Software Components and the KobrA Model-Driven Component-Based Software Engineering Methodoloy

1. Software Components and the KobrA Model-Driven Component-Based Software Engineering Methodoloy Jacques Robin

2. Outline • UML2 Components • KobrA Components • KobrA2 Components

3. UML2 Classifier Compartments Name Attributes Operations NestedClassifiers Nested Classes, Components, Interfaces & Associations linking their attributes, Realizations, Usages & Generalizations Encapsulated within containing Kernel::Class

4. UML2 Components • New to UML2 for all lifecycle stages except deployment • Specialize encapsulated classes • The behaviors that it provides to its environment are only accessible through itsprovided interface(s) • The behaviors that it expects its environment to provide to it are only accessible through its required interface(s) • Through these associated interfaces, a UML2 component defines an abstract behavioral type independent of its realization • The interfaces of a UML2 component can be either: • Directly associated to it, or • Indirectly associated to it through its ports. • The abstract behavior type specified by a UML2 component can be realized either: • Directly by the component itself; • Indirectly by the assembly of its internal parts; • Indirectly by a set of external classifiers. • A UML2 packageable component specializes a UML2 component by grouping all the artifacts involved in the component specification or realization into a package

5. UML2 Component: Meta-Model realizingClassifier nestedClassifier ownedConnectors * Kernel::Class Kernel::Classfier Connector Feature 0..1 * CompositeStructures::Classfier Property StructuralFeature parts * 0..1 Port CompositeStructures::Encapsulated Classfier ConnectableElement ownedPort * 0..1 CompositeStructures::Class * provided * Interface Component * required * 0..1 0..1 PackageableElement packagedElement * ComponentRealization Realization abstraction realization * *

6. Component.requiredInterface.name Component.providedInterface.name Component.requiredInterface Component.providedInterface Component Component.providedInterface.name Component.name Component.requiredInterface Component.providedInterface Component.requiredInterface.name Component.requiredInterface Component Diagram without Interface Operations: Link to Meta-Model

7. Component Diagram with Interface Operations: Link to Meta-Model Component.providedInterface Component.requiredInterface Component InterfaceRealization Usage Component.requiredInterface.name Component.providedInterface.name Component.name Component.providedInterface.operation

8. Component.nestedClassifier.ownedAttribute.upper = Component.nestedClassfier.ownedAttribute.lower Component Component.name Component.nestedClassifier= Class Component. providedInterface. name Component. nestedClassifier.name Component.nestedClassifier.ownedAttribute.isComposite = true Component. requiredInterface Component. providedInterface Component.nestedClassifier= Association Component.nestedClassifier.ownedAttribute. name Component. requiredInterface. name Component. nestedClassifier.name Component.nestedClassifier= Class Component Diagram Nested Classifiers Compartment: Link to Meta-Model NestedClassifiersCompartment

9. Component. ownedPort Component.ownedConnector Component.ownedConnector.ConnectorEnd.type Component.ownedConnector.kind = #delegate Component Component. providedInterface. name Component.name Component.part.type = Component Component.part.type = Component Component. providedInterface Component.part.type.name Component.part.type.name Component. ownedConnector. kind = #assembly Component. ownedPort Component. ownedConnector. ConnectorEnd. type Component.ownedConnector Component.ownedConnector.kind = #delegate Component.part.type.name Component. requiredInterface. name Component.part.type = Component Component. requiredInterface Component Diagram Parts Compartment: Link to Meta-Model PartsCompartment

10. Component-Based Engineering (CBE) • Vision • Assemble applications from prefabricated parts • COTS component market • Web Services • Vision • Development activities oriented around product families • Manage commonalities and variabilities KobrA Product-Line Engineering (PLE) Model-Driven Engineering (MDE) • Vision • Capture core software assets as platform-independent models (PIMs) • Automatically map PIMS to PSMs to codethrough model transformation 1 3 2 KobrA Goals • Pre-KobrA Obstacles • Current technologies (.NET, J2EE) exclusively at the code-level • Little understanding of how to scope components • Pre-KobrA Obstacles • Lack of systematic methods for creating PIMs • Fixed and Ad-hoc mapping techniques • Obstacles • Larges upfront investment • Poor connection with regular “single-system” technology

