Artifacts > Business Modeling Artifact Set > Business Object Model... > Business Worker > Guidelines


Business Worker
A business worker represents a role or set of roles in the business. A business worker interacts with other roles and manipulates business entities while participating in business use-case realizations.
Topics

Explanation To top of page

A business worker represents an abstraction of a human that acts within the business. A business worker object interacts with other business worker objects and manipulates business entity objects in order to realize a business use-case instance. We use worker individual as a synonym for business worker object.

A worker is instantiated ("manned") when the workflow of its corresponding use-case instance is started or, at the latest, just in time for the person doing the job to play his role in the use-case instance. A worker object often "lives" (the person is engaged) as long as the business use case executes.

Attributes To top of page

A business worker may have a checklist she must follow. She may also have information that she provides to other workers or business entities as she executes a business use case, such as her security level, e-mail address, and so on.

This kind of information can either be described implicitly in the textual description of the business worker, or modeled explicitly as an attribute of the business worker.

An attribute is of a certain type. An attribute has a name, preferably a noun that describes the attribute’s role in relation to the class. An attribute type can be more or less primitive, starting from a simple number or string. Different classes can have attributes with identical structures. Those attributes should share a description; that is, they should share attribute type.

An attribute may be more or less tangible. For instance, you might model as an attribute the information that a certain business worker must keep in mind as he executes a business use case. For example, characteristic "suspicious behaviours" are kept in the minds of trained customs agents to identify who to pull aside for questioning.

Note: You should only model attributes to make a business worker more understandable!

Operations To top of page

An operation of a business worker represents a specific activity to be performed by an individual of that class. The operation of a business worker is initiated by a message from another worker individual or from an actor. An operation has a name and, optionally, parameters.

An operation describes a task a business worker may be asked to perform. It is initiated by a message. A business worker represents a role played by an employee. To perform the job in a use case, the person acting as a business worker performs one, or several activities.

When designing a business worker—that is, when defining what a business worker must be able to do in order to produce the desired results of a business use case—you have two alternatives. You can either:

  • Write a general textual description of the work, or
  • Explicitly define each activity in the form of an operation, which in turn should be described textually. For each operation, you define what message initiates its execution.

Each operation is defined by a name, which should tell its purpose, and optionally, a number of parameters. The parameters specify what an object of the class should expect to receive from an object that is requesting support or making an access, and what the object will provide when the operation has been performed. As an example, you can give parameters that reflect when a business worker should take a step in the worker operation, or when he should access a certain business entity by initiating one of the business entity’s operations. Parameters can also represent more or less tangible things that are handed over.

Operations can be defined informally, or in more detail, depending on the importance or required level of detail in a use case. A "more detailed" description might describe a behavior sequence that tells which attributes and relationships are dealt with during its performance, how objects of other classes are contacted, and how it is terminated.

Business Worker Characteristics To top of page

The characteristics of a business worker should cover the following topics: 

  • Prior knowledge and experience
  • Physical characteristics
  • Social and physical environment 
  • Job, tasks, and requirements
  • Cognitive characteristics

This type of information is only useful to capture for "human" business workers. 

Checkpoints for Good Business Workers To top of page

  • Its name and description are clear and understandable.
  • Each business worker has an association to the business entities it must know about.
  • Each business worker has a link to the other business workers it must communicate with.
  • A business worker’s relationships do not depend on each other.
  • Each business worker participates in at least one business use case.
  • Each relationship is used in the workflow of at least one business use case.
  • Each of the business worker’s operations is performed in the workflow of at least one business use case.
 

Copyright  © 1987 - 2001 Rational Software Corporation


Display Rational Unified Process using frames

Rational Unified Process