Layered Models drs.ing. A.V. Avontuur Biggenweide 6 2727 GS Zoetermeer email@example.com dr. J.L.M. Vrancken B. Nooijstraat 24 2642 BS Pijnacker 06-26380336 firstname.lastname@example.org Abstract This paper contains a short description of so-called layered models that occur often in architecture documents. The reason for the importance of this kind of models is that several well-know modeling concepts can be expressed in a single layered model. Introduction The best known examples of layered models are probably the ISO-OSI (Open Systems Interconnection, ref. ) reference model for data communication with 7 layers (shown below), and the ANSI-SPARC model for database-design with 3 layers (ref. ). These two examples show that layered models historically precede the advent of software architecture as a separate discipline. Experiences at Rijkswaterstaat in various architecture projects (ref. , , , ) have shown that layered models are a versatile tool, ideally suited to express important parts of an architecture. They are applicable to virtually any part of an architecture, be it business modeling, organizational issues or technical infrastructure. Experiences elsewhere corroborate this (ref. [1,2 and 6-19, 21]). The essence of a layered model is that it describes the way a large subject (like data communications or database systems) is organized. Each layer describes a certain type of objects, used in the implementation of the objects in the layer above: Layer Object described Application layer Applications that can exchange meaningful information Presentation layer Objects that can find each other, exchange data and can understand the meaning of each other’s data Session layer Objects that can set up a session for communication. Transport layer Objects that can exchange bits end to end. Network layer Objects that can exchange bits via a number of links. Link layer Pairs of objects that can exchange bits reliably. Physical layer Physical means to convey bits Table 1: ISO-OSI model for Open Systems Interconnection The example in table 1 shows how a large subject can be subdivided into a number of types of objects. Other simple examples of layered models are: Written Chemicals Computer processes language Texts Mixed Communicating chemicals processes Sentences Molecules Processes with concurrency Words Atoms Sequential processes Letters Elementary Atomic steps particles Table 2: Examples of simple layered models Each layer should describe an important type of objects that correspond with an important subarea of the subject being modeled. The objects in a layer are implemented by means of the objects in the layer below (objects in layer n use services from, or are composed of, objects in layer n-1). Moreover each layer introduces at least one additional important concept. For instance in the model of written language in table 2, each word is an ordered set of letters, but the additional concept involved is "meaning". Words have meaning, something that lacks completely in the Letters-layer. The Sentences-layer introduces the meaning of a well-formed group of words. Texts describe extensive subjects. Texts involve text structuring and text layout, both of which do not apply to sentences. Why layered models? The importance of layered models stems from their ability to express the following modeling concepts: Semantical levels Recursive structuring General/specific hierarchy Why-what-how ordering Task organization Well-designed layered models express several or all of these concepts at the same time. In addition to this high expressiveness, layered models have a number of properties that increase their constructibility and understandability. Semantical levels A semantical level denotes the set of typical notions used in a business area or scientific discipline. Semantical levels often correspond with professional groups: doctors, stock brokers, pilots: each profession has its own typical notions. Designing systems involves the translation of the semantical level of a business area into the semantical level of the computer domain. Most often there is a large distance between these levels. Translation cannot be done in a single step but requires several intermediate steps. The layers of a layered model correspond to these semantical steps, by defining or discerning intermediate semantical levels. The highest layer usually consists of business terms. The lowest layer corresponds with the computer domain or any other low level implementation environment. Recursive structuring Structuring is the very common modeling technique of dividing an object into a number of parts and indicating relationships between these parts. Virtually any model involves some kind of structuring. Structuring can be done recursively: parts can be further subdivided into smaller parts: a text consists of sentences, sentences consist of words, words consist of letters. In this way quite naturally a layered model arises. It is recommendable that the parts at the same level of structuring be of the same type or the same weight. This can be achieved by focusing explicitly on the layered model involved and characterizing the types of the objects within each layer. In this way, a layered model may be considered as a hierarchical types model. A well chosen layered model greatly improves comprehensibility of a recursive structure. General/specific hierarchy A good example of a general/specific hierarchy can be found in a class hierarchy for objects (beware: in a class hierarchy the most general is found near the top, the most specific near the bottom of the page or screen; in a layered model this is reversed). Inheritance denotes the relationship between more specific classes of objects and more general classes. More general objects have the advantage to be useful in a larger number of cases and will remain useful for a longer period, but the disadvantage that any use involves more work than the use of a more specific object. The natural way to strike a balance between these opposing properties is to construct more specific objects by means of more general ones. This can be done recursively: again a layered model arises. The importance of general/specific hierarchies can be illustrated by a comparison of structured design methods, like SA/SD (ref. ), and object-oriented methods. In SA/SD functional decomposition plays an important role. But SA/SD fails to put functions and subfunctions in a general/specific hierarchy. Lower level functions are often more general than higher level functions and should be treated as such. Object-orientation does a lot better in this respect by putting objects in an inheritance hierarchy. In the short term it is of course cheaper to implement each function only for the purpose at hand. But then any change in requirements will propagate deeply into the system, a well-known drawback of systems designed using SA/SD. The higher cost of a more general implementation will be returned in the maintenance phase of a system. In addition it can be compensated by serving a larger user group. Why-what-how models Yet another well-known way that leads to layered models consists of the interrogative pronouns “why”, “what” and “how” (ref. ): what are you doing, why are you doing it, how are you doing it? The what-question only serves the purpose of focusing on a subject. The really meaningful pronouns are “why” and “how”. The essential point here is that these questions can be applied recursively: any purpose has a purpose behind it. Why do we have letters? To write texts. It is a correct answer but it becomes easier to understand if we add the intermediate steps. Letters serve the purpose of forming words. Words serve the purpose of building sentences and sentences finally build texts. The same holds for the “how”-question. The implementation of texts is done by means of letters, but this becomes a lot easier to understand when the intermediate steps are added. This also shows that “how” is essentially the same question as “why”, only in the other direction. Task organization Layered models have an organizational dimension. Often the different layers in a well designed layered model correspond with different tasks and different organizational units. This is a consequence of the fact that each layer is a semantical level, as was explained above. In the Texts-example letters are the domain of compositors and font-designers. Words are the domain of word morphologists and lexicographers. Sentences are the domain of grammar-specialists. Texts finally are the domain of text writers and editors. A layered model is thus an effective means for solving organizational problems or identifying organizational consequences of new systems. Properties of layered models We mention three properties that are useful in constructing as well as in reading layered models: sublayers, traceability and multi-layer services. Sublayers Often the layers of a model can be further detailed into sublayers or, the other way round, adjacent layers may be combined into a single layer. Experience shows that 3 to 9 layers in a single model is optimal for readability. This can be achieved by either expanding or combining layers. Traceability Traceability denotes the property of a layered model that for any object at any given layer, it is clear which objects it serves in the layer above and which objects it uses in the layer below. This is very helpful in the construction of a model as traceability assures the internal completeness of a model. Multi-layer services In some models, a layer uses services not only from the adjacent layer below, but from several layers below. This occurs often in typical IT-infrastructure models (ref. , ). This is just a variant of layered models. The description above applies equally well to this kind of models. References  A.S. Tanenbaum: Computer Networks, 1988.  C.J. Date: An introduction to Database Systems, Volume 1, Fifth Edition, 1990.  Handboek Automatiseringsinfrastructuur, Meetkundige Dienst, Rijkswaterstaat, 1996.  J. v. d. Hoven, J. v. Putten, J. Vrancken: IT-Architecturen voor Legacy Systemen, juli 1995.  J.L.M. Vrancken e.a.: Architectuur voor Verkeersbeheersing, beknopte versie, mei 1998.  C. Ghezzi, M. Jazayeri, D. Mandrioli: Fundamentals of Software Engineering, 1991.  M. Jackson: Software Requirements & Specifications, 1995.  http://estes.on-line.com/epicug/jargon/sld019.htm  http://www.simonstl.com/articles/layering/layered.htm  http://www.mentorg.com/inventra/confpapers/ip97_ocb/tsld032.htm  http://www-tcad.stanford.edu/tcad/programs/alamode-97.08.19/alamode.html  http://ocelot.cat.syr.edu/3Si/Java/JavaSecurity/sld002.htm  http://www.swlink.net/~hendersn/education/isomodel.htm  http://compsci.ucd.ie/staff/tahar/Courses/4thYear/chapter5/ppframe.htm  Complex structures : a functionalist perspective / edited by Betty Devriendt, Louis Goossens, Johan van der Auwera. Berlin ; New York : Mouton de Gruyter, 1996.  D. B. Frederick: Estimation of hydraulic properties and development of a layered conceptual model for the Snake River Plain aquifer at the Idaho National Engineering Laboratory, Idaho / by David B. Frederick and Gary S. Johnson ; submitted to State of Idaho INEL Oversight Program. Moscow, Idaho : Idaho Water Resources Research Institute, University of Idaho, 1996.  J. Bosch: Design Patterns as Language Constructs. Journal of object-oriented programming. 1 May 1998.  Taniguchi, Shoichi: Revaluation of the 3-Layered Model in Descriptive Cataloging. Toshokan Gakkai, Annals of Japan Society.  D. Jacobs, Het Kennisoffensief, 1999.  J.F. de Ronde, F.T. Withagen: VICNet Architectuurmodel Update 1998, Meetkundige Dienst, Rijkswaterstaat.  P. Bovy, M. Minderhout: Telematica en IT in het verkeer, Informatie en Informatiebeleid, zomer(14) 1996, a. 2.