UML diagram tříd

[jugli]

Dobrý den,byl by prosím někdo tak hodný a poradil studentovi jak má udělat  diagram tříd..respektive jde me jen o jednu část,kterou nemohu namodelovat.
Mám abstraktní třídu osoba a dvě podtřídy zákazník a odběratel. To by nebylo nic těžkého,ale zákazník a odběratel může být buď fyzická nebo právnická osoba a tedka právě nevim jak tam mam fyzickou a právnickou osobu zakomponovat.
V příloze je obr. něco jsem nakreslil ale asi je to blbost :-(
Mnohokrát Vám děkuji.
Moc mě pomůžete
Děkuji Karel

[Reklama]

[alex6bbc]

osoba je zakladni trida/interface.
z osoby lze oddedit detske tridy fyzicka_osoba, pravnicka_osoba.
z fyzicke/pravnicke_osoby lze oddedit 4 detske tridy zakaznik_pravnicka_osoba, odberatel_pravnicka_osoba, zakaznik_fyzicka_odoba, odberatel_fyzicka_osoba.

v realu bych asi nevytvarel takovou hierarchii tridy, ale spis pouzil kompozici, ze by
trida odberatel obsahovala volitelne data (optional) bud pro fyzickou nebo pravnickou osobu atp.

[LadislavBohm]

Podle me je to nevhodne pouziti dedicnosti, ale chapu, ze ve skolach se to tak stejne porad uci. Bylo by vhodnejsi pouzit "composition over inheritance", jehoz popis najdete treba tady:
https://en.wikipedia.org/wiki/Composition_over_inheritance

Je to tam vcetne obrazku, ale zkratka bych to popsal tak, ze napriklad jeden a ten samy zakaznik muze nekdy v systemu vystupovat jako pravnicka osoba (objednavam "na firmu") a nekdy jako fyzicka (objednava "pro sebe"). Proto potrebujete tu "fyzicnost" a "pravnicnost" osoby zahrnout jako kompozici. Neboli jako vlastnost, kterou ten zakaznik muze nebo nemusi mit. Stejne by to asi platilo pro odberatele.

Ale obecne je urcite mnoho zpusobu jak tohle resit, nicmene si myslim, ze dedicnost je pro to nevhodna.

[RDa]

A proc to nevzit tak jak to doopravdy je:

Osoba je zakladni trida, odvozene jsou fyzicka (majici RC) a pravnicka (majici ICO), s tim, ze u pravnicke je prvek zastoupen (typove: Fyzicka osoba). Odberatel a dodavatel jsou jenom ROLE, neprinasi zadne rozdily v strukture.

Mohl by jste ty role integrovat s vektorem priznaku (nekdy-dodal, nekdy-odebral), neboli skrze interfacy. Ale tyto role nejsou vyhradni, pac samozrejme neni vylouceno, ze dany subjekt nebude jak dodavatelem tak odberatelem
(pokud tedy nechcete definovat roli dedici obe role - napr. s nazvem Obchodni partner)

EDIT: vy tam mate zakaznik/odberatel, to se snad nelisi ne? FO je vzdy zakaznik, PO je vzdy odberatel. Ja to blbe precetl, proto ta jina reakce vyse.

[SB]

Správně to píše až RDa - osoba (jinak též právní subjekt) je obecná, v ČR pak jako uvedené 2 specializace. Dodavatel a odběratel jsou pouze role, tudíž vznikají až v nějaké souvislosti, např. na objednávce, přičemž vůbec nemusejí být vyjádřeny samostatným objektem, spíše se vyskytnou např. ve formě vlastností oné objednávky.

Doporučuju oprostit se od uvažování o dědičnosti a přemýšlet o hierarchii jako specializaci + generalizaci.

[Reklama]

[Ondrej Nemecek]

Správně to píše až RDa - osoba (jinak též právní subjekt) je obecná, v ČR pak jako uvedené 2 specializace. Dodavatel a odběratel jsou pouze role, tudíž vznikají až v nějaké souvislosti, např. na objednávce, přičemž vůbec nemusejí být vyjádřeny samostatným objektem, spíše se vyskytnou např. ve formě vlastností oné objednávky.

Doporučuju oprostit se od uvažování o dědičnosti a přemýšlet o hierarchii jako specializaci + generalizaci.

Jj, a ty role budou mít pak třeba nějaká oprávnění. Takže osoba bude mít sadu rolí a role bude mít zas sadu oprávnění.

Interface je pak potřeba udělat tak, aby pro většinu funkcí stačilo pracovat s Osobou. Aby se třeba v GUI nemuselo rozlišovat zda pracuji s Právnickou nebo Fyzickou osobou. Pokud se to takto navrhnout nepodaří, raketově roste složitost a nečitelnost kódu...

[SB]

...Takže osoba bude mít sadu rolí a role bude mít zas sadu oprávnění.

To nemusí být vůbec pravda, ta oprávnění např. můžou vyplývat z té smlouvy, ne osoby, pak nemusí mít smysl modelovat je u osoby.

Interface je pak potřeba udělat tak, aby...

Na této úrovni abstrakce se interface obvykle nevyskytuje, dokonce ani dost jazyků jej nemá.

[Ondrej Nemecek]

...Takže osoba bude mít sadu rolí a role bude mít zas sadu oprávnění.

To nemusí být vůbec pravda, ta oprávnění např. můžou vyplývat z té smlouvy, ne osoby, pak nemusí mít smysl modelovat je u osoby.

Jasně, řešení je víc, myslel jsem to tak, že oprávnění jsou často další požadavek a tak je dobré rovnou zauvažovat, kde tam budou. Může to odhalit špatný návrh nebo potvrdit správný.

Interface je pak potřeba udělat tak, aby...

Na této úrovni abstrakce se interface obvykle nevyskytuje, dokonce ani dost jazyků jej nemá.

Moc nerozumím, uvažuju v intencích javy a třeba seznamu osob, kde pro výpis toho seznamu nemusím rozlišovat, zda je to právnická nebo fyzická osoba. Když je pak potřeba to rozlišit, mohu použít polymorfismus.

PS: Ale podle mě zrovna v tomto učebnicovém příkladu dojde té javě podle mě rychle dech (což je řešitelé reflexí, což je ale de fakto rezignace na OOP).

[SB]

Na této úrovni abstrakce se interface obvykle nevyskytuje, dokonce ani dost jazyků jej nemá.

Moc nerozumím, uvažuju v intencích javy...

Chyba, to nikdy nedělejte - tazatel řeší čistě obecný návrh a i vám hrozí, že si předčasně zavlečete do rozboru problémy implementace. Na prznění dle (ne)schopností daného jazyku, DB ap. je času dost.

[frantaN49]

Asi bych to dělal podle toho do jakého školního projektu to potřebuješ. Pokud je to semestrální projekt na střední, tak bych to udělal metodou žaves. Jestli je to do diplomové práce, tak to udělal sofistikovaněji.

Osobně jsem ale nikdy moc nepochopil k čemu dělat tyhle diagramy předem. Radši jsem nejdřív vše naprogramoval (původní představa se často změnila) a ten diagram (když byl vyžadován) udělal až podle hotového projektu. Ale každý to má jinak...

Metodou žaves bych to řešil asi takto:
osoba se rozděluje na zákazník a odběratel, kde každý z nich má atribut typ osoby. Typ může být "fyzická osoba" nebo "právnická osoba".

Sofistikovaně: použití toho kompositoru nebo podrobného větvení, ale nesmíš se do toho zamotat a musíš to pak umět vysvětlit a obhájit, pokud se tě kantor(komise) zeptá proč to máš tak dělané.

[Ondrej Nemecek]

Na této úrovni abstrakce se interface obvykle nevyskytuje, dokonce ani dost jazyků jej nemá.

Moc nerozumím, uvažuju v intencích javy...

Chyba, to nikdy nedělejte - tazatel řeší čistě obecný návrh a i vám hrozí, že si předčasně zavlečete do rozboru problémy implementace. Na prznění dle (ne)schopností daného jazyku, DB ap. je času dost.

Proto jsem odpověděl obecně, ať se snaží udělat interface Osoby tak, aby bylo co nejpoužitelnější. Kdo do toho zavlekl závislost jste byl spíš vy - s tím, že požadavek většina jazyků nedokáže dokonale naplnit: „(...) dokonce ani dost jazyků jej nemá“.

[SB]

Osobně jsem ale nikdy moc nepochopil k čemu dělat tyhle diagramy předem. Radši jsem nejdřív vše naprogramoval (původní představa se často změnila) a ten diagram (když byl vyžadován) udělal až podle hotového projektu. Ale každý to má jinak...

Diagramy jsou nástrojem pro ujasnění zadání a popisným prostředkem, na tom není nic objevného. Jejich smyslem a výhodou je právě ta abstrakce a nezabývání se implementací. Obecně začít programovat bez alespoň jakési rozvahy, případně ujasňovat si zadání progamováním, ještě hůře dodělávat analýzu dle realizace je amatérismem (mnoho z nás tak začínalo, někteří tak i pokračují). V případě, že dostanete za úkol pouze vytvořit analýzu požadovaného systému (např. pro jinou firmu, nebo pro zlepšení stávajícího systému), tak se k nějakému programování ani nedostanete!
Samozřejmě, diagrámky můžou řešit různou úroveň, ale bez nich to u složitějších systémů asi nepůjde. Na druhou stranu píše Fowler, že nemá smysl využívat všechny detaily předimenzovaného UML, smysl to má jen dotud, dokud mi to v analýze něco přináší.

[SB]

Proto jsem odpověděl obecně, ať se snaží udělat interface Osoby tak, aby bylo co nejpoužitelnější. Kdo do toho zavlekl závislost jste byl spíš vy - s tím, že požadavek většina jazyků nedokáže dokonale naplnit: „(...) dokonce ani dost jazyků jej nemá“.

Termín interface jste první zmínil vy.

[Ondrej Nemecek]

Proto jsem odpověděl obecně, ať se snaží udělat interface Osoby tak, aby bylo co nejpoužitelnější. Kdo do toho zavlekl závislost jste byl spíš vy - s tím, že požadavek většina jazyků nedokáže dokonale naplnit: „(...) dokonce ani dost jazyků jej nemá“.

Termín interface jste první zmínil vy.

Ano, zmínil, ale podle mě jde o pojem nezávislý na jazyku, ne?

Nicméně to mi žíly netrhá, spíš mě zajímá ta vaše poznámka k tomu interface, co jste tím měl na mysli?

Třeba v té javě mě štve tohle https://github.com/google/guava/wiki/EventBusExplained#what-about-a-generic-handlert-interface

Elementární učebnicový příklad, přitom se nedá řešit čistě. Uvádím, protože bych třeba chtěl, abych si mohl za běhu zaregistrovat zobrazovač, který zobrazí odpovídajícím způsobem osoby fyzické i právnické a běhové prostředí mi samo vybere odpovídající metodu. Tak hezky, jak bych si to představoval, to nejde, musím použít např. reflexi nebo se vzdát typové bezpečnosti. To zamrzí. Ale to už jsme skoro OT.