软件工程原理与实践（硕士）课件汇 沈备军 06-12 软件架构设计-软件工程新进展

高级软件工程

SoftwareEngineering软件架构设计软件架构设计软件架构是一系列重要决策的集合，这些决策关于：软件系统的组织；组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；如何组合这些些元素，使它们逐渐合成为更大的子系统；架构风格；这些元素以及它们的接口、协作和组合。Architecturedecisionsarethemostfundamentaldecisions,andchangingthemwillhavesignificanteffects.ArchitectureDesignImplementationCode2软件架构的主要建模方法文本语言建模方法基于非规范的图形表示的建模方法该图形表示不具有严格的标准，较为随意，具有一定方便交流的作用。如：盒线图（Box-LineDiagram）、PowerPoint风格图形等基于UML/SysML的建模方法

半形式化方法，UML/SysML

作为一个工业化标准的软件建模语言，支持多角度、多层次、多方面的建模需求，支持扩展，并有强大的工具支持基于AADL的建模方法半形式化方法，AADL是一个实时嵌入式软件系统的架构建模语言，适用于航天航空、汽车、自动化、医疗、核能等领域基于形式化的建模方法例如Petri-Net3软件架构设计的内容架构设计的内容：设计软件架构的多个视图物理视图、逻辑视图、进程视图、开发视图、技术视图、数据视图等选择软件质量属性的设计策略性能、可靠性、安全性、可移植性、可扩展性等架构设计的目标：使得软件系统在架构层面的设计上满足拟建软件的功能性和非功能性需求402-质量因素的架构设计战术01-软件架构的多个视图逻辑视图部署视图进程视图开发视图技术视图数据视图03-软件架构的质量5SoftwareArchitecture:The“4+1View”ModelProcessViewDeploymentViewLogicalViewUse-CaseViewImplementationViewEnd-userFunctionalityProgrammers

Softwaremanagement

PerformanceScalabilityThroughput

SystemintegratorsSystemtopology

Delivery,installationcommunicationSystemengineeringAnalysts/DesignersStructure

6LogicalView(逻辑视图)ProcessViewDeploymentViewLogicalViewUse-CaseViewImplementationViewEnd-userFunctionalityProgrammers

Softwaremanagement

PerformanceScalabilityThroughput

SystemintegratorsSystemtopology

Delivery,installationcommunicationSystemengineeringAnalysts/DesignersStructure

7Example1:Logicalview缺陷预测系统8基于非规范的图形表示的建模方法Example2:LogicalviewMiddleware<<layer>>BaseReuseglobalApplication<<layer>>BusinessServices<<layer>>NecessarybecausetheApplicationLayermusthaveaccesstothecoredistributionmechanismsprovidedwithJavaRMI.选课系统9基于UML的建模方法SecurityGUIFrameworkSecureInterfacesApplication<<layer>>BusinessServices<<layer>><<layer>>Application<<layer>>BusinessServicesExample:ApplicationLayerUniversityArtifactsRegistrationExternalSystemInterfaces10Middleware<<layer>>BusinessServices<<layer>>Example:BusinessServicesLayerContextjava.sqlcom.odi<<layer>>

MiddlewareBillingSystem<<subsystem>>CourseCatalogSystem<<subsystem>>ExternalSystemInterfacesUniversityArtifactsObjectStoreSupport<<layer>>

BusinessServicesGUIFrameworkSecureInterfacesSecurity<<subsystem>>SecurityManager11Example3:Logicalview12基于AADL的建模方法Example:飞行控制系统AADL架构13如何才能设计出好的软件架构？14复用现有的成功设计方案──设计模式(DesignPattern)的复用！软件设计模式1987年，模式的思想被引入软件工程方法学中。1995年，以ErichGamma为首的四人组(GangofFour，GoF)归纳发表了23种在软件开发中使用频率较高的设计模式，出版了《DesignPatterns:ElementsofReusableObject-OrientedSoftware》一书。软件设计的模式分类架构风格Architecturalstyle例如分层架构风格、MVC风格设计模式Designpattern例如Facade模式、工厂模式、单例模式编程惯用Idiom例如Java多线程编程模式15基于逻辑架构风格进行逻辑视图的设计表现层分离风格：MVC数据流风格(Dataflow)：批处理序列、管道－过滤器风格(Pipe-and-Filter)调用/返回风格：主程序/子程序、面向对象风格(ADT)、多层(Layer)分布计算风格：多层（Tier)、代理、C/S、P2P独立构件风格：事件响应、消息总线、服务和微服务虚拟机风格：解释器、基于规则的系统仓库风格：数据库系统、超文本系统、黑板系统自适应风格：微内核、反射、控制反馈……161)MVC

模型Model：管理系统中存储的数据和业务规则，并执行相应的计算功能。视图View：根据模型生成提供给用户的交互界面，不同的视图可以对相同的数据产生不同的界面。控制器Control：接收用户输入，通过调用模型获得响应，并通知视图进行用户界面的更新。172)管道和过滤器（PipesandFilters）Inthisstyle,eachcomponenthasasetofinputsandasetofoutputs.Acomponentreadsstreamsofdataonitsinputsandproducesstreamsofdataonitsoutput.18举例Linux的Shell程序可以看做是典型的管道与过滤器架构的例子例如下面的Shell脚本：$catTestResults|sort|grepGood

