Component-Based Design: A Complete Worked Examplesyntropy.co.uk/papers/CBDtutorial.pdf · Component-Based Design: A Complete Worked Example John ... UML diagrams Concept ... Reservation

1

John Daniels - Component-based Design

TOOLS Europe 2000

Component-Based Design:A Complete Worked Example

John DanielsSyntropy Ltd, UK

[email protected]

Introduction

� Goal: follow a small example from requirementsthrough to code-ready specification

� Component-based: assume that the targettechnology will be COM+, EJB or similar

� Process-centric: follow a well-defined design process

� Specification-oriented: most of the tutorial will beconcerned with specifying the system and itscomponents

� UML: use standard UML to describe thespecifications

2


Tutorial Map

� Introduction

� Design Process

� Requirements Definition

� Component Identification

� Component Interaction

� Component Specification

� Provisioning

Break

ComponentObject

ComponentObject

ComponentObject

ComponentObject

ComponentObject

DatabaseSQL, etc.

HTTP

Active/JavaServerPage

DCOM / IIOP / RMI

ExistingSystem

Blueprint for the systems beingconsidered in this tutorial

COM+ / EJB

3


App

licat

ion

Sys

tem

Business SystemOperations are new transactions.Can be used with a variety of user dialogs or batch.Components correspond to �Business Systems�.No dialog or client related state.

User DialogDialog Logic: corresponds to use cases.Transient state corresponds to the dialog.Can sometimes be used with multiple UIs.

Business Services/EntitiesComponents correspond to �stable� business types or groups.Operations can be combined with others in a transaction.Usually have associated databases.

User InterfaceCreates what the user sees.Handles UI logic.

�client� part

�server� part

System architecture layers

Tutorial Map

� Introduction

� Design Process





� Provisioning

4


Informal, organic,design process

Formal, cyclic,evolutionary,managementprocess

The Design Process

� The designprocess isorganised aroundthe production ofartefacts

� The managementprocess isorganised aroundthe delivery ofworking software

Specification Provisioning Assembly

Test

Requirements

Deployment

Workflows in the design process

Workflow (c.f. RUP)

Businessrequirements

Business Conceptmodels

Existingassets

Technicalconstraints

Components

Component specs& architectures

Userinterface

Use Casemodels

Assemblies

Testedassemblies

Artefact

5


Provisioning

Specification

Requirements

ComponentIdentification

ComponentInteraction

ComponentSpecification

The scope of this tutorial

Requirements

Business Concept Model

Use Case Model

Specification

Business Type Model

Interface Specifications

Component Specifications

Component Architecture

Organising the artefacts in tool packages

6


Requirements


Use Case Model

Specification

Business Type Model

Interface Specifications

Component Specifications

Component Architecture

Interactions

Use Case Diagram

Use CaseDiagrams

Package Diagram


Diagrams

InterfaceSpecification

DiagramsClass Diagram

ComponentArchitecture

Diagram

Class Diagram

BusinessConcept Model

Diagram

BusinessType Model

Diagram

InterfaceResponsibility

Diagram

Collaboration Diagram

ComponentInteractionDiagrams

UML diagrams

Concept modelUse Case modelComponent specsComponents

0% 100%% complete

1st iteration 2nd iter. 3rd iter. 4th iter. 5th iter.

Evolutionary delivery

� All the artefacts evolve at each iteration

� Focus is on delivery to the user

7


Tutorial Map

� Introduction

� Design Process





� Provisioning

Requirements Definition

RequirementsDefinition

Problem domainknowledge

Businessrequirements

Develop businessprocesses

Identify Use Cases

Softwareboundarydecisions

Use Cases

Develop BusinessConcept Model

BusinessConceptModel

8


Checkavailability

Makereservation

Take upreservation

Cancelreservation

Amendreservation

[suitableroom]

[else]

customer arrives/

cancel request/

amendment request/

Wait forevent

enquiry/

Process noshow

no show/

Confirmreservation

Notify billingsystem

Business process

