Business Process Modeling Chapter 4

Chapter 4: Business Process and Functional Modeling

• This chapter focuses on identifying, modeling, and documenting business processes using use-case diagrams, activity diagrams, and use case descriptions.
• Objectives include understanding the processes for creating use-case diagrams, activity diagrams, and use case descriptions along with creating functional models of business processes.
• Functional models are logical representations of a system, independent of implementation methods (manual or computerized).
• Use cases describe how a system interacts with its environment, including a diagram and a description of discrete user activities.
• Activity diagrams model business processes or operations, showing the flow of data between activities.

Objectives

• Understanding the process for identifying business processes and use cases.
• Understanding the creation process for use-case diagrams.
• Understanding the process for modeling business processes using activity diagrams.
• Understanding the rules and style guidelines for activity diagrams.
• Understanding the process for creating use case descriptions.
• Understanding the rules and style guidelines for use case descriptions.
• Creating functional models of business processes using use-case diagrams, activity diagrams, and use case descriptions.

Introduction

• The goal is to translate requirements into functional models.
• Models are logical, not tied to implementation methods.
• Use cases are created from requirements, describing a system's interaction with its environment through discrete user activities.
• Activity diagrams derive from use cases, modeling business processes and data flow between activities.

Business Process Identification With Use-Cases

• Use-case diagrams include elements like actors (users or systems) and associations (lines connecting actors and use cases).
• Interactions are depicted through inclusions, extensions, or generalizations.
• A use case represents a significant process in the system that benefits users.
• A subject boundary defines the system's scope.

Identifying Major Use-Cases

• Review the requirements definition.
• Identify the subject's boundaries.
• Identify the primary actors and their goals.
• Identify the business processes and major use cases.
• Carefully review the existing use cases.
• Potentially split or combine use cases to achieve the right size.
• Identify additional use cases.

Create a Use-Case Diagram

• Place and draw use cases and actors.
• Draw the subject boundary.
• Connect actors and use cases with associations.

Example Use Case (Library Circulation System)

• This example shows a system with actors (Librarian, Borrower) and use cases (Process Overdue Books, Maintain Book Collection, Borrow Books, Return Books, Search Collection).
• Use cases and actors are interconnected.

BPM With Activity Diagrams

• Business processes consist of several activities.
• Activity diagrams visualize the sequence of those activities.
• Diagrams are abstract, focusing on general procedures.
• Activity diagrams are independent of the objects they model.
• They are applicable to various processes.

Activity Diagram Syntax

• Actions/activities represent specific actions or sets of actions.
• Control flow shows the sequence of execution.
• Initial nodes mark the start of action sets.
• Final nodes end all flows within an activity.
• Decision nodes represent decision points based on conditions.

Elements of an Activity Diagram

• Activities are steps in a business process, named with verbs and nouns (e.g., Get Patient Information).
• Activities can be subdivided into actions.
• Object nodes illustrate data flow between activities.
• Control flows represent the execution path.
• Object flows show data movement.
• Control nodes (initial, final, decision, etc.) direct process flow.

Control Nodes

• Initial nodes begin process activities.
• Final-activity nodes stop all activities within a specific flow.
• Final-flow nodes stop a single execution path while allowing other paths to continue.
• Decision nodes represent conditions that determine the execution path.
• Merge nodes combine mutually exclusive execution paths.
• Fork nodes split a single flow into multiple parallel paths.
• Join nodes bring parallel paths back together.

Activity Diagram Symbols

• Detailed visual representations exist for various actions, activities, control and object flows, and nodes in an activity diagram.

Sample Activity Diagram (Patient Registration)

• This example illustrates how a patient can register for care, including information gathering, payment arrangement, and appointment creation. This diagram includes actions such as "Get Patient Information" and different paths based on new patients or existing patients.

Swimlanes

• Swimlanes assign responsibilities to objects or individuals, visually separating roles in an activity diagram.
• Responsibilities are clearly seen, either displayed vertically or horizontally.

Guidelines for Activity Diagrams

• Define the scope of the activity being modeled.
• Identify and connect activities with flows.
• Identify any decisions required during the process.
• Highlight potential opportunities for parallelism.
• Draw the activity diagram.

Creating an Activity Diagram

• Choose a previously identified business process.
• Review use case diagrams, requirements, and documentation.
• Identify activities and their sequence in the business process.
• Identify control and object flows and associated nodes.
• Construct the activity diagram by minimizing crossing lines.

Use Cases

• They are the primary driver for UML diagramming, showing user activities.
• Use cases represent essential system functionality, specifying user actions and responses.
• They are building blocks for further design activities.
• Each use case should document a single function.

Types of Use Cases

• High-level use cases offer a general overview of crucial functionalities and issues.
• Detailed use cases provide an in-depth description of specific actions, steps, and functionality within a system.

Elements of a Use Case Description

• Overview (name, ID, type, actor, description, importance, stakeholders, trigger).
• Relationships (association, extension, inclusion, generalization).
• Flow of events (normal flow, subflows, alternate/exceptional flows).

Use Case Writing Guidelines

• Write use cases in a subject-verb-object format.
• Clearly identify the step initiator.
• Maintain an observer's perspective.
• Maintain consistent levels of abstraction.
• Create a sensible set of use case steps.
• Follow KISS (Keep It Simple, Stupid) principle.
• Repeat instructions where applicable.

Creating Use-Case Descriptions

• Select a priority use case.
• Outline details such as the actor type, stakeholders, importance, triggers, relationship between use cases, and overview of the use case itself.
• Define the steps for use case execution (normal flow, subflows).
• Detail any exceptions or alternative flows.
• Review the entire description, and refine as necessary.
• Iterate over the entire use case description.

Creating Use Case Descriptions (Continued)

• Ensure the step details are consistent and not overly complex.
• Identify and document alternative and exceptional events.
• Verify the accuracy of the descriptions.
• Re-iterate over the description elements.

Example Use-Case Description (Borrow Books)

• Provides a detailed example of a use case description format.
• Includes details, like use case name, actor (Borrower), importance level, use case type, and flow of events.
• Highlights both normal and exceptional flows.

Verifying and Validating Use Cases

• Use cases must be verified and validated prior to structural and behavioral modeling.
• Use walkthroughs to analyze and refine all existing models and diagrams in the project.
• Client and development team members participate in interactive reviews.
• Clearly defined roles exist for Facilitator (planner and moderator), Presenter (lead reviewer), and Recorder (scribe).

Rules for Verification & Validation

• Ensure each documented use case action/activity is reflected in the activity diagram.
• All objects within activity diagrams should be referenced in the use case description.
• The sequence in the use case description must match the activity diagram sequence.
• One specific use case description must be provided for each instance.
• All actors referenced in the use case description should be illustrated in the corresponding use case diagram.
• Relationships in the use case description must be shown in the use case diagram.
• Diagram-specific rules must be adhered to.

Summary

• Chapter 4 details the identification and modeling of business processes using use-case diagrams, activity diagrams, and descriptions.
• Methods for creating these documents and validating the results are provided.