系統分析設計與實作 Week 7

烏龜訂購系統
phase 2 萃取穩定的結構共用元素(企業物件)

1. middle ware
2. controller

一開始不容易馬上判斷出來，可先放controller，再透過重構方式「逐漸萃取」
ex. 「計算訂購總額」應該放哪
hint: 推理，不要強記
「計算訂購總額」理論上放在訂購object上，但應該抽出到BO(企業物件)，當共用的元素

過去，放store_procedure或script都不算好

但一開始要不容易抽，所以折衷先放controller
將來重構放到business object
=>將可共用的企業規則抽出

交易事件
人，(事/時)，地，物

1. 界定範圍
   利用UC，一般抓到5,6成就夠了
   
   • User Case View
   • Locial View
     -UC Realization
     -Class Model (配合codegen)
     

   UC都是片斷，有滿足即可，不要流程，至於滿足的程度依"Session"來判斷

2. 撰寫UC敘述
   把「容易變」的跟「不容易變」的分開
   共用的可抽出來放
   =>產出Document
   
3.  
4. 實現UC (logical view realization)
   用UC Diagram當doc type
   *橋接實作，即建Conroller
5. 建Controller
   設計可能會漏掉，由實作(feedback)去做調整，補足或修正Controller, UC Description
   

   隨時都在調，因此文件要少、精簡，過程中都是只是最後文件的snapshot

16.1.3.資訊系統的分層結構

• 表達層(Presentation):UI
• 中間層：CO(Control Object)
  DAO: 將DB存取細節放至DAO,任何跟DB有關的存取透過小弟DAO解決
  Adapter:外部系統的鏈結
  軟體主結構即抽出的概念性物件BO
• 資料層：Database

三大物件

1. Controller
2. Boundary
   實體變動
3. BO
   應付Domain變動，一開始不易抓，先放controller

循序圖不是要表達精細，重點在完成某功能時，反應run time的流程

EA做Sequence Diagram時，拉物件會要選擇"Simple link or Instance", 選instance,因為是物件
隱含的method用加雙斜線 ex.到db抓資料=>//select

不用每個UC都畫Sequence，只畫比較需要的
何謂需要
programmer無法看出必要的method(無共識時)

UI, Controller 應分開獨立的Project

系統結構面
Jobcason將結構分為
控制
實體
邊界
目的：好分類->好維護
結構只對developer有好處(好維護)，User只看畫面

---
為何叫物件導向
都是用類別在定義，為何不是類別導向
心中想像的是物件在互動，而利用class描述出來，
ex. 作曲做的是音樂，但是得利用五線譜「作曲」記錄