Upload
hillary-hunt
View
214
Download
0
Tags:
Embed Size (px)
Citation preview
Component-BasedProduct Line Engineeringwith the UML
The KobrA Method
Colin Atkinson, Joachim Bayer, Christian Bunse, Colin Atkinson, Joachim Bayer, Christian Bunse, Erik Kamsties, Oliver Laitenberger, Roland Laqua, Erik Kamsties, Oliver Laitenberger, Roland Laqua, Dirk Muthig, Barbara Paech, Jürgen Wüst, and JDirk Muthig, Barbara Paech, Jürgen Wüst, and Jöörg Zettelrg Zettel
InstitutExperimentellesSoftware Engineering
Fraunhofer
IESE
- 2 -Copyright © KOBRA Group 2000
Industrial Reuse Drivers
Vision
Assemble applications from prefabricated parts
COTS component market
Web Services
Obstacles
Current technologies (.NET, J2EE) very implementation oriented
Little understanding of how to scope components
Vision
Capture core software assets as platform-independent models (PIMs)
Automatically map PIMS to PSMs
Obstacles
Larges upfront investment
Poor connection with regular “single-system” technology
Obstacles
Lack of systematic methods for creating PIMs
Fixed and Ad hoc mapping techniques
Vision
Development activities oriented around product families
manage commonalities and variabilities
KobrA
Component-based Development (CBD)
Model-DrivenArchitecture (MDA)
1
2
3Product-LineEngineering (PLE)
- 3 -Copyright © KOBRA Group 2000
The KobrA Project
Supported by the German Ministry for Research and Technology (BMBF)
KoKomponentenbbasierrte AAnwendungsentwicklung
Four partners
Softlab GMBH, Munich (leaders) PSIPENTA Software Systems, Berlin GMD FIRST, Berlin Fraunhofer IESE, Kaiserslautern
Three year duration
January 1999 -> December 2001
Products
Method, Workbench, Components Copyright © KOBRA Group 2000
1 KobrA Project
2 Questions
3 Properties
4 Existing Methods
Background
5 Influences
6 Characteristics
- 4 -Copyright © KOBRA Group 2000
Properties of a Good Method
Simple
– Minimal set of concepts– No redundancy (different words for the same thing)
Systematic
– Methodological, step-wise process– rigorous
Prescriptive
– Should try to say what you should do not what you may do
Flexible
– Should be useable in as wide a range of circumstances as possible
Scaleable
– Should be applicable in the same way to large and small systems
1 KobrA Project
2 Questions
3 Properties
4 Existing Methods
Background
5 Influences
6 Characteristics
- 5 -Copyright © KOBRA Group 2000
Problems with Existing Methods
Unified Process
– Complicated– Limited view of components– Fundamental conflict between being “use-case
driven” and “architecture centric”
Catalysis
– Complicated– Unfocused
OPEN
– Very high level – unprescriptive
Fusion
– “Flat” and unscaleable
Cleanroom
– Structured (i.e. function-oriented)
1 KobrA Project
2 Questions
3 Properties
4 Existing Methods
Background
5 Influences
6 Characteristics
- 6 -Copyright © KOBRA Group 2000
Methodological Influences on KobrA
Catalysis
Fusion
Cleanroom
Copyright © KOBRA Group 2000
Product LineEngineering(PuLSE)
OPEN
Unified Process
SELECTPerspective
OMT Booch
Objectory
1 KobrA Project
2 Questions
3 Properties
4 Existing Methods
Background
5 Influences
6 Characteristics
- 7 -Copyright © KOBRA Group 2000
Main Characteristics of KobrA
KobrA is a method for software engineering that is - simple systematic prescriptive flexible scaleable component-based (object-oriented) architecture centric iterative and Incremental quality-oriented product line capable UML-based component technology compatible
Copyright © KOBRA Group 2000
1 KobrA Project
2 Questions
3 Properties
4 Existing Methods
Background
5 Influences
6 Characteristics
- 8 -Copyright © KOBRA Group 2000
Modeling Principles
Uniformity
all behavior rich elements should be viewed as components, including (sub)systems
component assembly = component development
Parsimony
minimal set of concepts (no redundancy)
Locality
all models should be local to a component
Encapsulation
component specifications (what) must be separated from component realizations (how)
- 9 -Copyright © KOBRA Group 2000
What is a Component?
There are many different definitions of “component”
The three primary component implementation technologies are -
JavaBeans, COM and CORBA
Common theme -
prepackaged software entities that can be plugged together -
1 Components
2 Locality
3 Specifications &Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 10 -Copyright © KOBRA Group 2000
Traditional Client/Server Model
plugs and sockets represent sets of services
plug => required services
– services which a component needs to do its job
– services of which the component is a client socket => supplied services
– services which a component offers to others
– services for which the component is a server
=> Contract model
interacting components enter into a contract
contract
client server
1 Components
2 Locality
3 Specifications &Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 11 -Copyright © KOBRA Group 2000
Tree-Based Development
In general, the client/server model leads to a network (graph) of interconnected components
BUT, an arbitrary graph has numerous shortcomings
no model of composition no obvious development order
Cleanroom shows that a tree based software structure has many advantages
natural model of composition obvious development sequences recursive definitions and activities systematic improved quality
1 Components
2 Locality
3 Specifications &Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 12 -Copyright © KOBRA Group 2000
A System = A Component
Many approaches view component development and component assembly as different activities
development with components development of components
In KobrA component development and assembly are the same thing
a system = a component
+ =
+ =
1 Components
2 Locality
3 Specifications &Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 13 -Copyright © KOBRA Group 2000
Creation as the basis for Composition
The basic composition concept does not yield a tree
many shades of aggregation an entity can be a component of several things
simultaneously
How can trees be crystallized from client/server graphs?
Solution is the “creation” relationship
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
1 Components
2 Locality
3 Specifications &Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 14 -Copyright © KOBRA Group 2000
creates
imports
Run-time Composition Tree
A
B C
D E F G
H I1 I2
1 Components
2 Locality
3 Specifications &Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 15 -Copyright © KOBRA Group 2000
The Principle of Locality
Run-time composition structures are traditionally described within global models
inhibits reuse non-component oriented
The principle of locality states that -
content and organization of software artifacts should be relative to a single component
Global artifacts
should be used as little as possible should be generated recursively
1 Components
2 Locality
3 Specifications &Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 16 -Copyright © KOBRA Group 2000
Applying the Principle of Locality
Run-time Hierarchy
set of modelsdefines
Traditionalapproaches
Development Time Description
“component of” relationship
1 Components
2 Locality
3 Specifications &Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
KobrA(Principle of Locality)
- 17 -Copyright © KOBRA Group 2000
Internal versus External Views
The properties of a component can be seen from two viewpoint points -
external view
– properties of a component visible from, or controlled by, the “outside”
– in KobrA, described by the specification internal view
– properties of a component visible from the “inside”
– includes the properties visible from outside
– in KobrA, described by the realization
Externalview point
Internalview point
Component
Realization
Specification
1 Components
2 Locality
3 Specifications &Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 18 -Copyright © KOBRA Group 2000
Component Specification
Describes a component’s externally visible properties
Structural Model(UML class/object diagrams)
Functional Model(operation specifications)
Behavior Model(UML statechart diagram)
ComponentSpecification
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 19 -Copyright © KOBRA Group 2000
Component Realization
Describes a component’s realization properties
Structural Model(UML class/object diagrams)
Interaction Model(UML collaboration diagrams)
Activity Model(UML activity diagrams)
ComponentRealization
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 20 -Copyright © KOBRA Group 2000
Component Model Suite
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)
Komponent
Specification
Realization
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 21 -Copyright © KOBRA Group 2000
Framework Correctness Rules
A
B
Consistency relationships
Refinement relationships
Contract relationship
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 22 -Copyright © KOBRA Group 2000
Containment Trees
Clientship rules
Clientship +Containment rules
Clientship +Containment rules
Clientship +Containment rules
Containment rules
Cliensthiprules
Clientship rules
- 23 -Copyright © KOBRA Group 2000
Framework Engineering
SpecificationRealization
Cpt A
Cpt B
Cpt D
Cpt C
ComponentReuse
COTS Component
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 24 -Copyright © KOBRA Group 2000
Context Realization
Represents a description of the environment of the system
can be thought of as a realization without a specification (i.e. a component without a “top”)
involves “front end” activities akin to requirements analysis
Structural Model(UML class/object diagrams)
Interaction Model(UML collaboration diagrams)
Activity Model(UML activity diagrams)
Realization
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 25 -Copyright © KOBRA Group 2000
Implementation and Building
Mapping component realizations into an executable form represents a separate dimension
executable images can be created after each realization
incremental development
Cpt A
Cpt B
Cpt C
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 26 -Copyright © KOBRA Group 2000
Product Line Engineering
Most software development organizations develop a line of similar but slightly different products
KobrA describes a family of similar systems (i.e. components) by modeling
variabilities decisions
A component (class) with (non-empty) decision models (i.e. optional features) is known as a generic component
A tree of generic components represents a generic framework
decision models are related hierarchically decision model resolution implies the resolution of all
lower decision models
=> Incremental introduction of product lines
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 27 -Copyright © KOBRA Group 2000
Generic Component Models
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)
Komponent
Decision Model(textual)
Specification
Realization
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 28 -Copyright © KOBRA Group 2000
High-Level KobrA Life Cycle
Development
Maintenance
FrameworkEngineering
ApplicationEngineering
…
Phase #1
…
Framework Engineering
Application Engineering
Application Engineering
Phase #2
…
Framework Engineering
Application Engineering
Application Engineering
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 29 -Copyright © KOBRA Group 2000
Method Prescriptiveness
FrameworkApplicationImplementationExecutableDeployedSystem
0%
100%
Prescriptiveness
KobrA Method
Othertechnologies1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 30 -Copyright © KOBRA Group 2000
Separation of Concerns
Abstraction
Composition
Specificity
Instantiation
FrameworkEngineering
Implementation
Framework Application
Implementation
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 31 -Copyright © KOBRA Group 2000
Summary of Key Features
Strict separation of concerns– Genericity, composition, abstraction
Strict separation of product and process
Uniform treatment of systems and components– component assembly = component creation– Fractal-like product, Recursive process
Incremental support for product lines– Incremental addition/resolution of decision models
Integrated Quality assurance– Inspections, testing, quality modeling
Flexible Implementation Approach– Separation of refinement and translation– Refinement and translation patterns– Compatible with most implementation technologies
(including JavaBeans, CORBA, COM)
1 Components
2 Locality
3 Specifications & Realizations
4 Frameworks
6 Life Cycle
Overview
5 Product Lines
- 32 -Copyright © KOBRA Group 2000
Single-System versus Product-line Development
An application = a framework with no decisions models (i.e. no variabilities)
Single-system development is a special case of product line engineering with no variabilities– framework engineering + implementation –
variabilities
FrameworkEngineering
ApplicationEngineering
Implementation
Single-System
Product-Line
(no variabilities)
(variabilities)
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 33 -Copyright © KOBRA Group 2000
Primary Framework Engineering Activities
Context Realization produces a set of realization models for the environment
of the system
Component Specification produces a specification of a component in relationship
to a given realization
Component Realization produces a realization of a component in relationship to
a given specification
Component Reuse matches the needs of a given realization to the
capabilities of a preexisting component (I.e. a COTS component) via a mutually agreed specification
Quality Assurance ensure the quality of the KobrA models using
inspections, testing and quality modeling
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 34 -Copyright © KOBRA Group 2000
Simple International Banking System
The Simple International Banking (SIB) System provides very simple banking services to customers.
These fall into two categories,
Creation and management of simple accounts Simple currency exchange calculations
Customers are able to open simple accounts in some denomination, but must do so with a minimum balance of 50 EUR. Once opened, money can be deposited into and withdrawn from an account in any denomination. The current state of the account can also be viewed by Banks Clerks.
The bank maintains a set of exchange rates between Euros and other currencies. Customers can request for amounts in foreign currencies to be converted to and from Euros. Bank Clerks can enter exchange rates at any time.
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 35 -Copyright © KOBRA Group 2000
Context Realization
Starting Point for Development Describes the Context of the Software System Provides Realization Models for the Root
Komponent
Usage
Software
Business
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 36 -Copyright © KOBRA Group 2000
Primary Realization Models (The Output)
Structural model
describes the data and components needed by the component in order to fulfill is 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)
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 37 -Copyright © KOBRA Group 2000
Types of Activities
Any separately identifiable unit of behaviour (functionality) is called an activity in KobrA
Three kinds of activities are recognized
free: a separate chunk of behaviour, charaterized by its input and output
– depicted as an activity diagram without swimlanes associated: an activity assigned to an object, but
not yet identified as an operation
– depicted as an activity diagram with swimlanes operation: an activity that is identified as an
operation of a component
– such an activity is said to be allocated
– depicted by an activity diagram or interaction diagram
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 38 -Copyright © KOBRA Group 2000
Context Realization Activities
DataActivities
DataModeling
Business ProcessModeling
Realization
InteractionModeling
UsageModeling
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 39 -Copyright © KOBRA Group 2000
Context Realization Activities (Continued)
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
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 40 -Copyright © KOBRA Group 2000
SIB Context Structural Model
Bank1
Account
Clerk
Customer
name
IDBalancedenomination*
*
1
**
*
1
Bank Conte
xt
Bank Context Class Diagram
- 41 -Copyright © KOBRA Group 2000
openNewAccount activity diagram
SIB Context Activity Model
DecideStarting Balance
:Customer :Clerk :Bank
Balance 50 EURBalance < 50 EUR
CheckStarting Balance
CreateAccount
DepositBalance
Bank Conte
xt
- 42 -Copyright © KOBRA Group 2000
SIB Context Interaction Model
OpenNewAccount sequence diagram
:Bank:Customer :Clerk
OpenNewAccount (bal, curr, name)
[bal < 50 EUR] InsufficentMessage()[bal 50 EUR]CreateAccount (name, curr) : ID
Deposit (ID, bal, curr)
Bank Conte
xt
- 43 -Copyright © KOBRA Group 2000
The Role of Use Cases
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
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 44 -Copyright © KOBRA Group 2000
Use Cases within Context Realization
DataActivities
DataModeling
Business ProcessModeling
Realization
Use CaseModeling
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 45 -Copyright © KOBRA Group 2000
SIB Use Case Model
OpenNewAccount
Deposit
ViewAccount
SetRate
Withdraw
Convert
Bank
Customer
Clerk
CloseAccount
«uses»
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 46 -Copyright © KOBRA Group 2000
Component Specification
To describe the externally visible properties of a component
Defines a component’s
supplied services (supplied interface) imported services (components) exported services (components)
provides the basis for the contract between the component and its clients
Is defined in the context of the parent component’s realization (or the context realization if the root)
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 47 -Copyright © KOBRA Group 2000
Primary Specification Models
Structural model
data manipulated by the component, its environment, and any externally visible structure
– one or more class diagrams
– zero or more object diagrams
Functional model
computations performed by the component
– one operation specification for each operation
Behavioral model
states exhibited by the component and the events that change them
– zero or more statechart diagrams
– zero or more event maps
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 48 -Copyright © KOBRA Group 2000
Auxiliary Specification 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
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 49 -Copyright © KOBRA Group 2000
Bank Specification Structural Model
createAccount deposit viewAccount withdraw closeAccountsetRateconvertToEuro convertFromEuro
Bank
noOfAccounts : Integer := 0Account
accountID : Stringbalance : FloatDenom : String
manages1 *
Bank
Bank Specification Class Diagram
- 50 -Copyright © KOBRA Group 2000
Bank Specification Functional Model
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
Bank
createAccount Operation Specification
- 51 -Copyright © KOBRA Group 2000
Bank Specification Functional Model (Contd)
Name withdraw
Informal Description
An amount of money in a particular currency is withdrawn from an account.
Constraints --
Receives ID : String currency:String amount:Float
Returns A boolean indicating whether the withdrawal was possible
Changes account with ID = ID
Assumes --
Result If ID or currency are not valid, the operation has been aborted and an exception has been raised. Else if account.balance >= amount, account.balance := account.balance – amount and „true“ has been returned Otherwise „false“ has been returned.
Bank
withdraw operation specification
- 52 -Copyright © KOBRA Group 2000
Bank Specification Behavioral Model
Empty
AccountsButNoRates
RatesButNoAccounts
AccountAandRates
createAccount/deposit/viewAccount/withdraw /closeAccount [noOfAccounts > 2]/
noOfAccounts : Integer
createAccount/deposit/viewAccount/withdraw/closeAccount [noOfAccounts > 2]/setRate/convertToEuro/convertFromEuro/
noOfAccounts : Integer := 0
setRate/convertToEuro/convertFromEuro/
createAccount
setRate
setRate
closeAccount [noOFAccounts = 1 ]
createAccount
closeAccount [noOFAccounts = 1 ]
{crateAccount, deposit, withdraw, viewAccount mustall be in Euro}
Bank
- 53 -Copyright © KOBRA Group 2000
Role of a Component Realization
To describe the way in which a component realizes the services specified in the specification
Defines a component’s
private subcomponents architecture and design
Is defined in the context of the component’s specification
the realization models expand upon the information in the specification models
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 54 -Copyright © KOBRA Group 2000
Primary Realization Models
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)
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 55 -Copyright © KOBRA Group 2000
Auxiliary Realization Artifacts
Quality Measures
Measures of relevant Quality Factors
Dictionary
tables of model entities and their role
Test Suite
Test Cases for Structural Testing
Decision Model
variable features and related user decisions
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 56 -Copyright © KOBRA Group 2000
Auxiliary Realization Artifacts
Quality Measures
Measures of relevant Quality Factors
Dictionary
tables of model entities and their role
Test Suite
Test Cases for Structural Testing
Decision Model
variable features and related user decisions
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 57 -Copyright © KOBRA Group 2000
Role of Realization Activities
Data Activities
StructuralModeling
InteractionModeling
ActivityModeling
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 58 -Copyright © KOBRA Group 2000
The DNA (Data aNd Activity) Model
Data Activities
Specification
Realization/Specifications
Object-oriented
Object-oriented
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 59 -Copyright © KOBRA Group 2000
The DNA Spiral
Activities Data
Realization
Realization
Context Realization
Specification
Specification
Specification
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 60 -Copyright © KOBRA Group 2000
Bank Realization Structural Model
Bank
Converter
1
1
PersistentAccount
1
11 *
*
setRateconvertToEuroconvertFromEuro
createAccountgetAccountcloseAccount
Teller
accesses
creates
Account
depositwithdraw
*
1
Bank
- 61 -Copyright © KOBRA Group 2000
Bank Realization Structural Model (Contd.)
:Bank :Converter:Teller
PersistentAccount
Bank
Bank Realization Object Diagram
- 62 -Copyright © KOBRA Group 2000
Bank Realization Interaction Model
:Bank
:Teller
createAccount (name, curr) : ID
1: createAccount (name, curr) : ID
Bank
createAccount Collaboration Diagram
- 63 -Copyright © KOBRA Group 2000
Bank Realization Interaction Model (Contd)
:Bank
:Converter
withdraw (ID, curr, am) : res
4 : [bal > euro] withdraw (euro) : res
a : PersistentAccount
1: getAccount(ID) : a
:Teller
2: convertToEuro (curr, am) : euro
3 :getBalance() :bal
Bank
withdraw Collaboration Diagram
- 64 -Copyright © KOBRA Group 2000
Bank Realization Activity Model
getAccount
GetBalance evaluateRequest
WidthrawCash returnFalse
returnTrue
:Teller :Account :Bank
Balance RequestBalance < Request
:Converter
ConvertRequest
Bank
- 65 -Copyright © KOBRA Group 2000
SIB Component Hierarchy
Bank
Teller Converter
Association
Account
Dictionary
1
1
*
*
«owns»
«owns»
1
creates
- 66 -Copyright © KOBRA Group 2000
Teller Specification Structural Model
Teller
createAccount getAccount closeAccount
Teller
noOfAccounts : Integer := 0
creates *
PersistentAccount
accountID : Stringbalance : FloatDenom : String
1
Teller Specification Class Diagram
- 67 -Copyright © KOBRA Group 2000
Teller Specification Functional Model
Teller
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 teller
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
createAccount operation specification
- 68 -Copyright © KOBRA Group 2000
Teller Specification Behavioral Model
Teller
Empty
HasAccounts
createAccount/getAccount/closeAccount [noOfAccounts > 2]/
noOfAccounts : Integer := 0
createAccount
closeAccount [noOFAccounts = 1 ]
Teller Statechart diagram
- 69 -Copyright © KOBRA Group 2000
Teller Realization Structural Model
Teller Dictionary
PersistentAccount Object
11
**
Teller
Teller Realization Class Diagram
- 70 -Copyright © KOBRA Group 2000
Teller Realization Interaction Model
Teller
:Teller
:Dictionary
createAccount (name, curr) : ID 2: store (ID, a)
a : PersistentAccount
1: create (name, curr) : ID
createAccount Collaboration Diagram
- 71 -Copyright © KOBRA Group 2000
Dictionary Specification Structural Model
Dictionary
PersistentObject*Store
retrieve remove
Dictionary
noOfEntries : Integer := 0
Dictionary Specification Class Diagram
- 72 -Copyright © KOBRA Group 2000
Dictionary Realization Structural Model
Dictionary
PersistentObject*
Dictionary
Association
Dictionary Realization Class Diagram
- 73 -Copyright © KOBRA Group 2000
Contract View of Component Reuse
KobrA component Specification
(Requirements on Reused Component)
Contract
Consumer
Supplier
KobrA Specification of Reused Component
Conformance Map
ReusedComponent
(Non-KobrA) Specification of Reused Component
1 Main Activities
2 Example
3 ContextRealization
4 Specification
6 ComponentHierarchy
Single SystemDevelopment
5 Realization
7 Reuse
- 74 -Copyright © KOBRA Group 2000
What does KobrA Offer?
KobrA helps answer the following basic questions - What UML models should I build and how should
I organize them? What information should be in the models? How do I start? How can I check that my models are correct or
“good enough”? How can I capture the different variants of my
systems? How can I incorporate my existing software, or
software that I can buy? How should I go about changing my system once
I’ve finished the first version? How do I know what do do next ?
1 Product Families
2 Commonalites &Variabilities
3 Decision Models
4 ApplicationEngineering
6 Refinement vTranslation
Product LineDevelopment
5 Implementation
7 Conclusion
- 75 -Copyright © KOBRA Group 2000
Further Information
Web Pages www.iese.fhg.de/KobrA www.kobra-project.org
Book Atkinson et. al., Component-Based Product Line
Engineering with the UML, Addison-Wesley, 2001
Papers– C. Atkinson, J. Bayer, O. Laitenberger and J. Zettel, Component-
Based Software Engineering: The KobrA Approach, ICSE’200 , Limerick, Ireland. 200
– C. Atkinson, J. Bayer and D. Muthig, "Component-Based Product Line Development: The KobrA Approach," SPLC1, Pittsburgh, August. 2000
Contact Person Dr. Oliver Laitenberger +49 6301 707 223, [email protected]
1 Product Families
2 Commonalites &Variabilities
3 Decision Models
4 ApplicationEngineering
6 Refinement vTranslation
Product LineDevelopment
5 Implementation
7 Conclusion