M1.x UML in der Bioinformatik UML in der...©2011 JKU Linz, Institut für Bioinformatik,...

Modul 1.x:

UML in der Bioinformatik

DI Angelika Kusel

a.Univ.-Prof. Dr. Werner Retschitzegger

Vorlesu

ng

IFS in der B

ioinformatik

SS 2011

Johannes Kepler University Linzwww.jku.ac.at

Johannes Kepler University Linzwww.jku.ac.at

Institute of Bioinformaticswww.bioinf.jku.at

Institute of Bioinformaticswww.bioinf.jku.at

IFSIFSInformation Systems Group

www.ifs.uni-linz.ac.at

IFSIFSIFSIFSInformation Systems Group

www.ifs.uni-linz.ac.at

M1.x-2© 2011 JKU Linz, Institut für Bioinformatik, Arbeitsgruppe Informationssysteme (IFS)


Inhalt

MotivationHistorische Entwicklung von UMLDiagrammarten im ÜberblickKlassendiagrammPaketdiagrammZustandsdiagramm



MotivationWarum modellieren wir?

»When it comes down to it, the real point of software development is cutting code«

»Diagrams are, after all, just pretty pictures«

»No user is going to thank you for pretty pictures; what a user wants is software that executes«

[aus M. Fowler, ”UML Distilled”, Addison Wesley, 1997]



Motivation Modelle und Diagramme

Ein Modell stellt eine Abstraktion eines Realitätsausschnitts dar

Um Information verständlicher darzustellenUm essentielle Systemaspekte aufzuzeigenZur Kommunikation (Projektmitarbeiter, Kunden)Um komplexe Architekturen darstellen zu können

Ein Diagramm ist die grafische Repräsentation eines Modells

1928, René Magritte

ModellModell

Personcd A

StudentAssistent

intover a

ref X ref Y

sd P

m1 m2

m3

rolle1rolle1 rolle2rolle2 rolle3rolle3 rolle4rolle4

Diagramme

Realitäts-ausschnitt Sicht Sicht



Motivation Warum Model Engineering (MDE)?

Traditionelle Verwendung von Modellen in derSoftwareentwicklung

Kommunikation mit den Auftraggebern bzw. Anwendern und innerhalb der Entwicklergruppe selbst (Anforderungs-beschreibung, Prototypen)

Model as “sketch”

Hilfsmittel für den Softwareentwurf, Erfassen der Absicht und Aufgabenspezifikation für die Programmierer, Code-Visualisierung, bspw. in TogetherJ

Model as “blueprint”

Was ist der Unterschied zu Model Engineering?Model as “programming language”



MotivationPrinzipien und Ziele von MDE

Abstraktion von spezifischen RealisierungstechnologienErfordert Modellierungssprachen, die keine spezifischenKonzepte von Realisierungstechnologien (z.B., Java EJB) enthaltenVerbesserte Portabilität von Software auf neue/wechselndeTechnologien – model once, build everywhereInteroperabilität zwischen unterschiedlichen Technologienkann automatisiert werden (sog. Technology Bridges)

Automatisierte Codegenerierung aus abstrakten Modellenz.B., Generierung von Java-APIs, XML schemas etc. aus UMLErfordert ausdrucksstarke und präzise ModelleErhöhte Produktivität und Effizienz (Modelle bleiben aktuell)

Getrennte Entwicklung von Anwendung und InfrastrukturTrennung von Anwendungs- und sog. Infrastruktur-Code (z.B. Application Framework) erhöht die WiederverwendbarkeitFlexibilisierung der Entwicklungszyklen sowie Spezialisierungder Kompetenzen möglich



MotivationEinsatzgebiete von MDE in der BI

Modellgetriebene Entwicklung von BI-IFSEntwicklung domainspezifischer Modellierungssprachen(DSLs) für biologische Teilbereiche

Bottom-up Ansatz

Einsatz von MDE (Model-Driven Engineering)-Techniken im Bereich „System Biology“

Top-down AnsatzKonzeptuelle Integration und globale Repräsentation verschiedener „technological spaces“ („Omics“), bspw. Genomics, Proteomics und GlycomicsReduktion der Komplexität biologischer Systeme durch Abstraktion in Modellen Modell-basierte Analyse, Vorhersage und Testen des Verhaltens biologischer Systeme

Quelle: Magali Roux-Rouquié, Debora Schuch da Rosa, Ten Top Reasons for Systems Biology to Get Into Model-Driven Engineering, ACM GaMMa Workshop (held in conjunction with ACM ICSE), Shanghai, China, May 2006.



MotivationEinsatzgebiete von MDE in der BI – Abstraktionsstufen

Organismus

RNS

Protein

Struktur

„Quellcode“von einem unerreichbaren Autor,Dokumentation nicht vorhanden

„Kompilierte Klassen“

„Laufzeitobjekte“

DNS

«import»

«import»

«import»

«import»

«import»

mRNS-Abschnitt{abstract}

Splicing*

Aminosäuresequenz

bildet (Translation)

1

1*

Intron(nicht

kodierend)

Exon(kodierend)

DNS::RNSStruktur::Zellkern

enthält

Gen-expression

Prä-mRNS

DNS::Base

1

rRNS tRNS

Codon

AntiCodon

Reife mRNS

1

1

3

3

Glycin

Anzahl=20

…Leucine Cystine

Aminosäure

1

*

1

1

1

DNS::Makromolekül

Struktur::Riobosom

*

*

*

Bild aus: http://www.cs.ucl.ac.uk/staff/A.Finkelstein/papers/cchallcomputer.pdf



Historische Entwicklung von UMLZiele

Bereitstellung einer ausdrucksstarken Modellierungssprache