会将TestResults文件的文本进行排序，然后找出其中包含单词Good的行，并显出在屏幕上。Shell命令cat、sort和grep依次执行，就构成了一个管道-过滤器架构。19举例203)面向对象风格这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。214)层次架构（layeredarchitecture）风格GeneralfunctionalitySpecificfunctionalityDistinctapplicationsubsystemsthatmakeupanapplication—containsthevalueaddingsoftwaredevelopedbytheorganization.Businessspecific—containsanumberofreusablesubsystemsspecifictothetypeofbusiness.Middleware—offerssubsystemsforutilityclassesandplatform-independentservicesfordistributedobjectcomputinginheterogeneousenvironmentsandsoon.Systemsoftware—containsthesoftwarefortheactualinfrastructuresuchasoperatingsystems,interfacestospecifichardware,devicedrivers,andsoon.ApplicationSubsystemsBusiness-SpecificMiddlewareSystemSoftware上一层依赖下一层22不断提取共性！沉淀成为一层软件保持应用软件的复杂性相对稳定应用软件应用软件操作系统DBMS操作系统应用软件中间件操作系统应用软件DBMS中间件23中间件的分类1)数据访问中间件允许应用程序和本地或者异地的数据库进行通信，并提供一系列的应用程序接口（如ODBC、JDBC等）。该类中间件技术上最成熟，但局限于与数据库相关的应用。2)消息中间件可以屏蔽平台和协议上的差异进行远程通信，实现应用程序之间的协同，如IBM的MQSeries、BEA的MessageQ、SUN的JMS和微软的MSMQ等，其优点在于提供高可靠的同步和异步通信，缺点在于不同的消息中间件产品之间不能互操作。3)远程过程调用RPC中间件解决了平台异构的问题，但编程复杂且不支持异步操作。24中间件的分类（2）4）事务中间件是在分布、异构环境下提供保证事务完整性和数据完整性的一种平台，如BEA的TUXEDO、IBM的CICS、微软的MTS。其优势在于对关键业务的支持，但机制复杂、对用户要求较高。5）分布对象中间件在分布、异构的网络计算环境中，可以将各种分布对象有机地结合在一起，完成系统的快速集成。主流标准有Microsoft的DNA/COM+、OMG的OMA/CORBA、Sun的J2EE/EJB。Weblogic,Websphere,Jboss,.Net等应用服务器都包含了分布对象中间件，也有如Orbix、HPORB等独立产品。6）分布式服务中间件通过网络对松散耦合的业务服务进行分布式部署、组合和使用。Web服务中间件，其标准是SOA，应用服务器都包含了Web服务中间件，也有AXIS2、HPWebServicesPlatform等独立产品。微服务中间件，例如Dubbo。25层次架构实例26数字出纳员ATM出纳员付款开发票应用系统现金管理帐户管理发票管理特定业务银行客户管理ApplicationServerHPORBPlus中间件NTWorkstationMSSQLServer系统软件5)3Tiers表示层：负责向用户呈现界面，并接收用户请求发送给业务逻辑层；业务逻辑层：负责执行业务逻辑以处理用户请求，并调用数据访问层提供的持久性操作；数据访问层：负责执行数据库持久性操作。27表示层业务逻辑层数据访问层数据库举例286)基于事件的隐式调用构件不直接调用另一个构件，而是触发或广播一个或多个事件。系统中的其它构件订阅一个或多个事件，当一个事件被触发，系统自动调用订阅这个事件的所有构件，这样，一个事件的触发就导致了另一构件的调用。这种风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。29举例IDE：编辑器和变量监视器可以登记相应Debugger的断点事件。当Debugger在断点处停下时，它声明该事件，由系统自动调用处理程序，如编辑器可以卷屏到断点，变量监视器刷新变量数值。而Debugger本身只声明事件，并不关心哪些过程会启动，也不关心这些过程做什么处理。307)消息总线系统的连接件，负责消息的分派、传递和过滤以及处理结果的返回。各个构件(或系统、服务等）挂在消息总线上，向总线订阅感兴趣的消息类型。构件根据需要发布消息，由消息总线把该消息分派到系统中所有对此感兴趣的消息类型，消息是构件之间通信的唯一方式。31举例328）基于容器的微服务风格33服务架构风格服务的抽象性（基于接口的编程）服务的自治性（实现分布式应用）服务间的松耦合式绑定，基于消息进行通信单体架构VS微服务架构MonolithicapplicationVs.

Microservices34举例：单体架构（网络订餐系统）

35将应用程序构建为单个可执行和可部署组件随着业务的扩张，代码仓库急剧膨胀，构建和部署变慢，敏捷开发和快速交付很难实现。举例：微服务架构（网络订餐系统）

36通过API网关对来自移动应用的服务请求进行路由围绕业务能力组织服务服务数据私有基于轻量级通信协议的服务APISpringCloud微服务开发相关组件

37Zuul为外部的客户端应用访问后台服务提供了统一的接入点，实现了反向代理和服务端负载均衡，同时还实现了认证、鉴权、限流等网关管理功能Eureka服务端以服务的形式提供服务注册和发现功能，客户端以一种透明的方式为每个服务实例实现与Eureka服务端的交互，包括服务注册、心跳消息发送以及服务注册信息的拉取和本地缓存Ribbon实现了客户端负载均衡，提供了随机选择、轮询等不同的负载均衡算法，同时还实现了服务调用超时和重试等机制Hystrix为服务调用方实现了服务调用的熔断降级功能SpringCloudSecurityOAuth2为客户端提供认证和授权服务SpringCloudConfig为微服务应用提供了统一的配置数据管理服务微服务架构风格微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能够通过自动化部署方式独立部署，这些服务自己有一些小型集中化管理，可以是使用不同的编程语言编写。和SOA不同：SOA倡导粗粒度服务，而它是细粒度服务。同时，微服务采用“智能终端和哑管道”，它们拥有自己的领域逻辑，以类似Unix管道过滤方式运行，接受到一个请求，使用相应的逻辑，产生一个响应，这些都可以使用RESTful方式编排，而不是使用复杂的协议如WS-Choreography或BPEL或ESB指挥控制。和构件不同：它从内存方法调用转换到RPC远程方法调用，每个服务运行在自己的进程。优点：易于敏捷的开发、更新与部署，高度可扩展和可靠性38容器微服务的管理问题：因为服务通常部署在多个主机上，很难持续跟踪指定服务究竟运行在某台主机上。因为微服务架构使用的主机容量往往小于Monolithic架构，随着微服务架构不停的横向扩展，主机数量将以一个非常恐怖的速度增长。解决方案：容器不同容器共享相同的内核，容器的共享和发布非常简单容器之间进行了完全的隔离，简易了不同语言开发的微服务代码部署例如：Docker等39微服务容器镜像构建及实例创建

40镜像描述（如Docker容器的Dockerfile）指定了基础容器镜像（其中包含基础运行环境，例如Java运行时环境JRE），同时描述了一些软件安装和容器配置指令及容器实例创建时的初始化脚本在运行阶段，每台虚拟机实例上的容器运行时根据指令从容器镜像仓库中拉去不同服务的容器镜像（一般还需要指定版本）然后创建相应的容器实例（其中运行着对应的服务实例）仓库中可以包含同一服务的不同版本的镜像B容器编排与集群管理

微服务的容器化部署经常需要容器编排和集群管理工具的支持服务之间经常会存在依赖关系，同时服务还有可能依赖于消息代理和数据库等基础服务，因此仅仅以单个服务为单位进行实例创建和管理经常是不够的需要将一组相关的容器作为一个整体进行编排和管理容器编排与集群管理系统DockerCompose：可以在单个服务器或主机上创建并管理多个容器DockerSwarm：可以在多个服务器或主机上创建并管理容器集群Kubernetes：使用最广泛的大规模Docker编排和集群管理工具419)仓库风格和黑板风格仓库风格是以数据为中心的系统架构，它细分为：数据库系统以数据库为核心，各个构件存取数据。超文本系统用超链接的方法，将各种不同空间的文字、图片等信息组织在一起的网状文本黑板系统

