Návrh - Statická struktura

[FilipMatys]

Poprosím Tě o vypracování části návrhu, a to Statická struktura. Zejména se zaměř na diagram tříd. Pokud budeš potřebovat, tak Ti budu k dispozici. Můžeme se domluvit i na společné schůzi.

Na schůzi bychom měli probrat alespoň beta verzi návrhu, tudíž poprosím o prvotní vypracování do čtvrteční schůze 9.4.2015.

[FilipMatys]

Vycházej jak ze specifikace, tak z návrhu GUI, který je v datovém skladu. Jeho bližší popis vypracuji taktéž do 9.4.2015, takže dotazy směřuj na mě.

[FilipMatys]

Výsledek by mohl vypadat nějak takto: http://people.cis.ksu.edu/~reshma/classdiagram1.JPG

Ignoruj metody. Důležité jsou kardinality, primární klíč uvažuj vždy jako Id (vše dědí z "Indexed entity", tedy IndexedEntity: { Id:double }).

Vyplněná šipka znamená pevná vazba, tedy že entita nemůže bez té druhé existovat (jestli si to správně pamatuji ^^), trojúhelníková šipka pak značí dědičnost.

[FilipMatys]

Čau Tome, Jak jsi na tom? Podařilo se ti něco vymyslet?

[xlenga01]

V datovem skladu je prvni nastrel - par veci mi nebylo jasnych, takze se to bude muset dodelat.

[FilipMatys]

Vyborne, diky. Zitra na to mrknem

[xlenga01]

Ok, nahodil jsem do datoveho skladu verzi, ktera by mela byt uz pouzitelna.

[FilipMatys]

Super, diky. Poprosim i ostatni cleny tymu, aby na to mrkli a eventuelne pronesli kritiku, diky

[andreamarcelyova]

Ja teda nie som programator, ale myslim, ze pre deadliny a podobne by bol vhodnejsi typ pre datum a nie string. Potom sa mi nezda kardinalita napr. medzi Admin a User - nie kazdy user je zaroven admin, to iste s Company a ContactPerson. Co su tie Note? Asi sa o tom hovorilo na stretnutiach, ale som z toho trosku zmatena. :)

Este otazka na Filipa, cisto zo zvedavosti, preco id: double? :)

[FilipMatys]

Ahoj, Díky za reakce.

1) Datum

• Co mám informace, tak dostupný nástroj, který Tomáš použil, tak typ Datum neumožňuje, takže jej budeme muset dodatečně upravit, o tomto vím.

2) Máš pravdu. Tímto poprosím, aby Tomáš provedl úpravu

3) Notes

• Jsou to poznámky, které přidávají kontaktní osoby k firemním účastem a pomáhají tím ostatním kontaktním osobám orientovat se v aktuálním stavu jednání s danou firmou.

4) Id jako double

• Zvyk z práce :) Ale pokud nekecám, tak Entity Framework vytváří pro každou entitu primární klíč jako Id:double sám o sobě a je součástí LightSwitch

Pro Tomáše:

• Poprosím upravit kardinality uživatelských rolí
• Přidat do Participation atribut specialRequests:String

Děkuji

[andreamarcelyova]

Myslela som si, len ma trochu v tom Notes zmiatlo spojenie s User.

[FilipMatys]

Nad tím jsem taky přemýšlel. Otázkou pro mě však bylo, jestli bude moci přidávat poznámky pouze přiřazená kontaktní osoba, nebo třeba i admin.

Za mě by více dávalo smysl přiřazená kontaktní osoba. Souhlasíš?

Ve specifikaci může přidávat "Zaměstnanec FIT"

[andreamarcelyova]

Ja si tiez myslim, ze to viac dava zmysel aby poznamky pridavala kontaktna osoba, ten admin mi tam pripada trochu zbytocny. Ale neviem, mozno niekomu napadne kedy by sa to hodilo..

[KratochvilJiri]

