The KobrA2 Multi-View Component Model Driven Software Engineering Methodology

1. The KobrA2Multi-View Component Model Driven Software Engineering Methodology Jacques Robin

2. Outline • History • KobrA Goals and Principles • Component Views • Component Relationships • Process • Illustrative Case Studies • KWAPIF: a KobrA2 Web App Platform-Independent Framework • A toy photo album web app, instance of KWAPIF • KMASPIF: a KobrA2 Multi-Agent System Platform-Independent Framework • A toy penalty simulation MAS, instance of KMASPIF

3. KobrA: History • KobrA1 • German project lead by Prof. Colin Atkinson at FhG-IESE (Fraunhofer-Gesellschaft, Institute of Experimental Software Engineering), Kaiserslautern, Germany • Resulted in publication of book "Component-Based Product Line Engineering with UML", Atkinson, C. and al., 2002, Addison-Wesley, 528 pages • Extended for component testing by European project Component+ involving 7 European academic and industrial research centers • Resulted in publication of book "Component-Based Software Testing with UML", Gross, H.B., 2004, Springer, 316 pages • Based on UML1.4, no OCL, no MOF

4. KobrA: History • KobrA2: • Brazilian-German project started in 2006, led by Profs. Colin Atkinson, Universität Mannheim, and Jacques Robin, UFPE • Goals: • Leverage lastest OMG standards: UML2, OCL2, MOF2 • Support most mature levels of MDE allowing full code generation by model transformation from fully refined Platform-Independent Models (PIMs) • Support full separation of concerns into complementary views of software component PIMs

5. KobrA1 Goals Component-Based Engineering (CBE) KobrA Product-Line Engineering (PLE) Model-Driven Engineering (MDE) 1 3 2

6. KobrA Principles:1. Separation of Concerns • Separate functionalities of whole software concerns into reusable components • For each component: • Separate PIM from PSM from code • Separate general product line framework model from specific product application model • Separate execution model from testing model • Separate public specification from private, encapsulated realization • Separate structural model from behavioral model from operational models (operations link behavior to structure) • Separate computational service aspects from data structure aspects • Separate concept (class) model from instance (object) model • Separate software methodology into: • prescribed or recommended artifacts, and • prescribed or recommended process (i.e., constraints on tasks producing these artifacts, including precedence)

7. Separation of Concerns Process does not fix whether to move first left, front or down in this cube Executability Instantiation Application Framework Framework Engineering Implementation Specificity Implementation Refinement/Nesting

8. KobrA Principles • Multiple views: • For each component, provide one view for each point in themulti-dimensional space of separated concerns • For each component, reconcile these views into a Single Unified Model(SUM) • Leverage OMG standards: • UML2 diagrams and OCL2 constraints and expressions for framework and application PIMs • MOF2 diagrams and OCL2 constraints to metamodel these framework and application level diagrams and associated constraints • UML2 diagrams and OCL2 constraints for software process modeling • Prescriptiveness • KobrA strives to precisely prescribe, as much as possible for a general purpose software engineering methodology, which UML2 and OCL2 model elements to use in each view of a KobrA component

9. Single Unified Model KobrA Principles • User only create and manipulate partial views of each KobrA component • These views are automatically transformed into a coherent Single Unified Model by model transformations Partial View 1 View 1 to SUM automated transformation Metamodel conformance verification automated transformations SUM to View 1 automated transformation Partial View 2 View 2 to SUM automated transformation SUM to View 2 automated transformation ... View N to SUM automated transformation Partial View N SUM to View N automated transformation

10. KobrA Principles • Formally specified rules to automatically check: • View-level well-formedness (i.e., conformance to prescribed relationships among model elements within one view of one component) • Component-level well-formedness (i.e., conformance to prescribed relationships among model elements across different views of one component) • Assembly-level well-formedness (i.e., conformance to prescribed relationships among model elements across views of different components) • Parsimony • Avoid as much as possible redundant model elements and views • Choose a minimum model element and diagram subsets from UML2, able to cover all the key aspects/concerns of a software component

