|
知识路径: > 系统开发基础知识 > 设计方法 > 面向对象的分析与设计 > 面向对象方法 > 面向对象分析 >
|
相关知识点:1个
|
|
|
|
OOA的基本任务是运用面向对象方法,对问题域和系统责任进行分析和理解,正确认识其中的事物及它们之间的关系,找出描述问题域及系统责任所需的类和对象,定义它们的属性和服务,以及它们之间所形成的结构、静态联系和动态联系。最终产生一个符合用户需求,并能直接反映问题域和系统责任的OOA模型及其详细说明。
|
|
|
用例分析方法的创始人Ivar Jacobson给用例的定义是:“用例实例是在系统中执行的一系列动作,这些动作将生成特定参与者可见的价值结果。一个用例则定义一组用例实例。”从这个定义中,我们可以得知用例是由一组用例实例组成的,用例实例也就是常说的“使用场景”,就是用户使用系统的一个实际的、特定的场景;其次,可以知道,用例应该给参与者带来可见的价值,这点很关键;最后还可以得知,用例是在系统中的。
|
|
|
用例分析技术为软件需求规格化提供了一个基本的元素,而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。而且用例还可以使开发团队与客户之间的交流更加顺畅。构建用例模型需要经历识别参与者、合并需求获得用例、细化用例描述三个阶段。
|
|
|
(1)识别参与者。参与者(actor)是系统之外与系统进行交互的任何事物,参与者可以是使用系统的用户,也可以是其他外部系统、外部设备等外部实体。在UML中采用小人符号来表示参与者。参与者有主要参与者和次要参与者之分,开发用例的重点是要找到主要参与者。
|
|
|
(2)合并需求获得用例。将参与者都找到之后,接下来就是仔细地检查参与者,为每一个参与者确定用例。而其中的依据主要可以来源于已经获取得到的特征表。首先,将特征分配给相应的参与者,然后进行合并操作,最后绘制成用例图。在确定用例的过程中,不能混淆用例和用例所包含的步骤,要注意区分业务用例和系统用例。
|
|
|
(3)细化用例描述。用例建模的主要工作是书写用例规约(use case specification),而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果,其内容至少包括用例名、参与者、目标、前置条件、事件流(基本事件流、扩展事件流)、后置条件等,其他的还可以包括非功能需求、用例优先级等。
|
|
|
:一个较为复杂的系统会有较多的用例,为便于理解,可以为它们建立多张用例图。更为复杂的情况将导致所有用例难以维持一种平面结构,这时可以对用例进行分组。UML使用用例主题划分用例图,一组用例放置在以主题命名的方框中(类似于系统边界),每个主题中可以包含多个用例图。
|
|
|