软件工程课件 SE1101-lecture10 2系统示例——从分析到设计.ppt

考勤卡系统从需求到设计1-2-从需求到分析Analysis workflowAnalysis workflowAnalysis Class-3-从分析到设计Design ClassSubsystemAnalysis ClassDesign workflowDesign workflow-4-基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 3 详细、完整地描述需求详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包1. 获取原始需求 52. 开发一个可以理解的需求2.1 识别参与者开发者：谁将使用这个应用程序？客 户：所有用它来记录可记帐以及不可记帐的工时记录可记帐以及不可记帐的工时的雇员雇员开发者：现在考勤卡应用程序是什么样的？客 户：每半个月就用一个Excel表格来记录每个雇员都将通过他的表格填好，然后用电子邮件发给我这个表格相当标准：纵向是收费项目代码，横向是日期雇员可以在每个条目上填写说明开发者：这个收费项目代码可以从什么地方得到？开发者：谁来管理收费项目代码管理收费项目代码？客 户：嗯，必要的时候由我（业务经理）（业务经理）来添加这个代码。

而每个经理总会告诉他的下属应该填写什么62. 开发一个可以理解的需求2.2 识别用例开发者：谁将使用这个应用程序？客 户：所有用它来记录可记帐以及不可记帐的工时记录可记帐以及不可记帐的工时的雇员雇员开发者：现在考勤卡应用程序是什么样的？客 户：每半个月就用一个Excel表格来记录每个雇员都将通过他的表格填好，然后用电子邮件发给我这个表格相当标准：纵向是收费项目代码，横向是日期雇员可以在每个条目上填写说明开发者：这个收费项目代码可以从什么地方得到？开发者：谁来管理收费项目代码管理收费项目代码？客 户：嗯，必要的时候由我（业务经理）（业务经理）来添加这个代码而每个经理总会告诉他的下属应该填写什么7-8-2. 开发一个可以理解的需求2.3 构建用例图 11、Record Time2、Comment Time Entry3、Create Charge Code4、Export Time Entries-9-2. 开发一个可以理解的需求2.3 构建用例图 2-10-用例规约组成 用例名称 用例标识 涉及的参与者 描述 用例的规格说明 前置条件 PreConditions 后置条件 PostConditions 正常事件流 Flow of events 备选事件流 Alternate flow 其它 非功能需求、设计约束、尚存在的问题-11-3 详细、完整地描述需求进行用例阐述UC01：“Record Time”用例文档用例名称：Record Time（记录时间）用例标识：UC01涉及的参与者：雇员、系统管理员描述：雇员利用“Record Time”用例来登记他们的工时 系统管理员用这个用例为任何雇员登记时间前置条件：用户必须已经登录到这个系统后置条件：系统将雇员的工时正确的记录到数据库中-12-3 详细、完整地描述需求进行用例阐述正常事件流：1.雇员查看当前时间之前输入的数据；2.雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的；3.雇员从当前的时间段选择一个日期；4.雇员输入以正整数表示的工时；5.系统在视图中显示这个数据，并在以后的视图中看到这个数据。

备选事件流1：雇员更改他的时间1.雇员查看当前时间之前输入的数据；2.雇员选择一个已有的条目；3.雇员改变工时；4.在视图中更新这个信息，并在以后的视图中都可以看到13-3 详细、完整地描述需求进行用例阐述非功能需求：无设计约束：无部署约束：用户可以从客户端或雇员的家中访问到“Record Time”用例，如果是从客户端访问，则要考虑到客户端的防火墙未解决的问题雇员是否可以在以前的考勤卡上输入和更改时间雇员是否可以在以后的考勤卡上输入和更改时间，例如，在休假之前？-14-建立第一个迭代周期1-1-风险风险2-2-重要性重要性3-3-合适性合适性-15-经典的三层构架-1数据库记录销售信息支付授权表示层表示层应用逻辑层应用逻辑层存储层存储层-16-MVC备选构架示意图-17-面向对象分析过程 面向对象的分析方法：用例分析技术 用例分析技术是基于用例的，在每一次迭代中针对每一个用例： 1. 寻找候选对象对象清单 2. 描述对象间的交互交互图（顺序图） 3. 描述类类图（VOPC）-18-1. 寻找候选对象对象清单 寻找用于解决某个用例的一组对象 寻找对象的准则 限制每一个分析类（analysis class）的职责 对类和方法采用一致的命名 保持分析类的简单 寻找对象的步骤（MVC构架） 实体（Entity） 边界（Boundary） 控制（Control） 生命周期（Lifecycle）-19-步骤1：实体对象 实体对象（entity object）对系统的业务数据和业务逻辑进行封装 解决问题所需要的全部数据和行为，然后将这些数据按相关性分组 识别出重要的名词，并将它们作为实体对象，之后确定每一个实体对象包含的数据和行为 识别实体对象检查表（checklist-2）寻找对象的步骤（MVC构架）实体（Entity）边界（Boundary）控制（Control）生命周期（Lifecycle）-20-寻找实体对象-Record Time正常事件流：1. 1.雇员雇员查看当前时间段之前输入的数据时间段之前输入的数据；2.雇员从已有的支付号码支付号码中选择一个，这些收费代码收费代码是按客户客户和项目项目组织的；3.雇员从当前的时间段时间段选择一个日期日期；4.雇员输入以正整数表示的工时工时；5.系统在视图视图中显示这个数据数据，并在以后的视图中看到这个数据。