11. KobrA Principles • Locality • All KobrA Views and UML2 diagrams are local to a given component • stereotyped as the «subject» component of the view, • and hence reusable "as is"; • The whole PIM of the system is derivable from the union of all these local models • Uniformity • The sole first-class modeling entity deserving to possess its own multiple views is the KobrA component • All behaviorally complex entities are modeled as KobrA components, including the system itself • Only behaviorally trivial system entities are modeled as KobrA classes, second-class modeling entity which structure and behavior are specified and realized in the views of their owning KobrA component

12. KobrA Principles • Top-down decomposition • The realization of any KobrA component K potentially consist of an assembly of finer-grained KobrA components, encapsulated in K and not directly visible outside of K • There is thus no fundamental difference between assembling existing components (i.e., engineering with reuse) and refining new components (i.e., engineering for reuse); • The root of this decomposition is the system being modeled; • Its leaves are the common functionalities provided by the most popular or standard API for the application domain at hand. • Component engineering/assembly driven process: • Thus, driven by architecture, • neither strictly by entities (like pure OO) • nor by relationships (like E-R DB engineering), • nor by functionalities (like use-case driven engineering); • Hence, avoids RUP inherent conflict between being entitiy-driven (objects) and functionality-driven (use-case).

13. = + Component External view point Specification Internal view point Realization = + KobrA Principles • Separate public specification from encapsulated realization • Realization as local assembly of finer-grained components • Component engineering (for reuse) = component assembly (with reuse)

14. KobrA Principles:Locality and Top-Down Decomposition Run-time Hierarchy Development Time Description Traditional approaches defines set of models “component of” relationship KobrA (Principle of Locality)

15. KobrA Conformance Rules Consistency relationships A Contract relationship Refinement relationships B

16. KobrA Conformance Rules Specification of server component must match realization of client component Clientship + Containment rules Clientship + Containment rules Containment rules Clientship rules Cliensthip rules Clientship + Containment rules Clientship rules

17. KobrA Principle:Creation Tree Driven Process • In general, the client/server model leads to arbitrary graph of interconnected components • But, an arbitrary graph has numerous shortcomings as software structure: • Neither model of composition/nesting, nor obvious development order • Tree based software structure has many advantages: • Natural model of composition/nested • Obvious development sequences • Recursive definitions and activities • Systematic • All together resulting in improved quality and reusability • How to reconcile arbitrary client server graph with tree-based process? • Solution: by projecting graph on creation tree • Every software entity must be created by exactly one other entity • Every object-oriented system running today contains a creation tree • An entity normally creates the things to which it has a strong composition relationship

18. KobrA Component Assembly Client-Server Graph Projected on Creation Tree A acquires B C D F E G creates I2 I1 H

19. KobrA2 Views

20. Realization Specification Structural Structural Class Class Service Type Service Type Instance Instance Service Type Service Type Operational Operational Service Type Service Type Behavioral Behavioral Protocol Algorithmic KobrA2 Component Views «merge»

21. KobrA2 Global Views:Operational Dependencies • Automatically derived from the Operational and Algorithmic Views local to each component • Operation O1 depends on operation O2 iff: • O2 is called in the OCL2 expression specifying the precondition, body orpost-condition of O1 (operational view) • O2 is called in the Activity Diagram A specifying the method of O1 (algorithmic view) • O2 is called in the OCL2 expression specifying a guard or a local post-condition in the Activity Diagram A specifying the method of O1 (algorithmic view)

22. KobrA2 Global Views:Component Class Dependencies • Automatically derived from the global operation dependency view and the local structural class views at each component • Component Class or (Data) Class C1 depends on Component Class or (Data) Class C2 iff: •  O1 operation  C1,  O2 operation  C2 | O1 depends on O2, or • C2 appears in the structural class service or type view of C1, or •  A associating C1 with C2, or • C1 specializes C2

23. Specification Structural Class Service View: Overview • Specifies the local assembly connections of the subject component class • Shows: • The name, public operation signatures and public attributes of: • subject component S0 • the component or (data) classes G1,..., Gm that immediately generalize S0 • the components S1, ..., Sn providing S0's required services • the components C1, ..., Cp that S0's creates before using as server • Generalization relationships from S0 to G1,...,Gm • Stereotypes associations «acquires» from S0 to S1,...,Sn • Stereotypes associations «creates» from S0 to C1,...,Cp • Structural OCL constraints, i.e., classifier invariants and property initialization, derivation and definitions, among the attributes or operation parameters of S0, G1,...Gm,S1,...,Sn, C1,...,Cp

