What is a View
On Dragon1, a View is defined as a representation of a model in which certain entities, patterns, or situations are emphasized or highlighted.
A view is a visual or conceptual representation derived from a viewpoint.
It illustrates specific aspects of the enterprise architecture, such as systems, data, or processes, tailored to meet the needs of a particular stakeholder or role. filter of a model for certain data entities.
In short: a view is a filter of a model.
An example of a view is: Functionally fit Applications, or Inefficient Business Process.
Such views would filter out / hide all applications or processes that are not functionally fit or efficient.
Often, a view is a meaningful aspect or subset of a model.
Other examples of views are:
- Technically fit applications
- Standards Compliant applications
- Cost Heat map application
Dragon1 supports you in documenting and visualizing views in the repository, in JSON files and Excel Sheets.
Read more about how to define Views
Dynamic Views
Views can be static or dynamic. Views can be previously generated or real-time generated.
With dynamic views, whenever the data in the model changes, the view also changes.
Sometimes this is required behavior.
Read more about Dynamic Views
Viewpoints
A Viewpoint is a perspective or focus area from which a model or specific subset of the enterprise architecture is examined.
A viewpoint is the (abstract) point or location from which a stakeholder (role-based) looks at data.
A stakeholder has needs and interests because of their experience, expertise, job, or role. So, there are things they find important to see, understand, or know. With views, we can provide that.
Viewpoint examples are: Financial Viewpoint, Risk Viewpoint, IT Management Viewpoint, TAX Viewpoint, Security Viewpoint, Integration Viewpoint, Privacy Viewpoint.
A view can be linked to a stakeholder and viewpoint.
A financial manager, for instance, will see different things when looking at an application landscape diagram than a network administrator.
This is all because of the different viewpoints they look at models and diagrams (because of their knowledge, skills, work, and interests.
A financial manager might see applications that are too costly and, therefore, are eliminated.
A network administrator might see the same applications as mandatory for the IT organization, and will advise management to keep these applications.
Architects can visualize these different viewpoints and views into 1 architecture diagram to help people decide.
{"class":"viewpoint", "id":"123", "name":"Financial Viewpoint","stakeholders":"CFO,CIO,CEO","interest":"financial aspects of objects","classes","process,application","attributes":"cost,budget,payment","views":"IT cost view"}
With this viewpoint specified, if you select a stakeholder on a visualization or the repository, you are shown a list of viewpoints.
If you select a viewpoint, you are shown a list of views, etc...
Define Views via Classes, Attributes and Values
Dragon1 supports creating and documenting views in the repository on top of models and visualizations.
View is technically made available as an entityclass in the repository.
On Dragon1, you can specify a view that filters out or lets through certain entity classes.
Suppose you have a diagram showing processes, applications, and servers, but you only want to see applications, you can create a view that filters out the processes and servers.
If you provide an attribute and a value to the view specification, then Dragon1 will filter out or only let through data objects that match these attributes and values.
For instance, a view that only shows the logistic applications that are in the cloud and used in the office in Amsterdam.
Dragon1 supports you to define one or more views on top of a model or visualization, as shown below.
{"class":"view", "id":"12345","name":"logistic applications", "modelname":"my enterprise model", "filterclass":"application","filterattribute":"type","filtervalue":"logistics","filter":"in"}
{"class":"view", "id":"12345","name":"cloud applications", "modelname":"my enterprise model", "filterclass":"application","filterattribute":"deployment","filtervalue":"cloud","filter":"in"}
{"class":"view", "id":"12346","name":"Applications used in Amsterdam", "modelname":"my enterprise model", "filterclass":"application","filterattributes":"location","filtervalues":"amsterdam","filter":"in"}
These three views together show only the logistic applications that are in the cloud and used in the office in Amsterdam
Define Views via Relationships
Adding relationships is the second way to define views.
If you specify one or more relationships in a view, Dragon1 will only let through data objects that have a matching relationship.
{"class":"view", "id":"12346","name":"Applications supporting financial processes", "modelname":"my enterprise model", "filterrel-sourceclass":"application","filterrel-sourcetype":"*","filterrel-targetclass":"process","filterrel-targettype":"financial","filter":"in"}
Define Views via Rules
Configuring rules is a third way to define views.
If you specify one or more rules, Dragon1 will only let through data objects of a model that match the rules.
{"class":"view", "id":"12346","name":"Unused applications", "modelname":"my enterprise model", "filterrule":"application.relationship.count=0","filter":"out"}
View Actionscript
Views can be specified via classes, attributes, values, rules, and relationships, but also using action functions.
A full list of can be found here: /help/dragon1-api-action-script
It makes it easy to color, hide, move, or highlight objects that match certain values.
Suppose you want to color all functionally visible applications, you use the colorObjects function as below:
{"class":"view", "name":"functionally fit view", "actionscript":"colorObjects(application,tags,fit,green);"}