人人都是领域专家.docx
《人人都是领域专家.docx》由会员分享，可在线阅读，更多相关《人人都是领域专家.docx（21页珍藏版）》请在冰豆网上搜索。
人人都是领域专家
人人都是领域专家
1、人人都是领域专家-用例图
2、人人都是领域专家-活动图
3、人人都是领域专家-类图
4、人人都是领域专家-顺序图
5、人人都是领域专家-类图关系化
6、人人都是领域专家-类图关系说明
一个好的设计能使开发事半功倍，好的设计来源于好的需求。
这就需要需求分析师帮我们开发人员提供精炼，清晰，准确的需求报告。
需分将采集来的需求用UML（UnifiedModelingLanguage）描述出来，我称之为需求建模。
需求阶段建模的过程中涉及到的有用例图（usecasediagram）和活动图（activitydiagram）。
下面就对网上购物的应用进行用例建模，以此举例用例建模的过程。
当然任何事情都不能一蹴而就，用例建模也是一样。
用例建模的过程可能分好几次迭代进行，一开始粒度可能较粗，随着迭代进行而逐渐精化。
所以不需要一开始就妄想考虑的面面俱到。
1、网上购物的需求描述非常简单：
无非就是用户在一个购物网站上购买商品。
用用例图描述如下，有一个参与者和一个用例。
非常简单，目标明确。
2、然后自评一下，觉得购买商品这个用例粒度太粗了，还有细化分解的可能。
于是就将该用例分解。
这个过程需要和客户更好的沟通。
3、用例分解以后，新的用例粒度更细，权责也更明确了。
但是客户反映有些用例是购买商品的必选步骤，有些则不是。
这时如何在用例图上体现这个关系呢？
我们可以利用include和extend概念来描述，include描述的是主用例和次用例之间的包含关系即必选关系，extend描述的是可选关系。
include关系箭头是主用例指向次用例，extend关系箭头是次用例指向主用例。
4、随着迭代的推进，发现有些用例可以有多种实现方式，不同的实现方式可能有不同的活动图和顺序图。
故在用例图上使用泛化关系描述之。
泛化关系使用一个空心的箭头，可以把它想象成继承关系。
5、用例精化的差不多了，还有别的参与者吗？
用户提醒我们说，除了普通会员可以购买商品以外，还有一类Vip会员可以以折扣价购买一些特价商品。
so，用例需要添加新的参与者和新的用例。
6、从上图可以看出，Vip会员就是特殊化的普通会员。
然后，我们也可以对参与者泛化。
但是参与者泛化会带来一些理解上的复杂性。
可以的话，一般不推荐使用。
7、在重新审视需求，和客户充分沟通以后，本着简单，清晰有效，且不引起歧义的宗旨，我们重新修订整个用例，得到结果如下。
当然这可能还没完，可能还有进一步挖掘需求和用例精化的空间。
可以在保证进度前提下继续迭代建模。
在建模的世界里，没有最好，只有更好。
需求阶段用例图完成以后，需要进一步描述用例。
由于每一个用例可能对应几个事件流，单从用例不能获取有效的信息。
这时候就要用到活动图了。
活动图专门用来描述用例的事件流。
我们借用上一节其中一次迭代的用例图做例子，寻找商品用例，泛化成两个子用例，这两个用例不能合并的主要原因就是事件流不同。
我们以“通过搜索引擎寻找商品”用例为例，使用活动图描述其事件流。
活动图的描述可以参考以前完成的用例文档，一般的用例文档的格式如下：
用例名称：
通过搜索引擎寻找商品
描述：
（...）
前置条件：
（...）
部署约束：
（...）
正常事件流：
（...）
可选事件流：
（...）
异常事件流：
（...）
非功能性需求：
（...）
说明（可选）：
（...）
未解决的问题（可选）：
（...）
每一个用例文档都有描述三种事件流：
正常事件流、可选事件流、异常事件流。
除了正常事件流以外，可选和异常都是可选的。
根据用例文档对事件流的描述，我们可以作出活动图。
“通过搜索引擎寻找商品”用例的活动图如下（用例文档省略）：
其他用例也可以使用类似方式作出活动图。
这里就不再赘述。
经过了领域专家的辛勤劳作，我们终于得到了精准的需求文档、形象的用例图和每个用例的活动图。
接下来轮到架构师出场，开始轰轰烈烈的分析阶段。
分析阶段最主要的产出是类图和顺序图。
为了简化问题，我们使用最后一次迭代的产出用例图（没有将用例进一步精化）。
如果使用敏捷迭代开发，一开始分析阶段倾向于选择风险最大的用例优先开发，这个风险的评估在架构人员拿到用例文档以后就可以开始了。
在这个例子里，我们倾向于选择“购买商品”为风险最大用例，“登录”用例次之。
so，接下来的分析阶段，我们只关注“登录”和“购买商品”这两个用例。
接下来分析这个用例图所有的参与者和用例，将实体识别出来添加到类图中。
这往往是画类图的第一步，也是较简单的部分。
既然UML主要用于面向对象语言建模，领域中的实体就是对应着语言里的对象。
我们分析过程如下：
∙参与者是很明显的实体，因此会员，vip会员都是实体；
∙购买商品用例明显涉及到商品实体；
∙要购买商品肯定会生成一个订单实体；
∙支付时还要涉及到账户实体；
先想到这么多，深入分析的话会发现用例中其实还有其他实体，但是，按照敏捷的思想，我们在第一个迭代中不用求全责备。
况且，这个教程是用来说明方法过程，力求简单，并没有强求模型的完整性。
UML类图的最佳实践里包含三种久经考验的类类型：
∙实体类（entity）
∙控制类（control）
∙边界类（boundary）
当然这只是模型意义上的类型，和语言的类没有关系。
实体类我们已经了解了，边界类是用户和控制类的媒介也就是用户接口，控制类是边界类和实体类的媒介。
OK，其实就是分层的概念了好吧。
你可以理解成MVC差不多。
一个用例就可以抽取成为一个控制类，命名的方式可以是用例名+后缀。
比如登录用例名是Login，我们可以用LoginWorkflow来描述登录控制类。
后缀名可以任意取，比如Workflow，Controller，Service等等都可以，但至少在一个模型中要一致。
边界类也是如此，比如商品购买用例，我们采用用例名PurchaseStuffs+后缀的方式，后缀可以选择采用UI、View等等。
我们暂时只对登录和商品购买这两个用例进行建模。
得到的类图如下。
类中的方法和属性可以在以后迭代中逐步补完。
在这里先列出一些比较有可能用到的方法，属性可以慢慢来。
类图的改进和细化
到现在我们在类图上罗列了一堆游离的类，我们可以在已知的条件下改进这个类图比如说Member类和VIPMember类可以抽离出一个共有的接口或有默认实现的父类等等。
这个类图的改进还包括描述清楚类之间的关系。
先别急着加，我们可以等画顺序图的时候再来考虑类间的关系。
/**
* 转载请注明作者longdick
*
*/
相关帖子：
1、人人都是领域专家-用例图
2、人人都是领域专家-活动图
3、人人都是领域专家-类图
4、人人都是领域专家-顺序图
5、人人都是领域专家-类图关系化
6、人人都是领域专家-类图关系说明
在分析阶段顺序图（SequenceDiagram）用来描述活动图里的单一事件流。
也就是说每个用例对应一个活动图，一个活动图对应一个以上的顺序图。
顺序图是交互图（interactiondiagram）的一种。
另一种交互图是协作图（CollaborationDiagram）。
第一次迭代我们只关注风险最大的两个用例“购买商品”和“登录”。
有了类图做铺垫，对照着用例的活动图，我们可以轻松的画出顺序图。
下图是登录用例的正常事件流顺序图。
你可以看到顺序图的类顺序排列符合一般架构的分层原则：
参与者--边界类--控制类--实体类。
但是这里有个问题，就是控制类LoginWorkflow怎么定位实体类Customer呢，当然不能凭空变出来，从顺序图推导出可能需要引入辅助类协助LoginWorkflow定位Customer。
这时候我们就需要增加一个实体类定位器，这种构造型称为LifeCycle的类可以以实体类名+后缀的形式命名，后缀名可以是Factory，Locator，Handler等等，在一个模型里保持一致即可。
我们将其命名为CustomerLocator，提供findByName方法来定位Customer，so，LoginWorkflow只需要持有一个对CustomerLocator的引用就可以了。
修改后的顺序图如下：
刚才已经说过了，顺序图对应活动图的每个事件流，除了正常事件流，可能还需要描述可选和异常事件流。
下图就是登录用例的可选事件流示例，除了个别细节不同，大体上是很类似的。
然后就到了购买商品的用例了，购买商品用例流程比较复杂，为了说明方便，对其做了精简，精简后的购买商品活动图如下：
这个购买商品的活动图有两个事件流，从活动图我们可以清晰的推出涉及到的实体：
商品、账户、订单和顾客。
顺序图可以说是水到渠成。
在作顺序图的时侯很适合做类的关联，可以在这个时候好好想想各个实体之间的关系、控制类对实体的直接引用还是使用辅助类间接引用等等。
当然有些人喜欢在画类图时就考虑类之间的关系也没有问题，我只是建议，不是要求。
基于同样的原因，我们增加了一个StuffLocator的LifeCycle类。
购买商品的正常事件流如下：
OK，如果项目时间还宽裕的话，把每个可选和异常事件流都加上。
/**
* 转载请注明作者longdick
*
*/
相关帖子：
1、人人都是领域专家-用例图
2、人人都是领域专家-活动图
3、人人都是领域专家-类图
4、人人都是领域专家-顺序图
5、人人都是领域专家-类图关系化
6、人人都是领域专家-类图关系说明
经过上一轮的顺序图的pk，我们发现需要在模型中添加两个辅助类：
CustomerLocator和StuffLocator，现在回来在类图里添加上这两个类。
这时候可以重新审视这张类图，也许有些类回过头来看觉得没有必要，就可以删掉。
比如VIPMember类，你想在Member类加个属性来区别是否是VIP也可以啊，这个可以经过讨论得出结论。
现在，接下来的工作就很Happy了，我们将顺序图中类的关系添加到类图里。
可以一个用例一个用例的来，别急着一股脑全上。
下图就是Login用例的类关系图。
下图是购买商品用例的类关系图
分析阶段建模的第一次迭代差不多到尾声，项目时间允许范围内还需要做几次迭代，最后的模型会和现在的大相径庭也不是没有可能。
只要掌握方法，细心加上耐心，一定可以作出优秀的领域模型来。
**
* 转载请注明作者longdick
*
*/
相关帖子：
1、人人都是领域专家-用例图
2、人人都是领域专家-活动图
3、人人都是领域专家-类图
4、人人都是领域专家-顺序图
5、人人都是领域专家-类图关系化
6、人人都是领域专家-类图关系说明
classdiagram里的四种关系DAAC，如图所示：
Dependency（依赖）
Association（关联）
Aggregation（聚合）
Composition（组合）
关联的紧密程度如下：
依赖<关联<聚合<组合
依赖：
短期联系，可能是作为方法的参数
或者在方法中创建，用完就丢掉了。
关联：
长期联系，可能是作为一个域存在
聚合：
一个整体包含另一个对象。
被包含
对象可能会参与多个聚合关系，例如Person
可以属于ProjectTeamA，也可能同属于
ProjectTeamB。
被包含对象相对独立。
组合：
一个整体拥有另一个对象。
被包含对象不能脱离整体而存在。
升级会员 