軟體工程第六版 第六章 系統工程

1. 軟體工程第六版第六章 系統工程

2. 系統工程簡介 • 約在五百年前，Machiavelli曾說：「再也沒有什麼比引進事情的新秩序更為困難接手、更為冒險的處理或在成功方面更為不確定的。」 • 過去五十年，以電腦為基礎的系統已引進一種事情的新秩序。 • 雖然自Machiavelli說出之後，技術已有極大的進展，但他的話卻繼續敲響著事實。

3. 系統工程簡介 • 軟體工程的出現是一個稱為系統工程(system engineering)流程的結果。 • 系統工程並非單一地專注於軟體上，它聚焦於許多不同的元素(elements)、分析、設計和組織，在系統中的這些元素可以是一種產品、一項服務，或一項資訊與控制轉換的技術。 • 系統工程流程依據它所運用的應用領域而呈現不同的形式。 • 當工作的環境聚焦於一家企業時，商務流程工程(business process engineering)就會被導入。 • 當某種產品(在此環境中，產品包括所有的東西，從無線電話到空中交通管制系統)將被建造時，此流程就被稱為產品工程(product engineering)。 • 商務流程工程與產品工程兩者均嘗試將秩序帶入以電腦為基礎的系統發展中。雖然每個都運用於不同的應用領域，但兩者均努力將軟體放入環境中。 • 本章將聚焦於管理議題與特定流程的活動，使軟體組織能確保它在正確的時間、以正確的方法、做正確的事。

4. 快速瀏覽 • 它是什麼？　 • 在軟體能被工程化之前，必須要瞭解它所駐留的「系統」。 • 為達完成此項工作，必須要決定系統的整體目標：硬體、軟體、人、資料庫、程序和其他必須確認的系統元素；操作的需求必須被誘引、分析、指明、塑模、確認和管理。這些活動是系統工程的基礎。 • 誰完成它？　 • 一位系統工程師的工作是藉由與顧客一起工作以瞭解系統的需求、未來的使用者和其他利益共享者。

5. 快速瀏覽 • 它為何重要？　 • 有一句古老的諺語：「你不能見樹而不見林。」 • 在此環境中，「森林」即是系統，而樹則是實現系統所必要的技術元素(包括軟體)。 • 若你在瞭解系統前，急著搶先建構技術元素，毫無疑問地你將會讓你的顧客失望。 • 在你擔憂樹之前，先瞭解森林。

6. 快速瀏覽 • 步驟為何？　 • 藉由從顧客所誘引的資訊，使得目標與更詳盡的操作需求被確認；分析需求以評估它們的清晰程度、完整性和一致性；經常產生結合著系統模型的規格，並由參與人員與顧客共同確認。最後，管理系統需求以確保變更可以被適當地控制。 • 工作產品為何？　 • 必須產生系統的一種有效表示法，以做為系統工程的結果。 • 這可能是一個雛型、一項規格或甚至是一種象徵性的模型，但它必須要溝通運作、功能和所要建構系統的行為特性，並提供對系統架構的深刻瞭解。

7. 快速瀏覽 • 我如何確定我所做的是正確的？　 • 以清晰、完整和一致性檢視所有系統工程的工作產品。 • 預期系統需求的改變，並使用穩固的變更管理方法管理它們。 • 即商務流程工程與產品工程一起進行為電腦軟體配置角色的工作，並且同時建立出將軟體與其他以電腦為基礎的系統元件綁在一起的鏈結(links)。

8. 6.1 以電腦為基礎的系統 • 韋伯字典(Webster’s Dictionary)用下列的方式定義系統： • 一組或安排的事情的有關形成個體(unity)或根本的(organic whole)全部； • 一組事實、原則、規則等，以某種安排的形式被分類與組織，作為顯示一個鏈結不同部份且合乎邏輯的計畫； • 一種分類或安排的方法或計畫； • 一種被建立來做某些事的方式、方法、程序…

9. 以電腦為基礎的系統 • 借用韋伯的定義，我們定義以電腦為基礎的系統為： • 一組元素或元素的安排，它們藉由處理資訊而被組織，以達到某些預先定義的目標。

