软件工程复习指南2-需求建模

需求分析

1. 需求分析的目的:
   • 说明软件的工作特征
   • 指明软件和其他系统元素的接口
   • 规定软件必须满足的约束
2. 需求分析的主要任务：
   • 细化在前期需求工程的基础需求
   • 构建一种或多种模型以描述用户场景、功能活动、类、类之间的关系、系统和类的行为、数据流等
3. 需求建模的总体目标:
   描述客户需要什么；
   为软件设计奠定基础；
   定义在软件完成后可以被确认的一组需求。
4. 需求建模的元素
   
   场景模型
   出自各种系统“参与者”观点的需求
   数据模型
   描述问题信息域的模型(用于建立数据库)
   类模型
   表示面向对象类（属性和操作）的模型
   数据流模型
   描述功能元素在系统中运行时怎样进行数据变换
   行为模型
   描述系统的外部行为

UML建模

介绍
关联关系
1、依赖关系（虚线箭头，指向被依赖）
依赖（Dependency）关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。
在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。
2、关联关系（实线箭头/实线无箭头）
关联（Association）关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，如老师和学生、师傅和徒弟、丈夫和妻子等。
3、聚合关系（尾部为空心菱形的实线，指向整体）
聚合（Aggregation）关系是关联关系的一种，是强关联关系，是整体和部分之间的关系，是 has-a 的关系。
聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。例如，学校与老师的关系，学校包含老师，但如果学校停办了，老师依然存在。
4、组合关系（尾部为实心菱形的实线，指向整体）
组合（Composition）关系也是关联关系的一种，也表示类之间的整体与部分的关系，但它是一种更强烈的聚合关系，是 cxmtains-a 关系。
在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象不能脱离整体对象而存在。例如，头和嘴的关系，没有了头，嘴也就不存在了。
5、泛化关系（实线空心三角形箭头，指向父类）
泛化（Generalization）关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系，是 is-a 的关系。在代码实现时，使用面向对象的继承机制来实现泛化关系。
6、实现关系（虚线空心三角形箭头，指向接口）
实现（Realization）关系是接口与实现类之间的关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的所有的抽象操作。

基于场景的建模（用例图）

1. 用例：
   用于表示系统所提供的服务，描述参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话（交互）。

2. 场景：
   场景是用例的实例化，从一个用例可以实例化出来多个用例场景。用例就是对全部场景的抽象。

3. 用例建模的步骤：

   1. 确定系统的范围和边界；
   2. 识别系统的参与者（执行者，actor）
   3. 识别用例；
   4. 对用例进行描述；
   5. 定义用例之间的关系；
   6. 审核用例模型。

4. 理解参与者
   系统外
   参与者不是系统的一部分，处于系统的外部
   系统边界
   参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定
   系统角色
   参与者与使用系统的物理人和职务没有关系
   参与者代表的是使用某个功能的一类事物，并不是特指某一个具体的人（用户）或事物，是指一个角色，是一个集体概念
   需要从参与系统的角色(作用)来寻找参与者
   与系统交互
   系统需要处理其交互过程，即系统职责
   任何事物
   人、外系统、外部因素、时间及其他抽象等事物均可
   角色与用例
   角色往往是发现新用例的基础，同时也是分析员和用户交流的起点。一个参与者可用启动多个用例，而一个用例也可以被多个参与者启动

参与者不是表示具体事物，是个抽象概念，参与者之间可以有继承关系，如系统中经理可以参加雇员的所有用例

• 识别用例：

• 参与者使用系统达到某个目标而执行的功能，用例名使用动宾短语描述

• 用例具有响应性：一个用例不自动执行，总是有参与者启动。

• 用例具备完整性：用例表示一个完整的功能，必须是一完整的描述。 必须以向参与者提供返回值作为该用例完整性的标志。

• 用例具有回执性：向参与者提供可识别的返回值，可观测的和有意义的

• 用例命名：（状语）动词+（定语+ ）宾语 比如 管理商品或名称+动词 比如 商品管理

• 用例间关系：

  • 包含(include，虚线箭头)：表示某个用例中包含了其他用例的行为
    箭头指向的用例为被包含的用例，称为包含用例；箭头出发的用例为基本用例。
    

  • 拓展（extend，虚线箭头）：指向基础用例，用例功能的延申，相当于为基础用例提供一个附加功能
    

  • 继承（泛化）（实线空心三角形箭头）：当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例
    

• 用例描述：借书过程

用例描述（活动图及泳道图）

