【XJTU】软件系统分析与设计

写学习指导的时候顺便把之前一些可能对同学有帮助的资料上传，方便查看，仅供参考。目前比较粗糙，计划在期末考试后（大概在2023.5.15）整理一番，并进行资料的更新、往年考试内容等。

考试复习课的一些截图

   ​​​​​​​ ​​​​​​​

 

范式+稳定性

完全依赖

三：不能有a+b=c

重点！！！！！

两张表中间的关系表

抽象

考前老师在微信群发语音答疑（转文字）

围绕一个案例，把需求分析、数据库的分析与设计，OO分析与设计几个工作结合来了。

一、需求分析：

第7章的内容中介绍核心内容，其中也涉及到的DFD， 定边界？、定职责？、定功能？、定权限？

让大家去理解需求，到底要干啥，它的核心怎么去设计，那么后面我们再说到用力也好，是用DFD也好，都是工具，都是为了实现需求描述的工具。而前面所说到的在需求中怎么去定边界，怎么保证语义的一致性，怎么来对不同的角色描述之后对他的职责进行确认和定义，以及通过职责定义来实现对功能的确定，其中，还需要定一些权限，那么这些工作，都是围绕需求做的，那么这个需求才是核心。

就算是拿用例分析，也是第一件事儿。是对用户分析，对不对，对角色分析，所以你们老是看到一个表象，要去认真的去思考一下这个我的需求，我怎么去，来定这个边界是拿啥定的，我们也是说从外而内，本质是这个从外外是啥？就外部实体外部实体这是DFD的定义，但是对内，对面向对象？面向对象是啥，那不就是角色吗。

需求有三个层次，那层次是啥，那需求是围绕绳儿出来的，需求三个层次，你们都知道了，那是啥呀，那咱这开始用了，那怎么去定职责，职责是谁的职责人的，就是你的角色的，你角色都定义不清楚，角色都定义少了一个，那你职责能对吗？肯定不对，那这个职责是要干嘛？就是人要跟系统交互过程中。他要完成的事情了，这就是需求，这就是定义的整个这个需求本身，那完成了一个需求，你对应的这个职责对应啥？对应就从系统角度来看，职责是从角色的角度，用户的角度，那对应的后面不就是功能吗？对不对，那功能是啥功能？就是从我们在DFD里面所讲到的那个数据的那个加工数据的处理不就这事儿吗？那到了这个用力是啥，那不就是整个用力那个东西吗。

再说到其实我把这个这个这个定义完了以后，那下面肯定有一个想法，就是这个角色也知道了，他职责也定义了，那对应的需求也清楚了，那对应的整个系统，从系统角度那个需求解决对应的那功能也定义清楚了，而且每个功能对应是哪个人的，哪个人能访问这些功，哪些人不能访问，这功能从本质上，从这个用力图里面，本身就直接就体现出来了，对不对？

？你画那个不同的外部那个，那个actor，那个actor，它能。对某些用例可以进行这个，这个导航可以进行一个操作，那有一些，他不去关联起来，那这时候他就相当没操作，那个用例的一个权利，那通过这个方式本身也是在做权限的定义，那么在权限的定义里面，角色和角色之间是不是存在一种泛化的关系，其实这个关系，本身就是在做权限设计里面经常会用到的书上，网上大量的地方都有。

从数据库从到DFD，两者合并起来，一个静态一个动态，然后组合起来，就形成了一个更大力度的面向对象，那面向对象又形成了一系列的不同的模型。

二、按要求设计数据库ER图

1.按第一范式优化 2.按第二范式优化 3.按第三范式优化

第一问数据库设计的重点是按范式优化设计 需要能体现出来怎样改变的依赖关系 使得满足二、三范式。

还有一个是RBAC的数据库设计要会画

角色—权限—操作之间的绑定 要能画出来

数据字典标出即可 不用写内容

ER图核心包括三种关系：

1）是1：n(建议多用非确定性关系，即弱关系，外键不作主键这种)

2） n:n的关系，一般是不直接用的，而应分解为2个1：n,  即加入中间表，（也就是说，只接用N:N是错误的，特别注意） ；

3）  另外一个1：1的关系， 只能用于抽象与泛化的情况之下。  如果两普通表之间存在着1:1的关系，本质上是可以合并成一张表的。

三、然后接着设计UML图

1.用例图

有个虚线框，虚线框是啥？就你系统，就是边界，你的边界之外是啥，那就外部实体就是你的角色有区别吗？

这个实际图的时候就可以把一些对象进行一个抽象，所以在那个实际图里面经常会看到有个叫匿名，匿名对象，匿名对象啥概念，已经不需要具体的名了，它可以匿名了，匿名它再往下走一步，那就是一个类，所以你会看到在很多这个实际图的表达里面是前面是对象，后面是一个类，为啥？它就告诉你在这个，通过这个抽象，把一个对象已经抽象成一个类，而在具体的这个。实意图里面是用的是这个抽象出来的一个类中的一个具体的一个对象，那么，在整个实意图里面在做一个动态的交互，那么这个，是特别需要你们知道的，所以，在我们的书上，在讲义里面都开始看到，在一开始都会有什么用力用力，在在做整个这个操作过程中，会考虑到就是在一个用力本身，和不同的这个actor在做。

2.活动图

3.时序图

先看一下MVC，再看一下类在分解过程中，存在的三个类，再理解就容易了，

4.类图

类图可以根据每个同学的理解来处理，可以以MVC，也可以接口来定义，也可以实体类为核心，上课大致说过;

类图的设计，我个人的建议可以以实体类为核心， 可以考虑 类图设计的5个核心基本原则，来进行优化;

其实通过实际图得到两个工作，第一个是对象获得一个对象和对象之间的操作，也就是说我可以建立未来不同类之间的那种关系，

所以我们在说到在整个um儿里面所涉及到的三个可能类，一个是。边界类一个控制类，还有一个呢就实体类，

最后一个工作就是关于这个变化对象中的最后一个输出，也就是一个这个这个类图了，那在类图这块儿，是肯定是必须要去做的，而且这个工作，会要求会比较高，

也就是说，我们也在说到设计过程一直是一个优化的过程，什么叫优化的过程？就是我做一个简单一个类是可以实现，基本系统的，但是这个简单，这个过程，是存在一些缺陷和问题的，那么在这个过程中，怎么能够把这样的一个类。或者这样一个能够满足整个，这个结构的一个基本的几个类和类之间的关系，然后通过我们所提供的这个设计原则，能够不断的持续优化，这才是我觉得设计中的一个本质，这才是我们考试的最核心的任务。