软件工程 Chapter 6 - USTChome.ustc.edu.cn/~xiaoning/se2017/PPT/SE_06_Designing...Pfleeger and Atlee, Software Engineering: Theory and Practice 软件工程 Chapter 6 设计模块

Pfleeger and Atlee, Software Engineering: Theory and Practice

软件工程

Chapter 6

设计模块

Shari L. Pfleeger Joanne M. Atlee

4

th Edition


软件工程

Contents 6.1 设计方法 6.2 设计原则 6.3 面向对象的设计 6.4 在UML中体现面向对象设计 6.5 面向对象设计模式 6.6 设计中其他方面的考虑 6.7 面向对象度量 6.8 设计文档 6.9 信息系统的例子 6.10 实时系统的例子 6.11 本章对你的意义


软件工程

第6章的目标

• 设计原则 • 面向对象启发法 • 设计模式 • 异常和异常处理 • 文档设计


软件工程

6.1 设计方法 • 已有：

– 对客户问题的解决方案的抽象描述， – 软件体系结构设计 – 把设计分解成软件单元和为系统分配功能性需求的计划

• 体系结构设计阶段的末期和模块级设计阶段的初期没有严格界限 • 没有相应的“设计食谱”来指导如何从软件单元的规格说明书到它的模

块设计 – No comparable design recipes for progressing from a software unit’s

specification to its modular design • 通往最终解决方案过程本身并不如我们制作的文档重要

– The process taken towards a final solution is not as important as the documentation produced


软件工程

6.1设计方法 Refactoring 重构

• 需要周期性地重审和修改设计决策 • 重构 Refactoring • 目标：

– 简化过度复杂的方案 – 处于某种特殊性能的考虑而对设计进行优化


软件工程

6.2 设计原则 • 设计原则(Design principles) 是指把系统功能和行为分解成模块的指导方针

• 从两个角度明确了应该使用的标准 – 系统分解 – 确定在模块中将要提供哪些信息(和隐藏哪些信息)

• 6个领域的原则: – 模块化 Modularity – 接口 Interfaces – 信息隐藏 Information hiding – 增量式开发 Incremental development – 抽象 Abstraction – 通用性 Generality


软件工程

6.1设计原则补充材料 6.1 “伪造”合理的设计过程

• 在理想的设计过程中，软件系统的设计应该从高层的规格说明推进到解决方案 – 使用一系列的自顶向下、无差错的设计决策 – 以得到层次化的模块集合

• 由于某些原因(如不正确的理解、需求的变更、重构或人为错误)，从需求到模块的设计工作很少进行得顺利、直接

• 我们应该在完全按照理想过程的假设下，编写将要制作出的文档 – 把软件单元分解成模块 – 定义模块的接口 – 描述模块间的相互依赖关系 – 把模块内部设计文档化

• 为延期实现的设计决策插入预留位置；当细节变得清晰时，添加新的信息


软件工程

6.2 设计原则模块化 Modularity

• 模块化(Modularity) 是一种把系统中各个不相关的部分进行分离的原则（也被称为关注点分离separation of concerns ）

• 如果该原则运用得当，每个模块都有自己唯一目的，并且相对独立于其他模块 – 每个模块理解和开发将会更加简单 – 故障定位更容易 (因为对于一个故障，可疑的模块会减少) – 系统的修改更容易 (一个模块的变动所影响的其他模块会减少)

• 为确定一个设计是否很好地分离了关注点，我们使用两个概念来度量模块的独立程度： – 耦合度 coupling – 内聚度 cohesion


软件工程

6.2设计原则耦合度 Coupling

• 紧耦合(tightly coupled) ：模块间有大量依赖关系 • 松耦合(Loosely coupled) ：模块间具有某种程度依赖性，但是它们

之间的相互连接比较弱 • 非耦合(Uncoupled)：模块之间没有任何相互连接，它们之间是完全

独立的

Tightly coupled - many dependencies

Loosely coupled - some dependencies

Uncoupled - no dependencies


软件工程


• 模块之间的依赖方式有很多种: – 一个模块引用另一个模块 – 一个模块传递给另一个模块的数据量 – 某个模块控制其他模块的数量

• 可以根据依赖关系的范围来测量耦合度


软件工程


• 内容耦合 • 公共耦合 • 控制耦合 • 标记耦合 • 数据耦合

TIGHT COUPLING

LOOSE COUPLING

LOW COUPLING

Content coupling

Common coupling

Control coupling

