Chapter 3软件架构实践第三版PPT
合集下载
软件系统架构实践课程(PPT 45张)
讲义版权由中培教育所有，未经同意，不得转印
软件产品线的双生命周期模型
领域工程 领域分析 领域需求模型 领域设计 领域体系结构 领域实现 领域构件
领 域 需 求
应 用 需 求
应用工程 应用需求分析 有、分析 应用系统设计 应用系统实现
应 用 系 统
讲义版权由中培教育所有，未经同意，不得转印
（三）基于产品线的平台架构设计
1、产品线定义
2、产品线基本活动
3、产品线生命周期模型 4、产品线的组织结构 5、产品线的优缺点 6、产品管理模型 7、基于产品线的架构开发方法ADM
讲义版权由中培教育所有，未经同意，不得转印
软件产品线的基本活动
软件产品线包括核心资源开发、利用核心资源的 项目开发以及在这两部分中所需要的技术协调和 组织管理 软件产品线开发活动
软件产品线的基本活动
软件项目开发活动
▲项目实际需求 ▲产品线范围 ▲核心资源 ▲开发计划 软件项目开发
技术协调 组织管理
▲项目 1 ▲项目 2 …… ▲项目 n
讲义版权由中培教育所有，未经同意，不得转印
软件产品线的基本活动
软件产品线工程与其它复用技术相比，主 要存在以下两方面的差异：
软件产品线的双生命周期模型
应用工程是在领域工程的基础上开发软件项目的 过程 在软件产品线中，应用工程包括应用需求分析 、应用系统设计和应用系统实现3个阶段 在领域工程和应用工程的相应阶段之间，存在着 纵向连接线，其含义是：产品线领域工程指导应 用工程的实施 应用工程的结果可以反馈给领域工程，促进核心 资源的建设，因此，整个软件产品线是一个互相 迭代和相互完善的过程
软件工程导论 第3章.ppt
结构化分析方法就是面向数据流自顶向下逐步求精 进行需求分析的方法。通过可行性研究已经得出了 目标系统的高层数据流图，需求分析的目标之一就 是把数据流和数据存储定义到元素级。为了达到这 个目标，通常从数据流图的输出端着手分析，这是 因为系统的基本功能是产生这些输出，输出数据决 定了系统必须具有的最基本的组成元素。
为了解决这些问题，往往需要向用户和其他有关人 员请教，他们的回答使分析员对目标系统的认识更 深入更具体了，系统中更多的数据元素被划分出来 了，更多的算法被搞清楚了。通常把分析过程中得 到的有关数据元素的信息记录在数据字典中，把对 算法的简明描述记录在IPO图(见3.7节)中。通过分析 而补充的数据流、数据存储和处理，应该添加到数 据流图的适当位置上。
一旦得出了意见一致的列表，就把与会者分成更小 的小组，每个小组的工作目标是为每张列表中的项 目制定小型规格说明。小型规格说明是对列表中包 含的单词或短语的准确说明。
7. 逆向需求
逆向需求说明软件系统不应该做什么。理论上有无 限多个逆向需求，我们应该仅选取能澄清真实需求 且可消除可能发生的误解的那些逆向需求。
8. 将来可能提出的要求
应该明确地列出那些虽然不属于当前系统开发范畴， 但是据分析将来很可能会提出来的要求。这样做的 目的是，在设计过程中对系统将来可能的扩充和修 改预做准备，以便一旦确实需要时能比较容易地进 行这种扩充和修改。
在展示了每个人针对某个议题的列表之后，大家共 同创建一张组合列表。在组合列表中消去了冗余项， 加入了在展示过程中产生的新想法，但是并不删除 任何实质性内容。在针对每个议题的组合列表都建 立起来之后，由协调人主持讨论这些列表。组合列 表将被缩短、加长或重新措辞，以便更准确地描述 将被开发的产品。讨论的目标是，针对每个议题(对 象、服务、约束和性能)都创建出一张意见一致的列 表。
软件体系结构3数据流体系结构DataFlowArchitectures-PPT精品文档
2019/3/22
©
8
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 数据流系统的结构是显而易见的
体系结构风格帮助软件工程师 推断软件体系结构的质量
2019/3/22
©
2
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 具有已经被熟知的特性，并且可以复用
2019/3/22
©
3
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 这些组件的拓扑分布
软件体系结构Chap03_风格(下)ppt精选课件
.
16
• HMB风格基于层次消息总线、支持构件的分布和并发， 构件之间通过消息总线进行通信；
• 消息总线是系统的连接件，负责消息的分派、传递、 过滤及处理结果的返回；
• 各个构件挂接在消息总线上，向总线登记感兴趣的消 息类型；构件发送的消息由总线传送到其他构件，处 理结果也由总线返回；
• 不要求各个构件具有相同的地址空间或局限在同一台 机器上，可较好地刻画分布式并发系统。
–构件收到消息后，根据当前所处状态对消息 进行响应，并可能导致状态的变迁；
–复合构件是更简单的子构件通过局部消息总 线连接而成。
2020/4/25
.
19
3.5.2 HMB的构件接口
• HMB风格的构件接口的特点：
–降低构件之间的耦合：构件只对消息本身感兴趣， 不关心消息如何产生；切断构件之间的直接联系；
–层次异构(Hierachical Heterogeneity)：各构件 和连接件内部采用不同风格。
2020/4/25
2020/4/25
.
28
• 解决A、B不匹配的方法： –按照B的形式重写A，即将A的形成改变成B的 形式； –公布A的形式的抽象化信息，即开放API；
–数据传输过程中从A的形式转变到B的形式； –通过协商，A和B达成一个统一的形式； –使B成为支持多种形式； –为B提供进口/出口转换器：独立程序或系统
服务：消息登记 消息分派 消息传递 消息过滤
消息总线的结构
.
22
3.5.4 HMB的构件静态结构
• HMB风格支持自顶向下的层次化分解，复合构 件由简单子构件构成；
• 子构件通过复合构件内部的消息总线连接，各 层次的消息总线在逻辑功能上一致；
Chapter 2 软件架构实践第三版PPT
– Modifiability: Assign responsibilities to elements so that the majority of changes to the system will affect a small number of those elements.
– Security: Manage and protect inter-element communication and control which elements are allowed to access which information; you may also need to introduce specialized elements (such as an authorization mechanism).
1. An architecture will inhibit or enable a system’s driving quality attributes. 2. The decisions made in an architecture allow you to reason about and manage
change as the system evolves. 3. The analysis of an architecture enables early prediction of a system’s qualities. 4. A documented architecture enhances communication among stakeholders. 5. The architecture is a carrier of the earliest and hence most fundamental,
– Security: Manage and protect inter-element communication and control which elements are allowed to access which information; you may also need to introduce specialized elements (such as an authorization mechanism).
1. An architecture will inhibit or enable a system’s driving quality attributes. 2. The decisions made in an architecture allow you to reason about and manage
change as the system evolves. 3. The analysis of an architecture enables early prediction of a system’s qualities. 4. A documented architecture enhances communication among stakeholders. 5. The architecture is a carrier of the earliest and hence most fundamental,
华南理工高英《软件架构理论及实践》第3章
第3章 软件体系结构风格 3.2 经典软件体系结构风格
面向对象的风格有如下3个特点： • 封装：对象具有信息隐藏特性。对象负责维持本身的 内部变量，其内部结构对其他对象不可见，对它的所有访 问都是通过方法调用完成的。这有利于对它进行修改。 • 继承：继承是指从具有通用特征的对象开始，逐步定 义更具体的对象。这样，当需要更具体的对象时，可以在 继承一个已定义好的所有特征的基础上，再加入其它定义。 • 多态：多态是指不同类型的对象可以对相同的激励适 当做出不同响应。
第3章 软件体系结构风格 ◇ 定义
3.1 软件体系结构风格概述
软件体系结构风格是描述某一特定应用领域中系统组 织方式的惯用模式。
体系结构风格定义了一个系统家族，即一个体系结构 定义一个词汇表和一组约束。词汇表中包含一些构件和 连接件类型，而这组约束指出系统是如何将这些构件和 连接件组合起来的。
体系结构风格反映了领域中众多系统所共有的结构和 语义特性，并指导如何将各个模块和子系统有效地组织 成一个完整的系统。
（4）域转换器，它可以辅助解决构件之间的不兼容 性，例如消息的名称、参数类型、参数顺序的失配问题。
第3章 软件体系结构风格 ◇ 产生背景
3.3 客户/服务器风格
◎ 在集中式计算技术时代广泛使用的是大型机/小型机 计算模型。它是通过一台物理上与宿主机相连接的非智 能终端来实现宿主机上的应用程序。
• 编辑器和变量监视器为调试器的断点事 件注册
• 遇到断点，调试器发布断点，系统调用 编辑器和变量监视器
第3章 软件体系结构风格 3.2 经典软件体系结构风格 ◇ 基于事件的隐式调用的优点
◎ 为软件重用提供了强大的支持。当需要将一个构 件加入现存系统中时，只需将它注册到系统的事件中。 ◎ 为改进系统带来了方便。当用一个构件代替另一 个构件时，不会影响到其它构件的接口。
全套电子课件：软件工程-理论与实践(第3版)
40多年来，软件工程率已，经保证历软了件四质个量重的要关发键是展“阶软段件：过
程”，是软件开发和维护中的管理和
1.第一代软件工程 支—持传能力统，的逐软步件形工成程软件过程工程。
2.第二代软件工程 — 对象工程
3.第三代软件工程 — 过程工程
4.第四代软件工程 — 构件工程
90起年代，基于构件（Component）
螺旋模型将开发过程 分为几个螺旋周期，每 个螺旋周期可分为4个工 作步骤： 第一，确定目标、方案 和限制条件； 第二，评估方案、标识 风险和解决风险； 第三，开发确认产品； 第四，计划下一周期工 作。
6.智能模型(intelligent model)
也称为基于知识的软件开发模型，是知识工程 与软件工程相结合的软件开发模型。
软件工程是一门新兴的边缘学科,涉及的学科多， 研究的范围广，研究的主要内容有以下几方面：
软件开发方法、技术 软件开发工具及环境 软件管理技术 软件规范（国际规范）
} 软件开发技术 } 软件管理技术
１.２ 软件工程过程
为了克服软件危机，人们从其他产业的工业 化生产得到启示，于是在68年北大西洋公约的软 件可靠性会议（NATO）上，首次提出了“软件工 程”的概念。提出了在软件生产中采用工程化的 方法，采用一系列科学的、现代化的方法技术来 开发软件。这种工程化的思想贯穿到软件开发和 维护的全过程。
2. 增量模型(incremental model)
增量模型是一种非整体开发的模型。是一种进 化式的开发过程。
根据增量的方式和形式的不同，分为： 基于瀑布模型的渐增模型 基于原型的快速原型模型 该模型具有较大的灵活性，适合于软件需求不 明确、设计方案有一定风险的软件项目。
增量模型和瀑布模型之间的本质区别是什么？
程”，是软件开发和维护中的管理和
1.第一代软件工程 支—持传能力统，的逐软步件形工成程软件过程工程。
2.第二代软件工程 — 对象工程
3.第三代软件工程 — 过程工程
4.第四代软件工程 — 构件工程
90起年代，基于构件（Component）
螺旋模型将开发过程 分为几个螺旋周期，每 个螺旋周期可分为4个工 作步骤： 第一，确定目标、方案 和限制条件； 第二，评估方案、标识 风险和解决风险； 第三，开发确认产品； 第四，计划下一周期工 作。
6.智能模型(intelligent model)
也称为基于知识的软件开发模型，是知识工程 与软件工程相结合的软件开发模型。
软件工程是一门新兴的边缘学科,涉及的学科多， 研究的范围广，研究的主要内容有以下几方面：
软件开发方法、技术 软件开发工具及环境 软件管理技术 软件规范（国际规范）
} 软件开发技术 } 软件管理技术
１.２ 软件工程过程
为了克服软件危机，人们从其他产业的工业 化生产得到启示，于是在68年北大西洋公约的软 件可靠性会议（NATO）上，首次提出了“软件工 程”的概念。提出了在软件生产中采用工程化的 方法，采用一系列科学的、现代化的方法技术来 开发软件。这种工程化的思想贯穿到软件开发和 维护的全过程。
2. 增量模型(incremental model)
增量模型是一种非整体开发的模型。是一种进 化式的开发过程。
根据增量的方式和形式的不同，分为： 基于瀑布模型的渐增模型 基于原型的快速原型模型 该模型具有较大的灵活性，适合于软件需求不 明确、设计方案有一定风险的软件项目。
增量模型和瀑布模型之间的本质区别是什么？
软件项目管理案例教程(第3版) 教学课件 ppt 作者 韩万江 课程总结
MED燃尽图：7：13
60
chapter__15
MED第一迭代任务燃尽图-7月18
61
chapter__15
MED：跟踪甘特图
62
MED：项目总体情况分析
63
挣值分析方法
chapter__15
需求分析过程审计
64
chapter__12
设计产品评审
65
chapter__15
路线图：辅助计划执行控制
F4 分类广告
F4.1与产品有关 F4.2与产品无关 F4.3匹配 F4.4招标
F5 协会/学会
F5.1编辑 F5.2浏览 F5.3管理
F6 医院管理
F6.1编辑 F6.2浏览 F6.3检索 F6.4管理
F7 Email管理
F8 Chat管理
F9 护士排班表
F10 联机帮助
个人注册
在线产品 组织注册 产品状态管理 协会/学会注册 F2.2浏览 登录 按厂商浏览 F1.2管理
北京邮电大学
hanwanjiang@
韩万江
软件项目管理
1
课程总结
软件项目管理过程路线图
2
项目初始
3
路线图：项目确立
4
立项：医疗信息商务平台
5
chapter__1
甲方招标书
6
乙方项目分析
7
乙方标书
8
招标与竞标
9
chapter__1
双方合同
10
项目章程
11
chapter__1
路线图：配置管理计划
37
配置管理活动
38
1. 2. 3. 4.
5.
配置项标识、跟踪 配置管理环境建立 基线变更管理 配置审计 配置状态统计
软件体系结构ppt精选课件
基于规则系统
• 调用和返回系统
数据中心系统（知识库）
• 主程序和子程序
• 面向对象系统
• 多级分层
数据库
超文本系统
黑板
• 独立构件
• 通讯进程
• 事件系统
精选ppt
24
2.1体系结构风格
• 7种通用的风格
• 管道和过滤器、对象、隐式调用、层、知识库、解释器和过程调用。
精选ppt
25
2.2管道过滤器（pipes &filters）
软件体系结构
精选ppt
1
1概述
• 我们要学的这个是什么玩意？
• 我们为什么要学这个玩意？
• 我们将来会怎么干？
• 其他人是怎么玩的？
精选ppt
2
1概述
• 软件工程师需要一种更好的视角来理解软件，并试图找到一种新的方法来
构建更复杂的大型软件系统
• SA (software architecture)
软件系统“可扩展”的前提条件是“保持结构稳定”，否则软件难
以按计划开发出来，稳定性是使系统能够持续发展的基础。所以稳
定性和可扩展性都是体系结构设计的要素。
• •如果每次变化都导致体系结构发生大的变动，那简直就是“伤筋
动骨”，这样的体系结构无疑是败笔之作。（例如房屋装修）
精选ppt
21
• 复用就是指“重复利用已经存在的东西”。被复用的对象可以是有
套共享的，语义丰富的词典，它由软件系统的习
惯用语，模式，软件系统组织结构风格组成。
• 通过识别一个管道过滤器体系结构风格的实例，
一个软件工程师传达了这样的事实：这个系统的
主要功能就是进行数据流的转换，系统的主要功
• 调用和返回系统
数据中心系统（知识库）
• 主程序和子程序
• 面向对象系统
• 多级分层
数据库
超文本系统
黑板
• 独立构件
• 通讯进程
• 事件系统
精选ppt
24
2.1体系结构风格
• 7种通用的风格
• 管道和过滤器、对象、隐式调用、层、知识库、解释器和过程调用。
精选ppt
25
2.2管道过滤器（pipes &filters）
软件体系结构
精选ppt
1
1概述
• 我们要学的这个是什么玩意？
• 我们为什么要学这个玩意？
• 我们将来会怎么干？
• 其他人是怎么玩的？
精选ppt
2
1概述
• 软件工程师需要一种更好的视角来理解软件，并试图找到一种新的方法来
构建更复杂的大型软件系统
• SA (software architecture)
软件系统“可扩展”的前提条件是“保持结构稳定”，否则软件难
以按计划开发出来，稳定性是使系统能够持续发展的基础。所以稳
定性和可扩展性都是体系结构设计的要素。
• •如果每次变化都导致体系结构发生大的变动，那简直就是“伤筋
动骨”，这样的体系结构无疑是败笔之作。（例如房屋装修）
精选ppt
21
• 复用就是指“重复利用已经存在的东西”。被复用的对象可以是有
套共享的，语义丰富的词典，它由软件系统的习
惯用语，模式，软件系统组织结构风格组成。
• 通过识别一个管道过滤器体系结构风格的实例，
一个软件工程师传达了这样的事实：这个系统的
主要功能就是进行数据流的转换，系统的主要功
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
– Standard industry practices – Software engineering techniques prevalent in the architect’s professional community.
• Today’s information systems are web-based, objectoriented, service-oriented, mobility-aware, cloudbased, social-networking-friendly.
– “Why do you want this system to have a really fast response time?” – This differentiate the produeveloping organization capture market share.
– Technical. What technical role does the software architecture play in the system or systems of which it’s a part? – Project life cycle. How does a software architecture relate to the other phases of a software development life cycle? – Business. How does the presence of a software architecture affect an organization’s business environment? – Professional. What is the role of a software architect in an organization or a development project?
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Architecture and Business Goals
• Systems are created to satisfy the business goals of one or more organizations.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Technical Context
• The most important technical context factor is the set of quality attributes that the architecture can help to achieve. • The architecture’s current technical environment is also an important factor.
• • • • • • • • Architecture in a Technical Context Architecture in a Project Life-Cycle Context Architecture in a Business Context Architecture in a Professional Context Stakeholders How Is Architecture Influenced? What Do Architectures Influence? Summary
Chapter 3: The Many Contexts of Software Architecture
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Chapter Outline
• Some business goals will not show up in the form of requirements. • Still other business goals have no effect on the architecture whatsoever.
– A business goal to lower costs might be realized by asking employees to work from home, or turn the office thermostats down in the winter, or using less paper in the printers.
• Architects need to understand who the vested organizations are and what their goals are. Many of these goals will have a profound influence on the architecture.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Business Context
• Architectures and systems are not constructed frivolously. • They serve some business purposes. • These purposes may change over time.
– It wasn’t always so. – It won’t be so ten years from now.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Architecture Activities
• All of these processes include design among their obligations. • Architecture is a special kind of design, so architecture finds a home in each one. • No matter the software development process, there are activities involved in creating a software architecture, using that architecture to realize a complete design, and then implementing or managing the evolution of a target system or application:
– – – – – – – 1. Making a business case for the system 2. Understanding the architecturally significant requirements 3. Creating or selecting the architecture 4. Documenting and communicating the architecture 5. Analyzing or evaluating the architecture 6. Implementing and testing the system based on the architecture 7. Ensuring that the implementation conforms to the architecture
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Architecture and Business Goals
• Every quality attribute—such as a user-visible response time or platform flexibility or ironclad security or any of a dozen other needs—should originate from some higher purpose that can be described in terms of added value.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Contexts of Software Architecture
• Sometimes we consider software architecture the center of the universe! • Here, though, we put it in its place relative to four contexts:
– – – – Waterfall Iterative Agile Model-driven development
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Project Life-cycle Context
• Today’s information systems are web-based, objectoriented, service-oriented, mobility-aware, cloudbased, social-networking-friendly.
– “Why do you want this system to have a really fast response time?” – This differentiate the produeveloping organization capture market share.
– Technical. What technical role does the software architecture play in the system or systems of which it’s a part? – Project life cycle. How does a software architecture relate to the other phases of a software development life cycle? – Business. How does the presence of a software architecture affect an organization’s business environment? – Professional. What is the role of a software architect in an organization or a development project?
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Architecture and Business Goals
• Systems are created to satisfy the business goals of one or more organizations.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Technical Context
• The most important technical context factor is the set of quality attributes that the architecture can help to achieve. • The architecture’s current technical environment is also an important factor.
• • • • • • • • Architecture in a Technical Context Architecture in a Project Life-Cycle Context Architecture in a Business Context Architecture in a Professional Context Stakeholders How Is Architecture Influenced? What Do Architectures Influence? Summary
Chapter 3: The Many Contexts of Software Architecture
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Chapter Outline
• Some business goals will not show up in the form of requirements. • Still other business goals have no effect on the architecture whatsoever.
– A business goal to lower costs might be realized by asking employees to work from home, or turn the office thermostats down in the winter, or using less paper in the printers.
• Architects need to understand who the vested organizations are and what their goals are. Many of these goals will have a profound influence on the architecture.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Business Context
• Architectures and systems are not constructed frivolously. • They serve some business purposes. • These purposes may change over time.
– It wasn’t always so. – It won’t be so ten years from now.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Architecture Activities
• All of these processes include design among their obligations. • Architecture is a special kind of design, so architecture finds a home in each one. • No matter the software development process, there are activities involved in creating a software architecture, using that architecture to realize a complete design, and then implementing or managing the evolution of a target system or application:
– – – – – – – 1. Making a business case for the system 2. Understanding the architecturally significant requirements 3. Creating or selecting the architecture 4. Documenting and communicating the architecture 5. Analyzing or evaluating the architecture 6. Implementing and testing the system based on the architecture 7. Ensuring that the implementation conforms to the architecture
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Architecture and Business Goals
• Every quality attribute—such as a user-visible response time or platform flexibility or ironclad security or any of a dozen other needs—should originate from some higher purpose that can be described in terms of added value.
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Contexts of Software Architecture
• Sometimes we consider software architecture the center of the universe! • Here, though, we put it in its place relative to four contexts:
– – – – Waterfall Iterative Agile Model-driven development
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Project Life-cycle Context