Case nástroj nebo nástroj na kreslení diagramů

 Proč použít case nástroj (například Sparx Enterprise Architect) oproti nástroji na kreslení diagramů? A jak se to vlastně liší? 

Case nástroj má tzv. repository a jednotlivé diagramy jsou jen různé pohledy na danou repository nebo spíše na její část. Jednotlivé elementy se mohou vyskytovat v různých diagramech a mít mezi sebou vazby. 

Oproti tomu v nástroji na kreslení diagramů repository chybí. Takový nástroj umožňuje naskreslit diagram, ale informace o jednotlivých elementech a jejich propojení se neukládá do repository.

Mějme dva diagramy kde se vyskytuje zákazník. Na jednom diagramu je vztah mezi zákazníkem a objednávkou, na druhém mezi zákazníkem a fakturou. V case nástroji je vše uloženo v databázi (repository case nástroje) a u entity zákazník se dá zjistit, ke kterým entitám má vztah (relation). Pokud analytik provede změnu a přejmenuje zákazníka na klienta, přejmenuje se v obou (ve všech) diagramech.

V nástroji na kreslení diagramů jsou výstupem dva diagramy. Pokud přejmenujete zákazníka na klienta v jednom z nich, v druhém se to vůbec neprojeví. Máme tak zákazníka a klienta, jeden má na diagramu vztah k faktuře, druhý k objednávce. 

Závěr:

• Pokud chcete modelovat informační systém, potřebujete case nástroj.
• Pokud chcete nakreslit diagram, použijte nástroj na kreslení diagramů.
• Modelovat informační systém v nástroji na kreslení diagramů lze, ale bude to obtížné a neefektivní.
• Kreslit diagramy v case nástroji lze, ale case nástroj je jako řešení jen pro kreslení diagramů poměrně drahý.

Na námět analýzy

Dnes se chci zabývat situací, kdy se vývojář analýzou jen inspiruje a výsledek je zcela jiný, než je popsáno ve specifikaci. A mám tu konkrétní případ:

Jedná se o výpočet, kde se je očekáván výsledek za celý úvěrový případ. Úvěrový případ může obsahovat více klientů. Je třeba získat pomocí další služby výsledky za každého klienta zvlášť a pak spočítat výsledek za celý úvěrový případ. Služba pro získání výsledku pro daného klienta může selhat.

V analýze bylo toto:

1. Získáme seznam klientů na úvěrovém případu.
2. Pro každého klienta zapíšeme do databáze stav výpočtu NEW.
3. Pro každého klienta zavoláme službu zjišťující výsledky za daného klienta. Stav výpočtu nastavíme na IN_PROGRESS.
4. Pokud získáme výsledek pro klienta, nastavíme stav výpočtu FINISHED. Pokud bude vrácena chyba, nastavíme stav výpočtu ERROR.
5. Počkáme na získání výsledku výpočtu pro všechny klienty pro daný případ. Pokud je stav výpočtu pro všechny klienty FINISHED, spočítáme výsledek za celý úvěrový případ. Pokud je alespoň jeden stav výpočtu ERROR, vracíme chybu.

Implementováno bylo toto:

1. Získáme seznam klientů na úvěrovém případu.
2. Pro každého klienta zapíšeme do databáze stav výpočtu NEW.
3. Pro každého klienta zavoláme službu zjišťující výsledky za daného klienta. 
4. Pokud získáme výsledek pro klienta, nastavíme stav výpočtu FINISHED. Pokud bude vrácena chyba, nastavíme stav výpočtu ERROR.
5. Počkáme na získání výsledku výpočtu pro všechny klienty pro daný případ. Spočítáme výsledek za celý případ pro všechny klienty se stavem výpočtu FINISHED. Pokud žádný takový klient není, vracíme chybu.

Jak je vidět, stav IN_PROGRESS v implementaci chybí. Takže pokud bude potřeba řešit "zaseklé" případy u kterých z nějakého důvodu nedošlo k vrácení výsledku, bude analytik čekat (dle původní analýzy), že tyto případy budou mít stav výpočtu IN_PROGRESS. A bude čekat marně...

Dalším problém je samotný výpočet, který nebere v úvahu, že může existovat část klientů se stavem výpočtu FINISHED a část se stavem výpočtu ERROR. Dle analýzy by měl výpočet skončit chybou, podle implementace se výsledek spočítá pro všechny klienty se stavem výpočtu FINISHED.  

Ve výsledku tedy není implementace dle analýzy, ale spíše "na motivy" analýzy, kdy se analýzou jen volně inspiruje. A to není stav, který by byl žádoucí.