What use is a model? We consider an architectural maquette - a scale model of a building, made from paper or plywood - to be a very desirable type of model. It allows many of those involved to review a plan. The fire department looks at it from the perspective of safety and flight routes. An interior designer check the fall of the light. Prospective dwellers see if it holds the rooms they expect. Etcetera.
But what is a model of software? Software is nothing much to look at. Software reveals itself in its *use*. The value of software is closely tied to its usage - a piece of software no one wants to use is, well, useless. So a model of software should be usable. Which leads to the question how it can be a *model*, then, if it is already usable? The software industry resorts to models in terms of *diagrams* and (technical) text. But such models are mostly useless to the average lay person - including, unfortunately, usually the prospective users and Product Owners. IT will create wire frames and screen mockups. But those are mere pictures. One doesn't buy a car from pictures only - we want a test drive!
With Perspectives, we try to walk a middle path. First, we have created a design language that does not rely on technical knowledge. This makes diagrams more readily understandable, even to lay persons. However, they are still diagrams - not usable. So we added, to the diagramming tool, *prototyping functionality*. A software program presents itself as a series of *screens*. A user opens a screen, takes note of information on display, changes some of it, navigates to another screen and this process repeats.
So when creating diagrams describing contexts and roles, Perspectives automatically creates screen elements, too. These have a default layout and style, based on property types. The modeller assembles these basic building blocks into larger units by drag and drop - screens. These screens form a prototype. It may not *look* like the program as it will finally appear when the building project is done - but it certainly is a *usable model* of it.
So, really, modelling is prototyping, too. Let's delve a little deeper into that.
A User Role - in Perspectives - has a Perspective. This is just the collection of Actions the Role can perform in that Context - where consulting information is an Action, too. When the analyst selects a Role in a Context diagram, the tool displays a list of Actions that make op the Role's Perspective.
When the analyst selects such an Action, a dialog pops up that supports the Action. To prevent confusion: this dialog is *not* a tool for the analyst, to refine the Action for example. It is meant for the end user. It is one of these standardised screen elements. By arranging such dialogs on a rectangular area, the analyst designs a prototype screen. It is a model - prototype - of the screen that the end user will see when the application is finished.
Once the analyst has created enough prototype screens, he can simulate a walk through the program for a given User by selecting the corresponding User Role. Screens will pop up and he can navigate through them.



This entire process is so fast and effortless, that an analyst can create a prototype of the application while discussing it with business informants (Product Owners). So they can validate immediately! They validate by a process that comes really close to using the actual, final program. Note how this validation can be done *from all perspectives*, much like those involved in a new building look at it from their own perspectives. This really contributes to detecting potential conflicts, different opinions as to what the program should support. And to detect such time bombs right at the beginning of the process is invaluable.