UML團隊開發(fā)流程與管理

內(nèi)容概要

　　初出茅廬的軟件設(shè)計新手在面對大量信息時，往往備感迷茫，不知從何處下手；有本書在手，這樣的問題將迎刃而解?！秛ml團隊開發(fā)流程與管理(第2版)》在實例的引導(dǎo)下全面展開論述，內(nèi)容精彩紛呈，講解細致入微，是面向設(shè)計人員的優(yōu)秀讀物；《uml團隊開發(fā)流程與管理(第2版)》主要內(nèi)容如下：
　　介紹uml及使用場合
　　《uml團隊開發(fā)流程與管理(第2版)》第i部分設(shè)計了一個完整案例，井在其中應(yīng)用了14個uml圖形；通過對話方式說明14個圖形的含義和應(yīng)用方式，指導(dǎo)讀者在實踐中掌握uml基礎(chǔ)知識。
　　講述如何在實際項目中應(yīng)用uml
　　《uml團隊開發(fā)流程與管理(第2版)》第ii部分設(shè)計了另一個完整案例，該案例結(jié)合使用了軟件工具、uml、mda和不同平臺的編程語言(java、c#)，并提供了練習(xí)單元，讓讀者“從做中學(xué)”。
　　討論軟件開發(fā)團隊合作模式
　　《uml團隊開發(fā)流程與管理(第2版)》第iii部分列舉團隊合作案例，引領(lǐng)讀者了解團隊中的各個角色并挑選合適的工具。
　　分析enterprise architect9.2的用法
　　《uml團隊開發(fā)流程與管理(第2版)》所有案例均使用enterprisearchitect，enterprisearchitect是一套完整的uml支持工具，可支持14個
uml圖形以及多種編程語言和數(shù)據(jù)庫，并能提供極大的定制化空間。

作者簡介

　　賴信仁，信仁軟件設(shè)計負責(zé)人。精通面向?qū)ο笏枷?、UML、程序設(shè)計、系統(tǒng)設(shè)計實戰(zhàn)及數(shù)據(jù)倉儲等。擔(dān)任多家公司(臺灣電通、中科院、農(nóng)學(xué)社、臺積電TSMC、統(tǒng)一企業(yè))的軟件配置顧問。參與多項系統(tǒng)開發(fā)項目(CMO
eRMA、TSMC
eMaterial、秀波電子ERP、臺灣電通Workflow、臺灣電通財務(wù)系統(tǒng)等)。曾任系統(tǒng)分析師及專業(yè)講師；并于臺積電及奇美電子擔(dān)任高級軟件設(shè)計師，負責(zé)軟件技術(shù)策略的擬定及開發(fā)新軟件技術(shù)。文化大學(xué)進修推廣部軟件設(shè)計與實務(wù)應(yīng)用班——UML
2．0與Java J2EE講師。..

書籍目錄

