软件体系结构

软件工程

研究软件生产的一门学科，采用工程的概念，原理，方法，技术来开发和维护软件，把经过时间考验而证明正确的管理技术和当前能够的到的最好的技术方法结合起来。

软件工程的基本要素

• 过程：支持软件开发的各个环节的控制和管理。
• 方法：完成软件开发任务的技术手段。
• 工具：为软件开发提供自动的或半自动的软件支持环境。
• 质量:

软件开发的过程

问题定义 —>需求开发—》软件设计----》软件构建—》软件测试

软件工程的基本方法

• 面向服务：在应用的层面上将软件构件化，即应业务过程由服务组成，而服务由构件组装而成。
• 面向构建：寻求比类的粒度更大的且易于复用的构件，期望实现软件的再工程。
• 面向对象：以类为基本程序单元，对象是类的实例化，对象之间消息传递为基本手段，
• 面向过程：以算法作为基本构建单元，强调自顶而下的功能分解，将功能和数据进行分离。

软件过程

软件过程就是将用户需求变为软件产品的过程。

软件过程的模型主要类型

• 瀑布模型：把开发过程看成一系列界限分明的独立阶段，是一种计划驱动的过程。

• 原型化模型：原型是一部分开发的产品，用于加强对系统的理解，有助于明确和挑选设计策略。

• 迭代式开发：将描绘，开发和验证等不同获得交织在一起，建立一系列的版本，逐步交付。

  （迭代式有两种方式，一是增量模型，另一种是迭代模型）。

• 可转化模型：利用自动化的手段，通过一系列转换将需求规格说明转换为可以交付的系统。

瀑布模型的特定

1. 以预测为原则
2. 以文档为驱动
3. 以过程控制为核心。

为什么要使用迭代化开发：

1. 快速开发产品。
2. 追求产品创新。
3. 需求不确定性高。
4. 需要快速响应用户的变化。
5. 关注用户的行为。

软件结构影响因素

• 架构受系统利益相关者影响。
• 架构受开发组织影响。
• 架构受架构师背景和经验影响。
• 架构受技术环境影响。

架构设计流程

1. 创建系统的业务用例。
2. 理解用户需求。
3. 创建或选择合适架构。
4. 为架构建立文档。
5. 分析评价架构。
6. 实现基于架构的系统。
7. 确保系统实现符合架构。

良好架构的特征

1. 弹性。

2. 简单。

3. 可实现。

4. 功能职责的清晰分解。

5. 平衡职责分布。

6. 平衡经济和技术约束。

软件体系结构构成（核心模型）

软件体系结构包括构成系统的设计元素的描述，设计元素之间的交互，设计元素的组合模式以及这些模式中的约束。

• 构件：一组基本的构成要素。

• 连接件：这些要素之间的连接关系。

• 约束：作用于这些要素或者连接关系上的限制条件。

• 质量：性能。

• 物理分布：这些要素连接之后的拓扑结构。

  软件体系结构=构件+连接件+约束

软件体系结构的目标：

• 可重用性：复用已证明的体系结构，或提供可重用资产。
• 可扩展性：易于增加新的功能。
• 可改变性：易于适应需求变更。
• 简单性：将复杂问题简单化，使系统更加易于理解和实现
• 有效性：体现早期设计决策，展现系统满足需求的能力。

风格，模式和框架

体系结构风格：用于描述某一特定应用领域中系统组织的惯用模式，反映了领域领域中众多系统所共有的结构和语义特性。

设计模式：描述了软件系统设计过程中常见问题的一些解决方案，通常是从大量的成功实践中总结出来的且被广泛的实践和认识。

软件框架：软件框架是由开发人员定制的应用的骨架，是整个或部分系统的可重用设计，由一组抽象构件和构件实例的交互方式组成。

框架和体系结构的关系

体系结构的呈现方式是一个设计规约，而框架则是“半成品”的软件。

