1. Relating Use Cases
popo

2. Use cases can be used to related each other.
Relating Use Cases
Use cases can be used to related each other.
Organizing use cases into relationships has no impact on the behavior or requirements of the system.
It is simply an organization mechanism to improve communication and comprehension of the use cases, reduce duplication of text, and improve management of the use case documents.
popo

3. The include Relationship The extend Relationship
Relating Use Cases
Two types
The include Relationship
The extend Relationship
popo

4. Relating Use Cases popo The include Relationship
It is common to have some partial behavior that is common across several use cases.
For example, the description of paying by credit occurs in several use cases, including Process Sale, Process Rental, Contribute to Lay-away Plan, and so forth.
Rather than duplicate this text, it is desirable to separate it into its own sub function use case, and indicate its inclusion.
This is simply refactoring and linking text to avoid duplication.
popo

5. Relating Use Cases popo The include Relationship For example:
UC1: Process Sale …
Main Success Scenario:
1.Customer arrives at a POS checkout with goods and/or services to purchase.
7.Customer pays and System handles payment.
Extensions:
7b. Paying by credit: Include Handle Credit Payment.
7c. Paying by check: Include Handle Check Payment.
UC7: Process Rental
6b. Paying by credit: Include Handle Credit Payment.
popo

6. Relating Use Cases popo The include Relationship Example
UC12: Handle Credit Payment …
Level: Subfunction
Main Success Scenario:
1. Customer enters their credit account information.
2. System sends payment authorization request to an external Payment Authorization Service System, and requests payment approval.
3. System receives payment approval and signals approval to Cashier.
4. …
Extensions:
2a. System detects failure to collaborate with external system:
1. System signals error to Cashier.
2. Cashier asks Customer for alternate payment.
popo

7. Relating Use Cases popo The include Relationship
A use case that includes another use case, or that is extended or specialized by another use case is called a base use case.
Process Sale is a base use case with respect to the included Handle Credit Payment subfunction use case.
On the other hand, the use case that is an inclusion, extension, or specialization is called an addition use case.
Handle Credit Payment is the addition use case in the include relationship to Process Sale.
Addition use cases are usually abstract.
Base use cases are usually concrete.
popo

8. Relating Use Cases popo The extend Relationship
Suppose a use case's text should not be modified.
Perhaps continually modifying the use case with new extensions and conditional steps is a maintenance headache, and can't be touched.
How to append to the use case without modifying its original text?
Using The extend relationship.
The idea is to create an extending or addition use case, and within it, describe where and under what condition it extends the behavior of some base use case.
popo

9. Relating Use Cases popo The extend Relationship For example:
UC1: Process Sale (the base use case) …
Extension Points: VIP Customer, step 1. Payment, step 7.
Main Success Scenario:
1.Customer arrives at a POS checkout with goods and/or services to purchase.
7.Customer pays and System handles payment.
popo

10. Relating Use Cases popo The extend Relationship
UC15: Handle Gift Certificate Payment (the extending use case) …
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 enters gift certificate ID.
popo

11. Relating Use Cases popo This is an example of an extend relationship.
Note the use of an extension point, and that the extending use case is triggered by some condition.
Extension points are labels in the base use case which the extending use case references as the point of extension, so that the step numbering of the base use case can change without affecting the extending use case.
popo

12. Domain Model
popo

13. Domain Model
Domain Model may be incrementally developed by considering the concepts in the requirements for this iteration.
Techniques such as the Concept Category List and noun phrase identification will use.
An effective approach to developing a domain model is to study the work of other authors on this subject.
popo

14. Domain Model popo Concept Category List Table 26.1 shows some
concepts being considered
in this iteration
popo

15. Domain Model popo Noun Phrase Identification from the Use Cases
To reiterate, noun phrase identification cannot be mechanically applied to identify relevant concepts to include in the domain model.
Judgement must be applied and suitable abstractions developed, since natural language is ambiguous and relevant concepts are not always clear in existing text.
However, it is a practical technique in domain modeling since it is straightforward.
This iteration handles the scenarios of the Process Sale use case for credit and check payments.
The following shows some noun phrase identification from
these extensions:
popo

