第五章-UML核心模型课件

《第五章-UML核心模型课件》由会员分享，可在线阅读，更多相关《第五章-UML核心模型课件（57页珍藏版）》请在金锄头文库上搜索。

1、第五章第五章 UMLUML核心模型核心模型 UMLUML的模型是提出论点，静态图是论的模型是提出论点，静态图是论据，动态图是论证；建模的过程就是采据，动态图是论证；建模的过程就是采用论据来论证论点的过程。用论据来论证论点的过程。 论点的提出是由软件生命周期的需要论点的提出是由软件生命周期的需要确定的确定的本章要讲解的模型包括： 业务用例模型 概念用例模型 系统用例模型 领域模型 分析模型 软件架构模型和框架模型 设计模型 组件模型 实施模型5.1 用例模型概述用例模型在统一过程中占据十分重要的地位： 它是面向对象软件过程的骨架开发过程中一切工作的组织框架； 它是面向对象软件过程的神经系统用例驱

2、动过程； 它也是面向对象软件过程的血肉需求的来源，测试的依据 用例模型是系统既定功能及环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。用例模型即为需求工作流的结果，可当做分析设计工作流程及工作流程的输入使用。 到这里为止，我们只是粗略窥视了用例模型的综合概念。我们谈到过用例有三个层次解释：业务用例、概念用例、系统用例，自然地，用例模型也就有业务用例模型、概念用例模型和系统用例模型三个层次的模型，如图5.2所示。 三种用例模型的关系 这三种用例模型分别在软件开发的不同生命周期阶段发生作用，业务用例模型用于识别和规定业务需求，概念模型用来分析和确认业务需求，而系统

3、用例模型用来规定系统开发需求。这三者之间是一种精化的关系。5.2 业务用例模型 业务用例模型业务用例模型描述一个业务的流程以及它们与外部各方（如客户和合作伙伴）之间的交互。 由业务用例业务用例和主角主角构成的模型的主要目的是说明客户和合作伙伴是如何开展业务的。直接与客户或合作伙伴相关的活动以及与外部各方并不直接相关的支持和管理任务都可以在模型中给出。 为什么要建立业务模型？ 业务用例模型的目的是为现存的或客户预想中的真是业务建立模型，是我们为了理解客户的业务，并与客户达成业务理解上的共识而建立的你模型，它不需要考虑计算机环境。相对于系统模型来说，业务模型是对现实业务的一种直观的理解，而没有加入

4、其他的因素，因而更加容易在客户和开发双方达成共同理解。业务用例的不同类型业务用例的不同类型 当考查业务中的活动时，您至少可以确定三类工作，它们对应着三种业务用例类型。 第一类是在商业上比较重要的活动，常称为业务流程。 第二类是在商业上不太重要的活动，但必须进行这些活动来保证业务正常运转。系统管理、清洁和安全等工作就是这类活动的示例。该业务用例具有支持的性质。 第三类是管理工作。具有管理性质的业务用例所显示的工作影响如何管理其他业务用例以及该业务和其所有者的关系。 我们有三种关系用于建立业务用例模型。使用这些关系，您可以将那些可以在其他业务用例中复用的、或者作为该业务用例的特化或选项的部分业务用

5、例分离出来。我们将代表修改的业务用例称为附加用例附加用例。被修改的业务用例称为基本用例基本用例。 如果基本用例的某个部分代表一个功能，而业务用例只依赖于本功能的结果，而不是产生结果的方法，那么您可以将这部分分离出来，形成一个附加用例。使用包含关系，将附加部分明确包含于基本用例中。 如果基本用例的一部分是可选的，或对于理解该用例的主要目的来说不是必需的，那么您可以将这部分分离出来，形成一个附加用例，以简化基本用例的结构。利用扩展关系，将附加部分隐含地包含于基本用例中。 如果几个业务用例在行为和结构上具有共同点，同时在目的上又很相似，则可以将它们的共同部分分离出来，形成一个基本用例（父用例），该基

6、本用例被附加用例（子用例）继承。子用例可以在从父用例继承的结构中插入新的行为或修改现有的行为。 下图展示了登记处的主角和用例。这里，我们还显示了包含用例“行李处理”(Baggage Handling) 和扩展用例“通过登记处”(Through Check-In)。 5.3 概念用例模型概念用例模型位于先启阶段，有时在精化阶段进行，是业务用例建模的一个子集。该模型在统一过程的官方文档中并未强调建立，也没有专门的流程来完成它们。但是该模型在实际工作中比较重要。 当系统规模较大的时候，业务用例的粒度相应也会比较大。通常一个业务用例所能描述的业务很粗略，而系统用例由于必须适应软件开发的需要，其粒度需要