体系结构的目的是指导软件系统的开发，而框架的目的是设计复用。

框架和设计模式的关系

框架给出的是整个应用系统的体系结构，而设计模式则给出了单一设计问题的解决方案，且可以在不同的应用程序或者框架中应用。

设计模式的目标是改善代码的结构，提高程序的结构质量，框架强调的是设计的重用性和系统的可扩展性，以缩短开发周期，提高开发质量。

构件的获取和管理

构件获取

• 从现有的构件中获得符合要求的构件，直接使用或作适应性修改，得到可重用的构件。
• 通过遗留工程，将具有潜在重用价值的构件提取出来，得到可以重用的构件。
• 从市场上购买现成的商业构件。
• 开发符合要求的新构件。

架构模型定义

架构模型实现四个目标

• 对系统进行优化。
• 规约系统的结构或行为。
• 用于知道构件系统的模板。
• 将设计决策形成文档。

架构模型的分类

• 结构模型： 最直观、最普遍的建模方法。这种方法以体系结构的构件、连接件和其他概念来 刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、 隐含的假设条件、风格、性质等。
• 框架模型： 框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
• 动态模型： 型是对结构或框架模型的补充，研究系统的“大颗粒”的行为性质。例如， 描述系统的重新配置或演化。动态可以指系统总体结构的配置、建立或拆除通信 通道或计算的过程。
• 过程模型： 型研究构造系统的步骤和过程。
• 功能模型： 型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。 可以看作是一种特殊的框架模型。

Kruchten4+1模型概述

• 逻辑视图（最终用户）： 逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。
• 开发视图（编程人员）： 开发视图也称模块视图，主要侧重于软件模块的组织和管理。
• 物理视图（系统工程人员）： 考虑如何把软件映射到硬件上，它通常要考虑到系统性能、规模、 可靠性等。解决系统拓扑结构、系统安装、通讯等问题。
• 进程视图（系统集成人员）： 侧重于系统的运行特性，主要关注一些非功能性的需求。
• 场景： 景可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种 意义上说场景是最重要的需求抽象。

Rational的4+1视图模型

• 设计视图（用户）：

  设计视图包含构建系统的类、接口和类之间的协作。主要支持系统的功能性需求，也即系统提供给用户的服务。

• 实现视图（程序员）：

  实现视图包含用于组装和发布物理系统的组件。 主要解决系统发布的配置管理问题

• 部署视图（系统工程师）：

  部署视图包含形成系统硬件拓扑结构的节点。主要解决构成物理系统的部件的分布、发布和安装问题。

• 交互视图（集成工程师）：

  交互视图描述了系统不同部分之间的控制流，包括可能的并发和同步机制 。 主要解决系统的性能、可拓展性、吞吐量等问题。

• 用例视图

统一建模语言

模型的意义

• 模型是对现实的简化，建模是为了更 好地理解系统。
• 模型说明系统结构和行为。
• 模型给出构造系统的模板（按照模型构造系统）。
• 选择创建什么模型对如何动手解决问题和如何形成解决方案有意义深远的 影响
• 每一种模型可以在不同的精度级别上表示。
• 比较好的模型可以让用户根据观察者 角色及其他原因选择系统表述的详细 程度。
• 对每个系统最好用一组几乎独立的模 型去处理（低耦合）。

UML目标

客户，产品经理，架构师，程序员，测试员，质量保证，项目经理，产品运维。

UML特点

• 统一的标准，已经被OMG接受为标准建模语言。
• 面向对象，支持面向对象开发。
• 可视化，表示能力强
• 独立于开发过程，可以适用于不同软件开发语言和 软件过程
• 概念明确，表示简洁，结构清晰，容易学习掌握。

UML构成简介

事物

• 结构事物

  结构事物（structural thing）：UML 模型的静态部分，描述概念或物理元 素。 • 结构事物也称为：构件事物。

  常见的结构事物包括：

  • 类（class）

  • 接口（interface）

  • 协作（collaboration）

  • 用例（use case）

  • 主动类（active class）

  • 构件（component）

  • 节点（node）

