計算機管理信息系統(tǒng)章

計算機管理信息系統(tǒng)章第一頁，共五十七頁，編輯于2023年，星期五2023/6/251第8章運行與維護10.1模型的作用借助于模型實現(xiàn)對復(fù)雜系統(tǒng)的認識，是一種有效手段；實際的管理信息系統(tǒng)是一個復(fù)雜的系統(tǒng)，我們要開發(fā)以計算機處理為基礎(chǔ)的現(xiàn)代管理信息系統(tǒng)，首先就得認識、理解原有的系統(tǒng)或手工業(yè)務(wù)，經(jīng)過反復(fù)討論和修改以后，構(gòu)造出新的管理信息系統(tǒng)方案。在這一過程中，模型起著非常關(guān)鍵的作用。模型可以幫助我們以化簡的形式捕捉現(xiàn)實系統(tǒng)中問題的本質(zhì)；通過模型可以把被討論的概念可視化，把你心目中的系統(tǒng)實現(xiàn)方案勾勒出來，把它變成大家能夠看得見的東西，便于討論和修改；模型有助于在由“問題”到“方案”的過渡過程中更好的認知、理解和溝通。結(jié)論：學(xué)習(xí)建模是學(xué)習(xí)軟件開發(fā)（包括管理信息系統(tǒng)開發(fā)）的一項基本技能。第二頁，共五十七頁，編輯于2023年，星期五2023/6/252第8章運行與維護10.1模型的作用10.1.1什么是模型10.1.2建模的價值第三頁，共五十七頁，編輯于2023年，星期五2023/6/253第8章運行與維護10.1.1什么是模型模型并不深奧。在你和別人討論問題時，把你想表達的東西以簡化的形式畫到紙上，這就是模型，哪怕是隨便勾畫了幾筆，只要有助于表達問題，它就是模型了。模型可以描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，也可以描述系統(tǒng)的動態(tài)行為；可以描述系統(tǒng)的宏觀面貌，也可以描述系統(tǒng)內(nèi)的微觀交互場景。簡單地講，模型是對現(xiàn)實的簡化、或者說，模型是簡化的現(xiàn)實；模型會先于方案而存在，模型提供了營造方案的藍圖。第四頁，共五十七頁，編輯于2023年，星期五2023/6/254第8章運行與維護建模是有目的建模的目的，是為了認識復(fù)雜的問題（或系統(tǒng)）；簡化是認識復(fù)雜系統(tǒng)的一種有效方法；而建模是簡化問題的有效手段；“簡化”是有目的的進行的準確地講，一個具體的模型是人對現(xiàn)實系統(tǒng)抽象認知的結(jié)果，這一結(jié)果取決于人和他觀察問題的角度。人是認知活動的主體，他在認識一個事物的時候，往往是帶有主觀意志的，即他會從自己的立場或角度來看問題。從某個角度看問題，排除不必要的干擾，把問題化簡，抓住主要矛盾和事物的本質(zhì)，這就是建模的目的。打一個比方，一座大樓在土木設(shè)計師眼里可能是一堆鋼筋混凝土和表面材質(zhì)；在管道設(shè)計師眼里可能是一堆管子和接頭；在網(wǎng)絡(luò)工程師眼里可能是一堆網(wǎng)絡(luò)設(shè)備和布線。不同主體對同一客體的認識結(jié)果有賴于各自的視角，即看問題的角度。這樣能更好地集中注意力，從而有效地解決關(guān)鍵問題。第五頁，共五十七頁，編輯于2023年，星期五2023/6/255第8章運行與維護建模是有原則的在建立模型的過程中，建模者的主觀立場或認識問題的角度，被強調(diào)為認知活動的原則，這很重要。建模過程就是簡化問題的過程，就是要把某些主要的關(guān)鍵的東西勾勒出來，把對討論問題無關(guān)緊要的東西暫時略去，以免干擾視線。因此，在討論一個系統(tǒng)中的某個問題的時候，我們不是把整個系統(tǒng)都詳細地表述出來以后再進行討論，而習(xí)慣于從某個角度整理出一個從某個側(cè)面觀察的問題模型，這就是建模的原則。對于一個系統(tǒng)，基于不同的簡化動機（目的）和簡化水平（原則），可以得到多個模型，這樣有助于更深刻和更準確地把握系統(tǒng)的本質(zhì)。第六頁，共五十七頁，編輯于2023年，星期五2023/6/256第8章運行與維護對模型的評價利用價值高的模型就是好模型；針對特定的建?！皠訖C”和“原則（抽象層次）”，我們通常會忽略那些與特定抽象層次無關(guān)的次要因素，而強調(diào)那些具有廣泛影響力的主要因素，這就是在追求模型的使用價值。換言之，內(nèi)容多的模型未必是好模型，因為價值高的內(nèi)容有可能被價值不高的內(nèi)容淹沒了。模型的的好壞，取決于兩個因素，即建模的“視角（動機）”和“抽象層次”，這兩個因素決定了模型有沒有把握問題的本質(zhì)和有沒有洽到好處的排除掉干撓視線的次要因素，便于清晰的認識問題。第七頁，共五十七頁，編輯于2023年，星期五2023/6/257第8章運行與維護模型的表述模型是一組具有完整語義的信息，包括兩個方面的含義：一方面，模型是對現(xiàn)實的簡化；另一方面，模型反映了認知主體（開發(fā)人員）對問題域認識的視角和抽象層次。不同的視角，表現(xiàn)為各種類型的圖（Diagram）及其包含的元素和關(guān)聯(lián)；不同的抽象層次，表現(xiàn)為不同類型的視圖（View）。兩者都是模型不可或缺的要素。盡管說模型是簡化的現(xiàn)實，并強調(diào)化簡價值，但這并不意味著可以片面地夸大圖示信息的作用，好的模型應(yīng)該是圖文并茂，其關(guān)鍵是可用和易用。第八頁，共五十七頁，編輯于2023年，星期五2023/6/258第8章運行與維護10.1.2建模的價值建模（Modeling）是捕捉問題本質(zhì)的過程。為了降低風(fēng)險和獲得高回報，建模活動普遍應(yīng)用于各種行業(yè)，信息系統(tǒng)（軟件）開發(fā)更不例外。為了說明建模的價值，GradyBooch曾經(jīng)給出過一個經(jīng)典的類比：蓋一個寵物窩棚、修一個鄉(xiāng)間別墅和建一座摩天大樓，三種工作對建筑規(guī)劃圖紙的依賴程度有質(zhì)的差異。建立一個簡單的系統(tǒng)，模型可有可無；建立一個比較復(fù)雜的系統(tǒng)，模型的必要性增大；建立一個高度復(fù)雜的系統(tǒng)，模型則不可缺少。應(yīng)用處理簡單系統(tǒng)的方法對待復(fù)雜系統(tǒng)通常是行不通的，這好比用搭建一個寵物窩棚的方法來營造一座摩天大廈。建模的意義隨著系統(tǒng)復(fù)雜程度的增加而越發(fā)顯著，從起初借助于模型以更好地理解系統(tǒng)，到后來不得不借助模型來理解系統(tǒng)。人腦對復(fù)雜問題的理解能力是有限的，與模型相應(yīng)的特定視角和抽象層次是簡化復(fù)雜問題的有效出發(fā)點。第九頁，共五十七頁，編輯于2023年，星期五2023/6/259第8章運行與維護建模對于復(fù)雜軟件系統(tǒng)的開發(fā)是必要的目前，我們開發(fā)的軟件，特別是商業(yè)軟件，通常一開始就很不簡單，并且復(fù)雜性隨著時間的演進和技術(shù)的發(fā)展持續(xù)上升。一個復(fù)雜軟件系統(tǒng)的開發(fā)必須面對多種未知因素、多個開發(fā)人員、復(fù)雜的開發(fā)工具和永遠不夠用的時間。開發(fā)人員不可能、更沒有必要去了解從問題到方案的所有細節(jié)。他們需要那些基于特定視角的、有助于解決問題的并且是完整的某一部分信息，即所謂的模型。總之，建模對于復(fù)雜軟件系統(tǒng)的開發(fā)是必要的。建?；顒邮怯幸庾R的、有目的、有原則、有計劃的嚴密工作廣義上講，無論出于何種動機，只要在問題到方案之間做出一些過渡性的努力，哪怕只是在草稿或白板上畫了幾筆，實際上就是在建模了。不過有意識和無意識的建?；顒訉δＰ偷馁|(zhì)量或價值的影響很大。有意識的建?；顒油ǔＪ怯杏媱澋?、有準備的和早動手的。通過這樣的建模活動，得到的模型通常是完整的、一致的和可復(fù)用的。無意識的建?；顒?，通常是隨機的、無準備的和補救性的，得到的模型往往是零散的、混亂的和一次性的。準確地講，建?；顒又庇^地記錄下認知和求解過程，支持團隊成員之間的有效溝通，為重復(fù)利用各個階段積累的智力成果創(chuàng)造了有利的條件。概括地講，建模簡化了認知過程，化簡了求解過程。第十頁，共五十七頁，編輯于2023年，星期五2023/6/2510第8章運行與維護10.2統(tǒng)一建模語言UML為了表達問題，你可以使用任何能夠說明問題的圖形符號、文字、表格、線條等，只要能說明問題，所有這些都可以作為建模的工具。在管理信息系統(tǒng)的開發(fā)過程中，建模是必不可少的。在結(jié)構(gòu)化的系統(tǒng)分析與設(shè)計過程中，我們學(xué)過的主要建模工具包括數(shù)據(jù)流圖、數(shù)據(jù)字典、結(jié)構(gòu)圖等；UML則是面向?qū)ο蟮拈_發(fā)方法中使用的主要建模工具之一。統(tǒng)一建模語言UML，全稱是UnifiedModelingLanguage。掌握UML的建模技術(shù)，是面向?qū)ο蠓治雠c設(shè)計的基本技能之一。第十一頁，共五十七頁，編輯于2023年，星期五2023/6/2511第8章運行與維護JimRumbaugh是IBM杰出的工程師，如今他正領(lǐng)導(dǎo)IBMRational分部的軟件建模工作。他和GradyBooch、IvarJacobson并稱為發(fā)明UML的“三友”，UML在1997年被國際對象組織接收為建模標準。他也參與了RUP的開發(fā)并且曾經(jīng)是面向?qū)ο蠓治雠c設(shè)計方面的OMT的主要開發(fā)者。上周，InfoWorld編輯在在SantaClara召開的SDWest2005會議上對Rumbaugh進行了訪談，討論了UML、SOA(service-orientedarchitectures)和ESB(enterpriseservicebus)技術(shù)。Rumbaugh對微軟及其在UML上的騎墻姿勢表示了不屑。第十二頁，共五十七頁，編輯于2023年，星期五2023/6/2512第8章運行與維護UML的來歷20世紀90年代初，很多面向?qū)ο蟮姆椒ㄒ呀?jīng)擁有自己的符號體系，其中有三種比較突出：JimRumbaugh的OMT方法，GradyBooch的Booch方法IvarJacobson的OOSE方法。不同的方法和符號體系各有所長：OMT擅長分析，Booch擅長設(shè)計，OOSE則擅長業(yè)務(wù)建模。那個時期的面向?qū)ο蠹夹g(shù)人員沒有我們這么幸運，為了建立比較豐滿的模型并進行有效的溝通，他們需要掌握不同的符號體系，并且花費一些精力去翻譯和轉(zhuǎn)述用不同符號體系表述的模型。第十三頁，共五十七頁，編輯于2023年，星期五2023/6/2513第8章運行與維護UML的來歷在后來的幾年中，上述三位大師在各自的著作中自然而然地融入了其他兩種方法的技術(shù)內(nèi)容。JimRumbaugh于1994年離開GE加入GradyBooch所在的Rational公司，開始和GradyBooch協(xié)同研究一種統(tǒng)一的方法。一年后，UnifiedMethod0.8誕生了。同年，Rational收購了IvarJacobson所在的Objectory公司，IvarJacobson從此也成為Rational的一員。UnifiedMethod不久更名為UML。仰仗三位面向?qū)ο蠓椒▽W(xué)大師的威望，基于數(shù)十位業(yè)內(nèi)重量級人物歷時兩年的通力合作，并充分考慮到多個合作伙伴的反饋意見，UML一步步趨于成熟。1997年9月，UML1.1被提交到國際對象管理組織，同年11月被該組織認定為標準的建模語言。統(tǒng)一建模語言，顧名思義有三個要點：統(tǒng)一（Unified）、建模（Modeling）和語言（Language）。第十四頁，共五十七頁，編輯于2023年，星期五2023/6/2514第8章運行與維護把握UML的優(yōu)勢和學(xué)習(xí)方法“統(tǒng)一”是UML的核心。它提升了開發(fā)團隊的溝通效率，節(jié)約了以往用于翻譯和轉(zhuǎn)述的開銷，屏蔽了藏匿于含糊語義中的風(fēng)險。在傳統(tǒng)的方法中，它們各自擁有專用的符號系統(tǒng)，這也是長期以來潛在的溝通壁壘，而使用UML表述的內(nèi)容能被各類人員所理解，包括用戶、領(lǐng)域?qū)＜?、分析師、設(shè)計師、程序員、測試人員和培訓(xùn)師等。通過UML，他們可以充分地理解并表述自己所關(guān)注的那部分內(nèi)容?！敖！斌w現(xiàn)了UML的使用價值。UML在制定過程中汲取了多種建模方法的精華，包括業(yè)務(wù)建模和數(shù)據(jù)建模等。UML的使用價值不可能脫離特定類型的建?；顒?。對于學(xué)習(xí)者而言，如果以掌握UML的符號和規(guī)則為最終目的，你將所獲甚微。盡管UML所表述的內(nèi)容可以貫穿系統(tǒng)開發(fā)的整個生命周期，但UML不同于普通的程序設(shè)計語言，所以僅僅掌握UML的符號和規(guī)則并不能得到實際的解決方案。第十五頁，共五十七頁，編輯于2023年，星期五2023/6/2515第8章運行與維護把握UML的優(yōu)勢和學(xué)習(xí)方法“語言”是UML的普遍價值的表現(xiàn)語言的一層基本含義是一套按照特定規(guī)則和模式組成的符號系統(tǒng)，被擁有相同傳統(tǒng)和習(xí)慣的人群所使用。我們在日常生活中將“擁有共同語言”看做是能夠有效溝通的必要條件。近年來，軟件開發(fā)所涉及的技術(shù)飛速發(fā)展，不同技術(shù)門類所使用的建模語言自成體系，同時也具有很大的局限性，表現(xiàn)形式的差異往往掩蓋了本質(zhì)內(nèi)容的相通。幸好，與人類的自然語言不同的是，在軟件開發(fā)過程中使用的建模語言不涉及宗教和文化等諸多歷史或地域障礙。在博采眾長的基礎(chǔ)上，UML作為一種共通的和可擴展的語言，其描述能力適用于軟件開發(fā)中各種技術(shù)門類的建?；顒印Ｗ匀徽Z言是人類對客觀世界建模最直接有效的表述形式；類似地，UML是迄今為止，軟件開發(fā)人員進行統(tǒng)一建?；顒幼钪苯佑行У谋硎鲂问?。不僅如此，UML還是能被軟件開發(fā)環(huán)境所理解的語言。通常，我們沒必要在掌握所有的詞匯和語法之后才開始使用一種語言。掌握語言的關(guān)鍵在于有目的地使用，學(xué)習(xí)UML的情況很類似。在開始階段，基于一個明確目標，集中精力理解一些必要的詞匯和語法，在使用中深入體會才是事半功倍的做法。第十六頁，共五十七頁，編輯于2023年，星期五2023/6/2516第8章運行與維護10.3UML模型下面以實用為目標，簡單介紹一些UML的基本語義、內(nèi)容組織與表述規(guī)則，內(nèi)容包括三小節(jié)：10.3.1模型的基本內(nèi)容10.3.2UML的語義擴展10.3.3模型的組織結(jié)構(gòu)第十七頁，共五十七頁，編輯于2023年，星期五2023/6/2517第8章運行與維護10.3.1模型的基本內(nèi)容概念上，UML用于描述模型的基本詞匯有三類：要素、關(guān)系和圖?！耙亍笔悄Ｐ椭械暮诵膬?nèi)容，可以形象地理解為“點”；“關(guān)系”在邏輯上將要素聯(lián)系在一起，可以形象地理解為“線”；“圖”將一組要素和關(guān)系展現(xiàn)出來，可以形象地理解為“面”。總體上看，由這些“點”、“線”、“面”組成了“立體”的模型。第十八頁，共五十七頁，編輯于2023年，星期五2023/6/2518第8章運行與維護1．第一類詞匯——要素UML中有四種類型的要素。（1）表述結(jié)構(gòu)的要素，包括“UseCase”、“類（Class）”、“接口（Interface）”和“協(xié)作（Collaboration）”。（2）表述行為的要素，包括“交互（Interaction）”和“狀態(tài)機（StateMachine）”。（3）用于組織模型內(nèi)容的要素，即“包（Package）”。（4）用做輔助說明的要素，即“注釋（Notes）”。第十九頁，共五十七頁，編輯于2023年，星期五2023/6/2519第8章運行與維護2．第二類詞匯——關(guān)系UML中有四種類型的關(guān)系。（1）關(guān)聯(lián)關(guān)系（Association），表達兩個類的實例之間存在連接。聚集關(guān)系（Aggregation）與組合關(guān)系（Composition）是關(guān)聯(lián)關(guān)系的兩種強化形式。（2）依賴關(guān)系（Dependency），依賴者“使用”被依賴者的關(guān)系。（3）泛化關(guān)系（Generalization），表達“特殊的”與“一般的”的關(guān)系。（4）實現(xiàn)關(guān)系（Realization），“被實現(xiàn)者”是要求的說明，“實現(xiàn)者”是針對要求的解決方案。第二十頁，共五十七頁，編輯于2023年，星期五2023/6/2520第8章運行與維護3．第三類詞匯——圖UML中有九種圖，實踐中常用的有六種，包括兩種靜態(tài)圖和四種動態(tài)圖。（1）UseCase圖：UseCase圖是一種靜態(tài)圖，主要用于展示UseCase、Actor及其關(guān)系。（2）類圖：類圖也是一種靜態(tài)圖，主要用于展示類、接口、包及其關(guān)系。（3）序列圖（Sequence）：序列圖是一種動態(tài)圖，用于按時序展示對象間的消息傳遞場景。（4）協(xié)作圖（Collaboration）：協(xié)作圖是一種動態(tài)圖，其核心內(nèi)容與序列圖相對應(yīng)，與序列圖表示的是相同的內(nèi)容，但它并不是關(guān)注對象之間消息傳遞的場景，而是強調(diào)對象間由于收發(fā)消息而關(guān)聯(lián)起來的一種組織結(jié)構(gòu)。序列圖和協(xié)作圖統(tǒng)稱交互圖（InteractionDiagram）。（5）狀態(tài)圖（StatechartDiagram）：狀態(tài)圖也是一種動態(tài)圖，主要用于展示對象在其生命周期中可能經(jīng)歷的狀態(tài)，以及在這些狀態(tài)上對事件的響應(yīng)能力。（6）活動圖（ActivityDiagram）：活動圖也是一種動態(tài)圖，用于展示系統(tǒng)從一個活動流轉(zhuǎn)到另一個活動的可能路徑與判斷條件。其他三種靜態(tài)圖分別為對象圖（ObjectDiagram）、構(gòu)件圖（ComponentDiagram）和部署圖（DeploymentDiagram）。第二十一頁，共五十七頁，編輯于2023年，星期五2023/6/2521第8章運行與維護10.3.2UML的語義擴展作為一種語言，UML除了提供基本詞匯，還給出了對自身描述能力的三種擴展機制，即構(gòu)造型（Stereotype）、標注值（Taggedvalue）和約束（Constraint）。本書實例中主要使用“構(gòu)造型”擴展基本模型詞匯的語義，來表達新的概念。在后續(xù)的分析與設(shè)計活動中，主要用到以下幾種。（1）類的構(gòu)造型。在系統(tǒng)分析階段的“提取分析類”活動中將使用實體類<<entity>>、控制類<<control>>和邊界類<<boundary>>；在“確定核心元素”活動中將使用“子系統(tǒng)代理”<<subsystemproxy>>；在“引入外圍元素”活動中將使用角色<<role>>。實質(zhì)上，接口也是類的一種構(gòu)造型<<interface>>。（2）包的構(gòu)造型。在“選用構(gòu)架模式”活動中將使用層次<<layer>>；在“確定核心元素”活動中將使用子系統(tǒng)<<subsystem>>。第二十二頁，共五十七頁，編輯于2023年，星期五2023/6/2522第8章運行與維護10.3.2UML的語義擴展（3）UseCase的構(gòu)造型?！癠seCase實現(xiàn)”<<usecaserealization>>是UseCase的一種構(gòu)造型，表述用分析或設(shè)計元素實現(xiàn)局部需求的協(xié)作內(nèi)容；“設(shè)計機制”<<mechanism>>，表述解決特定技術(shù)問題的協(xié)作模式。上述構(gòu)造型是UML應(yīng)用建模中常見的語義擴展形式，在后面章節(jié)結(jié)合特定應(yīng)用場合會具體講到相關(guān)的概念和用法。第二十三頁，共五十七頁，編輯于2023年，星期五2023/6/2523第8章運行與維護10.3.3模型的組織結(jié)構(gòu)總體上，模型的內(nèi)容通過包以及包的層層嵌套組織在一起。模型中的包類似于Windows系統(tǒng)管理磁盤文件的目錄結(jié)構(gòu)，如圖10.1所示。包將一堆零散的模型內(nèi)容簡單地組織在一起，目的是更易于理解和管理。模型應(yīng)該能夠反映建模者和使用者的特定視角，它就是建模動機，表現(xiàn)為的模型中的“構(gòu)架視圖”（ArchiectureView）。正如在土木設(shè)計師眼里的大樓可能是一堆鋼筋混凝土和表面材質(zhì)，同樣一座大樓，在管道設(shè)計師眼里可能是一堆管子和接頭，在網(wǎng)絡(luò)工程師眼里可能是一堆網(wǎng)絡(luò)設(shè)備和布線：不同主體對同一客體的認識結(jié)果有賴于各自的視角，即看問題的角度。這樣能更好地集中注意力，從而有效地解決關(guān)鍵問題。在模型中，構(gòu)架視圖用包的形式表達。每一種特定的“視角”對應(yīng)一種類型的構(gòu)架視圖，在RationalRose建模工具中，用UseCase視圖（UseCaseView）描述需求模型；用邏輯視圖（LogicalView）描述設(shè)計模型。還有組件視圖和部署視圖分別用于描述實施模型和系統(tǒng)整體部署。圖10.1模型的組織結(jié)構(gòu)

