软件体系结构Chap05建模课件

第五章软件体系结构建模5.1软件体系结构建模概述5.2“4＋1”视图模型5.3软件体系结构的核心模型5.4软件体系结构的生命周期5.5软件体系结构设计2023/2/61§5.1软件体系结构建模概述根据侧重点不同，可分为5种：1、结构模型以体系结构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究核心是体系结构描述语言(ADL)；2、框架模型侧重于整体结构，以一些特殊的问题为目标建立只针对和适应该问题的结构；2023/2/623、动态模型

结构或框架模型的补充，研究系统的"大颗粒"的行为性质。例如，描述系统的重新配置或演化。4、过程模型

过程模型研究构造系统的步骤和过程，其结构是遵循某些过程脚本的结果。5、功能模型

将体系结构视为由一组功能构件按层次组成，下层向上层提供服务。一种特殊的框架模型。2023/2/63不同视图从不同的侧面描述系统；使得不同需求的人员能够得到他们对于软件体系结构想要了解的东西。逻辑视图(LogicView)；进程视图(ProcessView)；物理视图(PhysicalView)or部署视图(DeploymentView)；开发视图(DevelopmentView)or实现视图(ImplementationView)；场景视图(Scenarios)or用例视图(UseCaseView)；2023/2/652023/2/665.2.1

逻辑视图－－面向对象的分解面向最终用户；支持系统的功能需求，即系统提供给最终用户的服务；从问题域出发，采用面向对象的方法，按照抽象、封装、继承的原则，进行分解，得到代表着系统的关键抽象表示的集合；描述方法：RationalRose支持的Booch标记法。2023/2/675.2.3

进程视图面向系统集成人员；考虑是的一些非功能性的需求，侧重于系统的运行特性，主要是关注一些非功能性的需求，例如系统的性能和可用性。进程视图可以描述成多层抽象，每级分别关注不同的方面。2023/2/695.2.4

物理视图－－从软件到硬件的映射面向系统工程人员；物理视图主要考虑如何把软件映射到硬件上，它通常考虑到系统性能、规模、可靠性等；解决系统拓扑结构、系统安装、通信等问题；考虑的是非功能性的系统需求，如系统的可用性、可靠性(容错性)、性能(信息吞吐量)和可扩展性。2023/2/6105.2.5

场景视图－－汇总重要系统活动的抽象，它使4个视图有机联系起来，从某种意义上说场景是最重要的需求抽象；逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。

2023/2/611ROSE的视图用例视图；逻辑视图；构件视图；部署视图；2023/2/613ROSE的标记方法Booch标记法；面向对象建模技术(OMT:ObjectModelingTechnique)；统一过程方法(UnifiedProcess)；2023/2/6142023/2/6152023/2/617§5.3软件体系结构的核心模型2023/2/618体系结构的核心模型由五种元素组成：构件、连接件、配置、端口和角色；构件是具有某种功能的可重用的软件单元，表示了系统中主要的计算元素和数据存储，在体系结构中，一个构件可能小到一个过程或大到整个应用程序，它包括了多种属性，如接口、类型、语义、约束、演化和非功能属性等。接口是构件与外部世界的一组交互点。ADL中的构件接口说明了构件提供的那些服务（消息、操作、变量），是由一组端口组成，每个端口表示了构件和外部环境的交互点通过不同的端口类型，一个构件可以提供多重接口。类型是实现构件重用的手段，保证了构件能够在体系结构描述中的多次实例化，并且每个实例可以对应于构件的不同实现。连接件是用来建立构件间的交互以及支配这些交互规则的体系结构构造模块。与构件不同，连接件可以不与实现系统中的编译单元对应。他们可以是消息路由设备实现，也可以是共享变量、表入口、客户服务协议、管道、过程调用、应用程序中的SQL语句等；配置是描述体系结构的构件与连接件的连接图，是提供信息来确定构件是否正确连接、接口是否匹配，连接件构成的通信是否正确，并说明实现要求行为的组合语义2023/2/619软件系统实现各个阶段：1、需求分析阶段任务：根据需求，决定系统功能；特点：一个抽象思维、逻辑推理的过程；过程：需求获取、生成类图、对类分组、把类打包成构件，需求评审；结果：软件规格说明。2023/2/6212、建立软件体系结构阶段特点：从结构的角度对整个系统进行分析；任务和过程：选择体系结构风格、将构件映射到体系结构中，选择恰当的构件、构件间的相互作用关系、以及对它们的约束；结果：形成一个系统框架，为设计奠定基础。3、设计阶段对系统进行模块化，决定描述各个构件间的详细接口、算法和数据结构的选定；独立于系统开发的外部人员对体系结构进行评审。2023/2/6224、实现阶段将设计阶段的算法和数据结构用程序语言表示，满足设计体系结构和需求分析的要求；每个构件必须满足软件体系结构中说明的对其他构件的责任；通过组装支持工具把构件的实现体组装起来，完成整个系统的连接与合成。5、测试阶段单个构件的功能性测试和整个系统的功能和性能测试。2023/2/623软件体系结构的生命周期模型2023/2/625§5.5

