Použití standardů Použití standardů v dokumentu Úvodní studie Určeno pro zákazníky společnosti HARPAGON software s.r.o. Příručka vysvětluje význam jednotlivých standardů UP, UML a BPMN v kontextu dokumentu úvodní studie. Ing. Petr Pokorný HARPAGON Software s.r.o.
Obsah Úvod... 3 Použité nástroje a standardy... 3 Unifikovaný proces UP... 3 Správa požadavků... 3 Přehled a vysvětlení základních elementů v přehledu správy požadavků... 4 Ukázka detailního popisu požadavku pod diagramem... 5 Standard BPMN... 5 Přehled a vysvětlení základních elementů v diagramu notace BPMN... 6 Jazyk UML... 7 Použité diagramy chování... 7 Diagram aktivit... 8 Přehled a vysvětlení základních elementů v aktivity diagramu notace UML... 9 Diagram případů užití (Use Case)... 10 Přehled a vysvětlení základních elementů v diagramu případů užití.... 11 Ukázka neformálního popisu případu užití... 12 Ukázka scénáře případu užití... 12 Výklad pojmů... 13 HARPAGON Software s.r.o.stránka 2 z 13
Úvod Při implementaci informačního systému je důležité, aby dodavatel správně pochopil požadavky a potřeby odběratele. Na základě stanovených požadavků je možno stanovit časový rozsah a objem prací a zjistit požadovanou licenci Helios Orange. Problém vzájemného nepochopení může vést v důsledku ke zbytečnému prodlení prací na projektu, navýšení rozpočtu atp. K zpracování výše uvedených údajů se používají v informačních technologiích nástroje, techniky a postupy, které usnadňují komunikaci Uživatel Implementátor a nastavují komunikační standard. Dále uvedené informace o použitých standardech si nekladou za cíl podat vyčerpávající informace. Cílem je uživatelům vysvětlit jejich použití v dokumentu úvodní studie. Použité nástroje a standardy Problémem jak správně evidovat požadavky a modelovat budoucí informační systém se zabývá celá řada technologií a metodik. Většina standardů se věnuje situacím, kdy se celá funkcionalita vytváří tzv. na zelené louce, tedy úplně od začátku. V případě, že se jedná o implementaci již hotového informačního systému, se používá jen ta část technik, které se zabývají analýzou a správou požadavků. Standardy UML a BPMN spravuje konsorcium OMG (Object management group). Použité nástroje a metodiky pro tvorbu úvodní studie uvádíme dále. Unifikovaný proces UP Obecně jde o doporučený otevřený postup při návrhu a implementaci softwarové aplikace. Definuje: Způsob tvorby aplikace potřebných vykonávaných činností od začátku až dokonce Strukturování potřebných činností prostřednictvím doporučených fází, etap a kroků Používání jednotlivých technik a nástrojů pro jednotlivé činnosti Obsah dokumentů, které jsou v průběhu aplikace metody vytvářeny Unifikovaný proces používá jazyk UML (viz Jazyk UML). Existují i další metodiky vycházející z UP např. RUP komerční pojetí UP. Správa požadavků Jde o jednu z položek standardu UP. Tato pasáž úvodní studie si klade za cíl evidovat a analyzovat požadavky uživatelů na nový IS. Každý požadavek je evidován a identifikován. Požadavky jsou rozčleněny podle oblastí (ekonomika, oběh zboží). Rozlišujeme dva typy požadavků : Systémové požadavky určují, jaké chování bude systém nabízet. Nefunkční požadavky specifikují vlastnosti, nebo omezující podmínky daného systému. HARPAGON Software s.r.o.stránka 3 z 13
custom Doprava Name: Doprava Author: Petr Pokorný Version: 1.0 Created: 6.12.2006 13:08:05 Updated: 16.8.2007 14:56:27 (POZ-049) Sledování nákladů na rozvoz (POZ-055) Sledovat opravy vozidel (POZ-060) Plánovat dopravu dle regionů (POZ-054) Evidence externí dopravy dle Odběratelů (POZ-056) Plánovat povinné prohlídky (POZ-145 ) Evidovat pojistné události Podklady z nabídkového Kola (POZ-057) Evidovat stazky (POZ-058) Sledování povinného školení řidičů (POZ-146 ) Sledovat opotřebení pneumatik dle Km (POZ-059) Vypočítat silniční daň za jednotlivá vozidla Skladba vozového parku Nákladní vozidla: 5 vozidel vlastních 2 externí Osobní vozidla: 17 osobních Manipulační technika Diagram 1 Přehled a vysvětlení základních elementů v přehledu správy požadavků Element Popis Požadavek identifikace požadavku včetně jeho popisu. Detail popisu požadavku je umístěn pod diagramem požadavků. K požadavku se připojuje informace: Status (navrženo, schváleno, ) každý status má svou barvu (navrženo = žlutá, schváleno =zelená) Obtížnost (Malá,Střední,Velká). Toto vyjádření se týká obtížnosti splnit tento požadavek. Agregace je typ spojení požadavku, který znázorňuje situaci, kdy požadavek dole (POZ-146) je součástí požadavku nahoře (POZ-056). Jinými slovy : Požadavek na Plánované povinné prohlídky v sobě obsahuje také požadavek Sledování opotřebení pneumatik dle ujetých Km. Požadavek Agregace HARPAGON Software s.r.o.stránka 4 z 13
Ukázka detailního popisu požadavku pod diagramem (POZ-056) - Plánovat povinné prohlídky Status: Navrženo Obtížnost: Medium Popis: - STK - Emise - Pneumatiky (POZ-146) - Sledovat opotřebení pneumatik dle Km Status: Navrženo Obtížnost: Medium Popis: V rámci servisních prohlídek sledovat opotřebení pneumatik dle ujatých Km. Standard BPMN Používáme ho pro modelování firemních procesů (diagram BPD). Jeden z prvních úkonů při analýze společnosti uživatele je rozpoznání hlavních procesů. Proces chápeme jako pracovní postup, nebo postupné dílčí kroky k dosažení nějakého cíle. Dělíme je na několik úrovní podle obecnosti. V úvodní studii je uvidíte v přílohách, které se věnují jednotlivým modulům (Ekonomika, Oběh zboží, Mzdy). Neklademe si za cíl uvádět vyčerpávající seznam procesů, ale pouze takové, které se bezprostředně dotýkají použití Helios Orange a jsou pro chod aplikace důležité. Pro modelování procesů se používá notace BPMN (Business Process Modeling Notation) a diagram BPD (Bussines proces diagram). BPMN je de facto již několik let standard notace pro procesní modelování. Viz ukázka BPD Diagram 2. HARPAGON Software s.r.o.stránka 5 z 13
BPMN Plánování rozv ozu Name: Package: Version: Author: Plánování rozvozu Doprava 1.0 Petr Pokorný Zboží k dodání Seskupit objedávky podle regionů Zjištění hmotnosti zboží. Naplánování trasy pro každý region Přiřazení vozidla k trase «Pool» Vedoucí odbytu Objednávky k datu uzávěrky Vytvoření jízdních příkazů Jízdní příkaz Rozvoz je naplánován Diagram 2 Přehled a vysvětlení základních elementů v diagramu notace BPMN Element Popis Start startovací událost. V diagramu by měl tento element být popsán (není povinné) např. Faktury k proplacení, nebo Zboží k přijetí Události Činnosti Toky Konec popisuje situaci po skončení procesu. V diagramu by měl být tento element popsán např. Faktura zaplacena nebo Zboží přijato. Proces znázorňuje proces vyšší úrovně. Tento proces je dále rozpracován detailně v samostatném diagramu (BMPN nebo Aktivity diagramu). Jde většinou o popis procesů 1. Nebo 2. Úrovně. Název procesu je popsán v těle elementu (místo slova proces). Aktivita představuje činnost (úkon), která se zpravidla dále nerozpadá (nerozděluje na další menší aktivity). Měla by představovat jednoduchý úkon např. Tisk faktury nebo Zadání údajů do formuláře. Název aktivity je umístěn v těle elementu (místo slova Aktivita). Sekvenční tok vyjadřuje následnost procesních prvků ve směru šipky. Vstup/výstup popisuje směr vstupu a výstupu artefaktu do /z aktivity viz dále. HARPAGON Software s.r.o.stránka 6 z 13
Element Artefakt Popis Artefakt používají se pro zobrazení produktů informačního systému. Většinou to jsou vstupní a výstupní dokumenty. Obrázek znázorňuje dokument Faktura, která vstupuje/vystupuje do nějaké aktivity (procesu). Bazény Bazén uvozuje zodpovědnost příslušné role / uživatele. Vše co je nakresleno uvnitř je aktivitou příslušné role (uživatele). Orientace bazénu může být vertikální a horizontální. Místo slova Uživatel je zapsána konkrétní role. Brána XOR je místo větvení, možná je pouze jedna z cest z tohoto uzlu. Brána OR je místo větvení z kterého vede alespoň jedna cesta- může jich být i více současně. Brány Brána AND je místo současného (paralelního) větvení /slučování. Brána Komplex používají se v těchto případech: Podmínky běhu nelze vyjádřit pomocí výše uvedených větvení. Sloučení více než jednoho větvení Jazyk UML UML, Unified Modeling Language je v softwarovém inženýrství grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. V úvodní studii používáme verzi UML 2.0. UML podporuje objektově orientovaný přístup (není podmínkou) k analýze, návrhu a popisu programových systémů. UML je podpůrným nástrojem pro komunikaci mezi pracovníky IT a pro zaznamenání myšlenek a návrhů. Do diagramů se kreslí pouze věci podstatné pro grafické vyjádření návrhu. Jazyk UML obsahuje celkem 14 diagramů (v tomto dokumentu nejsou všechny uvedeny), které se dělí na diagramy chování a strukturální diagramy. Pro naše potřeby v úvodní studii používáme pouze dále uvedené diagramy chování. Použité diagramy chování diagram aktivit (aktivity diagram) je velmi podobný diagramu notace BPMN diagram případů užití (use case diagram) stavový diagram (state machine diagram) HARPAGON Software s.r.o.stránka 7 z 13
Diagram aktivit Je velmi podobný diagramu notace PBMN.V podstatě je jeho předchůdcem. Zobrazuje sekvenci aktivit, které podporují jak postupné (sekvenční) tak souběžné (paralelní) chování. Diagram takém vyjadřuje zodpovědnost jednotlivých rolí aktivit vyjádřenou tzv. plaveckou dráhou (swimlane). Tento diagram je obdobou vývojových diagramů. Tento diagram může být přiřazen k jakémukoliv elementu UML (např. Use Case) a tak popsat jeho chování. act LZ-0100 Přijetí zaměstnance Personalista:Personalista Mzdov á účetní:mzdov á účetní Vedoucí příslušného střediska Jednatel společnosti:jednatel Uchazeč Pohovor personalisty s uchazečem Pohovor vedoucího příslušného střediska s uchazečem Vyplnění osobního dotazníku Zaev idování zaměstnance v Helios Orange Vytvoření a tisk smlouvy Schválení smlouvy jednatelem Schválení smlouvy vedoucím příslušného střediska Zaevidování v docházce Zaevidovaný nový zaměstnanec Name: LZ-0100 Přijetí zaměstnance Author: Ing. Jaromír Zajíček Version: 1.0 Created: 13.10.2006 13:43:19 Updated: 23.8.2007 10:40:47 Diagram 3 HARPAGON Software s.r.o.stránka 8 z 13
Přehled a vysvětlení základních elementů v aktivity diagramu notace UML Element Popis Start startovací stav. V diagramu by měl tento element být popsán (není povinné) např. Faktury k proplacení, nebo Zboží k přijetí Stavy Akce Přechody Konec popisuje stav po skončení procesu. V diagramu by měl být tento element popsán např. Faktura zaplacena nebo Zboží přijato. Akce (Aktivity) nedělitelné, zjednodušené stavy, které probíhají rychle a jsou nepřerušitelné. Měly by představovat jednoduchý úkon např. Tisk faktury nebo Odeslání příkazu do banky. Název aktivity je umístěn v těle elementu. Přechod mezi jednotlivými stavy dochází k přechodům ve směru šipky. Plavecké dráhy Plavecká dráha uvozuje zodpovědnost příslušné role / uživatele. Vše co je nakresleno uvnitř je aktivitou příslušné role (uživatele). Orientace dráhy může být vertikální a horizontální. Role je zapsána v záhlaví dráhy. Rozvětvení dle podmínky je místo větvení, možná je pouze jedna z cest z tohoto uzlu. U každé cesty je Rozvětvení Sjednocení po podmínce je místo sjednocení po rozvětvení. Rozcestí je místo větvení které modeluje paralelní chování. Sjednocení je místo spojení (ukončení) paralelního (souběžného) chování. HARPAGON Software s.r.o.stránka 9 z 13
Diagram případů užití (Use Case) Diagram znázorňuje komunikaci aktéra (uživatele) s navrhovaným systémem. Znázorňuje, jaké úlohy (případu užití) bude aktér používat. Kromě grafického znázornění je potřeba upřesnit funkčnost každého případu užití slovním popisem. Jde o dohodu budoucího uživatele a dodavatele informačního systému. uc Skladov á účetní Name: Package: Version: Author: Skladová účetní Skladová účetní 1.0 Petr Pokorný Helios Orange (US-079) «HeliosOrange» Příjem na sklad «include» (US-081) «HeliosOrange» Účtov ání skladov ých dokladů (US-080) «HeliosOrange» Výdej ze skladu «include» «include» Skladov á účetní (from Ekonomika) (US-082) «HeliosOrange» Ev idence dodatečných nákladů «include» (US-083) «HeliosOrange» Párov ání faktur s příjemkami Diagram 4 HARPAGON Software s.r.o.stránka 10 z 13
Přehled a vysvětlení základních elementů v diagramu případů užití. Element Popis Aktér rozumíme tím roli, ve které vystupuje uživatel v rámci své komunikace se systémem. Všechny akce v systému jsou vyvolány aktéry. Aktéři Ohraničení Případ Užití Aktér - systém aktérem může být také externí systém s kterým uvažovaný systém spolupracuje. Obrázek znázorňuje obdélníkovou notaci aktéra, který se používá pro neživé aktéry (např. homebankingový systém banky, webová aplikace atp.) Ohraničení vyjadřuje ohraničení modelovaného systému. Všechny případy užití které jsou uvnitř tohoto elementu, jsou provozovány vyjadřovaným systémem. Případ užití - popisuje požadovanou činnost kterou systém nabízí. Identifikován je údajem v závorce. Informace HeliosOrange a oranžové zbarvení znamená, že požadovaná funkcionalita je standardní součástí IS Helios Orange. Detailní popis případu užití je doplněn textem: stručným popisem viz dále scénářem viz dále aktivity diagramem Případ užití- význam viz předešlý element. Požadovaná funkcionalita je ovšem předmětem dovývoje. Funkcionalita není standardní součástí IS Helios Orange. Použití vyjadřuje spojení aktéra a případu užití. Jinými slovy: Skladník používá.. Propojení Vložení - jeden případ použití obsahuje jiný případ užití (povinně). Rozšíření jeden případ užití je rozšířen o druhý (vpravo). Jinými slovy: Případ užití (vlevo) může být (ale není to nutně podmínkou) rozšířen o funkcionalitu, kterou vyjadřuje druhý případ užití (vpravo). HARPAGON Software s.r.o.stránka 11 z 13
Element Popis Zobecnění (generalizace) aktér (dole)dědí vlastnosti jiného aktéra (nahoře). Jinými slovy: Vedoucí skladu je taky skladník a povinnosti funkce vedoucího má navíc. Ukázka neformálního popisu případu užití (US-095) - Zobraz podklady pro Intrastat Popis: Zobrazí za určené období podklady pro Intrastat vstupní a výstupní. Vstupní se bude sledovat na základě příjemek, výstupní dle Výdejek pro prodej či vydaných faktur. Ukázka scénáře případu užití Název US-076 - Kontrola platební disciplíny Status Navrženo Verze: 1.0 Fáze: 1.0 Autor Petr Pokorný Vytvořeno 29.7.2007 Modifikováno: 30.7.2007 Poznámky Přehled o stavu zaplacených a nezaplacených pohledávek a závazků. Scénář: Hlavní Pohledávky 1. Uživatel vybere typ saldokontní skupiny (dodavatelé/odběratelé) 2. Zvolí typ pohledu (Nezaplacené/Zaplacené), Před/Po splatnosti. 3. HeO zobrazí požadované saldokontní případy. Podmínky: Vstupní Zaúčtováno Všechny dostupné doklady (faktury dodavatelské/odběratelské, vzájemné zápočty a ostatní případy spojené se saldokontními účty - 311,321) jsou zaúčtovány. Výstupní Zobrazení Dle nastaveného typu jsou požadované položky saldokontních skupin zobrazeny. HARPAGON Software s.r.o.stránka 12 z 13
Výklad pojmů Termín Popis Workflow pojem označující návaznost aktivit a sub procesů v rámci firemního procesu (tzv. chování firemního procesu) Activita elementární firemní proces Sub-process firemní proces, který je dále dekomponován (vytvářející hierarchie) tj. skupina dalších sub-procesů a aktivit IS Informační systém Aktér rozumíme tím roli, ve které vystupuje uživatel v rámci své komunikace se systémem. Všechny akce v systému jsou vyvolány aktéry. Generalizace Zobecnění HARPAGON Software s.r.o.stránka 13 z 13