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

Ivar Jacobson 专栏收录该内容
12 篇文章 1 订阅
1)2014年2月11日完成相关需求说明书的确认工作。

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

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

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

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

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


[img]http://dl2.iteye.com/upload/attachment/0093/5907/6f509f5a-351b-3f14-918a-28fc62de9383.jpg[/img]


[img]http://dl2.iteye.com/upload/attachment/0093/5909/e9d7419b-4905-3760-a916-7d2a13f8de2c.jpg[/img]


[img]http://dl2.iteye.com/upload/attachment/0093/5911/e87814e0-f93d-3ef5-8257-a16ff284cfbc.jpg[/img]


[img]http://dl2.iteye.com/upload/attachment/0093/5913/3f850135-939a-37a8-994d-bc35d2998207.jpg[/img]
  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值