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

2. What are Software Components?  No standard, universally accepted definition  In essence, any software unit that:  Is “independently” deployable  (albeit) reuses/requires a set of typed and constrained operations (typically provided by other components that its uses at servers)  To provide a set of typed and constrained operations  Executable by either:  Humans through a user interface (stand-alone deployment)  Other software through an calling interface (for which it then acts as a server)  Encapsulates:  Meta-data allowing the deployment platform or development environment to automatically assemble it with other components to provide complex services  Several related classes, routines, or functions

3. Component Diversity Abstraction Level Executability Level > Class PIM Specification > Class PSM Specification Component Communication Protocol Bytecode > Class PIM Realization > Class PSM Realization Component Service Implementation Bytecode : Component Instance PIM Realization : Component Instance PSM Realization Component Assembly Bytecode Component Object Binary Code Component Source Code Interfaces Component Source Code Implementation Component Object Constructor Method Source Code

4. Components vs. objects Component:  Independently deployable  Possesses user-interface for stand-alone deployment  Not necessarily object-oriented  Mid-size grained unit intermediate between objects and systems  At run time subject to service invocation  At deployment time subject to composition/assembly Object:  But be wrapped inside a program to be executed  Only subject to method invocation

5. Component Class vs. Module, Library, Package and API  API:  Ambiguous term, can mean only an interface specification or an interface specification and its implementation  A component class always means the latter  Modules, libraries, packages and APIs:  Not independently deployable  Single unit of compilation  Source code language dependent  Only encapsulates behavior not data  No user interface nor testing interface  No meta-data  Libraries and APIs:  No conceptual generalization relationships  No encapsulating containment relationships  Modules and Packages:  Merely a source code structuring namespaces  No instantiation as run-time entity

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

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

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

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

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

11. KobrA Component Assembly creates imports A B C D E F G H I1I1 I2I2  Client-Server Graph Projected on Creation Tree

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

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

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

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

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

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

18. KobrA Local Artifact Conformance Rules A B Consistency relationships Refinement relationships Contract relationship

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

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

21. KobrA Recursive Process  Interleaves component specification with component realization  COTS reused by wrapping them in KobrA specification constructed by black-box reverse engineering

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

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

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

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

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

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

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

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

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

31. KobrA Built-In Contract Testing (BICT) > Server A > Client B > Server A > Client B w/ BICT > Tester(A) > Server A w/ BICT > Server A

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

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