1SoftwareEngineering軟件工程精品課程2第三章傳統軟件工程技術簡介結構化程序的發展3.1結構化程序的開發流程與特點3.2結構化程序與面向對象程序開發的比較3.3結構化程序的應用3.433.1結構化程序的發展結構化程序設計(StructuredProgramming)是瑞士計算機科學家尼克勞斯·沃思（NiklausWirth）于1971年，基于其開發程序設計語言和編程的實踐驗，首次提出了“結構化程序設計”的概念。 結構化程序的定義如下：

“如果一個程序的代碼僅通過順序、選擇和循環這三種控制結構組合、連接而成，并且僅有一個入口和一個出口，則稱這個程序是結構化的。”4結構化程序的控制結構結構化程序設計循環順序選擇5只使用“順序”、“選擇”和“循環”3種基本控制結構進行程序設計是結構化程序設計的主要內容。隨著IBM公司1971年在《紐約時報》系統中成功使用了結構化程序設計。結構化程序設計成為上世紀70年代初到90年代初，最為成功的軟件設計與開發模型。但在面向對象方法的廣泛使用后，大型軟件開發基本上拋棄了結構化程序設計方法，而只在較小的模塊一級使用。63.2結構化程序開發的流程與特點結構化軟件開發方法

即所謂的SASD方法，也稱為面向功能的軟件開發方法或面向數據流的軟件開發方法。它首先用結構化分析（SA）對軟件進行需求分析，然后用結構化設計（SD）方法進行總體設計，并用結構圖來描述軟件的結構，最后是結構化編程（SP）。

7結構化開發的特點

結構化開發方法產生過程的抽象，這些抽象把軟件視為處理流，定義構成一系列步驟的算法，每一步驟都是帶有預定義輸入和特定輸出的一個過程，把這些步驟串聯在一起可產生合理的穩定的貫通于整個程序的控制流。在結構化開發方法中，數據結構是應算法步驟的要求而開發的。數據結構貫穿于過程，提供過程需要傳送給它的操作的信息。系統的狀態是一組全局變量，這組全局變量保持了狀態的值，把它們從一個過程傳送到另一個過程。83.2.1結構化程序設計的分析與建模分析原則與軟件需求規約

結構化分析是結構化軟件開發的第一步，結構化分析確定了軟件要做什么。軟件需求規約又叫軟件需求說明，是結構化分析的最終產物。數據建模

數據建模是組織數據使其結構化的過程。一般來說，軟件開發的早期關注于概念數據模型，細化后得到邏輯數據模型。實體-關系圖

實體-聯系圖（E-R圖），提供了表示實體型、屬性和聯系的方法，用來描述現實世界的概念模型。是概念數據模型的高層描述所使用的數據模型或模式圖，它為表述這種實體聯系模式的數據模型提供了圖形符號。構成E-R圖的基本要素是實體型、屬性和聯系，其表示方法如圖3-1所示。9圖3-1實體聯系圖的基本成分10數據流圖(DFD)

數據流圖是軟件設計開發過程中概念模型設計的重要圖形表示法，它是從數據傳遞和加工的角度，以圖形的方式來刻畫數據流和轉換的信息建模技術。它提供層次結構，讓分析人員能夠方便的表示任意抽象級別上的信息系統或其子系統，并支持問題分解、逐步求精的分析方法。數據流圖中具有四種基本成分，如圖3-2所示。11圖3-2數據流圖的基本成分及其表達符號12haha數據流表示數據的流動情況；加工表示對數據的加工處理過程，它的名字應能簡明扼要地表明所完成的是什么加工；數據存貯在數據流圖中起著保存數據的作用，指向數據存貯的數據流可以理解為寫數據，從數據存貯引出的數據流可以理解為讀數據，雙向數據流可以理解為修改數據。在數據流圖中，如果有兩個以上數據流指向一個加工或從一個加工中引出，則這些數據流之間往往存在一定的關系。我們通常用圖3-3所示符號表示這種關系。13圖3-3多個數據流與加工關系的表示14狀態轉換圖狀態轉換圖是描述一個實體基于事件反應的動態行為，顯示了該實體是如何根據當前所處的狀態，對不同的事件做出反應的。狀態轉換圖與數據流圖有本質的不同，數據流圖側重于狀態的描述。狀態轉換圖的條件和一個過程的輸入數據流相對應，并且還與控制的流出相對應。狀態圖的符號集包括5個基本元素：初始起點，它使用實心圓來繪制；狀態之間的轉換，它使用具有開箭頭的線段來繪制；狀態，它使用圓角矩形來繪制；判斷點，它使用空心圓來繪制；以及一個或者多個終止點，它們使用內部包含實心圓的圓來繪制。15數據字典數據字典是包含所有系統數據元素定義的倉庫。在這里，數據元素的定義必須是精確的、嚴格的和明確的。數據字典的定義包括過程描述、數據流定義、數據元素定義和數據存儲定義。

163.2.2結構化程序設計的原則與方法模塊化模塊化就是把程序劃分成若干個模塊，每個模塊都具有某個子功能，把這些模塊集成起來構成一個整體，可以完成指定的功能，實現問題的求解。層次圖層次圖用樹狀層次結構描述系統各個組成部分之間的關系，層次圖中的一個矩形框代表一個模塊，方框間的連線表示調用關系。層次圖十分清晰的反映了系統結構。結構圖系統結構圖是軟件系統的模塊層次結構，表達了程序模塊之間的關系，反映了整個系統的功能實現，即將來程序的控制層次體系。系統結構往往用樹狀或網狀結構的圖形來表示。17數據結構數據結構是指同一數據元素類中各個數據元素之間的關系。數據結構分別為邏輯結構、存儲結構（物理結構）和數據的運算。程序流程圖程序流程圖(ProgramFlowDiagram簡稱PFD圖)又稱為程序框圖。使用程序流程圖的主要優點是，很直觀地描述了程序的控制邏輯，便于初學者掌握，而且其表現方式較為靈活，使用起來非常方便。PAD圖問題分析圖(ProblemAnalysisDiagram,簡稱PAD)是由日本日立公司設計的,它針對程序流程圖的某些特點，進行了適當的改進。它把程序過程控制結構表示成二維樹的圖形，是一種具有很強的結構化特征的分析工具。183.2.3測試單元測試（Unittest）單元測試是對程序最小單元——模塊的測試。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數的行為。初步的單元測試是由程序員自己來完成，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試用例。執行單元測試，就是為了證明這段代碼的行為和期望的一致。

集成測試(Integrationtest)

集成測試是在單元測試的基礎上，將所有的軟件單元按照概要設計規格說明的要求組裝成子系統，然后測試子系統各部分是否達到或實現相應技術指標及要求的活動。在集成測試之前，單元測試應該已經完成。集成測試最簡單的形式是：兩個已經測試過的單元組合成一個組件，并且測試它們之間的接口。19系統測試(Systemtest)

系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否能夠提供系統方案說明書中指定功能的有效方法。它目的是對最終軟件系統進行全面的測試，確保最終軟件系統滿足產品需求并且遵循系統設計要求。203.2.4軟件維護定義：所謂軟件維護，就是指在軟件交付使用之后，為了改正軟件錯誤或者滿足用戶新的需要而修改軟件的過程。特點：軟件維護需要的工作量很大，平均來說，大型軟件的維護成本高達開發成本的4倍左右。許多軟件開發組織把60％以上的人力用于維護已有的軟件，而且隨著軟件數量增多和使用壽命的延長，這個百分比還在持續上升。總的來說有以下三點：

1、結構化維護與非結構化維護差別巨大。

2、維護的代價高昂。

3、維護的問題很多。213.3結構化程序與面向對象程序開發的比較空格上個世紀60年代后期，開始出現面向對象的概念。到80年代中期，面向對象的設計與分析技術逐步成型。到90年代，面向對象的程序設計逐漸成為軟件開發的重要方法，而今天，它已經成為軟件開發的首選方法和必備條件。空格為什么采用面向對象技術，面向對象技術的概念和特點是什么？在本章，僅從一個程序實例的角度，使大家對結構化程序設計和面向對象程序設計的區別有一個感性上的認識。

