出版时间:2012-9 出版社:清华大学出版社 作者:赖信仁 页数:416 字数:563000
Tag标签:无
内容概要
初出茅庐的软件设计新手在面对大量信息时,往往备感迷茫,不知从何处下手;有本书在手,这样的问题将迎刃而解。《uml团队开发流程与管理(第2版)》在实例的引导下全面展开论述,内容精彩纷呈,讲解细致入微,是面向设计人员的优秀读物;《uml团队开发流程与管理(第2版)》主要内容如下:
介绍uml及使用场合
《uml团队开发流程与管理(第2版)》第i部分设计了一个完整案例,井在其中应用了14个uml图形;通过对话方式说明14个图形的含义和应用方式,指导读者在实践中掌握uml基础知识。
讲述如何在实际项目中应用uml
《uml团队开发流程与管理(第2版)》第ii部分设计了另一个完整案例,该案例结合使用了软件工具、uml、mda和不同平台的编程语言(java、c#),并提供了练习单元,让读者“从做中学”。
讨论软件开发团队合作模式
《uml团队开发流程与管理(第2版)》第iii部分列举团队合作案例,引领读者了解团队中的各个角色并挑选合适的工具。
分析enterprise architect9.2的用法
《uml团队开发流程与管理(第2版)》所有案例均使用enterprisearchitect,enterprisearchitect是一套完整的uml支持工具,可支持14个
uml图形以及多种编程语言和数据库,并能提供极大的定制化空间。
作者简介
赖信仁,信仁软件设计负责人。精通面向对象思想、UML、程序设计、系统设计实战及数据仓储等。担任多家公司(台湾电通、中科院、农学社、台积电TSMC、统一企业)的软件配置顾问。参与多项系统开发项目(CMO
eRMA、TSMC
eMaterial、秀波电子ERP、台湾电通Workflow、台湾电通财务系统等)。曾任系统分析师及专业讲师;并于台积电及奇美电子担任高级软件设计师,负责软件技术策略的拟定及开发新软件技术。文化大学进修推广部软件设计与实务应用班——UML
2.0与Java J2EE讲师。..
书籍目录
第i部分uml基础
第1章案例设计与说明
1.1案例背景说明
1.2总结
第2章利用uml表达业务流程与系统需求
2.1活动图与业务流程
2.2用例图与系统需求
2.3总结
第3章表达系统内部的结构
3.1系统结构与类图
3.2系统结构与序列图
3.3系统结构与通信图
3.4总结
第4章表达系统的微观设计
4.1对象图
4.2状态机图
4.3时间图
4.4总结
第5章表达系统的宏观设计
5.1总则图
5.2包图
5.3交互概述图
5.4组合结构图
5.5总结
第6章表达系统的实现与部署
6.1组件图
6.2部署图
6.3总结
第ii部分umi与软件开发实现
第7章电子化采购管理系统案例
7.1案例背景说明
7.2总结
第8章业务流程设计与需求收集
8.1捕捉业务流程
8.2从业务流程找出用例
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部分软件开发与团队合作
第14章团队合作案例场景介绍
14.1团队合作与uml
14.2案例场景介绍
14.3团队合作机制的环境建立
14.4ea团队合作机制简介
第15章建立uml合作的中央集权控制环境
15.1案例背景说明
15.2开发模型的集中化管理
15.3利用ea中央控制开发模型
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参考书目及网络资源
章节摘录
版权页: 插图: 2.2.1信仁医院案例背景描述 HSDc RA与信仁医院特助就信仁医院住出院系统的作业流程取得共识后,接下来要开始找出信仁医院住出院系统的相关系统需求。 HSDc RA采用HSDc所建议的“从业务流程到用例”的分析方式(有关这部分的详细步骤,请参阅本书第Ⅱ部分的介绍),设法找出有关信仁医院住出院系统中的用例。 用例分析对信仁医院特助以及用户来说是一种全新的需求收集方式,因此,HSDc RA与信仁医院的利益相关方之间有了以下的对话过程。 HSDc RA:特助、主任以及所有承办人员,今天主要是要开始进行需求方面的访谈,为了让整个访谈过程可以顺利进行,我们预计采用“用例”方式与各位进行沟通。 信仁医院特助:用例?这与我们以前熟悉的访谈方式好像不大一样,你能够进一步说明一下吗? HSDc IRA:各位,其实这与一般的访谈方式十分类似,只是让我们能够更明确地知道现在要谈的主题是什么? 举例来说,如果今天我要和各位谈的主题是“登记住院记录”,由于经过我们的分析,这个主题相关的人员主要是住院柜台的人员,因此,我们将只访谈住院柜台人员以便确切了解他们的需求,并把所有的需求全部整理到“登记住院记录”这个需求规范中,这个需求规范就称为“用例”。 信仁医院特助:喔,这样我就明白了,其实你所说的用例就是以前其他软件公司说的“需求功能”嘛! HSDc RA:嗯,有点类似。只是我们的每个用例都会找出使用这个用例的相关人员,我们称其为“执行者”(Actor),由于有这样的分析,因此在访谈时会更有效率。 信仁医院特助:嗯,听起来还不错。不过以往其他软件公司都会提供相当多的功能菜单让我们选择…… HSDc RA:是的,不过我想请问一下,这些软件公司所提供的功能,贵单位是否会全盘接受? 信仁医院特助:哈哈,这确实令我们感到非常困惑。其实软件公司提供的功能菜单中,有很多我们搞不懂要做什么,像“医保芯片读取格式转换”、“医保媒体申报格式转换”之类的功能。有些功能我们又了无兴趣,像“病人基本数据建立操作”、“医生基本数据建立操作”等。总之一句话,你们信息人员交流使用的术语,对我们来说真的是“天书”啊! HSDc RA:是啊,这就是为什么我们要采取“用例”取代“功能菜单”的原因啊!“用例”重点考虑贵单位用户对于系统的“期望”(Expectation)。因此,我们会先利用贵单位的“标准作业程序”作为基础,找出真的对贵单位有帮助的系统功能以及其相关执行者。这样,我们就可以针对每个功能进行需求收集,让整个系统的开发更有效率! 信仁医院特助:嗯,听起来令人振奋,那我们就开始吧! 2.2.2问题与分析 在笔者多年的教育经历中,发现很多刚开始接触用例的同学常问到以下几个问题: 什么是用例? 用例与表单是否有关系? 用例的开发有没有顺序性? 用例与数据库有关还是无关? 为什么不能用“功能树”(Function Tree)来取代用例? 以上这些问题,其实与前面信仁医院的特助所提的问题有一些雷同之处。其实这些问题的答案,都与以下这个基本假设有相当大的关系: 系统的功能究竟是用户所想要的,还是系统开发人员凭空想象出来的? 用例本身并不是深奥的学问,事实上,说穿了,也不过是一句话而已:系统需求的本质,最终不过是设法捕捉到用户心中的真正期望! 因此,需求工具本身应该具备以下三个特性: 让用户一目了然,也就是说,要尽量用通俗易懂的字眼来描述某个功能需求。功能需求的描述必须是“目的性”的,而非“操作性”的。也就是说,要尽可能表达出用户进入到系统后,通过这个功能需求可以“达到什么目的”,而不是平铺直叙地说明。
编辑推荐
《UML团队开发流程与管理(第2版)》在实例的引导下全面展开论述,内容精彩纷呈,讲解细致入微,是面向设计人员的优秀读物。
图书封面
图书标签Tags
无
评论、评分、阅读与下载