3. Owning a hammer doesn't make one an
architect
Knowing an object-oriented language (such as Java) is a necessary but
insufficient first step to create object systems. Knowing how to "think in
objects" is also critical.
The UML is not OOA/D or a method, it is simply notation.
How should responsibilities be allocated to classes of objects? How should
objects interact? What classes should do what? These are critical questions in
the design of a system.
4. What Is Analysis and Design
Design emphasizes a conceptual solution that fulfills the requirements, rather
than its implementation. Ultimately, designs can be implemented.
=> Do the thing right.
Analysis emphasizes an investigation of the problem and requirements, rather
than a solution. It is a broad term, best qualified, as in requirements analysis
(an investigation of the requirements) or object analysis (an investigation of the
domain objects).
=> Do the right thing.
5. What Is Object-Oriented Analysis and Design
OOD: Defining software objects and how they collaborate to fulfill the
requirements.
Ex. Book software object may have a title attribute and a getChapter method.
OOA: Finding and describing the objects - or concepts - in the problem domain.
Ex. Book, Library, Patron. (跟 Software object 無關)
7. 這不是OO的產出，只是寫故事。
Play a Dice Game: A player picks up and rolls the dice. If the dice face value
total seven, they win; otherwise, they lose.
8. Define a Domain Model
● Object-oriented analysis is concerned with creating a description of the
domain from the perspective of classification by objects. A decomposition
of the domain involves an identification of the concepts, attributes, and
associations that are considered noteworthy. (分類法，找出概念、屬性跟關
係)
● A domain model is not a description of software objects; it is a
visualization of concepts in the real-world domain. (真實世界的概念)
12. 因為 play message 是丟給 DiceGame，所以 DiceGame 需要有 method play
而 Die Class 需要 roll 跟 getFaceValue 兩個方法
描述 Class 而不是真實世界
13. 使用UML的三種角度
1. Conceptual perspective the diagrams are interpreted as describing things
in a situation of the real world or domain of interest.
2. Specification (software) perspective the diagrams (using the same
notation as in the conceptual perspective) describe software abstractions
or components with specifications and interfaces, but no commitment to a
particular implementation (for example, not specifically a class in C# or
Java). <<實務上不常用>>
3. Implementation (software) perspective the diagrams describe software
implementations in a particular technology (such as Java).
16. Use Cases
Use cases 是文字的故事，不是 Diagrams
Process Sale:
A customer arrives at a checkout with items to purchase. The cashier
uses the POS system to record each purchased item. The system
presents a running total and line-item details. The customer enters
payment information, which the system validates and records. The system
updates inventory. The customer receives a receipt from the system and
then leaves with the items.
什麼故事：Some actor using a system to meet goal.
17. Definition: Actors, Scenarios and Use Cases
● An actor is something with behavior, such as a person (identified by role),
computer system, or organization; for example, a cashier.
● A scenario is a specific sequence of actions and interactions between
actors and the system; it is also called a use case instance.
● A use case is a collection of related success and failure scenarios that
describe an actor using a system to support a goal.
18. Scenarios example - Handle Returns (退貨處理)
Main Success Scenario:
A customer arrives at a checkout with items to return. The cashier uses the
POS system to record each returned item ...
Alternate Scenarios:
If the customer paid by credit, and the reimbursement (退款) transaction to
their credit account is rejected, inform the customer and pay them with cash.
If the item identifier is not found in the system, notify the Cashier and
suggest manual entry of the identifier code (perhaps it is corrupted).
If the system detects failure to communicate with the external accounting
system, ...
19. Use Cases 討論
● Use Cases 是文字故事
● Use Cases 跟物件導向沒有關係，寫下 Uses Cases 並不是在做OOA
● Use Cases are a key requirements input to classic OOA/D
● Use Cases emphasize the user goals and perspective (User-centric)
“Who is using the system, what are their typical scenarios of use, and what
are their goals?” (誰在什麼情境使用此系統，為了完成什麼事情)
20. 三種 Actors
Primary actor: has user goals fulfilled through using services of the system. <
收銀員>
Why: To find user goals, which drive the use cases.
Supporting actor: provides a service (ex. information) to the system. <自動付款
認證服務>
Why: To clarify external interfaces and protocols
Offstage actor: has an interest in the behavior of the use case. <稅務局>
Why: To ensure the all necessary interests are identified and satisfied.
27. Guidelines
1. Write in an Essential UI-Free Style (Root-goal, keep the user interface out
and focus on actor intent)
2. Write Terse Use Cases (刪掉贅詞)
3. Write Black-Box Use Cases (不考慮內部的運作，只在乎系統的
responsibilities，What 而不是 How)
4. Take an Actor and Actor-Goal Perspective
5. How to Find Use Cases
6. What Tests Can Help Find Useful Use Cases
29. 4. Take an Actor and Actor-Goal Perspective
Write requirements focusing on the users or actors of a system, asking about
their goals and typical situations.
Focus on understanding what the actor considers a valuable result.
30. 5. How to Find Use Cases
1. 選擇 system boundary (大框框)
2. 找出所有的 primary actors
3. 找出每個 primary actor 的 Goal
4. Define User Cases satisfy the goals of the primary actors
Actor-Goal List
33. 5.4 Define Use Cases
● 一個 Goal 寫一個 Use Case <CRUD例外>
● Use Case 的名稱類似 Goal :
○ Goal: process a sale
○ Use Case: Processs Sale
● Use Case 從動詞開始
34. 6. What tests can help find useful use cases
1. The Boss Test
2. Elementary Business Process (EBP) Test： A task performed by one person in
one place at one time, in response to a business event, which adds measurable
business value and leaves the data in a consistent state
3. The Size Test：3~10 steps
38. System Sequence Diagram
Clarify the input and output system events
related to our system
System Sequence Diagrams:
● 一個特定的scenario，所有
系統都當作黑盒子
● actor generate events
● 重點在抓出從 actor 穿越
system boundary 的 Event
UC已經描述外部的actor怎麼跟系統互動
39. SSD for a Process Sale scenario
Simple cash-only success
scenario of Process Sale
45. Domain Model, aka. Conceptual Model
A domain model is a visual representation of real-world
conceptual classes, not of software components in a
domain of interest. It is not a set of diagrams describing
software classes, or software objects with responsibilities.
- domain objects or conceptual classes
- associations between conceptual classes
- attributes of conceptual classes
Class Diagram 只用這些
48. Domain Model 不是在 Model Software Component
不要出現這些
● Software artifacts, such as a window or a database, unless the domain
being modeled is of software concepts, such as a model of graphical user
interfaces.
● Responsibilities or methods
49. Conceptual Class Identification
● The central task is to identify conceptual classes related to the scenarios
under design.
● It is better to overspecify a domain model with lots of fine-grained
conceptual classes than to underspecify it.
1. Use a conceptual class category list
2. Identify noun phrases
3. Analysis patterns [Fowler96] <<Transaction Pattern>>
尋找的策略
52. Domain Modeling Guidelines
1. List the candidate conceptual classes using the Conceptual Class
Category List and noun phrase identification techniques related to the
current requirements under consideration.
2. Draw them in a domain model.
3. Add the associations necessary to record relationships for which there is a
need to preserve some memory.
4. Add the attributes necessary to fulfill the information requirements.
53. Common Mistake
Perhaps the most common mistake when creating a domain model is to
represent something as an attribute when it should have been a concept.
If we do not think of some conceptual class X as a number or text
in the real world, X is probably a conceptual class, not an attribute.
如果還是不確定，將它當作 concept，domain model 中很少有attribute
56. From analysis to design
Use Case SSD
Domain
Model
Design
Model
use case diagram
and descriptions
sequence diagram conceptual class
diagram (state diagram)
class diagram
