UML与业务建模-C

UML与业务建模中程在线咨询培训师CSAI软件工程首席顾问徐锋xf@csai.cnxuf@miiceic.org.cn.AgendaUML背景与基础UML的组成常用UML模型基础RUP的UML业务建模法.AgendaUML背景与基础UML的组成常用UML模型基础RUP的UML业务建模法.模型是对现实的简化.建模的目的与原则建模目的：帮助我们按照实际情况或按我们需要的样式对系统进行可视化；提供一种详细说明系统的结构或行为的方法；给出一个指导系统构造的模板；对我们所做出的决策进行文档化仅当需要模型时，才构建它选择要创建什么模型对如何动手解决问和如何形成解决有着意义深远的影响；每一种模型可以在不同的精度级别上表示；最好的模型是与现实相联系的；单个模型是不充分的。对每个重要的系统最好用一组几乎独立的模型去处理。.UML发展历程.UML特性与发展现状UML是一种Language（语言）UML是一种Modeling（建模）LanguageUML是Unified（统一）ModelingLanguage已进入全面应用阶段的事实应用领域正在逐渐扩展，包括嵌入式系统建模、业务建模、流程建模等多个领域成为“产生式编程”的重要支持技术：MDA、可执行UML等.为什么使用UML建模UML是一种统一的、标准化的建模语言UML是一种应用面很广泛的建模语言.草图和蓝图蓝图一般是指采用CASE工具绘制的、正式的、规范的UML模型草图则通常是指手工绘制的、规范度较低的在纸张的UML模型大胆地绘制草图，尽可能基于草图进行讨论。对于局部的、重要性不高的、共享范围较小的UML模型，直接将草图扫描到电脑存档即可；对于全局的、重要性高的、高度共享的，在草图的基础上用CASE工具绘制成为正式的蓝图，并将其纳入统一的模型管理中.谁应该建模业务建模：以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与需求模型：以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和资深开发人员参与设计模型：高层设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发人员从技术实现方面提供支持。详细设计模型则以资深开发人员为主，架构师提供指导。实现模型：以资深开发人员（设计人员）为主，架构师提供总体指导。数据库模型：以数据库开发人员为主，架构师提供指导，资深开发人员（设计人员）予以配合。.常见认识误区UML是一种方法论UML就是一堆图形UML只能够应用于面向对象开发中UML就是Rose里的符号UML的学习周期很长、很复杂.AgendaUML背景与基础UML的组成常用UML模型基础RUP的UML业务建模法.UML的组成基本构造块：也就是建模元素，是模型的主体UML规则：也就是支配基本构造块如何放在一起的规则公共机制：运用于整个UML模型中的公共机制、扩展机制.事物构造块事物构造块是对模型中最具有代表性的成分的抽象结构事物：UML中的名词，它是模型的静态部分，描述概念或物理元素。行为事物：UML中的动词，它是模型中的动态部分，是一种跨越时间、空间的行为。分组事物：UML中的容器，用来组织模型，使模型更加的结构化。注释事务：UML中的解释部分，和代码中的注释语句一样，是用来描述模型的。.面向对象视角下的世界首先建立反应现实世界中不同事物的“构造块”，然后确定“构造块”之间的“关系”，再确定各个构造块的“属性”和“行为”。这样，在软件系统中就可以模拟现实世界的“构造块”之间的交互与协作面向对象软件开发的核心思想就是高内聚(封装)、低耦合(消息驱动)，使用简洁的接口拼合简单部件.结构事物类（class）和对象（object）接口（interface）主动类（activeclass）用例（usecase）协作（collaboration）构件（component）节点（node）.类和对象类是对一组具有相同属性、相同操作、相同关系和相同语义的对象的抽象UML中类是用一个矩形表示的，它包含三个区域，最上面是类名、中间是类的属性、最下面是类的方法对象则是类的一个实例.接口接口是描述某个类或构件的一个服务操作集.主动类主动类实际上是一种特殊的类。引用它的原因，实际上是在开发中需要有一些类能够起到启动控制活动的作用主动类是指其对象至少拥有一个进程或线程，能够启动控制活动的类.用例与协作用例是著名的大师IvarJacobson首先提出的，现已经成为了面向对象软件开发中一个需求分析的最常用工具用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。协作定义了一个交互，它是由一组共同工作以提供某协作行为的角色和其他元素构成的一个群体。对于某个用例的实现就可以表示为一个协作.构件在实际的软件系统中，有许多要比“类”更大的实体，例如一个COM组件、一个DLL文件、一个JavaBeans、一个执行文件等等。为了更好地对在UML模型中对它们进行表示，就引入了构件（也译为组件）构件是系统设计的一个模块化部分，它隐藏了内部的实现，对外提供了一组外部接口。在系统中满足相同接口的组件可以自由地替换.节点为了能够有效地对部署的结构进行建模，UML引入了节点这一概念，它可以用来描述实际的PC机、打印机、服务器等软件运行的基础硬件节点是运行时存在的物理元素，它表示了一种可计算的资源，通常至少有存储空间和处理能力.行为事物交互（interaction）：是在特定语境中，共同完成某个任务的一组对象之间交换的信息集合交互的表示法很简单，就是一条有向直线，并在上面标有操作名状态机（statemachine）：是一个对象或交互在生命周期内响应事件所经历的状态序列在UML模型中将状态画为一个圆角矩形，并在矩形内写出状态名称及其子状态.分组事物对于一个中大型的软件系统而言，通常会包含大量的类，因此也就会存在大量的结构事物、行为事物，为了能够更加有效地对其进行整合，生成或简或繁、或宏观或微观的模型，就需要对其进行分组。在UML中，提供了“包（Package）”来完成这一目标.注释事物结构事物是模型的主要构造块，行为事物则是补充了模型中的动态部分，分组事物而是用来更好地组织模型，似乎已经很完整了。而注释事物则是用来锦上添花的，它是用来在UML模型上添加适当的解释部分.关系构造块—关联关系关联（Association）表示两个类之间存在某种语义上的联系。关联关系提供了通信的路径，它是所有关系中最通用、语义最弱的。在UML中，使用一条实线来表示关联关系在关联关系中有两种比较特殊的关系：聚合和组合聚合关系：聚合（Aggregation）是一种特殊形式的关联。聚合表示类间的关系是整体与部分的关系如果发现“部分”类的存在，是完全依赖于“整体”类的，那么就应该使用“组合”关系来描述.关系构造块—其他关系泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。实现关系是用来规定接口和实现接口的类或组件之间的关系。接口是操作的集合，这些操作用于规定类或组件的服务。扩展表示将一个构造型附加到一个元类上，使得元类的定义中包括这个构造型。有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X。.UML规则命名：也就是为事物、关系和图起名字。和任何语言一样，名字都是一个标识符范围：与类的作用域相似，包括所有者作用域和目标作用域两类可见性：.公共机制—规格描述在图形表示法的每个部分后面都有一个规格描述（也称为详述），它用来对构造块的语法和语义进行文字叙述。这种构思，也就使可视化视图和文字视图的分离：.公共机制—UML修饰与通用划分在为了更好的表示这些细节，UML中还提供了一些修饰符号，例如不同可视性的符号、用斜体字表示抽象类UML通用划分：1）类与对象的划分：类是一种抽象，对象是一个具体的实例2）接口与实现的分离：接口是一种声明、是一个契约，也是服务的入口；实现则是负责实施接口提供的契约.UML扩展机制构造型：在实际的建模过程中，可能会需要定义一些特定于某个领域或某个系统的构造块.UML扩展机制标记值：则是用来为事物添加新特性的。标记值的表示方法是用形如“{标记信息}”的字符串约束：是用来增加新的语义或改变已存在规则的一种机制（自由文本和OCL两种表示法）。约束的表示法和标记值法类似，都是使用花括号括起来的串来表示，不过它是不能够放在元素中的，而是放在相关的元素附近.UML定义的图.UML视图和图.UML图形分类.4+1视图.4+1视图用例视图：它是最基本的需求分析模型，是可被最终用户看到的系统行为的用例组成。常用的模型包括用例图、交互图、状态图、活动图等。设计视图：又称为逻辑视图，以问题域的语汇组成的类和对象集合，用来描述类、接口、协作。常用的模型包括类图、交互图、状态图、活动图等。进程视图：形成系统并发与同步机制的线程和进程，也就是将可执行线程和进程作为活动类的建模，可理解为设计视图的一次执行实例。它使用的模型与设计视图类似，区别在于更侧重于主动类。.4+1视图实现视图：对组成基于系统的物理代码的文件和组件进行建模，即装配与发布物理系统的构件和文件。常用的模型包括构件图、交互图、状态图、活动图。部署视图：包含了形成系统硬件拓扑结构的节点，也就是描述组件是如何物理地部署到一组物理的、可计算节点上的。常用的模型包括部署图、交互图、状态图、活动图。.开发过程.练习题如果你想对一个类的用途进行简要描述，那么应该采用？请简要说明原因。A.标记值B.规格描述C.注释D.构造型请列举出三个以上UML中的事物构造块。说说适合用来表示“系统向用户提供的功能”的构造块是什么适用于模型管理的是哪张图？下图所示的符号表示的是什么？它是关系构造块还是事物构造块？.AgendaUML背景与基础UML的组成常用UML模型基础RUP的UML业务建模法.3.1类图.理解面向对象思想.理解面向对象思想每个对象都扮演了一个角色，并为其它成员提供特定的服务或执行特定的行为。在面向对象世界中，行为的启动是通过将“消息”传递给对此行为负责的对象来完成的；同时还将伴随着执行要求附上相关的信息（参数）；而收到该消息的对象则会执行相应的“方法”来实现需求用类和对象表示现实世界，用消息和方法来模拟现实世界的核心思想.如何用UML表示一个类名称：每个类都有一个惟一的名称，通常采用CamelCase格式表示属性：是已被命名的类的特性，它描述该类实例中包含的信息操作：是类所提供的服务，它可以由类的任何对象请求以影响其行为属性名和操作名也通常采用CamelCase格式表示，只不过首字母通常为小写。.如何阅读类图先看清有哪些类，然后看看类之间存在的关系，并结合多重性来理解类图的结构特点以及各个属性和方法的含义.读图过程读出类：图中共有7个类，Order、OrderItem、Customer、Consignee、DeliverOrder、Peddlery、Prodcut读出关系：从图中关系最复杂（也就是线最密集）的类开始阅读，本图中最复杂的就是Order类。1）OrderItem和Order之间是组合关系，根据箭头的方向可知Order包含了OrderItem。2）Order类和Customer、Consignee、DeliverOrder是关联关系。也就是说，一个订单和客户、收货人、送货单是相关的。.读图过程多重性：用来说明关联的两个类之间的数量关系.读图过程—理解方法和图Order类，有两个方法：dispatch()和close()，从名字中可以猜出它们分别实现“分拆订单生成送货单”和“完成订单”。而在DeliveOrder()类中则有一个Close()方法，同理它应该表示“完成送货”。而在OrderItem中有一个stateChange()方法和deliverState，不难猜出它就是用来改变其“是否交给收货人”标志位的.读图过程—理解方法和图先调用Order的dispatch()方法，它将根据其包含的OrderItem中产品信息，来按供应商户分拆成若干个DeliverOrder。商户登录系统后就可以获取其DeliverOrder，并在执行完后调用close()方法。这时，就将调用OrderItem的stateChange()方法来改为其状态。同时再调用Order的close()方法，判断该Order的所有的OrderItem是否都已经送到了，如果是就将其真正close()掉.使用了更多建模元素的类图.辅助建模符号导航箭号：类的实例之间只能沿着导航箭头的方向传递，在Order中可以获取其相应的Consignee，而从Consignee中是无法了解与其相关的Order的角色名称：Customer端有一个“+Owner”字符串，这表示Customer扮演的角色是Owner，也能对关联进行命名.辅助建模符号导出属性：是指可以根据其他值计算出来的特性，这种属性应在其名称前加上一个“/”符号。限定符：在Order和OrderItem之间的组合关系中，OrderItem这端多了个方框，写着“ProductId”。在UML中称为限定符，存在限定符的关联称为受限关联。它用来表示某种限定关系。在本例中说明：对于一张订单，每一种产品只能用一个订单项约束：用来说明规则，{xor}…职责：在类的属性栏中添加注释行表示，或增加了一个新的分栏.对象约束语言环境与约束：每个OCL表达式都必须是针对某个元素的，因此在OCL表达式前必须说明它针对元素（这就称为环境）1）“contextObjectinv：”，其中Object是OCL表达式针对的建模元素名称；2）“Object”，其中Object是OCL表达式针对的建模元素名称。当声明了环境之后，就可以用self来引用它的变量.对象约束语言子集约束：一致性：一个客户拥有零个或多个，发票是基于某个合同的，而一个客户将收到零张或多张发票Invoice：self.contract.customer=self.customer.对象约束语言异或关系：规定的取值范围：Rectangle：length>0andwidth>0.用类图表示软件系统模型领域模型是从面向对象视角看待现实世界的结果，也就是通过类图描述现实世界中各种事物的关系。分析模型和领域模型很相近，分析模型主要是针对软件系统，领域模型则更多偏重对业务领域的分析设计模型则是在分析模型的基础上添加设计元素的结果。设计模型中的类的属性集更趋完善。.最常见的域建模错误10立即给关联指定多重度(multiplicity)，确保每个关联都有明确的多重度。类图上的有些关联表示的是一对一的关系，而其他关联表示的是一对多的关系。这两种关系都被称为多重度。然而，不应在域建模期间就确定所有的多重度——这将占用大量的时间，是导致分析瘫痪的主要原因之一.最常见的域建模错误9对名词和动词做过度的分析，而背离初衷。将很可能处于过低的抽象层次上，同时有神经崩溃的危险。可以使用一些技巧来发现对象，但绝不要沉溺其中。.最常见的域建模错误8不对用例和时序图进行研究，就将操作分配给类。我们提倡在域建模过程中使用要求最低的方式。事实上，我们是想告诉您，不应在域建模期间将任何操作分配给类。因为，在项目的该阶段还没有足够的信息，无法就操作做出正确的决策。进入交互建模后，您将拥有足够的信息(至少我们希望如此)。在确保已满足用户需求之前，对代码进行优化以提高重用性。.最常见的域建模错误7对象和类的通用程度越高，在其他项目中重用它们的可能性就越大。一个完整的类在理论上是可以在任意数目的环境(context)中重用的，然而要实现完整性和重用性，必须考虑属性和操作，而前面已经指出了不应在域建模期间将操作分配给类的原因，因此在完成高级类图期间，将过多的精力用于提供类的可重用性是不明智的。应快速完成域建模工作，以便有时间确保您要构建的系统正是客户所需要的。.最常见的域建模错误6对于每个“…一部分(part-of)”关联，就使用聚集还是组合(composition)而争论不休。在UML中，最初描述的“按引用拥有(hasbyreference)”关系是聚集，而“按值拥有(hasbyvalue)”关系是一种被称为组合的“强”形式的聚集，在这种关系中，“部分(piece)”类归父类“所有”：父对象被删除后，其所有的子对象实例将自动被删除。在域建模期间试图区分聚集和组合无疑是费力不讨好的。在域建模期问，我们喜欢使用简单的聚集。使用聚集还是组合是一个详细设计方面的问题。.最常见的域建模错误5未对问题空间进行建模之前，就假定一种具体的实现策略。改进域模型时，应删除所有明显陈述动作而不是持久性的内容以及同实现相关的内容。在高级类图中，不应引入涉及到具体技术的内容，如关系型数据库或特定的服务器。将实现问题留待实现阶段解决，首先对问题域进行建模。.最常见的域建模错误4将类命名为难以理解的名称cPortMgrIntf)，而不是直观的名称(如PortfolioManager)。首先建立域模型的重要原因之一，是促使每个小组成员就关键抽象的名称达成一致。类名越简明，这项任务就越容易。应等到实现时再使用首字母缩写和各种缩略语(如果您一定要这样做).最常见的域建模错误3直接进入到实现结构，如友元关系和参数化类。UML提供了大量将我们称作“解决素材”的东西添加到类图中的机会。这包括直接来自C++的结构，如参数化类和友元关系。这些东西与解决方案空间相关，而与问题空间不相关，因此域建模绝对是属于问题空间的。.最常见的域建模错误2在域类和关系型数据库表之间建立一对一的映射。对使用关系型数据库的遗留系统进行重构时，数据库中的表可能是很好的域类名称来源。然而，决不要将它们完全照搬到静态模型中。关系型表中的很多属性不能照搬到对象模型环境中，应尽可能通过聚集，将属性组转换为“助手(helper)类。这种类包含的属性和操作可被组合成更小的“部分(piecepart)”类。.最常见的域建模错误1过早地执行“模式化”，这将导致根据同用户问题毫无关系的模式创建解决方案。模式通常在健壮性分析时才能发现。有两种策略可用于发现同用例相关的模式：“屏幕控制”和“用例控制器”。设计模式对时序图和设计级类图很有用，但域建模期问不应考虑模式的问题。.练习一下图是一个仓库管理系统的类模型局部，其中IncomeOrder是指入库单，OrderItem是指入库中的每一项，Product则是产品信息。请指出模型中的错误，说明原因并改正错误.练习二在描述“税务审批服务申请”时，它主要包含哪几个方面的内容？它有几种不同的类别?对于每一条流转记录，可能与几个“税务审批服务申请”相关？与几个处理人相关？.练习三.练习四.练习五.练习六.练习七.练习八.练习九：根据下面描述绘制类图这是一个“碟片出租店”使用的系统，它将用于计算每一位顾客的消费金额并打印报表。操作者告诉程序：顾客租了哪些影片、租期多长，程序便根据租凭时间和影片类型算出费用。影片分三类：普通片、儿童片和新片。除了计算费用，还要为常客计算机点数；点数会随着“租片种类是否为新片”而有所不同。.练习十下图是小张绘制的一张关于网上商城用户管理的领域类图，但其中存在一些问题，请指出错误并说明理由.3.2用例图.核心元素：参与者定义：在系统之外，透过系统边界与系统进行有意义交互的任何事物.边界是职责边界，而非物理边界.谁是机票预订系统的执行者.它们都可以是执行者用户维护人员时间系统其他系统.参与者参与者是为了完成一个事件而与系统交互的实体，是用户相对系统而言所演的角色参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是个参与者；2）硬件设备：系统需要与硬件设备交互，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者；3）时钟：系统需要定时触发.用例用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景用例应该给参与者带来可见的价值，这点十分关键.核心元素：用例IvarJacobson在RUP中为用例做出了以下定义用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。步骤目标路径.用例定义：用例描述了执行者（参与者）使用系统实现目标的方式，以及系统为其能够实现该目标而提供的帮助。用例描述了系统及其执行者结合起来向至少一个参与者传递有价值的东西的方式.常见错误用例太细（用例应包括事件流，事件流中应有步骤）把步骤当做用例（如登录输入用户名、验证密码…）把系统活动当用例！特例：新增、删除、查询、修改管理也被戏称为：CRUD（四轮马车）误认为用例的粒度与系统实现的复杂度相关其实很简单，一个用例为执行者提供一个价值.用例要突出涉众的利益找出用例相关的涉众；分析涉众的利益所在；在用例中充分考虑涉众的利益。.用例分析技术的组成用例图：用例描述：前置条件：用户启动该应用系统基本路径：1）系统显示登录界面；2）用户输入用户名和密码；3）系统验证信息；…………可选路径：后置条件：执行者，Actor参与者用例，UseCase参与者：定义了用户在系统交互过程中所扮演的角色，其可以是一个人，也可以是另一个系统。.阅读用例图.用例图的组成元素图中的元素包括：参与者、用例、一个方框和一些表示关系的连接线所有的用例都位于方框之内，这个方框我们称为“系统边界”参与者与用例的关系：在参与者和用例之间的关联是用一根带箭头的线来表示的用例之间的关系：1）包含关系2）扩展关系3）泛化关系.包含与扩展关系被包含的用例（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用例（此例中的预订座位、安排座位）的一部分出现基用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可被另一个用例的行为所扩展.泛化关系可以用来表示参与者与参与者之间，用例与用例之间的特殊/一般化关系.读图小结这张用例图首先定义了三个基用例：预订座位、安排座位和处理结账客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成。.用例描述用例描述的是一个系统做什么（what）的信息，并不说明怎么做（how），怎么做是设计模型的事事件流：.用例描述：前置条件指在用例启动时，参与者与系统应置为何状态；1）系统能到；2）系统在用例开始前能检测到；3）应为“可观测”的前置条件.用例描述：前置条件客户已发出订单----错误工作人员已登录系统----正确库存大于下单数----错误.用例描述：后置条件用例结束时，系统的状态1）系统能检测到；2）应为“可观测”的：只包含可检测的条件，合并影响相同的条件后置条件.用例描述：基本事件流基本事件流是对用例中常规、预期路径的描述（有时被称为Happyday场景），这是大多数用户在大部分时间中所采取的路径。通常体系了系统的核心价值。基本事件流.用例描述：扩展事件流系统还需要进行意外处理扩展事件流.事件流编写要点使用简单的语法：主语明确，语义易于理解明确写出“谁控制球”：通常就是指出参与者；从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是跳开来；显示过程向前推移：也就是每一步都有前进的感觉（例如：用户按下tab键就不够）；显示执行者的意图而非动作（光有动作，让人不容易直接从事件流中理会用例）。.事件流编写要点包括“合理的活动集”（带数据的请求、系统确认、更改内部、返回结果）；“确认”而不是“检查是否”；（如：系统确认用户密码正确，而非系统检查用户密码是否正确）可选择地提及时间限制；习惯用语“用户让系统A与系统B交互”；习惯用语“循环执行步骤x到y，直到条件满足；.用例描述模板.练习一对于一个电子商务网站而言，以下哪些不是合适的用例，指出并说明理由。输入支付信息将商品放入购物车结账预订商品用户登录邮寄商品查看商品详情.练习二本系统主要将实现客户资料信息管理、客户委托（出租、出售、租赁、购买）信息管理、业务线索生成与管理、房源状态自动更新、权限管理、到期用户管理、房源组合查询等功能。但该图不符合“用例建模”思想，请指出并修改。.练习三：会议管理系统有一个对外界开放的会议中心，它拥有若干间不同规格的会议室。使用者可以去该会议中心预订房间召开一个会议或一系列会议，当然用户必须确定开会的时间、日期以及到会的大概人数以确定一个合适规格的会议室。如用户可以申请在某周五下午1:00到3:00召开一个大约100人参加的主题会议。另外，如果用户需要定期召开一个会议（如某种论坛会议，每月开一次），那么用户可以方便地向会议中心一次性地申请几次会议的使用。同时，在任何一个会议开始之前，用户可以修改会议的时间，添加或减少预期到会的人数，直到取消某次会议。确定了一个会议后，用户负责提供与会者的信息给会议中心，会议中心负责进行会务人员的管理，制作会务代表证明并通知每位参加者有关会议的信息。当然，如果会议作了变更（包括取消），会议中心也要通知由用户确定的预定会议的每位参与者。会议中心可以采用电子的方式或寄会议通知的方式通知每位与会者，这要视用户提供给会议中心的每位与会者的联络而定。本系统要求用户首先定义一个会议，然后再根据该会议，要求用户申请相应的时间段内使用的会议室。如果一个会议已经定义（如已经申请过的会议），则用户可以直接根据参加的人员、会议召开的时间来申请一个合适的会议室。另外，系统可以根据会议室的使用情况来更改用户申请使用的时间限制，如最多只能提前一个月预订。同时，允许用户把某些与会人员定义为一个组，这样用户在以后申请时就可以简化操作了。.3.3交互图.四种交互图顺序图：强调消息时间顺序。首先把参与交互的对象放在图的上方，沿X轴方向排列。通常把发起交互的对象放在左边，较下级对象依次放在右边。然后，把这些对象发送和接收的消息沿Y轴方向按时间顺序从上到下放置。读者提供了控制流随着时间推移的清晰的可视化轨迹。协作图：在UML2.0中称为通信图，强调的是参加交互的对象的组织。首先将参加交互的对象作为图的顶点，然后用这些对象之间的边线表示为图的边，再使用对象发送和接收的消息来修饰这些边。为读者提供了在协作对象结构组织的语境中观察控制流的一个清晰的可视化轨迹.四种交互图定时图：采用了一种带数字刻度的时间轴来精确地描述消息的顺序，而不是像顺序图那样只是指定消息的相对顺序。而且它还允许可视化地表示每条生命线的状态变化，当需要对实时事件进行定义时，定时图就可以很好地满足交互概述图：是交互图和活动图的混合物。你可以把交互概述图想像为活动图，只不过其中的活动被换成了一些小型顺序图；也可以把其想像为利用标明控制流的活动图分解过的顺序图.阅读顺序图.读图小结在dispatchForm（分发窗体）中，对于某个已支付的Order进行分发时，就会调用该订单（一个Order类的实例对象aOrder）的dispatch()方法。dispatch()方法将逐个调用该Order对应的所有OrderItem对象的getPeddleryId()方法还获取供应商ID（PeddleryId），而OrderItem对象则是通过其所对应的Product对象来的getPeddleryId()方法来获取供应商ID。.读图小结当Order的实例对象aOrder得到返回的PeddleryId后，根据该值判断是否已经有相对应的DeliverOrder对象，如果没有就创建它（调用create(PeddleryId)），然后再将对应的Product添加到这个DeliverOrder对象中。否则就直接添加到相应的DeliverOrder对象中。.阅读协作(通信)图.交互模型的类型与演变.3.5状态图.状态及状态表示法状态是指在对象生命周期中满足某些条件、执行某些活动或等待某些事件的一个条件和状况一个状态通常包括名称、进入/退出活动、内部转换、子状态和延迟事件等五个部分组成.阅读简单状态图最为核心的元素无外乎是两个：一个是用圆角矩形表示的状态（初态和终态例外）；另一个则是在状态之间的、包含一些文字描述的有向箭头线，这些箭头线称为转换.转换的五要素源状态：即受转换影响的状态目标状态：当转换完成后对象的状态触发事件：用来为转换定义一个事件，包括调用、改变、信号、时间四类事件监护条件：布尔表达式，决定是否激活转换动作：转换激活时的操作.读图小结与状态off相关的转换有两个，其触发事件都是turnOn，只不过其监护条件不同。如果对象收到事件turnOn，那么将判断壶中是否有水；如果[没水]，则仍然处于off状态；如果[有水]则转为on状态，并执行“烧水”动作而与状态on相关的转换也有两个，如果“水开了”就执行turnOff，关掉开关；如果烧坏了，就进入了终态了.复杂转换.阅读带复杂转换的状态图.各种转换的区别进入和退出转换：当进入一个状态时，执行某个动作；或当退出某个状态时，执行什么动作。这时就可以使用进入和退出转换来表示内部转换：用来处理一些不离开该状态的事件.活动与延迟事件活动：当对象处于一个状态时，它一般是空闲的，在等待一个事件的发生。但是某些时间，你可能希望描述个正在进行的活动。在处于一个状态的同时，对象做着某些工作，并一直继续到被某个事件中断。延迟事件：延迟事件是一种特殊的事件，它是指该事件不会触发状态的转换，当对象处于该状态时事件不会丢失，但会被延迟执行。例如，当E-mail程序中正在发送第一封邮件时，用户下达发送第二封邮件执令就会被延迟，但第一封邮件发送完成后，这封邮件就会被发送。这种事件就属于延迟事件。.3.5活动图.活动图概述活动图是一种表述过程机理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模。因此，它的作用和传统的“流程图”是有着很深的渊源，也十分的相似。不过它与流程图的最主要区别在于，活动图能够支持并行的行为在UML的各个版本中，活动图的改变可谓最大，每次UML标准更新时，都对活动图进行了修订。对于UML2.0而言，最大的改变莫过于去除了“活动图是状态图的一种特例”这一规定.阅读简单活动图.活动图主要元素初始节点和活动终点：用一个实心圆表示初始节点，用一个圆圈内加一个实心圆来表示活动终点活动节点：是活动图中最主要的元素之一，它用来表示一个活动转换：当一个活动结束时，控制流就会马上传递给下一个活动节点，在活动图中称之为“转换”，用一条带箭头的直线来表示.活动图主要元素分支与监护条件：分支是用菱形表示的，它有一个进入转换（箭头从外指向分支符号），一个或多个离开转换（箭头从分支符号指向外）。而每个离开转换上都会有一个监护条件，用来表示满足什么条件的时候执行该转换。分岔与汇合：.带泳道的活动图.带对象流的活动图.复杂活动图辅助活动图汇合描述：当汇合的所有入流均到点汇合点时，就将执行汇合点指向的活动节点。但是有些时候，你希望对其做一些约束，这时就可以借助汇合描述来完成。汇合描述实际上是一个约束，其格式就是“{约束条件}”。.复杂活动图发送信号与接收信号.活动图应用说明对工作流建模：用于业务建模的时候，每一条泳道表示一个职责单位，该图能够有效地体现出所有职责单位之间的工作职责，业务范围以及之间的交互关系、信息流程对操作建模：每一个对象占据一个泳道，而活动则是该对象的成员方法.练习有一个表示某公司销售过程的一张活动图，请阅读并说明该图所表示的含义假设订单的接收与关闭是由销售人员负责，开票收款是由财务人员负责，准备货物是由仓管负责。请将其修改成为带泳道的活动图，以体现这种分工.练习假设，我们希望在活动图中体现出：仓管人员是根据“订单”来准备货物的，因此销售人员在收到订单后，必须将订单传给仓管人员。应该采用什么机制？请直接修改活动图。在公司运转一段时间后，财务人员对该流程提出了置疑，反应说收款工作经常滞后，客户总是在收到货物后的很长时间才付款。因此必须加以改进。请提出一个合理的修改意见，并用活动图表示出来。.3.6构件图.构件的类型实施构件：这类构件是构成一个可执行系统必要和充分的构件，例如动态链接库、可执行文件，另外还包括如COM+、CORBA及企业级JavaBeans、动态Web页面也属于实施构件的一部分。工作产品构件：这类构件主要是开发过程的产物，包括创建实施构件的源代码文件及数据文件。这些构件并不是直接地参与可执行系统，而且用来产生可执行系统的中间工作产品。执行构件：作为一个正在执行的系统的结果而被创建的，例如由DLL实例化形成的COM+对象。.构件及构件接口表示法.阅读基本构件图.阅读嵌套构件图.3.7部署图.阅读基本部署图.部署图主要元素节点：它代表一个运行时的计算资源，例如一台计算机、一个工作站等其它设备节点的概念和构件有许多相同之处，例如二者有多名称，都可以参与依赖、泛化和关联关系，都可以被嵌套，都可以有实例，都可以参与交互。但它们之间也存在明显的区别：构件是参与系统执行的事物，而节点是执行构件的事物；构件表示逻辑元素的物理打包，而节点表示构件的物理部署。本图中建模了四个节点：B/S客户端、C/S客户端、IIS服务器和数据库服务器.部署图主要元素连接：节点之间最常见的关系就是关联关系（用一根实线表示）。为了更好地表示两个节点之间的关系，我们可以通过“约束”来对连接进行描述。.部署图补充元素处理器（《process》）：具有处理能力的节点，即可以执行构件。设备（《device》）：没有处理能力的节点，至少是不关心其处理能力的节点。例如打印机、IC卡读写器，如果我们的系统不考虑它们内部的芯片，就可以建模为设备。节点属性和操作：可以为一个节点提供处理器速度、内存容量、网卡数量等属性，可以为其提供启动、关机等操作.部署图补充元素自定义构造型图标.部署图应用说明部署图是一种分两阶段演化的，最初的部署图是在设计时，作为确定最终硬件构架过程的一部分而创建的，然后逐步地对它进行精化，从而得到一个或多个实例形式的部署图。设计阶段：焦点聚焦于节点或节点实例，以及它们之间的连接实现阶段：焦点聚集于将物理构件分配给节点.部署图适用领域如果你开发的应用系统是一个单机程序，那么部署图并不能够给你带来什么好处嵌入式系统建模：对于嵌入式系统，部署图可以使硬件工程师和软件开发者之间实现更好的交流客户机/服务器和分布式系统建模.AgendaUML背景与基础UML的组成常用UML模型基础RUP的UML业务建模法.业务建模的目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户、最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求.业务建模的主要产物业务活动图.业务用例图要对什么建模？>人（客户、雇员）>一组人（组织、机构、部门）>事（对象、表单、设施）>过程如何建模？>人：客户业务参与者>人：雇员业务工人（Worker）>组织组织单元>事业务实体>过程业务用例.业务用例图图例.业务建模的工作流程评估业务状态1）说明当前业务2）确定、改进、设计流程，细化角色和职责3）流程自动化研究开发领域模型（概念模型）.评估业务状态评估目标组织（要在其中部署最终系统的组织）的状态。 了解如何对项目进行分类以及采用哪种业务建模方式最合适。 决定如何在当前迭代中继续工作，并概括出在随后的迭代中如何处理业务建模工件。初步理解目标组织的目标，而且涉众和业务建模团队对此能达成一致意见。.业务建模方式组织图：构建组织及其流程的简图，以便更好地了解对正在构建的应用程序的需求。通常不重视对其流程的改进。领域建模：只关心其业务层面的数据，而非流程。单业务多系统：业务模型帮助您找出功能性需求，并且也作为构建应用程序系列构架的输入。通用业务模型：产品开发。新业务：要启动一项全新的业务。修改：要对其经营方式进行彻底修改。.说明当前业务理解当前目标组织的流程及结构。 在此理解基础上，改进业务建模工作的目标.4.1寻找业务参与者与业务用例.查找业务参与者与业务用例查找业务参与者查找业务用例确定业务用例的优先级编写业务用例工作流程的概述描述业务参与者与用例交互的方式在用例图中表示业务用例模型评审结果.查找业务参与者为了充分理解业务目的，您必须知道业务与谁进行交互；即谁对业务提出要求，或者谁关心它的输出来源：客户、供应商、合作伙伴、潜在客户（“市场”）、当地政府、在业务中未建模部分工作的同事参与者通常都是指人类用户。但是在某些情况下，事物（例如信息系统）也可以担任参与者的角色业务参与者应该有一个能反映它在业务中所承担角色的名称。这个名称应该适用于承担该角色的任何个人或信息系统.查找业务用例考虑各业务参与者能从业务中获取什么价值。考虑“业务为客户提供的主要服务有哪些？”研究客户生命周期是一种有效方法：客户与业务的首次接触是什么？客户经历了业务的哪些阶段或状态？业务流程被定义为数个不同的业务用例，其中每个业务用例都代表业务中某个特定的工作流程。业务用例确定了执行业务时将要发生的事情；它描述了一系列动作的执行，而这些动作会产生对特定业务参与者具有价值的结果。业务流程为业务产生价值或降低业务的成本。 .业务用例实例游客(Passenger)可以独自旅行，也可以随旅游团(TourGuide)旅行。随旅游团旅行时，游客将由导游带领。.业务用例的三种类型第一类是商业上比较重要的活动，常称为业务流程第二类是商业上不太重要的活动，但必须进行这些活动来保证业务正常运转。例如：系统管理、清洁和安全，它具有支持的性质。第三类是管理工作。具有管理性质的业务用例所显示的工作影响如何管理其他业务用例以及该业务和其所有者的关系.某餐馆的业务用例模型在餐馆中，核心业务用例是市场营销(Marketing)和用餐服务(ServingDinner)，而采购(PurchasingSupplies)是支撑业务用例.确定业务用例优先级业务参与者与业务用例一旦确定，就必须确定业务用例的优先级，看哪些业务用例值得进行详细说明。如果您执行业务工程的目的是发现对信息系统的需求，则应确定哪些业务用例对预期的系统具有价值。这些业务用例需要进行详细说明对于有些业务用例，如果您不能确定它们与信息系统之间是否存在关系，那么在决定是否包括这些业务用例之前需编写分步说明。.编写业务用例工作流程概述为了解业务用例的目的，您通常都需要使用工作流程的概述。这种概述可采用分步说明的形式。乘客在登记处排队。乘客将机票交给登记代理。登记代理验票。登记代理登记行李。登记代理为乘客预订座位。打印登机证。登记代理将登机证交给乘客。乘客离开登记处。.业务参与者与用例的交互方式要确定哪些业务主角与业务用例进行交互，可通过定义它们之间的通信关联关系来进行。如果必须要表示通信的发起方，则应向该关联关系中添加导向性。介于用例和主角之间的通信关联关系表示用例实例和主角实例之间将进行交互。关联关系的多重性显示了一个业务主角实例能同时与多少个业务用例实例进行交互；反过来，它还显示了一个业务用例实例能与多少个业务主角实例进行交互。.在用例图中表示业务用例模型用例图用于综合说明业务主角、业务用例以及它们之间的关系。用例图中可以包括以下任何内容：>业务主角和所有与他进行交互的业务用例>与相同业务主角进行交互的业务用例>通常按顺序执行的业务用例>属于同一个用例包的业务用例>最重要的业务用例-该图可作为整个业务用例模型的概览图，它有助于对该模型进行复审.评审是否确定了所有必要的业务用例是否确定了任何不必要的业务用例是否按正确顺序说明了各业务用例的行为各业务用例的工作流程是否达到了现阶段可能具备的完整程度业务用例模型的调查说明是否明白易懂.业务用例模型示例Prepare Tender：准备系统说明书的流程Select Vendor：选择供应商的流程End User Manager：公司内的需要自动控制系统的部门Vendor Manager：供应商的管理者.Prepare Tender事件流基本流：>指定用户代表> 用户代表准备系统规约> IT部门复审系统规约，并改进它，形成招标文件>用户代表批准招标文件扩展流：>系统规约无效。当IT部门发现需求太含糊，最终用户必须重新制作需求。那么这个用例从第二步从新开始，如果最终用户管理者不想继续，也可以终止。 >系统已存在。如果IT部门发现这个需要的系统和其它部门存在的系统很类似，IT部门就提交给最终用户如果最终用户希望继续寻找新系统，他必须写出该系统的特色，并重新提交该说明书，回到第二步，如果最终用户不想继续，也可以终止。 >招标文件和需求规约冲突。最终用户在第四步发现招标文件有问题，它将被拒绝，IT部门必须重做它，用例在第三步继续.4.2寻找业务工人与业务实体.查找业务工人与业务实体确定组织单元确定业务工人（业务角色）确定业务实体定义业务用例实现建立业务对象模型的结构评估结果.确定组织单元确定正在建模的业务内部的各个组织单元，并对其进行简要说明组织单元中包括业务角色、业务实体和按照某种标准合成整体的其他组织单元。组织单元具有名称要建立业务结构，通常要按照各种标准将职员组织成部门、科室、小组等。其建模方法是将业务角色和业务实体放入组织单元中.确定业务工人（业务角色）为您能想到的每个组织角色确定一个业务角色，并对该业务角色进行简要说明。业务角色代表业务中的一个或一组角色。参与业务用例实现时，一个业务角色和其他角色进行交互，并操纵业务实体业务角色是对业务中发挥作用的人员的一种抽象。业务角色对象与其他业务角色对象进行交互，操纵业务实体对象，以此来实现业务用例实例。我们使用角色个体作为业务角色对象的同义词.确定业务实体考虑各个业务角色所处理的“事物”，以确定应将哪些事物当作业务实体业务实体代表业务角色处理或使用的“事物”通常，业务实体代表产品的文档或重要组成部分。有时候，业务实体也代表一些非实体的对象，如关于市场或客户的重要信息。例如饭店中的业务实体有菜单和饮料；而在机场，机票和登机牌是重要的业务实体您只需将业务对象模型中其他类必须引用的那些现象建模为业务实体。而其他“事物”可以建模为相关类的属性.定义业务用例实现对于各个业务用例，都应在业务对象模型中创建一个业务用例实现。业务用例实现的名称应与相关业务用例的名称相同，同时应确定从业务用例实现到它的相关业务用例的追踪依赖关系业务用例模型从与客户和业务流程对应的业务主角和业务用例的角度，对业务进行描述。业务用例模型包括工作流程说明，此说明确定完成了哪些工作。而每个业务用例中的工作是如何完成的则在业务对象模型中进行说明.定义业务用例实现活动图：记录业务用例实现的首选方法就是绘制活动图，其中泳道（或分区）代表参与的业务角色。.定义业务用例实现顺序图：以图的形式详细描述了业务角色和业务主角之间的交互，以及如何在执行业务用例时访问业务实体。序列图简要描述了参与的业务角色的工作，从激活的角度描述了如何操作业务实体，以及它们如何通过发送消息实现通信.定义业务用例实现类图：每个业务用例实现可以有一个或多个类图，图中描述了参与的业务角色和业务实体。.建立业务对象模型的结构分析各业务实体的生命周期。各业务实体都应由某人在业务生命周期中创建和删除。确保各业务实体都可以由某业务角色或另一业务实体访问与使用减少角色的数量。当您开发模型时，很可能会发现过多的角色。每个用例实现通常都有一个或多个角色每个业务实体都应有一名对其负责的拥有者。利用从业务角色到其负责的业务实体的关联关系，您就可建立这种关系的模型.评审评估业务用例实现的工作流程，并评估记录该工作流程的文本与图。评估的方法之一是进行走查。在走查中，负责业务用例实现的人员将带领团队的几个成员经历该业务用例实现的工作流程。另一种方法是进行角色扮演，在角色扮演中，人们将充当业务主角、业务角色与业务实体.4.3实作练习.练习一Mr.Delay软件公司核心业务：从客户那里承接定制开发的软件项目问题：缺乏更好、更快地从客户那里获取需求、分派任务、监控项目状态的方法预期：一个项目管理系统，它将是基于Web开发的，能够基于Internet获取需求，管理任务，以及随时查询完成状态.与客户访谈的信息客户会打电话给项目经理，告诉他需要开发一个新的项目项目经理将创建一个项目，以及该项目的任务列表然后项目经理将对任务进行进度安排，并指派相应的开发人员去完成该项目的任务。开发人员将向项目经理汇报工作的状态。客户、项目经理和开发人员都可以随时检查任务的完成状态.练习二零售商店你与谁做生意？他们希望你做什么样的生意？你的业务如何满足他们的需要。有哪些业务参与者？.练习二有哪些业务用例？和哪些参与者相关？.练习二业务用例“购买产品”的事件流应该是如何的？请用活动图表示出来。.练习二为了更好地管理好货物，该企业设了一个库存管理员管理和维护产品目录；而零售客户购买了“可送货”产品后，就由“物流人员”制定配送计划，然后将订单分配给不同的物流公司，然后由仓管人员根据订单与物流公司交接，并更新产品目录。请识别业务工人（角色）与业务实体，并以业务对象模型形式绘制出来。.4.4业务规则描述.制定业务规则业务规则是对如何操作业务（包括业务工具）的各种要求。它们可以是业务需要遵守的法律或规范，也可以表示选定的业务构架和风格必须严格、正式地表述业务规则；可以采用伪码、OCL、自然语言团队不能超过10个成员contextTeaminv:   self.numberOfMembers<=10.业务规则分类约束规则规定了限制对象结构和行为的策略和条件。激励和响应规则对某一行为进行约束，方法是通过指定何时触发该行为以及是否必须满足某些条件才能触发该行为。操作约束规则规定了在操作前后必须符合的条件，以确保操作正确执行。结构约束规则规定了有关类、对象和它们之间关系的不可违背的策略和条件。推导规则规定了从一些事实经过推理和计算得到其他事实的策略和条件。推论规则规定如果某些事实为真，则可以推出一个结论。计算规则通过处理运算法则（一种更精确完善的推论规则）得出结果.在模型中反映规则—激励和响应可以在工作流程中显示条件路径或备选路径。如果涉及的操作不太重要，则只需将对业务规则的考虑体现在活动状态中即可WHENanOrderiscancelledIFOrderisnotshippedTHENcloseOrder. 此例中的业务规则转化为一个通过工作流程的备选路径.在模型中反映规则—操作约束ShipOrdertoCustomerONLYIFCustomerhasashippingaddress.此类业务规则通常转化为工作流程的“前置条件”或“后置条件”，或者转化为工作流程中的条件路径或备选路径。它可以是要达到的性能目标或某个应该追踪到应用该规则的业务用例的其他非行为性规则业务规则转化为工作流程中的一个备选路径.在模型中反映规则—结构约束ITMUSTALWAYSHOLDTHATanOrderreferstoatleast1Product.这类业务规则影响业务实体实例之间的关系。它们通过两个业务实体之间的关联关系表现出来；有时也表现为关联关系的多重性此业务规则转化为一个多重性为1..*的关联关系.在模型中反映规则—推论规则ACustomerisaGoodCustomerIFANDONLYIFtheunpaidinvoicessenttothisCustomerarelessthan30daysold.推论规则看上去常与激励和响应规则、操作约束规则或结构约束规则类似；不同之处在于，需要对其中的一些步骤进行思考才能得出结论。此规则为一种方法，需要在工作流程的活动状态中得以体现，最终在对业务角色或业务实体的操作中得以体现.在模型中反映规则—推论规则A