软件工程讲义_第10章构件级设计建模

合集下载

第10章软件产品线体系结构

第10章软件产品线体系结构106产品线体系结构的演化产品线的演化业务部门业务部门产品特定的代码产品特定的代码产品族产品族需求需求产品线需求产品线需求产品线体系结构产品线体系结构产品线产品线构件构件产品线产品线构件构件产品线产品线构件构件特定的产品线构件特定的产品线构件框架体系结构框架体系结构框架实现框架实现第10章软件产品线体系结构106产品线体系结构的演化axis通信公司的产品线体系结构背景介绍13产品线体系结构产品线体系结构jazjaz服务器服务器体系结构体系结构光盘服务器光盘服务器体系结构体系结构扫描服务器体系结构扫描服务器体系结构摄象服务器体系结构摄象服务器体系结构存储服务器体系结构存储服务器体系结构各种产品各种产品各种产品各种产品各种产品各种产品各种产品各种产品axis公司产品线体系结构的等级第10章软件产品线体系结构106产品线体系结构的演化第一代文件系统框架nfsnfs文件系统框架文件系统框架存取控制存取控制isoiso96609660pseudopseudo块设备块设备scsiscsi硬件硬件fatfatufsufsaxis通信公司的产品线体系结构背景介绍23第10章软件产品线体系结构106产品线体系结构的演化第二代文件系统框架nfsnfs文件系统框架文件系统框架isoiso96609660存取控制框架存取控制框架pseudopseudoscsiscsi硬件硬件fatfat1616ufsufs块设备块设备axis通信公司的产品线体系结构背景介绍33第10章软件产品线体系结构106产品线体系结构的演化两代产品的各种发行版本17第一代产品的第二个版本以太网模块以太网模块令牌网模块令牌网模块网络协议框架网络协议框架网络文件系统框架网络文件系统框架netwarenetwarescsiscsiisoiso96609660pseudopseudosmbsmbnfsnfs文件系统框架文件系统框架未改变的构件未改变的构件修改了的构件修改了的构件新构件新构件第10章软件产品线体系结构106产品线体系结构的演化两代产品的各种发行版本27第一代产品的第三个版本以太网模块以太网模块令牌网模块令牌网模块网络协议框架网络协议框架网络文件系统框架网络文件系统框架netwarenetwarescsiscsismbsmbnfsnfs文件系统框架文件系统框架未改变的构件未改变的构件修改了的构件修改了的构件新构件新构件httphttp

软件工程-构件级设计建模

软件工程
8.1 什么是构件（续）
• 针对不同的系统设计体系，构件所指的对象不一样。
软件工程
8.1.1 面向对象观点
• 在面向对象的设计中，构件指一个协作类的集合。 • 一般来讲，构件的规模比类大，但有时一个构件
也可以对应一个类。 • 在构件级设计时，应设计出类的所有属性以及和
其它类之间的相关操作，通信接口必须明确定义。
软件工程
软件工程
• （2）为每个构件确定适当的接口
– UML接口是“一组外部课件的（即公共的）操作，接口不包含内部结构、没有属性，没有关联……”
– 为设计类定义的接口可以归结为一个或者更多的抽象类
– 抽象类中的每个操作接口应该是内聚的
内聚性差！
软件工程
建立工作单检查任务的优先级
将任务传递给生产线
–某些情况下，部署图在这个时候被细化为实例形式
7. 反省和检查现有的设计
软件工程
8.4 对象约束语言
• 对象约束语言（Object Constraint Language, OCL），一种形式化语言
• 四个组成部分：
–语境—定义了哪些情况语句是正确的 –特征—描述语境的一些特征 –操作—用来操纵和限制一个特性 –关键字—用于说明条件表达式
个数据类型时
软件工程
8.2.4 耦合性（续）
• 包含或导入耦合—当构件A引入或者包含一个构件B的包或者内容时
• 外部耦合—当一个构件通信和协作时发生
构件的UML表示
软件工程
图带接口的构件构件具有它们支持的接口和需要从其他构件得到的接口
构件图表示了构件之间的依赖关系。
软件工程
每个构件实现（支持）一些接口，并使用另一些接

《软件工程》教学课件11软件复用和构件技术

