close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

1 Was wird modelliert? - Software and Systems Engineering

EinbettenHerunterladen
Pladoyer fur ein einheitliches Grundgerust bei der System- und
Softwaremodellierung
B. Paech
Institut fur Informatik, Technische Universitat Munchen
D-80333 Munchen, Germany
email: paech@informatik.tu-muenchen.de
Zusammenfassung
In diesem Beitrag stellen wir einen Grundgerust zur Einordnung von Modellierungstechniken in
der System- und Softwareentwicklung vor. Dieses Grundgerust macht die Vielzahl der bei der Modellierung relevanten Fragestellungen deutlich, zeigt aber auch einen Weg um diese Vielfalt zu systematisieren. Mit diesem Beitrag soll keine endgultige Losung fur diese Systematisierung vorgestellt werden,
sondern eine Diskussionsgrundlage fur die Frage gescha en werden, ob ein einheitliches Grundgerust
moglich und sinnvoll ist bzw. wie es aussehen sollte.
In diesem Workshop werden verschiedene Modellierungskonzepte und -vorgehensweisen verglichen. Angesichts der Fulle der unterschiedlichen Modellierungstechniken in der Literatur und der industriellen Praxis
ist diese Gegenuberstellung dringend erforderlich. Dies wurde auch bei einer Erhebung unter 17 Industriepartnern im Rahmen des Bayerischen Forschungverbunds Software Engineering BEF+ 96] bestatigt
DHP+ 98]. Dort wurde insbesondere eine klare Bewertung gefordert, welche Modellierungstechniken zu
welchen Zweck verwendet werden konnen. Diese Bewertung erfordert allerdings einen Konsens daruber,
was die wesentlichen Kriterien bei der Verwendung von Modellen in der System- und Softwaremodellierung sind. Ob dieser Konsens zu erreichen ist, wird sich im Verlauf des Workshops zeigen.
Im folgenden stelle ich ein Grundgerust zur Einordnung der verschiedenen Modellierungstechniken vor.
Dieses Grundgerust macht die Vielzahl der bei der Modellierung relevanten Fragestellungen deutlich,
zeigt aber auch einen Weg um diese Vielfalt zu systematisieren. Mit diesem Beitrag soll keine endgultige
Losung fur diese Systematisierung vorgestellt werden, sondern eine Diskussionsgrundlage fur die Frage
gescha en werden, ob ein einheitliches Grundgerust moglich und sinnvoll ist bzw. wie es aussehen sollte.
Die Kernpunkt dieses Grundgerusts sind die folgenden drei Fragen:
Was wird modelliert?
Welche Aspekte werden modelliert?
Wie werden die Modelle im Proze der System- und Softwareentwicklung verwendet?
Wir gehen nachfolgend auf diese Fragen naher ein. Dabei fokussieren wir auf graphische Modellierungstechniken, die typischerweise semi-formal sind (d.h. mit festgelegter Syntax, aber ohne festgelegte Semantik). Am Schlu des Beitrags diskutieren wir noch gesondert die Einbindung formaler Modellierungstechniken.
1 Was wird modelliert?
Im Lauf der System- und Softwareentwicklung werden typischerweise drei verschiedene Systeme betrachtet:
das Anwendungssystem, d.h. das Umfeld des zu entwickelnden Softwaresystems - bei Informationssystemen typischerweise ein Unternehmensausschnitt,
This paper originated in the
ForSoft project supported by the Bayerische Forschungsstiftung.
1
das Nutzungssystem, d.h. die Interaktion zwischen BenutzerInnen und Softwaresystem bei der Aufgabenerfullung, und
das Softwaresystem selbst.
Bei der Modellierung werden diese Systeme oft nicht klar getrennt. So wird z.B. die Modellierung der Aufgabenerfullung im Anwendungssystem oft mit der Modellierung des Anwendungskerns im Softwaresystem
vermischt.
Typische Modellierungstechniken fur das Anwendungssystem sind heute Daten- bzw. Geschaftsproze modelle. Letzter thematisieren vor allem die Beziehung zu den Kunden. Sozio-technische Ansatze SN93]
fokussieren dagegen mehr auf die Bedurfnisse der Mitarbeiterinnen und Mitarbeiter im Unternehmen.
Die Modellierung des Nutzungssystems wurde lange Zeit als eigenstandiges Forschungsgebiet (SoftwareErgonomie) angesehen, und wird erst in letzter Zeit zunehmend als Teil der Softwareentwicklung betrachtet. Ein wichtiger Beitrag dazu waren die Use Cases von Jacobson Jac92]. Typischerweise konnen bei
den Modellen im Nutzungssystem sehr viele verschiedene Abstraktionsebenen unterschieden werden: von
den Arbeitsaufgaben uber die Systemfunktionsaufrufe oder Dialoge bis hin zu einzelnen Mausklicks.
Auch bei der Modellierung des Softwaresystems sind verschiedene Abstraktionsebenen zu unterscheiden:
von der konzeptuellen Beschreibung bis hin zu Code.
Da alle drei Systeme auch als informationsverarbeitende Systeme angesehen werden konnen, ist es sinnvoll
die gleichen Modellierungstechniken fur die verschiedenen Systeme einzusetzen. Allerdings ist sorgfaltig
abzuwagen, welche Aspekte wichtig sind, und welche Abstraktionsebene angemessen ist: so reicht es bei
der Anwendungssystemmodellierung nicht aus, nur Daten und Verhalten zu modellieren. Sehr wichtig
sind auch die Interessen und Ziele der menschlichen Akteure im Anwendungssystem (siehe z.B. Yu97]).
Weiterhin ist eine sehr detaillierte Verhaltensmodellierung des Anwendungssystems nicht sinnvoll, im
Gegensatz zum Softwaresystem.
Eine erste Einordnung von Modellierungstechniken ist also moglich im Hinblick auf die Art des modellierten Systems. Eine detailliertere Betrachtung mu sich auf die modellierten Systemaspekte beziehen
(siehe den nachsten Abschnitt). Um die Angemessenheit der Modellierungstechnik fur das jeweilige System bewerten zu konnen, ist eine Priorisierung der Aspekte und der Abstraktionsebenen fur die jeweiligen
Systeme notig.
2 Welche Aspekte werden modelliert?
Abbildung 1 zeigt die typischen Aspekte eines informationsverarbeitenden Systems in einem Metamodell.
Anhand dieser Aspekte lassen sich viele verschiedene Modellierungstechniken einordnen. Das Systemmodell ist stark beein u t von Uberlegungen zur formalen Fundierung von Modellierungstechniken mit
einem mathematischen Systemmodell BHH+ 97, Pae96]. Die hier angegebenen Beziehungen zwischen
den Konzepten haben keine formale Semantik, sondern reprasentieren nur wichtige Zusammenhange,
die typischerweise mit den Modellierungstechniken erfa t werden. Die Raute steht fur die besteht-ausBeziehung, der Pfeil fur die ist-ein-Beziehung.
Im folgenden beschreiben wir kurz die einzelnen Aspekte. Die Beziehungen sind in der Erklarung kursiv
hervorgehoben.
Akteur/System Akteure sind die wesentlichen Bestandteile eines Systems. Die Akteure kommunizieren
miteinander, dazu ist die Kenntnis-Beziehung notwendig. Fur die Modellierung der Kommunikation
werden typischerweise verschiedene Annahmen getro en: z.B. asynchroner oder synchroner Nachrichtenaustausch, gerichtete oder ungerichtete Nachrichten an einzelne oder mehrere Empfanger,
oder Sicherheit des Kommunikationsmediums. Akteure konnen selbst wieder aus kommunizierenden Akteuren zusammengesetzt (und damit Systeme) sein.
Daten/Zustand Daten sind in den Akteuren gekapselt. Ihre Werte sind zeitlich variabel. Fur andere
Akteure sind die Daten nur uber Kommunikation zugreifbar. Bei der Modellierung von Daten ist
zu unterscheiden:
Datentypmodellierung beschreibt die Menge der moglichen Datenwerte, z.B. durch Abstrakte
Datentypen.
statische Datenmodellierung beschreibt die Menge der moglichen Datenzustande eines Akteurs, typischerweise durch Entity-Relationship-Diagramme.
2
System
Zielstruktur
hat
Rolle
Ziel
hat
Akteur
Dienst
kennt
führt aus
ist Partner von
kapselt
sendet
kapselt
empfängt
Aktivität
Daten
Zustand
Interaktion
Nachricht
greift zu auf
Prozeß
Abbildung 1: Das Systemkonzeptmodell
Datenverhaltensmodellierung beschreibt die Veranderung des Datenzustands uber die Zeit,
z.B. durch Zustandsubergangsdiagramme.
Aktivitat/Proze Aktivitaten strukturieren das interne Verhalten eines Akteurs. Die Struktur wird
bestimmt durch den Daten- und Steuer u zwischen den Aktivitaten und durch den Aufgabenkontext. Aktivitaten greifen auf Daten zu und senden und empfangen Nachrichten. Aktivitaten
konnen selbst wieder aus Aktivitaten zusammengesetzt (und damit Prozesse) sein. Wieder konnen
zwei Arten der Aktivitatsmodellierung unterschieden werden:
statische Aktivitatsmodellierung beschreibt die Menge der moglichen Daten usse zwischen
den Aktivitaten, z.B. die Daten u diagramme der strukturierten Analyse.
Aktivitatsverhaltensmodellierung beschreibt die Abfolge der Aktivitaten, entweder vollstandig
oder als einzelne Prozesse. Dabei kommt zum Daten u Steuer u hinzu. Zur Darstellung
komplexen Steuer usses konnen Ereignisse hinzugenommen werden. Steht die Synchronisation
der Aktivitaten auf dem gemeinsamen Datenraum im Vordergrund ist, die Hinzunahme von
Zustandselementen wie in Petrinetzen sinnvoll.
Typischerweise werden Aktivitatenfolgen auch akteursubergreifend modelliert (z.B. Geschaftsproze diagramme). Die Zuordnung der Aktivitaten zu Akteuren bzw. Rollen im Modell macht semantisch einen gro en Unterschied: Ohne Rollen arbeiten die Aktivitaten auf einem gemeinsamen
Datenraum, durch die Zuordnung zu Rollen haben die Aktivitaten nur Zugri auf die Daten der
eigenen Rolle.
Dienst Dienste strukturieren das externe Verhalten eines Akteurs. Sie kapseln eine von au en ansto bare
Folge von Aktivitaten. Bzgl. der Dienstausfuhrung sind wieder fur die Modellierung einige Annahmen zu tre en: z.B. werden beim Aufruf Daten ubergeben, wartet der Aufrufer auf das Ergebnis,
konnen in einem Akteur mehrere Dienste gleichzeitig aktiv sein. Wir unterscheiden wieder statische
und dynamische Dienstmodellierung:
statische Dienstmodellierung beschreibt die Menge aller moglichen Dienstinstanzen eines Akteurs und die moglichen gegenseitigen Aufrufbeziehungen und Verschachtelungen. Diese Zusammenhange werden typischerweise bei der prozeduralen Programmierung modelliert.
Dienstverhaltensmodellierung beschreibt die Ausfuhrung eines Dienstes. Bei mehreren Threads
ist insbesondere die Synchronisation der Dienste auf dem gemeinsamen Datenraum des Akteurs
interessant. Fur die Dienstverhaltensmodellierung konnen die gleichen Modellierungstechniken
wie fur Aktivitatsverhaltensmodellierung eingesetzt werden.
Ziel/Zielstruktur Ziele beschreiben selbstgesetzte Rahmenbedingungen einer Rolle bei der Aufgabenerfullung. Ein Beispiel fur eine statische Zielmodellierung wird in Yu97] beschrieben. Dort werden
3
die Abhangigkeiten zwischen Zielzustanden, Ressourcen, Kriterien und Aufgaben (auch verschiedener Akteure) modelliert. Spezielle Wege durch diese Zielstruktur entsprechen moglichen Wegen der
Zielerreichung.
Nachricht/Interaktion Nachrichten sind die Grundlage der Kommunikation zwischen den Akteuren.
Sie werden nur im Zusammenhang von Interaktion zwischen einzelnen Akteuren bzw. Rollen modelliert. Wie beim Daten u kann man die Menge der moglichen Nachrichten usse (die Kanale) oder
spezielle Abfolgen ( z.B. Sequenz- und Kollaborationsdiagramme in UML BRJ97]) modellieren.
Rolle Rollen charakterisieren einen zusammenhangenden Aufgabenbereich eines Akteurs durch Angabe
von Daten, der auf ihnen operierenden Dienste und der Kommunikationspartner. Klassen in der
objektorientierten Modellierung erlauben nur eine eingeschrankte Rollenmodellierung, in der jeder
Akteur (d.h. jedes Objekt) nur eine Rolle besitzt. Bei der
statischen Rollenmodellierung werden die einzelnen Rollen mit ihren Daten, Diensten und
Partnern beschrieben. Ein typisches Beispiel sind die Objektmodelle der objektorientierten
Methoden.
Rollenverhaltensmodellierung beschreibt das Zusammenspiel der Dienste einer Rolle. Im sequentiellen Fall (wie bei den typischen objektorientierten Programmiersprachen) wird dazu
ein Zustandsubergangsdiagramm verwendet, dessen Transitionen mit Dienstaufrufen beschriftet sind. Sind die Dienstinstanzen innerhalb eines Akteurs nebenlau g, so konnen sie nicht
mehr als atomar betrachtet werden. PR97] zeigt einen Ansatz, wie man in diesem Fall das
Rollenverhalten aus den einzelnen Dienstbeschreibungen ableiten kann.
Durch die obige Diskussion wird deutlich, da Diagramme mit der gleichen Syntax zu sehr verschiedenen
Zwecken eingesetzt werden konnen (z.B. Zustandsubergangsdiagramme fur Rollenverhalten, Dienstverhalten und Datenverhalten). Umgekehrt konnen kleine notationalle Erweiterungen starke Auswirkungen
auf die Semantik haben (z.B. Aktivitatsfolgen mit und ohne Rollen). Der Wunsch nach mglst. wenig
verschiedenen Modellierungstechniken steht also im Widerstreit mit der visuellen Unterscheidungen verschiedener Modellierungskonzepte.
3 Wie werden die Modelle im Proze des System- und Softwareentwicklung verwendet?
Modelle werden in der System- und Softwareentwicklung innerhalb einer Methode eingesetzt. Eine Methode dient zur Erlangung von Erkenntnissen und Ergebnissen. Die Frage ist also, welche Erkenntnisse
sich durch die Modelle gewinnen lassen und welchen Stellenwert sie im Hinblick auf die Produkt der
Methode haben.
Erkenntnisse Modelle dienen zur Wissens- und Konsensbildung zwischen den unterschiedlichen Betei-
ligten, zur Untersuchung von Eigenschaften des modellierten Systems, und als Vorgabe fur ein zu
realisierendes System. Je nach Einsatzzweck ergeben sich unterschiedliche Anforderungen an die
Anschaulichkeit und Genauigkeit der Modelle. Die Wichtigkeit der Erkenntnisse im Gesamtproze
gibt einen Rahmen fur den Modellierungsaufwand vor.
Produkte Ein System wird typischerweise durch drei Produkte beschrieben: die externe Aufgabenspezi kation, die interne Aktivitatenspezi kation und der Entwurf. Bei den typischen Softwareentwicklungsmethoden wird die externe Aufgabenspezi kation meist nur fur das Softwaresystem
angegeben, die interne Aktivitatenspezi kation fur das Anwendungssystem, und fur das Nutzungsund Softwaresystem nur der Entwurf. Diese Produkte lassen sich aber jeweils fur alle drei Systeme
aufstellen. Aus den Erfahrungen mit den strukturierten und objektorientierten Methoden wurde
deutlich, da typischerweise eine Modellierungstechnik nicht fur alle drei Produkte geeignet ist.
Stattdessen werden heute oft fur die interne Aktivitatenspezi kation daten- und proze orientierte
Modellierungstechniken eingesetzt, wahrend ein Entwurf sich gut durch rollen- und interaktionsorientierte Modellierungstechniken beschreiben la t. Fur die externe Aufgabenspezi kationen sind
Ziel- und Dienstbeschreibungen wichtig. Durch die Beschreibung des gleichen Systems mit verschiedenen Modellen entsteht auch die Frage nach der Beziehung zwischen den Modellen.
4
Neben der Ausdrucksmachtigkeit sind also die mit einer Modellierungstechnik anwendbaren methodischen
Schritte und der Zusammenhang von Modellen innerhalb einer Methode zu bewerten.
4 Formalitat
Wir haben bisher vor allem semi-formale Beschreibungstechniken diskutiert. Je gro er die Wichtigkeit
von qualitativen und quantitativen Analysen der Modelle und eine Uberprufung der Beziehungen zwischen verschiedenen Modellen ist, desto wichtiger ist eine formale Semantik. Dabei ist aber zwischen
einem direkten Gebrauch des Formalismus, bei dem die Entwickler eine formale Spezi kationssprache
verwenden, d.h. die Details der formalen Semantik verstehen mussen, und einem indirekten Gebrauch zu
unterscheiden, bei dem der Formalismus nur als semantische Grundlage fur ein Regelwerk bzw. Werkzeug
dient, das die Entwickler verwenden konnen ohne die semantischen Details zu kennen Hu 97, Pae95].
Im letzteren Fall mussen nur die Methoden- bzw. Werkzeugentwickler die Details der Semantik kennen.
BHH+ 97] gibt ein Beispiel fur solch eine Semantik. Da eine formale Semantik fur komplexe System
meist sehr aufwendig ist, scheint ein direkter Gebrauch im gesamten Entwicklungsproze nicht moglich.
Interessant ist der indirekte Gebrauch, der eine stellenweise Hinzunahme formaler Spezi kationssprachen
wie Pradikatenlogik erlaubt, ohne sie fur die ganze Systementwicklung zu fordern. Erste Ansatze fur eine
solche Werkzeugunterstutzung bietet z.B. Autofocus HSE97].
Literatur
BEF+ 96] M. Broy, J. Eberspacher, G. Farber, G. Reinhart und H. Wildemann. Bayerischer Forschungsverbund Software - Engineering, Antrag auf Einrichtung an die Bayerische Forschungsstiftung.
http://www.forsoft.de, 1996.
BHH+ 97] R. Breu, U. Hinkel, C. Hofmann, C. Klein, B. Paech, B. Rumpe und V. Thurner. Towards a
Formalization of the Uni ed Modeling Language. In ECOOP, LNCS 1241, Seiten 344{366,
1997.
BRJ97] G. Booch, J. Rumbaugh und I. Jacobson. The Uni ed Modeling Language for Object-Oriented
Development, Version 1.1, 1997.
DHP+ 98] B. Deifel, U. Hinkel, B. Paech, P. Scholz und V. Thurner. Die Praxis der Softwareentwicklung:
Eine Erhebung. submitted to publication, 1998.
HSE97] F. Huber, B. Schatz und G. Einert. Consistent Graphical Speci cation of Distributed Systems.
In J. Fitzgerald, C. B. Jones und P. Lucas, Hrsg., FME '97, LNCS 1313, Seiten 122 { 141.
Springer, 1997.
Hu 97] H. Hu mann. Formal Foundations for Software Engineering Methods, LNCS 1322. Springer,
1997.
Jac92] I. Jacobson. Object-Oriented Software Engineering. Addison-Wesley, 1992.
Pae95] B. Paech. A Methodology Integrating Formal and Informal Software Development. In
M.Wirsing, Hrsg., ICSE-17 Workshop on Formal Methods Application in Software Engineering Practice, Seiten 61{68, 1995.
Pae96] B. Paech. Algebraic View Speci cation. In M.Wirsing, Hrsg., AMAST'96, LNCS 1101, Seiten
444{457, 1996.
PR97] B. Paech und B. Rumpe. State Based Service Description. In H. Bowman und J. Derrick,
Hrsg., FMOODS, Volume 2, Seiten 293{304. Chapman and Hall, 1997.
SN93] D. Schuler und A. Namioka. Participatory Design - Principles and Practices. Lawrence
Erlbaum Associates, 1993.
Yu97]
E.S.K. Yu. Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering. In Symposium on Requirements Engineering, Seiten 226{235. IEEE, 1997.
5
Document
Kategorie
Internet
Seitenansichten
8
Dateigröße
145 KB
Tags
1/--Seiten
melden