第1章 緒論
"UML系統(tǒng)建模"是一門與軟件開(kāi)發(fā)密切相關(guān)的建模課程。1968年軟件工程產(chǎn)生后，軟件分析與設(shè)計(jì)的技術(shù)在20世紀(jì)80年代末至90年代中期出現(xiàn)了一個(gè)發(fā)展高潮，UML是這個(gè)高潮的產(chǎn)物。它不僅統(tǒng)一了Booch、Rumbaugh和Jacobson的建模表示方法，而且使其有了進(jìn)一步的發(fā)展，并終統(tǒng)一為大眾所接受的標(biāo)準(zhǔn)建模語(yǔ)言(unified modeling language，UML)。
1.1 UML的發(fā)展史
工程師為什么要建造模型？航天工程師為什么要建造航天器的模型？橋梁工程師為什么要建造橋梁模型？建造這些模型的目的是什么？
工程師建造模型來(lái)查明他們的設(shè)計(jì)是否可以正常工作。航天工程師建造好了航天器的模型，然后把它們放入風(fēng)洞中了解這些航天器是否可以飛行。橋梁工程師建造橋梁模型來(lái)了解橋是否穩(wěn)固。建筑工程師建造建筑模型可以了解客戶是否喜歡這種建筑樣式。通過(guò)建立模型來(lái)驗(yàn)證建造事物的可行性。
UML系統(tǒng)建模是一種與面向?qū)ο筌浖_(kāi)發(fā)密切相關(guān)的建模方法。各種面向?qū)ο蟮姆治雠c設(shè)計(jì)方法都為面向?qū)ο罄碚撆c技術(shù)的發(fā)展作出了貢獻(xiàn)。這些方法各有自己的優(yōu)點(diǎn)和缺點(diǎn)，同時(shí)在各自不同范圍內(nèi)擁有自己的用戶群。各種方法的主導(dǎo)思想以及所采用的主要概念與原則大體上是一致的，但是也存在不少差異。這些差異所帶來(lái)的問(wèn)題是，不利于面向?qū)ο蠓椒ㄏ蛞恢碌姆较虬l(fā)展，也給用戶的選擇帶來(lái)了一些困惑。為此，Rational公司的Booch和Rumbaugh決定將他們各自的方法結(jié)合起來(lái)成為一種方法，并于1995年10月了第1個(gè)版本，稱為"統(tǒng)一方法"(Unified Method 0.8)。此時(shí)OOSE的作者Jacobson也加入了Rational公司，于是也加入了統(tǒng)一行動(dòng)。1996年6月了第2個(gè)版本UML 0.9。鑒于統(tǒng)一行動(dòng)的產(chǎn)物只是一種建模語(yǔ)言，而不是一種建模方法(因?yàn)椴话^(guò)程指導(dǎo))，所以自UML 0.9起，改稱"統(tǒng)一建模語(yǔ)言"。在此過(guò)程中，由Rational公司發(fā)起成立了UML伙伴組織。開(kāi)始時(shí)有12家公司加入，共同推出了UML 1.0版，并于1997年1月提交到對(duì)象管理組織(OMG)申請(qǐng)作為一種標(biāo)準(zhǔn)建模語(yǔ)言。此后，又把其他幾家向OMG提交建模語(yǔ)言提案的公司擴(kuò)大到UML伙伴組織中，并汲取意見(jiàn)對(duì)UML進(jìn)一步作了修改，產(chǎn)生了UML 1.1版。該版本于1997年11月4日被OMG采納。此后UML還在繼續(xù)改進(jìn)，目前的版本是UML 2.5(www.UML.org)。
OMG提交給國(guó)際標(biāo)準(zhǔn)化組織(ISO)的UML 1.4已經(jīng)通過(guò)審核成為國(guó)際標(biāo)準(zhǔn)(ISO/IEC 19501：2005)。UML早期發(fā)展過(guò)程如圖1-1所示。
圖1-1 UML的發(fā)展史
1.2 日常生活中的應(yīng)用
模型是用某種工具對(duì)某個(gè)系統(tǒng)的表達(dá)方式。模型從某一個(gè)建模觀點(diǎn)出發(fā)，抓住事物重要的方面而簡(jiǎn)化或忽略其他方面。工程、建筑和其他許多需要?jiǎng)?chuàng)造性思想的領(lǐng)域中都使用模型。
表達(dá)模型的工具要便于使用。建筑模型可以是圖紙上所繪的建筑圖，也可以是用厚紙板制作的三維模型，還可以用存于計(jì)算機(jī)中的方程來(lái)表示。一個(gè)建筑物的結(jié)構(gòu)模型不僅能夠展示這個(gè)建筑物的外觀，還可以進(jìn)行工程設(shè)計(jì)和成本核算。
軟件系統(tǒng)的模型用建模語(yǔ)言來(lái)表達(dá)，如UML。模型包含語(yǔ)義信息和表示法，可以采取圖形和文字等多種不同形式。
霧霾的研究可以建造模型嗎？建造模型的好處有哪些？
UML的目標(biāo)是以面向?qū)ο蟾鞣N相關(guān)圖的方式來(lái)描述任何類型的系統(tǒng)。常用的是建立軟件系統(tǒng)的模型，但UML也可用來(lái)描述其他非計(jì)算機(jī)軟件的系統(tǒng)或者商業(yè)機(jī)構(gòu)或過(guò)程，以下是UML常見(jiàn)的應(yīng)用。
信息系統(tǒng)：向用戶提供信息的存儲(chǔ)、檢索、轉(zhuǎn)換和提交處理存放在關(guān)系或?qū)ο髷?shù)據(jù)庫(kù)中大量具有復(fù)雜關(guān)系的數(shù)據(jù)。
技術(shù)系統(tǒng)：處理和控制技術(shù)設(shè)備，如電信設(shè)備、軍事系統(tǒng)或工業(yè)過(guò)程，它們必須處理設(shè)計(jì)的特殊接口，標(biāo)準(zhǔn)軟件很少，技術(shù)系統(tǒng)通常是實(shí)時(shí)系統(tǒng)。
嵌入式實(shí)時(shí)系統(tǒng)：在嵌入其他設(shè)備(如移動(dòng)電話、汽車、家電)的硬件上執(zhí)行的系統(tǒng)通常是通過(guò)低級(jí)程序設(shè)計(jì)進(jìn)行的，需要實(shí)時(shí)支持。
分布式系統(tǒng)：分布在一組機(jī)器上運(yùn)行的系統(tǒng)，數(shù)據(jù)很容易從一臺(tái)機(jī)器傳送到另一臺(tái)機(jī)器，需要同步通信機(jī)制來(lái)確保數(shù)據(jù)完整性，通常是建立在對(duì)象機(jī)制上的，如CORBA、COM/DCOM或Java Beans/RMI上。
系統(tǒng)軟件：定義了其他軟件使用的技術(shù)基礎(chǔ)設(shè)施，操作系統(tǒng)、數(shù)據(jù)庫(kù)和在硬件上完成底層操作的用戶接口等，同時(shí)提供一般接口供其他軟件使用。
商業(yè)系統(tǒng)：描述目標(biāo)、資源、人、計(jì)算機(jī)規(guī)則、法規(guī)、商業(yè)策略、政策等，以及商業(yè)中的實(shí)際工作、商業(yè)過(guò)程。商業(yè)系統(tǒng)是面向?qū)ο蠼?yīng)用的一個(gè)重要的領(lǐng)域，引起了人們極大的興趣，面向?qū)ο蠼７浅＿m合為公司的商業(yè)過(guò)程建模，運(yùn)用全質(zhì)量管理等技術(shù)，可以對(duì)公司的商業(yè)過(guò)程進(jìn)行分析、改進(jìn)和實(shí)現(xiàn)，使用面向?qū)ο蠼ＵZ(yǔ)言為過(guò)程建模和編制文檔，使過(guò)程更易于使用。
UML具有描述以上這些類型系統(tǒng)的能力。
1.3 本課程學(xué)習(xí)中需要注意的問(wèn)題
建模是計(jì)算機(jī)學(xué)科所特有的嗎？其他領(lǐng)域是否需要建模？設(shè)想造一幢摩天大廈，如果沒(méi)有圖紙將會(huì)是怎樣的結(jié)果？
教師可按照章節(jié)進(jìn)行一步步的理論教學(xué)，實(shí)踐性的案例貫穿在相關(guān)章節(jié)中，有興趣的學(xué)生可主動(dòng)按照案例進(jìn)行模仿建模，探索學(xué)習(xí)，主動(dòng)學(xué)習(xí)，理論聯(lián)系實(shí)際學(xué)習(xí)效果將更好。
(1)簡(jiǎn)單的案例描述在第3章講述，主要引導(dǎo)學(xué)生觀察了解UML常用的9種圖的畫(huà)法及作用，圖形簡(jiǎn)單易用，便于學(xué)習(xí)，可立即上手模仿實(shí)踐。
(2)中型案例在全書(shū)的第二部分按章節(jié)詳細(xì)講述，按照統(tǒng)一過(guò)程的各過(guò)程流在第二部分的每章結(jié)尾處展開(kāi)說(shuō)明。
圖1-2是按軟件RUP過(guò)程設(shè)置建模的知識(shí)點(diǎn)概況。
圖1-2 建模的知識(shí)點(diǎn)框圖
學(xué)期開(kāi)始，學(xué)生可在老師的協(xié)助指導(dǎo)下明確一個(gè)感興趣的軟件案例作為學(xué)期學(xué)習(xí)目標(biāo)，教師講理論的同時(shí)學(xué)生自己動(dòng)手一步步完成案例。教師課上講解的時(shí)候，學(xué)生也可舉一反三，并結(jié)合自己所做案例思考自己的經(jīng)驗(yàn)和教訓(xùn)。圖1-3是軟件人才的發(fā)展途徑。
圖1-3 軟件工程師發(fā)展途徑
(3)復(fù)雜的大型案例在第三部分高級(jí)課題中講述，大型軟件可能是涉及人身財(cái)產(chǎn)安全的系統(tǒng)，還有一些大型系統(tǒng)的需求很難說(shuō)清或抽取，第12章用案例詳細(xì)講述了這種系統(tǒng)建模過(guò)程中的復(fù)雜網(wǎng)絡(luò)需求獲取方法和形式化方法技術(shù)的補(bǔ)充作用。
部分
建模理論概述
本部分介紹面向?qū)ο蠓椒ǖ漠a(chǎn)生、UML的發(fā)展、RUP統(tǒng)一過(guò)程的模型、Rose工具及UML的更多技術(shù)細(xì)節(jié)。
第2章 面向?qū)ο蠓椒?/p>
軟件工程從1968年產(chǎn)生以來(lái)，經(jīng)歷了傳統(tǒng)軟件工程階段并發(fā)展到現(xiàn)在的高級(jí)軟件工程階段，面向?qū)ο蟮姆椒?簡(jiǎn)稱00方法)在傳統(tǒng)軟件工程方法的基礎(chǔ)上產(chǎn)生，因其一些顯著特點(diǎn)解決了一些軟件問(wèn)題，是目前主流的軟件開(kāi)發(fā)方法。有了面向?qū)ο蟮乃枷氩女a(chǎn)生了后面所要介紹的UML。
請(qǐng)回憶傳統(tǒng)軟件工程課上完成軟件案例作業(yè)的過(guò)程，完成情況如何？該過(guò)程中存在哪些問(wèn)題？
本章知識(shí)要點(diǎn)
(1)面向?qū)ο螽a(chǎn)生的原因。
(2)面向?qū)ο蟮乃伎挤绞健?/p>
興趣實(shí)踐
現(xiàn)實(shí)生活中哪些軟件基于面向?qū)ο蠓椒ㄩ_(kāi)發(fā)？試舉一例。
探索思考
計(jì)算機(jī)硬件有摩爾定律，為什么軟件沒(méi)有呢？
預(yù)習(xí)準(zhǔn)備
復(fù)習(xí)傳統(tǒng)的結(jié)構(gòu)化軟件工程方法的知識(shí)及面向?qū)ο蟪绦蛘Z(yǔ)言相關(guān)的三個(gè)特性。
2.1 了解面向?qū)ο螽a(chǎn)生的原因
俗話說(shuō)：天下大勢(shì)，分久必合，合久必分。計(jì)算機(jī)軟件技術(shù)的發(fā)展也是一個(gè)"分久必合，合久必分"的過(guò)程。
從1946年2月14日臺(tái)計(jì)算機(jī)誕生之日起，軟件應(yīng)運(yùn)而生。
起初軟件是手工作坊的生產(chǎn)方式，沒(méi)有標(biāo)準(zhǔn)化的過(guò)程、工具和技術(shù)，從而導(dǎo)致大量軟件錯(cuò)誤。之后計(jì)算機(jī)專家提出了各種語(yǔ)言和方法，但還是不能避免錯(cuò)誤的發(fā)生。小型軟件(5000行代碼以下的軟件)基本能正確地生產(chǎn)出來(lái)，但大中型軟件(5萬(wàn)行代碼以上的軟件是大型軟件，其間的為中型軟件)項(xiàng)目就很難保障。到目前為止約1/3的軟件項(xiàng)目是失敗的。
20世紀(jì)60年代起隨著計(jì)算機(jī)硬件性能的不斷提高和價(jià)格的不斷下降，其應(yīng)用領(lǐng)域也在不斷擴(kuò)大。人們?cè)谠絹?lái)越多的領(lǐng)域把更多、更難的問(wèn)題交給計(jì)算機(jī)解決。這使得計(jì)算機(jī)軟件的規(guī)模和復(fù)雜性與日俱增，從而使軟件技術(shù)不斷受到新的挑戰(zhàn)。60年代軟件危機(jī)的出現(xiàn)就是因?yàn)橄到y(tǒng)的復(fù)雜性超出了人們?cè)诋?dāng)時(shí)的技術(shù)條件下所能解決的程度。此后在軟件領(lǐng)域，從學(xué)術(shù)界到工業(yè)界，人們一直在為尋求更先進(jìn)的軟件方法與技
