Overview Ch1, 6, 9, 10

1. Applying UML and Patterns
2017/01/11
Taka Wang

2. CH1.
Object-Oriented Analysis and Design

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 無關)

6. Dice Game
骰子遊戲，一次丟兩個骰子，如果總和是
7則贏，否則就輸。

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. (真實世界的概念)

9. Partial Domain Model

10. 物件只是從真實世界得到 啟發，而不是直接Model真實世界。

11. Define Interaction Diagrams

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).

14. 三種角度的範例
domain concepts or conceptual classes
design classes

15. CH6.
USE CASES

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.

21. 三種常見的UC格式
Brief：通常是 main success scenario (抓個主題與範圍的感覺)
Casual： 前面的退款範例 (多個scenarios)
Fully dresses：所有步驟與變形的完整描述 (通常選10%有價值的UC來寫)

22. 完整陳述的範本

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

28. 3. Write Black-Box 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

31. 5.2 收銀員或顧客才是 Primary Actor?

32. 另一種手法：從 Event 出發
什麼事件，從哪來，為什麼？

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

35. Use Case Diagram
UC：畫圖還有畫線是次要的，文字
描述才是重點
畫 Use Case Diagram時，一併寫
下 actor-goal 清單
不要花超過一小時在這張圖上

36. Use Case Diagram 的繪製建議

37. CH9. USE-CASE MODEL:
Drawing system sequence
diagrams

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

40. SSDs and Use Cases
SSD 是從 UC 導出來的 後面有過程

41. 找出 System boundary，找出直接觸發(穿過)系統的 Event

42. Naming System Events and Operations
● System Event 應該表達出 intent，而不是從什麼媒介 (按
鈕)
● 從動詞出發比較好， 命令導向

43. 加上文字描述 (從 UC 抓過來)
● operations
● parameters
● return data
簡短就好

44. CH 10. Domain Model
Visualizing Concepts

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 只用這些

46. Domain Model example
Domain model is a visual dictionary of abstractions

47. Relate to Domain-Driven Design (DDD)
Ubiquitous
Language

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>>
尋找的策略

50. Conceptual Class Category List

51. 從 UC 找名詞

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

54. Skip..

55. Lowering the representational gap

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

57. Thank you