空间信息移动服务2 软件体系结构

移动空间信息服务应用
设计与开发
主讲人：熊庆文
工作邮箱： xiong_yx@126.com
本教程的主要内容
 软件体系结构的概念
 移动空间信息服务应用系统体系结构
 系统服务器端开发平台、应用设计
 系统移动端开发平台、应用设计
 研究开发案例
 上机实习
 课程设计：一个完整的应用系统的设计实现
武汉大学国际软件学院空间信息与数字工程研究中心
软件体系结构参考书
 软件构架实践（影印版 · 第 2 版），
– Len Bass,Paul Clements,Rick Kazman
– 卡内基 · 梅隆大学软件工程丛书
– 清华大学出版社
 软件构架编档（影印版）
– Paul Clements,Felix Bachmann,Len Bass
– 卡内基 · 梅隆大学软件工程丛书
 软件体系结构（第 2 版）
– 张友生等

移动开发参考书
 J2ME 平台
– http://club.book.csdn.net/people/mylist668
.html
 Windows Mobile 平台
.html
 LINUX 平台
.html
 Symbian 平台
– http://club.book.csdn.net/book/23966.html
 BREW 平台
其它参考书籍
 空间信息处理类
– 空间数据结构
– 空间数据库
 基于 Web 的应用开发
– Java
– .net
 主流空间信息处理平台产品操作使用
– Esri
– Mapinfo
 数据库及 SQL
 各类标记语言及脚本语言
– Html
– Xml
– Gml
– Wml
在线资源
 课程信息
– http://c4se.51.net/mobile/index.htm
 体系结构
– http://www.sei.cmu.edu/architecture/
– http://www.uml.org.cn/zjjs/zjjs.asp
－……
 移动开发
– http://mobile.csdn.net/
– http://www.j2medev.com/
– ……
课程安排
周次课次内容课次内容
6 1 上课 2 上课
7 1 上课 2 上课
8 1 上课 2 上课
9 1 上课 2 上机实习
13 1 课程设计 2 课程设计
14 1 课程设计课程设计
2 武汉大学国际软件学院空间信息与数字工程研究中心
课程安排
周数内容周数内容
1 上课 10 上机实习
2 上课 11 上课
4 上机实习 13 上课
6 上机实习 15 上课
7 上课 16~ 集中实习
8 上机实习
9 上课武汉大学国际软件学院空间信息与数字工程研究中心
1. 软件体系结构
 1.1 简介
 1.2 SA 与 SE
 1.3 体系结构的风格
 1.4 体系结构描述
1.1 软件体系结构简介
你可能早就知道的一些 —
—
“软件体系结构 ”
 C/S
 3-tier/n-tier
 P2P
 分布式
 ……
Architecture-“ 建筑体系
结构”
Architecture-“ 建筑体系
结构”
构建一个小狗屋
可以由一个人制造
的需求：
最小模型
简单的过程
简单的工具
构造一栋房屋
由一个团体建设，并且需要更高的效率、更精确的时间限制
需求
模型
良好定义的过程
功能强大的工具武汉大学国际软件学院空间信息与数字工程研究中心
构建一个高层建筑
早期的结构
过程
- 有限的
理论知识
现代的结构
进步
- 先进的原材料
- 先进的分析
范围
- Pantheon 的五倍范围
- Cheops 的 3 倍高度
房屋建模
民间风格的结构
过程
 青铜时代 / 古埃及 (Imhotep) -- 对早期成就的模仿
从失败中学习
 古希腊 / 罗马 (Vitruvius) - 对其他影响因素的综合
- 试验
 东罗马 / 罗马式
 哥特式
 怪异的 ( 米开朗基罗 , Palladio)
 巴洛克
 工程 /Rational/National/Romantic
 艺术 noveau
 现代风格 (Wright, LeCorbusier)
民用建筑结构的种类 ( 功能
划分 )
 社会
– 房屋 , 、旗子和单元房、花园、教育、旅店和宗
教
 商务
– 商店和仓库、饭店、旅馆、办公楼、银行、机场
 工业
– 工业建筑、图书馆、农场建筑
 休闲
– 运动、剧场、电影院、博物馆
Brand, How Buildings Learn
剪切层的改变
空间计划
服务
填充
结构
表面
场地
软件中的影响因素
功能
成本兼容性
容量失败安全
可用性容错度
性能吞吐量
技术混合恢复能力
20 年之后的挑战不是速度、成本和性能，而是复杂度的问题了。
Bill Raduchel, Sun 微系统公司策略执行总裁
复杂度是我们的敌人，是我们的目标，我们要消灭它。
Jan 武汉大学国际软件学院空间信息与数字工程研究中心
Baan
Software Architecture
的定义
 “There is no standard,
universally-accepted definition of
the term, for software
architecture is a field in its
infancy, although its roots run
deep in software engineering. ”
对 SA 的定义
 Booch, Rumbaugh, and Jacobson, 1999:
An architecture is the set of significant
decisions about the organization of a
software system, the selection of the
structural elements and their interfaces by
which the system is composed, together with
their behavior as specified in the
collaborations among those elements, the
composition of these structural and
behavioral elements into progressively larger
subsystems, and the architectural style that
guides this organization---these elements
and their interfaces, their collaborations, and
their composition
对 SA 的定义
 Perry and Wolf, 1992:
– A set of architectural (or, if you will,
design) elements that have a
particular form.
– distinguish between processing
elements, data elements, and
connecting elements, and this
taxonomy （分类） by and large
persists through most other
definitions and approaches.
对 SA 的定义
 Garlan and Shaw, 1993:
...beyond the algorithms and data structures

of the computation; designing and specifying
the overall system structure emerges as a
new kind of problem. Structural issues
include gross organization and global control
structure; protocols for communication,
synchronization, and data access;
assignment of functionality to design
elements; physical distribution; composition
of design elements; scaling( 确定规模 ) and
performance; and selection among design
alternatives ( 备选方案 )." 武汉大学国际软件学院空间信息与数字工程研究中心
SA 的定义
 后人精简 Garlan and Shaw 的定义为
：
– 体系结构 = 组件 + 连接件 + 约束
– Architecture = Components +
Connectors + Constrains
SA 的定义
 软件体系结构定义了软件的局部和总体计算部件的构
成，以及这些部件之间的相互作用关系。
– 部件包括诸如服务器、客户、数据库、过滤器、程序包、过
程、子程序等一切软件的组成成份。
– 相互作用关系包括诸如过程调用、共享变量访问、消息传递
等。
– 相互作用也包括具有十分复杂的语义和构成关系，诸如客户
/ 服务器的访问协议、数据库的访问协议网络的传输协议、
异步事件的映射等。
 除了描述系统的构成和结构关系外，在系统的功能需
求方面，体系结构还表达了系统需求和构成之间的对
应关系。
SA 的重要性
 最早指出 SA 的重要性的
是大师 Edsger
Dijkstra(1930-2002)
“..the larger the

project, the more
essential the
structuring!”(1968)
程序 = ？
 程序 = 算法 + 数据结构
（ 1960’s ）
 程序 = 子程序 + 子程序
（ 1970’s ）
 对象 = 算法 + 数据结构
程序 = 对象 + 对象（ 1980’s ）
 程序 = 组件 + 连接件（ 1990’s ）
SA 之重要
 好的软件体系结构，
是好的软件的必要条件。
 “Good architectural design has
always been a major factor in
determining the success of a
software system.”
SA 在 SE 中的地位
 Guide to the Software Engineering Body of Knowledge (SWEBOK)

from http://www.swebok.org/ © IEEE
Software
Structure
and
Architectur
e
SA 的发展历程
SA 发展
 1980’s
– 使用非正式的框图
– 依靠专家的特定经验
– 不规范、多样地使用体系结构模式和风格
 1990’s
– 认识到了体系结构的价值
– 开发过程中要求体系结构文档，并开始体系结构评审
– 产品化、商业化的体系结构标准和组件集成框架开始出现
– 规范化体系结构设计中的词汇、符号和工具
– 软件体系结构的书籍和课程
 2000’s
– ？
好的体系结构
 与大多数好的设计一样
– 是一系列相容的原理和技术的产物，在项
目的各个阶段保持一致
– 在各种变化面前表现出弹性
– 在产品的整个生命周期中充当向导
– 重用成熟的工程知识
DeRemer 和 Kron 说…
(1976)
 “Structuring a large collection of
modules to form a “system” is an
essentially distinct( 本质区别 ) and
different intellectual activity from that
of constructing the individual
modules.”
 “Correspondingly, we believe that
essentially distinct and different
languages should be used for the two
activities.”
Module Interconnection
Languages (MIL, 模块互连
语言 )
 DeRemer 和 Kron 发明了 MIL
 MIL 提供了描述模块之间的相互关系以
及模块如何调用的静态方法。
– 静态是指模块之间的互联是通过某些隐式
的约定，如过程调用和数据共享。
– 使得模块互连语言有很大的局限性，通常
对于特定的程序开发语言，必须构造一个
特定的 MIL （例如： Ada 的 MIL ）
– 也就是说， MIL 是基于程序开发语言的。
1.2 SA 与 SE
SA 对 SE 的贡献
 体现在以下几个方面
– 开发团队的组织结构
– 捕获需求
– 设计方案的选择
– 分析和描述复杂系统的高层属性
– 人员交流
– 技术进步
– ……
开发团队的组织结构
 按体系结构设计出的组件，划分开发小
组
 构建新的类似系统时，每个小组贡献自
己的组件（复用）
捕获需求
 通过对相似系统的总结、吸收，更利于
理解新的相似系统的需求
– 引导用户是否应具备什么功能
 用户在旧系统基础上提出新需求
设计方案的选择
 有众多已有体系结构供参考
 通过对体系结构的度量，可知哪种体系
