Transcript KobrA: A Model-Driven Component-Based Software Product Line

KobrA:
A Model-Driven
Component-Based
Software Product Line
Engineering
Methodology
Jacques Robin
Ontologies
Reasoning
Components
Agents
Simulations
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
KobrA Goals







Component-Based
(CBE)
Vision
Engineering
Assemble applications from
prefabricated parts
COTS component market
Web Services
Vision
Development activities
oriented around product
families
Manage commonalities
and variabilities
Product-Line
Engineering (PLE)






Pre-KobrA Obstacles
Current technologies (.NET, J2EE)
exclusively at the code-level
Little understanding of how to
scope components



KobrA
2
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
Model-Driven
Engineering (MDE)
Vision
Capture core software assets as platformindependent models (PIMs)
Automatically map PIMS to PSMs to code
through model transformation
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
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
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
Component
External
view point
Specification
Internal
view point
Realization
 thus component engineering (for reuse) = component assembly (with reuse)
+
=
+
=
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
KobrA Component Assembly
 Client-Server Graph Projected on Creation Tree
A
imports
B
C
D
E
F
G
creates
H
I1
I2
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)
KobrA Principles: Locality
Run-time Hierarchy
Development Time Description
Traditional
approaches
“component of”
relationship
defines set of models
KobrA
(Principle of
Locality)
Separation of Concerns
 Process does not fix whether to move first left, front or down in this cube
Executability
Framework
Framework
Engineering
Instantiation
Applicati
on
Implementation
Specificity
Refinement/Nesting
Implement
ation
KobrA Local Primary Artifacts
Specification
Behavior Model
(UML
statechart diagram)
Functional Model
(Operation specifications)
Structural Model
(UML class/object dia
KobrA
Component
Interaction Model
(UML collaboration diagrams)
Activity Model
(UML activity diagrams)
Structural Model
(UML class/object dia
Realization
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
Name
createAccount
Informal
Description
An account is opened in a particular currency for a customer
with a particular name, and the Account ID is returned
Constraints
--
Receives
name : String
currency:String
Returns
A String with the ID of the account
Changes
bank
Assumes
Result
There is an exchange rate for the specified currency
A new account with a unique ID in the denomination,
currency, has been generated
The name of the customer has been stored in account
The account ID has been returned
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
KobrA Local Artifact
Conformance Rules
Consistency
relationships
A
Contract
relationship
Refinement
relationships
B
KobrA Local Artifact Assembly
 Specification of server
component must match
realization of client
component
Clientship +
Containment rules
Clientship +
Containment rules
Containment rules
Clientship
rules
Cliensthip
rules
Clientship +
Containment rules
Clientship
rules
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





Interaction Model
(UML collaboration diagrams)
Activity Model
(UML activity diagrams)
Structural Model
(UML class/object diagram
Realization
KobrA Recursive Process
 Interleaves component specification with component realization
 COTS reused by wrapping them in KobrA specification constructed
by black-box reverse engineering
Specification
Realization
Cpt A
Component
Reuse
Cpt C
Cpt B
COTS Component
Cpt D
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 A
Source Code
Cpt A PSM
Cpt B PIM
Cpt C
PIM
Cpt B PSM
Cpt C
PSM
Cpt C
Source Code
Cpt C
Source Code
KobrA Process Activities
Context
Realization
Specification
Activities
Data
Specification
Object-oriented
Single
Component
Realization/
Specifications
Top-Down
Recursive
Nested
Assembly
Realization
Specification
Realization
Specification
Activities Data
KobrA Specification Process Activities
 Business process modeling
who does what to what and when
actors, activities, data and rules
described at “business” level of Activities
abstraction
Data
 Data modeling
identify organizational and
technological data
identify information and
material data
 Usage modeling
Business Process
Modeling
Usage
Modeling
Interaction
Modeling
activity modeling
 decompose activities that
involve the “system”
interface design
 screen templates, dialogues etc.
 Interaction modeling
integrate actors, activities,
data and rules
Realization
Data
Modeling
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
 use case = activity associated Modeling
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
Data
Activities
Business Process
Modeling
Data
Modeling
KobrA Process Realization Activities
 Structural model
describes the data and
components needed by the
component in order to fulfill its
contract
Activities
Data
 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)
Activity
Modeling
Structural
Modeling
Interaction
Modeling
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
KobrA PLE:
Example of
Framework
Class Diagram
with
<<variant>>
stereotype
KobrA PLE Framework Artifacts
Decision Model
(textual)
Specification
Behavior Model
(UML
statechart diagram)
Functional Model
operation
( schemata)
Structural Model
(UML class/object dia
KobrA
Framework
Component
Structural Model
(UML class/object dia
Interaction Model
(UML collaboration diagrams)
Activity Model
(UML activity diagrams)
Decision Model
(textual)
Realization
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
KobrA Built-In Contract Testing (BICT)
<<Component>>
Client A
<<Interface>>
Client A
<<uses>>
<<Component>>
Server B
<<Component>>
Server B w/ BICT
<<Component>>
Client A w/ BICT
<<Testing Interface>>
Client A
<<uses>>
<<Tester Component>>
Tester(A)
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
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