[OOP]Klassen-diagrammen

[McFreak]

Beste mensen van het goede progleven, kunnen jullie mij een beetje in de goede richting schoppen want ik word gek.

Ik zit nu zeg maar in de 2e van het HIO(Hogere Informatica bullshit) en ben NOG STEEDS bezig met het ontwerpen van een normaal klasse diagram.
Usecase, sequence diagrammen, collaboration diagrammen, etc blaat.

Waar ik nou nog steeds niet goed in ben is het opzetten van een klassediagram. Volgens mijn leraar is het een beetje de zelfstandige naamwoorden uit de beschrijving van het toekomstige prog halen en daar nog een beetje in kloten.
Wat ik ook doe.
Maar elke keer als ik weer een klassendiagram heb, kijk ik er nog eens naar, gooi ik heel de boel weer weg en begin weer opnieuw omdat mijn hersens de logica gewoon niet toelaten.

Is er misschien een soort standaard of makkelijkere manier om dit voor elkaar te krijgen.
Ik werk in Rational Rose voor degene die dat willen weten.

Het lukt me wel om een klassediagram te maken, maar ik denk constant dat het gewoon niet goed is.
Voorbeelden van de leraar zijn ook verwarrend omdat hij het de ene keer van het ene opzicht naar kijkt en de andere keer weer van de hele andere kant.
IK heb wel is zo ver doorgevraagd aan een leraar dat ie het zelf ook niet meer snapte, wat moet ik daar nu mee?
Duizenden tutorials afgezocht etc.

Dis misschien een beetje vaag, maar das mijn probleem ook.
Dus beste OOP mensen, schop me is in de goede richting please, ik wil dit heel graag snappen.

[Verwijderd]

tja, 't blijft wat lastig, maar ga 'ns van het principe uit dat je alles in kleine stukjes opdeelt en dat je elk stukje volgend jaar apart wilt kunnen vervangen.

dan moet je dus met heel algemene methode-namen enzo werken (binnen jouw concept), want dat maakt het overzichtelijker en duidelijker.

ik denk dat je dan al een heel eind bent.

edit: zit je toevallig in utrecht? daar lullen ze ook al zo vaag. op m'n werk heb ik het pas goed geleerd, in de praktijk. dan snap je 't tenminste (tot die tijd begreep ik d'r ook niet veel van)

[McFreak]

Nah.. HIO in rotterdam op Coolhaven.
Das toch zon baggerschool <-- is flame ja ;)er zijn ook idd goede dingen.

Maar goed ik zal ff kijken of ik iets vatbaars kan posten hiero..

[Verwijderd]

Op maandag 12 november 2001 23:15 schreef RaR het volgende:
Nah.. HIO in rotterdam op Coolhaven.
Das toch zon baggerschool

nou, de HvU (Utrecht) is ook niet alles. maar goed, behalve OO heb ik al heel wat zinvolle (en niet zinvolle) dingen geleerd...

[McFreak]

tja, 't blijft wat lastig, maar ga 'ns van het principe uit dat je alles in kleine stukjes opdeelt en dat je elk stukje volgend jaar apart wilt kunnen vervangen.
dan moet je dus met heel algemene methode-namen enzo werken (binnen jouw concept), want dat maakt het overzichtelijker en duidelijker.

Kan je misschien een voorbeeld geven hiervan en heb je misschien url's van goede tutorials die ik misschien nog niet heb

[McFreak]

Tja.. zoiets heb ik gemaakt en ik denk dat het wel klopt..maar ook weer niet.
Ik weet gewoon niet wat ik ermee moet.

[reddog33hummer]

Uh ? wat voor UML gebruik jij ???
volgens mij heb je de verkeerde pijlen te pakke

[reddog33hummer]

Hio enschede, aangenaam zelfde problemen hier... docent a zegt het tegenovergestelde van docent b.

naja. wat ik er van gesnopen heb uit onze uml boekjes is:

een pijl betekend dat object kent die andere.
een lijn betekend ze kennen elkaar.
een lijn met een "swabbertje" (ruitje) betekend beziter van.
dit is een soort algemene collector.

zo'n driehoekpijl = lijn + driehoek is een erving of instantie van. Dus bij bv inherentance

[McFreak]

dit is rational rose
enneuh ik dacht dat er maar 1 UML was

