02-2 Daniels Tutorial-UML Components

8/3/2019 02-2 Daniels Tutorial-UML Components

1/66

UML Components

John DanielsSyntropy Limited

[email protected]

Syntropy Limited 2001 All rights reserved


2/66

email:[email protected] Syntropy Limited

Agenda

Aspects of a component

A process for component specification

Implications for the UML


3/66


Aspects of a component


4/66


UML

Unified Modeling Language

The UML is a standardised language fordescribing the structure and behaviour ofthings

UML emerged from the world of object-oriented programming

UML has a set of notations, mostly graphical

There are tools that support some parts ofthe UML


5/66


1..*

Interface

realization*

! Specification unit

! Implementation unit

ClassImplementation source0..1

1 Class

*

1

instance

Aspects of an Object

Object

! Execution unit


6/66


Only interoperablewithin the language.Single address space

ObjectPrinciples

ObjectPrinciples

developed within

Typically language neutral.Multiple address spaces.Non-integrated services

DistributedObject

Technology

DistributedObject

Technology

1989-

adopted by

CORBA

DCOM

RMI

Object-orientedProgramming

Object-orientedProgramming

1967-Smalltalk

JavaC++

adopted by

ComponentsComponents

1995-

A way of packagingobject implementationsto ease their use.Integrated services

EJB

COM+/.NET

Evolving

Components in context


7/66


Component standard features

Component Model:

defined set of services that support the software

set of rules that must be obeyed in order to takeadvantage of the services

Simple programming model, no need todesign/know about the infrastructure

Services include:

remote access, transactions, persistent storage, security

typically use services by configuring not programming


8/66


! It conforms to a standard

EnterpriseComponentStandard

!

It has animplementation

