1st International Working Conference of Software Architecture

Uwe Aßmann

22.-24.2.99, San Antonio, Texas

This travel report is in an ugly form (Denglish); however, I do not have the time to translate everything.

1. General remarks to the conference

Bad: No discussion about aspect orientation, seems to be unknown. However, architecture is just one aspect of several.

Almost no pattern people attended, this seems to be a totally separated community, although patterns describe microarchitectures. Also almost no framework people, except Pree and Koskimies. No OO people.

The discussion groups and the open sessions lead to too many diverse discussions. The field is not ripe in so far it has not specialized enough yet; there are no major subfields into which a division would be natural.

The structure of the conference was not systematic. I had the impression that somehow the sessions were arbitrarily grouped together, but maybe this is due to the unripe field.

Good: Lots of questions from companies, problems, views from people with different background. Some good papers. The following people should be interested in the following papers.

Oliver, Benedikt: Rick Kazman, An architectural recovering method.

Thomas Genssler, Benedikt, Andreas Ludwig: Jan-Peter Riegel, Kaiserslautern, Code gernation from design patterns. Don Batory: Styles as adaptors. (uses metaprogramming)

Fazit: Wegen dem sehr unterschiedlichen Hintergrund der Teilnehmer war die Konferenz sehr gut zur Horizonterweiterung. Es war interessant zu sehen, dass viele, insbesondere Leute aus der Industrie, unter Softwarearchitektur keineswegs nur die Definition von ARchitektursprachen verstehen, sondern behaupten, dass das in den Softwareentwicklungsprozess eingebunden werden muss: Entscheidungshilfen, Bewertung von Architekturen, Simulation, Analyse, Qualitätsmanagement und vieles andere muss mit der Architekturbeschreibung zusammengehen, damit diese sinnvoll sein soll.

Zwar ist Architektur gleich automatisiertem Entwurf, aber sie muss in einen Softwareentwicklungsprozess eingebunden sein.

Zukunft: Es wird eine IFIP WG 2.10 "Software-Architektur" geben. Gründungskomitee Clements, Perry, Ran, Shaw, Kruchten, Kramer und 3 andere Leute. Die Berufung war pseudodemokratisch: Jeder durfte jeden vorschlagen, also schlugen die Cracks die Cracks vor.

Das Komitee wird eine 2. Konferenz vorbereiten, sowie sich Gedanken über die initialen Mitglieder machen. Da ca. 100 Leute auf der Konferenz anwesend waren, ist die Chance momentan gering, hineinzukommen.

2. Montag, 22.2.

2.1 Modelling Session Montag früh

Stuurman Delft

Software Architecture and Java Beans. Einige Anforderungen, die sich ergeben, wenn man eine ADL auf Beans aufbauen will. Naja, eine einigermassen systematische Zusammenstellung.

Hirsch

Modelling Software Architecture with graph grammars and constraints. Idee: Kontextfreie Graphgrammatiken auch für dynamische Änderungen der Architektur einsetzen. Aufteilung der Regeln in 3 Klassen: statisch, dynamisch, und ?? Wie kann man bestimmen, welcher Stil, welche Architektur in den Spezifikationen vorliegt? LeMetayer scheint mir klarer zu sein. Die Beispiele waren schwierig zu verstehen, da mit roten Labels Gleichheitsconstraints ausdrücken. Wo sind die Grenzen des Ansatzes? Was kann man nicht mehr modellieren?

2.2 Analysis and Assessment of Software Architecture, Montag früh

Magee

Analysing behavior of architecture. FSP: Eine Prozessalgebra, um Zustandsmaschinen zu generieren. Auf ihnen wird analysiert. Ein Alphabet von Interaktionen; jede Komponente erhält eine Zustandsmaschine zugeordnet. Sie haben ein Tool, das die Zustandsautomaten animieren kann. Man kann Erreichbarkeitsanalyse einsetzen, um die Erreichbarkeit von Deadlocks oder Fehlerzuständen zu testen. Einsatz von Milners observational equivalence. Man kann Sicherheitsbedingungen spezifizieren und checken. LTL model checking ist einsetzbar. Eingeschränkte LTL ist in einer Programmiersprachen-Syntax erhältlich. Wright, Promela benutzen auch model checker. Labelled Transition system Analyser (LTSA) www-dse.doc.ic.ac.uk/concurrency. Workflows sind Architekturen von Problemen, nicht von Systemen.