为参与问题解决的知识源提供了共享的数据表示，这些数据表示是与应用相关的。在黑板系统中，控制流是由黑板数据的状态决定的，而并非按照某个固定的顺序执行。42黑板系统黑板系统专门针对没有确定的解决方法的问题，例如信号处理和模式识别，它通过多个知识源的协作来解决问题，而这种协作完全是状态驱动的，因此各个知识源具有公平的机会获取并更新黑板中的状态数据。黑板系统主要由三部分组成：知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。43举例撞击地球后产生的爆炸当量数据；第三类专家Expert3在看到新的数据后，根据自己的知识计算出了爆炸造成的破坏程度的数据，以此类推，最终所有的专家在一起得到了小行星撞击地球的应对方案。在整个过程中，控制流完全由黑板中的数据驱动，这就是黑板架构的特点。举例2：Siri系统最核心部分就是“黑板系统”，驱动调用大部分其他数据、模型和功能。类似于人的记忆系统的“工作记忆”，提供当前分析内容相关激活的本体等信息的临时存储以及集成调用各种模块进行处理。举例1：在系统中当黑板中初始数据是第一类专家Expert1根据自己的知识计算的有关小行星的质量、速度和运行轨迹等数据；第二类专家Expert2在看到这些数据后，根据自己的知识计算出了小行星4410)解释器架构解释器架构用于仿真当前不具备的计算环境，通常包含四个组成部分：用来解释伪码程序的解释引擎、包含待解释程序的内存、解释引擎的控制状态，以及被仿真程序的当前状态：45Example:JVM46基于规则的架构基于规则的架构是一种解释器架构风格，它将人类专家的问题解决知识编码成规则，这些规则在系统执行计算满足指定的条件时被执行或激活，通过规则不断地被执行和激活，最终使得问题被解决。由于这些规则不能被计算机系统直接执行，因此需要通过解释器来解释它们。4711)微内核风格微内核概念来源与操作系统领域。微内核是提供了操作系统核心功能的内核，它只需占用很小的内存空间即可启动，并向用户提供了标准接口，以使用户能够按照模块化的方式扩展其功能。现在大多数操作系统都采用了微内核架构。4812)开环和闭环控制风格49举例50DeploymentView(部署视图)TheDeploymentViewisan“architecturallysignificant”sliceoftheDeploymentModel.ProcessViewDeploymentViewLogicalViewUse-CaseViewImplementationViewEnd-userFunctionalityProgrammers

Softwaremanagement

PerformanceScalabilityThroughput

SystemintegratorsSystemtopology

Delivery,installationcommunicationSystemengineeringAnalysts/DesignersStructure

51又称为物理视图部署架构风格Client/Server3-tierFatClientFatServerDistributedClient/ServerServerlessPeer-to-peer(P2P)52Thinnerclient,thickerserverDatabaseServer(s)ApplicationBusinessObjectServicesClientABusinessObjectEngineClientCWWWBrowserClientBApplicationWebServerHTMLCGIASPJavaBusinessObjectServicesBusinessObjectEngineBusinessObjectServicesBusinessObjectEngineBusinessObjectServerDCOMADO/RCORBABeansCOMMTSBeansETS1）Client/ServerArchitectures53Example1:DeploymentDiagraminUML<<legacyRDBMS>>CourseCatalog<<CampusLAN>><<CampusLAN>><<CampusLAN>><<applicationserver>>RegistrationServer<<clientworkstation>>PCBillingSystem<<legacy>>0..200011111选课系统C/S54Example2:B/S和C/S混搭应用实例：B/S结构和C/S结构组合——“内外有别”模型55应用实例：B/S结构和C/S结构组合——“查改有别”模型56Example3:DeploymentDiagram环境远程监控系统57Example4:物联网的云边端一体化架构58云是指位于核心网中具有高可扩展的强大算力的计算中心；边缘侧是在移动网络边缘部署的服务器，它们靠近产生数据的移动终端，具备一定的数据存储和处理能力；端通常是指移动终端，它们具有更为受限的存储和计算能力，但是会产生大量的数据和数据处理任务。2）Serverless架构风格Serverless是一种基于互联网的技术架构，采用FAAS（FunctionasaService）架构，通过功能组合来实现应用程序逻辑。同时，Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的SLA，按照调用次数进行计费，有效节省应用成本。Serverless特点：弹性伸缩、按需付费、事件驱动、无需运维59一个典型的C/S三层应用程序转变为60基于无服务器架构的应用在无服务器架构中，没有单一的传统后端。通过API网关，应用程序的前端直接与服务、数据库或计算函数进行联系。613)P2PArchitecture所有计算机节点都是对等的，可相互调用。多种风格的混搭？B/S架构,Server端用P2P架构62ProcessView(进程视图)TheProcessViewisan“architecturallysignificant”sliceoftheprocessesandthreadsoftheDesignModelProcessViewDeploymentViewLogicalViewUse-CaseViewImplementationViewEnd-userFunctionalityProgrammers

