Wednesday, November 30, 2005

Ende ;-)

Hinweis: Die Vorlesung ist nur ein Ausschnitt aus dem großen Gebiet Software Engineering und erhebt keinen Anspruch auf Vollständigkeit.
Für Hinweise, Anregungen und Kritik bin ich stets offen und können Sie richten an:

Thomas.Schrader@computer.org

Nachtrag: Begriffe, immer wieder auftauchen

. Schnittstelle - (interface): Schnittstellen definieren für den Anwender Dienstleistungen. In einer funktionalen Abstraktion werden Operationssignaturen (Namen der Operationen) bereitgestellt, die nur festlegen, was getan werden soll, aber nicht das wie. Ein Schnittstelle ist eine Klasse, die keine Attribute besitzt sondern abstrakte Operationen.
. abstrakte Klasse - von einer abstrakten Klasse kann es keine Objekte geben. Sie wird nur deshalb modelliert, damit sie ihre Eigenschaften und Operationen an spezialiserte Klassen weitervererben kann.

Zusammenfassung


Mit UML ließ sich auch endlich der Computer selbst für die Programmierung gut einsetzen, dem grafische Entwicklungstools zur Verfügung stellt wurden - Computer Aided Software Engineering (CASE-Tools).

Was zum Üben


Wenn Sie Ihre Ausarbeitungen mir zusenden, schaue ich sie mir gerne durch - email s.u.

Aus OOA wird OOD


Während in der OOA überlegt werden muss, WELCHE Prozesse abgebildet werden müssen, um einen Use Case zu realisieren und den Business Case zur Anwendung zu bringen, geht es beim OOD vor allem um die Frage des WIE.
Dabei haben sich verschiedene Vergehensweisen bewährt:

1. Neuorganisation der Klassenstruktur - Pakete
Zusammenfassen der Klassen nach:
.1 Verfahrensklassen - enthalten im wesentlichen Algorithmen
.2 Control-Klassen - Koordinieren die Zustände
.3 Representation-Klassen - Klassen, die mit der GUI zu tun haben
.4 Subject-Klassen - alle übrigen Klassen

2. Anwendung von Design Pattern
Das Rad muss nicht mehrmals erfunden werden. Für fast alle Probleme gibt es vorgefertigte Lösungen.
Wiederverwendbare Design Pattern enthält die einzelnen Klassen und deren Zusammenspiel, im Gegensatz zu einer reinen Klassenbibliothek. Besteht ein Pattern aus mehreren Klassen so existiert eine Art Protokoll darüber, wie die Kommunikation zwischen den Klassen funktioniert (gegenseitige Methodenaufrufe, Ereignisse in bestimmter Reihenfolge).
Es gibt zwei Rollen der verwendeten Klassen:
.1 Model-Klassen
.2 Dependents - Klassen, die sich vollständig aus den Model-Klassen ableiten. Ein Aktualisierungsmechanismus sorgt dafür, dass Zustände der Model-Klasse konsistent in den Dependents gehalten werden.