• 行为事物

  行为事物 （ Behavioral Thing ） ： UML模型图的动态部分，描述跨越空 间和时间的行为。

  • 常见的行为事物包括：

  • 交互（interaction）：实现某功能的一组构件事物之间的消息的集合，涉及消息，动作序列、链接。

  • 状态机（state machine）：描述事物或交互在生命周期内响应事件所经历的状态序列。

• 分组事物

  分组事物（Group Thing）：UML模 型图的组织部分，描述事物的组织结构。

  • 常见的分组事物包括：

  • 包（package）。

• 注释事物

  注释事物 （ Annotational thing ） ： UML模型的解释部分，用来对模型中 的元素进行说明和解释。

  • 常见注释事物包括：

  • 注解（note

关系

• 关联关系（Association）是一种结构 关系，它指明一个事物的对象与另一 个事物的对象间的联系。
• 泛化关系（Generalization）是一种特殊/一般的关系。也可以看作是常说的继承关系。
• 实现关系（Realization）是类元之间的语义关系，其中的一个类元指定了由另一个类元保证执行的契约。
• 依赖关系（Dependency）是两个事物之间的语义关系，其中一个事物（独立事物）发生变化，会影响到另 一个事物（依赖事物）的语义。

图

UML图形是模型元素集的图形表示， 通常是由顶点和边相互连接构成，其 中顶点表示模型元素，边表示关系。

• 常见的UML图形包括：

• 用例图（Use Case Diagram）

• 类图（Class Diagram）

• 对象图（Object Diagram）

• 交互图（Interaction Diagram）

​ • 顺序图、通信图和定时图

• 状态图（State Chart Diagram）

• 活动图（Activity Diagram）

• 构件图（Component Diagram）

• 部署图（Deployment Diagram）

用例图

组成要素

• 用例（Use Case）。
• 参与者（Actor）。
• 关系（Relationship）。

用例定义

系统、子系统或类与外部参与者交互的动作序列的说明，包括各种活动序列及出错 序列。

参与者

• 在系统外部使用软件系统的角色。
• 也称作活动者或角色。

关系

• 关联关系： 表示参与者启动用例。 关联关系表示法 ：直线或箭头直线。

• 包含关系表示法：带有箭头的虚直线，带有版型<<包含>>或<>。

  包含关系语义（1）：两个以上用例有 共同公共功能，可分解到单独用例， 形成包含关系。

• 扩展关系表示法：带有箭头的虚直线， 带有版型<<扩展>>或<>。

• 扩展关系语义：一个用例（在某些扩 展点上）扩展出一些功能，这些功能 构成新用例.

• 归纳关系也成为泛化关系。 归纳关系语义：表示用例直接或参与 者之间抽象与具体的关系。 归纳关系表示法：带有空心三角箭头 的实线直线。

类图

• 面向对象程序设计的基础是类，类是现实世界事务或功能的抽象和构造块。
• UML类图（Class Diagram）是用于描述面向对象程序设计中的“类”的模型。
• 类图描述软件系统结构化设计，包括类、接口以及它们之间的静态结构和关系。
• 类图是一种静态建模方法 。

类图的作用

• 在系统分析阶段，类图主要用于显示角色和提供系统行为的实体的职责。
• 在系统设计阶段，类图主要用于捕捉组成系统体系结构的类结构。
• 在系统编码阶段，根据类图中的类及它们之间的关系实现系统的功能。

类图的组成

1. 类名: 类的名字，代表该类抽象出来 事物的主要特点。
2. 属性: 抽象出来的类的特征。
3. 操作: 抽象出来的类的行为。

属性格式

操作的格式

类图的关系

关联关系

• 描述了类的结构之间 具有关系。 关键关系表示法：箭头直线 。

