Abgrenzbares Problemfeld Einsatzbereich für Computersysteme oder Software.

Spezielle Anforderungen an ein technisches System je nach Fachgebiet.

Abstrakte Repräsentation

Zeigt Struktur und Verhalten des zu entwickelnden Softwaresystems

"Realitätsausschnitt" einer Problem-Domäne.

Überblick, Kommunikation im Team (Modellierungssprachen).

Abstraktionsprinzip: Information Hiding und Vererbung.

Vorteile:

Nachteil:

Diagramme stellen einen unvollständigen Teil der des Software-System-Modells dar

Modell kann viele Diagramme haben.

Elemente in unterschiedlichen Diagrammen können sich auf ein und dasselbe Modellelement beziehen.

Jede Phase im Entwicklungsprozess erfordert eine andere Abstraktionsebene in den Modellen

1. Übersichts-Diagramme

   Übersicht

   Kommunikation mit Menschen außerhalb des Projekts

2. Technische Diagramme

   Kommunikation mit Entwicklern

statische Zusammenhänge → statische Modelle ("immer")

• Klassendiagramm (class diagrams)

• Komponentendiagramme (component diagrams)

• Kompositionsstrukturdiagramme (composite structure diagrams)

• Objektdiagramme (object diagrams)

• Verteilungsdiagramme (deployment diagrams)

• Paketdiagramme (package diagrams)

dynamische Zusammenhänge → dynamische Modelle ("wenn-dann")

• Aktivitätsdiagramme (activity diagrams)

• Anwendungsfalldiagramme (use-case diagrams)

• Zustandsautomaten (state diagrams)

Interaktionsdiagramme

• access

  Zugriff, aber wird nicht importiert, vollständiger Paketname bei Aufrug

• import

  Zugriff, Namespace importiert

• merge

  Wird importiert aber es gibt namen die gleich sind, deshalb vollständigen Namen benutzen

> technischen Artefakte (Komponenten) in Pakete bzw. Schichten.

> Abhängigkeiten der Schichten zueinander mit Dependency-Pfeilen

Ovale, Name ist ein Verb

System / Subsystem mit Anwendungsfällen

Interagiert mit Subjekt mit Assoziationen .

Können von anderen Akteuren Erben.

include - Anwendung auf die der Pfeil zeigt wird immer ausgeführt (wie Methodenaufruf innerhalb einer anderen Methode)

extend - (Pfeil wird umgekehrt gezeichnet!) Anwendung auf die der Pfeil zeigt ist die erbende Anwendung die quasi mit dem Pfeil Zugriff auf die Funktionen des Vererbers bekommt.

Linie durch die Mitte der Anwendung die erbt.

1. Enterprise goals

   Anforderungen an Unternehmen (zB Datenexport nach xy)

2. User goals

   Aus der Domäne herausgeholt → Anforderungen an Software

3. System goals

   Anwendungsfälle, die vom Akteur „System“ bzw. „Administrator“ durchgeführt werden

in Stereotypen << ... >> steht die Art der Klasse.

Public     + Sichtbar für jedes Element das die Klasse sieht
Protected  # Sichtbar für Elemente der Klasse und ihrer Subklassen
Private    - Sichtbar für Elemente der Klasse
Package    ˜ Sichtbar für Elemente im selben Paket wie die Klasse

sichtbarkeit attributName : Typ [ multiplizität ] = defaultWert { eigenschaften }

konkret

-foo : int = 0 { not null }

sichtbarkeit methodenName ( parameterName : Typ ) : rückgabeTyp { eigenschaften }

konkret

+setFoo( foo : int ) : void { reentrant }

Kann auch eine eigene Assoziationsklasse sein

Immer eine 1..* Beziehung

Sollte das Ganze gelöscht werden, müssen Bestandteile auch gelöscht werden

Kann Teil von mehreren Dingen sein und nach einem Löschvorgang weiterexistieren

Rechteck mit Komponenten-Symbol rechts oben.

Atomar

Kann den Zustand des Systems ändern oder Nachrichten verschicken.

Zoomt man in eine Aktivität hinein, findet man ein anderes Aktivitätsdiagramm, das einen detaillierteren Kontrollfluss der jeweiligen Aktivität beschreibt.

Interaktion zwischen mehreren Classifiern (Klassen, Anwendungsfällen oder Akteuren) oder Instanzen.

Zeigen Lebensdauer eines Objektes

Rechtecke auf der Lebenslinie

Zeigen aktives Ausführen einer Nachricht

• synchrone Nachrichten

  Sender wartet auf Antwort

• asynchrone Nachrichten

• Antworten

Bestimmte Logik für Nachrichten

alt : Fragment für if-else-then

opt : switch, nur ausgeführt wenn Bedingung wahr

loop : schleife, so lange ausgeführt wie Bedingung wahr

ref : Referenz zu einem anderen Sequenzdiagramm

• Einfacher Zustand

  Zustände ohne Subzustände, zb Endzustand

• Pseudo Zustand / Transienter Zustand

  Zustand in denen System nicht bleibt, zb Initialzustand, Verzweigungen

• Komplexer Zustand

  Enthalten Subzustände

Zustände können Aktivitäten auslösen.

Aktivität             Ausführung innerhalb eines Zustands
-----------------------------------------------------------------------------
entry / aktivität     beim Eingang in den Zustand ausgeführt.
exit / aktivität      beim Verlassen des Zustands ausgeführt.
do / aktivität        wird ausgeführt, Parameter sind erlaubt.
event / aktivität     behandelt Ereignis innerhalb des Zustands.

Erfolgt wenn Bedingung / guard erfüllt ist.

• UND-Verfeinerung → nebenläufige subzustände

• ODER-Verfeinerung → getrennte subzustände

Extended Entity Relationship Model (EER-Model)

Entity Relationship Diagram (ERD)

Dritte Normalform 3NF

Typen (VARCHAR, INTEGER, BOOL, FLOAT etc.)