OO系统设计师之路--分析模型系列(2)--怎样做分析模型 [从老博客搬家至此]

 

上一篇笔者阐述了什么是分析模型，我们为什么要使用分析模型，分析模型能给我们带来什么。这一篇来讨论怎么做分析模型。

开篇之前先说点题外话。笔者不厌其烦地一次次提到需求的可追溯性，是因为软件工程比UML更重要更本质。笔者自己在学习UML过程中，曾经也非常迷惑而不得要领，这么多UML元素，每个都有其特定的含义，RUP中定义了更多更复杂的流程，模板，工具...虽然读了很多资料，却始终感觉UML信息太过于分散，不能很好的把UML应用到实际的项目中去。直到有一天突然转变了思维，不是从UML的定义中去思考如何做软件，而是站在软件工程的角度，去UML中找寻需要的工具。正是这一转变使我对UML的认识茅塞顿开。我想，初始学习UML的人可能也会经历跟我同样的困惑，在这里我愿意把我的领悟与大家分享。对软件项目来说，OO也好，面向过程也好，UML也好，UC矩阵也好，这些都不是最重要的，软件项目真正的灵魂是软件工程。软件工程的需要才是这些工具诞生的原因。因此我建议阅读我文章的朋友们，在讨论如何应用UML之前，应当先系统学习软件工程。只有掌握了软件工程，你才会知道为什么要有用例，为什么要有分析模型。站在软件工程的立场，那些孤独的UML图符才会变得有生命力，你随时都会知道需要用什么样的UML图符来表达软件的观点。UML也不再面目可憎，它们是一群有着强大能力的精灵，帮助你在复杂的软件工程道路上搭起一座座通向光明目标的桥梁。

虽然是不厌其烦，还是要再次提醒，注意需求的过追溯性，这是软件工程的需要。这一篇我们要讨论的话题里，仍然逃不开这条主线的牵引，你会发现这一篇里产生的任何一个成果都与之前的工作息息相关。如何做分析模型？在UML里，RUP里没有明确的答案，我从软件工程中找到了答案，正如上一篇所说，析模型是采用分析类，在系统架构和框架的约束下，来实现用例场景的产物。用例场景是什么？是用户需求的模拟，实现用例场景，就是实现需求。为了达到需求可追溯的目的，分析模型需要以下这些输入（还是采用用例分析系列文章中的例子）：

• 用例场景