结构最有效
分析和描述复杂系统的高层属
性
方便人员交流
 知道了采用的体系结构，也就知道了此
系统有何优缺点
 对体系结构的命名，使交流变得简单
– 否则需要描述好久，才能使对方明白……
技术进步
 每个新的体系结构的诞生，都给技术的
进步带来深远影响
– WWW
– 三层结构
– CORBA
– J2EE
– .NET
SE 的目标是什么？
软件质量
 运行时质量
 非运行时质量（？？？）
 商业质量（？？？）
 体系结构质量
通过观察可以得知的质量
 它是否在做你所期望的事情？
 它用起来方便吗？
 计算结果正确吗？
 算了多久？
 非法用户能侵入它吗？
 它多久崩溃或者停止工作一次？
通过观察不能得知的质量
 这个系统开发了多久？
 被测试了多久？
 被集成了多久？
 它的成本是多少？
 很容易修改吗？
软件质量
 了解了一个方面的质量，并不能对你了解其
他方面的质量有多大帮助
 但是，如果改变结构从而提高一个质量，经
常会影响其它质量
 体系结构的选择极大地影响软件质量，但并
不能影响所有的质量
 体系结构只为获得某个质量创造条件，但并
不能保证肯定获得
影响软件质量的因素
 Correctness  Modifiability
Functionality  Portability
 Performance  Reusability
 Security  Integrability
 Robustness  Testability
Availability  Compatibility
 Usability  Economy
Ease of use
Correctness/Functionality
功能正确
定义：做该做的事情，并且作得对
 难的是有的时候不知道什么是该做的
 软件只能被证明有错，不能被证明无错
 正确性与体系结构无关
– 两个同样功能的软件体系结构必须相同吗
？
Performance
性能
定义：系统的响应时间，硬件资源的占用
率
 “Make it right before you make it

fast”
 Architect 的手段：
– 分而制之
– 监测与调节
– 简单的资源申请与释放机制武汉大学国际软件学院空间信息与数字工程研究中心
Security
安全
定义：在对合法用户提供服务的同时，阻止
未授权用户的使用企图。
– 入侵监测
– 防火墙
– 加密与解密
– 提供最少的入口
– 安全核心和外壳
Robustness/Availabilit
y
鲁棒性、可用性、健壮性
定义：能长时间正确运行并快速从错误
状态恢复到正确状态
 没有绝对的健壮！
Robustness/Availabilit
y
鲁棒性、可用性、健壮性
– 广泛适用的错误恢复策略
– 提防不可靠的传送
– 冗余关键部件和通讯线路
– 现场切换能力
– 监测活跃状态和错误报告
– 错误产生、捕获和传播的模板
– 快速恢复或启动策略
Usability/Ease of use
易用性
定义：最终用户容易使用和学习
 Don’t pretend you know the user; you

don’t.
– 仿照现有的工具和环境
– 统一的界面外观和工具
– 统一风格的帮助
– 定制？
Modifiability
适应性
定义：系统很容易被修改从而适应新的
需求或采用新的算法、数据结构的能力
 改一个组件比改多个组件要容易
 组件由体系结构定义，所以体系结构对
此影响很大
Modifiability
适应性
– 稳定的功能分解与分配
– 少量使用模式
– 信息隐藏和抽象
– 分层
– 退耦：去除或尽量降低耦合性，否则牵一
发动全身
Portability
移植性
定义：软件可以很简单地在平台间移植
– 为平台 / 网络独立分层（如 java vm ）
– 建立接口标准（如 OSI ，开放系统互联）
Reusability
重用性
定义：在新系统中应用已有的组件
– 规则和小型的模式
– 建立应用框架
– 建立产品线体系结构
Integrability
集成性
定义：让分别开发的组件在一起正确的工作
– 最小化接口的复杂度
– 限制交互机制和协议的数量
– 建立产品线体系结构
– 统一的命名规范
– 命名服务
Testability
可测性
定义：让软件容易被证明是错的
– 自检、捕获、回放、故障注入和报告
– 一致的错误处理方式
Compatibility
兼容性
定义：易于把软件元素和其他软件结合
 文件格式、数据结构、用户界面
– 中间件
Economy
经济效益
定义：开发成本、开发时间和对市场的适应
能力
– 正确的选择体系结构
– 组件重用
– Modifiability （可以修改升级而不是重新构建）
– 中间件
关于质量的教训
 先对要达到的质量做好计划，把它们设
计到体系结构中去
 理解各种体系结构的质量表现很重要，
注意折衷
 控制好实现环节，不要让体系结构的贡
献被糟糕的实现消灭
怎样提高质量？
我们能做的是，使体系结构
 易于理解
 可度量（建立一些评价指标）
 可复用
 可文档化
 易于交流和执行
1.3 Architectural
Styles
软件体系结构的风格
 1.3.1数据流风格
 1.3.2过程调用体系结构
 1.3.3事件驱动体系结构
 1.3.4信息共享体系结构
 1.3.5其它体系结构
Styles - Moving from
Qualities to Architectures
Architectural styles help software
engineers to reason about
architectural qualities.
体系结构风格帮助软件工程师
推断软件体系结构的质量
Styles -Moving from
Qualities to
Architectures
 A style
– describes a class of architectures
描述一类体系结构
– is found repeatedly in practice
在实践中被多次设计、应用
– is a package of design decisions
是若干设计思想的综合
– has known properties that permit reuse
具有已经被熟知的特性，并且可以复用
Architectural Styles
 A style is determined (described) by
– a set of component types (e.g., data
repository, process, object)
一组组件类型（例如：数据存储，过程，对象）
– a set of connector types/interaction
mechanisms (e.g., subroutine call, event,
pipe)
一组连接件类型 / 交互机制（例如：过程调用，
事件，管道）
– a topological layout of these components
这些组件的拓扑分布
 A style is determined (described) by
– a set of constraints on topology and behavior
(e.g., a data repository is not allowed to
change stored values, pipelines are acyclic)
一组对拓扑和行为的约束，如：数据容器不能自己改
变数据，管道不能是循环的
– an informal description of the costs and
benefits of the style, (e.g.: “Use the pipe and
filter style when reuse is desired and
performance is not a top priority)
一些对风格的成本和益处的非正式的描述，如：如果
你需要重用性并且性能不是很重要，那么可以使用管
道风格武汉大学国际软件学院空间信息与数字工程研究中心
Garlan and Shaw compiled a catalog of architectural
styles in 1995. Others, such as Buschmann, have
augmented this.
There is no complete list.

没有完备的列表
There is no unique, non-overlapping list.

没有无重叠的列表
Styles overlap. 风格是彼此重叠的
Systems exhibit multiple styles at once.

一个系统通常表现出多种风格
Types of Architectural
Styles
Notes about
 When we introduce a new style, we will typically
first examine its “pure” form.
– pure architectural style are rarely found in practice
其实，纯粹的体系风格在实际中很难遇到
– systems in practice
 regularly deviate from the academic definitions of these
systems. 循规蹈矩地背离了对这些系统的学术定义
 typically feature many architectural styles simultaneously
典型地，融合很多体系风格的特色
– as an architect you must understand the “pure” styles to
understand the strength and weaknesses of the style as
well as the consequences of deviating from the style
作为一个架构师，必须理解“纯”的风格。理解它的优点与缺陷
，也要理解偏离此种风格之后会带来什么结果
1.3.1 Data Flow Style
数据流风格
 A data flow system is one in which
– the availability of data controls the computation
由数据控制计算
– the structure of the design is dominated by orderly
motion of data from process to process
系统结构由数据在处理之间的有序移动决定
– the pattern of data flow is explicit
数据流系统的结构是显而易见的
 In a pure data flow system, there is no other
interaction between processes
在纯数据流系统中，处理之间除了数据交换，没有任
何其他的交互 ( 如调用关系 )
The Data Flow Style
 There are variety of variations on
this general theme: 一些考虑因素
– how control is exerted (e.g., push
versus pull)
如何施加控制（比如：推还是拉）
– degree of concurrency between
processes
并行的程度
– Topology
拓扑结构
Data Flow Styles
 Components: Data Flow Components
– Interfaces are input ports and output
ports
组件接口是输入端口和输出端口
– Input ports read data; output ports
write data
从输入端口读数据，向输出端口写数据
– Computational model: read data from
input ports, compute, write data to
output ports
计算模型：从入口读数，计算，然后写到出口
Data Flow Styles
 Connectors: Data Streams
– Uni-directional （单向）
 usually asynchronous, buffered （通常是异步的，
有缓冲）
– Interfaces are reader and writer roles
接口是 reader 和 writer
– 计算模型 : 把数据从 writer 转向 reader
 Systems
– Arbitrary graphs （任意拓扑结构）
– Computational model: functional
composition （计算模型 : 功能组合）
Patterns of Data Flow in
Systems
In general, data can flow
in arbitrary patterns （一
般情况，数据的流向无序）
Often we are primarily
interested in nearly
linear data flow
systems （我们主要研究近
似线性数据流）
or in very simple, highly
constrained cyclic
structures （或者是在限度
内的循环数据流）使问题得
到简化
Control Flow vs. Data
Flow
 Control Flow (typical case in
procedural systems)
– Dominant question is how locus of control
moves through the program
主要问题是控制点怎样在程序或系统之间移动
– Data may accompany the control but is
not the driving force
数据可能跟着控制走，但是并不起推动系统运转
的作用
– Primary reasoning is about order of
computation
关注的核心是计算顺序
Control Flow vs. Data
Flow
 Data Flow
– Dominant question is how data moves
through a collection of (atomic)
computations
主要问题是数据怎样在运算单元之间流动
– As data moves, control is “activated”
数据到了，控制（计算）单元便开始工作
– We reason about data availability,
transformations, latency,…
我们关心数据是否可用，转换，等待时间……
Three Examples of
Data Flow
 Batch Sequential （批处理）
 Pipe-and-Filter （管道）
 Process Control （控制）