22例子：空格電梯是人們日常生活中經常使用和乘坐的設備，我們就不妨以電梯的控制程序為例，看看結構化程序設計與面向對象設計的本質區別。

電梯的控制規則在這里不作贅述。需要說明的是，我們主要是分析結構化設計和面向對象設計的區別，鑒于有些知識是后續才介紹的內容，這里僅進行軟件頂層的設計，重要的是了解分析問題的方法和思路，而不是實現細節。233.3.1結構化程序設計方法結構化程序設計是面向過程的設計，我們研究的是系統的工作流程，具體的講是數據和狀態的變化過程。明確輸入與輸出及功能要求要求：針對樓層按鈕和電梯內按鈕的狀態要求，控制電梯的正確運行。我們將所有數據分為外部輸入和內部狀態兩類：24Diagram外部輸入數據：樓層按鈕：boo：UpButton[N]，DownButton[N]；電梯內部按鈕：bool：button[N]，DoorOpen，DoorClose；數據內部數據：電梯當前樓層：int：CurrentFloor；電梯運行方向set：CurrentRunDirection={UP，DOWM}；

25系統硬件結構圖圖3-4系統硬件結構圖26顯然，軟件分為底層信號獲取模塊、控制執行模塊和上層控制策略處理模塊。其軟件結構圖如圖3-5所示。

圖3-5軟件結構圖27空格顯然，信號獲取、執行驅動和系統初始化的模塊都比較簡單，不再說明，僅對電梯控制策略處理模塊進行進一步說明。其中，僅需對電梯停頓規則和運行方向調整規則進行說明：電梯停頓規則：

1本樓層有與電梯運行同方向的停頓請求（按鈕）；

2或電梯內有本樓層的停頓請求（按鈕）；

3或已到頂層或底層（包括后續同方向無停頓請求）；方向調整規則：

1若電梯內有后續樓層的同向停頓要求（按鈕）；

2或后續樓層有停頓請求；則保持方向不變；否則反向。28空格到這里，我們用結構化設計方法對電梯系統的分析已基本完畢。這里我們給出的是程序設計的基本框架，而不是具體實現。但是，我們可以看到，結構化程序設計時，設計人員必須面對所有數據和控制流程。何時獲取數據，何時進行計算，如何驅動執行機構等必須都安排好順序。事實上，往往整個程序執行工程都必須全部清晰地反映在設計者的頭腦中，才能進行流程控制和理順全部的數據與時序。下面讓我們看看用面向對象的程序方法是如何做的。293.3.2面向對象程序設計方法空格現在我們再來看看面向對象設計的方法。要讓程序設計者在頭腦中準確記住所有的輸入數據、輸出數據和狀態關系，往往是十分困難、甚至難以做到的事。面向對象設計與結構化程序設計方法的最根本區別，是我們不需要去考慮所有的數據、輸出和狀態等，而我們只關心有哪些對象構成，每個對象能做什么？我們再來考慮電梯控制程序，我們首先考慮在這個過程中都有哪些對象，從系統需求中我們知道有：大廈、電梯、樓層、按鈕等，我們把這些對象細化到與程序有關的對象：大廈是沒有直接意義的，電梯又由按鈕、電梯門和電梯執行機構組成，當然，還有每層的樓層按鈕，以及電梯控制器：決定電梯的上升、下降停止和開門與關門。30空格在面向對象設計時，每一個對象是獨立的，它根據自己的狀態和外部信息決定自己的動作。那么，我們只要將每一個對象的數據和功能設計完成，整個系統就設計完成了。而不用將全部的數據和控制順序全部考慮在頭腦中。我們設計電梯控制系統由樓層按鈕類（FloorButton）、電梯按鈕類（ElevatorButton）、電梯門類（ElevatorDoor）、電梯控制器類（ElevatorControler）、電梯執行器類（ElevatorActor）構成。31空格讓我們以“樓層按鈕類”為例，來看看類的內部構造，以便讓我們對“類”有一個初步認識：樓層按鈕類（FloorButton）：

classFloorButton{private：

boolUP，DOWN；//按鈕“上”、“下”的狀態

public：

pressUp（）；//按下“上”按鈕

pressDown（）；//按下“下”按鈕

cleanUp（）；//清楚“上”按鈕

CleanDown（）；//清除“下”按鈕

}32空格也許我們現在還看不懂類是怎樣構造出來的，沒有關系，在后面的章節中我們會學到有關的知識，這里只要認識就可以了。空格將前面所列出的類一一構造出來后，面向對象的分析也可基本考一段落。我們可以看到，面向對象的程序設計，更符合人們日常的思考習慣和工作方法，各個對象都有獨立的狀態和方法，使軟件工程師將更多的精力放在應用問題的處理上，而不再是復雜的程序結構和控制順序上。隨著后續章節的說明，大家會對面向對象程序設計方法有越來越多的認識。333.4結構化程序的應用ATM機是人們日常生活經常使用的設備，我們給出它的需求，請大家嘗試按結構化程序設計的方法設計該系統的數據結構、軟件結構、模塊劃分和各個模塊的流程圖。ATM機功能需求：①系統功能語言選擇（中文、英文、日文）用戶合法性檢驗用戶刷卡、6位數密碼②網絡通訊實現與銀行數據庫系統的聯接③帳戶基本管理功能查詢余額查詢當前帳戶的剩余金額；存儲當前帳戶中存入現金；取現金從當前帳戶余額中，提取不超過余額和本日提取金額的用戶輸入現金數；歷史信息查詢查詢從“起始日期”到“結束日期”的本帳戶所有存、取活動；④打印打印上述活動的信息⑤帳戶高級功能掛失帳戶對當前帳戶進行掛失操作；轉帳從本帳戶支付用戶輸入金額到用戶指定帳戶中；34小結與作業空格本章對面向結構化程序設計的軟件工程技術進行了介紹和說明。雖然面向對象的軟件設計和軟件工程技術已成為當今的主流技術，但在一定條件下，面向結構化程序的設計技術與方法還有著重要的意義。而且作為面向對象軟件工程技術的基礎，了解和學習傳統的結構化軟件工程技術與方法，也是后續學習的必要保證。作業與練習：（回答下列問題）1.結構化程序設計基本要求要點是什么？2.結構化分析與結構化設計的區別？3.結構化方法以及其手段有哪些？4.面向對象方法與結構化方法的相同和不同之處有哪些？5.結構化分析方法建立的系統模型包括什么，請具體說明？6.不論項目采用什么樣的軟件生存周期過程，其基本特征是什么？7.軟件開發模型與軟件開發學之間的關系是什么？35ThankYou!2025/2/2636第七章面向對象分析

2025/2/2637第七章

面向對象分析（OOA）

基本原理與概念

1基本方法與過程2OOA實踐1:ATM系統3OOA實踐2：電梯控制系統4小結52025/2/2638面向對象分析（OOA）

在本章中，我們將介紹面向對象分析（object-orientedanalysis，OOA）的各種技術和方法。它包括分析和定義用戶的需求（用例模型）、系統中數據的定義（靜態模型），以及控制流（動態模型）分析。2025/2/2639

7.1基本原理與概念

面向對象分析（OOA），就是抽取和整理用戶需求，并建立問題域精確模型的過程。 面向對象分析的關鍵，是識別出問題域內的對象，并分析它們相互間的關系，最終建立起問題域的簡潔、精確、可理解的正確模型。根據Coda&Yourdon的面向對象分析和設計技術，面向對象分析（Object-OrientedAnalysis,OOA）模型的5個層次分別如下：2025/2/26407.1基本原理與概念對象-類層（Class&ObjectLayer），表示待開發系統的基本構造塊。

