Explanation

A business worker represents an abstraction of a human, software or hardware, or a composite of these, 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.

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

When you choose to bind a human worker to a business worker role, you are also creating a mapping into the RUP Worker Viewpoint (see Concept: System Architecture) and its extension in business modeling, the Human Resources View (see Concept: Business Architecture). This is important when considering the attributes, operations and characteristics of the business worker, to ensure that they are supportable within the organization.

Attributes

A human 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 behaviors" 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

An operation provided by a business worker represents a specific task to be performed by an instance of that class. The operation of a business worker is initiated by a message from another business worker object 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. To perform the role in a use case realization, a business worker performs one, or several tasks.

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:

• Write a general textual description of the work.
• Explicitly define each task 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 describe 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 perform a particular step in the operation, or when the business worker should access a certain business entity by initiating one of the business entity's operations. Parameters can also represent tangible things that are exchanged.

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

The characteristics of a business worker are really constraints on whatever is chosen to fulfill the role. For example, in the case of a human business worker, you may be concerned about:

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

The successful performance of the role may depend on the performer meeting these criteria or being comfortable in a particular environment.

Similarly, software systems, and systems generally, may have constraints expressed on them to be suitable for use - performance, capacity, responsiveness, for example.

Checklist for Good 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 realization.
• Each relationship is used in the workflow of at least one business use case realization.
• Each of the business worker's operations is performed in the workflow of at least one business use case realization.