Z mého pohledu bych nechal klidně přidávat poznámky jakoukoliv kontaktní osobou. Protože pokud má někdo nějaké zkušenosti/na něco si vzpomněl z dřívější spolupráce/jednal s firmou a není v tomto roce přiřazen pro firmu jako kontaktní osoba, ale chce pouze přidat poznámku, aby pomohl kolegovi, který ji má letos, tak přoč by tam tu poznámku nemohl napsat? Není to žádné zasahování někam, navíc tam bude jeho podpis (autor poznámky), takže bych to nechal pro všechny.

Co se admina týka, pokud má takové právo kontaktní osoba, měl by mít pravděpodobně toto právo i admin. Vždyť admin "řídí/spravuje" celý systém, takže by neměl mít menší možnosti než jeho "podřízení". Ačkoliv se to asi moc nevyužije zase nevidím důvod, proč by k tomu nemohl mít přístup.

Ještě mě teď napadlo, řešili jsme mazání poznámek? Asi to není nutné, ale ta možnost by tam měla být např. když někdo odešle omylem nějaký nesmysl, tak by to tam nemělo vyset x let...

Co se class diagramu týká, tak už to vypadá dobře. Dobrá práce Tomáši!

[FilipMatys]

Ad Poznámky) Ok, takže pro poznámky spojení s user zůstává

Ad Mazání) Bude doplněno do návrhu během zítřejšího dne. Ostatní poprosím, aby s tím počítali. Tlačítko pro smazání bude u každé poznámky viditelné pro admina a pro autora poznámky

[xlenga01]

Ok, nahrana nova verze: kardinality opraveny pridan atribut specialRequests

vztahy k poznamkam jsem zatim nemenil a osobne nevidim duvod, proc by admin nemohl pridavat poznamky

[azuritus]

Ahoj, taky bych mel par poznamek, krome toho co tady uz zaznelo bych jeste mel:

1. Admin a ContactPerson, nevidim duvod proc by mely tyhle tridy vubec existovat.
2. To ze je uzivatel admin je dano jeho roli a zadnou dalsi informaci tahle trida nenese, takze bych ji navrhoval bez nahrady zrusit.
3. Kontaktni osoba, tam je to podobne - zrusit a vazbu na Participation udelat na primo. Zaroven bych navrhoval do tridy User property name a phone (ktery je navic duplicitne ve dvou tridach).
4. Nevim jestli uplne presne chapu vyznam vazby mezi Note a User, pokud to ma byt ve vyznamu "autor", potom mi to dava smysl, ale neni zvlastni resit autora jen u jedne tridy? Pokud to tam ma mit nejaky jiny vyznam, tak me aktualne nenapada jaky a byl bych rad, kdyby mi to nekdo priblizil. Jak tu zaznelo o omezeni toho, kdo muze pridavat komentare, je podle meho nazoru aplikacni logika, kterou neni potreba reprezentovat v diagramu trid a v takovem pripade bych navrhoval vazbu odstranit.
5. Attendee nese podobnou informaci jako User, takze by mozna stalo za zvazeni, jestli nevytahnout duplicitni informace do nove tridy Person. Sem by patrilo vsechno, co se tyka osoby, tj. jmeno a kontakty (telefon, email). Z Attendee by tak zustal jen rozklad M:N vazby Participation - User, ktere nenese zadnou informaci a neni jej tedy treba drzet jako tridu. Proto navrhuji Attendee zrusit.
6. Company, atributy contact* - opet mame jednu informaci (jmeno a telefon) na vice mistech, takze navrhuji zrusit a informaci uchovavat v navazanem objektu User popr. v nove vazbe na Person.
7. Conference - atributy Deadline a DeadlineDesc castecne nesou stejnou informaci, takze navrhuji vytahnout je do nove tridy Deadline s atributy type (DeadlineType), date (datum), description (string) a vazbou na Conference. Kde DeadlineType by vzniklo prejmenovanim ExceptionType a pridanim chybejicich polozek.

A nakonec par drobku:

• datum by melo byt skutecne datum, protoze takto neni poznat jestli je to myslene jako date, datetime nebo nejaky timestamp a model ponekud ztraci na informacni hodnote
• ICO/DIC - je to normalni string, jehoz strukturu omezuje aplikacni logika, DIC se navic ani neda reprezentovat celym cislem
• Participation.funds - double neni vhodny typ na reprezentaci financnich castek (kvuli zaokrouhlovani), vhodnejsi by bylo pouzit decimal
• ExceptionType a AttachementType nesou podobnou informaci, stalo by za zvazeni jestli by je nebylo mozne sloucit.
• StateOfParticipation - schazi mi tu neco jako aborted, cancelled pro reprezentaci situace, kdy uz se s ucasti firmy na konferenci zacalo, ale nepodario se ji dotahnout do konce.
• id double? to je nejaka haluz, ne? Mohl bys mi prosim, Filipe vysvetlit dusevni pochody, ktere k teto ezotericke konstrukci vedly? Osobne bych to videl na neco normalniho, tj. int/bigint.

Jinak to vypada dobre, dobra prace, diky.

[xlenga01]

Mrknul jsem se na to a vzhledem k tomu, ze nemam zitra cas a s vetsinou pripominek osobne souhlasim jsem nahodil do skladu verzi 2 v upravovatelnem formatu:

1-3 : souhlas(ted je tam jen trida user, ktera ma atribut role) 4 : ano ta vazba je autor(jestli je to zvlastni osobne netusim) 5 : attendee ma jen jeden atribut a to je jmeno(vytiskne se na jmenovce), zatim jsem tam tu tridu nechal (mam dojem, ze ve specifikaci jsou nektere ty atributy u osob uvedene jako povinne, coz je u attendee zbytecne) 6 : nektere z tech atributu by se asi na strane company daly zrusit, ale nejsem si ted jisty jak to tam presne funguje (pac je rozdil mezi uctem firmy a kontaktni osobou firmy) 7 : OK, vytvorena nova trida(osobne porad nechapu co tam delaj ty descriptiony, ale tak co...)

zbytek: datove typy predelany, zadne enumarationy jsem neslucoval, pridan stav cancelled

Uz je dost pozde a v hlave mi prave dupe stado nosorozcu, takze si nejsem jisty, jestli jsem vse pochopil spravne a jestli jsem tam nahodou nekde neudelal nakou chybu, kazdpadne ve skladu jsou ted obe verze(muze te se zitra o to porvat a pak mi dejte vedet, kdo vyhral, at to upravim do konecne faze)

[FilipMatys]

Díky @azuritus za připomínky. Jelikož Tomáš v sobotu nemůže pokračovat, tak poprosím Vojtu o dokončení a zapracování připomínek.

Dál k poslední poznámce, ke které bych se rád vyjádřil: Ano, přiznávám chybu na své straně. Měl jsem v hlavě informaci, která nebyla pravdivá, což přiznávám. Dále však nepovažuji způsob, jakým si zvolil prezentovat svůj názor, za zcela vhodný.

Věřím, že mě můžeš považovat za osobu nedosahující Tvých kvalit ani po kotníky, nebo že si měl špatný den. Nebo oboje. Ale zkus se krotit ve svých obratech. "Kamarádi" být nemusíme, ale respektujme se jako lidé a členové týmu.

Děkuji

[FilipMatys]

@Malajda

[KratochvilJiri]

Trošku bych zklidnil emoce z obou stran a soustředil se hlavně na řešení. Díky Pavlovi za reakci na diagram, jeho poznámky jsou k věci a má v nich pravdu, ale tu poslední si mohl zcela jistě odpustit. Ačkoliv věřím, že to měl být spíše vtíp, ocenil bych trošku profesionálnější přístup.

Tenhle projekt je hlavně o řízení, komunikaci a vzájemné spolupráci v týmu. Máme nastaveny nějaké role a zrovna mezi Vámi je vztah šéf(Filip)-podřízený(Pavel) a proto by měl Pavel respektovat názory svého šefa (samozřejmě respektovat bychom se měli všichni navzájem i na stejné úrovni nejen ve vztahu šef-podřízený) a trošku si předem rozmyslet co napíše. Já se o to taky snažím a určitě tu nejsme proto, abychom čekali až jeden z nás udělá chybu a mohli ho nějakým způsovem shodit nebo zesměšnit. Kdyby jsi tohle řekl šefovi v práci a ještě před ostatními členy týmu asi by to taky nevzal uplně ok.