第二十四頁，共五十七頁，編輯于2023年，星期五2023/6/2524第8章運行與維護10.4常見圖的用法與內(nèi)容UML中的主要“詞匯”包括：“要素”、“關(guān)系”和“圖”；“圖”UML的主要“詞匯”之一，是為了實現(xiàn)建模目的而使用的一種表現(xiàn)手段，有時一種圖可用于不同場合以滿足特定的要求。圖不僅表述了建模的最終結(jié)果，同樣記錄了認知求解的軌跡?；凇耙杂脼楸尽钡脑瓌t，本節(jié)概念性地說明幾種圖，其中著重強調(diào)兩方面的內(nèi)容：第一，圖的用法及其在模型中的位置；第二，包含的關(guān)鍵內(nèi)容。第二十五頁，共五十七頁，編輯于2023年，星期五2023/6/2525第8章運行與維護10.4.1UseCase圖第二十六頁，共五十七頁，編輯于2023年，星期五2023/6/2526第8章運行與維護1．用于描述系統(tǒng)與外部環(huán)境交互關(guān)系的UseCase圖（1）用法及在模型中的位置UseCase圖主要用于描述系統(tǒng)和外部環(huán)境的交互關(guān)系，如圖10.2所示。概念上，UseCase的集合表達了擬建系統(tǒng)的全部，Actor的集合表達了外部環(huán)境，UseCase和Actor之間的連線的集合則表達擬建系統(tǒng)和外部環(huán)境的邊界。影院售票系統(tǒng)UseCase圖如圖10.3所示。圖10.2描述擬建系統(tǒng)與外部環(huán)境的UseCase圖圖10.3影院售票系統(tǒng)UseCase圖第二十七頁，共五十七頁，編輯于2023年，星期五2023/6/2527第8章運行與維護這種用法的UseCase圖通常位于“UseCase模型”的“UseCases”包內(nèi)，如圖10.4所示。通常將Actors和UseCase放在不同的包中。圖10.4UseCase圖在模型中的位置第二十八頁，共五十七頁，編輯于2023年，星期五2023/6/2528第8章運行與維護（2）關(guān)鍵內(nèi)容。①Actor。Actor在圖中表現(xiàn)為火柴棍兒。簡單講，Actor代表擬建系統(tǒng)外部和系統(tǒng)進行交互的某類人或系統(tǒng)，可以稱為與系統(tǒng)有交互的外部實體。②UseCase。UseCase在圖中表現(xiàn)為一個橢圓。UseCase定義了一組相關(guān)的由系統(tǒng)執(zhí)行的動作序列，將有價值的可見結(jié)果提供給Actor。UseCase與外部的交互活動中可能涉及若干個Actor，但是只有一個主動要求得到有價值的可見結(jié)果，常被稱之為主導(dǎo)（Primary）Actor。主導(dǎo)Actor觸發(fā)交互活動，它到相應(yīng)的UseCase的連線是標有箭頭的。與該UseCase相連的其他Actor則為被動Actor，相應(yīng)的連線不標箭頭。③通信關(guān)聯(lián)。Actor和UseCase之間的連線稱為通信關(guān)聯(lián)，表示Actor和相應(yīng)的UseCase之間的交互。無論有沒有箭頭，通信關(guān)聯(lián)都表示介于Actor和相應(yīng)UseCase之間的雙向會話，用箭頭僅表示Actor觸發(fā)UseCase的執(zhí)行。第二十九頁，共五十七頁，編輯于2023年，星期五2023/6/2529第8章運行與維護2．用于描述需求模型與設(shè)計模型關(guān)系的UseCase圖（1）用法與相對位置這里使用UseCase圖描述功能需求部分的UseCase與相應(yīng)的設(shè)計內(nèi)容，“UseCase實現(xiàn)”之間的可追溯關(guān)聯(lián)如圖10.5所示。概念上，“UseCase實現(xiàn)”是指用擬定的方案實現(xiàn)用戶提出的需求（用usecase表達的需求），如圖10.6所示。圖10.5用UseCase圖表示可追溯的關(guān)聯(lián)第三十頁，共五十七頁，編輯于2023年，星期五2023/6/2530第8章運行與維護（2）關(guān)鍵內(nèi)容。①UseCase實現(xiàn)。“UseCase實現(xiàn)”用虛線邊框的橢圓表示，其中描述的是設(shè)計內(nèi)容，即如何用設(shè)計方案實現(xiàn)UseCase描述的需求。描述這些設(shè)計內(nèi)容使用的圖一般包括“序列圖”、“協(xié)作圖”、“活動圖”、“類圖”等。②實現(xiàn)關(guān)系。實現(xiàn)關(guān)系是“UseCase實現(xiàn)”到UseCase之間的連線。設(shè)計工作完成時，UseCase模型中的每個UseCase在設(shè)計模型中至少有一個“UseCase實現(xiàn)”與之對應(yīng)，“UseCase實現(xiàn)”和“UseCase”之間有可能是多對一的關(guān)系。通俗地講，一種要求可以通過多種辦法解決。通常，在設(shè)計模型的“UseCase實現(xiàn)”包中，對應(yīng)每一個UseCase建立一個以該UseCase命名的包，在此放置對應(yīng)該UseCase的“UseCase實現(xiàn)”的模型內(nèi)容，如圖10.6所示。圖10.6描述需求模型與設(shè)計模型關(guān)系的UseCase圖第三十一頁，共五十七頁，編輯于2023年，星期五2023/6/2531第8章運行與維護10.4.2表述類、接口和子系統(tǒng)之間關(guān)系的類圖1．用法與相對位置類圖是應(yīng)用最廣泛的一種圖，描述擬建系統(tǒng)各個層面的靜態(tài)結(jié)構(gòu)，主要用于表述類、接口和子系統(tǒng)之間的關(guān)系，如圖10.7所示。這種用法的類圖可以進一步劃分為三種不同的情形，盡管表現(xiàn)形式相似，但是它們通常位于模型的不同位置。圖10.7描述類、接口和子系統(tǒng)之間關(guān)系的類圖第三十二頁，共五十七頁，編輯于2023年，星期五2023/6/2532第8章運行與維護（1）第一種情形，用于描述參與某一特定協(xié)作的類、接口和子系統(tǒng)之間的關(guān)系。這種情形的類圖被稱為“參與類圖”?！癠seCase實現(xiàn)”與“構(gòu)架機制”是兩種典型的協(xié)作，“參與類圖”是隸屬于這兩種類型的協(xié)作內(nèi)容，如圖10.8、圖10.9所示。構(gòu)架機制指的也是一組對象的協(xié)作關(guān)系，在后面章節(jié)會具體講到。圖10.8“UseCase實現(xiàn)”中的“參與類圖”