24. Prototypical Specification Structural Class Service View

25. general * Generalization Classifier specific * * 0..1 powerType * GeneralizationSet powerExtent * DataType PrimitiveType Structured Classifier Behaviored Classifier 0..1 Class (from Reception) Enumeration Literal Instance Specification Enumeration /superClass EncapsulatedClassifier * * 0..1 ownedAttribute * memberEnd Property Association Class (from Kernel) Class (from StructuredClass) 2..* 0..1 Operation Parameter 0..1 ownedOperation * 0..1 ownedParameter * Component Specification Structural Class Type View: Reused UML2/OCL2 Metamodel 0..1 owningConstraint specification * constrainedElement * ValueSpecification Element Constraint Whole OCL2 Metamodel ownedRule * OpaqueExpression NamedElement TypedElement 0..1 context topExpression 0..1 Namespace OclExpression ExpressionInOcl bodyExpression 0..1 contextVariable selfOwner 0..1 Variable

26. Specification Structural Class Service View: Metamodel KobrA2 Extension Class (from Reception) Class (from Kernel) Constraint Property Component Association constrainedElement Structural Constraint ComponentClass Acquires Creates Class Derived context ownedRule constrainedElement Init Inv PropDef Classifier (from Kernel) DataType DataType String UnlimitedNatural PrimitiveType PrimitiveType Numeric Integer Boolean Real

27. Specification Structural Class Type View: Overview • Defines the non-primitive data types used by the subject component class • Shows: • The name, public operations signatures and public attributes of the (data) classes and association classes that type the parameters of the public operations of the components or (data) classes that appear in the Specification Structural Class Service View of the subject component class • The generalizations and associations (including association classes, aggregations and compositions) among these (data) classes and association classes • The structural OCL constraints among the properties and operation parameters of these classes and association classes • The definition of the enumerations that type the parameters of the public operations of the component or (data) classes that appear in the Specification Structural Class Service View of the subject component class

28. Prototypical Specification Structural Class Type View

29. general * Generalization Classifier specific * * 0..1 powerType * GeneralizationSet DataType PrimitiveType 0..1 Enumeration Literal Instance Specification Enumeration AssociationClass Specification Structural Class Type View: Reused UML2/OCL2 Metamodel 0..1 owningConstraint specification * constrainedElement * ValueSpecification Element Constraint Whole OCL2 Metamodel ownedRule * OpaqueExpression NamedElement TypedElement 0..1 context topExpression 0..1 Namespace OclExpression ExpressionInOcl bodyExpression 0..1 contextVariable selfOwner 0..1 Variable powerExtent * Structured Classifier Behaviored Classifier Class (from Reception) /superClass EncapsulatedClassifier * * 0..1 ownedAttribute * memberEnd Property Association Class (from Kernel) Class (from StructuredClass) 2..* 0..1 Operation Parameter 0..1 ownedOperation * 0..1 ownedParameter * Component

30. Specification Structural Class Type View: Metamodel KobrA2 Extension Class (from Reception) Class (from Kernel) Constraint Property Component constrainedElement Structural Constraint ComponentClass Class Derived context ownedRule constrainedElement Init Inv PropDef Classifier (from Kernel) DataType DataType String UnlimitedNatural PrimitiveType PrimitiveType Numeric Integer Boolean Real

31. Specification Structural Instance Service View: Overview • Defines typical instantiation patterns of the Specification Structural Class Service View of the subject component class • Shows: • «ComponentObject» stereotyped component object(s) O01,...,O0q1 instance(s) of subject component class S0 with their public slots • «ComponentObject» stereotyped component objects(s) S11,...,Snqn instances(s) of component classes S1,...,Sn providing the services requires by S0, with their public slots • «acquires» stereotyped links La11,...,Lanqn instances of the «acquires» stereotyped associations between S0 and S1,...,Sn • «ComponentObject» stereotyped component objects(s) S11,...,Snqn instances(s) of component classes C1,...,Cp created by S0 • «creates» stereotyped links Lc11,...,Lcpqp instances of the «acquires» stereotyped associations between S0 and C1,...,Cp

32. Prototypical Specification Structural Instance Service View

