Enterprise-Architect-UML指南.docx

《Enterprise-Architect-UML指南.docx》由会员分享，可在线阅读，更多相关《Enterprise-Architect-UML指南.docx（80页珍藏版）》请在课桌文档上搜索。

1、EnterpriseArchitectUM1.指南1 .应用UM1.进行数据库建模1.1 介绍当须要为软件系统系统供应一种牢靠，敏捷而又高效的对象长久化方法时，当今的设计师和架构师们面临着众多的选择,从技术的层面上，这个选择往往介于完全面对对象，对象关系混合，完全关系化和建立在公开或专有文件格式上的常规解决方案之间（如：XM1.1O1.E的结构化存储1从供应者的层面上，Orade,IBM,Microsoft,POET和其它的公司供应了相像,但是彼此间往往不相容的解决方案.本文仅论述这些选择中的一种，即在完全关系数据库上层面对对象的类模型进行分层.这并不表明它是唯一、成好而又简洁的解决方案，但是

2、从好用的角度看，它是最常用的一种类型，和也是最简洁被用娼的一种.我们先快速阅读两个设计领域的模型，并试图把它们连接起来：第一，介绍用UM1.表达面对对象的类模型；其次.关系数据库模型.对每一个领域我们只涉及联向到我们任务的主要功能.然后捌门将关注从类模型到数据库模里映射的技术和礴.包括对象长久性，对象行为，对象和对象标识之间的关系.我们将总结对UM1.数据profile的回顾（RationalSoftware举荐1.一些面对对象设计，UM1.和关系数抠库建模的相像性也会被提及.类模型是UM1.用来表达软件系统逻辑结构的主要工件.它用来记录数据需求和模型领域内对象的行为.本文不探讨创建和具体描述

3、该模型的技术，我们将假设已经存在一个设计好的类模型,它须要映射到关系数据库上.类榛型类在UM1.中是一个基本的逻辑实体.它定义了一个结构单元的数据和行为.一个类是一个模板或运行时创建实例和对盆的模型.当开发一个陵辑模型，如UM1.中的结构层次，我们将明嫡地把它们当作类来处理.当面对动态图时，如依次图和协作图，我们也要处理类的实例和对象,以及它们运行时的内部动作.数I藏和封装原则是基于作用域效果.类有它的内部数据元素.访问这些数据元素须要通过类对外的行为或接口.遵循这个原则会生成更易于维沪的代码。一个筒触的“Person”类,没有显示状态和行为Peson Address:CAdctess Nam

4、e Age:double ge!Age)int SetAge(0 g!Name stNarreQ.cgrS2Q dMXM.OltflWTHrtJ10 eTfpro.cuaTHd)a：) to5.CM11Of rfocCMaTM0 4Cteckkch.cutt4mfk)这个例子描述了下列行为：一个主健约束（PK）;一个外键约束（FK）;一个索引约束（Index）;一个触发器（Trigger）;一个唯T约束（UniqUe）;一个存储过程（Proc）一个有效性检查（Check）.运用上面供应的标注，我们可以在DBMS层次上，对困难的数据结构和行为建模.另外，UM1.还供应表达逻辑实体间关系的标注.关

5、系UM1.数抠建模profile定义了两个表间造意一种依靠关系.它表示为一构造型的关联并包括一组主键，的卜键,数据profile仍旧须要一种关系始终参加到父类和子类之间，父类定义一个主城，子类实现一个建立于全部或部分父类主键基础上的外梃.这种关系将被区分为：”定义的（假如该子类外犍包含全部父类主健元素）和非定义的（假如只包括部分主键元素I这个关系可以包括基数性约束，以及袖成对的相关主键与外键来建模，并命名为关联角色.下图描述了运用UM1.对这种关系的建模.上图显示I父类和子类之间的标识关系，带有主螳到外槌的角色名物理模型UMI.也供应一些机制来表示数据库的整体物理结施，它的内容和部署位西.我们