10. 以電腦為基礎的系統元素 • 一個以電腦為基礎的系統利用許多不同的系統元素： • 軟體(Software) • 電腦程式、資料結構和相關工作產品，作為產生必要的邏輯的方法、程序或控制。 • 硬體(Hardware) • 提供計算能力、相互聯結( interconnectivity)裝置(例如，網路交換器、通訊裝置)的電子設備，讓資料可以流動，並提供外部世界功能的電機裝置(例如，感測器、電動機、泵)。 • 人(People) • 硬體與軟體的使用者與操作者。

11. 以電腦為基礎的系統元素 • 資料庫(Database) • 一個很大、有組織經由軟體與長時間存取的資訊整體。 • 文件(Documentation) • 描述系統使用與運算的敘述資訊(例如，模型、規格、紙本手冊、線上輔助檔案、網站)。 • 程序(Procedure) • 定義每個系統元素特定的使用或系統所駐流程序環境(context)的步驟。

12. 巨集元素 • 以電腦為基礎系統的一項複雜特性是建構某個系統的元素，也可能表示一個更大系統的巨集元素(macro element)。 • 巨集元素是以電腦為基礎的系統，也是一個更大的以電腦為基礎的系統的一部份。 • 例如，考慮一個工廠自動化系統(factory automation system)，實質上它是一種系統的階層。 • 在最低的階層中，我們有個數值控制機器、機器人和資料登錄裝置。每個以電腦為基礎的系統有它自己的權力(right)。 • 數值控制機器的元素包括電子與電機機械的硬體(例如，處理器與記憶體、馬達、感測器)、軟體(為了溝通與機器控制)、人(機器操作員)、一個資料庫(儲存NC的控制程式)、文件與程序。每個都是以電腦為基礎的系統。

13. 6.2 系統工程的階層 • 系統工程含括一個由上往下(top-down)與由下而上(bottom-up)方法的集合，以通過如圖6.1所示的階層。 • 系統工程流程通常由「世界觀點(world view)」開始。即整個商業或產品領域受到檢查，以確保適當的商業或技術環境可以被建立。 • 世界觀點被改進以聚焦在更為有興趣的特定領域。 • 在某個特定領域中，對目標系統元素的需要(例如，資料、軟體、硬體、人)會被分析。 • 某個目標系統元素的分析、設計和建構就被啟始。 • 在階層的頂端建立出非常廣泛的環境。在底層則藉由執行相關工程紀律(例如，硬體或者軟體工程)導入詳細的技術活動。

14. 圖 6.1 系統工程階層分類

15. 系統工程階層的表示 • 世界觀點(WV)是由一組領域(Di)所組成，每個可以是一個系統或在自己權力系統中的系統。 WV = { D1, D2, D3, …, Dn } • 每個領域都由特定的元素(Ej)組成，每個都在完成領域或元件(components)的目標與目的中扮演某種角色： D1 = { E1, E2, E3,…, Em } • 每個元件以特定的技術元件(Ck)實作，以達成某個元素所必需的功能： Ej = { C1, C2, C3,…, Ck } • 在軟體環境中，一個元件可以是一支電腦程式、一個可重複使用的程式元件、一個模組、一個類別或物件，或甚至是某個程式設語言的敘述(statement)。

16. 6.2.1 系統模型建立 • 系統塑模是系統工程流程的一項重要元素。 • 不論聚焦是否在世界觀點或細節觀點上，工程師創造模型以: • 定義流程作為所考慮觀點的需要。 • 表示流程的行為和行為所基於的假設。 • 明確地對模型定義外生的(exogenous)和內生的(endogenous)輸入。 • 表示所有的連結(包括輸出)，使工程師能夠更為瞭解其觀點。

17. 建構系統模型考慮的約制因素 • 建構一個系統模型，工程師應該考慮一些約制(restraining)因素： • 假設(Assumption)排除許多可能的排列與變化的數量，因而可促使一個模型以合理的方式反映問題。 • 例如，考慮娛樂業使用來創造真實動畫的三度空間演繹(rendering)產品。 • 產品其中的一個領域能夠表示3D立體人形。 • 輸入到此一領域含括來自真人演員指定移動(specify movement)能力、從視訊( video)或藉由繪圖模型的創作。 • 系統工程師確定某些關於人類運動可允許範圍的假設(例如，腳不能纏繞在軀幹的周圍)，因此輸入範圍與處理就可以被限制。

