1 Einleitung
Die Technik entwickelt sich vom Primitiven ĂŒber das Komplizierte zum Einfachen. (Antoine de Saint-ExupĂ©ry)
1.1 Vorweg
»FrĂŒher war alles besser!«
»FrĂŒher war alles viel einfacher. Da konnte man noch mit einer Handvoll Leute etwas auf die Beine stellen. Heute sind es schnell hundert Leute, die man braucht, um ein ordentliches System zu entwickeln. Und die kriegen dann meist nichts auf die Reihe ... Denk doch nur mal an das Projekt P08/15. Dabei sind dort Experten aus allen Bereichen vertreten ...«
Wechselstimmung
Solche oder Ă€hnliche Feierabendmonologe höre ich immer hĂ€ufiger. Als GeschĂ€ftsfĂŒhrer eines Beratungsunternehmens treffe ich viele Personen aus den unterschiedlichsten Branchen. Der Tenor ist aber gleich. Woran liegt das? Ganz einfach: am Fortschritt.
Wir sind an einem Punkt angekommen, an dem komplexe und verteilte Systeme gefordert werden, die von komplexen und verteilten Organisationen entwickelt werden. Die herkömmlichen Entwicklungsmethoden sind aber noch nicht bereit, diese ausreichend schnell und in einem akzeptablen Kostenrahmen zur VerfĂŒgung zu stellen.
»Fortschritt ist unaufhaltsam.«
Wir können nicht erwarten, immer fortschrittlichere, gröĂere, bessere Systeme zu entwickeln und dabei weiterhin dieselben Werkzeuge einzusetzen. Die Vorgehensweisen, Modellierungssprachen, Entwicklungsumgebungen und Rollen wie der Systems Engineer mĂŒssen an dem Fortschritt teilhaben und sich ebenfalls weiterentwickeln.
Von Bits zu Objekten
In der Softwareentwicklung ist dieser Weg an einem Beispiel deutlich zu sehen. Angefangen bei Lochkarten ĂŒber Assembler, prozedurale Programmiersprachen bis hin zu den objektorientierten Sprachen kennen die Entwicklungswerkzeuge immer gröĂere Bausteine (von Bits bis Klassen/Objekte). Sie erleichtern so die Beschreibung komplexer Systeme. Der Weg zur nĂ€chsten Generation ist bereits eingeschlagen: Die grafische Unified Modeling Language (UMLâą) oder domĂ€nenspezifische Sprachen (DSL) werden zunehmend verwendet, um Softwaresysteme zu entwickeln, und mit diesen Sprachen werden immer mehr Aufgaben gelöst, die vorher mit herkömmlichen Programmiersprachen erledigt wurden (Abb. 1.1).
Abbildung 1.1 Steigende Abstraktion der Programmiersprachen
1+1=3
Das Gesamtsystem ist mehr als die Summe seiner Bausteine. Die Wechselwirkungen zwischen den Elementen können komplex und schwer kontrollierbar sein. Das fĂŒhrt dazu, dass Vorgehensmodelle und Notationen benötigt werden, um effektiv diese Systeme entwickeln zu können. Ansonsten werden die Kosten der Entwicklung in naher Zukunft in keinem VerhĂ€ltnis zum akzeptablen Preis der Produkte stehen.
Systems Engineering
Das Systems Engineering (Systementwicklung1) setzt sich schon lĂ€nger mit dieser Problematik auseinander. Die Entwicklung groĂer Systeme, bei der viele unterschiedliche Disziplinen beteiligt sind, erfordert ganzheitliche Sichtweisen. Also losgelöst vom spezifischem Detailwissen werden die Anforderungen und Strukturen des Systems betrachtet, der gesamte Lebenszyklus von der Idee bis zur Entsorgung geplant, um insgesamt ein System zu entwickeln, das den WĂŒnschen aller Beteiligten entspricht.
Modellbasiertes Systems Engineering (MBSE)
Im Systems Engineering fordert der Fortschritt einen Paradigmenwechsel: vom dokumentenzentrierten zum modellbasierten Systems Engineering (MBSE). Das Modell wird zur Quelle aller relevanten Informationen. Um gleich einem gĂ€ngigen MissverstĂ€ndnis vorzugreifen: Die Dokumente sollen nicht verschwinden. Nur sind sie nicht mehr die Quelle der Informationen, sondern eine Sicht auf das Modell, beispielsweise automatisch erzeugt von einem Modellierungswerkzeug. Die Modellierungssprachen OMG Systems Modeling Language (OMG SysMLâą) und UML spielen in diesem Szenario natĂŒrlich eine wichtige Rolle.
Voneinander lernen
UML â S. 201
SysML â S. 309
INCOSE â S. 19
Die Softwareentwicklung kann viel vom Systems Engineering lernen. Zum Nehmen gehört aber auch ein Geben. Umgekehrt kann das Systems Engineering auch von der Softwareentwicklung lernen. Werkzeuge und Methoden zur Modellierung sind hier schon sehr weit entwickelt. Die UML ist eine Modellierungssprache aus diesem Umfeld. Sie hat sich als weltweiter Standard etabliert. Dem Systems Engineering fehlte bisher eine standardisierte Modellierungssprache. Das wird sich durch die neue SysML2 Ă€ndern. Sie basiert auf der UML und wird von fĂŒhrenden Unternehmen aus der Systems-Engineering-Branche einschlieĂlich des International Council on Systems Engineering (INCOSE) unterstĂŒtzt.
1.1.1 Passt das Buch zu mir?
Dieses Buch wird Sie interessieren und fĂŒr Sie sehr hilfreich sein, wenn Sie ...
- die Modellierungssprache SysML lernen wollen,
- Systeme beschreiben, spezifizieren und entwickeln,
- mit komplexen Systemen arbeiten,
- Systems Engineering mit SysML durchfĂŒhren wollen,
- Systeme mit gemischten Disziplinen â beispielsweise Software und Hardware â entwickeln,
- ein ganzheitliches Modell erstellen wollen, in dem Elemente nachvollziehbar zusammenhÀngen (Traceability),
- einen durchgÀngigen Weg von der Systemidee zum Systemdesign kennenlernen wollen.
Wenn Sie sich nicht in den obigen Punkten wiederfinden, fragen Sie mich, ob das Buch fĂŒr Sie wertvoll sein könnte. Ich freue mich ĂŒber eine E-Mail von Ihnen:
[email protected]. Werkzeugkasten SYSMOD
Sie lernen in diesem Buch einen Werkzeugkasten kennen, mit dessen Hilfe Sie einen Weg von der Idee eines Systems zur Architektur finden. Die Ergebnisse halten wir in detaillierten und aussagekrĂ€ftigen Modellen fest. Die Modellierungssprache ist SysML. Der Werkzeugkasten heiĂt SYSMOD â abgeleitet von Systemmodellierungsprozess bzw. Systems Modeling Process.
1.1.2 Was bietet mir das Buch?
In diesem Buch finden Sie:
- den Werkzeugkasten SYSMOD zur Systementwicklung von der Systemidee zur Systemarchitektur,
- Steckbriefe zu den Werkzeugen, die Sie individuell zu einem Gesamtvorgehen zusammensetzen können â das Buch gibt Ihnen einen Standardweg vor,
- eine Beschreibung der SysML und UML,
- eine EinfĂŒhrung in das Systems Engineering,
- Randnotizen beispielsweise ĂŒber Variantenmanagement, funktionale Architekturen, Simulation, Testen und Modellierungsmuster,
- Best Practices zu SysML und SYSMOD.
1.1.3 Wie ist das Buch entstanden? Und danke!
UML ohne Software
Die Idee zu diesem Buch hatte ich im Jahr 2003 bekommen. Zu dieser Zeit hatte ich viele Seminare und BeratungseinsĂ€tze zum Thema Analyse und Design mit der UML. Der Teilnehmerkreis konzentrierte sich auf Softwareentwickler â vom Programmierer bis zum Projektleiter. In einem Seminar hatte sich allerdings ein auĂergewöhnlicher Teilnehmerkreis zusammengefunden: Ingenieure, z. B. Nachrichtentechniker, aber kein einziger Softwareentwickler. Sie planten ein groĂes Projekt, das Software, aber auch bauliche MaĂnahmen, Hardware und andere Disziplinen beinhaltete. In der Schulung habe ich den Softwareaspekt reduziert und die Analyse- und Designtechniken allgemeiner erlĂ€utert. FĂŒr die Teilnehmer hat sich hieraus eine hervorragende Vorgehensweise fĂŒr ihr Projekt ergeben.
Diese Teilnehmerkonstellation war ab dann kein Einzelfall mehr. Es folgten weitere Seminare, Workshops und BeratungsauftrĂ€ge, in denen keine Softwareentwickler, sondern Ingenieure aus anderen Disziplinen teilnahmen, die Analyse und Design mit der UML fĂŒr ihre Arbeit kennenlernen wollten. In mir keimten zunehmend Fragestellungen, Ideen und weiterfĂŒhrende Ăberlegungen auf: Wie viel Software enthĂ€lt eigentlich die UML? Wie beschreibe ich Anforderungen mit der UML? Wie gehe ich mit hybriden Systemen um? Mir wurde langsam bewusst, dass die Sprache UML und die Vorgehensweise in vielen Bereichen unabhĂ€ngig von Software eingesetzt werden kann.
Systems Engineering und SysML
OMG â...