Important Questions重要的问题
你可以把整个领域的面向对象的分析和设计减少到两个简单的问题: 首先，系统中的对象是什么？其次，需要的系统行为如何在对象中分配？
已经明确要建立的正确的对象集，并且你已经为一个系统分配了合适的类集，你的项目将会进展顺利。最难的工作恐怕是我们听起来觉得很很顺耳的“分配行为是不错的工作”这句话，这也是有经验的面向对象分析者的生存之本。
Drive the Static Model from the Dynamic Models从动态模型中分离出静态模型
无论你打算在哪个过程使用UML，从动态模型中分离出静态模型（类图）是不错的实践方式，从较高层次的用例图开始，尤其是使用UML 时序图在类图中分配行为。 这个理论，是从Jacobson的OOSE/Objectory 过程中得来的，是1993年的时候一个关系好的Objectory咨询者解释给我听的。在过去的四年中我继续把它作为一种设计形式在教，它内在的智慧和广泛的应用让我已经越来越信服它了。
这个观点的本质在于： 通过遵从对象模型方法我们可以开始并且得到一个系统的粗略的对象集，这同通过问题描述来寻找名词得到“现实世界”或“问题领域”很相似。有时，我们可以做出聪明的猜测，一个特殊的类可能会是一个特殊操作的容器。但是，通常在面向对象的设计过程中，我们发现缺少用例开发来考虑静态模型是幼稚的。
以我的经验，面向对象分析与设计的实质在于真正好的方法解决类中分配行为的问题，把用例在更详细的（信息传递/方法）阶段。正规的或者非正规的，我所遇到的年长的的面向对象分析者大部分是这样设计的。当方法不正式时（不可见），设计者对怎样从一系列给定的领域对象和用例中得到一个明确的方法充满疑惑。通常，在使用一个系列像“多态、封装接口“这样的行话时这样的疑虑又会产生。这样能限制项目组成员完成有用的设计评估，让水平高的程序员更灵活地根据情况完成任务。
然而，在我看来，在UML（参看“UML模型如何匹配“，关注UML， SR4 页，时序图例子）中使用时序图设计方法才能更好的完成。时序图通过左侧的早先的（需求阶段，用户手册视图）父用例文本描述，图中间的实际的详细的动态行为（每一个方法和触发事件）描述来实现的。在一页纸上描述看出详细设计和需求阶段用例描述需要快速的浏览需求，可以证明至少你的用例设计符合需求。简单的重复系统中所有用例，将会得到一个可跟踪的设计。
画时序图的过程中，在设计中要确认具体的操作并把它分给具体的对象。虽然画动态（时序）图实际上也是在创建静态类模型。时序图是教我们如何从抽象的世界中找到对象模型的。
Defer Assigning Operations to Classes操作迟些分配给类
在项目分析阶段不要过多的去关注将操作放进哪个类中。除了大部分显而易见的情况外（有时连这些也会出错），很可能规划错误。经验告诉我，做这些行为分配决定的时候最好仔细，随着动态模型的开发一次一个。
要把这种分离一直记住（分析：什么是对象？设计：行为如何分配？）会帮助项目组定义分析和设计的界限。我们最先的统一对象建模过程方法在最初的分析阶段使用了对象建模方法符号，在设计阶段使用了Booch符号。在分析的过程中对象建模方法被使用，更详细的设计阶段的模型使用Booch方法。在UML中，这些符号被融合成单一的，对象模型方法。随着分析和设计符号的模糊不清，项目组经常要分清分析和设计的界限在哪儿会很困难。
即使我在教跌代和递增过程， 在某些逻辑点上，需求和设计评估是必须的。如果我在评估一个分析模型，我并不会很在意类的操作（在大多数场合，如果没有我会很高兴）。我在寻找一个好的域类集和可以理解的用例模型。而在设计评估时，所有的操作都需要考虑在内，在时序图中需求和设计必须可以跟踪。设计者必须能解释清楚为什么他会把一些操作放在特定的类中。
Simply Successful简单既成功
在项目中使用UML，需要时刻记住的是保持简单，先写用户手册（一次一个用例），同时让项目组对过程有统一的认识。记住，UML是一种符号，而不是过程。我所见到的最成功的项目都采用用例驱动，迭代，递增方法的。如果能把过程细化并且让项目组掌握技巧，UML项目已经离成功不远了。
文章来源于领测软件测试网 https://www.ltesting.net/
