Ahoj René, takhle na první pohled, pozdě v noci (poté co jsem dořešil komentáře), bych přidal atribut spojení mezi projektem a členem projektu. Nad zbytkem se zkusím zamyslet zítra.

Jeden pokus jako ranni rozcvicka - role jednotlivych clenu projektoveho tymu by bylo asi lepsi nedelat pomoci dedicnosti. Pri vyhazovu neschopneho project managera a jeho nahrazeni stavajicim senior programatorem by byl trochu problem s identitou instanci.

Na môj vkus sa tam nejako moc ticho predpokladá, že v jednom projekte bude jeden ProjectManager. Ale to je asi normálne. Môže existovať Project bez ProjectManagera?

Nemala by byť kardinalita TeamMember <-> Project M:N?

Čiže skôr to vidím na niečo ako:
Project <-1-N-> Role <-N-1-> Member

A co kdyz si takovy manager bude chtit sednout za klavesnici a trochu si zaprogramovat? Teoreticky se to prece muze stat ;-)

Navrhoval bych udelat tridu TeamRole a z ni by dedily tridy Manager a Programmer. Tridu TeamMember mit zvlast a asociovat ji s tridou TeamRole.

Souhlasím s tím, že by bylo lepší neodvozovat programátory a managery, ale zavést roli. Tu bych ale také nedědil (jako navrhuje johno), spíš bych to viděl na asociaci ke členu týmu.

Jinak jsou tam detaily k diskusi (může být OK - podle toho, co vlastně chceme):
1. možná, že agregace členů týmu do projektu je moc silná vazba (já osobně bych volil spíše běžnou asociaci)
2. podmínka, že k projektu je přiřazen alespoň jeden člen týmu (neumožní mi vytvořit projekt, který bude nějakou dobu čekat na svou realizaci)
3. určitě člen týmu může pracovat jen na jednom projektu? Co až ten projekt bude hotov? Člen týmu se destruuje a pro nový projekt se vytvoří nový člen?

Ještě úvaha k těm rolím: To, že se role "nedědí" je známá finta, ale není to vlastně ústupek "bežným" jazykům se statickými typy? Myslím, že v dynamických jazycích (nebo ještě lépe v OO jazycích, které nemají třídy) by se ten diagram vlastně klidně dal použít tak, jak je.

OOPS: omlouvám se johnoovi, to dědění role navrhoval Petr Felzman. Já ty příspěvky ve Firefoxu vidím dost nepřehledně - graficky to vypadá, že příspěvek patří k autorovi předchozího příspěvku.

Klidne jeste diskutujte panove, reseni a muj nazor napisu az za tyden. :)
a pak se tady objevi nova hadanka - a ta uz bude za sampaske (aby me nekdo netahal za slovo - presneji za Bohemia sekt). :)

tak já bych to taky zkusila, přestože nejsem pán:) ale buďte René, prosím, shovívavý:)
TeamMember ve mě vyvolává pocit, že by tam měl někde být nějaký tým (ale možná jsem jen poblouzněná tou metodou "najděte podstatná jména a nasekejte z nich třídy;)) - takže bych vytvořila třídu Team s asociací na Project a TeamMember (tady bych možná dala i agregaci) a agregaci mezi Projectem a TeamMemberem bych zrušila. potom bych vytvořila power type Typy rolí s asociací na TeamMember. z potomků třídy TeamMember bych vytvořila generalization set {incomplete, overlapping}

Terezko, dámy a jejich názory jsou zde jen vítány, za ten podvědomý a latentní mužský šovinismus v předchozím příspěvku se omlouvám. :)
Aniž bych prozrazoval víc - máte dobré nápady :)

Tak jsem cestou do práce měl chvilku a zkusil se zamyslet (poměrně odvážné tvrzení). Členové týmu, který byl již zmíněn, by měli být v nějaké hierarchii (odpovědnosti). S tím, že člen týmu může patřit zároveň do několika týmů. Jeden tým pak řeší jeden projekt v daný časový úsek. Pokud to vezmu trošku detailněji, dojdu k tomu, že projekt je poměrně velká množina úkonů a nejspíše by bylo vhodnější rozdělit projekt na jednotlivé moduly (subprojekty), které jsou řešeny jednotlivými týmy. Přeci jen by zde mohla být jistá specializace členů týmu - nikoli ta návrhová. Vztah mezi subprojektem a týmem pak ovlivňuje několik faktorů (atributů). Když se ještě více ponořím, tak mezi ty hlavní by patřil datum dokončení a v první řadě odměna :-) Ale že mi ta cesta do práce nějak rychle utekla.
PS: není ten obrázek popisem stavu as-is u některých (spíše většině) českých softwarových firem, kdy každý si dělá na projektu "co chce"?