软件体系结构设计体系结构的设计应支持对软件质量的需求，如健壮性、适应性、可重用性和可维护性等。体系结构决定了早期的设计决定，体现了系统的全局结构、对整个系统的质量有着决定性的影响。5.5.1体系结构设计方法的元模型元模型是对各种体系结构设计模型的抽象；元模型是各种设计方法的抽象，用于比较和分析各种体系结构设计方法；2023/2/626领域知识：解决某一问题所应用的知识的范围，包括问题领域知识、商业领域知识、解决方案领域知识、通用知识，等等；需求规格说明：表示规格说明，描述了所要开发的体系结构的系统需求；解决方案抽象：定义了体系结构中子结构的概念表示；体系结构描述：定义了软件体系结构的规格说明。2023/2/6272、用例驱动的体系结构设计从用例导出体系结构抽象；一个用例是指系统进行的一个活动序列，它为参与者提供一些结果值；参与者通过用例使用系统；用例模型作为系统预期功能及其环境的模型，在客户和开发者之间起到合约的作用；统一过程(UnifiedProcess)使用用例驱动的体系结构设计方法；问题：难以把握域模型和商业模型的细节；包的语义简单，难以形成体系结构构件。2023/2/6293、领域驱动的体系结构设计从领域模型导出体系结构抽象；领域模型可有不同的表示方法：如类、实体关系图、框架、语义网络、规则，等等；问题：问题领域分析在导出体系结构抽象方面效果较差，领域分析不足以驱动体系结构设计过程。2023/2/630特定领域的软件体系结构设计DSSA(DomainSpecificSoftwareArchitecture)；从领域分析阶段开始，面向一组有共同问题和功能的应用程序。参考需求包括功能需求、非功能需求、设计需求、实现需求；参考体系结构是用于一个应用系统族的体系结构，应用体系结构是用于一个单一应用系统的体系结构。2023/2/6314、模式驱动的体系结构设计软件设计模式的目的在于编制一套可重用的基本原则，用于开发高质量的软件系统；意图：表示使用模式的基本原则；上下文：表示问题的产生环境；问题：表示上下文环境中经常出现的问题；解决方案：以元素及其关系的抽象描述的形式来表示对问题的解决方案。2023/2/6325.5.3

软件体系结构设计基本原理一些最重要的支撑软件体系结构的原则：抽象Abstraction封装Encapsulation信息隐藏InformationHiding模块化Modularization注意点分离SeparationofConcerns内聚与耦合Cohesion

andCoupling充分性、完备性与原子性Sufficiency,Completeness&Primitiveness策略与实现的分离SeparationofPolicy&Implementation界面与实现的分离SeparationofInterface&Implementation分治Divide-and-Conquer层次化Layering2023/2/633用语言支撑开发需求描述语言构件描述语言模式描述语言框架描述语言构件编程语言过程控制和系统集成语言2023/2/634系统开发的集成平台各种支撑语言、制作构件。制作界面和I/O。构件管理和查询。实例生成和系统集成。2023/2/635模型表示方式模型分为四个部分描述：

