CS616 – Software
Engineering II
|
Lecture 9
|
Larman – Part5 – Elaboration: Iteration 3
Chapter 24 – Iteration 3 and its Requirements
Iteration 3 Requirements
- Provide failover to local services when the
remote services cannot be accessed
- Provide support for POS device handling, such as
chash drawer and coin dispenser
- Handle credit payment authorization
- Support for persistant objects
Iteration 3 Emphasis
Broad view of design –
exploring:
- Relating use-cases
- Generalization and specialization
- State modeling
- Layered architetectures
- Design of packages
- Architectural analysis
- More GoF design patterns
- Design frameworks
Chapter 25 – Relating Use Cases
1. The Include Relationship
·
Most common and
important organizing relationship
·
E.g.
UC1: Process Sale
|
Main
Success Scenario (or Basic Flow): |
|
1. Customer arrives at 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
|
… |
Extensions
|
|
6b. Paying by credit: Include Handle Credit Payment |
|
… |
UC12: Handle Credit Payment
|
… |
Level: Subfunction
Main Success Scenario: |
Extensions: 2a. System detects failure to collaborate with external system: 1. System signals error to Cashier. 2. Cashier asks Customer for alternate payment … |
|
|
NOTE: Handle Credit Payment subfunction use case was
originally in extension section of Process Sale use case., but factored out to
avoid duplication.
2. The extend Relationship
·
Create an extending use
case
·
Within it describe
where and under what conditions it extends the behavior of some base use case
UC1: Process Sale (the base use case)
|
… Extension
Points: VIP
Customer, step 1. Payment, step 7. Main
Success Scenario (or Basic Flow): |
|
1. Customer arrives at POS checkout with goods and/or services to
purchase. |
|
… |
|
7. Customer pays and System handles payment. |
|
… |
3. Use Case Diagrams
Figure – Use case include relationship
Figure – extend relationship
Chapter 26 – Modeling Generalization
1. New Concepts for the Domain Model
1. Create generalization-specialization hierarchies
Concepts Category List
|
Category |
Examples |
|
Physical and tangible
objects |
Credit Card, check |
|
Specifications, designs,
or descriptions of things |
|
|
Places |
|
|
Transactions |
CashPayment,
CreditPayment, CheckPayment |
|
Transaction line items |
|
|
Role of people |
|
|
Containers of other things |
|
|
Things in a container |
|
|
Other computer or
electro-mechanical systems external to system |
CreditAuthorizationService,
CheckAuthorizationService |
|
Abstract noun concepts |
|
|
organizations |
CreditAuthorizationService,
CheckAuthorizationService |
|
Events |
|
|
Rules and policies |
|
|
Catalogs |
|
|
Records of finance, work,
contracts, legal matters |
AccountsReceivable |
|
Financial instruments and
services |
|
|
Manuals, books |
|
Noun Phrase Identification from the Use Cases
|
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. |
|
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. |
2. Generalization
·
Concepts CashPayment,
CreditPayment, and CheckPayment all similar
·
Organize them into
generalization-specialization class hierarchy
- Superclass Payment represents a more general
concept
3. Defining Conceptual SuperClasses and Subclasses
- A conceptual superclass definition is more
general and encompassing than a subclass definition
- e.g. Consider the superclass Payment and its
subclasses (CashPayment, CreditPayment, and CheckPayment )
- Assume definition of Payment represents the
transaction of transferring money for a purchase from one party to
another
- All members of a conceptual subclass set are
members of their superclass set
- Subclass conformance:
- Is-a Rule:
- All the members of a subclass set must be
members of their superclass set
- E.g. CreditPayment is a Payment.
4. When to define a Conceptual Subclass
·
Create a conceptual
subclass of a superclass when:
- 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
subclasses, in ways that are of interest
- The subclass concept represents an animate thing
(e.g. animal. Robot) that behaves differently than the superclass or other
subclasses, in ways that are of interest
5. When to define a Conceptual SuperClass
- Create a conceptual siperclass in a
generalization relationship to subclasses when:
o
The potential
conceptual subclasses represent variations of a similar concept
o
The subclasses will
conform to Is-a rule
o
All subclasses have the
same attribute which can be factored out and expressed and expressed in the
superclass
o
All subclasses have the
same association which can be factored out and related to the superclass
6. NEXGEN POS Conceptual Class Hierarchies
Payment Classes
Figure – Justifying Payment subclasses
Authorization Services Classes
7. Abstract Conceptual Classes
·
Every member of a class
C must also be a member of a subclass, then class C is called and abstract
conceptual class
·
e.g. every Payment
instance must be an instance of the subclass CashPayment, CreditPayment, and
CheckPayment
·
since every Payment
member is also a member of a subclass, Payment is an abstract conceptual
subclass
Figure – abstract conceptual
classes