软件工程课程第八章--需求建模

要求：掌握用例和各种UML方法的用途的特点，给定特定的场景，可以正确的建模

1. 1. 需求分析

在技术层面上，软件工程师开始于一系列的建模工作，关注的是“做什么”，而不是“怎么做”。

需求模型必须达到三个主要目标:

• 描述客户的需求;
• 为软件设计的创作奠定基础;
• 定义一组可以在软件构建后验证的需求。

需求模型在系统级描述和软件设计之间建立的桥梁

1. 分析的经验原则
2. 模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些。即不要试图解释系统如何工作。
3. 需求模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域，功能和系统行为的深入理解。
4. 关于基础结构和其他非功能的模型应推迟到设计阶段再考虑。
5. 最小化整个系统内的关联。
6. 确认需求模型为所有利益相关者都带来价值。对模型来说，每个客户都有自己的使用目的。
7. 尽可能保持模型简洁。
   1. 需求分析的要素
8. 1. 基于场景的建模（灵活运用）

[用例]只是帮助定义系统外部（参与者）和系统应该执行的内容（用例）。

1. 描述系统使用线程的用户场景的集合
2. 每个场景都是从一个“参与者”的角度来描述的——一个以某种方式与软件交互的人或设备

角色代表人或设备扮演的角色作为系统功能

用户可以在给定的场景中扮演许多不同的角色

利益相关者是对系统感兴趣的各方，可以影响或受到系统的影响

1. 1. 开发一个用例
2. 参与者执行的主要任务或功能是什么？
3. 参与者将获取、产生或更改什么系统信息？
4. 参与者是否必须通知系统外部环境的变化？
5. 参与者希望从系统中获得什么信息？
6. 参与者是否希望知道意外的变化？
   1. 安全屋案例

• 简述：我们的研究表明，家庭安全系统的市场正以每年40%的速度增长。我们希望通过建立一个基于微处理器的家庭安全系统来进入这个市场，该系统可以保护和/或识别各种不受欢迎的“情况”，如非法进入、火灾、洪水等。该产品暂时被称为SafeHome，它将使用适当的传感器来检测每种情况，可以由房主编程，并在检测到情况时自动致电监控机构。

• 参与者：房主、设置管理器、传感器、监控和响应子系统
• 房主如何与家庭安全功能互动？

• 输入密码以允许所有其他交互
• 查询安全区域的状态
• 查询传感器的状态信息
• 在紧急情况下按紧急按钮
• 激活/关闭安全系统

用例图

• 关闭安全系统

1. 房主观察SafeHome控制面板，以确定系统是否准备好输入。如果系统还没有准备好，房主必须关闭窗户/门，以便准备指示灯显示。

2. 房主使用小键盘输入一个四位数字的密码。密码与系统中存储的有效密码进行比较。如果密码不正

确，控制面板将发出哔哔声一次，并重置自身以进行额外输入。如果密码正确，控制面板等待进一

步操作。

3. 房主选择或者键入stay或away来激活系统。Stay只激活周边传感器(内部运动检测传感器关闭)。Away激活所有传感器。

4. 当激活发生，房主可以观察到一个红色的警报灯。

• 用例：通过互联网访问摄像机监视设备-显示摄像机视图
• 参与者：房主

1. 房主登录SafeHome产品网站；

2. 房主输入账号；

3. 房主输入两个密码（每个至少8个字符长度）；

4. 系统显示所有的主要功能按钮；

5. 房主从主要功能按钮中选择“监视”；

6. 房主选择“选取摄像机”；

7. 系统显示房屋的平面设计图；

8. 房主从平面设计图中选择某个摄像机图标；

9. 房主选择“视图”按钮；

10. 系统显示一个由摄像机编号确定的视图窗口；

11. 系统在视图窗口内以每秒一帧的速度显示视频输出。

1. 活动图

通过提供特定场景中交互流的图形表示来补充用例

活动图使用两端为半圆形的矩形表示一个特定的系统功能，箭头表示通过系统的流，菱形表示分支（标记从菱形发出的每个箭头），实水平线意味着并行发生的活动。增加了一些细节，用例图无法完成的细节，用户可以尝试有限次的输入账号和密码，通过“提示重新输入”的判定菱形来体现。

1. 泳道图

允许建模器表示用例描述的活动流程，同时指示哪个参与者（如果特定用例中涉及多个参与者）或分析类负责活动矩形描述的操作。