Stamp coupling

Data coupling

Uncoupled


软件工程

6.2设计原则内容耦合 Content Coupling

• 一个模块修改了另一个模块的内部数据项 • 一个模块修改另一个模块的代码

Module B _________________ _________________ _________________ _________________ Generate D Call D _________________ _________________ _________________ _________________ _________________ _________________ _________________ _________________

Module D _________________ _________________ _________________ _________________ _________________ _________________ _________________ _________________ _________________ _________________


软件工程

6.2设计原则公共耦合 Common Coupling

• 对公共数据的改变意味着需要通过反向跟踪所有访问过该数据的模块来评估该改变的影响


软件工程

6.2设计原则控制耦合 Control Coupling

• 某个模块通过传递参数或返回代码来控制另一个模块的活动时

• 如果没有接收到来自控制模块的指令，受控制的模块不可能工作的


软件工程

6.2设计原则标记和数据耦合 Stamp and Data Coupling

• 标记耦合(Stamp coupling)：复杂的数据结构在模块间传递 – 标记耦合体现了模块之间更为复杂的接口，因为模块之间的数据

格式和组织必须匹配

• 如果仅传递数值，不是结构数据，则模块之间是通过数据耦合(data coupling)连接的 – 数据耦合更简单，并且因数据表示的改变而出错的可能性更小


软件工程

6.2设计原则内聚度 Cohesion

• 内聚度(Cohesion)是指模块的内部元素(数据、功能、内部模块)的“粘合”程度

LOW COHESION

HIGH COHESION

Coincidental

Logical

Temporal

Procedural

Communicational

Functional

Informational


软件工程


• 巧合内聚 Coincidental (worst degree) – 模块的各个部分互不相关

• 逻辑内聚 Logical – 模块中的各个部分只通过代码的逻辑结构相关联

• 时态内聚 Temporal – 模块中的数据和功能仅因在一个任务中同时被使用而形成关联

• 过程内聚 Procedural – 与时态内聚相似 – 其功能总是设计相关活动和针对相关的目标 – Similar to temporal, and functions pertain to some related action

or purpose


软件工程


• 通信内聚 Communication – 操作于同一数据集

• 功能内聚 Functional (ideal degree) – 一个模块中包含了所有必需的元素 – 每一个处理元素对于执行单个功能来说都是必需的

• 信息 Informational – 在功能内聚基础上，将其调整为数据抽象化和基于对象的设计


软件工程

6.2设计原则接口 Interfaces

• 接口(interface) 定义了该软件单元为系统其他部分提供的服务，以及如何获取这些服务 – 例如，一个对象的接口是该对象所有公共操作以及这些操作的签名

(signatures)的集合，指定了操作名称、参数和可能的返回值

• 为确保该单元能够正确工作，接口还必须依据服务或假设来定义该单元所必需的信息

• 软件单元的接口描述了它向环境提供哪些服务，以及对环境的要求


软件工程


• 一个软件单元可能有若干不同的接口来描述不同的环境需求或者不同的服务

Data ________________ _________________ _________________ Operation 1 _________________ _________________ _________________ _________________ Operation 2 _________________ _________________ _________________ _________________

Module

Interface A Operation 1 () Operation 2 () Operation 4 ()

Interface B Operation 2 () Operation 3 ()

Operation 3 _________________ _________________ _________________ _________________ Operation 4 _________________ _________________ _________________ _________________


软件工程


• 软件单元的规格说明(specification)描述了软件单元的外部可见的性质

• 接口的规格说明需向其他系统开发人员传达正确应用该软件单元的所有信息 – 目标 Purpose – 前置条件 Preconditions (assumptions) – 协议 Protocols – 后置条件 Postconditions (visible effects) – 质量属性 Quality attributes


软件工程

6.2设计原则信息隐藏 Information Hiding

• 信息隐藏(Information hiding) 以系统分解为特征: – 每个软件单元都封装了一个将来可以改变的独立的设计决策 – 根据外部可见的性质，在接口和接口规格说明的帮助下描述各个软件单元

• 遵循该原则，模块可能表现出不同类型的耦合 – 隐藏了数据表达形式的模块可能是信息内聚的 – 隐藏了算法的模块可能是功能内聚的 – 隐藏了任务执行顺序的模块可能是过程内聚的

• 信息隐藏的一个很大的好处是使得软件单元具有低耦合度


软件工程

6.2设计原则补充材料 6.2 面向对象设计中的信息隐藏

