Asi každý, kdo podnikal má nějaké historické projekty, které jsou v různých stádiích – některé jenom „v šuplíku“, tedy  ve stádiu úvah, třeba zjištění prvních informací o trhu, … Další třeba započal, udělal si rozpočty, koupil doménu v případě webových projektů, ale prostě málo času, nebo nedostatek nadšení pro ně způsobil, že opět nepostoupily dál. No a určitě je i pár takových „otazníků“ – použijme terminus technicus BSC matice – tedy projekty, které započaly, nějak si žijí, není čas/chuť/síla se o ně starat a je to takové „třeba se k tomu někdy vrátím, třeba ne“, možná se to rozjede samo, nebo až dokončím něco důležitějšího (často výnosnějšího).

Má smysl se k těmto projektům vracet? Má cenu je udržovat? Zrovna nedávno jsem udělal menší inventuru – mám pár věcí, u kterých bych určtě věděl, jak je pošťouchnout dopředu, ale prostě čas na to není. Pokud má někdo zkušenosti s projekty, které takto po letech otevřel a začlo se jim dařit, svěřte se.

Můj soukromý názor je, že 90% podobných projektů nikdy nedospěje dál, ale pokud je energie na jejich udržení minimální, nebo nulová, asi nemá smysl je hned rušit. Na druhou stranu by si asi měl každý stanovit hranici – pokud se k projektu nevrátím po dobu řekněme 5 let, asi nemá smysl ho „udržovat ve stádiu hibernace“.

Když už jsme si připravili Use Case diagram (a není ještě úplný), měly bychom si říci, jaký je vlastně rozdíl resp. vztah mezi požadavky, Use Case a Use Case diagramem. Čtenáře poprosím o schovívavost, ale budu používat anglický termín Use Case namísto českého Případy Užití, který je i u nás obecně používaný a nechci být jazykový puritán.

Takže shrňme si to:

Požadavky

Jsou seznam operací, které bude systém provádět, respektive, které budou jednotliví uživatele používat, většinou by mělo být alespoň trochu popsáno o co jde (často jen slovně) a kdo činnost provádí/má k ní oprávnění.

Diagram Use Case

Obsahuje jednotlivé uživatele/role (Actors) a procesy (Use Cases) s naznačením, co kdo má oprávnění provádět. Zde již je vidět jistý náznak objektové hierarchie – mezi uživateli se často používá vztahu generalizace. Což je vlastně zobecnění, tedy “nadtřída” a naopak vztah specializace, což je potomek, tedy podtřída. Mezi procesy pak existují vztahy <<include>> a <<extends>> – píše se na šipku spojující procesy (Use Case-y, jestli to tak mohu skloňovat) a vede směrem k případu, který se v tom prvním používá – tedy například šipka s include vede od rezervovat knihu k procesu najít knihu … když chceme knihu zarezervovat, musíme jí předtím najít – velmi často je proces ke kterému vede vztah <<include>> sám o sobě nepoužitelný. Spojení extends je méně časté a ukazuje rozšíření dané funkce, případu, které nemusí vždy nastat – při přidávání knihy bychom mohli zakládat kategorii (žánr), ale to jenom tehdy, pokud by již daný žánr neexistoval … Určitě sek tomu při zpřeňování ještě dostaneme.

Use Case – Případy užití

A konečně poslední varianta – není to graf, ale seznam jednotlivých Use Case, spolu s popisem jednotlivých kroků a jejich odpovědností – vhodné je pro popis používat jistý pseudokód – ať už anglický, nebo čestký, tedy “když/if, jinak/else, dokud/while …” nejdůležitější je abychom myi zákazník popisu rozumněli.

Nejjednodušší je asi zápis do tabulky

Všimněme si jedné drobnosti – v tuhle fázi často ignorujeme stavy kniha nenalezena, uživatel nenalezen – většinou procházíme typické scénáře. Na výjimky/speciální případy bude snad čas později. Jde spíše o to si popsat s uživatelem standardní běh systému.

Protože jsme si posledně definovali požadavky a kreslili si je do grafu podobně jako Use Case, jediné co nyní potřebujeme je uvědomut si – spolu s uživatelem, kdo jaké dělá/používá. Identifikovali jsme čtyři možné role – host, uživatel, knihovník a administrátor. Tak jim tedy přiřaďmě jednotlivé akce – zde je určitě prostor pro diskuzi se zákazníkem, protože na něm je určit, jestli host smí prohlížet seznam knih, uživatel si sám půjčit knihu, …

Výsledný UML diagram vypadá následovně:

Jestli se ptáte, v čem je diagram vytvořen, je to IDE NetBeans, aktuálně v 6.7. Volba prostředí již asi i přeurčuje, kam budu dále směřovat a jaké možnosti budeme mít.

Po nějaké době (resp. po kurzu) se vracím k projektu knihovna – vzhledem k tomu, že se snažím vpravit se do projektového řízení, rozhodl jsem se „začít znovu“ a vyzkoušt teoretické znalosti a poučky v praxi.

Takže od začátku

No jak začít – asi tím, že nás někdo osloví tím, že potřebuje vyřešit nějaký problém. Řekněme tedy, že přijde někdo (proč ho nenazývat zákazníkem) a chce asi následující:

„Víte, potřebovali bychom evidovat/zlepšit naší knihovnu. Zdá se mi, že systém lístků pro jednotlivé knihy není to nejlepší a strašně špatně se zjišťuje, co máme a případně kdo to zrovna má, případně co všechno má někdo půjčeno. Chtěli bychom, aby se uživatelé mohli zaregistrovat přes síť, ale pak je ještě vlastně někdo musí potvrdit a ověřit, že zadali údaje správně. Měli by mít možnost si prohlídnout naše tituly a případně jestli je půjčený, nebo v knihovně. No a samozřejmě musí jít si knihu půjčit a zase vrátit – to dělá naše knihovnice. Ta se taky stará o seznam knih – edituje je, přidává a případně maže, když se nějaká ztratí, nebo se již opotřebuje. Ta taky posílá upomínky, ale to bych řešil asi až později. A taky si členové – myslím tím registrovaní uživatelé – mohou knihu zablokovat, aby ji knihovnice dala stranou, když se ta kniha vrátí. Občas taky musím někoho zakázat – protože třeba nevrátil knížky a nemůžeme ho normálně sehnat.“

Asi každého napadne sáhnout po nějaké hotové aplikaci, ale to by nebylo o čem psát (možná o výběru, ale to nechci), takže proč se do toho nevrhnout. Nejprve se zamysleme nad požadavky, které z tohoto textu plynou … nakreslil jsem je do následujícího grafu, abych už rovnou směřoval k USE-CSE (případy užití) diagramu … určitě se k němu dostaneme příště, stejně jako k třídám a balíčkům.

Dlouho jsem tak procházel programy a jejich zdrojové kódy a stále mám pocit, že objektové programování se sice prosazuje, ale čistých objektových modelů je v reálném světě stále dost málo. Zkusím tedy napsat jednoduchý prográmek objektově a popsat postup řešení + snažit se co nejvíce používat moderní nástroje …

Takže projekt knihovna (webová aplikace) může začít …