1.0. 软件生命周期与软件架构概述

34
软件架构设计的一些特点
• 处于软件系统建设的上游
需求分析 架构设计 系统设计 系统开发 测试上线
• • • • •
需要全面考虑多方面的因素 对于同一个问题，可以有多种设计结果 是在各种制约条件下取得的较好折衷方案 科学 + 经验 + 艺术 “系统架构”往往被滥用
35
软件架构的层次
层次
Enterprise Application
• 这些质量属性归根结底要落实到软件构架之上。
10
增量式开发的前提
• 迭代生命周期模型开始逐渐替代传统的瀑布模型，然而要 真正实现其增量式开发的目标，却需要满足若干关键的前 提条件：向已有交付添加新功能非常容易(可扩展)；后续 的增量不会破坏已有的交付，使得迭代退化为返工(健壮)。
• 这些条件最终归结为在大批量的增量开发之前，要构建一 个构架基线，它同时提供可扩展性与健壮性。
28
软件架构师的知识结构
• 业务知识 – 深入了解系统建设的业务需求。 – 了解系统的非功能需求和运行维护需求。 – 了解企业 IT 公共设施、网络环境、外部系统。
29
你知道那些知识？
• MFC，Msf，mof，rup，j2ee，spring，soa，junit， ORM，。net • Mvc，uml，xml，corba，mda，mdd，webservice • Rss，web2。0，ajax，serlet，hibernate • Ioc， aop， • ruby on rails • Rup • Bpel • Workflow engine • LBS • Oracle • CMMI • MQ
• 设计良好的对象可以方便地添加新的行为，而封装性为其 对变化提供免疫力，基于对象的构架在微观上便具有更强 的可扩展性与健壮性。 • 分层(分包、子系统)架构在大粒度上隔离关注面，同样从 宏观上增强了可扩展性与健壮性。
11
健壮性与可扩展性
• 要实现健壮性与可扩展性等质量特性，主要有两个途径— —尽可能降低系统的冗余程度，同时隔离不同的关注面 (实质是高内聚、低耦合，例如：将稳定部分与可变部分 隔离，将用户交互与业务、数据等功能域分离，将功能和 非功能的实施代码分离)。 • 隔离关注面，使得扩展或变更时，对系统的修改局部化， 对其它部分造成的影响被限制在较小范围内，避免出现那 种牵一发而动全身的情形；高内聚的结构也利于聚焦于各 部分的设计适应性上。 • 低冗余，使得即使要变更，变更所触及的部分也尽可能地 少；系统被改动的地方越少当然就越健壮，同时开销也小、 实施也更容易。
• 系统设计中影响深远(构架敏感)的各项最重要决定： 这些决定严重影响系统的实施，一旦作出并被贯彻，其变 更的代价将及其高昂(例如构架的样式、复用策略、开发 中将贯彻的设计原则等)
13
软件构架的意义
• 软件构架的静态方面，其着眼点在于———保持目标系统 的最终交付在结构上的一致性；为分工协作提供划分依据， 并避免结构上的重叠和冗余。 • 软件构架的动态方面，其着眼点在于——保持目标系统在 关键行为实现上的一致性，突出系统的既有风格；同时通 过为各类关键重复问题提供通用解决方案来提高复用度， 避免实施代码的冗余。 • 上述两个方面，共同提供了构造目标系统过程中的健壮性 与可扩展性——大量的功能实现将在这个构架基础上被不 断添加，而同时系统整体上仍然保持既有的一致和完整。
软件架构的设计与开发 用户培训
17
软件体系结构
• 软件体系结构至少有十几种思想流派。 – Zachman框架 – 开放分布式处理 – 领域分析 – Rational4＋1视图模型 – 软件体系结构风格 • 供应商驱动的方案 – Sun Enterprise JavaBeans – MS .Net 体系
软件生命周期与软件架构介绍
软件架构辨析
• 市场体系结构 • 软件架构
2
3
MS e-Gov Architecture Framework
服 务 器 管 理 平 台 统一政务门户支撑平台（SharePoint Portal Server） 统一的管理门户支撑平台 统一的对外门户支撑平台 统一的对内门户支撑平台
Visual Studio .NET
客 户 机 管 理 平 台
统 一 管 理 服 务
..
统一的政务信息交换及系统整合平台 (Biztalk Server) 数据交换，系统整合，业务流程管理，政务网关
协同工作环境 (Exchange Server,LCS, Live Meeting) 邮件服务，即时消息，会议日程，资料库...
9
为什么需要软件构架
• 目标系统总是要面临各种变数，项目组期望系统在发生变 更、部署到新环境中时，仍然保持既有的稳定、可靠和性 能——目标系统应具备一种健壮性。 • 系统的构建要经历一个不断增添新功能、加入新行为的过 程，项目组期望做得比较容易、开销较低，且在此过程中 不存在重大的风险——目标系统应具备一种可扩展。
• 主要环节 – 根据系统主要的应用场景，确定系统概念架构。
33
软件架构设计过程举例
• 调研已有的成功参考架构和相关模式 – 提出系统逻辑架构，包括分层的整体逻辑架构、子系统/模 块组成以及边界划分根据。 – 讨论逻辑架构的依据、优缺点、以及已经考虑和参考的其 它方案。 – 设计相关子架构，包括：数据架构、子系统架构、安全架 构、网络架构等。 – 验证架构设计、确认能够满足业务需求和其他关键指标， 如性能要求、费用限制等。
Biblioteka Baidu
6
市场体系结构的特点
• 面向客户而非面向软件开发者。 • 对于商业产品的特色宣传非常有效，但对开发者远远不够。 • 市场体系结构与开发流程脱节。
7
软件构架的特点
• 好的软件构架满足它们的需求，并富有弹性和基于构件。 • 一个富有弹性的软件构架能够： – 改进可维护性和可扩展性 – 实现经济性显著的可重用度 – 将开发团队成员间的工作清楚地分割开 – 封装对硬件和系统的依赖
各 种 系 统 开 发 环 境
标 准 及 规 范 管 理
基础架构服务(Windows Server) 统一用户管理 Active Directory 政务数据中心 SQL Server 统一安全服务 ISA Server 统一接入及网络管理
4
5
MS Application Reference Architecture
MOM Server SMS Server
电子政务应用系统支撑平台（.NET Framework, COM+） 地 理 信 息 公 众 管 理 应 急 指 挥 决 策 支 持 呼 叫 中 心 社 区 服 务 政 务 大 厅 业 务 系 统 (1) 业 务 系 统 (2) 知 识 管 理 流 程 管 理 项 目 管 理 公 文 系 统
• 这种兼容异质成分的分布式处理，称为开放分布式处理。
21
RM—ODP的元模型体系
• ISO/ITU－T RM－ODP定义的抽象层次(视角)： • 企业视点(Enterprise Viewpoint) – purpose， scope and policies • 信息视点(Information Viewpoint) – semantics of information and information processing • 计算视点(Computational Viewpoint) – functional decomaosition • 工程视点(Engineering Viewpoint) – infrastructure required to support distribution • 技技术视点 (Technology Viewpoint ) – choices of technology for implementation
25
基本理念
• • • • • IT行业的人才结构与软件架构师的定位 软件架构师应掌握的知识体系 软件架构设计的特点、层次、分类 软件架构的主要理论、方向和趋势 软件工厂，实现软件开发的产业化
软件架构师在干什么？
• 思考、思考、再思考 – 深入理解、准确把握建设的业务需求 – 分析所有可见的问题、障碍、风险 – 充分参考已有的成功方案，降低风险 • 交流、讨论、博弈、质疑 – 对构思中的方案不断提出质疑，避免漏洞 – 广泛听取各层面的意见，开拓思路 – 反复质疑、逐步完善已有的设计构思 • 在动手实现之前验证设计方案的正确性
18
Zachman框架
• 来源于IBM • 传统的体系结构，设计为非面向对象。
19
20
开放分布式处理（ODP）
• 构件可以最大程度的进行互操作和重用。 • 对系统和处理方式加以标准化，只是增强软件可操作性和 重用性的一种权宜之计，并不能彻底解决问题。
• 分布式处理：借助计算机网络将分布在不同地点的构件 (对象)组织在一起，进行信息处理。 • 分布式处理中的构件可能由不同的厂商开发、生产，因而 构件之间可能存在不一致的接口；另外，构件之间的通信 也可能使用不同的协议。
30
软件架构师的思维方式
• 基于框架的思维 – 架构设计的层次（Enterprise， Application， etc） – IT 的生命周期（What， Why， Where， How， When， etc） – 成功经验以及方法论的指导
• 合理把握技术细节 – 把握各个层次应有的内容 – 合理忽略不应有的技术细节
22
领域分析
• 是一种支持软件复用的系统的管理过程。 • 将项目专有需求转化为一般的领域需求。 • 通用功能被用来做水平框架和可复用软件体系结构的基础。
23
4＋1视图模型
• 逻辑 实现 进程 部署 • 用例 • 与UML紧密相连
24
软件体系结构风格
• • • • • • • • MVC风格 管道－过滤器风格 客户－服务器风格 层次系统 仓储（数据库和黑板）风格 面向对象风格 基于消息广播且面向图形用户界面的Chiron2风格 基于事件的隐式调用风格
8
为什么需要软件构架
• 最终开发出的目标系统总是由多个组成部分所构成，这种 结构如果没有预先定义，很难保证系统的构建过程能自发 创建出一个一致而满足需求的交付。 • 当前的软件规模已大到需要采用团队开发的模式，多个开 发人员的分工协作，必然依赖于一种对开发内容的合适划 分，以减少相互干扰、缩短工期的关键路径，从而提高开 发效率、加快项目进度－－软件构架无疑是其中最关键的 一类划分，它将被用来计划、管理与执行系统开发的各项 活动。 • 模块/构件化
14
架构的分层
• 业务应用层 (Business Application) – 由应用开发者开发 • 应用框架层 (Application Framework) – 特定领域框架层 – 跨领域框架层
• 基础框架层 (Foundation Framework)
• 操作系统层
15
16
从经济的角度考虑架构
31
软件架构师的思维方式
• 风险管理意识 – 采用成功经验、避免不应有的风险 • 多方位的开放思维 – 多维度、多方向、包容性、避免排他性 – 分析、质疑、抽象、归纳 – 没有绝对好的架构设计，只有相对优秀的方案
32
软件架构设计过程举例
• 应用系统逻辑架构设计 – 目标：提供系统架构方案、满足业务需求、为物理设计提 供依据。
特征
• 关注 整个机构、企业所有 IT 系统的整体能力 • 从整体着眼、与业务紧密相关、与IT 规划相关 • 负责应用系统的架构，奠定系统建设的基础 • 关注系统内部的构成和子系统/模块的分划 • 需要负责与外部相关系统的互联互通 • 根据应用系统的逻辑架构制定相应的技术实现 方式，设计系统的物理架构
27
软件架构师的知识结构
• 软件知识 – 最好要有系统开发全过程经验。 – 对 IT 建设生命周期各个环节有深入了解，包括：系统/ 模块逻辑设计、物理设计、代码开发、项目管理、测试、 发布、运行维护等。 – 深入掌握1-2种主流技术平台上开发系统的方法。 – 了解多种应用系统的结构。 – 了解架构设计领域的主要理论、流派、框架。
12
如何理解软件构架
• 软件系统进行分解的顶层结构，包括其组成元素，元素之 间、元素与外部的关系关注构架的静态方面，即系统大粒 度(宏观)的总体结构(例如分层、子系统的划分等) • 系统中解决各类关键的重复问题的通用解决方案关注构架 的动态方面，侧重于系统内部关键行为的共同特征(已经 包含了微观细节，例如构架机制)