圖10.9“構(gòu)架機制”中的“參與類圖”

第三十三頁，共五十七頁，編輯于2023年，星期五2023/6/2533第8章運行與維護（2）第二種情形，表述同一包中的類、接口和子系統(tǒng)之間的關(guān)系。這種類圖通常出現(xiàn)在相應(yīng)的包中，如圖10.10所示。（3）第三種情形，針對上述兩種情形以外的其他目的，表述類、接口和子系統(tǒng)之間的關(guān)系。這種情形的類圖可以出現(xiàn)在需要的任何位置。圖10.10表述包內(nèi)部關(guān)系的類圖第三十四頁，共五十七頁，編輯于2023年，星期五2023/6/2534第8章運行與維護2．關(guān)鍵內(nèi)容

（1）類。類用于描述一組具有相同屬性、操作、關(guān)系和語義的對象。如圖10.11所示，上面是類的名稱，通常其首字母大寫，中間是屬性，下面是類的操作。圖10.11類的UML表述第三十五頁，共五十七頁，編輯于2023年，星期五2023/6/2535第8章運行與維護（2）接口（Interface）。接口用來說明一個類或子系統(tǒng)應(yīng)該提供的服務(wù)。在形式上接口是一組操作的集合。如圖10.12所示，是接口的兩種UML表述形式：第一種是簡略的表述，只有一個圓圈和接口的名稱，沒有顯示接口中定義的操作；第二種是詳細的表述，在形式上，接口與類的性質(zhì)相似。（3）子系統(tǒng)（Subsystem）。子系統(tǒng)是一組元素的集合。子系統(tǒng)所具有的行為特征在概念上與類相似。用包的構(gòu)造型<<subsystem>>表述子系統(tǒng)，如圖10.13所示。圖10.12接口的兩種UML表述形式