Pree Koskimies

Rearchitecturing Legacy Systems. Identify replicated code fragments which vary a bit, such that they cannot be put into a module or procedure. Idee: Packe es stattdessen in kleine Frameworks, framelets. Diese haben keinen selbständigen Kontrollfluß, haben weniger als 10 Klassen mit einem einfachen Interface. Pree benutzt Reflektion, um die Kopplung zu kontrollieren. Guter Vortrag.

Guo Allen/Kazman

Reconstruction of software architecture with the ARM method. Interessante Methodik, um Muster in Code zu erkennen, analog Prechelt, aber noch ausgefeilter. Abspeicherung der extrahierten Daten in einem primitiven Faktenformat, Rigi Standard Format. Abspeichern in Datenbank.

Böhm

the MBASE model. Was wollte Barry Boehm mit diesem Vortrag sagen? Wohl, wie er Architekturen in sein win-win-Spiralmodell einbauen will. Nein, was verschiedene Nutzer von einer Architektursprache wollen. Naja.

Diskussion

mit verschiedenen völlig verquer vorgetragenen Fragen bzw. Statements. Wesentlicher Beitrag: wann endlich kommen wir zu einer stärker formalisieren Basis für Softwarearchitektur und verlassen das informelle Gelaber?

2.3 Montag nachmittag

Canal

Eine Architektursprache auf der Basis des Pi-Kalküls. Komponenten und Konnektoren sind Pi-Kalkül-Programme. Nützlich für die Lehre? Über Ausführung wurde nicht gesprochen...

Medvidovic

Modellierung von ADLs mit UML. 2 Methoden der Abbildung: a) Abbildung auf normale UML-Klassen b) auf Stereotypes. Letzteres ist eine Erweiterungsmöglichkeit von UML, mit dem sozusagen neue UML-Elemente definiert werden können. Ihnen können z.B. Ikone oder spezielle graphische Elemente zugeordnet werden. Nach Medvidovics Meinung ist eine Repräsentation in UML zwar möglich, aber er zweifelt, ob es adäquat ist. Dafür hat es den Vorteil, dass sofort viele Leute es verstehen. Medvidovic schein ein sehr aktiver junger Professor zu sein (UC Irvine).

Hofmeister Siemens

Abbildung des 4+1-Viewmodells von Philippe Kruchten auf UML. Das teilt Architektur in 4 Sichten ein: Conceptual, Module, Execution, Implementation. Auf jeder Ebene werden die Elemente auf UML Stereotypen abgebildet: Konnektoren, Module, Prozess, Protokolle, jeweils mit passenden UML Elementen. Hofmeister ist positiv eingestellt: viele ihrer industriellen Entwickler verstehen es sofort. Allerdings gibt auch sie zu, dass die Abbildung aller architektonischen Elemente insgesamt zu unübersichtlichen UML-Diagrammen führt, daher haben sie manches auf textuelle Annotationen abgebildet.

3. Dienstag, 23.2.

3.1 Technical papers

Batory Austin

Styles as Adaptors. Die Kommunikation, d.h. die Konnektoren, werden als GenVoca-Adapter bzw. Schichten ausgedrückt. Das bedeutet, dass man die Kommunikationsart als Parameter an generische Klassen angeben kann. Resultat: Ausfaktorisierung der Kommunikation in generische Parameter. Implementierung mit verschiedenen Mitteln: Metaprogramme, templates, programmtransformationssysteme. Architekturstile beruhen auf Verfeinerung: Anwendungen eines Stils sind Verfeinerungen des Stils. Algebraische Ersetzungsregeln optimieren. Batory baut also Systeme, mit denen die Paramter der generischen Klassen die Kommunikation bestimmen. Paramter als Löcher, in die etwas eingehängt werden kann. Implementierung mithilfe von Metaprogramming.