第i部分uml基礎(chǔ)
第1章案例設(shè)計與說明
1.1案例背景說明
1.2總結(jié)
第2章利用uml表達業(yè)務(wù)流程與系統(tǒng)需求
2.1活動圖與業(yè)務(wù)流程
2.2用例圖與系統(tǒng)需求
2.3總結(jié)
第3章表達系統(tǒng)內(nèi)部的結(jié)構(gòu)
3.1系統(tǒng)結(jié)構(gòu)與類圖
3.2系統(tǒng)結(jié)構(gòu)與序列圖
3.3系統(tǒng)結(jié)構(gòu)與通信圖
3.4總結(jié)
第4章表達系統(tǒng)的微觀設(shè)計
4.1對象圖
4.2狀態(tài)機圖
4.3時間圖
4.4總結(jié)
第5章表達系統(tǒng)的宏觀設(shè)計
5.1總則圖
5.2包圖
5.3交互概述圖
5.4組合結(jié)構(gòu)圖
5.5總結(jié)
第6章表達系統(tǒng)的實現(xiàn)與部署
6.1組件圖
6.2部署圖
6.3總結(jié)
第ii部分umi與軟件開發(fā)實現(xiàn)
第7章電子化采購管理系統(tǒng)案例
7.1案例背景說明
7.2總結(jié)
第8章業(yè)務(wù)流程設(shè)計與需求收集
8.1捕捉業(yè)務(wù)流程
8.2從業(yè)務(wù)流程找出用例
8.3總結(jié)
第9章實現(xiàn)用例
9.1分析類與用例
9.2勾勒用例的控制對象
9.3交易模式與實體對象
9.4使用序列圖描述對象交互
9.5總結(jié)
第10章領(lǐng)域模式、平臺技術(shù)與類模式
10.1 mda基本介紹
10.2不同軟件平臺的實現(xiàn)技術(shù)
10.3利用mda轉(zhuǎn)換領(lǐng)域模型
10.4總結(jié)
第11章測試代碼的編寫
11.1在不同平臺中新增項目與生成代碼
11.2在不同平臺中編寫測試代碼
11.3總結(jié)
第12章代碼的編寫
12.1編寫領(lǐng)域?qū)哟a
12.2編寫數(shù)據(jù)源層代碼
12.3總結(jié)
第13章代碼的重構(gòu)
13.1代碼重構(gòu)的時機
13.2重構(gòu)手法
13.3結(jié)構(gòu)的重整與設(shè)計模式
13.4電子化采購系統(tǒng)重構(gòu)練習(xí)(c#)
13.5總結(jié)
第iii部分軟件開發(fā)與團隊合作
第14章團隊合作案例場景介紹
14.1團隊合作與uml
14.2案例場景介紹
14.3團隊合作機制的環(huán)境建立
14.4ea團隊合作機制簡介
第15章建立uml合作的中央集權(quán)控制環(huán)境
15.1案例背景說明
15.2開發(fā)模型的集中化管理
15.3利用ea中央控制開發(fā)模型
15.4總結(jié)
第16章配置管理與uml
16.1案例背景說明
16.2軟件配置管理的原理與操作
16.3利用ea進行軟件配置管理
16.4總結(jié)
第17章團隊安全機制與uml
17.1案例背景說明
17.2ea的團隊合作機制
17.3練習(xí)
17.4總結(jié)
第iv部分附錄
附錄aea的基本操作
附錄bea的定制化
附錄c參考書目及網(wǎng)絡(luò)資源

章節(jié)摘錄

版權(quán)頁：   插圖：   2.2.1信仁醫(yī)院案例背景描述 HSDc RA與信仁醫(yī)院特助就信仁醫(yī)院住出院系統(tǒng)的作業(yè)流程取得共識后，接下來要開始找出信仁醫(yī)院住出院系統(tǒng)的相關(guān)系統(tǒng)需求。 HSDc RA采用HSDc所建議的“從業(yè)務(wù)流程到用例”的分析方式（有關(guān)這部分的詳細步驟，請參閱本書第Ⅱ部分的介紹），設(shè)法找出有關(guān)信仁醫(yī)院住出院系統(tǒng)中的用例。 用例分析對信仁醫(yī)院特助以及用戶來說是一種全新的需求收集方式，因此，HSDc RA與信仁醫(yī)院的利益相關(guān)方之間有了以下的對話過程。 HSDc RA：特助、主任以及所有承辦人員，今天主要是要開始進行需求方面的訪談，為了讓整個訪談過程可以順利進行，我們預(yù)計采用“用例”方式與各位進行溝通。 信仁醫(yī)院特助：用例？這與我們以前熟悉的訪談方式好像不大一樣，你能夠進一步說明一下嗎？ HSDc IRA：各位，其實這與一般的訪談方式十分類似，只是讓我們能夠更明確地知道現(xiàn)在要談的主題是什么？ 舉例來說，如果今天我要和各位談的主題是“登記住院記錄”，由于經(jīng)過我們的分析，這個主題相關(guān)的人員主要是住院柜臺的人員，因此，我們將只訪談住院柜臺人員以便確切了解他們的需求，并把所有的需求全部整理到“登記住院記錄”這個需求規(guī)范中，這個需求規(guī)范就稱為“用例”。 信仁醫(yī)院特助：喔，這樣我就明白了，其實你所說的用例就是以前其他軟件公司說的“需求功能”嘛！ HSDc RA：嗯，有點類似。只是我們的每個用例都會找出使用這個用例的相關(guān)人員，我們稱其為“執(zhí)行者”（Actor），由于有這樣的分析，因此在訪談時會更有效率。 信仁醫(yī)院特助：嗯，聽起來還不錯。不過以往其他軟件公司都會提供相當(dāng)多的功能菜單讓我們選擇…… HSDc RA：是的，不過我想請問一下，這些軟件公司所提供的功能，貴單位是否會全盤接受？ 信仁醫(yī)院特助：哈哈，這確實令我們感到非常困惑。其實軟件公司提供的功能菜單中，有很多我們搞不懂要做什么，像“醫(yī)保芯片讀取格式轉(zhuǎn)換”、“醫(yī)保媒體申報格式轉(zhuǎn)換”之類的功能。有些功能我們又了無興趣，像“病人基本數(shù)據(jù)建立操作”、“醫(yī)生基本數(shù)據(jù)建立操作”等?？傊痪湓?，你們信息人員交流使用的術(shù)語，對我們來說真的是“天書”啊！ HSDc RA：是啊，這就是為什么我們要采取“用例”取代“功能菜單”的原因??！“用例”重點考慮貴單位用戶對于系統(tǒng)的“期望”（Expectation）。因此，我們會先利用貴單位的“標(biāo)準(zhǔn)作業(yè)程序”作為基礎(chǔ)，找出真的對貴單位有幫助的系統(tǒng)功能以及其相關(guān)執(zhí)行者。這樣，我們就可以針對每個功能進行需求收集，讓整個系統(tǒng)的開發(fā)更有效率！ 信仁醫(yī)院特助：嗯，聽起來令人振奮，那我們就開始吧！ 2.2.2問題與分析 在筆者多年的教育經(jīng)歷中，發(fā)現(xiàn)很多剛開始接觸用例的同學(xué)常問到以下幾個問題： 什么是用例？ 用例與表單是否有關(guān)系？ 用例的開發(fā)有沒有順序性？ 用例與數(shù)據(jù)庫有關(guān)還是無關(guān)？ 為什么不能用“功能樹”（Function Tree）來取代用例？ 以上這些問題，其實與前面信仁醫(yī)院的特助所提的問題有一些雷同之處。其實這些問題的答案，都與以下這個基本假設(shè)有相當(dāng)大的關(guān)系： 系統(tǒng)的功能究竟是用戶所想要的，還是系統(tǒng)開發(fā)人員憑空想象出來的？ 用例本身并不是深奧的學(xué)問，事實上，說穿了，也不過是一句話而已：系統(tǒng)需求的本質(zhì)，最終不過是設(shè)法捕捉到用戶心中的真正期望！ 因此，需求工具本身應(yīng)該具備以下三個特性： 讓用戶一目了然，也就是說，要盡量用通俗易懂的字眼來描述某個功能需求。功能需求的描述必須是“目的性”的，而非“操作性”的。也就是說，要盡可能表達出用戶進入到系統(tǒng)后，通過這個功能需求可以“達到什么目的”，而不是平鋪直敘地說明。

編輯推薦

《UML團隊開發(fā)流程與管理(第2版)》在實例的引導(dǎo)下全面展開論述，內(nèi)容精彩紛呈，講解細致入微，是面向設(shè)計人員的優(yōu)秀讀物。

圖書封面

圖書標(biāo)簽Tags

無

評論、評分、閱讀與下載

---

    UML團隊開發(fā)流程與管理 PDF格式下載

---