一切皆可抽象

业务用例对角色（什么样的个体和接口访问到我们识别出来的各种业务任务）
业务对象对业务对象（各个业务对象之间是如何彼此交互的，和他们共享信息的种类）
用例对用例（任务彼此之间的依赖，和被一定的过程共享的公用任务

用例设计误区
用例被创建的太大或者太小 －－ 粒度问题
用例在跨越团队的情况下不一致  －－ 用例一致性（形式 含义）
没有对用例分组的包进行良好的计划  －－ 模块划分不合理
不合理的对模型的访问进行控制，导致在团队分析协作的过程中发生冲突  －－ 开放式团队管理
过于细致的定义用例，在用例进入原型、设计和开发任务之前就定义每一件事情  －－ 粒度太小 需求确定的可以这么做 不稳定的当抽象为主 对应变更
定义用例时过于简单，使需求被工程团队可以有众多的解释  －－ 言语还是不确定 无法用语言表达的借助图形 图形无法描述的 定义术语集合 语言支持

角色模型
模块模型

在从用例向设计类转化的过程中，我们希望能够实现：

将分析小组的知识传授给工程团队。   －－ 文档传承 结构合理易于理解的文档（加以详细注释）不失为最好的选择
识别能够满足所有需求的技术方案 — 或者，什么地方不是可能的，识别与技术方案冲突的需求，并确定是否他们是重要的或者被改变或者被删除。
 －－ 需求阶段应该加入这样的分析和模型了
识别能够帮助确定团队结构、架构层次和对于购买软件的候选的接口。
 －－ 整合好的方案 不能整合的以清晰的头脑单做
指定技术方案的细节并开始计划如何在团队之中分配工作。
 －－
基于设计模型的细化时间进行计划和预算的预估。
 －－ 经验 改进
分配类到平台、产品和私有代码。
 －－ 拿手完
为了反馈和同步的目的，生成软件架构文档，软件架构文档能够被分发到内部和外部的团队成员。
 －－ 传承沟通

我们如何组织通用的服务？
回答：公用服务被单独的放在一个子包中（日志服务；数据同步和备份服务；访问控制服务和登陆服务）。
我们应该在 shipping 和 part management 之间画线吗？
回答: 我们不需要连接他们两个。
我们根据领域还是架构来定义子系统？
回答：架构在大多数地方都能与领域结合。
我们允许包之间的双向依赖吗？
回答：不。这是违背我们内部设计指导方针的不好的设计实践。
MDA 的观点下有四个原则：

以一种定义良好的符号表示的模型是理解企业级方案系统的基础。
系统的构建能够围绕着一系列模型通过使用在模型之间的一系列转换被组织的，并且能被组织到一个分层的和转换的体系架构框架中。
以一系列元模型来描述模型的一种正式的支持能力能够使在模型中有意义的集成和转换变得容易，并且是通过工具实现自动化的基础。
接受和广泛采纳基于模型的方法需要工业的标准提供开放性给客户，并鼓励供应商之间的竞争。

OMG已经定义了一系列的层次和转换，他们为MDA提供了概念性的框架和词汇表。
特别的，OMG 确定了四种模型类型：
计算无关的模型（CIM），
平台无关的模型（PIM），
被一个平台模型（PM）描述的平台相关的模型（PSM）和
一个实现相关的模型（ISM）。

问题领域模型和方案领域模型
业务建模 数据建模 安全建模 性能建模
狭义上讲，它是关于一个系统的不同抽象模型，和在模型之间定义良好的模型转换的。
广义上讲，它是关于抽象的各种级别上的模型，这些抽象作为基础为软件架构服务，这些架构最终将通过各种实现技术被实现。