XJTUSE-系统设计与分析

YiYo832

已于 2023-11-29 20:25:09 修改

阅读量926

点赞数 10

分类专栏： XJTUSE-大三上文章标签：软件工程

于 2023-11-20 17:52:29 首次发布

本文链接：https://blog.csdn.net/weixin_64112516/article/details/134510578

版权

XJTUSE-大三上专栏收录该内容

18 篇文章 5 订阅

订阅专栏

本文转载了部分blog内容，若有侵权，请联系

前言

2023-11-20开始编写，2023-11-22晚上考试，整理重点考试的内容和自己拓展的知识。（可能存在部分错误）

主要参考：

大作业+知识点梳理：

系统分析与设计_Hydrion-Qlz的博客-CSDN博客

系统分析与设计_雨落俊泉的博客-CSDN博客

往年真题：

【XJTU软件系统分析与设计】期末考试_xjtu软件系统与设计_几希的博客-CSDN博客

知识梳理

第一部分

数据流图

数据流图可以分为顶层图，第一层数据流图，第二层数据流图。或上下文图+0级图+n级图

绘图时需要了解以下符号和原则：

符号：

原则：

父图-子图平衡原则：即父图输入输出数据流等于子图输入输出数据流
数据守恒原则：
守恒加工原则每个加工至少有一个输入数据流和一个输出数据流

下面给出我作业的DFD图：

现在看来，还是有不少瑕疵的。下面指出：

图示还是不规范，比如数据库的图形有问题。
没有给数据流编号，优点混乱。
箭头不应该用动词，应该传递的是数据。
复杂度较低。

实体和实体的职责

做作业的时候也有写到，应该是根据题目描述，确定系统的需求和角色，进而确定每一个角色的行为，即可以写出实体和实体的职责。

RBAC

期末题目：画出RBAC0模型，解释它的要点（不多于80字），画出ER图。

下面进行RBAC的展开：

RBAC0

解释要点：RBAC0是由用户，角色，会话，权限四部分构成的。其中用户-角色和角色-权限均为多对多关系。会话是由单个用户控制的，会话只能由用户创建。在一个会话中的角色的激活是由用户来决断的，因此会话-角色为一对多关系。（字数有点超出，考试的时候自行省略即可）

RBAC1

RBAC1解释要点：RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念，有了继承那么角色就有了上下级或者等级关系，即子角色可以继承父角色的所有权限，但是子角色必须是在父角色的基础上减少权限点。

个人理解：引入继承的概念，相当于一个树状的角色图。由于每个角色都有一个父类，为了使权限合理分配，子类的权限只能比父类少，这不会有冗余。不然，子类权限比父类权限多，可能存在冗余。

RBAC2

要点解释：RBAC2是建立的RBAC0的基础之上的，在RBAC0基础上假如了约束的概念，主要引入了静态职责分离SSD和动态职责分离DSD。

非重点内容，看一下即可：

SSD是用户和角色的指派阶段加入的，主要是对用户和角色有如下约束:

互斥角色：同一用户不能分配到一组互斥角色集合中的多个角色，互斥角色是指权限互相制约的两个角色。
基数约束：一个角色被分配的用户数量受限，它指的是有多少用户能拥有这个角色。
先决条件约束：指要想获得较高的权限，要首先拥有低一级的权限。
运行时互斥：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色

RBAC3

要点解释：RBAC3 把 RBAC1 和 RBAC2 组合在一起，提供角色的分级和继承的能力。

第二部分

数据库设计的原则

我翻了PPT和学长学姐的笔记，好像没有找到，下面是网上找的答案。

原则：

一致性原则，保证数据的一致性和有效性；
完整性原则，是数据的正确性和相容性；
安全性原则；
可伸缩性与可扩展性原则；
规范化原则。

我觉得还是比较全的和正确的，可以再加上业务逻辑和数据分离原则之类的。

范式概念

题目：第一范式，第二范式，第三范式的概念

我直接在PPT找到了答案：

第一范式：数据库表中的所有字段都是单一属性，不可再分的。换句话说，第一范式要求数据困中的表都是二维表。

