Software Engeineering

1. Organisatorisches und Motivation

Software Engineering ist die Entdeckung und Anwendung solider Ingenieur-Prinzipien mit dem Ziel, auf wirtschaftliche Art Software zu bekommen, die zuverlässig ist und auf realen Rechnern läuft, verhindert Schäden, senkt die Gesamtkosten und hält Fortschritte fest. Es sind Methoden, Sprachen und Werkzeuge durch Konzepte miteinander verbunden. Reine Programmierfehler, wie ein falsches Zeichen kann eine Katastrophe auslösen, wie zum Beispiel die Mariner-1-Rakete.  Je früher ein Fehler in der Entwicklung entdeckt wird, desto günstiger ist dessen Beseitigung.

1. Organisatorisches und Motivation

Software

Software beschreibt sämtliche nicht physische Bestandteile eines Computers, Computernetzwerks oder mobilen Geräts. Gemeint sind Programme und Anwendungen (Betriebssystem), die den Computer für den Nutzer funktionstüchtig machen.

1. Organisatorisches und Motivation

Software Engineering

Ist die Herstellung und Anwendung einer Software, wobei mehrere Personen beteiligt sind oder Versionen entstehen.

  1. Werkzeuge zur automatischen oder vom Benutzer gesteuerten Transformation und Speicherung von Information.
  2. es werden Programmier- und Modellierungssprachen genutzt, um die Syntax festzulegen
  3. Methoden werden genutzt, um die Software herzustellen
  4. mit diesen drei Dinge entstehen Konzepte

Was macht man im Software Engineering?

SE als defensive Disziplin: Sie verhindert Schäden und sollte generell beachtet werden.
SE als globale Optimierungsmaßnahme:  Separate Einsparungen an einzelnen SE-Aktivitäten
SE als Technologie für die Köpfe: Wissenschaftliche Erkenntnis und neue Technologie lassen sich gut in die Anwendung transferieren, wenn sie sich in Produkten niederschlagen

image-1662213138595.pngimage-1662213447546.png

 

image-1662213332950.png

image-1671544186981.png

 

image-1662213356374.png

 

 

 

 

 

 

2. Softwareentwurfsprozesse und Clean Code Development

2. Softwareentwurfsprozesse und Clean Code Development

Clean Code

Clean Code – Quellcode, Dokumente, Konzepte, Regeln und Verfahren, die intuitiv verständlich, stabil und effizient sind. 

Maßnahmen:

 

2. Softwareentwurfsprozesse und Clean Code Development

Software Entwicklungsprozesse

Prinzipien des Software Engineering

Dadurch soll eine bessere Wartbarkeit und eine einfachere Angepasstheit erreicht werden

1. Abstraktion

Identifizierung und Trennung wichtiger und (zunächst) weniger wichtige Aspekte.

2. Modularisierung 

beschreibt das Strukturieren eines Produkts oder Systems in Form von austauschbaren Funktionsbausteinen.

3. Kapselung 

Verbergen und Schützen von (inneren) Details der Implementierung eines Moduls

Nachteil: Erschwert ggf. die Testbarkeit von Modulen und die Fehlersuche

4. Hierarchische Zerlegung 

Zerlegung eines Problems in Teilprobleme, so dass sich eine Baumstruktur ergibt.

Funktioniert durch: Abstraktion, Modularisierung und Trennung von Zuständigkeiten. 

5. Trennung von Zuständigkeiten

Aufteilung eines Problems in unabhängige Teilaufgaben zur Reduzierung der Gesamtkomplexität

Unter anderem wird dafür das Architekturmuster MVC genutzt 

6. Einheitlichkeit

Vereinheitlichung von Strukturen, Schemata, Muster, Vorgehensweisen und Entwurfsentscheidungen

Agile Softwareentwicklung

Scrum

Ein agiler Prozess für Softwareentwicklung und Projektmanagement

3. Allgemeine Softwareentwicklungsprozesse

Anforderungsanalyse

Anforderungsanalyse

Der Modellbegriff

Modelle sind Abbilder von etwas oder Vorbilder für etwas.

Modellarten

Petri-Netz                                                                                                                                           UML-Klassendiagramm

image-1662406662562.pngimage-1662406708098.png

Anforderungsanalyse

Bilder

Modellbegriff

image-1662405741724.png

Scrum 

image-1662448976751.png

Wasserfallmodell

image-1662407310792.png

 

Anforderungsanalyse

Anforderungen an Software

Aus Sicht des Kunden:

image-1662553504589.png

Aus der Sicht der Entwickler:
Verschiedene Phasenmodelle in der Entwicklung von Software beinhalten Erhebung und Analyse von Anforderungen
-> Wasserfall, iteratives Modell, evolutionäres Modell, agile Entwicklung, Scrum, etc.

Sowohl für Scrum als auch für das Wasserfallmodell sind Lastenheft und Pflichtenheft besonders wichtig

Das Lastenheft sind die Anforderungen, die der Auftraggeber einem potenziellen Auftragnehmer zur Last legen möchte.

Das Pflichtenheft sind Anforderungen, zu deren Umsetzung sich Auftragnehmer gegenüber Auftraggeber verpflichtet.

Anforderungsanalyse

Anforderungsspezifikation

Anforderung – Eine Bedingung oder Fähigkeit, die Benutzer benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen.

Anforderungsanalyse - Prozess der Untersuchung muss System-, Hardware- oder Softwareanforderungen gelangen.

Anforderungsspezifikation dokumentiert die Anforderungen an Software und ihre Schnittstellen präzise und vollständig 

Anforderungen werden durch Befragungen, Überprüfungen und Hospitationen erkannt

Anforderungsanalyse

Nichtfunktionale Anforderungen

Anforderungen, die Merkmale des Systems ohne Bezug zum Funktionsumfang beschreiben (Zuverlässigkeit, Leistung, ...)

image-1662481031696.png

Funktionale Eignung

 

Funktionale Eignung

Grad, in Produkt Funktionen bietet, die angegebenen und impliziten Bedürfnissen entsprechen

Funktionale Vollständigkeit

Grad, zu dem Satz von Funktionen alle angegebenen Aufgaben und Benutzerziele abdeckt.

Funktionale Korrektheit

Grad, zu dem Produkt die richtigen Ergebnisse mit dem erforderlichen Grad an Präzision liefert.

Funktionale Angemessenheit

Grad, zu dem die Funktionen die Erledigung bestimmter Aufgaben und Ziele erleichtern

Leistungsfähigkeit

 

Leistungseffizienz

Leistung im Verhältnis zur Menge der Ressourcen unter bestimmten Bedingungen. 

Zeitverhalten

Ausmaß, in dem die Verarbeitungszeiten eines Produkts entsprechen.

Ressourcennutzung

Grad, in dem Ressourcen, die ein Produkt verwendet werden, den Anforderungen entsprechen.

Kapazität 

Grad, zu dem die Grenzen eines Produkt- oder Systemparameters die Anforderungen erfüllen.

Kompatibilität

 

Kompatibilität

Grad, in dem ein Produkt Informationen mit anderen Produkten austauschen kann

Koexistenz

Grad, zu dem ein Produkt seine Funktionen ausführen kann ohne Auswirkungen auf ein anderes

Interoperabilität 

Grad, in dem mehr Produkte Informationen austauschen und nutzen können

Benutzerfreundlichkeit

 

Benutzerfreundlichkeit

Grad, in dem ein Produkt von Benutzern verwendet werden kann

Angemessenheit

Grad, in dem die Benutzer erkennen können, ob ein Produkt für ihre Bedürfnisse geeignet ist.

Erlernbarkeit

Grad, in dem ein Produkt mit Effektivität und Zufriedenheit in einer Nutzung.

Bedienbarkeit

Grad, zu dem ein Produkt Eigenschaften aufweist, die es einfach zu bedienen machen

Schutz vor Benutzerfehlern 

Ausmaß, in dem ein System die Benutzer vor Fehlern schützt.

Ästhetik der Oberfläche

Grad, zu dem eine Benutzeroberfläche eine angenehme Interaktion für Benutzer ermöglicht.

Zugänglichkeit 

Ausmaß, in dem Produkt von Menschen mit unterschiedlichsten Eigenschaften genutzt wird

Verlässlichkeit

 

Zuverlässigkeit 

