---
tags : 資訊工程導論
title : 資訊工程導論
---
# Module 4 : Software Engineering

## 7.1 軟體工程專業

### Software Engineering
:::success
軟體工程的目的主要是尋找引導大型且複雜軟體系統開發的原則
:::
### The Software Engineering Discipline (軟體工程專業)
:::success
軟體工程所涉及的問題
- 如何估計完成計畫所需要的時間？
- 如何將計畫分成可管理的小計劃？
- 如何確定這些小計劃的產出物能相容？
- 各小計劃的工作人員彼此之間如何溝通？
- 如何估計進度？
- 如何克服包羅廣泛的戲解？
軟體工程專案挑戰
- 成本超支
- 產品延遲交付
- 不滿意的客戶
對這些問題的解決方案
- 找到軟體工程與其他工程之間的差異性
- 開發一般化軟體元件的方法相當困難(複雜的軟體系統向來都是從頭重新打造)
- 軟體度量(metrics)
- 估算開發一個軟體系統的成本(一般都喜歡估計此提議產品的複雜度)
- 估算軟體產品的品質
因此，軟體工程的研究分成兩個層次進行
- 研究人員(實務派) VS 研究人員(理論派)
- 實務派
- 朝向可以立刻應用的方面發展
- 理論派
- 朝向基礎理論研討，主要希望未來可以憑這些理論建立更穩定的技術
- 兩著之間的問題
- 實務派
- 所做的都會因為時間而被取代
- (過去所發展及推行的許多方法是基於主觀的基礎，現在已被其他方式取代，而他們本身早晚也會過時)
- 理論派
- 研究進度緩慢
電腦輔助軟體工程(CASE)工具
* 專案規劃系統 project planning
* 專案管理系統 project management systems
* 文件製作系統 documentation systems
* 雛型建立系統 prototyping and simulation systems
* 介面設計系統 interface design systems
* 整合開發環境 integrated development environment
* 專業及標準制定的組織
- 計算機協會 (ACM),電機電子工程師協會 (IEEE),ISO
- 專業行為
- 倫理規範

:::

### In-Class Exercise 4.1 試問是否有什麼方法可以計算程式元件(a unit of software)中的錯誤個數？
:::info
使用一段固定時間後所發現的錯誤數量如何？
在此有一個問題是此數值無法預先量測的
:::

## 7.2 The software life cycle 軟體生命週期
整體週期
軟體工程的最基本的觀念是軟體生命週期
### The software life cycle
:::success
Use(使用)階段
* 建置與使用軟體
Maintenance (維護)階段
* 維修
* 更正或更新
- 尋找錯誤
* 問題
- 如果在開發階段做得不好，需要付出很多努力
Development(開發)階段
* 因此，軟體供稱的大部分研究，著重於軟體生命週期中的開發階段傳統的發展階段
* 需求包括
- 規格、設計、建置與測試
:::
### Requirements Analysis Stage 需求分析階段
:::success
主要目的
* 確認所提議建構的系統該提供哪些服務
* 指認出這些服務的限制條件
* 定義出外界將如何與此系統互動
意圖(goals)
- 涉及利害人關係(stakeholder)
- 未來使用者
- 從一個只診對使用著而做的可行性研究開始
- c.f.COLTS(commercial off-the-shelf)
- 包括編譯和分析軟件用戶的需求
- 調諧專案個利害關係人之間對於
- 需求
- 成本
- 可行性的差異
- 產生一套能夠指出最後完成的軟體系統，必須具有的各種特性及服務功能的需求
- 這些需求被記錄在軟體需規格書(software requirements specification document)
- 此文件式所以相關單位間的書面協議，其目的是引導軟體的開發，且提供解決稍後在發展過程中，可能發生爭議的一種方法
:::
### Design Stage
:::success
所提議的系統產生一套建構的計畫
發展出解決問題的方法
決定系統將如何做到
意圖(goals)
- 設計階段結果就是軟體系統架構的詳細描述，而這些可被轉化成各種程式
- 使用圖表和建模工具
- 方法和工具 (稍後討論)
- 人機介面 (心理學和人體工程學)
:::

