uml团队开发流程与管理

1、I推 荐 序本书作者Ringle是一个一直喜欢 思考的、有个性的“大 熊”。在与他合作时， 发现其人如其名、个性温厚笃实、乐于与他人 知识、理性包容、不愠不火，设计速度之快令我好奇他怎么会有如此高的天赋！常常发现与他合作的其他架构师都很难跟上他的速度，很难能找到与他搭配Pair Program架构师；这几年总算找到另一只小 熊Arthur与之搭配，相信Arthur在与Ringle的合作过程中，一定会学到不少东西。我们期望Ringle能够将这上天恩赐的能力充分发挥出来，造福于 上需要这 识的人们，第一版UML团队开发流程与管理中文繁体、简体版相继于 和陆诞生，为那些对 充满热情的莘莘学子提供了优

2、秀的学习资料。该版受到业界、学界人士的广泛好评。本着架构师与时俱进的精神，Ringle不负大家的殷殷期盼，全面更新了第一版的内容，撰写了这本内容更加丰富的第二版书籍。怀着激动的心情拜读本书后，可以发现Ringle是按照以架构为中心的 艺术本质精神，在案例实战演练的引导下循序渐进地 了大量十分重要的知识。以架构观点阅读本书时，可以发现该书并非只是单纯地讨论理论知识，而是恰当地融合了很多实战经验。这是一本让有向架构师生涯发展的读者们扎实掌握知识的好书。祝福Ringle，也盼望陆与 的产业能更加蓬勃地发展！宋企业架构师分会执行长II推 荐 序UML这个名词，对于从事 设计的工作者来说一定非常熟悉，但

3、我相信一定有很多设计师和我走过同样的心路历程。市面上UML的书籍不胜枚举，拿起这些书籍阅读时，也许有时似懂非懂，有时心领神会，甚而也可头头是道地讲出这14 的个别用途，然而，每当在开发项目时准备实际应用UML图形来表达各开发阶段的层次时，就会开始满腹疑惑：“这两个用例的应该是什么？ Association？ Generalization？”、”抓出来的用例怎么像是系统功能？”、“序列图到底要表达到多细节？画的人好辛苦，看的人也好累！”、“活动图表达出来的像是数据流图？”直到我们公司请了HSDc来辅导项目开发后，我那闭塞的思路才豁然开朗了。在参与辅导的过程中，本书作者Ringle将过去我对UML

4、的误解不具实质意义的理论工具完全纠正回来，我重新认识了每的本质意义，一步一步将真实项目，协同开发团队通过UML 并进一步实现出来。经过了HSDc顾问团队的辅导之后，让我对每每陷入泥沼的 开发，重新点燃了热情，有了前进的动力。在设计之余，感叹市面上关于UML与团队开发的书籍总是不够通俗易懂，也许是大师的著作内容层次过高，让 开发初学者无法心领神会地悟透UML本质，从而无法将理论正确的实际应用在项目中。Ringle在各方 之下，终于将其多年来的设计及顾问辅导的经验，集结成书，娓娓道来，引导读者进入模拟的项目角色之中，一步步绘制出UML图形，从实践中了解各种UML图形的本质与绘制方式。书中的第、部分

5、再次利用实战方式，以案例实际带领读者，捕捉企业流程、找出用例、撰写用例与测试案例、实现用例、编码、部署，可确实了解完整的团队 开发流程与建构管理的各个方面， 阅读起来不仅浅显易懂，更让人顿觉恍然大悟，是适合 开发团队中各种角色阅读的一本实用书籍。方雅汶博晖科技项目经理III推 荐 序很荣幸的接到Ringle 的邀请，生平第一次写推荐序，下面 我这个小女子与Ringle 的合作经历。公司在2008年为技术同仁们开设了一系列Java与UML技术培训课程，聘请了Ringle与其顾问团队担任课程的专业讲师，规划长达七的训练。在每次上课时，我看到他们挥汗如雨，全心投入教学及互动，课前或课后也都会互相沟通

