4 1体系结构视图
4+1模型案例
案例教学1：4+1视图方法进行软件体系结构设计要开发出用户满意的软件并不是件容易的事，软件体系结构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。
本文从理解需求种类的复杂性谈起，通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行体系结构设计，从而确保重要的需求一一被满足。
1、呼唤体系结构设计的多重视图方法灵感一闪，就想出了把大象放进冰箱的办法，这自然好。
但希望每个体系结构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。
需要体系结构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。
以工程领域的例子开道吧。
比如设计一座跨江大桥：我们会考虑"连接南北的公路交通"这个"功能需求"，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及"大桥的使用期质量属性"，比如为了"能在湍急的江流中保持稳固"，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，"建造期间的质量属性"也很值得考虑，比如在大桥的设计过程中考虑"施工方便性"的一些措施。
和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所示。
图1 软件需求分类的复杂性2、超市系统案例：理解需求种类的复杂性例子是最好的老师。
为了更好地理解软件需求种类的复杂性，我们来分析一个实际的例子。
在表1中，我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。
表1 超市系统案例：理解需求种类的复杂性简单而言，功能需求就是"软件有什么用，软件需要做什么"。
软件体系结构知识总结
第一部分-------填空，选择，判断1．软件工程三个要素：方法、工具和过程2．软件元素：程序代码、测试用例、设计文档、设计过程、需求分析文档3．构件分类：关键字分类刻画分类法和超文本组织法4．软件体系结构技术反战经历四个阶段（1）无体系结构设计阶段----以汇编语言进行小规模应用程序开发（2）萌芽阶段-----以控制流图和数据流图构成软件结构为特征（3）初期阶段-----出现了从不同侧面描述系统的结构模型，UML（4）高级阶段-----描述系统的高层抽象结构，出现“4+1”模型5．软件体系结构模型：结构模型、框架模型、动态模型、过程模型和功能模型。
6．“4+1”视图模型从五个不同的视角，包括逻辑试图，进程试图，物理视图，开发视图和场景视图来描述软件体系结构。
逻辑视图主要支持系统的功能需求，是系统提供给最终用户的服务。
通过抽象，封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图；开发视图也称模块视图，主要侧重于软件模块的组织和管理，主要考虑软件内部的需求，如软件开发的容易性、软件的重用等，通过系统输入输出关系的模型图和子系统图来描述,提供给编程人员的；进程视图侧重于系统的运行特性，主要关注非功能性的需求，如系统的性能和可用性。
进程视图强调并发性、分布性、系统集成性和容错能力管道和过滤器风格、客户/服务器风格等适合进程视图，提供给系统集成人员的；物理视图主要考虑如何把软件映射到硬件上，它通常考虑系统性能、规模、可靠性等，解决系统拓扑结构、系统安装、通信问题,提供给系统工程人员的。
而场景是那些重要系统活动的抽象，它使四个视图有机联系起来，是最重要的需求抽象，它可以帮助设计者找到系统结构的构件和他们之间的作用关系。
总之，逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
软件体系结构的核心模型由五中元素组成：构件、连接件、配置、端口和角色。
7. 软件体系结构的核心模型由五中元素组成：构件、连接件、配置、端口和角色。
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
过程视图的体系结构：过程分解
软件被分为独立的任务的集合。每个任务是一个独立的控制线程，可 以在一个处理节点上独立单独调度。因此可以将任务分为主任务和辅 任务。主任务是需要单独解决的体系结构元素。辅任务是由于实现原 因而在本地加入的附加任务(缓冲，超时，等等)，例如可以将它们实 现为轻量级的线程。主任务通过一套完善定义的任务间通信机制进行 通信：同步的或异步的基于消息的通信服务、远程过程调用、时间广 播等。不应当假设通信中的主任务处于同一个过程中或处在同一个处 理节点上。辅任务的通信可以采用共享内存的方式或其他双方约定的 方式。 基于过程体系结构设计图，可以估计出消息流和过程负荷。
体系结构蓝图—软件体系结构的+视图(中文版)
体系结构蓝图—软件体系结构的+视图(中文版)————————————————————————————————作者：————————————————————————————————日期：本文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，并且能够独立地处理功能性和非功能性需求。
本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示方法。
这些视图使用以架构为中心的、场景驱动以及迭代开发过程来进行设计。
引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。
通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。
方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。
是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。
有时架构并不能解决所有"客户"（或者说"风险承担人"，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个视图结合在⼀起才能反映系统软件架构的全部内容。
软件体系结构试题库(软件工程)
软件体系结构试题库（软件工程）一、判断题4、软件体系结构充当一个理解系统构件和它们之间关系的框架，特别是那些始终跨越时间和实现的属性。
答案：√6、体系的核心模型由5种元素组成：构建、连接体、配置、端口和角色（）答案：√7、软件体系结构的核心由5种元素组成：构件、连接件、配置端口和角色。
其中，构件、连接件和配置是最基本的元素（）答案：√8、开发视图主要支持系统的功能需求，即系统提供给最终用户的服务（）答案：某9、构件、连接件以及配置是体系结构的核心模型最基本的元素（）答案：√10、HMB风格不支持系统系统自顶向下的层次化分解，因为它的构件比较简单。
答案：某11、正交软件体系结构由组织层和线索的构件构成。
答案：√12、基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。
答案：√13、线索是子系统的特例，它由完成不同层次功能的构建组成，每一条线索完成整个系统中相对独立的一部分功能。
（）答案：√15、相交关系R是一个等价关系。
答案：√16、在软件设计中占据着主导地位的软件体系结构描述方法是图形表达工具。
答案：√17、Rapide是一种可执行的ADL，其目的在于通过定义并模拟基于事件的行为对分布式同步系统建模。
答案：某18、体系结构设计是整个软件生命周期中关键的一环，一般在需求分析之后，软件设计之前进行。
答案：√19、基于软构件的系统描述语言是较好的一种以构件为单位的软件系统描述语言。
答案：√20、需求语言与ADL的区别在于后者描述的是问题空间，而前者则扎根于解空间中。
答案：某21、基于构件的动态系统结构模型分为三层，风别是应用层、中间层、和体系结构层。
答案：√22、ADL提供了一种形式化机制来描述软件体系结构，大多数ADL不进描述系统的静态结构，也支持对体系结构动态性的描述（）答案：某23、基于构件的动态系统结构模型分为应用层，中间层和体系结构层。
答案：√24、2000年世界计算机大会提出，软件体系结构中最为重要的三个研究方向是：体系结构风格，静态体系结构和动态体系结构。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
@收款机
本班出纳员 开始时间 结束时间 @登录
售货 结帐
商品一览表
商品目录
检索 种类增删
超市销 售管理
销售事 收件款人
购物清单 应收款 ……
销售计划 入帐
商品
编号 名称 单价 架上数量 下限
售出 补充 价格更新
系统
特价商
(特征层)
开品始日期
结束日期
计量商品
*单价 计量单位 计价方式
*售出 *补充 *价格更新
例：栈的状态/服务对照表
空
半满
满
压入 可执行 可执行 不可执行
弹出 不可执行 可执行 可执行
例：栈状态转换图 创建
空
弹出(报错)
压入
弹出(已空)
压入(未满) 弹出(未空)
半满
压入(已满)
弹出
压入
满
(报错)
•定义服务
对象行为分类 发现服务的策略 审查与调整 识别对象的主动行为 服务的详细说明(服务解释、消息协议、 消息发送、约束条件、服务流程图)
帐户 …… ……
……
ATM …… ……
……
银行 …… ……
……
出纳员 …… ……
……
…… …… ……
……
步骤3：定义结构与连接
• 初步确定关联
•对应于描述性动词或动词短语 •需求陈述中隐含 •根据问题域知识得出
• 筛选
• 完善
• 分析标识对象之间的关系
•对象之间的分类关系：一般-特殊结构 •对象之间的组成关系：整体-部分结构 •对象之间的静态联系：实例连接 •对象之间的动态关系：消息连接
▪ 与系统发生作用的其它系统和必要
的设备可作为候选的类及对象; 如： 打印机等 (分析阶段可不把与实现有关的计算 机部件作为候选的类及对象)
▪ 系统必须观测、记忆的与时间有关的
事件可作为候选的类及对象;
如：建立帐户的日期 打开一个帐户等
▪ 与系统发生交互的人及系统必须保留
其信息的人,可作为候选的类及对象;
从一般类发现特殊类
公司职员
姓名 身分证号码
股份 工资 ……
？ …… ？
举例：用例模型中添加通信关联的指向 执行者启动用例
订货
客户
系统启动用例
客户
获得订单的状态
由客户或者系统 启动用例
客户
获得订单的状态
Yourdon的OOA方法
以类与对象图及对象状态图为辅助工 具，建立问题域的五层模型.
OOA模型被划分为五个层次 (五个视图)
OOA的结构
Class &object layer (类及对象层)
用例模型 分析模型 设计模型 实现模型
取款
取款
取款
取款
用例的分析、设计和实现
用例模型
分析模型
取款
出纳员接口 吐钞器 帐户 提取
三种不同构造型的分析类
≪实体类≫ ≪边界类≫ ≪控制类≫
：实体对象一般是系统中长效且持久
的对象
:边界对象处理系统与环境之间的通信，
建立系统与参与者间的交互模型
:控制对象执行与特定用例有关的行为，
分析 模型 出纳员接口
吐钞器
设计 模型
显示
吐钞传感器
提取 帐户
提取
帐户
数字键盘
吐钞输送器 储户管理
永久类
读卡机
点钞机
事务管理 帐户管理
《分析子系统》 ATM接口
出纳员接口
《分析子系统》 控制逻辑
《分析子系统》 帐户管理
提取
吐钞器
转帐
帐户
出纳员
存入
有三个子系统的分析模型,在影射到设计模型 之前需要把分析类型分解到各个分析子系统中
Attribute layer (属性层) Service layer (服务层)
Structure layer (结构层)
Subject layer (主题层)
属性 服务
类的边界 实例的边界
实例连接 消息连接
主题
分析阶段由五个活动组成： (1) 标识类及对象 (2) 标识结构 (3) 标识主题 (4) 定义属性及实例连接 (5) 定义服务及消息连接
如：柜员、储户等
▪ 这些人所属的组织单位，可作为候选
的类及对象;
如：总行、分行等
▪ 系统必须记忆、且不在问题域约束中
的顺序操作过程(为了指导人机交互) 可作为候选的类及对象;
如：柜员事务、远程事务等。 其中属性是操作过程名,操作特权及操作 步骤的描述;
▪ 系统需了解掌握的物理位置、办公
地点等可作为候选的类及对象;
帐册
前班节余 销售事件表 收入累计 上交款 本班节余
接班 计帐 报帐交班
@上级系统接口
帐目目册
@消息发送
查帐 报帐 价格更新 种类增删
供货员
缺货登记表 缺货登记 供货
建立数据字典
为所有模型实体准备一个数 据字典, 精确描述每一个对象 类,包括:
•成员 •约束 •关联、属性、操作
对象字典举例：
类名 父类 提供的服务 需要的服务
建立系统与参与者间的交互模型
帐户
出纳员接口
提取
分析类型之间的关系
用例模型
分析模型
取款
出纳员接口 吐钞器
提取 帐户
每个用例都有一个说明如何执行用例的出纳员接口 吐钞器 提取 帐户
银行储户标识自己
检验标识符
银行储户说明帐户 和要提取的钱数. 系统从帐户中提取 并给付此笔钱款
4+1体系结构视图
最终用户
功能
逻辑视图
程序员
软件管理
实现视图
设计人员 /测试人员
用例视图
行为
过程视图 展开视图
系统集成人员 性能
可扩展性 吞吐量
系统工程师 系统拓扑结构
交付、安装 通信
举例：自动取款机(ATM)系统的用例模型 用例模型捕获、表示系统的功能性需求
取款
存款
银行储户
在不同帐户间转帐
用例的分析、设计和实现
如：ATM机器、帐户等
(2)审查和筛选,
▪ 舍弃无用的类 ▪ 对象的精简
•只有一个属性的对象 •只有一个服务的对象
▪ 推迟到OOD考虑的对象
@收款机
销售事 件
帐册
商品一览表
商品
@上级系统接口
超市销
售管理 系统
特价商 品
(对象层)
计量商品
供货员
步骤2： 定义属性与服务 •定义属性 •定义服务
对象的状态与状态转换图
五个步骤常根据需要交叉进行
步骤1：识别类与对象
(1)发现对象
主要策略:
▪ 考虑问题域
• 人员 • 组织 • 物品 • 设备 • 事件
•表格结构
▪ 考虑系统边界
• 人员 • 设备 • 外系统
▪ 考虑系统责任
▪ 问题域描述中的名词,往往是候选的
及对象;根据问题域结构可提取候选 的类及对象;
例: 银行储蓄管理系统
提取
给付
提取
分析模型形成系统体系结构
分析模型
出纳员接口
银行储户
提取 吐钞器
提取管理
帐户
采用分析模型重新描述取款用例
分析模型中参与多个用例实现的类
用例模型
分析模型
取款
吐钞器 提取
在不同帐户间转帐
银行 储户
存款
出纳员接口 转帐 帐户 出纳员 存入
用例模型捕获、表示系统的功能性需求
设计模型中的设计类与分析模型中的分析类