• 关联关系特点：

  • 关联关系语义较弱（除聚合和组合）。

    • 具有导航性、名字、角色和多重性等属性。 • 关联关系导航性（方向性）： 
  
    • 导航性表示从一个类可访问到另一个类。
  
    • 单箭头表示单向关联，无箭头表示双向关 联。  	
  

  ​ • 被关联的对象不知道谁与自己关联，但关 联对象知道自己与谁有关联。

聚合关系

• 特殊关联关系。 指明一个聚集（整体）和组成部分之间的 关系。

• 聚合关系表示法：空心菱形箭头直线。

• 理解：

  • 表示整体由部分构成的语义。

  • 整体和部分不是强依赖的，即使整体不存 在了，部分仍然存在。

  • 例如：一个学院由多个学生和教师组成， 学院撤销后，学生和教师不会消失，他们 依然存在。

组合关系

• 组合关系：

  • 特殊关联关系。

  • 指明一个聚集（整体）和组成部分之间的 关系。

  • 语义更强的聚合，部分和整体具有相同的 生命周期。

  • 组合关系表示法：实心菱形箭头直线。

• 理解：

  • 表示整体由部分构成的语义。

  • 整体和部分是强依赖的，即使整体不存在 了，部分也不存在了。

  • 例如：一所大学由多个学院和部门组成， 大学撤销后，学院和部门也会撤销，他们不存在了。

泛化关系

• 泛化关系：

  • 表示具体与一般的关联关系。

  • 在面向对象中一般称为继承关系，存在于 父类与子类、父接口与子接口之间。

• 泛化关系表示法：空心三角箭头直线。

• 理解：

  • 自顶向下的属性继承。可以使得子类共享 父类的属性和操作，实现继承。

  • 自底向上的实例替换。可以使得子类的实 例用于任何父类被声明使用的地方，实现 多态。（派一个人来开会。学生、老师都 可去开会。派一个老师来开会，若替换为 派一个人去开会则有歧义）。

实现关系

• 实现关系：

  • 表示类实现了契约和规定。

  • 对应于类和接口之间的关系。

• 泛化关系表示法：空心三角箭头虚线。

依赖关系

• 依赖关系：

  • 描述了一个类的变化对依赖于它的类产生 影响的情况。

  • 有多种表现形式，例如绑定（bind）、友 元（friend）等。

• 依赖关系表示法：箭头虚线

顺序图

软件体系风格

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。

经典的体系结构风格

• 数据流风格：批处理；管道、过滤器。
• 调用/返回风格，主程序/子程序；面向对象风格；层次结构。
• 独立构件风格：进程通讯；事件系统。
• 虚拟机风格：解释器；基于规则的系统。
• 仓库风格：数据库系统；超文本系统，黑板系统。

主程序-子程序

主程序-子程序风格是结构化设计的一种典型风格，从功能的观点设计系统，通过逐步分解和细化，形成整个系统的体系结构。

面向对象风格

系统被看作是对象的集合，每个对象都有自己的功能集合；数据集作用在数据上的操作被封装成抽象数据类型。只通过接口和外界交互，内部的设计决策则被封装起来。

面向对象风格的优点

因为对象对其他区对象隐藏它的存在，所以可以改变一个对象的表示，而不影响其它的对象。

设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。

面向对象风格的缺点

为了是一个对象和另一个对象通过过程调用进行交互，必须知道对象的标识，只要有一个对象的标识改变了，就必须改变所以其他明确调用的对象。

必须修改所有显式调用的其它对象，并由此带来的一些副作用。

管道过滤风格

把系统任务分成若干个连续的处理步骤，这些步骤通过系统的数据流连接起来，一个步骤都输出是下一个步骤的输入。

管道过滤风格的优点

