Sonderforschungsbereich 501 | ||
Teilprojekt B4 Generische Kommunikationssysteme AG Rechnernetze |
Generische Kommunikationsdienste |
Prozessmodell. Ein von 1995 bis 1997 entwickeltes erstes Prozessmodell für die Problemanalyse wurde aufgrund der Erfahrungen mehrerer Fallstudien (s. auch "Engineering von Kommunikationsdiensten") weiterentwickelt und konsolidiert [44] [48]. An dieser Stelle seien vier Aspekte des Prozessmodells besonders hervorgehoben:
Spezifikationstechniken. Von 1995 bis 1997 wurde zur formalen Spezifikation von Anwendungsanforderungen und Kommunikationsdiensten die auf das Anwendungsfeld zugeschnittene Realzeit-Logik tRTTL (tailored Real Time Temporal Logic) eingesetzt. Die beim Einsatz von tRTTL auftretenden Defizite hinsichtlich Strukturierung und Ermittlung von Kommunikationsanforderungen konnten mit der Entwicklung der Formal Requirements Specification Technique (FoReST) [57] [56] [16] (in Kooperation mit Teilprojekt C1), die objektorientierte Konzepte und tRTTL integriert, beseitigt werden.
Referenzmodell für Problemspezifikationen. Aufbauend auf dem in [65] vorgestellten Referenzmodell für Anforderungen und Spezifikationen wurde in Kooperation mit Teilprojekt C1 ein Referenzmodell für Problemspezifikationen definiert [46] [57]. Das Referenzmodell unterscheidet zwischen beobachteten und kontrollierten Größen sowie zwischen Umgebungs- und Systemgrößen und trifft darüberhinaus Festlegungen bezüglich ihrer Sichtbarkeit.
Ermittlung der Kommunikationsanforderungen. Zur Ermittlung der Kommunikationsanforderungen wird die Problemspezifikation - unterstützt durch den Einsatz von Service Patterns - verfeinert. Über die Definition der Service Patterns, insbesondere das Analysemodell als Bestandteil dieser Definition, kann ein unmittelbarer Zusammenhang zu Requirement Patterns hergestellt werden. Damit ist aus dem Einsatz eines Requirement Patterns in der Problemspezifikation ein direkter Schluss auf die zur Verfeinerung anwendbaren Service Patterns möglich. Die Adaption des Service Patterns ist teilweise aus der bereits gegebenen Adaption des Requirement Patterns ermittelbar. Die Verfeinerung kann in mehreren Schritten erfolgen [47]. Die praktische Erprobung dieser Vorgehensweise sowie der Aufbau einer initialen Service-Pattern-Sammlung sind im Gange und sollen noch bis Ende 2000 zu einem abschließenden Ergebnis führen.
Requirement-Pattern-Sammlung. Von 1998 bis 2000 wurden mehrere umfangreiche Fallstudien zur Problemspezifikation durchgeführt (s. auch "Engineering von Kommunikationsdiensten"), bei denen die Requirement-Pattern-Sammlung intensiv eingesetzt wurde. Im Anschluss an diese Fallstudien fand jeweils eine Überarbeitung der Mustersammlung statt. So hat sich die Sammlung gegenüber der initialen Version stark verändert, auch wenn sich die Anzahl der Muster kaum erhöht hat. Verschiedene Stadien von Requirement Patterns sind in [44], [48] und [15] dokumentiert. In [44] wird die Gewinnung von Requirement Patterns im allgemeinen und des LazyReaction-Patterns im besonderen ausführlich dargestellt.
Service-Pattern-Sammlung. Die Entwicklung der Service-Pattern-Sammlung ist wie bereits erörtert eng an die Requirement Patterns gekoppelt. Aufgrund dieser starken Abhängigkeiten und bedingt durch die neuen Resultate im Anforderungsbereich ist der Aufbau der Service-Pattern-Sammlung noch im Gange, so dass hier erst gegen Ende 2000 aussagekräftige Ergebnisse vorliegen werden.
Werkzeugunterstützung. Die aktuelle Requirement-Pattern-Sammlung ist im organisatorischen Teil der Erfahrungsdatenbank SFB-EDB (s. Teilprojekt A1) abgelegt und kann bei der Durchführung von Projekten herangezogen werden. Ferner wurde das in Teilprojekt C1 entwickelte rechnergestützte Werkzeug xforest [64] zur Verwaltung der Requirement Patterns eingesetzt.
Die in den Arbeitspaketen A1 und A2 entwickelten Methoden, Techniken, Werkzeuge und Mustersammlungen wurden in mehreren umfangreichen Fallstudien [57] [45] [18] (s. Querschnittprojekt Q4) sowie einer Variante der Problemspezifikation "Lichtsteuerung", die als Ausgangspunkt für die durchgängige Entwicklung einer verteilten Gebäudesteuerung dient, eingesetzt und erprobt. Die darin gesammelten Erfahrungen sind jeweils unmittelbar in die Weiterentwicklung und Konsolidierung dieser Ansätze eingeflossen.
B4 | Forschungsaktivitäten | Ergebnisse 98-99-00 | Dienste |
peper@informatik.uni-kl.de | 02.08.00 |