Maar desalnietemin, hier dus een voorbeeld van mijn kundigheid met deze #&*&*(^#$:r]

edit:
enne met die docent a en docent b herken ik maar al te goed

[The - DDD]

Uhm, omzet overerven als een bon en dat weer overerven als een verkoper?

Eh... Of zijn die pijlen van een ander type?

Denk wat betreft overerven meer in de lijn van iets steeds preciezer definiëren...

Paarden, honden, katten, etc... zijn allemaal dieren.
Maar een Paard is geen hond, een hond is geen kat en een kat is geen hond.

De superklasse waarvan je overerft is dus een algemenere aanduiding voor datgene wat je overgeerft hebt.

Een auto is een voertuig.
Een bus is een voertuig.
Maar een auto is geen bus. Terwijl een bus en een auto wel een stuur hebben en voor en achteruit en links en rechts kunnen.

Dus wat kun je zeggen over een verkoper en een bon? Wat betreft overerving hebben ze niks met elkaar te maken. Het is wel zo dat een bon gemaakt wordt door een verkoper, maar dat betekent niet dat je een verkoper van een bon overerft.

Wil je een ultieme overervings diagram zien? Dan moet je is naar het dierenrijk kijken met hun zoogdieren, reptielen, etc... Katachtigen en hondachtigen zijn zoogdieren. Een spaniel is een hondachtige, een wolf is een hondachtige.

Ik denk dat als je daar de logica van ziet, dat het OO verhaal dan veel duidelijk wordt. Zorg dat je eerst snap wat de essentie is van een parent-child relatie.

[reddog33hummer]

De manier die wij volgen is zo.

je hebt een "virtuele regel" van een tabel:

pietje heeft een auto geparkeerd op vak 4B

daarna ga je extra informatie toevoegen:

persoon pietje heeft een voertuig auto geparkeert op vlak 4B

dan pak je een twede regel:

persoon sandra heeft een voertuig fiets geparkeert op vlak 6A

daar haal je de verschillen van weg

Persoon X heeft een voertuig V op vlak K

dit is dan je informatie model

[tomato]

The - DDD: Uhm, omzet overerven als een bon en dat weer overerven als een verkoper?

*LOL*

Eh... Of zijn die pijlen van een ander type?

* tomato hopes so...

[reddog33hummer]

stel je voor ik heb nu:

persoon X heeft Naam N
persoon X heeft Koe k

persoon X heeft auto A

auto A heeft snelheid S

ik kan hiervan 2 classen maken

Persoon
met een naam en een koe

Auto
met een snelheid

deze 2 zijn ook nog eens met elkaar verbonden.
nu komen uniciteiten in het spel
wie met wie verbonden en in welke mate

[McFreak]

Die open pijlen zijn generalisaties en die normale pijlen zijn associaties ..

dus de klasse bon erft de eigenschappen van de klassen verkoper en artikel want de gegevens daarvan moeten op de bon komen.
van alle bonnen moet dus de omzet worden berekend en een commissie voor de verkopers.

tara das mijn zienswijze

[The - DDD]

Op maandag 12 november 2001 23:58 schreef reddog33hummer het volgende:
De manier die wij volgen is zo.

je hebt een "virtuele regel" van een tabel:

pietje heeft een auto geparkeerd op vak 4B

daarna ga je extra informatie toevoegen:

persoon pietje heeft een voertuig auto geparkeert op vlak 4B

dan pak je een twede regel:

persoon sandra heeft een voertuig fiets geparkeert op vlak 6A

daar haal je de verschillen van weg

Persoon X heeft een voertuig V op vlak K

dit is dan je informatie model

Ut lijkt wel NIAM... Natuurlijke Informatie Analyse Methode.

[VyperX]

UML staat voor "Unified Modeling Language"...
Deze "standaard" is ontstaan uit overleg tussen verschillende groepen binnen de informatica. Al deze groepen hebben hun eigen manier toegevoegd aan de "standaard". Deze is dus erg uitgebreid, en de modellen kun je op verschillende manieren gebruiken/interpreteren.

Back on-topic:
Ik weet niet of je in Java hebt geprogrammeerd... Toen ik dat vak eenmal had gedad begreep ik waar zo'n klasse diagram op slaat..
Lees eerst nog eens goed de syntax door van zo'n "class-diagram"... Zoals jij die lijntjes + pijltjes nu gebruikt, slaat het nog nergens op... (no offense)

