三位“盟友”James Rumbaugh、Grady Booch和Ivar Jacobson在1995年创建了UML,将他们各自的方法(OMT、Booch开发方法和OOSE)融合成一个整体。在1997年,OMG组织将UML用作实际的公开标准。
在很大程度上,UML是一种图形语言,用来描述、记录、设计和构造解决方案。UML的强大作用体现在:为用户、开发人员、分析师、客户和软件开发过程中的其他股东提供了一种公共语言,使所有成员可以理解并由此进行交流。进一步讲,UML独立于编程语言,故使用面广,采用这种语言时,开发团队不需要在分析、描述和同意要求、工作流和约束前作出技术决策。
这些模型有一个共同点,要设计和描述软件解决方案,单个模型无法满足要求。任何一个模型都不足以描述问题或设计解决方案,总需要一组模型。UML新手经常会提这样一个问题,该使用哪种模型?对于这个问题,实在给不出明确的答案,因为这取决于解决方案的复杂性,以及股东的特点。如果解决方案的问题简单明了,例如构建的一个软件解决方案显示一个Web 页(ASP),描述有关小卖部开张时间的信息,而另一个解决方案计算所有个人或单位的年纳税额,则前者的模型肯定没有后者多,也不如后者详细。本书的案例研究将讨论在什么时候使用什么模型。凭经验判断,模型的数量和明细级别应达到所有股东能够处理解决方案的程度。
UML中包含的模型,分为三类:功能、行为和实现。功能类别模型用来收集要求和描述功能。行为类别模型用于描述解决方案的对象和用户的行为。实现类别模型用于解决方案功能和行为的物理实现。
功能: 用例图、类图
行为:交互图(顺序图和协作图)、状态图、活动图
实现:、组件图、部署图
一、功能图
功能图构建解决方案功能的模型。换言之,如果要弄清解决方案能做什么,则查看功能图。功能图是用例图和类图。查看这些图,将准确了解解决方案的作用及开发方式。顺序图也显示功能,但将顺序图归入行为类别,因为它们的面向行为特性更明显。
1. 用例图
一般首先构建用例图,该图用来收集用户要求。用例图是从用户角度查看的解决方案。应该使用用户能够理解的语言讨论解决方案。在这一阶段,不应提及触发器和数据库约束等。用例模型由行动者和用例,及它们之间的关系组成。
行动者(actor)指与系统交互的某人或某事。行动者要么从解决方案接收信息,要么将信息传给系统。行动者的图形是一个人形。行动者经常表示人(如用户),也表示另一个IT系统。例如,企业资源规划(Enterprise Resource Planning,简写ERP)系统可从电子商务解决方案接收数据,换言之,ERP系统是电子商务解决方案的一个行动者。人员行动者的例子如从自动取款机(ATM)取钱的客户。此处的客户是一个与ATM系统相关的行动者。
用例是一个过程,其表示符号是一个椭圆
2. 类图
类图用于收集要求阶段。它提出问题,如可能发生什么,并验证系统确能完成要求。一般从项目团队和开发人员的角度查看类图。
在类图中,绘制逻辑和物理实体,以及解决方案中对象的关系。换言之,构建用例图中识别的类的模型。本例的候选对象包括Customer和Order。故在类图中构建Customer类和Order类的模型。这些可能是传统的面向对象的类,也可能是诸如ASP页、数据库表或COM+组件的非面向对象的类。
UML类的表示符号是一个矩形,如图3-6所示。由图可知,该类有一些属性(CustomerID和Date等)和一些方法(New、PlaceOrder和Delete)。
在类图中,类相互之间具有关系。例如,Customer可将若干个Order放入系统。类之间的关系用实线表示,如图3-7所示。
二、 行为图
行为图描述解决方案的行为或交互。此类图构建解决方案中发生的事情。只有了解这些内容才能开发解决方案。
1. 交互图
UML有两类交互图:顺序图和协作图。这两种图之间的区别在于:顺序图基于时间,按时间顺序显示出现的任务;而协作图显示任务和信息(对象)的交互方式。在协作图中,时间以编码形式显示,很难选取。虽然存在这些根本区别,但这两类图有相同之处:都用于显示对象和用户如何交互以执行任务。
对UML新手而言,很难记住该使用哪一种交互图。幸运的是,可以用一个简单方法来解决这个问题。可从图的名称中加以判断。顺序图描述如何按时间顺序执行交互。协作图显示信息和任务的交互方式,不过分强调时间。有时要同时使用这两种类型,但在构建交互模型时,要使用一些策略:
if 基于时间 then
顺序图
else (注重于组织方面)
协作图
end if
2. 状态图
在设计面向对象的解决方案中,用状态图来显示对象的生命期。
用实框符号表示状态,实线箭头表示转换。另外,实心圈指示起点,实心圈外加一个空圈表示终点。
注意:
状态图只用来显示对象的各种可能状态,以及如何从一个状态转换到另一个状态。换言之,对象的生命期用状态图来表示。
3. 活动图
初看起来,活动图很难理解。但是,活动图只是描述工作流以及谁完成工作的方式,与流行的数据流程图类似。实际上,可将活动图视为数据流程图。
活动图使用的符号与状态图使用的符号相近。在活动图中,用拉长的椭圆表示活动,用圆角框表示状态。顾名思义,“活动”是执行的动作,如验证订单(validate order)。“状态”表示对象的可能状态;例如,在验证订单后,订单进入Validated Order(已验证订单)状态。活动图的有趣部分是泳道(swimlane),由竖线表示。使用泳道,可大体了解系统中的各个行动者/部门,以及它们执行的任务。如果有过多行动者参与,或在泳道间频繁切换,则可能导致错误或延迟,通过活动图,可发现这些问题。此分析有助于优化业务过程。
通过活动图,可概览系统和工作流程;有时,活动图也用于过程建模。
三、 实现图
实现图描述如何打包和实现解决方案。这非常有助于实现和恢复解决方案。
1. 组件图
顾名思义,组件图指在解决方案中构建实际物理组件模型的方式。组件图可显示源代码组件、COM+组件及其他二进制和可执行组件。组件图还显示组件接口。
接口是组件间的通信方式。例如,小汽车的接口是仪表板和踏板。可通过“接口”与小汽车通信。Order组件可包含一个方法来取消订单,接口指定执行这个操作需要订单ID;换言之,要使Order对象删除订单,必须为要删除的订单传输订单ID。
组件图用来设计解决方案
2. 部署图
部署图显示解决方案的部署方式,由处理器、设备和连接器构成。“处理器”是可执行组件的硬件项。“设备”是不具备执行组件能力的硬件设备,如调制解调器和打印机。“连接器”是处理器和设备之间的关系。
部署图用来描述组件运行在哪些物理计算机上,以及解决方案如何与硬件交互。通过部署图,还可指定解决方案中各个节点类型的数目。
符号是一个显示物理部分的箱。
类之间的关系
UML把类之间的关系分为以下5种.
● 关联:类A与类B的实例之间存在特定的对应关系
● 依赖:类A访问类B提供的服务
● 聚集:类A为整体类,类B为局部类,类A的对象由类B的对象组合而成
● 泛化:类A继承类B
● 实现:类A实现了B接口
关联(Association)
关联指的是类之间的特定对应关系,在UML中用带实线的箭头表示。按照类之间的数量对比,关联
可以分为以下三种:
● 一对一关联
● 一对多关联
● 多对多关联
注意:关联还要以分为单向关联和双向关联
依赖(Dependency)
依赖指的是类之间的调用关系,在UML中用带虚线的箭头表示。如果类A访问类B的属性或者方法,
或者类A负责实例化类B,那么可以说类A依赖类B。和关联关系不同,无须在类A中定义类B类型的属性。
聚集(Aggregation)
聚集指的是整体与部分之间的关系,在UML中用带实线的菱形箭头表示。
聚集关系还可以分为两种类型:
● 被聚集的子系统允许被拆卸和替换,这是普通聚集关系。
● 被聚集的子系统不允许被拆卸和替换,这种聚集称为强聚集关系,或者组成关系。
注:强聚集(组成)可用带实线的实心菱形箭头表示。
泛化(Generalization)
泛化指的是类之间的继承关系,在UML中用带实线的三角形箭头表示。
实现(Realization)
实现指的是类与接口之间的关系,在UML中用带虚线的三角形箭头表示。
以下是GOF设计模式中的描述:
箭头和三角表示子类关系。
虚箭头线表示一个类实例化另一个类的对象,箭头指向被实例化的对象的类。
普通的箭头线表示相识(acquaintance也叫关联或者引用),意味着一个对象仅仅知道另一个对象。相识的对象可能请求彼此的操作,但他们不为对方负责,它只标示了对象间较松散的耦合关系。
尾部带有菱形的箭头线表示聚合(aggregation),意味着一个对象拥有另一个对象或者对另一个对象负责。一般我们称一个对象包含另一个对象,或者是另一个对象的一部分。聚合意味着聚合对象和其所有者具有相同的生命周期。
抽象类名以斜体表示,抽象操作也以斜体表示。图中可以包括实现操作的伪代码,代码将出现在带有褶角的框中,并用虚线将该褶角框与代码所实现的操作相连。
简单说明
Package
包。用来聚集和组织模型中的一个部分(Use Case,类,等等)。
Actor
参与者。它代表一个用户或者其他外部的激励器。
Use Case
用例。Use Case描述了系统某一部分的行为。一般地,Use Case记录对某个系统功能的需求,而这个功能由对动作或者事件的应答示范。
<> Relationship
包含关系。标注为<>关系的Use Case关系能够引入其他Use Case的功能。这是一种方便的分割Use Case、避免单个Use Case过于庞大的方法。
<> Relationship
扩充关系。标注为<>关系的Use Case关系能够在不重复现有Use Case的各种描述和需求的情况下,使现有Use Case的行为特殊化。
Dependency
依赖。正如其字面意义,它表示一个事物依赖另一个事物。这意味着一个事物了解另一个事物,并需要另外一个事物才能发挥功能。
Note
注解。在UML图中提供注解的目的是以简短的说明阐明图表的内容。
Component
构件。构件一般代表一个软件单元,它可能是一个DLL、一个执行文件,或者是一个数据库。
Node
节点。节点一般代表一台机器,这台机器具有运行一个或者多个系统构件的能力。
Class
类。UML中的类与面向对象编程中的类一样,即它定义并封装了一组行为和属性。类在运行时被实例化从而创建出对象。
Object
对象。对象是类的实例。例如,“MyClass myObj = new MyClass; ”创建了一个myObj对象。
![](https://img2024.cnblogs.com/blog/35695/202408/35695-20240814092323678-2007548550.jpg)