for (int i=0;

i


9/66


ComponentSpecification

spec

Interface

realization

1

1..*

*

*

! Specification unit

! Packaging unit

Component

Module

file

1..*1..*

ComponentObject

*

1

instance

! Execution unit

! Implementation unit

ComponentImplementation source

0..11

Component forms

Component

1..*

ClassImplementation

Classsource

Interface

realization0..1

*

1

Object*

1

instance


10/66


ComponentSpec

Interface

Two distinct contracts

Client

Usage contract: a contract between acomponent objects interface and a client

Component

Interface

Realization contract: a contract between

a component specification and a

component


11/66


placeOrder(custNum, prodNum, quan)numOfOrders(custNum): Integer

IOrderMgt

reserveStock(prodNum, quan)availableStock(prodNum): Integer

IProductMgt

Interface specification

We could specify placeOrder( )

like this:

The number of orders for the

customer is increased by one

and a reserveStock message is

sent to the component

supporting the IProductMgt

interface


12/66


The client cares about this - it affects thesubsequent result of numOfOrders( ).

Therefore it is part of the usage contract

The IOrderMgt client does not care aboutthis - but the implementer does.Therefore it is part of the realization

contract

The number of orders for the

customer is increased by one

and a reserveStock message

is sent to the component

supporting the IProductMgt

interface

Separation of specification concerns


13/66



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 supported

interfaces

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 versus Component Specs


14/66


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 a

component specification

ClientA person who writessoftware that uses a

component

The Usage Contract


15/66


InstalledComponent

installed asserver

! Registration unit

1..*1..*

*

1

InstalledModule

copy

! Installation unit

1

*

file

ComponentComponent

Module

1..*1..*

Component deployment


16/66


applicationObject:ComponentObject

instance

docObject:ComponentObject

instance

File / New

C:/../winword.exe:InstalledModule

copy

wordApplication:InstalledComponent

installed as

installed as server

server

wordDocument:InstalledComponent

file

file

wordApplication:Component

winword.exe:ComponentModule

wordDocument:Component

Example - Microsoft Word


17/66


invoiceABC:ComponentObject

instance

c:/../invoice.jar:InstalledModule

copyinstalled as

invoiceBean:InstalledComponent

server

file

invoice.jar:ComponentModule

invoiceBean:

Component

c:/../invoice.java:ComponentImplementationrealization

invoice:ComponentSpec

Example - Enterprise Java Beans


18/66


A process forcomponent specification


19/66


Application Architecture Layers

Service

Data

Presentation

Client

Web Client

Web Server

Application Server

Database Server

ExistingSystem(server)

HTTP

RMI / IIOP / DCOM RMI / IIOP / DCOM

JDBC / ODBC / SQL

Any


20/66


Web Server

Application Server

ComponentObject

ComponentObject

ComponentObject

ComponentObject

Component

Object

A/JSP

ExistingSystem

Application Blueprint

Database


21/66


Service

PresentationUser Interface

User Dialog

System Services

Business Services

Finer-Grain Application Layers

UI LogicWhat the user sees

Dialog Logic (UseCases)

Supports multiple UIsTransient Dialog State

Business transactions

Allows multiple Dialogs(including Batch)Business Integrity State

Sub-transactionsBusiness Instance State

Data


22/66


Management and Development Processes

Management Processes Schedule work and plan deliveries

Allocate resources

Monitor progress

Control risk

Development Processes

Create working software from requirements

Focus on software development artifacts

Described independently of the management process

Defines ordering constraints and dependencies

Organized into Workflows

SpecificationWorkflowBusiness Concept

models

Component specs& architectures

Use Casemodels

Concept model

Use Case model

Component specsComponents

0% 100%% complete


23/66


Specification Provisioning Assembly

Test

Requirements

Deployment

Business

requirements

Business Conceptmodels

Existingassets

Technicalconstraints

Components

Component specs& architectures

Userinterface

Use Casemodels

Assemblies

Testedassemblies

Workflows in the development process

Workflow (c.f. RUP)

Artefact


24/66


RequirementsWorkflow

Problem domainknowledge

Businessrequirements

Develop businessprocesses

Identify Use Cases

Softwareboundarydecisions

Use Cases

Develop BusinessConcept Model

BusinessConceptModel

The Requirements Workflow


25/66


Checkavailability

Makereservation

Take upreservation

Cancelreservation

Amendreservation

[suitableroom]

[else]

customer arrives/

cancel request/

amendmentrequest/

Wait forevent

enquiry/

Process no

show

no show/

Confirmreservation

Notify billing

system

Business process

We want to provide some automatedsupport for managing hotel reservations


26/66


Hotel Chain

Hotel

Clerk

Room

Bill

Payment

ReservationCustomer

Address

1

1..*1

1..*

1..*

11

*

* 0..1

0..1

0..1

1

1

*1

1

0..1

*

*

allocation

contactedHotel

contactAddress

RoomType

1

*

1

*

Business Concept Model


27/66


[suitableroom]

Checkavailability

Make

reservation

Take upreservation

Cancelreservation

Amend

reservation

[else]

customer arrives/

cancel request/

amendmentrequest/

Wait forevent

enquiry/

Process noshow

no show/

Confirmreservation

Notify billingsystem

Identify Use Cases

A use case describes the interaction thatfollows from a single business event. Where

an event triggers a number of process

steps, all the steps form a single use case.


28/66


Reservation system

ReservationMaker

Guest

BillingSystem

ReservationAdministrator

Cancel areservation

Make areservation

Update areservation

Take up areservation

Process no

shows

Add, amend,remove

hotel, room,

customer,etc.

Use Casediagram

Name Make a Reservation


29/66


Name

Initiator

Goal

Make a Reservation

Reservation Maker

Reserve a room at a hotel

Main success scenario1. Reservation Maker asks to make a reservation

2. Reservation Maker selects hotel, dates and room type3. System provides availability and price4. Reservation Maker agrees to proceed5. Reservation Maker provides name and postcode

6. 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

Steps

or

ExtensionPoints

Extensions3. Room Not Available

a) System offers alternative dates and room typesb) Reservation Maker selects from alternatives

6. Customer already on filea) Resume 7

AlternativesUse an informal

Alternativessection if you dontwant to specify the

detail required foran extension

Th S ifi i W kfl


30/66


Provisioning

Specification

Requirements

ComponentIdentification

ComponentInteraction

Component

Specification

The Specification Workflow

C t i th i l


31/66


Service

Presentation

System Services

Business Services

Components in the service layers

Data

BusinessComponent

BusinessComponent

SystemComponent

SystemComponent

System interfacesoperations support usecase steps

Business interfaces

operations support corebusiness logic

C t Id tifi ti


32/66


Component

Identification

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

Id tif S t I t f d ti


33/66


2. Reservation Maker selectshotel, dates and room type

3. System provides availability andprice

7. System makes reservation andgives it a tag

8. System reveals tag toReservation Maker

9. System creates and sends

confirmation by email

Make aReservation

Use case

Usecase

steps

MakeReservation

IMakeReservation

getHotelDetails()getRoomInfo()makeReservation()

Dialoglogic

System

Interface

System interfaces act as facades - they are the point of contact for the UI and other

external agents. They are supported by components in the system services layer.

Start with one interface per use case, then refactor as necessary.

Identify System Interfaces and operations

Use case step operations


34/66


ITakeUpReservation

