[UML] Specialization?

[D4Skunk]

Aangezien ik voor 1 van mijn klanten een analyse aan het maken ben, en ik mij eens op UML wou toeleggen ipv ERD, ben ik begonnen met het ontwerpen van een model in UML.
De use case was (vanzelfsprekend) a piece of cake, maar nu zit ik met een probleempje in mijn class diagram, dus bij deze een vraagje voor de UML experts op dit forum :

Dit is het class diagram :


Ik veronderstel dat dit voor de uml-mensen redelijk vanzelfsprekend is, en hopelijk zitten er geen fouten in.

Wat is nu mijn probleem : het specializeren van de "taak".
Wanneer ik deze ga specializeren, dan heb ik bv Bezoek,Verhandelen assets,Meeting, ...
Mijn taakverslagen moeten echter ook 'gespecialized' worden, dus zou ik hebben : Verslag bezoek, verhandelde assets,...

Hoe integreer je dit nu in dit diagram zonder er een soep van te maken ?
Of moet ik gewoon een nieuw diagram maken, specifiek voor taak en taakverslag, en dan per taakverslagtype een apart diagram ?

Moet ik dan voor deze subtaken, bv het verhandelen van assets, ook een link leggen van de subtaak naar het product bv ? Ik zou veronderstellen van niet, gezien men rechtsreeks via het dossier aan deze gegevens kan geraken.

Maar : sommige taken kunnen enkel en alleen voor een bepaald type van product uitgevoerd worden, dus denk ik dan weer van wel

Of benader ik alles teveel vanuit het ERD-standpunt ?

Kortom : HELP

[ Voor 2% gewijzigd door D4Skunk op 11-10-2005 17:50 . Reden: layout grmmbl.... ]

[NMe]

D4Skunk schreef op dinsdag 11 oktober 2005 @ 17:48:
Of benader ik alles teveel vanuit het ERD-standpunt ?

Ehm...ja.

Een ERD is niet zomaar inwisselbaar voor een klassendiagram. Voor een groot deel zal het overeen komen, maar voor een groot deel ook niet. De specialisaties van een taak kun je er toch gewoon onder tekenen, net zoals je bij Contact en Persoon hebt gedaan?

Trouwens, de manier van linken tussen Contact en Organisatie vind ik ietwat raar. Je geeft namelijk aan dat Organisatie een specialisatie is van Contact, maar intussen bevat een Contact wel een Organisatie. Dit vind ik ietwat vaag overkomen. Als je inheritance goed implementeert, dan heeft een Organisatie toch al alle mogelijkheden van een Contact? Waarom zou je dan nog zo'n rare manier van verbinden gebruiken?

Verder vind ik die ContactDossierRol class nogal vaag overkomen, ook dat komt op me over alsof je teveel vanuit de database denkt. Misschien moet je je eens verdiepen in de Model-View-Controller architectuur, die is eigenlijk bijna overal wel toepasbaar, en het zou je ook hier een hoop schelen.

[.oisyn]

-NMe- schreef op dinsdag 11 oktober 2005 @ 18:15:
Trouwens, de manier van linken tussen Contact en Organisatie vind ik ietwat raar. Je geeft namelijk aan dat Organisatie een specialisatie is van Contact, maar intussen bevat een Contact wel een Organisatie.

Zoals ik het lees heeft een organisatie meerdere contacten, dat is toch niet zo vreemd?

[NMe]

Ow wacht, inderdaad, het ruitje zit aan de andere kant. My mistake.

Heeft een organisatie trouwens mogelijk andere organisaties als contact? Of kunnen dat alleen personen zijn? Dan zou het misschien logischer zijn om te verwijzen naar Persoon in plaats van naar Contact.

[D4Skunk]

-NMe- schreef op dinsdag 11 oktober 2005 @ 18:15:
[...]

Ehm...ja.

Een ERD is niet zomaar inwisselbaar voor een klassendiagram. Voor een groot deel zal het overeen komen, maar voor een groot deel ook niet. De specialisaties van een taak kun je er toch gewoon onder tekenen, net zoals je bij Contact en Persoon hebt gedaan?

Ja, maar het is wel zo dat de afgeleide klasse van taakverslag enkel en alleen van toepassing op 1 enkel type taak, vandaar dat ik me afvroeg of er hiervoor geen speciale representatie bestond...

...
Verder vind ik die ContactDossierRol class nogal vaag overkomen, ook dat komt op me over alsof je teveel vanuit de database denkt. Misschien moet je je eens verdiepen in de Model-View-Controller architectuur, die is eigenlijk bijna overal wel toepasbaar, en het zou je ook hier een hoop schelen.

ContactDossierRol is een ??composite aggregation ?? , en wordt meestal omgezet in een class volgens UML-docs
Wat MVC betreft : ik ben er mee vertrouwd, maar MVC is NVT (no pun intended ) voor zover ik zie...
Waar ik wel aan gedacht had was om een command factory op te zetten om de taken te implementeren...

-NMe- schreef op dinsdag 11 oktober 2005 @ 18:30:
Ow wacht, inderdaad, het ruitje zit aan de andere kant. My mistake.

Heeft een organisatie trouwens mogelijk andere organisaties als contact? Of kunnen dat alleen personen zijn? Dan zou het misschien logischer zijn om te verwijzen naar Persoon in plaats van naar Contact.

Ik gebruik organisatie in de meest brede zin van het woord, dus een organisatie kan idd een andere bevatten, denk bv aan een holding..

Ik heb trouwens een interessante link gevonden : INHERITANCE OF COMPOSITE STRUCTURE (einde v/d pagina)

[ Voor 6% gewijzigd door D4Skunk op 12-10-2005 10:11 . Reden: toevoegen link ]

[D4Skunk]

Schopje, iemand ???
Ik heb trouwens zelf al een foutje uit mijn uml gehaald : het taakverslag moest verwijzen naar contactdossierrol ipv dossier.
Nieuwe UML :

[ Voor 85% gewijzigd door D4Skunk op 13-10-2005 19:30 . Reden: toevoegen UML ]

[Aetje]

Een taak heeft geen of meerdere taakverslagen. Is dat wel correct? Moet een taak niet een enkel verslag hebben?

Zelf zou ik taak en taakverslag niet uitgesplitst hebben.

[D4Skunk]

Aetje schreef op donderdag 13 oktober 2005 @ 19:25:
Een taak heeft geen of meerdere taakverslagen. Is dat wel correct? Moet een taak niet een enkel verslag hebben?

Zelf zou ik taak en taakverslag niet uitgesplitst hebben.

Een rol is een standaardmodel voor een bepaald contact.
Wanneer een contactpersoon de rol Relatiebeheerder heeft, is 1 van zijn taken het trimesterieel bezoek.
Dit is dus 1 specifieke taak die 3maandelijks moet gebeuren, en waar elke keer een verslag van moet opgeleverd worden.
Een andere taak kunnen zijn : het verkopen van nieuwe producten. Wanneer dit (nog) niet aan bod gekomen is, is dit dus een 0..n relatie

Ok, versie 3 alweer, ik denk dat ik nu echt wel in de buurt begin te komen

[ Voor 21% gewijzigd door D4Skunk op 13-10-2005 20:24 . Reden: nieuwe UML toegevoegd ]