Brontekst bekijken van Taxonomy/supplement/Towards a Taxonomy for Architecture in the Digital World

<big>Hanno Wupper</big> <br>
<big>Informatics for Technical Applications</big> <br>
<big>Radboud University Nijmegen</big> <br>
Hanno.Wupper@cs.ru.nl<br>
http://www.cs.ru.nl/H.Wupper

; Acknowledgements : The author wishes to thank Henk Barendregt, Ed Brinksma, Stijn Hoppenbrouwers, Angelika Mader, Erik Proper, Daan Rijsenbrij and Frits Vaandrager for their implicit or explicit contribution to the taxonomy and critical remarks.
== Introduction ==
After all, the computer science community and industry are convincing each other that adequate methods, languages, notations, tools to extract, represent, share, use and re-use ''architectural knowledge'' are necessary, much like forty years ago the necessity of theoretically sound, well-defined and practically usable programming methods and languages was perceived. 
We should learn from history and not repeat what then went wrong. Methods, languages, and tools only help when they are fully understood by the professionals who use them, while also their managers and the stakeholders involved share a basic understanding of their essence. When the use of new tools based on new languages is enforced by an un-understanding management in the hope they will improve the world ''by themselves'', professionals will just remain doing what they are used to do, much like in te last century programmers kept writing unstructured BASIC-programs in modern languages like Pascal, PL1, Algol, or Ada.

We therefore have to propagate a consistent system of comprehensible, language- and tool-independent concepts and classifications – a ''taxonomy'' – to explain what architectural knowledge ''is''. Such a taxonomy should be so straightforward and obvious that it can be understood not only by architects and IT-specialists, but also by managers, customers and educated users. Only when they all share an understanding about architectural knowledge and why it is necessary to extract, represent and re-use it and how it can be read, new methods and tools can become a success.
== A lesson from the past ==
In the sixties and seventies of the last century, IFIP WG 2.1 spent a lot of energy and creativity on the definition of a consistent system of concepts for not only methodical programming but also for programming languages to support it and the unambiguous definition and correct implementation of such languages. This international effort culminated in the Revised Report on Algol 68, a thick document defining a powerful language. Both the report and the language were a treasure of new useful, consistent concepts, but the target group completely failed to see these concepts through a document considered unreadable and a language considered unimplementable. The whole effort had little impact, and soon many other languages and compilers emerged that contained flaws that should never have occurred. Sure, at present the language Algol 68 is out-dated as a programming language - but it is a pity that the conceptual understanding obtained during its development had very little impact. Nowadays, language and compiler developers are still re-inventing old Algol 68 concepts one by one.

What made it worse was that, at that time, there was very little knowledge transfer between "programming", "databases" and  "machine architecture". In all these areas languages have been defined, one more awful than the other, all described in their own terminology. 

At present, various disciplines are somehow or other concerned in architectural knowledge: software architecture, software engineering, systems engineering, rerqirements engineering, embedded systems, verification and validation, modelling, information systems. We therefore plead for a joint effort of all these discplines: while different research groups focus on the development of different, hopefully complementary or at least compatible methods, languages, and tools they should at the same time try to agree on a taxonomy that can be used to explain all these and their underling relations. Such a taxonomy should be so straightforward that the intended users, their managers and customers can understand it. This means that it should avoid those historically grown terms and concepts that are only understood by some schools of researchers, while it should also avoid fashionable buzz-words.
== A note on terminology ==
A taxonomy is a system of classification. To classify means to divide and conquer by putting everything into classes. To define a simple, meaningful and orthogonal system of classes is difficult enough. To label the resulting classes with non-confusing, generally acceptable terms is inpossible in computer science, where different schools use terms like "model", "location", "specification", "function", "type" for entirely different concepts. The reader is kindly asked to understand that this paper is not about terminology. It is about the necessity of a consistent system of ''concepts'' and ''questions''. Only after these have been established we should quarrel about how to name them. Alas, it is unavoidable to use terms in a paper like this. Please mentally replace them by your favourite terms for the intended concepts.
== A sketch of a taxonomy ==
We start from the ''[[Taxonomy/0. Taxonomy of Computer Science|Taxonomy of Computer Science]]'' as described in (1), (2), (3), (4), (5). It has succesfully been used in teaching for several years; it has helped to bring together researchers from different areas; it has proved valuable when one has to explain to people alien to IT what IT and computer science is about. This taxonomy differs from, e.g., the ACM index and various thesauri in the way it was achieved: We did not start from the historically grown partition of the discipline (programming, databases, machines, requirements engineering, etc.). For philosophical reasons we took nothing for granted. Our method was to begin with a basic, abstract and general observation, which was subsequently refined and detailed as described in (1). In this short paper we can only give a sketch of the basic concepts obtained this way and elaborate on their usefulness in handling architectural knowledge.[[Image:Vierkant_compleet_oud.gif|thumb|500px|The Rationality Square]]
=== Basic concepts ===
We need simple, discipline independent basic concepts that provide a classification system for architectural knowledge. They should not be restricted to software but suitable for the description of all artefacts that contain some IT.
==== Rationality Square ====
It is helpful to distinguish rigorously between the ''physcal world'', where the considered artefact and its environment exhibit behaviour and other observable properties, and (formal or informal) ''descriptions'' of such physical objects and phenomena. Software engineers tend to neglect this distinction: in pure software systems a physical program, stored in the working memory of a physical computer, can be identified with its formal description (the code). This can, however, be confusing. In general, a description ''abstracts'' from most properties of the artefact under consideration and states only properties considered relevant. It should be good practise to explicitly state the reasons for the chosen ''abstraction''.

