Architectural views represent a perspective of looking at a particular problem solution. There are different standards. And different versions of diagrams. That is because one diagram rarely would give you everything you'd want. So you sort of mix and match. We have to recognize that there are many stakeholders in the system: from architects themselves, maintainers, clients, and safety/security assurance. Essentially, we need the right diagram to the particular audience. If we are taking to clients who are interested in e.g. ensuring smooth business process than to software engineering who are interested in a particular QA.
It is very much about communication, ability to sell your solution. If you use incorrect view, you are likely to receive negative feedback, not because your solution is bad, but because your audience doesn't understand it. This may sound quite obvious now, but wait until you actually have to do a presentation. The idea of the diagram is to communicate information, therefore it needs to be as clear as possible. Using convention: starting from top to bottom and from left to right.
Generally, 'commonly' used approaches do not work unless everybody in the room has the same information. There are 2 main advantages of using common approaches: (1) everybody understands it and (2) usually there are tool available to use to make use of particular notation. Within the team, you might want to use standard approach, but outside, you may wanna create something which can be understood by audience.
There is IEEE P1471 - Recommended
View - expression of the system architecture with respect to some viewpoint (view is an 'instance' of the viewpoint)
View point - particular way of looking at the problem (things which are recommended to be in the diagram)
Viewpoints
An architectural description will present view relating to a number of different view points, specified by:
- Viewpoint Name (e.g. behavioural point) - needed for communication
- Stakeholders addressed by that viewpoint - You need to use a viewpoint which addresses the concerns of our stakeholders
- The vocabulary, language, modelling techniques or analytical methods used in constructing the view associated with the viewpoint - wide variety languages inc. UML
- Source (+ configuration information)
- Rationale - Why this viewpoint?
UML class diagram is a viewpoint. They in a way correspond to metamodels, how to present something from a different angle. Think who is going to use the view.
Views
View are usually used as ways to prove that the key scenarios are being addressed.
Structural Viewpoints
When the number of diagrams exceeds 7, this is one needs to start thinking about spiting. This is a general rule, but a useful one.
There also view cultural differences between audiences. For examples, people from the middle read from right to left. This can make the diagrams harder to read.
Generally, go from left-to-right and top-to-bottom.
When presenting the architecture (view) it might be useful to use animations.
Behavioural Viewpoints
Behavioural viewpoints are primarily concerned with expressing the dynamic actions of and within the system. Generally speaking, they are the kinds of actions the system produces and participates in and of course how those actions relate and interact (ordering, synchronization, etc.).
Behavioural viewpoints can be expressed through vocabulary, language (e.g. Wright, Dawin, Rapide), modeling technique (Events, processes, states, operations on entities) and analytic methods (CSP, pi-calculus, posets). UML Sequence diagram might be used as to model behavioural view.
Data Viewpoints
They are concerned with how to enterprise data is 'defined, organized (i.e. structured), accessed and maintained". The people who would normally use these views are data administrators, producers and composers of capabilities. The view would focus on:
- How data is accessed
- How data is interpreted
- What metadata is available about data
There are a number of modelling methods available to produce data views. These include but are not limited to: data access capabilities, interfaces, data stories, data models, metadata, ownership and security, ACID attributes, inheritance, extensions, aggregation (part-of), access rights, security restrictions, and consistency information.
UML class diagrams might be an example. Other Entity-Relation diagrams. Generally speaking, there will be too much to convey in one figure.
Security Viewpoints
Essentially, how the secruity would be integrated into the system. Stakeholders include: users, owners, accreditors, developers, etc. The primarily focus lies on
- Who can see what?
- How is access controlled?
- How are compromises detected and reacted to?
Modelling methods include: threads! subjects, objects, mechanisms (e.g. guard firewalls). Ready made viewpoint languages exist such as Bell-Lapadula.
Which views to use
The general consensus is that multiple views have to be used in order to document architecture.
A software architecture is a complex entity that cannot be described in a simple one-dimentional fashion"
Clements et. al.
There are a number of view 'packages' which have been designed in order to help presenting views:
- Siemens model - 4 views [Hofmeister et al]
- SEI appraoch - 3 view types [Clements et al]
- Kruchten - 4+1 Views (i.e. 4 Views + Scenario) - the concept is based on the notion that scenario is also a view
- IEEE P1471 - a number of (custom) viewpoints
SEI Approach
SEI argue that there are three 'viewtypes':
- The module viewtype - principal units of implementation i.e. the basic structure of the system.
- The Component and Connector (C&C) viewtype - units of excution i.e. what is the runtime of the system
- The Allocation viewtype - relationship between a system's software and its development and execution environments.
A viewtype contraint is a set of elements and relations that exist in its views.