Post on 11-Feb-2016
description
transcript
OntologiesReasoningComponentsAgentsSimulations
KobrA: KobrA: A Model-Driven A Model-Driven
Component-Based Component-Based Software Product Line Software Product Line
Engineering Engineering MethodologyMethodology
Jacques Robin
OutlineOutline
1. KobrA goals2. KobrA principles3. KobrA artifacts4. KobrA process5. KobrA Built-In Contract Testing6. KobrA limitations7. KobrA2 improvement goals8. KobrA2 meta-model9. A UML2 profile for KobrA210.KobrA2 process
KobrA
KobrA GoalsKobrA 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
codethrough model transformation
Model-DrivenEngineering (MDE)
Vision Development activities
oriented around product families
Manage commonalities and variabilities
1
2
3Product-LineEngineering (PLE)
KobrA CharacteristicsKobrA 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 PrinciplesKobrA 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: EncapsulationKobrA 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)
Externalview point
Internalview point
Component
Realization
Specification
KobrA Principles: Creation TreeKobrA Principles: Creation TreeDriven ProcessDriven 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 AssemblyKobrA Component Assembly
creates
imports
A
B C
DE F G
H I1 I2
Client-Server Graph Projected on Creation Tree
KobrA PrinciplesKobrA 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: LocalityKobrA Principles: LocalityRun-time Hierarchy
set of modelsdefines
Traditionalapproaches
Development Time Description
“component of” relationship
KobrA(Principle of Locality)
Separation of ConcernsSeparation of Concerns
Process does not fix whether to move first left, front or down in this cube
Executability
Refinement/Nesting
Specificity
Instantiation
FrameworkEngineering
Implementation
Framework Application
Implementation
KobrA Local Primary ArtifactsKobrA 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(UML statechart diagram)
KobrAComponent
Specification
Realization
KobrA Component Functional KobrA Component Functional SpecificationSpecification
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 There is an exchange rate for the specified currency Result 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 ArtifactsKobrA 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 ArtifactKobrA Local ArtifactConformance RulesConformance Rules
A
B
Consistency relationships
Refinement relationships
Contract relationship
KobrA Local Artifact AssemblyKobrA Local Artifact Assembly
Clientship rules
Clientship +Containment rules
Clientship +Containment rules
Clientship +Containment rules
Containment rules
Cliensthiprules
Clientship rules
Specification of server component must match realization of client component
KobrA Top-Level Artifact:KobrA Top-Level Artifact:Context RealizationContext 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
Structural Model(UML class/object diagrams)
Interaction Model(UML collaboration diagrams)
Activity Model(UML activity diagrams)
Realization
KobrA Recursive ProcessKobrA Recursive Process
SpecificationRealization
Cpt A
Cpt B
Cpt D
Cpt C
ComponentReuse
COTS Component
Interleaves component specification with component realization COTS reused by wrapping them in KobrA specification
constructed by black-box reverse engineering
KobrA: Refinement Process KobrA: Refinement Process Orthogonal to Implementation Orthogonal to Implementation
ProcessProcess 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 CPIM
Cpt A PSM
Cpt B PSM
Cpt CPSM
Cpt ASource Code
Cpt CSource Code
Cpt CSource Code
KobrA Process ActivitiesKobrA Process Activities
Data Activities
Specification
Realization/Specifications
Object-oriented
Data Activities
Specification
Realization/Specifications
Object-oriented
Activities Data
Realization
Realization
Context Realization
Specification
Specification
Specification
SingleComponent
Top-DownRecursive
NestedAssembly
KobrA Specification Process ActivitiesKobrA 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
DataActivities
DataModeling
Business ProcessModeling
Realization
InteractionModeling
UsageModeling
DataActivities
DataModeling
Business ProcessModeling
Realization
InteractionModeling
UsageModeling
Role of Use Cases in KobrARole 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
DataActivities
DataModeling
Business ProcessModeling
Use CaseModeling
DataActivities
DataModeling
Business ProcessModeling
Use CaseModeling
KobrA Process Realization ActivitiesKobrA 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)
Data Activities
StructuralModeling
InteractionModeling
ActivityModeling
Data Activities
StructuralModeling
InteractionModeling
ActivityModeling
KobrA: Product Line ArtifactsKobrA: 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:KobrA PLE:Example of Example of FrameworkFramework
Class Class DiagramDiagram
with with <<variant><<variant>
>>stereotypestereotype
KobrA PLE Framework ArtifactsKobrA 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(UML statechart diagram)
Decision Model(textual)
KobrAFrameworkComponent
Decision Model(textual)
Specification
Realization
KobrA Built-In Contract Testing (BICT)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)KobrA Built-In Contract Testing (BICT)
<<Component>>Client A
<<Component>>Server B
<<Interface>>Client A
<<uses>>
<<Component>>Server B w/ BICT
<<Tester Component>>Tester(A)
<<uses>><<Component>>Client A w/ BICT
<<Testing Interface>>Client A
Limitations of KobrALimitations 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 GoalsKobrA2 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