Dev:UseCases/Example
Navigation: Dev:UseCases.
Sem pride strucnejsi a ludskejsi popis toho, co je napisane viac podrobne nizsie. Prakticky nieco ako literarny vycuc zvysku kapitoly. Na zaciatok je asik rozumnejsie tento vycuc pisat az po tom, co mate hotove to nizsie. Aspon sa vam to nebude pliest.
Ide hlavne o to, aby sa jednoducho v malych odstavcoch zhrunulo, na co sa citatel moze v tejto kapitole tesit. Zaroven by to vsak mal byt aj postacujuci popis pre nejakeho toho managera, ktoreho uz obvykle konkretne technicke detaily moc nezaujimaju, ktory iba chce vediet, o com to asi tak je.
Contents |
Hlavny
Use case zacne zbeznym popisom ktory vysvetli, co dana akcia ma znamenat. Nie vzdy musi byt totiz jasne z nazvu, co to robi a preco to robi. I ked vam to jasne je, citatel na tom obvykle nie je rovnako. Staci dvoma vetami, prikladom alebo opisom.
Snazte sa vyhnut pisaniu toho, odkial uzivatel tento use case zacal. Hlasky typu uzivatel sa sem dostane z hlavnej stranky nemusia byt casom pravda. Moze sa stat, ze sa sem dostane aj z nastaveni. Nikdy nevies.
Co sa zobrazi na uvod akcie
Vacsina use caseov nieco zobrazi, nie? Detail fotky zobrazi fotku a jej hodnotenie, uvodna stranka zobrazi kopu kdejakych okienok, editacny formular uzivatelovi zobrazi aktualne hodnoty. Malokedy sa stava, ze sa nezobrazi nic, napr. pri odhlaseni sa na uvod nezobrazi nic, i ked aj to je mozne. Niektore use case su vlastne iba o tomto, aby sa im nieco zobrazilo, napr. uvodna stranka, detail albumu.
Nezabudnite jasne napisat, co sa zobrazi a pripadne i ako sa to zobrazi. Napiste, z akych objektov sa vytiahnu ktore atributy a ako sa z nich spocitaju zobrazene hodnoty. Na tento ucel tu mame tieto templates:
- Linku na triedu urobite pouzitim {{link class|classes chapter|class name}}.
- Linku na atribut v triede pouzitim {{link attr|classes chapter|class name|attribute name}}.
- Linku na use case urobite pouzitim {{link usecase|usecases chapter|usecase section}}.
Napriklad: Uzivatelovi sa zobrazia jeho detaily, tj. vsetky atributy z jeho User.Profile. K tomu sa zobrazi cas, ako dlho bol online, ktory sa spocita ako rozdiel atributov User.last_access a User.last_login.
Jak to bude prebiehat
Dalej popiseme postup prace daneho use case. Takze uzivatel zvoli, zada ci vyplni. Uzivatel urobi tamto, pripadne na nieco pocka.. System potom overi ci skontroluje. Je potrebne detailne popisat vsetky mozne netrivialne scenare a tie trivialne dat aspon do poznamok.
Je dobre drzat rozumnu terminologiu:
- Uzivatel si zvoli alebo vyberie - uzivatel zvoli/vyberie z nejakej mnoziny volieb - napr. combo box, radio boxy, klikatelne zoznamy.
- Uzivatel zada alebo vyplni - uzivatel nieco napise, mnozina volieb je prilis velka - napr. edit box.
- Hlasky typu uzivatel napise alebo klikne urcite nie su dobre.
Je potrebne napisat plny zoznam toho, co vlastne uzivatel zada, alebo aspon to nejak okaslat. Napisat, ze uzivatel vyplni formular nestaci, pokial ste predtym nepopisali, ako ten formular bude presne vypadat.
Tiez je potrebne popisat, ako system skontroluje. Urcite nestaci napisat, ze sa skontroluje, ci uzivatel ma nejake heslo. Je potrebne napisat, ze sa skontroluje, ci existuju nejake hesla pre tohoto uzivatela (vid popis triedy Password). Inymi slovami, jasny odkaz na triedu, kde sa daju potrebne informacie najst. Pouzitim toho template je linkovanie predsa hracka.
Jak to skonci
Na konci sa vacsinou uzivatelovi tiez nieco zobrazi. Napriklad chybove hlasenie alebo hlasenie o uspesnosti operacie, trebars i s detailom prave vlozenej fotky.
Pokial je vysledkom operacie zobrazenie nejakeho ineho use case, tak sa nebojte to napisat. Dobrym prikladom je prihlasenie, kde sa miesto hlasky boli ste prihlaseny rovno zobrazi uvodna stranka, ktora je uz inym use caseom. Nezabudnite sprievodny text doplnit linkou..
Poznamky
Potom este pridu nejake tie poznamky, ktore su relevantne, ale zas nie tak podstatne. Ako napriklad, ze ked uzivatel predtym nieco zvolil, uz to nemusi zvolit znovu a podobne. Poznamky su napr. aj na to, aby bolo jasne, ze ste sa nad tym zamysleli, ze ste na to nezabudli. Pripadne na to, aby ste mozno zrejmy fakt spomenuli aj pre tych, ktorym to tak zrejme nepride.
Poznamky nemusia byt vsetky na konci textu, kludne ich narvite aj do stredu textu. Nejak ich vhodne zakomponujte k tomu, k comu sa vztahuju.
Implementacne poznamky
Nakoniec use case sa este mozu vyskytnut nejake tie implementacne poznamky. Tieto mozu napriklad pripominat fakt, ze emailova adresa by sa mala skontrolovat, ci je v tvare [a-zA-Z0-9\._-]+@[a-zA-Z0-9\._-]+\.[a-zA-Z0-9\._-]+.. (no.. podobne regularne zakernosti tam urcite nepiste, to bol len explanativny priklad.. ;))
Implementacne poznamky nemusia byt vsetky na konci textu, kludne ich narvite aj do stredu textu. Nejak ich vhodne zakomponujte k tomu, k comu sa vztahuju.
Vzor
- Ako vzor skusim popisat use case prihlasenie. Pozor! Tento popis nemusi zodpovedat realnym moznostiam a nemusi obsahovat vsetko co chceme implementovat. Je to iba priklad, nie sucast analyzy. Skutocny proces prihlasenia treba zanalyzovat a popisat znovu. Analyza nesmie vychadzat z tohto prikladu.
Prihlasenie sluzi na to, aby system identifikoval navstevnika ako konkretneho registrovaneho uzivatela a umoznil mu pristup k jeho osobnym udajom, fotkam a pod.
Uzivatel sa prihlasuje zadanim svojho loginu a hesla.
Formular
System uzivatelovi zobrazi prihlasovaci formular, do ktoreho uzivatel zada svoj login a heslo. Moze tiez zvolit, aby sa jeho prihlasenie na danom pocitaci pamatalo aj po jeho vypnuti.
Po zadani prihlasovacich udajov system skontroluje:
- Ci taky uzivatel existuje, tj. ci existuje uzivatel so zadanym loginom (atribut User.login).
- Ci k takemu uzivatelovi existuje zadane heslo (atribut Password.passwd, vid triedu Password).
- Ci ten uzivatel nie je v systeme zakazany alebo nepotvrdeny (atribut User.state).
Uspesne prihlasenie
Pokial uzivatel existuje, zadal spravne heslo a nie je v systeme zakazany/nepovoleny, prihlasenie je uspesne. Upravi sa cas jeho posledneho prihlasenia (atribut User.last_login triedy User) na aktualny cas a vygeneruje sa mu nova session (atribut User.session). Pokial heslo, ktore uzivatel zadal bolo jednorazove (atribut Password.once triedy Password), toto heslo sa zmaze.
Po uspesnom prihlaseni sa uzivatelovi automaticky zobrazi uvodna stranka uzivatela, ktora bude opisana v kapitole Uvodna stranka uzivatela.
Neuspesne prihlasenie
- Pokial prihlasenie nebolo uspesne z dovodu loginu/hesla, zobrazi sa hlasenie o tom, ze dana kombinacia loginu a hesla neexistuje a opat sa zobrazi prazdny prihlasovaci formular.
- Pokial prihlasenie nebolo uspesne z dovodu, ze uzivatel je v systeme zakazany, zobrazi sa hlasenie o tom, ze uzivatel bol zakazany a pokial je vyplneny dovod jeho zakazania v atribute User.reason triedy User, zobrazi sa aj ten.
- Pokial prihlasenie nebolo uspesne z dovodu, ze uzivatel v systeme este nie je povoleny, zobrazi sa hlasenie o tom, ze uzivatel nebol este povoleny a ze musi pockat na potvrdenie spravcu.
Poznamka: Kontrola loginu a hesla je prioritnejsia nez kontrola zakazania/nepotvrdenia uzivatela. To znamena, ze pokial uzivatel nezada spravnu kombinaciu loginu a hesla, o svojom pripadnom zakazani sa nic nedozvie.
Poznamky
Implementacna poznamka: Pokial uzivatel zadal, aby sa jeho prihlasenie na danom pocitaci pamatalo aj po vypnuti toho pocitaca, je potrebne dohliadnut na to, aby sa tak stalo. Napr. nastavit casovo obmedzene cookies, ktore preziju aj vypnutie browseru, pokial sa na prihlasovanie budu pouzivat cookies.