On Perspectives

There are several reasons for developing Perspectives. One is the complexity and verbosity of current modelling languages such as the Unified Modelling Language (UML). More than ten different diagrams, overlapping in their purpose to cover different aspects of a system with no clear semantics how to combine them. More than 50 artefacts with the implicit invitation to use and interpret them in the way that suits you. 

Then the Business Process Modelling Notation (BPMN) does a better job.  The problem with BPMN however is that it implicates a rigid process that is known upfront. This may be accurate for structured processes where the distribution of work is predefined but that makes it unsuitable for knowledge work and knowledge workers. 


There are two reasons for this. The first is to emphasise that here are different perspectives on the same thing. Perspectives that depend on goals and responsibilities of the observers. It is important to understand each other’s viewpoint to be able to discuss and compromise.

The second is that Perspectives provides insight into the way the resulting system will look like and function in the future. It provides perspectives on the system to be for each stakeholder.


In Perspectives an Action has a Subject (Role) and an Object (Role). The first is the Agent that executes, or better is permitted to execute, the Action. In Object Oriented (OO) Analysis and Design there is not such a Subject Role. All behaviour, both calculations and control are distributed among the Objects.

OO lacks the notion of Agency. In other words: in OO modelling the question of  “Who” performs or requests behaviour is never asked. Let alone the question of who is permitted to do so. This means that the role of the user, as one of the possible Actors is not modelled intrinsically and will be an afterthought.

Moreover, OO lacks the notion of Context. This means that in OO it is not possible to modularise object behaviour other than that of the classes that define them.

Finally, OO lacks the notion of Role. Role in the sense of a concept that has different state and behaviour in different contexts. Of course in UML we can model Association Classes as placeholders for role-attributes but this seems to be an exception more than a fundamental pattern as in Perspectives.

This is not to say that OO is inadequate or useless. It is just not suited for modelling Business processes and their consequences for Information Management. Together the notions of (permitted) Agency, Context and Roles are essential in modelling business domains and the behaviour of Actors in these domains.


Perspectives Principle

The Perspectives Principle describes the vision we have on what a Perspective is: “Perspectives are the available Actions of Roles in Contexts”. This means that when I have Role in a Context I can execute certain Actions, more specifically, Information Actions such as consulting, creating and changing information. The available Actions depend on the Context and the Role I play in the Context.


According to literature a Context is the background by which events can be interpreted. An event can not be understood without its context and vice versa. In Perspectives a Context is just that. A background in which events occur, events such as Roles, more specifically Actors, performing Actions while they collaborate.  Therefore in Perspectives a Context is a container of behaviour. When users switch Contexts, they will perform different Actions, dependent on the Role they play in the new Context. This is the root of the Perspectives Principle: “Perspectives are the Actions of Roles in Contexts”.

In Perspectives we define five different types of Contexts:

  • Domain: An area of interest defining relevant Parties and Cases
  • Party: Individual, Group, Team or Organisation that operates in a Domain
  • Case: A  management Context in which Parties work together to achieve common goals
  • Activity: An operational Context with Actors that perform practical Actions
  • State: A State within a Case or Activity that constrains the available Actions of Roles 



A Role is the only concept in Perspectives that has Properties. Roles are the Entities of Perspectives but there is a difference that is essential to the philosophy of Perspectives. An Entity is and absolute collection of Properties, independent of the context in which it is relevant. In contrast, a Role has Properties dependent on the Context in which it is relevant.

Perspectives defines three different types of Roles: Role, User and Bot. Users and Bots are called Actors and can be the subject of Actions. Roles can only be the object of Actions. Of course, actors can also be the objects of Actions because others can do things with the Objects of Actions.

Roles are filled with other Roles. This is modelled by the “in” connector, the only connector, in the diagramming language. When a Role is filled by another Role the Properties of the first become available in de second. This implements the notion of inheritance in Perspectives. When an Actor is filled by another Actor, not only the Properties of the first become available in the second, more importantly the Actions of the first become available in the second.


An Action is defined as a elementary sentence with a Subject, a Verb and an Object. The Subject and Object are the Roles of an Action and are filled with other Roles in the Context of the Action. The Subject Role can be filled by an Actor (User Role or Bot). The Object-Role can be filled by all types of Roles.

