电子科大软件系统架构设计——系统架构设计_电子科技大学软件架构模型与设计

系统架构设计

系统设计概述

系统设计定义

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

系统设计过程

系统设计活动

1.系统架构设计

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

2.基础设施平台设计

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

3.系统构件设计

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

4.系统界面设计

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

5.系统数据库设计

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

6.程序流程设计

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

7.安全机制设计

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

系统设计基本方法

1.抽象化

• 抽象是在大型系统繁杂关系中，降低系统设计复杂性的基本策略。
• 抽象过程是指从特殊对象到一般对象建立反映事物本质要素的过程。上层概念是对下层概念的抽象。通过抽象可实现系统全局建模描述。
• 抽象使得设计者能在宏观层面描述过程和数据，不需被低层细节所困扰。

2.逐步求精

• 逐步求精是将把问题的求解过程分解成若干步骤或阶段进行，每步处理都比前步处理更加精化，更接近问题的解法。
• 逐步求精有助于设计者在微观层面设计低层技术细节。

3.模块化

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

4.信息隐藏

• 每个模块的实现细节对于其它模块来说应该是隐蔽的，模块之间实现松耦合，以便实现软件构件的可复用性。
• 模块中所封装的数据和操作方法只能通过接口访问，以便支持模块的可维护性。

5.模块独立

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

系统设计原则

1. 建立良好的系统体系架构，以满足系统的可靠性、安全性、可伸缩性、可维护性等非功能特性需求。
2. 系统设计应采取模型抽象、模块化方法，将复杂系统分解为较简单的子系统及其构件进行开发。
3. 系统设计的构件应满足高内聚、低耦合、可复用原则。
4. 对系统架构、应用架构、软件架构、数据架构、用户界面、构件程序逻辑等设计内容进行可视化建模表示。

系统设计方法分类

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

系统架构基础

系统架构定义

系统架构（又称系统体系架构）是指系统的组成结构，同时反映系统各部件之间的关联性、交互性和约束机制。

系统架构设计定义

系统架构设计是系统设计重要活动，它根据系统需求，从全局层面给出系统总体框架的设计蓝图。

系统架构作用

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

系统架构类型

系统总体架构

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

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

系统拓扑架构

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

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

系统拓扑架构类型

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

系统拓扑架构案例

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

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

系统数据架构

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

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

系统数据分层架构设计

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

系统数据治理架构设计

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

系统数据存储架构设计

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

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

系统应用架构

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

应用架构类型

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

应用架构层次设计

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

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

软件体系架构

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

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

软件架构设计定义

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

软件架构设计目标

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

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

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

软件技术架构

软件架构设计实践练习——妇幼保健信息系统软件技术架构设计

软件架构风格

软件架构风格定义

软件架构风格是指针对领域共性问题提供通用的软件架构解决方案，它反映了领域中众多系统所共有的软件架构模式。

软件架构风格作用：用于指导开发者参照软件架构风格设计本软件系统架构，合理地将构件、子系统有效地组织成一个完整的软件系统。

软件架构风格要素

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

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

软件架构风格应用意义

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

软件架构风格分类

分层体系架构

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

• 将软件系统分解设计为若干层次。每一层都有清晰的功能处理分工，各层不需要知道其他层的细节，层与层之间仅通过接口通信。

• 用户对软件系统的访问请求将依次通过各层功能逻辑构件对下层进行调用访问处理。通常不允许跨层调用访问。

应用案例: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）进行交互。

应用案例:淘宝开放平台

微服务架构优点:

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

微服务架构缺点:

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

软件架构模式

软件架构模式定义

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

软件架构模式意义

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用户客户(GUI 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)描述一个软件的类程序静态逻辑组成结构。
• 表示软件中类与类之间的关系，以及各个类的属性与操作组成。

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

ChatGPT4：

这个类图代表了一个销售订单子系统，它包括多个类和它们之间的关系。下面是每个类的详细解释以及它们如何相互作用：

1. Customer（顾客）:
   • 这个类代表一个顾客，包含基本信息如名字（name），送货地址（deliveryAddress），联系方式（contact），以及顾客的活跃状态（active）。
2. Order（订单）:
   • 与每个Customer相关联（一个顾客可以有多个订单），包含订单创建日期（createDate）。
3. OrderStatus（订单状态）:
   • 这是一个枚举类型，定义了订单可能的不同状态，包括创建（CREATE）、运送中（SHIPPING）、已送达（DELIVERED）、和已支付（PAID）。
4. Item（商品项）:
   • 代表订单中的单个商品，具有重量（weight）、描述（description），并且包含方法来获取基于数量的价格（getPriceForQuantity）和获取重量（getWeight）。
5. OrderDetail（订单详情）:
   • 代表订单中的一行商品明细，包括数量（qty），税务状态（taxStatus），以及两个方法：计算小计（calculateSubTotal）和计算重量（calculateWeight）。
   • OrderDetail与Item有关联关系，表示每个OrderDetail包含一个Item。
6. Payment（支付）:
   • 与Order有关联关系，表示一个订单可以有多种支付方式，包含支付金额（amount）。