33. Specification Structural Instance Service View: Reused UML2/OCL2 Metamodel NamedElement Element PackageableElement owningInstance * Instance Specification Value Specification Slot 0..1 owningSlot value * * definingFeature OpaqueExpression Property StructuralFeature topExpression 0..1 0..1 contextVariable selfOwner 0..1 ExpressionInOcl Variable * * Classifier (from Kernel) Feature featuring Classifier TypedElement OclExpression bodyExpression

34. Specification Structural Instance Service View: Metamodel KobrA2 Extension InstanceSpecification Link Object AcquiresLink CreatesLink ComponentObject

35. Specification Structural Instance Type View: Overview • Defines typical instantiation patterns of the Specification Structural Class Type View, of the subject component class • Shows: • «ComponentObject» stereotyped instance specifications whose classifying classifier are the component classes occurring in the Specification Structural Class Type View of the subject component class • Instance specifications whose classifier are the (data) classes occurring in the Specification Structural Class Type View of the subject component class • Instance specifications whose classifier are the association classes occurring in the Specification Structural Class Type View of the subject component class • Instance specifications whose classifier are the associations (not classes) occurring in the Specification Structural Class Type View of the subject component class

36. Prototypical Specification Structural Instance Type View

37. Specification Structural Instance Type View: Reused UML2/OCL2 Metamodel Same as Specification Structural Instance Service View NamedElement Element PackageableElement owningInstance * Instance Specification Value Specification Slot 0..1 owningSlot value * * definingFeature OpaqueExpression Property StructuralFeature topExpression 0..1 0..1 contextVariable selfOwner 0..1 ExpressionInOcl Variable * * Classifier (from Kernel) Feature 0..1 resultVariable resultOwner 0..1 featuring Classifier * parameterVariable varOwner 0..1 TypedElement OclExpression bodyExpression correct

38. Specification Structural Instance Type View: Metamodel KobrA2 Extension InstanceSpecification Link Object ObjectLink ComponentObject

39. Specification Operational Service View: Overview • Declaratively specifies the behavioral contracts between the component classes of the Specification Structural Class Service View of the subject component class • Shows: • The OCL precondition, postcondition or body constraints of the operations whose signatures are given in the Specification Structural Class Service View of the subject component class

