Guidelines: Business Worker
Topics
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.
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!
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.
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.
- 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.
|