第5章需求分析与验证解析.ppt

构建分析模型的理由 分析模型比用例模型更加结构化、更加清晰直观 所以分析模型的构建过程实际上也是不断深入理解用例模型的过程，同时也是剔除用例的自然语言描述中可能存在的模糊性和不一致性的过程 分析模型是用例模型与软件设计模型之间的“桥梁” 它比用例模型更接近于设计模型，更适合于软件设计师设计软件系统的结构、构思软件求解算法，更易于为不太熟悉业务的软件设计师所理解，换言之，理解分析模型对业务知识的要求远低于理解用例模型 几点说明 需求分析立足于需求、立足于用户 仅从用户的角度、以用户易理解的方式描述需求 要注意减轻用户理解的负责，建议流程 业务/功能、机构人员分解（业务术语） 业务流程描述（业务术语） 业务分析（用例） 业务对象（数据）描述（数据字典） 仅从概念的层面描述 类间关系用线条表示，而不用字段表示 业务流程（动态分析）（数据流图） 基于图4-7 所示的家庭保安系统初步的领域概念模型，考虑到“开关机及复位处理”、“系统配置”和“传感器监测”用例均需记录日志，“日志查询”用例需要使用该日志，所以引入“日志”概念类，其主要属性包括时间、动作描述、动作执行者。 由于报警时必须描述异常事件的发生位置并且在日志中记录发现异常的传感器编号，所以“传感器”概念类具有“编号”和“安装位置”两项属性。 扩充机制适合于以下应用场景： ⑴建模者希望向模型的读者或实现者传递UML标准语义无法表达的更为精细的语义信息。 如，针对类中的操作，如果建模者希望区分查询类操作（不改变对象的属性值）和更改类操作，就必须借助扩充机制。 ⑵对于模型处理的CASE工具，依据标准的UML语义无法完成有关的处理功能，必须针对待处理的UML模型利用扩充机制进行人工标注，在某些模型元素上附加更多语义信息。 如，考察关联关系之上的“1对多”型多重性，Java代码生成工具很难确定使用何种Java集合类型来实现它，数组（array）、列表（list）还是普通的集合（collection）？如果在关联端附加“有序”、“可变数量”两条语义信息，代码生成工具就可据此选用列表类型。 ⑶针对特定的行业或特殊类别的应用，利用扩充机制定义专业性的术语和“方言”，以简化模型的表示，提高建模过程的效率。 如，可以针对电信行业应用建模的特殊需求扩充UML的表示机制。 又如，针对Web应用，设计模型需要以简单的方式区分位于客户端的类、位于Web服务端的类和后台的业务逻辑类。 顺序图是一张二维图。 其纵向代表时间轴，时间沿垂直方向向下延伸； 其横向由多个参与交互的对象构成，这些对象之间无顺序关系。 一般情况下，时间轴上的两点只有相对时序的差异，但在实时应用中，可以使用带时间刻度的时间轴以度量两点之间的绝对时差。 一张基本的顺序图由以下图形元素构成：对象及其生命线与活跃期，消息传递，注解。 例 5.9 确立分析类的属性 考虑家庭保安系统中的“监测器”类，其主要职责是“分析传感数据”。 根据图5.16，它将此职责分解为： （1）获取门窗监测灵敏度或烟雾浓度阈值； （2）判别是否出现异常； （3）在异常情况下记录日志、启动警报器、拨报警电话报告异常事件、显示异常事件。为完成第（1）、（3）项职责“监测器”通过消息传递通道求助于其他分析类。 假设“监测器”依靠某种判别算法完成第（2）项职责，该算法除门窗监测灵敏度和烟雾浓度阈值以外不需要其他数据，所以针对该类目前不需要设置属性。 * * 例5.9确立分析类的属性（续1） 再考虑“报警电话接口”类，其主要职责是“报告异常事件”。 根据例5.7，它要拨报警电话直至接通或者重拨足够多次，为此，它应该能够获取“电话号码”、“重拨延迟”和“最大重拨次数”三项数据。 如果将它们纳入“报警电话接口”类作为属性，那么，为避免数据冗余，必须从分析类图中删除“报警电话”类，让“报警电话接口”同时兼为边界类和实体类。 另一种更为自然的做法是，保留“报警电话”实体类，让“报警电话接口”通过属性查询消息从实体类中获取上述三项数据，见例5.10。 * * （五） 整理分析类图 迄今为止已经获得了覆盖多个交互图的分析类图，在分析、设计工作继续推进之前，需求工程师有必要全局地研究分析类图，视实际情况对它们进行必要的调整和优化。 第一项优化工作是，通过消除分析类在职责和属性方面的重叠或冗余以简化分析模型。 * * 整理分析类图 （1）如果两个分析类A和B具有相同或相近的职责，区分如下两种情形： A将此职责委托给B，A自身并不实际完成此职责； A和B均实际完成此职责。 第一种，分析类图中的A和B勿需调整，但必须存在一条从A指向B的通道以便传递 “委托”消息，必要时在分析类图中添加此通道，并在交互图中添加“委托”消息传递； 第二种，必须调整为第一种情形，或在不损害软件需求的完整实现的