【系统分析师之路】第六章需求工程记忆敲出Part2-CSDN博客

本文链接：https://blog.csdn.net/Last_Impression/article/details/124206628

【系统分析师之路】第六章需求工程记忆敲出Part2

系统分析师记忆敲出需求工程

- 【系统分析师之路】第六章需求工程记忆敲出Part2

一. 需求分析的概念

在需求获取过程之后，紧接着要做的就是需求分析和建模的过程。
需求分析包括了结构化分析和面向对象分析两种，随着技术的不断发展和面向对象开发技术的普及，面向对象需求分析技术逐渐在取代相对比较老的结构化需求分析。

二. 结构化需求分析的概念

结构化需求分析主要是建立三大模型：功能模型，行为模型和数据模型。
这三个模型分别对应三种图：DFD数据流图，状态迁移图，ER实体联系图。
在这三个模型的中间，有一个中间结点就是数据字典。
结构化时代最重要的两个流：数据流和控制流。

三. 数据字典的概念

数据字典是用来做数据的解释说明工作的。
不管在结构化还是在面向对象的需求分析过程中，数据字典就是作为支撑模型的存在。
数据字典具体用来描述什么内容呢？从DFD图中去联想，数据字典可以描述数据加工，外部实体，数据流，数据元素，数据存储，数据结构等信息。
比如在DFD图中，我们要对【注册请求】这个数据流具体包含哪些内容进行详细的说明，这个时候就是数据字典登场的时候了。

四. 用例图中的弱实体概念

它相当于依附某个实体的实体。
比如员工实体包括了经理和服务员，那么我们就说经理实体和服务员实体就是员工实体的弱实体。
站在数据模型的视角，不管是经理还是服务员，都保存在一个员工表中，使用弱实体指示为了表现和单独讨论的时候方便罢了。

五. 数据流图的概念

DFD图强调自顶向下逐步求精的设计方针。
它的最概略的图就叫做顶层图，0层图是顶层图的详细描述，而1层图又是0层图的详细描述，这样从顶层到底层实现了逐步细化求精。
DFD图遵循平衡原则。0层图和1层图在输入输出中应该是一样的，这叫做平衡原则，但1层图是0层图的细化。
如果在数据流图中，抠掉某些线上的数据流的名字让你补充的时候，可以运用平衡原则来填充。因为根据原理任何一个输入输出都应该是平衡的。
自顶向下逐步分解，其实分解的就是数据流图中的加工。
###六. 数据流图的图形表达
DFD图中由四个元素组成：加工，数据流，数据存储，外部实体。
数据流是用实线来表示，加工使用圆圈来表示，数据存储使用两根平行线，比较直观，而外部实体使用方框来表示。
外部实体其实和UML用例图中的小人很接近，而加工和用例图中的椭圆型比较接近，DFD中的两根平行线，将来就可以用ER图将它具体化。

七. 面向对象分析的概念

面向对象分析的英文为Object-Oriented Analysis，按照面向对象的思想去分析业务需求。
进行模块化的处理，描述问题的本质，区别每个问题的不同点相同点，确定问题中的对象。
面向对象方法的系统分析和系统设计之间界限已经不明显了。UML既可以用在分析阶段也可以用在设计阶段。
面向对象分析的任务包括:
1.建模系统功能
2.发现并确定业务对象
3.组织对象并确定对象之间的关系
它的主要任务就是发现对象并进行筛选。

八. 结构化需求分析与面向对象分析的区别

结构化强调的是对业务现状和方法进行分析；而OOA则是使用面向对象的思想对建立所需要的素材，并对其归类和整理的过程。
面向对象分析最大的优点就是强调了复用，快速适应需求的变化而进行调整，还有更加方便用户的参与，还能帮助我们系统分析师加强对问题域和系统责任的理解。
UML中的用例图，顺序图等就是作面向对象分析工作的产物；数据流图，ER图，状态图是结构化需求分析的产物。

九. 面向对象分析中的三个类的概念

在面向对象世界中，提到了三个类：实体类，控制类，边界类。
实体类对应的是ER图中的数据模块，一般用在信息系统的内部；
通过用例图可以找到，系统和系统外部角色之间的交互，边界类就是定义了外部实体访问信息系统内部的一个接口类；
有了接口类和实体类，他们两者之间是怎么联系在一起的呢?于是就需要有衔接接口类和实体类的类：也就是控制类；
实体类：是一个在地面的球的图形表示;在静态图中的类名上面，有<< entity >>这个标识。
控制类：一个类似于苹果的图形表示;在静态图中的类名上面，有<< control >>这个标识。
边界类：一个黏在墙壁上的圆球的图形表示;在静态图中的类名上面，有<< boundary >>这个标识。
边界类：用户界面类，系统接口类，设备接口类都属于边界类
控制类：控制类的设计与用例实现有着很大的关系，一个用例可能对应多个控制类对象
实体类：用于对必须存储的信息和相关行为建模的类

十. 需求规格说明书与项目范围说明书的区分

SRS需求规格说明书是用来定义项目的需求的，经过批准之后的SRS就可以形成需求基线。
项目范围说明书是用来对产品或项目详细的范围进行描述。它和WBS，WBS词典共同构成了项目范围的基准。
我们可以根据SRS也就是需求基线作为输入，做成相应的范围说明书。
需求基线变化了，那么项目范围说明书必然要更新；如果项目范围基准发生变化，SRS不一定会发生变化。

十一. 面向对象的多态（Polymorphism）

多态是同一个行为具有多个不同表现形式或形态的能力。多态就是同一个接口,使用不同的实例而执行不同操作。
多态往往需要使用高层类的指针去指向低层类的对象，然后进行统一化的的操作。
比如一个动物类，猫类和狗类继承了动物类，它们都有"叫"这个Function，对于动物类来说，"叫"是他们的共同的类。
而小猫喵喵叫，小狗汪汪叫就是多态的很好的一个应用。

十二. 面向对象中的重载，覆盖，隐藏和接口

重载就是在一个类中有相同的类名，但是同名的方法它们的参数不同，在调用的时候，根据你调用同名方法时使用不同的参数，来达到重载的目的。
覆盖就是一个子类的方法覆盖掉父类中同名同参数的方法，从而达到实现不同功能的目的。当然使用覆盖的时候有一个前提，就是父类需要定义虚方法virtual关键字，但是父类同名方法不是接口方法。
隐藏指的是派生类的函数屏蔽了与其同名的基类函数。如果派生类的函数与基类的函数同名，并且参数也相同，但是基类函数没有virtual关键字，这个时候如果调用派生类对象的同名方法时，派生类的同名方法将被调用。换个角度看父类的同名非虚方法在这个时候就被隐藏掉了。
接口是一种类，它只有接口而没有对于接口的实现。在接口里面定义的方法都是纯虚函数。

十三. 继承和泛化的区别与联系

继承和泛化其实在很多时候可以理解为是一回事情。在UML中继承和泛化的图形标识也是一样的。它们都表示一般与特殊的关系。
接下来说说继承和泛化之间的区别。
继承往往是站在子类的角度讲，继承是子类需要对父类获取；而泛化是站在父类的角度，在父类描述的基础之上，对子类进行扩展。
继承关系是泛化关系的反关系，也就是说子类是从父类继承的，而父类则是子类的泛化。

十四. UML4+1视图

UML采用4+1视图来描述软件和软件的开发过程，软件架构也可以使用4+1视图来进行描述。4+1视图提出的本质就是将复杂的问题简单化
程序员一般关注的是实现视图，包括了具体物理代码文件和组件
系统分析师一般关注的是逻辑视图，逻辑视图内包括了类和对象等一连串系统逻辑的信息
系统集成人员一般关注的是进程视图，进程视图关注的是并发，进程线程等信息。
系统与网络工程师一般关注的是部署视图，部署视图内包括了系统中软件和硬件是如何部署的。
最终用户一般关注的是用户视图，也就是最终我们将在什么样的场景下如何使用系统。

十五. UML用例图中的三种关系

UML依赖关系既有包含也有扩展。也就是说用例图中也可以理解为只有两种关系：依赖关系（包含，扩展），泛化关系。
泛化关系(generalization)：两个用例之间有父子关系的时候使用。比如用户注册用例包括了邮件注册和电话注册，这两个注册和用户注册时父子关系，在这里就是泛化。
包含关系(include)：在UML1.0中叫做使用关系，包含关系中多个用例包含着一个用例，而每次动作任何一个用例，都会去调用这一个公共的用例，比如存款用例和取款用例，他们每次被调用的时候，都需要去调用查询余额用例，那么存款用例和取款用例中就包括了查询余额用例。
扩展关系(extend)：和包含关系类似，但是与被包含的用例每次都会被调用相比，被扩展的用例并不会每次100%的被调用的场合，那么就可以使用到扩展关系。比如查询书籍信息用例和修改书籍信息用例之间的关系就是扩展关系。每次查询不一定都会去修改书籍的信息，但是有一定的概率，查询后去修改书籍信息。
还有箭头的方向是需要特别注意的，在包含关系中，箭头指向被包含的用例；而在扩展关系中，箭头不是指向被扩展出来的用例，这点需要特别的注意。

