人人都是领域专家-类图

/**

*  转载请注明作者longdick    http://longdick.iteye.com

*

*/

相关帖子：

1、人人都是领域专家-用例图

2、人人都是领域专家-活动图

3、人人都是领域专家-类图

4、人人都是领域专家-顺序图

5、人人都是领域专家-类图关系化

6、人人都是领域专家-类图关系说明

 

经过了领域专家的辛勤劳作，我们终于得到了精准的需求文档、形象的用例图和每个用例的活动图。

接下来轮到架构师出场，开始轰轰烈烈的分析阶段。

分析阶段最主要的产出是类图和顺序图。

 

为了简化问题，我们使用最后一次迭代的产出用例图（没有将用例进一步精化）。

 

如果使用敏捷迭代开发，一开始分析阶段倾向于选择风险最大的用例优先开发，这个风险的评估在架构人员拿到用例文档以后就可以开始了。在这个例子里，我们倾向于选择“购买商品”为风险最大用例，“登录”用例次之。so，接下来的分析阶段，我们只关注“登录”和“购买商品”这两个用例。

 

接下来分析这个用例图所有的参与者和用例，将实体识别出来添加到类图中。这往往是画类图的第一步，也是较简单的部分。既然UML主要用于面向对象语言建模，领域中的实体就是对应着语言里的对象。

 

我们分析过程如下：

• 参与者是很明显的实体，因此会员，vip会员都是实体；
• 购买商品用例明显涉及到商品实体；
• 要购买商品肯定会生成一个订单实体；
• 支付时还要涉及到账户实体；

先想到这么多，深入分析的话会发现用例中其实还有其他实体，但是，按照敏捷的思想，我们在第一个迭代中不用求全责备。况且，这个教程是用来说明方法过程，力求简单，并没有强求模型的完整性。

 

 

UML类图的最佳实践里包含三种久经考验的类类型：

• 实体类（entity）
• 控制类（control）
  
• 边界类（boundary）

 

当然这只是模型意义上的类型，和语言的类没有关系。

实体类我们已经了解了，边界类是用户和控制类的媒介也就是用户接口，控制类是边界类和实体类的媒介。

OK，其实就是分层的概念了好吧。你可以理解成MVC差不多。

 

一个用例就可以抽取成为一个控制类，命名的方式可以是用例名+后缀。比如登录用例名是Login，我们可以用LoginWorkflow来描述登录控制类。后缀名可以任意取，比如Workflow，Controller，Service等等都可以，但至少在一个模型中要一致。

 

边界类也是如此，比如商品购买用例，我们采用用例名PurchaseStuffs+后缀的方式，后缀可以选择采用UI、View等等。

我们暂时只对登录和商品购买这两个用例进行建模。得到的类图如下。

 

类中的方法和属性可以在以后迭代中逐步补完。在这里先列出一些比较有可能用到的方法，属性可以慢慢来。

 

类图的改进和细化

 

到现在我们在类图上罗列了一堆游离的类，我们可以在已知的条件下改进这个类图比如说Member类和VIPMember类可以抽离出一个共有的接口或有默认实现的父类等等。这个类图的改进还包括描述清楚类之间的关系。先别急着加，我们可以等画顺序图的时候再来考虑类间的关系。