• 在OO设计中，将一个系统分解成对象和它们的抽象类型 – 从这个角度来说，每个对象对其他对象隐藏了它的数据表示 – 其他对象访问给定对象的唯一途径是通过这个对象接口中声明的访问函数 – 使用这种信息隐藏技术，使得更容易改变对象的内部表示，而不影响系统的其他部分

• 数据表示并不是我们可以隐藏的唯一设计决策 – 可能需要扩大对象的概念，以涵盖包括数据类型在内的信息类型

• 对象之间不可能完全非耦合，因为一个对象至少要知道另一个对象才能实现交互 – 意味着，一旦改变对象的名称或者对象实例的个数，那么所有调用该对象的单元都要做出相应的改变 – 当被访问的对象有着特定标识时，我们无法对这种依赖做出显著的改善


软件工程

6.2设计原则增量式开发 Incremental Development

• 假定一个软件设计是由软件单元和它们的接口所组成的，我们可以使用单元之间的依赖关系来设计出一个增量式设计开发进度表

• 首先指定单元间的使用关系(uses relation) – 为各个软件单元和它依赖的单元之间建立关联

• 使用图(Uses graphs) 可以帮助我们逐步确定更大的系统子集，对此可以增量地进行实现和测试


软件工程


• 两种设计的使用图 – 扇入(Fan-in) ：使用某个软件单元的单元数量 – 扇出(Fan-out) ：某个软件单元中使用其他单元的数量


软件工程


• 我们可以尝试使用夹层法(sandwiching)来消除使用图中的循环 – 循环中的一个单元被分解成两个单元，这样分解后的新单元中有一个没有必须依赖的单元

– 夹层法可以反复使用，以解除高耦合单元间的相互依赖或较长的循环链

(a) (b) (c)


软件工程

6.2设计原则抽象 Abstraction

• 抽象(abstraction)是一种忽略一些细节来关注其他细节的模型或表示

• 在定义中，关于模型中哪部分细节被忽略是很模糊的，因为不同的目标会对象不同的抽象，会忽略不同的细节


软件工程

6.2设计原则补充材料6.3 使用抽象

• Suppose that one of the system functions is to sort the elements of a list L. The initial description of the design is:

Sort L in nondecreasing order The next level of abstraction may be a particular algorithm: DO WHILE I is between 1 and (length of L)–1:

Set LOW to index of smallest value in L(I),..., L(length of L)

Interchange L(I) and L(LOW)

ENDDO

• The algorithm provides a great deal of additional information, however, it can be made even more detailed


软件工程

6.2 Design Principles Sidebar 6.3 Using Abstraction

• The third and final algorithm describes exactly how the sorting operation will work:

DO WHILE I is between 1 and (length of L)-1

Set LOW to current value of I

DO WHILE J is between I+1 and (length of L)

IF L(LOW) is greater than L(J)

THEN set LOW to current value of J

ENDIF

ENDDO

Set TEMP to L(LOW)

Set L(LOW) to L(I)

Set L(I) to TEMP

ENDDO


软件工程

6.2设计原则通用性 Generality

• 通用性(Generality) 是一种…的设计原则 – 在开发软件单元时，使它尽可能地能够成为通用的软件，来加强它在将来

某个系统中能够被使用的可能性

• 我们通过增加软件单元使用的上下文环境的数量来开发更加通用的软件单元

• 几条实现原则: – 将特定的上下文环境信息参数化 – 去除前置条件 – 简化后置条件


软件工程

6.2设计原则通用性 Generality

• 下面4个接口按通用性递增排列: PROCEDURE SUM: INTEGER;

POSTCONDITION: returns sum of 3 global variables

PROCEDURE SUM (a, b, c: INTEGER): INTEGER;

POSTCONDITION: returns sum of parameters

PROCEDURE SUM (a[]: INTEGER; len: INTEGER): INTEGER

PRECONDITION: 0 <= len <= size of array a

POSTCONDITION: returns sum of elements 1..len in array a

PROCEDURE SUM (a[]: INTEGER): INTEGER

POSTCONDITION: returns sum of elements in array a


软件工程

6.3 面向对象的设计(OO Design) • 面向对象的方法(Object oriented methodologies) 是最受欢迎、最完善的设计方法

• 一个设计是面向对象的(object oriented)，如果该设计将系统分解成若干个封装了数据和函数的运行时构件，即所谓的“对象” – 对象是唯一可标识的(identifiable)运行时实体，它们可以设计成消息或请