屬性層（AttributeLayer），對象所存儲（或容納）的數據。服務層（ServiceLayer），對象所做的“工作”，加上對象實例間的通訊。結構層（StructureLayer），負責捕捉特定應用論域中的結構關系。如電梯作為一個整體而言，必須由電梯馬達、超載傳感器、樓層到達顯示面板、隨機指令面板、隨機召喚面板等組成。主題層（SubjectLayer），可以將眾多的對象歸類到幾個子模型或子系統，即各個主題。對于電梯控制系統，可分為電梯控制和電梯管理兩個主題。2025/2/26417.1基本原理與概念 OOA的實現方法有多種，大多數分析結果可以被歸結到如下方面：功能模型（用例模型）。通過用例描述，來表達系統的詳細需求，為軟件的進一步分析和設計打下基礎。靜態結構（對象模型）。對象模型描述了現實世界中的“類和對象”以及它們之間的關系，表示了目標系統的靜態數據結構。交互次序（動態模型）。動態模型描述系統的動態結構和系統對象之間的交互。2025/2/26427.2基本方法與過程7.2.1OOA原則

OOA的主要原則有以下九點：

抽象：從許多事物中舍棄個別的、非本質的特征，抽取共同的、本質性的特征，就叫作抽象。抽象原則有兩方面的意義：第一，需要分析研究其中與系統目標有關的事物及其本質性特征。第二，通過舍棄個體事物在細節上的差異，抽取其共同特征而得到一批事物的抽象概念。抽象原則包括過程抽象和數據抽象兩個方面。

2025/2/26437.2基本方法與過程封裝：就是把對象的屬性和服務結合為一個不可分的系統單位，并盡可能隱蔽對象的內部細節。 繼承：特殊類的對象擁有的其一般類的全部屬性與服務，稱作特殊類對一般類的繼承。 分類：就是把具有相同屬性和服務的對象劃分為一類，用類作為這些對象的抽象描述。分類原則實際上是抽象原則運用于對象描述時的一種表現形式。2025/2/26447.2基本方法與過程聚合：又稱組裝，其原則是：把一個復雜的事物看成若干比較簡單的事物的組裝體，從而簡化對復雜事物的描述。 關聯：是人類思考問題時經常運用的思想方法：通過一個事物聯想到另外的事物。能使人發生聯想的原因是事物之間確實存在著某些聯系。 消息通信：這一原則要求對象之間只能通過消息進行通信，而不允許在對象之外直接地存取對象內部的屬性。通過消息進行通信，是由于封裝原則而引起的。在OOA中要求用消息連接表示出對象之間的動態聯系。 粒度控制：一般來講，人在面對一個復雜的問題域時，不可能在同一時刻既能縱觀全局，又能洞察秋毫。因此需要控制自己的視野：考慮全局時，注意其大的組成部分，暫時不詳察每一部分的具體的細節；考慮某部分的細節時，則暫時撇開其余的部分。這就是粒度控制原則。 行為分析：現實世界中事物的行為是復雜的。由大量的事物所構成的問題域中各種行為往往相互依賴、相互交織。2025/2/26457.2基本方法與過程7.2.2OOA建模基本過程1)功能模型的建立該階段的目標是獲得對問題論域的清晰、精確的定義，產生描述系統功能和問題論域的基本特征的綜合文檔。論域分析過程是抽取和整理用戶需求并建立問題域精確模型的過程。主要任務是充分理解專業領域的業務問題和投資者及用戶的需求，提出高層次的問題解決方案。應具體分析應用領域的業務范圍、業務規則和業務處理過程，確定系統范圍、功能、性能，完善細化用戶需求，抽象出目標系統的本質屬性，建立問題論域模型。在我們的分析過程中，則須建立詳細的用例模型圖。2025/2/26467.2基本方法與過程2)對象模型的建立

對象是由描述其屬性的數據，及可以對這些數據施加的操作（即服務），封裝在一起構成的獨立單元。因此，為建立完整的對象模型，既要確定類中應該定義的屬性，又要確定類中應該定義的服務。這些信息體現在類模型圖中。在分析過程中，由軟件分析師來確定所需要的類的集合和它們的屬性，以及類與類之間的關系。對象服務的確定我們放在設計階段。這一步驟完全等同于面向數據的技術。幾乎解決任何一個問題，都需要從客觀世界實體及實體間相互關系抽象出極有價值的對象模型；對于復雜問題（大型系統）的對象模型一般由Coad方法所述的五個層次組成：主題層（也稱為范疇層）類&對象層結構層屬性層服務層2025/2/26477.2基本方法與過程

通過劃分主題，我們可以把一個大型、復雜的對象模型分解成幾個不同的概念范疇。一個主題有一個名稱和一個標識它的編號。在描繪對象模型的圖中，把屬于同一個主題的那些類—&—對象框在一個框中，并在框的四角標上這個主題的編號。在建立對象模型階段，分析師借助用例腳本和用例圖來獲得關于該軟件后續設計階段中，所要創建的對象類的最原始信息。包括分析為創建一個用例圖已經寫出的用例腳本的描述性文字，其實，這也是E-R圖（實體-關系圖）的另一種形式。工作步驟如下：確定對象類和關聯進一步劃分出若干主題給類和關聯增添屬性利用適當的繼承關系進一步合并和組織類確定類中的服務（等到建立了動態模型和功能模型之后）2025/2/26487.2基本方法與過程(1)

類和關聯的確定。

名詞抽象是類建模的第一步，在面向對象分析階段，緊隨用例建模之后。為了定義一系列后選類和對象，名詞抽象是一種語言分析形式，被用來分析用例細節和其它已經提取出的系統行為的書面描述。名詞抽象時，每一步的輸入要么是不正式的產品描述（正如在Schach多級處理的描述），或者是在用例建模期間被創建的詳細用例情節。在這個章節里，我們將詳細說明這兩個方法。下文中將介紹使用兩種名詞抽象抽象方法來實現設計的修改。 對象類的確定是在需求陳述的基礎上進行的。需求陳述闡明軟件的具體功能，即“做什么”，它描述用戶的需求但一般不提出解決問題的方法。需求陳述可以由用例（usecase）分析的結果直接得出。陳述的內容包括：問題范圍，功能需求，性能需求，應用環境及假設條件等。2025/2/26497.2基本方法與過程類和對象是在問題域中客觀存在的。首先，我們要找出所有候選的類和對象；然后，從候選的類和對象中篩選掉不正確的或不必要的。一種指導我們分析的方法為：以用自然語言書寫的需求陳述為依據，把陳述中的名詞作為類的候選者；找出隱含類；形容詞作為確定屬性的線索；動詞作為服務（操作）的候選者。通常，在需求陳述中不會一個不漏地寫出問題域中所有有關的類和對象；根據領域知識或常識，可以進一步把隱含的類和對象提取出來。