We want to provide some automatedsupport for managing hotel reservations

Hotel Chain

Hotel

1

1..*Clerk

1

1..*

Bill

Payment

0..1

0..1

1

1

*

*contactedHotel

Address

10..1contactAddress

Room1..*

1

* 0..1allocation

1*

ReservationCustomer

1*

*1

RoomType1

*


9


Checkavailability

Makereservation

Take upreservation

Cancelreservation

Amendreservation

Reservation maker

System

[suitableroom]

[else]

Guest

customer arrives/

cancel request/

amendment request/

Wait forevent

enquiry/

Process noshow

no show/

Confirmreservation


Assign responsibilities

amendment request/

[suitableroom]

Checkavailability

Makereservation

Take upreservation

Cancelreservation

Amendreservation

Reservation maker

System

[else]

Guest

customer arrives/

cancel request/

Wait forevent

enquiry/

Process noshow

no show/

Confirmreservation


Identify Use CasesA use case describes the interaction thatfollows from a single business event. Wherean event triggers a number of processsteps, all the steps form a single use case.

10


Reservation system

ReservationMaker

Guest

BillingSystem

ReservationAdministrator

Cancel areservation

Make areservation

Update areservation

Take up areservation

Process noshows

Add, amend,remove

hotel, room,customer,

etc.

Use Casediagram

NameInitiatorGoal

Make a ReservationReservation MakerReserve a room at a hotel

Main success scenario1. Reservation Maker asks to make a reservation2. Reservation Maker selects hotel, dates and room type3. System provides availability and price4. Reservation Maker agrees to proceed5. Reservation Maker provides name and postcode6. Reservation Maker provides contact email address7. System makes reservation and gives it a tag8. System reveals tag to Reservation Maker9. System creates and sends confirmation by email

Extensions3. Room Not Available a) System offers alternative dates and room types b) Reservation Maker selects from alternatives

6. Customer already on file a) Resume 7

Steps

orExtension

Points

AlternativesUse an informal�Alternatives�section if you don�twant to specify thedetail required foran extension

11


Exercise 1

� Complete the use case on the next slide

NameInitiatorGoal

Take up a ReservationGuestClaim a reservation

Main success scenario1. Guest arrives at hotel to claim a room2. Guest provides reservation tag to system3.

Extensions

12


NameInitiatorGoal

Take up a ReservationGuestClaim a reservation

Main success scenario1. Guest arrives at hotel to claim a room2. Guest provides reservation tag to system3. System displays reservation details4. Guest confirms details5. System allocates a room6. System notifies billing system that a stay is starting

Extensions3. Tag not recognised

1. Failetc.

Tutorial Map

� Introduction

� Design Process





� Provisioning

13


ComponentIdentification

Business ConceptModel

Use CaseModel

Identify SystemInterfaces & Ops

Identify BusinessInterfaces

Create InitialComp Specs &Architecture

ExistingAssets

ExistingInterfaces

ArchitecturePatterns

BusinessInterfaces

ComponentSpecs &Architecture

SystemInterfaces

Develop BusinessType Model

BusinessType Model

Component Identification

ComponentImplementation

1

* realization


1

* installation

InstalledComponent

instance*

1

ComponentObject

ComponentInterface

1..* supportedInterface

*

Componentconcepts

� Component Specification� The specification of a unit of

software that describes thebehaviour of a set of objects,and defines a unit ofimplementation and deployment

� Component Interface� A definition of a set of

behaviours that can be offeredby a Component Object

� Component Implementation� A realization of a Component

Specification

� Installed Component� An installed (or deployed) copy

of a Component Implementation

� Component Object� An instance of an Installed

Component. A run-time concept






Specification

� Installed Component� An installed (or deployed) copy

of a Component Implementation






Specification







14


ComponentSpec

Interface

Two distinct contracts

Client<<use>>

Usage contract: a contract between acomponent object�s interface and a client

ComponentImplementation

<<realize>>

Interface

Realization contract: a contract betweena component specification and acomponent implementation

The Realization Contract