求的目标 – 对象是可组合的(composed)，因为它的数据变量本身可能也是对象(封装

了对象的内部变量的实现) – 对象的实现可以通过继承(inheritance)的方式被复用和扩展，用来定义其

他对象的实现 – OO的代码可以是多态的(polymorphic)：可以对多个不同但类型相关的

对象都起作用的通用代码


软件工程

6.3 OO Design 术语 Terminology

• A class(类) is a software module that partially or totally implements an abstract data type

• If a class is missing implementations for some of its methods, we say that it is an abstract class(抽象类)

• The class definition includes constructor(构造函数) methods that spawn new object instances

• Instance variables(实例变量) are program variables whose values are references to objects


软件工程


• The runtime structure of an OO system is a set of objects(对象), each of which is a cohesive collection of data plus all operations for creating, reading, altering, and destroying those data

• An object’s data are called attributes(属性), and its operations are called methods(方法)

• An object may have multiple interfaces, each offering a different level of access to the object’s data and methods – Such interfaces are hierarchically related by type: if one interface offers a

strict subset of the services that another interface offers, we say that the first interface is a subtype(子类型) of the second interface (the supertype 超类型)


软件工程


addItem(Item) removeItem(product No.) computeSubtotal() computeTax() computeTotal() voidSale()

Sale

subtotal : Money tax : Money total : Money

Date

day: 1..31 month : 1..12 year : integer

Item

product No. name description price : Money

sale date

1 *

*


软件工程


• Variables can refer to objects of different classes over the course of a program’s execution, known as dynamic binding(动态绑定)

• The directed arrows in the figure below depict the relationships between constructs, and the adornments at the ends of each arrow indicate the multiplicity(多重性) (how many of an item may exist)


软件工程


• 4种面向对象的结构：类、对象、接口、实例变量


软件工程


• Building new classes by combining component classes, much as children build structures from building blocks is done by object composition(对象组合)

• Alternatively, we can build new classes by extending or modifying definitions of existing classes – This kind of construction, called inheritance(继承), defines a

new class by directly reusing (and adding to) the definitions of an existing class


软件工程


• 继承的例子


软件工程


• 多态(Polymorphism) occurs when code is written in terms of interactions with an interface, but code behavior depends on the object associated with the interface at runtime and on the implementations of that object’s method

• 继承、对象组合、多态是面向对象设计的重要特征，它们使得设计出来的系统在很多方面都是有用的


软件工程

6.3 OO Design 继承与对象组合

• A key design decision is determining how best to structure and relate complex objects

• In an OO system, there are two main techniques for constructing large objects – Inheritance – composition

• A new class can be created by extending and overriding the behavior of an existing class, or it can be created by combining simpler classes to form a composite class.


软件工程

6.3 OO Design Inheritance vs. Object Composition

• Each construction paradigm has advantages and disadvantages • Composition is better than inheritance at preserving the encapsulation of the

reused code, because a composite object accesses the component only through its advertised interface

• By contrast, using the inheritance approach, the subclass’s implementation is determined at design time and is static

• The resulting objects are less flexible than objects instantiated from composite classes because the methods they inherit from their parent class cannot be changed at runtime

• The greatest advantage of inheritance is the ability to change and specialize the behaviors of inherited methods, by selectively overriding inherited definitions


软件工程

6.3 OO Design Inheritance vs. Object Composition


软件工程

6.3 OO Design 可替换性 Substitutability

• Ideally, a subclass must preserve the behavior of its parent class, so that client code can treat instances of it as instances of the parent class

• 利斯科夫替换原则 Liskov Substitutability Principle – 子类支持父类的所有方法，并且它们的签名是兼容的(compatible) – 子类的方法必须满足父类方法的规格说明

• 前置条件规则 pre_parent ⇒ pre_sub • 后置条件规则 pre_parent ⇒ (post_sub ⇒ post_parent )

– 子类必须保留父类中声明了的所有性质 • 就其他大部分设计原则而言，可替换性并不是一个强制性的规定。相反的，

该原则作为指南使用，帮助我们决定什么时候不检查被扩展类的客户端模块，而能保证它是安全的


软件工程

6.3 OO Design 德米特法则 Law of Demeter

• Law of Demeter: 通过把组合类中作用在类构件上的每个方法都包含进来，可以降低它们的依赖程度

• 优点: 使用组合类的客户代码仅仅需要知道组合本身，而不需要知道组合的构件

