掌握软件工程基础：知识点全面解析【chap03、chap05、chap06、chap08、chap09】

chap03 UML

UML定义了哪些视图？分别具有什么特点？

1．用例图（Use case diagram）

       用例图展示各类外部执行者与系统所提供的用例之间的连接。一个用例是系统所提供的一个功能的描述，执行者是指使用这些用例的人或外部系统，执行者与用例的连接表示该执行者使用了此用例。

一个论坛系统的用例图

2．类图(Class diagram)

1. 类图描述系统中类的静态结构。不仅定义系统中的类，表示类之间的联系如关联、依赖、聚    合等，也包括类的内部结构(类的属性和操作)
2. 类图是以类为中心来组织的，类图中的其他元素或属于某个类或与类相关联 

类之间的关系及其UML表示

3.对象图( Object Diagram )

4. 顺序图(Sequence Diagram)

5.  协作图(Collaboration Diagram)

6. 状态图（State Chart Diagram）

状态图通常是对类描述的补充，它说明该类的对象所有可能的状态以及哪些事件将导致状态的改变。

7. 活动图(Activity Diagram)

8.构件图(Component Diagram)

9. 部署图(Deployment Diagram)

10. 包图（Package Diagram）

chap05 需求工程概论

需求分析分为哪几个阶段？有哪些主要技术和方法？

1. 需求获取/收集 (需求搜集/需求确认与审核)

• 目标： 收集所有潜在的需求，理解项目目标和期望成果。
• 主要活动：
  • 与利益相关者（用户、客户、管理层等）进行访谈，了解他们的期望和需求。
  • 进行市场调研，分析竞争对手的产品和市场趋势。
  • 进行用户调查，收集用户反馈。
  • 分析现有文档和数据，了解现有系统或流程的性能。
• 主要技术和方法：
  • 访谈： 与用户或利益相关者进行一对一或小组访谈。
  • 问卷调查： 发放问卷以获取大量用户反馈。
  • 文档分析： 分析现有文档或数据。
  • 头脑风暴： 集体讨论，激发创意。
  • 原型法： 快速创建原型，与用户交互并收集反馈。

2. 需求分析/定义 (精确分析与准确定位/需求分析)

• 目标： 对收集到的需求进行分析、整理、归纳和提炼，去除冗余和冲突，形成清晰、完整、一致的需求规格说明。
• 主要活动：
  • 对需求进行分类和组织，例如按功能、性能、安全性等进行分类。
  • 识别需求的优先级，确定哪些需求是必须实现的，哪些是可选的。
  • 创建需求模型，例如用例图、数据流图、实体关系图等。
• 主要技术和方法：
  • 用例图： 描述用户与系统之间的交互。
  • 数据流图： 描述系统中数据的流动和处理过程。
  • 实体关系图： 描述系统中数据的组织和关系。
  • 数据字典： 定义数据元素的含义和属性。
  • 结构化分析方法 (SA)： 包括数据流图、数据字典、实体关系图等。
  • 面向对象分析方法 (OOA)： 包括用例图、类图、对象图等。

3. 需求分类和组织/需求协商和确认 (测试验证必不可少/需求分发)

• 目标： 将分析后的需求进行分类、组织，并与利益相关者进行协商和确认，确保大家对需求的理解一致。
• 主要活动：
  • 将需求整理成文档，例如需求规格说明书。
  • 与利益相关者进行评审，收集反馈并进行修改。
  • 对需求进行优先级排序，确定开发顺序。
• 主要技术和方法：
  • 需求规格说明书： 详细描述软件系统的功能、性能、接口等方面的需求。
  • 评审会议： 与利益相关者共同审查需求文档。
  • 原型验证： 使用原型与用户交互，验证需求的正确性和可行性。

4. 需求验证 (归纳总结阶段/需求实现和需求验证)

• 目标： 验证需求是否完整、正确、一致、可行，并确保所有利益相关者都理解和接受这些需求。
• 主要活动：
  • 进行需求测试，例如编写测试用例。
  • 进行用户验收测试，确保系统满足用户需求。
