Moreover, when designing the software for a large, complex system, it will be necessary to consider more than one structural perspective as well as the relationships among them. Though one often thinks about structure in terms of system functionality, there are system properties in addition to functionality, such as physical distribution, process communication, and synchronization, that must be reasoned about at an architectural level. These other properties are addressed in multiple structures often referred to as architectural views. They are also sometimes referred to as architectural models, but again the terminology has not settled enough yet to be dependable. Each different view reflects a specific set of concerns that are of interest to a given group of stakeholders in the system.
Views are therefore abstractions, each with respect to different criteria.
Each view can be considered to be a software blueprint and each can use its own notation, can reflect its own choice of architectural style, and can define what is meant in its case by components, interrelationships, rationale, principles, and guidelines. Views are not fully independent, however. Elements in one can relate to elements in another so while it is helpful to consider each separately, it is also necessary to reason rigorously about the interrelations of these views. Whether the structures describe the product, the process of building the product, or the process of using the product to solve a problem. All the views discussed in this section are of the product.