Editing Informatiker FA M222 Zusammenfassung

= OO-Grundlagen =

== Was heisst modellgetriebene Architektur (MDA) ==

MDA ist eines der grossen Themen bei OMG (www.omg.org). Das Ziel von OMG ist es , mittels MDA die Geschäftslogik von der darunter liegenden Technik zu entkoppeln

*Systeme sollen klug durchdacht werden
*System in Modellen darlegen
*Jedes Modell adressiert eine bestimmte Thematik und die Modelle bauen aufeinander auf.
*Im Idealfall kann das ganze System als Modell beschrieben und dann mit einem Generator erstellst werden.
*'''Wichtiger Anspruch''': Modell muss durch Mensch und Maschine gelesen werden können.


MDA Modellebenen:
*M3: Metadatenebene
*M2: Beschreibung der Sprache oder Notation
*M1: Hier modelliert der Entwickler
*M0: Ebene der Laufzeitinstanzen


Um die einzelnen Modelle als XMI speichern zu können, entwickelte die OMG die XMI. XMI = gemeinsames Format für Import- und Export unterschiedlicher Tools.

'''Modelltransformationskette:'''

[[Image:Modelltransformationskette.gif]]

*'''CIM-Modell''' (Computational Independent Modell): enthält vor allem die fachlichen Anforderungen (unabhängig von der Technik)
*'''PIM''' (Plattform Independent Modell): bildet vor allem das Analysemodell unabhängig von der zukünftigen Plattform
*'''PSI''' (Platform Specific Implementation): repräsentiert den eigentlichen Code
*'''PM''' (Platform Model) beschreiben die Quell- und Zielplattform als Metamodelle und die dazugehörenden Transformationsregeln.  Damit z.B. eine Klasse aus dem Fachklassenmodell eine Tabelle im physischen Datenmodell ergibt.


Eine Transformation von Modellen bzw. Code-Generierung heisst '''Forward-Engineering'''. Wenn aus dem Code ein Design-Modell erstellt wird, heisst dies '''Reverse-Engineering'''.


== Welches sind die Grundelemente von OO? ==

=== Das Objekt ===

*Ein Objekt ist immer einmalig und hat somit eine klare Identität.  (auf Programmebene eindeutig durch die Speicheradresse identifiziert)
*Ein bestimmtest laufendes Exemplar eines Objektes entspricht einer Instanz
*Objekte haben Eigenschaften (Attribute), Methoden (Funktionen)
*können auf Ereignisse (Events) reagieren.
*Objekte können Nachrichten austauschen

[[Image:222-1.gif]]

*Zugriffsmöglichkeiten sind klar geregelt
*Alle sichtbaren (public) Methoden bilden die '''Schnittstelle''' gegenüber der Umwelt
*Das Verbergen der inneren Funktionsweise wird '''Kapselung''' (Encapsulation) genannt.


Ein Objekt hat eine definierte Lebensdauer (Life-Cycle):
*Geburt: Kreieren (Instantiieren, Create) eines Objektes
*Leben: eine aktive Instanz
*Tod: zerstören (Destroy) des Objektes

=== Die Klasse ===

*Die Verallgemeinerung wird '''Klasse''' genannt.
*Im Modell  wird eine Generalisierung der gleichartigen Objekte vorgenommen, womit die Klassen entstehen


[[Image:222-3.gif]]


*Klassen wiesen untereinander Beziehungen auf.
*Die Beziehungen werden Assoziation genannt und beschreiben den Kardinalität (Multiplizität) zwischen der Menge der Objekte

Im folgenden Beispiel hat eine Firma mindestens einen Mitarbeiter, kann aber auch beliebig viele haben.

[[Image:222-4.gif]]

'''Umgekehrte Richtung''': Ausgehend von der Oberklasse vererben sich die Eigenschaften und Methoden auf die Unterklasse. Dabei handelt es sich um eine '''Spezialisierung''', da die Unterklasse eine immer speziellere Ausprägung ausweist.

[[Image:222-5.gif]]

*Klassen welche nicht mehr weiter generalisiert sind, werden Basisklasse, Wurzelklasse oder RootClass genannt.
*übergeordnete Klassen werden Oberklasse (Superclass) oder Vaterklasse genannt.
*Spezialisierte Klassen sind Unterklassen oder Sohnklassen (Childclass)

Klassen bei denen keine Instantiierung von Objekten erlaubt sind, sind abstrakte Klassen. 

'''Binding''':
*Statisches Binding: Der methodenaufruf ist fix programmiert und bei der Kompilierung bekannt.
*Spätes Binding: Die Methodenaufrufe werden nach dem Kompilieren aber vor der Laufzeit bekannt.
*Dynamisches Binding: Die Methodenaufrufe werden erst bei der Laufzeit zugeordnet.



Beim Polymorphismus ist der Methodenaufruf erst während der Laufzeit bekannt:

[[Image:222-6.gif]]


Bei der Mehrfachvererbung vererbt eine Klasse Eigenschaften aus zwei oder mehreren  Klassen (wird nicht von allen Sprachen unterstützt). Werden nur die Signatur (Schnittstelle) vererbt, so implementieren die Entwickler über Interface-Klassen.


Klassen, deren Instanzen nicht Objekte sonder wieder Klassen sind, werden Metaklassen genannt. Der Einsatz von Metaklassen ist eher in der Entwicklung eines Frameworks anzusiedeln und braucht einen hohen Grad an Abstraktionsvermögen der teilnehmenden Entwickler.