• 主要技术和方法：
  • 测试用例设计： 根据需求编写测试用例。
  • 用户验收测试 (UAT)： 用户在实际环境中测试系统。

chap06 面向数据流的分析方法

数据流图的绘制、根据信息流的类型(变换流、事务流)映射为程序结构图

四元素

三句话 

1. 分解 平衡 联系  
2. 数据守恒
3. 静态实体

父图输入输出数据流等于子图输入输出数据流    每个加工至少有一个输入数据流和一个输出数据流

画数据流时需注意的问题

       如：下图中读下张卡属于控制流，不应画出。    

1. 数据流 (Data Flow)

数据流描述的是数据在系统中的流动和转换过程。它关注的是“什么数据”在“哪里”被“如何”处理。数据流图（DFD）是描述数据流的常用工具，它使用箭头表示数据的流向，使用方框或圆角矩形表示数据的处理过程。

在你的例子中：

• “卡片信息” 就是数据流。它是从“读入卡片”这个处理过程输出，并作为“卡片校验”这个处理过程的输入。

2. 控制流 (Control Flow)

控制流描述的是程序执行的顺序和逻辑。它关注的是“按照什么顺序”执行“哪些操作”。控制流决定了程序中各个步骤的执行顺序，例如条件判断、循环、分支等。控制流图（CFG）是描述控制流的常用工具，它使用箭头表示控制的转移，使用节点表示程序的基本块。

在你的例子中：

• “读下张卡” 是控制流。它表示在“卡片校验”之后，如果需要继续处理其他卡片，程序应该跳转回“读入卡片”这个步骤。它并不表示有任何数据在流动，而是表示程序执行的流程发生了跳转。

为什么“读下张卡”不应该作为数据流画出？

因为它不是数据。它是一个指令，告诉程序下一步要做什么。把它画成数据流会造成误解，让人以为“读下张卡”是一个可以被处理和传递的数据。

 o不要标出激发条件

加工的命名

错误(1)

错误(2)

错误示例（用“X”标示）：

• 数据源 ╳ 数据终点： 数据不能直接从数据源流向数据终点。数据源是数据的发出者，数据终点是数据的接收者。数据必须经过处理才能从源头到达终点。例如，顾客（数据源）不能直接获得最终的账单（数据终点），而是需要经过一系列处理，如点餐、计算价格等。
• 数据源 ╳ 数据存储： 数据不能直接从数据源存储到数据存储中。数据需要经过处理才能被存储。例如，顾客的信息（数据源）不能直接存入数据库（数据存储），而是需要经过验证、格式化等处理。
• 数据存储 ╳ 数据终点： 数据不能直接从数据存储流向数据终点。从数据存储中读取的数据也需要经过处理才能被使用。例如，从数据库（数据存储）中读取的商品信息不能直接显示给用户（数据终点），而是需要经过格式化、排版等处理。
• 数据存储 ╳ 数据存储： 数据不能直接在一个数据存储流向另一个数据存储。数据的转移或复制也需要经过处理。例如，将数据从一个数据库（数据存储）迁移到另一个数据库（数据存储），需要经过数据提取、转换、加载等处理。

分解的程度

分解的深度与层次：

chap08-面向数据流的设计方法

变换分析

步骤一 复审基本系统模型

  基本系统模型指顶级ＤＦＤ和所有由外部提供的信息。这一设计步骤是对系统规格说明书和 软件需求规格说明书进行评估。这两个文档描述软件界面上信息的流程和结构。

   图8.4和图 8.5分别为“家庭保安系统”的顶层和第一层数据流图。

步骤二  复审和精化软件数据流图

  精化软件需求规格说明书中的分析模型，直至获得足够详细的ＤＦＤ。

如，由“传感器监测子系统”的第一级（图8.５的局部）和第二级（图8.６）ＤＦＤ进 一步推导出第三级数据流图（图8.７）。

   每个变换对应一个独立的功能，可望用一 个具有较高内聚度的模块实现，至此已有足够的信息用于设计“传感器监测子系统”的程序结构，精化过程亦可结束。

