# 系統分析與設計

###### tags: `程式筆記` `web111a` `SA`

* **老師：洪福成**
* 時間：2022/3/16

## 進銷存

單純「進貨」、「銷貨」、「庫存」，進的貨不能**經過加工**

## 資料表規劃

### 依需求調整，依需求調整，依需求調整

### 基本檔

不太變動

1. 商品檔
2. 廠商檔
3. 客戶檔
4. 員工檔
1. 眷屬檔

### 交易檔

時常性變動，會有主檔及明細檔（正規化）

1. 採購檔
2. 進貨檔
3. 退貨檔
4. 訂單檔
5. 銷貨檔
6. 銷退檔

### 紀錄檔

1. 盤點檔
2. 匯率檔

### 衍生檔

系統產生的，非自建立

1. 進銷匯總檔
2. 應收檔
3. 應付檔

### 正規化

* 目的：避免資料重複
* 給電腦運作，不是給人看的
* 用編號取代名稱
* 可以用同一張表計算出的（例：總金額）不用列出
* 範例：進貨檔
* 主檔：
| 進貨編號 | 廠商編號 | 日期 | 總金額 |
| -------- | -------- | ---- | ----- |
* 明細檔
| 編號 | 商品編號 | 數量 | 單價 | 折扣 | 單據編號 |
| ---- | -------- | ---- | ---- | ---- | -------- |

### 作業：進銷存資料表規劃

---

* 配合投影片01，版權問題不放

## 開發原則

1. 目標明確
2. 有用
3. 新技術（系統可用壽命）
4. 有跡可循（合作流暢）
5. 考量人力及成本
6. 條件限制（例：時間、環境等）
7. 環境因素（例：公司文化）

## 程式設計師困境

* 轉職問題：40歲以後需有帶人經驗，能晉升高階主管
* 多數程式設計師只會跟電腦溝通，學會溝通很重要，包含你的扣、畫的圖別人看的懂

## 角色

* 專端使用者：問題領域的專家
* 企業經理：專端使用者的高階主管，通常把握前、人力、時間的預算，要巴結

## 結構化及物件導向

> 一旦開始排斥，就會一直覺得很難

### 結構化

* DFD：資料流程圖 Data Flow Diagram
* 主要的概念就是在表示**資料**的流程
* ERD：實體關係模型 Entity-relationship model
* 關聯式資料庫的設計圖，描述資訊需求和／或要儲存在資料庫中的資訊的類型

### 物件導向

## UML(本課會教以下4種)

是一種標準化建模語言，在軟體開發中，當系統規模比較複雜時，需要用圖形抽象地來表達複雜的概念。使用UML可幫助專案團隊進行溝通、探索潛在設計並驗證軟體的架構設計。

1. 使用個案圖
2. 類別圖
3. 循序圖
4. 活動圖

### 作業：學習目標

### 參考資料