40. context CC0::op01(in pa011:Cl2, inout p012:Boolean, out p013:Real):Clapre: qboe011body: qoe011 context CC0::op02(pa021:Set(Integer)):OrderedSet(Tuple(Integer,String)) pre: qboe021post: pboe021 context CC1::op11(pa111:Bag(Cla)):Sequence(String)pre: qboe111 context CC1::op12():CC2body: qoe121 context CC2::op21():Clbpost: pboe211 context Cla::opa1(in paa11:Cl2, inout paa12:Boolean, out paa13:Real):Clbpre: qboea11body: qoea11 context Cla::opa2(paa21:Set(Integer)):OrderedSet(Tuple(Integer,String) pre: qboea21post: pboea21 context Clb::opb1(pab11:Bag(Cla)):Sequence(String)pre: qboeb11 context Clb::opb2():CC1post: qboeb21 context Clc::opc1():Clapost: qboec11 Conventions: q: OCL query expression p: OCL postcondition expression b: OCL boolean expression oe: Ocl Expression CC: Component Class Cl: Class op: Operation pa: parameter PrototypicalSpecification Operational Service View

41. Specification Operational Service View: Reused UML2/OCL2 Metamodel Namespace 0..1 context BehavioralFeature ownedRule * Class (from Kernel) 0..1 preContext precondition * NamedElement owningConstraint Operation Constraint specification 0..1 postContext postcondition * 0..1 0..1 ValueSpecification 0..1 bodyContext bodycondition * * ownedOperation * constrainedElement OpaqueExpression * Element 0..1 contextVariable selfOwner 0..1 Variable ExpressionInOcl 0..1 resultVariable resultOwner 0..1 * parameterVariable varOwner 0..1 TypedElement Whole OCL2 Metamodel topExpression 0..1 bodyExpression OclExpression

42. Specification Operational Service View: Metamodel KobrA2 Extension Operation Constraint OclExpression EffectOperation BehavioralConstraint PostExp PreExp Pre Post

43. Specification Operational Type View: Overview • Declaratively specifies the behavioral contracts between the component classes, (data) classes and association classes of the Specification Structural Type View of the subject component class • Shows: • The OCL precondition, postcondition or bodies constraints of the operations whose signatures are given in the Specification Structural Type View of the subject component class

44. context Cla::opa1(in paa11:Cl2, inout paa12:Boolean, out paa13:Real):Clbpre: qboea11body: qoea11 context Cla::opa2(paa21:Set(Integer)):OrderedSet(Tuple(String,Integer) pre: qboea21post: pboea21 context Clb::opb1(pab11:Bag(ACa)):Sequence(String)pre: qboeb11 context Clb::opb2():CC1post: qboeb21 context Clc::opc1():ACapost: qboec11 context ACA::opA1(in paA11:Cl2, inout paA12:Boolean, out paA13:Real):Clbpre: qboeA11body: qoeA11 context ACA::opA2(paA21:Set(Integer)):OrderedSet(Tuple(Integer,String)) pre: qboeA21post: pboeA21 context ACB::opB1(paB11:Bag(ACA)):Sequence(String)pre: qboeB11 context ACB::opB2():CC1post: qboeB21 context ACC::opC1():Clapost: qboeC11 PrototypicalSpecification Operational Type View

45. Specification Operational Type View: Reused UML2/OCL2 Metamodel Same as Specification Operational Service View Namespace 0..1 context BehavioralFeature ownedRule * Class (from Kernel) 0..1 preContext precondition * NamedElement owningConstraint Operation Constraint specification 0..1 postContext postcondition * 0..1 0..1 ValueSpecification 0..1 bodyContext bodycondition * * ownedOperation * constrainedElement OpaqueExpression * Element 0..1 contextVariable selfOwner 0..1 Variable ExpressionInOcl 0..1 resultVariable resultOwner 0..1 * parameterVariable varOwner 0..1 TypedElement Whole OCL2 Metamodel topExpression 0..1 bodyExpression OclExpression

46. Specification Operational Type View: Metamodel KobrA2 Extension Same as Specification Operational Service View Operation Constraint OclExpression EffectOperation BehavioralConstraint PostExp PreExp Pre Post

47. Specification Behavioral Protocol View: Overview • Defines the external visible state transitions of the subject component class together with the restricted subset of its public operation that is available for invocation in each of these states • Contains a simple UML2 protocol state machine without: • transition's operation post-conditions, for these are redundant with the transition's target state invariant • associated port or interface, for protocol state machines are directly associated with components in KobrA2 • states with embedded state machines • multiple regions • connection points • The sequence of operations on the state machine transitions represent the protocol to follow to satisfy the invocation contract of the services provided by the subject component class

48. PrototypicalSpecification Behavioral Protocol View psm1 {protocol} [qbs0] op0() / S0 [qbe0] [qb01] op01(pa011:(Real,Boolean)) / S1 [qbe1] [qbe13] op13() / [qbe12] op12 (in pa121:Integer inout pa122:en122, out pa123:Seq(String) / [qbe32] op3() / S3 [qb3] S2 [qbe2] [qbe22] op22(pa221:CC2) / [qbe31] op3() / [qbe2f] op2f(pa2f1:Cl1) / ebe2f [qbe3f] op3() / ebe3f

49. Specification Behavioral Protocol View: Reused UML2/OCL2 Metamodel outgoing source Transition Vertex Region target incoming * 0..1 0..1 PseudoState kind: PseudoStateKind StateMachine ProtocolTransition Protocol State Machine referred * Namespace FinalState State Operation precondition 0..1 guard 0..1 0..1 owningState 0..1 context ownedRule Constraint specification 0..1 owningConstraint «enumeration» PseudoStateKind initial ... terminate ValueSpecification stateInvariant 0..1 OpaqueExpression OclExpression ExpressionInOcl bodyExpression topExpression

50. Specification Behavioral Protocol View: Metamodel KobrA2 Extension classifierBehavior BehavioredClassifier Protocol Transition Pseudo State Behavior Region State Operation 0..1 0..1 Class (from Reception) Protocol Transition Pseudo State State Operation StateMachine Region ProtocolStateMachine ComponentClass ProtocolStateMachine