Batch Sequential
Pattern
Characteristics of Batch
Sequential Systems
 Processing steps are independent programs
每个处理步骤是一个独立的程序
 Each step runs to completion before next
step starts
每一步必须在前一步结束后才能开始
 Data transmitted as a whole between steps
数据必须是完整的，以整体的方式传递
 Typical applications:
– classical data processing
– program compilation/computer aided software
engineering
Characteristics of Batch
Sequential Systems
 Architectural Heuristics( 体系结构
设计要点 )
– components (processing steps) are
independent programs
– connectors are some type of media
 traditionally magnetic tape
– each step runs to completion before
the next step begins
Example: Batch Sequential
Systems
 Compilers
– early compilers began as essentially
batch sequential systems
 lexical analysis, parsing, semantic
analysis, code generation
– initially a mechanism to turn higher
level source code into object code
Compilers
源程序
词法分析
单词
语法分析
表语法单位出
格错
管中间代码生成处
理中间代码理
优化
优化后的
中间代码
目标代码生成
目标程序
编译程序的结构与工作过程
Example: Batch Sequential
Systems
 Computer Aided Software Engineering
– CASE tools initially provided an environment to
write and compile source code into object code
 compiler, library, linker, make, into an
integrated tool
– early tools were independent programs
– later tools shared only files( 文件方式共享 )
 common formats, simple sharing
mechanisms, scripts
 eventually tools grew to include design,
documentation, configuration control, and
even automatic code generation
Three Examples of
Data Flow
Pipe-and-Filter
Pipes and Filters
 Role of (“pure”) filters
– reads streams of data as input, produces streams
of data as output
 traditionally byte-oriented
 performs stream-to-stream transformations
– enrich data by computation and adding information
通过计算和增加信息丰富数据
– refine by distilling data or removing irrelevant data
通过浓缩和删除精炼数据
– transform data by changing its representation
通过改变记录方式转化数据
Pipes and Filters
– incrementally transform data from the
source to the sink （递增地转化数据）
 data is processed as it arrives, not gathered
then processed
数据到来时便被处理，不是收集然后处理（偶有例外）
– filters are independent entities( 独立实体 )
 no context in processing streams 不需要上下文条
件
 no state preservation between instantiations 不
保存状态
 no knowledge of upstream/downstream filters
 the correctness of the output should not depend
upon the order in which the pipes are connected
in a pipe-and-filter network
过滤器的先后顺序不影响输出的结果
Pipe-and-Filter
 Role of (“pure”) pipes
– move data from a filter output to a filter input (e.g.,
to a device or file)
– data moves in one direction, upstream flow control
is allowed
– pipes form data transmission graph
 Overall Operation
– system action is mediated by data delivery
数据传送引起系统动作
– pipe-and-filter systems run until
 no more data is available and
 no more computations possible
“Pipes” and “Filters”
in unix
 unix processes that transform stdin to stdout are
generally called filters
– but when they consume all the input before starting the
output, they violate the filter assumption
– E.g., ,sort( 收集完所有数据，排好序之后才输出 )
 unix pipes can treat files as well as filters as data
sources and sinks
– but files are passive, so you can’t make arbitrary
combinations
 unix assumes that the pipes carry ASCII character
streams
– the good news: anything can connect to anything else
– the bad news: everything must be encoded in ASCII,
then shipped, then decoded
“Pipes” and “Filters”
in unix
example
 DOS pipe command
– Dir | more > filelist.txt
Issue: Data Pulling and
Data Pushing
 Question: what is the force that makes the
data flow?
 Three choices, all with force emanating( 发出
) from filters
– Push( 推送 ): data source pushes data in
downstream direction
– Pull( 抽取 ): data sink pulls data from upstream
direction
– push/pull: a filter is actively pulling from upstream,
computing, and pushing downstream
– passive: don’t do either, act as a sink for data
 Combinations may be complex. If more than
one filter is pushing/pulling, synchronization
is needed 武汉大学国际软件学院空间信息与数字工程研究中心
Batch Sequential vs Pipe &
Filter
Batch Sequential vs Pipe
& Filter (UNIX)
Both
Decompose task into fixed
sequence of computations Interact
only through data passed from one
to another
把任务分解成为一系列固定顺序的计算单
元 ( 组件 ) ，组件间只通过数据传递交互
Batch Sequential vs Pipe
& Filter (UNIX)
Batch Pipe/Filter
Sequential
Total 完全处理 Incremental 部分的、增量
处理
High latency 等待时间 Results start immediately
长 (real-time is hard)
几乎无法实时处理
No concurrency Feedback loops possible
Non-interactive Ofteninteractive,
awkwardly
A Variant on Data Flow
 Issue: in some systems,
– Data flows slowly through the
system
– Data does not remain strictly in
order 数据的次序会有变化
Summary: Guidance for
Selecting a Data Flow
Style
 task is dominated by the availability of
data
任务由数据主导，数据流到启动任务
 data can be moved predictably from
process to process
事先知道数据的确切流向
 there may be a performance penalty in
data flow styles, however this depends on
many factors 数据的流动带来性能损耗，
 （过滤器数量，循环次数，有无并行处理等）
Selecting a Data Flow
Style
 pipe-and-filter architectures are good
choices for many data flow
applications because
– they permit reuse and reconfiguration of
filters
– generally easy to reason about 易于设计
– reduce system testing
– may allow incremental( 增量的 ) AND
parallel processing
Three Examples of
Data Flow
Open Loop Control( 开
环控制 )
Closed Loop Control( 闭
环控制 )
Closed Loop Process
Control Architecture
Example - Thermostatic
Control Architecture
Selecting a Control Style
 when Consider a Closed Loop Control
Architecture ?
– the task involves continuous action, behavior,
changing state
任务包含连续的动作、行为、状态的改变
– when open loop control systems are inadequate
开环结构不适合
 safety 、 function 、 ease of use 、 reduction of
manpower
– software can be reasonably be embedded in a
physical system
 writing software for these systems often requires
domain expertise beyond software
写此类软件通常都需要相当的领域知识
1.3.2 Call/Return
Systems
过程调用体系结构风格
 Main Program and Subroutine
 Data Abstraction or Object-Oriented
 Stylistic Variations
History
 Main program and subroutines
– Decomposition into processing steps with
single-threaded control
单线程控制，划分为若干处理步骤
 Functional modules
– Aggregation of processing steps into
modules
把处理步骤集成到多个模块内
 Abstract Data Types
– Bundle operations and data, hide
representations and other secrets
操作和数据捆绑在一起，隐藏实现和其他秘密武汉大学国际软件学院空间信息与数字工程研究中心
History
 Objects
– Methods (bound dynamically), polymorphism
(subtypes), reuse (through inheritance)
方法（动态绑定），多态（子类），重用（继承）
 OO Architectures
– Objects as separate processes/threads
对象活动于不同的进程 / 线程
– Client-server, tiered styles 分层风格
 Components
– Multiple interfaces, binary compatibility, advanced
middleware （多个接口，二进制兼容，高级中间件）
Main Program and
Subroutine
Main Program and
Subroutine
 Hierarchical decomposition:
逐步分解
– Based on definition-use relationship
基于定义—使用关系
– Uses procedure call as interaction
mechanism
用过程调用作为交互机制
 Single thread of control:
单线程控制
– Supported directly by programming
languages 武汉大学国际软件学院空间信息与数字工程研究中心
Main Program and
Subroutine
 Hierarchical reasoning 我们可以知道 :
– Correctness of a subroutine depends on
the correctness of the subroutines it calls
子程序的正确性取决于被它调用的子程序的正确
性
 Subsystem structure implicit:
子系统的结构不清晰
– Subroutines typically aggregated into
modules
子程序通常合成为模块
Main Program and
Subroutine
Criteria for
Modularization
 What is a module?
– Common view: a piece of code.
Too limited.
– Compilation unit, including
related declarations and
interface （编译单元，包含相关的
声明和接口）
– Parnas: a unit of work. （工作单
元）
 Key issue: what criteria to use for
modularization 武汉大学国际软件学院空间信息与数字工程研究中心
Criteria for
Modularization
 Why modularize a system, anyway?
– Management: Partition the overall
development effort
易于管理 : 将整体开发工作分成若干部分
 divide and conquer ( 分而治之 )
– Evolution: Decouple parts of a system so
that changes to one part are isolated from
changes to other parts
进行改进：降低模块间的耦合度，使改变一个模
块不会影响其他
– Understanding: Permit system to be
understood as composition of mind-sized
chunks
易于理解：系统可以被理解成若干个易于理解的武汉大学国际软件学院空间信息与数字工程研究中心
模块的组合
Modularization
Problems
 Access to internal representation:
– Vulnerability 弱点 :
 Visible representations can be manipulated in
unexpected, undesired, and dangerous ways
– Nonlocality 非定域性 , 位置相关性 :
 If the way something is used depends on its
implementation, you must find all uses to
change it (e.g. Y2K)
 Forced distribution of knowledge:
– Non-uniform referents:
 Syntax may reveal structure (If you export a
data structure, how does its user iterate through
it?)
Modularization
Problems
 Coupling 耦合 :
– Instance dependence: When
multiple instances of a given
structure are active, they must
remain independent
 Families of definitions ( 众说纷纭 ) :
– Dynamic binding: If shared
definitions involve type variants,
function variants must be chosen at
run-time 武汉大学国际软件学院空间信息与数字工程研究中心
Module Decomposition
 Parnas
– Hide secrets. OK, what’s a “secret”?
 Representation of data
 Properties of a device, other than required
properties
 Mechanisms that support policies 算法的实现机制
– Try to localize future change( 尽量找出可能
变化 )
 Hide system details likely to change
independently
把可能改变的系统细节分别隐藏
 Expose in interfaces assumptions unlikely to