Softwaremanagement

PerformanceScalabilityThroughput

SystemintegratorsSystemtopology

Delivery,installationcommunicationSystemengineeringAnalysts/DesignersStructure

63Example1:ModelingProcesses64composition<<process>>CourseCatalogSystemAccess<<thread>>CourseCache<<process>>CourseRegistrationProcess<<thread>>OfferingCachedependency1111<<process>>StudentApplicationExample2:ModelingProcessesinUML选课系统65进程间交互进程交互关系可以使用时序图（SequenceDiagram）来描述交互的参与方激活状态（即交互参与方在此期间处于激活状态）同步请求消息异步请求消息请求返回消息66ImplementationView(开发视图)ProcessViewDeploymentViewLogicalViewUse-CaseViewImplementationViewEnd-userFunctionalityProgrammers

Softwaremanagement

PerformanceScalabilityThroughput

SystemintegratorsSystemtopology

Delivery,installationcommunicationSystemengineeringAnalysts/DesignersStructure

TheImplementationViewisan“architecturallysignificant”sliceoftheComponentModel.67WhatIsaComponentDiagram?AdiagramthatshowstheorganizationsanddependenciesamongcomponentsCourse68Howmanyviews?SimplifiedmodelstofitthecontextNotallsystemsrequireallviews:Singleprocessor:dropdeploymentviewSingleprocess:dropprocessviewVerySmallprogram:dropimplementationviewAddingviews:Technicalview,Dataview,securityview69技术视图Technicalview技术选型：编程语言操作系统数据库框架中间件库70技术视图描述方式：文本技术视图在逻辑视图上标注在物理视图上标注选择合适的编程语言命令式（imperative）语言冯.诺伊曼C,Ada,Fortran…面向对象Smalltalk,Eiffel,C++,Java…脚本式Perl,Python,PHP…说明式（declarative）语言函数式Lisp/Scheme,ML,Haskell,Clean,Erlang,Miranda…数据流Id,Val…逻辑式或基于约束的Prolog,spreedsheets…基于模板的XSLT…量子编程语言Q#,Quipper,Sliq…71编程语言的排名TIOBEProgrammingCommunityIndex（/tiobe-index/）72选择合适的框架/中间件/库1.MVC框架SpringMVC、Struts2、JSF、Grails、GoogleWebToolkit（GWT）2.ORM框架MybatisHibernate、SpringDataJPA3.Web前端框架CSS框架：Bootstrap，FundationJS框架：VUE.JS,React.js,AngularJS,Ember.js4.并行计算框架

Hadoop,Spark,MapReduce5.服务与微服务框架

JAX-RS1.0+Jersey/CXF，SpringCloud，Dubbo6.深度学习框架

PyTorch,TensorFlow，Caffe等等73数据视图DataViewItisoptional.IftherearesomepersistentobjectsthatrequirepersistentstorageStorageMechanismsObjectdatabasesRelationaldatabasesNoSQLdatabasesOtherflatfilesXMLstructuresPalmOSPDBfileshierarchicaldatabasesandsoon74RelationalDataModelGenerateRelationalDataModel(conceptualdatamodelorphysicaldatamodel)fromObjectOrientedModelThenimproveitNote:Youcanalsogenerateitduringobjectorientedanalysisphase.75Example:RelationalDataModelERDiagram76O-RMappingTheProblem:Aswithrelationaldatabases,arepresentationmismatchexistsbetweenobjectsandthesenon-object-orientedformats.TheSolution:O-RMappingserviceapersistenceservicetranslateobjectsintorecordsandsavetheminadatabase,andtranslaterecordsintoobjectswhenretrievingfromadatabaseO-RMappingMiddlewareorPersistenceFrameworkSuchasHibernate,iBatis7702-质量因素的架构设计战术01-软件架构的多个视图03-软件架构的质量78质量因素的架构设计战术可用性和可靠性战术可维护性战术性能战术安全性战术可测试性战术易用性战术79可用性（availability）战术刺激响应战术80错误检测查错方法被动式查错在程序中需要进行检查的部位设置监测点，若实际执行结果满足接收判断，则判定程序运行正常，否则则出错。主动式查错设计一个检测监视器，在规定时间或规定的时间间隔内，或者是在系统处于闲置或等待的状态下，主动对系统进行检测。查错技术命令/响应：ping/echo一个组件发送ping，期望在预期时间内收到被审查组件的响应心跳：heartbeat组件定期发送消息（心跳），如果另一个组件没有收到，则通知纠错组件。异常：exceptions异常处理的程序接收判断：judgment日志和监控：logging/monitoring81被动式查错原则零信任原则在设计任何一个单元或者模块时，需要假设和它相互关联的单元或者模块存在错误。当该单元或者模块接收到数据时，首先假设该数据是一个出错数据，无论该数据来源于何处，然后尽力去证实该假设是否成立。对硬件错误进行检测设计例如电源失效、电磁干扰、系统不稳定、接口故障、干扰信号以及错误操作等的设计。数据检测设计按照已知的数据极限，检查数据范围。82错误恢复——修复接收表决，即N版本程序（NVP）技术冗余处理器的每个进程都有相同的输入，它们计算并发送给表决者一个输出值。（如果检测到某个错误，就停止该处理器）表决规则可以是“多数规则”或“首选组件”等注意多样性问题——冗余组件运行不同算法主动冗余（热重启）所有冗余组件都以并行的方式对事件做出反应（仅用其一）发生错误，就切换到某一个组件利用可靠传输协议，将传递给任何一个冗余组件的消息，都传递给其他所有组件被动冗余（暖重启/多重冗余）由一个组件负责对事件作出响应，并通知其他组件更新状态出错后，在继续提供服务之前，确保备用状态是最新的可以经常切换“主组件”，保持新状态备件（冷重启）替换各种的出现故障的组件定期对备件进行备份、设定检查点，出错后重新初始化。恢复时间可能稍长冗余技术83示例：航空控制软件的N版本程序（NVP）设计要求