圖10.13子系統(tǒng)的UML表述形式

第三十六頁，共五十七頁，編輯于2023年，星期五2023/6/2536第8章運行與維護（4）關(guān)聯(lián)關(guān)系（Association）。關(guān)聯(lián)關(guān)系的基本含義是兩個類的實例之間存在穩(wěn)定的“連接”，可以用于傳遞消息。當一個類的對象作為另一個類的對象的變量成員時，兩個類之間就有關(guān)聯(lián)關(guān)系存在。圖10.14給出一個通俗的實例。關(guān)聯(lián)關(guān)系的多重性（Multiplicity）表示A的多少個實例對應(yīng)B的一個實例。圖10.15給出一個通俗實例，一只麻雀兩條腿，一只螃蟹八條腿。在對多重性沒有明確認識的時候，可暫不做標注。當然，如果多重性非常明顯，也可省略標注。在分析和設(shè)計過程中，多重性主要用來表述業(yè)務(wù)規(guī)則，常見的標識方式有“1”、“*”、“0..1”、“0..*”、“1..*”等。圖10.14關(guān)聯(lián)關(guān)系的基本含義

圖10.15關(guān)聯(lián)關(guān)系中的多重性表示

第三十七頁，共五十七頁，編輯于2023年，星期五2023/6/2537第8章運行與維護關(guān)聯(lián)關(guān)系的訪問方向表示某一方的實例能夠“訪問”另一方的實例。至少存在一個可用的訪問方向，如果僅存在一個可用的訪問方向，那么關(guān)聯(lián)關(guān)系是單向的，用箭頭表述這一概念，兩端都沒有箭頭的連線表述關(guān)聯(lián)關(guān)系是雙向的。如圖10.16所示，在一個小公司里，公司的總裁認識所有的職員，當然每個職員都認識公司的總裁；在大公司里則有所不同，所有的職員都認識公司的總裁，但是總裁通常只認識核心職員，并不認識那些外圍職員，因而大公司總裁和大公司外圍職員之間的關(guān)聯(lián)關(guān)系是單方向的。圖10.16關(guān)聯(lián)關(guān)系的訪問方向第三十八頁，共五十七頁，編輯于2023年，星期五2023/6/2538第8章運行與維護關(guān)聯(lián)關(guān)系中的角色（Role），表示該類在對方眼里所扮演的角色或用途，或者說對方是如何看待自己的，即類A的實例對類B的實例的具體含義?？梢越Y(jié)合圖10.17中的實例加以理解：一個領(lǐng)域?qū)＜覍σ粋€行業(yè)協(xié)會而言是一個成員，一個行業(yè)協(xié)會對一個領(lǐng)域?qū)＜叶允且粋€信息來源；依次類推。圖10.17關(guān)聯(lián)關(guān)系中的角色示例