第二范式：数据库的表中不存在非关键字段对任一候选关键字段的部分函数依赖。即，所有非主属性完全函数依赖于主属性；

第三范式：实体的非主属性的值不依赖于任何其它非主键属性。即，所有非主属性对任何候选关键字都不存在传递依赖。

找到了一篇blog详细讲解了（虽然我之前学过数据库，但确实忘得差不多了）：

数据库设计的三范式超详细详解_数据库三大范式_秃了也弱了。的博客-CSDN博客

ER图

题目：画数据库的ER图，每一个范式是五分，要依次优化或者一步到位，但是解释他是否满足第几范式。

根据PPT上的内容，应该是这个步骤：

但是，我觉得考试时间那么紧张，应该是只能一次到位到第三范式，然后进行解释。

我在思考怎么说明数据库满足第三范式，我觉得可以按照以下步骤来说明：

首先，说明设计的数据库表格都是二维表格，所有字段都是单一属性。
要说明每个表都满足非主属性完全依赖于主属性，我觉得说明可能产生争议的点就可以了吧，毕竟那么多表，一一说明不太现实。
然后说明，每个表都不存在传递依赖，应该也是只说有争议的点就好了。
可以再说明一下自己的数据库哪里有亮点或者不同之处。

总的来说，这个数据库设计的范式说明可以通过把每一个数据库表的列出来，逐个说明满足第三范式即可，难度不大，不过耗时，说明考试的时候，别把表画太复杂，增加后续工作了。

这里涉及到了数据库的ER图，下面开始讲解：

不妨先学习PPT上的一个案例：

题目：

设计：

我是觉得课堂案例有一些地方挺奇怪的。比如，他一直强调要把表名放在外面，还有对于一对多等等关系的连线他也就只认他的一套。royal总是喜欢把自己认为对的就当成放之四海而皆准的真理。不过设计出来的数据库能看懂，只是部分要求不同，为了成绩也就过去了。

下面进行数据库设计的知识讲解：

属性的特征

数据类型：是属性的一个参数，定义了这个属性中可以存储什么类型的数据
域：是属性的一个参数，定义了这个属性可以取的合法数据值
默认值：如果用户没有指定值的话，将被记录的值
键：是一个属性（或一组属性），他们对每个实体实例具有唯一的值，也称为标识符
候选键：是一组可以作为一个实体主键的键，也称为候选标识符
主键：是最终用来唯一表示或者确定一个实体实例的候选键
替代键：是没有被选中作为主键的其他候选键

关系的特征

关系：是存在于一个或多个实体之间的业务联系
聚数：定义了一个实体相对于另一个关联实体的某个具体指的最大或最小具体值的数量
度数：是参与某一个关系的实体数量
二维关系：两个实体之间的关系
单一实体之间的关系，即递归关系
页存在多个实体之间，即多维关系

外键：是一个实体的主键，但被复制到另一个实体以确定一个关系实例

外键总是与另一个实体的主键匹配
获得外键的实体为子实体
提供外键的实体为父实体

非确定性关系：是每个参与关系的实体都有各自的独立主键关系

不共享主键属性
实体被称为独立实体（强实体）

确定性关系：是父实体提供其转称为子实体的主键的一部分的关系

不共享主键属性
子实体被称为关联实体（弱实体）
非特定关系：是一个实体的多个实例同另一个实体的多个实例相关联的关系，即多对多的关系

实体的泛化

泛化（Generalization）：是指将几类实体公共的属性组合成独立的实体
超类（SuperType）：是一个实体，其实例存储了一个或多个实体子类的公共属性
子类（SubType）：是一个实体，其实例从一个实体超类中继承了一些公共属性

我觉得重点了解主键，外键，子类，候选键就好了。

数据库还有一些设计，比如NOT NULL，UNIQUE，TRIGGER等，我觉得这考试用不到，感兴趣可以自己复习数据库部分。

在考试的时候，设计数据库，可以考虑RBAC，这个设计也有模板，考试的时候也方便迅速画图。下面给出泉佬的设计和鄙人的垃圾设计。

