uml导论Word格式文档下载.docx
《uml导论Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《uml导论Word格式文档下载.docx（9页珍藏版）》请在冰豆网上搜索。
消息的图标是带箭头的实线，如：
包的图标：
每一种模型元素会在后续课程中学到，这里不在赘述。
三．扩展机制
用于扩展一个模型元素。
模型元素就像UML的基本词汇，如果基本词汇不够用，用户可以扩展需要的词汇。
在图中可以像使用模型元素一样使用扩展机制。
四．图
由模型元素和扩展机制构成。
包括9种不同的图，分为表示系统静态结构的静态模型（包括用例图，类图，对象图、构件图，部署图），以及表示系统动态结构的动态模型（包括顺序图，协作图，状态图，活动图）。
注意：
顺序图和协作图统称为交互图！
4.1用例图
4.1.1用例
用例表示系统的功能，一个用例是系统功能的一个通用描述，系统的用例构成了系统的所有使用功能。
可以将用例应用到整个系统，也可以将用例应用到系统的一部分，如子系统等。
一个系统通常需要多个用例来描述系统需求。
用例表示为一个椭圆。
4.1.2参与者（活动者）
代表与系统交互的人、硬件设备或另一个系统。
活动者不是系统的组成部分，活动者存在于系统的外部，是虚拟的概念。
用一个小人来表示活动者。
4.1.3用例图
用例图主要描述系统和外部环境的关系和系统提供的服务，以及外界想采用何种方式与系统进行交互，定义的是系统的功能需求。
用例图中包含系统、活动者、用例以及元素之间的各种关系（泛化，关联、依赖）等模型元素，如图显示了一个个人图书管理系统的用例图：
上图显示了一个个人图书管理系统的用例图。
其中，“新增书籍信息”，“查询书籍信息”，“修改书籍信息”，“登记外借情况”，“查询外借情况”和“统计金额与册数”等都是用例的实例。
用例图主要用来为系统的需求建模。
系统的全部或大部分功能需求都可以表达为用例。
需求建模规定系统应该做什么，但不涉及到怎样做，所以用例图用于面向对象的需求分析阶段。
4.1.4包含和扩展
两个用例之间的关系主要可以概括为两种情况：
1.用于重用的包含关系，用构造型《include》表示；
2.用于分离出不同的行为，用构造型《extend》表示。
4.1.4.1包含关系
当可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个组件来实现某一个用例的部分功能是很重要时，应该使用包含关系来表示它们。
如下图所示。
4.1.4.2扩展关系
如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情。
我们可以将这个用例分为一个主用例和一个或多个辅用例，描述可能更加清晰。
4.1.5用例模型
描述的是外部执行者（Actor）所理解的系统功能，由若干个用例图构成。
用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。
首先，它描述了系统的功能需求；
其次，它将系统看作黑盒，从外部活动者的角度来理解系统；
另外，它驱动了需求分析之后个阶段的开发工作，从而影响开发工作各个阶段和UML的各个模型。
用例模型是软件系统后续开发活动的基础。
4.2类图
在面向对象建模技术中，我们将客观世界的实体映射为对象，并归纳成一个个类，类（Class）、对象（Object）和它们之间的关联是面向对象技术中最基本的元素。
对于一个想要描述的系统，其类模型和对象模型提示了系统的结构。
4.2.1类与类图的基本概念
4.2.1.1类
在UML中，类的可视化表示为一个划分成3个格子的长方形（下面两个格子可省略）。
在下图中，“书籍”，“借阅记录”等都是一个类。
最顶部的格子包含类的名字,中间的格子包含类的属性（public,private,protected，分别用“+”，“-”，“#”号表示）,最下面是类的操作。
如图：
类可以分为3种类型：
实体类、接口类、控制类。
在类图中，类与类之间有4个很重要的关系：
依赖关系、泛化关系、关联关系、实现关系。
4.2.1.2依赖关系
有两个元素X，Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖（Dependency）于元素X。
使用带箭头的虚线表示依赖关系（X，Y分别为两个类中的元素，箭头指向X）：
依赖关系有如下三种（假设B类依赖A类）：
1.A类是B类的一个成员变量；
2.A类是B类方法中的一个参数；
3.A类向B类发送消息，从而影响B类发生变化。
4.B类继承A类
classB:
publicshape
{
private:
Ax_circle;
public:
voiddisplay（）
x_circle.displayIt（）;
}
};
classB
voidf1（Aobj）;
classA
{
voidf1（）
B:
:
staticF（1,2）;
b.f1（）;
do（）{……};
ClassB:
publicA{……}
4.2.1.3泛化关系
又叫做概括关系。
就是父类与子类之间的关系。
继承关系是泛化关系的反关系，也就是说，子类是从父类中继承的，而父类则是子类的泛化。
使用带空心箭头的实线表示，箭头指向父类。
泛化特点：
1.父类所具有的属性、操作，子类都有；
2.子类中除了与父类一致的信息外，还包括自己的信息；
3.子类对象能完成父类对象的一切功能。
4.2.1.4关联关系
关联（Association）表示两个类之间存在某种语义上的联系。
关联关系一般都是双向的，即关联的对象双方彼此都能与对方通信。
根据关联的不同含义，关联又可分为：
普通关联、递归关联、或关联、有序关联、三元关联、聚合和组合等。
本节重点介绍普通关联、聚合和组合三种关联。
1.普通关联
普通关联是最常见的一种关联。
只要类与类之间存在连接关系就可以用普通关联表示。
普通关联的图标是一条直线。
下图是关联在类图中的表示。
一个关联至少有两个关联端，每个关联端连接到一个类，关联端是有序的。
名字：
可以在关联的一个方向上为关联取一个名字，而在另一个方向上取另一个名字或不取名字。
关联的名字最好是能够反映类之间的关系的动词。
为避免混淆，在名字的前面或后面带一个表示关联方向的黑三角，黑三角的尖角指明这个关联只能够用在尖角所指的类上。
导航：
关联的方向也可以用在关联端加上箭头来表示，这些箭头起导航的作用。
关联可以是单向的，也可以是双向的。
如果关联是双向的，则不必指出方向箭头。
重复度（Multiplicity）：
又称多重性，指的是一个类的实例能够与另一个类的多少个实例相关联，多重性表示为一个整数范围n..m，整数n定义所连接的最少对象的数目，而m则为最多对象数（当不知道确切的最大数时，最大数用*号表示）。
最常见的多重性有：
0..1
表示0到1个对象
0..*或*
表示0到多个对象
1..*
表示1到多个对象
3..15
表示3到15个对象
5
表示5个对象
例如：
●书与借书记录之间的关系就应该是1对0..1的关系，也就是一本书可以有0个或1个借书记录。
●经理与员工之间的关系则应为1对0..*的关系，也就是一个经理可以领导0个或多个员工。
学生与选修课程之间的关系就可以表示为0..*对1..*的关系，也就是一个学生可以选择1门或多门课程，而一门课程有0个或多个学生选修。
如果图中没有明确标明关联的多重性，则意味着是1。
多重性标识在表示关联关系方向上直线的末端。
又如：
上图中表示“一个人参加一个会议，一个会议可以有一个或多人参加”。
角色：
在关联的类图标旁还可以标出类的角色名。
任何关联关系中都会涉及到与此关联有关的角色，即与此关联相连的对象所扮演的角色。
例如，在下图中，类Account与类AccountGroup关联，类Account又与类Password关联，类Account在这两个关联中的角色分别是user和owner,而Password类在关联中的角色是key。
关联中的角色通常用字符串命名，并放置在类图中与此角色有关的关联关系（直线）的末端，紧靠使用该角色的类。
classAccountGroup
Account*user[100];
……
classAccount
Passwordkey;
可见性：
某些情况，需要限制关联外部的对象对于该关联的可见性。
如上图所示，给出一个Account对象，可以找到相应的Password对象，但是，由于Password是Account私有的，它不应该被外部对象访问，因此如果给出一个AccountGroup对象，虽然可以导航到Account对象，但不应该看到Account对象的Password对象。
在UML中，通过对角色名附加可见性符号“+”、“-”和“#”,分别表示3种可见性：
公共可见性，私有特性和保护可见性。
2.聚合关系
聚合（Aggregation）是一种特殊形式的关联。
聚合表示类之间的关系是整体与部分的关系。
在UML中，使用一个带空心的菱形的实线表示，空心菱形指向是代表“整体”的类，如下图所示。
聚合关系中可以出现多重性、角色（仅用于表示部分的类）和限定符。
也可以为聚合关系命名。
（聚合关系的图标）
例如主板（Mainboard）、CPU、内存（Memory）等都是计算机（Computer）的组成部分，因此，在Computer类与Mainboard类、CPU类或Memory类之间的关系都是聚合关系，如图：
代码为：
classComputer
Mainboardm;
CPUc;
Memoryme;
3.组合关系
又叫组装关系,是聚合的变种，也是关联的特例。
鸟类和翅膀类。
在一个组合关系中，一个对象一次只能是一个组合的一部分；
另外，在组合关系中，“整体”负责“部分”的创建和破坏。
使用带有实心菱形的实线表示。
升级会员 