[reddog33hummer]

je moet open pijlen zien als:

Ik ben ikke maar ik eigenlijk ben ik hem

normale pijlen zijn:

das mijn vrientje

[The - DDD]

Op dinsdag 13 november 2001 00:02 schreef RaR het volgende:
Die open pijlen zijn generalisaties en die normale pijlen zijn associaties ..

dus de klasse bon erft de eigenschappen van de klassen verkoper en artikel want de gegevens daarvan moeten op de bon komen.
van alle bonnen moet dus de omzet worden berekend en een commissie voor de verkopers.

tara das mijn zienswijze

Euhm, ten eerste: Je leest die pijlen net de andere kant op.
En ten tweede: Lees even mijn eerste post in deze thread. Kijken of je dan je eigen denkfout ziet.

[reddog33hummer]

Op dinsdag 13 november 2001 00:03 schreef The - DDD het volgende:
Ut lijkt wel NIAM... Natuurlijke Informatie Analyse Methode.

das wat wij krijgen in enschede, het lijkt veel op niam wat ik hier neergezet heb maar het is even iets simpler

edit:

wat ik bedoelde te zeggen was dat wij niam in enschede kregen en dat ik hier ff een simpelere versie gebruikt heb

[McFreak]

Je moet een verkoper kunnen aanmaken en een artikel, de gegevens daarvan komen op een bon te staan.
Van die bonnen die ingevoerd zijn moet er dus een omzet worden berekend en van de verkopers een commissie.

[The - DDD]

Op dinsdag 13 november 2001 00:05 schreef reddog33hummer het volgende:
je moet open pijlen zien als:

Ik ben ikke maar ik eigenlijk ben ik hem

normale pijlen zijn:

das mijn vrientje

Je kan beter zeggen:
Bij een associatie: "Ik heb jou telefoon nummer dus ik kan jou opbellen om jou wat te laten doen."

Bij een overerving, die dus van kind naar ouder wijst: Ik ben hetzelfde als die ene daarboven, maar ik heb ook nog wat extra's te bieden.

[The - DDD]

Op dinsdag 13 november 2001 00:07 schreef RaR het volgende:
Je moet een verkoper kunnen aanmaken en een artikel, de gegevens daarvan komen op een bon te staan.
Van die bonnen die ingevoerd zijn moet er dus een omzet worden berekend en van de verkopers een commissie.

Ja ok, maar is een verkoper een bon? Wat jij zegt is dat een verkoper in weze een bon is met wat extra eigenschappen.

Net als een bon een speciefieke vorm van omzet is.

Jongens, wie heeft er toevallig nog een klasse diagrammetje liggen?

[reddog33hummer]

Op dinsdag 13 november 2001 00:07 schreef The - DDD het volgende:
Je kan beter zeggen:
Bij een associatie: "Ik heb jou telefoon nummer dus ik kan jou opbellen om jou wat te laten doen."

Bij een overerving, die dus van kind naar ouder wijst: Ik ben hetzelfde als die ene daarboven, maar ik heb ook nog wat extra's te bieden.

das een betere verwoording ja

[McFreak]

AAAAAAAAAAAAAAAAAAAAAARGH!!!!!!!!!!

[VyperX]

Ik denk dat ik me er maar eens even aan ga wagen... over 5 minuten een image van wat ik denk dat het moet zijn...

[reddog33hummer]

een lijn met een wiebertje (ruitje) betekend eigenaar van (moeilijke woorden onthoud ik nooit)

zoeits van een groep die in een cafe zit en 1 persoon weet de telefoonnummers van ieders GSM.
Zadra die persoon weg gaat, vertrekken alle personen die bij hem horen.

[The - DDD]

Dit is een duidelijk overerving...

Zie je dat letters, leestekens, speciale karakters en nummers allemaal karakters zijn?

[McFreak]

Ja net zoals een fiets heeft wielen, zodra de fiets geen wielen meer heeft is het geen fiets meer.. das een open ruitje.
Bij een wielrenner hebben diezelfde wielen ook hetzelfde doel maar zijn dan belangrijker.. nat weer banden, droogweer banden etc..

dat bedoel je toch ?

[reddog33hummer]

daar zet je dan nog ff bij of het
1 op 1
1 op meer
meer op 1
meer op meer
relaties zijn en de namen van de relaties dan is je UML
een heel stuk verder

