1 / 30

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

KobrA: A Model-Driven Component-Based Software Product Line Engineering Methodology. Jacques Robin. 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

elvis
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related