系统架构设计

系统设计概述

系统设计定义

系统设计是指在系统需求分析的基础上，运用软件工程的思想与方法，设计出能满足系统需求目标的新系统构造方案的活动。

系统设计过程

系统设计活动

1.系统架构设计

在系统架构设计中，需要对系统的总体架构、网络拓扑结构、软件架构、数据架构和应用架构等方面进行设计。

2.基础设施平台设计

在系统总体设计时，还需考虑信息系统的运行环境设计，即基础设施平台设计。在基础设施平台设计中，除了考虑系统的网络结构、网络结点通信关系、硬件计算资源能力、硬件存储资源能力设计外，还需要考虑系统运行软件环境设计，如操作系统软件、数据库系统软件、应用中间件等。

3.系统构件设计

系统构件设计是对系统的组成构件进行设计，确定出系统构件功能逻辑、构件接口等。

4.系统界面设计

界面设计是对人和外部系统与信息系统之间交互界面设计。它包括操作界面、表单、报表、系统接口等要素设计。

5.系统数据库设计

数据库设计是指根据特定的系统应用需求，设计出合理的系统数据库结构。数据库设计需要经过概念设计、逻辑设计和物理设计等步骤。

6.程序流程设计

程序流程设计是对构件内部功能逻辑进行设计，确定算法程序流程及其数据结构。

7.安全机制设计

安全机制设计是对系统与数据的安全访问、隐私保护等安全措施与手段进行设计。

系统设计基本方法

1.抽象化

• 抽象是在系统规模大、逻辑复杂的情况下，降低系统设计复杂性的基本策略。
• 抽象的过程是从特殊到一般的过程，上层概念是下层概念的抽象。通过抽象实现系统设计建模。

2.逐步求精

• 逐步求精，把问题的求解过程分解成若干步骤或阶段，每步都比上步更精化，更接近问题的解法。
• 抽象使得设计者能在宏观层面描述过程和数据而忽略低层的细节，而求精有助于设计者在微观层面设计低层技术细节。

3.模块化

• 模块化，即把一个大系统按照特定规则，划分为若干较小的，又相互关联的部件，以便将复杂问题分解为简单问题进行解决。
• 模块是数据说明、可执行语句等程序对象的集合。它是单独命名的、可以通过名字来访问的功能部件，如程序的过程、函数、子程序、宏等。

4.信息隐藏

• 每个模块的实现细节对于其它模块来说应该是隐蔽的，模块之间实现松耦合，以便实现软件构件的可复用性。
• 模块中所包含的信息（包括数据和过程）只能通过接口访问，以便支持模块的可维护性。

5.模块独立

• 模块完成独立的功能，并且与其他模块通过接口关联，符合信息隐蔽和信息局部化原则，模块间关联和依赖程度尽可能小。
• 模块独立便于功能被划分，更易于开发和维护。
• 模块独立性可以由两项指标来衡量:内聚度与耦合度。

系统设计原则

1. 建立良好的系统体系架构，以满足系统的可靠性、安全性、可伸缩性、可维护性等非功能特性需求。
2. 系统设计应采取模型抽象、模块化设计，将复杂系统分解为较简单的子系统及其构件进行开发。
3. 采用标准建模语言方式直观、明确地表达设计思路，对系统架构、应用架构、软件架构、数据架构、系统构件、用户界面、程序逻辑等设计内容采用可视化模型表示。

系统设计方法分类

面向对象系统分析与设计建模过程

系统架构基础

系统架构定义

系统架构（又称系统体系架构）是指系统的组成结构模式，它由反映系统部件的关联性、交互性和约束机制进行描述。

系统架构设计定义

系统架构设计根据系统需求，从不同层面、不同视角给出系统总体框架的设计蓝图。

系统架构作用

• 系统架构反映系统设计总体框架，有利于开发者围绕系统设计进行交流与讨论。
• 系统架构体现系统设计策略，它对系统开发工作有深远的影响。
• 系统架构决定了系统非功能特性，如系统可靠性、可用性、安全性、可伸缩性，以及系统性能。