Zur Formulierung unterschiedlicher Typen von ModellenZum Austausch von ModellenZur Spezifikation, Konstruktion, Visualisierung und Dokumentation der Artefakte eines SW-Systems

Bedeutung des Begriffs »Unified«Unterstützung des gesamten EntwicklungsprozessesFlexibilität in Bezug auf VorgehensmodelleUnabhängigkeit von Entwicklungswerkzeugen und –plattformen, sowie ProgrammiersprachenEinsetzbarkeit für verschiedenste AnwendungsbereicheGenerizität der Sprachkonzepte in einem MetamodellIntegration von »Best Practices«



Diverse Methoden

OML, Catalysis, Syntropy, etc.Booch OMT OOSE

Unified Method 0.8

UML 0.9

UML1

UML 1.1

ÖffentlichesFeedback

Industrialisierung

UML 1.3

UML2

UML 1.4

1995

1996

1997

Fragmentierung»Methodenkriege«

Vereinheitlichung

Standardisierungim Sept. 1997 durch die OMG

1998

1999

2000

2001

2002

2003


Erweiterung und Konsolidierung

UML 1.5

2004

2005


OCL

XMI

Komponenten, Profile,

Kollaborationen

Aktionsmodell

FundamentaleNeuerungen

Historische Entwicklung von UML... vom Methodenkrieg zu UML2



Historische Entwicklung von UMLDie Wurzeln von UML

OMT - Object Modeling Technique (J. Rumbaugh et al.)

Starker Bezug zur DatenmodellierungModellierung komplexer (CAD-) Objekte in Form von erweiterten ER-Diagrammen

Booch-Methode (Grady Booch)Starker Programmiersprachenbezug (Ada)Modellierung von Echtzeitsystemen und nebenläufigen Systemen

OOSE - Object-Oriented Software Engineering (I. Jacobson)Skandinavische Schule – stark in der Beschreibung von AnforderungenModellierung und Simulation von Telekommunikationssystemen durchMessage Sequence Charts und SDL (Specification and Design Language)Use-Case-orientiert



Strukturdiagramm

Diagrammart

Verhaltensdiagramm

Kompositionsstruktur-diagramm

Klassen-diagramm

Objekt-diagramm

Paket-diagramm

Komponenten-diagramm

Verteilungs-diagramm

Anwendungsfall-

diagramm

Aktivitäts-diagramm

Zustands-diagramm

Interaktions-diagramm

Sequenz-diagramm

Kommunikations-diagramm

Zeit-diagramm

Interaktionsübersichts-

diagramm

Diagrammarten im Überblick



Diagrammarten im ÜberblickStrukturdiagramme 1/2

(1) KlassendiagrammBeschreibt den strukturellen Aspektin Form von Klassen, Interfaces und Beziehungen

(2) ObjektdiagrammBeschreibt den strukturellen Aspektin Form von Objekten und Links

(3) PaketdiagrammGruppiert Modellelemente auf verschiedenen Abstraktionsebenenzur Komplexitätsreduktion

A B

C1..*

1

1 *

1

0..1

A B1 *

P

a1:A b1:B

c1:C

c2:C

b2:B



Diagrammarten im ÜberblickStrukturdiagramme 2/2

(4) KomponentendiagrammZeigt interne und externe Sicht vonKomponenten, sowie die Verknüpfungvon Komponenten untereinander

(5) KompositionsstrukturdiagrammZeigt die interne Struktur von Modellelementenund ermöglicht dadurch eine hierarchischeDekomposition

(6) VerteilungsdiagrammZeigt die eingesetzte HW- und SW-Topologie in Form von Knotenund Kommunikationsbeziehungensowie das zugeordneteLaufzeitsystem in Form von Artefakten

«component»A

«component»B

c1:C 1 b2:B 11 1

A

«artifact»Order.jar «component»

Order

«device»DBServer

«device»PDA

«deploy»

«manifest»



Diagrammarten im ÜberblickVerhaltensdiagramme 1/2

(1) AnwendungsfalldiagrammBeschreibt die Funktionalität des zuentwickelnden Systems aus Benutzersicht

(2) AktivitätsdiagrammDient zur Modellierung von prozeduralenAbläufen in Form von Kontroll- und Datenflüssen

(3) ZustandsdiagrammBeschreibt das erlaubte Verhaltenvon Modellelementen in Form vonZuständen und Zustandsübergängen

a1 c1

b1

A B C

z1 z2

z3

z4

e e‘

e‘

X Y

Z

«include»



Diagrammarten im ÜberblickVerhaltensdiagramme 2/2

(4) SequenzdiagrammBeschreibt komplexe Interaktionenzwischen Objekten in bestimmten Rollen, um eine konkrete Aufgabe zu erfüllenFokus: Zeit als eigene Dimension

(5) KommunikationsdiagrammBeschreibt einfache InteraktionenFokus: Strukturelle Beziehungen

(6) ZeitdiagrammZeigt Zustandsänderungen derInteraktionspartner aufgrund von Zeitereignissen und Nachrichten

(7) InteraktionsübersichtsdiagrammZeigt auf abstrakter Ebene den Kontrollfluss zwischen verschiedenenInteraktionsabläufen

a:A b:B c:Cm1

m2m3

a:A b:B c:C1:m1 2:m2

3:m3

m1z1z2a:

A

m3z7z8b:

B

a:A b:B c:Cm1

m2m3

sd P



Klassendiagramm 1/24... vs. Objektdiagramm

KlassendiagrammBeschreibt den strukturellen Aspekt einesSystems auf Typebene in Form von Klassen,Interfaces und Beziehungen

ObjektdiagrammBeschreibt den strukturellen Aspekt einesSystems auf Instanzebene in Form vonObjekten und LinksMomentaufnahme (snapshot) des Systems –konkretes SzenarioAusprägung zu einem Klassendiagramm

