

首页  思维导图  详情



软件架构设计

2023-12-26 18:56:34   30  举报





AI智能生成

软件架构设计

架构设计

读书笔记

阅读笔记

读书

模版推荐

作者其他创作

大纲/内容

<b>基本概念篇</b>

软件架构概念

组成派

定义：将系统描述为计算机组件及组件之间的交互

特点

关注架构实践中的客体——软件，以软件本身为描述对象

分析了软件的组成，即软件由承担不同计算任务的组件组成，这些组件通过相互交互完成更高层次的计算

决策派

定义：在一些重要方面所做出的决策的集合

特点

关注架构实践中的主体——人，以人的决策为描述对象

归纳了架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能需求的决策

架构设计视图

问题1：架构视图为什么必不可少？

架构视图的本质是“分而治之”，能帮助架构师从不同角度设计，特别是面对复杂系统时“分而治之”的设计是必需的

问题2：架构视图是什么？

架构视图是一种设计架构、描述架构的核心手段

问题3：如何运用“逻辑视图+物理视图”设计系统架构？

逻辑架构

定义

软件的逻辑架构规定了软件系统由哪些逻辑元素组成以及这些逻辑元素之间的关系。具体而言，组成软件系统的逻辑元素可以是逻辑层（Layer）、功能子系统、模块。

设计

层、子系统、模块等的划分决定

交互接口与交互机制

物理架构

定义

软件的物理架构规定了组成软件系统的物理元素，这些物理元素之间的关系，以及它们部署到硬件上的策略。

设计

软件系统在计算机运行期间的并发和交互情况

<b>实践过程篇</b>

架构设计过程

3个原则

【原则1】看透需求

需求要全

矛盾关系

追溯关系

【原则2】架构大方向正确

一种策略，先设计概念架构（架构模式、集成技术选型）

【原则3】设计好架构的各方面

运用“多视图设计方法”

逻辑视图

开放视图

物理视图

运行视图

数据视图

6个步骤

需求分析

领域建模

确定关键需求

概念架构设计

细化架构设计

架构验证

需求分析

愿景=业务目标+范围+Feature+上下文图

定义

愿景分析，要解决项目、产品或解决方案的起源问题。所谓明确愿景，就是针对系统目标、主要特性、功能范围和成功要素等进行构思并达成一致。

工作成果

《愿景与范围文档》

上下文图

定义

上下文图是一种“辅助说明”需求范围（Scope）的方式，它清晰地描述了待开发系统与周围所有事物之间的界限与联系。

内容原则

关注本系统，以及和本系统有关联的因素，但不关注本系统内部——既不关注内部功能，也不关注内部结构。

形式原则

明确标识出要研发的是什么系统，保持它为黑盒，将它画在上下文图的中央位置，其他相关因素环绕周围。

软件需求=功能+质量+约束

定义

IEEE定义

1、用户所需的解决某个问题或达到某个目标所要具备的条件或能力 2、系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力 3、上述第一项或第二项中定义的条件和能力的文档表述

RUP定义

需求描述了系统必须满足的情况或提供的能力，它就可以是直接来自客户需要，也可以来自合同、标准、规范或其他有正规约束力的文档

二维需求观与ADMEMS矩阵

横向

组织级需求

用户级需求

开发级需求

纵向

功能需求

质量属性

约束

工作成果

《软件需求规格说明书》—— SRS （SoftwareRequirements Specification）

《SRS》精确地阐述了一个软件系统必须提供的功能、必须达到的质量属性指标，以及它必须遵守的约束。

用例与需求

用例图

描述软件系统为用户或外部系统提供的服务

用例简述（用户故事）

通过简短的文字对用例的功能进行描述；一般而言，用例简述都应包含成功场景的简单描述

用例规约

对用例的详细描述，一般包括简要说明、主事件流、备选事件流、前置条件、后置条件和优先级等

用例实现（鲁棒图）

多个对象为了完成某种目标而进行的交互

领域建模

定义

将领域概念以可视化的方式抽象成一个或一套模型

作用

为需求定义提供了领域知识和领域词汇

软件界面的设计往往和领域模型关系密切

领域模型经过精化之后会成为业务层的核心

领域模型是设计持久化数据模型的良好基础

确定关键需求

作用

关键需求（横跨功能需求、质量属性、约束）决定架构

其余需求可以用来验证架构

实践要领

确定关键质量

确定关键功能

概念架构设计

定义

概念架构直指目标的设计思想、重大选择

实践要领

功能需求和质量需求并重

1个决定

如何划分顶级子系统

4个选择

架构风格选型

开发技术选型

二次开发技术选型

集成技术选型

细化架构设计

5视图方法

每个视图，一组技术关注点

逻辑架构

职责单元 + 协作关系

开发架构

程序单元 + 编译依赖关系

运行架构

控制流 + 同步关系

物理架构

物理节点 + 拓扑连接关系

数据架构

数据单元 + 数据关系

实践（15个设计任务）

逻辑架构设计

模块划分

接口定义

领域模型

开发架构设计

技术选型

文件划分

编译关系

运行架构设计

技术选型

控制流划分

同步关系

物理架构设计

硬件分布

软件部署

方案优化

数据架构设计

技术选型

存储格式

数据分布

架构验证

方法

原型法（垂直演讲原型），适合项目型开发

将选定的功能特性完整地实现

要对一组架构设计决策“对系统要求的非功能需求的满足程度”进行验证

框架法，适合产品型开发

将架构设计方案用框架的形式实现，并在此基础上进行评估验证

验证架构对质量属性需求的支持程度

测试运行期质量

评审开发期质量

模块划分专题

功能模块划分

功能树

作为需求分析的手段，功能树（Function Tree）是一种框架性工具，有助于需求分析人员一层一层地选择确定系统必须具有的各项功能（Function）与特性（Feature）。

作为需求分析的成果，功能树是一种功能表达结构，它将“功能大类”、“功能组”和“功能项”的隶属与支持关系以“树”的形式呈现出来，非常直观。

由架构分析师设计

功能模块结构图

对系统进行结构分解的结果示意图

刻画解决方案

由架构师设计

分层架构

三层架构

展现层

显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。

业务层

处理各种功能请求，实现系统的业务功能，是一个系统最为核心的部分。

数据层

主要与数据存储打交道，例如实现对数据库的增、删、改、查等操作。

四层架构

用户界面层（UI层）

负责封装与用户的双向交互、屏蔽具体交互方式

系统交互层（SI层）

负责封装硬件的具体交互方式，以及封装外部系统的交互

问题领域层（ PD层）

负责问题领域或业务领域的抽象、领域功能的实现

数据管理层（DM层）

负责封装各种持久化数据的具体管理方式，例如数据库系统、二进制文件、文本文档、XML文档、Flash存储结构

用例驱动的模块划分

核心原理

从用例到类，再到模块

实现

实现用例需要哪些类

运用鲁棒图

运用序列图，明确类之间的交互关系

划分类到对应模块

封装驱动设计方法（Encapsulation-Driven Design方法，EDD方法）

研究需求

粗粒度分层

细粒度划分模块

用例驱动的模块划分结构评审、优化

 Collect

Get Started

软件架构设计理论

 Collect

Get Started

音乐机顶盒软件架构设计

 Collect

Get Started

数字化设计平台系统架构设计图

 Collect

Get Started

系统架构设计图





0 条评论

下一页