系统架构类型

系统总体架构

系统总体架构是从全局层面给出系统各种组成要素之间结构关系。它通常包括基础设施、运行平台、应用软件、业务部门、信息数据以及用户等。

Power Designer实践练习——证券客户关系管理平台系统总体架构设计

系统拓扑架构

系统拓扑结构是指从系统基础设施平台层面描述节点与节点之间的通信连接关系。节点是指系统中处理逻辑相对独立的物理实体，如PC计算机、服务器、外围设备等。

系统拓扑结构设计是从系统基础设施平台层面给出系统节点在网络环境中的结构关系，包括节点分布、节点类型、节点运行环境以及节点之间的通信联系。

系统拓扑架构类型

系统拓扑架构技术演化阶段

系统拓扑架构案例

建模实践练习——电子政务系统拓扑架构设计

建模实践练习——电子商务系统高可用拓扑架构设计

系统数据架构

系统数据架构是指从数据管理视角所描述的系统架构，它通常用来反映各类数据咨源的组织与存储。

• 系统数据架构不仅需要反映机构的数据结点分布关系。
• 还需要考虑数据资源的存储结构与存储方式，如文件存储、数据库存储或数据仓库存储。

系统数据分层架构设计

在大数据应用系统中，按照数据不同处理要求，可以将它们组织到不同层次的数据管理系统进行计算与分析处理。

系统数据治理架构设计

在信息系统中，数据资源结点一般是按照业务管理的需求，将它们部署到不同业务部门服务器进行数据存储与访问管理。系统数据治理架构与组织机构的数据管理职能有直接关系。

系统数据存储架构设计

在信息系统中，一些数据资源需要采用文件系统存储，另外一些数据资源需要采用数据库系统存储，还有一些数据资源则需要数据仓库系统进行数据存储。每类存储系统在设计上需要满足应用需求，如支持高可用、高性能的存取访问。

数据架构设计案例——电子政务系统数据架构

系统应用架构

系统应用架构是指从应用功能视角所描述的系统架构。系统应用架构关注立用功能划分、应用功能配置、服务访问、服务管理等要素。

应用架构类型

1. 企业级应用架构:在企业信息化全局层面，系统应用架构起到了统一规划、承上启下的作用，向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。一般在系统规划阶段设计。
2. 单个系统的应用架构:在开发单个信息系统时，设计系统的应用功能结构，并考虑系统各个层次的功能结构组成，如前端展示层、业务处理逻辑层、数据访问层的功能模块结构。一般在系统开发阶段设计。

应用架构层次设计

应用架构设计案例——供应商管理系统应用架构

建模实践练习———供应链系统应用架构设计

软件体系架构

软件体系架构（简称软件架构）是一种从软件视角所描述的系统架构，它对软件系统的结构、行为进行高层抽象，一般通过构件、连接件、
配置、端口、角色等图符元素进行描述。

