 FOAL 2010 Modeling Aspects by Category Theory Serge P. Kovalyov Novosibirsk, Russia.

Slides:



Advertisements
Similar presentations
Three-Step Database Design
Advertisements

1 Events, Actions, and Compositions Somayeh Malakuti, Christoph Bockisch, Mehmet Aksit Software Engineering Group
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Event structures Mauro Piccolo. Interleaving Models Trace Languages:  computation described through a non-deterministic choice between all sequential.
An Aspect-Oriented Approach For Web Application Access Control Presented by: Mohamed Hassan Carleton University Carleton University
ASTA Aspect Software Testing Assistant Juha Gustafsson, Juha Taina, Jukka Viljamaa University of Helsinki.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 32 Slide 1 Aspect-oriented Software Development.
Design Concepts and Principles
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
ASPECT ORIENTED SOFTWARE DEVELOPMENT Prepared By: Ebru Doğan.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 8 The Enhanced Entity- Relationship (EER) Model.
1 Objectives To introduces the concept of software Design. To introduce the concept of Object- Oriented Design (OOD). To Define various aspects about object.
CS 290C: Formal Models for Web Software Lecture 6: Model Driven Development for Web Software with WebML Instructor: Tevfik Bultan.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 32 Slide 1 Aspect-oriented Software Development 2.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 11 System Test Design
1 Model Interface Implementation for Two-Way Obliviousness in Aspect-Oriented Modeling Presented by Wuliang Sun Department of Computer Science Baylor University.
Deriving AO Software Architectures using the AO-ADL Tool Suite Luis Fernández, Lidia Fuentes, Mónica Pinto, Juan A. Valenzuela Universidad de Málaga
UML - Development Process 1 Software Development Process Using UML (2)
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
DBMS Lecture 9  Object Database Management Group –12 Rules for an OODBMS –Components of the ODMG standard  OODBMS Object Model Schema  OO Data Model.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
Towards Executable Aspect-Oriented UML Models 10th Int. Workshop on Aspect-Oriented Modeling (AOM), 6th Int. Conf. on Aspect-Oriented Software Development.
1 N Degrees of Separation: Multi-Dimensional Separation of Concern (MDSOC) HyperJ: language and concepts of general concern combination.
Aspect Oriented Programming Razieh Asadi University of Science & Technology Mazandran Babol Aspect Component Based Software Engineering (ACBSE)
VERIFICATION OF ASPECT ORIENTED MODELS BY DON MARTIN JAYASHREE VENKIPURAM PATHANGI PIYUSH SRIVASTAVA REFERENCES F. Mostefaoui and J. Vachon,” Design level.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
SOFTWARE DESIGN.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 32 Slide 1 Aspect-oriented Software Development 1.
MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office. All other product or service names are the property of their respective.
SOFTWARE DESIGN Design Concepts Design is a meaningful engineering representation of something that is to be built It can be traced to a customer’s requirements.
POSL (Principles of Software Languages) Gr. Kyushu Institute of Technology, Japan Pointcut-based Architectural Interface.
Aspect Oriented Programming Gülşah KARADUMAN.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Hong Zhu Dept of Computing and Communication Technologies Oxford Brookes University Oxford, OX33 1HX, UK TOWARDS.
The Representation of Reality in Computational Form Nick Rossiter Visiting Fellow with Michael Heather and Dimitrios Sisiaridis Computing, Engineering.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Aspect-Oriented Action Semantics Descriptions Luis Menezes University of Pernambuco
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Alloy-based Lightweight Verification for Aspect-oriented Architecture Naoyasu Ubayashi(Kyushu Institute of Technology) Yuki Sato(Kyushu Institute of Technology)
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
1 Software Design Lecture What’s Design It’s a representation of something that is to be built. i.e. design  implementation.
1 Context-aware Feature-Oriented Modeling with an Aspect Extension of VDM Naoyasu Ubayashi (Kyushu Institute of Technology) Shin Nakajima (National Institute.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Properties as Processes : FORTE slide Properties as Processes: their Specification and Verification Joel Kelso and George Milne School of Computer.
Applying Aspect-Orientation in Designing Security Systems Shu Gao Florida International University Center for Advanced Distributed Systems Engineering.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
CS223: Software Engineering Lecture 13: Software Architecture.
Aspect-Oriented Software Development (AOSD)
An Object-Z / CSP Based Approach for the Specification of Architectural Connectors Mourad Maouche Philadelphia University Jordan Mohamed Bettaz MESRS Algeria.
Architectural Design Rewriting as Architectural Description Language R. Bruni A. LLuch-Lafuente U. Montanari E. Tuosto.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
OSLC PLM Reference model February Summary of the OSLC PLM Reference Model V0.2 February 22 nd 2011 Gray Bachelor Mike Loeffler OSLC PLM Workgroup.
CHESS Methodology and Tool Federico Ciccozzi MBEES Meeting Sälen, January 2011 January 2011.
Design Concepts ch-8
Lecture 9- Design Concepts and Principles
Software Quality Engineering
Software Design Methodology
CS201: Data Structures and Discrete Mathematics I
Logical architecture refinement
Object-Oriented Design
Chapter 20 Object-Oriented Analysis and Design
Lecture 9- Design Concepts and Principles
Event-Based Architecture Definition Language
Architecture Description Languages
An Introduction to Software Architecture
Algebraic Trace Theory
Presentation transcript:

 FOAL 2010 Modeling Aspects by Category Theory Serge P. Kovalyov Novosibirsk, Russia

Aspect-oriented software development  Mission: explicit separation and composition of concerns  Motivation  Concerns are tangled  Concerns crosscut modular architecture bounds  Traceability is compromised (ability to determine what each fragment of the system is included into it for)  Proposed solution  Equip program models with traces of refinements that produce them from concerns (i.e. “label” programs by concerns)  Explicitly identify, compose (weave), and separate concerns  Application: enhance modular design technologies with aspect handling capabilities  FOAL 2010

Category-theoretic formalization  Explicit definition of intuitive notions  Objects (things)  Morphisms (connections)  Functors (translations)  Describing objects via relations with similar objects  Avoiding appeal to “interiors” of objects  Constructing object by systemic criteria  Universality (existence and uniqueness of connection with similar objects)  Naturality (independence of the result on the way it is reached)  Formal specification and verification of systemic properties  Complexity  Modularity  Traceability  FOAL 2010

Category of descriptions  Category c-DESC  Objects are formal models of programs (descriptions)  Morphisms are actions of integrating components into systems  Composition is multistep integration  Identity morphisms are “doing nothing”  Example: category of UML classes and inheritance relations  Scenario modeling  Category Pos  Objects are partially ordered sets (posets) of events ordered by causal dependence  Morphisms are poset homomorpisms (preserving events and ordering)  FOAL 2010

Diagrams  c-DESC-diagram  Functor  : X  c ‑ DESC  Graph of X labeled by c ‑ DESC-objects and c ‑ DESC-morphisms  Cocone  Natural transformation of a diagram (base) to a singleton (vertex)  Colimit of a diagram   Universal cocone with base   Minimal “container” that encapsulates objects of  respecting their interconnections  FOAL 2010

Configurations  Well-formed configuration  Is a c-DESC-diagram (of components and their interconnections)  Has a colimit (system built from interconnected components)  Satisfies structural constraints  Configurations of scenarios  Well-formed configurations are disjoint unions of cocones  Examples  FOAL 2010 well-formed: parallelism ill-formed: concurrency

Interfaces  Category SIG of interfaces and their integration actions  Functor sig : c-DESC  SIG  Default realization of any interface  Functor sig* : SIG  c-DESC  sig ◦ sig* = 1 SIG  Bijective map Mor(sig*(I), A) to Mor(I, sig(A)) by functor sig (i.e. sig* is left adjoint to sig with identity as the unit)  Example: signature of a program module  Scenario interface  Set of events  Forgetful functor |–| : Pos  Set  FOAL 2010 |–|

Refinements  Category r-DESC  Objects are models  Morphisms are refinements (individual component development steps)  Examples  Elaborating requirements  Implementing specification by means of a programming language  Scenario refinement  Replacing atomic events with subscenarios fully inheriting the order  Dual to a surjective homomorphism  FOAL 2010

 Tracing a refinement r : X  S  Labeling S by concerns that constitute X  Trace is a c-DESC-morphism t : S  X dual to a refinement  sig(t) has right inverse (to preserve traceability at subsequent integrating S into a larger system) Traceable refinements  FOAL 2010 r s : sig(t) ◦ s = 1 X S sig(X) sig(S) t = r op sig(t) sig  Every refinement of scenarios is traceable

Enhancing descriptions with aspects  Aspect-oriented description is a pair  A, l : sig(A)  L   A  Ob c ‑ DESC is a “modular” part  L  Ob SIG is an aspect structure  l labels sig(A) by aspects (sig(l) is a trace)  Morphism of AO-description  A, l  to  A', l '  is a pair  p, q   A, l : sig(A)  L  p  sig(p)   q  A', l ' : sig(B)  L'   Aspect-oriented scenarios  Object are pomsets (labeled posets)  Morphisms are homomorphisms that preserve labeling  FOAL 2010

Aspect-oriented design  AO-configurations are modular configurations that admit any labeling of components by aspects (i.e. have suitable colimit)  Interfaces of AO-descriptions  mod :  A, l  |  A (modular design interfaces)  asp :  A, l  |  l (aspect design interfaces)  int :  A, l  |  sig(A) (original interfaces)  AO-refinements are duals to such AO-morphisms that are produced from traces  Aspect-oriented scenario modeling  Configurations are disjoint unions of AO-cocones  Functor mod forgets labeling  Functor mod* labels each event by a unique label (event itself)  Refinement replaces events with subscenarios fully inheriting the order and detailing the labeling  FOAL 2010

Aspects  Aspects are “elementary” building blocks of AO-descriptions  An integration of an aspect into a system is an invertible embedding at the level of aspect structures  A is an aspect iff for every object A' and morphism  p, q  : A  A' q has left inverse (often a trace)  Aspects in scenario modeling  Aspect is a scenario with all events labeled by the same label  Aspect is precisely a pair  A, ! : |A|  1   FOAL 2010

Weaving  Specifying how to weave an advice W with a base program B  Connector: C  Pointcut descriptor: j : C  B  Entry points descriptor: e : C  W  Performing weaving  Pushout (colimit):  1 C, e  : C  C  W j   B  X  Weaving labeled scenarios  Weaving exists if a connector “tolerates” concurrency (i.e. it doesn’t impose specific order of executing different aspects of the advice bound to the same join point )  Weaving with an aspect preserves labeling of a base  FOAL 2010

Explication of aspect structure  Explication of aspect structure of an AO-description  A, l   Obtaining “actual” refinement from concerns  r ‑ DESC-morphism s : X  A where s op is a trace and sig(s op ) = l  An explication of  A, l  is universal if every AO-morphism  p, q  :  A, l    A', l '  has an explication (provided that  A', l '  has) p : A  A' s op   r op p' : X  X '  Explicating labeled scenarios  Every explication is universal  Every aspect is explicable  “Many” scenarios are inexplicable e.g. interleaving  FOAL 2010

Separation of concerns  Subaspect of an AO-description S  AO-morphism m : A  S where A is an explicable aspect  Explication m' of m is right inverse to a trace  Explication diagram of m is a pullback (i.e. mod(m) is a “preimage” of m' along an explication trace of S)  An aspect has no proper subaspects  If S is an aspect, then m is an isomorphism  Each explicable labeled scenario can be partitioned to subaspects  Each scenario can be labeled by linearly ordered subaspects  Maximal partition: assign a unique label to each event (i.e. apply mod*)  Minimal partition: factorize by linear equicomparability relation  FOAL 2010

Industrial application  Distributed measurement system (DMS) development  Main measurement cycle is linear order of separable aspects  Measurement automation infrastructure aspects are woven to it undermining separation of concerns  DMS scenario weaving schema measure  store  validate  compute  display      FOAL metadata model + monitoring + security

Summary  Understanding systemic nature of AOSD concepts  Providing formal paradigm-neutral description of  Aspects  Weaving  Explication of aspect structure  Separation of concerns  Verifying structural properties of aspect-oriented operations  Applying in concurrency theory: labels are aspects  Applying in industry: large-scale DMS development  FOAL 2010

Thank you for your attention  FOAL 2010