步骤三 确定ＤＦＤ为变换流还是事务流。

        系统内部的信息流总可以用变换流表示，倘若具有明显的事务特性，还应该采用针对事务流的映射方法。设计人员首先要判定ＤＦＤ中占主导地位的信息流，并确定其特性，然后孤立出具有变换特性或事务特性的支流，这些支流将用于精化由主导数据流推出的程序结构。

        以图8.7所示ＤＦＤ为例，数据沿一个传入路径进来，沿三个传出路径离开，无明显的事务中心，该信息流应属变换流。

步骤四  划定输入流和输出流边界孤立变换中心。

 输入、输出流边界的划分可能因人而异，不同的设计人员可能把边界沿着数据通道向前推进或后退一个处理框，这对最后的软件结构影响不大。

“传感器监测子系统”的流界在图8.７中用虚线表示。

步骤五

  执行“一级分解”导出具有三个层次的程序结构。

如图8.８所示，主控模块负责协调下面几个中层控制模块：

输入流控制模块，接收所有输入数据；

变换流控制模块，对内部形式数据进行加工、处理；

输出流控制模块，产生输出数据

一级分解

   图8.８展示的是一个简单三叉结构，实际处理大型系统的复杂数据流时，可能需要两个甚至多个模块对应上述一个模块的功能。

“一级分解”的原则

   在完成控制功能并保持低耦合度、高内聚度的前提下尽可能减少模块数。

传感器监测子系统一级分解结果

   控制模块的名字概括了所有下属模块的功能。

步骤六

  执行“二级分解”

   把数据流图中每个处理框映射成程序结构中一个适当的模块，二级分解过程是从变换中心的边界开始沿输入、输出通道向外移动，把遇到的每个处理框映射为程序结构中的一个模块。

二级分解

步骤七

  采用启发式设计策略，精化所得程序结构雏形，改良软件质量。

  对于程序结构的雏形，以“模块独立”为指导思想，对模块或合或拆，旨在追求高内聚、低耦合，易实现、易测试、易维护的软件结构。

