日本旅遊有用的連結

利木津巴士的路線（中文）
利木津巴士的路線（英文）
利木津巴士新宿車站的時刻表（英文）
利木津巴士新宿車站附近地圖
日本氣象廳
日本地圖網
日本漫遊
這裡有一些東京旅遊資訊
John & Christine's Tokyo experience

Study "Applying Use Case Driven Object Modeling with UML" 4

至此，覺得ICONIX確實有助於我們將使用案例轉為設計文件，但同時也有以下的疑問：

1. 如何表達關於DAO的設計，如果缺了這部分，很難說直接從 controller 到 entity objects 是個完整設計
2. 是否能將其 CDR (Critical design review) 應用於測試導向設計 (Functional test plan)，可討論
3. 若將 Function list 的 SRS 作為分析的基礎，應該要將其轉為 use case 再作處理較佳，若稍有經驗者，可以直觀法將其視為 use case 將其 function 視為 basic or alternate caurses 並據以形成 domain models 以轉化成 sequence diagram 及基本的 static models
4. 按照 noun/verb 規則，若僅是單純導頁，如在首頁中按下新增按鈕，導頁至可有數種新增選項枝頁面，其為弱牽涉 controller 控制，若此二頁面中有連接線並無不可，相對而言，若堅持中間必須經過 controller 過程，則整體設計師去彈性
   

Study "Applying Use Case Driven Object Modeling with UML" 3

The Top 10 PDR (preliminary design review) Errors

1. 未確認客戶了解這是系統建構釋出前可以變更系統行為的最後機會
2. 未確認使用案例描述與 robustness diagram 是否吻合
3. 未確認新的 entity object 被加入 domain model
4. 在 domain class 中未尋找其屬性
5. 在 PDR 階段就預期將 operation 分派給 class
6. 未再提醒客戶使用案例描述就是客戶與開發的技術人員的合約
7. 要求以 robustness analysis 做為 design pattern 的延伸使用（表現出 design pattern）
8. 未審視 noun/verb 物件間的連接規則
9. 期待 robustness diagram 表現出詳細設計而非概念層設計
10. 不用快速追蹤證實所有行為都被設計，而去仔細檢查每根箭頭的方向正確與否

Sequence Diagrams
在 interaction modeling 階段，需達成三個目標

1. 在三種 objects 間分派行為，在 robustness analysis 時期，辨別或推測出一組 class 可能完成使用案例中期待的行為，而且將這些行為拆解成分離的單位，再針對每一個單位的行為設計出 controller，然後決定哪個 object 該負責某項行為。若無法確定三種 objects 間的關係，就表示還沒到達進入此階段的時機。
2. 顯示你所有的使用案例中相關物件間詳細的交互影響。運行期物件間的交互影響是藉由彼此間的訊息傳遞為之。訊息促使期待之動作發生，而必須針對使用案例中每個單位的行為確認所需的訊息或方法。
3. 結束了物件間 operations 的分配後，應置重心於定義 static model 的屬性上。我們主張在 domain model 階段及 robustness analysis 階段以極抽象的方法定義 operations，甚至在初期設計階段 (preliminary design) 由於資訊不足，因此不應指派 method。本階段應有完整資訊以完成在 sequence diagrams 上 objects 行為的詳細設計。安排使用案例中 attributes 及 operations 所屬的物件也應於本階段完成。當進行動態塑模時，必須更新及擴充靜態模型，此舉會使你在瞭解如何運行系統的認知更加確定。

The Top 10 Sequence Diagramming Errors

1. 未對每個使用案例作出 sequence diagram
2. 未將使用案例情節描述置於 sequence diagram
3. 未先在 robustness diagram 上確認必要的 object
4. 未顯示出案例文件及訊息箭頭間之蹤跡
5. 未顯示 sequence diagram 的線路，反而代之以高階抽象概念
6. sequence diagram 中原本應該分派給各 objects 的行為卻改為流程圖
7. 忽略運算或邏輯相關的 method，反而將注意力放在屬性相關的 getter、setter method
8. 未對 sequence diagram 中 objects 間的訊息發生時機仔細設計
9. 當以繪製訊息箭號配置行為時，未遵循責任導向的物件設計原則
10. 當建構使用案例中每個 package 中的 local class diagram 時未同步更新靜態模型