7. Credit（信用卡支付）、Cash（现金支付）、Check（支票支付）、WireTransfer（电汇支付）:
   • 这些都是Payment的具体子类，分别代表了不同的支付方式。
   • Credit类包含卡号（number）、类型（type）、过期日期（expireDate）等属性。
   • Cash类包含现金支付金额（cashTendered）。
   • Check类包含支票持有者的名字（name）、银行ID（bankID），以及一个方法来授权支票（authorized）。
   • WireTransfer类包含银行ID（bankID）和银行名称（bankName）。

这个类图展示了一个典型的销售订单处理子系统的面向对象设计。顾客下订单，订单包含多个订单详情，每个订单详情关联一种商品项。支付是订单的一个组成部分，可以有多种形式，如信用卡支付、现金支付、支票支付或电汇支付。通过这个类图，可以看出系统如何追踪顾客的订单和支付信息，以及商品如何与订单详情关联。这种设计支持多种支付方式和商品的灵活性，并允许系统轻松地添加新的商品或支付类型。

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

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

ChatGPT4：

1. UI（用户界面）:
   • 这个包包含了系统的所有用户界面元素。它与Ordering包有直接的关系，这表明用户界面直接与订单处理模块交互，例如，提交订单、显示订单状态等。
2. Ordering（订单处理）:
   • 这个包是系统的核心部分，负责处理订单的创建、验证和管理。它与CustomerDB有直接的关系，表明它需要访问客户信息来处理订单。Ordering包也与Accounting和Shipping包有交互，但这个图中并没有显示它与StockDB有直接的关系。
3. CustomerDB（顾客数据库）:
   • 这个包负责管理顾客信息的存储和检索。Ordering包需要这些信息来处理订单，比如验证顾客信息、提供定制服务等。
4. StockDB（库存数据库）:
   • 这个包负责管理库存信息。尽管在这个包图中它与Ordering包没有直接的箭头连接，但它与Shipping包有依赖关系，这可能意味着Shipping包需要在发货前检查库存或者在发货后更新库存状态。
5. Accounting（会计）:
   • 这个包负责处理与会计和财务相关的功能，如发票的生成、支付的处理和财务记录的维护。它与Ordering包有双向的关系，表示会计流程与订单处理流程密切相关。Accounting包还与Bank包有依赖关系，表明它需要与银行服务交互来处理金融交易。
6. Shipping（发货）:
   • 这个包处理所有与订单发货相关的任务。它与StockDB有依赖关系，说明发货流程需要访问和更新库存数据。
7. Bank（银行）:
   • 这个包表明系统需要与银行的服务进行交互。Accounting包依赖于Bank来执行金融交易，如处理支付和转账。

在这个设计中，实线箭头表示包之间的直接关系，而虚线箭头表示包之间的依赖关系。例如，Ordering包直接与CustomerDB包相关联，意味着它需要直接访问顾客数据。同时，Accounting包依赖于Bank包，这表示在处理财务事务时，它需要银行的服务。

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

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

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

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

ChatGPT4：

这个通信图展示了一个图书商品销售系统中各个子系统之间的动态交互行为。它展示了从顾客选择商品到安排交付的整个流程，每个步骤由相应的方法调用表示。以下是每个步骤的详细解释：

1. itemSelect():
   • 这是交互的第一步，由顾客进行。在BookSale子系统中，顾客选择他们想要购买的商品。
2. queryItem():
   • 一旦顾客选择了商品，BookSale子系统会查询该商品的详细信息，可能是从库存子系统中检索。
3. submitOrder():
   • 顾客提交他们的订单。这个步骤由Customer子系统发起，信息传递到Order子系统，以便开始处理订单。
4. onlinePayment():
   • 为了完成订单，顾客需要进行在线支付。这个步骤由Payment子系统处理，顾客通过它完成支付过程。
5. finishedPayment():
   • 当支付完成后，Payment子系统通知Order子系统，订单支付已经完成。
6. paidOrder():
   • Order子系统在确认支付完成后，通知Inventory子系统，订单已支付。这可能会触发库存更新或保留所购买的图书。
7. arrangeDelivery():
   • 最后，Order子系统将通知Delivery子系统开始安排交付过程。这可能包括打包图书、准备发货单据和安排运输服务。

这个通信图代表了一个典型的在线销售流程，其中每个子系统都有专门的职责，并通过定义好的接口和方法与其他子系统通信。这样的设计有助于分离关注点，每个子系统可以专注于实现自己的功能，同时通过清晰定义的接口与系统的其他部分交互。这不仅使得系统的维护和升级变得更容易，也提高了系统的可扩展性和可靠性。

软件架构的物理结构模型

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

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

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

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

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

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

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

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

ATM机系统分解设计

ChatGPT4：

这张图展示了一个ATM机系统的组件分解设计，其中涉及的组件被划分为外部设备、用户、子系统，以及它们之间的交互。这个设计描绘了ATM软件系统如何与外部元素和银行服务系统接口。以下是对各个组件和交互的详细解释：

