logo资料库

基于UML的面向对象分析与设计案例.doc

发布时间：2022-06-09 发布人：admin 分类：说明书 资料大小：0.24M 资料格式：doc 举报 版权申诉
第1页 / 共6页
第2页 / 共6页
第3页 / 共6页
第4页 / 共6页
第5页 / 共6页
第6页 / 共6页
资料共6页，全文预览结束
    基于UML的面向对象分析与设计案例
    基于 UML 的面向对象分析与设计案例 摘要 本文以实例的方式，展示了如何使用 UML 进行面向对象的分析与设计。本文将 假设读者对 UML、面向对象等领域的基本内容已了然于胸，所以将不会过多阐述，而将重点 放在应用过程上。本文的目的是通过一个完整的实例，展现基于 UML 的 OOA&D 过程的一个简 化模式，帮助朋友们更好的认识 UML 在 OOA&D 中起的作用。 前言 经常听到有朋友抱怨，说学了 UML 不知该怎么用，或者画了 UML 却觉得没什么 作用。其实，就 UML 本身来说，它只是一种交流工具，它作为一种标准化交流符号，在 OOA &D 过程中开发人员间甚至开发人员与客户之间传递信息。另外，UML 也可以看做是 OO 思想 的一种表现形式，可以说“OO 是神，而 UML 是型”。所以，想用好 UML，扎实的 OO 思想基 础是必不可少的。然而，在 UML 应用到开发过程中时，还是有一定的模式可以遵循的。（注 意，是模式而不是教条，我下面给出的流程只是一个启发式过程，而不是说一定要遵循这个 流程。）下面，我们通过一个 CMS 系统的分析设计实例，看看如何将 UML 应用到实际的开发 中。 1.从需求到业务用例图 OOA&D 的第一步，就是了解用户需求，并将其转换为业务用例图。我们的 CMS 系统需求非常简单，大致课做如下描述：这个系统主要用来发布新闻，管理员只需要一个， 登录后可以在后台发布新闻。任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后 可对新闻进行评论。管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。 通过以上需求描述，我们画出如下的业务用例图： 这里要注意三点： 1.业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。它描述 的是“该实现什么业务”，而不是“系统该提供什么操作”。例如，在实际系统中，“登录”
    肯定要作为一个用例，但是这是软件系统中的操作，而用户所关注的业务是不包含“登录” 的。 2.业务用例仅包含客户“感兴趣”的内容。 3.业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂 什么意思，它也许就不适合作为业务用例。 2.从业务用例图到活动图 完成了业务用例图后，我们要为每一个业务用例绘制一幅活动图。活动图描述 了这个业务用例中，用户可能会进行的操作序列。活动图有个很重要的使命：从业务用例分 析出系统用例。例如，下面是“新闻管理”的活动图： 可以看到，一个“新闻管理”这个业务用例，分解出 N 多系统操作。这里要特 别注意这些操作，其中很多“活动”都很可能是一个系统用例（当然，不是每个都是）。例 如，由这个活动图可以看出，系统中至少要包含以下备选系统用例：登录、注销登录、查看 新闻列表、修改新闻、删除新闻。 这样，将每个业务用例都绘制出相应的活动图，再将其中的“活动”整合，就 得出所有备选系统用例。 3.从活动图到系统用例图 找出所有的备选系统用例后，我们要对他们进行合并和筛选。合并就是将相同 的用例合并成一个，筛选就是将不符合系统用例条件的备选用例去掉。 一个系统用例应该是实际使用系统的用户所进行的一个操作，例如，“查看新 闻列表”就不能算一个系统用例，因为他只是某系统用例的一个序列项。
    最终我们得出的系统用例图如下： 4.从系统用例图到用例规约 得出系统用例图后，我们应该对每一个系统用例给出用例规约。关于用例规约， 没有一个通用的格式，大家可以按照习惯的格式进行编写。对用例规约唯一的要求就是“清 晰易懂”。 下面给出“登录”这个系统用例的一个规约： 5.绘制业务领域类图 完成了上面几步，下面应该是绘制业务领域类图了。所谓业务领域类图要描述 一下三点：
    1.系统中有哪些实体。 2.这些实体能做什么操作。 3.实体间的关系。 这里要特别强调：这里的实体不是 Actor，而是 Actor 使用系统时使用的所调 用的实体，是处在系统边界之内的实体。例如，管理员就没有作为一个实体出现在这里， 因为管理员处在系统边界之外，它所有的工作都可以通过调用这三个类的方法完成。并且， 这里的“注册会员”实体也不是刚才用例图中注册会员这个 Actor，而是作为一个系统内的 业务实体，供 Actor 们使用的。例如，其中的注册功能是给注册会员这个 Actor 使用，而 移除则是给管理员这个 Actor 使用的。 理解以上这段话非常重要，我经常看到由于混淆了实体和 Actor 的关系而导致 画出的领域类图不准确或职责分配不准确。 大家可能还注意到，我们这里没有给出每个实体的属性。其实，在领域分析阶 段，实体的属性并不重要，重要的是找出实体的操作。 6.绘制实现类图 以上这几步，就是分析的过程。而下面的步骤就是设计了。 设计没有分析那么好描述，因为分析是“客户面”，它只关心系统本身的功能 和业务，而不关心任何和计算机有关的东西。但是，设计和平台、语言、开发模型等内容关 系紧密，因而很难找出一个一致的过程。但是，一般在设计过程中实现类图是要绘制的。 实现类图和领域类图不一样，它描述的是真正系统的静态结构，是和最后的代 码完全一致的。因此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、 接口等元素以及其中的关系。因此，实现类图是很复杂的，而且是平台技术有关的。所以， 我在这里不可能给出一个准确的实现类图，不过为了描述，我还是给出一个简化了的实现类 图，当然，它是不准确的，而只是从形式上给出实现类图的样子。 我们假设这个系统建构于.NET 3.5 平台上，并且使用 ASP.NET MVC 作为表示层，
    整体使用三层架构。那么，用户模块体系的实现类图大体是这样子（不准确）： 7.绘制序列图 有了静态结构，我们还要给出动态结构，这样，才能看清系统间的类是如何交 互的，从而有效帮助程序员进行编码工作。
    上图给出的是用户登录的序列图。首先注册会员作为 Actor，调用 UserContro ller 的 Login 方法启动序列，然后序列按图示步骤执行。其中 UserServices 作为业务组件， 首先调用数据访问组件的 GetByName 确定用户是否存在，如果存在，再调用 GetByNameAndP assword 确定输入密码是否是此用户的密码。从而完成业务功能。 要注意，序列图在实际中是很多的，几乎每个类方法都配有相应的序列图。 8.后面的步骤 在完成了上面的过程后，就可以进行编码、调试、测试等工作了。但这些已经 超出了本文讨论的范围。 总结 本文简要给出了使用 UML 进行 OOA&D 的过程。当然，由于示例较小，而且本人 水平有限，所以给出的相关内容可能不是很准确。而且软件分析设计本来就不是一个固定模 式的过程，随着系统的不同整个过程会有变化。本文只是想起到一个抛砖引玉的作用，让朋 友们大致了解 UML 的使用流程。至于实际的分析设计，还需要深入的学习和实践的积累。
    分享到：
    赞 收藏

    相关推荐

    资料库

    课程资源

    共收录17145份资料，累计13个分类，关注成员有19位，主要包括：PHP,网络管理,网页制作,Java,.Net,数据库,3G/移动开发,C/C++,游戏开发,嵌入式,讲义,软件测试,专业指导

    热门标签

    PHP 网络管理 网页制作 Java .Net 数据库 3G/移动开发 C/C++ 游戏开发 嵌入式 讲义 软件测试 专业指导

    最新资料