### Testing Stage
:::success
相當於對所以程式做除錯
確認最終的軟體產品與軟體需求規格相符
許多軟體工程師主張測試不應在被視為軟體開發中的獨立步驟，而應被植入其他步驟中，產生一個三步驟的開發過程，其中元件可能會被稱為
* 需求規格及確認(requirement specification and confirmation)
* 設計及驗證(design and validation)
* 建置及測試(implementation and testing)
:::

### In-Class Exercise 4.2 軟體生命週期的開發階段對於維護階段會有什麼樣的影響?
:::info
開發時多投入一點的力量，將在維護時有極大的回報
開發時多做點準備，在維護時可以不用那麼累
e.x. 寫專案時 在開發階段 對所有 function 都寫一個註解之後維修就能看懂
:::

## 7.3 軟體工程方法論
:::success
Software Engineering Methodologies
* 瀑布模式(幻燈片)
- 開發過程只允許單一方向的思考
* 最先進的
- 漸進模式(Incremental model)
- 在漸進開發模式下，一個完整的系統，由雛型經過 演進式雛形(evolutionary prototyping) 而逐漸完成的
* 反覆模式(Iterative model)
- 例子: Rational 統一流程(RUP)
- 這種重複過程所建立的雛型被捨棄，而只採用隊最終設計重新製作的解果，這種方法稱為 捨棄式雛形(throwaway prototyping)
- 捨棄式雛形法是一個 快速塑模(rapid prototyping) 的概念
* 開放原始碼方式(open-source development)
- 一個已經被電腦玩家使用多年的演進式雛形的一種變形
* 高彈性方法(Agile method)
- 高彈性方法其中的每種方法都主張在早期快速地建立起一個漸進式的基礎，對需求的變化立刻回應，並主張降低對嚴密需求規格與設計的依賴。
- 例子: 極限程式設計方法(extreme programming, XP)

:::

### In-Class Exercise 4.3 試問傳統演進是原型化與開放原始碼開發法有何差異?
:::info
傳統的演進式雛型建立是在開發軟體的組織內進行，而開放原始買開放模式則不限於一個組織。
在開放原始碼開放模式的情況下，負責監督開發工作的人，並不需要決定有哪些地方被強化，然而在傳統演進式雛型建立負責管理軟體開發的人需指派人力給特定的強化工作
:::

## 7.4 Modularity Outline 模組化
### Modularity Outline 模組化大綱
:::success
* 模組實作
* 外連
* 內聚
* 資訊隱藏
* 元件
:::

### Modularity Implementation 模組實作
:::success
* 將軟體分成許多可管理的單元(模組化)
* 每一個單元只對付軟體全部工作的一部分
:::
### Modularity Implementation 模組實作
:::success
* 各種形式
- 命令式方法(函數)
- 結構圖
- 並未指出每個程序如何執行其任務
- 他指示指出有哪些程序及程序之間的關聯性
- 模組 -> 函數(元件)
- 物件導向方法(物件)
- 類別(Class)圖
- 循序圖
- 模組 -> 物件(元件)
- 物件導向設計方法則用物件作為基本的模組元件
- Component assembler
:::

### Coupling versus Cohesion 外連 與 內聚 差異
:::success
* 外連
- 控制外連
- 資料外連
* 內聚
- 邏輯內聚
- 功能內聚
:::

### Coupling 外連
:::success
* 當設計模組系統，應該是將獨立性最大化，或者將模組間的連接(外連)最小化
* 被用來度量一個軟體系統複雜度的尺度，就是去量測其模組間的外連程度
* 模組之間連接方式
- 控制外連
- 一個模組將控制權交給另一個模組
- 例如:程序之間的呼叫
* 資料外連
- 指模組間資料的共享
- 程序間的資料外連可以兩種型式發生
- 以參數的形式明顯地從第一個程序傳遞資料到另一格程序
- 以廣域資料(global data)的形式，隱含地模組間分享資料
- 問題
- 在於一個人試圖修改一個依賴廣域資料的模組，可能會發現要指出發生問題的模組，與其他模組如何互動困難重重。
- 簡言之，使用廣域變數會減低該模組作為抽象化工具的用途
:::

