Der Requirement-Pattern-Ansatz - Forschungsergebnisse
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Forschungsergebnisse:
Der Requirement-Pattern-Ansatz
Computer Networks Group
Dipl.-Inform. C. Peper
Prof. Dr. R. Gotzhein
Fachbereich Informatik
Universität Kaiserslautern
URL: http://rn.informatik.uni-kl.de/
Email: gotzhein@informatik.uni-kl.de
1 Kurzfassung
Je früher Wiederverwendung stattfindet, desto größer die Auswirkungen auf ein Projekt.
Akzeptiert man diese These, dann sollte Wiederverwendung bereits in der Anforderungsphase
beginnen. In Analogie zu den Entwurfsmustern wurde in der Computer Networks Group der
Requirement-Pattern-Ansatz entwickelt, der die Musteridee mit einer objekt- und eigenschafts-
orientierten Beschreibungstechnik verbindet. Teil des Ansatzes ist ein iterativer Analysepro-
zess, der u.a. regelmäßige Kundenreviews auf der Grundlage präziser, aus der Spezifikation
abgeleiteter natürlichsprachlicher Beschreibungen vorsieht. Ferner wurde eine Mustersamm-
lung entwickelt und in mehreren umfangreichen Fallstudien, darunter auch dem auf der
CeBIT’2001 gezeigten Gebäudemodell, eingesetzt.
2 Methoden und Techniken
Kernergebnisse sind die Entwicklung, Erprobung und Konsolidierung eines Prozessmodells
für die Ermittlung und Präzisierung von Anwendungsanforderungen, die Auswahl und Integra-
tion von Spezifikationstechniken und die Definition eines Referenzmodells für Anforderungs-
dokumente.
Prozessmodell. Das Prozessmodell für die Anforderungsanalyse wurde aufgrund der Erfah-
rungen mehrerer Fallstudien (s.u.) entwickelt und konsolidiert [3] [7]. An dieser Stelle seien
vier Aspekte des Prozessmodells besonders hervorgehoben:
• Die Anforderungsanalysephase verläuft iterativ, wobei jede Iteration neben der Forma-
lisierung ein Review mit Kundenbeteiligung vorsieht (s. Abb. 1). Das Eingabedoku-
ment für das Kunden-Review wird aus der Anforderungsspezifikation durch eine
Projektion, bei der formale Anteile ausgeblendet werden, gewonnen. Um die Abwei-
chung zwischen formaler und natürlichsprachlicher Version so klein wie möglich zu
halten, wird letztere bei der Formalisierung durch einen quasi-Übersetzungsvorgang
aus der formalen Version erzeugt
• Ergebnis der Analysephase ist eine formale Anforderungsspezifikation, die direkt als
Eingabe für die Entwurfsphase dient (s. Abb. 1). Diese formale Spezifikation liegt beipositivem Abschluss des Kunden-Reviews bereits fertig vor, muss also nicht mehr ent-
wickelt werden, so dass potenzielle Fehlerquellen weitgehend vermieden werden..
Anforderungs-
beschreibung
n≥0
Anforderungs-
analyse modifizierte
n>0
NLRSn Modifi-
kationen
Formalisierung Kunden-
(n:=0) Review keine Modifi-
kationen
Legende: NLRSn
Prozess (n:=n+1)
Produkt Anforderungs- NL-
spezifikationn Projektion
Produktfluss
Prozess- und
Anforderungs-
Produktfluss spezifikation
Abbildung 1: Anforderungsanalyseprozess
• Zur Formalisierung der Anforderungsbeschreibung werden musterbasierte Ansätze ein-
gesetzt (s. Abb. 2). Ausgangspunkt ist eine Sammlung von Requirement Patterns, die
aufgrund von Aussagen der Anforderungsbeschreibung selektiert, adaptiert und
schließlich komponiert werden.
Anforderungs- modifizierte
beschreibung NLRSn
n>0
n≥0
Formalisierung
konventionelle
Formalisierung
Kompo- (n:=n+1)
Requirement Selek- Adap-
Pattern Pool tion tion sition
Anforderungs-
spezifikationn
Abbildung 2:Musterbasierte Formalisierung von Anforderungen
• Das Prozessmodell beinhaltet ferner Schritte zur Gewinnung von Mustern durch Ana-
lyse von Entwicklungsdokumenten abgeschlossener Projekte [3]. Dies entspricht den
Schritten analyze und package des Quality Improvement Paradigms (QIP).
Das Prozessmodell ist unabhängig von der eingesetzten Spezifikationstechnik. Es wurde zur
Durchführung von Fallstudien mit der Spezifikationstechnik FoReST [2] (s.u.) instanziiert.
Computer Networks Group, University of Kaiserslautern -2-Sprachunterstützung. Zur formalen Spezifikation von Anwendungsanforderungen wurde die auf das Anwendungsfeld zugeschnittene Formal Requirements Specification Technique (FoReST) [2] [9], die objektorientierte Konzepte mit der Realzeit-Logik tRTTL (tailored Real Time Temporal Logic) integriert, entwickelt und eingesetzt. Das zuvor beschriebene Pro- zessmodell wurde mit FoReST instanziiert. FoReST-Spezifikationen bestehen aus einer Sammlung von Klassendefinitionen, wobei die aus der objektorientierten Modellierung bekannten Assoziationen wie Aggregation, Komposition und Spezialisierung (Vererbung) direkt unterstützt werden. Abweichend von den bekannten Techniken werden die Objekte einer Klasse jedoch nicht durch Operationen näher charakteri- siert, sondern durch ihre Eigenschaften. Zur Spezifikation dieser Eigenschaften wird die bereits erwähnte Logik tRTTL eingesetzt. In Verbindung mit Spezialisierung und Vererbung hat diese Vorgehensweise den Vorteil, dass die Substitutionseigenschaft erhalten bleibt. Referenzmodell für Anforderungsdokumente. Aufbauend auf einem Referenzmodell für Anforderungen und Spezifikationen wurde ein Referenzmodell für Anforderungsdokumente definiert [5] [2]. Das Referenzmodell unterscheidet zwischen beobachteten und kontrollierten Größen sowie zwischen Umgebungs- und Systemgrößen und trifft darüberhinaus Festlegungen bezüglich ihrer Sichtbarkeit. Diese differenzierte Betrachtung liefert Kriterien, um die Aussa- gen einer Anforderungsspezifikation in Domänenwissen, Anforderungen und Maschinenspezi- fikation zu klassifizieren. Ausgangspunkt für die weitere Systementwicklung ist ausschließlich die Maschinenspezifikation. Das Referenzmodell ist Grundlage für die Spezifikationstechnik FoReST. In FoReST werden sämtliche geforderten Klassifikationen syntaktisch unterstützt. Ferner liefert das Referenzmo- dell Kriterien für die Überprüfung der Vollständigkeit einer Anforderungsspezifikation sowie die Erkennung von Konflikten. Requirement-Pattern-Sammlung. Wie sich gezeigt hat, ist die Gewinnung von Mustern mit hohem Zeitaufwand verbunden. “Gute” Requirement Patterns sind kein “Abfallprodukt” der Anforderungsanalyse, sondern müssen systematisch entwickelt und kontinuierlich verbessert werden, entsprechend den Schritten analyze und package des Quality Improvement Paradigms (QIP). Aus diesem Grund geht es bei der Weiterentwicklung der initialen Requirement-Pat- tern-Sammlung nicht primär darum, möglichst viele Muster zu gewinnen, sondern auch und vor allem um die Verbesserung der vorhandenen Muster und die graduelle Ergänzungen der Sammlung. Es wurden mehrere umfangreiche Fallstudien zur Anforderungsspezifikation durchgeführt (s. u.), 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 ersten Version stark verändert, auch wenn sich die Anzahl der Muster kaum erhöht hat und momentan bei 12 liegt. Verschiedene Stadien von Requirement Patterns sind in [3], [7] und [8] dokumentiert. In [3] wird die Gewinnung von Requirement Patterns im allgemeinen und des LazyReaction-Patterns im besonderen ausführlich dargestellt. Fallstudien. Prozessmodell, Beschreibungstechniken und Mustersammlung wurden in mehre- ren umfangreichen Fallstudien eingesetzt und erprobt. Die dabei gesammelten Erfahrungen Computer Networks Group, University of Kaiserslautern -3-
sind jeweils unmittelbar in die Weiterentwicklung und Konsolidierung des Ansatzes eingeflos-
sen. Folgende Fallstudien wurden durchgeführt:
• Anforderungsspezifikation “Lichtsteuerung (Version 1)” [4] [13] als Formalisierung
einer Anforderungsbeschreibung für das Dagstuhl-Seminar Nr. 99241
• Anforderungsspezifikation “Lichtsteuerung (Version 2)” [2] als Formalisierung einer
Anforderungsbeschreibung für die Sonderausgabe des Journal of Universal Computer
Science “Requirements Engineering: The Light Control Case Study”
• Anforderungsspezifikation “Lichtsteuerung (Version 3)” als Formalisierung einer
Anforderungsbeschreibung, die Ausgangspunkt für die durchgängige Entwicklung des
auf der CeBIT’2001 demonstrierten Gebäudemodells war; in dieser Fallstudie wurden
weitere Methoden, Techniken, Werkzeuge und Mustersammlungen (SDL-Pattern-
Ansatz, Pattern-Annotated-SDL, Cadvanced, EnvGen, SDL-Pattern-Pool) eingesetzt.
3 Fazit
Wesentliches Ergebnis ist die Entwicklung und der Einsatz einer musterbasierten Vorgehens-
weise zur Ermittlung von Anwendungsanforderungen [7] [3]. Durch die Wahl häufig auftreten-
der Muster wird das Potenzial für die Wiederverwendbarkeit von Lösungen gesteigert. Dies
betrifft zum einen die Wiederverwendung der Muster selbst (horizontale Wiederverwendung),
zum anderen aber auch die Wiederverwendung von Entscheidungen des Systementwicklungs-
prozesses, soweit sie an die Verwendung von Mustern koppelbar sind (vertikale Wiederver-
wendung).
Die musterbasierte Entwicklung trägt zudem ganz wesentlich zur Verfolgbarkeit von Entwick-
lungsentscheidungen bei. Innerhalb einer Phase führt die Musteranwendung zu einer zusätzli-
chen, orthogonalen Systemstruktur, welche die Art und die Abfolge von Entwicklungsschritten
dokumentiert (horizontale Verfolgbarkeit). Phasenübergreifend werden Abhängigkeiten zwi-
schen Systemteilen verschiedener Abstraktionsstufen sichtbar gemacht (vertikale Verfolgbar-
keit). Die Kommunikation innerhalb des Entwicklerteams wird durch das abstrakte,
problemspezifische Vokabular, das durch die Mustersammlungen definiert ist, unterstützt.
4 Veröffentlichungen
Zeitschriften / Monografien
[1] Avenhaus, J., Gotzhein, R., Härder, T., Litz, L., Madlener, K., Nehmer, J., Richter, M., Ritter, N., Rom-
bach, D., Schürmann, B., Zimmermann, G.: Entwicklung großer Systeme mit generischen Methoden -
Eine Übersicht über den Sonderforschungsbereich 501, Informatik, Forschung und Entwicklung,
13(4):227–234, Dezember 1998
[2] Kronenburg, M., Peper, C.: Application of the FOREST Approach to the Light Control Case Study, Jour-
nal of Universal Computer Science (J.UCS), Special Issue on “Requirements Engineering: The Light
Control Case Study”, Springer, 2000
Tagungsbeiträge
[3] Gotzhein, R., Kronenburg, M., Peper, C.: Reuse in Requirements Engineering: Discovery and Applica-
tion of a Real-Time Requirement Pattern, 5th International Symposium on Formal Techniques in Real-
Time and Fault-Tolerant Systems (FTRTFT’98), Lecture Notes in Computer Science 1486, Springer,
Lyngby, Denmark, September 14-15, 1998. pp. 65-74
Computer Networks Group, University of Kaiserslautern -4-[4] Gotzhein, R., Kronenburg, M., Peper, C.: Pattern-Based Requirements Capture Applied: The SFB 501
Case Study, in: E. Börger, B. Hörger, D. Parnas, D. Rombach (Hrsg.), Requirements Capture, Documen-
tation, and Validation, Dagstuhl-Seminar-Report 242, Juni 1999
[5] Kronenburg, M., Peper, C.: Definition and Instantiation of a Reference Model for Problem Specificati-
ons, 11th International Conference on Software Engineering and Knowledge Engineering (SEKE’99),
Kaiserslautern, 1999
[6] Peper, C.: Transformations in Pattern-Based System Specifications, 9. GI/ITG-Fachgespräch Formale
Beschreibungstechniken für verteilte Systems (FBT’99), München, Herbert-Utz-Verlag, 1999
[7] Peper, C., Gotzhein, R., Kronenburg, M.: A Generic Approach to the Formal Specification of Require-
ments. Proceedings of the 1st IEEE International Conference on Formal Engineering Methods
(ICFEM’97), Hiroshima, Japan, November 1997, pp. 252-261
Technische Berichte
[8] Gotzhein, R., Kronenburg, M., Peper, C.: Reuse in Requirements Engineering: Discovery and Applica-
tion of a Real-Time Requirement Pattern, SFB 501 Report 8/98, Fachbereich Informatik, Universität Kai-
serslautern, 1998
[9] Kronenburg, M., Peper, C.: An Example of a FOREST Problem Specification, SFB 501 Report 01/1999,
Fachbereich Informatik, Universität Kaiserslautern, 1999
[10] R. Gotzhein, M. Kronenburg, C. Peper: Specifying and Reasoning about Generic Real-Time Require-
ments - A Case Study, SFB 501 Report 15/96, Fachbereich Informatik, Universität Kaiserslautern, 1996
[11] M. Kronenburg, R. Gotzhein, C. Peper: A Tailored Real-Time Temporal Logic for Specifying Require-
ments of Building Automation Systems, SFB 501 Report 16/96, Fachbereich Informatik, Universität Kai-
serslautern, 1996
[12] C. Peper, R. Gotzhein, M. Kronenburg: Formal Specification of Real-Time Requirements for Building
Automation Systems, SFB 501 Report 1/97, Fachbereich Informatik, Universität Kaiserslautern, 1997
Online-Dokumente
[13] Kronenburg, M., Peper, C.: Specification of the Case Study “Light Control System”, Dagstuhl-Seminar
Requirements Capture, Documentation, and Validation, 13.-18. Juni 99, http://rn.informatik.uni-kl.de/
~forest/examples
Computer Networks Group, University of Kaiserslautern -5-Sie können auch lesen