7、小。由于种种原因，我们需要一种“分解”的方法来处理较大的业务用例，从中找出核心的工作单元，这就是概念用例。概念用例模型的主要内容（1）概念用例视图 概念用例视图将得到的概念用例包含、泛化、扩展关系连接到基本业务用例，表示这些概念的来源及它们服务与哪个或哪些业务用例。（2）概念用例分析 是从业务用例模型中挑选出中重要和典型的业务用例场景，可能只是部分场景，也可能是跨多个业务用例，然后将得到的概念用例集中起来，绘制这些概念用例如何贡献或者说如何实现这些业务用例场景。（3）分析类视图 分析类视图绘制出从概念用例分析过程中抽象出来的分析类的静态关系。分析类得到我们理解系统实现的第一个关口。（4）分析场

8、景 分析场景使用分析类绘制对象图，从对象的角度去实现概念用例分析场景。这些结果将对下一步建立软件架构和决定系统用例产生影响。 概念用例通常使用的UML视图如图所示：5.4 系统用例模型什么是系统用例模型？ 官方文档中系统用例模型系统用例模型定义为系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。用例模型即为需求工作流程的结果，可以当作分析设计工作路程以及测试工作流程的输入使用。 在统一过程中，系统的功能性需求完全由用例模型来表达。 下图展示的工件都是建立用例模型需要完成的。完整的用例模型系统用例模型的主要内容（1）业务用例 在系统用例模型中用例

9、使用精化关系连接到业务用例，表明软件过程的可追溯性，说明哪些用例是从哪个或哪些业务用例演化出来的。（2）概念用例 概念用例对用例模型来说只起到获取用例的指导作用。（3）用例视图 包括参与者与用例，是系统功能性需求的高层视图。（4）用例规约 采用文档形式描述参与者如何启动和终止用例，参与者如何使用用例完成目标。（5）补充规约 应说明与用例相关的非功能性需求。（6）业务规则 是客户执行其业务必须遵守的法律法规、惯例、各种规定，也可能是客户的操作规范、约束机制等。（7）用例实现 一个用例实现是用例的一种实现方式，通常代表不同的应用环境。（8）用例场景 说明参与者如何与计算机之间交互以达成其目的。可使

10、用交互图来描述。（9）分析对象 分析对象是用例场景中代表计算机逻辑的概念化产物。它是将来分析模型的重要来源。5.5 领域模型 领域模型用来对问题领域中某个我们关心的问题来建立对象（领域类）模型，它代表系统工作环境中存在的“事情”或发生的事件。例如网上购物整个过程中定单对象与其他对象的关系模型和交互模型；通过网上交易时支付账号与交易合同、安全控件、网银接口等的关系模型和交互模型等。一般来说，领域类有三种典型的形式： 业务对象，表示业务中使用到或产生的东西。业务对象，表示业务中使用到或产生的东西。如定单、账号、合同等。 系统需要处理的现实世界中的对象和概念。系统需要处理的现实世界中的对象和概念。如

11、商品、买家、卖家等。 将要发生或已经发生的事件。将要发生或已经发生的事件。如购买、撤单、付费等。 领域模型可以帮助我们理解问题领域中的关键概念和关键对象，帮助我们理解这些对象如何工作，以及如何解决问题。例如在网上交易中，安全是一个重要的课题，那么我们就可以专门为安全解决方案建立领域模型。 在大多数情况下，没有业务模型的指引而直接建立领域模型是比较困难的，事实上它需要建模者对业务有相当了解，同时具备相当的面向对象分析设计功力才能够从复杂的业务中直接找到那些关键而复杂的问题领域。如果通过业务模型来推导，则事情要简单得多。因为在建立业务模型过程当中我们已经能够体会到那些对实现业务最为关键和核心的问题