### Cohesion 內聚
:::success
* 盡量加大模組的內部束縛
* 盡量減少模組之間的外連
* 內聚 指模組內各部分的相關程度
也就是說，軟體設計者也必須努力於模組內的高度內聚
* 內聚分為兩種
- 邏輯內聚
- 廣義的內聚
- 為模組內部個單元應該自然地執行相類似的任務而造成的內聚
- 一個執行系統與外界的所有通訊模組
- 功能內聚
- 狹義的內聚
- 為模組內的所有部分都是專注於單一的行為
- 物件導向設計概念
:::
### Information Hiding 資訊隱藏 (模組化的要領之一)
:::success
* 概念是指將資訊限制在一個軟體系統的特定部分

* 資訊vs封裝

* 資訊包括

- 資料
- 資料結構的類型
- 編碼系統
- 模組內部組成結構
- 某依程序單元的邏輯結構
- 某一模組內部特質
* 資料隱藏的目的

- 在於避免模組的動作對其他模組產生不必要的關聯或效應
- 例子(避免發生)
- 如果一個模組不限制其他模組對內部資料的取用，資料可能會被其他模組破壞
- 如果某個模組被設計成需要利用其他模組的內部結構，或稍後該內部結果如果有所改變，就可能導致故障
* 資訊隱藏 的雙重意義

- 設計目標
- 一個模組被設計成其他模組不需要取用其內部資訊
- 擴大其內聚而減低外連
- 建置目標
- 一個模組應被以能固守其界限的方式來建置
- 涉及區域變數的使用、應用封裝、以及使用定義嚴謹的控制結構
* 資訊隱藏 (抽象化)

- 抽想化工具的觀念就是黑箱(black box)的概念
- 資訊隱藏就相當於以相似於一個防止擅自撕開的標籤，可以用來保護複雜又潛存危險的電子設備一般，可將抽象化工具封存起來的概念

:::

### Components 元件
:::success

* 先前提到在軟體工程的一個障礙，就是缺乏一些預先製作好的「可隨時取用」的原件，以供建構大型軟體系統
* 對於物件導向式程式語言都附隨著一大堆讓程式設計師能夠簡易地建造擔任特定角色物件的預製「樣板」
- C++ 的 STL
- Java 的 API
- C# 的 .NET
* 因此，一個物件其實是一個更依般化概念的特例，此概念就是元件(componet)，一齊定義，他就是軟體可再使用的單元
- 在實務上，大多數元件是基於物件導向方法，其中每個元件形式上是一個或一群功能上自足的單元
:::

### Component Architecture 元件架構
:::success
* 又稱為餘件事軟體工程 (component-based software engnieering)
- 元件組合師(Assembler)
- 他們以預製的元件建構軟體系統(以圖像顯現在圖形化的介面中)
- 元件組合師的方法，是由一群預製的原件中選擇住要的元件，然後做最少的改變，而基他們連接獲致想要的功能
:::

### In-Class Exercise 4.4 試定義耦合(外連)、內聚與資訊隱藏
:::info
外連是指模組之間的連結。
內聚則是模組內的連接性。
資訊隱藏則是對資訊的分享做限制。
:::

## 7.5 Tools of the Trade
:::success
* 資料流向圖(Data Flow Diagram)
* 資料辭典(Data Dictionary)
* 統一塑模語言(UML)
:::

