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

內容概要

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

作者簡介

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

書籍目錄

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

章節(jié)摘錄

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

編輯推薦

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

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

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

---