构件技术的概念和特点
1 概念
2 特点
构件技术是一种软件开发方法，通过将系统分解为独立的模块（构件）来构建复杂的应用程序。
高度可重用、独立可测试、易于部署和升级。
构件的组织和管理
1
构件库
建立和维护一个集中的构件库，用于存储、组织和分享构件。
2
版本控制
使用版本控制系统来跟踪构件的修改，确保系统的稳定性和一致性。
3
构件文档
编写清晰的文档，描述构件的功能、接口和用法，以便其他开发人员能够使用和理解。
构件的开发和测试
1
构件设计
根据需求和规范，设计构件的接口、功能和数据结构。
2
构件实现
使用合适的编程语言和工具，开发构件的源代码。
3
构件测试
进行单元测试和集成测试，确保构件的正确性和可靠性。
结论和总结
通过软件复用和构件技术，我们可以提高开发效率、降低成本，同时增加软件的可维护性和可重用性。构件技术是现代软件工程中的重要方法之一。
重复使用已重用已开发的独立模块，如界面组件和业务逻辑组件。
3 框架复用
利用通用的软件框架来构建应用程序，如Web框架和移动应用框架。
软件复用的优点和挑战
优点
• 提高开发效率 • 提高软件质量 • 降低开发成本
挑战
• 找到合适的复用组件 • 解决兼容性问题 • 维护和更新复用组件
《软件工程》教学课件11 软件复用和构件技术
在本节课中，我们将探讨软件复用和构件技术，了解其定义、分类、优点和挑战，以及构件的组织、管理、开发和测试。
软件复用的定义和意义
软件复用是指在开发过程中使用已有的软件组件来构建新的应用程序，以提高效率、降低成本并增加可靠性和可维护性。

软件工程全部课件-第10章软件复用与构件技术

10.2.3分类和检索软件构件
❖ 1．描述可重用的构件
可以用很多种方式描述可重用的软件构件，但是一种理想的描述方式是Tracz提出的3C模型——概念（concept）、内容（ content）和语境（context）。
软件构件的“概念”是对构件做什么的描述，应该完整地描述构件的接口，并在前置条件和后置条件的语境中标识构件的语义。构件的“内容”描述实现概念的方法。 “语境”把可重用的软件构件置于其应用领域中，也就是说，通过指定概念的、操作的和实现的特征，语境使得软件工程师能够找到适当的构件以满足应用需求。
10.3 面向对象的软件重用技术
(3)类的合成如果从类库中检索出来的基类能够完全满足新软件项目的需求，则可以直接复用。否则，必须以类库中的基类为父类，采用构造法或子类法派生出子类。
构造法为了在子类中使用类库中基类的属性和操作，可以考虑在子类中引进基类的实例作为子类的实例变量。然后，在子类中通过实例变量来复用基类的属性或操作，构造法用到面向对象方法的封装特性。子类法与构造法完全不同，子类法把新子类直接说明为类库中基类的子类。通过继承、修改基类的属性和操作来完成新子类的定义。子类法利用了面向对象方法的封装特性和继承特性。
(2)选取：即用户根据已有软件制品的抽象，寻找、比较和选择最适合他需要的那个制品（可复用件）；
(3)特化：即对已集成：将例化后的复用件集成为应用系统。
10.2基于构件的软件开发
❖ 10.2.1开发可复用的软件构件 ❖ 10.2.2 软件构件的组织 ❖ 10.2.3分类和检索软件构件
10.2.2 软件构件的组织
❖ 可复用构件库的组织方法有枚举分类法、关键词分类法、多面分类法、超文本组织法、模型法等。

软件工程2-11.构件级设计

11.1.3 其他相关观点
二、基本概念的比较
CORBA CORBA的对象模型基本上按OMG所定义的公共对象模型COM（不同于微软的COM），支持类、封装、继承和多态，是一个功能比较完备的对象模型。对象或类之间可按客户/服务器方式互相调用。每个对象或类即可以作为客户，也可以作为服务器，有时还可以兼作客户和服务器。客户对象和服务器对象只通过消息交互作用。客户对象向服务器对象发出请求，服务器对象响应客户对象的请求完成一定的操作，并返回操作结果和必要的信息。它们只通过消息往来，不必了解与请求无关的功能。即使客户对象或服务对象重新实现，只要接口的语法和语义不变，不影响用户的使用。客户和服务器的通信方式一般有两种：常用的是同步方式，即客户提交请求后，客户要等到服务器放操作执行完毕并返回操作结果或信息后，才继续运行；另一种方式是异步方式，即客户提交请求后，可继续运行。
1121基本设计原则29依赖正置就是类间的依赖是实实在在的实现类间的依赖也就是面向实现编程这也是正常人的思维方式我要开奔驰车就依赖奔驰车我要使用笔记本电脑就直接依赖某笔记本电脑而编写程序需要的是对现实世界的事物进行抽象抽象的结构就是有了抽象类和接口然后我们根据系统设计的需要产生了抽象间的依赖代替了人们传统思维中的事物间的依赖倒置就是从这里产生的
11.2 设计基于类的构件
构件级设计基于分析模型、体系结构模型。面向对象方法中构件级设计主要关注分析类的细化（特定的问题域类）和基础类的定义和精化。
11.2.1 基本设计原则
四个基本设计原则：
开关原则 Liskov替换原则依赖倒置原则接口分离原则
11.2.1 基本设计原则开关原则
11.2.1 基本设计原则 Liskov替换原则