备选事件流1：雇员更改他的时间1.雇员查看当前时间之前输入的数据；2.雇员选择一个已有的条目已有的条目；3.雇员改变工时工时和/或支付号码支付号码；4.在视图中更新这个信息，并在以后的视图中都可以看到备选事件流1：雇员提交考勤卡考勤卡1. 雇员雇员 已有条目已有条目 收费代码收费代码 客户客户 项目项目 工时工时 考勤卡考勤卡寻找对象的步骤（MVC构架）实体（Entity）边界（Boundary）控制（Control）生命周期（Lifecycle）-21-步骤2：边界对象 边界对象（boundary object）描述系统将如何用参与者交互 通过检查在用例图中的参与者与用例之间的关系，可以识别出边界对象 在分析模型中，每一对参与者/用例都构成了一个边界对象 边界对象可分为两种： 用户界面：允许系统与人交互 系统接口：允许系统与其他系统交互 识别边界对象检查表（checklist-3）寻找对象的步骤（MVC构架）实体（Entity）边界（Boundary）控制（Control）生命周期（Lifecycle）-22-寻找边界对象寻找对象的步骤（MVC构架）实体（Entity）边界（Boundary）控制（Control）生命周期（Lifecycle）-23-步骤3：控制对象 控制对象（control object）为其他对象提供工作流和会话服务 在边界对象访问实体对象的时候，控制对象将一系列复杂的请求封装成通用的工作流，使这种访问变得简单 从边界对象发出的高级的消息将被转换成一系列从控制对象发往实体对象的消息 通常，每一个用例都应该有一种控制对象 识别控制对象检查表（checklist-4）寻找对象的步骤（MVC构架）实体（Entity）边界（Boundary）控制（Control）生命周期（Lifecycle）-24-寻找控制对象寻找对象的步骤（MVC构架）实体（Entity）边界（Boundary）控制（Control）生命周期（Lifecycle）-25-步骤4：对象生命周期类 对象生命周期类（object lifecycle classes）跟踪实体对象 对象的创建、定位，以及销毁 控制对象或者实体对象需要根据不同的准则来定位一个实体对象 常见的生命周期对象有factory、container等，当然这些名字不适合分析模型 识别生命周期类检查表（checklist-5）寻找对象的步骤（MVC构架）实体（Entity）边界（Boundary）控制（Control）生命周期（Lifecycle）-26-识别生命周期类检查表checklist-5 生命周期类是否定位、创建和销毁实体对象？生命周期类是否定位、创建和销毁实体对象？ 生命周期类是否只专用于一类实体对象？生命周期类是否只专用于一类实体对象？-27-2. 描述对象间的交互 描述对象间的交互，从而寻找对象行为 寻找对象行为的准则 确保方法之间的内聚性 采用清楚明确的方法名 完全满足用例要求 保持简单 描述行为的步骤 将以识别的参与对象加到顺序图中 从参与者开始，一步步寻找行为 验证行为序列-28-描述对象交互正常事件流：1.雇员查看当前时间段之前输入的数据；2.雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的；3.雇员从当前的时间段选择一个日期；4.雇员输入以正整数表示的工时；5.系统在视图中显示这个数据，并在以后的视图中看到这个数据。

备选事件流2：雇员提交考勤卡1.雇员看到当前时间段之前输入的数据；2.雇员选择提交考勤卡；3.系统要求雇员确认他的选择，并提醒他将不能再编辑这些条目；4.考勤卡被提交，再也不能对它进行编辑29-3. 描述类 顺序图描述了用例中对象间的交互关系；而对象间的交互要用到类的方法以及类之间的关系 描述类的准则 完整 保持简单 维持类的一致性 描述类的步骤 将对象的行为合并到类中 重构类，使其符合规则 发现类之间的关系 完成该用例“参与类类图”（VOPC, View of Participating Classes Class Diagram）-30-Record Time用例中类的关系-31-总结：用例分析过程 评估用例，确定迭代周期 在每一次迭代中的每一个用例： 1. 寻找候选对象 获得各类对象清单：实体类、控制类、边界类 2. 描述对象间的交互-顺序图 针对每个事件流，通过顺序图演示用例的实现过程 3. 描述类-类图 完成类图，描绘类图中的关系 重构类图，构造整个系统的分析模型设计1、体系结构设计2、用例设计3 3、子系统、子系统设计设计4、类设计5、数据库设计32-33-1、体系结构设计过程 1. 确立目标 2. 将类分组 3. 展示技术 4. 抽取子系统 5. 针对准则和目标对体系结构进行评估-34-将类分组并评估各个类 将分析类划分成几个候选包，并对它们的内聚性进行评估 目标是使每个包具有清晰的且严格定义的目的和职责 结合体系结构模式，考虑分组方式 实体类(功能，业务数据和业务规则) 用户界面类（复杂的人机界面处理） 控制类（将来自边界消息转化后传往实体类） 系统接口类（封装与外部系统交互细节，EDI，协议，RPC等） 生命周期类（实体类生成、定位、销毁） 描述包之间的耦合度：包依赖关系图用户界面类 AdministrativeLoginUI:让用户输入用户名和密码，来验证是否获得授权使用系统。

很显然，从该类的目的来看，可以归为简单数据输入 EmployeeLoginUI：因为该类提供与AdministrativeLoginUI相同功能，所以它必定具备相同的用户界面复杂度：简单数据输入-35-用户界面类 RecordTimeAdministrativeUI：该类向管理员用户提供为任何雇员输入工时的功能即显示已有的时间条目，又允许用户输入新的时间条目，另外还能够更新已有的时间条目从目的得出结论，它最为匹配的分类应该是简单的数据输入和静态数据视图-36-用户界面 类-37-例：考勤卡用户界面部署约束 仔细阅读用例，可以得到：对于系统而言，存在两类明确的部署约束对于雇员的Login和Reco。