第三十九頁，共五十七頁，編輯于2023年，星期五2023/6/2539第8章運行與維護聚合關(guān)聯(lián)（Aggregation）是關(guān)聯(lián)關(guān)系的一種強化形式，表示兩個類的實例之間有“整體”與“部分”的關(guān)系：處于空心菱形符號一端的類是“整體”，另一端的類是“部分”。如圖10.18所示，連隊和士兵是整體和部分的關(guān)系。如果“整體”的多重性大于1，表示“部分”的實例可以被多個“整體”的實例“共享”。例如，球隊和球員就可能是這種關(guān)系：一個球員既可以是俱樂部球隊的球員，同時也可以是國家隊的球員。聚合關(guān)聯(lián)并不隱含“整體”的實例消失將導(dǎo)致“部分”的實例也消失。例如，球隊解散了，球員還在。圖10.18關(guān)聯(lián)關(guān)系中的聚合示例

第四十頁，共五十七頁，編輯于2023年，星期五2023/6/2540第8章運行與維護（5）依賴關(guān)系（Dependency）。依賴關(guān)系表達“使用”的語義，用帶箭頭的虛線表示，如圖10.19所示。相對于關(guān)聯(lián)關(guān)系而言，依賴關(guān)系是一種比較弱的關(guān)聯(lián)，“被依賴者”類的變化有可能影響“依賴者”。