软件工程的软件工程建模

测试执行建模
执行测试用例记录测试结果生成测试报告
● 05
第五章软件部署建模
部署建模概述
软件部署建模是指将软件系统部署到目标环境中，并进行配置、安装和测试的过程。这个过程需要考虑不同的环境因素，确保软件能够正常运行并满足用户需
求。
部署环境建模
硬件配置
包括服务器、存储设备等的配置
操作系统
第3章软件设计建模
设计建模概述
软件设计建模是在需求建模基础上，通过各种模型来描述系统的结构、行为和交互，为实际编码提供指导。在设计建模过程中，需要考虑系统的静态结构以及动态行为，以确保软件系统
能够满足用户需求并具备良好的扩展性和可维护性。
结构设计建模
类图
描述系统中的类及其之间的关系
组件图
水平和用户体验，推动软件工程的进步。
谢谢观看！
验证系统对不同输入的响应
测试执行建模
执行测试用例
按照测试计划执行各个测试用例
记录测试结果
及时记录测试过程中的结果和问题
生成测试报告
整理测试结果并提出改进建议
软件测试建模
帮助提高软件质量发现潜在缺陷规划测试流程
总结
测试计划建模
确定测试方向详细规划执行过程设计测试用例
测试设计建模
设计测试用例准备测试数据覆盖系统路径
用例建模
用例图
用例与参与者之间的关系图
时序图
展示系统中对象之间的交互顺序
活动图
描述系统中业务流程的流程图
领域建模
领域建模是软件需求建模中的重要步骤，通过分析系统所涉及的业务领域，定义系统的需求和功能。实体、关系和属性的定义是领域建模中的核心内容，能够帮助开发团队更好地理解系

软件工程概论_详细设计

//最后，我们来看看客户端的调用过程： public void DecriptionTheAnimal(Animal animal) { if (typeof(animal) is Cat) { Cat cat = (Cat)animal; Cat.Description(); Cat.Mew(); } else if (typeof(animal) is Dog) { Dog dog = (Dog)animal; Dog.Description(); Dog.Bark(); } }
但如果我们将原来的设计变更如下：
// 符合开关原则的一个好例子 class GraphicEditor { public void drawShape(Shape s) { •看看原来的drawShape函数，这里它只是调 s.draw(); •用了s的draw函数，原来的 drawCirlcle， } •drawRectangle也没了。现在如果再增加新 }
}
11
12
6.2.1基本设计原则
如何使用开闭原则：抽象约束第一，通过接口或者抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；第三，抽象层尽量保持稳定，一旦确定即不允许修改。
17
class Animal{ private string name; void Animal(string name) { = name; } public void Description() { Console.WriteLine("This is a(an) " + name); } } //下面是它的子类猫类： class Cat extends Animal{ void Cat(string name) { } public void Mew() { Console.WriteLine("The cat is saying like 'mew'"); } } //下面是它的子类狗类： class Dog extends Animal{ void Dog(string name) { } public void Bark() { Console.WriteLine("The dog is saying like 'bark'"); } }

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

SAFEHOME实例[50]
0
SAFEHOME实例[51]
图10-4 遵循OCP原则
基本设计原则