• 遵循德米特法则的设计具有更少的依赖关系，而类之间的依赖关系越少，软件故障也就越少


软件工程

6.3 OO Design 德米特法则 Law of Demeter


软件工程

6.3 OO Design 依赖倒置 Dependency Inversion

• 依赖倒置是最后一个与面向对象设计相关的启发式方法 – 把两个类之间的依赖连接方向进行倒置

• 通过引入接口来实现依赖倒置 • 很多设计模式中都会用到这种依赖倒置的原则


软件工程

6.4 在UML中体现面向对象设计

• UML是用来描述面向对象解决方案的一种受欢迎的设计标识法

• UML可以用来可视化、说明或文档化软件设计 • UML在描述不同的设计选择，直至最终对设计工件

(artifact)进行文档化时，是特别有用的


软件工程

6.4在UML中体现面向对象设计过程中的UML

• Use case diagrams 用例图 • UML activity diagrams UML活动图 • Domain model 领域模型 • Component diagrams UML构件图 • Deployment diagrams UML部署图 • Class diagrams UML类图 • Interaction diagrams 交互图 • Sequence diagrams 顺序图 • Communication diagrams 通信图 • Activity diagrams 活动图 • State diagrams 状态图 • Package diagrams 包图


软件工程

6.4在UML中体现面向对象设计过程中的UML

• 如何在开发过程中使用UML

Requirements Design Architecture

UML use case diagrams

Scenarios

UML activity diagrams

UML state diagrams

UML class diagrams

UML object diagrams

UML sequence diagrams

UML communication

diagrams

UML package diagrams

UML component diagrams

UML deployment diagrams

Domain models

UML activity diagrams


软件工程

6.4在UML中体现面向对象设计补充材料 6.4 皇家服务站需求

• Royal Service station provides three types of services • The system must track bills, the product and services • System to control inventory • The system to track credit history, and payments overdue • The system applies only to regular repeat customer • The system must handle the data requirements for interfacing with other system • The system must record tax and related information • The station must be able to review tax record upon demand • The system will send periodic message to customers • Customer can rent parking space in the station parking lot • The system maintain a repository of account information • The station manager must be able to review accounting information upon demand • The system can report an analysis of prices and discounts • The system will automatically notify the owners of dormant accounts • The system can not be unavailable for more than 24 hours • The system must protect customer information from unauthorized access


软件工程

6.4在UML中体现面向对象设计 UML类图

• UML类图描述了对象类型和它们之间的静态关系 – 特别是对象之间的关系，以及父类和子类将的关系 – 类图能描述每个对象的属性，它们各自的行为，以及每个类或对象所受的限制

• Look for and seek – 参与者；物理对象；位置；组织；记录；事务；事物的集合；操作过程；系统将会操纵的事物


软件工程


• 皇家服务站系统用例图


软件工程


• 哪些数据需要以某种方式被“处理”？ • 哪些条目有多个属性? • 什么时候一个类所拥有的对象不止一个? • 哪些信息是根据需求本身而得出的，而不是从对需求的理解中得到的? • 哪些属性和操作对一个类或对象总是适用的?


软件工程

6.4在UML中体现面向对象设计属性和类的初始组织: Step 1

Attributes Classes

Personal check 个人支票 Customer 顾客

Tax 税 Maintenance 维护

Price 价格 Services 服务

Cash 现金 Fuel 燃油

Credit card 信用卡 Bill 账单

Discounts 折扣 Purchase 购买 Station manager 站管理员


软件工程


Attributes Classes Personal check 个人支票 Customer 顾客 Tax 税 Maintenance 维护 Price 价格 Services 服务 Cash 现金 Parking 停车 Credit card 信用卡 Fuel 燃油 Discounts 折扣 Bill 账单 Name 姓名 Purchase 购买 Address 地址 Maintenance reminder 维护提醒 Birthdate 生日 Station manager 站管理员


软件工程


Attributes Classes Personal check Tax Price Cash Credit card Discounts Name Address Birthdate

Customer Maintenance Services Parking Fuel Bill Purchase Maintenance reminder Station manager Overdue bill letter 过期账单信件 Dormant account warning 休眠账户警告 Parts 部件 Accounts 账户 Inventory 库存清单 Credit card system 信用卡系统 Part ordering system 部件订购系统 Fuel ordering system 燃油订购系统


软件工程

6.4在UML中体现面向对象设计 Guidelines for Identifying Behaviors

