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

 




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

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

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

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

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

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