UML概述_comet uml
赞
踩
初步学习了解UML
1.自己的小思考
刚开始了解UML
啥是UML
根据我的初步理解，UML首先自己猜测一下这个名字应该是英文缩写吧，果然百度一搜，U是统一-----Unified，M是建模------Modeling，L是语言-----Language，合在一块就是叫做Unified Modeling Language，统一建模语言，咦咦咦，Java是一种面向对象的语言，那UML是一种统一建模语言，它们两者之间有什么关系嘞
2.csdn学习初步了解
一，UML概述
UML是一个为面向对象软件设计提供统一的、标准的、可视化的建模语言。适用于 描述以用例为驱动，以体系结构为中心的软件设计的全过程。
二、UML模型图的构成
（一）事物[Things] (4种)：UML模型中最基本的构成元素，是具有代表性的成分的抽象
1.构件事物：UML模型的静态部分，描述概念或物理元素
2.行为事物：UML模型图的动态部分，描述跨越空间和时间的行为
交互:实现某功能的一组构件事物之间的消息的集合，涉及消息、动作序列、链接 状态机:描述事物或交互在生命周期内响应事件所经历的状态序列
3.分组事物：UML模型图的组织部分，描述事物的组织结构
包:把元素组织成组的机制
4.注释事物：UML模型的解释部分，用来对模型中的元素进行说明、解释
注解:对元素进行约束或解释的简单符号
（二）关系[Relationships]：关系把事物紧密联系在一起
（三)图[Diagrams]：图是事物和关系的可视化表示
1.用例图[Use Case Diagram]:用例图是从用户角度描述系统功能， 是用户所能观察到的系统功能的模型图， 用例是系统中的一个功能单元
2.用例图[Use Case Diagram]:用例图是从用户角度描述系统功能， 是用户所能观察到的系统功能的模型图， 用例是系统中的一个功能单元
3.对象图[Object Diagram]:对象图是类图的实例，几乎使用与类图完全相同的标识。 他们的不同点在于对象图显示类的多个对象实例，而不是实际的类
4.顺序图[Sequence Diagram]:(1)顺序图显示对象之间的动态合作关系,他强调对象之间消息发送的顺序，同时显示对象之间的交互;(2)顺序图的一个用途是用来表示用例中的行为顺序。当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或引起状态转换的触发事件
5.协作图[Collaboration Diagram]:(1)协作图描述对象间的协作关系，协作图跟顺序图相似， 显示对象间的动态合作关系。除显示信息交换外，协作图还显示对象以及他们之间的关系 (2)协作图的一个用途是表示一个类操作的实现
6.状态图[State Chart Diagram]:状态图是一个类对象所可能经历的所有历程的模型图。 状态图由对象的各个状态和连接这些状态的转换组成
7.活动图[Activity Diagram]:(1)活动图是状态图的一个变体，用来描述执行算法的工作流程中涉及的活动 (2)活动图描述了一组顺序的或并发的活动
8.构件图[Component Diagram]:构件图为系统的构件建模型——构件即构造应用的软件单元——还包括 各构件之间的依赖关系，以便通过这些依赖关系来估计对系统构件的修改给系统可能带来的影响
9.部署图[Deployment Diagram]:部署视图描述位于节点实例上的运行构件实例的安排。 节点是一组运行资源，如计算机、设备或存储器。这个视图允许评估分配结果和资源分配
总结
（四）各UML图的关系
三、UML语法描述
UML学习笔记
第一章:引言
本章概述
对软件建模和设计的简要介绍
介绍软件体系结构
概述基于UML的面向对象的分析和设计
1.1软件建模
建模在各行各业都广泛应用，比如数学建模
在基于模型的软件设计和开发中，软件建模被作为软件开发过程的一个根本性的部分，模型在系统的实现之前进行构造分析，用于后期的指导，也可从多个角度去看
1.2面向对象的方法和统一建模语言
面向对象概念的重要性。对于方法，继承的好处分析。
1.3软件体系结构设计
软件体系结构把系统的总体结构（包括构件及其连接关系）与各个构件的内部细节相分离。对于构件及其连接关系的强调有时被称为全局性的编程，而单个构件的详细设计被称为局部性的编程。
软件体系结构可以在不同的细节层次上进行描述。
在较高的细节层次上，体系结构可以描述软件系统是如何分解为子系统的。
在较低的细节层次上，体系结构可以描述子系统是如何分解为模块或构件的。
这些不同层次上的体系结构强调的都是子系统/构件的外部视图，即子系统/构件所提供和需要的接口以及与其他子系统/构件的连接关系。
设计软件体系结构的时候应当考虑系统的软件质量属性。
这些属性与体系结构如何满足重要的非功能性需求相关，例如性能、安全性和可维护性等。
软件体系结构有时被称为高层设计。软件体系结构可以从不同的视图进行描述重要的是保证体系结构同时满足功能性（软件必须做什么）和非功能软件需求。软件体系结构同时也是详细设计和实现（此时开发团队一般会变得更大）的出发点。
1.4方法和表示方法
对一些设计相关术语的定义
1.软件设计表示法
是一种使用图形或文本方式或同时使用图形和文本描述软件设计的方法。
2.软件设计思想
是一种可以用于设计系统的根本性的思想。例如，信息隐藏是一种软件设计思想。
3.软件设计策略
是一种对设计的整体规划和方向的性的指导。
4.软件结构组织准则
是用于帮助设计者将软件系统组织为构件的启发式规则或指导方针。例如，对象结构设计准则为如何将系统分解为对象提供了指导方针。
5.软件设计方法
是一种描述了用于在给定的应用系统软件需求基础上创建”个设计方案的步骤序列的系统化方法。
这种方法可帮助设计者或设计团队确定需要做出的决策、做出决策的顺序以及决策时使用的结构设计准则。设计方法建立在一组设计思想基础上，使用一种或多种设计策略，并且使用某种设计表示法描述所得到的设计。在一个给定的设计步骤中，设计方法可能会提供一组结构设计准则来帮助设计者将系统分解为构件。
6.协作的对象建模和设计方法
使用 UML 表示法来描述设计。COMET 基于信息隐藏、类、继承和并发任务等设计思想。该方法使用并发对象设计的设计策略，该策略将软件系统的结构组织为一组主动和被动对象并
且定义它们相互之间的接口。此外，该方法还为分析过程提供了结构设计准则来帮助将系统的结构组织为对象，而且为设计过程提供了附加的准则来确定子系统和并发任务。
1.5COMET:一种基于UML的软件应用建模和设计方法
描述了一种称为 COMET 的基于 UML 的软件建模和体系结构设计方法。
COMET是一种迭代的用例驱动和面向对象的软件开发方法，涵盖了软件开发生存周期的需求、分析和设计建模阶段。系统的功能性需求被定义为参与者和用例。每个用例定义了一个或多个参与者与系统之间的交互序列。用例可以在各种不同的细节层次上进行考虑。在需求模型中，系统的功能性需求被定义为参与者和用例。在分析模型中，用例被具体化为参与用例的对象及其交互关系。而设计模型中则会开发软件体系结构，考虑分布、并发和信息隐藏等问题。
1.6UML标准
UML 0.9 统一了 Booch、Pcobson（1992）和 Rumbaugh et al（1991）所述的表示法。这一版本与各种厂商和系统集成商的参与一起构成了 UML 标准化工作的基础。
基于 UML 的模型驱动体系结构
按照 OMG 的观点，“建模是软件应用在编码之前的设计”。OMG 积极推动着在模型驱动的软件体系结构中将 UML 模型作为实现之前的软件体系结构建模表示。OMG 认为 UML 独立于特定的方法学，是一种描述面向对象分析和设计结果的表示法，其中的分析和设计过程可以采用各种不同的方法学。
UML 模型可以是平台无关模型也可以是平台相关模型PIM 是一种在采用特定平台的决策做出之前描述软件体系结构的精确模型。首先开发 PIM 特别有用，因为同一个 PIM 可以映射到不同的中间件平台上，
例如 COM、CORBA、.NET、J2EE、Web Services 或其他 Web 平台。本书中介绍的方法使用模型驱动体系结构的概念开发基于构件的软件体系结构，并将其表示为 UML 平台无关模型（PIM）。
1.7软件体系结构的多视图
软件体系结构可以从不同的角度进行考虑，称为不同的视图。提出了软件体系结构的 4+1 视图模型，提倡软件体系结构的多视图建模方法，其中用例视图位于中心位置（4+1 视图中的 1)。这些视图包括：逻辑视图，一种静态建模视图；进程视图,一种并发进程或任务视图；开发视图，一种子系统和构件设计视图；物理视图，一种反映物理拓扑结构及连接关系的视图。Hofimeister et al.（2000）描述了工业界对于软件体系结构的一种观点，包括四个视图:一个概念视图，描述主要的设计元素及其间的关系;一个代码视图，将源代码组织为对象代码、函数库和目录；模块视图，由子系统和模块组成；执行视图，描述了并发和分布式执行方面。
这本书描述 UML 中不同的软件体系结构建模视图。
这些视图包括:
1.8软件建模和设计方法的发展
20 世纪 60 年代，软件程序经常是在几乎没有进行任何系统化的需求分析和设计的情况下开发出来的。图形化的表示法（主要是流程图）经常在编码之前的详细设计规划中作为文档工具或者设计工具使用。创建子程序的最初目的是通过在程序中不同的部分调用代码块使其能够得到共享。很快，人们意识到子程序可以作为一种构造模块化系统的手段，并将其用作一种项目管理工具。程序可以被划分为多个模块，其中每个模块可以由单个的程序员进行开发并实现为一个子程序或函数。
20 世纪 70 年代早期，自顶向下设计以及逐步精化的思想成为主流的程序设计方法，其目的是提供系统化的结构化程序设计方法。Dijkstra 在 T.H.E.操作系统的设计过程中提出了最早的软件设计方法之一（Dijkstra 1968 ），该方法使用了层次化的体系结构。这是第一个用于并发系统（即操作系统）设计的设计方法。
20 世纪 70 年代中晚期，两种不同的软件设计策略占据了主导地位：面向数据流的设计和数据结构化设计。结构化设计中的面向数据流的设计方法是最早出现的几个完整、全面的设计方法之一。该方法的主要思想是通过考虑数据在系统中的流动可以更好地理解系统的功能。该方法提供了一种开发系统数据流图然后将其映射为结构图的系统化方法。结构化设计引入了耦合和内聚准则来评价设计质量，强调基于模块的功能分解以及模块接口的定义。基于数据流图开发的结构化设计中第一个部分则被细化和扩展成了一种全面的分析方法，即结构化分析。另一种软件设计方法是数据结构化设计。该方法的观点是通过考虑数据结构获得对问题结构的充分理解。因此，该方法强调首先设计数据结构然后基于数据结构设计程序结构。使用这种策略的两种主要的设计方法是 Jackson 结构化方法（Jackson 1983）和 Warnier/Orr方法。
在数据库领域中，逻辑数据和物理数据分离的思想是开发数据库管理系统的关键。有很多方法都强调数据库的逻辑设计，包括 Chen 引入的实体-关系建模。Parnas（1972）关于信息隐藏的观点对软件设计做出了巨大的贡献。早期系统（甚至是那些已经考虑了模块化设计的系统）的一个主要问题来自于全局数据的广泛使用，这使得这些系统很容易出错且难以修改。信息隐藏为大量减少全局数据的使用提供了一种方法。
20 世纪 70 年代后期 MASCOT 表示法以及此后的 MASCOT 设计方法的提出是对并发和实时系统设计的一个重要贡献。MASCOT 在数据流方法基础上，对任务之间基于消息通信通道或者数据池（封装了共享数据结构的信息隐藏模块）的通信方式进行了形式化。任务只能通过调用通道或数据池提供的访问程序间接地访问通道或数据池中的数据。访问程序还可以对数据访问进行同步（通常使用信号量)，从而使访问数据的任务无需关心任何同步问题。
软件设计方法在 20 世纪 80 年代逐渐成熟起来，同时出现了几种新的系统设计方法。Parnas 在海军研究实验室（Naval Research Lab，NRL）工作期间探索了信息隐藏方法在大规模软件设计中的使用，由此导致了海军研究实验室软件成本降低方法。在并发和实时系统上应用结构化分析和结构化设计方法的工作导致了实时结构化分析和设计方法以及实时系统设计方法的产生。
另一种在 20 世纪 80 年代早期出现的软件开发方法是 Jackson 系统设计方法。JSD 方法将软件设计视为对现实世界的模拟，强调使用并发任务对问题域中的实体进行建模。该方法是较早倡导设计应该首先对现实进行建
模的方法之一，在这一点上早于面向对象分析方法。系统被视为对现实世界的模拟，并被设计为一个并发任务的网络，其中每个现实世界实体使用并发任务进行建模。JSD 方法同时还突破了当时已成为惯性思维的自顶向下的设计思想，对软件设计采用了一种中间向外的行为性建模方法。该方法是对象交互建模的先导，而对象交互建模则是现代面向对象开发的一个重要内容。
1.9面向对象的分析和设计方法
20 世纪 80 年代中晚期，面向对象编程的流行和成功使得几种面向对象设计方法相继出现
这些方法所强调的重点在于问题域建模、信息隐藏和继承。
Parnas 倡导将信息隐藏作为一种设计更加独立的模块的方法，这种独立的模块可以在对其他模块影响很小甚至不造成任何影响的情况下进行修改。
Booch 将面向对象思想引入到设计中，最初与信息隐藏一起应用到基于 Ada 的系统的面向对象设计中，然后扩展为在面向对象设计中使用信息隐藏、类和继承。
Shlaer and Mellor（1988）、Coad and Yourdon（1991）及其他人将面向对象思想引入到分析中。
与结构化方法相比，面向对象方法被普遍认为提供了一种更加平滑的从分析到设计的过渡。面向对象分析方法将面向对象思想应用到软件生存周期的分析阶段，强调识别问题域中的现实世界对象并将其映射为软件对象。
在对象建模上最初的设想是源自于逻辑数据库设计中使用的信息建模。
实体关系建模中的实体是问题域中的信息密集型对象。实体、实体的属性以及实体间的关系在实体关系图中进行确定和描述；重点完全在数据建模上。
在设计过程中，实体关系模型被映射到库（通常是关系数据库）中。在面向对象分析中，问题域中的对象被识别和建模为软件类，然后确定每个类的属性以及类之间的关系（Coad 1991；Rumbaugh et al.1991；Shlaer and Mellor 1988 ）。面向对象的静态建模中的类与实体关系建模中的实体类型的主要区别在于类有操作而实体类型没有操作。此外，信息建模只对存储在数据库中的持久化实体进行建模，而静态的对象建模中也会对其他问题域中的类进行建模。信息建模中也包含了聚合和泛化/特化这样更加高级的概念。在 UML 之前使用最广泛的静态对象建模表示法是对象建模技术
静态对象建模也称为类建模和对象建模，因为其中包含确定对象所属的类并且在类图中描述类与类之间的关系。领域建模这一术语也用来指对问题域的静态建模
早期的面向对象分析和设计方法通过信息隐藏和继承强调软件开发的结构性方面而忽视了动态方面。
1.10并发，分布式和实时设计方法
实时系统的并发设计方法结合了早期的并发设计、实时设计和早期的面向对象设计方法，强调信息隐藏模块的构造和并发任务的构造。Octopus是一种基于用例、静态建模、对象交互和状态图的实时设计方法。
ROOM是一种与 CASE工具 ObjecTime 紧密联系的面向对象的实时设计方法，它是基于参与者（actor）的，即一种使用 ROOMcharts（一种状态图的变种）建模的主动对象。
ROOM 模型可以被执行，因此可以作为系统的早期原型使用。针对大规模系统的动态建模，Buhr（1996）引入了一个有趣的概念，称为用例映射，它是基于用例的概念产生的。
第二章
2.1 UML图
2.2用例图
一个参与者（actor）发起一个用例（use case ）。用例定义了参与者与系统之间的一组交互序列。在用例图中，参与者用一个人形图标表示，系统则用一个方框来表示，一个用例表示为方框中的一个椭圆。通信关联将参与者与他们参与的用例进行连接。用例之间的关系通过包含（include）关系和扩展（extend）关系进行定义。
2.3类和对象
类和对象在 UML 表示法中被描绘成方框
表示类的方框总是包含类名，并且可选择性地列出类的属性和操作。
为了区分类（类型）和对象（该类型的一个实例)，对象名称需要带有下划线。可以在对象名和类名之间使用冒号分隔来完整地描绘一个对象，例如 anObject:Class。也可选择性地隐藏冒号和类名，仅剩下对象名，例如 anObject。另一种方式是隐藏对象名，仅在冒号后显示
类名，例如：Class。
2.4类图
前言总说:
在类图中，类用方框描绘，类之间的静态（永久）关系被描绘成连接方框之间的连线。
UML 表示法支持以下三种类之间的主要关系类型：关联、整体/部分关系和泛化/特化关系。
第四种关系，即依赖关系，经常被用来表示包之间是如何进行关联的。
2.4.1 关联
小知识点
1.一个关联（association）是两个或多个类之间的一个静态的、结构化的关系。
2.两个类之间的关联被称为二元关联（binary association )，它用两个类框之间的连线表示。
3.一个关联具有一个名字，并且可选择性地具有一个黑色小箭头来表示关联名称的阅读方向。
4.每个连接类的关联线的末端标明关联的多重性，多重性指的是一个类的多少个实例关联到另一个类的一个实例。
5.此外，可以用棍状箭头描绘导航的方向。
6.一个关联的多重性（multiplicity）指的是一个类的多少个实例可能和另一个类的单个实例有关（如图 2-3a 的右边)。
7.一个类的多重性可以是一个（1）可选（0…1）、零或多个（)）、
一个或多个（1…)，或者特定的数值范围（m…n)，其中 m和n 是数值。
2.4.2 聚合和组合层次
聚合和组合层次是整体或部分的关系。组合关系（用黑色菱形表示）是一个比聚合关系（用空心菱形表示）更强的整体/部
分关系的形式。
菱形与聚合或组合中（ClassWhole）的类方框相连接。
2.4.3 泛化和特化层次
泛化/特化层次是一种继承关系。泛化被描绘为一个连接子类到父类的具有箭头的连线，箭头与表示父类的方框连接。
2.4.4 可见性
可见性指类中的一个元素是否在类外可见，如图 2-4 所示。在类图中描绘
可见性是可选的。
公有可见性使用 + 号，表示一个元素在类的外部是可见的。
私有可见性使用 - 号，表示一个元素只在定义它的类的内部是可见
的，对于其他类是隐藏的。
受保护可见性使用 # 号，表示一个元素在定义它的类及其所有子类中是可见的。
2.5 交互图
通信图和顺序图是 UML 的两种主要类型的交互图，它们用来描绘对象间是如何进行交互的。在这些交互图中，对象用长方形方框表示，对象的名字不需要使用下划线标绘。
2.5.1通信图
通信图在 UML 1.x 中被称为协作图通信图描绘了交互对象的组织结构。其中，对象用方框表示，连接方框的线代表了对象间的交互。与这
些线相邻的带有标签的箭头表示了对象间消息传递的名字和
方向。
其中，星号（*）表示一个可选的迭代,即一条消息被发送了多于一次。
一个可选的条件表示一条消息在满足特定条件的情况下才会被发送。
2.5.2顺序图
顺序图是另一种对象间的交互方式图。
将对象通过对象交互通过时间序列的方式进行描绘。
顺序图具有两个维度，其中参与交互的对象被描绘在水平方向，而垂
直方向代表时间维度。
从每一个对象框出发都有一条被称为生命线的垂直虚线。每条生命线可以选择性地具有一个使用双实线表示的激活杆,它用来表示对象执行的时间。
**参与者通常显示在页面的最左端。**带有标签的水平箭头代表消息。仅有箭头连接的源对象和目标对象是相关的，消息从源对象发送到目标对象。时间从页面的顶部开始增加直至底
部。
另外，消息之间的间隔是不相关的。
2.6 状态机图
在 UML表示法中，一个状态转换图被称为状态机图。本书使用状态图这一更为通用的术语。
在 UML 表示法中，圆角框表示状态，连接圆角框的弧线表示转换
状态图的初始状态用一个始于小黑圆圈的弧线表示。
终结状态是可选的，它被描绘为嵌套在大白圈中的小黑圆圈，有时也被称为靶心。
状态图可以按层次分解。
可选的动作作为转换的结果被执行。
一个状态可具有以下
任意的动作：
•进入动作（entry action )，它在进入状态的时候执行
•退出动作（exit action )，它在退出状态的时候执行
上图描述了一个被分解为顺序的子状态 Al 和 A2 的组合状态 A。
在这种情况下，状态图在一个时刻内只会处于一个子状态，即进入第一个子状态 A1 然后进入子状态 A2。
上图描述了一个被分解为正交区域BC 和 BD 的组合状态 B。在这种情况下，状态图在同一个时刻进入了每一个正交区域 BC 和 BD 中。每一个正交的子状态被进一步分解为顺序的子状态。因此，当进入组合状态 B 时，同样进入了状态 B1 和 B3。
2.7包
在UML里包是一个 一组建模元素的组合。
eg:
代表一个系统或一个子系统。
2.8并发通信图
在 UML 表示法中，一个主动对象可用于描绘一个并发对象、进程
、线程或任务。
可以用一个左右两边带有两根垂直线的方框表示—
个主动对象。
主动对象拥有自己的控制线程，并且能与其他对象并发执行。
被动对象不具有控制线程。被动对象只在其他对象调用其方法时才会执行。
主动对象在描绘系统并发视角的并发通信图中描绘。
区别:
主动对象用左右两边带有两条相互平行的垂直线的矩形框表示，被动对象则用常规的矩形框表示。
2.9 部署图
部署图以物理结点和结点间物理连接的方式（eg:网络连接）展示了一个系统的物理配置。
一个结点使用一个立方体表示，连接则用这些立方体之间的连接线表示。
本质上，部署图是以系统结点为关注点的一种类图。
在第当两个以上的计算机结点被同一网络连接在一起时，可以使用这种表示形式。
2.10 UML 扩展机制
UML 提供了三种语言扩展机制构造性，标记值和约束。
2.10.1 构造型
一个构造型定义了一个从已有 UML 建模元素中派生出来的、且针对建模者问题进行裁剪的构造块。UML 已经定义了多种标准的构造型。另外，建模者可以定义新的构造型。
扩展构造型的概念，它们允许一个建模元素被附加多个构造型。因此，一个建模元素不同的、可能正交的特性可以通过不同的构造型被描绘出来。COMET 方法就是利用了这个附加的功能。
UML 构造型表示法允许一个建模者针对一个特定的问题对 UML 建模元素进行裁剪。
然而，UML 也允许将构造型表示为符号。
2.10.2 标记值
标记值扩展了一个 UML 构造块的属性为其增加新的信息。
标记值以{标记=值}的形式书写在大括号中。
新添加的标记值用逗号分隔。
一个类可具有标记值。
2.10.3 约束
UML 表示法中的标记值和约束约束指定了一个必须为真的条件。
在UML 中，约束是一个 UML元素语义的扩展，它允许新规则的加入或修改已存在的规则。
UML也提供了对象约束语言来表达约束。
2.11 本书的约定
2.11.2 分析建模
1.类
类名单词首字母大写。
在图中，多单词的名字间没有空格，例如 CheckingAccount。
然而在文本中，为了提升可读性引入了空格，例如 CheckingAccount。
属性名单词首字母小写，例如 balance。
对于多单词组成的属性，在图中不使用空格分隔，但在文本中引人空格。多单词名称中的第一个单词首字母小写，接下来的单词首字母大
写。例如，在图中使用 accountNumber，在文本中使用 account Number。属性的类型使用首字母大写的单词表示，例如 Boolean、Integer 或 Real。
2.对象
对象可以通过多种方式表示。
在这种情况下，第一个单词的首字母小写，之后单词的首字母大写。例如，在图中，对象表示为 aCheckingAccount 和anotherCheckingAccount 的形式；在文本中，相同的对象表示为 aChecking Account 和another CheckingAccount 的形式。
一个单独的未命名对象。图中有些对象被表示为不具有对象名的类实例，例如：
CheckingAccount。在文本中，这个对象被命名为 CheckingAccount。为了提升可读性，
冒号被去除了，且在多单词组成的名字中引入了空格。这意味着，根据一个对象在图中的表示方式，在文本中有时该对象的首单词首字母大写，有时首单词的首字母小写。
3.消息
在分析模型中，由于消息的类型未被确定，因此消息总是表示为简单消息消息名字的首字母大写。在图和文本中，多单词组成的消息名字具有空格，例如 Simple Message Name。
4.状态图
在图和文本中，状态、事件、条件、动作和活动的名称都是首字母大写的，并且在多单间存在空格。
2.11.3 设计建模
设计模型的命名约定如下：
1.主动类和被动类主动类（并发类）和被动类的命名约定与分析模型中类的命名约定一致
2.主动对象和被动对象主动对象（并发对象）和被动对象的命名约定与分析模型中对象的命名约定一致。
3.消息在设计模型中，消息名字的第一个单词首字母是小写的，接下来的单词首字母大写。在图和文本中，单词之间都没有空格，如 alarmMessage。消息参数的名字用首字母小写的形式，例如 speed。在图和文本中，多单词的属性名字之间没有空格，另外，多单词名字的第一个单词首字母小写，之后的单词首字母大写，例如cumulativeDistance。
4.操作
在图和文本中，操作（也叫方法）的命名约定都遵循消息的命名约定。因此，操作及其
参数的第一个单词的首字母都是小写的，之后的单词首字母大写。单词之间不存在空格，例
如 validatePassword （userPassword ）。
