1 topics discovering business operations maintaining referential integrity completing the picture...

1

TopicsTopics

• Discovering Business Operations

• Maintaining Referential Integrity

• Completing the Picture

• Refining the Interfaces

• Module Summary

• Hands-on: Component Interaction

2

Component Interaction StageComponent Interaction Stage

• Purpose• Define the interactions that need to take place inside the

system• Refine existing interface definitions• Understand interface dependencies• Discover new interfaces and operations

• Input• Business & System Interfaces• Component Specifications & Architecture

• Output• Interfaces• Refined Component Specifications & Architecture

• Activities• Discover Business Operations• Refine Interfaces and Specify Operation Signatures• Refine Component Specifications and Architecture

Provisioning

Specification

Requirements

Assembly

RequirementDefinition

Deployment

ComponentIdentification

ComponentInteraction

ComponentSpecification

BusinessProcesses

3

Activities in Component InteractionActivities in Component Interaction

Provisioning

Specification

Requirements

Assembly

RequirementDefinition

Deployment

ComponentIdentification

ComponentInteraction

ComponentSpecification

BusinessProcesses

Component Interaction

Interfaces

Discover Business Operations

RefineComponent Specs

& Architecture

Component Specs & Architecture

System Interfaces

RefineInterfaces & Ops

Component Specs & Architecture

BusinessInterfaces

4

Discovering Business OperationsDiscovering Business Operations

• Purpose• Discover operations on business interfaces that must be specified.

• Not all operations will be discovered or specified.

• Check the dependencies in the component architecture.

• Representation• Interaction Diagrams

• Input• System and Business Interfaces

• Output• Interface Interaction Model• Business Operations with its Signatures

• Modeling Techniques• 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.

5

Interaction Modeling Quick GuideInteraction Modeling Quick Guide

• Break use cases into use case steps.

• Map the use case steps to their responsible types or interfaces.

• Look for existing interfaces that can supply the required behavior.

• Use collaboration diagrams to help to further factor responsibilities to interfaces.

• Apply viewpoint analysis to the interfaces, depending on level of desired resuability.

• Use sequence diagrams to help to explore the detailed machanics of interaction between interfaces.

6

Review: Interaction DiagramReview: Interaction Diagram

• System level interaction diagram for Make a Reservation

Reservation Maker

Make

Reservation

IMake

Reservation

1: Asks to make a reservation

4: Provides price information

5: Request a reservation

7: Reveal reservation tag

6: makeReservation()

2: getHotelDetails()

3: getRoomInfo()

7

Simple Interactions: getHotelDetails()Simple Interactions: getHotelDetails()

• Intent• Provide a list of hotels from which the user can choose.

• Input• A string to be used as a partial match against the hotel name.

• Output• A list of hotel names, a unique hotel identifier for each hotel and a list of the

types of room each hotel has.

• Signature• IMakeReservation::getHotelDetails(inMatch: String): HotelDetails[]

• Structured data type for hotel details<<data type>>

HotelDetails

id: HotelId

name: String

roomType: String[]

8

Simple Interactions: getRoomInfo()Simple Interactions: getRoomInfo()

• Intent• Provide a room information to stay at a hotel from the starting date to the

ending date.

• Input• Hotel identifier, the dates for the proposed stay, and the required room type.

• Output• Availability and price.

• Signature• IMakeReservation::getRoomInfo(inRes: ReservationDetails, outAvailability:

Boolean, outPrice: Currency)

• Structured data type for reservation details<<data type>>

ReservationDetails

hotel: HotelId

dates: DateRange

roomType: String

9

Breaking Dependencies: makeReservation()Breaking Dependencies: makeReservation()

• Intent• Create the reservation and notify the customer by e-mail.

• Input• The required reservation and customer information.

• Output• A tag or reference number for the newly created reservation.

• Signature• IMakeReservation::makeReservation(inRes: ReservationDetails, inCus:

CustomerDetails, outResRef: String): Integer