泉的：

主要的模板可以归结下面部分：

鄙人的：

模板主要可以归结为下面部分：

我觉得自己的设计应该是满足RBAC1的，因为role表有继承。不过RBAC3可能也满足。

SQL

题目：查询2022年“系统分析与设计”成绩在90以上的学员，写出SQL语句（3分）

关于SQL语句，不少地方都有资料，下面分享我找到的一个资料：

史上最全SQL学习指南！（教程+实例+练习题） - 知乎 (zhihu.com)

我觉得这课重点应该不在SQL语句上面，想要考察的应该是知道不知道自己的设计出来的表怎么进行SQL语句的增删改查执行，简要学习即可：

　　选择：select * from table1 where 范围

　　插入：insert into table1(field1,field2) values(value1,value2)

　　删除：delete from table1 where 范围

　　更新：update table1 set field1=value1 where 范围

　　查找：select * from table1 where field1 like ’%value1%’ ---like的语法很精妙，查资料!

　　排序：select * from table1 order by field1,field2 [desc]

　　总数：select count * as totalcount from table1

　　求和：select sum(field1) as sumvalue from table1

　　平均：select avg(field1) as avgvalue from table1

　　最大：select max(field1) as maxvalue from table1

　　最小：select min(field1) as minvalue from table1

用例图

题目：画出用例图，然后选择其中的一个用例来描述，写基本事件流等。

我觉得这题目可能不全，不然的话可以提前背好一个通用用例描述和基本事件流，比如登陆注册啥的，这是个系统都要的用例描述和基本事件流。不过不管怎么说，因为不知道具体的系统，我不妨就以登陆注册用例进行讲解。

首先系统的用例图，这一部分需要具体的系统，比较难说，可以看例子。

学生学籍管理系统为例子。

泉佬画的：

鄙人画的：

如果知道每个角色的行为（能做什么），然后根据行为细化，再将行为之间的关系进行细化。用例图基本就出来了，没什么太大的难度。但是，需要知道具体的关系概念，下面给出：

可以参考：UML—用例图的扩展关系和包含关系的区别_用例图扩展和包含的区别-CSDN博客

        扩展关系（Extend）：当某个新用例在原来的用例基础上增加了新的步骤序列，则原来用例被称为基用例，这种关系称为扩展关系，可以这样理解这里的基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能，只有当扩展点被激活时，子用例才会被执行。由子用例指向基用例，比如说充值金额查询用例中有导出Excel子用例，离开子用例不影响充值金额查询的功能，这就是扩展关系。

包含关系（include）：几个用例可以提取他们共用的用例作为子用例，使其成为自己行为的一部分，因为子用例被提出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。由基用例指向子用例，比如几个用例都要用到登录子用例，登录作为子用例没有它的参与，其他用例也无法执行，这就是包含关系。

比较：容易混淆的原因在于不理解扩展和包含的含义，所谓扩展是从基用例的基础上扩展出新的功能（子用例），子用例不影响基用例，基用例本身是完整的，没有子用例的参与也可以完成自己的功能，而包含关系是提取出来的用例是基用例的一部分基用例和子用例必须一起使用才完整。二者的关键在于离开子用例，基用例是否可以完成一个完整的功能。

   如图：



    泛化：当多个用例共同拥有一种类似的结构和行为时，可以将他们的共性抽象成为父用例，其他的用例作为泛化关系的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，它继承了父用例的所有结构、行为、关系。其中三角箭头指向父用例。假如在机房收费系统的注册可以通过本地注册和网上注册。

总的来说，如果理解不了，只用包含关系《include》就行。

然后，就是要选择一个用例，进行描述，写基本事件流。

按照上面的格式写就好了。再给出一个例子。

至此，用例图部分编写完毕！

序列图

题目：画刚刚选的那个用例的序列图

不知道序列图到底指什么，最相关的应该就是时序图了。

参考blog：UML时序图(Sequence Diagram)学习笔记_sequencediagram-CSDN博客

下面做简要讲解：