Contracts and roles

Specifier (Architect)A person who produces the technical

specification for a system orcomponents within a system

RealizerA person who builds a

component that meets acomponent specification

ClientA person who writessoftware that uses a

component

The Usage Contract

15



ComponentInterface

� Represents the usage contract

� Provides a list of operations

� Defines an underlying logicalinformation model specific tothe interface

� Specifies how operationsaffect or rely on theinformation model

� Describes local effects only

� Represents the realizationcontract

� Provides a list of supportedinterfaces

� Defines the run-time unit

� Defines the relationshipsbetween the information modelsof different interfaces

� Specifies how operations shouldbe implemented in terms ofusage of other interfaces

Interfaces vs Component Specs

User Interface

User Dialog(Use Case Logic)

Business System(Use Case Step Logic)

Business Type(Core Business Logic)

Dialog Types

Business Interfaces

System Interfaces

Mapping the architecture layersto software specifications

16


Make a Reservation

Use case

identify room requirementssystem provides pricerequest a reservation

Usecase

steps

MakeReservation

DialogType

<<interface type>>IMakeReservation System

Interface

Identify System Interfaces and Operations

<<interface type>>ITakeUpReservation

getReservation()beginStay()

<<interface type>>IMakeReservation

getHotelDetails()getRoomInfo()makeReservation()

Use case step operations

Return a list of hotels and theroom types they have

Return price and availabilitygiven hotel, room type anddates

Create a reservation givenhotel, room type and dates;return its tag

Return reservation detailsgiven a tag

Given a tag, allocate a roomand notify billing system

17


Hotel Chain

Hotel

Clerk

Room

Bill

Payment

ReservationCustomer

Address

1

1..*1

1..*

1..*

11*

* 0..1

0..1

0..1

1

1

*1

10..1

*

*

allocation

contactedHotel

contactAddress

RoomType1*

1

*

! !

!! !

Develop the Business Type Model

<<trace>>


Business Type Model

<<type>>RoomType

<<type>>Customer

1

<<type>>Hotel

<<type>>Room<<type>>

Reservation

1..*

11

*

* 0..1*

allocation

1

*

1 1..*1

*

Initial Business Type Diagram

name: StringpostCode: Stringemail: String resRef: String

dates: DateRange

name: String name: Stringprice: Currency

number: String

18


Identify Core types� Core types represent the primary business information

that the system must manage

� Each core type will correspond directly to a businessinterface

� A core type has:� a business identifier, usually independent of other identifiers

� independent existence � no mandatory associations (multiplicityequal to 1), except to a categorizing type

� In our case study:� Customer YES. Has id (name) and no mandatory assocs.

� Hotel YES. Has id (name) and no mandatory assocs.

� Reservation NO. Has mandatory assocs.

� Room NO. Has mandatory assoc to Hotel

� RoomType NO. Has mandatory assoc to Hotel

<<type>>RoomType

name: Stringprice(Date): CurrencystayPrice(DateRange): Currencyavailable(DateRange): Boolean

<<core>>Customer

name: StringpostCode: Stringemail: String

1

<<core>>Hotel

name: String

<<type>>Room

number: String<<type>>

ReservationresRef: Stringdates: DateRange

1..*

11

*

* 0..1*

allocation

1*

1 1..*1

*

{Hotel::room.roomType =Hotel::roomType}

{Reservation::hotel =Reservation::roomType.hotel}

BTM with core types and constraints

19


context RoomType

-- AVAILABILITY RULES

-- a room is available if the number of rooms reserved on all dates-- in the range is less than the number of roomsavailable(dr) = dr.asSet->collect(d | reservation->select(r | r.allocation->isEmpty and

r.dates.includes(d))->size)->max < room->size)

-- can never have more reservations for a date than rooms (no overbooking)Date->forAll(d | reservation->select( r | not r.allocation->isEmpty and

r.dates.includes(d))->size) <= room->size

-- PRICING RULES