• Structured data type for Reservation Details and Customer Details<<data type>>

ReservationDetails

hotel: HotelId

dates: DateRange

roomType: String

<<data type>>

CustomerDetails

name: String

postCode[0..1]: String

email[0..1]: String

10

Breaking Dependencies: makeReservation()Breaking Dependencies: makeReservation()

• Dependencies• ICustomerMgt::getCustomerMatching(inCusD: CustomerDeatils, outCusId:

CustId): Integer• IHotelMgt::makeReservation(inRes: ReservationDetails, inCus: CustId,

outResRef: String): Boolean• ICustomerMgt::notifyCustomer(inCus: CustId, inMsg: String)

<<comp spec>>

Reservation

System

<<comp spec>>

BillingSystem

<<comp spec>>

CustomerMgr

<<comp spec>>

HotelMgr

IMakeReservation

ITakeUpReservation

IBilling

ICustomerMgt

IHotelMgt

++

11

Refined: Interaction DiagramRefined: Interaction Diagram

• Make a Reservation – existing customer, happy day scenario.

Reservation Maker

Make

Reservation

IMake

Reservation

1: Asks to make a reservation

4: Provides price information

5: Request a reservation

7: Reveal reservation tag

6: makeReservation(r, c, rr)

2: getHotelDetails(s)

3: getRoomInfo(r, a, p)

IHotelMgt

2.1: getHotelDetails(s)

3.1: getRoomInfo(r, a, p)

ICustomerMgt

6.1: getCustomerMatching(c, id)

6.2: makeReservation(r, id, rr)

6.3: notifyCustomer(id, s)

++

12

Interaction Pattern vs. Architectural PatternInteraction Pattern vs. Architectural Pattern

Fork structure Stair structure

Hierarchical architecture Network architecture

13

Package Structure: Refined Interaction ModelPackage Structure: Refined Interaction Model

Specification

Business Type Model

Interface Specifications

Component Specifications

Component Architecture

Interactions

System Interfaces

Business Interfaces

Collaboration for Cancel a reservation

...

Create a Collaboration Package under the Interactions package. Each collaboration contains one or more Interactions with the same name as the use case

Create Business Operations in its Interfaces Specification

ICustomerMgt

IHotelMgt

14

Maintaining Referential IntegrityMaintaining Referential Integrity

• Component Specification Architecture• we know that certain kinds of component will exists.

• we don’t know how many component objects of each kind will have at runtime.

• Assumption – Two CustomerMgr component objects, each with its own set of customers, and no guarantee of globally unique customer identities.

• If the ReservationSystem skipped between use of these two, confusion would reign.

• So, we will need to say clearly that the ReservationSystem will always use the same business component objects.

<<comp spec>>

Reservation

System

<<interface type>>

ICustomerMgt

<<interface type>>

IHotelMgt

<<interface type>>

IBilling

1 {frozen}

1 {frozen}

1 {frozen}

15

Maintaining Referential Integrity – Cont’dMaintaining Referential Integrity – Cont’d

• There are a number of mechanisms to control the intercomponent references.

• These can also be used in combinations.1.Responsibility can be allocated to the component object storing the reference.

2.Responsibility can be allocated to the component object that owns the target of the reference.

3.Responsibility can be given to a third component object.

4.Permit, and tolerate, references to become invalid.• Usually higher up the call chain.

5.Disallow the deletion of information.

Op3. It assumes that the CustomerMgr component object is exclusive to ReservationSystem and not shared any other system.

Op2. It is going to be more complicated because any component object holding a customer identity will have to notify the CustomerMgr component objects, which is going to have to keep a list of these dependent and notify them when deleting a customer

16

Example: Maintaining Referential Integrity Op3.Example: Maintaining Referential Integrity Op3.

• Delete Customer

Housekeeping/IHousekeeping

:ReservationSystem

/IHotelMgt