• 祈使动词 Imperative verbs • 被动词 Passive verbs • 动作 Actions • 其中的成员关系 Membership in • 管理或拥有 Management or ownership • 对谁负责 Responsible for • 一个组织提供的服务 Services provided by an organization


软件工程

6.4在UML中体现面向对象设计皇家服务站的初次设计


软件工程

6.4在UML中体现面向对象设计类的关系类型

Association关联

Composition组合

Aggregation聚合

Dependency依赖

Navigation导航

Generalization泛化


软件工程

6.4在UML中体现面向对象设计第二次设计的皇家服务站类图


软件工程

6.4在UML中体现面向对象设计最终设计的皇家服务站类图


软件工程

6.4在UML中体现面向对象设计其他UML图

• 类描述模板 Class description template • UML包图 Package diagrams • 交互图 Interaction diagrams • 顺序图 Sequence diagrams • 通信图 Communication diagrams • 状态图 State diagrams • 活动图 Activity diagrams


软件工程

6.4在UML中体现面向对象设计 Other UML Diagrams – Class Description Template

Class name: Refuel Category: service External documents: Export control: Public Cardinality: n Hierarchy: Superclasses: Service Associations: <no rolename>: fuel in association updates Operation name: price Public member of: Refuel Documentation: // Calculates fuel final price Preconditions: gallons > 0 Object diagram: (unspecified)


软件工程

6.4在UML中体现面向对象设计 Other UML Diagrams – Class Description Template

Semantics: price = gallons * fuel.price_per_gallon tax = price * purchase.tax_rate Object diagram: (unspecified) Concurrency: sequential Public interface: Operations: price Private interface: Attributes: gallons Implementation: Attributes: gallons State machine: no Concurrency: sequential Persistence: transient


软件工程

6.4在UML中体现面向对象设计 Other UML Diagrams – Package Diagram

• UML包图使得我们可以

将系统看成是一个小的，由包组成的集合。每个包都可以展开为一个由类组成的大的集合


软件工程

6.4在UML中体现面向对象设计 Other UML Diagrams – SequenceDiagram

• 交互图描述对象如何实现操作和行为

• 交互图有两种： – 顺序图 – 通信图


软件工程

6.4在UML中体现面向对象设计 Other UML Diagrams – Communication Diagram

• 通信图描述对象之间的消息顺序，但是它是基于对象模型之上的，适用对象之间的链接作为隐含的信道


软件工程

6.4在UML中体现面向对象设计 Other UML Diagrams – StateDiagram

• 状态图展示了对象可能具备的状态、触发状态改变的事件，以及每次状态改变所导致的动作


软件工程

6.4在UML中体现面向对象设计 Other UML Diagrams – State Diagram


软件工程

6.4在UML中体现面向对象设计 Other UML Diagrams – Activity Diagram

• 活动图被用于为类中的过程流或活动流建模

• 决策节点用于表示选择（调用哪个活动）


软件工程

6.4在UML中体现面向对象设计 Other UML Diagrams – Activity Diagram (continued)

• 活动图被用于为类中的过程流或活动流建模

• 类inventory的活动图 • 有两个决策

– 验证燃油是否充足 – 验证是否还有部件储备


软件工程

6.5 OO 设计模式

• 设计模式(design pattern)编写了设计决策以及最好的实践，根据设计原则来解决一些特定的问题 • A design pattern codifies design decisions and best practices for solving a

particular design problem according to design principles

• 设计模式和软件库并不相同，它们不是拿来就可以适用的打包的解决方案，而是解决方案的模板，必须针对各种特定的使用情况进行修改和调整 • Design patterns are not the same as software libraries; they are not packaged

solutions that can be used as is. Rather, they are templates for a solution that must be modified and adapted for each particular use


软件工程

6.5 OO 设计模式模板方法模式 Template Method Pattern

• 模板方法模式的目标是减少同属于一个父类的几个子类之间的重复代码量特别适合于：多个子类对同样的方法有着相似但不是完全相同的实现时该模式将重复的代码结构放置在一个抽象类中，然后让子类继承这个抽象类

• 抽象类定义了一个模板方法(template method )来实现一个操作中共同的步骤，并且声明了抽象的原语操作(primitive operation)来表示变化的部分


软件工程

6.5 OO设计模式模板方法模式 Template Method Pattern


软件工程

6.5 OO设计模式工厂方法模式 Factory Method Pattern

• 工厂方法模式封装了创建对象的代码 • 工厂方法模式和模板方法模式相似 • 类似但不完全等同的方法是实例化对象的构造函数的方法