change
把改变的可能不大的放到接口当中 ( 通过接口暴露 )
Example: Key Word In
Context (KWIC)
 Problem Description:
– 索引系统接受一些行，每行有若干字，每个字由
若干字符组成
– 每行都可以循环移位。重复地把第一个字删除，
然后接到行末
– 把所有行的各种移位情况按照字母表顺序输出
 请你来设计，准备采用什么体系结构风格？
Key Word In Context
(KWIC)
 Inputs: Sequence of lines
– Pipes and Filters
– Architectures for Software Systems
 Outputs: Sequence of lines, circularly
shifted( 循环移位 ) and alphabetized
– and Filters Pipes
– Architectures for Software Systems
– Filters Pipes and
– for Software Systems Architectures
– Pipes and Filters
– Software Systems Architectures for
– Systems Architectures for Software
Design Considerations
 Change in Algorithm
– Eg., batch vs incremental
 Change in Data Representation
– Eg., line storage, explicit vs implicit shifts
 Change in Function
– Eg., eliminate lines starting with trivial words
 Performance
– Eg., space and time
 Reuse
– Eg., sorting
Solution 1
 Decompose the overall processing into
a sequence of processing steps. 分解
– Read lines; Make shifts; Alphabetize; Print
results
 Copy data in modules
数据在每个模块内拷贝
 Determine the representation of data
between neighbors.
相邻模块间约定好数据格式
– Usually use the same representation of
data for all modules
通常完全采用相同的数据格式，也最好这样做武汉大学国际软件学院空间信息与数字工程研究中心
Solution 1 ：
Modularization
 Module 1 ： Input
– Read data lines and pass to the next module
按行读取数据，传递给下一模块
 Module 2 ： Circular Shift
– The first line’s coming make it work
第一行数据到来后开始运作
– Transmit the old and new lines to the next
把原始数据行，和新的移位后的行输出给下一模块
 Module 3 ： Alphabetize
– Collect data lines, buffer. All done, begin to work
接收行数据，缓存。当数据都到达后，开始排序
– Finish, output results
排序完毕，输出结果
Solution 1 ：
Modularization
 Module 4 ： Output
– Called after Alphabetization
排序后被调用
– Read sorted data lines, print
formatted output
读取排序生成的数据，逐行格式化输出
Architecture of
Solution 1
Properties of Solution
1
 Concurrent partly
部分并行处理
 Use lots of memory
空间消耗很大
 Every modules should know the
representation of data
每个模块都必须知道输入和输出的数据
格式
Solution 2
 Decompose the overall processing into
a sequence of processing steps.
– Read lines; Make shifts; Alphabetize; Print
results
 Each step transforms the data
completely.
每一步完全转换数据
 Intermediate data stored in shared
memory.
– Arrays of characters with indexes
带索引的字符数组
Solution 2 ：
Modularization
 Module 1: Input
– Reads data lines and stores them in
“core”.
– Storage format: 4 chars/machine word;
array of pointers to start of each line.
 Module 2: Circular Shift
– Called after Input is done.
– Reads line storage to produce new array of
pairs: (index of 1st char of each circular
shift, index of original line)
 Module 3: Alphabetize
– Called after Circular Shift.
– Reads the two arrays and produces new
index.
Solution 2 ：
Modularization
 Module 4: Output
– Called after alphabetization and prints
nicely formatted output of shifts
– Reads arrays produced by Modules 1 & 3
 Module 5: Master Control
– Handles sequencing of other modules
– Handles errors
Architecture of
Solution 2
2
 Batch sequential processing.
 Uses shared data to get good performance.
用共享数据获得性能
 Processing phases handled by control
module.
– So has some characteristics of main program –
subroutine organization.
– Depends critically on single thread of control.
 Shared data structures exposed as inter-
module knowledge.
共享数据的结构是所有模块必须知道的
– Design of these structures must be worked out
before work can begin on those modules.
数据结构的设计必须在其他模块设计开始之前进行
Solution 3
 Maintain same flow of control, but
 Organize solution around set of abstract data
type managers( 管理者，也可以叫做 objects) for :
– initial lines
– shifted lines
– alphabetized lines
 Each manager:
– handles (and hides) the representation of the
data
– provides a procedural interface for accessing
the data
Solution 3:
Modularization
 Module 1: Line storage
– Manages lines and characters; procedural
interface
– Storage format: not specified at this point
 Module 2: Input
– Reads lines of data and stores using
“Characters” ADT
 Module 3: Circular Shift
– Provides access functions to characters in
circular shifts
– Requires “setup” as initialization after Input is
done 武汉大学国际软件学院空间信息与数字工程研究中心
Solution 3:
Modularization
 Module 4: Alphabetize
– Provides index of circular shift
– “Alph” called to initialize after
Circular Shift
 Module 5: Output
– Prints formatted output of shifted
lines
 Module 6: Master Control
– Handles sequencing of other
Architecture of
Solution 3
3
 Module interfaces are abstract
– hide data representations
 could be array + indices, as before
 or lines could be stored explicitly
– hide internal algorithm used to process that

data
 could be lazy or eager evaluation 外部见不到
具体算法
– require users to follow a protocol( 协议 / 过程 )
for correct use
 initialization, error handling
3
 Allows work to begin on modules
before data representations are
designed.
 Could result in same executable
code as solution 2.
Comparisons - 1
 Change in Algorithm
– Solution 1: permits alternatives
– Solution 2: batch algorithm hard-wired( 固
连？依赖算法 )
– Solution 3: permits alternatives
 Change in Data Representation
– Solution 1: data formats are common
among many modules or two modules 公开
– Solution 2: data formats are common
among many modules 公开
– Solution 3: data formats are hidden
Comparisons - 2
 Change in Function
– Solution 1: easy if adding a new filter
– Solution 2: easy if adding a new phase of
processing
– Solution 3: modularization doesn’t give
particular help. But we can use
inheritance. 通过继承来添加功能
Comparisons - 3
 Performance
– Solution 1: Bad in space and good in speed
存在数据副本、并行处理
– Solution 2: Good
– Solution 3: Probably not as good, but
might be
Comparisons - 4
 Reuse
– Solution 1: Poor since tied to
particular data formats 都依赖于数据
结构
– Solution 2: Poor since tied to
particular data formats
– Solution 3: Better
KWIC ： Summary
This example teach us …
…
 For some quality attributes (space/time
performance, change of functional flow)
shared memory can be a good architecture
 For other quality attributes (reuse, general
modifiability, portability) ADT solution is
better
 The ADT solution also permits a divide-and-
conquer approach ( 分而治之 ) to software
development
– in terms of allocation of work 便于工作分配
– in terms of cognitive effort 便于认识待开发的系统
 This thinking leads to object architectures.
Encapsulation/Informatio
n Hiding
 Parnas ： Hide secrets (not just
representations)
 Booch: Object’s behavior is
characterized by actions that it
suffers and that it requires
对象的行为体现在其接受和请求的动作
Encapsulation/Informatio
n Hiding
 Practically speaking:
– Object has state and operations, but also
has responsibility for the integrity of its
state
对象拥有状态和操作，也有责任维护状态
– Object is known by its interface
通过接口了解对象
– Object is probably instantiated from a
template
对象一般是一个模板（类）的实例
– Object has operations to access and alter
state and perhaps generator
通过操作来存取、改变和产生对象的状态
– There are different kinds武汉大学国际软件学院空间信息与数字工程研究中心
of objects (e.g.,
actor, agent, server)
Data Abstraction or
Object-Oriented
Elements of Object
Architectures
 Encapsulation: Restrict access to
certain information
封装：限制对某些信息的访问
 Interaction: Via procedure calls or
similar protocol
交互：通过过程调用或类似的协议
 Polymorphism: Choose the method at
run-time
多态：在运行时选择具体的操作
 Inheritance: Keep 1 definition of
shared functionality
继承：对共享的功能保持唯一的接口
Elements of Object
Architectures
 Advantage: Reuse and maintenance: Exploit
encapsulation and locality to increase
productivity
复用和维护：利用封装和聚合提高生产力
 Problem: Management of many objects: Need
structure on large set of definitions
管理大量的对象：怎样确立大量对象的结构
Note: the object architecture often closely

resembles the object programming style. Is
this a problem?
注意：面向对象体系结构，通常和面向对象编程风格
? 好不好呢 ?
很类似，这是个问题吗武汉大学国际软件学院空间信息与数字工程研究中心
Finding Objects: Model
the Real World
 It’s intuitive: if we understand the
domain then we are led to a natural
system structure based on the domain.
直觉很重要：如果对现实领域理解得很好，
那么我们设计的体系结构就自然而然地基于
现实的结构
 The real world doesn’t change much,
so systems that model it are unlikely
to change much either.
现实世界结构变化很小，按照其结构建立的
体系结构变化也会很小
Finding Objects: Model
the Real World
 Capture families of related designs
through use of templates, and inheritance
通过类和继承表达同一家族的事物
 But what happens when you aren’t
modeling the real world (e.g. system for
manipulating FSMs, fuzzy logic robot
controller, natural language translation
system)? － everything is object
但是当你不是为现实世界建模时，怎么办？（比
如，你在写 FSM 管理软件，模糊逻辑机器人控
制，翻译软件）武汉大学国际软件学院空间信息与数字工程研究中心
Problems with Object
Approaches
 Managing many objects
– vast sea of objects requires additional
structuring
海量的对象需要额外的结构来容纳
– hierarchical design suggested by Booch
and Parnas
 Managing many interactions
– single interface can be limiting & unwieldy
单一的接口能力有限并且笨拙
– some languages/systems permit multiple
interfaces 多种接口方式 (inner class,
interface, multiple inheritance)
Problems with Object
Approaches
 Distributed responsibility for behavior
