_面向对象的需求获取sr.pptVIP

软件工程 taohuating@126.com 第11章 面向对象的需求获取 11.1 用例图 11.2 活动图 11.3 状态图 11.4 获取需求活动 11.5 实例 11.1 用例图 项目初期，通常先以最终用户为调查对象，了解系统应具备哪些功能、提供哪些服务。面向对象的做法，是将用户提出的需求定义为若干个“用例（Use Case）”。每一个用例都是从系统外部看到的一个相对完整、直观的功能或完整的事务。用例、角色以及角色与用例之间的连线构成了用例图。 用例图是分析师与用户交流的基础，用户从用例图了解谁要访问系统，系统提供给每个角色的功能是什么，这有助于分析系统的边界，检查需求的完整性。在UML中，用例图包括用例、角色和关系三要素，主要表述系统与外部环境的交互情况。用例图又称Use Case图，如图11.1所示。 为了便于理解和叙述，本书后面章节中统一约定“Use Case”即“用例”，“Actor”即“角色”，“Use Case图”即“用例图”，“Use Case报告”即“用例报告”，在没有特别声明的地方，这几组术语可以互换。 Use Case报告是详细描述Use Case事件流的文档。Use Case图和Use Case报告是需求模型的主要内容，必要时会用到活动图和状态图。 11.1.1 用例 用例描述的是系统的外部特性，即从外部看，系统具备的功能或提供的服务，它揭示了用户使用系统的情形。如图11.1所示，ATM系统提供了一些基本功能，使客户可以取钱、修改密码、查询余额和转账等，这里的每个功能都可看作是一个用例。 为了便于理解、便于控制复杂性和编程实现，结构化方法是把系统逐步分解成功能模块，把系统构建成易于实现和维护模块化结构。 出于同样的目的，面向对象的方法则采用了另外一种思维模式。面向对象方法的核心概念是对象，关心的是对象间的“交互”，即用户要系统完成什么，系统要返回给用户什么信息。每个用例都是角色与系统间的一个完整的交互事务，从用户的角度看，用例是一个相对直观、完整的功能。 用例的划分与模块的划分类似，同样追求“高内聚、低耦合”原则，这样便于以用例为单位进行任务分割、实现迭代式开发和项目进度控制。 11.1.2 角色 角色是与系统交互的人、事物或其他系统。图11.1中，客户、信用系统、储蓄系统等都是与ATM系统交互的角色。连接角色与用例的线段表示角色与用例之间存在交互。 角色有主动与被动之分。在图11.1中，左侧为主动角色，右侧为被动角色。主动角色与用例之间的连线带有箭头，表示主动角色可以触发用例。被动角色与用例间的连线不带箭头。在交互过程中，被动角色被动地响应用例的请求，通过交互实现用例的功能，满足主动角色的功能请求。需要明确的是，角色与用例之间的连线无论有没有箭头，其交互都是双向的，箭头仅表示主动角色触发用例的语义。 角色有三类：用户、外部系统和时间。用户是最重要的角色，如ATM系统中的客户、维护人员都属于用户类型的角色。当外部系统与拟建系统有交互时，外部系统也被看作是该系统的角色，如ATM系统与银行信息系统有交互，用于维护每位客户的信用信息。另外，因为在特定的时间，时钟会触发系统中的某个事件，所以时间是系统的一种特殊角色，如ATM系统可能在每天夜里运行一些功能，进行跨行账务清算。由于时间不在控制之内，因此也将它视为一种角色。 11.1.3 关系 在Use Case图中，Actor与Use case之间的连线表示Actor与Use case之间的关系。一般有通信、使用、扩展和泛化四种关系。“通信”表示了Actor与Use case之间有信息交互的语义，“使用”表示了Actor使用Use case的语义。用例之间的关系包括“使用”和“扩展”两种，“泛化”关系本质上与类之间的泛化关系相同。 （1）通信关系 （2）使用关系 （3）扩展关系 （4）依赖关系 11.2 活动图 活动图既可以描述工作流，也可以描述用例的事件流。活动图中的主要图形元素包括： 泳道（Swimlane），活动图中的分隔线，说明谁负责执行该泳道中的任务。 开始状态(Start State)，工作流的开始点。 活动(Activity)，工作流可能由多个活动组成，每个活动都是工作流的一个步骤。 动作(Action)，每个动作执行一定的操作，一个活动可以有多个动作。动作可能发生在进入活动时、退出活动时、活动内或特定的事件发生时。如图11.3是一个退货验收活动，entry是进入该活动时的动作；do是活动中发生的动作；exit是离开该活动时的动作。另外，如表示当某个事件发生时的动作，应标有On event字样。 开始状态、活动、决策点及结束点的表示符号，如图11.4所示。 为了说明活动图的使用方法和意义，图11-5