In the next paragraphs the most prominent Perspectives Modeling Patterns are described.
Perspectives on Roles
Below a Userrole has a Perspective on Thingrole. The Thingrole has five Properties, one of each type of Property. On the left side the Context Diagram and the Role Diagram are shown and on the right side the generated prototype is shown:
Perspectives on Multiroles
In the diagram below we have made the Thingrole a Multirole and therefore it creates a Table in the generated prototype.
Filler and Filled Role Pattern
In the next pattern the Userrole has a Perspective on a Thingrole that can be a filler for a filled role. This is indicated by the IN relation between the Thingrole (the Filler Role) and the Filledrole. The Role Diagram of the Filledrole (left below) shows the single Property of the Filledrole and the five Properties that the Filledrole will get from the Thingrole.
Normally nothing will happen to the Filledrole when the Thingrole instance is created. But in this case the IN relation’s Autocreate FilledRole flag has been set. As a consequence, the Filledrole will be instantiated automatically when the Thingrole is instantiated. The right side shows this. First the Filledrole form only shows its single Property. After the creation of an instance of the Thingrole the Filledrole will have all Properties of both and their Property Values. This of course will also work for Multiroles.
The Make Pattern
In the next pattern a Userrole has a Perspective on both a Fillerrole and an Filledrole. This pattern is called a “Make Pattern” and enables the Userrole to make a Filled Role of the Filler Role. As soon as the Filler Role is instantiated an option appears as a checkbox: “Make the new Filled Role from the Filler Role. We see that as the checkbox is checked and the Filler Role is saved, the Filled Role is instantiated and has the Properties and Property Values of the Filler Role.
And after checking the checkbox and Save:
This pattern is especially useful when both the Filler Role and the Filled Role are Multi Roles. Instances of the Filled Role can then be based on Instances of the Filler Role. Here a new instance of the Filled Role is based on the selected instsance of the Filler Role:
Note that the fact the the Filled Role now has more Properties as is also the case in the previous examples is not a problem for the model and the data. Properties can be added and removed at will during the modeling process. Here the Human Resource Worker can
The Make Pattern for User Roles
The same Make pattern can also be applied to User Roles. Here the Human Resource Worker can make a Worker a Commerce Worker.
And after Save:
As soon as the Human Resource Worker has made a Worker a Commerce Worker, the Commerce Worker has the Perspectives of itself and the Worker. In this case the Opportunity and the Inbox::
The Be(come) Pattern
The next pattern shows the “To be” or BE relation between two User Roles. This relation defines that a User Role can make itself another User Role. If both User Roles are in the same Context the Another User Role will have the Perspectives of both itself and the original User Role:
Note that now that there are two tabs besides the Home tab, the Worker Tab and the Commerce Worker Tab. Because of the BE relation between the Worker and the Commerce Worker, the Worker can choose the Commerce Worker Tab. As is shown below the Commerce Worker does have both the Perspectives of the Worker and the Commerce Worker.
Note that the BE arrow is half black and half white. This is to indicate that the BE relation is a combination of the IN (Fill) relation and the ON (Perspective) Relation.