第一章
1.1.1 系统架构师的概念
现代信息系统“架构”三要素：构件、模式、规划；规划是架构的基石，也是这三个贡献中最重要的。
架构本质上存在两个层次：概念层，物理层。
1.2.1 系统架构师的定义
负责 理解、管理 并最终确认和评估 非功能性系统需求，给出开发规范，搭建系统实现的核心架构，对整个软件架构、关键构建、接口 进行总体设计 并澄清关键技术细节。 主要着眼于系统的“技术实现”，同时还要考虑系统的“组织协调”。
要对所属的开发团队有足够的了解，能够评估该开发团队实现特定的 功能需求目标和资源代价。
1.2.2 系统架构师技术素质
对软件工程标准规范有良好的把握。
1.2.3 系统架构师管理素质
系统架构师是一个高效工作团队的创建者，必须尽可能使所有团队成员的想法一致，为一个项目订制 清晰的、强制性的、有元件的目标 作为整个团队的动力； 必须提供特定的 方法和模型 作为理想的技术解决方案；
必须避免 犹豫，必须具备及时解决技术问题的 紧迫感和自信心。
1.2.4 系统架构师 与 其他团队角色 的 协调
系统分析师，需求分析，技术实现
系统架构师，系统设计，基于环境和资源的系统技术实现
项目管理师，资源组织，资源实现
由于 职位角度出发产生冲突制约，不可能很好地给出 开发规范，搭建系统实现的 核心架构，并澄清技术细节，扫清主要难点。
所以 把架构师定位在 项目管理师与系统分析师 之间，为团队规划清晰的目标。
对于大型企业或项目，如果一人承担多个角色，往往容易发生顾此失彼的现象。
1.3 系统架构师知识结构
需要从大量互相冲突 的系统方法和工具中 区分出 哪些是有效的，那些是无效的。
1.4 从开发人员到架构师
总结自己的架构模式，深入行业总结规律。
第三章
19xx年，意大利学者 朗高（G·Longo）提出：信息是反映事物的形式、关系相差别的东西，它包含在事物的差异之中，而不在事物本身。
目前，关于信息 比较科学和统一的定义是：信息是对客观事物 变化和特征 的反映，是客观事物之间 互相作用和联系 的表征，是客观事物经过 感知或认知后 的再现。
3.1.2 信息的特征
1、客观性：反映了事物的 运动状态和方式，既事实性。
2、普遍性：信息无所不在。
3、无限性：事物及其变化是 无限多样的。
4、动态性：随着时间变化而变化。
5、依附性：不能完全脱离物质而独立存在。
6、变换性：可以用不同的载体 以不同的方法来负载。
7、传递性：时间上的传递 即存储；空间上的传递 即 转移或扩散。
8、层次性：信息可以分为 战略级、管理级、操作级。
9、系统性：可以形成与现实世界相对应的信息系统。
3.1.3 信息化的定义
信息化 Informationalization，是以信息资源开发利用为核心，以网络技术、通讯技术等高科技技术为依托的 一种新技术扩散的过程。
3.1.4 信息化的内容
1、信息资源的开发利用
2、信息网络的全面覆盖，计算机网络、电信网、电视网等，逐步实现三网合一。
3、信息技术的广泛应用，这是信息化的基础。
4、信息产业的大力发展
5、信息化人才的培养
6、信息化政策和标准规范建设
基于web的架构是 松散耦合的，优势在于能够在不同的网络及操作系统中运行；以服务器为中心，客户端瘦小、简单，容易在运行时实现自动升级。
3.3 信息化的典型应用
电子政务的内容
1、政府与政府 G2G
2、政府对企事业 G2B
3、政府对居民 G2C
4、企业对政府 B2G
5、居民对政府 C2G
3.3.3 企业资源规划的结构和功能
物料需求计划 MRP，物料单系统 BOM，制造资源计划 MRPII。
1、ERP 的概念
企业的所有资源包括三大流：物流、资金流、信息流。
ERP是建立在信息技术基础上，全面地集成了企业的所有资源信息，并为企业提供决策、计划、控制、经营业绩评估 的全方位 和 系统化的管理平台。
ERP是一种管理理论和管理思想，不仅仅是信息系统。
1.生产预测
市场需求是企业生存的基础，ERP中首先需要对市场进行较准确的预测，预测主要用于计划。 常用的预测方法有：德尔菲方法、移动平移法、指数平滑法、非线性最小二乘曲线拟合法。
2.销售管理（计划）
销售管理从其计划角度来看，属于最高层计划的范畴，是企业最重要的决策层计划之一。
3.经营计划（生产计划大纲）
4.主生产计划
5.物料需求计划
根据主生产计划 对最终产品的 需求数量和交货期，推导出构成产品的 零部件及材料的 需求数量和需求时期，再导出自制零部件的制作订单下达日期和采购件的采购订单发送日期。
6.能力需求计划 CRP
通过分析比较 MRP 的需求和企业现有生产力，及早发现 能力瓶颈所在。
7.车间作业计划 PAC
将零部件的生产计划以订单的形式下达给适当的车间，属于 ERP 执行层计划。当前主流的车间作业计划模式是 JIT模式。
8.采购与库存管理
是ERP的基本模块，从采购订单产生至货物受到的全过程进行 组织、实施、控制，库存管理IM 对企业物料的 进、出、存 进行管理。
9.质量与设备管理
全面质量管理 TQM，对企业的全过程进行质量管理，而且明确指出执行质量职能是企业全体人员的责任。
设备管理对 设备寿命周期内的 所有设备 物资运动形态和价值运动形态 进行综合管理。
10.财务管理
以货币的形式 反映和监督 企业的日常经济活动，并对数据进行分类、汇总，为企业管理和决策提供必要的信息支持。
11.ERP 有关扩展应用模块
客户关系管理、分销资源管理、供应链管理、电子商务 等。
3、ERP 的功能
ERP 为企业提供的功能是 多层面的 全方位的。
3.3.4 客户关系管理在企业的应用
1、CRM 的概念
提供的信息要有利于更好地理解客户；
流程管理要为客户提供高效、适当的体验；
提供那些构件强有力关系、提高客户忠诚度的体验。
CRM 的核心思想就是 以客户为中心，
从传统的“以产品为中心”的经营理念解放出来，通过富有意义的交流沟通，理解并影响客户行为，最终实现客户 保留、客户忠诚、客户创利 的目的。
将客户信息 转化为 积极的客户关系 的 反复循环过程。
市场竞争，客户资源逐渐减少，市场主动权让给客户，了解市场和客户 真实需要的基础上 提供令其满意的 产品和服务。
客户能根据自己的需求 量身定做 合适自己需要的产品和服务。
客户信息是 客户关系管理 的基础。
更低成本、更高效率 地 满足客户的需求，与客户建立起 基于学习性关系基础，最大程度提高客户满意度、忠诚度。
销售自动化 SFA
功能：日历和日程安排、联系和客户管理、佣金管理、商业机会、传递渠道管理、销售管理、建议的生产和管理、定价、区域划分、费用报告 等。
产品目录和价格、购买记录、服务记录、存货情况、促销文本资料、信用记录。 SFA 应用往往集成 电子邮件、办公软件 等 其它各种标准应用。
营销自动化 MA
集成客户商业智能信息、产品信息、“营销百科全书”等 信息资源。
CRM 中，客户服务与支持主要是通过 呼叫中心 和 互联网 来实现，在满足客户的个性化要求方面，高速度、准确性、高效率 来完成客户服务人员的各种要求。
当把客户服务与支持功能同销售、营销功能比较好地结合起来时，就能为企业提供很多机会。 客户服务与支持的内容应包括：客户关怀；纠纷、订货、订单跟踪；现场服务；问题及解决方法数据库；维修行为安排调度；服务协议合同；服务请求管理 等。
商业智能是指利用 数据挖掘、知识发现 等 技术 分析和挖掘 结构化的、面向特定领域的 存储与数据仓库的信息，帮用户 认清发展趋势、识别数据模式、获取职能决策支持、得出结论。
智能的范围：客户、产品、服务、竞争者 等。
收集和分析市场、销售、服务 和整个企业的各类信息，对客户进行全方位的了解，从而理顺企业资源与客户需求之间的关系。
CRM 尚未有成型的理论出现
对市场的设定、跟踪、分析总结。
呼叫中心支持由合作的硬件厂商参与并提供全套设备，而不仅仅是提供支持呼叫中心的应用软件。
对移动设备的支持。
决策者所掌握的信息完全，能更及时地做出决策。
不管客户由何种渠道与企业联系，与客户的互动都应该是 无缝的、统一的、高效的。 需要任命一名来自企业的 系统管理员，作为内部系统专家。
经特殊调整的系统 必须 伴随技术培训。
由于数据转换过程工作量极大，因此要精确预测该过程的时间表几乎是不可能的。 “培训者”必须接受由软件供应商 进行的培训，称为新系统专家。
对所有用户的 正规培训，用户必须认识到 使用新系统的 即时和明显好处。
对系统的持续支持要求公司配备至少一名全职的内部系统管理员，可保证技术上自给自足的灵活性，CRM 系统的支持是艰巨的工作。
为保证系统带来所希望的益处，在将其推广到所有用户之前一定要加以测试。
间接电子商务，商品是有形货物。
直接电子商务，商品是无形的货物或服务，双方越过地理界限直接进行交易。
3.3.7 供应链管理
供应链是企业赖以生存的商业循环系统，企业供应链可以耗费企业高达 25% 的运营成本。 从供应商开始，经由制造商、分销商、零售商，直到最终客户的全要素、全过程的集成化管理模式。
正向 推动式 运作模式是 以生产为中心；逆向 拉动式 运作模式是 以用户为中心；两种不同的运作模式 适用于不同市场环境。
第四章
4.1 软件开发方法
4.1.1 软件开发生命周期
传统的软件生命期 是指软件产品 从形成概念（构思）开始，经过定义、开发、使用、维护、废弃，的全过程。
可以把软件生命期划分为 软件定义、软件开发、软件运行与维护，三个阶段。
1、软件定义时期
1.问题定义，目标系统“是什么”，系统的定位以及范围。
2.可行性研究，技术可行性、经济可行性、操作可行性、社会可行性。
3.需求分析，确定软件系统的功能需求、性能需求、运行环境的约束，写出需求规格说明书、软件系统测试大纲、用户手册概要。
充分理解用户的需求，并以书面形式写出规格说明书，这是以后软件设计和验收的依据；用户也许很难 一次性 说清楚系统应该做什么。
系统分析员、软件开发人员、用户，共同完成，逐步细化、一致化、完全化 等。 软件需求规格说明 SRS，内容可以有 系统（或子系统）名称、功能描述、接口、基本数据结构、性能、设计需求、开发标准、验收原则 等。
2、软件开发时期
软件开发时期就是软件的设计与实现，概要设计、详细设计、编码、测试 等。
概要设计是在软件需求规格说明的基础上，建立系统的 总体结构（含子系统的划分） 和 模块间的关系，定义功能模块及各功能模块之间的关系。
详细设计对概要设计 产生的功能模块 逐步细化，包括 算法与结构、数据分布、数据组织、模块间接口信息、用户界面 等，写出详细设计报告。
测试可分成 单元测试、集成测试、确认测试、系统测试 等。通常把编码和测试 称为系统的实现。
3、软件运行和维护
软件维护就是尽可能地延长软件的寿命，没有维护的价值时，宣告退役，软件的生命结束。
4.1.2 软件开发模型
软件生存周期模型 又称 软件开发模型 或 软件过程模型，模型的特点是 简单化，是软件开发实际过程的 抽象与概括。
为软件工程管理提供 里程碑和进度表，为软件开发过程提供 原则和方法。软件过程有各种各样的模型。
1、瀑布型
瀑布型的特点是 因果关系紧密相连，前一个阶段工作的结果是后一个阶段工作的输入，前一个阶段的错漏会隐蔽地带到后一个阶段，每一个阶段工作完成后，都要进行审查和确认， 它的出现有利于人员的组织管理，有利于软件开发方法和工具的研究。
2、原型模型
根据用户提出的软件系统的定义，快速地开发一个原型，包含目标系统的关键问题和反映目标系统的大致面貌。
三种途径：
利用模拟软件系统的人机界面和人机交互方式。
真正开发一个原型。
找来一个或几个正在运行的类似软件进行比较。
实际工作中，由于各种原因，大多数原型都废弃不用，仅仅把建立原型的过程 当作帮助定义软件需要的一种手段。
注意：
用户对系统模糊不清，无法准确回答目标系统的需求。
经过对原型若干次修改，应该收敛到目标范围内，否则可能会失败。
对大型软件来说，如果没有现成的，就不应该考虑用原型法。
3、螺旋模型
是生命周期模型与原型模型的一个结合，分成多个阶段，每一个阶段都由4部分组成：
1.目标设定，指定对过程和产品的约束，并且制订详细的管理计划。
2.风险分析，制订解决办法。
3.开发和有效性验证，即开发软件产品。
4.评审，确定是否需要进入螺线的下一次回路。
增加一周，软件系统就生成一个新版本，系统应该尽快地收敛到用户允许或可以接受的目标范围内。
该模型支持大型软件开发，适用于面向规格说明、面向过程、面向对象 的软件开发方法，也适用于几种开发方法的组合。
4、基于可重用构件的模型
把软件工程项目所创建的 构件 不断地积累和存储在一个构件库中，系统将依赖构件的健壮性。
5、基于面向对象的模型
构件重用是非常重要的技术之一。一方面进行构件开发，另一方面进行需求开发，快速建立 OOA、OOD 原型，由重用构件组装而成，甚至通过组装可重用的子系统而创建更大的系统。
6、基于四代技术的原型
四代语言 完全不用变成方式来构造应用系统，而是利用一些生成器。
与通常的软件工程环境或计算机辅助软件工程不同，只侧重于支持应用软件开发过程中的 设计阶段和实现阶段，特别是支持界面以及与界面有关的处理过程。
4.1.3 敏捷方法
1、敏捷方法的特点
敏捷方法是“适应性”而非“预设性”的，重型方法在计划制定完成后拒绝变化，而敏捷方法则欢迎变化。
“面向人的”而非“面向过程的”
传统的软件开发方法的基本思路一般是 只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利构造。
但是，一些设计错误只能在编码和测试时才能发现。
传统正规开发方法是 个体不重要，角色才是重要的，尽量减少人的因素对开发过程的影响，但是敏捷方法正好相反。
管理人员已经脱离实际开发活动相当长的时间了，如此设计出来的开发过程是难以为开发人员所接受的。
只有在第一线的开发人员才能真正掌握和理解开发过程中的技术细节，所以技术方面的决定必须由他们来做出。
敏捷方法特别强调 相关人员之间的信息交流。因为项目失败的原因最终都可以追溯到信息没有及时准确地传递到应该接受它的人。
特别提倡直接的面对面交流，交流成本远远低于文档的交流。
按照高内聚、松散耦合的原则 将项目划分为若干个小组，以增加沟通。
2、敏捷方法的核心思想
1.适应性型，利用变化来发展。
2.以人为本，在无过程控制和过于严格繁琐的过程控制中取得一种平衡，以保证软件的质量。
3.迭代增量式的开发过程，发行版本小型化，根据客户需求的 优先级和开发风险，制订版本发行计划。
3、敏捷方法的含义及其特征
重型方法注重开发文档的完备和充分性；而敏捷方法认为最根本的文档应该是源码。
4、敏捷方法的适用范围
实际上，满足工程设计标准的唯一文档是源代码清单。
敏捷方法比较适合需求变化比较大 或者 开发前期对需求不是很清晰的项目。
敏捷方法对设计者、开发者、客户 之间的有效沟通和及时反馈要求比较高，不易在开发团队比较庞大的项目中实施。
5、敏捷方法的主要内容
四个核心价值观：沟通、简单、反馈、勇气。
简单：只要满足当前功能需求，不做假象设计。
勇气：用于抉择，用于实践，用于重构。
12条实践规则：简单设计、测试驱动、代码重构、结对编程、继续集成、现场客户、开发版本小型化、系统隐喻、代码集体所有制、规划策略、规范代码、40小时工作机制。
6、主要敏捷方法简介
极限编程
水晶系列方法
开放式源码，任何人发现Bug都可以将补丁发给维护者。
SCRUM
Coad的功用驱动开发方法：短时迭代阶段 和 可见可用的功能，一个迭代周期一般为两周，编程人员分为 类程序员、首席程序员。
ASD方法，猜测、合作、学习。
4.1.4 RUP
RUP把软件开发生命周期划分为多个循环（cycle），每个cycle生成产品的一个新版本，每个cycle依次由4个连续阶段（phase）组成：
初始：定义最终产品视图和业务模型，并确定系统范围。
细化：制定工作计划及资源要求。
构造。
移交。
迭代并不是重复地做相同的事，而是针对不同用例细化和实现，每一个迭代都是一个完整的开发过程。
每个阶段结束前有一个里程碑（milestone）评估该阶段的工作。如果未能通过该里程碑的评估，则决策者应该做出决定，是取消该项目还是继续做该阶段的工作。
RUP中的核心概念
角色（Role），who的问题，某个人或一个小组的行为与职责。
活动（Activity），how的问题，是一个有明确目的的独立工作单元。
制品（Artifact），what的问题，是活动生成、创建、修改 第一段信息。
工作流（Workflow），when的问题，每个工作流产生一些有价值的产品，并显示了角色之间的关系。
RUP的特点
RUP是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。
用例驱动：需求分析、设计、实现、测试，都是用例驱动的。
以体系结构为中心：刻画了系统的整体设计，去掉了细节部分，突出了系统的重要特征。 不依赖于具体语言，是软件设计过程的一个层次。
体系结构层次的设计问题包括：总体组织和全局控制、通讯协议、同步、数据存取、给设计元素分配特定功能、设计元素的组织、物理分布、系统的伸缩性、性能 等。
一个系统不可能在所有特性上都达到最优，对于一个系统，不同人员所关心的内容也是不一样的，对于不同类型的人员，只需提供这类人员关心的视图即可。
分析和测试人员关心用例图，最终用户关心逻辑视图，程序员关心实现视图，系统工程师关心部署视图。
RUB强调采用迭代和增量的方法来开发软件，每次迭代中，之考虑系统的一部分需求，每次增加一些新的功能实现。
好处：
早期就可以对关键的、影响大的风险进行处理。
可以提出一个软件体系结构来指导开发。
处理不可避免的需求变更。
可以较早地得到一个可运行的系统，鼓舞开发团队的士气，增强项目成功的信心。 更有效工作的开发过程。
没有一个项目会使用RUP中所有的东西，用用RUP时要裁剪，裁剪步骤：
1.确定本项目 需要哪些工作流。
2.确定每个工作流要产出哪些制品。
3.确定四个阶段之间（初始阶段、细化阶段、构造阶段、移交阶段）如何演进。
4.确定每个阶段内迭代计划。
5.规划工作流内部结构。
4.1.5 软件系统工具
按软件过程活动将软件工具分为 软件开发工具、软件维护工具、软件管理和软件支持工具。 软件开发工具有：需求分析工具、设计工具、编码与排错工具、测试工具 等。
需求分析工具，生成完整的、清晰的、一致的功能规范。功能规范是软件开发者和用户间的契约，也是软件设计者的和实现者的依据。正确、完整 表达清晰的、无歧义的。
需求分析工具分为 基于自然语言或图形描述的工具，基于形式化需求定义语言的工具。
项目管理工具：项目的 计划、调度、通信、成本估算、资源分配、质量控制等。
4.2 需求管理
需求 最终文档 经过评审批准后，则定义了需求基线 Baseline；构筑了 功能需求 和 非功能需求 的一个 约定Agreement。约定是需求开发和需求管理之间的桥梁。
需求管理是一个 对系统 需求变更、了解和控制 的过程，初始需求导出的同时 就启动了需求管理规划。
4.2.1 需求管理原则
过程能力成熟度模型 CMM，指导软件过程改进，5个成熟级别，6个关键过程域KPA。 一旦需求 文档化了，开发组和有关团队 需要评审文档。发现问题应与客户或者其他需求源协商解决。软件开发计划是基于 已确认的需求。
绝不要承诺 任何 无法实现的事。
关键处理领域 通过版本控制和变更控制 来管理需求文档。确保与新的需求保持一致。
4.2.2 需求规格说明的版本控制
版本控制是管理需求的一个必要方面，必须统一确定需求文档的每一个版本，当需求发生变更时，及时通知所有涉及人员。
为了尽量减少困惑、冲突、误传，应该仅允许指定的人员来更新需求。
清楚地区分草稿和文档定稿版本。
4.2.4 需求变更
迟到的 需求变更 会对已进行的工作产生非常大的影响。
如果每一个建议的需求变更都采用，该项目将可能永远无法完成。
需求文档应该 精确描述 要交付的产品。
项目负责人 在信息充分的条件下 做出决策。
变更成本计算 应该包括 需求文档的修改、系统修改的设计、实现的成本。
变更控制过程 并不是给变更设置障碍，相反，它是一个渠道和过滤器，确保采纳最合适的变更，使变更产生的负面影响降到最低，变更过程应该做成文档。
绝不能 删除或者修改 变更请求的 原始文档。
变更控制委员会 只要能决定合适的人做正确的事就足够了，在保证权威性的前提下 应尽可能精简人员。
对每个变更 权衡利弊 做出决定。
“利”包括 节省资金 或 额外收入、客户满意度、竞争优势、减少上市时间；
“弊”是指 增加开发费用、推迟交付日期、产品质量下降、减少功能、用户不满意。 变更总是有代价的，即使 拒绝的变更 也因为决策行为 而耗费资源。
接受了重要的需求变更时，为了适应变更情况 要与管理部门和客户重新协商约定。推迟交货时间、增加人手、推迟实现尚未实现的较低优先级的需求，或质量上进行折中。 要是不能获得一些约定的调整，应该把面临的风险写进风险计划中。
4.2.5 需求跟踪
需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档 等。
跟踪能力（联系）链（traceability link）是优秀需求规格说明书的一个特征，确保软件需求规格说明包括所有客户需求。
跟踪能力联系链 记录了单个需求之间的 父层、互连、依赖 的关系。
不必拥有所有种类的跟踪能力联系链，要根据具体情况调整。
4.2.6 需求变更的代价和风险
只有在知道变更成本后 才能做出理智的选择，一个表面上很简单的变更 也可能转变成很复杂的局面。
影响分析 确定对现有系统做出是修改或者抛弃的决定，创建新系统以及评估每个任务的工作量，进行 影响分析的能力 依赖于 跟踪能力、数据的质量、完整性。
4.3 开发管理
1、范围
可交付物、架设、约束条件 的基础上准备详细的项目范围说明书，是项目成功的关键。
2、时间
进度安排的准确程度可能比成本估计的准确程度更重要。对于成本估计的偏差，可以靠重新定价或大量的销售来弥补成本的增加，
如果进度计划不能得到实施，则会导致市场机会的丧失或用户不满意，而且会使成本增加。 工作分解结构 Work Breakdown Structure WBS
4.3.2 配置管理 文档管理
1、配置管理
配置项 Configuration Item CI，
属于产品组成部分的工作成果，如 需求文档、设计文档、源代码、测试用例 等。
属于项目管理和机构支撑过程域 产生的文档，如 工作计划、项目质量报告、项目跟踪报告 等。
每个配置项的主要属性有 名称、标识符、文件状态、版本、作者、日期 等。
2、文档管理
文档是影响软件可维护性的决定因素，使用过程中必然会经受多次修改，所以文档比程序代码更重要。
用户文档：主要描述系统功能和使用方法。
系统文档：描述系统设计、实现、测试 等各方面内容。
软件文档应该满足下述要求：
1.如何使用
2.怎样安装 和 管理
3.需求 和 设计
4.实现 和 测试
说明用户操作错误时 应该怎样恢复和重新启动。
4.3.3 软件开发的质量与风险
1、软件质量
IOS9000 对 项目质量 的定义：一组固有特性 满足需求的 程度。
质量 与 范围、成本 和 时间，是项目成功的关键因素，通过范围管理 转换隐含需求为项目需求。
质量低 说明产品或服务存在问题，而低等级的产品或服务 不一定存在问题，二者概念不同。
2、软件开发风险
认识不足 或者 没有足够的力量加以控制。
了解、掌握 风险的来源、性质、发生规律，进而施行有效的管理。
或然性、不确定性、涉及到某种选择时，才成为有风险，以上三个是风险定义的必要条件，不是充分条件，具有不确定性的事件不一定是风险。
4.4.1 结构化分析与设计
结构程序设计 较流行的定义为：采用自顶向下 逐步求精 的设计方法 和 单入口单出口的控制构件。
自顶向下逐步求精的方法是：先整体后局部，先抽象后具体，一般具有较清晰的层次。
仅使用单入口单出口的控制构件，具有良好的结构特征。
采用结构程序设计，可能会多占用一些时间和空间资源，这也是那些反对从高级语言中排除GOTO语句者的主要依据。实际上，硬件飞速发展，这点耗费，不再是重要的因素。
4.4.2 面向对象的分析设计
面向对象的 分析模型主要由 顶层架构图、用例与用例图、领域概念模型 构成； 设计模型包含：
以包图表示的 软件体系结构图、
以交互图表示的 用例实现图、
完整精确的类图、
针对复杂对象的状态图、
描述流程化处理过程的 活动图 等。
4.5 软件的重用
重复使用 相同或相似 软件元素。
软件元素：需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识 等，通产这些软件元素称为 软部件。
不断地进行软部件的积累，并将它们组织成软部件库。
横向重用（horizontal reuse）：重用不同应用领域中的软件元素。
标准函数库 是一种 典型的、原始的 横向重用机制。
纵向重用广受瞩目，并称为软件重用技术的真正希望所在，关键点是 域分析，根据应用领域的 特征 以及 相似性 预测软部件的可重用性。
库的组织结构 直接影响软部件的检索效率。
由于软部件大都经过严格的质量认证，并在实际运行环境中得到检验，因此重用软部件有助于改善软件质量。
4.6 逆向工程与重构工程
逆向工程 就是 分析已有的程序，寻找比源代码更高级的抽象表现形式。
相关概念：
重构 Restructuring，在同一抽象级别上转换系统描述形式；
设计恢复 design recovery，
重构工程 re-engineering，也称 修复和改造工程。
1、恢复信息的级别
逆向工程导出的信息，4个抽象层次
1.实现级
2.结构级
3.功能级
4.领域级
2、恢复信息的方法，4类：
1.用户指导下搜索与变换
2.变换式方法
3.基于领域知识的
4.铅板恢复法
第五章
Software Architecture 简称 SA
5.1.2 软件架构设计与生命周期
1、需求分析阶段
需求 和 SA设计 面临的是不同的对象：一个是问题空间；另一个是解空间。保持二者的可跟踪性和转换。
2、设计阶段
1.传统的设计概念只包括 构件，随着研究的深入，构件间的 互联机制 逐渐独立出来，成为与构件同等级别的实体，称为 连接子。
2.体系结构描述语言（Architecture Description Language ADL）对 连接子 的重视成为区分 ADL和其他建模语言的重要特征之一。
3.不同的视角 得到多个视图，组织起来以描述整体的SA模型；不同侧面的视图反映所关注的系统的特定方面，体现了关注点分离的思想。
3、实现阶段
团队的 结构 应该和体系结构模型有一定的对应关系，提高软件开发 效率和质量。 分析和记录 不同版本构件和连接子之间的演化。
填补高层 SA模型 和 底层实现 之间的鸿沟，典型的方法如下：
1.引入实现阶段的概念。
2.SA模型 逐步精化。
3.封装底层称为较大粒度构件。
4、构件组装阶段
可复用构件 组装 可以在较高层次上实现系统，研究内容包括：
1.如何互联。
2.如何检测并消除体系结构失配问题。
中间件跨平台交互。
产品化的中间件更好地保证最终系统的质量，中间件导向的体系结构风格。
失配是指复用过程中，待复用构件对最终系统的体系结构和环境的架设（Assumption）与实际状况下不同而导致的冲突。
5、部署阶段
软件构件的互联性、硬件的拓扑结构、硬件资源占用。
6、后开发阶段
实现中的软件往往具有动态性，一类是软件内部执行所导致的体系结构改变，另一类变化是软件系统外部的请求对软件进行的重配置。
升级或进行其他修改时 不能停机。
SA重建是指 从已实现的系统中 获取体系结构的过程。
5.2 基于架构的软件开发方法
5.2.1 体系结构的设计方法概述
基于体系结构的软件设计（Architecture-Based Software Design ABSD）方法。
体系结构驱动，指 构成体系结构的 商业、质量、功能 需求的组合驱动。
设计活动的开始 并不意味着 需求抽取和分析活动 就可以终止，而应该 并行，快速开始设计 至关重要。
ABSD 方法有三个基础，功能分解、选择体系结构风格、软件模板的使用。
5.2.2 概念与术语
1、设计元素
ABSD方法是一个 自顶向下，递归细化 的方法。
2、视角与视图
重要的是从不同的视角（perspective）来检查，考虑体系结构的不同属性。
3、用例和质量场景
在使用用例捕获功能需求时，通过定义特定场景来捕获质量需求，称为质量场景。捕获变更、性能、可靠性、交互性，质量场景必须包括 预期的 和 非预期的。
5.2.4 体系结构需求
可以从需求库中取出，加以利用和修改。
获取需求，体系结构需求一般来自三个方面：系统的质量目标、系统的商业目标、开发人员的商业目标。
5.2.6 体系结构文档化
体系结构规格说明 和 测试体系结构需求的质量设计说明书。
需求模型构件的 精确形式化描述，作为 用户和开发者 之间的一个协约。
从使用者的角度进行编写，必须保证开发者手上的文档是最新的。
5.2.7 体系结构复审
根据架构设计，搭建一个可运行的最小化系统 用于 评估 和 测试 体系架构是否满足需要。是否存在可识别的技术和协作风险。
复审的目的是 标识潜在风险，及早发现 缺陷和错误。
5.2.8 体系结构实现
分割成规定的构件，按规定方式互相交互。
5.3 软件架构风格
体系结构设计 核心目标是 重复的体系结构模式，体系结构级的 软件重用。
5.3.1 软件架构风格概述
一个体系结构 定义 一个词汇表 和 一组约束。词汇表中包含 构件和连接件类型约束指出 如何 组合起来。
体系结构风格 反映了 共有的结构和语义特性，并指导如何 组织成一个完整的系统。
5.3.2 经典软件体系结构风格
每个构件都有一组输入和输出，数据输入构件，经过内部处理，然后产生数据输出。这里的构件称为 过滤器。
构件是对象。
分层系统，每一层为上层提供服务，并作为下层的客户。除一些精心挑选的 输出函数外，内部的层接口只对 相邻层可见。由于一层最多只影响两层，为软件重用提供了强大的支持。 仓库风格中，两种不同的构件：中央数据结构、独立构件。
若构件控制共享数据，则仓库是一传统型数据库；若中央数据结构 的当前状态触发进程执行的选择，则仓库是一黑板系统。
C2 体系结构 通过连接件绑定在一起 按照一组规则运作的并行构件网络。构件与构件之间的连接是不允许的。
5.3.3 客户/服务器 风格
宿主机应用程序 既负责与用户的交互（前端），又负责对数据的管理（后端）。
C/S 体系结构 定义了工作站如何与服务器相连，实现部分数据和应用 分布到多个处理机上。 C/S三个主要组成部分：服务器、客户机、网络。
易于对系统进行扩充和缩小。
功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，数据库服务器的开发集中于数据的管理，将大应用处理任务分布到许多通过网络连接的低成本计算机上，模型思想简单。
开发成本高，尤其是软件不断升级，客户端变得越来越臃肿。
信息内容和形式单一，用户获得的只是单纯的字符和数字。
软件移植困难，维护升级困难。
5.3.4 三层 C/S 结构风格。
三层 C/S 体系结构中，可以将 整个应用逻辑 驻留在应用服务器上，只有表示层存在于客户机上，称为“瘦客户机”。表示层、功能层、数据层。
表示层一般要使用图形用户界面 GUI。
功能层之间的数据交互 要 尽可能简洁，一次性传输。
数据层不同层构件 相互独立，层间接口简洁，适合复杂事务处理。
5.3.5 浏览器/服务器 风格
浏览器/服务器 风格 就是 三层应用结构的一种实现方式。浏览器/web服务器/数据库服务器。
系统安装、修改、维护 全在服务器端解决。仅仅需要一个浏览器就可运行全部模块。 B/S 体系结构还提供了 异种机、异种网、异种应用服务 的 连机、联网 等。
扩展能力差。响应速度慢。交互性不强，不利于在线事务处理 OLTP。
5.4 特定领域软件体系结构
主要目的 在一组相关的应用中 共享 体系结构。
DSSA的必备特征：
1、一个严格定义的 问题域 和 解域。
2、具有普遍性。
3、对整个领域的 构件 组织模型 其当抽象。
4、具备该领域 固定的、典型的 可重用元素。
5.4.2 DSSA 的基本活动
1、领域分析
主要目标是 获得 领域模型，描述领域中 系统之间的共同需求，定义领域的边界。从而明确分析的对象，识别信息源，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。
2、领域设计
目标是获得 DSSA，DSSA描述在领域模型中表示的需求 的解决方案。不是单个系统的表示，而是能够适应领域中 多个系统的需求的 一个高层次设计。
3、领域实现
主要目标是 依据 领域模型 和 DSSA 开发和组织 可重用信息。领域模型 和 DSSA 定义了这些可重用信息的 重用时机。
以上过程是 反复的、逐渐求精 的过程。
5.4.3 参与 DSSA 的人员
4种角色：领域专家、领域分析师、领域设计人员、领域实现人员。
1、领域专家 可能包括 有经验的用户、从事该领域中系统的需求分析、设计、实现 以及项目管理的有经验的软件工程师等。
主要任务 提供 需求规约和实现的知识，组织规范的、一致的领域字典，选择样本系统，复审领域模型、DSSA。
应该 熟悉该领域 软件设计和实现、硬件限制、未来的用户需求、技术走向 等。
2、领域分析人员 应由 系统分析员来担任。
知识获取 组织到领域模型中，根据 现有系统、标准规范 等 验证模型的 准确性 和 一致性。
应熟悉软件重用和领域分析方法，具有一定的该领域经验，较高的 抽象、关联、类比 能力，较高的 交互合作能力。
3、领域设计人员 控制整个软件设计过程，根据领域模型和现有系统 开发出DSSA，对DSSA的准确性和一致性进行验证，建立领域模型和DSSA之间的联系。
应熟悉软件重用和领域设计方法，熟悉软件设计方法，有一定的该领域经验。
4、领域实现人员 根据领域模型和DSSA，从头开发可重用构件，或 利用再工程技术 从现有系统中提取可重用构件。
5.4.4 DSSA 的建立过程
一般情况下，需要用 开发者习惯使用的工具和方法 建立DSSA模型。
DSSA建立过程分为5个阶段，过程是 并发的、递归的、反复的，可能每个阶段经历几遍，每次增加更多的细节。
1、定义领域范围，一系列用户的需求。
2、定义领域特定的元素，编译领域字典、领驭属于的同义词词典。
3、定义特定的设计和实现需求约束，不仅要识别出约束，并且要 记录 约束对设计和实现 造成的后果，还要记录对处理这些问题时所产生的所有问题的讨论。
4、定义领域模型和体系结构，产生一般的体系结构，并说明构成它们的模块或构件的语法、语义。
5、搜集可重用的产品单元，为DSSA增加构件。
5.5 系统架构的评估
评估 可以只针对一个体系结构，也可以针对一对一组体系结构。关注的是 质量属性。
1、性能，是指系统的响应能力，多长时间 对某个事件做出响应，或者 某段时间内系统所能处理的事件的个数。
2、可靠性，是最重要的软件特性，平均失效等待时间 MTTF，平均失效间隔时间 MTBF
1.容错，内部修复。
2.健壮性，不受错误使用和错误输入的影响。
3、可用性，正常运行的时间比例。经常用两次故障之间的时间长度或恢复正常的速度来表示。
4、安全性，阻止非授权用户。分为 机密性、完整性、不可否认性、可控性 等特性。
5、可修改性，通过考察 变更的代价 衡量可修改性。
1.可维护性，主要体现在问题修复上，做局部性的修改并能使对其他否见的负面影响最小化。
2.可扩展性，新特性来扩展软件系统，改进版本来替换构件并删除不需要的特性构件，需要松散耦合的构件。
3.结构重组，需要精心设计构件之间的关系。
4.可移植性。
6、功能性，完成所期望的工作 的能力。
7、可变性。
8、互操作性，精心设计的软件入口。
5.5.2 评估中重要概念
敏感点 权衡点，是关键的体系结构决策。
敏感点是 构件（和/或 构建之间的关系）的特性。研究敏感点可使人员明确在实现质量目标时 应注意什么。
权衡点 是多个质量属性的 敏感点。
风险承担着 或称为 收益相关人。
场景，首先要精确地得出具体的质量目标，为得出这些目标采用的机制叫做场景。从风险承担者的角度与系统的交互的简短描述。
刺激、环境、响应，三个方面描述场景。
5.5.3 主要评估方法
1、SAAM 非功能质量属性的体系结构分析方法，是最早形式成文档并得到广泛使用的分析方法。最初它用于比较不同的软件体系结构，以分析SA的可修改性。
1.特定目标，目标是对描述应用程序属性的文档，验证假设和原则，有利于评估固有的风险。
2.评估技术，使用场景技术，描述了各种系统 必须支持的活动 和 将要发生的变化。
3.质量属性，可修改性 是 SAAM分析的主要 质量属性。
4.风险承担者，SAAM 协调不同参与者所感兴趣的方面，作为后续决策的基础，提供了对系统结构的 公共理解。
5.体系结构描述，描述形式 应该被所有参与者理解。功能、结构、分配，三个主要方面。
6.方法活动，SAAM 的主要输入问题是 描述、需求声明、体系结构描述。
SAAM 分析评估 体系结构过程包括 5个 步骤：场景开发、体系结构描述、单个场景评估、场景交互、总体评估。
通过各类 风险承担者协商讨论，开发一些 任务场景，体现系统所支持的 各种活动。
通过对场景交互的分析，得出系统中所有场景对系统中构件所产生影响的列表。总体的 权衡 和 评价。
2、ATAM
体系结构权衡分析方法，主要针对 性能、实用性、安全性、可修改性。
确定多个质量属性之间 这种 的必要性。
体系结构空间 受到 历史遗留系统、互操作性 和 以前失败的项目 约束。
逻辑视图被分为 功能结构 和 代码结构。这些结构加上他们之间适当的映射可以完整地描述一个体系结构。
用一组 消息顺序图 显示运行时的 交互 和 场景。
从不同的体系结构角度，有三种不同场景，用例、增长场景、探测场景。
ATAM 使用定性的 启发式分析方法 QAH，构造 精确分析模型时 要进行分析。
4个主要的活动领域（或阶段），场景和需求收集、结构视图和场景实现、属性模型构造和分析、分析、折中。
属性分析是互相依赖的。获得属性交互的方法有两种，敏感度分析来发现折中点、通过检查假设。
迭代的改进。除了通常从场景派生而来的需求，还有很多对 行为模式和执行环境的 假设。 由于属性之间存在折中，每一个架设都要被 检查、验证、提问，完成所有操作后，把分析的 结果和需求 进行对比。
领驭知识库通过基于属性的 体系结构风格ABAS 维护，变得更为惯例化、更可预测，得到一个标准问题集合。
第六章
UML 建模与架构文档化
方法种类的膨胀，极大地妨碍了用户的使用和交流。
UML通过统一的表示法，使不同知识背景的 领域专家、系统分析、开发人员、用户 可以方便地交流。
6.1.2 UML 体系结构演变
UML 是用 元模型 描述的，元模型是 4层元模型体系结构模式中的一层，其他层次分别是 元-元模型、模型层、用户对象曾。其中元模型层 由 元-元模型层 导出。
元模型的体系结构模式 可以用来定义 复杂模型 所要求的 精确定义，这种复杂模型通常需要被 可靠地 保存、共享、操作 以及在工具之间进行交换。它的特点如下：
1、在每一层都递归地定义语义结构。
2、可用来定义 重量级和轻量级 扩展机制。
3、在体系结构上 将其他体系结构的标准统一起来。
UML 元模型又被分解为三个逻辑子包：基础包、行为元素包、模型管理包。
6.2 UML 基础
UML 通过 图形化的表示机制 从多个侧面 对系统的分析和设计模型进行刻画。 10种视图，四类：
1、用例图
2、静态图，包括 类图、对象图、包图。
类图的边表示类之间的联系，包括 继承、关联、依赖、聚合 等。
对象图描述在某种状态下或某一时间段，系统中 活跃的对象及其关系。 包由 子包、类 组成。
3、行为图，包括 交互图、状态图、活动图，他们从不同的侧面刻画系统的动态行为。 交互图分为 顺序图、合作图。顺序图强调 对象之间 消息发送的时序。合作图更强调对象间 的动态协作关系。
状态图 描述 对象的动态行为。
活动图 描述 操作序列，这些操作序列 可以并发、同步，包含控制流、信息流。
4、实现图，包括 构件图、部署图。描述组成和分布情况。
部署图 节点表示实际的计算机和设备，边表示节点之间的物理连接，也可以显示连接的类型及节点之间的依赖性。
6.2.2 用例和用例图
用例图 也翻译为 用况、用按 等，在 UML 中，用例用一个椭圆表示，往往用 动宾结构 或 主谓结构 命名。
可选的 动作序列 和 会出现异常的动作序列。
用例是代表系统中 各种相关人员之间 就系统的行为所达成的契约。 需求阶段 用例是 分析人员与客户沟通的工具 项目规模估算的依据； 设计阶段 用例是 系统功能设计的主要输入；
实现阶段 用例是 检测类型为正确性的文档。
本质上，用力分析 是一种功能分解 的技术。
1、参与者 角色，参与者实际上 并不是系统的一部分。
2、用例间的关系，泛化、包含、扩展 等。
包含是比较特殊的依赖关系。
扩展，基本用例必须声明 若干“扩展点”，而这些扩展用例只能在这些扩展点上增加新的行为和含义。
3、用例图
建模人员可以在途中给某些图符加上填充色，在语义上，使用填充颜色和不使用填充颜色的模型是 一样的。
6.2.3 交互图
描述对象之间 对象与参与者之间 动态协作关系 协作过程中行为次序。
通常描述用例的行为，显示该用例中所涉及的对象 对象之间的消息传递。
顺序图、协作图 之间可以互相转化，一个用例需要多个顺序图或协作图。
交互图可以帮助分析人员 对照检查 每个用例中所描述的 用户需求，提醒分析人员去补充遗漏的类或方法。
水平方向为对象维，一般 主要参与者放在最左边，次要参与者放在最右边。
垂直方向为时间维。
6.2.4 类图和对象图
一般而言，类的名字是 名词。
类之间的关系 有 关联、聚集、组合、泛化、依赖 等。
1、关联，链 是关联的实例，关联表示 类与类之间的关系，链表示 对象与对象之间的关系。 关联用 实线表示，角色还具有多重性。
关联类 描述关联的 属性、操作、以及其他信息。
关联类 通过一条虚线与关联连接。
自返关联 又称 递归关联，同一个类的两个对象间的关系。两个关联端，每个关联端的角色不同。
2、聚集和组合
聚集 是一种特殊形式的 关联，类之间整体与部分的关系。
组合 整体与部分具有同样的生存期，是一种特殊形式的聚集。
3、泛化关系，一般和特殊元素之间的关系，就是平常所说的继承关系。
6.2.5 状态图和活动图
1、状态图
描述 对象 生存期间的 动态行为，所经历的状态序列，引起状态转移的 事件、动作。 是 UML 动态行为建模的 5个图之一，用 状态机 对一个对象的生命周期建模，状态图 用于显示状态机，重点在于 状态之间的控制流。
除了 初态和终态，还有 Idle 和 Running 两个状态，keyPress、finished、shutDown 是事件。
2、活动图
是 UML 动态行为建模的 5个图之一，描述系统的 工作流程 和 并发行为。状态图的特殊形式，一个活动结束后将立即进入下一个活动。
基本概念：活动、泳道、分支、分叉、汇合、对象流。
1.活动，注意区分 动作状态 和 活动状态，
动作状态是原子的，没有内部转移，没有内部活动，所占用的时间可以忽略，目的是执行进
入动作，然后转向另一个状态。
活动状态是可分解的，工作完成需要一定的时间。
2.泳道，是活动图中区域划分，每个泳道代表一个责任区，泳道 和 类 并不是一一对应的关系。
3.分支，同一个触发事件，可以根据不同的警戒条件 转向不同的活动，每个可能的转移 是一个分支。
4.分叉和汇合，如果要表示 系统或对象 中的 并发行为，使用 分叉fork 和 汇合join，汇合正好与分叉相反。
5.对象流，活动图中可以出现对象，对象可用作为活动的输入输出。活动图中的对象流表示活动和对象之间的关系。
6.2.6 构件图
构件 是系统中 遵从一组接口 且提供其实现的 物理的、可替换 的部分。
构件图 显示一组构件 以及它们 之间的相互关系，包括 编译、连接、执行时 构建之间的依赖关系。
构件就是一个实际文件，以下几种类型：
1、部署构建
2、工作产品构件
3、执行构件
构件图可以对以下几个方面建模：
1、对源代码文件之间的相互关系建模。
2、对可执行文件之间的相互关系建模。
6.2.7 部署图
部署图 也称 配置图、实施图，显示系统中计算节点的 拓扑结构、通信路径、节点上运行的软构件等。
一个系统模型只有一个部署图，常用语帮助理解分布式系统。
部署图 由 体系结构设计师、网络工程师、系统工程师 等 描述。
6.3 基于 UML 的软件开发过程
6.3.1 开发过程概述
UML 是独立于软件开发过程的，能够在几乎任何一种软件开发过程中使用。迭代的渐进式软件开发过程包含四个阶段：初启、细化、构件、部署。
1、初启
项目的发起人 确定项目的 主要目标 和 范围，初步的可行性分析 和 经济效益分析。
2、细化
细化阶段的开始 标志着 项目的正式确立。
1.初步的需求分析，比较重要、比较有风险的用例。
2.初步的高层设计，用例、用例图、类、类图 将 依据 包 的划分方法 分属于 不同包。
3.部分的详细设计，根据软件元素 的重要性和风险程度 确立优先细化原则，不能将风险的识别和解决延迟到细化阶段后。
4.部分的原型构造。
3、构建
构造阶段，每次迭代中实现一部分用例，用户可以及早参与对已实现用例的实际评价。 原则：
1.用户认为业务价值较大的用例 应 优先安排。
2.开发人员评估后 认为 开发风险较高的用例 优先 安排。
迭代计划中，要确定迭代次数、每次迭代所需时间 以及 每次迭代中应完成的用例。
6.3.2 基于 UML 的需求分析
1、生成用例
如果多个用户扮演同一角色，这些用户将由单一执行者表示。如果一个用户扮演多种角色，则需要多个执行者来表示同一用户。
用例主要来源于分析人员对 场景的 分类和抽象，即将相似的场景进行归类，使一个用例可以通过实例化和参数调节而涵盖多个场景。
2、用活动图表示用例
3、生成用例图
执行者与用例之间的关系有两种：触发执行、信息交换。
执行者指向用例 表示 触发执行 和/或 信息交换，用例指向执行者 表示用例将生成的信息传递给执行者。
4、建立顶层架构
顶层架构便于开发人员 聚焦于系统的不同部分。
模型——视图——控制器（Model、View、Controller，MVC）模式。
模型 维护并保存数据，视图 呈现数据，控制器将动作映射为处理功能并实际调用。 MVC 模式特别适合于分布式应用软件，尤其是web应用系统。
分层模式 降低软件系统的 耦合度。
确立顶层架构的过程中需综合考虑以下因素：
包的数量，架构过早地陷入细节，返工的可能性很大，也不合理地限制了后续分析和设计活动的自由空间。
包之间的耦合度。
将不稳引起的软件元素分类聚集于少数几个包中，以提高软件系统的可维护性。 可选功能 和 必须实现的功能 置于 不同的包。
根据开发人员 专长 划分，使每个包都能分配给最合适的开发人员，有利于并行开发。
6.3.3 面向对象的设计方法
1、设计用例实现方案
1.提取边界类，实现类和控制类。
边界类用于描述 系统与外部环境之间的交互。
a.界面控制。
b.外部接口。
c.环境隔离。使目标软件系统的 其余部分 尽可能地 独立于环境软件。
边界类，<<boundary>>。
实体类“内向收敛”特征，仅提供 读/写 信息的必要操作 作接口，并不涉及业务逻辑处理，<<entity>>。
控制类，<<control>>。
边界类的作用范围可以超越单个用例。
2.构造交互图
交互图作为用力的精确实现方案。
事件流中的事件 直接对应交互图中的消息，事件间的先后关系体现为 交互图中的时序，对消息的响应 则构成消息接收者的职责，这种职责被确立为 类的方法。
不应该出现 穿越控制类 生命线 的消息。
为 易于理解，应该用分离的 UML 交互图 分别表示 事件流和每个备选事件流。 原则上，每个类都应该有一个操作来响应交互图中指向其对象的那条消息。
2、设计技术支撑方案
当用户需求发生变化时，技术支撑方案应具有良好的稳定性。
技术支撑方案应该位于层次结构中的较低层次。
一方面取决于 需求，另一方面取决于 对软件技术手段把我和选取。
3、设计用户界面
1.熟悉用户 并对 用户分类，以便尽量照顾到所有用户的合理要求，并优先满足某些特权用户。
2.按用户类别 分析用户的 工作流与习惯，从每类中选取一个用户代表，建立调查表，判断用户对操作界面的需求和喜好。
3.首先应考虑命令的顺序，一般常用命令居先，与用户工作习惯保持一致；其次，根据外部服务之间的聚合关系组织相应的命令；然后充分考虑人类记忆的局限性，最好组织为一颗两层多叉树；提供操作的快捷方式。
5.利用快速原型演示，改进界面设计。并评判系统是否 齐全、方便、好用。
4、精化设计模型
对模型进行改进的活动可以分为 精化 和 合并 两种。一般先从精化开始。设计优秀的粗粒度组件应该只是完成一项功能，这一点是它与子系统的主要区分。
粗粒度组件的范围过于广泛，难以发挥重用价值，粗粒度组件拥有持久化的行为，拥有业务逻辑，需要表示层的支持。
将需求分成几个功能组，基本上就可以得到相应的粗粒度组件了。
过小的范围，将会造成粗粒度组件不容易使用，用户需要理解不同的粗粒度组件之间的复杂关系。
如果可能，在粗粒度组件之间定义单项关联可以有效的减少组件之间的耦合。
尽可能简化组件之间的关系。
我们需要从软件的目标领域中 识别出关键性的实体，或者说领域中的名词。然后决定它们应该归属于那些粗粒度组件。
两个组件之间存在重复的要素，可以从中抽取共性的部分，形成新的组件。
6.4 系统架构文档化
6.4.1 模型概述
以精心选择的形式 将若干结构元素进行装配。
软件架构 = { 元素，形式，关系/约束 }
逻辑视图（logical view）对象模型。
过程视图（process view）并发和同步特征。
物理视图（physical view）分布式。
开发视图（development view）静态组织结构。
场景。
Rational 4.1 视图模型。
每个视图上均独立地应用 Perry&Wolf 软件架构公式。
对每种视图选用特定的 架构风格（architectural style）。
6.4.2 逻辑结构
逻辑架构主要支持功能性需求，系统分解为一系列的关键抽象，（大多数）来自于问题域，表现为对象或对象类的形式。
抽象、封装、继承。
对于数据驱动程度高的应用程序，可以使用其他形式的逻辑视图，如 E-R图 代替面向对象的方法。
1、逻辑视图的风格
采用面向对象的风格，试图在整个系统中 保持 单一的、一致的 对象模型。
6.4.3 进程架构
进程架构考虑一些非功能性的需求，并发性、分布性、系统完整性、容错性，以及逻辑视图的主要抽象如何与进程结构相配合在一起。
进程是 构成可执行单元任务的分组。
区分主要次要任务：主要任务是 可以唯一处理的架构元素；次要任务是 由于实施原因而引入的局部附加任务。
6.4.4 开发架构
开发架构关注软件开发环境下实际模块的组织。
开发架构用模块和子系统图来表达，显示了“输出”和“输入”关系。
考虑因素：开发难度、软件管理、重用性、通用性、由工具集、语言 所带来的限制。 开发视图 是建立产品线的 基础。
推荐使用分层（layered）的风格，每层具有良好定义的职责。某层子系统依赖同一层或低一层的子系统，最大程度地减少了具有复杂模块依赖关系的 网络的开发量。
6.4.5 物理架构
物理架构主要关注系统非功能性的需求，可用性、可靠性（容错性），性能（吞吐量）、可伸缩性。
软件至节点的映射需要高度的灵活性 及 对源代码产生最小的影响。
6.4.6 场景
4种视图的元素通过数量比较少的一组重要场景（更常见的是用例）进行无缝协同工作，我们为场景描述相应的脚本（对象之间和过程之间的交互序列）。
在某种意义上 场景是最重要的 需求抽象。
4+1 的 +1 起到了两个作用：
作为一项驱动因素 来发现架构设计过程中的 架构元素。
作为架构原型测试的出发点。
场景表示法与组件逻辑视图非常相似，但它使用过程视图的连接符来表示对象之间的交互。
6.4.7 迭代过程
在进行文档化时，提倡一种更具有迭代性质的方法——架构先被原型化、测试、估量、分析，然后在一系列的迭代过程中被细化。
除了减少 风险之外，还有其他优点：团队合作、培训、加深对架构的理解、深入程序和工具 等。使 需求被细化、成熟化。
系统大多数关键的功能以场景的形式被捕获，关键意味着：最重要的功能、系统存在的理由、使用频率最高的功能、必须减轻的一些重要技术风险。
第七章
7.1 设计模式概述
重复遇到的典型问题，描述这些共同问题 和 解决这些问题的方案 就形成了所谓的 模式。
7.1.1 设计模式的历史
模式分为几个部分：
特定的情景（Context），指模式在 何种情况下发生作用；
动机（System of Force），指问题或预期的目标；
解决方案（Solution），平衡各动机 或 解决所阐述问题的 构造或配置。
每个模式描述了一个在某种特定情境下不断重复发生的问题，以及解决该问题解决方案的核心所在。
7.1.2 为什么要使用设计模式
面向对象设计时需要考虑 封装性、力度大小、依赖关系、灵活性、可重用性 等。
1、简化并加快快设计
无需从底层做起，重用成功的设计，节约开发时间，提高软件质量。
2、方便开发人员之间的通信
可以更准确地 描述问题 及 问题的解决方案，使解决方案具有一致性。
3、降低风险
4、有助于转到面向对象技术
开发人员对新技术往往会有抵触或排斥心理，对新技术可能带来的效果持怀疑态度。 成熟的设计模式具有以下特性：
1.巧妙。
2.通用，不依赖于 系统、语言、领域。
3.不仅仅停留在理论上。
4.简单。
5.可重用。
6.面向对象。
7.1.3 设计模式的组成元素
1、模式名，简洁地描述了 模式的本质，可以帮助我们思考。
2、问题或意图，解释了设计问题和问题存在的前因后果，可能描述了特定的设计问题。
3、情景，告诉我们该模式的适用性。
4、动机，描述相关的动机和约束，通常需要对各期望的目标进行有限排序，动机阐明了问题的复杂性，定义了在相互冲突时所采取的各种权衡手段。
5、解决方案，因为模式就像一个模板，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的 抽象描述 和怎样用一个 具有一般意义的 元素组合。
6、示例，帮助读者理解模式的具体使用方法。
7、结果情景，阐述了模式后续状态和副作用。
8、基本原理，解释该模式 如何、为何 能解决当前问题。
9、相关模式，包括 静态的 和 动态的，迁到模式、后续模式、替代模式。
10、已知应用，通常好的模式前面都有一个摘要，提供简短的总结和概述，为模式描绘出一
个清晰的图画，提供有关该模式能够解决问题的快速信息。
模式应该说明它的目标读者，以及对读者有哪些知识要求。
7.1.4 设计模式的分类
软件模式 主要可分为 设计模式、分析模式、组织和过程模式 等。
设计模式主要用于 得到简洁灵活的 系统设计。
按设计模式的目的划分，创建型、结构型、行为型；
按设计模式范围划分，类设计模式、对象设计模式。
1、创建型模式，对对象实例化过程的 抽象，采用抽象类所定义的接口，封装了对象如何创建、组合 等信息。
2、结构型模式，如何组合已有的类和对象 以及获得更大的结构。
3、行为型模式，不仅描述对象或类的模式，还描述它们之间的通信模式，特别是描述一组 对等的对象怎样互相协作 完成其中任一对象 无法单独完成的任务。
7.2 设计模式实例
7.2.1 创建性模式
通过该了的子类来创建对象的。但是，这可能会 限制在系统内创建对象的 类型或数目。
1、Abstract Factory 模式
在不指定具体类的情况下，为创建一些列 相关 或 相互依赖的对象提供了接口。 提供了一个可以 确定合适的具体类 的抽象类。
优点：
可以与具体类分开。
更容易在产品系列中转换。
提高了产品间的一致性。
以下情况应该使用 Abstract Factory 模式：
系统独立于产品的 创建、组成、表示。
系统配置成 具有多个产品的 系列。
相关产品对象系列 是共同使用的，而且必须确保这一点。
你希望提供产品的类库，只开放其接口。
2、Builder 模式
将复杂对象的 构件与表示 相分离，相同的构造过程可以创建不同的对象，通过只指定对象的 类型和内容。
一次就可以创建所有的复杂对象，而其他模式一次就只能创建一个对象。
优点：
可以对产品内部表示进行改变。
将构造代码与表示代码相分离。
以下情况应该使用 Builder 模式：
算法独立于 组成对象。
构造过程必须允许已构件对象有不同表示。
3、Factory Method 模式
实例化工作交给其子类，可以在不修改代码的情况下引入新类，因为新类只实现了接口。 优点：
代码只处理接口，因此可以使用任何实现了接口的类。
在类中创建对象比直接在客户端创建要更加灵活。
以下情况中，应该使用 Factory Method 模式：
类不能预料它必须创建的对象的类。
类希望其子类指定要创建的对象。
类将责任转给某个帮助子类，而用户希望定位那个被授权的帮助子类。
4、Prototype 模式
只要将对象类定义成能够复制自身就可以实现。
优点如下：
可以在运行时 添加或删除产品。
通过改变值 指定新对象。
通过改变结构 制定新对象。
减少子类的生成和使用。
可以用类 动态地配置 应用程序。
以下情况中，应该使用 Prototype 模式：
运行时，指定需要实例化的类，例如动态载入。
避免构建与产品的类层次结构相似的 工厂类层次结构。
5、Singleton 模式
确保 一个类只有一个实例，并且提供全局访问入口，确保使用这个 实例 所有的对象 使用相同的实例。
优点：
对单个实例的受控访问。
命名空间的减少。
允许改进操作和表示。
允许改变数目的实例。
比类操作更灵活。
7.2.2 结构性模式
机构性模式 控制 较大部分之间的 关系。
它将以不同的方式 影响应用程序。
允许在补充写代码或自定义代码的情况下 创建系统。
具有增强的 重复使用性和应用性能。
1、Adapter 模式
可以充当两个类之间的媒介，可以转换一个类的接口，被另外一个类使用，使得具有不兼容接口的类能够系统使用。
优点：
允许 多个 不兼容的对象 进行交互和通信。
提高已有功能的 重复使用性。
以下情况，应该使用 Adapter 模式：
要使用已有类，而该类接口与所需的接口并不匹配。
要创建可重用的类，该类可以与 不相关 或 未知类 进行协作。
要在一个 不同于已知对象接口的接口环境中 使用对象。
必须要进行多个源之间的接口转换的时候。
2、Bridge模式
将一个复杂的组件 分成两个独立的 但又相关的 继承层次结构：功能性抽象和内部实现。 优点：
接口与实现相分离。
提高了可扩展性。
对客户端隐藏了实现的细节。
以下情况中，应该使用 Bridge 模式：
避免在抽象及其实现之间 存在永久的绑定。
抽象及其实现 可以使用子类进行扩展。
抽象的实现被改动 不用重新编译代码。
3、Composite 模式
创建树形层次结构来改变复杂性。
优点：
定义了由 主要对象 和 符合对象 组成的类层次结构。
添加新的组件类型更加简单。
结构的灵活性 和 可管理性的接口。
以下情况中，应该使用 Composite 模式：
想要表示对象的整个 或者部分的层次结构。
想要客户端能够忽略符合对象和单个对象之间的差异。
结构可以具有任何级别的复杂性，而且是动态的。
4、Decorator 模式
不修改对象外观和功能的情况下 添加或删除对象功能。
优点：
比静态继承具有更大的灵活性。
避免了特征装载的类 处于层次结构的 过高级别。
简化了编码。
改进了对象的扩展性。
在以下情况中，应该使用 Decorator 模式：
在单个对象中 动态并且透明地 添加责任，不会影响其他对象。
以后可能要修改的对象中添加责任。
无法通过静态子类化实现扩展时。
5、Facade 模式
为子系统中的一组接口 提供了一个统一的接口。更容易使用子系统的高级接口。 优点：
在不减少系统所提供的选项的情况下，为复杂系统提供了简单接口。
屏蔽了子系统组件。
提高若耦合度。
将客户端请求转换后 发送给能够处理这些请求的 子系统。
以下情况中，应使用 Facade 模式：
为复杂的子系统提供简单的接口。
客户端和抽象的实现类中 存在许多依赖关系。
想要对子系统进行分层。
6、Flyweight 模式
通过共享对象 减少对象数目。
通过共享一个接口来避免使用多个具有相同信息的实例 所带来的开销。 优点：
减少了要处理的对象数目。
如果对象能够持续，可以减少内存和存储设备。
以下情况中，应该使用 Flyweight 模式：
应用程序使用大量的对象。
由于对象数目巨大，导致很高的存储开销。
不依赖于对象的身份。
7.2.3 行为性模式
行为性模式 影响 系统的 状态、行为流。
简化、优化 并且 提高应用程序的 可维护性。
1、Chain of Responsibility 模式
在系统中建立一个链，在首先接收到它的级别处 被处理，或者定位到可以处理它的对象。 优点：
降低了耦合度。
增加面向对象制定责任的 灵活性。
类的集合可以作为一个整体。
以下情况中，应该使用 Chain of Responsibility 模式：
多个对象可以处理一个请求，而其处理器却是未知的。
在不指定确切的 请求接受对象的情况下，向几个对象中的 一个 发送请求。
动态地指定能够处理请求的对象集。
2、Command 模式
在对象中封装了请求。
优点：
将调用操作的对象 与 知道如何完成该操作的对象 相分离。
更容易添加新指令，因为不用修改已有类。
以下情况中，应该使用 Command 模式：
要通过执行的动作 来 参数化对象。
在不同的时间 指定、排序、执行 请求。
必须支持 Undo、日志记录 或 事务。
3、Interpreter 模式
解释定义其语法表示的语言，提供了语句解释器。
优点：
容易修改并扩展语法。
更容易实现语法。
以下情况中，应该使用 Interpreter 模式：
语言的语法比较简单。
效率并不是最主要的问题。
4、Iterator 模式
为集合中的有序访问提供了一致的方法，而该集合是独立于基础集合。
优点：
支持集合的不同遍历。
简化了集合的接口。
以下情况中，应该使用 Iterator 模式：
不开放集合对象内部表示的前提下，访问集合对象内容。
支持集合对象的多重遍历。
为遍历集合中的不同结构 提供了统一的接口。
5、Mediator 模式
通过引入一个能够管理对象间消息分布的对象，简化了系统中对象间的通信。提高了对象间的松耦合度，还可以独立地 改变 其间的交互。
优点：
去除对象间的影响。
简化了对象间协议。
集中化了控制。
由于不再需要直接互传消息，单个组件变得更加简单，而且容易处理。
由于不再需要 包含逻辑 来处理组件间的通信，组件变得更加通用。
以下情况中，应该使用 Mediator 模式：
对象集合需要以 一个定义规范但复杂的方式 进行通信。
6、Memento 模式
保持对象状态的“快照”（snapshot），对象可以在不向外界公开其内容的情况下 返回到它的最初状态。
优点：
保持封装的完整性。
简化了返回到初始状态所需的操作。
以下情况中，应该使用 Memento 模式：
必须保存对象状态的快照，恢复状态。
7、Observer 模式
定义了对象间 一到多 的依赖关系，当对象改变状态时，将自动通知 并 更新它所有的依赖对象。
优点：
抽象了主题与 Observer 之间的耦合关系。
支持广播方式通信。
以下情况中，应该使用 Observer 模式：
对一个对象的修改 涉及对其他对象的修改，而且不知道有多少对象 需要进行相应修改。 对象应该能够 在不同假设对象标识的前提下 通知其它对象。
8、State 模式
对象在内部状态变化时，变更其行为，并且修改其类。
优点：
针对不同状态来划分行为，使状态转换显式进行。
9、Strategy 模式
定义了一组能够用来表示 可能行为集合的类。这些行为 可以在应用程序中使用，来修改应用程序功能。
优点：
另一种子类化方法。
在类自身中定义了 每一个行为，减少了条件语句。
更容易扩展模型。
以下情况中，应该使用 Strategy 模式：
许多相关类 只是在行为方面有所区别。
需要算法的不同变体。
算法使用客户端未知的数据。
10、Template Method 模式
不重写方法的前提下 允许 子类重载部分方法 的方法。
将一些步骤由子类实现。
优点：代码重用的基础技术。
以下情况中，应该使用 Template Method 模式：
一次实现算法的不变部分，子类实现算法的可变行为。
11、Visitor 模式
不改变操作元素的类 的前提下 定义一个新操作。
优点：
容易添加新操作。
集中相关 排除不相关 操作。
以下情况中，应该使用 Visitor 模式：
包含许多具有不同接口的对象类，并且想要对这些 依赖具体类的对象进行操作。 定义对象结构的类很少被修改，但想要在此结构上定义新的操作。