So far, the system has been described on a very abstract level only reflecting its purpose. The implementation of most components is still undefined. We see a high-level structure, which also could be explained with a few words. Looking at the block diagram (figure C.1), we only learn that the customers and interested persons are expected to be humans. Nothing is said about how the reservation system, the help desk, the travel organization are implemented, how the stored information looks like, whether it will be an office with friendly employees answering questions and distributing printed booklets or an IT system, which can be accessed using the Internet. All this is undefined on this level of abstraction.
Nevertheless, the model shows a very concrete structure of the example system. The system structure has been made visual, which highly improves the efficiency of communication. There is some meaningful structure you can point to, while talking about it and discussing alternatives. This would be inherently impossible if the real system did not exist yet or if the system just looked like a set of technical low-level devices, that could serve any purpose.
By refining the high-level structure of the system while considering additional requirements, a hierarchy of models showing the system on lower levels of abstracting is being created. Again, the system description can be partitioned according to the three fundamental aspects, that define each dynamic system -- compositional structure, behavior and value structures. Making the relationship between the different models visible using visual containment and descriptive text, comprehension of the systems is maintained over all levels of abstraction. Using this approach, it is possible to prevent the fatal multiplication of fuzziness, while communicating about complex structures without anything to hold on.
Figure C.4 shows a possible implementation of the information help desk and the storage holding the travel information. The storage turns out to be implemented as a collection of database servers, mail and web servers used by the different travel organizations to publish their documents containing the travel information. The information help desk contains a set of adapters used to acquire the information from the different data sources. The core component of the help desk is the document builder. It provides the documents assembled from the collected information and from a set of predefined templates to a web server. Persons being interested in the services from the travel agency may read the documents from this web server using a web browser. It is not obvious that the reservation system now has to request travel information from the information help desk instead of getting it itself. This is an example for non-strict refinement.
We could continue to describe the dynamics and value structures on that level, afterward refining or introducing new aspects one more time and so on. We won't do this here. When to stop this iteration cycle depends on the purpose of your activities: Maybe you are you going to create a high-level understanding of the systems' purpose, maybe you are discussing design alternatives of the systems architecture or estimating costs, whatever.
Knowing the system's structure presented in figure C.1, it is quite easy to understand the more complex lower-level structure presented now. To ease comprehension, components from a higher-level system view should be projected into the lower-level system view whenever possible. In case implementation is done by simple refinement the result will be a containment hierarchy between the nodes representing components of different levels of abstraction. Without doubt, it would have been much harder to understand the example system if it would have been introduced on the level of adapters, mail servers and browsers. It would have been nearly impossible to create a common understanding without any figures at all.
 |
Apache Modeling Portal 2004-10-29 |