6、用恂造型组件来表示一个物理;库.见下图：oDstabase*NainOraOB一个组件表示了一个留敢，可部署的实体.在物理模型中,组件可以映射到一个物理硬件（UM1.的节点X对于数SS库内的关系模式，我们用带Schema构造型的包来表示.一个表可以放国到Schema中来建立它在数据库中的范围和位置.schema*UserChMGrjndohiMGrjndpjrentParentPerson1.3从类模型到关系模型的映射我们已经描述了所关注的两个领域和它们运用的标注,现在将我们的留意力转移到如何映射，及如何从一个领域转换到另一个领域,以下采纳的策略和表达依次是建议性的，而不是必需的.果纳何种步骤

7、和过程要依据个人的须要和环境而定.1 .类的建模首先我“城设从T已经创建的类模里构建一个新的关系数据库模式.明显这是一个最简洁的方向，这是因为摸型始终在我们的限制之下，并且我们能依据类模型来优化这关系模型.在现实环境下，你可趣要在原有数抠模型之上对类模型分层，这是更难的一种状况，具有挑战性。在这里，我们只关注第一种状况,至少类模型会记录元素的关联，继承和聚合关系.2 .标识长久对象建立类模型后,我由预要将类模型的元素分成须要长久性和不须要长久性两类.例如，假如我们采纳“模型-视图-限制的设计模式来设计我们的应用程序,另蚣只在模型部分的类将须要长久状态.3 .假设每一个长久类映射到一个关系装这是

8、一个大的钱设，但是它对大多数状况有用（现在先把继承的问题放一边在一个最简洁模型中，来自逻指模型的类映射到关系表的全部或一部分。这个映射的逻辑扩展是一个单独的对象（或类的实例）映射到表中单独的“行“Parent”关存有唯一标识符（OID）,名称和性别国性，并映射到一个关系表PKAddressD:VMeHMNerrieV乐CHXROD:VMCH纸SexVMCHZR来自逻钺横型的“Address”关联成为数推模型中的外碳关系逻物模型中“Address”类变为数据模率中的一个表tb1.A4 .选择一个继承策8g继承可能是从面对对象模型转换到关系模型过程中最简洁出现问题的关系和逻辑结构.关系领域本质上是

9、平面的，每一个实体自身完成，而对象模型用常是一个具有深度的，设计完善的类层次结构.这样深度的类模型可以有多层的继承属性和行为，运行时生成最终全功能的对象：每一个类层次结构有一个单独对应的表，这个表包含全部元素的继承属性-因此，这个表是该层次结构中每个类的联合.例如，人，父母，孩子和孙子可能形成一个单独的类层次结构，并且每个类中的元素都会出现在相同的关系表中；类层次结构中的每一个类有一个对应的表，该表有仅能被该类访问的属性（包括继承属性1.例如，假如“孩子”仅仅从人继承而来，表将仅包含人和孩子”的元素；类层次结构中的每个类的自有属性对应一个表.例如，“孩子”将映射到一个仅带孩子属性的单个表对每一

10、种方法，我们有对应的案例.但是我们举荐第三种方法，因为它最简洁，最简洁维护和跟不简洁出错.第一种方法供应了运行时最佳的性能.其次种方法是第一种与第三种的折更.第一种方法绽开层次结构，在一个表里放置全部的属性，这样便利类层次结构中对类的更新和握取,但是不易于验证和维护.与行”关联的业务规则是难以实现的,因为表中的每一行都可能被实例化为层次结构中的对象.“列”之间的依靠关系可能变得相当困难.此外，对层次结构中任何一个类的更新将可能影响层次结构中其它得个类，如表中的列被添加，删除和修改.其次种方法是一师裹方案，供应了更好的封装和消退空列.可是，对父类的修改可靛须要在全部子类的表中进行复制，更糟的是，

11、有两个或多个子类的父类数据可能被冗余地存储在很多表中；假如父类的原性被修改，那么要花相当的时间去查找相关的子表，并更新受影晌的行.第三种方法精确地反映了对象模型，它将层次结构中的每一个类映射成一个独立的表.父类或子类的更新是在正确空间的局部范围内进行的.对实体的任何修改被严格限定于第个表内，因此表的推沪也就相对简洁.缺点是须要在运行时重构结构层次，来精确产生一个子类的状态,一个Child的对象可能须要一个Person”的成员变量用于表示它的父耕.由于这两者都须要加就，两次调用数据库来初始化一个对象.随着类结肉层次加深,初始化或更新一个单独对象的数据库调用次数也随之增加.当你映射继承关系到关系模

