Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

From Requirements To Components

Download as pdf or txt
Download as pdf or txt
You are on page 1of 13

From Requirements to

Components

John Daniels
Syntropy Limited
john@syntropy.co.uk

Agenda

• System architecture with components


• The Requirements workflow
• The Specification workflow
• Modelling components with UML

email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 1


Application Architecture Layers
Presentation Web Client
HTTP
Client
Web Server
RMI / IIOP / DCOM RMI / IIOP / DCOM

Service
Application Server
Existing
Any
System
(server)
JDBC / ODBC / SQL

Data
Database Server

email:john@syntropy.co.uk Syntropy Limited

Application Blueprint

Web Server
A/JSP Application Server

Component
Object
Component
Object
Component
Object
Component
Presentation focus: Object
Component
How do you design
Object
this part?

Existing
Database System
email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 2


Finer-Grain Application Layers
Presentation UI Logic
What the user sees
User Interface
Dialog Logic (UseCases)
User Dialog Supports multiple UIs
Transient Dialog State

Service
Application

Business transactions
Allows multiple Dialogs
System Services
(including Batch)
Business Integrity State
System

Business Services
Sub-transactions
Business Instance State

Data

email:john@syntropy.co.uk Syntropy Limited

Management and Development Processes


• Management Processes
– Schedule work and plan deliveries
– Allocate resources Concept model
0% % complete 100%

– Monitor progress Use Case model


Component specs
– Control risk Components

• 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

Use Case
models Specification Component specs
Workflow & architectures
Business Concept
models

email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 3


Workflows in the development process
Business
requirements
Existing
Artefact assets
Requirements

Business Concept User


models interface
Technical Components
constraints

Use Case Specification Provisioning Assembly


models

Component specs Assemblies


& architectures

Test

Tested
assemblies
Workflow (c.f. RUP)
Deployment

email:john@syntropy.co.uk Syntropy Limited

The Requirements Workflow

Problem domain Business


knowledge requirements

Requirements
Workflow

Develop Business Develop business


Concept Model processes
Software
boundary
Identify Use Cases decisions

Business Use Cases


Concept
Model

email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 4


Business Concept Model
1
Hotel Chain 1..*
Clerk
1..*
1
Hotel
*
contactedHotel 1
1
* * 1..*
allocation
Customer Reservation Room
1 * * 0..1

1 1 * *
contactAddress 0..1 1

Address RoomType
1
0..1
1
Bill

Payment
0..1

email:john@syntropy.co.uk Syntropy Limited

Identify Use Cases


A use case describes the interaction that follows from a
single business event. Where an event triggers a number
of process steps, all the steps form a single use case.
Take up
reservation

customer arrives/
Wait for
event
enquiry/ [else] cancel request/

Check amendment
availability Cancel
request/
[suitable reservation
room]
Make Amend no show/
reservation reservation

Confirm Process no Notify billing


reservation show system

email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 5


Reservation system

Cancel a
reservation
ReservationMaker
Use Case
Make a diagram
reservation

Update a
Guest reservation

Take up a
reservation

BillingSystem Process no
shows

Add, amend,
remove
hotel, room,
ReservationAdministrator customer,
etc.
email:john@syntropy.co.uk Syntropy Limited

Name Make a Reservation


Initiator Reservation Maker
Goal Reserve a room at a hotel
Steps
Main success scenario
or 1. Reservation Maker asks to make a reservation
Extension 2. Reservation Maker selects hotel, dates and room type
Points 3. System provides availability and price
4. Reservation Maker agrees to proceed
5. Reservation Maker provides name and postcode
6. Reservation Maker provides contact email address
7. System makes reservation and gives it a tag
8. System reveals tag to Reservation Maker
9. System creates and sends confirmation by email

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

6. Customer already on file


email:john@syntropy.co.uk a) Resume 7 Syntropy Limited

© John Daniels 2001 6


The Specification Workflow

Requirements

Specification
Component
Identification

Component
Interaction

Component
Specification

Provisioning

email:john@syntropy.co.uk Syntropy Limited

Component Identification

Business Concept Use Case


Model Model

Component
Develop Business Identification
Type Model
Existing
Interfaces Identify Business Identify System
Interfaces Interfaces & Ops
Existing Architecture
Assets Create Initial Patterns
Comp Specs &
Architecture

Business Business Component System


Type Model Interfaces Specs & Interfaces
Architecture

email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 7


Identify System Interfaces and Operations
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.

Make a Make Dialog


Use case
Reservation Reservation Type