Prinzipiell kann jede Diagrammart auf Instanzebenemodelliert werden

A B

C1..*

1

1 *

1

0..1

a1:A b1:B

c1:C

c2:C

b2:B



KlassendiagrammKlasse und Objekt

Klasse:

Objekt:Name des Objekts (und seiner Klasse) unterstrichen

Benutzername: Stringberechtigung: Rechtpwd: Stringanzahl: Integer

pruefePW (PW: String): boolermittleAnzahl(): Integer

Klassenattribut

Klassenoperation

Attribute

Operationen

: BenutzereinBenutzer: Benutzer

einBenutzer martin: Benutzername = "Martin"berechtigung = "E/L"pwd = "4711"anzahl = 4



KlassendiagrammKlasse in verschiedenen Phasen

/auszeichnung: Farbebeginn: DatumZeitbeschreibung: Stringdauer: Zeithyperlink: URL[0..1]typ: Termintyp anzahlTermine: Int

Termin

{auszeichnung = colorCode(typ)}

V.1.3: -hyperlink[0..1]: URL

≅ t.beginndatum= beginndatum ∧¬(t.beginnzeit ≥ beginnzeit + dauer ∨t.beginnzeit + t.dauer ≤ beginnzeit)

«entity»Termin

{persistence=persistent}

-beginndatum: Datum-beginnzeit: Zeit -beschreibung: String-dauer: Zeit = "01:00"-hyperlink: URL[0..1]

«Konstruktion»+Termin()

«Attributzugriff»+liesBeschreibung () : String {query}+setzeBeschreibung (in text: String)+auszeichnung () : Farbe {query}...

«Beziehungsnavigation»+kollidiertMit (in t: Termin): bool {query}...



KlassendiagrammKlasse – Eigenschaften von Attributen und Operationen

Klassenattribute und -operationen: unterstreichen

Sichtbarkeiten von Attributen und Operationen:+ ... public- ... private# ... protected~ ... package (vgl. Java)

Eigenschaften von Attributen:»/« attributname: abgeleitetes Attribut{optional}: Nullwerte sind erlaubt[n..m]: Multiplizität (auch: [n..m ordered])

Eigenschaften von Operationen:{query}: Operation ohne Seiteneffekte



KlassendiagrammAbstrakte Klasse

Eine abstrakte Klasseist eine Klasse, die nicht instanziert werden kannist daher nur in Generalisierungshierarchien sinnvoll

dient zum »Herausheben« gemeinsamer Merkmaleeiner Reihe von Unterklassen

Mit analoger Notation wird zwischen konkreten (= implementierten) und abstrakten (= nur spezifizierten) Operationen einer Klasse unterschieden

{abstract}Eintrag Eintragoder



KlassendiagrammExkurs: Identifikation von Klassen – Konstruktiv ...

Linguistische Analyse der Problembeschreibungnach R.J. Abbott, Program Design by Informal English Descriptions, CACM, Vol. 26, No. 11, 1983

Hauptwörter herausfiltern

FaustregelnEliminierung von irrelevanten BegriffenEntfernen von Namen von AusprägungenBeseitigung vager BegriffeIdentifikation von AttributenIdentifikation von OperationenEliminierung von Begriffen, die zu Beziehungen aufgelöst werden können



Welche Klassen lassen sich mittels Dokumentanalyse identifizieren?

Formulare, Listen, etc.Bei Re-Engineering – Benutzerhandbücher, Bildschirmmasken, Dateibeschreibungen, Funktionalität des laufenden Systems

Welche Klassen lassen sich aus den Use Cases identifizieren?

Sind Klassen der folgenden Kategorien zu modellieren?Geschäftstransaktionen

Diese sind kritisch (haben mit Geld zu tun); deshalb sollten Sie mit Transaktionen beginnen (z.B. Sale, Payment, Reservation)

TransaktionspositionenTransaktionen enthalten oft mehrere Positionen; deshalb sollten Sie diese als Nächstes betrachten (z.B. SaleslineItem)

Produkt oder Dienst, das bzw. der mit einer Transaktion oder Transaktionsposition verbunden ist

Transaktionen beziehen sich auf ein Produkt oder einen Dienst (z.B. Item, Flight, Seat, Meal)





Sind Klassen der folgenden Kategorien zu modellieren?Wo wird diese Transaktion registriert?

z.B. Register, FlightManifest

Rollen von Leuten oder Organisationen, die an der Transaktion beteiligt sind; Akteure im Use Case

Wir müssen normalerweise wissen, welche Parteien an Transaktion beteiligt sind (z.B. Cashier, Customer, Store, MonopolyPlayer, Passenger, Airline)

Ort der Transaktion; Ort des Dienstesz.B. Store, Airport, Plane, Seat

Problemrelevante Ereignisse und Aktionen, häufig mit einer Zeit und/oder einem Ort, die bzw. den wir festhalten müssen

z.B. Sale, Payment, MonopolyGame, Flight

Physische und logische DingePhysische Dinge sind besonders relevant, wenn Software zur Gerätesteuerung oder für Simulation entwickelt wird (z.B. Item, Register, Board, Airplane)

Beschreibungen von DingenProductDescription, FlightCatalog

Container von physischen oder logischen DingenStore, Bin, Board, Airplane

Dinge in einem ContainerItem, Square (auf einem Board), Passenger




Sind Klassen der folgenden Kategorien zu modellieren?Andere kollaborierende Systeme

z.B. CreditAuthorizationSystem, AirTrafficControlKataloge

Beschreibungen stehen häufig in einem Katalog (z.B. ProductCatalog, FlightCatalog)

Diverse Unterlagen (Finanzen, Arbeit, Verträge, Rechtsangelegenheiten)