== Wie sieht ein typisches OO-Vorgehen aus? ==

Projektvorgehensmodelle helfen, das Risiko eines Projekt-Crashes zu minimieren. Sie bilden Teile der konstruktiven Qualitätssicherungsmassnahmen, damit Fehler vermieden werden und Projektziele nicht aus den Augen zu verlieren:

'''Projekt-Zieldreieck: Termine, Kosten, Qualität'''

[[Image:222-7.gif]]

Projekte werden in Phasen abgewickelt. Die meisten Phasenmodelle bestehen aus folgenden Phasen:


*Vorstudie: Projektumschreibung, ist das Projekt sinnvoll
*Fachkonzept: Anforderungen aufnehmen und fachliche Spezifikation, was soll mit dem Projekt abgedeckt werden.
*DV-Konzept (Datenverarbeitungskonzept): EDV-technischer Entwurf, wie wird das System gebaut.
*Realisierung: Programmierung, Beschreibung,m eigentlicher Bau des Systems
*Einführung: Schulung, Installation, Going Live

Aus diversen Gründen hat sich jedoch ein Vorgehen in kleinen überblickbaren Schritten bewäjhrt. Daraus entstanden die folgenden Modelle:

*Spiralmodell
*Ration Unified Process (IBM)
*oose Engineering Process (OEP)
*Extreme Programming (XP)


XP ist ein Vertreter der agilen Softwareentwicklung. Diese beinhaltet folgend vier Thesen um Software, schnell, flexibel und wendig zu entwickeln:

*Personen und deren Interaktionen gehen Prozessdefinitionen und Werkzeugen vor
*Gut funktionierende Software nützt mehr als ausgedehnte Dokumentation
*Enge fachliche Zusammenarbeit mit dem Kunden bringt das Projekt weiter als ausgedehnte Vertragsverhandlungen
*Auf Änderungen reagieren ist wichtiger als den ursprünglichen Plan einzuhalten

=== Prinzipen des OO-Vorgehens ===

*'''OO-Projekte werden iterativ in überschaubaren Inkrementen entwickelt'''.
*'''OO-Projekte werden von der Benutzeranforderung her getrieben'''.
*'''OO-Projekte werden architekturzentriert und modellbasiert entwickelt'''. (Weil der zugrunde liegende Geschäftsprozess vermutlich länger lebt als die verwendete IT-Technologie muss die Lösung Technologie unabhängig entwickelt werden.)


=== Phasen - Meilensteine ===
Aus dem natürlichen Ablauf eines Projektes ergeben sich vier Hauptphasen:

*'''1.Phase: Einstieg (Inception'''). Hier geht es darum den Fachbereich zu verstehen. Der Geschäftsprozess wird beleuchtet und eventuell einem Business Process Reengineering unterzogen. Der Anwender legt die wichtigsten Anforderungen und Einschränkungen dar. Eine erste Architekturskizze zeigt mögliche Realisierungswege auf. Das gesamte Projekt wird geplant und die Kosten-Nutzen Überlegungen dienen als Basis für den Go-Nogo Entscheid.

*'''2. Phase: Ausarbeitung (Elaboration)'''. Die Detail werden weiter ausgearbeitet. Die Anforderungen sollte vollständig vorhanden sein. Der Schwerpunkt liegt im Analyse/Design-Prozess, in welchem die Architektur, der gesamte Entwurf und ein Prototyp entsteht.

*'''3. Phase: Konstruktion (Construction)'''. Das System wird gebaut. die Komponenten werden entwickelt und integriert. Ziel ist ein lauffähiges und getestetes System.

4. Phase: Überleitung: (Transition). Das fertige System wird in dir Produktivumgebung gebracht. Dies beinhaltet die Schulung, Installation und weiter Anpassungs- und Testarbeiten.


=== Iteration (Wiederholung) ===

In jeder Phase sind eine bis mehrere Iterationen zu planen. Eine Iteration ergibt als Resultat einen definierten geprüften Zustand.

=== Prozesse - Tätigkeiten ===

Die einzelnen Prozesse beschreiben je Phase und Iteration welche Tätigkeiten ausgeführt werden und welche Resultate (Artefakte) erwartet werden.

Unified Prozess:

[[Image:222-8.gif]]

In den einzelnen Disziplinen sind die Module des Fachausweises zu erkennen: Geschäftsmodellierung, Anforderungen definieren, Analyse und Entwurf, Realisierung, Test + QS, Einführung, Projektmanagement, Change- und Configmanagement.


=== Artefakte - Lieferobjekte ===

Die Resultate werden ja nach Vorgehensmodell unterschiedlich benannt. Der Begriff Artefakt zeigt auf den gegensatdn (das eigentliche Resultat) hin. Während Lieferobjekt eher auf die Verantwortung appelliert, was zu liefern ist. Ein Artefakt kann sowohl ein Dokument als auch eine lauffähige Komponente sein.

=== Rollen - Projektmitarbeiter ===

Die wichtigsten Rollen in einem Softwareentwicklungsprojekt:

[[Image:222-9.gif]]


=== Zeitschätzungsverfahren ===

Zuerst muss man sich ein Bild über die nachfolgend aufgeführten '''Einflussfaktoren''' machen:

*Innovationsgrad des Projektes und deren zugrunde liegenden Techniken
*Qualität, Vollständigkeit und Klarheit der Aufgabenstellung
*Qualität, Motivation und Grösse des Projektteams
*Quantität der zur Verfügung stehenden Ressourcen
*Projektorganisation (Führungsstil, Kompetenten, Informationswege)
*Handhabung des Change Managements
*Komplexität der Schnittstellen bzw. Systemintegration
*...

Die wichtigste Komponenten ist die Erfahrung mit dem Teams selbst. Wer für ein neu zusammengestelltes Team eine Zeitschätzung abgeben muss, soll immer auf den grossen Unsicherheitsfaktor hinweisen. Unabhängig von einer bestimmten Technik ist der Schätzvorgang ein iterativer Prozess, welcher während der ganzen Projektdauer für die noch ausstehende Tätigkeiten eine periodische Überprüfung und Korrektur benötigt.


== Wie ist die Unified Modelling Laguage (UML) aufgebaut? ==

Die "Three Amigos" entwickelten in den neunziger Jahren ein gemeinsame Modellierungssprache welche nun von der OMG als Standard weiter gepflegt wird.

Das Hauptziel der UML ist es, eine einfache und für alle Beteiligten verständliche Modellierungssprache anzubieten. UML deckt vie Grundbedürfnisse der Systementwicklung ab:

*Visualisierung
*Spezifizieren
*Dokumentieren
*Programmieren (mittels bidirektionalen Konvertern können Klassencode erstellt oder aus bestehendem Programmcode wieder Diagramme erstellt werden.)


=== UML-Werkzeuge ===

=== Architektur-Sichten ===

[[Image:222-10.gif]]

=== UML Sprachelemente ===

Folgender Aufbau ist in den Metadefinitionen festgelegt:

*Struktur (statische Aspekte)
**Klassen mit dem Klassendiagramm, Paketdiagramm und Objektdiagramm
**Komponenten mit dem Komponentendiagramm
**Kompositionsstruktur mit dem Kompositionsstrukturdiagramm und Kollaborationsdiagramm
**Physische Verteilung von Artefakten mit dem Verteildiagramm
*Verhalten (dynamische Aspekte)
**Aktivität, Aktion mit dem Aktivitätendiagramm
**Interaktion mit den Integrationsdiagrammen
**Zustandsautomat mit dem Zustandsdiagramm
**Anwendungsfall mit dem Anwendungsfalldiagramm
*Erweiterung durch eigene Profile
**Erweiterung des Metamodells durch spezielle eigene Elementgruppen wir z.B. J2EE-Profile, MS .NET mit Web-Services und COM Profile.
*OCL - Object Constraint Language


= Artefakte im Analyseprozess =

*Die Analyse nimmt die Informationen aus den beiden vorangegangenen Prozessen der Geschäftsmodellierung und der Anforderungsaufnahmen
*Daraus wird die Beschreibung erstellt WAS im neuen System gelöst werden soll.

Dies bedingt eine Teamarbeit folgender Personen:
*Systemanalytiker
*Domänenexperten (Anwenden)
*Evtl. berate für Spezialgebiete (z.B. Datenschutz)
*Prototypenentwickler


Dadurch entsteht eine Systembeschreibung welche nach und nach komplettiert wird.

== Was beinhaltet die Systembeschreibung? ==

*Ausgangssituattion (Auslöser, Umfeld, Organisation)
*aktuelle Schwachstellen
*Zielsetzungen der neuen Lösung
*Beschreibung der Aufbau-Organisation
*Abriss des aktuellen Systems und dessen Integration (ergibt Rückschlüsse über die Schnittstellen)
*zu berücksichtigende gesetzliche Regelungen
*Projket-Begriffsverzeichnis


== Welche Modelle werden während der Analyse erstellt? ==

Die Modellierung verfolgt mehrere Zwecke:
*eindeutige Kommunikation zwischen den Beteiligten
*grafische Visualisierung von komplexen Zusammenhängen
*Möglichkeiten geben, Modelle auf Vollständigkeit, Konsistenz und Machbarkeit hin zu prüfen.