根据系统安全评估，软件级别分为：A级软件：软件的失效或故障可能导致灾难性事故发生；B级软件：软件的失效或故障可能导致危险性事故发生；C级软件：软件的失效或故障不会导致人身安全问题，但会对机组造成较大影响；D级软件：对飞行安全的影响已降低到较小的程度；E级软件：无安全影响。NVP设计A级软件，推荐的失效容限为2，要进行5版本程序设计；B级软件，推荐的失效容限为1，要进行3版本程序设计；C和D级，无需软件冗余。84错误恢复——重新引入影子Shadow以前出现故障的物体，在恢复之前，模仿工作组件的内容状态再同步组件重新提供服务之前，需要更新其状态检查点/回滚使用上一个一致的检查点85错误预防软件运维时运行监测利用监视进程检查进程中存在的错误，监视进程可以删除没有在运行的进程。从服务中删除执行某些活动，防止预期可能发生的错误重启，防止内存泄露软件研发时减少和控制软件的程序复杂度模块化设计冗余设计提高数据传递和转换的精确性改善信息传递方式软件健壮性设计事务:将一些有序的步骤绑定为事务86可维护性战术刺激响应战术87局部化变更维持语义一致性语义，指的是模块内各责任之间的关系要确保这些责任能够协调一致地工作，而不过多地依赖其他模块耦合、内聚的程度是度量一致性的一个指标同时还应该根据是否支持预期的变更，来判断一致性程度预期可能的变更在实践中，往往很难预期所有重要的变更（经验）泛化该模块使模块能根据输入计算更广泛的功能可以把输入看作是为该模块定义了一种语言，对其进行解释限制可能的选择实际中可选范围往往很大，可能会影响很多模块例如，处理器的变更，可以限制使用相同家族的成员正交88防止连锁反应信息隐藏信息隐藏，就是把某个实体的责任分解为更小的部分，并选择使哪些信息成为公有的，哪些私有，目的是使变更被隔离在一个模块内维持现有接口创建抽象接口，与具体实现相分离添加接口：提供最新的服务或数据添加适配器：给A添加适配器，把A包装起来，提供原始A的信息限制通信路径限制与给定模块A共享数据的模块。即减少两类模块的数量，1，使用由A生产的数据的模块数量。2，给A提供数据的模块的数量仲裁者的使用对于非语义型的依赖，可以在A、B间插入一个仲裁者，管理与该依赖相关的活动89推迟绑定时间支持部署时（变更）及非开发人员的修改运行时注册即插即用。但需要额外的管理注册的开销配置文件在开机启动时，根据其设置参数多态允许方法调用的后期绑定组件更换允许载入时绑定遵守已定义的协议允许各个独立进程在运行时绑定90性能战术刺激响应战术91资源需求提高计算效率改进关键算法。用一种资源换取另一种资源减少计算开销例如删除一些仲裁者管理事件速率降低对环境监视的强度控制采样频率限制执行时间限制队列的大小92资源管理引入并发不同的线程上处理不同的事件流维持数据或计算的多个副本（注意一致性）例：高速缓存。增加可用资源提供额外的处理器、内存、速度更快的网络等。93资源仲裁：对竞争的资源进行调度常见的调度策略FIFO：适用于相同优先级固定优先级调度：可能使低优先级请求等待过多时间。常见优先级策略为：语义重要性时限时间：时限短（到期）的请求优先级高速率单调：对于周期任务，选择周期短的优先级高动态优先级轮转时限优先静态（脱机）调度系统执行前，基于被调度任务的时间参数来安排调度适用具有确定性时间要求的系统，例如空管。94示例：实时嵌入式软件的性能战术跳过操作系统直接访问硬件软硬件协同，利用硬件来实现软件的功能，例如进程间通信发挥硬件性能计算和IO的并行化用空间换时间，例如cache内存池进程池、线程池……95示例：淘宝的性能和可用性战术应用服务器微服务架构容器、集群和弹性扩容负载均衡和无状态服务CDN数据库读写分离分库分表集群内存数据库NoSQL数据库设计战术多级缓存消息队列、异步处理和限流异地多活熔断和降级……96安全性战术刺激响应战术97抵抗攻击对用户身份进行验证确保用户或计算机是它所声称的用户或计算机密码、数字证书对用户进行授权经过身份验证的用户，有什么样的访问权限访问控制维护数据的机密性加密数据，VPN，SSL维护完整性限制暴露信息限制访问防火墙根据消息源或目的端口，来限制访问98检测攻击将网络通信模式与数据库中的进行对比检测攻击的“传感器”将各传感器进行融合记录日志分析工具和控制台99100从攻击中恢复恢复状态（防守性）维持重要副本数据识别攻击者（惩罚性）维持审计追踪示例：平安银行系统的安全性战术101可测试性战术刺激响应战术102可测试性战术管理输入输出记录/回放：捕获跨接口的信息，将其作为测试专用软件的输入将接口和实现分离占位程序可以使得系统剩余部分得到检测特化访问路线/接口测试工具独立地捕获某些变量值内部监视内置监视器103易用性战术刺激响应战术104易用性战术运行时用户主动：撤销混合主动：提供进展指示器系统主动：预测与用户相关的某些信息维持任务的一个模型维持用户的一个模型维持系统的一个模型设计时将用户接口（可能频繁改变）与应用的其余部分分离开支持该战术的架构模式：MVC、PAC、Seeheim、Arch/Slinky105多目标权衡不同质量属性之间往往存在冲突，例如：性能VS.安全性可靠性VS.灵活性可维护性VS.高效性……排出优先级，进行多目标权衡106讨论你的大作业项目中哪个非功能需求（质量因素）最重要？采用哪些设计战术？10702-质量因素的架构设计战术01-软件架构的多个视图03-软件架构的质量108CharacteristicsofaGoodArchitectureResilientSimpleApproachableClearseparationofconcernsBalanceddistributionofresponsibilitiesBalanceseconomicandtechnologyconstraints1097种软件设计的坏味道1）僵化性（Rigidity）很难对软件进行改动，因为每个改动都会迫使对系统其他部分的许多改动2）脆弱性（Fragility）对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题3）牢固性（Immobility）很难解开系统中某部分与其它部分之间的纠结，从而难以使其中的任何部分可以被分离出来被其它系统复用1104）粘滞性（Viscosity）做正确的事情要比做错误的事情困难。表现为两种形式：软件粘滞性需要对软件进行修改时，可能存在多种方法。有的方法可以保持原有的设计质量，另一些方法则会破坏原有的设计质量。如果，破坏软件质量的修改比保持原有设计质量的修改更容易实施时，我们就称该软件具有“软件粘滞性”。环境粘滞性当开发环境迟钝、低效时，就会产生环境粘滞性。例如：如果编译时间很长，那么开发人员可能会放弃那些能保持设计质量，但是却需要导致大规模重新编译的改动。1115）不必要的复杂性（NeedlessComplexity）设计中包含不具有任何好处的基础结构。6）不必要的重复（NeedlessRepetition）设计中包含一些重复的结构，这些结构本来可以通过单一的抽象进行统一使用Cut/Copy/Paste实施源代码级的软件复用容易导致这一问题这种代码级别的冗余，将带来修改上的问题7）晦涩性（Opacity）很难阅读和理解，不要相信你永远都会如此清楚的了解你的每一行代码，“时间会冲淡一切”。要站在阅读者的角度进行设计112软件架构的质量评估基于场景的评估方法软件架构的评审基于度量和预测的评估方法软件架构的度量基于仿真和测试的评估方法软件架构的仿真与测试形式化验证113基于场景的评估方法