Grad, in dem ein System bestimmte Funktionen Bedingungen über bestimmten Zeitraum erfüllt.

Reifegrad 

Grad, in dem System die Anforderungen an Zuverlässigkeit im Normalbetrieb erfüllt.

Verfügbarkeit 

Grad, in dem ein System betriebsbereit ist, wenn es für die Nutzung benötigt wird.

Fehlertoleranz 

Grad, zu dem ein System wie vorgesehen funktioniert trotz Vorhandenseins Fehlern erhöht.

Wiederherstellbarkeit 

Grad, in dem ein Produkt oder System im Falle einer Unterbrechung  wiederherstellen kann.

Sicherheit

 

Sicherheit

Grad, in dem ein Produkt so schützt, dass Personen keinen Datenzugriff erhalten.

Vertraulichkeit

Grad, zu dem ein Produkt sicherstellt, dass Daten nur denjenigen wahren zugänglich sind

Integrität

Grad, zu dem ein System den unbefugten Zugriff verhindert.

Unverfälschbarkeit

Grad, in dem Aktionen nachweislich stattgefunden haben 

Rechenschaftspflicht 

Grad, in dem Handlungen einer Einheit auf diese Einheit zurückgeführt werden können.

Authentizität 

Grad, in dem die Identität eines Subjekts oder einer Ressource diejenige ist, die behauptet wird.

Wartungsfähigkeit

 

Wartungsfähigkeit

Grad der Effektivität, mit der ein Produkt geändert werden kann, um es zu verbessern

Modularität

Grad, in dem ein System aus einzelnen Komponenten besteht

Wiederverwendbarkeit

Grad, zu dem ein Asset in mehr als einem System verwendet werden kann

Analysierbarkeit

Grad der Effektivität, mit dem es möglich ist, die Auswirkungen einer Änderung zu identifizieren

Modifizierbarkeit

Ausmaß, in dem ein Produkt effektiv modifiziert werden kann, ohne Fehler einzuführen 

Testbarkeit

Grad der Effektivität, mit dem Testkriterien für ein System für ein System festgelegt 

Portabilität

 

Portabilität

Grad der Effektivität, mit der System einer Nutzungsumgebung in andere übertragen wird

Anpassungsfähigkeit

Grad, in dem ein Produkt effektiv an unterschiedliche Nutzungsumgebungen angepasst wird

Installierbarkeit

Grad der Effektivität, mit der Produkt in Umgebung erfolgreich installiert werden kann.

Ersetzbarkeit 

Grad, in dem ein Produkt ein Software in der gleichen Umgebung ersetzen kann.

image-1662491852757.png

Bewertung:
Wichtigkeit: erster Parameter, vom Auftraggeber
Risiko in der Umsetzung: zweiter Parameter, Auftragnehmer
Skala: hoch (H), mittel (M), gering (L)

image-1662534282143.png

 

Anforderungsanalyse

Funktionale Anforderungen

User story (Anwendererzählung) – Eine in Alltagssprache formulierte Software-Anforderung.

Mustervorlage: “Als ... möchte ich <Ziel/Wunsch>, um ....”

image-1662492231601.png

Der Anwendungsfall Authentifizieren repräsentiert eine vom System zu realisierende Funktion Funktionale Anforderung
Die Dokumentation des Anwendungsfalls mit der dargestellten Tabellenschemas repräsentiert die Spezifikation der Anforderung

Aktivitätsdiagramm                                                                                         Sonderfälle

image-1662492318163.png

image-1662492361035.png

 

 

 

 

 

 

KISS-Prinzip (Keep it simple [and] stupid)

 

 

 

image-1662539540508.png

image-1662539295579.png

 

image-1662539837779.png

 

 

extends immer bei seperaten use case vorgängen 

 

 

 

 

Unified Modeling Language (UML)

Unified Modeling Language (UML)

Unified Modeling Language

Bestandteile:

Modell: Festlegung gültiger Begriffe und der Beziehungen zwischen diesen Begriffen
Notation: Graphische Sicht auf Ausschnitte dieser Modelle
Austausch: Vorschalg von Formaten für die Werkezugunterstützung

Eigentlicher Nutzen: Gemeinsame Arbeit an nicht-trivialen Softwareprojekten: Übersicht und Kommunikation

image-1663744846604.png

Unified Modeling Language (UML)

UML Anwendungsfalldiagramme

Jeder Player nimmt an genau einem Spiel teil.
Jedes Spiel wird von mindestens zwei Playern gespieltDiagrammtyp der UML zur Beschreibung der Interaktion von Akteuren mit einem betrachteten Systemen.

image-1664091438196.png

Zweck von Anwendungsfalldiagrammen

1. Dienen der abstrakten Beschreibung der Leistung sowie der Umgebung eines Systems
2. Strukturieren Anforderungen an System mit Spezifikation Akteure, Anwendungsfälle und Beziehungen

Anwendungsfall (engl. use case) – Eine von einem betrachteten System bereitgestellte Funktion.

Beschreiben, was System leisten muss: Funktionalität des Systems und Interaktion eines Anwenders
Können um extension points erweitert werden und können mit eigenen Stereotypen zur Nutzung fachspezifischer Begriffe versehen werden

Vorlage für Dokumentation von Anwendungsfällen

  1. Anwendungsfall: Name
  2. Ziel: Zielsetzung des Anwendungsfalls
  3. Kategorie: primär, sekundär oder optional
  4. Vorbedingung: erwarteter Zustand, bevor Anwendungsfall beginnt
  5. Nachbedingung (Erfolg): erreichter Zustand bei erfolgreicher Ausführung des Anwendungsfalls
  6. Nachbedingung (Fehlschlag): erreichter Zustand bei fehlerhafter Ausführung des Anwendungsfalls
  7. Akteure: Personengruppen oder Systeme, die den Anwendungsfall auslösen oder daran beteiligt sind
  8. Auslösendes Ereignis: Wenn dieses Ereignis eintritt, dann wird der  Geschäftsprozess initiiert
  9. Beschreibung: vom durch den Anwendungsfall beschriebenen Geschäftsprozess auszuführende Aktionen

Akteur  – Gruppe von Personen oder Systemen, die mit einem zu betrachtenden System interagieren (Student)

Subjekt – Grenz eines zu betrachtenden Systems in Bezug auf das Sammeln und Analysieren von Anforderungen (Bank).

Assoziation – Interaktion zwischen einem Akteur und einem Anwendungsfall.

image-1664092213147.pngMultiplizität – Definition der Kardinalität (d.h. Anzahl von Elementen) durch ein inklusives Intervall nicht-negativer Ganzzahlwerte zur Spezifikation der erlaubten Anzahl von Instanzen.

image-1664187335714.png

Multiplizität Kurzform Kardinalität
0..0 0 Collection must be empty
0..1   No instances or one instance
1..1 1 Exactly one instance
0..* * Zero or more instances
1..*   At least one instance
5..5 5 Exactly 5 instances
m..n   At least but no more than instances

 

Generalisierung von Akteurenimage-1664187564638.png

Beziehung, die jede Instanz des spezifischen Akteurs indirekt als Instanz des Akteurs definiert

→ Spezielle Akteure nehmen indirekt an gleichen Anwendungsfällen teil ("Ist ein"-Beziehung)

include-Beziehungimage-1664187728360.png

Beziehung zwischen zwei Anwendungsfällen, die das Verhalten des eingeschlossenen Anwendungsfalls in das Verhalten des übergeordneten Basis-Anwendungsfalls einfügt.

→ Ausführung eines Anwendungsfalls innerhalb eines anderen Anwendungsfalls
→ Strukturierung komplexer Anwendungsfälle
→ Wiederverwendung vorhandener Funktionen und Vermeidung von Redundanz

extend-Beziehungimage-1664192944806.png

Bedingte Erweiterung eines Anwendungsfalls durch einen eigenständigen anderen.

→ erweiternde Anwendungsfall ist unabhängig vom weiteren Anwendungsfall und für sich gesehen sinnvoll
→ Erweiterungspunkt (extension point ) definiert die Erweiterung im Anwendungsfall

Generalisierungimage-1664193175840.png

Beziehung zwischen Anwendungsfällen, die jede Instanz des spezifischen Anwendungsfalls indirekt auch als Instanz des generelleren Anwendungsfalls definiert.

