信息系統(tǒng)分析與設(shè)計(jì)第三章

信息系統(tǒng)分析與設(shè)計(jì)第三章第一頁，共三十二頁，2022年，8月28日學(xué)習(xí)目標(biāo)掌握面向?qū)ο蠡舅枷牒突靖拍钫莆誙ML工具概括統(tǒng)一過程下的關(guān)鍵思想第二頁，共三十二頁，2022年，8月28日3.1面向過程與面向?qū)ο竺嫦蜻^程：面向過程的思想是把一個(gè)項(xiàng)目、一件事情按照一定的順序，從頭到尾一步一步地做下去，先做什么后做什么，一直到結(jié)束。這是一個(gè)人做事的方法。面向?qū)ο螅好嫦驅(qū)ο蟮乃枷胧前岩粋€(gè)項(xiàng)目、一件事情分成更小的項(xiàng)目，或者說分成一個(gè)個(gè)更小的部分，每一部分負(fù)責(zé)什么方面的功能，最后再由這些部分組合而成為一個(gè)整體。這種思想比較適合多人的分工合作。第三頁，共三十二頁，2022年，8月28日

面向過程的演出主持人開場(chǎng)節(jié)目一節(jié)目二節(jié)目三主持人總結(jié)第四頁，共三十二頁，2022年，8月28日面向?qū)ο蟮难莩鲋鞒秩斯?jié)目開場(chǎng)總結(jié)節(jié)目編號(hào)演員組成演出可以這樣策劃：需要一個(gè)主持人a，需要節(jié)目b。演出的事情可以表示為：a的開場(chǎng)——>b進(jìn)行——>a的總結(jié)。第五頁，共三十二頁，2022年，8月28日面向過程就是分析出解決問題所需要的步驟，然后用函數(shù)把這些步驟一步一步實(shí)現(xiàn)，使用的時(shí)候一個(gè)一個(gè)依次調(diào)用就可以了。面向?qū)ο笫前褬?gòu)成問題事務(wù)分解成各個(gè)對(duì)象，建立對(duì)象的目的不是為了完成一個(gè)步驟，而是為了描敘某個(gè)事物在整個(gè)解決問題的步驟中的行為。開發(fā)下五子棋的系統(tǒng)。第六頁，共三十二頁，2022年，8月28日面向過程的設(shè)計(jì)思路首先分析問題的步驟：

1、開始游戲，

2、黑子先走，

3、繪制畫面，

4、判斷輸贏，

5、輪到白子，

6、繪制畫面，

7、判斷輸贏，

8、返回步驟2，

9、輸出最后結(jié)果。把上面每個(gè)步驟用分別的函數(shù)來實(shí)現(xiàn)，問題就解決了。

第七頁，共三十二頁，2022年，8月28日面向?qū)ο蟮脑O(shè)計(jì)的思路兩人對(duì)局，各執(zhí)一色，黑子先出手，輪流下一子。先將橫豎或斜線的連續(xù)5個(gè)或5個(gè)以上同色棋子連成不間斷的一排者為勝。黑白棋子棋盤系統(tǒng)規(guī)則系統(tǒng)接收用戶輸入告知棋盤系統(tǒng)棋子布局變化接收到棋子的變化負(fù)責(zé)在屏幕上面顯示出這種變化利用第三類對(duì)象（規(guī)則系統(tǒng)）來對(duì)棋局進(jìn)行判定第八頁，共三十二頁，2022年，8月28日四大發(fā)明之活字印刷——面向?qū)ο笏枷氲膭倮?/p>