Dál bych to asi nerozebíral a soustředil se na řešení, jsme přece všichni dospělí a inteligentní lidé, tak bych poprosil i o přístup, který tomu alespoň trošku odpovidá.

[FilipMatys]

Poprosím Vojtu, aby mi potvrdil převzetí úkolu, děkuji.

[FilipMatys]

Ještě podle připomínek Pavla bych poprosil sjednocení výčtových typů. Dnes prezentujeme, ale ve finální verzi by bylo dobré to mít.

Dejte mi, prosím, vědět, že berete na vědomí. Rozdělte si práci podle časových možností: @xlenga01 @Malajda

[xlenga01]

Nahodil jsem do skladu excellClassv3.pdf - dva datove typy jsem sjednotil, ale attachement a deadline jsem nechal zvlast, pac v deadlinu jsou dve hodnoty navic, takze mi to prijde cistci nechat to oddelene...

[FilipMatys]

Poprosím o následující změny:

• Participation:Funds nahradit Participation:ExpectedPayment
• Conference:Date nahradit Conference:DateFrom a Conference:DateTo

Děkuji a výsledek poprosím ve formátu PNG. Děkuji @xlenga01

[FilipMatys]

Muzu dnes ocekavat zmeny? Dekuji

[xlenga01]

Ok, je to ve skladu v png i pdf.

[FilipMatys]

Ještě se omlouvám, ale všiml jsem si, že ve výčtových typech DeadlineType chybí:

• contract Poté zaměnit:
• propagVideo za propagPaper
• videoconferention za videoPresentation (v podstate tak, jak je to v AttachmentType), v tomto případě nevím, jestli by nebylo lepší to sloučit, podobně jako předtím ExceptionType, jelikož AttachmentType je podmnožina DeadlineType

[xlenga01]

chyby opraveny, nahrano, ja bych to teda neslucoval, ale muzem se o tom pobavit zitra

[FilipMatys]

Poprosim o zapracovani: User(M) to Participation(N) - přidána tabulka UserParticipation pro rozdělení M:N

Více v issue #38

[FilipMatys]

Budeš mít dnes čas na provedení změn? Děkuji

[jlorenc01]

Ve třídě Participation chybí sponsorshipLevel a příznak isPaid.

[FilipMatys]

Tady poprosím o vyjádření ostatních členů týmu. Momentálně je myšleno následovně:

• úroveň sponzorství je odvozována, neukládá se
• příznak isPaid je dán stavem Paid pro workflow účasti

[KratochvilJiri]

Podle mě to takhle stačí.

[FilipMatys]

Mimo jiné chybí specializace pro kontaktní osobu. Poprosím taktéž o doplnění

[jlorenc01]

Ve své poznámce jsem asi trochu promíchal návrh tříd s tím, jak se to dělá v LS (jak jsem to pochopil):

V LS je třeba přidat do entity (Participation) nový atribut pro vypočítanou hodnotu (sponsorshipLevel), zatrhnout checkbox isComputed a napsat metodu pro vypočtení toho atributu. Potom je možné tento atribut zobrazit na obrazovce a pokud jsem to správně pochopil, do databáze se tento atribut neuloží.

[FilipMatys]

Dobra poznamka. Poprosim tedy uroven sponzorstvi taktez pridat do diagramu trid.

[KratochvilJiri]

Poprosim přidat textový popisek, že se jedná o odvozený atribut.

[jlorenc01]

V tom případě tedy i isPaid. Ten bude taky computed (state == paid or complete => ispaid = Yes, other => isPaid = No).

[FilipMatys]

To uz mi zacina smrdet, ale pokud nema nekdo dalsi namitky, tak ok.

[KratochvilJiri]

Souhlas.

[xlenga01]

OK, omlouvam se, ze to trvalo tak dlouho, nicmene nova verze je ve skladu. Byly provedeny nasledujici upravy: 1, do Participatioon pridany atributy isPaid a sponsorshipLvl 2, do User pridal atribut Specialization 3, misto vztahu M:N mezi user a partitipation pridana tabulka UserPartitipation s odpovidajicimy vztahy

[FilipMatys]

Diky Tome. Nezapomen si zalogovat praci.