It should also be good practice to distinguish rigorously between the ''purpose'' (the desired ''properties'') of an artefact under a certain view and its ''structure'', viz. the decomposition in components that ensure these properties.

These two distinctions lead to the ''[[Taxonomy/1._Quality/01._Rationality|Rationality Square]]'' defining the necessary ''relations'' between its ''cornerstones'' and the corresponding ''professional activities''. Our experience is that the Rationality Square can easily be explained even to stakeholders who are no IT-experts. It naturally gives rise to a first classification of architectural concerns:
* specification,
* design,
* verification,
* validation,
* the development process,
* the languages involved,
* the manner of documentation.
==== Chinese Box Principle ====
An artefact can be studied from different ''views'' like functionality, security, energy consumption, maintenance. Decomposition depends on the view. The dean of a faculty, the cleaner, the electrician, the network administrator and the student mentally decompose the same faculty building in very different ways. The concept "component of an artefact" is only meaningful under a well-defined, explicitly stated view.

''Structure'' is not an inherent property of an artefact but something we mentally impose on it when we reason about it under a certain view. The [[Taxonomy/supplement/Chinese_Box_Principle|Chinese Box Principle]] says that we should reason about the correctness of an artefact  considering it as a ''glass box'' containing components which we treat as ''black boxes''.  At each ''level of decomposition'' we only use knowledge about the ''purpose'' of these black boxes, not about their internal structure, when we establish that the black boxes together ensure the desired properties of the white box. At a lower level of decomposition, each black box can be "opened", i.e. treated as a glass box independently of its neighbours. This reduces the complexity of reasoning considerably and allows re-use of components.

For each view, the corresponding Chinese Boxes struture (i.e. hiearchical decomposition) can be mirrored by a data structure orthogonal to the previous classification. This data structure allows architectural knowledge to be stored where it belongs, maintained and retrieved.
==== Correctness theorem ====
Ideally, with each glass box a ''[[Taxonomy/1._Quality/04._Correctness_Theorems|Correctness Theorem]]'' is associated that confirms that the properties of its constituent black boxes together ensure its desired properties. 

Properties should be stated as ''assumption''-''commitment''-pairs: an artefact and any of its components is required to exhibit certain properties only as long as its environment ensures that certain assumptions hold. Therefore the correctness theorem, stated in plain logic, has the form:
       (a1=>c1)/\(a2=>c2)/\... => (A=>C)
Even if a correctness theorem is not written down at all, or stated informally or in some language different from logic, one should be aware that the above form is its essence. As described in (2) and (3), this form also allows to explain how we can distinguish between:
* an ''artefact'' (ensuring ci or C) and its ''environment'' (ensuring ai or A),
* ''verification'' (establishing that (a1=>c1)/\(a2=>c2)/\... indeed imply (A=>C)) and ''validation'' (establishing that component i indeed ensures (ai=>ci)),
* the different ''stakeholders'' involved (''developer'', ''customer'', ''supplier'', ''domain expert''),
* different kinds of ''design decisions'',
* different choices for ''fault tolerance''.

Design decisions, a special case of architectural knowledge, can be explained, justified, and classified along the structure of the Correctness Theorem: design means chosing a decomposition into parts and then strengthening or weakening the corresponding ai and ci as well as A and C until a provable theorem is reached - even if that theorem is never written down but only lives in the back of the designer's mind.