第九頁，共三十二頁，2022年，8月28日活字印刷——面向?qū)ο笏枷氲谝?，要改，只需更改要改之字，此為可維護(hù)；第二，這些字并非用完這次就無用，完全可以在后來的印刷中重復(fù)使用，此乃可復(fù)用；第三，此詩若要加字，只需另刻字加入即可，這是可擴(kuò)展；第四，字的排列有可能是豎排，有可能是橫排，此時(shí)只需將活字移動(dòng)就可做到滿足排列需求，此是靈活性好。第十頁，共三十二頁，2022年，8月28日3.2UML基本知識(shí)例：音樂的演奏該音樂是一首進(jìn)行曲，B小調(diào)。第一小節(jié)開始于用小提琴演奏的中央C音之上的A調(diào)。在演奏該音符時(shí)，鋼琴家演奏一種包含7個(gè)音符的和音。右手演奏如下4個(gè)音符：中央C音之上的E高音……樂譜顯示了需要哪些樂器來演奏一段音樂，注明了要演奏的每一件樂器、何時(shí)演奏它們以及一整套技術(shù)信息，如調(diào)號(hào)、節(jié)拍、音量等。第十一頁，共三十二頁，2022年，8月28日系統(tǒng)分析與設(shè)計(jì)UML——統(tǒng)一建模語言Rumbaugh（OMT方法）、Booch（Booch方法）、Jacobson創(chuàng)立的一種表示面向?qū)ο笙到y(tǒng)模型的一種方法。一種可視化的專門用于建造系統(tǒng)模型的語言。以統(tǒng)一與規(guī)范的方式使復(fù)雜的建模過程變得有序方便。第十二頁，共三十二頁，2022年，8月28日3.2.1對(duì)象和類英國(guó)國(guó)王喬治三世法國(guó)國(guó)王路易十六世對(duì)象KingClassShoe

Class第十三頁，共三十二頁，2022年，8月28日3.2.2繼承CardholderClothingCompany公司的信息系統(tǒng)：CreditCardClass的UML表示：

個(gè)人通過WWW訂購衣服，并把貨款計(jì)入信用卡。系統(tǒng)包括通過WWW通信；銷售衣服的各種情況；Web安全；發(fā)貨選項(xiàng)；將貨款計(jì)入信用卡。如果信用卡公司現(xiàn)在擴(kuò)展信息系統(tǒng)，以使它能夠處理付款卡及信用卡，我們需要建立付款卡類。第十四頁，共三十二頁，2022年，8月28日建立更一般的類

CreditCardClass和DebitCardClass繼承自BankCardClass。它們具有BankCardClass的所有特性，此外還具有自己的特定的屬性和操作。如CreditCardClass具有屬性CreditLimit，DebitCardClass具有操作determineAccountBalance。UML圖顯示CreditCardClass和DebitCardClass是BankCardClass的子類繼承第十五頁，共三十二頁，2022年，8月28日CreditCardClass是BankCardClass的子類。BankCardClass是CreditCardClass的超類。CreditCardClass是BankCardClass的特殊化。BankCardClass是CreditCardClass的泛化。CreditCardClass是一個(gè)Bank

CardClass。BankCardClass是基類，CreditCardClass是派生類。BankCardClass是父類，CreditCardClass是子類。CreditCardClass繼承自BankCardClass。第十六頁，共三十二頁，2022年，8月28日繼承的層次結(jié)構(gòu)繼承是一種自頂向下的關(guān)系第十七頁，共三十二頁，2022年，8月28日3.2.3泛化、聚合和關(guān)聯(lián)當(dāng)“類X”包含“類Y”時(shí)，產(chǎn)生聚合關(guān)系：第十八頁，共三十二頁，2022年，8月28日關(guān)聯(lián)關(guān)聯(lián)——兩個(gè)類之間任意關(guān)系consults涉案放射學(xué)家咨詢律師consults斷腿律師咨詢放射學(xué)家第十九頁，共三十二頁，2022年，8月28日3.2.4UML建模實(shí)例示例1：為冰激凌工廠建模示例2：為人建模IceCreamFactoryClassIceCreamFactoryClass第二十頁，共三十二頁，2022年，8月28日示例3：擴(kuò)展示例2第二十一頁，共三十二頁，2022年，8月28日示例4：為人建模，其中人由頭、軀干和四肢組成，而肢是指胳膊或腿。聚合泛化第二十二頁，共三十二頁，2022年，8月28日示例5：使用UML為系統(tǒng)分析師收聽收音機(jī)建模。練習(xí)：習(xí)題1、2、3listens第二十三頁，共三十二頁，2022年，8月28日3.3信息隱藏具有信息隱藏的BankAccount信息隱藏使實(shí)現(xiàn)細(xì)節(jié)對(duì)對(duì)象外部不可見，從而使信息系統(tǒng)實(shí)質(zhì)上由獨(dú)立的類組成，通過發(fā)送消息給它們自己的操作以及其他類的操作來進(jìn)行通信，以此來增強(qiáng)系統(tǒng)可維護(hù)性。第二十四頁，共三十二頁，2022年，8月28日J(rèn)ava提供了四種級(jí)別的訪問控制限定符，這些限定符規(guī)定了類中的哪些變量和方法對(duì)其他類是可見的。訪問控制限定符在不同類中的可見程度：

