05电子数据交换.pptVIP

第五章 用例视图 一、概述 二、参与者（Actor） 三、用例（Use Case） 四、用例图建模技术 一、用例图概述 画好用例图（Use Case Diagrams）是由软件需求到最终实现的第一步，在UML中用例图用于对系统、子系统或类的行为的可视化，以便使系统的用户更容易理解这些元素的用途，也便利了软件开发人员最终实现这些元素。 UML中的用例图描述了一组用例、参与者以及它们之间的关系。用例图包括以下3方面内容。 （1）用例（Use Case） （2）参与者（Actor） （3）依赖、泛化以及关联关系 二、参与者（Actor） 参与者（Actor）是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者由他们参与用例时所担当的角色来代表。 在图形上，参与者用人形图符表示。 识别用例 识别用例最好的办法就是从分析系统的参与者开始，考虑每个参与者是怎样使用系统。使用这种策略的过程中可能会找出一个新的参与者，这对完善整个系统建模很有帮助。 在识别用例的过程中，通过以下的几个问题可以帮助识别用例： （1）特定参与者希望系统提供什么功能？ （2）系统是否存储和检索信息？如果是，这个行为由哪个参与者触发? （3）当系统改变状态时，通知参与者吗？ （4）存在影响系统的外部事件吗？ （5）是哪个参与者通知系统这些事件？ 用例与事件流 用例分析是处于系统的需求分析阶段，这个阶段应该尽量的避免去考虑系统实现的细节问题。也就是说，用例描述的是一个系统做什么，而不是怎么做。 可以通过一个清晰的，易被用户理解的时间流来说明一个用例的行为。这个事件流包括用例何时开始和结束，用例何时和参与者交互，什么对象被交互以及该行为的基本流和可选流。 用例间的关系 用例除了与其参与者发生关联外，还可以参与系统中的多个关系，这些关系包括：泛化（Generalization）关系、包含（Include） 关系和扩充（Extend） 关系。应用这些是为了抽取出系统的公共行为和变种。 四、用例图建模技术 对语境建模 对系统语境建模可以参考如下方法。 （1）得出需要从系统中得到帮助的组；执行系统功能必须的组；与外界进行交互的组；执某些辅助功能的组，并由此来识别系统外部的参与者。 （2）将类似的参与者组织成泛化的关系中。 （3）如需加深理解，可以为参与者提供构造型。 （4）说明用例图中参与者和用例间的通信路径。 对需求建模 软件需求就是根据用户对产品的功能的期望，提出产品外部功能的描述。需求分析师的工作是获取系统的需求，归纳系统所要实现的功能，使最终的软件产品最大限度的贴近用户的要求。需求分析师的一般只考虑系统做什么（what），而尽可能的不去考虑怎么做（how）。 对系统功能建模可以参考如下方法： （1）识别系统外部的参与者，从而建立系统的语境。 （2）考虑每一个参与者期望的行为或需要系统提供的行为。 （3）把公共行为命名为用例。 （4）确定供其他用例使用的用例和扩展其他用例的用例。 （5）在用例图中对这些用例、参与者和它们间的关系建模。 （6）用描述非功能需求的注释修饰用例图。 * 三、用例（Use Case） 用例是一个叙述型的文档，用来描述一个参与者（Actor）使用系统完成某个事件时的事情发生顺序。用例是系统的使用过程。更确切的说，用例不是需求或者功能的规格说明，但用例也展示和体现出了其所描述的过程中的需求情况。 图形上用例用一个椭圆来表示，用例的名字可以书写在椭圆的内部或下方。 学习动物精神 11、机智应变的猴子：工作的流程有时往往是一成不变的，新人的优势在于不了解既有的做法，而能创造出新的创意与点子。一味 地接受工作的交付， 只能学到工作方法 的皮毛，能思考应 变的人，才会学到 方法的精髓。 学习动物精神 12、善解人意的海豚：常常问自己：我是主管该怎么办才能有助于更好的处理事情的方法。在工作上善解人意， 会减轻主管、共 事者的负担，也 让你更具人缘。