Modeling Perspectives

Modeling Perspectives is easy. It is all about determining the actions of roles, or more specific user roles or bots, in a context and adding properties to the views of roles and actions. In the whitepaper the Perspectives Diagramming Language (PDL) is defined, the diagram language we use in Perspectives modelling. The PDL is implemented as a Sparx Enterprise Architect Add-In that we use in our Perspectives Projects. Here is a short description of the Perspectives modelling concepts:

• Context: a background in which roles perform actions. Examples of contexts are a case, an activity, a party or a domain
• Role: Perspectives defines active and passive roles. Active roles are also called Agents and are Users or Bots. Agents can be the subject of an actions, ordinary roles can not.
• Action: AnAction performed by an Agent as subject and another role as Object
• Property: a attribute of a Role. Only Roles have Properties. Property types are Text, Date, Number etc.
• View: a selection of Properties of a role that is relevant in the context of an Action

The modelling process

As there is no gap between the way employees and managers talk about their work and its Perspectives description, analysts find they can actually keep track of a (well moderated) discussion between experts. This means that a model can be created live, as the experts speak.

The process is reminiscent of those 'brown paper sessions' that famously promote mutual understanding between co-workers. But Perspectives goes far beyond free-style post-it tacking. Your result is a runnable system prototype and perfect specs for actual system development.

So, in the very same sessions, experts can get a feel for how screens may look and feel (again, please note that it's generic screens with generic design we're talking about!).

Just think of how this speeds up the early stages of a digital transformation project!

Let's assume you've taken up a new job, as store supervisor. Sitting with friends, you tell them about what your new role involves. These are some typical actions you would be expected to perform:

• schedule staff shifts
• hire new employees
• draw up budgets
• check on deliveries

When checking on deliveries, you wouldn't scrutinise every detail. Instead, you'd be interested in expected delivery time, a report from the work floor on the delivery (is something missing?) and the contact details of the supplier in case something went wrong.
Obviously, for the warehouse manager who actually handles the delivery, knowing in advance what goods (and in what quantities) will delivered, is important to be able to handle them adequately.
Colleagues of finance are interested in other properties of the delivery. They must know about the cost breakdown and payment deadlines.
So, from their respective roles, each will have a different view of the same delivery.

Hiring employees

When hiring staff, an interview committee might be involved. The store chain might have as a rule of best practice that the HR manager always heads that committee. You will be a member. So, in this context, you play a secondary role even if you have end responsibility over the store. The HR manager will have scanned the applicants beforehand. Nevertheless, the decision to hire would be yours. So the roles on the committee are allotted according to positions in the store, and role responsibilities are clearly defined in terms of actions.

Let's focus on some core concepts (italicised in the above):

• Context: the store, the interview committee
• Role: store supervisor, HR manager, warehouse manager
• Action: check on deliveries, hire staff, etc.
• View: we've seen three, on the delivery: the logistical details, the financial details and the contact details
• Property: cost, delivery date and time, contact telephone number.

Context and Roles

We can draw pictures of contexts and roles to clarify their relationships. The video below shows how to draw a Context Diagram.

Usually we think of people taking up a role. However, in the job description above we actually wrote the HR manager always heads (the job interview) committee. If you look closely, you see two roles. In designing Perspectives, we found it very useful to use that notion. In fact, we speak of a role telescope: roles filling roles filling roles, etc.

What about a Context filling a Role? The job interview committee plays a role in the organisation. There, we've actually said it! However, it is a Context in its own right, as it has Roles (the chair, other members, and - oops, we forgot: the interviewee!).

So Contexts are related through Roles. When looking at a Context as it fills a Role, you'll only see its 'outside properties'. But when you actually play a role in a Context, you'll be able to see other Roles, too. And to perform Actions!

Actions

Roles and Views get together in Actions. An Action is easily described in a sentence, such as The warehouse managers changes the 'complete' property of the delivery. Here, the warehouse manager is the subject role and the delivery is the object role.

Now, in Perspectives, we'd put this just a little differently, bringing in the View available to the warehouse manager: The warehouse manager changes the delivery with the 'warehouse manager view'. Notice how we used the view's name as introduced in the video. It is actually not such a good name: in a real setting we'd find the workfloor uses a more adequate name.

We can draw Actions, too.

Collectively, we call the Actions available to a Role, the Perspective of that Role on its Context. We consider consulting some information on the screen to be an Action, too. Actions are part of the context diagram.

Properties and Views

We only allow Roles to have Properties. However, because we have a Role representing a Context (the circle outside), actually Contexts have Properties, too. Let's draw some Properties on a Role.

In the video, we drew a Role Diagram. Such diagrams just show the Properties on a role and how properties are collected in a View. Above, we referred to the Role telescope. If you draw a Role diagram on a Role that is part of a telescope, you'll see Properties on Roles higher up in the telescope, too. The meaning of this is that from a Role, you may have access to properties of the Role that fills that Role.

Enterprise Architect

Perspect IT built a plug-in for the Sparx Enterprise Architect (well known among software architects) that supports in drawing and managing large models. This plug-in allows you to validate your design by generating screens for Actions. These can be composed into more meaningful units by drag and drop.

It is important to understand that these screens are not production-ready software. Rather, they support a validating process. End users generally like to judge ideas more by getting a hands-on feel of what will come, than by reading designs (however understandable these designs may be).