| Enterprise
Architect（以下简称EA）是一款基于OMG UML的可视化模型与设计工具，提供了对软件系统的设计和构建、业务流程建模和基于领域建模的支持，被企业和组织不仅应用于对系统的建模，还用于推进模型在整个应用程序开发周期中实现。
在EA工具建模平台上，提供如下常用设计模型：
Business Process 业务流程模型
Requirements 需求分析模型
Use Case 用例模型
Domain Model 领域模型
Class 类设计模型
Database 数据库设计模型
Component 组件模型
Deployment 部署模型
Testing 测试模型
Maintenance 维护模型
Project Management 项目管理模型
User Interface 用户接口模型
对于现阶段我们能用到的最多的就是类设计模型、数据库设计模型、用例设计模型、组件模型和部署模型。我们可以根据自己的需要选择所要创建的模型，当然如果不选或选错了在后期还可以进行更改所以这一步是无关紧要的，本文重点介绍基于类设计模型的时序图设计实践。
序列图主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。很象类图，开发者一般认为序列图只对他们有意义。然而，一个组织的业务人员会发现，序列图显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。除记录组织的当前事件外，一个业务级的序列图能被当作一个需求文件使用，为实现一个未来系统传递需求。在项目的需求阶段，分析师能通过提供一个更加正式层次的表达，把用例带入下一层次。那种情况下，用例常常被细化为一个或者更多的序列图。
组织的技术人员能发现，序列图在记录一个未来系统的行为应该如何表现中，非常有用。在设计阶段，架构师和开发者能使用图，挖掘出系统对象间的交互，这样充实整个系统设计。
序列图的主要用途之一，是把用例表达的需求，转化为进一步、更加正式层次的精细表达。用例常常被细化为一个或者更多的序列图。序列图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互。当把这个系统移交给另一个人或组织时，这个文档很有用。
序列图的主要目的是定义事件序列，产生一些希望的输出。重点不是消息本身，而是消息产生的顺序；不过，大多数序列图会表示一个系统的对象之间传递的什么消息，以及它们发生的顺序。图按照水平和垂直的维度传递信息：垂直维度从上而下表示消息/调用发生的时间序列，而且水平维度从左到右表示消息发送到的对象实例。
本实践软件项目中，已经完成用例模型（图中Use Case Model部分）设计，以“流程全生命周期管理”用例为例进行深入设计。
第一步：在类模型（图中Class Model）中添加包“Add
a Package”，命名为“流程管理”，如下图1所示，建立“流程管理”包，并同时生成“流程管理”用例图。
第二步：打开“流程管理”用例图，画“流程全生命周期管理”用例。
放置序列图的位置跟一般的图形不大一样，并不是放置在特定的"包"（Package）中。通常，序列图是表达对象如何合作，进而来完成某一个用例的任务的，因此，序列图似乎要放在用例当中才合理。所以，我们先到上一步生成“流程管理”用例图中画出需要细化的用例。
图1
第三步：在“流程全生命周期管理”用例里，创建类模型图和时序图，如下图2所示过程：
（1）在“流程全生命周期管理”用例图示中，点击鼠标右键，弹出（2）窗口；
（2）选择“Add”，弹出（3）窗口；
（3）选择“Add Diagram...”。
图2
结果如图3所示，形成“流程全生命周期管理”类图和时序图。
图3
第四步：在类模型图中创建类及其属性（Attributes...）和方法（Operation...）
如下图4所示，拖拽Class到类图（Class Diagram）设计窗口中，双击或右击选择属性，在弹出的对话框中的常规选项卡中添加信息。其中名称“流程模型管理列表”为类名，构造类型可以选择此类是窗体类还是边界类还是业务类、实体类等等，本例中选择为“form”。可见性为类的可见性分别可设为public、private、protected。阶段和版本号根据自己的需要设置。备注为给该类添加的备注说明。选择编译的语言以方便生成源代码。点击详细信息选项卡，可以向类中添加属性、方法及方法的参数和相关说明。
图4
第五步：为类添加属性和方法
图5
第六步：画时序图
在Project Browser窗口中，双击打开“流程全生命周期管理”时序图窗口，Toolbox窗口中有如下组件：
Actor：角色/执行者，通常用于用例场景图中，在描述用户交互时表示当前用户/操作者。
Lifeline：生命线，最常用，例如系统、子系统、岗位角色、模块、类。当画一个序列图的时候，放置生命线符号元件，横跨图的顶部。生命线表示序列中，建模的角色或对象实例。
Boundary、Control、Entity是三种特殊的生命线对象类型，通常一起使用（MVC模式、控制模式）：
Boundary：边界对象，初学者用得少，在MVC模式、控制模式、需求分析过渡到系统设计中用得多些，可用于表示交互界面、子系统。
Control：控制对象，用于表示业务逻辑、分工协调的职责对象，采用控制模式分析设计时用得多。
Entity：实体对象，用于表示需要永久保存或较长生命期的数据对象，例如票据、文件、数据库（通常不直接说数据库等技术实现方式，而说逻辑意义的名称）。
Fragment：片段，表示某一局部序列图单元，例如条件分支、循环、子图或子图链接，后者可用于序列图分层建模。
EndPoint：结束点，表示流程退出、异常退出、子图结束，一般与“Diagram
Gate”搭配使用。
Diagram Gate：图入口，表示进入序列图的一个入口。用于在子序列图中表示是在什么情况下由上一级序列图进来的
（Interaction Relationships）消息：为了显示一个对象（例如，生命线）传递一个消息给另外一个对象，你画一条线指向接收对象，包括一个实心箭头（如果是一个同步调用操作）或一个棍形箭头（如果是一个异步讯号）。消息/方法名字放置在带箭头的线上面。正在被传递给接收对象的消息，表示接收对象的类实现的一个操作/方法。
1、拖拽Actor到图板中，命名为“流程管理者”，再从Project
Browser树形目录中，拖拽“流程模型管理列表”到图板中，形成如下图6所示效果。
图6
或者直接点击工具箱中的生命线（Lifeline）命令，在图上分别添加多个生命线，输入生命线名称后大致调整各个生命线的位置；
2、通过消息来表示图中对象间的互动关系，在图7中，点击工具箱中的消息箭头命令，在一个生命线虚线上按下鼠标左键，拖动到另一个生命线虚线上再松开鼠标左键，然后双击消息线就可以输入消息名称了。
图7
按本案例，先定义出类的顺序，则是选择消息名称，如下图8所示。图中：初始化默认列表（）、流程模型新增（）、选中流程（）等方法，都是在类“流程模型管理列表”定义好的，在这里直接选用。也可以点击按钮“Operations”，现增加。
图8
第七步：序列图分层
使用序列图分层技术可以让一个图不至于太复杂，在不同层次的序列图中表达不同级别的细节。在上图中，双击交互引用框“具体做什么”就能进入子序列图，在子序列图中表达更详细的内容。
操作方法：创建单独的序列图（子序列图，例如下图“流程模型管理列表”时序图），在模型树上将“流程模型管理列表”子序列图节点拖到当前序列图上，在弹出的对话框中选择第一个类型“交互引用框”：
图9
图10
图11
使用UML经验与愿景。
序列图把人当作系统。软件开发的目的就是要改进当前的现实，可能是引进一个新系统，也可能是升级现有的系统。序列图强迫思考动作背后的目的。其中，消息代表责任分配而不是数据流动。
使用EA进行UML建模，是个很好的选择。在实际工作中，首先保证开发完整的用例模型，用以确定需求范围和规划目标；其余的模型，根据工作需求，设计到可以接受的粒度，如果资源允许，则按规范进行设计更好。
在开发时序图时，尽量要逐级精细、深入。反过来，如果编码进行不顺畅，则应再回到时序图开发过程中，逐步求解，再深入剖析，使开发代码尽量简洁、逻辑清晰。
|