12、，知道了关键怕业务对象，也知道了业务过程中的交叉和重合，这些信息都对我们发现和建立领域模型相当有用。你需要做的是从业务场景出发，针对某些重要的业务问题来建立领域模型，再用业务对象去验证该模型。所以笔者建议先建立业务模型，再来推导领域模型，见图5.6。图5.6 领域模型推导何时使用领域模型？ （1）为非交互密集型的软件建立领域模型。 （2）为交互密集型软件中交叉和重叠的对象建立领域模型 在交互密集型的软件里，当问题领域比较复杂，一项业务涉及很多对象，并且对象之间相互影响很频繁时，常常需要建立领域模型。例如许多管理系统大部分功能都是针对某项数据的增删改查，建立领域模型必要性不是很大，但如果是一个生

13、产系统，各部门相互写作很多，一件产品历经很多生产线、管理线，则为产品的整个生命周期建立领域模型就很有意义。5.6 分析模型 分析类一节中已经介绍过，分析类用于获取系统中主要的“职责簇”。它们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。分析模型则使用分析类来建立系统原型，获得系统实现需求的第一手方案。 在统一过程中，分析模型被定义为一种可选模型，是从需求向设计模型转化的过渡。但是在自己的工作实践中，分析模型占据了很重要的地位，其重要程度甚至高于设计模型应当成为面向对象设计的核心。分析模型的地位 分析模型是采用分析类在软件架构和框架的约束下来实现用例场景的产物。如果分析类完全实

14、现了这些用例和场景，我们就能肯定地说分析类已经满足了需求。 分析模型是高层次的系统视图，在语义上，分析类不代表最终的实现。它是计算机系统元素的高层抽象。分析类具化以后才产生真正的实现类。 相对而言，设计模型只是分析模型的一种实现手段，分析类具化以后才产生真正的实现类。如果分析模型建立得很好，再具体化分析类形成实现类是很容易的。 分析模型是MVC模式的经典应用。从分析类的名称就可以看出来。5.6.1 如何使用分析模型 由于分析类采用了MVC模式，所以在定义分析类之间关系的时候，应当注意以下几个原则： （1）边界类不应当与实体类之间有依赖关系。边界类只能通过控制类与实体类交互。 （2）实体类和实体

15、类之间可以有聚合或组合关系，但不应当有依赖关系。它们不应当直接交互，而只能通过控制类间接交互。 （3）控制类和控制类之间不应当有聚合或组合关系，如果可能，应当尽量减少依赖关系。 （4）正确的依赖关系应当是边界类依赖于控制类，控制类依赖于实体类，而不能反过来。 定义了备选的分析类的关系以后，进一步仔细地观察它们，如果需要，应当采用面向对象的思考方法来进行调整和优化。调整分析类主要原因和手段主要来自以下几个方面： （1）业务规则 业务规则作为分析类交互的一个约束存在，它是需要调整分析类的重要原因。尤其应当关注那些复杂的、将来可能会经常变化的那些规则。它可能需要在某个分析类上加一个状态，也可能需要将

16、业务规则单独取出来作为一个分析类，甚至可能专门就规则的动态变化作为一个问题领域建立领域模型。 （2）结构优化 根据面向对象的原则，应当尽量减少对象之间的耦合度。仔细查看备选的分析类，如果分析类之间的关系呈网状，那么就应当考虑调整这个结构。常用手段有加入中介类，让刚定结构呈星形结构；或者使用门面模式，将分析类的关联关系集中起来。另一个办法是将对象之间的关系抽象出来，专门用一个关系类来存取对象间的关系。这在UML中被称为关联类。 （3） 分离职责 对象越简单越容易维护。如果一个分析类负责的事情太多，则应当考虑将它分解为几个各负一部分责任的类。5.6.2 分析模型的主要内容 分析模型架起了现实世界的

17、需求和对象世界的桥梁，架起了软件架构和系统实现之间的桥梁，架起了组件和对象之间的桥梁，也架起了对象和实施之间的桥梁。这就是为什么分析模型很重要的原因。完成了分析模型，也就完成了系统的原型，接下来的工作都将围绕着分析模型进行。因此，在分析设计过程中花费精力维护分析模型是十分值得的。 图5.9展示了分析模型的主要内容。图5.9 分析模型的主要内容5.6.3 分析模型的意义 分析模型采用MVC模式，将用例场景中描述的业务分解为边界（操作界面和展示界面）、控制（业务逻辑）和实体（业务数据），用这三个元素建立实现用例场景的对象模型。 分析模型一方面为我们提供了系统如何实现需求的理解，一方面为下一步演化到

