本文最后更新于 2023-10-13,文章内容可能已经过时。

系统分析与设计

image-20230824221926798

1.系统:

1.1 系统与信息系统:

系统:一个能够产生特定结果的相关构件的集合.

信息系统:以信息作为输入/输出对象,以计算机软、硬件为核心的系统.

1.2系统开发角色:

QQ截图20230329151714

1.3系统开发方法:

结构化开发:

QQ截图20230329151751

面向对象开发:

QQ截图20230329151838

UML面向对象开发:

QQ截图20230329151910

2.UML:

2.1 定义:

UML — Unified Modeling Language.

UML 是一种对软件系统的制作过程/产出物进行下述工作的描述语言: 可视化(visualizing)、详述 (specifying)、构造 (constructing)、 文档化(documentin).

2.2构成:

主要有四部分构成:视图(views).图(Diagrams).模型元素.通用机制.

2.2.1 视图:

QQ截图20230329152406

2.2.2 图:

QQ截图20230329152536

2.2.3 关系:

QQ截图20230329152559

3.需求:

3.1需求的必要性:

QQ截图20230329152740

3.2 需求的获取步骤:

QQ截图20230329152929

3.3 需求分类:

3.3.1 业务需求:

描述项目的总体目标.

QQ截图20230329153135

3.3.2 用户需求:

重点描述项目需求中涉及到用户操作的部分,一般分为功能需求与非功能需求.

QQ截图20230329153329

3.3.2.1 功能需求:

功能需求是指系统需要提供的功能以及服务.

3.3.2.2 非功能需求:

非功能需求(Non-Functional Requirements, NFR):从各个角度对系统的约束和限制,反映了客户对软件系统质量和性能(quality and performance)的额外要求,包括安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性等.

注意:非功能需求隐含了对可选设计方案的一些关键影响

3.3.3 业务规则:

业务的具体实现细节.可执行性或内部执行逻辑的一些限定条件.

3.3.4 数据定义:

较为复杂的数据格式的定义.

3.3.5 约束条件:

范围比较广泛,主要描述系统开发在过程中的限制条件.

QQ截图20230329153941

3.3.6 外部接口需求:

QQ截图20230329154022

3.4 好的需求:

QQ截图20230329154105

4.需求建模:

获取需求之后,建立模型,对需求进行描述.

4.1 事件:

事件:发生在某一特定的时间和地点、可描述并且系统应该记录下来的事情.

信息系统的所有处理过程都是由事件驱动/触发的.事件发生时需要系统做出响应,能列出所有这样的事件就可以搞清楚用户对系统的需求.

4.1.1 事件类型:

外部事件: 系统外的事件.一般的行为都可以被认为是外部事件.

临时事件:某一时刻发生的事件.比如定时任务等.

状态事件:系统发生状态是所引发的事件.

QQ截图20230329155153

4.1.2 事件定义:

1.与系统无关的不算做事件.

2.特别细节的事件在系统分析阶段不予考虑.

QQ截图20230329155451

多个不同的事件组成了事件列表.

4.2 事物:

在传统的开发方法中,事物就是构成系统存储 信息的相关数据 在面向对象的开发方法中,事物就是在系统中相互交互的对象.

4.2.1 关系:

QQ截图20230330154018

4.2.2 属性:

属性:有关事物的一条特定信息.

4.2.3 ERD:

实体关系图.

示例:

QQ截图20230330154536

关系说明:

QQ截图20230330154436

简单记为:双方都有一条竖线,有圈是可选,斜线数量代表各种关系.

4.2.4 类图:

面向对象设计所构建出来出的模型,用类图表示.

一个类由三部分组成:名字,属性,方法.

不同类之间的关系如下:

泛化:

QQ截图20230330154838

组合:物理上一体的组成部分:

QQ截图20230330154853

聚合:物理上本没有关系,人为的联系在一起.

QQ截图20230330154846

4.3.敏捷开发:

4.3.1 用户故事:

QQ截图20230330155247

QQ截图20230330155324

