Kruchten的4+1模型描述软件体系结构
- 格式：ppt
- 大小：1.01 MB
- 文档页数：58
下载文档原格式
合集下载
软件体系结构期末大题
软件体系结构-期末大题————————————————————————————————作者：————————————————————————————————日期:ﻩ1．基于构件的软件开发的优势是什么?基于构件的软件将软件开发的重点从程序编写转移到了基于已有构件的组装,更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降低了软件开发的费用2.尝试用自己的语言介绍Ｋruｃhteｎ的“4+１”模型。
Ｋrｕcｈten 提出了一个"4+1"视图模型，从５个不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。
每一个视图只关心系统的一个侧面,5个试图结合在一起才能反映系统的软件体系结构的全部内容。
3.在希赛公司的一个财务管理系统,财务部要客户提供…………4.不同的体系结构风格具有各自的特点、优劣和用途。
试对管道－过滤器风格、事件驱动风格、分层系统、C2风格和基于消息总线的风格进行分析比较。
P52-56（1)管道和过滤器特点:@使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；@允许设计者将整个系统的输入输出行为看成是多个过滤器的行为的简单合成；@支持软件重用。
只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；＠系统维护和增强系统性能简单。
新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉;@允许对一些如吞吐量、死锁等属性的分析;@支持并行执行。
每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行ﻫ缺点:①通常导致进程成为批处理的结构。
②不适合处理交互的应用。
③因为在数据传输上没有通用的标准,每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降,并增加了编写过滤器的复杂性。
(2)(3）分层系统体系结构有以下优点：第一，支持基于抽象程度递增的系统设计。
这允许设计者可以将一个复杂系统设计按递增的步骤进行分解。
软件体系结构-期末大题
1.基于构件的软件开发的优势是什么？基于构件的软件将软件开发的重点从程序编写转移到了基于已有构件的组装，更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降低了软件开发的费用2.尝试用自己的语言介绍Kruchten的“4+1”模型。
Kruchten 提出了一个"4+1"视图模型，从5个不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。
每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容。
3.在希赛公司的一个财务管理系统，财务部要客户提供…………4.不同的体系结构风格具有各自的特点、优劣和用途。
试对管道-过滤器风格、事件驱动风格、分层系统、C2风格和基于消息总线的风格进行分析比较。
P52-56(1)管道和过滤器特点：@使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；@允许设计者将整个系统的输入输出行为看成是多个过滤器的行为的简单合成；@支持软件重用。
只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；@系统维护和增强系统性能简单。
新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；@允许对一些如吞吐量、死锁等属性的分析；@支持并行执行。
每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行缺点：①通常导致进程成为批处理的结构。
②不适合处理交互的应用。
③因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。
（2）（3）分层系统体系结构有以下优点：第一，支持基于抽象程度递增的系统设计。
这允许设计者可以将一个复杂系统设计按递增的步骤进行分解。
第二，支持功能增强。
因为每层至多和与之相邻的上层和下层交互，所以，改变某层的功能最多只会影响与之相邻的其它两层。
第三，支持重用。
与抽象数据类型一样，只要对相邻层提供同样的接口，每层可以有很多不同的可相互替代的实现方法。
软件体系结构期末大题
软件体系结构期末大题1.基于构件的软件开发的优势是什么？基于构件的软件将软件开发的重点从程序编写转移到了基于已有构件的组装，更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降低了软件开发的费用2.尝试用自己的语言介绍Kruchten的“4+1”模型。
Kruchten 提出了一个"4+1"视图模型，从5个不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。
每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容。
3.在希赛公司的一个财务管理系统，财务部要客户提供…………4.不同的体系结构风格具有各自的特点、优劣和用途。
试对管道-过滤器风格、事件驱动风格、分层系统、C2风格和基于消息总线的风格进行分析比较。
P52-56(1)管道和过滤器特点：@使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；@允许设计者将整个系统的输入输出行为看成是多个过滤器的行为的简单合成；@支持软件重用。
只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；@系统维护和增强系统性能简单。
新的过滤器能够添加到现有系统中来；旧的能够被改进的过滤器替换掉；@允许对一些如吞吐量、死锁等属性的分析；@支持并行执行。
每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行缺点：①一般导致进程成为批处理的结构。
②不适合处理交互的应用。
③因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。
（2）。
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、软件重用是指重复使用已有的软件产品用于开发新的软件系统，以达到提高软件系统的开发质量与效率，降低开发成本的目的。
答案：√依据页码：P42、可重用技术对构件库组织方法要求不仅要支持精确匹配，还要支持相似构件的查找。
答案：√依据页码：P73、超文本组织方法与基于数据库系统的构件库组织方法不同，它基于全文检索技术。
答案：√依据页码：p84、软件体系结构充当一个理解系统构件和它们之间关系的框架，特别是那些始终跨越时间和实现的属性。
答案：√依据页码：P285、构件可以由其他复合构建和原子构件通过连接而成。
（）答案：√依据页码：P376、体系的核心模型由5种元素组成：构建、连接体、配置、端口和角色（）答案：√依据页码：P377、软件体系结构的核心由5种元素组成：构件、连接件、配置端口和角色。
其中，构件、连接件和配置是最基本的元素（）答案：√依据页码：P378、开发视图主要支持系统的功能需求，即系统提供给最终用户的服务（）答案：X依据页码：P32、339、构件、连接件以及配置是体系结构的核心模型最基本的元素（）答案：√根据页码：P3710、HMB风格不支持系统系统自顶向下的层次化分解，因为它的构件比较简单。
答案：×依据页码：P8111、正交软件体系结构由组织层和线索的构件构成。
答案：√依据页码：P7012、基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。
答案：√依据页码：P5313、线索是子系统的特例，它由完成不同层次功能的构建组成，每一条线索完成整个系统中相对独立的一部分功能。
（）答案：√依据页码：P7014、层次系统中支持抽象程度递增的系统设计是设计师可以把一个复杂系统按照递增的步骤进行分解，同时支持功能增强，但是不支持重用。
答案：×参考页码:P5515、相交关系R是一个等价关系。
答案：√16、在软件设计中占据着主导地位的软件体系结构描述方法是图形表达工具。
体系结构蓝图—软件体系结构的4 1视图(中文版)
本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。
是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。
许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的Abowd & Allen、SEI 的Clements。
作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。
Perry 和Wolfe 使用一个精确的公式来表达，该公式由Boehm 做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
我们用由多个视图或视角组成的模型来描述它。
为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图1）：∙逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
个人通讯录Kruchten“4+1”模型
个人通讯录“4+1”视图模型Kruchten“4+1”模型由5个视图构成：逻辑视图：当采用面向对象的设计方法时，逻辑视图即是对象模型。
开发视图：描述软件在开发环境下的静态组织。
进程试图：描述系统的并发和同步方面的设计。
物理视图：描述软件到硬件之间的映射关系，反映系统在分布方面的设计。
场景视图：通过选择出的一些用例对体系结构加以说明，这些用例被称作场景。
1.逻辑视图：便于理解系统设计的结构与组织如图1所示：系统只有一个逻辑视图，该视图以图形方式说明关键的用例实现、子系统、包和类，它们包含了在构架方面具有重要意义的行为。
逻辑视图在每次迭代过程中都会加以改进。
逻辑视图表示了设计模型中在构架方面具有重要意义的部分。
图1 通讯录系统体系结构的逻辑视图2.开发视图：设计满足开发期质量属性的体系结构，如图2所示：图2 通讯录系统体系结构的开发视图3.进程视图：设计满足运行期质量属性的体系结构,如图3所示：●应用层中的线程代表主程序的运行，它直接利用了MFC的主窗口线程。
无论是用户交互，还是串口的数据到达，均采取异步事件的方式处理，杜绝了任何"忙等待"无谓的耗时，也缩短了系统响应时间。
●通讯层有独立的线程控制着"上上下下"的数据，并设置了数据缓冲区，使数据的接收和数据的处理相对独立，从而数据接收不会因暂时的处理忙碌而停滞，增加了系统吞吐量。
●嵌入层的设计中，分别通过时钟中断和RS232口中断来激发相应的处理逻辑，达到轮询和收发数据的目的。
图3 设备调试系统体系结构的进程视图●过程视图侧重于系统的运行特性，主要关注一些非功能性的需求。
●过程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。
它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。
顺序图如下：显示联系人信息如图4：图4 显示联系人信息顺序图4.物理视图：和部署相关的体系结构决策，如图4所示：软件最终要驻留、安装或部署到硬件才能运行，而软件体系结构的物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求, 图4所示的物理体系结构视图表达了设备调试系统软件和硬件的映射关系。
架构蓝图--软件架构 4+1 视图模型(Philippe Kruchten)
架构蓝图--软件架构"4+1" 视图模型---Philippe Kruchten引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。
是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。
许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的Abowd & Allen、SEI 的Clements。
作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。
Perry 和Wolfe 使用一个精确的公式来表达，该公式由Boehm 做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
我们用由多个视图或视角组成的模型来描述它。
为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图1）：∙逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
∙过程视图（Process View），捕捉设计的并发和同步特征。
∙物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
体系结构蓝图—软件体系结构的41视图（中文版）
本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。
是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"（或者说"风险承担人"，USC 的命名）所关注的问题。
许多作者都提及了这个问题：Garlan & Shaw 1、CMU 的 Abowd& Allen、SEI 的Clemen ts。
作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。
架构模型软件架构用来处理软件高层次结构的设计和实施。
它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。
Perry和 Wolfe使用一个精确的公式来表达，该公式由 Boehm做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。
软件体系结构 4+1模型案例
案例教学1：4+1视图方法进行软件体系结构设计要开发出用户满意的软件并不是件容易的事，软件体系结构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。
本文从理解需求种类的复杂性谈起，通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行体系结构设计，从而确保重要的需求一一被满足。
1、呼唤体系结构设计的多重视图方法灵感一闪，就想出了把大象放进冰箱的办法，这自然好。
但希望每个体系结构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。
需要体系结构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。
以工程领域的例子开道吧。
比如设计一座跨江大桥：我们会考虑"连接南北的公路交通"这个"功能需求"，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及"大桥的使用期质量属性"，比如为了"能在湍急的江流中保持稳固"，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，"建造期间的质量属性"也很值得考虑，比如在大桥的设计过程中考虑"施工方便性"的一些措施。
和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所示。
图1 软件需求分类的复杂性2、超市系统案例：理解需求种类的复杂性例子是最好的老师。
为了更好地理解软件需求种类的复杂性，我们来分析一个实际的例子。
在表1中，我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。
表1 超市系统案例：理解需求种类的复杂性简单而言，功能需求就是"软件有什么用，软件需要做什么"。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
到需要表达它的各个视图中 每个体系结构视图必须在一页内完成 清晰地区分出哪些是体系结构视图，哪些
不是
2020/9/18
15
坏描述
所有的线看起来都一样 箭头不代表任何涵义 箭头代表很多涵义 实现与文档冲突 没有图例 太多的必要需求
2020/9/18
16
视图
系统需要多种视图来描述
其中的一小部分是描述体系结构的
2020/9/18
2
假定你是Module Designer
你来开发A2和A3，怎么开始？
2020/9/18
3
假定你是Consultant(顾问)
你是一个请来的顾问，对一个体系结构设 计进行评估。Modifiability和Performance 是重要的体系结构质量因素。
你会询问什么样的信息？
2020/9/18
18
软件体系结构建模的种类
结构模型 框架模型 动态模型 过程模型 功能模型
2020/9/18
19
结构模型
这是一个最直观、最普遍的建模方法。这种方 法以体系结构的构件、连接件和其他概念来刻画 结构，并力图通过结构来反映系统的重要语义内 容，包括系统的配置、约束、隐含的假设条件、 风格、性质等。
研究结构模型的核心是体系结构描述语言。
2020/9/18
20
框架模型
框架模型与结构模型类似，但它不太侧重 描述结构的细节而更侧重于整体的结构。
框架模型主要以一些特殊的问题为目标建 立只针对和适应该问题的结构。
2020/9/18
21
动态模型
动态模型是对结构或框架模型的补充，研 究系统的“大颗粒”的行为性质。例如， 描述系统的重新配置或演化。动态可以指 系统总体结构的配置、建立或拆除通信通 道或计算的过程。
2020/9/18
8
与顾问交流
体系结构的必要需求(driving requirement)是什 么(如，performance, availability, security, modifiability, interoperability)？
各种体系结构视图是如何描述的？
抽象出来什么？ 功能怎样分解？ 功能怎样分配？ 使用什么硬件以及软件怎样布置在硬件上？
让别人理解系统的第一手资料Βιβλιοθήκη 2020/9/187
与Module Designer交流
基本想法是什么？ 我该做什么 (如，实现哪些需求) ？ 我该在哪做 (如，这项功能实现在哪里) ？ 我和谁交互？接口是什么？ 有什么可以重用的代码？ 必须遵从什么约定(质量目标、旧体系/接口、预算
等)？ 有哪些硬性规定(设计、接口、约束等)？
它怎样去符合需求与约束 其他的设计
2020/9/18
13
其他方面
风格/产品线问题
设计可变的尺度 体系结构的那个方面必须不被改变？
管理问题
暗含开发团队的组织结构 体系结构评审情况
其他设计问题
代码重用、标准的运用 风险分析 运作、管理和维护
2020/9/18
14
好描述
线和框有不同的形状/颜色，并有图例说明 用表格总结方案选择等等各种问题 图并不试图去表达很多信息：把信息分散
2020/9/18
22
过程模型 过程模型研究构造系统的步骤和过程。 结构是遵循某些过程脚本的结果。
2020/9/18
23
功能模型
功能模型认为体系结构是由一组功能构件 按层次组成，下层向上层提供服务。
功能模型可以看作是一种特殊的框架模型。
2020/9/18
24
“4十1”模型
Rational公司的Philippe Kruchten在1995年提出了用于体系结构描 述 的 “ 4 十 l” 模 型 。 该 模 型 建 立 在 体 系 结 构 的 Perry ＆ Wolf 定 义 和 Berry Boehm定义的基础上。
采用了哪些体系结构风格？
2020/9/18
9
这是什么？
2020/9/18
10
上图的毛病
很多事情没有说：
组件类型 连接件类型 圆圈和箭头代表什么？ 这种布局的意义是什么？ 为什么CP要放在上层？
只画出方框和线条不是体系结构，只是体 系结构的开始
2020/9/18
11
好的体系结构描述的必要元素
第2章 软件体系结构建模
2020/9/18
1
假定你是Module Designer
你最近加盟一家公司，并被安排在一个新 项目的开发组中。虽然你富有经验，但是 对此项目所涉及的领域还是一个新手。系 统的高层体系结构设计已经完成。
你的老板（项目经理）让你预计你将要完 成的几个模块的开发时间。
你怎么办？
运行时视图/动态视图(组件和连接件)
在高层分解成组件和连接件
代码视图
模块关联和依赖
使用/调用/和…共享数据
文件和目录、工程和编译文件、版本控制
物理视图
把计算单元分配到各个进程或处理器
2020/9/18
17
阅读
Philippe Kruchten, Architectural Blueprints— The “4+1” View Model of Software Architecture, IEEE Software 12 (6), 1995, pp. 42-50
需求陈述
商业环境、产品的背景、领域
描述环境
必须和什么系统交互、外部接口
使用体系结构图
用恰当的线框 简洁的说明
2020/9/18
12
好的体系结构描述的必要元素
考虑实现时的限制
但是仅在它们能影响体系结构设计的范围内
被限定的下层结构、处理器需求
通常包含其他结构图
体系结构设计的原理
2020/9/18
4
假定你是Consultant(顾问)
面对这样的图，你会有什么反应？
2020/9/18
5
假定你是Consultant(顾问)
面对这样的图，你会有什么反应？
2020/9/18
6
体系结构描述方法
软件开发过程中各种角色之间交流设计思 想的媒介
进行上层分析的基础。此基础上可以验证 体系结构设计方案，精炼或改变必要的方 案
Release 6A Segment/Design Specification for the ECS Project, Section 4.4. NASA Report 305-CD-600-001, pages 4-160-185. March 2001 /waisdata/toc/cd30 560001toc.html
不是
2020/9/18
15
坏描述
所有的线看起来都一样 箭头不代表任何涵义 箭头代表很多涵义 实现与文档冲突 没有图例 太多的必要需求
2020/9/18
16
视图
系统需要多种视图来描述
其中的一小部分是描述体系结构的
2020/9/18
2
假定你是Module Designer
你来开发A2和A3，怎么开始？
2020/9/18
3
假定你是Consultant(顾问)
你是一个请来的顾问，对一个体系结构设 计进行评估。Modifiability和Performance 是重要的体系结构质量因素。
你会询问什么样的信息？
2020/9/18
18
软件体系结构建模的种类
结构模型 框架模型 动态模型 过程模型 功能模型
2020/9/18
19
结构模型
这是一个最直观、最普遍的建模方法。这种方 法以体系结构的构件、连接件和其他概念来刻画 结构，并力图通过结构来反映系统的重要语义内 容，包括系统的配置、约束、隐含的假设条件、 风格、性质等。
研究结构模型的核心是体系结构描述语言。
2020/9/18
20
框架模型
框架模型与结构模型类似，但它不太侧重 描述结构的细节而更侧重于整体的结构。
框架模型主要以一些特殊的问题为目标建 立只针对和适应该问题的结构。
2020/9/18
21
动态模型
动态模型是对结构或框架模型的补充，研 究系统的“大颗粒”的行为性质。例如， 描述系统的重新配置或演化。动态可以指 系统总体结构的配置、建立或拆除通信通 道或计算的过程。
2020/9/18
8
与顾问交流
体系结构的必要需求(driving requirement)是什 么(如，performance, availability, security, modifiability, interoperability)？
各种体系结构视图是如何描述的？
抽象出来什么？ 功能怎样分解？ 功能怎样分配？ 使用什么硬件以及软件怎样布置在硬件上？
让别人理解系统的第一手资料Βιβλιοθήκη 2020/9/187
与Module Designer交流
基本想法是什么？ 我该做什么 (如，实现哪些需求) ？ 我该在哪做 (如，这项功能实现在哪里) ？ 我和谁交互？接口是什么？ 有什么可以重用的代码？ 必须遵从什么约定(质量目标、旧体系/接口、预算
等)？ 有哪些硬性规定(设计、接口、约束等)？
它怎样去符合需求与约束 其他的设计
2020/9/18
13
其他方面
风格/产品线问题
设计可变的尺度 体系结构的那个方面必须不被改变？
管理问题
暗含开发团队的组织结构 体系结构评审情况
其他设计问题
代码重用、标准的运用 风险分析 运作、管理和维护
2020/9/18
14
好描述
线和框有不同的形状/颜色，并有图例说明 用表格总结方案选择等等各种问题 图并不试图去表达很多信息：把信息分散
2020/9/18
22
过程模型 过程模型研究构造系统的步骤和过程。 结构是遵循某些过程脚本的结果。
2020/9/18
23
功能模型
功能模型认为体系结构是由一组功能构件 按层次组成，下层向上层提供服务。
功能模型可以看作是一种特殊的框架模型。
2020/9/18
24
“4十1”模型
Rational公司的Philippe Kruchten在1995年提出了用于体系结构描 述 的 “ 4 十 l” 模 型 。 该 模 型 建 立 在 体 系 结 构 的 Perry ＆ Wolf 定 义 和 Berry Boehm定义的基础上。
采用了哪些体系结构风格？
2020/9/18
9
这是什么？
2020/9/18
10
上图的毛病
很多事情没有说：
组件类型 连接件类型 圆圈和箭头代表什么？ 这种布局的意义是什么？ 为什么CP要放在上层？
只画出方框和线条不是体系结构，只是体 系结构的开始
2020/9/18
11
好的体系结构描述的必要元素
第2章 软件体系结构建模
2020/9/18
1
假定你是Module Designer
你最近加盟一家公司，并被安排在一个新 项目的开发组中。虽然你富有经验，但是 对此项目所涉及的领域还是一个新手。系 统的高层体系结构设计已经完成。
你的老板（项目经理）让你预计你将要完 成的几个模块的开发时间。
你怎么办？
运行时视图/动态视图(组件和连接件)
在高层分解成组件和连接件
代码视图
模块关联和依赖
使用/调用/和…共享数据
文件和目录、工程和编译文件、版本控制
物理视图
把计算单元分配到各个进程或处理器
2020/9/18
17
阅读
Philippe Kruchten, Architectural Blueprints— The “4+1” View Model of Software Architecture, IEEE Software 12 (6), 1995, pp. 42-50
需求陈述
商业环境、产品的背景、领域
描述环境
必须和什么系统交互、外部接口
使用体系结构图
用恰当的线框 简洁的说明
2020/9/18
12
好的体系结构描述的必要元素
考虑实现时的限制
但是仅在它们能影响体系结构设计的范围内
被限定的下层结构、处理器需求
通常包含其他结构图
体系结构设计的原理
2020/9/18
4
假定你是Consultant(顾问)
面对这样的图，你会有什么反应？
2020/9/18
5
假定你是Consultant(顾问)
面对这样的图，你会有什么反应？
2020/9/18
6
体系结构描述方法
软件开发过程中各种角色之间交流设计思 想的媒介
进行上层分析的基础。此基础上可以验证 体系结构设计方案，精炼或改变必要的方 案
Release 6A Segment/Design Specification for the ECS Project, Section 4.4. NASA Report 305-CD-600-001, pages 4-160-185. March 2001 /waisdata/toc/cd30 560001toc.html