6、了解学员的学习状况，并研究如何调整后续的教学方向，这让我备感钦佩和敬仰。课程结，学员们对课程的总体评价很高，我们对此感到十分欣慰！恭喜Ringle将 、项目开发与顾问辅导时的经验等编撰成册，对于期望将面向对象原理应用于开发实务的朋友来说，相信会得到一本价值极高学习指南！翎HiTrust训练中心培训专员IV推 荐 序三年前因负责一个小型系统的开发，带领一组团队完成承接的项目并进行 培训，项目初期就遇到无法有效整理出需求的窘境，项目最后虽然顺利完成，心中却埋下了一连串的问号： 需求提出者虽长期在相关领域任职，提出的需求却是不连贯的片段。这些不连贯的信息要如何有效归纳为需求，才出现鸡同鸭讲的尴尬局面

7、？ 在分析、设计、开发过程中，需求变动的一致性要如何维持？ 项目采用面向对象编程语言开发时，项目成员如何才能迅速地掌握和运用？ 项目有时会承受，要如何进行缓解，让项目在可控的范围内顺利执行？ 哪些部分可以外包出去？在外包的同时，自身应该要做好哪些准备？此外，项目过程中会生成各种文档，例如：系统分析文档 企业的业务活动、准则、系统需求，设计文档则描绘实践系统的 、步骤，生成这些文档需要耗费大量人力，若无法达到有效 的目的，就会出现时程延宕、品质不佳、成本居高不下等现象，项目的失败也就不令人诧异了。文档可被视为企业的重要资产，当然希望能有效地加以保存和运用，但常因相关主事者的习惯和喜恶，而生成各种

8、不同形式的文档，保存的方式也各有不同，降低文档的流通性及可利用性，文件最终散落在各处。虽可作为 者的参考 ，但真正要解决问题时， 只有去阅读大量代码，才能确实理解系统的处理规则，维护人力也会大量增加。文档因欠缺标准、可阅读性而未能得到有效运用，并未真正成为企业的资产，这些都是我们尝试要解决的课题。V偶然的机会中接触了信仁 设计 的顾问团队，经主管的支持，邀请他们分享在 分析、设计、开发领域的心得。此后请他们在一个小型研究项目中提供顾问服务， 借此进行 培训。在为期四 的顾问服务期间，通过运用UML建模方式进行项目需求分析、设计、验证等过程，真切地体验到信仁顾问团队在整合理论与实务上的深厚功力。

9、后来，我们尝试在其他项目上导入UML分析设计的做法，利用“用例图” 来捕捉客户需求并界 范围。利用“序列图”来描绘系统内部的 ，码框架，将这些代码框架来作为外包开发的基础。利用“活动图”与客户确认相关的业务流程。使用EA作为我们项目团 队的共同文档制作平台。在具体操作中，我们并未使用UML全部的建模图形，而以项目团 队可以熟练运用的为主。文档的“ 性”是我们专注的重点，如果纯粹为了UML而使用UML，效果将适得其反，这不是我们所乐于见到的。经过这些尝试的过程，我们逐渐总结出适于在的项目推动的文档规范与模式，地完成了任务。UML 团队开发流程与管理 ( 第 2 版 )本书作者 ( Ringle)

10、即为辅导理论与实践完美融合在一起的顾问之一，经过三年的苦心积累，他将辅导客户的心得整理成册，透过信仁医院的模拟案例，带领读者经由“企业流程”“系统需求”“领域模型”“系统结构(宏观与微观)”“系统实现” 等步骤，探讨UML在系统分析及设计领域的相关议题。全书语言流畅，浅显易懂，像在娓娓讲述一个动人的故事，并对故事的情节进行透彻分析。读者可先以浏览方式快速阅读一次，然后把书放在便利之处，在闲暇时间轻松翻阅， 从万物依存的角度来检视系统、企业、人三者间 的关联，在 开发的工作上能提供另一种思考的方向及层次。此外，虽然本书以面向对象的观念来说明UML的分析设计方法，但其分析设计 并非完全拘泥于采用面

