Thinking in uml--http://www.uml.org.cn/oobject/201008245.asp

xueqibuildxue

浏览: 798791 次
性别:
来自: 大连

最近访客更多访客>>

yf2000

XiaoPY

faxMonkey

feiruqueshui

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

UML ASP 设计模式领域模型企业应用

UMLO 火龙果

大象-Thinking in UML早知道

2010-08-24 作者：coffeewoo 来源：coffeewoo's Blogs

1--公告

亲爱的关注本博的朋友，最近一段时间俺都忙于写书，没有时间更新博客，让许多朋友久等了。

由于书的写作和出版需要较长的时间，预计出版时间已经排到了08的11月份。俺曾经答应过一些朋友，在书没有出版之前，在这段时间内将书的一部分内容先在博客上发表，一方面为了感谢他们对俺一直的支持，另一方面也为书做点宣传，毕竟要是销路不好的话浪费这一年的辛苦倒也罢了，要是还要自己贴钱那就真是赔了夫人又折兵了^_^

目前书已经完成了三分之一左右，从今天开始，每隔一段时间都会发表书中内容的一部分。当然，出于可以理解的原因，请原谅俺不能发表完整的章节，也不能披露过多的内容，那里还有一纸合同呢……

本书名定为《大象-Think in UML》，这是因为笔者在书中写了大量的自己的思考和经验，与之前的OO之路系列相似，因此使用了Thinking 这个词。至于大象，呵呵，留个悬念吧，或者有朋友可以猜出来是什么意思？

今天这贴算是一个公告吧，顺带把书中《写给读者的话》先发表出来。下一帖再发表实际的内容。谢谢朋友们的支持哦！！

写给读者的话

近几年来，面向对象几乎成为软件技术的代名词。不论是学校设置的计算机课程，还是时下最流行的编程语言、设计方法，还是新兴的概念、标准和新思想莫不被冠以面向对象的标志。而UML是面向对象方法的一面旗帜，谈到面向对象的分析和设计就不能不谈到UML。如今UML也成为了面向对象分析和设计事实上的行业标准。然而什么是UML？怎样使用UML？UML仅仅是一组符号吗？可以说，UML是面向对象思想和方法的具体化和符号化。学习UML的过程就是掌握面向对象思想和方法的过程。相对学习UML的符号含义而言，掌握它们背后的方法和思想则是更为重要的。古人将知识分为“技”和“道”，习技固然可以成为人杰，而悟道才能羽化升仙。希望读者不满足仅仅于学会使用UML，而能够从中悟道。

不论是面向对象的方法，还是面向对象的杰出代表UML，许多朋友在现实中并不能真正掌握它们。虽然用着面向对象的工具，采用面向对象的语言，却做不出一个真正符合面向对象思想的软件。笔者在工作中发现许多使用了多年UML的人其实并不真正理解UML的意义，常常用着UML却做出了并非面向对象的设计。就像一个不知道诗歌格律的人，不论采用什么文字都写不出诗歌一样；没有真正理解面向对象的思想，没有真正掌握面向对象的方法，仅仅使用UML符号并不等于可以做出面向对象的分析和设计。

人类自从有思想以来，就在不断的探寻和认识自己所生活的这个世界。本质上说，面向过程和面向对象都是人们认识这个世界的方法；而具体的技术，则是在采用这种方法认识世界的过程中被发明、总结和归纳出来的最佳实践。对于学习者而言，掌握这些技术是重要的；掌握这些技术表示你已经继承了前人的经验积累，并且是一个捷径，一如设计模式。但是，作者更建议把学习提升一个层次，超越具体技术细节去思考其背后蕴含的思想和方法。这正是本书要冠名以Thinking in UML的原因。然而本书并不是一本讲述哲学和方法论的书籍，相反，本书中将以大量的实例来进行阐述，同时把作者在面向对象分析和设计领域的经验溶入其中，更像是一本实战手册。本书除了讲解面向对象的基本概念和UML语言之外，将采用更大篇幅现身说法，深入浅出的把面向对象思想的精髓、分析思路、推导方法传授给读者。本书的讲解均来自实际工作，乃作者多年工作经验和最佳实践的总结和归纳。这些经验和最佳实践来源于实际，更贴近于实际。

本书中某些实例或许正好与读者正面临的问题相同或相似，读者当然可以照葫芦画瓢，举一反三地去解决现实中的问题，然而这并非作者的本意。作者在思考这本书的时候，是希望以实例为线索，将思考方法和分析过程传达给读者，让读者理解某个具体解决方案背后的思考过程、分析过程和推导过程。哪怕读者经过思考得出与作者完全不同的结果，甚至证明出作者所给出的解决方案并非一个好方案，这也是作者所期望的。