* [SA, SE, SD的差別](https://dennis74728.pixnet.net/blog/post/13012312)

---

* **老師：洪福成**
* 時間：2022/3/21
* 配合投影片02，版權問題不放

### 作業講解：進銷存資料表設計

* 沒有絕對的正確答案
* 交易檔中主檔、明細檔間需要有對應的「編號」做關聯
* 有時候過度正規劃也會影響效能

### 課程預告

* 週四、週五：MS-SQL
* 著中於語法而非操作

## 資訊系統開發模式

因應不同情況有適合的開發模式

### 瀑布模式

* 將開發過程分成階段性，例如：分析>設計>實施
* 缺點：
* 初期就要把需求講清楚
* 需求變更很麻煩

### 漸增模式

* 雷於瀑布模式，但子系統可以**平行**開發

### 雛形模式

* 因得到的資訊（顧客需求）有限
* 強調快速開發及使用者參與度
* 較不適合大型開發案

### 螺旋模式

* 分成階段式，每一階段週而復始

### 同步模式

* 需要有整合管理系統，例如：coding 命名方式

### 統一流程模式

### 敏捷開發

主要的精神在於較短的開發循環（建立在反覆式開發方式上）以及漸進式開發與交付

在敏捷式開發中有個很重要的觀點是筆者很感興趣的，它認為塑模（Modeling）的目的**在於增加開發者了解軟體的程度**，進而使得軟體更接近於使用者的需求，而非使用塑模之後產生的文件。

* [你真的搞懂什麼叫敏捷式開發嗎？](https://www.projectup.net/article/view/id/15726)

#### 你有聽過 [Trello](https://trello.com) 嗎？


圖源：[什麼是敏捷式開發？--Microsoft dosc](https://docs.microsoft.com/zh-tw/devops/plan/what-is-agile-development)

### 練習：裝櫃明細

* 使用 access

---

## 需求分析

* **老師：洪福成**
* 時間：2022/3/30
* 配合投影片03，版權問題不放

### 階段活動

* 需求判斷：確認需求正確性
* 需求分析：解決矛盾
* 擷取
* 轉換
* 需求溝通

### 結構化系統分析

### 環境圖

系統所在之環境及其與環境間之關係，這包括與系統有關之外部實體及系統與外部實體間之互動，例如資訊之輸出入與處理等。


### 流程圖

* 系統流程圖(System Flow Chart)用以描述整個工作系統中，各單位之間的作業關係。
* 程式流程圖(Program Flow Chart)則用以表示程式中的處理過程。


1. 找出外部實體
2. 找出作業處理
3. 檢視外部實體
4. 繪製流程圖
5. 檢視流程圖

### 課外練習1：進銷存資料表查詢

* 進銷匯總檔：雖然欄位皆為系統產生，但仍需要一張資料表
* 資料關聯圖
* 小計、總計可善用[`UNION`](https://www.fooish.com/sql/union.html)

### 課外練習2：瑪雅面試

---

* 時間：2022/4/20
* 配合投影片03

## 專題題目討論

## 物件導向

* 配合投影片09

以物件模式來描述真實系統：

* 物件
* 類別


---

* 時間：2022/4/25
* 配合投影片10

## 使用個案圖

以外部觀察者角度來描述觀察到的系統功能，強調系統能做什麼(what)，而不是如何做(how)這些事。使用個案圖的繪製工作就是從需求分析文件中找出 Actor、使用個案及使用個案之間的關係。

一個使用個案是使用者透過介面要求系統所做的一連串相關事件流，應有起點及終點。從使用者的角度來看，每一個使用個案就是一個案例，可以完成某一項任務。


1. **Actor (行為者)** 在 Use Case 中有兩種角色：
1. 使用者(User)
2. 支援者 (Supporter)
1. **Use Case (使用個案)** 代表一個目的。所以在替 Use Case 命名時都是要以動詞+名詞為規範。
1. **Boundary (系統邊界)** 這是在 Use Case Diagram 中最重要的關鍵點之一。在需求的蒐集時若不先定義系統邊界，那很有可能所蒐集到的需求會越來越廣，廣到包山包海。

:::info
實務上，現在的使用個案圖已經不需要特別標示系統邊界，也不用箭頭方向，直線連接就好
:::

> 建議在抓 Use Case時能夠越精要越好，儘量不要將細節當成 Use Case 來使用，因為細節很可能會一直變，只有核心的目的是不會變的。


* 包含
* 使用個案 A 一定會用到另一使用個案 B，則稱 A 委派或整合 B(A Include B)，關係之箭頭符號由 A 指向 B。
* 例如：一定要加入購物車(B)才能結帳(A)。
* 延伸
* 使用個案 C 在某情況(條件)時（並非所有情況），被插入至另一使用個案的定義中（例如D），而形成一新的組合使用個案。即 C 在特定情況下為 D 的 Extension(C Extend D)，關係之箭頭符號由 C 指向 D。
* 當使用個案間有 Extend 關係時，需在 Extend 關係線上註明 Extend 之條件(Condition)與時機(Extension Point)。
* 例如：是會員(條件)的話，折扣\(C\)才能在結帳(D)時使用。

### 使用個案描述

完整的使用個案文件應包括使用個案名稱、行為者、使用個案、目標、使用個案發生之前提與結束狀態、一系列事件描述等。並在描述使用個案後，對照需求描述，以確認使用個案與需求描述相符。


## UI循序圖

要清楚地傳遞各物件在時間軸上的互動情境，因此會透過以下這張圖來標示參與的所有物件有哪些，以及在各時間點彼此互動的情況，幫助閱讀的人可以快速及清晰地掌握細節。

[[UML] 使用循序圖傳達各物件互動及時序關係](https://dotblogs.com.tw/wasichris/2016/03/17/232341)


* alt (Alternatives) : 任何情況只有一個序列發生，是互斥的條件。
* par (Parallel) : 平行處理，片段中的事件可以交錯執行。
* opt (Option) : 選擇項，不一定會發生的序列(要符合條件)。
* loop : 重複片段。可以設立重複的條件，若未設定最小級最大重複次數，預設表示無限制。
* ref (Reference) : 表示參考另一個互動循序圖，屬於Interaction Use 範疇。

## 專題

:::info
4/25確認組別、題目
:::

1. 列出功能列表
1. 使用個案圖
1. 使用個案描述
1. UI循序圖
1. AC循序圖
1. 類別圖
1. 流程圖
1. 工具推薦：
1. [cacoo](https://cacoo.com/) 有可愛貼圖
1. [Xmind](https://www.xmind.net/share/) 有可愛貼圖
1. [GitMind](https://gitmind.com/tw/)
1. draw.io

---

* 時間：2022/05/02
* 配合投影片10

## 活動圖

### 活動圖之元件


---

* 時間：2022/05/09

### 常見錯誤

* 不必要之活動不需要放進去，譬如更新資料成功後就可以結束，不需要在拉箭頭到瀏覽資料
* 有輸入資料就要註記（資料表欄位）
* 條件內容寫在菱形外面，盡量字數精簡，不要超過 6 字

## 循序圖（Sequence Diagram）

* 配合投影片11

:::info
AC 循序圖與 UI 循序圖正常是同一張循序圖，本課分開講解
:::

* 描述一個使用個案執行過程中，參與該個案的物件、以及物件間傳遞訊息的先後順序
* **強調訊息傳遞的時間性**

### 循序圖元件


* 介面物件(Interface Object)也稱邊界物件，包含表單、報表、硬體介面以及其他與系統溝通的介面，也是行為者和系統交談的媒介(又稱Boundary Object)。
* 控制物件(Control Object)包含許多應用系統邏輯（如企業規則），是實體物件及介面物件間的溝通者，也負責協調與管理其他物件。
* 實體物件(Entity Object)常以企業的領域術語命名，用來表示使用個案完成後仍需要儲存在資料庫中的資料，但某些實體物件也可以是暫存的資料，例如搜尋結果。

### 循序圖的基本步驟

參照老師 word 檔

* 活動圖有幾個活動，循序就要有對應的 UI（介面）
* UI 訊息 AC 中也要有對應
* UI 循序圖中，控制物件 controll 與實體 entity 物件可濃縮成一個系統「應用程式核心(Application Core, AC)」物件

#### UI 循序圖之建構步驟

1. 確認物件
1. 根據物件找尋準則，先找出介面與控制物件，介面物件包含表單、報表、硬體介面、其他與系統溝通的介面或行為者和系統交談的媒介。
1. 介面物件的屬性常是顯示在介面上的元件名稱，如欄位、超連結、選取方塊與按鈕名稱，而操作會將使用者在介面上輸入的資料傳遞給控制物件。
1. 控制物件的屬性包含從介面物件（或實體物件）接到的資料，其操作可分「傳遞資訊」與「執行邏輯功能」兩類。
1. 確認訊息與操作
1. 找出物件後可依使用個案描述和活動圖找出介面和控制物件間之訊息傳遞及操作。
1. 繪製UI 循序圖

#### AC 循序圖之建構步驟

1. 確認物件
1. 建構UI 循序圖時已找出各控制物件，因此建構AC 循序圖時僅須找出實體物件。
1. 實體物件常以企業的領域術語命名，用來表示需儲存在資料庫的資料或是暫存資料。
1. 其屬性主要記錄該物件所具備的特徵與資訊；操作為處理系統資訊的相關行為。
1. 確認訊息與操作
1. 接著依使用個案描述和活動圖找出控制與實體物件間之傳遞訊息及操作。
1. 繪製AC 循序圖

* 注意
* 去回都一定會經過控制類別，不能直接到實體

### 常見錯誤及提問

請參考老師提供[常見錯誤示範:B6.1.循序圖繪製問題參考](https://docs.google.com/document/d/1V_Ukfex8GBknq6rKhq31MIFwPCOnutdA/edit?usp=sharing&ouid=108484208317571215917&rtpof=true&sd=true)，連結可能失效

* UI(介面)物件不能與UI(介面)物件直接互動。
* 活動圖與循序圖介面個數不一致
* 同框架可以合併，用虛線分開
* 框架誤用
* 一定要選一個用 alt
* 可以都不選才用 opt
* UI跟AC名稱要一致
* 介面的生命線無法處理程序，要自己繞到自己須在控制物件生命線上
* 
* 回傳的訊息要經過呼叫他的類別
* 所以ac圖要先確認方法名稱
* Ans：是的，沒確認先寫中文
* 循序圖的編號有什麼意義？
* Ans：意義不大，只有在溝通圖時方便閱讀了解，可參見PPT-11章P43。
* 結帳可以放在opt裡嗎？
* Ans：一般購物車與結帳是分開，因為可以不必馬上結，購物車資料會留存，但妳的商品是購買課程且妳是購物與結帳一起，應該傾向同時結帳，所以不一定要OPT，但如果不結訂單就不成立，資料也不會留存，如果妳留存，也意味後續可結帳，也就表示購物與結帳分開。
* 課程管理裡若要確認身份別可以這樣寫嗎？還是opt中三格都要寫[if老師]，抑或是外面再包一層opt呢？
* Ans：如果整個OPT框架都是老師，自然只有老師符合條件，以較完整的邏輯是如妳說的外面再包一層opt，寫[if老師]，內無虛線，內容原opt中三格有虛線分隔，都不必寫[if老師]。
* 留言管理有需要標示行為者是留言本人才能做編輯、刪除嗎？
* Ans：一般有登入，電腦就會知道是某會員，會是認為會員本人，自然可以依權限行駛會員的權限，超出權限範圍，也自然無法執行；另外老師或管理者應該可以回覆留言。
* 可以有多個entity嗎？
* Ans：是的確實需要用到。
* UI為什麼要有兩個控制焦點？
* 
* Ans：都可以，一個是長一點算是連在一起，跟2個一樣，都表示操作訊息線經過改物件！
* 結帳是否需要畫出先到購物車取資料的步驟？
* Ans：依妳的圖結帳的上一個操作描述是載入購物車，應該不必畫出取資料的步驟，但如果購物車與結帳分開時，結帳就應包含載入購物車。
* `<controll> Class FDouble` 是什麼？看起來像按鈕
* 
* Ans：它是Form 1, 基本上也是一個class。控制類別。

## 類別圖

* 配合投影片13
* [IT鐵人DAY 7－Class Diagram類別圖](https://ithelp.ithome.com.tw/articles/10269231)

類別圖主要用於表達系統內部的靜態結構

* 實體類別(Entity Class)
* 使用個案完成後仍需儲存在資料庫中的資料
* 也可以是暫存的資料，例如(SQL)搜尋結果，當使用個案執行結束後，這些資料也跟著消失。
* 多為永久類別
* 介面類別(Boundary Class)
* 行為者與系統交談的媒介
* 程式執行完畢後，介面類別之物件都將被刪除，因此介面類別屬於暫存類別。
* 控制類別(Control Class)
* 連接邊界類別和實體類別的一種類別
* 大部分是傳送許多訊息給其他類別，或是將工作指派給其他類別
* 一個使用個案至少需搭配一個控制類別，來控制使用個案中事件的發生順序。
* 選擇執行的流程，當有錯誤發生時知道該做什麼
* 屬於暫存類別


關係

* 相依
* 「使用」的關係
* 一個類別會用到其他類別，且被使用之類別的改變可能會影響到使用它的類別，但反之則不必然。
* 使用類別指向被使用類別
* 一般化
* 繼承
* 由子類別指向父類別
* 關聯
* 實現化


### 繪製流程


* 找類別
* boundary：從 **UI 循序圖**對照
* control：從 **AC 循序圖**對照
* entity：從 **AC 循序圖**對照
* 加上屬性
* boundary：從**活動圖**對照
* control：空的
* entity：**資料表欄位**
* 加上方法
* boundary：從**活動圖**，生命線以左(操作者)來的控制焦點對照
* control：從 **AC 循序圖**，該生命線上控制焦點以右(Entity)對照
* 顯示的 control 不會有往右，只有往左
* entity：**資料表 CRUD**
* 加上資料型態