软件工程（第3版）—第5章需求分析与验证.ppt

谢谢 * * 根据交互图确立分析类的属性 如果一个分析类A为了完成其自身职责而需要的数据不能自然地设为其属性，将其归为另一分析类B的属性更为妥当，那么，应该将其确定为B的属性，并且在交互图中添加一条从A到B的消息以获取该数据。 属性表示方式：属性既可以严格地采用UML中类的属性的表示，也可以仅采用简短的自然语言中的名词或名词短语。 在目前阶段，需求工程师没有必要过分担心分析类的属性列表的完全性，只需将分析类为完成职责所必需的信息列入其属性表即可，后续的设计过程将进一步精化类的属性定义，见9.5节。 * 国防科技大学计算机学院 * 例 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的通道以便传递 “委托”消息，必要时在分析类图中添加此通道，并在交互图中添加“委托”消息传递； 第二种，必须调整为第一种情形，或在不损害软件需求的完整实现的前提下，将此职责从A、B二者之一中剔除。 * * 整理分析类图 （2）如果分属于A和B的两项职责具有公共的子职责，那么可考虑设置单独的辅助类C，让其完成此公共子职责，然后在分析类图中增加分别从A、B指向C的通道，并在交互图中增加相应的消息传递。 辅助类的UML构造型为helper。 * * 整理分析类图 （3）利用面向对象中的继承和代理机制实现多个分析类之间对职责和属性的共享。 在面向对象技术中有两种基本的方法可实现软件复用： 继承法和代理法，分别见图5.19和图5.20。 在图5.19中，Fax类直接复用其父类Telephone中的dial和hangUp功能； 在图5.20中，Fax类通过消息传递通道将这两项功能委托给Telephone类。 * * 整理分析类图 继承法和代理法各有优势： 前者的代码量较小，但子类可以改变被复用的父类中访问权限为protected、public的属性和操作，这样容易破坏父类中数据和处理逻辑的完整性； 后者的代码量稍大，但被复用的类对于复用类而言完全是黑箱，两个类之间的耦合度较轻。 一般推荐采用代理法实现复用，除非被复用类与复用类之间存在非常自然的继承关系。 * * 整理分析类图.复用 图5.19利用继承机制实现复用 图5.20利用代理机制实现复用 * * 整理分析类图 另一项优化工作是，将规模过大的分析类图分拆为若干张规模适度的类图。这要用到包图。 在整个软件开发过程中，包图用于以结构化、层次化的方式组织、管理大型的软件模型，使得分别处理不同包的开发团队之间的相互干扰程度降至最低； 在业务分析和需求定义阶段，包图可用于刻画业务系统和软件需求的结构； 在设计和实现阶段，包图可用于描述软件系统的高层结构。 可以将若干分析类划归不同的包，针对每个包绘制分析类图。 * * 例 5.10 导出分析类图 综合前述分析结果可导出家庭保安系统的分析类图，如图5.21所示。 * * 图5.21 家庭保安系统的分析类图 * * 5.5 利用快速原型辅助需求分析 原型的分类： 探索性原型 实验性原型 进化性原型 探索性原型：这类原型是问题域中某些子系