软件工程

6.5 OO设计模式策略模式 Strategy Pattern

• 策略模式使得可以在运行时选择算法

• 适用于：有多个算法可用于一

个应用，但知道运行时候才能知道选择哪个算法最好


软件工程

6.5 OO设计模式装饰模式 Decorator Pattern

• 装饰模式可以在运行时扩展对象的功能 • 为了支持新的特征，可以使用

• 子类继承 • 装饰模式(更灵活)


软件工程

6.5 OO设计模式观察者模式 Observer Pattern

• 观察者模式是发布-订阅

体系结构风格的一种应用

• 适用于：软件在某个关键事件时

需要通知多个对象


软件工程

6.5 OO设计模式组合模式 Composite Pattern

• 组合对象(composite object)是异构(可能也是递归的)对象的汇集(collection)，表示一些组合的实体

• 组合模式中，每个对象都共用统一的接口


软件工程

6.5 OO设计模式访问者模式 Visitor Pattern

• 访问者模式把操作片段集中并封装在自身类中

• 每个操作都实现抽象类Visitor的一个单独的子类


软件工程

6.5 OO 设计模式 Application of Composite Pattern to Represent Math Expressions


软件工程

6.6 设计中其他方面的考虑数据管理

• 数据管理考虑的就是与性能和空间相关的系统需求 • 根据对数据需求和相关约束的裂解，我们必须列出对象及其操作的

设计 • 4个步骤:

确认数据、数据结构及它们之间的关系设计管理数据结构及其互相关系的服务找到工具，例如数据库管理系统，来实现某些数据管理任务设计类和类层次，来检查数据管理功能


软件工程

6.6设计中其他方面的考虑 Data Management for the Royal Service Station


软件工程

6.6设计中其他方面的考虑异常处理 Exception Handling

• Allows making programs become more robust • Helps separate error checking and recover from a program’s main

functionality • Chapter 5 offers more details


软件工程

6.6设计中其他方面的考虑异常处理 Exception Handling

attempt_transmission (message: STRING) raises TRANSMISSIONEXCEPTION // Attempt to transmit message over a communication line using // the low-level procedure unsafe_transmit, which may fail, //triggering an exception. // After 100 unsuccessful attempts, give up and raise an exception local failures: INTEGER try unsafe_transmit (message) rescue failures := failures + 1; if failures < 100 then retry else raise TRANSMISSIONEXCEPTION end end


软件工程

6.6设计中其他方面的考虑 Designing User Interfaces 用户界面设计

• 必须考虑几个问题: 确定谁将与系统进行交互开发系统可能执行任务的每种方式的场景设计用户命令的层次细化用户与系统交互的时序设计层次中相关的类，以实现用户界面设计决策把用户界面类集成到整个系统的类层次中


软件工程



软件工程



软件工程

6.6设计中其他方面的考虑框架 Frameworks

• 框架是针对特定应用领域的大规模的可复用设计 • GUI editors, web applications, accounting systems • 和软件产品线的区别：

• 软件产品线是公司开发供自己使用的 • 框架往往是公共可用资源（和工具箱toolkit类似）

• 框架往往是高层体系结构和模块，低层的细节需要填入


软件工程

6.7 面向对象度量面向对象系统规模的度量

• Objects(对象) and methods(方法) as a basic size measure • Lorenz and Kidd’s nine aspects of size 场景脚本的数目 Number of scenario script (NSS) 关键类的数目 Number of key classes 支持类的数目 Number of support classes 每个关键类的平均支持类数目 The average number of support classes per key classes 子系统的数目 Number of subsystems 类规模 Class size 子类重载操作数目 Number of operations overridden by a subclass (NOO) 子类添加的操作数目 Number of operation added by a subclass 转化指数 Specialization index •SI = (NOO X debth) / (total class methods)


软件工程

6.7面向对象度量 Lorenz and Kidd Metrics Collection in Different Phases of Development

Metric Requirements Description

System Design

Program Design Coding Testing

Number of scenario script X

Number of key classes X X

Number of support classes X Average number of support classes per key class X

Number of subsystem X X Class size X X X

Number of operations overridden by a subclass X X X X

Number of operations added by a subclass X X X

Specialization index X X X X


软件工程

6.7面向对象度量皇家服务站的用例图


软件工程

6.7面向对象度量皇家服务站的类层次图


软件工程

6.7面向对象度量面向对象系统设计质量的度量

