业务分析模型从业务系统和业务工作者内部的角度定义业务用例实现。该该模型为产生预期效果确定了业务人员以及他们处理和使用的对象(业务实体)之间必须具有的静态和动态关系。它注重在业务区域中扮演的角色以及他们的当前职责。该模型将显示实现所有业务用例所需的所有协作,以及将对象实例化以绑定(实现)这些角色的所有类。
业务分析模型的关键元素是:
-
业务系统,将较大的业务模型分为互相依赖的职责区域。业务系统包括它们的资源,并且通过明确定义的接口向业务的其他部分提供服务。
-
业务工作者是业务的活动单元,在业务分析模型中它们代表人或软件的抽象,或甚至是包含人、硬件和软件的系统(该系统与业务系统不同,不会在业务分析或业务设计模型中进一步分解)的抽象。他们的职责是在业务分析模型中定义的。
-
业务实体表示使用或产生的可交付成果、资源和重要信息。
-
业务事件表示在业务的日常操作中发生的、可能会触发其他业务流程的重要事件。
-
业务规则,指在业务流程的执行过程中必须满足的策略或条件的声明。
-
业务用例实现显示业务系统、业务工作者、业务实体和业务事件如何协作以执行业务用例。业务用例实现是使用以下图记录的:
-
类图,显示参与的业务系统、业务工作者和业务实体。
-
活动图,其中泳道显示业务系统或业务工作者的职责,对象流显示在工作流程中如何使用业务实体。
-
时序图,描绘业务系统、业务工作者和业务参与者之间交互的详细信息,并描述在执行业务用例的过程中如何访问业务实体。
业务分析模型将结构和行为的概念合在一起。业务用例实现将指定预期行为的流程描述(业务用例)映射到组织中的结构元素(请参阅出现在项目符号后的图)。
下面是业务分析模型的一些特征:
-
它是一个衔接工件,以类似于软件开发人员的思考方式说明了业务问题,同时仍保留纯粹的业务内容。它将我们所知道的有关业务的信息按照对象、属性和职责进行了合并。
-
它探索业务领域知识的本质,所采用的方式使我们能够从对业务问题的思考转变到对软件应用程序的思考上来。
-
它是一种确定需求的方法,使需求能够为将构建的信息系统使用,并得到该系统的支持。
-
同意业务对象定义、对象之间的关系、对象的名称以及对象之间关系的名称的流程,允许业务区域知识以精确、可以由业务区域专家理解并验证的方式表示。
一般来说,业务系统、业务工作者、业务实体和业务事件应有唯一的并且不与其他名称类似的简短的描述性名称。有时可能需要使用多个词描述模型元素的目的,并确保其唯一并且可以识别,尤其当考虑更广的环境时(可能在将来很重要)更是如此。
业务系统提供具有一个特定目的的相关职责的集合,并应以反映这种目的的方式命名。它可能试图使用通用名称或在名称中使用短语(例如“客户端服务”),但请确保该术语确实适用并有描述性。通常,动词的动名词形式(例如“装运(shipping)”、“开发票(Invoicing)”或“销售(Selling)”)在用来指业务系统的用途(例如,客户管理或获取目标)时很有用。请参阅指南:业务系统以获取更多信息。
业务工作者应以表达其职责的方式命名。不要描述职能(在业务工作者是人的情况下),而要描述该业务工作者在用例实现中所扮演的角色。该角色由该业务工作者参与业务用例实现的目的来反映。请参阅指南:业务工作者以获取更多信息。
例如,想象这样一个流程,即由一个业务工作者将数据输入系统,并保留到第二个业务工作者在处理之前验证或核准该数据(例如在银行的贷款申请中)。输入数据的业务工作者可以命名为“数据键入员”或“数据输入职员”,而第二个业务工作者可以命名为“验证人”、“授权人”或“发放人”。“数据输入职员”有听起来像是人的缺点,而后三个必须在某个阶段进一步限定(例如,如果该银行也要启动代理保险政策,则可以有“抵押授权人”)。
业务实体应以反映它们代表的信息的方式命名。业务实体必须始终在业务词汇表中定义,因为通常关于定义和关系有太多的不同观点。不要在业务实体的名称中包含其状态或属性。业务实体名称应为单数,而不是复数。请参阅指南:业务实体以获取更多信息。
业务事件应以表示其代表的事件或已更改状态的方式命名。不要在名称中描述事件的触发器或对事件的反应。事件的指定独立于其触发器。请参阅指南:业务事件以获取更多信息。
当您研究参与业务的不同用例的业务工作者和业务实体时,您可能发现若干非常相似,实际上是一个类。即使当不同业务用例没有相同的需要时,这些类也可能足够相似以被视为一个类和同一现象。如果是这种情况,请将类似的类合并为一个。这会导致具有足够的关系、属性和操作以满足不同业务用例的所有需要的业务工作者或业务实体。标题为“说明”(上述内容)的那一节末尾的图显示业务工作者和业务实体如何参与不同的业务用例实现。
因此,几个业务用例可能对同一个类具有非常不同的需要。在业务工作者的情况下,如果您有雇员能够充当上述的那组角色,您还将有可以在几个职位上工作的灵活雇员。这可以向您提供更灵活的业务。
在业务分析模型中,业务工作者表示业务的活动单元将要扮演的角色,而业务实体表示活动单元要处理的那些对象。使用业务分析模型,您可以定义业务工作者(和处于较高级别的业务系统)需要如何进行交互以生成业务参与者预期的结果。上面已经说明业务工作者可以表示软件系统的抽象;
当您移出业务建模环境时,您将使用系统用例模型和设计模型来指定该软件系统。
业务建模和软件建模在两个不同的抽象级别上处理两种不同的问题域。因此,一般来说,您应允许这种差异的存在,不应将软件建模的详细信息强加到业务模型中,而应注重业务工作者的业务目的。
在您寻求自动化机会时,当您检查“按现状”模型中业务工作者(尤其是那些由人员工作者扮演的角色)的交互和特征时,业务事件的发生和使用,在业务实体上执行的操作,以及业务建模和系统建模环境之间的某些关系推断可能非常有用。业务模型中的链接、关联和属性可能暗示存在自动化的可能:
-
充当特定业务工作者的雇员与信息系统的系统参与者对应。如果信息系统被结构化,使他或她在业务用例中的整个工作可以得到一个系统用例的支持,则他或她可能会得到最好的支持。
-
或者,如果业务用例很大、存在时间很久或组合了若干独立区域中的工作,则信息系统用例可以支持该业务工作者的一个操作。
-
信息系统中常常说明了业务工作者操作的对象(这些对象建模为业务实体)。在信息系统的对象模型中,这些业务实体作为实体类出现。
-
在面向服务的体系结构软件系统中,业务事件通常作为消息实施,在工作流程自动化系统中,通常作为任务实施。
-
业务实体之间的关联和聚集通常会在设计模型的实体类之间产生相对应的关联和聚集。
-
因此,一个信息系统用例访问和操作在设计模型中代表由所支持的业务用例访问的业务实体的实体类。
-
在系统建模环境中,直接使用业务信息系统的业务参与者也成为该信息系统的系统参与者。
这些关系在确定对支持业务的信息系统的需求时很有用。
请参阅指南:从业务模型到系统中关于自动化业务工作者的那一部分。
有时,某个业务的员工通过使用自己业务的信息系统联系另一个业务的员工。从建模业务的角度,该信息系统即是一个业务参与者。
示例:
软件开发人员尝试了解他负责的产品中的一个问题。要了解该问题是否源自他使用的编程工具,他联系了供应商的万维网服务器并研究该编程工具当前发行版中的已知问题列表。以这种方式,业务工作者“软件开发人员”与业务参与者“供应商 WWW 服务器”交互。
将业务工作者对业务实体进行的操作建模时,很明显,有许多对业务实体的操作都将借助某些工具(可能基于计算机)来执行。 您选择将它显式地建模为信息系统还是其他系统(从而用业务工作者来表示它)取决于它在业务中的重要性。
例如,您不会将具有字处理和电子表格功能的简单桌面系统作为独立的业务工作者建模。另一方面,当您遇到业务中的信息系统直接由客户使用的情况,并且这种交互形成了业务服务的主要部分,则它可能在商业上很重要,因而您想在业务分析模型中显示它。电话银行服务是这种信息系统的很好示例。
在这种情况下,您可以按如下方法继续:
-
将信息系统视为与参与者交互的完全自动化的业务工作者。
-
如果信息系统与任何其他业务工作者或业务实体相关,请考虑使用链接或关联说明这种关系。可能该系统告知一个业务工作者其进度或使用关于一个业务实体的信息。
-
简短描述该业务工作者,以及在业务分析模型中代表信息系统的服务列表。
-
在下级信息系统模型中为信息系统的所有详细信息和特征及其环境建模。
-
引入命名约定,以便从多个业务工作者中轻松地确定完全自动化的业务工作者;例如,使用前缀或后缀,如“自动化的<业务工作者名称>”或“系统:<业务工作者名称>”。您甚至可以使用特定的图标定义构造型。
业务系统、业务工作者、业务实体和业务事件一起协作以执行业务用例中描述的所有任务,绝不多一点,也绝不少一点。 业务分析模型通过适当的抽象对组织进行了有效而全面的展示。
转换为业务设计模型
业务设计模型是通过有选择地实现(也可能是重构)由人员、软件或系统(这些系统本身由人员、软件和硬件这几项中的某几项或所有项组成)充当的业务工作者,由业务分析模型演进而来的。业务设计模型不会进一步分解它们,那是后续的系统或软件开发工作。
|