圖10.19依賴關(guān)系的示例

第四十一頁，共五十七頁，編輯于2023年，星期五2023/6/2541第8章運行與維護（6）泛化關(guān)系（Generalization）。類B（相對特殊）到類A（相對一般）的泛化關(guān)系表示“類B是類A的一種”。通常稱類B為子類，稱類A為父類。如圖10.20所示，一名足球運動員同時也是一位大球運動員、球類運動員和運動員（越來越籠統(tǒng)）。在一般意義上，泛化關(guān)系和繼承（Inheritance）是可以互換的概念。如果要加以區(qū)別，那么泛化關(guān)系是一種關(guān)系的名稱，而繼承則是反映和實現(xiàn)泛化關(guān)系的一種機制。圖10.20泛化關(guān)系的示例第四十二頁，共五十七頁，編輯于2023年，星期五2023/6/2542第8章運行與維護（7）實現(xiàn)關(guān)系（Realization）。實現(xiàn)關(guān)系中的一方（甲方）作為要求被提出，另一方（乙方）具本履行要求中聲明的任務(wù)。類圖中出現(xiàn)的實現(xiàn)關(guān)系大多表述子系統(tǒng)或類實現(xiàn)接口。如圖10.21所示，實現(xiàn)關(guān)系的表述方式為虛線加上一個空心的箭頭，雇用“保姆”或?qū)⒑⒆铀偷健坝變簣@”都可以完成接口“照顧學(xué)齡前兒童”中規(guī)定的任務(wù)。如圖10.22所示，因為“照顧學(xué)齡前兒童”是一個接口，所以圖10.21還可以表示成圖10.22所示的簡略形式。如圖10.23所示，以日常生活為例，將關(guān)聯(lián)、依賴、泛化和實現(xiàn)四種關(guān)系反映在同一張類圖中，希望有助于理解它們的語義區(qū)別。圖10.21實現(xiàn)關(guān)系的表示圖10.22實現(xiàn)關(guān)系的（簡略）示例圖10.23日常生活四種關(guān)系的舉例第四十三頁，共五十七頁，編輯于2023年，星期五2023/6/2543第8章運行與維護10.4.3序列圖第四十四頁，共五十七頁，編輯于2023年，星期五2023/6/2544第8章運行與維護1．用序列圖描述局部分析與設(shè)計的場景（1）用法與相對位置。序列圖用于描述動態(tài)行為，直觀易懂，是最常用的一種交互圖，如圖10.24所示。描述局部分析和設(shè)計場景的序列圖位于“UseCase實現(xiàn)”的協(xié)作中，如圖10.25所示。通常，UseCase中的每一個事件序列對應(yīng)“UseCase實現(xiàn)”中的一張序列圖。圖10.24序列圖示例

