shari l. pfleeger joanne m. atlee -...

Pfleeger and Atlee, Software Engineering: Theory and Practice

软件工程

Chapter 5

设计体系结构

Shari L. Pfleeger Joanne M. Atlee

4th Edition


软件工程

Contents 5.1 设计过程 5.2 体系结构建模 5.3 分解和视图 5.4 体系结构风格和策略 5.5 满足质量属性 5.6 协作设计 5.7 体系结构的评估和改进 5.8 文档化软件体系结构 5.9 体系结构设计评审 5.10 软件产品线 5.11 信息系统的例子 5.12 实时系统的例子 5.13 本章对你的意义


软件工程

第5章的目标

• Examine different types of decomposition • Compare competing designs • Document the design • Verify architecture meets the requirements


软件工程

5.1 设计过程

• 设计(Design) 是一种创造性的过程，它考虑如何实现所有的客户需求。设计所产生的计划也称为设计

• 早期的设计(Early design) ：系统的体系结构(system’s architecture)

• 后续的设计(Later design) ：如何实现单个的单元


软件工程

5.1设计过程设计是一种创造性过程

• 设计是一种具有智力挑战性的任务 – 要搞清楚软件系统可能遇到的所有可能情况 – 非功能目标 (e.g., ease of use, ease to maintain) – 外部因素 (e.g., standard data formats, government regulations)

• 通过学习优秀的设计例子，来改进我们的设计技巧

• 大部分设计工作是例程设计(routine design) – 通过对相似问题的解决方案进行复用和调整来解决问题


软件工程


• 有效利用现有解决方案的方法有很多 – 克隆(Cloning): 借鉴现有的整个

设计/代码，仅对它做少许调整 – 参考模型(Reference models):

Generic architecture that suggests how to decompose the system


软件工程


• 编译器的参考模型


软件工程


• 更典型的情况，对于要解决的问题没有一个参考模型

• 软件体系结构也具有一般性的解决方案，称为体系结构风格(architectural styles) – Focusing on one architectural style can create problems – Good design is about selecting, adapting, and integrating

several architectural design styles to produce the desired result


软件工程


• 用于理解决策以及评估选择的体系结构的工具很多，包括: – 设计模式(Design patterns): 针对单个软件模块或少量模块而给出

的一般性解决方案 – 设计公约(Design convention or idiom): 一系列设计决策和建议的

集合，采用这些，能够提高系统某方面的设计质量 – 创新设计(Innovative design): 具有无规律的突发式进展的特征 – 设计原则(Design principles): 描述的是一些良好设计的特征


软件工程

5.1设计过程设计过程模型

• 软件系统设计是一个迭代的过程 • 最终结果是：software architecture document (SAD)


软件工程

5.1设计过程补充材料 5.1 敏捷体系结构

• 在需求有大量不确定因素的情况下，采用敏捷过程是有利于开发的 • 敏捷体系结构基于4个前提:

– valuing individuals and interactions over processes and tools – valuing working software over comprehensive documentation – valuing customer collaboration over contract negotiation – valuing response to change over following plans

• 使用敏捷方法可能存在的问题: – 必须小心处理复杂度和可能的变化 – 鼓励程序员在建模的同时开始编写代码 – 需要不断地重构


软件工程

5.2 体系结构建模

• 这些模型帮助我们推理所提出的体系结构是否能够满足特定的需求

• 6种使用体系结构模型的方式: – 理解系统 – 确定该系统的哪部分将复用前面已经构建的系统中的元素，以及

系统哪些部分将会被复用 – 展示构建系统的蓝图 – 推测系统将会如何演变 – 分析依赖关系 – 为管理决策提供支持


软件工程

5.3 分解和视图 • High-level description of system’s key elements • Creating a hierarchy of information with increasing details

Top level

First level of decomposition

Second level of decomposition


软件工程

5.3分解和视图普遍的设计方法

• 有些设计问题没有现成的解决方案可供使用 – 设计者用分解的方法来隔离系统的关键问题

• 一些较普遍的设计方法: – 功能性分解 Functional decomposition – 面向特征的分解 Feature-oriented decomposition – 面向数据的分解 Data-oriented decomposition – 面向进程的分解 Process-oriented decomposition – 面向时间的分解 Event-oriented decomposition – 面向对象的设计 Object-oriented design


软件工程


• 功能性分解 Functional decomposition – 把功能或需求分解成模块 – 首先从需求规格说明书列出的功能开始 – 更低层次的设计将这些功能划分成子功能，它们随后将被指派给更小的模块

– 描述模块(子功能)间互相调用的情形


软件工程


