面向对象分析与设计 课件 第3、4章 系统业务建模、用例建模

第3章系统业务建模学习目标

理解和掌握业务模型中的业务和业务架构等概念，了解业务模型的基本结构和作用

理解和掌握基于UML的业务模型的基本建模方法

理解和掌握业务规则的概念、分类和表示法

理解和掌握业务过程的建模方法第3章系统业务建模业务模型是一种专门用于描述业务结构和业务行为的模型，业务模型与软件模型具有十分密切的关系。建模软件系统时，不论你是否选择一个专门的业务建模过程，理解业务和获取需求都是软件开发过程中不可或缺的工作任务之一。业务建模主要用于描述目标系统在何时、何地、由何角色、按什么业务规则去完成哪些业务活动，以及完成这些业务活动的所需要的步骤或流程。业务模型与软件模型中的功能模型和数据模型在结构、意义和建模方法等多个方面具有很大的相似性。业务建模的方法也不是惟一的，常见的有基于用例的业务建模和基于BPMN的业务流程建模两类方法。本章将在介绍业务模型的基本概念、结构、建模方法和建模原则等问题的基础上，介绍基于BPMN的业务流程建模方法。3.1业务模型今天，经营一家企业比以往任何时候都更具有竞争性。技术尤其是互联网技术所带来的世界经济全球化要求业务人员获取和适应新的业务逻辑。人们发现，不努力改进业务、产品和服务的人很难在这个充满挑战的环境中获得成功。为了保持和维持竞争力，公司和企业必须评估其产品的质量和服务的效率。同时，他们必须考虑他们周围的世界，如他们的竞争对手、分包商、供应商和不断变化的法律法规等。3.1业务模型对于客户，还必须客观地检查产品或服务，并考虑这样一些问题，如公司的内部运作是否顺利？能否改进产品或服务？生产是否能够尽可能地高效？能否扩大产品或服务的组合以开辟新的市场，能否发展新的客户？业务人员还需要评估他们的信息系统是否能够有效地支持他们的工作方式？系统是否容易适应变化吗？信息是企业中重要的战略资源吗？信息是否充分和正确？在今天的市场中，信息系统的作用已经不再是仅仅用于支持企业的业务，它们本身也越来越成为业务系统中重要的组成部分。3.1业务模型为了解决上述这些问题，建立一个能够简单但又十分清晰的业务模型就是十分必要的了。这可以使企业能够排除不重要的细节，关注问题的一个或多个重要的方面。有效的模型也有以用于企业中不同的利益相关者之间讨论问题，帮助他们在关键的基本原则上达成一致，并朝着共同的目标努力。业务模型还可作为其它模型的基础。如支持业务的信息系统，建模是目前分析和设计信息系统的公认的并被成功运用的方法。为了构建适当的软件，软件系统运行的业务也必须按照业务的需要进行建模、理解和改进。3.1业务模型业务模型是对业务系统如何发挥其作用的一种抽象，其具体的细节会根据建模人员的不同而不同。每一个建模人员对同一个问题可能会有不尽相同的理解，这里的问题包括业务的目标、效率以及业务中相互协作的各种业务元素等。这是正常的，任何一种建模方法都不能完全消除这些差异。业务模型将提供的是一个简化的业务结构视图，它将作为业务系统交流、改进或创新的基础，并定义支持业务所必需的信息系统的需求。业务模型并不要求绝对地描述业务或描述业务的每一个细节。3.1业务模型业务模型是围绕业务如何运做或业务操作改进的焦点。演进模型还可以帮助开发人员的构造和集中思想。建模工作能够增加他们对业务的理解，并使有希望使他们认识到新的改进业务新机会。业务系统中，业务的拥有者负责设定业务目标并分配资源，以使业务运行。业务建模人员负责创建业务的结构、设计流程，并分配资源以实现业务目标。最后，系统开发人员负责适应、设计或开发适当的支持业务运行的信息系统。3.1.1业务的概念所谓的业务（Business）或企业可以看成是一个具有其特定目标的，由多种资源构成的复杂系统，其各个资源或过程之间相互作用向前运作，以实现其特定目标。事实上，业务是对企业、组织等概念的一个抽象。具体地说，任何一个企业、组织、或者企业或组织中的一个特定部门都可以看成是一个业务，业务也可以称为企业或业务系统。3.1.1业务的概念业务具有如下基本特点。1）业务系统是一个与环境密切相关的系统。任何一个业务都不是一个孤立存在的系统，它们通常会与环境或其它系统中的决策或事件相关联并接受其影响，因此孤立地分析一个业务系统是没有意义的。因此，有时定义一个业务系统的边界往往是很困难的，而且，有时某项资源的目标也可能不符合业务系统的总体目标。3.1.1业务的概念2）业务系统是一个开放的系统。业务系统中的许多重要要素，如客户、供应商、法律和规则等，既不是属于业务系统内部，也不是业务系统本身定义的。因此，业务系统必然是一个开放的系统，其组成对象或组成成分通常也是其它业务系统的一部分。3.1.1业务的概念3）业务是一个有着明确目标的系统。对于业务系统来说，不仅是系统本身要有明确的目标和结构。系统中的每项单独的业务也都有其各自不同的业务目标和内部结构。这使得可以使用相似的概念来描述它们的结构和操作。总结上述特点，可以知道业务具有环境相关性、开放性和目标性。3.1.2良好的业务架构由于业务系统的复杂性、模型抽象性、以及建模过程中各种复杂因素带来的复杂性等方面的原因，这些都使得建立的业务架构模型本身也具有了多种不同的可能性。因此，评价一个模型并不是一件简单的事情。简单地说，好的业务模型应具有较强的抽象性，即能够将业务抽象成多个不同的侧面，允许人们每次只通过其中的某个侧面独立地观察系统。以更好地帮助建模人员理解系统，从繁杂的现象中抽象出问题的本质，抑制无关紧要的细节和信息。3.1.2良好的业务架构具体地说，一个好的业务架构模型应具有如下一些特点：1）尽可能真实、正确地捕捉业务。定义的业务架构应该是现实可行的、易于实现、有助于实现业务目标。2）在适当的抽象层次上关注业务的关键流程和结构。其中的适当抽象层次将因具体的业务的实际情况的不同而不同，通常取决于体系结构的用途。3）代表了系统中运作业务的人员的共识。4）具有良好的适应性，易于变化，易于扩展。5）易于理解，并能够促进不同的利益相关者（stakeholders）之间的沟通。架构只有在用户能够理解的情况下才有用。3.1.2良好的业务架构实现上述这些目标并不简单。它需要满足下列的几个条件：1）建模人员应具有高水平的业务知识或至少能访问到具有这种知识并且参与构建架构模型的人员。2）使用合适的建模语言以捕获重要业务概念及其之间的关系。这个语言应既可以用于捕获系统的静态结构，也可以用于捕获系统的动态行为。这个建模语言要足够简单以便于不同的人理解，但又不会失准确和表现能力。建模语言还必须是可伸缩的，以便可以在不同的层次上描述事物。3.1.2良好的业务架构3）具有将模型组织成多种不同的业务视图的能力，并以此说明业务的不同侧面。这是因为一个业务的完整描述不可能只在一个单独的视图中定义。4）在做什么和不做什么的选择问题上，使用基于经验的设计。可能的情况下，可以使用那些已经被证明是行之有效的具有良好定义的建模模式。5）使用能够确保模型质量和准确性的开发过程。不论如何，架构建模都需要使用一种公众能够接受的语言表达。目前公认的业务建模方法就是使用UML的过程建模和面向对象模型来构建业务模型。3.1.3业务模型的基本结构业务模型是一种用来描述业务系统的目标、结构及其功能的模型，用于描述业务系统的结构、功能及其运作情况。业务模型的具体内容包括对系统的目标和资源，以及为实现这些目标而定义的业务过程和这些过程必须满足的约束等方面的描述。为了更好理解业务模型，下面给出一组与业务相关的概念，这些概念及其相互关系构成一个完整的业务系统的概念模型。3.1.3业务模型的基本结构1.业务模型的基本概念(1)资源（Resources）资源是业务系统内部使用或产生的人员、原料、信息或产品等对象。这些对象被按照它们之间的相互关系安排在系统内某个特定的结构中。资源可以分为物理、抽象和信息资源等多种类型。业务系统通过其业务过程支配（如使用、消耗、精化或生产等）这些资源。3.1.3业务模型的基本结构1.业务模型的基本概念(2)业务过程（Businessprocess）业务过程也可称为业务处理，是业务系统中用于改变资源状态的活动。用来描述业务系统中的任务是如何完成的，业务过程要受到业务规则支配和制约。(3)目标（Goals）目标即系统的目的，是指整个企业正在为之努力而期望得到实现的结果。一个目标可以分解成多个子目标，并分配给业务系统的各业务过程或资源。目标可以被看成是期望的资源状态，并通过业务过程加以实现。目标可以表示成一个或多个业务规则。3.1.3业务模型的基本结构1.业务模型的基本概念(4)规则（Rule）规则是指用来定义或约束业务的语句，可用于表达业务知识。业务规则决定了业务的运行方式和资源结构的构造。规则可以是系统外部定义的法律法规，也可以是业务系统内部为实现某个特定目标而定义的。规则可以分为功能性、行为性和结构性三种规则。所有这些概念都是相互关联的：如规则可以影响某些资源的构造方式；资源被分配给一个特定的业务过程；目标有与特定的业务过程的执行相联系。3.1.3业务模型的基本结构2.业务结构的概念模型业务结构的概念模型指描述业务系统中的概念及其相互关系。图3-1给出了一个用类图表示的概念模型。它也可称为业务模型的元模型。这个模型清晰地描述了业务相关的概念，以及这些概念之间的相互关系。仔细解读图中的概念及其相互关系，将能够有效地加深对业务模型的理解。3.1.3业务模型的基本结构图3-1业务模型的概念模型