责任分配
– makes system hard to understand
– interaction diagrams now used in design
 Capturing families of related designs 对
相关设计的获取
– types/classes are often not enough
– design patterns as an emerging off-shoot
分支，
Managing Large Object
Sets
 Pure O-O design leads to large flat systems
with many objects
– Same old problems can reappear
– Hundreds of modules => hard to find things
– Need a way to impose structure
 Need additional structure and discipline( 规定
)
 Structuring options
– Layers (which are not necessarily objects)
– Supplemental index
– Hierarchical decomposition: big objects and little
objects
Pipes versus
Procedures
Pipes Procedures
Asynchronous, Synchronous,
Control
data-driven Blocking 模块化
Semantics 语
Functional Hierarchical
义
Parameter /
Data Streamed
return value
Binding time,
Variations 变 Buffering, end- exception
化在于 of-file behavior handling,
polymorphism
Stylistic Variations
此风格的变种
 Client-server
– Objects are processes
对象就是进程
– Asymmetric: client knows about servers, but not
vice versa
不对称：客户端知道服务器，反之则不然
 Tiered
– Elaboration on client-server
C/S 模式的扩展
– Aggregation into run-time strata (layer)
运行时层的结合
– Usually small number of tiers
通常只有少量的层
Stylistic Variations
 Components (later)
– Multiple interfaces
– Special protocols for dynamic
reconfiguration
支持动态配置的专门协议
 Compound documents 复合文档
(later)
– Document is a set of embedded
objects
一组嵌入的对象构成文档
The Middleware View
Applications
Common Application Services
Common Transport Services

invokes
 Main features
– tiered system
– factor out 50%-90% of application independent code 与
应用无关 into shared services
– build on existing transport/communication infrastructure
Example ： Reference
Model for Flight
Simulator
Required Qualities
 Real-time performance 强调及时响应
 Modifiability 适应性
– Aircraft being simulated is frequently
modified.
飞机型号经常更换，波音、空客、麦道、伊尔
– Extend these systems so that they can
simulate more and more of the real world
and further improve the fidelity of the
simulation
扩展系统使其能模拟更多的真实情况和让模拟的
精度更高
 Integrability of components
– large numbers 大量组件
– often developed by different organizations
History - 1
 Electronic flight simulators date from the 1940s.
 Digital flight simulators date from the 1960s.
 Flight simulators were written in Fortran.
 architectures were (and are) multi-process and multi-
processor: 多进程、多处理器
– communication through global common 全局组件相
互通信
– optimized for efficiency
– emphasized “run” mode over other modes
– fragmented functionality for load balancing 功能划分
很细碎 ( 平衡负载到各处理器上 )
– software partitioned based on update rates 基于更
新率（变化的幅度）进行软件划分
History - 2
 Consequences 体系结构上的缺陷
– difficult to modify/update (too many
intertwined relationships) 相互纠结
– difficult to distribute (and to change the
distribution) 分布处理
– low fidelity in non-run mode
在非 run 模式，精度很低
– difficult to insert simulated aircraft
malfunctions
难以增加飞机的新故障
– integration time was growing
exponentially with the size of the system
集成时间成指数增长
History - 3
 The primary focus has been on
performance and crew control
loops.
 System and software organization
have been based on simulator
state:
– landing
– level flight 水平飞行
– turns 武汉大学国际软件学院空间信息与数字工程研究中心
Requirements Growth
需求不断在增长 ……
 The simulator domain has grown
continually larger and more
complex.
– A complex simulator has 1-2 million
lines of code.
– Simulations involve multiple
interacting aircraft (refueling
missions).
模拟多飞机的协作 , 燃料补给 , 空中加油
– Aircraft have multiple-person crew.
Interaction Among
Instructor, Environment,
and Air Vehicle
 Instructor operator station responds to
events corresponding to instructor
commands.
 The air vehicle model works as a set of
periodic processes 周期性处理 . 仪表测试，显示
– events assumed to happen at end of period
– one “periodic” activity is to service just-occurred
aperiodic events( 不定期的事件 )
 The environment model
– updates itself periodically or
– responds to events.
Structural Model - 1
 A structural model( 结构模型 ) has two
parts.
– reference model 参照模型
– architectural style
 Architectural style features
– object-based approach (not pure O-O
because of real-time considerations)
– limited number of component types
– few patterns of components
– strictly constrained methods of
communication (hierarchical)
Structural Model - 2
 Also concerned with
– management of time 时间管理
– Coordination( 协同 ) among
components
– periodic and aperiodic computations
 The goal of the structural
modeling O-O style is to isolate
interfaces and encapsulate
knowledge, as with ADTs.
Reference Model 参考
模型
 Some functions are based on physical air
vehicle model components. 基于真实的飞机部
件,如
– airframe subsystems （机身子系统）
– propulsion subsystems （推进子系统）
 Some functions are based on environment
and physics models. 环境与物理模型
– equations of motion 运动方程
– weather
– terrain
– forces and moments 力矩模型
 Each of these is broken into subsystem and
component objects hierarchically .
Functional Partitioning
功能划分 – Airframe
机身
Functional Partitioning
– Propulsion 动力
How the Reference Model
Leads to Software
Structure
从参考
 模型到软
Fewer interfaces 件结构of
(because
functional cohesion, 功能内聚 )
 Decomposition based on physical
components when possible; this
facilitated communication between the
software engineers and the
customers/users
尽可能地按照真实情况中的形式进行组件分
解。这使开发者和用户之间更容易交流
 Modeling of malfunctions encapsulated
within components affected
把故障封装在引起该故障的组件内
Structural Modeling
Style:
Major Object Types
 Two parts: application and executive
 Application( 应用组件 ): modeling objects 给对
象建模
– subsystems
– components
 Executive( 控制组件 ): real-time scheduling 实
时调度 , instructor/operator interface, data
sharing/integrity objects
– periodic sequencer 定时序列发生器
– event handler
– timeline synchronizer 时间表同步器
– Surrogates 代理
Application
Component/Patterns
应用组件
process_event
import
Subsystem Controller
update
configure
configure
update
Component
process_event
Salient Features of
Application 应用组件的
要点
 Supports strict two-level hierarchical
pattern of decomposition( 分解 ) and
interaction( 交互 ).
– Each subsystem controller has multiple
components as children.
– Communication between subsystems is
handled by subsystem controllers, not
independent components.
– Each component can communicate only
with its parent.
– 存在不同的方法进行
 normal cyclic operation 正常的循环操作
 aperiodic operation 不定期操作
 modify configuration 修改配置武汉大学国际软件学院空间信息与数字工程研究中心
Executive Components
控制组件
Timeline Synchronizer
send
process_event
receive
Surrogate
import
export
Network
get_outbound_msg
to Other update send
Processors Periodic Sequencer configure Event Handler
import constituent_event
configure
import
Air Vehicle Subsystem
update 武汉大学国际软件学院空间信息与数字工程研究中心
processe_event
Salient Features of
Executive 控制组件的要
点
 Executive: controls real-time scheduling,
manages events, invokes data sharing.
– the timeline synchronizer( 时间同步器 )
manages the real-time scheduling on a single
hardware platform and synchronization with
other computers
– periodic tasks are controlled by the periodic
sequencer (principally import and update)
– aperiodic events are handled by the event
handler
– surrogates 代理
 represent “non-native” subsystems on a
computer and
 hides platform specifics from the rest of the
executive and the application 隐藏平台细节

Responsibilities of
Components 各组件的功
能
 Timeline synchronizer
– maintains global time for single processor
– coordinates time with other processors
 The periodic sequencer controls
schedule (invoking subsystems at the
right rates/orders).
 The event handler manages aperiodic
events (configure, send, etc.).
 Surrogates( 代理 ) manage
communication between air vehicle,
environment, and operator.
How Structural Model
Achieves Qualities 如何保证质
量
 Real-time performance is managed via
a strict separation of concerns( 相关部
件严格分离 ).
– Scheduling is managed by the executive.
– Application does the modeling.
– Subsystems are given a time “budget” and
must complete their computations within
that time.
– Frame overruns( 超限 ) are recorded for
performance monitoring and tuning.
– Subsystems run independently of each
other. 子系统间独立运行
Achieves Qualities
 Modifiability is managed by
– a division of functionality( 功能划分 ) that
matches the air vehicle wherever possible
– making components and subsystems
“standalone”; components/subsystems do
not communicate directly with each other
不直接通信，而是通过子系统控制器
– strict patterns of object interactions
 This avoids “spaghetti” objects. 粘连、
纠缠在一起
Achieves Qualities
 Integrability is achieved by the limited
paths of communication between
components and subsystems.
– Components are called by their
subsystem, which manages their data
needs.
– Subsystems are similarly called by the
executive.
 There is little direct coupling 直接耦合
between objects (unlike in
unconstrained object architectures).
Side Issue :Template-
Based Development 引出
的问题
 使用模板
 Templates (forms) were developed for
specifying functions. 对特定的功能设计有
模板
 A generator was applied to the
templates to insert coordination and
communication interfaces 加入协同与通
信接口 ;
 functionality is kept separate from
infrastructure. 功能与主系统架构分离
Flight Simulation:
Summary
 Architecture was the basis for
achieving qualities.
 A structural model uses a minimal
number of patterns to construct
flight simulators;
 this eases system
comprehension. 易于理解
 模式少，系统复杂度就小
Flight Simulation:
Summary
 The strict limitations on data and
control flow simplify integrability,
modifiability, and performance tuning
…… 简化了集成、适应性修改及性能调整 .
 Modifiability is also eased by the direct
mapping( 直接的对应关系 ) of air vehicle
subsystems to software subsystems.
1.3.3 Event System
事件驱动体系结构
 并不陌生
– Windows GUI 程序开发
– 数据库触发器
 ……
