Subsysteme und MVC: Architektur‑Design, Produkte und Kriterien

11) Große Schritte im OO-Design

In OO-Design sind zu Beginn der Planungsphase zwei große Schritte notwendig. Was sind sie und welche Produkte werden erzeugt?

Der erste Schritt besteht darin, das Domain-Problem und das Verhalten einer Organisation zu analysieren und dann eine Unterteilung in Pakete vorzunehmen, wobei die Pakete mit Stereotypen versehen werden. Wenn dieser Ansatz das Problem in der Domäne annimmt, ist damit der erste Schritt getan: die Partition des Analysemodells zu definieren. Zusammenhängende Sammlungen von Klassen, Beziehungen und Verhaltensweisen werden zu Paketen oder Subsystemen gebündelt.

Wichtig!

Ein Subsystem hat eine gut definierte Schnittstelle, über die die gesamte Kommunikation mit dem Rest des Systems erfolgt. Abgesehen von einer kleinen Anzahl von Klassen, die mit anderen Subsystemen kommunizieren, sollten Klassen innerhalb eines Subsystems nur mit anderen Klassen desselben Subsystems zusammenarbeiten. Die Anzahl der Teilsysteme sollte klein gehalten werden.

Der zweite Schritt besteht darin, für jedes Subsystem die Klassen nach der Art der Funktion zu gruppieren, die sie im System erfüllen, das heißt nach ihrem Stereotyp.

12) Wichtige Produkte des Architekturprojekts

Das architektonische Design ist das Zuweisungsmodell der grundlegenden Anforderungen an eine bestimmte Technologie. Es legt fest, welche Prozesse auf welchen Prozessoren laufen, wo Daten gespeichert werden und wie viel Kommunikation zwischen Prozessoren erforderlich ist.

Zu den wichtigsten Produkten gehören:

• Die geografische Verteilung der berechnungsbezogenen Anforderungen
• Hardware-Komponenten auf Client-Rechnern
• Hardware-Komponenten auf Server-Maschinen
• Konfiguration und Anzahl der Hardware-Schichten im Client-Server-Modell
• Die Software-Plattform für die Umsetzung, einschließlich Programmiersprachen und Präsentationsschicht (Benutzerschnittstelle), Betriebssysteme, Middleware, Kommunikationsmechanismen und Netzwerk-Systeme
• Der Datenbank-Manager
• Der Ort oder die Orte der Dateien
• Örtlichkeiten und physische Repräsentation von Daten
• Strategien zur Datensynchronisation bei geografischer Verteilung

13) Kriterien bei Konstruktion von Subsystemen

• Projektschnittstellen
• Kupplung (Coupling)
• Architekturstil
• Wartbarkeit
• Wiederverwendbarkeit (Komponenten und Standards)

14) Architekturmodell MVC

Das MVC-Modell (Model-View-Controller) trennt vorwiegend Daten und Geschäftslogik (Model), die Benutzeroberfläche (View) sowie den Fluss der Anwendung (Controller).

Die Idee ist, dass dieselbe Geschäftslogik über verschiedene Schnittstellen abgerufen und betrachtet werden kann. In der MVC-Architektur weiß die Geschäftslogik (das Modell) nicht, wie viele oder welche Benutzeroberflächen ihren Zustand anzeigen. Aufgrund der heute vorhandenen Vielzahl von Schnittstellen ist MVC ein wesentliches Instrument zur Entwicklung von Systemen.

„Die Geschäftslogik sollte nichts darüber wissen, wie ihr Zustand auf dem Bildschirm angezeigt wird!“

Die Anwendung ist in drei Teile gegliedert:

• Model (Modell): Geschäftslogik
• View (Ansicht): Schicht der Benutzeroberfläche; in dieser Schicht sieht der Benutzer den Zustand des Modells und bedient die Schnittstelle, um die Geschäftslogik zu nutzen
• Controller (Steuerung): Wandelt Ereignisse aus der Schnittstelle in Aktionen für die Geschäftslogik und verändert das Modell

15)