-- the price of a room for a stay is the sum of the prices for the days in the staystayPrice(dr) = dr.asSet->collect(d | price(d))->sum

Business rules in the BTM

<<type>>RoomType

name: Stringprice(Date): CurrencystayPrice(DateRange): Currencyavailable(DateRange): Boolean

<<core>>Customer


1

<<interface type>>IHotelMgt

<<interface type>>ICustomerMgt

*

*

<<core>>Hotel

name: String

<<type>>Room

number: String<<type>>

ReservationresRef: Stringdates: DateRange

1..**

* 0..1*

allocation

1*

1..*1

*

Identify business interfaces:The Interface Responsibility Diagram

Responsibility for holdingthis association has beenallocated to IHotelMgt

Responsibility for businesstypes is shown by containment

20


Component Specifications� We need to decide what components we want, and

which interfaces they will support

� These are fundamental architectural decisions

� Business components:� they support the business interfaces

� remember: components define the unit of development anddeployment

� The starting assumption is one component spec perbusiness interface

<<comp spec>> CustomerMgr

ICustomerMgt <<component spec>> HotelMgr

IHotelMgt

<<comp spec>>BillingSystem

IBilling

IBilling

<<comp spec>>Reservation

System

IMakeReservation

ITakeUpReservation

IHotelMgt

ICustomerMgt

System components

� We will define a single system component spec thatsupports all the use case system interfaces� Alternatives: one component per use case, support system

interfaces on the business components

� Separate component spec for billing system wrapper

21


<<comp spec>>HotelMgr

IHotelMgt


ICustomerMgt

<<comp spec>>BillingSystem IBilling


SystemIMakeReservation

ITakeUpReservation

Initial component architecture

Tutorial Map

� Introduction

� Design Process





� Provisioning

22


ComponentInteractionDiscover Business

Operations

RefineComponent Specs& Architecture

BusinessInterfaces

Component Specs& Architecture

SystemInterfaces

RefineInterfaces & Ops

Component Specs& ArchitectureInterfaces

Component Interaction

Operation discovery

� Uses interaction diagrams (collaboration diagrams)

� The purpose is to discover operations on businessinterfaces that must be specified� not all operations will be discovered or specified

� Take each use case step operation in turn:� decide how the component offering it should interact with

components offering the business interfaces

� draw one or more collaboration diagram per operation

� define signatures for all operations

23


/IMakeReservation:ReservationSystemgetHotelDetails( )

/IHotelMgt

1:getHotelDetails( )

<<interface type>> IMakeReservation

getHotelDetails ( )getRoomInfo ( )makeReservation ( )

<<data type>>HotelDetails

id: HotelIdname: StringroomTypes: String [ ]


getHotelDetails (in match: String): HotelDetails [ ]

getHotelDetails (in match: String): HotelDetails [ ]getRoomInfo ( )makeReservation ( )

/IMakeReservation:ReservationSystemgetRoomInfo ( )

/IHotelMgt

1:getRoomInfo( )


getHotelDetails (in match: String): HotelDetails [ ]getRoomInfo ( )makeReservation ( )

<<data type>>ReservationDetailshotel: HotelIddates: DateRangeroomType: String


getHotelDetails (in match: String): HotelDetails [ ]getRoomInfo (in res: ReservationDetails, out availability: Boolean, out price: Currency)

getHotelDetails (in match: String): HotelDetails [ ]getRoomInfo (in res: ReservationDetails, out availability: Boolean, out price: Currency)makeReservation ( )

24


/IMakeReservation:ReservationSystem

makeReservation ( )

/ICustomerMgt

1:getCustomerMatching( )


getHotelDetails (in match: String): HotelDetails [ ]getRoomInfo (in res: ReservationDetails, out availability: Boolean, out price: Currency)makeReservation (in res: ReservationDetails, in cus: CustomerDetails, out resRef: String): Integer


getHotelDetails (in match: String): HotelDetails [ ]getRoomInfo (in res: ReservationDetails, out availability: Boolean, out price: Currency)makeReservation (in res: ReservationDetails, in cus: CustId, out resRef: String): Boolean

