Zum Inhalt springen
L

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

UML-Sequenzdiagramm für AP2 Fachinformatiker Anwendungsentwicklung

Stefan Macke30:17 29.439 Aufrufe veröffentlicht Auf YouTube

Das Wichtigste aus dem Video

Tipp auf eine Zeit – das Video springt genau dorthin.

Transkriptautomatisch erstellt · 238 Zeilen
Herunterladen
  1. [Musik] so heute wollen wir uns über das Sequenzdiagramm einmal unterhalten das
  2. ist eines der Big Five wenn man die so nennen kann die wir für die IT Abschlussprüfung lernen dürfen besonders als ansentwickler und ansentwicklerinnen
  3. und ich würde behaupten das Sequenzdiagramm das kam schon sehr sehr häufig in Abschlussprüfung dran vor allem auch jetzt in letzter Zeit in
  4. Verbindung mit bestimmten design pattern insbesondere z.B dem observer pattern das lässt sich nämlich vorragend mit so einem Sequenzdiagramm modellieren oder
  5. auch dokumentieren wie das funktioniert also jetzt gerade nach der neuung der IT Berufe wo auch im anwendungsentwicklungsbereich mehr UML
  6. testen design pattern etc kommt finden die immer wie ich finde ganz interessante Aufgabenstellung um die Sachen auch mal sinnvoll
  7. zusammenzubringen und dann war dann z.B eine Aufgabe hier ist das observer pattern malen sie mal das Klassendiagramm und programmieren Sie
  8. ein bisschen Code und hier das ganze noch bitte als Sequenzdiagramm darstellen also für mich finde ich immer so eine schöne Runde Aufgabenstellung
  9. und das Sequenzdiagramm ist jetzt nicht unbedingt das leichteste aber es gibt jetzt auch nicht so viele syntaxelemente aber im Detail muss man
  10. halt schon gucken was man wie richtig zeichnet da kann man dann schnell Punkte verlieren und deswegen wollen wir uns das Ding heute mal angucken und ähnlich
  11. wie ich das beim Klassendiagramm schon gemacht habe schalte ich jetzt mal um damit wir hier auch mal ein Sequenzdiagramm sehen und wir fangen
  12. vielleicht erstmal an wofür das Zeug da ist also ich habe es nicht gesagt aber ist natürlich Teil der UML unified modeling language mit der wir unsere
  13. Software insbesondere modellieren aber auch dokum tieren können und hier wäre auch gleich meine erste Frage zum Einstieg ob wir dieses Sequenzdiagramm
  14. eher für die Dokumentation oder für die Modellierung nutzen und das hängt einfach ganz davon ab was wir machen wollen wie eigentlich so ziemlich bei
  15. jedem Diagramm ich persönlich würde glaube ich eher dieses Diagramm nutzen um etwas zu dokumentieren und nicht um etwas zu modellieren grundsätzlich kann
  16. ich jedes Diagramm vor der Programmierung zeichnen oder nach der Programmierung und D hat halt ein unterschiedlichen Zweck wenn ich noch
  17. nicht genau weiß was ich überhaupt programmieren muss kann ich erstmal Diagramm zeichnen und hoffe dass das Problem dann dadurch besser zu verstehen
  18. und kannst D leichter programmieren dann würde ich es eher zur Modellierung benutzen oder ich habe meinen Code schon fertig und will das einfach nur noch
  19. verständlich dokumentieren anstatt in den Code reinschauen zu müssen dann nutze ich es halt zur Dokumentation ich persönlich bin der Meinung das
  20. Sequenzdiagramm würde man eher zur Dokumentation nutzen weil das werden wir gleich auch sehen wenn ich immer so ein bisschen runter scrolle das geht schon
  21. sehr ins Detail dieses Diagramm ne das heißt hier können komplett if und vor und ich weiß nicht was also wirklich ein ganzer Algorithmus kann mit so einem
  22. Sequenzdiagramm da gestellt werden und dann ist irgendwann die Frage lohnt sich das noch oder ist es nicht tatsächlich sogar einfacher in den Code zu gucken ja
  23. weil wenn ich mir jetzt überlege ich habe hier eine Fallunterscheidung da noch eine Schleife drin oder noch eine Unterscheidung drin also irgendwann habe
  24. ich dann ein riesengroßes Sequenzdiagramm und ob das dann so viel verständlicher ist als fünf Zeilen Code die ich sofort verstehe weil es aus if
  25. und vorschleifen besteht weiß ich nicht also das muss jeder selber entscheiden ich glaube diese Diagrammform ist eher dazu geeignet im Nachhinein etwas zu
  26. dokumentieren und dann auch eher auf einem High Level würde ich sagen also ich würde jetzt hier nicht anfangen und meine Kleine Methode mit wie gerade
  27. gesagt drei vorschleifen und einer ifanweisung irgendwie dokumentieren weil das kann ich viel schneller im Code lesen aber wenn ich auf einer höheren
  28. Ebene mir das angucke wie Arbeiten vielleicht Komponenten miteinander gerade wenn wir eine verteilte Anwendung haben eine Webanwendung eine Client
  29. Server wer schickt was wohin was kommt zurück was passiert dann so auf der Ebene kann ich ein Sequenzdiagramm auch super benutzen und da finde ich es
  30. passender als bis runter in den konkreten kleinen Algorithmus da jeden Fitzel darzustellen das kann ich schneller im Code lesen also meine
  31. persönliche Meinung ja in der EAK Prüfung glaube ich geht's auch oft in den in die Richtung der Dokumentation da werden normalerweise keine Algorithmen
  32. damit entworfen sondern eigentlich nur die vorhandenen modelliert im Nachhinein also dokumentiert so gucken wir uns das Ding einfach mal von vor bisschen an
  33. also erstmal ein konkretes Beispiel wo alles drin ist was aus meiner Sicht prüfungsrelevant ist alles ist mit Vorsicht zu genießen also das
  34. sequenzdiagram hat noch ein paar mehr syntaxelemente aber ich gehe jetzt hier auf die ein die hauptsächlich für die Prüfung relevant sind und meine Meinung
  35. nach auch für die Praxis also brauchen nicht bei allen Diagrammtypen alle Möglichkeiten die man damit abbilden kann wir finden immer in ganz ganz
  36. vielen Diagrammen diese Sachen die wir hier sehen vor und die anderen die lasse ich jetzt einfach mal aus sonst reden wir hier stundenlang darüber wer das im
  37. Detail wissen will gibt's genug Bücher die man sich da durchlesen kann das ist so erstmal so ein Überblick wie so ein Ding aussehen könnte und jetzt gucken
  38. wir uns mal die syntaxelemente einzeln an fangen wir erstmal noch mal ganz oben an wofür ist das Zeug eigentlich da es geht darum die Interaktion mit
  39. Nachrichtenaustausch zwischen Objekten darzustellen meist geht's darum Nachrichtenaustausch ne das war eigentlich mal die Idee der
  40. Objektorientierung dass ich Objekte Nachrichten schicken und die eigentliche Idee der Objektorientierung war dass diese Nachrichten asynchron sind das
  41. wissen viele gar nicht aber das was wir heute standardmäßig haben nämlich synchrone Nachrichten war eigentlich gar nicht die Idee sondern eigentlich ging
  42. es darum die leben alle fleißig vor sich hin schicken sich mal ein paar Nachrichten und irgendwann kriegen sie noch mal eine Antwort aber es war gar
  43. nicht so gedacht dass sie die ganze Zeit warten bis sie eine Antwort kriegen kriegen aber das nur so als als neben kriegsschaplatz das ist aber durchaus
  44. wichtig im Sequenzdiagramm weil je nachdem wie ich die pile gleich zeichne ist es entweder asynchron oder synchron und da muss man immer im Kopf haben der
  45. Standard ist asynchron und das ist bei unserer Programmierung aber genau umgekehrt da ist der Standard synchron und nicht asynchron aber gucken wir
  46. gleich noch mal wie mal se wir fangen mal oben an was brauchen wir denn wenn wir Interaktion zwischen Objekten darstellen wollen ja nun Objekte wären
  47. vielleicht ganz gut ja und diese Objekte sind wirklich im Sinne der Objektorientierung als Objekt te aus einer Klasse also Instanz einer Klasse
  48. zu verstehen die leben und sterben können und Dinge tun während ihrer Lebenszeit namentlich Algorithmen ausführen bei anderen Objekten irgendwas
  49. aufrufen Rückgaben verarbeiten was auch immer diese Dinger halt so tun und hier ist aber jetzt wie bei jedem anderen UML Diagramm auch grundsätzlich die Freiheit
  50. da dass ich so ein Objekt auch als irgendwas anderes definieren kann ich habe eben gesagt wenn ich jetzt hier nicht wirklich ein eine Klasse Client
  51. Server habe sondern einfach die beiden Programmkomponenten Client und Server darstellen will dann kann ich das auch einfach da reinschreiben ja letztlich
  52. sind das alles ja nur Hilfsmittel um mein Programm besser zu verstehen und da wird dann keiner sagen das ja aber jetzt nicht hundertprozentig korrekt weil es
  53. geht darum dass der Mensch der das liest das leichter versteht als in den Crew zu gucken ja von daher in der Praxis ist es vielleicht auch jetzt nicht unbedingt
  54. schlimm wenn ich z.B die pilspitze nicht durchziehe oder doch weil das Verständnis wird wahrscheinlich trotzdem gegeben sein aber für die Prüfung ist es
  55. natürlich sehr wichtig dass wir syntaktisch korrekt machen und deswegen werde ich auch wie beim Klassendiagramm darauf eingehen wie die Pfeile genau
  56. aussehen müssen weil es gibt eine eindeutige Definition und da schauen wir jetzt einfach mal drauf also Objekte ne die haben einen Lebenszyklus die werden
  57. irgendwann mal erzeugt mit new in den meisten Programmiersprachen und irgendwann werden die auch mal wieder ja getötet das passiert in den meisten
  58. Programmiersprachen heutzutage nicht mehr explizit sondern implizit der Garbage Collector kommt irgendwann und räumt die ab in einigen
  59. Programmiersprachen cc++ muss man die aktiv zerstören die Objekte ähm beides lässt sich auf jeden Fall darstellen im Sequenzdiagramm also der
  60. komplette Lebenszyklus eines Objekts kann damit modelliert werden Objekte werden so dargestellt ich habe hier oben so ein Kasten so ein Rechteck da steht
  61. einfach der Name des Objekts drin man kann das wirklich wie im objektdiagram machen als die konkrete Ausprägung also mein Beispiel klasse Auto dann habe ich
  62. hier den roten BMW als Objekt drin stehen ganz oft sieht man aber auch einfach oben nur den Klassennamen ja das heißt es wirk kein konkretes Objekt
  63. benannt sondern einfach nur ein Objekt der Klasse Auto da steht oben halt Auto drin ja ich könnte hier aber auch wie gesagt kleinen Server REST API irgendwas
  64. eintragen es geht D darum wer tut hier etwas wenn wir uns an den Standard haben halten sind das aber wirklich Objekte im Sinne der Objektorientierung und diese
  65. Objekte können jetzt miteinander interagieren und das heißt jetzt halt die schicken sich Nachrichten ne und in den meisten Programmiersprachen heute
  66. sind Nachrichten schicken gleichbedeutend mit Aufrufen von Methoden ja das heißt wir machen sowas wie Auto Punkt fahre und dann ist das
  67. ein Methodenaufruf und den würde ich dann hier modellieren und grundsätzlich ist es möglich wie bei der Programmierung halt auch wir wollen ja
  68. die echte Welt der Programmierung hier ab abbilden wir können Funktionen haben wir können auch Prozeduren haben das heißt Funktion die Rückgabewerte
  69. zurückliefern muss ich genauso modellieren können wie M wie Prozeduren die nichts zurückliefern ja und ich muss noch unterscheiden können asynchron oder
  70. synchron das war das was ich gerade schon gesagt habe dass das hier ganz wichtig ist und jetzt gucken wir mal einmal konkret auf die Syntax das hier
  71. wä jetzt ein Beispiel Fahrer und Auto Fahrer interagiert mit dem Auto das heißt der Fahrer sagt dem ao starte bitte deinen Motor und das habe ich
  72. jetzt mal als asynchrone Nachricht modelliert weil der Fahrer das ist jetzt ein pinkt ein bisschen in der Praxis nicht darauf wartet dass der Motor
  73. gestartet ist der erst nicht und macht in der Zeit nichts weiter sondern der sagt im Auto startte Motor das dauert dann 3 Sekunden und dann ist das Ding
  74. gestartet aber das Auto sagt dann nicht Motor gestartet du kannst losfahren sondern ich krieg das halt irgendwie implizit mit ich kriege also kein
  75. Rückgabewert und es ist asynchron das heißt da wäre der normale Aufruf ein durchgezogener PIL von Fahrer an Auto und da drüber steht dann der
  76. Methodenname also z.B starte Motor das darf man und soll man auch sehr technisch hier hinschreiben also hier darf gerne der komplette methodename mit
  77. Klammer auf und so und Klammer zu und wenn es Parameter gibt auch Parametern da drin stehen bzw an der stell wens Argumente und nicht Parameter ja
  78. grundsätzlich noch mal wir haben also diese Objekte die haben oben einen Namen und man liest diese Diagramme gar nicht gesagt von oben nach unten ja das ist
  79. ein Ablauf der oben anfängt und nach unten sich fortsetzt das heißt wenn ich dieses Objekt mir angucke und ich folge dieser gestricheten Linie die sogenannte
  80. Lebenslinie dieses Objektes dann kann ich wirklich von oben nach unten sehen was in welcher Reihenfolge passiert also genau wie bei einer Sequenz bei der
  81. Programmierung von oben nach unten wird das abgearbeitet und jetzt sehe ich also das erste was irgendwo passiert ist Fahrer der startet als allererstes den
  82. Motor sendet das ans Auto das Auto schickt offensichtlich nicht zurück das startet einfach den Motor und fertig und danach sagt der Fahrer dem Auto Mensch
  83. fahre mal bitte 100 km und das habe ich jetzt synchron modelliert weil 100 km fahren in der Zeit kann der Autofahrer nicht viel
  84. anderes tun als fahren wenn er nicht ein Unfall machen will deswegen sehen wir hier einmal den Unterschied zwischen synchron asynchroner Aufruf der
  85. asynchrone Aufruf hat eine nicht ausgefüllte pilspitze und jetzt habe ich hier planturml benutzt und das der Unterschied zur ausgefüllten
  86. fallilspitze nicht so extrem eigentlich müsste der hier komplett zu sein der PIL aber man sieht den Unterschied hier sind es einfach zwei Striche und hier ist es
  87. ein komplett ausgefüllter fallil quasi der unten noch mal zugeht und der komplett schwarz angemalt ist so wäre eigentlich der Standard das wäre dann
  88. ein synchroner Aufruf und dieser synchrone Aufruf habe ich jetzt mal modelliert gibt uns auch was zurück nämlich einen neuen Kilometerstand ich
  89. bin ja 100 km gefahren also hat sich der Kilometerstand verändert und diese Rückgabe Information die modelliert man mit einem gestrichelten Pfeil das heißt
  90. hier wird dann zurück vom Auto an den Fahrer etwas geliefert und was da geliefert wird das können wir dann z.B wie ein Variablen Namen auch benennen in
  91. diesem Fall habe ich mal neuer Kilometerstand dran geschrieben das heißt Fahrer ruft synchron auf fahre dann wartet er bis das Auto gefahren ist
  92. und kriegt dann zurück aha neuer Kilometerstand und dann kann er weitermachen und das letzte was er dann noch macht ist stoppe den Motor das ist
  93. wieder asynchron und dann ist die Bearbeitung hier vorbei entspricht nicht hunderprozentig dem wie es im warnleben ist ja aber nur von der Idee her erstmal
  94. Lebenslinie Objekte asynchroner synchroner Aufruf Argumente Rückgabewerte so sieht das Zeug hier aus dann gucken wir mal weiter was ich
  95. jetzt noch weg lassen habe das Diagramm was wir gerade gesehen haben war syntaktisch nicht ganz korrekt aber wir wollen das ja Schritt für Schritt
  96. aufbauen was jetzt nämlich doch dazu kommt ist die sogenannte Aktivierung von Objekten und die Aktivierung ist das während das Objekt entscheidet was
  97. passiert oder anders gesagt den Programmfluss steuert also wer hat gerade die Kontrolle darüber wie das Programm weiterläuft und das Modellieren
  98. wir mit diesem dicken weißen Kasten hier ja auf der Lebenslinie wir sehen das hier ist gestrichelt im Hintergrund wenn dieses Objekt die Kontrolle übernimmt
  99. kriegt das so einen schwarzen Balken auf seine Lebenslinie hier gemalt und schwarz ist jetzt ein bisschen übertrieben das ist ein nicht
  100. ausgefülltes Rechteck wie man hier sieht ja und das wird dann auf die Lebenslinie drüber gezeichnet quasi und während dieser Zeit steuert dieses Objekt jetzt
  101. wie es weitergeht man kann sie jetzt vorstellen ich rufe eine Methode auf und wenn ich jetzt in dieser Methode gelandet bin und dort wird die
  102. sequenziell abgearbeitet das ist genau der Zeitpunkt wo ich jetzt hier so einen Balken aufmalen muss ja was wie in der realen Welt auch so ist ein Objekt kann
  103. sich auch selbst aktivieren wenn ich z.B hier mal reingucke beim dateileser der übernimmt hier die Kontrolle hier startet der Balken und jetzt ruft er da
  104. unten an sich selbst eine neue Methode auf das heißt das Objekt ist in der einen Methode macht einfach ein Call auf eine andere Methode die in derselben
  105. Klasse definiert ist dann erhöht sich der aktivierungskontext und ich beschreibe es jetzt immer ganz gerne so diese diese Balken die würde ich mir
  106. vorstellen wie den Call Stack bei der Programmierung ne ich habe einen Methodenaufruf was passiert die Methode wird inklusive ihre Argumente auf den
  107. Stack gelegt und wenn die die nächste Methode aufruft wird die oben drauf gelegt und wieder oben drauf und wieder oben drauf ne der Stck ist ein auf
  108. Deutsch kellererspeicher na der immer nur oben aufgebaut wird und immer nur rückwärts wieder abgebaut werden kann ich kann niemals unten was rausnehmen
  109. wenn oben noch was drüber liegt ja deswegen kommt immer nur von oben was drauf als würde ich es in den Keller schmeißen ja und dann kann ich nur das
  110. wieder rausholen was ganz oben liegt das ist der Call Stack und den gibt's in jeder Programmiersprache wenn das Programm ausgeführt wird und genau
  111. diesen Stack quasi modellieren wir mit diesen aktivierungskontexten wenn ich hier sehe der dateiverarbeiter fängt an der ruft jetzt eine Methode auf während
  112. der ganzen Zeit sind wir ja noch in der Methode des dateiverarbeiters die läuft quasi ist der erste Eintrag auf dem Stack dann ruft der dateiverarbeiter
  113. öffne Datei auf beim dateileser jetzt kommt öffne Datei auf den Stack oben drauf das heißt wir haben jetzt die Methode unten läuft weiter aber die
  114. zweite da oben drauf übernimmt jetzt die Kontrolle und jetzt machen wir wieder weiter der ruft die nächste Methode auf die kommen wieder auf den Stack ja und
  115. jetzt gucken wir mal hier ist vorhanden der übernimmt die Kontrolle jetzt wird diese Methode die dritte aktuell auf dem Stack abgearbeitet und wenn die fertig
  116. ist dann wird der Stack abgeräumt die Methode fliegt runter und dann wird der Stack dafür benutzt wofürher gedacht ist nämlich zum Rücksprung zur vorherigen
  117. Methode dafür ist er ja eigentlich da Methode a Ruf B auf Ruf C auf woher soll der Computer wissen wo er zurück muss wenn fertig ist na ja nimmt die C vom
  118. Stack und springt dahin was oben drauf liegt und das ist B ja das heißt wenn wir das Ding hier abgebaut haben dann springen wir zurück und sind jetzt auf
  119. der zweiten Ebene im Stack und jetzt kommt der Aufruf an das Objekt selbst erhöht den Kontext wieder jetzt haben wir wieder drei auf dem Stack und auch
  120. wenn die Kleine wieder abgehakt ist wird abgearbeitet komplett abgearbeitet dann ist das Programm beendet also man kann wieder wirklich diese Balken sich so
  121. vorstellen wie den Stack wenn man das im Kopf hat weil die meisten Entwickler und entwicklerinen haben den Stack Verstand en weil sie den jeden Tag benutzen meist
  122. implizit dann kann man das glaube ich auch ganz gut aufzeichnen hier gut jetzt haben ich hier noch ein paar mehr Sachen drin nicht nur den den den Stack B die
  123. Aktivierung das sehen wir jetzt hier nämlich auch die Erzeugung von Objekten wir schon gesagt der gesamte Lebenszyklus von Objekten kann
  124. dargestellt werden und es kann so sein dass Objekte erst während der Sequenz erzeugt werden die müssen nicht von Anfang an da sein und das habe ich hier
  125. mal versucht zu modellieren der dateiverarbeiter startet mit einer Methode die hier nicht benannt ist ruf beim dateileser den es schon gibt eine
  126. Datei auf ja und der dateileser der erzeugt sich jetzt ein neues Objekt vom Typ dateiprüfer also wenn ich mir den Code vorstellen würde ne hier würde
  127. einfach stehen dateiverarbeiter auchummer mache und dann steht da drin dateileser Punk öffne Datei springt da rein und hier würde halt im Code drin
  128. stehen new dateiprüfer und dann wird daran ist vorhanden aufgerufen ja so wie das jetzt syntaktisch dargestellt wird ist die Objekte die schon da sind werden
  129. ganz oben einfach Ihre Lebens Linie beginnen und die die erst im Verlauf des Ablaufs erzeugt werden beginnen halt erst ein bisschen drunter sieht man ne
  130. ist einfach weiter unten und die werden dann mit einem mit new versehenden PIL erzeugt und das ist quasi dieser Teil hier ist die Syntax um zu zeigen das
  131. Objekt wird neu erzeugt und genau das Gegenteil das Objekt wird wieder weggeschmissen das macht man mit einem schönen offensichtlichen Roten Kreuz was
  132. einfach am Ende der Lebens äh des aktivierungskontext drunter gezeichnet wird ja ähm wie das jetzt technisch genau implementiert ist ist irrelevant
  133. also das Objekt wenn wir jetzt in Java z.B denken wird niemals hier sofort zerstört nur weil die Methode Weg ist ja aber soll ja darstellen können dass ein
  134. Objekt zerstört wird ob man da jetzt einen Destruktor aufruft oder auf den Garbage Collector wartet ist jetzt hier erstmal völlig irrelevant sondern wir
  135. wollen einfach nur zeigen der teilprüfer wird während des Ablaufs erzeugt und auch währenddessen wieder weggeschmissen der überlebt nicht den ganzen Ablauf
  136. sondern ist halt nur temporär quasi da und wie gesagt Syntax das Ding schieben bisschen nach unten dickes fettes rotes Kreuz heißt das Ding ist
  137. jetzt tot und ansonsten können wir jetzt von oben nach unten das Ding mal abarbeiten sehen dateiarbeiter ruft hier was auf erhöht den Kontext der erzeugt
  138. sich ein Objekt danach wird die Kontrolle abgeegben an dem Prüfer der wird danach kaputt gemacht der gibt auch was zurück nämlich ist die dat Tei
  139. vorhanden ja oder nein da kommt zurück ja und jetzt habe ich einfach den selfc mit eingebaut der dateileser ruft an sich noch eine weitere Methode auf prüfe
  140. encoding erhöht den Kontext und da gucken wir noch mal drauf da zeichnen wir einfach ein zweit ein zweites Rechteck über das vorhandene drüber aber
  141. nicht daneben sondern wirklich dass ich das so leicht überlappt wie man es hier auch sieht ne weil das da kann man jetzt schön dran sehen dass das jetzt quasi
  142. der Stack ist dass das aufeinander liegt ja habe ich auch schon die selten seltsamsten syntaktischen Sachen in der iak Prüfung korrigieren dürfen also so
  143. leicht versetzt da drauf da drüber zeichnen und dann nicht vergessen die rücksprungpfeile wenn ich das Ding aufgerufen habe und auch wenn es keinen
  144. Rückgabewert hat wenn es ein synchroner Aufruf ist ist muss es auch immer ein rückwärtspfeil geben weil synchron heißt ja ich rufe das andere auf und warte bis
  145. der fertig ist und wenn der aber nie fertig wird weil kein fallil zurückkommt dann kann ich nicht weitermachen das heißt synchrone Aufrufe müssen auch
  146. einen rückgabepil quasi haben und der sieht immer so aus dass er halt gestrichelt ist und in diesem Fall das hier ist wirklich ein ein Beispiel was
  147. man häufig sieht auch in ehak Prüfung durchaus ich rufe an mir selber eine Methode auf die läuft und dann wird die beendet was heißt ich muss den Stack
  148. auch wieder abbauen also und ich z mal s weit es geht da rein ja von diesem Rechteck aus geht der Pfeil zurück auf das darunter liegende Rechteck so muss
  149. das Aussehen ich springe von oben zurück zum darunter liegenden Rechteck das ist die syntaktisch korrekte Darstellung dafür so dann ist Aktivierung hier
  150. beendet geht zurück auf die letzte die letzten aktivierungskontext und dann ist das Ding abgearbeitet da haben wir jetzt also alles drin Erzeugung von Objekten
  151. Zerstörung und vor allem die aktivierungskontexte und da habe ich die Erfahrung ich Spoiler das schon mal in vielen iak Prüfungen wenn ich sowas
  152. korrigiert habe waren ganz oft die Fehler bei diesen aktivierungskontexten die waren gar nicht gezeichnet oder falsch oder waren nicht überlappend oder
  153. so etwas wurde ganz vergessen dass ein Methodenaufruf an sich selbst ja auch den Stack erhöht also da stecken ganz viele Fehlermöglichkeiten drin aus
  154. meiner Erfahrung in der Praxis so jetzt brauchen wir noch eine Kleinigkeit um wirklich komplette Algorithmen modellieren oder Dokument en
  155. zu können und bis lang haben wir eigentlich nur Sequenzen gesehen ne von oben nach unten machen machen machen machen aber wir brauchen noch mindestens
  156. zwei andere Bestandteile damit wir Algorithmen bauen können und zwar eine Verzweigung eine Fallunterscheidung oder eine Wiederholung und beides kann ich im
  157. Sequenzdiagramm darstellen auch wenn das vielleicht nicht unbedingt offensichtlich so heißt wie man sie erwarten würde aber von der Idee her ist
  158. das exakt das Fallunterscheidung und Wiederholung und da gucken uns mal die Syntax an die Dinger die das Umsetzen heißen
  159. Fragmente das ist auch etwas was was man mal gelesen haben darf wenn man mal Sequenzdiagramme sich anguckt da hatte ich auch in einer letzten Prüfung den
  160. Eindruck als hätte die Hälfte der prüfläe das noch nie gehört dass es so etwas gibt also die wussten gar nicht wie man sowas einzeichnet ja obwohl wenn
  161. ich mich nicht entsinne sogar auf dem Beiblatt die Syntax noch mal stand also völlig wild aber darf man kennen weil das sind halt super wichtige Elemente
  162. wenn ich einen Algorithmus darstellen kann oder muss ja und mir fehlen zwei von drei algorithmenbausteinen wie soll ich das machen also das funktioniert
  163. einfach nicht ne ich meine feilen Folgen ist das eine aber viel interessanter natürlich für Algorithmen ist ist Fallunterscheidung und Wiederholung und
  164. wie man das jetzt darstellt ist so in Form eines fragments und es gibt jetzt eben also die grundsätzliche Syntax der Fragmente und dann gibt es bestimmte
  165. Arten von Fragmenten und eine davon ist eine Fallunterscheidung und eine ist eine Wiederholung es gibt auch noch andere die lasse ich hier jetzt aber mal
  166. weg wie gesagt wollen auf das Fokussieren was für die Prüfung am wichtigsten ist und das ist genau das diese beiden Sachen denn dann kann ich
  167. komplette Algorithmen mit dem Sequenzdiagramm darstellen so wenn wir überlegen wie könnten wir so so ein Fragment nennen für eine
  168. Fallunterscheidung da wäre es ja viel zu offensichtlich einfach ein if dran zu schreiben ne weil das kennt ja jeder deswegen überlegen wir uns einen coolen
  169. anderen Begriff und nennen das alt und fragen uns was so helle soll old heißen ist die Abkürzung für alternative das heißt wir haben ja ein
  170. alternatives Verhalten entweder macht das Sequenzdiagramm das oder es macht was anderes also eine Verzweigung nur irgendjemand hat gesagt if ist viel zu
  171. offensichtlich lass uns das mal old nennen deswegen heißt das Ding t und das was wir hier sehen ist quasi ein if ja eine if Anweisung wie funktioniert das
  172. jetzt je nachdem was in diesem in dieser Alternative verarbeitet wird kann ich diesen dicken fetten schwarzen Kasten über alles das drüber Zehen was
  173. beteiligt ist in meinem Beispiel ist hier beteiligt der dateiverarbeiter und der dateileser man kann so eine Alternative aber auch nur auf einer
  174. Lebenslinie machen oder über drei oder vier in Weg ganz egal ich mache diesen dicken Kasten um alles drum herum was Teil ich sage jetzt mal auf codeebene
  175. dieses if Statements ist ne und jetzt kann ich mir das wirklich im Code so vorstellen ich habe ein if mit einem if Zweig und einem els Zweig und ich male
  176. diesen riesengroßen Kasten wie die geschweifte Klammer die das gesamte if Statement umfasst die es in ganz vielen programmiersparen gar nicht gibt ja die
  177. denken uns jetzt einfach mal und dann kann ich da drin unterscheiden in den if und in den els branch und das Ding was hier oben steht über dieser kleinen
  178. gestrichelten schwarzen Linie das ist quasi der if Zweig und das was da drunter steht das ist der els Zweig ja das heißt Syntax ist dickes fettes
  179. Rechteck über alles zeichnen was ich brauche dann mache ich oben links in der Ecke so eine Lasche ne dieses komische Ding was wir hier sehen dieser
  180. abgeschrägte rechteckige Bereich das ist so wie so wie so eine Lasche bei soem Ordner und da schreibe ich dann bitte auch unbedingt rein alt weil der einzige
  181. Unterschied zwischen diesen drei Fragmenten die wir hier sehen ist die Bezeichnung die Syntax ist exakt identisch das heißt wenn da nichts drin
  182. steht habe ich keine Ahnung ist das eine Schleife ist das eine was ist das ne ich muss das benennen wie das if Statement im Code das heißt da muss ein alt drin
  183. stehen und dann ist wie gesagt der obere Bereich abzutrennen mit so einer gestrichenen Linie das ist das if und was da drunter steht ist das els und
  184. wenn ich das jetzt noch weiter spezifizieren will wann ist überhaupt zu welchem Pfad kommt dann kann ich das mit diesen in eckigen Klammern geschriebenen
  185. Hinweisen hier machen die es auch in ganz ganz vielen anderen Diagrammen gibt wir werden uns noch das Zustandsdiagramm angucken da gibt's z.B auch Bedingungen
  186. für Zustandsübergänge und die werden exakt genauso modelliert das ist das Schöne an der UML die ist wirklich einheitlich über alle Diagrammtypen
  187. hinweg das heißt wenn ich so etwas habe wie eine Art Bedingung dann sieht das immer so aus ich habe das in eckigen Klammern stehen ja und wenn wir uns
  188. jetzt mal das Beispiel angucken und das versuchen zu verstehen der dateiverarbeiter öffnet die Datei und es könnte der dateileser sagen entweder ist
  189. die Datei erfolgreich geöffnet worden und in diesem Fall gibt er uns einen dateihandel zurück über dass ich auf die Datei zugreifen kann oder es ist eben
  190. nicht erfolgreich und dann kann ich ja sagen entweder er gibt ein Return Code zurück oder wie in vielen Programmiersprachen üblich heutzutage er
  191. schmeißt ein Exception ja und dann könnte ich z.B sagen in diesem erfolgreichen Fall gibt er uns ein Handle wenn es nicht erfolgreich war
  192. schmeißt er uns eine Exception um die Ohren damit ich auch damit dann hier was machen kann wenn ich das Modellieren will und dann könnte ich da dran
  193. schreiben in in Freitext wie man hier sieht ne öffne Datei erfolgreich Handel geht zurück oder eben datei nicht gefunden F not found Exception und jetzt
  194. kann ich überlegen wenn ich eine Datei öffne kannst noch 27 andere Fehler geben Festplatte voll falscher pfahrt weiß der geil was Datei ist nicht lesbar dann
  195. kann ich auch mit so einer Alternative durchaus mehrere fade modellieren ne das ist nicht nur if els sondern es ist eigentlich wenn man es überträgt auf
  196. coten Switch mit mehreren möglichen Pfaden ja wenn ich mehrere habe mache ich einfach noch eine gestrichelte Linie drunter und schreib den nächsten Fall
  197. drunter wieder mit so einer g da drüber z.B jetzt hier datei nicht gefunden und runter schreibe ich dann noch Datei konnte nicht gelesen werden oder sowas
  198. weil Rechte falsch sind ja dann dann kriege ich halt eine andere Exception das heißt die Alternative ist nicht eingestränkt auf zwei fade sondern
  199. durchaus auf mehrere und die trenne ich einfach durch die gestrich Linien ab und ich denke an diesem Beispiel wird das einigermaßen klar was hier passiert
  200. übrigens syntaktisch nicht ganz korrekt weil dieses also es konnte ich leider mit plant nicht anders darstellen aber dieser Balken hier müsste eigentlich
  201. auch bis dahin runtergehen ne weil jetzt geht dieser dieser return File kommt aus dem Nichts das kann eigentlich nicht sein aber plant UML wollte das leider
  202. nicht so zeichnen wie ich das gerne hätte eigentlich müsste der komplett durchgezogen sein hier bis da unten weil das Objekt lebt ja noch zu diesem
  203. Zeitpunkt und gibt uns dann halt eben die F not F Exception zurück so das ist das klassische if els wenn wir ein if els haben ohne els was es auch geben
  204. kann ja ein Art verkürzes if dann gibt's dafür ein anderes Fragment das sieht zwar genauso aus wie das Old da oben habe ich schon gesagt aber hat ein
  205. anderen Namen und zwar opt opt für optional das heißt entweder mache ich das oder nicht aber wenn ich es nicht mache mache ich keine Alternative
  206. deswegen ist es keine Alternative sondern halt einfach ein optionaler teil und das habe ich mal versucht so zu modellieren wenn jetzt der
  207. dateiverarbeiter die Datei zurückbekommt vom Leser dann entscheidet der gibt es dort vielleicht Kopfzeilen Beispiel ich will eine csvteil einlesen ne und erste
  208. Zeile stehen die Überschriften drin die Überschriften interessieren mich natürlich nicht ich will nur die Datensätze das heißt wenn jetzt da eine
  209. Kopfzeile drin steht dann soll bitte gemacht werden übers springe Kopfzeile aber ansonsten ja muss halt nichts machen weil dann gibt's ja keine
  210. Kopfzeile ne das heißt das Ding ist jetzt ein optional quasi eine Alternative ohne els das nennt man dann opt ja und als letztes nehmen noch die
  211. Loop mit rein dann haben wir es nämlich vollständig das hier oben ist also die Fallunterscheidung die Verzweigung und als drittes kommt jetzt noch die
  212. Wiederholung dazu und die sieht syntaktisch exakt identisch aus wie ihr seht nur dass da halt als Bezeichner Loop drin steht was jetzt durchaus
  213. einigermaßen sprechend ist also while oder vor hätte man natürlich auch nehmen können aber wie man hier sieht nutzen die gerne neue Begriffe und haben sich
  214. dann hier halt für Loop entschieden es gibt sogar Programmiersprachen wo man Schleifen mit Loop beginnt von na ja das passt sogar noch aber es deutet drauf
  215. hin was hier passiert ne es ist eine Schleife es wird wiederholt etwas durchgeführt und die Syntax ist exakt identisch wie bei dem anderen hier
  216. könnte ich z.B ein Abbruchkriterium reinschreiben ne solange es noch Zeilen gibt könnte ich reinschreiben ich könnte aber auch wenn wir uns Java angucken
  217. eine Art enhanced vorschleife bauen und sagen für jede Zeile mache folgendes oder noch einfacher für alle Zeilen ja also das ist das muss nicht 100%
  218. lauffiger Code hier sein es muss ja nur verständlich sein was hier passiert ja ich könnte also sowas reinschreiben wie für Zeile Z in Zeilen wenn mir das
  219. besser gefällt und dann könnte ich z.B Z hier als Parameter übergeben oder irgendwelche Dinge damit tun also da bin ich relativ frei es muss ja nicht
  220. laufiger Code sein wie gesagt und ansonsten ist das genau das gleiche wieder oben und ich habe ich es mal nachgebaut mit für alle Zeilen geh zur
  221. nächsten Zeile über geb die Kontrolle an den Leser damit er die Zeile liest und er gibt mir die Zeile zurück und jetzt passiert nicht mehr viel weil das muss
  222. irgendwann aufhören das Diagramm das heißt er würde jetzt dann einfach mit der nächsten Zeile weitermachen solange es noch Zeilen gibt und so habe ich dann
  223. die Wiederholung eingebaut und wie ihr seht Syntax exakt identisch man nennt das Zeug Fragment oder auf Englisch Fragment ja relativ ähnlich der Begriff
  224. und jetzt haben wir eigentlich alles was wir im ursprungsdiagramm da oben gesehen haben ja wir haben die Objekte mit ihren Lebenslinien mit ihrem Aktivierungs
  225. Kontext wir haben asynchrone synchrone Aufrufe wir haben hier eine Fallunterscheidung wir haben hier eine Schleife wir haben die äh Dekonstruktion
  226. eines Objekts das Erzeugen eines Objekts das heißt wir können wirklich quasi unseren ich sag jetzt mal Java Code den wir programmieren eins zu ein in soem
  227. Sequenzdiagramm darstellen jetzt habe ich aber als letzten Punkt noch mal einmal zwei Punkte glaube ich was man da falsch machen kann oder was mir halt
  228. aufgefallen ist was sehr häufig falsch gemacht wird und die hatte ich beide schon mal angeteasert äh das letzte hatten wir eben schon Fragmente so als H
  229. die die noch nie gegeben kommt mir ganz oft vor in Prüfung und das erste falsche pilspitzen da würde ich als Prüfer auf jeden Fall auff achten weil synchron
  230. asynchron ist halt wenn man jetzt mal einfach auf die Praxis schaut eine komplett andere Art und Weise zu programmieren ja es ist halt eben nicht
  231. och mach mal aus der fallspitz in der andere und schwup die wup läuft das auf einmal asynchron das funktioniert in der Praxis so nicht ne wer das schon mal
  232. programmiert hat synchron Aufruf easy peasy asynchron komplett anderes Modell ja weil ich krieg halt nichts zurück ich brauche ein eine Möglichkeit auf dieses
  233. bnis zu warten ich muss zurückgerufen werden können das kann ich nicht mal eben einfach so runter programmieren wie ich das gewohnt bin ne also da würde ich
  234. auf jeden Fall drauf achten die pile korrekt zu setzen und was ich immer ganz wichtig finde der Standard ist asynchron ja deswegen muss ich eigentlich bei 95%
  235. unseres Codes wahrscheinlich immer von diesem Standard abweichen weil die meisten von uns werden wahrscheinlich synchron programmieren in den meisten
  236. Methoden die wir so programmieren täglich jo das wäre jetzt meine Kleine Einfürung und Sequenzdiagramm mit allem was ich für die Prüfung und die Praxis
  237. wichtig finde und dann haben wir glaube ich nur noch drei Diagramme vor uns die wir uns no anschauen werden mit Sequenz Diagrammen werden wir jetzt erstmal
  238. [Musik] durchfute

Zum Nachlesen