Seminar Modelio – Intensivseminar UML, Analyse, Design und Softwarearchitektur

Beschreibung

Der Intensivpfad führt von Modelio-Bedienung und fachlicher Analyse über Use Cases, Domänen- und Klassenmodelle bis zu Verhalten, Komponenten, Schnittstellen, internen Strukturen und Deployment. Ein gemeinsames Softwaresystem wird in konsistenten fachlichen, logischen, dynamischen und physischen Sichten entwickelt.

Formatbegründung: Fünf Tage sind erforderlich, um UML-Grundlagen, Analyse, Entwurf, Verhaltensmodellierung und Softwarearchitektur vollständig praktisch zu verbinden und mit Audit sowie Architekturreview abzusichern.

Zielgruppe

Softwareanalysten, Entwickler, Softwarearchitekten, technische Lead-Entwickler und Projektteams mit End-to-End-Modellierungsbedarf.

Voraussetzungen

Allgemeine Softwareentwicklungskenntnisse. Spezifische UML- oder Modelio-Vorkenntnisse sind nicht zwingend erforderlich, ein sicherer Umgang mit objektorientierten Konzepten ist hilfreich.

Inhaltsübersicht

1. Arbeitsbereich, Perspektiven und Navigation
2. Projektanlage und Basiskonfiguration
3. Systemkontext, Stakeholder und Akteure
4. Use Cases und fachliche Leistungen
5. Fachliches Domänenmodell
6. Klassenmodell und objektorientierter Entwurf
7. Aktivitätsdiagramme und Ablauflogik
8. Sequenzdiagramme und Interaktionsentwurf
9. Zustandsautomaten und Lebenszyklen
10. Kommunikations- und alternative Interaktionssichten
11. Komponenten, Schnittstellen und Verantwortungsgrenzen
12. Interne Strukturen, Ports und Konnektoren
13. Deployment, Knoten und Laufzeitzuordnung
14. Architektursichten und Entscheidungsnachweise
15. Abhängigkeiten, Kopplung und Wiederverwendung
16. Layout, Stil und Leseführung
17. Audit ausführen und Befunde bewerten
18. Modellreview und Freigabeverfahren

Seminarinhalte

1. Arbeitsbereich, Perspektiven und Navigation

Der Einstieg legt eine reproduzierbare Arbeitsweise für Projekte, Modelle, Diagramme und Eigenschaften fest.

1. Arbeitsbereich öffnen und die Projektansicht, Modellansicht, Diagrammansicht sowie Eigenschaftsansicht einordnen.
2. Ein Übungsprojekt anlegen und zwischen Modellbaum, Diagramm und Elementdetails wechseln.
3. Suchen, Filtern, Umbenennen und Verschieben von Modellelementen mit kontrollierter Auswahl durchführen.
4. Perspektive und Fensteranordnung speichern und anhand einer Readiness-Checkliste prüfen.

2. Projektanlage und Basiskonfiguration

Eine belastbare Projektbasis verhindert spätere Struktur-, Modul- und Austauschprobleme.

1. Projektziel, Modellumfang, Namensschema und Verantwortungsbereiche festlegen.
2. Projekt anlegen, benötigte Module aktivieren und Grundeinstellungen dokumentieren.
3. Startpakete, Diagrammordner und gemeinsame Modellelemente nach dem vereinbarten Strukturplan erzeugen.
4. Projekt öffnen, schließen, erneut laden und die Konfiguration auf einem zweiten Arbeitsplatz kontrollieren.

3. Systemkontext, Stakeholder und Akteure

Der fachliche Analyseumfang wird vor der detaillierten Modellierung eindeutig abgegrenzt.

1. Systemgrenze, Nachbarsysteme, Stakeholder und externe Auslöser ermitteln.
2. Akteure nach Rolle statt nach konkreter Person benennen und generalisieren.
3. Ziele der Akteure mit dem Systemkontext abgleichen.
4. Kontextdiagramm im Review auf fehlende Schnittstellen und unklare Verantwortungsgrenzen prüfen.

4. Use Cases und fachliche Leistungen

Use Cases beschreiben beobachtbare Leistungen des Systems aus Sicht externer Akteure.

1. Use Cases aus Akteurszielen ableiten und mit eindeutiger Verbform benennen.
2. Beziehungen, Einbeziehung, Erweiterung und Generalisierung zurückhaltend einsetzen.
3. Hauptablauf, Alternativen, Vorbedingungen, Nachbedingungen und fachliche Regeln ausarbeiten.
4. Use-Case-Modell gegen Anforderungen und Systemgrenze validieren.