Event Systems
Implicit versus Explicit
Invocation
Indirect vs. Implicit
Invocation
Event Systems: Model
 Components: objects or processes
– Interface defines
 a set of incoming procedure calls 过程调用集合
 And also a set of outgoing events 事件集合
 Connections: event-procedure bindings
– Procedures are registered with events
– Components communicate by announcing
events at “appropriate” times “ 适时”产生
事件
– when an event is announced the
associated procedures are (implicitly)
invoked 事件发生时注册过程就调用
– Order of invocation is non-deterministic
– In some treatments, connectors are event-
Example 1 ： Smalltalk-80
Model-View-Controller
(MVC)
Example 2 ：
Field Programming
Environment
Field ： A Friendly Integrated Environment for

Learning and Development
Example 3 ：
Gandalf Environments
Daemon ：后台程序
Application 1:
Mediators 中介
 Example:
– Relationship = maintain
correspondence 管理通信
Possible Solutions
 Solutions 1: Each of the components
knows about the other
– when update operation is applied, call
routine in other
– result: brittle （脆弱）
 Solutions 2: Write a third component
that encompasses ( 包含 ) the two
– new component has combined interface
– result: overly specialized （过于特殊化，每
两个交互组件都要引入一个组件做中介）
Implicit Invocation
Solution
Application 2: Case Study
in Industrial Architecture
Design
 Oscilloscopes （示波器），一个示波器有
很多用途
 Goals
– Multiple hardware platforms for
same user interface 不同厂商产品的都
用同样的接口！使用方式大致相同
– Multiple user interfaces for same
platform 一个产品有多种用户接口 - 多
功能性！
 How to separate user interface from
application? 武汉大学国际软件学院空间信息与数字工程研究中心
continue..
 Output: application announces events 输出时
应用系统产生事件
continue..
 Input: user generates events 输入时用户产生
事件
KWIC ：考虑一下，还有别
的设计方案吗？
KWIC ： Solution 4
Advantages
 Problem Decomposition 问题分解方面
– Objects more independent than with explicit
invocation
– Interaction policy can be separated from
interacting objects! 不再使用交互对象进行交互
 System Maintenance and Reuse
– Static name dependencies not wired in, so dynamic
reconfiguration is easy 不使用静态的名字来调用了，
– Reuse objects simply by registering them
 Performance
– Possibility of parallel handling of events.
 Robustness
– The crash of one component can’t affect the others
Disadvantages
 Problem Decomposition
– No control over sequencing of invocations 无法控制调用的
顺序
– Function call semantics problematic 有语义问题？哪个才是
我真正要使用的功能呀
– Cycles may be problematic 可能会出现循环调用！
 System Maintenance and Reuse
– Needs central management to keep track of events,
registrations, and dispatch policies
– Event handling may interact badly with other run time
mechanisms (e.g., event control loops of X, RPC, etc.) 无
法交互
 Performance
– Indirection may incur overhead 处处都是间接调用！
 KWIC 中数据传输问题，数据如何传输。
Reasoning about
Events Systems 使用时
要考虑 ……
 ? Is a component living up to system-
level expectations for event
announcements?
– possibility of events not announced at
appropriate times 事件没有在恰当的时机发布
– possibility of events announced at wrong
time
 ? Are the event-method bindings
sufficient to achieve intended system
behavior?
– possibility of not having registered enough
or the right components to events
 ? Will components interfere with each
other
Implementation
Concerns:
Two Key Issues
 What are the kinds of components?
– objects
– modules
– processes
– tools
 How are events raised? 事件如何引起
– in the programming language
– as external communication events
– via some other mechanism (e.g., active
data)
Categories of Event
System 应用范畴
 Programming language extensions and
libraries
– Smalltalk, Mediators, Ada Events, C++
with events,CORBA
 Integration frameworks
– Programming events: Field, Forest, HP
Softbench, Dec Fuse, Sun ToolTalk
– User interface frameworks: X Windows,
Visual Basic, Java Beans
 Special-purpose applications 专门的应
用
– Gandalf daemons, Active databases,
Design Issues
 Event Declarations
– Who should declare events and where?
 Event Structure
– How should events be parameterized?
 Event Bindings
– How/when should events be bound to
procedures?
 Event Announcement
– How should events be announced and
dispatched?
 Concurrency
– Can components operate concurrently?
Event Declarations
事件声明
 How should events be declared?
如何
– Predefined Set of Events
– Static Event Declaration
– Dynamic Event Declaration
 Where should events be
declared? 位置
– Central Declaration of Events 集中
– Distributed Declaration of Events 分
布武汉大学国际软件学院空间信息与数字工程研究中心
Event Structure
 How should events be
parameterized?
– Simple Names
– Fixed Parameter Lists
– Parameters Determined by Event
Type
– Parameters Determined Dynamically
Event Bindings
 When should events be bound to
procedures? 何时绑定
– Static Event-Procedure Binding
– Dynamic Event Registration
 How should data be communicated between
an event and its implicitly-invoked
procedures?
– Single Fixed Parameters
(Event_Manager.Arg)
– Multiple Parameters, but all passed
– Selectable Parameters 武汉大学国际软件学院空间信息与数字工程研究中心
Event Announcement
 How should events be
announced? 事件发生后发布
– Single Announcement Procedure
– Multiple Announcement Procedures
– Extend language (e.g., announce
keyword)
Concurrency
 What is an implicitly-invocable
component?
– Independent procedure
– Module/object with procedure calls
– Independent process
– Process defined by Event_Manager
 How are events "delivered"?
– Full Delivery
– Selective Delivery
– Pattern-based Selection 武汉大学国际软件学院空间信息与数字工程研究中心
–
Example 1 ： Smalltalk-80
Model-View-Controller
(MVC)
Example 1 ： Smalltalk
 Key Points
– Commercial programming
language/environment
– Small vocabulary of events and
methods
– Implemented by inheritance +
dependency list ( 相关表 )
– Synchronous dispatch 同步分配
– Dynamic registration of dependents
依赖关系动态注册
– Primary application is user interfaces
Example 2 ：
Field Programming
Environment
Example 2 ：
Field Programming
Environment
 Key Points:
– ROTS (Remote Open Terminal
services )
– Processes communicating via
sockets to central dispatcher (MSG)
– Synchronous and asynchronous
– Pattern matching as selection
mechanism
– Events can be arbitrary strings
– Primary application is tool
Example 3 ：
Example 3 ：
 Key points:
– Events triggered on operations to data
– Fixed set of events for predefined data
operations
– Fixed event structure
– Extensible set of events for other
operations
– Organized around transactions
– Synchronous invocation
– "Tools" are written in a special purpose
language, which understands notion of
Cyclic Tasks + Shared
data
 Events via Shared Data
– Gandalf: use events to signal changes in data
– Alternative: use changes in data to represent
events
Each task repeatedly checks

the state of some set of
variables. Changes to
variables act like event
announcements.
Cyclic Tasks + Shared
data
 Key points:
– Events are represented by changes
to shared data 事件由共享变量的变化
来表示
– Each shared variable can be thought
of as an event 每个共享变量都被认为
是事件
– Tasks must be cyclic ( 循环 ):
 could be cyclic processes in a real-time
operating system, or 武汉大学国际软件学院空间信息与数字工程研究中心
written as a
1.3.4 Shared
Information
信息共享体系结构
Where are we?
Families of Architectural
Styles
Styles
Styles
Styles
Shared Information
Systems
 Style represents a large variety of systems
很多系统采用此风格
– many variants depending on nature of shared data
共同特点是共享数据
 Style addresses mechanisms for:
此风格说明其运行机制是
– collecting, manipulating and preserving large
bodies of data
收集、操作、保存大量的数据
 Databases are a natural example, but not the
only one
数据库是一个典型的例子，但不是仅有的例子
– we’ll see others in this lecture
Shared Information
Systems
 High level view
– what are the apparent features of this style?
此风格的明显特点是什么？
– what are some issues regarding this style?
这种这个风格有什么可研究的问题？
Shared Information
Systems
 Advantages
– easy to add consumers and producers of
data
很容易增加数据的生产者和消费者
 How about modifier?
 Issues
– synchronization （同步）
– configuration and schema management
（配置和管理）
– atomicity （原子性）
– consistency （一致性）
– persistence （持久性）
– performance （性能）武汉大学国际软件学院空间信息与数字工程研究中心
Shared Information
Systems Lineage 发展
历程
 Earliest repositories appear in batch
sequential systems
早期的仓库出现在批处理系统
– mainframes, drums, magnetic tapes, disc drives 主
机与记录介质
– resources manually managed
人工调配资源
 Pressure for on-line access to data
迫切需要数据即时存取
– requirement to make access to data easy and
instant
简捷地数据存取
– help to drive the shift from batch-sequential to
interactive processing
促进了从批处理到交互式处理的转变
Shared Information
Systems Lineage
 Today
– shared information systems appear
everywhere from the smallest business, to
the most advanced scientific applications
从最小的商业应用到最顶尖的科学应用，信息共
享无处不在
– many applications provide access
mechanisms to shared data
很多应用提供对共享数据的存取机制
– the Web has become a giant distributed
repository
Web 成为庞大的分布式仓库
Evolution of Shared
Information Systems
 Batch Sequential Systems
– flat file access (I/O) 普通的文件访问
Early File Access
 In the earliest systems, code had to be
written to position the media, read the data,
and do any associated “house cleaning”
operations.
早期的系统，必须自行编写代码定位存储介质、读数
据、数据整理等操作
Early File Access
 Advances in OS development focused on the
abstraction of devices 不必再关心数据存储的物
理位置
– the demand to use external data helped to drive
the development of more capable file systems
 flat file systems - one level of directories that contain
only files
 hierarchical file systems - directories that can contain
files and more directories
 language and OS support for many file types and file
access methods
Evolution of Shared
Information Systems
 Datapool (Shared Memory) Example:
