商业管理软件的建模语言UML

统一建模语言UML(UnifiedModelingLanguage)是一种定义良好、易于表达、功能强大且普遍适用的、用于构建商业管理软件和文档的可视化建模语言。UML是一个标准的图形表示法，是建立系统模型的一种语言，其本身不能被编译、执行，属于系统分析工具。但支持UML语言的工具软件可以提供从UML到各种编程语言的代码生成，也可以通过现有程序逆向构建UML模型。

一个UML模型主要由构造块、语义规则和公共机制三部分组成，如图9—1所示。构造块，就是建模元素，是模型的主体；语义规则，是支配构造块如何放在一起的规则；公共机制，是运用于整个UML模型中的公共机制、扩展机制。

一、构造块
构造块有三种：事物(Things)、关系(Relationships)和图(Diagrams)。
(1)事物：是模型中最静态的部分，代表概念上或物理上的建模元素，又可分为结构事物(类、接口、协作、用例、组件、活动类、节点)、动作事物(交互、状态机)、分组事物(包)和注释事物。
(2)关系：是系统中各事物之间有意义的联系，是将事物紧密组合在一起的纽带，分为关联、依赖、泛化、实现4种类型。
(3)图：是相关事物通过它们之间的关系形成的组，是事物与关系的表现形式，包括类图、对象图、用例图、顺序图、协作图、状态图、活动图、组件图、部署图9种。

二、语义规则
语义规则就是如何将图正确地描述出来的一些约束，相当于UML语言的语法。
(1)命名：如何为事物、关系和图命名。
(2)范围：与类的作用域相似，包括所有者作用域(OVcD_eEScope)和目标作用域(TargetScope)。
(3)可见性：如何让其他人使用或者看见，有public、protected、private等。
(4)完整性：相互联系的事物如何保持正确性、一致性。
(5)执行：运行或模拟动态模型的含义是什么，会有什么预期结果。

三、公共机制
公共机制描述了为达到对象建模目的而采取的绘图策略与方法，即如何用图描绘出系统模型的通用方法。
(1)规格说明：用来对构造块的语法和语义进行文字叙述。
(2)修饰：为了更好地描述语法和语义细节，提供一些特殊符号或排版。

充当系统的多个执行者，不同用户可能会成为一个执行者。在UML中，执行者用人形图加名字表示。

用例是系统提供的外部可感知的功能单元，用例的目的是定义清晰的系统行为，但不解释系统的内部结构。内部的具体动作行为可以用交互视图来进一步描述，比如顺序图、协作图。用例用椭圆来表示，用例名标在椭圆下方，用实线与同自身通信的执行者相连，

(二)顺序图(SequenceDiagram)
顺序图显示对象之间的动态合作关系。它强调对象之间消息发送的顺序，同时显示
对象之间的交互。顺序图用二维表来表示交互，纵向是时间轴，横向是参与的角色以及它
(3)通用划分：类与对象的划分，接口与实现的分离。
(4)扩展机制：定义一些特定于某个领域或某个系统的构造块，以及一些特殊的标记和约束。
组成UML的三大部分中，最重要也是我们最需要掌握的就是构造块，尤其是其中的“图”。不管是同处构造块里的“事物”和“关系”，还是后面的“语义规则”和“公共机制”，都会体现在“图”或绘制“图”的过程中。重点在于各种“图”以及它们的画法，建模过程的实质也是一系列图形绘制的过程。