画时序图时会涉及7种元素：角色(Actor)、对象(Object)、生命线(LifeLine)、控制焦点(Activation)、消息(Message)、自关联消息、组合片段。下面先讲解前六种。

角色(Actor)

系统角色，可以是人或者其他系统，子系统。以一个小人图标表示。

对象(Object)
对象位于时序图的顶部,以一个矩形表示。对象的命名方式一般有三种：
1 对象名和类名。例如：华为手机:手机、loginServiceObject:LoginService。
2 只显示类名，不显示对象，即为一个匿名类。例如：:手机、:LoginSservice。
3 只显示对象名，不显示类名。例如：华为手机:、loginServiceObject:。
生命线(LifeLine)
时序图中每个对象和底部中心都有一条垂直的虚线，这就是对象的生命线(对象的时间线)。以一条垂直的虚线表。
控制焦点(Activation)
控制焦点代表时序图中在对象时间线上某段时期执行的操作。以一个很窄的矩形表示。
消息(Message)
表现代表对象之间发送的信息。消息分为三种类型。

同步消息(Synchronous Message)：消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息的接收者放弃或者返回控制。用来表示同步的意义。以一条实线+实心箭头表示。
异步消息(Asynchronous Message)：消息发送者通过消息把信号传递给消息的接收者，然后继续自己的活动，不等待接受者返回消息或者控制。异步消息的接收者和发送者是并发工作的。以一条实线+大于号表示。
返回消息(Return Message)：返回消息表示从过程调用返回。以小于号+虚线表示。

自关联消息
表示方法的自身调用或者一个对象内的一个方法调用另外一个方法。以一个半闭合的长方形+下方实心箭头表示。

除了基本的六大元素，还有一些组合片段。感兴趣的可以自己搜索，只给出抉择和循环。

抉择

循环

同时还需要注意事项：

控制焦点两端要以消息元素封顶，控制焦点不要超过消息元素。

正确示范

错误示范

下面给出blog的登录时序图

给出鄙人绘制的时序图：

现在看来，自己画的时序图还是有不少问题的：

控制焦点两端要以消息元素封顶，控制焦点不要超过消息元素。
循环存在逻辑错误。

至此，时序图部分讲解完毕！

类图

题目：画类图（5分）

类图的设计思路从数据库开始。注意：这里不要画太好了，因为后面的题目要求优化类图。

参考blog：

【精选】[UML] 类图介绍 —— 程序员（灵魂画手）必备画图技能之一_类图怎么画-CSDN博客

由于面向对象中学过类图的概念，下面只给出类图的部分知识：

类是对一组具有相同属性、操作、关系和语义的对象的描述。关系是类之间的、语义是蕴藏的，对于一个类而言，其关键的特性是属性（成员变量）和操作（成员方法）。类用一个矩形表示的，包含三个分栏，每个分栏分别写入类的名称、类的属性和类的操作。

抽象类，接口等知识不再赘述。

类与类之间的关系：

设计类图的时候，可以参考数据库的设计，比如一些实体的数据库表借鉴一下其属性值。比如一些数据库的关系通过理解后，改为聚合，组合，依赖等关系，再比如数据库的继承可以改为类图的继承。通过分析数据库设计，可以得到不少有效信息，然后，合理设置操作，让类与类之间进行交互。完成类图。

我寻思考试应该没时间细想类图的设计，可以背下来几个典型的类图设计。

下面给出典型的类图设计实例：

23种设计模式——UML类图+简要分析+例题_uml设计模式-CSDN博客

给出鄙人设计的类图：

现在来看还是由非常多错误的：

部分关系的箭头出现错误，比如应该使用实心黑色菱形应该改为空心菱形。
数据操作类没有进行关联。

不过，自己的设计还是有部分优点的，首先，自己的设计还是基本符合类图要求同时满足了业务功能。其次，该设计比较清晰，估计考场也能写出来。

至此，类图部分完毕！

类图设计原则

题目：写出类图的几个原则，写名称或者写要点都可以（5分）

这要是不复习，写不出来几个，笑死。