• Chidamber和Kemerer也为面向对象的开发设计了一套度量方法 • 关注设计质量 (不是规模)

每个类的加权方法

继承的深度子类的数目对象之间的耦合度类的响应度方法中内聚的缺乏程度Lack of cohesion of methods, LCOM


软件工程

6.7面向对象度量 Chidamber-Kemerer Metrics applied to the Royal Service Station’s System Design


软件工程

6.7面向对象度量计算耦合度

• Given class C with n methods, M1 through Mn • Suppose {Ij} is the set of instance variables used by the method M • We can define P to be collection of pairs (Ir , Is) where Ir and Is, share no

common members P = {(Ir , Is) | Ir ∩ Is = Ø}

• Q is the collection of pairs (Ir , Is) where Ir and Is, share at least one common member

Q = {(Ir , Is) | Ir ∩ Is ≠ Ø} • Lack of cohesion in methods for C to be

|P|-|Q| if |P| > |Q| Zero if otherwise


软件工程

6.7面向对象度量 Chidamber-Kemerer Metrics applied to the Royal Service Station’s System Design


软件工程

6.7面向对象度量 Other Metrics

• Li and Henry (1993): metrics to predict the size of changes in classes during maintenance 消息传递耦合 Message-passing coupling: the number of methods

invocations in a class’s implementation 数据抽象耦合 Data abstraction coupling: the number of abstract data

types used in the measured class and defined in another class of the system

• Travassos (1999) 平均操作大小 The average operation size 每个操作的平均参数数目 The average number of parameters per operation


软件工程

6.7面向对象度量根据时序图得到的测量


软件工程

6.7面向对象度量在何处进行面向对象测量

• 只有当度量可以用来帮助我们增进对系统的理解、预测或控制时，它才是有价值的 • 度量与很多种类型的文档相关

• 用例图 Use cases • 类图 Class diagrams • 交互图 Interaction diagrams • 类描述 Class descriptions • 状态图 State diagrams • 包图 Package diagrams


软件工程

6.7面向对象度量在何处进行面向对象测量


软件工程

6.8 设计文档

• 系统体系结构的细节文档化于 documented in Software Architecture Document (SAD)

• SAD是连接需求和设计的桥梁 • Many ways to document the design • 按合同设计(Design by contract):

• 一种特殊的创建文档的方法 • 使用文档的目的不仅用来描述设计，而且用来鼓励开发人员之间的交互


软件工程

6.8设计文档按合同设计 Design by Contract

• 在按合同设计方法中，每个模块都有一个接口规格说明，精确描述了该模块应该做的事情

Meyer (1997) 提出按合同设计有助于确保模块之间可以正确地互操作这个规格说明，称为合同(contract),, 控制了模块和模块以及模块和其他系统之间的交互方式这样的规格说明不能保证模块的正确性，但为测试和验证提供了一个清晰一致的基础合同涵盖了相互义务(前置条件)，利益(后置条件)和一致性的约束(称为不变量invariant) 综合起来，合同的这些性质称为断言assertions


软件工程

6.8设计文档按合同设计 Design by Contract

• Design contract between software provider and user


软件工程

6.9 信息系统的例子 Data Model of Opposition Programs

Broadcast by Piccadilly’s Competition

• Domain elements and relationships that the Piccadilly database will maintain

• A closer examination will reveal that there are considerable commonality


软件工程

6.10 实时系统的例子 Design by Contract

• Had Ariane-5 been implemented using an object-oriented approach, the reuse would have been either in terms of composition or inheritance

• In composition approach: the SRI is viewed as a black box and called from the main system

• In inheritance approach: the SRI structure and behavior are open to view, inheriting as much structure and behavior from parent classes as possible


软件工程

6.11 本章对你的意义

• The design process describes the system components using a common language with which to communicate

• Object orientation is a particularly appealing basis for such design, because it allows us to describe and reason about the system from its birth to its delivery in the same terms: classes, objects, and methods

• Consistent notation makes it easier for your team to understand the implications of using a particular object or class Consistency assists the maintainers and testers, enabling them to build test

cases and monitor changes more easily Because the requirements, design, and code are expressed in the same way, it is

easier for you to evaluate the effects of proposed changes to the requirements or designs

Documents

软件工程 Chapter 6 - USTChome.ustc.edu.cn/~xiaoning/se2017/PPT/SE_06_Designing...Pfleeger and Atlee, Software Engineering: Theory and Practice 软件工程 Chapter 6 设计模块