→ Vererbung von Verhalten und Bedeutung eines generellen Anwendungsfalls an einen speziellen
→ Speziellerer Anwendungsfall kann: Geerbtes Verhalten partiell überschreiben ODER Neues Verhalten hinzufügen

Unified Modeling Language (UML)

Vorgehen zur Modellierung

1. Akteure ermitteln:
Personen ermitteln, die die Aufgaben durchführen. Welche Rollen spielen diese Personen?
Welche externen Systeme werden durch das Produkt genutzt bzw. was gehört nicht mehr zum System?

2. Anwendungsfälle ermitteln:
Mittels Akteuren: (Personen bzw. deren Rollen): Welche Arbeitsabläufe lösen sie aus? An welchen Arbeitsabläufen wirken sie mit?
Mittels Ereignissen: Externe und zeitliche Ereignisse auflisten. Für jedes Ereignis einen Anwendungsfall identifizieren.
Mittels Aufgabenbeschreibungen: Was sind die Gesamtziele des Systems / wichtigsten Aufgaben? Ziele jeder Aufgabe ermitteln.

3. Anwendungsfälle für Sonderfälle formulieren:
Erweiterungen und Alternativen der Standard-Anwendungsfälle formulieren. -> Mittels <extend> die Sonderfälle modellieren.

4. Aufteilen komplexer Anwendungsfälle
Komplexe Schritte als eigene Use Cases modellieren, z.B. per <include> .
Komplexe Use Cases in mehrere Use Cases zerlegen und Gemeinsamkeiten mit <include> modellieren.

5. Gemeinsamkeiten von Anwendungsfällen ermitteln
Auf redundanzfreie Beschreibung achten, insbesondere bei <include> 

6. Verfeinerungen von Anwendungsfällen vornehmen (falls nötig):
UML Aktivitätsdiagramme: falls Anwendungsfall komplexes Verhalten modelliert
UML Interaktionsdiagramme (Sequenzdiagramme): falls Anwendungsfall komplexe Interaktionen mit Akteuren beinhaltet

Tipps: Verständlichkeit | Beschreibung extern wahrnehmbaren Verhaltens | Fachliche Beschreibung | Vollständige Beschreibung des Standardablaufs |Separate Beschreibung von Sonderfällen | eine Seite lang

Unified Modeling Language (UML)

Ein Beispiel - Krankenhausempfang

image-1664198036966.png

Die Rezeptionistin plant die Termine des Patienten und die Aufnahme in das Krankenhaus, sammelt Informationen vom Patienten bei der Ankunft des Patienten und/oder telefonisch.

Für den Patienten, der im Krankenhaus bleibt, sollte er oder sie ein Bett auf einer Station erhalten.

Empfangsmitarbeiter erhalten möglicherweise auch Zahlungen des Patienten, zeichnen sie in einer Datenbank auf und stellen Quittungen, Versicherungsansprüche und medizinische Berichte zur Verfügung

Unified Modeling Language (UML)

Zusammenfassung

image-1664198633475.png

UML Aktivitätsdiagramme

UML Aktivitätsdiagramme

Dynamisches Verhalten

Aktivitätsdiagramme beschreiben Ausschnitt aus Ablaufmöglichkeiten eines Systems mit Hilfe von Aktivitäten

Einsatz: Detaillierte Sicht auf Anwendungsfälle | den Ablauf innerhalb von Klassen | Geschäftsprozessmodellierung mit der UML

Aktivität – Parametrisiertes Verhalten, dargestellt als koordinierter Fluss von Aktionen

Aktivitätsknoten:image-1664209087734.png
Aktionen: abgerundete Rechtecke
Objekte: Rechtecke
Kontrollflusselemente: verschiedene Symbole für Entscheidungen, parallele Ausführung
Kontrollfluss: Verbinden von Knoten mit gerichteten Kanten

Aktion – Benanntes Element, das einen einzelnen atomaren Schritt innerhalb der Aktivität darstellt

Kann eingehende und ausgehende Aktivitätskanten enthalten, die Kontroll- und Datenfluss von und zu anderen Knoten definieren
Kann andere Aktivitäten aufrufen (call activity action)
Beginnt mit der Ausführung, wenn alle Eingabebedingungen erfüllt sind

Start- und Endzustandimage-1664209622178.png

Startknoten – Start des Kontrollflusses in einer Aktivität
Aktivitäts-Endknoten – Ende jeglicher Kontrollflüsse in einer Aktivität
Fluss-Endknoten – Ende eines einzelnen Kontrollflusses

Endzustände können mehrfach vorkommen, Startzustände ideal nur einmal

Entscheidungimage-1664209962271.png

Steuerknoten, der eingehenden Kontrollfluss akzeptiert und Kontrollfluss aus mehreren ausgehenden Kontrollflüssen auswählt

Annotation von Bedingungen in Form von booleschen Ausdrücken an Transitionen
Unterstützt auch einen vordefinierten else -Kontrollfluss
Optionaler Merge-Knoten fügt mehrere eingehende alternative Flüsse zusammen

Parallele Ausführungspfade

Fork – Steuerknoten, der einen eingehenden Kontrollfluss in mehrere nebeneinander laufende Kontrollflüsse aufteilt

Die Ausführung des Diagramms durchläuft alle parallelen Pfadeimage-1664210239165.png
Die Ausführungsreihenfolge nebenläufiger Pfade ist irrelevant: nacheinander, gleichzeitig, abwechselnd

Join – Steuerknoten, der mehrere eingehende nebenläufige Kontrollflüsse synchronisiert

UND-Synchronisation: Die Kontrollflüsse aller Transitionen müssen vorliegen, bevor die Transition starten kannimage-1664210562609.png

Probleme mit Fork und Join

Verantwortlichkeitsbereicheimage-1664210973320.png

Gruppierung von Aktionen anhand gemeinsamer Merkmale

Definieren organisatorische Verantwortlichkeiten
Können hierarchisch aufgebaut werden: Klassenzugehörigkeit, Organisationseinheiten, Akteuren

Objekte und Objektfluss

image-1664211238111.png

Objektflusskanten – Kanten, mit denen der Datenfluss zwischen Aktionsknoten angezeigt wird

Objektknoten – Knoten, mit dem Objekte definiert werden. Vorliegen eines Objektes zu Zeitpunkt innerhalb einer Aktivität

image-1664211422682.png

Pin – Objektknoten für Ein- und Ausgänge von Aktionen

image-1664211520886.png

Data Stores – Zentraler Speicherknoten für nicht-transiente Informationen

Signale senden und empfangenimage-1664259454906.png 

Sendesignalaktion – Senden eines Signals 

Annahmeereignis – Aktion, die auf das Eintreten eines bestimmten Ereignisses (z. B. Signal) wartet 

Sender- und Empfängerobjekte von Signalen müssen nicht spezifiziert werden 

Wartezeitereignisse und Unterbrechungenimage-1664259904268.png

Wartezeitaktion – Warten auf das Eintreten eines Zeitereignisses

Unterbrechbare Aktivitätsregionen – Aktionen, deren Ausführung durch Ereignisse unterbrochen werden können

UML Aktivitätsdiagramme

Modellierbeispiele

Wie erstelle ich Aktivitätsdiagramme?
1. Wer sind die wichtigen Akteure des zu beschreibenden Prozesses?
2. Welche relevanten Aktionen führen diese Akteure aus?
3. Welche temporalen bzw. kausalen Zusammenhänge bestehen zwischen den Aktionen (Sequenzen, Entscheidungen,...)?
4. Welche Objekte werden für die Ausführung der Aktionen benötigt bzw. durch eine Aktion erzeugt oder verändert?
5. Welche asynchronen Signale werden ausgetauscht und wie hängen die Ausführungspfade zwischen den Aktionen davon ab?

Modellierungsbeispiel
Es soll die Abwicklung einer Warenbestellung in einem Shopssystem modelliert werden. Die Bestellung ist der Eingabeparameter der Aktivität. Falls eine Bestellung angenommen wurde, müssen zunächst alle erforderlichen Informationen gesammelt und eingegeben werden. Danach wird der Versand der Ware veranlasst und eine Rechnung versendet. Nach Versand und Zahlungseingang wird der Vorgang abgeschlossen.

image-1664261395890.png

UML Klassendiagramme

UML Klassendiagramme

Objektorientierte Analyse

Lastenheft (Anforderungen):  Anwendungsfalldiagramme, Aktivitätendiagramme image-1664262182770.png

