1. Ontologies Reasoning Components Agents Simulations KobrA: A Model-Driven Component-Based Software Product Line Engineering Methodology Jacques Robin

2. Outline 1.KobrA goals 2.KobrA principles 3.KobrA artifacts 4.KobrA process 5.KobrA Built-In Contract Testing 6.KobrA limitations 7.KobrA2 improvement goals 8.KobrA2 meta-model 9.A UML2 profile for KobrA2 10.KobrA2 process

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

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. 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) External view point Internal view point Component Realization Specification

7. KobrA Principles: 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:  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 creates imports A B C D E F G H I1I1 I2I2  Client-Server Graph Projected on Creation Tree

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 set of models defines Traditional approaches Development Time Description “component of” relationship KobrA (Principle of Locality)

11. Separation of Concerns  Process does not fix whether to move first left, front or down in this cube Executability Refinement/Nesting Specificity Instantiation Framework Engineering Implementation Framework Applicati on Implement ation

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

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 Artifact Conformance Rules A B Consistency relationships Refinement relationships Contract relationship

16. KobrA Local Artifact Assembly  Specification of server component must match realization of client component

17. 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. KobrA Recursive Process  Interleaves component specification with component realization  COTS reused by wrapping them in KobrA specification constructed by black-box reverse engineering

19. 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 Cpt A PIM Cpt B PIM Cpt C PIM Cpt A PSM Cpt B PSM Cpt C PSM Cpt A Source Code Cpt C Source Code Cpt C Source Code

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

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  Usage modeling  activity modeling  decompose activities that involve the “system”  interface design  screen templates, dialogues etc.  Interaction modeling  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  > stereotype in framework component model elements not general to all products  Decision model:  Maps characteristics of product to > stereotyped model elements to include in corresponding product  Table with predefined fields filled with natural language

25. KobrA PLE: Example of Framework Class Diagram with > stereotype

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

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. KobrA Built-In Contract Testing (BICT) > Client A > Server B > Client A > Server B w/ BICT > Tester(A) > Client A w/ BICT > Client A

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