11、向对象开发方式的项目中，读者可以尝试在 传统结构化语言中加以灵活运用，在传统结构化语言中，同样可以清晰地勾勒 的全貌与领域模型。统一企业项目经理VIVII第二版序感谢所有读者对本书第1版提出的批评和改正意见。也借此 的机会，将笔者在这两年来在教学过程中感悟到的点点滴滴融汇到第二版中，希望让读者能有耳目一新的感觉。UML规范从第一版的2.0迈向了2.4，在2.4规范中，UML的重点放到了团队合作方面， 以往单打独斗式的开发方式，因为在新版本中推出了“总则图”(Profile Diagram)而划上了 。因此，在这次 的机会中，笔者将“总则图”加入到 中，在市面上所有的书籍中，相信这是第一次的尝试

12、。此外，在实现的部分，笔者将第1版的VB.NET的实现改为使用C#以及Java Spring Framework。因此，实现的部分增加了大量篇幅。本书语言平实，贴近实用，包含诸多精彩篇章，衷心希望能够得到广大读者的厚爱。VIII言前这本书的 历程可谓一波三折，最初的想法非常简单，只是要写一本 UML、实现与团队合作相关的实务性书籍，但是在实际开始写作时，却发现如果只谈实务操作面，整本书似乎少了“ ”，没有 的书籍，在浩瀚书海中，也会很快被时间的洪流无情地淹没。也因此，在正式开始写书时，笔者想要列出这本书一个简单的“中心思想”。这四个字说来容易，但实际上要浓缩出这个中心思想却非常难。在UML与设

13、计领域内外大师级的作者已经创作出不少优秀，要从这些书籍的夹缝中杀出一条血路，其难度不言而喻；对于我们这些不是大师级的人来说，唯一能够和大师相抗衡的，或许只是一个突发的创意吧！在开始写书的某个时间点，忽然有一个念头浮现在脑海中，那就是写一本十年前的我 无论如何一定会买的书！于是，我把原先写 草稿全部丢弃，重新审视 这十年来学习UML与设计中总结的经验。本书第部分要与那些想要学习UML十四 形的读者交流一下心得。在笔者开始接触UML时，除了对UML的历史稍有了解外，其实对于“什么时候需要用哪一个UML图形”这个简单的问题，是完全没有任何概念的。纵观所有谈论 UML的书籍，无论是UML三个创始人Iv

14、ar Jacobson、Grady Booch、James Rumbaugh所合著的UML User Guide或是笔者最欣赏的大师Martin Fowler所写的UML Distilled，虽然 每的实际内涵都有详尽的呈现与说明，但对于笔者在实际项目中要能够灵活运用这些图来说，帮助实在不大。这并不是说大师们的书有问题，而是对于一个刚开始接触UML或是纯粹对“UML是什么”有的读者来说，这些书籍的写作方式无疑地过于抽象深奥了。也因此，笔者尝试用另式来阐述这UML的十四。笔者将过往的顾问经验做了一个整理，并把许多客户曾经遇到的问题浓缩成一个完整的故事。在开始 每一 之前，通过这个完整故事的部分情

15、节来引出 开发中的问题， 并在后续章节中，利用问题与分析把“为什么在这个时间点要用某张UML图形”带出来，接着该图形的基本语法与如何利用UML工具来绘制图形。由于UML本身是一门“语言”(Language)，因此，笔者认为在学习UML时，应该像学习英文 那样，用情境演练来取代文法 ，这对初学者而言(也就是十年前的笔者)，会比较容易学习与记忆。IX你可以把本书的第部分当 开发过程中的 练习：UML 团队开发流程与管理 ( 第 2 版 )第 2章：主要模拟开发团队与客户的。第 3章第 5章：模拟开发团队间的。第 6章：代表开发团队管理团队的。通过这样的 ，读者也可以试着审视 实际的开发项目，并且尝