Perspectives defines five types of Actions. The generic Action can be defined by the modeller and represents a Business Action. A Business Action is an Action specific for the Domain. Business Actions are transformed into one or more Information Actions of which there are four types Consult, Create, Change and Remove.


A Property holds information of a Role. Perspectives defines five basic types of Properties:

  • Boolean,
  • String
  • Number
  • Date-Time
  • Option

The string can represent different things:

  • a Text item
  • a Memo
  • a Filename

When a Role is filled with another Role, its Properties are augmented with the Properties of the filling Role. This constitutes the notion of Property Inheritance in Perspectives.

Just like a View in SQL, a View is a Selection of Properties of a Role. Unlike the SQL View,  the Perspectives View only defines the Property selection and not the function (eg. Update, Insert) that operates on the selection. Every Role has an “Local Properties” View. This contains the Properties that are locally defined for the Role.

The modeller can create additional Views for Roles that are selections of the Properties in the Local Properties View and can contain Properties of the fillers of the Role.


Perspectives Method

Or otherwise stated: “is it better to first add detail to (an embedded) context or is it better to first model more contexts and then start detailing them?”. Our experience shows that one of the pitfalls in Perspectives modelling is that much of the precious workshop time is wasted on irrelevant details delving too deep in embedded Contexts. So it is better to model breadth first. This makes sure that in an early phase, the scope of the Project becomes clear, and the participants can decide how much time and effort will be spend on certain details.


At the start of a Perspectives Project the focus of attention is determined. We call this the Common Subject. It is a Role or Context that is common to all stakeholders and serves as an index of all information and information actions in the domain. The type of Common Subject depends on the purpose of the modelling project. This may be of an  Strategic, Tactical or Operational nature.

Strategic perspectives are focussed on domains and parties. An example would be to focus on an organisation in a domain and determine other domains or parties in its context that influence the behaviour of the organisation. This is expecially useful in re-assessing the role of an organisation in its changing context.

In Modelling Tactical Perspectives we typically put a case in focus and model the role different parties play in the context of the case.  The main question here will be: “Who is responsible for what concerning the case”. Take for example a Customer Account. This would be a continuous case that represents all events, actions and activities that occurred and will occur involving a particular Customer.

Operational Perspectives put an Activity or even a State within an Activity in focus. Here also the main question is: “Who does what with respect to the Activity” but now, not so much from a responsibility perspective as in Tactical analysis, but from a practical perspective.

The Perspectives Method is particularly suited for modelling Tactical perspectives. However, they can be detailed into Operational perspectives. However, it can also happen that from Tactical perspectives Strategic questions arise that must be solved.

It is useful to separate the perspectives of Actors that are involved in the operation in a domain and the managerial perspectives that are interested in management information. Obviously, we first model the operational perspectives and later the managerial. The important question to ask is whether all information managerial perspectives are interested in, is created during the operational processes. If not, extra information has to be produced during operations. All possible should be done to create this information automatically to prevent additional information actions during operations.

Perspectives Software

The Perspectives Software, called Perspectives4EA, is an Add-In for Sparx Systems widely used Enterprise Architect (EA) Case Tool. Importing the Add-In to EA, the Perspectives Modelling Language becomes available and can be combined with other modelling Langages such as UML and Archimate. It is important to note however,  that the Perspective Modelling Language  and Perspectives4EA is designed to offer standalone support without requiring integration with other modelling languages.

Perspectives4EA does not only support modelling Perspectives but also generates prototypes. When a User Role is double-clicked immediately a Perspectives Dialog appears that shows the Actions of the User Role in question. From this the appropriate screen for the User’s Actions is composed. This enables validation and repair of the modelled Perspectives during the modelling workshop.


Alas, not yet. At the moment we apply it in the first projects and use the experience to improve it step by step. This phase will last until summer (2019). After the summer we will make it available and support it with educational resources.

Perspectives Uses

Suppose an organisation wants to re-asses its role in its context. Examples of research questions that may arise are:

  • Who are our customers?
  • Who are our competitors?
  • Which products and services will we offer?
  • How do we get the right human resources?

One way to get answers on these questions is to model the organisation (party) as common context in a broad context that includes other parties and roles. And then model the Perspectives that these parties and roles have in the context of the organisation. 

By definition, these Perspectives are the Actions the contextual parties and roles have in the context of the organisation.