• 使得构件具有良好的隐蔽性和高内聚，低耦合的特点。
• 整个系统输入输出行为是多个过滤器的行为的简单合成。
• 支持软件重用。
• 系统维护和增强系统性能简单。
• 允许对一些如吞吐量和死锁等属性的分析。
• 支持并行执行。

过滤器风格的缺点

• 通常导致进程成为批处理的结构。
• 不适合处理交互的应用。
• 因为没有通用的标准，每个过滤器都增加了解析和合成数据的工作，导致系统性能的下降。
• 管道太长，系统性能将受到很大的影响。

分层风格的优点

支持基于抽象程度递增的系统，使设计者可以把一个复制系统按递增的方式进行拆解。

支持功能增强

支持重用

分层风格的缺点

• 并不是每个系统都可以很容易地划分为分层的模式。 甚至即使一个系统的逻辑结 构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的 功能综合起来
• 很难找到一个合适的、正确的层次抽象方法

事件风格

事件系统是将应用看成一个构件集合，每个构件直至发生对它有影响的事件时才有所动作。

策略之一：选择广播模式

策略二：察者模式。

事件风格的优点

为软件重用提供了强大的支持。

为改进系统带来了方便。

事件风格的缺点

• 构件放弃了对系统计算的控制。

• 数据交换的问题，

• 甚至即使一个系统的逻辑结 构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的 功能综合起来 ，难找到一个合适的、正确的层次抽象方法 。

Web体系风格结构

两层C/S结构

胖客户：客户端执行大部分的数据处理操作。

瘦客户端：客户端具有很少或没有业务逻辑。

三层C/S结构

表示层：包括所有的与客户机交互的边界对象，如窗口，表单，网页等。

功能层，包括所有的控制和实体对象，实现应用程序的处理逻辑个规则。

数据层：实现对数据库的存储，查询和更新。

三层C/S结构的优点

• 允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和 软件的可维护性和可扩展性。
• 允许更灵活有效地选用相应的平台和硬件系统
• 应用的各层可以并行开发
• 利用功能层有效地隔离开表示层与数据层，

三层结构的缺点

• 三层C/S结构各层间的通信效率若不高
• 设计时必须慎重考虑三层间的通信方法、通信频度及数据量。

软件设计过程

软件总体设计

• 明确系统设计目标
• 确定子系统或模块
• 选择部署方案
• 定义设计策略
• 评审系统设计方案

系统设计目标

• 性能准则
  • 响应时间
  • 吞吐量
  • 存储量
• 可靠性准则
  • 健壮性
  • 可靠性
  • 可用性
  • 容错性
  • 安全性
  • 预防性
• 维护准则
  • 可扩展性
  • 可修改性
  • 适应性
  • 可移植性
  • 需求可追踪性
• 最终用户准则
  • 效用
  • 易用性
• 成本准则
  • 开发成本
  • 部署文本
  • 升级成本
  • 维护成本
  • 管理成本
• 说明
  • 设计目标定义了系统应该重点考虑的质量要求
  • 性能，可靠性和最终用户准则通常可以从肺功能需求或应用领域中推断出来，维护和成本准则需要开发人员识别。

确定子系统或模块

• 功能分解
• 独立配置数据
• 独立特有的硬件控件
• 独立出时间至上的构件、
• 将人机接口实现模型分离。

微服务和SOA的主要区别

SOA实现	微服务架构实现
企业级，自顶向下开展实施	团队级，自底向上开展实施
服务由多个子系统组成，粒度大	一个系统被拆分为多个服务，粒度细
企业服务总线，集中式的服务架构	无集中式总线，松散的服务架构
集成方式复杂	集成方式简单
单块架构系统，相互依赖，部署复杂	服务都能独立部署

相比传统SOA的服务实现方式，微服务更具有灵活性、可实施 性以及可扩展性，其强调的是一种独立测试、独立部署、独立 运行的软件架构模式 。

标签：关系,模型,系统,视图,软件体系结构,构件,事物
来源： https://blog.csdn.net/humorious/article/details/112548396