– Enabled by availability of RAM and languages to
permit the sharing of common data (E.g., FORTRAN
COMMON BLOCK)
– Processes are not necessarily sequential
– Gets messy( 混乱 ) without implementation rules -
what are the issues? ( 死锁！脏读 …… )
Repository
Architecture
Unified Schemas 统一模式
for Integrating
Databases
Abstraction:
multiplex the databases; put
filters on the query/update to
match diverse views
抽象：
– 复合多个数据库；
– 在查询 / 更新操作中
增加过滤器来匹配
不同的视图
– 建立一个虚拟数据库，
定义到多个数据库的
静态映射
– 如：关系数据库中不同
的用户看到的都是二维
表形式的数据，统一用
SQL 操作访问数据
Multi-databases
Mediator 建立不同客户与不同数据库之间的映射
Evolving Database
Architectures 总结一下
……
 Batch processing:
– Standalone programs （独立的
程序）
– results were passed from one to
another on magnetic tape （结
果通过磁带从一个程序传到另一个程
序）
– batch sequential model （批处
理风格）
Evolving Database
Architectures 总结一下
……
 Interactive processing:
– concurrent operation and faster
updates preclude batching, so updates
are out of synch with reports.
并行操作、更快的更新速度，但是使更新和报
告难以保持同步。
– Repository model with external control
（类似仓库风格）
Problem: information became distributed
among many different DBs.
新问题：信息分布到很多不同的数据库
Evolving Database
Architectures
 Unified schemas:
– create one virtual database by
defining (passive) consistent
conversion mappings to
multiple DBs
建立一个虚拟数据库，定义到多个数
据库的静态映射
Evolving Database
Architectures
 Multi-database:
– DBs have many users; passive
mappings don‘t suffice; use
active agents.
数据库有很多用户；静态映射不满足
要求；使用活动的代理。
– “Layered” hierarchy
层次风格（活动代理构成一个层）
Computer Aided
Software
Engineering(CASE)
 起初，就是做从源代码到目标代码的转
换
compiler, library, linker, make
 逐渐开始包含分析、设计、调试、测试
、文档、配置管理、增量编译等功能
 集成已经作了 20 余年，但还没有结束
CASE vs. DBMS
 As compared to databases, CASE has:
– more types of data
更多的数据类型
– fewer instances of each type
更少的数据类型实例
– slower query rates
更慢的查询频率
– larger, more complex, less discrete
information
更大，更复杂，更集中的信息
– but not shorter lifetime 武汉大学国际软件学院空间信息与数字工程研究中心
生命周期没有更短
Traditional Compiler
 词法 - 句法 - 语义 - 优化 - 执行代码
Example: Modern
Canonical
Compiler
Canonical Compiler
换个角度再来看 ……
Software Tools with
Shared
Representation
Evolution of CASE
Environments
Evolution is much like databases:
 Interaction: batch --> interactive
交互：批处理交互式
 Granularity: complete processing -->incremental
粒度：完全处理增量
 Coverage: compilation --> full life cycle
应用范围覆盖：编译全生命周期
 Like databases, started with batch sequential style
如同 DB, 也是从批处理风格开始
 Integration needs led to repositories with rigid control,
then to open systems in layers
对集成性的要求，促成了应用严格控制的仓库风格，让系统开
始分层
Varieties of
Repositories
仓库风格的各种形式
Discriminate on control strategy
在控制策略上的区别，由谁决定进程的执行
 Predetermined by designer （设计者预先定义
好）
– Compilers
 Driven by types of information in input
stream
输入流的信息类型决定
– Database transaction system
 Driven by availability of new information
from other parts of the system （系统其他部分
的新信息决定）
– Scratchboard （刮板风格）武汉大学国际软件学院空间信息与数字工程研究中心
Repository
(Blackboard)
谁来控制、决定 ks (Knowledge
source) ，须一个其它模块！
The Blackboard Model
The Blackboard Model
 Knowledge Sources
– 把问题分成几个部分，每个部分独立
计算
– 响应黑板上的变化
 Blackboard Data Structure
– 全局数据库包含解域的全部状态
– 知识源互相作用的唯一媒介
 Control
– 让知识源响应偶然事件
Blackboard
Architecture
 Key ideas
– 知识在一些协作的 processes 之间共享和分
布
 The Blackboard Architecture have 3 major
components
– knowledge sources （知识源）
– blackboard （黑板）
– control （控制）
 Historical examples:
– Hearsay I, Hearsay II, HASP/SAIP,
CRYSALIS, ATOME
– 信号处理、专家系统、模式识别领域经常采用武汉大学国际软件学院空间信息与数字工程研究中心
Blackboard
Architecture
Blackboard Problem
Characteristics
 no direct algorithmic solution
没有直接的算法可解
– multiple approaches to solving the problem
多种方法都可能解决问题
– various domain expertise required to solve the
problem
需要多个领域的专门知识协作解决
 Uncertainty 非确定性
– error and variability in data and solution
数据和解决方法可能错误或变化
– moderate to low “signal-to-noise-ratio” in data
数据中信噪比的变化，那些是可以给出解决方案的 KS
– Uncertainty interferes with algorithmic solutions
算法接口的变化， KS 总在变化
Blackboard Problem
Characteristics
 “Best-effort” or approximation is good
enough
– no single discrete answer to problem, or
“right” answer may vary
问题没有唯一的解答，或者“正确”答案会变化
 examples
– signal processing （信号处理）
– problem solving (planning, logistics,
diagnostics)
– compiler optimization
Knowledge Sources
 Objective:
– contribute knowledge that leads to solution
提供解决问题的知识
 Representation:
– procedures, sets of rules, logic assertions
过程、规则、逻辑断言
 Action:
– modify only the blackboard (or control data --
magic)
只修改黑板
 Responsibility:
– know when it’s possible to help
知道何时能发挥作用 ( 黑板状态改变时 )
 Selection:
– loosely-coupled subtasks, or 武汉大学国际软件学院空间信息与数字工程研究中心
areas of specialization
低耦合的子任务，或是在专门的应用领域
Blackboard Data
Structure
 Objective:
– hold data for use by knowledge sources
保存知识源要使用的数据
 Representation:
– stores objects from solution space, including
保存来自解空间的数据，包括
 input data, partial solutions, alternatives, final
solutions, control data
 objects and properties define the terms of the
discourse ( 推理过程 )
 relationships are denoted by named links (“next-to”,
“part-of”)
 Organization:
– hierarchical, possibly multiple hierarchies; links
between objects on same or 武汉大学国际软件学院空间信息与数字工程研究中心
different levels
Control
 Objective:
– 让知识源响应偶然事件
 Representation:
– 了解各个知识源的能力，决策解决问题的步骤
Example ： The Puzzle
Metaphor
Example ： The Puzzle
Metaphor
 Data within the blackboard is often
structured hierarchically
Level 4 assemble chunks

build chunks of
Level 3 edges
build chunks of sky
collect edge pieces
Level 2
collect sky pieces
Turn all pieces
Level 1
picture side up
Hearsay II( 一个专家系
统 -- 语音理解系统 )
 Complex blackboard system to deal with
arbitrary speech recongition (a difficult
problem):
– Ambiguity in segmentation （音节分割问题） :
“Mary’s truck” versus “Mary struck”
– Ambiguity in stress （重音问题） :
“disease” versus “dizzies”
– Ambiguity in grammar （语法问题） :
“The horse raced past the barn fell”
“The horse raced past the barn fell”
“ 这个星期日本人参观了国软学院”
– Ambiguity in semantics （语义问题） :
“I saw the man on the hill with the binoculars”
“I saw the man on the hill with the binoculars”
Problem Solving
Strategy
 Had to be incremental, opportunistic, flexible
必须是增量的、机会的、灵活的
 Hearsay-II employed several strategies:
– Bottom-up (synthetic)
– Top-down (analytic)
– General hypothesize-and-test （猜测和测试）
 Blackboard structure entertained many
simultaneous hypotheses
黑板结构可以同时处理多种假设
 Control was complex: had a monitor portion
and a priority based scheduler
控制很复杂：有一个监视器，采用基于优先级的调度
Hearsay II Structure
Lecture Summary
 Repositories are ubiquitous in computer-
based applications.
仓库在计算机应用中几乎无处不在
 Shared information systems in many areas
show similar trends, stimulated by similar
technological and business pressures.
信息共享系统在很多领域有相似的发展趋势，因为有
相似的技术和商业压力的激励
 Blackboards are specialized types of
repositories for dealing with “messy”
information processing domains where the
control strategy must be opportunistic.
黑板是一种特别的仓库，主要用于需要对凌乱的信息
进行处理的领域，其控制策略必须是机会主义的
1.3.5 Others
其他体系结构
我们要研究的体系结构
 层次
– 完整的包装
 解释器
– 计算机语言理解
 客户 / 服务器
– 80% 的应用使用
 P2P
– 未来？游戏？
层次 (Layered System)
 无处不在的层次结构
软件用
硬件
户
应用
OS 用
硬件
户
应用
应用 OS 用
户
平台
硬件
应用
OSI 参考型
层次风格特点
 每层为上一层提供服务，使用下一层的
服务，只能见到与自己邻接的层
– 适当时候 ( 必不得已的时候 ) ，可以允许
一定的越层操作
 大的问题分解为若干个渐进的小问题，
逐步解决，隐藏了很多复杂度
 修改一层，最多影响两层，而通常只能
影响上层。接口稳固，则谁都不影响
层次风格特点
 上层必须知道下层的身份，不能调整层
次之间的顺序
 层层相调，影响性能
Java 的 I/O
 层次风格，还是管道风格？
DataOutputStream out =
new DataOutputStream(
new BufferedOutputStream(
new
fileOutputStream(“Data.txt”)));
out.writeChars(“ 偶是层次风格的吗！” );
Java 的 I/O
 层次风格，还是管道风格？
