Upload
mabel-booth
View
213
Download
0
Embed Size (px)
Citation preview
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
Auxiliary Operations – Cont’dAuxiliary Operations – Cont’d
• 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
Auxiliary Operations – Cont’dAuxiliary Operations – Cont’d
• 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
Sample Solution: Discovering Business Op.Sample Solution: Discovering Business Op.
• IRecordReservation::identifyVehicleType()
Record
InternetReservationIRecordReservation
1: identifyVehicleTypes(selectedModel: String): VehicleTypeDetail
IVehicleMgt
1.1: identifyVehicleTypes(selectedModel: String): VehicleType
29
Sample Solution: Discovering Business Op.Sample Solution: Discovering Business Op.
• IRecordReservation::listAvailableVehicles()
Record
InternetReservationIRecordReservation
1: listAvailableVehicles(selectedModel: String, requestedFromDate: Date, requestedToDate: Date): Vehicle[]
IVehicleMgt
1.1: listAvailableVehicles(selectedModel: String, requestedFromDate: Date, requestedToDate: Date): Vehicle[]
30
Sample Solution: Discovering Business Op.Sample Solution: Discovering Business Op.
• IRecordReservation::identifyCustomer()
Record
InternetReservationIRecordReservation
1: identifyCustomer(identifier: String, password: String): CustomerDetail
IPartyMgt
1.1: identifyCustomer(identifier: String, password: String): Customer
1.2: getPartyInfo(partyId: String): Party
31
Sample Solution: Discovering Business Op.Sample Solution: Discovering Business Op.
• IRecordReservation::recordReservation()
Record
InternetReservationIRecordReservation
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