3.1.4业务建模的主要动机业务系统本身的复杂性导致了业务模型的复杂。企业（Business)通常是一个由具有层次组织的部门及其职能（function）组成的复杂系统。其中的业务过程也并不仅仅局限于某个特定部门，而有可能横跨多个部门。另一方面，由于建模人员和建模工具等多种因素的限制也导致了模型的局限性。这使得任何业务模型都不可能是准确和完整的描述一个企业。3.1.4业务建模的主要动机现实世界中发生的变化也会影响模型的创建和使用，这会使模型中的某些内容不再完全有效。还有，在实施过程中，模型也可能会受到系统中管理人员或员工的抵制。模型的复杂性决定了任何一种业务建模都不可能也不应该是漫无目的的，而应该是目标驱动的。人们总结出理解业务、信息系统支持、业务改进、业务创新和设计新的业务流程等五种业务建模的动机。3.1.4业务建模的主要动机1.理解业务理解业务是最基本的建模动机。业务建模能够有效增强人们对业务的理解和促进关于业务的交流。可视模型比文本描述或没有描述更容易理解和讨论，它既可以增强建模人员对业务的理解，也可以改进业务本身。建好的业务模型还可以用于人员培训。2.支持信息系统开发信息系统时，不一定需要业务建模。但以业务建模为基础的信息系统将在业务支持、可集成性、可维护性、可重用性等多个方面更具有不可比拟的优点。3.1.4业务建模的主要动机3.业务改进业务改进的基本技术是业务流程改进（BPI，BusinessProcessImprovement）技术，这是是一种通过对当前业务进行建模和分析，以便改进或获得改进的机会的技术。4.业务创新业务创新是指分析当前的业务和在模型中寻找新的工作方式。创新将会使业务模型及其流程发生显著变化，以创建不同的和改进的流程。与业务改进相比，创新对实施的要求更高。创新也比改进具有更大的风险，但创新的成功会使企业在效率上获得更大的收益。3.1.4业务建模的主要动机5.设计新的业务过程希望为企业增加新的业务流程时进行的建模活动。为了试验新的业务概念如何适应当前模型，业务建模可以用来创建新的业务模型，而不是建模以前业务的一部分。用以确定当前组织、资源和信息系统是否可以很容易地使用或适应新流程。6.业务流程再造业务流程再造（BPR，BusinessProcessReengineering）也可以看成是业务创新的极端形式。业务流程再造指的是放弃原有的业务过程或业务规则，建立全新的业务流程，即对原有的业务系统进行彻底的变革；不同的动机给出了业务建模的不同的目的，也隐含的不同的业务建模的范围和方法。必要时，可根据业务的实际情况开展不同的业务建模活动。3.2业务建模方法除了面向对象方法以外，当然有其它一些创建业务模型的方法，如IDEF0。有时人们甚至使用文字叙述的描述方法。所有这些方法中，UML是一个具有良好定义标准并可由许多工具支持的软件建模方法，也是目前应用最广泛使用的业务建模方法。3.2.1UML与业务建模使用面向对象方法建模业务系统具有如下一些优点。1.使用了与对象模型相似的概念业务系统概念模型将业务系统抽象成一组具有特定目标的过程，每个过程使用了不同的资源，并通过这些资源之间的相互协作来完成其特定的目标。规则定义了过程和资源实现其目标是需要遵守和满足的条件和约束。通过面向对象建模技术，可以将业务系统中的概念映射到对象模型中，如对象、关联以及对象之间的交互。3.2.1UML与业务建模2成熟的技术多年的实践证明，面向对象建模和程序设计技术能够更好地处理大型的复杂系统。面向对象领域中出现的新技术，如各种模式，可以为业务建模提供许多现成的借鉴。3.标准的符号体系任何建模方法都需要一个标准的符号系统和功能完善的工具。统一建模语言（UML）提供了一个通用并可扩展的符号系统，这使得扩展UML并将其应用于业务建模是一个可行的方法。并且这样的方法也为业务需求的可连续追踪提供了现实的可能性。3.2.1UML与业务建模4.易于学习使用相同概念描述一个业务系统及其支持系统是面向对象方法最重要的优势。这就与面向对象模型减少了分析、设计与实现之间的语义鸿沟一样，面向对象同样可以有效地缩小业务人员与软件开发人员之间的差距。5.为观察业务系统提供了新的、更简单的方法。传统的观察和描述一个组织的方式通常不能说明业务是如何执行的。如传统的组织结构图不能描述横跨业务部门并影响业务中的许多功能的业务过程。而面向对象技术可以很容易地描述这些传统的组织结构及其相关的过程。3.2.2UML的业务扩展UML的主要用途是对软件系统的体系结构进行建模，虽然软件和业务系统之间有很多相似之处，但也存在一些差异。业务系统的很多概念，这些概念从来就不是用于或适合于在程序中执行的，如业务系统的人员、设备、以及驱动业务过程的规则和目标等。因此，使用UML进行业务建模，就必须对UML进行必要的扩展，以便能够更清楚地识别和表示业务系统中的目标、资源、过程和规则等重要概念。3.2.2UML的业务扩展1.业务过程执行语言（TheBusinessProcessExecutionLanguage，BPEL）业务过程执行语言（TheBusinessProcessExecutionLanguage，BPEL），是一种符合OASIS标准定义的执行语言，其根本特征是使用了含有Web服务的业务过程。BPEL业务过程仅使用Web服务接口导入和导出信息。OASIS是结构化信息标准促进组织（TheOrganizationfortheAdvancementofStructuredInformationStandards）的英文缩写,该组织是一个全球性的非盈利组织，该组织致力于物联网、能源、内容技术、应急管理等领域的开发、融合和采用等方面的安全标准。3.2.2UML的业务扩展1.业务过程执行语言（TheBusinessProcessExecutionLanguage，BPEL）BPEL把Web服务之间的交互分成两种类型，一种是业务系统中参与者之间的实际交互，称为可执行业务过程。另一种是并不期望被实际执行的业务过程，称为抽象业务过程。与可执行过程相比，抽象过程可能会隐藏了一些必要的具体操作方面的细节。抽象过程充当了一个可能带有多个用例的描述性的角色，这包括了它的可观察的行为以及过程模板。3.2.2UML的业务扩展1.业务过程执行语言（TheBusinessProcessExecutionLanguage，BPEL）BPEL的目的是使用过程规范语言描述过程的行为，它扩展了Web服务交互模型，并使之能够支持业务事务。它还定义了一个可互操作的集成模型，这个集成模型应有助于扩展企业内部及企业之间自动化过程集成。在建模语言的发展过程中，BPEL发挥了重要的基础作用。随后出现的多种模型，如BPMN模型等，都是在此基础上定义出来的。3.2.2UML的业务扩展2.业务过程模型符号（BusinessProcessModelandNotation,BPMN）业务过程模型符号（BusinessProcessModelandNotation，BPMN）是一种由业务过程管理倡议组织（BPMI）于2004年5月发布的业务过程模型符号标准。从2005年BPMI与OMG两个组织合并开始，BPMN转由OMG组织维护和管理。到目前为止，已发布了BPMN的1.0、1.1和2.0多个版本。3.2.2UML的业务扩展2.业务过程模型符号（BusinessProcessModelandNotation,BPMN）BPMN的目标是通过为业务人员提供即直观又能够表达复杂的过程语义的符号，支持技术人员和业务人员进行业务过程管理。BPMN规范还提供了图形符号和执行语言的底层结构之间的映射，特别是到业务流程执行语言（BPEL）的映射。BPMN的主要目标是为企业中所有相关者提供一组易于理解的标准符号。这些利益相关者包括负责创建和完善流程的业务分析人员、负责实现它们的开发人员以及监控和管理它们的管理人员。因此，BPMN也被看成一种公共语言，用于桥接经常发生在业务过程设计和实现之间的交流鸿沟。目前，到多数的UML工具软件均给出了这些标准的具体实现。这也为也建模的广泛应用提供了良好的条件。3.2.3业务过程模型对于业务模型，最主要的扩展就是对业务流程的扩展，扩展的方式就是提供了业务流程图和模型元素两个层次的扩展。1.业务流程图（BusinessProcessDiagram）业务流程图（BusinessProcessDiagram）是一种以UML类图为基础定义的扩展图，其内容可以包含系统的目标、资源、业务过程和业务规则等所有的业务概念，可以从总体上描述一个业务系统的结构。可以说业务流程图是业务模型中最重要的一种图。业务流程图中可以使用模型元素包括业务过程、资源对象和业务规则以及这些模型元素之间的各种关系等。3.2.3业务过程模型1.业务流程图（BusinessProcessDiagram）业务过程（BusinessProcesses）是业务流程图中最重要的模型元素，表示特定的业务过程。业务过程通常与一系列资源对象相关联。同时，由于业务过程本身也是一个活动集合，因此也可以使用UML活动图建模业务过程的具体细节。3.2.3业务过程模型图3-2业务流程示例3.2.3业务过程模型1.业务流程图（BusinessProcessDiagram）例如，图3-2给出了一张业务流程图示例，图中的图书在线销售（Sellbookonline）和顾客订单管理（managecustomerorder）就是两个业务过程。它们是这张图的核心元素。其中，用户请求（UserEnquery）和客户订单（CustomerOrder）是两个业务事件，分别用于触发这两个相应的业务过程。接受客户订单（TakeCustomerOrder）和配送订单（Shiporder）分别是这两个业务过程的目标。图中的WEB页（Webpages）、图书目录（Bookcatalogue）和运输公司（shippingcompany）分别是这两个业务过程的三个支持对象。库存（WarehouseInventory）则同时是这两个业务过程的输入对象。订单(Order)和付货单（DeliveredOrder）则分别是这两个业务过程的输出对象。整个图在较高的抽象层次上，完整地表达了一个企业的业务流程。3.2.3业务过程模型2.业务过程（ProcessSteps）与UML活动图中的活动一样，业务过程也可以是嵌套（nested）的活动。可以将每个业务过程分解成多个业务过程或活动。每个这样的业务过程或活动都可以看成是业务过程的子过程。这意味着业务过程是可分解的，即一个业务过程还可能蕴含则更多的子过程。3.2.3业务过程模型2.业务过程（ProcessSteps）图3-3给出了一个嵌套的业务过程的例子。图中展示了一个名为Process1的业务过程，该过程定义了一个由三个步骤构成的业务过程，其中前两个步骤是原子过程（Activity1和Activity2），最后一个步骤则是（Process2）一个包含了两个原子过程（Activity3和Activity4）的过程。3.2.3业务过程模型2.业务过程（ProcessSteps）图3-3嵌套的业务过程3.2.3业务过程模型2.业务过程（ProcessSteps）按照业务活动在业务过程的作用，可以将业务活动划分成直接、间接和质量保证等三种类型。直接活动是直接参与产品或服务创建的活动，产品或服务是业务过程创造的价值；间接活动是支持直接活动的活动；包括维护、管理和计划等活动；质量保证活动是保证其它活动质量的活动，如检查、控制、评价和审查等活动。分类这些业务活动，显然也是业务建模工作内容之一。3.2.3业务过程模型2.业务过程（ProcessSteps）这样的分类也导致了对业务过程的分类，如主营业务、支持业务和质量保证业务这样的分类。业务过程还可以以其它方式进行分类，如开发、改进或管理过程这样的分类。活动图中的接收（Receive）和发送（Send）等动作也可以出现在业务流程图中，分别表示接收和发送业务事件这样的特定动作。发送表示生成和发送事件；接收表示正在等待特定事件的发生，以触发特定的业务事件。图3-2中就使用了用户请求（UserEnquiry）和顾客订单（CustomerOrder）这两个这样的接收动作。3.2.3业务过程模型3.目标（Goal）业务流程图中，除了表示业务过程这样最重要的模型元素之外，比较重要的元素还有业务过程的目标。它们可以被表示成带有《goal》构造型的UML类（或对象）。目标对象表示特定业务过程的目标，可使用指向目标的并带有构造型«achieve»的依赖与特定过程相连，以表示进程试图实现的目标。图3-2中包含也多个这样的目标元素。与目标相联系的是目标的分解和实现目标需要解决的问题。则可以使用业务模型中的目标/问题模型描述。3.2.3业务过程模型4.资源对象（Resource）业务流程图中，同样重要的模型元素是表示业务资源的业务对象，它们被表示成带有《business》构造型的UML类（或对象）来表示。目标对象表示特定流程的目标，可使用指向目标的并带有«achieve»构造型的依赖与特定过程相连，以表示进程试图实现的目标。3.2.3业务过程模型4.资源对象（Resource）资源对象可以按照资源类型分成：输入对象、输出对象、供应对象和控制对象等多种类型。可以用«physical»，«abstract»，«people»或«information»等构造型标识这些资源对象的具体类型。输入对象是业务过程消耗或加工的对象。它们与从对象到业务过程的带有《input》虚线连接表示输入。与此类似，输出对象（过程生成的对象）、供应对象（参与了进程但并没有被加工或消耗的资源对象）、以及控制对象（控制或运行业务过程的资源对象）等也都使用了类似的表示。3.2.3业务过程模型4.资源对象（Resource）通过对输入对象进行的加工，业务过程将改变输入对象的位置、外观、内容或所携带的信息。有时，很难将输入对象与供应提供对象严格地区分开来，因为在业务过程中，供应对象也可能会改变它的状态。本质的区别是：输入对象是关键对象，该对象被加工或消耗，以便生成输出对象；供应对象只是业务过程所需要的对象，它参与了业务过程，以便能够执行这种加工或消耗。例如，在制造过程中，原材料是输入对象，业务过程中使用加工设备则是供应对象。3.2.3业务过程模型4.资源对象（Resource）另外，输出对象与输入对象可能具有相同的类型，但具有从过程中产生的附加值。用于描述资源对象及其相互关系模型叫做资源模型（ResourceModal），显然，资源模型也是业务过程模型的辅助模型。它们与业务过程元素之间具有多种不同的关联或依赖关系。这些关系包括：输入（input）、输出（outout或outcome）、支持（support）和使用（use）和控制（control）等多种类型。3.2.3业务过程模型5.业务事件（BusinessEvents）从系统的角度来说，事件是指系统内部或其环境中发生的某件事情。对于业务系统来说，业务事件则对系统内业务过程有影响的事件。特定的事件将激活某个特定业务过程。所以，业务事件也可以视为出发或控制业务活动运行的触发器。业务事件对业务过程的影响可以分成触发业务过程、影响业务过程的行为和执行方式以及结束或中止业务过程等三种方式。3.2.3业务过程模型5.业务事件（BusinessEvents）对于业务过程来说，业务事件的来源并不重要，重要的是业务过程如何响应这些业务事件。很多最重要的业务事件通常都来源于企业的外部过程，如来源于用户的订单、支付、投诉，来源于分包商的交货和发票，或来源于竞争者的产品发布和降价等过程生成的事件。有时，需要分析事件的属性和行为特征时，可以使用类图描述来这样的情况。业务模型中，使用带有构造型《BusinessEvent》的类（或对象）表示业务事件。并使用泛化描述业务事件的层次。3.2.3业务过程模型5.业务事件（BusinessEvents）如图3-4就给出了一张用于描述一组业务事件的类图，图中使用泛化表示了这些业务事件之间的层次关系。图3-4业务事件及其层次关系3.2.3业务过程模型6.概念建模（ConceptualModeling）概念模型定义了业务系统中使用的重要概念及其相互关系。为业务系统建立了一个通用的词汇表。通过概念模型，避免不同的人对这些概念的不同理解和解释。在概念模型中，用于描述对象的名词术语、概念和现实世界中的对象之间往往是有差距的（理论上被称为Ogden三角）。建模时应注意它们之间的差别。3.2.3业务过程模型6.概念建模（ConceptualModeling）例如，形式地看，文本出现的汽车这个词汇只是名词术语；当需要考虑如何准确地定义或说明汽车这样一种事物时，考虑的就是如何定义一个概念，你可能把它定义成一种与发动机、汽车底盘和车轮相联系的一种交通工具；当需要考虑汽车的结构、性能和行为等方面的特征时。汽车这个词指的可能就是一个类，此时可能要考虑的是汽车的种类、它应该有哪些属性、及其它还要有哪些方法之类的东西。3.2.3业务过程模型6.概念建模（ConceptualModeling）与类模型相比较，概念模型应该是一种更高层次的抽象。业务模型中，虽然使用类图描述概念模型，那只不过是将概念模型表示成类图而已。可以使用标准的UML类图来表示概念模型。在这样的概念模型中。可以使用类图模型中的各种元素表示业务系统中的概念和概念之间的各种关系。3.2.3业务过程模型6.概念建模（ConceptualModeling）使用类描述某个概念时，可以在类的标准文档属性（如Document或Specification属性）中使用文本来描述这些概念，也可以为概念添加必要的属性（feature）来描述这个概念所具有的某方面的特性，这样就可以为概念提供一个准确的描述。随后，为这些概念定义的名字就可以被描述业务的其它模型或文档引用了。需要注意的是，一张类图并不一定能描述了所有的概念及其相互关系。事实上，一个完整的概念模型可以被建模在多张类图中。实际上，在建模过程中，随时都有可能向模型中加入新的概念和关系。3.2.3业务过程模型6.概念建模（ConceptualModeling）需要指出的是，概念模型中的类属性和类操作并不像描述软件类的类图中的那么重要。概念模型关注的是准确地捕捉这些概念以及它们之间的相互关系。如果属性和操作有助于刻画这些概念，当然可以将它们添加到相应的概念中。总之，一个完整的业务模型中可以包含多种不同的模型，其核心要素是描述业务系统的目标、过程、资源等概念，以及定义在这些概念上的业务规则。典型的业务模型包括业务过程模型、目标模型、资源结构模型等。实际建模一个业务系统时，可根据需要建立能够满足建模目的的业务模型。3.2.4软件模型与业务模型之间的关系目前，多种软件开发方法过程都提倡使用统一建模语言建模一个软件系统，当建模一个与业务密切相关的软件时，软件模型中的概念、关系、规则和约束够不可避免的与其环境的业务是密切相关的，及时建模的软件不是业务相关的软件时，软件建模时，所要用到的建模方法和建模技术与业务建模有着很多的可借鉴之处。对于软件模型来说，模型中所描述的对象、过程以及附加在这些要素上的约束和限制通常源自于软件所支持的业务。很多时候，软件系统与其业务系统之间并不存在一个十分严格和清除的界线。软件建模过程中的很多工作，实际上也可能就是在进行业务建模。3.2.4软件模型与业务模型之间的关系大多数的软件开发过程都是从用例建模开始的，用例描述了一个或多个参与者与系统之间的交互，用例建模的目标是识别和描述参与者与系统之间交互的所有用例。然后使用建立的用例模型分析和设计一个健壮的系统架构来实现这些用例（即所谓的用例驱动开发）。这导出的问题是如何获取这些用例，或者说如何获取能够正确地支持系统所运行的业务的正确用例。一种有效的方法是对系统的环境进行建模以增进对面临的问题的理解。3.2.4软件模型与业务模型之间的关系这样的业务环境建模需要考虑的问题包括：参与者之间是如何交互的？哪些活动是他们工作的组成部分？他们工作的最终目标是什么？哪些相关的人、系统或资源没有被表示成这个系统的参与者？哪些规则支配和控制了他们的活动和结构？有能够让参与者更有效的工作方式吗？3.2.4软件模型与业务模型之间的关系这些问题的答案显然应来自于业务系统，并超出了当前正在构建的信息系统的功能范围（使用用例建模以外的技术）。所有软件系统的最终目标都是对其部分业务提供正确和广泛的支持。然而，当建模信息系统环境中的东西时，就不再是构建软件模型了。而是进入了业务流程建模的世界。3.3业务规则一条业务规则可以被表示成一个语句，即可以使用这些规则去控制或影响业务过程的执行，也可以使用他们控制业务系统中的资源。每个语句都需要指定必须满足的或控制下一步活动的条件。业务规则可以用于表示业务目标、指定业务过程的执行方式、详细说明模型中的关系应满足的条件或约束资源的使用方面的行为。业务系统（或企业）通常要受到关于规范运作和资源结构的业务规则控制，业务规则可以确保企业按照预定的外部限制（例如法律或法规）或内部（例如，为了使业务尽可能高效和盈利，并实现业务目标）目标的条件下进行运作。业务规则支配了业务系统的策略、术语、定价、定义和配置，并影响业务流程、组织结构和业务行为。规则可以在较高的战略级别上定义，也可以用于表示某个特定的信息系统的详细需求（需求可以根据规则指定，或者规则可以对系统产生一定的需求）。3.3业务规则业务规则可以定义成：对必须满足的政策或条件的声明、单位业务知识或定义或约束业务某些方面的语句。定义业务规则的目的是维护业务结构，或者控制或影响企业的行为。规则即存在于业务模型，也存在于软件系统模型，并且是业务系统与信息系统所支持的支持技术之间的集成点。支持系统的设计就可能要使用并且实现来自于业务模型中规则的大量信息。业务知识和策略则要映射成可执行系统中实现的规则，这保证了这些规则不会被违反。3.3业务规则例如，图3-5给出了一张描述了某金融系统结构的类图。其中，客户（Customer）表示这个系统的客户对象。证券（Portfolio）表示某个客户的全部有价证券的集合。证券（Portfolio）对象是由客户的所拥有的所有现金账户（CashAccount）、股份（Holding）和订单（Order）等有价证券聚合对象。其中，每个股份（Holding）对象都包含一个有价证券（Security）对象。有价证券（Security）对象又可分为债券（Bond）和股票（Stock）有两种类型，并且有价证券（Security）还被定义成一个递归形式的组合（Option）。图3-5某金融系统的结构模型3.3业务规则这意味着，每个股份（Holding）也是一个由股票和债券构成的组合，它代表了客户所持有的一个股份。图中的关联和聚合等关系描述了这些类和对象之间的关系。3.3.1派生规则（Derivations）派生规则是专门用于描述知识或信息的形式转化的业务规则，即如何根据信息得出结论的业务规则。派生规则可以是一个计算规则，也可以是一个推理规则。例如，对于图3-5中的客户对象来说，“保证金高于投资组合的贷款总值的90%的客户是高风险的”这样一个业务规则就可以被视为是一个派生规则。建模时，可以直接使用自然语言描述，也可以使用OCL表达式类进行描述。3.3.1派生规则（Derivations）下面的OCL表达式就提供了这样一个描述。contextCustomer::highRisk():Booleanpost:result=possession.margin()>0.90*possession.loan_value()这个表达式被表示成Customer类中highRisk()方法的后置条件，事实上，这个业务规则也隐含了这个方法的实现方法。3.3.1派生规则（Derivations）如图3-6以注释的形式描述了Customer类中的HighRisk（）方法需要满足的后置条件约束。图3-6派生规则的建模实例3.3.1派生规则（Derivations）下面的OCL表达式就提供了这样一个描述。contextCustomer::highRisk():Booleanpost:result=possession.margin()>0.90*possession.loan_value()这个表达式被表示成Customer类中highRisk()方法的后置条件，事实上，这个业务规则也隐含了这个方法的实现方法。3.3.2约束（Constraint）约束规则是用来约束对象或过程的可能结构和行为的规则，即描述对象的关联方式或状态变化的方式的规则；约束指用于支配资源对象的可能结构或业务过程的可能行为的业务规则，即指定资源之间的关联方式、资源或业务过程发生状态变化的可能方式等。约束主要用于维护对象的完整性。当创建对象或对象之间的关系发生变化时，控制对象或过程的行为。根据业务规则的适用对象的不同，约束还可以分为结构性、操作/行为和刺激/响应等三种类型。3.3.2约束（Constraint）1.结构性规则（StructuralRules）结构性规则（StructuralRules）主要用于类型和关联，用于指定与结构有关的必须保持为真的条件，通常称为类不变量。结构性规则有助于定义业务的结构相关不同术语，主要用于表达业务系统的静态方面。有些结构性规则可以直接通过类图中的类和关联的多重性定义，而不需要附加新的约束。例如，图3-6中的客户类（Customer）与证券类（Portfolio）之间的关联关系及其多重性，就已经描述了这两类对象之间应有的结构约束。对这样的情况，就没有必要再附加新的约束了。3.3.2约束（Constraint）1.结构性规则（StructuralRules）对于不能用UML图直接表示的结构性约束，则必须给出明确的指定。例如，对于图3-7中的表达式{refer_to.oclType<>Option}为Option类上的关联referto指定了“选项对象（Option）不能引用其它选项（Option）对象”这样的一个约束。3.3.2约束（Constraint）1.结构性规则（StructuralRules）图3-7选项类上关联的约束3.3.2约束（Constraint）1.结构性规则（StructuralRules）表示这个约束的完整的OCL表达式如下。contextOptioninv:refer_to.oclType<>Option如果将规则改成“选项可以引用其它选项，但不能引用自己”，则这个规则就可以表示为下面的OCL表达式。contextOptioninv:refer_to<>self3.3.2约束（Constraint）2.操作或行为约束（Operational/BehavioralConstraints）对操作或行为的约束主要指操作的前置条件和后置条件。它们规定了对象在操作执行之前或执行之后必须满足的条件，它们限制了状态变更可能发生的方式，以及执行操作的对象如何受到操作的影响。前置条件表示了操作将正确地执行需要的约束；后置条件保证正确的操作结果。3.3.2约束（Constraint）2.操作或行为约束（Operational/BehavioralConstraints）例如，对于图3-5中的订单类（Order），要求其putOnMarket操作在执行前应处于“created”状态，并且在执行后处于“onMarket”状态。这样的约束也可表示成如下表达式。contextOrder::putOnMarket():voidpre:state=#createdpost:state=#onMarket3.3.2约束（Constraint）2.操作或行为约束（Operational/BehavioralConstraints）例如，图3-8就描述了这个业务规则。图中的两个状态Created和onMarket以及它们之间的迁移共同定义了操作putOnMarket()的前置条件和后置条件。图3-8带有操作或行为规则的状态图3.3.2约束（Constraint）3.刺激或响应约束（Stimulus/ResponseConstraints）刺激或响应规则用于指定业务系统中发生某些事件时应执行的特定操作。由于OCL是一种陈述性的语言，因此不能用于定义动作。更好的方法是，使用带有动作的活动图或状态图来定义这类规则。在活动图或状态图中，可以使用刺激或操作的事件部分指定UML模型中的守卫条件，而且图中的动作也可以被指定为动作或状态迁移的规格说明。3.3.2约束（Constraint）例如，图3-9所示的活动图中，使用了用OCL表达式编写的动作迁移的守卫条件。图3-9带有刺激或相应规则的活动图3.3.3存在性规则（Existence）存在规则描述某个事物在什么情况下可以存在及其何时开始存在的规则。存在性规则表示的是特定对象可以存在的条件，这类规则通常是类模型的固有成分。存在性规则可以表示为一个类不变量。例如，对于图3-10中的Option类的对象来说，“到期日期（expirationdate）小于当前日期”就是一个关于Option对象的存在性约束。3.3.3存在性规则（Existence）图3-10存在性规则3.4业务过程的建模方法本节将讨论如何为一个办公用品销售公司的业务系统进行建模，建模的目的是公司要建立一个“网络销售系统”，以改善公司的经营状况。该公司是一个办公用品销售公司，主要向其它组织或部门销售办公设备和办公用品，销售范围包括传真机、复印机、电脑、计算机软件和办公耗材等各种办公设备和用品，并提供附加的安装、调试、维修和维护服务。近年来，基于互联网的业务系统的出现和发展，该公司的销售受到了极大地影响。因此，公司决定开发一个基于互联网的网络销售系统以更好地支持其主营业务，现在要做的是为这个网络销售系统建立一个业务模型，以便为其提供必要的业务需求。需要注意的是，这个业务模型的建模目的是为软件系统的定义需求，而不是实际构建这个特定的软件系统。建模这个业务模型的最终结果是获得一个需求规范，它将作为构建支持软件系统的输入。3.4.1定义业务系统的目标表达任何一个业务或企业的愿景或目标都需要建立一个包含了与业务相关的关键概念的概念模型。并以此为基础定义业务的愿景或目标。1.愿景陈述公司的愿景陈述如下：公司的目标是成为办公设备和用品的主要供应商。公司可以根据客户需求提供整体性的解决方案。由于不通过零售环节，因此可以大幅度地降低销售成本和价格，并且为客户提供附加的服务。新系统应该将公司的销售流程和客户的采购流程结合起来，从而可以有效地进行交流和交付。为了能够集成这些过程，系统还需要提供了多种不同的外部接口，如Internet、电子邮件、FTP、电话和传真等。此外、系统还应该提供进一步的额外服务，如库存、物流跟踪和自动支付等。3.4.1定义业务系统的目标2.系统目标该公司的总体目标是在两年内将公司的市场份额从原来的5%提高到30%。实现这样的目标需要将日平均交易量从原来的1000笔增加到7000才能完成。要完成这个目标，必须采取实际的措施增加客户数量。3.4.1定义业务系统的目标图3-11办公用品销售公司的业务目标3.4.1定义业务系统的目标2.系统目标为了实现这个目标，公司需要增加互联网用户。这要求公司的网站主页必须容易找到，并积极鼓励访问者称为注册用户。这可以通过为注册用户提供一次性或季节性的回报，如折扣订单或贴现等，从而实现鼓励注册的目的。这样增加用户的方法是一个高成本的任务，并且可能对利润产生负面影响。但在在这方面进行投资对增加市场份额和未来的高利润又都是必需的。所以，这两个目标又是相互矛盾的。3.4.1定义业务系统的目标2.系统目标还有一些其它的源于信息系统方面的问题。例如，原有的销售系统不能连接到互联网；每笔销售或交易都需要手动完成。为此，我们可以得到如下的目标模型。分析和总结愿景陈述和业务模型中出现的各个概念，可以得到该公司的概念模型。图3-12办公用品销售公司的概念模型3.4.1定义业务系统的目标2.系统目标在这个概念模型中，业务计划（BusinessPlan）是一个非常重要的概念，它包含了市场营销计划（MarketingPlan）、产品策略（Productstrategy）、因特网策略（Internetstrategy）以及业务理念（BusinessIdea）等几个主要概念。其中，产品策略（Productstrategy）是业务营销计划中的一个关键概念，它以市场分析（MarketingAnalysis）为基础。它决定了公司的产品研发、生产和选购策略和方法。实施市场营销计划（MarketingPlan）可以有效地提高市场占有率（MarketShare）。实施过程则可以是，客户首先提交订单（Order）并形成一次交易，然后在交易（Transaction）中进行支付。支付完成后，再向客户交付（Delivery）客户购买的商品（Item），进而在提供商品所附加的服务。交付过程（Deliveryprocess）可以通过关键比率（KeyRatio）实施控制。3.4.2业务过程模型业务过程模型是一个主要用于描述如何实现公司的愿景和目标的模型。图3-13给出了一个能实现上述目的的业务过程模型。模型中包括了市场开发（MarketDevelopement）、业务开发（BusinessDevelopement）、管理过程（ManagementPrecess）、承包商开发（SubcontractorDevelopment）、交付（Delivery）等五个过程。3.4.2业务过程模型其中，市场开发（MarketDevelopement）过程以市场分析为输入，输出是能够帮助公司实现扩大市场份额目标的市场计划；业务开发过程（BusinessDevelopement）这是一个以市场计划为输入，输出是能够实现交易和利润目标的业务计划的业务过程，业务开发过程通过业务计划控制管理过程和承包商开发过程的实施；在业务计划的指导下，管理过程（ManagementPrecess）控制分包商开发过程的实施，以为公司提供满足用户需求的产品供应。最后，交付过程负责处理用户订单的交易、支付和交付等处理。图3-13公司的业务过程模型3.4.3交付业务流程图为了更好地描述公司的业务状况，我们分解了图3-13中的交付过程，得到了图3-14所示的交付过程的业务流程图。这个模型细化了交付过程。将交付过程分解成客户交互（CustomerInteraction）、订单（Order）和采购（Procurement）三个处理过程。其中，客户交互（CustomerInteraction）过程负责与用户交互，输出用户体提交的商品订单。这个过程需要客户和商品两个方面的信息支持。3.4.3交付业务流程图订单（Order）过程对客户提交的订单进行处理，包括订单支付和商品的实际交付等。采购（Procurement）过程负责商品的采购，其输入信息包括商品需求预测（Prognosis）信息和订单信息（Order）。输出的公司的商品信息。业务建模时，有时有必要建立公司的组织结构模型、资源结构模型以及必要的业务分析模型等模型。受篇幅等原因的限制，我们略去这些问题的讨论。3.4.3交付业务流程图图3-14交付过程处理流程图

