Business Sub-process Modeling

This chapter explains how you can define sub-processes using Unified Modeling Language (UML) diagrams.

Use Case

A use case is a definition of a sub-process. The following UML Use Case Diagram defines the business process of a dental clinic receptionist as four use cases in which the receptionist participates:

Formally, a use case is a set of interactions between a role, known in the UML as an actor, and a software product for achieving some goal.

For example, dental office receptionist does the following activities for patient identification (role – receptionist and use case – patient identification):

· Requests health card.

· Notifies patient that additional charge is required if patient does not have health card.

· Verifies health card validity.

· Notifies patient that additional charge is required if health card is expired.

· Checks whether the information system contains patient’s information.

By performing the activities defined above, the receptionist moves the patient identification use case from the initial state to one of the final states – the patient is identified, or the patient is not identified.

UML Activity Diagrams can be used to visually define use cases. For example, the following diagrams visualize use cases for a dental clinic receptionist's business process:

1. Patient identification.

· Initial state: the patient entered the dental office.

· Trigger: a receptionist began serving the next patient in line.

· Activity: patient identification.

· Rule: The patient is identified if one's profile is available in the information system.

· Final state of positive result: patient is identified.

· Final state of negative result: patient is not identified.

The use case starts with an initial “The patient entered the dental office” state, which is represented by the circle at the beginning of the diagram.

The “A receptionist began serving the next patient in line” transition (indicated by the arrow in the diagram) switches use case from the initial state to the final state “The patient is identified” or to the final state “The patient is not identified” depending on whether the patient profile is available in the information system.

The receptionist begins (or triggers) the transition by requesting a patient’s health card. The trigger is indicated by an asterisk in the diagram.

To determine the result of the transition, the receptionist follows the rule “The patient is identified if his profile is available in the information system”.

You can read the contents of other diagrams in a similar way.

2. Patient registration.

· Initial state: the patient’s registration is required.

· Trigger: a receptionist began patient’s registration.

· Activity: patient registration.

· Final state of positive result: patient is registered.

The patient registration process is very simple. This is just a set of activities to fill out some forms with the patient’s data, his medical history and current condition. The result is always the same - the patient is registered. The receptionist does not have to make any decisions during this process, so no rule is defined for this transition.

3. Appointment scheduling.

· Initial state: the patient wants to see a specialist.

· Trigger: a receptionist began appointment scheduling.

· Activity: appointment scheduling.

· Rule: Make an appointment if a specialist has time.

· Final state of positive result: the appointment is scheduled.

· Final state of negative result: the appointment is scheduled.

4. Visit finalization.

· Initial state: the appointment is scheduled.

· Trigger: the appointment is over.

· Activity: finalize patient’s visit preparing all the necessary documentation, taking payment, and scheduling another appointment if needed.

· Final state of positive result: the patient’s visit is finalized.

Since we said that a use case can represent a sub-process, we can conclude that for this to be possible, the use case must inherit all the elements and properties of the sub-process.

Use Case Elements

A use case can be defined by the same five elements that are used to define the sub-process:

· Initial state – the state of the sub-process before it was launched.

· Trigger – an event which starts a sub-process.

· Activities – a set of actions that make up a sub-process and transfer it from the initial state to the one of the final states.

· Final states or results – states of the sub-process after completion of all activities.

· Rules – elements which determine the final state of an activities.

Use Case Definition

Looking at the above example, we can say that a use case is a set of activities performed according to established rules, which transitions the sub-process from the initial state to one of the final states .

Or we can say that a use case is a set of states, transitions, and rules .

Alternative Definition of a Business Process

We can now give another definition of a business process by saying that a business process is a set of use cases, or more precisely, a business process is a set of states, transitions, and rules logically grouped into use cases .

Use Case Concepts

The use case is based on the concepts of uniqueness, isolation, encapsulation, and reusability.

Uniqueness

We are already familiar with the concept of uniqueness of a use case, but let's look at it again.

A use case represents a sub-process (set of logically grouped activities), which one actor (receptionist, Information Technology Department, or technician) is involved in. And since we've learned that every part of a business process is unique, we can say that every use case is also unique.

Saying that, we understand that uniqueness is the nature of use case.

Isolation

Since a use case represents sub-process, a unique part of a business process, it can be said that there is nothing common between any use cases. They are isolated from each other.

That is, the functionality of each use case can be defined independently of any other use case.

This brings us to the concept of use case encapsulation.

Encapsulation

Any change to the specific functionality of a use case cannot (and does not) affect the functionality of any other use case.

Reusability

Once defined, a use case can be part of many business process models that have the same sub-process. As an example, consider the “Person Registration” use case. It can be reused across multiple business processes that use person registration.

Table of Content Introduction into Business Process Previous: Business Process Modeling Next: UML State Diagrams