面向对象课程设计UML中 建立需求模型.ppt.ppt

* * （3）用况陈述了参与者和系统在交互过程中双方所做的事，而不是任何单独一方所做的事。 （4）在所有的用况中，由参与者首先发起对话的可能性较大，但有些对话也可能是由系统首先发起的。 例如：参与者向系统发出一条命令要求它做某件事； 系统经过判断，要求参与者提供进一步的信息； 参与者输入信息； 系统进行处理，把结果报告参与者。 这确实是一种“对话”，你一段台词，我一段台词，互相交织，构成一个剧本。 例如，系统在发现某些异常情况时主动要求操作员的干预，系统主动地向设备发出操作指令，本系统主动要求与外系统通信等，就需要一个由系统首先发起对话的用况来进行描述。 * * （5）用况的典型用法是描述参与者和系统彼此为对方直接地做了些什么事，不描述怎么做，也不描述间接地做了些什么。 对参与者只描述它对系统的直接动作（例如“输入某某数据”），不描述为了完成这个动作所进行的一切准备工作（例如为获得输入数据进行的调查、统计和计算）。 同样的道理，对系统则只描述其外部可见的行为，即与参与者的要求直接有关的外层系统功能，不必详细地描述为完成这样的功能而进行的大量内部工作。 * * （6）用况对参与者和系统双方行为的描述应力求准确、清晰。 在不引起误解的前提下允许用比较简练的语言来概括地说明每一方的行为，但这种概括的最大限度是，不要把双方的行为混在一起不分彼此。 就是说，至少要把交互过程中每一个“回合”的角色切换都表现出来。 * * （7）一个用况所描述的功能可以分别由多种参与者使用。 例如“登录”功能既可以由系统管理员使用，也可以由普通用户使用。 另有一种复杂情况是：一项系统功能需要有多个参与者同时参加与系统的交互才能完成。例如：电话交换机系统所提供的“通话”功能，需要呼叫人和接听人两种参与者同时参加与系统的交互才能完成。 前一种“登录”情况表明，一个用况可以由多种参与者分别参与；后一种“通话”情况表明，一个用况可以由多种参与者共同参与。 * * 4.4.2 定义用况的策略 定义用况的基本策略，是把自己当成一个参与者，与设想中的系统进行交互。 考虑：进行这种交互是为了使用系统的什么功能？使用该功能的目的是什么？为达到这一目的，需要向系统输入什么信息？希望由系统进行什么处理并从它得到何种结果？进一步考虑具体的交互过程，并对每一步的具体交互考虑以上问题。 * * 全面地认识和定义每一个用况，要深入问题域进行调查研究，其要点如下： （1）全面地了解和收集用户所要求的各项系统功能，确定系统边界，找出所有的参与者，向用户和领域专家了解与各项功能有关的业务流程； （2）把用户所提出的功能组织成适当的单位，即：一项功能完成一项完整而相对独立的工作，并且是通过参与者与系统的一次交互能够完成的； * * （3）以穷举的方式考虑每一类参与者与系统的交互情况，看看每个参与者要求系统提供什么功能，以及参与者的每一项输入信息将要求系统做出什么反映，进行什么处理，定义相应的用况； （4）检查用户对系统的各项功能需求是否都通过相应的用况做了描述。 * * 4.4.3 如何在Rational Rose中定义用况 有以下方式： 1、详细说明和事件流可以写在user case specification（用例规约）的Documentation中。 2、可以打开Use ? Case ? Specification，在Files列表中使用右键菜单insert一个文件。该文件可以是word等文字处理软件。 3、可以结合RequisitePro（一种最常见的需求和用例管理工具 ）来创建用例规约文档。前提是要将Rose模型与RequisitePro项目相关联 。 ? 用例规约文档包含该用例的文本特征。包括下列用例特征：用例名称、简单说明、基本事件流、备选事件流、前置条件、后置条件和特殊需求。 4、用活动图来替代。 * * 4.5 用况图 对一个系统或者子系统的参与者、用况以及它们之间的关系进行可视化表示的模型图称为用况图(use case diagram)。 用况图以直观的形式展示了系统的用户需求，是系统的需求模型。 构成用况图的模型元素包括参与者、用况以及它们之间的各种关系，其表示法如图4.5所示。 * * 图4.5 用况图 * * 现在对用况图的各种模型元素的表示法做如下说明： ①参与者：用一个人体形状的符号表示，旁边注明参与者的名称。 图中的一个参与者符号表示一类在与系统的交互中呈现共同行为的参与者。 例如，“营业员”参与者表示在一个问题域中以相同的方式使用系统的所有的营业员，或者说任何一个营业员，而不是单独的、特定的一个营业员。 * * ②用况：用一个椭圆表示一个用况，在椭圆内或者它的旁边给出用况的名称。 ③参与者与用况之间的关系：从参与者符号到用况符号之间的连