Enterprise-Architect-UML指南.docx

EnterpriseArchitectUM1.指南1 .应用UM1.进行数据库建模1.1 介绍当须要为软件系统系统供应一种牢靠，敏捷而又高效的对象长久化方法时，当今的设计师和架构师们面临着众多的选择,从技术的层面上，这个选择往往介于完全面对对象，对象关系混合，完全关系化和建立在公开或专有文件格式上的常规解决方案之间（如：XM1.1O1.E的结构化存储1从供应者的层面上，Orade,IBM,Microsoft,POET和其它的公司供应了相像,但是彼此间往往不相容的解决方案.本文仅论述这些选择中的一种，即在完全关系数据库上层面对对象的类模型进行分层.这并不表明它是唯一、成好而又简洁的解决方案，但是从好用的角度看，它是最常用的一种类型，和也是最简洁被用娼的一种.我们先快速阅读两个设计领域的模型，并试图把它们连接起来：第一，介绍用UM1.表达面对对象的类模型；其次.关系数据库模型.对每一个领域我们只涉及联向到我们任务的主要功能.然后捌门将关注从类模型到数据库模里映射的技术和礴.包括对象长久性，对象行为，对象和对象标识之间的关系.我们将总结对UM1.数据profile的回顾（RationalSoftware举荐1.一些面对对象设计，UM1.和关系数抠库建模的相像性也会被提及.类模型是UM1.用来表达软件系统逻辑结构的主要工件.它用来记录数据需求和模型领域内对象的行为.本文不探讨创建和具体描述该模型的技术，我们将假设已经存在一个设计好的类模型,它须要映射到关系数据库上.类榛型类在UM1.中是一个基本的逻辑实体.它定义了一个结构单元的数据和行为.一个类是一个模板或运行时创建实例和对盆的模型.当开发一个陵辑模型，如UM1.中的结构层次，我们将明嫡地把它们当作类来处理.当面对动态图时，如依次图和协作图，我们也要处理类的实例和对象,以及它们运行时的内部动作.数I藏和封装原则是基于作用域效果.类有它的内部数据元素.访问这些数据元素须要通过类对外的行为或接口.遵循这个原则会生成更易于维沪的代码。一个筒触的“Person”类,没有显示状态和行为Pe<son Address:CAdctess Name Age:double ge!Age<)int SetAge(0 g!Name stNarre<s)H性和操作定义了运行时对象的状态和美的行为行为行为运用了类定义的操作，在类模型中被记录.操作是可以外部可见的(public),对子类可见的(protected)和隐藏的(private通过结合隐藏数据和公共访问接口,隐藏或爱护数枢的振作，类的设计人员可以建立极易维护的结构单元，这些结构单元是支持而不是阻昭变更的.关系和特性关联是两个类之间的一种关系.关系TW的类知道和在某种程度上运用或操控另一侧的类.这种关联可以是功能上的(为我做茶学)也可以是结构上的(是什么在本文中更多的是侧重结构上的关系.如：'Address"类可以关联一个"Person*类,将这种关系映射到数据空间须要多加留就的关系.聚合是关联的一种形式，表示一个类多个对象的集合在另一个类中,复合是一种更强的聚合形式，说明一个对象事实上由其它对象构成.对于关联关系来说，它意味着一个困难的类属性，将该属性映射到关系模型时须要更具体的考虑.当一个类表示为生成很多对象实例的模板或模型时，对皴须要在运行时有识别自己的方式，这样被关联对象可以对正确的对象实例施加作用.在编程语言中JQC+,对象指针可能会传递，并使所指对领可以访问一个独一无二的对象实例,通常尽管一个对象会被俏毁，但是在须要时，又象上一次有效实例期间那样被里建.所以，这些对象须要一个存储机制来保韬它们的内部状态和关联，并在须要时且原所需状态.继承给类模型供应一种方式，该方式提取通用行为到泛化的类中，使这个泛化类稍后可以做为在一般主题上诸多变异的原形.继承是一种管理更用和困难性程度的方式,如我们将看到的，关系模型并没有与继承关系的干脆对应项，这给数据模型建立者建立一个从对象模型到关系框架造成了困难,从一个运行时的对象到另外一个对象的导航是建立在完全引用的基础之上.一个对象有多种形式的连接（指针或唯一的对象标识），用这些连接可以定位和亚建所需的对象.ts有三种形式的聚合关系：弱聚合用菱形表示（不填充）.想聚合（复合）用实心受形衣示（内部填充个地址可以没有人.也可以有多个人居住.关系模型关系数抿模型已经运用多年，供应的性能和敏捷性始终行之有效.它本质上是基于集合的（set-based）,并且用表做为它的基本单元，表由一个或多个列组成，每一个列包含一个数抿元素.表和列：一个关系表是一个或多个列的集合，每个列在表结构中有一个唯一名称，井目被定义成一个特定基本数露类型,如：数字、文本、二元数据.表定义是一个模板，表的"行"从这个模板中破创建，行可能做为一个表实例的实例.关系模型仅仅供应一个公共数据访问的模型.全部数据向外对任何一个过程开放，以便于被更新，查询和操控.信息廉菽（informationhiding）是未知的.行为与表相关联的行为通常是基于所应用实体的业务或逻辑规则.约束以多个形式应用到"列"，如：独特性需求、对应其它表和列的关系完整性约束，允许的值和数据类型.触发器供应了关联到一个实体的很多附加行为。通常在数据被插入、删除和更新前后，强制执行数抿的完整性检直.数据库存储过程供应了一种通过专有语言扩展来延长数提库功能的方式，这些犷展通常用来构造功能性单元（脚本1这些功能不会干脆映射到这些实体，也不会与它们有逻辑关系,通过关系数据集的导航是基于"行"遍历和表连接实现.SQ1.是用来从表集选择“行”和放置实例的一种主要的语言.关系和识别表的主键为识别行供应一个特定值.这里有两种我们关注的主键：首先是意义键（meaningkey）,它由数抿列构成，这些数据列在业务领域有意义.其次是一个抽象的唯一标识符，如计数器值，它没有商业意义,但是可以唯一地标识一个行.我们将先探讨抽象唯一标识符，然后再阐述意义键,一个表可以包含映射到另一个表主健的"列二表间的关系定义了一个外耀，说明白在这两个表之间的结构关系或关联.小节从以上的钱述我们可以看出对象模型是建立在离散实体基批上这些实体既有状态属.关系模型同等地显露全性和数据），也有行为，TS仅通过类的公共接口来访问封装;部数据，有限支持利用触发器从行为到数据元素的关联.依靠运用唯一对象标识符，可以从一个对象移动到另一个对象,这使得我们可以在对象模型中导航,并建立对象关系（类似于网络数据模型在关系模型中，通过运用检索标准，SQ1.合并和过逑结果集,你可以直找我所需的行.标识符在对象模型中既可以是实时引用，也可以是长久的唯一标识符（称作OlDX在关系校域里,主键定义了数据集在整个数抠空间中的唯一性.对象模型中有丰富的关系集合：继承，聚合，关联，豆合，依服，以及其它。在关系模型中，可以仅运用外键来指明一种关系.我们已经对感爱好的两个领域进行了介绍并比较了每一个领域的几个变要功能，然后将简洁了解UM1.中关系数据模型的标注.1.2UM1.数据模型Profile（特性描述）数据模型Profile是EnterpriseArchitect的UM1.扩展来支持关系数据库建模.它包括一些定制犷展，如：表，数据库图表，表鎏,触发器和约束。它是一种在UM1.中对关系数据库建模的技术.衰和列表在UM1.数据Profile中是带Table构造型的类，它在右上角显示一个表的符号.数据库中的列用Table类的尿性来建模.CustomerPKOK):Ct-5e:VftRCHM2VWRCHAR2例如：上面图型显示与客户表关联的属性。在此示例中,对象ID被定义为表的主腱，还有两个列：“Name"和"Address".留意上图例子中列的数据类型是依据原DBMS的数据类型定义的。行为到目前为止，我们仅定义了表的遗辑（静态）结构.此外，我们将描述与列关联的行为，包括：索引,械，触发器，过程等等。行为表示为带构造型的操作下图显示我:三讨的表，它有一个主健约束和索引，均被定义为带构造型的操作CurtcmerPK00irrtNhq:VARCHAR?AddressWCHARZ*PK»IdxeCustomerOOO«ind«K»rfx-cumerOlQ留意："OID"列上的PK标签定义了逻辑主置,而构造型操作""PK»idx_customer（X定义了与主被实现相关联的约束和行为（即主捱的行为对上例进行增加，我在可以定义附加行为，如：触发器，约束，存储过程.见下图：Cy(XnorPK0(XStMIP：MleCi¼R2A!.RCHAR2FKIaCUVlcifTMdKO 1K>Q.cgrS2Q dMX>M«.OltflWTHrtJ10 eTfpr>»o.cua«THd)a：) <Uf¼>to5.CM11Of rfocCMaTM<0 4Cteckkch.cutt4mfk)这个例子描述了下列行为：一个主健约束（PK）;一个外键约束（FK）;一个索引约束（Index）;一个触发器（Trigger）;一个唯T±约束（UniqUe）;一个存储过程（Proc）一个有效性检查（Check）.运用上面供应的标注，我们可以在DBMS层次上，对困难的数据结构和行为建模.另外，UM1.还供应表达逻辑实体间关系的标注.关系UM1.数抠建模profile定义了两个表间造意一种依靠关系.它表示为一构造型的关联并包括一组主键，的卜键,数据profile仍旧须要一种关系始终参加到父类和子类之间，父类定义一个主城，子类实现一个建立于全部或部分父类主键基础上的外梃.这种关系将被区分为：”定义的"（假如该子类外犍包含全部父类主健元素）和"非定义的"（假如只包括部分主键元素I这个关系可以包括基数性约束，以及袖成对的相关主键与外键来建模，并命名为关联角色.下图描述了运用UM1.对这种关系的建模.上图显示I父类和子类之间的标识关系，带有主螳到外槌的角色名物理模型UMI.也供应一些机制来表示数据库的整体物理结施，它的内容和部署位西.我们用恂造型组件来表示一个物理;库.见下图：oDstabase*NainOraOB一个组件表示了一个留敢，可部署的实体.在物理模型中,组件可以映射到一个物理硬件（UM1.的节点X对于数SS库内的关系模式，我们用带Schema构造型的包来表示.一个表可以放国到Schema中来建立它在数据库中的范围和位置.schema*UserChMGrjndohiMGrjndpjrentParentPerson1.3从类模型到关系模型的映射我们已经描述了所关注的两个领域和它们运用的标注,现在将我们的留意力转移到如何映射，及如何从一个领域转换到另一个领域,以下采纳的策略和表达依次是建议性的，而不是必需的.果纳何种步骤和过程要依据个人的须要和环境而定.1 .类的建模首先我“城设从T已经创建的类模里构建一个新的关系数据库模式.明显这是一个最简洁的方向，这是因为摸型始终在我们的限制之下，并且我们能依据类模型来优化这关系模型.在现实环境下，你可趣要在原有数抠模型之上对类模型分层，这是更难的一种状况，具有挑战性。在这里，我们只关注第一种状况,至少类模型会记录元素的关联，继承和聚合关系.2 .标识长久对象建立类模型后,我由预要将类模型的元素分成须要长久性和不须要长久性两类.例如，假如我们采纳“模型-视图-限制"的设计模式来设计我们的应用程序,另蚣只在模型部分的类将须要长久状态.3 .假设每一个长久类映射到一个关系装这是一个大的钱设，但是它对大多数状况有用（现在先把继承的问题放一边在一个最简洁模型中，来自逻指模型的类映射到关系表的全部或一部分。这个映射的逻辑扩展是一个单独的对象（或类的实例）映射到表中单独的“行“Parent”关存有唯一标识符（OID）,名称和性别国性，并映射到一个关系表<-eoliscs>>PKAddressD:VMeHMNerrieV乐CHXROD:VMCH纸SexVMCHZR来自逻钺横型的“Address”关联成为数推模型中的外碳关系逻物模型中“Address”类变为数据模率中的一个表tb1.A<kc¾sCwV/RCHXRPKODWCHXfiPhoneWCHXRStateVMCHMStreetVMCH加«realises>>4 .选择一个继承策8g继承可能是从面对对象模型转换到关系模型过程中最简洁出现问题的关系和逻辑结构.关系领域本质上是平面的，每一个实体自身完成，而对象模型用常是一个具有深度的，设计完善的类层次结构.这样深度的类模型可以有多层的继承属性和行为，运行时生成最终全功能的对象：每一个类层次结构有一个单独对应的表，这个表包含全部元素的继承属性-因此，这个表是该层次结构中每个类的联合.例如，人，父母，孩子和孙子可能形成一个单独的类层次结构，并且每个类中的元素都会出现在相同的关系表中；类层次结构中的每一个类有一个对应的表，该表有仅能被该类访问的属性（包括继承属性1.例如，假如“孩子”仅仅从"人"继承而来，表将仅包含"人"和孩子”的元素；类层次结构中的每个类的自有属性对应一个表.例如，“孩子”将映射到一个仅带孩子属性的单个表对每一种方法，我们有对应的案例.但是我们举荐第三种方法，因为它最简洁，最简洁维护和跟不简洁出错.第一种方法供应了运行时最佳的性能.其次种方法是第一种与第三种的折更.第一种方法绽开层次结构，在一个表里放置全部的属性，这样便利类层次结构中对类的更新和握取,但是不易于验证和维护.与"行”关联的业务规则是难以实现的,因为表中的每一行都可能被实例化为层次结构中的对象.“列”之间的依靠关系可能变得相当困难.此外，对层次结构中任何一个类的更新将可能影响层次结构中其它得个类，如表中的列被添加，删除和修改.其次种方法是一师裹方案，供应了更好的封装和消退空列.可是，对父类的修改可靛须要在全部子类的表中进行复制，更糟的是，有两个或多个子类的父类数据可能被冗余地存储在很多表中；假如父类的原性被修改，那么要花相当的时间去查找相关的子表，并更新受影晌的行.第三种方法精确地反映了对象模型，它将层次结构中的每一个类映射成一个独立的表.父类或子类的更新是在正确空间的局部范围内进行的.对实体的任何修改被严格限定于第个表内，因此表的推沪也就相对简洁.缺点是须要在运行时重构结构层次，来精确产生一个子类的状态,一个"Child"的对象可能须要一个"Person”的成员变量用于表示它的父耕.由于这两者都须要加就，两次调用数据库来初始化一个对象.随着类结肉层次加深,初始化或更新一个单独对象的数据库调用次数也随之增加.当你映射继承关系到关系模型时，理解上述要点是很电要的，这样你就选择最适合你的方案.5 .为每一个类添加一个唯一的对象标识符在关系和对象的领域里，须要唯一标识一个对釜或实体.在对象模型中，非长久对象在运行时通常被干脆引用或对象指针来标识。一旦对象被创建，我们可以用它运行时的标识符来引用它.但是，假如我们将对象写入存描空间，那么如何按须要得到完全相同的实例是一个问题.最便捷的方式是定义OID（对象标识符），它在关注的命名空间是被确保唯一的.依据须要，这可能发生在类，包或系统的层级上.系统级别OID的一个例子可以是一个运用微软"guidgen”工具创建的GUID（全局唯一标识符），DAlA68E8E-CD92-420b-BDA7-118F847B71EB.类级别的OlD可以用简洁得数字实现（如：32位计数器1线如一个对象具有对其它对象的引用，它可以采纳运用它们的OID的方法.另除，在运行时有效地将引用的对象从存储区加载到模型中.关于上述OID值的里点是它没有超出定义它为标识符的简洁含义,它们仅是逻辑指针而没有其它意义.在关系模型中，状况往往是不同的.关系模型中标识正常地用一个主键实现,主鞋是一个表中的一组"列"，它们合起来可以唯一地标识一个行.例如：名称和i½址可以唯一地标识一个“客户二其它实体，如："销售员"引用"客户"，它们要实现基于"客户"主键的外键,这个方法存在的问鹿是：将业务信息（如客户名和地址）嵌入标识符中对我们目标的影响.设想三个或四个表全部具有基于“客户”主键的外键，对于一个须要修改客户主键（如：增加一个用户类型）的系统修改，那么既要修改客户表，也要修改与外键相关的实体，这个工作是特别巨大的.另一方面，赖如一个OID被当作主键实现，并为其它表建立外键，月及修改范围仅限于主表,并且修改的影响也因此大大减小.事实上,一个基于业务数据的主键或许会被修改.如：一个客户可以修改地址和名字，既然这样，这个变更须要被正确的传递到全碍它相关的实体，更不用提变更部分主键信息的困难。一个OID忌是引用同T实体，而不管其它信息怎么变更.在上面的例子中，客户可以修改名称和地址，与它相关联的表不须要被修改.当把对敷模型映射到关系表时，实现完全OlD的标识符比采纳业务联系的主键更加便捷.用OlD做为主犍和外犍的方法将为对象供应更好的加载和更新效率，将维护服务减到最少.事实上，一个与业务相联系的主键可以替换为： 一个唯一性约束或相关列的索引； 派入类行为的业务规则； 或将上述两种结合起来.再次生申，是运用有意义的键还是运用OlD取决于被开发系统的实要.6 .映射属性到"列"通常，我们将简洁的类数据跟性映射到关系表的列。例如，一个文本联字字段可以分别表示一个人的名字和年龄，这种干脆映射不会引起什么问题，只是简洁地在数据库服务商的关系模型中选择适当的,与类属性相对应的数据类型.对困难属性（即属性为其它对象）运用下面具体的步赛来处理关联和聚合关系。7 .映射关联到外健更困难的美属性（即它由城表其它类）通常建模为关联关系,一个关联是对象间的结恂关系.例如，一个人可以居住在一个地址，当这个人被建模，他会有城市，街道，郃编的属性.在对象和关系领域里，我们倾向于把这个信息当作单独蹴体来构造："地址在对象领域里，地址代表一个独一无二的物理对象，并可能带有一个唯一OlD.在关系领域，一个地址可以是地址表中的一行，该表的主健被用作为其它实体的外犍.在这两种模型中，趋向于移动地址信息到独立实体，这有助于避开冗余数据和提高可维护性.所以对于每一个类模型中的关联，要考虑创建一个从子类到父类表的外健.此关系基千“外窿一主嫌”对，该例用适当的外犍和主像来联系植害员和客户。这里假设一个客户仅与一个销生员关联。8 .映射聚合和复合鬃合和复合关系类似于关联关系，并通过"主健-外援”对来映射成表.但是,须要提示的是：一般聚合（弱聚合）对关系建模，如：一个人住在一个或多个地址，在此例中，超过一个以上的人可能住在相同地址，假如这个人不在这里住了，与他相连的地址仍旧存在.这个例子例举了关系术语中称之为"多对多的关系"，并且通常实现为一个独立的表，该表包含了从一个表格的主耀到另一个表格主犍的映射.弱聚合的其次个例子是：一个实体在那里运用或解除了另f实体的全部权.例如：一个“人”的实体拥有一组股票，这标明这个人可能与一个"股票"表中的某些股票有关联，也可能没有关系.但是每个股票可以联系一个人，财与任何人发生关系.假如这个人不在了，这个股票将变为"无主"的，或者被传递给下一个人.在这个关系摸型中，可以通过每个股票有一个“全部者“列来实现，这个“全部者”列将存储T人的标识符（OID）.强聚合形式则有与之关联的完整约束。豆合表明一个实体由部件组成，并且这些部件对整体有依先关系.例如：一个人可以有很多证明文件，如护照，诞生证明，驾照等.这个人的实体可以由这样的一组文件组成假如这个人从系统里嬲除用B么证明文件也要被删除,因为这些文件被映射到一个唯一个体.假如我们短哲忽视OID,弱聚合可能运用中间表来实现（对多对多的状况）或者在一个聚合的类或表采纳一个外犍来实现（一对多的状况1在多对多关系的状况下，假如父类被捌除，中间表中的实体也要被删除.在一对多的状况下，1但如父类被删除，外键输入（如“全部者”）必需被清除.在复合的状况下，夕隧的运用是强制的,约束条件是父类删除后,部件也必需被删除.谡箱上,豆合是有一种含义,部件主蛙形成了全部主键的一部分.例如：一个人的主键由他证明文件组成.尽管事实上是相当冗长的，但逻辑关系上为真.9 .定义关系作用对于每一个关联关系，可能会进一步指明关系每一个端点的角色信,息.通常包含主键约束名和外犍约束名.图6例示了这个概念，这在逻辑上定义两个类之间的关系.另外，可能会在作用名上标明附加约束（即（非空）和基数性约束（即0n）.10 .模型行为我们现在来探讨另一个难题：是映射部分还是全部的类行为到数据庠商供应的功能上，这些功能以触发龈,存储过程，唯一性,数翅约束和关系完整性的形式出现.一个非长久对象模型通常可以实现一种或多种语言（如Java和C+）须要的全部行为。每一个类将用公共的，爱沪的和私有的方式描述它被给予的行为和职责.不同数据库商的关系数据库通常包含不同形式的，基于SQ1.的可编程脚本语言,用来实现对数提的操作.最淮用的例子是触发器和存储过程.当我们混合对象和关系模型，要做的确定往往是：是实现类模型中全部的业务浸辑,还是将部分的业务逻相放在关系DBMS中更常用而有效率的H蛾器和存储过程中。从完全面对对象的角度吞，答案是避开运用触发器和存储过程，并且将全部行为放到类中.这样会使行为局部化，从而供应了一个更清晰的设计，简化了维护,并且供应了在不同DBMS供应商之间更好的移植性.在现实世界,存储过程不睡发器的设计目标底或可以是每秒至少执行几百次或几千次之务.软如为了追求模型的清晰，移植性，可维护性和敏捷性，那么就将全部的行为放在对象方法中，假如性能是关注的焦点，可以考虑将部分行为交给更有效的DBMS编程语言.留息到将对象模型与存储过程以平安方式集成所花的额外时间，包括远程影响和调试的问题，可能要比简洁部署更高性能的硬件更多.如前面所述，UMl数据profile供应下列扩展(构造型操作)，可用来对DBMS行为建模： 主艇约束(PK); 外键约束(FK); 索引约束(Index); 触发器(Trigger); 唯一性约束(Unique); 有效性检直(CheCk).11.产生物理模型在UM1.中，物理模型描述了物体如何在现实世界里部署:硬件平台，网络连接,软件，操作系统，动态连接库和其它组件.你须要生成T物理模型来完成这个周期：从一个初始的用例或领域模型，到类模型和数据模型，最终到部署模型.通常对这个模型，你要创建一个或多个节点，这些节点可以存放数据库，并安装DBMS组件.假如数据库被分成多于一个的DBMS实例，你可以安排表的包Schema给单个DBMS组件来指明数掴位置.MainScrvcv<Databae>WUinOiMB<schemo>SystemSysjxocs8ysjugssjabte58ys-user<tchemaUser国CHM国GrancicbM匡Oancwfcnt国P»entF三lPerson一个个点是一个妾部署姐件的物理硬件(却UniXServer)这个例干的数据库组件映射到四个逻簿图(4schema构造怨)，每一个图包含一定数量的表。1.4总结运用UM1.进行数据库建模，就象彳尔看到的，当从对象领域映射到关系领域时，有很多要留京的问题,UMl供应了这两个领域之间的桥梁.UMl.数据profile也是一种胜利地把两个领域集成起来的优秀的扩展语言.2.UM1.教程统一建模语言(UM1.)已经快速变成建立面对对象软件的事实标准.本教程供应了EnterPriSeArChiteCt支持的13种UM1.图的技术概览.UM1.2具体的语义说明请看新的UM1.2教程.首先什么是UM1.?OMG组织规范声明：统一建模语言(UM1.)是一种图形化的语言,用于软件宓集系统要素的可视化、制定规范、构建对象和编写文档.UM1.供应了一种标准的方式来描述系统的设计图，既包括概念方面，例如业务过程和系统功能，也包括具体事务，如编程语言语句，数据库图示和可更用的软件组件.这里若里指出的是UM1.是一种说明性的“语言"，而不是一种方法或程序UM1.通常用来定义软件系统与细化、编写、构造系统中的要素,是“写"设计图的语言。UM1.可以用不同的方式来支持软件开发方法（例如：统一软件开发过程）-但是它本身并不指定某种方法或过程。UM1.定义了下列领域的标注和语义：- 用户交互或用例模型-描述系统和用户之间的界定和交互.在某些方面对应于一个需求模型.- 交互或通信模型-描述系统中的对象彼此之间5出可进行交互以完成工作.- 状态或动态模型状态图表描述随着时间变更，类所呈现的状态和条件。；舌动图则描述系统即将执行的工作流程.- 逅辑或类模型描述构成系统的类和对象.- 物理组件型-描述构成系统的软件有时也包含硬件I.- 物理部暑模型-描述物理架梅与物理架构中组件的部署。UM1.也定义了一些扩展机制，以扩展UM1.符合特殊须要（例如：业务过程建模的扩展）.其次部分敢程绽开论述如何运用UM1.定义和建立总实系统.2.1用例模型用例模型描述的是新系统规划的功能。它表示用户（人或机器）和系统之间交互的矗散单元.该交互是一个有意义的独立单元，如：创建账户，阅读怅户信息.每一个用例三述建立在规划系统中的功能,它可以包含另一个用例功能或用自己的行为扩展另一个用例.1.ogtn一个用例描述通常包话：描述用例的常规注释和说明需求-用例必需供应应最终用户正式的需求.如：(abilitytoupdateorder能更新订单.它4涧对应构造方法中建立的功能规范，并建立用例执行动作!哈系统供应值的约定.约束-用伊运行所遵循的正式规则和限制，它们定义了什么能做，什么不能做.包括： 预置条件是用例国亍以前就已经发生了.如：.创建订单(createOrder必需发生在“修改订单modifyOrder之前. 后国条件是用例完成后必需为真.如："订单修改和一样性检直. 常景在用例的整个运行过程中始终为直，如：一个订单始终有客户号. 情形-用伤则亍时各步骤正式有序的描述或用例实例化过程中事务发生的流程.它包含多种情形来应付特殊环境和可选择的处理方式.它们通常由文本建立和对应于依次图的文本表达. 情形图-描绘工作流的依次图;类似于情形，但是图形化描述. 附加同性，照实施阶段，版本号,困难性程度,构造型和状态.执行者用例通常与执行者关联，执行者可以是人或机器实体，用于系统交互来执行有意义的工作从而智助他们完成目标,执行者参加的用例定义了它们在系统中总体的作用和动作的范围.Actor包含和扩屈用例间的关系一个用例可以包含另一个用例功能做为它自身正常运行的一部分.通常假设在用例运行时被包括的用例每次都会被调用,例如：在修改选定订单前，列出一份客户订单表，每次modifyOrder>修改订单.用例执行时，<listorders1列出订单用例被调用执行.一个用例可以被T或多个其它用例包含。通过将通用的行为提炼成可以多次生复运用的用例，有助于降低W能至豆级Sl1.通常,在特殊状况下，一个用例可以扩展另一个用例的行为。例如：低如一个用户在惨改一个特殊类型的客户订单之前,该用户必需得到某种更高级别的许可，然后“获得许可”<GetApproval用例将有选择地扩展常规的“修改订单"VMOdifyOrder>用例.依次图依次图供应地时间变更，对象交互的图形化描述.通常用来表现一个用户或执行者，对效和组件，以及它们在用例执行过程中之间的交互,一个依次图典型地表示一个单独的用例情形或事若流.依次图可以精彩的显示文档运用情形，既可以记录早期分析的所需对象，也可以在稍后的设计阶段睑证对象.它显示一个对象到另一个对象的消息流，这些消息流对应看一个类和对釜支持的方法和事务.下面依次黝标了左侧的用户或执行者初始化事务和消息流，它们对应于用例情形,在最终模型中，对象间传递的消息变成类的操作.?Cu«o»r«f1.oginValKJatelber0JxyManagerlher3e!aibResuHJVaIioatQ：C<*Uw<S0tal6执行图用例是对所构造系统将有功能的正式描述。与用例关联的执行图用来设计元素（如：组件和类）和实现用例在新系统中的功能.这为系统设计者，客户和团队,这些实际建立系统的人，供应了高级别可跟踪实力。组件和类连接的用例列表说明白必需被组件执行的或少功能.1011.OflQntotheWebtae,froPormafeq,urmSaiIfrDmUserhfeffacet结束所可能采纳的推断方式,他们也图示某些活动执行中，并行处理可能发生在那里。状态圉(statecharts)状态图用来具体描述系统中，对象经验的状态转移和变更.它们显示一个对领如何从一个状态到另一个状态，以及限制这种变更的规则，通常有f5fc和结束状态.End过程模型过程模型是UM1.活动图的扩展，用于业务过程建模-该图显示这个过程的目标，过程的同入，筠出，事务和所包含的信息.2.3业务过程建模2.3.1 介绍比起业务分析与建模来，UM1.在过去与软件工程和系统设计的联系更加紧茁.并且，UM1.2.X标准供应了丰富的行为模型，这对于过程、活动、及对每一个业务部生要的人与信息等的建模特别有用.除标准的UM1.规范外，还有两个备受关注的UM1.扩展，它们进一步强化了对业务过程和相关结构的建模,第一个是业务过程建模标注，它已经广受欢迎，并快速成为业务过程建模与设计的新标准.其次个是Eriksson-PenkerProfile,虽然不另必流行，但在可视化、业务过程间通信、以及企业（组织）内部的信息流方面，仍旧是独一二的.本文将对这两种扩展供应深化介绍，阐述如何在EnterpriseArchitect中运用它们以及他们所用的通用模型结构.2.3.2 业务过程建模标注（BPMN）BPMN定义了一种业务过程图（BPD）,该图是基于一种特地绘制流程图技术，用于业务过程的图形化建模.无论是创建业务过程草图的业务分析师，还是负责实现这个过程的技术开发人员，或者管理、监督业务过程的相关人员，全部的业芬人员都简洁理解这种标注.一个BPMN模型是由一组简洁图构成，每一个图又包含一组图形元素.2.3.2.1 流程元素1 .活动（Activity）:一个活动是业务过程中执行的一个作业，用圆角矩形表示2 .事务（Event）:一个事务是在业务过程的流程中发生的，并膨响业务过程中活动的执行依次与执行时间的事情.事务用带有不同边界的小圆表示，以区分初始事务（细实线中间事务（双实线），海止事务（相实线1在图形内部显示图标以便于区分触发能和事务结果.3 .关口（Gateway）:关口用来限制依次流如何在过程内进行合并和分岔.关口可用来表示推断点，可以表示一个或多个路径在此处不能通过.关口也可以表示一条路径在此分岔.4 .依次流：依次流用来表示活动在业务过程中的执行依次.依次流用有实箭头的线表示。5 .消息流：一个消息流用来表示两个实体之间的消息流向.实体用池来表示，消息用虚线在源端连接浅颜色的圆并在目标端连接箭头.6 .关联：关联是用流对象将信息与制品联系起来.关联采纳虚线表示并在目标端有或者没有箭头，依据须要而定.2.3.2.2 泳道（分割）1 .泳池：表示一个业务过程中的参加者.一个参加者可能是业务实体或者角色.泳池表示了对业务过程的一种划分.2 .泳道：是泳池的再划分,用于组织和分类泳池内的活动.2.3.2.3 过程要素1 .数掴对象：一个数抠对象对一个业务过程i殳有干能的影Q同，但供应信息给相关的过程,数据对象用一个上角折抬的走形来表示.2 .组：组供应了对过程内的元素进行分组的非正式手段，用虚线的矩形表示.3 .注解：注解供应一种机制使得BPMN的模型建立者为BPMN模型的用户供应附加信息.它是用T开口的矩形表示,注解文字写入其中.2.3.2.4 BPMN示例例1：上面的图展示了BPMN的几个主要功能.特殊是将一任务过程进行层次分解成较小的任务.以及能表示循环结构和夕倍事务干扰正常过程流程.'上行活动”和下行;舌动”是连接触发的中间事务，换句话说，是页面间承上启下的连接器.对每个供应商重复执行”是一循环活动,它对每一个供应商重定执行所包含的三个活动，或者直到时间限制已到.固定在活动下边沿的终止事务是一时间事务触发器。例2:上面的图表示一个业务过程由一个事务开启,在本例中,一个消息触发器产生一个事务，该事务通知业务过程活动组处于活动状态。该图也显示一个由时间事务限制的循环，并显示一个决策关口（在本例中是“异或”决策关口）限制什么时候偌环该结束.例3：!Hi杓通知§AI收到病入旧家r溜温-该图例示运用泳池来表达过程间的交互以及运用消息流连接器来表示消息在泳池间进行传递的方法2.3.3 Eriksson-Penker业务Profile本节介绍业务过程模型所运用的术语与图标。并简要介绍一些基本UM1.建模语言概念以及如何在EA的业务过程建模中如何运用它们.一个业务过程：1 .有一个目标2 .有指定的输入3 .有指定的输出4 .运用资源5 .有按某种依次进行的一组活动6 .可能影响多个组织单元，造成横向组织影响7 .为客户创建某种价值，客户可能是内部的，也可能是外部的.2.3.3.1 过程模型一个业务过程是T活动的集合，用于为特定的客户或市场产生指定的输出.与产品所强调的“过程是什么"不同,业务过程强调作业在组织内部是如何进行的.指定在不同时间和地点的作业活动依次，带有一个起先和一个结束，并清晰地定义输入和输出：一个动作结构.始于对象信息供应链,供应链是指连接到过程的信息或对象在处理阶Esi殳有被运用完.例如，订单模板可能翱运用，并供应特定样式的新订单.作为这个活动的一部分，这个模板不会更改和被消耗光.始于对象资源的供应造：一个输入供应Ia是指所连接的对象或资源将在处理过程中被消耗.例如，当消费者的订单在被处理后，它。泄标记为完成并签字，并且每个资源仅运用一次. 成终对象目标的目标链：一个目标链是指连接到业务过程的对象描述业务过程的目标.目标劭行S动的业务宗旨. 对象流连接对象输出 始于事务的对象流：一个对象流连接是指在一业务过程一些对象被传递.它强调对在实体之间或过程之间所传递信息的限制.2.3.3.2 目标一个业务过程有一些定义完备的目标.这也是组织制定业务过程的缘由所在.并且这些目标的制定