QQ截图20230330155430

QQ截图20230330155445

5.用例分析:

1.用例模型图.

2.每个用例的详细描述.

3.术语表:所用到的术语说明.

4.补充规约:非功能性需求的说明.

QQ截图20230330161302

5.1 用例:

用例(Use Case):表示系统所提供的服务或可执行的某种行为.

– 定义了系统是如何被参与者所使用的,描述了参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段“对话”.

– 用例的概念在1986年由Ivar Jacobson正式提出之后被广泛接受,迅速发展,已成为OO、UML、RUP的标准规范和方法.

5.2 特征:

1.不可分解

2.系统参与

3.可观测

4.有价值

5.特定角色触发

5.3 用例图:

QQ截图20230330160049

5.4 用例建模的基本流程:

1.识别并描述参与者(actor);

2.识别用例(use case),并给出简要描述;

3.识别参与者与用例之间的通讯关联(Association);

4.给出每一个用例的详细描述.

5.细化用例模型.

5.4.1 特殊参与者:

QQ截图20230330160340

5.4.2 详细描述:

包括事件流(常规与备选),前置,后置条件,目标等。

QQ截图20230330160656

5.4.3 细化用例模型:

包含:

QQ截图20230330160802

拓展:

QQ截图20230330160811

注意箭头指向的方向是拓展的主体方向。

泛化:

QQ截图20230330160753

QQ截图20230330160849

5.5 活动图与泳道图:

作为补充.

活动图:

QQ截图20230330161349

泳道图:

QQ截图20230330161357

6.结构化系统分析:

自顶向下.

将待解决的问题看作一个系统,从而用系统科学的思想方法(抽象、分解、模块化)来分析和解决问题.

6.1 DFD图:

数据流图,用处理、外部实体、数据流以及数据存储来表示系统需求的图表.

image-20230824223305552

image-20230824223353918

给出一个DFD图的例子:

image-20230824223505033

主要就是三部分,正方形框是外部实体,即访问系统的实体,正方形框带个横线是处理,可以理解为一个方法,正方形框带个竖线是数据存储,可以理解为数据库表.

关于DFD图,有几点需要注意:

1.每一个处理必须有输入和输出,否则会出现奇迹和黑洞,输入由数据提供,然后输出到外部实体.

2.数据存储之间不能直接交换数据,必须经过处理.

3.外部实体获取数据,必须经过处理.

6.2 DD图:

数据字典,对DFD细节的内容描述.数据处理:给出处理的流程和说明信息

主要包括:

1.数据处理名

2.数据处理说明

3.输入数据: {数据结构}

4.输出数据: {数据结构}

5.处理过程简要描述

image-20230824223956858

6.3 ERD图与IDEF1X图:

描述实体关系的图,二者的唯一区别就是描述类似一对多这种关系时的符号不一样.

image-20230824224354023

image-20230824224407275

7.面向对象分析:

自底向上.

7.1 静态模型

7.1.1 BCE图:

边界类:

image-20230824235147139

控制类:

**image-20230824235208205**

实体类:

image-20230824235225710

三者为多对多关系.

image-20230824235253472

7.1.2 分析类图:

就是完整的bce类,加上箭头,用于表示关系.

image-20230824235432356

7.1.3 领域类图:

类似于erd图,用于表示实体之间的关系.

image-20230824235607914

注意领域类图和分析类图的区别,领域类图只是大体上的描述,具体的方法不用写,但是分析类图是最终的成品,类中的方法一定要写.

7.2 动态模型:

7.2.1 时序图:

将用户与分析类结合在一起,实现将用例的行为分配到所识别的分析类中.

将交互关系表示为一个二维图:

纵轴是时间轴,时间沿竖线向下延伸;横轴代表了在协作中各独立的对象.

image-20230824235807886

给出时序图的例子:

image-20230824235859924

7.2.2 协作图:

image-20230824235922836

8.数据库设计:

8.1 数据库设计的基本原则:

image-20230825002039550

明确概念.逻辑,物理ERD设计.