Study "Applying Use Case Driven Object Modeling with UML" 2

Top 10 Domain Modeling Errors
（因斷電致使筆記資料遺失，後補）


Top 10 Use Case Modeling Errors

1. 把使用案例情節寫成了功能需求
2. 把使用案例的用途寫成了屬性及方法
3. 把使用案例寫得太簡要
4. 使用案例與 UI 完全分離
5. 使用案例中的角色可接觸之介面物件的命名不清，易生混淆
6. 描述情節時用了主動語態而非使用者的被動語態
7. 僅描述了使用者之間的互動而忽略了系統該有的回應
8. 省略了供替代的動作路線文字敘述
9. 未將焦點集中在案例內，而放在如何進入本案例或完成本案例後所發生之事
10. 花大把時間取決案例是 include 關係還是 extend 關係

The Top 10 Requirements Review Errors

1. 僅針對需求中之特徵審核而未審核所有需求
2. 不確認使用案例中之文字敘述是否符合系統行為
3. 不使用任何 GUI 原型或螢幕原型以確認系統行為
4. 使用案例維持在抽象的高階表達，致使非技術背景的客戶無法實際觸及系統實體
5. 不確認 domain model 能準確反映實體世界中概念上之物件
6. 不確認使用案例文件涉及 domain object
7. 未質疑沒有替代途徑的使用案例
8. 未質疑是否在每一個使用案例中所有替代途徑都已被考慮
9. 不關注以被動語態完成的使用案例描述
10. 使用案例過長

Robustness Analysis

1. robustness diagram

• 使用三種 Objects - Boundary objects (nouns), Entity objects (nouns), Control objects (verbs) （看起來跟MVC差不多）
• noun/verb 規則（Nouns can’t talk to other nouns, but verbs can talk to either nouns or verbs）
• - 1. Actors can only talk to boundary objects.
• - 2. Boundary objects can only talk to controllers and actors.
• - 3. Entity objects can only talk to controllers.
• - 4. Controllers can talk to boundary objects, entity objects, and other controllers, but not to actors.
  

The Top 10 Robustness Analysis Errors

1. 違反了 noun/verb 規則
2. 在使用案例文件上，未以 robustness analysis 分析成一致的格式
3. 未以 robustness analysis 確認在使用案例文件中的名稱是否與 class diagram 中的名稱一致
4. 在 robustness diagram 中，未含括替代途徑
5. 在 robustness diagram 中分派行為給 class
6. 在一個使用案例中包含過多或過少的 controllers，建議介於 2~5 個之間
7. 花過多時間修飾 robustness diagrams
8. 在 robustness diagrams 的基礎上嘗試做出系統詳細設計
9. 未針對使用案例文件進行 robustness diagrams 的追蹤查核
10. 未更新靜態模型 (static model)

Study "Applying Use Case Driven Object Modeling with UML"

主要議題：如何從 use case model 過渡成 codes

1. OO系統中，codes的結構是藉由class所定義，因此在coding前需完成 design-level class diagram。問號因此介於 use case model & class diagram
2. 設計中極困難之處是如何配置行為，而 sequence diagram 可提供有效的資訊，class因此清楚本身需完成的行為

ICONIX process

1. 解決如何從 use case model 到 sequence diagram
2. robustness diagram - 介於需求及細部設計間，有助於跨越需求到設計的鴻溝
3. 物件模型中的背景描述要說明系統的用處
4. 經由問題領域而定義的 domain objects 及 boundary objects可使 sequence diagram 到 class diagram 間能更明確其設計演變的過程