圖10.25序列圖在模型中的位置

第四十五頁，共五十七頁，編輯于2023年，星期五2023/6/2545第8章運行與維護（2）關(guān)鍵內(nèi)容。①對象。概念上，對象是一個具有明確邊界的、封裝著狀態(tài)與行為的實體。狀態(tài)表現(xiàn)為屬性的一組取值以及同其他對象的“連接”狀況，行為是指對象自身的行動以及對外界請求的響應(yīng)。在序列圖中，對象的符號有三種表示方式：第一種，僅僅給出所屬類的名字，不指明特定的對象（例如，Author表示某個作者）；第二種，僅僅給出對象的名字，不指出所屬類（例如，amos:表示一個名稱為amos的對象）；第三種，同時給出對象和類的名字（例如，amos:Author表示一個叫做amos的作者）。同一序列圖中出現(xiàn)的某一類的多個不同實例時，須指明每個對象的具體名稱。序列圖中，對象符號正下方是一條垂直的虛線，稱對象生存線。沿對象生存線上展開的細長矩形為控制焦點，表述來自其他對象的消息被回應(yīng)的時間跨度。第四十六頁，共五十七頁，編輯于2023年，星期五2023/6/2546第8章運行與維護②消息。消息是對象間通信的具體內(nèi)容，消息表述為一條對象生存線到另一條對象生存線的帶箭頭的水平實線，箭頭指向接受消息的對象，見圖10.24。如果消息被對象發(fā)至其自身，稱為返身消息。消息由序號、名稱和參數(shù)組成。序號可以是連續(xù)編號或?qū)哟位幪?，名稱是必須的內(nèi)容，參數(shù)按需而定。第四十七頁，共五十七頁，編輯于2023年，星期五2023/6/2547第8章運行與維護2．用序列圖描述構(gòu)架機制的典型場景序列圖還用于描述“構(gòu)架機制”的典型應(yīng)用場景，在模型中的相對位置如圖10.26所示，這種序列圖中的關(guān)鍵內(nèi)容與前一種用法沒有區(qū)別。圖10.26描述“構(gòu)架機制”場景的序列圖的位置第四十八頁，共五十七頁，編輯于2023年，星期五2023/6/2548第8章運行與維護10.4.4協(xié)作圖——用于描述局部分析與設(shè)計的場景協(xié)作圖是另一種形式的交互圖，如圖10.27所示。協(xié)作圖的本質(zhì)內(nèi)容（“對象”和“消息”）與相關(guān)的序列圖存在明顯的對應(yīng)關(guān)系，圖10.27和圖10.24是等價的。在協(xié)作圖中，傳遞消息的對象之間存在一條連線，表示消息傳遞的通道。可以通過序列圖直接生成相應(yīng)的協(xié)作圖。在Rose中的操作步驟為：首先選中序列圖，然后在主菜單中選擇“Browse|CreateCollaborationDiagram”，這樣就可以自動生成對應(yīng)于該序列圖的協(xié)作圖了。圖10.27用序列圖生成的協(xié)作圖第四十九頁，共五十七頁，編輯于2023年，星期五2023/6/2549第8章運行與維護協(xié)作圖主要用于描述局部分析和設(shè)計中的特定場景，其特點是強調(diào)對象間的結(jié)構(gòu)關(guān)系。這種用法的協(xié)作圖位于“UseCase實現(xiàn)”的協(xié)作中，其相對位置如圖10.28所示。通常，只關(guān)注那些對應(yīng)重要事件序列的協(xié)作圖，即不是所有的序列圖都有必要給出相應(yīng)的協(xié)作圖。圖10.28協(xié)作圖在模型中的相對位置第五十頁，共五十七頁，編輯于2023年，星期五2023/6/2550第8章運行與維護10.4.5狀態(tài)圖1．用法與相對位置狀態(tài)圖用于展示某對象在其生命周期中可能處于的幾種狀態(tài)、在這些狀態(tài)中的行為、發(fā)生狀態(tài)轉(zhuǎn)換的事件及其相關(guān)的動作。一個類所處的全部可能狀態(tài)及相關(guān)行為構(gòu)成了這個類的狀態(tài)機。圖10.29給出了一個通俗的狀態(tài)圖的例子，該狀態(tài)圖描述了人一生中的各類狀態(tài)及轉(zhuǎn)變。人從出生到死亡的生命周期內(nèi)，要么處于清醒狀態(tài)，要么處于睡眠狀態(tài)；靜躺超過15分鐘從清醒狀態(tài)轉(zhuǎn)入睡眠狀態(tài)；鬧鐘一響，人會睜開眼睛醒來；進入睡眠狀態(tài)必然暫停有意識的思維活動，在清醒狀態(tài)時可能吃飯、工作或者鍛煉身體。圖10.29狀態(tài)圖示例第五十一頁，共五十七頁，編輯于2023年，星期五2023/6/2551第8章運行與維護描述類狀態(tài)特征的狀態(tài)圖隸屬于該類的狀態(tài)機，在模型中的相對位置如圖10.30所示。一個狀態(tài)機可以有多張狀態(tài)圖來描述。圖10.30狀態(tài)圖在模型中的位置