面向对象分析与建模.pptVIP

**用例与用例的确定UML将用例定义为“由系统执行的一个动作序列，并能产生可观察的结果值给某个特定的参与者”。这里的动作可以包括与参与者间的通讯、执行计算以及系统内部的工作等。 用例确定首先要弄清系统的问题域、业务流程，梳理系统的功能需求，在此基础上结合已经识别的角色，并确定和描述用例。**用例与用例的确定可以通过以下几个问题帮助进行判断：某个参与者要求系统为其提供什么功能？参与者需要创建、销毁、更新或存储系统中的某些信息吗？系统中的事件一定要告知参与者吗？参与者需要告诉系统一些什么吗？系统内部的事件从功能的角度代表什么？由于新功能的识别，参与者的日常工作被简化或效率提高了吗？上面是针对已经识别的参与者，下面的问题针对系统：系统需要什么样的输入/输出？输入来自哪里?输出去哪里？该系统的当前情况存在哪些主要问题？**用例场景用例对应并描述一个完整的功能，由一定的业务步骤组成，其中还会涉及业务的变化、出错以及异常情况，这些就是用例场景。用例场景需要以一定的方式加以描述，从而形成一个完整的用例。**用例场景简要说明 描述该用例的作用，包括执行用例的不同类型用户和通过这个用例要达到的结果。 **用例场景前置条件前置条件是用例执行之前必须满足的前提条件。例如，前置条件是另一个用例已经执行或用户具有运行当前用例的权限，但并不是所有用例都有前置条件。**用例场景主事件流和其他事件流 用例的具体细节在主事件流和其他事件流中描述。事件流是从用户角度描述执行用例的具体步骤，关注系统“做什么”，而不是“怎么做”。主事件流和其他事件流包括：用例如何开始和结束、用例如何与参与者交互、用例的正常流程（主流程）、正常流程的扩展、变化和错误流（其他事件流）。**用例场景后置条件后置条件是用例执行完毕后必须为真的条件。与前置条件一样，后置条件可以增加用例次序方面的信息，如要求一个用例执行后必须执行另一个用例，就可以在后置条件中进行说明。当然，并不是每个用例都有后置条件。**用例间的关系在用例图中，用例间可具有多种关联，通过这些关联，可以从系统中抽取出公共行为及其行为变化，从而简化用例图。分为：(1)包含关系(2)扩展关系(3)泛化关系**用例间的关系包含关系很多用例可以用其他的更简单的用例来描述。一个用例可以简单地包含其他用例具有的行为，并把该行为作为自身行为的一部分，这就是包含关系（Include）。这时，新用例（包含其他用例的用例）不是初始用例（被包含的用例）的一个特殊例子，所以不能被初始用例所代替。**用例间的关系包含关系在UML中，包含关系表示为虚线箭头加include字样，箭头指向被包含的用例，填写订单验证订单include**用例间的关系扩展关系一个用例也可以被定义为基础用例（Baseusecase）的增量扩展，它和基础用例的关系就是扩展关系（Extend），扩展关系是把新的行为插入到己有用例中的方法。同一个基础用例的几个扩展用例可以在一起使用。基础用例的扩展增加了原有的功能，系统应用的是基础用例而不是扩展用例，在应用基础用例时，只有当某些条件成立，或某些情况发生时，才会同时就用扩展用例的功能。**用例间的关系扩展关系在UML中，扩展关系表示为虚线箭头加extend说明，箭头指向被扩展的用例（即基础用例）借书交纳罚金extend**用例间的关系泛化关系一个用例可以有一个或多个子用例，它们之间的关系就是用例泛化。在UML中，用例泛化与其他泛化关系的表示法相同，用一个带箭头的实线从子用例指向父用例**用例间的关系泛化关系销售网上销售门市销售**静态建模UML的静态建模机制 静态建模反映系统的静态结构，支持系统的功能需求，也就是系统要提供给最终用户的服务。静态建模主要通过类图、对象图和包图表示。类图不仅定义系统中的类，描述类之间的联系，如关联、依赖和聚合等，还包括类的内部结构，即类的属性和操作。**静态建模类图中的组成元素 类图用来描述类的结构及其相关内容，具体内容包括类、接口、协作以及它们之间关系，它是一种静态模型类型。类图不仅显示了系统内的信息结构，也描述了系统内的信息行为。**静态建模类的属性及描述 类的属性用来描述类所代表的事物的特性，这些特性是所有的对象所共有的。此外，属性值也可以用来描述对象的状态。**静态建模类的操作及可见性 类的操作是对该类的对象实例所做事务的抽象，相当于一个服