4 1体系结构视图
软件体系结构知识总结
第一部分-------填空，选择，判断1．软件工程三个要素：方法、工具和过程2．软件元素：程序代码、测试用例、设计文档、设计过程、需求分析文档3．构件分类：关键字分类刻画分类法和超文本组织法4．软件体系结构技术反战经历四个阶段（1）无体系结构设计阶段----以汇编语言进行小规模应用程序开发（2）萌芽阶段-----以控制流图和数据流图构成软件结构为特征（3）初期阶段-----出现了从不同侧面描述系统的结构模型，UML（4）高级阶段-----描述系统的高层抽象结构，出现“4+1”模型5．软件体系结构模型：结构模型、框架模型、动态模型、过程模型和功能模型。
6．“4+1”视图模型从五个不同的视角，包括逻辑试图，进程试图，物理视图，开发视图和场景视图来描述软件体系结构。
逻辑视图主要支持系统的功能需求，是系统提供给最终用户的服务。
通过抽象，封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图；开发视图也称模块视图，主要侧重于软件模块的组织和管理，主要考虑软件内部的需求，如软件开发的容易性、软件的重用等，通过系统输入输出关系的模型图和子系统图来描述,提供给编程人员的；进程视图侧重于系统的运行特性，主要关注非功能性的需求，如系统的性能和可用性。
进程视图强调并发性、分布性、系统集成性和容错能力管道和过滤器风格、客户/服务器风格等适合进程视图，提供给系统集成人员的；物理视图主要考虑如何把软件映射到硬件上，它通常考虑系统性能、规模、可靠性等，解决系统拓扑结构、系统安装、通信问题,提供给系统工程人员的。
而场景是那些重要系统活动的抽象，它使四个视图有机联系起来，是最重要的需求抽象，它可以帮助设计者找到系统结构的构件和他们之间的作用关系。
总之，逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
软件体系结构的核心模型由五中元素组成：构件、连接件、配置、端口和角色。
7. 软件体系结构的核心模型由五中元素组成：构件、连接件、配置、端口和角色。
软件体系结构的4+1视图new
Example Of Process Blueprints
The Development View
• The subsystem decomposition • Notation for the development view • Style for the development view • Example of development blueprints
“include”, “with” • Containers: subsystem (library) • Stakeholders: developer • Tool support: Rational/Apex
Notation For The Development View
• A version of the Booch notation, the Apex development environment from Rational s upport the notation.
• Garlan and Shaw’s taxonomy: pipes and filters client/server (for simple system)
• Similar to the process groups approach of the ISIS system as described by K.Birman with another notation and toolset (for complex system)
Style For The Development View
The Logical View
• Concerns: functionality • Components: object or object class • Connectors: association,
Kruchten的4+1模型描述软件体系结构2
2013-7-9
25
对体系结构进行的描述是围绕着以上4个视图展开的。然后，通 过选择出的一些用例对体系结构加以说明。这些用例被称作场景 (scenarios)，它们构成了第5个视图。实际上，体系结构在某种 程度上是由场景演化而来的。
2013-7-9
26
体系结构的概念在每个视图里面都可以独立应用。这就是说，可以在每个视图 里面定义体系结构的各种组成元素，如构件、连接件等。对于不同的视图，还 可以选择不同的体系结构风格，因此在同一个系统结构中可以使用多种风格。 此外，在每一种视图里，我们使用该视图特定的符号。这避免了符号用法和意 义的混乱。“4十1”视图模型是一个十分通用的模型：可以便用其他的符号表示 法，也可以使用其他的设计方法，尤其是逻辑视图和过程视图的分解。
终端
连接服务
控制器
编号计划
2013-7-9
32
进程视图的体系结构：过程分解
过程体系结构考虑的是一些非功能性的需求，诸如性能、可用性等。 它所要面对的问题有并发，分布，系统的完整性，容错能力等。它还 要考虑怎样把过程体系结构与逻辑视图体系结构的要点相适应——对 某个对象的某个操作实际上是在哪个控制线程上发生的。
2013-7-9
33
过程视图的体系结构：过程分解
软件被分为独立的任务的集合。每个任务是一个独立的控制线程，可 以在一个处理节点上独立单独调度。因此可以将任务分为主任务和辅 任务。主任务是需要单独解决的体系结构元素。辅任务是由于实现原 因而在本地加入的附加任务(缓冲，超时，等等)，例如可以将它们实 现为轻量级的线程。主任务通过一套完善定义的任务间通信机制进行 通信：同步的或异步的基于消息的通信服务、远程过程调用、时间广 播等。不应当假设通信中的主任务处于同一个过程中或处在同一个处 理节点上。辅任务的通信可以采用共享内存的方式或其他双方约定的 方式。 基于过程体系结构设计图，可以估计出消息流和过程负荷。
软件体系结构-期末大题
1.基于构件的软件开发的优势是什么？基于构件的软件将软件开发的重点从程序编写转移到了基于已有构件的组装，更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降低了软件开发的费用2.尝试用自己的语言介绍Kruchten的“4+1”模型。
Kruchten 提出了一个"4+1"视图模型，从5个不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。
每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容。
3.在希赛公司的一个财务管理系统，财务部要客户提供…………4.不同的体系结构风格具有各自的特点、优劣和用途。
试对管道-过滤器风格、事件驱动风格、分层系统、C2风格和基于消息总线的风格进行分析比较。
P52-56(1)管道和过滤器特点：@使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；@允许设计者将整个系统的输入输出行为看成是多个过滤器的行为的简单合成；@支持软件重用。
只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；@系统维护和增强系统性能简单。
新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；@允许对一些如吞吐量、死锁等属性的分析；@支持并行执行。
每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行缺点：①通常导致进程成为批处理的结构。
②不适合处理交互的应用。
③因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。
（2）（3）分层系统体系结构有以下优点：第一，支持基于抽象程度递增的系统设计。
这允许设计者可以将一个复杂系统设计按递增的步骤进行分解。
第二，支持功能增强。
因为每层至多和与之相邻的上层和下层交互，所以，改变某层的功能最多只会影响与之相邻的其它两层。
第三，支持重用。
与抽象数据类型一样，只要对相邻层提供同样的接口，每层可以有很多不同的可相互替代的实现方法。
体系结构蓝图—软件体系结构的+视图(中文版)
体系结构蓝图—软件体系结构的+视图(中文版)————————————————————————————————作者：————————————————————————————————日期：本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。
是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。
许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的Abowd & Allen、SEI 的Clements。
作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。
Perry 和Wolfe 使用一个精确的公式来表达，该公式由Boehm 做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
程序员教程张友生版课后答案
程序员教程张友生版课后答案一、选择题←不属于软件体系结构的核心模型的最基本的元素是DA构件B连接件C配置D角色2、选项中不属于“4+1"视图模型的是: (D)A逻辑视图B物理视图C连接视图D开发视图3、下列说法错误的一项的是(D)A ：逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务B：开发视图也称模块视图，主要侧重于软件模块的组织和管理C：进程视图侧重与系统的运行特性，主要关注一些功能性需求,例如系统的性能和可用性。
D：物理视图主要考虑如何把软件映射到硬件上，它不需要考虑到系统性能、规模、可靠性等。
4、Kruchten 在1995提出了“4+1"模型，从5个不同的视角来描述软件体系结构，其中“4”不包括的视图是(D) ?A逻辑视图B开发视图C物理视图D场景视图5、下列哪个选项是描述系统的静态结构(A)A.逻辑视图和开发视图B.进程视图和物理视图C.开发视图和物理视图D.开发视图和进程视图开发视图也称模块视图，主要侧重于软件模块的组织和管理6、在三层C/S体系结构中，(A) 是最重要的构件。
A中间件B末尾件C功能层D数据层7 C/S系统中，服务器的以下任务中哪一个是错的? (A)A数据库一致性要求B数据库访问并发性控制C数据库前端的客户应用程序的全局数据完整性规则D数据库的备份与恢复8、与C/S体系结构相比，B/S体系结构也有许多不足之处一下说法正确的是(A)A :B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理能力。
B :B/S体系结构的系统扩展能力差，但是安全性比较容易控制。
C：采用B/S体系结构的应用系统,在数据查询等响应速度上,要远远的高于C/S体系结构。
D：B/S体系结构的数据提交-般以页面为单位，数据的动态交互性不强，利于在线事务处理. (Online Transaction Processing, OLTP)应用。
9、通常,一个Web服务可以分为4个逻辑层，分别为数据层(Data Layer) 、数据访问层(Data Access Layer) 、业务层(Business Layer) 和监听者(Listener) 。
体系结构蓝图—软件体系结构的41视图（中文版）
本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。
是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。
许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的 Abowd& Allen、SEI 的Clemen ts。
作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。
Perry和 Wolfe使用一个精确的公式来表达，该公式由 Boehm做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
软件架构设计之“4+1”视图模型
软件架构设计之“4+1”视图模型1、软件架构设计 软件架构是具有⼀定形式的结构话元素，即构件的集合，包括处理构件、数据构件和连接构件。
处理构件负责对数据进⾏加⼯，数据构建是被加⼯的信息，连接构件把架构不同部分负责连接起来。
软件架构是软件设计过程中⼀个层次，这⼀层次超越计算过程中的算法设计和数据结构设计。
2、软件架构建模 设计软件架构的⾸要问题是如何表⽰软件架构，即对软件架构建模。
根据建模的侧重点不同，可以讲软件建构的模型分为5种，分别是结构模型、框架模型、动态模型、过程模型和功能模型。
2.1结构模型这是⼀个最直观、最普遍的建模⽅法。
这种⽅法以架构的构件、连接件和其他概念呢来刻画架构，并⼒图通过结构来反映系统的重要寓意内容，包括系统的配置、约束、隐含的假设条件、风格和性质等。
研究结构模型的核⼼是架构描述语⾔。
2.2框架模型框架模型和结构模型类似，但他不太侧重描述结构的细节⽽更侧重与整体的结构。
框架模型主要以⼀些特殊的问题为某表建⽴⾄针对和适应该问题的结构。
2.3动态模型动态模型是对结构或框架模型的补充，研究系统“⼤颗粒”的⾏为性质例如，描述系统的重新配置活演化。
动态可以指系统的总体结构和配置、建⽴活拆除通信通道或计算的过程。
这类系统是激励型的。
2.4过程模型过程模型研究构造系统的步骤和过程，因⽽结构是遵循某些过程脚本的结果。
2.5功能模型该模型认为架构是⼀组功能构件按层次组成，下层向上提供服务。
它可以看作是⼀种特殊的框架模型。
在这5中模型中，最常⽤的是结构模型和动态模型。
这5中模型各有所长，将5中模型有机地统⼀在⼀起，形成⼀个完整的模型来刻画软件架构更合适。
例如，Kruchten在1995年提出了“4+1”视图模型。
3、“4+1”视图模型 “4+1”视图模型从5个不同的视⾓包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。
每个视图只关⼼系统的⼀个侧⾯，5个视图结合在⼀起才能反映系统软件架构的全部内容。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
从一般类发现特殊类
姓名 身分证号码 股份 工资 ……
公司职员
姓名 身分证号码 …… ……
公司职员
？
……
股东 股份 ……
……
……
职员 工资 ……
？
从特殊类发现一般类 ？
……
两种结构的变通
汽车 ……
……
制冷设备
……
……
汽车 ……
……
冷藏车
……
……
冷藏车
冷藏车
制冷设备
……
……
……
……
……
……
汽车 ……
……
制冷设备
……
……
仅用一般 -特殊结构
两种结构 同用
仅用整体 -部分结构
用整体-部分结构实现复用
机床 ……
……
起重机
……
……
送料车
……
……
车床
刨床
……
……
……
……
钻床
超市销 售管理 系 统 (特征层)
售出 补充 价格更新
计量商品
供货员 特价商 开始日期 品
结束日期 *单价 计量单位 计价方式 缺货登记表 缺货登记 供货
*售出 *补充 *价格更新
建立数据字典
为所有模型实体准备一个数 据字典, 精确描述每一个对象 类,包括:
•成员 •约束 •关联、属性、操作
对象字典举例：
对象的状态与状态转换图 例：栈的状态/服务对照表
空 压入 弹出 可执行 不可执行 半满 可执行 可执行 满 不可执行 可执行
例：栈状态转换图 创建
空
压入 压入(未满) 弹出(未空) 半满
弹出(报错) 弹出(已空)
压入(已满)
满
弹出
压入 (报错)
• 定义服务
对象行为分类 发现服务的策略 审查与调整 识别对象的主动行为 服务的详细说明(服务解释、消息协议、 消息发送、约束条件、服务流程图)
并发系统中 的消息传递
被动对象D
控制线程内部 的消息连接 控制线程之间 的消息连接
被动对象C
被动对象E
控制点返回示意
多个控制线程之间的消息与顺序系统中消息的不同之处
(1)并发执行的控制线程之间传送的消息的不同用途: • 向接收者发出访问请求
•向接收者提交数据 •向接收者发布通知或事件信息 •向接收者传递同步控制信号
……
……
电动机 … … ……
筛选：删除下列关联 •已删去的类间的关联 •无关或实现关联 •瞬时事件 •三元关联 •派生关联
总行
拥有
组成
银行代码
分行
持有 雇佣
拥有
帐户 储户
拥有 存取
修改
拥有 通信
修改
中央 计算机
通信
分行 计算机
拥有
出纳员
被进入
出纳
进入
工作站
出纳业务 授权 现金卡
对每个控制线程考虑：
(3)对象分布问题及对消息的影响
•每台处理机上分布的一组对象中至少应有一
个主动对象；
•同一台处理机上的对象之间的消息通信既可
能是一个控制线程内部的，也可能是不同控 制线程之间的。
@收款机
本班出纳员 开始时间 结束时间
销售事 收款人 件
帐册
@登录 售货 结帐
购物清单 应收款 …… 销售计划 入帐
类名 帐户 ATM 银行 出纳员 …… 父类 …… …… …… …… …… 提供的服务 需要的服务 …… …… …… …… …… …… …… …… …… ……
步骤3：定义结构与连接
• 初步确定关联
• 对应于描述性动词或动词短语 • 需求陈述中隐含 • 根据问题域知识得出
• 筛选 • 完善 • 分析标识对象之间的关系
(2)消息的同步与异步
(3)接收者对消息的不同响应方式 (4)发送者对消息处理结果的不同期待方式 (5)消息的接收者是否唯一
•定向消息 •广播消息
OOA对消息的表示—消息连接
消息连接是OOA（或OOD）模型中对对象 之间行为依赖关系的表示 识别和表示的主要问题：
•对象之间是否存在消息？ •消息是同一线程内部的还是不同线程之间的？ •每一种消息是从发送者哪个服务发出的？
:控制对象执行与特定用例有关的行为，
建立系统与参与者间的交互模型
帐户
出纳员接口
提取
分析类型之间的关系
用例模型 分析模型
取款
出纳员接口
提取
吐钞器
帐户
每个用例都有一个说明如何执行用例的协作图
描述对象如何执行用例的顺序图
银行储户 出纳员接口 吐钞器
银行储户标识自己
提取
帐户
检验标识符
提取
银行储户说明帐户 和要提取的钱数. 系统从帐户中提取 并给付此笔钱款
举例：用例模型中添加通信关联的指向
执行者启动用例
订货
客户
系统启动用例
获得订单的状态
客户
由客户或者系统 启动用例
客户
获得订单的状态
Yourdon的OOA方法
以类与对象图及对象状态图为辅助工 具，建立问题域的五层模型.
OOA模型被划分为五个层次 (五个视图)
OOA的结构
Class &object layer (类及对象层)
用例的分析、设计和实现
用例模型 分析模型
取款
设计模型
取款
实现模型
取款
取款
用例的分析、设计和实现
用例模型 分析模型
取款
出纳员接口
吐钞器
帐户
提取
三种不同构造型的分析类
≪实体类≫ ≪边界类≫ ≪控制类≫ ：实体对象一般是系统中长效且持久
的对象
:边界对象处理系统与环境之间的通信，
建立系统与参与者间的交互模型
提取
给付
分析模型形成系统体系结构
分析模型
出纳员接口
银行储户
吐钞器 提取管理
提取
帐户
采用分析模型重新描述取款用例
分析模型中参与多个用例实现的类
用例模型 分析模型
取款
吐钞器
提取
在不同帐户间转帐
出纳员接口
转帐
帐户
银行 储户
存款
出纳员
存入
用例模型捕获、表示系统的功能性需求
设计模型中的设计类与分析模型中的分析类
取消没有特殊属性的特殊类
学生 姓名 学号 班级 ……
……
学生 姓名 学号 班级 ……
……
大学生
研究生 研究方向 指导教师
……
研究生 研究方向 指导教师
……
通过增加属性简化一般-特殊结构
人员 ……
……
人员 性别 国籍 ……
美国人 日本人
……
男人 ……
女人 中国人
…… ……
……
…… ……
…… ……
……
如：ATM机器、帐户等
(2)审查和筛选, 舍弃无用的类 对象的精简
•只有一个属性的对象 •只有一个服务的对象
推迟到OOD考虑的对象
@收款机
销售事 件
帐册
商品一览表 商品
@上级系统接口
超市销 售管理 系 统 (对象层)
供货员 特价商 品
计量商品
步骤2： 定义属性与服务 •定义属性 •定义服务
姓名 身分证号码 …… ……
公司职员
股东 姓名
身分证号码
职员 姓名
身分证号码
股东 股份 ……
……
……
职员 ……
……
收款机
A B C X Y
现钞收款机
A B C D E F X Y Z
收款机类成为 可供本领域其 它系统复用的 领域构件
现钞收款机 D E F
Z
为支持复用建立结构
4+1体系结构视图
最终用户
功能
程序员
逻辑视图
设计人员 /测试人员 行为
实现视图
软件管理
用例视图 过程视图 展开视图
系统工程师 系统拓扑结构 交付、安装 通信
系统集成人员 性能 可扩展性 吞吐量
举例：自动取款机(ATM)系统的用例模型
用例模型捕获、表示系统的功能性需求
取款
存款
银行储户
在不同帐户间转帐
(2)建立控制线程之间的消息连接
• 它在执行时是否需要请求其它控制线程中的对
象为它提供服务？由哪个对象发出？由哪个对 象中的服务处理？ • 它在执行时是否要向其它控制线程中的对象提 供或索取数据？ • 它在执行时是否将产生对其它控制线程的执行 有影响的事件？ • 各个控制线程的并发执行是否要传递同步控制 信号 • 一个控制线程在何种条件下中止执行？ 中止后在何种条件下由其它控制线程用何法唤醒?
由接收者哪个服务响应处理的？
•消息是同步还是异步？ •发送者是否等待消息的处理结果？
如何建立消息连接
(1)建立控制线程内部的消息连接 基本策略：“服务模拟”
“执行路线追踪”
具体做法：
•人为地模拟当前服务的执行，通过考虑需要
请求其它对象的服务来发现新消息。
•分析该消息的发送者与接收者在执行时是否
属于同一控制线程
Attribute layer (属性层)
属性 服务
类的边界
实例的边界 实例连接
消息连接
Service layer (服务层) Structure layer (结构层)