业务用例模型

UML（Unified Modeling Language）统一建模语言是一种用于对软件密集系统进行可视化建模的标准化建模语言。

用例模型是UML中的一个重要概念，主要用于描述系统的功能需求和行为。

用例模型主要由三个部分组成：参与者（Actor）、用例（Use Case）和它们之间的关系。

参与者（Actor）：参与者是与系统进行交互的用户或其他系统，可以是外部实体或内部实体。

用例（Use Case）：用例描述了系统执行的功能，即参与者与系统之间的交互行为。

一个用例通常描述了一个单一的功能或业务过程。

关系：关系描述了参与者与用例之间的交互，包括关联（Association）、泛化（Generalization）和依赖（Dependency）等。

在构建用例模型时，通常首先识别参与者，然后确定系统的功能需求，为每个功能需求创建一个用例。

接着，通过添加关系来描述参与者与用例之间的交互。

用例模型的主要目的是帮助开发人员理解系统的功能需求和行为，以便更好地设计和实现系统。

通过用例模型，开发人员可以更好地理解系统的边界、参与者与系统的交互以及系统的功能需求，从而更好地进行系统设计和开发。

软件工程之用例模型总结一、用例模型1.用例概念用例：使用系统时发现的功能性需求，不应过于复杂，简单的来说就是你希望系统能够有什么功能，能够增加系统的价值。

用例模型包括用例描述和用例图，我们主要把中心放在用例描述上。

用例模型包含参与者和场景，场景包括成功场景和失败场景。

因此用例模型中有多个场景；每个场景是一个用例。

用例必须注重为用户提供可观察的返回值，就是系统触发了一个用例之后能够给用户带来什么。

一般用例都是黑盒用例，即不考虑如何实现。

e Case Description每个用例都有一个描述。

怎样确定用例？(1)确定一个功能；(2)写一个用例；(1)主要参与者：调用系统服务完成目标的人。

(2)次要参与者：为系统提供服务的人。

(3)写出每个项目相关人员的理想需求，从中分析功能。

(4)PreCondition:执行到这个用例之前必须为真的情况，比如必须已成功登录或通过验证。

(5)PostCondition:成功执行完此用例后的情况，比如登录用例的后置条件是成功登录（不考虑其他失败情况）。

(6)main flow：将最理想的步骤列出。

一般main flow步骤如下：(1)参与者发生动作。

(2)系统验证。

(3)返回结果。

(7)extension flow：扩展步骤,通常格式为：(1)系统检测到**有问题;在main flow中的第一步扩展，则用1a,1b,1c;3.如何确保正确的用例EBP原则:一般用例都需要遵守这个规则，即确定主要用例。

用例中的主要用例是一些重复做但是有意义的事，比如收银员收钱，重复多次是有意义的，因为钱收得多了；但是像登录系统，这种做100次却没有意义的用例，不能被称为主要用例；(1)EBP（基本业务过程）原则的用例写入；(2)如果要写编辑A，删除A，添加A，可以合并成“管理A”；4.用例图每个用例描述都是一个用例，左边是主要参与者（希望系统为他提供服务）和次要参与者（提供给系统服务的人）；在次要参与者中不能有数据库，因为在用户角度看是不知道系统有数据库的；关系：(1)泛化关系，在参与者和用例中都能泛化。

业务用例模型业务用例模型：业务用例模型描述一个业务的流程以及它们与外部各方（如客户和合作伙伴）之间的交互。

解释由业务用例和主角构成的模型的主要目的是说明客户和合作伙伴是如何开展业务的。

直接与客户或合作伙伴相关的活动以及与外部各方并不直接相关的支持和管理任务都可以在模型中给出。

模型以业务用例（相当于我们常说的“流程”）的形式对业务进行说明。

登记处的主角和用例。

业务用例的不同类型当考查业务中的活动时，您至少可以确定三类工作，它们对应着三种业务用例类型。

