大象：THINKING IN UML 第2章 建模基础.pptVIP

2.5对象分析方法 我们获取和分析对象的手段经常是通过分析某个场景，但是需要知道，对象是离散的，它不是为该场景而存在的。场景中的对象只是对象“映射”到该场景中的一个侧面，我们称之为对象实体。换言之，通过一个场景，我们能得到对象的一个侧面的信息， 对象分析方法 2.5对象分析方法 3. 对象都具有原子性 无论在什么时候，在同一抽象层次上，在分析过程中都应当将对象视为一个不可分割的原子。在分析过程中，对象总有一个边界，永远也不应打破边界去窥探对象的内部。 2.5对象分析方法 4. 对象都是可抽象的 对象参与一个场景时会展现出某一方面，总可以将对象的某一方面抽象出来。 2.5对象分析方法 5. 对象都有层次性 根据问题领域的复杂程度设定多个抽象层次，在每个抽象层次上使用适合的抽象程度的对象描述。 对象分析方法 第2章 建模基础 2.1 建模 建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察到对象的内部结构和工作原理的便于理解的表达。 模型要能够真实反映客观事物就需要一个论证过程，使得模型建立过程是严谨的，并且结果是可追溯和验证的。 对于一种软件建模方法来说，为现实世界建立模型也要是严谨的，可追溯和可验证的，除了描述清楚需求，还要能很容易将这个模型转化为计算机也能够理解的模型。 建模要解决的两个问题 建模要解决的两个问题 1. 怎么建？ 2. 什么是模？ “怎么建”依赖于方法论和认识论，不同的软件方法（面向过程还是面向对象）将导致不同的建模结果。 建模，首先并且重要的是选择抽象角度，之后就顺理成章了。 软件建模 具体来说，做需求的时候，首要目标不是要弄清业务是如何一步一步完成的，而是要弄清楚有多少业务的参与者?每个参与者的目标是什么? 参与者的目标就是你的抽象角度。与分析个复杂业务流程相比，单独分析参与者的一个个目的要简单得多。实际上，这就是用例!这也就是为什么用例会成为业务建模的方法的原因之一。 “什么是模”依赖于选择了抽象角度下的场景模拟。一旦选择了抽象角度，就确定了一个目标。现在，要做的事情便是找出那些能够满足这一目标的事物。 软件的模 模就是“人”、“事”、“物”、“规则”。 人=业务主角(Business Actor)、业务工人(Business Worker)、参与者(Actor)等； 事=业务用例(Business Use Case)、系统用例(use Case)等； 物=业务实体(Business Entity)、实体(Entity)等。 建模公式 2.2 用例驱动 要解决问题领域就要归纳出所有必要的抽象角度（用例），为这些用例描述出可能的特定场景，并找到实现这些场景的事物，规则和行为。再换个说法，如果我们找到的那些事物，规则和行为实现了所有必要的用例，那么问题领域就被解决了。这就是用例驱动方法的原理。 在统一过程中，一个用例就是一个分析单元，设计单元，开发单元，测试单元甚至部署单元。 用例可以驱动的内容 用例可以驱动的内容 1. 逻辑视图：该视图以图形方式说明关键的用例实现，子系统，包和类，即，人，事，物，规则，是如何分类组织的。 用例可以驱动的内容 2. 进程视图：以图形方式说明了系统中进程的详细组织结构，其他包括类和子系统到进程和线程的映射，即，人，事，物，规则，是如何交互的。 用例可以驱动的内容 3. 部署视图：以图形方式说明了处理活动在系统中各节点的分布，包括进程和线程的物理分布，即，人，事，物，规则，是如何部署在物理节点（主机，网络环境）上的。 用例可以驱动的内容 4. 实施视图：其作用是获取为实施制定的架构决策。包括：a. 例举实施模型中的所有子系统。b. 描述子系统如何组织为层次和分层结构的构件图。c. 描述子系统间的导入依赖关系的图解。 实施视图作用 a. 为个人，团队或分包商分配实施工作。 b. 估算要开发，修改或删除的代码数量。 c. 阐明大规模复用的理由。 d. 考虑发布策略。 也即，人，事，物，规则，如何构成系统的零部件，以及我们如何组织人力生产和组装这些零部件以建成最终系统。 2.3抽象层次 首先，抽象层次越高，具体信息越少，但是概括能力越强；反之，具体信息越丰富，结果越确定，但相应的概括能力越弱。从信息的表达能力上说，抽象层次越高表达能力越丰富，越容易理解。 2.3抽象层次 但随之而来的另一个问题是如果抽象层次太高，信息量过少的话，人们实施起来又会产生新的困难——信息量不足。因此，在面向对象的分析过程中，在适当的时候采用适当的抽象层次是十分重要的。几乎所有使用过UML的朋友都会觉得选择用例的粒度是一件很困难的事，实际上用例粒度选择的困难本质是由