UML

@Frank, wiki was het eerste waar ik heen ging voor informatie over Uml, en toen een beetje gegoogled, maar ik zie dat er heel veel verschillende UML Diagrams zijn? Maar welke heb je nodig?

Ik al een beetje zitten lezen in mijn boek. Ik kom tot de conclusie dat er 4 soorten van diagrammen zijn welke gebruikt kunnen worden binnen UML. Ik zit er aan te denken om mijn boek vereenvoudigd hier weer te geven in de vorm van een tutorial. Maar dan moet ik het wel eerst zelf snappen :) Dus ik ga in mijn vrije uurtjes (die zijn er wel weinig) er maar eens aan werken!

ooooow. dat... (thnx too frank :) )

Ik snap het!

Dat zuigt... -_-'

Ne serieus, die Flowcharts maken van programma's vind ik echt irri.
En een UML lijkt me ok niet fijn, je zit dan eerst een heel schema te maken enal.. wat ik altijd doe is gewoon: BEGINNEN... ik begin gewoon ergens, en maak het zo dat er altijd nog wat toe te voegen is..

Ik 'ken' 8 soorten diagrammen:
- Klasse-diagram
- UseCase-diagram
- Staat-diagram
- Activiteit-diagram
- Volgorde-diagram
- En nog 3 waarvan ik geen idee heb waarvoor ze zijn, en waar ik geen simpele nederlands vertalen van ken (Component-, Deployment- en Collaboration -Diagram)

Klasse diagram
Spreekt voor zich, je definieert je klasses, je bepaald de naam, de attributen met type, de methodes met argumenten en wat er uit komt (void voor niks), en je geeft de relaties met andere klasses aan, en welke class welke extend/implement etc.
Wordt dus alleen gebruikt icm OOP.

UseCase diagram
Hoe ik het simpel zie: Je bekijkt hoe je applicatie bekeken en behandelt wordt. (In dit geval een website), dus wat moet de gebruiker kunnen, wat moet de beheerder kunnen, en wat komt daar bij kijken.

Staat diagram Statechart
Deze gebruik ik zelf nog erg weinig, maar wat het volgens mij inhoud: Je geeft aan welke staat het object heeft op welk moment. Bijvoorbeeld: Stel je hebt een sessie-klasse (kan even niks beters verzinnen :+), als een bezoeker de website afsluit, zijn de sessies en dus het object inactief, als de gebruiker weer aanmeld zijn ze actief. Dat geef je aan in een statechart.

Activiteit-diagram
Een schema waarin je laat zien wat er gebeurt, op mijn school veel gebruikt voorbeeld: Ticket systeem. Gebruiker kiest band uit, aantal kaarten en datum. Systeem controleerd bij ticketserver of er nog genoeg tickets zijn voor dat moment bij die band, en geeft signaal terug etc etc.

Volgorde-diagram
Gebruik ik zelf toch vrij vaak, het helpt me namelijk om aan te geven welke methodes ik moet gaan maken. Het lijkt een beetje op Activiteit diagram, alleen anders ingedeelt, en je kijkt echt naar methodes, en niet naar handelingen.

En engelse UML Wiki pagina vond ik erg helder, en ik hoop dat het voor jou/jullie ook helderder is, en ik niet te veel hele stomme dingen heb verteld, want ik ben ook nog niet zolang bezig met UML :)

Voor mij zijn de UseCase diagrammen de belangrijkste, dat is echt de basis. En wanneer die niet goed is, dan kun je het verder ook wel vergeten. Tevens is dit deel van het ontwerpproces goed te begrijpen door de klant, je benoemt tenslotte de verschillende spelers en in grote lijnen wat er waar moet gebeuren. De UseCase diagrammen zijn tevens de basis waarmee het testplan wordt opgesteld en dus uiteindelijk ook de testscripts.

Per UseCase diagram ga ik ook altijd de requirements opstellen, ook dit is input voor het testplan en de testscripts.

Nu heb je 3 verschillende producten gemaakt die de basis zijn voor een goed systeem:
- UseCase diagrammen
- Requirement diagrammen
- Testplan

Wanneer deze door de klant zijn goedgekeurd, dan kun je echt gaan bouwen/verder gaan met ontwerpen en beginnen met testen.

Frank, ben het zeker met je eens, ik lees net me post weer, en zie idd dat dat niet naar voren komt, alsof volgorde diagram belangrijkste is. Maar ik begin ook altijd met usercase diagram..

Edit: Typo

En nog een edit: Voor UML gebruik ik Jude. Je moet alleen even registreren.