第一类是在商业上比较重要的活动，常称为业务流程。

第二类是在商业上不太重要的活动，但必须进行这些活动来保证业务正常运转。

系统管理、清洁和安全等工作就是这类活动的示例。

该业务用例具有支持的性质。

第三类是管理工作。

具有管理性质的业务用例所显示的工作影响如何管理其他业务用例以及该业务和其所有者的关系。

通常，管理类型的业务用例概括地描述了CEO 和业务用例中工作人员之间的关系。

它还说明了业务用例是如何被开发和“启动”（实例化）的。

在餐馆中，核心业务用例是市场营销(Marketing) 和用餐服务(Serving Dinner)，而采购(Purchasing Supplies) 是支撑业务用例。

请注意，有时候您当作核心业务用例的用例在其他业务中会成为支撑业务用例。

例如，在软件开发公司中，软件开发是核心业务用例；而在银行或保险公司中，它却是支撑业务用例。

一个业务有多个业务用例一个业务有多个业务用例。

多个不同业务用例的实例或一个业务用例的多个实例并行执行的情况是很正常的。

一个用例实例可以遵循的路径的数目几乎是没有限制的。

这些不同的路径代表了工作流程说明中用例实例的各种选择。

根据具体事件和情况，用例实例可以沿着多种可能路径中的一种进行下去，例如：●来自主角的输入。

●一条业务规则。

在对业务用例建模时，您可以假定用例实例可以在不互相冲突的情况下同时进行。

在业务开发的这个阶段，您应该侧重于业务应该作些什么。

abstract class 抽象类,提供一组子类共有行为的类，但它本身并不具有实例。

抽象类表示一个概念，从中派生的类代表对这一概念的实施。

Abstraction 抽象,对视图或模型的创建，其中忽略了不必要的细节，以便专注于一组特定的相关细节。

access modifier存取权限,对类、方法或属性进行访问控制的关键字。

Java 中的存取权限可以是公有、私有、保护和包装（默认）。

accessor methods存取器方法,由对象提供的、用于定义连接该对象实例变量的方法。

用来返回实例变量值的存取器方法被称为获取方法；用来为实例变量指定值的存取器方法被称为设置方法。

acceptance验收,客户接受软件产品（作为部分或完整履行合同的结果）所有权的操作。

action动作,对构成计算过程抽象的可执行语句的规范。

动作通常会导致系统状态发生变化，这是通过向一个对象发送消息或是更改链接或属性值来实现。

action sequence动作序列,解析为一系列先后发生的动作的表达式。

action state动作状态,表示不可分动作的执行状态，通常指的是调用一个操作。

activation激活,动作的执行active class主动类,表示系统中控制线程的类。

请参见主动对象。

activity活动,要求角色执行的工作单元。

active object主动对象,拥有线程并可发起控制活动的对象。

主动类的实例。

activity graph活动图,状态机的特例，用于对涉及一个或多个分类器的进程建模。

对比：状态图(statechart diagram)。

同义词：活动图(activity diagram)。

actor主角,系统之外与系统交互的某人或某事物。

actor class主角类,定义一组主角实例，其中每个主角实例相对于系统而言都担任着同样的角色。

在与用例交互时这些用例的用户所担任的一组紧密相关的角色。

主角为每个要与其通信的用例都准备了一个角色。

业务模型的定义和分类业务模型是指对企业或组织的业务活动进行描述和分析的一种框架或工具。

它用于理解和解释组织的运作方式，帮助管理者制定决策和规划战略。

业务模型可以根据不同的分类标准进行划分和描述，下面将详细介绍业务模型的定义和分类。

一、业务模型的定义业务模型是对企业或组织的业务活动进行抽象和描述的模型。

它通过表示和描述组织的业务流程、业务规则、业务角色、业务数据等要素，揭示了企业或组织的运作机制和商业逻辑。

业务模型能够帮助企业或组织理清业务关系、优化业务流程、提升业务效率。

