Viewpoints, Views, and Models
IT architecture makes use of views to represent aspects of a system from a related set of topics. These topics are related in their shared interest to a unique set of consumers of the information exhibited in the view. For example, the architecture description of an eCommerce website will likely use wireframes to describe the user experience to UI developers. Likewise, a set of PhotoShop mock-ups are of interest to end users who would like to visualize the finished product. Also, an database ERD can be used to describe the website’s backend database table structure to DBAs. All three “views” into the eCommerce website are accurate and complete – in that they represent the full website, but they are perspective-based; given the unique needs of the consumers of the description UI, end product, and database structure.
To carry the example further, let’s imagine that the organization developing the eCommerce website, would like to build other websites of varying degrees of similarity to the eCommerce site. Each potential future website would certainly have a UI, end users curious of the website’s look-and-feel, and database elements that would need to go to the DBAs for review. This would lead to similar views produced for the same types of consumers as the first eCommerce site. In an attempt to increase efficiency, the organization decides to create templates for these views. Each view template could include standard notation, the questions that came from the consumers of the views for the first eCommerce site, as well as common attributes characteristic of a template; such as a title and description of the data in the view. This company could achieve greater consistency, increased efficiency, and an opportunity of quality improvement by refining the template over time and allowing each use of the template to produce a view to provide feedback to the next use.
In an attempt to standardize the production of architecture descriptions for software systems, the IEEE in 2000 released a recommended practice entitled “IEEE Recommended Practice for Architecture Description of Software-Intensive Systems.” For those that are familiar with IT architecture already will know that this is the extremely commonly referenced IEEE 1471, but if you are new to the domain, or are still unclear on the differences between views, viewpoints, and models, hopefully this short description will help.
Views
In IEEE 1741, views are defined as “a representation of a whole system from the perspective of a related set of concerns.” In the eCommerce example above, the three topical views – wireframe, mockup, and ERD diagram, fit this description. Each view attempts to present the whole system, or a subcomponent of a large system, from an interest-oriented purview. This is done so that whoever is interested in the information in the view can understand the system in the way most pertinent to them. In civil and industrial engineering, an example of this concept would be the use of floor plans to describe the structure of the home to a contractor, electrical schematic to describe the wiring plan to an electrician, and a 3d model to describe the end product to the customers. Each view on the physical structure represents the entire building from a specific perspective based on the concerns of the stakeholder.
Models
Models are simply parts of the overall view. For example, wireframes of 10 different screens exhibit the view – the wireframe of the eCommerce site – with 10 different models – one for each screen. In IEEE 1471, models are not given specific definition, but they are discussed in terms of their contribution to a view and their consistency with viewpoints.
Viewpoints
In IEEE 1741, viewpoints are defined as “a specification of the conventions for constructing and using a view.” It goes on to say that they are “a pattern or template from which to develop individual views by establishing the purposes and audience of a view and the techniques for its creation and analysis.” Returning to the eCommerce website example, the process of creating templates for views would lead to the creation of viewpoints. The viewpoint attempts to embody the concerns, or topics, that the consumers of a given view are interested in, and thereby provide the view-creator – that is the architect – the promise of addressing the concerns of the view-consumers – that is the system stakeholders.
Below is a clip of the IEEE 1471 concept model that addresses these three terms with respect to one another:
