OOSK

Home > Preview

The flashcards below were created by user Anonymous on FreezingBlue Flashcards.


  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
    Image Upload
  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
    Image Upload
  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
    Image Upload
  19. Template Method
    Image Upload
  20. Iterator
    Image Upload
  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 , 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
    • Image Upload
  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
    • Geplante WV: Komponenten werden mit Ziel WV entwickelt
    • Ungeplante WV: Bereits realisierte Komponenten
  48. Adapter
    • Image Upload
    • Hier: Objektadapter
    • Klassenadapter: Adapter erbt von Dienst
  49. Prototype
    Image Upload
  50. Wiederverwendung im engeren Sinn
    Image Upload
  51. Decorator
    Image Upload
  52. Kosten/Nutzen Reuse
    • Kosten
    • Mehraufwand bei Entwicklung
    • Lagerung, Verwaltung
    • Finden, Anpassen, Integration
    • Nutzen
    • Weniger Entwicklingskosten
    • qualitativ besser

    Nutzen > Kosten ab 3x WV
  53. Umgebungsobjekt
    • Realisiert Arbeitsplatz
    • Bindet Arbeitsplatz an externe Dienste an(Materialverwaltung)
    • Erzeugt und koordiniert Werkzeuge(Werkzeugkoordinatoren)
  54. Verteilungsstandpunkt
    • Zeigt, wie Komponenten auf Infrastruktur- und HW-Einheiten abgebildet werden
    • Aufteilung der Entwickler auf Teams
  55. Dynamischer Standpunkt
    • Darstellung der Zusammenarbeit der Komponenten zur Laufzeit
    • Modellieren Systemverhalten
  56. Statischer Standpunkt
    Sichten zeigen zentrale Komponenten der Architektur, sowie ihre Schnittstellen und Beziehungen
  57. 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
  58. Reverse-Engineering-Techniken
    • Redocumentation: im selben Abstraktionslevel eine äquivalente Repräsentation bilden
    • Design recovery: Wiederherstellung einer Designabstratktion aus Code, Doku, Erfahrung und Wissen
  59. 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
  60. Werkzeugkopplung
    • Werkzeugbaum wird durch Funktionskomponenten gebildet
    • Kontext-Interaktionskomponente muss nicht mit Sub-Interaktionskomponente zusammenarbeiten
    • Kontext-IAKen und FKen beobachten Sub-FKen
  61. Vorgehensmodell
    • Definieren wie prinzipiell SW entwickelt wird
    • Wasserfallmodell
    • Prototyping
    • Spiralmodell
    • etc.
  62. Kopplung von Material und Werkzeug
    • Material erbt Aspektschnittstellen
    • Werkzeuge nutzen ausschließlich Aspekte
  63. Systemstandpunkt
    Sichten zeigen, wie das zu entwickelnde System in die Umgebung eingebettet ist
  64. Programming by Contract (Java)
    Zusicherung spez. Vor- und NachbedingungenAufrufer muss Vorbedingungen einhaltenAnbieter muss Nachbedingungen garantierenInvariante dauerhaft gültig
  65. 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
  66. Use-Case-Beschreibung
    • ID
    • Goal
    • Classification
    • Precondition
    • Postcondition
    • PC on error
    • Actors
    • Trigger
    • Mainflow
    • Deviations
  67. Unification
    • Hook und Template-Methoden in einer Klasse
    • User UK überschreiben hook-Methode
    • Kein Wechsel des Verhaltens zur Laufzeit
  68. Dimensionen der Wiederverwendung
    • Einsatzspektrum: vertikal, horizontal
    • Anpassung: White-Box, Black-Box
    • Technik: neutral, spezifisch
    • Funktionalität: anwendungsspezifisch, anwendungsneutral
  69. Analysemethode
    • SW-Entwurfsmethode in Analyse um Anforderungen
    • vollständig
    • widerspruchsfrei
    • präzise
    • zu definieren
  70. 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
  71. 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
  72. 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
  73. 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
  74. 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.
  75. 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
  76. 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
  77. Open-Closed Prinzip
    • Geschlossen: Schnittstelle ist vollständig und ändert sich nicht mehr.
    • Offen: Modul kann problemlos erweitert werden
    • Lösung durch Vererbung
  78. Entwurfsregeln
    • Direkte Abbildung von Anwendungsbereichstruktur auf SW-Struktur
    • Wenige Schnittstellen
    • Kleine Schnittstellen
    • Explizite Schnittstellen
    • Geheimnisprinzip
  79. 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
  80. Schichten - Nachteile
    Evtl Performanceeinbußen durch Durchreiche-Operationen
  81. 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

Card Set Information

Author:
Anonymous
ID:
11346
Filename:
OOSK
Updated:
2010-03-20 18:07:20
Tags:
oosk objektorientierte softwarekonstruktion informatik
Folders:

Description:
Lernkarten zur Vorlesung Objektorientierte Softwarekonstruktion
Show Answers:

Home > Flashcards > Print Preview