oosk

• Anfragestelle der Werkzeuge für Materialien
• delegiert an Materialversorger
• Umgebungsobjekt ermittelt Materialversorger und übergibt sie der Materialverwaltung
• Anfrage an Materialverwaltung liefert Materialbehälter

• Produktivitätssteigerung
• Qualitätssteigerung
• Geringer Wartungsaufwand
• Lernen am guten Beispiel

• Komponentenentwurf
• Schnittstellenfestlegung
• Aufruf-/Verwendungsbeziehung festlegen
• ==> Spezifikation der Komponenten

• Architekturentwurf
• System in Subsysteme zerlegen
• Komponenten identifizieren
• Beziehungen der Komponenten ermitteln
• Zusammenspiel der Komponenten etablieren
• ==> Architekturbeschreibung

• Strukturdiagramme
• Klassendiagramm
• Objektdiagramm
• Paketdiagramm
• Kompositionsstrukturdiagramm
• Komponentendiagramm
• Verhaltensdiagramme
• Use-Case-Diagramm
• Aktivitätsdiagramm
• Zustandsdiagramm
• Interaktionsdiagramme (sind Verhaltensdiagramme)
• Sequenzdiagramm
• Kommunikationsdiagramm
• Timing-Diagramm
• Interaktionsübersichtsdiagramm

• Vorgehensmodell
• Aspekte der Projektorganisation
• Qualitätssicherung
• Dokumentation
• Rollen
• Musterstruktur für Organisation und Durchführung eines SW-Prozessees

• Begriff
• Bedeutung
• Abgrenzung
• Gültigkeit
• Bezeichnung
• Unklarheiten
• Querverweise

• Liste aller Hauptwörter
• Irrelevante Begriffe entfernen
• Ausprägungen entfernen
• Vage Begriffe entfernen
• Synonyme entfernen
• Merkmale entfernen
• Dienstleistungen entfernen
• Beziehungen identifizieren

• Funktion besitzt 1-n Typparameter
• Zulässige Typen haben selbe Struktur
• Bsp. generische Funktionen

• Echte Polymorphie
• Selber Code für alle Argumente des zulässigen Typen

• Abstraktion
• Trennung Schnittstelle, Implementierung
• Information Hiding
• Seperation of Concerns
• Hohe Kopplung, geringe Kohäsion
• Modularisierung
• Kapselung
• Teile und Herrsche
• Ausreichend, vollständig, einfach
• Open-Closed Prinzip

• Schreibt Architektur vor
• Generelle Designentscheidungen für Anwendungsklasse
• Definiert, welche Klassen angepasst werden können
• Implementiert Kommunikationsmechanismen zwischen Klassen
• Verantwortlichkeiten von Klassen
• Kann Klassenbibliotheken enthalten
• Design Reuse

• Festlegen von
• Architektur, Komponenten, Schnittstellen

• Konsistenzbedingungsobjekte überwachen Material
• Abhängige Materialien in Materialbehälter
• Materialbehälter mit KBO parametrisiert
• Änderung Material -> Info an MB -> KBO aktualisieren

• Strikt: Erweiterung, Definition
• Nicht Strikt: Erweiterung, Definition, Redefinition

Ein System wird sich im Laufe der Zeit ändern oder wird weggeworfen.

• Signaturregel: S muss alle Methoden von B anbieten (Signaturen kompatibel)
• Methodenregen: Die in S redefinierten Operationen von B müssen zumindest in all jenenSituationen aufrufbar sein, in denen B‐Operationen aufgerufen werdenkönnen, und »kompatible« Ergebnisse liefern.
• Eigenschaftenregel: Eine Unterklasse muss alle Eigenschaften der Oberklasse bewahren (insb. Invariante)
• ==> Vorbedingungen duerfen abgeschwaecht werden, Nachbedingungen verschaerft werden.

• Generalisierung
• isA

• WV von SW-Produkten
• WV von Lösungsstrukturen, Methoden, Sprachen
• WV von Komponenten des OS, Bibliotheken

