oosk

Card Set Information

Author:
maddinac
ID:
11419
Filename:
oosk
Updated:
2010-03-21 11:55:59
Tags:
oosk informatik softwarekonstruktion objektorientiert
Folders:

Description:
Lernkarten zur Vorlesung "Objektorientierte Softwarekonstruktion"
Show Answers:

Home > Flashcards > Print Preview

The flashcards below were created by user maddinac on FreezingBlue Flashcards. What would you like to do?


  1. Materialverwaltung
    • Anfragestelle der Werkzeuge für Materialien
    • delegiert an Materialversorger
    • Umgebungsobjekt ermittelt Materialversorger und übergibt sie der Materialverwaltung
    • Anfrage an Materialverwaltung liefert Materialbehälter
  2. Gründe für Klassenbibliotheken
    • Produktivitätssteigerung
    • Qualitätssteigerung
    • Geringer Wartungsaufwand
    • Lernen am guten Beispiel
  3. Feinentwurf
    • Komponentenentwurf
    • Schnittstellenfestlegung
    • Aufruf-/Verwendungsbeziehung festlegen
    • ==> Spezifikation der Komponenten
  4. Grobentwurf
    • Architekturentwurf
    • System in Subsysteme zerlegen
    • Komponenten identifizieren
    • Beziehungen der Komponenten ermitteln
    • Zusammenspiel der Komponenten etablieren
    • ==> Architekturbeschreibung
  5. UML-Diagrammarten
    • Strukturdiagramme
    • Klassendiagramm
    • Objektdiagramm
    • Paketdiagramm
    • Kompositionsstrukturdiagramm
    • Komponentendiagramm
    • Verhaltensdiagramme
    • Use-Case-Diagramm
    • Aktivitätsdiagramm
    • Zustandsdiagramm
    • Interaktionsdiagramme (sind Verhaltensdiagramme)
    • Sequenzdiagramm
    • Kommunikationsdiagramm
    • Timing-Diagramm
    • Interaktionsübersichtsdiagramm
  6. Factory Method
  7. Prozessmodell
    • Vorgehensmodell
    • Aspekte der Projektorganisation
    • Qualitätssicherung
    • Dokumentation
    • Rollen
    • Musterstruktur für Organisation und Durchführung eines SW-Prozessees
  8. Begriffslexikon
    • Begriff
    • Bedeutung
    • Abgrenzung
    • Gültigkeit
    • Bezeichnung
    • Unklarheiten
    • Querverweise
  9. Wie man zu Begriffen kommt
    • Liste aller Hauptwörter
    • Irrelevante Begriffe entfernen
    • Ausprägungen entfernen
    • Vage Begriffe entfernen
    • Synonyme entfernen
    • Merkmale entfernen
    • Dienstleistungen entfernen
    • Beziehungen identifizieren
  10. Parametrisierte Polymorphie
    • Funktion besitzt 1-n Typparameter
    • Zulässige Typen haben selbe Struktur
    • Bsp. generische Funktionen
  11. Universelle Polymorphie
    • Echte Polymorphie
    • Selber Code für alle Argumente des zulässigen Typen
  12. Grundlegende Entwurfsprinzipien
    • 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
  13. Strategy
  14. Rahmenwerk
    • 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
  15. Entwurf
    • Festlegen von
    • Architektur, Komponenten, Schnittstellen
  16. Materialbehälter
    • Konsistenzbedingungsobjekte überwachen Material
    • Abhängige Materialien in Materialbehälter
    • Materialbehälter mit KBO parametrisiert
    • Änderung Material -> Info an MB -> KBO aktualisieren
  17. Varianten der Vererbung
    • Strikt: Erweiterung, Definition
    • Nicht Strikt: Erweiterung, Definition, Redefinition
  18. Composite
  19. Template Method
  20. Iterator
  21. Lehman's first law of software evolution
    Ein System wird sich im Laufe der Zeit ändern oder wird weggeworfen.
  22. Substitutionsprinzip
    • 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.
  23. Subtype Inheritance
    • Generalisierung
    • isA
  24. Wiederverwendung im Allgemeinen
    • WV von SW-Produkten
    • WV von Lösungsstrukturen, Methoden, Sprachen
    • WV von Komponenten des OS, Bibliotheken
  25. Reuse-Team
    • Reuse-Manager: Zieldefinition
    • Reuse-Librarian: zertifiziert, verwaltet
    • Reuse-Engineer: entwickelt, pflegt, berät, schult
    • Reuse- Evaluator: bewertet
  26. Extension Inheritance
    • Es kommen neue Eigenschaften hinzu.
    • Z.B. List<--SortedList
  27. Restriction Inheritance
    • Einschränkung einer Bedingung.
    • Z.B. Rectangle<--Square
  28. View Inheritance
    • Unterklassen B_1...B_n von A spezilisieren A im Sinne von unterschiedlichen Klassifikationsaspekten
  29. Structure Inheritance
    • Oberklasse definiert allgemeine strukturelle Eigenschaft, Unterklasse besitzt diese Eigenschaft
    • Z.B. Printable
  30. Reifaction Inheritance
    • Vergegenständlichung
    • (Abstrakte) Oberklasse A definiert allgemeine Datenstruktur
    • Unterklasse B realisiert Implementierungsalternative
    • Z.B. Sequential Table <-- LinkedListTable
  31. Uneffecting Inheritance
    • Redefinition der Eigenschaften so, dass sie virtuell werden
    • nur bei Mehrfachvererbung
  32. Functional Variation Inheritance
    • Redefinition der Eigenschaften der Oberklasse
    • Keine neuen Eigenschaften
    • Hier: Nur Methodenrumpf redefinieren
    • Z.B: HashTable <-- FastHashTable
  33. Type Variation Inheritance
    • Redefinieren, keine neuen Eigenschaften
    • Hier: Nur Redifinieren der Signaturen
    • Z.B. Employee <-- MaleEmployee
  34. Eigenschaften guter Programme
    • Sauberes Layout
    • Sinnvolle Namen
    • Ausführliche Kommentare
    • Robust
    • Lesbar
  35. Stufen der OO-Sprachen
    • Objekt-basiert: Objekte als Datenkapsel
    • Klassenbasiert: Objekte und Klasse
    • Objektorientiert: Objekte und Klassen und Vererbung
  36. Vorgehensweise der Use-Case-Modellierung
    • Wichtige Use Cases identifizieren
    • Beziehungen zwischen Akteuren und UC identifizieren
    • Beziehungen zwischen UC identifizieren
    • UC in strukturierter Form beschreiben
  37. Use-Case-Level
    • Basisfunktion
    • Benutzerfunktion
    • Top-Level-Funktion
  38. Aufbau von CRC-Karten
    • Class
    • Superclass
    • (Attributes)
    • Responsibilities
    • Collaborators
  39. Bersoff's First Law of System Engineering
    System ändert sich während der Entwicklung
  40. Facility Inheritance
    • 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.
  41. Implementation Inheritance
    Eine Unterklasse B erbt Eigenschaften von A, die ausschließlich verwendetwerden, um die zu B gehörende Abstraktion zu implementieren.
  42. Ad hoc Polymorphie
    • 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
  43. Typanpassung
    • Vorhandenen Typen in erwarteten konvertieren
    • Ohne Anpassung: Typfehler
    • Statisch oder dynamisch
  44. Überladen von Operationen
    • Selber Bezeichner für verschiedene Operationen
    • Unterschiedliche Parametertypen
  45. Inklusionspolymorphie
    • Objekt kann zu mehr als einem Typ gehören
    • Sybtyping ist Form von Inlusionspolymorphie
  46. Entwurfskriterien nach Meyer
    • Zerlegbarkeit
    • Kombinierbarkeit
    • Verständlichkeit
    • Lokalität
  47. Wiederverwendung im engeren Sinn
    • Entscheidung zwischen Wiederverwendung und Neuentwicklung ist gegeben
    • Geplante WV: Komponenten werden mit Ziel WV entwickelt
    • Ungeplante WV: Bereits realisierte Komponenten
  48. Adapter
    • Hier: Objektadapter
    • Klassenadapter: Adapter erbt von Dienst
  49. Prototype
  50. Decorator
  51. Kosten/Nutzen Reuse
    • Kosten
    • Mehraufwand bei Entwicklung
    • Lagerung, Verwaltung
    • Finden, Anpassen, Integration
    • Nutzen
    • Weniger Entwicklingskosten
    • qualitativ besser

    Nutzen > Kosten ab 3x WV
  52. Umgebungsobjekt
    • Realisiert Arbeitsplatz
    • Bindet Arbeitsplatz an externe Dienste an(Materialverwaltung)
    • Erzeugt und koordiniert Werkzeuge(Werkzeugkoordinatoren)
  53. Verteilungsstandpunkt
    • Zeigt, wie Komponenten auf Infrastruktur- und HW-Einheiten abgebildet werden
    • Aufteilung der Entwicklung auf Teams
  54. Dynamischer Standpunkt
    • Darstellung der Zusammenarbeit der Komponenten zur Laufzeit
    • Modellieren Systemverhalten
  55. Statischer Standpunkt
    Sichten zeigen zentrale Komponenten der Architektur, sowie ihre Schnittstellen und Beziehungen
  56. Reengineering-Techniken
    • 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
  57. Reverse-Engineering-Techniken
    • Redocumentation: im selben Abstraktionslevel eine äquivalente Repräsentation bilden
    • Design recovery: Wiederherstellung einer Designabstratktion aus Code, Doku, Erfahrung und Wissen
  58. Symptome schlechten Designs
    • Sehr lange Klassen
    • Duplizierter Code
    • Case-Anweisung auf Typmerkmale
    • Aufwändige Kommentierung
    • Frederic hat programmiert
    • Silivo hat programmiert
    • Christoph hat programmiert
    • Yannick hat programmeirt
  59. Werkzeugkopplung
    • Werkzeugbaum wird durch Funktionskomponenten gebildet
    • Kontext-Interaktionskomponente muss nicht mit Sub-Interaktionskomponente zusammenarbeiten
    • Kontext-IAKen und FKen beobachten Sub-FKen
  60. Vorgehensmodell
    • Definieren wie prinzipiell SW entwickelt wird
    • Wasserfallmodell
    • Prototyping
    • Spiralmodell
    • etc.
  61. Kopplung von Material und Werkzeug
    • Material erbt Aspektschnittstellen
    • Werkzeuge nutzen ausschließlich Aspekte
  62. Systemstandpunkt
    Sichten zeigen, wie das zu entwickelnde System in die Umgebung eingebettet ist
  63. Programming by Contract (Java)
    Zusicherung spez. Vor- und NachbedingungenAufrufer muss Vorbedingungen einhaltenAnbieter muss Nachbedingungen garantierenInvariante dauerhaft gültig
  64. Lokal korrekte Klasse A
    • 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
  65. Use-Case-Beschreibung
    • ID
    • Goal
    • Classification
    • Precondition
    • Postcondition
    • PC on error
    • Actors
    • Trigger
    • Mainflow
    • Deviations
  66. Unification
    • Hook und Template-Methoden in einer Klasse
    • User UK überschreiben hook-Methode
    • Kein Wechsel des Verhaltens zur Laufzeit
  67. Dimensionen der Wiederverwendung
    • Einsatzspektrum: vertikal, horizontal
    • Anpassung: White-Box, Black-Box
    • Technik: neutral, spezifisch
    • Funktionalität: anwendungsspezifisch, anwendungsneutral
  68. Analysemethode
    • SW-Entwurfsmethode in Analyse um Anforderungen
    • vollständig
    • widerspruchsfrei
    • präzise
    • zu definieren
  69. Werkzeugkoordinator
    • 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
  70. Trennung von Interaktion und Funktion
    • Sichern Konsistenz zwischen abhängigen Materialien
    • Materialverwaltung kennt alle Klassen, die KBO realisieren
    • Strategie zur Korrektur von Inkonsistenzen muss implementiert werden
    • Rein algorithmisch
  71. Methodensuche
    • 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
  72. Statische Typierung und dynamischen Binden
    • 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
  73. Kontravarianz / Kovarianz
    • 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.
  74. Stufen der Kopplung
    • 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
  75. Stufen der Kohäsion
    • 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
  76. Open-Closed Prinzip
    • Geschlossen: Schnittstelle ist vollständig und ändert sich nicht mehr.
    • Offen: Modul kann problemlos erweitert werden
    • Lösung durch Vererbung
  77. Entwurfsregeln
    • Direkte Abbildung von Anwendungsbereichstruktur auf SW-Struktur
    • Wenige Schnittstellen
    • Kleine Schnittstellen
    • Explizite Schnittstellen
    • Geheimnisprinzip
  78. Schichten - Vorteile
    • 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
  79. Schichten - Nachteile
    Evtl Performanceeinbußen durch Durchreiche-Operationen
  80. Arten von Schichten
    • 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
  81. Kompositionsstrukturdiagramm
    • Ausgangspunkt sind Kompositionen
    • Classifier besteht aus Parts, die mit Konnektoren verbunden sein
    • Ports (evtl mit Rollennamen) beschreiben Schnittstellen zwischen Parts oder Classifiern
  82. Defensives Programmieren
    • 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
  83. Typische Probleme von Legacy Systemen
    • Entwickler sind nicht verfügbar
    • Entwicklungsmethoden inzwischen veraltet
    • System ist seit Entwicklung heftig modifiziert worden
    • Dokumentation fehlt
    • Wartung ist teuer
  84. Kompositionsmuster
    • Interpretation und Gestaltung von tatsächlichen Anwendungssituationen und SW-Systemen
    • Interpretation und Erfassung der Anwendungswelt
  85. Umgebung
    • Stellt fachliche Abhängigkeiten zwischen Materialien und deren Konsistenz sicher
    • Kontrolliert ob Anwendung eines Werkzeugs auf ein Material möglich ist
  86. Werkzeugkomposition
    • Werkzeuge werden aus wiederverwendbaren Teilwerkzeugen zusammengesetzt
    • Komplexe Aufgabe wird von zusammengesetztem Werkzeug durch Delegation an Subwerkzeuge erledigt
    • Darstellung es Werkzeugbaums durch Composite
  87. Entwurfsmuster - Klassifikation
    • Ebene: Klassen-, Objektebene
    • Zweck: Erzeugungs-, Struktur-, Verhaltensmuster

What would you like to do?

Home > Flashcards > Print Preview