Post on 20-Oct-2019
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