(１）因只存在唯一一条传入路径，故输入控制模块可删除；

(２）由变换中心产生的整个子结构可归并为“建立警报条件”一个模块（选择电话号码的功能纳入其中），变换控制模块不再需要；

(３）“格式化显示”和“生成显示”两个模块归并为“产生显示”一个模块。

事务分析

当数据流具有明显的事务特征时，即能找到一个事务（亦称触发数据项）和一个 事务中心，采用事务分析法更为适宜。

下面以“家庭保安系统”中“用户交互子系统”为例，说明事务分析法。

该子系统的第一级数据流图如图8.５所示，精化后得到如图8.１４所示第二级 数据流图。图中“用户命令数据”流入系统后，沿三条动作路径之一离 开系统，若将数据项“命令类型”看作事务，该子系统的信息流具有明显的事务 特征。

事务分析法的步骤与变换分析方法基本类似，主要差别在于从数据流图到程序结构的映射。

事务分析法可分为七个步骤

步骤一  复审基本系统模型；

步骤二  复审并精化软件数据流图；

步骤三  确定数据流图的特性；／前三步与变换分析法相同／

步骤四  找出数条动作路径的公共源头，即为事务中心，确定由事务中心发出的每一动作路径的数据流特性。

图8．14的事务中心是 “启动命令处理”框。

图8．15划定接受路径与所有动作路径的界限，判定每一动作路径上数据流的特征。

步骤五

   把数据流图映射为事务处理型的程序结构。

　事务处理型的程序结构由“ 输入”和“散转”两部分组成，输入部分的构成方法如变换分析法，即从事 务处理中心开始，沿输入通路向外推进，每个处理框映射为一个模块。

“ 散转 ”部分顶层为一“散转”模块，它总控所有对应于每一动作路径的控制模块，每条动作路径都根据它的信息流特征映射为一个程序子结构。

用户交互子系统的一级分解

步骤六

  分解并精化事务结构以及每条动作路径所对应的结构。

　这些子结构是根据流经每一动作路径的数据流特征，采用本节或上节所述设计步骤导出的。

  图8.１８给出了各条动作路径映射后的程序结构。

步骤七

  使用启发式设计策略，精化所得程序结构雏形，改良软件质量。

  这一步骤与变换分析法相同。

chap09-面向对象的需求分析及设计

用例图、类图的绘制以及几种关系的理解

用例图

五种常见元素：

1. 参与者 (Actor)：

   • 表示与系统进行交互的外部实体，可以是人、组织、其他系统或设备。
   • 用一个小人图标表示，通常位于系统边界之外。
   • 例如：顾客、管理员、银行系统等。

2. 用例 (Use Case)：

   • 表示系统提供的一个完整的功能单元，描述了参与者与系统之间的一次交互过程，以达到某个特定的目标。
   • 用一个椭圆表示，内部写有用例的名称，通常使用动词+名词的短语。
   • 例如：购物、登录、支付订单等。
3. 关联关系（Association）：表示参与者与用例之间的通信和交互，用一条直线表示，箭头指向消息的接收方。

4. 系统边界 (System Boundary)：

   • 用于划分系统内部和外部的界限。
   • 用一个矩形框表示，用例通常位于矩形框内部，参与者位于矩形框外部。

5. 注释 (Note/Comment)：

   • 用于对图中的元素或关系进行解释和说明。
   • 用一个带有折角的矩形表示，内部写有注释内容。

四种主要关系：

关联 (Association)：

• 表示参与者与用例之间的交互关系，表明参与者使用某个用例。
• 表示方法：带箭头的实线，箭头指向用例。
• 举例说明：用户登录系统

包含 (Include)：

• 表示一个用例的功能包含在另一个用例中，被包含的用例是必须执行的。
• 用一条带箭头的虚线表示，箭头指向被包含的用例，线上标注 <<include>>。
• 用于提取多个用例中的公共部分，提高代码复用性。
• 例如：用户在账号登录过程中，包括输入账号、输入密码、确认登录等操作

扩展 (Extend)：

• 表示在一个用例的基础上，在特定条件下增加一些额外的功能，扩展的用例是可选的。
• 用一条带箭头的虚线表示，箭头指向被扩展的用例，线上标注 <<extend>>，并附带扩展条件。
• 用于处理异常情况或可选功能。
• 例如：用户在登录过程中忘记了密码

泛化 (Generalization)：

• 表示用例之间的继承关系，子用例继承父用例的所有属性和行为，并可以添加新的属性和行为。
• 用一条带空心三角形箭头的实线表示，箭头指向父用例。
• 也用于表示参与者之间的继承关系。

（PS：泛化关系的箭头不是指向被泛化，而是指向被继承。泛化和继承是不同的方向。泛化是从下到上的抽象过程，继承是从上到下，从一般到特殊的过程。）

• 例如：VIP会员和普通用户，归纳为用户；账号登录与微信登录，也可归纳为登录系统。

类图

在UML中类属性的一般语法格式为：

[可见性] 属性名称 [：属性的类型] [=初始值] [{属性字符串}]

[可见性] 方法名 [（参数表）] [：返回类型] [{属性字符串}]

在面向对象软件工程中，将类划分为以下三种类型。

（1）实体类（Entity Class）

          实体类表示系统问题空间内的实体。

（2）边界类（Boundary Class）

              边界类用于处理系统内部与外部之间的通信，为系统的

              参与者或其他系统提供接口。

（3）控制类（Control Class）

          控制类用于控制系统中对象间的交互

区分类的关系怎么表示

（1）依赖关系（用虚箭线表示）

所谓依赖关系，就是构造这个类的时候，需要依赖其他的类，比如：动物依赖水和氧气。如下图所以：

（2）继承、泛化关系（用带空心三角形的实线表示）

继承（泛化）关系，它指定了子类如何特化父类的所有特征和行为。例如：鸟是动物的一种，企鹅、鸭、大雁是鸟的一种。

（3）实线关系（用带空心三角形的虚线表示）

一种类与接口的关系，表示类是接口所有特征和行为的实现。它有两种表示方法：

第一种，矩形表示法，

• 顶端有<<interface>>
• 第一行：接口名称
• 第二行：接口方法

第二种，棒棒糖表示法

• 圆圈旁为接口名称
• 接口方法在实现类中出现

（4）关联关系（用实箭线表示）

所谓关联关系，就是这个类有一个属性是其他类。

5）聚合关系（用带空心菱形的实线表示）

聚合关系是关联关系的一种，是强的关联关系 ；

特点： 部分对象的生命周期并不由整体对象来管理。也就是说，当整体对象已经不存在的时候，部分的对象还是可能继续存在的。比如：一只大雁脱离了雁群，依然是可以继续存活的。

（6）组合关系（用带实心菱形的实线表示）

组合关系同样是关联关系的一种，是比聚合关系还要强的关系。

特点：在组合中，部分与整体生命期一致，部分与组合同时创建并同时消亡 。比如：鸟与翅膀的关系。

时序图、活动图的绘制

时序图

时序图常用消息类型

时序图的组成元素
1、角色（Actor）
系统角色，可以是人、机器、其他系统、子系统；在时序图中用一个小人图标表示。
2、对象（Object）
一是包括对象名和类名，二是只显示类名，三是显示对象名不显示类名，这几种方式都可以，就看你的时序图需要哪种，哪种更加容易理解就选择哪种。排列不重要，不过对象要尽量靠拢。为了整个图形的整洁和可视化需求。
3、生命线（Lifeline）
从对象图标向下延伸的一条虚线，用来表示对象存在的时间。
4、控制焦点（Focus of Control）
表示时间段的符号，在这个时间段内对象将执行相应的操作。
5、消息（Message）
消息分为3种，同步消息（Synchronous Message），异步消息（Asynchronous Message）和返回消息（Return Message）。

如何制作时序图
01、当我们画时序图的时候，要边界清晰，识别交互的语境
02、需要将需要绘制的交互场景中的角色以及对象梳理出来
03、从触发整个交互的某个消息开始，在生命线之间从上到下按顺序画出所有消息，并注明每个消息的特征。

做时序图的顺序
1）定目标，指定用例或业务目标展开分析
2）找对象，找出参与实现目标的对象/角色
3）列消息，按时间顺序列出对象的交互消息

活动图

1. 起点是活动图的初始状态，也是活动图的起始位置，表示一个工作流的开始。起点只能作为转换（Transition）的源，而不能作为转换（Transition）的目标。起点在活动图中只允许有一个。活动图中起点的表示方法与状态图中起点的表示方法相同。

2. 终点是活动图的最后状态，也是活动图的终止位置。与起点相反，终点只能作为转换（Transition）的目标，而不能作为转换（Transition）的源。终点在一个活动图中可以有一个或有多个，也可以没有。活动图中终点的表示方法与状态图中终点的表示方法相同。

• 活动表示一个工作流或一个过程中任务的执行，包括动作状态和活动状态。
• 动作状态是指执行原子的、不可中断的动作，并在此动作完成后通过转换转向另一个状态。在UML中，动作状态使用带圆端的矩形表示，动作状态的名称写在该矩形内部。
• 活动状态用于表示非原子的运行，可被进一步分解。活动状态的表示方法与动作状态相似，只是活动状态可以添加入口动作、出口动作、动作状态等。

o活动图中的转换用于描述两个活动之间的关系，表示一个活动执行完相应的操作后会自动转换到另一个活动。与状态图中不同的是，这种转换一般不需要特定事件的触发。活动图中转换的表示方法与状态图中转换的表示方法相同。

分支也称判定，是软件系统流程中十分常见的一种结构。在活动图中，分支描述了对象在不同的判定结果下所执行的不同动作。通常，分支包括一个进入转换和两个（或多个）输出转换，即有一个入口和两个（或多个）出口。每个出口都应带有监护条件，当且仅当该监护条件成立时，相应的出口路径才有效。在所有的出口中，其监护条件必须互斥，而且应该尽量覆盖所有的可能性，这样才可以保证有且仅有一条输出转换能够被触发。在UML中，分支被表示为菱形框

o在活动图建模的过程中，可能会遇到这样的情况：存在两个或多个并发执行的控制流。为了描述这种并发执行，在活动图中可以使用分叉和汇合。在UML中，分叉和汇合都被表示为比较粗的实线，该实线也称为同步条，分水平和垂直两种。