# 高等軟體工程
###### tags: `Note`

## 軟體工程簡介
### 軟體危機
- DEF：軟體開發的速度遠不及軟體的成長速度，因此導致開發成本的提高以及時辰的延誤
- SOL：以工程化的方式引入軟體開發，以解決軟體危機

#### issue
- Unrealistic Deadline
- Vague(不明確) Requirements
- Complex Structure
- Numerous Uncertainties (不確定因素)

#### Fredrick Brooks 提出的軟體本質問題
- Complexity
- 複雜程度與程式大小呈非線性或等比級數遞增
- Changeability 易變性
- 開發到完成，維護，隨時都需要變更
- Invisibility
- 易造成溝通不良
- Conformity 一致性
- 各介面 模組 系統間的介接不一

### 軟體開發活動

- 需求分析 Requirements Analysis
- 客戶需求
- 系統可行性
- 需求的一致性及正確性
- 設計 Software Design
- 將客戶的需求轉換為系統的過程
- Including Architecture, DS, Algorithm, and Database
- 實作 Implementation （Coding）
- 將設計的內容轉化為程式碼
- Debug
- 測試與維護 Testing and Maintence
- 檢測程式是否符合要求及效能
- 「軟題維護」確保軟體系統持續滿足客戶需求

#### 軟體測試<div id="sw_test"></div>

- 單元測試 Unit Test
- 測試單元模組 （class）
- 整合測試 Integration Test
- 測試模組或子系統（sub system）的介面整合
- 系統測試 System Test
- 測試整體系統的效能，安全性，穩定性
- 包含軟硬體
- 接受測試 Acceptance Test
- 系統是否符合使用者需求

#### Activities Common to SW Projects

紅字：Work Product 工作產出