Klein

ABAS: Attribute-based architectural styles. Klassifizierung der Probleme und auch der Stile mithilfe von Attributen. Ablage in Datenbank. Suche nach passenden Stilen. Interessant für Reengineering!

Riegel Kaiserslautern

Pattern Generators. Codegenerierung aus Mustern für Gebäudesimulatoren. Muster-Bindungseditor, der Patterns auf Klassengraphen bindet. Katalog aller Gamma-Pattern. Generierung der Datenstrukturen und der Funktionalität. Datenfluß-Stil wird durch Pipe-und-Filter-Muster unterstützt. Push/Pull-aktive Pipelines. Tja, da wollten wir hin; sie sind schon da, allerdings nur für Smalltalk, wie üblich. Wie unterscheidet sich das von Ansätzen von Florijn (Riegel kannte ihn nicht!)? Kann man das ausdehnen auf alle Anwendungen? Wie baut man es in Standardsysteme ein?

3.2 Experience papers

Butler

Security in the Global Command and Control System. Bezieht man Sicherheit ein, hat das starke Auswirkungen auf die Architektur. Das wird bei ADLs immer vernachlässigt.

Gruhn Dortmund

Integration of Heterogeneous Software Architectures. Projekt mit Telekom-Firma. "software landscape". Problem: Inkompatibilitäten unter Kundendaten. Plädiert für UML als Syntax von Architektursprachen. Bessere Akzeptanz.

Shaw

Challenges in Software Architecture Research.

3.3 Session Domain-specific architectures resp. product lines

Product lines are domain-specific by definition.

Bass

A Domain Engineering Method. Dashboard für Autofirmen. Unverstanden.

Lassing Amsterdam

Evaluation of the ComBAD Architecture. Man benutzt SAAM (software architecture analysis method), um die Qualität einer existierenden Architektur zu beurteilen. SAAM vom SEI scheint eine beliebte Methode zu sein, um die Qualität von Architekturen von Systemen zu beurteilen. Was bringt das für Reengineering?

Bosch

Bosch stellte seine Industrieprojekte vor.

4. Mittwoch, 24.2.

4.1 Panel

Langweilig. Jeder Panelist stellte vor, was er arbeitet, aber es kam zu keiner konstruktiven Diskussion.

4.2 Working group reports from afternoons before

Models and Description languages (Rosenblum)

Question: What is an architectural style? Answer: Style is a set of component and connector types plus constraints on connection. Or: Packaging of engineering experience, description of problems and domains, description of pitfalls. A subspace of software architecture.

Styles are like drugs: you have an ailment (design problem), you apply the drug (the style), you know the benefits (indication), recommended dosage (application and reasoning), limitations (contraindications), cookbook of styles, side effects. Real systems - like real disease treatments - are composed of many styles (several drugs). Dangerous interactions. Contraindiations. "Maybe we should be doctors".

Styles may be general (pipe-filter, client-server...) or domain-specific (product line styles, C2 for dynamically recofigurable systems).

Patterns vs Styles: .. differ in their applicability (abstraction, granularity). Patterns try to grasp well-known things.

Interoperability, evolution, integration (Shaw)

Schöne Diskussion mit vielen aufgeworfenen Forschungsfragen, aber keine Antworten.

Full list available at www.bell-labs.com/user/dep/prof/wicsa1

Domain-specific Architectures and Product families (Hofmeister, Obbink)

What's the difference between the design of a single system and the architecture of a product line?

The difference between a product line/family and a domain-specific architecture?

What is a design method for product lines?

Differences from single system design? Economic analysis of the product line is important. Use of ingredients from open systems

Planning for the unexpected: Delta technology. Roadmapping.

Product lines are for experienced fields: where you know what you do.

Analysis and Assessment of architectures (Kazman)

The following was a wish list of the participants.

Techniques and methods (Paulisch)

We need