• 构件(component） :具有特定功能的、可重用的软件模块。
• 连接件(connector) :用以表示构件之间的交互，如过程调用、事件广播、交互协议等。配置(configuration）:用于对构件与连接件的拓扑逻辑、语义约束等说明。
• 端口(port）:表示构件接口与外部环境的交互点。
• 角色(role) :连接件的参与者，如事件消息的发布者与接受者。

软件架构设计定义

软件架构设计是指基于一定的设计原则和系统需求，从软件角度对组成系统的各部分进行划分和组织，设计系统的构件组成结构及其构件之间的相互关系。

软件架构设计目标

在软件架构设计中，除了满足系统功能需求外，还应满足系统非功能需求，即达到如下质量目标。

1. 可靠性（Reliable）——软件系统具有可靠运行的能力。
2. 安全性(Secure)——软件系统具有安全运行的能力。
3. 可伸缩性(Scalable）——软件系统具有在用户访问量、并发用户数发生变化情况下，保持合理运行性能和资源利用率的能力。
4. 定制化(Customizable）——软件系统具有个性化系统功能定制的能力。
5. 可扩展性(Extensible)——具有对系统进行功能和性能扩展的能力。
6. 可维护性(Maintainable）——具有进行软件修改或软件进化的能力。

软件架构设计案例——电子商务系统软件架构

软件技术架构

软件架构风格

软件架构风格定义

软件架构风格是指针对不同系统共性问题提供一般性可重用的软件架构解决方案，它反映了领域中众多系统所共有的软件结构及其模式。

软件架构作用:用于指导开发者将软件构件、子系统有效地组织成一个完整的软件系统。

软件架构风格要素

软件架构风格描述了特定应用领域中软件系统构件组成的惯用模式，其要素如下:

• 软件架构包含哪些类型的构件与连接件?
• 组成系统的结构模式是什么?
• 基本的计算模型是什么?
• 架构的基本特性是什么?
• 架构应用的场景是什么?
• 架构的优缺点是什么?

软件架构风格应用意义

• 定义了一类软件系统架构的要素和一组指导系统架构设计的规则。
• 可促进软件系统设计的复用，使得一些经过实践验证的软件架构方案能够可靠地解决新问题。
• 通过对标准软件架构风格的应用可支持不同系统之间互操作性，以便于实现系统集成。
• 在特定设计空间下，便于对软件系统相关设计作出分析。

软件架构风格分类

风格类型	典型风格
数据流风格	批处理序列架构、管道/过滤器架构
调用/返回风格	主程序/子程序架构、面向对象架构、分层体系架构
独立构件风格	进程通讯架构、事件驱动架构
虚拟机风格	解释器架构、基于规则的系统架构
客户/服务器风格	客户/服务器架构、浏览器/服务器架构
面向服务风格	面向服务架构(SOA)、微服务架构
仓库风格	数据共享体系架构、黑板系统架构

分层体系架构

分层体系架构采用层次化方式组织功能构件，每一层都是为上一层提供服务，并使用下一层提供的功能服务。

• 将软件系统分成若干个水平层，每一层都有清晰的功能处理分工，各层不需要知道其他层的细节，层与层之间仅通过接口通信。
• 用户对软件系统的访问请求将依次通过各层功能逻辑构件进行处理，不允许跳过其中任何一层。

应用案例:Linux系统架构

分层体系架构优点:

• 便于复杂系统设计，使整体设计更加简洁与清晰。
• 支持系统功能扩展设计，每层的功能修改最多只影响相邻层。
• 只要给相邻层提供标准接口，就可实现功能复用。

分层体系架构缺点:

• 并不是每个系统都可以很容易地划分层次，此外，层次的划分还没有统一的方法。
• 层次过多，会造成系统性能降低。
• 当用户请求大量增加时，必须依次扩展每一层处理能力。如果某层的内部是耦合的，系统扩展较困难。

数据共享体系架构

数据共享体系架构是一种以数据存储服务器为中心，为客户软件提供数据共享、数据交换访问的软件架构风格。

• 在数据共享体系架构中，各个客户软件相互独立，它们通过共享数据存储实现数据交换。
• 一个客户软件对共享数据进行了修改，其他客户软件可以获得数据变更信息。

应用案例:基于数据共享体系架构的数据挖掘与分析系统

数据共享体系架构优点:

• 体系架构简单，容易实现软件开发。
• 可有效地实现大量数据共享，新客户软件加入系统，无须考虑其他客户软件的存在。
• 只要遵循共享数据访问接口，各个客户软件可以独立执行。

数据共享体系架构缺点:

• 当共享数据结构发生变化，各客户软件都需要进行数据访问调整，通常比较麻烦。
• 当客户软件大量增加时，共享数据存储服务器将面临性能压力。
• 共享数据存储服务器作为系统的中央单元，若没有考虑高可用性方案，它一旦故障将导致整个系统无法运行。
• 共享数据存储难以实现分布式处理。

事件驱动体系架构

事件驱动体系架构是一种基于事件与消息机制实现软件构件之间进行通信的软件架构。

• 构件（子系统)之间并不直接交互，而是通过触发一个或多个事件，隐式调用另一构件执行。
• 系统各构件需要在消息处理器中注册相关事件，一旦事件触发，将隐含调用注册构件进行处理，并将处理结果返回事件发布构件。

应用案例:Windows事件驱动模型

事件驱动体系架构优点:

• 具有良好的可扩展性。通过注册可引入新的构件，而不影响现有构件。
• 便于软件维护。只要构件名及其接口不变，可以用一个构件代替另一个构件。
• 构件之间耦合性低，容易实现软件重用。

事件驱动体系架构缺点:

• 事件驱动削弱了构件对系统的控制能力。一个构件事件触发时，并不能保证其它构件会对其进行事件响应。
• 消息传送机制不能很好地解决数据交换问题。

客户机/服务器软件架构

客户机/服务器软件架构是一种典型的分布系统体系架构，其软件分为客户端构件和服务端构件，客户端构件通常在客户机上运行，服务端构件在服务器上运行。

• 客户机/服务器架构采用分布式系统模式，它通常将界面展示、应用逻辑与数据存取构件分布在多个节点机上进行处理。
• 客户端构件为完成特定功能，需要向服务端构件发出请求。服务端构件接收客户端构件请求进行处理，并将结果返回请求者。
• 客户端与服务端构件一般是分别部署在客户机和服务器中，通过网络连接进行通信，也可以将它们部署在同一物理机器内部。

C/S架构原理

应用案例:基于C/S架构的企业固定资产管理平台

C/S架构优点:

• 可实现分布式计算处理，有利于系统负载分担。
• 交互性强、具有安全的存取模式、响应速度快、利于处理大量数据。

C/S架构缺点:

• 缺少通用性，系统维护、升级需要重新安装部署，增加了维护和管理的难度。
• 只限于小型的局域网应用。

B/S架构原理

应用案例:基于B/S架构的物流管控系统平台

B/S架构优点:

• 分布性强——服务器可以在任何地点运行。
• 访问方便——只要有网络、浏览器，就可以对系统应用进行访问。
• 系统处理负载能力强——可以将负载分布在Web服务器、应用服务器、数据库服务器处理。此外，通过负载均衡、集群技术可以支持更大负载处理。
• 系统运维方便——只需要在服务器进行功能修改与发布，即可实现所有用户访问的同步更新。
• 用户共享性强——可以支持不同地点用户共享访问系统。

B/S架构缺点:

• 个性化处理、人机交互性能不如C/S架构软件。
• 在系统安全性设计需要考虑更多内容。

微核体系架构

微核体系架构又称为“插件架构”，系统基本核心功能在软件内核中实现，其功能较少，系统大部分功能和业务逻辑都通过插件实现。

• 微核体系架构将待开发的目标软件分为软件内核和插件两个部分。
• 内核实现软件的基本核心功能和插件管理功能。
• 插件实现软件功能的运行时扩展与补充。它是一种按照统一插件接口规范实现的功能程序。

应用案例:Eclipse开发平台

微核体系架构优点:

• 良好的功能扩展性，需要什么功能，开发一个插件即可。
• 插件之间是隔离的，可以独立的加载和卸载，使得它比较容易部署。
• 可定制性高，适应不同的开发需要。
• 可以渐进式地开发，逐步增加功能插件。

微核体系架构缺点:

• 伸缩性差，内核通常是一个独立单元，不容易做成分布式。
• 开发难度相对较高，因为涉及到插件与内核的通信，以及内部的插件登记机制。

微服务架构

微服务架构(microservices architecture）是面向服务架构( service-oriented architecture，SOA）的轻量级实现版本。

• 将应用软件划分成一组小型服务，服务之间相互协调与配合，为用户提供功能服务。
• 每个服务运行在独立的进程中，服务之间采用轻量级通信机制进行消息交互。
• 每个服务都围绕业务进行构建，并且能够独立部署到运行环境。
• 这些服务都是分布式的，互相解耦，通过标准通信协议（如REST、SOAP）进行交互。

应用案例:淘宝开放平台

微服务架构优点:

• 扩展性好，各个服务之间低耦合。
• 容易部署，软件从整体部署拆分成多个独立功能服务进行部署，可以分别进行服务部署。
• 容易开发，每个服务都可以进行持续迭代开发，可以做到实时部署，不间断地升级。
• 易于测试，每个服务可以单独测试。

微服务架构缺点:

• 由于强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得凌乱和笨重，性能也会不佳。
• 分布式处理使得微服务较难实现原子性操作，交易回滚会比较困难。

软件架构模式

软件架构模式定义

软件架构模式就是针对特定需求问题及其环境，所给出通用的软件架构设计解决方案。软件架构模式相对软件架构风格，所涉及范围要窄些，解决更具体问题。

软件架构风格	软件架构模式
分层架构风格	代理者模式
数据共享架构风格	发布/订阅模式
事件驱动架构风格	多客户/单服务模式
客户/服务器风格	多客户/多服务模式
微核架构风格	多层客户/服务器模式
面向服务风格	异步消息通信模式、同步消息通信模式
数据流风格	服务代理转发通信模式
虚拟机风格	复合事务模式
异构风格	MVC模式、MVP模式、MVVM模式

软件架构模式意义

1. 使得软件工程成熟的架构设计方案可以被复用，避免重复“发明车轮”

   的设计工作。

2. 为软件系统重构提供架构模式支持，从而完善原软件系统架构。

3. 基于架构模式方法设计软件系统，可以节省开发成本，提高软件开发效率。

4. 在软件系统设计中，使用架构模式方法，还可以提高系统设计质量。

软件架构模式应用方式

软件架构模式的描述模板

模板项目	内容描述
模式名称	每一个模式都有自己的名字，以简短的、明确含义的名称描述架构模式本质
解决问题	描述该模式需要解决的设计问题
环境	描述问题所在环境，包括应用领域
解决方案	提供问题解决方案的详细说明
优缺点	描述本架构方案的优缺点
适用性	描述本架构模式的适用场景
相关模式	相关架构模式说明

代理者模式的描述模板

模板项目	内容描述
模式名称	代理者
解决问题	在分布式应用的多个客户端与多个服务通信中，客户端不知道服务的位置。
环境	分布式系统
解决方案	服务构件向代理者注册，客户端发送服务请求给代理者，代理者扮演客户端和服务的中介。
优缺点	优点: 客户端可以不需要知道服务位置，服务可以透明在系统中更新、加入。 缺点: 客户端与服务通信涉及了代理者的额外开销。如果代理者有高负载，代理者将成为系统性能瓶颈。
适用性	分布式环境中，有多个服务的客户/服务器应用。
相关模式	代理者转发

软件架构结构模式

在软件架构模式中，反映软件构件组成及其控制关系的结构模式主要有如下几种:

代理者模式

• 在代理者模式的软件架构中，需要使用代理者扮演客户端和服务端的中介角色。
• 代理者使得客户端不再需要知道某个服务在哪里，就可以获得这个服务，从而使得客户端可以方便地定位服务。

案例：客户client对象在访问一个业务服务（EJBService、JMSService）时，并不知道该服务位置，可通过业务代理（BusinessDelegate）进行查找，然后可以定位该服务,并对该服务进行请求访问。

集中式控制模式

• 在集中式控制模式的软件架构中，中央控制构件按照特定对象状态机逻辑对系统全局行为进行控制操作。
• 中央控制构件接收输入构件或用户界面构件的输入操作。
• 中央控制构件根据输入事件引发的系统状态变迁，对相关部件实施操作控制，从而实现系统功能控制。

案例：在微波炉控制系统中，设备的中央控制构件采用集中式控制模式对各个执行部件进行控制操作。

分布式控制模式

• 在分布式控制模式的软件架构中，系统控制分布在多个控制构件之中，不存在总控全局的单一构件。
• 每个控制构件按照特定对象状态机逻辑对系统特定部分的行为进行控制操作。
• 多个控制构件通过消息通信协作完成整个系统的控制处理。

案例：在一个植物工厂控制系统中，其控制系统对植物生长所需要的光照、温度、湿度等参数进行控制，其控制方式采用分布式控制体系架构模式对各个执行部件进行控制操作。

多层控制模式

• 在多层控制模式的软件架构中，系统控制分布在多个控制构件之中，此外，通过协调者构件控制所有控制构件实现整个系统的控制。
• 协调者构件提供全局控制，而每个控制构件按照特定对象状态机逻辑对系统特定部分的行为进行控制操作。
• 协调者控件发布命令到各个控制构件执行控制操作，同时协调者控件也从控制构件接收状态消息。

案例：在一个植物工厂控制系统中，其控制系统对植物生长所需要的光照、温度、湿度等参数进行控制，其控制方式也可采用多层控制体系架构模式对各个执行部件进行控制操作。

抽象分层模式

• 在抽象分层模式的软件架构中，复杂的软件构件关系被抽象到不同的功能层次。
• 每个层次构件只能访问它的相邻下层服务同时也只对相邻的上层提供服务。
• 相邻上下层次构件之间通过请求调用访问、返回响应消息方式进行交互实现系统功能处理。

案例：在一个Unix系统中，软件系统采用分层架构组成，分别由内核、系统调用、shell/实用程序/公共函数库、应用程序层次组成。

多客户/单服务模式

• 在多客户/单服务模式的软件架构中，软件构件被部署到多个客户端结点和一个服务端结点。
• 各客户端结点的软件构件通过网络连接访问服务端结点上运行的服务。
• 在本模式下，多个客户端构件可并发向一个服务端构件提出服务请求，服务端构件一次将处理结果返回给请求的客户端构件。

案例：在银行ATM系统中，每个银行网点都有多台ATM客户端结点通过网络连接银行业务系统，其软件系统采用多客户/单服务模式体系架构。

多客户/多服务模式

• 在多客户/多服务模式的软件架构中，软件构件被部署到多个客户端结点和多个服务端结点上运行。
• 客户端构件通过网络连接访问多个服务器结点上运行的服务。
• 在本模式下，多个客户端构件可并发向多个服务端构件提出服务请求，服务端构件各自将处理结果返回给请求的客户端构件。

案例：在一个支持多家银行互联互通的ATM系统中，每个银行网点都有多台ATM客户端结点通过网络连接银行业务系统，它们的软件系统采用多客户/多服务模式体系架构。

多层客户/服务模式

• 在多层客户/服务模式的软件架构中，除了基本的客户端层次和服务端层次外，还有一个同时扮演客户端角色和服务端角色的中间层。
• 中间层对于它的服务层而言是一个客户端，但对其他客户端而言又是一个服务端。
• 客户端、中间层、服务端的结点通过网络进行通信，支持多个客户端构件向服务端构件提出服务请求，服务端构件将处理结果返回给请求的客户端构件。

案例：在一个具有三层客户/服务模式架构的银行ATM系统中，“银行服务”层向“客户端”层提供服务，同时它又是“数据库服务”层的一个客户端。

软件架构通信模式

软件架构通信模式关注构件之间通信的方式。典型的软件架构通信模式如下:

• 调用/返回模式
• 异步消息通信模式、同步消息通信模式
• 服务注册、转发、发现模式
• 广播/组播模式

调用/返回模式

• 在软件构件之间的通信交互中，一种常见的交互模式就是调用/返回模式。
• 一个客户构件对象的操作方法去调用服务构件对象的操作方法。
• 当服务构件对象的操作方法执行后，将处理结果返回客户构件对象。

案例:银行服务子系统的软件架构由储蓄账户构件(SavingsAccount）、支票账户构件(CheckingAccount）、转账功能构件(TransferTransactionManager）和取款功能构件(WithdrawalTransactionManager）所组成。构件对象之间的通信方式如下图所示。

异步消息通信模式

• 在软件构件的对象交互通信中，生产者构件进程可以独立于消费者构件运行。
• 一个构件中对象发送一个消息给另一个构件的对象，其发送者不需要等待对方回复，可以继续执行其他操作。

案例:在一个汽车自动泊车控制系统的软件架构中，其中“运行监控（operationSupervisory)”构件、“到位传感器（( arrivalSensor)钩什“车辆控制（vehicleControl )”构件之间进行交互通信。

同步消息通信模式

• 一个构件中对象发送一个消息给另一个构件的对象，需要等待对方回复，才可继续执行其他操作。
• 若发送消息的构件对象没有收到接收构件对象的回复消息，其进程将会挂起。

案例:在银行服务系统的软件架构中，其中“ATM机客户（ATM Client）构件”、 “GUI用户客户(GUl UserClient）构件”与“银行服务（BankingService)”构件之间进行消息通信。

服务注册、转发、发现通信模式

• 服务注册、转发、发现通信模式应用于面向服务的软件架构中，各个服务构件能够分布在多个节点上运行。
• 这些服务构件在代理构件的协助下能够被客户构件所访问。
• 代理构件扮演客户构件和服务构件的中介，它使客户构件不需要知道某个服务在哪里提供，而是通过代理构件便能获得服务构件的位置信息。

案例:在基于Web服务实现的软件架构中，Web服务代理者使用统一描述、发现、集成框架(Universal Description， Discovery and Integration,
UDDI)为客户端提供一种在Web上动态发现服务的机制。

广播/组播通信模式

广播/组播消息通信模式适合于分布式应用，将一个构件消息同时发送到多个构件处理。

案例:一个视频监控跟踪系统有三个卡口视频监控跟踪构件（videoTrace1\videoTrace2\ videoTrace3）、视频监控事件服务（alarmHandingService）构件、视频监测构件(eventMonitor）组成。它们之间的通信交互关系如下图所示。

软件架构事务模式

软件架构事务模式关注构件之间的事务处理，以确保业务数据完整性。典型的软件架构事务模式如下:

• 两阶段提交协议模式
• 复合事务模式
• 长事务模式

两阶段提交协议模式

两阶段提交协议模式用于分布式系统中原子事务处理，即确保事务所封装的服务请求操作是不可分割的，它们要么都完成，要么都取消。

在两阶段提交协议模式中，通过一个提交协调构件(commitCoordinator)与多个服务构件进行通信协调，实现事务处理。

案例:在从银行A的一个账户转账到银行B的一个账户中，可以采用两阶段提交协议模式实现转账事务处理，以确保银行数据的一致性。

复合事务模式

在复杂业务处理中，当一个事务可以被分解为若干更小的、独立的处理单元时，这种事务就是复合事务。

例：一个旅游团的出行预订业务，由机票预订、酒店预订和租车预订组成。这些构件服务之间的事务通信关系如下图模型所示。

长事务模式

在业务处理中，若需要用户参与决策操作，则会出现较长时间的数据资源锁定处理，这样的事务称为长事务。

例一个航班预订功能由“航班1预订”、“航班2预订”、“航班3预订”等功能构件协作完成,它们之间的事务通信关系如下图模型所示。

软件架构UML建模设计

软件架构的静态结构模型

软件架构的静态结构模型（如UML类图、UML包图等）用于描述软件系统的静态逻辑结构。在面向对象系统设计中，采用UML设计类图模型将软件系统的类程序组成静态结构可视化呈现出来。

• 类图(Class Diagram)描述一个软件的类程序静态逻辑组成结构。
• 表示软件中类与类之间的关系，以及各个类的属性与操作组成。

案例:在一个销售订单子系统的软件设计中，其系统架构的静态结构模型如图所示。

在一个复杂系统的软件设计中，仅采用一个类图来反映系统的软件静态结构是不现实的。需要将复杂系统划分设计为相互联系的若干子系统。针对各个子系统，分别给出它们的类图设计，但在高层设计中采用UML包图对系统的软件静态结构进行抽象设计。

• 包图( Package Diagram )是采用类似文件夹的包符号表示模型元素的组织结构模型图。
• 包被描述成文件夹，可以应用在任何一种UML图上。
• 系统中的每个元素都只能为一个包所有，一个包可嵌套在另一个包中。

软件架构的动态交互行为模型

软件架构的动态交互行为模型用于反映软件系统的对象之间交互行为。在UML软件建模设计中，可以采用交互图（通信图或顺序图）描述软件对象之间的协作通信，从而反映对象之间通过动态消息交互行为实现系统功能。

• 通信图(CommunicationDiagram）是表现对象间直接交互关系的模型图。
• 它展现了多个对象在协同工作达成共同目标的过程中互相通信的情况。
• 通过对象和对象之间的链接、发送的消息来显示对象之间的交互关系。

案例:在一个图书商品销售系统的软件设计中，采用如下通信图反映该系统的各个子系统之间的动态交互行为模型。

软件架构的物理结构模型

软件架构的物理结构模型用于反映软件系统架构的实现方案。在面向对象系统设计中，软件架构采用UML构件图和UML部署图表示系统物理结构实现方案。

• 构件图(Component Diagram )是描述系统的构件结构及其关系的模型图。
• 描述软件的物理结构，从而支持基于构件的软件实现。

• 部署图( DeploymentDiagram）是表示系统构件在环境节点中的部署方案。
• 从部署图还可以获知软件和硬件组件之间的物理拓扑、连接关系以及处理节点的分布情况。

案例:在一个商品销售系统的物理结构模型设计中，采用如下构件图反映该系统架构的物理结构模型。

案例:在一个商品销售系统的物理结构模型设计中，采用如下部署图反映该系统架构的物理结构模型。

银行ATM系统软件架构设计实践

案例:ATM（自助取款机）系统是银行为客户提供方便自助业务的信息系统。它由ATM前端硬件设备及其软件系统组成，并通过网络连接到银行服务系统，为客户提供取款、转账、查询等银行业务服务。

在ATM系统软件架构设计中，依据银行领域需求，采用客户机/服务器架构模式设计软件架构。以下将给出系统分解设计、系统静态结构设计、系统对象交互结构设计、系统构件结构设计、系统部署结构设计。

ATM机系统分解设计

ATM机系统静态结构类图模型设计

ATM机系统动态交互图模型设计

ATM系统构件图模型设计

ATM系统部署图模型设计

课堂作业与作业练习

1．高质量的信息系统主要由下面哪项工作决定?（A)

A．系统设计

B．软件编程

C．软件测试

D．软件运维

2．下面哪种设计方法只应用在面向对象系统设计中?(D)

A．抽象设计

B．逐步求精

C．模块化设计

D．信息隐蔽

3．下面哪种UML模型图只用于系统总体设计建模?（D)

A．系统类图

B．顺序图

C．通信图

D.．系统部署图

4．用户最关心下面哪种架构?（A)

A．应用架构

B．软件架构

C．数据架构

D．拓扑架构

5．下面哪种软件架构风格最适合复杂软件系统?（A)

A．分层体系架构

B．客户机/服务器体系架构

C．微核体系架构

D．数据共享体系架构

二、判断题

1．类图模型在系统设计各阶段都需要涉及。（√)

2．系统数据架构是一类数据库模型。（×)

3．系统架构的核心视图就是软件架构。（√)

4．客户机/服务器体系架构适合Web应用。(√)

5．异步消息通信模式适合银行转账业务。(×)

系统架构通常包括系统拓扑架构、系统数据架构、系统软件架构和(系统应用架构)等。

典型软件系统一般被划分为表示层、业务逻辑层、(数据存取访问层)和数据存储层。

客户/服务模式可以细分为(多客户/单服务模式)、多客户/多服务模式、多层客户/服务模式。

在面向服务的软件架构中，其通信模式主要有服务注册通信模式、(服务代理转发通信模式)、服务句柄代理转发通信模式、服务发现通信模式。

软件对象之间的消息通信模式主要有同步消息通信模式和(异步消息通信模式)。