1. CardReader（卡阅读器）:
   • 这是一个外部输入/输出设备，负责读取顾客的银行卡信息。它提供输入（cardReaderInput）给ATM客户端，同时可能会给顾客提供一些卡相关的输出信息（cardReaderOutput）。
2. CashDispenser（现金分配器）:
   • 另一个外部输出设备，用于向顾客分发现金。它从ATM客户端接收指令（dispenserOutput）来分配特定金额的现金。
3. ReceiptPrinter（收据打印机）:
   • 用于打印交易收据的外部输出设备。它接收来自ATM客户端的打印指令（printerOutput）。
4. Customer（顾客）:
   • ATM的外部用户，与KeypadDisplay交互以输入指令（Customer Input）和查看信息（Display Information）。
5. Operator（操作员）:
   • 另一种外部用户，负责ATM机的维护和管理。操作员可以输入指令（Operator Input）和查看操作信息（Operator Information）。
6. ATMClient（ATM客户端）:
   • ATM软件系统的核心子系统，处理用户输入，并控制其他设备如CardReader、CashDispenser和ReceiptPrinter。它负责执行客户端的交易逻辑（ATMTransaction），并与BankingService子系统交互来完成交易。
7. BankingService（银行服务）:
   • 这是一个后端子系统，通常位于银行的服务器上，处理来自ATMClient的交易请求（ATMTransaction），并返回交易结果（bankResponse）。

整个交互流程开始于顾客使用卡阅读器输入银行卡信息，然后通过键盘显示屏输入交易指令。这些指令由ATM客户端处理，后者可能会指示现金分配器分发现金或收据打印机打印收据。同时，ATM客户端会与银行服务进行通信来授权交易并获取交易状态。操作员可以对ATM进行维护或管理操作，如加钱、修复设备等。

这个设计展示了ATM机如何作为一个集成系统运作，其中包含了用户交互界面、硬件设备的控制和后端银行服务的通信。这种分解有助于将ATM机的不同功能模块化，使得维护和升级更加容易。它还提供了一个清晰的框架来理解ATM机的操作流程和各组件之间的相互作用。

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

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

ATM系统构件图模型设计

ChatGPT4：

1. ATMClient:
   • 这个子系统是ATM客户端的主要部分，负责处理用户与ATM的交互。
2. CardReader:
   • 这是一个输入组件，用于读取插入ATM机的银行卡信息。
3. ATMKeypadDisplay:
   • 作为用户交互的界面，它接收用户的输入（如PIN码、取款金额等）并显示相关信息。
4. Operator:
   • 这个组件代表ATM机的操作员界面，可能用于维护和管理ATM机。
5. ATMControl:
   • 控制组件，负责协调ATM机的各个部分，包括处理卡片信息、用户交互和执行交易。
6. CashDispenser:
   • 这是一个输出组件，负责在用户完成取款交易后分发现金。
7. ReceiptPrinter:
   • 另一个输出组件，用于打印交易凭据，如取款或存款的确认收据。
8. BankingService:
   • 与ATM客户端子系统交互的银行服务子系统，它处理交易请求并返回交易结果。它通过IBankServiceTransaction接口与ATMControl组件进行通信。

在这个图中，箭头表示数据流或控制流。ATMControl是ATM客户端子系统的核心，它接收CardReader的输入数据，响应ATMKeypadDisplay和Operator的用户交互，并控制CashDispenser和ReceiptPrinter来执行操作。同时，ATMControl还需要与BankingService子系统通信，以验证交易并完成用户请求的操作。

ChatGPT4：

1. BankService:
   • 这是一个子系统，代表银行服务端，负责处理与银行相关的业务逻辑。
2. BankTransactionCoordinator:
   • 作为协调者组件，它负责协调处理不同的交易请求，并确保业务逻辑的正确执行。
3. QueryTransactionManager:
   • 这是一个业务逻辑组件，专门负责处理查询交易，如检查账户余额。
4. WithdrawalTransactionManager:
   • 另一个业务逻辑组件，用于处理取款交易，包括验证取款请求和更新账户余额。
5. TransferTransactionManager:
   • 负责转账交易的业务逻辑组件，处理从一个账户向另一个账户转移资金的请求。
6. PWDValidationManager:
   • 这个组件负责密码验证的业务逻辑，确保交易请求是由合法用户发起。
7. CheckingAccount/SavingsAccount:
   • 这些是数据库封装组件，它们分别代表支票账户和储蓄账户的数据，用于直接与数据库交互。
8. TransactionLog:
   • 数据库封装组件，用于记录所有交易的日志。
9. DebitCard/CardAccount:
   • 这些数据库封装组件代表借记卡和卡账户数据，用于处理与借记卡相关的操作。

在这个构件图中，箭头代表不同组件之间的通信。BankTransactionCoordinator是核心组件，与多个业务逻辑组件相连，这些组件又与相应的数据库封装组件相连，以完成具体的数据操作。这个设计使得银行服务端的结构清晰且易于管理，每个组件都有明确的职责，同时也便于扩展或修改特定的业务逻辑。通过IBankServiceTransaction接口，银行服务端子系统与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．异步消息通信模式适合银行转账业务。(×)

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

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

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

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

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