【软考】高级架构师核心模块
2024-05-17 17:08:47 0 举报AI智能生成
高级架构师是一个在信息技术领域具有深厚知识和丰富经验的专业人士。他们负责设计、规划、实施和维护复杂的信息系统架构。这些架构师需要具备全面的技能，包括对软件、硬件、网络和数据库的深入了解，以及对新兴技术的敏感度和适应能力。 他们通常需要在各个业务领域之间建立联系，以确保技术的应用能够满足组织的战略目标。此外，他们还需要具备良好的沟通和团队协作能力，以便与其他团队成员和利益相关者进行有效沟通。 高级架构师的工作范围很广，从企业级信息系统的设计和开发，到针对特定业务需求的定制解决方案的实施。他们还可能需要评估和选择合适的技术堆栈，以确保组织的信息系统能够随着业务的变化而不断发展。 总的来说，高级架构师是信息技术领域的核心角色，他们的工作对于确保组织的信息系统能够满足当前和未来的业务需求至关重要。
作者其他创作
大纲/内容
开发方法
软件生命周期的8个阶段（性需要细，先成人使用）
可行性研究与计划阶段：确定软件是否可行，制定开发计划
需求分析阶段：确定软件需求，定义软件功能
概要设计阶段：设计软件的整体结构，定义各模块的接口
详细设计阶段：定义各模块的详细设计，编写代码
实现阶段：编写代码，实现软件的功能
集成测试阶段：将各个模块集成在一起，测试整个软件的功能
确认测试阶段：测试软件的性能、安全性、兼容性等
使用和维护阶段：用户使用软件，维护软件的运行和更新
软件开发模型
软件开发模型的类型
瀑布模型：一种传统的软件开发模型，按顺序执行各个阶段，适用于需求明确、变更较少的项目。
软件开发阶段划分
瀑布模型中，软件开发的阶段划分是明确的，一个阶段到下一个阶段有明显的界线
在每个阶段结束后，都会有固定的文档或源程序流入下一阶段
文档和源程序
需求分析结束后，需要有明确的描述软件需求的文档
总体设计结束后，需要有描述软件总体结构的文档
详细设计结束后，需要有可以用来编码的详细设计文档
编码结束后，代码本身被作为文档流到下一个阶段
面向文档的软件开发模型
瀑布模型也被称为面向文档的软件开发模型
需求明确与稳定的软件开发
当软件需求明确、稳定时，可以采用瀑布模型按部就班地开发软件
需求不明确或变动剧烈的软件开发
当软件需求不明确或变动剧烈时，瀑布模型中往往要到测试阶段才会暴露出需求的缺陷
造成后期修改代价太大，难以控制开发的风险
缺点
需求分析阶段
需求分析是一切活动的基础，设计、实现和验证活动都是从需求分析阶段的结果导出
如果需求分析的结果不完全正确，存在偏差，那么后续的活动只能放大这个偏差
瀑布模型难以适应变化
瀑布模型精确地定义了每一个阶段的活动和活动结果，每一阶段都紧密依赖于上一阶段的结果
如果在软件的后期出现了需求的变化，整个系统又要从头开始
瀑布模型交付软件产品需要长时间等待
提出需求后需要相当长一段时间的等待才能够看到最终结果
瀑布模型产生大量的文档
大部分的文档对客户没有任何意义，但完成这些对客户没有意义的文档却需要花费大量的人力
瀑布模型是一种重载过程
演化模型
瀑布模型无法一次性完全理解用户需求、设计出完美的架构，开发出可用的系统
瀑布模型需要一次性完全理解用户需求，这是不可能的
瀑布模型的设计需要预先定义，无法适应需求的变化
瀑布模型不适合复杂系统的开发
演化模型优势
演化模型能够更好地适应需求的变化
演化模型能够更好地处理复杂系统的开发
演化模型能够更好地利用认知过程进行软件开发
演化模型能够实现软件系统的持续演化和完善
演化模型类型
螺旋模型
螺旋模型适用于复杂系统的开发
螺旋模型通过多次迭代实现软件系统的持续演化和完善
螺旋模型能够更好地处理需求的变化和不确定性
螺旋模型的优点
螺旋模型结合了瀑布模型和演化模型的优点
螺旋模型强调风险分析，弥补了其他模型的不足
螺旋模型的周期
螺旋模型的周期包括需求定义、风险分析、工程实现和评审4个阶段
螺旋模型的应用
螺旋模型适用于大型、高风险的项目
螺旋模型有助于提高项目的成功率和效率
螺旋模型的局限性
风险评估经验和专业知识的重要性
风险评估经验和专业知识对于螺旋模型的成功实施至关重要
缺乏经验可能导致风险识别不足，进而导致项目延误和成本超支
丰富的风险评估经验和专业知识可以帮助团队更好地识别风险，制定有效的应对策略
过多迭代次数的弊端
过多迭代次数会增加开发成本，延迟提交时间
迭代次数过多可能导致团队士气下降，影响项目的整体进度和效率
应通过优化设计和实施过程，尽量减少迭代次数，提高项目效率
增量模型
增量模型适用于系统的技术架构成熟、风险较低的系统开发
增量模型通过逐步增加功能实现软件系统的持续演化和完善
增量模型能够更好地管理风险和成本
增量发布策略
首先做好系统的分析和设计工作，将系统划分为若干不同的版本
后一版本以前一版本为基础进行开发，扩充前一版本的功能
第一版本往往是系统的核心功能，可以满足用户最基本的需求
随着增量的发布，系统的功能逐步地丰富、完善起来
用户在很短的时间内就可以得到系统的初始版本并进行试用
试用中的问题可以很快地反馈到后续开发中，从而降低了系统的风险
注意点
每一个版本都是一个完整的版本
版本间的增量要均匀，这一点是很重要的
如果第一个版本花费一个月的时间，而第二个版本需要花费 6 个月的时间，这种不均匀的分配会降低增量发布的意义，需要重新调整
原型法开发
原型法开发适用于需求不明确、架构不确定的系统开发
原型法开发通过快速构建原型实现软件系统的持续演化和完善
原型法开发能够更好地处理需求的变化和架构的不确定性
原型法的概念
原型法是一种软件工程方法，通过快速构建原型来获得用户需求和验证架构可用性
原型法适用于用户需求不明确或技术架构存在未知因素的情况
原型法的迭代生命周期
原型法的每一次迭代都经过一个完整的生命周期，包括需求分析、设计、实现和测试等步骤
原型法的快速实现
在初始原型中，针对一般性的用户需求进行快速实现，不考虑算法的合理性或系统的稳定性
原型法的主要目的
原型法的主要目的是获得精确的用户需求，或验证架构的可用性
原型法的后续处理
一般情况下，会在后面的开发中抛弃这个原型，重新实现完整的系统
原型法的应用
原型法适用于需求不明确或技术架构存在未知因素的情况
原型法在项目管理中，有助于降低风险和减少项目延迟
原型法在软件开发中，有助于提高软件的可用性和用户体验
原型法的局限性
原型法需要投入更多的时间和资源进行原型的迭代和改进
原型法在复杂的系统开发中，可能会面临实现和维护的困难
演化模型的应用
演化模型在软件系统开发中的应用
演化模型能够更好地适应复杂系统的开发
演化模型能够实现软件系统的持续演化和完善
演化模型在敏捷软件开发中的应用
演化模型能够更好地处理需求的变化和不确定性
演化模型在项目管理中的应用
演化模型能够更好地管理风险和成本
演化模型的挑战
演化模型需要更好的管理复杂性和变化
演化模型需要更好的处理需求和架构的不确定性
演化模型需要更好的处理风险和成本
演化模型需要更好的处理认知过程的渐进性和深化性
软件开发模型的选择
选择软件开发模型时，需要考虑项目的需求、规模、团队能力等因素。
没有一种模型适用于所有项目，需要根据实际情况选择最适合的模型。
在实际应用中，可以结合多种模型，形成混合模型，以更好地满足项目需求。
统一过程（Unified Process，UP）以架构为中心
4个阶段（初细建交）
初始阶段
业务建模
需求分析
细化阶段
逻辑模型抽象
架构设计
构建阶段
系统构建
测试和部署
交付阶段
重构
修改
测试和部署
产品化
下一个版本
4个里程碑
目标里程碑
目标里程碑代表着软件系统开发初步阶段的结束
在该阶段，开发者需要明确软件系统的目标、范围以及需求
架构里程碑
架构里程碑是UP生命周期中的第二个里程碑
在该阶段，开发者需要确定稳定的系统架构，以便后续开发工作
能力里程碑
能力里程碑是UP生命周期中的第三个里程碑
在该阶段，系统需要完成Alpha测试，确保系统的稳定性和成熟度
发布里程碑
发布里程碑是UP生命周期中的第四个里程碑
在该阶段，需要完成系统的测试、完成系统发布和用户培训等工作
后续维护和迭代
经过这 4 个里程碑后，即为一个完整的生命周期，开发出一个新的版本。
此时可以关闭该产品的开发，也可以迭代进入下一版本。
此时可以关闭该产品的开发，也可以迭代进入下一版本。
特点
UP开发模型的特点
UP是一个迭代的二维开发模型，每个阶段都可以进行需求、设计等活动
UP给出了迭代的生命周期，并给出生命周期每一阶段的迭代指南
采用不同迭代方式的UP可以演变为演化模型或增量模型
UP的迭代特点使得更容易控制软件开发的风险
UP不是一个敏捷方法，而是一个重载过程
UP的适用范围
可以根据具体问题对UP进行裁减，使其适应各种规模的软件和开发团队
架构设计师在 UP 中的活动
架构设计师的协作与沟通
架构设计师需要同需求人员和项目管理人员密切协作
架构设计师需要了解需求人员提出的需求，以便于设计出符合需求的系统架构
架构设计师需要与项目管理人员密切配合，确保项目的顺利推进和按时完成
架构设计师的细化软件架构工作
架构设计师需要细化软件架构
细化软件架构的目的是使系统架构更加具体、明确，以便于开发和实施
细化软件架构包括设计各个模块、接口、数据流、业务流程等
保持架构的概念完整性
保持整个架构的概念完整性是架构设计师的重要任务
架构的概念完整性是指系统架构在逻辑上具有一致性，各个部分能够相互配合、协调工作
保持架构的概念完整性需要架构设计师对整个系统有深入的理解和把握
架构设计师的设计工作
架构设计师需要定义设计方法、设计指南、编码指南、评审设计等工作
设计方法是指架构设计师采用的设计策略和方法论
设计指南是指架构设计师提供的设计原则和规范，用于指导开发人员进行开发
编码指南是指架构设计师提供的编码规范和标准，用于指导开发人员编写高质量的代码
评审设计是指架构设计师对开发出的系统进行评审，确保其符合设计要求和规范
敏捷方法：
以人为核心，注重沟通和协作，适用于需求多变、快速交付的项目
以人为核心，注重沟通和协作，适用于需求多变、快速交付的项目
极限编程(XP)
价值观
沟通
沟通是XP的核心要素，是团队协作的基础
沟通包括及时、准确、有效地传递信息
沟通需要团队成员积极参与，分享想法和意见
简单
简单是XP的重要原则，强调以最简单、最直接的方式解决问题
简单意味着去除不必要的复杂性，提高效率
简单要求团队成员具备良好的判断力和决策力
反馈
反馈是XP的关键环节，是学习和改进的源泉
反馈包括正面反馈和负面反馈，可以帮助团队成员了解自己的表现和需要改进的地方
反馈需要团队成员之间的相互支持和鼓励
勇气
勇气是XP的精神支柱，是面对困难和挑战的必备品质
勇气意味着敢于尝试、敢于承担风险
勇气需要团队成员之间的相互信任和支持
XP价值观的应用
XP价值观在项目管理和团队协作中发挥重要作用
XP价值观帮助团队建立良好的沟通机制和决策机制
XP价值观有助于提高团队的凝聚力和执行力
XP价值观有助于培养团队成员的职业素养和领导力
最佳实践
计划游戏
快速制定概要计划
随着项目细节清晰逐步完善计划
计划游戏结果
一套用户故事及后续迭代的概要计划
计划游戏步骤
快速制定概要计划
根据项目需求，快速制定一份初步计划
考虑关键里程碑和重要任务
确定初步的时间表和预算
随着项目细节清晰逐步完善计划
随着项目进展，不断收集和更新项目信息
调整计划，以反映新的项目细节和需求变化
根据实际情况，优化资源和时间安排
计划游戏结果
一套用户故事及后续迭代的概要计划
用户故事是指对项目需求的简短描述
后续迭代的概要计划是对未来几轮迭代的初步规划
计划游戏优点
快速响应变化
由于计划是逐步完善的，所以可以快速响应项目需求的变化
能够更快地适应市场的变化和竞争
提高团队协作
通过制定和调整计划，提高团队成员之间的协作和沟通
增强团队成员的目标感和责任感
提高项目成功率
通过逐步完善计划，提高项目的成功率
减少项目风险和成本
计划游戏缺点
需要不断的迭代和调整
由于计划是逐步完善的，所以可能需要多次迭代和调整
可能会增加时间和人力成本
对项目经理的要求较高
计划游戏的成功很大程度上依赖于项目经理的经验和能力
需要项目经理具备良好的沟通和协调能力
计划游戏的应用
新产品开发
在新产品开发中，可以快速制定一份初步计划，然后随着产品研发的深入，逐步完善计划
软件项目管理
在软件项目管理中，可以快速制定一份概要计划，然后随着项目进度的推进，逐步完善计划
项目风险管理
在项目风险管理中，可以通过计划游戏快速制定一份风险应对计划，然后随着风险情况的变化，逐步完善计划
小型发布
持续集成、小步快走
XP 方法的核心理念是持续集成、小步快走，通过频繁的小型发布，实现快速迭代和持续改进。
每个版本都应该尽可能地小，前提是每个版本有足够的商业价值，值得发布。
客户满意度
小型发布可以使得集成更频繁，客户获得的中间结果越频繁，反馈也就越频繁。
客户可以实时地了解项目的进展情况，从而提出更多的意见，以便在下一次迭代中计划进去，以实现更高的客户满意度。
XP 方法的应用场景
XP 方法适用于软件开发、产品迭代等场景，通过持续集成、小步快走，实现快速迭代和持续改进。
XP 方法的局限性
XP 方法需要团队成员有良好的沟通和协作能力，以保证持续集成、小步快走的实施。
XP 方法需要有明确的商业价值和客户需求，以保证每个版本有足够的商业价值，值得发布。
隐喻
隐喻是语言的一种表达手段
隐喻用来暗示字面意义不相似的事物之间的相似之处
隐喻有助于寻求共识
隐喻有助于发明共享语汇
隐喻是创新的武器
隐喻用于描述架构
隐喻的运用需要掌握一定的技巧和创意
隐喻的运用需要避免过度夸张和误解
隐喻的运用需要确保其意义的准确性和清晰度
隐喻的运用需要考虑到文化差异和受众的理解能力
隐喻在文学、广告、电影等多种领域都有广泛应用
测试先行
重构
结对编程
持续集成
现场客户
特征驱动开发（Feature Driven Development 、FDD）
FDD方法概述
FDD是一种迭代的、增量的软件开发方法
FDD强调在每一步中注重质量，快速交付可运行的软件
三个要素
人
人作为软件开发中的关键角色，其技能和生产率对项目成败具有决定性作用。
团队协作和沟通是确保项目成功的关键。
FDD定义了6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。
过程
软件开发过程是确保项目质量和效率的重要保障。
FDD强调了软件开发的规划和组织，以确保项目的顺利进行。
技术
技术是软件开发的重要组成部分，包括工具、方法和技术栈的选择。
技术应服务于项目需求，并随着项目的进展而不断更新和优化。
FDD 角色定义
项目经理
项目经理负责组织的开发，为团队提供适宜的开发环境，协调团队与外界的沟通。
首席架构设计师
首席架构设计师负责系统架构的设计，确保系统结构和功能的合理性。
开发经理
开发经理负责团队日常的开发，解决开发中出现的技术问题与资源冲突。
主程序员
主程序员带领一个小组完成特征的详细设计和构建的工作，要求具有一定的工作经验。
程序员
程序员在主程序员的带领下形成一个开发小组，按照特征开发计划完成开发。
领域专家
领域专家对业务领域精通，一般由客户、系统分析员等担当，为项目提供业务支持和指导。
核心过程
开发整体对象模型
业务建模的阶段，有助于把握整个系统，而不仅仅关注系统中的若干个点。
领域专家和首席架构设计师相互配合，完成整体对象模型。
构造特征列表
完成系统建模后，需要构造一个完整的特征列表。
采用动作、结果和目标来描述特征，特征的粒度最好可以在两周之内实现。
在这一阶段中，可以整理出系统的需求。
计划特征开发
项目经理根据构造出的特征列表、特征间的依赖关系进行计划，安排开发任务。
特征设计
主程序员将带领特征小组对特征进行详细设计，为后面的构建做准备。
特征构建
特征构建和特征设计这两个阶段合并起来可以看做特征的实现阶段，这两个阶段反复地迭代，直到完成全部的开发。
最佳实践
领域对象建模是FDD的重要组成部分，它是将系统分解为多个领域对象并建立其关系的过程
领域对象建模的目标是建立领域对象的详细描述，以便于开发人员理解和实现
领域对象建模应遵循一定的规则，如单一职责原则、开闭原则等，以提高系统的可维护性和可扩展性
根据特征进行开发
根据特征进行开发是指在FDD中，将系统划分为多个特征，每个特征对应一组相关的领域对象
根据特征进行开发可以降低系统复杂度，提高开发效率
根据特征进行开发需要遵循一定的原则，如先易后难、先局部后整体等，以确保开发进度和质量
类的个体所有
在FDD中，类的个体所有是指每个领域对象只属于一个类，每个类只包含一个领域对象
类的个体所有可以降低类之间的耦合度，提高系统的可维护性和可扩展性
类的个体所有需要遵循一定的原则，如单一职责原则、开闭原则等，以确保类的质量和可重用性
组成特征小组
在FDD中，组成特征小组是指将开发团队分为多个小组，每个小组负责一个或多个特征的开发
组成特征小组可以提高开发效率，降低沟通成本
组成特征小组需要遵循一定的原则，如组内职责明确、组间协作良好等，以确保开发进度和质量
审查
审查是FDD中非常重要的环节，它是对领域对象建模、根据特征进行开发、类的个体所有、组成特征小组等环节的检查和验证
审查可以提高系统的质量和可靠性
审查需要遵循一定的原则，如客观公正、全面细致等，以确保审查的效果
定期构造
定期构造是指在FDD中，按照预定的时间周期对系统进行构建和测试
定期构造可以及时发现系统中的问题，降低风险
定期构造需要遵循一定的原则，如按时完成、保证质量等，以确保系统的稳定性和可靠性
配置管理
配置管理是指在FDD中，对系统进行版本控制和变更管理
配置管理可以降低系统风险，提高系统的可维护性和可扩展性
配置管理需要遵循一定的原则，如版本控制、变更管理、测试管理等，以确保系统的稳定性和可靠性
结果的可见性
结果的可见性是指在FDD中，确保每个开发阶段和成果都是可见的
结果的可见性可以降低沟通成本，提高开发效率
结果的可见性需要遵循一定的原则，如及时沟通、明确责任等，以确保开发的顺利进行
FDD与传统方法的不同
FDD与传统的软件开发方法不同，它弱化了过程的作用
FDD强调人的重要性，注重个体和小组的能力
FDD的优势
FDD能够快速交付可运行的软件，提高软件开发效率
FDD能够提供精确的项目进度报告和状态信息，提高项目管理透明度
FDD的局限性
FDD不适合大规模的软件开发项目
FDD需要团队具有良好的沟通和协作能力
FDD在需求变更较多的情况下，可能会出现进度延期和成本超支的问题
Scrum 是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程
五个活动
产品待办事项列表梳理
梳理产品待办事项列表的意义
确定产品待办事项，明确产品开发目标
提高产品开发效率，避免重复工作和资源浪费
梳理产品待办事项列表的步骤
确定产品功能需求，制定需求列表
对需求列表进行优先级排序，确定产品待办事项
制定每个待办事项的详细计划，包括时间、资源等
梳理产品待办事项列表的注意事项
明确每个待办事项的目标和预期成果
及时更新和调整待办事项列表，以适应项目变化
确保团队成员对待办事项列表达成共识
梳理产品待办事项列表的工具和方法
使用项目管理软件，如Trello、Jira等
采用敏捷开发方法，如Scrum、看板等
Sprint计划会议
Sprint计划会议的定义
Sprint计划会议是Scrum框架中的一项活动，用于制定Sprint计划
Sprint计划会议通常在Sprint开始前举行
Sprint计划会议的内容
确定Sprint目标，分解用户故事，制定Sprint backlog
分配任务，明确每个团队成员的责任和任务
预估任务时间，确定Sprint时间表
Sprint计划会议的注意事项
确保团队成员对Sprint目标达成共识
避免过度承诺，确保任务时间合理
及时调整Sprint计划，以适应项目变化
Sprint计划会议的工具和方法
使用Sprint backlog，记录Sprint计划
采用敏捷开发方法，如Scrum、看板等
每日Scrum会议
每日Scrum会议的定义
每日Scrum会议是Scrum框架中的一项活动，用于团队内部沟通和协作
每日Scrum会议通常在每天早晨举行
每日Scrum会议的内容
汇报昨日工作成果，讨论遇到的问题和挑战
确定当日工作计划，明确任务优先级
进行团队协作和信息共享
每日Scrum会议的注意事项
保持会议简短，控制在15分钟内
避免问题讨论，确保会议聚焦于工作进度和计划
及时更新Sprint backlog，以适应项目变化
每日Scrum会议的工具和方法
使用看板，记录团队工作进度和任务状态
采用敏捷开发方法，如Scrum、看板等
Sprint评审会议
Sprint评审会议的定义
Sprint评审会议是Scrum框架中的一项活动，用于展示Sprint成果
Sprint评审会议通常在Sprint结束后举行
Sprint评审会议的内容
展示Sprint成果，包括完成的用户故事和任务
讨论Sprint过程中遇到的问题和挑战
提出改进意见和建议，以优化后续Sprint计划
Sprint评审会议的注意事项
确保团队成员对Sprint成果达成共识
避免过度承诺，确保Sprint成果符合预期
及时调整Sprint计划，以适应项目变化
Sprint评审会议的工具和方法
使用Sprint backlog，记录Sprint计划
采用敏捷开发方法，如Scrum、看板等
Sprint回顾会议
Sprint回顾会议的定义
Sprint回顾会议是Scrum框架中的一项活动，用于总结Sprint经验教训
Sprint回顾会议通常在Sprint结束后举行
Sprint回顾会议的内容
回顾Sprint过程中的成功和失败经验
讨论团队和项目存在的问题和挑战
提出改进意见和建议，以优化后续Sprint计划
Sprint回顾会议的注意事项
确保团队成员对Sprint经验教训达成共识
避免过度承诺，确保改进措施切实可行
及时调整Sprint计划，以适应项目变化
Sprint回顾会议的工具和方法
使用Sprint backlog，记录Sprint计划
采用敏捷开发方法，如Scrum、看板等
5 大价值观
承诺—愿意对目标做出承诺
专注—把你的心思和能力都用到你承诺的工作上去
开放—Scrum 把项目中的一切开放给每个人看
尊重—每个人都有他独特的背景和经验
勇气—有勇气做出承诺，履行承诺，接受别人的尊重
Scrum价值观的应用
承诺的应用—在项目中明确并执行目标，保证项目的顺利进行
专注的应用—团队成员将精力集中在他们承诺的任务上，提高工作效率
开放的应用—项目中的所有信息对所有团队成员开放，提高透明度和沟通效率
尊重的应用—尊重团队成员的背景和经验，促进团队合作和交流
勇气的应用—鼓励团队成员勇于承担和完成他们的承诺，形成积极的团队氛围
水晶方法（Crystal）
Crystal方法概述
Crystal方法是一种提倡机动性的方法，包含具有共性的核心元素
每个元素包含独特的角色、过程模式、工作产品和实践
Crystal家族
Crystal家族是一组经过证明、对不同类型项目非常有效的敏捷过程
Crystal家族成员包括Crystal Clear，Crystal Yellow，Crystal Orange 和 Crystal Red
Crystal家族成员可以根据项目和环境选择最合适的敏捷过程
透明水晶方法
透明水晶方法是使用频度较高的Crystal方法
透明水晶方法适合于一个小团队来进行敏捷开发，人数在6人以下为宜
透明水晶方法的特点
透明水晶方法注重团队合作和沟通的效率
透明水晶方法强调快速迭代和持续改进
透明水晶方法鼓励团队自主管理和自我组织
透明水晶方法的应用
透明水晶方法适用于多种类型的项目，如软件开发、产品设计等
透明水晶方法可以提高团队的协作效率和创新能力
透明水晶方法的局限性
透明水晶方法可能需要更多的团队沟通和协作能力
透明水晶方法可能不适用于大规模项目或复杂项目
开放式源码
开放源码项目地域分布广
查错排障高度并行性
任何人可以提交错误修正源码
维护者合并补丁或新增代码
ASD方法概述
ASD方法由Jim Highsmith提出
核心为三个非线性、重叠的开发阶段：猜测、合作与学习
软件重用
重用形式
源代码重用的挑战
大规模重用的困难
源代码重用的局限性
架构重用
架构重用的优势
架构风格的推广
设计模式的应用
应用框架的重用
应用框架的发展
成熟软件公司的开发框架
开源社区的创新框架
业务建模的重用
领域模型的通用性
业务领域的模型重用
降低需求风险
文档及过程的重用
软件文档的重要性
软件过程的重用
提高开发效率和软件质量
软构件的重用
软构件的定义
软构件的重用方法
软件服务的重用
Web服务的发展
软件服务的重用潜力
构件技术
构件的定义
构件是自包容、可复用的程序集，是程序集的集合，整体向外提供统一的访问接口
构件的内部功能界限清晰，可以独立配置与使用
构件的特性
自包容
可重用
构件的应用
在软件开发中，构件可以实现模块之间的松耦合，提高代码的重用性和可维护性
在系统集成中，构件可以作为系统的构建模块，实现系统的快速部署和维护
构件的局限性
构件的接口一致性要求高，需要大量时间和精力进行设计和维护
构件的内部逻辑和外部接口需要严格区分，增加了编程的复杂性
构件的发展趋势
构件在云计算、微服务等新兴技术领域得到广泛应用，推动软件开发模式和架构的变革
构件的轻量级、微服务化趋势明显，推动系统架构向更加灵活、可扩展的方向发展
基于架构的软件设计（Architecture-Based Software Design，ABSD）
一种架构驱动方法。
一种架构驱动方法。
3 个基础
功能分解
ABSD方法
ABSD方法将软件系统分解为多个模块
ABSD方法强调模块的内聚性和耦合性
ABSD方法提高了软件系统的可维护性和可扩展性
基于模块的内聚和耦合技术
内聚性是指模块内部的元素紧密相关
耦合性是指模块之间的相互依赖关系
高内聚低耦合的模块结构有利于提高软件系统的可维护性和可扩展性
架构风格选择
质量和业务需求
质量和业务需求是架构风格选择的重要依据
质量和业务需求决定了软件系统的性能、可维护性和可扩展性
架构风格
架构风格是指软件系统的整体结构和设计方法
常见的架构风格包括分层架构、微服务架构、分布式架构等
选择合适的架构风格有利于满足质量和业务需求
软件模板使用
软件模板
软件模板是一种可以重复使用的软件结构
软件模板可以提高软件开发效率和质量
软件模板包括通用模板和特定领域的模板
软件系统的结构
软件系统的结构是指软件系统的各个组成部分及其相互关系
理解软件系统的结构有利于更好地使用软件模板
6个输入
抽象功能需求
ABSD方法假定需求阶段的输出之一是功能需求的抽象描述
ABSD方法考虑所有最终用户，包括系统管理员、维护工程师等
ABSD方法理解公共需求和与这些需求相关的粗略变化的描述
ABSD方法在某种抽象级别上获取功能需求
ABSD方法详细需求的获取为详细需求提供了分类
ABSD方法在设计阶段，理解需求之间的依赖关系是至关重要的
ABSD方法在产品详细需求明确时，抽象功能的获取为详细需求提供了分类
ABSD方法的应用领域
ABSD方法应用于软件工程、系统设计等领域
ABSD方法应用于需求管理、系统设计、产品开发等环节
用例
用例是系统交互的具体表述
用例可以是操作人员与系统间的交互
用例也可以是软件系统与系统间的交互
用例管理
限制用例的数量
分析用例，找出重要的用例
对创建的用例进行分组和设置优先级
筛选出最重要的用例
用例创建时机
设计阶段创建重要的用例
不重要的用例可以在设计阶段的任何时间创建
用例的注意事项
确保用例的高效性和准确性
避免重复和冗余的用例
确保用例与系统的实际需求相符
抽象的质量和业务需求
质量属性和刺激
每个质量属性都有一个特定的刺激，用于激发响应
质量属性需要具体化，以便于理解和实现
刺激需要明确定义，以便于测试和验证
业务需求具体化
业务需求需要明确定义，以便于理解和实现
业务需求需要分解为具体的功能点，以便于测试和验证
构建系统质量的重要性
构建系统质量直接影响到系统的可用性和可靠性
构建系统质量直接影响到用户的体验和满意度
构建系统质量直接影响到系统的维护和更新成本
构建系统质量直接影响到系统的安全性和合规性
质量因素（实际质量和业务需求）
架构选项
约束
性能约束
安全性约束
可维护性约束
可扩展性约束
成本约束
时间约束
人员约束
环境约束
法规约束
基于架构的软件开发模型（Architecture-Based Software Design Model，ABSDM
（需计化，审现演）
（需计化，审现演）
架构需求
需求获取
需求是对软件系统的期望，包括功能、行为、性能等方面
需求受技术环境和架构设计师经验的影响
需求过程主要是获取用户需求，标识系统中的构件
需求分类
功能需求：用户希望系统完成的功能
行为需求：用户希望系统如何响应操作
性能需求：用户对系统性能的期望
设计约束需求：系统设计时需要考虑的因素
标识构件
使用CASE工具生成类图
Rational Rose：自动生成类图
其他CASE工具：如Enterprise Architect等也可生成类图
对类进行分组
隔离类：形成独立组
泛化关联类：形成附加组
聚合或组合关联类：形成附加组
打包成构件
类簇打包成构件
构件分组合并成大构件
需求评审
审查需求是否真实反映用户要求
审查需求来源和真实性
审查需求的完整性和准确性
审查类分组是否合理
审查类的划分是否合理
审查类之间的关系是否清晰
审查构件合并是否合理
审查构件合并的必要性和合理性
审查构件合并后对系统的影响
架构设计
提出软件架构模型
在建立架构的初期，选择一个合适的架构风格是首要的。
在这个风格基础上，开发人员通过架构模型，可以获得关于架构属性的理解
在这个风格基础上，开发人员通过架构模型，可以获得关于架构属性的理解
把已标识的构件映射到软件架构中
把在架构需求阶段已标识的构件映射到架构中，将产生一个中间结构，
这个中间结构只包含那些能明确适合架构模型的构件
这个中间结构只包含那些能明确适合架构模型的构件
分析构件之间的相互作用
认真分析这些构件的相互作用和关系
产生软件架构
一旦决定了关键的构件之间的关系和相互作用，就可以在第 2 阶段得到的中间架构的基础上进行细化
设计评审
一旦设计了软件架构，我们必须邀请独立于系统开发的外部人员对架构进行评审
架构文档化
文档是系统设计与开发人员的通信媒介，为验证架构设计和提炼或修改这些设计（必要时）所执行预先分析的基础。
文档化过程的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书这两个文档。
生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。
软件架构的文档要求与软件开发项目中的其他文档是类似的。
文档的完整性和质量是软件架构成功的关键因素。
文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，且必须保证开发者手上的文档是最新的。
软件架构文档化过程的重要性
文档化是确保软件架构成功的关键环节，对系统演化的每一个阶段都至关重要。
文档化过程需要遵循一定的规范和标准，以保证文档的质量和完整性。
文档化过程需要明确定义文档的编写、审核和分发流程，以保证文档的时效性和准确性。
文档编写的注意事项
文档编写需要从使用者的角度出发，确保文档的可读性和实用性。
文档编写需要明确文档的结构和内容，以保证文档的完整性和一致性。
文档编写需要遵循一定的格式和规范，以保证文档的质量和美观性。
文档分发和更新的重要性
文档分发是确保所有相关人员都能及时获取最新信息的关键环节。
文档更新需要及时、准确，以确保所有相关人员都能获取最新的文档信息。
文档分发和更新需要建立相应的制度和流程，以保证文档的时效性和准确性。
架构复审
由外部人员（用户代表和领域专家）参加的复审
标识潜在的风险
发现架构设计中的缺陷和错误
确保架构满足需求
体现质量需求
保证层次清晰
合理划分构件
明确文档表达
满足功能与性能的要求
架构实现
架构演化
软件架构设计
重要性
项目关系人之间交流的平台
早期设计决策
架构明确了对系统实现的约束条件
架构设计师对系统实现的各方面进行权衡的结果，是总体设计的体现
架构影响着系统的质量属性
架构可以用来预测系统的质量
架构为维护的决策提供根据
架构有助于原型开发
在较高层面上实现软件复用
构对开发的指导与规范意义不容忽略
5个模型
结构模型
结构模型是一种直观和普遍的建模方法，通过架构的构件、连接件和其他概念来刻画结构
结构模型力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质
架构描述语言是研究结构模型的核心
框架模型
框架模型与结构模型类似，但不太侧重描述结构的细节而更侧重于整体的结构
框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构
动态模型
动态模型是对结构或框架模型的补充，研究系统“大颗粒”的行为性质
动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程
过程模型
过程模型研究构造系统的步骤和过程
结构是遵循某些过程脚本的结果
功能模型
功能模型认为架构由一组功能构件按层次组成，且下层向上层提供服务
4+1视图模型
逻辑视图
系统功能分解
问题领域中的功能抽象
功能分析的通用机制和设计元素
面向对象技术中的逻辑视图
逻辑视图设计注意事项
单一、内聚的对象模型贯穿整个系统
开发视图
模块视图是一种软件开发视角，主要关注软件的组织结构和管理
模块视图允许软件通过程序库或子系统进行组织，提高软件系统的开发效率
开发视图考虑软件的内部需求，如软件开发的容易性、软件的重用和软件的通用性
开发视图充分考虑具体开发工具的局限性
开发视图通过系统输入输出关系的模型图和子系统图来描述
开发视图可以在确定了软件包含的所有元素之后描述完整的开发角度
开发视图也可以在确定每个元素之前，列出开发视图原则
进程视图
进程视图强调并发性、分布性、系统集成性和容错能力
进程视图中的主要抽象的进程结构包括线程、进程和任务等
进程视图可以描述成多层抽象，每个级别分别关注不同的方面
进程视图中的各个类的操作具体是在哪一个线程中被执行的
进程视图需要测试和优化，以提供良好的并发性和分布性
物理视图
主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题
从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小
场景
场景抽象了重要系统活动
场景使四个视图有机地联系起来
场景是最重要的需求抽象
场景在开发架构中的应用
场景帮助设计者找到架构的构件和它们之间的作用关系
场景可以用于分析特定视图
场景描述不同视图构件间如何相互作用
场景表示形式
场景可以用文本表示
场景也可以用图形表示
质量属性
分类
可用性
可修改性
性能
安全性
可测试性
易用性
描述规范
刺激源：生成该刺激的实体（人、计算机系统或其他激励器）；
刺激：刺激到达系统时可能产生的影响（即需要考虑和关注的情况）；
环境：该刺激在某条件内发生。如系统可能正处于过载情况；
制品：系统中受刺激的部分（某个制品被刺激）；
响应：刺激到达后所采取的行动；
响应度量：当响应发生时，应能够以某种方式对应其度量，用于对是否满足需求的测试。
软件架构风格
概念
软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（ idiomaticparadigm）。
架构风格定义了一个系统家族，即一个架构定义一个词汇表和一组约束。
词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
按这种方式理解，软件架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
架构风格定义了一个系统家族，即一个架构定义一个词汇表和一组约束。
词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
按这种方式理解，软件架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
分类
数据流风格
批处理
批处理风格的特点
批处理风格的每一步处理都是独立的，且顺序执行
数据在步与步之间作为一个整体进行传送
批处理风格的典型应用
经典数据处理
程序开发
Windows下的BAT程序
批处理风格的优劣势
优势：易于理解和实现，适用于大规模数据处理
劣势：处理速度相对较慢，无法实时处理数据
批处理风格的优化
优化数据传送方式，提高数据传输效率
优化处理步骤，减少数据处理时间
优化资源分配，提高处理效率
管道/过滤器
管道/过滤器风格的基本概念
管道/过滤器风格是一种软件架构，其中每个构件都有一组输入和输出，通过输入流的变换和增量计算产生输出数据流
管道/过滤器风格的特点
每个构件是独立的实体，不共享数据，不知道上下游的标识
输出数据的产生不依赖于增量计算过程的顺序
管道/过滤器风格的优势
这种风格可以提高软件的模块化和可扩展性
这种风格可以方便地对输入数据进行处理和转换
这种风格可以降低系统的耦合度，提高系统的可靠性和稳定性
管道/过滤器风格的应用
在数据流处理系统中，管道/过滤器风格可以大大提高数据处理的效率
在分布式系统中，管道/过滤器风格可以实现系统的解耦和模块化，提高系统的可扩展性和可维护性
在数据可视化系统中，管道/过滤器风格可以实现数据的高效处理和可视化展示
管道/过滤器风格的挑战
如何在保证数据正确性的前提下提高系统的处理效率
如何在保证系统可扩展性的前提下降低系统的复杂性
如何解决数据流处理中的并发和同步问题
如何应对系统中可能出现的故障和异常情况
调用/返回风格
主程序/子程序
结构化开发时期的经典架构风格
采用单线程控制，把问题划分为若干处理步骤
构件即为主程序和子程序
子程序通常可合成为模块
过程调用作为交互机制，即充当连接件
调用关系具有层次性
其语义逻辑表现为子程序的正确性，取决于它调用的子程序的正确性
结构化开发时期的典型特点
采用模块化设计和分层次的编程结构
注重程序的可维护性和可扩展性
强调程序的逻辑性和条理性
结构化开发时期的典型应用领域和成功案例
结构化开发时期的局限性和缺点
难以处理复杂的数据结构和算法
难以应对大规模的软件开发需求
难以实现跨平台的开发和应用
难以应对快速变化的用户需求和软件需求
面向对象风格
对象的表示对其他对象隐蔽
对象对其他的对象隐藏了实现细节，使得系统具有更好的模块化和可维护性
对象负责维护其表示的完整性
对象之间的独立性使得系统更加健壮和可扩展
面向对象的优点
面向对象的方法使得系统设计更加灵活和高效
对象之间的独立性使得系统更加易于维护和扩展
面向对象的方法使得系统设计更加接近于人类思维和行为模式
面向对象的挑战
对象之间的交互和通信可能会导致系统的复杂性增加
对象之间的数据共享和同步可能会导致系统的性能下降和错误率上升
面向对象的方法需要更多的学习和实践经验
层次结构
层次系统的组织结构
层次结构中的每一层都是为上层服务的，同时也作为下层的客户
精心挑选的输出函数使得内部层对外部层透明，否则内部层对外部层是不可见的
虚拟机在层次系统中实现，使得构件部分不透明
连接件通过协议来定义，连接件决定层间如何交互
拓扑约束包括对相邻层间交互的约束
支持基于可增加抽象层的设计
允许将一个复杂问题分解成一个增量步骤序列的实现
每一层最多只影响两层，只要给相邻层提供相同的接口，允许每层用不同的方法实现
软件重用提供了强大的支持
独立构件风格
进程通信
构件是独立的过程
构件通常是命名过程
消息传递的方式可以是点到点、异步和同步方式及远过程调用等
构件之间通过消息传递的方式进行交互
连接件是消息传递
消息传递是进程通信的主要方式
进程通信架构风格的特点是构件的独立性和消息传递的灵活性
事件系统
基于事件的隐式调用风格
思想是构件不直接调用一个过程，而是触发或广播一个或多个事件
系统中的其他构件中的过程在一个或多个事件中注册
当一个事件被触发，系统自动调用在这个事件中注册的所有过程
一个事件的触发就导致了另一模块中的过程的调用
优点
为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。
为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其他构件的接口。
缺点
构件放弃了对系统计算的控制
一个构件触发一个事件时，不能确定其他构件是否会响应它
而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序
数据交换的问题
有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互
在这些情况下，全局性能和资源管理便成了问题
架构上，这种风格的构件是一些模块，这些模块既可以是一些过程，又可以是一些事件的集合
过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用
主要特点是事件的触发者并不知道哪些构件会被这些事件影响
不能假定构件的处理顺序，甚至不知道哪些过程会被调用
因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式
支持基于事件的隐式调用的应用系统很多
在编程环境中用于集成各种工具
在数据库管理系统中确保数据的一致性约束
在用户界面系统中管理数据
在编辑器中支持语法检查
示例：编辑器和变量监视器可以登记相应 Debugger 的断点事件
虚拟机风格
解释器
解释引擎
解释引擎是解释器中的核心组件，负责完成代码的解释工作
解释引擎将源代码转换为虚拟机可以执行的指令
源代码存储区
源代码存储区包含将被解释的代码
源代码存储区提供源代码给解释引擎进行解释
工作状态数据结构
工作状态数据结构记录解释引擎当前工作状态
工作状态数据结构帮助解释引擎理解源代码并决定下一步的执行操作
执行进度数据结构
执行进度数据结构记录源代码被解释执行的进度
执行进度数据结构帮助解释引擎跟踪源代码的执行过程
虚拟机
虚拟机是具有解释器风格的软件中的一部分
虚拟机可以仿真硬件的执行过程和一些关键应用
解释器与虚拟机
解释器通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异
虚拟机可以模拟硬件的执行过程，使得程序能够在不同的硬件平台上运行
解释器的优点
解释器可以在不同的硬件平台上运行程序，提高了程序的可移植性
解释器可以动态地解释源代码，使得程序更加灵活和易于修改
解释器的缺点
解释器执行效率较低，因为每次执行都需要解释源代码
解释器通常需要使用大量的内存来存储源代码和执行进度
典型应用
专家系统是解释器的典型应用之一
专家系统使用解释器来解释和执行规则的知识库，实现智能化的处理和决策
规则为中心
规则集
规则集是系统的核心部分，包含一系列的规则
规则集的大小和复杂程度会影响系统的性能和效率
规则解释器
规则解释器负责对规则进行解析和执行
规则解释器需要保证规则的正确执行，避免错误和冲突
规则/数据选择器
规则/数据选择器负责选择合适的规则和数据
规则/数据选择器的准确性直接影响系统的性能
工作内存
工作内存用于存储临时数据和中间结果
工作内存的大小和速度会影响系统的效率
仓库风格
在仓库（repository）风格中，有两种不同的构件：
中央数据结构说明当前状态
独立构件在中央数据存储上执行，仓库与外构件间的相互作用在系统中会有大的变化
数据库系统
数据库架构主要包含两大类构件
中央共享数据源保存当前系统的数据状态
多个独立处理元素处理数据元素进行操作
数据库架构的应用场景
在商业领域，数据库架构用于管理大量数据，提高数据处理的效率和准确性
在科研领域，数据库架构用于处理复杂的科研数据，辅助科研人员进行数据分析和研究
在教育领域，数据库架构用于存储和管理大量的教育数据，提供高效的数据查询和检索
数据库架构的优缺点
数据库架构的优点是数据共享和统一管理，提高数据的一致性和准确性
数据库架构的缺点是数据安全和数据冗余问题，需要采取措施保障数据的安全性和减少数据的冗余
数据库架构的发展趋势
未来数据库架构将向分布式、云存储和智能化方向发展
数据库架构将更加注重数据的安全性和隐私保护
数据库架构将更加注重数据的实时性和动态性
超文本系统
早期的静态网页
黑板系统
组成
知识源
知识源是独立存在的，与应用程序相关的知识
知识源之间不直接通信，通过黑板进行交互
黑板数据结构
黑板数据按照层次组织，用于解决问题
知识源通过改变黑板数据解决问题
控制
控制由黑板状态驱动，决定使用的特定知识
概念
是一种问题求解模型
组织推理步骤、控制状态数据和问题求解之领域知识的概念框架
将解空间组织成多个应用相关的分级结构
领域相关知识被分成独立的知识模块
通过不同知识表达方法、推理框架和控制机制的组合来实现
影响黑板系统设计的因素
应用问题本身的特性
支撑应用程序的黑板体系结构有许多相似的特征和构件
应用
信号处理领域，如语音和模式识别
松耦合代理数据共享存取
层次系统架构风格
C/S架构
C/S 架构是基于资源不对等，且为实现共享而提出来的
二层 C/S
组成
服务器（后台）负责数据管理
客户机（前台）完成与用户的交互任务
优点
具有强大的数据操作和事务处理能力
模型思想简单
易于人们理解和接受
缺点
系统的性能容易变坏，服务器的负荷太重
数据安全性不好
三层 C/S
组成
表示层
应用的用户接口部分，它担负着用户与应用间的对话功能。
它用于检查用户从键盘等输入的数据，并显示应用输出的数据。
在变更用户接口时，只需改写显示控制和数据检查程序，而不影响其他两层。
检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。
它用于检查用户从键盘等输入的数据，并显示应用输出的数据。
在变更用户接口时，只需改写显示控制和数据检查程序，而不影响其他两层。
检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。
功能层
相当于应用的本体，它是将具体的业务处理逻辑编入程序中。
而处理所需的数据则要从表示层或数据层取得。
表示层和功能层之间的数据交往要尽可能简洁
而处理所需的数据则要从表示层或数据层取得。
表示层和功能层之间的数据交往要尽可能简洁
数据层
数据库管理系统，负责管理对数据库数据的读写。
数据库管理系统必须能迅速执行大量数据的更新和检索
数据库管理系统必须能迅速执行大量数据的更新和检索
B/S架构
系统安装、修改和维护在服务器端解决
用户只需浏览器运行全部模块，实现“零客户端”功能
自动升级，无需用户手动操作
异种机、异种网、异种应用服务的联机、联网、统一服务
扩展功能覆盖范围至供应商和客户
实现电子商务和客户关系管理等新企业应用
减少应用程序维护工作量
B/S架构概述
B/S架构是一种基于互联网的软件架构模式
B/S架构主要应用于企业级应用和互联网应用
B/S架构的主要优点包括简化系统维护、降低客户端硬件要求、易于升级等
B/S架构的应用领域
企业级应用，如ERP、CRM等
互联网应用，如电商、社交网络等
移动应用，如移动办公、移动支付等
B/S架构的局限性
数据安全性较低，因为数据主要存储在服务器端
用户体验相对较差，因为所有计算和渲染任务都在服务器端完成
对于网络依赖性较高，如果网络状况不佳，系统性能会受到影响
B/S架构的未来发展
云计算和分布式计算的普及为B/S架构提供了更好的性能和扩展性
物联网和移动设备的普及为B/S架构提供了更多的应用场景
HTML5等新型前端技术的发展为B/S架构提供了更好的用户体验
B/S架构与C/S架构的比较
C/S架构主要应用于桌面应用，而B/S架构主要应用于互联网应用
C/S架构的数据安全性和性能通常优于B/S架构
B/S架构的维护成本和部署难度通常低于C/S架构
B/S 架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能
B/S架构与云计算的结合
云计算为B/S架构提供了无限的计算和存储资源
云计算使得B/S架构的应用程序可以更加快速地部署和扩展
云计算为B/S架构的应用程序提供了更加安全和可靠的数据存储机制
MVC 架构
核心思想
关注点分离
Model
对应用状态和业务功能的封装，我们可以将它理解为同时包含数据和行为的领域模型
View
实现可视化界面的呈现并捕捉最终用户的交互操作
捕获到用户交互操作后会直接转发给 Controller，后者完成相应的 UI 逻辑。
Controller
接受请求并完成相应的业务处理，在状态改变的时候向 View 发出相应的通知
MVP （Model-View-Presenter）架构
MVP是从MVC模式演变而来
MVP的基本思想与MVC相通，包括Controller/Presenter负责逻辑处理，Model提供数据，View负责显示
MVP与MVC的区别在于，不允许View和Model直接交互
MVP中，View不直接使用Model，而是通过Presenter进行通信
MVP中的交互发生在Presenter内部，而在MVC中View直接从Model读取数据
优点
MVP模式能够更好地分离视图与逻辑，使得视图与逻辑的维护更加简单
MVP模式提高了代码的可重用性和可测试性
模型与视图完全分离，我们可以修改视图而不影响模型
可以更高效地使用模型，因为所有的交互都发生在一个地方—Presenter 内部
我们可以将一个 Presenter 用于多个视图，而不需要改变 Presenter 的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁
如果我们把逻辑放在 Presenter 中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）
缺点
视图渲染的频繁性
视图渲染放在Presenter中，导致视图和Presenter交互过多
交互过多可能导致性能问题
交互过多可能导致代码复杂性增加
视图和Presenter的关系
视图和Presenter关系过于紧密
视图和Presenter的紧密联系可能导致代码耦合度增加
视图变更的影响
视图变更可能需要同时变更Presenter
视图变更可能会导致代码维护困难
视图变更可能会增加开发成本
视图渲染的优化
优化视图渲染流程，减少视图和Presenter的交互
将视图渲染从Presenter中分离出来，降低耦合度
采用模块化设计，提高代码的可维护性和可扩展性
面向服务的架构（Service-Oriented Architecture，SOA）
设计原则
明确定义的接口
自包含和模块化
粗粒度
松耦合
互操作性、兼容和策略声明
服务构件架构（Service Component Architecture，SCA）
SCA提供了构建粗粒度构件的机制
粗粒度构件由细粒度构件组装而成
SCA将传统中间件编程从业务逻辑分离出来
SCA允许开发人员集中精力编写业务逻辑
SCA服务构件与传统构件的主要区别
服务构件往往是粗粒度的，而传统构件以细粒度居多
服务构件的接口是标准的，主要是服务描述语言接口
服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言
服务构件可以通过构件容器提供QoS的服务，而传统构件完全由程序代码直接控制
实现 SOA 的方法
Web Service
企业服务总线（ESB）
功能
（1）支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性。
（2）通过使用 ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准。
（3）充当缓冲器的 ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使不同的系统可以同时使用同一个服务，不用在系统或数据发生变化时，改动服务代码。
（4）在更高的层次，ESB 还提供诸如服务代理和协议转换等功能。允许在多种形式下通过像HTTP、SOAP 和 JMS 总线的多种传输方式，主要是以网络服务的形式，为发表、注册、发现和使用企业服务或界面提供基础设施。
（5）提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地。
（6）提供安全和拥有者机制，以保证消息和服务使用的认证、授权和完整性。
优势
（1）扩展的、基于标准的连接。ESB 形成一个基于标准的信息骨架，使得在系统内部和整个价值链中可以容易地进行异步或同步数据交换。ESB 通过使用 XML、SOAP 和其他标准，提供了更强大的系统连接性。
（2）灵活的、服务导向的应用组合。基于 SOA，ESB 使复杂的分布式系统（包括跨多个应用、系统和防火墙的集成方案）能够由以前开发测试过的服务组合而成，使系统具有高度可扩展性。
（3）提高复用率，降低成本。按照 SOA 方法构建应用，提高了复用率，简化了维护工作，进而减少了系统总体成本。
（4）减少市场反应时间，提高生产率。ESB 通过构件和服务复用，按照 SOA 的思想简化应用组合，基于标准的通信、转换和连接来实现这些优点。
服务注册表（service registry）
服务注册
指服务提供者向服务注册表发布服务的功能（服务合约），
包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性
包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性
服务位置
指服务使用者，帮助它们查询已注册的服务，寻找符合自身要求的服务
服务绑定
服务使用者利用查找到的服务合约来开发代码，
开发的代码将与注册的服务进行绑定，调用注册的服务，以及与它们实现互动
开发的代码将与注册的服务进行绑定，调用注册的服务，以及与它们实现互动
微服务
通过编排组合的方式来使用，从而真正做到了
独立、解耦、组件化、易维护、可复用、可替换、高可用、
最终达到提高交付质量、缩短交付周期的效果。
独立、解耦、组件化、易维护、可复用、可替换、高可用、
最终达到提高交付质量、缩短交付周期的效果。
优势
技术异构性
弹性
扩展
简化部署
与结织结构相匹配
对可替代性的优化
劣势
分布式系统的复杂度
运维成本
部署自动化
与SOA对比
差异
实现差异
架构设计（架构风格）
演变交付生命周期
属性驱动设计法（Attribute-Driven Design，ADD
一种定义软件架构的方法，该方法将分解过程建立在软件必须满足的质量属性之上。
ADD 的输入为：功能需求（一般表示为用例）、限制条件和质量需求（一组特定于系统的质量场景）。
软件架构文档化
架构编档过程的目的
促使架构设计师深入思考，完善架构设计
生成描述架构的文档，供项目关系人使用
架构编档过程的步骤
收集架构设计信息
分析架构设计需求
编写架构设计文档
架构编档过程的重要性
提高项目团队之间的沟通效率
确保架构设计的准确性和一致性
架构编档过程中可能出现的问题
文档内容不准确，导致团队成员误解
文档更新不及时，无法反映最新架构设计
文档格式不统一，不利于团队之间的沟通和协作
基本规则
（1）从读者的角度编写文档。
（2）避免出现不必要的重复。
（3）避免歧义。
（4）使用标准结构。
（5）记录基本原理。
（6）使文档保持更新，但更新频率不要过高。
（7）针对目标的适宜性对文档进行评审。
（2）避免出现不必要的重复。
（3）避免歧义。
（4）使用标准结构。
（5）记录基本原理。
（6）使文档保持更新，但更新频率不要过高。
（7）针对目标的适宜性对文档进行评审。
架构重构
信息提取（View Extraction）
可以从源代码、编译时制品和设计制品中提取静态信息；
可以使用分析工具提取动态信息。
可以使用分析工具提取动态信息。
数据库构造（Database Construction）
将提取的信息转化为标准的形式，并置于数据库中
视图融合（View Fusion）
将数据库中的信息组合在一起，生成该架构的一个内聚的视图
重构（Reconstruction）
构建数据抽象和各种表示以生成架构表示
主要由两个活动组成
主要由两个活动组成
可视化和交互
模式定义和识别
最后生成需要的架构文档（Documentation）
软件架构评估
基于调查问卷或检查表的方式
很大程度上依赖于评估人员的主观推断
基于场景的方式
架构权衡分析法
（Architecture Tradeoff Analysis Method，ATAM）
（Architecture Tradeoff Analysis Method，ATAM）
目的
理解架构设计满足系统质量需求的结果
产生如下结果
一个简洁的架构表述
ATAM 的一个要求是在一小时内表述架构，
这样就得到了一个简洁、可理解的、面向普通项目关系人的架构表述
这样就得到了一个简洁、可理解的、面向普通项目关系人的架构表述
它是从架构文档中提炼形成的
表述清楚的业务目标
用场景集合捕获质量需求
架构决策到质量需求的映射
所确定的敏感点和权衡点集合
风险主题的集合
9个步骤
ATAM 方法的表述
评估负责人向参加会议的项目代表介绍 ATAM
商业动机的表述
项目决策者从商业角度介绍系统的概况
架构的表述
设计师要描述用来满足需求的架构方法或模式，还应描述技术约束条件及与其他系统的交互等
对架构方法进行分类
通过研究架构文档及倾听上一步的表述，了解系统使用的架构模式和方法（进行明确命名）。
生成质量属性效用树
根——质量属性——属性求精（细分）——场景（叶）
修剪这棵树，保留重要场景（不超过 50 个）
再对场景按重要性给定优先级（用 H/M/L 的形式）
再按场景实现的难易度来确定优先级（用 H/M/L 的形式）
分析架构方法
评估小组把相关架构决策编成文档，确定其有风险决策、无风险决策、敏感点、权衡点，并对其进行分类（分别用表格列出）
集体讨论并确定场景的优先级
集体讨论后，可通过投票的方式获得各场景的优先级
分析架构方法
结果的表述
已编写了文档的架构方法；
经过讨论得到的场景集合及其优先级；
效用树；
所发现的有风险决策；
已编成文档的无风险决策；
所发现的敏感点和权衡点。
成本效益分析法成本效益分析法
（the Cost Benefit Analysis Method，CBAM）
（the Cost Benefit Analysis Method，CBAM）
在 ATAM 上构建，用来对架构设计决策的成本和收益进行建模，是优化此类决策的一种手段。
CBAM 的思想就是架构策略影响系统的质量属性，
反过来这些质量属性又会为系统的项目关系人带来一些收益（称为“效用”），
CBAM 协助项目关系人根据其投资回报（ROI）选择架构策略
反过来这些质量属性又会为系统的项目关系人带来一些收益（称为“效用”），
CBAM 协助项目关系人根据其投资回报（ROI）选择架构策略
软件架构分析方法
（Software Architecture Analysis Method，SAAM）
（Software Architecture Analysis Method，SAAM）
基于度量的方式
构件及其复用
商用构件标准规范
CORBA（Common ObjectRequest Broker Architecture，
公共对象请求代理架构）
公共对象请求代理架构）
CORBA架构的三个层次
对象请求代理（ORB）：规定了分布对象的定义和语言映射，实现对象间的通信和互操作
公共对象服务：在ORB之上定义了很多公共服务，可以提供并发服务、名字服务、事务服务、安全服务等各种服务
公共设施：定义了构件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则
CORBA架构的应用
在分布式系统中，CORBA架构可以提供对象间的通信和互操作，实现系统之间的互联互通
在公共服务中，CORBA架构可以提供并发服务、名字服务、事务服务、安全服务等各种服务，提高系统的稳定性和安全性
在构件框架中，CORBA架构可以提供可直接为业务对象使用的服务，提高系统的可扩展性和灵活性
J2EE
RMI（Remote Method Invocation，远程方法调用）
IIOP（Internet Inter-ORB Protocol，互联网内部对象请求代理协议）
DNA 2000
COM（Component Object Model，构件对象模型）
产品线及系统演化
特定领域软件架构
（Domain Specific Software Architecture，DSSA）
（Domain Specific Software Architecture，DSSA）
DSSA概述
DSSA是一种支持特定领域中多个应用生成的开发方法
DSSA的目标是提供整个领域的合适程度的抽象和可复用元素
DSSA必备特征
一个严格定义的问题域或解决域
具有普遍性，可以用于领域中某个特定应用的开发
对整个领域的合适程度的抽象
具备该领域固定的、典型的在开发过程中的可复用元素
领域
垂直域
定义了一个特定的系统族，导出在该领域中可作为系统的可行解决方案的一个通用软件架构。
水平域
定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统（族）的特定部分功能。
活动阶段
领域分析
主要目标：获得领域模型
通过分析领域中系统的需求，确定被广泛共享的需求
建立领域模型
领域设计
目标：获得DSSA
适应领域多个系统的需求
具有变化性，表示多选一、可选的解决方案
领域实现
主要目标：依据领域模型和DSSA开发与组织可复用信息
复用信息可以从现有系统中提取或新开发得到
看作复用基础设施的实现阶段
领域建模专注于分析问题领域，发掘重要业务领域概念，建立业务领域概念之间的关系
通常领域模型可用UML的类图和状态图表示
架构及系统演化
软件架构视图
三种类型
模块视图类型
模块视图类型：为系统的主要模块实现单元编档
模块视图类型的主要特点是以模块为中心，关注模块的独立性和封装性
模块视图类型常用于描述系统的架构，包括模块的分布和交互关系
构件和连接件视图类型
构件和连接件视图类型：为系统的构件和连接件执行单元编档
构件和连接件视图类型的主要特点是以构件和连接件为中心，关注构件的独立性和可重用性
构件和连接件视图类型常用于描述系统的架构，包括构件的分布和交互关系
分配视图类型
分配视图类型：为软件的开发和执行环境之间的关系编档
分配视图类型的主要特点是以环境和资源为中心，关注软件的部署和执行环境
分配视图类型常用于描述系统的架构，包括环境的分布和资源分配关系
0 条评论
下一页