希望读者在阅读本书的过程中，关注并思考作者在面对一个问题领域时的思考和分析过程，而不要沉迷于书中给出的具体事例。本书的核心是Thinking，UML只是表达的载体。如果读者能从作者的分析方法中获得灵感，对面向对象的分析和设计有所感触，开始有恍然大悟的感觉，那么作者将最大程度的感到欣慰。另外，作者的分析方法和推导过程只是作者本人在工作中自己总结出的经验，不是标准答案，更不是圣经。期望读者能够从作者的这些经验中经过思考，结合自己的实际，获得自己的方法。如果真是这样，作者的这些文字工作就真正劳有所值了。

为了让读者方便阅读，本文中的绝大部分示例图中的UML元素都是用中文命名的。在实际工作中作者建议除了业务模型部分，其他模型都最好使用英文，这是因为一方面Rose对中文的支持不太好，另一方面毕竟最终代码实现是英文的，模型与实现都用英文会避免很多歧义。

最后，感谢您购买此书，希望在本书中能够找到那些正在困扰着您的问题的答案。祝大家阅读愉快！

2--面向过程方法与面向对象方法

3--基本建模方法

4--参与者基本概念

5--业务实体

6 -- 非功能性需求

如何采集非功能性需求

在需求阶段，与功能性需求不同，非功能性需求是需要需求人员主动引导的。因为客户并非计算机专家，除了可用性之外，他们很少会考虑其它的非功能性需求。即使提出，也是很模糊的要求，比如速度要快，报表要在一分钟之内统计完成等模糊的语言。

需求人员要在需求过程中了解清楚系统的应用环境，包括硬件环境、网络环境、用户情况、预期使用人数、并发使用情况等等，这些因素都是确定非功能性需求的重要依据。在收集非功能性需求时，可以采用固定表格的形式，一个一个问题搞清楚。下面笔者给出一个调研表的示例，供读者参考。在这个表格中，通过回答表中的问题来确定非功能性需求的指标。

非功能性需求调查表
可靠性
安全性	系统数据的敏感程度？	在此回答系统数据的保密要求。这个要求与客户的业务相关，是指的整体敏感程度。例如可以分为机密、保密、一般、公开等几种类别
系统运行于何种环境？	在此回答系统的运行环境。是运行于Internet还是Intranet？是公用服务器还是私有服务器？是集中式应用还是分布式应用？是单机版还是服务器版？
客户组织中的信息保密制度？	在此回答客户组织中的信息保密制度。例如，工资数据、财务数据保密级别很高，只有组织中的部分人员可访问；一般公司制度数据，人员资料可向内部人员公开等等。
使用人员成份情况	在此回答使用人员的成份。例如，是否都是内部人员？是否分为正式员工和合同工？是否有外部人员访问等等
事务性	系统业务交叉程度如何？	在此回答业务的交叉程度。如果多个部门或很多用户频繁的对同一份数据存取，业务交叉程度就高，相应的事务性要求也就高。
数据精确度要求如何？	在此回答数据的精确度要求。如果数据精确度要求很高，例如财务数据，相应的事务性要求也就高；反之，例如人员档案资料，精确度要求低，相应的事务性要求也就没那么严格
业务是在线的还是离线的？	在此回答业务的运行要求。在线交易必须保证事务性，所谓一手交钱一手交货。而离线交易则事务级别可相应降低。
系统集成情况如何？	在此回答系统的集成情况。如果系统与其他很多系统集成在一起，相互依赖于数据的同步，那么事务性要求就高。
是分布式系统还是集中式系统？	在此回答系统的应用模式。如果系统是分布式的，那么一般都需要借助事务中间件完成全局事务。否则，有可能数据库本身的事务处理机制就能满足要求。
稳定性	系统的服务能力要求如何？	在此回答系统的服务能力要求。例如是需要7*24小时不间断服务，还是可以允许短暂停机。
用户的操作频率如何？	在此回答用户的操作频率。例如，假设每操作10次就可能出现一次故障，如果客户每天只使用1次，那么或许是可以忍受的。但如果客户每天使用10次以上，就是不可忍受了。
业务的及时性要求如何？	在此回答业务的及时性要求。例如，客户的业务依赖于数据的连续传输，一旦数据链停止，整个业务都将停止，则系统稳定性要求就高。反之，如果今天传输数据，明天才来读取，稳定性要求就低。
数据的重要程度如何？	在此回答数据的重要程度。例如，一旦部分数据丢失，整个系统就存在失效或崩溃的风险，则稳定性要求就高；反之，如果数据丢失，不影响系统的正常运行，稳定性要求就低。

