用例分析(Usecase Analysis)和类的设计
用例分析
用例分析用於
解释用例的目的
分析以及它在生命周期中的执行位置
识别执行事件用例流程的类
将用例行为分配给这些类，确定类的责任
开发用例模型实现，该模型对所确定的类的实例之间的协作进行建模
用例分析包括
用例模型(Use-case Model)、類(Analysis Classes)、分析模型(Analysis Model)、用例實現(Use-case Realization)、軟件架構文檔(Software Architecture Document)、項目專用設計指南(Project Specific Guidelines)、术語表(Glossary)、補充規約(Supplementary Specifications)
用例分析步驟
补充用例描述
针对每个用例实现
从用例行为中查找类
将用例行为分配给类
对于每个结果类
描述责任
描述属性和关联
资格分析机制
统一類
检查点
由用例到系統
用例(Use Case)->類(Analysis Classes)->設計元素(Design Elements)->源代碼(Source Code)->可執行系統(Exec)
将用例行为分配给类
对于每个用例的事件流：
确定类
将用例的职责分配给类
在交互图中为类建模
把用例圖轉為用例實現(時序圖、協作圖)
将职责分配给类
用类的构造型做指导
边界类: 行为包括与参与者的联系
实体类: 行为包括封装数据
控制类: 用例或事件流特有的行为
谁需要履行职责所需的数据？
如果一个類有数据，职責放在該類
如果多个类有数据：
把职责放在一个類上，然后增加一个关系
创建一个新类，将职责放在新类中，并将关系添加到执行职责所需的类中
将职责放在控制类中，并将关系添加到执行职责所需的类
時序圖解析
client object: 客户端对象
supplier object: 服務端对象
object lifeline: 对象生命线
message: 信息
focus of control: 控制的焦点
perform responsibility: 履行职责
reflexive message: 自反信息(不必請求其他類就能返回值)
perform another responsibility: 履行另一項职责
hierarchical message numbering: 分層信息編號
協作圖(Collaboration Diagrams)
與時序圖等價
类的设计
邊界類(Boundary Class)
提供了对参与者或外部系统交互协议的接口
为用例中涉及到的每对参与者/用例设计一个边界类来封装面向这个参与者的接口
接口与系统外部之间的中介
几种类型
用户界面类(关注于用户界面的交互内容，不是具体窗体构件)
系统接口类(关注于定义什么通信协议，不要关注协议的实现细节)
设备接口类
實體類(Entity Class)
系统的关键抽象
在系统中存储和管理
存储（通常具有持久性）一些现象的信息，并包含与这些信息相关的业务规则
如学生，计划表，课程清单
如何确定实体类
将用例的事件流作为输入
获取用例的关键抽象
过滤名词的方法：
对事件流中的名词加下划线
去除冗余的候选名词
去除含义不明确的候选名词
去除参与者
去除实现结构
去除属性
去除操作
控制類(Control Class)
用例行为协调器
更复杂的用例通常需要一个或多个控制案例
封装一个或多个用例所特有的控制行为
控制类有效地分离了边界对象和实体对象，使系统更能承受系统边界的变更
如何确定控制类
通常为每个用例设计一个控制类，封装这个用例的顺序
由時序圖轉化為UML類圖(描述类)
時序圖的每一條鏈(兩個對象相連的直線)都會轉化為關聯(兩個類相連的直線)
两个对象有整体-部分的关系是聚集关系
两个对象被认为是独立的是关联关系
不确定时使用关联关系
描述分析機制
收集所有分析机制形成列表绘制客户类到分析机制的映射图
确定分析机制的特征
类到分析机制的映射图
课程表类使用的持久性:
粒度: 每张课程表占用1到10千字节
容量: 上限为2,000张课程表
访问频率
创建: 每天500次
读取: 每小时2000次
更新: 每天1000次
删除: 每天50次
其它特征
合并類
總結
檢查：班級
這些類是否合理？
每個類的名字是否清楚地反映了它扮演的角色？
這個類是否代表一個明確定義的抽象？
所有的屬性和職責是否在功能上相結合？
班級是否提供了所需的行為？
班上的所有具體要求是否都是針對？
檢查：用例功能的实现
是否已處理所有主要和/或子流程，包括特殊情況？
是否找到了所有需要的對象？
所有行為是否已明確分配給參與對象？
行為是否已分配給正確的對象？
哪裡有幾個交互圖，他們的關係是否清晰一致？