12、型时，理解上述要点是很电要的，这样你就选择最适合你的方案.5 .为每一个类添加一个唯一的对象标识符在关系和对象的领域里，须要唯一标识一个对釜或实体.在对象模型中，非长久对象在运行时通常被干脆引用或对象指针来标识。一旦对象被创建，我们可以用它运行时的标识符来引用它.但是，假如我们将对象写入存描空间，那么如何按须要得到完全相同的实例是一个问题.最便捷的方式是定义OID（对象标识符），它在关注的命名空间是被确保唯一的.依据须要，这可能发生在类，包或系统的层级上.系统级别OID的一个例子可以是一个运用微软guidgen”工具创建的GUID（全局唯一标识符），DAlA68E8E-CD92-420b-BD

13、A7-118F847B71EB.类级别的OlD可以用简洁得数字实现（如：32位计数器1线如一个对象具有对其它对象的引用，它可以采纳运用它们的OID的方法.另除，在运行时有效地将引用的对象从存储区加载到模型中.关于上述OID值的里点是它没有超出定义它为标识符的简洁含义,它们仅是逻辑指针而没有其它意义.在关系模型中，状况往往是不同的.关系模型中标识正常地用一个主键实现,主鞋是一个表中的一组列，它们合起来可以唯一地标识一个行.例如：名称和i址可以唯一地标识一个“客户二其它实体，如：销售员引用客户，它们要实现基于客户主键的外键,这个方法存在的问鹿是：将业务信息（如客户名和地址）嵌入标识符中对我们目标的

14、影响.设想三个或四个表全部具有基于“客户”主键的外键，对于一个须要修改客户主键（如：增加一个用户类型）的系统修改，那么既要修改客户表，也要修改与外键相关的实体，这个工作是特别巨大的.另一方面，赖如一个OID被当作主键实现，并为其它表建立外键，月及修改范围仅限于主表,并且修改的影响也因此大大减小.事实上,一个基于业务数据的主键或许会被修改.如：一个客户可以修改地址和名字，既然这样，这个变更须要被正确的传递到全碍它相关的实体，更不用提变更部分主键信息的困难。一个OID忌是引用同T实体，而不管其它信息怎么变更.在上面的例子中，客户可以修改名称和地址，与它相关联的表不须要被修改.当把对敷模型映射到关系

15、表时，实现完全OlD的标识符比采纳业务联系的主键更加便捷.用OlD做为主犍和外犍的方法将为对象供应更好的加载和更新效率，将维护服务减到最少.事实上，一个与业务相联系的主键可以替换为： 一个唯一性约束或相关列的索引； 派入类行为的业务规则； 或将上述两种结合起来.再次生申，是运用有意义的键还是运用OlD取决于被开发系统的实要.6 .映射属性到列通常，我们将简洁的类数据跟性映射到关系表的列。例如，一个文本联字字段可以分别表示一个人的名字和年龄，这种干脆映射不会引起什么问题，只是简洁地在数据库服务商的关系模型中选择适当的,与类属性相对应的数据类型.对困难属性（即属性为其它对象）运用下面具体的步赛来处

16、理关联和聚合关系。7 .映射关联到外健更困难的美属性（即它由城表其它类）通常建模为关联关系,一个关联是对象间的结恂关系.例如，一个人可以居住在一个地址，当这个人被建模，他会有城市，街道，郃编的属性.在对象和关系领域里，我们倾向于把这个信息当作单独蹴体来构造：地址在对象领域里，地址代表一个独一无二的物理对象，并可能带有一个唯一OlD.在关系领域，一个地址可以是地址表中的一行，该表的主健被用作为其它实体的外犍.在这两种模型中，趋向于移动地址信息到独立实体，这有助于避开冗余数据和提高可维护性.所以对于每一个类模型中的关联，要考虑创建一个从子类到父类表的外健.此关系基千“外窿一主嫌”对，该例用适当的外