Liskov替换原则(LSP)：“子类可以替换它们的基类”。最早提出该原则的 [LIS88]建议，将子类传递给构件来代替基类时，使用基类的构件应该仍然能够正确完成其功能。LSP原则要求源自基类的任何子类必须遵守基类与使用该基类的构件之间的隐含约定。
基本设计原则
依赖倒置原则(DIP)：“依赖于抽象，而非具体实现”。抽象可以比较容易地对设计进行扩展，又不会导致大的混乱。构件依赖的具体构件越多，其扩展起来就越困难。接口分离原则(ISP)：“多个用户专用接口比一个通用接口要好”。多个客户构件使用一个服务器类提供的操作的实例很多。ISP原则建议设计者应该为每一个主要的客户类型都设计一个特定的接口。只有那些与特定客户类型相关的操作，才应该出现在该客户的接口说明中。如果多个客户要求相同的操作，则这些操作应该在每一个特定的接口中都加以说明。
传统观点
与面向对象的构件相类似，传统的软件构件也来自于分析模型。不同的是在该种情况下，是以分析模型中的数据流要素作为导出构件的基础。数据流图最低层的每个变换都被映射为某一层次上的模块。一般来讲，控制构件位于层次结构顶层附近，而问题域构件则倾向位于层次结构的底层。为了获得有效的模块化，在构件细化过程中采用了功能独立性的设计概念。
传统观点
图10-3 ComputePageCost的构件级设计
过程相关的观点
上面提及的关于构件级设计的面向对象观点和传统观点，都假定从头开始设计构件。即设计者必须根据从分析模型中导出的规格说明创建新构件。当然，还存在另外一种方法。在过去的10年间，软件工程已经开始强调使用已有构件来构造系统的必要性。实际上，软件工程师在设计过程中可以使用已经过验证的设计或代码构件的目录。当软件体系结构设计完后，就可以从目录中选出构件或者设计模式，并用于组装体系结构。由于这些构件是根据复用思想来创建的，所以其接口的完整描述、要实现的功能和需要的通信与协作等对于设计者来说都是可以得到的。
面向对象的观点
图10-1设计构件的细化
面向对象的观点
构件级设计将由此开始。必须对PrintJob构件的细节进行细化，以提供指导实现的充分信息。通过不断补充作为构件PrintJob的类的全部属性和操作，来逐步细化最初的分析类。定义为体系结构设计组成部分的每一个构件都要实施细化。细化一旦完成，要对每一个属性、每一个操作和每一个接口进行更进一步的细化。适合每个属性的数据结构必须予以详细说明。另外还要说明实现与操作相关的处理逻辑的算法细节。最后是实现接口所需机制的设计。对于面向对象软件，还包含对实现系统内部对象间消息通信机制的描述。

内聚性

内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。[LET01]定义了许多不同类型的内聚性。
内聚性
功能内聚分层内聚通信内聚顺序内聚过程内聚暂时内聚实用内聚

耦合性
耦合性是类之间彼此联系程度的一种定性度量。随着类相互依赖越来越多。类之间的耦合程度亦会增加。在构件级设计中，一个重要的目标就是尽可能保持低耦合。 [LET01]定义了如下耦合分类：

设计基于类的构件

构件级设计利用了分析模型开发的信息和体系结构模型表示的信息。当选择了面向对象软件工程方法后，构件级设计主要关注分析类的细化和基础类的定义和精化。这些类的属性、操作和接口的详细描述是开始构建活动之前所需的设计细节。
基本设计原则
有四种适用于构件级设计的基本设计原则，这些原则在使用面向对象软件工程方法时被广泛采用。使用这些原则的根本动机在于，使得产生的设计在发生变更时能够适应变更并且减少副作用的传播。开关原则(OCP)：模块应该对外延具有开放性，对修改具有封闭性。简单地说，设计者应该采用一种无需对构件自身内部做修改就可以进行扩展的方式来说明构件。

面向对象的观点

在面向对象软件工程环境中，构件包括一个协作类集合。构件中的每一个类都被详细阐述，包括所有的属性和与其实现相关的操作。作为细节设计的一部分，所有与其他设计类相互通信协作的接口必须予以定义。为了完成这些，设计师从分析模型开始，详细描述分析类和基础类。
面向对象的观点

考虑为一个高级印刷车间构建软件。软件的目的是为了收集前台的客户需求，对印刷业务进行定价，然后把印刷任务交给自动生产设备。在需求工程中得到了一个被称为PrintJob的分析类，如图10-1所示。 PrintJob有两个接口：computeJob具有对任务进行定价的功能，initiateJob能够把任务传给生产设备。
基本设计原则

共同封装原则：‖一同变更的类应该合在一起‖。类应该根据其内聚性进行打包。即当类被打包成设计的一部分时，它们应该处理相同的功能或者行为域。当域的一些特征必须变更时，只有那些包中的类才有可能需要修改。这样可以进行更加有效的变更控制和发布管理。
基本设计原则

共同复用原则：‖不能一起复用的类不能被分到一组‖。当包中的一个或者多个类变更时，包的发布版本数量也会发生。所有那些依赖于已经发生变更的包的类或者包，都必须升级到最新的版本，并且都需要进行测试以保证新发布的版本能够无故障运转。如果类没有根据内聚性进行分组，那么这个包中与其他类无关联的类有可能会发生变更，而这往往会导致进行没有必要的集成和测试。因此，只有那些一起被复用的类才应该包含在一个包中。
构件级设计指导方针
构件。对那些已经被确定为体系结构模型一部分的构件应该建立命名约定，并对其做进一步的细化和精化，使其成为构件级模型的一部分。体系结构构件的名字来源于问题域，并且应该能够被查看体系结构模型的所有共利益者理解。在详细设计层面使用构造型帮助识别构件的特性也很有价值。