Pflichtenheft (Analyse): Klassendiagramme, Sequenzdiagramme, Kollaborationsdiagramme

Entwurfsphase: Paketdiagramme, Klassendiagramme, Zustandsdiagramme, Sequenzdiagramme

Implementierungsphase: Komponentendiagramme, Verteidigungsdiagramme

Die Objektorientierte Analyse - Erstellen eines ersten Modells des Systems (Analysemodell)

Das Analysemodell dient dem Entwickler als Grundlage für den Entwurf

Formalisierung der Anforderungen: Entdecken, Nachverfolgen und Beseitigen von Fehlern und Problemen, Mehrdeutigkeiten, Widersprüchen und Lücken für die Anforderungsspezifikation,...

Bestandteile des Analysemodells (Fachmodell)
Statisches Fachmodell: Systemstruktur mittels Klassendiagramm
Dynamisches Fachmodell: Systemverhalten mittels Sequenzdiagramm oder Zustandsdiagramm

Vorgehen:
1. Identifizieren der Fachobjekte, Systemgrenzen und Steuerungsobjekte, z.B. als Typen von Klassen mittels Klassendiagrammen
2. Zuordnen der Objekte zu den Anwendungsfällen (z.B. mittels Sequenzdiagrammen)
3. Identifizieren von: Beziehungen (Abhängigkeiten, Assoziationen, Vererbung) | Attribute | Methoden

UML Klassendiagramme

Objektorientierung

Darstellung von Objekten der realen Welt als Objekte in der Programmierung

Objekt hat ...
1. Eine Objektidentität, die es von anderen Objekten unterscheidet
2. Einen Kontext, d.h. ein Objekt kennt andere Objekte, zu denen es in Beziehung steht
3. Einen Objektzustand, bestimmt durch die Werte der Attribute eines Objekts und dessen Beziehungen zu anderen Objekten
4. Ein Objektverhalten, bestimmt durch eine Reihe von Methoden des Objektes

Der Zustand eines Objekts: Umfasst die Attribute und ihre aktuellen Werte und deckt die relativen Beziehungen ab
Das Verhalten eines Objekts: Wird durch Methoden definiert, Änderungen oder Abfragen nur durch Methoden möglich

Die Eigenschaft, die ein Objekt von allen anderen Objekten unterscheidet, wird als Identität bezeichnet.

drei Grundprinzipien der Objektorientierung: Datenkapselung | Vererbung | Polymorphie

UML Klassendiagramme

Klassendiagramme

Klassendiagramme modellieren die statischen strukturellen Beziehungen zwischen den Komponenten eines Systems. 

Klassendiagramme sind der Hauptbaustein der objektorientierten Modellierung. image-1664266638154.pngimage-1664266692230.pngScopes und Multiplizität

Gültigkeitsbereich (scope):
Pfadnamen können in Klassendiagrammen verwendet werden, um den Gültigkeitsbereich (scope) der Klasse zu identifizieren,
z.B. org::openoffice::SpellChecker

Multiplizität von Klassen:image-1664267537828.png
In der oberen rechten Ecke einer Klasse kann die Multiplizität (d.h. Anzahl der Instanzen) einer Klasse sein:
Keine Zahl in der oberen rechten Ecke: mehr als eine Instanz einer Klasse möglich

Klassenattribute stellen die Eigenschaften (properties) einer Klasse dar.

Sichtbarkeit von Attributen
+ öffentlich: Unbeschränkter Zugriff
# geschützt: Zugriff von Klasse sowie von Unterklassen
− privat: Nur die Klasse selbst kann das Attribut sehen
~ paketsichtbar: Innerhalb des Pakets sichtbar		 Arten von Beziehungen
Dependency: Abhängigkeit zwischen zwei Klassen
Assoziation: lies “hat ein”
Aggregation: Spezieller Typ der Assoziation, lies “besitzt ein”
Komposition: Stärkste Beziehung zwischen Klassen, lies “besteht aus”
Generalisierung: Vererbungsbeziehung, lies “ist ein”
Realisierung: Implementierung einer Schnittstelle

image-1664268206260.pngimage-1664268514308.pngNutzungsabhängigkeit – Angabe, dass ein Element ein anderes Element oder eine Menge von Elementen für seine Implementierung benötigt.

Assoziation image-1664268662459.png– Angabe, dass Typinstanzen miteinander in Verbindung stehen oder logisch bzw. physisch miteinander zu einer Aggregation kombiniert werden können. z.B: Wrote:image-1664268808416.png

 

Navigierbarkeit von Assoziationen

Beide Enden der Assoziation haben eine nicht spezifizierte Navigierbarkeit:image-1664269027332.png

A2 hat nicht spezifizierte Navigierbarkeit, während B2 von A2 aus navigierbar ist:

image-1664269289802.png

A3 ist von B3 nicht navigierbar, wenn B3 nicht spezifizierte Navigierbarkeit hat:

image-1664269323035.png

A4 ist von B4 aus nicht navigierbar, während B4 von A4  navigierbar ist:

image-1664269339696.png

A5 ist von B5 aus navigierbar und umgekehrt:

image-1664269359890.png

A6 ist von B6 aus nicht navigierbar und umgekehrt

image-1664269384882.png

Stelligkeit von Assoziationen:image-1664270111177.png

Binäre Assoziationen: verbindet genau zwei Typen bzw. Klassen.image-1664270253739.png

n-äre Assoziationen mit mehr als zwei Assoziationsenden

Multiplizität (Kardinalität) - Definition Anzahl maximal Elemente durch inklusives Intervall nichtnegativer Ganzzahlen

Multiplizität  Option  Bedeutung
0..0  0 Keine Instanzen (leere Menge)
0..1    Keine oder eine Instanz
1..1  1  Genau eine Instanz
0..*  *  Null oder mehr Instanzen
1..*    Mindestens eine Instanz
5..5  5 Genau fünf Instanzen
m..n   

Mindestens , aber nicht mehr als Instanzen

Beispiel:
image-1664279701380.pngJeder Professor kann (als author) ein oder mehrere Bücher schreiben (kann sein lassen): 0..*
Jedes Buch (als textbook) ist von mindestens einem Professor geschrieben: 1..*

image-1664279792142.png

Multiplizität
Ordnung ( ordered oder unordered )
Einzigartigkeit der Elemente ( unique oder nonunique )
Standardgemäß sind Elemente eines Intervalls unordered und unique

Aggregation - Eine binäre Assoziation, die eine Teile-Ganzes Beziehung darstellt.

Asymmetrisch: nur ein Ende der Assoziation kann eine Aggregation sein
Transitiv: Aggregationsverknüpfungen sollten gerichteten, azyklischen Graph bilden, so dass keine Instanz Teil seiner selbst ist
Unabhängig: Wenn übergeordnete Instanzen gelöscht werden, können die untergeordneten Teile-Instanzen weiterbestehen

(shared) Aggregation
image-1664280033323.pngEin Dreieck hat drei einzigartige Liniensegmente, die als Seiten bezeichent werden.
Die Liniensegmente sind von Dreieck (Triangle) aus navigierbar.

Die Komposition

Komposition - Eine binäre Assoziation, die eine Teile-GanzesBeziehung darstellt und es gilt:

1. Ein Teil kann zu einem Zeitpunkt höchstens in einem Ganzen (engl. whole, composite) enthalten sein.   image-1664280683396.png
2. Wenn ein Ganzes gelöscht wird, werden alle seine Teile mit diesem gelöscht.

Die Generalisierungimage-1664280891735.png

Generalisierung - Eine binäre taxonomische Beziehung zwischen einem allgemeineren Typ

Realisierung

Realisierung odellelementen, von denen eine die Spezifikation und die andere deren Implementierung (Kunde) darstellt.

Spezielle Realisierung zwischen einem Klasse und einer Schnittstelle. image-1664281130770.png

Operation (engl. operation) -- Verhaltensmerkmal einer Schnittstelle, eines Datentyps oder Klasse

Datentyp -- Typ, dessen Instanzenimage-1664281473494.pngimage-1664281488584.png nur durch ihren Wert bestimmt sind

Aufzählung ( enumeration) -- Datentyp, dessen Werte benutzerdefinierte Literale sind

 

UML Klassendiagramme

Ein Beispiel

image-1664281706204.png

image-1664285868774.png