### Data Flow Diagram 資料流向圖
:::success
* 雖然命令式方法(imperative programming paradigm)試圖以程序來打造軟體，而指認出這些程序的方法是去考量要被處裡的資料，而非程序本身。
* 軟體開發設計階段(design stage)
- 協助指認出各個程序
* 軟體開發分析階段(analysis stage)
- 試圖瞭所提議的系統
* 建構流向圖，可作為改善客戶與工程師溝通的一個方法
:::
### Data Dictionary 資料辭典
:::success
- 資料辭典
- 軟體系統中出現的所咬鄒凹料項目的中央資訊儲存式(repository)
- 識別字
- 數值
- 字母
- 數值範圍
- 處存何處
- 軟體的那些地方會處存資料
- 目標
- 該善軟體系統淺在使用者與被賦予(即)將使用者的需要，轉乘需求及規格的軟體工程師之間的溝通
- 建立系統整體的一致性
- 重複
- 在存貨紀錄中 PartNumber 所指的資料可能與銷售紀錄中的資料 PartID 相同
- 矛盾
- 人士專門不可能使用Name表示員工
- 存貨紀錄可能使用Name表示零件
:::

### UML(Unified Modeling Language)
:::success
* Use case diagram 用例圖
- Use cases (用例)
- 或譯使用案例、用況，是軟體工程或系統工程中對系統如何反應外界請求的描述，是一種通過用戶的使用場景來獲取需求的技術。 每個用例提供了一個或多個場景，該場景說明了系統是如何和最終用戶或其它系統互動，也就是誰可以用系統做什麼，從而獲得一個明確的業務目標。
- Actors (參與者)
* 用例圖
* Class diagram 類別圖
- Entity-Relationship Diagram 實體關關係圖
- One-to-one relation 一對一關係
- One-to-many relation 一對多關係
- Many-to-many relation 多對多關係
- Generalization 廣義化/Inheritance 繼承
- 缺點:
- 相互偶合關係增加;對於保養的步驟不好
- 舉例:實施概括的情況僅限於不可變物件
* Interaction diagrams 相互圖
- Sequence diagram 順序圖
- CRC(class-responsibility-collaboration)cards
- 根據上面的描述
- 模擬"戲劇"實驗的角色扮演
- Strutured walkthrought 結構化演練
:::

### CRC Card
:::success
* CRC 代表 Class(類別),Responsibility(責任),and Collaboration(合作)
- Class (類別): A 使對象分享共同的結構體及共同的行為 involved

- Super-class : 一個類別來自另一個類別的繼承
- subclass : 一個類別的繼承來自一個或更多的類別
* Responsibility (責任) : 對一些行為追究責任
* Collaboration (合作) : 過程對一些合作對象去提供一些更高層次的行為
* CRC Card Example
* 
:::