Altogether, these basic concepts lead to a classification that helps to extract, represent, store, maintain, and retrieve architectural knowlegde. This classification is independent of specific methods, languages, and tools and allows to combine several such and to understand their relations.
=== Quality criteria ===
Our ongoing research is concerned in defining ''quality criteria'' along this taxonomy. In this short paper we can only briefly state some examples. Obviously, some of these quality criteria are unrealistic and in conflict with each other. But it is pleasant to have ideals.
==== Quality criteria for specifications of the artefact (at the right side of the [[Taxonomy/1._Quality/04._Correctness_Theorems|Correctness Theorem]]) ====
* Sufficiently general not to exclude possible solutions. Will have to be weakened if customer was too specific.
* As long as a specification is not formalised: Not so vague that different readers might understand it differently. Will have to be clarified if it contains vague terms.
* When a design has been chosen: provable from the design. Will have to bee weakened until an affordable design is found.
* Suitable as a contract between [[Taxonomy/supplement/developer|developer]] and [[Taxonomy/supplement/customer|customer]].
* Readable in the culture of the customer or at least of his [[Taxonomy/supplement/Domain_expert|Domain expert]].
==== Quality criteria for specifications of components (at the left side) ====
* Suitable as a contract between [[Taxonomy/supplement/developer|developer]] and [[Taxonomy/supplement/supplier|supplier]].
* Realisable, if possible automatically.
* Contains enough information for the proof of the [[Taxonomy/1._Quality/04._Correctness_Theorems|Correctness Theorem]].
* Does not contain unnecessary details.
* Readable in the culture of the [[Taxonomy/supplement/supplier|supplier]] or at least of his [[Taxonomy/supplement/Domain_expert|Domain expert]].
==== Quality criteria for the [[Taxonomy/1._Quality/04._Correctness_Theorems|Correctness Theorem]] ====
* Covers all aspects considered relevant.
* Abstracts from aspects not considered relevant.
* Generic, if possible, i.e. covering a class of parameterised solutions.
* Provable, if possible automatically.
* Adaptable.
* Human-readable.
==== Quality criteria for the languages involved ====
* Human-readable, at least for [[Taxonomy/supplement/Domain_expert|Domain expert]] and [[Taxonomy/supplement/developer|developer]].
* Unambiguous.
* Compact.
* Extensible.
* Decidable.
* Automatically translatable to whatever you like.
* Suitable for simulation and formal verification.
* Supported by graphic tools.
==== Quality criteria for development methods and tools ====
* Should only lead to a [[Taxonomy/1._Quality/04._Correctness_Theorems|Correctness Theorem]] meeting above quality criteria.
* Should not exclude useful design.
* Should ''quickly'' lead to a [[Taxonomy/1._Quality/04._Correctness_Theorems|Correctness Theorem]]
== A joint venture ==
Our [[Taxonomy/0. Taxonomy of Computer Science|Taxonomy of Computer Science]] has brought together researchers with different backgrounds and motivations (linguistics, requirements engineering, formal methods, embedded systems, architecture, information science) from research groups that so far had seen not much reason to work together. The taxonomy helped to understand that their research questions had more in common than one would expect from reading the respective project proposals. This resulted in the plan to compile consistent classifications of 
* decisions and
* quality criteria.
These can be used fo two goals:
# scrutinise, compare, and relate our own and others' methods, languages, and tools,
# teach IT-professionals, managers and stakeholders what the benefit of keeping track of architectural knowledge is.
We would appreciate if researchers from more different groups and users from industry would take part in this project.

== References ==
# Hanno Wupper and Hans Meijer ''Towards a Taxonomy for Computer Science''. In: Informatics as a discipline and in other disciplines: what is in common? Informatics in Higher Education - IFIP WG 3.2 Working Conference, Enschede, Aug. 1997. (Mulder and Van Weert, ed ) London 1998 (also available as technical report CSI-R9713)
# Hanno Wupper ''Design as the Discovery of a Mathematical Theorem - What Designers Should Know about the Art of Mathematics''. Proc. Third Biennial World Conf. on Integrated Design and Process Technology (IDPT) (Ertas et al., ed.) Soc. Des. & Proc. Sc., Austin 1998 (Rudolf Christian Carl Diesel Best paper Award; also available as technical report CSI-R9729)
# Hanno Wupper and Angelika Mader ''System Design as a Creative Mathematical Activity''. technical report CSI-R9919; compressed Postscript
# Hanno Wupper en Hans Meijer ''Wat is informatica eigenlijk?'' TINFON - tijdschrift voor informatica-onderwijs, 9e jaargang nr. 1 en 2 (2000) (also available as technical report CSI-R0008)
# Angelika Mader, Ed Brinksma, Hanno Wupper, Nanette Bauer: ''Design of a PLC Control Program for a Batch Plant, VHS Case Study 1'', European Journal of Control, 2001 vol. 7, issue 4, p.416-439. (also available as technical Report CSI-R0113, March 2001)