1
John Daniels - Component-based Design
TOOLS Europe 2000
Component-Based Design:A Complete Worked Example
John DanielsSyntropy Ltd, UK
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
John Daniels - Component-based Design
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
John Daniels - Component-based Design
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
� Requirements Definition
� Component Identification
� Component Interaction
� Component Specification
� Provisioning
4
John Daniels - Component-based Design
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
John Daniels - Component-based Design
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
John Daniels - Component-based Design
Requirements
Business Concept Model
Use Case Model
Specification
Business Type Model
Interface Specifications
Component Specifications
Component Architecture
Interactions
Use Case Diagram
Use CaseDiagrams
Package Diagram
ComponentSpecification
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
John Daniels - Component-based Design
Tutorial Map
� Introduction
� Design Process
� Requirements Definition
� Component Identification
� Component Interaction
� Component Specification
� Provisioning
Requirements Definition
RequirementsDefinition
Problem domainknowledge
Businessrequirements
Develop businessprocesses
Identify Use Cases
Softwareboundarydecisions
Use Cases
Develop BusinessConcept Model
BusinessConceptModel
8
John Daniels - Component-based Design
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
*
Business Concept Model
9
John Daniels - Component-based Design
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
Notify billingsystem
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
Notify billingsystem
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
John Daniels - Component-based Design
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
John Daniels - Component-based Design
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
John Daniels - Component-based Design
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
� Requirements Definition
� Component Identification
� Component Interaction
� Component Specification
� Provisioning
13
John Daniels - Component-based Design
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
ComponentSpecification
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
� 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 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
� 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 Specification� The specification of a unit of
software that describes thebehaviour of a set of objects,and defines a unit ofimplementation and deployment
14
John Daniels - Component-based Design
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
John Daniels - Component-based Design
ComponentSpecification
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
John Daniels - Component-based Design
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
John Daniels - Component-based Design
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 Concept Model
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
John Daniels - Component-based Design
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
John Daniels - Component-based Design
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
name: StringpostCode: Stringemail: String
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
John Daniels - Component-based Design
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
John Daniels - Component-based Design
<<comp spec>>HotelMgr
IHotelMgt
<<comp spec>> CustomerMgr
ICustomerMgt
<<comp spec>>BillingSystem IBilling
<<comp spec>>Reservation
SystemIMakeReservation
ITakeUpReservation
Initial component architecture
Tutorial Map
� Introduction
� Design Process
� Requirements Definition
� Component Identification
� Component Interaction
� Component Specification
� Provisioning
22
John Daniels - Component-based Design
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
John Daniels - Component-based Design
/IMakeReservation:ReservationSystemgetHotelDetails( )
/IHotelMgt
1:getHotelDetails( )
<<interface type>> IMakeReservation
getHotelDetails ( )getRoomInfo ( )makeReservation ( )
<<data type>>HotelDetails
id: HotelIdname: StringroomTypes: String [ ]
<<interface type>>IHotelMgt
getHotelDetails (in match: String): HotelDetails [ ]
getHotelDetails (in match: String): HotelDetails [ ]getRoomInfo ( )makeReservation ( )
/IMakeReservation:ReservationSystemgetRoomInfo ( )
/IHotelMgt
1:getRoomInfo( )
<<interface type>> IMakeReservation
getHotelDetails (in match: String): HotelDetails [ ]getRoomInfo ( )makeReservation ( )
<<data type>>ReservationDetailshotel: HotelIddates: DateRangeroomType: String
<<interface type>>IHotelMgt
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
John Daniels - Component-based Design
/IMakeReservation:ReservationSystem
makeReservation ( )
/ICustomerMgt
1:getCustomerMatching( )
<<interface type>> IMakeReservation
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
<<interface type>>IHotelMgt
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
John Daniels - Component-based Design
/ITakeUpReservation:ReservationSystem
/IHotelMgt
beginStay( )
/IBilling
/ICustomerMgt
<<interface type>>ITakeUpReservation
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)
<<interface type>>IHotelMgt
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
John Daniels - Component-based Design
/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
<<interface type>>ITakeUpReservation
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)
<<interface type>> ICustomerMgt
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
<<interface type>>IHotelMgt
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
John Daniels - Component-based Design
Tutorial Map
� Introduction
� Design Process
� Requirements Definition
� Component Identification
� Component Interaction
� Component Specification
� Provisioning
Component Specification
ComponentSpecification
Interfaces
Specify OperationPre/Post-Conditions
Interfaces
Specify Component-Interface constraints
Define InterfaceInformation Models
BusinessType Model
Component Specs& Architecture
Component Specs& Architecture
28
John Daniels - Component-based Design
<<interface type>>ICustomerMgt
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
John Daniels - Component-based Design
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
<<interface type>>IHotelMgt
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
John Daniels - Component-based Design
: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
John Daniels - Component-based Design
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
<<interface type>>ITakeUpReservation
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
name: StringpostCode: Stringemail: String
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
John Daniels - Component-based Design
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
<<comp spec>>Reservation
System
IMakeReservation
IHotelMgt ICustomerMgt
ITakeUpReservation
IBilling
Specifying a component (1)
Specification of interfaces offered and used(part of the realization contract)
33
John Daniels - Component-based Design
<<comp spec>>Reservation
System
<<interface type>>ICustomerMgt
<<interface type>>IHotelMgt
1 {frozen}
<<interface type>>IBilling1 {frozen}
1 {frozen}
Specifying a component (2)
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
Specifying a component (3)
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
John Daniels - Component-based Design
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)
Specifying a component (4)
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
� Requirements Definition
� Component Identification
� Component Interaction
� Component Specification
� Provisioning
35
John Daniels - Component-based Design
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
<<interface type>> ICustomerMgt
addCustomer()deleteCustomer()getCustomer()
<<comp spec>> CustomerMgr
<<realize>>
CustomerMgr
<<offers>>
<<interface>> ICustomerMgt
addCustomer()deleteCustomer()getCustomer()
<<realize>>
<<realize>>
36
John Daniels - Component-based Design
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
John Daniels - Component-based Design
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
John Daniels - Component-based Design
Want to know more?
� Forthcoming book by John Cheesman and JohnDaniels, Addison-Wesley, October 2000