软件开发需求之需求建模解析.ppt

类图 语言级别 —————— 类图 class Animal{ String name; String sex; int age; void move(){ } void roar(){ } } 对象图 对象图 对象图和类图很相似，它们能在类被实例化的时候提供系统在某一时刻的视图。 对象图是有利于表示一个系统怎样运作的具体实例。 obj1：Animal name = tiger sex=male age = 9 move( ) 关系 关系： 依赖，依赖是一种“使用”关系， 泛化，继承关系，意味着子类可以替换父类。 关联，最普遍的联系，连接两个类的一条实线 聚合，表示部分对象与整体对象之间的关系。 依赖于 visio与UML 用例描述 光有用例图是不够的，还需要用例描述，可以是一份文档,包含 简要说明。简要介绍该用例的作用和目的。 事件流。包括基本流和备选流，事件流应该表示出所有的场景。 用例场景。包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。 用例描述 特殊需求。描述与该用例相关的非功能性需求和设计约束（所使用的操作系统、开发工具等）。 前置条件。执行用例之前系统必须所处的状态。 后置条件。用例执行完毕后系统可能处于的一组状态。 常见的用例建模的错误 编写功能性需求，而不是编写使用场景文本。 描述属性和方法而不是使用情况。 编写得用例过于简洁。 让自己和用户界面完全脱离。 不给边界对象提供明确的名称。 不从用户的角度编写用例，使用被动语态。 只描述用户的交互，而忽略系统做出的响应。 常见的用例建模的错误 不描述操作的分支流程。 不将重点放在用例的内部，而是放在如何到达这里或以后将要发生的情况。 花了大量的时间来决定使用包含结构还是扩展结构。 用例建模的好处 书写简单、容易理解。 从用户的角度考虑问题。 用例使用户参与需求过程，帮助他们理解开发者提出的解决方案，提供了一种交流方式。 用户能据此给出系统需求的场景，使人们理解需求的原因以及系统如何实现它的目标。 用例为需求提供一种排序机制，人们可以说出在下一个事件发生之前必须发生什么。 用例建模的好处 大多数情况下用例是由开发人员编写的，这意味着需求被真正理解。 用例在分析过程中是一个关键工具，帮助我们理解系统需要做什么，以及系统可能如何去做。 用例在设计和实现过程中也是一个关键工具，它降低了把需求从表达向实现转化时产生不一致的风险。 用例可以直接延续到测试过程，它有助于确保系统真正做了它应该做的事情。 用例也是用户文档的输入，可以很方便地组织起来。 实验中的问题 1、不理解用例图和活动图的区别和意义 用例图用来表示系统的需求，属于静态图。即能看出客户对系统有何需求，但看不出过程。（追求完整性） 活动图是从行为角度对每个用例的细化，描述每个用例的执行过程。（追求细节） 实验中的问题 1、不理解用例图和活动图的区别和意义 典型错误： 将“用例图”同“活动图”混合在一张图中。 将“用例”同“动作”混淆。 实验中的问题 2、不理解参与者与用例的关系 参与者是用来启动用例的，没有用例是孤立的。 时间也是一种用例。 参与者与用例之间应该是关联（无向直线），一般是无方向的。 实验中的问题 2、不理解用例与用例的关系 用例与用例之间的关系一般有两种，一种是扩展（ extend），另一种是包含（include，旧称use）。 在用例描述中需要对事件路径进行描述，而包含用例和扩展用例都是对基本事件路径的补充。 可以不要过早考虑用例间的关系，先找后分析。 实验中的问题 2、不理解用例与用例的关系 扩展表示一个用例是另一个用例的子类关系，如管理课程和新建课程的关系。注意，管理课程可以包括新建课程也可以不包括新建课程，新建课程用例是一种具体的管理课程用例。 实验中的问题 2、不理解用例与用例的关系 包含表示一个用例执行的过程一定包含另一个用例的执行过程。 实验中的问题 3、其他用例典型错误： 将“用例”与“界面元素”混淆。 用例之间有交叉。 用例命名有歧义或不明确。 实验中的问题 2、不理解活动图 活动图一般是一个用例的细化，表示了一个用例执行过程中多个对象的活动。 典型错误 将“用例”与“界面元素”混淆。 用例之间有交叉。 用例命名有歧义或不明确 实验中的问题 时刻不要忘记建模的目的是什么 建模的目的是为了更好的理解系统，不是为了画图！ 不要追求手段而忘了目的！ 不要过早陷入到细节而忽略了模型的完整性！ 2010.8 需求建模 需求建模 建模是为了更好的理解需求 模型分为业务模型、商业模型和系统模型 需求阶段的主要工作是业务建模 业务建模使用的主要工具是用例建模 用例建模涉及到UML中以用例图为主的一部分内容。 业务模型(Operation?