Starší komentáře ke článku: Návrh aplikací v jazyce UML - složitější diagram případů užití
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 17.8.2004 13:05:13
Tak jsme se dockali pokracovani. Hezky clanek. Verim, ze dalsi pokracovani nebude mit tak dlouhy interval
Datum vložení: 17.8.2004 13:08:43
Dekuji, ja take doufam, ze takove prodlevy jiz nebudou.
Vysvetleni meho zpozdeni naleznete zde <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://blog.vyvojar.cz/rene/archive/2004/08/17/1535.aspx' target='_blank'>http://blog.vyvojar.cz/rene/archive/2004/08/17/1535.aspx</a>
Datum vložení: 17.8.2004 13:07:55
Velmi dobrý článek. Nicméně chtěl bych podotknout, že nepochopení analytického popisu zákazníkem nemusí být vždy způsobeno nedostatkem jeho intelektu. Zákazník mnohdy používá "jinou řeč" než analytik (a naopak), totéž platí i o způsobu myšlení obou individualit. Důležitým předpokladem plodné spolupráce je, aby se výrazové prostředky zákazníka a analytika dostatečně přiblížily. Proto by měl analytik v analýze dbát na použití výrazů z problémové domény zákazníka, příp. ještě doplnit slovníček pojmů. Bohužel, mnohdy ani to nestačí. U větších systémů se tak vyplácí užití prototypování, kdy zákazník přímo vidí, co dostává a může se k tomu konkrétně vyjádřit.
Datum vložení: 17.8.2004 13:11:27
Ahoj Michale,
naprosto souhlasim. Bohuzel vsechny tyto prostredky selhavaji v okamziku, kdy se zakaznik rozhodne, ze ho nasazeni systemu vlastne vubec nezajima, protoze tem "lidem od pocitacu" vubec nerozumi a ze to nejak dopadne.
Prototypovani a upravy jadra aplikace je vetsinou nakladna legrace, kterou ne vzdy je ochoten zakaznik platit.
Datum vložení: 17.8.2004 13:30:03
Ahoj Rendo,
právě, je to především o nalezení společné komunikační roviny. Zákazník by nás měl brát (pokud možno) jako rovnocenného partnera. Nejhorší, co může být, je zákazník, který má při rozhovoru s analytikem pocit, že ho "navštívili ufoni". Znáš to, to je takové to zákazníkovo "uculování" v okamžicích, kdy se mu popisuje "princip činnosti modulu akceptace řešení incidentu".
Bohužel, v 90% případů je to o absolutním nedostatku času zákazníka, překvapivě zejména ve fázi akceptace hotového řešení.
Jinak souhlasím s tím, že prototypování nemusí být vždy finančně průchodné, proto jsem také zmínil větší projekty, kde se tato položka "navíc" rozhodně vyplatí.
Datum vložení: 18.8.2004 14:48:07
Byl jsem kdysi na obou stranách. Diagram užití, krom jiného, definuje podmnožinu činnosti u zákazníka. Proto u zákazníka k aplikaci patří i různé "rituály", které SPOLEČNĚ určují fungování organizace. A obě strany o těchto rituálech moc nekomunikují, pro uživatele jsou samozřejmé a např. vyplývající z nějaké vnitřní směrnice a analytik nemá šanci se o nich dozvědět. Pro různé kontroly se dnes vyjíždí určitá sada sestav, která jako celek dává kontrolorovi obraz. Pokud dojde ke změně i jediné sestavy, může to tyto "stínové" informace a vazby rozbít a vyvolat velkou roztržku. Navíc ve fázi, kdy je vše hotovo a musí se dělat velké překopávky...
Datum vložení: 17.8.2004 14:04:20
Jeste bych se chtel zeptat, z jakeho programu jsou ty diagramy.
S UML diagramy teprve zacinam, takze mi nazev EA 4.00 nic moc nerika a ani google nepodal moc presvedcive vysledky.
Predem dekuji
Datum vložení: 17.8.2004 14:17:24
V dobe psani clanku jsem zkousel Enterprise Architecta, takže obrázky jsou z něj.
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.sparxsystems.com.au/' target='_blank'>http://www.sparxsystems.com.au/</a>
Datum vložení: 17.8.2004 14:24:09
A jaky nastroj byste z vlastni zkusenosti doporucil?
Z doslechu vim, ze PowerDesigner by mel byt nejlepsi.
Neporadil byste taky neco, jak nejlepe zacit s navrhy aplikaci v UML? Vase clanky jsou dobre citelne a docela se v nich vyznam ale kdyz to chci aplikovat na nejaky vlastni pripad, tak se stretavam s mnoha problemy, jako zakladni treba neznalost funkci napr. vyse zminovaneho Case nastroje.
Doted jeste uplne nechapu k cemu vsemu je dobre pouzivat takove nastroje a z ceho zacit. Ale nadruhou stranu jsem se o UML analyzy zacal zajimat pred par dny, tak snad casem budu moudrejsi.
Datum vložení: 17.8.2004 14:33:19
Ja myslim, ze na zacatku si uplne vystacite s tuzkou nebo papirem, pripadne s nejakym jednoduchym kreslitkem jako je MS Visio. Take
jsem tak zacinal.
V prvni fazi vas totiz sofistikovane nastroje spis matou, protoze se soustredite na jejich propracovane vychytavky a unika vam smysl diagramu.
PowerDesigner je take muj nejoblibenejsi CASE nastroj, jen ta jeho cena je dnes preci jen trochu vysoka...
Datum vložení: 17.8.2004 14:58:21
Smysl použití CASE nástroje vidím především v zajištění konzistence a dobré čitelnosti vytvářených modelů. Pokud jste zároveň v roli analytika i vývojáře, lze předpokládat, že tužkou vytvořené diagramy plně postačí (pokud je bude schopen a ochoten číst i zákazník). Nicméně ve chvíli, kdy má analytikův "produkt" převzít a pochopit několik vývojářů nebo prostě musíte dát Vašemu projevu formu z důvodu širší prezentace, jste s "malůvkami" v koncích.
Další, sice stále ještě nepříliš použitelnou (prodejci těchto nástrojů Vám samozřejmě budou trdit něco jiného), ale zajímavou vlastností některých CASE nástrojů, zejména pro fázi návrhu aplikace, je možnost automatického vygenerování kostry projektu (na základě jeho statického modelu/diagramů tříd) a naopak tzv. reverse-engineering, když je zapotřebí zmapovat existující zdrojový kód a extrahovat z něj model (laicky řečeno, vygenerovat z kódu diagramy). Naopak docela obstojně tyto mechanismy fungují v případě návrhu struktury relačních databází (umí i Visio).
Datum vložení: 18.8.2004 11:04:44
EA mi nepřišel špatný, zvláště pokud vezmeme v úvahu jeho cenu. Jinak jsou tyto nástroje _velmi_ nákladné. Některé produkty mají "free" verze, které jsou všelijak omezené (např. jeden diagram každého typu, max. počet objektů, apod.), ale obrázek se v nich udělat dá. Například Borland Together Community Edition už (prý) umí i UML 2.0, což se může hodit.
Power Designed ale neznám.
Datum vložení: 19.8.2004 9:23:39
Nemohl byste být konkrétnější, o které free verze se jedná? Dělám práci do školy, kde navrhuji /modeluji/ systém s pomocí UML a pokoušel jsem se najít SW alespoň pro jednoduchou prezentaci diagramů. Zatím se mi nepodařilo najít free verzi, kde by se to alespoň trochu smysluplně dalo provést a použít. Že bych se legálně dostal k jakékoli "plné" verzi je i nás bohužel nereálné a z hlediska mojí práce i zřejmě zbytečné.
Datum vložení: 19.8.2004 9:31:07
Resenim jsou asi Community edition nastroju.
Viz treba
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.visual-paradigm.com/productinfovpumlce.php' target='_blank'>http://www.visual-paradigm.com/productinfovpumlce.php</a>
Omezeni je na jeden diagram v projektu + pridani loga do tistenych diagramu. Na skolni projekt asi takovy nastroj staci.
Datum vložení: 19.8.2004 11:17:19
Děkuji, to by mohlo být ono.
Datum vložení: 20.8.2004 8:24:51
ja jsem na skole pracoval s MetaEdit+ od <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.metacase.com' target='_blank'>http://www.metacase.com</a>
podporuje jakoukoliv metodologii.. OMT,BORM,UML dle toho jaky plugin mas k dispozici. Nebo si vytvoris svoje pravidla pro navrh.
pro akademickou sferu zdarma.
Nevim jestli maji i samostatny soft, ale tohle bezelo jako upraveny image Smalltalku.
Datum vložení: 20.8.2004 14:29:48
No, díval jsem se na to, ale z licenčních podmínek pro akademickou sféru jsem pochopil, že by to asi byl trochu problém. Abych to vysvětlil, škola kde dělám externě doktorandskou dizertační práci má legálně nástroj Rhapsody (I-logix). Jeho používání je ale omezeno jen na katedru a tím pádem je to pro mě mimo, protože nemůžu na měsíc vypadnout z práce, abych seděl u počítače ve škole cca 150 km, od mého bydliště. V zadání mám vytvoření systému pomocí UML + možnost animace 1. stupně na úrovni příslušných diagramů. Tak se snažím najít nástroj, ve kterém bych to mohl dělat po večerech doma. Jelikož nedělám v oblasti IT, tak se moc neorientuju a k OO metodám jsem se dostal vcelku nedobrovolně, ale jiná cesta není. :-)
Datum vložení: 6.9.2004 13:38:55
Jeden z rozsirenych CASE v CR a SR je aj Select Component Architect - tiez doporucujem pozriet ...
Kedze je pomerne pouzivany v tomto teritoriu tak skor narazite na ludi, co s tym maju prakticku skusenost a vedia aj poradit.
:-)
Datum vložení: 31.8.2004 13:35:43
Skúste pozriet <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://argouml.tigris.org' target='_blank'>http://argouml.tigris.org</a>, možno bude na niektore veci stačiť. Dokáže neznalého aj trochu postražiť.
Datum vložení: 25.8.2005 15:51:59
Mj., když už jsme u těch nástrojů: na simulaci Business Procesů lze použít: http://www.craftcase.com. (zatim o nevim, kdo jinej to umí - Power Designer to umí exportovat do Simul8, jinak nevim) A hodně dobrej nástroj na tvorbu Webů s užitím jazyka WebML je http://webratio.cz/ Jenom licence stojí dost neuvěřitelný a nereálný peníze.
Datum vložení: 20.8.2004 16:46:34
Pekny clanek.
Ad generalizace Use Case - u prikladu, ktery uvadite (Sprava incidentu - Zalozeni incidentu, ...) bych vahal, zda-li se jedna opravdu o generalizaci. Ja bych v tomto pripade pravdepodobne pouzil spis "rozpad" use casu (jakesi zanoreni - vytvoreni use casu na n-1 urovni ...). Budeme-li totiz generalizaci chapat v zazitem smyslu jako ' generalizaci/specializaci" (obdobne jako u trid), pak tento priklad neni uplne stastny (jinymi slovy muze specialnejsi pripad vzdy nahradit obecnejsi?). Nicmene s podobnym pouzitim teto "konstrukce" jsem se setkal jiz vickrat, tudiz mozna jsem na omylu ja ...
Jinak pokud jde o CASE nastroje - jak bylo zmineno v diskusi - nedavno vysel <B>Together CC Comunity edition </B>(mel by byt free). Nevim presne jaka ma omezeni oproti plne "verzi", ale jelikoz je IMHO TCC jeden z nejlepsich OO CASE vubec (mel jsem to stesti, ze jsem v prubehu let poznal OO CASE nastroju docela dost), tak bych rozhodne doporucoval se na nej mrknout.
Dalsi free OO CASE krome EA by mohl byt <B>Poseidon for UML</B>(gentleware.com), nicmene ten je podle me pro vaznejsi praci nepouzitelny (zatim obsahuje dost chyb).
Pokud jde o Metaedit, ten byl vzdycky jenom zajimavy tim, ze umoznoval nadratovat vlastni metodu (viz BORM). Jinak mi az tak zajimavy (natoz user friendly) neprisel.
Powerdesigner? Uz jsem jej dlouho nevidel, ale naposledy kdyz jsem se s nim setkal, tak se pod "podporou UML" skryvala moznost vytvaret class diagramy a to bylo tusim vsechno. Ale to uz je docela dlouho.
A posledni - zajimava byla zminka o pouzivani Use Case modelingu v komunikaci spolu se zakaznikem. Mam v tomhle smeru dost rozdilne zkusenosti. Obecne bych si troufal tvrdit, ze vetsine lidi (=koncovych zakazniku) moc nesedi premysleni v abstraktnich pojmech, natoz hledani souvislosti mezi nimi (viz vazby include/extends, ...). Nejlepe lze IMHO v komunikaci s klientem pouzit activity diagramy na urovni modelovani procesu. Cokoliv dalsiho dela zakaznikum vetsinou problemy. Vyjimkou jsou technicky zamereni jedinci.
Dospel jsem postupne k nazoru, ze pouzivat UML v komunikaci spolu s klientem neni prilis vhodne. Jak vyplynulu z komentare Michal J., analytik by mel opravdu slouzit jako "interface" mezi svetem uzivatelu a programatoru (nebo designeru) s tim, ze by se s klientem melo opravdu mluvit vzdy jeho reci, pouzivat jeho nastroje.
Happy modelling ;)
Petr S.
Datum vložení: 20.8.2004 17:09:26
Dobry den,
ad generalizace) Cekal jsem, kdo se ozve jako prvni :) Souhlasim, ze se daji najit lepsi didakticke priklady na generalizaci a ze mnou uvadeny priklad pusobi ponekud umele. Ale v praxi je prave abstrakce spravy ciselniku velmi dulezita pro zprehledneni diagramu. Kdyz se nad tim zamyslite, zjistite, ze opravdu o generalizaci jde - konkretnejsi pripad muze byt dosazen na misto obecneho, protoze se take jedna o spravu ciselniku. Ta vyznamova nuance je v tom, ze abstraktni UC Sprava* je intuitivnejsi na pochopeni, kdyz si ji predstavime jako mnozinu zahrnujici vsechny k ni vztazene konkretni UC jako sve elementy.
Na urovni class diagramu (typ, podtyp) jsou pravidla pro generalizaci ale formalnejsi a striktnejsi, uznavam.
Nevyhodou "rozpadu" UC, ktery poskytuji nektere CASE nastroje, je to, ze nejde o UML vyrazovy prostredek.
Stale mi take generalizace prijde vhodnejsi nez pouziti "pretizeneho" vyznamu slova extend v UML az do verze 1.2.
Ad PowerDesigner) PowerDesigner uz zvlada mnohem vic, i kdyz na "ciste" UML mi EA prisel lepsi ;)
Ad vztahy se zakaznikem) Kolega Michal moji myslenku mirne zastrel - hned na zacatku zaverecneho odstavce je varovani, aby diagram nebyl pretezovan pokrocilymi rysy. Ja si take urcite nemyslim, ze zakaznik by mel dostat lekci z klicovych slov extend a include.
Jsem rad, ze se vam clanek libil a Happy Modelling preju take ;)
Rene Stein
Datum vložení: 22.8.2004 20:08:23
nie som "od fachu", aspon co sa UML tyka ale spomenul som si, ze v KDE je myslim defaultne UML softik Umbrello. Vie mi niekto k tomuto pocinu nieco povedat? Je to vobec pouzitelne? Alebo ma vobec cenu s takymto niecim zacat?
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://uml.sourceforge.net/' target='_blank'>http://uml.sourceforge.net/</a>
Datum vložení: 25.8.2004 13:51:15
Cau,
tem co zacinaji s UML muzu jen doporucit knihu "UML a unifikovany vyvoj aplikaci"
(<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://knihy.cpress.cz/Book.asp?ID=727)' target='_blank'>http://knihy.cpress.cz/Book.asp?ID=727)</a> a nastroj spolecnosti Borland "Together Designer Community Edition"
(<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.dbsvet.cz/view.php?cisloclanku=2004080301)' target='_blank'>http://www.dbsvet.cz/view.php?cisloclanku=2004080301)</a>.
Martin
Datum vložení: 25.8.2004 13:53:40
Cau,
koukam, ze neni radno davat odkazy do zavorek :-)))
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.dbsvet.cz/view.php?cisloclanku=2004080301' target='_blank'>http://www.dbsvet.cz/view.php?cisloclanku=2004080301</a>
<a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://knihy.cpress.cz/Book.asp?ID=727' target='_blank'>http://knihy.cpress.cz/Book.asp?ID=727</a>
Martin
Datum vložení: 3.9.2004 13:04:57
Příspěvek se mi velice líbil.
Takže jsem si soukromě chtěl v UC problém rozebrat podrobněji.
Bohužel hned na začátku jsem narazil na docela banální problém.
Jak nazvat anglicky slovo "řešitel". Upozorňuji, že standardní slovník toto slovo nezná.
Datum vložení: 15.10.2004 9:20:01
Ještě jeden drobný dotaz na zkušenější. Pro školní práci používám Visual Paradigm for UML, freeware z webu ve kterém se mi podařilo vytvořit model systému. Bohužel jsem se od školitele dozvěděl, že je nutné pro obhajobu vygenerovat kód a předvést animaci. VP obsahuje položku Java pro generaci kódu, ale zřejmě tam mám chyby protože nedostanu žádný výstup. Jestli lze provést animaci mi není jasné (jak). Ze stránek jsem to nějak nepochopil. Chtěl bych se tedy zeptat, zda s tím někdo nemá zkušenosti, jestli to ve VP 3.2 vůbec lze provést (generace kódu, animace). Předem děkuji.
Datum vložení: 22.10.2004 20:14:21
jestli je to jeste aktualni : animaci sekvencnich diagramu umi provest select component architect (viz <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.selectbs.com' target='_blank'>http://www.selectbs.com</a> , mozna po vas budou chtit registraci, ale tim se nenechte zaskocit :-)
pokud vam jde nejde o animaci dle sekvencnich diagramu, ale napr. o animace prechodu mezi obrazovkami, dovedl bych si to predstavit take pomoci sekvencniho (jednotlive obrazovky pouzit jako "objekty", prechod mezi obrazovkami ovsem musite znazornit jako poslani zpravy od jedne obrazovky ke druhe, nikoliv zpravou od aktora k te prvni obraovce)
nevim o jinem (v nasem regionu) pouzivanem CASE, ktery by toto umel
kdyz tak mi napiste na e-mail
Datum vložení: 22.10.2004 20:22:50
aha - nevim, kam toto forum zahazuje e-mail adresu, kterou jsem vyplnil do hlavicky prispevku, takze zde je jeste jednou : pavex2@email.cz
jeste bych upresnil - od selectu se da ziskat demonstracni verze zdarma, ktera je omezena (v jednom modelu muzete vytvorit jen jeden diagram kazdeho typu apod.), ale animace tam delat muzete
Datum vložení: 22.10.2004 20:25:54
Na to je odpověď jednoduchá, stačí si přečíst upozornění hned pod textovým polem pro reakci...
Datum vložení: 23.10.2004 11:19:49
aha, mate pravdu, omlouvam se ....
Datum vložení: 2.11.2004 22:37:33
jako člověk analytik, který se pohybuje často u zákazníka, mám v případě use case takové zkušenosti.
Use case jsou podpůrným prostředkem pro definování uživatelských požadavků. Až se nadefinují uživatelské požadavky a případně se rozšíří o uvedené use case modely, může se přikročit k definici softwarové specifikace, neboli co skutečně bude daný software dělat. I v této fázi lze do této specifikace zahrnout use case modely.
Obecně lze use case modely rozdělit asi do několika pohledů : business model, user model a případně (pokud to specifický systém vyžaduje) systémový use case model. V žádném případě bych se nesnažil vytvářet nějaké dekompozice use case modelů. A stejně tak bych bych se nesnažil, aby use case model kopíroval nějaké nabídkové menu.
Mluvit v současnosti o nějaké generalizaci v use case mi nepřipadá vhodné, protože v současnosti neznám zákazníka, který by tomu rozuměl nebo spíše chtěl rozumět.
Datum vložení: 3.11.2004 13:20:07
mám zkušenost, že v use case modelu může někdy pomoct gen-spec pro aktory, např.:
mám organizaci, kde pracuje "operátor", "vedoucí týmu, "vedoucí oddělení", "top manager" --> některé use case mohou provádět jen "top manageri", některé jen "vedoucí týmu", ale některé (obecné činnosti) mohou provádět všichni vyjmenovaní aktoři --> pokud je takovýchto činností více, musel bych ke všem vždy namalovat všechny 4 aktory --> vytvořím tedy aktora "zaměstnanec", který má 4 specializace;
myslím, že toto je schopen zákazník pochopit (zde vidíte aktora zaměstnanec, který se "dělí" na tyto 4 aktory .... pokud uvidíte u use case aktora "top manager",může to provést jen váš top manager .... pokud u use case uvidíte aktora "zaměstnanec", může to provést kterýkoliv z oněch 4 aktorů);
generalizaci use case ovšem nepoužívám
Datum vložení: 3.11.2004 14:14:16
vim jak to myslite, mě spíše napadá ten pohled, že aktor (role) top manager je právě odlišná v tom, že používá jinou funkcionalitu než řadový zaměstnanec, tudíž to bude jiný případ užití. Tzn. že pokud mají obě role nějakou společnou funkcionalitu - teď mě napadá Login, udělám use case na Login a pak u use case pro třeba Top Manager napíšu do precondition = musí předcházet use case Login. Víte, připadá mi, že se variabilita Use case modelování dohání analytiky a vyvojáře k tomu, že se snaží do toho "vecpat" pokud možno všechno a přitom se tak trochu zapomíná na to, pro koho je to především určeno. Že je to uživatel a právě v takovém případě vyhrává pokud možno jasný, jednoduchý a srozumitelný use case. Co však bývá zábavné, když zpočátku nakreslíte třeba 20 případů užití, den, dva si s tím hrajete a zredukujete je na max. 10, které budou jasné. A zákazník Vám pak řekne - No přesně takhle to chci, vždyť je to úplně jednoduché ALE proč vám těch 10 koleček trvalo 2 dny ???
Datum vložení: 3.11.2004 14:29:36
řeknu to tedy jinak : mám 6 rolí, každá má několik svých funkcionalit, ale všechny společně také mají několik obecných funkcionalit, např.:
prohlížení reportů, objednávání obědů, vybírání dovolené, kniha docházek, prohlížení kalendáře, poznámkový blok, čtení novinek..... atd. atd.
u všech těchto use case namalujete všech 6 aktorů ?
mé zkušenosti jsou ty, že když u těchto use case namaluju jednoho aktora "zaměstnanec", tak je to právě přehlednější, jednodušší a jasnější
- další výhoda je, že zákazník nemusí podrobně kontrolovat, zda jsou všechni potřební aktoři u use case namalováni a zda tam nějaký (sedmý) nechybí (kontroluje přítomnost jen jednoho obecného
- a je to i flexibilnější pro případ, že v budoucnu budu potřebovat přidat další roli spadající pod aktora "zaměstnanec"
Datum vložení: 3.11.2004 14:53:49
Chápu co myslíte, to co říkáte je v pořádku. Jistěže můžete nakreslit jeden diagram pro zaměstance. Druhý - separátně pro pro top managera. šlo mě o to, že se mi nezdá vhodné vše zakreslit do jednoho diagramu a v pak tam udělat generalizaci aktora. O čem přece je use case ? jedná se o případ užití. Tu generalizaci aktora můžete udělat separátně. A proč. Až budete psát softwarovou specifikaci, kterou Vám zákazník podepíše a podáte si ruce a řeknete, tak tohle bude software dělat, tak tahle dokument bývá většinou dělen do dvou částí - overview - pro toho, komu se nechtějí číst detaily a nemají na to čas (manažer), ale především proto aby kdokoliv rychle věděl, o co jde, a detaily specifikaci (pro fázi design) a tam ty druhé use case umístíte. A právě v první části se píše kromě jiného o charakteristikách uživatele a tam tuhle genralizaci aktorů dáte. A t ostatní případy užití doplníte do funkčních specifikací.
Datum vložení: 3.11.2004 15:41:08
teď nějak nerozumím (ad ".... jeden diagram pro zaměstance. Druhý - separátně pro pro top managera ....") - diagramy se nedělají pro konkrétního aktora (!)
jak bys to tedy udělal ? u všech těch "obecných" use case budeš kreslit vždy všech 6 aktorů ? nebo žádného a píšeš to někde v textu ? nebo jak ?
ale nejde jen o to - aktor může mít definovány další závislosti, může mít odkazy na třídy a interfejsy, kterými je implementován, může mít definovány externí odkazy, jako element může podléhat version managementu atd. atd. - a toto všechno pak musíš udržovat (v našem příkladě) 6 krát - a abych to mohl dělat jen jednou a znovupoužít, použiji gen-spec (někteří analytici tvrdí, že ve svém důsledku je v OO největší přínos v re-use --- ale ty se o něj tímto přístupem na analytické úrovni ochuzuješ ....)
neber to jako flame-war --- diskutuju tu svůj názor na věc, ok ?
Datum vložení: 3.11.2004 16:05:19
V pohodě, rád s někým diskutuji o problému. Problém je, mít na to čas.
Diagramy use case se dělají pro aktory nebo role. Tzn. role může být řadový zaměstnanec. Role může být IT manager. role IT managera používá funkcionalitu stejnou jako řadový zaměstnanec. Ale díky své roli muže například využívat funkce systému třeba IT governance, což řadový zaměstanec nemůže. Pak udělám co, jeden use case pro aktora Zaměstnanec a druhý use case pro IT managera. A do třetího diagramu udělám generalizaci (i když se jí bráním) těchto dvou aktorů. Nic se nikde neduplikuje. Nevím co myslíš těmi odkazy na interface a třídy ... elementy. Zdá se mi, že vtahuješ Use case model do designu, ale tam nemá co dělat.
Datum vložení: 3.11.2004 16:51:02
dobře, tvůj názor znám - takže přece jen používáš generalizaci :-)
jen by mě zajímalo, jaks došel k tomu, že děláš use case diagramy pro aktory nebo role - jestli jsem to dobře pochopil, tak děláš pro každou roli zvláštní diagram ?
tj. v našem příkladě : máme 6 různých rolí, všechny role společně provádí, dejme tomu, 10 stejných use case (kromě toho samozřejmě každá role má spoustu dalších svých use case) - tedy ty namaluješ 6 use case diagramů (pro kažou roli samostatný diagram), kde těch 10 společných use case zduplikuješ ?
pokud ano, jak jsi k tomu došel, kdo ti to poradil nebo z jaké metodologie to máš ?
Datum vložení: 3.11.2004 17:26:32
raději pro jistotu => use case model = use case diagram, a ten se skládá z aktorů a řekněme několika use cases. use case je to kolečko. Sorry, že to tak píšu, ale ať je jasno.
nevím, jestli tě dobře chápu, říkáš máš 6 různých rolí a kromě toho, že každá dělá něco specifického, používají stejnou funkcionalitu (zmiňovaných 10 use case v rámci jednoho use case modelu).
Navaž tedy tento jeden model (s 10 use cases) na společného aktora (vhodně ho pojmenuj třeba ABC)
Pak pro každého Aktora udělej jeho use case model, kde budou jen jeho případy užití, které jiný nemá.
No a nakonec můžeš udělat generalizaci aktorů, tzn. aktor ABC a pod ním těch 6 aktorů. Na solo diagram. A to je vše.
A proč používám takové postupy ? Výsledek diskuzí a dohadů mezi analytiky (ale konstruktivních), a především praxe. Metodologie na Use Case neexistuje. Speciálně Use Case jsou natolik variabilní, že se o nich můžeš dohadovat donekonečna. Co považuji za podstatné, je aby je zákazník a dodavatel shodně pochopily. Já si spíše lámu hlavu, jak modelovat real-time systémy, kde interaktiva uživatele je minimální, a přesto ovlivňuje zásadně chod celého systému a pokud use case jen trochu vtáhneš do designu, začneš okamžitě technické detaily s developery. Ale tohle by analytik dělat neměl.
Datum vložení: 3.11.2004 18:34:05
aha - tak už mě je to jasnější :
- takže používáš generalizaci tak, jak jsem popisoval v dnešním prvém příspěvku, že ano ?
- máš guláš v pojmech : mixuješ a zaměňuješ pojmy "model" a "diagram" : obecně use casemodel se nerovná use case diagram, žel ani autor tohoto seriálu to nevysvětlil dostatečně :-(
- vytvářet separátní diagramy pro každého aktora je sice možné, dle mého ale nevhodné; můžeš přicházet o resuse (include, extend, pokud tedy zavrhneme generalizaci use case), v komplexnějších systémech to IMHO povede k znepřehlednění, a je to IMHO méně flexibilní k budoucím změnám
- metodologie se samozřejmě dotákají i use case modelu (viz UP/RUP, agile modeling, doporučení samotných autorů UML v UML user guide a uml reference guide
- UML 2.0 přináší podporu timing modelování, zkus si něco najít i k UML profiles (tuším že jeden profil je k real-time modelování)
- podrobněji už to tady asi fakt není vhodné, když tam na e-mail či icq (nick pavus)
zdar !
Datum vložení: 3.11.2004 19:13:10
Ještě zareaguji, snad se ten čas přehlédne. Model = diagram = to je přesně to slovíčkaření, které v praxi málokoho zajímá. Jestli do dokumentu napíšu - Diagram ABC nebo Model ABC. To fakt nikoho nezajímá. Vytvářet separátní diagramy pro každého aktora, to jsem vůbec neřekl, pouze jsem naznačil jak řešit případ, který uvádíš. Jasně, že můžu do modelu (diagramu) namalovat více aktorů. K tomu není vůbec co dodat.
K metodologii ... jasně, že je UML jakási visuální metodologie, pro modelování systémů. V případě Use Case máš k dispozici tohle a tohle, nějaký include a exclude adt. A použij to takhle. Jenže, to co jsem myslel, je právě ta variabilita jak to kreslit, do jaké hloubky jít atd. A tady tě žádná metodologie nezachrání, protože neexistuje. Existuje pouze X doporučení (a pro mne doporučení neznamená metodologie) jak to nejlépe kreslit.
Ale opět, možná jsme každý na jiné lodi. Já jsem analytik, který vytahá z uživatele požadavky a produkuje analytické dokumenty pro dálší fázi Design. A nejedná se o malé systémy.
Mě pořád připadá že do Use Case taháš Design. Co je tvá pozice ?
Datum vložení: 8.12.2006 9:18:20
<<include>> <<extend>> Ahojte, robim UML diagram V Microsoft Visio a neviem kde tam mam najst sipku <<include>> a <<extend>>. Ak sa nemzlim mala bz bzt prerusovana, ale taku tam nenachadyam, viete mi pleas poradit???? vopred moc vdaka