17、犍和主像来联系植害员和客户。这里假设一个客户仅与一个销生员关联。8 .映射聚合和复合鬃合和复合关系类似于关联关系，并通过主健-外援”对来映射成表.但是,须要提示的是：一般聚合（弱聚合）对关系建模，如：一个人住在一个或多个地址，在此例中，超过一个以上的人可能住在相同地址，假如这个人不在这里住了，与他相连的地址仍旧存在.这个例子例举了关系术语中称之为多对多的关系，并且通常实现为一个独立的表，该表包含了从一个表格的主耀到另一个表格主犍的映射.弱聚合的其次个例子是：一个实体在那里运用或解除了另f实体的全部权.例如：一个“人”的实体拥有一组股票，这标明这个人可能与一个股票表中的某些股票有关联，也可能没有

18、关系.但是每个股票可以联系一个人，财与任何人发生关系.假如这个人不在了，这个股票将变为无主的，或者被传递给下一个人.在这个关系摸型中，可以通过每个股票有一个“全部者“列来实现，这个“全部者”列将存储T人的标识符（OID）.强聚合形式则有与之关联的完整约束。豆合表明一个实体由部件组成，并且这些部件对整体有依先关系.例如：一个人可以有很多证明文件，如护照，诞生证明，驾照等.这个人的实体可以由这样的一组文件组成假如这个人从系统里嬲除用B么证明文件也要被删除,因为这些文件被映射到一个唯一个体.假如我们短哲忽视OID,弱聚合可能运用中间表来实现（对多对多的状况）或者在一个聚合的类或表采纳一个外犍来实现（

19、一对多的状况1在多对多关系的状况下，假如父类被捌除，中间表中的实体也要被删除.在一对多的状况下，1但如父类被删除，外键输入（如“全部者”）必需被清除.在复合的状况下，夕隧的运用是强制的,约束条件是父类删除后,部件也必需被删除.谡箱上,豆合是有一种含义,部件主蛙形成了全部主键的一部分.例如：一个人的主键由他证明文件组成.尽管事实上是相当冗长的，但逻辑关系上为真.9 .定义关系作用对于每一个关联关系，可能会进一步指明关系每一个端点的角色信,息.通常包含主键约束名和外犍约束名.图6例示了这个概念，这在逻辑上定义两个类之间的关系.另外，可能会在作用名上标明附加约束（即（非空）和基数性约束（即0n）.1

20、0 .模型行为我们现在来探讨另一个难题：是映射部分还是全部的类行为到数据庠商供应的功能上，这些功能以触发龈,存储过程，唯一性,数翅约束和关系完整性的形式出现.一个非长久对象模型通常可以实现一种或多种语言（如Java和C+）须要的全部行为。每一个类将用公共的，爱沪的和私有的方式描述它被给予的行为和职责.不同数据库商的关系数据库通常包含不同形式的，基于SQ1.的可编程脚本语言,用来实现对数提的操作.最淮用的例子是触发器和存储过程.当我们混合对象和关系模型，要做的确定往往是：是实现类模型中全部的业务浸辑,还是将部分的业务逻相放在关系DBMS中更常用而有效率的H蛾器和存储过程中。从完全面对对象的角度吞

21、，答案是避开运用触发器和存储过程，并且将全部行为放到类中.这样会使行为局部化，从而供应了一个更清晰的设计，简化了维护,并且供应了在不同DBMS供应商之间更好的移植性.在现实世界,存储过程不睡发器的设计目标底或可以是每秒至少执行几百次或几千次之务.软如为了追求模型的清晰，移植性，可维护性和敏捷性，那么就将全部的行为放在对象方法中，假如性能是关注的焦点，可以考虑将部分行为交给更有效的DBMS编程语言.留息到将对象模型与存储过程以平安方式集成所花的额外时间，包括远程影响和调试的问题，可能要比简洁部署更高性能的硬件更多.如前面所述，UMl数据profile供应下列扩展(构造型操作)，可用来对DBMS行

