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 de Perspectives Diagramming Language (PDL) is defined. The PDL is implemented as a Sparx Enterprise Architect Ad-Inn that can be downloaded here.
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.
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 Role
We can draw pictures of contexts and roles to clarify their relationships.
The video shows how to draw a Context Diagram. Two things might jar with your intuitive understanding of contexts and roles:
- roles filling roles
- contexts filling roles
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!
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.
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.
From business description to software
It turns out that a description such as we have sketched above, using just two type of diagrams, is actually a complete specification of software. As a matter of fact, we can even (in principle) generate software from it. Of course you need to fill in a lot of detail (such as that the invoice due date property we gave above is a date) and usually there are quite a few Actions to describe. But it doesn't get much more difficult than what you've seen above.
We have given Perspectives a very sound mathematical base. We can translate a model into logic. Models have very desirable properties, such as that Roles, Perspectives, Properties etc. can be incrementally added without compromising what has been modelled before. There is a lot more to the theory of Perspectives than that meets the eye!
All that is very interesting to scientists. But for business purposes, we can stick to a few points of understanding:
- anyone can understand a Perspectives model of a business or work situation;
- the model is precise and complete enough to function as a specification for a software building project;
- with a little training, a business analyst can create such models herself.
This puts the business firmly in the driver's seat, when it comes to software projects.
Enterprise Architect
Perspect IT built a plug-in for the program Enterprise Architect (well known among software architects) that supports you 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).
The design 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!
From design to software
An IT supplier uses a deterministic procedure to derive more traditional specifications from a Perspectives model (such as a UML model, epics and user stories). From there on, it will be business as usual. However, because you've given them a formal, precise and complete specification, it will be easy
- for them to set a price;
- for you to formally accept the end result.
Moreover, a readily understandable specification will foster understanding of your business with the IT company, too. All too often programmers work on functionality without having a clue of the wider context in which it should function!
Software generation
Perspect IT will complete automatic software generation from a Perspectives model within a year. This process is better described elsewhere (...). The generated software will be fully distributed (meaning users will connect directly to each other, without an intervening server). Companies open to such a form of deployment should be interested in this development!
Please have a look at www.inplace.one for an example of an App for citizen end users based on Perspectives.