Zum Inhalt springen
L

Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).

UML-Anwendungsfalldiagramm (Use-Case-Diagramm) für AP1 der IT-Berufe

Stefan Macke27:03 65.991 Aufrufe veröffentlicht Auf YouTube

Das Wichtigste aus dem Video

Tipp auf eine Zeit – das Video springt genau dorthin.

Transkriptautomatisch erstellt · 196 Zeilen
Herunterladen
  1. diesem Video geht's um das UML Use Case Diagramm oder auch anwendungsfalldiagramm auf Deutsch eines der Diagramme was in der iak Prüfung für
  2. Fachinformatiker sehr häufig dran kommt in der AP1 durchaus auch aber in AP2 für anwungsentwickler das ist es eigentlich auch Standard sage ich mal deswegen
  3. gucken wir uns heute mal an was man dabei alles so falsch machen kann das ist auch interessant aber vielleicht fangen wir erstmal mit den grundlegenden
  4. Bestandteilen an und dann gehen wir die Details auf geht's [Musik]
  5. so wie bei meinen anderen Videos zu UML Diagramm habe ich auch wieder ein Beispiel mitgebracht und das gehen wir jetzt einfach Schritt für Schritt durch
  6. gucke uns die ganzen syntaxelemente an was gibt es da was muss man zeichnen wie muss man das Zeichnen in welche Richtung müssen die Pfeile gezeichnet werden etc
  7. und ich würde sagen ja wir schauen uns da direkt mal ein Beispiel an ich habe da mal eins mitgebracht das use casase Diagramm fangen wir ganz vorne an wofür
  8. ist das überhaupt da wir wollen damit zeigen was das zu erstellende System tun kann wird also hoffe ich bei der Softwareentwicklung benutzt um zu zu
  9. erklären ja ganz grob was sind so die Use Cases die Anwendungsfälle die ein Benutzer unserer Anwendung mit dieser Anwendung durchführen kann ne was auf
  10. ganz hoher Ebene kann das System für ihn leisten quasi und da ist natürlich dann die Frage wie stellen wir das da und ich habe mal ein Beispiel mitgebracht das
  11. hier ist ein mehr oder weniger vollständiges usecase Diagramm ich mache das immer so dass ich die Syntax Elemente reinnehme die am
  12. wahrscheinlichsten auch in der Prüfung dran kommen es gibt so ziemlich bei bei jedem UML Diagramm noch 57 andere Sachen die man einbauen könnte theoretisch
  13. wobei das usec Diagramm das ist jetzt nicht so umfangreich tatsächlich aber hier würde ich sagen ist es erstmal alles drin was in den letzten Prüfungen
  14. so dran kam ja darauf kann man sich glaube ich erstmal fokussieren auf diese Elemente und die werden schon oft genug falsch gemacht deswegen würde ich sagen
  15. wir gucken uns die mal der Reihe nach an und schauen mal ja wie man die umsetzt und was man damit so macht also erstmal use casase Diagramm grobe Übersicht ich
  16. habe hier einen Webshop z.B und dieses System Webshop wir von einem Kunden benutzt oder auch von einem Mitarbeiter es gibt also zwei Personen das sind so
  17. Strichmännchen die heißen eigentlich Akteure kommen wir gleich drauf die mit unserem Webshop interagieren und was können die da machen da kann z.B der
  18. Kunde eine Bewertung erstellen oder die Lieferadresse ändern oder auch eine Bewertung löschen eigs darf das nur der Mitarbeiter und hier sieht man so eine
  19. vererbungsbeziehung das heißt der Mitarbeiter darf auch alles was der Kunde darf und so weiter und dann gibt's so zwei Beziehungen die wichtig sind und
  20. zwar einmal eine include Beziehung und einmal eine extens Beziehung zwischen use casases und die werden auch gerade in der Prüfung häufig verwechselt
  21. deswegen schauen wir uns die gleich auf jeden Fall an so das wä so erstmal so der Überblick wie ein USC Diagramm aussehen kann und jetzt gehen wir
  22. Schritt für Schritt mal rein wir fangen erstmal ganz einfach an was ist überhaupt das Größte was wir in dem use casase Diagramm sehen na ja das System
  23. was da benutzt werden soll das wollen wir ja beschreiben ne das heißt das ist der größte Anteil und das wird hier als so ein Ort noch mit so einer Lasche da
  24. oben dargestellt das nennt man d auch Systemkontext und das ist auch ganz wichtig dass dann z.B diese sogenann Akteure die mit dem System interagieren
  25. außerhalb dieses Kontextes sind also dieser Rahmen der umschließt mein System das was ich bauen will als Einheit und von draußen kommen dann die z.B Anwender
  26. die mit der mit dem System interagieren also wir fangen erstmal an und malen ein Rechteck mit so einer kleinen Lasche dran und da schreiben wir dann rein wie
  27. das System heißt wie im Beispiel oben eben z.B Webshop oder sowas ne dann haben wir Akteure das müssen nicht nur Menschen sein auch wenn das syntaktisch
  28. als Strichmännchen dargestellt wird ja das kann auch eine Maschine sein wenn wir heute z.B Anwendung entwickeln die mit einer REST API miteinander
  29. kommunizieren z.B dann können auch zwei Systeme miteinander reden das muss also nicht unbedingt ein Mensch sein wir nennen das einfach mal das ist irgendein
  30. ja Akteur halt der mit unserem System interagiert und den zeichnen wir außerhalb des systemkontextes um zu zeigen der kommt von draußen rein und
  31. macht irgendetwas mit unserem System und was macht er mit unserem System ja da möchte er halt seine use casases seine Anwendungsfall seine
  32. Anwendungsfälle umsetzen aufrufen durchführen was auch immer also das System bietet ihn bietet ihm eine Möglichkeit zu interagieren und bietet
  33. eine Funktionalität an die dieser Akteur mit dem System durchführen kann und das nimnt man halt eben anmeldungsfall und das wird als oval in das System also in
  34. den Systemkontext hineineezeichnet und der bekommt üblicherweise auch einen Namen und üblicherweise na ja also üblicherweise in vielen Prüfungen wird
  35. auch unterschiedich mal dargestellt mal sind das einfach Substantive mal sind das auch halbe Sätze sowas wie Buchung ja oder buchen oder Buchung durchführen
  36. oder sonst irgendwas also etwas was beschreibt was fachlich hier gemacht wird ne es ist eine fachliche Sicht ganz ganz wenig technisch das ususecase
  37. Diagramm ist das so das abstrakteste Diagramm was ich zeichnen kann von meinem System da sage ich nur in Anführungszeichen stichpunktartig du
  38. kannst mit diesem System folgendes machen zack zack zack zack aber ich gehe nicht in die Details wie der das gemacht wird das kommt dann später in dem
  39. anderen Diagramm sondern nur dass ich etwas machen kann also das was steht hier im Fokus ich habe mal ein Beispiel hier oben gemacht ich nenne die Dinger
  40. immer gerne ja mit so einem halben Satz mit einem Verb drin also Bewertung erstellen ne oder Lieferadresse ändern man kann das aber auch substantivieren
  41. z.B bewertungserstellung oder Adressänderung oder bewertungslöschung gruselig ne also von
  42. daher ich finde das mit so einem Verb immer ganz nett aber das ist so ein bisschen Geschmackssache ja wichtig wäre vielleicht nur dass du es in deinem use
  43. casase Diagramm dann einheitlich machst und nicht mal Substantiv mal mit Werb mal ohne das ist immer blöd entscheide ich einfach für eine Variante die dir
  44. gut gefällt und dann passt hat so also s Case kann jetzt durchgeführt werden von einem Akteur die Assoziation zwischen den beiden dass dieser Akteur genau
  45. diesen anmeldungsfall durchführen kann das machen wir jetzt mit so einem durchgezogenen strich mit einer ich Zoom hier noch mal rein oh Gott oh Gott Pixel
  46. Alarm ähm nicht aus gefüllten nicht geschlossenen also offenen Pfeilspitze also das übliche V ne was wir auch aus dem Klassendiagramm kennen nicht
  47. ausgefüllt und nicht geschlossen damit zeigen wir vom Akteur auf den usecase der Akteur ruft quasi den ususecase auf in diese Richtung geht der PIL und dann
  48. haben wir die beiden assoziiert das bedeutet der Akteur kann diesen usecase durchführen aufrufen machen ja das ist erstmal so das grobe und in einigen iak
  49. Prüfungen je nachdem welcher man guckt ist das schon fast alles was man kennen muss das heißt ich ma dann ein paar ovale schreib da einen Namen rein und ma
  50. ein paar Striche dazwischen im feil und dann bin ich fertig das reicht schon in einigen Prüfungen aus aber es gibt noch ein bisschen mehr und das wird auch in
  51. vielen Prüfungen dann abgefragt also ganz so einfach machen Sie es uns dann doch oft nicht und zwar gibt es Generalisierung und Spezialisierung und
  52. das ganze kann man sowohl auf die Akteure beziehen als auch auf Use Cases auch wenn letzterer Punkt in der Realität jetzt nicht so oft vorkommen
  53. sondern eher bei Akteuren aber vielleicht erst mal vorweg was heißt das jetzt wir kennen aus dem Klassendiagramm vielleicht schon diesen PIL hier eine
  54. durchgezogene Linie und eine geschlossene nicht ausgefüllte pilspitze im Klassendiagramm steht das für eine Vererbung eine Klasse erbt von einer
  55. anderen und genau das gleiche Prinzip gilt hier im usecas Diagramm denn dieser PIL in der im Klassendiagramm habe ich das zwar für erbung genannt aber
  56. eigentlich heißt das Ding Generalisierung das bedeutet nämlich dass ein spezieller Akteur von einem generellen Akteur etwas Erben kann also
  57. alle seine use casases übernimmt quasi ja das heißt schauen wir uns z Beispiel an der Sachbearbeiter kann die Stammdaten ändern und jetzt gibt es im
  58. System aber auch noch einen Administrator der Administrator kann auch Benutzer anlegen aber weil der eine Spezialisierung des Sachbearbeiters ist
  59. erbt er auch alle seine Usecases und kann demnach alles das was der Sachbearbeiter auch kann also z.B auch Stammdaten ändern ja das ist die Idee
  60. und meistens hat man in System eben so ein Rollenkonzept wo die rechte immer mehr werden aber die nächst höhere Rolle darf
  61. automatisch auch alles was die kleinere Rolle kann und das kann man super mit so einer Generalisierung darstellen also das heißt wenn ich ja in
  62. Anführungszeichen use casases wieder verwenden will dann kann ich einfach die die Akteure voneinander Erben lassen und dann haben die das ich habe hier oben
  63. noch reingeschrieben dass es häufig eine is Einbeziehung ist häufig nicht immer ja in diesem Fall würde das sowas heißen wie der Administrator ist auch ein
  64. Sachbearbeiter und darf das Ändern ob das in der Realität so ist ich glaube nicht in vielen Systemen wird das sicherlich getrennt sein aber ich habe
  65. mir das jetzt hier einfach mal so ausgedacht ja das gleiche Prinzip gilt bei use casases selbst auch die können voneinander Erben oder ja um es jetzt
  66. mal genau zu sagen andere use casases spezialisieren diese vererbungsbeziehung das kennst du vielleicht auch wir haben die Generalisierung in Richtung nach
  67. oben und die Spezialisierung nach unten also wir haben einen allgemeinen Fall z.B ja in diesem Fall Benutzer anlegen und dann gibt es speziellere Fälle davon
  68. Benutzer ist der allgemeine Fall und wenn ich jetzt einen Administrator anlege oder einen Sachbearbeiter dann ist das ja spezieller weil das sind
  69. besondere Formen von Benutzern deswegen nennt man das Spezialisierung die pile im uscas Diagramm gehen aber immer in Richtung der Generalisierung das heißt
  70. das konkrete zeigt auf das allgemeine ja genauso ist es hier auch genau wie im Klassendiagramm übrigens die Idee ist exakt die gleiche und hier sehen wir es
  71. bei den Use Cases auch wir haben benutzeranlegen als ganz allgemeinen generellen Fall und wir haben zwei spezielle Fälle nämlich Administrator
  72. und Sachbearbeiter anlegen und die gener Entschuldigung die spezialisieren Benutzer anlegen weil der PIL geht in Richtung der generellen des generellen
  73. Usecases ja das ist jetzt die dabei wie gesagt diese Syntax braucht man sehr selten in der Realität ja gibt es aber deswegen wollte ich sie mal einzeichnen
  74. das das hier ist durchaus häufig und wird dann auch in Prüfung häufig erwartet deswegen haben wir uns mal beides jetzt angeguckt so jetzt kommen
  75. wir zu den beiden Beziehungen so viele gibt's eigentlich nicht im usec Diagramm trotzdem kann man die sehr schön falsch machen ja 5050 Chance ne was war noch
  76. mal was habe ich in vielen Prüfungen leider schon falsch gesehen fangen mit der ersten an die ich sag mal häufiger vorkommt das ist die include Beziehung
  77. und das bedeutet Anwendungsfälle können andere anweldungsfälle inkludieren also halten oder ein einfügen einschließen sage ich mal ja und das bedeutet und das
  78. jetzt ganz wichtig dass diese Usecases die dort inkludiert werden immer immer immer immer auch ausgeführt werden wenn der inkludierende usecase ausgefüht wird
  79. was bedeutet das schauen wir uns an der Sachbearbeiter kann einen Vertrag storieren zum storniieren eines Vertrages muss eine
  80. Kündigungsbestätigung verschickt werden und der breiter erstattet werden es kann nicht sein dass ein Vertrag trag stoniert wird und nur der
  81. beitragestatttet wird es müssen immer immer immer ohne Ausnahme beide anderen use casases durchgeführt werden das heißt es ist eine
  82. obligatorische Beziehung wenn ich das mache dann muss ich alles was inkludiert wird auch immer machen und ich kann das nur noch mal wiederholen immer immer
  83. immer muss das sein ja weil das bringt wirklich so viele Prüflinge durcheinander also in diesem Fall besagt das usecase Diagramm dass der
  84. sachbearbeit eigentlich drei Sachen machen könnte mit dem System nämlich Vertrag stonieren eine Kündigungsbestätigung verschicken und
  85. weiterestatten das ist quasi dadurch dass sie der in clubbeziehung stehen wird quasi dieser PIL so ein bisschen sag ich mal fortgesetzt und man kann
  86. über diesen usease alle anderen erreichen und damit kann der Akteur quasi alles drei machen nur um zu zeigen dass diese wirklich immer auch
  87. mitgemacht werden müssen wenn ich ein Vertrag stoniere kann ich halt eine include Beziehung einzeichnen theoretisch könnte ich vom
  88. Sachbearbeiter auch noch ein PIL auf die Kündigungsbestätigung ziehen brauche ich aber nicht weil halt diese include Beziehung zwischen den use casases
  89. besteht das heißt es muss immer ausgeführt werden also heißt das dass sachbarbeiter das natürlich auch können muss sonst kann er es nicht immer
  90. ausführen logischerweise deswegen kann ich mir den Pfeil sparen also wir merken uns include heißt immer muss das Zeug mit ausgeführt werden und der PIL geht
  91. in Richtung dessen was immer ausgeführt werden muss also das was inkludiert wird wir sagen dieser usecase inkludiert das Verschicken einer Kündigungsbestätigung
  92. das heißt da geht der Pfeil in diese Richtung dessen was inkludiert werden muss und so kann ich ich Spoiler mal so ein bisschen schon fast eine Art
  93. Ablaufdiagramm aus meinem usecase diagram machen was ich aber gibt's ein auf Finger bitte nicht machen soll da kommen wir gleich noch mal drauf das ist
  94. einer der häufigsten Fehler weil ich könnte jetzt sagen ja der Eine inkludiert den anderen der inkludiert wieder den der inkludiert dann den und
  95. da habe ich so eine Art Flussdiagramm ja aber das ist im usecase Diagramm gar nicht Ziel das wollen wir hier nicht darstellen es ist hier nicht in dieser
  96. Reihenfolge wird hier was bearbeitet das ist gar nicht Ziel und auch gar nicht möglich eigentlich im uscas diagram zu zeigen hier geht es nur eine ganz
  97. statische allgemeine Sicht was ich mit dem System machen kann und dann kann ich sagen wenn ich das eine mache muss auch noch das andere mitgemacht werden aber
  98. es soll bitte nicht dazu missbraucht werden ja einen Ablauf darzustellen das macht man mit einem anderen Diagramm nämlich einem Aktivitätsdiagramm ja um
  99. das kurz auszuholen weil es wirklich so ein häufiger Fehler ist wenn ich mir jetzt vorstelle im usecase Diagramm sehe ich diesen ganz allgemeinen usecase
  100. Vertrag stonieren da kann natürlich jetzt ein Entwickler nichts me anfangen ja programmere das jetzt mal stoniere einen Vertrag keine Ahnung was muss denn
  101. jetzt passieren in welcher Reihenfolge welche Bedingung gibt es da das kann ich im usecase diram nicht darstellen und will ich auch gar nicht dafür gibt es
  102. gar keine Syntax wenn ich das jetzt machen möchte weil ich meinem Entwickler meiner Entwicklerin eine konkrete Vorgabe machen will wie das zu
  103. programmieren ist dann könnte ich mir jetzt vorstellen in einem coolen Tool ja dass ich auf diesen usecase hier so ein Doppelklick mache und dann ploppt ein
  104. Editor auf für ein Aktivitätsdiagramm denn das hat genau die Bestandteile die ich jetzt brauche um zu sagen mach das mach das wenn dann wiederhole
  105. zusammenführen auseinanderführen Tralala das kann ich alles im Aktivitätsdiagramm darstellen damit kann ich wirklich Algorithmen aufmalen das use casase
  106. Diagramm ist dafür überhaupt nicht gedacht deswegen bitte nicht von Anfang an hier das muss noch gemacht W und das und das und das und das das ist nicht
  107. das Ziel s es ist ein ganz abstrakter Blick auf meine Software ja bitte nicht durcheinander bringen gut das include deutet so ein bisschen darauf hin aber
  108. es geht darum nicht sondern es geht nur darum zu sagen dass es eine Abhängigkeit gibt zwischen den use casases ne wenn ich das eine mache muss ich auch das
  109. angemachen so wenn wir eine Beziehung haben für Pflicht muss immer gemacht werden obligatorisch dann gibt's auch eine andere Möglichkeit für optional
  110. eventuell wird etwas gemacht aber nicht immer ja und das ist die extens Beziehung und die schauen wir uns jetzt als nächstes an extens ist etwas
  111. komplizierter das include ist relativ easy zwei use casases ein PIL dazwischen übrigens wir haben uns die Syntax noch gar nicht angeguckt ist eine
  112. gestrichelte Linie und die gleiche pilspitze wie bei der Assoziation also einfach das V ne nicht geschlossen und nicht ausgefüllt und beim extens sieht
  113. der PIL übrigens genau gleich aus es sind immer gestrichelte Linien mit offener nicht ausgefüllter Pfeilspitze aber während da oben wirklich nur der
  114. PIL ausreicht und ich Bib dann include dran ja und das kann ich noch in diese französischen Anführungszeichen die GM schreiben dann wird noch ein bisschen
  115. schicker ist das hier unten doch ein bisschen schwieriger weil es reicht nicht nur aus dem PIL zu zeichnen und das ist auch gleich ein Fehler den viele
  116. im in der Prüfung D machen PIL dran extens Feierabend nein das reicht leider nicht so funktioniert das extens nicht das hat mehr Bestandteile und die
  117. schauen wir uns jetzt an Nummer ein Anwendungsfälle können andere Anwendungsfälle optional erweitern optional ist hier das Schlüsselwort
  118. include obligatorisch extend optional es kann erweitert werden muss aber nicht ja und allein daraus wäre jetzt die Frage wenn es das erweitern kann wann passiert
  119. das denn denn wenn das nicht immer der Fall ist muss ich ja irgendwie spezifizieren können dann wird es erweitert und dann nicht das heißt es
  120. ergibt sich schon aus dieser Idee dass ich mehr sündheichselemente brauche um das darzustellen include heißt immer da gibt's keine Ausnahme keine Begründung
  121. kein nichts wird einfach immer gemacht extend heißt es kann auch mal sein dass es nicht gemacht wird und deswegen muss ich aufschreiben können was denn
  122. vorliegen muss damit es gemacht werden kann eine Art Bedingung ja und dafür haben wir hier bei der extens Beziehung gleich zwei Sachen die wir reinzeichnen
  123. müssen und zwar einmal einen sogenannten Extension Point und ein Extension Point das ist ein Ereignis das Auftritt bei dem geprüft wird ob der anmeldungsfall
  124. erweitert werden soll oder eben nicht und ich habe mal ein Beispiel mitgebracht dann wird das vielleicht etwas
  125. passender angenommen ich bin an einem Geldautomaten ja und ich habe ich habe die ganzen Akteure jetzt mal rausgelassen es geht nur um die
  126. Beziehung ne das heißt ich habe hier was will ich beim Geldautomaten machen meistens Geld abheben dafür gehe ich dahin ja das heißt ich habe das ist der
  127. Akteur sorry habe ich ganz übersehen also der Bankkunde möchte Bargeld abheben das ist sein use casase geht zum Geldautomat holt Bargeld raus ja und das
  128. war's dann auch ne dann kann er wieder nach Hause gehen aber kennst du vielleicht von einen Geldautomaten die haben auch die Möglichkeit die
  129. Geldscheine die man ausgezahlt bekommt auszuwählen also nicht 100 € und dann kriegst du halt random irgendwie die Banknoten sondern Du kannst auch sagen
  130. 150er 220er einer ja und um das darzustellen dass der Bankautomat das kann kann man jetzt folgendes machen der Bankkunde kann Bargeld abheben aber es
  131. gibt jetzt an diesem Use Case Bargeld abheben ein sogenannten Extension Point und zwar Banknoten auswählen das heißt das ist etwas was ich machen will wenn
  132. ich diesen usecase durchführe und an diesem Extension Point kann jetzt ein weiterer usecase diesen usecase erweitern und wie sieht das jetzt aus
  133. dazu male ich an diesen extens File eine Notiz ne eine ein kleines gelbes posted siehst du hier mit der abgeknickten Lasche da und da drin werden jetzt zwei
  134. Sachen aufgeschrieben und zwar Nummer eins eine condition also ein eine Voraussetzung eine Bedingung die erfüllt sein muss und da drunter schreibe ich
  135. noch für welchen Extension Point das gilt denn es kann auch sein dass use casases mehrere Extension points haben nicht nur einen ja und um das jetzt mal
  136. zu vervollständigen wir gucken un das an der Bankkunde kann Bargeld abheben es gibt den Extension Point Banknoten auswählen wenn der Kunde die
  137. banknotenauswahl wünscht was ja nicht immer der Fall ist viele Leute interessiert das nicht wie die Banknoten rauskommen das heißt wenn ich das möchte
  138. dann registriere ich mich an dem Extension Point Banknoten auswählen unter der Bedingung dass die gewünscht ist und wenn das der Fall ist dann kommt
  139. der use casase Banknoten auswählen da dazu das heißt der Bankkunde kann mit meinem Geldautomaten auch Banknoten auswählen aber nicht einfach irgendwie
  140. so direkt sondern nur im Kontext des Abhebens von Geld logischerweise weil was soll ich bankn auswen w ich danach nicht ausgezahlt bekomme ist ja quatsch
  141. ne das heißt eigentlich will ich Geld haben aber ich erweitere die Barauszahlung um die Auswahl von Banknoten wirklich erweitern und das ist
  142. optional wie gesagt ich muss das nicht machen das ist meine freie Wahl nächstes Beispiel andersrum der Bankkunde zahlt Geld ein auch das machen wahrscheinlich
  143. meistens die Leute stopfen die Kohle rein fertig ja viele Leute wollen dann aber wahrscheinlich als kleinen Beweis dass es auch stattgefunden hat eine
  144. Quittung haben es gibt aber auch Leute die das nicht haben wollen es ist halt nicht verpflichtend es ist optional das heißt auch hier wieder es gibt ein
  145. Extension Point Bargeld einzahlen da gibt es jetzt Einzahlung beendet wenn ich meine Einzahlung beendet habe dann kann ich optional noch eine quitchung
  146. dren und das wäre dann so ich habe wieder so eine Notiz an der extensionensbeziehung der Extension Point ist Einzahlung beendet ne da steht
  147. er da steht er noch mal und dann ist die condition dass ich auch Geld eingezahlt habe in diesem Fall weil kann auch sag ich sage Geld einzahlen mach das Fach
  148. direkt wieder zu und nichts ist passiert dann kriege auch keine quitchung logischerweise sondern es muss schon Geld eingezahlt worden sein dann kann
  149. ich zusätzlich die Quitung drucken ja das ist mal so ein Beispiel wie gesagt so use casases können auch mehrere Extension points haben je nachdem wie
  150. man die halt erweitern möchte jetzt fällt mir kein spontanes Beispiel natürlich ein gibt's hier vielleicht noch be banknotenauswahl irgendwie was
  151. ähm das ist jetzt ein schlechtes Beispiel aber sowas wie hey abbrechen ich will doch nichts mehr auszahlen ja dann könnte ich hier vielleicht
  152. Extension Point Abbruch gewünscht oder so irgendwie was und sagen dann gehen wir wieder raus das ist jetzt nicht ganz so passend aber in anderen newscase
  153. diagram gibt's da vielleicht mehrere deswegen ist es wichtig dass wir die Extension points hier mehrere aufschreiben einfach
  154. untereinander weg wenn es mehrere gibt und weil ich denn jetzt halt auf diesen usecase mehrere extenspile habe muss ich ja schon sagen für welche Extension ist
  155. das denn jetzt gemeint und deswegen muss jetzt wangsläufig auch der Extension Point genannt werden auch wenn es nur einen gibt gleich dran gewöhnen hier
  156. stehen die Extension points und dieser Name hier muss eins zu ein auch hier unter Extension Point stehen um zu zeigen auf diese Extension zeige ich
  157. dann kommt noch die conditionition dazu übrigens conditionondition wie bei vielen anderen auch das ist in diesen geschweiften Klammern einfach wie so
  158. eine Art Guard cl drüber ne gut also guck noch mal oben Notiz da drin wird spezifiziert unter welcher Bedingung ein Anwendungsfall an welchem Extension Po
  159. erweitert wird das heißt Notizen die gibt's übrigens in jedem usecase Diagramm nicht in jedem UML Diagramm kann ich Notizen irgendwo dran malen
  160. dafür sind die da das ist ein syntaxbandteil jedes Diagramms um Sachen zu erklären in diesem Fall sind sie verpflichtend ich muss an den pile eine
  161. Notiz dann schreiben weil ich den PIL sonst nicht verstehen kann ich muss ihn also wirklich erklären mit genau genau dieser Aufbau mit diesem Aufbau
  162. condition Guard CL Extension Point Name des Extension points also noch mal grob Übersicht include muss immer gemacht werden da es keine Bedingung
  163. gibt einfach ein fil in Richtung des zu inkludierenden use casases include dran schreiben Feierabend extens bisschen schwieriger weil das
  164. optional ist muss ich sagen warum wann wie auch immer dieses Ding ausgeführt wird also brauch nicht nur den pile ich brauche noch ein Extension Point und ich
  165. brauche noch die Notiz die erklärt unter welcher Bedingung an welchem Extension Point etwas ausgeführt wird und jetzt sch schauen zuletzt noch mal die
  166. pilrichtung an die ist jetzt wenn man so will umgedreht zum include wir hatten gesehen so ich nenne das Ding jetzt mal oberuse Case hier ne der inkludiert die
  167. unteruse casases der pile geht also in Richtung der kleineren in Anführungszeichen Usecases beim extend ist ist genau andersrum die kleineren
  168. use casase erweitern den großen also geht der PIL in Richtung dieses großen use casases hier ne also man kann das wie auf auf
  169. Englisch tatsächlich lesen includ inkludiert also das inkludiert das andere nicht wird
  170. inkludiert sondern inkludiert das ist aktiv das inkludiert das und in die Richtung muss der feil gehen und genauso ist beim extend auch da macht man ein
  171. extend das heißt dieser Fall erweitert diesen und nicht wird erweitert durch ja das heißt lie einfach die Verben so wie sie da stehen includes
  172. und extend und dann ist ganz klar eigentlich in welche Richtung der fallil gehen muss ne der erweitert den der inkludiert den also in die Richtung muss
  173. der PIL immer zeigen so das waren die beiden Beziehungen und dann kommen wir schon zum Ende denn das waren eigentlich die
  174. syntaxelemente die es so in der Prüfung gibt für für newcas Diagramm und wie gesagt trotzdem weil es so obwohl es so wenig sind werden die ständig falsch
  175. gemacht ja und ein paar Sachen habe ich mal aufgeschrieben include und extend verwechselt habe ich auch ganz oft ne dann also ja wie gesagt bitte einfach
  176. merken include verpflichtend extend optional ja und daraus folgen schon die ganzen anderen Elemente die wir gerade gesehen haben ich muss eine Beschreibung
  177. dran schreiben etc das heißt das bitte einfach merken verpflichtend also obligatorisch vers optional das ist genau die semantische Unterscheidung die
  178. wir hier brauchen dann habe ich ganz oft das pile in die falsche Richtung zeigen das habe ich Gefühl in jeder Prüfung bitte merke dir einfach diese Verben
  179. includes und extens und dann ist klar in welche Richtung die Pfeile zeigen müssen und dann das habe ich ganz am Anfang schon gesagt use casase Diagramme werden
  180. missbraucht als Ablaufdiagramm in der Form dass man include include include include macht und dann noch ein extens und am besten noch eine
  181. Fallunterscheidung reinbaut bitte nicht machen das usece Diagram sind statische Diagramm es soll hier kein Ablauf gezeigt werden sondern es soll einfach
  182. nur die Möglichkeit gezeigt werden welche Use Cases überhaupt gemacht werden können so ein bisschen Vergleich Klassendiagramm Klassendiagramm ist auch
  183. statisch das zeigt nur welche Klassen es gibt aber nicht wann die wie in welcher Reihenfolge welcheer anderen Klasse was aufrufen dafür brauchen wir ein anderes
  184. Diagramm und zwar das Sequenzdiagramm ja bei dem usecase Diagramm wäre die Form um wirklich den Ablauf darzustellen eben ein Aktivitätsdiagramm damit kann ich
  185. dann also einen ein Algorithmus modellieren den ich brauche um so ein usecase zu implementieren also wenn ich jetzt an ein echtes Projekt denke dann
  186. würde ich als erstes ein Lastenheft aufschreiben und meine Anforderung drin stehen daraus abstrahiere ich dann ein usecase Diagramm und sag mit meinem
  187. System wie es du folgendes machen können bla bla blapp ja und wenn ich jetzt sagen will wie das genau passiert mache ich für jeden einzelnen usecase ein
  188. Aktivitätsdiagramm wo dann drin steht mit swimlanes ne der Akteur macht das in dem System und eine Fallunterscheidung und dann wird was parallelisiert und
  189. dann kommen die wieder zusammen und dann gibt's ne so das kann ich mit einem Aktivitätsdiagramm machen das hat im use cas Diagramm wirklich nichts verloren ja
  190. bitte nicht machen weder in deinem Projekt noch in der Prüfung bitte dafür ist dieses Diagramm nicht gedacht ja einer der häufigsten Fehler wie gesagt
  191. ja das wär es für heute würde ich sagen das war mein kurz ich zeig mal einmal das gesamte Ding ne wo alles dann drin ist noch mal die ganze Syntax auf einen
  192. Blick da war es ja da haben wir alle drin Akteure mit Generalisierung mit use casases extends und includes und so weiter ne das heißt m jetzt hast du
  193. nicht alles gesehen was du für die Prüfung zumindest brauchst und normalerweise auch für den Abschlussprojekt kompliziertere Sachen
  194. habe ich da e noch nicht gesehen ja gut damit sind wir für heute durch das wäre das use casase Diagramm im Schnelldurchlauf ich hoffe es hat dir
  195. ein bisschen geholfen ich wünsche dir viel Erfolg beim Zeichnen dieser Diagramme in der Prüfung und wir sehen uns beim nächsten Mal bis dann
  196. [Musik]

Zum Nachlesen

Akteur (UML)Ein Akteur (Actor, „Handelnder“) ist ein Modellelement in der Unified Modeling Language (UML), einer Modellierungssprache für Software und andere Systeme. Generalisierung (UML)Generalisierung (engl. Generalization) ist ein Modellelement in der Unified Modeling Language (UML), einer Modellierungssprache für Software und andere … KlassendiagrammEin Klassendiagramm ist ein Strukturdiagramm der Unified Modeling Language (UML) zur grafischen Darstellung (Modellierung) von Klassen, Schnittstellen sowie … AktivitätsdiagrammEin Aktivitätsdiagramm (englisch activity diagram) ist ein Verhaltensdiagramm der Unified Modeling Language (UML), einer Modellierungssprache für Software …