Post on 25-May-2020
Systems Engineering and Project Management
(Modellierungsprozess) Prof. Dr. Franz Wotawa
Institute for Software Technology wotawa@ist.tugraz.at
Modellierungsprozess SYSMOD nach Tim Weilkiens, Systems Engineering mit SysML/UML, dpunkt.verlag GmbH, 3. Auflage, 2014.
Grundlegende Idee (“Blackbox-Sichtweise auf Systeme”): – Elemente identifizieren, – Kontext beschreiben – Innenansicht weiter ausarbeiten
SYSMOD Rollenkonzept
SYSMOD Rollenkonzept
Systems Engineer – Anforderungsanalytiker: Erheben und
Verwalten der Systemanforderungen – Systemarchitekt: Leitet aus Anforderungen die
Lösungsarchitektur ab Projektleiter Systemtester
SYSMOD - Übersicht Aufgaben:
1. Systemidee und Systemziele beschreiben 2. Basisarchitektur festlegen 3. Anforderungen ermitteln 4. Systemkontext modellieren 5. Anwendungsfälle modellieren 6. Fachwissen modellieren
Achtung: iteratives Vorgehen gewünscht!
SYSMOD - Übersicht
SYSMOD Architekturprozess
Dokumente
[ Projekttagebuch: Sammlung von Notizen während des Projekts ]
Protokolle der Arbeitstreffen: – Titel – Ort, Datum – Teilnehmer – Beschreibung der Inhalte und Ergebnisse
Start ist immer eine Systemidee!
Beschreibung der Systemidee Welche Innovationen werden benötigt? Innovationen sind nicht per se gut Anforderungen können Innovationen bremsen Anforderungen/Ideen sollen nicht die Lösung vorwegnehmen! In Systems Engineering sollten mehrere potentielle Lösungen erstellt und verglichen werden.
Systemidee
Suchen Sie nach dem idealen System Fokus auf Einfachheit!
Methode zum Finden innovativer Lösungen: Design Thinking! – Disruptive Innovationen als Ziel – Fokus auf menschliche Bedürfnisse – Iterativer Prozess
Design Thinking
SYSMOD Prozess im Detail
Beschreibung der einzelnen Phasen mit Hilfe eines Steckbriefs
(1) Systemidee und –ziele beschreiben
Ein- und ausgehende Daten: – Systemidee – Systemziele
Verantwortliche Rolle: – Projektleiter
Beteiligte Rollen: – Anforderungsanalytiker
(1) Systemidee und –ziele beschreiben
Motivation / Beschreibung: – Warum? Die Systemidee und Ziele des Systems
müssen allen Beteiligten bekannt sein. – Was? Beschreiben Sie die Idee und die Ziele des
Systems in kurzer und lesenswerter Form. – Wie? Die Informationen werden in Workshops
erarbeitet und dokumentiert. – Wohin? Systemidee und –ziele sind Basiswissen
für alle folgenden Schritte!
(1) Systemidee und –ziele beschreiben
Leitfragen: q Wie kann das System in 5 Minuten vorgestellt
werden? q Was sind die drei wichtigsten Ziele des Systems? q Sind alle Projektbeteiligten über die Ziele
informiert? q Welche Ziele verfolgt das Projekt nicht?
Modellelemente: – SysML: Anforderungsdiagramm – SYSMOD: Ziel
(2) Basisarchitektur festlegen
Ein- und ausgehende Daten: – Systemidee – Systemziele – Basisarchitektur
Verantwortliche Rolle: – Systemarchitekt
Beteiligte Rollen: – Anforderungsanalytiker
(2) Basisarchitektur festlegen Motivation / Beschreibung:
– Warum? Die Basisarchitektur gibt das Abstraktionsniveau der Anforderungen vor und trennt explizit die Anforderungen von der technischen Lösung.
– Was? Modellieren und beschreiben Sie die Architekturentscheidungen, die als Rahmenbedingung vorgeben sind.
– Wie? Die Basisarchitektur wird mit Blockdiagrammen, Skizzen und textuellen Erläuterungen beschrieben.
– Wohin? Basis für die Projektumsetzung und kann für andere Systementwicklungen wiederverwendet werden.
(2) Basisarchitektur festlegen Leitfragen: q Welche technischen Komponenten sind
vorgegeben? q Wie hoch ist der gewünschte Innovationsgrad? q Welche Architekturentscheidungen sind
vorgegeben? Modellelemente:
– SysML: Blockdefinitionsdiagramm, internes Blockdiagramm, Assoziation, Generalisierung, Rolle, Konnektor, Port
– SYSMOD: System, Subsystem
(3) Anforderungen ermitteln
2 Teile: – Stakeholder
identifizieren – Anforderungen
aufnehmen
(3.1) Stakeholder identifizieren
Ein- und ausgehende Daten: – Systemidee – Systemziele – Basisarchitektur – Stakeholder
Verantwortliche Rolle: – Anforderungsanalytiker
Beteiligte Rollen: – Keine
(3.1) Stakeholder identifizieren
Motivation / Beschreibung: – Warum? Bedürfnisse der Stakeholder sind
entscheident für den Projekterfolg. – Was? Identifikation aller Personen und
Institutionen, die Interesse bzw. Anforderungen ans System haben.
– Wie? Liste der Stakeholder im Workshop erarbeiten und laufend ergänzen.
– Wohin? Stakeholder sind die Quelle für Anforderungen. Ihre Interessen werden festgestellt und analysiert.
(3.1) Stakeholder identifizieren
Leitfragen: q Wer hat Interesse am System? q Was wäre, wenn wir diese Stakeholder und ihre
Interessen nicht berücksichtigen? q Wer wird das System verwenden? q Wer ist betroffen, wenn das System ausfällt? q Wer entsorgt das System?
Modellelemente: – SysML: Anwendungsfalldiagram – SYSMOD: erweiterte Stakeholder
(3.2) Anforderungen aufnehmen
Ein- und ausgehende Daten: – Stakeholder – Basisarchitektur – Anforderungen
Verantwortliche Rolle: – Anforderungsanalytiker
Beteiligte Rollen: – Keine
(3.2) Anforderungen aufnehmen
Motivation / Beschreibung: – Warum? Anforderungen sind die elementare
Grundlage der Systementwicklung. Bestimmen was das System leisten soll.
– Was? Anforderungen werden von Stakeholder erfragt, dokumentiert und strukturiert.
– Wie? Mittels Erhebungstechniken (z.B. Interviews) werden Anforderungen ermittelt und mit SysML beschrieben.
– Wohin? Anforderungen sind Eingangsinformation für die gesamte Systementwicklung.
(3.2) Anforderungen aufnehmen
Leitfragen: q Fragen Sie die richtigen Personen? q Sind die Antworten offiziell? q Stellen Sie die richtigen Fragen? q Ist die Stakeholder-Forderung Pflicht oder Wunsch? q Wie kann überprüft werden, ob die Anforderungen
vom System erfüllt wird? Modellelemente:
– SysML: Anwendungsfalldiagram, Enthältbeziehung, Verfeinerungsbeziehung, Verfolgungsbeziehung
– SYSMOD: erweiterte Anforderung
(4) Systemkontext modellieren
3 Schritte: – Systemakteure identifizieren – System/Akteur-Objektfluss modellieren – Systeminteraktions-
punkte identifizieren
(4.1) Systemakteure identifizieren
Ein- und ausgehende Daten: – Anforderungen – Systemkontext
Verantwortliche Rolle: – Anforderungsanalytiker
Beteiligte Rollen: – Systemarchitekt
(4.1) Systemakteure identifizieren
Motivation / Beschreibung: – Warum? Systemakteure sind direkte
Interaktionspartner für die Dienstleistungen und Schnittstellen entwickelt werden. Beschreibung der Systemgrenzen.
– Was? Alle Benutzer und Systeme, die mit dem zu entwickelten System interagieren.
– Wie? Systemakteure werden primär von den Anforderungen entnommen und im Systemkontextdiagramm modelliert.
– Wohin? Ausgehend von Akteuren werden Dienstleistungen und Schnittstellen des System identifiziert.
(4.1) Systemakteure identifizieren
Leitfragen: q Wer bzw. was gehört zum System? q Wer bzw. was interagiert mit dem System? q Auf welche Kommunikationspartner wollen Sie
sich konzentrieren? q Welche Aspekte wollen Sie mit einer
Akteurskategorie betonen? Modellelemente:
– SysML: Blockdefinitionsdiagramm, internes Blockdiagramm, Assoziation, Rolle, Konnektor
– SYSMOD: System, Akteurskategorien
(4.2) System/Akteur-Objektfluss modellieren
Ein- und ausgehende Daten: – Systemkontext – Systemkontext (Objektfluss)
Verantwortliche Rolle: – Anforderungsanalytiker
Beteiligte Rollen: – Keine
(4.2) System/Akteur-Objektfluss modellieren
Motivation / Beschreibung: – Warum? Zum eindeutigen Verständnis der
Systemeinbettung ist der Objektfluss des Systems mit seiner Umgebung hilfreich.
– Was? Beschreiben Sie die Objekte, die das System mit seiner Umgebung austauscht.
– Wie? Für jeden Akteur werden die relevanten Objekte, die er zum System sendet bzw. vom System erhält, notiert. Der Fokus liegt auf der Objektflussrichtung vom Akteur zum System.
– Wohin? In der Analyse werden die Objektflüsse zum Identifizieren und Beschreiben von Anwendungsfälle genutzt. In der Systemarchitektur müssen sich die Objektflüsse im Inneren des Systems widerspiegeln und den Systemschnittstellen entsprechen.
(4.2) System/Akteur-Objektfluss modellieren
Leitfragen: q Welche Objekte senden die Akteure an das
System? q Sind die Objekte für unser System fachlich
relevant? q Welche Objekte sendet das System an seine
Akteure? Modellelemente:
– SysML: Blockdefinitionsdiagramm, internes Blockdiagramm, Systembaustein, Akteur, Assoziation, Rolle, Konnektor, Objektfluss
(4.3) Systeminteraktionspunkte identifizieren
Ein- und ausgehende Daten: – Systemkontext – Systemkontext (Interaktionspunkte)
Verantwortliche Rolle: – Systemarchitekt
Beteiligte Rollen: – Anforderungsanalytiker
(4.3) Systeminteraktionspunkte identifizieren
Motivation / Beschreibung: – Warum? Die Interaktionspunkte beschreiben die
Schnittstelle zur Systemumgebung (Systemintegration!).
– Was? Beschreiben Sie die Punkte des Systems, über die die Interaktion mit der Umgebung stattfindet.
– Wie? Überlegen Sie sich je Akteur den zugehörigen Interaktionspunkt und spezifizieren Sie die Dienstleisungen und Objekte, die über den Punkt angeboten oder eingefordert werden.
– Wohin? Die Interaktionspunkte werden in der Architektur näher spezifiziert und mit den inneren Bausteinen des Systems verbunden.
(4.3) Systeminteraktionspunkte identifizieren
Leitfragen: q Über welche Wege tauscht das System
Informationen mit seiner Umgebung aus? q Welche Interaktionswege mit den Akteuren
können zusammengeführt werden? Modellelemente:
– SysML: Blockdefinitionsdiagramm, internes Blockdiagramm, Systembaustein, Akteur, Assoziation, Rolle, Konnektor, Port
(5) Anwendungsfälle modellieren
(5.1) Anwendungsfälle identifizieren
Ein- und ausgehende Daten: – Anforderungen – Systemkontext – Anwendungsfälle
Verantwortliche Rolle: – Anforderungsanalytiker
Beteiligte Rollen: – keine
(5.1) Anwendungsfälle identifizieren
Motivation / Beschreibung: – Warum? Anwendungsfälle beschreiben die
Dienstleistungen des Systems. – Was? Anwendungsfälle werden identifiziert und
beteiligten Akteuren zugeordnet. – Wie? Auf Basis der Anforderungen und des
Systemkontexts werden Anwendungsfälle systematisch erarbeitet.
– Wohin? Anwendungsfälle werden mit einer Ablaufbeschreibung versehen und dienen zur Ableitung der Architektur.
(5.1) Anwendungsfälle identifizieren
Leitfragen: q Was kann das System für den einzelnen Akteur
leisten? q Welche Informationen sthen am Anfang eines
Ablaufs? q Welche Ereignisse liefern die Dienstleistungen an die
Akteure? Modellelemente:
– SysML: Anwendungsfalldiagramm, Akteur, Anforderungen, Assoziation, Objektfluss, Verfeinerungsbeziehung
– SYSMOD: Systemanwendungsfall, kontinuierlicher Anwendungsfall (Anwendungsfall der kontinuierlich Ergebnisse liefert)
(5.2) Anwendungsfälle essenziell beschreiben
Ein- und ausgehende Daten: – Anforderungen – Anwendungsfälle – Anwendungsfälle (essenziell)
Verantwortliche Rolle: – Anforderungsanalytiker
Beteiligte Rollen: – keine
(5.2) Anwendungsfälle essenziell beschreiben
Motivation / Beschreibung: – Warum? Benötigen einen Überblick über die
Dienstleistungen des Systems, der schnell ermittelt werden kann und unabhängig von technischen Lösungen ist.
– Was? Beschreibung der fachlichen Intention des Anwendungsfalls in Form essenzieller Schritte ohne technische Details und konkrete Abläufe zu berücksichtigen.
– Wie? Schritte des Standardablaufs überlegen und abstraktion der technischen Details.
– Wohin? Die essenziellen Schritte geben die Struktur der nächsten Detailierungsebene vor. Beschreibung ist stabil und kann für nachfolgende oder verwandte Systeme wiederverwendet werden.
(5.2) Anwendungsfälle essenziell beschreiben
Leitfragen: q Was ist die fachliche Intention des Anwendungsfalls? q Enthält die essenzielle Beschreibung technische
Lösungen? q Heißt ein Essenzschritt wie der Anwendungsfall? q Ist die essenzielle Beschreibung für eine fachkundige
aber projektfremde Person verständlich? q Hat der Anwendungsfall 2-8 essenzielle Schritte?
Modellelemente: – SysML: Anwendungsfalldiagramm, Kommentar – SYSMOD: Systemanwendungsfall
(5.3) Systemprozesse beschreiben
Ein- und ausgehende Daten: – Anwendungsfälle – Systemprozesse (Anwendungsfallübergreifender
Ablauf und besteht aus einer Menge von Anwendungsfällen, die eine sachlogische Ablauffolge haben)
Verantwortliche Rolle: – Anforderungsanalytiker
Beteiligte Rollen: – keine
(5.3) Systemprozesse beschreiben
Motivation / Beschreibung: – Warum? Komplexe Ablaufreihenfolgen zwischen
Anwendungsfällen müssen explizit behandelt und modelliert werden.
– Was? Beschreibung der Ablaufabhängigkeiten zwischen Anwendungsfällen und Zusammenfassung von Abläufen in Systemprozessen.
– Wie? Untersuchung von Ablaufabhängigkeiten fachlich verwandter Anwendungsfälle anhand ihrer Vor- und Nachbedingungen und Beschreibung der Aktivitäten mittels eines Zustandsautomaten.
– Wohin? Systemprozesse müssen in der Architektur berücksichtigt und oft auch umgesetzt werden.
(5.3) Systemprozesse beschreiben
Leitfragen: q Welche Ablaufabhängigkeiten bestehen zwischen
den Anwendungsfällen? q Welche Anwendungsfälle haben eine große
fachliche Nähe? Modellelemente:
– SysML: Anwendungsfalldiagramm, Aktivitätsdiagramm, Enthältbeziehung, Aktivität, Aktion, Kante, Kontrollknoten, Komposition
– SYSMOD: Systemprozess
(5.4) Anwendungsfälle redundanzfrei modellieren
Ein- und ausgehende Daten: – Anwendungsfälle – Anwendungsfälle (redundanzfrei)
Verantwortliche Rolle: – Anforderungsanalytiker
Beteiligte Rollen: – keine
(5.4) Anwendungsfälle redundanzfrei modellieren
Motivation / Beschreibung: – Warum? Redundante Modellinformationen können zu
schwerwiegenden Problemen führen, wenn ihre Konsistenz verletzt wird.
– Was? Identifikation von Gemeinsamkeiten zwischen den Abläufen der Anwendungsfälle. Isolierte Modellierung dieser Bereiche um Redudanzen zu vermeiden.
– Wie? Gemeinsamkeiten zwischen Anwendungsfällen werden in sekundären Anwendungsfällen beschrieben und über Enthältbeziehungen in die primären Anwendungsfälle eingebunden.
– Wohin? Die redundanzfreie Anwendungsfallstruktur liefert gute Anhalstpunkte für eine redundanzfreie Architektur des Systems.
(5.4) Anwendungsfälle redundanzfrei modellieren
Leitfragen: q Welche Anwendungsfallschritte wiederholen
sich in anderen Anwendungsfällen? q Welche Anwendungsfälle sind ähnlich?
Modellelemente: – SysML: Anwendungsfalldiagramm,
Anwendungsfall, Enthältbeziehung, Generalisierung
– SYSMOD: sekundärer Anwendungsfall
(5.5) Anwendungsfallabläufe modellieren
Ein- und ausgehende Daten: – Anforderungen – Anwendungsfälle (essenziell) – Anwendugnsfälle (detailliert)
Verantwortliche Rolle: – Anforderungsanalytiker
Beteiligte Rollen: – Systemarchitekt
(5.5) Anwendungsfallabläufe modellieren
Motivation / Beschreibung: – Warum? Die Ablaufbeschreibungen der
Anwendungsfälle gehören zur Kerninformation der Anforderungsanalyse. Sie geben detailliert das geforderte Verhalten des Systems vor.
– Was? Beschreibung der Abläufe der Anwendungsfälle mit allen Ausnahmen und Varianten.
– Wie? Anwendungsfallabläufe werden mit Aktivitäten der SysML beschrieben.
– Wohin? Die Aktivitäten sind direkte Grundlage für die funktionalen Aspekte der Systemarchitektur. Zur Einbindung des Auftraggebers in die Systementwicklung.
(5.5) Anwendungsfallabläufe modellieren
Leitfragen: q Welche Schritte sind für den Anwendungsfall
notwendig? q Welche Ausnahmen und Varianten können
während des Ablaufs auftreten? q Ist der Anwendungsfall ausreichend detailiert und
verständlich beschrieben? Modellelemente:
– SysML: Aktivitätsdiagramm, Aktivität, Aktion, Kante, Kontrollknoten
– SYSMOD: essenzielle/kontinuierliche Aktivität
(5.6) Objektfluss modellieren
Ein- und ausgehende Daten: – Anforderungen – Anwendungsfälle (detailliert) – Anwendungsfälle (Objektfluss)
Verantwortliche Rolle: – Anforderungsanalytiker
Beteiligte Rollen: – Keine
(5.6) Objektfluss modellieren
Motivation / Beschreibung: – Warum?Betrachtung der ein- und ausgehenden
Daten der Ablaufschritte schärft ihre Beschreibung und liefert wichtige Informationen für die Architektur (Schnittstellen!).
– Was? Modellierung der ein- und ausgehenden Daten der einzelnen Anwendungsschritte und deren Zusammenhänge.
– Wie? Aktionen der Aktivitäten enthalten Pins, die die ein- und ausgehenden Daten beschreiben.
– Wohin? Der Objektfluss fügt dem Modell einen Detailierungsgrad hinzu, der für Simulationen und automatisierte Konsistenzprüfung verwendet werden kann.
(5.6) Objektfluss modellieren
Leitfragen: q Welche Daten werden von einem
Anwendungsfallschritt benötigt? q Welche Daten werden von einem
Anwendungsfallschritt erzeugt bzw. verändert?
Modellelemente: – SysML: Aktivitätsdiagramm, Aktivität,
Aktivitätsparameter, Aktion, Pin, Kontrollknoten
(6) Fachwissen modellieren
Ein- und ausgehende Daten: – Anforderungen – Anwendungsfälle (Objektfluss) – Fachwissen (Struktur der fachlichen Betriffe
des Systems) Verantwortliche Rolle:
– Anforderungsanalytiker Beteiligte Rollen:
– Keine
(6) Fachwissen modellieren
Motivation / Beschreibung: – Warum? Die fachlichen Objekte, die im Objektfluss
der Aktivitäten verwendet wurden, müssen definiert werden. Eindeutiges Verständnis der Stakeholder und Modellkonsistenz sind davon abhängig.
– Was? Modellierung der Struktur fachlich relevanter Begriffe aus Sicht des Systems.
– Wie? Begriffe und Strukturen werden als fachliche Systembausteine in einem Blockdefinitonsdiagramm modelliert.
– Wohin? Das Fachwissensmodell spiegelt die statische Sicht der Fachlogik wider und eignet sich gut zur Abstimmung mit den Auftraggeber und als Grundlage für die Architektur.
(6) Fachwissen modellieren
Leitfragen: q Mit welchen fachlichen Begriffen setzt sich
das System auseinander? q Ist der Begriff dem Auftraggeber bekannt? q Ist der Begriff wichtig genug, um explizit
modelliert zu werden? Modellelemente:
– SysML: Blockdefinitionsdiagramm, Assoziation, Generalisierung
– SYSMOD: fachlicher Systembaustein
(7) Logische Architektur modellieren
Architektur: Summe fundamentaler und später nur schwer zu revidierender Entscheidungen über den Aufbau eines Systems.
Logische Architektur: Beschreibung der technischen Konzepte und Prinzipien des Systems.
(7.1) System/Akteur-Interaktion modellieren
Ein- und ausgehende Daten: – Systemkontext – Anwendungsfälle – Interaktionsmodell (System/Akteur)
Verantwortliche Rolle: – Systemarchitekt
Beteiligte Rollen: – Anforderungsanalytiker
(7.1) System/Akteur-Interaktion modellieren
Motivation / Beschreibung: – Warum? Der Systemkontext und die
Anwendungsfälle betrachten nicht detailliert die Interaktion zwischen System und Akteuren, was zu Fehleinschätzungen der Benutzbarkeit un Systemintegration führen kann.
– Was? Beschreibung der Interaktionen zwischen System und Akteuren bezogen auf einen Anwendungsfall.
– Wie? Die Interaktion zwischen System und Akteuren wird in einem Sequenzdiagramm für ausgewählte Ablaufszenarien beschrieben.
– Wohin? Die System/Akteur-Interaktion liefert eine Vorlage für das Design, speziell zur Definition der Schnittstellen.
(7.1) System/Akteur-Interaktion modellieren
Leitfragen: q Welche Anfragen senden die Akteure während
eines Anwendungsfallablaufs an das System? q Welche Anfragen sendet das System während
eines Anwendungsfallablaufs an die Akteure? q Wer führt wann welche Anfragen aus?
Modellelemente: – SysML: Sequenzdiagramm, Lebenslinie,
Nachricht, kombiniertes Fragment
(7.2) Systemschnittstellen ableiten
Ein- und ausgehende Daten: – Systemkontext (Interaktionspunkte) – Interaktionsmodell (System/Akteur) – Systemkontext (Schnittstellen)
Verantwortliche Rolle: – Systemarchitekt
Beteiligte Rollen: – Keine
(7.2) Systemschnittstellen ableiten
Motivation / Beschreibung: – Warum? Die Schnittstellenspezifikation ist notwendig
um das System in seiner Umgebung integrieren zu können.
– Was? Beschreibung der Schnittstellen zwischen System und Akteuren bezogen auf die einzelnen Interaktionspunkte.
– Wie? Ableitung der Schnittstellen aus den System/Akteur-Interaktionspunkten und Modellierung mittels Ports.
– Wohin? Die Systemschnittstellen repräsentieren die “Verträge”, die das System mit seinen Akteuren abschließt, um das System dauerhaft und erfolgreich in seinen Kontext zu integrieren.
(7.2) Systemschnittstellen ableiten
Leitfragen: q Welche Dienstleistungen werden über die
Interaktionspunkte angeboten? q Welche Dienstleistungen werden eingefordert? q Welche Objekte fließen durch die
Interaktionspunkte? Modellelemente:
– SysML: Blockdefinitionsdiagramm, Port, Schnittstelle
– SYSMOD: Benutzerschnittstelle, Dokumentenbaustein
(7.3) Systemstrukturen modellieren
Ein- und ausgehende Daten: – Systemkontext (Schnittstellen) – Anwendungsfälle – Logische Architektur
Verantwortliche Rolle: – Systemarchitekt
Beteiligte Rollen: – Keine
(7.3) Systemstrukturen modellieren
Motivation / Beschreibung: – Warum? Die Systemstrukturen sind die
statischen Bausteine der logischen Architektur. – Was? Modellierung der Systembausteine und
ihrer Beziehungen in ausreichender Detailtiefe, die für das Gesamtsystem notwendig ist, um die Projektanforderungen zu erfüllen.
– Wie? Je Anwendungsfall oder Anforderung werden notwendige Bausteine und Strukturen ermittelt und mittels Blockdiagrammen modelliert.
– Wohin? Die Bausteine der logischen Architektur beschreiben generische Konzepte und Prinzipien und können wiederverwendet werden.
(7.3) Systemstrukturen modellieren
Leitfragen: q Welche Bausteine werden zur Umsetzung der
Anwendungsfälle/Anforderungen benötigt? q Wie ist ein Baustein aufgebaut? q Wie sind die Bausteine miteinander verbunden? q Welche Interaktionspunkte und Schnittstellen haben
die Bausteine? Modellelemente:
– SysML: Blockdefinitionsdiagramm, internes Blockdefinitionsdiagramm, Systembaustein, Schnittstelle, Assoziation, Konnektor, Port, Objektfluss
– SYSMOD: disziplinenspezifische Elemente
(7.4) Zustandsmodell erstellen
Ein- und ausgehende Daten: – Logische Architektur – Anwendungsfälle – Logische Architektur (Zustandsautomaten)
Verantwortliche Rolle: – Systemarchitekt
Beteiligte Rollen: – Keine
(7.4) Zustandsmodell erstellen
Motivation / Beschreibung: – Warum? Das Systemverhalten wird durch die
Zustände der Systembausteine beschrieben. – Was? Modellierung der Zustandsautomaten für
alle relevanten Systembausteine. – Wie? Beschreibung der Zustandsautomaten
durch Zustandsdiagramme. Ausgangsbasis sind Interaktionen zwischen Systembausteinen und Anwendungsfallabläufen.
– Wohin? Zustandsautomaten können leicht zur Ausführung gebracht und zur Simulation des Systems benutzt werden.
(7.4) Zustandsmodell erstellen
Leitfragen: q Sind alle Pfade der Systemabläufe in den
Zustandsautomaten berücksichtigt? q Sind unterschiedliche Aspekte in getrennten
Regionen modelliert? Modellelemente:
– SysML: Zustandsdiagramm, Zustandsautomat, Zustand, Transition, Pseudozustände
(7.5) Physische Produktarchitektur modellieren
Ein- und ausgehende Daten: – Logische Architektur – Physische Produktarchitektur
Verantwortliche Rolle: – Systemarchitekt
Beteiligte Rollen: – Keine
(7.5) Physische Produktarchitektur modellieren
Motivation / Beschreibung: – Warum? Die physische Produktarchitektur
spezifiziert die spezifischen Produktdetails, die in der logischen Architektur nicht enthalten sind.
– Was? Modellierung von Systembausteinen, deren Beziehungen und deren Verhalten auf der Ebene ganz konkreter Bauteile.
– Wie? Die Modellierung erfolgt auf konkreter Ebene ähnlich wie bei der logischen Architektur.
– Wohin? Die physische Produktarchitektur wird für die detaillierte, konkrete und interdisziplinäre Produktentwicklung eingesetzt.
(7.5) Physische Produktarchitektur modellieren
Leitfragen: q Welchen Mehrwert hat der hohe Detailierungsgrad
der physischen Produktarchitektur gegenüber der logischen Architektur? Rechtfertigt der Mehrwert den Aufwand?
q Benötigen Sie eine lose oder enge Kopplung der physischen Produktarchitektur an die logische Architektur?
Modellelemente: – SysML: Blockdefinitionsdiagramm, internes
Blockdiagramm, Systembaustein, Schnittstelle, Assoziation, Konnektor, Port, Objektfluss
– SYSMOD: disziplinenspezifische Elemente
Zusammenfassung Prozess zur Modellierung von Systemen
Abstrakte Systembeschreibungen
Abgleich mit Stakeholdern
Anforderungs- und Anwendungsfallfokusiert