将分析模型转换为软件设计.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 用例模型是把满足用户需求的基本功能集聚合起来表示的强大工具。 获取用例是需求分析阶段的主要工作之一，而且是首先要做的工作。 大部分用例将在系统需求阶段产生，并且随着开发工作的是深入还会发现更多用例，这些新发现的用例都应及时补充到已有的用例集合中。 一个用例模型由若干用例图组成。创建用例的工作包括：定义系统，寻找角色和用例，描述用例，定义用例之间的关系，确认模型。其中，寻找行为者和用例是关键。 9.6.2 用例建模 1. 寻找行为者 为获取用例首先要找出系统的行为者，可以通过请系统的用户回答一些问题的办法来发现行为者。下述问题有助于发现行为者： 谁将使用系统的主要功能（主行为者）？ 谁需要借助系统的支持来完成日常工作？ 谁来维护和管理系统（副行为者）？ 系统控制哪些硬件设备？ 系统需要与哪些其他系统交互？ 哪些人或系统对本系统产生的结果（值）感兴趣？ 注意：在寻找系统用户的时候不要只停留在使用计算机的人员身上，直接或间接得与系统交互或从系统获取信息的任何人和任何事都是用户。 2. 寻找用例 一旦找到了行为者，就可以通过请每个行为者回答下述问题来获取用例： 行为者需要系统提供哪些功能？行为者自身需要做什么？ 行为者是否需要读取、创建、删除、修改或存储系统中的某类信息？ 系统中发生的事件需要通知行为者吗？行为者需要通知系统某些事情吗？从功能观点看，这些事件能做什么？ 行为者的日常工作是否因为系统的新功能而被简化或提高了效率？ 还有一些不是针对具体行为者而是针对整个系统的问题，也能帮助建模者发现用例，例如： 系统需要哪些输入输出？输入来自何处？输出到哪里去？ 当前使用的系统（可能是人工系统）存在的主要问题是什么？ 注意，最后这两个问题并不意味着没有行为者也可以有用例，只是在获取用例时还不知道行为者是谁。事实上，一个用例必须至少与一个行为者相关联。 3种模型分别从3个不同侧面描述了所要开发的系统：功能模型指明了系统“做什么”；动态模型明确规定了什么时候做（在何种状态下接受何种条件的触发）；对象模型定义了做事情的实体。 在面向对象方法学中，对象模型是最基本最重要的，它为其他两种模型奠定了基础，我们依靠对象模型完成3种模型的集成。 9.7 3种模型之间的关系 3种模型之间的关系： （1） 针对每个类建立的动态模型，描述了类实例的生命周期或运行周期。 （2） 状态转换驱使行为发生，这些行为在数据流图中被映射成处理，在用例图中被映射成用例，它们同时与类图中的服务相对应。 （3） 功能模型中的处理（或用例）对应于对象模型中的类所提供的服务。通常，复杂的处理（或用例）对应于复杂对象提供的服务，简单的处理（或用例）对应于更基本的对象提供的服务。有时一个处理（或用例）对应多个服务，也有一个服务对应多个处理（或用例）的时候。 （4） 数据流图中的数据存储，以及数据的源点/终点，通常是对象模型中的对象。 （5） 数据流图中的数据流，往往是对象模型中对象的属性值，也可能是整个对象。 （6） 用例图中的行为者，可能是对象模型中的对象。 （7） 功能模型中的处理（或用例）可能产生动态模型中的事件。 （8） 对象模型描述了数据流图中的数据流、数据存储以及数据源点/终点的结构。 结构化技术的缺点 不稳定：结构化分析和设计技术是围绕实现功能的过程来构造系统的，而用户需求的变化大部分是针对功能的，因此这种变化对基于过程的设计来说是灾难性的，因此这样设计出的系统结构常常是不稳定的，即用户需求的变化往往造成系统结构的较大变化。 可重用性差:把数据和操作作为分离的实体,使得一些具有潜在可重用价值的软件构建已和具体应用环境密不可分了. 9.8 小结 面向对象学的出发点和基本原则,是尽可能模拟人类习惯的思维方式,使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程,也就是使描述问题的问题空间(问题域)与实现解法的解空间(求解域)在结构上尽可能一致 从而解决了传统信息方法学中存在的如何从分析平滑过渡到设计的老问题. 面向对象方法在开发的早期定义了一系列面向问题的对象,并且在整个开发过程中不断充实和扩充这些对象.由于在整个开发过程中都使用统一的软件概念“对象”,所有其他概念(如功能、关系、事件等)都是围绕对象组成的，因此，对生命周期各阶段的区分自然就不重要、不明显了。 分析阶段得到的对象模型也适用于设计和实现阶段。由于各个阶段都使用统一的概念和符号，因此，整个开发过程时吻合一致的，或者说是无缝连接的，这自然就很容易实现