[The - DDD]

Op dinsdag 13 november 2001 00:15 schreef RaR het volgende:
Ja net zoals een fiets heeft wielen, zodra de fiets geen wielen meer heeft is het geen fiets meer.. das een open ruitje.
Bij een wielrenner hebben diezelfde wielen ook hetzelfde doel maar zijn dan belangrijker.. nat weer banden, droogweer banden etc..

dat bedoel je toch ?

Een fiets is dus een combinatie van 2 wielen, een frame, een stuur, een voorvork, een zadel, etc....

Deze objecten zouden samen (geagregeerd in 1 object) een fiets voor kunnen stellen... MAAR wat betreft eigenschappen hebben ze niks met elkaar te maken. Een frame lijkt niet echt op een wiel of niet? Een wiel kan rollen, maar een frame lijkt me van niet. (bijvoorbeeld)

Wat je zou kunnen doen is natweer banden en droogweer banden beiden van een algemenere banden klasse overerven.

Want een natweer band en een droogweer band zijn allebij rond en hebben allebij een diameter. Die eigenschappen kun je in een gezamelijk ouder stoppen.

[McFreak]

maar die overervingen etc die dagen me wel.
Maar hoe moet je dan in godsnaam een systeem zoals dit inelkaar flansen?

Feitelijk heb je dan zoals jullie het zeggen helemaal geen streepies nodig en staat elke klasse op zichzelf ..

[The - DDD]

Op dinsdag 13 november 2001 00:18 schreef RaR het volgende:
maar die overervingen etc die dagen me wel.
Maar hoe moet je dan in godsnaam een systeem zoals dit inelkaar flansen?

Feitelijk heb je dan zoals jullie het zeggen helemaal geen streepies nodig en staat elke klasse op zichzelf ..

Ze hebben associaties naar elkaar(simpele pijl) en objecten hebben andere objecten als eigenschap (pijl met wiebertje).

Een klasse fiets heeft bijvooebeeld als eigenschap 2 wielen. Die twee wielen zijn een eigenschap van een fiets.

[Beurlap]

Idd een K*T school. Ik zit daar ook aan de coolhaven ook 2de jaar HIO en het zuigt nogal. Kmoet nog de helft van het 1ste jaar inhalen

Zo..dat most er ff uit

[reddog33hummer]

Wat er normaal gebeurt is dat je eerst een informatie analyse doet.

Hieruit volgt een datamodel.

Dan maak je een classe diagram om dit model op te slaan.
(gewoon de strucktuur van het model)

daarna maak je use cases:
wat wil je met het programma doen.

Daarna maak je sequences:
verwerk wat je wil doen tot acties.

[McFreak]

hohoho mensen.. Ik heb het hier specifiek over de klassendiagrammen, niet sequence etc..

He Beurlap.. ik leef met je mee.
Ik zou wel wat beter gaan doe als ik jou was, want het 2e jaar zuigt nog veel meer !!

[McFreak]

maar ik heb inmiddels nog ff meer geflanst :

[VyperX]

Dingen die je af kan leiden (zoals het totaal aan verdiende commissies) die hoef je niet als klasse op te nemen.

Eigenlijk zou ik de relaties nog moeten benoemen, maar het is al laat enzo...

hint: prijzen zijn floats, niet doubles... (float is met komma erin, "double" is een korte benaming voor "double int" (dus een int met twee keer zoveel bits beschikbaar))

[reddog33hummer]

gewoon ff aangeve hoe het proccess verloopt

maargoed

associaties (normale pijl)

het ene heeft een relatie met een ander
maar het kan zonder de andere bestaan.
bv een loss stuur of wiel kan er zijn zelf als er geen fiets is.

andere ding (wiebertje)

ene heeft een relatie met de ander
maar kan niet zonder de andere bestaan.
een stuur en een wiel bestaan alleen als er een fiets aan vast zit

[McFreak]

ok.. Ik bedank jullie gasten allemaal heel erg voor dit stukkie.. het heeft mij nieuwe gedachten opgeleverd

Vooral VyperX met zijn use-case, bedankt.. waarschijnlijk wordt dit een soort tutorial voor heel veel gasten die ik ken die het net zo als mij ook niet snappen

[reddog33hummer]

viper, ik zou nog niet met bidirectionele assosiaties werken. Daarmee maak je het in de implementatie jezelf moeilijk.