18、设计模型提供了极好的输入。何时需要单独的分析模型? (1)需要设计在多目标环境下使用、带有独立设计构架的系统时，独立的分析模型就非常有用。分析模型是设计模型的抽象或泛化关系。为了概述系统功能，它省略了设计的许多细节。 (2)由于设计的复杂性，因此在向新的团队成员介绍设计时就需要使用简化而抽象的“设计”。此外，明确定义的构架可起到相同的作用。 (3)在考虑建立分析模型所带来的益处时，必须权衡为确保分析模型与设计模型保持一致性所需的额外工作，因为该模型只代表系统运行方式的最重要的细节。保持分析模型和设计模型之间高一致性的成本极其昂贵。一个折中的方法可以是分析模型仅具有设计中最重要的领域类和关键的抽

19、象概念。维护分析模型的成本随着其复杂性增加而增加。 （4）一旦不再对分析模型进行维护，则其价值将迅速衰减。从某种意义上说，如果它得不到维护，则它因为无法精确地反映系统的当前设计而将失去使用价值。决定不再维护分析模型也许是正确的（它可能已经达到其目的），但是这种决定应该是明智的。 实践证明，对于那些系统使用寿命有数十年或系统有许多版本的公司来说，独立分析模型常有用。5.7 软件架构和框架架构和框架架构和框架 现实中，很多人把架构和框架搞混，有的人认为架构和框架就是同一个东西。实际上架构和框架是非常不同的。框架是针对某个问题领域的通用解决方案，它通常集成了最佳实践和可复用的基础结构，对开发工作起到

20、减少工作量、指导和规范作用。 如果用建设一幢大楼来比喻，架构就是大楼的结构、外观和功能性设计，它需要考虑的问题可以延展到抗震性能、防火性能、防地表下陷性能等；而框架则是建设大楼过程中一些成熟工艺的应用，例如楼体成型、一次浇灌等。再举另一个例子，可以说架构是战略性的，它描述部署、职责、战略目标、指挥系统、信息传递等：框架则是战术性的，它描述组织、建设、作战方案、命令下达、战术执行等。5.7.1 软件架构 对于软件来说，架构需要描述两个方面的内容。这两个方面分别针对业务领域的理解和系统领域的理解，我们可以称之为业务架构和软件架构。这两者是需要和谐统一的。5.7.1.1 业务架构 目标：为业务领域建

21、立一个维护和扩展的逻辑结构，描述业务的构成，它是软件架构的重要输入。 来源于两个主要输入：业务用例和领域模型。 业务架构可以使用领域包和组织结构包来表示业务主要领域和组织结构关系。如图5.10所示。它展示了一个网上购物系统的业务架构示例。图5.10 业务架构业务架构所需要的文档 （1）描述每一个领域包的职责、与其他领域包的关系，例如门户网站负责什么，它与购物中心之间通过什么机制交互。 （2）在文档中引用用例模型来阐述典型业务是如何在这个业务架构中运行的。 （3） 对一些重要的领域，例如购物中心，使用领域模型来解释它如何运作。5.7.1.2 软件架构 一个典型的软件架构包括两个视角，广度视角和深

22、度视角，这两个视角构成对软件架构的“立体”描述。广度视角即是常见的软件层次结构，它关注软件的分层，规定每一层的职责以及层之间的通讯标准。一般使用层包元素来绘制。图5.12展示了一个典型的多层架构的层次模型图5.12 软件层次广度视角架构图 另一方面，软件架构还需要描述深度视角。所谓深度视角，是指广度视角中每一层的详细说明，它关注每一层以及每个部分的具体实现架构。例如可以针对业务实体层进行架构描述，也可以针对XMLBean进行架构描述。图5.13展示了业实体层的深度视角视图。图5.13 软件层次深度视角架构图5.8 设计模型 概念：通俗地说，设计模型就是我们所熟知的详细设计。它采用设计类绘制，它

