Unified Modeling Language( Jednotný modelovací jazyk)

- grafické zobrazenie na vyjadrenie analytických návrhov a modelov

- umožňuje zdieľanie výsledkov s inými vývojármi - zahrňuje všetky fázy životného cyklu softvéru - je jednotný pre všetky jazyky - je štandardom

© Peter Golian

1. Špecifikácia požiadaviek2. Analýza3. Návrh4. Konštrukcia5. Implementácia

© Peter Golian

Berte do úvahy podmienky obmedzujúce fungovanie systému (požiadavky zákazníka, existujúci systém užívateľov, prostredie zákazníka, HW, SW, dodržanie štandardov)

Požiadavky častokrát udáva užívateľ(do problematiky je potrebné zapojiť všetkých užívateľov budúceho systému)

Hlavné zásady popisu požiadaviek

- stručnosť, presnosť (holé vety, výstižné)

- požiadavky musia byť úplné (popis by mal obsahovať hranice)

(Ak pri nejakej ďalšej fáze narazíte na nedostatky je potrebná zmena špecifikácie požiadaviek. Premietnite ju spetne a aj do ďalších fáz. Musíte zaznamenať ako pôvodný stav, tak aj po zmene.Ak pracujete v tíme musíte všetkých informovať a zmeny archivovať

© Peter Golian

Hlavný slovník špecifikácie

- vyžaduje sa evidovať <čo> - systém bude podporovať pridánie, editáciu, mazanie <čoho> - vyžaduje sa ochrana proti nepovolanému uživateľovi... - systém bude čítať dáta <čoho odkiaľ> a bude ich zpracovávať za

účelom <čoho> - systém pošle <komu> správu o <čom> - dáta prenosu budú nečitatelné pro iného uživateľa - atď.

© Peter Golian

Čo je chybou pri tvorbe špecifikácie požiadaviek ?

nepredbiehajte požiadavku riešením (je potrebné písať požiadavku a nie riešenie ) nevynechajte žiadnu požiadavku pri každej požiadavke vymenujte stručne čo požaduje nepoužívajte programátorský žargón a výrazy

CASE nástroje(Computer Aided Software Engineering)

-nástroje pre podporu a analýzu návrhu

© Peter Golian

USE CASE (prípad použitia)Aktér (užívateľ) = užívatelská rola (nemusí byť osoba môže to byť aj externý systém napr. Denná uzávierka)- označuje sa ako postavička

Funkcia sa označuje ako elipsa Popis1. Názov (napr. prijať spotrebič do opravy)2. Jednoduché číslovanie krokov3. Stručné vety4. Rozlišovať jeden a viac prípadov

Pri popise nezabudnúť na:- vyjadrovanie sa v reči aktéra - jednotne vrámci tímu - jednotne v rámci prípadov riešenia

© Peter Golian

AGREGÁCIA- jedna trieda je súčasťou druhej

© Peter Golian

ASOCIÁCIA-obojstranné zdieľanie tried

© Peter Golian

GENERALIZÁCIA- dedenie (parent,child)

© Peter Golian

ABSTRAKTNÁ TRIEDA

© Peter Golian

POLYMORFIZMUS- tá istá trieda počítaná inak

© Peter Golian

Interakčné diagramy- sekvenčné - objektovej spolupráce

© Peter Golian

Sekvenčný diagram

© Peter Golian

Diagram objektovej spolupráce

© Peter Golian

Dátove modelovanie-logický dátový model entita= jednotka (zoskupenie dát ktoré k sebe logicky patria napr. faktúra ) atribút = položka entity (napr. zákazník položka meno, adresa ... ) väzba= vzťah medzi entitami - 1 1 - často sa zlučuje - 1 N - jeden pracovník viac úloh - M N - musí sa previesť na 1 N (napr.pacient liek ,kardinalita väzby ) ( použitie nie je univerzálne jedna organizácia sa odlišuje od drujej )

© Peter Golian

-logický dátový model - kľúče (jeden atribút má významnejšiu úlohu ako druhý ) - primárny kľúč (vrámci entity má jednoznačný výskyt napr. ID pracovníka ) - cudzí kľúč ( v inej entite ako primárny kľúč master detail -sú dôležité pri návrhu databázy (rýchlosť databázy)

Identifikácia entít pacient lekár chorobopis liek lekársky predpis

Identifikácia kľúčov číslo lekára číslo chorobopisu

Určovanie vzťahov - v akom vzťahu sú k sebe jednotlivé entity

- matica entít

Vytvorenie dátového modelu

Odstránenie duplicít

© Peter Golian

Fyzický dátový model databáza = organizovaná štruktúra dát usporiadaná do tabuliek tabuľka = dátová štruktúra organizovaná do riadkov a stĺpcov riadok = nesie danú informáciu o jednom výskyte entity uloženej v databáze ) stĺpec kvázi atribút Normalizácia dát modelu- identifikácia vzájomného vzťahu dát- združenie dát do optimálnych skupín- umožnenie dodatočného rozšírenia- Jednoduchá údržba dát

norma SQL –92 definuje štandard dátových typov( niekedy sa nedeje normalizácia kvôli výkonu )

© Peter Golian

Stavové diagramy

- mapujú všetky možné stavy - pre celý životný cyklus - vychádza z toho, že objekty sa menia - stavy na základe prijatých udalostí

© Peter Golian

© Peter Golian

- modelovanie činností- zobrazenie jednotlivých krokov procesu

Akcie - sú nedelitelné, nie je možné ich prerušiť, sú okamžité, jeden vstupný a

výstupný bod

Prechody- medzi stavmi dochádza k prechodom Hodnotenie prechodov -logické podmienky (súčasne splnená iba jedna z nich ) Rozvetvenie- rozcestie, spojenie Plavecké dráhy- zodpovednosť (umožňuje paralelné procesy)

Diagramy aktivít

© Peter Golian

Vstup dát

Generovanie informácie

Tlač informácie

KriteriaZostavy

Zostava

Manažér projektu

Tlačiareň

Systém riadenia projektu

[viac zostáv]

[žiadna ďalšia zostava]

Diagramy aktivít

© Peter Golian

Nástroje UML ako programy Visual Paradigm

a Rational ROSE dokážu vygenerovať z diagramov UML zdrojový kód, do väčšiny

programovacích jazykovtakže stačí dopísať len funkciu (napr. daň=0,2*základ_dane)

© Peter Golian

Celkové náklady na implementáciu softvéru obvykle zahŕňajú viac ako len náklady na samotný softvér, ktoré sú určené počtom zakupovaných používateľských licencií. Niektoré náklady sú len jednorazové a spájajú sa naprklad s migráciou dát z existujúcich aplikácií do nového systému. Iné (napríklad náklady na podporu) môžu byť trvalé. V závislosti od komplexnosti riešenia môžu vzniknúť aj náklady vzťahujúce sa na prispôsobenie softvérua nastavenie riešenia na existujúce aplikácie. Musíte brať do úvahy všetky výdavky na začiatočné školenie zamestnancov, ako aj ďalších nových pracovníkov. No pri sčítaní všetkých nákladov by ste mali brať do úvahy aj ich krátkodobú a dlhodobú návratnosť v rámci implementácie softvéru na riadenie podniku.

© Peter Golian