活动图是系统动态行为建模的图形工具之一，用来表示完成一个操作所需要的活动，或者一个用例实例（场景)的活动。是一种流程图，描述活动的序列，即系统从一个活动到另外一个活动的控制流。
活动图用来显示系统中不同的工作流是如何构造的，工作流如何开始，以及从开始到结束所可能采用的判断方式。
活动图包括：动作、活动、开始节点、终止节点、动作流、对象流、分支与合并、分叉与汇合和泳道等主要组成要素。

1. 动作：动作表示一个最小的原子执行单元，即动作是不能再分解的执行单元。动作的种类包括调用、发送、接收、创建、修改销毁等。动作有3个突出的特性：原子性、不可中断性、瞬时性。
2. 活动：活动是包含一系列内部动作的执行单元，其中的每个动作可能执行零次或多次。可以理解活动是动作的一个组合或集合，是由多个动作组成的。因此，与动作恰恰相反，活动是可以分解的，可以被中断的，是占有有限时间的。
   
   泳道：在UML活动图中，泳道将活动图中的活动划分成不同的若干组，并把每一组指定给负责这组活动的业务组织或对象。在活动图中，泳道使用带头部的矩形区域表示，可以是垂直分隔的，也可以是水平分隔的，通常使用垂直分隔的比较多，泳道头部内为泳道名称。
   借书用例为例：
   

静态模型-类和对象图模型

类和对象建模用于描述一个系统的静态结构
静态模型由若干类图和对象图描述
类图由若干类的图形符号及表示其之间关联的图形符号组成
对象图是类图的一个实例，它描述了类图中各个类的特定实例以及某一时刻这些实例之间的特定链接


在软件开发的不同阶段都使用类图,但这些类图表示了不同层次的抽象。
需求分析阶段,类图是研究领域的概念;
设计阶段,类图描述类与类之间的接口;
实现阶段,类图描述软件系统中类的实现;
按照Steve Cook和John Dianiels的观点,类图分为三个层次：概念层、说明层、实现层。

常规关联
最常见的关联，在两个类之间有一条直线连接，上线写上关联名。
在关联的两端可以写上一个称为重数的数值范围，表示该类有多少个对象可以对方一个对象连接，重数得到默认值为1，符号：
“0…1”：表示“零或1”；
“0…”或“”：表示“0”或“多”；
“1…*”：表示“1或多”；
“5…11”：表示“5至11”；
“1，3，8”：是枚举型，表示“1或3或8”。

关联是类之间的连结,关联是类之间的语义联系，代表类的对象（实例）之间的一组连接（称为链）。分为：
1、常规关联
2、多元关联
3、有序关联
4、受限关联
5、或关联
6、关联类
7. 递归关联

例题：采购员从供货商处订货，双方需要签订订单，一个采购员可以订多个供货商的货品，一个供货商也可以给多个采购员供货。
要求：
1. 提取这个问题涉及的类;
2. 定义各个类之间的关系，并画出类图。

1、举出一个具有聚合关系的类图的例子。聚合关系（见上UML）是整体与部分的关系，但部分可以脱离整体存在

2、举出一个具有组合关系的类图的例子。组合关系是整体与部分的关系，一旦整体对象不存在，部分对象也将不存在

类图建模

1. 步骤：
   1. 分析问题域，确定需求
   2. 寻找分析类，确定类的含义和职责
   3. 定义类的属性和操作
   4. 确定类之间的关系
   5. 精化类和类间的关系
   6. 绘制类图
2. 什么是分析类
   分析类代表了“系统中必须具备职责和行为的事物”的早期概念模型
   分析类处理主要的功能需求，模型化问题域对象
   根据备选架构定义三类分析类

边界类：系统及其参与者的边界

控制类：系统的控制逻辑

实体类：系统使用的信息

一个较为完整的类图

动态模型

为了更准确获取到对象的行为或职责，需要对对象进行动态建模。 动态模型主要描述系统的动态行为和控制结构。包括4类图：状态图、活动图、顺序图、合作图。

顺序图

消息的标识格式：
[序号][警戒条件]*[重复次数][回送值表：= ]操作名（参数表）
1．序号：表示消息在对象间交互的时间顺序号。
2．[警戒条件]：选择项，为一布尔条件表达式。
3．*[重复次数]：选择项，表示消息重复发送的次数。
4．回送值表：以“，”区分的名字表列，分别表示完成指定操作后返回的系列值。可缺省。
5．操作名：必须是接收该消息的对象类角色中的操作名。
6．“（）”内的参数表是以“，”号区分的实参表，传送给接收消息的对象中的某个操作。