• Reuse-Manager: Zieldefinition
• Reuse-Librarian: zertifiziert, verwaltet
• Reuse-Engineer: entwickelt, pflegt, berät, schult
• Reuse- Evaluator: bewertet

• Es kommen neue Eigenschaften hinzu.
• Z.B. List<--SortedList

• Einschränkung einer Bedingung.
• Z.B. Rectangle<--Square

• Unterklassen B_1...B_n von A spezilisieren A im Sinne von unterschiedlichen Klassifikationsaspekten
• 

• Oberklasse definiert allgemeine strukturelle Eigenschaft, Unterklasse besitzt diese Eigenschaft
• Z.B. Printable

• Vergegenständlichung
• (Abstrakte) Oberklasse A definiert allgemeine Datenstruktur
• Unterklasse B realisiert Implementierungsalternative
• Z.B. Sequential Table <-- LinkedListTable

• Redefinition der Eigenschaften so, dass sie virtuell werden
• nur bei Mehrfachvererbung

• Redefinition der Eigenschaften der Oberklasse
• Keine neuen Eigenschaften
• Hier: Nur Methodenrumpf redefinieren
• Z.B: HashTable <-- FastHashTable

• Redefinieren, keine neuen Eigenschaften
• Hier: Nur Redifinieren der Signaturen
• Z.B. Employee <-- MaleEmployee

• Sauberes Layout
• Sinnvolle Namen
• Ausführliche Kommentare
• Robust
• Lesbar

• Objekt-basiert: Objekte als Datenkapsel
• Klassenbasiert: Objekte und Klasse
• Objektorientiert: Objekte und Klassen und Vererbung

• Wichtige Use Cases identifizieren
• Beziehungen zwischen Akteuren und UC identifizieren
• Beziehungen zwischen UC identifizieren
• UC in strukturierter Form beschreiben

• Basisfunktion
• Benutzerfunktion
• Top-Level-Funktion

• Class
• Superclass
• (Attributes)
• Responsibilities
• Collaborators

System ändert sich während der Entwicklung

• Klasse definiert zusammengehörende Eigenschaften
• Diese werden anderen Klassen mittels Vererbung zur Verfügung gestellt
• Constant Inheritance: Klasse definiert globale Konstanten
• Machine Inheritance: Klasse definiert Eigenschaften einer (abstrakten) Maschine: :Die Klasse definiert Eigenschaften einer (abstrakten) Maschine.

Eine Unterklasse B erbt Eigenschaften von A, die ausschließlich verwendetwerden, um die zu B gehörende Abstraktion zu implementieren.

• Scheinbare Polymorphie
• Operationen auf verschiedenen Typen zeigen nicht unbedingt gleiches Verhalten
• Typen müssen keine Gemeinsamkeiten haben
• Operationen können verschiedenen Code ausführen
• Menge von monomorphen Operationen

• Vorhandenen Typen in erwarteten konvertieren
• Ohne Anpassung: Typfehler
• Statisch oder dynamisch

• Selber Bezeichner für verschiedene Operationen
• Unterschiedliche Parametertypen

• Objekt kann zu mehr als einem Typ gehören
• Sybtyping ist Form von Inlusionspolymorphie

• Zerlegbarkeit
• Kombinierbarkeit
• Verständlichkeit
• Lokalität

• Entscheidung zwischen Wiederverwendung und Neuentwicklung ist gegeben
• Geplante WV: Komponenten werden mit Ziel WV entwickelt
• Ungeplante WV: Bereits realisierte Komponenten

• 
• Hier: Objektadapter
• Klassenadapter: Adapter erbt von Dienst

• Kosten
• Mehraufwand bei Entwicklung
• Lagerung, Verwaltung
• Finden, Anpassen, Integration
• Nutzen
• Weniger Entwicklingskosten
• qualitativ besser

Nutzen > Kosten ab 3x WV

• Realisiert Arbeitsplatz
• Bindet Arbeitsplatz an externe Dienste an(Materialverwaltung)
• Erzeugt und koordiniert Werkzeuge(Werkzeugkoordinatoren)

