UML

So#wareprak*kum2007

18.04.07 SoPra'07 2

Inhalt

• Mo*va*on

• Eigenscha#en

• Sichten

• Klassendiagramm

18.04.07 SoPra'07 3

ProundContra

• „UML‘sjustpain/ng“DavidSchmidt,KansasStateUniversity2006

• “TheUMLasaFormalModelingNota/on”R.Franceetal.,FloridaAtlan*cUniversity1997

18.04.07 SoPra'07 4

Mo1va1on(I)

• fürdieEntwicklungkomplexerSystemeistModellierungunabdingbar

• Modellierung– Abstrak*onderRealität

– mitKonzentra*onaufdiewesentlichenAspekte

18.04.07 SoPra'07 5

WarumModellierung?(I)

• Beispiel1:

BaueinerHundehüZe– einfacheArbeitsschriZe– einfacheWerkzeuge

– einfacherBauplan

• keineArchitekturnotwendig!

18.04.07 SoPra'07 6

WarumModellierung?(II)

• Beispiel2:

BaueinerKathedrale– aufwendigeArbeitsschriZe

– vielespezielleWerkzeuge

– komplizierteBaupläne

• ohneArchitekturnichtrealisierbar!

18.04.07 SoPra'07 7

Mo1va1on(II)

• Modellierunghil#– dieStrukturunddasVerhalten

• zubeschreibenund

• zudisku*eren

– dasSystemzuverstehen

– dieProbleme• zuerkennenund

• zubeheben

18.04.07 SoPra'07 8

Mo1va1on(III)

• Modellierungkann– dieStrukturunddasVerhaltenspezifizieren

– dasSystemvisualisieren

– auseinerVorlageeinSystemkonstruieren

– Entscheidungendokumen*eren

18.04.07 SoPra'07 9

Mo1va1on(IV)

• Modellierungbraucht(zurRealisierungdieserAspekte)– eineeinheitlicheund

– umfassendeNota*on

UMLUnifiedModelingLanguage

18.04.07 SoPra'07 10

Eigenscha?en

• Visualisierung– Konstrukte:z.B.Diagramme

• heute:Klassendiagramme

• Spezifika*on– sehrabstrakt:Stereotypen– sehrimplemen*erungsnah:„No*zen“,OCL

• Konstruk*on– ForwardEngineering– ReverseEngineering

• Dokumenta*on– Spezifika*on:Analyse,Design– Implemen*erung:Quellcode,Tesjälle

18.04.07 SoPra'07 11

Sichten(I)

• UnterteilungderKonstrukteinSichten• Weshalb?

– BetrachtungdesSystemsauseinerbes*mmtenPerspek*ve– FokussierungaufeinenspeziellenSachverhalt

• Warum?– essindverschiedenePersonengruppeninvolviert

• Kunde,Benutzer,• Analy*ker,Entwickler,• Tester,u.s.w.

– hilfreichfürdasVerständnis

18.04.07 SoPra'07 12

Sichten(II)

• StrukturelleKlassifika*on– ObjekteundderenBeziehungzuanderenObjekten

• DynamischesVerhalten– ÄnderungdesSystemsinAbhängigkeitderZeit

• ModellManagement– Organisa*ondesModellsansich

18.04.07 SoPra'07 13

Sichten(III)

18.04.07 SoPra'07 14

Klassendiagramm(I)

• Klassenstellendas„Vokabular“desSystemsdar

• SiebildendieBasis,aufderalleanderenKonstrukteauoauen

18.04.07 SoPra'07 15

Klassendiagramm(II)

18.04.07 SoPra'07 16

Findungsprozess

• Iden*fika*onvon„Dingen“,dieBenutzerundEntwicklerzurBeschreibungdesProblemsundderLösungbenutzen

• HilfsmiZel:– Anwendungsfall‐basierteAnalyse

– CRC‐Karten(CRC=Class,Responsibility,Collabora*ons)

18.04.07 SoPra'07 17

Verantwortlichkeiten

• InderAnalyse‐PhasewerdenKlassenVerantwortlichkeitenzugeteilt;Ausgewogenheitistwich*g

• ErstinderEntwurfs‐undImplemen*erungsphasewerdenAZributeundOpera*onenfestgelegt,umdiespeziellenVerantwortlichkeitenzubewerkstelligen

18.04.07 SoPra'07 18

Sichtbarkeit

• Sichtbarkeit(Visibility)=FestlegungderZugriffsrechteandererKlassenaufdieAZributebzw.Opera*oneneinerKlasse– public(+)

• JedebeliebigeKlassedarfzugreifen

