Chapter 8 Comparative Analysis of Ontology Charts
8.2 Modelling Techniques and Related Theories
OC is the diagrammatic language used in Stamper’s OS theory and the out- come of applying the method of SAM to an organizational problem. The underlying theory – OS theory – is based upon two simple assumptions:
1. There is no knowledge without a knower, and 2. His knowledge depends upon what he does.
These assumptions lead to the notion that any language for representing business, organisational, or social knowledge should have well-formed formulas (wffs) with the following syntactic structure: <knower-term>
<behaviour-term> or <agent-term><action-term>. The behaviour-term relates to actions afforded together by the agent and the environment.
Individual elements in the environment are seen from the perspective of the actions they make possible or afford for the agent and are referred as affordances. Affordances are the patterns of behaviour afforded by a par- ticular element. For example, a cup may be seen as an affordance because it affords drinking, holding liquids, throwing it, (patterns of behaviour).
Some affordances cannot exist without the existence of others; swimming is not possible without being immersed in water. In this case we have an ontological (or existential) dependency between affordances. Ontological dependency is the main relationship between affordances. Besides behav- iour, which is afforded by the environment, there are also norms that guide agent’s behaviour. These norms are social in nature, like laws, regulations, rules, which constrain or determine agent’s actions. Norms are shared by people and can jointly form information fields (IF) leading to a new para- digm – the IF paradigm. An IF corresponds to a set of norms, shared by a specific social group such as a family, an organization, and a department that regulate their expected behaviour.
Agents and affordances are represented as nodes in OCs, while ontologi- cal dependencies (OD) are the lines connecting these nodes. Specialised OD includes generic/specific and whole/part relationships. Affordances can be substantive, representing here and now, or semiological, standing for other affordances. Agents may have roles in the scope of an OD. Time is also present in OCs – leftmost affordances must exist for the ones on the right side to exist.
A missing element from OCs, although an important concept in OS, is Norms that are represented in OS using a formal language. Although absent, they can be and are implicitly attached to affordances specifying, among other things, the start and finish of those affordances and the authority (ies) responsible for acknowledging its existence.
8.2.2 UML activity diagrams
The unified modelling language (UML) is “… a graphical language for visualizing, specifying, constructing, and documenting the artifacts of dis- tributed object systems” (OMG 2003).
UML was adopted as a standard by the Object Management Group (OMG) in November 1997 and was the result of merging and adapting dif- ferent notations from different methods and methodologies used for ana- lysing and designing software systems, which applied the object-oriented paradigm.
UML became one of the most used modelling languages in the “software development world” and its flexibility, and extension capability allowed to be adapted and used in different areas such as business processes and infor- mation systems. UML defines nine diagram types (version 1.5 and before) which are described in Table 1.
In this work we will be interested in business processes and information system models, which exclude UML implementation diagrams. From the remaining diagrams the most commonly used for business modelling are activity diagrams, which enable the representation of the popular flow- charts and workflows. In addition, but not analysed here, case diagrams can be used to describe system functionalities and class diagrams to de- scribe a static or structural view of different (business) entities and their relationships.
In this chapter we will be interested in activity diagrams as a complemen- tary and standard diagram for our comparative purposes. Activity diagrams are used to represent activities, actions, and their sequence, sometimes pre- sented and related to a responsible or performing actor that can be a human or a system. A course of action or sequence can be split in alternative routes by adding a decision element and a guard condition that will specify the route according to the (true) value of the condition. It is also possible to rep- resent parallel actions using a fork at the start of the concurrent group of actions and a join element at the end. Objects associated or necessary to the actions and activities can be shown as attached notes.
Table 1. UML diagrams
Diagram type Diagram name Use Structural
(static)
class To show classes (or classifiers) and their attrib- utes and operations. Also relationships among classes are shown. Represents a static structural view of the entities and their relationships.
object To show a snapshot of the detailed state of a system, namely objects and data values at a point in time.
use case To show the relationship among use cases within a system and their actors. Tell us the functionality of a system.
sequence To show an interaction or the exchange of mes- sages among objects and/or actors. It provides a temporal view of the messages being exchanged.
collaboration To show collaborations containing a set of roles and the required collaboration relationships. To de- scribe the realisation of an operation or a classifier.
statechart To describe the behaviour of instances of a model element such as a class instance or a spe- cific operation. Includes possible sequences of states and actions in response to events.
Behavioural (dynamic)
activity To show a sequence of actions. It is a special case of a state diagram in which states are action states and transitions are automatic upon com- pletion of the actions inside action states.
component To show dependencies among software compo- nents. It’s a structural and logical view of soft- ware components and their relationships.
Physical
(implementation) deployment To show the configuration of run-time process- ing elements and the software components, processes, and objects that execute them.
8.2.3 Role-activity diagrams (RAD)
RADs were introduced by Holt et al. (1983) and further developed by Ould (1995; 2005). We will refer to Ould’s RADs in this comparison.
RADs constitute the main modelling language used by the Riva method (Ould 2005), which is a method for the elicitation, modelling, analysis, and design of organisational processes. In Riva we are interested in business processes understood as “a coherent set of actions carried out by a collabo- rating set of roles to achieve a goal” (Ould 2005, p. 32). RAD shows busi- ness processes personalised by one or more interacting roles. Roles are acted by one or more people – the actors which carry the responsibility for that role. Computer systems can also be modelled as roles. A role is repre- sented as a shaded area containing a sequence of actions, including alterna- tive and concurrent paths of actions, role states and role state descriptions, and initiators of actions (triggers). Actions are considered atomic and no further decomposition is allowed. An important aspect shown in a RAD is the interaction between roles, which represent explicitly the collaborations between roles. The start of a role can also be presented in a RAD.
8.2.4 DIPLAN plans
The DIPLAN language, described in Holt (1988), is the diagrammatic lan- guage used by the Theory of organized activity (TOA) (Holt 1997). This language was adapted from Petri Nets and permits simulation and action sequence analysis. TOA is based on “human” activities, which occur within every organisation or business system. Human action is the key element for the structuring and planning of all activity processes. An action in TOA corresponds to the unit of human effort, whereas bodies represent material or physical units. Every action is doubly performed by organisational enti- ties, for example, a department, a president, a committee, and by a person.
Actions and bodies are related by involvement: every action involves at least one body; every body is involved in at least one action. TOA defines dif- ferent types of involvement between actions and bodies, namely creation, destruction, support, use, state change, and definition. An important aspect of bodies is that only bodies can have states which create alternative sets used for decision. According to this principle information consists only on these alternative sets used for decision. For example if someone decides to buy a pen only the elements such as price and writing colour effectively used in the decision constitutes information.
TOA is social in nature, any element or unit as called by the theory is acknowledge or identified by a criterion maintained by a community bound together by a shared organised activity – a criterion by which its members decide whether a given something is, or is not, a realization of the unit. The diagrams defined by DIPLAN are used to present plans de- scribing organised activities. In DIPLAN the main elements are actions,
bodies, and (involvement) relationships among them. Bodies represent physical objects either humans or materials, and are related to the spatial dimension, whereas actions are related to the time dimension and always connected to a human performer.
8.2.5 Dynamic essential modelling of organisations (DEMO) models
The DEMO methodology is based on the language action perspective, mainly inspired by the book of Winograd and Flores (1986) and based on James Austin’s speech-act theory (1962), which was formalised in part by John Searle (1969). This book presents and proposes a design of computer systems based on a linguistic model of conversation for action. A language- act may be explained as the utterance of a sentence seen as an action. In this case it is called a performative utterance having a general form given here through this rough definition: When we say something (a locutionary act), with the intention or the effect to change the world (or acting on the world) in some way, we are performing an illocutionary act, being those changes perlocutionary acts.
DEMO defines the elements of a communicative act, with an illocution- ary part and a propositional part that is represented formally by the OER1 notation:
<locutor> : <illocution> : <addressee> : <fact> : <time-for –completion>
Connecting these elements forms the DEMO basic building block of every business system – the business transaction. A business transaction is composed by an order phase, an execution phase, and a result phase. The first and last phases are seen as performative conversations and are used to reach an agreement respectively, on the request and on its successful re- sult. The middle phase is the necessary (objective) action associated with the request. DEMO sees a business system as “a coherent structure of transactions” and proposes six different models each one associated with a correspondent diagram. Table 2 gives a brief overview of these diagrams.
In order to keep this analysis simple and short, we will use only interac- tion diagrams which identify the main elements of DEMO approach, namely: actors and transactions. The other models go further in the analysis by giving detailed description of transactions such as their phases and se- quences, structure, states involved, and information facts.
1 OER stands for Order Phase, Execution Phase and Result Phase.
Table 2. DEMO diagrams Diagram name Use
Interaction To show the different transaction types (business transac- tions at the type level), initiating and executing actors, and the system boundary.
Business process To show the transaction phases, and their causal and condi- tional or optional relationships providing a time aware view of business transactions.
Transaction process To show the structure of transactional communication by describing the possible communicative actions and transac- tion states in a business transaction process.
Action To show action rules through procedures (a kind of flow- chart) that is applied to every distinct non-terminal state of each transaction type.
Fact To specify in a precise and complete manner the informa- tion space of an organisation under consideration.
Interstriction To show informative conversations, information banks, and actors.