•面向特征的分解 Feature-oriented decomposition – 为各个模块指定了各自的特征 – 高层设计描述了具有某个服务和特征集的系统 – 低层设计描述了各个特征如何将服务进行扩展，以及确定特征之间如

何进行交互 lower-level designs describe how each feature augments the

service and identifies interactions among features


软件工程


•面向数据的分解 Data-oriented decomposition – 关注如何将数据分解成模块 – 高层设计描述概念上的数据结构 – 低层设计提供细节

• 数据如何在模块中分配 • 分配好的数据如何实现概念上的模型


软件工程


•面向过程的分解 Process-oriented decomposition – 将系统分解成一系列并发的进程 – 高层设计:

• 确定系统的主要工作 • 为执行进程指派任务 • 解释任务之间是如何协调工作的

– 低层设计描述这些进程的细节


软件工程


•面向事件的分解 Event-oriented decomposition – 关注系统必须处理的事件，将事件的责任分配给不同的模块 – 高层设计将系统预期的输入事件便成目录 – 低层设计将系统分解为状态，并描述事件是如何触发状态转移的


软件工程


•面向对象的分解 Object-oriented decomposition – 将对象分配给模块 – 高层设计定义了系统对象的类型，解释了对象之间是如何关联的 – 低层设计细化了对象的属性和操作


软件工程


• 一个设计是模块化的(modular) – 系统的每个活动都仅由对应的软件单元实现 – 每个软件单元的输入和输出都已经定义明确 – A design is modular when each activity of the system is performed by exactly one software

unit, and when the inputs and outputs of each software unit are well-defined • 一个软件单元是定义明确的(well-defined)

– 接口必须能准确指定该单元的外部可见行为 – A software unit is well-defined if its interface accurately and precisely specifies the unit’s

externally visible behavior


软件工程


• 构件 Component • 子系统 Subsystem • 运行时进程Runtime process • 模块Module • 类Class • 包Package

• 库Library • 过程Procedure • 软件单元Software unit • 模块Modular • 明确定义Well-defined


软件工程

5.3分解和视图补充材料 5.2 基于构件的软件工程

• 基于构件的软件工程(Component-based software

engineering ,CBSE) 是一种将现存的构件组合成系统的软件开发方法

• 构件(component) 是“有着定义明确的接口的、自包含的软件部分”，可以单独开发、购买和销售的实体

• CBSE的目标是 – 通过把开发过程简化成“构件集成”过程来支持系统的快速开发 – 通过把维护过程简化成“构件替换”过程来使维护变得更容易

• At this point, CBSE is still more of a goal than a reality with considerable on-going research


软件工程

5.3分解和视图体系结构视图

• 体系结构视图一般包括： – 分解视图 Decomposition view – 依赖视图 Dependencies view – 泛化视图 Generalization view – 执行视图 Execution view – 实现视图 Implementation view – 部署视图 Deployment view – 工作分配视图 Work-assignment view


软件工程

5.3分解和视图 Decomposition View 分解视图

• 系统分解视图将系统描述为若干个可编程的单元 • 这种视图可以是层次化的 • 使用了多种模型


软件工程

5.3分解和视图 Dependencies View 依赖视图

• 依赖视图展示软件单元之间的依赖关系 • 在做项目计划的时候很有用 • 在对某个软件单元做设计调整时，可以帮助看清该改变带来的影响


软件工程

5.3分解和视图 Generalization View 泛化视图

• 展示一个软件单元是否是另一个单元的泛化或特化

• 在设计抽象或可扩展软件单元时是非常有用


软件工程

5.3分解和视图 Execution View 执行视图

• 是设计人员绘制的传统的方框-箭头图，在考虑到构件和连接器的情况下，展示系统运行时的结构

• 构件(component) 是独立的执行实体，可能会有自己的程序栈

• 连接器(connector) 是一种构件之间的通信机制 – 信道 – 共享数据存储库 – 远程过程调用 – …


软件工程

5.3分解和视图 Implementation View 实现视图

• 在代码单元和源文件之间建立映射 • 帮助程序员在一片源代码文件的迷宫中找到某个软件单元的实现


软件工程

5.3分解和视图 Deployment View 部署视图

• 在…间建立映射 – 运行时实体(如构件、连接器) – 计算机资源(如处理器、数据存储器、通信网络)

• 有助于设计人员分析一个设计的质量 – 性能、可靠性、安全性


软件工程

5.3分解和视图 Work-assignment View 工作分配视图

• 将系统分解成可以分配给各项目团队的工作任务 • 有助于