事物和关系的图形表示
一、事物
(一)结构事物(StructuralThings)总共有七种结构化事物。第一种是类(Class)，类是描述具有相同属性、方法、关系和语义的对象的集合。一个类实现一个或多个接口。在UML中类被画为一个矩形，通常包括它的名字、属性和方法(如图9—2所示)。
第二种是接口(Interface)，接口是指类或组件提供特定服务的一组操作的集合。因此，一个接口描述了类或组件的对外的可见的动作。一个接口可以实现类或组件的全部动作，也可以只实现一部分。接口在UML中以一个圆和它的名字来表示(如图9—3所示)。
第三种是协作(Collaboration)，协作定义了交互的操作，描述了一组事物间的相互作用的集合。一个给定的类可能是几个协作的组成部分。协作在UML中用一个虚线椭圆和它的名字来表示(如图9—4所示)。
第四种是用例(UseCase)，用例代表一个系统或系统的一部分行为，是一组动作序列的集合。这些动作是系统对一个特定角色执行，产生值得注意的结果的值。在模型中用例通常用来组织动作事物。在UML中，将用例画为一个实线椭圆，通常还有它的名字(如图9—5所示)。
第五种是活动类(ActiveClass)，它的对象有一个或多个进程或线程。活动类和类很相象，只是它的对象代表的元素的行为和其他的元素是同时存在的。在UML中，活动类的画法和类相同，只是边框为粗线条(如图9—6所示)。
第六种是组件(Component)，组件是物理上或可替换的系统部分，它实现了一个接口集合。在一个系统中，你可能会遇到不同种类的组件，例如COM+或JAVABEANS。组件在UML中如图9—7所示。
第七种是节点(Node)，节点是一组运行资源，如计算机、设备或存储器。在节点内部，放置可执行部件(组件)和对象，以显示节点与可执行软件单元的对应关系。

类、接口、协作、用例、活动类、组件和节点这七个元素是在UML模型中使用的最基本的结构化事物。系统中还有这七种基本元素的变化体，如角色、信号(某种类)、进程和线程(某种活动类)、应用程序、文档、文件、库、表(组件的一种)。

(二)动作事物(BehavioralThings)
动态事物是UML模型中的动态部分。它们是模型的动词，代表时间和空间上的动作。总共有两种主要的动作事物。
第一种是交互(Interaction)，交互是实现某功能的一组事物之间进行的一系列消息交换而组成的动作集合。在交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次序(消息产生的动作)、连接(对象之间的连接)。在UML中消息表示为带箭头的直线，通常加上操作的名字(如图9—9)。

第二种是状态机(StateMachine)，状态机由一系列对象的状态组成，描述事物或交互在生命周期内响应事件所经历的状态序列。
交互和状态机是UML模型中最基本的两个动态事物元素，它们通常和其他的结构元素、主要的类、对象连接在一起。

(三)分组事物(GroupingThings)
分组事物是UML模型中组织的部分，可以把它们看成一个盒子，模型可以在其中被分解。总共只有一种分组事物，称为包(Package)。

包是一种将有组织的元素分组的机制。结构事物、动作事物甚至其他的分组事物都有可能放在一个包中。与组件(存在于运行时)不同的是，包纯粹是一种概念上的东西，只存在于开发阶段。

(四)注释事物(AnnotationalThings)
注释事物是UML模型的解释部分。

二、关系
(一)关联(Association)
关联是一种结构化的关系，指一种对象和另一种对象有联系。给定有关联的两个类，可以从一个类的对象得到另一个类的对象。关联有二元关系和多元关系。二元关系是指一对一的关系，多元关系是一对多或多对一的关系。一般用实线连接有关联的同一个类或不同的两个类。有一些修饰可以应用于关联。
(1)名字：可以给关系取名字。
(2)角色：关系的两端代表两种不同的角色。
(3)重数：表示有多少对象通过一个关系的实例相连接。

(二)依赖(Dependency)
依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的事物，反之不成立。在你想表示一个事物使用另一个事物时，使用依赖关系。通常情况下，依赖关系体现在某个类的方法使用另一个类作为参数。UML中用虚线箭头表示依赖关系(如图9—16所示)。

(三)泛化(Generalization)
泛化是一种特殊／一般的关系，是“is—a～kind—of”的关系，即常说的继承关系。泛化在UML中用带空心三角形的实线表示(如图9—17所示)。
(四)实现(Realization)
实现是依赖的一种，但由于它具有特殊意义，所以将它独立讲述。实现是连接说明和实现之间的关系。实现是类元之间的语义关系，一个类元说明一份契约，另一个类元保证实现该契约。实现在UML中用带空心三角形的虚线表示。

建模实际上是对真实世界进行简化，从而可以更好地理解你要开发的系统。使用UML中基本的构造块如类、接口、组件、关联、依赖、继承等，可以建立简单的系统模型。