z.B. Reiceipt, Ledger, MaintenanceLogZeitpläne, Handbücher, Dokumente, die regelmäßig herangezogen werden, um Arbeit zu erledigen

z.B. DailyPriceChangeList, RepairScheduleFinanzinstrumente

z.B. Cash, Check, LineOfCredit, TicketCredit



Liegt ein aussagekräftiger Klassenname vor? entspricht der Fachterminologieist ein Substantiv im Singularist so konkret wie möglich gewähltdrückt dasselbe aus wie die Gesamtheit der Attributebeschreibt nicht die Rolle dieser Klasse in einer Beziehung zu einer anderen Klasse ist eindeutig im Paket bzw. im Systemdrückt nicht dasselbe aus wie der Name einer anderen Klasse

Sie enthält eine wohldefinierte Menge von VerantwortlichkeitenIhre Attribute und Operationen sind (wirklich) notwendig, um die Verantwortlichkeiten der Klasse zu realisieren Zu viele Verantwortlichkeiten - auf neue Klassen aufteilenZu wenig Verantwortlichkeiten - zusammenfassen mit anderen Klassen Ihre öffentliche Schnittstelle sollte nur aus Operationen bestehen, d.h. Attributesollten verborgen seinOperationen sollten möglichst wenig Parameter haben Jede Operation sollte Attribute der Klasse verwenden

Fehlerquellen„God Classes“ vs. „Ravioli Classes“Klasse ist eigentlich ein Attribut

KlassendiagrammExkurs: Identifikation von Klassen – Analytisch ...



KlassendiagrammExkurs: Identifikation von Attributen – Konstruktiv ...


Adjektive und Mittelwörter herausfiltern

FaustregelnAttribute beschreiben Objekte und sollten weder klassenwertig noch mehrwertig seinabgeleitete Attribute sollten als solche gekennzeichnet werdenkontextabhängige Attribute sollten eher Assoziationen zugeordnet werden als Klassen

Attribute sind i.a. nur unvollständig in der Anforderungsbeschreibung definiert



KlassendiagrammExkurs: Identifikation von Attributen – Analytisch ...

Ist der Attributname geeignet?kurz, eindeutig und verständlich im Kontext der Klasseein Substantiv oder Adjektiv-Substantiv (kein Verb!)den Namen der Klasse nicht wiederholen (Ausnahme: „standardisierte“ Begriffe)nur fachspezifische oder allgemein übliche Abkürzungen verwenden

Klasse oder komplexes Attribut?Klasse: Objektidentität, Existenz unabhängig von der Existenz anderer ObjekteAttribut: keine Objektidentität, Existenz abhängig von Existenz anderer Objekte, Zugriff immer über das Objekt

Gehört das Attribut zu einer Klasse oder einer Assoziation?Liegen Klassenattribute vor?

Alle Objekte der Klasse besitzen für dieses Attribut denselben AttributwertEs sollen Informationen über die Gesamtheit der Objekte modelliert werden

Sind Schlüsselattribute fachlich notwendig?Schlüsselattribute werden nur dann eingetragen, wenn sie – unabhängig von ihrer identifizierenden Eigenschaft – Bestandteil des modellierten Domains sind

FehlerquellenFormulieren von Assoziationen als Attribute (Fremdschlüssel!)



KlassendiagrammExkurs: Identifikation von Operationen – Konstruktiv ...


Zeitwörter herausfiltern

FaustregelnWelche Operationen kann man mit einem Objekt ausführenNicht nur momentane Anforderungen berücksichtigen, sondern Wiederverwendbarkeit im Auge behaltenWelche Ereignisse können eintretenWelche Objekte können auf diese Ereignisse reagierenWelche anderen Ereignisse werden dadurch ausgelöst



KlassendiagrammExkurs: Identifikation von Operationen – Konstruktiv ...

Operationen aus dynamischen Modellen eintragenTragen Sie alle Operationen aus den Sequenz- und Kommunikationsdiagrammen einTragen Sie alle Operationen aus den Zustandsautomaten einPrüfen Sie für Aktivitäten in Zustandsautomaten, durch welche Operationen sie realisiert werden

Listenoperationen eintragenFügen Sie Listenoperationen einListenoperationen werden in der Analyse oft als Klassenoperationen realisiert

Verwaltungsoperationen nicht eintragennew(), delete() etc. werden nicht ins Klassendiagramm eingetragen

Operationen und GeneralisierungOperationen so hoch wie möglich in der Hierarchie eintragen

Beschreibung der Operationen erstellenBei einfachen Operationen informal, d.h. TextBei komplexeren Operation auch semiformale Spezifikation, z.B. Aktivitätsdiagramm, Zustandsdiagramm



KlassendiagrammExkurs: Identifikation von Operationen – Analytisch ...

Besitzt die Operation einen geeigneten Namen?Enthält ein VerbBeschreibt, was die Operation „tut“Ist eindeutig im Kontext der Klasse

Erfüllt jede Operation die geforderten Qualitätskriterien?Angemessener Umfang

Ist das „balancing“ erfüllt?Alle Attribute werden von den Operationen benötigt

FehlerquelleKeine Benutzeroberfläche spezifizieren



KlassendiagrammAssoziation

Assoziationen zwischen Klassen modellieren mögliche Objektbeziehungen (links) zwischen den Instanzen der Klassen

Angaben (optional):AssoziationsnamePfeilspitze über Kante drückt Leserichtung ausPfeilspitze am Kantenende: NavigationsrichtungMultiplizität am Ende einer Assoziation: Mögliche Anzahlen jener Objekte, die mit genau einem Objekt der gegenüberliegenden Seite in Beziehung stehen können

Kalender Termingehört zu1..* *

Assoziation



KlassendiagrammAssoziation – Navigationsrichtung

