OO系统分析员之路--用例分析系列(2)--用例的类型与粒度

在正式讨论如何获取用例之前,笔者觉得有两个问题还是先解释清楚为好,这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑,也是最难掌握的。一个是各种用例类型之间的区别和用法,另一个是用例的粒度。 

先说说用例类型的问题。 

用例类型,有的资料翻译为版型,英文原文是stereotype。在Rose中默认的类型有business usecase , business usecase realization和use case realization三种。相应的,就是指

业务用例:

业务用例实现:

用例实现:

若不指定类型,则它就是通常意义上的use case :

时间: 2024-10-03 18:06:04

OO系统分析员之路--用例分析系列(2)--用例的类型与粒度的相关文章

OO系统分析员之路--用例分析系列(8)--如何编写一份完整的UML需求规格说明书

终于到了快结束的时候了,这将是用例分析系列的最后一篇,结果是得到需求规格说明书,以结束需求分析的过程.经过前面七篇的工作,我们从最初的业务用例获取入手,获得了业务用例模型,这是我们的业务范围:经过分析得到了业务场景,这是我们的业务蓝图:经过规划,得出用例实现视图,这是我们的系统范围:经过再次分析,得到了用例实现以及领域模型,包括用例规约,业务规则和业务数据,这是我们的概念模型.仅从需求所需的必要元素来说,我们基本上已经完成了需求分析的工作.诚如上一篇结尾所说,为了让我们的需求更完美,这一篇所要做

OO系统分析员之路--用例分析系列(2)--什么是用例

我发现,在OO和UML几乎一统天下的今天,仍有很多系统分析员对OO和UML一知半解,甚至包括很多已经使用了很久UML的系统分析员. 于是打算写一个系列文章,将多年来的工作经验做一个总结.对初学者起个启蒙作用,也希望抛砖引喻,与各路大虾共同探讨,共同提高. 这个系列文章将以我对OO和系统分析的理解为主,从UML基础开始,阐述面向对象的需求分析方法,过程,并以RUP为例,阐述如何将OO过程与软件过程有机结合在一起,做一个真正OO应用. 好了,今天是第一篇.想得很远,不知能否坚持下去,呵呵:lol:

OO系统分析员之路--用例分析系列(4)--业务建模一般步骤和方法

本篇开始之前先扯点闲话,商业应用系统开发经历了三个阶段: 第一个阶段以计算为中心,分析设计围绕程序的运行效率,算法优劣,存贮优化来进行.90年代的大学课程讲的都是这些. 第二阶段以数据为中心,分析设计围绕数据流进行,以数据流程来模拟业务流程.这也就是所谓的面向过程的分析模式. 第三阶段以人为中心,分析设计围绕人的业务需求,使用要求,感受要求进行.这也就是现在的面象对象分析模式. 使用OO方法建立商业模型必须先定义涉众.商业系统无论多复杂,无论什么行业,其本质无非是人,事,物,规则.人是一切的中心

OO系统分析员之路--用例分析系列(5)--用户、业务用例和业务场景

很久没有动笔了,这期间承蒙许多朋友的喜欢和鼓励,再不写点东西就对不住这些朋友了. 写点什么呢?按照原先的设想,应该开始动手写如何从业务用例转化到概念用例和系统用例,不过老实说这一步需要的是经验居多,而很难找出一个普适的步骤来.先暂时放一放吧,以后一定会写到的.上一篇讲到用例分析的一般步骤和方法,也给出了一个实例,不过没有做更进一步的说明,所以这一篇,笔者决定先罗嗦罗嗦之前的内容,说说业务建模中各种图的用法,以及它们对需求的贡献. 在说明实例之前,再重复一下的需求,并提醒读者下载实例,本文下面只会

OO系统分析员之路--用例分析系列(7)--用例规约的编写--业务规则和实体描述

先说说业务规则.笔者习惯将业务规则分为三种. 一种是全局规则,这种规则一般与所有用例都相关而不是与特定用例相关,例如actor要操作用例必须获得相应的授权,用例的操作与授权级别相关,或者用户在系统中的所有操作都要被记录下来等等.这类规则笔者习惯于,并且也建议将它们写到用例的补充规约里面去,因为它们一般与具体的业务功能性要求没有直接关系.有时候,这类规则也被写到软件架构文档中.关于用例补充规约以后再讨论. 第二种是交互规则.这种规则产生于用例场景当中,例如当提交一份定单时,哪些数据是必须填写的,用

OO系统分析员之路--用例分析系列(6)--用例实现、用例场景和领域模型

上一篇说到我们经过初步的业务分析,得到了用户.业务用例以及业务场景模型.这三项工作成果形成了基本的需求框架,并圈定了业务范围.这时应当做一份基线. 当然,第一份基线所包括的内容是非常粗的,要达到完整的需求说明还有更多工作要做.这一篇就来说说详细的需求过程和产出物,以及这些成果对需求的贡献.在开始之前,还是提醒读者下载实例,本文下面只会从实例中挑选很少一部分来说明,对照实例读者将能更好的理解. 上一篇确定了业务用例,以及业务场景.该场景只描述了业务框架,接下来要对业务用例进行场景分析.用例场景分析

OO系统分析员之路--用例分析系列(3)--业务建模之涉众

从这一篇开始,笔者将借助一个虚拟的实例来阐述获取用例的方法,以及如何判断用例获取是否完备,粒度选择是否合适.事实上,在做这些工作时,我们正在进行需求分析的第一个阶段,即业务建模阶段.借助这个例子,笔者同样会阐述业务建模到底应该做什么,做到什么地步才能说明业务需求已经完整,可以称为一份完整的需求规格说明书了. 一般来说,只有当以下工作都完成,才能说业务模型建立完成,它们是: 发现和定义涉众 画定业务边界 获取用例 绘制用例场景图 绘制业务实体模型(领域模型) 编制词汇表 下面笔者开始就一个事例来说

dubbo源码分析系列(1)扩展机制的实现

1 系列目录 dubbo源码分析系列(1)扩展机制的实现 dubbo源码分析系列(2)服务的发布 dubbo源码分析系列(3)服务的引用 dubbo源码分析系列(4)dubbo通信设计 2 SPI扩展机制 站在一个框架作者的角度来说,定义一个接口,自己默认给出几个接口的实现类,同时允许框架的使用者也能够自定义接口的实现.现在一个简单的问题就是:如何优雅的根据一个接口来获取该接口的所有实现类呢? 这就需要引出java的SPI机制了 2.1 SPI介绍与demo 这些内容就不再多说了,网上搜一下,一

dubbo源码分析系列(3)服务的引用

1 系列目录 dubbo源码分析系列(1)扩展机制的实现 dubbo源码分析系列(2)服务的发布 dubbo源码分析系列(3)服务的引用 dubbo源码分析系列(4)dubbo通信设计 2 服务引用案例介绍 先看一个简单的客户端引用服务的例子,dubbo配置如下: <dubbo:application name="consumer-of-helloService" /> <dubbo:registry protocol="zookeeper" ad