软件架构的人工评审初始工件基线工件规划总体会议准备评审会议改进重审方法举例SAAM方法ATAM方法114软件架构Checklist符合软件架构的模板多个架构视图的选择是合适的，每个视图是正确的逻辑视图、用例视图、进程视图、部署视图、数据视图、开发视图等采用的架构风格是合适的质量因素的架构设计战术是合适的支持所有的需求与目标计算机的硬件/软件特征（初始化、异步操作、同步和中断等）之间不存在冲突软件架构设计是明确的、无歧义的、一致的。无重要的设计遗漏应针对具体领域进行细化115基于度量和预测的评估方法(静态方法）

通过精确的度量，评估软件架构的内部质量特征复杂度耦合度内聚度扇入扇出数接口数…利用预测模型评估软件的外部特征（可维护性、可靠性等）116需要工具的支持方法举例SAEM方法PASA方法SAABNet方法SACMM方法SASAM方法ALRRA方法基于仿真和测试的评估方法(动态方法）

软件架构模型的仿真运行用以评估架构的性能、可靠性等比如，STOOD工具支持AADL模型的编辑、模拟仿真、性能分析等。软件架构原型的开发与测试用以评估架构的性能、可靠性、可扩展性、正确性等比如，核心算法的测试117需要工具的支持性能指标最大运行时间平均运行时间平均内存利用量内存利用平衡率最大内存占用量单位时间内存利用量软件架构的形式化验证软件架构的形式化验证（formalverification）通过模型检验或者推理验证的方式检查软件架构设计模型中是否存在安全性、活性、公平性以及一致性等方面的问题。安全性（safety）：指系统不应该达到的危险状态，即坏的事情是从来不会发生的。如：无死锁即是系统的一种安全属性活性（liveness）：指系统应该达到的正确状态，即好的事情最终是会发生的。如：系统中某进程进行了一个请求，该请求总能够得到回应。公平性（fairness）：指如何保证系统的资源能够公平地得到各个任务的使用,不会导致某些任务长期不能得到响应,即好的事情能否无限重复地发生。一致性（consistency）：指对于同一个架构，不同的人员有着不同的看法，就会产生不同的软件架构视图。如何采用形式化的方法来验证这些不同视图之间的一致性问题。118需要形式化建模和工具的支持高级软件工程

SoftwareEngineering软件质量管理与测试软件灾难苏联导弹预警系统软件故障差点导致第三次世界大战（1983年）造价80亿美元的Ariane5型火箭因浮点数溢出，被迫引爆自毁。原因是5型的发射系统直接重用了4型的相应代码，而4型的飞行条件和5型的截然不同（1996年）由北京南站开往福州站的D301次列车与杭州站开往福州南站的D3115次列车发生追尾事故，造成40人死亡，直接经济损失2亿元。原因是信号设备存在严重缺陷，遭雷击发生故障后，导致本应显示为红灯的信号机错误显示为绿灯（2011年）区块链业界最大的众筹项目TheDAO遭到攻击，导致300多万以太币资产被盗，原因是其智能合约中splitDAO函数有漏洞（2016年）印尼狮航一架波音737MAX8客机途中坠落，189人罹难，失事原因为软件设计缺陷，飞机的迎角传感器“数据错误”触发“防失速”自动操作，导致机头不断下压，最终坠海（2018年）120问题软件系统功能齐全是不是就是质量好？没有BUG是不是就是软件的质量好？什么是用户满意的软件项目？软件测试是不是软件质量的全部？那么，什么是软件的质量？如何保证软件的质量？12102-软件质量管理01-基本概念03-软件评审12204-软件测试软件质量的定义ANSI/IEEEStd729-1983定义“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。M.J.Fisher定义“所有描述计算机软件优秀程度的特性的组合”。123何谓软件质量好明确声明的功能和性能需求、明确文档化过的开发标准、以及专业人员开发的软件所应具有的所有隐含特征都得到满足。软件需求是进行质量度量的基础，与需求不符就是质量不合格指定的标准定义了一组指导软件开发的准则，如果不能遵照这些准则，就极有可能导致质量不好通常有一组隐含需求是不被提及的，如易维护性，如果软件符合了明确的需求却没有满足隐含需求，软件质量仍然值得怀疑124软件的质量属性质量的三种视角：内部、外部、和使用质量ISO/IEC25010:2011《软件工程产品质量》使用周境125ISO/IEC25010(SQuaRE)–Systemandsoftwarequalitymodels产品质量模型（外部质量和内部质量）126使用质量模型127质量与质量特性软件质量是各种质量特性的综合体现但具体产品中各质量特性的重要性与产品类型相关，例如关键任务系统(如银行)强调可靠性和安全性大众娱乐软件强调用户可用性广泛分发的软件服务(银行支付服务等)强调互操作性实时系统特别强调时间效率嵌入式系统特别强调资源效率具有一定用户面的特定领域产品强调可配置性和可维护性128质量特性之间的关系无关互补或依赖易理解性与易操作性可靠性与容错性：特性与子特性冲突安全性与性能可移植性与效率129质量成本130分类质量成本典型成分一致性成本预防成本质量管理体系建立和维持、软件过程改进、培训、工具、供应商评价等评价成本测试、评审、审核等非一致性成本内部故障成本重新设计、工期延期、BUG修复、返工、回归测试、纠错、资源闲置等外部故障成本客户投诉处理、故障处理、处罚及赔偿、市场影响、销售影响等02-软件质量管理01-基本概念03-软件评审13104-软件测试如何进行质量管理？ISO9000：质量计划、质量控制、质量保证、质量改进。ISO12207和SWEBOK

：软件质量保证、验证和确认、软件评审、软件审核、配置管理。SQuBOK：从组织级和项目级进行质量管理。132软件质量管理133项目级软件质量管理134软件质量计划是软件项目计划的子计划内容：质量目标开展质量活动的质量标准、方法、规程和工具验证、确认、评审、测试、审核、问题解决等质量活动和任务的安排开展质量活动的资源、日程和职责质量记录的标识、收集、归档、维护和处理的规程135验证和确认的定义V&V是一个用以分析、评价、测试系统和软件文档以及代码系统的过程，从而尽可能地确保质量、可靠性以及系统需求和目标满意度。

[IEEEStandardGlossary]验证(Verification)是“对系统或单元评价的过程，以确定一个给定的开发阶段的产品是否满足在此阶段开始时所给定的条件”确认(Validation)是“在软件开发过程期间或结束时评价系统或单元的过程，以确定它是否满足给定的需求”我们是否正确地完成了产品?我们是否完成了正确的产品？136质量评价在软件开发和运维过程中，收集与其执行过程、执行结果和成果相关的数据，进行质量评价。评价结果作为判定能否批准接收成果和进度状况的依据，并运用于过程改进。质量评价的对象软件产品（包括中间产品和最终产品）例如，项目在每个开发迭代结束时，都会以本次迭代的软件版本为对象，以软件需求规约为依据，遵循软件产品质量模型，进行正式的产品质量的评价，以确定项目是否进入下一个迭代？需求是否必须改动？软件开发是否需要更多的资源？等。软件过程例如，项目在每个开发迭代结束时，在产品质量评价的同时，对项目过程的质量进行评价，以确定是否要对过程进行修改。尤其当产品质量出现问题时，需分析是否由于过程的问题引起的。137软件质量管理技术138如何检测软件中的缺陷开发活动软件制品缺陷检测活动需求分析软件设计软件实现软件运行需求模型设计模型源代码可执行代码软件系统评审模拟形式化验证代码静态分析软件测试运行时监控静态方法动态方法139可靠性预测符号执行各种方法的缺陷检测效果来源：“美国国防部：软件技术进展”，2010年1401)软件评审审查小组评审走查结对编程同级桌查轮查临时评审正式化程度141系统分析和设计需求分析设计编码系统方案评审需求规范评审设计文档评审单元测试集成测试确认测试系统测试2)软件测试验收测试ɑ