16、试和本书的故事情节对应起来，相信对于读者了解“什么时间用什么UML”这样一个练习来说，会有相当大的帮助。 ，的目的在于“实际生成有用的代码”，因此，对于十年前的笔者来说，光是学会UML是绝对不够的。本书第部分则是对于那些想了解“UML如何辅助项目中的各个阶段，让每个阶段以有效产出”的读者来说，所另外设计的一个开发范本。笔者利用另一个案例，展示了从企业流程分析、用户需求分析、系统结构设计到代码写作的完整开发流程。对于初学者而言，可以将第部分作为 在实际开发时的范本，也可以从每一个不同阶段的具体叙述中，找到各个阶段的一些需要遵循的规范。在本部分中，笔者同时参考了“统一流程规范”(Unified P

17、rocess，UP)、“ 模式” (Tran ion Pattern)、MDA、“极限编程”(Extreme Program ，XP)以及“重构”(Refactoring)。笔者实际进行顾问辅导以及开发内部 时，顾问团队也始终按照这个流程来执行任务。我在产业的第一份工作是从系统分析师(System Analyst，SA)开始做起，之后才开始学习写程序以及学习作一个 架构师，也因此，在笔者的 生涯中，其实在刚起步的阶段，就相当重视“如何建构团队合作的环境及机制”。在这样的一个背景下，笔者秉持 着“写给十年前的我一定要买的书”的中心思想，进一步阐释有关团队合作环境及机制的 建立。本书第部分将第部分

18、有关团队合作的分离出来，并且利用故事情节来说明“在何时需要导入什么样的团队机制”。有鉴于中文书籍中对于团队合作的讨论相当稀少，因此在本部分中，笔者加入了Subversion的配置、版本库的建立策略、安全控制机制的建立等内容，希望能提供给想要建立团队合作环境的读者一个可以遵循的基本策略。总之，本书完成后，我尝试以十年前的心情来读这本书。虽然多少还是有些不满意，不过，十年前的知道的，在这本书中至少已经完成七成以上。本书面向那些对设计、UML以及团队合作有 的读者，期待读者与笔者以在 设计领域中，继续奋斗与努力！X前言配套学习资源配套学习资源提供了一些与本书配套的学习资源。可登录该 ，输 的ISBN

19、或书名打开 页面，在其中 需要的内容。 包含正文中提及和用到的三个文件夹的内容：Example、M和Resource。反馈邮箱如果对本书有任何意见或建议，请与我们。我们的反馈邮箱是wkservice， 投稿信箱是bookservice。XIXIIXIII谢致这本书能够得以完成，要感谢那些在我人生历程中，不断鞭策和鼓励 家人、朋友及同事们。感谢同事Ken ，如果不是你的督促，这本书到现在可能仍然只停留于构想阶段。感谢同事Arthur以及 部的成员， 你们对这本书提出的许多有益建议。感谢我的编辑，虽然在我屡屡没有赶上原先设定交稿时间，仍然给予我最大的支持与包容。感谢我在 设计的道路中的导师 先生，

20、没有您的指导， 对于 世界中的美好事物，我可能永远都 了！最后，感谢 父母、姐姐以及亲爱的妻子，没有你们温暖的鼓励与包容，我可能早就放弃 设计，也 有这本书的诞生了！录目第部分UML 基 础第1章案例设计与说明31.1 案例背景说明41.2 总结5第2章利用UML表达业务流程需求72.1 活动图与业务流程82.1.1 信仁医院案例背景描述82.1.2 问题与分析102.1.3 有关活动图的·················&#

21、183;·················································&#

22、183;·········································· 112.1.4 信仁医院住 的活动图142.1.5 在EA中绘制活动图152.2 用例

23、图需求202.2.1 信仁医院案例背景描述202.2.2 问题与分析212.2.3 有例图的 ··········································&

24、#183;·················································&

25、#183;················· 222.2.4 信仁医院住 的用例图242.2.5 在EA中绘制用例图242.3 总结28第3章表达系统内部的结构293.1 系统结构与类图303.1.1 信仁医院案例背景描述303.1.2 问题与分析333.1.3 有关类图的·············

