Starší komentáře ke článku: Návrh aplikací v jazyce UML - textová specifikace případů užití
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 9.9.2004 11:27:48
Teď zrovna zkouším dělat USE-CASE k malému projektu. Není mi ale jasné, zda se do podmínek před spuštěním zahrnují i podmínky typu "Uživatel je přihlášen", "Uživatel má oprávnění k formuláři" apod. Dále přemýšlím, jestli když mám definovanou nějakou podmínku, tak jestli musím tu samou podmínku napsat i v USE-CASE, který mám vložen jako include (např. to oprávnění).
Datum vložení: 9.9.2004 11:31:37
Dobry den,
podminek muzete zapsat libovolne mnozstvi, ale mejte na pameti ze:
U kazdeho UC by mely byt pouze podminky, ktere s nim primo souvisi. Prepoklad, ze je uzivatel zalogovan je natolik obecny, ze nema smysl jej vypisovat do kazdeho UC, ale je vhodnejsi v UC Prihlaseni uzivatele zapsat poznamku, ze system nedovoluje neprihlasenemu uzivateli provadet zadne cinnosti popisovane v ostatnich UC.
Datum vložení: 9.9.2004 13:56:52
OK, moc diky. Už se těším na další díl.
Datum vložení: 28.12.2004 14:54:50
Mně se nezdá, že by přihlašování do systému mělo mít vlastní UC ..copak je logování funkcí systému?.. ne, není, uživatel přece nevyužívá systém tak, že se do něj loguje.
Datum vložení: 25.8.2005 14:04:44
Souhlasím, uživatel získává svou roli teprve zalogováním, proto nejde o UC.
Datum vložení: 6.12.2005 18:15:18
Co vam říká role npřihlašeny uživatel? Obvykle mam možnost prohližet některe vystupy aplikace a dalši z funkčnosti kterou muže použivat je PŘIHLASIT SE!! Přihlšenim nepřihlašný uživatel ziskavá nějakou novou roly...
Datum vložení: 22.9.2004 14:48:17
Byl bych rad i za clanek o tvorbe modelu obchodnich procesu (BPM). Proste o mapovaní reality. Myslim, ze to je prvni krok pred naslednou implementaci nejakeho reseni.
Mejte se
Datum vložení: 23.11.2004 10:20:42
Dobry den, od kamarada jsem dostal odkaz na vas "UML tutotrial", ktery jsem si teprve ted precetl a mel bych na autora nekolik dotazu vyplyvajicich z prakticke zkusenosti. UML je pouze vyjadrovaci nastroj, nikde v UML neni posana "metodika" jak se ma postupovat, co maji jake objekty obsahovat, atd. Nicmene neodpustim si otazku tykajici se Vasich clanku o pripadech uziti - setkal jste se nekdy s pojmem funkcni dekompozice? Vsichni tzv. "guru" UML, kteri se pozdeji vice ci mene podileli i na tvorbe RUPu, varuji pred jednou ze zakladnich chyb pri tvorbe use case modelu (pravdepodobne ji ze zacatku dela kazdy) a to zamenovanim use casu za funkcnosti navrhovaneho systemu. Jednotlive use casy by mely popisovat ne funkcnost systemu, ale jeden pripad uziti nebo jak to jinak nazvat. Proste cilem je popsat jak se systemem pracuje uzivatel, ne jak je realizovan systemem. Vsechny popisy zminovane ve Vasich clancich tomuto pravidlu odporuji. Takovyto navrh maji tendenci vytvaret vyvojari nebo lide s programatorskymi zkusenostmi - a navrh stoprocentne povede k navrzeni modelu (a potazmo i systemu), ktery bude sice bezvadne pochopitelny pro vyvojare (technicky znale lidi), ale nebude vubec respektovat co od systemu pozaduji uzivatele. Jedna se opravdu o velky problem, neznam nejake jednoduche pravidlo na to jak vytvaret use casy - jedine co vim je, ze tento postup je pravdepodobne spatny :-)
Pokud vite o nejakem reseni nebo mate cokolic zajimaveho k tomuto tematu, tak cokoliv privitam.
S pozdravem
Honza Loucka
Datum vložení: 26.11.2004 10:27:26
Odporucil by som jeden zaujimavy clanok:
<B><a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www.objects.cz/clanky/clanek13/clanek13.asp</B>' target='_blank'>http://www.objects.cz/clanky/clanek13/clanek13.asp</B></a>
(hovori o tom, ze je lepsie tvorit Use-case model cez BPM a nie cez ACTOR-a)
Niesom sice ziadny "UML guru", ale tiez mi pride logicke, ze to hlavne v Use-case modele su prave uzivatelske poziadavky (teda to "co od systemu pozaduji uzivatele") reprezentovane pripadmi uzitia.
Samozrejme prvok Actor, a to ako pouziva jednotlive pripady uzitia, je tiez dolezity, ale nie az tak ako samotny obsah pripadov uzitia.
Datum vložení: 26.11.2004 22:34:22
Dobry denaasi jsem vas prispevek nepochopil, protoze nevim, proti cemu brojite. :)
(Nejen) zakladatele UML varuji pred smesovanim uzivatelskeho pohledu s implementacnim pohledem - to znamena, ze, jak jsem popsal v prvnim clanku o UC, v zadnem pripade nejsou UC psany s ohledem na platformu, programovaci jazyk atd.
Co se tyce pripadu uziti a jejich vztahu k RUP, tak ocituji z knihy UML a unifikovaný proces vývoje aplikaci, ve ktere si snadno muzete ma slova overit, protoze vysla i v cestine - doporucuji se v knize podivat i na priklady popisu UC a srovnat je s mymi.
"Modelování případů užití je jiným doplňkovým způsobem získávání a dokumentování rolí."
"Klíčovými aktivitami metodiky P jsou nalezení účastníků a případů užití"
"Případy užití jsou funkce (!!!!! pozn. aut.), které systém vykonává jménem jednotlivých účastníků nebo v jejich prospěch"
V případě zájmu mohu rozdíly mezi různými přístupy k psaní UC popsat.
Článek pana Kravala zmiňovaný dalším diskutujícím je spíš matoucí, protože "BPM i ACTOR" pristup je komplementarni. Pan Kraval ma v clanku potize s konfuznim zachazenim s terminem Actor, kdy jej nepovazuje za dostatecne vyhranenou roli vuci systemu, ktera interaguje se systemem, ale reaguje se pseudoproblemy, zda "klient banky odstrci obsluhu" a komunikuje se systemem sam. Ach jo ;)
Datum vložení: 30.11.2004 9:11:18
Protoze tusim, proti cemu by Jan Loucka mohl "brojit", dovolim si tez reagovat :
1. Myslim, ze p. Louckovi slo spis o to, ze programatori ci analytici se zkusenostmi ze "strukturovaného vývoje" muzou byt svadeni k modelovani dekompozic funkci (uz v <B>analyze</B>, i kdyz je vytvari <B>nezavisle na implementaci</B> !), tj. podobne jako v DFD ci SAD diagramech rozpadaji funkce smerem dolu, a komponuji je smerem nahoru; tzn. ze nakonec mam sice use case digramy specifikujici sadu pripadu uziti systemu, ale mam tam pak i diagramy dekompozic (dolu) a kompozic (nahoru), takze v nejvyssi urovni mam jakesi "top - use case" nazvany treba "rizeni banky" nebo "knihovna" apod.; UML vsak ani ve sve specifikaci nema dekompozici use case (ma dekompozici packages)
2. myslim vsak, ze v teto serii clanku se problem, jak ho popisuji v bodu 1., nevyskytuje - autor neprovadi funkcni dekompozici (at uz implementacne zavislou ci nezaavislou), ale obecne tento problem existuje a i ja bych uvital, kdyby ho se autor serialu alespon dotknul
3. ad "pripady uziti jsou funkce" - myslim, ze vhodnejsi preklad by znel "funkcnosti" ci "funkcionality" - IMHO to tak mysleli i autori knihy, a jiste i autor reakce (Rene ?)
4. myslim, ze clanek pana Kravala ma neco do sebe : jisteze oba pristupy jsou komplementarni (tj. v obou pripadech bych mel dostat system se stejnymi funkcnostmi), ale myslim ze pri analyze komplikovanejsich systemu lze dojit k cili snadneji zpusobem, ktery I.K. nazyva "pristup pres BPM"
Datum vložení: 5.1.2005 17:20:44
Ja se jeste pokusim vysvetlit, co jsem presne zamyslel svym "brojenim". Strasne casto se u nas setkavam s tim, ze analytici (a opravdu to jsou vetsinou programatori) inklinuji k tomu, ze navrhuji use casy jako jednotlive funkcnosti systemu. Ja tvrdim (a toto me tvrzeni je podlozene od samotnych autoru UML), ze toto je zasadni chyba. Pokud se na tomto shodneme, tak mluvime o stejne veci neni zadneho sporu :-)
Ja jsem jenom nabyl dojmu, ze clanky uverejnovane na techto strankach tykajici se use case modelovani se teto chyby dopusteji - pokud je muj usudek spatny, tak me prosim opravte.
Ja jsem presvedcen o tom, ze v nazvu use casu by nemely figurovat zadne pojmy ala "zalozit", "smazat", "editovat", atd. Tohle vsechno jsou presne jednotlive funkcnosti (nebo funkcionality) systemu jak je vidi vyvojar nebo obecne IT znaly clovek. Laicky uzivatel systemu (to je ten, ktery to potom bude pouzivat) chce vetsinou neco jineho. On chce dosahnout nejakeho cile - k tomu potrebuje treba neco vytvorit, pokud se mu to nepovede tak zeeditovat a pokud treba zjisti, ze uz to neni potreba, tak smazat. Ale vsechno je to soucasti nejake jedne snahy neceho docilit - je to jeden use case. Use case je mnohem "obecnejsi" nez funcknost, je to spis na urovni proceduralni nez funkcni.
Mezi use casem a funkci nebo funkcnosti je diametralni rozdil!!! Proto se v RUPu a v jinych metodikach pouzivaji faze, kdy se mapuji a realizuji vazby mezi use casy a funkcnosti systemu.
Z me zkusenosti (a myslim, ze muzu rict, ze v tomhle ohledu nejake zkusenosti mam) vyplyva, ze pokud nekdo zamenuje use casy za funkcnosti systemu, pak mu misto IS, ktery dela to co zakaznik chtel vyleze system, ktery je shluk samostatnych <B>funkcnosti</B>, ktere dohromady netvori zadny celek. Takovych aplikaci je velke mnozstvi (dokonce bych rekl, ze vetsina), coz je jenom dukaz toho, co tady pisu.
Datum vložení: 6.1.2005 11:42:51
Tak ted jsem zmaten taky - na tom, ze use case model by nemel ukazovat funkcni roklad z hlediska programoveho kodu se asi zhodneme, ale :
1. ad "me tvrzeni je podlozene od samotnych autoru UML" (ze navrhovani use case jako jednotlivych funkcnosti systemu je chyba): ve specifikaci UML 1.5, kapitola 3.54.1 (popisujici semantiku use case diagramu) se pise :
---- citace ------------
The use cases represent functionality of a system or a classifier, like a subsystem or a class, as manifested to external interactors with the system or the classifier.
---- konec citace ----
nevim, jestli jse se s autory sesel u piva :-) a tam vam rikali neco jineho, ale specifikace jasne rika, ze <B>use case reprezentuji funkcnost</B> (funcionality) systemu ci klasifikatoru (treba i jedine tridy)
2. ad "jsem presvedcen o tom, ze v nazvu use casu by nemely figurovat zadne pojmy ala "zalozit", "smazat", "editovat"" :
IMHO tyhle pojmy jsou ok :
a. uzivatel prijde k systemu a chce jen zalozit (treba objednavku), nebo ji zeditovat - proc by mel spoustet jine jednani, nez to, ktere se prave jmenuje "zalozit objednavku" resp. "zeditovat objednavku" ?
b. pokud tim myslite, ze namisto "zalozit", "smazat", "editovat" by tam melo spis byt "zpracovat" (objednavku) v ramci cehoz by tuto objednavku zalozil, a ihned v ramci te same cinnosti by ji mohl zeditovat a pak opravit, tak i to je mozne, ale spravnejsi je IMHO mit zalozeni, opravu a smazani samostatne, nebot : tato tri jednani <B>nejsou na sobe bezprostredne zavisla</B> (pomijim zde, ze opravovat muzu jen to, co uz jsem nekdy zadal - ovsem opravovana polozka se tam klidne mohla dostat jinak, treba importem XML souboru apod.), vysledek kazdeho z jednani <B>zpusobil zmenu obsahu evidovanych dat, tj. zmenu stavu</B> (po zadani ci oprave ci zruseni muzu klidne zacit delat neco naprosto jineho ci uplne prestat system pouzivat) a zadne z techto jednani by <B>nemelo byt "prerusitelne"</B>
3. ad "On chce dosahnout nejakeho cile - k tomu potrebuje treba neco vytvorit, pokud se mu to nepovede tak zeeditovat a pokud treba zjisti, ze uz to neni potreba, tak smazat. Ale vsechno je to soucasti nejake jedne snahy neceho docilit - je to jeden use case." :
a. pokud tim myslite napr. situaci :
<I>pracovnik vieopujcovny chce zaevidovat novou vidokazetu, potrebuje vyplnit udaj "reziser" vyberem ze seznamu (jiz evidovanych) reziseru (tj. vyberem z ciselniku), ale resiser jeste neni v systemu evidovany --> musi cinnost ukoncit a spustit cinnost pro zaevidovani noveho resisera, kde potrebuje vyplnit udaj "narodnost" vyberem ze seznamu narodnosti, ale ona narodnost jeste neni v systemu evidovana --> musi cinnost ukoncit a spustit cinnost pro zaevidovani nove narodnosti --> znovu spusti cinnost pro zaevidovani rezisera (ted uz se to povede) --> znovu spusti cinnost pro zaevidovani videokazety (ted uz to lze)</I>
tak IMHO toto vse neni vhodne komponovat do jednoho use case : uzivatel zjistil v ramci jednani "zadani kazety", ze v systemu chybi potrebne informace (chybi tam reziser, narodnost - nejde o nejakou chybovou vetev, jde o to doplnit do systemu udaje), tak proste ted chce pouzit system jinak (chce vlozit informace o reziserovi ci o narodnosti), tj. musi spustit jine, samostatne jednani pro zadani resisera ci zadani narodnosti - a mel by byt natolik znaly, ze vi, jak toto jednani provest (pripravim mu treba prirucku popisujici predem vytipovane procesy), nebo ze vi, komu ma rict, aby toto jednani provedl
b. pokud tim ale myslite, ze by mely byt namodelovany cele procesy (business processes), tak k tomu proste use case diagramy urceny nejsou, a resit to muzete takto :
- pouzit diagram aktivit
- rozsirit si sam UML, vhodne by bylopouzit <B>profiles</B> : priklad takoveho rozsireni je uveden primo ve specifikaci UML 1.5 v casti "4 UML example profile" : jeden z profilu je tam <B>UML profile for business modeling</B>
- nektere z CASE toolu obsahuji specialni diagramy pro modelovani business procesu
- pockat si na UML 2.0 - mozná by se vam hodil interaction overview diagram
Ale mozna by bylo nejlepsi, kdybyste tu ukazal nejaky komplexnejsi priklad - jestli tedy mate namodelovany nejaky use case <I>podle vas dobre</I>, tak ho namodelujte jeste jednou tak, aby to bylo <I>podle vas chybne</I> (tj. dle autora serialu) : pak by bylo snad jasnejsi, co vlastne chcete rict ....
uff
Datum vložení: 15.1.2005 9:17:52
Ad 1 - myslím, že tento často citovaný odstavec je jen nevhodně překládán. Jak jste z této jedné anglické věty odvodil, že use-case = funkce? Vždyť se tam píše o celých systémech, subsystémech či třídách a nikoliv o jednotlivých metodách (tedy funkcích) daného systému, subsystému či třídy.
Navíc jedna věc je přeci jazyk (respektive jeho syntaxe) a druhá je jeho použití. Tady nám nestačí specifikace 1.5, ale musíme sáhnout po metodikách (např. RUP), které říkají, jak daný jazyk používat. Podívejte se například zde Ivar Jacobson, Grady Booch and James Rambaugh – The Unified Software Process, ISBN 0-201-57169-2. Ty tři jména jsou snad dostatečnou zárukou :-)
Ad 2 a 3 - částečným vysvětlením je tento článek <a href='http://interval.cz/__redirect/redirect.asp?what=interval_discussion&url=http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/WhyUseCasesAreNotFunctionsDec00.pdf' target='_blank'>http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/WhyUseCasesAreNotFunctionsDec00.pdf</a>
Z výše popsaných důvodů tedy use-case například Správa faktur není to samé, jako funkční dekompozice téhož problému na Přidání faktury, Editace faktury a Storno faktury. Rozdíl je v tom, že pokud sebelépe vyřešíte samostatné funkční části, není zaručeno, že efektivně vyřešíte problematiku Správy faktur jako celku.
Samozřejmě, že v určité fázi analýzy/designu se vám to "rozpadne" na tyto funkčnosti, ale je obrovská chyby tím začít. Praxe jasně potvrzuje če těmito přístupy dojdete k naprosto odlišnému návrhu systému (z pohledu uživatele, nikoliv z pohledu vývoje)
Rozdíl mezi use-case Správa faktur a funkční dekompozicí téhož na jednotlivé funkce tedy není v granularitě, ale v naprosto kvalitativně odlišném uchopení celého problému.
Je nutné si uvědomit, že v analýze neplatí 1+1=2, tedy že součet částí je celek, ale že se zde automaticky ještě objevují synergické efekty, které budou buď záporné nebo kladné.
Howk :-)
Datum vložení: 4.3.2005 12:41:13
Nerad bych posouval diskuzi mimo problematiku UML, ale kdyz uz jste to nakousl, rad bych reagoval na doporuceni pouzivat slova "funkcnost" ci "funkcionalita". Ac se s obema slovy v praxi bezne setkavam, jsem presvedcen, ze by se s nimi melo zachazet opatrneji, resp. - podle meho - melo by se spise pouzivat slovo "funkce", ktere je dost obecne na to, aby pokrylo vyznamy, jez se pripisuji slovum "funkcionalita" ci "funkcnost". "Funkcionalita" je podle Slovniku spisovneho jazyka ceskeho "ucelova zamerenost; funkcionalnost, funkcnost, funkce". Jedna se o ridcejsi vyraz. "Funkcnost" jsem jako heslo ve slovniku nenasel. Ale zda se mi jasne, ze znamena proste fakt, ze neco funguje jak ma. Tedy napriklad misto "system je funkcni" lze napsat neco jako "system vykazuje spravnou funkcnost". Nebo jinak, "funkcnost" je vlastnost toho, co funguje, ale neni to konkretni "funkce", neni to to, co je vykazovano jako konkretni pozadovana vlastnost, je to "jen" stav, kdy je dosazeno funkce.
Datum vložení: 6.3.2005 20:36:13
Jestli je to reakce na mne, tak diskuzi klidne posunte - vsak muzete videt z reakci, ze nekdy problemy v komunikaci plynou opravdu jen ze spatneho pochopeni napsaneho (zel nekdy i ze psatneho precteni, ale s tim uz nic nenadelame :-( Tedy svuj postoj osvetlim : s pojmem "funkce" je totiz problem, nebot ve svete programatoru to znamena funkci jako kus programu (laicky receno - nekolik radku programu s vymezenym zacatkem a koncem a pripadne se vstupnimi a navratovymi parametry); proto pokud mi jde o popis toho "co to vlastne dela", snazim se nepouzivat slovo funkce, aby bylo zrejmejsi, ze nemyslim funkci jako kus programu. Apropo - jak vy byste prelozil " The use cases represent functionality of ... " ? I v prekladu tohoto je pouziti slova "funkcionalita" spatne ?
Datum vložení: 7.3.2005 16:41:51
To ale zalezi na kontextu, na sirsi interpretaci textu. 1. Moznost: Protoze Vami zminovany text je v pluralu, mohu dale predpokladat, ze chce rici, ze "Pripady uziti dokladaji funkcnost..." asi aplikace, reseni, proste nejakeho celku. Ta "funkcnost" by tu znamenala, ze je dany celek funkcni, ze je spravne navrzen, jinymi slovy spravnost reseni merenou vysledkem. Takova "funkcnost" muze byt jen jedna pro dany celek, je to "souborna" vlastnost. Poznamka: Brojil jsem proti slovu "funkcnost", je-li pouzivano v jinem smyslu (viz nize). 2. Moznost: Mohlo by se jednat o to, ze pripady uziti ukazuji "funkci" nejake komponenty (soucasi sirsiho celku) ve smyslu toho konkretniho, co poskytuje (to by sohlasilo s puvodnim textem, z nehoz tahle diskuze o terminech vznikla). A nebo bychom zde mohli pouzit i to slovo "funkcionalita" ve smyslu nejakeho zamereni daneho celku (k cemu je urcen), podle toho, o co spise jde. Ne vsak "funkcnost". Zkusme se na to podivat z pohledu budouciho uzivatele, resp. toho, kdo reseni posuzuje na opacne strane. Ten pravdepodobne nebude programatorem, takze by ho ten Vami uvedeny vyznam slova "funkce" nemel mast. Naopak, bude ho spise zajimat "vysledek", zda mu reseni poskytne to, co chtel. A to je bud konkretni funkce, nebo vice funkci; a pokud ty jsou "spravne", pak je dosazena "funkcnost" reseni. Vasek
Datum vložení: 15.3.2005 23:28:12
stava se nam z toho jazykovy koutek :-) vasemu vyvetleni rozumim, ale : nevim, z jake pozice to pisete, ale verte mi, lidi byvaji mateni : 1. zakaznik : ve velkych projektech je bezne, ze se konzultaci na strane zakaznika ucastni i lide z IT oddeleni; pokud to jsou neznalci UML a OO (coz je bezne), tak kdyz jim mam rict "tahle elipsa mi znazornuje funkci", tak jak myslite ze si to preberou ? 2. zhotovitel : i zde neni nic neobvykleho, ze kolegove (na jakychkoliv urovnich rizeni) sklouzavaji k tomu chapat use-podobne jako "programovou" funkci (znaji DFD diagramy, nekdy uz nejake funkce naprogramovali apod.). Je to nekoncici boj, stale vysetlovat, ze v use case nejde o funkcni rozklad. Takze se v UML/OO slovu "funkce" snazim vyhnout jak to jen jde - a zadny jiny duvod mne k tomu opravdu nevede ...
Datum vložení: 12.4.2005 15:24:16
Sériál se mi moc líbil. Přečetl jsem ho na jeden zátah asi za dvě hoďky i s diskuzema. Začínám uvažovat o koupy knihy UML a unifikovaný vývoj aplikaci. Ještě jednou chválím autora a děkuji :-)
Datum vložení: 6.6.2005 15:14:01
Ackoliv jsem tolerantni k vyjadrovacim schopnostem spoluobcanu, nedovolim si nerypnout - pribalte si ke kniham o UML i ucebnici ceskeho pravopisu :-).
Datum vložení: 19.2.2007 10:43:45
Takže s tou tolerancí to zas až tak horké nebude, že?