软件工程讲义 第10章 构件级设计建模要点课件.ppt
现代软件工程,第10章 构件级设计建模,主要内容,什么是构件设计基于类的构件实施构件级设计对象约束语言设计传统构件小结,构件级设计建模,一套完整的软件构件是在体系结构设计过程中定义的。但是没有在接近代码的抽象级上表示内部数据结构和每个构件的处理细节。构件级设计定义了数据结构、算法、接口特征和分配给每个软件构件的通信机制。,构件级设计建模,必须能够在建造软件之前就确定该软件是否可以工作。为了保证设计的正确性，以及与早期设计表示（即数据、体系结构和接口设计）的一致性，构件级设计需要以一种可以评审设计细节的方式来表示软件。它提供了一种评估数据结构、接口和算法是否能够工作的方法。,构件级设计建模,数据、体系结构和接口的设计表示构成了构件级设计的基础。每个构件的类定义或者处理叙述都转化为一种详细设计，该设计采用图形或基于文本的形式来详细说明内部的数据结构、局部接口细节和处理逻辑。设计符号包括UML图和一些辅助表示。通过使用一系列结构化编程结构来说明程序的设计。,构件级设计建模,每个软件的设计都以图形的、图表的或基于文本的方式表示，这是构件级设计阶段产生的主要工作产品。采用设计走查或审查机制。对设计执行检查以确定数据结构、接口、处理顺序和逻辑条件等是否都正确，并且给出早期设计中与构件相关的数据或控制变换。,构件级设计建模,体系结构设计第一次迭代完成之后，就应该开始构件级设计。在这个阶段，全部的数据和软件的程序结构都已经建立起来，其目的是把设计模型转化为运行软件。但是现有设计模型的抽象层次相对较高，而可运行程序的抽象层次相对较低。这种转化具有挑战性，因为可能会在软件过程后期阶段引入难于发现和改正的微小错误。,构件级设计建模,用编程语言表示构件级设计是可以的。其实，程序的创建是以体系结构设计模型作为指南的。一种可供考虑的方法是使用某些能够容易转化为代码的中间表示来表示构件级设计。无论采用何种机制来表示构件级设计，定义的数据结构、接口和算法应该遵守各种已经精心规定好的设计指导准则，以避免在过程设计演化中犯错误。,什么是构件,通常来讲，构件是计算机软件中的一个模块化的构造块。OMG UML规范将构件定义为“系统中某一定型化的、可配置的和可替换的部件，该部件封装了实现并暴露一系列接口”。构件存在于软件体系结构中，因而构件在完成所建系统的需求和目标中起重要作用。由于构件驻留于软件体系结构的内部，它们必须与其他的构件和存在于软件边界以外的实体进行通信和合作。,面向对象的观点,在面向对象软件工程环境中，构件包括一个协作类集合。构件中的每一个类都被详细阐述，包括所有的属性和与其实现相关的操作。作为细节设计的一部分，所有与其他设计类相互通信协作的接口必须予以定义。为了完成这些，设计师从分析模型开始，详细描述分析类和基础类。,面向对象的观点,考虑为一个高级印刷车间构建软件。软件的目的是为了收集前台的客户需求，对印刷业务进行定价，然后把印刷任务交给自动生产设备。在需求工程中得到了一个被称为PrintJob的分析类，如图10-1所示。PrintJob有两个接口：computeJob具有对任务进行定价的功能，initiateJob能够把任务传给生产设备。,面向对象的观点,图10-1设计构件的细化,面向对象的观点,构件级设计将由此开始。必须对PrintJob构件的细节进行细化，以提供指导实现的充分信息。通过不断补充作为构件PrintJob的类的全部属性和操作，来逐步细化最初的分析类。定义为体系结构设计组成部分的每一个构件都要实施细化。细化一旦完成，要对每一个属性、每一个操作和每一个接口进行更进一步的细化。适合每个属性的数据结构必须予以详细说明。另外还要说明实现与操作相关的处理逻辑的算法细节。最后是实现接口所需机制的设计。对于面向对象软件，还包含对实现系统内部对象间消息通信机制的描述。,传统观点,在传统软件工程环境中，一个构件就是程序的一个功能要素，程序由处理逻辑及实现处理逻辑所需的内部数据结构以及能够保证构件被调用和实现数据传递的接口构成。传统构件也被称为模块，作为软件体系结构的一部分，它承担如下三个重要角色之一：(1)控制构件，协调问题域中所有其他构件的调用;(2)问题域构件，完成部分或全部用户的需求;(3)基础设施构件，负责完成问题域中所需相关处理的功能。,传统观点,与面向对象的构件相类似，传统的软件构件也来自于分析模型。不同的是在该种情况下，是以分析模型中的数据流要素作为导出构件的基础。数据流图最低层的每个变换都被映射为某一层次上的模块。一般来讲，控制构件位于层次结构顶层附近，而问题域构件则倾向位于层次结构的底层。为了获得有效的模块化，在构件细化过程中采用了功能独立性的设计概念。,传统观点,再来考虑为一个高级影印中心构建软件。在分析模型建立过程中导出一组数据流图。假设这些数据流图已经被映射到图10-2中所显示的体系结构中。图中每个方框都表示一个软件构件。,传统观点,图10-2 一个传统系统的结构图,传统观点,考虑ComputePageCost模块。该模块的目的在于根据用户提供的规格说明来计算每页的印刷费用。为了实现该功能需要以下数据：文档的页数，文档的印刷份数，单面或者双面印刷，颜色，纸张大小。这些数据通过该模块的接口传递给ComputePageCost。ComputePageCost根据任务量和复杂度，使用这些数据来决定一页的费用这是一个通过接口将所有数据传递给模块的功能。每一页的费用与任务的大小成反比，与任务的复杂度成正比。,传统观点,图10-3给出了使用UML建模符号描述的构件级设计。其中ComputePageCost模块通过调用getJobData模块和数据库接口accessCostDB来访问数据。接着，对ComputePageCost模块进一步细化，给出算法和接口的细节描述。其中算法的细节可以由图中显示的伪代码或者UML活动图来表示。接口被表示为一组输入和输出的数据对象或者数据项的集合。设计细化的过程需要一直进行到获得构件的导向结构为止。,传统观点,图10-3 ComputePageCost的构件级设计,过程相关的观点,上面提及的关于构件级设计的面向对象观点和传统观点，都假定从头开始设计构件。即设计者必须根据从分析模型中导出的规格说明创建新构件。当然，还存在另外一种方法。在过去的10年间，软件工程已经开始强调使用已有构件来构造系统的必要性。实际上，软件工程师在设计过程中可以使用已经过验证的设计或代码构件的目录。当软件体系结构设计完后，就可以从目录中选出构件或者设计模式，并用于组装体系结构。由于这些构件是根据复用思想来创建的，所以其接口的完整描述、要实现的功能和需要的通信与协作等对于设计者来说都是可以得到的。,设计基于类的构件,构件级设计利用了分析模型开发的信息和体系结构模型表示的信息。当选择了面向对象软件工程方法后，构件级设计主要关注分析类的细化和基础类的定义和精化。这些类的属性、操作和接口的详细描述是开始构建活动之前所需的设计细节。,基本设计原则,有四种适用于构件级设计的基本设计原则，这些原则在使用面向对象软件工程方法时被广泛采用。使用这些原则的根本动机在于，使得产生的设计在发生变更时能够适应变更并且减少副作用的传播。开关原则(OCP)：模块应该对外延具有开放性，对修改具有封闭性。简单地说，设计者应该采用一种无需对构件自身内部做修改就可以进行扩展的方式来说明构件。,SAFEHOME实例50,0,SAFEHOME实例51,图10-4 遵循OCP原则,基本设计原则,Liskov替换原则(LSP)：“子类可以替换它们的基类”。最早提出该原则的LIS88建议，将子类传递给构件来代替基类时，使用基类的构件应该仍然能够正确完成其功能。LSP原则要求源自基类的任何子类必须遵守基类与使用该基类的构件之间的隐含约定。,基本设计原则,依赖倒置原则(DIP)：“依赖于抽象，而非具体实现”。抽象可以比较容易地对设计进行扩展，又不会导致大的混乱。构件依赖的具体构件越多，其扩展起来就越困难。接口分离原则(ISP)：“多个用户专用接口比一个通用接口要好”。多个客户构件使用一个服务器类提供的操作的实例很多。ISP原则建议设计者应该为每一个主要的客户类型都设计一个特定的接口。只有那些与特定客户类型相关的操作，才应该出现在该客户的接口说明中。如果多个客户要求相同的操作，则这些操作应该在每一个特定的接口中都加以说明。,基本设计原则,发布复用等价性原则：”复用的粒度就是发布的粒度”。当类或构件被设计用以复用时，在可复用实体的开发者和使用者之间就建立了一种隐含的约定关系。开发者承诺建立一个发布控制系统，用来支持和维护实体的各种老版本，同时用户缓慢地将其升级到最新版本。明智的方法是将可复用的类分组打包成能够管理和控制的包作为一个更新的版本，而不是对每个类分别进行升级。,基本设计原则,共同封装原则：”一同变更的类应该合在一起”。类应该根据其内聚性进行打包。即当类被打包成设计的一部分时，它们应该处理相同的功能或者行为域。当域的一些特征必须变更时，只有那些包中的类才有可能需要修改。这样可以进行更加有效的变更控制和发布管理。,基本设计原则,共同复用原则：”不能一起复用的类不能被分到一组”。当包中的一个或者多个类变更时，包的发布版本数量也会发生。所有那些依赖于已经发生变更的包的类或者包，都必须升级到最新的版本，并且都需要进行测试以保证新发布的版本能够无故障运转。如果类没有根据内聚性进行分组，那么这个包中与其他类无关联的类有可能会发生变更，而这往往会导致进行没有必要的集成和测试。因此，只有那些一起被复用的类才应该包含在一个包中。,构件级设计指导方针,构件。对那些已经被确定为体系结构模型一部分的构件应该建立命名约定，并对其做进一步的细化和精化，使其成为构件级模型的一部分。体系结构构件的名字来源于问题域，并且应该能够被查看体系结构模型的所有共利益者理解。在详细设计层面使用构造型帮助识别构件的特性也很有价值。,构件级设计指导方针,接口。接口提供关于通信和协作的重要信息。然而接口表示的随意性会使构件图趋于复杂化。AMB02建议：(1)当构件图变得复杂时，在较正式的UML框和虚箭头记号方法中使用接口的棒棒糖式记号；(2)为了保持一致，接口都放在构件框的左边；(3)即使其他的接口也适用，也只表示出那些与构件相关的接口。依赖与继承。为了提高可读性，依赖关系是自左向右，继承关系是自下而上。另外，构件之间的依赖关系通过接口来表示，而不是采用“构件到构件”的方法来表示。遵照OCP的思想，这种方法使得系统更易于维护。,内聚性,内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。LET01定义了许多不同类型的内聚性。,内聚性,功能内聚分层内聚通信内聚顺序内聚过程内聚暂时内聚实用内聚,耦合性,耦合性是类之间彼此联系程度的一种定性度量。随着类相互依赖越来越多。类之间的耦合程度亦会增加。在构件级设计中，一个重要的目标就是尽可能保持低耦合。LET01定义了如下耦合分类：,耦合性,内容耦合共用耦合控制耦合印记耦合数据耦合例程调用耦合类型使用耦合包含或者导入耦合外部耦合,实施构件级设计,构件级设计本质上是细化的。设计者必须将分析模型和架构模型中的信息转化为一种设计表示，这种表示提供了用来指导构建活动的充分信息。,实施构件级设计,步骤1:标识出所有与问题域相对应的类。使用分析模型和架构模型，每个分析类和体系结构构件都要细化。步骤2:确定所有与基础设施域相对应的设计类。在分析模型中并没有描述这些类，并且在体系结构设计中也经常忽略这些类，但是此时必须对它们进行描述。这种类型的类和构件包括GUI构件、操作系统构件、对象和数据管理构件等。,实施构件级设计,步骤3:细化所有不能作为复用构件的设计类。详细描述实现类需要的所有接口、属性和操作。在实现这个任务时，必须考虑采用设计试探法。步骤3a:在类或构件的协作时说明消息的细节。分析模型中用协作图来显示分析类之间的相互协作。在构件级设计过程中，某些情况下通过对系统中对象间传递消息的结构进行说明，来表现协作细节是必要的。这可作为接口规格说明的前提，这些接口显示了系统中构件通信和协作的方式。,实施构件级设计,图10-6给出了前述印刷系统的一个简单协作图。ProductionJob、WorkOrder和JobQueue三个对象相互协作为生产线准备印刷作业。图中的箭头表示对象间传递的消息。随着设计的进行，消息通过下列方式的扩展语法来细化：guard condition sequence expression(return value):=message name(argument list),实施构件级设计,图10-6 带消息的协作图,实施构件级设计,guard condition采用对象约束语言OCL来书写，并且说明了在消息发出之前应该满足什么样的条件集合；Sequence expression是一个表明消息发送序号的整数或其他样式的表明发送顺序的指示符；(return value)是由消息唤醒操作返回的信息名；message name表示唤醒的操作，(argument list)是传递给操作的属性列表。,实施构件级设计,步骤3b:为每一个构件确定适当的接口。在构件级设计中，一个UML接口是“一组外部可见的（即公共的）操作。接口不包括内部结构，没有属性，没有关联。接口是某个抽象类的等价物，该抽象类提供了设计类之间的可控连接。实际上，为设计类定义的操作可以归结为一个或者更多的抽象类。抽象类内的每个操作应该是内聚的，即它应该展示那些关注于一个有限功能或者子功能的处理。,实施构件级设计,参照图10-1，由于initiateJob接口没有展现出足够的内聚性而受到争议。实际上，它完成三个不同的子功能：建立工作单，检查任务的优先级，并将任务传递给生产线。接口设计应该重构。一种方法是重新检查设计类并定义一个新类WorkOrder，该类用来处理与装配工作单相关的所有活动。buildWorkOrder()操作成为该类的一部分。另外可能要定义一个合并了操作checkPriority()的JobQueue类。ProductionJob类包括传递给生产线的生产任务的所有相关信息。initiateJob接口将采用图10-7所示的形式。initiateJob现在是内聚的，集中在一个功能上。与ProductionJob、WorkOrder和JobQueue相关的接口都是近乎专诚的。,实施构件级设计,图10-7 为PrintJob重构接口和类定义,实施构件级设计,步骤3c:细化属性并且定义相应的数据类型和数据结构。UML采用下面的语法来定义属性的数据类型：name:type-expression=initial-valueproperty string其中name是属性名，type expression是数据类型；initial-value是创建对象时属性的初始值；property string用于定义属性的特征或特性。,实施构件级设计,在构件级设计的第一轮迭代中，属性通常用名字来描述。随着设计的进一步细化，使用UML的属性格式注释来定义每一个属性。如可以下列方式来定义paperType-weight:paperType-weight:string=“A”contains 1 of 4 values A,B,C or D如果某一属性在多个设计类中重复出现，并且其自身具有比较复杂的结构，最好是为这个属性创建一个单独的类。,实施构件级设计,步骤3d:详细描述每个操作中的处理流。可以用流程图、伪代码或者UML活动图来完成。每个软件构件都需要应用逐步求精概念通过大量的迭代进行细化。第一轮迭代中，将每个操作都定义为设计类的一部分。任何情况下，操作应该采用确保高内聚性的方式来刻画；即，一个操作应该完成单一的目标功能或者子功能。接下来的一轮迭代，只是完成对操作名的详细扩展。如对图10-1中的操作computePaperCost()可以采用如下方式进行扩展:computePaperCost(weight,size,color):numeric,实施构件级设计,如果实现computePaperCost()的算法简单而且易于理解，则没有必要开展进一步的设计细化。软件编码人员将会提供实现这些操作的必要细节。如果算法比较复杂或者难于理解，则需要进行设计细化。图10-8给出了操作computePaperCost()的一个UML活动图。当活动图用于构件级设计的规格说明时，通常都在比源码更高的抽象级上表示。另外，还可以在设计规格说明中使用伪代码。,实施构件级设计,图10-8 computePaperCost()操作的UML活动图,实施构件级设计,步骤4:说明持久数据源(数据库和文件)并确定管理数据源所需要的类。数据库和文件通常都凌架于单独的构件设计描述之上。在多数情况下，这些持久数据存储起初都被指定为体系结构设计的一部分，然而，随着设计细化过程的不断深入，提供关于这些持久数据源的结构和组织等额外细节常常是有用的。,实施构件级设计,步骤5:开发并且细化类或构件的行为表示。UML状态图被用作分析模型的一部分，以表示系统的外部可观察的行为和更多的分析类个体的局部行为。在构件级设计过程中，有些时候对设计类的行为进行建模是必要的。对象(程序执行时的设计类实例)的动态行为受到外部事件和对象当前状态(行为方式)的影响。为了理解对象的动态行为，设计者必须检查设计类生命周期中所有相关的用例，这些用例提供的信息可以帮助设计者描绘影响对象的事件，以及随着时间流逝和事件的发生对象所处的状态。图10-9描述了使用UML状态图表示的状态之间的转换。,实施构件级设计,图10-9 PrintJob类的状态图,实施构件级设计,从一种状态到另一种状态的转换，都表示为如下形式的事件序列：event-name(parameter-list)guard-conditon/action expression其中event-name表示事件；parameter-list包含了与事件相关的数据；guard-condition采用对象约束语言书写，并描述了一个在事件发生前必须满足的条件，action expression定义了一个状态转换时发生的动作。针对状态的进入和离开两种情形，每个状态都可以定义entry/和exit/两个动作。多数情况下，这些动作与正在建模的类的相关操作相对应。do/指示符提供了一种机制，用来显示伴随此种状态的相关活动；而include/指示符则提供了通过在状态定义中嵌入更多状态图细节的方式细化的手段。,实施构件级设计,行为模型经常包含一些在其他设计模型中不明显的信息。例如，通过仔细查看图10-9中的状态图可以知道，当得出印刷任务的价钱和进度数据时，PrintJob类的动态行为取决于用户对此是否认可。如果没有同意，印刷工作就不能提交，因为不可能到达submittingJob状态。,实施构件级设计,步骤6:细化部署图以提供额外的实现细节。部署图用作体系结构设计的一部分，并且部署图采用描述符形式来表示。在这种表示形式中，主要的系统功能都表示在容纳这些功能的计算环境中。在构件级设计过程中，部署图应该被细化以表示主要构件包的位置。然而，构件一般在构件图中不被单独表示，目的在于避免图的复杂性。某些情况下，部署图在这个时候被细化成实例形式。这意味着指定的硬件和要使用的操作系统环境应加以说明，而构件包在这个环境中的位置等也需要指出。,实施构件级设计,步骤7:考虑每一个构件级设计表示，并且时刻考虑其他选择。设计是一个迭代过程。创建的第一个构件级模型总没有迭代N次之后得到的模型那么全面、一致或精确。在进行设计工作时，重构是十分必要的。设计中经常存在其他的设计方案，在没有决定最终设计模型之前，最好的设计师会考虑所有(或大部分)的方案，并且仔细考虑和分析这些方案。,对象约束语言,作为UML一部分的各种图为设计得提供了丰富的设计模型表示形式。然而，图形表示往往是不够的，设计者还需要一种机制，以明确和规范地表示那些可以约束设计模型元素的信息。对象约束语言OCL通过允许软件工程师使用形式化的语法和文法构建各种设计模型元素(如类和对象、事件、消息、接口)，利用这些无歧义描述语句作为UML的补充。,对象约束语言,最简单的OCL语言语句由四个部分组成：(1)语境(context)定义了哪些情况语句是正确的;(2)特性(property)描述语境的一些特征（如，如果语境是一个类，那么特性可能就是一个属性）；(3)操作(operation)用来操纵和限定一个特性(如，算术运算、集合运算等)；(4)关键字(keyword)用于说明条件表达式。,对象约束语言,作为OCL表达式的一个例子，假设在PrintJob类的状态图中，在一个能够引起computingJobCost与formingJob之间状态转换的jobCostAccepted事件上有一个警戒条件。在图中，警戒条件以自然语言的形式表达，并且意味着只有当客户有权批准任务的报价时这个授权才会发生。在OCL中，可以采用如下方式来描述这个表达式：customer self.authorizationAuthority=yesCustomer类(实际是类的一个特定实例)的一个布尔属性authorizationAuthority必须被设为yes，才满足警戒条件。,对象约束语言,在创建设计模型时，经常有一些实例在完成设计规定的动作之前必须满足它们的前置条件或后置条件。OCL提供了一个强有力的工具，以形式化的方式说明前置和后置条件。例如，假设印刷车间系统要进行扩展，在说明其他印刷任务特性的同时，客户提供了印刷任务价格上限和交付的最后期限。如果印刷价格与交付时间超过其上限，任务就不能被提交并且必须通知客户。在OCL中，可以采用如下方式来说明一系列前置条件和后置条件：,对象约束语言,对象约束语言,该OCL语句定义一个不变量也就是必须在一些行为之前(pre)和之后(post)存在的条件。开始的时候，前置条件建立了一个由客户指定的价格上限和交付期限，并且任务授权必须设置为”no”。确定价格上限和交付期限之后，将应用后置条件。还需要注意的是，表达式self.jobAuthorization=yes并不是用来设置”yes”值，而是声明在操作结束时必须将jobAuthorization设置为”yes”。,设计传统构件,传统软件构件的构件级设计基础在20世纪60年代已经形成，Dijkstra等人提出，所有程序都可以建立在一组限定好的逻辑构造之上，这一组逻辑构造强调了“对功能域的支持”，其中每一个逻辑结构有可预测的逻辑结构(structure)，从顶端进入，从底端退出，读者可以很容易地理解过程流。这些逻辑构造包括顺序型、条件型和重复型。这些逻辑构造是结构化编程的基础，而结构化编程是构件级设计的一种重要技术。,图形化设计表示,图10-10 流程图构造,图形化设计表示,一般来说，如果需要从一组嵌套的循环或条件中退出，完全依赖结构化的构造将导致效率降低。更重要的是，退出路径上的复杂逻辑检验将会使软件的控制流不清晰，增加出错的可能，降低可读性和可维护性。设计人员有两种选择：(1)重新设计过程表示，保证内层嵌套的控制流中不需要退出分支;(2)以受控方式突破结构化的构造，即设计一条从嵌套层内退出的路径。第一种选择是最理想的，但第二种选择也不违反结构化编程的精神。,表格式设计表示,在许多软件应用系统中，模块需要对复杂的组合条件求值，并根据这些条件选择要执行的动作。决策表（判定表）提供了一种表示方法，可以将动作和条件翻译成表格。决策表分为四个部分，左上部列出了所有的条件，左下部列出所有可能的动作，右半部构成了一个矩阵，表示条件的组合以及特定条件组合对应的动作，因此矩阵的每一列可以解释成一条处理规则。,表格式设计表示,开发决策表的步骤如下：1、列出特定过程（或模块）相关的所有动作。2、列出执行该过程时的所有条件（或所做的决策）。3、将特定的条件组合与特定的动作相关联，消除不可能的条件组合；或者找出所有可能的条件排列。4、定义规则，指出一组条件对应哪个或哪些动作。,决策表实例,图10-11 决策表,程序设计语言,程序设计语言PDL也称为结构化的英语或伪代码，它是“一种混合语言”，采用一种语言的词汇和另一种语言的语法。,设计表示方法的比较,设计表示方法应该能够导致一个易于理解和评审的过程表示。此外，这些表示方法还应该增强“面向代码”的能力，以便代码确实能够成为设计的一个自然副产品。最后，设计表示方法必须易于维护，使得设计总是正确地表示程序。PDL可以被直接嵌入到源程序列表中，以改善文档并减少设计维护的难度。可以由任何文本编辑程序或字处理系统完成编辑，自动处理器已经存在，并具有“自动代码生成”的潜力。活动图和流程图的图形化特征使得设计人员更容易看清控制流。决策表的准确内容，是表驱动应用系统的理想工具。对设计工具的选择可能更取决于人为因素而不是技术因素。,