### Design Patterns 設計模式
:::success
* 精心設計"範本"去解決翻覆發生的問題
* Examples
- 配接器模式:使用適配器的模組介面來滿足當前需求 (via wrapping 透過包裝)
- 修飾器模式:當有許多不同的組合需要同時行動需求時，用來控制涉及的複雜性
* 被 Christopher Alexander 的建築所啟發
* 反映了今日的軟體開發包
- Java 程式編譯環境由 Oracle 提供
- .NET Framework 由 Microsoft 提供
[設計模式 維基百科](https://zh.wikipedia.org/wiki/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F_(%E8%AE%A1%E7%AE%97%E6%9C%BA))
:::
## 7.6 Quality Assurance 品質保證
:::success
* 避免
- 故障、成本超支、錯過最後期限
* 範圍包括:
- 最初是為了去除程式的錯誤(實作階段)
* 後來擴展去改善軟體工程的程序，發展培訓課程(認證)，及建立標準(ISO,IEEE,AMC IEC)
* 軟體品質保證 SQA(Software Quality Assurance)確保這件事情發生
* 任務
- 記錄管理 (有據可查，以備將來參考)
- 用來複查(IEEE標準去做審查)
- 要求審查，設計審查，實作審查。
:::
### Software Testing 軟體測試
:::success
* 演算法的正確驗算方式(如本章 5 6)
* 為什麼需要軟體測試策略?
- 我們無法保證一個軟體是完整通過測試除非我們能夠跑出足夠的情景
- 然而,在簡單的程式裡有許多可能的情景，更不用說在複雜的程式
:::

### Software Testing Strategies 軟體測試策略
:::success
* Glass-box testing (玻璃箱測試) (測試人員知道軟體的內部結構設計測試)
- Pareto principle (帕累托法則)
- 結果可以增長快速的狀態由集中空間努力
- Basis path tseting (基礎路徑測試)
- 可以保險每條在軟體的指令測試數據集以確保每一條都有被執行至少一次
* Black-box testing (黑箱測試) (測試員對關於軟體的內部構造一無所知)
- 邊值分析
- 包括確定軟體應以類似方式執行的數據範圍（等效類），然後在接近那些範圍邊緣的數據上測試軟體。
- Alpha 測試
- Alpha版本通常會送到開發軟體的組織或某群體中的軟體測試者作內部測試。在市場上，越來越多公司會邀請外部客戶或合作夥伴參與其測試。這令軟體在此階段有更大的可用性測試。
- Beta 測試
- Beta版本是軟體最早對外公開的軟體版本，由公眾（通常為公司外的第三方開發者和業餘玩家）參與測試。
:::

## 7.7 Documentation 文獻資料
:::success
* 重要的軟體工程主題
- 使用者的文獻資料
- 去說明這軟體的特徵及描述如何去使用它
- 印刷書籍給所有顧客
- 線上幫助模組
- 系統文獻資料
- 去描述軟體內部結構以便在軟體生命週期以後可以維護
- 原始碼
- 設計文件
- 技術文獻資料
- 安裝，定制，更新，等等
- 描述如何服務系統組件
:::

## 7.8 Human-Machine Interface 人機介面
:::success
* 如何讓人及機械互相作用是在成功的軟體系統非常重要
* 設計便利的給人們
* 使使用者有深刻的印象
- 對於使用者，易用性比功能性更為重要
* 不斷成長的軟體工程領域
- 人體工程學，cognetics(認知)
* GOMS [goals(目標)，operators(經營)，methods(方法)，selection rules(選擇規則)] 模式，1954
- 人機介面設計公制
- 人類行為的基本特徵，像是動手或是做決定
- 注重人們的特點人機介面設計
:::
### Software Ownership 軟體所有權
:::success
* Copyright 版權
- 允許產品在發布後保留知識產權在所有權
- 主張所以作品(使用法律(版權)聲明)
- Requirements Specifications 需求規格
- Design statements 設計陳述
- Source code 原始碼
- Test plans 測試計畫
- Final product 最終產品
* Software License 軟體執照
- 一個法律協議給予使用者一些權限但沒有轉讓所有權
* Patents 專利
- 必須演示它是新的，可用的，以及沒有其他類似背景的
- 處理是昂貴且耗時
:::
# Module 5:Data Abstractions
## 8.1 Basic Data Structures 基本資料結構
:::success
* Arrays 矩陣
- Dimension 大小
- indices 指標
* Aggregate Type 聚合型
- Field 型態
* List(head/tail)清單(頭/尾)
- Stack(top/bottom(base)) 堆疊(頂點/底部(基底))
- Backtracking 回溯法
- LIFO Last In,First Out 後進先出法
- Pop/push
:::
### Terminology for a tree 術語樹
:::success
* tree
* node
* root node
* terminal or leaf node
* parent
* child
* ancestor
* descendent
* siblings
* binay tree
* subtree
* depth/height
:::
#### In-Class Exercise : 8.1
:::success
假設某個樹中有四個節點A, B, C 和D，若A
和C 是兄弟節點，D 的父節點是A，試問哪
些節點為葉節點？哪個節點是根節點？
:::info
:::
## 8.2 Related Concepts 相關概念
:::success
* Abstraction 抽象化
* Static vs Dynamic Structure 靜態結構VS動態結構
* Pointer 指標
:::
#### In-Class Exercise : 8.2
:::success
1. 試問陣列、串列、堆疊、佇列和樹等資料
結構的抽象化意義為何？
2. 試描述在什麼樣的應用中你會想到使用靜
態的資料結構？試描述在什麼樣的應用中
你會想到使用動態的資料結構？
:::
## 8.3 Storing Arrays 處存陣列
:::success
* 矩陣會放在記憶體的特定位址
* Row-majororder versus column majororder
* 位址多項式
- x+(c(i-1))+(j-1)
- If A8x5, then A[3,4]=5 的位址?
:::