Simple restaurant sequence diagram

Ik worstel soms met tegenstrijdige gevoelens over het internet. Dat gaat niet over verslaving, maar over het conflict tussen wat het me oplevert en wat het me kost. Het internet is krachtig en het internet is frustrerend.  Dat laatste is misschien het minst voor de hand liggend; het overkomt me als ik een idee heb dat ik zou willen uitvoeren, maar dat na enig ge-Google allang door iemand anders is bedacht. En uitgevoerd. En goed ook. Dat zijn de momenten waarop ik me overbodig voel en in een hutje op de hei wil gaan wonen. Maar ja, daar is geen internet. Zie je het conflict? Want tegelijkertijd levert het internet ook alle informatie en inspiratie op die ik nodig heb bij de ideeën die ik wel wil uitvoeren. En die zijn er toch nog. De hei kan wachten, hij bloeit elk jaar opnieuw en ik straks misschien wat minder.

Dus, toen ik ging fietsen (of eigenlijk toen ik weer terugkwam, want het fijne van fietsen is nou juist dat je hoofd helemaal leeg wordt), bedacht ik dat de beeldtaal, waarover ik vorige keer droomde, ook alweer bestaat. Al jaren, en “iedereen” gebruikt het: UML, de Unified Modeling Language. Sterker nog, ik had UML hier zelf al min of meer gebruikt in een ouder artikel. Ik zal proberen hieronder het GUI-projectje uit de vorige artikelen te beschrijven in UML.

UML is een taal van diagrammen. Er is een 15-tal diagram-types, waarvan er niet meer dan 5 frequent worden gebruikt. Er zijn regels waaraan die diagrammen moeten voldoen, maar die regels worden met grote vrijheid (niet) toegepast. In de Java-cursussen die ik geef pas ik UML met zeer grote vrijheid toe, maar hier zal ik proberen wat strakker te zijn. De diagrammen die ik wil gebruiken zijn het class diagram, het communication diagram en het sequence diagram. Daarmee kunnen we de GUI beschrijven zonder te kiezen voor een programmeertaal, zelfs zonder kennis van een programmeertaal. De enige voorwaarde die wordt opgelegd door UML is: het ontwerp is object-oriented. Ik zou niet anders willen.

Ik begin met het communication diagram (vaak nog aangeduid met de oude naam collaboration diagram). Het toont een aantal objecten die samen een bepaalde functie hebben; anders gezegd: die samen een bepaald systeem implementeren. Het toont ook de referenties die ze naar elkaar hebben en de taken die ze elkaar laten uitvoeren. Een object wordt weergegeven door een rechthoek, met daarin zijn naam en zijn type in de vorm “naam:Type” (de onderstreping betekent dat het hier om een object gaat en niet om een class). Een referentie is een lijn tussen 2 objecten, terwijl een taak een pijl is die daarlangs wordt getekend. Je kunt die taak nog het beste zien als een opdracht die een object aan een ander object geeft. Sommige mensen spreken graag van een “bericht” (in het engels: message) dat van het ene object naar het andere wordt gestuurd. De nummering geeft de volgorde van de berichten aan (waarbij “2.x” betekent dat het bericht wordt veroorzaakt door bericht “2”).

GUI-communication

Voor mij is het communication diagram het belangrijkste, omdat het de grote lijnen in een systeem vastlegt. Pas daarna kun je je gaan bezighouden met details. Als je die volgorde zou omdraaien zou je vastlopen in de details, omdat je de grote lijnen niet kent.

De details van de objecten worden vastgelegd in class diagrams. Zoals altijd is een class een ander woord voor het type van het object. De class beschrijft wat objecten van dat type hebben (de gegevens die ze onthouden) en kunnen (de taken die ze uitvoeren). In het diagram zie je drie vakjes; het eerste vakje bevat de naam van de class, in het tweede staat wat de objecten hebben, in het derde wat ze kunnen. Per class tekenen we een class diagram, zoals hieronder voor de class “Knop”.

Knop-UML

Het laatste type diagram is het sequence diagram. Het laat (net als het communication diagram) zien welke objecten er zijn en welke berichten ze elkaar sturen, maar de nadruk ligt hier op de volgorde van die berichten. Een stippellijn geeft de levensduur van een object aan. De tijd loopt van boven naar beneden; berichten bovenaan een stippellijn worden eerder gestuurd en ontvangen dan berichten eronder. Bij een X op de stippellijn wordt het betreffende object overbodig en kan het worden verwijderd. Een rechthoek op de stippellijn is een functie (een taak) die wordt uitgevoerd n.a.v. een bericht. Binnen een functie worden weer andere berichten gestuurd naar andere objecten. Probeer te begrijpen wat er gebeurt, en vergelijk het met de pseudo-code in “Een GUI, iets concreter”.

GUI-sequence

Zo, de GUI beschreven in alweer een andere taal. Een taal “zonder” woorden, dit keer. Een plaatje zegt meer dan duizend woorden, toch? Daarom gebruik ik altijd diagrammen tijdens de cursussen. Om het allemaal wat minder abstract te maken. Denk ik. Maar weet je wat nou het gekke is? Veel cursisten vinden juist de plaatjes abstract. Ze willen code zien om het concreter te maken. Code, geschreven in een “echte” programmeertaal. Zoals Java. Het zijn juist de meer ervaren cursisten die in de plaatjes het systeem doorzien. En zo schiet UML dus aan zijn doel voorbij als het om leren programmeren gaat. Misschien is de taal Scratch daarvoor geschikter (al is die vooral bedoeld voor kinderen). Maar voor de vastlegging van de functionaliteit van een systeem is UML onmisbaar. Voor UML geen hutje op de hei.

Advertenties