Takze k blogu a presnemu popsani problemu a k zadani dalsi hadanky se dostanu kolem 20.11. - opravdu ted nestiham :(
Ale zaznela tu spousta zajimavych veci - presto minimalne jednu klicovou informaci bych chtel jeste slyset :)
Kdo ji napise spravne, dostane sampanske i po teto hadance :)

Chybí mně tam entita, která označuje osobu (např. Person). Jméno (a další údaje) ve skutečnosti nese osoba, entita TeamMember pouze informuje o zařazení osoby do projektu (resp. do týmu). Jinak postrádám informace o tom, co má vlastně daná úloha řešit, bez toho se těžko posuzuje jestli je řešení dobré nebo ne...

ANo - je to zatim jen hricka bez zadani, protoze testuje i jak se dovedete postavit k modelu bez semantickeho zakladu. A jde mi ciste jen o Vase predpklady nad syntaxi ... pro me to bude odrazovy mustek k dalsim hadankam

Pokud vyjdu z myšlenky slečny Terezy o existenci třídy Team a její asociaci na Project, tak...
...co takhle zavést TeamMember jako asociativní třídu mezi třídami Team a Person, přičemž TeamMember bude obsahovat asociaci na číselník TeamRole? Rozšíření by pak mohlo přijít v podobě změny třídy TeamRole z pouhého číselníku na kořen GenSpecu, to pokud bych očekával od každé role jinou funkcionalitu.

Takze pokud mam vychazet pouze z toho, co je na obrazku: aby mely odvozene tridy ProjectManager, SeniorProgrammer, JuniorProgrammer "pravo na existenci", tak musi pridavat neco navic oproti bazove tride nebo prepisovat jeji funkcnost, coz na obrazku neni. Takze by se mely bud tyto tridy doplnit, nebo to neresit dedenim, ale vlastnosti tridy TeamMember (napr. Role), coz muze byt bud enumerator, nebo odkaz na prislusnou tridu - ciselnik (napr. TeamMemberRole).

C-Press "UML a unifikovany proces vyvoje aplikaci"

15.5.1. Agregace nebo dedeni (str 258)

Zakladni semanticka chyba... TeamMember nebo TeamRole? = Mam roli nebo je Member? => ma roli...

Pokud bych mel vychazet jenom z toho nakresleneho kousku (tzn. neresit to, co tohle "neumi" ale jenom to opravit):
Rozhodne musi existovat samostatna trida pro osobu (aby se mi nestalo, ze az budu vytvaret evidenci stravniku v podnikove jidelne (nebo neco takoveho) budu muset mit tytez udaje na mnoha mistech). TeamMember tuhle osobu muze agregovat v 1(osoba):n(teammember). Jak resit ruzne role clena tymu je otazka.
reseni:
a)Pokud nejsou s ruznymi rolemi asociovane ruzne informace a clovek aa)nemuze mit vic roli -> odliseni pomoci jednoducheho enumeratoru.
ab) muze mit vic roli -> enumerator s Flags.

b)S ruznymi rolemi ruzne doplnujici informace. ba) dedeni od abstraktniho teammembera.
bb) agregace ruznych roli.

1. projekt může (dle diagramu) mít více project managerů .... což asi neodpovídá realitě;
2. člen týmu "neví" (tedy neví to přímo a jednoduše) do jakého projektu patří

pojďmě dál :
3. členové jednoho týmu "nevidí" přímo a jendoduše na svého project managera (vyřešila by asociace mezi TeamMember a ProjectManager)
4. každý team member je členem právě jednoho týmu (problém při potřebě být členem více týmů v jednom okamžiku, problém změny týmu v čase)
5. může existovat jednočlenný tým, kde jediným členem týmu je třeba JuniorProgrammer
6. členové jednoho týmu "nevidí" přímo a jendoduše na ostatní členy týmu
7. už tu zaznělo : může člen týmu zastávat více rolí ?
8. souvisí s více předchozími body: zajímá mě jen aktuální stav, nebo chci mít i informace o historii ?

Ahoj, teda, ty nás napínáš s řešením té žhnoucí hádanky. ;-)
Nepřemýšlel jsi, jen tak čirou náhodou, že by jsi uveřejnil finální rozřešení(?), třeba jako malý dáreček. Pravda, ten bys měl vlastně dneska dostat spíše ty.
Všechno nejlepší a ať se ti daří a vychází vše co si přeješ.
J.

Diky moc za peani Jardo,
ani bych Vas tolik nenapinal, kdybych nasel nekde nebo dostal alespon trochu volneho casu ;(

Proč mít pro každou roli samostatnou třídu? Co když vznikne role nová, nebo se změní její název? Role je číselník v systému a měla by být IMHO chápána jako atribut Team Member. Takže udělat třídu Role (id, name) a Team Member bude mít jednu nebo více rolí (záleží, zda může být ve více rolích najednou).

Tak vse nej do noveho roku a at zbude i neco casu na blog.