UML符号.doc

3.5 UML符号 本节将介绍UML符号以及UML的构建方式。可将本节视为UML语言的简介。第4、5章将详细介绍UML、UML符号和各种模型。 从高级观点看，UML模型由用来描述和设计软件解决方案各个部分的一组模型组成。一些模型用于软件设计的早期阶段，例如项目团队成员在采访用户以获得用户要求和期望时；其他模型用于描述物理软件组件，由开发人员使用。 这些模型有一个共同点，要设计和描述软件解决方案，单个模型无法满足要求。任何一个模型都不足以描述问题或设计解决方案，总需要一组模型。UML新手经常会提这样一个问题，该使用哪种模型？对于这个问题，实在给不出明确的答案，因为这取决于解决方案的复杂性，以及股东的特点。如果解决方案的问题简单明了，例如构建的一个软件解决方案显示一个Web 页(ASP)，描述有关小卖部开张时间的信息，而另一个解决方案计算所有个人或单位的年纳税额，则前者的模型肯定没有后者多，也不如后者详细。本书的案例研究将讨论在什么时候使用什么模型。凭经验判断，模型的数量和明细级别应达到所有股东能够处理解决方案的程度。 表3-1列出了UML中包含的模型。分为三类：功能、行为和实现。功能类别模型用来收集要求和描述功能。行为类别模型用于描述解决方案的对象和用户的行为。实现类别模型用于解决方案功能和行为的物理实现。 表3-1 UML模型 类 别 模 型 功能 用例图 类图 行为 交互图：顺序图和协作图 状态图 活动图 实现 组件图 部署图 下一节将详细描述这些模型。 3.5.1 功能图 功能图构建解决方案功能的模型。换言之，如果要弄清解决方案能做什么，则查看功能图。功能图是用例图和类图。查看这些图，将准确了解解决方案的作用及开发方式。顺序图也显示功能，但将顺序图归入行为类别，因为它们的面向行为特性更明显。 1. 用例图 一般首先构建用例图，该图用来收集用户要求。用例图是从用户角度查看的解决方案。应该使用用户能够理解的语言讨论解决方案。在这一阶段，不应提及触发器和数据库约束等。用例模型由行动者和用例，及它们之间的关系组成。 行动者(actor)指与系统交互的某人或某事。行动者要么从解决方案接收信息，要么将信息传给系统。行动者的图形是一个人形，如图3-3所示。行动者经常表示人(如用户)，也表示另一个IT系统。例如，企业资源规划(Enterprise Resource Planning，简写ERP)系统可从电子商务解决方案接收数据，换言之，ERP系统是电子商务解决方案的一个行动者。人员行动者的例子如从自动取款机(ATM)取钱的客户。此处的客户是一个与ATM系统相关的行动者。 图3-3 行动者 用例是一个过程，其表示符号是一个椭圆，如图3-4所示。在本例中，用例是订购过程(Place Order)。该用例包括执行订购的一系列任务。 图3-4 过程 图3-5是一个非常简单的用例图例子。在此图，已在行动者(theCustomer)和用例之间添加了关系，指示客户与过程交互；客户通过订购来启动过程。这可通过单击电子商务解决方案的Buy按钮来进行。 图3-5 简单的用例图 2. 类图 类图用于收集要求阶段。它提出问题，如可能发生什么，并验证系统确能完成要求。一般从项目团队和开发人员的角度查看类图。 在类图中，绘制逻辑和物理实体，以及解决方案中对象的关系。换言之，构建用例图中识别的类的模型。本例的候选对象包括Customer和Order。故在类图中构建Customer类和Order类的模型。这些可能是传统的面向对象的类，也可能是诸如ASP页、数据库表或COM+组件的非面向对象的类。 UML类的表示符号是一个矩形，如图3-6所示。由图可知，该类有一些属性(CustomerID和Date等)和一些方法(New、PlaceOrder和Delete)。 图3-6 UML类 在类图中，类相互之间具有关系。例如，Customer可将若干个Order放入系统。类之间的关系用实线表示，如图3-7所示。 图3-7 一个简单类图 3.5.2 行为图 行为图描述解决方案的行为或交互。此类图构建解决方案中发生的事情。只有了解这些内容才能开发解决方案。 1. 交互图 UML有两类交互图：顺序图和协作图。这两种图之间的区别在于：顺序图基于时间，按时间顺序显示出现的任务；而协作图显示任务和信息(对象)的交互方式。在协作图中，时间以编码形式显示，很难选取。虽然存在这些根本区别，但这两类图有相同之处：都用于显示对象和用户如何交互以执行任务。 图3-8是一个顺序图，指示客户订购执行的交互。注意，另添加了一个对象。在订购时，客户必须首先将商品放在购物篮中。此处可看到，行动者是一个人形，对象是实线框。执行的交互或任务显示为实线，箭头指示交