/IHotelMgt

2:makeReservation( )

<<data type>>CustomerDetails

name: StringpostCode[0..1]: Stringemail[0..1]: String

3:notifyCustomer( )

Exercise 2

� Specify the interaction for beginStay( )

� Complete the collaboration diagram on the next slide

� Add operations to the interface types on the slideafter

25


/ITakeUpReservation:ReservationSystem

/IHotelMgt

beginStay( )

/IBilling

/ICustomerMgt


beginStay (in resRef: String, out roomNumber: String): Boolean-- result is true if room allocated successfully

<<interface type>>IBilling

<<interface type>> ICustomerMgt

getCustomerMatching (in custD: CustomerDetails, out cusId: CustId): IntegercreateCustomer(in custD: CustomerDetails, out cusId: CustId): BooleannotifyCustomer (in cus: CustId, in msg: String)


getHotelDetails (in match: String): HotelDetails [ ]getRoomInfo (in res: ReservationDetails, out availability: Boolean, out price: Currency)makeReservation (in res: ReservationDetails, in cus: CustId, out resRef: String): Boolean

26


/ITakeUpReservation:ReservationSystem

/IHotelMgt

1.1:getReservation(rr, rd, c) 1.2:beginStay(rr, n)

1:beginStay( )

/IBilling

1.4:openAccount(rd, cd)

/ICustomerMgt

1.3:getCustomerDetails(c): cd


beginStay (in resRef: String, out roomNumber: String): Boolean-- result is true if room allocated successfully

<<interface type>>IBilling

openAccount (in res: ReservationDetails, in cus: CustomerDetails)


getCustomerMatching (in custD: CustomerDetails, out cusId: CustId): IntegercreateCustomer(in custD: CustomerDetails, out cusId: CustId): BooleannotifyCustomer (in cus: CustId, in msg: String)getCustomerDetails (in cus: CustId): CustomerDetails


getHotelDetails (in match: String): HotelDetails [ ]getRoomInfo (in res: ReservationDetails, out availability: Boolean, out price: Currency)makeReservation (in res: ReservationDetails, in cus: CustId, out resRef: String): BooleangetReservation(in resRef: String, out rd ReservationDetails, out cusId: CustId): BooleanbeginStay (resRef: String , out roomNumber: String): Boolean

27


Tutorial Map

� Introduction

� Design Process





� Provisioning

Component Specification


Interfaces

Specify OperationPre/Post-Conditions

Interfaces

Specify Component-Interface constraints

Define InterfaceInformation Models

BusinessType Model



28



getCustomerMatching (in custD: CustomerDetails, out cusId: CustId): IntegercreateCustomer(in custD: CustomerDetails, out cusId: CustId): BooleangetCustomerDetails (in cus: CustId): CustomerDetailsnotifyCustomer (in cus: CustId, in msg: String)

Customer

id: CustIdname: StringpostCode: Stringemail: String

*

Interface information model

Defines the set of information assumed to be held by acomponent object offering the interface, for thepurposes of specification only.

Implementations do not have to hold this informationthemselves, but they must be able to obtain it.

The model need only be sufficient to explain the effects ofthe operations.

The model can be derived from the Business Type Model.

context ICustomerMgt::getCustomerDetails (in cus: CustId): CustomerDetails

pre:-- cus is validcustomer->exists(c | c.id = cus)

post:-- the details returned match those held for customer cusLet theCust = customer->select(c | c.id = cus) inresult.name = theCust.nameresult.postCode = theCust.postCoderesult.email = theCust.email

Pre- and post-conditions

� If the pre-condition is true, the post-condition must be true

� If the pre-condition is false, the post-condition doesn�t apply

� A missing pre-condition is assumed �true�

� Pre- and post-conditions can be written in natural language or ina formal language such as OCL

29


context ICustomerMgt::createCustomer (in custD: CustomerDetails, out cusId: CustId): Boolean

pre:-- post code and email address must be providedcustD.postCode->notEmpty and custD.email->notEmpty