十六. UML用例图的概念

用例图的三个基本组件：Actor角色，用例UseCase，关系Relationship。
用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图的主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。

十七. 活动图的概念

将进程或其他计算结构展示位计算内部一步步的控制流和数据流。活动图专注于系统的动态视图，它对系统的功能建模和业务流程建模特别重要，并强调对象之间的控制流程。活动图中还可以表示为泳道。
泳道图：具体描述哪些事情有那种角色去完成描述清楚。

十八. 用例建模的四步流程

识别参与者
合并需求获得用例
细化用例描述
调整用例模型
步骤1-3是必须的，而步骤4不是必须的。白话用例建模的步骤就是：识别小人，做成椭圆，使用用例规约去描述去细化椭圆，调整椭圆。

十九. 关于用例规约的概念

用例图中有用例规约的存在，用例规约在我看来其实就是用例图的数据字典。
用例规约包括了用例的名称，用例ID，进入用例的前置条件，执行完用例以后退出用例打算后置条件，对用例功能的详细说明，哪些角色使用了这个用例，本用例和其他用例之间的关系是怎样的等等等等。
PS：相对于基本事件流，用例规约还包括了异常事件流。（事件流包括了参与者动作和系统的响应）。

二十. UML图的四种关系

这里的四种关系容易和用例图中的三种关系相互混淆概念，所以要特别注意。
第一种是实现关系，UML中有接口，那么接口的实例化就是实现关系；
第二种是泛化关系，这里的泛化关系和用例图中所说的泛化关系是一回事；特殊一般的关系就是UML中的泛化关系。
第三种是关联关系，关联关系包括了组合关系和聚合关系两种。它描述了一组链，链是对象之间的连接。
组合关系和聚合关系一个用的是实心的菱形箭头，一个则是用空心的菱形；它们之间最大的区别就是生命周期不同。
整体与部分生命周期相同的叫组合；整体与部分之间生命周期不同的叫聚合。
最后一种是依赖关系，一个对象的变化让另外一个对象也同时发生变化。

二十一. UML中的四种事物分别是什么

结构事务
注释事务
分组事务
行为事务
其中注释事务最好理解，在UML图中总有一些事务是需要加注解的；
当UML图多起来了，怎么去归纳和整理呢，这个时候就需要分组事务，比如包，构件看起来好像一个盒子，这就是分组的事务；
结构事务对应的就是UML静态图中的类，对象，接口，活动类，构件等元素，它是最静态的部分；
行为事务刚好与结构事务相对应，比如消息，动作次序，连接等，它代表了时间和空间上的动作。

二十二. UML中的图的分类

UML中的图分为了静态图（结构图）和动态图（行为图）
结构图：类图，部署图，组件图，对象图，构件图，包图，制品图。
行为图：活动图，顺序图，通信图，用例图，状态图，定时图，交互概览图。
通信图和顺序图我们又可以把它称之为交互图。
静态图表现系统中稳定的组成部分。

二十三. 活动图与程序流程图之间的区别与联系

程序流程图来自于结构化分析与开发，活动图多用于面向对象的分析与开发；
活动图可以表示多个进程并行的执行，程序流程图没有这个功能；
活动图中有泳道的概念，所以活动图可以表示不同角色之间参与活动流程的细节，而程序流程图没有这个功能。

二十四. 需求建模的概念

需求建模包括了用例模型和分析模型两个方面。
用例模型的步骤之前已经有说过了，分为四步。首先识别参与者，接下来合并需求获得用例，第三步是细化用例，最后一步也是可有可无的，就是对现有的用例进行调整。
分析模型的建立和用例模型建立的步骤完全不一样，它先是定义概念类，识别类之间的关系，为类添加相应的职责，最后建立交互图。
用自己的话概括总结就是先定义类，然后看类与类之间存在的关系，第三给类添加相应的方法，最后建立起交互图来。