【转】UML造型——使用EA时序图工具的开发实践和经验

来源:互联网 发布:office for mac 账号 编辑:程序博客网 时间:2024/04/27 16:06
    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所看到的。

图中:初始化默认列表()、流程模型新增()、选中流程()等方法,都是在类“流程模型管理列表”定义好的,在这里直接选用。也能够点击button“Operations”。现添加。

        

                                                                                                       图8


        第七步:序列图分层

        使用序列图分层技术能够让一个图不至于太复杂,在不同层次的序列图中表达不同级别的细节。在上图中。双击交互引用框“具体做什么”就能进入子序列图,在子序列图中表达更具体的内容。

        操作方法:创建单独的序列图(子序列图,比例如以下图“流程模型管理列表”时序图)。在模型树上将“流程模型管理列表”子序列图节点拖到当前序列图上,在弹出的对话框中选择第一个类型“交互引用框”:

        

                                                                                                                                                  图9

        完毕链接子时序图操作时,在当前时序图上产生图示。

        终于效果例如以下图10所看到的,点击其所链接的时序图“ref/流程模型管理列表”的图标。则展示出图11,流程模型管理列表内部的时序图,展现其分层逐级深入的效果。

        

                                                                                                                               图10

        

                                                                   图11

        使用UML经验与愿景。

        序列图把人当作系统。

软件开发的目的就是要改进当前的现实,可能是引进一个新系统,也可能是升级现有的系统。序列图强迫思考动作背后的目的。当中,消息代表责任分配而不是数据流动。

        使用EA进行UML建模。是个非常好的选择。在实际工作中,首先保证开发完整的用例模型。用以确定需求范围和规划目标;其余的模型,依据工作需求,设计到能够接受的粒度,假设资源同意,则按规范进行设计更好。

        在开发时序图时。尽量要逐级精细、深入。反过来。假设编码进行不顺畅。则应再回到时序图开发过程中。逐步求解,再深入剖析。使开发代码尽量简洁、逻辑清晰。假设其它目的,故弄玄虚,不在此讨论。

        初次使用EA工具,不足之处在所难免,欢迎反馈讨论。

原创粉丝点击