分析模型是分析设计阶段出现的简化而抽象的模型 [RUP称为细化阶段一个工件]，
该阶段可能会出现相关的分析时序图、活动图等其他的人机交互的直观体现方式；而设计的目标是将此初步（且有些理想化的）映射转换成可实施的模型元素集。模型元素从分析阶段演进到设计阶段后，细节和精度都得到精化。因此，“分析类”经常保持非常高的非固定性，并且在设计活动中固化之前可做极大的改进。即：设计模型是分析模型进一步精化和细化的产物；分析模型是设计模型的抽象或泛化关系。以上理解估计大多设计人员都能理解，不再赘述。
现在存在的一个争议是：分析模型过渡到设计模型后，是否有继续存在的意义？
这是矛盾的，分析模型做为为设计模型的高度抽象结合关键抽象和需求阶段的用例等工件，为想在短时间内了解项目的用户提供的了不可估量的便利捷径，比如项目新成员；同时对于分析阶段和设计阶段职责划分较为明确的项目，分析模型代表了两个不同阶段的角色对系统的不同的分析过程。为了更好的进行任务的交接，保留分析模型也是有其重要的意义的。但是，庞大的业务系统随着不断的迭代、变更造成分析模型的维护成本及其昂贵。面对以上问题，RUP提出一个折中的方法可以是分析模型仅具有设计中最重要的领域类和关键的抽象概念。我的观点：在设计迭代的过程中要保证关键抽象[领域模型]的时时更新，而分析模型在过渡到设计模型后，分析类直接转化为设计类，分析类中的方法，转化或细化为设计类中的方法中去，分析模型的生命到此终止。
结论：对于规模较小的系统，分析模型和设计模型不必划分如此清晰；对于较为复杂的系统，由分析模型过渡到设计模型后，不必花费较大的成本进行重复维护分析模型。
