/**
* 转载请注明作者longdick http://longdick.iteye.com
*
*/
相关帖子:
经过了领域专家的辛勤劳作,我们终于得到了精准的需求文档、形象的用例图和每个用例的活动图。
接下来轮到架构师出场,开始轰轰烈烈的分析阶段。
分析阶段最主要的产出是类图和顺序图。
为了简化问题,我们使用最后一次迭代的产出用例图(没有将用例进一步精化)。
如果使用敏捷迭代开发,一开始分析阶段倾向于选择风险最大的用例优先开发,这个风险的评估在架构人员拿到用例文档以后就可以开始了。在这个例子里,我们倾向于选择“购买商品”为风险最大用例,“登录”用例次之。so,接下来的分析阶段,我们只关注“登录”和“购买商品”这两个用例。
接下来分析这个用例图所有的参与者和用例,将实体识别出来添加到类图中。这往往是画类图的第一步,也是较简单的部分。既然UML主要用于面向对象语言建模,领域中的实体就是对应着语言里的对象。
我们分析过程如下:
- 参与者是很明显的实体,因此会员,vip会员都是实体;
- 购买商品用例明显涉及到商品实体;
- 要购买商品肯定会生成一个订单实体;
- 支付时还要涉及到账户实体;
先想到这么多,深入分析的话会发现用例中其实还有其他实体,但是,按照敏捷的思想,我们在第一个迭代中不用求全责备。况且,这个教程是用来说明方法过程,力求简单,并没有强求模型的完整性。
UML类图的最佳实践里包含三种久经考验的类类型:
- 实体类(entity)
- 控制类(control)
- 边界类(boundary)
当然这只是模型意义上的类型,和语言的类没有关系。
实体类我们已经了解了,边界类是用户和控制类的媒介也就是用户接口,控制类是边界类和实体类的媒介。
OK,其实就是分层的概念了好吧。你可以理解成MVC差不多。
一个用例就可以抽取成为一个控制类,命名的方式可以是用例名+后缀。比如登录用例名是Login,我们可以用LoginWorkflow来描述登录控制类。后缀名可以任意取,比如Workflow,Controller,Service等等都可以,但至少在一个模型中要一致。
边界类也是如此,比如商品购买用例,我们采用用例名PurchaseStuffs+后缀的方式,后缀可以选择采用UI、View等等。
我们暂时只对登录和商品购买这两个用例进行建模。得到的类图如下。
类中的方法和属性可以在以后迭代中逐步补完。在这里先列出一些比较有可能用到的方法,属性可以慢慢来。
类图的改进和细化
到现在我们在类图上罗列了一堆游离的类,我们可以在已知的条件下改进这个类图比如说Member类和VIPMember类可以抽离出一个共有的接口或有默认实现的父类等等。这个类图的改进还包括描述清楚类之间的关系。先别急着加,我们可以等画顺序图的时候再来考虑类间的关系。