使用UML对系统进行建模-Read.docVIP

使用UML对系统进行建模 面向对象的软件工程，同传统的面向过程的软件工程相比，在需求的获取、系统分析、设计和实现方面都有着很大的区别。UML是OOA和OOD的常用工具。使用UML来构建软件的面向对象的软件工程的过程，就是一个对系统进行不断精化的建模的过程。这些模型包括用例模型、分析模型、设计模型，然后，我们需要使用具体的计算机语言来建立系统的实现模型。当然，在整个软件工程中，我们还需要建立系统的测试模型，以保证软件产品的质量。 使用面向对象的工具来构建系统，就应该使用面向对象的软件工程方法。然我，我们经常会发现，在实际的开发过程中，很多开发人员虽然能够理解UML的所有图形，却仍然不能得心应手的使用UML来构建整个项目，其很大的原因，是仍然在使用原有的软件工程方法，而不清楚如何使用UML来建立系统的这些模型，不清楚分析和设计的区别，以及他们之间的转化。 应用软件系统，就其本质来说，是使用计算机对现实世界进行的数字化模拟。应用软件的制造过程，按照UML的方法，就是建立这一些列模型的过程。本文将就一个图书馆系统，说明如何使用UML来对系统进行这一系列的建模。 关于这个图书馆系统，基本的需求比较简单，就是允许学生可以在图书馆借阅和归还图书，另外，也可以通过网络或者图书馆的终端来查阅和预订书。当然，图书馆管理员也可以对图书进行管理。为了简化系统，我们没有把图书馆中的人员作细分。 之所以采用这个相对简单案例，是因为很多人都对图书馆系统有很强的感性认识，这样，读者不需要花很多的时间来理解系统包含的业务知识。同时，也因为本文只是对使用UML的过程做一个探讨，着眼于使用UML进行建模的过程，说明各个层次的模型之间的区别和联系，展示系统演进的过程，而不会深入UML的细节方面。对于更加复杂的系统，其分析和设计的方法是相通的，可以举一反三。 用例模型——系统需求的获取 用例模型定义系统做什么，是用来获取系统需求的有效手段。用例模型由“角色”和“用例”组成。我们在构建一个用例的时候，通常要做的第一件事情是识别角色，或者说，参与者。然后我们我们需要识别系统为参与者提供的服务，或者说，参与者的行为，也就是用例。最后，我们确定角色和用例之间的关系。在这个图书馆系统中，我们可以识别出的角色有学生和图书管理员。整个用例模型包含的用例有：借书、还书、查阅图书、预订图书，以及图书维护。用例模型可以用用例图表示如下： 确定有效用例的关键是，检查用例是否包含了一个完整的功能。用例不能定的过细，不能把一个完整的功能的一个部分作为一个用例，也不能在一个用例中包含过多的功能。例如，用户的登录。学生在预定图书的时候，可能会需要首先登录系统，这是系统的一个功能。但是，这个功能只是预定图书这个完整的功能中的一个步骤，或者说一个子功能，就不适于做成一个用例。另一方面，借书和还书，都是相对完整的功能，如果把这两个用例合并成一个类似于“处理图书”的用例，显然是不能明确的表达用例需要表达的含义的。 描述用例 需要了解的是，使用UML进行系统建模，并非只是意味着画UML图形，对UML图的文档说明是同样重要的。学习UML，不仅仅要学习UML图形，相应的文档描述方法也同样要学习，也同样重要。 在描述用例时，我们可以用文字来描述，也可以用其他图形来描述，例如，顺序图或者活动图等等。下面给出了一个RUP中推荐的描述用例的完整的结构： 名称。名称无疑应该表明用户的意图或用例的用途，如“研究班招生”。 标识符 [可选]。唯一标识符，如 UC1701，在项目的其他元素（如类模型）中可用它来引用这个用例。 说明。概述用例的几句话。 参与者 [可选]。与此用例相关的参与者列表。尽管这则信息包含在用例本身中，但在没有用例图时，它有助于增加对该用例的理解。 状态 [可选]。指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查。 频率。参与者访问此用例的频率。这是一个自由式问题，如用户每次录访问一次或每月一次。 前置条件。一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足。 后置条件。一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足。 被扩展的用例 [可选]。此用例所扩展的用例（如果存在）。扩展关联是一种广义关系，其中扩展用例接续基用例的行为。这是通过扩展用例向基用例的操作序列中插入附加的操作序列来实现的。这总是使用带有 extend 的用例关联来建模的。 被包含的用例 [可选]。此用例所包含用例的列表。包含关联是一种广义关系，它表明对处于另一个用例之中的用例所描述的行为的包含关系。这总是使用带有 include 的用例关联来建模的。也称为使用或具有 (has-a) 关系。 假设 [可选]。对编写此用例时所创建的域的任何重要假设。您应