Guidelines:
Business Worker

Business Worker |
A business worker represents a
role or set of roles in the business. A business worker interacts with
other workers and manipulates business entities while participating in business use-case
realizations. |
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 use case executes.
An object normally holds different pieces of information that describe some of its
characteristics. Such pieces of information can either be described implicitly in the
textual description of the objects class, or modeled explicitly as an attribute of
the class.
An attribute is of a certain type. An attribute has a name, preferably a noun
that describes the attributes 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. Another example of a potential attribute is a checklist that a
business worker should follow.
Note: You should only model attributes to make a class more understandable!
An operation of a business worker class 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 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 workerthat is, when defining what a business worker
must be able to do in order to produce the desired results of a business use caseyou
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 entitys
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.
- 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 workers 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 workers operations is performed in the workflow of at least
one business use case.
|