需求的OO描述方法.ppt

* * * * * * * * * * * ⑴标识输入消息 在例图中，有三个地方的工作流穿过订单职员和系统之间的边界线。 在每一个工作流穿过自动化边界的地方，都须输入数据，因此同样需要消息。 * */117 ?? ⑵描述从外部参与者到系统的消息 消息名：要反映参与者向系统请求的服务。 参数列表：开发人员要确定数据参数通常需要数次的迭代，才能找到一个正确而又完整的列表。 确定数据参数的规则：根据类图来确定数据参数(类中一些恰当的属性可以用做参数列表)。 * */117 ? “产生新建订单”用例电话订购场景的SSD startOrder：本用例的前提条件是用户应存在。后续条件是订单必须与一个客户相关联。 addItem：需要参数来标识目录中的条目，以及要购买的数量。 completeOrder：基于活动图，须输入支付数量。 * */117 ??? ⑶在输入消息上确定并添加特定条件 本例中，有迭代框和与之相关的真/假条件(在方括号中)。 * */117 ? ⑷确定并添加输出返回消息 显示返回消息的两种选择： ①在消息上添加返回值 ②用虚线箭头表示一个独立的返回消息。 活动图可提供关于返回消息的线索，但并没有一个标准的规则，当工作流中的转换箭头从系统出发到达外部参与者的时候，不一定总会产生一个输出。 * */117 ?? 系统分析的目标是理解和发现，所以应该与用户一起工作，以便准确定义工作流是如何运作的，以及什么样的信息需要作为输出被传递和提供。 这是一个迭代过程，在这些图反映用户需要之前，需要多次地修改。 * */117 ? 3. RMO例 产生新订单用例的Web订购场景的简化系统顺序图。 * */117 ? Web订购场景活动图 SSD ? 5 问题域建模——域模型类图 由于事物存在于真实的对象中，而对象是OO方法的基础，所以类图常被认为是所有UML模型中最重要的一个。 事实上，类图是OO开发中的一个焦点。 每个其他的UML模型必须与类图一致。 域模型类图只是一个开始。 * */117 ?? 定义系统需求时开发人员只关注用户问题域类，定义这些系统需求而建立的类图称为域模型类图或简称为域模型，因为它显示的类是用户问题域中的一部分。域模型类图并不显示方法，相反它主要关注的是用户真实世界的对象。 * */117 ? 域模型类图或者域模型 描述类的基本结构和概念上的数据模型。 使用域模型类图的目的： 它描述必须由OO的编程方法运行的类的基本结构。 它被当做一种概念上的数据模型——描述用于DB定义的类。 * */117 ? ?? 学生 域模型类图的例子 该图的扩展，显示从学生到本科生和研究生的概括/具体类。如，在本科生中的每个对象同时也是学生。 具体类继承了概括类的所有属性和关联。 ? 建立域模型时，标识主键字段很重要。 在UML中，属性的特征是用大括号括起来的，就像课程类中的课程号{主键}。 课程部分数量用下划线指明它是类级属性。 通常，每个对象的属性都有惟一值,而类级属性有一个应用于类的所有对象的数值。 在Java中，它作为一个静态属性被执行；在VB.NET中，它是一个共享属性。 系统需要存储一个用于表示所提供课程的部分数量的值。每次多选取一个课程部分，该数值加1。 * */117 ? 关联关系 连线指明类之间的相互关系。 连线的名字随意。 本例中，相互关系有一个多对多的重数(基数)。 只要多对多的关联存在，则关联类就可能存在。 * */117 ? 满足三个条件关联类存在 ①关联关系必须有多对多的重数。 ②关联关系必须有一个仅应用于本关联(而不是任何有联系的类)的属性(年级)。 ③由于关联类中的每个对象代表了相互联系的类中两个对象之间的一个独立的关联连接，因此关联类对象的键值通常是相互联系类的键值的组合。 如果在键值中需要其他的属性，那么关联类就有可能被定义错误。 * */117 ? RMO域模型类图 * */117 ?? 6 OO模型的集成 完整的用例图对理解新系统的总体规模很重要。但包含在用例描述、活动图和系统顺序图中的支持细节只需为特定迭代中的用例完成。 域模型类图比较特殊，它更像完整的用例图。 系统的问题域类的数量为系统总体规模提供一个提示。类的精炼和实际执行将等到以后的迭代中进行，但域模型应该基本完成。 域模型对于确定新系统所需要的所有域类是必要的。 * */117 ? 至此应该明白 一个图的构造如何参照另一幅图所提供的信息来完成。 新图表的开发通常有助于精简和纠正先前的图。 详细图的开发对于充分理解用户需求是至关重要的。 * */117 ? OO需求模型中的关系 说明OO开发中需求模型间的主要关系。 依赖性通常从顶部流到底部，双向箭头表示在两个方向都产生影响。 * */117