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