11. KobrA Characteristics • Integrates: • Model-Driven Engineering • Component-Based Engineering • Product-Line Engineering • Object-Oriented Engineering • Recursive Top-down Decomposition/Refinement • Design Patterns • Quality Assurance • Scope focus: • In essence PIM construction, even tough historically conceived before OMG’s distinction of CIM, PIM, PSM and source code executability levels • Engineering for reuse and then with reuse (weak on reuse of software artifacts not developed for reuse) • Highest level part of CMMI technical solution process area • Artifact specification separate from process specification (idea reused in SPEM2.0 standard) • Why? • Provide precise guidance on which UML diagrams to use for each part of a KobrA component model • Without sacrificing process flexibility to be adaptable to a wide range of circumstantial process needs

12. KobrA Principles • Uniformity to achieve simplicity and scalability through recursive artifact nesting: • Uniform recursive software unit: KobrA component • Only behaviored classifier are KobrA components • Only operation-less Classes used only for data modeling • Uniform modeling language: precisely prescribed restricted subset of UML1.4 diagrams completed with tables with predefined fields filled by unrestricted natural language • Component engineering/assembly driven process: • Thus driven by architecture, • neither by entities and relationships (like BD and OO engineering), • nor by functionalities (like use-case driven engineering); • Avoids RUP inherent conflict between being entities (object) driven and functionality (use-case) driven

13. = + Component External view point Specification Internal view point Realization = + KobrA Principles: Encapsulation • KobrA component clearly separates: • the externally exposed structure and behavior of a component needed • from its internally hidden structure and behavior that realize the exposed ones as assembly of nested component • thus component engineering (for reuse) = component assembly (with reuse)

14. KobrA Principles: Creation TreeDriven Process • In general, the client/server model leads to arbitrary graph of interconnected components • But, an arbitrary graph has numerous shortcomings as software structure: • No model of composition/nesting • No 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 reconciling arbitrary client server graphs 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

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

16. KobrA Principles • Locality: • All diagrams show a restricted view of the global PIM limited to artifacts directly related to a given component • Thus global PIM results from assembly of local UML diagrams and complementary tabular and natural language artifacts • Separation of concern by distinguish 3 orthogonal engineering axis: • Specificity axis (product line common framework components vs. product specific components) • Refinement/nesting axis (refinement level through recursive engineering/assembly of nested components) • Executability axis (CIM, PIM, PSM, source code)

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

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

19. KobrA Local Primary Artifacts Specification Behavior Model (UML statechart diagram) Functional Model ( Operation specifications) Structural Model (UML class/object diagrams) KobrA Component Interaction Model (UML collaboration diagrams) Structural Model (UML class/object diagrams) Realization Activity Model (UML activity diagrams)

20. KobrA Component Functional Specification • For each operation provided as service by the component: • One table with predefined fields filled with unrestricted natural language descriptions • e.g., createAccount Operation Specification

21. KobrA Local Complementary Artifacts • Non-functional requirements specification • desired quality characteristics • Quality Measures • desired quality thresholds and the related quality factors • Dictionary • tables of model entities and their role • Test Cases • test cases to support functional testing • Decision Model • variable features and related user decisions

22. KobrA Local ArtifactConformance Rules Consistency relationships A Contract relationship Refinement relationships B

23. Clientship + Containment rules Clientship + Containment rules Containment rules Clientship rules Cliensthip rules Clientship + Containment rules Clientship rules KobrA Local Artifact Assembly • Specification of server component must match realization of client component

24. Interaction Model Structural Model (UML collaboration diagrams) (UML class/object diagrams) Realization Activity Model (UML activity diagrams) KobrA Top-Level Artifact:Context Realization • Corresponds to: • CIM in MDE, • Domain model in domain engineering • Business model in early requirement engineering; • KobrA’s uniformity principle: • Whole system = all containing top level server component • Server of whom? • Of system usage context = non-computational environment! • Its specification must conform to some containing client component • The non-computational environment is thus represented using a set of artifacts that specializes the artifacts of a KobrA component realization • This context realization is thus a peculiar specification-less KobrA Component