测试

ß

测试试运行内部外部项目产品1423)代码静态分析不运行代码，通过词法分析、语法分析、控制流分析等技术，对代码进行检查，分析代码的结构，查找代码的问题（例如内存泄漏、安全漏洞、重复代码、未使用变量等），度量代码的质量（例如耦合度、内聚度、复杂度、重用度等）分析对象：源代码、bytecode或二进制代码可以由人工进行，也可以借助代码分析工具进行商用代码分析工具：Understand(多语言)、Sourceinsight(多语言)等开源代码分析工具：PMD和Checkstyle(Java)、flake8和pylint(Python)、SonarQube(多语言)等143常用的代码静态分析技术词法分析：从左至右一个字符一个字符的读入源程序，对构成源程序的字符流进行扫描，通过使用正则表达式匹配方法将源代码转换为等价的符号（Token）流，生成相关符号列表，Lex为常用分析工具。语法分析：判断源程序结构上是否正确，通过使用上下文无关语法将相关符号整理为语法树，Yacc为常用工具。抽象语法树分析：将程序组织成树形结构，树中相关节点代表了程序中的相关代码，目前已有javacc等抽象语法树生成工具。语义分析：对结构上正确的源程序进行上下文有关性质的审查。控制流分析：生成有向控制流图，用节点表示基本代码块，节点间的有向边代表控制流路径，反向边表示可能存在的循环；还可生成函数调用关系图，表示函数间的嵌套关系。数据流分析：对控制流图进行遍历，记录变量的初始化点和引用点，保存相关数据信息。污点分析：基于数据流图判断源代码中哪些变量可能受到攻击，是验证程序输入、识别代码表达缺陷的关键。

1444)符号执行

符号执行（symbolicexecution）是指在不执行代码的前提下，用符号值表示代码中变量值，然后模拟程序执行来进行相关分析的技术，分析代码的语义信息。符号执行分为：过程内分析是指只对单个过程的代码进行分析；过程间分析（又称全局分析）指对整个软件代码进行上下文敏感的分析。145intm=M,n=N,q=Q;intx1=0,x2=0,x3=0;if(m!=0){x1=-2;}if(n<12){

if(!m&&q){x2=1;}

x3=2;}assert(x1+x2+x3!=3)分析什么样的输入向量<M,N,Q>的情况下，得到的三个输出变量的和等于35)形式化验证形式化验证用以验证软件是否满足其规约的要求，常用于验证关键软件的安全性主要技术：定理证明(Theoremproving)模型检验（modelchecking）1466)模拟

