OO Methodology Elaboration Iteration 3 – Part 1 Refining Models.
-
Upload
sophia-conley -
Category
Documents
-
view
227 -
download
3
Transcript of OO Methodology Elaboration Iteration 3 – Part 1 Refining Models.
OO Methodology
Elaboration Iteration 3 – Part 1
Refining Models
2
Table of Contents
• Iteration 1– Use-Case Model
– Process Sale Use Case
– Domain Model
– Design Model
• Iteration 2 – GRASP: More Patterns for Assigning Responsibilities
– Designing Use-Case Realizations with GoF Design Patterns
• Iteration 3– Iteration 3 and Its Requirement
– Related Use Cases
– Modeling Generalization
– Refining the Domain Model
– Adding New SSDs and Contracts
– Modeling Behavior in Statechart Diagrams
– Designing the Logical Architecture with Patterns
– Organizing the Design and Implementation Model Packages
– Introduction to Architectural Analysis and the SAD
– Designing More Use-Case Realization with Paterns
– Designing a Persistence Framework with Patterns
3
Iteration 3 Requirements
• Handle credit payment authorization
• Provide failover to local services when the remote services cannot be accessed.
• Provide support for POS device handling, such as the cash drawer and coin dispenser
• Support for persistent objects
4
Relating Use Cases
• Three methods of relating use cases– include
– extend
– generalize
• The include relationship– a relationship from a base use case to an inclusion use case
– specify how the behavior of the inclusion use case can be inserted into the behavior of the base use case
– an inclusion use case represents encapsulated behavior that potentially can be reused in multiple base use cases
– an inclusion use case is not a separate instantiable classifier
– an inclusion use case sets attribute values in the base use case
– the base use case must not access the attributes of inclusions
Process Sale Process Rental
Handle Credit Payment
<<include>><<include>>
5
The include Relationship
Use Case: Process Sale (the base use case)Main Success Scenario:1. Customer arrives at a POS ...7. Customer pays and System handles payment...Extensions:7b. Paying by credit: Include Handle Credit Payment7c. Paying by check: Include Handle Check Payment
Use Case: Process Rental (the base use case)Extensions:...6b. Paying by credit: Include Handle Credit Payment
Use Case: Handle Credit Payment (inclusion use case)Level: subfunctionMain Success Scenario:1. Customer enters their credit information.2. System sends payment authorization request to an external
Payment Authorization Service System.3. ...Extensions:2a. System detects failure to collaborate with external system:
1. System signals error to cashier.2. Cashier asks Customer alternate payment.
....
6
The extend Relationship
• The extend Relationship– a relationship from an extension use case to a base use case
– The extension use case incrementally modifies the base use case in a modular way
– a base use case defines a set of extension points, references of locations in the base case
– an extension use case contains a list of one or more insertion segments
– an extension use case accesses and modifies attribute values in the base use case
– the base use case must not access the attributes of extensions
Process Sale
Extension Points:Payment
VIP Customer
Handle Gift CertificatePayment
<<extend>>Payment [Customer presentsa gift certificate]
7
The extend Relationship
Use Case: Process Sale (base use case)
Extension Points: VIP Customer, step 1. Payment, step 7.
Main Success Scenario:1. Customer arrives at a POS ...7. Customer pays and System handles payment...
Use Case: Handle Gift Certificate Payment(extension)
Trigger: Customer wants to pay with gift certificate
Extension Points: Payment in Process Sale
Level: subfunction
Main Success Scenario:
1. Customer gives gift certificate to Cashier
2. Cashier enter gift certificate ID.
...
8
The extend Relationship
• Example : ATM
9
The generalize Relationship
• The generalize Relationship– a taxonomic relationship between a child use case and the
parent use case
– the parent describes the characteristics the child shares with other use cases
– the child inherits the behavior sequence of the parent and may insert additional behavior into it.
– the child may modify behavior steps inherited from the parent
Verify Identity
Check Password Retinal Scan
10
Comparison of Use Case Relationships
11
Modeling Generalization
• Generalization-specialization class hierarchy
• Generalization is the activity of identifying commonality among concepts and defining superclass (general concept) and subclass(special concept)
• Generalization is different from inheritance– inheritance is a mechanism for combining shared incremental
descriptions to form a full description of an element
CashPayment
CreditPayment
CheckPayment
Paymentsuperclass - more generalconcept
subclass - morespecialized concept
these are conceptualclasses, not softwareclasses
12
Modeling Generalization
• Conceptual Subclass Definition Conformance– 100% of the conceptual superclass’s definition shold be
applicable to the subclass
– the subclass must conform to 100% of the superclass’s attribute and associations (100% rule)
• Conceptual Subclass Set Conformance– all members of a subclass set must be members of their
superclass set. (Is-A rule)
CashPayment
CreditPayment
CheckPayment
Payment
amount : Money
abstract classindicated by italics
Payment
CashPayment CreditPayment CheckPayment
13
Modeling Generalization
• When to Define a Conceptual Subclass– the subclass has additional attributes of interest.
– the subclass has additional associations of interest.
– the subclass concept is operated on, handled, reacted to, or manipulated differently than the superclass or other classes
– the subclass concept represents an animate thing that behaves differently than the superclass or other classes
• When to Define a Conceptual Superclass– the potential conceptual subclasses represent variations of a
similar concept
– the subclasses will conform to the 100% and Is-A rules
– all subclasses have the same attribute which can be factored out and expressed in the superclass
– all subclasses have the same associations which can be factored out and related to the superclass
MaleCustomer
FemaleCustomer
Customer Correct subclasses.
But useful?
14
Abstract Conceptual Classes
• If every member of a class C must also be a member of a subclass, the class C is called an abstract conceptual class
Payment
CashPayment CreditPayment CheckPayment
Payment
CashPayment CreditPayment CheckPayment
If a Payment instance mayexist which is not aCashPayment, CreditPaymentor CheckPayment, thenPayment is not an abstractconceptual class.
Payment is an abstractconceptual class. A Paymentinstance must conform to oneof the subclasses:CashPayment, CreditPaymentor CheckPayment.
abstract conceptual class
(a)
(b)
CashPayment
CreditPayment
CheckPayment
Payment
amount : Money
abstract classindicated by italics
15
NextGen POS Class Hierarchies
• Payment Classes
• Authorization Service
CashPayment
CreditPayment
CheckPayment
Payment
amount : Money
Check
Identifies-credit-with Paid-with*
each payment subclass ishandled differently
additional associations
superclass justified by commonattributes and associations
SalePays-for
CreditCard
1
1
1 1
CreditAuthorization
Service
CheckAuthorization
Service
CheckPayment
AuthorizationService
addressnamephoneNumber
additional associations
superclass justified bycommon attributes andassociations
StoreAuthorizes-payments-of *
Authorizes
CreditPayment
Authorizes
**
*
1 1
16
NextGen POS Class Hierarchies
• Authorization Transaction Classes– Degree of generalization
CreditPaymentApproval
Reply
CheckPaymentApproval
Reply
CreditPaymentApprovalRequest
CheckPaymentApprovalRequest
CreditPaymentDenialReply
CheckPaymentDenialReply
CheckPaymentAuthorization
Reply
CreditPaymentAuthorization
Reply
PaymentAuthorization
Reply
PaymentAuthorization
Request
PaymentAuthorizationTransaction
datetime
Concepts too fine grained?Useful to show this degree ofpartitioning?
Each transaction ishandled differently, soit is useful to partitionthem into discreteclasses.
CreditPaymentApprovalRequest
CheckPaymentApprovalRequest
PaymentAuthorization
Reply
PaymentAuthorization
Request
PaymentAuthorizationTransaction
datetime
CreditPaymentApproval
Reply
CheckPaymentApproval
Reply
CreditPaymentDenialReply
CheckPaymentDenialReply
17
Modeling Changing States
• Do not model the states of a concept X as superclasses of X. Rather either:
– define a state hierarchy and associate the states with X
– Ignore showing the states of a concept in the domain; show the sates in a state diagram instead.
Transition between Non-member Customer and Member Customer ???
Paymentnot useful
these subclasses arechanging states of thesuperclass
UnauthorizedPayment
AuthorizedPayment
PaymentState better
UnauthorizedState
AuthorizedState
Payment Is-in 1*
18
Constraints on Generalization
• A constraint on a generalization specifies further information about how the generalization could be used and extended
• Predefined constraints– overlapping
– disjoint
– complete
– incomplete
Worker
Butcher Baker CandlestickMaker
{overlapping, incomplete}
Customer
FemaleCustomer
MaleCustomer
{complete,disjoint}
19
Association
• Association– Association is semantic relationship between two or more
classifiers that involves connection among their instances
– Each instance of an association(a link) is a tuple (an ordered list) of references to objects
• Structure
• Advanced Topics– association class
– n-ary association
– derived association
– qualifier
A Bq_name:C0..*role
qualifier
multiplicity
rolename
navigability
associationpath aggregation/
composition
associate
associationname
20
Association Class
• Association class is an association that is also a class
• It may have attributes, operations and associations with other classes
• Semantics– a link(instance) of an association class takes its identity from
the object references in it.• job1 : c1 – p1
• job2 : c1 – p2
• job3 : c1 – p1
– an association is a set of tuples and has no duplicates among its object references
Company Person
Job
salary
0..* 0..*
employer employee
duplicate (not correct)
21
Association Class
• Consider the following associations
– implicit relationship by Job class
– provides duplicates in relationship among Company and Person objects
• c1 – job1 – person1
• c1 – job2 – person2
• c1 – job3 – person1
• An Example1. a person owns stock (some number of shares) of a company
2. a person purchased stock of a company several times each with different price at different time
duplicate (correct)
Company Person
Stock
quantity
0..* 0..*
Company PersonJob
salary0..* 0..*1 1
Company PersonPurchase
salarydatecost
0..* 0..*1 1
buyerseller
seller buyer
22
Association Class
• NextGen POS Requirements– Authorization services assign a merchant ID to each store for
identification
– A payment authorization request from the store to an authorization service needs the merchant ID
– A store has a different merchant ID for each service
• Placing Merchant ID in the Store class or AuthorizationService
– it is incorrect because a Store can have more than one value for merchantID
• A better solution, not yet useful
addressmerchantIDnamephoneNumber
AuthorizationService
addressmerchantIDname
Store both placements ofmerchantID are incorrectbecause there may bemore than one merchantID
addressnamephoneNumber
AuthorizationService
addressname
Store
merchantID
ServiceContractPurchases
1..* *
a better model, but notyet as useful as possible
Sells
Authorizes-payments-via 1..**
23
Association Class
• Final Solution : using an association class
• Guidelines for adding association classes– an attribute is related to an association
– instances of the association class have a life-time dependency on the association
– there is many-to-many association between two concepts and information associated with the associated with the association itself
– a link (an instance of association) is identified by two objects in it.
addressnamephoneNumber
AuthorizationService
addressname
Store
merchantID
ServiceContract an association class
its attributes are related tothe association
its lifetime is dependent onthe association
Authorizes-payments-via 1..**
24
n-ary Association
• An association among three or more classes
• each instance of the association is an n-tuple of values from the respective classes
• Properties– navigability is meaningless
– multiplicity may be specified but is less obvious and complicated
– aggregation is meaningless
• Generally, n-ary associations are useful only when all the values are needed to uniquely determine a link
• An n-ary association is almost always implemented as a class whose attributes include pointers to the participant objects
Year
PlayerTeam
season
goalkeeper
team*
*
*
25
n-ary Association
• Multiplicity in n-ary association– the multiplicity is defined with respect to the other n-1 ends.
• e.g. in a ternary association (A,B,C), the multiplicity in C states how many C objects may appear in association with a particular pair of A and B objects.
• Example: Course Registration
– for a (course, student) pair, there is zero or one professor
– for a (student, professor) pair, there are many courses
– etc.
Student
ProfessorCourse *
*
0..1
Registration
26
n-ary Association
• Example(cont.)
Student
Professor
Course
*
Registration
*
*11 1
Student
Professor
OpenCourse
1
Registration
1..*
*11 1
Course
*
1
27
Qualifiers
• Qualifier– a slot for an attribute or list of attributes on a binary
association– the values of the attributes select a unique related object or a
set of related objects from the entire set of objects– it is an index on the traversal of an association– qualified object vs target object– a qualifier always acts on an association whose multiplicity is
many in the target direction
• The purpose of the qualifier is to reduce the multiplicity to one by adding the qualifier so that a query can be assured of returning a single value
Bank
account #
Person
*
1 multiplicity after qualification
targetclass
qualifiedclass
qualifier
(bank, accont#) -> one personone person -> many (bank, account #)
28
Qualifiers
• Example
Directory
filename
File
*
0..1
(directory,filename) -> o or 1filedirectory -> many filesfile -> many (directory, filename)file-> many directoriesfile -> many file names
Directory
filename
File
*
0..1
1
*
{same}
same but different level ofdetails
(directory,filename) -> o or 1filedirectory -> many filesfile -> many (directory, filename)file-> 1 directoryfile -> many file names
29
Qualifiers
• Qualified Association in NextGen POS
ProductCatalog
ProductSpecification
itemID Contains
ProductCatalog
ProductSpecification
Contains 1..*
multiplicity reduced to 1
(a)
(b)
qualifier
1
11
30
Roles
• Role names
• Roles as Concepts vs Roles in Associations
Flight CityFlies-to* destination
role name
describes the role of a city in theFlies-to association
Person
*parent
Creates
2
child
1
Store PersonEmploys-to-handle-sales cashier
Employs-to-manage manage
r
**
Manages
*worker
manager
Store
Cashier
ManagerEmploys
*
Employs
*
roles as concepts
Manages
*
roles in associations
1
1
1
1 1
31
Derived Elements
• Derived element is an element that can be computed from other elements and is included for clarity
• It is logically redundant and adds no semantic information
Person
birthdate/age { age = currentDate-
birthdate }
Company
Person
1
*
1
* Department
worksForDepartment
/worksForCompany
derivedassociation
date/totaltime
Sale
derived attribute
32
Constraints on Associations
• Ordered
• Exclusive-OR
SalesLineItem1..*{ordered
}
Sale
... 1there is some kind ofordering, such as byorder added
Insurancecompany
Insurancecontract
Person Compnay
{or}
1
0..*
1..* 1..*
0..*