Component-Based Product Line Engineering with the UML The KobrA Method Colin Atkinson, Joachim...

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)


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


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


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


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


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


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)


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


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


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


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


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


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


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


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


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


creates

imports

Run-time Composition Tree

A

B C

D E F G

H I1 I2

1 Components

2 Locality


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


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


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


Applying the Principle of Locality

Run-time Hierarchy

set of modelsdefines

Traditionalapproaches

Development Time Description

“component of” relationship

1 Components

2 Locality


4 Frameworks

6 Life Cycle

Overview

5 Product Lines

KobrA(Principle of Locality)


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


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


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


Component Realization

Describes a component’s realization properties


Interaction Model(UML collaboration diagrams)

Activity Model(UML activity diagrams)

ComponentRealization

1 Components

2 Locality


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


Component Model Suite


Functional Model(operation specifications)





Komponent

Specification

Realization

1 Components

2 Locality


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


Framework Correctness Rules

A

B

Consistency relationships

Refinement relationships

Contract relationship

1 Components

2 Locality


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


Containment Trees

Clientship rules

Clientship +Containment rules



Containment rules

Cliensthiprules

Clientship rules


Framework Engineering

SpecificationRealization

Cpt A

Cpt B

Cpt D

Cpt C

ComponentReuse

COTS Component

1 Components

2 Locality


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


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




Realization

1 Components

2 Locality


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


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


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


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


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


Generic Component Models


Functional Model(operation schemata)





Decision Model(textual)

Komponent

Decision Model(textual)

Specification

Realization

1 Components

2 Locality


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


High-Level KobrA Life Cycle

Development

Maintenance

FrameworkEngineering

ApplicationEngineering

…

Phase #1

…


Application Engineering


Phase #2

…




1 Components

2 Locality


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


Method Prescriptiveness

FrameworkApplicationImplementationExecutableDeployedSystem

0%

100%

Prescriptiveness

KobrA Method

Othertechnologies1 Components

2 Locality


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


Separation of Concerns

Abstraction

Composition

Specificity

Instantiation


Implementation

Framework Application

Implementation

1 Components

2 Locality


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


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


4 Frameworks

6 Life Cycle

Overview

5 Product Lines


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


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


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


4 Specification



5 Realization

7 Reuse


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


4 Specification



5 Realization

7 Reuse


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


4 Specification



5 Realization

7 Reuse


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


4 Specification



5 Realization

7 Reuse


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


4 Specification



5 Realization

7 Reuse


Context Realization Activities

DataActivities

DataModeling

Business ProcessModeling

Realization

InteractionModeling

UsageModeling

1 Main Activities

2 Example


4 Specification



5 Realization

7 Reuse


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


4 Specification



5 Realization

7 Reuse


SIB Context Structural Model

Bank1

Account

Clerk

Customer

name

IDBalancedenomination*

*

1

**

*

1

Bank Conte

xt

Bank Context Class Diagram


openNewAccount activity diagram

SIB Context Activity Model

DecideStarting Balance

:Customer :Clerk :Bank

Balance 50 EURBalance < 50 EUR

CheckStarting Balance

CreateAccount

DepositBalance

Bank Conte

xt


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


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


4 Specification



5 Realization

7 Reuse


Use Cases within Context Realization

DataActivities

DataModeling

Business ProcessModeling

Realization

Use CaseModeling

1 Main Activities

2 Example


4 Specification



5 Realization

7 Reuse


SIB Use Case Model

OpenNewAccount

Deposit

ViewAccount

SetRate

Withdraw

Convert

Bank

Customer

Clerk

CloseAccount

«uses»

1 Main Activities

2 Example


4 Specification



5 Realization

7 Reuse


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


4 Specification



5 Realization

7 Reuse


Primary Specification Models

Structural model

data manipulated by the component, its environment, and any externally visible structure



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


4 Specification



5 Realization

7 Reuse


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


4 Specification



5 Realization

7 Reuse


Bank Specification Structural Model

createAccount deposit viewAccount withdraw closeAccountsetRateconvertToEuro convertFromEuro

Bank

noOfAccounts : Integer := 0Account

accountID : Stringbalance : FloatDenom : String

manages1 *

Bank

Bank Specification Class Diagram


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


Bank Specification Functional Model (Contd)

Name withdraw


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


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


{crateAccount, deposit, withdraw, viewAccount mustall be in Euro}

Bank


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


4 Specification



5 Realization

7 Reuse


Primary Realization Models

Structural model

describes the data and components needed by the component in order to fulfill its contract



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


4 Specification



5 Realization

7 Reuse


Auxiliary Realization Artifacts

Quality Measures

Measures of relevant Quality Factors

Dictionary


Test Suite

Test Cases for Structural Testing

Decision Model


1 Main Activities

2 Example


4 Specification



5 Realization

7 Reuse


Role of Realization Activities

Data Activities

StructuralModeling

InteractionModeling

ActivityModeling

1 Main Activities

2 Example


4 Specification



5 Realization

7 Reuse


The DNA (Data aNd Activity) Model

Data Activities

Specification

Realization/Specifications

Object-oriented

Object-oriented

1 Main Activities

2 Example


4 Specification



5 Realization

7 Reuse


The DNA Spiral

Activities Data

Realization

Realization

Context Realization

Specification

Specification

Specification

1 Main Activities

2 Example


4 Specification



5 Realization

7 Reuse


Bank Realization Structural Model

Bank

Converter

1

1

PersistentAccount

1

11 *

*

setRateconvertToEuroconvertFromEuro

createAccountgetAccountcloseAccount

Teller

accesses

creates

Account

depositwithdraw

*

1

Bank


Bank Realization Structural Model (Contd.)

:Bank :Converter:Teller

PersistentAccount

Bank

Bank Realization Object Diagram


Bank Realization Interaction Model

:Bank

:Teller

createAccount (name, curr) : ID

1: createAccount (name, curr) : ID

Bank

createAccount Collaboration Diagram


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


Bank Realization Activity Model

getAccount

GetBalance evaluateRequest

WidthrawCash returnFalse

returnTrue

:Teller :Account :Bank

Balance RequestBalance < Request

:Converter

ConvertRequest

Bank


SIB Component Hierarchy

Bank

Teller Converter

Association

Account

Dictionary

1

1

*

*

«owns»

«owns»

1

creates


Teller Specification Structural Model

Teller

createAccount getAccount closeAccount

Teller


creates *

PersistentAccount

accountID : Stringbalance : FloatDenom : String

1

Teller Specification Class Diagram


Teller Specification Functional Model

Teller

Name createAccount


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


Teller Specification Behavioral Model

Teller

Empty

HasAccounts

createAccount/getAccount/closeAccount [noOfAccounts > 2]/


createAccount


Teller Statechart diagram


Teller Realization Structural Model

Teller Dictionary

PersistentAccount Object

11

**

Teller

Teller Realization Class Diagram


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


Dictionary Specification Structural Model

Dictionary

PersistentObject*Store

retrieve remove

Dictionary

noOfEntries : Integer := 0

Dictionary Specification Class Diagram


Dictionary Realization Structural Model

Dictionary

PersistentObject*

Dictionary

Association

Dictionary Realization Class Diagram


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


4 Specification



5 Realization

7 Reuse


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


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

Component-Based Product Line Engineering with the UML The KobrA Method Colin Atkinson, Joachim...

Documents

Transcript of Component-Based Product Line Engineering with the UML The KobrA Method Colin Atkinson, Joachim...