KobrA: A Model-Driven Component-Based Software Product Line Engineering Methodology

1. KobrA: A Model-Driven Component-Based Software Product Line Engineering Methodology Jacques Robin

2. Outline • KobrA goals • KobrA principles • KobrA artifacts • KobrA process • KobrA Built-In Contract Testing • KobrA limitations • KobrA2 improvement goals • KobrA2 meta-model • A UML2 profile for KobrA2 • KobrA2 process

3. 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

4. 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

5. 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

6. = + 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)

7. 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

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

9. 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)

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

11. 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

12. 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)

13. 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

14. 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

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

16. 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

17. 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

18. 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

19. 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

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

21. 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

22. 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

23. 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)

24. 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

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

26. 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)

27. 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

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

29. 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

30. 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