Design Pattern:
..1 Observer - findet Anwendung in den Repräsentionsklassen
..2 Delegation - Die Model-Klasse wird Aggregatklasse genannt, die Dependent-Klasse Komponenten-Klasse. Die Aggregatklasse leitet alle Aufrufe an die Komponentenklassen weiter (z.b. Resize eines Screens - automatische Weiterleitung an andere Bildschirmelemente: Button, ListBox u.a.
..3 Iterator - dient zur elementweisen Verarbeitung von Collections (Aufzählungen, Mengen, Listen über eine abstrakte Schnittstelle
..4 Composite - besteht aus einem
...1 Element mit Deklaration eines bestimmten Funktionsumfanges und Protkoll nach außen
...2 Basiselement (Blatt) mit Implementierung der Fuktionalität
...3 Gruppe mit Speicherung und Verwaltung aller zugeordneten Elemente und Delegation der Messages
..5 Strategie (Policy) - eine Steuerklasse (Mediator) als Schnittstelle übernimmt die Modellierung von verschiedenen Verfahrensweisen einer Operation

OOA & OOD

State Chart - Zustandsdiagramm - Objekt case:Case

Am Beispiel eines Falles, welche unterschiedlichen Zustandformen er einnehmen kann, läßt sich der Aufbau eines State Charts gut darstellen.

.1 Anfangszustand
.2 Zustandsübergang (Transition)
.3 Ereignis
.4 interner Übergang ohne Änderung des Zustands
.5 Endzustand

Collaboration Diagram


Notiz zum Sequenzdiagramm

Darstellung des zeitlichen Verlaufs des Nachrichtenaustauschs - Sequenzdiagramm


.1 Objekte mit Objektlinien
.2 Objekte werden erzeugt
.3 Botschaft
.4 Objekt schickt Botschaft an sich selbst

Einige Hinweise zum Erstellen eines Aktivitätsdiagramms

Aufspaltung und Zusammenführung in verschiedenen Möglichkeiten

Activity Diagram .Use Case CreateCase


.5 Aufspaltung mit Synchronisationsbalken
.6 Zusammenführung
.7 Endzustand

Activity Diagram .Use Case: Create Case



.1 Anfangszustand
.2 Aktivität
.3 Kontrollfluss (Trigger)
.4 Verzweigung - Entscheidungspunkt mit guard conditions
.5 Verantwortlichkeitsbereich - swin lane

Verwendete Klassen

Use Case: Fall erstellen (Create Case)



Use Cases des Business Case

Business Case: T.Konsult

Klasse, Attribute, Operationen, Objekte




Deployment View

Component View

Logical View

Use Case View

Sichten der UML

Business Case


Ausgangspunkt eines Softwareentwicklungsprozesses ist der Business Case: Was soll die Software eigentlich können. Das sollte möglichst genau beschreiben werden.
Damit die zu entwickelnde Software auch funktioniert, aber und vor allem akzeptiert wird, ist es notwendig, sich den Business Case von unterschiedlichen Perspektiven anzuschauen.

Objektorientiert


Im weiteren Verlauf konzentieren sich die Ausführungen auf die Objektorientierte Analyse und das Design. Objektorientierung in der Softwareenticklung bedeutet, dass bestimme Paradigmen genutzt werden, die es der Programmierung davor so nicht gab. Die Grundprinzipien haben sich als so nützlich und wirksam erwiesen, dass damit mit größerer Flexibilät eine Entwicklung durchgeführt, vor allem aber durch die mögliche Wiederverwendung die Entwicklungskosten gesenkt werden konnten.
Seit ca. 1979 wird die Objektorientierung in den Programmiersprachen angewandt (beginnend mit Smalltalk).
Software-Systeme wurden immer komplexer, so dass es notwendig wurde, Modelle und Beschreibungen zu finden, die ein System beschrieben. Januar 1997 wurde von den drei Amigos (Booch, Rumbaugh, Jacobson) führten Ihre Notationen zur Objektorientierten Entwicklung zusammen und es entstand Unified Modelling Language V 1.0.

Der Anfang


Die Vorlesung beschäftigt sich mit dem Thema Dynamik in der Software-Entwicklung. Eigentlich ist das ja ein Problem, welches sich wie ein roter Faden durch den Software-Entwicklungsprozess zieht. Nicht nur die Wünsche und Ziele ändern sich, sie sind dynamisch, Software an sich soll etwas verändern. Sie hat eine Aufgabe zu erfüllen.

Tuesday, November 01, 2005

Objektorientierte Analyse und Design

Hier finden Sie den Inhalt der Vorlesung "... sie bewegt sich - Modellierung von Verhalten und Dynamik in der objektorientieren Analyse und Design", gehalten an der FH Stralsund, am 1. Dezember 2005.

Wer von den Zuhörern die Vorlesung kommentieren oder ergänzen möchte, schicke mir bitte eine eMail, damit ich einen Account einrichten kann.

Herzliche Grüße

Dr. Thomas Schrader
thomas.schrader@computer.org