需求分析和系统建模(4).doc

2.4 域模型及建立系统域模型示例2.4.1建立项目系统中的域模型1什么是问题域和域建模（1）什么是问题域？软件系统所要解决的现实世界中的问题领域称为问题域，如银行业务属于银行的问题域、网上商城系统属于电子商务的问题域、BBS论坛系统属于内容管理的问题域。（2）什么是域建模？软件系统的开发者设计和开发实现一个软件系统，总是希望该软件系统能解决一些特定的问题，这些问题总是会映射到和现实问题相关的一些概念。对这些问题进行归纳、分析的过程就是域建模(域指的就是问题域)的过程。（3）为什么要进行域建模?建模是开发优秀软件系统活动的核心部分为软件系统建立模型的主要目的是实现设计结构和系统行为之问的沟通，并对软件系统体系结构进行可视化控制。建模是为了更好地理解正在开发的软件系统，并能够提供简化和复用的机会；同时建模还可以降低开发过程中产生风险的可能性。建立域模型的优点建立域模型能够从现实的问题域中找到最有代表性的概念对象；并能找出其中的类和类之间的关系，因为所捕捉的类是反馈问题域本质内容的信息。图2.43所示是某BBS论坛系统中业务层组件的类图示例，从这个类图中可以了解各个类之间的关系。图2.43某BBS论坛系统中业务层组件的类图示例2与建立域模型相关的一些知识（1）什么是域模型?所谓的域模型实际上是可视化了领域中的名词列表，并且为这些名词列表建立领域类。也就是说，域模型是抽象了的一个可视化字典。模型展现了部分视图或抽象，而忽略了建模者不感兴趣的细节。（2）域模型不是软件组件的模型。域模型是现实世界领域中相关事务的可视化表示，不是Java语言或者c#语言中的有关类等这样的软件组件。因此以下元素或者名称不适合在域模型中表述。软件组件（窗口或数据库）。对象中的成员方法：成员方法是纯粹的软件领域的概念。对象的职责：在设计工作期间考虑对象职责是非常重要的，但在域模型中不考虑这些问题。而在域建模中考虑职责的正确方法是给对象分配角色（比如收银员）。3识别领域类的策略是根据名词短语识别有人提出了用名词短语分析找出领域类的方法，然后把它们作为候选的领域类或者属性；不过开发者在使用这种方法时必须十分小心，因为从名词机械地映射肯定是不行的，自然语言中的单词本来就是模棱两可和存在歧义的。下面是识别领域类的一些指导原则。（1）不要认为域模型中领域类越少越好，情况往往恰恰相反。领域类越少，也就意味着类的职责越集中，这样将不利于系统后期的复用；组成系统的基本单元越简单，粒度越细，用这些单元构建系统的灵活性就会越大，单元的可复用性也越大。（2）识别领域类的过程也是一个不断完善的过程。在初始识别阶段往往会漏掉一些领域类，在后面考虑属性和类之间的关系时才会发现它们，这时应该再把它们添加上。（3）尽可能全面地找出各个领域类。不要仅因为需求中没有要求保留某个领域类的信息，或者因为某个领域类没有属性，就排除掉这个领域类。4如何通过建立域模型识别系统中的各个类及其关系通过对软件系统中的各个业务对象建立域模型，分析和设计人员能够获得系统的基本对象。随后即可进行软件系统中数据库表的逻辑设计，进而再实现系统的业务逻辑处理功能，最后实现系统中的各个表现层组件。建立域模型主要的思路和基本的实现步骤如下：（1）收集和描述软件系统中的各个用例。（2）对用例进行分析并首先建立一个用例实现。通常对一个用例的实现，开发者需要做下面这些事情：设计包括开发者关注的用例中出现的所有类的一个UML类图（有时也叫做合作类视图）；设计描述交互的对象，以及它们之间的调用关系的一个或多个UML交互图。在UML中定义了两种类型的交互图：顺序图和协作图。（3）其次，补充和完善前面用例的描述。当开发者在进行用例分析时，设计出的用例描述只记录了从用户角度来看，系统的行为是什么样子的。在概要地描述系统内部一些不可见的操作时，这足够了，但是按照这样的描述，并不能完成具体的用例编程实现。因此，开发者还需要进一步补充和完善对前面用例的描述。（4）再为用例行为找出分析类。这一步的目的是找出分析类的候选范围，这些类共同合作可以完成用例的所有行为。（5）根据分析的结果找出软件系统中的各个分析类。寻找类的一个简单方法就是语法分析，开发者只要找出在软件项目需求中的各个名词短语即可，这些名词短语(有些是形容词+名词)以后将成为软件系统中的类、类中的属性等内容。当然，一些对软件系统无关紧要的名词短语，开发者可以筛选掉它们。对领域类的命名，一般使用问题域中的词汇；另外，如何正确而合理地分辨出哪些候选名词才是真正的问题领域中的类呢？此时，开发者需要对每个候选词做检查，一个常用的检查方法就是用一些简单的问题来测试每个词是否为所需要的名词。这个候选的名词是在系统的边界之内吗?如果不是，那么它可能是系统的用户。当 然，此时它也不是软件系统中的分析类。这个候选名词有某些明显的与业务主题有关的行为吗?也就是说，这个候选名词可 以拥有或者提供某些系统的服务或功能吗?如果不是，那么也不能够成为软件系统中的分析类。这个候选名词拥有明显的数据结构吗?也就是说，这个候选名词拥有或者管理某些 数据吗?如果不是，那么同样也不能够成为软件系统中的分析类。这个候选名词和其他候选名词之间有什么关系吗?如果有关系，那么开发者可以把 它看成软件系统中的分析类。注意：开发者依此规则检查各个名词，因此寻找领域类是一个迭代式的任务，需要反复思索和筛选。（6）描述已找出分析类的职责。在面向对象技术中，类的职责的概念应该是描述了这个类在系统中所提供的服务，而且其他类不会重复提供这些服务。因为，各个类的职责是不能重叠的。当然，开发者在域建模过程中提及的分析类的职责更多的应该是类所属的业务角色。开发者需要和领域专家、业务分析专家一起上作，共同完成类的职责的定义。首先要注意“清晰定义”，即应该明确地指定该类可以做什么以及不可以做什么。这可以应用通用职责分配软件模式（GRASP）来获得指导，读者可以参考本书的第8章“通用职责分配软件模式（GRASP）”中的有关内容。当然，在比较复杂的系统域模型的建立过程中开发者也不应该期望一次性完整地将系统中的各个类的职责准确地定义出。因为，当开发者随着对系统需求的进一步理解或者了解更多有关软件系统中的信息之后，开发者再对类的职责进行调整是很正常的。（7）建立分析类之间的关系。对于任意两个具有关系的类，确定关系是关联（包括确认关系的多重性，如“一对一”、“一对多”、“多对一”和“多对多”）、聚合、组合还是继承等形式中的某一种。（8）确认分析类的行为。到现在为止，开发者还没有涉及类的内部结构和组成的分析和建模，因为在前面定义的各个分析类是没有操作和属性的，而且类图也是静态的。开发者如何确认这些类并完成在用例的事件流中描述业务的过程。这可以通过进一步确认分析类的行为来完成，也可以借助于UML提供的两种形式的交互图顺序图和协作图。在软件系统的分析和建立模型阶段中，UML中的交互图是很重要的。而且还应该明确的一点是，交互图中的消息只表明了意图，而不是具体的虽后实现；消息只是简单地表明希望接收消息的对象做什么事情，而消息本身并不真正代表一次对方法的调用。对方法的调用等这些更具体的与实现相关的信息，是在随后的设计阶段确定的。这也是分析阶段的交互图和设计阶段的交互图的差别所在。（9）描述各个分析类中的属性。为了类能够完成其自身的职责，需要一些属性（也就是在面向对象编程语言中的类成员的属性变量）来保存其状态。当然，在此阶段中类的属性没有必要注明其数据类型，因为属性的具体数据类型也是在设计阶段确定的。发现和识别领域类的属性是很有意义的。属性可以是另一个对象，也可以是简单的数据类型（如int、float、char等）。当然还可以是其他的一些数据类型，比如：Color（颜色）、Address（地址）、Phone Number（电话号码）等自定义的类型。2.4.2 建立域模型的示例下面通过某个内容管理系统域模型建屯的具体实例来说明如何建立系统的域模型，该内容管理系统的具体用例请见第1章图1.3所示的某个BBS论坛系统项目中面向注册用户的UML用例图。为了突出重点内容，在构成本示例时，对BBS论坛系统项目进行了简化。1建立某个内容管理系统域模型的实例需求分析和理解（1）本内容管理系统的主要功能需求。开发方的工作人员，从用户方获得的内容管理系统的主要功能需求如下（对实际的需求内容进行了简化）：我需要做一个网站。我的文章、我最近的活动(新闻)、下载和留言。我希望把我平时的文章发布出来给用户看。我希望把我最近做的讲座放到我的活动栏目中进行宣传。我还会把我的一些源代码和讲座录像打包发布。我希望用户给我留言。（2）需求分析和理解。根据前面对需求分析的有关知识的学习，开发者可以将需求分离为下面的功能性需求和非功能性需求两种形式的需求。内容管理系统的功能性需求。网站可以提供我平时写的文章的链接。网站可以将我最近的活动情况发布出来。网站能够将我平时的源代码和讲座录像打包发出去。网站能够保存用户给我的留言。内容管理系统的非功能性需求。网站要简单、美观和大方。浏览速度尽可能快。下面基于对前面提出的系统需求的理解，进行域模型的建立（为了简单明了和节省本书的篇幅，只给出了核心步骤和实现要求、Rational Rose中主要的实现过程的图示）。2建立某个内容管理系统域模型的实例一发现并找出各个有关的类（1）从需求列表中找出有关的名词短语。（2）发现并找出域模型中各个有关的类，并在Rational Rose中设计出。创建“用户留言”功能模块包，最后的结果如图2.44所示。图2.44 创建“用户留言”功能模块包在该包中分别添加各个分析类，最后的结果如图2.45所示。图2.45 在该包中分别添加各个分析类3建立某个内容管理系统域模型的实例找小类之间的关系设置“用户留言”功能模块中相关的各个分析类的关系并在Rational Rose中定义出它们之间的关系。最后的结果如图2.46所示。图2.46找出类之间的关系4建立某个内容管理系统域模型的实例一设计类中的各个属性有关UML中的类及类图的概念，以及其在Rational Rose中如何制作，请参见本书第4章中UML静态建模的内容，在此只需要大家对此有初步的了解即可。最后的操作结果如图2.47所示。图2.47 设计类中的各个属性5建立某个内容管理系统域模型的实例动态分析交互图中的顺序图设置名称为“用户留言模块的顺序图”，然后分别从用例图中拖动“用户”和“留言功能包”中拖动“留言表单”、“用户留言”和“留言”、“留言成功”等类到视图中。再分别设计其消息发送和返回的次序。最后的操作结果如图248所示。图2.48 动态分析交互图中的顺序图应该注意的是，到目前为止所建立出的顺序图中出现的各个消息都没有映射成对应类的操作方法，如“填写表单”消息没有映射成“留言表单”类的操作方法。因此，如果此时应用Rational Rose生成代码进行“检查模型”会出现错误。最后的操作结果如图2.49所示。图2.49 动态分析交互图中的顺序图的最后结果有关顺序图的概念及其在Rational Rose中是如何制作的，请参见本书第5章中UML交互建模的内容，在此只需要大家对此有初步的了解即可。6建立某个内容管理系统域模型的实例动态分析中交互图中的协作图由于Rational Rose工具提供了可以直接根据顺序图自动地创建出对应的协作图的功能（只在Rational Rose工具中提供，如果在其他类型的UML工具中，则必须自己来实现）。因此，可以借助该功能直接获得协作图。如图250所示的Rational Rose中的菜单。图2 50 Rational Rose 工具提供的转换菜单选中图2.