:HotelMgrt

/ICustomerMgt

:CustomerMgr

1: deleteCustomer(cd)

1.1: getCustomerMatching(cd, cid)

1.2: deleteReservationsFor(cid)

1.3: deleteCustomer(cid)

deleteCustomer(cid)++

17

Completing the PictureCompleting the Picture

<<interface type>> ICustomerMgt

getCustomerMatching (inCustD: CustomerDetails, outCusId: CustId): IntegercreateCustomer(inCustD: CustomerDetails, outCusId: CustId): BooleannotifyCustomer(inCus: CustId, inMsg: String)

<<interface type>>IHotelMgt

getHotelDetails(inMatch: String): HotelDetails[]getRoomInfo(inRes: ReservationDetails, outAvailability: Boolean, outPrice: Currency)makeReservation(inRes: ReservationDetails, inCus: CustId, outResRef: String): Boolean

<<interface type>> IMakeReservation

getHotelDetails(inMatch: String): HotelDetails[]getRoomInfo(inRes: ReservationDetails, outAvailability: Boolean, outPrice: Currency)makeReservation(inRes: ReservationDetails, inCus: CustomerDetails, outResRef: String): Integer

18

Auxiliary OperationsAuxiliary Operations

• Basic operations comes from the assigned joint actions.

• As well as from various sources• Problem statement or requirements documentation

• Domain experts or real world knowledge

• Architectural design decisions

• Integration of the models

19

Auxiliary Operations – Cont’dAuxiliary Operations – Cont’d

• Derive auxiliary operations to complement basic operations

• Derived operations may be:• Necessary for proper system functionality

• Important for internal or external reuse

• Helpful in testing

• They include:• Inverse operations

• Recovery operations

• Extended operations

20


• Inverse operations:• Have an effect opposite from that of another operation

• Occur in pairs

• Examples: move up/move down, add/delete

• Recovery operations:• Provide the capability to recover to a previous state

• Examples: undo, rollback

• Extended operations:• Provide extensions of an operation

• May include additional parameters for intermediate values, extrapolation, iteration, or special cases

• Examples: page up(no of pages), delete(all)

21


• By parameterization, simplify identified operations• Parameterization ~ The elimination of the lowest levels (leaf nodes) of an

event, operation, or message generalization hierarchy by treating the discriminator as a parameter (e.g., attribute or argument)

• For example, two operations, named Up() and Down(), can be reduced into one operation, named Move(dir:{up, down})

22

Refining the InterfacesRefining the Interfaces

• Purpose• Refine existing interface specifications.

• Representation• Interface Specification Type

• Interaction Diagrams

• Input• System and Business Interfaces

• Output• Refined Interface Specification

• Modeling Techniques• Minimization of calls.

• Avoid cyclic dependencies.

• Normalization of operations and interfaces.

• Using existing design patterns.

23

Considerations when making ChangesConsiderations when making Changes

• Minimize the operation calls,

• Avoid cyclic dependencies,

• Use the existing design patterns,

• Handling the Cross-Component Referential Integrity,

• Worry about normalization of operations and interfaces,

• And so on.

How do you eat an elephant?

One bite at a time!

24

Factoring Interfaces and OperationsFactoring Interfaces and Operations

• Factoring interface• partition its responsibilities among two or more interfaces.

• Take care over generalization.• Several clear operations are better than only one operation with confusing semantics

and many optional parameters.

• You should also seek to design for today.• Don’t try to anticipate future requirements.

• Much of the flexibility in component-based system design comes from the fact that components may offer multiple interfaces.

• When new requirements appear, support can be provided by adding on new interfaces.

op(p1, p2, p3)op2(p2)

op3(p3)

op1(p1)

Less complex code Less operation call

25

Module SummaryModule Summary

• Develop interaction models for each system interface operation.

• Discover business interface operations and their signatures.

• Refine responsibilities as you go.