Eine gerichtete Kante gibt an, in welche Richtung die Navigation von einem Objekt zu seinem Partnerobjekt erfolgen kann

Ein nicht-navigierbares Assoziationsende wird durch ein »X« am Assoziationsende angezeigt

Navigation von einem bestimmten Termin zum entsprechenden Dokument

Umgekehrte Richtung - welche Termine beziehen sich auf ein bestimmtes Dokument? - wird nicht unterstützt

Ungerichtete Kanten bedeuten »keine Angabe über Navigationsmöglichkeiten«

In Praxis oft bidirektionale Navigierbarkeit angenommen

HypertextDokumentTermin zusatzInfo0..1



KlassendiagrammAssoziation als Attribut

Ein navigierbares Assoziationsende hat die gleiche Semantik wie ein Attribut der Klasse am gegenüberliegenden AssoziatonsendeEin navigierbares Assoziationsende kann daher anstatt einer gerichteten Kante auch als Attribut modelliert werden

Die mit dem Assoziationsende verbundene Klasse muss dem Typ des Attributs entsprechen Die Multiplizitäten müssen gleich sein

Für ein navigierbares Assoziationsende sind somit alle Eigenschaften und Notationen von Attributen anwendbar

HypertextDokumentTerminzusatzInfo: HypertextDokument [0..1]



KlassendiagrammAssoziation – Multiplizität

Bereich: »min .. max«Beliebige Anzahl: »*« (= 0.. *)Aufzählung möglicher Kardinalitäten (durch Kommas getrennt)

genau 1: 1

≥ 0: * oder 0..*0 ∨ 1: 0..1

fixe Anzahl (z.B. 3): 3Bereich (z.B. ≥≥3): 3..*

Bereich (z.B. 3-6): 3..6

Aufzählung : 3,6,7,8,9 oder 3, 6..9



KlassendiagrammAssoziation – Rollen

Es können die Rollen festgelegt werden, die von deneinzelnen Objekten in den Objektbeziehungen gespielt werden

Person

Insurance Contract

InsuranceCompany insurer

1 issued by *

refe

rs to

1..*

*

policyholder

husband

married to

Angestelltervorgesetzter

untergebener*

0..1

0..10..1wife

Beispiel 1:

Beispiel 2:



Ordnung {ordered} ist unabhängig von Attributen

EindeutigkeitWie bei Attributen durch {unique} und {nonunique}Kombination mit Ordnung {set}, {bag}, {sequence} bzw. {seq}

KlassendiagrammAssoziation – Ordnung und Eindeutigkeit

Queue QueueItem1 contains *{ordered}

Geordnete Mengeorderedorderedunique

Geordnete Menge mit Duplikaten (Liste)

sequence, seqorderednonunique

Multimenge, d.h. Menge mit Duplikaten

bagunorderednonunique

Menge (Standardwert)setunordereduniqueBeschreibungKombinationOrdnungEindeutigkeit



KlassendiagrammAssoziation – Exklusivität und Teilmenge

Exklusives Oder {xor}für ein bestimmtes Objekt kann zu einem bestimmten Zeitpunkt nur eine von verschiedenen möglichen Assoziationen instanziert werden

Teilmenge {subset}

Serie

1..*

ToDoEintrag

{sorted} 1..*

Termin

{xor}

{sorted}

1

1

Benutzer Termin1..* nimmt Teil *

*{subset}

koordiniert

1

teilnehmer

verantwortlicher



KlassendiagrammAssoziationsklasse 1/2

Kann Attribute der Assoziation enthaltenBei m:n-Assoziationen mit Attributen notwendig

Bei 1:1 und 1:n-Assoziationen sinnvoll aus Flexibilitätsgründen (Änderung der Multiplizität möglich)

Benutzer Termin*1..*

istVerschiebbar

*Person

namesozVers#adressegehaltfunktion

Firmanameadresse Anstellung

gehaltfunktion

1

Assoziations-klasse

Teilnahme



KlassendiagrammAssoziationsklasse 2/2

Mitarbeiter Projekt**

Projektanstellungqualifikationsprofilstundenrahmentagessatz

Mitarbeiter Projekt**

Projektanstellungqualifikationsprofilstundenrahmentagessatz

1 1

M1 A1

A3A4

P1

M2 P2

A2

M1 A1

A3A4

P1

M2 P2

Normale Klasse ungleich Assoziationsklasse



KlassendiagrammN-äre Assoziation

Beziehung zwischen mehr als zwei KlassenNavigationsrichtung ist nicht angebbarMultiplizitäten geben an, wie viele Objekte einer Rolle/Klasse einem festen (n-1)-Tupel von Objekten der anderen Rollen/Klassen zugeordnet sein können

Beispiel für eine ternäre (3-wertige) Assoziation: Kalender

TermintypBenutzer

*

**

Assoziations-klasse

Berechtigungrecht {set of [r, w, d]}

prüfeRecht(...)

NN--äärere AssoziationAssoziation



KlassendiagrammAggregation

Aggregation ist eine spezielle Form der Assoziation mit folgenden Eigenschaften:

Transitivität: C ist Teil von B u. B ist Teil von A ⇒ C ist Teil von A

Anti-Symmetrie: B ist Teil von A ⇒ A ist nicht Teil von B

UML unterscheidet zwei Arten von Aggregationen:Schwache Aggregation (shared aggregation)Starke Aggregation – Komposition (composite aggregation)



KlassendiagrammStarke Aggregation - Komposition

Ein bestimmter Teil darf zu einem bestimmten Zeitpunkt in maximal einem zusammengesetzten Objekt enthalten seinDie Multiplizität des aggregierenden Endes der Beziehung kann (maximal) 1 seinAbhängigkeit der Teile vom zusammengesetzten ObjektPropagierungssemantik