1.组织描述系统的组织机构，有那些岗位及上下级关系；2.角色的责职功能描述各岗位上的责职，用IPO方式描述--即输入、处理和输出：3.数据各单据、文档等；4.过程(活动)处理各事务的流程，实际上这部分是冗佘信息，可作一致性和完备性检查用。仿真客观世界形成客观系统。2023/2/636组织客观系统设置那些岗位，以及这些岗位之间的关系，即客观系统中的体系结构，而通常这是一种层次结构，如：总经理下级有秘书和若干个副经理，它们又分管若干部门，每个部门中有一负责人，并设立若干岗位，他们之间有上下级关系，每个岗位又称为角色。2023/2/637角色每个角色要给以名称，即标志符。角色是要执行一列动作的。同时要给文档或文件进行记录。角色是系统中承担动作的人员、组织、设备。角色是作为独立成份看待。大角色，有自己的文档，与对外联系关系。但他又可以分成若干小角色，大角色的引入是为建立层次的分解，小角色是真正系统中有实质性的作用。2023/2/638角色必须与系统的目标有关，如银行中的警卫员与银行付款系统无直接关健，不能作角色。角色是客观系统中概念，不是软件系统中概念，也不是现实系统中概念。角色又分为二种，主角和配角，主角是系统主要完成某些功能而执行一系列动作，配角仅是起到触发系统工作的。2023/2/639角色的各种活动的动作序列每个岗位上要负责几件事，做每个事称为活动，每个活动是通过一系列动作完成。每个动作将如何记录文档，何时与其他角色进行联系。角色间的联系是一种通信联系，要给出联系的方式，如请求其他角色给以服务，即一种同步通信。或通知其他角色已发生了某事件，即异步通信。2023/2/640主角需完成某些活动，而配角没有活动，而只向某主角发送一个事件，配角之间的联系对客观系统是无意义的，而主角与主角间存在着紧密的联系。一个主角可以有承担多个活动，如收发人员承担收信、发信、订阅杂志、接待访问者，如外事人员，可承担外事活动，代办出国手续等，2023/2/641这些动作是要顺序执行，有些动作可以并行执行或重复执行，分别要给出标志用图形描述较为直观。每个动作通常是动作又分为二种,通信及IPO：对文档的输入、处理、输出操作；通信可以是发送或接受某个服务或事件。2023/2/642ARIS角色法需求建模该方法是面向企业领导的企业功能模型，它不仅是为软件开发用，也可用于企业诊断和改革用，现已有几百类企业的参考模型销售模型，每个约五万美元以上。已成为国际上名牌产品。用于开发时，需要依此建立逻辑模型。2023/2/643基于业务过程的ARIS方法ARIS体系结构ARIS――集成信息系统结构ARIS是TheArchitectureofIntegratedInformationSystems的缩写，是由谢尔教授发展起来的一种信息集成系统体系结构，其目的是为了寻求一种能够用来缩小企业与信息技术之间差距的应用框架，提供一种能够对业务流程概念进行准确描述和详细分析的方法，这种方法为企业信息系统的发展提供了一个起点2023/2/645苏东坡的《题西林壁》中描述庐山是“横看成岭侧成峰”，其实换个角度来讲，就是因为对于相同或不同的人在相同或不同的角度观察事物，在大脑中构建出来的模型是不一样的。同样对于企业而言，从不同的角度去考虑、去观察所看到的结构也是不一样的。归结到模型上，也就是同一个企业可以建出许许多多的模型，管理有管理的模型，业务有业务的模型，而信息系统也有它的模型，各个模型反映着企业的某个方面。当我们对一个事物进行观察，我们总是带着特定的目的，而那个事物在那个目的下它只会呈现出一种或两种样子，这一种或两种样子传递了事物的部分信息，当然如果要将一个事物完整的反映出来只靠这一两个样子显然是不够的。当我们回到业务流程建模上来时，对一个企业的业务流程进行建模，我们显然不可能依靠一个大的、单独的模型来反映整个企业。我们所要做的是构建出一系列相对较小，容易理解的，从各个特定方面反映企业业务流程的模型，然后再将它们通过某种方式结合起来形成一个完整的模型。这也是ARIS建模体系所使用的途径。在ARIS中有各种各样的模型，每一个模型包含有一系列的项目（对象）和连接（关系），而且在一个模型中出现的对象也可能同时会在其他的模型出现。ARIS体系结构

2023/2/646ARIS将对象和关系通过四种视图进行分类和组织

组织视图：组织结构的静态模型。包括：层次组织结构的人员(peoplenothuman)资源，生产资源(比如，设备，运输等)以及计算机、通信网络结构等。数据视图：业务信息的静态模型。包括：数据模型，知识结构，信息载体，技术术语和数据库模型等。功能视图：业务流程任务的静态模型。包括：功能层次，业务对象，支持系统和应用软件等。控制（业务）视图：动态模型，展示流程运转情况，并能够将业务流程与流程相关的资源、数据以及功能等联系起来。包括：事件驱动过程链、信息流、物流、通信图、产品定义、价值增值图等。2023/2/647ARIS-业务过程管理build-time-configurationIV.过程应用III.过程流I.过程设计业务过程重组参考模型II.过程管理对象库标准软件internetJava的程序数据库仿真质量管理建模分析导航模块

Internet文件夹执行信息系统控制监控进度和能力控制过程连续改善打开功能打开文档打开数据©Scheer2023/2/648ARIS方法

我们为什么需要企业过程模型?标准软件的介绍建立客观系统

(软件的开发)业务工程成本核算工作流系统的实施ISO9000质量论证(标准软件客户化)模型-今天(现状)-明天(目标)ARI