可用性
界面	客户的行业性质如何？	在此回答客户的行业性质。不同的行业性质应该有不同的界面风格考量。例如，给政府部门做项目，界面风格应当是庄严稳重的，不能设计成娱乐网站式的花花绿绿。
客户的企业文化如何？	在此回答客户的企业文化。界面的色调和风格应与客户的企业文化相符合。例如，如果客户以年轻人居多，界面风格可以轻松活泼一些。如果以老年人居多，界面风格应当稳重一些。
客户业务的复杂程度如何？	在此回答客户业务的复杂程度。例如，客户的业务功能庞杂，界面设计时导航功能考虑就要多一些，尽量在一个版面容纳更多的功能并方便导航；否则，就应该考虑第一时间可以看到所有功能。
使用人员的情况如何？	在此回答使用人员的情况。如果使用人员计算机素质较高，可以考虑复杂一些的界面设计，反之就应当尽量简单和直接。
操作习惯	客户之前使用过什么系统吗？	在此回答客户之前使用过系统的界面风格。人总是有惰性的，尤其对上了年纪的人来讲，适应新的风格总要慢一些。应当考虑保持原先客户习惯的操作模式。
客户喜欢怎样的操作风格？	在此回答客户习惯的操作风格。例如是喜欢菜单，还是导航条，是喜欢按钮，还是超链接等。
文档要求	客户需要联机文档吗？	在此回答客户是否需要联机文档。联系文档类似word的帮助菜单里的内容。
客户需要在线帮助吗？	在此回答用户是否需要在线帮助。在线帮助需要在界面中放置该界面的操作指导。
客户的计算机操作水平如何？	在此回答客户的计算机操作水平。若客户的操作水平较高，则用户手册可专心描述业务操作；若客户的操作水平很差，则用户手册还要考虑普及一些计算机基础知识，并且多使用界面截图。

有效性
性能	系统的平均访问量？	在此回答系统数据的平均访问量。平均访问量是指在特定的时间段内，比如天，或小时，系统平均被访问的次数。
系统的峰值访问量？	在此回答系统的峰值访问量。峰值访问量是指在特殊的情况下，系统瞬时可能被访问的最大数量。
系统的数据流量？	在此回答系统的数据流量。数据流量是指在系统中传输和处理的数据量。包括数据的数量和数据的大小。
系统的并发要求？	在此回答系统的并发要求。并发是指同一时间内多个访问者对同一资源的访问。区别于平均访问量。若同时使用系统但访问的是不同资源，则不称为并发。
硬件环境如何？	在此回答系统的硬件环境。包括服务器情况，例如内存、CPU、硬盘等，以及网格状况，例如带宽、交换机容量等。
可伸缩性	客户业务预期的扩张速度？	在此回答客户业务预期的扩张速度。业务扩张速度是指使用系统的频繁程度，随着业务的扩张，使用系统的频率随之提高，就需要系统有一定的伸缩能力。
客户数据量的扩张速度？	在此回答客户数据的扩张速度。即使客户的业务没有扩张，但有可能随着系统的使用，数据量急剧扩张。这也需要系统具备一定的伸缩能力。
使用人数的扩张速度？	在此回答使用人数的扩张速度。例如网站，随着人气的提升，访问人数可能呈爆炸性增长，也需要系统具备一定的伸缩能力。
可扩展性	系统规模会持续扩大吗？	在此回答系统规模是否会持续扩大。例如客户的项目是分期建设的，系统规模会随着项目的进展持续扩大。则系统的建设初期就要考虑扩展性。
客户是否有长期系统建设的计划？	在此回答客户是否有长期的系统建设计划。如果客户具有这样的计划，随着新建设的系统不断加入运行，同时还要保证原先系统的稳定，就要考虑系统的可扩展性。
客户有升级系统的长期计划吗？	在此回答客户是否有系统升级的长期计划。如果客户具有这样的计划，那么技术的升级换代是不可避免的。系统在建设的初期就要考虑可扩展性。