构件级设计指导方针

传统观点

图10-3给出了使用UML建模符号描述的构件级设计。其中ComputePageCost模块通过调用 getJobData模块和数据库接口accessCostDB 来访问数据。接着，对ComputePageCost模块进一步细化，给出算法和接口的细节描述。其中算法的细节可以由图中显示的伪代码或者 UML活动图来表示。接口被表示为一组输入和输出的数据对象或者数据项的集合。设计细化的过程需要一直进行到获得构件的导向结构为止。
构件级设计建模
每个软件的设计都以图形的、图表的或基于文本的方式表示，这是构件级设计阶段产生的主要工作产品。采用设计走查或审查机制。对设计执行检查以确定数据结构、接口、处理顺序和逻辑条件等是否都正确，并且给出早期设计中与构件相关的数据或控制变换。

构件级设计建模

体系结构设计第一次迭代完成之后，就应该开始构件级设计。在这个阶段，全部的数据和软件的程序结构都已经建立起来，其目的是把设计模型转化为运行软件。但是现有设计模型的抽象层次相对较高，而可运行程序的抽象层次相对较低。这种转化具有挑战性，因为可能会在软件过程后期阶段引入难于发现和改正的微小错误。
接口。接口提供关于通信和协作的重要信息。然而接口表示的随意性会使构件图趋于复杂化。 [AMB02]建议：(1)当构件图变得复杂时，在较正式的UML框和虚箭头记号方法中使用接口的棒棒糖式记号；(2)为了保持一致，接口都放在构件框的左边；(3)即使其他的接口也适用，也只表示出那些与构件相关的接口。依赖与继承。为了提高可读性，依赖关系是自左向右，继承关系是自下而上。另外，构件之间的依赖关系通过接口来表示，而不是采用“构件到构件”的方法来表示。遵照OCP的思想，这种方法使得系统更易于维护。

耦合性
内容耦合共用耦合控制耦合印记耦合数据耦合例程调用耦合类型使用耦合包含或者导入耦合外部耦合

实施构件级设计

构件级设计本质上是细化的。设计者必须将分析模型和架构模型中的信息转化为一种设计表示，这种表示提供了用来指导构建活动的充分信息。
实施构件级设计
步骤1:标识出所有与问题域相对应的类。使用分析模型和架构模型，每个分析类和体系结构构件都要细化。步骤2:确定所有与基础设施域相对应的设计类。在分析模型中并没有描述这些类，并且在体系结构设计中也经常忽略这些类，但是此时必须对它们进行描述。这种类型的类和构件包括GUI构件、操作系统构件、对象和数据管理构件等。

传统观点

在传统软件工程环境中，一个构件就是程序的一个功能要素，程序由处理逻辑及实现处理逻辑所需的内部数据结构以及能够保证构件被调用和实现数据传递的接口构成。传统构件也被称为模块，作为软件体系结构的一部分，它承担如下三个重要角色之一：(1)控制构件，协调问题域中所有其他构件的调用;(2)问题域构件，完成部分或全部用户的需求;(3)基础设施构件，负责完成问题域中所需相关处理的功能。
构件级设计建模

用编程语言表示构件级设计是可以的。其实，程序的创建是以体系结构设计模型作为指南的。一种可供考虑的方法是使用某些能够容易转化为代码的中间表示来表示构件级设计。无论采用何种机制来表示构件级设计，定义的数据结构、接口和算法应该遵守各种已经精心规定好的设计指导准则，以避免在过程设计演化中犯错误。

传统观点
再来考虑为一个高级影印中心构建软件。在分析模型建立过程中导出一组数据流图。假设这些数据流图已经被映射到图10-2中所显示的体系结构中。图中每个方框都表示一个软件构件。
传统观点
图10-2 一个传统系统的结构图
传统观点
考虑ComputePageCost模块。该模块的目的在于根据用户提供的规格说明来计算每页的印刷费用。为了实现该功能需要以下数据：文档的页数，文档的印刷份数，单面或者双面印刷，颜色，纸张大小。这些数据通过该模块的接口传递给 ComputePageCost。ComputePageCost根据任务量和复杂度，使用这些数据来决定一页的费用— —这是一个通过接口将所有数据传递给模块的功能。每一页的费用与任务的大小成反比，与任务的复杂度成正比。