系统软件架构及应用

驱动因素
软件质量属性-系统品质关注点 • 在现实系统中，在决定系统的成功或失败的因素 中，满足非功能需求往往比满足功能性需求更为 重要。
• Robert Charette
• 架构指明了功能性必须以何种品质交付，才能被 系统的相关人员所接受，系统的结果包含这些人 的既定利益。
• John Klein & David Weiss
架构驱动设计的2种哲学
• 问题1：盲目追求新技术带来很大的风险 • 问题2：忽略约束条件导致设计时过于理想化的运行环境无法支持 • 问题3：忽略质量属性导致任务工作量评估时考虑实现功能忽略其他 工作量
软件架构师对架构驱动因素的分析
驱动架构设计的因素1-软件功能 • 关键软件业务需求（关键业务场景）
• 在于晶纯眼里，架构是有生命的，是不断变化的。因此，她认为：设 计架构不能只想着要考虑到所以的问题，设计出一个能够包容所有可 能问题的架构，这几乎是不可完成的任务。任务变化是绝对的，架构 总会需要修改，关键问题在于何时改？一定不能在系统问题频出、已 经不来不及补救的时候才去考虑修改，而是在潜伏的问题逐渐露出端 倪之前展开入进去。因此，架构是需要监控的。通过各项指标。在最 适当的时候对架构进行最适当的重构。以满足变化的需求。
常用软件架构视图类型
• • • • • • •
逻辑视图 开发视图 部署视图 进程视图 场景视图
数据视图 实现视图
Logical Views MOdel
• 消费者：客户/用户/开发组织管理者 • 视角：系统的功能元素，以及它们接口，职责交 互 • 主要元素：系统，子系统，功能模块，子功能模 块，接口 • 用途：开发组织划分，成本/进度的评估
Implement Views MOdel
• 消费者：开发相关人员/测试人员/实施人员 • 视角：系统交付物结构形式和相关实施规范 • 主要元素：
1：创建可交付物的形式（网页，DLL，可执行文件，源码） 2：开发编程过程中必须遵守的相关规范和指南
• 用途：
软件架构视图最佳实践
• • • •
最佳实践1-架构建模的方式 最佳实践2-结合实际项目情况选择合适的视图 最佳实践3-多视图可以组合 最佳实践4-多视图并行设计
驱动架构设计的因素2-系统质量属性
驱动架构设计的因素2-商业质量属性
驱动架构设计的因素3-系统受制于的约束
实际架构过程中质量属性面临的问题
• 对质量属性的定义不具有可操作性，称某 个系统是可修改的没有意义。 • 质量属性是否实现不可度量
软件架构因素-质量分析
• 软件架构因素分析中定义质量需求时推荐使用“ 质量场景”，因为它定义了可度量的（或者只是 可以观察的）响应，并且因此能够加以验证，诸 如：系统容易修改/系统高性能，这样含混描述很 难具有实用性。
WLS Process View
• WLS executes all request using execute threads • Threads are allocated as:
– Reader threads,for handing network traffic – Execute threads,for processing user requests
• SEI 软件架构设计
实际工作之中架构师面临的经典难题
输出混乱 不能提供清晰的架构文 档……
驱动因素不清楚 不能深入全面理解 架构驱动因素……
驱动因素
架构设计过程
架构结果
架构应用
思维过程乱 不能系统有序进行 思维……
应用混乱 设计人员和编程人 员不知道如何应用架 构……
设计过程概论
架构是有生命的-架构需要溶化的
驱动因素不清楚 不能深入全面理解 架构驱动因素……
驱动因素
架构设计过程
架构结果
架构应用
思维过程乱 不能系统有序进行 思维……
应用混乱 设计人员和编程人 员不知道如何应用架 构……
软件架构的定义
• 什么是架构？如果你问五个人不同的人， 可能会得到五种不同的回答。
• ——Ivar Jacobson 《AOSD中文版》
软件架构
实际工作之中架构师面临的经典难题
输出混乱 不能提供清晰的架构文 档……
驱动因素不清楚 不能深入全面理解 架构驱动因素……
驱动因素
架构设计过程
架构结果
架构应用
思维过程乱 不能系统有序进行 思维……wenku.baidu.com
应用混乱 设计人员和编程人 员不知道如何应用架 构……
实际工作之中架构师面临的经典难题
输出混乱 不能提供清晰的架构文 档……
Abstract This article presents a model for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. This use of multiple views allows to address separately the concerns of the various ‘stakeholders’ of the architecture: end-user, developers, systems engineers, project managers, etc., and to handle separately the functional and non functional requirements. Each of the five views is described, together with a notation to capture it. The views are designed using an architecture-centered, scenariodriven, iterative development process. Keywords: software architecture, view, object-oriented design, software development process Introduction We all have seen many books and articles where one diagram attempts to capture the gist of the architecture of a system. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear that their authors have struggled hard to represent more on one blueprint than it can actually express. Are the boxes representing running programs? Or chunks of source code? Or physical computers? Or merely
Scenarios Views MOdel
• 消费者：设计和开发人员 • 视角：概括了架构上最重要的场景（最典型和最 有风险）及其非功能性需求，能过这些场景的实 现，阐明了架构的广度或众多架构元素运行的方 式 • 主要元素： • 用途：
•
重要场景：1、风险用例 2、典型用例 3、业务级别高
Data Views MOdel
Software Architecture View(软件架构视图)
• 单一的视图无法完整的表达架构，因此需要具备完整的视 图集 • 软件系统架构视图是从特定的视角出发，专注于该视角系 统的结构，模块划分，基本组件职责和主要的控制协作接 口。同时架构视图应该解释为什么架构是这样的。 • 架构视图四要素
– – – – 图示化的主要元素和玩素之间的关系 具有明确的图例，定义和说明元素 每个元素具备明确的接口和行为规范 设计原理和设计决策的信息
Architectural Blueprints—The “4+1” View Model of Software Architecture
Philippe Kruchten Rational Software Corp.
“4+1 Views” Model
功能需求
质量属性 可扩展性 可维护性 ……
质量属性 易用性 性能 ……
安装部署要 求
业务其他观点
• • • • SEI（模块视图，组件和连接件视图，分配视图） 西门子4种视图（概念，模块，代码，执行视图） 美国国防部C4ISR架构视图（操作，系统架构，技术） RM-OOP（企业视图，信息视图，计算视图，工程视图）
• 消费者：系统集成商/系统运维人员 • 视角：系统逻辑组件到物理节点的物理部署和节 点之间的物理网络配置 • 主要元素：物理节点以及节点的通信 • 用途：
Process Views MOdel
• • • •
消费者：性能优化/开发相关人员 视角：系统运行时的线程/进程的情况 主要元素：系统进程/线程以及处理队列等 用途：
• Adding Views
– Security View – Interface View – Business Process View
最佳实践3-多视图可以组合
• 根据实际项目情况进行考虑视图组合
最佳实践4-多视图并行设计
• 多视图的，是分而治之（总架构师负责协调保持 一致性） • 多视图可以指导不同的团队并行思维
Incoming Requests
R R R R R R R
Reader Thread Pool
Execute Queue
R R R R R
Execute Thread Pool
R
多线程架构模式
• • • • Half-Sync/Half-Async Leader/Floolwers Active Object Monitor Object
最佳实践1-架构建模的方式
• 非标准 • 标准UML建模 • 文档描述
最佳实践2-结合实际项目情况选择合适的视图
• Not all systems require all views:
– Single process:drop process view – Very Small program:drop Deployment View
实际工作之中架构师面临的经典难题
输出混乱 不能提供清晰的架构文 档……
驱动因素不清楚 不能深入全面理解 架构驱动因素……
驱动因素
架构设计过程
架构结果
架构应用
思维过程乱 不能系统有序进行 思维……
应用混乱 设计人员和编程人 员不知道如何应用架 构……
驱动因素
• 软件架构驱动因素 • 软件系统质量属性定义和策略
– 1、Business-Critical（关键业务）。 – 2、High Impact（高影响）。
• 功能需求的语境整理关键功能需求识别变化点和 最具可能性的进化点
– 系统变化点-当前现有系统和需求中变化之处。例如：必须支持多 种资费策略 – 系统进化点-现有需要中不存在，但是可能在将来发生推测性的变 化点。比如：目前打印报表临时使用Excel文件导出。将来可能使 用专业的报表工具。
• 消费者：数据架构师和开发人员 • 视角：系统数据模型以及数据存储/存取等 • 主要元素：
1：系统的核心实现模型以及相应的数据储模型和存储方式 2：系统的数据存取相关策略 3：系统核心的数据流
• 用途：
数据模型
• 模型的选择会影响最终产生系统的灵活性和可重 用性。
– Martin Fowler<分析模式>
• 很多人都试图给“架构”下定义，而这些 定义本身却很难统一。
• ——Martin Fowler 《企业应用架构模式》
软件架构定义——决策过程角度和结果组成角度
• 动词/过程观点 Booch、Rumbeugh和 Jacobaon的定义
• 架构是一系列重要决策的集合
• 名词/结构观点 SEI定义
• 程序或者计算机系统的软件架构应该是该系统一个 （或多个）结构它由软件元素，元素的外部可见属性 及它们之间的关系组成 • 软件架构={结构,……} • 结构={元素，外部可见属性，关系}
Development Views MOdel
• 消费者：开发相关人员/测试人员 • 视角：系统如何开发实现 • 主要元素：描述系统的层，分区，包，架构，系 统通用服务，业务通用服务，类和接口，系统平 台和相关基础框架 • 用途：指导开发组织设计和开发实现
Physical Views MOdel