軟體工程課程

tags: `Tech Note` `課程` `2019` `軟體工程`

Homework

Homework 1

Process Models
1. Describe the characteristics of the plan-driven and agile processes.
  
  Plan-driven 方法的特性
  - 以Artifact和 milestone為導向
  - 文件是非常正式和結構化
  - 規劃的週期是非常正式的，並且持續進行
  - 很多專案的活動或儀式
  - 會有較多的Team meetings，以及正式的project reviews，和詳細紀錄的status reports
  - 需要經過Change Control Boards來做change control
  - 專案每個stage都需要經過正式approval才能到下個stage
  - 詳細定義專案每個角色的責任
  - 開發的iteration通常比較長，然後次數較少(都常要數個月，或是數季，或是更多)
  Agile 方法的特性
  - Code-based 為主的交付導向
  - 以人為主的非正式溝通，但是次數很頻繁
  - 初次規劃是非常正式，但是之後會依需求來持續規劃
  - 較少的專案儀式或活動
  - 較少的team meetings，project review，也沒有很詳盡的status reports
  - 較少專案的stage需要經過正式approval才能到下個stage
  - 開發的iteration通常比較短，然後次數較多(都常要幾天，或是數週)
2. Draw and describe the major activities of the waterfall process.
  Image Not Showing Possible Reasons
  - The image file may be corrupted
  - The server hosting the image is unavailable
  - The image path is incorrect
  - The image format is not supported
  Learn More →
  1. 需求分析及定義(requirements analysis and definition)
  2. 系統及軟體設計(system and software design)
  3. 實作及單元測試(implementation and unit testing )
  4. 整合及系統測試(integration and system testing)
  5. 操作及維護(operation and maintenance
3. Draw and describe the major activities of the Scrum process.
  Image Not Showing Possible Reasons
  - The image file may be corrupted
  - The server hosting the image is unavailable
  - The image path is incorrect
  - The image format is not supported
  Learn More →
  - 大綱：
    - 3種角色、4個會議、3項產出：
      - 3種角色：Scrum教練、產品負責人和團隊。
      - 4個會議：衝刺規畫會議、每日站立會議、衝刺審查會議以及衝刺回顧會議。
      - 3項產出：產品待辦清單、衝刺待辦清單和燃盡表。
  - Scrum的3種角色
    在Scrum敏捷開發中，提出了3種主要的角色，分別說明如下
    - 產品負責人（Product Owner）：其實，產品負責人這個角色有點像是客戶代表。
      - 他會站在比較接近客戶的立場，去設定產品待辦項目的優先順序，以及為團隊說明客戶的需求。
    - Scrum教練（Scrum Master）：顧名思義，Scrum教練必須熟知整個Scrum敏捷開發，以便能夠協助產品負責人和團隊的運作。
    - 團隊（Team）：就是一般的開發團隊，通常是跨職能的組成，也就是團隊成員混合著架構師、分析師、設計師、程序員、測試員等等。
  - Scrum的4個會議
    在每一個衝刺（Sprint）期間，除了團隊需要實際執行分內的任務外，Scrum還定義了4個重要的會議，分別簡單敘述如下
    - 衝刺計畫會議（Sprint Planning Meeting）：每個衝刺期間的一開始必須先舉行衝刺計畫會議，主要用來決定該衝刺期間的待辦項目，以及團隊的衝刺任務。
    - 每日站立會議（Daily Standup Meeting）：衝刺期間的每一天早上，都要執行15分鐘的站立會議，主要可以用來了解團隊的工作執行狀況。
    - 衝刺審查會議（Sprint Review Meeting）：每個衝刺的最後一天會先執行衝刺審查會議，隨後執行衝刺回顧會議。
      - 在衝刺審查會議中，主要用來展示並了解該衝刺的待辦項目達成狀況。
    - 衝刺回顧會議（Sprint Retrospective Meeting）：相較之下，前述的衝刺審查會議，其討論的主題鎖定在「產品」上頭。
      - 而此處的衝刺回顧會議，其討論的主題則聚焦在團隊的「開發程序」上頭，主要用來討論並調整下一期衝刺的開發程序。
      - 在物件導向技術中，建議採用反覆式的開發方式，而不是過去的瀑布式開發方式。
      - 簡單來說，所謂的反覆式的開發方式是指，在一小段的反覆期中，執行了分析、設計、實作、測試等等的開發步驟，以便迅速地修訂錯誤。
      - 而在Scrum敏捷開發中，同樣採用反覆式的開發方式。不過，在物件導向技術中，稱為這樣的一小段時期為一個「反覆」（Iteration，也有另一個常見的譯詞為「循環」）。
      - 到了Scrum敏捷開發中，則稱為一個「衝刺」（Sprint， Sprint Iteration）。
  - Scrum的3項產出
    在Scrum敏捷開發中，一共有3項重要的產出，分別簡述如下
    - 產品待辦清單（Product Backlog）：其實，產品待辦清單的概念很簡單，它主要包含了一般常見的功能性需求和非功能性需求。
      - 不過，比較特別的是，它還包含了技術團隊提出的需求，而不只是照顧到客戶的需求而已。
      - 因此，Scrum敏捷開發特別採用了「產品待辦清單」（Product Backlog）的字眼，用來跟傳統作法上只照顧客戶的系統需求，做字面上的分野。
    - 衝刺待辦清單（Sprint Backlog）：衝刺待辦清單中的待辦項目，其實是產品待辦清單的子集。
      - 在每一次的衝刺規畫會議中，才會開會決定要處理哪些待辦項目。
    - 燃盡圖（Burndown Chart）：簡單來說，我們可以繪製燃盡圖，來呈現一個時間區段中，剩餘的工作量。
      - 所以，有些文章或書籍中，也將「Burndown Chart」中譯為「剩餘工作圖」或者是「剩餘時間圖」，原因正是如此。
4. Describe the differences between the plan-driven and agile process models in terms of their philosophy and applications.
  - Plan-driven 和 Agile的相同點：
    - 都是提供processes，tools和techniques。
    - 都要求以有紀律的方法來做軟體開發。
  - Plan-driven 和 Agile 不同之處：
    - Agile：
      - Agile方法所適合的狀況，對plan driven來說可能不合適。
      - agile對軟體開發來說，仍然是有紀律的方法. 但是它和plan driven所強調的面向不同，所以它並不是一團混亂。
      - Agile方法強調continual informal communications，以及快速反應change和不確定性的能力，所以本質上是希望能多一點adaptive
      - Agile的擁護者認為plan dirven的方法不夠彈性，緩慢，不能夠及時反應change。
    - Plan driven：
      - Plan driven 強調formal communications and control，也就是本質上強調希望能夠多一點predictive。
      - Plan driven的擁護者認為agile是很混亂，沒有管理，不受控制。
    - 但是若每個方法能被適當的執行，這些爭論不不會存在，因為同樣都能達到很好的效果。
    - 所以重點應該是了解它們各自的優缺點，以及適用的時機，看看是否符合你目前專案的需求。
  plan driven作的好的經理，同樣也能把agile方法做的好。
  plan driven作不好的經理，通常也無法把agile方法做的好。
CMMI
1. What is CMMI？
  - CMMI(Capability Maturity Model Integration)將軟體開發流程視為一種工程(製造)流程。
  - CMMI列出了25個流程領域（process areas）。
  - 這25個流程領域分布於每個階段。
    - Level2 有7項：
      1. 需求管理（Requirements Management）
      2. 專案規畫（Project Planning）
      3. 專案監控（Project Monitoring and Control）
      4. 供應商協議管理（Supplier Agreement Management）
      5. 度量與分析（Measurement and Analysis）
      6. 流程與產品品質保證（Process and Product Quality Assurance）
      7. 建構管理（Configuration Management）。
    - Level3 的流程領域有14項：
      1. 有需求發展（Requirements Development produces）
      2. 技術解決方案（Technical Solution）
      3. 產品整合（Product Integration）
      4. 驗證（Verification）
      5. 確認（Validation）
      6. 組織流程專注（Organizational Process Focus）
      7. 組織流程定義（Organizational Process Definition）
      8. 組織訓練（Organizational Training）
      9. 整合的專案管理（Integrated Project Management）
      10. 風險管理（Risk Management）
      11. 決策分析（Decision Analysis）
      12. 解決方案（Resolut）
      13. 適於整合之組織環境（Organizational Environment for Integration）
      14. 整合團隊合作（Integrated Teaming）
    - Level4 有2項：
      1. 流程領域為組織流程績效（Organizational Process Performance）
      2. 數量化專案管理（Quantitative Project Management）
    - Level5 有2項：
      1. 組織創新與推展（Organizational Innovation and Deployment）
      2. 原因分析與解決方案（Causal Analysis and Resolution）
2. What is it used for？
  - 利用控制、量測、改善(control，measure，and improve)等循序漸進的方法，達到軟體流程改善的一個框架。
  - 利用能力（Capability Model）和成熟度（Maturity Model）分別是組織針對單項或全面性的評估，一般組織都以後者作為努力目標。
  - 成熟度是指在特定專業領域中，預測組織未來績效表現的方法，隨著每一階段的進步，流程領域複雜性會增加，凌群建議，專注於一組可掌握的流程領域，可提高未來績效表現。
3. What is CMMI staged representation？
  - 以階段來分別：
    - ML 1 (initial)：企業有開發軟體產品的能力，但掌控專案時程、成本、流程的能力不佳。
    - ML 2 (managed)：具備ML 1的能力，且對於專案的需求、流程、產出物具有管理能力，能在特定時間點(如專案里程碑到達時)交付產出物。但流程則可能因專案而異，仍未加規範。
    - ML 3 (defined)：具備ML 1、ML 2的能力，且企業對常用的流程以及其修改方式均加以定義。因此，雖專案採用流程可能有所不同，其不同處均被清楚定義。
    - ML 4 (quantitatively managed)：具備ML 1、ML 2、ML 3的能力，且以統計方法進行流程控管，了解其實施作法的變異性，以供採取因應措施。
    - ML 5 (optimized)：具備ML 1、ML 2、ML 3、ML 4的能力，且具有調整與修正流程的能力，使其達到最佳化。
  - 依性質來分：
    這些PA分屬於流程管理、專案管理、工程、與支援等四大類
    - 流程管理：CMMI的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。
    - 專案管理：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。
    - 工程：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。
    - 支援：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。
4. Explain the advantages of implementing CMMI.
  - CMMI有連續式(continuous)與階段(staged)式兩種表示法。
  - 採用連續表示法者，可依據企業軟體開發的實際需求，自由選擇為數恰當且最相關的PA進行導入工作。
  - 採用階段表示法者，則須依據SEI規範，在一期間內同時導入若干相關PA。
  - 在連續表示法中，每一PA執行程度被規範成0至5等六個能力等級(capability level)。
  - 在階段表示法中，則有1至5等五個成熟等級(maturity level)。
  - 連續表示法近似於循序漸進的流程改善(同一時間僅處理少數PA，逐級推升能力等級)，而階段表示法則較屬於跳躍式的流程改善(同一期間內處理多個PA，同步達到該成熟等級所規範PA所需達到的能力等級)。
  - 由於階段表示法的成熟等級相當容易描述並能簡短的表達企業軟體開發能力，採用者較多。
Other process models
1. Draw and describe the major activities of the Unified Process (UP).
  - 統一軟體開發過程（RUP）又稱為統一軟體過程，是一個面向對象且基於網路的程式開發方法論。
  - 根據Rational(Rational Rose和統一建模語言的開發者)的說法，好像一個線上的指導者。
  - 它可以為所有方面和層次的程式開發提供指導方針，模版以及事例支持。
  - 統一軟體開發過程和類似的產品，如面向對象的軟體過程（OOSP），以及OPEN Process都是理解性的軟體工程工具，把開發中面向過程的方面（例如定義的階段，技術和實踐）和其他開發的組件（例如文檔，模型，手冊以及代碼等等）整合在一個統一的框架內。
  六大經驗
  1. 迭代式開發。
    - 在軟體開發的早期階段就想完全、準確的捕獲用戶的需求幾乎是不可能的。
    - 實際上，我們經常遇到的問題是需求在整個軟體開發工程中經常會改變。
    - 迭代式開發允許在每次迭代過程中需求可能有變化，通過不斷細化來加深對問題的理解。
    - 迭代式開發不僅可以降低項目的風險，而且每個迭代過程以可以執行版本結束，可以鼓舞開發人員。
  2. 管理需求。
    - 確定系統的需求是一個連續的過程，開發人員在開發系統之前不可能完全詳細的說明一個系統的真正需求。
    - RUP描述瞭如何提取、組織系統的功能和約束條件並將其文檔化，用例和腳本的使用以被證明是捕獲功能性需求的有效方法。
  3. 基於組件的體繫結構。
    - 組件使重用成為可能，系統可以由組件組成。
    - 基於獨立的、可替換的、模塊化組件的體繫結構有助於管理複雜性，提高重用率。
    - RUP描述瞭如何設計一個有彈性的、能適應變化的、易於理解的、有助於重用的軟體體繫結構。
  4. 可視化建模。RUP往往和UML聯繫在一起，對軟體系統建立可視化模型幫助人們提供管理軟體複雜性的能力。
    - RUP告訴我們如何可視化的對軟體系統建模，獲取有關體繫結構於組件的結構和行為信息。
  5. 驗證軟體質量。
    - 在RUP中軟體質量評估不再是事後進行或單獨小組進行的分離活動，而是內建於過程中的所有活動，這樣可以及早發現軟體中的缺陷。
  6. 控制軟體變更。
    - 迭代式開發中如果沒有嚴格的控制和協調，整個軟體開發過程很快就陷入混亂之中，RUP描述瞭如何控制、跟蹤、監控、修改以確保成功的迭代開發。
    - RUP通過軟體開發過程中的製品，隔離來自其他工作空間的變更，以此為每個開發人員建立安全的工作空間。
2. Draw and describe the major activities of the spiral model.
- 螺旋模型是一種演化軟體開發過程模型，它兼顧了快速原型的疊代的特徵以及瀑布模型的系統化與嚴格監控。
- 螺旋模型最大的特點在於引入了其他模型不具備的風險分析，使軟體在無法排除重大風險時有機會停止，以減小損失。
- 同時，在每個疊代階段構建原型是螺旋模型用以減小風險的途徑。螺旋模型更適合大型的昂貴的系統級的軟體應用。
一個典型的螺旋模型應該由以下的步驟構成：
1. 明確本疊代階段的目標、備選方案以及應用備選方案的限制。
2. 對備選方案進行評估，明確並解決存在的風險，建立原型。
3. 當風險得到很好的分析與解決後，應用瀑布模型進行本階段的開發與測試。
4. 對下一階段進行計劃與部署。
5. 與客戶一起對本階段進行評審。
Theory and Practice

我們的團隊決定採用敏捷開發，主要原因如下：

Responding To Change
Accepting Uncertainty
Faster Review Cycles
Greater Flexibility In Releasing Features
Less Up-Front Work

敏捷團隊共享協作文化，當每個人對於Project的認知與實作能力差不多時，效率往往會比較高。

而當團隊進入穩定的開發時，就可更好的預測軟體開發的各項計畫，使敏捷開發的團隊在工作效率上較高。

我們的團隊在實務上經驗不足，且軟體工程背景不深，若採用Plan-driven的做法的話，很可能會因前期規劃不佳導致中後期要一直不停的修正錯誤導致浪費效率。
在技術層面：
我們採用網頁的設計，以PHP+MySQL+Apache為主要的網頁架構，本團隊在網頁開發經驗不多，以這三者為主體的開發方式較適合入門，且開發環境容易架構且免費。

Homework 2

Consider the requirements engineering process.
1. Describe the major requirements engineering activities.
  
  是一個收集和定義系統提供的服務的過程。
  需求工程流程包括以下主要活動：
- 需求獲取或需求誘導、需求啟發
  - 開發者和利益相關者見面，後者詢問他們對軟體產品的需求和要求。
  - 知識來源於各方面包括客戶、業務手冊資料、相同類型的現有軟件、標準和項目的其他涉眾。
  - 用於需求啟發的技術包括訪談，任務分析，原型設計等。
  - 擴大了分析人員的知識範圍，從而有助於為下一階段提供輸入。
- 需求分析和交涉、需求規範
  - 此活動用於生成正式的軟件需求模型。
  - 這些模型總共指定了包括『功能性』和『非功能性』需求以及『約束』在內的所有需求。
  - 此階段使用的模型包括ER圖，數據流程圖（DFD），功能分解圖（FDD），數據字典等。
- 系統建模、需求驗證和確認
  - 一些工程領域（或特殊情況）要求產品在其施工或製造開始之前被完全設計和建模，因此，必須提前執行設計階段。
  - 驗證：它是指確保軟件正確實現特定功能的一組任務。
  - 驗證：它是指一組不同的任務，這些任務可確保已構建的軟件可追溯到客戶需求。
  - 需求應與所有其他需求保持一致，即兩個需求之間不應相互衝突。
  - 這些要求應該在各個方面都完整。
  - 這些要求實際上是可以實現的。
- 需求管理
  - 需求管理是分析，記錄，跟踪，確定需求的優先順序並達成一致並控制與相關利益相關者的溝通的過程。此階段照顧需求的不斷變化的性質。
  - 應該確保SRS盡可能可修改，以便在以後的階段中也納入最終用戶指定的要求變更。
b.Draw an activity diagram to explain the process of requirements change management.
- 當需求於專案執行期間漸進發展時，管理需求的變更。
- 有關維護和控制需求基準，並使需求及其變更資料能為專案運用，請參考建構管理流程領域，以獲得更多資訊。
- 在專案執行期間，造成需求變更的原因甚多。
- 當需要改變或工作進行中衍生新需求時，就可能需要變更現有的需求。
- 如何有效率和有效果地管理這些新增需求或變更需求是很重要的。
- 要有效分析變更所造成的影響，必須知道每一需求項目的來源，並記錄變更的原因。
- 專案經理或許要追蹤需求變更程度的適當度量，以決定是否要實施新的或修訂現有的控制方式。
- 細部執行方法：
  1. 記錄所有的需求和需求變更，不論是專案本身產生的或外界的要求。
  2. 維護需求變更紀錄，以及每次變更的理由。維護變更的歷史紀錄，有助於追蹤需求變更的狀況。
  3. 從相關關鍵人員的觀點，評估需求變更的影響。
  4. 確保專案人員能取得需求和變更的資料。
c. Discuss the associated Requirements Engineering (RE) activities within Scrum framework.
What kinds of Scrum meeting and artifacts are related to RE activities?
What kinds of RE techniques, such as prototyping, can be used and benefits Scrum?
(note: you may specify your thinking for Agile Requirements Engineering)
- 在需求分析和交涉、需求規範時Scrum的產品負責人必須要參與。
- 產品待辦清單其實就是需求規範時必須詳列出來的『功能性』與『非功能性』需求。
- RE中的需求管理與衝刺審查會議（Sprint Review Meeting）和衝刺回顧會議，是同一樣的東西。
You have been appointed to develop a vending machine that has an embedded system to control the vending machine
1. 販賣機系統的作業與功能需求描述表達如下：
  1. 消費者來到自動販賣機前面，瀏覽商品資訊消費者欲知詳細商品資訊，可進一步了解商品細部說明。
  2. 消費者可購買一種商品或多種商品，數量以五瓶為限(每項商品的預設值皆為一瓶)。
  3. 消費者可對商品進行數量或商品之修改。
  4. 消費者選定購買商品後，自動販賣機會自動進行庫存檢查並計算總金額，列出所購買之清單(註：必需鏈結相關的購買藍圖/資料詞彙)。
  5. 消費者進行購買清單之確認。
  6. 消費者使用現金付款的機制：使用現金，系統確認消費者在45秒內投入金額，完成付款。
  7. 消費者使用手機付款的機制：系統感應手機定確認手機身分，系統紀錄購買應付的金額，傳回手機，消費者完成付款動作消費者領取購買商品，系統自動盤點商品存貨(註：必需鏈結相關的補貨藍圖/資料詞彙)。

Homework 3

Software architecture
1. Model-View-Controller (MVC) architectu。
  - MVC模式的目的是實現一種動態的程式設計，使後續對程式的修改和擴充簡化，並且使程式某一部分的重複利用成為可能。
  - 此模式透過對複雜度的簡化，使程式結構更加直覺。
  - 軟體系統透過對自身基本部分分離的同時也賦予了各個基本部分應有的功能。專業人員可以依據自身的專長分組：
  - 控制器（Controller）
    - 負責轉發請求，對請求進行處理。
    - 起到不同層面間的組織作用，用於控制應用程式的流程。
    - 它處理事件並作出回應。
    - 「事件」包括用戶的行為和資料 Model 上的改變。
  - 視圖（View）
    - 介面設計人員進行圖形介面設計。
    - 能夠實現資料有目的的顯示（理論上，這不是必需的）。
    - 在 View 中一般沒有程式上的邏輯。
    - 為了實現 View 上的重新整理功能，View 需要存取它監視的資料模型（Model），因此應該事先在被它監視的資料那裡註冊。
  - 模型（Model）
    - 程式設計師編寫程式應有的功能（實現演算法等等）、資料庫專家進行資料管理和資料庫設計(可以實現具體的功能)。
    - 用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。
    - 有對資料直接存取的權力，例如對資料庫的存取。
    - 不依賴「View」和「Controller」，也就是說，Model不關心它會被如何顯示或是如何被操作。
    - 但是 Model 中資料的變化一般會通過一種重新整理機制被公布。
    - 為了實現這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比如：觀察者模式（軟體設計模式））
2. Draw and describe the clean architecture.
  - 軟體架構的目標是最小化建構與維護所需系統的人力資源
  - 行為（Behavior）：軟體架構需要支持將使用著的需求轉成可執行的軟體系統。
  - 結構（Structure）：好的軟體架構要讓「軟體變軟」，也就是要具備可修改性、可維護性。
  - 目前主流使用的編程典範：
    - 結構化：規範直接流程控制（不要使用 go to）。
    - 物件導向：規範間接流程控制（透過多型）。
    - 函數編程：規範指定指令（assignment）。
  - SOLID
    - Single Responsibility
    - Open-Closed
    - Liskov Substitution
    - Interface Segregation
    - Dependency Inversion
Consider an ATM system with its partial class diagram.
Describe the 5 key activities in an object-oriented design process.
1. 類別
  - 類別（Class）定義了一件事物的抽象特點。
  - 通常來說，類別定義了事物的屬性和它可以做到的（它的行為）。
  - 舉例來說，「狗」這個類別會包含狗的一切基礎特徵，例如它的孕育、毛皮顏色和吠叫的能力。
2. 物件
  - 物件（Object）是類別的例項。
  - 例如，「狗」這個類別列舉狗的特點，從而使這個類別定義了世界上所有的狗。而萊絲這個物件則是一條具體的狗，它的屬性也是具體的。
  - 狗有皮毛顏色，而萊絲的皮毛顏色是棕白色的。因此，萊絲就是狗這個類別的一個例項。
  - 一個具體物件屬性的值被稱作它的「狀態」。（系統給物件分配內部記憶體空間，而不會給類別分配內部記憶體空間，這很好理解。
  - 類別是抽象的系統不可能給抽象的東西分配空間，物件是具體的。
3. 方法
  - 是定義一個類別可以做的，但不一定會去做的事。
  - 作為一條狗，萊絲是會吠叫的，因此「吠叫()」就是它的一個方法。
  - 與此同時，它可能還會有其它方法，例如「坐下()」，或者「吃()」。
  - 對一個具體物件的方法進行呼叫並不影響其它物件，正如所有的狗都會叫，但是你讓一條狗叫不代表所有的狗都叫。
4. 繼承
  - 繼承（Inheritance）是指，在某種情況下，一個類別會有「子類別」。
  - 子類別比原本的類別（稱為父類別）要更加具體化，例如，「狗」這個類別可能會有它的子類別「牧羊犬」和「吉娃娃犬」。
  - 在這種情況下，「萊絲」可能就是牧羊犬的一個例項。
  - 子類別會繼承父類別的屬性和行為，並且也可包含它們自己的。
  - 我們假設「狗」這個類別有一個方法叫做「吠叫()」和一個屬性叫做「毛皮顏色」。它的子類別（前例中的牧羊犬和吉娃娃犬）會繼承這些成員。
  - 這意味著程式設計師只需要將相同的代碼寫一次。
5. 封裝
  - 具備封裝性（Encapsulation）的物件導向程式設計隱藏了某一方法的具體執行步驟
  - 取而代之的是透過訊息傳遞機制傳送訊息給它。
  - 因此，舉例來說，「狗」這個類別有「吠叫()」的方法，這一方法定義了狗具體該透過什麼方法吠叫。
  - 但是，萊絲的朋友蒂米並不需要知道它到底如何吠叫。

The SOLID stands for five basic principles of object-oriented programming and design.

Initial	Stands for	Name	Concept
S	SRP	Single Responsibility	認為物件應該僅具有一種單一功能的概念。
O	OCP	Open-Closed	認為「軟體體應該是對於擴充開放的，但是對於修改封閉的」的概念。
L	LSP	Liskov Substitution	認為「程式中的物件應該是可以在不改變程式正確性的前提下被它的子類所替換的」的概念。
I	ISP	Interface Segregation	認為「多個特定客戶端介面要好於一個寬泛用途的介面」的概念。
D	DIP	Dependency Inversion	認為一個方法應該遵從「依賴於抽象而不是一個實例」的概念。

Suppose that you are taking an Interdisciplinary Program of NTUT.

Homework 4

Describe the major activities of configuration management (CM).
- 從一特定系統壽命的開發期到營運期，憑藉針對自動化資料系統的硬體、軟體、韌體、檔案、測試、測試裝置、以及測試檔案所做的變更的管制，進行安全特點與安全保證的管理，原始碼管理、或版本控制是其中的一部份。
- 系統生命週期內從頭到尾，針對硬體、軟體、韌體、以及檔案所做的變更（包括其衍生出的紀錄）的管制。
- 針對複雜系統的發展的管制、與適應。是一種規則，能讓逐步成形的軟體產品持續處於控制之下，因此能夠滿足品質，延緩限制。
- 當建立了一個資訊系統形態之後，針對該形態、或與其相關聯的系統構件所做的評估、與變更核准。

What is Domain-Driven Design (DDD)? What are the building blocks of DDD?
1. DDD簡介：
  - 領域驅動設計（英語：Domain-driven design，縮寫 DDD）是一種通過將實現連接到持續進化的模型來滿足複雜需求的軟體開發方法。
  - 把專案的主要重點放在核心領域（core domain）和域邏輯。
  - 把複雜的設計放在有界域（bounded context）的模型上。
  - 發起一個創造性的合作之間的技術和域界專家以疊代地完善的概念模式，解決特定領域的問題。
2. 建構DDD：
  - Entity
    - 一個不由自身屬性定義而是由標識線和它的身分定義的物件。
  - Value Object
    - 只包含元素屬性的不可變物件。
  - Service
    - 強調與其他物件的關係，只定義了可以為客戶做什麼，不應該替代 Entity 和 Value Object 的所有行為。
  - Module
    - 一種表達機制，劃分代碼和概念。
  - Factory
    - 對於那些需要建立特定域物件的方法應該委派給工廠物件，因為這樣可以更容易的替換實現。
  - Repository
    - 對於檢索特定域物件的方法應該委派給 Repository 物件，因為這樣可以很容易地互換替代儲存的實現。
  - Aggregate
    - 由 ROOT ENTITY 繫結在一起的物件的集合，也稱為聚合根。
    - 聚合根通過禁止外部物件保持對其成員的參照來保證在聚合內進行的更改的一致性。
  - Domain Event
    - 一個域物件定義了一個事件。域事件是域專家所關心的事件

Consider software evolution?
1. What are the differences between refactor and reengineering?
  - Refactor：
    - 『重構』通常是對應用程序的相對較小的動作。
    - 系統仍然可以正常且『無任何改變』的工作，並且使用『相同』的數據。
    - 執行『相同』的功能並以相同的方式與用戶交互。
    - 可能會有一些新選項可用，但通常它保持不變。
  - Reengineering：
    - 『重新設計』可能會改變『應用程序』的工作方式。
    - 用戶、系統、數據或以上所有的交互方式都有可能改變。
    - 『重新設計』通常是一項艱鉅的工作，系統基本上就是整個重新設計，可視為一套全新的系統。
2. Describe the three types of software maintenances?
  - 重點分為三項『適應性維護』、『完善的維護』、『預防性的維護』
  1. 適應性維護
    - 自適應維護是在系統的一部分中實施更改，該更改已受到系統其他部分中發生的更改的影響。
    - 自適應維護包括使軟件適應環境的變化，例如硬件或操作系統。
    - 在本文中，術語『環境』是指（從外部）對系統起作用的條件和影響。
    - 例如，業務規則，工作模式和政府政策會對軟件系統產生重大影響。
  2. 完善的維護
    - 完善的維護主要處理實現新的或更改的用戶需求。
    - 完善的維護包括對系統進行功能增強，以及進行活動以提高系統性能，即使在故障未提示更改的情況下也是如此。
    - 這包括增強代碼的功能和效率，以及根據用戶不斷變化的需求更改系統的功能。
  3. 預防性的維護
    - 預防性維護涉及執行活動以防止錯誤的發生。
    - 它傾向於降低軟件複雜性，從而提高程序的易懂性並增加軟件的可維護性。
    - 它包括文檔更新，代碼優化和代碼重組。
    - 文檔更新涉及修改受更改影響的文檔，以便與系統的當前狀態相對應。代碼優化涉及修改程序，以加快執行速度或有效利用存儲空間。
    - 代碼重組涉及到轉換程序結構，以降低源代碼的複雜性並使其更易於理解。
3. What are bad smells (or code smells)? How will you relate bad smells and preventative maintenance?
  - 觀察氣味的一種方法是『關於原理』和『質量』。
  - 氣味是代碼中的某些結構，指示違反基本設計原理並對設計質量造成負面影響。
  - 代碼氣味通常不是錯誤，它們在技術上不是不正確的，並且不會阻止程序運行。
  - 相反，它們表示設計上的弱點可能會減慢開發速度，或增加將來出現錯誤或失敗的風險。錯誤的代碼氣味可以指示導致技術債務的因素。
  - 羅伯特·C·馬丁（Robert C. Martin）稱代碼列表為軟件工藝的『價值體系』。

Consider a program that takes a numerical score.

區分測試

{X(score<0 or score > 100), <-1, "X">}
{X(score<0 or score > 100), <101, "X">}

{C(score<60), <0, "F">}
{C(score<60), <10, "F">}
{C(score<60), <20, "F">}
{C(score<60), <30, "F">}
{C(score<60), <40, "F">}
{C(score<60), <50, "F">}
{C(60<=score<70), <60, "D">}
{C(70<=score<80), <70, "C">}
{C(80<=score<90), <80, "B">}
{C(score>=90), <90, "A">}
{C(score>=90), <100, "A">}

邊緣測試：

{X(score<0 or score > 100), <-1, "X">}
{X(score<0 or score > 100), <101, "X">}

{C(score<60), <0, "F">}
{C(score<60), <10, "F">}
{C(score<60), <59, "F">}
{C(60<=score<70), <60, "D">}
{C(60<=score<70), <69, "D">}
{C(70<=score<80), <70, "C">}
{C(70<=score<80), <79, "C">}
{C(80<=score<90), <80, "B">}
{C(80<=score<90), <89, "B">}
{C(score>=90), <90, "A">}
{C(score>=90), <99, "A">}
{C(score>=90), <100, "A">}

Consider the following program letterGrade.java.

區分測試

import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class Test {
    @Test
    public void TestEquivalencePartitioning() {
        char level = letterGrade(-1);
        assertEquals('X', level);
        level = letterGrade(101);
        assertEquals('X', level);
        level = letterGrade(0);
        assertEquals('F', level);
        level = letterGrade(10);
        assertEquals('F', level);
        level = letterGrade(20);
        assertEquals('F', level);
        level = letterGrade(30);
        assertEquals('F', level);
        level = letterGrade(40);
        assertEquals('F', level);
        level = letterGrade(50);
        assertEquals('F', level);
        level = letterGrade(60);
        assertEquals('D', level);
        level = letterGrade(70);
        assertEquals('C', level);
        level = letterGrade(80);
        assertEquals('B', level);
        level = letterGrade(90);
        assertEquals('A', level);
        level = letterGrade(100);
        assertEquals('A', level);
    }
}

邊緣測試：

import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class Test {
    @Test
    public void TestboundaryValue() {
        char level = letterGrade(-1);
        assertEquals('X', level);
        level = letterGrade(101);
        assertEquals('X', level);
        level = letterGrade(0);
        assertEquals('F', level);
        level = letterGrade(10);
        assertEquals('F', level);
        level = letterGrade(59);
        assertEquals('F', level);
        level = letterGrade(60);
        assertEquals('D', level);
        level = letterGrade(69);
        assertEquals('D', level);
        level = letterGrade(70);
        assertEquals('C', level);
        level = letterGrade(79);
        assertEquals('C', level);
        level = letterGrade(80);
        assertEquals('B', level);
        level = letterGrade(89);
        assertEquals('B', level);
        level = letterGrade(90);
        assertEquals('A', level);
        level = letterGrade(99);
        assertEquals('A', level);
        level = letterGrade(100);
        assertEquals('A', level);
    }
}