系统架构师- 软件架构知识点

软件架构

  • 架构模式是软件设计中的高层决策
  • 设计模式主要关注软件系统的设计,与具体实现语言无关
  • 惯用法则是实现时通过某种特定的程序设计语言来描述构件与构件之间的关系

架构文档化的主要输出结果是架构说明书和架构质量说明书

介绍

软件架构设计包括提出

  • 架构模型
  • 产生架构设计
  • 进行设计评审

软件系统架构是善于软件系统的结构、行为和属性的高级抽象。

  • 架构设计关注点
    • 结构
    • 属性
    • 交互作用

架构风格

介绍

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

架构风格定义了一类架构所共有的特征,主要包括架构定义、架构词汇表和架构约束。

定义

一个体系结构定义了一个词汇表和一组约束

架构风格反映领域中众多系统所共有的结构和语义特征

架构设计是一个迭代过程,在建立软件架构的初期,选择一个合适的架构风格是首要的,在此基础上,开发人员通过架构模型,可以获得关于软件架构属性的理解,为将来的架构实现与演化过程建立了目标。

  • GUI:事件驱动

解释器

  • 强调用户自定义

管道过滤器

    • 支持分阶段数据处理

隐式调用

  • 调试器,本质是在断点处设计一个事件监听函数

闭环结构

  • 适用于处理简单的任务

  • 机器装配

  • 不适用于复杂任务

分层结构

  • 引入抽象层

  • 低层不确定的实现细节在高层会变得确定

  • 系统结构更加清晰

数据共享

  • 现代编译器

面向构件

介绍

软件构件是部署、版本控制和替换的基本单位。

  • 构件通常需要同时部署的院子构件
  • 原子构件通常成组地部署,但他也能够被单独部署
原子构件 与 构件的区别

原子构件永远不会被单独的部署,尽管其可以单独部署

大多数原子构件都属于一个家庭,一次部署往往整个家庭

一个模块是不带单独资源的原子构件


  • 逻辑构件模型用功能描述系统的抽象设计
    • 作为系统的设计蓝图以保证系统提供适当的功能
  • 物理构件模型
    • 技术设施产品、硬件分布和拓扑结构
    • 了解系统的性能、吞吐率等许多非功能性属性

构件特性

  1. 独立部署单元
  2. 作为第三方的组装单元
  3. 没有(外部的)可见状态

对象的特性

  1. 一个实例单元,具有唯一的标志
  2. 可能具有状态,此状态外部可见
  3. 封闭了自己的状态

构件组装

问题
  • 构件失配
    • 由于系统对构件基础设施、控制模型和数据模型的假设存在冲突引起的失配
  • 连接子失配
    • 包括于系统对构件交互协议、构件连接子失配包括由于系统对构件交互协议、构件连接时数据格式的假设存在冲突引起的扮酷

CORBA

对象适配器
作用

在底层的传输平台与接收调用并返回结果的对象实现之间进行协调

目前采用的对象适配器规范是POAching(可移植对象适配器)

替代了传统的BOA(基本对象适配器)

Servant 伺服对象

最终完成客户请求的服务对象实现

伺服对象管理器

伺服对象激活器和伺服对象定位器

用来提供CORBA服务端的对象查找服务

活动对象映射表用来保存已注册的CORBA对象标识和伺服对象之间的映射关系。

实体(Entity)
  • 长期持久并主要用于事务性行为
  • 由窗口管理其持久化
加工(Process)
  • 同样需要窗口管理其持久化,但没有客户端可以访问的主键
会话(Session)
  • 构件不需要窗口管理其持久化
  • 自己管理自身状态信息
服务(Service)
  • 构件是无状态的
COP 面向构件编程

需要的基本支持

  • 多太性(可替代性)
  • 模块封装性(高层次信息隐藏)
  • 后期的绑定和装载(部署独立性)
  • 安全性(类型和模块安全性)

分布式系统