UML Klassendiagramme

Anwendungsfall zu Fachmodell

Entity: Objekte, die persistentes Wissen (d.h. Daten) repräsentieren; häufig aus dem Domänenmodell hergeleitet.
Boundary: Objekte, die eine Schnittstelle zu Systemakteuren bilden (z.B. einem Benutzer oder einem externen System).
Control: Objekte, die Prozesswissen repräsentieren (später ggf. als separate Klassen oder einfache Funktionen implementiert).

Kommunikationsregeln im ECB-Muster
1. Akteure können nur mit Grenzobjekten (boundary objects) sprechen.
2. Systemgrenzobjekte können nur mit Kontrollobjekten (control objects) und Akteuren sprechen.
3. Entitätsobjekte (entity objects) können nur mit Kontrollobjekten kommunizieren.
4. Kontrollobjekte können mit Grenzobjekten, Entitätsobjekten und Kontrollobjekten kommunizieren, nicht mit Akteuren

Entity Objects identifizieren:
image-1664285994106.png1. Ausdrücke, die geklärt werden müssen, damit der Anwendungsfall verständlicher wird
2. Wiederkehrende Substantive in Anwendungsfällen
3. Begriffe aus der Fachdomäne
4. Aktivitäten in der realen Welt, die befolgt werden müssen
5. Vorhandene Datenquellen oder Ergebnisse

Boundary Objects identifizieren
1. Jeder Akteur interagiert mit mindestens einem Boundary Object in jedem Anwendungsfall.
2. sammeln Benutzerinfos und übersetzen sie in Strukturen, die von Control / Entity Objects verarbeitet werden.
3. Grobe Abstraktion der Systemgrenze treffen, ohne Details der visuellen Darstellung
4. Begriffe verwenden, die der Anwender versteht
5. Geräte der Interaktion identifizieren, Benutzungsschnittstellen beschreibenimage-1664287455676.png

Control Objects identifizieren - Koordination von Entity und Boundary Objects
1. Empfange Informationen von den Boundary Objects.
2. Verteile diese in geeigneter Form an die Entity Objects.

Beispiel:

1. Der Außenbeamte aktiviert die ,,MeldeNotfall"-Funktion auf dem Terminal. Ereignis ablauf

2. FRIEND antwortet durch Bereitstellung eines Formulars. Das Formular enthält Menü über Art des Notfalls, Ortsbeschreibung und Felder für eine Beschreibung des Notfalls, für Betriebsmittelanforderungen und für den Eintrag von gefährlichen Gütern.

3. Außenbeamter füllt das Formular aus durch Kurzspezifizierung des Notfalltyps und der übrigen Beschreibungen. Außenbeamter kann auch mögliche Aktionen auf die Notfallsituation beschreiben und spezielle Betriebsmittel erbitten. Sobald das Formular ausgefüllt ist, übermittelt es der Außenbeamte durch Drücken der,,Sende Meldung"-Taste dem Dienstleiter.

4. Der Dienstleiter überprüft die Information, die vom Außenbeamten übermittelt wurde, und erzeugt einen Vorfall in der Datenbank, indem er den Eröffne Vorfall-Anwendungsfall aufruft. Alle Informationen, die im Formular des Außenbeamten enthalten sind, befinden sich automatisch im Vorfall. Der Dienstleiter wählt eine Antwort aus durch Zuweisen von Betriebsmitteln an das Ereignis (mit dem WeiseBetriebs mittelZu-Anwendungsfall) und bestätigt die NotfallMeldung durch Übersenden einer Nachricht an den Außenbeamten. Die Empfangsbestätigung zeigt dem Außenbeamten, dass die Notfall Meldung erhalten, ein Vorfall erzeugt und Betriebsmittel an den Vorfall zugeteilt wurden. In der Empfangsbestätigung sind die Betriebsmittel (z.B. Löschzug) und deren voraussichtliches Eintreffen angegeben.

5. Der Außenbeamte erhält die Bestätigung und die ausgewählte Antwort.

Entity Objects

Dienstleiter Polizeibeamter, der den Vorfall leitet. Ein Dienstleiter eröffnet, dokumentiert und schließt Vorfälle ab als Antwort auf Notfall Meldungen und andere Kommunikation mit dem Außenbeamten. Dienstleiter werden durch Dienstnummern identifiziert.
NotfallMeldung Anfangsbericht über einen Vorfall von einem Außenbeamten an einen Dienstleiter. Eine NotfallMeldung erfordert das Erstellen eines Vor fall durch den Dienstleiter. Eine NotfallMeldung besteht aus einer Notfallebene, einem Typ (Brand, Verkehrsunfall, Sonstiges), einem Ort und einer Beschreibung.
Außenbeamter Polizist oder Feuerwehrmann im Einsatz. Ein Außenbeamter kann zu jeder Zeit nur einem Vorfall zugewiesen sein. Außenbeamte werden durch die Dienstnummer identifiziert.
Vorfall Ereignis, das die Aufmerksamkeit eines Außenbeamten erfordert. Ein Vorfall kann von einem Außenbeamten dem System mitgeteilt wer den. Ein Vorfall besteht aus einer Beschreibung, einer Antwort, einem Status (offen, beendet, ...), einer Örtlichkeit und einer Anzahl von zugewiesenen Außenbeamten.

Boundary Objects

Empfangsbestätigung

Bestätigung, um dem Außenbeamten den Empfang der Meldung beim Dienstleiter anzuzeigen.
DienstleiterStation Vom Dienstleiter benutzter Rechner.
MeldeNotfall Taste Vom Außenbeamten benutzte Taste, um den MeldeNotfall-Anwen dungsfall zu initiieren.
NotfallMeldeformular Formular, das für die Eingabe von MeldeNotfall benutzt wird. Dieses Formular wird dem Außenbeamten auf der Mobilen Station angeboten, wenn die Melde Notfall"-Funktion gewählt wurde. Das NotfallMeldeformular enthält Felder, um alle Attribute einer NotfallMeldung zu spezifizieren und einen Knopf (oder etwas Ähnliches), um das ausgefüllt Formular abzuschicken.
MobileStation

Vom Außenbeamten benutzter mobiler Rechner.
Vorfall Formular Formular, das für die Erstellung eines Vorfalls benutzt wird. Die ses Formular wird dem Dienstleiter auf der DienstleiterStation angeboten, wenn die NotfallMeldung empfangen wurde. Dienstleiter benutzt dieses Formular auch, um Betriebsmittel zuzuweisen und den Bericht des Außenbeamten zu bestätigen.

Control Objects

MeldeNotfall Steuerung Verwaltet die Benachrichtigungsfunktion MeldeNotfall auf der MobilenStation. Dieses Objekt wird kreiert, wenn der Außenbeamte den,,Melde Notfall"-Knopt auswahlt. Es erzeugt dann ein Notfall Meldeformular und bietet es dem Außenbeamten ar.. Nach dem Abschi cken des Formulars sammelt dieses Objekt die Informationen des Formulars, erzeugt eine NotfallMeldung und leitet sie zum Dienst leiter. Das Steuerungsobjekt wartet dann auf eine Empfangsbestäti gung von der DienstleiterStation. Sobald die Empfangsbestätigung eingetroffen ist, erzeugt das MeldeNotfall Steuerung-Objekt eine Empfangsbestatigung und zeigt sie dem Außenbeamten an.
VerwalteNotfall Steuerung Verwaltet die Benachrichtigungsfunktion MeldeNotfall auf DienstleiterStation. Dieses Objekt wird erzeugt, wenn eine Not fallMeldung empfangen wird. Es erzeugt dann ein Vorfall Formular und bietet es dem Dienstleiter an. Sobald Dienstleiter Vorfall erzeugt, Betriebsmittel bereitgestele und Empfangs bestätigung eingegeben hat, leitet VerwalteNotfallSteuerung die Empfangsbestätigung an MobileStation weiter

image-1664284378109.png

image-1664285532910.pngEine Checkliste:
Identifikation von entity, boundary und control objects
Abbildung von Anwendungsfällen auf Objekte
Identifikation von Assoziationen zwischen Objekten
Identifikation von Aggregationen
Identifikation von Attributen der Objekte
Modellerung von zustandsabhängigem Verhalten Objekte
Aktualisierung des gesamten Analysemodells

Sequenzdiagramme

Sequenzdiagramme

