UML关联关系

UML中的关联关系其内在意思就是has a

相对于依赖关系,关联关系在代码中有所体现.上图中的关联关系在代码中体现为
其中water 中将Climate作为其中的属性.
当然,关联关系中也有双相关联

 

 

关联又分为组合,聚合

 

对应的代码如下:

设计模式中的关联关系

代码如下:

  1: //工作经历

  2:     class WorkExperience

  3:     {

  4:         private string workDate;

  5:         public string WorkDate

  6:         {

  7:             get { return workDate; }

  8:             set { workDate …

没有评论

admin | UML |

UML简单例图

UML,统一建模语言，是一种面向对象的建模语言。它的主要作用是帮助用户对软件系统进行面向对象的描述和建模（建模时通过将用户的业务需求映射为代码，保证代码满足这些需求，并能方便地回溯需求的过程），它可以描述这个软件开发过程从需求分析直到实现和测试的全过程。

 

UML的组成：
UML由设图(View)、图(Diagram)、模型元素(Model Element)和通用机制(General Mechanism)等几个部分组成。
视图(View)：是表达系统的某一方面的特征的UML建模元素的子集，由多个图构成，是在某一个抽象层上，对系统的抽象表示。
图(Diagram)：是模型元素集的图形表示，通常是由弧（关系）和顶点（其他模型元素）相互连接构成的。
模型元素(Model Element)：代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。
通用机制(General Mechanism)：用于表示其他信息，比如注释、模型元素的语义等。另外，UML还提供扩展机制，使UML语言能够适应一个特殊的方法（或过程），或扩充至一个组织或用户。

 

UML视图的分类：
UML是用来描述模型的，用模型来描述系统的机构或静态特征，以及行为或动态特征。从不同的视角为系统构架建模，形成系统的不同视图。
(1)用例视图(Use Case View)，强调从用户的角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图。
(2)逻辑视图(Logical View)，展现系统的静态或结构组成及特征，也称为结构模型视图(Structural Model View)或静态视图(Static View)。
(3)并发视图(Concurrent View)，体现了系统的动态或行为特征，也称为行为模型视图(Behavioral Model View)或动态视图(Dynamic View)。
(4)组件视图(Component View)，体现了系统实现的结构和行为特征，也称为实现模型视图(Implementation Model View)。
(5)配置视图(Deployment View)，体现了系统实现环境的结构和行为特征，也称为环境模型视图(Environment Model View)或物理视图(Physical View)。

 

视图是由图组成的，UML提供9种不同的图：
(1)用例图(Use …

UML例图

没有评论

admin | UML |

UML符号、图例

三位“盟友”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 (注重于组织方面)…

没有评论

admin | UML |

UML扩展机制

为了避免UML语言整体的复杂性，UML没有吸收所以的面向对象的建模机制和技术而是设计了扩展机制，通过扩展机制用户可以定义使用自己的元素。在前边介绍UML构成的时候，提到了UML的扩展机制（extensibility mechanism）：版型（stereotype）、标记值（tagged value）和约束（constraint）。在很多情况下我们利用UML的版型这种机制对UML进行扩展，使其能够应用到更广泛的领域。

1.         什么是版型

版型是建模元素的一种类型，扩展UML的语义。版型必须以UML中已经定义的元素为基础，可以扩展语义但不能扩展已存在的元素结构。版型不是给元素增加新的属性或约束，而是直接在已有元素中增加新的语义，这种机制可以看作是已有元素进行专有化。版型的表示方法是在模型元素的旁边添加一个版型的名称，版型名称使用双括号括起来，《版型名》。版型是一种非常好的扩展机制他避免了UML语义过于复杂化，同时也使得UML能够适应各种需求。

通常人们在特定方法或特定的应用领域中使用UML时，会使用版型。有些概念、方法或特定领域特有标注UML不支持，用户就可以自定义。自定义版型时需要作以下工作：描述自定义版型的基础是哪个元素；对该元素语义的影响；给出使用该版型的例子。

利用UML的扩展机制对UML进行扩展是已经非常有意义的工作，有时我们需要使用UML来建模，但是UML本身提供的元素满足不了我们的需要，此时并不意味者UML没有用了，而是需要我们应用UML的扩展机制来实现自定义元素，从而实现建模。

1.1 数据建模

我们在进行数据建模时经常使用的建模工具是ERWin、Power Designer、ERStudio等。既然UML功能强大使用UML可以进行数据建模吗？当然可以，此时我们需要UML的扩展机制。对于关系型数据库来说，可以用类图描述数据库模式，用类描述数据库表，用类的操作来描述触发器和存储过程。

进行数据库设计时有一些关键概念我们需要用UML来表示，他们是模式（schema）、主键、外键、域、关系、约束、索引、触发器、存储过程、视图等。从某种意义上说，使用UML进行数据库建模就是要确定如何使用UML中的元素来表示这些概念。同时考虑引用完整性、范式等要求。下面是使用版型来表示这些元素。

数据库中的概念

版型

对应UML元素

数据库《database》组件模式《schema》包表《table》类视图《view》类域《domain》类索引《index》操作主键《PK》操作外键《FK》操作唯一约束《Unique》

…

没有评论

admin | UML |

UML活动图

UML 活动图记录了单个操作或方法的逻辑，单个用户案例，或者单个业务流程的逻辑。在很多方面，活动图是结构化开发中流程图和数据流程图 (DFD) 的面向对象等同体,要创建一个 UML 活动图，您需要反复执行下列步骤。

第一步，定义活动图的范围首先应该定义您要对什么建模。单个用户案例力？一个用户案例的一部分？一个包含多个用户案例的商务流程？一个类的单个方法？一旦您定义了您所作图的范围，您应该在其顶部，用一个标注添加标签，指明该图的标题和唯一的标示符。您有可能也想要包括该图的时间甚至作者名。
第二步，添加起始和结束点每个活动图有一个起始点和结束点，因此您也要马上添加它们。在 《UML 精粹》(UML Distilled) (参见参考资料)，Fowler 和 Scott 认为结束点是可选的。有时候一个活动只是一个简单的结束，如果是这种情况，指明其唯一的转变是到一个结束点也是无害的。这样，当其他人阅读您的图时，他或她知道您已经考虑了如何退出这些活动。

第三步，添加活动如果您正对一个用户案例建模，对每个角色(actor)所发出的主要步骤引入一个活动(该活动可能包括起始步骤，加上对起始步骤系统响应的任何步骤)。如果您正对一个高层的商务流程建模，对每个主要流程引入一个活动，通常为一个用户案例或用户案例包。最后，如果您正对一个方法建模，那么对此引入一个活动是很常见的。

第四步，添加活动间的转变我的风格总是应该退出一个活动，即使它是转变到一个结束点。一旦一个活动有多个转变时，您必需对每个转变加以相应标示。

第五步，添加决策点有时候，您所建模的逻辑需要做出一个决策。有可能是需要检查某些事务或比较某些事务。要注意的是，使用决策点是可选的。

第六步，找出可并行活动之处当两个活动间没有直接的联系，而且它们都必需在第三个活动开始前结束，那它们是可以并行运行的。

 

下面的活动图描述了大学新生第一次将如何办理入学的商业逻辑。

• 实心圆表示活动图的起点，实际上是一个占位符，带边框的实心圆表示终点。
• 圆角矩形表示执行的过程或活动。在该图中，虽然您会注意到“登记研习班”用例将多次调用“登记研习班”活动，但这些活动却相当紧密地映射到用例。活动可以细致得多，特别在选择记录方法逻辑，而不是高级商业过程时。
• 菱形表示判定点，虽然在此示例中判定点只有两种可能结果；但即使有更多可能结果，它也同样容易。
• 箭头表示活动之间的转换，各种活动之间的流动次序。
• 箭头上的文字表示继续转换所必须满足的条件，总是使用格式“[条件]”来描述。我猜想，在 UML 的将来版本中，我们将会看到使用 UML 约束表示法（如“{condition}”）记录的条件。
• 粗线条表示可能会并行进行的过程的开始和结束；在大学里成功入学后，必须参加指定的概况介绍，还要至少登记一个研习班并交付一部分的学费。

退出活动可能有几种方法，如您看到的“填写入学表”活动的那样。如果正确填写了表格，那么可以继续进行大学的入学手续。但是，如果表格不正确，那么必须获得帮助（可能从注册员获得帮助）以正确填写它们。

图 1. …

没有评论

admin | UML |

UML用例图总结

用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。

【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。

用例图所包含的元素如下：

　　1. 参与者(Actor)

表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。

　　2. 用例(Use Case)

用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。

　　3. 子系统(Subsystem)

用来展示系统的一部分功能，这部分功能联系紧密。

　　4. 关系

用例图中涉及的关系有：关联、泛化、包含、扩展。

如下表所示：

　　a. 关联(Association)

表示参与者与用例之间的通信，任何一方都可发送或接受消息。

【箭头指向】：指向消息接收方

　　b. 泛化(Inheritance)

就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

【箭头指向】：指向父用例

　　c. 包含(Include)

　　包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。

【箭头指向】：指向分解出来的功能用例

　　d. 扩展(Extend)

扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。

【箭头指向】：指向基础用例

　　e. 依赖(Dependency)

以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。

【箭头指向】：指向被依赖项

　　5. 项目(Artifact)…

UML用例图

没有评论

admin | UML |

UML类图详解

在UML的静态机制中类图是一个重点，它不但是设计人员关心的核心，更是实现人员关注的核心。建模工具也主要根据类图来产生代码。类图在UML的9个图中占据了一个相当重要的地位。

James Rumbaugh对类的定义是：类是具有相似结构、行为和关系的一组对象的描述符。类是面向对象系统中最重要的构造块。类图显示了一组类、接口、协作以及他们之间的关系。在UML中问题域最终要被逐步转化，通过类来建模，通过编程语言构建这些类从而实现系统。类加上他们之间的关系就构成了类图，类图中还可以包含接口、包等元素，也可以包括对象、链等实例。接口在类图中通过版型来表示<<interface>>，下面的介绍将主要介绍类，接口和类类似。

A.      类的UML表示

 

类的命名尽量应用领域中的术语，应明确、无岐义，以利于相互交流和理解。类的属性、操作中的可见性使用＋、#、－分别表示public、protected、private。

B.      类之间的关系

类之间的关系是类图中比较复杂的内容。有关联、聚合、组合、范化、依赖。

关联：是模型元素之间的一种语义联系，是类之间的一种很弱的联系。关联可以有方向，可以是单向关联，也可以是双向关联。可以给关联加上关联名来描述关联的作用。关联两端的类也可以以某种角色参与关联，角色可以具有多重性，表示可以有多少个对象参与关联。可以通过关联类进一步描述关联的属性、操作以及其他信息。关联类通过一条虚线与关联连接。对于关联可以加上一些约束，以加强关联的含义。如下图所示：

 

聚合是一种特殊的关联，聚合表示整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构。从而找出一些组成类，该整体类和组成类之间就形成了聚合关系。例如舰队是由一系列的舰船组成。需求描述中“包含”、“组成”、“分为….部分”等词常意味着聚合关系。

 

组合也是一种特殊的关联，也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在。部分对象与整体对象之间具有共生死的关系。

聚合和组合的区别：聚合关系是“has－a”关系，组合关系是“contains－a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。

泛化定义了一般元素和特殊元素之间的分类关系，类之间的这种泛化关系也就是继承关系。泛化关系是“a－kind－of”关系，定义一般元素和特殊元素之间的分类关系。下图是一个泛化关系的例子。

 

有两个元素如果修改X的定义可能会导致对Y的定义，则认为Y依赖X。依赖关系可能由各种原因引起，如一个类向另一个类发送消息，或者一个类是另一个类的数据成员类型，或者一个类是另一个类的操作的参数类型等。有时依赖关系和关联关系比较难区分。如果类A和类B有关联关系，它们之间必然有依赖关系。如果两个类之间有关联关系时不用再表示出这两个类之间的依赖关系。

 

 

C.      建立类图

在软件开发不同阶段使用的类图具有不同的抽象层次，即概念层、说明层、和实现层。使用UML进行应用建模也应该是一个迭代的过程，所以我们应该建立一个类图的层次的概念。

概念层类图描述应用领域中的概念，这些概念与实现它们的类有联系。通常没有直接的映射关系。画概念层类图时很少考虑或不考虑实现问题，因此概念层类图应独立于具体的编程语言。下面是一个概念层类的表示。

说明层类图。此时我们考察的是类的接口部分，而不是实现部分。这个接口可能因为实现环境、运行特性等有多种不同的实现。下面是一个说明层类的表示。

实现层类图才真正考虑类的实现问题，提供实现的细节。此时的类的概念才应该是真正的严格意义上的类。它揭示了软件实体的构成情况。实现层的类是最常用的，在很多的时候说明层的类更有助于人们对软件的理解。

UML的最终目标是识别出所有必须的类，并分析这些类之间的关系，类的识别贯穿于整个建模过程，分析阶段主要识别问题域相关的类，在设计阶段需要加入一些反映设计思想、方法的类以及实现问题域所需要的类，在编码实现阶段，因为语言的特点，可能需要加入一些其他的类。

建立类图的步骤：

（1）研究分析问题领域确定系统需求。

（2）确定类，明确类的含义和职责、确定属性和操作。

（3）确定类之间的关系。

类的识别是一个需要大量技巧的工作，寻找类的一些技巧包括：名词识别法；根据用例描述确定类；使用CRC分析法；根据边界类、控制类、实体类的划分来帮助分析系统中的类；参考设计模式确定类；对领域进行分析或利用已有领域分析结果得到类；利用RUP中如何在分析和设计中寻找类的步骤。

1.       名词识别法：

这种方法的关键是识别系统问题域中的实体。对系统进行描述，描述应该使用问题域中的概念和命名，从系统描述中标识名词及名词短语，其中的名词往往可以标识为对象，复数名词往往可以标识为类。

2.       从用例中识别类：

用例图实质上是一种系统描述的形式，自然可以根据用例描述来识别类。针对各个用例，可以提如下的问题辅助识别：

用例描述中出现了那些实体？

用例的完成需要哪些实体合作？

用例执行过程中会产生并存储哪些信息？…