getReservation()beginStay()

IMakeReservation


Use case step operations

Return a list of hotels and theroom types they have

Return price and availabilitygiven hotel, room type and

dates

Create a reservation given

hotel, room type and dates;return its tag

Return reservation details

given a tag

Given a tag, allocate a roomand notify billing system

Develop the Business Type Model


35/66


Hotel Chain

Hotel

Clerk

Room

Bill

Payment

ReservationCustomer

Address

1

1..*1

1..*

1..*

11

*

* 0..1

0..1

0..1

1

1

*1

1

0..1

*

*

allocation

contactedHotel

contactAddress

RoomType

1

*

1

*

" "

"

""

"

Develop the Business Type Model

Initial Business Type Diagram


36/66


RoomType

name: Stringprice: Currency

Customer

name: StringpostCode: Stringemail: String

1

Hotel

name: String

Roomnumber: StringReservationresRef: Stringdates: DateRange

1..*

11

*

* 0..1*

allocation

1*

1 1..*1

*

BusinessConcept Model

BusinessType Model

Initial Business Type Diagram

Identify Core types


37/66


Identify Core types

Core types represent the primary businessinformation that the system must manage

Each core type will correspond directly to a business

interface A core type has:

a business identifier, usually independent of other identifiers

independent existence no mandatory associations(multiplicity equal 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

Identify business interfaces


38/66


Customer

Hotel

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

Customer

name: String

postCode: Stringemail: String

1

IHotelMgt *

ICustomerMgt

*

Hotel

name: String

Room

number: String

ReservationresRef: Stringdates: DateRange

1..**

* 0..1* allocation

1*

1..*1

*

Responsibility for holdingthis association has been

allocated to IHotelMgtResponsibility for business

types is shown by containment

Identify business interfaces

1

1

1

Component Specifications


39/66



We need to decide what components we want, andwhich interfaces they will support

These are fundamental architectural decisions

Business components: they support the business interfaces

remember: components define the unit of development

and deployment The starting assumption is one component spec

per business interface

CustomerMgr

ICustomerMgt

HotelMgrIHotelMgt

System components


40/66


BillingSystem

IBilling

IBilling

Reservation

System

IMakeReservation

ITakeUpReservation

IHotelMgt

ICustomerMgt

System components

We will define a single system component specthat supports all the use case system interfaces

Alternatives: one component per use case, support system

interfaces on the business components Use a separate component spec for billing system

wrapper

Component architecture


41/66


HotelMgr

IHotelMgt

CustomerMgr

ICustomerMgt

BillingSystem IBilling

Reservation

SystemIMakeReservation

ITakeUpReservation

Component architecture

Minimal component object architecture


42/66


:HotelMgr

IHotelMgt

:CustomerMgr

ICustomerMgt

:BillingSystem IBilling

:Reservation

SystemIMakeReservation

ITakeUpReservation

Minimal component object architecture

Component Interaction


43/66


ComponentInteractionDiscover Business

Operations

RefineComponent Specs& Architecture

BusinessInterfaces

Component Specs& Architecture

SystemInterfaces

RefineInterfaces & Ops


Interfaces

Component Interaction

Operation discovery


44/66


Operation discovery

Uses interaction diagrams (collaborationdiagrams)

The purpose is to discover operations onbusiness interfaces 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


45/66


/IMakeReservation:ReservationSystemgetHotelDetails( )

/IHotelMgt

1:getHotelDetails( )

HotelDetails

id: HotelId

name: StringroomTypes: String [ ]

IMakeReservation


IMakeReservation

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

IHotelMgt

getHotelDetails (in match: String): HotelDetails [ ]

/ICustomerMgt

/IHotelMgt


46/66


/IMakeReservation:ReservationSystem

makeReservation ( )

g

1:getCustomerMatching( )

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

IHotelMgt


getRoomInfo (in res: ReservationDetails, out availability: Boolean, out price: Currency)makeReservation (in res: ReservationDetails, in cus: CustId, out resRef: String): Boolean

g

2:makeReservation( )

CustomerDetails

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

3:notifyCustomer( )

Component Specification


47/66



Interfaces

Specify OperationPre/Post-Conditions

Interfaces

Specify Component-Interface constraints

Define InterfaceInformation Models

BusinessType Model


Component Specs

& Architecture

p p


48/66

Pre- and post-conditions


49/66


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.name

result.postCode = theCust.postCoderesult.email = theCust.email

If the pre-condition is true, the post-condition must be true If the pre-condition is false, the post-condition doesnt

apply

A missing pre-condition is assumed true Pre- and post-conditions can be written in natural language

or in a formal language such as OCL

IHotelMgt


50/66



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: HotelId

name: String

Room

number: String

RoomType

name: Stringavailable(during: DateRange): Booleanprice(on: Date): Currency

stayPrice(for: DateRange): Currency

Customer

id: CustId

Reservation

resRef: String

dates: DateRangeclaimed: Boolean

*

1..*1

1

1

1

0..1

** *

* *

1

allocation

*

:Hotel{id=4}


51/66


: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 ( )


52/66


context IHotelMgt::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 reservation

r.resRef = resRef and-- other attributes matchr.dates = res.dateRange andr.roomType.name = res.roomType and not r.claimed andr.customer.id = cus

Specifying a component (1)


53/66


ReservationSystem

IMakeReservation

IHotelMgt ICustomerMgt

ITakeUpReservation

IBilling

Specification of interfaces offered and used

(part of the realization contract)



54/66


Reservation

System

ICustomerMgt

IHotelMgt

1 {frozen}

IBilling1 {frozen}

1 {frozen}

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

the used interfaces are involved



55/66


Context ReservationSystem

-- between offered interfacesIMakeReservation::hotel = ITakeUpReservation::hotelIMakeReservation::reservation = ITakeUpReservation:: reservationIMakeReservation::customer = ITakeUpReservation::customer

-- between offered interfaces and used interfacesIMakeReservation::hotel = iHotelMgt.hotelIMakeReservation::reservation = iHotelMgt.reservation

IMakeReservation::customer = 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 elements

of offered interfaces and used interfaces that must be maintained.

Interactions as specification?


56/66


Is every implementation of ReservationSystemrequired to invoke getHotelDetails() in this situation?

If so, drawing the collaboration diagram is an act of

specification... If not, then we are using this technique simply as a

way of discovering useful operations

/IMakeReservation:ReservationSystemgetHotelDetails( )

/IHotelMgt

1:getHotelDetails( )



57/66


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 we

drew earlier, for operation discovery,that focus on the component beingspecified.

Each fragment specifies how a

particular operation is to beimplemented in terms of interaction

with other components.

Warning: in some cases this will be

over-specification.

UML diagrams used in the process


58/66


Requirements

Business Concept Model

Use Case Model

Specification

Business Type Model

Interface Specifications


Component Architecture

Interactions

Use CaseDiagrams

Use CaseDiagram

PackageDiagram


Diagrams

InterfaceSpecification

Diagrams

Class

Diagram

ComponentArchitectureDiagram


Diagram ClassDiagram

BusinessType Model

Diagram

InterfaceResponsibility

Diagram

ComponentInteractionDiagrams

Collaboration

Diagram


59/66


Implications for the UML

UML Component (v1.4)


60/66


1

UMLComponent

ModelElement

Node

Classifier

* * * *

Deploymentcharacteristics

UML Glossary: a physical, replaceable part [] thatpackages implementation and [] provides the realization

of a set of interfaces

Structure and Behaviorcharacteristics

Packagecharacteristics

Artifact

*

*

Implementationcharacteristics

ComponentInstance

*

Mapping to UML

C


61/66


Component

Object

Component

Implementation


Component

ComponentModule

InstalledModule

Installed

Component

Interface UML Class

UML Class

UML Component

UML Artifact

UML Artifact

UML Component

UML Component

UML Component

Instance

Concept UML element (1.4)UML stereotype

( )

NB your UML tool might letyou use Interface

Strictly, a Set of Artifact

Realization mappings


62/66


ICustomerMgt

addCustomer()deleteCustomer()getCustomer()

ICustomerMgt

addCustomer()deleteCustomer()

getCustomer()

CustomerMgr

CustomerMgr

Model perspectives


63/66


UML is a language for describing models

What is the purpose of your model?

Models that describe the problem domain

nothing to do with software

Models that specify software

ranging from the whole system to one small part

Models that describe the implementation of software

Problem domain S/W spec Implementation

Typical usage of UML notations


64/66


Use case

Class diagram

Seq/collabdiagram

Activitydiagram

Statechart


informationmodels

businessprocesses

boundary

interactionscomponentstructures

required objectinteractions

object lifecycles

componentstructures

designed objectinteractions

algorithms

object lifecycles

Same name, different purpose


65/66



Customer Customer


Customer


setName (String)

ICustomerMgt

*


Business Type Model,Interface Spec

privateimplementation

design

Want to know more?


66/66


UML Components by John Cheesman andJohn Daniels, Addison-Wesley

http://www.umlcomponents.com

02-2 Daniels Tutorial-UML Components

Documents