Use identify room requirements <<interface type>>


case system provides price
steps request a reservation IMakeReservation System
Interface
getHotelDetails()
getRoomInfo()
makeReservation()

email:john@syntropy.co.uk Syntropy Limited

Develop the Business Type Model

!
1
Hotel Chain

!
1..*
Clerk
1..*
1

!
Hotel
*
contactedHotel 1
1
* * 1..*
allocation
Customer Reservation Room
1 * * 0..1

1 1 * *
contactAddress 0..1 1

Address

! 0..1
1
RoomType

!
1
Bill

!
Payment
0..1

email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 8


Identify business interfaces
<<type>> 1
<<interface type>> RoomType
1 1..*
IHotelMgt * <<core>>
<<type>>
name: String
Hotel
price(Date): Currency
name: String stayPrice(DateRange): Currency
1 available(DateRange): Boolean
1
1
<<core>>
<<type>> 1 *
1..* <<type>>
Customer *
<<type>> Room
name: String number: String
* Reservation
postCode: String 0..1
resRef: String * allocation
email: String
dates: DateRange
*
*

Responsibility for holding


<<interface type>>
this association has been
ICustomerMgt
allocated to IHotelMgt
Responsibility for business
types is shown by containment

email:john@syntropy.co.uk Syntropy Limited

Component architecture

<<comp spec>>
Reservation IMakeReservation
System
ITakeUpReservation

<<comp spec>>
BillingSystem IBilling

<<comp spec>>
CustomerMgr
ICustomerMgt

<<comp spec>>
HotelMgr
IHotelMgt

email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 9


Minimal component object architecture

<<comp object>>
:Reservation IMakeReservation
System
ITakeUpReservation

<<comp object>>
:BillingSystem IBilling

<<comp object>>
:CustomerMgr
ICustomerMgt

<<comp object>>
:HotelMgr
IHotelMgt

email:john@syntropy.co.uk Syntropy Limited

Component Interaction

Business System Component Specs


Interfaces Interfaces & Architecture

Component
Discover Business Interaction
Operations

Refine Refine
Interfaces & Ops Component Specs
& Architecture

Component Specs
Interfaces
& Architecture

email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 10


/ICustomerMgt /IHotelMgt

makeReservation ( )
1:getCustomerMatching( )
3:notifyCustomer( ) 2:makeReservation( )

<<data type>>
CustomerDetails
/IMakeReservation:ReservationSystem name: String
postCode[0..1]: String
email[0..1]: String

<<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
email:john@syntropy.co.uk Syntropy Limited

Component Specification

Business Component Specs


Type Model Interfaces & Architecture

Component
Define Interface Specification
Information Models

Specify Component-
Specify Operation Interface constraints
Pre/Post-Conditions

Interfaces Component Specs


& Architecture

email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 11


Interface information model

<<interface type>>
ICustomerMgt

getCustomerMatching (in custD: CustomerDetails, out cusId: CustId): Integer


createCustomer(in custD: CustomerDetails, out cusId: CustId): Boolean
getCustomerDetails (in cus: CustId): CustomerDetails
notifyCustomer (in cus: CustId, in msg: String)

*
Defines the set of information assumed to be held by a Customer
component object offering the interface, for the
id: CustId
purposes of specification only.
name: String
postCode: String
Implementations do not have to hold this information email: String
themselves, but they must be able to obtain it.

The model need only be sufficient to explain the effects of


the operations.

The model can be derived from the Business Type Model.


email:john@syntropy.co.uk Syntropy Limited

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 in a formal language such as OCL

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

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

post:
-- the details returned match those held for customer cus
Let theCust = customer->select(c | c.id = cus) in
result.name = theCust.name
result.postCode = theCust.postCode
result.email = theCust.email
email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 12


UML diagrams

Use Case Business


Diagram Concept Model
Requirements Diagram Class
Use Case
Diagrams Business Concept Model
Diagram

Use Case Model


Business
Type Model
Specification
Diagram
Interface
Class Specification Business Type Model
Diagrams Interface
Diagram Responsibility
Interface Specifications
Diagram
Component
Specification Component Specifications
Diagrams
Component Architecture
Component Component
Architecture
Interactions Interaction
Diagram Diagrams

Collaboration
Package Diagram
Diagram
email:john@syntropy.co.uk Syntropy Limited

Want to know more?

• UML Components by John Cheesman and John


Daniels, Addison-Wesley
• http://www.umlcomponents.com

email:john@syntropy.co.uk Syntropy Limited

© John Daniels 2001 13

You might also like