5. Fachliches Domänenmodell

Fachbegriffe und Beziehungen werden als gemeinsames Analysemodell strukturiert.

1. Kandidaten aus Use Cases, Glossar und Prozessen sammeln.
2. Klassen, Attribute, Assoziationen, Multiplizitäten und Generalisierungen modellieren.
3. Technische Implementierungsdetails aus dem fachlichen Modell entfernen.
4. Modell mit Beispieldaten und fachlichen Szenarien auf Konsistenz prüfen.

6. Klassenmodell und objektorientierter Entwurf

Das fachliche Modell wird zu einem implementierbaren Entwurf mit klaren Verantwortlichkeiten weiterentwickelt.

1. Analyseklassen in Entitäts-, Steuerungs- und Schnittstellenverantwortlichkeiten überführen.
2. Operationen, Sichtbarkeiten, Datentypen und Navigierbarkeit ergänzen.
3. Kopplung, Kohäsion, Vererbung und Komposition anhand konkreter Entwurfsentscheidungen prüfen.
4. Klassenmodell mit Sequenzdiagrammen und Architekturgrenzen abgleichen.

7. Aktivitätsdiagramme und Ablauflogik

Aktivitätsdiagramme strukturieren fachliche oder technische Abläufe mit Entscheidungen und Parallelität.

1. Start, Ende, Aktionen, Verantwortungsbereiche und Objektflüsse festlegen.
2. Entscheidungen, Guards, Zusammenführungen, Forks und Joins korrekt einsetzen.
3. Fehler-, Abbruch- und Ausnahmewege ergänzen.
4. Ablauf mit Beispielpfaden durchspielen und gegen Anforderungen oder Prozessmodell abgleichen.

8. Sequenzdiagramme und Interaktionsentwurf

Zeitliche Zusammenarbeit zwischen Akteuren, Komponenten und Objekten wird nachvollziehbar dargestellt.

1. Szenario, beteiligte Lebenslinien und relevante Schnittstellen auswählen.
2. Nachrichten, Rückgaben, Erzeugung, Zerstörung und Aktivierungen modellieren.
3. Alternativen, Schleifen, optionale Abläufe und Fehlerpfade mit kombinierten Fragmenten darstellen.
4. Interaktion gegen Use Case, Operationen und Zustandsbedingungen prüfen.

9. Zustandsautomaten und Lebenszyklen

Zustandsmodelle beschreiben zulässige Lebenszyklen reaktiver Objekte oder Komponenten.

1. Modelliertes Objekt, Ereignisse und fachlich relevante Zustände identifizieren.
2. Transitionen mit Triggern, Guards und Aktionen ausarbeiten.
3. Hierarchische Zustände, Eintritts- und Austrittsverhalten gezielt einsetzen.
4. Erreichbarkeit, Vollständigkeit und Widerspruchsfreiheit anhand von Szenarien prüfen.

10. Kommunikations- und alternative Interaktionssichten

Zusätzliche Interaktionssichten verdeutlichen Struktur, Nachrichtennetz und zeitliche Randbedingungen.

1. Geeignete Sicht für Strukturbetonung, Ablaufübersicht oder zeitkritisches Verhalten auswählen.
2. Objekte und Nachrichten konsistent zu bestehenden Sequenzdiagrammen übernehmen.
3. Nummerierung, Bedingungen und Verantwortlichkeiten nachvollziehbar modellieren.
4. Abweichungen zwischen Interaktionssichten identifizieren und bereinigen.

11. Komponenten, Schnittstellen und Verantwortungsgrenzen

Die logische Architektur wird über klar abgegrenzte Komponenten und explizite Verträge strukturiert.

1. Architekturtreiber, Qualitätsziele und fachliche Zerlegung sammeln.
2. Komponenten mit Verantwortlichkeiten, bereitgestellten und benötigten Schnittstellen modellieren.
3. Abhängigkeiten und zulässige Kommunikationsrichtungen festlegen.
4. Komponentenschnitt anhand ausgewählter Use Cases und Änderungsfälle bewerten.

12. Interne Strukturen, Ports und Konnektoren

Komponenten werden bis zu relevanten internen Rollen und Kommunikationspunkten verfeinert.

1. Komponente auswählen und interne Parts sowie Ports bestimmen.
2. Schnittstellen an Ports zuordnen und Konnektoren modellieren.
3. Delegation und Assembly-Verbindungen gegen die äußeren Verträge prüfen.
4. Interne Struktur mit Sequenzdiagramm oder Deployment-Sicht konsistent halten.

