巨核信息共享中心

Christopher Alexander 说过：“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”。简单来说就是：设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解并且保证代码可靠性。

设计模型是系统实施的抽象。它用于设想和记录软件系统的设计。它是全面的组合工件，包括所有设计类、子系统、包、协作和它们之间的关系。模型是一种将构思形象化的有效手段，同时也将三维概念的空间关系准确地表达出来，利用模型可以引发更多的创造力。

设计模型是系统实施的抽象。它用于设想和记录软件系统的设计。它是全面的组合工件，包括所有设计类、子系统、包、协作和它们之间的关系。模型是一种将构思形象化的有效手段，同时也将三维概念的空间关系准确地表达出来，利用模型可以引发更多的创造力。

领域模型，顾名思义，就是需求所涉及的领域的一个建模，更通俗的讲法是业务模型。

在业务对象模型中，业务角色代表雇员将担当的角色，而业务实体则代表雇员将处理的对象。一方面，可以使用业务对象模型来确定业务雇员将如何进行交互，以产生业务主角所期望的结果。另一方面，系统用例模型和设计模型指定了业务的信息系统。业务建模和系统建模解决不同的问题，其抽象程度也不一样。所以一般而言，信息系统不应该直接出现在业务模型中。另一方面，雇员作为业务角色来使用信息系统，实现相互之间的通信、与主角的通信以及对业务实体信息进行访问。所有的链接、关联关系或属性都有某个潜在的信息系统对其进行支持。这两类建模环境有以下关系：作为特定业务角色的雇员与信息系统的一个系统主角相对应。如果建立的信息系统使该雇员在业务用例中的所有工作都得到一个系统用例的支持，则他最有可能得到最好的支持。 另外，如果业务用例规模大、生存期长或者合并了多个独立领域中的工作，信息系统用例将可以支持业务角色的操作。 雇员工作的对象（建模为业务实体）常在信息系统中得到表现。在信息系统的对象模型中，这些业务实体作为实体类出现。业务实体之间的关联关系和聚合关系常常使设计模型中实体类之间产生对应的关联关系和聚合关系。 因此，系统用例访问并操作设计模型中的实体类，这些实体类代表由被支持业务用例访问的业务实体。最后，直接使用业务信息系统的业务主角也成为信息系统的系统主角。 当确定对支持业务的信息系统的需求时，这些关系十分关键。

领域模型设计是需求分析的关键步骤。它帮助用户及需求分析人员建立业务概念，确定用户业务的问题域，系统涉及的业务范围等等。领域模型设计的步骤为：

1. 从业务描述中提取名词；

2. 从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、实例，形成问题域中操作实体的集合；

3. 从业务实体集合中抽象业务模型，建立问题域的概念（例如在前面的例子中，我们把容易变质的水果称之为“短期保持水果”，当然也可以是其它说法，只要能跟用户达成共识即可）；

4. 用UML提供的方法和图例进行领域模型设计、确定模型之间的关系

领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。