post:result implies

-- new customer (with name not previously known) created(not customer@pre->exists(c | c.name = custD.name)) and(customer - customer@pre)->size = 1 and

Let c = (customer - customer@pre) inc.name = custD.name and c.postCode = custD.postCode andc.email = custD.email and c.id = cusId


getHotelDetails (in match: String): HotelDetails [ ]getRoomInfo (in res: ReservationDetails, out availability: Boolean, out price: Currency)makeReservation (in res: ReservationDetails, in cus: CustId, out resRef: String): BooleangetReservation(in resRef: String, out rd ReservationDetails, out cusId: CustId): BooleanbeginStay (resRef: String , out roomNumber: String): Boolean

Hotel

id: HotelIdname: String

Room

number: String

RoomTypename: Stringavailable(during: DateRange): Booleanprice(on: Date): CurrencystayPrice(for: DateRange): Currency

Customer

id: CustId

Reservation

resRef: Stringdates: DateRangeclaimed: Boolean

*

1..*1

1

11

0..1

** *

* *

1allocation

*

30


:Hotel{id=4}

:RoomType{name=single}

:RoomType{name=double}

:Customer{id=38}

:Reservation{refRef=H51}

before

:Hotel{id=4}

:Reservation{resRef=A77}

:RoomType{name=single}

:RoomType{name=double}

:Customer{id=92}

:Customer{id=38}

:Reservation{refRef=H51}

after

makeReservation ( )

context makeReservation (in res: ReservationDetails, in cus: CustId, out resRef: String): Boolean

pre:-- the hotel id and room type are validhotel->exists(h | h.id = res.hotel and h.room.roomType.name->includes(res.roomType))

post:result implies

-- a reservation was created-- identify the hotelLet h = hotel->select(x | x.id = res.hotel)->asSequence->first in

-- only one more reservation now than before(h.reservation - h.reservation@pre)->size = 1 and-- identify the reservationLet r = (h.reservation - h.reservation@pre)->asSequence->first in

-- return number is number of the new reservationr.resRef = resRef and-- other attributes matchr.dates = res.dateRange andr.roomType.name = res.roomType and not r.claimed andr.customer.id = cus

31


context IHotelMgt::beginStay (in resRef: String, out roomNumber: String): Boolean

pre:-- resRef is validreservation->exists (r | r.resRef = resRef) and-- not already claimednot reservation->exists (r | r.resRef = resRef and r.claimed)

post:Let res = reservation->select (r | r.resRef = resRef) inresult implies

-- the reservation is now claimedres.claimed androomNumber = res.allocation.number-- nb room allocation policy not defined


getReservation (in resRef: String, out rd: ReservationDetails, out cus: CustomerDetails): BooleanbeginStay (in resRef: String, out roomNumber: String): Boolean

Hotel

id: HotelId

Room

number: String

RoomType

name: String

Customer


Reservation

resRef: Stringdates: DateRangeclaimed: Boolean 1..*

11

1

1

0..1

** *

* *

1allocation

*

For system interfaces supporting usecase steps, such asITakeUpReservation, the informationmodel would never be implementedas persistent storage.

The information it represents is heldby business components.

32


context ITakeUpReservation::beginStay (in resRef: String, out roomNumber: String): Boolean

pre:-- resRef is validreservation->exists (r | r.resRef = resRef) and-- not already claimednot reservation->exists (r | r.resRef = resRef and r.claimed)

post:Let res = reservation->select (r | r.resRef = resRef) inresult implies

-- the reservation is now claimedres.claimed androomNumber = res.allocation.number-- nb room allocation policy not defined here


System

IMakeReservation

IHotelMgt ICustomerMgt

ITakeUpReservation

IBilling

Specifying a component (1)

Specification of interfaces offered and used(part of the realization contract)

33



System



1 {frozen}

<<interface type>>IBilling1 {frozen}

1 {frozen}


Specification of the component object architecture.This tells us how many objects offering

the used interfaces are involved