22、为建模： 主艇约束(PK); 外键约束(FK); 索引约束(Index); 触发器(Trigger); 唯一性约束(Unique); 有效性检直(CheCk).11.产生物理模型在UM1.中，物理模型描述了物体如何在现实世界里部署:硬件平台，网络连接,软件，操作系统，动态连接库和其它组件.你须要生成T物理模型来完成这个周期：从一个初始的用例或领域模型，到类模型和数据模型，最终到部署模型.通常对这个模型，你要创建一个或多个节点，这些节点可以存放数据库，并安装DBMS组件.假如数据库被分成多于一个的DBMS实例，你可以安排表的包Schema给单个DBMS组件来指明数掴位置.MainScrvcvWU

23、inOiMBSystemSysjxocs8ysjugssjabte58ys-user修改订单.用例执行时，listorders1列出订单用例被调用执行.一个用例可以被T或多个其它用例包含。通过将通用的行为提炼成可以多次生复运用的用例，有助于降低W能至豆级Sl1.通常,在特殊状况下，一个用例可以扩展另一个用例的行为。例如：低如一个用户在惨改一个特殊类型的客户订单之前,该用户必需得到某种更高级别的许可，然后“获得许可”用例.依次图依次图供应地时间变更，对象交互的图形化描述.通常用来表现一个用户或执行者，对效和组件，以及它们在用例执行过程中之间的交互,一个依次图典型地表示一个单独的用例情形或事若流.

24、依次图可以精彩的显示文档运用情形，既可以记录早期分析的所需对象，也可以在稍后的设计阶段睑证对象.它显示一个对象到另一个对象的消息流，这些消息流对应看一个类和对釜支持的方法和事务.下面依次黝标了左侧的用户或执行者初始化事务和消息流，它们对应于用例情形,在最终模型中，对象间传递的消息变成类的操作.?Cuorf1.oginValKJatelber0JxyManagerlher3e!aibResuHJVaIioatQ：C*UwS0tal6执行图用例是对所构造系统将有功能的正式描述。与用例关联的执行图用来设计元素（如：组件和类）和实现用例在新系统中的功能.这为系统设计者，客户和团队,这些实际建立系统的人

25、，供应了高级别可跟踪实力。组件和类连接的用例列表说明白必需被组件执行的或少功能.1011.OflQntotheWebtae,froPormafeq,urmSaiIfrDmUserhfeffacet结束所可能采纳的推断方式,他们也图示某些活动执行中，并行处理可能发生在那里。状态圉(statecharts)状态图用来具体描述系统中，对象经验的状态转移和变更.它们显示一个对领如何从一个状态到另一个状态，以及限制这种变更的规则，通常有f5fc和结束状态.End过程模型过程模型是UM1.活动图的扩展，用于业务过程建模-该图显示这个过程的目标，过程的同入，筠出，事务和所包含的信息.2.3业务过程建模2.3

26、.1 介绍比起业务分析与建模来，UM1.在过去与软件工程和系统设计的联系更加紧茁.并且，UM1.2.X标准供应了丰富的行为模型，这对于过程、活动、及对每一个业务部生要的人与信息等的建模特别有用.除标准的UM1.规范外，还有两个备受关注的UM1.扩展，它们进一步强化了对业务过程和相关结构的建模,第一个是业务过程建模标注，它已经广受欢迎，并快速成为业务过程建模与设计的新标准.其次个是Eriksson-PenkerProfile,虽然不另必流行，但在可视化、业务过程间通信、以及企业（组织）内部的信息流方面，仍旧是独一二的.本文将对这两种扩展供应深化介绍，阐述如何在EnterpriseArchitec

27、t中运用它们以及他们所用的通用模型结构.2.3.2 业务过程建模标注（BPMN）BPMN定义了一种业务过程图（BPD）,该图是基于一种特地绘制流程图技术，用于业务过程的图形化建模.无论是创建业务过程草图的业务分析师，还是负责实现这个过程的技术开发人员，或者管理、监督业务过程的相关人员，全部的业芬人员都简洁理解这种标注.一个BPMN模型是由一组简洁图构成，每一个图又包含一组图形元素.2.3.2.1 流程元素1 .活动（Activity）:一个活动是业务过程中执行的一个作业，用圆角矩形表示2 .事务（Event）:一个事务是在业务过程的流程中发生的，并膨响业务过程中活动的执行依次与执行时间的事情.