26、··················································

27、··················································

28、· 343.1.4 信仁医院住 的领域模型363.1.5 在EA中绘制类图383.2 系统结构与序列图463.2.1 信仁医院案例背景描述46UML 团队开发流程与管理 ( 第 2 版 )3.2.2 问题与分析483.2.3 有关序列图的·····························&#

29、183;·················································&#

30、183;······························ 493.2.4 信仁医院住的序列图案例503.2.5 在EA中绘制序列图513.3 系统结构与通信图543.3.1 信仁医院案例背景描述543.3.2 问题与分析563.3.3 有关通信图的···&#

31、183;·················································&#

32、183;·················································&#

33、183;······ 573.3.4 信仁医院住的通信图案例583.3.5 在EA中绘制通信图583.4 总结61第4章表达系统的微观设计634.1 对象图644.1.1 信仁医院案例背景描述644.1.2 问题与分析654.1.3 有关对象图的························

34、83;·················································

35、83;··································· 664.1.4 信仁医院住的对象图案例664.1.5 在EA中绘制对象图674.2 状态机图694.2.1 信仁医院案例背景描述694.2.2 问题与分析704.2.3 有

36、关状态机图的·················································

37、··················································

38、······· 714.2.4 病床状态的状态机图案例724.2.5 在EA中绘制状态机图734.3 时间图754.3.1 信仁医院案例背景描述754.3.2 问题与分析764.3.3 有关时间图的···························

39、3;·················································

40、3;································ 764.3.4 病床状态的时间图案例774.3.5 在EA中绘制时间图774.4 总结80XVI目录第5章表达系统的宏观设计815.1 总则图825.1.1 信仁医院案例背景描述825.1.2 问题与分析835

41、.1.3 有关总则图的················································&

42、#183;·················································&

43、#183;··········· 845.1.4 信仁医院住的总则图案例865.1.5 在EA中绘制总则图865.2 ·······························

44、··················································

45、·················································935.2.

46、1 信仁医院案例背景描述935.2.2 问题与分析945.2.3 有的············································&

47、#183;·················································&

48、#183;··················· 955.2.4 信仁医院住的 案例955.2.5 在EA中绘制 ························

49、3;·················································

50、3;····································· 965.3 交互概述图975.3.1 信仁医院案例背景描述975.3.2 问题与分析985.3.3 有关交互概述图的···

51、;··················································

52、;················································· 995.

53、3.4 正常处理与意 的交互概述图995.3.5 在EA中绘制交互概述图1005.4 组合结构图1025.4.1 信仁医院案例背景描述1025.4.2 问题与分析1045.4.3 有关组合结构图的·································

54、3;·················································

55、3;················1045.4.4 信仁医院住与其他系统 的组合结构图1065.4.5 在EA中绘制组合结构图1065.5 总结109第6章表达系统的实现与部署1116.1 组件图1126.1.1 信仁医院案例背景描述1126.1.2 问题与分析1136.1.3 有关组件图的············&

56、#183;·················································&

57、#183;·············································1136.1.4 信仁医院住的组件图案例114XV

58、IIUML 团队开发流程与管理 ( 第 2 版 )6.1.5 在EA中绘制组件图1146.2 部署图1166.2.1 信仁医院案例背景描述1166.2.2 问题与分析1176.2.3 有关部署图的·································

59、3;·················································

60、3;························1176.2.4 信仁医院住的部署图案例1186.2.5 在EA中绘制部署图1186.3 总结122第部分UML与 开发实现第7章化采购管理系统案例1257.1 案例背景说明1267.2 总结126第8章业务流程设计与需求收集1298.1 捕捉业务流程1308.1.1 Erikson-Penker业务扩展模

61、型简介1308.1.2 化采购系统的业务流程1328.2 从业务流程找出用例1388.2.1 用例需求1388.2.2 找出用例的步骤1408.2.3 编写用例的测试案例1458.3 总结152第9章实现用例1539.1 分析类与用例1549.2 勾勒用例的对象1569.3 模式与实体对象1639.3.1 模式的原理1639.3.2 模式在化采购系统的应用1689.4 使用序列图描述对象交互1709.5 总结179XVIII目录第10章领域模式、平台技术与类模式18110.1 MDA基本·········

