Architekturentwurf und Architekturmodellierung Flashcards
Ziele des Architekturentwurfs
Ziele des Architekturentwurfs:
1. Entwurf eines klar strukturierten Systems mit einem tragfähigen
Komponentenmodell und expliziten, schlanken Schnittstellen.
2. Entwurf einer durchgängigen Architektur mit explizit gewählten Stilen
und Mustern.
3. Dokumentation einer Architektur, die eine kontinuierliche
Qualitätssicherung zur Sicherstellung der Problemangemessenheit und
der Überprüfung der Auswirkungen von Änderungen ermöglicht.
Iterativ-Inkrementeller Architekturprozess
- Analyse des Kontexts und der Anforderungen
- Entwicklung von Architektursichten und technischen Konzepten
- Evaluierung von Architektur- und Entwurfsentscheidungen
- Überwachung und Überprüfung der Architekturrealisierung
=> 1.
Datenmodellierung im Systementwurf
Analyse -> Modellierung als UML-oder ER-Modell -> Umwandlung von UML zur ER-Modell -> Nutzung der Datenmodelle im Entwurf und der Implementierung des Systems
Analyseklassen
Notation: UML
Objekte: Faachgegenstände
Klassen: Fachbegriffe
Vererbung: Begriffsstruktur
Annahme perfekter Technologie
Funktionale Essenz
Grobe Strukturskizze
Entwurfsklassen
Notation: UML
Objekte: Softwareeinheiten
Klassen: Schemata
Vererbung: Programmableitung
Erfüllung konkreter Rahmenbendingungen
Gesamtstruktur des Systems
Genaue Strukturdefinierung
Data-Driven Design (DDD)
- Welche Daten müssen im System repräsentiert werden?
- Ausgehen von Analyseklassen
-> Noun Identification - Sammeln aller für das System relevanten Daten
Objekte der Domäne
Rollen
Ereignisse
Ein- und Ausgabeobjekte von Aktivitäten - Aufteilung der Daten auf Klassen, die sie repräsentieren
- Anschließend Zuordnung von Verantwortlichkeiten
zur Realisierung der Systemfunktionen
Responsibility-Driven Design (RDD)
- Wie werden die Verantwortlichkeiten verteilt?
- Ausgehen von Sammlung der Systemfunktionen
funktionale Anforderungen
Use Cases, deren Abhängigkeiten und Prioritäten
abgeleitete Systemaufgaben - Aufteilung der Verantwortlichkeiten auf Klassen
- Faustregel: maximal drei Verantwortlichkeiten pro Klasse
-> sonst Klasse aufteilen!
CRC-Cards
- Class
- Zugeordnete Verantwortlichkeiten (Responsabilies), realisiert durch Operationen
- Collaborators: Klassen die an der Realisierung der Verantwortlichkeiten beteiligt sind
Inkrementelle Modellierung
Iterative Verfeinerung der Datenmodelle
- Finden beteiligter Klassen
- schrittweises Hinzufügen von Assoziationen
- schrittweises Hinzufügen von Attributen und Operationen
- schrittweises Hinzufügen von Multiplizitäten, Navigierbarkeiten etc.
Refactoring:
- Veränderung der Modelle (oder von Code),
- ohne das sichtbare Verhalten zu beeinflussen, z.B.
- Neuzuordnung von Operationen, Assoziationen etc.
- Beseitigung von überlappenden Verantwortlichkeiten
-> Abstraktionen (Auslagern in gemeinsame abstrakte Oberklasse)
-> lose Kopplung der Klassen!
8 Goldenen Regeln für Interface Design
- Strebe nach Konsistenz
- Strebe nach universeller Bedienbarkeit
- Biete informatives Feedback an
- Gestalte Dialoge so, dass sie zu einem Abschluss führen
- Verhindere Fehler
- Erlaube die Umkehrung von Aktionen (“undo”)
- Gib dem Nutzer das Gefühl der Kontrolle
- Reduziere die Belastung für das Kurzzeitgedächtnis
Mock-UI
Simulierte Benutzeroberflächen, die die visuellen und interaktiven Aspekte der Software darstellenm aber ohne tatsächliche Funktionalität
Was ist zu beachten bei der Modellierung von Nutzungsschnittstellen?
Design-Richtlinien (”User Interface Design Guidelines”)
- Richtlinien für die Gestaltung von grafischen Benutzungsschnittstellen
- Fördern Konsistenz der Benutzeroberflächen, damit die Nutzer sich zurechtfinden
Formular-basiertes Arbeiten
- “Page Flow” für komplexe Anwendungen
- Legt fest, wie Dialoge und Formulare aufeinander aufbauen und wie zwischen diesen navigiert wird
Multimodale Nutzungsschnittstellen
- Unterstützung unterschiedlicher Eingabekanäle (z.B. Tastatur, Maus, Sprache) und
Ausgabekanäle (z.B. Text, Sprache)
Datensicherheit und Datenschutz (Architekturentwurf)
Datensicherheit:
- Datensicherung
- Maßnahmen zum Schutz von Daten bei hrer Bearbeitung
- Sicherstellung von Vertraulichkeit, Integrität und Verfügbarkeit
Datenschutz:
- Maßnahmen zur Verhinderung unerwünschter Folgen bei der Bearbeitung, Speicherung und Löschung von Daten
- Sicherstellung der Zugriffssicherheit
- Schutz vor unbefugtem Zugriff durch Dritte
Fehlerbehandlung
- Softwaresysteme müssen nicht nur bei korrekter Bedienung zuverlässig reagieren
- Fehlerhafte Eingaben oder unsach- gemäße Bedienung sollen nicht zu
Systemzusammenbruch oder unerwünschten Datenverlusten führen - Robuste Syteme betreiben Ausnahme- oder Fehlerbehandlung, um kontrolliert zu reagieren
- Softwarearchitektur sollte Konzeption einer umfassenden
Fehlerbehandlung enthalten, idealerweise in ausschließich dafür
zuständiger Komponente
Der Grobentwurf
Der Grobentwurf: Entwicklung der Systemarchitektur
* Zerlegung des Systems in Komponenten und Beschreibung ihrer
Schnittstellen
Unterscheiden:
- Black-Box-Sicht (Außensicht): Nur die Schnittstelle der Komponente nach außen wird angegeben, die Realisierung ist nach außen hin verborgen.
- White-Box-Sicht (Glas-Box oder Innensicht): Die Realisierung der Komponente (interner Aufbau) wird betrachtet.
+++
* Der Komponentenentwurf folgt dann den gleichen Prinzipien wie der
Systementwurf
