=====================================================================
如果喜欢，请关注：JellyThink | 思想的果冻
更多原创精彩博文，尽在www.jellythink.com
还可以关注新浪微博：http://weibo.com/u/1887014677
=====================================================================
前言
类图和序列图是UML中最常用的两种Diagram。我将做详细的总结。在许多书中，或者网站中，在介绍一个系统的子系统的设计时，很多时候，都是给出简单的类图来简述构成子系统的类之间的关系。这足以说明类图的重要性。
对类图的基本认识有以下两点：
- 类图是以反映类的结构（属性、操作）以及类之间的关系为主要目的，描述了软件系统的结构，是一种静态建模方法；
- 类图中的类与面向对象语言中的类的概念是对应的，是对现实世界中的事物的抽象。
我们基于以上两点，来对类图进行更详细的学习。
类图中基本语法学习
在UML中，画每一种图，都有一套规范的，不同的符号是不同的意义，我们要熟悉这些符号的意义，才能理解一副类图的意义。
先来一副画好的类图，从解析这个类图开始：
如图，这是一副很简单的类图，很简单，也很熟悉。
可以看到，这个类图，从上到下分为三部分。是的，一般类图从上到下分为三部分，分别是：
- 类名
- 属性
- 操作
正如你所看到的，上面类图的名称是Student，属性有Name, Sex, Age, 对应的操作有六个。你应该知道一个类图的Student是必须存在的，而属性和操作是可选的。如果，你看到了一个没有任何属性和操作的类时，也不要感到惊讶，那是正确，虽然不是很正常。
类的名字没有什么好说的，那么，我从属性开始，例如以下属性：
- Name:String
如果你看过Objective-C，你也许就不会感到惊讶，为什么有减号和加号了，但是，伙计，这里的减号和加号和Objective-C中的意思是完全不同的。
这里的加号和减号表示的是属性和方法的可访问性，有如下定义：
- -表示private
- +表示public
- #表示protected
Name表示的是属性的名称，而它后面的String表示的是这个属性的类型；
那么现在对于- Name:String就好理解了；它表示Student类中定义的一个私有的String类型的属性Name；而对于图中这样的一个特例：
- Age:int=10
在这里，int=10，表示的Age属性的默认值为10。
最下面是类的操作，“+”的意思，已经解释过了。我选取以下的一个操作进行详细讲解：
+ SetAge(Age:int):void
操作名为SetAge，参数为int类型的Age，操作的返回值为void。有的时候，我们会遇到以下的这种语法：
+ SetAge(in Age:int):void
是的，多了一个in关键字，这个关键字表示这个Age参数是输入参数，如果看过C#的话，理解其中的out关键字，我想in就不用我多讲了。
抽象类
看下面这个图：
你会发现类名和Eat方法是以斜体字体表示的；在类图中以斜体表示也是有特殊意义的，上图表示Animal是一个抽象类，抽象类是不能实例化的，一般至少包含一个抽象操作，比如上图的Eat就是抽象操作。
接口
看下图这个图：
这是接口的表示方法。接口是什么，不用做什么解释。这里让大家对接口图有一个大体的了解。
类图之间的关系
对于类图的基本讲解就到这里了，接下来讲解类图中最重要的一部分，也是比较难理解的一部分：类图之间的关系。
一个负责的系统，每个类不是独立存在的，而是类与类组织起来的，而每个类之间的关系是错综复杂的，那么UML是如何表达其中的关系的呢？
继承关系
继承关系是一种基本而重要的关系；至于继承的概念，我就不做解释了，而只讲UML中对继承的表示。
以上两张图，都是Astah中对继承关系的表示方法，继承通过指向超类的一条闭合的，单箭头的实线表示。这个表示和用例图中的泛化表示方式是一致的，不熟悉的朋友，可以去看看UML用例图总结这篇文章。
关联关系
当系统建模时，特定的对象间会彼此关联，而且这些关联本身需要被清晰地建模，这里我会介绍5中关联，关于什么时候使用哪种关联，这里是不做介绍的，这里而是将重点集中在每种关联的用途，并说明如何在类图上表现出来。
双向的关联
关联是两个类之间的连接，关联总是被假定是双向；这说明，两个类彼此知道它们之间的关系，都可以调用对方的公共属性和方法；虽然在分析阶段这种关系是适用的，但我觉得对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针；对象引用本身就是有向的。这种关系在设计的时候比较少用到，关联一般都是有向的。
单向关联
在一个单向关联中，两个类是相关的，但是只有一个类知道这种关系的存在。如下图：
一个单向的关联，表示为一条带有指向已知类的开放箭头的实线。Class0知道Class1的存在，而Class1不知道Class0的存在，Class0可以调用Class1的公共属性和方法。使用Astah导出代码时，单向关联体现为Class0中包含一个Class1对象。
关联类
这个概念有点不好理解，我也是参考别人的理解，再做出自己的理解，如下图：
Person和Company是有关系的，存在什么关系？存在一个雇佣的关系，由于存在一个Job，导致Person和Company产生了关系，但是在建模时，由于Job将Person和Company关联到了一起，而描述Job的Salay放在Person或者Company都不是很合适的，由于不同的岗位有不同的Salary，如果将岗位和Salary放在Person，将导致Person类存在很高的耦合性。所以关联出一个关联类Job，表示岗位信息。从图中可以看出，Job类即是一个关联关系也是一个类，是为了描述类Person与类Company之间的关联关系的。
聚合
聚合是一种特别类型的关联，用于描述“总体到局部”的关系。
基本聚合
在基本聚合中，部分类的生命周期独立于整体类的生命周期；如下图：
房子是一个整体实体，而窗户是房子的一部分，而窗户可以在建房子之前就创建，在这里，Window实例清楚地独立地Car类实例而存在。使用空心的菱形表示。
组合聚合
组合聚合也叫包容，但是子类实例的生命周期依赖于父类实例的生命周期；如下图：
公司是一个整体实体，公司包含部门，部门不能独立于公司而存在。使用实心菱形表示。
自身关联（反射关联）
就是自身关联自身，你可能想不到这样存在的意义，但是，你要想到，类可以是抽象的，当一个类关联到它本身时，这并不意味着类的实例与它本身相关，而是类的一个实例与类的另一个实例相关，可以表现为多肽，在UML中就是如下图所示：
实现接口
如下图：
在UML中表示的很简单，就是将泛化中的实线变成了虚线就好了。
总结
这篇文章大体的对UML类图做了一个总结，平时工作中涉及到的内容都大体上做了介绍，如果有什么遗漏，请大家指出。同时，在本文中所有的类图都是使用Astah画的，关于使用Astah画类图，大家可以参考：UML工具Astah的使用。
附录
多重值和它们的表示
| 表示 | 含义 |
| 0..1 | 0个或1个 |
| 1 | 只能1个 |
| 0..* | 0个或多个 |
| * | 0个或多个 |
| 1..* | 1个或多个 |
| 3 | 只能3个 |
| 0..5 | 0到5个 |
| 5..15 | 5到15个 |
2013/6/30 于东软大连
2013/6/30 于东软大连
=====================================================================
如果喜欢，请关注：JellyThink | 思想的果冻
更多原创精彩博文，尽在www.jellythink.com
还可以关注新浪微博：http://weibo.com/u/1887014677
===============================================
前言
在我的工作中，用的最多的就是时序图了。可能由于工作的原因，我也是最喜欢画时序图了，很清楚，很明了，什么时候发送什么消息，到达什么状态，一下子就展示在你的脑海里，对于消息驱动的程序来说，是再好不过的了。
时序图简介
首先，时序图用来表示用例中的行为顺序，当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或者状态机中引起转换的事件；
其次，时序图展示对象之间的交互，这些交互是指在场景或用例的事件流中发生的。时序图属于动态建模；
最后，时序图的重点在消息序列上，也就是说，描述消息是如何在对象间发送和接收的。表示了对象之间传递消息的时间顺序。
还有，别忘了，浏览时序图的方法是，从上到下查看对象间交换的消息。
时序图中的元素
时序图中包括的建模元素主要有：角色、对象、生命线、控制焦点、消息和Combined Fragments。接下来，分别介绍每一个元素，以及展现它们在Astah中的表现形式。
角色
如下图：
图中的小人，就表示一个角色，这里的角色，可以是人，或者是其它的子系统或者系统。
对象
如下图：
每条生命线上都关联着一个对象，上图中有三条生命线，可以看到有三个对象，但是三个对象的命名方式都是不一样的。在使用Astah画时序图时，选择一个对象，在属性中可以更改这种命名，分别介绍一下这三种命名方式：
- 显示实例名和类名，方式：实例名:类名；
- 只显示类名，方式：:类名；
- 只显示实例名，方式：实例名。
其实，三种命名方式，没有特别的要求，哪一种能让阅读该时序图的人一眼就能看明白，就使用哪种，而我一般使用的是第一种和第二种，第一种信息量多，在单例时，可以用来表示；第二种，画时序图时不用刻意的去强调实例名，只需要作出类名就好了；但是，第三种，我一直不知道存在的意义，给你一个实例名，其实从图中真的看不出其的类名。所以，我个人还是建议大家使用第一种和第二种。
生命线
没有什么多说的，从上面的两张图中，我们都可以看到一条向下延伸的虚线，而这条虚线就是表示的生命线，表示一个对象存在的时间。
控制焦点
控制焦点是顺序图中表示时间段的符号，在这个时间段内对象将执行相应的操作。用小矩形表示。如下图表示：
消息
消息一般分为同步消息、异步消息和返回消息；如下图表示。
同步消息就是指消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息的接收者放弃或者返回控制。用来表示同步的意义。
异步消息就是指消息发送者通过消息把信号传递给消息的接收者，然后自己继续活动，不等待接收者返回消息或者控制。异步消息的接收者和发送者是并发工作的。
返回消息就是指消息从过程调用返回。
自关联消息
表示方法的自身调用以及一个对象内的一个方法调用另外一个方法，如下图：
Combined Fragments
表示带有一些特定条件发送的消息。
http://images.cnitblog.com/blog/405273/201307/06155657-732b73868c65429f8fba164931377107.png
如上图，就表示，循环（loop）发送GetProperty消息获得属性。在使用Astah画时序图时，选择一个Combined Fragments之后，可以在其对应的属性面板更改对应的发送条件。里面介绍了很多，此处列举一二：
- Alternative fragment（denoted “alt”） 与 if…then…else对应
- Option fragment (denoted “opt”) 与 Switch对应
- Parallel fragment (denoted “par”) 表示同时发生
- Loop fragment(denoted “loop”) 与 for 或者 Foreach对应
总结
关于时序图，就到此为止，讲的不深，主要是一些关于时序图的概念，没有涉及到应用，以及实际案例的分析，总是觉得缺点什么，是吧。没有关系，大家可以参考这里：这里。我的这篇博文中的很多内容也是参考这里的。希望大家满意。也希望大家有所收获，下一篇博文再见。
2013/7/6 于东软-大连
=====================================================================
如果喜欢，请关注：JellyThink | 思想的果冻
更多原创精彩博文，尽在www.jellythink.com
还可以关注新浪微博：http://weibo.com/u/1887014677
=====================================================================
=====================================================================
如果喜欢，请关注：JellyThink | 思想的果冻
更多原创精彩博文，尽在www.jellythink.com
还可以关注新浪微博：http://weibo.com/u/1887014677
=====================================================================
前言
用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示一个外部用户能够观察到的系统功能模型图。用例图多用于静态建模阶段（主要是业务建模和需求建模），帮助开发团队以一种可视化的方式理解系统的功能需求。下面将从各个部分来分析和理解用例图。
参与者（Actor）
在系统外部与系统直接交互的人或事物；需要注意以下两点：
- 参与者是角色而不是具体的人，它代表了参与者在与系统打交道的过程中所扮演的角色。所以在系统的实际运作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者的不同实例。
- 参与者作为外部用户（而不是内部）与系统发生交互作用，是它的主要特征。
在UML中，参与者使用如图所示的一个小人表示：
用例（Use Case）
系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用椭圆表示，椭圆中的文字简述系统的功能：
子系统（Subsystem）
用来展示系统的一部分功能，这部分功能联系紧密。
关系（Relationship）
用例图中涉及的关系有：
- 关联
- 泛化
- 包含
- 扩展
关联（Association）
表示参与者与用例之间的交互，通信途径，任何一方都可发送或接受消息。
箭头指向：指向消息接收方。
泛化（Inheritance）
在编程中，泛化关系是一种很重要的关系，我们随处可见。
泛化关系是一般和特殊关系，就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
箭头指向（需要特别注意）：指向父用例。
包含（Include）
包含关系用来把一个较复杂用例所表示功能分解成较小的步骤。包含用例是必须的，如果缺少包含用例，基用例就不完整；包含用例必须被执行。
箭头指向：指向分解出来的功能用例。
扩展（Extend）
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性。
箭头指向（需要特别注意）：指向基用例
下图提供一个完整的系统的用例图，让大家有一个感官上的全面认识。
总结
用例图虽然作为UML中的一部分，给团队成员提供一种形象的系统表述，但是，用例图也由它本身的缺陷，用例图一般在需求分析阶段就给出了，有的时候对于系统的需求，并不能很好的表述，对于没有UML背景的人来说，更是一种痛苦与折磨，但是，话又说回来，作为软件开发人员，没有UML背景是说不过去的；有的时候，我们需要借助用例图对客户讲解系统，而让客户去理解用例图则是很困难的。
虽然，在用例图中的关系种类不是很多，也不是很复杂，但是UML的表示确实很让人费解的，别的还好，特别是扩展（Extend）和包含（Include），表示方式都一样的，仅靠上面的说明来进行区分，在一个复杂的系统中，是很容易看错的，从而理解出错，同时，扩展（Extend）中的箭头指向一直是让我很费解的，为什么需要让箭头指向基用例呢？
鉴于用例图有的时候并不能清楚地表达功能需求，开发中大家通常用用例描述表来补充某些不易表达的用例，请大家参考下图：
2013/6/15 于东软-大连
=====================================================================
如果喜欢，请关注：JellyThink | 思想的果冻
更多原创精彩博文，尽在www.jellythink.com
还可以关注新浪微博：http://weibo.com/u/1887014677
=====================================================================