– 项目管理人员计划和分配工程资源 – 项目管理人员跟踪各个团队的工作进度


软件工程

5.4 体系结构风格与策略

• 管理-过滤器 Pipes-and-Filter • 客户-服务器 Client-Server • 对等网络 Peer-to-Peer • 发布-订阅 Publish-Subscribe • 信息库 Repositories • 分层 Layering


软件工程

5.4体系结构风格与策略 Pipes-and-Filter

• 系统由…构成 – Streams of data (pipe) for input and output – Transformation of the data (filter)

KEY pipe


软件工程

5.4体系结构风格与策略 Pipes-and-Filter

• 一些重要的属性 – The designer can understand the entire system's effect on input and

output as the composition of the filters – The filters can be reused easily on other systems – System evolution is simple – Allow concurrent execution of filters

• 缺点 – Encourages batch processing – Not good for handling interactive application – Duplication in filters functions


软件工程

5.4体系结构风格与策略 Client-Server

• 两种构件: – Server 提供服务 – Clients 通过请求/应答协议（request/reply protocol）访问服务

• Client 可以向Server发送一个可执行的函数，称为回调函数（callback） – Server随后在特定的情况下调用这些回调函数


软件工程

5.4体系结构风格与策略补充材料 5.3 世界杯的客户-服务器系统

• Over one month in 1994, the World Cup soccer matches were held in the United States. Design system issues:

– 24 teams played 52 games – nine different cities that spanned four time zones – results of each game were recorded and disseminated to the press and to the fans – To deter violence among the fans, the organizers issued and tracked over 20,000

identification passes • This system required both central control and distributed functions. Thus, a client-

server architecture seemed appropriate. • The system that was built included a central database, located in Texas, for ticket

management, security, news services, and Internet links. This server also calculated games statistics and provided historical information, security photographs, and clips of video action.

• The clients ran on 160 Sun workstations that were located in the same cities as the games and provided support to the administrative staff and the press


软件工程

5.4体系结构风格与策略 Peer-to-Peer (P2P)

• 每个构件都只执行自己的进程，对于其他同级构件它们既是客户端又是服务器

• 任一个构件都可以其他同级构件发起请求 • 特性

– 易于扩展 – 增加了系统容量 – 容错性好

• 例: Napster and Freenet


软件工程

5.4体系结构风格与策略补充材料 5.4 Napster的P2P结构

• Peers are typically users’ desktop computer systems running general-purpose computing applications (email, word processors, Web browsers, etc.)

– Many user systems do not have stable Internet protocol (IP) addresses – Not always available to the rest of the network – Most users are not sophisticated; they are more interested in content than in the network’s

configuration and protocols – Great variation in methods for accessing the network, from slow dial-up lines to fast

broadband connections • Napster’s sophistication comes from its servers, which organize requests and

manage content, with actual content provided by users, shared from peer to peer, and the sharing goes to other (anonymous) users, not to a centralized file server

• If the file content changes frequently, sharing speed is key, file quality is critical, or one peer needs to be able to trust another, a centralized server architecture may be more appropriate


软件工程

5.4体系结构风格与策略 Publish-Subscribe

• 构件通过对事件的广播和反应实现交互 – 如构件对某个事件感兴趣，则可订阅(subscribe)该事件 – 另一个构件发布(announce / publish)事件发生了，订阅者被通知 – 隐含调用(Implicit invocation) 是一种常见的发布-订阅体系结构

• Registering: 订阅者将自己的某个过程与感兴趣的事件建立关联

• 特性 – 为系统演化和可定制性提供强有力的支持 – 在其他事件驱动的系统中，容易复用构件 – 需要共享的信息库来在构件间共享数据(persistent data) – 难以测试


软件工程

5.4体系结构风格与策略 Repositories

• 两类构件 – 中心数据存储 – 一组构件，在中心数据存储上…操作

• 存储、检索、更新信息

• 难点是决定构件间如何交互 – A traditional database: transactions trigger process execution – A blackboard:

• the central store controls the triggering process • Knowledge sources: information about the current state of the

system’s execution that triggers the execution of individual data accessors


软件工程

5.4体系结构风格与策略 Repositories

• 主要的优点: openness – Data representation is made available to various programmers

(vendors) so they can build tools to access the repository – But also a disadvantage: the data format must be acceptable to

all components


软件工程

5.4体系结构风格与策略 Layering

• 层次化组织 – 每层为其上层提供服务，同时又作为下层的客户 – 层次桥接(Layer bridging): 允许一个层访问所有低层的服务

• The design includes protocols(协议) – 确定两层之间如何交互

• 优点 – High levels of abstraction – Relatively easy to add and modify a layer

