人人都是领域专家.doc

人人都是领域专家 1、人人都是领域专家-用例图 2、人人都是领域专家-活动图 3、人人都是领域专家-类图 4、人人都是领域专家-顺序图 5、人人都是领域专家-类图关系化 6、人人都是领域专家-类图关系说明 一个好的设计能使开发事半功倍，好的设计来源于好的需求。这就需要需求分析师帮我们开发人员提供精炼，清晰，准确的需求报告。需分将采集来的需求用UML（Unified Modeling Language ）描述出来，我称之为需求建模。 需求阶段建模的过程中涉及到的有用例图（usecase diagram）和活动图（activity diagram）。 下面就对网上购物的应用进行用例建模，以此举例用例建模的过程。 当然任何事情都不能一蹴而就，用例建模也是一样。用例建模的过程可能分好几次迭代进行，一开始粒度可能较粗，随着迭代进行而逐渐精化。所以不需要一开始就妄想考虑的面面俱到。 ? 1、网上购物的需求描述非常简单：无非就是用户在一个购物网站上购买商品。用用例图描述如下，有一个参与者和一个用例。非常简单，目标明确。 ?2、然后自评一下，觉得购买商品这个用例粒度太粗了，还有细化分解的可能。于是就将该用例分解。这个过程需要和客户更好的沟通。 ?3、用例分解以后，新的用例粒度更细，权责也更明确了。但是客户反映有些用例是购买商品的必选步骤，有些则不是。这时如何在用例图上体现这个关系呢？ 我们可以利用include和extend概念来描述，include描述的是主用例和次用例之间的包含关系即必选关系，extend描述的是可选关系。include关系箭头是主用例指向次用例，extend关系箭头是次用例指向主用例。 4、随着迭代的推进，发现有些用例可以有多种实现方式，不同的实现方式可能有不同的活动图和顺序图。故在用例图上使用泛化关系描述之。泛化关系使用一个空心的箭头，可以把它想象成继承关系。  5、用例精化的差不多了，还有别的参与者吗？用户提醒我们说，除了普通会员可以购买商品以外，还有一类Vip会员可以以折扣价购买一些特价商品。so，用例需要添加新的参与者和新的用例。  6、从上图可以看出，Vip会员就是特殊化的普通会员。然后，我们也可以对参与者泛化。但是参与者泛化会带来一些理解上的复杂性。可以的话，一般不推荐使用。 ?7、在重新审视需求，和客户充分沟通以后，本着简单，清晰有效，且不引起歧义的宗旨，我们重新修订整个用例，得到结果如下。当然这可能还没完，可能还有进一步挖掘需求和用例精化的空间。可以在保证进度前提下继续迭代建模。在建模的世界里，没有最好，只有更好。 ?  ? ?需求阶段用例图完成以后，需要进一步描述用例。 由于每一个用例可能对应几个事件流，单从用例不能获取有效的信息。这时候就要用到活动图了。活动图专门用来描述用例的事件流。 ? 我们借用上一节其中一次迭代的用例图做例子，寻找商品用例，泛化成两个子用例，这两个用例不能合并的主要原因就是事件流不同。 我们以“通过搜索引擎寻找商品”用例为例，使用活动图描述其事件流。 ? 活动图的描述可以参考以前完成的用例文档，一般的用例文档的格式如下： ? 用例名称：通过搜索引擎寻找商品描述：（...）前置条件： （...） 部署约束： （...） 正常事件流： （...） 可选事件流： （...） 异常事件流： （...） 非功能性需求： （...） 说明（可选）： （...） 未解决的问题（可选）： （...） ? 每一个用例文档都有描述三种事件流：正常事件流、可选事件流、异常事件流。 除了正常事件流以外，可选和异常都是可选的。 ? 根据用例文档对事件流的描述，我们可以作出活动图。 “通过搜索引擎寻找商品”用例的活动图如下（用例文档省略）：?其他用例也可以使用类似方式作出活动图。这里就不再赘述。 ? 经过了领域专家的辛勤劳作，我们终于得到了精准的需求文档、形象的用例图和每个用例的活动图。 接下来轮到架构师出场，开始轰轰烈烈的分析阶段。 分析阶段最主要的产出是类图和顺序图。 ? 为了简化问题，我们使用最后一次迭代的产出用例图（没有将用例进一步精化）。 ? 如果使用敏捷迭代开发，一开始分析阶段倾向于选择风险最大的用例优先开发，这个风险的评估在架构人员拿到用例文档以后就可以开始了。在这个例子里，我们倾向于选择“购买商品”为风险最大用例，“登录”用例次之。so，接下来的分析阶段，我们只关注“登录”和“购买商品”这两个用例。 ? 接下来分析这个用例图所有的参与者和用例，将实体识别出来添加到类图中。这往往是画类图的第一步，也是较简单的部分。既然UML主要用于面向对象语言建模，领域中的实体就是对应着语言里的对象。 ? 我们分析过程如下： 参与者是很明显的实体，因此会