[面向对象的软件工作-----笔记.docVIP

概念： 主题信息专家：SME 用况：（case） 描述了真实世界中参与者与系统相互交互的的方式。 我的理解是用况其实是为完成某件事情，所要经历的步骤。 用况是从执行者的观点描述系统行为 用况分为本质用况与系统用况。 本质用况： 用于以独立于技术的方式捕获用户的意图。用于反映需求 系统用况： 细化的用况，用于描述系统如何实现对应的本质用况的需求。用于反映分析 用况图： 显示用况、参与者及之间关系的UML图 执行者：（actor） 是与系统交互的外部实体。包括一个用户角色（如系统管理员、顾客等）或其他系统（如一个中心数据库、一个装配件等。） 功能性需求： 描述环境与系统之间的交互而不考虑系统实现。环境包括用户及任何与系统交互的外部系统。 非功能性需求： 指与系统功能行为没有直接关系但用户可见的系统部分。 伪需求： 是客户强加的需求，约束了系统的实现。  一、需求分析 （一）需求概述 1、需求包括功能性需求、非功能性需求和伪需求。 功能性需求： 描述环境与系统之间的交互而不考虑系统实现。环境包括用户及任何与系统交互的外部系统。 非功能性需求： 指与系统功能行为没有直接关系但用户可见的系统部分。 伪需求： 是客户强加的需求，约束了系统的实现。 2、需求描述的要求 正确性： 模型中的每个东西都准确地描述了系统的一个方面。 完整性： 系统的所有方面都被需求模型描述（包括例外行为）。 一致性： 模型中的描述不自相矛盾，模型中的所有概念与同一事实的现象对应。 清晰性： 模型中所有概念都只对应一个现象。 现实性： 模型描述了可以存在的事实，即系统能在约束条件下实现。 （二）收集需求 目的：需求的提出与分析主要集中于描述系统目的，集中于使用者对系统的观点上。 步骤： 1、与用户交流，获得用自然语言书写的系统规格说明。 2、通过系统规格说明，标识业务事件并制作事件表。 3、为每个业务事件编写基本用例及叙述。 4、为每个与外部事件相关的用例场景绘制系统时序图。 5、进行领域建模，生成域模型，以表示系统问题域中的概念、属性和关联。 6、为每项系统操作编写约定。 结果：对需求的提出和分析产生如下系统模型： 系统规格说明：是用自然语言写的，支持与客户和用户进行交流。 业务事件分析表：每个系统一个，说明业务事件的输入、输出、及事件的内容及输入输出的参与者。 分析模型：用一种形式化或半形式化的符号表达，支持开发人员之间的交流。主要有 本质用况图（用例图）及叙述 系统时序图（每个用例至少一个） 本质用户界面原型 本质用户界面流程图 域模型 系统操作约定 业务事件分析 事件定义： 外部：由系统边界外的参与者激发的事件。 内部：发生在系统边界内的事件，主要由系统在条件满足时自动触发。 定时：发生在预先指定的时间的事件。 事件分析： 此处的业务事件指系统级的事件。 例如： “客户向银行账号中存款”是一个系统级的事件，而“选择存款选项”是一个低级、小规范事件，是系统级事件的一个组成事件。 事件分析是通过合成（或综合）而非分解来实现的。 需要确定和理解系统必须响应的环境中的每一个情况。 建立基本事件模型，而忽略具体实现技术。例如：“客户向银行账号中存款”，其具体实现既可以在柜台，也可在ATM机上自助存款。但基本系统就是：客户以某种形式提供确定数量的资金，并将其存入一个有效的帐号中。 是对系统的完整响应建模。响应必须包含系统根据当时所拥有的信息而所能做的所有事情。如果不能对事件的系统完整响应建模，那么也可以将事实上的单个事件分割为两个或多个片段。例如：在事件“学生注册班级”中，直到系统生成学生班级列表，整个响应才算完成。当学生被所有他请求的开放小组录取后，系统就拥有了为其生成学生班级列表的所有信息，所以生成学生班级列表不是单独的事件。 隔离各个单独事件。同第5相反，当事件没有足够的信息来生成输出时，此事件应被隔离为单独事件。例如：“顾客付账”是独立于“顾客点餐”的事件，因为账单是完成“顾客点餐”事件后的输出，但当时顾客并不知道账单总额。“到生成大学班级计划的时间了”是独立事件。因为系统要等到所有的“系提交班级计划”事件发生后才有足够的信息去生成大学班级计划。 事件描述： 事件分析需要描述如下信息： 系统需要响应的所有事件。 与每个事件相关联的输入消息（事件流或数据流） 所需的响应。 对每个刺激进行响应所需的动作或行为。 事件流：包含与应用无关数据的信息流。它的目的是通知系统特定事件的发生并触发系统响应。 数据流：包含与应用程序相关的具有描述事件细节特定值的数据元素。它的目的是触发系统响应，并提供系统产生所需响应所必需的数据。 定时事件的描述：“到。。。。的时间”或“现在该。。。。” 确定事件的参与者：参与者是可以生成系统输入或接收系统输出的人、组织或其