UML Sequenzdiagramme

Darstellung von Nachrichten*, die zwischen Akteuren und Objekten in begrenzten Zeitrahmen ausgetauscht werden.

→ zur Beschreibung des Systemverhaltens in Anwendungsfällen

image-1664353892038.png

Lebenslinie – Lebenszyklus von (anonymen oder konkreten) Objekten und Akteuren

Nachricht – Darstellung einer einzelne Kommunikation zwischen zwei Lebenslinien

Ausführung – Darstellung Zeitraums, in der Verhalten oder Aktion ausgeführt, ein Signal gesendet oder gewartet wird

→ Synchroner Aufruf – Senden Nachricht und Unterbrechen der Ausführung während Wartezeit auf eine image-1664354747302.png Antwort
→ Asynchroner Aufruf – Senden einer Nachricht und sofortige Fortsetzung der eigenen Ausführung
→ Rückgabe – Senden einer Antwortnachricht an das aufrufende Objekt
→ Selbstdelegation – Senden von Nachrichten eines Objekts an sich selbst
→ Callback – Ausführung, die synchron über eine Rückgabe für den originalen Aufrufer informiert

Benennung von Nachrichten: Nummer der Nachricht | Name der Methode | Argumente | Rückgabetyp 
1: aMessage(num:int, value:double):String

Bedingungen, wenn Nachricht gesendet: 1: (x<0): aMessage(num:int, value:double):Stringimage-1664354918334.png
Nachrichten können wiederholt gesendet werden: 1: *[while(result<25)]: result=operation()


Instanziierung – Nachricht zur Erstellung einer Lebenslinie eines Objekts
image-1664355075002.pngTerminierung – Nachricht zum Beenden einer Lebenslinie eines Objekts

Kombinierte Fragmente
alt : Alternativen: Auswahl des auszuführenden Verhaltens 
opt : Optionen: Auswahl eines einzelnen Operanden 
image-1664355693437.pngloop . Wiederholungen (Schleifen): Iteration im Ausführungsverhalten
break : Abbrüche oder Ausnahmen
par : Parallele Ausführungen
strict : Strikte Sequenzen: Reihenfolge einhalten
seq : Schwache Sequenzen: ausführen, Reihenfolge egal

Sequenzdiagramme

Beispiel

image-1664355890397.png

Sequenzdiagramme

Fortsetzung objektorientierten Analyse

Vorgehen: Abbildung der Anwendungsfälle auf Sequenzdiagramme

image-1664356495275.png

  1. Erste Spalte ganz links: Akteure, die den Anwendungsfall veranlassen
  2. Zweite Spalte von links: Systemgrenze (boundary object), die mit Akteur interagiert
  3. Dritte Spalten von links: das relevante Kontrollobjekt (control object)
    1. Zugriff auf Fachentitäten (entity objects)
    2. Kann andere Kontrollobjekte und Fachentitäten erstellen (create -Nachricht)
    3. Kann mit anderen Kontrollobjekten interagieren
  4. Folgende Spalten: Fachentitäten (entity objects)

image-1664356417443.png

Sequenzdiagramme

UML Kommunikationsdiagramme

Darstellung der Interaktionen zwischen Objekten mithilfe sequenzierter Nachrichten

Lebenslinie – Darstellung individueller Teilnehmer der Interaktionimage-1664356838992.png

sequence-term ::= [integer [name]] [recurrence]
→ sequence-term repräsentiert Reihenfolge der Nachricht in der Kommunikation
→ recurrence nennt Bedingung oder Schleife                                                         
Beispiel: Instanz der Klasse A sendet remove() -Nachricht an Instanz von B, wenn s1 gleich s2 ist. 

image-1664356943533.pngimage-1664356963789.png

 

 

Systementwurf

Systementwurf

Systementwurf allgemein

Auswirkungen von Entscheidungen verstehen, z.B. Virtualisierung und Cloud-Infrasturkturen, Entwurfsmuster...