• Define any component object architecture constraint you need.

• Factor interfaces as appropriate.

26

Lab 06: Component InteractionLab 06: Component Interaction

Business Type

Modeling

Interface Responsibility

Modeling

Component Architecture

Modeling

Business Concept

Modeling

Use Case

Modeling

Use Case Step

Modeling

Interface Interaction

Modeling

Interface Information

Modeling

Writing

Pre/Postcondition

Completing

Component Specification

RequirementRequirement

SpecificationSpecification

Object ModelingObject Modeling Behavior ModelingBehavior Modeling

27

Sample Solution: Discovering Business Op.Sample Solution: Discovering Business Op.

• IRecordReservation::listVehicleTypes()

Record

InternetReservationIRecordReservation

1: listVehicleTypes(pickupCountry: String, pickupAddress:String): VehicleType[]

IVehicleMgt ILocationMgt

*1.1.1: getLocationMatching(refLocation:String, pickupCountry: String, pickupAddress: String): Boolean

1.1: listVehicleTypes(pickupCountry: String, pickupAddress:String): VehicleType[]

28


• IRecordReservation::identifyVehicleType()

Record


1: identifyVehicleTypes(selectedModel: String): VehicleTypeDetail

IVehicleMgt

1.1: identifyVehicleTypes(selectedModel: String): VehicleType

29


• IRecordReservation::listAvailableVehicles()

Record


1: listAvailableVehicles(selectedModel: String, requestedFromDate: Date, requestedToDate: Date): Vehicle[]

IVehicleMgt

1.1: listAvailableVehicles(selectedModel: String, requestedFromDate: Date, requestedToDate: Date): Vehicle[]

30


• IRecordReservation::identifyCustomer()

Record


1: identifyCustomer(identifier: String, password: String): CustomerDetail

IPartyMgt

1.1: identifyCustomer(identifier: String, password: String): Customer

1.2: getPartyInfo(partyId: String): Party

31


• IRecordReservation::recordReservation()

Record


1: recordReservation(regNumber: String, airline:String, flightNo:String): String

IReservationMgt IVehicleMgt

1.1: recordReservation(regNumber: String, fromDate: Date, toDate: Date, airline:String, flightNo:String): String

1.1.1: bookup(regNumber: String, fromDate: Date, toDate: Date): Boolean

32

Sample Solution: Refining the InterfacesSample Solution: Refining the Interfaces<<interface type>>

IResevationMgt

recordReservation(regNumber: String, fromDate: Date, toDate: Date, airline:String, flightNo:String): String

<<interface type>>

IVehicleMgtlistVehicleTypes(pickupCountry: String, pickupAddress:String): VehicleType[]

identifyVehicleTypes(selectedModel: String): VehicleType

listAvailableVehicles(selectedModel: String, requestedFromDate: Date, requestedToDate: Date): Vehicle[]

bookup(regNumber: String, fromDate: Date, toDate: Date): Boolean

<<interface type>>

ILocationMgt

getLocationMatching(refLocation:String, pickupCountry: String, pickupAddress: String): Boolean

<<interface type>>

IPartyMgt

identifyCustomer(identifier: String, password: String): Customer

getPartyInfo(partyId: String): Party

33

Sample Solution: Refining the InterfacesSample Solution: Refining the Interfaces

<<comp spec>>

ReservationSystem

ICreditInfoSystem

IRecordReservation

IRecordVehicleCollection

IRecordVehicleReturn

IMaintainContractPolicy

<<comp spec>>

ContractMgr

IContractMgt

<<comp spec>>

ReservationMgr

IReservationMgt

<<comp spec>>

VehicleMgr

IVehicleMgt

<<comp spec>>

PartyMgr

IPartyMgt

<<comp spec>>

InvoiceMgr

IInvoiceMgt

<<comp spec>>

LocationMgr

ILocationMgt

1 topics discovering business operations maintaining referential integrity completing the picture...

Documents