• 缺点 – Not always easy to structure system layers – System performance may suffer from the extra coordination among layers


软件工程

5.4体系结构风格与策略 Example of Layering System

• The OSI Model


软件工程

5.4体系结构风格与策略 Combining Architectural Styles组合体系结构风格

• 实际的软件体系结构很少仅使用一个风格 • 体系结构风格有若干种组合方式

– 在不同的层次使用不同的风格 (e.g., overall client-server architecture with server component decomposed into layers)

– 使用混合的风格来为不同的构件或者构件间不同类型交互进行建模 • Use mixture of styles to model different components or types of interaction

(e.g., client components interact with one another using publish-subscribe communications

• 当体系结构被表达成若干模型的集合时，必须为模型之间的联系建立文档


软件工程

5.4体系结构风格与策略 Combination of Publish-Subscribe, Client-Server,

and Repository Architecture Styles


软件工程

5.5 满足质量属性

• 体系结构风格智能实现一般意义上良好的性质 • 为了确保对特定属性的支持，需要使用策略(tactics) :

– 可修改性 Modifiability – 性能 Performance – 安全性 Security – 可靠性 Reliability – 健壮性 Robustness – 易使用性 Usability – 商业目标 Business goals


软件工程

5.5满足质量属性可修改性 Modifiability

• 设计必须便于修改 • 两类受影响的软件单元:

– 受直接影响 Directly affected – 受间接影响 Indirectly affected

• 受直接影响的软件单元： – 为了适应系统改变而改变自身职责的单元

• 受间接影响的软件单元： – 不需要改变自身职责 – 需要修改实现（适应受直接影响的单元产生的变化）


软件工程


• 为减少受直接影响的软件单元数，可用的策略关注于将设计中的预期改变集中在一起: – 预测预期改变(Anticipate expected changes): Identify design

decisions that are most likely to change, and encapsulate each in its own software unit

– 内聚性(Cohesion): Keeping software units highly cohesive increases the chances that a change to the system’s responsibilities is confined to the few units that are assigned those responsibilities

– 通用性(Generality) : The more general the software units, the more likely change can be accommodated by modifying a unit’s inputs rather than modifying the unit itself


软件工程


• 为减少受间接影响的软件单元数，可用的策略关注于减少单元间的依赖关系 – 耦合性(Coupling): Lowering coupling reduces the likelihood that

a change to one unit will ripple to other units – 接口(Interfaces): If a unit interacts with other units only through

their interfaces changes to one unit will not spread beyond the unit’s boundary unless its interface changes

– 多重接口(Multiple interfaces): A unit modified to provide new data or services can offer them using a new interface to the unit without changing any of the unit’s existing interfaces


软件工程

5.5满足质量属性补充材料 5.5 自管理软件

• 为了…，软件界开始对自管理软件进行实验 – 使系统在不同的，有时会变化的环境下有最佳表现 – 也被称为：as autonomic, adaptive, dynamic,

selfconfiguring, self-optimizing, self-healing, context-aware

• 核心思想是相同的 – the software system monitors its environment or its

own performance, and changes its behavior in response to changes that it


软件工程

5.5满足质量属性补充材料 5.5 自管理软件

• Some examples of sensor changes: – Change the input sensors used, such as avoiding vision-based sensors

when sensing in the dark – Change the Web servers that are queried, based on the results and

performance of past queries – Move running components to different processors to balance processor

load or to recover from a processor failure

• Obstacles to building self-managing software: – Few architectural styles – Monitoring nonfunctional requirements – Decision making


软件工程

5.5满足质量属性性能 Performance

• 性能属性描述了系统速度和容量上的特点 – 响应时间(Response time): 软件对请求的反应有多迅速?

– 吞吐量(Throughput): 每分钟可以处理多少请求？ – 负载(Load): 在响应时间和吞吐量变糟糕之前，软件可以支持多少用户使用？


软件工程

5.5满足质量属性性能 Performance

• 提供系统性能可用的策略: – 增加计算资源 – 有效地管理资源分配

• 先到/先服务 First-come/first-served: 按接受到的顺序来处理请求

• 显式优先级 Explicit priority: 按具有优先级高低来处理请求 • 最早时限优先 Earliest deadline first: 按时限长短的顺序来处理请求

– 降低对资源的需求


软件工程

5.5满足质量属性安全性 Security

• 体系结构有两个和安全性联系十分紧密的重要特点 • 免疫力 Immunity: 系统能够阻挡攻击企图

– 体系结构通过…提高免疫力: • 在设计中保证包含了所有的安全性特征 • 间可能被攻击者利用的安全性弱点最小化

• 弹性 Resilience: 系统能够快速容易地从攻击中恢复 – 体系结构通过…提高弹性:

• Segmenting functionality to contain attack • Enabling the system to quickly restore functionality


软件工程

5.5满足质量属性可靠性 Security

• 一个软件系统是可靠的，当其可以在假设的环境下正确地实现所要求的功能 – Is the software internally free of errors?

• 故障(fault ) 是一些人为错误的结果，而失效(failure)是系统行为和预期行为之间一种可观察的偏离 – Software is made more reliable by preventing or tolerating

faults


软件工程


• 被动故障检测 Passive fault detection: wait until fault occurs during execution

• 主动故障检测 Active fault detection: periodically check for symptoms or try to anticipate when failures will occur

• 异常 Exceptions: situations that cause the system to deviate from its desired behavior

• Include exception handling (异常处理) in design to handle exception and return system to acceptable state

• 典型的异常包括: – 不能提供服务 Failing to provide a service – 提供错误的服务 Providing the wrong service – 数据破坏 Corrupting data – 违背系统不变量 Violating a system invariant (e.g.; security property) – 死锁 Deadlocking


软件工程


• N版本编程 (N-version programming) – 如果两个功能相同的系统由两个不同的团队、在不同的时间、使用不同的技术开发而成的，那么这两种实现出现同样的故障的几率十分小

– N版本编程不像设想的那样可靠，因为 • 很多设计人员学习设计的方法是类似的 • 都使用类似的设计模式和设计原则


软件工程


• 故障恢复 Fault recovery: 立即处理故障以减少破坏性 • 故障恢复策略:

– 撤销食物 Undoing transactions: manage a series of actions as a single transaction that are easily undone if a fault occurs midway through the transaction

– 检验点/回退 Checkpoint/rollback: software records a checkpoint of current state; rolls back to that point if system gets in trouble

– 备份 Backup: system automatically substitutes faulty unit with backup – 服务降级 Degraded service: returns to previous state, offers degraded version

of the service – 修正和继续 Correct and continue: detects the problem and treats the

symptoms – 报告 Report: system returns to its previous state and reports the problem to an

exception-handling unit


软件工程

5.5满足质量属性补充材料 5.6 安全设计的需要

• From 1986 to 1997, over 450 reports filed with the U.S. Food and Drug Administration (FDA) detailing software defects in medical devices, 24 of which led to death or injury – Numbers may be greater based on time to file report

• The FDA established a software forensics unit in 2004 after noticing that medical device makers were reporting more and more software-based recalls

• Software designers must see directly how their products will be used

• Then designers can build in preventative measures to ensure their products are not misused


软件工程

5.5满足质量属性健壮性 Robustness

• 系统是健壮性的，如果系统包含了…机制 – 适应环境 – 从环境中或者其他单元中的问题中恢复

• 互相怀疑 Mutual suspicion: 每个软件单元都假设其他软件单元中包含故障

• 健壮性策略和可靠性策略是不同的 • 恢复策略是类似的:

– 回退到检查点状态 Rollback to checkpoint state – 放弃事务 Abort a transaction – 初始化备份单元 Initiate a backup unit – 提供降级的服务 Provide reduced service – 处理症状后继续执行进程 Correct symptoms and continue processing – 触发一个异常 Trigger an exception


软件工程

5.5满足质量属性易使用性 Usability

• 易使用性(Usability) 反映了用户使用系统的容易程度 – 用户界面需要放置于自身的软件单元中 – 一些用户发起的命令需要体系结构的支持 – 一些系统发起的活动要求系统维护一个环境模型


软件工程

5.5满足质量属性商业目标 Business Goals

• Business Goals are quality attributes the system is expected to exhibit (e.g., minimizing the cost of development and time to market) – 购买与开发 Buy vs. Build

• Save development time, money • More reliable • Existing components create constraints; vulnerable to supplier

– 最初的开发成本和维护的成本 Initial development vs. maintenance costs • Save money by making system modifiable • Increased complexity may delay release; lose market to competitors

– 新的技术与已知的技术 New vs. known technologies • Acquiring expertise costs money, delays product release • Either learn how to use the new technology or hire new personnel • Eventually, we must develop the expertise ourselves


软件工程

5.6 协作设计

• 软件系统的设计往往是由开发人员组成的团队完成的 • 设计团队必须处理几个问题:

– Who is best suited to design each aspect of the system – How to document all aspects – How to coordinate and integrate the software units

• 在其文化和道德背景下看待小组的交互作用是很重要的 – Important to view group interaction in its cultural and ethical

contexts


软件工程

5.6协作设计补充材料 5.7 造成设计崩溃的原因

• 设计团队每个成员都必须知道造成设计崩溃的原因，并使用团队力量来解决它们

• 设计过程崩溃的主要类型: – Lack of specialized data schemas – Lack of meta-schema about the design process – Poor prioritization of issues – Difficulty in considering constraints – Difficulty in performing mental simulations – Difficulty in tracking and returning to subproblems – Difficulty in expanding or merging solutions


软件工程

5.6协作设计外包 Outsourcing

• 协作变得更加困难 • 协作小组可能遍布世界各地 • 分布式开发的4个阶段:

– Project performed at single site with on-site developers from foreign countries

– On-site analysts determine system requirements, which are in turn provided to off-site groups

– Off-site developers build generic products and components that are used worldwide

– Off-site developers build products that take advantage of their individual areas of expertise


软件工程

5.7 体系结构的评估和改进

• 设计是一个迭代的过程: – we propose design decisions, assess, make adjustments, and

propose more decisions • 对设计进行评估的技术:

– 测量设计质量 Measuring design quality – 故障数分析 fault-tree analysis – 安全性分析 Safety analysis – 权衡分析 Trade-off analysis – 成本效益分析 Cost-benefit analysis – 原型化 Prototyping


软件工程

5.7体系结构的评估和改进测量设计质量

• 度量标准正在制定，以评价设计质量 – Chidamber and Kemerer

• 用于面向对象设计的通用度量集

– Briand, Morasca, and Basili • 用于评估高层设计的度量，包括内聚度和耦合度

– Briand, Devanbu, and Melo • 在上述思想基础上，提出了测量耦合度的方法


软件工程

5.7体系结构的评估和改进故障树分析

• 一些…的技术 – 在设计过程中，识别可能的故障

• 故障树分析(Fault-tree analysis) 沿着设计逆向跟踪 – Trees then used to determine which faults to

correct/avoid/tolerate – 数据流图 Data-flow graph: 描述从一个加工向另一个加工传递数

据 – 控制流图 Control-flow graph: 描述在软件单元之间传输控制


软件工程



软件工程


• 一旦建立了故障树，就可以查找设计中的弱点 • 割集树(Cut-set tree) 揭示了哪些事件的组合可以引起失效

– 构造割集树的规则: • Assign the top node of the cut-set tree to match the logic gate at the top of the

fault tree. • Working from the top down, expand the cut-set tree as follows:

– Expand an or-gate node to have two children, one for each or-gate child – Expand an and-gate node to have a child composition node listing both of

the and-gate children – Expand a composition node by propagating the node to its children, but

expanding one of the gates listed in the node • Continue until all leaf nodes are basic events or composition nodes of

basic events


软件工程


• 一旦发现设计中的失效点:

– 改正错误 – 增加构件或条件以便预防 – 增加构件

– 检测故障和失效 – 从损害中恢复


软件工程

5.7体系结构的评估和改进安全性分析

• 进行安全性分析的6个步骤: – 软件特征化 Software characterization: review documentation for

understanding functionality of the system – 威胁分析 Threat analysis: look for threats (e.g., espionage, interception,

disruption) – 漏洞评估 Vulnerability assessment: includes failure to authenticate user or

use of cryptological algorithm that is easy to break – 风险可能性决策 Risk likelihood determination: must consider motivation,

ability of the threat to exploit, impact of the exploitation, and degree to which current controls can prevent

– 风险影响决策 Risk impact determination: business consequences – 风险缓解计划 Risk mitigation planning: planning to reduce likelihood and

consequences of most severe risks


软件工程

5.7体系结构的评估和改进权衡分析

• 通常有多种设计候选方案供考虑 – 作为专业人员，应该去研究这些设计候选项而不是简单实现第一个想到的设计

– 设计组中不同的成员提出竞争设计 – 需要一种基于度量的方法在设计候选项间进行比较


软件工程

5.7体系结构的评估和改进 One Specification, Many Designs

• One specification, many designs: 不同的设计可以解决同样的问题

• Shaw and Garlan present four different architectural designs to implement KWIC (Key Word in Context problem)

• shared data • abstract data type • implicit invocation • pipe and filter


软件工程


• 共享数据解决方案

• Four functional parts: input, circular shift, alphabetize, and output


软件工程


• 数据模块解决方案 • Modules form data

abstraction (hide data representation)


软件工程

• ADT 方案: Data are no longer centralized, stored, and shared, but the decomposition process is similar



软件工程


• 管道-过滤器方案: The sequence of processing is controlled by the sequence of filters


软件工程



软件工程


• 解决方案比较

Attribute

Shared Data

Data Abstraction

Implicit Invocation

Pipe and Filter

Easy to change Algorithm

- - + +

Easy to Change Data - + - - Easy to Add Functionality

+ - + +

Performance - - + + Efficient Data Rep + + + - Easy to Reuse - + - +


软件工程


• 解决方案带权重比较

Attribute

Priority

Shared data

Abstract data type

Implicit invocation

Pipe and filter

Easy to change algorithm

1 1 2 4 5

Easy to change data representation

4 1 5 2 1

Easy to change function

3 4 1 4 5

Good performance 3 5 4 2 2 Easy to reuse 5 1 4 2 5


软件工程


• Other attributes to consider – Modularity – Testability – Security – Ease of use – Ease of understanding – Ease of integration


软件工程

5.7体系结构的评估和改进成本效益分析

• Consider a proposal to improve KWIC performance because the number of KWIC indices have increased – Eliminate noise word indices? – Change representation of indices to bin of indices? – Increase server capacity?

• 成本效益分析(cost–benefit analysis)是一种…工具 – 广泛使用的 – 用来估计和比较:提议改变所带来的成本 vs 效益


软件工程

5.7体系结构的评估和改进成本效益分析

• 将经济效益和经济成本进行比较 – 成本往往是一次性的资金消耗 – 效益是贯穿始终的

• 投资回报率 Return on Investment (ROI) – ROI = Benefits/Cost

• 投资回收期 Payback period – 在累计的效益抵消实现时消耗的成本之前的时间长度


软件工程

5.7体系结构的评估和改进 Computing Benefits

• 价值随质量属性增长

• 改变带来的净值就是曲线以下，当前和改进之间的区域


软件工程

5.7体系结构的评估和改进 Prototyping 原型化

• 设计中一些问题可以通过使用原型化得到很好的解答 • 原型 Prototype: 一种可执行的系统模型，用来解答关于系统特定方

面的问题 • 抛弃型原型 Throw-away prototype: meant to be discarded • 快速原型化 Rapid prototyping: progressively refine the prototype

until it becomes the final system • 潜在的风险: the customer may believe the operational prototype is

the actual system and close to being finished


软件工程

5.8 文档化软件体系结构 • 系统体系结构在整个开发过程中有着重要地位，是…的基础:

– 设计 Design – 质量保证 Quality assurance – 工程管理 Project management

• SAD应该包含下面几个方面的信息: – 系统综述 System overview – 视图 Views – 软件单元 Software units – 分析数据和结果 Analysis data and results – 设计合理性 Design rationale – 定义、术语表、缩写词 Definitions, glossary, acronyms


软件工程

5.8文档化软件体系结构视图间的映射

• SAD中包含视图数目以及哪些视图，取决于： – 系统的结构 – 我们将要测量的质量属性

• 至少应该包含一个分解视图、一个执行视图 • 设计是一系列视图的集合；应该展示视图之间是如何联系起来的


软件工程

5.8文档化软件体系结构 Documenting Rationale 文档化设计合理性

• Document rationale: 概述关键问题以及做出的权衡 • 什么时候该为一个决策建立合理性文档:

– Significant time spent on decision – Decision is critical – Decision is counterintuitive – Costly to change decision


软件工程

5.9 体系结构设计评审

• 设计评审是工程实践中必不可少的一部分 • 两种方式评估SAD的质量 :

– 确认 Validation: 确认设计是否符合客户指定的所有需求 (i.e., is this the right system?)

– 验证 Verification: 保证设计是否遵循了良好的设计原则 (i.e., are we building the system right?)


软件工程

5.9体系结构设计评审 Validation 确认

• 参与评审的关键人员: – The analyst(s) who helped define the system requirements – The system architect(s) – The program designer(s) for this project – A system tester – A system maintainer – A moderator – A recorder – Other interested developers not otherwise involved in this project


软件工程

5.9体系结构设计评审 Verification 验证

• 判断设计是否遵循了良好的设计原则: – Is the architecture modular, well structured, and easy to understand? – Can we improve the structure and understandability of the architecture? – Is the architecture portable to other platforms? – Are aspects of the architecture reusable? – Does the architecture support ease of testing? – Does the architecture maximize performance, where appropriate? – Does the architecture incorporate appropriate techniques for handling

faults and preventing failures? – Can the architecture accommodate all of the expected design changes

and extensions that have been documented?


软件工程

5.9体系结构设计评审 Verification 验证

• 主动设计评审 Active design review: 两种方式一致 – 评审人员应用该设计文档的方式 – 开发人员在实践中使用最终文档的方式

• 被动设计评审Passive review process: 阅读文档，发现问题


软件工程

5.10 软件产品线

• 很多公司通过在相关产品系列中复用专门技术和软件资源而获得成功

• 设计和开发相关产品的共同策略是以一个共同产品线(product line)的元素复用为基础的

• 建立产品线的一个显著特征是把衍生产品集视为产品系列(product family)，在开始的时候就计划好同时开发它们

• 一个系列的共性会被描述成可复用资源的集合 (包括需求、设计、代码和测试用例), 存储在核心资产库(core asset base)中


软件工程

5.10软件产品线 Core Asset Base

• 资产核心库中的候选元素: – 需求 Requirements – 软件体系结构 Software architecture – 模型和分析结果 Models and analysis results – 软件单元 Software units – 测试 Testing – 项目计划 Project planning – 团队组织 Team organization


软件工程

5.10软件产品线战略范围

• 产品线不仅仅是以产品间的共性为基础的，而且还必须具有一套最佳的开发方式 – 首先，我们使用了战略化的商业计划来确定我们要创建的产品系

列，我们运用知识和良好的判断能力来预测市场趋势和对不同产品的需求

– 然后，划定计划范围(scope) ，这样我们就可以集中于那些有足够多的共性的产品，以确保以产品线方式进行开发

• 也就是说，开发（公共）产品线的代价肯定比我们希望衍生的系列产品节约所抵消的部分更多


软件工程

5.10软件产品线补充材料 5.8 生产线的生产力

• CelsiusTech AB, a Swedish naval defense contractor, motivated by desperation, transitioned from custom to product-line development. In 1985, the company, then Philips Elektronikindustier AB, was awarded two major contracts simultaneously, one for the Swedish Navy and one for the Danish Navy.

– senior managers questioned whether they would be able to meet the demands of both contracts, particularly the promised (and fixed) schedules and budgets, using the company’s current practices and technologies.

• Development of the product line and the first system were initiated at the same time; development of the second system started six months later. The two systems plus the product line were completed using roughly the same amount of time and staff that was needed previously for a single product. Subsequent products had shorter development timelines. On average, 70–80 percent of the seven systems’ software units were product-line units (re)used as is.


软件工程

5.10软件产品线产品线体系结构的优势

• A product lines promotes planned modifiability • Examples of product-line variability:

– 构件替换 Component replacements – 构件特化 Component specializations – 产品线参数 Product-line parameters – 体系结构扩展和收缩 Architecture extensions and

retractions


软件工程

5.10软件产品线补充材料 5.9 生成式的软件开发

• 生成式的软件开发(Generative software development) 是产品线开发的一种形式 – 产品根据规格说明自动生成

• “领域工程师”定义特定领域语言( domain-specific language，DSL) ；“应用工程师”使用它来指定需要建立的产品

• Lucent(朗讯) developed several product lines and generative tools for customizing different aspects of its 5ESS telephone switch


软件工程

5.10软件产品线产品线的演化

• 产品线成功的最重要因素是产品线的理念 – 公司最主要的关注点应该是产品线资产的开发和演化，而不是个别的产品

– 对产品线的改动是以提高衍生产品的能力为目标的

– 保持以前的产品仍能够兼容(Backwards capability)


软件工程

5.11 信息系统的例子 Piccadilly System

• What might be a suitable architecture for the Piccadilly systems? • 重要构件 • 一个信息库 • 能处理各种各样的信息查询

• 一个典型的信息系统的标准体系结构 • N层的客户-服务器结构


软件工程

5.12 实时系统的例子 Ariane-5 Failure

• Inquiry found that the Ariane program had a “culture...of only addressing random hardware failures” and assuming the software was correct

• Hardware failures are independent of one another • Software faults tend to be logical

– All redundant components will have the same faults • Redundancy in Ariane-5 is likely to recover only from

hardware failures


软件工程

5.13 本章对你的意义 • Systems need to be designed based on carefully expressed requirements • Design begins with a high-level architecture, where architectural decisions

are based not only on system functionality and required constraints but also on desirable attributes and the long-term intended use of the system (including product lines, reuse, and likely modification)

• Keep in mind several characteristics of good architecture as you go, including appropriate user interfaces, performance, modularity, security, and fault tolerance

• The goal is not to design the ideal software architecture for a system, because such an architecture might not even exist. Rather, the goal is to design an architecture that meets all of the customer’s requirements while staying within the cost and schedule constraints

shari l. pfleeger joanne m. atlee -...

Documents