25. Specification Realization Cpt A Cpt C Component Reuse Cpt B COTS Component Cpt D KobrA Recursive Process • Interleaves component specification with component realization • COTS reused by wrapping them in KobrA specification constructed by black-box reverse engineering

26. Cpt ASource Code Cpt A PIM Cpt A PSM Cpt CSource Code Cpt B PIM Cpt B PSM Cpt C Source Code Cpt C PIM Cpt C PSM KobrA: Refinement Process Orthogonal to Implementation Process • Refinement: recursive PIM component specification and realization down the component nesting structure • Implementation: translation of PIM to PSM and code

27. KobrA Process Activities Top-Down Recursive Nested Assembly Single Component

28. KobrA Specification Process Activities • Business process modeling • who does what to what and when • actors, activities, data and rules • described at “business” level of abstraction • Data modeling • identify organizational and technological data • identify information and material data • Usagemodeling • activity modeling • decompose activities thatinvolve the “system” • interface design • screen templates, dialogues etc. • Interactionmodeling • integrate actors, activities, data and rules

29. Role of Use Cases in KobrA • Traditional use-case modelling roughly covers the concerns addressed by usage and interaction modelling • use case modelling = usage modelling + interaction modelling • A use case corresponds to an activity asociated with the software system • use case = activity associated with the software system • a use case diagram can be used to document such activities • The system is one of the actors or data items identified in the “to be“ business process models

30. KobrA Process Realization Activities • Structural model • describes the data and components needed by the component in order to fulfill its contract • one or more class diagrams • zero or more object diagrams • Activity model • describes the algorithms used to realize the operations of the component • zero or more activity diagrams • Interaction model • describes how operations of the component are realized in terms of interactions • zero or more interaction diagrams (per operation)

31. KobrA: Product Line Artifacts • Generic framework component contains all the functionalities of all their possible product specific instantiations • <<variant>> stereotype in framework component model elements not general to all products • Decision model: • Maps characteristics of product to <<variant>> stereotyped model elements to include in corresponding product • Table with predefined fields filled with natural language

32. KobrA PLE:Example of FrameworkClass Diagramwith <<variant>>stereotype

