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

1
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 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 OMGs 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)

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
I1
I2
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
set of models
defines
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

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
KobrA Local Artifact Assembly

• Specification of server component must match
  realization of client component

17
KobrA Top-Level ArtifactContext Realization

• Corresponds to
• CIM in MDE,
• Domain model in domain engineering
• Business model in early requirement engineering
• KobrAs 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

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
• Usage modeling
• activity modeling
• decompose activities thatinvolve 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
• ltltvariantgtgt stereotype in framework component
  model elements not general to all products
• Decision model
• Maps characteristics of product to ltltvariantgtgt
  stereotyped model elements to include in
  corresponding product
• Table with predefined fields filled with natural
  language

25
KobrA PLEExample of FrameworkClass
Diagramwith ltltvariantgtgtstereotype
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 activity diagrams)
Decision Model
Realization
(textual)
27
KobrA Built-In Contract Testing (BICT)

• KobrAs 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)
ltltusesgtgt
ltltComponentgtgt Client A
ltltComponentgtgt Server B
ltltInterfacegtgt 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