2025/2/26507.2基本方法與過程初步選出候選類和對象之后，我們還必須對候選類進行篩選。篩選時主要依據下列標準，刪除不正確或不必要的類和對象，包括：冗余：如果兩個類表達了同樣的信息，則應該保留在此問題域中最富于描述力的名稱。無關：僅需要把與本問題密切相關的類和對象放進目標系統中。籠統：去掉籠統的或模糊的類。屬性：有些名詞實際上描述的是其他對象的屬性，應該把這些名詞從候選類中去掉。當然，如果某個性質具有很強的獨立性，則應把它作為類而不是作為屬性。操作：一些既可作為名詞，又可作為動詞的詞，應該慎重考慮它們在本問題中的含義，以便正確地決定把它們作為類還是作為類中定義的操作。但是，本身具有屬性且需獨立存在的操作，應該作為類。例如，談到電話時通常把“撥號”當作動詞，當構造電話模型時確實應該把它作為一個操作，而不是一個類。但是，在開發電話的自動記賬系統時，“撥號”需要有自己的屬性（如日期、時間、受話地點等），因此應該把它作為一個類。實現：去掉僅和實現有關的候選類。在設計和實現階段，這些類可能是重要的，但在分析階段過早地考慮它們反而會分散我們的注意力。2025/2/26517.2基本方法與過程確定了類和對象之后，我們來確定類和對象間的關聯關系。兩個或多個對象之間的相互依賴、相互作用的關系就是關聯。分析確定關聯，能促使對問題域的邊緣情況進行分析，有助于發現那些尚未被發現的類和對象。大多數關聯可以通過直接提取需求陳述中的動詞詞組而得出。進一步分析需求陳述，能發現一些在陳述中隱含的關聯。分析員通過與用戶及領域專家討論問題域實體間的相互依賴、相互作用關系，根據領域知識可能再進一步補充一些關聯。經初步分析得出的關聯只能作為候選的關聯，還需經過進一步篩選，以去掉不正確的或不必要的關聯。要刪除的關聯包括：已刪去的類之間的關聯。如果在分析確定類和對象的過程中已經刪掉了某個候選類，則與這個類有關的關聯也應該刪去，或用其他類重新表達這個關聯。與問題無關或應在實現階段考慮的關聯。即處在本問題域之外的關聯或與實現密切相關的關聯。瞬時事件：關聯描述問題域的靜態結構，因此瞬時事件應該刪除。三元關聯：三個或三個以上對象之間的關聯，大多可以分解為二元關聯或用詞組描述成限定的關聯。如果三元關聯中涉及的某個實體僅用于描述另兩個實體的關系，而且這個實體本身不包含屬性，則它是二元關聯上的鏈屬性。派生關聯：可以用其他關聯定義的關聯。經過篩選后的關聯還需要進行進一步的完善，這一步的工作主要包括：正名：仔細選擇含義更明確的名字作為關聯名。分解：為了能夠適用于不同的關聯，必要時應該分解以前確定的類。補充：及時補上遺漏的關聯。標明階數：初步判定各個關聯的類型，并粗略地確定關聯的階數。2025/2/26527.2基本方法與過程(2)

劃分主題主題是按照問題域來確定的，注意不是用功能分解方法來確定主題。不同主題內的對象間應相互依賴和交互最少。如在ATM系統中，一般可分為三個主題。(3)

確定屬性屬性是對象的性質，借助于屬性我們能對類和對象的結構有更深入、更具體的認識。通常，在需求陳述中用名詞詞組表示屬性，例如，“汽車的顏色”或“光標的位置”。另外，借助于領域知識和常識，才能分析得出需求陳述中未直接給出的屬性。屬性的確定既與問題域有關，也和目標系統的任務有關。以下我們給出幾點確定屬性的方法：僅考慮與具體應用直接相關的屬性，不考慮那些超出所要解決的問題范圍的屬性；首先找出最重要的屬性，以后再逐漸把其余屬性增添進去；在分析階段不考慮那些純粹用于實現的屬性。2025/2/26537.2基本方法與過程認真考察經初步分析得到的屬性，從中刪掉不正確的或不必要的屬性。要刪除的屬性包括：屬性對象：誤把對象當作屬性。連接屬性：把鏈屬性誤作為屬性限定：把限定誤當成屬性內部狀態：誤把內部狀態當成了屬性過于細化需要合并的屬性不一致的屬性(4)識別繼承和組合一般說來，可以使用兩種方式建立繼承關系：自底向上：抽象出現有類的共同性質泛化出父類，這個過程實質上模擬了人類歸納思維過程。自頂向下：把現有類細化成更具體的子類，這模擬了人類的演繹思維過程。從應用域中常常能明顯看出應該做的自頂向下的具體化工作。例如，帶有形容詞修飾的名詞詞組往往暗示了一些具體類。但是，在分析階段應該避免過度細化。

2025/2/26547.2基本方法與過程組合也是一種特殊的關聯關系，“事務”和“更新”之間是組合關系。通常，一個事務包含對賬戶的若干次更新，這里所說的更新，指的是對賬戶所做的一個動作（取款、存款或查詢）。“更新”雖然代表一個動作，但是它有自己的屬性（類型、金額等），應該獨立存在，因此應該把它作為類。在關聯的識別過程中，大部分組合關系已被識別，在這里再次列出，以進一步發現遺漏的組合關系。

3)動態模型的建立動態模型建模的目標，是要創建一個描述軟件在運行過程中，所有可能進入的不同狀態的狀態裝換圖（STD）。就此而言，狀態轉換圖，好比是用來說明在結構分析的建模過程中，建立的一個有限狀態機（FSM）。一個狀態轉換圖可以定義成如下的公式：當前狀態+事件+斷言

下一個狀態即

currentstateandeventandpredicate

nextstate2025/2/26557.2基本方法與過程然而實際上，狀態轉換圖通常以圖形的方式表現出來，以便于更清晰地表示出狀態轉換之間的關系。在開發交互式系統時，動態模型起著很重要的作用，動態模型的建立通常有以下幾步：編寫典型交互行為的腳本。從腳本中提取出事件，確定觸發每個事件的動作對象以及接受事件的目標對象。排列事件發生的次序，確定每個對象可能有的狀態及狀態間的轉換關系，并用狀態圖描繪它們。比較各個對象的狀態圖，檢查它們之間的一致性，確保事件之間的匹配。2025/2/26567.2基本方法與過程(1)編寫腳本腳本是指系統在某一執行期間內出現的一系列事件。編寫腳本的過程，實質上就是分析用戶對系統交互行為的要求的過程。編寫腳本的目的是為了保證不遺漏重要的交互步驟，它有助于確保整個交互過程的正確性和清晰性。其內容范圍既可以包括系統中發生的全部事件，也可以只包括由某些特定對象觸發的事件。腳本描寫的范圍主要由編寫腳本的具體目的決定。腳本用來描述事件序列，每當系統中的對象與用戶（或其他外部設備）交換信息時，就發生一個事件。所交換的信息值就是該事件的參數（例如，“輸入密碼”事件的參數是所輸入的密碼）。也有許多事件是無參數的，這樣的事件僅傳遞一個信息——該事件已經發生了。對于每個事件，都應該指明：觸發該事件的動作對象（例如，系統、用戶或其他外部事物）；接受事件的目標對象；事件的參數。編寫過程中要考慮以下三種情況：正常情況。特殊情況，例如，輸入或輸出的數據為最大值（或最小值）。出錯情況，例如，輸入的值為非法值或響應失敗。如果可能，系統應該允許用戶“異常中止”或“取消”一個操作。應該提供諸如“幫助”和”狀態查詢”之類的在基本交互行為之上的“通用”交互行為。2025/2/26577.2基本方法與過程(2)事件提取仔細分析每個腳本，從中提取出所有外部事件。事件包括系統與用戶（或外部設備）交互的所有信號、輸入、輸出、中斷、動作等等。對象傳遞信息的動作也是事件。對控制流產生相同效果的事件組合在一起應作為一類事件，并采用唯一的名字。對控制流有不同影響的事件則應區分開來，最后，還應該區分出每類事件的發送對象和接收對象。完整、正確的腳本為建立動態模型奠定了必要的基礎。但是，用自然語言書寫的腳本往往不夠簡明，而且有時在閱讀時會有二義性。為了有助于建立動態模型，通常在畫狀態圖之前先畫出事件跟蹤圖，即時序圖。(3)繪制狀態圖狀態圖用于描繪事件與對象狀態的關系。狀態圖的詳細作用及繪制方法參見第五章。有以下幾點需要注意：

