架构师培训讲义3-领域建模与系统行为分析.docxVIP

第三章 领域建模与系统行为分析用例模型原则上不是面向对象的，它描述的是系统的功能，只是建立系统的最初的输入，为了更细腻的分析需求，从面向对象的角度，可以建立领域模型。识别一个丰富的对象集或者领域类集，是面向对象分析的核心工作，做好这项工作，将会在设计和实现期间获得丰富的回报。 第一节 领域建模的思想和方法领域模型是作为设计软件对象的启发来源，也是后续工件的必须输入。领域模型是说明问题域里（对建模者来说）有意义的领域类，它是面向对象分序的时候要创建的最重要的工作（必须说明，用例虽然也是一个重要的分析工作，但它并不是面向对象的，它是强调的概念的过程视图）。一、领域建模的思想及其方法学问题什么是“问题域”和“领域建模”？问题域:现实世界中系统所要解决问题的领域为“问题域”，如“银行业务”属于“银行的问题域”。领域建模:1．我们设计一个系统，总是希望它能解决一些问题，这些问题总是会映射到现实问题和概念。2，对这些问题进行归纳、分析的过程就是领域建模（这个域，指的就是问题域）。建立领域模型的好处：1，通过建立领域模型能够从现实的问题域中找到最有代表性的概念对象2，并发现出其中的类和类之间的关系，因为所捕捉出的类是反馈问题域本质内容的信息。经典的面向对象的分析或调研的步骤，是把一个相关的领域，分解为单个领域类或者对象（是一个我们能够理解的概念）。领域模型是领域类或者是我们感兴趣的现实对象的可视化表示。它们也被称之为：概念模型、领域对象模型、分析对象模型等。在UML中，领域模型是不定义操作（方法）的一组类图来说明，它主要表达：领域对象或者领域类领域类之间的关联领域类的属性属性用以表达对象的状态。（1）三种领域类1，边界对象：参与者使用该对象与系统进行交流，也即边界对象代表系统的内部工作和它所处环境之间的交互。边界对象将系统的其它部分和外部的相关事物隔离和保护起来。其主要的责任是：输入、输出和过滤。2，实体对象：代表要保存到持续存储体中的信息。实体类通常用业务域中的术语命名。通过它可以表达和管理系统中的信息。在模型中，系统中的关键概念以实体对象来表现。其主要的责任是：业务行为的主要承载体3，控制对象：它协调其他类的工作，每个用例通常有一个控制类，控制用例中的时间顺序。它可能是与其它对象协作以实现用例的行为，控制类也称管理类。其主要的责任：控制事件流，负责为实体类分配责任有四个规则对应上面的三种分析类对象间的交互1，用例的参与者只能与边界对象交互（这相当于结构化分析里面的自动化边界） 2，边界对象只能与控制对象和动作者交互（即不能直接访问实体对象）3，实体对象只能与控制对象交互 4，控制对象可以和边界对象交互，也可以和实体交互，但是不能和动作者交互三种领域类的UML的图示如下：（2）领域建模的简单例子下面举个简单的例子，说明领域建模的基本概念。1）问题的描述例如：两个领域类Payment（支付）Sale（售出）在领域模型中以一种有意义的方式关联。2）关键概念仔细考察上面的图，可以看出，领域模型实际上是可视化了领域中的单词或领域类，并且为这些单词建立了领域类。也就是说，领域模型是抽象了一个可视化字典。模型展现了部分视图或抽象，而忽略了建模者不感兴趣的细节。它充分利用了人类的特点—大脑善于可视化思维。3）领域模型不是软件组件的模型领域模型视相关现实世界领域中事务的可视化表示，不是Java或者C#类这样的软件组件。下面这些元素不适合在领域模型中表述：1，软件工件（窗口或数据库）2，职责或者方法：方法是个纯粹的软件概念，在设计工作期间考虑对象职责是非常重要的，但领域模型不考虑这些问题，在这里考虑职责的正确方法是，给对象分配角色（比如收银员）。4）领域类领域模型表示领域中的领域类或词汇，一个不是太准确的描述：一个领域类就是一个观点、事务或者对象。比较准确的表达：领域类可以按照它的符号、内涵和外延来考虑。符号：代表一个领域类的单词或者图片。内涵：领域类的定义。外延：领域类定义的一组实例。 二、领域类的识别我们的目标是在相关领域中创建有意义的领域类。比如说创建“处理销售”用例中的相关领域类。一般来说，用大量细粒度的领域类来充分描述领域模型，比粗略描述要好。下面是识别领域类的一些指导原则：不要认为领域模型中领域类越少越好，情况往往恰恰相反。在初始识别阶段往往会漏掉一些领域类，在后面考虑属性和关联的时候才会发现它，这是应该把它加上。不要仅仅因为需求中没有要求保留一些领域类的信息，或者因为领域类没有属性，就排除掉这个领域类。无属性的领域类，或者在问题域里面仅仅担当行为的角色，而非信息的角色的领域类，都可以是有效的领域类。1）识别领域类的策略下面提供了两种识别领域类的技巧。使用领域类分类列表。识别名词短语。2）使用领域类分类列表通过建立一个候选的领域类的列表，来开