所處的類限定符同一類內(nèi)

同一包

不同包子類內(nèi)非子類內(nèi)子類內(nèi)非子類內(nèi)默認(rèn)可見可見可見不可見不可見public可見可見可見可見可見Private可見不可見不可見不可見不可見protected可見可見可見可見不可見第二十五頁，共三十二頁，2022年，8月28日職責(zé)驅(qū)動(dòng)型設(shè)計(jì)的原則當(dāng)把一條消息發(fā)送給對(duì)象時(shí)，不但它與如何執(zhí)行請(qǐng)求無關(guān)，而且發(fā)送消息的模塊甚至不允許知道對(duì)象的屬性是如何實(shí)現(xiàn)的。執(zhí)行消息的所有方面的全部職責(zé)是由負(fù)責(zé)接收消息的對(duì)象負(fù)責(zé)。第二十六頁，共三十二頁，2022年，8月28日3.4統(tǒng)一過程RUPRational統(tǒng)一過程RUP（RationalUnifiedProcess）是一種軟件開發(fā)的過程。所謂統(tǒng)一過程，即表示在系統(tǒng)開發(fā)過程中使用同一種開發(fā)方法與同一種表示形式。它提供了在開發(fā)組織中分派任務(wù)和責(zé)任的紀(jì)律化方法。它的目標(biāo)是在可預(yù)見的日程和預(yù)算前提下，確保滿足最終用戶需求的高質(zhì)量產(chǎn)品。

統(tǒng)一過程模型是一種“用例驅(qū)動(dòng)，以體系結(jié)構(gòu)為核心，迭代及增量”的軟件過程框架，由UML方法和工具支持。第二十七頁，共三十二頁，2022年，8月28日統(tǒng)一過程定義了四個(gè)階段和兩種開發(fā)手段：

四個(gè)階段：

初始階段細(xì)化階段構(gòu)造階段過渡階段簡(jiǎn)單用例圖項(xiàng)目詞匯表項(xiàng)目規(guī)劃與風(fēng)險(xiǎn)評(píng)估完善用例圖建立靜態(tài)模型與動(dòng)態(tài)模型建立物理構(gòu)架修改后發(fā)布正式版本開發(fā)所有代碼測(cè)試與集成簡(jiǎn)單用例圖詳細(xì)用例圖系統(tǒng)邏輯視圖Beta版本軟件產(chǎn)品代碼程序員手冊(cè)用戶手冊(cè)第二十八頁，共三十二頁，2022年，8月28日兩種手段

迭代與增量

細(xì)化階段構(gòu)造階段過渡階段初始階段Rational統(tǒng)一過程中的迭代增量A增量B增量CRational統(tǒng)一過程中的增量第二十九頁，共三十二頁，2022年，8月28日總結(jié)面向?qū)ο蠓缎偷幕舅枷險(xiǎn)ML統(tǒng)一建模語言是描述軟件開發(fā)過程RUP的一種理想工具類、對(duì)象、繼承、泛化、聚合、關(guān)聯(lián)第三十頁，共三十二頁，2022年，8月28日習(xí)題1、用UML為公寓建模。其中出租單元具有月租金，住宅單元具有購買價(jià)格。2、用UML為公共圖書館中的以下特性建模。書籍被分類為兩