People, organizations, and the things they do are important aspects of SOA systems. HumanActor and Task capture this as another set of core concepts of the ontology. Both are concepts that are generic and have relevance outside the domain of SOA. For the purposes of the SOA-O we have chosen to give them specific scope in that tasks are intrinsically atomic (corresponding to, for instance, the Business Process Modeling Notation (BPMN) 2.0 definition of task) and human actors are restricted to people and organizations.
This chapter describes the following classes of the SOA-O:
In addition, it defines the following properties:
- does and doneBy
A human actor is a person or an organization. The concept of human actor is captured by the HumanActor OWL class, which is illustrated below:
Figure 1. SOA-O HumanActor Class.
HumanActor is defined as disjoint with the Service and Task classes. Instances of these classes are considered not to be people or organizations. HumanActor is specifically not defined as disjoint with System since an organization in many cases is in fact just a particular kind of system. We choose not to define a special intersection class to represent this fact.
The uses and usedBy Properties Applied to HumanActor
In one direction, a human actor can itself use things such as services, systems, and other human actors. In the other direction, a human actor can, for instance, be used by another actor or by a system (as an element within that system such as a human actor in a process).
The represents and representedBy Properties Applied to HumanActor
Human actors are intrinsically part of systems that instantiate SOAs. Yet in many cases as an element of an SOA system we talk about not the specific person or organization, rather an abstract representation of them that participates in processes, provides services, etc. In other words, we talk about elements representing human actors.
As examples, a broker (instance of HumanActor) may represent a seller (instance of HumanActor) who wishes to remain anonymous, a role (instance of Element) may represent (the role aspect of) multiple instances of HumanActor, and an organizational unit (instance of HumanActor) may represent the many people (all instances of HumanActor) that are part of it.
Note that we have chosen not to define a “role class”, as we believe that using Element with the represents property is a more general approach which does not limit the ability to also define role-based systems. For all practical purposes there is simply a “role subclass” of Element, a subclass that we have chosen not to define explicitly.
Continuing the organizational example, we can now express that P1 (John), P2 (Jack), P3 (Joe), and P4 (Mary) as instances of Element are in fact (people) instances of HumanActor. We can also express (if we so choose) that all of O1 (CarWashBusiness), O3 (CarWash), and O4 (Administration) are (organization) human actors from an action perspective at the same time that they are systems from a collection/composition perspective.
A task is an atomic action which accomplishes a defined result. Tasks are done by people or organizations, specifically by instances of HumanActor.
The Business Process Modeling Notation (BPMN) 2.0 defines task as follows: “A task is an atomic Activity within a Process flow. A task is used when the work in the process cannot be broken down to a finer level of detail. Generally, an end-user and/or applications are used to perform the task when it is executed.” For the purposes of the ontology we have added precision by formally separating the notion of doing from the notion of performing. Tasks are (optionally) done by human actors, furthermore (as instances of Element) tasks can use services that are performed by technology components.
The concept of task is captured by the Task OWL class, which is illustrated below:
Figure 2. SOA-O Task Class.
Task is defined as disjoint with the System, Service, and HumanActor classes. Instances of these classes are considered not to be atomic actions.
does and doneBy Properties
Tasks are naturally thought of as being done by people or organizations. If we think of tasks as being the actual things done, then the natural cardinality is that each instance of Task is done by at most one instance of HumanActor. Due to the atomic nature of instances of Task we rule out the case where such an instance is done jointly by multiple instances of HumanActor. The cardinality can be zero if someone chooses not to instantiate all possible human actors. On the other hand, the same instance of HumanActor can (over time) easily do more than one instance of Task. The does property, and its inverse doneBy, capture the relation between a human actor and the tasks it performs.
uses and usedBy Applied to Task
In one direction, the most common case of a task using another element is where an automated task uses a service as its realization. In the other direction, a task can, for instance, be used by a system (as an element within that system, such as a task in a process).
represents and representedBy Applied to Task
As mentioned in the introduction to this section, tasks are intrinsically part of SOA systems. Yet in many cases as an element of an SOA system we talk about not the actual thing being done, rather an abstract representation of it that is used as an element in systems, processes, etc. In other words, we talk about elements representing tasks.
As a simple example, an abstract activity in a process model (associated with a role) may represent a concrete task (done by a person fulfilling that role). Note that due to the atomic nature of a task it does not make sense to talk about many elements representing different aspects of it.
Continuing the organizational example from above, we can now express which tasks that are done by human actors (people) P1, P2, P3, and P4, and how those tasks can be elements in bigger systems that describe things such as organizational processes.