基于OOSE方法的第三个项目实践

阅读更多
 




1)2014年2月11日完成相关需求说明书的确认工作。

最近完成了基于OOSE方法的第三个项目实践,对用例建模又有了更加深入的体会.

1)基于对象建模的方法来进行用例建模:通常在用例建模的时候,要保持合适的尺度,不能太多,也不要太小,如何保持这种尺度,通常没有一个固定的方法,这也是大家普遍不愿意应用这种方法的原因。OOSE的观点认为, 用例本身是一种特殊的对象,他主要表现为一种异步的操作模式,所以可以利用对象建模的方法来进行用例建模,但这要突破一种思维的限制,因为大家通常是习惯对信息结构进行对象建模,而不习惯对动作序列进行建模。 一旦掌握这种方法,这样可以有效的控制用例的数量,又能够准确的对需求切片。

2)基于领域对象对用例进行优化。 通过本次分析,我发现在用例优的时候,可以结合领域对象进行优化,合并部分用例,并识别部分隐含的用例。 因而,用户通常对领域对象的识别比较模糊,他们通常只会描述常用的功能需求,而忽视一些使用频率低的功能需求,识别领域对象以后,可以和客户沟通对领域对象的使用模式,这样往往可以发现一些隐含的需求。 同时在合并用例的时候,可以围绕领域对象模型进行用例的聚合,将一些操作进行合并。这样优化的用例和用户的需求场景比较贴近, 对UI的设计也能够有很好的指导。

3)识别抽象用例:对于一些用例的共性部分,可以提炼部分共性部分,形成抽象用例, 在此基础上,可以方便分离接口,或者选择中间件。 比如规则引擎,其实就是将很多用例中的规则处理部分,分离出来,进行组件复用处理。

     道德经上说:"九层之台,始于垒土,合抱之木,生于毫末“。 软件开发的过程,是一个不断模型转化的过程,而用例模型是这个转化的起点,只有结合对象建模的方法,对用例进行反复的迭代,和优化,才能有效的进行后续的设计,形成一个用户满意的实现模型。 最后实现很多双赢。项目实施都有很多波折,可能就是因为太忽视用例的设计,希望WLAN项目是一个契机,形成一种新的良性循环吧。


基于OOSE方法的第三个项目实践_第1张图片


基于OOSE方法的第三个项目实践_第2张图片


基于OOSE方法的第三个项目实践_第3张图片


基于OOSE方法的第三个项目实践_第4张图片

  • BSseach0127.rar (2.6 MB)
  • 下载次数: 1
  • 基于OOSE方法的第三个项目实践_第5张图片
  • 大小: 12.1 KB
  • 基于OOSE方法的第三个项目实践_第6张图片
  • 大小: 29.2 KB
  • 基于OOSE方法的第三个项目实践_第7张图片
  • 大小: 36.8 KB
  • 基于OOSE方法的第三个项目实践_第8张图片
  • 大小: 21.1 KB
  • 附件一:2014年重点创新项目计划清单.rar (28.5 KB)
  • 下载次数: 0
  • 需求说明书确认.rar (1.6 MB)
  • 下载次数: 1
  • 查看图片附件

你可能感兴趣的:(OOSE,用例模型,模型转换)