系统软件架构及应用ppt课件.ppt

《系统软件架构及应用ppt课件.ppt》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

软件架构 实际工作之中架构师面临的经典难题驱动因素架构设计过程架构结果架构应用驱动因素不清楚不能深入全面理解架构驱动因素……输出混乱不能提供清晰的架构文档……思维过程乱不能系统有序进行思维……应用混乱设计人员和编程人员不知道如何应用架构…… 实际工作之中架构师面临的经典难题驱动因素架构设计过程架构结果架构应用驱动因素不清楚不能深入全面理解架构驱动因素……输出混乱不能提供清晰的架构文档……思维过程乱不能系统有序进行思维……应用混乱设计人员和编程人员不知道如何应用架构…… 软件架构的定义什么是架构？如果你问五个人不同的人，可能会得到五种不同的回答。——IvarJacobson《AOSD中文版》很多人都试图给“架构”下定义，而这些定义本身却很难统一。——MartinFowler《企业应用架构模式》 软件架构定义——决策过程角度和结果组成角度动词/过程观点Booch、Rumbeugh和Jacobaon的定义架构是一系列重要决策的集合名词/结构观点SEI定义程序或者计算机系统的软件架构应该是该系统一个（或多个）结构它由软件元素，元素的外部可见属性及它们之间的关系组成软件架构={结构,……}结构={元素，外部可见属性，关系} SoftwareArchitectureView(软件架构视图)单一的视图无法完整的表达架构，因此需要具备完整的视图集软件系统架构视图是从特定的视角出发，专注于该视角系统的结构，模块划分，基本组件职责和主要的控制协作接口。同时架构视图应该解释为什么架构是这样的。架构视图四要素图示化的主要元素和玩素之间的关系具有明确的图例，定义和说明元素每个元素具备明确的接口和行为规范设计原理和设计决策的信息 ArchitecturalBlueprints—The“4+1”ViewModelofSoftwareArchitecturePhilippeKruchtenRationalSoftwareCorp.AbstractThisarticlepresentsamodelfordescribingthearchitectureofsoftware-intensivesystems,basedontheuseofmultiple,concurrentviews.Thisuseofmultipleviewsallowstoaddressseparatelytheconcernsofthevarious‘stakeholders’ofthearchitecture:end-user,developers,systemsengineers,projectmanagers,etc.,andtohandleseparatelythefunctionalandnonfunctionalrequirements.Eachofthefiveviewsisdescribed,togetherwithanotationtocaptureit.Theviewsaredesignedusinganarchitecture-centered,scenariodriven,iterativedevelopmentprocess.Keywords:softwarearchitecture,view,object-orienteddesign,softwaredevelopmentprocessIntroductionWeallhaveseenmanybooksandarticleswhereonediagramattemptstocapturethegistofthearchitectureofasystem.Butlookingcarefullyatthesetofboxesandarrowsshownonthesediagrams,itbecomesclearthattheirauthorshavestruggledhardtorepresentmoreononeblueprintthanitcanactuallyexpress.Aretheboxesrepresentingrunningprograms?Orchunksofsourcecode?Orphysicalcomputers?Ormerely “4+1Views”Model功能需求质量属性可扩展性可维护性……质量属性易用性性能……安装部署要求 业务其他观点SEI（模块视图，组件和连接件视图，分配视图）西门子4种视图（概念，模块，代码，执行视图）美国国防部C4ISR架构视图（操作，系统架构，技术）RM-OOP（企业视图，信息视图，计算视图，工程视图） 常用软件架构视图类型逻辑视图开发视图部署视图进程视图场景视图数据视图实现视图 LogicalViewsMOdel消费者：客户/用户/开发组织管理者视角：系统的功能元素，以及它们接口，职责交互主要元素：系统，子系统，功能模块，子功能模块，接口用途：开发组织划分，成本/进度的评估 DevelopmentViewsMOdel消费者：开发相关人员/测试人员视角：系统如何开发实现主要元素：描述系统的层，分区，包，架构，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架用途：指导开发组织设计和开发实现 PhysicalViewsMOdel消费者：系统集成商/系统运维人员视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置主要元素：物理节点以及节点的通信用途： ProcessViewsMOdel消费者：性能优化/开发相关人员视角：系统运行时的线程/进程的情况主要元素：系统进程/线程以及处理队列等用途： WLSProcessViewWLSexecutesallrequestusingexecutethreadsThreadsareallocatedas:Readerthreads,forhandingnetworktrafficExecutethreads,forprocessinguserrequestsRRRRRRRIncomingRequestsRRRRRRExecuteQueueReaderThreadPoolExecuteThreadPool 多线程架构模式Half-Sync/Half-AsyncLeader/FloolwersActiveObjectMonitorObject ScenariosViewsMOdel消费者：设计和开发人员视角：概括了架构上最重要的场景（最典型和最有风险）及其非功能性需求，能过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式主要元素：用途：重要场景：1、风险用例2、典型用例3、业务级别高 DataViewsMOdel消费者：数据架构师和开发人员视角：系统数据模型以及数据存储/存取等主要元素：1：系统的核心实现模型以及相应的数据储模型和存储方式2：系统的数据存取相关策略3：系统核心的数据流用途： 模型的选择会影响最终产生系统的灵活性和可重用性。MartinFowler<分析模式>数据模型 ImplementViewsMOdel消费者：开发相关人员/测试人员/实施人员视角：系统交付物结构形式和相关实施规范主要元素：1：创建可交付物的形式（网页，DLL，可执行文件，源码）2：开发编程过程中必须遵守的相关规范和指南用途： 软件架构视图最佳实践最佳实践1-架构建模的方式最佳实践2-结合实际项目情况选择合适的视图最佳实践3-多视图可以组合最佳实践4-多视图并行设计 最佳实践1-架构建模的方式非标准标准UML建模文档描述 最佳实践2-结合实际项目情况选择合适的视图Notallsystemsrequireallviews:Singleprocess:dropprocessviewVerySmallprogram:dropDeploymentViewAddingViewsSecurityViewInterfaceViewBusinessProcessView 最佳实践3-多视图可以组合根据实际项目情况进行考虑视图组合 最佳实践4-多视图并行设计多视图的，是分而治之（总架构师负责协调保持一致性）多视图可以指导不同的团队并行思维 实际工作之中架构师面临的经典难题驱动因素架构设计过程架构结果架构应用驱动因素不清楚不能深入全面理解架构驱动因素……输出混乱不能提供清晰的架构文档……思维过程乱不能系统有序进行思维……应用混乱设计人员和编程人员不知道如何应用架构…… 驱动因素软件架构驱动因素软件系统质量属性定义和策略 驱动因素 软件质量属性-系统品质关注点在现实系统中，在决定系统的成功或失败的因素中，满足非功能需求往往比满足功能性需求更为重要。RobertCharette架构指明了功能性必须以何种品质交付，才能被系统的相关人员所接受，系统的结果包含这些人的既定利益。JohnKlein&DavidWeiss 架构驱动设计的2种哲学问题1：盲目追求新技术带来很大的风险问题2：忽略约束条件导致设计时过于理想化的运行环境无法支持问题3：忽略质量属性导致任务工作量评估时考虑实现功能忽略其他工作量 软件架构师对架构驱动因素的分析 驱动架构设计的因素1-软件功能关键软件业务需求（关键业务场景）1、Business-Critical（关键业务）。2、HighImpact（高影响）。功能需求的语境整理关键功能需求识别变化点和最具可能性的进化点系统变化点-当前现有系统和需求中变化之处。例如：必须支持多种资费策略系统进化点-现有需要中不存在，但是可能在将来发生推测性的变化点。比如：目前打印报表临时使用Excel文件导出。将来可能使用专业的报表工具。 驱动架构设计的因素2-系统质量属性 驱动架构设计的因素2-商业质量属性 驱动架构设计的因素3-系统受制于的约束 实际架构过程中质量属性面临的问题对质量属性的定义不具有可操作性，称某个系统是可修改的没有意义。质量属性是否实现不可度量 软件架构因素-质量分析软件架构因素分析中定义质量需求时推荐使用“质量场景”，因为它定义了可度量的（或者只是可以观察的）响应，并且因此能够加以验证，诸如：系统容易修改/系统高性能，这样含混描述很难具有实用性。SEI软件架构设计 实际工作之中架构师面临的经典难题驱动因素架构设计过程架构结果架构应用驱动因素不清楚不能深入全面理解架构驱动因素……输出混乱不能提供清晰的架构文档……思维过程乱不能系统有序进行思维……应用混乱设计人员和编程人员不知道如何应用架构…… 设计过程概论 架构是有生命的-架构需要溶化的在于晶纯眼里，架构是有生命的，是不断变化的。因此，她认为：设计架构不能只想着要考虑到所以的问题，设计出一个能够包容所有可能问题的架构，这几乎是不可完成的任务。任务变化是绝对的，架构总会需要修改，关键问题在于何时改？一定不能在系统问题频出、已经不来不及补救的时候才去考虑修改，而是在潜伏的问题逐渐露出端倪之前展开入进去。因此，架构是需要监控的。通过各项指标。在最适当的时候对架构进行最适当的重构。以满足变化的需求。FreeWheelCTO和联合创始人于晶纯 软件需求不可预测性！！ 软件架构师的设计之路希望架构师用一种理性的、不会犯错的方式从需求说明中推导出鏎架构。这画面根本就不现实。没有哪个系统是这种方式设计出来的，即便教科书和论文和小型程序设计也是不真实的，它们都是经过修订和修饰的，直到作者让他们看到他想到的结果，因而是不可能在实际中发生的过程。DavidParnas&PaulClement 同样，在烂代码的情况下，你也不停的在制造垃圾代码!!!!! 软件架构设计过程商业架构分析逻辑架构分析物理架构分析 架构的分阶段观点第一阶段：宏观决策逻辑和部署视图第二阶段：开发实现开发和进程视图第三阶段：业务结合数据，用例和实现视图 逻辑架构的设计步骤架构的复用-调查可用资产应用类型和架构风格引入架构模式软件架构立方图分析系统通用服务服务设计与实现每层架构的决策指南质量-场景-决策分析进程视图-运行时构架（进程或者线程的分布） 架构的落地步骤1：视图的细化和构建步骤2：设计框架步骤3：细化通用业务服务步骤4：完成架构文档，准备架构评审 应用架构视图逻辑视图（80%完成商业架构分析阶段）部署视图（80%完成商业架构分析阶段）开发视图（70%完成商业架构分析阶段）运行视图（70%完成商业架构分析阶段）数据视图（新开始）场景视图（新开始）实现视图（新开始） 实际工作之中架构师面临的经典难题驱动因素架构设计过程架构结果架构应用驱动因素不清楚不能深入全面理解架构驱动因素……输出混乱不能提供清晰的架构文档……思维过程乱不能系统有序进行思维……应用混乱设计人员和编程人员不知道如何应用架构…… 应用概论 软件架构应用过程软件架构评估验证软件架构基于架构和设计与开发架构的恢复与重构 软件架构评审软件架构是重要决策，如果错误决策对后期的开发会严重的错误通过评审可以带来沟通，公司管理导可以更加深入掌握系统开发各个方面的情况，从而更好的进行管理评审人员的分类如果可以使用外部独立的评审机制，可以很大程序上客观，中立反映系统的开发情况，为架构和设计的改进提供参考。评审本身就是公司内部系统 软件架构评估ATAM评估方法SAAM评估方法ARID评估方法 验证架构的2种方法完整架构实现原型（包含多个完整业务功能）原形法：原型的上报是快速探索可选的设计，这样可以尽早解决某些风险，使产品的发布版本免受危害，从本质上来说，这样的原形是不完整的，只完成了起码的工作，在它们完成任务之后是要被抛弃的。验证架构后期的应用环节。架构设计的风险点（关健点风险）就是将架构设计方案之中高风险点进行论证 架构恢复与重构步骤步骤1：建立反向工程与正向工程概念步骤2：架构和设计的恢复步骤3：架构和设计重构步骤4：系统代码重构 完！谢谢！