33. KobrA PLE Framework Artifacts Decision Model Specification (textual) Behavior Model (UML statechart diagram) Functional Model operation schemata) ( Structural Model (UML class/object diagrams) KobrA Framework Component Structural Model (UML class/object diagrams) Interaction Model (UML collaboration diagrams) Activity Model (UML activitydiagrams) Decision Model Realization (textual)

34. KobrA Built-In Contract Testing (BICT) • KobrA’s principle of uniformity and locality applied to testing • Built testing capability locally in each component • The component assembly not only results in application by functionality composition • But it also results in testing infrastructure composition that saves work of constructing a global application specific testing infrastructure • Key idea: • Add to each client component a nested tester component to test each server to which it may be connected through assembly • Add to each server component a testing interface distinct from the functional interface that can be used by the nested tester component of the clients to which it may be connected through assembly • The testing interface expose state information not needed for the application execution but needed for its testing

35. <<uses>> KobrA Built-In Contract Testing (BICT) <<uses>> <<Component>> Server A <<Interface>> Server A <<Component>> Client B <<Component>> Client B w/ BICT <<Tester Component>> Tester(A) <<Component>> Server A w/ BICT <<Testing Interface>> Server A

36. Limitations of KobrA • Based on UML1.4 which did not support neither for MDE nor CBE: • Monolithic meta-model, unpractical for partial reuse in profiles for building PSM • No OCL, thus no fully refined PIM in an unambiguous computational language free of natural language, thus no possibility for automated code generation through model transformation • No full-life cycle components (only in deployment diagram), thus no design by contract PIM • Narrow scope not covering: • Implementation • Model transformation • Focuses on design for reuse: • Provides little guidance for design with reuse from legacy software, refactoring, reverse engineering, etc. • Simplistic, not scalable PLE variation modeling scheme • Does not deal with component repository management

37. KobrA2 Improvement Goals • Support more advanced forms of MDE and CBE • By leveraging the latest OMG standards: • UML2.1 modular meta-model and better founded profiles • UML2.1 full life cycle components • OCL2.0 to model PIM, PSM, meta-models and UML2.0 profiles that are: • Fully refined, yet free of natural language ambiguities, • thus viable input to fully automatic model transformation • MOF2.0 and Ecore to define meta-model of KobrA2 • SPEM2.0 to support full KobrA2 method and process modeling • By leveraging latest Eclipse integrated MDE CASE tools: • Eclipse Modeling Framework (EMF, based on Ecore) • Eclipse Process Framework (EPF, based on SPEM2.0) • Borland Together (based on EMF) • Atlas Transformation Language Development Tool (ATL-DT, based on EMF) • Leverage model transformation to: • Weave product-specific elements onto framework components instead of or in addition to instantiating them • Add on and take off BICT artifacts

38. Profile: Top-Level Package K2View * K2Specification ActorView * K2Specification InstanceView K2Specification TypeView K2Specification ServiceView K2Specification OperationView K2Specification LifeCycleView * * 1..* * K2Specification FunctionallView K2Specification StructuralView K2Specification BehavioralView K2SpecificationView K2View K2TopView K2View K2Component Component 1..* K2Realization StructuralView K2Realization BehavioralView K2RealizationView K2Realization FunctionallView * * * 1..* K2Realization AlgorithmicView K2Realization InstanceView K2Realization TypeView K2Realization ServiceView K2Realization OperationlView K2Realization CollaborationView 1..* * K2View

39. <<K2TopView>> Comp1 <<K2SpecificationView>> Comp1Specif <<K2SpecificationStructuralView>> Comp1StructSpecif <<K2TypeSpecificationView>> Comp1TypeSpecif <<K2InstanceSpecificationView>> Comp1InstanceSpecif <<K2ServiceSpecificationView>> Comp1ServSpecif <<K2SpecificationBehavioralView>> Comp1BehavSpecif <<K2SpecificationFunctionalView>> Comp1FuncSpecif <<K2SpecificationLifeCycleView>> Comp1LifeCycleSpecif <<K2RealizationAlgorithmicView>> Comp1AlgoRealiz <<K2SpecificationOperationView>> Comp1OperSpecif <<K2SpecificationActorView>> Comp1ActorSpecif <<K2RealizationView>> Comp1Realiz <<K2RealizationStructuralView>> Comp1RealizSpecif <<K2TypeRealizationView>> Comp1TypeSpecif <<K2InstanceRealizationView>> Comp1InstanceSpecif <<K2ServiceRealizationView>> Comp1ServRealiz <<K2RealizationFunctionalView>> Comp1FuncSpecif <<K2RealizationBehavioralView>> Comp1BehavRealiz <<K2RealizationOperationView>> Comp1OperRealiz <<K2RealizationCollaborationView>> Comp1CollabRealiz Prototypical Top-Level Views

40. Profile: Specification Service View K2SubjCompoClassSSV • K2CompoClassSSV have neither attributes,nor operations, nor nested classifiers Component K2CompoClassSSV 1..* • Each non-specialized K2ISSV must be linked to the K2SubjCompoSSV through either a K2IRealiz or a K2Use Interface K2ISSV 1..* K2IOp Operation 2..* • A K2IOp is necessarily part of an K2ISSV K2GetState Parameter K2OpArg * • K2ClassAsType only has a name and a multiplicity. • It has no attribute, operation, nor nested classifiers K2Specification ServiceView K2ClassAsType Class * DataType K2DType • A K2Realiz does not stereotype UML2 InterfaceRealization and a K2Use does not stereotype UML2 Usage because these two UML2 metaclasses specialize PackagableElement and not Classifier: they therefore do not specialize MultiplicityElement nor can they type an InstanceSpecification. • A KobrA2 model needs to be able to express multiplicity constraints on how many instances of each server component class (respect. client component class) can connect to the required (respect. provided) interface of a subject component class • Therefore K2Realiz and K2Use stereotype UML2 Association * EnumerationLiteral K2EnumLit * K2Realiz 1..* K2Use Association * Property K2Attr * K2IGen Generalization * K2Invar Constraint * • A K2IGen can only relate two K2ISSV ExpressionInOCL K2ConstrExp *

41. Interface Component Association Interface +op2(dir2 param2:type3[mult3], ... ):type4[mult4] ... Component ExpressionInOCL Interface Interface Association Class Class or or DataType DataType Association or or Enumeration Enumeration Component Prototypical Specification Service View +getState()::CC1State +op1(dir1 param1:type1[mult1], ... ):type2[mult2] ... <<K2ISSV>> I1 mult13 <<K2CompoClassSSV>> CC0 <<K2Use>> mult12 <<K2ISSV>> I2 <<K2Realiz>> <<K2SubjCompoClassSSV>> CC1 mult11 mult10 context I4 inv: inv1 OCLExp1 Constraint Generalization <<K2Use>> <<K2Use>> <<K2ISSV>> I3 <<K2ISSV>> I4 +getState():CC4State +op4(dir4 param4:type7[mult7], ... ):type8[mult8] ... +getState():CC3State +op3(dir3 param3:type5[mult5], ... ):type6[mult6] ... Operation Parameter mult14 mult15 <<K2Realiz>> <<K2Realiz>> <<K2CompoClassSSV>> CC3 <<K2CompoClassSSV>> CC4

42. Profile: Specification Type View 1..* Class K2ClassTV • Each behavior modeled by a K2IOp • Only a K2CompoClass requires and provides K2Is • Only a K2I has Operations • A K2ClassTV only represents data • It thus only has Public Attributes • It cannot have neither operations nor nestedClassifiers • For each K2IOpArg of non-primitive type from the Specification Service View there must be a K2ClassTV or a K2Enum in the Specification Type View * K2DerivedClass * DataType K2DType * K2Enum Enumeration * K2EnumLit EnumerationLiteral 1..* K2Specification TypeView K2Attr Property * K2DerivedAttr * K2Asso Association * K2DerivedAsso * K2AssoClass AssociationClass * Generalization K2ClassGen * K2Invar Constraint * K2ConstrExp ExpressionInOCL

43. <<enumeration>> enumType1 enumLit1 ... +attr4:enumType1 ... +attr2:type10[multi18] ... +/attr3:type11[multi19] ... +attr5:type12[multi17] ... +attr1:type9[multi16] ... <<K2ClassTV>> Class1 <<K2ClassTV>> Class2 <<K2ClassTV>> AssoClass1 <<K2ClassTV>> Class4 <<K2ClassTV>> Class3 Property Association Property Constraint Association ExpressionInOCL Association Constraint ExpressionInOCL Enumeration Association EnumerationLiteral Constraint ExpressionInOCL Prototypical Specification Type View Class AssociationClass multi20 Property DataType part1 compos1 Generalization whole1 role1 assoc1 role2 multi21 multi22 multi23 context Class3::attr3 derived OCLExp3 multi24 whole2 multi26 whole3 <<K2Invar>> aggreg2 context Class1 inv:inv2 OCLExp2 multi27 sharedPart3 multi25 /aggreg1 sharedPart1 context aggreg1 derived OCLExp4

44. Profile: Specification Instance View K2SubjCompObjSIV * K2CompObjSIV * K2Specification InstanceView K2ISIV InstanceSpecification * K2UseLinkSIV * K2RealizLinkSIV • The type of a K2CompObjSIV can only be a K2CompoClassSSV • The type of a K2SubjCompObjSIV can only be a K2SubjCompoClassSSV • The type of a K2ISIV can only be a K2ISSV • The type of a K2UseLink can only be a K2Use • Neither a K2CompObjSIV, nor a K2ISIV can have Slots • No direct link can relate two K2CompObjSIV nor two K2ISIV • Only a K2CompObjSIV can be linked to a K2ISIV through either a K2UseLinkSIV or a K2RealizLinkSIV

45. Prototypical Specification Instance View <<K2CompObjSIV>> co2:CC0 <<K2CompObjSIV>> co3:CC0 role7 <<K2UseLink>> role8 <<K2UseLink>> <<K2ISIV>> iis1:I1 <<K2ISIV>> iis2:I1 <<K2RealizLink>> <<K2UseLink>> role6 <<K2ISIV>> iis6:I4 <<K2SubjCompObjSIV>> co1:CC1 InstanceSpecification (Object) <<K2UseLink>> <<K2UseLink>> <<K2UseLink>> InstanceSpecification (Link) InstanceSpecification (Link) role5 role4 role3 InstanceSpecification(of classifier Interface) <<K2ISIV>> iis3:I3 <<K2ISIV>> iis4:I3 <<K2ISIV>> iis5:I3 <<K2RealizLink>> <<K2RealizLink>> <<K2RealizLink>> <<K2RealizLink>> <<K2CompObjSIV>> co6:CC3 <<K2CompObjSIV>> co7:CC4 <<K2CompObjSIV>> co4:CC3 <<K2CompObjSIV>> co5:CC3

46. Profile: Specification Operation View 1..* • K2IOV and only have name to form the context prefix of an OCL expression Interface K2IOV 1..* K2Op Operation 1..* Parameter K2OpArg * K2ClassAsType Class * DataType K2DType • For each read-only, state-change free K2Op of each K2ISSV in the K2SpecificationServiceView there must be a K2OpBody in the K2SpecificationOperationView • For each read-write, state-changing K2Op of each K2ISSV in the K2SpecificationServiceView there must be a K2OpPost in the K2SpecificationOperationView * K2Enum Enumeration * K2OpPre * K2OpPost K2Specification OperationView * K2OpBody Constraint * K2ConstrExp ExpressionInOCL * K2Bool LiteralBoolean * K2Int LiteralInteger * K2Inf LiteralUnlimitedInteger * ExpressionInOCL K2Real * K2Str LiteralString * K2Null LiteralNull * K2EnumLit EnumerationLiteral

47. Class or DataType or Enumeration Parameter Operation Interface Prototypical SpecificationOperation View context I1::op1(dir1 param1:type1[mult1], ... ):type2[mult2] body: OCLExp5 context I2::op2(dir2 param2:type3[mult4], ... ):type4[mult4]) post: OCLExp6 context I3::op3(dir3 param3:type5[mult5], ... ):type6[mult6] pre: OCLExp7 body: OCLExp8 context I4:: op4(dir4 param4:type7[mult7], ... ):type8[mult8]) pre: OCLExp9 post: OCLExp10 context I1::getState():CC1State body: CC1.State Constraint ExpressionInOCL