28、事务用带有不同边界的小圆表示，以区分初始事务（细实线中间事务（双实线），海止事务（相实线1在图形内部显示图标以便于区分触发能和事务结果.3 .关口（Gateway）:关口用来限制依次流如何在过程内进行合并和分岔.关口可用来表示推断点，可以表示一个或多个路径在此处不能通过.关口也可以表示一条路径在此分岔.4 .依次流：依次流用来表示活动在业务过程中的执行依次.依次流用有实箭头的线表示。5 .消息流：一个消息流用来表示两个实体之间的消息流向.实体用池来表示，消息用虚线在源端连接浅颜色的圆并在目标端连接箭头.6 .关联：关联是用流对象将信息与制品联系起来.关联采纳虚线表示并在目标端有或者没有箭头，依

29、据须要而定.2.3.2.2 泳道（分割）1 .泳池：表示一个业务过程中的参加者.一个参加者可能是业务实体或者角色.泳池表示了对业务过程的一种划分.2 .泳道：是泳池的再划分,用于组织和分类泳池内的活动.2.3.2.3 过程要素1 .数掴对象：一个数抠对象对一个业务过程i殳有干能的影Q同，但供应信息给相关的过程,数据对象用一个上角折抬的走形来表示.2 .组：组供应了对过程内的元素进行分组的非正式手段，用虚线的矩形表示.3 .注解：注解供应一种机制使得BPMN的模型建立者为BPMN模型的用户供应附加信息.它是用T开口的矩形表示,注解文字写入其中.2.3.2.4 BPMN示例例1：上面的图展示了BP

30、MN的几个主要功能.特殊是将一任务过程进行层次分解成较小的任务.以及能表示循环结构和夕倍事务干扰正常过程流程.上行活动”和下行;舌动”是连接触发的中间事务，换句话说，是页面间承上启下的连接器.对每个供应商重复执行”是一循环活动,它对每一个供应商重定执行所包含的三个活动，或者直到时间限制已到.固定在活动下边沿的终止事务是一时间事务触发器。例2:上面的图表示一个业务过程由一个事务开启,在本例中,一个消息触发器产生一个事务，该事务通知业务过程活动组处于活动状态。该图也显示一个由时间事务限制的循环，并显示一个决策关口（在本例中是“异或”决策关口）限制什么时候偌环该结束.例3：!Hi杓通知AI收到病入旧

31、家r溜温-该图例示运用泳池来表达过程间的交互以及运用消息流连接器来表示消息在泳池间进行传递的方法2.3.3 Eriksson-Penker业务Profile本节介绍业务过程模型所运用的术语与图标。并简要介绍一些基本UM1.建模语言概念以及如何在EA的业务过程建模中如何运用它们.一个业务过程：1 .有一个目标2 .有指定的输入3 .有指定的输出4 .运用资源5 .有按某种依次进行的一组活动6 .可能影响多个组织单元，造成横向组织影响7 .为客户创建某种价值，客户可能是内部的，也可能是外部的.2.3.3.1 过程模型一个业务过程是T活动的集合，用于为特定的客户或市场产生指定的输出.与产品所强调的“

32、过程是什么不同,业务过程强调作业在组织内部是如何进行的.指定在不同时间和地点的作业活动依次，带有一个起先和一个结束，并清晰地定义输入和输出：一个动作结构.始于对象信息供应链,供应链是指连接到过程的信息或对象在处理阶Esi殳有被运用完.例如，订单模板可能翱运用，并供应特定样式的新订单.作为这个活动的一部分，这个模板不会更改和被消耗光.始于对象资源的供应造：一个输入供应Ia是指所连接的对象或资源将在处理过程中被消耗.例如，当消费者的订单在被处理后，它。泄标记为完成并签字，并且每个资源仅运用一次. 成终对象目标的目标链：一个目标链是指连接到业务过程的对象描述业务过程的目标.目标劭行S动的业务宗旨. 对象流连接对象输出 始于事务的对象流：一个对象流连接是指在一业务过程一些对象被传递.它强调对在实体之间或过程之间所传递信息的限制.2.3.3.2 目标一个业务过程有一些定义完备的目标.这也是组织制定业务过程的缘由所在.并且这些目标的制定