2025/2/26587.2基本方法與過程將圖中所有指向某條豎線的箭頭線，作為狀態圖中的箭頭線，邊上標以事件名。兩個事件之間的間隔就是一個狀態。從時序圖中當前考慮的豎線射出的箭頭線，是這條豎線代表的對象到達某個狀態時所做的行為。畫出狀態圖之后，再把其他腳本的時序圖合并到已畫出的狀態圖中。為此需在事件跟蹤圖中找出以前考慮過的腳本的分支點（例如“驗證賬戶”就是一個分支點，因為驗證的結果可能是“賬戶有效”，也可能是“無效賬戶”），然后把其他腳本中的事件序列并入已有的狀態圖中，作為一條可選的路徑。考慮完正常事件之后，再考慮邊界情況和特殊情況，其中包括在不適當時候發生的事件（例如，系統正在處理某個事務時，用戶要求取消該事務）。有時用戶（或外部設備）不能做出快速響應，然而某些資源又必須及時收回，于是在一定間隔后就產生了“超時”事件。對用戶出錯情況往往需要花費很多精力處理，并且會使原來清晰、緊湊的程序結構變得復雜、繁瑣，但是，出錯處理是不能省略的。當狀態圖覆蓋了所有腳本，包含了影響某類對象狀態的全部事件時，該類的狀態圖就構造出來了。2025/2/26597.2基本方法與過程(4)審查動態模型各個類的狀態圖通過共享事件合并起來，構成了系統的動態模型。在完成了每個具有重要交互行為的類的狀態圖之后，我們來檢查系統級的完整性和一致性。一般說來，每個事件都應該既有發送對象又有接受對象。對于沒有前驅或沒有后繼的狀態應該著重審查，如果這個狀態既不是交互序列的起點也不是終點，則發現了一個錯誤。基本系統模型由若干個數據源點/終點、及一個處理框組成，這個處理框代表了系統加工、變換數據的整體功能。由數據源點輸入的數據和輸出到數據終點的數據，構成了系統與外部世界之間交互事件的參數。2025/2/26607.3OOA實踐1:ATM系統本節以ATM系統為例來進一步詳細展示面向對象的分析過程。1).功能描述ATM系統的需求陳述如下：某銀行擬開發一個自動取款機系統，它是一個由自動取款機、中央計算機、分行計算機及柜員終端組成的網絡系統。ATM和中央計算機由總行投資購買。總行擁有多臺ATM，分別設在全市各主要街道上。分行負責提供分行計算機和柜員終端。柜員終端設在分行營業廳及分行下屬的各個儲蓄所內。該系統的軟件開發成本由各個分行分攤。銀行柜員使用柜員終端處理儲戶提交的儲蓄事務。儲戶可以用現金或支票向自己擁有的某個賬戶內存款或開新賬戶。儲戶也可以從自己的賬戶中取款。通常，一個儲戶可能擁有多個賬戶。柜員負責把儲戶提交的存款或取款事務輸進柜員終端，接收儲戶交來的現金或支票，或付給儲戶現金。柜員終端與相應的分行計算機通信，分行計算機具體處理針對某個賬戶的事務并且維護賬戶。2025/2/26617.3OOA實踐1:ATM系統11.擁有銀行賬戶的儲戶有權申請領取現金兌換卡。12.使用現金兌換卡可以通過ATM訪問自己的賬戶。13.目前僅限于用現金兌換卡在ATM上提取現金（即取款），或查詢有關自己賬戶的信息（例如，某個指定賬戶上的余額）。14.將來可能還要求使用ATM辦理轉賬、存款等事務。15.所謂現金兌換卡就是一張特制的磁卡，上面有分行代碼和卡號。16.分行代碼唯一標識總行下屬的一個分行，卡號確定了這張卡可以訪問哪些賬戶。17.通常，一張卡可以訪問儲戶的若干個賬戶，但是不一定能訪問這個儲戶的全部賬戶。18.每張現金兌換卡僅屬于一個儲戶所有，但是，同一張卡可能有多個副本，因此，必須考慮同時在若干臺ATM上使用同樣的現金兌換卡的可能性。19.也就是說，系統應該能夠處理并發的訪問。20.當用戶把現金兌換卡插入ATM之后，ATM就與用戶交互，以獲取有關這次事務的信息，并與中央計算機交換關于事務的信息。21.首先，ATM要求用戶輸入密碼，接下來ATM把從這張卡上讀到的信息以及用戶輸入的密碼傳給中央計算機，請求中央計算機核對這些信息并處理這次事務。22.中央計算機根據卡上的分行代碼確定這次事務與分行的對應關系，并且委托相應的分行計算機驗證用戶密碼。23.如果用戶輸入的密碼是正確的，ATM就要求用戶選擇事務類型（取款、查詢等）。24.當用戶選擇取款時，ATM請求用戶輸入取款額。25.最后，ATM從現金出口吐出現金，并且打印出賬單交給用戶。2025/2/26627.3OOA實踐1:ATM系統

圖7-1給出了系統的總體用例結構圖。涵蓋了需求陳述中描述的幾乎全部交互關系。圖7-2則以儲戶和ATM機之間的交互功能來給出詳細的用例。2025/2/26637.3OOA實踐1:ATM系統如圖7-2所示，銀行儲戶在ATM機上完成取款、存款及其他業務。在這里，參與者為“銀行儲戶”和ATM機。從系統需求描述中，我們知道ATM機目前僅限于用現金兌換卡在ATM上提取現金（即取款），或查詢有關自己賬戶的信息。將來可能還要求使用ATM辦理轉賬、存款等事務。因此我們在用例圖中僅有取款、存款及其余功能。其余功能即留作系統功能的擴展，包括存款，轉賬等。圖7-2ATM系統用例圖2025/2/26647.3OOA實踐1:ATM系統在此以取款用例為例來給出用例的詳細文本描述，如圖7-3所示。其中系統默認隨時有退卡功能，在此忽略。用例簡介:取款用例使得儲戶可以從ATM系統提取現金。詳細步驟描述:儲戶把現金兌換卡插入ATM；ATM要求儲戶輸入密碼，儲戶輸入密碼；如果儲戶輸入的密碼是正確的，ATM就要求用戶選擇事務類型（取款、查詢等），否則，提示密碼錯；儲戶選擇取款；ATM請求用戶輸入取款額，儲戶輸入取款額；ATM從現金出口吐出現金，并且打印出賬單交給儲戶。圖7-3取款用例描述2025/2/26657.3OOA實踐1:ATM系統2)類建模本節我們對ATM系統進行詳細分析，建立類圖模型。(1)主題劃分

首先我們根據問題域的關系對ATM系統進行主題劃分。整個銀行系統包括了賬戶庫、銀行儲戶庫及ATM系統三個主題，分別為圖中1,2,3所示。許多單個的賬戶組成了賬戶庫。許多銀行儲戶組成了儲戶庫。ATM系統包含了許多ATM機。2025/2/26667.3OOA實踐1:ATM系統(2)

類和對象的確定對象類的確定是在需求陳述的基礎上進行的。根據ATM系統需求陳述找到的候選類有：銀行自動取款機(ATM)系統中央計算機分行計算機柜員終端網絡總行市街道分行營業廳儲蓄所軟件成本柜員儲戶現金支票賬戶事務現金兌換卡余額磁卡分行代碼卡號副本訪問用戶信息密碼類型取款額賬單。在ATM系統的需求陳述中沒寫出的候選類：通信鏈路事務日志。對不正確或不必要的類和對象進行刪除，詳細過程如下：刪除冗余類。ATM系統的候選類中，”儲戶”與”用戶”，”現金兌換卡”與”磁卡”及”副本”分別描述了相同的二類信息；因此，應該去掉”用戶”、”磁卡”、”副本”等冗余的類，僅保留“儲戶”和“現金兌換卡”這兩個類。銀行自動取款機(ATM)系統中央計算機分行計算機柜員終端網絡總行市街道分行營業廳儲蓄所軟件成本柜員儲戶現金支票賬戶事務現金兌換卡余額分行代碼卡號訪問信息密碼類型取款額賬單用戶磁卡副本事務日志通信鏈路