48. Profile: Specification Actor View 1..* K2Actor Actor For each K2UseCase U of a K2Component C, C must provide an K2Interface I with an K2Operation O that realizes the U 1..* K2UseCase UseCase K2Specification ActorView * K2UCInclude Include 1..* Association K2ActorUCAssoc K2ActorGen Generalization K2UCGen

49. Generalization Generalization Prototypical Specification Actor View UseCase Actor <<K2UseCase>> Uc1 mult24 mult31 <<K2Actor>> Actor1 mult25 Include <<K2UseCase>> Uc2 <<include>> <<include>> <<K2UseCase>> Uc3 <<K2UseCase>> Uc4 <<K2UseCase>> Uc5 mult26 <<K2Actor>> Actor2 mult27 Association mult28 mult29 mult30 <<K2Actor>> Actor3

50. Profile: Specification Life Cycle View 1..* K2Protoc ProtocolStateMachine * K2PseudoState PseudoState * K2PseudoStateKind PseudoStateKindEnumerationLiteral 2..* K2State State * K2FinalState FinalState For each K2CompoClass C w/ a state attribute, there must be a K2Protoc containing all the state-changing K2IOp of C's provided,K2I 1..* K2ProtocTrans ProtocolTransition K2Specification LifeCycleView .* K2StateInvar .* • A K2IPSM only has a name and operations which must be the K2TransOps • It has no attribute K2TransPre Constraint .* K2TransPost 1..* K2IPSM Interface 1..* Operation K2TransOp * ProtocolConformance K2ProtocConform Each K2TransOp of a K2Protoc must be an Operation of the K2SubjCompoClass's provided K2I * ExpressionInOCL K2ConstrExp