设计模式常用的七大原则有:

1) 单一职责原则：应该有且仅有一个原因引起类的变更

2) 接口隔离原则：类间的依赖关系应该建立在最小的接口上。

3) 依赖倒转(倒置)原则：高层模块不应该依赖低层模块，两者都应该依赖其抽象;

4) 里氏替换原则：所有引用基类的地方必须能透明地使用其子类的对象。

5) 开闭原则：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

6) 迪米特法则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少

7) 合成复用原则

类图优化

题目：画出优化的类图（5分）解释一下优化（3分）

这个回头再编写，先缓缓

2023-11-21 19:56开始编写类图优化

我实在不知道royals到底要怎么类图优化，乌鱼啦。不过按照他在群里说的，大概就是尝试解耦之类的。

职责链设计模式：

2023-11-25 晚8点，我把我考试画的类图放这里了，希望对学弟学妹有用。当然，字丑见谅。

2023-11-21开始编写拓展部分。

拓展部分

老师在群里还说了几个必须掌握的部分，我觉得有可能会考，进行整理。

活动图

找到了如下blog：

【UML建模】活动图（Activity Diagram）-CSDN博客

简单地梳理：

先给出一个完整的活动图，然后进行讲解：

可以看到有如下的元素：

开始节点：开始是实心圆

结束节点：结束是一个空心圆中包含了一个小一点的实心圆

动作：动作则是通过一个圆角方框来表示，动作具有原子性，不可再分！！

决策节点：就是空心菱形框，满足条件时执行指定动作或者加入一条指定的分支。

合并节点：也是空心菱形框，但非必要。即几个分支合并到一条分支。

fork、join节点：即黑色细长条长方形，与上面的决策、合并节点类似，都是将一个流程分叉成多个子流程链路，最终再合并到一起。不同的是，fork节点分叉出的子流程是并行执行的，也就是异步操作。join节点也很好理解，就是在某个位置等待所有异步执行的流程都执行完毕后，再合并成同一个流程运行。

泳道图：同一种类型的动作按照角色、流程阶段等维度进行分组。在上图中，就分成了用户和三种服务。

笨人自己作业画的状态图：

感觉还是存在不少问题：

结束节点感觉应该只有一个会好一点。
决策节点的描述不太好
可以加入fork节点之类的。

状态机图

参考blog：

参考博客

不妨先看实例图：

有以下元素：

初态/终态：和活动图类似。表示状态机的入口状态和出口状态

简单状态：状态一般由状态名称、子状态、入口动作和出口动作、内部执行活动、内部转换和可推迟事件组成。对于简单状态而言，不会有子状态。

转换：转换是两种状态间的一种关系。它指明当特定事件发生或特定条件满足时，处于某状态（源状态）的对象将执行某一动作或活动并进入另一状态（目标状态）。转换表示为从源状态指向目标状态的实线箭头，并附有转换的标签。转换的标签格式如下：

⌊转换名称:⌋opt 事件名称opt ⌊(参数列表)⌋opt ⌊[监护条件]⌋opt ⌊/效果列表⌋opt

画状态机图的注意事项：

1、避免把某个“程序动作”当作是一种“状态”来处理。那么如何区分“动作”和“状态”？“动作”是不稳定的，即使没有条件的触发，“动作”一旦执行完毕就结束了；而“状态”是相对稳定的，如果没有外部条件的触发，一个状态会一直持续下去。

2、状态划分时漏掉一些状态，导致跳转逻辑不完整。所以在设计状态机时，我们需要反复的查看设计的状态图或者状态表，最终达到一种牢不可破的设计方案。

感觉做题的时候，需要抽象出状态和动作，建立相应的联系即可。

部署图

感觉挺难的，因为涉及到了具体的实现/物理设备。

参考blog：

UML--部署图-CSDN博客

名称	解释	图例
节点	节点用一长方形表示，节点定义了运行时对象和构件实例驻留的位置
构件	指系统中可替换的物理部分，构建的名字标在矩形中，提供一组接口实现
接口	外部可访问到的服务