2025/2/26677.3OOA實踐1:ATM系統刪除無關類。ATM系統并不處理分攤軟件開發成本的問題，而且ATM和柜員終端放置的地點與本軟件的關系也不大。因此，應該去掉候選類“成本”、“市”、“街道”、“營業廳”和“儲蓄所”。銀行自動取款機(ATM)系統中央計算機分行計算機柜員終端網絡總行分行軟件柜員儲戶現金支票賬戶事務現金兌換卡余額分行代碼卡號訪問信息密碼類型取款額賬單。成本市街道營業廳儲蓄所事務日志通信鏈路刪除籠統的類。“銀行”實際指總行或分行，“訪問”在這里實際指事務，“信息”的具體內容在需求陳述中隨后就指明了。此外還有一些籠統含糊的名詞。因此，在本例中應該去掉“銀行”、“網絡”、“系統”、“軟件”、“信息”、“訪問”等候選類。自動取款機(ATM)中央計算機分行計算機柜員終端總行分行柜員儲戶現金支票賬戶事務現金兌換卡余額分行代碼卡號密碼類型取款額賬單。銀行網絡系統軟件信息訪問事務日志通信鏈路2025/2/26687.3OOA實踐1:ATM系統刪除屬性。在ATM系統中，“現金”、“支票”、“取款額”、“賬單”、“余額”、“分行代碼”、“卡號”、“密碼”、“類型”等，實際上都應該作為屬性對待。因此，將它們從候選類中去除。自動取款機(ATM)中央計算機分行計算機柜員終端總行分行柜員儲戶賬戶事務現金兌換卡現金支票取款額賬單余額分行代碼卡號密碼類型事務日志通信鏈路刪除操作。在ATM系統中，沒有此類操作。刪除實現。在ATM系統中，“事務日志”無非是對一系列事務的記錄，它的確切表示方式是面向對象設計的議題；“通信鏈路”在邏輯上是一種聯系，在系統實現時它是關聯鏈的物理實現。總之，應該暫時去掉“事務日志”和“通信鏈路”這兩個類，在設計或實現時再考慮它們。自動取款機(ATM)中央計算機分行計算機柜員終端總行分行柜員儲戶賬戶事務現金兌換卡事務日志通信鏈路2025/2/26697.3OOA實踐1:ATM系統經過以上篩選步驟最終確定系統所需的類：自動取款機(ATM)中央計算機分行計算機柜員終端總行分行柜員儲戶賬戶事務現金兌換卡(3)確定關聯直接提取動詞短語得出的關聯：ATM,中央計算機,分行計算機及柜員終端組成網絡總行擁有多臺ATM。ATM設在主要街道上分行提供分行計算機和柜員終端柜員終端設在分行營業廳及儲蓄所內分行分攤軟件開發成本儲戶擁有賬戶柜員輸入針對賬戶的事務柜員終端與分行計算機通信分行計算機處理針對賬戶的事務分行計算機維護賬戶系統處理并發的訪問ATM與用戶交互ATM與中央計算機交換關于事務的信息ATM讀現金兌換卡中央計算機確定事務與分行的對應關系ATM吐出現金ATM打印賬單2025/2/26707.3OOA實踐1:ATM系統需求陳述中隱含的關聯：總行由各個分行組成分行保管賬戶總行擁有中央計算機系統維護事務日志系統提供必要的安全性儲戶擁有現金兌換卡根據問題域知識得出的關聯：現金兌換卡訪問賬戶分行雇用柜員2025/2/26717.3OOA實踐1:ATM系統對關聯進行篩選，詳細過程如下：已刪去的類之間的關聯。如果在分析確定類和對象的過程中已經刪掉了某個候選類，則與這個類有關的關聯也應該刪去，或用其他類重新表達這個關聯。以ATM系統為例，由于已經刪去了系統、網絡、市、街道、成本、軟件、事務日志、現金、營業廳、儲蓄所、賬單等候選類，因此，與這些類有關的下列八個關聯也應該刪去。ATM、中央計算機、分行計算機及柜員終端組成網絡。ATM設在主要街道上。柜員終端設在分行營業廳及儲蓄所內。分行分攤軟件開發成本。ATM吐出現金。ATM打印賬單。系統維護事務日志。系統提供必要的安全性。與問題無關或應在實現階段考慮的關聯。即處在本問題域之外的關聯或與實現密切相關的關聯。例如，在ATM系統的例子中，“系統處理并發的訪問”并沒有標明對象之間的新關聯，它只不過提醒我們在實現階段需要使用實現并發訪問的算法，以處理并發事務。2025/2/26727.3OOA實踐1:ATM系統瞬時事件。關聯描述問題域的靜態結構，因此瞬時事件應該刪除。以ATM系統為例，“ATM讀現金兌換卡”描述了ATM與用戶交互周期中的一個動作，它并不是ATM與現金兌換卡之間的固有關系，因此應該刪去。類似地，還應該刪去“ATM與用戶交互”這個候選的關聯。三元關聯。三個或三個以上對象之間的關聯，大多可以分解為二元關聯或用詞組描述成限定的關聯。例如，“柜員輸入針對賬戶的事務”可以分解成：“柜員輸入事務”和“事務修改賬戶”；“分行計算機處理針對賬戶的事務”可以分解成：“分行保管賬戶”和“事務修改賬戶”；“ATM與中央計算機交換關于事務的信息”可以分解成：“ATM與中央計算機通信”和“ATM上輸入事務”。如果三元關聯中涉及的某個實體僅用于描述另兩個實體的關系，而且這個實體本身不包含屬性，則它是二元關聯上的鏈屬性。例如，“公司付給員工工資”可以改造成帶有鏈屬性“工資”的二元關聯“公司雇用員工”。派生關聯。可以用其他關聯定義的關聯。例如，“總行擁有多臺ATM”實質上是“總行擁有中央計算機”和“ATM與中央計算機通信”這兩個關聯組合的結果。而“分行計算機維護賬戶”的實際含義是，“分行保管賬戶”和“事務修改賬戶”。2025/2/26737.3OOA實踐1:ATM系統經過以上處理，最終得到ATM系統中的所有關聯如下：總行由各個分行組成總行擁有中央計算機中央計算機與分行通信ATM與中央計算機通信分行擁有分行計算機分行擁有柜員終端柜員終端與分行計算機通信分行雇用柜員柜員輸入柜員事務柜員事務輸入柜員終端柜員事務修改賬戶分行保管賬戶儲戶擁有賬戶儲戶擁有現金兌換卡遠程事務由現金兌換卡授權在ATM上輸入遠程事務遠程事務修改賬戶現金兌換卡訪問賬戶2025/2/26747.3OOA實踐1:ATM系統(4)確定屬性

從需求陳述中可以得到帳戶具有帳戶類型、帳戶號、余額三個屬性。柜員事務則包括時間，日期和金額三個屬性。銀行儲戶及ATM機兩個類包含哪些屬性，如下頁圖7-5都一目了然。

2025/2/26757.3OOA實踐1:ATM系統2025/2/26767.3OOA實踐1:ATM系統(5)識別繼承和組合進一步考慮繼承和組合的因素對類進行組織。使用兩種方式建立繼承關系：自底向上：在ATM系統中，“遠程事務”和“柜員事務”是類似的（它們都“修改”帳戶），可以泛化出父類“事務”；類似地，可以從“ATM”和“柜員終端”（它們都“輸入”事務）泛化出父類“輸入站”。自頂向下：“現金兌換卡”類實際上有兩個相對獨立的功能，即鑒別儲戶使用ATM的權限的卡：“卡權限”和ATM獲得分行代碼和卡號等數據的數據載體：“現金兌換卡”。“卡權限”類標志儲戶訪問賬戶的權限，“現金兌換卡”類是含有分行代碼和卡號的數據載體。多張“現金兌換卡”可能對應著相同的“卡權限”。因此應將類“現金兌換卡”分解為兩個類“現金兌換卡”和“卡權限”。另外，“事務”和“更新”之間是組合關系。通常，一個事務包含對賬戶的若干次更新，這里所說的更新，指的是對賬戶所做的一個動作（取款、查詢）。“更新”雖然代表一個動作，但是它有自己的屬性（類型、金額等），應該獨立存在，因此把它作為類。這樣我們得到新的類圖7-6。2025/2/26777.3OOA實踐1:ATM系統圖7-6迭代后的ATM機類圖2025/2/26787.3OOA實踐1:ATM系統2)動態建模