18. 建構系統模型考慮的約制因素 • 簡單化(Simplifications)可使模型能夠及時的建立。 • 考慮一家銷售與服務各類型影印機、掃描器和相關設備的辦公室產品公司。 • 系統工程師正在建立服務組織的需要模型，以瞭解服務訂單產生後訊息的流程。 • 雖然服務訂單可源自各方，工程師只從二個來源進行分類：內在的需求與外界的請求。 • 這種簡單的輸入區分是產生服務訂單所必要的。 • 限制(Limitations)協助規範系統。 • 舉例來說，飛機的航空電子系統正為著下一代的飛機而進行模型化的工作。 • 因為飛機都有二部引擎的設計，推進力(propulsion)的監控領域將被模型化，以調適二部引擎的最大值並結合備用系統(redundant system)。

19. 建構系統模型考慮的約制因素 • 侷限(Constraints)將指導創造模型的方法和實作模型時所採取的方式。 • 舉例來說，對於先前所描述的三度空間演譯系統的技術基礎建設(technology infrastructure)採用雙G5為基礎的處理器。 • 問題的計算複雜度必須要被侷限，以符合加於這些處理器上的處理極限。 • 偏好(Preferences)指出對所有的資料、功能和技術所喜歡的架構。 • 所喜歡的解決方案有時會與其他的約制因素相互抵觸。 • 顧客滿意度時常是以其喜愛的方式所被瞭解的程度來預測的。

20. 6.2.2 系統模擬 • 許多以電腦為基礎的系統是以反應的形式與真實的世界互動。 • 真實世界的事件由形成以電腦為基礎系統中的硬體與軟體所監控，並且基於這些事件，系統於機器上、流程上和導致事件發生的人加入控制。 • 即時與嵌入式系統時常歸類到反應系統的類型。 • 在反應類型的控制機器及/或流程中的許多系統(例如，商用飛機或石油煉解廠)必須於極為高可靠度的情形下進行操作。 • 如果系統失敗，將可能會發生重大的經濟或人員的損失。 • 當以電腦為基礎的系統被建造時，系統塑模與模擬工具就被用來協助於反應時消除意外事件。 • 這些工具應用於系統工程流程期間，硬體與軟體、資料庫和人的角色都被明確指定。 • 塑模與模擬工具讓系統工程師能夠「試駕(test drive)」系統的規格。

21. 6.3 商務流程工程：概觀 • 商務流程工程(business process engineering, BPE)的目的 • BPE是一種為創造實作計算架構的一項全面性的計畫。 • 定義使商業有效地運用資訊的架構。 • 當以一家公司資訊技術需求的世界觀點來看時，會有些懷疑系統工程是必要的。 • 不僅所必要的適當運算架構規格，且植基於組織計算資源獨特組態的軟體架構也必須被發展。

22. 商業流程的設計架構 • 三種不同的架構必須在商務目標與目的的環境中分析與設計： • 資料架構 • 應用架構 • 技術基礎建設(Technology infrastructure)

23. 資料架構(data architecture) • 資料架構(data architecture)為商業的資訊需要或商務功能提供一種框架。 • 架構中的個別建構方塊是使用於商務的資料物件。資料物件包含一組定義某些面向、品質、特性或被描述資料的描述符號(descriptor)的屬性。 • 一旦一組資料物件被定義，它們的關係將可被確認。 • 關係(relationship)指出物件如何與彼此相連接。例如，考慮物件：顧客與產品A。此二種物件可以用購買(purchases)的關係相連接；即是，某位顧客購買產品A或產品A是由顧客所購買。 • 資料物件(對一個主要的商業活動可能有數百或數千個)被組織在資料庫中，且被轉換提供服務商業需要的資訊於企業功能間流動。

24. 應用架構(application architecture) • 應用架構(application architecture)含括那些為了某些商務目的轉換資料架構中物件的系統元素。 • 應用架構即為執行此種轉換的程式(軟體)系統。 • 在更大範圍的環境中，應用架構可能結合人的角色(是資訊轉換者與使用者)和尚未自動化的商務程序。

