UML了解
为什么说工程开发交流的语言是UML
简单的图形是不精确的
自然语言的描述是不精确的
沟通需要一门语言
工程化的过程我们需要用的不是容易引起歧义的自然语言，而是严谨统一的模型化语言即UML
UML让我们用一种语言，相同的方式进行交流
作计划，做需求，我们不用中文，而用UML
UML我们用它的三个方面：草图、蓝图、代码设计图
学好UML和看图说话的道理是一样的，记住两个要素：节点和联系
UML图形架构分三大类：
对象：类图、组件图、部署图
交互(行为)：用例图、时序图、协作图、活动图
状态：状态图
我们的世界是三维立体的，我们需要从三个方向观察物体，才能有一个较好的理解。所以我们应该学会从三个角度用UML来描述软件。
可以通过三张图来描述：用例、类图、时序图(或活动图)
UML入门
用例图
用例(Use Case)是帮助角色确定系统使用情况的UML组件
用例组(UseCase Group)就是从用户的角度出发对如何使用系统的描述
用例图(Use Case Diagram)是用图形的方式来描述场景
用例在最早是以表的形式展示，简称用例卡片
用例图要素：参与者(主，附加，后台)、假设条件、前置条件、场景中的步骤、后置条件
在StarUml中用例图的元素：包(Package)、用例(UseCase)、角色(Actor)、关联(Association)、定向关联(DirectedAssociation)、泛化(Generalization)、依赖(Dependency)、包含(Include)、扩展(Extend)、系统边界(System Boundary)
Package主要用来分类、模块、子模块
用例是实际描述的一个具体动作，一般用动宾短语
Association、DirectedAssociation关联就是陈述性语句，如小张喝水
Generalization就是继承
依赖、包含、扩展类似
系统边界就是划分模块区间
用例图的作用
用例图用来描述需求场景
在与用户交流过程中快速建立用户业务描述，并且跟用户确认
设计好的用例图用来检验程序实现场景
用例图示例：
用例图相关疑问
为何一定要使用用例图概念，把用户的需求描述记录下来不可以么
这样做在实际中往往行不通。对于用户的描述，我们往往要用一种结构组织起来，用例就提供了这种组织结构。在记录客户的交谈结果以及将这些结果与开发者沟通的时候，这些结构尤为重要
我们和客户交谈的时候，我们所做的仅限于他们告诉我们的用例么
当然不是，事实上要搞清楚客户告诉了你什么，还要发掘客户没有告诉你什么
获取用例的难度有多大
列出系统的用例一点也不难，但在深入研究每个用例，并且让用户列出每个场景的步骤的时候，会需要经验和技巧
在高层用例图中，并没有显示出参与者和用例之间的关联，这是为什么
高层用例图出现在与用户会谈的早期阶段，这个阶段它仍然是一个考虑不成熟的产物，其主要目标是找出系统的总体需求及系统的边界和范围，因此暂时不需要关联
我们需要画UML大图么仅仅知道每种类型的图什么时候使用还不够么
如果你理解了UML的组织结构，即使遇到前所未遇的问题你也能处理，你可以重新组织UML元素以便适应工作需要
针对商场购物画用例图
状态图
状态图就是开关，是描述状态变化的图形
状态图描述了一个对象状态与状态的转变并且给出了状态变化序列的起点和终点
状态图元素：状态节点(Composite State)、状态子节点(Submachine State)、初始状态(Initial State)、结束状态(Final State)、交汇点(junction->一个口多输入输出)、选择点(Choice->单输入输出)、浅层历史状态(Shallow History)、深层历史状态(Depp History)、同步(Fork)、对象流程结束(Exit Point)、状态传递(Transition)、自我传递(Self Transition->入口动作、出口动作，中间动作)
状态图相关疑问
什么时候会用到状态图：需求过程，需要描述一个对象的状态跟踪的时候，比如一个表单在不同环境审批的状态
开始建立状态图的最好方法：首先列出对象状态，然后将注意力集中在状态的转移上。当研究每个转移的时候，要估计是否触发事件或者执行某个动作
状态图是否必须有终止状态：不一定，有的状态永远是活动的
状态图的部图技巧：图要清晰，回避交叉点
状态图示例：
时序图
时序图是描述一个时间段的不同角色之间的业务情况
我们通常用时序图来画出流程，时序图和协作图是类似的，掌握一种即可
时序图元素：对象(Lifeline)、对象消息传递(Message)、自我消息传递(Self Message)、组合碎片(CombinedFragment)、交互操作(Interaction Use)、框架(Frame)
时序图多做分析图：业务流程的分析图和程序调用的分析图
时序图相关疑问
我们在哪用时序图：
需求阶段-分析按照时间关系的流程的时候
设计阶段-分析程序之间调用的时候
时序图不仅可以用于系统分析，还可以用来说明一个组织中各种交互关系。把组织中的重要角色标志为对象，对象之间的消息就标识了角色的控制转移
时序图示例：
协作图
协作图与时序图类似，协作图也是展现对象交互的图形
协作图和时序图的异同
同：协作图和时序图是语义等价的
异
协作图强调的是交互语境和参与交互的对象整体组织
时序图强调的是交互时间顺序
协作图和时序图可互转
协作图相关疑问
在UML建模时有需要包含时序图和协作图两种图吗
两种图包含是个好主意。时序图重在表示时间关系，协作图重在描述对象之间的关系。不过二图取其一也可以，因为它们语义相同，可以借助工具自动互转
协作图示例：
活动图
活动图用来描述一个过程或者操作的工作步骤，类似于流程图
活动图元素：动作状态(Action)、子活状态(StructuredActivity)、开始状态(inital)、结束状态(Final)、同步(fork)、选择(Decision)、流程结束(Flow Final)、对象流程(Object Node)、接收状态(Accpet Signal)、发送状态(Send Signal)、状态传递(Control Flow)、自我传递(Control Flow)、垂直泳道(Swimlane)、水平泳道(Swimlane)
活动图相关疑问
活动图的必要与否
活动图就是用来描述流程的。活动图能表现多个对象之间的复杂活动关系，比时序图更有表现力。如收录系统的流程图时序图就表现不出来。我们在选择时优先选择时序图，时序图做不到的用活动图。
活动图示例
类图
复杂的类图
类图是用来描述对象及对象之间关系的图
类图在需求阶段和设计阶段有不同的含义
需求阶段类图可以看做对象图
MDA模型驱动的基础就是对象
类图用来描述实体对象的，和用例图同等重要
类图和设计的关系，类图和数据库的关系
类图元素：子系统(Subsystem)、包(Package)、类(Calss)、接口(interface)、枚举(Enumeration)、信号(Signal)、异常(Signal)、端口(Port)、局部(part)、关联(Association)、定向关联(Directed Association)、聚合(Aggregation)、组合(Composition)、泛化(Generalization)、依赖等关系(Dependency)、实现(Realization)、关系类(AssociationClass)、连接(Connector)、对象(Object)、链接(Link)
聚合是空心组合是实心，组合是同生共死的，聚合如公司的组成，组合如房屋的组成
泛化就是继承
依赖在类中会有创建被依赖类的方法。如公司类依赖用户管理类
关联类是中间关系类
关联就好比公司和员工的关系，链接就好比我们公司和我的关系
类图相关疑问
不是程序员需要类图么：有必要，类图其实是描述实体的对象图。虽然它的类、接口、实现等特性在其它场景用不上。但是它们的属性，操作等来描述对象是最清晰的。
聚合具有传递性
类图的作用
需求阶段定义对象属性
定义数据库关系
设计阶段定义包、类结构和关系
组件图
软件组件可以是软件系统的一个物理单元、数据文件、表格、可执行文件、动态链接库等；这些都被定义为组件。
定义系统组件，接口及关系的图就是组件图
组件元素：接口(interface)、组件(Component)、组件实例(Component instance)、工件(Artifact)、端口(port)、部分(part)、关联(Association)、依赖(Dependency)、实现(Realization)、链接(Link)、连接器(Connector)
组件图示例：
部署图
部署图反应了工件如何在系统硬件上发布
剪贴画可以和UML混用，来表达更明确的图例
部署图示例：
案例展示
移动点菜系统
设计四要素
项目前提和评估
模块子模块,功能子功能
具体用例
界面原型
需求成文示例
网友评论