為建立動態模型，我們首先考慮ATM系統的使用過程。寫出ATM系統的用例腳本。考慮其正常腳本，及異常腳本。這里異常指用戶不合法操作。以下給出一個正常情況腳本和一個異常情況腳本。ATM系統的正常情況腳本：ATM請儲戶插卡；儲戶插入一張現金兌換卡。ATM接受該卡并讀它上面的分行代碼和卡號。ATM要求儲戶輸入密碼；儲戶輸入自己的密碼“1234”等數字。ATM請求總行驗證卡號和密碼；總行要求“39”號分行核對儲戶密碼，然后通知ATM說這張卡有效ATM要求儲戶選擇事務類型（取款、轉賬、查詢等）；儲戶選擇“取款”。ATM要求儲戶輸入取款額；儲戶輸入“880”。ATM確認取款額在預先規定的限額內，然后要求總行處理這個事務；總行把請求轉給分行，該分行成功地處理完這項事務并返回該賬戶的新余額。ATM吐出現金并請儲戶拿走這些現金；儲戶拿走現金。ATM問儲戶是否繼續這項事務；儲戶回答“不”。ATM打印賬單，退出現金兌換卡，請儲戶拿走它們；儲戶取走賬單和卡。ATM請儲戶插卡。2025/2/26797.3OOA實踐1:ATM系統ATM系統的異常情況腳本：ATM請儲戶插卡；儲戶插入一張現金兌換卡。ATM接受這張卡并讀它上面的分行代碼和卡號。ATM要求密碼；儲戶誤輸入“8888”。ATM請求總行驗證輸入的數字和密碼；總行在向有關分行咨詢之后拒絕這張卡。ATM顯示“密碼錯”，并請儲戶重新輸入密碼；儲戶輸入“1234”；ATM請總行驗證后知道這次輸入的密碼正確。ATM請儲戶選擇事務類型；儲戶選擇“取款”。ATM詢問取款額；儲戶改變主意不想取款了，他敲“取消”鍵。ATM退出現金兌換卡，并請儲戶拿走它；儲戶拿走他的卡。ATM請儲戶插卡。

2025/2/26807.3OOA實踐1:ATM系統

根據ATM的用例腳本出發畫出狀態圖。將各腳本描述的狀態轉換逐次添加到原圖上，得到最后的狀態圖，如圖7-7,7-8和圖7-9。針對系統腳本，三個圖分別從系統不同層次對類的交互行為進行了描述。狀態圖的詳細作用及繪制方法參見第五章。2025/2/26817.3OOA實踐1:ATM系統2025/2/26827.4OOA實踐2：電梯控制系統

7.4OOA實踐2：電梯控制系統1)功能描述電梯的抽象用例圖如下：圖7-10電梯控制系統用例圖2025/2/26837.4OOA實踐2：電梯控制系統電梯控制系統面向對象的分析，電梯系統我們在第三章提到過。在這里我們對電梯系統進行更詳細的描述，需求陳述如下：(1)有樓高為N層的大廈，需要安裝電梯；(2)

除底層和頂層僅有一個單向按鈕，其它樓層均安裝“上▲”、“下▼”兩個按鈕；(3)

電梯內有1~N個數字按鈕和“開”、“關”按鈕；每個數字按鈕代表一個樓層。當按下一個數字按鈕時，該數字按鈕指示燈亮。當電梯到達相應樓層時，該摟層對應數字按鈕指示燈滅。(4)

電梯在單向運行中，如“上升”：若在“上升需求”或“到達需求”中有高于目前樓層的需求存在或有更高的“下降需求”，方向不變，運行至上一樓層位置；(5)

否則運行反向，在若在“下降需求”或“到達需求”中有低于目前樓層的需求存在或有更低的“上升需求”，運行至下一樓層位置；若無任何需求，關門，停止運行，等待；(6)

到達需求樓層位置，若有到達需求或上升需求，或滿足反向條件，開門，保持20秒鐘，或響應“開”、“關”按鈕動作，在關門2秒鐘后，重復(3)；2025/2/26847.4OOA實踐2：電梯控制系統2)類建模從系統需求中我們得到候選類：按鈕，電梯，樓層，運行，大廈，指示燈，請求，門。其中，樓層、大廈是處于問題邊界以外的名詞，應該刪除。運行是抽象名詞，沒有實際意義，因此刪去。指示燈、請求都可以作為按鈕的屬性。最后我們得到三個類：電梯，按鈕和門。對于按鈕，根據需求中指定的兩種類型，進行抽象繼承，得到兩個子類：電梯按鈕和樓層按鈕。由此得到電梯控制系統的基本類模型。

圖7-11電梯控制系統的基本類模型

2025/2/26857.4OOA實踐2：電梯控制系統

在實際的電梯中，按鈕并不直接與電梯通信，按鈕響應與電梯之間的對應關系必須由某種類型的電梯控制器來負責。因此，我們增加電梯控制器類。電梯控制器處理請求并控制按鈕指示燈的亮與滅。另外，打開和關閉電梯門的唯一辦法是向“電梯門”對象發送一條消息，如果在錯誤的時間關閉或打開電梯門是很危險的。為了更好的保證電梯運行的安全，將電梯門從電梯分離出來，分別對它們進行控制。經過以上步驟，得到類圖:2025/2/26867.4OOA實踐2：電梯控制系統3)動態建模電梯控制系統中，用戶的任何輸入都是合法的。因此對其進行動態建模，只需考慮電梯的調度原則。而其狀態圖也恰恰只描述電梯的所有可能事件，及其交互過程。如圖7-13所示，電梯控制系統，即電梯事件循環狀態，不停的監視由按鈕對象發送來的消息，根據電梯運動現狀，選擇電梯移動方向。例如，當電梯移動一樓層時，處于“決定是否停止”狀態，此時則需要對當前請求隊列進行檢查，若無停留在該樓層的請求，則繼續移動，否則，要“停在樓層”，開門并啟動定時器。2025/2/26877.4OOA實踐2：電梯控制系統圖7-13電梯系統類圖2025/2/26887.5小結

7.5小結

面向對象的分析OOA（Object-OrientedAnalysis）是面向對象方法從編程領域向分析領域延伸的產物，充分體現了面向對象的概念與原則。面向對象的分析方法，強調從問題域中的實際事物及與系統責任有關的概念出發，來構造系統模型、與問題域具有一致的概念和術語，同時盡可能使用符合人類的思維方式來認識和描述問題域，有利于對問題及系統責任的理解以及人員之間的交流。再加上面向對象本身的封裝、繼承和多態等特征，OOA對需求變化有較強的適應性，并且很好的支持了軟件復用。在本章中，我們介紹了OOA的分析原則及詳細分析過程，并以ATM系統以及電梯調度系統開發為例，詳細說明了OOA分析中三種模型即用例模型、靜態模型和動態模型的建模過程。

SoftwareEngineering軟件工程精品課程第九章實現與測試

9.1重用性（reuse） 人們在開發一件新的產品時,往往會直接使用大量的成熟部件,這些被重新使用的軟件模塊和程序，稱為組件（component）。而在新的軟件開發中選用原有組件的方法，就是軟件重用。 軟件重用有兩種類型，第一種是意外（accidental）重用，另一種是預備（deliberate）重用。 隨著組件技術的不斷發展，軟件重用成為軟件開發的主要指標之一。第九章實現與測試9.1.2對象與重用 面向對象的程序設計，將數據結構及其之上的操作封裝起來，對外具有統一的接口定義和數據傳遞關系。這樣一種模式，為軟件重用技術的應用帶來了極大的便利。9.1.3

重用在軟件的各個階段 應用架構的重用

1.軟件設計階段的重用 設計模式的重用 軟件架構的重用

第九章實現與測試

