17586947
| Pregunta | Respuesta |
| Wozu eignen sich Zustandsdiagramme besonders | Darstellen von Abhängigkeiten und logischen Programmflüssen |
| Fragile Baseclass Problem | wenn Änderungen an der Basisklasse die Spezialisierungen zerstört. Die Entwickler trafen unterschiedliche Annahmen und verlassen sich auf Abhängigkeiten ein, die nicht spezifiziert sind. |
| Wozu eignen sich Kommunikationsdiagramme? | Ist ähnlich einem Sequenzdiagramm, aber mit weniger Struktur. Die Kommunikation zwischen den Objekttypen und damit die Schnittstellen können sehr gut visualisiert werden. |
| Wozu eignen sich Kommunikationsdiagramme nicht? | Spezifizierung von Vor- oder Nach-Bedingungen. Rückgabewerte werden nicht angegeben. Schwierig zu lesen bei vielen Interaktionen zwischen zwei Objekten |
| Wie unterscheiden sich logische Sicht und Entwicklersicht? | Die logische Sicht zeigt die Objekte & Beziehungen zur Laufzeit. Also auch, ob LRG gut umgesetzt ist. Die Entwicklersicht zeigt die dafür nötigen Klassen & Beziehungen. Also auch, welche zusammen benötigt werden. |
| Was ist Responsibility Driven Design? | Eine Entwurfsmethode, die für jede der vom System wahrzunehmende Verantwortung ein geeignetes Objekt einführt. Der Entwurf wird getrieben durch die Suche nach Verantwortungsträgern. |
| Welche Typen von Verantwortung unterscheiden wir im RDD? | Creator: Erstellt Objekte Controller/Coordinator: Koord. Abläufe, führt Aktionen anderer Objekte aus Information Expert: Speichert/Berechnet Informationen & stellt sie zur Verfügung |
| Was heisst contra-Varianz? | contra-Varianz akzeptiert Supertypen, wo ein Subtyp spezifiziert ist. Parameter dürfen contra-variant sein, Return-Werte nicht (Liskov) |
| Was heisst co-Varianz | co-Varianz aktzeptiert einen Subtyp, wo ein Supertyp spezifiziert ist. Return-Werte dürfen co-Variant sein, Parameter nicht (Liskov) |
| Was steht im 4+1 Architectural View Model | 4 Sichten auf SW-Architekturen: Logical (Enduser), Development (Programmer), Process (Functional Req, concurrency), Physical (Mapping auf HW). Und Scenarios der Anforderungen. |
| Was sagt das Open / Closed Prinzip | Dass man die Implementierung nicht ändern, sondern nur erweitern darf. Vererbung verwenden anstatt auf konkrete Eigenschaften eines Objekts abzufragen. Grosse Code-Blöcke aufteilen. |
| Was sagt das Dependency Inversion Prinzip? | Es sollte keine Abhängigkeiten zu konkreten Implementierungen geben, sondern nur zur Abstraktion. Dependency Injection folgt diesem Prinzip |
| Was sagt das Liskov-Prinzip? | Dass Subtypen alle für den Supertyp gültigen Bedingungen erfüllen müssen. |
| Was ist das Prinzip "Low Representational Gap" und wie wird es umgesetzt? | Ein Grundprinzip das die Analysierbarkeit von Programm-Code fördert, da dieser den Erwartungen aus der Realität entspricht. Domain Driven Design hilft dieses einzuhalten. |
| Was ist das Interface Segregation Prinzip? | Auf die einzelnen Anforderungen abgestimmte kleine Schnittstellen sind besser als eine grosse. |
| Was sind die grundlegenden Aussagen eines Box-and-Arrow Diagramms | |
| Was sind die Hauptunterschiede zwischen ERM-Entwurf und Klassendiagramm? | Relationales Modell erlaubt mehrere Konkretisierungen gleichzeitig, diese Rollen können einfach hinzugefügt und entfernt werden, allenfalls kann eine Person eine Rolle mehrfach haben. |
| Wie implementiert man Klassen, dass sie gemeinsam die im Entwurf dokumentierten Szenarien ausführen können? | Operationen, die ein Objekt auf einem anderen auslösen soll, müssen public sein. Beziehungen zwischen Objekten verlangen nach entsprechend gespeicherten Referenzen, z.B., in Instanzvariablen. |
| Was sagt das Single Responsibility Prinzip? | Dass jede Klasse nur eine Aufgabe und damit nur einen Grund zur Änderung der Implementierung haben soll. Responsibility Driven Design hilft bei Umsetzung. |
| Was ist GRASP? | SW Pattern zur Zuweisung von Verantwortungen: Creator, Controller/Coordinator, Information Expert |
| Unterschied zwischen Variation Point und Extension/Evolution Point | Variation Point: Varianten, die sicher zukünftig oder bereits jetzt benötigt werden Evolution Point: Spekulativ, eventuell zukünftig benötigte Varianten |
| Nachteile einer zu offenen (und komplexen) Architektur | Mehr Aufwand für - Laufzeit - Programmieren und Dokumentation - Einarbeitung - Veränderungen - Wartung |
| Was ist der Unterschied zwischen Sub-Typing und Sub-Classing | Subclassing: Code inheritance vs. Subtyping: Is-a-Relation, Polymorphismus |
| Aufgabe Microservices: Was sind Vor-/Nachteile wenn die Schnittstelle nur Tripel (Zeit, Temperatur, Drehzahl) zurückgeben kann? | - Einfache Schnittstelle - Für diverse Aufgaben nutzbar - Mehr Daten müssen übertragen werden, da Berechnungen beim Client erfolgen - Interface Segregation Prinzip verletzt? |
| Aufgabe Microservices: Warum nicht direkt SQL-Abfragen erlauben? | - Grössere Missbrauchsmöglichkeiten - Die interne Struktur muss offengelegt werden (-> Information Hiding verletzt) - Spätere Änderungen kaum möglich |
| Berechnung der Wirtschaftlichkeit: Entwicklung: 60 unvorbereitete Integration: 30 Entwicklung Schnittstelle heute: 15 Integration an Schnittstelle: 2 Wahrscheinlichkeit Bedarf p=0.3 | Kosten unvorbereitet: (60+30) * 0.3 = 27 Kosten vorbereitet: 15 + (60+2) * 0.3= 33.6 |
| DesignForExtension Regel | Alle nicht-privaten, nicht-statischen Methoden müssen abstract, final oder leer implementiert sein |
¿Quieres crear tus propias Fichas gratiscon GoConqr? Más información.