《UML的面向51 如析与爲十》由会员分享，可在线阅读，更多相关《UML的面向51 如析与爲十（8页珍藏版）》请在金锄头文库上搜索。
1、UML的面向51 如析与爲十摘要本文以实例的方式，展示了如何使用UML进行面向对彖的分析与设计。本文将假设读者对UM L、面向对彖等领域的基本内容C了然丁胸，所以将不会过多阐述，而将重点放在应用过程上。本文 的U的是逋过一个完整的实例，展现基于UML的OOA&D过程的一个简化模式，帮助刖友们更好的 认识UML在OOA&D中起的作用。经常听到有朋友抱怨，说学了 UML不知该怎么用，或者i出j了 UML却觉得没什么作用。其实， 就UML本身來说，它只是一种交流工具，它作为-种标准化交流符号，在OOA&D过程中开发人员 间甚至开发人员与客八之间传递信息。另外，UML也可以看做是OO思想的一种表现形式
2、，可以说7 0是神，而UML是型蔦 所以，想用好UML,扎实的00思想基础是必不可少的。然而，在UML 应用到开发过程中时，还是有一定的模式可以遵循的。（注意，是模式而不是教条，我下面给出的流 程貝是一个启发式过程，而不是说一泄要遵循这个流程。）下面，我们通过一个CMS系统的分析设 计实例，看看如何将UML应用到实际的开发中。从需求到业务用例图OOA&D的第一步，就是了解用户需求，并将其转换为业务用例图。我们的CMS系统需求非常 简单，大致课做如下描述：这个系统主要用来发布新闻，管理员只需要-个，登录后可以在后台发布 新闻。任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论
3、。管理员在后 台可以对新闻、评论、注册会员进彳亍管理，如修改、删除等。通过以上需求描述，我们闽出如下的业务用例图:这里要注总三点：1. 业务用例是仅从系统业务角度关注的用例,而不是具体系统的用例。它描述的是该实现什么业 务”,而不是“系统该提供什么操作例如，在实际系统中,“登录肯定要作为i个用例.但是这是软 件系统中的操作,询用八所关注的业务是不包含“登求的。2. 业务用例仪包含客八“感兴趣“的内容。3. 业务用例所有的用例幺应该让客八能看懂，如果某个用例的名宁客八看不懂什么总思，它也许 就不适合作为业务用例。从业务用例图到活动图完成了业务用例图后，我们要为每-个业务用例绘制幅活动图。活动图描
4、述了这个业务用例中, 用八可能会进行的操作序列活动图有个很匝要的使命：从业务用例分析出系统用例。例如，下面是“新闻管理的活动图:可以看到，一个“新闻管理”这个业务用例，分解出N多系统操作。这里要特别注意这些操作，其 中很多“活动都很可能是一个系统用例（当然,不是每个都是）。例如，由这个活动图可以看出,系 统中至少要包含以下备选系统用例：登录、注销登录、查看新闻列表、修改新闻、删除新闻。这样，将每个业务用例都绘制出相应的活动图,再将其中的“活动整合，就得出所有备选系统用 例。从活动图到系统用例图找出所冇的备选系统川例后，我们要対他们进行合并和筛选。合并就是将相同的川例合并成个, 筛选就是将不符合
5、系统用例条件的备选用例去掉。-个系统用例应该是实际使用系统的用八所进行的 个操作，例如，“査看新闻列表”就不能算一个系 统用例，因为他只是某系统用例的一个序列项。a终我们得岀的系统用例图如下:从系统用例图到用例规约得出系统用例图后，我们应该对每个系统用例给出用例规约。关丁用例规约，没有个通用的 格式，大家可以按照习惯的格式进行编写。对用例规约唯的要求就是“活晰易懂。下ihi给岀“背录这个系统用例的个规约:用例名称3登录系统卩用例简述2用户登录CMS系统心用例图Q用户主要流程31）用户输入用户名和密码42）选择用户类型23）点击登录按钮卩替代流程23a）“用户名或密码错误”，系统出现用户名或密码
6、错误的提示信息，回到主要流程1，由用户重新输入d3b）“输入的用户名与类型不符”，系统出现提示信息，回到主要流程1，由用户重新输入23b）当用户点击取消按钮时，取消登录Q业务领域类图完成了上面儿步，下面应该是绘制业务领域类图了。所谓业务领域类图要描述下三点:1. 系统中有哪些实体。2. 这些实休能做什么操作。3. 实体间的关系。这里要特别强调：这里的实体不是Actor,而是Actor使用系统时使用的所调用的实体，是处在系 统边界之内的实体。例如，管理员就没有作为一个实体出现在这里，因为管理员处在系统边界之外, 它所有的工作都可以通过调用这三个类的方法完成。并且，这里的注册会员实体也不是刚才用例
7、图 中注册会员这个Actor,而是作为一个系统内的业务实体，供Actor们使用的。例如，其中的注册 功能是给注册会员这个Actor使用，而移除则是给管理员这个Actor使用的。理解以上这段话非常重要，我经常看到山丁混淆了实体和Actor的关系而导致画出的领域类图不 准确或职责分配不准确。大家可能还注意到，我们这里没有给出每个实体的属性。其实，在领域分析阶段，实体的属性并 不垂要，匝要的是找出实体的操作。实现类图以上这儿步，就是分析的过程。而下面的步骤就是设计了。设计没有分析那么好描述，因为分析是“客户面”，它只关心系统本身的功能和业务，而不关心任 何和计算机有关的东西。但是，设计和平台、语言、
8、开发模型等内容关系紧密，因而很难找出一个一 致的过程。但是，一般在设计过程中实现类图是要绘制的。实现类图和领域类图不一样，它描述的是真止系统的静态结构,是和最后的代码完全一致的。闵 此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、接口等元索以及其中的关 系。因此，实现类图是很复杂的，而且是平台技术有关的。所以，我在这里不可能给出一个准确的实 现类图，不过为了描述，我还是给出一个简化了的实现类图，当然，它是不准确的，而只是从形式上 给出实现类图的样子。我们假设这个系统建构T-.NET 3.5平台上，并且使用ASP.NET MVC作为表示层，整体使用三 层架构。那么，用户模块体系
9、的实现类图人体是这样子（不准确）：A序列图有了静态结构，我们还要给出动态结构，这样，才能看清系统间的类是如何交互的，从而有效帮 助程序员进行编码工作。1 : Login():UserController:UserServices:UserDAL上图给出的是用户登录的序列图。首先注册会员作为Actor,调用UscrControllcr的Login方法 启动序列，然后序列按图示步骤执行。其! UserServices作为业务纽件，首先调用数据访问组件的G etByName确圧用八是否存在，如果存在，再调用GetByNameAndPassword确定输入密码是否是此 用户的密码。从而完成业务功能。要注意，序列图在实际中是很多的，儿乎每个类力法都配有相应的序列图。最后的步骤在完成了上面的过程后，就可以进行编码、调试.测试等工作了。但这些已经超出了本文讨论的范围。总结本文简要给出了使用UML进行OOA&D的过程。当然，山于示例较小，而且本人水平有限，所 以给出的相关内容可能不是很准确。而H.软件分析设计本來就不是-个尚定模式的过程，随着系统的 不同整个过程会有变化。本文只是想起到一个抛砖引玉的作用，让朋友们大致了解UML的使用流程。 至于实际的分析设计,还需要深入的学习和实践的积累。