• Zeigt, wie Komponenten auf Infrastruktur- und HW-Einheiten abgebildet werden
• Aufteilung der Entwicklung auf Teams

• Darstellung der Zusammenarbeit der Komponenten zur Laufzeit
• Modellieren Systemverhalten

Sichten zeigen zentrale Komponenten der Architektur, sowie ihre Schnittstellen und Beziehungen

• Restructuring: Transformation der Repräsentation zu einer anderen auf selbem Abstraktionslevel
• Data Reengineering: Neuorganisation der Daten für besseren Verständnis
• Refactoring: Restrukturierung im OO-Kontext

• Redocumentation: im selben Abstraktionslevel eine äquivalente Repräsentation bilden
• Design recovery: Wiederherstellung einer Designabstratktion aus Code, Doku, Erfahrung und Wissen

• Sehr lange Klassen
• Duplizierter Code
• Case-Anweisung auf Typmerkmale
• Aufwändige Kommentierung
• Frederic hat programmiert
• Silivo hat programmiert
• Christoph hat programmiert
• Yannick hat programmeirt

• Werkzeugbaum wird durch Funktionskomponenten gebildet
• Kontext-Interaktionskomponente muss nicht mit Sub-Interaktionskomponente zusammenarbeiten
• Kontext-IAKen und FKen beobachten Sub-FKen

• Definieren wie prinzipiell SW entwickelt wird
• Wasserfallmodell
• Prototyping
• Spiralmodell
• etc.

• Material erbt Aspektschnittstellen
• Werkzeuge nutzen ausschließlich Aspekte

Sichten zeigen, wie das zu entwickelnde System in die Umgebung eingebettet ist

Zusicherung spez. Vor- und NachbedingungenAufrufer muss Vorbedingungen einhaltenAnbieter muss Nachbedingungen garantierenInvariante dauerhaft gültig

• Nach Erzeugung eines Objekts von A gilt Invariante
• Nach Aufruf einer Methode von A gelten Invariante und Nachbedingung sofern vorher Invariante und Vorbedingungen galten
• Alle Objekte erfüllen vor und nach Methodenaufrufen Invariante

• ID
• Goal
• Classification
• Precondition
• Postcondition
• PC on error
• Actors
• Trigger
• Mainflow
• Deviations

• Hook und Template-Methoden in einer Klasse
• User UK überschreiben hook-Methode
• Kein Wechsel des Verhaltens zur Laufzeit

• Einsatzspektrum: vertikal, horizontal
• Anpassung: White-Box, Black-Box
• Technik: neutral, spezifisch
• Funktionalität: anwendungsspezifisch, anwendungsneutral

• SW-Entwurfsmethode in Analyse um Anforderungen
• vollständig
• widerspruchsfrei
• präzise
• zu definieren

• Zustand und Repräsentation eines Werkzeugs können durch Änderungen ihres Materials inkonsistent werden
• Materialbehälter haben einen Werkzeugkoordinator(koordiniert alle Werkzeuge des Materialbehälters)
• Material ändert sich => WZK informiert => Werkzeug informiert

• Sichern Konsistenz zwischen abhängigen Materialien
• Materialverwaltung kennt alle Klassen, die KBO realisieren
• Strategie zur Korrektur von Inkonsistenzen muss implementiert werden
• Rein algorithmisch

• Single Dispatch:
• Emfänger der Nachricht sucht die richtige Methode - Wird durch Klassenzugehörigkeit von a festgelegt
• a.plus(b)
• b(Parameterobjekte) trägt nicht zur Entscheidung bei
• Ausführung immer unymmetrisch
• Multiple Dispatch:
• plus(a,b)
• Klassenzugehörigkeit aller Parameter bestimmt aufzurufende Methode
• Symmetrische Behandlung der Parameter
• Kein ausgezeichneter Nachrichtenempfänger

• Bezeichner haben statischen Typ
• Zuweisung, Parameterübergabe: Objekte andere Typen können dynamisch gebunden werden
• Nur Typen zulassen, die konform zum statischen Typ sind (Type Checker)
• Richtige Implementierung binden (Laufzeitsystem)
• ==> Sicherheit durch Typkonzept, Flexibilität durch Polymorphie