16. Domain Model popo Noun Phrase Identification from the Use Cases
Use Case UC1: Process Sale
Extensions:
7b. Paying by credit:
1 . Customer enters their credit account information.
2. System sends payment authorization request to an external Payment Authorization
Service System, and requests payment approval.
2a. System detects failure to collaborate with external system:
1. System signals error to Cashier.
2. Cashier asks Customer for alternate payment.
3. System receives payment approval and signals approval to Cashier.
3a. System receives payment denial:
1. System signals denial to Cashier.
4. System records the credit payment, which includes the payment approval.
5. System presents credit payment signature input mechanism.
6. Cashier asks Customer for a credit payment signature. Customer enters signature.
7c. Paying by check:
1. The Customer writes a check, and gives it and their driver's license to the
Cashier.
2. Cashier writes the driver's license number on the check, enters it, and requests
check payment authorization.
3. Generates a check payment request and sends it to an external Check Authorization
Service.
4. Receives a check payment approval and signals approval to Cashier.
5. System records the check payment, which includes the payment approval.
popo

17. Domain Model popo Noun Phrase Identification from the Use Cases
Authorization Service Transactions
The noun phrase identification reveals concepts such as CreditPaymentRequest and CreditApprovalReply.
These may in fact be viewed as types of transactions with external services, and in general, it is useful to identify such transactions
because activities and processes tend to revolve around them.
popo

18. Domain Model popo Noun Phrase Identification from the Use Cases
These transactions do not have to represent computer records or bits travelling over a line.
They represent the abstraction of the transaction independent of its means of execution.
For example, a credit payment request may be executed by people talking on the phone, by two computers sending records or messages to each other, and so on.
popo

19. REFINING THE DOMAIN MODEL
popo

20. REFINING THE DOMAIN MODEL
Add association classes to the Domain Model.
Add aggregation relationships.
Model the time intervals of applicable information.
Choose how to model roles.
• Organize the Domain Model into packages
popo

21. REFINING THE DOMAIN MODEL
Association Classes
In a domain model, if a class C can simultaneously have many values for the same kind of attribute A, do not place attribute A in C.
Place attribute A in another class that is associated with C.
For example:
A Person may have many phone numbers.
Place phone number in another class, such as PhoneNumber or ContactInformation, and associate many of these to Person.
popo

22. REFINING THE DOMAIN MODEL
Association Classes
Placing merchantID in Store is incorrect because a Store can have more than one value for merchantID.
The same is true with placing it in Authorization-Service (see Figure 27.1).
popo

23. REFINING THE DOMAIN MODEL
Association Classes
Better way is
popo

24. REFINING THE DOMAIN MODEL
Association Classes
This leads to the notion of an association class, in which we can add features to the association itself.
ServiceContract may be modeled as an association class related to the association between Store and AuthorizationService.
In the UML, this is illustrated with a dashed line from the association to the association class.
popo

25. REFINING THE DOMAIN MODEL
Association Classes .
popo

26. REFINING THE DOMAIN MODEL
Aggregation and Composition
Aggregation is a kind of association used to model whole-part relationships between things. The whole is called the composite.
Aggregation is shown in the UML with a hollow or filled diamond symbol at the composite end of a whole-part association (see Figure 27.5).
popo

27. REFINING THE DOMAIN MODEL
Aggregation and Composition
Composite aggregation, or composition, means that the part is a member of only one composite object, and that there is an existence and disposition dependency of the part on the composite.
For example, a hand is in a composition relationship to a finger.
popo

28. REFINING THE DOMAIN MODEL
Association Classes
In the Design Model, composition and its existence dependency implication indicates that composite software objects create the part software objects (for example, Sale creates SalesLineItem)..
popo

29. REFINING THE DOMAIN MODEL
Association Classes
Composition is represented with a filled diamond.
It implies that the composite owns the part, and that they are in a tree structure parts hierarchy;
For example, a finger is a part of at most one hand thus the aggregation diamond is filled to indicate composite aggregation (see Figure 27.6).
popo