请指出下面的消息标签各部分的内容。
1:display(A )
A.序号:消息名 B.返回值：消息名
[mode=display] 1.2.3.7: redraw( B)
A.序号 返回值 消息名 B.警戒条件 序号：消息名
2 *[n:=a . . z] : prim:=nextPrim(prim)(A)
A.序号 重复次数 返回值 消息名 B.序号 返回值 消息名
3.1 [x<0] : foo( A)
A.序号 警戒条件 消息名 B.警戒条件 消息名 C.序号 消息名

协作图(合作图，通信图)

顺序图强调的是时间，而协作图（通信图）强调的是空间。在通信图中，通过链接显示对象与对象之间是如何联系在一起的，展示对象的组织
协作图(通信图)与顺序图都是交互图，用于描述系统动态行为特征的，都反映了对象之间的消息传递，在语义上是等价的。二者之间可以相互转换，但二者不能完全相互替代，二者之间是有所区别的。

状态图

状态图(State Diagram)用来描述一个特定对象的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的转移
通过状态图可以了解一个对象所能到达的所有状态以及对象收到的事件（收到消息，超时，错误等）对对象状态的影响等。
所有的类，只要它有可标记的状态和复杂的行为都应该有一个状态图。状态图是对单个类的对象的生命周期进行建模，描述了对象的动态行为，每个对象被认为是事件驱动的孤立实体。
状态图是对类的一种补充描述，它展示了此类对象所具有的可能的状态以及某些事件发生时其状态的转移情况
状态图可以精确地描述对象在生命周期中的各种状态和状态转换的情况。一个状态图包括：
状态:
状态指的是对象的状态。例如：
发票(对象)被支付(状态)
小车(对象)正在停着(状态)
发动机(对象)正在工作(状态)
电灯(对象)开着(状态)
转移:
转移的类型
自转移
源状态与目标状态为同一状态

自动转移
自动触发进入目标状态
箭头上无事件（隐式转换）

条件转移
通过分支判断确定的转移

事件:事件是已完成并能引发某种活动的一件事
动作和活动
判定和同步
判定：判定又称为“决策点”，用来表示一个事件根据不同的监护条件有不同的影响。在UML图中，判定使用空心菱形表示。
同步：可视化地定义了并发工作流的分劈（fork）与接合（join）
分劈是一个源状态分为两个或两个以上的目标状态
接合是两个以上的源状态连接为一个目标状态
同步在状态图中用一条粗短线表示，称为同步杆

建模步骤：

• 找出适合用模型描述其行为的类。
• 确定对象可能存在的状态。
• 确定引起状态转换的事件。
• 确定转换进行时对象执行的相应动作。
• 对建模的结果进行相应的精化和细化。
  
  
  
  状态图的转换不包括（C )
  A、 源状态
  B、 触发事件
  C、 消息
  D、 动作
  E、 目标状态
  F、 监护条件
  状态图的基本组成元素包括（ F )
  A、 状态
  B、 迁移
  C、 事件
  D、 动作和活动
  E、 判断和同步
  F、 以上都是
  需求建模的元素（F）
  A、 场景模型
  B、数据模型
  C、类模型
  D、数据流模型
  E、行为模型
  F、以上都是

基于数据流的建模

1. 结构化方法概述
   一种面向数据流的传统软件开发方法
   以数据流为中心构建软件的分析模型和设计模型
   分为：
   结构化分析(Structured Analysis 简称SA)
   结构化设计(Structuresd Design 简称SD)
   结构化程序设计(Structured Programmin 简称SP)
   发展历史
   提出：20世纪60年代末到70年代初
   成熟：20世纪70年代末到80年代中期
   主要思想：抽象与自顶向下的逐层分解(控制复杂性的两个基本手段)

2. 结构化分析模型
   系统模型不同的角度表述系统：
   从外部来看，对系统分析上下文或系统环境建模；
   从行为上看，对系统行为建模；
   从结构上看，对系统的体系结构和系统处理的数据结构建模。
   结构化的需求分析模型：
   功能模型（数据流模型），用来描述系统中的数据处理过程
   行为模型（状态转换模型），用来描述系统如何对事件做出响应
   数据模型（实体—关系模型）：用来描述系统中的数据及其之间的关系。

数据字典是模型的核心，它包含了软件使用和产生的所有数据的描述
数据字典由字典条目组成，每个条目描述DFD中的一个元素
数据字典条目包括：数据流、文件、数据项(组成数据流和文件的数据)、加工、源点和终点
定义数据组成的符号:

数据流组成示例：某高校可用的电话号码有以下几类：校内电话号码由4位数字组成，第1位数字不是0；校外电话又分为本市电话和外地电话两类，拨校外电话需先拨0，若是本市电话则再接着拨8位数字(第1位不是0)，若是外地电话则拨3位区码再拨8位电话号码(第1位不是0)。

电话号码=[校内电话|本市电话|外地电话]
校内电话=1{非0数字}1+3{数字}3
本市电话=0 + 1{非0数字}1+7{数字}7
外地电话=0 + 3{数字}3 + 1{非0数字}1+7{数字}7

数据流图（DFD，Data Flow Diagram）服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能。
数据流图与数据字典是密不可分的，两者结合起来构成软件的逻辑模型(分析模型)

数据流图符号：
Data Flow Diagram(简称DFD)：描述输入数据流到输出数据流的变换(即加工、处理)过程，用于对系统的功能建模，基本元素包括:
数据流图举例：设一个工厂采购部每天需要一张定货报表。定货的零件数据有：零件编号、名称、数量、价格、供应者等。零件的入库、出库事务由仓库管理员通过计算机终端输入给定货系统。当某零件的库存数少于给定的库存量临界值时，就应该再次定货。
数据流分析：
数据源点：仓管员（负责入库或出库事务给定货系统）；
数据终点：采购员（接收每天的定货报表）；
数据流：事务，定货报表；
数据存储：定货信息，库存清单；

画基本系统模型（顶层）：
第一步求精（分解）：对处理进行分解

第二步求精：

数据流图分层：

数据流图各个层次：
顶层图（第0层）只有代表整个软件系统的1个加工，描述了软件系统与外界之间的数据流
顶层图中的加工经分解后的图称为第1层图(只有1张)
中间层图中至少有一个加工(也可以有多个)在下层图中分解成一张子图
处于最底层的图称为底层图，其中所有的加工不再分解成新的子图
数据流图的编号：
顶层图只有一个代表整个软件系统的加工，该加工不必编号。
第1层图中的加工编号分别为1，2，3，…
子图号：若父图中的加工号x分解成某一子图，则该子图号记为“图x”
子图中加工的编号：若父图中的加工号为x的加工分解成某一子图，则该子图中的加工编号分别为x.1、x.2、x.3…

例题：
数据字典是软件需求分析阶段的最重要工具之一,其最基本的功能是( C)
A、数据库设计
B、数据通信
C、数据定义
D、数据维护

结构分析方法就是面向( B)的自顶向下逐步求精进行需求分析的方法。
A、目标
B、数据流
C、功能
D、对象

问题描述
学校教材购销系统从学生接受购书单，经处理后把领书单返回给学生，使学生可凭领书单到书库领书。对脱销的教材，系统则用缺书单的形式通知给书库；新书进库后也由书库将进书通知返回给系统。
学生购书流程
审查购书单的有效性（检查购书单上的内容是否与学生用书表相符）；
按购书单的内容查对教材存量表，生成领书单给学生，生成缺书信息保存到缺书登记表中，等待接到进书通知后再补售给学生。补售的手续和第一次购书相同。
采购流程
根据缺书登记表汇总后生成缺书单并送给书库保管员作为采购教材的依据。
新书入库后，要及时修改教材存量表，同时把进书信息通知销售子系统，使销售人员能通知缺书的学生补售教材。
请画出“学校教材购销系统”的顶层数据流图

请画出“学校教材购销系统”的第1层数据流图

请画出“学校教材购销系统”的第2层数据流图

基于数据的建模 （ER图）

ER图 ---- 是用来建立数据模型的工具。
ER图中包含了实体(即数据对象)、关系和属性等3种基本成分。
通常用矩形框代表实体；
用连接相关实体的菱形框表示关系；
用椭圆形或圆角矩形表示实体(或关系)的属性；
并用直线把实体(或关系)与其属性连接起来。

数据范式

常用“范式(Normal Forms)”定义消除数据冗余的程度。第一范式(1 NF)数据冗余程度最大，第五范式(5 NF)数据冗余程度最小。
1、范式级别越高，存储同样数据就需要分解成更多张表，因此，“存储自身”的过程也就越复杂。
2、随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。
3、范式级别提高则需要访问的表增多，因此性能(速度)将下降。从实用角度看来，在大多数场合选用第三范式都比较恰当。

第一范式：每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。
如：学生(学号，姓名，性别，年龄，年级，专业，籍贯)
第二范式：满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。如：选课 ( 学号，课程号，听课出勤率，作业完成率，分数 )
第三范式：符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。 如：教师(职工号，姓名，年龄，职称，职务，工资) ----- 工资依赖于职称或职务，因此其不满足第三范式