当前位置：文档之家 › 软件工程讲义_第10章 构件级设计建模

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

  • 格式：ppt
  • 大小：1.48 MB
  • 文档页数：72

下载文档原格式

  / 72

合集下载

第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表示
软件工程
图 带接口的构件 构件具有它们支持的接口和需要从其他构件得到的接口
构件图表示了构件之间的依赖关系。
软件工程
每个构件实现（支持）一些接口，并使用另一些接

最新整理软件工程讲义.ppt

最新整理软件工程讲义.ppt

构件级设计建模
❖每个软件的设计都以图形的、图表的或基 于文本的方式表示，这是构件级设计阶段 产生的主要工作产品。 ❖采用设计走查或审查机制。对设计执行检 查以确定数据结构、接口、处理顺序和逻 辑条件等是否都正确，并且给出早期设计 中与构件相关的数据或控制变换。
构件级设计建模
❖体系结构设计第一次迭代完成之后，就应 该开始构件级设计。在这个阶段，全部的 数据和软件的程序结构都已经建立起来， 其目的是把设计模型转化为运行软件。但 是现有设计模型的抽象层次相对较高，而 可运行程序的抽象层次相对较低。这种转 化具有挑战性，因为可能会在软件过程后 期阶段引入难于发现和改正的微小错误。
传统观点
❖与面向对象的构件相类似，传统的软件构件也 来自于分析模型。不同的是在该种情况下，是以 分析模型中的数据流要素作为导出构件的基础。 数据流图最低层的每个变换都被映射为某一层次 上的模块。一般来讲，控制构件位于层次结构顶 层附近，而问题域构件则倾向位于层次结构的底 层。为了获得有效的模块化，在构件细化过程中 采用了功能独立性的设计概念。
传统观点
再来考虑为一个高级影印中心构建软件。 在分析模型建立过程中导出一组数据流图。 假设这些数据流图已经被映射到图9-2中 所显示的体系结构中。图中每个方框都表 示一个软件构件。
传统观点
图9-2 一个传统系统的结构图
传统观点
❖考虑ComputePageCost模块。该模块的目的在于 根据用户提供的规格说明来计算每页的印刷费用。 为了实现该功能需要以下数据：文档的页数，文档 的印刷份数，单面或者双面印刷，颜色，纸张大小。 这些数据通过该模块的接口传递给 ComputePageCost。ComputePageCost根据任 务量和复杂度，使用这些数据来决定一页的费用— —这是一个通过接口将所有数据传递给模块的功能。 每一页的费用与任务的大小成反比，与任务的复杂 度成正比。

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

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

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

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

软件工程全部课件-第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.构件级设计

软件工程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'"); } }

第11章 构件图


前置条件：操作执行前必须满足的条件，若前置条件不满足，则不执行 操作。
后置条件：操作执行结束时必须满足的条件，若不满足，则操作的执行 不完全，必须进行调整。

10.2 软件构件的图形表示和特点
3）实例化。构件是一个物理实体，实例化代表运行期间的可执行软件模块。 类是一个逻辑抽象，可有多个实例。 4）与配置环境的亲合行。构件设计从内、外两方面满足与配置环境的相容性：
10.3 软件的分类
软件构件分为源代码构件、二进制代码构件和可执行代码构件。 1、源代码构件

源代码构件也称编译时构件，是实现一个或多个类的源代码 文件，二进制构件和可执行构件都是由源代码构件编译之后 产生的。源代码构件也称为工作产品构件，是开发过程的产 物。这些构件并不直接参加可执行系统，而是开发工作过程 中的工作产品，用来产生可执行系统。


10.5 软件图建模步骤
2）说明构件。利用构造型来说明构件的性质：

UML标准构造型： <<file>><<page>><<document>><<library>><<application>>和 <<table>>。 开发者自定义新的构造型。

3）标识构件之间的联系。确定构件之间通过接口依赖产生的 联系：
2、软件与类的比较

构件是一组逻辑元素（对象类、关系及协作等）的物理实 现。构件包含类，类通过构件来实现，构件与类之间是依 赖关系。
构件与类有很多相同点和不同点。
矩形图

图形
圆形图
饼形图
10.2 软件构件的图形表示和特点

软件工程概论参考课件1O_1_面向对象的建模概述

❖ 了解主流的实施技术，如设计语言和开发环境。
2020/5/20
21 /110
从图10.1中不难看出，分析师负责全局性的分析和设计 问题，设计师负责局部性的分析和设计问题以及细节性 的设计问题。
按照图10.1所示，建模的迭代过程中部署了两次全局到 局部的过渡，每一次过渡都为分析师和设计师之间提供 了沟通的机会，这为提升设计方案的质量和完整性创造 了有利条件。
第10章 面向对象的建模概述
第10章 面向对象的建模概述
10.1 对建模的认识 10.2 建模工具与过程
2020/5/20
2 /110
10.1 对建模的认识
10.1.1 什么是建模？ 10.1.2 我们已经历过的建模活动？ 10.1.3 我们已用过的建模工具？
2020/5/20
3 /110
2020/5/20
10 /110
❖ （1）准确、全面地获取并表达用户对新系统的真实需 求；
❖ （2）将用户需求的描述逐步演变为设计方案； ❖ （3）有步骤、分层次地设计与演化系统构架； ❖ （4）保障系统设计方案能够适应实施环境。
2020/5/20
11 /110
2. 建模过程框架
图10.1 建模过程框架
为了强调面向对象的分析与设计方法，因此，我们对Use Case有 了解之后，需要对面向对象的建模有一个较详细的了解，这是学习 面向对象的分析建模与设计建模的基础。
2020/5/20
25 /110
2020/5/20
6 /110
10.2 建模过程与工具
10.2.1 建模过程框架与迭代策略 10.2.2 建模活动中人员的分工与职责 10.2.3 UML
2020/5/20
7 /110
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 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根据任 务量和复杂度，使用这些数据来决定一页的费用— —这是一个通过接口将所有数据传递给模块的功能。 每一页的费用与任务的大小成反比，与任务的复杂 度成正比。