→ mit Module | Kohäsion (cohesion) | Kopplung (coupling

Entwurfsziele festlegen: Einschränkung möglicher Alternativen im Entwurf ermöglichen Entwurfsentscheidungen (Quality Tree)
→ durch Nichtfunktionale Anforderungen | Termine mit dem Auftraggeber | Studium der Anwendungsdomäne

Subsysteme definieren

Softwarearchitektur – Festlegung der Organisation eines Softwaresystems fest durch Komponenten und Verbindungen

→ Spezifikation der wesentlichen Strukturen eines Anwendungssystems, dh. der Komponenten und Schnittstellen (Bausteinsicht)

Fachliche Architektur – Architektur des Softwaresystems aus fachlicher Sicht, d.h. aus Sicht der Fachabteilung
Technische Architektur – Realisierung der logischen Komponenten auf der Grundlage der technischen Infrastruktur

image-1664362849795.png

image-1664362960754.png

 

 

 

 

 

 

Architekturmuster – Lösungsansatz, der für Element der Architektur durchgängig und ausnahmslos angewandt wird 

Beispiele: Datenzentrierte Architektur | Schichtenarchitektur | Ereignisbasierte Architektur | Service-orientierte Architektur

Datenzentriete Architektur: Komponenten kommunizieren über eine Datenbankimage-1664363729890.png
→Etablierung eines einheitlichen Datenmodells ist organisatorisch und technisch höchst anspruchsvoll

Schichtenarchitektur: Komponenten mit Zusammenhang werden einer Schicht zugewiesen.image-1664364054648.png
→ Komponenten einer Schicht dürfen nur die Komponenten dieser und der Schicht nutzen
→ Aufrufe passieren Schichten von oben nach unten.
→ Ergebnisse werden von unten nach oben durchgereicht.

Verteilung – Festlegung, auf welchen Rechnern die Komponenten einer verteilten Anwendung installiert werden

Datenhaltung | Geschäftslogik | Ergebnisdarstellung | verschiedene Architektueren

→ Ein-Ebenen-Architektur: Komponenten der Anwendung werden auf einem Rechner installiert. (Zentralrechner) (ERP-Systeme)
→ Zwei-Ebenen-Architektur: Komponenten der Anwendung werden auf zwei Rechnern installiert (Client und Server) (Datenbank)
→ Drei-Ebenen-Architektur: Komponenten auf drei Rechnern (Datenbankserver, Applikationsserver, Client) (ERP-Systeme)
→ Mehrebenen-Architektur: mehrere Rechnern (Datenbankserver, Applikationsserver, Websever, Client-Rechner) (Onlineshops)

Zwei-Ebenen-Architekturimage-1664364402204.png

 

Systementwurf

Wann ist ein Systementwurf gut?

Korrektheit

Ein Systementwurf ist korrekt, wenn das Analysemodell dem Systementwurf zugeordnet werden kann.

Kann jedes Subsystem auf eine funktionale oder nicht-funktionale Anforderung zurückverfolgt werden?
Kann jedes Entwurfsziel auf eine nicht-funktionale Anforderung zurückverfolgt werden?
Gibt es für jeden Akteur eine Zugangskontrolle?

Vollständigkeit

Ein Systementwurf ist vollständig, wenn jede Anforderung für den Systementwurf berücksichtigt wird.

Wurde das Anwendungsfalldiagramm verwendet, um fehlende Funktionen im Systementwurf zu entdecken?
Wurden alle Anwendungsfälle jeweils einem Kontrollobjekt zugewiesen?
Wurden alle Aspekte des Systementwurfs (Plattform, Datenspeicherung, Zugangskontrolle, Komponenten) behandelt?
Sind alle Subsysteme definiert?

Konsistenz

Ein Systementwurf ist konsistent, wenn er keine Widersprüche in sich trägt.

Sind gegenüberstehende Entwurfsziele priorisiert?
Verletzt ein Entwurfsentscheidung eine nicht-funktionale Anforderung?

Implementierbarkeit

Ein Systementwurf ist realistisch, wenn das System implementiert werden kann

Sind Leistungs- und Zuverlässigkeitsanforderungen im Rahmen der zerlegung in Subsysteme überprüft?
Können Probleme bei nebenläufigen Zugriff auf Objekte oder Subsysteme ausgeschlossen werden ( Deadlocks)?

Lesbarkeit

Ein Systementwurf ist lesbar, wenn nicht am Systementwurf beteiligte Entwickler den Entwurf verstehen können:

Sind die Namen der Subsysteme (fachlich) nachvollziehbar?

Entwurfsentscheidungen als Sensitivity Points, Trade-offs oder Risiken einordnen. 

Systementwurf

Paketdiagramme

Dienen der Gliederung eines Gesamtmodells in kleinere, überschaubare und miteinander interagierende Einheiten.

Paket – Benennung einer Gruppe von Elementen, die semantisch verknüpft sind und sich zusammen ändern können.

→ Elemente eines package können innerhalb oder außerhalb des package (mittels Zeichen) dargestellt werden.
→ Elemente eines package können öffentlich oder privat sein.

Pakete sind Zusammenfassungen von Elementen beliebigen Typs
→ Einzelne Modellelemente (Klasse, Akteur, etc.)
→ Teilmodelle (Klassendiagramm, Aktivitätsdiagramm, etc.)

Elementimporte erlauben das direkte Referenzieren eines Elements über seinen Namen.

Paketimporte erlauben das direkte Referenzieren mehrerer Elemente über ihren Namen.

Öffentlich (engl. public): <<import>> (optional, da Standardwert)image-1664369152011.png
Das importierte Element wird dem Namespace hinzugefügt und ist auch außerhalb des Namespace sichtbar.

Privat (engl. private): <<access>>
Das importierte Element wird ausschließlich dem Namespace hinzugefügt

image-1664369494973.png Paketzusammenführung- Erweiterung eines Pakets durch den Inhalt eines anderen Pakets

Modell - Paket, das die Abstraktion eines gesamten Systems darstellt.

Das Paket soll so strukturiert sein, dass es ...
  • den Leser durch das Modell führt,
  • in sich abgeschlossenen Themenbereich enthält,
  • logisch zusammengehörende Klassen enthält,
  • eine wohldefinierte Schnittstelle zur Umwelt enthält.
 Dabei soll die Paket-Schnittstelle ...
  • Vererbungsstrukturen in horizontaler Richtung schneiden 
  • keine Aggregation durchtrennen und
  • wenige Assoziationen enthalten

image-1664370220461.png

1. Die zu Anwendungsfall Elemente sollten zum Subsystem gehören.
2. Elemente, die zwischen Subsystemen Daten darstellen, sollten in
einem separaten Subsystem untergebracht werden.
3. wenig Assoziationen zwischen Subsystemen → Lose Kopplung
4. Elemente eines Subsystems sollten in funktionalen Zusammenhang
stehen → Hohe Kohäsion

Kopplung - Anzahl der Abhängigkeiten zwischen Subsystemen

Kohäsion - Anzahl der Abhängigkeiten innerhalb eines Subsystems

 

Systementwurf

UML Komponentendiagramme

Modellierung von Komponenten, deren bereitgestellte und benötigte Schnittstellen, Ports und Beziehungen zwischen ihnen

image-1664370539260.pngLogische Komponenten (z.B. Geschäftskomponenten) image-1664370591465.png
Physische Komponenten (Programme, Maven-Packages)

Realisieren interne Bestandteile (z.B. Klassen) eine Komponente, können diese innerhalb Komponente in einem separaten Abschnitt ( <realization> compartment) notiert werden

Schnittstellenimage-1664371334047.pngimage-1664371345792.png
Bereitgestellte Schnittstelle wird durch die Komponente ealisiert.
Benötigte Schnittstelle definiert durch Verwendungsabhängigkeit ( <use> dependency) .

Ports

Über Port kann Element mit Umgebung, mit anderen Objekten oder mit seinen internen Bestandteilen kommunizieren.

→ Standardsichtbarkeit: öffentlich (public)image-1664371510168.png
→ Angabe von Multiplizitäten optional, z.B. [1..6]
→ Simple port: Port mit nur einer Schnittstelle

Assembly Connectorimage-1664371630945.png

Verbindung zwischen min. zwei Komponenten, die Dienstbereitstellung und -nutzung zwischen Komponenten darstellt.

Delegationskonnectorimage-1664371817624.png

Verbindung eines externen Ports bzw. Schnittstelle einer Komponente mit ihren internen Bestandteilen

Komponenten sind Paketen ähnlich: Sie definieren Grenzen und gruppieren und gliedern Modellelemente

Pakete: Logische Sicht auf Codestruktur zur Entwicklungszeit | Komponenten: Physische Sicht zur Laufzeit

 

Systementwurf

UML Verteilungsdiagramme

Verteilungsdiagramme bieten Sichten auf ein Anwendungssystem zur Laufzeit
image-1664381501437.pngZeigen, welche Kommunikationsbeziehungen zwischen Komponenten, Prozessen, Objekten 

Knoten - Ziel der Verteilung für Laufzeitobjekte und sonstige Artefakte (evtl. hierarisch)

→ datenverarbeitenden Anlagen (Prozessoren, Computer) einer Systemarchitektur modellieren 

Knoten: Geräte

image-1664381845931.png

Eine physische Rechenressource, auf der Artefakte zur Ausführung bereitgestellt werden können

Standard-Stereotypen: device, application server, client, mobile

Spezielle Knoten: Ausführungsumgebungimage-1664382461362.png

Software für Typen von Komponenten, die darauf als ausführbare Artefakte bereitgestellt werden

Standard-Stereotyp: executionEnviroment, OS, workflow, web browser

Kommunikationsverbindungenimage-1664382844120.png

Zwischen Knoten eines Systems können Kommunikationsbeziehungen bestehen

Zwischen Geräten: physische Verbindungen, z.B. <ethernet>
Zwischen Ausführungsumgebungen: Kommunikationsprotokolle, z.B. <protocol> TCP/IP

Artefakte und Laufzeitobjekteimage-1664383029700.png

Auf Knoten können Laufzeitobjekte und sonstige Artefakte bereitgestellt und ausgeführt werden.

Standard-Stereotyp: <artefact, file, ...>
→ Konkrete physische Darstellung eines oder mehrerer Modellelemente durch ein Artefakt
→ Artefakte können von anderen Artefakten abhängig sein

Deploymentimage-1664383642973.png

Bereitstellung (engl. deployment) - Zuordnung Artefakts zu einem Verteilungsziel

→ Darstellung als Abhängigkeit (dependency) mit Stereotyp <deploy>
→ Kann auch als in einem Knoten enthalten dargestellt werden Kann auch auf Instanzebene dargestellt werden

Relevante Fragestellungen:
→ Welche Kommunikationsbeziehungen bestehen zwischen diesen Komponenten, Prozessen und Objekten?
→ Arten der Modellierung: Können auf Typebene (Spezifikationsebene) und auf Instanzebene verwendet werden!

 

Implementierung

Implementierung

Muster in der Softwareentwicklung

Muster – Beschreibung eines wiederkehrenden Problems sowie einer bewährte und generische Lösung dafür

→ Müssen an das jeweilige Projekt angepasst werden
→ Dienen der Kommunikation von zwischen Entwicklern

Microservices – Architekturstil, bei Anwendung in Dienste aufgeteilt wird, die unabhängig entwickelt / installiert werden 

→ Laufen als eigenständige Prozesse, die separat bereitgestellt und skaliert werden können
→ Unterliegen einer minimalen zentralisierten Verwaltung

Implementierung

Entwurfsmuster

Entwurfsmuster (design pattern) – Lösung für bestimmtes, in Zusammenhängen wiederkehrendes Entwurfsproblems

→ Faustregel: mindestens dreimal vor der Dokumentation sinnvoll eingesetzt und/oder beobachtet haben

Klassifizierung von Designmustern
Creational Patterns: Helfen, System unabhängig davon zu erstellen, wie Objekte erstellt, komponiert und dargestellt werden.
Structural Patterns: Umgang mit der Zusammensetzung von Klassen und Objekten in größere Strukturen
Behavioural Patterns: Umgang mit der Wechselwirkung zwischen Objekten und Klassen, komplexe Kontrollflüsse

Beispiel: Strategy-Muster
Problem: Verwandte Klassen unterscheiden sich dadurch, dass sie gleiche Aufgaben durch verschiedene Algorithmen lösen
Lösung:

  1. Eine Klasse definiert alle gemeinsame Operationen (Strategy Context)
  2. Signaturen der unterschiedlich zu implementierenden Operationen werden in einer weiteren Klasse (Strategy)
  3. Von Klasse/Schnittstelle wird für Implementierungsalternative eine konkrete Unterklasse abgeleitet (Concrete Strategy)
  4. Strategy Context benutzt konkrete Strategy-Objekte, um unterschiedlich Operationen per Delegation auszuführen 

image-1664527626721.png

image-1664527651846.png

 

 

 

 

 

 

Vorteil des Strategy-Musters Nachteile des Strategy-Musters
  • Einkapselung von Algorithmen in Strategieklassen vermeiden Fallunterschiede zum Auswählen der jeweiligen Variante eines Algorithmus.
  • Auswahl der Varianten geschieht durchKonfiguration des Kontextes mit einem geeigneten Strategieobjekt.
  • Erhöhter Wissensbedarf
  • Erhöhter Kommunikationsaufwand:
  • Erhöhte Anzahl von Objekten
Vorteile der Musternutzung allgemein Nachteile der Musternutzung allgemein
  • Muster bieten eine Sprache für das Design
  • Probleme, Lösungen werden explizit gemacht
  • Muster sind keine fertigen Entwurfslösungen
  • Muster ersetzen nicht Konzept noch sauberen Entwurf
Implementierung

Einstieg ins Testen

Testen – Die - auch mehrfache - Ausführung eines Programms auf einem Rechner mit dem Ziel, Fehler zu finden

Systematisches Testen – Test, bei demimage-1664531586440.png
(1) die Randbedingungen definiert erfasst sind,
(2) die Eingaben systematisch ausgewählt wurden, und
(3) die Ergebnisse dokumentiert und nach vor dem Test festgelegten Kriterien beurteilt werden

Verifizierung – Prüfen, ob die Ergebnisse einer Phase des Projekts mit denen der vorherigen Phase übereinstimmen

→ "Wurde das System richtig entwickelt?"

Validierung – Prüfen, ob das endgültige Ergebnis des Projekts wirklich dem Bedarf des Kunden entspricht

→ "Wurde das richtige System entwickelt?"

Qualitätsprioritäten: Richtigkeit, Sicherheit, Leistung, schnelle Entwicklung, geringer Aufwand, Wartungsfähigkeit ...
Testziele: Hoher Anteil getesteter Codezeilen, hoher Anteil getesteter Funktionen, hohe Fehlererkennungsrate, schnelle Tests ...

Arten von Tests

Funktionsprüfung: Nicht funktionale Prüfung:
Unit Testing
Integration Testing
System Testing - Gesamte Prüfung
Acceptance Testing - Anforderungtesting
Smoke Testing - Prüfung in Prod-Umgebung 

Performance Testing

Security Testing

Usability Testing

Compatibility Testing

Verwengung von Staging Areasimage-1664532175588.png
DEV: Entwicklungsumgebung eines Entwicklers
INT: Integrationsumgebung eines Teams mit Mocks externer Systeme
CON: Konsolidierungsumgebung für Testen mit externen Systemen durch ein Testteam
OPS bzw. PROD: Die Produktivumgebung beim Kunden

 

Implementierung

Funktionsprüfung

Unit Testing – Testen einzelner Softwaremodule oder Komponenten eines Softwaresystems

→ von den Programmierern des Moduls testgetrieben erstelltimage-1664532394619.png
→ Jede Modulfunktion wird durch Testfälle getestet
→ Unit-Tests laufen automatisiert in DEV Staging-Bereich

Drei Gesetze der testgetriebenen Entwicklung
1. keinen Produktionscode, außer um fehlschlagenden Test zu bestehen
2. nur so viel von einem Test, um einen Fehler zu demonstrieren.
3. nur gerade so viel Produktionscode, um den Test zu bestehen.

Integrationstest – Testen einzelnen Softwaremodule im Zusam-menspiel, um spezifische Aufgaben / Aktivitäten durchzuführen

→ Prüfung erfolgt als Kombination aus automatisierten und (falls nötig) manuellen Funktionstests.
→ Integrationstests laufen im INT-Staging-Bereich

Systemtest – Prüfung des System in seiner Gesamtheit auf Fehler

→ Verbund aller Hardware- und Softwarekomponenten des gesamten Systems
→ als Blackbox-Testmethode angesehen, in Software auf vom Benutzer Arbeitsbedingungen sowie auf Ausnahmebedingung
→ Systemtests laufen im CON-Staging-Bereich (sollte eine vollständige Kopie von OPS bzw. PROD sein.)

Akzeptanztest - Prüfung, ob das System alle Anforderungen des Endkunden erfüllt

→ Akzeptanztests werden im CON-Staging-Bereich vom Endkunden ausgeführt (ggf.auch vom Product Owner)

Smoke-Test – Prüfung der Funktionsfähigkeit der OPS/PROD-Umgebung nach Develop einer Software-Version vor Relase 

→ Nach den Smoke-Tests startet üblicherweise eine 2-3 wöchige Testphase am LiveSystem

Implementierung

Nicht funktionale Prüfung (oo):

Spezifikationstest (auch: Black-Box-Test):
→ Überprüfen der Eingabe-/Ausgabebeziehungen einer Klasse oder Komponente.
→ Die interne Struktur wird vernachlässigt.
→ Erstellung geeigneter Äquivalenzklassen

Äquivalenzklasse – Bezüglich Ein- und Ausgabedaten ähnliche Objekte, wo erwartet wird, dass sie sich gleich verhalten

Beispiel: Anwendungsfall "Veranstaltung finden"
Anwendungsfall: Veranstaltung finden | Primärer Akteur: Käufer | Kontext: Ticket Informationsschalter | Bedingungen: keine
Testenszenario:
1. Benutzer wählt Genre und einen Datums- und Uhrzeitrahmen aus. Das System überprüft, dass der Zeitrahmen stimmt
2. Das System zeigt das Ergebnis der Abfrage.
3. Der Benutzer fordert eine detaillierte Ansicht einer ausgewählten Veranstaltung an.
4. Das System zeigt die Detailansicht für die ausgewählte Veranstaltung. 

Erweiterungen: 2a. Die Abfrage enthält keine Ergebnisse. Zurück zu 1. oder abbrechen.
Konsequenzen: keine.
Anweisungen: Abfrage durch das Webportal des Systems, Kiosk-Schnittstelle, Kassa-Client (unterstützter sekundärer Akteur)

Nr. Testfall  Erwartetes Ergebn.  Eingabedaten
1 Entering valid name  Search Result name="cinema word"
2 Entering valid state Search Result  state="NÖ"
3 Entering empty state  Exception Message state="
4 Entering invalid state  Empty Search Result  state="bavaria"
5 Entering valid city  Search Result  city="Hürm"
6 Entering city not in database  Empty Search Result  city="4444"

Schwellenwert – Wert, der gerade noch innerhalb oder schon außerhalb eines gültigen Wertebereichs liegt.

→ Falsche Vergleichsoperatoren, z.B. < statt <=, Rundungsfehler,...

Strukturtest (White-Box-Test):
→ Prüfung der internen Programmstruktur
→ Struktur des zu untersuchenden Objekts muss bekannt sein
→ Experimentiere: 1. Bestimme alle Ausführungswege und 2. Entdecke mögliche Fehler in einem dieser Wege
→ Vorteil: Lage des Fehlers kann sehr genau eingegrenzt werden
→ Nachteil: Sehr kosten- und arbeitsintensiv

Grad der Codeabdeckungimage-1664534440563.png
C0-Überdeckung oder Knotenüberdeckung: Jede auftretende Anweisung im Code muss mindestens einmal in einem Testfall durchlaufen werden.

C1-Überdeckung oder Kantenüberdeckung: Jede Kante im Kontrollflussgraph muss mindestens einmal in einem Testfall durchlaufen werden.

Cinfinite-Überdeckung oder Pfadüberdeckung: Jede (praktisch) mögliche Reihenfolge aller Codeanweisungen müssen von den Testfällen abgedeckt werden.

Bedingungsüberschneidung: Jede Kombinationen der  Teilausdrücke logischen Ausdrucks muss in Testfällen überprüft werden.

Kantenüberlappung vs. Zustandsüberlappung IF (A=true) and (B=false) THEN ...
Zwei Testfälle, um eine Kantenüberlappung zu erreichen: (A=true) and (B=false) == true | (A=true) and (B=true) == false
Vier Testfälle, um Bedingungsüberlappung erreichen: A = true, B = true A = true, B = false A = false, B = true A = false, B = false