可移植性
硬件环境	客户当前的硬件环境如何？	在此回答客户当前的硬件环境。若客户的硬件设备比较陈旧，面临着更新的问题，那么系统移植应当被纳入考虑范围。至少应当考虑假设客户将来要更新设备，会更新成哪一类设备
客户是否有长期的硬件厂商合作伙伴？	在此回答客户是否有长期的硬件提供商。假设客户有长期的设备供应商，那么客户的硬件设备就会比较稳定，相应的移植能力也就没那么重要。反之，如果客户隔三岔五的更换设备供应商，系统的移植能力就需要重视了。
客户的业务是否在快速增长？	在此回答客户业务增长速度。如果客户的业务增长迅速，那么相对频繁的升级硬件设备就是意料中的事，移植能力就重要一些。反之，客户业务稳定，升级硬件设备的可能性就低，相应的移植能力也就没那么重要。
软件环境	客户和系统运行环境如何？	在此回答客户的系统运行环境。如果客户的系统运行环境比较单纯，仅有有限的系统在运行并且相互之间关系不大，则移植的可能性小。反之，客户就有可能从信息化的整体考虑而提出统一系统平台的构想，由此带来移植的问题。
客户是否有长期的软件提供商？	在此回答客户是否有明确的软件供应商。例如客户如果与某家应用服务器供应商建立了长期合作关系，那么改变软件环境的可能性就小。反之，就有可能因为改变了第三方软件产品而带来移植问题。
自己是否有长期明确的技术路线？	在此回答开发商自己是否有长期明确的技术路线。如果公司已经有技术路线规划和长期的产品规划，则应当考虑移植能力，以保证当软件所遵循的标准或技术路线改变时自己和客户的投入成本不受到大的损失。

如何记录非功能性需求

前面已经讲过，非功能性需求不适合记录在用例规约里。在RUP里提供了两份模板可以用来记录非功能性需求。一份是用例补充规约，另一份是软件需求规约。用例补充规约是专门为某个用例服务的，如果某个非功能性需求只只该用例有关，例如仅有某个用例需要特别的安全性，那么可以写在用例补充规约里。软件需求规约是针对整个软件的，所以如果非功能性需求是针对整体软件的，就应当写在软件需求规约文档里。

不过，笔者建议将这两个文档合并。因为在实践中，非功能性需求仅仅针对某个用例的情况是不多见的。并且文档过多和信息过于分散会增加项目管理的难度。因此可以将所有的非功能性需求都写到同一份文档里，既便于管理，也容易阅读。

7 -- 类图

类图

类图用于展示系统中的类及其相互之间的关系。

本质上说，类图是现实世界问题领域的抽象对象的结构化、概念化、逻辑化描述。在开始本节之前请读者回顾一下，在1.1.2面向过程的困难一节中，我们曾经谈到过面向对象的困难；而在1.2.7面向对象的困难解决了吗一节中又谈到了面向对象困难的解决。实际上，UML解决面向对象困难的方法源于面向对象方法中对类理解的三个层次观点，这三个层次是概念层、说明层和实现层。在UML中，从开始的需求到最终的设计类，类图也是围绕着这三个层次的观点来进行建模的。类图建模是先概念层而说明层，进而实现层这样一个随着抽象层次的逐步降低而逐步细化的过程。

概念层类图

概念层的观点认为，在这个层次的类图描述的是现实世界中问题领域的概念理解，类图中表达的类与现实世界的问题领域有着明显的对应关系，类之间的关系也与问题领域中实际事物的关系有着明显的对应关系。需要注意的是，概念层类图中的类和类关系和最终的实现类并不一定有直接和明显的对应关系。在概念层上，类图着重于对问题领域的概念化理解，而不是实现，因此类名称通常都是问题领域中实际事物的名称。概念层的类图是独立于实现语言和实现观点的。

回顾图1.9，概念层类图位于业务建模阶段。通常在这个阶段类图是以领域模型图，即业务实体图来表示的。图4.7展示了网上购物的业务实体图，这个类图表达了概念层的类观点。说明在问题领域中，网上购物主要由商品、定单、支付卡这几个关键类构成，这几个类的交互能够完成网上购物这个业务目标。

图4.7概念层类图

说明层类图

说明层的观点认为，在这个层次的类图考察的是类的接口而不是实现，类图中表达的类和类关系应当是对问题领域在接口抽象层次的描述。也就是说，这时候我们不必关心类最终是用什么语言编码的、是用什么设计模式设计的、是遵循什么标准的，我们所关心的只是这样一些类，它们通过接口进行交互，进而完成了问题领域中的业务目标。

说明层类图是搭建在现实世界和最终实现之间的一座桥梁。在这个阶段，类通常都非常粗略，虽然它表达了计算机的观点，但是在描述上却采用了近似现实世界的语言，以保证从现实世界到代码实现的过渡。

回顾图1.9，说明层类图位于概念模型阶段。在这个阶段，类图是以分析类和分析模型图来表示的。4.8展示了网上购物的分析类图，这个类图表达了从计算机的观点来说，网上购物这个业务目标是由哪些类来完成的，这些类的接口保证了这个业务目标的达成。