它是企业或组织制定战略、规划发展的重要依据。

二、业务模型的分类根据不同的分类标准，业务模型可以分为多种类型，下面将介绍几种常见的业务模型分类。

1. 流程模型流程模型是一种描述业务活动流程和顺序的模型。

它通过定义业务流程中各个环节的输入、输出、活动和决策条件，揭示了业务活动的执行顺序和规则。

流程模型可以采用流程图、时序图等方式进行表示，便于理解和沟通。

通过分析流程模型，企业或组织可以找出流程中的瓶颈和问题，提出优化方案，提升业务效率。

2. 数据模型数据模型是一种描述业务数据和数据关系的模型。

它通过定义业务数据的属性、类型、关联关系等，揭示了业务数据的组织和结构。

数据模型可以采用实体关系图、类图等方式进行表示，便于理解和分析。

通过分析数据模型，企业或组织可以理清业务数据的流向和关系，优化数据存储和管理方式，提高数据的质量和可用性。

3. 角色模型角色模型是一种描述业务角色和职责的模型。

它通过定义各个角色的权限、职能、责任等，揭示了组织内部角色之间的协作和配合关系。

角色模型可以采用组织结构图、职责矩阵等方式进行表示，便于理解和管理。

通过分析角色模型，企业或组织可以明确各个角色的职责和权限，优化组织架构和人员配置，提升工作效率和协同能力。

4. 系统模型系统模型是一种描述业务系统和功能的模型。

它通过定义业务系统的组成、功能和交互关系，揭示了系统之间的协作和互动方式。

企业架构研究总结（21）——TOGAF架构开发⽅法（ADM）之业务架构阶段1.3 业务架构（Business Architecture）企业架构开发⽅法各阶段——业务架构1.3.1 ⽬标描述基线业务架构开发基于原则、业务⽬标和策略驱动⼒的⽬标业务架构，描述产品和/或服务策略，以及业务环境在组织、功能、过程、信息和地理这些⽅⾯的内容分析基线和⽬标业务架构之间的差距选择和开发相关的架构视⾓，通过这些视⾓架构师可以阐述业务架构是如何对各⼲系⼈的关注点进⾏解答的。

选择与选中的视⾓相关的⼯具和技术1.3.2 ⽅法针对业务架构的了解是进⾏其他领域（数据、应⽤和技术）架构⼯作的前提条件，因⽽如果不是因为组织中其他⼀些诸如企业规划、业务战略规划以及业务流程再造等⽅⾯流程，针对业务架构的制定应该是要⾸选进⾏的架构活动。

业务架构是⽤来将其后架构⼯作的业务价值阐述给相关⼲系⼈所必不可少的⼯具，它也可⽤来为各个⽀持和参与后续架构⼯作的⼲系⼈阐明企业架构的投资回报。

在实践过程中，业务架构的关键元素也许已经在其他⼯作中被明确，⽽在这种情况下，组织就需要验证和更新当前已经⽂档化的业务战略和规划，并/或在已经明确的业务驱动⼒、业务战略、⽬标与架构开发⼯作相关的特定业务需求之间建⽴关联。

⽽在另外⼀种情况下，业务架构⼯作也许并没有或者很少被执⾏，⽽这就需要架构团队研究、验证架构将要⽀持的各个关键业务⽬标和流程，并获得相关⼲系⼈的认同。

然⽽不论处在以上哪种情况，TOGAF ADM的业务情景技术，或者是其他⽤来阐明关键业务需求以及为IT架构指明其技术需求的⽅法，都需要被纳⼊到架构师的⼯具箱之中。

需要注意的是，在架构活动中应尽量重⽤各种已经存在的材料，并且针对信息的收集和分析也应该依据架构⼯作的范围⽽采⽤那些能够促成明智决策的信息。

