软件系统分析与设计

建模本质

对问题进行梳理（抽像、归类、关系）并形成结构化的模型，可以对需求、数据、业务、架构进行建模。建模从需求阶段就开始了。

1.概念建模:站在用户角度进行抽像、归类、关系梳理后的模型

2.逻辑建模:将概念阶段的模型转换为具体某个产品所支持模型，比如具体数据库

系统分析与设计

为什么要分析，为什么要设计。
1.分析是为了确定要做什么、条件约束是什么
2.设计是为了解决怎么去做

建模前问题分析定义

为什么要在建模前进行问题的定义？
一个系统的本质是为用户解决问题，在建模前需要做到问题的分析与定义并归结模型，最终得到更真实的模型，并为这些问题给出解决方案。

问题分析

1. 在问题定义上达成共识
开发团队与用户需求的理解达成共识，使系统开发向着合理的方向进行

书写格式：
问题概述：用简短的几句话，将所理解的问题本质描述出来；
影响：说明该问题将会对哪些项目干系人（Stakeholder，风险承担者）产生影响；
结果：确定问题对项目干系人和商业活动会产生什么样的影响；
优点：概要性地提出解决方案，并列举出该解决方案的主要优点

2. 理解问题的本质
每一句描述夹带着叙述者的个人理解，透过表面深进理解问题背后的问题，常用方法采用鱼骨图，将问题写在方框中，原因写在鱼骨上。

3. 确定项目干系人和用户
因为不同的项目干系人有着不同的需求，解决不同的需求就要找到项目的干系人，考虑：系统用户是谁、谁是系统用户的客户、谁来维护系统、其他的干系人

4. 定义系统的边界
数据从用户输入到系统，由系统输出到用户，用户与系统接口进行交互。定义系统的边界就要找到系统与系统的事件(参于系统的交互者)，通过数据流图方式或用户图方式（找到参于者就找到了边界）。

5. 确定系统实现的约束
约束就是限制，根据限制提供解决方案

问题定义

对问题分析完了，接下来就是对问题的定义，包括功能性、非功能性、目标
目标：构建系统的原因

书写格式：
目标：
优势：目标应该不仅仅是解决问题，还要提供业务上的优势；
度量：不仅要说明业务的优势，而且还必须提供度量这种优势的标准；
合理性：要确保完成解决方案所需的工作量少于所获得的业务优势，这才是合理的解决方案；
可行性：要探寻能够满足度量标准的解决方案；
可达成性：对于组织而言，是否具备获取该系统的技能，构建完成后是否能够操作它。

包括功能性
功能是否正确，需求有没有二义性

非功能性

（1）观感需求：即产品外观的精神实质，也就是与用户界面的观感相关的一组属性；
 （2）易用性需求：也就是产品的易用性程度，以及特殊的可用性考虑，通常包括用户
的接受率、因为引入该产品而提高的生产效率、错误率、特殊人群的可用性等指标；
 （3）性能需求：也就是关于功能实现要求有多快、多可靠、多少处理量及多精确的约
束。例如：速度、精度、安全性、容量、值范围、吞吐量、资源使用效率、可靠性（平均无
故障时间）、可用性（不停机时间）、可扩展性等；
 （4）可操作性需求：衡量产品的操作环境，以及对该操作环境必须考虑的问题；
 （5）可维护性和可移植性需求：期望的改变，以及完成改变允许的时间；
 （6）安全性需求：产品的安全保密性，通常体现为保密性、完整性和可获得性；
 （7）文化和政策需求：由产品的开发者和使用者所带来的特别需求；
（8）法律需求：哪些法律和标准适用于本产品

需求分析与设计

本节描述需求分析与设计的理轮，具有代表性的分析与设计参考 结构化分析与设计、面向对象分析与设及、领域分析与设计。

需求的本质是确认软件的功能、性能、数据、界面。分下面4个阶段

• 识别问题
  发现需求、描述需求，包括功能性需求、性能需求、安全性需求、可靠性需求、环境需求等以确定系统达成的目标
• 分析问题
  对问题进行分析，常用方式有SA
• 编写需求说明书
  对已确认的需求进行文档化描述，也就是编写需求规格说明书
• 需求评审
  对需求功能的正确性、完整性、清晰性进行评价

需求分类

• 软件需求
  • 功能性 ：系统必须完成的功能
  • 非功能性：性能、可靠性、安全性、响应时间、吞吐量、容错、扩展、可维护、可修改等
  • 设计约束性：也就是限制，比如限制只能用国产数据库
• 用户需求：站在用户角度的需求
• 系统需求：站在系统角度上描述的需求，如功能、非功能、约束、质量属性
• 业务需求：业务本身的的需求

如何进行系统设计

设计者拿到需求后怎么去进行系统设计呢？
1.在各系统目标之间找平衡点既在预算内又能满足用户
2.多参考其他目标系统进行舍取形成新的系统设计

参靠：
（1）组件的独立性。审视自己设计的系统，是否做到了高内聚、低耦合？
（2）例外的识别和处理。谁能保证系统使用者都精确按照使用说明书使用？
（3）防错和容错。当网络中断、数据库崩溃这样的灾难性事件发生时，系统也跟着崩