62、··················································

63、··················································

64、18210.1.1 模式驱动架构(MDA)简介18210.1.2 EA MDA机制简介18510.2 不同平台的实现技术18710.2.1 N-Tier系统与N-Layer开发模式总览18710.2.2 .NET Framework的重要技术······························

65、;·················································18910

66、.2.3 Java平台中的重要技术19010.3 利用MDA转换领域模型19210.3.1 将 对象转换为C#的实现类19210.3.2 将 对象转换为Spring Framework的实现类19810.3.3 将实体对象转换为MySQL的物理数据模型20610.4 总结209第11章测试代码的编写21111.1 在不同平台中新增项目与码21211.1.1 在.NET平台 码21211.1.2 在Java平台码使用Spring Source Toolsuite21411.1.3 产生MySQL的DDL21711.2 在不同平台中编写测试代码21911.2.1 功能性测试的基本观念21911.2

67、.2 在.NET平台编写功能测试代码使用C# 2010 Express +NUnit22011.2.3 在Java平台编写功能测试代码使用SpringSource Toolsuite22411.3 总结230第12章代码的编写23112.1 编写领域层代码23212.1.1 编写.NET平台的领域层代码23312.1.2 编写Java平台的领域层代码24112.2 编写数据源层代码26612.2.1 编写.NET平台的数据源层代码26712.2.2 编写Java平台的数据源层代码27412.3 总结280XIXUML 团队开发流程与管理 ( 第 2 版 )第13章代码的重构28313.1 代码

