Relating Use Cases popo Relating Use Cases Use

Relating Use Cases popo

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

Relating Use Cases • Two types • The include Relationship • The extend Relationship • popo

Relating Use Cases • 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

Relating Use Cases • • • • • The include Relationship For example: UC 1: 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: 7 b. Paying by credit: Include Handle Credit Payment. 7 c. Paying by check: Include Handle Check Payment. … UC 7: Process Rental … Extensions: 6 b. Paying by credit: Include Handle Credit Payment. popo

Relating Use Cases The include Relationship Example UC 12: 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: 2 a. System detects failure to collaborate with external system: 1. System signals error to Cashier. 2. Cashier asks Customer for alternate payment. popo

Relating Use Cases • 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

Relating Use Cases • 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

Relating Use Cases • • The extend Relationship For example: UC 1: 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

Relating Use Cases • The extend Relationship • UC 15: 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

Relating Use Cases • 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 can change without affecting the extending use case. popo

Domain Model popo

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

Domain Model • Concept Category List • Table 26. 1 shows some • concepts being considered • in this iteration popo

Domain Model • 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

Domain Model • • • • • • • Noun Phrase Identification from the Use Cases Use Case UC 1: Process Sale Extensions: 7 b. 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. 2 a. 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. 3 a. System receives payment denial: 1. System signals denial to Cashier. 2. Cashier asks Customer for alternate payment. 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. 7 c. 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

Domain Model • Noun Phrase Identification from the Use Cases • Authorization Service Transactions • The noun phrase identification reveals concepts such as Credit. Payment. Request and Credit. Approval. Reply. • 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

Domain Model • 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

REFINING THE DOMAIN MODEL popo

• • • 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

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 Phone. Number or Contact. Information, and associate many of these to Person. popo

REFINING THE DOMAIN MODEL • Association Classes • Placing merchant. ID in Store is incorrect because a Store can have more than one value for merchant. ID. • The same is true with placing it in Authorization. Service (see Figure 27. 1). popo

REFINING THE DOMAIN MODEL • Association Classes • Better way is popo

• • 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. Service. Contract may be modeled as an association class related to the association between Store and Authorization. Service. In the UML, this is illustrated with a dashed line from the association to the association class. popo

REFINING THE DOMAIN MODEL • Association Classes • . popo

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

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

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 Sales. Line. Item). . popo

• • 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