《用例建模与分析》PPT课件.ppt

3 GIS软件工程用例建模与分析,3.1 概述 用例建模是用来捕获系统场景的形式化过程，是识别和定义任何类型软件系统需求的重要方法。本章将重点讲述如何利用用例建模，有效获取软件系统需求。3.2 本章的重点陈述用例模型的组件描述用例模型如何辅助解决常见的需求定义问题开发用例为用例编写文档将用例建模贯穿到项目生命周期中,3.3 需求获取 需求是描述系统应该具备的功能，以及为满足此功能需要具备的条件。需求用来描述系统应该做什么，而不是如何构建系统。可以直接从用户那里获取需求，也可以在合同、标准、规范或其它正式使用的文档中来获得需求。需求获取是定义系统的过程，包括对问题空间的清晰理解，然后定义解决问题的应用或系统。1.定义需求过程中的一般问题 软件需求规范中确定需求一般只是简单基于自然语言的说明性语句，开发者总是使用规范中提供的经典场景来试图理解系统需求的含义以及期待系统如何运转，软件需求规范的编写方式非常低效。而用例是可以将场景捕获过程形式化的有用技术。2.用于需求获取的用例建模 用例（Use Case）是系统执行的一系列事件（操作），通过提供这些事件，可以为特定参与者产生可度量的结果。参与者（Actor）是与系统进行交互的某个人或者事物所扮演的角色。因此，用例是由一系列动作组成，用户必须进行这些动作，以完成一些有用的工作并实现目标。用例反映了在实现参与者目标的过程中，系统可能发生的所有事件。,3 GIS软件工程用例建模与分析,用例必须从用户的角度描述所期望的系统行为，完整的用例集合确定了系统的范围，包含了系统的所有行为。用例应作为需求定义单元或仅仅作为一个用户目标。3.4 用例建模技术 用例建模是一个从外部视角来描述目标系统行为的过程。用于描述系统将要做什么，而不是如何做，主要帮助设计师关注系统需求，而不是系统实现。用例图能够使系统设计师从用户的视角发现目标系统需求，是设计师与用户进行沟通的有效工具。用例模型（Use Case Model）是一幅图或一组图，还可能包含额外的资料，用于表达所提交的软件系统要完成的工作。用例图由3部分组成：参与者 用例以及用例之间的通信 额外文档 另外，用例图还包含系统边界。1.参与者 参与者是需要与系统交互信息的一切外部实体。主要包括以下几类：,3 GIS软件工程用例建模与分析,人；计算机硬件或设备；外部系统。参与者代表了用户可以扮演的角色，不是某个特定的用户，而是可以扮演某个角色的一组用户。一个人可能是某个参与者的实例，多个人也可能扮演某个参与者的同一角色。识别用例的通用方法是与将要直接操作该系统的用户交谈，该过程有助于设计满足用户需求的系统。而系统的其它涉众可能在关键的开发阶段漏掉，导致系统可能不满足所有涉众需求。在同一个软件系统中，不同涉众的需求可能存在冲突，开发小组的通行做法是召集所有涉众，以确定所有需求，同时解决存在矛盾的需求。2.表示参与者 参与者一般用人形简笔画来表示，即便参与者不是人类时，仍然使用这种表示法。在UML中，可以用带有构造形的类图来表示参与者，将构造形放在位于图标上半部分类名的上方，如下图所示。,3 GIS软件工程用例建模与分析,3.参与者类型 参与者可以分为主要参与者和次要参与者。所谓主要参与者是指主要用户或系统设计时主要面向的实体。主要参与者应具备的关键特征包括：完全位于系统外部，并驱动系统需求；使用系统，以实现某个可观测的用户目标。次要参与者是监督、操作和管理该系统的用户或者实体。扮演支撑角色，以帮助主要参与者实现他们的目标，次要参与者特征包括：次要参与者经常更多地出现在系统的内部而不是外部；次要参与者经常指定很多系统需求，这些需求不能直接从需求陈述中得到。如下面的例子所示。,ActorCustomer,3 GIS软件工程用例建模与分析,报税表可以由纳税人（直接参与者）直接提交，也可以通过Internet或邮寄进行，若是后面一种情况，就需要数据录入员将报税表单中的数据录入系统，数据录入员可视为次要参与者，因为他们帮助报税人处理报税表单。4.参与者与角色 在用例建模中，参与者的精确含义应该是一组角色，个人或其它外部系统都能扮演这些角色。同一个人可以在不同的时间扮演不同的角色，具有相同职务头衔的职员，可以扮演不同的角色以适应业务需求的需要。5.用例 用例描述一系列动作，系统执行这些动作，以产生某个特定参与者能够观察到的结果。即用例是参与者与系统之间对话的抽象，描述可能的交互，而不深入某个场景的详细细节。在UML中，使用带有描述参与者目标标签的椭圆形表示用例。使用直线表示通信链接，将用例连接到一个或多个参与者。如在与ATM系统的交互过程中，客户目标之一是从账户中取款，其用例可表示如下。,3 GIS软件工程用例建模与分析,好的用例应该满足的条件：描述系统执行的一系列事务，这些被执行的事务可为特定参与者产生可度量的结果。从用户角度描述期望的系统行为。使得系统分析使能够从高层次业务观点来理解系统，并为之建模。表示系统提供给外部实体的接口，以及参与者与系统之间的相互关系。6.系统边界 定义了开发中的系统范围，在UML中用矩形表示边界，所有用例都必须放在边界以内。参与者放在系统边界以外，所有用例共同组成了系统的总需求。,取款,参与者、用例和通信链接,3 GIS软件工程用例建模与分析,3.5 用例建模示例 1.ATM系统 ATM通过计算机化银行网络进行账户交易，银行网络包含一台中心计算机，它连接着所有的ATM机和单个银行拥有的银行计算机，每台银行计算机用来处理由其客户请求的交易。在这个例子中，客户Customer是ATM系统的一组参与者。他们操作ATM存款、取款或者检查账户余额等。可以将这些可观察的服务作为用来。,3 GIS软件工程用例建模与分析,ATM Banking System,取款,存款,查询余额,客户,系统名称,用例,系统边界,联系,ATM系统用例模型,3 GIS软件工程用例建模与分析,2.酒店信息系统 考虑简单的酒店信息系统，有两类客户，即团客和散客。前者是旅游承办商提前预定，后者是旅客直接与酒店进行预定。两类客户都可以利用Internet或电话预定、取消、检入和检出房间。基于这些需求，共有4个可观测到的服务可作为用例：预定、取消预定、检入和检出。其用例模型如下图所示。,3 GIS软件工程用例建模与分析,Hotel Information System,预定房间,取消预定,检入房间,检出房间,客户,团客,散客,处理房间预定的职员,接待职员,3 GIS软件工程用例建模与分析,3.6 用例分析技术3.6.1 进行用例分析 在用例分析过程中，通常可以访问客户和系统的典型用户。描述系统的用例是一个实用且非常重要的练习，它有助于识别冗余或不清晰的功能，用例分析有助于解决一些潜在的沟通问题。在以下领域中需要使用用例分析：发现新功能（需求）。在分析系统和深化设计的过程中，新的用例常常可以帮助产生新的需求。与客户沟通。产生测试案例。用例的场景结合还可以提供一个测试套件，并作为形成用户界面的起点。场景是捕获某个用例的某此特定执行。即用例是泛化描述或者是一系列事务的模板，而场景是用例的一个具体实例。,3 GIS软件工程用例建模与分析,3.6.2 用例建模的UML表示法小结 现将用例建模的UML表示法小结如下：,用例：系统执行的一系列事务，通过这些事务，系统产生某个特定用户可度量的结果。,用例名,参与者：用户在与这些用户交互时所扮演的一组角色。,参与者名称,系统边界：物理系统与该物理系统进行交互的参与者之间的边界,系统名称,3 GIS软件工程用例建模与分析,关联：参与者在某个用例中的参与，如参与者的某个实例与用例的某个实例进行通信,泛化：一般用例与较特定用例之间的分类关系，箭头指向一般用例。,扩展：扩展用例与其基本用例之间的关系，指定如何将扩展用例的行为插入到基本用例所定义的行为中去，箭头指向基本用例。,extend,包含：基本用例和包含用例之间的关系，指定为包含用例定义的行为如何插入到基本用例的行为中去。箭头指向包含用例。,include,3 GIS软件工程用例建模与分析,3.6.3 使用关系组织用例 在开发用例模型的过程中，可能会发现有些用例之间包含相同的行为。在有些情况下，除了一些额外的行为之外，有些用例很相似。在上面讲过的ATM系统中，取款、存款和查询余额都要先进行账户登录，因此可以将用户登录作为单独的用例，其它用例可以共享这个用例。在UML中，账户登录与取款和存款这两个用例之间的关系可以用include来表示。,取款,存款,账户登录,include,include,3 GIS软件工程用例建模与分析,在UML中，支持3种用于用例的关系类型：include、extend和泛化。UML构造型是书写在书名号（）中的标签，表示某些超出UML基本定义的语义概念。使用UML构造型，可扩展UML语义，以便支持特定的设计方法或设计师需求。1.include关系 include关系用于两个或多个用例中，以共享事件流中某些公共部分。然后将该公共部分分组并提取出来，形成一个包含用例，在两个或多个用例中共享。2.extend关系 如果两个用例相似，但一个用例比另一个用例所做的事稍多一些，则可以使用extend关系。例如，可以使用一个用例来捕获典型情况（基本用例），然后使用扩展来描述各种变化，使基本用例可以有条件地调用某个用例。即扩展用例向基本用例中添加了一些额外的行为。如取款有一个可能的行为，就是需要处理超额取款。,3 GIS软件工程用例建模与分析,取款,超额取款,extend,3.泛化关系 子用例可以继承父用例中的行为、关系和通信连接。即可以将子用例放置在父用例出现的地方，子用例与父用例之间的关系是泛化关系。例如，假设ATM可以用于支付账单，则它有两个子用例。一为Pay Credit Bill，其一为Pay Utility Bill。,3 GIS软件工程用例建模与分析,4.基本用例与抽象用例 一旦识别出系统的一组用例，就可以找到公共行为，通过提取这些用例的公共行为，就可以形成一个基本用例（具体用例）和抽象用例。前者基本上就是主用例，它可以直接由某个参与者实例化。它本身可实现可观测的用户目标。后则只能由基本用例实例化，因为它只包含在两个或多个用例之间共享部分的公共行为，即从用户角度看，它不是一个完整的用户目标。如前面讲过的账号登录用例，就是一个抽象用例，它不能完成一个完整的用户目标。,PayBill,Credit Card Bill,Utility Bill,泛化关系,3 GIS软件工程用例建模与分析,用例可能还展现多个场景，普通场景以及可能的几个其他场景。基本用例可以用来表示普通场景，而抽象用例则可以用来描述其他场景。下图给出了一个ATM系统的用例模型，取款是一个基本用例，是用户成功登录系统的普通场景，指定交易类型，并输入取款的有效金额。而处理超额属于抽象用例，因为用户的银行账户中可能有足够的钱供其取出。,取款,超额取款,基本用例中的扩展点,参与者可能直接调用基本用例，而抽象用例只能由基本用例实例化。抽象用例的实例化必须返回到调用用例（基本用例），返回位置就是进行调用的那个地方。抽象用例由从其他用例中提取出来的部分组成，抽象用例类似于子程序调用，而基本用例就像是主程序。基本用例用于实现某个用户目标的全部行为，抽象用例实现基本用例的部分行为。,3 GIS软件工程用例建模与分析,ATM System,存款,超额取款,取款,查询余额,账户登录,extend,include,include,include,显示extend和include关系的用例图,只有在定义了所有用例之后，才能识别和提取不同用例中相似的行为，以形成抽象用例。设计师要比用户更加关注抽象用例的提取。用例的组织和流图或数据流图的开发并不相似，用例的组织关注的是用户目标，数据流图关注的是数据的输入与转换。,3 GIS软件工程用例建模与分析,3.6.4 编写用例文档 用例关注系统的外部方面，捕获帮助用户执行任务所需的系统功能和行为。但用例并不能描述系统如何执行功能需求或行为需求。即它用于描述系统用来做什么及谁将使用它，但不描述系统如何执行其功能的详细细节。用例描述了一组动作序列，系统通过这些动作可以产生参与者能够观测得到的结果。用例实例只是用例的一个特定示例（特定系统服务），用例不仅仅有普通场景组成，还可以包括变种场景。这种情况下需要使用extend用例表示这种变种场景。1.开发用例描述：用例图是软件设计师和最终用户之间进行沟通的辅助工具。因此不要在描述中使用计算机行话和用户不熟悉的语言，应该使用用户能够适应和理解的清晰简洁语言，设计师在构造用例时应该关注用户和系统服务。专家建议使用用例模板来描述用例。2.用例模板,3 GIS软件工程用例建模与分析,用例模板捕获不同的信息，包括用例成功执行的主路径，还包括包含于其中的所有其它路径。下面是用例模板的一个示例，常常使用类似下面的模板按照一种标准格式来描述用例。表3.1 用例模板的组件,3 GIS软件工程用例建模与分析,3 GIS软件工程用例建模与分析,3.6.5 优先用例 用例模型不仅对于需求规约非常有用，且对系统开发周期的不同阶段规划工作进度也很有用。根据软件系统的规模，应该首先开发那些在架构上非常重要的用例，其次再开发那些可选的或者重要性相对较低的系统功能。在涉及大型软件系统的开发时，多个用例将并行开发，如何进行最优化用例的调度开发，是一件困难的事情。确定优先用例的指导原则是尽可能早地降低风险和不确定性。下面的因素通常可以提高用例的优先级：用例在架构上的重要性 使用了未经测试的新技术 需要仔细研究的问题 能够比较明显地提高业务处理效率 支持主要业务过程的用例 在确定用例的优先级顺序时需要考虑上述因素。常使用高-中-低模糊方案来为用例的优先级排序。,3 GIS软件工程用例建模与分析,3.7 用例建模与分析过程3.7.1 概论 在进行用例建模和分析前，必须进行背景研究，以获取系统需求，研究业务工作流或该组织已有的计算机系统。用例分析的输入可以是问题描述，或者是采访系统用户之后准备好的业务模型。用例分析的输出是从用户角度描述系统整体需求的用例模型，用例模型包括：用例图、用例描述和用例实用场景三部分。3.7.2 开发用例模型 在进行用例分析之前，必须采访用户，以获取对用户业务活动更好的理解。然后将采访的成果总结成问题描述或业务模型，用例分析是一个包含下列步骤的迭代和增量过程。开发初始用例模型：开发问题描述 识别主要的参与者与用例 创建初始用例图 简要地描述用例,3 GIS软件工程用例建模与分析,使用文本分析来识别/提取候选业务（领域）类 细化用例模型：开发基本用例描述在基本用例描述的基础上逐步求精，并确定extend、include和泛化关系开发实例场景优选用例 上述步骤不一定按顺序执行。3.7.3 开发初始用例模型 初始用例模型提供了系统功能的概貌，可以用作系统的一致需求规约，它可以有效用于规划不同用例开发的优先级。,3 GIS软件工程用例建模与分析,3.7.4 识别主要参与者 在识别系统的参与者时，需要找出以下问题的答案：谁将使用系统的主要功能；谁的日常工作需要系统的支持；谁将使用系统的结果及提交数据；谁将需要维护、管理和操作该系统？系统必须与什么硬件系统交互？系统必须与其它什么计算机系统交互？3.7.5 邮购案例研究 1.开发问题描述 同学们自己看 2.识别主要参与者 主要参与者包括：客户服务助理；订单处理员和库存控制员，并针对,3 GIS软件工程用例建模与分析,每类参与者进行简短描述：如订单处理员描述：订单处理员处理销售单，提交重订请求，向会员请求必要的押金，安排会员的交货事宜。实质上是对每类参与者主要任务的描述。（1）识别用例指南 寻找用例是一个迭代过程，该过程从采访客户（参与者）开始。因客户直接或间接地与系统交互，通常采用自底向上方法，涉及客户描述业务活动的场景。每个这样的描述都可能是一个用例，将这些潜在的用例详细描述、修改、分解成更小的用例或整合到自己更大的用例中去。在从用户那里收集信息时需要注意以下问题：每个参与者完成的主要任务是什么？系统操作和处理什么数据？系统需要解决什么问题？参与者使用本系统想要实现什么目标？当前系统存在的主要问题，预期系统如何简化用户的工作？,3 GIS软件工程用例建模与分析,（2）命名用例指南 用例命名由一个动词和一个名词或名词短语构成。用例名称描述可实现可观察用户目标的描述。如下订单、存款、取款等。3.识别用例 通过检查邮购系统中各参与者的职责，可以识别以下用例：检查订单状态 下订单 处理退货 更新会员关系记录 归档会员关系 注册新会员 处理订单,3 GIS软件工程用例建模与分析,安排交货订购货物接收货物发送货物 完整的初始用例模型如下图所示。,3 GIS软件工程用例建模与分析,邮购系统,检查订单状态,处理订单,下订单,安排发货,处理退货,订单处理,会员关系,更新会员记录,归档会员关系,注册新会员,库存管理,订货,接收货物,发送货物,客户服务助理,订单处理员,库存管理员,初始用例模型,4.创建初始用例图 在大型项目开发中，一般按包组织用例，并按层次结构来组织包。5.描述用例 简单描述每个用例，但在分析用例时，可对用例的简单描述进行扩展，进行详细描述。如订单处理员：订单处理员从已经填好的销售订单中选择订单，系统显示销售订单的详细信息，以及会员的电话号码和地址。在通过电话与会员进行交单之后，订单处理员输入交货日期和时间，系统在给发货小组的发送请求中记录交货日期和时间。识别/细化候选业务类：在为每个用例准备好简要描述后，尝试识别系统的类。对象和类的识别在整个系统的开发生命周期中是一个连续的过程，类模型在生命周期的每个阶段都将得到细化。,3 GIS软件工程用例建模与分析,6.进行原文分析 需要根据每个用例的描述对个用例进行文本分析，以此为基础，产生一组候选类。将这些类包含在领域类模型中，作为初步类模型，以便用于后续类模型开发。下表给出了处理订单用例的文本分析。在简要用例描述中，所有名词和名词短语都被加上了下滑线。,3 GIS软件工程用例建模与分析,扩展初始用例模型：在系统开发生命周期的后续阶段，渐增地扩展初始用例模型。在每个阶段，选取并分析一些用例，以便产生关于必要行为和功能需求的详细描说明。在扩展和分析用例时，识别出公共行为和其它行为。提取这些行为，以形成包含、扩展和泛化用例。确保用例模型更加易于维护，而用例分析中识别出来的类，被用来更新和细化类模型。7.开发基本用例描述 见书上P76的表3-7.根据前面已经介绍的用例模板组件，对某个用例进行详细描述。8.构造用例 在对用例进行详细描述后，发现下订单、注册新会员和归档会员关系3个用例有共同的行为:都要从系统中查找会员记录。因此可以创建“查找会员记录”包含用例来涵盖这个公共行为，修改后的用例图如下所示。,3 GIS软件工程用例建模与分析,邮购系统,检查订单状态,处理订单,下订单,安排发货,处理退货,订单处理,会员关系,更新会员记录,归档会员关系,注册新会员,库存管理,订货,接收货物,发送货物,修订后的用例模型,查找会员记录,include,include,修改后的下订单和查找会员记录两个用例的描述请见P78的表3-8和表3-9。开发实例场景：用例规定了为实现某个系统目标而使用某项系统功能的所有可能的方式。在软件系统开发过程中，需要编写一些示例，来演示某个复杂用例的执行。实现场景更加易于用例理解，并在澄清用例描述的任何歧义方面非常有用。9.优先用例 P79的表3-11给出邮购系统的一些用例的非正式排序。请同学们分析。,3 GIS软件工程用例建模与分析,3.8 使用用例建模分析中的技巧和提示 1.将用例作为沟通工具 在进行用例分析时，每个用例都要是用户能够看到的系统功能，并且用户和系统分析师都要能够理解，确保用例成为用户、领域专家、系统分析师和设计师之间有效沟通的工具。2.寻找正确的用例 为寻找正确的用例，必须首先检查系统目标。用例为参与者提供了一个可观察的值，通过关注参与如何实现系统目标，就能快速地识别出正确的用例。3.校正基本用例的关注点 在识别用例的过程中很容易关注过程，而不是目标。若用例没有产生用户可见的值，即实现目标，该用例就不能作为基本用例。,3 GIS软件工程用例建模与分析,4.好的用例应该是可观察的 不能将外部不可见的内部任务作为用例。5.用例和过程图 不能将用例之间的extend和include箭头误认为是数据流或者控制流的方向。实质上，参与者与用例之间没有任何流。6.在不同上下文中应用原文分析7.使用双向通信关联,3 GIS软件工程用例建模与分析,识别类和关联关系类的属性 使用继承来组织类 为可能存在验证查询提供关联关系类 迭代细化该模型,问题陈述,文本分析,候选类,初始领域类模型,带有属性的类,重新构造类模型,领域分析过程,3 GIS软件工程用例建模与分析,1.准备问题陈述 问题陈述用来描述某领域的通用需求，而非个别应用的特定需求。所以问题描述应该关注领域中对象及其关系的描述，而不是问题域中特殊程序的描述，因为每个组织执行任务的过程是不一样的。使用自然语言书写问题陈述，可能存在歧义和不一致性问题。问题陈述只是领域分析众多输入中的一项，它贯穿整个分析过程，需要使用自己的判断和领域专家的判断来解决歧义和不一致性问题。下面以网上股票交易示例说明如何进行问题陈述：股票经纪公司希望向其委托人提供一种网上股票交易服务，使其委托人能够通过计算机进行交易。委托人先要注册，并要开设一个或多个银行账户。股票经纪公司可以注册一个或多个股票交易所。注册成功后，委托人可以购入和销售股票，并可以实时检查当前价格、买入价、卖出价和股票交易总量。股票价格和交易总量由股票交易所提供，股票交易所是股票列出和成交的地方。当委托人发出某个账户的买单，必须指定,3 GIS软件工程用例建模与分析,股票代码、股票数以及希望支付的最高买价，委托人账户中必须有足够数量的资金。当委托人发出卖单时，必须指定股票代码、股票数和希望出售的最低价位，委托人账户要有足够的股票。委托人可以检查订单的执行状态，在交易日结束之前，委托人都可以发出买单和卖单。所有的买单和卖单都将转发给股票交易所的股票交易系统执行，当订单完成时，应该通过列表的方式返回交易细节。订单将一直在交易系统上执行，直到订单完成或交易日结束。因此交易单可能有三种结果：（1）交易单完成（2）交易单部分完成（3）在交易日结束之前没有执行交易单，订单将被取消。股票交易所一般要求订单中指定的股票数必须是股票手（100股为一手）的整数倍。委托人可以从账户中存入和取出现金或股票。股票经纪公司可能需要为使用由股票交易所提供的服务按月缴纳相应的费用。,3 GIS软件工程用例建模与分析,2.识别对象和类 为了识别对象和类，使用文本分析技术从问题陈述中提取所有名词和名词短语，以便得到可在后续进行详述和细化的候选类。选择类时，没有必要太过细致，对提取的名称或名词短语要认真考虑，是否真正代表了该领域中的某个对象。根据经验，下面类型的名词或名词短语更有可能代表对象：明确的事物（实验室、研究室、工程中心）概念事物（如课程、模块）事件（考试、讲座、测试等）外部组织（研究者、发布者）扮演的角色 其它系统,3 GIS软件工程用例建模与分析,2 GIS软件工程-结构建模与分析,下表列出了从网上股票交易示例问题陈述中提取的名称和名词短语。,该步骤的主要任务是识别领域中的类，应该忽略诸如继承和实现等在后续步骤将要处理的问题，对提取出来的名词或名词短语进行分类。在此基础上，消除一些不适当的类，进一步确定候选类。不适当的类主要包括：表示同一事物的冗余类、与问题没有直接关系的无关类、没有严格定义的模糊类、属性、操作、角色、实现结构。按上述要求，可以找出网上股票交易系统中的一些不适当的类。,3 GIS软件工程用例建模与分析,删除上表中的不适当类后，可以得到下表所示的候选类,3.开发数据词典 在得到候选类之后，需要准备一个数据词典来记录类的定义。对每个类，需要编写一个简短的描述来定义它的范围以及该类的细节信息，比如，属性和操作。数据词典还用于描述类之间的关联关系。在整个开发生命周期中，需要对数据词典不断进行完善和细化。,3 GIS软件工程用例建模与分析,4.识别类之间存在的关联关系 关联关系是对象之间存在的关系，一般通过查找问题陈述中连接两个或多个对象的动词和动词短语就能识别出关联关系。就网上股票交易系统，可以识别如下关联关系。,3 GIS软件工程用例建模与分析,根据领域知识，有以下关联关系：股票交易所列出所有股票 股票在股票交易所的股票交易系统上进行交易 交易单的结果是成交列表 一个股票交易所可以有一个或多个股票交易系统 根据以上信息，可以将系统最初的领域类模型规划如下。,3 GIS软件工程用例建模与分析,Trade order,Execution result,Transaction,Buy order,Sell order,Stock,Stock trading system,Stock exchange,Issuedby,Issuedby,Account,Client,初始领域模型,列出,交易,执行,返回,组成,拥有,3 GIS软件工程用例建模与分析,通过消除不必要和不恰当的关联关系，并根据问题领域知识添加额外的关联关系，以细化关联关系。细化关联关系应遵循如下准则：已消除的类之间的关联关系需要删除；删除不直接与问题域相关的关联关系和只与问题解决方案有关的关联关系。删除所有动作，关联关系用于定义领域类之间的结构关系，而非事件。将三元及以上的关联关系解析为二元关联关系。删除那些根据其它关联关系或者类的属性的条件定义的关联关系。按上述原则，修订后的领域类模型如下图所示。,3 GIS软件工程用例建模与分析,Trade order,Execution result,Transaction,Buy order,Sell order,Stock,Stock trading system,Stock exchange,Account,Client,细化后的领域模型,3 GIS软件工程用例建模与分析,5.识别类的属性和关联关系 属性是类的特性，从问题陈述中发现类的属性一般比较困难，在领域设计阶段，没有必要识别出所有属性，而在详细设计阶段识别属性相对容易。6.利用继承组织类 在识别出大部分的类和它们之间的关联关系后，就可以使用继承来重新组织类。继承为确定类之间的共性提供了有效途径。一般是通过自顶向下和自底向上两个相反的方向方法来识别继承。（1）自底向上方法 利用自底向上的方法，可以比较类的属性，以查找共性。查找具有相似属性、操作和与其它类具有关联关系的类。在上面的例子中，Buy order和Sell order都具有价格和股票数属性，二者均与Stcok类和Account类有关联关系。因此可以定义超类Trade order来涵盖它们共同的结构。在Trade order和Account类之间，以及Trade order和Stock类之间添加关联关系。删除Buy order、Sell order、Account以及Stock类之间的关联,3 GIS软件工程用例建模与分析,关系，这些关联关系可以通过继承以及超类Trade order的关联关系获得。（2）自顶向下方法 主要用于检查某个类是否具有一些特殊的情形，是否有额外的结构性或者行为性需求。自顶向下主要是特化过程。经过上述两个过程修订之后的领域模型如下图所示。,3 GIS软件工程用例建模与分析,Trade order-date-price-number of shares,Execution result,Transaction,Buy order,Sell order,Stock-code-name,Stock trading system,Stock exchange,Account,Client-id-name-address-teph No,0.n,0.n,列出股票,CashAccount,MarginAccount,1,0.n,0.n,1,1,1,1,1.n,0.n,0.n,1,0.n,使用继承进行重新构造并添加属性后的领域类图,3 GIS软件工程用例建模与分析,7.为可能的查询验证提供关联关系类 检验领域内模型的正确性和可用性的一种方法是检查领域类图能否为该领域内其它应用的通用查询提供正确答案。在上例中，委托人经常需要查询账户的当前股票余额，这需要Account类和Stock类之间的关联关系来提供保存在该账户中关于股票数目的信息。因此需要额外添加处理Stock类和Account类之间关联关系的类。,3 GIS软件工程用例建模与分析,Trade order-date-price-number of shares,Execution result,Transaction,Buy order,Sell order,Stock-code-name,Stock trading system,Stock exchange,Account,Client-id-name-address-teph No,0.n,0.n,列出股票,CashAccount,MarginAccount,1,0.n,0.n,1,1,1,1,1.n,0.n,0.n,1,0.n,添加Account类和Stock类之间的关联关系类,Stock Line-number of shares,8.迭代并细化模型 一次就能开发出完善的领域模型可能性非常小，要得到一个合理的领域模型，需要进行多次细化。下面的一些方法可以识别领域模型中可以提高的区域。如果某个类没有属性、操作和关联关系，应考虑删除该类。若某个类具有很多属性和操作，涵盖了很大范围的需求，应考虑将其划分为两个或更多个类。若通过检查领域类模型不能解答某个查询，应考虑添加额外的关联关系类。如在特化和关联关系中存在不对称，应考虑添加额外的关联关系，并用继承重新构造类。若有属性和操作没有宿主类，应添加新的类来存放这些属性和操作。,3 GIS软件工程用例建模与分析,2.10 结构建模和分析过程中的技巧和提示 1.设置图的关注点和上下文 在开始开发类图前，应设置上下文及其服务目标及类图范围，不要尝试将所有的内容都合并到单个类中。2.使用恰当的类名 3.组织好图元素 将图中的交叉线数目减到最少，并将语义上类似的元素靠近放置。4.为图元素提供注释 5.以迭代和增量的方式细化结构模型图 在经历各个阶段的开发时，可以一次次地不断丰富结构模型。如动态模型有助于识别类的职责，可以用于发现新类，实现类和控制类。,3 GIS软件工程用例建模与分析,6.只显示有关的关联关系 在类图中只给出与系统密切相关的关联关系，并隐藏无关的关联关系。并要尝试将所有的关联关系和类合并到一个大的模型中。2.11 使用VP-UML进行领域建模和分析,3 GIS软件工程用例建模与分析,