Multiple Views
Describing systems, both for the development purposes and aiming to create post-release documentation, is not a simple task considering today's systems complexity. To understand all aspects of the large systems, we need to look at them from different perspectives and use multiple techniques to describe them:
Each system can be viewed from two different perspectives, the horizontal and the vertical. The horizontal perspective describes different aspects of the system, all being placed at a similar level of detail. The vertical perspective, on the other hand, specifies just a single aspect but looks at it from different levels of detail. While the number of horizontal aspects depends on the nature of that system and is more or less given, the number of levels of detail in the vertical view could be selected by the team according to their needs. The more detailed the analysis is required, the more levels of detail are needed.
Horizontal View - Breadth
To describe a system, it is typically not sufficient to describe just one of its aspects, such as the user interface. To get a whole picture, the system must be understood from different perspectives - user interface, functions, data, security, etc. The following picture illustrates the principle: the diagram on the left shows the static view of how the system interacts with other systems, whereas the one on the right captures the dynamic view, including the order of communication.
Since these two models describe the same system, please note that they both use the same system artifact (Material Management System). Each artifact has a single purpose. For example, a screen always describes how the user interface will look and a database table always defines how the data will be stored. But it is also very common that a single artifact is a part of multiple models (views) that describe different aspects of the system.
Everything Has an Id
Producing multiple views, no matter if horizontal or vertical, has a significant side effect. Looking closer at the provided example, it could be seen that both diagrams include the same artifacts. This might present an issue, as one of the biggest sources of frustrations is duplication. If the Material Management System artifact is used in two models, renaming it will mean changing both of them. This may be a problem if it is not clear in which diagrams the artifact is used. The solution is to store the artifacts in a repository as objects, each having a unique id. Diagrams then only link to the objects in the repository, so renaming the artifact in the database will take effect in all diagrams. If the Material Management System is renamed to MMS, it will propagate the new name automatically to all views.
Assigning each artifact a unique identifier, and storing it in the repository just once, also has another benefit - it is easy to track relationships between artifacts and create impact analysis with a little effort.
This concept is hardly implementable without tools as it requires a modeling tool with the underlying repository. The reference implementation is presented in Part III.
Vertical View - Depth
A natural way of analyzing complex solutions is breaking it down into smaller parts. First, it is decomposed horizontally to individual components, such as modules, user interface screens, or data structures. But if it still remains too complicated, each horizontal component is further analyzed vertically - top-down, from the general high-level aspects to more concrete designs.
Logical vs. Physical
Each problem being analyzed can be viewed from two different perspectives, depending on the level of detail. Common names are logical/physical, analytical/design, or business/implementation description. They all mean the same and express the fact each subject of investigation could be described either from the perspective of stakeholders or from the developers' point of view. While the former uses business terms and high-level IT terminology, the later operates more with technical artifacts that are detailed enough to be implemented but only understandable to the development team. For example, business people talk about "customer information which is retrieved from the CRM system", whereas developers expect you to here "the customer_name and customer_address will be retrieved from the service GetCustomerInfo(cid)".
It is essential to understand that you need to work with both perspectives. Separating logical and physical views is crucial for managing `bigger problems and helps the analyst to slice the problem according to the level of detail being currently known. The analysis is typically done top-down, reminding peeling an onion, going from the surface to the core. But separating the levels of detail is not beneficial only to analyze complex problems, it is also needed when presenting the problem to different audiences. Different people need to see reality from a different perspective, which is complicated when multiple levels of detail are mixed together.
This separation has one downside, though. Describing the same thing twice effectively creates duplications. Unfortunately, it cannot be easily avoided. The only advice here is to keep the logical view abstract enough so that it does not change often. Another practice is to create tracing between the analytical and implementation view so that it is easy to find out what needs to be changed in the lower level once the higher one is changed.
What vs. How - Don't Mix Business Requirements With Implementation Details
Let's have the following process:
The problem with this model is it mixes the business description with the implementation details. On the one hand, it refers to the implementation artifacts, but at the same time, it includes steps that are described only in business language. It says, for example, if the PaymentService.PayOrder returns 0, then a new screen is displayed. This is great for developers but is not understandable to business stakeholders, so they cannot verify the model. Contrary, the model says to "inform the customer if the payment was not successful", which is a solid business description, but is of no use to developers as it lacks information on how to implement it. Should it be a new screen, a dialog, or just a warning message?
But what exactly is wrong about the overlapping layers? The problem is that the presented model cannot be discussed either with the stakeholders or with the developers. Stakeholders will not be able to read it because it is not clear to them how the process should work end to end. And for developers, it does not include all information for development - how the step "Inform Customer the Payment Was Not Successful" should be implemented, for example.
The Thread - Tracing Different Levels of Abstraction
In the previous sections, we described how important it is to cover different levels of detail when analyzing a problem. However, creating multiple views of the same thing comes with the problem the information is spread across multiple models. Therefore, there must be some glue connecting the different levels of detail together, so it is easy to navigate between them to create the whole picture. We call it a Thread.
The point is to replace multiple unrelated artifacts or models with one coherent view in which all layers are interconnected, which makes it easier to navigate between them to get the whole picture of the problem:
To accomplish this, it is required to store all views in one repository, which makes the navigability much smoother. In Part III, we are going to show you how tools can help in this manner.
Tips For Multiple Views
- Start with the process
When starting to analyze a problem, it is beneficial to first put it in context. If the problem is a business issue, the context is mostly best expressed using a process. This tip is elaborated in detail in this chapter. - Create tracing between the different views
The other word for the Thread concept described above is tracing, which means creating relationships between different views. There is a a whole chapter dedicated to tracing.