25. 技術的基礎建設(Technology infrastructure) • 技術的基礎建設(Technology infrastructure)提供資料與應用架構的基礎。 • 基礎建設含括硬體與使用支援應用程式的資料與軟體。 • 包括電腦、作業系統、網路、通訊連結、儲存技術和已被設計實行這些技術的架構(例如主從式(client/server))。

26. 圖6.2 商業流程工程的階層

27. 6.4 產品設計：概觀 • 產品設計的目的是將顧客所期望的一組被定義的能力(capabilities)轉換成為工作產品。 • 為達成此一目的，產品設計一定要源自架構與基礎建設。 • 架構含括四種不同的系統元件：軟體、硬體、資料(和資料庫)和人。 • 所建立支援的基礎建設包括必需將元件維繫在一起所必要的技術，和使用支援元件的資訊(例如，文件、光碟、影片)。

28. 產品工程的階層 • 世界觀點經由需求工程而達成(參閱圖6.3)。 • 產品的整體需求是從顧客所誘引出的。 • 這些需求含括資訊與控制的需要、產品功能與行為、整體產品的效能、設計與界面的限制和其他特別的需要。 • 一旦需求成為已知，需求工程的工作是配置(allocate)功能與行為到先前所提及的四種元件中的每一個。 • 配置一旦已經發生，系統元件工程於是開始。 • 系統元件工程實際上是一組針對每個分離系統元件的一組併行的活動：軟體工程、硬體工程、人因工程和資料庫工程。

29. 圖6.3 產品工程的階層

30. 軟體工程的元素觀點 • 產品工程的元素觀點是工程紀律本身應用到某個配置的元件上。 • 對於軟體工程，這意謂著分析與設計的塑模活動(在往後的章節中詳細說明)、含括程式碼產生的建構與部署的活動、測試和支援任務。 • 分析任務模型將需求配置到資料、功能和行為的表示。 • 設計將分析模型映對進入資料、架構的、介面和軟體元件層級的設計。

31. 6.5 系統塑模 • 一個系統可以由不同層級的抽象化程度所表示: • 例如，世界觀點、領域觀點、元素觀點 • 系統模型(system model)自然會傾向於成為階層(hierarchical)或層級的(layered)。 • 在階層的頂端，呈現出完整的系統模型(世界觀點)。 • 當階層改進或分層級時，元件層級的細節(在此種情況下，硬體、軟體和其他等的表示)被製作成模型。 • 最後系統模型演進成為指定適當工程紀律的工程模型(更進一步的改進)。

32. 6.5.1 Hatley-Pirbhai塑模 • 每個以電腦為基礎的系統可模擬成為一個使用輸入 - 處理 - 輸出樣版的資訊轉換器。 • Hatley-Pirbhai的模型描述輸入、處理和輸出，連同使用者介面和維護與自我測試。 • 雖然這些附加的功能並不會在每個以電腦為基礎的系統中出現，但是它們卻很普遍，並且它們的規格可使任何的系統模型更為強韌(robust)。

33. Hatley-Pirbhai塑模的系統樣版 • 使用輸入、處理、輸出、使用者介面處理和自我測試處理的表示方式，一位系統工程師可以在每項工程紀律中為稍後的步驟設定基礎，以創造系統元件的模型。 • 系統樣版中的五個處理區塊： • 使用者介面 • 輸入 • 系統功能與控制 • 輸出 • 維護與自我測試。 • 系統工程師配置系統元素給樣版中五個處理區塊

34. 系統環境圖(SCD) • 系統模型樣版能讓分析者創造詳細的階層。 • 系統環境圖(system context diagram, SCD)位於階層的頂層。 • 環境圖「建立所實作的系統與系統所運作環境間的資訊界限」。 • SCD定義系統使用的所有外部資訊生產者、所有被系統創造的外部資訊消費者，和所有經由介面通訊或執行維護與自我測試的個體。

35. SCD的使用範例 • 考慮以輸送帶分類系統(conveyor line sorting system, CLSS)用以下(略為模糊)對目標的敘述來描述： • CLSS必須被發展以使沿著輸送帶運送的盒子得以被辨識與分類進入位在輸送帶尾端的六個容器中的一個。盒子經過分類站時會被辨識。基於印在盒子側面的識別碼與條碼，盒子將被分流(shunted)引進到適當的容器內。盒子以隨機的順序與均等的間隔通過。輸送帶移動的很慢。 • 一部位在分類站上的桌上型電腦執行所有CLSS的軟體，它與條碼讀取機互動以讀取每個盒子上的零件編號；它與運送帶監控設備互動以取得輸送帶的速度；它儲存所有零件號碼的分類，與分類站的操作員互動以產生各種不同的報表與診斷；它將控制信號傳送給分流的硬體以分類盒子；它與中央工廠的自動化系統溝通。

36. 改進系統的環境圖 • 系統工程師更詳盡地考慮圖6.4中有陰影的長方形，以改進系統的環境圖(context diagram)。 • 由SCD所定義使輸送帶分類系統運作在環境中的主要子系統被確認。 • 主要的子系統定義於從SCD所得到的系統流程圖(system flow diagram, SFD)。 • 跨越SCD的資訊流使用來引導系統工程師發展SFD - 對CLSS更為詳細的「圖(schematic)」。 • 系統流程圖顯示主要子系統與重要的訊息流的路線(資料與控制)。

37. 圖6.4 CLSS的系統環境圖(context diagram)

38. 建立SFD階層 • 最初的系統流程圖變成SFD階層最頂端的節點。 • 在最初SFD中每個圓角的長方形能被擴展成為另一個用於它的架構樣版。 • 流程以圖形的方式說明於圖6.5中。 • 系統中SFD的每一個都可以作為已經描述過的子系統中接續工程步驟的啟始點。 • 子系統和流動於它們之間的資訊可被接續的工程工作所明確說明(有界限的)。 • 每個子系統的敘述描寫和所有流動於子系統間資料的定義變成很重要的子系統規格元素。

39. 圖 6.5 建立SFD階層

40. 6.5.2 UML系統塑模 • UML提供種類繁多的圖塊，作為系統與軟體層級分析與設計的使用。 • 對CLSS系統而言，有四個重要的系統元素被塑模： • 使CLSS動作的硬體； • 實作資料庫存取與分類的軟體； • 對系統提出不同要求的操作員；和 • 包含相關條碼與目的地資訊的資料庫。

41. CLSS硬體的UML部署方塊圖模型 • CLSS硬體可以在系統層級應用UML部署方塊圖模型化，如圖6.6所示。 • 必須設計與建造硬體元素以作為專案的一部份。 • 在多情況中，硬體元素可能是取得的現貨產品。 • 對工程團隊的挑戰則是適當地介接硬體元素。

42. 圖6.6 CLSS硬體的部署圖

43. CLSS硬體的UML部署方塊圖模型 • CLSS軟體的程序切面(procedural aspects)可以使用活動圖(activity diagram)(圖6.7)表示。 • 此一UML的記號與流程圖(flowchart)相類似，用來表示當系統執行它的功能時所發生的事。 • 圓角長方形意謂著一種特定的系統功能；箭頭代表流向系統的方向；決策菱形(decision diamond)表示分支(branch)的決定(來自菱形所散發具有標記的箭頭)；實體水平線表示平行(parallel)的活動正在發生。

44. 圖6.7 CLSS的活動圖

45. CLSS的類別圖 • UML記號的類別圖(class diagram)。 • 在系統工程層級，類別是從問題的敘述中所擷取出的。 • 對CLSS而言，候選的類別可能是： • 盒子(Box)、輸送帶(ConveyorLine)、條碼讀取機(Bar-code Reader)、分路控制器(Shunt Controller)、操作員請求(Operator Request)、報表(Report)、產品(Product)和其它的類別。 • 每個類別含括一組描繪所有類別所必需要的資訊屬性。 • 類別的描述也包括一組應用於CLSS系統環境類別的操作。 • 盒子(Box)的UML類別圖顯示於圖6.8中。

46. 圖6.8 盒子類別的UML類別圖

47. CLSS的使用者案例圖 • CLSS操作員可以使用UML案例圖(use-case diagram)塑模，如圖6.9所示。 • 使用案例圖說明動作者(actor)(在此情況下，操作員用枝幹圖(stick figure)表示)與系統的互動方式。 • 每個在盒子(表示CLSS系統的界限)裡標記的橢圓形代表一種使用案例 - 一個描述與系統互動的文字情境。

48. 圖6.9 CLSS操作員的使用案例圖