3.4.4网络销售系统的结构为了有效支持公司的业务目标，计划开发一个网络销售系统。并且将该系统纳入新的公司业务系统中。图3-15给出了该公司的信息系统结构图。3.4.4网络销售系统的结构图3-15网络销售系统结构图3.4.4网络销售系统的结构1）客户交互系统（CustomerInteraction）负责处理与客户交互的所有事务，这些事务能包括客户管理（注册、登录、客户信息管理等）、零售业务（如选择商品、提交订单、在线支付）等。也包括大客户销售业务（如提交购物请求、审核销售方案和确认最终销售方案）等业务。2）销售系统（Salessystem）负责接收客户交互系统提供的订单或购货合同，读取采购系统提供的商品信息，组织并实施商品的支付，并确保支付的及时和准确。3.4.4网络销售系统的结构3）采购管理系统（PrcurementSystem）则负责跟踪销售情况和市场发生的各种变化，及时调整公司的商品需求预测和采购计划，为销售系统提供及时有效的支持。4）财务系统（FinancialSystem）负责处理与上述系统相关的财务方面的事务。图3-15清晰地描述了目标系统的总体结构，但并没有描述这个系统的功能结构、概念结构和逻辑结构。弄清楚这些问题则需要对目标系统进行软件建模领域了。3.4.5系统需求1.功能需求功能需求主要解决系统做什么的问题，最常用的功能建模的方法通常是用例建模。例如，对于图3-15中所示的客户交互子系统，可以用图3-16所示的用例图描述其功能结构。3.4.5系统需求图3-16客户交互子系统的用例图3.4.5系统需求图中定义了用户、注册用户、集团客户、销售顾问以及销售系统等多种类型的参与者；对于普通用户（User）定义了登录（Login）、注册（Register）两个用例；对于注册用户，定义了注销（Logout）、选择商品（SelectItem）、提交订单（GenerateandSubmitanOrder）和支付（pay）等用例。而对于集团用户（GroupUser），还定义了提交购物请求和评审购物方案两个用例，以支持大宗货物采购。3.4.5系统需求最后，对于大客户，系统还定义了一种新的参与者销售顾问。销售顾问负责为集团客户制定能够满足客户需求的购物计划。建模这样的用例图时，隐含了一个系统边界的问题。即建模时，要分清楚那些东西是系统内的，那些东西是系统外部的。图13-6中的参与者均为系统外的，所有用例则均被默认为是系统内部的用例。如何确定内部用例，可能还需要在建模过程进行更细致的分析和设计工作。总结并分析图3-14中出现的信息对象，可以获得一个系统的概念模型。这样的概念模型也是系统需求的重要组成部分。3.4.5系统需求2.非功能需求主要指对目标系统在功能性需求之外的各方面的需求。非功能性需求通常会包括很多方面，如可靠性、安全性、完整性和一致性方面的要求，还有可能包括运行时间和空间方面的要求。有时还有开发方面的需求，如可维护性、可移植、可重用等。非功能性需求往往来自于业务系统对目标系统在某些方面的限制，必要的非功能需求得不到满足的系统往往不能有效地支持业务系统实现其业务目标。3.4.5系统需求序号标题说明1概述对需求规格说明书本身的一个概述，包括需求规格说明的目的、预期读者和设计的范围等2项目概述对当前项目的总体概述。内容包括软件概述、项目简介、环境、软件功能、用户特征、项目假设和项目与环境的依赖关系3需求建模系统的需求建模所选用的建模工具的介绍4系统需求模型包括功能需求、非功能需求和接口需求。接口需求又包括用户接口、软件接口、硬件接口和通讯接口等方面的需求5总体设计约束目标系统需要满足的约束，如系统应符合的各种标准、需要满足的硬件约束、采用的技术限制等6软件质量特性目标系统软件所应满足的软件质量属性7依赖关系目标系统与环境或其它系统之间的依赖关系8其它需求上述需求之外的一些特殊的需求，如系统需要使用特定的数据库。系统需要执行的特殊操作等。又如本地化或国际化等要求9需求分级确定需求的优先级别10待确定问题规格说明书中需要进一步解决或目前尚不明确的一些问题11附录可行性分析结果表3-1需求规格说明3.5小结本章比较简单地介绍了业务模型、业务模型的建模方法以及业务规则等方面的基础知识和基本内容。对于业务模型，介绍了业务模型的基本概念。简单介绍了业务的概念，详细讨论的业务模型的评价标准、基本结构以及业务模型的主要动机。需要明确掌握的是业务和业务模型的概念、业务模型的概念结构。对于业务建模方法，讨论了使用UML建模业务模型的原因；简要介绍了UML的主要业务扩展。以及基于UML业务扩展的业务建模方法。详细介绍了使用UML建模业务模型的基本方法。3.4.5系统需求也介绍了使用UML建模业务模型时建立的各种常见模型，如业务过程模型、目标/问题模型，资源结构模型等。重要的是，这些模型从不同的侧面描述了一个完整的业务系统，尽管它们不太可能描述了一个企业的全部。对于业务建模方法，讨论了使用UML建模业务模型的原因；简要介绍了UML的主要业务扩展。以及基于UML业务扩展的业务建模方法。详细介绍了使用UML建模业务模型的基本方法。也介绍了使用UML建模业务模型时建立的各种常见模型，如业务过程模型、目标/问题模型，资源结构模型等。重要的是，这些模型从不同的侧面描述了一个完整的业务系统，尽管它们不太可能描述了一个企业的全部。3.4.5系统需求业务规则方面，本章比较详细地讨论了业务规则的定义、种类、作用及其表示方法。需要说明的是，本章中介绍的业务规则及其表示方法，同样也适用于软件模型。在业务建模方法方面，本书给出了一个简单的例子，说明了业务模型的建模方法、过程和目的。事实上，并不存在一个普遍适用的业务建模方法。任何一个业务建模活动，都要从建模的具体目的出发，综合运用各种建模技术和方法，完成预定的建模目标即可。最后要说明的是，后续章节中介绍的用例、类图、交互图、状态图和活动模型都不仅仅适用于软件建模，它们仍然会涉及到业务建模的内容。则是因为大多数的软件开发，都不是建立在完整的业务建模的基础上的，这样的软件模型不可能不包含业务方面的内容，区别只不过是工作形式上的不同。除非你开发的是一个与任何业务都无关的软件。即使不进行完整的业务建模，理解和掌握基本的业务建模知识也是十分必要的。第4章用例建模学习目标

