Analyzing Activities › Basic Activity Modeling Concepts › Defining Processes

Defining Processes

A process is a defined business activity whose executions are identified in terms of the input and output of specific entities or of data about specific entities.

Processes are activities for which a start and an end can be imagined. A process is something that can be said to be executable. An occurrence of a process is named a process execution.

For example, a single execution of a process that is called Take Order deals with the input of certain information about a particular order request and results in the creation of an ORDER entity.

Processes can be discovered by:

• Analyzing life-cycles of the business and of entities within the scope of the development project.
• Examples of entities whose life-cycles are examined for clues to processes include products, orders, and suppliers.
• Identifying the activities that create and manage the business and those entities with which it is concerned.
• This is best achieved by analysts working closely with representative and authoritative business staff who can together agree upon, name, and define activities in a way that is relevant and acceptable to the business.

CA Gen captures the following details about a process:

• Name
• Description
• Definition properties
• Usage properties
• Expected effects
• Information views
• Dependencies

Note: The properties of processes that are discussed here are optional for all but elementary processes. Usage properties, information views, and dependencies are typically recorded only for elementary processes.

Name

The name of a process consist of a verb-noun combination. The noun is typically the name of an entity type or attribute.

For example:

• Take Order
• Create Invoice
• Terminate Contract
• Calculate Account Balance

Order, Invoice, and Contract are likely to be the names of entity types whose occurrences are manipulated during process execution.

Account is an entity type with an attribute Balance that the process Calculate Account Balance modifies.

Description

The definition of a process, which is stored as part of its description in CA Gen, explains the process does and why it does it.

If these facts are recorded, it is clear that they merely reflect the current approach of the business to implementing the process. The definition describe a single execution of the process.

Who performs the process, when it is performed, or how it is performed are questions that are not fundamental to the existence of the process.

A process that is called Take Order, for example, defined as an order is created based on a customer request, with an order item for each different type of product requested.

The description is the starting point for defining the actions of the process. It is therefore useful to assemble in the description the set of preconditions for an execution of the process, and the post-conditions that arise from an execution. These conditions are discussed later in Dependency Analysis.

Definition Properties

You record the following definition properties for a process:

• Whether it is an elementary process.
• For a discussion of the unique characteristics of an elementary process see Identifying Elementary Processes.
• Whether the process is repetitive, that is, whether it is likely to execute multiple times whenever a precondition arises that causes it to be executed.
• This property simply reminds you that the logic associated with the process (defined during interaction analysis, described in the chapter "Analyzing Interactions") should allow for repetition. The dependency that is associated with the precondition is named a repetitive dependency.
• For example, suppose that the process Recruit Employee is divided into five subordinate processes, as shown in the following illustration.

  

• Whenever an employee is recruited, Advertise Job executes once, so it is not repetitive. However, Interview Candidate executes one or more times depending on the number of interviews of selected candidates, so it is repetitive.
• A repetitive process is indicated by a horizontal bar within the process cushion. See Interview Candidate in the illustration.
• The suggested mechanism for implementing the process, or the principal mechanism if there may be more than one.
• This property is typically recorded only for elementary processes. This is a design decision, but when defining a process, you feel for the eventual implementation and can record this information.
• These are the options for implementing a process:
  • Online—A terminal operator carry out the process, interacting with some sort of terminal device.
  • Batch—A computerized batch job carry out the process, non-interactively.
  • Manual—The process is not computerized; this is not an option for elementary processes.
  • Other—The process is computerized but use some alternative other than online or batch. This classification of process is rare in business situations. Examples include Real-Time Systems and Process Control Systems.

Usage Properties

Usage properties include the "Expected frequency of occurrence," estimated number of executions of a process in a given time period, and the "Expected growth" of that number of executions over time. This information is useful in later stages, when defining databases, for instance.

Expected Effects

Expected effects define, at the level of entity types, the effect that the execution of an activity can have on data. For each entity type with which the activity deals, the analyst specify whether entities are read, created, updated, or deleted (C, R, U, or D).

When recording expected effects using CA Gen, you must have previously defined the affected entity types.

Considering expected effects prompt you to add further entity types to the model. This is one instance where activity modeling leads into interaction analysis.

You record expected effects for a process in process details, or by direct entry in the cells of the Entity Type/Process Matrix. For example, consider the process Take Order, which probably affects entities of the following types:

• CUSTOMER, since the process must read details of a customer placing an order.
• ORDER, since the order is created.
• ORDER ITEM, since each order likely contains multiple items, each of which is created.
• PRODUCT, since each order item is for a particular product that must be read.
• PRODUCT STOCK, since the stock level of a product must be reduced to reflect the number of items appearing on an order item.

The expected effects, then, appear in the matrix that is illustrated in the following table.

Remember that delete is rare in business. For legal, audit and statistical reasons, entities are updated to inactive status and not deleted until, often years later, a separate administrative process deletes entities that are no longer needed for any purpose.

Information Views

The information views of a process describe in detail which entities and attributes are referenced or manipulated during execution of the process.

Defining the content of information views closely associates a process with data. Therefore, the data model is stable before information views are defined. The chapter "Analyzing Interactions" includes a detailed discussion of information views.

Dependencies

Dependencies are the conditions that define how the execution of an activity depends resources, material, or information that are created or available as the result of an execution of other activities, or the occurrence of an event.