第九章面向对象分析讲义.ppt

复旦大学计算机科学与工程系 软件工程课程 第9章 面向对象分析 教学目的与要求 ⒈掌握面向对象分析的基本概念; ⒉掌握UML关于用例模型的有关概念; ⒊掌握UML关于用例模型的建立方法； 4.会应用UML建立静态模型和动态模型； 教学重点⒈面向对象分析的基本概念; ⒉面向对象分析建模;⒊ 应用UML分析和建立系统用例模型;⒋应用UML建立系统静态模型和动态模型。 问题域与系统责任 交流问题 需求的不断变化 复用的要求 抽象 封装 继承 分类 聚合 关联 消息通讯 粒度控制 行为分析 业主 业务提出者 业务管理者 业务执行者 第三方 用户 3．确定业务范围 在进行需求访谈之前，还需要对业务范围进行规划。业务范围的确定需要考虑项目的周期、成本和可行性等众多因素。业务范围并不是系统的建设范围，而是在需求调研的范围。业务范围可以从业务目标，涉众期望开始。例如在本例中教务人员在确定新学期开课目录前，需要参考各专业课程设置。而专业课程设置并没有在系统中维护，同时在确定新学期开课目录时，需要考虑的因素较为众多。所以可以取消计算机进行新学期课程设置的功能，而改为线下进行。 4．需求调研准备 这就要求系统分析人员在做需求调研前，一定要做好准备工作，对业务问题，访谈人的背景有一个充分的了解。在访谈过程中能够理清用户的业务问题。同时对于某些核心问题，往往会涉及到多个业务人员的工作，为了理清这一业务，需要系统分析人员能够针对这一问题，将问题设计各方组织起来进行专项讨论以达到理清业务需求的目的。 5．制定项目计划 在准备工作的最后，最终要的一项工作就是制定项目计划。 （1）参与者 参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者由参与用例时所担当的角色来表示。参与者用名字写在下面的人形图标表示。 每个参与者可以参与一个或多个用例。参与者有三大类： 系统用户 与所建造的系统交互的其他系统 一些可以运行的进程。 参与者可以划分为发起参与者和参加参与者。发起参与者发起用例的执行过程，一个用例只有一个发起参与者，但可以有若干个参加参与者。 参与者还可以划分为主要参与者和次要参与者，主要参与者是执行系统主要功能的参与者，次要参与者是使用系统次要功能的参与者。通过主要参与者有利于找出系统的核心功能，往往也是用户最关心的功能。 寻找参与者可以从以下几个问题入手： 系统开发出来后，主要功能被谁使用？ 谁需要借助系统来完成日常工作？ 系统需要从哪里获得数据？ 系统会为哪些人或其他系统提供数据？ 系统会与那些系统交互？ 系统由谁负责管理和维护？ 谁对本系统的结果感兴趣？ （2）用例 用例是外部可见的系统功能单元，这些功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用例的用途是，在不揭示系统内部构造的前提下定义连贯的行为。 用例的定义包含它所必需的所有行为—执行用例的主线次序、标准行为的不同变形、一般行为下的所有异常情况及其预期反应。从用户角度来看，上述情况很可能是异常情况：从系统角度来看，它们是必须被描述和处理的附加情况。更确切地说，用例不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。在UML中，用例用一个椭圆来表示，用例的名字可以书写在椭圆的下方，如图所示。 识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。 在识别用例的过程中，通过回答以下的几个问题，系统分析者可以获得帮助。 特定参与者希望系统提供什么功能； 系统是否存储和检索信息，如果是，由哪个参与者触发； 当系统改变状态时，是否通知参与者； 是否存在影响系统的外部事件； 哪个参与者通知系统这些事件。 （3）用例之间的关系 关系是指用例图中参与者与用例，用例与用例之间的联系。 除用例与其参与者发生关联外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。 应用这些关系的目的是为了从系统中抽取出公共行为及其变体。 包含是指基本用例会用到包含用例(inclusion)，具体地讲，就是将包含用例的事件流插入到基础用例的事件流中。 包含用例是可重用的用例──多个用例的公共用例。 包含关系： 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。 扩展用例的行为是否被执行要取决于主事件流中的判定点。 扩展关系： 泛化：同一业务目的的不同技术实现。 当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其