– protected(#)• NurdiedefinierendeKlasseselbstundvondieserabgeleiteteKlassendürfenzugreifen

– private(‐)• ZugriffnurdurchdiedefinierendeKlasse

18.04.07 SoPra'07 19

Sichtbarkeit(II)

• GraphischeDarstellung:

18.04.07 SoPra'07 20

AIribute

• ADribut(AZribute)=mitNamenverseheneEigenscha#einerKlasse

• Klassekannbeliebigviele(auchkeine)AZributebesitzen

18.04.07 SoPra'07 21

AIribute(II)

• VerschiedeneDetaillierungsgrademöglich

• GenerelleSyntax:[Sichtbarkeit]Name[[Mul*plizität]][:Typ][=ini*alerWert][{Eigenscha#}]

18.04.07 SoPra'07 22

AIribute(III)

• Eigenscha#enfürAZribute– changeablekeineRestrik*on(Standard)

– frozenWertdarfnichtmehrgeändertwerden,nachdemdasObjektini*alisiertist

18.04.07 SoPra'07 23

Opera1onen

• Opera/on=mitNamenversehenesVerhalteneinerKlasse,dasfürjedesObjektdieserKlasseangefordertwerdenkann

• Opera*onenkönnendenZustandeinesObjektesverändern

18.04.07 SoPra'07 24

Opera1onen(II)

• VerschiedeneDetaillierungsgrademöglich

• GenerelleSyntax:[Sichtbarkeit]Name[(Parameter‐Liste)][:Rückgabe‐Typ][{Eigenscha#}]

18.04.07 SoPra'07 25

Opera1onen(III)

• Signatur=Name[(Parameter‐Liste)]

• EinzelnenParameterderSignaturhabendiefolgendeSyntax:[Richtung]Name:Typ[=Standard‐Wert]

18.04.07 SoPra'07 26

Opera1onen(IV)

• Richtungen– in

• Eingabe‐Parameter;darfnichtgeändertwerden

– out• Ausgabe‐Parameter;ÜbermiZlungvonInforma*onzumAufrufer

– inout• Eingabe‐Parameter,dermodifiziertwerdenkann

18.04.07 SoPra'07 27

Opera1onen(V)

• Eigenscha#enfürOpera*onen:– leaf

• Opera*ondarfnichtüberschriebenwerden(Java:final,C++:nicht‐virtuelleFunk*on)

– isQuery• AusführungderOpera*onändertdenSystemzustandnicht(keineSeiteneffekte)(C++:constFunk*on)

18.04.07 SoPra'07 28

AbstrakteKlassen

• InkomplexerenKlassenhierarchienwerdenüblicherweisegewisseKlassenalsabstrakt(abstract)spezifiziert

• AbstrakteKlasse=Klasse,vondereskeinedirektenObjektegebendarf(Java:abstract,C++:mind.einereinvirtuelleFunk*on)

• ZurNutzungderFunk*onalitätvonabstraktenKlassenleitetmaneigeneKlassenvondiesenab

18.04.07 SoPra'07 29

AbstrakteKlassen(II)

• GraphischeDarstellung:– Klassennamewirdkursivgeschrieben

18.04.07 SoPra'07 30

AbstrakteOpera1onen

• EbensolassensichOpera*onenalsabstraktspezifizieren(Java:abstract,C++:reinvirtuelleFunk*on)

• AbstrakteOpera*onenmüsseninabgeleitetenKlassenimplemen*ertwerden

• GraphischeDarstellung:– Opera*onsnamewirdkursivgeschrieben

18.04.07 SoPra'07 31

Generalisierung

• Generalisierung(Generaliza*on)=BeziehungzwischeneinemallgemeinenElement(hierOberklasse(Superclass))undeinemspeziellerenElement(hierUnterklasse(Subclass))

• DurchGeneralisierungerbt(inherits)dieUnterklassedieStrukturunddasVerhaltenderOberklasse

18.04.07 SoPra'07 32

Generalisierung(II)

• Unterklasseerweitertodermodifizierti.a.Funk*onalitätderOberklasse

• VorteilederGeneralisierung:– ReduzierungdesImplementa*onsaufwandes

– OberklasseistdurchUnterklasseersetzbar

– NutzungvonPolymorphie

18.04.07 SoPra'07 33

Generalisierung(III)

• GraphischeDarstellung:– LiniemitDreieckandemEnde,welchesaufdieOberklassezeigt

18.04.07 SoPra'07 34

Assozia1on

• Assozia/on(Associa*on)=strukturelleBeziehungzwischenElementen

• MiZelsAssozia*onmodelliertmandiedirekteZugriffsmöglichkeitderbeteiligtenElementeaufeinander

18.04.07 SoPra'07 35

Assozia1on(II)

• GraphischeDarstellung:– LiniezwischenbeteiligtenElementen

18.04.07 SoPra'07 36

Namen

• Assozia*onkannmiteinemNamenversehenwerden,umdieBeziehungzuverdeutlichen

• Op*onal:AngabederRichtung,inwelcherderNamegelesenwird

18.04.07 SoPra'07 37

Rollen

• Klassen,dieaneinerAssozia*onbeteiligtsind,spielenindiesemKontexteinegewisseRolle

• DieselbeKlassekannverschiedeneRolleninanderenAssozia*onenspielen

18.04.07 SoPra'07 38

Mul1plizität

• Mul/plizitäteinerRolle=AnzahlderVerbindungen,dieesfüreineRollegebenkann

18.04.07 SoPra'07 39

Naviga1on

• KlasseAundKlasseBdurchAssozia*onverbunden– vonObjektderKlasseAkannmanzuObjektderKlasseBnavigierenundumgekehrt

• EinschränkungderNavigierbarkeitdurchexpliziteSpezifika*onderRichtungmitPfeilspitze

18.04.07 SoPra'07 40

Naviga1on(II)

• Beispiel:

• EinschränkungderNavigierbarkeitbedeutetnicht,dassüberhauptnichtaufdasandereObjektzugegriffenwerdenkann

• ImVordergrundstehtdirekter,einfacherZugriff(i.a.durchSpeichernvonReferenz/Pointer)

18.04.07 SoPra'07 41

Sichtbarkeit

• FürAssozia*onlässtsich‐wiebeiAZributenundOpera*onen‐Sichtbarkeitfestlegen(KennzeichnungamRollennamen)

• Beispiel:– NurvonObjektderKlasseBenutzerselbstdarfaufdasPasswortObjektzugegriffenwerden

18.04.07 SoPra'07 42

Referenzen

• „EinführunginUML”DinoAhrUniversitätHeidelberg

• „Wirtscha#sinforma*kI“Prof.Dr.HermannSiebdratFachhochschuleBonn‐Rhein‐Sieg

18.04.07 SoPra'07 43

Buch

• “AnalyseundDesignmitUML2.1”BerndOestereich