OutputStream
+write()
FilterOutputStream
+write()
DataOutputStream BufferedOutputStream FileOutputStream

+write() +write() +write()
Interpreter （解释器）
解释器的用途
 解释型语言
– VB 、 Javascript 、 VBScript 、 HTML
、 Java 字节码、 Matlab
– 脚本、配置文件
 通信协议
 用户输入
– 游戏中的组合按键
客户 / 服务器 (C/S)
客户
客户
客户
客户
网
络
服务器
客户
客户
客户客户
…
服务器
…
Local Loopback
…
…
客户客户
网络
客户
C/S 的特点
 基本上具备仓库风格的一切特点
 服务器和客户可以完全异构，只要遵从统一
的网络协议
 客户必须知道服务器的地址
 服务器的地址必须静态，客户可以动态
 必须由客户主动连接服务器
 客户之间的信息传递要经过服务器中转
– 可以扩展出客户之间的直接通信机制
 服务器易受攻击
 服务器瘫痪，所有客户失效武汉大学国际软件学院空间信息与数字工程研究中心
本地 C/S 的特点
 可以用不同语言编写服务器和客户机程
序 ( 只要保证协议一致 )
 一般说来，本地回路的网络状况很好，
非常稳定，速度快
 可以传递大量数据，但是要进行数据拷
贝，开销大
 可以远程客户和本地客户协同工作
 纯本地 C/S 不会受到外界影响
C/S 的特例 -- B/S
 客户端有 http 浏览器即可
– 为增强功能，往往还需要安装 flash 、 jvm 及一
些专用插件
 使用标准 http/https 协议，省却很多麻烦
 只能“拉”，不能“推”
 客户之间的通信只能通过服务器中转
 对客户机资源和其他网络资源的利用受限
 服务器的负荷大，客户机的资源浪费
– 用 java Applet 、 flash 、 ActiveX 等客户端计
算技术解决武汉大学国际软件学院空间信息与数字工程研究中心
对等网 (P2P)
P2P 特点
 整体稳定，不会因为一点的错误影响全局
 资源共享，任务分摊
 架构 1
– 两点之间可能不通
 某些情况可以从其他点获得同样的资源
 架构 2
– 两点之间可以寻求多种路径互通
– 每点还要承担一定量 ( 很可能大量 ) 的中转负荷
– 容易产生泛洪现象，浪费带宽
P2P 面临的人文问题
 P2P 的内容很难有效控制，所以成为有
害信息的温床
 “one for all, all for one”
– 真的很难做到
多种体系结构的组合方式
 聚合方式
– 组件的体系结构
– 例如：编译器中的文法分析组件
 联合方式
– 某一个组件或连接件成为两种以上体系结构联系
的纽带
– 可能是聚合方式的展开
– 例如：视频点播系统
 混合方式
– 把多种体系结构的优点，混合使用。主要体现在
连接件的混合使用
– 例如：事件驱动的 CASE 系统
1.4 体系结构描述
标书
 吹嘘自己（不温不火地贬低对手）
 提出自己的设计方案（体系结构）
 吹嘘自己的方案（不温不火地贬低对手
的方案）
描述和讲解体系结构设计方案是非常
重要的技术
假定你是 Module
Designer
 你最近加盟一家公司，并被安排在一个
新项目的开发组中。虽然你富有经验，
但是对此项目所涉及的领域还是一个新
手。系统的高层体系结构设计已经完成
。
 你的老板（项目经理）让你预计你将要
完成的几个模块的开发时间。
 你怎么办？
假定你是 Module
Designer
 你来开发 A2 和 A3 ，怎么开始？
假定你是 Consultant( 顾
问)
 你是一个请来的顾问，对一个体系结构
设计进行评估。 Modifibility 和
Performance 是重要的体系结构质量
因素。
 你会询问什么样的信息？
问)
 面对这样的图，你会有什么反应？
问)
 面对这样的图，你会有什么反应？
体系结构文档的用处
 软件开发过程中各种角色之间交流设计
思想的媒介
 进行上层分析的基础。此基础上可以验
证体系结构设计方案，精炼或改变必要
的方案
 让别人理解系统的第一手资料
与 Module Designer 交
流
 基本想法是什么？
 我该做什么 ( 如，实现哪些需求 ) ？
 我该在哪做 ( 如，这项功能实现在哪里 ) ？
 我和谁交互？接口是什么？
 有什么可以重用的代码？
 必须遵从什么约定 ( 质量目标、旧体系 / 接口
、预算等 ) ？
 有哪些硬性规定 ( 设计、接口、约束等 ) ？
与顾问交流
 体系结构的必要需求 (driving
requirement) 是什么 ( 如， performance,
availability, security, modifiability,
interoperability) ？
 各种体系结构视图是如何描述的？
– 抽象出来什么？
– 功能怎样分解？
– 功能怎样分配？
– 使用什么硬件以及软件怎样布置在硬件上？
 采用了哪些体系结构风格？
这是什么？
上图的毛病
 很多事情没有说：
– 组件类型
– 连接件类型
– 圆圈和箭头代表什么？
– 这种布局的意义是什么？
– 为什么 CP 要放在上层？
 只画出方框和线条不是体系结构，只是
体系结构的开始
好的体系结构文档的必要元
素
 需求陈述
– 商业环境、产品的背景、领域
 描述环境
– 必须和什么系统交互、外部接口
 使用体系结构图
– 用恰当的线框
– 简洁的说明
好的体系结构文档的必要元
素
 考虑实现时的限制
– 但是仅在它们能影响体系结构设计的范围
内
 被限定的下层结构、处理器需求
– 通常包含其他结构图
 体系结构设计的原理
– 它怎样去符合需求与约束
– 其他的设计
其他方面
 风格 / 产品线问题
– 设计可变的尺度
– 体系结构的那个方面必须不被改变？
 管理问题
– 暗含开发团队的组织结构
– 体系结构评审情况
 其他设计问题
– 代码重用、标准的运用
– 风险分析
– 运作、管理和维护
好文档
 线和框有不同的形状 / 颜色，并有图例
说明
 用表格总结方案选择等等各种问题
 图并不试图去表达很多信息：把信息分
散到需要表达它的各个视图中
 每个体系结构视图必须在一页内完成
 清晰地区分出哪些是体系结构视图，哪
些不是
坏文档
 所有的线看起来都一样
 箭头不代表任何涵义
 箭头代表很多涵义
 实现与文档冲突
 没有图例
 太多的必要需求
视图
 系统需要多种视图来描述
– 其中的一小部分是描述体系结构的
 运行时视图 / 动态视图 ( 组件和连接件 )
– 在高层分解成组件和连接件
 代码视图
– 模块关联和依赖
 使用 / 调用 / 和…共享数据
– 文件和目录、工程和编译文件、版本控制
 物理视图
– 把计算单元分配到各个进程或处理器
例子：运行结构
例子：代码结构
软件体系结构文档
IEEE P1471
http://www.firstmark.ca/ContentDocs/architectural%20docs/IEEE1471%20Arch%20Standard/ieeecontent.htm
文档使系统易于理解
 文档应该从读者而不是作者的角度写
– 对不同的人，写不同的文档
 避免重复
 避免无意的含糊言辞
 使用标准的文档结构
 解释符号的含义
 写下原理和理由
– 不仅是如此做的理由，还有为什么不那么做的理由
 让文档保持新鲜
– 但是别太新鲜
 审核
– 自我审核和他人审核
参考资料
 Philippe Kruchten, Architectural
Blueprints—The “4+1” View Model of
Software Architecture, IEEE Software
12 (6), 1995, pp. 42-50
 Release 6A Segment/Design
Specification for the ECS Project,
Section 4.4. NASA Report 305-CD-600-
001, pages 4-160-185. March 2001
http://edhs1.gsfc.nasa.gov/waisdata/toc/cd
2. 移动空间信息服务应用
系统体系结构
 整体
 固定端
 移动端
3. 系统固定端应用设计与
开发
4. 系统固定端应用设计与
开发
5. 课程设计要求
 开发移动空间信息服务应用

空间信息移动服务2 软件体系结构

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

空间信息移动服务2 软件体系结构

Uploaded by

Copyright:

Available Formats

移动空间信息服务应用

...beyond the algorithms and data structures

“..the larger the

 Guide to the Software Engineering Body of Knowledge (SWEBOK)

 “Make it right before you make it

 Don’t pretend you know the user; you

There is no complete list.

There is no unique, non-overlapping list.

Styles overlap. 风格是彼此重叠的

Systems exhibit multiple styles at once.

 or lines could be stored explicitly

– hide internal algorithm used to process that

Note: the object architecture often closely

Common Application Services

Common Transport Services

executive and the application 隐藏平台细节

Field ： A Friendly Integrated Environment for

Each task repeatedly checks

Level 4 assemble chunks

DataOutputStream BufferedOutputStream FileOutputStream

You might also like

空间信息移动服务2 软件体系结构

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

空间信息移动服务2 软件体系结构

Uploaded by

Copyright:

Available Formats

移动空 间信 息服务 应用

...beyond the algorithms and data structures

“..the larger the

 Guide to the Software Engineering Body of Knowledge (SWEBOK)

 “Make it right before you make it

 Don’t pretend you know the user; you

There is no complete list.

There is no unique, non-overlapping list.

Styles overlap. 风格是彼此重叠的

Systems exhibit multiple styles at once.

 or lines could be stored explicitly

– hide internal algorithm used to process that

Note: the object architecture often closely

Common Application Services

Common Transport Services

executive and the application 隐藏平台细节

Field ： A Friendly Integrated Environment for

Each task repeatedly checks

Level 4 assemble chunks

DataOutputStream BufferedOutputStream FileOutputStream

You might also like

移动空间信息服务应用