Die zusammengesetzten Objekte bilden einen Baum

A B

Dokument RandbemerkungGrafik

Textbaustein

* *

* *

*1

0..1 *

KompositionrolleB



KlassendiagrammStarke Aggregation vs. Assoziation – Faustregeln

EinbettungDie Teile sind i.A. physisch im Kompositum enthaltenÜber Assoziation verbundene Objekte werden über Referenzen realisiert

SichtbarkeitEin Teil ist nur für das Kompositum sichtbarDas über eine Assoziation verbundene Objekt ist i.A. öffentlich sichtbar

LebensdauerDas Kompositum erzeugt und löscht seine TeileKeine Existenzabhängigkeit zwischen assoziierten Objekten

KopienKompositum und Teile werden kopiertNur die Referenzen auf assoziierte Objekte werden kopiert



KlassendiagrammExkurs: Identifikation von Assoziationen – Konstruktiv ...

Welche Assoziationen lassen sich mittels Dokumentanalyse ableiten?

Aus Primär- und Fremdschlüsseln ermitteln

Welche Assoziationen lassen sich aus den Use Casesermitteln?

Welche Einschränkungen muss die Assoziation erfüllen?Eine Assoziation: z.B. {ordered}Mehrere Assoziationen: z.B. {xor}, {subsets Eigenschaft}



Kategorien von AssoziationenA ist eine Transaktion, die mit einer anderen Transaktion B verbunden ist

z.B. CashPayment – Sale; Cancellation – Reservation

A ist eine Position einer Transaktion Bz.B. SalesLineItem - Sale

A ist Produkt oder Dienst für eine Transaktion (oder Position) Bz.B. Item – SalesLineItem (or Sale); Flight – Reservation

A ist eine Rolle, die mit einer Transaktion B verbunden istz.B. Customer – Payment; Passenger – Ticket

A ist ein physischer oder logischer Teil von Bz.B. Drawer – Register; Square – Board; Seat – Airplane

A liegt physisch oder logisch in/auf Bz.B. Register – Store; Item – Shelf; Square – Board; Passenger - Airplane





Kategorien von AssoziationenA ist eine Beschreibung für B

z.B. ProductDescription – Item; FlightDescription – Flight

A ist in B bekannt, wird in B protokolliert/registriert/beschrieben/erfasst

z.B. Sale – Register; Piece – Board; Reservation –FlightManifest

A ist ein Element von Bz.B. Cashier – Store; Player – MonopolyGame; Pilot –Airplane

A ist eine organisatorische Untereinheit von Bz.B. Department – Store; Maintenance – Airline

A verwendet oder verwaltet oder besitzt Bz.B. Cashier – Register; Player – Piece; Pilot – Airplane

A befindet sich neben Bz.B. SalesLineItem – SalesLineItem; Square – Square; City -City



Ist ein Assoziations- oder Rollenname notwendig oder sinnvoll?

Namen sind notwendig, wenn zwischen zwei Klassen mehrere Assoziationen bestehenRollennamen sind gegenüber Assoziationsnamen zu bevorzugenRollennamen sind bei rekursiv Assoziationen immer notwendigRollennamen sind Substantive, Assoziationsnamen enthalten VerbenTest für Assoziationsname: „Klasse1 Assoziationsname Klasse2“ ergibt einen sinnvollen SatzRollenname: Welche Rolle spielt die Klasse X gegenüber einer Klasse Y?

Existieren zwischen zwei Klassen mehrere Assoziationen?Prüfen Sie, ob die Assoziationen

eine unterschiedliche Bedeutung besitzen oder/undunterschiedliche Multiplizitäten haben

FehlerquellenVerwechseln von Assoziation mit Generalisierung




Ist ein Schnappschuss (1- bzw. 0..1-Multiplizität) oder ist die Historie (many-Multiplizität) zu modellieren?

Ergibt sich aus den Anfragen an das SystemLiegt eine Muss- oder Kann-Assoziation vor?

Bei einer einseitigen Muss-Assoziation (Untergrenze ≥1 auf einer Seite) gilt:

Sobald das Objekt A erzeugt ist, muss auch die Beziehung zu dem Objekt B aufgebaut und B vorhanden sein bzw. erzeugt werden

Bei einer wechselseitigen Muss-Beziehung (Untergrenze ≥ 1 auf beiden Seiten) gilt:

Sobald das Objekt A erzeugt ist, muss auch die Beziehung zu dem Objekt B aufgebaut und ggf. das Objekt B erzeugt werdenWenn das letzte Objekt A einer Beziehung gelöscht wird, dann muss auch Objekt B gelöscht werden

Bei einer Kann-Beziehung (Untergrenze = 0) kann die Beziehung zu beliebigen Zeitpunkt nach dem Erzeugen des Objekts aufgebaut werdenBei einer Multiplizität von ≤ 1 auf beiden Seiten sind zwei Klassen zu modellieren, wenn

die Objektbeziehung in einer oder beiden Richtungen optional ist und sich die Objektbeziehung zwischen beiden Objekten ändern kanndie beiden Klassen eine unterschiedliche Semantik besitzen




Enthält die Multiplizität feste Werte?Ist eine Obergrenze vom Problembereich her zwingend vorgegeben (z.B. maximal sechs Spieler)? Im Zweifelsfall mit variablen Obergrenzen arbeitenIst die Untergrenze vom Problembereich her zwingend vorgegeben (z.B. mindestens zwei Spieler)? Im Zweifelsfall mit „0“ arbeitenGelten besondere Einschränkungen für die Multiplizitäten (z.B. eine gerade Anzahl von Spielern)?

FehlerquellenOft werden Muss-Assoziationen verwendet, wo sie nicht benötigt werden