5层

  • 表示层
    • 实现用户界面
  • 表示逻辑层
    • 为了生成数据
  • 应用逻辑层
    • 数据计算和分析
  • 数据处理层
    • 存储和访问数据库的应用逻辑和命令
  • 数据层
    • 数据库中实际存储的业务数据

4+1 视图

  • 4+1视图中,逻辑视图用来描述软件模块的组织与管理
  • 开发视图:描述了软件模块的组织与管理
  • 过程视图描述设计的并发和同步特征。

ADL

  • 组成部分
    • 组件、组件接口、连接件、架构配置

C2

介绍

通过连接件绑定在一按照一组规则动作的并行构件风格。

C2风格中的系统组织规则如下

架构复审

架构设计、文档化和复审是一个迭代的过程

  • 通常会对一个可运行的最小化系统进行架构评估和测试

  • 目标:

    • 标识潜在的风险,及早发现架构设计的缺陷和错误

介绍

目的

为了标识潜在的风险,及早发现架构设计中的缺陷和错误

在架构复审过程中,主要由用户代表与领域专家决定架构是否满足需求、质量需求是否在设计中得到体现

架构文档

  • 软件架构文档是对软件架构的一种描述,帮助程序员使用特定的程序设计语言实现软件架构

原则

  1. 文档从使用者的角度进行编写
  2. 必须分发给所有与系统有关的开发人员
  3. 保持文档更新,但不要太频繁
  4. 避免不必要的重复
  5. 每次架构文档的修改都应该记录进行修改的原则

软件架构设计

  • 是降低成本、改进质量、按时和按需交付产品的关键因素。

  • 满足系统的性能、可维护性

  • 使不同利益相关的人达到一致的目标

  • 支持项目计划和项目管理等活动

  • 能够有效地管理复杂性

软件体系结构

文档化过程

输出结果:体系结构规格说明测试体系结构需求的质量设计说明书

文档的完整性和质量是软件体系结构成功的关键因素

文档从使用者的角度进行编写

必须颁发给所有与系统有关的开发人员

且必须保证开发者手上的文档是最新的

软件架构需求

  • (软件架构需求不应该包括设计构件的过程)

基于架构的软件设计 - ABSD

  1. 功能分解
  2. 采用架构风格实现质量属性与商业需求
  3. 采用模板设计软件结构
  • ABSD方法是一个自顶向下,递归细化的过程,软件系统的架构通过该方法得到细化,直到能产生软件架构的类
  • 强调由商业、质量和功能需求的组合驱动软件架构设计。
  • 强调采用视角和视图来描述软件架构
  • 采用用例和质量场景来描述需求

设计策略

  • Ping/ Echo 主要提高系统的可用性

  • 限制访问

    • 提高系统的安全性
  • 运行时注册

    • 提高系统的可修改性
  • 主动冗余

    • 系统的可靠性
  • 队列调度

    • 提高系统的性能
  • 信息隐藏

    • 提高系统的可修改性
  • 记录回放

    • 可测试性

设计模式

  • 访问者模式

    • 在不改变原来的类结构(活动节点)的基础上增加新功能

三种模式

创建型

通过采用抽象类所定义的接口,封装了系统中对象如何创建、组合

  • abstract factory
  • builder
  • factory method
  • prototype
  • singletoin

结构型模式

主要用于如何组合已有的类和对象以获得更大的结构

  • adaptor
  • bridge
  • composite
  • decorator
  • facade
  • flyweight
  • proxy
行为型模型

主要用于对象之间的职责及其提供服务的分配方式

  • chain of responsibility
  • command
  • interpreter
  • iterator
  • mediator
  • memento
  • observer
  • state
  • strategy
  • template matehod
  • visitor

外观模式

  • 要求外部与一个子系统的通信必须通过一个统一的外观对象进行
  • 为子系统中的一组接口提供一个一致的界面

软件系统架构评估

ATAM

  • 软件体系结构的设计结果进行评估
  • ATAM并不是一种精确的评估方法,该方法表现的主要形式是评审会议

