/ janturon.cz / Od kodéra k analytikovi / Logiky a modely řešení

Logiky a modely řešení

Vícevýznamové slovo logika v oblasti návrhu aplikací znamená úroveň pohledu: čím nižší úroveň, tím větší množství detailů. Nejnižší úroveň je tedy samotná implementace, tedy kód. Pokud budeme programovat pouze na této úrovni, při každém kroku hrozí, že ztratíme ze zřetele původní záměr a nepřiměřeně mnoho času budeme věnovat řešení nepodstatného. Logika je návod, podle kterého lze rozhodnout, kterým problémům se vyplatí věnovat úsilí a které obejít.

Ignorování logiky vede k Murphyho zákonu 80/20: 80% vývoje trvá 20% času, 20% vývoje trvá 80% času. To je antivzor: zásadně postupujeme od nejvyšší logiky k nejnižší, nikdy ne naopak!

1. Obchodní (konceptuální) logika

Popisuje smysl aplikace, tedy účel, kterému slouží. Například rezervační systém zákroků u lékaře. obchodní model Tomuto diagramu se říká konceptuální nebo doménový nebo analytický model. Toto jsou obchodní třídy, a vztahy mezi nimi obchodní logika. Veškeré vývojové úsilí musí sloužit vyřešení těchto problémů. Všechny ostatní třídy a vztahy slouží pouze k realizaci tohoto modelu.

Za správnost tohoto modelu plně ručí zadavatel, který ho sestaví ve spolupráci s vedoucím projektu, který na vývoj alokuje realizátory. Pokud je obchodní logika složitá, asistuje těmto rozhovorům i analytik.

Všichni realizátoři musí porozumět doménové problematice, zde například významu slova anamnéza, specifické pro klinické obory.

2. Prezentační logika

Po formulaci obchodní logiky vytvoříme logiku prezentační, tedy způsob ovládání. Protože je to rezervační systém, nejdůležitější část bude formulář pro obvodního lékaře, který se bude ovládat následující posloupností akcí:

Formulář obvodního lékaře

  1. Zadání pacienta a zobrazení jeho anamnézy.
  2. Zadání zákroku, který je zapotřebí.
  3. Výběr specialisty, který tento zákrok provádí.
  4. Objednání pacienta do časového rozvrhu specialisty.

Druhou, jednodušší částí bude formulář pro specialistu.

Formulář specialisty

  1. Zanesení provedeného zákroku do anamnézy pacienta.

Součástí prezentačního modelu bývá také drátěný model (wireframe) ilustrující velikost a rozložení aplikačních prvků.

Tyto požadavky také diktuje zadavatel, tentokrát ve spolupráci s analytikem. Analytik a vedoucí projektu bývá často jedna a táž osoba.

3. Aplikační logika

Zatahuje do řešení tzv. Control třídy (často zapsány pouze rozhraním), které slouží k realizaci dosud vágně definovaných pojmů, které jsou produkty principu rozděl a panuj. Tuto činnost provádí analytik. Zde například bude jednou z control tříd (tedy podproblémem) časový rozvrh specialisty. Tato třída bude muset vyřešit (viz předchozí úrovně logik) následující problémy:

Model obohacený o control třídy se nazývá návrhový nebo designový: obsahuje více implementačních detailů než konceptový model (zde důležité agregace a typy).

Nesnažíme se do modelu vložit všechny vztahy (zde například chybí agragace zákroku do klientů): smyslem modelu je usnadnit pochopení, ne úplnost. Bez přehlednosti je model samoúčelný a zbytečný.

návrhový model

4. Implementační logika

Abychom mohli úkoly aplikační logiky realizovat, budeme potřebovat ještě pomocné třídy (zde například třídu pro práci se vzdálenou databází). Implementační logika znamená implementaci zadaných rozhraní a je zcela v rukou kodéra, který však nesmí hýbat s aplikační logikou (definicí rozhraní). Implementační model se už většinou nesestavuje, leda jako součást dokumentace u složitých aplikací, v jejichž vývoji pokračuje jiný kodér, než který jej započal. Z důvodu rozsáhlosti se obvykle sestavují jen dílčí modely těch nejsložitějších částí systému.