理解和掌握用例模型的概念、构成元素以及这些构成元素的建模方法

理解和掌握参与者、用例、用例描述及其相互之间的关系的概念和表示法

理解和掌握参与者、用例的识别方法，进而掌握用例模型的一般建模方法

深刻领会用例建模的意义和作用第4章用例建模通常的面向对象开发过程就是一个从使用用例模型开始建立目标系统的功能模型，进而识别出目标系统的结构模型，并通过结构模型找出构成目标系统所需的对象，在通过找出这些对象之间的相互协作完成项目的目标。最终构造出目标系统所需要的类以及这些类的属性和方法。从而完成软件系统的设计。用例建模主要用于获取目标系统的功能需求，用例模型要描述的是：目标系统中哪些参与者、用例和参与者与用例之间的关联关系。同时也要描述参与者之间的泛化关系及用例之间的包含、扩充以及泛化关系。更重要的是用例模型还需要描述实现每个用例所需要的动作系列。最后，还要从用例描述中分析出目标系统所需要的概念或名词术语，如业务逻辑和业务实体等，并以此为依据建立起目标系统的概念模型。第4章用例建模在基于用例的面向对象分析方法中，用例模型通常被视为目标系统的需求模型。作为用例模型的组成部分，用例图主要用来定义系统的功能需求，画用例图的过程实质就是分析系统的功能需求的过程。用例图主要描述参与者与用例之间的连接关系。参与者可以是人，也可以是外部计算机系统和外部进程。事实上，用例图仅仅从参与者使用系统的角度描述系统中的信息，即站在外部观察系统应具有的功能，它并不描述这些功能在系统内部得具体实现。用例图的作用主要有获取功能需求、设计测试用例和指导整个软件开发过程中的其它工作流等三方面的作用。4.1用例图的基本概念用例图的基本构成元素主要包括：参与者（Actor）、用例（UseCase）两种基本元素，同时还包括参与者与用例之间的关联、参与者之间的泛化，以及用例之间的包含、扩充和泛化等关系。另外，系统边界也是用例模型的一种模型元素。在需要强调系统范围或子系统结构时，可在用例图中使用系统边界。系统可以看作是由若干个确定的相互作用、相互依赖又相互影响组成部分结合而成，具有特定功能的有机整体，而且这个有机整体又可能是它从属的更大系统的组成部分。对于系统而言，系统外对系统内要素有影响的集合又被称为该系统的环境，任何一个系统都有其环境并且这个环境的影响和制约，这些影响和制约也对系统的演进产生重要影响。4.1用例图的基本概念如果一个系统的所有构成要素都是另一个系统的组成部分，则这个系统就是后一个系统的子系统。系统边界应该是在系统定义阶段确定的，属于系统分析的输入。在分析阶段考虑系统边界问题的意义主要体现在如下几个方面：在需求分析过程中，向建模人员强调系统边界的概念，从而明确项目的需求基线。在整个项目开发过程中，控制和管理像改变系统边界这样的需求变更。明确系统的范围、规模和外部接口。用例图中，可以使用一个带有名称的矩形框表示系统边界，系统的名字写在矩形框内部，矩形框内部还可以包含系统的用例，借以表示用例与系统的所属关系。4.2参与者当系统内部或环境中发生了某个事件，这个事件可能触发系统的某个动作从而使系统与其环境发生交互，此时，环境中可能都会有一个或若干实体参与这个交互，在用例模型中，环境中参与这个交互的实体就被统称为参与者。4.2.1参与者的定义参与者是指系统外部为了完成某一项任务而与系统进行交互的某个实体，这个实体可以是系统的某个用户、外部进程或设备等，参与者的本质特征是：参与者必须位于系统外部，参与者必须与系统有着某种形式的交互。对于一个具有较大规模的系统来说，一般会有多种不同的外部实体与之进行多种不同形式和不同内容的交互。例如对于电子商务系统来说，与这个系统有交互活动的实体就可能包括顾客、商家、管理人员、支付机构和物流公司等多种参与者与系统进行各种不同形式和内容的交互。4.2.1参与者的定义在用例模型中，参与者实际上是一种按照它所承担的职责而定义的角色，我们可以将每种角色称为一个参与者。而把实现角色职责的具体参与者定义为参与者实例。显然，参与者和参与者实例是两个不同层次的概念。与大多数教材一样，在不引起混淆的情况下，本教材将不严格区分参与者和参与者实例这两个概念，而将它们统称为参与者。在统一建模语言中，参与者与系统交互的方式与面向对象方法中的消息机制相似。在用例图中，参与者与系统之间的关系将使用参与者与用例之间的关联的方式描述，而在活动图、顺序图和通讯图中将使用消息传递方式描述参与者与系统（中的对象）交互。4.2.1参与者的定义图4-1图书管理系统的用例图，图中列出了系统的边界、参与者和用例，同时，还展现了参与者与用例之间的关联关系、参与者之间的泛化关系和用例之间的扩充及包含关系。4.2.2识别参与者从参与者的定义来看，参与者既可以是用户，也可以是其它计算机系统或正在运行的进程，还有可能是承担了某种系统责任的外部设备。因此，参与者的一个主要特征就是参与者总是处于目标系统的外部，它们并不是系统内部的组成部分。因此，我们可以列出如下发现系统参与者的启发式问题，分析这些问题将有助于找到目标系统的参与者。4.2.2识别参与者1）系统的主要用户是谁？分析系统的主要用户，将有助于找到最主要的系统用户。2）谁使用系统输出的信息？使用系统输出的信息的人可能是系统用户，也可能是系统的间接用户。对于间接用户，进一步的分析将有助于进一步明确和定义系统输出这些信息的方式。3）谁负责提供系统的输入信息？谁负责使用或删除系统中的信息？负责输入、使用和删除系统中信息的人员通常是系统用户，有些还有可能是系统重要的用户。仔细分析负责输入、使用和删除系统信息的人员及其管理的信息不仅有助于识别参与者，而且有助于识别和更详细地定义参与者的类别。4.2.2识别参与者4）谁负责来安装、操作和关闭该系统？负责安装、操作和关闭系统的人通常是系统维护人员，他们通常也有可能是系统的一种或多种参与者，他们维护系统时通常也需要与系统进行一些必要的交互。所以他们也可能是系统的参与者。5）系统是否在哪些预定的时刻会有某些事件自动发生？当系统需要在某些预定的时刻发生某些事件时，就需要找到这些事件的响应者。这些响应者就有可能是系统的参与者。4.2.2识别参与者6）系统需要响应哪些外部事件？如何响应？当系统需要响应某些外部事件时，这些外部事件的发起者就有可能是系统的参与者。这些事件的相应方式也决定了这种参与者与系统的交互方式。7）系统从何处获得信息？分析系统信息的来源有助于识别信息系统类型的参与者，如果系统地信息来源于某个外部系统，那么这个外部系统就有可能是当前系统地一个参与者。4.2.2识别参与者分析过程中，要注意参与者的确切含义，参与者是指任何与系统由交互关系的人或事物。寻找参与者时，不应该仅关注那些和系统发生直接交互的用户。还要关注系统需要使用的设备和与系统相关联的外部系统。在完成了参与者的识别之后，进一步需要考虑的问题是每个参与者需要系统完成什么功能，从而建模参与者所需要的用例。一个系统通常有多个参与者，而不同的参与者与系统的关系以及在系统运作过程中所发挥的作用也都是不同的。将所有参与者按照他们与系统之间的关系和他们在系统运作中所发挥的作用分类将既助于识别系统的参与者，同时也更有助于发现分析的功能需求。4.2.2识别参与者在系统运作过程中，参与者所发挥的作用取决于它们所能够进行的交互，如果把系统的功能划分为主要功能和次要功能，那么，就可以将参与者分为主要参与者和次要参与者。例如把系统的主要功能定义为指系统中那些能够产生输出信息并对实现系统目标有直接影响的功能。其余功能则定义为次要功能。那么，主要参与者就是指那些使用系统输出信息并且对实现系统目标有重要影响的参与者，其余的参与者就是次要参与者。识别主要参与者的实质是识别系统的主要功能，同时对下一步的建模计划也有着重要影响。4.2.3参与者之间的泛化关系在参与者中，如果一个参与者拥有另一个参与者的所有行为，那么就说这两个从参与者之间具有泛化关系。定义参与者之间泛化的实质是把某些参与者的共同行为抽取出来表示成通用行为，且把这些参与者描述成为抽象参与者。在参与者之间的泛化关系中，一个参与者的行为可以被其它多个的参与者所共享。抽象参与者充当了一个多个参与者所具有的公共行为的这样的一个角色。这样，当定义一个具体的参与者时，只需定义这个参与者所特有的那部分行为，它所具有的公共行为仅从抽象参与者中继承就可以了。4.2.3参与者之间的泛化关系UML中，参与者之间的泛化表示与类之间泛化的表示相同，其中的箭头指向的一端是抽象参与者，另一端则是具体的参与者。例如，图4-1中的读者和图书管理员、借阅管理员和读者管理员之间的泛化关系，图书管理员、借阅管理员和读者管理员时读者的派生参与者，他们都是读者，可以拥有读者的全部行为，同时他们还具有自己独特的系统行为。值得注意的是，具有泛化关系的参与者在与系统进行交互时，他们与系统之间进行的共同的交互也有可能仅仅是大致相同的。不同层次参与者与系统之间的交互，也可能会有某些细节上的差别，这时还需要仔细考虑他们之间的不同。4.2.3参与者之间的泛化关系例如，图书馆里系统中，图书管理员和读者都有图书信息查询的权限，但他们在进行图书信息查询时，二者可以执行的操作却可能会有很大的区别。读者查询图书时，仅仅能够阅读图书信息即可，而图书管理员却可能需要在查询图书时，扩充添加新图书信息、修改图书信息和删除图书信息等功能。显然，对这个问题的不同理解往往会导致不同的设计。在分析阶段的早期，确定一个抽象参与者有时是比较困难的。但随着分析的深入及对系统与其参与者之间交互信息