软件架构设计过程举例课件.ppt
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《软件架构设计过程举例课件.ppt》由用户(晟晟文业)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 架构 设计 过程 举例 课件
- 资源描述:
-
1、2软件架构辨析 市场体系结构 软件架构34MS e-Gov Architecture Framework56MS Application Reference Architecture7市场体系结构的特点 面向客户而非面向软件开发者。对于商业产品的特色宣传非常有效,但对开发者远远不够。市场体系结构与开发流程脱节。8软件构架的特点 好的软件构架满足它们的需求,并富有弹性和基于构件。一个富有弹性的软件构架能够:改进可维护性和可扩展性 实现经济性显著的可重用度 将开发团队成员间的工作清楚地分割开 封装对硬件和系统的依赖9为什么需要软件构架 最终开发出的目标系统总是由多个组成部分所构成,这种结构如果没有
2、预先定义,很难保证系统的构建过程能自发创建出一个一致而满足需求的交付。当前的软件规模已大到需要采用团队开发的模式,多个开发人员的分工协作,必然依赖于一种对开发内容的合适划分,以减少相互干扰、缩短工期的关键路径,从而提高开发效率、加快项目进度软件构架无疑是其中最关键的一类划分,它将被用来计划、管理与执行系统开发的各项活动。模块/构件化10为什么需要软件构架 目标系统总是要面临各种变数,项目组期望系统在发生变更、部署到新环境中时,仍然保持既有的稳定、可靠和性能目标系统应具备一种健壮性。系统的构建要经历一个不断增添新功能、加入新行为的过程,项目组期望做得比较容易、开销较低,且在此过程中不存在重大的风
3、险目标系统应具备一种可扩展。这些质量属性归根结底要落实到软件构架之上。11增量式开发的前提 迭代生命周期模型开始逐渐替代传统的瀑布模型,然而要真正实现其增量式开发的目标,却需要满足若干关键的前提条件:向已有交付添加新功能非常容易(可扩展);后续的增量不会破坏已有的交付,使得迭代退化为返工(健壮)。这些条件最终归结为在大批量的增量开发之前,要构建一个构架基线,它同时提供可扩展性与健壮性。设计良好的对象可以方便地添加新的行为,而封装性为其对变化提供免疫力,基于对象的构架在微观上便具有更强的可扩展性与健壮性。分层(分包、子系统)架构在大粒度上隔离关注面,同样从宏观上增强了可扩展性与健壮性。12健壮性
4、与可扩展性 要实现健壮性与可扩展性等质量特性,主要有两个途径尽可能降低系统的冗余程度,同时隔离不同的关注面(实质是高内聚、低耦合,例如:将稳定部分与可变部分隔离,将用户交互与业务、数据等功能域分离,将功能和非功能的实施代码分离)。隔离关注面,使得扩展或变更时,对系统的修改局部化,对其它部分造成的影响被限制在较小范围内,避免出现那种牵一发而动全身的情形;高内聚的结构也利于聚焦于各部分的设计适应性上。低冗余,使得即使要变更,变更所触及的部分也尽可能地少;系统被改动的地方越少当然就越健壮,同时开销也小、实施也更容易。13如何理解软件构架 软件系统进行分解的顶层结构,包括其组成元素,元素之间、元素与外
5、部的关系关注构架的静态方面,即系统大粒度(宏观)的总体结构(例如分层、子系统的划分等)系统中解决各类关键的重复问题的通用解决方案关注构架的动态方面,侧重于系统内部关键行为的共同特征(已经包含了微观细节,例如构架机制)系统设计中影响深远(构架敏感)的各项最重要决定:这些决定严重影响系统的实施,一旦作出并被贯彻,其变更的代价将及其高昂(例如构架的样式、复用策略、开发中将贯彻的设计原则等)14软件构架的意义 软件构架的静态方面,其着眼点在于保持目标系统的最终交付在结构上的一致性;为分工协作提供划分依据,并避免结构上的重叠和冗余。软件构架的动态方面,其着眼点在于保持目标系统在关键行为实现上的一致性,突
6、出系统的既有风格;同时通过为各类关键重复问题提供通用解决方案来提高复用度,避免实施代码的冗余。上述两个方面,共同提供了构造目标系统过程中的健壮性与可扩展性大量的功能实现将在这个构架基础上被不断添加,而同时系统整体上仍然保持既有的一致和完整。15架构的分层 业务应用层(Business Application)由应用开发者开发 应用框架层(Application Framework)特定领域框架层 跨领域框架层 基础框架层(Foundation Framework)操作系统层1617从经济的角度考虑架构软件架构的设计与开发用户培训18软件体系结构 软件体系结构至少有十几种思想流派。Zachman
7、框架 开放分布式处理 领域分析 Rational41视图模型 软件体系结构风格 供应商驱动的方案 Sun Enterprise JavaBeans MS.Net 体系19Zachman框架 来源于IBM 传统的体系结构,设计为非面向对象。2021开放分布式处理(ODP)构件可以最大程度的进行互操作和重用。对系统和处理方式加以标准化,只是增强软件可操作性和重用性的一种权宜之计,并不能彻底解决问题。分布式处理:借助计算机网络将分布在不同地点的构件(对象)组织在一起,进行信息处理。分布式处理中的构件可能由不同的厂商开发、生产,因而构件之间可能存在不一致的接口;另外,构件之间的通信也可能使用不同的协议
8、。这种兼容异质成分的分布式处理,称为开放分布式处理。22RMODP的元模型体系 ISO/ITUT RMODP定义的抽象层次(视角):企业视点(Enterprise Viewpoint)purpose,scope and policies 信息视点(Information Viewpoint)semantics of information and information processing 计算视点(Computational Viewpoint)functional decomaosition 工程视点(Engineering Viewpoint)infrastructure requir
9、ed to support distribution 技技术视点(Technology Viewpoint)choices of technology for implementation23领域分析 是一种支持软件复用的系统的管理过程。将项目专有需求转化为一般的领域需求。通用功能被用来做水平框架和可复用软件体系结构的基础。2441视图模型 逻辑 实现 进程 部署 用例 与UML紧密相连25软件体系结构风格 MVC风格 管道过滤器风格 客户服务器风格 层次系统 仓储(数据库和黑板)风格 面向对象风格 基于消息广播且面向图形用户界面的Chiron2风格 基于事件的隐式调用风格基本理念 IT行业的
10、人才结构与软件架构师的定位 软件架构师应掌握的知识体系 软件架构设计的特点、层次、分类 软件架构的主要理论、方向和趋势 软件工厂,实现软件开发的产业化27软件架构师在干什么?软件架构师在干什么?思考、思考、再思考 深入理解、准确把握建设的业务需求 分析所有可见的问题、障碍、风险 充分参考已有的成功方案,降低风险 交流、讨论、博弈、质疑 对构思中的方案不断提出质疑,避免漏洞 广泛听取各层面的意见,开拓思路 反复质疑、逐步完善已有的设计构思 在动手实现之前验证设计方案的正确性28软件架构师的知识结构软件架构师的知识结构 软件知识 最好要有系统开发全过程经验。对 IT 建设生命周期各个环节有深入了解
11、,包括:系统/模块逻辑设计、物理设计、代码开发、项目管理、测试、发布、运行维护等。深入掌握1-2种主流技术平台上开发系统的方法。了解多种应用系统的结构。了解架构设计领域的主要理论、流派、框架。29软件架构师的知识结构软件架构师的知识结构 业务知识 深入了解系统建设的业务需求。了解系统的非功能需求和运行维护需求。了解企业 IT 公共设施、网络环境、外部系统。30你知道那些知识?MFC,Msf,mof,rup,j2ee,spring,soa,junit,ORM,。net Mvc,uml,xml,corba,mda,mdd,webservice Rss,web2。0,ajax,serlet,hibe
12、rnate Ioc,aop,ruby on rails Rup Bpel Workflow engine LBS Oracle CMMI MQ31软件架构师的思维方式软件架构师的思维方式 基于框架的思维 架构设计的层次(Enterprise,Application,etc)IT 的生命周期(What,Why,Where,How,When,etc)成功经验以及方法论的指导 合理把握技术细节 把握各个层次应有的内容 合理忽略不应有的技术细节32软件架构师的思维方式软件架构师的思维方式 风险管理意识 采用成功经验、避免不应有的风险 多方位的开放思维 多维度、多方向、包容性、避免排他性 分析、质疑、抽
13、象、归纳 没有绝对好的架构设计,只有相对优秀的方案33软件架构设计过程举例软件架构设计过程举例 应用系统逻辑架构设计 目标:提供系统架构方案、满足业务需求、为物理设计提供依据。主要环节 根据系统主要的应用场景,确定系统概念架构。34软件架构设计过程举例软件架构设计过程举例 调研已有的成功参考架构和相关模式 提出系统逻辑架构,包括分层的整体逻辑架构、子系统/模块组成以及边界划分根据。讨论逻辑架构的依据、优缺点、以及已经考虑和参考的其它方案。设计相关子架构,包括:数据架构、子系统架构、安全架构、网络架构等。验证架构设计、确认能够满足业务需求和其他关键指标,如性能要求、费用限制等。35软件架构设计的
14、一些特点 处于软件系统建设的上游 需要全面考虑多方面的因素 对于同一个问题,可以有多种设计结果 是在各种制约条件下取得的较好折衷方案 科学+经验+艺术“系统架构”往往被滥用需求分析需求分析架构设计架构设计系统设计系统设计系统开发系统开发测试上线测试上线软件架构的层次层次特征说明Enterprise 关注 整个机构、企业所有 IT 系统的整体能力 从整体着眼、与业务紧密相关、与IT 规划相关最高层,人数极少Application 负责应用系统的架构,奠定系统建设的基础 关注系统内部的构成和子系统/模块的分划 需要负责与外部相关系统的互联互通系统架构最高层,大型系统需要有一个架构组System/S
15、ub-System 根据应用系统的逻辑架构制定相应的技术实现方式,设计系统的物理架构一个系统建设项目中常常有多个Component 负责系统模块的实现机制和详细结构设计 为系统开发建设奠定基础常常由系统工程是担任Data/Information 负责应用系统的信息和数据模型和结构 通常包括数据库模型和结构设计常常由数据库专家负责Security 负责系统的安全架构设计 涉及系统所有层面的安全措施需要由安全专家负责,极缺Network 系统内部、外部的网络拓扑设计常常由网络集成商负责Others 不同建设项目常常有一些特殊需求软件架构的分类软件架构的分类分类特征说明概念架构 关注 整个机构、企业
展开阅读全文