68、重构的时机28413.2 重构手法28513.2.1 与结构相关的重构28513.2.2 结构细节的重构28913.3 结构的重整与设计模式29013.4 化采购系统重构练习(C#)29113.5 总结301第部分开发与团队合作第14章团队合作案例场景·····························

69、············································· 30514.1 团队合作与UML30614.2 案例场景

70、··················································

71、··················································

72、··········30614.3 团队合作机制的环境建立30714.4 EA团队合作机制简介308第15章建立UML合作的 环境31115.1 案例背景说明31215.2 开发模型的集中化管理31215.3 利用EA 开发模型31315.3.1 EA 库结构31315.3.2 设置EA的客户端31815.4 总结330第16章配置管理与UML33116.1 案例背景说明33216.2配置管理的原理与操作33216.2.1 配置管理的基本原理33216.2.2 Subversion的原理以及安装

73、33516.2.3 Subversion的安装33616.2.4 Subversion库的规划34616.3 利用EA进行配置管理355XX目录16.4 总结358第17章团队安全机制与UML35917.1 案例背景说明36017.2 EA的团队合作机制36117.2.1 启动EA的权限 机制36117.2.2 设置用户与组36217.2.3 设置存取权限36417.3 练习36617.4 总结368第IV部分附录附录AEA的基本操作371附录BEA的定制化379附录C参考书目及网络资源415XXIUML 基 础第部分 本部分学习提示本部分主要利用一个实际案例来 UML(Unified Min

74、g Language)2.4规范中的14个UML图形。在该实际案例中，将会使用场景来说明这14个图形的应用时机，并在每一个图的说明 中穿插有关该图形在OMG(Object Management Group)所制定的UML 2.4规范中的相关注意事项，读者可以通过案例与该规范的比较，来学习正确的UML 2.4规范。在所有的实践练习中，本书所使用的UML工具主要是Sparx Systems公司的EA 9.2版本， 读者可以安装相应的版本进行练习，可以 Sparx Systems的. com 该版本。本部分不涉及实际代码的生成，仅着重UML图形，如果读者对实现感，建议从第部始阅读，将本部分当作UML

75、规范的参考资料。 第1章案例设计与说明01020304050641.1 案例背景说明信仁医院是一家区域医院，共有200张病床，医院的职能科室 内科、外科以及皮肤科。该医院在2000年采购了一套医院内部的医院管理系统，其中 门诊系统、挂号系统、收费管理系统、医保申报系统以及财。以往，信仁医院在办理住院出院时都必须使用人工填表的方式，只有在医保给付、门诊医嘱以及收费管理部分，才能进入医院管理系统进行 。但为了实现“e化医院项目”， 信仁医院的住、必须重新进行设计。信仁医院为了设计其住院和 ，委托HSDc进行系统的开发，且为了符合其项目招标的需求，HSDc设计规格必须要使用UML图形来表示。HSDc

76、的RA到信仁医院进行实地了解，发现了该医院的住出院流程如下： 患者到信仁医院就诊，由医师患者是否需要住院。 医护查看院内目前是否有可用病床，如果有，则告知患者进行住院登记。 患者到住院柜台进行住院登记。第 部分 医护告知患者其病房及病床号码，并通知该病房负责护理站有关该患者的病历。 患者到病房住院，负责护理站指派住院医生视察患者状况。UML 早晨，患者的主治医师会到病房巡房及看诊，如果有检查，则指定护理站负责护理在预定的检查时间带患者进行检查。基 础 主治医师患者已可出院，便告知患者及负责护理站患者的出院日期及时间。 病房负责护理站收到“患者可出院” 后，需在10分钟内将患者所有用药及看护费用

77、通知收费管理系统。 患者办理出院登记，医护告知患者应缴付的费用金额。以上是第一次访谈后，RA所收集的住院和出院的基本流程。你将会在未来章节中看到以下的角色参与整个案例的说明，： HSDc RA：主要负责与信仁医院，收集相统的需求。 HSDc Architect：主要负责建立系统的架构，在必要时也需要和信仁医院的领域 (Domain Expert)相互合作。 信仁医院特助：信仁医院的领域，对于医院的重要概念与业务流程有相当深入的认识。 信仁医院医护：实际系统的操作。150605040302011.2 总结本章的宗旨是给出简单的背景说明，在未来的章节中，将会逐步讲解本章未曾说明的细节。或许有些读者

78、会认为，在初期访谈阶段，只收集到上述的需求似乎有些贫乏空洞，但实际上这些读者对整体开发明显的误解。对于项目开始阶段的初期访谈，最好抓住以下几个重点：(1) 项目的范围：先找出目前已 的系统，了解该系统是否提供了相关的集成接口， 这一点与你所要开发的项目的复杂度有相当大的。(2) 必要的(Essential)业务流程：在摸索业务流程时，初期应该尽可能只捕捉“必要的” 业务流程，在该业务流程中，尽量避免对细节的研究，有关这方面，下一章将予以更详细的。(3) 项目的技术限制：使用的技术以及其他系统间的交流接口规范。(4) 项目的关键因素：要充分了解利益相关方(Stakeholder)对于整体项目与否

79、最关切的问题是什么，并且评估问题和项目成败的风险是否相关。第 章 案例设计与说明上述四个重点，其实在一开始就决定了项目是否会 ，如果在项目开始时就落入了细节性的讨论，反而非常容易造成项目的失败，对于开发团队来说不可不慎。而言， 上述四个重点，开发团队应该要尽快地先进行整体架构的POC(Proof Of Concept)，让使用者以及开发团队在初期就获得足够的信心；当然，这是属于项目开发方面的，并不 的讨论范围中。不过无论如何，千万不要一开始时就落入“分析瘫痪” 的陷阱，这是 开发团队必须要谨慎面对的课题！第部分UML与开发实现 本部分学习提示本部分 了一个 实现 ，并在一个“ 化采购系统”案例

80、的引导下讲述具体实现方式。本部分并对所用到的UML图形的相关语法特别说明；如果读者对语法还不熟悉，可参阅本书第部分来了解相关的语法。本部分的练习除了使用EA作为UML开发的相关工具外，还会使用Microsoft Visual Studio 2010 Professional Edition以及Spring Tool Suite作为编码平台，使用NUnit 2.0及JUnit作为测试平台，使用MySQL 5.1 Commu作为数据库平台；读者可以直接到相对应的 以下安装程序的最新版本: NUnit - MySQL - Spring Tool Suite - java本部分中所有的案例，都会放在配

81、套学习资源 中的ExampleeProcumentSystem下， 读者可将文件到的计算机上进行练习。 第7章化采购管理系统案例070809101112131267.1 案例背景说明IDM是一家大型家电商，主要业务是和销售家电。IDM的系统了一个大型ERP(Enterprise Resource Planning，ERP)。该ERP的数据库提供一组接口表格(Interface Table)供外部调用，该接口表格放在MySQL数据库中，外部系统可通过 或ODBC直接连接该组接口表格；此外，外部程序可以通过SMTP直接调用该公司的邮件系统。因为想要为厂商提供更加即时快捷的服务，IDM委托HSDc设

82、计一个 化采购系统；HSDc的RA在经过访谈后，该化采购系统整理了以下几个基本流： 该厂商是一家家电商，其上游有多家供应商，供应相关的各种原料。 当该厂商的生产 在其ERP拟定生产计划后，会将该年度的原料请购 送至电子化采购系统，该 化采购系统会自动产生“采购要求”(Request For Purchase， RFP)，并利用系统以及邮件通知的供应商。 供应商在收到或是 邮件通知后，必须要先到该厂商的化采购系统中，在采购要求所需的时间内提出报价单。第 部分 该厂商的采购 (Buyer)通过 化采购系统进行比价，决定第一优先及第二优先顺位的供应商，并产生采购单，同时通过系统以及 邮件通知这两家供

83、应商。UML 供应商收到后，如果确认要供货，必须在规定的期间内，到 化采购系统确认采购单， 化采购系统收到确认后，会以邮件通知负责的采购。与软件开发实现 采购到化采购系统确认采购单，化采购系统会将该采购单返回至该IDM 的ERP系统中。接下来将根据上述需求来说明如何利用用例技术收集有效的需求并快速开发程序，还会利用测试优先开发方式来有效地验证需求。7.2 总结本部分重点 开发过程(Software Development Process)，而赘述过多的UML 语法，如果读者对于本篇中相关的UML语法有不甚明了之处，可以回到本书第部分重新 复习。712713121110090807第 章 电子化

84、采购管理系统案例开发过程，主要分成“需求收集”(Requirement Acquisition)、“系统设计”(System Design)以及“编程”(Program )三个阶段。本书主要利用“迭代增量”(Iteration and Incremental，I&I)方式来开发这三个阶段；每个“迭代”(Iteration) “用例”为目标，每个用例会经历三次“增量”(Incremental)处理过程。本部分的案例首先 找出用例的 ，接着以一个用例作为练习的基础， 该用例如何利用I&I方式快速进行系统开发，并且利用“事先设计+重构(Refactoring)” ，让系统更具弹性和可

85、复用性。 第13章代码的重构0708091011121328413.1 代码重构的时机在笔者多年的顾问以及教育过程中，常有人问笔者，在整体开发中重构既然已经成为不可或缺的一个步骤，那么，究竟什么时候必须要重构？又如何才能知道重构时机已经来临呢？根据XP的创始人Kent Beck的说法，“时时重构”是不可避免的。，这句“时时重构”似乎和“所有事物都是对象”一样，说的 ，但是却缺少了一点“喔！我知道了！”的那种味道。相信对刚开始学习设计的人来说，这句话的确太空泛了。那么，除了这句空泛的话之外，是不是可以有一个“确切的准则”，让 设计 可以依据该准则“遵章办事”？这种想法不能说不对，只是有点天真。设计如果 以规范成一定的准则，那么，我们 设计 的工作，不早就被记忆能力比我们超出不止千倍的计算机所取代了？ 设计，不可避免地会有一些“人的因素”掺杂在内。对Kent Beck以及Martin Fowl