模型的动态模拟用于需求分析与设计模型的质量控制例如：状态图与工作流的模拟运行等目的：更深入地看到需求和设计的完整性、正确性和合理性等，从而确保需求反映了用户的真实要求，设计能满足预期的需求。代码在宿主机/开发环境上的模拟运行模拟目标机/运行环境1477)运行时监控系统监控是对运行时软件系统的性能和可靠性等进行实时监视的技术，记录和分析运行日志、轨迹和抛出异常，检查系统的在线服务质量，并及时发现问题。三种监控手段：日志（Logging）、指标（Metrics）、追踪（Tracing）工具举例：Actuator、Prometheus、Grafana、LogStash、APM等1488)可靠性预测采用可靠性增长模型定量地评价软件可靠性。可靠性增长模型能根据测试阶段和运行阶段的数据推断出软件可靠性。因为随着测试及运行，缺陷被不断发现与排除，可靠性会随之增长，故称为可靠性增长模型。软件可靠性增长模型一般可分为：故障发生时间模型，如NHPP模型、马尔可夫过程模型等故障发现数量模型，如贝叶斯模型、危险率模型等149七种基本质量工具（7QC）150质量控制图151鱼骨图152Pareto图Pareto法则：80%的缺陷经常由于20%的原因引起的15302-软件质量管理01-基本概念03-软件评审15404-软件测试评审目的提高质量减少软件开发/维护的时间和费用提高生产率提高估算准确性培训EngineeringDocumentsRulesForwritingEng.Docs.软件评审Defects发现缺陷、预防缺陷155投资回报率从4:1到30:1Review:评审方法审查小组评审走查结对编程同级桌查轮查临时评审正式化程度从高到低156审查Inspection最系统化、最严密的评审技术被认为是软件工业中最实用的、最有效的评审方法严格定义的审查过程，明确的分工审查组长、读者、审查者作者、记录员157审查过程初始工件基线工件规划总体会议准备审查会议重写重审158受审查的工件初始工件基线工件规划总体会议准备评审会议重写重审项目计划需求规格说明书概要设计、详细设计系统测试计划、用例和报告代码

等159审查的规划初始工件基线工件规划总体会议准备审查会议重写重审审查组长判断是否已满足审查的进入标准作者和审查组长协同对审查进行规划，确定审查员和时间进度审查会议效率：每小时4~6页

审查人员不超过7人或者更少审查人员可以是开发人员、测试人员、项目经理、用户等160RelativeTeamEfficiency:MajorDefects/timeused(uniquetotal)2367CheckersonteamRelative

Effectiveness:MajorDefectsfoundperpage(totalbyteam).Source:SørenSkogstadNielsen,Denmark’sTechnologicalInstitute(DTI),Lyngby,Denmark(Switch+4543504350).MajorDefectsfoundperPage45MajordefectsfoundperHourNote:thischartisanapproximationandisnotexactEffectivenesspeaksataround5or6checkersEfficiencypeaksataround3to4checkers评审小组人数对效率的影响1161审查的准备初始工件基线工件规划总体会议准备审查会议重写重审将需求说明书等到交给每位审查员每个审查员以审查清单为指导，检查文档可能出现的错误，并提出问题75%的错误是在准备阶段发现的162审查会议初始工件基线工件规划总体会议准备审查会议重写重审参加人员：审查组长、作者、记录员、审查人员（选其中一个为读者）每次会议不超过2小时审查目标：尽可能多地发现问题，而不是解决问题递交：会议记录（问题和缺陷）、审查结论163重写初始工件基线工件规划总体会议准备审查会议重写重审由作者根据审查发现的问题，重写文档164重审初始工件基线工件规划总体会议准备审查会议重写重审由审查组长或指派人单独重审由作者重写的文档，确保所有问题得到解决，所有错误得到修改。由审查组长判断：是否已满足审查的退出标准165小组评审TeamReview评审过程计划、准备、开会、返工作者或评审组长主持会议读者这个角色被省略了，改由评审组长询问其他评审者这一部分是否有问题使用记录员使用缺陷检查表166走查Walkthrough评审过程计划、开会、返工作者主持会议，起主导作用，陈述产品常用走查方法使用一些样品数据一步步执行一个模块，和同事一道检查以确保正确的逻辑和行为。使用交互式调试器按脚本执行，脚本描述了一项具体的任务或场景，用以说明系统如何在用户会话中发挥功能167结对编程PairProgramming极值编程XP中的一个实践两个开发者在一个工作站上同时编写同一个程序，进行实时的、持续的、非正式的评审。司机和搭档的角色还要不时地交换。由于搭档的实时评审，结对者可以迅速纠正错误。快速的迭代能使设计和程序更加强壮。结对编程技术除了能应用于编码，还能应用需求、设计、测试等文档。168同级桌查PeerDeskcheck在两次编译之间仔细地检查源代码以保证程序正确执行，这就是桌查。桌查是PSP的组成部分,是一种自评审，不属于同级评审。在同级桌查中，除作者外的一位评审者对工作产品进行检查。评审者可以和作者坐在一起讨论，也可以独立检查。评审完成后，评审者把错误表交给作者，或者两人一起坐下来共同准备错误表，或者简单地将做过标记的工作产品交给作者。要寻找一位足够专业且值得信赖的人担任评审者。169轮查Passaround轮查是由多人组成的并行同级桌查轮查有助于缓和同级桌查的两个主要风险评审者不能及时提供反馈评审效果太糟170选择合适的评审方法评审目标审查小组评审走查结对编程同级桌查轮查查找产品缺陷√√√√√√检查规范的一致性√√

√√检查是否符合标准√

√√检查完整性/正确性√

√

评估可理解性/可维护性√