Für eine Komposition giltEs liegt eine Ganzes-Teil-Beziehung vorDie Multiplizität bei der Aggregatklasse beträgt 0..1 oder 1Die Lebensdauer der Teile ist an die des Ganzen gebundenDas Ganze ist verantwortlich für das Erzeugen seiner Teile

Für eine Aggregation giltKommt selten vorEs liegt eine Ganzes-Teil-Beziehung vor

Im Zweifelsfall immer eine einfache Assoziation verwenden

FehlerquellenModellieren von Attributen mittels Komposition



KlassendiagrammGeneralisierung

Taxonomische Beziehung zwischen einer spezialisierten Klasse und einer allgemeineren Klasse

Die Spezialisierte erbt die Eigenschaften der AllgemeinerenKann weitere Eigenschaften hinzufügenEine Instanz der Unterklasse kann überall dort verwendet werden, wo eine Instanz der Oberklasse erlaubt ist (zumindest syntaktisch)Mehrfachvererbung kann spezifiziert werden

Universitätsangehöriger

Student Lektor

Tutor

...

Das Modell enthält mehrUnterklassen als dargestellt



KlassendiagrammExkurs: Identifikation von Generalisierungen – Konstruktiv ...

Lassen sich Generalisierungsstrukturen durch bottom-up-Vorgehen bilden?

Gibt es gleichartige Klassen, aus denen sich eine neue Oberklasse bilden lässt?Ist eine vorhandene Klasse als Oberklasse geeignet?Lassen sich für die neu gebildete Oberklasse Objekte erzeugen? (abstrakte Klasse!)

Lassen sich Generalisierungsstrukturen durch top-down-Vorgehen bilden?

Kann jedes Objekt der Klasse für jedes Attribut einen Wert annehmen?Kann jede Operation auf jedes Objekt der Klasse angewendet werden?Lassen sich für ursprüngliche Klassen Objekte erzeugen oder erfolgt dies nur noch für die Unterklassen? (abstrakte Klasse!)



KlassendiagrammExkurs: Identifikation von Generalisierungen – Analytisch ...

Liegt eine „gute“ Generalisierungsstruktur vor?Verbessert die Generalisierungsstruktur das Verständnis des Modells?Benötigt jede Unterklasse alle geerbten Attribute, Operationen und Assoziationen?Ist die ISA-Beziehung erfüllt, d.h., gilt die Aussage „Objekt der Unterklasse ist ein Objekt der Oberklasse“?Entspricht die Generalisierungsstruktur den „natürlichen“ Strukturen des Problembereichs?Besitzt sie maximal drei bis fünf Hierarchiestufen?

Wann liegt keine Generalisierung vor?Die Unterklassen bezeichnen nur verschiedene Arten, unterscheiden sich aber weder in ihren Eigenschaften noch in ihrem Verhalten (ein Attribut „Typ“ würde ausreichen)



KlassendiagrammBeispiel – CALENDARIUM

/auszeichnung: Farbebeschreibung: Stringtyp: Termintyp

EintragistOffen: bool

Kalender

Ansicht

nameberechtigung

Benutzer 1..* *nimmtTeil

stelltDar*

*

gehörtZu{ordered}

* 1..*

CALENDARIUM

Notifikation

verwaltetverwaltet

**

ergehtAn

erinnertAn

fälligPer: Datum

ToDoEintragwhDauerwhFrequenz

Seriebeginn: DatumZeitdauer: Zeithyperlink [0..1]: URLanzahlTermine: Int

Termin

{ordered}0..1

{ordered}

{xor}

*

*

/kollidiertMit

1..*

1..*

Personengruppe*

*

**

0..3 1

11

0..1



Paketdiagramm 1/2

UML-Abstraktionsmechanismus: Paket Modellelemente (z.B. Klassen und deren Spezialisierungen wie bspw. Anwendungsfälle oder Komponenten) können höchstens einem Paket zugeordnet sein

PartitionierungskriterienFunktionale KohäsionInformationskohäsionZugriffskontrolleVerteilungsstruktur....

Pakete bilden einen eigenen NamensraumSichtbarkeit der Elemente kann definiert werden als öffentlich »+« oder privat »-«

KlasseA

PaketX

KlasseB



Paketdiagramm 2/2

Verwendung von Elementen anderer Pakete

Elemente eines Pakets benötigen Elemente eines anderenQualifizierung dieser »externen« Elemente

Zugriff über qualifizierten NamenZugriff nur auf öffentliche Elemente eines Pakets

Import einzelner ElementeVoraussetzung: Sichtbarkeit des Elements ist öffentlich

Import ganzer PaketeÄquivalent mit Element-Import aller öffentlich sichtbarenElemente des importierten Pakets

PaketX

+KlasseA

PaketY::KlasseC

-KlasseB

PaketY

+KlasseC -KlasseD

«import»

«import»



Zustandsdiagramm 1/9

Ein Zustandsdiagramm (State Machine Diagram) beschreibt die möglichen Folgen von Zuständen eines Modell-elements, i.A. eines Objekts einer bestimmten Klasse

Während seines Lebenslaufs (Erzeugung bis Destruktion)Während der Ausführung einer Operation oder Interaktion

Modelliert werdenDie Zustände, in denen sich die Objekte einer Klasse befinden könnenDie möglichen Zustandsübergänge (Transitionen) von einem Zustand zum anderenDie Ereignisse, die Transitionen auslösenAktivitäten, die in Zuständen bzw. im Zuge von Transitionen ausgeführt werden




Beispiel-Klasse DigitalWatch

modemodeButtonButton

inc / min:= min+1inc / min:= min+1inc / hours:= hours+1inc / hours:= hours+1

modemodeButtonButton

modeButtonmodeButton

Display timeDisplay time

do/ do/ displaydisplaycurrentcurrent timetime