'''Modelle''':
*Das '''Anwendungsfalldiagramm''' basiert auf der IST-Situation der Business-Prozesse und den Anforderungen an das System. Hier wird die Frage beantwortet wie das System genutzt wird.
*Im '''Basismodell''' spürt der Analyst die Objekte auf. Aus den Objekten entstehen Klassen inkl. ersten Eigenschaften und Methoden. Das Basismodell ist Voraussetzung für das statische Analysemodell.
*Im '''statischen Analysemodell''' werden die Basismodell gefunden Element in Beziehung gesetzt. Weiter werden Generalisierungen vorgenommen (Klassen zu Oberklassen)
*Im '''dynamischen Analysemodell'''l werden die Interaktionen der Element dargestellt (zeitliche Ablauffolgen und Abhängigkeiten, mögliche Parallelität, Synchronisation von Aktivitäten, sowie Austausch von Nachrichten.


== Wie sieht das Prototyping in der Analysephase aus? ==

*Der Anwender wird beim Erstellen der Analyseprototyp einbezogen
*Dieses '''partizipative Protoptyping''' hat den Vorteil, dass grundlegenden Fehlüberlegungen in den Maskenabläufen und den wichtigsten Inhalten schon sehr früh ausgemerzt werden können.
*Für die Entwicklung können spezielle Autorentools oder Entwicklungsumgebungen eingesetzt werden (z.B. Rapid Application Development Tools)
*Die Maskendetail interessieren in dieser Phase noch nicht. Deshalb wird von einem '''Low-Fidelity-Wegwerf-Prototyp''' gesprochen.
*Meistens werden unterschiedliche Varianten erstellt um die beste Variante zu finden.


= Anwendungsfallmodell =
*Das Anwendungsfallmodell ist eine Black-Box-Betrachtung
*Aus jedem Geschäftsprozess werden die Geschäftsfälle (Business cases) identifiziert. Diese lassen sich in Geschäftsanwendungsfällen beschreiben und enthalten die Stereotyp-Bezeichnung "business".
*Der Analytiker trägt die jeweiligen Anwendungsfälle zusammen und vervollständigt sie mit dem Domänenexperten.

Die Anforderungen lasse sich in 3 Gruppen einteilen:
*Rahmenbedingungen (Projektumfeld, verfügbare Infrastruktur, Firmenstandards, gesetzliche Vorgaben)
*nicht-funktionale Anforderungen (Perfomanz, Benutzerfreundlichkeit, Robustheit, Wartbarkeit, ..)
*funktionale Anforderungen (was soll das System leisten)


== Wie werden Anwendungsfälle erstellt? ==

'''1. Schritt: Informationen vervollständigen.'''
*Mit Domänenexperten, dem Management,  den Kunden, Lieferanten Prozess-Owner und anderen Wissensträgern werden die Details durchgegangen.


'''2. Schritt: potenzielle Akteure finden.'''
*Welches sind die Kunden im betreffenden Geschäftsprozess?
*Welche internen Stellen sind beteiligt?
*zu welchen internen Stellen finden ein Datenaustausch statt?
*zu welchen externen Stellen finden ein Datenaustausch statt?

Die gefunden Akteure können in einem nächsten Teilschritt zu gleichen Gruppen zusammengefasst und einheitliche Namen gegeben werden.

z.B. beim Seminarhotel
*Kunden
*Mitarbeiter
*externe IT-Systeme
*interne IT-Systeme


'''3.Schritt: Anwendungsfälle identifizieren'''
*Ein Anwendungsfall besteht aus einer Folge zu Aktivitäten welche durch ein bestimmtest Ereignis ausgelöst wird.
*Meistens ist ein Akteur beteiligt für welchen mindestens ein sichtbares Ergebnis entsteht.
*Ein Anwendungsfall kann also durch ein auslösendes Ereignis und ein erhaltenes Resultat identifiziert werden.


'''4. Schritt: Akteure und Anwendungsfälle verbinden.'''
*Hier erfolgt ein erster Entwurf des Anwendungsfalldiagramms. Ausgehend von den definierten Anwendungsfällen wird der auslösende Akteure verbunden. So entsteht die Grundlage um an den Anwendungsfällen weiter zu arbeiten (im Normalfall CASE-Tool unterstützt).


'''5. Schritt: Akteure und Anwendungsfälle beschreiben und komplettieren'''

Es wird eine Beschreibung mit folgenden Eigenschaften und Inhalten erstellt:
*muss von allen Beteiligten verstanden werden (also nicht EDV-technisch verfasst)
*Akteure
*Vor/Nachbedingungen
*Ergebnisse
*Ablauf
*immer aus Sicht des Geschäftstreibenden beschreiben
*auf logische Abfolge der Anwendungsfälle achten


'''6. Schritt. Beziehungen zwischen Anwendungsfällen modellieren'''
*gleichartige Aktivitätsabfolgen suchen
*wenn vorhanden, dann als einen eigenen Anwendungsfall herausnehmen und in den anderen Anwendungsfällen mit einer "include"-Beziehung verwenden.


'''7. Schritt. Sicht überprüfen'''
*interagiert jeder Use Case unmittelbar oder mittelbar mit mindestens einem Akteur?
*Enthält kein Diagramm mehr als 10 Use Cases?
*Sind die Namen intuitiv verständlich?
*Ist die Beschreibung für Anwender verständlich?
*Sind die Begriffe konsistent?
*Sind die Use Cases weder zu mächtig noch zu klein?
*Ist die Beschreibung des Ablaufs nicht zu detailliert?
*Ist die Anwendung und nicht ein Dialogablauf beschrieben?
*sind alle Aspekte abgedeckt?
*Gibt es kein Widersprüche?


== Wie werden Anwendungsfalldiagramme erstellt? ==

*Ein entsprechend angeschriebenes Rechteck repräsentiert das zukünftige '''Informationssystem'''.
*Die Anwendungsfälle sind innerhalb des Systems zu platzieren.
*'''Akteure''' sind ausserhalb des Systems
*Die Anwendungsfälle werden mit einer durchgezogenen Linie mit den Akteuren verbunden. Die Linien nennt man '''Assoziationen'''.
*Die Akteure sind mit der in dieser Situation relevanten Rolle angeschrieben. 
*Die Anwendungsfälle sollten mit einer prägnanten Bezeichnung versehen sein (Substantiv und Verb wie z.B. Reservation durchführen)

[[Image:222-11.gif]]

[[Image:Anwendungsfalldiagramm.gif]]

*Akteure können Personen, OE oder andere fimeninterne oder firmenextern Informationssystem sein.
*Neben Strichmännchen dürfen auch andere Stereotypen verwendet werden.
*für ein anderes System hat sich das Knoten-Symbol der Verteildiagramms durchgesetzt.


'''Assoziationen:'''
*eine einfache Assoziation bedeutet eine bidirektionale Kommunikation zwischen dem Akteur und dem System (durchgezogene Linie ohne Pfeil)
*ist die Navigierbarkeit nur auf einen Seite gegeben, so wird dies mit einem offenen Pfeil und einem Kreuz am anderen Ende angedeutet (siehe Beispiel Rechnung an Kunde).
*Vor- bzw. Nachbedingungen werden mit einer gestrichelten Linie und offenem Pfeil gezeichnet. Siehe Beispiel: Check-Out nur möglich wenn Check-In durchgeführt wurde.
*Spezielle Anwendungsfälle können generalisiert werden. Alle Beziehungen des generellen Anwendungsfalles gelten dann automatisch für den speziellen. Die Beziehung wird durchgezogener und geschlossenem, gefüllten Pfeil gezeichnet. Siehe Beispiel "Reservation vornehmen" "Seminarreservation vornehmen".
*Gleiche Abläufe dürfen in separate Anwendungsfälle ausgelagert werden. Mit der Stereotype-Bezeichnung "include" können diese hinzugefügt werden. Dadurch werden Redundanzen vermieden. das Modell wird übersichtlicher und besser wartbar.
*"extend" ist ähnlich wie "include". Es kann aber eine Bedingung angegeben werden welche dann an einem "extension point" andockt.



[[Image:222-12.gif]]

[[Image:Include-extend.png]]


== Wie werden Anwendungsfälle beschrieben? ==

*Die Beschreibung soll möglichst kurz und prägnant sein.
*für alle Beteiligten verständlich
*Aus Sicht der Geschäftstreibenden

Die einzelnen Teile der Beschreibung:
*Name
*Spezialisierung von
*Kurzbeschreibung
*Akteure
*Auslöser
*Vorbedingung
*Eingehende Information
*Ergebnisse
*Nachbedingungen
*Ablauf
*Kategorie (Primär = notwendiges, häufiges Verhalten / Sekundär = notwendiges, seltenes Verhalten / Optional: nicht notwendiges Verhalten)


== Vom Anwendungsfall zum Testfall ==

Es ist sinnvoll bereits in dieser Phase die Testfälle und die Akzeptanzkriterien zu beschreiben. Diese können direkt aus den Anwendungsfällen abgeleitet werden.

= Statisches Analysemodell =

*Die Anwendnungfsfälle und das Pflichtenheft bilden den Input zum statischen Analysemodell. 
*Dieses konzentriert sich auf die Sichtweise des Aufbaus und die Struktur des Systems.
*Objekte bzw. Klassen mit ihren Attributen sind zu identifizieren
*Ebenso die Beziehungen zwischen den Klassen.
*Der Analytiker stellt die Resultate in einem UML-Klassendiagramm dar


== Welchem Zweck dienen CRC-Karten (Class - Responsibility - Collaborator)? ==

Auf den CRC-Karten werden in Arbeitssitzungen die Informationen gesammelt und auf einer Pin-Wand in der richtigen Beziehung platziert. Die erhaltenen Infos fliessen in die eigentliche Modellierung ein.

[[Image:222-13.gif]]

*Unter "Responsibility" werden die Verantwortlichkeiten eingetragen. 
*Collaborator" spricht die Beziehungen zu den anderen Klassen an.

Durch Beantworten folgender Fragen ergeben sich die ersten Klassen:

*Mit welchen Personen arbeitet das System zusammen?
*Welche Dinge sind im Geschäftsprozess involviert oder beschrieben?
*Welche Artikel bzw. Leistungen werden dem Kunden geliefert?
*Welche Papiere, Dokumente werden erstellt?
*Welche Informationen fliessen in das System?


Die Beziehungen:
*Welche fachlichen Beziehungen bestehen zwischen den Objekten?
*wie viele Objekte einer Klasse sind an einer Beziehung beteiligt?


== Wie werden Pakete geformt? ==


Ein Namensraum ist ein paketierbares Modellelement welches andere Element enthält. Pakete können ganz unterschiedlich Elemente enthalten. Pakete helfen Ordnung in die Anwendungen zu bringen. Gleichartige Artefakte lassen sich so bequem in ein entsprechendes Pakte versorgen. Man kann Elemente auch anderen Paketen wieder zugänglich machen.

Vier unterschiedliche Festlegungen der Sichtbarkeit:
*public: (+) für alle sichtbar
*private: (-) nur für die eigene Klasse sichtbar
*protected: (#) nur für die eigene Klassen und die Unterklassen sichtbar.
*package: (~) nur innerhalb des gleichen Paketes sichtbar


Pakete können andere Pakete importieren. Dazu gibt es folgende beiden Möglichkeiten:
*"import": die Elemente des anderen paketes werden importiert. Wenn das importierende Pakete von einem anderen Paket importiert wird, werden auch die von diesem Paket importierten Pakete ebenfalls impoirtiert.
*"acccess": Damit greift man nur auf die Elemente zu, ohne diese weiter zu exportieren.

Beide werden als Abhängigkeit gezeichnet, das heißt in der Form einer gestrichelten Linie mit einer offenen Pfeilspitze. Zu beachten ist, dass das importierte Paket am Ende mit der Pfeilspitze gezeichnet wird.

[[Image:222-14.gif]]

== Wie sieht ein Analyseklassenmodell aus? ==

Die Klassen mit den wichtigsten Attributen, den Assoziationen mit deren Multiplizität (Kardinalität) sowie den Verebungsstrukturen werden identifiziert.

=== Klasse ===

*Bezeichnung soll eine natürliche Identifikation ermöglichen
*eindeutige Bezeichnung im ganzen Modell
*keine Leerzeichen im Namen oder andere Sonderzeichen (ausser _)
*Zusammengesetzte Namen sollten mit GrossKlein-Schreibung abgegrenzt werden.
*diese Regeln gelten auch für Pakete, Attributs und Operationsbezeichnungen


Namen von abstrakten Klassen werden kursiv geschrieben. In Handzeichnung sollte aber besser den Constraint {abstract} angegeben werden.


In UML wird die Klasse als Rechteck gezeichnet:

[[Image:222-15.gif]]


=== Attribute ===

*bilden die Eigenschaften einer Klasse
*Name soll möglichst selbsterklärend sein.
*jedes Attribut weist einen Attributswert je Instanz auf
*Klassenattribute weisen hingegen einen Attributswert für die gesamte Menge der Objekte auf. Diese sind unterstrichen.
*Ein von anderen Attributswerten abgeleitetes Attribut beginnt mit einem Slash. Für das Design werden diese Attribute meist gestrichen, da sie sich errechnen lassen.

[[Image:222-16.gif]]

*Jedes Attribut weist eine Sichtbarkeit aus
*der Typ des Attributes zeigt die Art der darin enthaltenen Daten auf. Primitiver Datentyp (string, int), Aufzählungsdatentyp (Enum), Komplexer Datentyp (Objekt)

Beispiel Aufzählungsdatentyp:

[[Image:222-17.gif]]

*Im Design stehen die Typen der jeweiligen Plattform zur Verfügung (Java, .NET, ...)
*Attribute können bei den Instantiierung einen Initalwert erhalten. Dazu wird mit einem Gleichheitszeichen der Wert zugewiesen. Ohnen diese Anaben enthalten die Attribate den Leerwer (Null-Value)
*Attribute welche nur gelesen werden dürfen, haben das Merkmal {readonly}

Bei Attributen welche mehrere Werte enthalten können, wird die Multiplizität in eckigen Klammen angegeben. Die Listen können wir folgt beschrieben bzw. eingeschränkt werden:

*{bag}: beliebige Liste von Werten
*{unique}: jeder Attributswert darf nur einmal vorkommen.
*{ordered}: die Liste der Werte ist sortiert.

Künstliche Schlüsselattribute dürfen in der Analyse noch nicht festgelegt werden. Dies ist Design-Arbeit. Auch Fremd-Schlüsse sind noch nicht festzulegen.


Durch die Assoziation wurd die Navigierbvarkeit sichergestellt.

Die Syntax der Attributsdefinition lautet:

'''[sichtbarkeit][/][:typ[multiplizität][=initialwert][{eigenschaftswert}]'''

=== Operationen ===
*Erst während der Erstellen des dynamischen Analysemodells vervollständigt der Analytiker die Operationen mit den dazu gehörenden Parametern.
*Der Namen und die Parameter bilden die Signatur
*Die Menge aller Operationen bilden das Verhalten der Klasse
*Operationen enthalten die selben Sichtbarkeitshinweise wie die Attribute.


Die Paramter sind in der Klammer mit Komma abgetrennt. Ohne spezielle Angaben sind dies Eingabeparameter. Ansonsten:

*in: Eingabewert (Default)
*out: Rückgabewert
*inout: beides

Den Parametern ist der Typ (mit Doppelpunkt) beizufügen.


Zusicherungen welche das System beim Aufruf bzw. beim Abschluss der Operation einhalten muss, werden mit OCL in geschweiften Klammern (Constraints) angegeben:

*Vorbedingung: {pre: KundenNr ist gültig}
*Invariante (Zusicherung während Ausführung): {inv: Objekt ist für Dritte gesperrt}
*Nachbedingung: {post: Änderung ist persistiert)

Sofern eine Operation einen Typ besitzt, entspricht dies dem Typ des Rückgabeparameter.

Je nach Verantwortlichkeit der Aufgabe welche die Operation hat, werden folgenden Arten unterschieden:

*Konstruktor
*Destruktor
*Setter
*Getter
*Link (Aufbauen Objektbeziehung)
*Unlink
*Getlink
*Query (Dateninhalt abfragen. Mit/ohne Berechnung)
*Update (speichern, persititieren)

Die Syntax der Operation lautet:

'''[sichtbarkeit] name (parameterliste) [:typ] {constraints}'''

=== Assoziationen (Beziehungen) ===

*zeigen die Beziehungen zwischen Klassen auf
*werden mit einer ausgezogenen einfachen Linie dargestellt
*im Analyseklassendiagramm sind diese zu benennen.
*Wenn die Leserichtung nicht von oben nach unten oder nicht von links nach rechts geht, muss diese mit einem kleinen ausgefüllten Pfeil angegeben werden.
*Am Ende der Assoziation besteht die Möglichkeit die Rolle anzugeben welche dies entsprechende Klasse in dieser Beziehung hat.

Die Multiplizität definiert die gültige Kardinalität. 

Beispiel:

*Eine Firma ist Kunde des Seminarhotels
*Die Firma führt ein Seminar durch an welchem 3 Mitarbeiter teilnehmen.
*Die Kardinalität ist in diesem Fall 3
*Da wir keine Begrenzung der Anzahl vorgeben, ist die Multiplizität 1..*. 

Gültige Multiplizitäten sind in positiven ganzzahligen Werten anzugeben. Ein Von-bis-Wert ist mit zwei Punkten ".." anzugeben. Sobald der Wert 0 möglich ist, ist diese Beziehung optional.



Beispiele:

*1
*0..1
*1..3, 7
*1..*
*0..* ist gleichbedeutend wie *

'''Beispiel:'''

[[Image:222-18.gif]]

kann wie folgt gelesen werden:

*Ein Kunde besteht aus mindestens einer Person, kann aber aus beliebig vielen Personen bestehen.
*Genau eine Person ist die Kontaktperson beim Kunden.


Ein '''Objektdiagramm''' zeigt konkrete '''Instanzen''' mit deren Beziehungen aus. Es hilft konkrete Situationen darzustellen. Das obige Beispiel sieht als Objektdiagramm z.B. wie folgt aus:


[[Image:222-19.gif]]



'''Navigierbarkeit:'''
*werden mit einem offenen Pfeil bzw. dem Kreuz modelliert.
*wenn nichts angegeben ist, ist sie bidirektional.
*Die Navigierbarkeit muss im Design bei unidirektionalen (nur ein Weg) explizit modelliert werden. Entsprechend werden die dazu notwendigen Link-Operationen gebildet.

Wie im Beispiel angegeben, macht es keinen Sinn, vom Hotelzimmer her zu wissen wer dies präferenziert.

[[Image:222-20.gif]]


Wenn ein Objekt eine Beziehung zu einem Objekt der gleichen Klasse hat, spricht man von einer '''reflexiven Assoziation'''. Im folgenden Beispiel können Personen Mitarbeiter oder Vorgesetzte sein. Jeder Mitarbeiter hat genau einen Vorgesetzten und jeder Vorgesetzte hat 1 bis 10 "Untergebene".

[[Image:Reflexive-Assoziation.gif]]



'''noch ein Beispiel:'''

[[Image:222-21.gif]]


*Wenn man eine 1:1-Beziehung hast, muss dies überprüft werden.
*Wenn die eine Klasse nur eine Ergänzung bildet, müssen diese in der Analysephase zu einer Klasse zusammengefasst werden.
*Nur wenn eine separate Objektidentität vorhanden ist, darf eine 1:1-.Beziehung angewendet werden. Beispiel: Klasse Ehemannen und Ehefrau.


'''Aggregation:'''
*Ein Stockwerk besteht aus diversen Räumen.
*Die Räume sind Teil des Stockwerkes.

Eine solche Beziehung wird mit UML in einer '''Aggregation'''. Am Assoziationsende ist beim Ganzen ein nicht ausgefüllter Rhombus. Die Aggregation wird in der Analysephase gerne angewendet, im Design jedoch weggelassen, da eine Implementierung nicht stattfindet.

[[Image:222-22.gif]]

anderes Beispiel:  Restaurant und Stuhl. Stuhl kann auch ohne Restaurant leben. 



'''Komposition''':
*wenn die einzelnen teile nicht ohne die Existenz des Ganzen leben können, handelt es sich um eine Komposition.
*wird mit einem gefüllten Rhombus dargestellt.
*hat im Gegensatz zur Aggregation einen direkten Einfluss auf das Design.
*es muss sichergestellt sein, dass beim Löschen des Ganzen auch die dazugehörenden teile gelöscht werden, bzw. dass während der Existenz des Teiles das dazu gehörende Objekt des Ganzen auch vorhanden ist.

[[Image:222-23.gif]]



'''Zusicherungen:'''

Zwischen Assoziationen kann es Abhängigkeiten geben. Diese werden mittels Zusicherungen (Constraints) modelliert. Beide Beziehungen werden mit einer gestrichelten Linie verbunden und die Zusicherung in Klammern geschrieben:

*OCL Ausdruck
*or: keine, nur eine oder beide Beziehungen dürfen vorhanden sein.
*xor: es darf nur eine Beziehung vorhanden sein.
*and: es müssen beide Beziehungen vorhanden sein.

[[Image:222-24.gif]]



'''Assoziationsklasse:'''
*Es kommt vor, dass Bezeihungen ebenfalls Attribute und Operationen haben. 
*Damit werden diese Assoziationen zu Assoziationsklassen. 
*Im Analyseklassenmodell wird dies mit einer Klasse, welche eine gestrichelte Linie zur Assoziation aufweist, dargestellt.
*jede konkrete Beziehung bildet somit ein Objekt mit den entsprechenden Attributswerten.
*Für das Design-Modell muss dieses Konstrukt jedoch in 2 Beziehungen und einer normalen Klasse aufgelöst werden.

[[Image:222-25.gif]]

anderes Beispiel:

[[Image:Assoziationsklasse.gif]]

=== Generalisierung ===

*schon in anderen Kapiteln erwähnt.
*UML-Notation: ein geschlossener Pfeil der zur Oberklasse zeigt.

'''Beispiel eines Analyseklassediagramms:'''

[[Image:222-27.gif]]

=== Verwendung von visuellen Stereotypen ===

[[Image:222-26.gif]]

=== Wie präzisieren wir ein Modell mit OCL ===

*Visuelle Modelle haben grenzen
*z.B. wenn man modellieren will, dass nur Personen des gleichen Kunden in das gleiche Hotelzimmer bewohnen sollen.

Mit OCL lassen sich Modelle mit Einschränkungen und Präzisierungen ergänzen. OCL ist eine seiteneffektfreie Sprache. Es können keine Werte geändert werden. ähnlich SQL "select". In Bezug auf MDA bietet OCL die Voraussetzung, damit ein Modell vollständig und eindeutig auf einer hohen Abstraktionsebene definiert werden kann.

OCL-Befehle weisen immer einen '''Kontext''' auf, der eine Zuordnung auf ein konkretes Modellelement enthält:

*Classifier (wie z.B. Klasse, Akteur, ...)
*Feature eines Classifiers wie Attribut oder Operation.

'''Beispiele''':

Festlegen, dass die verantwortliche Person mindestens 18 Jahre alt sein muss:

''context: Kunde

inv:     self.Kontaktperson.Alter >= 18''


"inv" steht für Invariant, was mit einer "immer zutreffenden Zusicherung" übersetzt werden kann.


=== Prüfung des Modells ===

Folgende Fragen helfen bei der Überprüfung des statischen Analysemodells um die Qualität zu steigern

*Sind die Namen aussagekräftig (Klasse, Attribute, Operationen)?
*korrektes Abstraktionsniveau
*es dürfen keine Reports, Benutzeroberflächen oder Implementierungsdetails als Klassen modelliert sein.
*sind die nötigen Rollen spezifiziert?
*Liegen unberechtigte 1:1 Beziehungen vor?
*etc...



== Wie helfen Analysemuster Lösungen zu finden? ==

Für immer wieder auftauchende Problemstellungen wurden Musterkataloge geschaffen.

Beispiele:

[[Image:222-28.gif]]

[[Image:222-29.gif]]


= Dynamisches Analysemodell =

*Die Dynamik des System wird beschrieben.
*wird auch '''Interaktionsmodell''' genannt (weil dargestellt wird wie die Objekte interagieren)
*Der Schwerpunkt liegt auf de Innensicht (White Box). Im Gegensatz zum Anwendungsfallmodell (Black-Box-Betrachtung)

== Wie werden Prozessabläufe als Aktivitätendiagramm modelliert? ==
*Sobald ein Anwendungsfall einige Bedingungen und Nebenläufigkeiten hat, ist eine verbale Beschreibung nicht mehr geeignet. 
*Stattdessen kommt das Aktivitätendiagramm zum Zug (grafische Darstellung)
*Das Aktivitätendiagramm  kann auch für die Beschreibung des gesamten Geschäftsprozess verwendet werden(z.B. anstelle vom BPMN)


'''Beispiel eines einfachen Aktivitätendiagramm:'''

[[Image:222-30.gif]]

(Aktivität = ganzes / Aktion = Teilschritt bzw. kleinste ausführbare Einheit)
*genau ein Startknoten
*ein oder mehrere Endknoten
*Jede Aktion muss ein Ausgang haben.
*Bedingung bei Entscheidungsknoten muss gemäss UML-Regel in eckigen Klammern stehen)
*Alternativ kann Bedingung in einer Notiz angegeben werden.


'''Beispiel parallele Kontrollflüsse:'''

[[Image:222-31.gif]]

*Splitting- bzw. Synchronisationsbalken dürfen auch waagrecht sein
*erst wenn alle Zweige beim Synchronisationsbalken ankommen, läuft der Prozess weiter.
*Ausnahme: paralleler Kontrollfluss kann beendet werden.



'''Objekte / Pins / Buffers'''

*In UML 2.0 steht neu die Möglichkeit der Modellierung eines Objektflusses zur Verfügung. Objekte welches als Parameter übergeben werden oder Aktionen welche Objekte erzeugen werden als Pin visualisiert.
*Der "centralBuffer" bildet eine Zwischenspeicher für Objekte.
*Der "datastore"  ist die Endablage von Objekten.

Im folgenden Beispiel werden auch Konnektoren gezeigt:

[[Image:222-32.gif]]



'''Ereignisse''':

Im folgenden Beispiel sind folgende Ereignisse zu sehen
*normales Ereignis, d.h. ein Signal aus einem Ereignis empfangen
*Zeitereignis
*Ausnahmeereignis
*Ein Ereignis auslösen, d.h. ein Signal senden

[[Image:222-33.gif]]


'''Aktivitätsbereiche''':
*Mit Aktivitätsbereichen kann dargestellt werden wer für eine Aktion verantwortlich ist. 
*Diese dürfen horizontal oder vertikal angebracht werden. 
*Nicht mehr als Aktivitätsbereiche verwenden.
*Alternativ können die Aktivitätsbereiche mit Klammern angegeben werden.

[[Image:222-34.gif]]


'''Dekompositionen'''
*Wenn sich hinter einer Aktion ein komplexer Ablauf verbirgt, kann dies mit einem gabelähnlichen Symbol unten rechts angezeigt werden.
*Diese Aktion ist dann ein Aufruf zu einer eigenständigen Aktivität
*So können Dekompositionen auf unterschiedlichen Ebenen modelliert werden

[[Image:222-35.gif]]


'''Strukturelemente'''
*Für den Einsatz in der Designphase stehen auch Strukturelemente von Selektionen und Iterationen zur Verfügung

[[Image:222-36.gif]]