UML的九种图
系统代表着你要开发的事物，可以用一组来自不同视角的模型来进行描述。模型是对系统进行语义上的抽象，是整个真实系统的简化，是为了更好地理解系统而创建的。通过不同的模型从不同的视角来观察系统，这些视角以图的形式表达。图是一系列的元素，这些元素常常被画成用点(事物)和弧(关系)相连的形状。
上节介绍的只是一些最基本的UML构造块的图标表示，要想更好地描述系统，需要学习更多、更完善的图。在对真实系统进行建模的时候，你可以发现不管你的问题处于什么样的领域，你都会创建一些相同的图，因为它们代表着系统的通用视角。通常，UML使用如图9—22所示的九种图来观察系统，分为静态模型与动态模型两大部分。

一、UML动态模型
(一)用例图(UseCaseDiagram)用例图从用户角度描述系统功能，并指出各功能的操作者。它将系统功能划分为对用户有意义的事务，这些事务称为用例UseCase，用户称为执行者。用例图就是描述执行者在各个用例中的参与情况，它指导所有的行为视图。
执行者是与系统、子系统或类交互的外部人员、进程或事务。在运行时，具体人员会充当系统的多个执行者，不同用户可能会成为一个执行者。在UML中，执行者用如图9—23所示的人形图加名字表示。
用例是系统提供的外部可感知的功能单元，用例的目的是定义清晰的系统行为，但不解释系统的内部结构。内部的具体动作行为可以用交互视图来进一步描述，比如顺序图、协作图。用例用椭圆来表示，用例名标在椭圆下方，用实线与同自身通信的执行者相连。
(二)顺序图(SequenceDiagram)
顺序图显示对象之间的动态合作关系。它强调对象之间消息发送的顺序，同时显示对象之间的交互。顺序图用二维表来表示交互，纵向是时间轴，横向是参与的角色以及它们交换的信息。
(三)协作图(CollaborationDiagram)
协作图描述对象间的协作关系。协作图与顺序图相似，显示对象问的动态协作关系。如果强调时间和顺序，则使用顺序图；如果强调上下级关系，则选择协作图。这两种图合称为交互视图。顺序图和协作图是同构的，它们相互之间可以转化而不损失信息。
(四)状态图(StateChartDiagram)
状态图是一个类对象可能经历的所有历程的模型图，由对象的各个状态和连接这些状态的转换组成。状态图是对单个类的对象的生命周期进行建模，描述了对象时问上的动态行为。
(五)活动图(ActivityDiagram)
活动图是状态图的一个变体，用来描述执行算法的工作流程中涉及的活动。活动图是对工作流进行建模的特殊形式，它与流程图很类似，不过它支持并发控制。活动图描述了一组顺序的或并发的活动。

二、UML静态模型
(一)类图(ClassDiagram)
类图是描述系统中类的静态结构。类图应该是我们最熟悉的一个图，在面向对象程序设计的所有课本里均有介绍，只不过没有进行标准化规范，不同课本间可能存在一些差异。在UMI。中，类图不仅需要定义系统中的类，表示类之间的联系如关联、依赖、泛化、实现等，还要定义类的内部结构(类的属性和操作)。类图主要用来描述类以及类之间的关系。

(二)对象图 对象图是类图的一个实例，几乎使用与类图完全相同的标识。它们的不同点在于，对象图显示类的多个对象实例，而不是实际的类。对象图是系统在某一时刻的快照，图9—30为对象图的一个示例。

(三)组件图(ComponentDiagram)
组件是可重用的系统片段，具有良好定义接口的物理实现单元。每个组件包含了系统设计中某些类的实现。一个组件可能是源代码、可执行程序或动态库。组件设计的原则为：良好的组件不直接依赖于其他组件，而是依赖于其他组件所支持的接口。这样的好处是，系统中的组件可以被支持相同接口的组件所取代。组件图描述可重用的系统组件(含接口)以及组件之间的依赖。