5. Other contacts and observations

  1. Dieter XX AIFB: Prof. Studer vom AIFB Karlsruhe bietet eine Inferenzengine für feature logic an, in Java implementiert. Empfehlenswert für COMPOST-Leute und FAMOOS. Das AIFB plant eine Firma für ECommerce, sowie ein Esprit-Projekt in diese Richtung.
  2. Mcc\'{ }Austin: T.W. Cook works on description of architecturs in XML-DTDs. They have a description of ACME, and try to map the DTDs by XSL mapping specifications. (XSL is the future standard for mapping of DTDs on other DTDs).
  3. Paola XX, which brings up new companies. Major tip for those: the architecture of the company's system is not allowed to fail. It must fit the purpose. Hence the architect should be a qualified engineer. In University projects, people are not right trained for architecture and software engineering; in the lectures they teach the right things, but PhD's see different things.
  4. Henk Obbink, Philips Natlab Eindhoven: A research success becomes a real success if it turns into a business success. Philips has certain standardisized architectural related software processes: reengineering architecture, verifying architecture.
  5. www.wwisa.org: international institute on software architects. Institute for profession. Board: Booch, Denning, Winograd,..
  6. Philippe Kruchten, Rational: Rational hat in den letzten Jahren 6-8 Firmen aufgekauft und musste ihre Architekturen vereinigen. Pain. Es hat eine spezielle Architekturgruppe und berät andere Firmen in Softwarearchitektur.
  7. Will Tracz, Lockheed: Lockheed ist eine CMM-level-5 Organisation. Man pflegt 3 Ebenen der ARchitektur zu unterscheiden: Operational, Functional, Physical. Architekturen werden durch Simulation analysiert. Kritische Probleme sind COTS, customer awareness, tools, interoperability.
  8. Shaw: Greenfield systems become brownfield systems even before release.

6. Allgemeines zu TX

San Antonio, TX, scheint eine der netteren amerikanischen Städte zu sein. Man bezeichnet sie auch die heimliche Hauptstadt Texas'. Man erlebt jedoch in der Stadt eine Überraschung: Sie ist zwar für ihren Fluß und den zugehörigen river walk bekannt, aber fährt man durch die Stadt, sieht man ihn einfach nicht. Des Rätsels Lösung: man hat den Fluß einfach tiefer gelegt, so dass alle Brücken ebenerdig darüber gehen und man sozusagen absteigen muss, um an ihm entlang zu gehen. Ist man erst dort angelangt, wird es recht gemütlich, Tex-Mexican, Steaks, etcpp finden sich zuhauf, und alle flanieren am Flüsschen entlang. Natürlich ist alles kommerzialisiert: Leinen mit Glühbirnchen hängen von den Bäumen; Boote fahren vollbepackt mit Touristen; Musiker spielen ein Lied für 10 Dollar; Steaks: Ribeye, T-Bone, Filet Mignon, etcpp.

Texas an sich gehörte den Apache und Comantsche Indianern; ihnen wurde das Land per Vertrag abgekauft oder auch mit Gewalt abgenommen und sie aus dem Land vertrieben. Formal gesehen war Texas ein Teil Mexikos, d.h. Spaniens. 1820 wurde Mexiko selbständig, ca 1847 fiel Texas von den Mexikanern ab, da Mexiko von einem Diktator regiert wurde, der die Verfassung nicht achtete. Die entscheidenden Schlachten fanden in San Antonio und in der Nähe statt. Eine Gruppe von 200 Soldaten verteidigte die Alamo-Missionsstation in San Antonio; bei der Eroberung durch die Mexikaner wurden alle getötet, worauf der Alamo zum texanischen Nationalheiligtum wurde (wörtlich: "the texas shrine"). Kurze Zeit später wurden die Mexikaner vernichtend geschlagen, und Texas wurde selbständig. Allerdings schloß man sich doch 13 Jahre später freiwillig den USA an.

Texas besitzt einen deutschen Gürtel, der um 1845 besiedelt wurde, viele der Bewohner kamen aus Hessen Die Siedler kamen, geführt von einem Prinzen von Solms, ins Land. Entsprechend heisst eine Stadt New Braunfels, viele Namen sind deutsch. Leider schmeckt der Kuchen im Cafe doch amerikanisch, nicht deutsch.