2.軟件實現階段的重用選擇合適的組件、繼承和集成現有的軟件模塊，已經是軟件實現階段的重要任務。3.軟件維護階段的重用軟件重用對軟件維護帶來的好處，軟件的維護可以象機械設備的維修一樣進行部件（組件）的更換。當然我們知道軟件部件是不會磨損的，需要更換的軟件組件要么是有錯誤，要么是需要升級。

第九章實現與測試第四代語言第三代語言第二代語言

第一代語言面向問題描述的更自然的語言高級語言Fortran、BASIC、C匯編語言機器語言，即01代碼9.2選擇編程語言9.2.1編程語言的類型第九章實現與測試9.2.2快速原型語言

快速原型語言，是要在短時間內以直觀的方式展現用戶的需求。 快速原型語言的要求，一是快，二是直觀，圖形化的顯示。

建立原型的目的，是為了方便與用戶的溝通，而不是軟件的設計，僅需要描述軟件的外部特性而不是內部實現！

第九章實現與測試9.2.3最終實現語言 當我們實現一個軟件產品的模塊編程（coding）時，應該選擇什么樣的實現語言呢？選擇語言時，卻應該遵循一些基本的準則：選擇客戶具有經驗和支持工具的語言選擇適合應用特點的語言選擇信息內聚性最大的語言選擇具有最佳成本-效率比的語言選擇風險最小的語言第九章實現與測試9.3好的編程風格與原則

編程風格的基本要求：

使用一致的、有意義的變量命名注釋語句的必要性避免模糊、復雜的算法使用常量學會代碼的版面設計嵌套的

if語句第九章實現與測試9.4單元測試

關于軟件測試的工作，應該從軟件一開始的需求階段就包含進來，并且一直貫穿軟件生命周期的全過程。

軟件測試的目標為：

1.檢查軟件代碼是否達到軟件設計的功能與性能要求

2.盡可能發現代碼中存在的錯誤。

第九章實現與測試

針對軟件測試的兩個目標，從測試方法的角度，可以分為兩種測試的方法。

1.以軟件設計為標準，檢查軟件代碼是否滿足了軟件設計的要求----黑盒測試。

2.以軟件代碼為對象，檢查已完成的代碼中是否存在錯誤----白盒測試。

第九章實現與測試9.4.1黑盒測試

黑盒測試，是在不了解軟件代碼的條件下，檢測軟件是否達到的設計的要求。因為不了解程序的內部結構，測試數據就要從輸入數據和輸出數據上分析了。 對于黑盒測試而言，是檢測軟件是否達到設計的要求，即軟件的功能要求。因此測試用例的另一個生成標準，就是覆蓋軟件模塊的所有功能。

第九章實現與測試9.4.2白盒測試

白盒測試是基于代碼的測試，也稱為基于軟件結構的測試。白盒測試更注重于代碼自身的質量，而不是其要實現的功能。 白盒測試從軟件代碼出發，測試用例的選擇都是基于代碼的語句、結構和路徑的構成，測試的目的，就是盡可能覆蓋代碼的所有運行，從而發現其中的錯誤。 語句覆蓋（statementcoverage） 分支覆蓋（branchcoverage） 路徑覆蓋（pathcoverage）

第九章實現與測試9.4.3其他審查1）代碼走查（CodeWalkthroughs） 在軟件描述和編碼階段，對于軟件設計師和程序員完成的文檔和代碼，如果能夠有其他富有經驗的設計師和程序員重讀檢查，往往會發現許多存在的錯誤。而當進行重讀檢查的人員不止一人時，這種對文檔和代碼的重新檢查，往往能夠發現文檔和代碼的所有錯誤和問題。第九章實現與測試2）代碼視察（CodeInspections） 代碼視察是一種更規范的重讀方式，人員組成與代碼走查類似。一般由3~6人組成，包括當前階段（實現與測試階段）的代表和下一階段（集成測試）的代表、一個成員扮演團隊的協調者來領導和管理團隊、還有一個成員是記錄者，負責記錄代碼視察中發現的錯誤。

3）正確性證明（CorrectnessProofs）

正確性證明，是用形式化、數學的方法證明一段程序代碼滿足了輸入、輸出的要求。這是唯一能夠證明程序正確的方法。第九章實現與測試4）復雜性描述（ComplexityMetrics）

盡管復雜性描述更象一個白盒測試方法，它依賴于被測試的程序代碼，但它并不對程序進行測試，而只是表明程序的復雜性和哪個程序更需要被測試。

5）錯誤統計與可靠性分析（FaultStatisticsandReliabilityAnalysis）

錯誤統計提供了一個有用的體系來決定是否繼續測試一個模塊，還是重新編寫。在程序測試中，不論是白盒、黑盒還是走查，所有的錯誤被按照不同錯誤級別記錄下來，為軟件質量的評價提供了依據。第九章實現與測試6）靜室技術（TheCleanroomTechnique）

靜室技術是多種軟件開發技術的集成，包括了正確性證明、代碼審查、錯誤統計與可靠性分析等一系列技術方法。靜室技術的核心思想是：通過在第一次正確地書寫代碼增量并在測試前驗證它們的正確性，從而避免成本很高的錯誤消除過程。

第九章實現與測試9.4.4測試方法的評價與選擇

上面介紹了黑盒測試、白盒測試、程序走查等一系列軟件測試方法，究竟那種軟件測試方法最有效呢？ 實驗結果，并不能證明有哪一種測試方法具有明顯的優勢。黑盒測試、白盒測試、程序走查作為三種典型的軟件測試方法，各具有自己的優點和不足。當然，其中程序走查方法的費用要高于黑盒測試和白盒測試。第九章實現與測試9.5集成測試

軟件產品總是由許多不同功能的模塊組成的，當完成模塊編碼和單元測試工作后，就需要進行軟件的集成測試工作。

考慮如圖所示的模塊結構組成的軟件。

第九章實現與測試9.5.1自頂向下測試（Top-Down）

自頂向下的集成測試，優點是能夠及早發現軟件的需求錯誤、邏輯故障、結構錯誤等軟件的重要錯誤。 一類稱為邏輯模塊（Logicmodules），就是一般比較靠近根部的模塊，這類模塊往往是關于程序邏輯、結構、控制的模塊。 另一類稱為操作模塊（operationalmodules），一般是調用的最底層模塊，這類模塊往往是執行一些具體的操作，如輸入、輸出或硬件的驅動等。 自頂向下集成測試的缺點，正是因為從邏輯模塊開始，而導致對操作模塊的測試不足。

第九章實現與測試9.5.2自底向上測試（Bottom-Up）

自底向上的測試方法，對操作模塊的測試是充分的，因為在測試操作模塊時，可能尚不清楚本軟件對操作模塊的具體要求，所以會對操作模塊的全部功能都進行完全的測試。保證了對操作模塊測試的充分性。

自底向上的測試方法，因為將邏輯模塊的測試放在了后期，所以軟件的需求錯誤、結構錯誤都會較晚發現，甚至出現對操作模塊的完全測試，因為需求的錯誤，而變成完全無用的模塊。第九章實現與測試9.5.3三明治測試 仍然考慮圖9-9的軟件模塊，我們把模塊a，b，c，d，g，I當作邏輯模塊；把模塊e，f，h，i，k，l，m作為操作模塊。那么，我們可以對邏輯模塊采用自頂向下的測試方法，而對操作模塊，采用自底向上的測試方法。并且可以同時開始兩個小組的測試工作。這樣，我們既可以在早期就發現軟件需求、結構和邏輯上的錯誤，又可以保證對操作模塊測試的充分性。第九章實現與測試方法優點不足整體測試—錯誤定位難主要設計錯誤發現較晚自頂向下錯誤定位主要設計錯誤發現早重用模塊測試測試不足自底向上錯誤定位重用模塊測試充分主要設計錯誤發現晚三明治錯誤定位主要設計錯誤發現早重用模塊測試充分—集成測試方法總結第九章實現與測