如果架构活动关注于业务流程的定义，则在此阶段组织需要在此⽅⾯进⾏很多细致的⼯作，⽽如果关注点更着重于其他领域（数据/信息、应⽤系统和基础设施）中的⽬标架构，那么组织就需要在这个阶段构建⼀幅⽆需包含众多⾮必要细节的全景图。

在业务用例模型的基础上构建领域模型要求：根据某物资储运公司日常业务及业务用例模型，构建其领域模型。

公司基本业务情况：（1）主要部门包括：总经办、收货组、出货组、调运科、库管科和财务科；（2）主要业务活动包括入库、出库及盘点；（3）入库业务◆总经办根据供货商提供的货品明细单创建入库单，并打印入库单，将其交至收货组；◆调运员进行卸车登记，编写“到站日报”，并通知收货组，进行货物入库；◆收货组进行验收，编制“码单”；◆收货组查找与该批货物对应的入库单，将码单关联到入库单上，一并交总经办审核。

（4）出库业务◆出货组审核用户提供的提货单，查找相应货品；◆如数量足够出库，则产生出库业务号，创建三联出库单，根据货物存放位置，出具派车单；◆出货组根据派车单调度车辆，指挥库管人员装车，过秤，收取装车费后开具出门条；◆当一张入库单上全部货物出货完毕后，出货组将入库单、码单、出货单送至总经办进行审核平帐。

（5）盘点业务◆总经办根据码单信息创建盘点表；◆库管人员根据实际盘点情况填写货物实存数量并返回总经办；◆总经办将信息进行汇总，如有误差则进行调帐。

业务用例模型业务用例图总经办客户业务用例描述 出库用例的活动图领域模型的构建步骤一：获取业务对象在出库业务用例中可以识别出入库单、出库单、码单、派车单、出门条等基本的业务对象；对入库单中货品规格信息的处理，可以单独建模为一个业务对象。

码单到站日报入库单出库单派车单出门条货品规格盘点表步骤二：业务对象属性建模根据具体业务描述，可识别出入库单对象有入库业务号、应收数量、实收数量、客户、货品名、货品规格、入库时间等基本属性入库单入库单号应收数量实收数量客户货品名入库时间步骤三：业务对象关系建模没有对业务对象进行抽象分析，因此没有建立对象间的泛化关系； 大多业务对象之间的关系都表现为关联关系；对于入库单业务对象而言，其中货品的存放位置都记录在若干码单中，因此可以在入库单和码单对象之间建立组合聚合关系。

业务建模业务建模（Business Modeling）是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。

简介业务建模（Business Modeling）是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。

业务建模（Business Modeling）是一种建模方法的集合，目的是对业务进行建模。

这方面的工作可能包括了对业务流程建模，对业务组织建模，改进业务流程，领域建模等方面。

建模原因Brooks 大师说，三十多年来各式各样的应用系统（Application Programs AP）历经多次的修修改改，已经变得面目全非，如同一群的怪兽，难以驯服。

业务建模Rogerson大师也说，The application is a rock in the river of change.（应用（系统）成为改变之潮流中的顽石）。

对很多企业而言，有一个统合企业各部门的信息系统的心愿似乎已经成了一种奢望。

企业中或多或少都会有一些应用系统在辅助企业的自动化运作，当企业信息主管希望能够对目前的信息系统进行整合，能够配合企业的发展的时候，他们失望了。

大多数的应用缺乏一个统一的接口，难以进行整合。

在我们进行项目开发的银行中，我们也同样发现了这个问题，不同部门的系统之间无法进行互联，跨部门的业务流程必须经过手工的处理。

以前，应用程序的开发都是基于部门的功能的而建的。

单纯只是为了解决目的而建立应用系统。

所以这种方式建立的应用系统是针对特定的功能区域（Function Area）而建立的。

至于如何使企业内的多个应用系统共同运作，就不在设计者的考虑之列了。

随着企业的发展，就会发现企业需要变化以适应市场变化，业务发展的时候，原有的一系列应用系统却成了企业发展的拦路虎，这使得企业不得不回到手工的时代。