maargoed ik denk dat je pijlen of wiebertjes bedoelt .

het is inderdaad beter om die classes tot functies terug te brengen. Maar normaal met een goede informatieanalyse hoeft dat meestal niet meer zoveel.

[The - DDD]

Op dinsdag 13 november 2001 00:29 schreef reddog33hummer het volgende:
gewoon ff aangeve hoe het proccess verloopt
[...]

andere ding (wiebertje)

ene heeft een relatie met de ander
maar kan niet zonder de andere bestaan.
een stuur en een wiel bestaan alleen als er een fiets aan vast zit

Dit is dus bullshit.

Een klas kan prima bestaan zonder de klasse die achter het wiebertje hoort. De pointer, reference, etc... heeft dan gewoon een null waarde. En indien je daar niet op test en zodoende aanroepen naar de null-pointer voorkomt, krijg je nullpointer exceptions (in java dan). (in C++ kun je nog lijpere dingen doen, dangling pointers enzo... brrrr...) En je kan prima een los stuur of wiel hebben.

[reddog33hummer]

Op dinsdag 13 november 2001 00:25 schreef RaR het volgende:
He Beurlap.. ik leef met je mee.
Ik zou wel wat beter gaan doe als ik jou was, want het 2e jaar zuigt nog veel meer !!

het tweede jaar bij ons was ook vreselijk. Ze hadden op dat moment probleem gestuurt onderwijs ingevoerd als "test"

dat zu!@d ontzettend

[reddog33hummer]

Op dinsdag 13 november 2001 00:35 schreef The - DDD het volgende:
Dit is dus bullshit.

Een klas kan prima bestaan zonder de klasse die achter het wiebertje hoort. De pointer, reference, etc... heeft dan gewoon een null waarde. En indien je daar niet op test en zodoende aanroepen naar de null-pointer voorkomt, krijg je nullpointer exceptions (in java dan). (in C++ kun je nog lijpere dingen doen, dangling pointers enzo... brrrr...) En je kan prima een los stuur of wiel hebben.

de Classe (eigenlijk object) kan dan wel bestaan maar volgens het model zou hij er niet moeten zijn.

Bijvoorbeeld in een 3D Programma heb je wel een bak met punten, lijnen, vlakken, etc. die. Andere objecten kunnen dan referenties naar die figuren hebben (referenties) en wiebertje tussen de bak en de figuren. volgens het datamodel moet zodra de bak weggaat alle figuren weg zijn.
of dit in de implementatie ook echt gebeurt is een twede maar volgens het model zou het zo geimplementeerd moeten zijn.

[The - DDD]

Daar heb je weer wel gelijk in.

[reddog33hummer]

UML is een mooi systeem, jammer dat sommige mensen varianten gebruiken

[McFreak]

en jammer dat het zo vaag is voor n00bz, het scheelt zo veel onnuttigheid bij de implementatie wat ook weer een vak apart is

[VyperX]

Vooral VyperX met zijn use-case, bedankt.. waarschijnlijk wordt dit een soort tutorial voor heel veel gasten die ik ken die het net zo als mij ook niet snappen

Heb ik een use-case gemaakt dan?

Over die bidirectionele relaties: Dat is inderdaad een beetje overkill.. (ben het alleen tegenwoordig gewend met alle opdrachten die ik moet maken). Soms kan het wel handig zijn. Als je bijvoorbeeld van een bon wil weten wie hem uitgeschreven heeft... (heeft in dit geval niet veel nut, maar ja)
Ook ben ik het niet helemaal eens met die "administratie" klasse, maar dat was zo ff snel de enige manier waarop ik alle bonnen samen kon voegen (om ze te sommeren).

Zo zie je maar weer... hele hoop van de dingen die je maakt zijn afhankelijk van keuzes...

Anyway, veel geluk met UML.. en ik hoop dat je er wat aan hebt

[reddog33hummer]

het grote probleem met die bidirectionele is als je er niet vertrouwd mee bent dat je "wezen" maakt (objecten die er wel zijn maar niet goed verbonden zijn).

[Crysania]

dat plaatje wat ViperX net gepost had zag er toch echt uit als de uml die ik geleerd heb.

en dat met die zinnetjes is NIAM

ik zit trouwens in Eindhoven waar ik het leren van UML erg makkelijk vond. het is gewoon logisch volgens mij.