13. Deployment, Knoten und Laufzeitzuordnung

Die physische Sicht ordnet Softwareartefakte, Laufzeitumgebungen und Kommunikationswege zu.

1. Zielumgebungen, Knoten, Geräte, Ausführungsumgebungen und Netzzonen erfassen.
2. Komponenten und Artefakte den Laufzeitknoten zuordnen.
3. Verbindungen, Protokolle, Redundanz und Sicherheitsgrenzen darstellen.
4. Deployment gegen Betriebsanforderungen, Verfügbarkeit und Skalierungsszenarien prüfen.

14. Architektursichten und Entscheidungsnachweise

Mehrere konsistente Sichten verbinden fachliche, logische, Laufzeit- und physische Architektur.

1. Stakeholderfragen und benötigte Architektursichten festlegen.
2. Gemeinsame Elemente über Komponenten-, Interaktions- und Deploymentdiagramme hinweg verwenden.
3. Architekturentscheidungen, Annahmen, Risiken und Alternativen am Modell dokumentieren.
4. Sichten in einem Architekturreview auf Widersprüche und unbelegte Entscheidungen prüfen.

15. Abhängigkeiten, Kopplung und Wiederverwendung

Modellabhängigkeiten werden sichtbar gemacht und so gesteuert, dass Änderungen beherrschbar bleiben.

1. Zulässige Abhängigkeitsrichtungen zwischen Schichten, Paketen und Komponenten definieren.
2. Abhängigkeiten, Nutzung und Realisierung im Modell explizit abbilden.
3. Unbeabsichtigte Rückkopplungen und Mehrfachdefinitionen mit Suchen und Auditregeln aufdecken.
4. Eine Abhängigkeitsmatrix erzeugen und Maßnahmen für Entkopplung oder gemeinsame Bibliotheken dokumentieren.

16. Layout, Stil und Leseführung

Eine konsistente grafische Sprache verbessert Verständlichkeit und reduziert Interpretationsfehler.

1. Raster, Ausrichtung, Größen, Linienführung und Beschriftung vereinheitlichen.
2. Farben und Symbole sparsam nach Bedeutung statt nach persönlicher Vorliebe einsetzen.
3. Komplexe Inhalte durch Teilansichten, Ebenen und Fokusdiagramme reduzieren.
4. Lesbarkeit in Präsentations-, Druck- und Bildschirmgröße mit einer Review-Checkliste prüfen.

17. Audit ausführen und Befunde bewerten

Die integrierte Modellprüfung wird als wiederholbarer Qualitätsprozess eingesetzt.

1. Auditumfang, Regelmenge und betroffene Modellbereiche festlegen.
2. Audit ausführen und Befunde nach Schweregrad, Ursache und Verantwortlichkeit klassifizieren.
3. Repräsentative Fehler direkt am Modellelement nachvollziehen und kontrolliert korrigieren.
4. Audit erneut ausführen und Restbefunde mit Begründung dokumentieren.

18. Modellreview und Freigabeverfahren

Automatische Prüfungen werden durch strukturierte fachliche und technische Reviews ergänzt.

1. Reviewziel, Umfang, Rollen, Eingangsbedingungen und Abnahmekriterien festlegen.
2. Diagramme, Elemente, Beziehungen, Anforderungen und Dokumentausgaben systematisch prüfen.
3. Befunde mit Priorität, Verantwortlichkeit und Termin erfassen.
4. Nachprüfung durchführen und Freigabe oder begründete Restabweichung dokumentieren.

Praxisübungen

• Projektanlage und fachliche Analyse eines Beispielsystems.
• Klassen- und Verhaltensentwurf für Haupt- und Fehlerabläufe.
• Komponenten-, Schnittstellen- und Deploymentarchitektur.
• End-to-End-Konsistenzprüfung und Architekturfreigabe.

Qualitätskriterien

• Modellelemente werden im Modellbaum eindeutig strukturiert und in Diagrammen wiederverwendet statt dupliziert.
• Beziehungen, Status, Benennung und Verantwortlichkeiten sind nachvollziehbar und entsprechen dem vereinbarten Modellierungsrahmen.
• Audit- und Reviewbefunde werden priorisiert, korrigiert und in einer erneuten Prüfung verifiziert.
• Übungsergebnisse lassen sich nach Schließen und erneutem Öffnen des Projekts reproduzierbar nachvollziehen.
• Der durchgängige Fall verbindet alle Teilgebiete in einem freigegebenen, dokumentierten Gesamtmodell.