在系统开发之前,性能、可能性、安全性和可修改性等质量属性进行评价折中

ATAM分 为四个主要的活动阶段

  • 需求收集
  • 架构视图
  • 描述
  • 属性模型

强调以视图做为架构评估的核心概念

  • 效用树
    • 对质量属性的描述进行刻画与排序

在识别出质量属性描述后,通常采用效用树对质量属性的描述进行刻画与排序

架构评价的理解和应用

敏感点:是实现一个特定质量属性的关键特征

权衡点:会影响一个或多个属性,并对多个属性来说都是第三点

领域分析

  • 领域分析的主要目的是获得领域模型
  • 领域模型描述领域中系统之间共同的需求,即领域需求
  • 领域设计的主要目标是获取DSSA(需求的解决方案)
  • 领域实现的主要目标是依据领域模型和DSSA开发和组织可重用信息,并对基础软件架构进行实现

DSSA

介绍

DSSA是一个具有三个层次的系统模型,包括领域开发环境、领域特定应用开发环境和应用执行环境

  • 应用工程师主要在领域特定应用开发环境中工作

作用

以一个特定问题领域为对象,形成由领域参考模型、参考需求、参考架构等组成的开发基础架构,其目标是支持一个特定领域中多个应用的生成。

基本活动

领域分析、领域设计、领域实现

架构需求

UML

UML对系统架构的定义是系统的组织结构

  1. 逻辑视图:(设计视图),它表示了设计模型中在架构方面具有重要意义的部分,即类、子系统、包和用例实现的子集
  2. 进程视图:是可执行线程和进程作为活动类的建模,它是逻辑视图的一次执行实例,描述了并发与同步结构
  3. 实现视图:对组成基于系统的物理代码的文件和构件进行建模
  4. 部署视图:把构件部署到一组物理节点上,表示软件到硬件的映射和分布结构
  5. 用例视图:是最基本的需求分析模型

用例视图:是最基本的需求分析模型

架构分析

SAAM

是最早广泛应用的架构分析方法

SAAM输入是问题描述、需求说明和架构描述

分析过程:场景开发、架构描述、单个场景评估、场景交互和总体评估

软件策略

  • 心跳:增加计算机资源、减少计算机开销、引入并发机制、采用资源高度等。
  • 可用性:心跳、Ping/Echo、主动冗余、被动冗余 、选举等架构策略实现该属性
  • 安全性:入侵检测、用户认证、用户授权、追踪审计

野生知识

机器人

使用规划系统架构风格

IDL

介绍

是一种接口定义语言

主要元素

接口描述、模块定义、类型定义、常量定义、异常、值类型

核心

接口描述是ILD文件中最核心的内容

ILD只是一种接口定义语言,最终还是要落地与语言对接,所以IDL的数据类型要与实现语言进行映射

逆向工程

分析已有的程序,寻求比源代码更高级的抽象表现形式

系统移植

阶段

1. 计划阶段

在计划阶段,要进行现有系统的调查整理,从移植技术、系统内容(是否进行系统提炼等)、系统运行三个方面,探讨如何转换成新系统,决定移植方法,确立移植工作体制及移植日程

2. 准备阶段

在准备阶段要进行移植方面的研究,准备转换所需的资料。该阶段的作业质量将对以后的生产效率产生很大的影响

3. 转换阶段

这一阶段是将程序设计和数据转换成新机器能根据需要工作的阶段。提高转换工作的精度,减轻下一阶段的测试负担是提高移植工作效率的基本内容

4. 测试阶段

这一阶段是进行程序单元、工作单元测试的阶段。在本阶段要核实程序能否在新系统中准确地工作。所以,当有不能准确工作的程序时,就要回到转换阶段重新工作

5. 验证阶段

这是测试完的程序使新系统工作,最后核实系统,准备正式运行的阶段

原文地址:https://www.cnblogs.com/pipihao/p/15459271.html