23、需要考虑实现语言、架构、框架、编程模型、规范，目标是用程序逻辑来实现用例。图5.15展示了设计模型的主要输入。图5.15 设计模型的主要输入5.8.1 设计模型的应用场合 软件架构场合 软件架构是非常高层次的系统视图，对于系统规划和设计来说需要这样的高层次抽象。但具体到编码实现时，开发人员未必能够理解和掌握软件架构。这时，软件架构师就需要用一个设计模型来解释软件架构如何运行，以及描述应当如何使用架构的编程模型。图5.13所示的软件层次深度视角就是这样的设计模型。如果再加上协作图，描述架构运行的原理，开发人员就能够知道架构如何运行，编码时应当怎样使用架构。 软件框架场合 软件框架是一个半成品，包

24、括一系列的类库和编程模型。对于开发人员来说，如何使用框架有时候是一个问题。这时，系统设计师应当建立一个设计模型来解释框架如何运行，如何使用框架的类库以及开发时应当怎样遵循编程模型。 典型场景场合 虽然不必用设计模型实现全部的用例，但是从用例中抽取出典型的场景建立设计模型也是很有必要的。它将成为开发人员的指导和规范。例如对大多数管理系统来说，大量的应用场景都是针对数据的增删改查，我们显然没有必要为所有的场景建立设计模型，只需要从众多场景中抽取出一个来建立能够完成增删改查的设计模型就足够了。这个设计模型需要描述出与增删改查相关的那些框架中的接口和类，增删改查的使用方法等，这样开发人员举一反三就能够

25、实现其他增删改查的场景。5.8.2 设计模型的主要内容 与分析模型类似，设计模型也是用对象来实现用例的。不同的是，分析模型采用分析类而设计模型采用设计类。我们知道，分析类抽象层次高于实现方式和实现语言，所以不需要处理过多的细节；而设计类与实现方式与实现语言有关，例如如果决定使用Java作为编程语言，在使用设计类实现用例的时候就需要考虑到Java的语言特性。 图5.16展示了设计模型的主要内容，可以发现，它与图5.9所示的分析模型非常相似。图5.16 设计模型的主要内容5.9 组件模型 在分析模型和设计模型两节的描述中可以清楚地看到，组件总是用来容纳分析类或设计类的。从这个角度说，可以把组件理解

26、为一种特殊的“包”，只不过普通的包起到组织和容纳的用，而组件的组织行为却有着特别的目标：这些分析类或设计类被组织起来完成一组特定的功能。 组件的四个特性：完备性、独立性、逻辑性和透明性。 如何组织代码来保证这些特性呢？答案是架构。定义组件的目的（1）这些组件将成为可复用的单位。（2）每个组件都有一组特定的功能。（3）这些组件将成为可独立部署的单位。（4）这些组件将遵循架构规范。5.9.1 何时使用组件模型 在建模时，应当根据实际情况决定是否需要组件。在以下的场合中，你可以决定不使用组件图，反之则应该建立： 如果你所实施的项目不是一个分布式系统，通常没有必要为组件建模。 如果你所实施的项目不需要

27、向第三方提供支持服务，通常没有必要为组件建模。 如果你所实施的项目中没有将某部分业务功能单独抽取出来形成一个可复用的单元，在许多系统或子系统中使用的要求，通常没有必要为组件建模。 如果你所实施的项目没有与客户其他现存系统或第三方系统集成的要求，通常没有必要为组件建模。 如果你所实施的项目没有采用架构开发，尤其是没有遵循应用服务器厂商（如 Websphere、Weblogic）的架构，则没有必要为组件建模，因为缺乏部署环境和运行环境。5.10 实施模型 实施模型由配置节点和组件组成。其中配置节点使用节点元素绘制，它用来描述系统硬件的物理拓扑结构；组件使用组件元素绘制，它用来表示在配置图中描述的结

28、构上执行的软件。通常实施模型在分布式系统中使用，它可以描述硬件设备的配置、通信以及在各硬件设备上各种组件和对象的配置。 图5.20展示了一个论坛系统组件实施模型。图5.20 实施模型示例一何时使用实施模型 实施模型相对是比较简单的，脱离开UML，许多项目中也有自己的所谓“实施模型”。以下可以说明实施模型的使用场合。 （1） 如果你正在从事分布式系统，出于描述各种资源在不同节点上的分布情况，应当使用实施模型。 （2） 如果你正在从事的系统需要与来自多方的程序、模块等交互，出于描述这些程序的分 布情况，应当使用实施模型。 （3）如果你正在从事的系统具有多个硬件设备，例如与POS机相关的应用系统，出于描述可执行程序在不同硬件设备上的分布情况，应当使用实施模型。