软件架构及设计培训课件.ppt

软件架构及设计中科信软培训中心•语言不是可伸缩性的关键，架构才是关键我们的疑问？•1、什么是架构？•2、为什么要架构？•3、什么时候进行架构设计？•4、怎样进行架构设计？我们能得到什么？•1、知道架构的3W1H•2、掌握架构的流程和管理•3、理解架构的设计和评审•4、知道如何评估软件架构质量软件架构设计概述•软件设计、软件架构概念•软件架构与软件过程•面向服务设计模式(SOAD)•RUP的4+1视图体系结构•软件架构国际标准什么是架构？•组成派–软件系统的架构将系统描述为计算组件及组件之间的交互（Thearchitectureofasoftwaresystemdefinesthesystemintermsofcomputationalcomponentsandinteractionsamongthosecomponents）–MaryShaw《软件体系结构：一门初露端倪学科的展望》•决策派–软件架构包含了关于一下问题的重要决策•软件系统的组织•选择组成系统的结构元素和他们之间的接口，以及当这些元素相互协作时所体现的行为•如何组合这些元素，使他们逐渐合成更大的子系统•用户知道这个系统组织的架构风格：这些元素以及他们的接口、协作和组合–软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制和权衡，以及美学–Rational统一过程•架构的组成与决策是架构设计的两个基本概念，这两个概念并不矛盾•在架构设计中，往往是同时体现这两个概念，确保架构满足产品要求。由这两个概念出发，我们自然会提出：•软件架构的核心思维到底是什么呢？什么是架构？•首先，任何软件系统都是以满足需求作为目的。所以，好的架构设计必须以全面深入的需求分析作为基础，根据需求来组织合理的产品架构。•其次，一个软件系统的质量，很大程度上是由架构设计的质量决定的，所以架构师的眼光一般都专注于质量属性上，应该根据产品质量属性的要求提出合理的架构决策。•另一方面，任何架构思想的实现，必须与具体的项目组织相匹配才能发挥作用。什么是架构？•一个是架构设计的源泉来自于需求分析•第二个是，架构设计重心和特点来自于质量需求（非功能性需求）•第三个观点是，架构整体特征应该考虑项目管理特征三个核心思维为什么要架构？--从软件危机谈起•软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题•在1968年国际软件工程会议提出，并被人们广泛认识软件危机的表现•¡软件成本日益增长•¡开发进度难以控制•¡软件质量差•¡软件维护困难软件危机的原因•¡用户需求不明确•¡缺乏正确的理论指导•¡软件规模越来越大•¡软件复杂度越来越高如何克服软件危机•人们面临的不光是技术问题，更重要的是管理问题。管理不善必然导致失败。•要提高软件开发效率，提高软件产品质量，必须采用工程化的开发方法与工业化的生产技术。•在技术上，应该采用基于复用的软件生产技术；•在管理上，应该采用多维的工程管理模式。诞生了软件工程•用工程、科学和数学的原则和方法研制、维护计算机软件的有关技术及管理方法•方法：“如何做”的技术手段•工具：为方法提供的自动或者半自动的软件支撑环境•过程：将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发地目的软件架构在软件工程中的作用？•软件架构是一个软件系统的设计图•¡解决复杂性问题•¡提高复用和构件市场的潜力什么时候进行架构设计？详细设计软件架构架构视图概要设计什么时候进行架构设计？•架构设计过程分为两个阶段：高层设计阶段和详细设计阶段怎样进行架构设计？•在高层设计阶段，主要工作是分析与设计软件的体系结构。通过系统分解，确定子系统的功能和子系统之间的关系，以及模块的功能和模块之间的关系，产生《体系结构设计报告》。•这个阶段是系统架构师发挥作用的主要位置，高层架构设计过程设计流程如下。怎样进行架构设计？设计准备确定约束因素确定设计策略设计评审系统分解设计撰写文档高层架构设计过程设计流程怎样进行架构设计？•在分析阶段，我们建立模型表示真实的世界，以便理解业务过程以及这个过程中所要用到的信息。•基本上说，分析首先是分解，把复杂信息需求的综合问题，分解成易于理解的多个小问题。•然后通过建立需求模型来对问题领域进行组织、构造并且编制文档。•分析建模过程必须要用户参与，并且需要用户解释需求，并且验证建立的模型是否正确。•设计也称之为架构设计，实际上也是个建模过程，它把分析阶段得出的信息也就是需求模型，转换为称之为解决方案的模型。典型项目案例介绍一、架构分析方法•面向服务设计模式(SOAD)二、架构视图•RUP的4+1视图体系结构三、软件架构国际标准•服务相关的标准：SOAP面向服务设计模式(SOAD)•应用软件开发方法的演变过程：•􀂄面向过程;•􀂄面向对象;•􀂄面向组件;•􀂄面向服务。面向服务设计模式(SOAD)什么是面向服务的体系架构?•一个组件模型•􀂄将应用程序的不同功能单元(服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。•􀂄构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务设计模式(SOAD)service-orientedArchitecture•􀂄SOA（service-orientedArchitecture，也叫面向服务的体系结构或面向服务架构）是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。•􀂄SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。SOA的优点•SOA框架的特点是以服务为中心，它把应用程序划分成具有明确定义接口的模块，从而得到服务和应用程序之间相当松散的耦合。•在SOA中，服务供应商和消费者是两个独立的实体。•面向服务的架构的优点主要体现在以下几个方面：•􀂄降低应用开发费用。•􀂄降低维护费用。•􀂄增长的公司敏捷性。•􀂄生成对应用程序和设备的故障、中断更具免疫力的系统，提高整体的可靠性。•􀂄提供了一条应用系统的升级途径，对比使用单一的应用程序的时候，需要替换整个应用系统的标准升级方法，显然更为经济，更不容易失败。SOA的特性•SOA有以下特性：•􀂄服务具有明确的接口（合约）与策略。•􀂄服务通常代表业务功能或者领域。•􀂄服务拥有模块化的设计。•􀂄服务被松散的耦合在一起。•􀂄服务是可以被发现的。•􀂄服务的位置对客户是透明的。•􀂄服务是独立于传输层的。•􀂄服务是独立于平台的。•SOA可以通过很多方式来实现，但最常用的SOA是用WebService来实现，这主要应为WebService的独立于平台的特性和其它特性更符合SOA的规则。构建SOA架构时应该注意的问题•当架构师基于SOA来构建一个企业级的系统架构的时候，一定要注意对原有系统架构中的集成需求进行细致的分析和整理。基于SOA的企业系统架构通常都是在现有系统架构投资的基础上发展起来的，我们并不需要彻底重新开发全部的子系统。•SOA可以通过利用当前系统已有的资源(开发人员、软件语言、硬件平台、数据库和应用程序)来重复利用系统中现有的系统和资源。SOA是一种可适应的、灵活的体系结构类型，基于SOA构建的系统架构可以在系统的开发和维护中缩短产品上市时间，因而可以降低企业系统开发的成本和风险。服务粒度的控制•当SOA架构师构建一个企业级的SOA系统架构的时候，关于系统中最重要的元素，也就是SOA系统中的服务的构建有一点需要特别注意的地方，就是对于服务粒度的控制。•服务粒度的控制SOA系统中的服务粒度的控制是一项十分重要的设计任务。通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。案例：电源销售服务系统高层架构•这里只列出了初步的顶层架构。案例：电源销售服务系统高层架构•设计中注意了几个问题：•1，对于管理层和客户，主要从使用方便性考虑，采用浏览器。•2，对于工作人员，因为要处理的内容比较复杂，采用应用程序，但是一个免维护的瘦客户端。•3，瘦客户段并不是指代码越少越好或者功能越少越好，而是把易变的、需要配置的、需要集中处理的内容转向应用程序服务器。事实上，客户端的功能越强，越能缓解服务器的压力。•4，某些特殊的专业通讯联系（比如信用卡授权机构），可以由客户段直接完成，并不一定一切都通过服务器，但需要向服务器提交必要的信息。•5，对于集中处理的部分，采用大粒度设计，以缓解网络压力。•6，由于服务方采用无状态模式，所以要严格控制客户调用信息的时间，对于需要长时间传输的信息，可以采用其它通道完成。•7，对于客户应用程序，某些不是十分大的，变化频度不是十分高的，调用频度比较高的数据，可以在客户端建立缓存，并且可以建立关联的映像表，这样就可以对避免对最主要的数据处理的挤压，提高数据库的应用效率，但要考虑修改数据时候的并发策略。什么是软件架构视图•一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。•也就是说，架构要涵盖的内容和决策太多了，超过了人脑一蹴而就的能力范围，因此采用分而治之的办法从不同视角分别设计；同时，也为软件架构的理解、交流和归档提供了方便。RUP的4+1视图体系结构“无体系结构”设计阶段萌芽阶段初期阶段高级阶段以汇编语言进行小规模应用程序开发为特征出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征出现了从不同侧面描述系统的结构模型，以UML为典型代表。以描述系统的高层抽象结构为中心，不关心具体的建模细节，划分了架构模型与传统软件结构的界限，该阶段以Kruchten提出的“4+1”模型RUP的4+1视图体系结构•PhilippeKruchten提出的4+1视图方法RUP的4+1视图体系结构•运用4+1视图方法针对不同需求进行架构设计RUP的4+1视图体系结构•4+1视图视图模型一览表设备调试系统案例概述•设备调试员通过使用该系统，可以察看设备状态（设备的状态信息由专用的数据采集器实时采集）、发送调试命令。该系统的用例图（场景）如图所示设备调试系统案例概述•设备调试系统的需求逻辑视图：设计满足功能需求的架构首先根据功能需求进行初步设计，进行大粒度的职责划分。如图所示。•应用层负责设备状态的显示，并提供模拟控制台供用户发送调试命令。•应用层使用通讯层和嵌入层进行交互，但应用层不知道通讯的细节。•通讯层负责在RS232协议之上实现一套专用的应用协议。•当应用层发送来包含调试指令的协议包，由通讯层负责按RS232协议将之传递给嵌入层。•当嵌入层发送来原始数据，由通讯层将之解释成应用协议包发送给应用层。•嵌入层负责对调试设备的具体控制，以及高频度地从数据采集器读取设备状态数据。•设备控制指令的物理规格被封装在嵌入层内部，读取数采器的具体细节也被封装在嵌入层内部开发视图：设计满足开发期质量属性的架构•软件架构的开发视图应当为开发人员提供切实的指导。任何影响全局的设计决策都应由架构设计来完成，这些决策如果“漏”到了后边，最终到了大规模并行开发阶段才发现，可能造成“程序员碰头儿临时决定”的情况大量出现，软件质量必然将下降甚至导致项目失败。•其中，采用哪些现成框架、哪些第三方SDK、乃至哪些中间件平台，都应该考虑是否由软件架构的开发视图确定下来。图展示了设备调试系统的（一部分）软件架构开发视图：应用层将基于MFC设计实现，而通讯层采用了某串口通讯的第三方SDK。处理视图：设计满足运行期质量属性的