• Kontravarianzregel: In der Unterklasse werden die Parametertypen allenfalls ausgeweitet
• Kovarianzregel: In der Unterklasse werden die Parametertypen allenfalls eingeschränkt.
• Typsicherheit falls Argumenttpen kontravariant und Ergebnistypen kovariant.

• Einbruch: Modifikation des Codes einer anderen Komponente
• Volle Öffnung: Zugriff auf alle Daten
• Fremdsteuerung: Klient steuert Server über Steuerparameter
• Selektive Öffnung: Bestimmte Daten zugänglich
• Parameter: Programmteile als Prozeduren. Kommunikation nur über Parameter
• Funktionen: Nur Wertparameter und Funktionsresultate
• Keine Kopplung: Keine Verbindung zwischen Komponenten

• Kein Zusammenhalt: Zufällige Zusammenstellung
• Ähnlichkeit: Ähnlicher Zweck, z.B. Fehlerbehandlung
• Zeitlich: Ausführung zur gleichen Zeit, z.B. Initialisierungsanweisungen
• Arbeitet mit denselben Daten: z.B. Datumsoperationen
• Kommunikation über Zwischenergebnisse: Interne Ergebniskette
• Einziger Zweck: z.B. Iteratoroperationen
• Einziges Datum: Datenkapsel

• Geschlossen: Schnittstelle ist vollständig und ändert sich nicht mehr.
• Offen: Modul kann problemlos erweitert werden
• Lösung durch Vererbung

• Direkte Abbildung von Anwendungsbereichstruktur auf SW-Struktur
• Wenige Schnittstellen
• Kleine Schnittstellen
• Explizite Schnittstellen
• Geheimnisprinzip

• Geringe Kopplung: Schichten nur gekoppelt, wenn benachbart
• Änderungen haben meißt nur Auswirkungen auf eine Schicht
• Schicht kann aus mehreren entkoppelten Teilen mit hohem Zusammenhang bestehen

Evtl Performanceeinbußen durch Durchreiche-Operationen

• Protokollbasiert: Nur Nachbarschichten sind sichtbar. Protokoll wird für oben liegende Schichten zur Verfügung gestellt
• Obiektorientiert: Schicht = Klassen, Rahmenwerke, Bibliotheken; Zugriff mittels "use" und "inherit"
• oo-Schicht darf nur Komponenten der nächsttieferen Protokollschicht benutzen
• Schicht darf Komponenten aller tieferen oo-Schichten benutzen

• Ausgangspunkt sind Kompositionen
• Classifier besteht aus Parts, die mit Konnektoren verbunden sein
• Ports (evtl mit Rollennamen) beschreiben Schnittstellen zwischen Parts oder Classifiern

• Operation schützt sich selbst vor Fehlern
• Alle denkbaren Fehlersituationen werden abgefangen
• Code wird umfangreich
• Relevanter Code schwer zu erkennen
• Redundante Prüfsequenzen
• Spezifikation der Einsatzbedingungen ist im Code verteilt

• Entwickler sind nicht verfügbar
• Entwicklungsmethoden inzwischen veraltet
• System ist seit Entwicklung heftig modifiziert worden
• Dokumentation fehlt
• Wartung ist teuer

• Interpretation und Gestaltung von tatsächlichen Anwendungssituationen und SW-Systemen
• Interpretation und Erfassung der Anwendungswelt

• Stellt fachliche Abhängigkeiten zwischen Materialien und deren Konsistenz sicher
• Kontrolliert ob Anwendung eines Werkzeugs auf ein Material möglich ist

• Werkzeuge werden aus wiederverwendbaren Teilwerkzeugen zusammengesetzt
• Komplexe Aufgabe wird von zusammengesetztem Werkzeug durch Delegation an Subwerkzeuge erledigt
• Darstellung es Werkzeugbaums durch Composite

• Ebene: Klassen-, Objektebene
• Zweck: Erzeugungs-, Struktur-, Verhaltensmuster