系统设计文档

概要设计：高层设计，将软件需求转化为数据结构和软件的系统结构
详细设计：低层设计，将对结构表示进行细化，得到详细的数据结构与算
法。

面向结构化分析与设计

结构化分析

自顶向下逐层分解
结构化分析步骤

1. 数据流图：画出系统的数据流图，说明输入、输出数据的情况，数据经过哪些加工处理
2. 建立系统逻辑模型 ：将数据流图转换成系统等价的逻辑模型
3. 划清人机关系：哪些是机器完成，哪些是人工完成

数据流图DFD

基本元素
过程：也称为加工，一步步地执行指令，完成输入到输出的转换。
外部实体：也称为源/宿，系统之外的数据源或目的。
数据存储：也称为文件，存放数据的地方，一般是以文件、数据库等形式出现。
数据流：从一处到另一处的数据流向，如从输入或输出到一个过程的数据流。
实时连接：当过程执行时，外部实体与过程之间的来回通信。

对于一个系统标为0编号，然后对系统进行分解，这个分解叫0层分析

结构化设计

结构化设计包括架构设计、接口设计、数据设计、过程设计，它是一种面向数据流设计，自顶向下、精益求精、模块化的过程。
概要设计：高层设计对软件系统的结构、哪些模块组成、模块关系描述，可用结构图、层次图描述
详细设计：低层设计，对系统、模块结构详细描述，单入口单出门控制，常用流程图、盒图
结构图：由模块、调用、数据组成，结构图是在数据流程图基础之上进行设计，将数据分为加工类型、事务类型。
程序流程图和盒图：都是用来描述程序的细节逻辑的

模块设计原则

高内聚、低耦合，信息隐蔽

面向对象化分析与设计

概念

对象：是类的实列（对应现实中的事物），由名称、属性、行为组成
类：对象的抽像及描述
实体：只有属性没有行为，负责存储数据
控制类：控制其他类的行为功能
边界类：描述外部与系统之间交互的类

分析与设计

分析与设计
顶层架构图、用例及用例图、领域模型构成。
设计模型：以包图描述软件体系结构、以交互图表示用例实现图、类图、 复杂对象的状态图和以流程化处理过程的活动图。
设计原则：可重用、低耦合、高内聚

UML基础

1.用例图

从用户角色描述系统的功能。并指出功以的执行者。本质上是功能分解、支持领域建模、面向对象用例驱动。关系有：关联、扩展、泛化、包含

2.静态图

类图：描述系统静态结构，包括，继承、聚合、关联、依赖等关系
对象图：是类的实现，反应某一个时间内对象的活动
包图：描述系统的分解结构，继承、构成、依赖

3.行为图

• 交互图：顺序图（对象间消息发送时间序列）、合作图（对象间的状态协作）
• 状态:描述对象的状态行为
• 活动：描述系统某一项的执行操作序列，可以并发、同步，包含控制流和信息流动作状态、活动状态
• 泳道：根据活动的职责划分所有的活动，每个泳道带表一个责任区，所关心的是职责 分支：branch
  分叉汇合:fork join 对象流

4.实现图：构建图、部署图
5.构建图:构建之间的依赖
6.部署图：系统结构的部署

UML设计说明
依赖（Dependency）
【依赖关系】：是一种使用的关系, 即一个类的实现需要另一个类的协助, 所以要尽量不使用双向的互相依赖.
【代码表现】：局部变量、方法的参数或者对静态方法的调用
【箭头及指向】：带箭头的虚线，指向被使用者

关联（Association）
【关联关系】：是一种拥有的关系, 它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子
关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量
【箭头及指向】：带普通箭头的实心线，指向被拥有者

聚合（Aggregation）
聚合关系】：是整体与部分的关系, 且部分可以离开整体而单独存在. 如车和轮胎是整体和部分的关系, 轮胎离开车仍然可以存在.如微服务A 微服务B 聚合合微服务AB。但A、B都是可独立使用的
聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
【代码体现】：成员变量
【箭头及指向】：带空心菱形的实心线，菱形指向整体

组合（Composition）
【组合关系】：是整体与部分的关系, 但部分不能离开整体而单独存在. 如公司和部门是整体和部分的关系, 没有公司就不存在部门.
组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期
【代码体现】：成员变量
【箭头及指向】：带实心菱形的实线，菱形指向整体

泛化（Generalization）
具体描述建立在一般描述的基础之上，并对其进行了扩展。在java中用来表示继承的关系

具体描述建立在一般描述的基础之上，并对其进行了扩展。在java中用来表示继承的关系
实现（Realization）
实现是一种类与接口的关系，表示类是接口所有特征和行为的实现，在程序中一般通过类实现接口来描述。对Java应用程序进行建模时，实现关系可直接用implements关键字来表示。

面向领域分析与设计

分析阶段
在分析阶段的领域模型中，我觉得主要描述领域实体及关系，可以辅助领域名词解释（可以是业务字典形式）、以及约束（业务规则），而业务实体（域实体）仅描述主特征即可。用例分析法

设计阶段
聚合根
领域服务
领域事件
边界上下文