Set Set hourshours

entryentry/ / beepbeepdo/ do/ displaydisplay hourshours

Set Set minutesminutes

entryentry/ / beepbeepdo/ do/ displaydisplay minutesminutesnewnew

rekursiverekursiveTransitionTransition

modeButton()inc()

min : Integer = 0hours : Integer = 0

DigitalWatch



Zustand (state)Zustand i.e.S.Endzustand

Pseudozustände (weil transient)InitialzustandHistory-Zustand, Synch-Zustand, Gabelung, Vereinigung, etc.

Aktivität innerhalb eines Zustandsentry / aktivitätAktivität wird beim Eingang in den Zustand ausgeführtexit / aktivitätAktivität wird beim Verlassen

des Zustands ausgeführtdo / aktivitätAktivität wird ausgeführt, Parameter sind erlaubtevent / aktivitätAktivität behandelt Ereignis innerhalb des Zustands


Basiskonzepte – Zustand

Name

Name Name

do / Aktivität(...)entry / Aktivität(...)exit / Aktivität(...)

Set hoursentry/ beep

do/ display hours




Basiskonzepte – Zustandsübergang

Ein Zustandsübergang (state transition) erfolgt, wenndas Ereignis eintritt – eine evt. noch andauernde Aktivität im Vorzustand wird unterbrochen!und die Bedingung (guard) erfüllt ist – bei Nicht-Erfüllung gehtdas nicht »konsumierte« Ereignis verloren

Durch entsprechende Bedingungen können Entscheidungsbäume modelliert werdenStandardannahmen

Fehlendes Ereignis entspricht dem Ereignis »»Aktivität ist abgeschlossen««

Fehlende Bedingung entspricht der Bedingung [true]Aktionen auf Zustandsübergängen möglich

Spezielle Aktion: Nachricht an anderes Objekt sendensend empfänger.nachricht()

Beispiel:right-mouse-down (loc) [ loc in window ] / obj:= pick-obj (loc); send obj.highlight()

e[B] [¬B]




Basiskonzepte – Zustandsübergang: Ereignisarten

CallEvent: Empfang einer Nachricht: stornieren

SignalEvent: Empfang eines Signals: left_button_down

ChangeEvent: Eine Bedingung wird wahr: when(x<y)

TimeEvent: Zeitablauf oder Zeitpunkt: after(5 sec.)

Terminbeginndauerstornieren ()löschen()

löschen

löschen

Aktivnew

Storniertstornieren

Stattgefundenwhen(beginn+dauer<=now)

Eckdaten setzen



Verfeinerung eines komplexen Zustands(composite state) — geschachteltes ZustandsdiagrammODER-Verfeinerung

Disjunkte Sub-Zustände, d.h.genau ein Subzustand ist aktiv, wenn der komplexe Zustand aktiv ist

UND-VerfeinerungNebenläufige Sub-Zustände, d.h.alle Subzustände sind aktiv, wenn der Superzustand aktiv istDie Subzustände werden i.A. ihrerseits Oder-verfeinert

Hinweis auf ausgeblendeteVerfeinerung

Diese kann an anderer Stelledargestellt werden


Strukturierung – ODER- vs. UND-Verfeinerung

Z

X Y

ZA B

X Y

Z




Strukturierung – Beispiel

Lebenslauf eines Termins - ODER-Verfeinerung

Aktiv

Storniertstornieren

Stattgefundenwhen(beginn+dauer<=now)

löschenEckdaten setzennew




Strukturierung – Beispiel

Verschieben

do/ Teiln. benachr. u.Sicht aktualisieren

Aktuell

verschiebe (neuerBeginn)[not in Aktuell]/ beginn:=neuerBeginn

Nicht aktuell

when(beginn<=now) when(beginn+dauer<=now)

Eingetragen

Aktiv

Stattgefunden

Storniert

stornieren

Lebenslauf eines Termins - UND-Verfeinerung des Zustands »Aktiv«




BI-Anwendung: Modellierung/Simulation von T-Zellen

Quelle: Efroni, S.; Harel, D.; Cohen, I.R., Reactive animation: realistic modelingof complex dynamic systems, IEEE Computer, Volume 38, Issue 1, Jan. 2005.



Literatur… zu MDE & UML

BücherK. Czarnecki, U.W. Eisenecker: Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000D.S. Frankel: Model Driven Architecture – Applying MDA to Enterprise Computing. Wiley, 2003J. Greenfield, K. Short: Software Factories. Wiley, 2004V. Gruhn, D. Pieper, C. Röttgers, MDA, Springer, 2006Hitz et al: UML@Work - Objektorientierte Modellierung mit UML 2. dpunkt.verlag, 2006IEEE Computer, Special Issue on Model Driven Engineering. February 2006, Cover Feature : Model Driven Engineering byDouglas Schmidt, Vanderbilt University S.J. Mellor, M.J. Balcer: Executable UML: a foundation formodel-driven architecture. Addison-Wesley, 2002B. Rumpe, Agile Modellierung mit UML, Springer, 2005T. Stahl, M. Völter: Modellgetriebene Softwareentwicklung. dpunkt.verlag, 2005

Webseitenwww.codegeneration.net/www.metacase.comwww.planetmde.orgwww.omg.org/mda/www.modelware-ist.orgwww.eclipse.org/ecesiswww.eclipse.org/gmt/am3/zoos

ArtikelMarkus Völter: Sprachen, Modelle, Fabriken. verfügbar unter: http://www.voelter.de/data/articles/lmf.pdf

M1.x UML in der Bioinformatik UML in der...©2011 JKU Linz, Institut für Bioinformatik,...

Documents

Transcript of M1.x UML in der Bioinformatik UML in der...©2011 JKU Linz, Institut für Bioinformatik,...