(四)部署图(DeploymentDiagram)
部署图是用来显示系统中软件和硬件的物理架构的。它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系，也可显示连接的类型及部件之间的依赖性。通过部署图，我们可以了解到软件和硬件组件之间的物理关系，以及节点(Node)内部组件的分带隋况。在节点内部，放置可执行部件和对象以显示节点与可执行商业管理软件单元的对应关系。

三、UML建模过程
学习完UML的九种图之后，我们就可以开始学习如何利用UML来开发一个管理信息系统了。一般从用例图开始，由动人静，一步步搭建起系统模型。从确定系统基本需求(用例图)人手，完成用例图之后，再分析各个用例具体实现的动态模型——顺序图、状态图等。然后通过这些动态模型来确定系统的静态模型——类、对象图等，最后得到整个系统的组件图、部署图。
(一)确定用例以及用例之间的关系
用例模型主要由以下模型元素构成：
1．执行者(Actor)
执行者是指存在于被定义系统外部并与该商业管理软件发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
2．用例(UseCase)
用例用于表示系统所提供的服务，它定义了商业管理软件是如何被执行者所使用的，它描述执行者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
3．通信关联(CommunicationAssociation)
通信关联用于表示执行者和用例之间的对应关系，它表示执行者使用了系统中的哪些服务(用例)。或者说系统所提供的服务(用例)是被哪些执行者所使用的。
这三种模型元素在UML中的表述如图9—33所示。
以银行自动提款机(闽rM)为例，它的主要功能可以由图9—34来表示。ATM的主要使用者是银行客户，客户主要使用自动提款机来进行银行账户的查询、提款和转账交易。
用例之间除了一般的通信关联(CommunicationAssociation)关系之外，还包含(in—clude)、扩展(extend)和泛化(generalization)这三种关系。
(1)包含：包含关系是通过在关联关系上应用《include))构造型来表示的，如图9—35所示。
(2)扩展：是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。
(3)泛化：当多个用例共同拥有一种类似的结构和行为时，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例，如图9—37所示。

(二)确定执行者和用例的细节描述
参照图9—34中描述的银行ATM用例图，以其中的执行者“银行客户”和用例“提款”为例来说明执行者和用例的细节描述。

(三)根据用例详述，给出系统动态模型
参照图9—39里描述的“提款”用例详述，可以将“提款”过程用顺序图描述出来，如图9—40所示。注意：提款过程除了“银行客户”和“后台服务器”两个执行者之外，还有ATM机参与。
动态模型除了顺序图之外，还有协作图、状态图和活动图，本章前面均已做过介绍。动态模型中的图主要为系统分析之用，在具体管理信息系统时，可以灵活选择，搭配使用。

(四)根据系统动态模型，给出系统静态模型
参照图9—40里描述的系统动态模型，可以确定银行ATM系统的“提款”功能中需要用到的两个类(ATM类和后台服务器类)，以及它们之间的关系。图9—41为“提款”用例的类图。

静态模型除了类图之外，还有对象图、组件图、部署图。静态模型中的图相当于系统设计图纸和施工蓝图，对简单管理信息系统来说，用类图就可以清晰表达了。

四、UlVIL图例汇总UML的图例繁多，为了方便读者，特将UML图例汇总展示。

UML是面向对象的系统建模方法，是一个标准的图形表示法，是建立系统模型的一种语言。UML不能被编译、执行，属于系统分析与设计工具。UML模型主要由构造块、语义规则和公共机制三部分组成。构造块就是建模元素，是模型的主体；语义规则是支配构造块如何放在一起的规则；公共机制是运用于整个UML模型中的公共机制、扩展机制。
其中，构造块是最重要的基础，而构造块中最重要的内容就是图。UML中一共有九种图，分为动态模型和静态模型两大部分。动态模型中包括用例图、顺序图、协作图、状态图、活动图；静态模型中包括类图、对象图、组件图、部署图。
UMI。建模的过程实质上是一个由动人静的过程。从动态模型的用例图人手，接着生成顺序图、协作图，状态图和活动图作为补充；然后，由顺序图、协作图就可以过渡到静态模型的类图、对象图，当系统中类、对象较多的时候，还可以用组件图来安排，直至用部署图来安排整个系统的物理结构。