1. Requirements and Specification
- 確認需求
2. Modeling
- Use case modeling
- 描述軟體的功能性
- 以user角度看這些軟體的功能
- Structural modeling
- 描述軟體的資料
- class 繼承 結構 關係 等等
- Dynamic and behavioral modeling
- 描述軟體的行為（動態）
- 藉由屬性method等等如何去描述一個系統的行為
3. Design
- 確定需求如何被正確實作
- System engineering
- 決定硬體與軟體
- System architecture
- 決定子系統及其如何整合
- Internals of subsystems
- 子系統內部設計（演算法 資料結構）
- User interface design
- Database design
4. Programming
5. Quality assurance
- Reviews and inspections
- 靜態測試
- [軟體測試](#sw_test)
- Testing
- 動態測試
- 實際執行，以結果驗證測試
- 白箱 黑箱 測試
6. Deployment

#### Management
- Managing sw configurations
- Version Control
- Managing sw process
- 預估成本（時間）
- planning -> PEP (project execution plan)

### 軟體流程模型

軟體流程模型：定義軟體開發流程指引的抽象樣板
- 瀑布開發 Waterfall Model
- 統合流程 Unified Process
- 極限製程 Extreme Programming, XP

#### 瀑布開發 Waterfall Model


SRS：軟體需求規格書
SDD：系統設計規格書
STD：系統測試報告

瀑布：水往下流，且不往回（往上）流
- 每一階段沒有完成，就不會進入下一階段
- 每一階段的產出（work product）是下一階段的輸入

瀑布式開發時程規劃範例

優點 |缺點 |
-----------|:-----------------------------------------:|
清楚的階段分割| 需求提供者（早期）無法正確及完整的表達需求 |
明確的文件產出| 使用者 系統分析師 系統設計師 程式設計師溝通上的誤解|
null | 使用者需求可能會改變 |

瀑布式開發適合大型專案，且需求變更幅度不大的系統

#### 統合開發 Unified Process
因應物件導向程式語言興起，採用UML為開發方法，提供比起waterfall 更為彈性的開發流程。

以工作流（workflow）貫穿兩個面向
- 時間面向
- 內容面向
- 主要工作流
- 支援工作流


##### 統合流程強調
- 反覆 Iterative
- 系統分析 設計 實作 測試 整合是反覆不斷進行的
- 遞增 Incremental
- 需求可以是逐步漸增的
- 演進 Evolutionary
- 系統是不斷演進的，而非後期建置的

##### 統合流程特色為
- 使用者案例導向 User Case Driven
- 強調使用者價值
- 以架構為中心 Architecture_centric
- 以元件 模組為基礎的架構 component-based approach

##### 時間面向
1. 起始階段
- plan
2. 分析階段
- demand analysis
3. 建構階段
- design, coding and testing
4. 移交階段
- user document

##### 內容面向
1. 企業模組工作流
- Domain analysis
- 了解與評估企業的背景與動機
- 建立溝通管道
2. 需求工作流
- 了解與確認該系統所需的功能
3. 分析設計工作流
- modeling
- design
- DS, algo, database
4. 實作工作流
- model to codes
- unit test
- 可及早發現可能的設計錯誤
5. 測試工作流
- 確認單元可以整合
- 確認單元介面相容
- 可測試到缺失（Defects）
6. 佈署工作流
- release version

##### Construction 階段採回合制，每一個回合都可能檢視需求與設計並修正

##### 每一回合產生minor release以供使用，最後再產生final production release

##### 統合流程開發時程規劃範例

##### 優點
- 具瀑布開發優點，並強調反覆，遞增與演進
- 以使用者觀點，藉由use case diagram確認使用者需求
- 反覆的系統展示與架構檢視減少客戶與系統的落差
- by minor release

#### 極限製程 Extreme Programming, XP
「擁抱改變」

##### 特色
- 客戶駐點
- 隨時溝通
- 快速回饋
- 漸進式規劃
- Story Card
- 頻繁改版
- 簡單設計
- 測試先行
- 事先撰寫單元測試
- Test-driven development (TDD)
- 事先設計測試案例
- 自動化測試

##### 極限製程開發時程規劃範例

##### 優缺點
- 非常具備彈性，較敏捷
- 測試程式若不完整，容易造成危機

## 需求工程
#### 需求是甚麼
-- 描述系統必須做甚麼事情
-- 描述系統有甚麼限制或品質

相關人員：Stakeholders
- 開發人員
- 開發主管
- 客戶
- 使用者

由需求文件(requirements document)確認需求

### 需求種類
對象
- 使用者需求(user requirements)
- 系統需求(system requirements)

軟體功能
- 功能性需求
- 非功能性需求

##### 使用者需求
- 抽象的想法
- 口語陳述為主
- 企業目的為導向

##### 系統需求
- 比較明確
- 文字規格
- 系統導向的思考與分析

*** 軟體需求規格書(System Requirements Specification, SRS) ***

##### 功能性需求
- 指具體提出系統應該提供的服務項目
- 非常明確，只有有或沒有，沒有程度差異

##### 非功能性需求
- 強調系統品質與限制
- 系統的特性
- ex 可靠度 安全性
- 相依於功能性需求
- 快 on 搜尋
- 良好 on 使用者介面
- 使用者關心
- 正確性 可靠性 效率性
- 開發者關心
- 可維護性 可測試性 再使用性
- 不同需求提出者關心的可能有所衝突 ex 效率VS可再使用性

#### 軟體品質
- 產品操作
1. 正確性
2. 可靠性
3. 效率性
4. 整合性
5. 可使用性
- 產品開發
1. 可維護性
2. 可測試性
3. 彈性
- 產品移交
1. 可移植性
2. 再利用性
3. 互助運作性

##### 建議盡量量化非功能性需求，使其成為可測試性的非功能性需求 #####
ex 良好的UI -> 最多2步驟即可完成功能
ex 快速的搜尋 -> 2秒內有搜尋結果

### 需求工程
指 將待開發的系統需求由需求端擷取出來，加以分析及建置，以供開發端依此開發

Process for Developing Requirements

##### Domain Analysis
使SW針對所要開發系統的領域有一定程度的瞭解
ex 銀行 -> 存提款，借貸
domain expert: 銀行經理
- how
- domain expert
- 已存在的軟體及文件
- advantage
- faster development
- better system
- 擴充性

##### 定義問題與範圍
- Problem:
- 遇到的困難
- 改善生產力

*問題描述需短及簡潔*

- scope
- 列出所有系統需要完成的事情
- 移除太廣泛的
- ex 註冊系統 (可以註冊，瀏覽課程，......)
- 也不要定義的太瑣碎
- Ex 考試教室安排，註冊費用繳交(屬於別的系統)

### 需求擷取

如何將使用者需求擷取出來

#### 擷取方法
- 面談
- 最直接，口述
- 問卷
- 客觀，多方面，符合多數使用者的期望
- 使用者觀察
- 實地考察，耗時
- 研討會
- 具經驗的主持人，提前準備，適合系統的使用者來自不同單位或組織
- 腦力激盪
- 創意型的開發
- 使用案例
- 情境思考
- 站在使用者角色思考
- 使用案例（User Case）
- 雛型法(Rapid Prototyping)
- 初步雛型系統視覺化展示以確認需求
- 捨棄式雛型法（Throwaway Prototyping）
- 針對一開始沒有把握的系統需求做確認
- 用完就丟
- 漸進式雛型法（Evolutionary Prototyping）
- 從最有把握的需求開始開發
- 進而擴充其他功能需求
- 不會丟棄

### 需求分析
目的：需求是否
- 正確
- 是否可行，符合企業目標
- 完整
- 是否有遺漏
- 沒有衝突
- 是否有矛盾及衝突

#### 資料流程的分析 （Data Flow Analysis）
- 以系統功能面的角度切入
- 利用 資料流程圖 （Data Flow Diagram, DFD）


- 圈圈：process
- 箭頭：Data flow
- 一個process的output可能是別的process的input
- 資料會儲存到Data Store裡

#### 實體關聯的分析 （Entity Relation Analysis）
1. 實體關聯分析 （Entity Relation Analysis）
- 以系統資料面切入
- 實體資料（Entity）-> 名詞
- Entity Type , ex class
- Entity Instance, ex instance from class
- 關聯（Relation）-> 動詞
- 實體關聯分析圖（Entity Relation Diagram, ERD）
ex 線上考試系統 ERD

- 實體具有許多屬性 Attribute
- 可利用關鍵屬性（Key Attribute）來取得特定的實體
- 關鍵屬性（Key Attribute）：唯一性及不變性
- ex
- 國民（Entity）
- 性別（Attribute）
- 戶籍（Attribute）
- 身份證（Key Attribute）

2. 擴充實體關聯分析圖（Extended Entity Relationship Diagram, EERD）
- 目的：透過實體關聯分析將資料庫裡實體的邏輯內容定義出來
- 針對實體的 1. 2. 做擴充
1. 屬性
2. 關係

- 屬性擴充
- 主要鍵值 Primary Key
- 外部索引鍵值 Foreign Key
- 屬性資料型態 Type
- 寬度 Width
- 可否允許空值 Null OK
- ex 學生實體屬性定義
- 
- 關係擴充
- 選擇性關係（Optionality）
- 可有可無
- ex 修課關係
- 左圖
- 學生可以選不修課
- 課程必須要有學生
- 右圖
- 學生必須要有推薦人
- 

- 生存相依關係（Existence Dependency）
- 描述某一實例是否必須依賴另一實例的存在
- 
- 課程相依於開課班級
- 利用箭頭表示
- 抽象關係 （Abstraction）
- 抽象關係之重疊關係（Overlay）
- 學生可以是運動員，同時也是樂手
- 
- 粗體線段箭頭表示
- 抽象關係之互斥關係 （Mutual Exclusion）
- 只能是其一
- 學生只能是大學生，或是研究生
- 
- 以相交實體（Intersection Entity）來表示多對多的關係
- 學生可以修很多課
- 課程有很多學生
- 
- 多對多實體關係下，特定實體實例之間的對應關係
- 

#### 狀態行為的分析 （Behavior Analysis）
- 狀態轉換圖（State Transition Diagram, STD）
- ex 線上考試簡易狀態轉換圖
- 
- ex 線上考試系統復合狀態轉換圖
- 目的：隱藏一些複雜的狀態
- 

#### 企業流程的分析 （Business Process Analysis）
- 分析作業流程
- 企業流程模組（Business Process Model）
- 流程應考慮不同的組織或角色
- ex 線上考試的企業流程模組
- - 

### 需求規格文件
#### Software Requirements Specification，SRS
- ex 線上考試系統之SRS
- 
- ex IEEE 830 建議的SRS
- 

* 要有version control

### 需求確認與需求管理
#### ==需求確認 Validation==
- 確認定義的需求是不是使用者要的
- 規格書審查
- 雛型展示
- 確認需求之重要性
- Do Right Thing
#### ==需求驗證 Verifiable==
- 設計的系統是否符SRS的規範
- 建立測試案例
- Do Thing Right

#### 需求管理
- 開發中的需求會變更
- 制定及遵循變更的程序
- 需求追溯表(Requirements Traceability Matrix, RTM)
- 水平追溯(Horizontal Traceability)
- 紀錄需求與需求之間的關係
- 

- 垂直追溯(Vertical Traceability)
- 追溯需求的來源與其相對應的程式
- 

## 物件導向與UML
### UML
### 使用案例（Use Case Model）
==Use Case== :以使用者角度出發思考系統功能
- 目的
1. 使用者如何與系統互動
2. 如何達到使用者目的
- 內容
1. full sequence steps
2. user's interaction (不在乎如何系統設計)
3. independent with UI
4. only include actions actor interact with

- ex
1. Bank system
- 
2. Sales report system
- 

- Use Case View 使用案例觀點

- Actor 行為者
- class
- system
- subsystem
- ==outside system interact directly==
- 可以有繼承關係
- 
- 個人與公司都是繼承自銀行客戶

- Use case 使用案例
- a sequence of actions
- relatonship
- Association
- actor與use case的關係
- 非use case間的
- Extend
- use case 與另一 use case 的擴充關係
- 
- 
- 額外的功能，少了並不會導致原use case失去意義

- Include
- 在 use case中常被使用的另一 use case
- 
- 
- reuse 的概念
- 如果沒有pw use case，那提存款等use case就沒有意義了

- Generalization
- use case間的繼承關係
- 少用
- 使用案例規格樣板 (斜體為建議要有，highlight為一定要有)
* ***ID***
* ***Description***
* ==***Actors***==
* Assumptions
* Constraints (使用限制)
* Priority
* Pre-Conditions (執行前須符合之條件)
* Post-Conditions
* ==***Basic Flow (基本流程)***==
* Alternative Flows (備胎)
* Exceptional Flows (意外狀況處理)
* Include Use Cases(其他Use Case)
* Business Rules
* Special Requirements
* Artifacts
* Use Case Glossary
- 

### 類別圖（Class Diagram）
==描述Data==

- Class
- Associations
- class間的關係
- Attribute
- class及instance間的關係
- Operation
- class的功能
- Generalization
- class的繼承
#### Class
1. class 表示法
- 

2. operation 表示法
- 

#### Associations
- 描述class的關係 及 multiplicity(*, 1, 0, ...)
- 
- '*' : zero to more
- Label
- 
- 可具方向性
- 

- Role name
- 腳色
- 

1. many to one

2. many to many

##### Implementation
1. 

2. 

3. multiplicity
- 
- use vector

* 避免 one to one
* 

* default雙向
* 
#### Generalization
- 
- 

#### Aggreation 聚合關係
- whole part
- isPartOf
- whole：擁有者，part：被擁有者
- 
- ex
- 
- when to use
- are part of
- is kind of
#### Composition 組合關係
- strong of aggregation
- 
- *part/whole不存在，whole/part就沒有存在的意義*

#### Interfaces
- class without operaction
- visible behavior
1. 
2. 

#### Note

#### Example
http://140.136.149.35/courses/SoftwareEngineering/2015-10-14-SE-CH3-U03.ecm.mp4/index.html
第22小節

### 動態塑模
#### 互動圖（Intersaction Diagram）
- 動態觀點
- 視覺化
- 從use case 與 class disgram 建立
##### Sequence Diagram 循序圖
- ==時間軸表示==
- class
- 

- actors
- 

- message
- 

- ex
- :有底線就是物件
- 

- 由來
- 
- Object deletion
- 
- Iteration
- loop
- 
- opt
- 
- alt 多選一
- ref: 副函式
- [] : 判斷condition
- 

##### Communication Diagram 溝通圖
- ==class之間的平面關係==
- 好處：一目了然每個class之間的互動
1. 

3. 

###### how to choose
* Sequence diagram
1. 時間軸 base
2. 更多詳細資訊
- return value
- loop

* Communication diagram
1. a project from class diagram
2. validating class diagram
##### 狀態機（State Machine Diagram）
- 元素
- State
- Event
- Transition
- Action
- ex
- 
- time out and condition
- 馬路紅綠燈
- 
- 課程選課階段
- 

- from class
- 
- Activity
- a period of time
- after activity, run into another state
- may be interrupted
- Action
- 立即的改變
- Nested Substate
- 開車換檔
- 

##### 活動圖（Activity Diagram）
- flow of work
- 解讀不同 use case 間的互動
- concurrnt activities
- ex.
- 課程註冊
- 
- Representing Concurrency
- fork
- 一進多出
- rendezvous
- 多進多出
- join
- 多進一出
- ex
- 
- Swimlanes
- 分隔不同腳色的視角
- 適用 business process model
- ex
- 

## 設計樣式（Design Pattern）
### Pattern
- Pattern describes **problem which occurs over and over again**, and then describes the **core to the solution**
- The recurring aspects of the designs are called ==**design patterns**==

#### Elements
* ==Context==
* 在什麼樣的情況下適用什麼pattern
* Problem
* Forces
* 一些需考慮的issue or constraints
* Solution
* Antipattern (optional)
* some patterns will not work
* Related patterns (optional)
* some similar pattern will work
* References
* refer to or being referred

#### Example (物件導向語言)
1. ==Reources Acquisition Is Initialization==
- 把所有初始化都放在constructor做
- complier error instead of running time error

2. Garbage collection
- 每一個 new 必須要有一個 delete

#### 比較
- Idiom
- 特定語言的pattern或技巧

- Design pattern
- 與語言無關的
- design level

- Framework
- partially completed design to solve a problem
- ex. 視窗程式拖拉（填入參數即可）

### Design Patterns

#### Modeling pattern

##### The Abstraction-Occurrence Pattern
- Context
-
- Problem
-
- Forces
-
- Solution
-
- Antipattern (optional)
-
- Related patterns (optional)
-
- References
-
##### The General Hierarchy Pattern
- context
- 物件在一個hierarchy的關係中要如何描述其他objects
- Solution

##### The Player-Role Pattern
- Context
- 物件在不同context 扮演不同角色
- Problem
- 如何model 角色跟物件以使物件可以扮演不同的腳色
- Forces
-
- Solution
-
- Antipattern (optional)
-
- Related patterns (optional)
-
- References

#### GoF Design Patterns
- Three type
##### Creational
- how to new a object
- try to hide the how to
- example

- Factory Method
- Abstract Factory
- 每一種object就是一個只有自己的類別

- Prototype
- 可以產生不同的 object copy 並動態替換
- Builder
- Singleton

##### Structural
- 關注 class 與 object 如何組成一個大的 structure

##### The Adapter Pattern
##### The Façade Pattern
##### The Proxy PatternThe Factory Pattern

##### Behavior