第14讲——第10章 面向对象分析与建模(10.1-10.2).ppt

《软件工程》第14讲第10章 面向对象分析与建模(10.1-10.2) 主讲人：李淑芝 第10章 面向对象基础 10.1 用例驱动分析 10.2 领域与业务建模 10.3 系统行为建模 10.4 POS机系统案例分析 10.5 分布式结对编程系统分析与建模 ▲ Robustness分析 技术 Ivar Jacobson曾提出了 一种健壮性分析（俗称鲁棒分析）技术。 鲁棒分析是在用例模型的基础上所做的进一步分析，帮助对用例模型的正确性、完善性进行检查，并从中发现一些新的对象及类，以及相关的责任，从而对分析模型的完善提供了支持。 精化用例 鲁棒分析 解决方案 可依据架构师的设计，进行最终的解决方案设计； 通常可套用开源框架或公司内部平台框架。 用例图 一幅用例图包含的模型元素有系统、行为者、用例及用例之间的关系。 （1）系统 系统被看作是一个提供用例的黑盒子。 代表系统的方框的边线表示系统的边界，用于划定系统的功能范围，定义了系统所具有的功能。 代表外部实体的行为者置于方框外。 自动售货机系统用例图 （2）用例 一个用例是可以被行为者感受到的、系统的一个完整的功能。 在UML中把用例定义成系统完成的一系列动作，动作的结果能被特定的行为者察觉到。 这些动作除了完成系统内部的计算与工作外，还包括与一些行为者的通信。 用例具有下述特征： —用例代表某些用户可见的功能，实现一个具体的用户目标； —用例总是被行为者启动的，并向行为者提供可识别的值； —用例必须是完整的。 （2）用例 注意，用例是一个类，它代表一类功能而不是使用该功能的某个具体实例。 用例的实例是系统的一种实际使用方法，通常把用例的实例称为脚本。 脚本是系统的一次具体执行过程。 例如，在自动售货机系统中，张三投入硬币购买矿泉水，系统收到钱后把矿泉水送出来，上述过程就是一个脚本。 又如：李四投币买可乐，但是可乐已卖完了，于是系统给出提示信息并把钱退还给李四，这个过程是另一个脚本。 （3）行为者（参与者） 行为者是指与系统交互的人或其他系统，它代表外部实体。 参与者既可以是使用该系统的用户，也可以是与系统交互的其他外部系统、硬件设备或组织机构。 行为者代表一种角色而不是某个具体的人或物。事实上，一个具体的人可以充当多种不同角色。 （3）行为者（参与者） 在用例图中用直线连接行为者和用例，表示两者之间交换信息，称为通信联系。 行为者触发（激活）用例，并与用例交换信息。单个行为者可与多个用例联系；反之，一个用例也可与多个行为者联系。 实践表明，行为者对确定用例是非常有用的。 面对一个大型、复杂的系统，要列出用例清单往往很困难，可以先列出行为者清单，再针对每个行为者列出它的用例。 这样做可以比较容易地建立起用例模型。 （4）用例之间的关系 UML用例之间主要有扩展和使用两种关系，它们是泛化关系的两种不同形式。 1）扩展关系 向一个用例中添加一些动作后构成了另一个用例，这两个用例之间的关系就是扩展关系。 后者继承前者的一些行为，通常把后者称为扩展用例。 如：自动售货机系统。 把提供售罐装饮料的常规动作放在“售货”用例中，而把售散装饮料的非常规动作放置于“售散装饮料”用例中。 这两个用例之间的关系就是扩展关系。 含扩展和使用关系的用例图 （4）用例之间的关系 2）使用关系 当一个用例使用另一个用例时，这两个用例之间就构成了使用关系。 如果在若干个用例中有某些相同的动作，则可以把这些相同的动作提取出来单独构成一个用例（称为抽象用例）。 当某个用例使用该抽象用例时，就好像这个用例包含了抽象用例中的所有动作。 结论： 在描述一般行为的变化时采用扩展关系； 在两个或多个用例中出现重复描述又想避免这种重复时，可以采用使用关系。 一个用例模型由若干幅用例图组成。 创建用例模型的工作包括：定义系统，寻找行为者和用例，描述用例，定义用例之间的关系，确认模型。 其中，寻找行为者和用例是关键。 1）寻找行为者 a.谁将使用系统的主要功能（主行为者）？ b.谁需要借助系统的支持来完成日常工作？ c.谁来维护和管理系统（副行为者）？ d.系统控制哪些硬件设备？ e.系统需要与哪些其他系统交互？ f.哪些人或系统对本系统产生的结果感兴趣？ 2）寻找用例 一旦找到了行为者，就可以通过请每个行为者回答下述问题来获取用例： a.行为者需要系统提供哪些功能？行为者自身需要做什么？ b.行为者是否需要读取、创建、删除、修改或存储系统中的某类信息？ c.系统中发生的事件需要通知行为者吗？