systems engineering and project management ... · qwas kann das system für den einzelnen akteur...

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