Context ReservationSystem

-- between offered interfacesIMakeReservation::hotel corresponds to ITakeUpReservation::hotelIMakeReservation::reservation corresponds to ITakeUpReservation:: reservationIMakeReservation::customer corresponds to ITakeUpReservation::customer

-- between offered interfaces and used interfacesIMakeReservation::hotel corresponds to iHotelMgt.hotelIMakeReservation::reservation corresponds to iHotelMgt.reservationIMakeReservation::customer corresponds to iCustomerMgt.customer


Specification of the Component Spec-Interface constraints.

The top set of constraints tell the realizer the required relationshipsbetween elements of different offered interfaces.

The bottom set tell the realizer the relationships between elementsof offered interfaces and used interfaces that must be maintained.

34


theComponentBeing Specified/IW: A

1:doIt (a, b)

aComponentSupporting/IX: C

anotherComponent: B

aComponentSupporting/IY

1.1:doIt (a, b)

1.1.1:doIt (a, b)


If we want to provide a more detailedspecification we can use interactiondiagram fragments.

These are pieces of the diagrams wedrew earlier, for operation discovery,that focus on the component beingspecified.

Each fragment specifies how aparticular operation is to beimplemented in terms of interactionwith other components.

Warning: in some cases this will beover-specification.

Tutorial Map

� Introduction

� Design Process





� Provisioning

35


Provisioning

� Target technology

� CORBA Component Model?

Component Standard Platform Dependencies Language Dependencies

Microsoft COM+ Windows 2000 None

Enterprise Java Beans None Java

Realization mappings and restrictions

� Operation parameters

� Error handling

� Interface inheritance and support

� Architecture mappings


addCustomer()deleteCustomer()getCustomer()


<<realize>>

CustomerMgr

<<offers>>

<<interface>> ICustomerMgt

addCustomer()deleteCustomer()getCustomer()

<<realize>>

<<realize>>

36


Operation parameters

� All parameters are either:� passed by value, or

� references to component objects

� In EJB:� All parameters must be �in�

� The parameters must obey RMI rules (base or serializable)

� For COM+:� If using COM automation the parameters must be VBA types

Error handling� COM+ uses standard result structure

� EJB uses Java exceptions� Need to establish a policy:

� exceptions correspond to defined result states, or

� exceptions correspond to undefined results

� If exceptions imply defined states:� use multiple post-conditions (Soundarajan & Fridella, UML99)

context addItem(p: IProduct, quantity: integer): voidpre: quantity >=0post: not orderLine@pre->exists(o | o.product = p) and

(orderLine - orderLine@pre)-> size = 1 and(orderLine - orderLine@pre)->exists(o |

o.product = p and o.quantity = quantity)bi:BadItem.post: orderLine@pre->exists(o | o.product = p) and

bi.originator = self and bi.errorString = �item already in order�

Normal post-condition, noprevious line for this product

Post-condition thatapplies when BadItemexception is raised

37


Interface support and inheritance

� EJB:� each component offers one interface

� interfaces can have multiple inheritance

� therefore: use inheritance to offer multiple interfaces

� beware clashes!

� COM+� each component can offer many interfaces

� interfaces can have single inheritance

Architecture mappings

Dialog Software

System Components

Business Components

<<sessionEJB>>Reservation

System

TX_REQUIRES_NEW makeReservation()

TX_REQUIRED getCustomerMatching()

<<sessionEJB>>CustomerMgr

<<database>>Customer

<<sessionEJB>>Make Reservation

<<sessionEJB>>Reservation

System

<<entityEJB>>Customer

<<database>>Customer

<<sessionEJB>>Make Reservation

The entity beanHome acts asthe manager

38


Want to know more?

� Forthcoming book by John Cheesman and JohnDaniels, Addison-Wesley, October 2000

Documents

Component-Based Design: A Complete Worked Examplesyntropy.co.uk/papers/CBDtutorial.pdf · Component-Based Design: A Complete Worked Example John ... UML diagrams Concept ... Reservation