SCÉNÁŘ FÁZE ZAHÁJENÍ NAD DOMÉNOU SSZ V ČR (20. Dubna 2012)

Transkript

1 SCÉNÁŘ FÁZE ZAHÁJENÍ NAD DOMÉNOU SSZ V ČR (20. Dubna 2012) Úvod problémová doména Co je problémová doména? Pojem je sice informatický, ale srozumitelný rovněž managementu. Informatici nemohou do svých úvah o komputerizaci zařadit celý reálný svět, tj. realitu, která nás obklopuje. To prostě nejde vzhledem k její nekonečnosti. Proto je zaveden pojem problémové domény jako konečného výseku existující reality. Problémová doména je reálně existující fyzický systém. A je-li problémové doména příliš rozsáhlá, pak ji stejně musíme členit na dílčí podsystémy. Menší části problémové domény snadněji analyzujeme a modelujeme, což je nezbytné pro jejich komputerizaci. V znalostech o problémové doméně dominuje znalost procesů a v nich zpracovávaných dat. A zde se informatici potýkají s potřebnou úrovní znalostí, což mnohé softwarové firmy řeší náborem manažerů do svých řad. Praxe dosud jednoznačně ukázala, že komputerizovat doménu bez její dokonalé znalosti je relevantní riziko, relevantní hendikep pro výsledný cílový software. Vývojový proces software bychom mohli rozdělit do následujících částí: 1. Studium zadané problémové domény. Na problémovou doménu se díváme ze všech nám již známých pohledů (systémový, datový a aktivitní, organizační a pohled ze strany řízení). Zdroje pro toto studium získáme zejména od managementu problémové domény. Pokud problémovou doménu dostatečně neznáme, nepouštíme se do žádného informačního modelování. 2. Informační modelování. Pomocí metod, technik a nástrojů informačně modelujeme poznatky získané uplatněním zmíněných pohledů. K tomu nám pomůže zejména vývojová metodika jednoho z vývojových paradigmat (strukturované paradigma, objektové paradigma). Modelování provádíme souběžně jak pro problémovou doménu, tak rovněž pro právě vznikající softwarovou doménu. Tyto dvě domény sice spolu těsně souvisí, ale musíme je rovněž umět odlišovat. Pro obě dvě domény musíme získat konceptuální modely, zejména procesů, dat a architektury software. Které to jsou a jaké mají vlastnosti, nám říkají vývojové metodiky. V modelování se pomalu do pozadí dostává problémová doména a prudce do popředí se dere softwarová doména. 3. Testování získaných výsledků. Tato aktivita není spojitá, promítá se do všech ostatních částí. Testujeme vše, k čemu jsme v modelování dospěli, bez ohledu jde-li o problémovou nebo softwarovou doménu. Testy se připravují dopředu a výsledky jejich provedení se dokumentují. 4. Příprava návrhu software. Konceptuální modely se musí převést do návrhové podoby vhodné pro skutečné programování. Teď se pracuje zejména v softwarové doméně. Realizace software má otevřenou cestu. 5. Nasazení software. Poznání prostředí zákazníka (tedy asi jeho informační infrastruktury), v kterém bude cílový software nasazen, je další významná aktivita v oblasti softwarové domény. Po vlastním nasazení se software testuje a zabezpečuje se jeho bezporuchový provoz. 1

2 K čemu jsme přišli? Pro tvorbu software musíme založit softwarový projekt (se vším co říká tzv. projektové řízení), do projektu zabudovat fáze vybrané vývojové metodiky. Tedy metodiky orientované na vývoj software pro komplexní problémové domény. Základem pro vývoj software IS je Informační inženýrství, do kterého vybraná metodika patří. Postupem vývoje postupně přenášíme vliv problémové domény do domény softwarové (první přístup k: výběru vývojového prostředí, prostředí nasazení, architektury cílového software, ). Modelujeme ve dvou doménách, problémové-fyzické a softwarové. Modelování pro problémovou doménu postupně přechází do modelování pro softwarovou doménu. Potřebnému odlišení obou domén se musíme naučit samotnou praxí ve vývoji. Jako příklad návodu na výsledný elaborát softwarového projektu použijeme doménu Správa soukromých zbraní na teritoriu ČR (SSZ v ČR). Dále často redukujeme odkaz jen na zkratku SSZ v ČR. Nepatří do výsledného elaborátu softwarového projektu Poznámka: Nadpisy dalších kapitol již souhlasí s nadpisy výsledného elaborátu protokolu softwarového projektu. 2

3 1 ÚVOD (popis problémové domény) Následující komplexní příklad se týká domény Správa soukromých zbraní v ČR (SSZ v ČR). Ukážeme nejdříve její obecný popis, ale nebudeme se přísně držet současně platného zákona o soukromých zbraních. SSZ v ČR sama o sobě není IS české policie, ale spíše jeho součástí. Sama o sobě je víceméně samostatná a v bázi IS policie má vydělitelnou část. V této doméně jsou rozhodující informace o majiteli zbrojního průkazu (MZP), o samotných zbrojních průkazech (ZP), o zbraních a průkazech zbraní (PZ). Modifikace a vytváření informace o MZP, ZP, zbrani a PZ náleží jen administrátorovi daného okresu, tj. podle trvalého bydliště MZP. Je-li zbraň zakoupena, musí být podle zákona do jisté doby zavedena do používání. Prodejce vydává ke zbrani výsledek její výrobní kontroly (osvědčení o správné funkcionalitě, nástřelný terč, vše s podpisy státem delegovaných kontrolorů). Zbraň je potom zavedena do systému policejním administrátorem v daném okrese, tj. vytvoří se informace o jejím zavedení a asociaci s MZP. Je-li to zákonem stanoveno, zbraň musí být kontrolována a výsledek zapsán do báze dat. V další části popisu SSZ v ČR jsou uvedeny její některé charakteristiky: MZP 1. Každý majitel Zbrojního průkazu je v bázi cílového software evidován, tedy vede se o něm následující informace: MZP = (ID majitele ZP, jméno a příjmení, rodné číslo, fotografie, trvalé bydliště, ID žádosti, ID lékařského vysvědčení, ID vysvědčení o zkoušce). Žádný jiný občan ČR, než ten který má zavedený zbrojní průkaz, není v bázi cílového software evidován. S MZP souvisí Žádost formulář (ŽF) o vydání nového ZP, Lékařské vysvědčení (LV) o způsobilosti používat a vlastnit zbraň dané kategorie, Vysvědčení o zkoušce (VZ) ze znalosti a manipulaci se zbraní dané kategorie/-í a aktuální fotografii (viz dále ZP). ZP 2. Zbrojní průkaz (ZP) je samostatná datová entita se strukturou ZP = (eviden. číslo, platnost do, ID majitele ZP, kategorie zbraní: A F, kdo vydal). Atributy jméno a příjmení, rodné číslo, fotografie a trvalé bydliště, které jsou na kartičce zbrojního průkazu vytištěny, jsou přebírány od MZP. 3. Nový ZP se tiskne speciálním strojem a je neprodyšně zataven (nelze do něj nic doplňovat). 4. Každý ZP je evidován samostatně, podobně jako MZP. 5. Osoba vlastní pouze jeden ZP a nemusí vlastnit žádné zbraně. 6. K vydání nového ZP je nutno předložit několik dokumentů: a. Žádost formulář (ŽF) o vydání nového ZP. b. Lékařské vysvědčení (LV) o způsobilosti používat a vlastnit zbraň dané kategorie. c. Vysvědčení o zkoušce (VZ) ze znalosti a manipulaci se zbraní dané kategorie/-í. d. Aktuální fotografii. 7. Se záznamem nového ZP se musí vytvořit nový záznam pro MZP. 8. ZP je možno odebrat (pochopitelně potom i vlastněné zbraně) na základě několika skutečností (zhoršení zdrav. stavu, odsouzení k závažnému nepodmíněnému trestu, nepřípustné použití zbraně,... ). 9. Může dojít k situaci, že ZP je nutno aktualizovat (změna vzhledu, změna příjmení, změna bydliště, rodného čísla, změna oprávnění na kategorie zbraní). Pak se musí aktuální ZP zničit a 3

4 Zbraň vyrobit nový, editovaný. Proto se může evidovat i pořadí vydání nového ZP. 10. Řízení informace v uvedených procesech je dovoleno jen administrátorovi okresního velitelství policie ČR, tj. stanovenému důstojníkovi na policejním velitelství. 11. Každá zbraň musí být důsledně evidována. Relevantní informace o samotné zbrani, se získají z prodejního dokumentu Prodejka zbraně (PROZ), kde je uvedeno: PROZ = (název zbraně, výrobní číslo zbraně, druh zbraně, ráže, výrobce, kategorie zbraně (A, B, ), datum výroby, datum prodeje, ID majitele zbraně). K Prodejce zbraně je přiložena Výstupní kontrola zbraně (VKZ) z výrobního podniku, která obsahuje identifikaci osoby, která kontrolu provedla a rovněž terč s výsledkem střelby tří ran na vzdálenost 25 metrů. Tedy eviduje se následující informace: VKZ = (ID kontroly, výrobní číslo zbraně, druh zbraně, ráže, ID kontrolora, výsledek kontroly). Entita Zbraň je velmi důležitou datovou entitou systému Správa soukromých zbraní v ČR a rozhodující je výrobní číslo zbraně. Evidence zbraně obsahuje následující informaci: ZBRAN = (výrobní číslo zbraně, ID majitele ZP, datum nabytí zbraně, stav zbraně). V doméně může dojít k situaci, že zbraň je ztracena, nebo ukradena. V každém případě je majitel zbraně povinen situaci hlásit. Informace o ztrátě je vedena v entitě ZTRÁTA = (ID ztráty, výr. č. zbraně, ID majitele, datum hlášení, protokol) Vzhledem k této situaci musí být o zbrani důsledně veden její stav. PZ 12. Ke každé zbrani se musí vytvořit Průkaz zbraně (PZ). Je v něm několik relevantních údajů z Prodejky zbraně (PRZ). Tedy PZ = (eviden. číslo, druh zbraně, výrobce, vzor, ráže, výrobní číslo zbraně, kategorie, ID majitele, registrace u, datum registrace). Průkaz zbraně je tedy vázán na majitele zbraně, přes ID majitele zbraně, a je platný pro celou ČR. Na PZ je informace o majiteli vytištěna (jméno, příjmení a rodné číslo) 13. Každý Majitel zbraně musí být evidován a identifikován (včetně fotografie) a určeno místo jeho pobytu. Mimo jiné musí mít Zbrojní průkaz. 14. Každá zbraň musí být pravidelně předkládána ke kontrole a kontrola musí být evidována. Tedy o Kontrole zbraně by měla být vedena následující informace: KZ = (ID kontroly, datum kontroly, druh zbraně, výrobní číslo zbraně, výsledek kontroly). 4

5 2 Fáze ZAHÁJENÍ Co vše se musí udělat v této fázi? Pro jednodušší problémové domény se doporučují provést ve fázi ZAHÁJENÍ tyto úkoly: Pracovní postup PLÁNOVÁNÍ: Plánování ITERACÍ softwarového projektu. Podmínky proveditelnosti, RIZIKA a jejich zhodnocení. Obchodní případ (podnikatelské zhodnocení). Kontextová analýza problémové domény. Analýza klientů cílového software. Prvotní přístup k architektuře cílového software. Prvotní přístup k prostředí nasazení. Prvotní přístup k použití vývojového prostředí. Pracovní postup POŽADAVKY: Analýza uživatelských požadavků (Vize o budoucím soft. systému, Seznam specifikací požadavků, Taxonomie požadavků). Přiřazení požadavků případům užití. Diagramy případů užití a modelování případů užití, včetně jejich specifikace. REALIZUJME TEĎ OBA DVA PRACOVNÍ POSTUPY 2.1 Pracovní postup PLÁNOVÁNÍ Tento pracovní postup zde nebudeme realizovat celý, protože souvisí s ustanovením softwarového projektu. Zejména nebudeme plánovat iterace, hodnotit rizika, hodnotit obchodní případ. Z tzv. PRVOTNÍCH PŘÍPADŮ ovšem realizujeme následující: Kontextová analýza problémové domény Analýza klientů cílového software Prvotní přístup k architektuře cílového software Prvotní přístup k prostředí nasazení Prvotní přístup k vývojovému prostředí KONTEXTOVÁ ANALÝZA PROBLÉMOVÉ DOMÉNY Nakreslíme-li SSZ v ČR jako černou skříňku a zaměříme se na okolí, potom můžeme nakreslit následující schéma. Doména SSZ v ČR je specifickou doménou s malým počtem prvků v okolí (zbrojní technici, majitelé ZP, administrátoři), je to dáno její povahou. 5

6 Zbrojní technici Majitelé ZP Administrátoři Výrobní kontroloři SSZ v ČR Doména je součást policejního ředitelství, které má několik organizačních jednotek, věnujících se problematice SSZ v ČR. Zajímavější je procesní struktura domény SSZ v ČR. V ní můžeme rozeznat i více množin procesů než uvádíme v následujícím obrázku. Uvedené množiny ovšem považujme za stěžejní. Správa klientů Správa ZP Statistiky a vyhledávání SSZ v ČR Správa MZP Správa zbraní a PZ ANALÝZA KLIENTŮ CÍLOVÉHO SOFTWARE Výrobní kontrolor, Majitelé ZP (vlastní/nevlastní zbraně), Administrátoři a Zbrojní technici potom působí jako příjemci informace a zdroje informací. Někteří z nich mají ještě širší práva, např. spouštět procesy v doméně SSZ v ČR. Majitelé ZP sice mohou číst informace o sobě, o svých zbraních, ale nemají právo ji měnit. Nemají právo spouštět jiný proces než ten, který jim dá jim povolené informace. Zbrojní technici přijímají požadavek ke kontrole zbraně a mají právo k zápisu výsledku do báze dat. Mohou tedy spustit proces pro zápis výsledku kontroly. Jiné procesy spouštět nemohou. Výrobní kontroloři vyhotovují záznam o přezkoušení právě vyrobené zbraně, který se přiloží k Prodejce zbraně. Kardinální roli má administrátor. Jeho práva se sice týkají daného okresu, ale může mu být nadřízeným krajským administrátorem povoleno dočasné právo i pro jiný okres, nebo na celé území ČR. Hlavní administrátor je na policejním ředitelství ČR. 6

7 VIZE O CÍLOVÉM SOFTWARE Cílový software pro SSZ v ČR bude uložen na serveru informační infrastruktury policejního ředitelství ČR v Praze. Zde je rovněž hlavní administrátor, který deleguje administrátory pro kraje a ti pro jednotlivé okresy. Takto určení administrátoři mají práva, kompetence a povinnosti jen na základě územního členění. Distribuce dat mezi cílovým softwarem a klienty je realizována internetem se stanovenou ochranou (aplikační kryptografie). Přímý přístup k cílovému software má jen hlavní administrátor. Cílový software bude bazicky na architektuře Klient-server a vrcholově na architektuře dynamických komponent. Vedle toho bude cílový software typu data-driven přes vytvořenou bázi dat. PRVOTNÍ PŘÍSTUP K ARCHITEKTUŘE CÍLOVÉHO SOFTWARE. Začátek úvah o logické architektuře cílového software vychází z členění fyzické problémové domény na skupiny, nebo množiny procesů. Procesní podstata problémové domény je tedy pro logickou architekturu rozhodující. Za prvotní přístup k logické architektuře považujeme následující schéma: Správa soukromých zbraní na teritoriu ČR Statistiky a vyhledávání Správa MZP Správa ZP Správa klientů Správa zbraní a PZ Uvedené schéma můžeme nazvat schématem podsystémů, nebo modulů cílového software. Budeme používat termín podsystémy. Schéma je opravdu prvotním schématem, protože je oproštěno od zobrazení jakéhokoliv interního života každého z podsystémů a rovněž oproštěno od zobrazení vzájemného, externího života podsystémů. Pokud bychom jen stručně načrtli vizi vývoje cílového software, v souvislosti s uvedeným schématem, tak je nutno říci následující: 1. Procesy, tedy požadavky komputerizace budou rozděleny do jednotlivých podsystémů, podle jejich sémantiky. 2. Jestli mapujeme požadavky na případy užití, tak vzniklé případy užití padnou do stejného podsystému jako jejich vzor-požadavek. 3. Jestli nalezneme realizaci případu užití pomocí skupiny svázaných analytických tříd, tak tyto třídy padnou do stejného podsystému, v kterém je vzorový případ užití. 4. Jestliže mapujeme každý z podsystémů do skupiny jeho komponent, přechází prvotní schéma pro logickou architekturu do složitého komponentového modelu. Úkoly 1 a 2 se provedou ve fázi ZAHÁJENÍ, úkoly 3 a 4 až ve fázi ROZPRACOVÁNÍ. 7

8 PRVOTNÍ PŘÍSTUP K PROSTŘEDÍ NASAZENÍ. Cílový software, jehož relevantní vlastností by měla být jeho komponentová dynamická architektura, může být vyvíjen v jisté softwarové firmě na zakázku. Rozhodující pro nasazení cílového software je způsob jeho poskytnutí zákazníkovi, tj. Policejnímu ředitelství ČR. Je několik možností: 1. Cílový software je Policejnímu ředitelství ČR jednorázově prodán s celoživotní licencí. Vzhledem k možnostem informační infrastruktury Policejního ředitelství ČR, je cílový software buď součástí IS, nebo figuruje samostatně, jako komponentový celek, mimo IS. Takový celek může být nainstalován na jednom ze serverů, nebo je rozložen na více serverů, což je dáno jeho fyzickým nasazením. Potřebné úpravy (modifikace, modernizace) software musí být s produkční firmou řešeno pomocí samostatných smluv. 1. Cílový software je Policejnímu ředitelství ČR poskytován v nájmu (podle nájemního modelu produkční firmy) a není na informační infrastruktuře Policejního ředitelství ČR fyzicky nasazen. Všechny přístupy klientů jsou produkční firmou zabezpečeny. Produkční firma potom, v rámci nájmu, zohlední modernizační požadavky Policejního ředitelství ČR. PRVOTNÍ PŘÍSTUP K POUŽITÍ VÝVOJOVÉHO PROSTŘEDÍ. Jistě je možno najít mnoho vývojových prostředí pro cílový software domény SSZ v ČR. Berme však ohled na plánovanou dynamickou komponentovou architekturu. Zde bychom mohli volit vývojové prostředí jazyka Java, nebo vývojové prostředí Visual Studio. Oba dva vývojové systémy jsou podporovány mohutným Framework systémem se vzorovým systémem správy dynamických komponent. Obě prostředí rovněž disponují progresivním způsobem práce s bází dat a realizací bazické architektury Klient-server. 2.2 Pracovní postup POŽADAVKY Zkusme teď uvést návrh obsazení jednotlivých množin procesů konkrétními procesy. Tyto procesy budou sloužit jako požadavky policie ČR pro komputerizaci SSZ v ČR. Správa majitelů ZP. o Zavedení nového MZP o Modifikace informací ohledně MZP o Odstranění MZP Správa ZP. o Vydání nového ZP o Odebrání ZP o Editace stávajícího ZP Správa zbraní a průkazů zbraní (PZ). o Zavedení zbraně. o Vytvoření průkazu zbraně. o Zrušení zbraně, zrušení PZ. o Převedení zbraně na jiného vlastníka. o Předložení zbraně ke kontrole. o Hlášení o ztrátě zbraně. Vyhledávání a statistiky. o Statistiky ohledně majitelů ZP. o Statistiky ohledně zbraní. Procesy v jednotlivých skupinách jistě nevyčerpávají všechny možnosti. Další procesy mohou být průběžně doplňovány. 8

9 o Správa klientů. o o Statistiky ohledně výrobců zbraní. Řízení krajských a okresních administrátorů. Nastavení práv, povinností a kompetencí majitelů ZP. Jako silné informační entity domény SSZ v ČR mohou vystupovat: Zbrojní průkaz - ZP Majitel zbrojního průkazu - MZP Zbraň Průkaz zbraně - PZ Žádost, formulář- ŽF, k vydání nového zbrojního průkazu Lékařské vysvědčení - LV Vysvědčení o zkoušce - VZ Prodejka zbraně - PROZ Výstupní kontrola zbraně - VKZ Pravidelná kontrola zbraně KZ Ztráta zbraně - ZTRÁTA SPECIFIKACE POŽADAVKŮ Všechny procesy, uvedené v předchozím procesním obsazení jednotlivých skupin, považujeme za funkční požadavky na cílový software. Krok: TAXONOMIE POŽADAVKŮ: Funkční požadavky: Zavedení nového MZP Modifikace informací ohledně MZP Odstranění MZP Vydání nového ZP Odebrání ZP Editace stávajícího ZP Zavedení zbraně. Vytvoření průkazu zbraně. Zrušení zbraně, zrušení PZ. Převedení zbraně na jiného vlastníka. Předložení zbraně ke kontrole. Hlášení o ztrátě zbraně. Statistiky ohledně majitelů ZP. Statistiky ohledně zbraní. Statistiky ohledně výrobců zbraní. Řízení krajských a okresních administrátorů. Nastavení práv, povinností a kompetencí majitelů ZP. Nefunkční požadavky: Softwarové: Registrace Přihlášení se Odhlášení se Ostatní požadavky: Změna účtu se nepovoluje! Ochrana informace uložené v bázi dat cílového software (aplikační kryptografie) a ochrana přenosů po internetu. Tvorbu klientských (majitelů ZP) účtů řídí výlučně lokální okresní administrátor. Pro krajské administrátory řídí tvorbu administrátorských účtů hlavní administrátor. Krajský administrátor řídí účty pro podřízené okresní administrátory. 9

10 Vzhledem k tomu, že jsou procesy rozdělené do pěti skupin/množin, není možné, abychom se najednou zabývali všemi skupinami. Je-li pouze jeden řešitelský tým, tak musí postupovat po ukončení informačního modelování podle metodiky UP od jedné skupiny ke druhé. Chceme-li paralelní vývoj, tak zavedeme několik týmů a každý z nich bude informačně modelovat jen určené skupiny procesů. Krok: Stručná deskripce procesů skupiny Správa zbraní a PZ Informační modelování vyžaduje dobré znalosti o procesech domény SSZ v ČR. Teď přesněji, náš tým si sestaví prvotní deskripce procesů skupiny Správa zbraní a PZ: Nová zbraň se zavádí v procesu Zavedení zbraně. Jde nejen o vytvoření nového záznamu o zbrani, ale rovněž nového Průkazu zbraně-pz. Dále se musí zabezpečit asociace zbraně na její průkaz a rovněž na majitele Zbrojního průkazu-zp. Zrušení zbraně musí být spojeno se zrušením instance zbraně a Průkazu zbraně a tím zabezpečit rovněž zrušení asociace zbraně na majitele Zbrojního průkazu. Proces Převedení zbraně na jiného vlastníka požaduje zrušit asociaci zbraně na původního Majitele ZP, který zbraň prodává, a přepsat asociaci zbraně na Majitele ZP, který zbraň kupuje. Je nutné zrušit stávající Průkaz zbraně a vytvořit nový, protože průkaz je vázán nejen na zbraň, která se nemění, ale rovněž na vlastníka. Předložení zbraně ke kontrole se zapíše datum a výsledek kontroly jako nová instance kontroly. Hlášení o ztrátě zbraně se musí nejdříve evidovat jako instance ztráty, zbraň se z evidence nevyřadí, ovšem její nový stav je ztracena. Na základě stručného popisu skupiny Správa zbraní a PZ vyřešíme jako vzor dva následující úkoly: 1. Namapujeme procesy skupiny Správa zbraní a PZ na případy užití a využijeme hrubého popisu procesů. Vytvoříme pro skupinu Správa zbraní a PZ jediný balíček případů užití a nakresleme jeho diagram a aktéra. Využijeme pokročilé kreslení diagramů případů užití. Pokud je to nutné, doplníme balíček případy užití s relacemi <<include >> a <<extend>>. 2. Dále si vybereme jen případ užití Převedení zbraně na jiného vlastníka, pro který vytvoříme detailní tabulku s hlavním scénářem. Hlavní scénář zakreslíme aktivitním diagramem. Načrtneme plavecké dráhy (budou-li potřebné) a znázorníme tok objektů-instancí (pokud instance vznikají). 1. Mapování: Za vhodné mapování procesů-požadavků skupiny Správa zbraní a PZ můžeme považovat zobrazení 1:1, které je dáno následující tabulkou, v níž přeneseme názvy požadavků na vzniklé případy užití. Procesy Případy užití Zavedení zbraně Vytvoření Průkazu zbraně Zrušení zbraně Převedení zbraně na jiného vlastníka Předložení zbraně ke kontrole Hlášení o ztrátě zbraně Zavedení zbraně Vytvoření Průkazu zbraně Zrušení zbraně Převedení zbraně na jiného vlastníka Předložení zbraně ke kontrole Hlášení o ztrátě zbraně Chápejme vzniklé případy užití jako balíček (sémantické vazby případů užití jsou velmi silné). Pokusíme se proto vytvořit balíček případů užití, přičemž jsme zvážili doplnění dalšími případy 10

11 užití, které jsou nezbytně nutné k životu celého balíčku (Vyhledání zbraně, Zrušení PZ). Jsou ovšem další pomocné případy užití, např. Vyhledání MZP, Vyhledání ZP, Vyhledání PZ, Odebrání zbraně, Přidání zbraně, Těmito případy užití můžeme diagram balíčku ještě zjemnit. Správa zbraní a PZ Ztráta zbraně <<include> > Vyhledání zbraně Administrátor Zavedení zbraně <<extend>> Vytvoření PZ Zrušení zbraně <<include>> << extend >> Vyhledání zbraně Zrušení PZ Zbrojní technik Převedení zbraně na jiného vlastníka <<extend>> Vytvoření PZ Předložení zbraně ke kontrole Co lze k vytvořenému balíčku dodat? - je pro celou skupinu Správa zbraní a PZ, - jisto-jistě neobsahuje všechny potřebné případy užití, je to jen první nástin, ale zatím dostatečný. 2. Detailní scénář: Teď bychom měli vytvořit detailní scénáře pro všechny případy užití z našeho balíčku. Stačí ovšem, když si vybereme jeden případ užití. Pro ostatní bychom postupovali obdobně. Jako vzorový si vybereme jen případ Převedení zbraně na jiného vlastníka. Není to příliš komplikovaný případ užití. Zajímavé je to, že se netýká změn Zbrojního průkazu, ale týká se změny Průkazu zbraně (je na něm nový majitel zbraně). Změní se tedy asociace mezi zbraní a jejím novým průkazem. Jde v podstatě jen o změnu asociace mezi entitou Majitel zbrojního průkazu a entitou Zbraň a to jak pro prodávajícího, tak i kupujícího. Vstupní podmínkou případu užití je existence obou platných ZP (prodávajícího a kupujícího), PZ a platná kontrola prodávané zbraně. Následující tabulka je návrh detailizace případu užití Převedení zbraně na jiného vlastníka. Do podrobné tabulky případu užití Převedení zbraně na jiného vlastníka prozatím nezavedeme alternativní scénáře, ačkoliv obecně pro tento případ užití existují. Prvním z nich je alternativní scénář pro situaci, kdy jsou sice prodávající a kupující ze stejného kraje, ale z různých okresů. Potom musí lokální administrátor žádat krajského administrátora o povolení provést operaci mezi okresy. Jisto-jistě existují pro daný případ užití další specifické situace, k nimž je nutno napsat alternativní scénáře, ale na tyto situace jsme zatím nepřišli. 11

12 Případ užití: Převedení zbraně na jiného vlastníka ID: 6 Stručný popis: Systém umožní převést danou zbraň od jednoho majitele na jiného. Hlavní aktéři: Administrátor policejní důstojník Vedlejší aktéři: Žádní Vstupní podmínky: Platné ZP prodávajícího a kupujícího, platný PZ prodávané zbraně a její kontroly. Oba ZP jsou evidované v lokálním okrese Hlavní scénář: 1. Zadej výrobní číslo zbraně potom evidenční číslo PZ. 2. Je-li zbraň v pořádku a rovněž v pořádku její průkaz, zjisti kategorii zbraně, majitele a pokračuj na bodu 3. Jestliže nejsou v pořádku (zbraň: není evidovaná v systému, má neplatnou kontrolu, PZ: není evidován v systému), tak oznam závady a ukonči případ užití. 3. Zadej evidenční čísla obou ZP, prodávajícího a kupujícího. Jsou-li oba ZP v pořádku (jsou evidované v systému), tak pamatuj identifikaci obou majitelů, jejich kategorie zbraní a jdi na bodu 4. Jinak udělej oznámení chyby a ukonči případ užití. 4. Je-li vše v pořádku (prodávající je evidovaným majitelem zbraně, zbraň má platnou kontrolu, kategorie prodávané zbraně je v souladu s kategoriemi na ZP prodávajícího a kupujícího), tak zruš asociaci dané zbraně (podle výrobního čísla zbraně) na majitele, tj. prodávajícího. 5. Zaveď asociaci zbraně (podle výrobního čísla) na kupujícího. 6. Zruš původní PZ a vytvoř nový s indikací nového majitele. 7. Podej zprávu o provedení případu užití a dokumentuj výpisy nové asociace prodávané zbraně. Výstupní podmínky: Žádné Alternativní scénáře: Nejsou zavedeny Relace aktérů k případu užití: Aktér, lokální okresní administrátor se k cílovému software přihlašuje (musí zadat své uživatelské jméno a heslo) a případ užití spouští. 3. Aktivitní diagram: K danému hlavnímu scénáři patří následující aktivitní diagram. Určíme v něm pouze dvě odpovědnosti za aktivity v případu užití, které jsou dány Systémem cílového software a Administrátorem. V průběhu případu užití dochází ke vzniku nové instance PZ, dochází rovněž k přepisu atributů jedné instance datové entity Zbraň. 12

13 Systém Administrátor Zadej: výr. číslo zbraně, evidenční číslo PZ závady Oznámení o nedostatcích v evidenci a kontrole Zadej evidenční čísla ZP prodávajícího a kupujícího evidence? kategorie? závady Oznam závad Zruš asociaci zbraně na prodávajícího. Zaveď asociaci zbraně na kupujícího. Vytvoř nový PZ s indikací nového majitele. Dokumentuj správné provedení případu užití pomocí výpisu nové asociace zbraně na majitele Aktivitní diagram je možno ještě doplnit zákresem vzniku nové instance PZ. Závěr, co jsme udělali? Provedli jsme kontextovou analýzu Popsali jsme procesy-požadavky. Ukázali jsme mapování procesů-požadavků na případy užití. Rozebrali jsme obecné zájmy zákazníka a řešitele cílového software (Vize o cílovém software, Podmínky proveditelnosti) Diskutovali jsme vybrané Prvotní přístupy, Provedli jsme mapování procesů-požadavků na případy užití. Nepatří do elaborátu protokolu softwarového Sestrojili jsme balíček případů užití Řízení zbraní a PZ projektu Detailizovali jsme scénář vybraného případu užití. Využili jsme Aktivitní diagram pro grafickou anotaci případu užití. Splnili jsme základní úkoly fáze ZAHÁJENÍ a pracovních postupů Plánování a Požadavky. Všechny dosažené výsledky (případy užití, diagram případů užití ve formě balíčku, detaily případů užití, aktivitní diagramy) jsou vstupem do fáze ROZPRACOVÁNÍ. 13

14 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -1- Fáze ZAHÁJENÍ pro firmu BODY- CARE PRVOTNÍ PŘÍSTUPY: nejnovější elaborát, Podmínky proveditelnosti a jejich zhodnocení Firma BODY-CARE nechce nakoupit integrovaný systém. Dokonce IS, který by se hodil k realizaci procesů a zpracování dat v podstatě neexistuje. Tak, jak prohlásil ředitel firmy, ani centrum nemá IS, který by rovněž řídil filiálky v krajských městech. Centrum výhledově počítá s nákupem IS typu SAP pro veškeré ERP (majetek, finance, ) na centru, přičemž filiálky evolučně implementují systém pro řízení procesů prodeje a expedice zboží, marketingu a péči o své zákazníky. Tento softwarový systém filiálek by měl být na systém typu SAP připojitelný. Je to sice zvláštní řešení, ale ředitel firmy předpokládá podle prvních odhadů, že finanční zátěž vývoje softwarového systému je pro BODY- CARE akceptovatelná. Tabulka možného implementovatelného finančního kapitálu firmy BODY- CARE na vývoj zmíněného softwarového systému potvrzuje proveditelnost vývoje. To potvrdily obě firmy, BODY- CARE a softwarová firma IS Production Company. Jelikož odhady byly provedeny na úzkém jednání ředitele firmy a ředitele softwarové firmy (možný produkční adept) a prohlášeny oběma zástupci za citlivé, není možno je zveřejnit. 2 Obchodní případ (podnikatelské zhodnocení) Provádění všech aktivit firmy BODY- CARE tužkou, papírem a lidskou hlavou se ukázalo jako neúnosné. Extenzivní nárůst počtu pracovníků se stal pro firmu finančně nepřijatelný. Firmě se snižovala konkurenceschopnost, ačkoliv počet zaměstnanců narůstal. Komputerizované adekvátní firmy dosahovaly prostřednictvím internetového obchodu dalece většího obchodního obratu než nekomputerizovaná BODY- CARE. Studie, kterou vypracovalo vedení firmy za poradenství softwarové firmy, jasně poukázala na aktivity, které by po komputerizaci měli firmě přinést zvýšení obchodního obratu: Evidence veškeré informace v centrální bázi dat a její využívání. Dát zákazníkům, kteří jsou přítomni na prodejním místě firmy, možnost vytvořit elektronickou objednávku a odeslat ji do prodejního systému. Řízení prodeje a expedice zboží. Marketing a péče o zákazníky. Internetový obchod. Elektronická komunikace s centrem firmy v Praze. 3 Kontextová analýza problémové domény Ačkoliv se při letmém pohledu na okolí firmy zdá, že bude nevýrazné, skutečnost je jiná. Jako každá firma ČR rovněž BODY- CARE musí být napojena na mnoho jiných systémů veřejného života: bankovní ústav, zdravotní středisko, zdravotní pojišťovnu, pracovní úřad, finanční úřad, sociální úřad. Firma využívá možností dodavatelů propagačních tiskovin. Nelze ovšem opomenout kontakt na centrum firmy, které je v Praze.

15 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -2- Maloodběratel zboží 1 Odběratel firma 2 Bankovní ústav Zdravotní středisko Zdravotní pojišťovna 1 Sklad centra Centrum firmy 4 BODY- CARE 3 Dealer Pracovní úřad Dodavatelé propagačních tiskovin Sociální úřad Finanční úřad Jak bylo již řečeno, firma rozlišuje několik odběratelů zboží: maloodběratel, dealer a odběratel-firma. Poslední dva profitují, ačkoliv odlišně, na velkoodběru zboží. Popis relevantních vazeb: 1. Vazby 1, 2 a 3: Odběratelé posílají Objednávku zboží, dostávají Fakturu a Expediční list 2. Vazba 4: Centrum firmy dostává Objednávku-c pro přesun zboží do skladu filiálky. Vedle toho dostává centrum vyhodnocení měsíční aktivity filiálky. 4 Analýza klientů cílového software Vzhledem ke kontextové analýze firmy, budou zřejmě relevantními klienty cílového software maloodběratel, dealer a odběratel-firma a pochopitelně firma-centrum. Mimo softwarový systém rovněž stojí zaměstnanci firmy BODY- CARE, tj. klienti-zaměstnanci, kteří mají jistá práva, povinnosti a kompetence podle zaměstnaneckých pozic a rolí, které v nich mohou hrát. Za klienty systému budeme považovat rovněž některé systémy z okolí firmy BODY- CARE, např. centrum firmy, dodavatelé propagačních tiskovin, bankovní ústav,...). Pochopitelně, administrátor systému je rovněž relevantním klientem systému. 5 Prvotní přístup k architektuře cílového software Vzhledem k tomu, že bude plánováno doplnění cílového software o internetový prodej, bude rovněž realizovaná IINS (informační infrastruktura firmy), koncové počítače budou na prodejním místě a v boxech zákazníků, bude výhodné spojit koncového klienta jen s náležící komponentou cílového software, která realizuje klientem požadovanou funkcionalitu. Jistě budou konstruovány následující komponenty: pro prodej zboží, pro skladovou a expediční činnost,

16 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -3- pro marketing a péči o zákazníka, pro internetový prodej, pro ekonomicko-finanční vyhodnocení firmy, pro přístup k softwarovému systému. Distribuovaný softwarový systém na komponentovém základě umožní transparentnější vývoj a šetření operační paměti koncových počítačů. 6 Prvotní přístup k prostředí nasazení Jelikož firma bude mít samostatnou bázi dat, kterou bude cílový software využívat, bude požadována informační infrastruktura napojená na internet. Informační infrastruktura musí prokazovat alespoň tyto základní funkcionality: centrální ochrana informace, uložení a provozování cílového software na jednom ze serverů, poskytnutí serverových prostorů pro firemní bázi dat, napojení na internet, rozvedená místní počítačová síť. Napojení na internet by mělo umožnit organizovat internetový prodej, který bude později součástí cílového software, s osobním vyzvedáváním expedičního balíčku v sídle firmy. 7 Prvotní přístup k použití vývojového prostředí Vzhledem k tomu, že je zvolena komponentová architektura cílového software, připadají v úvahu jen objektová vývojová prostředí s možností tvorby silně distribuovaného cílového software, založeného na komponentách. Takovým prostředím je např. VISUAL STUDIO firmy Microsoft s objektovým jazykem C#. 8 Analýza požadavků Funkční (business) požadavky: Na základě interview s kolegiem ředitele firmy BODY- CARE došlo k vzájemné dohodě na požadavcích uživatele, uvedených v následujícím Seznamu funkčních požadavků zákazníka: 1. Řízení prodeje zboží počítačem a řízení skladování zboží počítačem. 2. Možnost statistického vyhodnocení prodeje. 3. Možnost analyzovat pohyb zboží v prodeji a ve skladu, vytvářet potřebné statistiky. 4. Možnost provádět ekonomicko-finanční vyhodnocení skladové činnosti a samotného skladu zboží. 5. Řízení expedice zboží počítačem. 6. Rozesílání dokumentů mezi odděleními firmy počítačem.

17 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE Počítačová příprava Objednávky. Zákazník může prezenčně připravit elektronickou Objednávku a odeslat ji do systému. 8. Zjištění stavu Objednávky. Zákazník chce vědět o stavu vyřizování své Objednávky. Zákazník může objednávku stornovat. 9. Řízení internetového prodeje. 10. Možnost počítačové komunikace s centrem firmy a některými systémy z okolí firmy. 11. Možnost internetového marketingu a specifické péče o zákazníky. 12. Počítačem řízená správa zákazníků Nefunkční požadavky: (softwarové) 1. Autentizace (poznání) typu klienta systému (host, neregistrovaný zákazník, registrovaný zákazník). 2. Povinná registrace. Systém vyžaduje, aby byl každý klient registrován. 3. Povinné přihlašování. Systém vyžaduje, aby každý styk již registrovaného klienta se systémem začínal procedurou Přihlášení se. 4. Změna stávajícího hesla na nové. Systém umožní klientovi změnu jeho stávajícího přístupového hesla do systému na heslo nové. 5. Odhlášení se od systému. Odhlášení se ukončí veškerou aktivitu klienta v systému. (ostatní) Realizace elektronického platebního systému za Faktury pomocí finanční transakce na účet firmy BODY- CARE (nutné využití registračních čísel zákazníků, které jsou rovněž identifikací zákaznické čipové karty). Zpracování požadavků inženýrem požadavků softwarové firmy: Na základě analýzy jednotlivých požadavků bylo zjištěno, že se sémanticky překrývají. Byly proto zavedeny jen požadavky relevantní a dílčí překrývající do nich zařazeny podle níže uvedeného schématu. Nový seznam funkčních a nefunkčních požadavků zákazníka: A. Řízení prodeje zboží počítačem B. Zavedení internetového prodeje C. Počítačové řízení skladové činnosti D. Řízení expedice zboží počítačem E. Internetový marketing a péče o zákazníka F. Správa dokumentů firmy počítačem G. Realizace elektronického platebního systému (ostatní) H. Přístup klienta k softwarovému systému (softwarové a funkční) Schéma zařazení původních dílčích požadavků: A 2, 7, 8 A, 1 C, 9 B, 10 H, 11 E 3, 4 C, 5 D, G (ostatní)

18 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE E, 6 F 1, 2, 3, 4 H (softwarové požadavky) Specifikace funkčních (business) a nefunkčních požadavků: A. Řízení prodeje zboží počítačem Uživatel požaduje, aby cílový software, uložený na serveru IINS firmy, měl svá koncová zařízení-počítače ve všech místech firmy (oddělení, vedení, zákaznické boxy, prodejní místo). Zákazník by měl vyplnit Objednávku, kterou mu systém umožní vytvořit. Objednávku zákazník předá do systému a systém ji buď zařadí do fronty, nebo ji začne okamžitě vyřizovat. Vyřizování Objednávky spočívá v kontrole správnosti materiálových čísel objednaného zboží a výsledku možnosti pokrytí Objednávky skladem firmy. Systém poté vytvoří Expediční list a Fakturu. Jeden vytištěný originál Faktury dostává zákazník v boxu, v kterém sedí, druhý originál Faktury je dán k dispozici Finančně ekonomickému oddělení. Expediční list dá systém zase k dispozici Oddělení skladu a expedice. Zákazník má možnost proplatit fakturu stylem cash (v místě styku se zákazníky), nebo elektronicky. Systém považuje proplacení Faktury za nutnou podmínku zaslání Expedičního listu do Oddělení skladu a expedice. Dokumenty Objednávka, Faktura a Expediční list spolu sémanticky souvisí a jsou klíčovány registračním číslem zákazníka (je rovněž na čipové kartě zákazníka) a dalšími atributy. Další klíčování může být určeno identifikací vlastního prodeje. Systém tedy vytváří svoji vlastní entitu Prodej. Je to důležitý záznam identifikace prodeje, data, času a dalších relevantních atributů. Entita Prodej je dána k dispozici Oddělení prodeje. Toto oddělení může požadovat na systému provedení jisté statistiky odhalující některé taje prodeje. Na základě mnoha uskutečněných prodejů, např. za týden, měsíc, rok je možno statisticky vyhodnotit nejúspěšnější odběratele podle jistých kritérií (finance, množství kosmetických přípravků), rovněž sledovat prodej některých kosmetických přípravků přímo. Základem pro vyhodnocení prodeje jsou Prodejky. Každý zákazník může v zákaznickém boxu připravit svou elektronickou objednávku a systém mu všeobecně vypomůže v její tvorbě. Výpomoc systému spočívá zejména v nakreslení formuláře, v řízení vyplňování kolonek, v poskytnutí všech potřebných pomocných materiálů, např. katalogů platných v daném měsíci, Zákazník potom může hotovou Objednávku odeslat do systému k vyřízení. Zákazník má právo se systému zeptat v jakém stavu jeho Objednávka je. Jestli se zákazníkovi zdá, že čas vyřizování Objednávky je nepřijatelně dlouhý, může Objednávku stornovat. Objednávka může být ve frontě, objednávka je stornována, objednávka je ve stavu vyřizování, Zákazník musí ovšem zadat identifikační číslo Objednávky, které mu systém sdělil po jejím přijetí. Zákazník se může rozhodnout stornovat zakázku i z jiných důvodů. Jsou-li již v době tvorby Faktury k dispozici katalogy zboží na příští měsíc, přidají se jako zboží do Faktury a přiloží se do expedičního balíčku. B. Zavedení internetového prodeje Je to možnost spočívající v tom, že vzdálený zákazník se může prostřednictvím internetu přihlásit k softwarovému systému a tím se stane jeho počítač koncovým zařízením. Podle typu zákazníka systém nastaví jeho komunikační interface s možnostmi uplatnit jeho práva, povinnosti a kompetence. Systém potom zákazníkovi umožní nakupovat do košíku, potvrdit nákup a košík odeslat. Současně systém automaticky vyhotoví Objednávku zákazníka a zařadí ji do procesu vyřízení. C. Počítačové řízení skladové činnosti Řízení skladové činnosti je orientováno jednak na uskladnění zboží, které je přijato z centrálního skladu a vyskladnění zboží v rámci jeho prodeje. Systém umožní zásobovači skladu vyhotovit Objednávku-c, kterou do centra odešle. Vyhotovení je provedeno na základě výsledků prověrky skladu (podlimitní stavy zásob, stav pohybu zboží-vyskladňování, ). Uskladnění zboží, dodaného z centrálního skladu je završeno aktivitou systému, která spočívá ve vyhotovení a odesláním Příjemky do centra. Tato aktivita systému je

19 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -6- ovšem podmíněna souhlasem zásobovače, který potvrdí, že dodané zboží souhlasí s Dodacím listem. Dále jde o operace, které umožní sledovat pohyb zboží mezi skladem firmy a centrálním skladem a pohyb zboží mezi zákazníky a skladem firmy v rámci prodeje. Dále musí být sledována finanční reprezentace pohybu zboží mezi skladem firmy a zákazníky. Musí se sledovat finanční velikost skladu zboží, tj. finanční reprezentace zásob. D. Řízení expedice zboží počítačem Systém oznámí expedici příchod Expedičního listu. Expedice může zahájit tvorbu expedičního balíčku. Balíček je stvořitelný, protože to zjistil systém (Faktura je již zaplacena). Balíček vytváří převážně jen jeden pracovník expedice. Úspěšné ukončení tvorby balíčku oznámí tento pracovník systému. Následuje potom vytvoření dvou originálů Výdejky. Jeden je vytištěn a přidán do expedičního balíčku, druhý zůstává v Oddělení skladu a expedice. Systém potom upozorní majitele Objednávky na možnost vyzvednutí expedičního balíčku na výdejním místě. E. Internetový marketing a péče o zákazníka Možnost vést internetové stránky, na kterých je propagováno zboží na skladě, na které je uplatněna slevňovací politika firmy, život firmy, zveřejňování a odměňování velmi úspěšných zákazníků, Je to rovněž možnost evidovat relevantní informace o zákaznících (např. zájem o jisté skupiny kosmetických přípravků, jejich záliby, ) a přednostně s některými zákazníky neustále vést dialog o nových výrobcích, jejich kvalitách, o cenové politice firmy, Jde rovněž o možnost provádění změn na kartě zákazníka, změn údajů o zákaznících. F. Správa dokumentů firmy počítačem Nemyslí se posílání dokumentů elektronickou poštou. Spíše jde o funkcionalitu zabezpečení přístupu k dokumentu na základě práv, povinností a kompetence. Týká se to zaměstnanců firmy BODY CARE, centra firmy a externích klientů (banka, úřady, ). G. Realizace elektronického platebního systému Vedle možné cash platby (provádí se v místě prezenčního styku se zákazníky) systém umožní pro majitele účtů a kreditních karet platbu elektronickou, prostřednictvím dohody s vybraným bankovním ústavem. Systém zabezpečí ochranu informací, zadaných zákazníkem a potřebných pro bankovní transakci. Systém předloží zákazníkovi krátké formuláře pro zadání bankovních dat a požádá o souhlas s provedením transakce. Zákazníkovi systém oznámí úspěšné provedení požadované bankovní transakce. H. Přístup klienta k softwarovému systému Jelikož se za klienta z okolí považuje rovněž centrum firmy, tak je požadavek na elektronizaci odesílání Objednávky-c do centra na dodání zboží, přijetí Dodacího listu z centra a odeslání Příjemky po dodání zboží. Centrum firmy BODY CARE je preferovaným klientem. Patří sem také možnost odesílat centru veškeré údaje o provozu firmy (prodej, skladování, marketing, péče o zákazníky). Patří sem rovněž možnost elektronické komunikace s klienty z okolí firmy (bankovní ústav, ). První styk klienta musí procházet přes tzv. Registraci. Po vyplnění registračního formuláře přidělí systém klientovi uživatelské jméno (Login) a prvotní heslo (Password) a současně stanoví jeho typ a příslušné pracovní prostředí, v kterém má možnost uplatnit svá práva, povinnosti a kompetence. Uživatelské jméno je možno změnit. Heslo systém se umožní měnit pomocí procedury Změna přístupového hesla. Každý registrovaný klient musí další styk se systémem začínat procedurou Přihlášení. Po vyplnění přihlašovacího formuláře, nastaví systém pro klienta jeho interface, tj. pracovní prostředí. Podle přání klienta, na základě jeho důvodů, umožní systém změnu přístupového hesla. Pro tuto změnu má systém připraven speciální formulář, ve kterém se musí zadat staré heslo a dvakrát heslo nové. Provedení změny je klientovi oznámeno. Na ukončení komunikace klienta se systémem, systém žádá

20 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -7- odhlášení. Přístupy centra firmy řídí administrátor firmy BODY CARE. 9 Mapování funkčních/nefunkčních požadavků na případy užití Jednotlivé funkční požadavky nejdříve sémanticky rozčleníme do několika balíčků a požadavkům přiřadíme případy užití. Mapování požadavků je ukázkově provedeno jen pro balíčky Prodej a Softwarové požadavky. Vytvořit Expediční list Vytvořit Objednávku zboží Stornovat Objednávku zboží balíček Prodej (f. požadavky): Řízení prodeje zboží počítačem Statistické vyhodnocení prodeje, pohyb zboží v prodeji Reklamovat Objednávku zboží Statistika prodaného zboží za měsíc Proplatit Fakturu za Objednávku zboží Vytvořit Prodejku zboží Vytvořit Fakturu zboží Dalších několik balíčků jen pojmenujeme (názvy jsou podobné názvům Obecného znění požadavků), ale mapování neprovedeme. Mapování na případy užití provedeme ještě u posledního, softwarového balíčku. Důvod je zřejmý. Tyto případy užití budou předcházet každému jinému případu užití. Internetový obchod (požadavky) Sklad a expedice (požadavky) Péče o zákazníky (požadavky) Správa dokumentů (požadavky)

21 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -8- Platební systém (požadavky) Autentizace Přístup Autentizace Autorizace Povinná registrace Povinné přihlášení Odhlášení ze systému Změna přístupového hesla Změna uživatelského jména Registrace Přihlášení Odhlášení Autorizace Změna přístupového hesla Změna uživatelského jména Diagram případů užití (k balíčku Prodej ): Prodej Asistent prodeje Reklamovat Objednávku zboží Oznámení Reklamační úprava Objednávky Statistika prodaného zboží za měsíc Zákazník Odběratel Firma 0 Dealer <<include>> Stornovat Objednávku zboží Změna hesla Vytvořit Objednávku Provize po odběru zboží <<include>> <<extend>> Vytvořit Fakturu <<extend>> <<extend>> <<extend>> Proplacení Faktury Vytvořit Expediční list <<extend>> <<extend>> Pokrytí Objednávky Vytvořit Prodejku

22 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -9- Protože firma BODY CARE nepotřebuje Autorizaci, tak ji ani neuvádíme v balíčku Přístup. Přístup Registrace Autentizace Přihlášení Odběratel Odhlášení Změna uživatelského jména Změna přístupového hesla Zákazník Dealer Firma Jak hledat případy užití? Velmi často se nesprávně volí za případy užití aktivity, na kterých se podílí jen jedna třída, a aktivita by měla být považována spíše za operaci nad danou třídou. Jestliže se na aktivitě podílí spolupracuje více tříd, potom je skutečné opodstatnění tuto aktivitu považovat za případ užití. Taková aktivita je realizovatelná spoluprací komunikací instancí účastnících se tříd na základě zasílání zpráv. Operace a případy užití musí pokrývat podstatu požadavku. Detailní popisy případů užití Z případů užití balíčku Prodej a Přístup si vybereme jen dva případy užití Stornovat Objednávku a Vytvořit Objednávku. První je poměrně složitý, druhý zase jednodušší.

23 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -10- Případ užití: Stornovat Objednávku ID: 5 Stručný popis: Systém podá zprávu o stavu provedení případu Stornovat Objednávku Hlavní aktéři: Odběratel (zákazník, dealer, firma) Vedlejší aktéři: Žádní Vstupní podmínky: Uživatel je zaregistrovaný a je již přihlášen. Uživatel zadá identifikační číslo Objednávky zboží Hlavní scénář: 1. Případ užití je spuštěn z menu systému volbou Stornovat Objednávku nebo z panelu ikon, ikonou Stornovat Objednávku 2. Systém žádá sdělení čísla Objednávky. 3. Systém prověří existenci Objednávky. Není-li Objednávka nalezena, je dán výstupní oznam a případ užití končí. Jinak, Objednávka je nalezena, pokračuje se na bod Systém zjistí stav Objednávky. 5. Objednávka může být v několika stavech: ve frontě (souvisící dokumenty ještě nebyly vypracovány), rozpracovaná (souvisící dokumenty již byly vytvořeny), ukončena (byl již vyzvednut expediční balíček). a. Je-li Objednávka ve stavu ve frontě je možné ji zrušit bezproblémově, protože nedošlo vůbec k zjištění pokrytí Objednávky a tvorbě dalších souvisejících dokumentů (Faktura,, Prodejka). b. Jestliže je Objednávka již v řešení a je tedy ve stavu rozpracovaná, potom může stornování povolit jen pracovník reklamačního místa. Systém čeká na jeho odpověď. Povolí-li zrušení, pak je provedeno. Není-li dán souhlas, případ užití končí a Objednávka v systému zůstává. c. Jestliže je Objednávka již ukončena, nelze ji stornovat, může dojít jen k Reklamaci. Systém své rozhodnutí oznámí. 6. Jestliže k zrušení Objednávky dojde, potom se musí zničit všechny instance všech souvisejících dokumentů (Faktura,, Prodejka) a peníze se vrátí na bankovní účet, jestliže byla Faktura již proplacena. Systém podá zprávu o výsledku stornování. Výstupní podmínky: Stav Objednávky Alternativní scénáře: Klient je vrácen do svého interface, poté se může ze systému odhlásit Relace aktérů k případu užití: Aktér Odběratel systému BODY- CARE případ užití spouští a musí zadat systému identifikační číslo své Objednávky. SEM VLOŽIT KOMUNIKAČNÍ DIAGRAM PRO: Případ užití STORNOVAT OBJEDNÁVKU

24 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -11- Případ užití: Vytvořit Objednávku OPRAVIT ID: 5 Stručný popis: Systém podá zprávu o stavu provedení případu Vytvořit Objednávku Hlavní aktéři: Odběratel (zákazník, dealer, firma) Vedlejší aktéři: Žádní Vstupní podmínky: Uživatelské jméno + heslo Hlavní scénář: 1. Případ užití je spuštěn z menu systému volbou VytvořitObjednávku nebo z panelu ikon ikonou Vytvořit Objednávku Klient již pracuje ve svém prostředí, tedy byl přihlášen a přihlášení proběhlo bez závad. 2. Systém žádá zadání identifikace zákazníka (číslo čipové karty). Je-li vše v pořádku pokračuje se dál. Jinak se pokus o zadání třikrát opakuje a třetí neúspěšný pokus se oznámí a případ užití končí. 3. Systém vytvoří novou instanci Objednávky a přidělí ji identifikaci (čísloobjednávky, číslovlastníka, datumčaspřijetí). 4. Systém umožní vyplnit novou instanci Objednávky údaji, které zadává zákazník. 5. Systém vytvoří novou instanci Faktury a z vytvořené Objednávky systém vyplní údaji novou instanci třídy Faktura. 6. Systém vytvoří novou instanci Expedičního listu a z instance Objednávky instanci Expedičního listu vyplní. 7. Systém vytvoří novou instanci Prodejky a vyplní ji z údajů nové instance Faktury. Výstupní podmínky: xx Alternativní scénáře: Klient je vrácen do svého interface, poté se může ze systému odhlásit Relace aktérů k případu užití: Aktér Odběratel systému BODY- CARE případ užití spouští a musí zadat systému své uživatelské jméno a heslo. SEM VLOŽIT KOMUNIKAČNÍ DIAGRAM PRO: Případ užití VYTVOŘIT OBJEDNÁVKU

25 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -12- Fáze ROZPRACOVÁNÍ pro firmu BODY- CARE 10 Diagram tříd Jako ukázku sestrojíme diagram tříd pro balíčky Prodej a Přístup případů užití. Jako kandidáty tříd můžeme navrhnout především abstraktní podstatná jména, na kterých je postavena datová a aktivitní podstata všech případů užití ve zmíněných balíčcích. Pochopitelně, ke všem případům užití těchto balíčků musíme mít detailní popisy s hlavními scénáři, protože kandidáty na analytické třídy hledáme především ve zmíněných hlavních scénářích. Problematiku reklamace Objednávky zatím vynecháme. Po pozorném přečtení všech hlavních scénářů jednotlivých případů užití balíčků Prodej a Přístup, můžeme navrhnout tyto analytické třídy: Název třídy Zákazník Dealer Firma Odběratel Zboží Objednávka Faktura Expediční list Prodejka Asistent prodeje Řádek Faktury Řádek Objednávky Záznam registrace Účet zákazníka Bankovní transakce Stručný popis třídy Abstrakce všech drobných odběratelů Abstrakce všech dealerů, kteří jsou drobnými podnikateli a mají svou síť zákazníků Velkoodběratel kosmetických přípravků pro své zaměstnance a tuto službu pro ně organizuje Abstraktní třída pro třídy Zákazník, Dealer a Firma Kosmetický přípravek Seznam materiálových čísel objednaného zboží podle aktuálního měsíčního katalogu. Identifikace odběratele a Objednávky Na základě přikrytí Objednávky vytvořená Faktura pro Odběratele. Na základě Faktury vytvořený seznam zboží, které koncipuje expediční balíček Evidence jednotlivého prodeje zboží Zaměstnanec firmy BODY-CARE, který realizuje styk s odběrateli při reklamaci, resp. jiných přání/stížností odběratelů Kompoziční vazba řádků na mateřskou Fakturu Kompoziční vazba řádků na mateřskou Objednávku Údaje o provedené registraci Údaje o účtu zákazníka (login, password) Zákazníkův účet v bance, údaje s možností provedení transakce Opětovným čtením hlavních scénářů najdeme třídy, které podílí se na realizaci jednotlivých případů užití. Dokladem analýzy podílu je následující tabulka. Případ užití Vytvořit Objednávku Vytvořit Fakturu Vytvořit Expediční list Vytvořit Prodejku Proplacení Faktury Pokrytí Objednávky Stornovat Objednávku Autentizace, Registrace, Přihlášení se, Odhlášení se, Třídy, které se na případu podílí Odběratel, Objednávka, Řádek objednávky, Katalogy, Zboží Objednávka, Řádek objednávky, Faktura, Řádek faktury, Zboží Objednávka, Řádek objednávky, Expediční list, Řádek expedičního listu Faktura, Řádek faktury, Prodejka, Řádek prodejky Odběratel, Faktura, Řádek faktury, Bankovní transakce Zboží, Objednávka, Řádek objednávky Odběratel, Objednávka, Řádek objednávky, Faktura, Řádek faktury, Expediční list, Řádek expedičního listu, Prodejka, Řádek prodejky, Bankovní transakce Odběratel, Záznam registrace, Účet Odběratele,

26 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -13- Změna hesla, Změna uživatelského jména Administrátor Výsledkem prvotního přístupu k analytickým třídám balíčků Prodej a Přístup je následující diagram tříd. Záznam registrace 1 1 Účet odběratele 1 Odběratel 1 Asistent prodeje Bankovní transakce 1 Zákazník Dealer 1 0..* 0..* Objednávka 1 Firma Faktura 1 1 Expediční list * Řádek faktury Prodejka 1..* 0..* Řádek Objednávky * 1 Zboží Reklamace Objednávky Stručné vysvětlení sémantiky asociací tříd (pravidla firmy BODY-CARE): Odběratel nemusí vystavit žádnou, nebo vystaví více Objednávek Objednávka je seznamem zboží (bez cen) s uvedeným počtem Na řádku je uváděn jen jeden typ zboží, to samé zboží může být na vícero řádcích K Objednávce se vystavuje jediná Faktura K Objednávce se vystavuje jeden Expediční list (pouhý seznam zboží) S Fakturou souvisí jedna Prodejka Asistent prodeje může debatovat s Odběratelem o více Objednávkách Tento diagram můžeme ještě upravit, když analyzujeme asociace 1 : 1. Je zřejmé, jestliže se znehodnotí jedna Objednávka (např. je stornovaná), musí se znehodnotit z ní odvozená Faktura, Expediční list a Prodejka. Je proto opodstatněné zavést místo asociací 1:1 kompozice. V diagramu již neuvažujeme reklamaci. Záznam registrace 1 1 Účet odběratele 1 Odběratel 1 Asistent prodeje 1 Bankovní transakce Zákazník Dealer 1 0..* 0..* Objednávka 1 Firma Faktura 1 Expediční list 1 1..* Řádek faktury 1 Prodejka 1..* 1 1 Zboží 1 * Řádek Objednávky 1..* Řádek Expedičního listu 1..* Řádek prodejky

27 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -14- Druhý přístup k analytickým třídám vyžaduje upravit diagram tříd podle požadavků jazyka UML 2.0. Tedy, uvést relevantní atributy a operace. Podle hlavních scénářů všech případů užití balíčku Prodej a Přístup můžeme definovat následující relevantní operace a atributy. Výsledkem analýzy scénářů mohou být např. následující analytické třídy: Odběratel zavést() vyřadit() hledat() Zákazník osobníčíslo jméno adresa datumzavedení Firma ID-firmy název adresa kontaktníosoba datumzavedení zavést() vyřadit() hledat() Dealer osobníčíslo jméno adresa datumzavedení Zboží číslozboží název zásobakusy uskladnit() vyskladnit() Asistent prodeje označení zákazník datumjednání čísloobjednávky Objednávka čísloobjednávky datumčaspřijetí stav číslovlastníka množstvícelkem vytvořit() odeslat() vyhledat() stornovat() dejstav změnit() sumírovatpočet() Faktura číslofaktury datumvzniku zdanitelnéplnění číslovlastníka vytvořit() stornovat() vypočístfakturu() stornovat() vyhledat() Řádek faktury číslozboží názevzboží množství cenajednotka cenařádku vytvořitřádek() zrušitřádek() propočístřádek() stornovat() Expediční list vytvořitřádek() zrušitřádek() stornovat() vyhledat() Prodejka vytvořitřádek() zrušitřádek() stornovat() vyhledat() ŘádekObjednávky číslozboží názevzboží množství vytvořitřádek() zrušitřádek() stornovat() dátdetailřádku() Platební transakce stornovat() vyhledat()

28 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -15- Jak jsme atributy a operace našli? Pro každou třídu musím určit jaká informace je pro ni důležitá. Např. pro Objednávku: Skutečných reálně existujících papírových Objednávek je mnoho. Každou je potřeba identifikovat vlastním číslem (číslo Objednávky) a ještě číslem zákazníka (číslovlastníka). Je to nutné, protože tentýž zákazník může za jeden den podat např. pět Objednávek. Je rovněž důležité vědět, kdy byla Objednávka podána (datumpřijetí). Vzhledem k stavům Objednávky, v kterých se může nacházet (např. spí ve frontě, vyřízení bylo zahájeno, byly již vypracovány všechny dokumenty, dochází k vytvoření expedičního balíčku, je již splněna) je potřeba mít atribut na pamatování stavu (stav). Na druhé straně, operace této třídy musí zahrnovat aktivity, které musíme nad Objednávkou provést. Operací vytvořit() definujeme novou reálnou Objednávku a vypíšeme její záhlaví a zápatí. Všechny další operace, kromě dejstav() a sumírovatpočet(), pracují vlastně nad záhlavím a zápatím. Všímejme si, že Objednávka je silně svázána se svými řádky (kompozice s třídou ŘádekObjednávky). Tedy, každá instance třídy Objednávka musí obsahovat rovněž instance svých řádků. V každém z nich je vlastně určeno jisté zboží svým materiálovým katalogovým číslem a počtem kusů (číslozboží, názevzboží, množství). Nic více. Na vyplnění jednoho řádku použijeme operaci vytvořitřádek(). V důsledku kompozice nemusíme řádky identifikovat pomocí čísloobjednávky a ještě nějakého číslařádku. Všechny operace uvedené v třídě ŘádekObjednávky nám dávají zatím předpokládané a potřebné aktivity s řádky. Podobným způsobem můžeme osvětlit vznik atributů a operací pro každou třídu v balíčku Prodej a Přístup. Kompaktní diagram nakreslíme UML-editorem, např. ARGO 1 Realizace případů užití Prvně si musíme uvědomit, že pří tvorbě realizace konkrétního případu užití, tj. sekvenčního nebo komunikačního diagramu k tomuto případu užití, budeme muset doplňovat třídy operacemi a atributy. Někdy bude nutné i zavedení nové třídy. Jako ukázkový si vybereme jeden z případů užití Stornovat Objednávku a Vytvořit Objednávku. Co se musí v komunikačním diagramu provést? Odpověď je v hlavním scénáři případu užití. Sekvenční diagram pro případ užití Stornovat Objednávku:

29 Prof. RNDr. Milan Mišovič, CSc. Podpůrné studijní texty k předmětu BI-ZSI Problémová doména BODY - CARE -16-

30 Firma BODY-CARE Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Základy Softwarového inženýrství 1 Úvod Na českém trhu je několik dodavatelských firem, které poskytují zákazníkům celou řadu věhlasných kosmetických přípravků. Stačí jmenovat dvě, které na českém trhu s kosmetikou vévodí. Jsou to ORIFLAME a AVON LADY. My chceme modelovat virtuální firmu, která je v aktivitách podobná zmíněným zavedeným firmám. Naši virtuální firmu pojmenujeme BODY- CARE. Firma BODY- CARE je situována v Praze, kde má vedení a centrální sklad. Filiálky firmy jsou téměř ve všech krajských městech. Vzhledem k velké samostatnosti jednotlivých filiálek je komunikace mezi centrem v Praze a filiálkami redukována jen na tok zboží z centrálního skladu do skladů filiálek a na tok finanční. Každá filiálka pracuje samostatně. Předmětem naší komputerizace bude právě filiálka, bez ohledu na její rezidenci. Označení filiálka již nebudeme dále používat, zůstaneme u názvu BODY- CARE, ovšem komunikaci s centrem si budeme všímat rovněž. Před námi stojí dva úkoly: 1. Sestavit verbální business deskripci problémové domény BODY-CARE. 2. Uplatnit objektovou metodiku UP (Unified Process) pro produkci zmíněné softwarové aplikace ke komputerizaci domény BODY-CARE. Řešení každého z úkolů umístíme do samostatného souboru. Zde naplníme požadavek business deskripce pro firmu BODY-CARE. Business deskripce firmy byla sestavena podle obsahu interview s ředitelem firmy a vedoucími jednotlivých oddělení. 2 Verbální business deskripce domény BODY-CARE Firma má celkem asi 30 zaměstnanců, jejichž zaměstnaneckými pozicemi jsou: Ředitel firmy Vedoucí oddělení Pracovník oddělení-specifická pozice Firma má několik oddělení: Finančně ekonomické Personální Oddělení prodeje Oddělení skladu a expedice Oddělení marketingu a péče o zákazníka Kolegium vedení firmy je složeno z ředitele a vedoucích jednotlivých oddělení. Vzhledem k tomu, že business problematika firmy je docela široká, soustředíme se na komputerizaci aktivit a zpracování dat jen na dvě oddělení: Oddělení prodeje, Oddělení skladu a expedice, Oddělení marketingu a péče o zákazníka.

31 Firma BODY-CARE Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Základy Softwarového inženýrství V každém z těchto oddělení probíhají procesy, které budeme komputerizovat tak, že pro každé oddělení napíšeme aplikace, a nakonec můžeme aplikace dát do jednoho celku Cílový software firmy BODY- CARE. Firma nemá žádné dopravní prostředky, styk se zákazníky je interaktivní v budově firmy. V prvním poschodí budovy firmy je situováno prodejní místo (pět prodejních boxů), expediční sklad a prostor pro zákaznické boxy (asi 5 zákaznických boxů). Zákaznické boxy umožní zákazníkům překontrolovat obsah expedičního balíčku podle Expedičního listu, který je do balíčku přidán. Přístup k prodejním boxům je řízen pomocí lístkového automatu spojeného s vizuálním systémem. Firma rozlišuje několik typů zákazníků: drobný odběratel (zákazník), odběratel-firma, odběratel-dealer. Prodej zboží, styk se zákazníkem Firma má připravenou papírovou zákaznickou Objednávku zboží, která identifikuje zákazníka (pomocí čísla jeho čipové karty) a má ještě své vlastní číslo Objednávky zboží. Názvy a materiálová čísla zboží jsou uvedena v katalogu, jehož nové číslo vydává oddělení marketingu na nový prodejní měsíc. Prodej je tedy orientován podle tohoto katalogu na jeden měsíc. Zákazník vyplní papírovou Objednávku a osobně předá v jednom z boxů prodejního místa. Prodejní asistentka prověří správnost materiálových čísel a zjistí možné pokrytí objednávky skladem firmy a vytvoří elektronickou Objednávku. Na základě pokrytí je vypracován Expediční list zboží pro sklad a expedici a rovněž Faktura, kterou zákazník ihned proplatí a převezme. Druhý originál Faktury je odeslán na Finančně ekonomické oddělení. Prodejní oddělení si vytváří Prodejku, na které je prodejce, zboží, datum, čas, Všechny tyto aktivity se musí komputerizovat. Procesy: Tvorba elektronické Objednávky. Zpracování Objednávky + tvorba Faktury a Expedičního listu. Sestrojení Prodejky. Zápisy do báze dat Oddělení marketingu a péče o zákazníka Oddělení eviduje zákazníky a posílá zákazníkům propagační materiály: Katalogy zboží, informace o životě firmy, propagace největších odběratelů, přiřazování bonifikací Procesy: Vedení seznamu zákazníků, operace nad zákazníky (zavedení, vyřazení, modifikace). Sestrojení báze dat, ve které jsou zákazníci, jejich Objednávky, k nim náležící Faktury, Expediční listy. Operace vyhledávání a vyhodnocování zákazníků, přiřazení bonifikační slevy

32 Firma BODY-CARE Prof. RNDr. Milan Mišovič, CSc Podpůrné texty k předmětu Základy Softwarového inženýrství Expedice Pracovníci skladu připraví podle Expedičního listu expediční balíček objednaného kosmetického zboží. Vizuální systém, který je v zákaznických boxech, upozorní zákazníka na již hotový expediční balíček a zákazník přikročí k jeho vyzvednutí ve výdejním místě. Expediční balíček je vybaven Výdejkou, jejíž druhý originál zůstává v Oddělení skladu a expedice. Procesy: Vytvoření balíčku podle Expedičního listu. Vytvoření Výdejky Zápis do báze dat. 3 Pokyny Komputerizaci provádí tři týmy: První tým (3 studenti) procesy Prodej zboží styk se zákazníkem. Druhý tým (4 studenti) Oddělení marketingu a péče o zákazníka a Expedice Aplikace konstruujte tak, aby se daly později spojit do jednoho celku. Oba dva týmy sestrojí požadovaný elaborát sestavený z fází metodiky UP. Vzorem pro elaborát je Evidence zbraní na teritoriu České republiky.

33 VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky SOFTWAROVÉ INŽENÝRSTVÍ ČÁST I. SOFTWARE A SOFTWAROVÉ INŽENÝRSTVÍ STUDIJNÍ TEXT PRO KOMBINOVANOU FORMU STUDIA Milan Mišovič 2011

34 Prof. RNDr. Milan Mišovič, CSc. SOFTWAROVÉ INŽENÝRSTVÍ 1. vydání Vydala Vysoká škola polytechnická Jihlava, Tolstého 16, Jihlava, 2011 Tisk Ediční oddělení VŠPJ, Tolstého 16, Jihlava Za jazykovou a věcnou správnost obsahu díla odpovídá autor. Text neprošel jazykovou ani redakční úpravou. Milan Mišovič, 2011

35 Obsah Část I. Software a Softwarové inženýrství 1 Úvod do Softwarového inženýrství Obecné cíle kurzu Softwarového inženýrství Definice SWI a historie jeho vzniku Úvod Začátky zpracování informace Programování a jeho vývoj Softwarové inženýrství Historické etapy ve vývoji SWI Software a typy software Pár vět k vývoji software Softwarový proces Základní modely softwarových procesů Vodopádový model Fontánový model Přírůstkový model Prototypový model (Prototyping Life Cycle) Stručné zhodnocení modelů softwarového procesu Zopakování relevantních termínů Formalizace software Klasické sekvenční programování Rozsáhlý softwarový systém Objektové programování Obecné vlastnosti vývoje software Modelování softwarových systémů (Software system modeling) Literatura... 34

36 Část I. Software a Softwarové inženýrství Učební cíle: Seznámit se 1. s historií zpracování informace, vývojem programovacích jazyků, 2. s koncepcí softwarového inženýrství, 3. s různými typy software a jejich vlastnostmi. Znát 1. podstatu charakteristických etap ve vývoji SWI. 2. Charakteristiku SWI pro současnou dobu. 3. Podstatu jednoduchých programů a Rozsáhlých programových systémů. Umět, mít dovednosti 1. Charakterizovat jednotlivé vlastnosti sekvenčního a objektového jednoduchého programu. 2. Vidět hranici mezi jednoduchými programy a rozsáhlými softwarovými systémy. 1 Úvod do Softwarového inženýrství Vážení čtenáři-studenti. V první chvíli jsem chtěl své přednášky pro předmět Softwarové inženýrství koncipovat jen na platformě současného stavu dlouhodobého rozvoje tvorby počítačových programů 1 (computer programs) a neohlížet se zpět. Po chvilkovém zamyšlení jsem ale naznal, že krátké ohlédnutí se k době počínaje rokem 1950 a konče rokem 2010 jistě pomůže pochopení současně dominujícího přístupu k tvorbě počítačových programů. Začal jsem programovat v roce 1963 a tedy tvořit sekvenční programy 2 a dosáhl v roce 1980 vrcholu ve své tvorbě produkcí rozsáhlejších programů se zpracováním souborů 3. Záhy jsem opustil zpracování souborů a přešel na zpracování relačních bází dat 4. V tomto zpracování jsem dosáhl svého vrcholu asi v roce Můj metodický přístup v tvorbě počítačových programů, později aplikací 5 a rozsáhlejších programových systémů 6 - RPS (Software systems), byl založen na strukturovaném přístupu. Ve všech fázích vývoje počítačových programů jsem používal charakteristické vlastnosti tohoto přístupu, které byly obsaženy v metodách, technikách a nástrojích mnou používaných strukturovaných metodikách vývoje 7. Strukturovaný přístup byl komplexně dopracován do tzv. strukturovaného paradigmatu 8 a koncem devadesátých let se již žádné nové relevantní poznatky neočekávali. Dominantnost strukturovaného přístupu se ale začala pozvolna ztrácet v devadesátých létech 1 Konečná posloupnost strojových instrukcí, nebo příkazů programovacího jazyka 2 Provádění příkazů počítačového programu je sekvenční, tj. provádění příkazů jeden po druhém, ačkoliv je možné pomocí příkazu IF plnění částečných sekvencí přerušovat 3 Soubor je konečná posloupnost záznamů, které mají stejnou strukturu svých datových položek (homogenní soubory) 4 Množina dat členěná na tzv. datové tabulky, mezi nimiž jsou datové asociace (fyzická rovina) 5 Aplikace je programové dílo, složené z jednoho nebo více počítačových programů a několika pomocných souborů 6 Rozsáhlý programový systém je programové dílo, složené z více počítačových programů, mezi kterými jsou specifické systémové vazby 7 Za svou nejoblíbenější jsem považoval SSADM metodiku, vhodnou i pro rozsáhlé programové systémy. Pro ČR ji školila firma LBMS ČR 8 Strukturované paradigma představuje filosofii tzv. strukturovaného přístupu k tvorbě software -4-

37 a v průběhu posledního desetiletí byla nahrazena dominancí přístupu objektového 9. Tento nový pohled na realitu světa a jeho dílčí problémové domény, přinesl pochopitelně zásadní změny v používaných metodách, technikách a nástrojích vývoje počítačových programů obsažených v nových objektových metodikách. Nový pohled se postupně zrodil v hlavách informatiků (J. Martin, E. Yordon, P. Coad, J.Rambaugh, I. Jacobson, G. Booche a další), kteří dlouhá léta tvořili počítačové programy pod vlivem strukturovaného paradigmatu, postupně úspěšně pochopili jeho negativa a pozitiva a dokázali vytvořit paradigma objektové. Některé z pozitiv byly přeneseny do nového objektového paradigmatu (např. podstata datových asociací mezi typovými datovými entitami, strukturovaný rozklad problémové domény na podřízené subjekty, ) a vidíme je tam dodnes. Podobně jako ve vývoji strukturovaného přístupu, došlo i v rámci objektového přístupu k sjednocení metod, technik a nástrojů mezi četnými objektovými školami a jejich formálními a grafickými notacemi. Celý vývoj přístupů k tvorbě počítačových programů, aplikací a rozsáhlých programových systémů ukázal, že je nutné tvořit inženýrským stylem a znovu používat již vytvořené programy jako komponenty rozsáhlejších programových systémů. Získané poznatky se postupně hromadily a vznikla disciplina s názvem Softwarové inženýrství, do které byly vloženy. Náš kurz Softwarového inženýrství bude postaven na krátkém úvodu a potom zcela na vývoji software v objektovém paradigmatu na jedné vybrané objektové metodice (veřejná varianta metodiky RUP Rational Unified Process, firmy Rational, pod názvem UP Unified Process). Kurz bude mírně zjednodušen pro fázi Zavedení (Transition), i když k tomu podá jisté návody. Kurz se soustředí především na fáze Zahájení (Inception), Rozpracování (Elaboration), s používanými pracovními postupy požadavky, analýza a návrh a nakonec na fázi Konstrukce (Construction) s produkcí cílového software ve vybraném zdrojovém kódu. Než ovšem začneme zkoumat a využívat metodiku UP, bude nutné pohovořit si o obecně platných poznatcích týkajících se softwarových systémů, nezávislých na vybraném paradigmatu. 2 Obecné cíle kurzu Softwarového inženýrství Kurz Softwarové inženýrství (SWI), je určen pro pochopení discipliny Softwarové inženýrství, získání základních dovedností v analýze a návrhu programů, seznámení s používanými technikami a nástroji. Kurz sleduje základní životní cyklus programového díla, od popisu problémové domény a specifikace požadavků, přes návrh řešení až po vlastní produkci kódu, provoz a údržbu. Důraz je kladen především na analytickou fázi, neboť ostatní fáze jsou součástí jiných předmětů s tématikou programování (vlastní produkce programového díla). Modelovacím prostředkem je UML (Unified Modeling Language). Předmět zahrnuje i úvod do technologie návrhu uživatelského vzhledu. Přidaná hodnota: Studenti se naučí porozumět formalizovaným zápisům analytických a návrhových modelů v jazyku UML. Částečně si vyzkouší i tvorbu těchto modelů ve cvičení, kde řeší menší projekty v týmech. Mají být schopni nad těmito modely kvalifikovaně diskutovat s ostatními členy softwarového týmu. Tyto zkušenosti a dovednosti umožní absolventům kurzu SWI se v praxi do takového týmu efektivně začlenit. Témata studijních materiálů: Úvod do discipliny Softwarové inženýrství : vznik, historie, směry, paradigma, pojetí 9 Objektový přístup je základem filosofie objektového paradigmatu k tvorbě objektového software -5-

38 software (relevantní pojmy). Stručně o výsledcích strukturovaného paradigmatu: modelování reality, relevantní diagramy, sekvenční programování, vývoj a metodiky, komputerizace vývoje 10 klasického sekvenčního software 11, nástup objektového paradigmatu. SWI a objektový přístup: modelování reality, relevantní diagramy, objektové programování, vývoj a metodiky, komputerizace vývoje objektového software. Nástup jazyka UML grafická deskripce výsledků objektových metodik. Úvod do jazyka UML, verze 1.0 a pokročilejší verze 2.0. Metodiky UP (Unified Process), MDA (Model Driven Architecture). Požadavky a jejich modelování pomocí případů užití, modelování aktivit. Case nástroje, pokročilé modelování případů užití, balíčky. Analýza hledání atributů a stavů, relace, dědičnost, polymorfismus, integritní omezení, OCL, sekvenční diagram, diagram komunikace. Návrh návrhové třídy, použití návrhových vzorů, upřesňování analytických relací. rozhraní, komponenty a diagramy časování. Implementace diagramy nasazení. Protože náš kurz je jednoznačně orientován na metodiku tvorby počítačových programů, počítačových aplikací, rozsáhlých programových systémů a dokumentace k nim, můžeme používat rovněž termínů software (programové dílo/programové vybavení a dokumentace k němu), softwarová aplikace/aplikace (programová aplikace a dokumentace k ní), rozsáhlý softwarový systém/softwarový systém (rozsáhlý programový systém a dokumentace k němu). Nejčastěji se používají termíny software a softwarový systém. Softwarové inženýrství SWI (Software Engineering - SWE) je v současnosti považováno především za velmi užitečnou metodickou disciplinu, která v průběhu svého vývoje neustále sledovala několik základních cílů: 1. maximálně zjednodušit tvorbu software, 2. zavedení automatizace do tvorby software, 3. zlepšování spolehlivosti software, 4. zavádět do tvorby software inženýrské přístupy, 5. postupná orientace na tvorbu rozsáhlých softwarových systémů a její zabezpečení, 6. reagovat na využití nejnovějších informačních technologií pro zpracování informací, 7. orientace na urychlení vývoje software a efektivního řízení vývoje. Pochopitelně, jednotlivé cíle se dařilo naplňovat postupně v kontinuitě s vlastním vývojem informačních technologií. Jestliže za raných dob byla orientace SWI na jednoduché 10 Jde o výpomoc vlastní tvorbě programového díla pomocí speciálních programů, označovaných CASE (Computer Aided Software Engineering) 11 Software je podle (Sommerville, 2010, str. 6) programové dílo (počítačový program, programová aplikace, rozsáhlý programový systém) spolu s dokumentací k němu -6-

39 programy, tak později se pozornost přenesla na aplikace a rozsáhlé programové systémy s jejich členěním na dynamické komponenty. Poznámka V předchozích odstavcích jsme použili neznámé termíny: automatizace, spolehlivost, inženýrský přístup, Všechny termíny objasníme postupně v následujících textech. Pokud budeme diskutovat vlastnosti jednoduchého programu, aplikace, nebo rozsáhlého programového systému, tak tyto termíny budeme důsledně používat. Někdy budeme mluvit o kusech kódu a budeme tím myslet posloupnosti, které nejsou organizovány do známých celků jimiž jsou procedura, funkce, webový skript,..., jed. program, aplikace, rozsáhlý programový systém. Již v předchozím textu jste si všimli jistá porušování grafických zásad, např. zmenšení textu pro uzávorkované vysvětlivky, využití barev, Chápejte, že předkládané učební texty nemají publikační charakter, jsou to pouhé vzdělávací pomůcky a porušování zmíněných zásad je využito k zvýšení jejich vizuálního účinku. 3 Definice SWI a historie jeho vzniku Cíl: Znát (umět vysvětlit): Základní cíle Softwarového inženýrství (SWI). Podstatu jednotlivých etap vývoje SWI, zejména současnou etapu. Pojetí softwarové krize. Seznámit se S přehledem implementace a vývoje počítačů na teritoriu Čech-Moravy a Slovenska. S pojetím Turingova stroje a číslicového počítače. S vývojem programování a programovacích jazyků od assembleru až po současné programovací jazyky. S pojetím Softwarového inženýrství. Klíčová slova: Počítač, strojová instrukce, zdrojový kód, sekvenční počítačový program, software, Softwarové inženýrství, vývojová metodika, strukturované a objektové paradigma, objektové programy 3.1 Úvod Zopakujme již vyslovenou charakteristiku softwarového inženýrství. Softwarové inženýrství SWI (Software Engineering - SWE) je v současnosti považováno především za velmi užitečnou metodickou disciplinu, která v průběhu svého vývoje neustále sledovala několik základních cílů: 1. maximálně zjednodušit tvorbu software, 2. zavedení automatizace do tvorby software, 3. zlepšování spolehlivosti software, 4. zavádět do tvorby software inženýrské přístupy, 5. postupná orientace na tvorbu složitých programových systémů a její zabezpečení, -7-

40 6. reagovat na využití nejnovějších informačních technologií pro zpracování informací, 7. orientace na urychlení vývoje software a efektivního řízení vývoje. Pochopitelně, jednotlivé cíle se dařilo naplňovat postupně v kontinuitě s vlastním vývojem informačních technologií. Jestliže za raných dob byla orientace SWI na jednoduché programy, tak později se pozornost přenesla na aplikace a rozsáhlé programové systémy s jejich členěním na dynamické komponenty. Podívejme se teď na celou cestu, kterou SWI dosud vykonalo a na to čeho bylo v průběhu této cesty dosaženo. 3.2 Začátky zpracování informace Začátky strojového zpracování informace na našem teritoriu spadají do padesátých let a velmi těsně souvisí s Kybernetikou. Tehdejší politická a společenská atmosféra nikterak nebyla vlídná k disciplině Kybernetika (CYBERNETICS), která se zabývala jak potřebnou teorií, tak i praxí zpracování informace. Ačkoliv byla Kybernetika tehdejším politickým vedením československého státu označována za buržoázní pavědu, přesto její poznatky pronikly i do československých výzkumných ústavů a vysokých škol. Na území Československa byl v létech téměř hlavním nositelem vývoje výpočetní techniky Výzkumný ústav matematických strojů (VÚMS) v Praze, Loretánské náměstí. Tým, vedený Doc. A. Svobodou postupně navrhnul počítač SAPO (1956, realizovaný na dvoustavovém prvku relátko) a nakonec v roce 1963 EPOS 1, který po značné změně přešel na EPOS 2. Pod označením ZPA-600 byl tento počítač již v roce 1968 vyráběn a dodáván zájemcům. Na vývoji základního software počítače ZPA-600 jsem se podílel v době mé základní vojenské služby ( ) v tehdejším Výzkumném ústavu matematických strojů (VÚMS Praha, Loretánské náměstí). Pochopitelně, historie dovozu a používání počítačů na teritoriu Československa byla pestřejší, zmínil jsem se stručně jen o našem vlastním vývoji. V roce 1957 dovezen ZUSE počítač z NSR, výroba děrovače děrné pásky Aritma, 1961 koupen americký počítač LGP-30, ruský Ural, 1962 koupen francouzský počítač GAMA, britský Sirius, 1964 dovezeno více kusů ruského počítače Minsk 2, později Minsk 22,. Vraťme se teď ke Kybernetice. Kybernetika chápala informaci jako údaje/data s přesně stanoveným významem, který byl definován prostředím, ve kterém informace vznikaly a pro které se zpracovávaly. Kybernetika již tušila, že stěží tak rychle přinese pro lidstvo stroje schopné chápat a zpracovávat informaci jako takovou. To byly ještě příliš vysoké požadavky na inteligenci zmíněných strojů. Mimo jiné, chápat význam informace nedokážou ani současné počítače. Na rozdíl od tohoto velmi vzdáleného cíle, Kybernetika viděla možnost přinést teoretické a později i provozuschopné stroje, které by sice nechápaly význam dat (tedy nikdy by nepracovaly s informacemi, ale s daty), ale způsoby zpracování by jim bylo možné vtisknout z vnějšku a obejít tak vysoké požadavky na vnitřní inteligenci strojů. Je to pochopitelné, protože Kybernetika tenkrát vůbec netušila na čem vystavět funkcionální inteligenci strojů, která by byla tak potřebná (dnes to již kybernetika ví jsou to neuronové sítě) k realizaci algoritmů. Algoritmy se staly hnací silou v úsilí o strojové zpracování dat. Byly schopné zpracovat výchozí data X a vedle toho vyprodukovat výsledná data Y. Práce s algoritmy a jejich realizací pomocí strojů se rapidně rozvíjela již počátkem 20. století a v jeho půlce doznala významných výsledků. Nejzávažnější výsledky byly dosaženy nejen v oblasti teorie algoritmů, ale i v návrhu strojů k jejich zpracování. Jedním z nich je Turingův stroj. Britský matematik Allan Turing v roce 1937 hledal výpočetní stroj založený na konečných automatech. Ve svém bádání takový stroj navrhnul a dokázal, že je to nejsilnější univerzální výpočetní stroj. Turingův stroj je vybaven nekonečnou vnější pamětí (více pásek) a je schopen v jisté podobě přijmout algoritmus A, výchozí data X a provést realizaci algoritmu po stanovených krocích a tak vyrobit výsledná data Y. Tento stroj byl schopen realizovat zobrazení X na Y, tedy A (X) Y. -8-

41 Turingův stroj neměl vnitřní řízení, byl kombinací konečného automatu a vstupních a výstupních pásek. Významnou záležitostí byla forma, ve které do stroje vstupoval algoritmus, data X a ze stroje vycházející data Y. Princip této formy byl založen na obecně platném způsobu kódování kroků algoritmu a znaků dat X a Y pomocí binárních číslic. Algoritmus A Data X Turingův stroj Data Y Obrázek 3-1: Hrubá struktura Turingova stroje. Koncem 30. let přišel americký kybernetik Von Neuman (maďarského původu) s koncepcí číslicového počítače, která byla nejen jednou z možných realizací Turingova stroje, ale zavedla i pojem a vlastnosti vnitřní paměti a vnitřního řízení stroje. Bylo ale ukázáno, že takový počítač nepřekročil schopnosti Turingova stroje a byl pouze jednou z jeho praktických realizací. Dnes je vlastně každý počítač univerzálním výpočetním strojem v duchu Turingového stroje. Připomeňme si teď Von Neumanovu koncepci číslicového počítače. Definice 3-1 Počítač je stroj, který má vnější pásku pro vstup dat X a vstup algoritmu A, dále má vnější pásku pro výstupní data Y. Algoritmus je v podobě tzv. programu ve strojových instrukcích uložen ve vnitřní paměti počítače. Strojové instrukce jsou prováděny procesorem s řadičem, který organizuje provedení aktivit zakódovaných ve strojových instrukcích. Aritmetické instrukce jsou prováděny v aritmetické jednotce nad daty uloženými v operační paměti počítače a výsledky jsou opět ukládány do operační paměti. Počítač má strojové instrukce pro vstup/výstup dat, pro aritmetické a logické operace umožňující měnit pořadí provádění instrukcí. Počínaje rokem 1940 vznikají první zkušenosti s použitím počítačů (počítače Mark I - USA). Informace uložené v datech X a Y jsou kódovány binárně, později osmičkově a šestnáctkově. Je pochopitelné, že jejich reálné čtení bylo obtížné, musel být prováděn převod do desítkové číselné soustavy. Rovněž kódování algoritmu do strojových instrukcí bylo namáhavé. Opět bylo možno použít jen číselné soustavy o základu 2. Rodina uživatelů počítačů nebyla příliš početná a převažovalo využití počítačů výhradně k vědeckotechnickým výpočtům. Sekvence strojových instrukcí, zapisujících algoritmus A, se začala nazývat počítačovým programem a proces tvorby zmíněné sekvence programováním ve strojovém kódu. Sekvenční charakter programování se stal typickým pro dlouhou dobu využívání počítačů. Programování, tj. proces zápisu algoritmu ve strojových instrukcích, se stalo základem všestranného využití počítačů. Proto bylo možné prostřednictvím programu, který byl počítač schopen provádět, převést počítač do role jiného stroje, přístroje, obecně do role provádění jakékoliv aktivity, jejíž algoritmus bylo možné zapsat do programu. Pochopitelně, program byl počítačem prováděn sekvenčně po jednotlivých instrukcích a změnu pořadí prováděných instrukcí bylo možné realizovat jen použitím logických a skokových instrukcí. Tyto možnosti předurčily počítače k všeobecnému použití. Vzhledem k tomu, že se neustále zvyšovaly objektivní požadavky na širší použití počítačů ve společenském životě, v oblasti -9-

42 řízení, ve vědě a výzkumu, to vedlo nejen ke zkvalitnění možností programování, možností prezentace informace (číselné, grafické, mediální) a stroje jako celku (vnitřní paměť, vnější paměti, procesor, aritmetická jednotka, ), ale způsobilo to především prosazení objektivního trendu vývoje počítačů a užitečných programů s orientací na širokou veřejnost. 3.3 Programování a jeho vývoj Podle Von Neumanovy koncepce a binární povaze základu pro bity 0 a 1, bylo potřeba rovněž strojové instrukce vyjádřit binárně. Velikost v počtu bitů na strojovou instrukci byla dána jednotkou operační paměti, která byla adresovatelná. Na obrázku uvedená první struktura instrukce je nejnázornější, ale později již nepoužívaná. Důvodem bylo zavedení registrů a velmi krátkých jednoadresových a registrových operací. OK ADRESA 1 ADRESA 2 ADRESA 3 ( ADRESA 1 Operace ADRESA 2 ) ADRESA 3 OK Register ADRESA ( Register Operace ADRESA ) Register OK Register Register ( Register Operace Register ) Register Obrázek 3-2: Tři z nejčastěji používaných typů strojových instrukcí. U současných počítačů se počet instrukcí pohybuje kolem 200 a jsou rozděleny do mnoha skupin podle operačního kódu (logické, aritmetické skokové, vstupní a výstupní, ). Program, zapsaný ve strojových instrukcích, byl velmi nečitelný a více pochopitelný až po převodu např. do osmičkového kódu. Jaké byly zásady, jimiž se programátoři řídili? 1. Optimalizovat program na co nejmenší počet strojových instrukcí. Tento požadavek byl důsledkem malé operační paměti prvních počítačů. Tato zásada vedla k tomu, že mnohé buňky operační paměti se používaly vícekrát (s jiným významem) a mnohokrát se rovněž přepisovaly instrukce. Často potom program po svém chodu byl zcela změněn a musel být před dalším spuštěním znovu nahrán do operační paměti počítače. Automatická obnova programu do původního stavu totiž vyžadovala přidat k němu další strojové instrukce. 2. Najít pro jednoduchý informační problém co nejoptimálnější algoritmus A, vedoucí na minimální počet strojových instrukcí. Tato snaha vedla k nacházení více algoritmů A 1, A 2,, A n, které pro tentýž jednoduchý informační problém (většinou numerické povahy, např. výpočet kořenů kvadratické rovnice) splňovaly požadavek zobrazení X Y. Z těchto algoritmů se potom vybral ten, který vedl na program s nejmenším počtem strojových instrukcí, tj. A = opt (A 1, A 2,, A n). -10-

43 3. Připravit optimální rozvržení operační paměti pro data X, Y a samotný program. Postupně bylo jasné, že tomuto rozvržení musel programátor věnovat patřičnou pozornost, chtěl-li získat vícenásobné použití každé paměťové buňky a tak snížit rozsah operační paměti pro data X, mezivýsledky a data Y. Takto ušetřené buňky mohl potom věnovat na další instrukce programu. Úspěšný potom byl ten programátor, který vynikal perfektní znalostí strojových instrukcí a byl schopen v programu realizovat užitečné triky, a který současně dovedl analyzovat jednoduchý informační problém a nalézt k němu optimální algoritmus (analytická práce). Pochopitelně, v této pionýrské době nebyla analytická a programátorská práce ještě oddělována tvořila jednotný postupový celek. Programování se ovšem vyvíjelo dál. Strojové instrukce začaly být považovány ne za ten nejvhodnější nástroj tvorby programů. Náročná znalost bitových kombinací pro OK a adresy byla postupně nahrazena jejich symbolickými zápisy. Vznikl tak nový programovací jazyk Jazyk symbolických adres - JSA, který obsahoval symbolické operační znaky a symbolické adresy. Program potom musel být přeložen do strojových instrukcí a to je doba vzniku PŘEKLADAČŮ. Programování ovšem již bylo přehlednější, rozvrh operační paměti snadnější a bylo umožněno sestavovat i rozsáhlejší programy z dílčích celků - podprogramů. Velmi brzo byla, tedy do JSA, zavedena možnost psát podprogramy, které se daly opakovaně využívat. Jejich spojování s hlavním programem potom řešil tzv. spojovací program, který spolu s JSA, vytvářel programovací systém ASSEMBLER. Tyto systémy dodnes nezanikly, protože mají nejblíže ke strojovému kódu počítače, čehož se využívá k sestrojení programů pro četné čipové procesory prostřednictvím emulátorů. Programování ve strojových nebo v symbolických instrukcích mělo své charakteristické rysy odpovídající plně stavu a využití výpočetní techniky. Narozdíl od strojového kódu, bylo programování v Jazyku symbolických adres hbitější s možností použití jednoduché adresní aritmetiky (sčítání/odčítání v adresní části symbolických instrukcí) a podprogramů. Účinného zlepšení se dosáhlo zejména v jednoduchosti rozvržení operační paměti a relativnosti uložení programu a zpracovávaných dat. Příklad 3-1 Tento příklad uvádí jednoduchý program v assembleru, který porovnává dvě čísla a, b a vytiskne rozhodnutí. návěští SOZ registry adresová část poznámka A B RDATA RDATA READ READ PRINTL PRINTL A B ="číslo A=", A ="číslo B=", B LOAD 1 A LOAD 2 B SUB 1 B a-b GREAT 1 NE1, ANO1 NE1 SUB 2 A b-a GREAT 2 NE2, ANO2 NE2 PRINTL ="A,B jsou stejné" STOP ANO1 PRINTL ="A větší než B" STOP ANO2 PRINTL ="B větší než A" STOP -11-

44 Již na zápisu algoritmu pro max (a,b) v assembleru, je vidět ten ohromný skok ve způsobu programování vzhledem k strojovému kódu. Co bylo na programování v těchto dvou jazycích to nejobtížnější? není to znalost strojových nebo symbolických instrukcí, v tom se získala velmi rychle jistá a potřebná rutina, obtížná ovšem byla komputerizace kroků algoritmu, tj. vyjádření kroků algoritmu pomocí strojových nebo symbolických instrukcí ve spojení se zpracováním dat. V průběhu celé pionýrské doby ( ) se žádná obecná pravidla, žádný inženýrský přístup k tvorbě programů neujaly. Na druhé straně ale nemůžeme tvrdit, že mnozí z programátorů neměli svůj styl programování. Dokonce podle stylu bylo možné programátora identifikovat. Za styl byl považován jistý souhrn atributů tvorby strojových nebo symbolických programů, např.: obliba v používání stejných instrukcí nebo jejich sekvencí pro často se vyskytující aktivity v programu (dotazy, skoky, vstupy/výstupy, ) postup ve využívání registrů, způsob rozvržení programu (kam dát deklarace dat, kam operační část programu), způsob používání podprogramů, tvorba programu na základě vzorů-koster pro mnohé aktivity, Ačkoliv symbolické adresy a na nich vzniklé programovací systémy ASSEMBLERY usnadnily programování, brzy byly nahrazeny prvními tzv. vyššími programovacími jazyky: ALGOL, FORTRAN IV a 77, PL/1, Pascal, Tyto jazyky a programovací systémy na nich založené, značně zautomatizovali překlad programu a rovněž samotný zápis programů. Podprogramy z Assembleru se staly formou, do které se překládaly nové programové jednotky nazývané procedury. Napsat velmi schopné překladače k těmto jazykům umožnil vznik TEORIE FORMÁLNÍCH JAZYKŮ a GRAMATIK. Detaily této teorie se probírají ve specializovaném předmětu. Nové programovací jazyky, které značně oddálily programátora od strojového kódu, vyvolaly změny v tvorbě programů, které podporovala i samotná praxe jejich využití. Programy, které představovaly počítačovou podporu pro mnohé aktivity (tzv. komputerizace aktivit), musely být později modifikovány, rozšiřovány a často postaveny na nové struktuře. Tento proces vyvolal bádání informatiků nad samotnými programy a způsoby jejich tvorby. Již v roce 1963 se ukazuje, jak je zhoubné pro čitelnost programu časté používání příkazu GOTO. Poukazuje se, že by měly existovat obecně doporučované myšlenkové postupy a inženýrské technologie pro tvorbu programů. Rovněž došlo ke změně v pohledu na data a jejich zabalení do jistých datových struktur. Jinými slovy, velmi důsledně byly v 60. až 80. létech rozebírány etudy vlastní programátorské práce. Vznikla disciplina SOFTWAROVÉ INŽENÝRSTVÍ, která již dávala návody na ty vhodnější inženýrské postupy tvorby programů. Velmi přísně se již stanovují podmínky na kvalitu programů a rozlišují se již metody programování, techniky a samotné prostředky-nástroje. Neustále je nutné chápat zmíněné programování jako sekvenční zápis příkazů daného jazyka a rovněž jejich sekvenční provádění, které nemuselo souhlasit s polohou příkazů. Termín sekvenční programování se pro klasické programování používá dodnes. Vedle toho se rozvíjí pojetí datových struktur kontejnerů pro data. Vývoj začíná od elementárních datových struktur a končí na bázích dat. Mezi oběma krajními póly je -12-

45 ale mnoho velmi užitečných datových struktur (proměnná, konstanta, pole, seznam, výčet, tabulka, fronta, zásobník, soubor, ) používaných v programech. Vše postupně vedlo k tomu, že JIŽ NEŠLO O TO UDĚLAT HVĚZDNÝ PROGRAM, ALE PROGRAM, KTERÝ BUDE STAVEBNĚ STRUKTUROVANÝ, PŘEHLEDNÝ A ČITELNÝ V ŘÍDÍCÍCH A DATOVÝCH STRUKTURÁCH A TAKÉ SNADNO MODIFIKOVATELNÝ A SPOLEHLIVÝ. Obsah použitých atributů programu (strukturovaný, přehledný-čitelný, modifikovatelný, spolehlivý) se postupně vyjasňoval a v praxi implementoval. 3.4 Softwarové inženýrství JEŠTĚ DO KONCE 60. LET BYLO PROGRAMOVÁNÍ POVAŽOVÁNO ČÁSTEČNĚ ZA VĚDU A ČÁSTEČNĚ ZA UMĚNÍ. Byla to doba průkopníků ve využití počítačů, která dovolila růst programátorských individualit nebývalého rozměru. Jejich dílo však bylo obecně nesrozumitelné a těžko modifikovatelné. Druhou a velmi nepříjemnou stránkou této doby bylo značné zatížení programátorů na údržbě vytvořených programů a tím nemožnost jejich orientace pro novou produkci (tzv. krize v programování). Již v průběhu 60. let se začínají ozývat hlasy o revizi celkového přístupu k programování. První myšlenky se týkaly úpravy stylu 12 programování (styl souvisící již s programováním ve vyšších programovacích jazycích) zavedením strukturovaného přístupu (v diagramech, příkazech programovacího jazyka). Začíná se mluvit o technologii programování s inženýrským přístupem. Myšlenky, které byly informatiky předkládány, postupně naplnily obsah nové discipliny - Softwarového inženýrství (Software Engineering SWE, česky SWI). Tvorba programu je přece jeho specifická výroba a bylo by dobré při ní dodržovat některé metody postupy a používat doporučené techniky a nástroje. Jistě je to analogie klasické výroby na základě jistého know-how. V češtině se často pro Softwarové inženýrství uvádí i synonymum "technologie programování". Definice 3-2 Softwarové inženýrství je nejen souhrn teoretických a praktických poznatků ve formě metod, technik a nástrojů podporujících inženýrský přístup k tvorbě jednoduchých programů a rozsáhlých programových systémů, ale i souhrn postupů, návodů jak těchto metod, technik a nástrojů využít pro ekonomickou produkci spolehlivých programů. Po pečlivém přečtení definice je zřejmé, že SWI je pro produkci programů považováno za silně metodickou disciplinu, která se nezabývá vlastním využitím programovacích jazyků. V publikacích existuje mnoho definic pro SWI, jednu z nich uvedl v roce 1989 známý informatik Fritz Bauer, která ovšem není příliš odlišná od naší Definice 3-2. Softwarové inženýrství je zavedení a používání řádných inženýrských principů tak, abychom dosáhli ekonomické tvorby software, který je spolehlivý a pracuje účinně na dostupných výpočetních prostředcích. Vysvětlení k této definici podal informatik Václav Kadlec ve své knize Agilní 12 styl programování je využívání neustále stejných datových a řídících struktur, metod programování, typového GUI, metod prověřování korektnosti, při produkci software -13-

46 programování (str ). Citujeme: Úkolem programátora (přičemž v dnešní době má spíše smysl hovořit o softwarové firmě) zdaleka není jen napsat program. Jeho (či její) práce by se měla řídit řadou důležitých aspektů, jejichž souhrn popisuje právě Softwarové inženýrství. Především: softwarové inženýrství nedbá jen na vlastní zavedení určitých inženýrských principů, ale pokouší se nabádat i k jejich dodržování. Mezi těmito dvěma pojmy je samozřejmě poměrně dramatický rozdíl: zavést lze kdeco, dokonce se (poměrně s úspěchem) můžeme tvářit, že se to používá, nicméně pokud to fyzicky není pravda, výsledky budou pravděpodobně vypadat podle toho. Typickou ukázkou je tzv. certifikát řízení jakosti (pocházející ze soustavy standardů ISO 9000), který může společnost po splnění mnoha podmínek a po absolvování auditu získat: tento certifikát je jistě dobrým začátkem a jeho získání může firmě přinést důležitý náskok před konkurencí. Řada lidí si ale představuje, že pouhým získáním tohoto certifikátu se automaticky a jaksi samovolně stane jeho firma efektivnější, úspěšnější a konkurenceschopnější. Jde samozřejmě o omyl, protože pokud se firma nebude o kvalitu skutečně starat, nepomůže jí ani celá baterie certifikátů. Dalším pojmem obsaženým v definici je ekonomická tvorba softwaru. O významu slova ekonomická panují zřejmě poněkud zkreslené představy. Obvyklý (skoro se mi chce napsat český ) způsob uvažování může vést k názoru, že ekonomická v tomto případě (a koneckonců i ve všech jiných případech) znamená levně vyvinout, draze prodat a neplatit daně. Samozřejmě, podobného cíle se jistě snaží dosáhnout každá společnost, ať již více či méně drsnými metodami, nicméně zdaleka v něm není obsaženo vše podstatné. Konkrétně v případě softwaru musíme zahrnout do pojmu ekonomický mnoho dalších faktorů: je nutné vhodně sestavit vývojový tým (nesmí mít málo/mnoho členů, měl by obsahovat vhodné osobnostní typy), důležitá je volba správného vývojového nástroje/operačního systému, je třeba provést úvahu vyvinout/koupit, důležité je nalézt společnou řeč se zadavatelem (úspora se promítne v budoucnu), je třeba uvažovat o budoucí údržbě/rozšiřování programu (dnes někde při vývoji uspoříme pár tisíc a za tři roky nás to bude stát měsíc času), mnohem více než u jiných druhů zboží musíme uvažovat směrem dopředu není vhodné snažit se ušetřit třeba na důkladné analýze problému Takových bodů bychom nalezli celou řadu (většině se budeme podrobně věnovat v příštích článcích) a všechny můžeme zahrnout do pojmu ekonomická tvorba, protože zanedbání kteréhokoliv z nich povede k ekonomickým (i jiným) ztrátám buď ihned, nebo v budoucnu. Definice dále hovoří o tom, že vytvořený software má být spolehlivý a má účinně pracovat na dostupných technologických zařízeních. O tom se asi netřeba dlouze rozepisovat: opět se dostáváme zpět k tomu, že nestačí napsat program, ale výsledná aplikace by měla splňovat požadavky uživatelů a nikoliv potencionálních hackerů. Navíc by měla efektivně využívat dostupné zdroje ať již hardwarové, softwarové, personální či jiné. Vágně řečeno softwarové inženýrství je souhrn pojmů, postupů a činností, jejichž porozumění, používání a provádění by mělo zajistit efektivnější tvorbu software a především komplexnější pohled na celý proces vývoje. Pokud vlastními silami programujete malou, specializovanou aplikaci pro konkrétního uživatele a velmi úzké použití, nemusíte nutně dodržovat vše, co vám softwarové inženýrství doporučuje. Hlavní síla tohoto oboru spočívá spíše v zavádění systému, pořádku a struktury do rozsáhlejších projektů, na kterých spolupracuje více vývojářů. Jak již bylo naznačeno, softwarové inženýrství se nezabývá pouze vlastním procesem vývoje (tedy psaním programového kódu), ale zahrnuje mnoho dalších navazujících oblastí, komunikací se zákazníky počínaje a etikou softwarového inženýra konče. Konec citace. Uvedená definice je ovšem orientovaná jen na produkci a nepostihuje teoretické přínosy, které mají na praxi značný vliv. Na akademické půdě musíme chápat SWI komplexněji. -14-

47 V historii SWI došlo ke změnám v chápání programů. Dlouhou dobu byla orientace na třídu tzv. jednoduchých programů, později na třídu aplikací a nakonec na třídu rozsáhlých programových systémů (RPS). Podle orientace se rovněž SWI obohacovalo o nové poznatky. Mnohé ze všeobecných poznatků jsou využitelné pro všechny třídy programů (jednoduché programy, aplikace a RPS), ale některé jsou spojeny pouze s jednou třídou. SWI vidí tvorbu software v širokých souvislostech, tj. s ohledem na související disciplíny (metodika, ekonomika, psychologie, metrologie, ergonomie, řízení a vedení-manažerství, ). Tvorba jednoduchých programů je ale všeobecným základem i pro další třídy. Od svého začátku byla tvorba jednoduchých programů řazena do rámce JEDNODUCHÉ METODIKY VÝVOJE, tzv. ALGORITMIZACE, která byla vlastně životním cyklem pro tvorbu jednoduchého programu. Pro informační problém, jehož řešení vedlo k nalezení algoritmu a k tvorbě jednoduchého programu, nebylo potřebné zavádět speciální analytické metody. To ale neplatí pro postup tvorby aplikací RPS, které odpovídají velmi komplexním informačním problémům (komplexní aktivita, podnik, škola, ) a představují vlastně aplikační (business) software informačních systémů. Dodnes se i na vysokých školách učí jak algoritmizace - životní cyklus tvorby jednoduchého programu, tak i tvorba RPS a jejich jednodušší verze, tj. aplikací. Pro informační problémy, jejichž aktivity již považujeme za procesy/transakce muselo SWI ustoupit nové disciplině, tzv. Informačnímu inženýrství (Information Engineering IE, česky II), zcela odlišnému komplexnímu přístupu, který je založen na modelování procesů a dat. V takovém přístupu je tvorba software, přesněji RPS, již samostatnou fází označovanou IMPLEMENTACE a SWI je potom běžně z Informačního inženýrství využíváno, ačkoliv je nadále považováno za samostatnou specifickou disciplinou vývoje programů. 3.5 Historické etapy ve vývoji SWI Ačkoliv vývoj programování šel mnoha směry, z nichž některé nedosáhly četného využití, je možno stanovit jisté mezníky a pomocí nich i samotné etapy vývoje. Relevantním mezníkem byla změna v pojetí tvorby programů, která byla vyvolána přechodem ze sekvenčního, strukturovaného pojetí programu na pojetí objektové. Tato změna zásadně určovala vývoj programů, aplikací a RPS již od začátku 90. let. Zabývejme se nejdříve historií vývoje SWI v době výlučného uznávání strukturovaného pojetí vývoje software (strukturované paradigma). ETAPA Tuto dobu minulého století jsme již nazvali pionýrskou érou. Programátoři této doby byli vcelku společností ještě ne zcela chápáni (měli punc podivínů, kterým málokdo rozuměl). Orientace na assemblery, resp. prvně se objevující vyšší programovací jazyky, nevyžadovala komplexní a řízený přístup k tvorbě programů. Žádná obecná pravidla, žádný inženýrský přístup k tvorbě programů se neujaly. Vytvořené jednoduché strojové/symbolické programy byly nepřenosné, protože byly pro odlišné počítače (odlišný strojový kód, jiné vnitřní zobrazení dat, jiný rozsah operační paměti, ). Pokud byly programy zapsány v assembleru, sice byla eliminována závislost na konkrétním počítači, ale vznikla nepříjemná závislost na překladači. Vytvořené programy byly zpravidla neudržované a neměnné, byly většinou pro jednorázové použití. Byla to doba programátorských hvězd s rozvernými přístupy, doba programování pro programátory (společnost ještě po programech příliš netoužila). Nikdo z programátorů neměl snahu tvořit pod vlivem jistých zásad a principů, protože, jak sami říkali, by šlo o omezování jejich umělecké tvořivosti ve vývoji programů. Proto byly návrhy některých souběžců-informatiků na zavedení jistého řádu v programování, vycházející z roviny atributů programu, většinou programátorů striktně odmítány. Nikdo v této době po nějakém Softwarovém inženýrství příliš nevolá. -15-

48 ETAPA NA PŘELOMU 60. A 70. LET. Již se začínají objevovat první náznaky jakýchsi snah, později ústících ve vznik softwarového inženýrství. Téma Softwarové inženýrství se dokonce objevuje na konferenci NATO v roce Vznikají pojmy návrhu SHORA- DOLŮ, MODULARITA atd. Začíná být chápán význam správně složeného týmu pro vývoj software, píše se v publikaci (Kadlec, 2004) na straně 26. Ovšem to je málo pro charakteristiku této doby. Ten, kdo tuto dobu přímo prožíval (a to pan Kadlec nebyl), dokáže jistě po krátkém zamyšlení udělat přesnější a přehlednější rekapitulaci nových poznatků náležících do Softwarového inženýrství. Pokusme se o některá doplnění. Především, programování doznalo velkého rozkvětu, společnost již pochopila význam výpočetní techniky a komputerizace aktivit a dat, což přímo souvisí s programováním jako takovým. Rychlý rozvoj vyšších programovacích jazyků: Změna stylu programování, první myšlenkové postupy pro vývoj programů (postupy SHORA-DOLŮ, ZDOLA-NAHORU, strukturované programování (rovněž bez příkazu GO TO), procedurové, normované, logické a paralelní programování), první koncepce pro funkcionalitu vývojových prostředí, základy teorie programů, základy teorie programovacích jazyků a překladačů. Význačný pokrokem byl přechod od klasického sekvenčního programování k jeho variantě strukturovanému programování. Tok provádění příkazů již byl řízen podle nových řídících struktur s jediným vstupem a výstupem z nich. Výzkum datových struktur: Vznik deskriptivního aparátu abstraktních datových struktur, používání datových struktur, propracování algoritmů pro datové struktury, výzkum fyzické a logické roviny práce s datovými strukturami, první náznaky pojetí báze dat a používání databázových strojů. Výstavba programů: První náznaky zkoumání struktur programů a vytváření větších programových celků, modulární programování, testování programů, pojetí verifikace a spolehlivosti programů (program dělá právě to, co zamýšlel programátor). Operační systémy: SWI nachází první pohledy na řízení počítače a řízení jeho služeb (spuštění překladu programu, spuštění programu, práce se soubory, knihovny procedur, ). Softwarová krize: Rozmach programování a enormní produkce programů byla spojena s jevem, který se vtipně označoval softwarová krize. Velmi stručně řečeno: vytvořený software vyžadoval četné opravy a doplňování, aby uspěl v měnící se praxi. Tyto aktivity zaměstnávaly postupně až 70% programátorů. Zbytek již nebyl schopen produkovat nový software pro neustále narůstající potřebu komputerizace ze strany společnosti. Za příčiny této krize byly později považovány: Prodražování a prodlužování softwarových projektů. Špatná komunikace. Nesprávné odhady trvání projektů špatné plánování. Nízká kvalita programů. Nezvládnutí technologie. Nesnadnost kvalitní údržby a inovací. Špatná produktivita programátorů, neefektivita vývoje. Softwarová krize byla ale motorem rychlého zavádění poznatků, které postupně na jistou dobu, naplnily obsah SWI. ETAPA KONCE 70. LET. Nikdo již nepochybuje o nutnosti discipliny pro vývoj programů, tedy SWI. Začíná se chápat rozdíl mezi jednoduchým programem, aplikací a -16-

49 rozsáhlým programovým systémem. Rozvíjí se způsoby řízení v rozsáhlých programových systémech. Souběžně s možnostmi počítačů se začíná přemýšlet o přechodu z dávkového zpracování na interaktivní komunikaci s uživatelem vytvořeného software. Použití bází dat a databázových strojů je již běžné. Objevují se striktní požadavky na řízení softwarových projektů. Situace ovšem pro jeho docenění ještě nedozrála, protože neustále existují problémy s dodávkami, jsou četné nedokončené projekty vývoj softwaru není ještě kvalitně řízen a uplatňování doporučovaných postupů ve vývoji software, které vzešly z analýzy softwarové krize, je pomalé. V letech se však již začínají využívat mnohé dnes známé techniky softwarového inženýrství, např. specifikace požadavků, návrh, architektura, testování, zajištění kvality, modely životního cyklu apod., viz (Kadlec, 2005, str. 26). Přichází se na to, že vlastnímu programování musí předcházet specifické analýzy, a to zejména požadavků, dat a procesů. Objevují se první metody myšlenkové postupy a první techniky pro zápis výsledků analýz. Řízení softwarových projektů se začíná věnovat patřičná pozornost. Naznačuje se, že perspektivou SWI je orientace na komputerizaci složitějších informačních problémů (firmy, školy, veřejné instituce, ). Vznikají první náznaky o pojetí informačních systémů. ETAPA 80. LET. Zároveň s rozvojem softwaru jako takového, se masivně rozvíjí i Softwarové inženýrství. V roce 1997 (!!!) je Softwarové inženýrství uznáno jako obor s certifikátem v USA, píše se v (Kadlec, 2005). Je to pravda. Pokrok, který SWI udělalo je nepředstavitelný v celé jeho šíři. Na našem teritoriu se ovšem ještě plně nepochopilo, že software je zboží. Na druhé straně začal na tvorbu software blahodárně působit objektivní trend zaměření na běžného zákazníka v prodeji výpočetní techniky a základního a aplikačního software. Začíná se projevovat silná orientace na interakci software se zákazníkem. Projevuje se vliv sítě sítí Internetu a jeho služeb. Jsou již zcela patrné odklony od sálových počítačů. Značný pokrok vývoje software je spojován s příchodem mikropočítačů. Obecná teorie formálních jazyků je dokončena, probíhá jen výzkum speciálních gramatik. Do programovacích jazyků proniká tzv. objektové programování a snahy o automatizaci programování. Verifikace programů, tj. prověřování jejich spolehlivosti, dosáhlo pozoruhodných teoretických a praktických výsledků. Dochází k ustálení názorů informatiků na pojetí, poslání a funkcionalitu informačních systémů. Nastal rapidní rozvoj metodik pro tvorbu aplikací komputerizujících procesy v podnicích, založených na vyzdvižení dat a procesů (James Martin, Edward Yordon) na stejnou úroveň. Ustálilo se pojetí tzv. strukturovaného přístupu k vývoji IS a strukturovaného paradigmatu (filosofie, metody, techniky, nástroje a informační technologie asociované se strukturovaným vývojem software). CESTU SI RAZÍ tzv.. OBJEKTOVÝ PŘÍSTUP, jehož rapidní rozvoj pokračuje v 90. létech a postupně se formuje objektové paradigma. Přetváří se pojetí a poslání SWI, jeho místo je již jednoznačně uzákoněno ve fázi IMPLEMENTACE v komputerizaci aktivit a dat robustních fyzických systémů vedoucí ke vzniku informačních systémů. V návaznosti na Softwarové inženýrství je již ustáleno i pojetí Informačního inženýrství a Organizačního inženýrství. Snahy o vyřazení programátorů, resp. ulehčení jejich práce v produkci software vedou k nástupu produkčního, podpůrného software typu CASE (Computer Aided Software Engineering) a jeho napojení na známé metodiky Softwarového a Informačního inženýrství. -17-

50 ZÁKLADY SOUDOBÉHO SWI Období je plně pod vlivem mnoha nových informačních technologií, zejména masivního rozvoje a uplatnění Internetu. Souběžně dochází k rozvoji a uzákonění protokolů pro přenos informace mezi klientem a serverem. Postupně se rozvíjí značkovací jazyky, které prezentují informaci prostřednictvím prohlížeče na straně klienta. Do značkovacích jazyků se vnáší dynamika a objektové pojetí. Rapidně se rozšiřuje produkce software na základě objektového paradigmatu. Vznikají velmi užitečné metodiky, využívající deskripci výsledků modelování na bázi jazyka UML (Unified Modeling Language). Nástup zpracování grafiky je opravdu obdivuhodný. Nová, tzv. integrovaná vývojová prostředí (IDE Integrated Development Environment) nabývají gigantických rozměrů a funkcionalit. Zákazník odebírající software je určující pro jeho produkci. Rozvíjí se proto cílevědomé metodiky zahrnující rovněž komunikaci se zákazníkem a metody pro zjištění jeho potřeb. Výroba software a vše co jí předchází, se stává profesionální týmovou záležitostí. Pokročil rozvoj interakce počítače s uživatelem. Výsledky výzkumu, vhodné grafické ikony a panely byly uplatněny v operačních systémech počítačů (Mac Intosh, Windows, ) a běžně i v dalším základním a aplikačním-business software. Rapidní rozvoj různých typů software a informačních a komunikačních technologií ICT přináší do SWI mnohá nová obohacení. Tato se týkají všech směrů spojených s vývojem software. SOUDOBÉ SWI je těsně spjato s objektovým paradigmatem, které proniká do všech vrstev současného software (vrstva prezentační, business vrstva a vrstva datová). Objektové paradigma silně ovlivnilo pojetí webových stránek, samotné prohlížeče a pochopitelně postup tvorby a ladění objektových aplikací na platformě internetu. Objektové metodiky předepisují odlišné metody, techniky a nástroje tvorby objektového software než tomu bylo u strukturovaných metodik. Na začátku vývoje objektových metodik se ještě objevil vliv paradigmatu strukturovaného a metodiky byly v podstatě hybridní. Objektové paradigma ovšem nekompromisně vytláčí paradigma strukturované, ačkoliv poznatky získané za éru strukturovaného paradigmatu (sekvenční a strukturované programování) se neuplatňují jen okrajově. Nové objektové metodiky již odráží rychle dosaženou čistotu objektového paradigmatu. Shrnutí kapitoly: Široký záběr této kapitoly je orientován na stručnou charakteristiku vzniku číslicového počítače, jeho vývoj, na vývoj programování a programovacích jazyků a na celkové etudy programátorské práce zaměřené na produkci software. Zvláště zajímavý je popis jednotlivých etap vývoje SWI zejména pro mladé studenty, kteří nastoupili do rychlíku informatiky nedávno. Σ Pojmy k zapamatování: Softwarové inženýrství Softwarová krize Turingův stroj Sekvenční programování -18-

51 Testy a otázky: 1. Vysvětlete pojetí Softwarového inženýrství a jeho relevantní cíle. 2. O kterých programovacích jazycích se sekvenčním charakterem programování jste slyšeli? 3. Čím se vyznačuje současná etapa vývoje SWI? Úkoly k zamyšlení: 1. Je možný vznik softwarové krize v současném období vývoje SWI? 2. Čím vysvětlujete rapidní nástup objektového programování? 4 Software a typy software Kapitola je jen informativní. Již bylo řečeno, že pod termínem software chápeme programové dílo/programové vybavení a potřebnou dokumentaci k němu. Software tedy zahrnuje jednoduché programy, aplikace a rozsáhlé programové systémy (RPS). Členění na jednoduchý program, aplikaci a RPS je dáno z hlediska vlastního rozsahu programového díla. Do rozsahu můžeme, alespoň prozatím, zařazovat např. šíři funkcionality, vyspělost použitých datových struktur, strukturální složitost, architekturu, Software může být posuzováno i z hlediska vyspělosti použitého programovacího jazyka (strojový kód, assembler, vyšší programovací jazyk). Vedle toho můžeme software posuzovat z hledisek zaměření dané komputerizace (užitková funkce), dostupnosti uživateli, Naším cílem bude vyjasnit si současný pohled na různé typy software a k tomu nám výborně pomůže Wikipedia, viz [wiksof], z které budeme čerpat. Pochopitelně, uvedené typy nebudou jistě vyčerpávající, ne každé software dokážeme konzistentně spojit s jedním z uvedených typů. Je to dáno jistě tím, že produkce software se rapidně zvyšuje a rozšiřuje se obzor komputerizace na zcela nevídané procesy. Tak jak to naznačuje Wikipedia, můžeme podle užitkové funkce software členit na: systémový software nejčastěji umožňuje efektivní používání počítače o firmware software obsažené v hardware (BIOS, firmware vstupně-výstupních zařízení ), o operační systém spravuje počítač, vytváří prostředí pro programy jádro operačního systému (včetně ovladačů zařízení) pomocné systémové nástroje pro správu operačního systému (formátování disků, nastavení oprávnění, utility, démoni, ) aplikační software umožňuje uživateli vykonávat nějakou užitečnou činnost, např. řídit vědeckou konferenci, vyčíslit fakturu, zřizovat zakázky, Do aplikačního software patří především tzv. business software kancelářské balíky: textový editor, tabulkový procesor, prezentační program, o grafické programy: vektorový grafický editor, bitmapový grafický editor, o vývojové nástroje: vývojová prostředí, překladače, o zábavní software: počítačové hry, přehrávače digitálního zvuku a videa apod. Často členíme software rovněž podle podmínek dostupnosti na: -19-

52 freeware (bezplatné, zadarmo), Open source software (s otevřeným, přístupným zdrojovým kódem), svobodné software (free software), shareware (volně distribuovatelné), komerční software (použití jen za platbu), škodlivé software (záměrně obtěžující uživatele). Freeware je software, který je distribuován bezplatně, či za symbolickou odměnu typu poslání pohlednice, mnohdy autor umožňuje (ale nevyžaduje) v případě spokojenosti zaslání finančního daru, někdy hovoříme o typu softwarové licence. Autor si u freeware zpravidla ponechává autorská práva, například nedovoluje program upravovat nebo omezuje použití zdarma jen pro nekomerční či osobní potřebu. Freeware software se tak liší od tzv. svobodného software nebo Open source software. Jedná se tedy o volně šiřitelný program, bez placení autorského honoráře. Na světě existuje mnoho katalogů, které seskupují tyto programy většinou společně s programy, které jsou k dispozici ke stažení na zkušební dobu. Tyto katalogy jsou dobrým zdrojem alternativního software k drahým placeným licencím. Open source nebo také Open-source software (OSS) je počítačový software s otevřeným zdrojovým kódem. Otevřenost zde znamená jak technickou dostupnost kódu, tak legální dostupnost - licenci software, která umožňuje, při dodržení jistých podmínek, uživatelům zdrojový kód využívat, například prohlížet a upravovat. V užším smyslu se OSS míní software s licencí vyhovující definici prosazované Open Source Initiative. Pro odlišení se někdy Open source software vyhovující požadavkům OSI označuje Open Source (se všemi velkými písmeny). V nepřesném ale poměrně běžném vyjadřování se označení Open source používá i pro mnoho vlastností, které s otevřeností zdrojového kódu nesouvisí, ale vyskytují se u mnoha Open source programů. Například může jít o bezplatnou dostupnost software, vývoj zajišťovaný úplně nebo z podstatné části dobrovolnickou komunitou nebo nekomerčnost. Svobodný software, někdy také nazývaný free software (pozor ne freeware), je software, ke kterému je k dispozici také zdrojový kód, spolu s právem tento software používat, modifikovat a distribuovat. Vzhledem k rozsahu práv zaručených svobodnou licencí není nabytí svobodné licence podmíněno poskytnutím finančního nebo jiného plnění držiteli autorských práv. Často autor k svobodnému softwaru nabízí další navazující placené zboží (např. originální instalační média a balení) a služby (např. technickou podporu); u svobodného softwaru využívanému k vysoce komerčním účelům je zakoupení těchto placených produktů obvyklé. V roce 1984 založil Richard Stallman projekt GNU, aby tak vytvořil kompletní unixový operační systém GNU založený na svobodném software. Jako krédo svobodného software definoval tyto čtyři svobody: svoboda používat program za jakýmkoliv účelem svoboda studovat, jak program pracuje a možnost přizpůsobit ho svým potřebám svoboda redistribuovat kopie programu. svoboda vylepšovat program a zveřejňovat zlepšení, aby z nich mohla mít prospěch celá komunita Za získání kopií svobodného software můžete platit, nebo je obdržet zdarma, ovšem bez ohledu na způsob, jak jste je získali, máte vždy svobodu kopírovat a měnit software, dokonce prodávat nebo darovat jeho kopie nebo pozměněné verze. Infornatik Stallman založil Free Software Foundation (Nadace pro svobodný software), která se stará o právní a organizační stránky GNU projektu a o rozšiřování povědomí o svobodném software. Myšlenky svobodného software byly formulovány prostřednictvím copyleft GNU General Public License a GNU Lesser General Public License (původně nazývaná GNU Library General Public License), které se časem staly nejrozšířenějšími licencemi svobodného software. GNU General Public License zajišťuje uvedené základní svobody svobodného software (dále jen základní svobody) a někdy je také nazývána copyleft licencí. Copyleft licence říká, že pokud redistribuujete originální nebo pozměněnou verzi programu, musíte tuto verzi redistribuovat pod -20-

53 stejnou licencí, pod jakou jste získali původní program. V podstatě to znamená, že k němu nesmíte přidat žádná omezení, abyste tak odepřeli základní svobody ostatním. Tato licence tedy nijak neomezuje základní svobody; spíše je chrání. Svobodný software neznamená nekomerční. Svobodný program musí být dostupný pro komerční využití. Komerční vývoj svobodného software není ničím neobvyklým; takové programy jsou komerčním svobodným software. Shareware je označení pro software chráněný autorským právem, který je možné volně distribuovat (typicky na internetu nebo na CD nebo DVD, jež jsou přílohami časopisů). Uživatel má možnost software po určitou dobu zkoušet, zda mu vyhovuje nebo ne. Pokud ho ale nadále používá, je povinen se řídit podle autorovy licence a zpravidla zaplatit cenu programu nebo se třeba jen registrovat. Volně šířený shareware má obvykle zabudovaná omezení (časová trial, funkční crippleware, omezující uživatelův komfort adware, nagware). Pak mluvíme o demoverzi. Heslo nebo softwarový klíč pro přístup k plně funkční verzi obdrží uživatel po zaplacení. Některé programy z kategorie shareware plnohodnotně fungují i po vypršení testovacího období. Komerční software je takový software, který je šířen jen za peněžní platbu. To znamená, že pokud produkt chcete používat, musíte za to tvůrci zaplatit. Takový software je obvykle možné používat jen dle omezení dané jeho licencí. Často je tak omezen počet instalací software současně, přenositelnost licence či právo modifikace produktu. Příklady komerčního software jsou Microsoft Windows, Microsoft Office či Adobe Photoshop, Komerční software je často brán jako synonymum pro proprietární software (viz níže). Ve většině případů skutečně platí, že komerční software je zároveň proprietární, ale nemusí tomu tak být. Škodlivé software Grayware je označení pro software, který záměrně obtěžuje, například dialery, spyware a adware. Oproti klasickým počítačovým virům se grayware nesoustředí na přímé páchání škod (například v podobě mazání dat), ani automaticky nekopíruje sebe sama, ale obtěžuje uživatele jinými cestami například vyskakovacími (pop-up) okny s všudypřítomnou nechtěnou reklamou, nebo dokonce pokusy o krádež identity. Poznámka: 1. Některé termíny se zdají býti synonyma, ale není tomu tak. Týká se to např. rozdílu mezi freeware, Open source software a svobodným software. Následně popsané rozdíly je nutné respektovat: a. Je třeba rozlišovat mezi freeware a svobodným software či Open-source, nejedná se o totožné pojetí licence (i když je to tak laickou veřejností někdy vnímáno). Freeware je na rozdíl od Open-source software proprietární software. b. K freeware se nedodávají zdrojové kódy a je zakázáno je vnitřně upravovat. U freeware autor dodává program už v přeložené podobě (jako.exe,.com, či jiný spustitelný soubor). Rovněž je u freeware typicky v licenci zakázáno zpětné získání zdrojových kódů ze spustitelného souboru, což mnohdy úplně znemožnuje jakoukoliv legální cestu k získání zdrojového kódu. c. Vývoj freeware programu je tedy (oproti Open-source) plně a pouze v rukou autora. d. Nezveřejňování zdrojových kódů u freeware také ztěžuje jeho bezpečnostní revizi. e. Zatímco freeware je software zdarma, svobodný a Open-source software lze volitelně šířit i za peníze. 2. Často se v souvislosti se software uvádí tzv. EULA (End-User-License-Agreement), což je licence pro koncového uživatele softwaru určující, co uživatel smí a nesmí dělat. Je možné, aby byl zdrojový kód Open source, ale výsledný produkt už spadá pod EULA, kde se hovoří o zákazu editace a šíření tohoto programu (viz např. prohlížeč Mozilla Firefox). 3. Proprietární software je takový software, kde jeho autor upravuje licencí (typicky EULA) či jiným způsobem možnosti jeho používání. K takovému software nejsou zpravidla k dispozici volně zdrojové kódy či v nich nelze svobodně dělat úpravy a výsledné dílo -21-

54 distribuovat. Takový software obvykle spadá do kategorie komerčního software, který jeho autor prodává. 4. Rovněž o termínech svobodný software a Open source se často mluví jako o synonymech. Pravda je ale následující: pojem svobodný software (free software) prosazuje Free Software Foundation od 80. let 20. století. V roce 1998 pak lidé, kteří se snažili prosadit Free Software ve světě komerčních firem, přišli s vlastním, novým názvem pro Free Software - Open Source. K přejmenování je vedla obava z toho, že termín Free Software komerční firmy odrazuje a mate. Nový název Open Source pak organizace OSI převzala jako svůj oficiální termín, zatímco FSF zůstává u názvu Free Software. 5 Pár vět k vývoji software Kapitola je jen informativní. V současné době rychle dopředu pokročily prostředky vizualizace s generováním zdravého programového kódu. Vizualizace se aplikují na mnoho téměř standardních aktivit, s kterými se setkáváme ve vývoji software. Existují tedy důvody, proč mluvíme o tom, že rodina tvůrců software se rozrůstá. Vizualizaci přichází na chuť mnoho velkých softwarových firem. Např. firma Microsoft, a to tedy není jediná, umožní v jazycích C# a Visual Basic velmi rychle a mechanicky zprostředkovat styk s BD a získat z ní potřebné informace. Vizualizační konstrukce této úlohy je jednoduchá, bez ohledu na to, jde-li o informaci z jediné tabulky, resp. o informaci z tabulek spojených datovou asociací. Např. zásobovač podniku, který se stará o sklad výrobního materiálu (tekutý, plynný nebo pevný) může rychle ke své BD sestavit aplikaci s SQL dotazem, který dodá požadovaný výsledek. Mnozí zaměstnanci podniků, firem, organizací a veřejné správy si tak mohou sestrojit aplikace podporující pracovní úkoly, protože nemají k dispozici příslušný profesionální software, anebo jim požadovanou aktivitu neumožňuje. Profesionální software je ovšem většinou vyvinut týmem té či oné softwarové firmy, tedy týmově a ne individuálně. Právě pro takový vývoj jsou určeny metody techniky a nástroje discipliny Softwarové inženýrství zabudované v objektových metodikách. 5.1 Softwarový proces Informační systémy můžeme chápat tak, jak k nim přistupuje management podniku, tj. jako ke zdroji informace pro řízení podniku. Tento zdroj je založen na komputerizaci podnikových procesů patřících do managementem uznávaných procesních množin ERP, SCM, CRM, BI, zejména na nejnižší transakční úrovni podniku. Ovšem informatici mají poněkud jiný přístup k informačním systémům (SI). Chápou, že jeho základem je rozsáhlý software a zajímají se především o možnosti jeho konstrukce. Konstrukce takového software je poněkud složitější než tvorba jednoduchých aplikací a proto se pro konstrukci rozsáhlého software zavádí speciální termín softwarový proces- Software Development Process (SDP). Pod tímto termínem je obecně chápán jakýkoliv způsob vývoje software. Průběh tohoto procesu, tj. členění na vývojové fáze je vlastně životním cyklem vyvíjeného software. Životní cyklus je tedy rekognoskací modelem života konkrétního softwarového procesu. Softwarový proces je obecně charakterizován jako uspořádaná posloupnost jistých aktivit, který vede k vytvoření nového, nebo modifikaci již existujícího software. Aktivity-kroky mohou probíhat sekvenčně, nebo paralelně. Mnohé z těchto kroků jsou zajišťovány softwarovými specialisty a s podporou tzv. CASE (Computer Aided Software -22-

55 Engineering) nástrojů. Softwarový proces je opakovatelný a implementovatelný pro vývoj komputerizačního software libovolné organizace. Poněkud vyšším členěním softwarového procesu než na kroky, jsou tzv. fáze, které prezentují skupiny sémanticky souvisejících kroků. 5.2 Základní modely softwarových procesů Za mnohá desetiletí se vyvinulo několik modelů pro softwarový proces. Začalo se jim říkat životní cykly vývoje software. Dnes ještě nemáme ani jeden z nich, který by byl prohlášen za tzv. referenční. Historie jejich vývoje ovšem začala vodopádovým životním cyklem, který je možno nalézt v různých podobách, rozšířeních a modifikacích v současné době používaných modelech. Poměrně mnoho se o pojetí a modelech softwarového procesu dovíte v [Som10]. Následující přehled uvádí často používané modely softwarových procesů: I. vodopádový, II. fontánový, III. spirálovitý, přírůstkový, IV. síťový a V. prototypový Vodopádový model Je to model, který předpokládá, že další fáze je zahájena jen tehdy, až je předchozí plně ukončena a její výsledky již schváleny. Často se nárůst poznatků od fáze předchozí k fázi následující zobrazuje pyramidálně, s postupem shora dolů. Definice inf. problému Plánování a Specifikace požadavků plánování analýza analýza návrh implementace a testování zavedení data návrh implementace aktivity Obrázek 5-1: Vodopádový model Fontánový model Je to model, který přímo předepisuje povinný návrat z dořešené fáze do fáze předchozí s opravou a upřesněním poznatků v ní. zavádění implementace návrh analýza popis Obrázek 5-2: Fontánový model. -23-

56 5.2.3 Přírůstkový model Dalším typem je tzv. přírůstkový (inkrementální) model, který umožní tvorbu software po částech. To ale obvykle znamená, že fázemi můžeme projít několikrát. Opakovaným průchodem libovolnou fází, vzniká nárůst nových poznatků. Průchod je často organizován spirálovitě. Jde tedy o postupné vylepšování získaného řešení. U spirálovitého modelu je názorně využit jeden z principů, tzv. iterativní přístup k tvorbě zejména rozsáhlých softwarových systémů. Iterace je tvořena posloupností relevantních vývojových kroků. Model byl navržen informatikem Barry Boehmem v roce Je tedy poměrně mladý. K jeho uplatnění došlo v mnoha metodikách a rovněž v metodikách RUP (Rational Unified Process) a UP (Unified Process), na které se budeme později orientovat. Spirálový model je vlastně sekvencí opakování jednotlivých pracovních postupů vývoje software. Následující obrázek uvádí vylepšený návrh Barry Boehma v IEEE Obrázek 5-3: Boehmův Spirálovitý model z [Som10]. Obrázek 5-4: Boehmův Spirálovitý model z [Kad04]. -24-

57 Ve čtyřech kvadrantech, počínaje levým horním, se opakují pracovní postupy: Stanovení cílů následné iterace (cíle, alternativy a omezující podmínky části projektu, která bude řešena), potom je Analýza rizik, pravý spodní kvadrant je pro Vývoj (vývoj, testování a ověřování), levý kvadrant je pro Plánování (další postup). Jednotlivé cykly spirály mají přesně stanovené úkoly. Následující pomocný obrázek jen velmi hrubě ilustruje iteraci složenou z pracovních postupů analýza, návrh, implementace, testování, a zavedení. Vzhledem k opakujícím se iteracím dostává model rovněž přívlastek iterativní (směr spirály není podstatný). analýza návrh posouzení verze uživatelem získané verze software implementace testování praktický provoz dané verze Obrázek 5-5: Spirálovitý model Prototypový model (Prototyping Life Cycle) feasibility guidelines Good candidat Rigorous specification approach Identify basic needs preliminary design Develop working model Demo in context solicit refinement and extensions Clean up prototype and document Implement revisions/ enhancements Prototype done Detail component needed Impact on prototype Rigorous specification components Obrázek 5-6: Prototypový model. -25-

58 Model vyjadřuje skutečnost, že řešitel a uživatel software vyberou počáteční přiměřeně náročnou část problémové domény a provedou se na ní všechny fáze, konče implementací. Vzniká tak práce schopný software, který simuluje vybrané aktivity domény. Mezitím dochází k vytvoření nového software a předešlý se zahazuje. Koncem 80. let mnoho informatiků předpokládalo nástup prototypování až s příchodem schopných vývojových prostředí. Ne každý požadovaný software lze výhodně vyvíjet pomocí prototypování. Vedle toho může použití prototypování nahrávat i situace samotného uživatele. 5.3 Stručné zhodnocení modelů softwarového procesu Jaké jsou výhody a nevýhody uváděných modelů softwarového procesu? Vodopádový model, který vzniknul v roce 1970, konečně zavedl důrazné členění na vývojové fáze a začlenění aktivit do nich. Fáze jsou prováděny sekvenčně, paralelismus není uvažován, a nejsou v nich zavedeny ani náznaky iterací (opakování pevných sekvencí jistých vývojových kroků). Model dává dostatečný čas pro důkladné splnění úkolů každé fáze, tj. ke schválení výsledků uživatelem dojde až tenkrát, když odpovídají realitě a jeho požadavkům na funkcionalitu software. Tato důkladnost do jisté míry zabezpečuje, že je málo omylů a tedy i málo vynucených návratů z jedné fáze do fáze předchozí. Návrat o jednu fázi zpět nebyl zakázán. Později byla k modelu, za fázi Zavedení, přidána fáze Údržba, v rámci které bylo možné přidat nové požadavky a vrátit se na fázi Analýza. Obecně je vodopádový model zdlouhavý a uživatel-zadavatel nemá dlouhou dobu ani malou fungující část cílového software. Přírůstkový model může rychle přinést fungující prototyp cílového software. Prototyp obvykle zahrnuje provedení úkolů jednotlivých fází jen nad vybranou částí domény, nejčastěji klíčovou. Na druhé straně může provedení fází pro další část domény vyvolat revizi předchozích poznatků a provedení oprav může být nákladné. Tato rizika rostou s růstem složitosti software. Fontánový životní cyklus umožní poopravit předchozí fázi na základě výsledků z fáze následující. Prototypový model sice velmi rychle přináší fungující část cílového software, ale další prototyp nemusí z předchozího příliš využívat, což vede ke ztrátám. Poznámka: V publikacích o vývoji software se často setkáváme pro vývoj software s termíny softwarový proces a životný cyklus software. Oba termíny nemůžeme považovat za úplná synonyma. Mluvíme o tom, že životní cyklus je rekognoskací konkrétního softwarového procesu. Životní cyklus charakterizuje model softwarového procesu. Jestliže konkrétní softwarový proces určuje CO, KDY, JAK a PROČ se má něco dělat, dále obsahuje rovněž filosofii vývoje software a zdůvodnění použitých metod, technik a nástrojů, je zvykem takový softwarový proces nazývat vývojovou metodikou. Např. hovoří se sice o softwarovém procesu RUP, ale jde vlastně o metodiku RUP. Velmi podrobně se o metodikách dočtete v [Kad04]. -26-

59 6 Zopakování relevantních termínů Kapitola je jen informativní. Zde soustředíme pozornost na stručný popis relevantních termínů Softwarového inženýrství: Termín Význam Software... Počítačové programy a potřebná dokumentace, která osvětluje jejich funkcionalitu architekturu a uživatelské použití (česky: programové dílo). Jednoduchý program...(computer program) Počítačový program rozsahu kódu max. 1A4. Aplikace/programová aplikace, /softwarová aplikace...(software application) Nejjednodušší varianta rozsáhlého programového systému. Rozsáhlý programový systém /softwarový systém...(software system) Skupina programů mající charakter systému. Softwarové inženýrství...(software engineering) Inženýrská disciplina, která se zabývá všemi aspekty vývoje software. Vývojový proces...(software process/development process) Cesta od formulace požadavků (specifikace požadavků) na software (vycházejí z business deskripce problémové domény), až po konečnou konstrukci software a jeho zavedení do vhodného prostředí. Nakonec bychom mohli uvést několik srovnání často používaných termínů: 1. Computer Science (počítačová věda) versus Software Engineering 2. Software Engineering versus System Engineering Porovnání uvedeme na přednášce. Položme si rovněž otázku Co přinesl Softwarovému inženýrství internet? Co byste odpověděli? 7 Formalizace software Cíl: Znát (umět vysvětlit): Základní komponenty formální notace sekvenčního programu. Základní komponenty formální notace objektového programu. Notaci rozsáhlého softwarového systému. Rozdíly mezi vlastnostmi jednoduchých programů a rozsáhlých softwarových systémů. Seznámit se S pojetím modelování software. S pojetím architektury software. Klíčová slova: Jednoduchý sekvenční program, jednoduchý objektový program, rozsáhlý softwarový systém, -27-

60 modelování software, architektura software Věnujme se teď pojetí jednoduchého klasického sekvenčního programu, aplikace a rozsáhlého programového systému. Později se budeme zabývat pojetím objektového jednoduchého programu, aplikace a RPS. Chceme-li vyjádřit podstatu jednoduchých programů, budeme muset spojit dohromady zkušenosti z jejich tvorby s transparentním formálním aparátem a využít znalosti dvou paradigmatů: klasického strukturovaného a objektového. Použitý formální aparát jistě posílí chápání podstaty tvorby jednoduchých programů. 7.1 Klasické sekvenční programování Historický vývoj chápání programů spěl rychle k vydělování tzv. jednoduchých programů a rozsáhlých programových systémů. Je však velmi obtížné běžným slovem charakterizovat jejich odlišnosti. Pokusíme se proto pomocí jednoduchých formálních aparátů postihnout nejtypičtější kvality obou skupin. Následující definice chápou jednoduchý program jako uspořádanou šestici komponent a RPS jako systém relativně nezávislých programů/aplikací. Definice později podrobíme revizi pod zorným úhlem role objektového programování (instance tříd-objekty-nové dat. struktury, události-reakce-nový způsob řízení-nové řídící struktury). V každém případě je program chápán jako jeden z modelů notace (zápis, notační představa) algoritmu A, před jeho realizací-provedením počítačem. Následující obrázek ilustruje vstupní data X a výstupní data Y programu P. X Program P=P(A ) Y Všechna přípustná vstupní data X a všechna přípustná výstupní data Y (zpracovávaná ve formě datové struktury) jsou svázána zobrazením A (X) Y. Přípustnost dat X a Y je stanovena složitými množinovými formulemi. Definice 7-1 Jednoduchý program P je uspořádaná šestice komponent ve tvaru P = ( T, D, R,, S st, S d ), kde T je text programu složený z příkazů nad jazykem J, píšeme T=T(J), D je konečná množina datových struktur v programu, R je konečná množina řídících struktur v programu, je konečná množina operací nad datovými strukturami v programu, S st je statická struktura programu předepsaná překladačem jazyka J, S d je dynamická struktura programu, která je dána přechody mezi příkazy na základě řídících struktur z množiny R. V tomto okamžiku je sice nepříjemné to, že ještě neznáme pohledy SWI na datové a řídící struktury. Přesto uvedené pojetí dynamické a statické struktury programu již intuitivně chápeme v důsledku znalosti programovacího systému některých z jazyků, na kterých je vyučována ALGORITMIZACE (např. jazyka Pascal, C,Basic, ). Logika programu je dána kartézským součinem L = D x x R. Tento vztah spojuje ty komponenty programu, které jsou pro aktivitu programu určující. Je pochopitelné, že vlastní porozumění tomuto zápisu je podmíněno potřebnými znalostmi abstraktních datových struktur a jejich formálních zápisů, významných operací nad datovými strukturami a pojetím řídících struktur v programu. Příklad 1: Následující příkaz v jazyku Pascal dostatečně dokumentuje pojetí logiky klasického -28-

61 sekvenčního (imperativního) programu. Odlišnými barvami jsou označeny řídící struktury, operace a datové struktury. if a > b then y := a b else y := b a ; Řídící struktury, jimiž jsou: větvení, cyklus a sekvence jednoznačně určují potenciální přechody mezi příkazy. Potenciální přechody, na nichž je dynamika založena, se dají reprezentovat tzv. orientovaným grafem G řízení programu P s notací G = G(P), nad kterým lze provádět řadu užitečných úloh (uzly jsou příkazy programu, hrany mezi uzly jsou potenciální přechody mezi příkazy). Charakteristické vlastnosti tohoto grafu jsou plně dány dynamickou strukturou programu S d. Tento graf řízení programu přesně ilustruje jeho dynamickou strukturu S d prostřednictvím individuálních potenciálních přechodů mezi příkazy. - řídící struktura (větvení) - operace - datové struktury Jednoduchý program je charakterizován velmi často např. těmito typickými vlastnostmi: neveliký rozsah textu (1 až 2 str. A4), kompaktní celek, nedělitelný na další programy, omezený rozsah použitých forem datových a řídících struktur, vně programu nepřenositelné fyzické formy datových struktur a logika jejich zpracování (výjimkou jsou soubory). V současné době jsou tyto historicky typické vlastnosti rozšiřovány. Do množiny J se přidávají příkazy umožňující zpracovat i složitější datové struktury, např. prvky GUI (okna parametrů, menu, dialogy), datové entity (z náležících zdrojových bází dat). Často se také mění pohled na řídící struktury. Běžně jsou již používány řídící struktury založené na událostech. I přes tato vylepšování dochází k tvorbě jednoduchých programů převážně v rámci výuky programování, resp. při tvorbě prostého firmware. Jednoduchým programům se ovšem neodpírá jejich možná dělitelnost na samostatné podprogramy (platné pro Assemblery), resp. na procedury (pro vyšší programovací jazyky), z nichž je vystavěna jejich celková aktivita. Později poznáme i další rozumné kusy kódu (např. skripty, ). Následující obrázek zase dokumentuje význam komponenty S st pro pascalovské programy. Příklad 7-2: Jak se dají interpretovat komponenty S st a S d? Zkuste zjistit jejich interpretaci pro známé programovací jazyky Algol, Pascal, Visual Basic, resp. další jazyky (nevyjímaje značkovací jazyky, skriptovací jazyky, ). Např. S st pro pascalovský program je interpretací následujícího schématu statické struktury programu. -29-

62 Rozsáhlý programový systém teď můžeme podat jen na jednoduchých programech. Později vy bylo možné tuto definici podat rovněž na aplikacích. 7.2 Rozsáhlý softwarový systém Definice 7-2 Rozsáhlý programový systém P = {P 1, P 2,, P n=1, P n} je tvořen skupinou vzájemně svázaných, relativně nebo úplně samostatných programů pracující navenek jako jeden celek mající atributy obecného systému. Tato definice sice umožňuje postavit jistou hranici mezi jednoduchými programy a rozsáhlými programovými systémy, ale např. pro modulární programy není jasné, do které skupiny patří. Definice 2 je ale východiskem pro rozvedení vlastností obecného systému: nejvyššími strukturálními prvky jsou programy P 1, P 2,, P n mezi nimiž jsou vazby V = {v i,j P i x P j }. Tyto vazby mohou mít různorodý charakter: 1. řídících vazeb pro potencionální přechody mezi programy, 2. datových vazeb pro předávání a zpřístupnění dat, -30-

63 3. kauzálních vazeb ( příčina, následek ), 4. synchronizačních vazeb pro přechody mezi programy v paralelním programovém systému, 5. koordinačních síťových vazeb (řízení distribuce), když je složitý programový systém rozložen na počítačové síti, 6. vazba přechod na událost a další. rozsáhlý programový systém má okolí O s prvky A 1, A 2,,A m píšeme O = ( A 1, A 2,, A m ) s možnými vazbami programů na prvky okolí což zapíšeme ve tvaru V = { v i,j P i x A j }. Tyto vazby mohou mít opět různorodý charakter : 1. datových vazeb pro přístup k vnějším zdrojům dat, 2. řídících vazeb pro tzv. vnější řízení, 3. zásahů pro restrukturalizaci vazeb. Programový systém je uzavřený, je-li V prázdnou množinou. zápis rozsáhlého programového systému může být také ve tvaru S = ( P, V, V ), stavem = ( x 1, x 2,,x t ) rozumíme souhrn přesně definovaných situací, podmínek, vlastností-stavových veličin x 1, x 2,,x t v nichž se může systém nacházet. Systém je obvykle v počátečním stavu 0 a přechází ze stavu do stavu na základě své činnosti, množinu programů P 1, P 2,, P n lze sémanticky sdružovat do disjunktních podmnožin S 1, S 2,, které nazýváme podsystémy. Tím dojde také k přeskupení vazeb, protože některé z vazeb mezi programy se stanou vazbami mezi podsystémy a jiné vazbami podsystémů na okolí. Další možností je seskupení programů do speciálních celků - modulů s interpretací všech možných vazeb mezi moduly a systémem řízení (potenciální přechody mezi moduly, dostupnost dat, ). Seskupování může být provedeno na základě specifických kritérií (např. modul pro správu dokumentů klienta, modul komunikace s klientem, ). Modulem může být např. i celý podsystém. Dílčí programy mohou hrát roli komponent se specifickými vazbami, nebo roli distribuovaných kódových celků (služby) s poněkud odlišnými vazbami. RPS jsou charakterizovány velmi často např. těmito typickými vlastnostmi: velký rozsah textu, jehož části mohou být v odlišných programovacích jazycích, členění systému na podsystémy v souladu s analýzou informačního problému, členění systému na moduly/komponenty/služby, vazby na okolí jsou realizovány v tzv. GUI (Graphical User Interface), je použito všech dostupných řídících a datových struktur, jednotná logická datová struktura daná bází dat (relační/objektovou), tvorba je řízena pomocí projektu se zvoleným životním cyklem, tvorba je převážně týmovou prací, členění na tři nebo více vrstev (prezentační, aplikační a datová), pro RPS na bázi Internetu: uplatnění technologie klient/server, možnost zavedení distribuovaných programů, Nižší formou RPS jsou tzv. aplikace. Vyznačují se tím, že programů není příliš mnoho -31-

64 (neurčité), ale je velké množství pomocných souborů různých formátů a významu. Příklady rozsáhlých programových systémů: operační systémy, aplikace různých druhů (textové a tabulkové procesory, ), business software všech klasických variant IS (transakční, expertní, taktické a strategické), business software mnoha variant IS na bázi Internetu. 7.3 Objektové programování Jaká je skladba objektových programů a na čem jsou založeny? Neoperační-deklarační část jednoduchého objektového programu je tvořena deklaracemi objektových tříd. Objektové třídy jsou základními datovými a operačními strukturami. Operační část je tvořena sekvencemi příkazů pro generování objektů instancí tříd a příkazy imitující zasílání zpráv vybraným objektům. Objektový program disponuje, podobně jako klasický sekvenční program, statickou a dynamickou strukturou. Významy některých položek notace P = ( T, D, R,, S st, S d ) jsou ale odlišné od notace pro klasický sekvenční program. Např.: T je kód programu, D je množina informačních struktur jednotlivých objektových tříd, R reprezentuje graf zasílání zpráv, je množina všech operací v objektových třídách programu. S st reprezentuje statickou strukturu kódu programu, S d reprezentuje dynamiku provádění operací na základě zasílání zpráv. Logika objektového programu je vysvětlitelná notací L = D x x R Za události, které způsobí vytváření uspořádaných trojic (d,, r) považujeme přijímání zpráv od jiných objektů. -32-

65 8 Obecné vlastnosti vývoje software Kapitola je jen informativní. Pro tuto kapitolu je využita kniha Iana Sommervilla Software Engineering. Zde uvedeme stručný výklad takových skutečností týkajících se vývoje software, které někdy nezávisí od jednoho nebo obou paradigmat (strukturované a objektové paradigma) a mají převážně charakter systémových vlastností. Zde stručně představíme následující vlastnosti vývoje software, kterými se budeme ve vzdělávacím materiálu průběžně věnovat: 1. Modelování softwarových systémů (Software system modeling) 2. Návrh architektury softwarových systémů (Architectural design of software systems) 3. Znovupoužití software (Software reuse) 4. Softwarové inženýrství založené na komponentách (Component-based software engineering) 5. Distribuované softwarové inženýrství (Distributed software engineering) 6. Správa konfigurací (Configuration management) 7. Vylepšení procesu vývoje software (Software process improvement) Dále se dovíme, že bod 2. je ve vývoji zejména rozsáhlého software zásadní. Potvrdí to rovněž využití metodiky UP (Unified Process) pro vývoj software. Věnujme se nejdříve prvním dvěma vlastnostem. 8.1 Modelování softwarových systémů (Software system modeling) Systémové modelování je v teorii a praxi obecných systémů používán velmi často. Prostředky využitelné pro modelování jsou různé povahy. Časté jsou různé grafické diagramy nebo matematické systémy. Pochopitelně, softwarové systémy jsou speciální staticko-dynamické abstraktní systémy a matematické prostředky nejsou využívány. Prostředky modelování softwarových systémů obecně na příslušném paradigmatu závisí. Obvykle se model softwarových systémů uvádí na konci ustanovení kolekce všech uživatelských požadavků. Situace s využitím systémových modelů software došla již teoreticky tak daleko, že se uvažuje generování software na jejich základě. Softwarový systém nedokážeme namodelovat jediným typem modelu. Obvykle se používá kolekce systémových modelů, která postihuje to, co je v každém systému to základní, tj. prvky, jejich kontext, interakce prvků, strukturu a chování systému, což představuje tzv. architekturu software. Podle toho se rozlišují následující typy modelů software: 1. Kontextové modely (hranice systému, okolí systému a kontext okolí na softwarový systém) 2. Interakční modely (interakce prvků okolí se systémem nebo prvků v systému, dynamika systému) 3. Modely chování (operace, procesy, které jsou prováděny, dynamika systému) 4. Strukturální modely (model prvků systému a jejich vzájemné vazby, statika systému) 5. Událostní modely (řízení systému na základě událostí, dynamika systému) 6. Speciální modely, na kterých je založeno generování software. Tyto modely měly odraz již ve strukturovaném paradigmatu. V objektovém paradigmatu -33-

66 jsou tyto modely prezentovány diagramy jazyka UML včetně širokých deskripcí. S tím se seznámíme v dalších částech vzdělávacího materiálu. Architekturou software se budeme velmi podrobně zabývat v Části II. Architektura software. Shrnutí kapitoly: Kapitola přináší formální pohled na jednoduché programy sekvenčního a objektového pojetí. Jsou použity jednoduché formalismy pro objasnění podstaty rozsáhlého softwarového systému. V závěru kapitoly je poukázáno čím modelovat základní vlastnosti software a zdůrazněno respektování tzv. architektury software, která dominuje zejména u rozsáhlých softwarových systémů. Σ Pojmy k zapamatování: Jednoduchý sekvenční a objektový program Rozsáhlý softwarový systém Okolí rozsáhlého softwarového systému Testy a otázky: 1. Z čeho se skládá formální notace sekvenčního jednoduchého programu? 2. Z čeho se skládá formální notace objektového jednoduchého programu? 3. Co je rozsáhlý softwarový systém? 4. Co představují specifické modely pro modelování software? Úkoly k zamyšlení: 1. Co si dosud představujete pod pojmem architektura software? 2. Myslíte si, že formální notace jednoduchého objektového programu dostatečně ilustruje jeho vlastnosti? 9 Literatura [ArNeu07] Arlow, J., Neustad, I. UML 2 a unifikovaný proces vývoje aplikací. Brno: [Som010] [wiksof] Computer Press, ISBN Sommerville, I. Software Engineering (the 9 th edition). London: Publisher PEARSON, ISBN 10: [Kad04] Kadlec, V.: Agilní programování. Metodiky efektivního vývoje software. Brno: Computer Press, ISBN [Rich96] Richta, K.: Softwarové inženýrství I. Praha: Vydavatelství ČVUT,

67 VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky SOFTWAROVÉ INŽENÝRSTVÍ ČÁST II. ARCHITEKTURY SOFTWARE STUDIJNÍ TEXT PRO KOMBINOVANOU FORMU STUDIA Milan Mišovič 2011

68 Prof. RNDr. Milan Mišovič, CSc. SOFTWAROVÉ INŽENÝRSTVÍ 1. vydání Vydala Vysoká škola polytechnická Jihlava, Tolstého 16, Jihlava, 2011 Tisk Ediční oddělení VŠPJ, Tolstého 16, Jihlava Za jazykovou a věcnou správnost obsahu díla odpovídá autor. Text neprošel jazykovou ani redakční úpravou. Milan Mišovič, 2011

69 Obsah Část II. Architektura software 1 Úvod Pojetí architektury v malém a velkém Historie pojmu Architektura IS Vzory architektury Pojetí architektury v komponentách Architektura založená na vrstvách Architektura založená na úrovních Modulární architektura Axiomy modulární architektury Koncepce řídících vazeb v modulárním systému Některá reálná pojetí Modulární architektury Jazyk UML a architektura rozsáhlého software Architektura klient server Distribuovaná objektová architektura Distribuovaná architektura na komponentách Realizační modely komponentové architektury Servisně orientovaná architektura SOA Podnikové služby Pojetí logické architektury rozsáhlého softwarového systému Modelování logické architektury Proces tvorby logické architektury Úkol A: Průzkum prvků architektury Úkol B: Definice přehledu architektury Úkol C: Dokumentace rozhodnutí o architektuře Literatura... 41

70 Část II. Architektura software Učební cíle: Seznámit se 1. se všemi vzory architektury software v pojetí malém a velkém, 2. problematikou zabezpečení jednotlivých vzorů architektur software. Znát 1. základy často používaných architektur software (Klient server, komponentová architektura), 2. základy pojetí logické, návrhové a fyzické architektury, základy prvotního přístupu k logické architektuře. Umět, mít dovednosti 1. VŠECHNY TYPY ARCITEKTUR: zvážit na základě vlastností problémové domény, která architektura je pro cílový komputerizační software nejvhodnější. 2. ARCHITEKTURY ve velkém: sestavovat prvotní schémata logické architektury. 1 Úvod Ačkoliv na první pohled se mnoho programátorů nezabývá problematikou architektury svých aplikací, přesto jimi vytvořené aplikace jistou architekturu mají a jde jen o to tento pojem precisněji definovat. Porozumění podstatě pojmu architektura dá možnost se k její tvorbě cílevědomě postavit a využívat možnosti, které pro software přináší. Architektura software není jen jeho pouhá struktura. Ano, je to sice členění na jisté architektonické jednotky, které je obrazem struktury, ale jde rovněž o vzájemný život těchto jednotek v softwarovém celku. To ovšem vyžaduje vytvoření jistých pravidel, platných pro všechny jednotky, z nichž je software složen: 1. Pravidla pro koncepci jednotek (složení jednotek). 2. Pravidla pro vzájemnou spolupráci jednotek (přechody a vstupní a výstupní interface pro spolupráci). 3. Pravidla pro konzistentnost jednotek (říkající, že dvě jednotky jsou zcela zaměnitelné v sestavě softwarového celku s danou architekturou). Je již alespoň trochu zřejmé, že architektura, postavená na poměrně inteligentních jednotkách, přinese softwarovému celku jisté výhody: 1. Vhodné rozčlenění celkové funkcionality software mezi jednotlivé jednotky, což umožní pečlivější a hlubší propracování dílčích aktivit a méně analytických a programátorských chyb. 2. Snadnější modifikaci funkcionality celku, protože víme kterou jednotku/-y máme modifikovat a kterou/-é ne. 3. Využití distribuce jednotlivých jednotek do operační paměti a jejich spouštění, jen tehdy, kdy jsou potřebné. Co ale úspěšné využití možností cílově budované architektury od programátora vyžaduje? Pečlivou analytickou práci s funkcionalitou software (požadavky na funkcionalitu). Návrh architektury prostřednictvím návrhu architektonických jednotek. Chápání života jednotek v celku ze systémového pohledu. Analytickou práci nad koncepcí a životem architektonických jednotek. Vytvoření jisté deskripce architektury, např. graficky, verbálně, -4-

71 Pochopitelně, velmi jednoduché aplikace je jistě možné oprostit od architektury. Na druhé straně u robustních aplikací, které již vyhovují pojetí rozsáhlých softwarových systémů, se architekturou již musíme pečlivě zabývat. V této části vzdělávacího materiálu nejprve rozebereme pojetí architektury, tak jak se postupně vyvíjelo a upřesňovalo, potom popíšeme jednotlivé typy-vzory architektury, což umožní jejich snadnější využití. Praxe ukazuje, že architekturou robustných aplikací se musíme zabývat počínaje zpracováním požadavků na funkcionalitu cílového software. Nejen že musíme stanovit mapování požadavků do architektonických jednotek, ale rovněž navrhnout spolupráci jednotek. Tyto analytické práce vedou k tzv. logické architektuře. Nic není naprogramováno, ale je již jistá vize jak to s architekturou robustné aplikace bude vypadat. Dokonce je možné tuto logickou architekturu naprogramovat a použít jako elektronický spustitelný základ pro tzv. návrhovou architekturu a rovněž pro závěr fyzickou (naprogramovanou) a nasazenou architekturu. Aby práce na tvorbě cílového software měla v produkční softwarové firmě jistý řád, často se problematikou funkcionality zabývá architekt požadavků a architekturou zase hlavní softwarový architekt. Více pochopení architektury přinese až vlastní uplatnění objektové metodiky UP (Unified Process), kde budou vysvětleny používané postupy, grafické notace a rozdíly mezi logickou, návrhovou a fyzickou architekturou (viz Část IV. Vývoj objektových aplikací podle metodiky UP). Dnes existují konkrétní vývojové systémy, pro které jsou všechna potřebná architektonická pravidla stanovena a v podpůrném vývojovém software-framework podporována. Často se u prvního přístupu k architektuře cílového software za architektonické jednotky považují podsystémy nebo moduly. Později se obojí zobecňuje zavedením komponenty. Použití podsystémů, nebo modulů vychází z prvního přístupu k architektuře cílového software pod vlivem relevantních vlastností komputerizované problémové domény. -5-

72 2 Pojetí architektury v malém a velkém. Cíle: Znát (umět vysvětlit): 1. Možná pojetí pojmu architektura software. 2. Pojetí architektury na komponentách. 3. Základní vlastnosti komponent (struktura, chování, interface-rozhraní, přechody). 4. Seznamy typů-vzorů architektur software v malém a velkém. Dovednosti (umět prakticky): 1. Uplatnit znalosti pro praktické definování architektonických jednotek. 2. Uplatnit znalosti pro prvotní přístup k architektuře cílového software z hlediska relevantních atributů komputerizované problémové domény. Klíčová slova: Architektura software, komponenta, rozhraní komponenty, chování komponenty 2.1 Historie pojmu Architektura IS Účelem této kapitoly je pochopit koncepci architektury software, pochopení historického upřesňování architektury. Pojetí tvorby logické architektury a její převod do návrhové podoby tato kapitola nepodává. V definici architektury softwarového systému je značná nejednotnost topových informatiků. Jedna definice je uvedena v příručce jazyka UML The Unified Modeling Language Reference Manual, viz [RuJaBo, 99] a zní takto: Architektura softwarového systému je jeho organizační struktura, včetně jeho rozkladu na součásti, jejich propojitelnosti, interakce, mechanismů a směrných zásad, která proniká do návrhu systému. Jiná definice je uvedená ve standardu IEEE, ta zní následovně: Architektura softwarového systému je jeho nejvyšší úroveň koncepce v jeho vlastním prostředí. Nakonec, Ian Sommerville ve své knize Software Engineering, viz [Som010], charakterizuje architekturu 1 softwarového systému a rozlišuje dvě její úrovně. První je architektura v malém, tj. jednoduchých programů a aplikací. Druhá je architektura ve velkém, tj. rozsáhlých programových systémů (RPS). První je pro něj významná z důvodu časté tvorby aplikací. Druhá je architekturou software podnikových informačních systémů, často založená na uplatnění distributivnosti internetu. Druhou architekturu považuje za systémový komplex komponent, s jejich osobitým chováním a vzájemným životem (vazby mezi sebou a distribuce do výpočetních uzlů). 2.2 Vzory architektury Za vzory architektury v malém se považují: Architektura založená na vrstvách. Architektura založená na repository. Architektura založená na úrovních. Modulární architektura (na rozhraní obou pojetí). 1 Architektura softwarového systému je jednou z jeho systémových vlastností a je už dnes v Softwarovém inženýrství dostatečně přesně definována. -6-

73 Za vzory architektury ve velkém se považují: Architektura klient server. Portálová architektura. Aplikační architektura. Distribuovaná objektová architektura na komponentách. Servisně orientovaná architektura SOA. 2.3 Pojetí architektury v komponentách Architektura rozsáhlého softwarového systému je definována v IEEE , IEEE Recommended Practice for Architectural Description of Software Intensive Systems následovně: Architektura je základní organizace systému, dána jeho komponentami, vzájemnými vztahy těchto komponent a jejich vztahy k okolnímu prostředí a principy řídícími jejich návrh a evoluci. Jak jsme již viděli, je možné uvést celou řadu různých definic architektury, ovšem pojem komponenta v nich není přesně definován, podobně jako v předchozí definici. Je to z důvodu možné, volné interpretace např. prostřednictvím podsystému nebo modulu. Skutečné pojetí objektové komponenty je definováno až v UML 2.2 z roku 2009 a toto pojetí je dnes určující. Má následující znění: Komponenta představuje modulární část systému, jež zapouzdřuje svůj obsah, a v rámci daného prostředí jsou její projevy nahraditelné. Komponenta definuje své chování v podobě poskytovaných a požadovaných rozhraní. Jako taková slouží komponenta jako typ, jehož konformita je definována právě těmito poskytovanými a vyžadovanými rozhraními (zahrnujícími jak jejich statickou, tak i dynamickou sémantiku). Jedna komponenta tedy může být nahrazena druhou pouze tehdy, pokud obě jsou typově konformní. Tato definice komponenty je používána v obou metodikách RUP a UP. Z uvedeného plyne, že architektura se zabývá především strukturou systému a jeho chováním prostřednictvím komponent. Za prvky architektury jsou považovány: komponenty, vztahy komponent, chování komponent, rozhraní komponent. V objektovém pojetí je komponenta chápána jako třída, takže můžeme vyrábět její instance. Pro tvorbu jednoduchých aplikací si budeme více všímat jen architektury v malém. V následujících kapitolách budou vysvětleny jednotlivé typy-vzory architektur. Shrnutí kapitoly: Kapitola podává základní přehled o pojetí architektury software a skrovně naznačuje rovněž její vývoj. Pojetí vylučuje chápání architektury jen jako struktury software, ačkoliv na strukturu je v architektuře brán ohled. Důležité je ovšem členění software na architektonické jednotky, jejich chování dané funkcionalitou na požadavcích uživatelů, souhrn interface jednotek pro vzájemnou spolupráci a schéma jejich vzájemných komunikací pomocí zpráv. Je pochopitelné, že vše musí být popsáno buď verbálně, nebo graficky. Kapitola uvádí seznamy typů-vzorů architektur pro oba přístupy - v malém a velkém. Σ -7-

74 Pojmy k zapamatování: Architektura software, struktura software, architektonická jednotka, komponenta, chování komponenty, rozhraní-interface komponent. Testy a otázky: 1. Co je vlastně architektura software? 2. Proč se zavádí architektonická jednotka a jakou má souvislost s funkcionalitou software? 3. Myslíte si, že definice architektury na komponentách je dnes nejpřesnější? 4. Co tvoří atributy komponenty. Úkoly k zamyšlení: 1. Proč se vlastně o architektuře software začalo mluvit, jaké jsou toho důvody? 2. Jaký je rozdíl mezi architekturou v malém a velkém? -8-

75 3 Architektura založená na vrstvách Kapitola je jen informativní. Vrstvená architektura je založena na rozlišení, tj. separaci a nezávislosti jistých vrstev v aplikaci. Separace, tj. vydělení vrstev nemusí být fyzické, ale je logické. Rozlišení vrstev je rovněž zužitkováno ve vývoji samotného kódu aplikace, protože to podporuje její inkrementální vývoj. Obecně se uznává, že právě separace a nezávislost jsou základem vrstvené architektury, protože zabezpečují možnost lokálního provádění změn, které jsou již náležící do jednotlivých vrstev aplikace. A nejen to. Jestliže se mezi vrstvami zřídí rozhraní, je potom možné některou vrstvu vyměnit za vrstvu kompatibilní, přičemž kompatibilita je založena na respektování rozhraní a funkcionality měněné vrstvy. Další možností vrstvené architektury je přenositelnost (portabilita) vrstev, která ovšem vyžaduje delšího vysvětlení. Počet vrstev je libovolný, často dán požadavkem přijatelné transparentnosti softwarové aplikace. Následující obecné schéma je vlastně metamodelem čtyřvrstvé architektury a snadno to bude model pro třívrstvou architekturu, když Autentizaci a Autorizaci zabalíme do vrstvy Uživatelského GUI. Uživatelské GUI Autentizace a autorizace klienta Jádro business logiky Správa databáze, podpora od operačního systému Obrázek 1: Metamodel čtyřvrstvé aplikace (upraveno, zdroj [Som010] ). Vrstvená architektura, uvedená v metamodelu, je vlastně konceptuálním pohledem na architekturu aplikace. Vrstvená architektura založená na repository: Zajímavým případem vrstvené architektury je její založení na repository součást informační infrastruktury podniku. Tato architektura je případem, kdy kolekce vrstev aplikace může sdílet společná data, která jsou uložena buď v bázi dat, nebo v reposirory. V obou případech se jedná o trvalejší data, na jejichž podstatě může být organizováno rozhraní mezi vrstvami. Říkáme, že aplikace je typu Data-driven. Vrstvená architektura založená na BD Na rozdíl od využití repository, které musíme obalit zprostředkovací funkcionalitou pro data, je uložení v BD jednodušší, protože můžeme využít již známých databázových strojů systémů řízení BD. -9-

76 4 Architektura založená na úrovních Cíle: Znát (umět vysvětlit): 1. Podstata pojetí úrovňové architektury, co je úroveň?. 2. Obecná schémata dvou a tříúrovňové architektury. 3. Charakterizovat využití úrovňové architektury u některých vývojových prostředí. 4. Jak fyzicky realizovat jednotlivé úrovně? Dovednosti (umět prakticky): 3. Využít zvládnuté vývojové prostředí k tvorbě dvouúrovňových desktopových aplikací. 1. Využít zvládnuté vývojové prostředí využívající platformu internetu k tvorbě tříúrovňových aplikací. Klíčová slova: Úroveň, GUI, business procedury, data Základem úrovňové architektury je pojetí úrovně: Úroveň (level) představuje jisté seskupení vzájemně související logiky zpracování. Příkladem jsou aplikace s třemi úrovněmi (víceúrovňová architektura): prezentační, business logika a datová. Úrovňová architektura je logickou architekturou, a jednotlivé úrovně mohou být různě fyzicky rozděleny. Stačí, porovnáme-li odlišnosti fyzického řešení tříúrovňové architektury ve formě desktopové a webové aplikace (kde jsou fyzicky umístěné jednotlivé úrovně?). Úroveň je dosti vysokou abstrakcí fyzické realizace této architektury. Abychom pochopily rozdíl mezi vrstvou a úrovní, uvedeme základ pojetí vrstvy: Vrstva (layer) je obecnější než úroveň a na vrstvách založená architektura se označuje jako vrstvená architektura. Vrstvená architektura představuje rozmístění architektonických jednotek (např. komponent) do jednotlivých vrstev, přičemž se rozlišuje vrstva vrcholová, vrstva nejnižší a potom vrstvy mezi nimi. Interakce (často nazývaná striktní/nestriktní) architektonických jednotek v jednotlivých vrstvách je stanovena speciálními interakčními pravidly. Následující dva obrázky ukazují interpretaci obecného schématu úrovňové architektury a používají pro společná data jejich uložení v bázi dat - BD. Jde o desktopové aplikace. První obrázek naznačuje jen dvě úrovně: business procedury + GUI a úroveň datová. Každá z nich má svou specifickou logiku zpracování (procesů, dat). Druhý obrázek naznačuje tři úrovně: prezentační - GUI, business procedury a datová. Oba dva případy mají funkcionalitu autentizace a autorizace klienta uloženou v úrovni GUI. Otázkou teď je, jak fyzicky jednotlivé úrovně realizujeme. Je např. možné konstruovat desktopovou aplikaci a v ní realizovat dvě úrovně. K tomu nám postačí mnoho obojetných (sekvenčně/objektový vývoj software) vývojových prostředí, např. celé Visual studio (Visual Basic, C#) od firmy Microsoft, nebo Delphi od původní firmy Borland. Druhou možností je realizovat úrovňovou aplikaci na platformě internetu. Potom ovšem bude nutno participovat rovněž na architektuře Client-server. Obecně platí, že úroveň GUI je na straně klienta a zbývající dvě úrovně (business procedury, datová úroveň) na straně serveru. -10-

77 Prvky GUI 1. úroveň kód Logika správy dat datové asociace, události události kód Aktivitní (business) procedury události Událostní procedury kód Poskytovatel spojení Data BD Tabulky 2. úroveň Databázový server Prvky GUI datové asociace datové asociace kód 2. úroveň kód Logika správy dat události BUSINESS procedury Asociace na základě událostí kód Reakční procedury 1. úroveň Poskytovatel BD 3. úroveň Obrázek 2: Ilustrace dvou a tří úrovní softwarové aplikace, s využitím BD pro uložení společných dat pro všechny úrovně. -11-

78 Poznámka: Aplikujme na obrázek 2 pojetí vrstvy. 1. Pojetí vrstvy a úrovně je rozlišitelné jen ve fyzické rovině. Např. všechny úrovně mohou být v jedné fyzické vrstvě. Nebo, zcela opačně, každá úroveň může být v jedné fyzické vrstvě. Potom tedy obrázek 2 je ilustrací dvou vrstev a tří vrstev a v každé vrstvě je jedna úroveň / více úrovní. 2. Pokud se např. jedná o aplikaci architektury klient-server, potom je úroveň GUI uložena ve vrstvě prohlížeče, úroveň datová ve vrstvě vzdáleného datového serveru a úroveň business kódu je uložena na vzdáleném provozním serveru. 3. Je sice otázkou proč někteří topoví informatici pojmy úroveň a vrstva zavedli. Zamyšlení nad touto problematikou ponecháme čtenáři. Doporučujeme používat jen pojem vrstva. Shrnutí kapitoly: V kapitole se podává vysvětlení pojmu úroveň jako seskupení vzájemně souvisící logiky zpracování procesů a dat. Naznačují se nejznámější úrovně a možnost jejich fyzické realizace. Σ Pojmy k zapamatování: Vrstva, úroveň Úkoly k zamyšlení: Umíte realizovat desktopové úrovňové aplikace a úrovňové aplikace na platformě internetu? -12-

79 5 Modulární architektura Cíle: Znát (umět vysvětlit): 1. Zavedení modulu a jeho struktury. 2. Zavedení sémantické algebry a jednotlivé operace. 3. Charakteristické grafy modulární struktury? 4. Podstatu zavedení axiomů modulární struktury. Dovednosti (umět prakticky): 1. Praktické zavedení modulární architektury. 2. Sestrojit charakteristické grafy pro modulární architekturu. Klíčová slova: Modul, struktura modulu, lokální data modulu, globální data modulu, procedury modulu, sémantická operace, charakteristický graf, axiom modulární architektury Modulární architektura byla sice zavedena v době rozkvětu strukturovaného paradigmatu, ale je v podstatě na paradigmatu nezávislá. Rovněž je nezávislá na webové platformě a je bez problémů aplikovatelná pro desktopové aplikace. Základními prvky jsou moduly, které mají své chování (funkcionalitu, vstupní a výstupní data) a jsou vybaveny vstupními a výstupními rozhraními pro komunikaci s jinými moduly v rámci modulárního systému. Je-li modulární systém organizován jako monolit, tj. moduly nejsou fyzicky mimo systém, je modulární architektura chápána jako architektura v malém. Pro oba případy chápání architektury je modulární systém podporován specifickým modulárním frame work prostředím, které by mělo být součástí operačního systému provozního počítače. Jestliže je modulární systém složen jen z jádra a integrátoru modulů, které jsou fyzicky mimo modulární systém (např. uložené ve frame work paměti operačního systému počítače), je tato architektura chápána jako architektura ve velkém. Nejde ovšem o skutečnou distribuci modulů, ale jen o realizaci reference s návratem. Následující text je věnován pojetí modulárního systému, teoretickým postřehům a strukturám modulárního systému, ačkoliv sami vidíme, že je na rozhraní mezi architekturou v malém a velkém. Modulární programování je technika vybízející programátora k rozložení aplikace na jednodušší části moduly se zachováním jejich celkového vzájemného kontextu (vazby). Členění aplikace na moduly by mělo sledovat především dekompozici funkcionality aplikace. Obecně se do modulů dekomponuje nejen funkcionalita, ale i další atributy programů: funkcionalita aplikace, která je zapsána pomocí specifikací na požadavky žadatele, data a jejich datové vazby, řízení přechodů mezi moduly, řídící vazby, kompetence na data a operace s nimi. Moduly jsou základní prvky modulárního systému, a mohou mít následující složení: -13-

80 deklarace lokálních datových struktur výkonná část modulu, procedury modulu lokální data globální data modulu Poznámka: 1. Globální data modulu M jsou přístupná všem procedurám ostatních modulů. 2. V každé proceduře modulu M se mohou používat trojí data: a. Lokální data, přístupná všem procedurám modulu M b. parametry procedur (formální - skutečné parametry), c. nelokální data modulu M (globální data ostatních modulů a globální data modulu M). Vzhledem k tomu musely být v souvislosti s modulárním programováním řešeny i teoretické otázky. Postupně se v odborné literatuře objevily články o sémantickém systému vhodných relací mezi moduly, pomocí kterých byly reprezentovány známé vazby. Výzkum pokročil v průběhu 90. let tak daleko, že nad modulární strukturou byla zavedena teorie s axiomy, užitečným jazykem, logikou a velmi schopnou algebrou operací. To vše umožnilo komputerizovat vývoj modulárního systému a vytvořit potřebné vývojové prostředí. Základem byly relace Použití... A B... Volání, odkaz a volání modulu B z podnětu modulu A. Jde o to, že procedury modulu A se obrací na procedury modulu B. Přístup... na globální data A B... Procedury modulu A používají globální data modulu B jako svá nelokální data (čtení/změna globálních dat modulu B). čtení B Mo A B Modul A má jen přístup (jen čtení) na globální data modulu B. ochrana... A B... Modul B je chráněn před zásahy z modulu A. Procedury modulu A nemohou používat globální data modulu B jako svá nelokální data. Graf modulárního systému je tvořen uzly-moduly a hrany jsou vazby mezi moduly. Jednotlivé relace mají vlastnosti, které se dají vyšetřovat. Nad modulární strukturou se dá vybudovat teorie s axiomy, jazykem a logikou. -14-

81 Pro orientaci v modulární struktuře je potřebné nakreslit alespoň dva grafy: 1. G 1, pro globální modulární strukturu aplikace, se zaměřením na vazby mezi moduly, na disponibilitu modulů (uzly jsou moduly). 2. G 2, pro strukturu každého z modulů (uzly jsou procedury modulu). Příklad 5-1 Nechť jsou dány čtyři moduly A, B, C a D. Jejich graf G 1 má tvar uvedený níže. Je zřejmé, že modul A musí být k dispozici vždy, když to žádá kterýkoli z modulů C a D. Rovněž modul C musí být k dispozici modulu B a modul B k dispozici modulu A. Modul D je chráněn od zásahů modulu B. Zaveďme pro relaci následující rozšíření: -15-

82 Na základě zavedených relací, které dostatečně definují vazby mezi jednotlivými moduly, a zavedeným rozšířením relace můžeme vyslovit následující axiomy vazeb mezi moduly, které jsou základem modulární architektury. -16-

83 5.1 Axiomy modulární architektury * 5.2 Koncepce řídících vazeb v modulárním systému Řídící vazby mezi moduly se zobrazují pomocí grafu řízení. Uzly tohoto grafu jsou moduly a nebývají kresleny tak jako běžné uzly grafu (často je to obdélník). Existuje několik struktur řídících vazeb, např.: -17-

84 1. Přísná struktura s jediným řídícím modulem M 0 (šipka je zde řídící vazba). M 0 M 1 M 2 M 3 Modul M 0 zajišťuje všechna logická rozhodnutí, ale neprovádí žádná zpracování. Vedle toho zprostředkuje přenos dat mezi moduly a vstup/výstup dat do/ze systému modulárních systémů. 2. Přísná struktura s jediným řídícím modulem M 0 a zpracovatelskými moduly do hlubší úrovně BEZ NÁVRATŮ NA ŘÍDÍCÍ MODUL. 3. Stromovitá struktura s řídícími návraty o jednu úroveň výše. Tato struktura odpovídá grafu se speciálními návraty. 5.3 Některá reálná pojetí Modulární architektury Mezi nejznámější reálně fungující implementace Modulárního programování patří: -18-

85 Modulární programování založené na Windows formulářích v technologii vývoje Microsoft desktopových aplikací. modul = win formulář + kód za formulářem Modulární programování založené na pojetí DHTML stránek a jejich formulářů na platformě WWW služby Internetu. modul = DHTML formulář + kód na formuláři Modulární programování založené na pojetí komponenty na bázi Objektového programování a platformě WWW služby Internetu. Modulární programování založené na pojetí aplikace jako MODULU v balíku aplikací IS podniku (tzv. Aplikační architektura ). Důležité je ovšem to, co modulární programování přineslo: zavedení struktury software pomocí základního strukturálního prvku - modulu, interpretaci pojetí modulárního systému v praxi, nutnost klasifikovat vazby mezi základními prvky - moduly, najít formální aparát pro zaznamenání kvality software rozloženého do základních prvků - modulů. Shrnutí kapitoly: Kapitola zavádí pojetí modulární architektury. Zavádí se pojem modulu a jeho struktury. Pro modulární strukturu se zavádí sémantická algebra, dva charakteristické grafy a nakonec rovněž relevantní axiomy. Ukazuje se, kde se dodnes vyskytuje uplatnění modulární architektury. Σ Pojmy k zapamatování: Modul, charakteristický graf, sémantická operace, axiom -19-

86 6 Jazyk UML a architektura rozsáhlého software Kapitola je jen informativní. Jazyk UML předkládá možnost podívat se na architekturu prostřednictvím pěti pohledů, převzatých od informatika Philippe Kruchtena: pohled případů užití, pohled logický, pohled procesů, pohled implementace a pohled nasazení Co do těchto pohledů patří, pochopíme až v implementaci objektové metodiky UP. Teď alespoň stručně o jednotlivých pohledech ačkoliv s některými se nemusíme vůbec setkat. Pohled případů užití: Pohled zachycuje funkcionální/nefunkcionální požadavky na softwarový systém a prezentuje je jako konzistentní množinu diagramů případů užití, čímž se vytváří základ tvorby všech následujících pohledů. Všechny ostatní pohledy jsou potom derivovány od pohledu případů užití. Logický pohled: Logický pohled obsahuje především slovník termínů problémové oblasti, která je modelována. Dále zachycuje množinu tříd a objektů. V logickém pohledu je kladen důraz na zobrazení způsobu, jak třídy a objekty, které tvoří základ modelované domény, modelují její chování. Pohled procesů: Pohled procesů spočívá v modelování procesů a tzv. procesních vláken (procesní logika problémové domény). Je to v podstatě procesově orientovaná varianta logického pohledu se stejnými artefakty. Procesy jsou považovány za požadavky, jsou mapovány do případů užití a funkcionálně dokumentovány v aktivitních diagramech. Pohled implementace: Je to pohled, v kterém se modelují zejména soubory a komponenty softwarového systému, které jsou nositeli kódového základu systému. Vedle toho, pohled sleduje vzájemné závislosti mezi jednotlivými komponentami a rovněž řízení konfigurace na platformě těchto komponent. V implementačním pohledu se rovněž odráží verzování softwarového systému. Architektonický diagram komponent dokumentuje život komponent v celku cílového software. Pohled nasazení: Pohled nasazení zvažuje množinu výpočetních uzlů, na které má být softwarový systém nasazen. Vedle toho ilustruje distribuci komponent na příslušné uzly distribuovaného systému. Situaci nasazení dokumentuje diagram nasazení. Všechny uvedené pohledy jsou obsaženy v jednotlivých diagramech jazyka UML. Budemeli se později řídit životním cyklem metodik RUP/UP, tak zažijeme postupné upřesňování zmíněných pohledů a konečná architektura je získána pomocí mnoha doplňování a upravování již načrtnutých diagramů (logické, konceptuální a návrhové povahy). -20-

87 7 Architektura klient server Cíle: Znát (umět vysvětlit): 5. Podstatu architektury Klient - server. 6. Hlavní komponenty systému zabezpečení architektury Klient server a jejich funkcionalitu. 7. Strukturu software architektury Klient server. 8. Filosofie práce internetu se software architektury Klient server. Dovednosti (umět prakticky): 2. Sestavit strukturu konkrétní webové aplikace s architekturou Klient - server. 3. Uplatnit v praxi znalost filosofie internetu, podstaty tenkého klienta a serverových stránek. Klíčová slova: Server, služby, klient Je to velmi často používaná run-time architektura pro distribuované systémy. Funkcionalita v Klient server softwarových systémech je založena na službách. Požadavky na služby zadávají klienti a funkcionalita na serverech zasílá klientům odpovědi na zaslané požadavky. Hardwarově je systém zabezpečen např. klientským počítačem a vzdáleným provozním serverem. Software architektury klient server je složen z části klientské a části serverové. Mezi oběma částmi musí být vytvořen, použitím počítačové sítě, distribuovaný přechod založený na protokolu. Architektura Klient server je multi-dimensionální, tj. může zahrnovat množinu klientů a množinu serverů. Za hlavní komponenty systému, který používá architekturu Klient server, se považují: Množina serverů, a jejich operační systémy a asociované překladače programovacích jazyků. Distribuční funkce serverů je zabezpečena v jejich operačních systémech (na základě speciálních strojových instrukcí procesorů, jimiž jsou servery vybaveny). Množina služeb, které koncipuje programátor v serverové části svého uživatelského software. Uživatelský software na straně klienta a na straně serveru. Uživatelský software na straně klienta zasílá požadavky na služby. Uživatelský software na straně serveru vyrábí odpovědi na služby. Obě části tvoří dohromady software s architekturou Klient server. Pomocný software na straně klienta (prohlížeč a asociované překladače pro skripty). Síť a její realizační software, což umožní distribuovat mezi klientem a serverem požadavky na služby a výsledky jejich provedení. Většina Klient server systémů je implementována jako distribuované systémy, jejichž komponenty jsou pospojované pomocí internetových protokolů (zabezpečeno internetem). Služba formulovaná v serverové části uživatelského software může např. představovat čtení informace z BD a získaná informace je předána klientovi jako výsledek služby. Jestliže je serverová část založena na tzv. webovských DHTML stránkách, potom je služba formulovaná ve stanoveném kódu na serverové stránce a odpověď je zase, podle filosofie spolupráce klienta a serveru, z téže stránky zasílána klientovi. Jestliže na straně klienta je pouze jednoduchý pomocný software prohlížeč, který -21-

88 neumožní další zpracování výsledku služby, je klient označován termínem tenký klient. Opačně se tento klient označuje termínem tlustý klient. Obrovskou výhodou uživatelského software architektury klient server je vysoká schopnost distribuce, je to tedy distribuovaná architektura. Filosofie práce s webovými stránkami je obecně známá a programátory využívána. Webové aplikace jsou konstruovány jako uživatelský software architektury klient server např. o třech úrovních (úroveň je dána typy logiky zpracování) viz Obrázek 7-1, přičemž prezentační úroveň je na straně klienta, business úroveň je na straně provozního serveru a datová úroveň je na samostatném datovém serveru. Webová aplikace může být typu Datadriven. Prvky GUI datové asociace 2. úroveň na provozním serveru Logika zprac.dat kód - skripty Prvky pro správu dat datové asociace BUSINESS procedury události kód asociace na základě událostí kód - skripty Reakční procedury Poskytovatel BD 1. úroveň na straně klienta 3. úroveň na datovém serveru Obrázek 7-1: Klasická úrovňová webová aplikace architektury Klient server. Na druhé straně je struktura klasické webové aplikace architektury klient - server dána následujícím obrázkem. START Úvodní stránka Skripty webové sídlo aplikace STOP Řídící a pracovní stránka Skripty Skripty ostatní stránky Skript Skripty Obrázek 7-2: Struktura klasické webové aplikace. -22-

89 Řízení v aplikaci je velmi jednoduché, začíná Úvodní stránkou, poté se musí přejít na Řídící a pracovní stránku (která je na obrazovce neustále) a poté po výběru funkcionality (jednoho z hyperlinků) se přejde na danou stránku a návrat je opět na Řídící a pracovní stránku automaticky. Úvodní stránka Řídící a pracovní stránka Ostatní stránky Obrázek 7-3: Řízení v klasické webové aplikaci. Poznámka: 1. Architektura Klient server zavádí pojem tenký klient, který je reprezentován běžným prohlížečem. Takový klient zobrazí data došlá ze strany serveru, ale nemůže je zpracovávat. Výhodou takového klienta je jednoduchý koncový počítač s prohlížečem. 2. Druhým typem klienta je tlustý klient, který vyžaduje schopný koncový počítač, kterému je dána možnost dalšího zpracování došlých dat. 3. Ačkoliv na Obrázku 7-1 je webová aplikace architektury Klient server, je této architektuře podčiněna úrovňová architektura. Shrnutí kapitoly: Kapitola vysvětluje pojetí architektury Klient server, její zabezpečení a základní vlastnosti. Uvádí členění software architektury Klient server na dvě části a vysvětluje poslání každé z nich. Σ Pojmy k zapamatování: Provozní server, Klient server, služba, klientský software, serverový software, pomocný software Testy a otázky: 1. Charakterizujte složení software architektury klient server? 2. Čím je zabezpečen provoz software architektury Klient server? Úkoly k zamyšlení: 1. V jakých vývojových systémech lze tvořit aplikace architektury Klient server? 2. Jaká je filosofie práce webové aplikace architektury Klient - server? -23-

90 8 Distribuovaná objektová architektura Cíle: Seznámit se: S podstatou technologie distribuovaných objektových architektur. Klíčová slova: Technologie distribuovaných objektových modulů Hlavní myšlenkou distribuované objektové architektury je rozdělit software na jisté moduly, chápané jako objekty, které mohou být uloženy na mnoha počítačích v rámci počítačové sítě. Základem komunikace mezi moduly je jejich chápání jako objektů a použití posílání zpráv a příjmem odpovědí. To je základ komunikace mezi objekty v objektovém paradigmatu. První aplikace s touto architekturou vznikly na počátku 90. let minulého století. Myslím si, že není zde nutné opět vysvětlovat objektové myšlení objektového paradigmatu. To vše jsme zvládli v Části III. Objektové myšlení a jazyk UML. Vzpomeňme teď objektové jazyky C++, C# a Java, které značně respektují objektové myšlení. Tyto jazyky umožňují tvorbu software jako objektových monolitů. Přesto se často specifikují objektové jazyky, které mají přímou podporu objektové distribuované technologie a jsou součástí distribuovaných technologií typu CORBA (Common Object Request Broker Architecture) od sdružení OMG, DCOM (Distributed COM-Component Object Model) a.net od Microsoftu a nakonec Java RMI (Remote Method Invocation) od společnosti Oracle. Každá z uvedených technologií je značně komplikovaná a těžko zde vysvětlíme jejich detaily. Co je všem ale společné? 1. Komunikační přístup klienta, řízení tvorby modulů - objektů a jejich interface. 2. Řízení posílání zpráv a přebírání výsledků, získávání informací o všech modulech - objektech. 3. Prostředí (frame work), které podporuje funkcionalitu technologie. Velmi příjemnou pro práci studentů je nativní distribuovaná architektura pomocí mechanismu Java RMI, která je součástí jazyka Java společnosti Sun. Poznámka: 1. Všechny uvedené technologie neměly příliš daleko od myšlenky považovat zmíněné moduly objekty za komponenty. 2. Důsledným vztahem modul objekt komponenta se distribuované objektové metody dopracovaly k distribuovaným objektovým komponentám. Přívlastek objektové se často vynechává. Protože distribuované objektové technologie se používají až ve fázi KONSTRUKCE, tj. přímé tvorby cílového software, ve vývojových objektových metodikách, jsou přednášeny až v v předmětech typu Softwarové inženýrství 2. Předmět Softwarové inženýrství 1 je na rozdíl od předmětu Softwarové inženýrství 2 věnován obecným záležitostem tvorby software a detailům vybrané objektové metodiky. -24-

91 9 Distribuovaná architektura na komponentách. Cíle: Znát (umět vysvětlit): 1. Podstatu a poslání komponenty. 2. Definici komponenty a relevantní charakteristiku komponenty. 3. Co je kompatibilita komponent a jaké mé důsledky? 4. Podstatu standardu pro rozhraní, komponentový model. Dovednosti (umět prakticky): 1. Tvořit komponentové diagramy, navrhovat co bude rozhraní obsahovat. 2. Uplatnit získané poznatky o komponentách v hledání architektonického modelu cílového software. Klíčová slova: Komponenta, realizační komponentový model, rozhraní, kompatibilita komponent, operace, standard pro rozhraní, middleware, komponentový diagram Základem této problematiky bude pochopení komponentového modelu, samotných komponent jako nezávislých stavebních jednotek pro cílový software a dynamiky jejich života v komponentovém systému. Za základ komponentového systému (component-based software) je považováno: 1. Nezávislé komponenty, které jsou softwarovými jednotkami (elementárními, nebo složenými z jiných komponent) a které jsou zcela specifikovány svými rozhraními a vnitřními operacemi. To umožňuje výměnu jedné komponenty za komponentu kompatibilní jen na základě shodného rozhraní. 2. Zavedení standardu pro rozhraní, který se používá pro všechny komponenty v systému. Jestliže komponenty vyhovují tomuto standardu, potom jejich vnitřní operace nezávisí na programovacím jazyku a mohou být bez problémů začleněny do systému. 3. Zavedení middleware, tj. speciální software, které podporuje integraci komponent. Je to software, které zařizuje komunikaci mezi komponentami. 4. Definování vývojového procesu, který umožní zavádět do komponent požadovanou funkcionalitu a podporuje tvorbu middleware pro jejich vzájemnou komunikaci a respektuje pravidla implementačního komponentového modelu. Často se používá následující standardní definice komponenty: Komponenta je softwarový prvek, hovící standardnímu komponentovému modelu, která může být samostatně vyvíjena a měněna bez modifikace kompozičního standardu. Komponenty obecně definují služby prostřednictvím svých rozhraní, které poskytují jiným komponentám a rovněž definují služby, které komponenta potřebuje od jiných komponent. Následující obrázek komponentového diagramu ilustruje poskytovaná (nabízená) rozhraní I 1, I 2, I 4 a požadované rozhraní I 3 služeb komponenty A. Je použita grafická notace komponenty z UML. <<component>> A I 1 I 3 I 4 <<component>> B Požadované Poskytované (nabízené) I 2-25-

92 Mají-li dvě komponenty komunikovat, např. A, B, potom musí být požadavky rozhraní I 3 pokryty nabídkou rozhraní I 4. Komponentový model je definice standardů pro uskutečnění komponent, pro jejich dokumentaci a vývoj. Uvedeme některé implementační komponentové modely: Web Services model, Sun s Enterprise Java Beans model, Microsoft s.net model. Jak jsou definovány elementy rozhraní, tj. operace, parametry, je stanoveno jednotlivými implementačními komponentovými modely. Komponenty mohou být elementární, tj. nesloženy z dalších komponent, nebo opačně, mohou být složené. Pro vizualizaci složených komponent se používají v UML stanovené grafické notace. Následující obrázek ilustruje komponentu složenou z dvou komponent. Jestliže je každá komponenta realizována jako webová služba, potom je komponentový systém čistě distributivní. Pochopitelně, tato možnost je zabudována v příslušném implementačním komponentovém modelu. Tato implementace ovšem již převádí obecný komponentový model na model SOA. 9.1 Realizační modely komponentové architektury Dnes jsou často na komponentový model zaměřeny informační technologie, které se používají jednak pro realizaci komponent v procesu převodu logické architektury na architekturu návrhovou a potom pro její převod do zdrojového kódu. Jsou to definice standardů pro uskutečnění komponent, pro jejich dokumentaci a vývoj. Uvedeme některé z nich: 1. Web Services model, 2. Sun s Enterprise Java Beans model, 3. Microsoft s.net model. Tyto komponentové modely jsou docela obtížné pro zvládnutí. Pozoruhodné jsou všechny, ale několik slov prohodíme jen o prvním a třetím. Web Services Model je postaven na webových službách akceptovatelných v mnoha programovacích jazycích. Problematika webových služeb je součástí výuky např. jazyků Visual Basic, C# a dalších. Webová služba je potom prostředek k realizaci distributivní komponenty software podnikového IS. -26-

93 Modely patřící do Microsoft s.net model, označované jako COM/DCOM a COM+ jsou popsány v publikaci [Kač, 2000]. Model COM+ je již platný v operačním systému Win 2000 a je na platformě distribuovaných-vzdálených komponent. Problematika komponentového software bývá součástí výuky jazyka C++. Shrnutí kapitoly: Kapitola uvádí základy komponentové architektury. Je definováno pojetí komponenty, rozhraní pro komunikaci s jinými komponentami. Jsou naznačeny důsledky zavedení pojmu kompatibility komponent výhradně na obsahu rozhraní. V závěru kapitoly je uveden jednoduchý komponentový diagram a stručně diskutovány komponentové modely. Σ Pojmy k zapamatování: Komponenta, rozhraní, kompatibilita komponent, komponentový model, komponentový diagram Testy a otázky: 1. Co je rozhraní komponenty? 2. Co vlastně znamená zavedení standardu pro rozhraní komponent? Úkoly k zamyšlení: 1. Kdy hovoříme o distribuované komponentové architektuře? 2. Jak je pojetí komponent zabudováno v jazycích typu C, C ++ a C#? -27-

94 10 Servisně orientovaná architektura SOA. Cíle: Znát (umět vysvětlit): 9. Podstatu zavedení podnikové služby a servisně orientovaného podniku. 10. Podstatu komputerizace podnikových služeb pomocí webových služeb. 11. Filosofii komputerizace podnikových služeb, která je realizovaná pomocí SOA. Klíčová slova: Podniková služba, servisně orientovaný podnik, systém podnikových služeb, integrátor podnikových služeb, SOA Mnozí informatici a IT manažeři podniků chápou vznik servisně orientované architektury podnikových informačních systémů (PIS) jako odpověď na řešení nezabezpečené flexibility stavebních prvků aplikační architektury, tj. aplikací. V mnoha článcích, jejichž autory jsou zejména informatici, je servisní orientace funkcionality IS podniku přisuzována jen business software, které aktivity podniku komputerizuje. Soudí se tedy, že je to přirozenou vlastností software a ne podniku samotného. Podnik se potom této architektuře musí přizpůsobit. Problém je ovšem poněkud složitější. Zapomíná se totiž na již dlouhodobě fungující podniky/systémy založené na konzumaci služeb jiných podniků/systémů. A právě na tuto skutečnost chceme dále upozornit. Následující text je názorem informatika a může vyvolat námitky zejména ze strany expertů z oblasti managementu Podnikové služby V současné době existují poradenské systémy, které mají funkcionalitu vůči svým zákazníkům postavenou na tzv. poradenských službách. Jedna poradenská služba může být sestavena z jednoho nebo více poradenských procesů. Sekvence poradenských služeb, poskytovaných stejnému zákazníkovi, je považována za poradenský případ. Podobně fungují i orgány veřejné správy ČR. Poradenské systémy ovšem nejen poskytují, ale rovněž konzumují služby poskytované jinými podniky, případně veřejnou správou. Je teď otázka, jestli by se nemohla postavit funkcionalita podniku na poskytování vzájemných podnikových služeb mezi jeho odděleními (případně divizemi/úseky/sekcemi), včetně chápání toho, že oddělení může poskytovat jisté služby samo sobě. Půjde tedy o jakýsi způsob (se stanovenými pravidly) poskytování podnikových služeb na teritoriu podniku. Je tedy možné, i když vágně, chápat jednu podnikovou servisní službu jako jednotku aktivity, která může být složena z diskrétní funkcionality podniku (a discrete business functionality) nebo z jistého počtu vzájemně propojených podnikových procesů. V souladu s vyslovenou myšlenkou je v podnicích již chápána funkcionalita mnoha oddělení. Patří mezi ně např. Personální oddělení, Oddělení údržby, Poradenské centrum (zdravotní, pracovní, psychologické a finanční poradenství), Podniková hypoteční a úvěrová banka a další, které mohou být o speciální služby požádány z jiných oddělení. Je zřejmé, že jednotlivá oddělení mají své interní služby a četné, jakoby externí služby, které poskytují jiným oddělením. Ne vždy vystačí podnik jen se svými interními podnikovými službami. Je často nucen použít rovněž externí služby jiného podniku, např. nájemného dopravce v logistickém řetězci, marketingových služeb jiné firmy pro propagaci svých výrobků nebo prodávaného zboží, finančních služeb, uklízecí služby a podobně. Ukazuje se, že servisní kooperace podniků navzájem a oddělení v podniku na základě podnikových služeb má reálné opodstatnění. Podniková služba by se tak mohla stát jednotkou pro vyjádření funkcionality podniku jako systému, který konzumuje poskytované služby. Dokonce by se pro stejně oborově orientované podniky mohly tyto služby považovat za typové. Služby by tak mohly -28-

95 vytvořit: buď jinou podnikovou rovinu než jeho oddělení/divize/úseky/sekce a zaměstnanci, nebo rovinu zcela vzdálenou a s podnikem vůbec neasociovanou. Obecně se dá mluvit o zavedení speciálního abstraktního systému, systému podnikových služeb SPS (ESS Enterprise Service System), jehož základními prvky jsou podnikové služby a vazby mezi nimi. Aktivity všech organizačních celků podniku, patřících do podnikových procesních setů, se pak dají vyjádřit pomocí poskytnutí služeb ze systému SPS. Podnik potom buď systém SPS vlastní, anebo systém může vlastnit organizace mimo podnik samotný. Tato organizace se pak stává poskytovatelem podnikových služeb a podnik jejich konzumentem. Je mnoho podniků, jejichž reálný život je postaven jen na konzumaci služeb, tj. jejich aktivita je značně suplována poskytovanými podnikovými službami. Poskytování služeb, jinými slovy správa podnikových služeb, je jistě spojena s platebním systémem, na kterém je založen profit poskytovatele. Podnikové služby nemusí být rozsáhlými jednotkami aktivity a tedy je snadné je modifikovat a skládat, na čemž je postavena flexibilita systému SPS. Každá služba žádá jistá výchozí data (dodává je management konzumenta), která zpracovává a zobrazuje je do jistých výsledných dat, která vydává. To je v podniku velmi závažné pro jeho management, který skládání řídí a rovněž výsledná data jedné služby převádí na výchozí data jiné služby, která je k předchozí službě následníkem. Pochopitelně, management správy podnikových služeb (integrátor podnikových služeb) musí mít dokonalou představu o funkcionalitě poskytovaných služeb a využívat ji pro zabezpečení datové, procesní a komunikační integrity ve funkcionalitě postavené na podnikových službách. To může vést i na požadavek, aby poskytovatel danou službu adaptoval na specifické prostředí konzumenta (např. výrobně obchodní). Výchozí data Podniková služba Výsledná data Obrázek 9-1: Struktura podnikové služby Z již uvedeného plyne, že podnikové služby by měly vyhovovat následujícím požadavkům: 1. Celá funkcionalita podniku (business logic) je rozdělena na podnikové služby, které jsou potencionálně znovupoužitelné a představují nedělitelnou část funkcionality podniku, tj. např. transakci/proces, resp. jinou diskrétní neohraničenou aktivitu. 2. Podnikové služby jsou navzájem nezávislé, lze je sdružovat do celků (např. vláken), které mohou být považovány za nové podnikové služby. 3. Podnikové služby tvoří systém podnikových služeb se stanoveným rámcem pro vzájemnou spolupráci. 4. Popisy služeb, tj. výchozí a výsledná data, funkcionalita a rámec pro vzájemnou spolupráci jsou volně přístupné nejen managementu správy podnikových služeb. Přesto, že podnik značně konzumuje podnikové služby, nemusí mít rozsáhlý management jejich správy. To vše je dáno stupněm komputerizace podniku. Pro takový podnik je užitečné z trvalých sekvencí podnikových služeb vytvořit větší jednotky aktivity (business elements), např. vlákna podnikových služeb, které jsou opět považovány za služby. S takto vytvořenými řetězci se pracuje jednodušeji, než se samotnými elementárními podnikovými službami. -29-

96 Řetězec podnikových služeb nová služba Výchozí data řetězce Podnikové služby Výsledná data řetězce Obrázek 9-2: Struktura řetězce podnikových služeb nová služba Na základě rychle se měnícího výrobně-obchodního prostředí podniku je nutno adekvátně měnit rovněž podnikové služby, a to na základě změny do služby včleněných transakcí/procesů, popřípadě včleněné diskrétní aktivity. Nejsou pochybnosti o pružnosti, s kterou by to měl příslušný management podniku provádět pro své interní služby a management poskytovatele pro služby externí. Na základě uvedených myšlenek je zřejmé, že orientací na správu interních a poskytovaných - externích podnikových služeb a postavením veškeré funkcionality podniku na správě podnikových služeb, přechází podnik na tzv. servisně orientovaný podnik (SOE Service-Oriented Enterprise). Tato orientace, která je postavena na podnikových službách, má relevantní dopad na jeho organizační strukturu. Podnik již nemá ty své subjekty a asociovaný management, které by jinak zabezpečovaly konzumované podnikové služby. Vedle toho tato orientace vede na specifický způsob podnikového řízení a ustavení nového typu managementu managementu správy podnikových služeb, pečujícího o zdárnou manipulaci se všemi podnikovými službami v souladu s rámcem jejich vzájemné spolupráce (podstatou tohoto rámce je zachování datové, procesní a komunikační integrity ve funkcionalitě podniku). Dílčí závěr: 1. Bylo ukázáno, že pojetí podnikové služby je reálné, ne zavádějící. Je reálné ovšem i to, že více podniků žije z poskytování podnikových služeb, tj. z jejich plného funkcionálního zabezpečení a prodeje a mnoho podniků služby zase konzumuje. Aktivity podniku se dají reprezentovat podnikovými službami, i když některé z nich realizuje podnik sám. 2. Podniková služba se stává pružnou a znovupoužitelnou jednotkou aktivity, dobrým stavebním kamenem pro širší aktivitu podniku, snadno uplatnitelnou pro více podniků a snadno modifikovatelnou a udržitelnou v souladu s rychle se měnícím výrobně-obchodním prostředím podniků. 3. Z podnikových služeb lze vytvořit systém, který může zcela suplovat aktivity mnoha subjektů podniku konzumenta služeb. Za manipulaci s výsledky poskytovaných podnikových služeb je odpovědný specifický management konzumenta. Za uskutečnění poskytované služby je odpovědný poskytovatel. Na základě dosud uvedených poznatků o SOE a SOA je možno soudit, že jádrem výstavby PIS (podnikový informační systém) se servisně orientovanou architekturou je tvorba nově pojatých objektových aplikací konzumentů podnikových w-služeb. SOE a SOA tak vlastně koncipují nové paradigma pro tvorbu takových aplikací. Roli nově pojatých aplikací v PIS se servisně orientovanou architekturou ilustruje následující obrázek. -30-

97 Aplikace pro ERP Internet INTEGRÁTOR Požadavek/odpověď na podnikovou w-službu Repository interních w-služeb Repository externích w-služeb Server poskytovatele externích podnikových w-služeb Aplikace pro SCM volání podnikové w-služby Podnikový server a interní podnikové w-služby Obrázek 9-3: Volání podnikových w-služeb z aplikací PIS pro dva procesní sety ERP a SCM. Jestliže tvoříme PIS z aplikací, které mají servisně orientovanou architekturu, nesmíme zapomínat na vzájemnou komunikaci mezi aplikacemi. Datový, procesní a komunikační charakter je potom řešen společným integrátorem, pro který může být vymezen všem aplikacím dostupný pracovní rámec (frame-work). Za podstatu servisně orientovaných aplikací nelze považovat jen volání podnikových w-služeb. Aplikace musí respektovat komputerizovaný rámec vzájemné spolupráce podnikových služeb, na kterém je postavena datově, procesně a komunikačně orientovaná integrita PIS. Shrnutí kapitoly: Kapitola podává podstatu podnikové služby a podnikově orientovaného systému služeb. Na základě toho je vysvětlena logika komputerizace podnikových služeb pomocí SOA a je uvedena její orientační ilustrace. Σ Pojmy k zapamatování: Podniková služba, systém podnikových služeb, komputerizace podnikových služeb pomocí SOA Testy a otázky: 1. Co je podniková služba? 2. Jaké vlastnosti má systém podnikových služeb? 3. Co je SOA a k čemu slouží. -31-

98 Úkoly k zamyšlení: 1. Je SOA v rozporu s filosofií Cloud Computing? 2. Jak SOA převést do podoby zdrojového kódu? 3. Je SOA v rozporu s komponentovou architekturou? -32-

99 11 Pojetí logické architektury rozsáhlého softwarového systému Cíle: Znát (umět vysvětlit): 1. Pojetí termínu architektura software. 2. Pojetí logické, návrhové a fyzické architektury software. 3. Proč je architektura software jednou z jeho relevantních charakteristik? 4. Přístup k modelování logické architektury podle publikace [EelCrip011]. Dovednosti (umět prakticky): 3. Realizovat prvotní přístup k logické architektuře na základě relevantních vlastností problémové domény a sestrojit prvotní schéma logické architektury. 4. Sestavit seznam klíčových rozhodnutí a otázek o architektuře. Klíčová slova: Architektura software, logická, návrhová a fyzická architektura, prvotní přístup k logické architektuře, opakovatelně využitelné prvky logické architektury, prvotní schéma logické architektury Architektura rozsáhlého software je jedním z relevantních atributů software. Pochopitelně, cesta, která vede k jejímu modelování a realizaci je poměrně dlouhá a silně závislá na procesech-požadavcích výchozí problémové domény. Je to v souladu s věhlasnými objektovými metodikami (např. RUP, UP, Select Perspective, ), které jsou postaveny na dominanci zpracování požadavků. Procesem postupného modelování architektury, v známých objektových metodikách, dospějeme k tzv. logické architektuře, která se musí převést na základě zvolené metody na tzv. návrhovou architekturu. Návrhová architektura se realizuje prostřednictvím zdrojového kódu ve zvoleném programovacím jazyku a vzniká tak architektura fyzická. Sémantika všech tří úrovní je konzistentní a týká se to rovněž vytvořených modelů, resp. diagramů. Rozdíl je ovšem v tom, že návrhový model je velmi blízko implementační fyzické realizaci architektury cílového software. Stačí, vyslovíme-li několik význačných charakteristik jednotlivých modelů architektury: Logická architektura vychází z požadavků problémové domény a je nezávislá na informačních technologiích. Jelikož není možné neuvažovat o architektuře cílového software, je logická architektura prostředkem přechodu od požadavků k návrhovému modelu architektury a potom ke konstrukci fyzické architektury cílového software. Návrhová architektura sice vychází z logické architektury, ale vzniká pod vlivem uplatnění zvoleného modelu informační technologie. Návrhová architektura je potom snadno převoditelná do formy zdrojového kódu. Pojetí obou architektur a zejména logické architektury, je uvedeno v publikaci [EelCrip011]. Některé pozoruhodné skutečnosti z této knihy, týkající se zejména logické architektury, uvedeme v následujícím textu. Návrhová architektura nebude zde rozvíjena, ale bude o ní mluveno ve fázi ROZPRACOVÁNÍ klasických pokročilých objektových metodik. Co vše potřebujeme znát pro zahájení a pokračování ve vývoji logické architektury jako vstupy procesu tvorby logické architektury? -33-

100 Jsou to následující skutečnosti: Pojetí podnikové architektury 2. Stávající IT prostředí (informační infrastruktura). Procesy jako funkční požadavky, jejich priority a členění do známých procesních setů. Nefunkční požadavky. Pojmový model podniku obsahující procesy a zpracovávaná data (např. objektový model tříd). Podniková pravidla nebo podmínky týkající se života podniku (tedy zejména podnikových procesů/služeb). Kontext organizačních součástí podniku (v souladu s jeho architekturou) a vazby na okolí podniku. Znalost uvedených skutečností evokuje správný názor, že logická architektura cílového software by měla zmíněné skutečnosti jaksi odrážet. Např. logická architektura může být postavena na podnikových podsystémech, na jejich komponentách, na procesních setech, na procesních podsetech, na organizačních jednotkách, nebo na vymezených skupinách podnikových dat. Toto je prvotní přístup, tedy obecná problematika odvozování logické architektury cílového software z kvalit problémové domény. Kde se dovíme zmíněné skutečnosti o podniku? Zjistíme je v provádění stanovených úkolů Úvodní studie (pro strukturované metodiky), nebo fáze ZAHÁJENÍ objektových metodik. Za výsledek procesu modelování logické architektury považujeme: Vyhodnocení kvality vstupů a jejich vlivu na architekturu cílového software. Rozhodnutí o logické architektuře, jaká bude a zdůvodnění proč takovou musí být. Přehled architektury (prvotní model, pozdější funkční model na komponentách, data a procesy versus komponenty, život komponent-rozhraní, nasazení architektury v uzlech informační infrastruktury podniku). Změnová kontrola logické architektury (jak architektura odolává změnám v podniku, zejména v jeho architektuře). Výsledný dokument o logické architektuře Modelování logické architektury Kniha [Hofm, 05] se zabývá několika přístupy k odvozování logické architektury cílového software. Již dříve uvedený prvotní přístup je v knize rovněž uvažován. Uveďme tři z nich bez hlubší charakteristiky: 1. Přístup na základě atributů celkové kvality problémové domény Attribute Driven Design (ADD). 2. Metoda 4 pohledů od firmy Siemens. 2 Architektura podniku je koherentní celek principů, metod a modelů, které jsou použity v návrhu a realizaci: podnikové organizační struktury, business procesů, podnikového informačního systému a podnikové informační infrastruktury. -34-

101 3. Přístup objektových metodik (RUP-Rational Unified Process, UP-Unified Process a dalších), které vycházejí z dominance procesů-požadavků. O posledním přístupu budeme později mluvit podrobněji (viz fáze ZAHÁJENÍ a ROZPRACOVÁNÍ metodik RUP/UP). Modelování logické architektury je součástí fáze ZAHÁJENÍ a pokračuje do fáze ROZPRACOVÁNÍ. Finálním nástrojem pro modelování logické architektury v metodice UP jsou UML grafické notace komponent a deskripce života komponent v logické architektuře (funkcionalita, rozhraní, vazby). Často se pro návrh logické architektury používá koncept založený na podsystémech, např. procesních, pro jisté oblasti života podniku. To může být prvotní, velmi hrubé schéma logické architektury (např. ve fázi ZAHÁJENÍ metodiky UP). Podsystém je potom chápán jako sada souvisejících komponent, do kterých se promítají procesy-požadavky přes případy užití, a tak vznikne poněkud detailnější schéma logické architektury. Zaznamenáme-li v předchozím schématu logické architektury život komponent (naznačení spolupráce), dojde k dalšímu užitečnému zjemnění pojetí logické architektury. Přidáme-li verbální deskripce funkcionality komponent, jejich rozhraní (poskytovaných a požadovaných) a zakreslíme-li schéma nasazení logické architektury v uzlech informační infrastruktury podniku, mohli bychom získané poznatky o logické architektuře považovat za užitečné pro její převod do architektury návrhové Proces tvorby logické architektury Publikace [EelCrip011] se zabývá v podstatě celým procesem tvorby architektury komputerizačního software. Tvorba je rozdělena do tří podprocesů: podprocesy pro tvorbu logické architektury, návrhové architektury a fyzické architektury. Abychom se příliš nevzdálili od pracovních postupů jednotlivých fází objektových metodik, vybereme z knihy [EelCrip011] jen některé myšlenky. Proces tvorby logické architektury, který budeme sledovat je popsán na základě úkolů a kroků, tak jak ukazuje Obrázek 10-1 aktivitního diagramu. Tyto úkoly nejsou v rozporu s později použitou metodikou UP. Pokusíme se teď naznačit, co se pod jednotlivými úkoly/kroky procesu tvorby logické architektury myslí. Jak se tyto úkoly odrazí v metodice UP zjistíme až v Části IV. Vývoj objektových aplikací podle metodiky UP. Pro čtenáře bude jistě užitečný příklad modelování logické architektury cílového komputerizačního software jednoduché domény Evidence soukromých zbraní v ČR, který bude uveden později. Ve vysvětlování metodiky UP se dovíme, že problematika logické architektury se začíná řešit již ve fázi ZAHÁJENÍ a poté řešení pokračuje velmi široce ve fázi ROZPRACOVÁNÍ, kde se důsledně rozpracuje návrhová architektura. Ve fázi KONSTRUKCE se problematika architektury soustřeďuje jen na dokončení návrhové architektury a potom na její fyzickou realizaci v programovacím systému. V softwarovém projektu, který je pro řízení vývoje software IS ustanoven a který využívá zmíněnou metodiku, je za architekturu zodpovědný hlavní architekt. Pochopitelně, je-li komputerizovaná problémová doména rozsáhlá, potom v projektu figurují rovněž datový architekt, procesní architekt, architekt infrastruktury a aplikační architekt. -35-

102 A B C Obrázek 10-1: Proces tvorby logické architektury (převzato a upraveno z [EelCrip011], str. 167) Úkol A: Průzkum prvků architektury Znalost procesní charakteristiky celé problémové domény, nebo jen jejího výseku, pomůže provést průzkum, jestli již existují nějaké opětovně využitelné prvky architektury 3, které bychom mohli využít. Opakovatelně využitelné prvky architektury se člení na prvky využitelné v logické architektuře a návrhové architektuře. Protože nás zajímá jen logická architektura, tak uvedeme jen prvky v ní použitelné: Opakovaně se vyskytující proces požadavek/podsystém/komponenta objevující se rovněž v jiné problémové doméně. Opakovaně využitelný vzor logické architektury. Je to vzor, který již byl využit v jiné problémové doméně. Např. u podniku je komputerizace orientována jen na problematiku personalistiky a my známe skupiny procesů a jejich osazení jednotlivými procesy. Hledání potom orientujeme na prověření, jestli náhodou neexistuje služba ve formě komponenty pro jednu nebo více skupin personálních procesů. Jestliže jsou pro komputerizaci problémové domény, nebo její části, předepsány jisté principy týkající se architektury, tak je nutné na ně brát ohled. Např. platí princip, že průzkum existence opakovaně využitelných prvků architektury musí být proveden jako první a musí být vyhotovena příslušná zpráva o výsledku. 3 Za opětovně použitelné prvky architektury považujeme již existující prvky, opakovaně využitelné pro logickou nebo návrhovou architekturu nově tvořeného software. -36-

103 Úkol B: Definice přehledu architektury Následující obrázek ilustruje vstupy a výstupy tohoto úkolu, jehož cílem je vytvořit Přehled architektury. Procesy-funkční požadavky Nefunkční požadavky Principy podn. architektury Výsledky kontextové analýzy Slovník pojmů Vstup Definice přehledu architektury Výstup Přehled architektury Obsah Přehledu architektury: Přehled architektury je spíše schematický a doplněn potřebnou verbální deskripcí. Představuje prvotní odvození architektury z procesů-požadavků problémové domény. Analýzu procesů, jejich seskupení do skupin/množin/podsystémů musíme ovšem provést jako první. Důležité je, že musíme mít procesní model domény, resp. její části. Schéma, které se musí v Přehledu architektury vytvořit je souhrnem obdélníků, které jsou pospojovány závislostními spojnicemi. Spojnice většinou nejsou interakčního charakteru. Jde o seskupení funkcionalit (daných procesy-požadavky) uvedených v obdélnících. Seskupení funkcionality jsou následujících typů: skupiny/množiny/oblasti procesů, podsystémy nebo komponenty. V prvotním schématu pro logickou architekturu použijeme jen jeden typ seskupení funkcionalit. Budou to podsystémy. Spojnice označují ze začátku jen jisté souvislosti. Jsou to souvislosti, které jsme objevili mezi skupinami/množinami/oblastmi procesů, nebo mezi podsystémy /komponentami. Spojnice se dále upřesňují, což souvisí rovněž s upřesňováním logické architektury. Podsystémy se chápou jako možné sady souvisejících komponent (s mapováním 1:1, 1:N). Význam komponenty budeme chápat v souladu s její definicí v UML 2.0 Schéma doplníme tak, aby dalo první obraz architektury cílového software, např. je načrtnuta komunikace s klienty a závislosti prvků schématu. 1 Hrubý přehled funkčních prvků, funkční model Cílem je nalezení základních funkčních prvků a jejich mapování do podsystémů/komponent a tak vytvořit první představu o funkčním modelu problémové domény. Např. <<Podsystém>> A <<Podsystém>> B <<Podsystém>> C <<Podsystém>> D <<Podsystém>> E Obrázek 10-2: První představa o funkčním modelu. -37-

104 Jednotlivé podsystémy by měly být identifikované a rovněž závislosti mezi nimi. Závislosti můžeme kreslit pomocí relace <<využívá>>. Následující příklad může sloužit jako vzor. Příklad 10-1: Ze znalosti funkcionality problémové domény Evidence soukromých zbraní v ČR můžeme poznat následující skupiny/podsystémy procesů a souvislosti mezi nimi. 1. Řízení zbraní a Průkazů zbraní 2. Řízení majitelů zbraní a zbrojních průkazů 3. Řízení klientů 4. Řízení statistiky Sestavíme hrubý funkční-procesní model problémové domény: <<Podsystém>> Řízení zbraní a průkazů zbraní <<využívá>>. <<Podsystém>> Řízení majitelů zbraní a zbrojních průkazů <<využívá>>. <<Podsystém>> Řízení statistiky <<využívá>>. <<využívá>>. <<Podsystém>> Řízení klientů Obrázek 10-3: Příklad hrubého funkčního modelu problémové domény. Můžeme tedy sestavit schematický Přehled architektury: a) prvotní schéma logické architektury: Řízení a komunikace s klienty Řízení zbraní a průkazů zbraní Řízení majitelů zbraní a zbrojních průkazů Řízení výstupních sestav Řízení statistiky BD Řízení klientů Obrázek 10-4: Prvotní schéma logické architektury pro doménu Evidence soukromých zbraní v ČR. b) Deskripce schématu: Systém potřebuje centrální řízení komunikace s klienty, které umožní nejen autentizaci a autorizaci, ale i organizaci plnění jejich požadavků. -38-

105 Klienti mohou spouštět jednotlivé podsystémy. Veškerá informace podsystémů je uložena v bázi dat. Podsystém Řízení statistiky nebude využívat ostatní podsystémy (jak je ve funkčním modelu), ale jen jejich data z báze dat-bd. Podsystém Řízení výstupních sestav bude organizovat výstup podle připravených výstupních šablon v podsystému Řízení statistiky. 2 Přehled prvků nasazení Zde uvažujeme o informační infrastruktuře (IT prostředí pro nasazení) problémové domény a identifikujeme lokality, v kterých bude cílový software nasazen, a pochopitelně uvažujeme o výpočetních uzlech, které se v daných lokalitách nacházejí. Můžeme načrtnout, jaké podsystémy budou v uzlech nasazeny. Jak již bylo načrtnuto, můžeme prvotní schéma logické architektury upravovat: Podsystémy mapujeme na dynamické komponenty. Stanovíme spolupráci komponent (nabízená a požadovaná rozhraní). Nakreslíme diagram nasazení komponent v informační infrastruktuře. 3 Ukázka koncepce architektury Je dokumentována spustitelným architektonickým modelem software, který je postaven sice na komponentách, ale není funkční. S tímto postupem se jistě setkáme v objektových metodikách Úkol C: Dokumentace rozhodnutí o architektuře Cílem tohoto úkolu je zaznamenat veškerá provedená a plánovaná klíčová rozhodnutí o architektuře. Všechny dosud provedené práce v souvislosti s architekturou Vstup Dokumentace rozhodnutí o architektuře Výstup Rozhodnutí o architektuře Sestaví se soupis otázek spojených s architekturou, charakterizují se možnosti, vybere se preferovaná možnost a toto rozhodnutí se dokumentuje. Jedna z otázek se soustřeďuje na vyřešení pozice podnikových pravidel (pravidla víceméně spojená s podnikovými procesy) v architektuře cílového software. To vše budeme řešit ve fázi ZAHÁJENÍ a fázi ROZPRACOVÁNÍ metodiky UP. Uvedené myšlenky počátečního přístupu k architektuře cílového software nám ukázaly, jak vyjít od požadavků a relevantních vlastností problémové domény a kráčet k logické architektuře. Tyto myšlenky jistě využijeme v metodice UP. Shrnutí kapitoly: Kapitola podává pojetí logické architektury a prvotní přístup k ní. V kapitole se využívá postupu, který je navržen v publikaci [EelCrip011]. Začíná se zhodnocením vlivu -39- Σ

106 relevantních vlastností problémové domény na logickou architekturu. Provede se průzkum prvků architektury, které by se daly v logické architektuře využít. V přehledu architektury se sestrojí prvotní schéma logické architektury. Rovněž musí dojít k tvorbě spustitelného architektonického základu, který bude dále dopracováván. Nakonec se logická architektura verbálně dokumentuje. Pojmy k zapamatování: Logická, návrhová a fyzická architektura software, prvotní schéma logické architektury Testy a otázky: 1. Jaké je pojetí logické, návrhové a fyzické architektury? 2. V čem tkví přístup k logické architektuře podle publikace [EelCrip011]? Úkoly k zamyšlení: 1. Zamyslete se, jestli můžeme spojit problematiku komponent již s logickou architekturou, nebo až s návrhovou architekturou. 2. Co si představujete pod architektonickým spustitelným modelem architektury? -40-

107 12 Literatura [EelCri011] Eeles, P. Cripps, P.: Architektura software. Nepostradatelný průvodce [WoMa06] [Erl06] [KrŽe04] [Tan07] [ArNeu07] [Som010] [wiksof] návrhem softwarové architektury, která funguje. Brno: Computer Press, ISBN WOODS, D., MATTERN, T.: Enterprise SOA. Designing IT for Business Innovation. O'REILLY, Tokyo. ISBN ERL, T.: Service-oriented Architecture. A Field Guide to Interacting XML and Web Services. Prentice Hall, USA, ISBN Král, J., Žemlička, M.: Architektury orientované na služby jako nové paradigma: mýty, problémy, výzvy, přínosy. In: Sborník z konference Systems Integration Praha, Vysoká škola ekonomická. Tanenbaum, A. S.: Distributed Systems. Principles and Paradigms. Printice Hall, Arlow, J., Neustad, I. UML 2 a unifikovaný proces vývoje aplikací. Brno: Computer Press, ISBN Sommerville, I. Software Engineering (the 9 th edition). London: Publisher PEARSON, ISBN 10: [Kač, 2000] Kačmár, D.: Programujeme v COM a COM+. Computer Press, Praha, ISBN [Hofm, 05] Hofmeister, CH.: Generalizing a Model of Software Architecture Design from five Industrial Approaches. Proceedings of the 5th Working IEEE/IFIP Conferences on Software Architecture (WICSA5). Washington, DC: IEEE Computer Society, [RuJaBo, 99] Rumbaugh, J., Jacobson, I., Booch, G.: The unified Modeling Language. Reference Manual. Amsterdam: ADDISON-WESLEY, ISBN X. -41-

108 VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky SOFTWAROVÉ INŽENÝRSTVÍ ČÁST IV. VÝVOJ OBJEKTOVÝCH APLIKACÍ PODLE METODIKY UP 1 OBECNĚ O METODICE UP STUDIJNÍ TEXT PRO KOMBINOVANOU FORMU STUDIA Milan Mišovič 2011

109 Prof. RNDr. Milan Mišovič, CSc. SOFTWAROVÉ INŽENÝRSTVÍ 1. vydání Vydala Vysoká škola polytechnická Jihlava, Tolstého 16, Jihlava, 2011 Tisk Ediční oddělení VŠPJ, Tolstého 16, Jihlava Za jazykovou a věcnou správnost obsahu díla odpovídá autor. Text neprošel jazykovou ani redakční úpravou. Milan Mišovič, 2011

110 Obsah Část IV. Vývoj objektových aplikací podle metodiky UP, 1 Obecně o metodice UP 1 Úvod Pojetí metodiky, relevantní vlastnosti metodiky UP Co je metodika? Úvod do metodiky UP (Unified Process) Historie vzniku UP Axiomy metodiky UP Podstata metodiky UP Struktura metodiky UP Souhrnné cíle jednotlivých fází Fáze ZAHÁJENÍ Fáze ROZPRACOVÁNÍ Fáze KONSTRUKCE Fáze ZAVEDENÍ Literatura... 18

111 Učební cíle: Seznámit se 1. s pojetím objektových metodik, s jejich vývojem a orientací na grafické notace výsledků modelování poskytované jazykem UML, 2. s metodikou Select Perspective a metodikou RUP, 3. s podpůrnými grafickými editory UML, s podpůrným software typu CASE. Znát 1. Pojetí architektury software v malém a velkém, architekturu Klient-server, Distribuovanou komponentovou architektura a architektura SOA. 2. Základy jazyka UML a jeho využití pro deskripci výsledků objektového modelování. 3. Podstatu všech fází metodiky UP, která je nosnou metodikou předmětu. Umět, mít dovednosti 1. SOFTWARE: uplatnit znalosti architektur software v jeho praktickém vývoji. 2. VÝVOJ SOFTWARE: aktivně se podílet na vývoji software pomocí metodiky UP, umět prakticky uplatnit znalosti jednotlivých fází metodiky UP ve vývojové praxi, vykonávat povinnosti plynoucí z podstaty všech pracovních postupů (požadavky, analýza, návrh a zavedení), respektovat principy týmového vývoje. 3. JAZYK UML: uplatnit znalosti jednotlivých diagramů ve fázích metodiky UP k deskripci výsledků objektového modelování. 1 Úvod Metodika UP je v přijatelném stupni implementace používána v předmětech Softwarového inženýrství na mnoha vysokých školách. Příznačné pro výuku implementace metodiky UP je, že teoretickou podporu některých, v ní se vyskytujících metod, budeme používat téměř výjimečně a většina poznatků, s nimiž se seznámíte, vycházejí z praxe věhlasných informatiků a jsou metodické povahy. Rozhodně i Vy k té všeobecné praxi svou troškou přispějete. Naše použití UP se sice liší od možností, které má, protože nebudeme komputerizovat komplexní problémové domény, ale jen jednodušší. Metodiky UP a RUP jsou využívány v širší implementaci až v předmětu Informační systémy, pro modelování komplexních domén a tvorby rozsáhlého software informačních systémů. Pro modelování komplexních domén se u větších softwarových firem raději používá širší RUP, která je jakoby komerční verzí metodiky UP. V průběhu přednášek, praktické činnost ve cvičeních a v průběhu práce na Vašem projektu získáte přesvědčení, že analytická práce je podstatou všech fází objektové metodiky. Pro naše účely vývoje nerozsáhlých softwarových systémů máme tedy několik možností: 1. Použít metodiku UP, která je pro vývoj jednoduchých aplikací v bakalářském/magisterském studiu na vysokých školách v předmětu Softwarové inženýrství/základy softwarového inženýrství nejpoužívanější. 2. Použít metodiku RUP, jejíž redukcí vznikla právě metodika UP. Metodika RUP je ovšem pro akademickou půdu nedostupná, nejvýše v demo verzi, která se již blíží metodice UP. 3. Vybrat si metodiku odlišnou od metodik RUP a UP, např. Select Perspective. Ovšem nadále budou problémy s vhodnou dostupností komerční verze pro akademickou půdu. Z těchto tří možností vychází nejrozumněji případ 1., přičemž provést některá rozšíření metodiky UP podle RUP není problém. -4-

112 Podstatou Vaší analytické práce jsou individuální schopnosti provádět rozbor faktů, najít výsledek tohoto rozboru, vytvářet prognózy a soudy-úsudky. Vedle rozboru faktů je rovněž důležitá jejich syntéza na základě vzájemných souvislostí. Analýza a syntéza, v analytické práci, velmi často následují bezprostředně za sebou. V přednáškách a cvičeních budete upozorňováni, kdy tyto analytické dovednosti musíte použít. V průběhu vývoje Vašeho projektu určitě nějaké návyky a dovednosti v analytické práci získáte. Vraťme se teď k metodice UP (Unified Process). Téměř všechny pracovní postupy v jednotlivých fázích budou popsány verbálně a do jisté míry si je zapamatujete až po praktické aplikaci metodiky na jednoduchou problémovou doménu, kterou budete chtít komputerizovat. Poněkud jednodušší to bude s pamatováním diagramů UML, které budeme používat pro grafické deskripce výsledků objektového modelování. K tomu stačí jen minimální grafická paměť. Implementace metodiky UP bude ukázkově realizována na problémové doméně Firma BODY-CARE a doméně Správa soukromých zbraní v ČR. To vše, co se bude dít v ukázkovém projektu, můžete potom odkoukat a použít pro analýzu Vám zadané problémové domény. Veškerý postup v jednotlivých fázích metodiky UP podřídíme publikaci [ArNe07] a možným rozšířením. Já ovšem nebudu z této publikace opisovat, ale spíše vykládat metody, techniky a nástroje použité v metodice UP a podporu této metodiky ze strany UML. Výklad ovšem promíchám i skutečným, praktickým vývojem pro dvě zmíněné problémové domény. Tak hodně zdaru v pochopení metodiky UP a její rozšířené implementace ve Vašich projektech. -5-

113 2 Pojetí metodiky, relevantní vlastnosti metodiky UP Cíle: Znát (umět vysvětlit): 1. Podstatu iteračního přírůstkového modelu použitého v metodice UP. 2. Pojetí pracovních postupů v metodice UP. 3. Pojetí skladby jednotlivých fází potřebnými iteracemi. 4. Základní plánovací body každé z fází (souhrnné cíle, primární zaměření, pracovníci, milník). Dovednosti (umět prakticky): 1. Sestavit iterace pro jednotlivé fáze metodiky. 2. Uplatnit znalosti plánovacích bodů jednotlivých fází a uplatnit je pro prvotní přístup k architektuře cílového software a pro naplnění požadavků jednotlivých pracovních postupů. Klíčová slova: Metodika, fáze, model softwarového procesu, softwarový projekt, fáze UP, charakteristiky jednotlivých fází, plánovací body fází, spustitelný architektonický základ 2.1 Co je metodika? Vážení čtenáři-studenti. Sami již dostatečně víte co metodika vlastně je a co sleduje. Zopakujme některé poznatky. Ian Sommerville nazývá vývoj software přiléhavým termínem Software Development Process. Tento proces není tak náročný na teoretické základy, jako je náročný na praktické dovednosti a návyky, důležité v analytické práci. Důležité je to, že profesionální software je v tomto procesu vyvíjen podle řádu stanoveného vývojovou metodikou. Jistě se nedopustíme přílišné nepřesnosti, když na základě několika předešlých vět definujeme metodiku takto: Definice 2-1: Metodika je ucelený systém metod, technik, nástrojů a filosofického zdůvodnění KDO, CO, KDE, JAK a PROČ má udělat, aby se vytvořil software, který komputerizuje požadavky zákazníka na aktivity a zpracování dat v zadané problémové doméně. Metodika se obvykle člení na fáze, v kterých jsou použity osvědčené pracovní postupy založené na vhodných metodách, technikách a nástrojích. Pochopitelně, metodika UP má své specifické metody, techniky a nástroje, které musíme zvládnout metodicky a implementačně. Na druhé straně je zde vybraná problémová doména (část nás obklopující reality), která je vlastně globálním objektem naší metodiky. Je jasné, že metodika, jazyk UML a analyzovaná problémová doména jsou sice tři odlišné jednotky 1 procesu vývoje software (Software Development Process SDP) 2, ale značně související a musíme jim věnovat pozornost nejen samostatně, ale i v souvislostech. A to bude náš obecný postup v použití metodiky UP. Úkolem této kapitoly je seznámit Vás s přehledem zaměření fází metodiky UP a s jejich pracovními postupy. V dalších kapitolách již uvedeme potřebné detaily. 1 Za jednotky procesu vývoje software můžeme prozatím považovat metodiku, jazyk UML, problémovou doménu, CASE nástroj, zadavatele první uživatel, analytika a programátora. 2 SDP je jeden z termínů pro české Metodika tvorby softwarového vybavení. Pro stejný význam v češtině bývá použit další anglický termín Software Engineering Process SEP. -6-

114 Na závěr několik důležitých poznámek: 1. Všechny implementační záležitosti diagramů UML budeme v přednáškách a cvičeních (vedle jiných příkladů) dokumentovat na problémových doménách Firma BODY-CARE, Správa soukromých zbraní v ČR. Domény jsou svou funkcionalitou dostatečně transparentní, nepříliš složité a jejich komputerizace nevede na příliš robustní komponentový software. 2. Pochopitelně, postupně tyto domény namodelujeme v intencích metodiky UP na deskriptivní bázi jazyka UML. V přednáškách já zahraji roli zadavatele, tj. virtuálního ředitele firmy BODY-CARE, a na druhé straně budete vy hrát roli expertů ze softwarové firmy, kteří se bez informačních sezení s managementem firmy (zejména s ředitelem, personalistou a finančníkem) neobejdou. 3. Problematika metodiky UP v části VI. je zpracována podle knihy [ArNe07]. Metodika je veřejná, zmíněná kniha je dostupná a proto se hodlám důsledně držet její terminologie. 2.2 Úvod do metodiky UP (Unified Process) Kapitola sleduje stručný přehled jak samotné historie vzniku metodiky UP, tak i vlastností, jimiž se vyznačuje. Detailní vysvětlení mnoha skutečností souvisejících s metodikou UP najdete v anglické publikaci Jacobson, I., Booch, G., Rumbaugh, J.: Unified Software Development Process, vydané v roce 1999 a v českém překladu knihy autorů Jim Arlow a Ile Neustad pod názvem UML 2 a unifikovaný proces vývoje aplikací. Brno: Computer Press, ISBN Vedle toho vyšlo několik publikací zabývajících se jen jednotlivými fázemi metodiky UP. Jejich seznam najdete v knize Jima Arlowa Historie vzniku UP Za otce metodiky UP je považován informatik Ivar Jacobson, přičemž se kladně hodnotí závažné příspěvky k jejímu vzniku od Grady Booche a Jamese Rumbaugha. V roce 1995 se ve firmě Rational Corporation setkali Jacobson, Booch a Rumbaugh, všichni se svými metodikami a společně vypracovali metodiku Rational Objectory Process ROP. Bylo to významné vylepšení jejich dílčích osobních metodik. Výrazným výsledkem spolupráce bylo zavedení 4+1 pohledů na architekturu software, tj. logického, procesního, fyzického a vývojového pod rozhodujícím a sjednocujícím pohledem případů užití. Tato interakce pohledů se později stala základem pro pojetí architektury software jak v UP, tak i v UML. Bylo zavedeno formální členění na fáze: ZAHÁJENÍ - Inception, ROZPRACOVÁNÍ - Elaboration, KONSTRUKCE - Construction ZAVEDENÍ - Transition. ROP se vyznačovala implementací modelu kaskádového životního cyklu s dynamickou citlivostí iterativního a přírůstkového vývoje software. Jako hnací mechanismus projektového vývoje software bylo použito pojetí rizika. Jacobson, Booch a Rumbaugh začali velmi rychle pracovat na nalezení společné bázi deskripce výsledků jednotlivých fází. Touto bází se stal grafický jazyk UML. V roce 1997 se firma Rational Corporation rozšířila akvizicí některých menších firem a -7-

115 získala jejich know-how vývoje software. Tento zisk se projevil v rychlém vypracování metodiky Rational Unified Process RUP, která se prodávala již v roce V roce 1999 byla publikována kniha Jacobson, I.: Unified Software Development Process, v které byla důsledně popsána nová metodika UP. Ačkoliv RUP byla produkcí firmy Rational Corporation, tak UP byla jen produkcí autorů jazyka UML. Pochopitelně, jejich velká podoba byla očividná. Tvrdí se, že RUP jako komerční verze otevřené UP je mnohem širší a důslednější. Postupem času se další rozdíly mezi nimi rychle prohlubovaly. V roce 2003 byla firma Rational koupena firmou IBM a RUP se stala světově významnou metodikou doplněnou mnoha užitečnými nástroji. Vraťme se teď k metodice UP. UP, podobně jako RUP, důsledně modeluje aspekty dané tvrzením KDO, CO, KDY, JAK a PROČ má ve vývoji software udělat, aby byl cílový software úspěšně vyvinut. Je užitečné uvést k slovíčkům KDO, CO, KDY, JAK a PROČ krátký komentář. Pod KDO vidí UP dělníka (worker) a popisuje jeho roli jak jako jedince, tak i ve vývojovém týmu. Pod CO se myslí úkoly, které jsou uděleny jednotlivcům a týmům. Pod KDY se rozumí v následnosti pracovních postupů jednotlivých fází. To jsou vlastně posloupnosti jistých aktivit, které jsou ve fázích předepsány. Pod JAK se rozumí způsob provádění aktivit a získání tzv. artefaktů (vstupy a výstupy aktivit) Slovíčko PROČ je zdůvodněno celkovou filosofií metodiky jak dosáhnout předepsaných cílů v pracovních postupech a celých fázích. Základem aktivit v metodice UP jsou pracovní postupy. Každý pracovní postup má své artefakty tvořené vstupy a výstupy. VSTUPY PRACOVNÍ POSTUP VÝSTUPY Ačkoliv je UP obecnou metodikou, přesto je pro každou její implementaci na konkrétní problémovou doménu nutné udělat její instanci. Proč to tak je, vychází z markantních rozdílů mezi problémovými doménami, což evokuje, že ne vše z metodiky je využitelné pro všechny domény Axiomy metodiky UP Axiomy jsou jisté vlastnosti metodiky UP, které považujeme za platné bez ohledu na rozdíly mezi problémovými doménami. UP je postavena na třech axiomech: Řízení vývojářských prací je výlučně na základě řízení případem užití a projektovým rizikem. Pozornost vývoje je soustředěna na architekturu cílového software. Model životního cyklu je iterativní a přírůstkový (inkrementální). Uveďme k těmto axiomům několik vysvětlujících vět. Případy užití, které reprezentují požadavky uživatele na vyvíjený software, jsou vlastně jak počátečním, tak i dále používaným supervizorem vývoje software. Říká se, že metodika UP je řízena případy užití, a není v tomto atributu samotná (platí to rovněž pro RUP a Select -8-

116 Perspective). UP posuzuje vývoj software v ustanoveném projektu na základě analýzy rizik, které mohou nastat a značně narušit uspokojivý vývoj software. Riziky se zabývá projektový manažer, který musí zabezpečit to, aby se vývoj možným rizikům vyhnul. Problematika softwarových projektů a činnost projektového manažera je mimo problematiku našeho kurzu. Na druhé straně, nelze se problematice softwarového projektu zcela vyhnout. Softwarové projekty bývají záležitostí samostatného předmětu. Pro nás teď stačí, víme-li, že jde o řízení vývoje software podle fází a pracovních postupů, s použitím modelu životního cyklu založeného na iteracích a inkrementech. Obsahovou problematiku softwarového projektu jsme předchozí větou naznačili, ale problematiku řízení ponecháme stranou. Architektura software je metodikou UP řešena postupně, na základě výběru modelu, který je vhodný (např. komponentový vývoj) pro rozklad robustného softwarového systému. Uplatnění techniky 4+1 pohledů (viz Část II. Architektury software) je k řešení architektury dostatečné. Iterativnost znamená rozklad projektu na menší části iterace, které usnadní postupnou cestu vedoucí k cílovému software. Pro každou iteraci se uplatňují pracovní postupy (viz v dalším textu) Podstata metodiky UP Podstata metodiky UP je založena na iteracích a přírůstcích. Projekt je členěn na dílčí miniprojekty, protože je pohodlnější a lépe zvládnutelná malá dílčí část projektu než projekt jako celek. Každá dílčí část - miniprojekt je vlastně iterací. Iterace má vlastnosti jako projekt celek, tj. při jejím řešení se projde všemi částmi běžného softwarového projektu (plánování, analýza, návrh, tvorba-implementace, integrace a testování interní nebo externí, nasazení). Každá iterace definuje svou základnu (baseline), která se skládá z částečně kompletní verze finálního softwarového systému, a tedy i z veškeré přidružené projektové dokumentace. Vrstvením základen se docílí finální softwarový systém a jeho dokumentace. Rozdíl mezi dvěma sousedními základnami je vlastně přírůstek inkrement ve vývoji softwarového systému. Je pochopitelné, že vznik nové základny (ze základny předcházející) ve vývoji finálního softwarového projektu a vznik přírůstku jsou evokovány řešením další iterace. Pro každou iteraci se vlastně provede pět základních pracovních postupů (workflows): Požadavky... Zde vznikají specifikace požadavků zákazníka, které... on přiřazuje softwarovému systému jako nutnou... podmínku jeho nákupu a implementaci ve... stanoveném prostředí. Analýza... Vyhodnocení požadavků a jejich přerod do... funkcionality softwarového systému. Návrh... Odraz požadavků v architektuře softwarového... systému. Implementace... Uskutečnění tvorby software. Testování... Verifikace toho, že implementace funguje tak, jak je... v požadavcích zákazníka stanoveno. Vedle toho se mohou provést další pracovní postupy, jsou-li specificky potřebné pro danou -9-

117 fázi, např. Plánování. Uvedené pracovní postupy jsou začleňovány do jednotlivých fází metodiky UP. Zařazení ovšem není jednoznačné. Např. v jedné fázi se může provést více iterací. Myslí se to rovněž tak, že pracovní postupy se táhnou např. přes dvě fáze. Rozkladem projektu na iterace se vytvoří velmi pružný přístup k samotnému plánování projektu. Což v nejjednodušším vede na časový plán iterací, v němž dokončení jedné vede na následující. Nevylučuje se ani souběžné provádění iterací, což by mohlo vést k časovému zkrácení projektu. Následující zařazení pracovních postupů a fází respektuje polohu, kde je použití pracovního postupu dominantní. Požadavky do fáze ZAHÁJENÍ Analýza ZAHÁJENÍ, ROZPRACOVÁNÍ Návrh ROZPRACOVÁNÍ Implementace KONSTRUKCE Testování ZAVEDENÍ První z následujících obrázků ilustruje vnoření iterace do iterace vyšší, druhý ilustruje vztah fází, iterací v nich a jednotlivé milníky fází. Požadavky Analýza Návrh 3 Implementace 3 Testování Iterace 3 Plánování Odhad Specifikace projektu Obrázek 2-1: Vztah některých pracovních postupů. Předmět Životního cyklu a rozsah systému Zahájení Architektura životního cyklu Rozpracován í Počáteční provozní způsobilost Konstrukce Nasazení produktu Zavedení Iter 1 Iter 2, 3 Iter 4, 5 Iter 6 Milníky Fáze Iterace R A D I T Requirements, Analysis, Design, Implementation, Testing Obrázek 2-2: Jeden ze vztahů mezi milníky, fázemi a iteracemi. Některá pravidla, která tvůrci metodiky UP zavedli a v její filosofii je vysvětlili, podává nejlépe Jim Arlowe ve své knize a je rovněž dobře uvedeno v jejím českém překladu. Proto cituji několik odstavců ze strany 61. Přestože může každá iterace obsahovat všech pět základních pracovních postupů, závisí důraz kladený na určitý pracovní postup na jeho umístění v modelu životního cyklu daného projektu. Rozkladem projektu na sled iterací dosáhneme pružného přístupu k plánování projektu. -10-

118 Nejjednodušší je sestavit časovou posloupnost iterací, kdy dokončení jedné vede k zahájení další. Následující zjednodušený obrázek, ve tvaru diskrétní spirály, ilustruje iterace projektu vývoje software a přírůstky v modelování. Umístění iterací do fází není zobrazeno. Analýza Požadavky Iterace z pěti pracovních postupů. Výsledek definuje základnu poznatků. Přírůstek-inkrement Návrh Implementace a Testování Nárůst požadavků Obrázek 2-3: Ilustrace pracovních kroků v iteraci a opakování iterací. Tento obrázek ilustruje vztah iterací a pracovních postupů a evokuje přírůstky. Nezobrazuje se vztah iterací a fází. Proč bychom se v některé fázi nemohli zabývat hlouběji více za sebou jdoucími iteracemi? Možné to je. Např. k pracovnímu postupu Analýza se při tomto postupu vracíme několikrát. Úplná spirála, podle které UP pracuje, je uvedena v Části I. Software a softwarové inženýrství Struktura metodiky UP Metodika UP se skládá ze čtyř po sobě jdoucích fází: ZAHÁJENÍ... (inception) období plánování ROZPRACOVÁNÍ... (elaboration) období architektury KONSTRUKCE... (construction) počátky provozuschopnosti cílového software ZAVEDENÍ... (transition) nasazení software do uživatelského prostředí. Zopakujme znovu, že pracovní postupy nelze jednoznačně zařadit celé jen do některých fází. Pracovní postupy se roztahují přes fáze. Názorný je obrázek 2.7 z knihy Jima Arlowa na straně 63. Z tohoto obrázku plyne, že: Ve fázi ZAHÁJENÍ je nejvíce času věnováno pracovním postupům sestavení požadavků a jejich analýze. Ve fázi ROZPRACOVÁNÍ je silná orientace na požadavky, analýzu jejich realizace a částečně na návrh. Ve fázi KONSTRUKCE je důraz jednoznačně kladen na návrh a implementaci. Ve fázi ZAVEDENÍ se dokončuje implementace a testování. Ukončení jednotlivých fází je dáno tzv. milníky, které jsou definovány specifickými podmínkami. Tyto podmínky musí být splněny, aby byl milník dosažen. -11-

119 2.2.5 Souhrnné cíle jednotlivých fází Zde musíme vyslovit několik upozornění: Metodika UP je využitelná jak pro vývoj jednoduchých aplikací, tak i pro vývoj rozsáhlých softwarových systémů. Pochopitelně, aplikace budou komputerizací značně jednodušších problémových domén (řízení vědeckých konferencí, malá vesnická knihovna, ) a rozsáhlé softwarové systémy budou zase komputerizací velmi složitých problémových domén (podnik, škola, veřejný sektor, vládní sektor, ). To se odrazí v obrovském rozdílu v náročnosti a v rozsahu pracovních postupů v jednotlivých fázích. Je pochopitelné, že rovněž souhrnné cíle a milníky jednotlivých fází nebudou pro aplikace tak silné jak pro rozsáhlé softwarové systémy. Metodika UP jde svým obsahem vstříc komputerizaci složitých problémových domén (vývoj profesionálního software) a pro jednoduché problémové domény dojde v její implementaci k redukci rozsahu souhrnných cílů a milníků (cíle, které musí být splněny) jednotlivých fází. To je souvislost s dříve vysloveným tvrzením každá implementace metodiky UP na problémovou doménu, je specifickou instancí metodiky UP V dalším textu půjde o instance metodiky UP pro nerozsáhlé problémové domény. Pro další pochopení textu je důležitý následující obrázek. Tento obrázek ilustruje asociaci mezi třemi plánovacími body každé fáze, jimiž jsou: Souhrnné cíle fáze, Primární zaměření fáze a Milník s jeho podmínkami splnění. Obrázek rovněž stanovuje hlavní pracovníky fáze. Souhrnné cíle fáze jsou dány povedením seznamu aktivit, Primární zaměření fáze uvádí její dominantní aktivity, Milník je dominantní bod fáze. Podmínky milníku obsahují cíle, které musí být splněny, aby bylo dosažení Milníku uznáno. V dalším textu uvedeme pro každou fázi obsah tří zmíněných plánovacích bodů formou odrážek, stejných jako jsou v překladu knihy Jima Arlowa. Artefakty fáze VSTUPY FÁZE VÝSTUPY Hlavní pracovníci fáze Souhrnné cíle fáze Primární zaměření fáze Milník fáze Podmínky splnění milníku Obrázek 2-4: Ilustrace asociací fáze s artefakty, s cíli, zaměřením a milníkem. Podívejme se teď na souhrnné cíle, pracovníky, primární zaměření a milník všech fází metodiky UP Fáze ZAHÁJENÍ Souhrnné cíle Tato fáze je startovací fází metodiky a od toho závisí obsah všech plánovacích bodů (Souhrnné cíle, Primární zaměření a Milník). -12-

120 Za Souhrnné cíle jsou stanoveny: Tvorba podmínek proveditelnosti (Feasibility conditions). Nadnesení obchodního (podnikatelského) případu (obchodní přínos). Zachycení podstatných požadavků (rozsah vznikajícího systému). Označení kritických rizik. Hlavní pracovníci V této fázi čeká nejvíce práce manažera projektu, jímž by měl být informační manažer žádající organizace. Na fázi se ještě spolupodílí systémový projektant. Obsah práce obou pracovníků je dán disciplínou Projektové řízení. Vedle toho se zejména na analýze požadavků zákazníka podílí zákazník sám, budoucí uživatelé, analytici požadavků, vývojáři softwarového systému a testeři chování systému. S problematikou cílového software jako zboží si musí poradit dokumentátoři, právníci, lidé z obchodního a marketingového oddělení softwarové firmy. Primární zaměření Ve fázi dominují pracovní postupy zabývající se specifikací požadavků a jejich analýzou. Vedle toho je důraz kladen na některé návrhářské a implementační práce. Neměla by se rovněž opomíjet kontextová analýza zadavatele a souvislost s jeho požadavky. Velmi důležité je stanovit celkový model životního cyklu vyvíjeného software. Milník Milníkem fáze je předmět životního cyklu a rozsah softwarového systému (Life Cycle Objectives). Je doporučována následující verifikační tabulka: Metriky Potvrzení záměrů životního cyklu Potvrzení rozsahu projektu Potvrzení klíčových požadavků Schválení nákladů a pracovní rozvrh Schválení Obchodního případu Schválení rizik Potvrzení provozuschopnosti (posudky) Náčrt architektury Definice prostředí pro nasazení Co je potřebné dodat Dokument, který obsahuje hlavní požadavky na projekt, funkce a podmínky Počáteční hrubý případ užití Slovník projektu Počáteční plán projektu Dokument o obchodním případu Dokument odhadu rizik Pokud možno, jeden nebo více prototypů (budou se zahazovat) Prvotní náčrt pro architekturu software Prvotní náznaky o prostředí pro nasazení Poznámka: Pochopitelně, metriky a co je potřeba dodat je značně závislé na složitosti problémové domény. Např. Jestliže pro komputerizaci podniku konstruujeme softwarový systém, založený na aplikacích, potom budeme muset značnou pozornost věnovat jeho aplikační architektuře Fáze ROZPRACOVÁNÍ Tato fáze je nesmírně závažná, protože musí respektovat předchozí fázi a dodat podstatné -13-

121 vstupy pro fázi KONSTRUKCE. V literatuře o metodice UP se tato fáze považuje za kritickou v tom smyslu, že chyby v ní vzniklé se mohou nepříznivě odrazit na akceptaci software zadavatelem. A nejen to, vzniklé chyby se těžce odstraňují. Souhrnné cíle Za souhrnné cíle se považuje: Tvorba spustitelného architektonického základu Vylepšení odhadu rizik Definice atributů kvality Zachycení realizace případů užití pro 80 % funkčních požadavků Tvorba přesného plánu fáze KONSTRUKCE Formulace nabídky, která zahrnuje veškeré prostředky, čas, vybavení, personál a náklady. Hlavní pracovníci Na fázi se podílí především zadavatel, který poskytuje interview k vysvětlení požadavků a prostředí pro nasazení cílového software. Dále, je neodmyslitelná účast analytiků a programátorů softwarové firmy, která má cílový software produkovat. Primární zaměření Důraz je kladen zejména na následující aktivity: V pracovním postupu Požadavky: Upřesnění rozsahu systému a požadavků na něj kladených V pracovním postupu Analýza: Upřesnění toho, co budeme tvořit (realizace případů užití) V pracovním postupu Návrh: Tvorba logické architektury cílového software V pracovním postupu Implementace: Tvorba Spustitelného architektonického základu V pracovním postupu Testování: Testování korektnosti Spustitelného architektonického základu Poznámka: 1. Z uvedených aktivit je zřejmé, že důraz je kladen na pracovní postupy Požadavky, Analýza a Návrh. Pracovní postup Implementace se zvýrazňuje až koncem fáze ROZPRACOVÁNÍ, kdy se začíná pracovat na Spustitelném architektonickém základu cílového softwarového systému. 2. Hlavní roli hraje tvorba Spustitelného architektonického základu. Je to termín pro softwarový systém, který již realizuje architekturu, ale je prázdný vůči jednotkám, na kterých je architektura postavena (architektonické klišé cílového softwarového systému). Není to prototyp, který by se měl zahodit, ale klišé, které se bude postupně doplňovat, až se dosáhne podoby cílového software. Tato aktivita se odehraje zejména ve fázi KONSTRUKCE. Milník V souladu s tím, jak bylo neustále upozorňováno na architekturu, je milníkem fáze ROZPRACOVÁNÍ architektura cílového software (Life Cycle Architecture). Podmínky pro splnění jsou uvedeny v následující tabulce: -14-

122 Metriky Vytvoření spustitelného architektonického základu Spustitelný architektonický základ potvrzuje vyřešení všech důležitých rizik Co je potřebné dodat Software Spustitelný architektonický základ Statický model domény v UML Strukturální diagramy: Diagram tříd, Diagram objektů, Diagram komponent, Kombinovaný strukturální diagram, Diagram balíčků + deskripce ke všem diagramům Dynamický model domény v UML Diagramy chování: Diagramy případů užití, Stavový diagram, Aktivitní diagramy. Interakční diagramy: Diagram spolupráce, Diagram komunikace, Sekvenční diagram, Přechodový diagram interakcí + deskripce ke všem diagramům Vize o produktu je reálná a stabilizovaná Odhad rizik byl revidován Obchodní případ byl revidován a schválen Projekt byl vytvořen do dostatečné hloubky, umožňuje sestavení reálné nabídky cílového software, odhadu času, nákladů a prostředků pro následující fáze Zadavatel a týmy projektu souhlasí s Plánem projektu Plán projektu byl konfrontován s Obchodním případem projektu Vznikl konsenzus o pokračování projektu Dokument o vizi cílového software Aktualizovaný odhad rizik Aktualizovaný Obchodní případ Aktualizovaný Plán projektu - Zápis konfrontace Plánu projektu a Obchodního případu Konečný dokument agregující výsledky fáze ROZPRACOVÁNÍ Fáze KONSTRUKCE Souhrnné cíle Je to fáze, v které již vzniká reálná nutnost splnit všechny požadavky Analýzy a Návrhu a vyvinout z dříve připraveného Spustitelného architektonického základu cílový software. Klíčovým heslem fáze KONSTRUKCE je důsledně zachovat integritu dříve navržené architektury (neporušovat ji). Hlavním pracovním postupem fáze KONSTRUKCE je implementace. Testování rodícího se software může být jak průběžné, tak i v době, kdy je tvorba již značně pokročilá. V této době bude nutné provádět jak dílčí, tak rovněž integrační testy. Hlavní pracovníci Hlavními pracovníky jsou analytici a programátoři softwarové firmy. Primární zaměření Ve fázi KONSTRUKCE se mají pracovní kroky Požadavky, Analýza, Návrh, Implementace a testování své speciální dominantní cíle. Primární zaměření uvádí následující seznam cílů: V pracovním kroku Požadavky odhalit všechny požadavky zadavatele, které byly dosud opomenuty V pracovním kroku Analýza dokončit analytický model (statický a dynamický model problémové domény) V pracovním kroku Návrh dokončit model návrhu a prověřit zachování integrity architektury -15-

123 V pracovním kroku Implementace zajistit počáteční provozní způsobilost (Initial Operational Capability) dosud vytvořeného software, tj. Počáteční funkční variantu V pracovním kroku Testování testovat počáteční funkční variantu software Milník Výsledkem fáze KONSTRUKCE je to, že je připravena Počáteční funkční varianta softwarového systému pro testování na počítačích zadavatele. Milníkem je proto zmíněné zajištění počáteční provozní způsobilosti software. Podmínky verifikace milníku jsou dány v následující tabulce: Metriky Stabilita softwarového produktu musí být taková, aby jej bylo možné nasadit na počítačích zadavatele Zadavatel a vývojáři souhlasí s tím, aby byl software nasazen do předpokládaného prostředí, a je na toto prostředí připraven Kontrola nákladů je s výsledkem, že poměr skutečných výdajů vůči plánovaným je pro zúčastněné strany (zadavatele, řešitele) přijatelný Co je potřebné dodat Softwarový produkt Model UML (statický a dynamický model problémové domény) Připravená testovací sada pro dílčí a integrační testy Vytvořené uživatelské příručky Deskripce právě vytvořené verze software Plán projektu, z něhož se vyčtou skutečné a plánované výdaje Fáze ZAVEDENÍ Nastane-li okamžik, kdy je dokončeno testování a konečné nasazení systému, potom začíná fáze ZAVEDENÍ (transition). V podstatě tato fáze zahrnuje opravu všech chyb v otestované verzi software (v tzv. Beta verzi) a skutečné přenesení software na všechny počítače zadavatele. Souhrnné cíle Vzhledem k výše uvedenému textu jsou souhrnné cíle v následujícím seznamu: Oprava chyb Příprava pracoviště zadavatele k přijetí software Nutné přizpůsobení software tak, aby korektně fungoval na pracovištích zadavatele Řešení neočekávaných problémů a evokovaná úprava software Tvorba uživatelských manuálů a další dokumentace stanovené v projektu Konzultace se zadavatelem a současně prvním uživatelem Konečná revize celého projektu vývoje software. Hlavní pracovníci Na fázi se podílí zejména projektový manažer, systémový integrátor, analytici a programátoři softwarové firmy. Je možné, že softwarová firma má specializované zaměstnance testery, kteří testy navrhují a provádí. Jejich spolupráce s analytiky a programátory musí být na vysoké úrovni. Primární zaměření Charakteristikou fáze je důraz na pracovní kroky Implementace a Testování. Pro Testování -16-

124 je připraven návrh, který by měl odhalit dílčí chyby a chyby integrace. Je-li vývoj správný, tak se v této fázi nesmí objevit silné nároky na zpětnou Analýzu. Je-li tomu naopak, potom je projekt ve velmi svízelné situaci. Primární zaměření je dáno následujícím seznamem: Úprava návrhu, jsou-li během testování odhaleny chyby v návrhu software V pracovním kroku Implementace přizpůsobení software pracovišti uživatele a oprava chyb, které nebyly při testování nalezeny V pracovním kroku Testování provést beta testy a přejímací testy na pracovišti uživatele. Milník Milníkem fáze je nasazení - uvolnění softwarového produktu (Product Release). To vyžaduje ukončení beta testů, přejímacích testů, opravy případných chyb a produkt je uvolněn a přijat do užívání. Tomu také odpovídají verifikační podmínky milníku. Metriky Co je potřebné dodat Beta testy jsou dokončeny a po nezbytných Softwarový produkt opravách, uživatel souhlasí s tím, že produkt byl úspěšně nasazen Produkt se u uživatele aktivně využívá - Je dohodnuta strategie podpory nasazení produktu Plán uživatelské podpory u uživatele na další období. Strategie je Uživatelské příručky implementována Shrnutí kapitoly: Kapitola je základním přehledem nejen vlastností metodiky UP, ale rovněž souhrnných cílů, pracovníků, primárního zaměření a milníků. Jsou použity podrobné tabulky, jejich využití je pro postup vývoje cílového software zásadní. Σ Pojmy k zapamatování: Fáze, plánovací body fáze (souhrnné cíle, primární zaměření, milník), spustitelný architektonický základ Testy a otázky: 1. Na které fáze se UP člení? 2. Co jsou plánovací body každé z fází metodiky UP? 3. Vyjmenujte milníky pro každou z fází metodiky UP. Úkoly k zamyšlení: 1. Zkuste se zamyslet jaké iterace a s jakými pracovními postupy byste přiřadily fázi ZAHÁJENÍ pro problémovou doménu Vašeho projektu? 2. Podobně se pokuste zamyslet nad fází ROZPRACOVÁNÍ. -17-

125 3 Metodika UP a procesní a datové modelování problémové domény. Po otevření a stručném prostudování fáze ZAHÁJENÍ z relevantní publikace [RJB1999] jste překvapeni, že metodika RUP, a potom rovněž její sestřička UP, nevěnují ve fázi ZAHÁJENÍ patřičnou pozornost procesní logice problémové domény. Není používán žádný procesní diagram, který by ukázal nejen návaznost procesů, ale rovněž kontext na organizační jednotky domény. A to je jistý nedostatek pro debatu informatiků s managementem na bázi metodik RUP/UP. Metodiky RUP a UP začínají dominancí požadavků na funkcionalitu a podávají aktivitu domény na základě logiky případů užití a kontext pomocí aktérů. Napadne nás myšlenka, proč tuto situaci neřešit následovně: 1. Sestrojit pomocí uznávané metody (např. Eriksson - Penker, ARIS, ) procesní diagram, kterému management problémové domény rozumí. 2. Transformovat procesní diagram na diagramy případů užití. 3. Pokračovat se vzniklými případy užití podle metodik RUP/UP. Tento postup by do jisté míry navázal na obecnou problematiku vývoje informačních systémů a obecného přístupu k informačnímu modelování problémových domén. V dalším textu proto uvedeme z dvou uznávaných metod (metoda Eriksson - Penker, metoda ARIS od prof. Sheera) jen jednu z nich, např. metodu Eriksson - Penker a svážeme ji s metodikami RUP/UP. 4 Literatura [RJB1999] RUMBAUGH, J. - JACOBSON, I., BOOCH, G.: The unified Software Development Process. Amsterdam: Addison Wesley Longman, Inc., ISBN [EelCrip011] [Wieg08] [Kad04] [Jul08] [Ald05] [ArNe03] [Jul08] Eeles, P. Cripps, P.: Architektura software. Nepostradatelný průvodce návrhem softwarové architektury, která funguje. Brno: Computer Press, ISBN Wiegers, K, E.: Požadavky na software. Od zadání k architektuře aplikace. Brno: Computer Press, ISBN KADLEC, V.: Agilní programování: metodiky efektivního vývoje softwaru. Brno: Computer Press, s. ISBN Julínek, P.: Použití RUP pro malé SW projekty. Diplomová práce. Brno: Masarykova univerzita, Fakulta informatiky, Dostupné na WWW: < ALDORF, F.: Metodika RUP [online], diplomová práce, Dostupné na WWW: < ARLOW, J. - NEUSTADT, I.: UML a unifikovaný proces vývoje aplikací: průvodce analýzou a návrhem objektově orientovaného softwaru. Brno: Computer Press, s. ISBN X. Julínek, P.: Použití RUP pro malé SW projekty. Diplomová práce. Brno: Masarykova univerzita, Fakulta informatiky, Dostupné na WWW: <

126 [ArNe07] [CoHu95] [Gib06] [Kru01] [RJB05] [Vach07] Arlow, J., Neustad, I. UML 2 a unifikovaný proces vývoje aplikací. Druhé vydání. Průvodce analýzou a návrhem objektově orientovaného software. Brno: Computer Press, ISBN COTTERELL, M. - HUGHES, R.: Software Project Management. Itp New Media, s. ISBN GIBBS, D.: Project Management with the IBM Rational Unified Process. IBM Press, s. ISBN KRUCHTEN, P.: The Rational Unified Process An Introduction. 2nd edition. Boston: Addison-Wesley, s. ISBN RUMBAUGH, J. - JACOBSON, I., BOOCH, G.: The unified modeling language reference manual. 2nd edition. Boston: Addison-Wesley, s. ISBN VACH, D.: IBM Rational [online] Dostupné na WWW: < [KaMu07] Kanisová, H. Muller, M.: UML srozumitelně. Brno: Computer Press, a.s ISBN [Smr010] Smrčka, F.: Disertační práce (školitel Mišovič). Brno: Mendelova univerzita, Provozně ekonomická fakulta, Ústav informatiky, Poměrně zajímavé informace o UML získáte na adrese

127 VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky SOFTWAROVÉ INŽENÝRSTVÍ ČÁST IV. VÝVOJ OBJEKTOVÝCH APLIKACÍ PODLE METODIKY UP 2 FÁZE ZAHÁJENÍ STUDIJNÍ TEXT PRO KOMBINOVANOU FORMU STUDIA Milan Mišovič 2011

128 Prof. RNDr. Milan Mišovič, CSc. SOFTWAROVÉ INŽENÝRSTVÍ 1. vydání Vydala Vysoká škola polytechnická Jihlava, Tolstého 16, Jihlava, 2011 Tisk Ediční oddělení VŠPJ, Tolstého 16, Jihlava Za jazykovou a věcnou správnost obsahu díla odpovídá autor. Text neprošel jazykovou ani redakční úpravou. Milan Mišovič, 2011

129 Obsah Část IV. Vývoj objektových aplikací podle metodiky UP, 2 Fáze ZAHÁJENÍ 3 ZAHÁJENÍ - požadavky zákazníka Souhrnné cíle, hlavní pracovníci, primární zaměření, milník Obecné pohledy na požadavky zákazníka Definice a typy požadavků Požadavky a UP Pracovní postup Požadavky v metodice UP Mapování požadavků do případů užití Vývoj požadavků Analýza skupin uživatelů Techniky hledání a sběr požadavků Priority požadavků Rozdělení požadavků mezi komponenty softwarového systému Zapsat požadavky ve formě specifikací Správa požadavků Požadavky a procesy Co udělat ve fázi ZAHÁJENÍ? Úvod Návody pro fázi ZAHÁJENÍ Kontextová analýza problémové domény (systémy a podsystémy) Komputerizace, podmínky proveditelnosti a jejich zhodnocení Plánování projektu Obchodní případ (podnikatelské zhodnocení) Analýza klientů cílového software Prvotní přístup k architektuře cílového software Prvotní přístup k prostředí nasazení Prvotní přístup k vývojovému prostředí ZAHÁJENÍ - případy užití Diagramy případů užití v UML Stanovení hranic (subjekt) Hledání aktérů a případů užití Případ užití a jeho popis-specifikace: Diagram případu užití

130 5.1.5 Detailizace případů užití ZAHÁJENÍ - modelování případů užití, aktivitní diagramy Obecně o aktivitách v problémových doménách Obecně o aktivitních diagramech Podrobněji o aktivitních diagramech Akční uzly Řídící uzly Plavecké dráhy Objektové uzly Sponky Závěr Některá rozšíření aktivitních diagramů Spojky Přídavný uzel Komunikační diagramy jako diagramy interakcí ZAHÁJENÍ - tvorba balíčků Obecně o balíčkování Pojetí balíčku Závislost balíčků Vnořené balíčky Zobecňování balíčků Balíčkování tříd Kdy používat balíčky? ZAHÁJENÍ - pokročilé modelování případů užití Zobecnění aktéra Zobecnění případů užití Vztahy mezi případy užití Relace <<include >> Relace <<extend >> Drobné rady Literatura

131 3 ZAHÁJENÍ - požadavky zákazníka Cíle: Znát (umět vysvětlit): 1. Souhrnné, primární cíle fáze ZAHÁJENÍ a ověřovací milník. 2. Podstatu požadavků zákazníka a práci s nimi. 3. Pracovní postup Požadavky. 4. Metamodel specifikace požadavků, analýzu uživatelů. Dovednosti (umět prakticky): 1. Sestavit výsledky analýz na začátku fáze ZAHÁJENÍ. 2. Sestavit deskripce požadavků a provést jejich mapování na případy užití. Klíčová slova: Souhrnné a primární cíle fáze ZAHÁJENÍ, požadavky, uživatelé, pracovní postup Požadavky 3.1 Souhrnné cíle, hlavní pracovníci, primární zaměření, milník Zopakujme teď Souhrnné cíle fáze ZAHÁJENÍ z krátkého přehledu metodiky UP: Souhrnné cíle Tato fáze je startovací fází metodiky a od toho závisí obsah všech plánovacích bodů (Souhrnné cíle, Primární zaměření a Milník). Za Souhrnné cíle jsou stanoveny: Tvorba podmínek proveditelnosti (Feasibility conditions). Nadnesení obchodního (podnikatelského) případu (obchodní přínos). Zachycení podstatných požadavků (rozsah vznikajícího systému). Označení kritických rizik softwarového projektu. Hlavní pracovníci V této fázi čeká nejvíce práce manažera projektu, jímž by měl být informační manažer žádající organizace. Na fázi se ještě spolupodílí systémový projektant. Obsah práce obou pracovníků je dán disciplínou Projektové řízení. Vedle toho se zejména na analýze požadavků zákazníka podílí zákazník, budoucí uživatelé, analytici požadavků, vývojáři softwarového systému, testeři chování systému. S problematikou cílového software jako zboží si musí poradit dokumentátoři, právníci, lidé z obchodního a marketingového oddělení softwarové firmy. Primární zaměření Ve fázi dominují pracovní postupy zabývající se specifikací požadavků a jejich analýzou. Vedle toho je důraz kladen na některé návrhářské a implementační práce. Neměla by se rovněž opomíjet kontextová analýza budoucího systému a souvislost s jeho požadavky. Velmi důležité je stanovit celkový model životního cyklu vyvíjeného software. -5-

132 Milník Milníkem fáze je předmět životního cyklu a rozsah softwarového systému (Life Cycle Objectives). Je doporučována následující verifikační tabulka: Metriky Co je potřebné dodat Potvrzení záměrů životního cyklu Dokument, který obsahuje hlavní požadavky na projekt, funkce a podmínky Potvrzení rozsahu projektu Počáteční hrubý případ užití systému Potvrzení klíčových požadavků Slovník projektu Schválení nákladů a pracovní rozvrh Počáteční plán projektu Schválení Obchodního případu Dokument o obchodním případu Schválení rizik Dokument odhadu rizik Potvrzení provozuschopnosti (posudky) Pokud možno, jeden nebo více prototypů (budou se zahazovat) Náčrt architektury Prvotní náčrt pro architekturu software Definice prostředí pro nasazení Prvotní náznaky o prostředí pro nasazení Poznámka k Primárnímu zaměření: Pochopitelně, metriky a co je potřeba dodat, je značně závislé na složitosti problémové domény. Např. pro komputerizaci podniku konstruujeme softwarový systém, založený na aplikacích, a budeme muset značnou pozornost věnovat jeho architektuře a orchestraci aplikací (aplikace je v roli komponenty). Poznámka k Milníku: Po přečtení této stručné charakteristiky fáze ZAHÁJENÍ musíme konstatovat, že fáze je značně široká, ale nepříliš přesně vymezena. Co je primární, jsou požadavky zákazníka a jejich analýza. Nutno konstatovat, že pracovní postup Analýza je rovněž součástí fáze ZAHÁJENÍ a je plně orientován na požadavky zákazníka. Praxe potvrzuje, že mnoho problémů s výsledným software, vzniká při sběru a analýze požadavků zákazníka. Jestliže se k tomu přidá nevyspělá komunikace se zákazníkem, je výsledkem softwarového projektu produkt, který plně nepokrývá požadavky zákazníka, nebo je přikrývá neakceptovatelným způsobem, a zákazník je nespokojen. Pochopitelně, v komunikaci se zákazníkem došlo k pokroku v mnoha směrech. Dnes jsou známé komunikační metody, které se komunikačním problémům vyhýbají. Rovněž značné metodické pokroky ve vývoji a správě požadavků umožňují vzniklé problémy ve sběru a analýze požadavků omezit, nebo je vůbec eliminovat. Tak široká pozornost a péče požadavkům zákazníka plyne z jejich role v objektových/strukturovaných metodikách: Nelze obcházet skutečnost, že požadavky zákazníka jsou hnacím motorem a supervisorem vývoje cílového software. Práce s požadavky, tj. řízení požadavků je označována jako inženýrství požadavků (Requirements Engineering). Inženýrství požadavků obecně začíná dokumentem VIZE O BUDOUCÍM SOFTWAROVÉM SYSTÉMU. Je to dokument, v kterém je v hlavních rysech popsáno, CO bude nový systém provádět, jakým je přínosem pro své okolí (např. zadavatele a jiné uživatele, ). Vedle toho dokument obsahuje přehled cílů, které jsou považovány za nejpodstatnější. Dokument vytváří systémový analytik právě ve fázi ZAHÁJENÍ. Je rovněž známo, že nikde v průběhu softwarového projektu se zájmy všech účastníků nesetkávají tak živě, jako při sběru a analýze požadavků zákazníka. Z uvedeného plyne, že problematiku požadavků je nutné rozebrat velmi podrobně, tj. klasifikovat požadavky, popsat způsob jejich sběru a analýzy. Nakonec použít Use Case diagramy jazyka UML k modelování některých typů požadavků zákazníka. Dále je zřejmé, že požadavky zákazníka se vyvíjí a bude nutné požadavky spravovat. Vývoj a správa požadavků jsou ale dvě odlišné, sice související, stránky života požadavků, a tak se musíme -6-

133 na ně dívat. Myšlenky, uvedené v následujícím textu jsou v souladu s publikací [Wieg08]. 3.2 Obecné pohledy na požadavky zákazníka Obecně je samotný vývoj a správa požadavků zákazníka, nebo procesů problematický. Neexistuje nic víc než zkušenosti mnoha softwarových firem a zákazníků, které mohou být prezentovány jako metodické rady v tom, jak pracovat s požadavky a čeho se vyvarovat. Narušení těchto rad může být jak na straně zadavatele, tak na straně vývojové softwarové firmy. Např. na straně zadavatele se mohou objevit tyto nesprávné přístupy: Neochota k diskusím. Nepřesné předávání požadavků. Nerozlišování priority požadavků. Nejednoznačné požadavky. Požadavky se neustále mění. Výsledkem toho všeho je, že: Rozsah softwarového projektu a jeho cíle nejsou jasně definované. Záznamy požadavků se zahazují a nic není výsledné. Nejednoznačné požadavky nelze analyzovat, analytici si musí domýšlet. Nedodržují se vývojové termíny. Na straně softwarové firmy to může vést k ukončení spolupráce se zadavatelem a zastavení softwarového projektu. Je pochopitelné, že rovněž na straně softwarové firmy mohou existovat nesprávné přístupy, např.: Neochota přistoupit na rozumný vývoj požadavků. Požadavky zákazníka se řádně nedokumentují. Nezabezpečení kontinuity vývoje po odchodu některých pracovníků. To může vést k nedůvěře zákazníka, je-li softwarová firma schopna dovést softwarový projekt do úspěšného konce. 3.3 Definice a typy požadavků IEEE Standard Glossary of Software Engineering definuje v roce 1990 požadavek zákazníka takto: 1. Je to podmínka, funkce nebo proces, které uživatel potřebuje pro řešení problému nebo dosažení jistého cíle. 2. Je to podmínka, funkce nebo proces, které musí systém nebo jejich část splňovat, aby vyhověl smlouvě, standardu, specifikaci nebo jinému dokumentu, jenž se na něj formálně vztahuje. 3. Je to dokumentovaná podoba některého z předchozích dvou bodů. Požadavek je tedy vlastnost softwarového systému nebo jeho části, která má hodnotu pro zákazníka. Je specifikací toho, co by mělo být v softwarovém systému implementováno. Požadavky by měli být jedinou formou nařizující CO by měl systém dělat. Abychom vedle toho, že stanovíme, CO vysvětlovali, JAK se má požadavek implementovat, je na úrovni fáze ZAHÁJENÍ nevhodné. -7-

134 Poznámka: Slova zákazník, zadavatel a uživatel jsou někdy matoucí. Uvažujme tak, že nám je jedno, které slovo použijeme, ale žádejme nutnou účast v softwarovém projektu. Zůstaňme u slova zákazník. V publikaci [Wieg08] se požadavky člení na: 1. Podnikatelské... podává je zástupce zákazníka v projektu (např. hlavní manažer, marketingový manažer, ), naznačují proč je softwarový systém potřebný a jaké cíle se systémem chce zákazník dosáhnout. Často se specifikace těchto požadavků uvádí do samostatného dokumentu. 2. Uživatelské... stanovují úkoly, které musí uživatelé se softwarovým systémem provést. Jinými slovy, tyto požadavky stanovují, co bude uživatel schopen se systémem dělat. Na zápis těchto požadavků jsou nejvhodnější diagramy případů užití. 3. Funkční... nazývají se též biheviorální, protože jsou to požadavky na chování systému. Je to vlastně funkcionalita, která musí být do softwarového systému vložena. Verbální věty, které je specifikují, používají should be, což je české přání měl by (CO by měl systém dělat). 4. Systémové... jsou globálními požadavky na cílový systém, který je složen např. z komponent. Komponenty mohou být obecně softwarové a rovněž hardwarové podle IEEE 1998c. Jde-li o informační systém, např. podnikový, mohou se některé systémové požadavky týkat nejen takového hardware jako čtečky příchodu/odchodu, výdeje oběda,, ale i samotných zaměstnanců podniku. 5. Softwarové... jsou požadavky na rozhraní uživatelů, na vývojový systém (výkonnost, odezva, standardy, spolehlivost), paradigma a často omezující způsob implementace softwarového systému, Všechny uvedené požadavky mohou být uvedeny v dokumentu s názvem Seznam specifikací požadavků. Faktem je, že všechny uživatelské a systémové požadavky musí být promítnuty do požadavků funkčních a tedy zabudované v systému. Jestliže si uvědomíme, že: na uživatelské požadavky mají omezující vliv tzv. Podniková pravidla, funkční požadavky mohou být řízeny pomocí Kvalitativních pravidel, musíme specifikovat rovněž vnější rozhraní uživatelů, musíme přidat rovněž specifikace různých omezení na systém potom je seznam specifikací docela rozsáhlý. -8-

135 Poznámka: 1. Zdá se, že zavedení pojmu Uživatelské požadavky jako skupiny je rozporné (většinou všechny požadavky jsou uživatelské), ovšem autor publikace [Wieg08] chtěl odlišit uživatelem vyslovené požadavky od jejich zabudování v systému, což je funkcionalita systému funkčnost systému. 2. Někteří informatici rozumí pod řízením požadavků (Requirements Engineering) dvě komponenty: a. jejich vývoj (Requirements Development) a b. jejich správu (Requirements Management). To je velmi výhodné, protože můžeme specifikovat dvě odlišné skupiny úkolů, které musí být provedeny. Jaké úkoly patří do oblasti vývoje, ilustruje následující relevantní seznam. Seznam potvrzuje, že jde většinou o úkoly pracovního postupu Analýza se zaměřením na uživatelské požadavky. 1. Důsledná analýza skupin uživatelů (jejich práva, povinnosti a kompetence a role) a sběr požadavků od jednotlivých skupin. 2. Pochopení požadavků a jejich zařazování do jednotlivých typových skupin (podnikatelské, uživatelské, funkční, systémové). 3. Stanovit priority požadavků. 4. Provést rozdělení požadavků mezi komponenty/moduly softwarového systému (tzv. mapování požadavků mezi komponenty). 5. Zapsat požadavky ve formě jejich specifikací. Pro správu požadavků se obvykle stanovují zase tyto úkoly: 1. Zabezpečit jednotný pohled všech zúčastněných na specifikace požadavků. 2. Svázat požadavky s iteracemi metodiky UP. 3. Posuzování změn v požadavcích. 4. Sledovat realizaci požadavků v kódu software a v testovacích scénářích (tedy ve vznikající funkcionalitě). Pochopitelně, co se týče požadavků, jejich sběr, tvorba specifikací, analýza, kontrola a rovněž jejich správa, mají své osvědčené postupy, o nichž stručně pohovoříme v dalším textu. Často se uvádí, že dobře popsané požadavky mají následující vlastnosti: úplnost, správnost, proveditelnost, nepostradatelnost, prioritu, jednoznačnost a ověřitelnost. Jejich vysvětlení není obtížné. 3.4 Požadavky a UP Základem práce s požadavky uživatele je zavedení pracovního postupu Požadavky. Vše co bude dále řečeno, do tohoto pracovního postupu patří. První co si musíme uvědomit, je to, že metodika UP zjednodušuje členění požadavků jen na dvě skupiny funkční a nefunkční. Skupiny Uživatelské a Funkční z publikace [Wieg08] (viz rovněž předchozí kapitola) se dávají dohromady s názvem funkční (jde o zjednodušení pohledu na požadavky). Do skupiny nefunkčních požadavků patří podnikatelské, systémové a rovněž softwarové. -9-

136 UP zavádí metamodel Specifikace požadavků (Requirement Specifications), který obsahuje: Model požadavků, sestávající z o funkčních požadavků (Functional Requirements) a o nefunkčních požadavků (Non-functional Requirements) Model případů užití, sestávající z tzv. balíčků případů užití. Oba dva modely se vzájemně doplňují a zachycují všechny požadavky na budoucí softwarový systém. O balíčkách budeme mluvit později (pokročilé modelování případů užití). Jen stručně, balíčky jsou technikou, která umožní velmi vhodně shromáždit případy užití s podobnými vlastnostmi (přesněji později). SPECIFIKACE POŽADAVKŮ Model požadavků Model případů užití Funkční požadavky Nefunkční požadavky B 1 Balíček případů užití B 2 Balíček případů užití B3 B 3 Balíček případů užití B 4 Balíček případů užití Obrázek 3-1: Metamodel specifikace požadavků. Obrázek dokumentuje, že cesta ke všem specifikacím požadavků probíhá přes jejich modely, která končí verbálními notacemi (s možnou jednoduchou formalizací) pro nefunkční požadavky a končí na balíčkách užitných činností pro funkční požadavky. Model případů užití je nejčastěji vytvořen pomocí modelovacího nástroje na bázi jazyka UML. Může to být např. CASE Rational Rose, nebo Enterprise Architect. Na druhé straně, Model požadavků může být vytvořen verbálně (textově) nebo pomocí speciálních nástrojů pro Requirement Engineering, např. RequisitePro (viz nebo DOORS (viz Ačkoliv funkční požadavky jdou úspěšně modelovat pomocí diagramů případů užití (Use Case), tak specifikace nefunkčních požadavků se většinou píšou verbálně. Pokud bychom chtěli zavést přehledný jazykový notační formalismus, tak můžeme používat notace tohoto typu: < ID > < jméno softw. systému > < funkce > Nad takovými notacemi je již možné provádět několik zajímavých operací. 3.5 Pracovní postup Požadavky v metodice UP Výsledkem celého pracovního postupu Požadavky jsou Specifikace požadavků. Vlastní postup provádění jednotlivých dílčích pracovních kroků, tj. workflow pracovního postupu -10-

137 pro funkční požadavky, ilustruje následující obrázek. Systémový analytik Architekt Odpovědná osoba Návrhář uživatel. rozhraní Najít aktéry a případy užití Stanovit priority případů užití Upřesnit případy užití Řízení toku úkolů Tok úkolů Vytvořit prototypy uživatel. rozhraní Obrázek 3-2: Podíl specialistů na provádění úkolů. Poznámka: Do obrázku lze zabudovat rovněž ohled na nefunkční požadavky. Stačí provést nejdříve čtyři obecné úkoly: o Vyhledání-sběr funkčních požadavků. o Vyhledání-sběr nefunkčních požadavků. o Stanovení priorit v celé množině požadavků a pokračovat. o ve Sledování požadavků cestou funkčních požadavků přidružit požadavky k případům užití (náš předchozí obrázek) a cestou nefunkčních požadavků (cesta může končit verbálními specifikacemi). Důležitost priorit požadavků je potvrzena tím, že priorita je zdrojem pro stanovení architektury celého softwarového projektu. Příklad 3-1: 1. Jako příklad uveďme několik funkčních požadavků z problémové domény Řízení vědeckých konferencí. ID Funkční požadavek-funkce, popis 1 Systém by měl mít schopnost zveřejnit program konference 2 Systém by měl mít schopnost předložit seznam již zaregistrovaných účastníků 3 Systém by měl dát k dispozici šablony pro tvorbu příspěvku a abstraktu 4 Systém by měl každému zájemci předložit registrační formulář 2. Následující požadavky pro stejnou doménu jsou nefunkčními požadavky. ID 1 2 Nefunkční požadavek, popis V systému je pro uhrazení účastnického poplatku povolena pouze bankovní platební transakce Systém nesmí povolit registrovaným účastníkům změnu uživatelského jména a přístupového hesla 3 Systém bude programován jako webová aplikace v jazyku C# 4 Systém bude výlučně používat databázový stroj Microsoft SQL Server

138 3.6 Mapování požadavků do případů užití Významným krokem pracovního postupu Požadavky je mapování požadavků na tzv. případy užití. Hlavním úkolem této aktivity je určit jednoznačně vztah požadavků a případů užití. Mluvíme o tzv. mapování požadavků na případy užití (vzájemné přiřazení požadavků a případů užití). Toto mapování by mělo být pružné, abychom některé případy užití mohli skládat, kvůli realizaci širších požadavků. Požadavek obecně představuje značně širokou aktivitu softwarového systému. Většinou je mapování podle vzoru 1:N, tj. požadavek je realizován více případy užití. Přesto může nastat vzor mapování 1:1. Např. Požadavek Příjem elektrického spotřebiče do opravy může být mapován na několik případů užití:... Evidovat záruční list... Vytvořit zakázku... Přidat nového zákazníka... Vybrat vhodný servis Mapování je součástí kroku Najít aktéry a případy užití (viz předchozí obrázek). Vraťme se teď k samotným požadavkům. 3.7 Vývoj požadavků Nebudeme zkoumat všechny úkoly vývoje požadavků. Stručný rozbor některých z nich je uveden v následujícím textu Analýza skupin uživatelů Každá organizace, např. obchodně výrobní podnik, firma, veřejný sektor, armáda, vláda, vysoká škola, má specifickou organizační strukturu odpovídající nutnosti plnit stanovené strategické cíle. Z organizační struktury a strategických cílů jsou potom odvozeny tzv. zaměstnanecké pozice a jejich náplň. Se zaměstnaneckými pozicemi souvisí jistá obecná a specifická práva, specifické povinnosti a kompetence související s postavením v organizaci. Stejná práva, povinnosti a kompetence v organizaci, náleží mnoha zaměstnancům. Jestliže práva, povinnosti a kompetence, vycházející ze zaměstnanecké pozice, jsou stejná pro mnoho zaměstnanců, je namístě zavést abstraktní pojem role pro název příslušných specifických množin práv, povinností a kompetencí pro zaměstnaneckou pozici. Vzájemné vztahy zaměstnance, pozice, role a typu klienta naznačuje následující obrázek. Zaměstnanecké pozice Zaměstnanci organizace Role náležící zaměstnaneckým pozicím Typy uživatelů Softwarového systému Práva, povinnosti a kompetence související s jednotlivými rolemi Obrázek 3-3: Vztah zaměstnanecké pozice, role a typu klienta. -12-

139 Každá role z množiny rolí se týká více zaměstnanců a má přesně specifikovaná práva, povinnosti a kompetence. Softwarový systém musí proto, po přihlášení se klienta, velmi přísně rozlišovat jeho typ (autentizace klienta) a nastavit mu náležející práva, povinnosti a kompetence (autorizace). Požadavky zaměstnanců na softwarový systém se stejnou rolí, jsou tytéž. Asociaci množiny rozhraní s typem klienta a jeho rolemi naznačuje následující obrázek. Typ klienta Seznam rolí Práva, povinnosti a kompetence na: procesy / transakce a data Hlavní klientské rozhraní Dílčí rozhraní Dílčí rozhraní Dílčí rozhraní Obrázek 3-4: Vztah rozhraní a typu klienta Techniky hledání a sběr požadavků Pochopitelně, požadavky nemohou vycházet odjinud než z problémové domény, kterou komputerizujeme pomocí cílového software. Je to právě tzv. kontext problémové domény s okolím, který se přenáší rovněž na softwarový systém, který komputerizuje problémovou doménu. Kontext je zdrojem požadavků na cílový software. Co může být v kontextu tohoto systému? Jsou to např.: Host systému. Přímý uživatel systému. Ostatní uživatelé (manažeři, údržba, správci-administrátoři, ). Pomocná hardwarová zařízení (čtečky čipů pro příchod-odchod, pro výdej obědu, ). Právní a regulační omezení. Obchodní cíle. Nejdříve se ovšem díváme do dokumentu VIZE O BUDOUCÍM SOFTWAROVÉM SYSTÉMU, pokud je vytvořen, a hledáme v něm první zdroje požadavků. Dále používáme některé techniky dané zkušenostmi analytiků, např. konzultace a dotazníky. Konzultace Jsou nejpřímější technikou pro získávání požadavků. Jednou z forem je např. osobní pohovor, jinou tzv. kolektivní pohovor. Konzultace mají několik užitečných zásad, které je nutno respektovat. Jejich přehled je uveřejněn na str. 85 knihy Jima Arlowa. Dotazníky Nejsou náhradou osobních nebo kolektivních pohovorů, spíš jako jejich doplněk. Více opět na str. 85 knihy Jima Arlowa Priority požadavků Jsou nutným atributem všech požadavků. Podle tohoto atributu rozlišujeme, jestli je implementace povinná, lze ji vynechat nebo se má provést jen když je čas. Metodika UP -13-

140 zavádí pro hodnotu atributu priorita speciální hodnoty M, S, E a W. Přesněji. Atribut priorita se v metodice UP měří hodnotami M, S, E, W podle následující tabulky: M... (must have)... povinné požadavky, základ systému S... (should have)... důležité požadavky, lze je ovšem vynechat E... (could have)... opravdu nepovinné požadavky (implementují se, jen jestli je čas) W... (want to have)... požadavky případně zahrnuté do dalších verzí systému Rozdělení požadavků mezi komponenty softwarového systému Požadavky se vyvíjí, mnohé vznikají v době vývoje softwarového systému postupně, jiné se ukážou jako nepodstatné. Jestliže je již vytvořen návrh architektury systému, potom je nutné přiřadit požadavky jednotkám této architektury (komponentám, modulům, ). Tato přidělení se respektují během celého vývoje systému Zapsat požadavky ve formě specifikací Cílem inženýrství požadavků je vytvořit tzv. specifikace požadavků (dokument: Seznam specifikací požadavků). Specifikace mohou být dány verbálními - textovými notacemi nebo notacemi grafickými. Pro funkční požadavky jsou v jazyku UML vytvořeny tzv. diagramy případů užití (Use Case). Nefunkční požadavky zapisujeme nejčastěji textově. 3.8 Správa požadavků Úkoly správy požadavků jsou poněkud výše než sběr, protože se týkají celého projektu. Problematika je zatím poněkud stranou našich požadavků kurzu SWI. Nebudeme zatím detaily úkolů Správy požadavků blíže analyzovat. Uspořádání požadavků Máte-li k dispozici nástroj pro správu požadavků, lze je setřídit do skupin, tj. provést jistou taxonomii. Jestliže je požadavků mnoho, potom taxonomie Funkční a Nefunkční požadavky je velmi hrubá. Práci s požadavky jistě ulehčí např. taxonomie podle jistých typů. Jaký seznam typů ovšem sestavit závisí od samotné problémové domény. Příklad: 1. Uvádíme příklad typů funkčních požadavků podle toho, koho nebo čeho se týkají. Např. pro problémovou doménu ŘVK (Řízení vědeckých konferencí) můžeme uvést následující taxonomii týkající se: Uživatele v roli zadavatele. Zákazníků. Předkládaných produktů (abstrakt, příspěvek). Posuzování a výběru příspěvků (pro prezentaci, uveřejnění ve sborníku, zveřejnění jako postru, Plateb účastnického poplatku.. 2. Zde je možná např. následující taxonomie nefunkčních požadavků podle: výkonu systému, kapacity systému, dostupnosti systému, shody se standardy, -14-

141 ochrany informace,.. Atributy požadavků Každý požadavek se může vyznačovat množinou vlastností, které se dají měřit. Mluvíme potom o tzv. atributech obecného požadavku. Často se mohou uvádět obecné notace tohoto typu: Požadavek = (ID, jméno požadavku, zdroj, hrubá taxonomie, priorita, ) Je na analytikovi požadavků, jaké atributy budou pro požadavky zavedeny a jak budou dále zužitkovány. 3.9 Požadavky a procesy Je mnoho problémových domén, např. podnik, firma, veřejná správa, poradenský systém, u kterých má management již zavedené jednotky aktivity. Těmito jednotkami jsou procesy a služby. Jsou to domény, u kterých není cílový software jednoduchou aplikací, ale je charakteru rozsáhlého software. Pro tyto domény chápeme procesy a služby jako synonyma termínu požadavek. Metodiky RUP a UP oba dva termíny, tj. procesy a služby, zohledňují prostřednictvím UML 2.0. Aktivitní diagramy byly dokonce upraveny tak, aby mohly modelovat specifické kvality podnikových procesů (např. paralelismus). Podobný je vztah UML 2.0 vůči službám, které jsou chápány za základní jednotku architektury SOA a mají silnou distributivitu. Pro jejich modelování jsou využitelné dynamické komponenty. Shrnutí kapitoly: Kapitola se zabývá základy první a to velmi důležitou fází, ZAHÁJENÍ. Fáze je postupně rozebrána co do obsahu a postupu co vše se v ní musí udělat. Hlavní důraz je kladen na požadavky uživatele. Jelikož je metodika UP založena na axiomu požadavků, je vysvětleno, co za požadavky považujeme a jak s nimi pracujeme. Kapitola nejdříve uvádí souhrnné cíle fáze, potom z nich vytahuje primární zaměření a nakonec uvádí milník, který je pro zavedený softwarový projekt velmi důležitý. Dosažení milníku evokuje naplnění primárních cílů fáze. Σ Pojmy k zapamatování: Souhrnné cíle, primární cíle, milník, požadavky, pracovní postup Požadavky Testy a otázky: 1. Vysvětlete účel zavedení termínů souhrnné cíle, primární cíle a milník. 2. Proč testujeme typ uživatele cílového software? 3. Jaký je účel zavedení metamodelu specifikace požadavků? Úkoly k zamyšlení: 1. Kde vlastně začíná specifikace práv, povinností a kompetencí pro každou zaměstnaneckou pozici a vlastně každého zaměstnance, který danou pozici zastává? 2. Co je podle Vás podstatou mapování požadavků na případy užití cílového software? -15-

142 4 Co udělat ve fázi ZAHÁJENÍ? Kapitola je jen informativní. 4.1 Úvod Uvažujme, že top management z problémové domény se již rozhodl, půjde-li: 1. o dosažení komplexního řešení komputerizace nákupem a nasazením informačního systému, nebo 2. bude zvoleno evoluční dosažení komplexního řešení komputerizace. V prvním případě jedná top management problémové domény s prodejcem o nasazení zvoleného IS komplexního řešení. Řeší se potom jen problematika nasazení. Tato situace nás teď nezajímá, protože nejde o skutečný vývoj IS. V druhém případě dochází k postupnému vývoji IS v jisté softwarové firmě, v těsné spolupráci s top managementem problémové domény. Právě tento případ nás bude zajímat, protože produkční softwarová firma bude ve vývoji postupovat profesionálně pomocí objektové metodiky. Předpokládejme, že je to jedna z metodik RUP/UP. Protože obě metodiky jsou velmi pružné, což umožňuje zejména aplikace iterativního přírůstkového životního cyklu v nich, musí nejprve dojít k poznání problémové domény ze strany produkční softwarové firmy, zhodnocení možnosti komputerizace, obchodního případu a po konsensu k naplánování projetu s využitím cyklů a iterací v nich. Toto plánování softwarového projektu musí být v souladu s cílovou komputerizací problémové domény a vývojovými nároky. V dalším textu se soustředíme na diskusi úkolů fáze ZAHÁJENÍ metodik RUP/UP v souladu se stanovenými Souhrnnými a Primárními cíli, a rovněž v souladu s Milníkem této fáze. 4.2 Návody pro fázi ZAHÁJENÍ Další text je vysvětlením možné konkrétní aktivity v jednotlivých úkolech fáze ZAHÁJENÍ. Je proto velmi důležitý po praktické stránce. Pro středně velké problémové domény doporučujeme provést ve fázi ZAHÁJENÍ tyto úkoly: Kontextová analýza problémové domény. Systém a podsystémy. Podmínky proveditelnosti komputerizace a jejich zhodnocení. Obchodní případ (podnikatelské zhodnocení). Plánování projektu, kritická rizika. Analýza klientů cílového software. Prvotní přístup k architektuře cílového software. Prvotní přístup k prostředí nasazení. Prvotní přístup k použití vývojového prostředí. Pracovní postup POŽADAVKY: Analýza uživatelských požadavků (dokumenty: Vize o budoucím softwarovém systému, Seznam specifikací požadavků). Přiřazení požadavků případům užití. Diagramy případů užití a modelování případů užití, včetně jejich detailní deskripce. -16-

143 Všechny tyto úkoly přímo souvisí s obsahem Primárního zaměření a Milníku fáze ZAHÁJENÍ. V následujícím textu si budeme všímat všech vybraných úkolů fáze ZAHÁJENÍ a ke každému z nich provedeme stručnou diskusi, která může být dále rozšiřována. Výhodou této části textu je to, že vše je pohromadě a možno ji považovat za verbální šablonu pro vypracování fáze ZAHÁJENÍ k libovolné, středně složité doméně. 4.3 Kontextová analýza problémové domény (systémy a podsystémy) Často je kontextové analýze problémové domény nevěnovaná analytiky dostatečná pozornost. Pokud analyzujeme komplexní problémové domény, neměli bychom kontextovou analýzu podceňovat. V kontextové analýze bychom měli uplatnit tři relevantní pohledy: Pohled systémový. Pohled procesní. Pohled datový. Všechny tyto tři pohledy, ve vzájemných souvislostech a poznatky jimi dosažené, již dávají mnoho možností pro představu vizi budoucího komputerizačního, cílového software. V systémovém pohledu se pokusíme zjistit povahu problémové domény jako systému s několika podsystémy. Pochopitelně, základními prvky tohoto systému budou procesy nebo data. Stává se, že někdy jsou za základní prvky považovány zaměstnanecké pozice, nebo organizační jednotky. Součástí systémového pohledu je tzv. Kontextová analýza. Prvním pohledem Kontextové analýzy je problémová doména jako černá skříňka a její souvislosti s okolím. V tomto okolí je organizován život kontaktů (zdroje/příjemci dat a zdroje řídící informace) domény, jimiž mohou být osoby, jiné systémy, úřady, organizace. Často jsou klienti zobecněni do rolí, např. dodavatelé, zákazníci, Asociace prvků z okolí mají různý charakter. Nejčastěji jsou to řídící nebo datové vazby. Důležité je, že bychom měli tyto asociace důsledně popsat. Výsledkem prvního pohledu Kontextové analýzy je Kontextový diagram 1. přiblížení. Druhým pohledem Kontextové analýzy je struktura systému v podsystémech. Tento rozklad je dán specifikou problémové domény. Problematika modelování je potom orientována na každý z podsystémů jednotlivě. Pochopitelně, zahajovací iterace tento postup respektuje. Asociace prvků z okolí problémové domény musíme rozložit mezi jednotlivé podsystémy. Vznikají ovšem i vnitřní asociace mezi jednotlivými podsystémy, které musíme rovněž popsat. Rozklad problémové domény na podsystémy je jen dokončení výsledku prvního pohledu. Každý z podsystémů má svou specifickou strukturu a její vizualizace vede na Kontextový diagram 2. přiblížení k problémové doméně. Velmi často se systémový pohled odráží rovněž v architektuře cílového software. Např. nakreslí se bloková struktura architektury a do každého bloku se zobrazí náležící skupiny procesů, které jsou základem pro požadavky na cílový software. 4.4 Komputerizace, podmínky proveditelnosti a jejich zhodnocení Obecně řečeno, jde o proveditelnost komputerizace problémové domény. Je mnoho faktorů, které proveditelnost ovlivňují. Uveďme některé z nich: 1. Stupeň komplexnosti problémové domény (systém, podsystémy, okolí). Šíře požadavků zákazníka (množiny procesů). 2. Produkční kapacita softwarové firmy. 3. Styl vývoje software IS (evoluční, parciální, kompaktní, ). 4. Kvalita vývojového prostředí. -17-

144 5. Kvalita informační infrastruktury zákazníka z hlediska nasazení software. 6. Obchodní případ. 7. Plánování a řízení projektu. 8. Rizika uskutečnění vývoje software IS a jejich odstranění. Čím je potom dokumentována proveditelnost komputerizace? Odpověď je jednoduchá: Kladnými výsledky zhodnocení každého z uvedených faktorů. NĚKTERÉ Z UVEDENÝCH FAKTORŮ ROZEBEREME PODROBNĚJI 4.5 Plánování projektu Mnohé z toho, co se potřebuje pro řízení projektu je obsaženo v pracovním postupu Plánování projektu metodik RUP a UP. Pro pracovní postup Plánování projektu je pochopitelně nutné znát dobře problémovou doménu a nároky její komputerizace. Plánování se týká konstituce jednotlivých iterací a cyklů. Protože fáze ZAHÁJENÍ je startovací fází, tak iterace v této fázi je specifická, úvodní a nemusí vůbec vést na první vzorek cílového software. Následující obrázek ilustruje návrh takové iterace. Problémová doména Obchodní případ Kontextová analýza Nároky komputerizace Podmínky proveditelnosti Finanční nároky komputerizace Plánování fází, plánování iterací, Analýza prvků okolí Architektura, první přístup Vývojové prostředí, první přístup Prostředí nasazení, prvotní přístup Naplnění cílů, kvalita výstupů, řešení vzniklých rizik Plánování projektu Cíle iterace, výstupy pracovní postupy, rizika komputerizace Cílový software Zhodnocení iterace Plánování další iterace Obrázek 4-1: Struktura iterace. 4.6 Obchodní případ (podnikatelské zhodnocení) Jde o zhodnocení finančních a ostatních nákladů na způsob komputerizace. K řešení obchodního problému se dospěje na společném sezení top managementu zákazníka a poskytovatele/výrobce komputerizačního software. Předmětem jednání jsou tyto skutečnosti: Požadavky komputerizace problémové domény zákazníka. Nabídka poskytovatele/výrobce komputerizačního software a ceny implementace. Kompromis na požadavcích zákazníka a nabídce poskytovatele/výrobce a zakotvení v předběžné smlouvě. 4.7 Analýza klientů cílového software Pochopitelně, prvky z okolí problémové domény se mohou stát klienty cílového software. Je ovšem nutno tyto prvky specifikovat, protože některé z nich zdroje řídící informace budou -18-

145 později v roli aktéra v případech užití. 4.8 Prvotní přístup k architektuře cílového software V kontextové analýze byla vymezena problémová doména, jako systém s jistými podsystémy. Bylo to provedeno pomocí tzv. Kontextových diagramů prvního a druhého přiblížení. V těchto diagramech figuruje okolí problémové domény a pochopitelně, každá problémová doména má své osobité kontextové diagramy a podsystémy. Z relevantních vlastností problémové domény velmi často vychází tzv. logická architektura. Problematika je zpracovaná v kapitole 10. Části II. Architektury software. 4.9 Prvotní přístup k prostředí nasazení Role architektury hraje významnou úlohu v posuzování požadovaného prostředí nasazení cílového software. U vyspělých problémových domén je toto prostředí tvořeno informační infrastrukturou, o které jsme již mluvili. Samotné nasazení je dokumentováno diagramem, který ilustruje, kde bude cílový software rozmístěn a provozován Prvotní přístup k vývojovému prostředí Vývojové prostředí komputerizačního software musí splnit požadavky, které nastoluje architektura cílového software. Tento přístup má význam jenom tehdy, jestliže je požadavek komputerizace naplňován vývojem nového cílového software. Jedná-li se o komputerizaci stylem implementace a úpravy již vytvořeného, nemá tento prvotní přístup význam. Častým požadavkem na vývojové prostředí je zabezpečení možnosti paralelního vývoje komponent a organizace jejich života jednotlivě a navzájem. Shrnutí kapitoly: Podstatou kapitoly jsou jednoduché návody pro analýzy (Kontextová analýza, podmínky proveditelnosti, obchodní případ, plánování projektu, analýza klientů, prvotní přístup k architektuře cílového software, jeho nasazení a použitému vývojovému prostředí), které předchází pracovnímu postupu Požadavky. Σ -19-

146 5 ZAHÁJENÍ - případy užití Cíle: Znát (umět vysvětlit): 1. Pojetí případu užití. 2. Mapování požadavků na případy užití. 3. Prvky případů užití. 4. Detailizace případů užití. Dovednosti (umět prakticky): 1. Uplatnit znalosti pro praktické nacházení aktérů. 2. Mapovat dané požadavky zákazníka na případy užití a kreslit diagramy případů užití a sestavovat detailizaci případů užití. Klíčová slova: Aktér, případ užití, diagram případu užití, detailizace případů užití, scénáře Uvědomme si, že bychom již měli mít připraveny všechny výsledky analýz ze začátku fáze ZAHÁJENÍ a sepsány dva význačné dokumenty (zahájení pracovního postupu Požadavky): Vize o budoucím softwarovém systému. Seznam specifikací požadavků. Můžeme tedy přikročit k dalším pracovním krokům pracovního postupu Požadavky. 5.1 Diagramy případů užití v UML 2.0 Modelování případů užití je dalším krokem pracovního postupu Požadavky a je to jeden ze způsobů získávání a dokumentování požadavků uživatele. Je nepopiratelná zejména jeho vhodnost pro modelování funkčních požadavků. Dále musíme poznamenat, že modely případů užití jsou pro systémového analytika hlavním zdrojem objektů a tříd. Vlastní modelování případů užití vychází z požadavků uživatele, a je založeno na těchto aktivitách: 1. Nalezení hranic systému (subjektu). 2. Stanovení množiny aktérů. 3. Nalezení případů užití, tj. mapování požadavků na případy užití. o K požadavkům navrhnout případy užití. o Sestavit specifikace případů užití. o Určení hlavních a alternativních scénářů v případech užití. Výsledkem těchto aktivit je obvykle dílčí model případu užití. Aktivity se pochopitelně opakují, pro nalezení dalšího dílčího modelu případu užití. Musíme si uvědomit, že pro jednoduché problémové domény, jejichž komputerizace nevede na robustní aplikaci, můžeme sestavit jen jeden model případů užití ke všem uživatelským požadavkům. Pro komplexní problémové domény často členíme požadavky do samostatných skupin a pro každou z nich vytváříme dílčí model případů užití. Tuto problematiku členění zohledňují objektové vývojové metodiky (RUP-Rational unified Process, UP-Unified Process, Select Perspective, ) prostřednictvím vývojových iterací (opakování pracovních postupů) a množstvím pracovních postupů (Požadavky, Analýza, Návrh, Implementace, Nasazení, ). Složení modelu případu užití je jednoduché (odpovídá výsledkům modelování případů užití): -20-

147 Hranice systému, v kterých jsou uvedeny všechny nalezené případy užití. Aktéři, kteří představují role přidělené předmětům a osobám, využívající daný systém. Případy užití, které mohou aktéři se systémem vykonávat (jde o jejich spuštění). Relace, tj. smysluplné vzájemné vztahy mezi případy užití (např. relace <<include>>, <<extend>>), vzájemné vztahy mezi aktéry (např. dědičnost) a vztahy mezi aktéry a případy užití (např. spustit) Stanovení hranic (subjekt) Stanovením hranic bychom měli začínat aktivitu hledání aktérů a případů užití. Hranice totiž stanoví, co je uvnitř systému a co v jeho okolí. Subjekt je v UML kreslen jako rámeček s názvem systému. Aktéři jsou mimo subjekt, tedy v jeho okolí. Subjekt se stává vypovídající, jestliže stanovíme alespoň jednoho aktéra a případ užití, který spouští Hledání aktérů a případů užití Aktér: Pod pojmem aktér se rozumí role, ve které vystupuje jistý předmět z okolí systému, v rámci své komunikace se systémem. Aktérem může být osoba (role: administrátor, přijímací technik, opravář v dílně, ), oddělení podniku nebo jiný systém. Správné pochopení role je velmi důležité. Např. zaměstnanec podniku hraje několik rolí a stejná role může být hrána více zaměstnanci. Za aktéra nebudeme brát konkrétního zaměstnance (např. Vopršálka Ivana), ale zobecněné postavení v podniku, tj. roli. Aktéři jsou v UML ilustrováni jednoduchou ikonou, která je vhodná pro osoby a obdélníkem pro aktéra typu jiný systém. Dodavatel <<actor>> Dispečing Ačkoliv je většinou aktér externí entitou systému, je záznam uvnitř systému o tomto aktérovi chápán jako interní aktér. V systému je častým případem, že za aktéra musíme zvolit rovněž čas. Je to pochopitelné pro řadu specifických případů užití (např. o půlnoci čištění báze dat). Jim Arlowe ve své knize doporučuje sadu vtipných otázek, které pomáhají aktéra najít. Pro hledání aktérů a případů užití je důležité vycházet: z popisu problémové domény, který je velmi užitečným zdrojem, z modelu požadavků, zejména funkčních. Tyto požadavky přímo naznačují případy užití a aktéry. Všechny akce systému (případy užití) jsou evokovány aktéry, aktér si vyměňuje informaci se systémem, aktér je externí entitou systému, aktér je role, v které vystupuje uživatel při své komunikaci se systémem (uživatelská role vůči systému) Případ užití a jeho popis-specifikace: Často se dříve, než stanovíme jeden případ užití systému daným aktérem, pokoušíme sepsat posloupnost kroků, popisujících interakci aktéra se systémem. To je hlavní scénář případu užití. Případ užití je posloupnost činností, které může systém vykonat prostřednictvím interakce s aktérem. Případy užití jsou vždy iniciovány-spouštěny aktérem a jsou sestaveny z pohledu aktéra. -21-

148 Pro případ užití používá UML velmi jednoduché znázornění Název případu užití je uveden uvnitř elipsy. Přijmout zakázku z provozovny S případem užití může být spojena vstupní podmínka před jeho spuštěním a na konci případu užití musí být splněna výstupní podmínka. Vstupní podmínka požaduje jistý stav softwarového systému a jeho absence zamezí aktérům případ užití spustit. Výstupní podmínka zase omezuje systém v tom, že podmiňuje, do jakých stavů může systém po provedení případu užití přejít. Je zde naznačena silná souvislost případu užití se stavy systému ilustrovanými v pozdějším diagramu stavů. Aktéři, kteří spouští případy užití jsou hlaví aktéři. Aktéři, kteří se přidávají k případu užití po jeho spuštění, jsou vedlejší aktéři Diagram případu užití Diagram případu užití je uveden v subjektu a případ užití je spojen s aktérem komunikační relací. S aktérem může být ovšem spojeno více případů užití, dokonce může být vytvořen balíček případů užití. Dodávkový systém BODY-CARE Hranice Předat objednávku zboží Expedovat objednávku zboží Stornovat objednávku zboží Dopravce Zákazník systému BODY-CARE Ověřit stav Objednávky zboží z Vytvořit objednávku zboží Dispečer Komunikační relace Obrázek 5-1: Příklad komplexu případů užití. Případ užití Vztahy mezi aktéry a případy užití kreslíme pomocí čar. Pro relaci spuštění můžeme použít šipku vedoucí na spouštěný případ užití Detailizace případů užití UML nestanovuje žádný předpis pro popis případu užití. Jedno je jisté, popis-deskripce udělat musíme, např. ve strukturované češtině. Můžeme použít verbálního způsobu tvorby scénáře, kde dokonce můžeme jednotlivé kroky očíslovat. Případ užití tedy popisuje jistou akci systému. Definování případu užití začneme jeho pouhým názvem, který by měl mít slovesní tvar (např. Sestavit objednávku zboží). Postupně začneme iterativně přidávat podrobnosti, až vznikne úplná specifikace případu užití. -22-

149 V upřesnění případu užití si můžeme pomoct sestavením jeho hlavního scénáře. UML nabízí šablonu pro detail případu užití, její použití se obecně doporučuje. Metodiky RUP a UP nabízí velmi sofistikovaný a přitom jednoduchý způsob vyjádření případů užití, v kterém se používají transparentní tabulkové šablony (viz str knihy Jima Arlowa). Jeho povinné používání zavede do vyjádření případů užití jednotný styl a popisy se stávají čitelné a srozumitelné všem účastníkům projektu. Význačným prvkem tohoto způsobu jsou hlavní scénář a jeho větve a vedlejší - alternativní scénáře. Hlavní scénář je platný pro hlavního aktéra, vedlejší - alternativní pro předpokládanou chybu v případu užití softwarového systému. O některých myšlenkách podrobněji: 1. Používejte pro název případu užití slovesný tvar a každé slovo pište velkým začátečným písmenem. 2. Zaveďte spolu se zadavatelem slovník termínů z problémové domény a zapište jejich význam. Zabezpečte, aby slovníku rozuměl každý účastník projektu. 3. Jakmile jste vytvořili jeden diagram užití, vrhněte se hned na jeho detailizaci (specifikaci podrobností). Tato činnost je v UML označována jako Detail případu užití. 4. Stanovte ID (identification) případu užití. 5. Stručně popište případ užití, jeho cíle a přínos pro aktéry případu užití jde o podstatu. 6. Specifikujte aktéry hlavní a vedlejší. 7. Stanovte vstupní a výstupní podmínky případu užití. Bez splnění vstupních podmínek nemůže být případ užití spuštěn. Po ukončení případu užití musí být zabezpečeny výstupní podmínky. 8. Napište scénář pro hlavní část případu užití a scénáře pro větve v případu užití. Větvení začínejte slovem KDYŽ, za kterým následuje podmínka. Zápis scénáře celé větve ukončete slovem KONEC-KDYŽ 9. V každém hlavním scénáři začínejte větami typu: Případ užití začíná, když zákazník zvolí volbu Vytvořit objednávku zboží. Zákazník se přihlásí do systému a zadá uživatelské jméno a své heslo. atd Jestliže se ve scénáři musí některé kroky opakovat a ukončení opakování je dáno jistou podmínkou, tak použijte jednoduchý způsob zápisu konečného počtu opakování pomocí modifikované verze programovacího příkazu FOR iterační výraz: kroky END-FOR Jestliže počet opakování některých kroků scénáře je dán jistou podmínkou předem, tak použijte modifikovanou verzi programovacího příkazu WHILE (podmínka): kroky END-WHILE 11. Případ užití může mít ještě tzv. alternativní scénáře, které se realizují, když dojde v provádění případu užití k možné chybě, o které se ví, že může nastat (celkem tedy poznáme hlavní scénář a jeho větve, vedlejší-alternativní scénář). Alternativní scénář se může vypořádat s chybou sám a nechce se vrátit do hlavního scénáře. Obecně tomu tak nemusí být, závisí to od závažnosti vzniklé chyby. 12. Používejte následující tabulku specifikace případu užití. Často se pro orientaci ve vztahu mezi hlavním a vedlejšími - alternativními scénáři používá jednoduchý graf (jen v jednoduchých případech je to strom). Formu tohoto grafu najdete na str. 107 knihy Jima Arlowa. -23-

150 Zmíněná specifikační tabulka má následující formu a obsahuje deskripci případu užití Ověřit stav objednávky zboží. Případ užití: Ověřit stav Objednávky zboží ID: 5 Stručný popis: Systém podá zákazníkovi zprávu o stavu jeho objednávky Hlavní aktéři: Zákazník Vedlejší aktéři: Žádní Vstupní podmínky: Identifikační číslo objednávky zboží Hlavní scénář: 1. Případ užití je spuštěn z menu systému volbou Ověřit stav objednávky 2. Systém žádá zákazníka zadat svou identifikaci (uživatelské jméno a heslo) 3. Systém ověří identifikaci 4. KDYŽ je identifikace špatná, potom systém opakuje: FOR 2 Zadejte identifikaci; Prověření správnosti; Je-li identifikace správná, přejdi na krok 5, není-li, oznam chybu a ukonči případ užití END-FOR 5. Identifikace je správná a systém zjistí stav objednávky a podá zákazníkovi zprávu Výstupní podmínky: Žádné Alternativní scénáře: Nejsou zavedeny Relace aktérů k případu užití: Aktér, Zákazník systému BODY-CARE, případ užití spouští a musí zadat systému své uživatelské jméno a heslo Za relevantní prvky případu užití se obecně považují: Relace aktéra vůči případu užití. Vstupní podmínka. Výstupní podmínka. Krok v hlavním scénáři. Hlavní/alternativní scénář. Atribut-vlastnost. Operace. Za nejčastěji uvažovanou relaci se považuje relace spuštění případu užití. Je-li A konečná množina aktérů a U konečná množina případů užití, potom je zmíněná relace podmnožinou součinu A x U. Předpis pro jednu z podmnožin využívá relevantních atributů, např. ID aktéra, jeho práva, povinnosti a kompetence. Příklad 5-1 Jednoduše si představme problémovou doménu Řízení vědeckých konferencí jistou agenturou, firmou, ústavem a vysokou školou. Pro tuto doménu můžeme navrhnout několik skupin -24-

151 požadavků-procesů, např.: Řízení účastníků (přihláška-formulář a zpracování, statistiky, výběry, ). Řízení přístupu (registrace, přihlášení, odhlášení a změny uživatelského účtu). Řízení abstraktů a příspěvků. Řízení odborných sekcí (vedení, příspěvky, technické zabezpečení, ). Zabezpečení konference (program, aktivity organizačního a programového výboru, propagace, tutoriály, platby, raut, ubytování, ).. Každá ze skupin obsahuje požadavky-procesy a pro každou skupinu odděleně můžeme určit aktéry a procesy skupiny mapovat na případy užití (vznik balíčku případů užití). Procesy jedné skupiny můžeme protáhnout jednou iterací vývojové metodiky s mnoha pracovními postupy (Požadavky, Analýza, Návrh, Implementace, Nasazení, ) a získat tak první dílčí tvář software, které již komputerizuje procesy vybrané skupiny. Shrnutí kapitoly: Kapitola objasňuje mapování požadavků uživatele na případy užití, zavádí pojem aktéra, uvádí jeho souvislost s případy užití. Ukazují se diagramy případů užití a detailizace případů užití postavená na hlavním a vedlejších scénářích. Σ Pojmy k zapamatování: Požadavek, případ užití, mapování požadavků na případy užití, diagramy případů užití, aktualizace případů užití -25-

152 6 ZAHÁJENÍ - modelování případů užití, aktivitní diagramy Cíle: Znát (umět vysvětlit): 1. Co vše můžeme dokumentovat pomocí aktivitních diagramů. 2. Koncepci tvorby aktivitního diagramu. 3. Základní prvky aktivitních diagramů. 4. Rozšíření aktivitních diagramů. Dovednosti (umět prakticky): 1. Uplatnit znalosti aktivitních diagramů pro dokumentaci scénářů případů užití. 2. Používat jak základní tak rozšiřující prvky aktivitních diagramů. Klíčová slova: Aktivitní diagram, řídící, objektový a akční uzel, hrana, plavecká dráha, vlákno V předchozí kapitole jsme se soustředili jen na verbální detailizaci případu užití. Nemluvili jsme o možnosti použít tzv. Aktivitních diagramů, tak teď to napravíme. Celá tato kapitola se zabývá právě zmíněnými diagramy. 6.1 Obecně o aktivitách v problémových doménách V mnoha publikacích se termín aktivita/-y používá velmi volně na libovolnou činnost v dané problémové doméně. Takto vágně postavený termín není vhodné považovat za činnostní jednotku. Často se právě obráceně za jednotku aktivity považují procesy, nebo jejich části, tj. dále nedělitelné transakce. Pojetí procesu a transakce již není tak vágní, oba termíny mají přesnější definice než obecná aktivita. Procesům je dnes věnována velká pozornost, protože tzv. procesní logika a její výsledek procesní vlákna jsou základem řízení nejen podniku/firmy, ale jakékoliv obecné organizace. V mnoha problémových doménách jsou na základě procesů formovány ještě vyšší jednotky aktivity. Např. z poradenských procesů se formují poradenské případy, podniky a firmy již fungují na tzv. podnikových/firemních službách, V současném zájmu informatiky jsou právě tyto služby. Možnosti jejich pružné změny a webové implementace vnáší do současně vyvíjeného software nové kvality, jako vysokou distribuovanost kódu nebo dat a podnikům a firmám přináší neočekávané zvýšení konkurenceschopnosti prostřednictvím jejich informačních systémů. Management podniků a firem rozumí procesům, umí je modelovat a spravovat-řídit (process management). Na základě procesů je v podnicích a firmách uplatňováno tzv. procesní řízení. Vztah managementu k procesům je odlišný od vztahu informatiků. Cílem informatiků je především kvalitní komputerizace procesů, nesnaží se je upravovat-měnit ani řídit. Procesu jsme schopni porozumět jen tehdy, čteme-li jeho velmi kvalitní a poměrně širokou deskripci (algoritmus, data, transakce, události, mateřské vlákno,...). Samotná deskripce často obsahuje hrubé a detailní diagramy, které vizualizují mnohé části deskripce procesu. V strukturovaném paradigmatu se používaly tzv. vývojové diagramy pro vizualizaci algoritmů. Měly mnohé nedostatky, které jim byly vytýkány (např. obtížná vizualizace paralelních částí algoritmů procesů,...). Objektové paradigma zavádí obdobné diagramy, nazvané Aktivitní diagramy (Activity Diagrams), které dokážou modelovat akce, vyskytující se na mnoha místech v problémové doméně, a tedy i na mnoha místech diagramů, které tato místa modelují. Např. takovými místy jsou případy užití, operace objektových tříd, hlavní scénáře v detailních tabulkách případů užití, interakční diagramy, stavové diagramy, Aktivitní diagramy jsou základem pro modelování podnikových procesů, které jsou -26-

153 v objektovém paradigmatu reprezentovány pomocí operací jednotlivých objektových tříd. Aktivitní diagramy dokážou modelovat procesy, procesní vlákna a paralelizmus, který se v provádění podnikových procesů vyskytuje velmi často. Jde jen o to, na jaké úrovni je použijeme. Aktivitní diagramy jsou vynikajícím výchozím materiálem pro provedení implementace libovolné aktivity, mají proto značný význam téměř pro všechny fáze metodik RUP a UP. V UML 1.0 byly aktivitní diagramy chápány jako modifikace stavových diagramů. Verze UML 2.0 jim dala novou sémantiku, která z nich udělala velmi pružné a na mnoha místech využitelné diagramy a zcela odlišitelné od stavových diagramů. Jako skutečné diagramy aktivit jsou tedy využitelné na mnoha místech metodik RUP a UP. 6.2 Obecně o aktivitních diagramech Na aktivitní diagramy jsou ze strany informatiků rozporné názory. Někteří, jako Jim Arlowe, je plně považují za objektové diagramy, jiní mají o tom pochybnosti. Je rovněž skupina, která je považuje za objektové jen za jistých okolností. O tom všem ale později. Aktivitní diagramy podporují nejen sekvenční chování, ale i chování paralelní. Lze jimi modelovat obchodní a výrobní strukturu podniku, pracovní postupy a chování obchodních procesů (business processes) bez nutnosti určení objektových tříd, které je realizují. Důležité je, uvědomit si, že v tomto poslání jsou určeny především pro komunikaci s managementem, a proto by měly být dostatečně transparentní a na přijatelné úrovni složitosti. Aktivitní diagramy jsou chápány jako speciální grafy typu Petriho 1 sítí. Mnohé publikace potom vysvětlují sémantiku prvků aktivitních diagramů na základě pohybu tzv. tokenů 2 v aktivitním diagramu. V každém případě nutno říct, že názorné použití tokenů umožní sémantiku jednotlivých prvků aktivitního diagramu vysvětlit velmi přesně. V tomto studijním materiálu se jedná o takové přiblížení k aktivitním diagramům, které použití tokenů nezbytně nevyžaduje. V případě nejasností je nutno se podívat např. do publikace [ArNe07]. V aktivitních diagramech se setkáme s takovými pojmy jako uzly (nodes) - akce, hrany (edges) - přechody, rozhodnutí, hodnocení přechodů, sloučení, rozvětvení, spojení, pohyb objektů a plavecké dráhy. Tyto pojmy budou postupně vysvětleny v následujícím textu. V metodice UP lze diagram aktivity přidat k mnoha modelovaným prvkům a postihnout tak jejich chování. Např. úspěšně můžeme toto přidání realizovat pro: Obchodní procesy, pracovní postupy, obchodní a výrobní strukturu podniku. Případy užití. Třídy (operace). Rozhraní. Komponenty softwarového systému. Obecné spolupráce. Obecné operace. Velkou výhodou aktivitních diagramů je možnost jejich zaměření na jisté, konkrétní dynamické chování softwarového systému. Mohou se uvádět na několika stupních zobecnění vybraného chování. 1 Speciální síťové grafy pro zobrazení stavů dynamických systémů. Petriho sítě jsou považovány za formální grafický modelovací jazyk, např. pro obecné procesy. 2 Token je symbol, prostřednictvím jehož pohybu a jeho polohy je určován stav dynamického systému, který je modelován pomocí Petriho sítě. -27-

154 Např. pro vybraný balíček případů užití uvedeme aktivitní diagram pro jeho chování prostřednictvím cest mezi případy užití v tomto balíčku. Tak modelujeme, jak zapadne každý jednotlivý případ užití do celkového chování balíčku, kam patří. Teprve potom uvedeme aktivitní diagramy jako grafické deskripce hlavních scénářů jednotlivých případů užití. Aktivitní diagramy se v metodice UP chápou jako univerzální mechanismy umožňující modelovat chování. Příznačné ovšem je, že jsou nejčastěji používané v pracovním postupu Analýzy. Důležité je rovněž to, že musíme vidět zásadní rozdíl mezi případem užití a jeho aktivitním diagramem. Případ užití uvádí chování systému jako interakci mezi aktérem a systémem, kdežto aktivitní diagram uvádí chování jako posloupnost akcí. Z toho plyne, že jde o dva pohledy na totéž chování systému. Podle zkušeností mnoha uživatelů metodik RUP a UP, jsou aktivitní diagramy nejčastěji používány v těchto případech: V analýze problémové domény, pro modelování: obchodní a výrobní struktury podniku, pracovních postupů a chování obchodních procesů (business processes) bez nutnosti určení objektových tříd, které je realizují. Ve fázi ZAHÁJENÍ, pracovní postup Analýza: Pro grafické modelování hlavního scénáře daného případu užití. Je to velmi srozumitelný a transparentní zápis algoritmu případu užití. Pro modelování cest mezi případy užití. Je to vlastně zjednodušený diagram interakce případů užití v balíčku, kam patří (chování balíčku). Pro hrubé modelování operací analytických tříd. V pracovním postupu Návrh: Pro podrobné modelování algoritmů operací jednotlivých tříd. Pro modelování chování rozhraní. Pro hrubé modelování chování komponent a cest přechodů mezi komponentami. 6.3 Podrobněji o aktivitních diagramech Jim Arlowe se ve své knížce [ArNe07] dívá na aktivitní diagramy téměř jako na grafy a proto i mluva tomu odpovídá. Základem je uzel (node), přechod je hrana (edge), hodnocení přechodů je vedeno jako řídící uzel. Vedle toho zavádí rovněž objektové uzly, které zastupují objekty v rámci dané aktivity-akce. Grafové pojetí je dotaženo k pojmu cesta (path). Cesty v diagramu jsou dány hranami a uzly. Hrany jsou dvojího typu, řídící, které udávají postup řízení v rámci aktivity a objektové, které ukazují na cestu objektů v rámci aktivity. UML odlišuje tuto kvalitu rovněž graficky (plná a čerchovaná šipka). Pojetí pohybu objektů v aktivitních diagramech je založeno na tzv. Petriho sítich, kde se chování modeluje pomocí hry s tokeny (žetony). Tato hra vlastně popisuje pohyb-cestu tokenů po síti a je řízena mnoha pravidly. Studium Petriho sítí je ovšem mimo naši problematiku. Token se zobrazuje symbolem a jeho cesta šipkou Pozoruhodné ovšem je, že s tokeny počítají právě softwarové procesy, ale ne podnikové business procesy (obchodní procesy). Zajímavé ovšem je, že na základě pohybu tokenů, jsou zavedeny různé podmínky týkající se: podmínek pro akční uzly (vstupní podmínky, kontrolní podmínky přechodu přes hranu, vstupní podmínky cílového uzlu), -28-

155 rozvětvení a spojení. Jim Arlowe považuje aktivitní diagramy za objektové a snaží se to ukázat na mnoha jejich možnostech, které je svazují s objekty. Podrobně hodnotí jejich využití zejména během objektové analýzy a během návrhu. UML 2.0 uvažuje o třech typech uzlů: 1. Akční uzly, které obsahují samostatné akce, které jsou dále nedělitelné. 2. Řídící uzly, pomocí kterých se řídí cesty mezi akcemi. Chápání cesty 3 v aktivitním diagramu je totožné s chápáním cesty mezi uzly v obecném grafu. 3. Objektové uzly, které prezentují, zastupují konkrétní objekty použité v rámci akcí celkové aktivity zobrazené v aktivitním diagramu. UML rozlišuje dva typy hran: 1. Řídící hrany, které indikují postup řízení v rámci akcí aktivity zobrazené v aktivitním diagramu. 2. Objektové hrany, které indikují pohyb objektů v rámci aktivity. V ukázkách příkladů pro aktivitní diagramy se nevyskytuje aktér, ačkoliv je uveden v hlavním scénáři daného případu užití. Aktivitní diagramy nepřebírají strukturální rysy případů užití a aktér do nich patří. Jiná situace nastává, jestliže použijeme plavecké dráhy, které nám umožní modelovat odpovědnost strukturálních prvků (osob, oddělení, ), tam se již aktér může vyskytnout Akční uzly Termín akční uzel je zaveden z hlediska pohledu na aktivitní diagram jako graf. Termín akce označuje aktivitu, která se v akčním uzlu provede. Samotné akční uzly mají několik zajímavých vlastností, např.: Nikterak se nedělí. Nepřerušují se (zahájená akce musí být dokončena). Akce v nich probíhají rychle. Nemusí mít jen jeden vstupní přechod a jeden výstupní přechod. Může nastat několik situací v incidenci akčního uzlu se vstupními hranami. Např. A B C D Potom je nutno zvažovat skutečnost, že uzly A, B zahájí aktivitu, když řízení k nim dojde po jediné řídící hraně. Uzly C, D zahájí aktivitu, když k nim dojde řízení po obou řídících hranách (uplatnění vlastností Petriho sítí). V obou případech dojde ještě k testování lokální podmínky akčního uzlu a teprve je-li platná, pak se aktivita akčního uzlu zahajuje. Po dokončení interní akce akčního uzlu se testuje výstupní podmínka uzlu. Je-li splněna, tak akční uzel nabízí východ řízení po všech výstupních hranách. Jde o tzv. implicitní rozvětvení, protože akce v akčním uzlu může být spouštěna několika aktéry a je to rovněž zabudováno v hlavních scénářích daných případů užití. Aktivitní diagram obsahuje především akční uzly ve spojení s akcí patřící do jisté aktivity, které jsou označeny slovesnou vazbou. Názvy akcí se zapisují do zaoblených obdélníků a 3 Sled je libovolná následnost uzlů a hran. Sled začíná počátečným uzlem a končí koncovým uzlem. Cesta v grafu G je sled, ve kterém se neopakuje žádný uzel. -29-

156 provádí se převážně sekvenčně. Např. Provést kontrolu konzistence dokumentů Vytvořit Objednávku Sestavit Zakázkový list Je-li to nutné, tak můžeme akci v daném akčním uzlu popsat v tzv. specifikaci. Bývá to obvykle podrobnější slovní popis. Je nutné ovšem upozornit na některé skutečnosti související s implementací aktivitního diagramu na vybrané konkrétní chování systému. Např. je-li aktivitní diagram použit pro grafické modelování chování vybraného případu užití (podle jeho hlavního scénáře) je nutno neustále udržovat sémantickou konzistenci mezi hlavním scénářem a aktivitním diagramem. Akčních uzlů je několik typů. 1. Volání 2. Odeslat signál, přijmout událost, přijetí časové události. První z nich volání (call action) má toto použití: Uzel iniciuje akci (je spojen s akcí). Uzel inicializuje zavolání akce. Uzel iniciuje chování, operaci. Kreslí se např. ve tvaru: Stornovat Objednávku Uložit Fakturu Do Archivu Jméno uzlu dejzůstatek() Druhý typ se týká modelování aktivit dynamických systémů a nebudeme se tímto typem zabývat Řídící uzly Řídící uzly řídí postup v rámci aktivity celého aktivitního diagramu. Grafická reprezentace je složena ze šipky a symbolu uzlu. Rozlišuje se několik typů řídících uzlů, uvedených dále v textu. Počáteční a koncové uzly: Počáteční uzel koncový uzel konec cesty Uzel rozhodnutí: Výsledkem je přechod přes výstupní hranu, která splňuje kontrolní podmínku uzlu. Uzel sloučení: Kopíruje všechny vstupní hrany do jedné výstupní hrany. Uzel rozvětvit: Rozvětví cestu do několika souběžných cest. Uzel spojit: Synchronizuje několik souběžných cest. Uzel může obsahovat specifikaci spojení, která upravuje sémantiku spojení. -30-

157 Poznámky k jednotlivým typům uzlů: 1. Aktivita diagramu může mít více počátečních uzlů. V tomto případě děj začíná ve všech počátečních uzlech simultánně a souběžně. Aktivita diagramu může mít více koncových uzlů. Platí ovšem pravidlo, že po dosažení prvního z nich jsou automaticky ukončeny všechny cesty v rámci aktivity a tudíž je ukončena celá aktivita. Jednotlivé akce jsou spojeny orientovanými hranami, tj. přechody. Přechody nastávají automaticky, bezprostředně po provedení akce. Každý přechod je zobrazen šipkou Zjistit přikrytí Objednávky Vytvořit Dodací list Akce, akční uzel Řídící hrana, přechod Vytvořit Fakturu Vytvořit Ex. list 2. UML 2.0 dále uvažuje, že jednotlivé akce jsou spojeny se vstupními a výstupními podmínkami. Vstupní podmínky musí být splněny před zahájením dané akce, a výstupní podmínky zase musí být splněny po jejím ukončení. Vedle toho mohou mít akce své vlastní interní vstupní a výstupní podmínky. 3. Uzel rozhodnutí má pouze jednu vstupní hranu a vstupní rozhodovací podmínku označenou stereotypem <<decisionimput>>. Výsledek této podmínky se používá při testování kontrolních podmínek na výstupních hranách. Z kontrolních podmínek výstupních hran může být splněna jen jedna. K uzlu rozhodnutí může být přidána jako výstupní hrana speciální hrana se slovem OTHERWISE. Tato hrana se stane výstupní, jestliže nebude splněna žádná podmínka z ostatních výstupních hran. Uzel sloučení bezprostředně následuje za uzlem rozhodnutí. Nedoporučuje se tyto dva uzly sloučit do jednoho uzlu. Názorný je následující obrázek, který ilustruje spolupráci několika případů užití ze společného balíčku (Autentizace, Registrace, Přihlášení). Jde vlastně o modelování chování balíčku. -31-

158 Realizuj Autentizaci klienta přechod Hodnocení přechodu host zákazník Dodej základní informaci o funkcionalitě systému registrovaný zákazník Realizuj Registraci Realizuj Přihlášení spojení Nastav pracovní prostředí zákazníka Obrázek 6-1: Aktivitní diagram k balíčku případů užití. 4. Již dříve jsme mluvili o velmi dobrých schopnostech aktivitních diagramů pro modelování paralelního postupu v provádění akcí. K tomu slouží tzv. rozvětvení. Rozvětvení je ilustrováno symbolem rozcestí, který se kreslí jako tlustá čára. Na rozcestí přichází vstupní akce a za čárou začíná několik vláken akcí, které se zase sejdou na tlusté čáře. Tak vzniká spojení (join) několika dílčích vláken. Užitečný je následující formální obrázek, jehož interpretaci snadno vymyslíte. Jak je vidět, spojení je synchronizace všech dílčích vláken za rozcestím do jediného výstupního přechodu. Aktivace všech výstupních přechodů za rozcestím se považuje jako souběžná. Zmíněný obrázek ilustruje chod dvou vláken, počínaje bodem zahájení (modrá a červená). -32-

159 rozcestí A 1 A 2 A 3 dílčí vlákno spojení A 4 A 5 Obrázek 6-2: Aktivitní digram s vlákny. 5. Každé vlákno rozvětvení můžeme vybavit jistou podmínkou a vlákno se stává podmíněným. V okamžiku aktivace podmíněného vlákna za rozcestím dojde k vyhodnocení jeho podmínky, a pokud je podmínka nepravdivá, je vlákno při dosažení spojení považováno za dokončené Plavecké dráhy Další zajímavou vlastností aktivitních diagramů je možnost do aktivitního diagramu zavést informaci o tom, kdo jednotlivé akce provádí a je za jejich provádění odpovědný. Myslí se tím osoby, oddělení, ale žádoucí je postavit odpovědnost na objektových třídách. K realizaci uvedené myšlenky se např. používají tzv. plavecké dráhy (swim lanes). Plavecké dráhy se vymezují převážně svislými čárami. Každá taková plavecká dráha reprezentuje zodpovědnost konkrétní třídy. Dojde tak k vykreslení diagramu akcí se znázorněním zodpovědnosti interaktivních diagramů. Zajímavé ovšem je, když za akce považujeme právě operace jednotlivých tříd. Tím dojde k požadovanému spojení aktivitních diagramů s diagramy interaktivními. Plavecké dráhy se používají zejména při modelování případů užití, tříd, komponent, organizačních jednotek problémové domény (obchodní modelování) a tzv. rolí (při modelování pracovních postupů). Plavecké dráhy jsou ovšem těžko použitelné pro komplexní aktivitní diagramy. Někdy se aktivitní diagramy vylepšují zakreslením relevantních objektů, které v průběhu aktivit mění svůj stav. Mluví se o tzv. toku objektů mezi aktivitami. Zkusme navrhnout objekty, které tečou (vznik a pohyb) v následujícím diagramu (Objednávka, Faktura, Expediční list). -33-

160 Zákazník Místo prodeje Expedice Objednat zboží Zjistit možnost realizace objednání Proplatit fakturaci Fakturovat dodávku Sestavit seznam zboží Vytvořit expediční balíček Vyzvednout si balíček Obrázek 6-3: Aktivitní diagram s plaveckými dráhami Objektové uzly Objektové uzly signalizují dostupnost instancí účastnících se tříd. Instance se kreslí obdélníkem, se jménem a cestou. Cesta se kreslí šipkou (lépe je používat čerchované šipky, nebude se to plést s hranami aktivitního diagramu). Pochopitelně, takový aktivitní diagram by měl mít příslušné plavecké dráhy. Následující diagram již eviduje vznik a pohyb instancí zúčastněných tříd (červená barva). Zákazník Místo prodeje Expedice Objednat zboží Zjistit možnost realizace objednání Objednávka Proplatit fakturaci Fakturovat dodávku Faktura Sestavit seznam zboží Vytvořit expediční balíček Expediční list Vyzvednout si balíček -34-

161 Obrázek 6-4: Aktivitní diagram s pohybem instancí. Výskyt jednotlivých instancí může být doplněn označením jejich stavů. Tím se zvýrazní, jak akce ovlivňují přechod mezi stavy jednotlivých instancí Sponky K přerušení kontinuity a dalšímu jejímu navázání, slouží v aktivitních diagramech tzv. výstupní a vstupní sponky (pins). Toho můžeme využít zejména v případě nepřehlednosti diagramu. K pokračování diagramu, v případě nedostatku místa na kreslení, není nejvhodnější. Sponka je uzlem s jediným vstupem a jediným výstupem a připojuje s k akci velmi jednoduchým způsobem: Akce 1 Akce 2 Výstupní sponka Vstupní sponka Závěr Aktivitní diagramy mají svá pozitiva a negativa. Mezi pozitiva jistě patří široké použití aktivitních diagramů. Zopakujme je znovu: V době objektové analýzy o V modelování podnikových business procesů, bez nutnosti se zabývat statickou strukturou objektových tříd (jejich atributů a operací), které ve své spolupráci realizují daný proces. Tento přístup je vhodný v počátku analýzy, kdy se snažíme pochopit podstatu podnikových procesů. o V analýze jednotlivých případů užití, kdy jde o zvýšení transparentnosti a pochopení chování případů užití. Tato myšlenka je aplikována zejména na grafické modelování hlavních scénářů případů užití, kdy se pomocí plaveckých drah znázorní zodpovědnost osob, oddělení a pomocí toku objektů se ukáže jejich cesta mezi osobami, odděleními, zodpovědnými za prováděné aktivity v případu užití. Pochopitelně, může být rovněž pohled, který říká, že aktivitní diagramy modelují případ užití jako sled událostí. Názvy událostí jsou potom totožné s názvy akcí. Velkou předností aktivitních diagramů je rovněž možnost modelovat následnost-cesty mezi více případy užití např. v balíčku, což vlastně dává téměř jistý diagram interakce případů užití a vlastně chování balíčku jako celku. o K zajímavému případu použití aktivitních diagramů pro modelování hlavního scénáře případu užití se návrhář dostane v případě, že všechny akce nahradí operacemi tříd, které aktivitu případu užití realizují. V době návrhu o Pro modelování detailů algoritmů podnikových business procesů. -35-

162 o o o Schopnost modelovat paralelní akce podnikové procesy, které se ve strukturovaném paradigmatu modelují a komputerizují převážně sekvenčně. Pro modelování podrobností chování objektových tříd, zejména jejich operací. Pro možnost připojení k rozhraním a komponentám. Velkým negativem aktivitních diagramů je to, že nedokážou zcela jasně znázornit vazby mezi akcemi a objekty. Ačkoliv můžete použít plavecké dráhy, s případným tokem relevantních objektů, přesto kvalitu spolupráce objektů znázorňují nejlépe interakční diagramy (posílání zpráv se žádostí o provedení operace). Právě na základě tohoto nedostatku aktivitních diagramů, mnozí informatici je nepovažují za objektové (tj. nepatřící do objektového paradigmatu). Obecně se poukazuje na to, že aktivitní diagramy se nedají použít k modelování spolupráce objektů (na to jsou interakční diagramy) a k modelování průběhu životního cyklu objektů (k tomu jsou stavové diagramy). Dva následující příklady ilustrují použití aktivitních diagramů. První k modelování business procesů a druhý k modelování konkrétního případu užití. Příklad 6-1 Představme si střední obchodně výrobní podnik, který musí systematicky přistupovat ke všem procesům jednotlivých množin ERP, SCM, CRM, BI, Zde je ukázka modelování business procesu Marketingový výzkum podle [Smr010], bez velkých detailů, který patří do množiny CRM. Spuštění 1 Definice problému a výzkumného cíle 2 Volba typu a metody výzkumu 3 Výběr vhodného typu dotazníku 4 Vytvoření dotazníku 5 Provedení předvýzkumu Analýza dat předvýzkumu 7 Korekce dat 8 Sběr a kontrola dat 9 Analýza dat 10 Prezentace výsledků Ukončení Následující tabulka upřesňuje dílčí procesy. Název dílčího procesu Popis 1 Definice problému a výzkumného cíle Zde se definuje problém, který je potřebný zkoumat. 2 Volba typu a metody výzkumu V tomto procesu se rozhoduje o typu výzkumu. Je možné se rozhodnout mezi dotazováním: ústním, písemným, telefonickým, on-line nebo kombinovaným. 3 Výběr vhodného typu dotazníku Zde se řeší, které informace se budou získávat ve výzkumu. 4 Vytvoření dotazníku Vytvoření dotazníku. 5 Provedení předvýzkumu Provedení předvýzkumu na malém zkoumaném vzorku. -36-

163 Vedoucí průzkumu Tým průzkumu Týmoví analytici 6 Analýza dat předvýzkumu Výsledkem analýzy dat v předvýzkumu je, zda dotazník skutečně zkoumá to, co bylo definováno v cíli výzkumu. 7 Korekce dat Na základě analýzy předvýzkumu se provede úprava dat dotazníku. 8 Sběr a kontrola dat V tomto procesu dochází ke sběru dat. 9 Analýza dat Kontrola správnosti a přesnosti získaných dat, výpočet výsledků a získávání statistických údajů. 10 Prezentace výsledků Transformace výsledků výzkumu na přehledná a srozumitelná data, použitelná pro management. Použití Aktivitního diagramu pro proces Marketingový výzkum: 1 Definice problému a výzkumného cíle 2 Metody výzkumu 10 Prezentace výsledků 7 Korekce dat 8 Sběr a kontrola dat 3 Typ dotazníku 4 Vytvoření otazníku 5 Provedení předvýzkumu 6 Analýza dat předvýzkumu 9 Analýza dat Pochopitelně, mnohé z procesů můžeme zjemnit a potom použít další prvky aktivitních diagramů (např. souběžně se provede několik metod analýzy dat v předvýzkumu paralelismus a potom se výsledky porovnají). Podobně bychom do aktivitního diagramu zavedli vznik a pohyb objektů (Deskripce výzkumného cíle, Metoda výzkumu, Dotazník, Deskripce výsledku, Soubor prezentace). Příklad 6-2 Je dán případ užití Stornovat objednávku. Případ je detailizován následující tabulkou s hlavním scénářem. Případ užití: Stornovat Objednávku -37- v systému BODY-CARE ID: 5 (zadáno jen pro ilustraci hodnoty) Stručný popis: Systém podá zprávu o stavu provedení případu Stornovat Objednávku Hlavní aktéři: Odběratel (zákazník, dealer, firma) Vedlejší aktéři: Manažer prodeje Vstupní podmínky: Uživatel je zaregistrovaný a je již přihlášen. Uživatel zadá identifikační číslo Objednávky zboží Hlavní scénář: 6. Případ užití je spuštěn z menu systému volbou Stornovat Objednávku nebo z panelu ikon, ikonou Stornovat Objednávku 7. Systém žádá sdělení čísla Objednávky.

164 8. Systém prověří existenci Objednávky. Není-li Objednávka nalezena, je dán výstupní oznam a případ užití končí. Jinak, Objednávka je nalezena, pokračuje se na bod Systém zjistí stav Objednávky. 10. Objednávka může být v několika stavech: ve frontě (souvisící dokumenty ještě nebyly vypracovány), rozpracovaná (souvisící dokumenty již byly vytvořeny), ukončena (byl již vyzvednut expediční balíček). a. Je-li Objednávka ve stavu ve frontě je možné ji zrušit bezproblémově, protože nedošlo vůbec k zjištění pokrytí Objednávky a tvorbě dalších souvisejících dokumentů (Faktura,, Prodejka). b. Jestliže je Objednávka již v řešení a je tedy ve stavu rozpracovaná, potom může stornování povolit jen pracovník reklamačního místa. Systém čeká na jeho odpověď. Povolí-li zrušení, pak je provedeno. Musí se ovšem zjistit, jestli byla Faktura již proplacena (vrácení peněz na účet). Jestliže není dán souhlas, případ užití končí a Objednávka v systému zůstává. c. Jestliže je Objednávka již ukončena, nelze ji stornovat, může dojít jen k Reklamaci. Systém své rozhodnutí oznámí. 11. Jestliže k zrušení Objednávky dojde, potom se musí zničit všechny instance všech souvisejících dokumentů (Faktura,, Prodejka) a peníze se vrátí na bankovní účet, jestliže byla Faktura již proplacena. Systém podá zprávu o výsledku stornování. Výstupní podmínky: Stav Objednávky Alternativní scénáře: Klient je vrácen do svého interface, poté se může ze systému odhlásit Relace aktérů k případu užití: Aktér Odběratel systému BODY- CARE případ užití spouští ze svého prostředí (je již přihlášen k systému) a musí zadat systému identifikační číslo své Objednávky. Tento hlavní scénář je ilustrován následujícím aktivitním diagramem. -38-

165 Vyhledat Objednávku ne Existuje? ano ve frontě Stav Objednávky? rozpracovaná (související dok. vytvořeny) Zrušení Objednávky ukončená Možnost Reklamace Objednávky ne Vyžádat souhlas storna Souhlas? ano Oznámení o zrušení Objednávky Oznámení o nepovolení storna Zrušit Objednávku Zrušit Fakturu, Expediční list, Prodejku Oznámení o neexistenci Objednávky Oprava účtu, je-li Faktura již proplacena Obrázek 6-5: Aktivitní diagram případu užití Stornovat objednávku 6.4 Některá rozšíření aktivitních diagramů Aktivitní diagramy byly rozšířeny v několika směrech: spojky, přerušitelné oblasti aktivit, ošetření výjimek, přídavné uzly, odesílání signálů a přijímání událostí, proudění a -39-

166 pokročilé funkce toku objektů. Některé z nich ale nebudeme popisovat, protože: jsou již na návrhové úrovni (přerušitelné oblasti aktivit, ošetření výjimek), náleží k modelování technických systémů (odesílání signálů a přijímání událostí). Používají se zřídka (pokročilé funkce toku objektů) Spojky Spojky (connectors) připomínají obdobné prvky v starých strukturovaných vývojových diagramech. Je jimi dáno roztržení a spojení diagramu, nejčastěji mezi dvěma akcemi. Akce 1 A A Akce 2 A Spojka má dvě části, první výstupní z Akce 1 a druhou vstupní do Akce 2. Spojky lze použít v situaci nedostatku kreslícího místa (přechod diagramu z jedné stránky papíru na další), k přerušení dlouhých hran a k odstranění křížících se hran. Vhodné použití spojek může zvýšit transparentnost aktivitního diagramu Přídavný uzel Je to objektový uzel, který zastupuje kolekci objektů vstupujících do, nebo vystupujících z tzv. přídavné oblasti (expansion region). Technika přídavného uzlu je využitelná jak v analýze, tak i v návrhu. Pojetí a zpracování kolekcí je známé z vyspělých objektových programovacích jazyků. V analýze se kolekcí naznačuje, že daná oblast přijímá kolekci objektů, ne samostatný objekt. Přídavný uzel pro kolekci se podobá sponce, ale kolekce se naznačuje vertikálním obdélníčkem s třemi částmi. Nakreslí se vstupní kolekce do přídavné oblasti, operace nad vstupní kolekcí se zapíšou dovnitř přídavné oblasti a nakonec se naznačí výstupní kolekce, která vznikla ze vstupní. Množina Objednávek Seřazení podle zavedení Výběr sobotních Množina Objednávek Přídavný uzel Přídavná oblast Pochopitelně, platí zde obecné zásady pro kolekce. Tedy: kolekce může obsahovat jen objekty stejného typu, a typ kolekce vstupní se musí shodovat s typem kolekce výstupní. Přídavné oblasti mají přiřazen režim, podle kterého se zpracovávají objekty vstupní kolekce: iterativní, tj. sekvenční zpracování všech objektů vstupní kolekce, paralelní, proudový, tj. zpracování objektů vstupní kolekce ihned po jejich přijetí v přídavném uzlu. -40-

167 6.4.3 Komunikační diagramy jako diagramy interakcí Jako stručné diagramy interakcí mohou posloužit aktivitní diagramy, které používají jako interakce případy užití. Tím takový diagram dostává charakter znázornění cest mezi případy užití (v předchozím textu již naznačováno). Velmi užitečné to je zejména pro balíčky případů užití. Tento diagram vyjadřuje o případech užití podstatně víc než diagram případů užití balíčku, v němž jsou postiženy pouhé závislosti případů užití (relace <<include>>, <<extend>>) mezi sebou, a na aktérech. Diagramy tak konkurují sekvenčním diagramům, protože jsou orientované přímo na tok řízení a vizualizují souběžnost. Shrnutí kapitoly: Kapitola se zabývá velmi podrobným vysvětlením podstaty tzv. aktivitních diagramů, jejich prvky a využitím diagramů pro dokumentaci aktivit různých typů. Aktivitní diagramy jsou v kapitole chápány jako grafy a proto je používána mluva náležící grafům. Velká péče je věnována uzlům, hranám a pochopitelně celé řadě významných doplnění (plavecké dráhy, tok instancí a paralelní vlákna). Σ Pojmy k zapamatování: Uzel, typy uzlů, hrany, plavecké dráhy, tok instancí Testy a otázky: 1. K čemu je aktivitní diagram zaměřen? 2. Co znamenají plavecké dráhy? 3. Jaké jsou typy uzlů? 4. K čemu slouží tok instancí? 5. Je možné modelovat paralelismus aktivit v procesech pomocí aktivitních diagramů? Úkoly k zamyšlení: 1. Dokážete porovnat aktivitní diagramy s možnostmi dřívějších vývojových diagramů? 2. Myslíte si, že když vložíme do aktivitních diagramů velký kontext (plavecké dráhy, tok instancí, vlákna) nemůže dojít k situaci, že aktivitní diagramy jsou nepřehledné? -41-

168 7 ZAHÁJENÍ - tvorba balíčků Cíle: Znát (umět vysvětlit): 1. Možná pojetí pojmu balíček. 2. Aplikaci balíčkování na skupiny tříd. 3. Aplikaci balíčkování na případy užití. 4. Možný projev balíčkování u komponent architektury cílového software. Dovednosti (umět prakticky): 1. Uplatnit znalosti pro praktické sgrupování případů užití do samostatných balíčků. 2. Uplatnit znalosti pro praktické sgrupování tříd do samostatných balíčků. 3. Chápat a uplatnit projev balíčkování pro komponenty architektury software. Klíčová slova: Balíček, vztahy mezi balíčky, vnořené balíčky, implementace balíčků 7.1 Obecně o balíčkování Pojetí balíčku UML umožňuje realizovat abstrakci sdružování prvků pomocí tzv. balíčků. Sdružujeme-li v době provádění objektové analýzy, potom mluvíme o analytických balíčcích. Balíček je v podstatě kontejnerem prvků se svým jmenným prostorem a všemi jedinečnými názvy. Je to univerzální mechanismus pro uspořádání prvků do skupin. Balíčkování je rovněž základem dekompozice softwarového systému a potom je vhodné, když začíná již od případů užití. Co balíčkování vlastně umožní? Odpověď je snadná: 1. Balíčky lze považovat za jednotky souběžné práce. 2. Balíčky seskupují sémanticky související prvky (např. případy užití, třídy, ). 3. Balíčky definují jisté sémantické hranice. Nejčastějšími případy aplikace balíčkování (packaging) je seskupování případů užití, analytických tříd a realizací případů užití (vznikají analytické balíčky). Stačí, když se dopředu podíváme na obecný obrázek objektové analýzy ve fázi ROZPRACOVÁNÍ, kde se v analytickém modelu zavádí balíčky analytických tříd a realizace případů užití. Základem pro toto balíčkování byl vznik diagramu tříd a diagramů realizace případů užití k vybranému analyzovanému diagramu případů užití. S balíčkem je spojena problematika tzv. viditelnosti prvku, která určuje, jestli jsou prvky použitelné jen v mateřském balíčku, nebo i v jiných balíčcích. Prvek s prefixem + je veřejný (public) a použitelný i v jiných balíčcích. Prvek s prefixem je soukromý (private) a vně balíčku nepoužitelný. Grafická podoba balíčku je následující: Odběratel +DrobnýZákazník +Dealer OdběratelFirma název prvky třídy Závislost balíčků Balíčkování můžeme považovat za dekomponování, ovšem mohou se vyskytnout závislosti mezi prvky dvou a více balíčků. UML respektuje pět typů závislostí, viz knihu Jima Arlowa, str Pokud je možné, tak je nejlépe se závislosti vyhýbat. Závislost mezi balíčky se -42-

169 kreslí přerušovanou šipkou. Odběratel +DrobnýZákazník +Dealer OdběratelFirma Prodej +Faktura +ExpedičníList Prodejka Což můžeme sémanticky rozumět ve smyslu tvrzení změny v balíčku Odběratel se projeví ve změnách v balíčku Prodej (balíček Prodej závisí od balíčku Odběratel). Balíčkujeme-li případy užití, analytické třídy a realizace případů užití, tak se řídíme některými zásadami, které omezují závislosti balíčků: Asociované třídy, třídy spojené dědičností, agregací a kompozicí by měly být ve stejném balíčku (respektování soudržných uskupení tříd). Zdrojem balíčků jsou rovněž případy užití. Zde se vyhýbáme případům, kdy nějaký případ užití je realizován třídami různých balíčků (použití operací). Realizace případů užití přidáváme do balíčku se souvisícími třídami, které se svými atributy a operacemi na realizaci případů užití podílí Vnořené balíčky Použití vnoření je ve vztahu balíčků velmi časté. Vnoření druhé úrovně je nejpřijatelnější. Např. takové vnoření můžeme kreslit hrubě a detailněji: kotva Zobecňování balíčků Vztahy mezi balíčky můžeme realizovat dědičností. Její sémantický význam je následující: Všude tam, kde použijeme nadřazený balíček, můžeme použít podřazený balíček. -43-

170 7.2 Balíčkování tříd Balíčkování tříd je velmi častým případem balíčkování. Toto balíčkování se používá pro třídy, které spolu logicky souvisí. Nejčastěji je základem této souvislosti souvislost sémantická daná relacemi mezi třídami (asociace, dědičnost, agregace a kompozice). Třídy v balíčku jsou obvykle veřejné (public), soukromé (private) a chráněné (protected). Pochopitelně, třída má v balíčku unikátní výskyt a v jiných balíčcích se již nesmí vyskytovat. Obecně se dá říct, že kompozice mezi dvěma třídami jasně evokuje nutný výskyt těchto tříd ve stejném balíčku. Příklad 7-1 První ukázka ilustruje výskyt tříd, mezi kterými je dědičnost ve stejném balíku Odběratel. Odběratel Odběratel SoukromáOsoba Dealer Firma Příklad 7-2 Druhá ukázka ilustruje výskyt tříd, mezi kterými je kompozice, ve stejném balíku Prodej. Prodej 1 Asistent prodeje 0..* Objednávka * Expediční list Faktura * Prodejka Řádek faktury Řádek Objednávky * * Zboží 7.3 Kdy používat balíčky? Balíčky jsou technikou pro větší projekty vývoje software. Můžeme např. říci, že balíčkování tříd použijeme již tenkrát, když nedokážeme nakreslit diagram tříd na jednu stránku A4. Komponentový vývoj software vyžaduje balíčkování tříd jako nezbytný analytický postup. (každá komponenta má svůj balíček tříd). Obecně však můžeme říci, že balíček použijeme: Pro případy užití, které spolu sémanticky souvisí. Pro skupinu tříd, která realizuje nějaký složitější případ užití. Komponenta v schématu architektury může mít svůj/-vé balíček/-ky případů užití a balíčky jejich realizačních tříd. -44-

171 Shrnutí kapitoly: Kapitola vysvětluje použití tzv. balíčkování, které je téměř nezbytné pro modelování komplexních problémových domén. Vysvětluje se jaké případy užití a jaké třídy balíčkujeme. Na jedné straně je balíčkování výhodné, na druhé straně musíme dát pozor na nežádoucí vznik závislostí mezi balíčky. Na konci kapitoly se uvádí konkrétní příklady balíčkování. Σ Pojmy k zapamatování: Balíček, balíčkování, závislosti mezi balíčky, vnořené balíčky, implementace balíčků Testy a otázky: 1. Co chápeme pod pojmy balíček a balíčkování? 2. Co vlastně balíčkujeme a proč? 3. Jaké jsou zásady pro balíčkování a co jimi omezujeme? Úkoly k zamyšlení: 1. Kdy musím začít uvažovat o možnosti použití balíčkování? 2. Jak nejlépe eliminuji nevhodné závislosti mezi balíčky? -45-

172 8 ZAHÁJENÍ - pokročilé modelování případů užití Cíle: Znát (umět vysvětlit): 1. Možná pojetí pojmu pokročilé modelování případů užití. 2. Pojetí zobecnění aktéra. 3. Pojetí zobecnění případů užití a relací mezi nimi. Dovednosti (umět prakticky): 1. Uplatnit znalosti pro praktické zobecňování aktérů. 2. Uplatnit znalosti pro praktické provádění zobecňování případů užití. 3. Navrhovat relace mezi případy užití. Klíčová slova: Zobecnění aktéra, zobecnění případů užití, relace mezi případy užití V kapitole 6. jsme rozebírali pouhé základy modelování případů užití. Praxe práce s funkčními požadavky ovšem přináší další, námi dosud nediskutované problémy některých pokročilých aspektů modelování případů užití. Některé z nich se týkají syntaxe, jiné zase obsahu diagramů. Za syntaxně - obsahový problém můžeme považovat zobecnění aktéra (actor generalization) a zobecnění případů užití (Use Case generalization). Čistě obsahové aspekty mají dvě relace <<include >>, <<extend >>. 8.1 Zobecnění aktéra Podívejme se na následující obrázek. Aktéři Zákazník a Dealer mají mnoho společného, ale i odlišného. Zákazník je koncový odběratel-spotřebitel. Dealer je nejen zákazník, ale rovněž obchodní podnikatel, který má svou klientelu koncových odběratelů. Dealer je tedy vůči Dodávkovému systému BODY-CARE sám systémem. Dodávkový systém BODY-CARE Předat objednávku zboží Expedovat objednávku zboží Stornovat objednávku zboží Dopravce Zákazník systému BODY-CARE Dealer Ověřit stav Objednávky zboží zboží Vytvořit objednávku zboží Dispečer Provize za velkoodběr zboží Obrázek 8-1: Výchozí náčrt balíčku pro Dodávkový systém BODY CARE. -46-

173 Oba dva aktéři spouští několik stejných případů užití, ale Dealer spouští i jiné, např. Provize za velkoodběr zboží. Mají tedy mnoho společného ve svém chování. Společné chování lze zachytit pomocí zobecněného - abstraktního aktéra Odběratel. Aktéři Zákazník systému BODY-CARE (dále jen Zákazník) a Dealer dědí potom jeho chování, tj. role a relace k případům užití. Nová syntaxe je ilustrována v následujícím obrázku. Pochopitelně, tato syntaxní úprava, která má rovněž sémantický podtext a není předčasná, protože relace Dědičnost 4 je zavedena v objektovém paradigmatu obecně. Zde se jedná o dědění rolí a užitných případů. Doufejme, že to co jsme o této implementaci dědičnosti řekli, je teď dostatečná její definice. Dodávkový systém BODY-CARE Odběratel Předat Objednávku zboží Stornovat Objednávku zboží Expedovat Objednávku zboží Dopravce Ověřit stav Objednávky zboží Dispečer Zákazník Dealer Vytvořit Objednávku zboží Provize za velkoodběr zboží Obrázek 8-2: Zavedené zobecnění aktéra vedoucí na Odběratele. 8.2 Zobecnění případů užití Jestliže se v digramech případů užití vyskytne několik případů užití, které jsou vlastně jistými specifikacemi obecnějšího případu užití, tak provedeme zobecnění. Zde se rovněž aplikuje implementace relace dědičnosti, která je v objektovém paradigmatu zavedena obecně a to respektuje rovněž UML 2.0 Nicméně, musíme si uvědomit, že z relevantních prvků případu užití-předek (relace-vztah, vstupní podmínka, výstupní podmínka, krok v hlavním scénáři, alternativní scénář, atributvlastnost, operace) relace a atributy-vlastnosti předka nelze předefinovat u potomků. V publikacích se doporučuje zobecňovat případy užití v případech, kdy to umožňuje dát do rodičovského případu užití společné funkce několika případů užití. Odvozené případy užití dědí všechny vlastnosti a funkce od svého předka, tj. aktéra, relaci, vstupní a výstupní podmínky, hlavní scénář (tok aktivit), vedlejší scénáře (alternativní toky aktivit). 4 Obecné zavedení relace Dědičnost umožňuje: dědit funkce a vlastnosti od svých předků přidávat nové funkce a vlastnosti překrývat (měnit definice) zděděných vlastností a funkcí -47-

174 Zákazník Vytvořit objednávku zboží Dodávkový systém BODY-CARE Vytvořit objednávku zboží z čistého formuláře Vytvořit objednávku zboží z vybrané staré objednávky Obrázek 8-3: Zavedení dědičnosti případů užití. 8.3 Vztahy mezi případy užití Relace <<include >> Relace <<include>> se jaksi podobá vyvolání funkce. Je to např. případ, kdy musí být nějaká operace zahrnuta v daném případu užití. Najít údaje v katalogu zboží, může být operace potřebná pro jeden nebo několik případů užití, viz následující diagram. Dodávkový systém BODY-CARE Předat Objednávku zboží Odběratel Stornovat Objednávku zboží Expedovat Objednávku zboží <<include >> Dopravce <<include >> Zákazník Dealer Ověřit stav Objednávky zboží zboží Vytvořit Objednávku zboží Najít Objednávku zboží Dispečer <<include >> Provize za velkoodběr zboží Obrázek 8-4: Zavedení relace <<include>>. -48-

175 Sémantika relace <<include >> je jednoduchá. Případ běží až k místu zahrnutí, pak je přechod na vložený případ a po jeho ukončení zase návrat za místo zahrnutí (podobně jako vyvolání funkce). Přerušovaná šipka (stejná jako pro závislost), končí na zahrnutém případu užití (tedy, volající případ užití závisí na zahrnutém) Relace <<extend >> Je to relace uvádějící volné, doplňující rozšíření případu užití o jiný případ užití. Rozšiřující případ přidává k základnímu případu rozšiřující chování. Místo rozšíření se naznačuje ve scénáři rozšiřovaného případu. Může to být např. dáno hlídáním data pro uhrazení objednávky, což je podmíněné zařazení (viz následující diagram). K relaci <<extend >> se v diagramu může přidat poznámka o místu rozšíření. Dodávkový systém BODY-CARE Zákazník Předat Objednávku zboží Uhradit Objednávku zboží <<extend >> Upomínka <<extend >> Penalizace Vytvořit Objednávku zboží Místo rozšíření: Zpoždění platby Základní případ užití Rozšiřující případ užití Obrázek 8-5: Zavedení relace <<extend >>. Přerušovaná šipka pro relaci <<extend >> končí na základním případu užití (rozšiřující případ užití závisí na základním případu užití). 8.4 Drobné rady 1. Pokročilé možnosti v diagramech případů užití použijte tehdy, když to zjednoduší model případů užití. 2. Vyhýbejte se funkční dekompozici případů užití, to není objektový přístup. Každá z relací <<include>> a <<extend>> je něco jiného než strukturovaná dekompozici případu užití. Shrnutí kapitoly: Kapitola upozorňuje čtenáře na častá zobecňování v diagramech případů užití. Vysvětluje se, jak zobecňovat aktéry a vzápětí jak zobecňovat případy užití. Nakonec je čtenář zaveden na použití relací <<include>> a <<extend>> mezi případy užití. Otázky uplatnění zobecňování značně souvisí se složitostí problémové doména a samotných zkušeností analytika případů užití. Σ -49-

176 Pojmy k zapamatování: Zobecnění aktéra, zobecnění případu užití, zavedení relací Testy a otázky: 1. Proč zobecňujeme aktéry a co musí mezi nimi platit ve vztahu ke spouštěným případům užití? 2. Vyslovte názor na zavedení relací <<include>> a <<extend>> do diagramu případů užití (balíček). Úkoly k zamyšlení: 1. Lze pro zobecňování aktérů a případů užití použít běžné relace mezi třídami a které? 2. Jaký je Váš názor: zpřehlední zobecňování diagramy případů užití? 8.5 Literatura [EelCrip011] Eeles, P. Cripps, P.: Architektura software. Nepostradatelný průvodce návrhem softwarové architektury, která funguje. Brno: Computer Press, ISBN [Wieg08] [Kad04] [Jul08] [Ald05] [ArNe03] [Jul08] [ArNe07] [CoHu95] [Gib06] [Kru01] Wiegers, K, E.: Požadavky na software. Od zadání k architektuře aplikace. Brno: Computer Press, ISBN KADLEC, V.: Agilní programování: metodiky efektivního vývoje softwaru. Brno: Computer Press, s. ISBN Julínek, P.: Použití RUP pro malé SW projekty. Diplomová práce. Brno: Masarykova univerzita, Fakulta informatiky, Dostupné na WWW: < ALDORF, F.: Metodika RUP [online], diplomová práce, Dostupné na WWW: < ARLOW, J. - NEUSTADT, I.: UML a unifikovaný proces vývoje aplikací: průvodce analýzou a návrhem objektově orientovaného softwaru. Brno: Computer Press, s. ISBN X. Julínek, P.: Použití RUP pro malé SW projekty. Diplomová práce. Brno: Masarykova univerzita, Fakulta informatiky, Dostupné na WWW: < Arlow, J., Neustad, I. UML 2 a unifikovaný proces vývoje aplikací. Druhé vydání. Průvodce analýzou a návrhem objektově orientovaného software. Brno: Computer Press, ISBN COTTERELL, M. - HUGHES, R.: Software Project Management. Itp New Media, s. ISBN GIBBS, D.: Project Management with the IBM Rational Unified Process. IBM Press, s. ISBN KRUCHTEN, P.: The Rational Unified Process An Introduction. 2nd edition. Boston: Addison-Wesley, s. ISBN

177 [RJB05] [Vach07] RUMBAUGH, J. - JACOBSON, I., BOOCH, G.: The unified modeling language reference manual. 2nd edition. Boston: Addison-Wesley, s. ISBN VACH, D.: IBM Rational [online] Dostupné na WWW: < [KaMu07] Kanisová, H. Muller, M.: UML srozumitelně. Brno: Computer Press, a.s ISBN [Smr010] Smrčka, F.: Disertační práce (školitel Mišovič). Brno: Mendelova univerzita, Provozně ekonomická fakulta, Ústav informatiky, Poměrně zajímavé informace o UML získáte na adrese

178 VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky SOFTWAROVÉ INŽENÝRSTVÍ ČÁST IV. VÝVOJ OBJEKTOVÝCH APLIKACÍ PODLE METODIKY UP 3 - FÁZE ROZPRACOVÁNÍ STUDIJNÍ TEXT PRO KOMBINOVANOU FORMU STUDIA Milan Mišovič 2011

179 Prof. RNDr. Milan Mišovič, CSc. SOFTWAROVÉ INŽENÝRSTVÍ 1. vydání Vydala Vysoká škola polytechnická Jihlava, Tolstého 16, Jihlava, 2011 Tisk Ediční oddělení VŠPJ, Tolstého 16, Jihlava Za jazykovou a věcnou správnost obsahu díla odpovídá autor. Text neprošel jazykovou ani redakční úpravou. Milan Mišovič, 2011

180 Obsah Část IV. Vývoj objektových aplikací podle metodiky UP, 3 Fáze ROZPRACOVÁNÍ 9 ROZPRACOVÁNÍ - úvod První přiblížení, obecné údaje Analýza a její artefakty Něco o třídách, objektech, implementaci v UML a vybraných programovacích jazycích Objekty Třídy Notace třídy v UML Krátká diskuse o implementaci zpracování tříd a objektů Tvorba a uvolnění objektů ROZPRACOVÁNÍ - diagram analytických tříd a relace Základní aktivita objektové analýzy Něco o analytických třídách Hledání analytických tříd Relace v UML Spojení mezi objekty Cesty a topologie spojení Asociace mezi třídami Násobnost-kardinalita Čtení asociace Reflexivní asociace Průchodnost Něco málo o implementaci asociace Pojetí závislostí v UML Dědičnost Překrývání Polymorfismus Možnosti zobecňování tříd ROZPRACOVÁNÍ - diagramy stavů Úvod do problematiky stavů v UML Třídy a jejich primitivní stavy Pojetí stavu a stavového diagramu v UML Pojetí události

181 Událost volání operace Časová událost Událost změny (podmínky) Pojetí přechodu ROZPRACOVÁNÍ interakční diagramy Úvod do interakčních diagramů Komunikační diagramy Sekvenční diagramy: Závěr ROZPRACOVÁNÍ pracovní postup Návrh Obecně o pracovním postupu Návrh Relace <<trace>> Návrhové třídy ROZPRACOVÁNÍ Návrh, relace agregace a kompozice Úvod Něco o agregaci a kompozici Agregace Kompozice Stručně o některých upřesněních analytických relací pomocí agregace a kompozice Práce s asociacemi, které nejsou podporovány běžně používanými objektovými programovacími jazyky Asociace typu M:N Obousměrné asociace ROZPRACOVÁNÍ komponenty a jejich rozhraní Obecně o architektuře založené na komponentách Více o komponentách Více o podsystémech Rozhraní a jeho hledání Obecně o pracovní aktivitě Architektonický návrh Architektonický návrh ROZPRACOVÁNÍ příklad Evidence soukromých zbraní v ČR Obecně o problémové doméně Správa soukromých zbraní v ČR Pracovní postup Požadavky Pracovní postup Analýza Pracovní postup Návrh Literatura

182 9 ROZPRACOVÁNÍ - úvod Cíle: Znát (umět vysvětlit): 1. Primární cíle fáze ROZPRACOVÁNÍ. 2. Milník fáze ROZPRACOVÁNÍ. 3. Znát pojetí pracovního postupu Analýza a její artefakty. 4. Složení analytického modelu. Dovednosti (umět prakticky): 1. Uplatnit znalosti objektů a tříd pro praktické programování jednoduchých aplikací. 2. Uplatnit znalosti grafických notací UML pro praktické modelování objektů a tříd. Klíčová slova: Primární cíle, milník, třída, objekt, spustitelný architektonický základ, pracovní postup analýza, analytický model Zopakujme si základní údaje o souhrnných a primárních cílech fáze ROZPRACOVÁNÍ. Tato fáze je nesmírně závažná, protože musí nejen respektovat předchozí fázi, ale i dodávat podstatné vstupy pro fázi KONSTRUKCE. V literatuře o metodice UP se tato fáze považuje za kritickou v tom smyslu, že chyby v ní vzniklé se mohou nepříznivě odrazit na akceptaci software zadavatelem. A nejen to, vzniklé chyby se těžce odstraňují. Souhrnné cíle Za souhrnné cíle se považuje: Tvorba spustitelného architektonického základu. Vylepšení odhadu rizik. Definice atributů kvality. Zachycení případů užití pro 80 % funkčních požadavků. Tvorba přesného plánu fáze KONSTRUKCE. Formulace nabídky, která zahrnuje veškeré prostředky, čas, vybavení, personál a náklady. Hlavní pracovníci Na fázi se podílí především zadavatel, který poskytuje interview k vysvětlení požadavků a prostředí pro nasazení cílového software. Dále, je neodmyslitelná účast analytiků a programátorů softwarové firmy, která má cílový software produkovat. Primární zaměření Důraz je kladen zejména na následující aktivity: V pracovním postupu Požadavky: Upřesnění rozsahu systému a požadavků na něj kladených. V pracovním postupu Analýza: Upřesnění toho, co budeme tvořit (relevantní diagramy pro statiku a dynamiku problémové domény). V pracovním postupu Návrh: Tvorba stabilní architektury cílového software. V pracovním postupu Implementace: Tvorba Spustitelného architektonického základu. V pracovním postupu Testování: Testování korektnosti Spustitelného architektonického základu. -5-

183 Poznámka: 1. Z uvedených aktivit je zřejmé, že důraz je kladen na pracovní postupy Požadavky, Analýza a Návrh. Pracovní postup Implementace se zvýrazňuje až koncem fáze ROZPRACOVÁNÍ, kdy se začíná pracovat na Spustitelném architektonickém základu cílového softwarového systému. 2. Hlavní roli hraje tvorba Spustitelného architektonického základu. Je to termín pro softwarový systém, který již realizuje architekturu, ale je prázdný vůči architektonickým jednotkám, na kterých je architektura postavena (architektonické klišé cílového softwarového systému). Není to prototyp, který by se měl zahodit, ale klišé, které se bude postupně doplňovat, až se dosáhne podoby cílového software. Tato aktivita se odehraje zejména ve fázi KONSTRUKCE. Milník V souladu s tím, jak bylo neustále upozorňováno na architekturu, je milníkem fáze ROZPRACOVÁNÍ architektura cílového software (Life Cycle Architecture). Podmínky pro splnění jsou uvedeny v následující tabulce: Metriky Vytvoření spustitelného architektonického základu Spustitelný architektonický základ potvrzuje vyřešení všech důležitých rizik Co je potřebné dodat Software Spustitelný architektonický základ Statický model domény v UML Strukturální diagramy: Diagram tříd, Diagram objektů, Diagram komponent, Kombinovaný strukturální diagram, Diagram balíčků + deskripce ke všem diagramům Dynamický model domény v UML Diagramy chování: Diagramy případů užití, Aktivitní diagramy, Stavový diagram. Interakční diagramy: Diagram spolupráce, Diagram komunikace, Sekvenční diagram, Přechodový diagram interakcí + deskripce ke všem diagramům Vize o produktu je reálná a stabilizovaná Odhad rizik byl revidován Obchodní případ byl revidován a schválen Projekt byl vytvořen do dostatečné hloubky, umožňuje sestavení reálné nabídky cílového software, odhadu času, nákladů a prostředků pro následující fáze Zadavatel a týmy projektu souhlasí s Plánem projektu Plán projektu byl konfrontován s Obchodním případem projektu Vznikl konsenzus o pokračování projektu Dokument o vizi cílového software Aktualizovaný odhad rizik Aktualizovaný Obchodní případ Aktualizovaný Plán projektu - Zápis konfrontace Plánu projektu a Obchodního případu Konečný dokument agregující výsledky fáze ROZPRACOVÁNÍ Objektová analýza spočívá obecně v tvorbě modelů, které zachycují charakteristické rysy problémové domény, které se přenáší do cílového softwarového systému, tj. statiku a dynamiku problémové domény. Analytické modely (pro statiku a dynamiku problémové domény) jsou pro vývoj software strategické. -6-

184 9.1 První přiblížení, obecné údaje V této kapitole nám půjde o zkoumání podstaty objektově orientované analýzy, kterou budeme provádět v pracovním kroku Analýza. Skutečností je, že analýzu jsme již prováděli na konci fáze ZAHÁJENÍ a tam šlo o provedení analýzy uživatelských požadavků. Hlavním cílem objektové analýzy v metodice UP je vytvoření tzv. analytického modelu problémové domény. Je to model, který plně říká CO má softwarový systém udělat, ale vůbec neříká, JAK to má udělat. Problematika JAK se ponechává na pracovní postup Návrh. Následující pracovní postupy nám jistě pomohou v úspěšné tvorbě analytického modelu. 9.2 Analýza a její artefakty Následující obrázek ilustruje vstupy a výstupy objektové analýzy. Model případů užití Objektová analýza Analytické třídy Realizace případů užití Analytické třídy představují klíčové entity problémové domény, na jejich základě se modeluje statika problémové domény. Základ statiky se zachycuje v následujících diagramech: Diagram tříd, Diagram objektů, Diagram komponent, Kombinovaný strukturální diagram a Diagram balíčků. Naopak, Realizace případů užití dokumentuje vzájemnou komunikaci objektů-instancí analytických tříd a tak modeluje chování-dynamiku problémové domény a pochopitelně rovněž cílového softwarového systému na základě specifikací, zadaných případy užití. Základy dynamiky se zachycují v následujících diagramech: Diagramy chování: Diagramy případů užití, Stavový diagram, Diagram činností - Aktivitní diagram. Interakční diagramy: Diagram spolupráce, Diagram komunikace, Sekvenční diagram, Přechodový diagram interakcí + deskripce ke všem diagramům. Následující metamodel ilustruje složení analytického modelu z jednotlivých analytických balíčků analytických tříd a realizací případů užití (jako příklad jsou uvedeny jen čtyři balíčky). P3 P1 Analytický model P2 P4 Analytické třídy Realizace případů užití Analytický balíček Obrázek 9-1: Metamodel ilustrující složení analytického modelu. -7-

185 Analytický model je koncepční povahy, vyhýbá se detailům a sleduje esenci. Důležité teď je, že analytický model konstruujeme pro celou problémovou doménu, je-li jednoduchá, nebo pro každý její subjekt zvlášť, je-li komplexní složitá. Pochopitelně, v hrubém návrhu architektury softwarového systému odpovídají podsystémům problémové domény tzv. komponenty. Analýza v UP má tyto obecné implementace: Architektonická analýza... provádí architekt Analýza případů užití... inženýr případů užití Analýza tříd a balíčků... inženýr analytik. Často se v publikacích uvádí mnoho rad, které mají zabezpečit úspěšnou tvorbu analytických modelů. V publikaci Jima Arlowa je několik takových rad na stránkách Uveďme některé jim podobné: Tvořte analytický model výlučně v jazyku problémové domény. Každý diagram by měl objasnit určitou část chování cílového systému. Případy užití kreslete přehledně a srozumitelně. Rozlišujte problémovou doménu a doménu řešení-cílového software (podrobné úvahy o návrhu softwarového systému). Nesnažte se hned o zákres všech vazeb v analytických modelech. Pozorně zvažujte případy přirozených hierarchií abstrakcí v problémové doméně a vyvozujte z toho datové asociace, agregace a dědičnosti. Zkoumejte užitečnost analytického modelu. Snažte se, aby analytický model byl jednoduchý a transparentní pro každého účastníka projektu. Další problematika přednášky souvisí s velmi stručnou, ale přehlednou diskusí obsahu a významu takových termínů jako jsou: Objekty, třídy a jejich notace v UML Zapouzdření Předávání zpráv Tvorba instancí Rozsah platnosti Tvorba a uvolnění objektů Všechny tyto akce s objekty a třídami jsou spojeny jednak s implementací v UML a rovněž s implementací v některých objektových programovacích jazycích (např. Visual Basic, C# a C ++, ). V mnoha publikacích jsou tyto implementace spojovány, a je to takto podáno rovněž v knize Jima Arlowa. 9.3 Něco o třídách, objektech, implementaci v UML a vybraných programovacích jazycích Objekty Třídy a objekty jsou základními entitami všech objektově orientovaných systémů. Objekt je diskrétní entita, která zapouzdřuje stav a chování, jako instance jisté třídy. Ukazuje to rovněž následující ilustrativní obrázek (obrázek není z UML). V implementaci zapouzdření je -8-

186 využívání operací řešeno pomocí odkazů. V reálné instanci - objektu operace a metody nejsou, ale jsou na ně účinné reference do objektového frame-work. Atributy jsou ovšem neoddělitelnou součástí objektů-instancí. informační struktura, atributy ( a 1, a 2,, a n ) chování - operace chování - metody Služba složení z jiných objektů pouzdro Servis služeb - interface Obrázek 9-2: Klasický pohled na objekt. Každý objekt je instancí nějaké třídy, která definuje společnou množinu atributů, operací a metod pro objekty-instance dané třídy. Identita objektu: Každý objekt má jedinečnou identitu, která jej odlišuje od všech ostatních objektů (rovněž od objektů téže třídy). Identita může být dána pomocí sériového čísla. Identifikaci spravuje implementační technologie zabudovaná v objektovém programovacím jazyku. Stav objektu: Stav objektu je definován hodnotami jeho atributů. Stav je stejný pro všechny objekty téže třídy. Jelikož jsou některé datové typy atributů nekonečné množiny, může být počet stavů nekonečný. V souboru Část III-Kap 1 Objektové paradigma jsme zavedli operaci redukce nekonečné množiny stavů na konečnou relevantní množinu stavů s ohledem na postavení objektů v problémové doméně. Na operaci může být reagováno různě, závisí to od stavu, ve kterém se objekt nachází (např. operace DejPeníze pro objekt-instanci třídy Účet vede do jiného stavu, když účet poklesne do mínusu a do jiného, když do mínusu nepoklesne). Chování: Chování objektu je dáno operacemi, které se v implementaci realizují pomocí tzv. metod. Provedení operace může způsobit změnu některého z atributů objektu, a tedy dojde ke změně stavu objektu. Zapouzdření: Zapouzdření, tj. ukrývání dat objektu před jinými objekty, vymezuje pro objekt provedení operací výlučně jen nad svými atributy. Je to obrovská výhoda v přidávání operací, což může vést k tvorbě rozsáhlejšího rozšiřitelnějšího software. Předávání zpráv: Jak objekty spojit, aby prezentovaly dynamiku problémové domény, tj. zpracování dat? Objekty již v sobě mají atributy a reference na operace. To je základ, který se musí využít. Objekty spolupracují - komunikují pomocí tzv. zpráv. Notace jedné zprávy zahrnuje jméno operace a jména argumentů (vstup) a návratových hodnot. Objekt na zprávu reaguje. V objektovém software se objekty-instance zřizují, posílají si navzájem zprávy a dostávají výsledky, potom jsou uvolněny a vymazány. Realizace takto naznačeného spojení objektů je -9-

187 dána implementační technologií v konkrétním objektovém programovacím jazyku. Notace objektů v UML Vzhledem k tomu, že třída je nositelem obecných vlastností objektů (chování, operace, metody a složení) nepřechází tyto obecné vlastnosti do objektů-instancí třídy. Implementační objekt-instance je nositelem pouze své identifikace a hodnot atributů. Odkazy na zbývající komponenty třídy zařizuje implementační technologie. Grafická notace objektu-instance v UML je dána obdélníkem se dvěma oddíly: oddíl názvů a oddíl atributů. Název objektu Název třídy můjúčet:účet jménoúčtu:string = zústatek:double vlastník:string = Jan Malý Oddíl názvů Oddíl atributů Název atributu Typ atributu Hodnota atributu Obrázek 9-3: Grafická notace objektu v UML. Anonymní objekt je bez názvu. Název objektu začíná malým písmenem. Je-li název objektu složen z více slov, tak první písmena, počínaje druhým slovem, píšeme s velkým písmenem. Uvedení atributů není povinné Třídy Třída je deskriptorem množiny objektů se stejnými vlastnostmi (množina atributů, chováníoperace, metody, relace). Tyto vlastnosti potom nemusíme popisovat u objektů-instancí dané třídy. V problémové doméně existují jisté klasifikace obecné třídy, které se vyplatí deklarovat jako podtřídy podřízené obecné třídě a které dědí atributy a chování. Zde jde o relaci dědičnosti. Může ovšem nastat jiná situace, kterou Jim Arlowe vysvětluje na vztahu stromu a jeho listů. Pro list stromu a strom postavíme dvě třídy. Každý objekt-instance třídy List patří k specifickému objektu - instanci třídy Strom. Jednotlivé stromy si nemohou listy vyměňovat ani společně sdílet. Protože jeden typ listu je nerozlučně spjat s typickým stromem, potom tento strom své listy jistého typu řídí. Tento vztah je v UML označen jako kompoziceskládání. Někdy se stává, že význam nějaké třídy vznikne seskupením jiných nezávislých tříd. Např. instanci třídy auto seskupíme z jistých instancí tříd: kola, podvozek a karoserie. Jedno je známo, že jeden typ kol je možno spojit s podvozkem mnoha aut. Může se stát, že auto se odveze na skládku, ale kola můžeme ještě použít. Životný cyklus kol, není závislý na životním cyklu auta. Tato relace se nazývá agregace, seskupení instance auta z instancí tříd kol, podvozku a karoserie. Třídy a jejich instance: Relace závislosti třídy a objektu-instance této třídy se nazývá << instantiate>>, a kreslí se přerušovanou šipkou << instantiate>>. Směr šipky vychází od závislého objektu. Pochopitelně, můžeme např. pro třídu Účet nakreslit dvě instance a použít inicializační nastavení některých atributů. -10-

188 Účet čísloúčtu:string= Účet zústatek:double čísloúčtu:string vlastník:string zústatek:double vlastník:string vybrat() uložit() Oddíl názvu Oddíl atributů Oddíl operací << instantiate>> milanůvúčet:účet čísloúčtu: zústatek: vlastník: Milan Malý << instantiate>> petrůvúčet:účet čísloúčtu: zústatek: vlastník: Petr Rychlý Obrázek 9-4: Účet a jeho dvě instance Notace třídy v UML Již z předchozího obrázku je zřejmé, že třídu v UML zakreslíme jako obdélník s třemi oddíly: oddíl názvu, oddíl atributů a oddíl operací. V analytickém modelu je pro třídu nutno zobrazit: název třídy, klíčové atributy, klíčové operace a stereotypy (mají-li význam). Zobrazovat není nutno: označené hodnoty, operační argumenty, viditelnost, inicializaci hodnoty. Příklad notace třídy v UML (podle Jima Arlowa, str. 153), která je nad požadavky pro analytickou třídu: <<entity>> BankovníÚčet -číslo:string -vlastník:string -zůstatek:double=0.0 +vytvořit (číslo:string, vlastník:string) +uložit(množství:double) +vybrat(množství:double) +dejčíslo():string +dejvlastnik():string +dejzůstatek():double Obrázek 9-5: Notace třídy podle Jima Arlowa Krátká diskuse o implementaci zpracování tříd a objektů Viditelnost: Viditelnost se vztahuje na atributy a operace objektové třídy. K označení viditelnosti se v UML používají ornamenty + - # ~ ve významu veřejný, soukromý chráněný a balíček. -11-

189 Viditelnost atributů se v objektově orientovaných jazycích Visual Basic a C# označují slovy public, private, protected a package což významově souhlasí s UML.. Typ atributů: Typ je primitivním typem nebo další třídou. UML připouští typy: Integer, UnlimitedNatural, Boolean, String. Typ Real je povolen v OCL jazyku. Násobnost: Násobnost se u atributů velmi často vyskytuje. Např. notace -jméno:string[2..*], -adresa:string[3], - string[0..1] znamenají výskyt dvou řetězců, tří řetězců a maximálně jednoho řetězce. Inicializační hodnota: Inicializační hodnota se atributu přiřazuje v okamžiku tvorby objektu-instance. Oddíl operací: Operace jako funkce mají název, seznam argumentů a typ návratové hodnoty. Notace funkce je následující: Viditelnost název (směr název argumentu: typargumentu = inicializačníhodnota) : návratový typ Směr argumentu má význam vstupní/výstupní. Používají se slova: in p 1 :Integer inout p2:integer out p3:integer return p4:integer return p5:integer Co znamená notace minimálníhodnota ( a:integer, b:integer):integer? Platnost operací a atributů: Operace a atributy mají obvykle platnost instance a někdy také platnost třídy. Přístup k operacím a atributům je určen rozsahem platnosti operace a rozsahem platnosti volané funkce. Operace třídy mohou přistupovat jen k jiným operacím a atributům té samé třídy. Operace třídy nemohou používat operací objektu-instance Tvorba a uvolnění objektů Na tvorbu objektu-instance se v objektovém jazyku používá tzv. konstruktor. Obvykle to jsou speciální metody s rozsahem platnosti třídy. Konstruktor nemá v době analýzy žádný relevantní význam. Často je to ovšem obecná metoda. K uvolnění objektu se používá destruktor. V objektových jazycích to je opět obecná metoda. Shrnutí kapitoly: Začátek kapitoly je věnován úvodu do objektové analýzy, který končí objasněním termínu analytický model. V druhé části je v kapitole krátké zopakování relevantních termínů objektového paradigmatu a vysvětleno použití grafických notací jazyka UML pro objekt a třídu. Na konci kapitoly je stručný popis zpracování objektů a tříd v objektových programovacích jazycích. Σ Pojmy k zapamatování: Objekt, třída, objektová analýza, analytický model, UML, notace objektů a tříd v UML Testy a otázky: 1. Co je obsahem objektové analýzy? 2. Vysvětlete co je analytický model. -12-

190 Úkoly k zamyšlení: Pokuste se porovnat schopnosti některých objektových programovacích jazyků vzhledem k zpracování tříd a jejich instancí. -13-

191 10 ROZPRACOVÁNÍ - diagram analytických tříd a relace Cíle: Znát (umět vysvětlit): 1. Pojetí pojmu analytická třída. 2. Způsoby hledání kandidátů a samotných analytických tříd. 3. Základní relace mezi třídami (asociace, závislost, dědičnost). 4. Pojetí překrývání a polymorfismusmu. Dovednosti (umět prakticky): 1. Uplatnit znalosti pro praktické nacházení kandidátů a samotných analytických tříd. 2. Uplatnit znalosti pro nacházení asociací mezi třídami, čtení asociací, stanovení násobnosti a rozklady asociace typu 1:N a reflexivity. Klíčová slova: Kandidát analytické třídy, analytická třída, relace mezi třídami, spojení mezi objekty, asociace tříd, násobnost, role, průchodnost, reflexivní asociace, asociace typu 1:N, překrývání, polymorfismus 10.1 Základní aktivita objektové analýzy Nalezení analytických tříd je základem pro konstrukci relevantního diagramu tříd pro modelování statiky problémové domény. Již z tohoto důvodu je hledání analytických tříd základní aktivitou objektové analýzy. Co vše k hledání potřebujeme a jaké metody pro hledání analytických tříd použijeme, je popisováno v následujícím textu. Případy užití jsou předmětem zkoumání objektové analýzy. Model případů užití je téměř nejdůležitější, zejména detailizace jednotlivých případů užití přímo napovídá kandidáty analytických tříd. Provozní model Model požadavků Analýza jednotlivých případů užití, typy kandidátů analytických tříd Analytická třída Model případů užití Popis architektury softwarového systému Realizace případů užití Sekvenční a komunikační diagramy Obrázek 10-1: Vstupy a výstupy analýzy případů užití Obrázek 10-1 ilustruje vstupy a výstupy pro postupnou analýzu případů užití a hledání kandidátů analytických tříd. Pochopitelně, analýza případů užití bude teď jiná, než ta, kterou jsme prováděli v rámci analýzy funkčních požadavků uživatele, když jsme případy užití tvořili. Model požadavků a Model případů užití již známe. Byly vytvořeny na konci fáze ZAHÁJENÍ. Provozní model problémové domény může být např. business modelem, procesním -14-

192 modelem anebo strukturálním modelem. Tento model může být dokonce suplován rovněž kontextovým diagramem z Kontextové analýzy. Jde o to, abychom z provozního modelu mohli vyčíst kandidáty na analytické třídy. Nejvhodnější k tomu je business model, který uvádí podnikové procesy, procesní vlákna (výsledek procesní logiky podniku) a jimi zpracovávaná podniková data a další široký kontext procesů v podnikovém prostředí. Nemáme-li provozní model, tak přicházíme o jeden důležitý zdroj informace při hledání analytických tříd. Na Model požadavků se obracíme z toho důvodu, že obsahuje rovněž specifikace nefunkčních požadavků, a ty nemůžeme při tvorbě softwarového systému obcházet. Hlavní ovšem jsou detailní popisy jednotlivých případů užití. Obsahují zmínky o podstatných podnikových entitách (Zaměstnanec, Odběratel, Dodavatel, ) a jiných datových prvcích (Faktura, Objednávka, ). Popis architektury, případně Architektonický model, dává rovněž přehled o začlenění případů užití do různých prozatímních architektonických jednotek (podsystémů a modulů), což také přispěje k hledání analytických tříd Něco o analytických třídách To, co zde bude řečeno, není návod na hledání analytických tříd, ale jen stručná charakteristika vlastností a poslání analytické třídy. Analytické třídy abstrahují realitu problémové domény a mapují podstatné pojmy, s kterými se v problémové doméně setkáváme. Jsou to většinou podstatná jména, jako Zaměstnanec, Faktura, Objednávka, Oddělení, Produkt, Zboží, Účet, Mapování reálně existujícího pojmu je založeno na mapování jeho vlastností a manipulaci pomocí operací nad jeho vlastnostmi-atributy. V mnoha publikacích jsou pro některé problémové domény (podnik, školy, armáda, veřejný život, ) již uvedeny seznamy pojmů, tj. kandidátů na třídy. Analytické třídy by neměly obsahovat všechny atributy mapovaného pojmu, ale jen relevantní, (vycházející z hlavního scénáře) a měly by obsahovat služby-operace, které musí pro dynamiku problémové domény analytické třídy poskytovat. Zobrazení třídy a objektu v UML jsme již probrali, ale pro zopakování uveďme její náčrt znovu. Zobrazení třídy: Účet čísloúčtu:string= Účet zústatek:double vlastník:string čísloúčtu:string zústatek:double vlastník:string vybrat() uložit() Oddíl názvu Oddíl atributů Oddíl operací V analytickém modelu je pro třídu nutno zobrazit: název třídy, klíčové atributy, klíčové operace a stereotypy (mají-li význam). Zobrazovat není nutno: označené hodnoty, operační argumenty, viditelnost, inicializaci hodnoty. Název objektu Název třídy Zobrazení objektu: můjúčet:účet jménoúčtu:string = zústatek:double vlastník:string = Jan Malý Oddíl názvů Oddíl atributů Název atributu Typ atributu Hodnota atributu -15-

193 Analytická třída je vždy jednoznačně spjata s případem užití, na jehož realizaci se podílí. Je možné, že daná analytická třída se podílí na realizaci více případů užití V objektových modelech musí být u objektové třídy uveden oddíl názvů. Příklad 10-1 Představme si, že hledáme analytické třídy problémové domény Řízení vědeckých konferencí. Tato doména není typu business domény, nemá tolik pojmů jako malý obchodně-výrobní podnik. Z vlastních zkušeností můžeme, velni rychle poukázat na tyto kandidáty analytických tříd: Zájemce o účast na konferenci (neregistrovaný) Registrovaný účastník Člen organizačního výboru Člen programového výboru Odborný garant konference Přednášející v plenárním zasedání Rozšířený abstrakt Finální příspěvek Odborná sekce Vedoucí odborné sekce Oponent Platba účastnických poplatků. Náhodné nebo zkušenostní hledání kandidátů analytických tříd však nemůžeme považovat za vhodnou metodu pro začátečníky v použití objektové analýzy. Kandidáti na analytické třídy jsou silně spjaty s vlastní problémovou doménou a daným případem užití. Protože v používání každé vývojové metodiky je jistý gradační řád získávání informací, musíme zvažovat, že zatím nemáme žádný jiný materiál než výsledky fáze ZAHÁJENÍ. Z těchto výsledků jsou relevantní požadavky uživatele (funkční, nefunkční), dále mapování funkčních požadavků na případy užití a specifikace případů užití s hlavními scénáři. Ve specifikaci případů užití jsou uvedeny nejen aktéři, ale i role, které hrají osoby, instituce, systémy v hlavních scénářích případů užití. Jsou to možní adepti na analytické třídy, dále různá vstupní a výstupní data např. dokumenty, které můžeme opět považovat za adepty analytických tříd. Velmi užitečným zdrojem je tedy hlavní adresář každého případu užití. Zde mohou mít různé pojmy (podstatná jména) charakter abstraktního označení množiny objektů. Pochopitelně, je-li náš hlavní scénář mělký, nečekejme, že z něj informaci o kandidátech analytických tříd vyčteme. Teď bychom mohli uvést několik známých poznatků z praxe v hledání analytických tříd: Třídy mají navzájem jisté vztahy. Třída bez vztahů k jiným třídám téměř neexistuje (snad jen jako pomocná nemající silnou souvislost s problémovou doménou). Nehledejte velké množství malých tříd, ani malé množství velkých tříd. Vyhýbejte se bohaté množině hierarchických vztahů mezi třídami Hledání analytických tříd Pokusíme se uvést několik metod, které sice nezaručí, že musíme všechny analytické třídy nalézt, ale mohou být prvotním užitečným přístupem začínajícího analytika. 1. Čtení detailních specifikací případů užití (zejména hlavního scénáře) a hledání kandidátů tříd z těchto specifikací. Toto považujme za hlavní způsob hledání kandidátů analytických tříd. Pro vyšší srozumitelnost mohou být hlavní scénáře vyjádřeny pomocí aktivitních diagramů (viz příslušný soubor pro fázi ZAHÁJENÍ). 2. Sledování popisu problémové domény, kdy si všímáme především ne všech podstatných jmen, ale jen těch, o nichž si myslíme, že se podílí na podstatě (data, procesy) problémové domény. Taková podstatná jména považujme za kandidáty na analytické třídy. Dále si všímejme sloves nebo slovesných frází v kontextu -16-

194 s kandidátskými podstatnými jmény. Tato slovesa/slovesné fráze mohou být vyjádřením operací, které se nerozlučně vztahují k jistému kandidátovi na analytickou třídu. Např. všimneme si podstatné jméno abstrakt (myslíme abstrakt budoucího příspěvku na konferenci) a budeme toto jméno považovat za kandidáta. Potom někde dále v popisu problémové domény čteme slovesní frázi posuzování abstraktů. Zcela jasně je to operace týkající se zmíněného kandidáta. Pro tuto metodu je velmi užitečný Slovník pojmů problémové domény, kde najdeme kandidáty analytických tříd přímo. Metoda je ovšem pro začátečníky v používání metodik tvorby software poněkud obtížná. 3. Metoda lístečků spočívá v použití pracovníků problémové domény pro návrh podstatných pojmů, s nimiž se setkávají v souvislosti s jednotlivými případy užití. Podstatné pojmy potom považujeme za kandidáty analytických tříd. 4. Hledání příhraničních tříd umožní najít kandidáty pro třídy pečující o styk systému s klienty, jinými systémy, nebo s technickými zařízeními. 5. Použití vzorů archetypů. Jde o seznamy specifikací analytických tříd pro různé výseky problémových domén. Takové seznamy jsou užitečnou pomocí zejména začínajícím analytikům. O každém z kandidátů na analytickou třídu bychom měli provést analýzu, výsledkem které je, jestli kandidáta zvolit za analytickou třídu nebo ne. Dostanete tak prvky modelu tříd, a ty, o kterých si myslíte, že mají vztah, spojte čárou (naznačíte pouhé spojení bez specifikace jeho typu). Dostáváte tak první návrh modelu analytických tříd. Pochopitelně, v hledání analytických tříd je rozhodující praxe a v ní získané zkušenosti. Poněkud postarší analytici využívají často i zkušenosti z hledání tzv. datových entit ve strukturovaném paradigmatu. Mnozí ovšem velmi rádi sáhnou k archetypům a čerpají z nich Relace v UML Pojem relace je významově vícerozměrný. V první řadě je to pojem z teorie množin, definovaný následujícím předpisem: Buďte A, B dvě množiny, A x B jejich kartézský součin. Potom každá množina, s vlastností AxB je binární relací na množinách A, B. Relace mají v UML 2.0 obecný význam sémantických vazeb mezi modelovanými prvky, spojující předměty a abstrakce dohromady. Některé z nich vyhovují matematickému pojetí, jiné ne. Dosud jsme mluvili o těchto relacích: Přiřazovací relace mezi funkčními požadavky a případy užití (tzv. mapování). Přiřazovací relace (vzor 1:1, 1:N) mezi aktéry a případy užití. Vzájemné relace mezi případy užití (jde o <<include>> a <<extend>>). Vzájemné relace mezi aktéry (dědičnost zobecnění/specializace). Za další typ relace mezi třídami v UML je považována tzv. asociace. Dříve musíme ovšem vysvětlit spojení (link) mezi objekty, které budeme později považovat za instanci asociace Spojení mezi objekty Než začneme zkoumat relace mezi analytickými třídami a speciální případ relace tzv. asociaci, řekneme si několik slov o obecném pojmu spojení objektů-instancí dvou tříd. -17-

195 Spojení mezi dvěma objekty je jejich sémantická vazba, která umožňuje předávání zpráv. Tedy, zprávy mezi objekty jsou předávány právě prostřednictvím spojení. Jestliže cílový objekt obdrží zprávu, tak spustí požadovanou operaci uvedenou ve zprávě. Minimálním požadavkem na spojení dvou objektů je to, aby alespoň jeden z nich obsahoval odkaz na druhý. Pomocí pojmu spojení můžeme definovat objektový program (objektový software) takto: Diagram, který znázorňuje objekty instance tříd a jejich spojení v reálném čase, se nazývá objektovým programem. Takové spojení je v podstatě dynamickou vazbou trvající krátkou dobu, tj. spojení nemusí trvat po celou dobu existence objektů. Ačkoliv jsme mluvili o binárním spojení dvou objektů, je v UML možné použít spojení ke sdružení více objektů, tj. vytvořit n-ární spojení. obuv:oddělení 325:Zaměstnanec Třídy jsou Oddělení a Zaměstnanec spojení Obrázek 10-2: Spojení objektů obuv a zaměstnance č. 325 Spojení zde spojuje objekt 325 s objektem obuv a obráceně (obousměrné spojení). Neníli spojení jednoznačně obousměrné, tak jednosměrné spojení označujeme šipkou. Zprávy potom mohou procházet jen směrem vyznačeným šipkou. Zamlčená identifikace objektu :Oddělení :Zboží Obrázek 10-3: Spojení objektů se zamlčenou identifikací Zprávy lze posílat pouze z instance typu: Oddělení na instanci typu: Zboží, ale ne obráceně. Jinak to znamená, že objekt typu: Oddělení obsahuje objektový odkaz k instanci typu: Zboží. Je zvykem používat tři možnosti pro vyznačení průchodnosti spojení: Všechny šipky jsou potlačeny. Pro obousměrné spojení se šipky nekreslí. Jednosměrná spojení mají jen jednu šipku Cesty a topologie spojení Postupné zasílání zpráv mezi objekty může představovat orientovanou cestu mezi objekty jisté topologie. Pro ilustraci spojení se nejčastěji používá vodorovných a svislých čar. Topologie může být hierarchická, vodopádová, hvězdicová a rovněž jako hrábě, Asociace mezi třídami Asociace (association) popisuje vztahy mezi třídami. Jestliže spojení sdružuje objekty, -18-

196 potom asociace sdružuje třídy. Souvislost spojení a asociace je ale poněkud závažná. Je zřejmé, jestliže má existovat spojení mezi dvěma objekty, musí existovat asociace mezi jejich třídami. Je tedy spojení instancí asociace. To je ovšem velmi závažné tvrzení, které relaci závislosti (instantiate) mezi třídou a objektem rozšiřuje na dvojici asociace a spojení. Ilustruje to následující obrázek. Oddělení Zaměstnanec asociace <<instantiate>> <<instantiate>> <<instantiate>> obuv:oddělení 325:Zaměstnanec Obrázek 10-4: Závislost objektů-instancí na mateřských třídách Asociace dvou tříd podmiňuje skutečnost, že mezi instancemi těchto tříd lze vytvářet spojení. Později uvidíme, že za speciální vylepšení asociace budeme považovat tzv. agregaci-seskupení a kompozici. Ke každé asociaci přiřazujeme: Název sociace. Název role. Násobnost (kardinalita). Průchodnost. Název, stejné pravidlo jako pro metody slovesní tvar. Jako prefix nebo sufix může být uvedeny šipka průchodnosti. Název role, podstatné jméno. Násobnost podle tabulky níže. Průchodnost, pomocí šipky. Na následujícím obrázku je uveden název asociace (Zahrnuje) a rovněž jsou uvedeny názvy rolí (personální jednotka, člen) v asociaci pro obě třídy. Takové bohaté označení je nadbytečné (považuje se dokonce za chybu) a uvádí se buď jen název asociace, anebo jen názvy rolí tříd v asociaci (červeně je anotace). Název role Oddělení personální jednotka Název asociace Zahrnuje člen 1 1..* Zaměstnanec 1 * násobnost Obrázek 10-5: Asociace tříd Oddělení a Zaměstnanec s anotací Názvy rolí jsou přirozené (podstatná jména) a v souladu se sémantikou asociace, která působí jako podnikové pravidlo, za které odpovídá podnik. Podniková pravidla se obecně chápou jako omezení podnikových procesů. Takže sémantiku čteme následovně: Oddělení zahrnuje alespoň jednoho zaměstnance (nejsou oddělení bez zaměstnanců). Zaměstnanec je zahrnut právě v jednom oddělení. -19-

197 V daném okamžiku je zaměstnanec zahrnut jen v jednom oddělení. Postupně, např. za jeden rok, mohl být zahrnut v několika odděleních (přestupoval z oddělení do oddělení) Násobnost-kardinalita Násobnost (multiplicity) je omezení spojení mezi objekty tříd účastnících se asociace v daném okamžiku. Přesněji: násobnost určuje, kolik instancí jedné třídy může být ve spojení s kolika instancemi druhé třídy. Násobnost zapsaná u jedné třídy stanovuje počet objektů druhé třídy, která se účastní téže asociace. Jazyk UML nabízí obecné notace (ornamenty) násobnosti podle následující tabulky: Ornament Význam Typ asociace nula nebo jedna 1:0, právě jedna 1:1 0..*... nula nebo více 1:0,N *... nula nebo více 1:0,N 1..*... jedna nebo více 1:N jedna až šest 1:N 1..4, (jedna až čtyři) (pět až sedm) 1:N Často se vyskytuje asociace typu M:N, např. Lékař * * Pacient Jazyk UML používá pro takovou asociaci její rozklad pomocí asociační třídy. Např. pro náš příklad to může být třída Návštěva a rozklad (spíše zjemnění) potom vypadá následovně: 1 * Lékař Návštěva * 1 Pacient Později uvidíme, že v pracovním postupu Návrh budeme se zjemněním pokračovat dál Čtení asociace Zachovávají-li se anotační pravidla asociace, je asociace ze svého diagramu přesně čitelná. Tedy, její sémantika by měla být zřejmá a není možno si něco vymýšlet. Pokud je násobnost zamlčena (což se považuje za chybu), tak v UML neplatí žádné pravidlo o její implicitní hodnotě. Násobnost asociací by měla být v analytickém modelu tříd uvedena, protože je respektováním jistého sémantického pravidla z problémové domény. 1 Příklad 10-2 Zkuste přesně přečíst sémantiku následující asociace, která může fungovat v běžné problémové doméně. Oddělení personální jednotka člen 1 * Vlastní k Zaměstnanec 1 1 Je administrátorem 0..* 0..* Softw. aplikace Obrázek 10-6: Zadání komplexních asociací pro účel čtení jejich sémantiky -20-

198 Reflexivní asociace V praxi se vyskytují rovněž případy, kdy jsou třídy asociovány samy se sebou. Je to tzv. reflexivita 1 dané asociace. Např. ve skladu jsou součástky. Jedna součástka může, nebo nemusí být složena z jiných součástek. Tuto asociaci můžeme ilustrovat následovně: Součástka nebo 0..* Součástka 0..* 0..* Skládá se Součástka Asociaci Skládá se čteme: Součástka se neskládá ze žádné další součástky, nebo se skládá z jedné a více součástek 0..* Skládá se Na úrovni spojení objektů-instancí typu Součástka vzniká síť, která není obecně hierarchická. Jestliže bychom měli následující rekurzivitu pro třídu B, potom spojení objektů-instancí má hierarchický charakter B * Jsou způsoby jak reflexivní asociaci odstranit, ale není to teď důležité. Touto problematikou se budeme zabývat v dalším textu souboru pro fázi ROZPRACOVÁNÍ Průchodnost V rovině spojení mezi objekty zdrojové třídy A a cílové třídy B je situace, kdy objekt typu A může zasílat zprávy jednomu nebo více objektům typu B, pochopitelně v závislosti na násobnosti. UML 2.0 doporučuje modelovat průchodnost takto: 1. Zcela explicitní průchodnost (dané všechny šipky-průchodnost a všechny křížky-neprůchodnost) 2. Zcela neviditelná průchodnost (šipky, ani křížky nejsou uvedeny) 3. Potlačení všech křížků (obousměrné asociace nemají šipku, jednosměrné asociace šipku mají). Třetí případ se uvažuje jako rozumný kompromis, který se v praxi téměř výhradně používá. A B A B Průchozí od A do B Neprůchozí od B do A Průchozí od A do B Průchozí od B do A Něco málo o implementaci asociace Velmi zajímavou je problematika implementace asociace. Tato problematika se 1 Reflexivita je jednou z vlastností binárních relací. Zní následovně (vyloučíme prázdnou množinu): Buď A neprázdná množina prvků a relace na množině A, tj. A 2. Jestliže pro každý prvek aa platí aa, je binární reflexivní relací na množině A. -21-

199 vykládá na obou úrovních, tj. tříd a objektů. Existují techniky, kterými je možné implementovat asociaci, např. na základě tzv. pseudoatributu v cílové třídě, nebo zavedením asociační třídy. Tuto problematiku teď nebudeme rozvíjet Pojetí závislostí v UML 2.0 Je to problematika velmi důležitá a s jedním případem závislosti, tj. <<instantiate>> jsme se již setkali. UML vysvětluje závislost mezi dvěma prvky jako relaci, v níž se změna jednoho prvku (dodavatele) promítá i do druhého prvku (klienta). Obecně to znamená, že klient závisí na dodavateli. Tuto problematiku nebudeme teď zkoumat Dědičnost Je všeobecně uznáváno, že zapouzdření, dědění a polymorfismus jsou třemi význačnými pilíři objektového paradigmatu. Problematika zapouzdření je široce známá. Známo je rovněž, jaký vliv má zapouzdření na vyjádření dynamiky problémové domény. Teď se budeme zabývat dvěma zbývajícími pilíři a ukážeme si jejich vliv na modelování statiky a dynamiky problémové domény. Vraťme se teď k pojmu Zobecnění, který jsme využili při zobecňování aktérů v případech užití. Zobecnění bychom mohli považovat za součást filosofických disciplín, a je dobré znát jeho obecnou povahu. Jim Arlowe na str. 216 své knížky uvádí, cituji: Zobecnění je relací mezi obecnějším prvkem a prvkem přesněji definovaným, v níž přesněji definovaný prvek je zcela konzistentní s obecnějším prvkem, ale obsahuje více informací Není to rozporné, když řekneme, že Zobecnění umožňuje použít konkrétní prvek všude tam, kde je uveden prvek obecný. Zobecnění je silnější typ relace než asociace, pro kterou tato možnost neplatí. Pro zobecnění tříd budeme rovněž používat termínu generalizace a pro konkretizaci zase termínu specializace. Nádherným případem zobecnění je ikona Tvary (první úroveň) na kartě Vložení aplikace Word Ikona Tvary zobecňuje mnoho rovinných a prostorových obrazců, jak snadno zjistíte po jejím oživení (klepnutí myší). Sami zjistíte, že jde o pokles specializace přes dvě další úrovně. Druhou úrovní jsou Čáry, Základní tvary, Plné šipky, Vývojové diagramy, Popisky, Hvězdy a nápisy. Teprve potom je třetí úroveň zcela konkrétních obrazců. Např. pro skupinu Základní tvary (z druhé úrovně) jsou takovými obrazci Kruh, Obdélník, Kosoúhelník, Lichoběžník, Kosočtverec, a Zaoblený obdélník. Jestliže chápeme problematiku Tvary objektově, tak všechny názvy, tj. Tvary Zaoblený obdélník považujeme za třídy a instance konkrétních tříd vznikne pomocí jednoduché techniky (přenesení ikony obrazce konkrétní třídy do kreslícího okna). Tuto diskusi můžeme ilustrovat jednoduchým schématem hierarchie, v kterém není ještě zabudována relace dědění. Tvary čáry Základní tvary Plné šipky Vývojové diagramy Popisky Hvězdy a nápisy Obdélník čtverec Kosoúhelník Lichoběžník Obrázek 10-7: Neukončený klasický hierarchický diagram. -22-

200 S p e c i a l i z a c e V první a druhé úrovni jsou abstraktní třídy, v třetí úrovni jsou již třídy konkrétní - reálné. Konkretizace shora-dolů přináší možnost dědění jistých vlastností předchůdce následníkem. Toto pojetí, později upřesněné, můžeme chápat za specifickou relaci mezi třídami. Jestliže uspořádáme třídy do hierarchie, to hned evokuje na dědičnou vazbu mezi nimi. Nižší třída-potomek dědí od své nadtřídy: 1. Atributy. 2. Operace. 3. Relace. 4. Omezení. Tvar Ke zděděným charakteristikám (atributy, operace, relace a omezení) mohou potomci: přidat svou novou charakteristiku a rovněž předefinovat (překrýt) některé operace svých předchůdců. G e n e r a l i z a c e čáry Základní tvary Plné šipky Vývojové diagramy Popisky Obdélník Čtverec Kosoúhelník Lichoběžník Hvězdy a nápisy Obrázek 10-8: Hierarchický diagram tříd s dědičností Příklad 10-3 Následující diagramy ilustrují využití dědičnosti v několika fragmentech diagramů tříd. a) Zaměstnanec a různé typy zaměstnance. Zaměstnanec příjmení adresa rodnéčíslo praxe datumnástupu Kešír Číšník Kuchař dotázatse() vybírat() Přinést() nalít() upravitstůl() zavolat() připravitjídlo() uvařitjídlo() vařitnamístě() upravitrecept() -23-

201 b) Varianty platby v restauraci (prvotní náčrt) Platba Hotovost Kreditní karta Spropitné Platba na účet c) Prvky windows formuláře (prvotní náčrt) Prvek w-formuláře Tlačítko DataGrid Kalendář DataList Překrývání Problematiku se pokusíme vysvětlit na relevantních operacích kreslit( ) a vypočístobsah( ), pro třídy Tvar, Základní tvary a např. Obdélník a Kosoúhelník. Stručně o možnostech potomka: Potomek může k zděděným atributům přidat své vlastní. Potomek může ke zděděným operacím zavést své vlastní operace. Jestli chce potomek předefinovat-překrýt zděděnou operaci, musí ji napsat znovu se stejnou signaturou (název, typ návratové hodnoty, a typy všech stejně seřazených argumentů), ale s jiným vnitřkem (názvy argumentů nejsou součástí signatury). Z následujícího obrázku je patrno, že kreslení obrazce a výpočet obsahu jsou pro obdélník a kosoúhelník odlišné. Proto si obě třídy definují svou vlastní operaci stylem překrytí. V třídě Tvar vůbec nemůžeme operaci kreslit(g:graphics) napsat. Podobné je to rovněž v třídě ZákladníTvary. Můžeme ji ovšem napsat tzv. abstraktně a k tomu stačí zapsat její název kurzívou. Taková operace není implementována, protože třída, která ji obsahuje, není rovněž implementována. Třídy, u kterých je použita tato možnost, jsou abstraktní. Na druhé straně operace OhraničujícíObdélník() se dědí a nepřekrývá, protože veličiny výška a šířka k výpočtu ohraničujícího obdélníku dostačují. Důležité je, pamatovat si, že instance tříd Tvar a ZákladníTvary nemůžeme vytvářet, jsou totiž abstraktní. Kam tedy dát operace o kterých bylo mluveno? Ukázkou jak to provést pro obdélník a kosoúhelník je uvedeno v následujícím obrázku Polymorfismus Polymorfismus, to je mnohotvárnost. Jeho častým použitím je polymorfismus grafů. Případem polymorfismu jsou abstraktní operace kreslit a vypočístobsah, protože mají více podob. -24-

202 10.9 Možnosti zobecňování tříd Potomky a předky můžeme někdy uspořádat do námi zvolených zobecňujících množin. Jednou z možných variant je zobecnění v obr. 7, které spočívá v zobecnění všech obrazců do třídy ZákladníTvary a potom všech základních tvarů do třídy Tvar. Zajímavý fragment diagramu dostaneme, když si vzpomeneme na možnost aplikace Word 2007, tj. stanovit kreslící plátno pro skupinu obrazců. Tomu odpovídá následující diagram Účet čísloúčtu:string= ZákladníTvary zústatek:double kreslit(g:graphics) vlastník:string vypočístobsah:int OhraničujícíObdélník():int Tvar šířka:int výška:int počátek:point=(0,0).. * Obdélník kreslit(g:graphics) vypočístobsah:int. Kosoúhelník Čtverec počátek:point=(0,0) kreslit(g:graphics). vypočístobsah:int. 1 KreslícíPlátno Obrázek 10-9: Kombinace asociace a dědičnosti v jednoduchém diagramu tříd V dosud uvedeném textu jsme objasnili relaci asociace a relaci dědičnosti. V diagramu tříd se ovšem můžeme setkat s dalšími relacemi. Jsou to relace celeksoučást (agregace) a relace kompozice. Obě tyto relace se používají ve fázi NÁVRH, ale v následujícím souboru fáze ROZPRACOVÁNÍ relace agregace kompozice rozebereme samostatně podrobněji. Pochopitelně, poměrně dost diagramů tříd bychom mohli kreslit jen na materiálu asociace a dědičnosti. Přesto bez agregace a kompozice někdy nevystačíme. Příklad 10-4 Následující fragment tříd pro dodávkový systém zboží používá rovněž dědičnost (pokud by měl být fragment v UML, tak musí být zadány všechny oddíly) Odběratel Odběratel Firma DrobnýZákazník Dealer -25-

203 Příklad 10-5 Zkusme sestavit diagram analytických tříd pro softwarový případ užití Registrace. Pochopení příkladu usnadní kapitola 12, příklad Pro nás je důležitý hlavní scénář tohoto případu užití: Případ užití: Registrace ID: 3 Stručný popis: Systém umožní se zákazníkovi registrovat do softwarového systému a podává zprávu o stavu provedení případu Registrace Hlavní aktéři: Zákazník Vedlejší aktéři: Žádní Vstupní podmínky: Předpoklad: Zákazník je již v systému zaveden administrátorem (jen nacionále a číslo čip. karty). Byla provedena Autentizace klienta a zjištěno, že zákazník není registrován. Podmínka: Zadat číslo čipové karty. Hlavní scénář: 1. Případ užití je spuštěn z menu systému volbou Registrovat nebo z panelu ikon ikonou Registrovat. 2. Systém žádá zákazníka zadat svou identifikaci pomocí čísla čipové karty. 3. Po dvou omylech, systém ukončí případ užití a dá zákazníkovi oznámení, jinak se pokračuje bodem Oživí se registrační formulář pro zadání uživatelského jména a hesla. 5. Systém vytvoří záznam o registraci, včetně data a času. 6. Systém vytvoří uživatelský účet (uživatelské jméno, heslo). 7. Systém oznámí zákazníkovi, že registrace byla úspěšná. Poté se užívá jen přihlášení. Výstupní podmínky: žádné Alternativní scénáře: Zákazníkovi je nastaveno jeho pracovní prostředí, z kterého se může ze systému odhlásit. Po úspěšné Registraci je zákazník automaticky přihlášen do systému. Relace aktérů k případu užití: Aktér Zákazník případ Registrace spouští a musí systému zadat číslo své čipové karty. Čtením hlavního scénáře narazíme jen na významná podstatná jména Zákazník, Účet zákazníka a Záznam registrace, které by vhodnými atributy a operacemi mohly prezentovat funkcionalitu případu užití Registrace. Tak např., číslo čipové karty by mohlo být uvedeno v třídě Zákazník a udělá to administrátor systému po vydání čipové karty zákazníkovi. Účet zákazníka by ve formě Login a Password obsahovala třída Účet zákazníka a datumovou stránku by mohla obsahovat třída Záznam registrace. Zmíněné třídy bychom tedy mohly považovat za kandidáty analytických tříd. Diagram by mohl potom vypadat následovně. Zákazník Záznam registrace Účet zákazníka -26-

204 Shrnutí kapitoly: Kapitola se zabývá problematikou analytických tříd a jejich hledáním. Základem tohoto procesu je zkoumání diagramů případů užití a jejich detailní deskripce. Vedle toho se v kapitole uvádí možné způsoby hledání analytických tříd. Značná pozornost kapitoly je věnována dvěma základním relacím mezi třídami, tj. asociaci a dědičnosti. Asociace je vysvětlována od pojetí asociace mezi objekty a jejím zobecněním na třídy. Podává se rozbor různých vlastností asociace a její úplná deskripce. Nemalá pozornost se věnuje reflexivitě a asociaci typu 1:N. V závěru kapitoly je rozebrána dědičnost a jsou uvedeny příklady jejího využití. Σ Pojmy k zapamatování: Analytická třída, asociace tříd, reflexivní asociace, dědičnost, překrývání, polymorfismus Testy a otázky: 1. Vysvětlete pojetí analytické třídy. 2. Co vše je nutné zvažovat pro hledání analytických tříd? 3. S čím nejtěsněji souvisí analytická třída? 4. Vysvětlete pojetí asociace mezi třídami. 5. Vysvětlete pojetí dědičnosti mezi třídami. Úkoly k zamyšlení: Jak v objektovém programovacím jazyku naznačíme asociace mezi třídami a rovněž dědičnost? -27-

205 11 ROZPRACOVÁNÍ - diagramy stavů. Cíle: Znát (umět vysvětlit): 1. Pojetí stavu všech objektů dané třídy. 2. Pojetí komplexnosti stavu podle UML Základy kreslení stavových diagramů v UML. 4. Využití stavů objektů v případech užití. Dovednosti (umět prakticky): 1. Uplatnit znalosti pro praktické nacházení stavů objektů dané třídy. 2. Uplatnit znalosti pro asociování operací dané třídy se stavy všech generovaných instancí. Klíčová slova: Stav třídy, relevantní stavy, složený stav, událost, přechod 11.1 Úvod do problematiky stavů v UML 2.0 Velmi často se v případech užití a jejich realizaci (realizační diagramy tříd a jejich operace, sekvenční nebo komunikační diagramy) setkáváme s nutností znalosti a použití stavu, ve kterém se instance jedné z realizačních tříd nachází. Stačí uvést případ užití pro Stornování objednávky zboží v jisté dodavatelské firmě. Objednávka je jednou z realizačních tříd zmíněného případu užití. Stornování konkrétní Objednávky (instance třídy Objednávka) ale nemůže být provedeno ve všech obdobích jejího života (zřízení prázdné instance Objednávka, vyplnění Objednávky, odeslání Objednávky, rozpracovaná Objednávka, realizovaná Objednávka,, založení - archivování realizované Objednávky). Např. realizovanou Objednávku již lze jen reklamovat. Rovněž v případě, že je Objednávka již tak rozpracovaná, že je k ní vytvořen Dodací list a Faktura, která je zákazníkem již zaplacena, není možné stornovat Objednávku bez souhlasu prodejního manažera firmy. Vyplatí se tedy poznat v životě instancí jisté třídy její sémanticky výrazně odlišné situace, které nazveme stavy. Ačkoliv je toto první seznámení s pojmem stav nepřesné vágní, přesto naznačuje roli, kterou bude stav života instancí téže třídy hrát. Vyšetřeme teď pojem stav přesněji. Jazyk UML poznává tzv. reaktivní objekty, které reagují na vnější události. Za reaktivní objekty, které jsou chápány v širším smyslu, jsou považovány: Objektové třídy. Případy užití. Podsystémy a celé systémy. Povětšinou se soustředíme na objektové třídy, na jejich stavy, jimiž prochází všechny jejich instance. Z předchozí věty do jisté míry plyne, že budou existovat přechody mezi stavy, do kterých se dostane každá instance. Tyto přechody a stavy jako uzly, připomínají tzv. diagramy automatů. Proto se často v publikacích mluví nejen o diagramech stavů, ale rovněž o stavových automatech. Přesto bude poznatelný jeden z rozdílů mezi automaty a jejich stavy a např. objektovou třídou-reakčním objektem. Objektová třída bude mít obecně nekonečný počet stavů, což je pro implementaci -28-

206 nepřijatelné. Řešení tohoto problému je vysvětleno v dalším textu. Stavové diagramy, které budou obsahovat uzly-stavy a orientované šipky jako přechody, musí být ještě doplněny důvodem vzniku přechodu z aktuálního stavu do stavu následujícího. Tímto důvodem je externí událost, ke které v životě reaktivního objektu došlo. Pochopitelně, stavový diagram bude muset mít počáteční uzel a rovněž uzel koncový. Jak uvidíme později, jsou grafické reprezentace těchto uzlů podobné obdobným uzlům z tzv. aktivitních diagramů. Obecně platí to, že stavové diagramy modelují historii životního cyklu jednoho z reaktivních objektů prostřednictvím jeho možných stavů. Tři základní prvky stavových diagramů mají následující význam: Stav Událost Přechod je to podmínka, nebo situace vzniklá v životě reaktivního objektu mající silný sémantický charakter. Objekt v tomto stavu vykonává jistou aktivitu nebo čeká na určitou událost. Je to výskyt specifické situace v životě reaktivního objektu, na kterou musí tento objekt reagovat. Způsob reakce je pro reaktivní objekty specifický, ale vždy je spojen s přechodem do následujícího stavu. je posunem z aktuálního stavu do stavu následujícího v důsledku vyskytnuvší se události. Reaktivní objekty svým životem poskytují stavový kontext, který se dá prezentovat stavovým diagramem. Tedy, reagují na vnější události, přičemž jejich životní cyklus je modelován jako množina stavů, přechodů mezi nimi a událostí, které přechody vyvolají. Mají stavové chování, tj. jejich následující stavy vychází z předchozích stavů (stavové modelování chování). UML rozlišuje dva typy stavových diagramů: 1. Stavové diagramy chování. 2. Stavové diagramy protokolu. První se používají pro takové klasifikátory jako objektové třídy, kdy jde o skutečné modelování chování. Druhé se používají pro klasifikátory rozhraní a porty, které nemají chování a tak se modeluje jen protokol užití. Těmito diagramy se nebudeme podrobně v tomto textu zabývat Třídy a jejich primitivní stavy Instance-objekt se může nacházet v mnoha primitivních stavech. Takový stav objektu je obvykle definován: jeho n-ticí hodnot ( x 1, x 2,,x n ) atributů, spojeními (relacemi) na jiné objekty a aktuálně prováděnou operací. To vše můžeme formalizovat následovně. Buďte T a T dvě různé třídy, mezi nimiž je asociace T 1 1.,n T. Nechť jsou IT, I 1, I 2,, I k T instance. Posloupnost ( x 1, x 2,,x n ) považujme za hodnoty atributů objektu I. -29-

207 různé objekty ve stejném stavu Existuje-li množina spojení = { I I 1, I I 2,, I I k } objektu I na objekty I 1, I 2,, I k, k n, potom je primitivní stav objektu I vyjádřen ve tvaru I : [ ( x 1, x 2,,x n ),, ]. Primitivních stavů je obvykle nekonečné množství. Často je to důsledkem nekonečných doméndefiničních oborů jednotlivých atributů. Pro praktické využití je pojetí primitivního stavu nevhodné. Zavádí se tzv. relevantní stav, který pojmenovává specifickou podmnožinu nekonečné množiny primitivních stavů. Množinu relevantních stavů objektů dané třídy, která je konečná, budeme označovat písmenem K. Jeden relevantní stav může být nekonečnou množinou hodnotových n-tic { ( x 1, x 2,,x n ) }. Např. Faktury ve stavu zřízena mohou mít ve své hlavičce porůznu uvedeného adresáta. Všechny tři komponenty primitivního stavu jsou abstrahovány na úroveň třídy, proto všechny její instance-objekty projdou stejnými předem definovanými relevantními stavy. Tyto stavy tvoří životní cyklus objektu. Např. každý objekt Faktura může být v těchto význačných stavech tvořících jeho životní cyklus: zřízena, vyplněna, propočtena, zkontrolována, zaslána, přepravuje se, doručena, zaplacena, archivována Každému z těchto relevantních stavů v interpretaci na objekt potom odpovídá příslušná n- tice hodnot atributů a množina spojení daného objektu s jinými objekty. Dva různé objekty téže třídy se mohou nacházet v libovolném stavu životního cyklu. I když jsou dva objekty ve stejném stavu, jsou obvykle obě n-tice hodnot atributů rozdílné. Tedy, relevantní stav je nekonečnou množinou primitivních stavů. Např. v následujícím obrázku může být v relevantním stavu archivována nekonečné množství faktur. faktury archivovaná množina n-tic hodnot Obrázek 11-1: Třída FAKTURA může mít mnoho svých objektů ve stejném stavu. Dále budeme uvažovat jen relevantní stavy a oba přívlastky primitivní a relevantní již nebudeme používat. Objekt může přejít do jiného stavu na základě externí události, která je asociována s operací, tj. operací dané třídy. Přechod ze stavu do jiného stavu závisí od typu operace. Každá operace z množiny patří do jedné z tří významných podmnožin: 1. konstruktory k, jejichž provedení mění stav objektu, 2. selektory s, které zpřístupňují informace o objektu (hodnoty atributů) a nemění stav objektu, 3. predikáty p, které dávají možnost testovat informace o objektu (hodnoty atributů) -30-

208 Kvalita konstruktorů, selektorů a predikátů se dá vyjádřit pomocí zobrazení a kartézských součinů, kde X i,k, X i,s a X i,p jsou parametry k : K x X i,k K s : K x X i,s { ( x 1, x 2,, x n ) } p : K x X i,p { true, false } Relevantní stav je tedy sémanticky výrazná situace, v níž se objekt nachází. Je vlastně označením nekonečné množiny primitivních stavů. Sémantiky jednotlivých relevantních stavů jsou výrazně odlišné. Množina relevantních stavů je konečná Pojetí stavu a stavového diagramu v UML V UML se stav kreslí jako zaoblený obdélník, do kterého napíšeme jméno stavu. Nejvhodnějším tvarem pro jméno stavu je trpné přídavné jméno. Stav je chápán poněkud strukturovaně a jsou stanoveny tyto jeho části: entry/vstupní akce1, interní aktivita (do: aktivita) exit/výstupní akce2. Graficky to můžeme ilustrovat následujícím obrázkem. akce 1 se provede hned po vstupu do stavu, je nepřerušitelná Jméno stavu entry/akce1 do: aktivita exit/akce2 aktivita se provádí po dobu setrvání ve stavu a je přerušitelná akce 2 se provede před přechodem do nového stavu, je nepřerušitelná Zjednodušeně řečeno, je Stavový diagram množinou stavových uzlů a množinou přechodů mezi nimi. Ve stavovém diagramu se zavádí speciální počáteční a koncový stav. Pro jejich vizualizaci se používají černě vyplněný kruh a dva soustředné kruhy (terčík). Pro přechody mezi stavy se používají šipky. Rozeberme teď zbývající prvky stavového diagramu (události a přechody) Pojetí události Nejčastěji jsou přechody mezi stavy vyvolány vznikem událostí. Za událost chápeme něco významného, co se odehrálo s objektem v čase a prostoru za velmi krátkou dobu. Událost Stav 1 Stav 2 Stav Událost V prvním případě událost evokuje přechod do jiného stavu, v druhém případě se po události stav objektu nemění. Často se rozlišují čtyři typy událostí: 1. Událost volání, tj. požadavek provedení operace. 2. Signální událost. 3. Událost změny. 4. Časová událost. -31-

209 V dalším textu poznáme, že velmi často je událost (externí, interní) asociována s jistou operací, která se okamžitě provede a poté je evokován přechod do následujícího stavu, nebo se v aktuálním stavu setrvává. Je to patrno na vzorovém reálném případě změny barvy světla semaforu. Nastavení barvy na semaforu je událostí pro řidiče a chodce. Obojí reagují na tuto událost svým specifickým způsobem, provedou svou operaci (řidiči na zelenou rozjedou auta, chodci se na červenou zastaví a nevchází do jízdní dráhy) a změní tak svůj stav. Událost je tedy spouštěčem operace (trigger), jejímž provedením se může změnit stav. Události můžeme třídit na externí (vznikají za hranicemi systému, systém není zdrojem události) a interní (vznikají přímo uvnitř systému, systém je zdrojem události). Kvůli jednotnosti pohledu na události můžeme interní události převést na externí. Operace může být spuštěna jednou nebo více událostmi. Z realizace řetězce případ užití realizace případu užití, diagram tříd interakční diagramy víme, že si objekty předávají zprávy, které obsahují požadavek na provedení operace. Příchod zprávy je pro přijímací objekt událostí, operace se provede, a může změnit stav objektu. Běžným požadavkem informatiků je kreslit události, operace a přechody mezi stavy pro tentýž objekt v jednom diagramu. Diagramu, abstrahovanému na úroveň třídy, se obvykle říká Stavový diagram a jeho základním cílem je zachytit změny stavů objektů téže třídy. Tento diagram prezentuje pouze část dynamiky v zájmové oblasti. Nepostihuje totiž exekutivní komunikaci mezi objekty různých tříd založené na požadavcích, jimiž jedny objekty žádají jiné o provedení služby realizované jistou operací (diagram objektové interakce). Velké rozdíly v syntaxi a sémantice stavových diagramů u jednotlivých informatiků znesnadňovaly jednotnost podpůrných softwarových prostředků, proto byly uvítány jednotící myšlenky v UML 1.0 a později ve verzi 2.0. Tato verze již jednoznačně oddělila stavové diagramy od aktivitních diagramů. Popišme stručně sémantiku jednotlivých typů událostí, mimo signální, kterou se nebudeme zabývat Událost volání operace je požadavkem na provedení konkrétní operace třídy nad atributy její instance. Když instance přijímá tento požadavek, je to spouštěcí mechanismus (trigger) pro provedení operace uvedené v požadavku. V následujícím obrázku (není nakreslen v UML) je uveden fragment stavového diagramu pro třídu T. S 1, S 2 a S 3 jsou stavy diagramu. Operace O 1, O 2 třídy T jsou konstruktory a proto mění stav instancí. Naproti tomu operace O 3 stav instancí nemění (je to selektor, nebo predikát). S 1 S 3 oper. O 3 oper. O 1 S 2 oper. O 2 U 3 U 1 U2 Obrázek 11-2: Přechody mezi stavy na základě událostí volání. Sémantika obrázku je jednoduchá. Objekt je ve stavu S 1 a přichází událost U 1. Ta vyvolá provedení operace O 1, která změní stav na S 2, atd. Uveďme příklady několika typických událostí volání, s nimiž se pochopitelně asociují operace jisté třídy. Přijde čtenář, chce si půjčit knížku. Každý pátek v vytvořit přehled transakcí. Neočekávaně přijede kontrola. Objednaná práce je završena. Poklepání na volnou plochu dialogového okna. Volá zákazník a chce si objednat letenku. Přetažení obrazce dialogového okna na jiné místo. -32-

210 Příklad 11-1 Pokusme se v problémové doméně Knihovna modelovat stavy instancí-objektů třídy Výtisk. Je to třída s informacemi a operacemi pro konkrétní fyzické knihy. Nadřazenou třídou je třída Kniha-vzor. Kniha-vzor 1 Každá instance třídy Výtisk se nachází v osmi relevantních, výrazně sémanticky odlišných stavech (je to návrh): 0..* Výtisk Zakoupen Reklamován Je k dispozici Vyřazen Půjčen Vrácen Upomínán Ztracen. Poznámka: Je potřebné uvádět pro názvy stavů vhodné slovní tvary. Jelikož stav je jistá situace v životě objektu, je možné používat přídavná jména (nejčastěji trpná) nebo podstatná jména. Pokud možno, tyto tvary nemíchat s jinými slovními tvary. Vedle toho je nutné, aby měla třída Výtisk operace, které jsou konstruktory, měnící stav instance-objektu, tj. alespoň změnu jeho atributů. Nevyšetřujme teď dědičnost, zajímejme se jen o relevantní atributy a operace. Jejich návrh je prezentován následujícím obrázkem. Účet čísloúčtu:string= Výtisk zústatek:double vlastník:string číslovýtisku:integer stav:string knihavzorid:integer.. prijmi() zarad() vyrad() dejkdispozici() pujcse() reklamuj() vratse() zapisztratu() vystavupominku() zaplatnahrad() vyrad() Zjednodušený význam jednotlivých operací obsahuje následující tabulka. Operace prijmi() zarad() vyrad() dejkdispozici() pujcse() vratse() zapisztratu() vystavupominku() zaplatnahrad() reklamuj() zaplatvracej() Zjednodušená sémantika Atributy instance se naplní hodnotami, které identifikují jedinečnou instanci třídy Výtisk Vedle jiných atributů nastaví se rovněž atribut stav na hodnotu je k dispozici Výtisk je již opotřebován a operace nastaví atribut stav na hodnotu vyřazen Vedle jiných atributů nastaví se rovněž atribut stav na hodnotu je k dispozici Vedle jiných atributů nastaví se rovněž atribut stav na hodnotu půjčen Vedle jiných atributů nastaví se rovněž atribut stav na hodnotu vrácen Vedle jiných atributů nastaví se rovněž atribut stav na hodnotu ztracen Vedle jiných atributů nastaví se rovněž atribut stav na hodnotu upomínán Vedle jiných atributů nastaví se rovněž atribut stav na hodnotu ztracen Vedle jiných atributů nastaví se rovněž atribut stav na hodnotu reklamován Vedle jiných atributů (platba) nastaví se rovněž atribut stav na hodnotu vrácen Události a s nimi asociované operace třídy jsou v diagramu uvedeny ve tvaru zlomku (událost jako čitatel a asociovaná operace třídy jako jmenovatel). -33-

211 0 požadavek na reklamaci REKLAMUJ 0 Obrázek 11-1: Stavový diagram třídy Výtisk Časová událost je na přechodu vyznačena klíčovými slovy when nebo after, za kterými následuje časový výraz. Vzniklý výraz má následující význam. when... je časový údaj, kdy je časová událost právě aktivována after... je časový údaj, po kterém je hned časová událost aktivována. S časovou událostí se opět váže akce (např. operace třídy), která se po vzniku události provede Událost změny (podmínky) je realizována jako booleovský výraz (x i, x j,,x n ) nad vybranými atributy x i, x j,,x n instance dané třídy. S událostí změny je asociována akce A,, která se provede jen tenkrát, je-li hodnotou booleovského výrazu pravda, tj. když (x i, x j,,x n ) = true. Jestliže je objekt ve stavu S 1 k němuž náleží booleovský výraz (x i, x j,,x n ), musí být tento výraz neustále sledován po celou dobu setrvání objektu ve stavu S 1, aby splnění výrazu vedlo k provedení akce A, a poté k přechodu do stavu S 2. Příklad 11-1 Můj sporožirový účet Karel může jistě nabývat několik stavů. Např. je zřízen, solventní, nesolventní, utlumen. Solventní je ovšem vždy, když je na něm zůstatek větší než Kč. Z účtu Karel, pravidelně každý 5. den měsíce, platím 2000 Kč pomocí operace platba(2000) jistou službu firmě O 2. Potom v případě, že vklad klesne pod Kč, musím vyvolat provedení finanční transakce : přesun Kč z bohatě solventního účtu Pepa na účet Karel pro naplnění účtu. Operace platba(2000) je tedy asociována s booleovským výrazem : (je 5. den měsíce a zůstatek 2.000), který realizuje událost změny (podmínku). Jestliže je účet Karel zřízen, tak musel být vklad takový, aby byl zůstatek větší než Kč. Ve stavu Solventní se neustále hlídá hodnota výrazu. Je-li výraz pravdivý, provede se operace platba(2000), a ve stavu Solventní se zůstává. Je-li výraz nepravdivý, uskuteční se druhý přechod do stavu Nesolventní. Ve stavu Nesolventní se hlídá 8. den měsíce a nastaneli, tak se provede transakce. -34-

212 Situaci ilustruje následující fragment stavového diagramu. Zřízen Utlumen (3x neúspěšná, účet Karel se nedá naplnit) Solventní =true, platba(2000) (úspěšná ) =false Nesolventní Do: opakuj operaci max. 3x a pamatuj výsledek (proč?) Obrázek 11-2: Stavy účtu Karel. Operace a jsou operacemi kontextové třídy s instancí Karel. Ve stavu Nesolventní vznikají interní události (3x neúspěšná ) a (úspěšná ) Pojetí přechodu Základní interakce mezi dvěma stavy se kreslí ve tvaru, kde jsou stavy zaoblené obdélníky, a událost se píše na přechodovou hranu ve tvaru šipky. Každý přechod obsahuje tři nepovinné prvky: 1. Událost (externí / interní), která zahájí přechod z aktuálního stavu do stavu následujícího. 2. Podmínku, tj. booleovský výraz, který podmiňuje přechod. 3. Akci, která je přidružena k přechodu a provede se, když se přechod zahájí. Např. Stav 1 Událost Operace Stav 2 Sémantika je jednoduchá: Jestliže objekt ve Stavu 1 přijme Událost, potom přejde do Stavu 2. přepravuje se podmínka Zapiš do seznamu doručených faktur doručena Sémantika je jednoduchá: Jestliže objekt ve Stavu 1 a podmínka je splněna, to vyvolá přechod do Stavu 2. Nejsložitějším je přechod, ve kterém je událost,[ podmínka] a akce, která se provede, je-li podmínka pravdivá. Stav 1 Událost [Podmínka] / Akce Stav 2 Sémantika zní následovně: Objekt je ve Stavu 1. Při vzniku Události, je-li [Podmínka] pravdivá, provede se Akce a ihned je vstup do Stavu 2. Poznámka: 1. Pomocí složených stavů je možné do diagramu stavů zavést princip generalizace a specializace. -35-

213 2. Autoři UML používají další užitečné rozšíření stavu objektu. Zavedli možnost provádět akci ihned po vstupu do stavu (entry activity) a ihned před výstupem ze stavu (exit activity). Způsob přechodu do jiného stavu přes událost/operace (event/operation) zůstal nezměněn. 3. Stavový diagram je užitečný z několika důvodů: umožní pochopit chování objektu v časovém průběhu, definuje sekvence operací a stavů, přesně definuje závislost chování na stavu, pomůže odhalit chybějící nebo nadbytečné operace, umožní upřesnit informační strukturu objektu. 4. Podobnost stavového diagramu a orientovaného, ohodnoceného grafu je nápadná. Přechodová situace ( U, aktuální p, následující ) připomíná konečné automaty a pravidla práce s nimi. Rozhodně by se pro realizaci operací nad tímto diagramem dal použít automat, na jehož vstupu by byl řetězec podmínek a služeb. Tento automat by prohlásil, že k danému řetězci podmínek a služeb existuje / neexistuje cesta po jednotlivých stavech daného objektu v ŽC. Tím je naznačeno, že grafickou a verbální podobu ŽC objektů a tím i všechny myšlenky o stavech bychom mohli převést na poněkud preciznější vyjádření v aparátu grafů nebo automatů. 5. Pro práci se stavy je vhodné zavést u vybraných tříd atribut stav. Závěr V souvislosti se stavovými diagramy objektových tříd je potřebné myslet rovněž na širší souvislosti: 1. Každá třída T je spjata s jinými třídami, které spolu s ní realizují jistý případ užití a realizace je prezentována komunikačním nebo sekvenčním diagramem. Třída T má operace, které jsou použity v uvedených interakčních diagramech a mohou se vyskytnout rovněž v jejím stavovém diagramu. Důvodem je to, že příchod zprávy je pro instanci třídy T událostí. Operace se provedou a mohou se změnit hodnoty atributů. 2. Třída T může mít více stavových diagramů, ale musí být konzistentní. Je to dáno možností třídy T podílet se na realizaci více případů užití. Shrnutí kapitoly: Kapitola předkládá pohled na zavedení a využití stavů tříd, tj. rovněž instancí zmíněných tříd. Ukazuje se tzv. komplexnost stavu, tj. akce před vstupem do stavu a rovněž akce před výstupem ze stavu. Pozornost se rovněž věnuje akci, která se provádí d celé době, co je objekt v daném stavu. Pojetí stavu se doplňuje vysvětlením konstrukce stavových diagramů a mnoha způsoby ohodnocení přechodů mezi stavy. Σ Pojmy k zapamatování: Stav, relevantní stav, přechod, událost, podmínka, akce Testy a otázky: 1. Jak je teoreticky zaveden stav objektů dané třídy? 2. Jak jsou zavedeny relevantní stavy a proč jsou zavedeny? 3. Jaké jsou způsoby ohodnocení přechodů mezi stavy? Úkoly k zamyšlení: Jak lze úspěšně využívat hodnoty stavu v různých operacích dané třídy? -36-

214 12 ROZPRACOVÁNÍ interakční diagramy Cíle: Znát (umět vysvětlit): 1. Pojetí komunikačního diagramu pro realizaci případu užití. 2. Pojetí Sekvenčního diagramu pro realizaci případu užití. 3. Základy kreslení komunikačních diagramů v UML. 4. Základy kreslení sekvenčních diagramů v UML. Dovednosti (umět prakticky): 1. Uplatnit znalosti pro praktickou dokumentaci realizace případu užití v komunikačním diagramu. 2. Uplatnit znalosti pro praktickou dokumentaci realizace případu užití v sekvenčním diagramu. Klíčová slova: Objekt, zpráva, typy zpráv, komunikační diagram, sekvenční diagram 12.1 Úvod do interakčních diagramů V předchozích souborech jsme postupně diskutovali o třídách samotných, o jejich atributech a jejich operacích. Vycházeli jsme z diagramů případů užití. Chápali jsme ovšem, že dokážeme navrhnout jen analytické třídy a jejich relevantní atributy a operace. Vybrali jsme si případy užití, vytvořili z nich balíček a pro tento balíček začali hledat třídy, jejich atributy a operace. Vše jsme prováděli s pohledem do budoucna, tj. že pomocí atributů a operací dokážeme vyjádřit naprogramovat aktivitní podstatu případů užití. Není pochyb, že budeme muset později nějaké atributy přidávat a rovněž operace, protože stávající nebudou dostatečné. Analytické třídy ovšem jen zabezpečují statiku a dynamiku daného případu užití. Skutečné realizace případů užití jsou ilustrovány interakčními diagramy, které jsou vedle diagramů tříd druhým výstupním artefaktem objektové analýzy ve fázi ROZPRACOVÁNÍ. Uveďme opět obrázek ilustrující toto tvrzení. Model případů užití Objektová analýza Analytické třídy Realizace případů užití Interakční diagramy: Komunikační diagramy Sekvenční diagramy vstupní artefakt Obrázek 12-1: Artefakty objektové analýzy. Postup v předchozím obrázku aplikujeme na celé balíčky (jednotlivě po jeho případech užití) anebo na případy užití mimo balíčky jednotlivě. Tedy, hlavním úkolem tvorby realizace konkrétního případu užití je najít třídy, které se zabezpečují jeho realizaci. Na realizaci se zmíněné třídy podílí svými atributy, operacemi a instancemi. Jestliže se na instance tříd posílají zprávy s požadavky provedení operací nad atributy instancí, získá se představa interakce zúčastněných tříd ve formě jednoduchého diagramu. Tato interakce musí ovšem realizovat aktivitu, kterou zvolený případ užití představuje. Zjednodušeně řečeno: Na realizaci případu užití se podílejí takové třídy, které realizují - uskutečňují chování případu užití pomocí svých operací. To je vlastně vzájemná spolupráce tříd na základě vydávání zpráv. Toto vydávání zpráv musíme zakreslit ve formě interakčního diagramu. Jazyk UML zavádí dva interakční diagramy, komunikační diagram a sekvenční diagram. Oba dva diagramy jsou pro realizaci případů užití nejdůležitějšími diagramy. Právě -37- výstupní artefakty

215 interakční diagramy mají vyjadřovací schopnost znázornit, jak instance-objekty mezi sebou spolupracují. Pochopitelně, právě tvorba interakčních diagramů nám pomůže odhalit správnost volby atributů (nebo jejich nedostatek) a operací spolupracujících tříd. Klíčovými prvky komunikačního diagramu jsou komunikující instance tříd a zasílané zprávy. Klíčovými prvky sekvenčního diagramu jsou tzv. čáry života, instance účastnících se tříd a zasílané zprávy. Nechť Z 1, Z 2 a Z 3 jsou zasílané zprávy a její vstupní/výstupní parametry, které obsahují název operace, která bude přijímacím objektem provedena, :Zákazník, :Záznam registrace, Účet zákazníka jsou instance-objekty účastnících se tříd. Potom následující obrázky ilustrují rozdíly mezi oběma diagramy. Náčrt Komunikačního diagramu: Z 1 :Zákazník Příjemce a Odesílatel zprávy Z 2 Příjemce zprávy :Záznam registrace Z 3 :Účet zákazníka Příjemce zprávy Obrázek 12-2: Obecný komunikační diagram. V tomto náčrtu jsou použity instance tříd Zákazník, Záznam registrace a Účet zákazníka, které ovšem nemají ještě definované hodnoty všech atributů (až poté, co je budou mít, se vlastně stanou hodnotnými objekty). Náčrt Sekvenčního diagramu: :Zákazník Z 1 Z 2 :Záznam registrace :Účet Zákazníka Z 3 Obrázek 12-3: Obecný náčrt sekvenčního diagramu. Čára života UML používá několik různých šipek pro označení typu zprávy: Symbolika Název zprávy Význam Z(parametr) Z(parametr) <<create>> Z(parametr) A Synchronní zpráva Návrat zprávy Asynchronní zpráva Tvorba instance-objektu Odesílatel čeká na dokončení úkolu příjemcem zprávy Informace, kterou předává příjemce odesílateli Odesílatel odešle zprávu a nečeká, až příjemce dokončí úkol Odesílatel zřídí instanci příjemce -38-

216 <<destroy>> Z(parametr) Uvolnění instance-objektu Odesílatel ukončí život příjemce Poznámka: 1. V analytickém pojetí komunikace objektů nejsou rozdíly mezi synchronní a asynchronní zprávami důležité. Používejte proto jen synchronní. 2. Návratové zprávy rovněž nejsou důležité, nemusíme je kreslit Komunikační diagramy Tyto diagramy prezentují strukturální charakter interakce objektů. Jsou výhodné pro analytické náčrty spolupráce objektů, bez ohledu na čas posílání zpráv. Jestli chceme tento nedostatek odstranit, stačí, když zprávy očíslujeme pořadovými čísly. Toto číslování ale není v UML 2.0 povoleno. Legální je používání desetinného značení zpráv (1, 1.1, 1.1.1, ). Větvení v diagramech zařídíme pomocí podmínek, o které zprávy doplníme. Příklad 12-1 Úkolem příkladu je realizovat případ užití Registrace pomocí interakčních diagramů. Je potřebné si uvědomit několik zásad, podle kterých softwarové systémy pracují s klienty. Klient musí být systémem autentizován, je-li hostem, nebo reálným zákazníkem (registrovaným/neregistrovaným) a autorizován kvůli přidělení práv, povinností a kompetence. Všem neregistrovaným zákazníkům systém nabídne registraci. Neregistrovaným je každý zákazník firmy, který je pouze zaveden do systému administrátorem. Pokud zákazník odmítne nabídku a měl by zůstat neregistrován, je systémem považován za hosta (převede se jeho vztah k systému). Níže je uvedena jedna z jednoduchých možností Autentizace (docela zajímavá) a její souvislosti s Registrací a Přihlášením. AUTENTIZACE KLIENTA (pro firmu BODY CARE): Každý zákazník firmy BODY CARE, zabývající se expedicí balíčků kosmetických přípravků, je vybaven čipovou kartou, na které je uloženo a vytištěno identifikační číslo, společné pro zákazníka a čipovou kartu zákazníka (číslo čipové karty je získáno generátorem náhodných čísel), jméno zákazníka a datum konce platnosti. Datum zavedení karty je sděleno zákazníkovi. Všichni zákazníci firmy mají čipovou kartu a jsou uloženi v bázi dat, ale nemusí být v softwarovém systému registrováni. Systém ovšem vyžaduje, aby byli v systému registrováni všichni zákazníci (kvůli postupnému zavedení elektronického řízení prodeje). Softwarový systém je přístupný přes jistou internetovou adresu. Jakýkoliv klient tuto adresu může použít a systém musí rozlišit zákazníka firmy (registrovaného/neregistrovaného) od hosta (autentizace). Na úvodní stránce systému je dotaz, bude-li klient hrát roli hosta, nebo zákazníka. Pro roli zákazníka se musí zadat číslo čipové karty. Systém zjistí, že čipová karta neexistuje. Tohoto klienta může systém považovat za hosta a nabídne mu hostitelské prostředí, anebo s takovým klientem ukončí komunikaci. Jestliže karta je v systému zavedena, potom systém provede následující proceduru s pokusem o identifikaci skutečného majitele čipové karty: 1. Zeptá se klienta na datum vydání karty (na kartě je jen konec její platnosti, datum vydání tam není). Je-li datum uveden správně, tak se pokračuje na bodu 2. Není-li klientem uveden správný datum, tak se komunikace s klientem ukončuje. 2. Klient se považuje za vlastníka čipové karty a tedy skutečného zákazníka firmy. Systém zjistí, jestli je provedena registrace vlastníka karty. Není-li, tak zákazníkovi nabídne možnost registrace. Je-li registrace již provedena, tak systém nabídne zákazníkovi možnost přihlášení. Tím analýza klienta končí. konec autentizace 3. Další postup systému závisí od toho, jestli zákazník použil ikonu registrace nebo přihlášení (může použít jen jednu možnost). Dále je uvedena vize práce systému pro Registraci/Přihlášení. -39-

217 PŘIHLÁŠENÍ: Systém vyhledá zákazníka (podle čipové karty) a žádá zadání login a password. Systém prověří správnost uživatelského jména (login) a hesla (password). Je-li obojí správné, je vysoce pravděpodobném že jde o reálného zákazníka firmy a je pro něj nastaveno jeho pracovní prostředí. Nechce-li zákazník se systémem dále pracovat, může se odhlásit. Není-li obojí správné, systém umožní opakování. Je-li opět chyba, tak systém ukončí komunikaci se zákazníkem, protože má podezření o nereálném zákazníkovi. konec Přihlášení REGISTRACE: Systém vyhledá zákazníka podle čipové karty a dá mu možnost stanovit si login a password. Zapíše údaje o registraci do báze dat a připíše ještě datum a čas registrace. Rovněž se vytvoří účet zákazníka. Tím se zákazník stává zaregistrovaným a je mu nastaveno jeho pracovní prostředí (je automaticky přihlášen do systému). Nechce-li zákazník se systémem dále pracovat, může se odhlásit. konec Registrace 4. Chce-li zákazník ukončit práci se systémem, musí se odhlásit. Ikona odhlášení je v jeho pracovním prostředí. Poznámka: Zaměstnanci, ani zákazníci firmy BODY CARE nepracují s dokumenty, které musí být chráněny. Není proto nutné řešit tzv. autorizaci (práva, povinnosti a kompetence). Z uvedeného plyne, že existuje několik případů užití, které komplexně zabezpečují vztah zákazníka se softwarovým systémem: Autentizace, Autorizace, Registrace, Přihlášení, Změna hesla, Změna uživatelského jména a Odhlášení. Poté, co se klient přihlásí na Domovskou stránku softwarového systému, je okamžitě autentizován. Zde se budeme orientovat jen na Registraci. Proveďme tedy realizaci případu užití Registrace. Jde vlastně o realizaci případu užití s následujícím diagramem a specifikační tabulkou detailů. Zákazník Registrace Případ užití: Registrace ID: -- Stručný popis: Systém umožní se zákazníkovi registrovat do softwarového systému a podává zprávu o stavu provedení případu Registrace Hlavní aktéři: Zákazník Vedlejší aktéři: Žádní Vstupní podmínky: Předpoklad: Zákazník je již v systému zaveden administrátorem. Byla provedena Autentizace klienta a zjištěno, že zákazník není registrován. -40-

218 Podmínka: Zadat číslo čipové karty (nebo využít čtečku). Hlavní scénář: 8. Případ užití je spuštěn z menu systému volbou Registrovat nebo z panelu ikon ikonou Registrovat. 9. Systém žádá zákazníka zadat svou identifikaci pomocí čísla čipové karty. 10. Po dvou omylech, systém ukončí případ užití a dá zákazníkovi oznámení, jinak se pokračuje bodem Oživí se registrační formulář pro zadání uživatelského jména a hesla. 12. Systém vytvoří záznam o registraci, včetně data a času. 13. Systém vytvoří uživatelský účet (uživatelské jméno, heslo). 14. Systém oznámí zákazníkovi, že registrace byla úspěšná. Výstupní podmínky: žádné Alternativní scénáře: Zákazníkovi je nastaveno jeho pracovní prostředí, z kterého se může ze systému odhlásit. Po úspěšné Registraci je zákazník automaticky přihlášen do systému. Relace aktérů k případu užití: Aktér Zákazník případ Registrace spouští a musí systému zadat číslo své čipové karty. Podílnickými třídami, které realizují chování případu užití Registrace, jsou: Zákazník, Záznam registrace a třída Účet zákazníka. Třída Zákazník musí vyhledat svou instanci zákazníka, který se chce registrovat. To třída provede operací vyhledej(). Třída Záznam registrace potom vytvoří, pomocí operace registrovatse(), novou instanci, která si pamatuje, koho se registrace týká a kdy bylo o ni požádáno. Třída Účet klienta vytvoří pomocí operace zapišúčet() instanci, která bude obsahovat konkrétní znění účtu, tj. uživatelské jméno (login) a heslo (password). Účastnické třídy budou mít následující atributy a operace. Zákazník čísločipovékarty jméno adresa datumzavedení hledej() Záznam registrace IDregistrace čísločipovékarty datumčas registrovatse() Účet zákazníka IDúčetZákazníka čísločipovékarty login password zapišúčet() Administrátor čísločipovékarty jméno adresa datumzavedení zavéstzákazníka() Popis operací: Na této úrovni analýzy vybraného případu užití, se obvykle netvoří popis operací tříd. Stačí jen jejich podstata. Pro začátečníky je ovšem tento popis užitečný, a proto je uváděn. zavéstzákazníka()... Operace je použita pro zavedení zákazníka pomocí jeho čipové karty do systému. Ta spočívá ve vytvoření instance třídy Zákazník a nastavení jeho identifikačního čísla jako čísla čipové karty. Nastaví se ještě datum a čas zavedení zákazníka do systému. Zákazník se nemůže do systému zavést sám, provede to administrátor systému. hledej()... Operace vyhledá zákazníka, který se chce registrovat. Parametrem operace je číslo čipové karty. registrovatse()... Předpokládá se, že zákazník je v systému již zaveden. Operace vytvoří novou instanci třídy Záznam registrace, stanoví hodnotu IDregistrace a nastaví hodnoty pro atributy datumčas a čísločipovékarty. zapišúčet()... Operace vytvoří novou instanci třídy Účet zákazníka, stanoví hodnotu IDúčetZákazníka. Potom nastaví hodnoty pro atributy osobníčíslo, login a password. Ve formuláři, který tato operace oživí, zadá zákazník login a password. -41-

219 Mezi uvedenými třídami jsou relace zapsané ve dvou variantách. Obecně můžeme říci, že vybraná varianta má vliv na podstatu výše zmíněných operací jednotlivých tříd. V dalším postupu použijeme levou variantu, která v bázi dat vede na asociací svázané třídy. Zákazník Účet zákazníka Zákazník Účet zákazníka 1 Záznam registrace 1 Záznam registrace Obrázek 12-4: Varianty pro diagram tříd realizace případu užití Registrace. Následuje Komunikační diagram, který ilustruje realizaci chování případu užití Registrace pomocí chování tříd Zákazník, Záznam registrace a Účet zákazníka prostřednictvím zasílání zpráv. Hodnoty 325, 18 a 12 jsou stanoveny v operacích tříd. Aktér zákazník hledej(325) registrovatse(18) 18:Záznam registrace 325:Zákazník zapišúčet(12) 12:Účet zákazníka Obrázek 12-5: Komunikační diagram pro třídy realizace případu užití Registrace. Detaily tohoto komunikačního diagramu nám sice říkají, že vyhledaný zákazník s osobním číslem 325 bude mít vytvořenou instanci o své registraci s ID 18 a instanci vlastního účtu s ID 12, ale stejné chování s jinými identifikacemi instancí platí pro všechny zákazníky, kteří se chtějí registrovat. Proto bychom nemuseli instance identifikovat a do operací dávat identifikační hodnoty Sekvenční diagramy: Interakce mezi instancemi-objekty jsou dány šipkami mezi čárami života a v podstatě jde o uspořádanou posloupnost událostí. Jako událost je chápán příchod zprávy na přijímací objekt. Čas života instancí-objektů probíhá shora dolů. Aktér-zákazník hledej(325) 325:Zákazník registrujse(18) zapišúčet(12) 18:Záznam registrace 12:Účet Zákazníka Všímejte si strategie pro vydávání zpráv. Může být i jiná strategie? Obrázek 12-6: Sekvenční diagram pro realizace případu užití Registrace. -42-

220 V sekvenčním diagramu postupujeme v čtení sémantiky aktivity případu užití vodorovně, kdežto život instancí-objektů je čten shora-dolů po čárách života. Start případu užití zákazník navodí např. zmáčknutím ikony registrace v dočasném pracovním prostředí pro Zákazníka, který ještě není registrován. Dočasné pracovní prostředí zaregistrovaného zákazníka nabídne přihlášení. Zřízení instancí tříd Záznam registrace, Účet zákazníka se provede v operacích jako první. Operace jednotlivých tříd a posloupnost jejich posílání ve zprávách dává jednoznačnou sémantiku sekvenčního diagramu. Do sekvenčního diagramu nekreslíme všechny kroky z aktivity případu užití, ale jen ty relevantní. Vše se dořeší až v návrhu. Oba dva diagramy můžeme doplnit poznámkami, ale to může vést k narušení transparentnosti diagramu. To, kdy nastane okamžik vydání zprávy, můžeme ilustrovat vertikálním obdélníčkem. Obdélníky se často nazývají aktivacemi (activation). Jsou časté případy při použití nástrojů CASE, že je vlevo od sekvenčního diagramu uveden hlavní scénář a tak je možné sémantiku případu užití číst přímo Závěr 1. Každá realizace případu užití zachycuje jen jeden vybraný případ užití. 2. Za komponenty realizace případu užití považujeme: a. Dílčí diagram tříd, které se podílí na realizaci případu užití svými atributy, operacemi a vazbami. b. Komunikační, nebo Sekvenční diagram. 3. Realizace případu užití si může vyžádat provedení změn v realizačních třídách, resp. v případu užití samotném. 4. Sekvenční diagramy jsou výhodné tehdy, jestliže chceme zdůraznit roli času na posílání zpráv. Komunikační diagramy jsou výhodné, jestliže chceme zdůraznit strukturální stránku a spojení - provázanost instancí - objektů realizace případu užití. Poznámka: V souboru Část IV. 6 Scénář fáze ROZPRACOVÁNÍ uvedeme příklad k doméně Evidence soukromých zbraní v ČR, který zahrnuje především realizaci vybraného případu užití Převedení zbraně na jiného vlastníka, diagram analytických tříd a sekvenční diagram. Nakonec je vybrána třída Zbraň, jejíž instance prochází konečnou množinou stavů a nakreslen stavový diagram a sepsány operace pro přechody mezi stavy. Shrnutí kapitoly: Kapitola předkládá pohled na zavedení reprezentace realizace případů užití tzv. interakční diagramy. Popisuje se nejdříve zpráva a typy zpráv, protože je základem spolupráce objektů instancí různých tříd. Vzniklé komunikační a sekvenční diagramy se déle rozebírají do potřebné hloubky. Σ Pojmy k zapamatování: Objekt, zpráva, komunikační diagram, sekvenční diagram Testy a otázky: 1. Proč potřebujeme interakční diagramy? 2. Jaké prvky se v komunikačních a sekvenčních diagramech používají? 3. Jaké jsou typy zpráv a jak to hodnotí UML? -43-

221 Úkoly k zamyšlení: Jaké strategie vydávání zpráv je pro sekvenční diagram možno uplatnit? -44-

222 13 ROZPRACOVÁNÍ pracovní postup Návrh Cíle: Znát (umět vysvětlit): 1. Pojetí návrhového modelu. 2. Pojetí vztahu analytického konceptuálního modelu a návrhového modelu ve vztahu k případu užití. Dovednosti (umět prakticky): 1. Uplatnit získané znalosti pro praktickou tvorbu návrhového modelu realizace případu užití. Klíčová slova: Konceptuální analytický model, pracovní postup Návrh, návrhový model 13.1 Obecně o pracovním postupu Návrh. Na rozdíl od pracovního postupu Analýza, který je prováděn na začátku fáze ROZPRACOVÁNÍ, je pracovní postup Návrh prováděn na jejím konci a v první polovině další fáze KONSTRUKCE. Analýza připravila logický - analytický - konceptuální model problémové domény jako analytické balíčky tříd a realizaci případů užití (interakční diagramy). Pracovní postup Návrh převádí konceptuální model do návrhové podoby, která je již vhodná pro implementaci. VSTUPY Pracovní postup Návrh VÝSTUPY Analytický konceptuální model Návrhový model Obrázek 13-1: Vstupy a výstupy pracovního postupu Návrh. Použijeme-li místo termínu návrhový model termín návrhový systém, který by měl vzniknout, potom je důležité uvažovat o jeho podsystémech z počátku tvorby logické architektury, protože vznik systémového nedělitelného monolitu odporuje naší strategii modelování. Protože podsystém je v tvorbě logické architektury později chápán jako speciální komponenta, jsou potom tyto podsystémy jako vzájemně komunikující komponenty, a proto budeme muset věnovat pozornost rovněž jejich interfejsům rozhraním pro možnosti jejich vzájemného propojení. Tato rozhraní vlastně spojují získaný systém dohromady. Komponenty a jejich rozhraní jsou základními prvky tzv. komponentových systémů. Zmíněné komponenty mají tedy velkou architektonickou roli. O rozhraní budeme mluvit později. Pro pracovní postup Návrh je směrodatný následující metamodel, který ilustruje členění komponentového systému na komponenty C 1 až C 3. Komponenta C 3 je vnořená. -45-

223 Component C 1 C 1 Návrhový model Component C 2 C 3 Návrhové třídy Návrhová realizace případů užití Obrázek 13-2: Metamodel pro konstrukci Návrhového modelu. Značka má jednoduchý význam. Horní oblouk je akceptant rozhraní (požaduje jisté rozhraní), dolní kolečko je dodavatel rozhraní (nabízí jisté rozhraní). Tedy podsystém C 2 dodává poskytuje, C 1 přebírá akceptuje. V komponentové architektuře a potom v komponentovém vývoji zastupuje bývalý podsystém z logické architektury nejčastěji jednu komponentu. Návrhový model se tedy skládá z návrhových komponent, a v nich návrhových tříd, návrhových realizací případů užití, rozhraní mezi komponentami. Návrhový model fyzický je ještě doplněn tzv. diagramy nasazení. O diagramech nasazení budeme mluvit později. Tyto diagramy ukazují, jak bude softwarový systém rozmístěn (zřejmě po komponentách) v jednotlivých uzlech informační infrastruktury, ale teď je předčasné o nich podrobněji mluvit, protože jsou záležitostí pracovního postupu Nasazení. Přechod od analytického modelu k modelu návrhovému je spojen s relací <<trace>>, což je indikace cesty přechodu. Závislost obou zmíněných modelů potom zakreslíme následovně Návrhový model << trace >> Analytický, konceptuální model Obrázek 13-3: Návrhový a analytický model spojené relací <<trace>>. Přechod od analytického modelu k návrhovému není problematický. Jde o rozpracování analytického modelu následujícím způsobem: jestliže analytická třída měla jen klíčové atributy, potom návrhová třída musí mít datové specifikace všech atributů, jestliže analytická třída měla jen klíčové operace, tak návrhová třída musí mít specifikace všech operací, včetně jejich vstupních a výstupních parametrů, navrhneme komponenty a jejich rozhraní, navrhneme předběžný diagram nasazení. -46-

224 Pochopitelně, zavedení podsystémů komponent je evokováno požadavkem jednoduššího vývoje rozsáhlého softwarového systému. Jinými slovy podsystémy komponenty potom můžeme vyvíjet nezávisle na sobě. Obecně můžeme mít tři pohledy na vznik původních podsystémů z tvorby logické architektury: 1. Podsystémy vychází z problémové domény a kopírují její členění na podsystémy. V tomto případě je prvotní přístup k architektuře chápán tak, že již samotné požadavky určují, do kterého podsystému patří. To se přenáší rovněž na případy užití a z nich vzniklé realizační třídy a interakční diagramy. Tímto přístupem mohou ovšem vzniknout rozsáhlé podsystémy a vysoká netransparentnost. 2. Na vznik podsystémů se díváme pohledem cílového softwarového systému. Jeho členění na podsystémy již nevychází z charakteristiky problémové domény, ale ze softwarové domény. Jinými slovy, je zdrojem pohledu analytický balíček, s možností jeho členění do více podsystémů. Tím se zvyšuje jak transparentnost, tak i jednoduchost implementace vzniklých podsystémů. 3. Často se také využívá již známé architektury adekvátního softwarového systému. Zkušenosti se potom přenáší na právě rozpracovaný softwarový systém. Problematiku komponent a jejich interpretaci (modul, podsystém, ) uvedeme v dalším souboru Relace <<trace>> Stereotyp <<trace>>, který určuje závislost prvků návrhového modelu na prvcích analytického modelu, umožňuje řešit jejich vzájemné mapování mnoha způsoby. Např.: Je možné jeden analytický balíček rozložit na více subbalíčků. Z analytické třídy může vzniknout více návrhových tříd. Převedením realizace případu užití vzniká jeho jedna návrhová podoba. Všechny tyto možnosti jsou definovány formální sémantikou mapování podle následujících schémat. 0..* Analytický balíček 0..* 0..* <<trace>> Návrhový Subbalíček C 1 Návrhové třídy Realizace případů užití návrh Realizace případu užití z analytického balíčku 1 <<trace>> 1 Realizace případu užití návrh -47-

225 1 <<trace>> 1 Analytická třída 0..* Návrhové třídy 1 <<trace>> 0..* Rozhraní Obrázek 13-4: Řešení vzájemných vztahů mezi prvky analytického a návrhového modelu. Poznámka: 1. Analytická třída může být rozložena do několika rozhraní nebo návrhových tříd. 2. Diagram Realizace případu užití je v návrhové podobě jen o něco podrobnější než analytický. 3. Doporučuje se udržovat dva synchronizované, tedy i konzistentní, modely: konceptuální - analytický a návrhový Návrhové třídy V pracovním postupu Návrh se provádí aktivity Architektonický návrh, získat návrhovou třídu a získat návrhovou podobu realizace případu užití. Architektonický návrh ještě nevyřešil produkci výsledných výstupních artefaktů, jako návrhové třídy (úplné), rozhraní (úplné), komponenty (úplné), model nasazení (úplný). Začneme teď s aktivitou krokem Získat Návrhovou třídu a ukážeme jak vytvořit návrhovou třídu úplnou. Návrhová třída je v metodikách URP a UP charakterizována jako třída, která je natolik podrobná, že může sloužit jako základ pro tvorbu zdrojového kódu. Do pracovního kroku Získat Návrhovou třídu vstupují Realizace případu užití návrh, návrhová třída (načrtnutá), Rozhraní (načrtnuté). Značí to, že musíme specifikovat všechny atributy a všechny operace. Je-li získaná návrhová třída velmi bohatá, potom je možné ji rozdělit rozbít na dvě a více návrhových tříd. Často se mluví o tom, že výsledná návrhová třída by měla být úplná, jednoduchá, vysoce soudržná a bez těsných vazeb. Uvedené vlastnosti jsou vysvětleny v následující poznámce: Úplnost atributů a operací je dána zásahem třídy v realizaci případu užití. Operace a atributy by se neměly sémanticky překrývat. Každý atribut, každá operace a každá asociace třídy by měly být navrženy tak, aby implementovaly malou, ale jasně zaměřenou množinu odpovědností. Každá třída by měla být přidružena pouze k takovým třídám, aby to zcela jasně vedlo k tomu, za co je odpovědná. Velmi často se v publikacích ještě rozebírá problematika vazeb návrhové třídy a vyhlašují se metodické poznatky k dědičnosti, agregaci a kompozici. Mnohé z těchto poznatků berou ohled na vývojový systém zdrojového kódu a zdrojový jazyk. Nebudeme je zde rozebírat. Přesto v dalším souboru provedeme rozbor a upřesňování analytických relací, což je pro návrhovou třídu významné. Neustále mějme na paměti, že pracovní postup Návrh je na konci fáze ROZPRACOVÁNÍ a v první polovině fáze KONSTRUKCE. S některými výstupními artefakty jako Rozhraní a -48-

226 Model nasazení se setkáme později. Shrnutí kapitoly: Kapitola je stručným popisem vzniku návrhového modelu případu užití z jeho analytického konceptuálního modelu. Kapitola k tomu podává popis příslušné transformace. Σ Pojmy k zapamatování: Analytická třída, analytický model, návrhová třída, návrhový model Testy a otázky: 1. Proč potřebujeme návrhový model realizace případu užití? 2. Jaký je postup převodu analytického modelu na model návrhový? 3. Jaké jsou výsledné požadavky na návrhovou třídu? Úkoly k zamyšlení: K čemu lze úspěšně využít návrhového modelu? -49-

227 14 ROZPRACOVÁNÍ Návrh, relace agregace a kompozice Cíle: Znát (umět vysvětlit): 1. Pojetí podstaty relací agregace a kompozice v pracovním postupu Návrh. 2. Pojetí úprav asociací pomocí agregace a kompozice. Dovednosti (umět prakticky): 1. Uplatnit získané znalosti pro praktické použití relací agregace a kompozice v Návrhu. 2. Uplatnit získané znalosti pro praktické úpravy asociací typu 1:N, M:N a obousměrných asociací pomocí agregace a kompozice. Klíčová slova: pracovní postup Návrh, agregace, kompozice, oboustranná asociace 14.1 Úvod Dále uvedené úpravy diagramu analytických tříd se provádí na konci fáze ROZPRACOVÁNÍ, přesněji v pracovním postupu Návrh. Jejich účelem je zjemnění-refining (upřesnit, vyjádřit, nahradit) obecné asociace mezi třídami pomocí agregace a kompozice a získat tak tzv. návrhové relace. V sestaveném diagramu analytických tříd se mohly objevit některé složité asociace mezi třídami, např. asociace typu M:N, dále některé implementační problémy (asociačních tříd, asociací 1:N, oboustranných asociací). Takto uvedené asociace se nedají implementovat (např. nemáme objektový programovací jazyk, který by podporoval asociace typu M:N nebo obousměrné asociace). Metodika UP požaduje úpravu analytických tříd do jejich návrhové podoby, která je stanovena tak, aby měly všechny návrhové asociace průchodnost a kardinalitu na obou koncích vazby. Právě návrhová podoba asociací je dále rozebírána v textu tohoto souboru Něco o agregaci a kompozici V době návrhu se mohou některé asociace upravit do podoby tzv. agregace-nahromadění, seskupení (aggregation - volná nebo slabá vazba mezi objekty) nebo do další podoby, která je silnější podobou agregace, tj. kompozice-sestavení (composition). Kompozice vytváří kompaktní kompozit, kdežto agregace je jen volné seskupení. Rozdíly v obou relacích jsou tedy značné, zejména v sémantice Agregace Např. do agregace-seskupení, tj. volné-slabé vazby mezi objekty, můžeme seskupit třídu počítače a třídy všech k němu připojených periferií. Přídavná zařízení, která jsou seskupena u daného počítače, je možno sdílet jinými počítači a dokonce je můžete odpojovat a připojovat k jinému počítači. Některá z přídavných zařízení jsou tak vyspělá, že dokážou pracovat zcela samostatně (např. tiskárna umožní tisk některých typů paměťových karet bez připojení k počítači). Agregaci vybraných přídavných zařízení do agregační třídy Počítač ilustruje následující obrázek. Počítač Celek Tiskárn a Reproduktory Externí disk Scanner -50- Součásti

228 Počítač * Přídavné zařízení Tiskárna Scanner Externí disk Reproduktory Obrázek 14-1: Agregace pro třídu Počítač a její zobecnění. První ani druhou část obrázku 14-1 nemůžeme ovšem považovat za skutečně reálný model počítače. Proč asi? Agregace tedy umožní jednotlivým třídám Tiskárna, Scanner, žít samostatně, ale rovněž v agregaci s celkem Počítač. Objekt-celek ovšem využívá služeb objektů-součástí, tj. Tiskárny, Scanneru,. Celek je v relaci agregace dominantní, řídí chod relace, zatímco součást je vcelku pasivní, poskytuje pouze služby a reaguje na požadavky celku. Průchodnost agregace ze strany celku vede k tomu, že součást téměř ani neví, že je součástí celku. Jim Arlowe ve své knize charakterizuje agregaci těmito slovy (str. 361), cituji: Sémantiku agregace můžeme shrnout takto: Celek (agregace) občas existuje nezávisle na součástech, jindy je na nich závislý. Součásti mohou existovat nezávisle na celku. Chybí-li určité součásti, je celek v jistém smyslu neúplný. Součást může být sdílena více celky. Ačkoliv jsme o vlastnostech agregace jako relace již mluvili, přesto opět uvádíme, že agregace je: Reflexivní, tj. je možné A A, ale na obou stranách musí být odlišná instance třídy A. Asymetrická, tj. objekt nemůže být přímo, či nepřímo součástí sám sebe. Tranzitivní, tj. platí: jestliže je B agregováno do A, C agregováno do B, pak je rovněž C agregováno do A. To lze zapsat ve tvaru: A B C A C. Reflexivitu můžeme chápat za reálnou vlastnost. Je zde ovšem jedna podmínka ohledu na to, že agregace je rovněž asymetrická. Následující reflexivitu potom vysvětlujeme tak, že na obou stranách nemůže být stejný objekt třídy Součástka. * Součástka * * Tranzitivita agregace je přímo triviální a nepotřebuje další rozvádění. Pro začátečníky máme ovšem radu: nedoporučuje se používat reflexivních agregací. Rozklad je ovšem jednoduchý a je nakreslen v následujících obrázcích až do druhé úrovně. Rozklad používá instance a:součástka, b:součástka c:součástka a d:součástka. Agregace zde ovšem může pokračovat do hlubší úrovně. Následující diagram respektuje vlastnosti agregace. Zajímavé ovšem je, -51-

229 jak v tomto diagramu předznačit, že objekt d:součástka se chce obracet na dekompoziční objekt a:součástka? a:součástka a:součástka b:součástka c:součástka Nes -mí být b:součástka c:součástka Zde mohou být cykly Zde nesmí být cykly d:součástka d:součástka Obrázek 14-2: Agregace pro reflexivní asociaci s třídou Součástka Kompozice Je to opět relace celek/část, ale vztah celek-část je podstatně silnější než u agregace. Vlastnosti kompozice jako relace jsou stejné s agregací, ale v kompozici nemohou části existovat mimo celek. Vytváří se tedy pevný kompozit. Dále, v kompozici patří každá součást jen k jednomu celku. Tedy je vyloučené sdílení součásti více celky. V praxi je docela dost typických příkladů. Často jsou to případy celku s částmi, ale části jsou od celku neoddělitelné. Např. v oblasti počítačových zařízení: obyčejná klávesnice se svými skupinami tlačítek, obyčejná počítačová myš a její ovládací prvky tlačítka a kolečka, přehrávač CD a jeho tlačítka,.. Z přírody a předmětů kolem nás, můžeme uvést tyto příklady: strom a jeho listy, člověk a části jeho těla, radiátor a jeho ovládací kolečko, Z oblasti podnikových dokumentů, můžeme uvést tyto příklady: Objednávky, Dodací listy, Faktury, Příjemky, Výdejky, a jejich řádky Smysl uvedených příkladů je ilustrován na třídě Faktura. K dané instanci Faktury (ID F = 321) náleží jako součást skupina řádků (každý řádek skupiny má identifikaci složenou z dvou atributů: ID F =321 a Č.řádku), což je jistá instance třídy Řádky faktury. Faktura 1 0..* Řádky faktury Všechny tyto případy celku-kompozitu se vyznačují tím, že zničíme-li instanci celkukompozitu, tak zničíme rovněž instance jeho částí. Konkrétní tlačítka myšky, listy stromu, části lidského těla, řádky faktury, existují jen v jednom objektu typu Myš, Strom, Člověk a Faktura. -52-

230 Sémantika kompozice je potom jasná: 1. Instance součásti patří jen a jen jedné instanci celku (kompozitu). 2. Celek má výhradní odpovědnost za vznik a zničení svých částí. 3. Výjimečně, přejde-li odpovědnost za součásti na jiný objekt, může celek součásti uvolnit. 4. Dojde-li ke zničení instance celku, tak celek musí zničit instance svých součástí, nebo přenést odpovědnost za ně na jiný objekt. Tato silná vazba mezi celkem a jeho součástmi je hlavním rozdílem mezi agregací a kompozicí. Existuje ovšem i další rozdíl: Reflexivní agregace mohou vytvářet jak hierarchie, tak i sítě. Ovšem reflexivní kompozice může vytvářet jen hierarchie objektů. Průchodnost kompozice se kreslí ve směru od celku k součásti. Strom 1 0..* List stromu 14.3 Stručně o některých upřesněních analytických relací pomocí agregace a kompozice V modelování analytických tříd je nutné se soustředit jen na tzv. business analytické třídy a nezavádět do modelu tříd např. softwarové třídy a třídy programovacích jazyků (utility Classes). V pracovním postupu Návrh je nutné převést asociace do návrhové podoby pomocí agregací a kompozic. V odborné literatuře se k UP metodice nejdříve uvádí rady pro upřesnění analytických relací: 1. V analytických třídách uvést relevantní atributy a operace. 2. K asociacím přidat násobnosti kardinality a role (neměl by se potom psát název asociace). Teď jde o možnost převedení asociací na agregace nebo na kompozice. Je to zjemnění, upřesnění, nebo nahrazení asociací. 3. Upřesnit, které asociace převedeme na agregace a které na kompozice a co bude celek a co součást. Obecně platí: a. Násobnost na straně celku je buď 1, nebo b. Je-li to 1, pak se může použít kompozice. c. Jinak se musí použít agregace. 4. Nezapomeňte přidat průchodnost od celku k části (návrhové asociace musí být jednosměrné). Tím jsme model tříd převedli na tvar, v němž již nejsou asociace, ale jen návrhové agregace a kompozice. Potom je jednodušší implementace takového modelu v objektových programovacích jazycích. Jsou ovšem případy, kdy musí zůstat i pro návrhovou podobu diagramu tříd původní asociace (vyhnutí se použití reflexivní agregace). -53-

231 Uveďme teď další pravidla s ohledem na násobnost: 5. Asociace typu 1:1 se převádí na kompozici. Vazba je silná jedno-jedno objektově, jako např. v případě k jedné instanci třídy Objednávka náleží jen jedna instance třídy Faktura. Někdy je sémantika vazby taková, že často lze obě třídy sloučit. Jestli to nejde, pak je výsledek převodu následovný: Analýza Objednávka 1 1 Dodací list <<trace>> Návrh Objednávka 1 1 Dodací list 6. Asociace typu N:1, v níž vlastně je násobnost na straně celku větší než 1, a to vylučuje použití kompozice. Je ovšem možno použít agregace, ale nesmí v ní existovat cyklické závislosti. Často uváděným příkladem je asociace peněz a jejich měny. Analýza Peníze * 1 Měna <<trace>> Návrh Peníze * 1 Měna 1 Nechť třída Peníze představuje hromádky peněz v jistých měnách. Potom je sémantika následující: Jedna instance třídy Měna je sdílena mnoha instancemi třídy Peníze. Jedna hromádka peněz je jen v jedné měně. Kolekce vzniká opět na straně součásti. K jedné instanci třídy Měna přiřazena kolekce instancí Peníze. <<trace>> 7. Asociace typu 1:N představují na straně součásti nativní kolekci instancí (vysvětleno dále). Tato kolekce se dá zpracovávat možnostmi objektového programovacího jazyka. Převod asociace 1:N je ilustrován následujícím příkladem. Analýza Faktura 1 <<trace>> * Řádek faktury Návrh Faktura 1 0..* Řádek faktury V tomto schématu je k jedné instanci třídy Faktura přiřazena kolekce řádků, instancí třídy Řádek faktury. Existuje ovšem ještě další možnost. Analytickou asociaci typu 1:N můžeme implementovat tzv. třídou kolekcí. Pochopitelně, zvládnutí práce s třídami kolekcí je základem dobré práce v objektovém programu. Je dobré, když se respektuje zásada, která k tomu přispívá, tj. že třídy kolekcí musí obsahovat metody pro: a. přidávání objektů do kolekce, b. odstraňování objektů z kolekce, -54-

232 c. získání odkazu na objekt v kolekci d. procházení kolekcí objektů (od začátku do konce). Následující obrázek ilustruje implementaci asociace typu 1:N pomocí třídy kolekcí s názvem InvCol (Invoice Collection). Analýza Faktura 1 * Řádek faktury analýza 0..* Návrh Faktura 1 1 <<trace>> InvCol 1 * Řádek faktury * Třída kolekcí Obrázek 14-3: Asociace 1:N pomocí třídy InvCol. To se dá zakreslit redukcí Faktura 1 {InvCol} * 1 Řádek faktury Tato explicitní implementace třídou InvCok je sice výhodná na zpracování, ovšem zavádí třídy, které nepříliš souvisí s business problematikou problémové domény. Návrhový model tříd se tak může stát značně netransparentním. Existuje mnoho typických/netypických složení kolekcí. Každé složení vyžaduje svůj způsob zpracování v objektovém programovacím jazyku. Práci s kolekcemi nebudeme dále diskutovat, jsou záležitostí objektového programovacího jazyka. V obou metodikách RUP/UP se doporučuje nezabývat se problematikou třídy kolekcí a ponechat převod 1:N na samotné programátory. Nebudeme tedy diskutovat setřídění kolekce a jedinečnost kolekce. Podrobnosti se dají najít v knize Jima Arlowa, str Další a skvělou možností z různých typů kolekcí je tzv. mapa. Třída tohoto typu má specifické vlastnosti umožňující velmi rychlé zpracování kolekce. Drobné podrobnosti najdete ve zmíněné knížce, str V odborné literatuře se uvádí rovněž jiné možnosti rozkladu asociace typu 1:N. Např. Analýza Faktura 1 * Řádek faktury 0..* <<trace>> Návrh Faktura * A Řádek faktury Obrázek 14-4: Jiný rozklad asociace typu 1:N. Rozklad je proveden pomocí třídy A, která je pouhou součástí celku. Je použita kompozice, protože A nemůže mimo třídy Faktura existovat. Volněji může být realizovaná asociace mezi třídami A a Řádek faktury. Zvolíme-li přístup, že třída A je zodpovědná za tvorbu a vymazání součástí, pak použijeme kompozici, jinak agregaci (v předchozím obrázku je použita kompozice). -55-

233 14.4 Práce s asociacemi, které nejsou podporovány běžně používanými objektovými programovacími jazyky Jsou to asociace, o kterých jsme zatím nemluvili, a je žádoucí, aby byly v diagramu tříd odstraněny, chceme-li realizaci provést objektovým programovacím jazykem. Konkretizovat se musí následující analytické relace: 1. Asociace typu M:N 2. Obousměrné asociace. 3. Asociační třídy Asociace typu M:N Nejsou zpracovatelné žádným objektovým programovacím jazykem. Zajímavé ovšem je, že na rozdíl od relačních databázových systémů, některé objektové databázové systémy je zpracovávají přímo. Jelikož je případů těchto asociací z prostředí problémových domén dostatek a objektové programovací jazyky nám nepomohou, je návrhové zjemnění žádoucí. Např. takovými asociacemi jsou: Lékař Pacient, Zaměstnanec Podnikový úkol, Podnik Osoba, Sklad Zboží, Vědecký pracovník vědecký úkol, Asociaci M:N lze rozložit a poté zjemnit do návrhové podoby. Ukažme tento proces na třídách Lékař a Pacient s následující sémantikou, která neplatí v ČR: Praktický lékař může léčit libovolné pacienty, pacient může být léčen libovolným praktickým lékařem Lékař * * Pacient <<trace>> Lékař 1 * Návštěva * 1 Pacient Lékař <<trace>> 1 * Návštěva * 1 Pacient Obrázek 14-5: Rozklad asociace Lékař-Pacient. Další příklad je založen na sémantice vztahu Skladu a Zboží. Ve skladě je uskladněno různé zboží. Totéž zboží může být uskladněno v různých skladech Pokusme se ukázat vícero nápadů pro zjemnění pomocí třídy Zásoba. A. Za celky jsou zvoleny Sklad a Zásoba. a. Ke každé instanci Skladu vznikne na straně součásti Zásoba kolekce příslušných instancí Zásoby. b. Ke každé instanci Zásoba, vznikne na straně součásti Zboží kolekce Zboží -56-

234 Sklad * * Zboží <<trace>> Sklad 1 * Zásoba * 1 Zboží Sklad <<trace>> 1 * Zásoba * 1 Zboží Obrázek 14-6: Sklad ví, jaké má zásoby a Zásoba ví, jakého zboží se týká. B. Můžeme za celky zvolit Sklad a Zboží. Potom je poslední zjemnění tvaru Sklad 1 * * 1 Zásoba Zboží Sklad ví, jaké má zásoby a rovněž to ví i Zboží. Sklad není silně spojen se Zásobou. Zboží je silně spojeno se Zásobou. Zruší-li se nějaké zboží, tak se ruší i jeho zásoba. Jaké kolekce se vytváří a kde je spojení zboží se skladem přes zásobu? Která z verzí A, B je logicky správná a která ne? Nebo jsou obě správné? Je ještě jiná možnost? Obousměrné asociace Je to asociace uvedená např. obecně mezi třídami s násobností 1:N. Žádný ze současných objektových programovacích jazyků zpracování obousměrných asociací nepodporuje. Takovou asociaci musíme převést na dvě jednosměrné nebo do závislostí podle následujícího náčrtu. Výdejka 1 * Řádky výdejky Původní asociace Výdejka 1 1 * * Řádky výdejky Upravená asociace Obrázek 14-7: Převedení obousměrné asociace na dvě jednosměrné. Jednoduše řečeno: Výdejka je celek, se silnou vazbou na součást Řádky výdejky. Součást Řádky výdejky rovněž ví do které instance celku je zařazena. Shrnutí kapitoly: Kapitola je obšírným popisem řešení uplatnění relací agregace a kompozice. K těmto relacím se vysvětlují jejich vlastnosti, odlišnosti a specifika využití. Vedle toho se v kapitole uvádí principy upřesnění některých asociací jak, z důvodu implementace do objektových Σ -57-

235 programovacích jazyků, tak i z obecného pohledu. Pojmy k zapamatování: Návrh, agregace, kompozice, asociace, oboustranná asociace Testy a otázky: 1. Jaký je rozdíl mezi agregací a kompozicí? 2. Proč upravujeme asociace typu M:N? 3. Jaké jsou důvody úprav asociací pro objektové programovací jazyky? Úkoly k zamyšlení: K čemu lze úspěšně využít relace kompozice? -58-

236 15 ROZPRACOVÁNÍ komponenty a jejich rozhraní Cíle: Znát (umět vysvětlit): 1. Pojetí architektonického modelu založeného na komponentách. 2. Pojetí vlastností komponent (vztahy, chování, rozhraní). Dovednosti (umět prakticky): 1. Uplatnit získané znalosti pro praktický návrh architektury založené na komponentách. Klíčová slova: Architektura software, komponenta, vztahy, chování a rozhraní komponent, architektonický návrh, 15.1 Obecně o architektuře založené na komponentách Architektura softwarového systému je definována v IEEE , IEEE Recommended Practice for Architectural Description of Software Intensive Systems následovně: Architektura je základní organizace systému, dána jeho komponentami, vzájemnými vztahy těchto komponent a jejich vztahy k okolnímu prostředí a principy řídícími jejich návrh a evoluci. Je možné uvést celou řadu dalších definic architektury, ovšem pojem komponenta v nich není přesně definován, podobně jako v námi uvedené definici. Je to z důvodu možné, volné interpretace např. prostřednictvím podsystému nebo modulu. Firma Microsoft považuje za komponentu rozsáhlého software modul a stanovuje pravidla pro vztahy modulů, chování modulů a rozhraní pro komunikaci mezi moduly. Modul je tvořen tzv. windows formulářem a kódem s ním asociovaným. Modul je realizován jako třída, takže je možné vytvářet jeho instance, které zapouzdřují svůj obsah. Skutečné pojetí komponenty je definováno až v UML 2.2/2009 v následujícím znění: Komponenta představuje modulární část systému, jež zapouzdřuje svůj obsah, a v rámci daného prostředí jsou její projevy nahraditelné. Komponenta definuje své chování v podobě poskytovaných a požadovaných rozhraní. Jako taková slouží komponenta jako typ, jehož konformita je definována právě těmito poskytovanými a vyžadovanými rozhraními (zahrnujícími jak jejich statickou, tak i dynamickou sémantiku). Jedna komponenta tedy může být nahrazena druhou pouze tehdy, pokud obě jsou typově konformní. Tato definice komponenty je používána v obou metodikách RUP a UP. Z uvedeného plyne, že architektura se zabývá především strukturou systému a jeho chováním prostřednictvím komponent. Za prvky architektury jsou považovány: komponenty, vztahy komponent, chování komponent, rozhraní komponent. Že architektura definuje chování je zřejmé z následujícího obrázku. Tento obrázek podává chování systému v komponentách pro vytvoření Zakázky, v podobě známého sekvenčního diagramu. -59-

237 :Prodejce :Zadání zakázky :Správa zákazníků :Správa účtů Vytvoření zakázky Načtení dat zákazníka Vytvoření zakázky Cyklus 1..* Přidání položky zakázky Dokončení zakázky Obrázek 15-1: Komponenty a jejich spolupráce (zdroj [EelCrip011], upraveno). V obrázku je ilustrováno pět interakcí, které jsou hrubě realizovány pomocí zpráv mezi komponentami a návraty Více o komponentách Komponenta zastupuje modulární část systému a chová se v podstatě jako černá skříňka s interním a vnějším chováním. Vnitřní chování je v podstatě funkcionalita komponenty. Vnější chování je dáno zpřístupněnými a požadovanými rozhraními. Pojetí rozhraní uvedeme v dalším textu. Komponenty mohou zastupovat obecnou logickou konceptuální konstrukci, např. podsystém nebo modul v architektuře software. Pro komponenty lze sestrojit komponentový model, který zahrnuje zejména závislosti mezi nimi. Komponenta se kreslí následujícím schématem, v kterém je její označení B, zpřístupněné rozhraní a požadované rozhraní. Schéma ale neobsahuje vnitřní chování komponenty. <<component>> B I 1 I 2 V pravém horním rohu je symbol komponenty a nad jménem je stereotyp <<component>>. Komponenta může mít rovněž vnitřní strukturu. Jestli ji opravdu má, potom je její odpovědnost, definovaná pomocí svých rozhraní, delegována na některé vnitřní součásti. <<component>> B <<delegate>> I 1 I 2 I 2 Obrázek 15-2: Schéma jedné z komponent s vnitřními součástmi. Většinou jsou komponenty na sobě závislé a komunikující mezi sebou. Vzájemná komunikace mezi komponentami A, B probíhá na základě jejich rozhraní. Není vyloučeno, -60-

238 že komponenta může mít více rozhraní. <<component>> B <<component>> A I 1 I 3 I 3 <<component>> C I 2 Obrázek 15-3: Komponenty a jejich spolupráce. Komponenta B závisí od komponenty A. Komponenta A zpřístupňuje dvě rozhraní I 1 a I 2 a požaduje rozhraní I 3. Komponenta C rozhraní I 3 zpřístupňuje, takže A, C mohou navzájem komunikovat. Komponenta se může uvést velmi abstraktně, např. komponenta A ve tvaru <<component>> A <<providedinterface>> I 1, I 2 <<artifacts>> 15.3 Více o podsystémech Podsystémy a moduly jsou komponenty. Vznikly při rozkladu rozsáhlého systému, kreslí se jako komponenty se stereotypy <<subsystem>>, <<module>>. Platí pro ně problematika rozhraní jako pro komponenty. Ze systémového hlediska považujeme problémové domény za systémy/moduly, které můžeme dělit na spolupracující podsystémy/moduly. Nejčastěji se ovšem používají termíny systém a podsystém. Z hlediska metodik RUP a UP, je podsystém základní stavební prvek pro rozsáhlé problémové domény. S použitím podsystémů a rozhraní mezi nimi vzniká tzv. systémová architektura. Co je ovšem považováno za podsystém problémové domény, je diskutabilní. U podniku to mohou např. být: 1. prvky organizačního schématu, 2. známé procesní sety ERP, SCM, CRM,, 3. velké skupiny procesů, např. týkající se skladů, personalistiky, prodeje, 4. velké skupiny procesů týkající se základních podnikových entit, např. Objednávka, Zákazník, Produkt, Příklad 15-1 Následující schéma představuje systémovou architekturu dvouvrstvého cílového software pro komputerizaci zpracování procesů týkajících se entit Odběratel (drobný zákazník, dealer, firma), Objednávka, Expediční balíček firmy BODY-CARE, která podle Objednávek dodává expediční balíčky kosmetických přípravků. -61-

239 <<subsystem>> GUI Management Objednávek Management Zákazníků Management Expediční listů Management Faktur <<subsystem>> Business logic Obrázek 15-4: Systémová architektura dvouvrstvého cílového software. Toto schéma sice odděluje vrstvu Graphical User Interface od vrstvy business (aplikační), ovšem nic nevypovídá o vztazích mezi Managementem Objednávek,, Managementem Faktur. Jestli chceme tyto vztahy považovat za velmi pružné a bohatší, musíme navrhnout jinou systémovou architekturu, např. následující. <<subsystem>> GUI <<subsystem>> Zákazník <<subsystem>> Objednávka <<subsystem>> Expediční list <<subsystem>> Faktura Obrázek 15-5: Systémová architektura dvouvrstvého cílového software s vazbami mezi podsystémy. Tato systémová architektura stanovuje vazby mezi podsystémy a GUI vrstvu napojuje jen na podsystém objednávka. Důvodem je dominance Objednávky a pouhé její kopírování do Faktury a Expedičního listu Rozhraní a jeho hledání. Co je rozhraní? Rozhraní budeme spojovat s třídami, později s komponentami (s možností interpretace pomocí podsystémů nebo modulů), pomocí kterých tvoříme systémovou architekturu. Rozhraní třídy předepisuje pojmenovanou množinu veřejných služeb pomocí operací třídy a jejich atributů. Některé obecné užitečné funkce, které rozhraní poskytuje, jsou uvedeny v následující tabulce. Rozhraní není schopno generovat instance. -62-

240 Rozhraní předepisuje 1. Operaci dané třídy 2. Atribut dané třídy 3. Označenou hodnotu 4. Protokol - směs Rozhraní jsou vyžadovaná a zpřístupněná. Zpřístupněná se nabízí, kreslí se jako kroužky, kdežto vyžadovaná musí být dodržena a zobrazují se pomocí značky. Teď již jistě víme, že rozhraní jsou rovněž základem vývoje komponentového software. Rozhraní mezi podsystémy můžeme hledat zcela metodicky. Předpokládejme, že máme obecné systémové schéma, kde jsou podsystémy spojeny asociacemi (obyčejné čáry). Vyšetřeme všechny asociace a uvažujme, jestli by neměla být asociace velmi pružná, více komunikační. Jestliže ano, tak zaveďme místo asociace rozhraní. Teď, když již toho hodně víme o komponentách, měli bychom si zopakovat, jak se k nim dostaneme a jak vytvoříme model komponent pro architekturu cílového software Obecně o pracovní aktivitě Architektonický návrh. O architektuře cílového software mluvíme již ve fázi ZAHÁJENÍ. Jde o to, že jsou-li již známé požadavky a jejich mapování do případů užití, můžeme zahájit předběžné úvahy o povaze architektury cílového software. Můžeme tedy zvážit, do kolika podsystémů umístíme případy užití a můžeme sestavit předběžnou úvahu a nakreslit obecné schéma. Tuto problematiku by měl řešit systémový architekt, který bude dále velmi podrobně sledovat realizaci případů užití a navrhovat rozbití dříve naznačených podsystémů na dílčí, jednodušší podsystémy. V rámci Pracovního postupu Návrh fáze ROZPRACOVÁNÍ je uvedena pracovní aktivita Architektonický návrh. Tato aktivita je základem pro vypracování logického návrhu architektury a rovněž jeho fyzické podoby tzv. spustitelného architektonického základu. Na aktivitě Architektonický návrh se vedle systémového architekta podílí dále inženýr případů užití a později rovněž inženýr komponent. Ve fázi ROZPRACOVÁNÍ v pracovním postupu Návrh dochází k transformaci - přeměně analytického koncepčního modelu na model návrhový a obecný pohled na jeho složení v podsystémech je dán následujícím obrázkem. Subsystém C 1 Návrhový model C 1 Subsystém C 2 C 3 Návrhové třídy Návrhová realizace případů užití Obrázek 15-6: Složení Návrhového modelu. -63-

241 Návrhový model se tedy skládá z návrhových podsystémů, návrhových tříd, návrhových realizací případů užití, rozhraní mezi podsystémy a nakonec z diagramů nasazení. O diagramu nasazení budeme mluvit až ve fázi ZAVEDENÍ. Pochopitelně, zavedení podsystémů je evokováno požadavkem jednoduššího vývoje rozsáhlého softwarového systému. Jinými slovy podsystémy potom můžeme vyvíjet nezávisle na sobě. Podsystémy žijí v rámci cílového softwarového systému prostřednictvím svých rozhraní, jak je to naznačeno v předchozím obrázku mezi podsystémy C 1 a C 2. Obecně můžeme mít tři pohledy na vznik podsystémů cílového systému: 1. Podsystémy vychází z problémové domény a kopírují její členění na podsystémy. V tomto případě je prvotní přístup k architektuře chápán tak, že již samotné požadavky určují, do kterého podsystému patří. To se přenáší rovněž na případy užití a z nich vzniklé realizační třídy a interakční diagramy. Tímto přístupem mohou ovšem vzniknout rozsáhlé podsystémy a vysoká netransparentnost a je nutné podsystémy rozbíjet. 2. Na vznik podsystémů se díváme pohledem cílového softwarového systému. Jeho členění na podsystémy již nevychází z charakteristiky problémové domény, ale ze softwarové domény. Jinými slovy, je zdrojem pohledu analytický balíček, s možností jeho členění do více podsystémů. Tím se zvyšuje jak transparentnost, tak i jednoduchost implementace vzniklých podsystémů. 3. Na vznik podsystémů se díváme prostřednictvím jiného, již propracovaného cílového software a jeho model architektury. Tento model se snažíme v hrubých rysech implementovat na náš cílový softwarový systém. Právě druhý pohled je dán následujícím obrázkem. Analytický balíček 0..* 0..* <<trace>> Návrhový Subsystém C 0..* Návrhové třídy Realizace případů užití návrh Obrázek 15-7: Relace <<trace>> pro analytický balíček a návrhový podsystém Architektonický návrh V předchozím souboru jsme uvedli základní poznatky týkající se pracovního postupu Návrh obecně. Pochopitelně, již z těchto poznatků vycházelo najevo, že návrh architektury, tj. aktivita Architektonický návrh, která vede na tzv. návrhovou architekturu, je v tomto postupu na prvním místě. Touto aktivitou se v pracovním postupu Návrh začíná. Následující obrázek ilustruje všechny vstupní a výstupní artefakty Architektonického návrhu. -64-

242 VSTUPY Architektonický návrh VÝSTUPY Model případu užití Podsystém (načrtnutý) Rozhraní (načrtnuté) Model požadavků Návrhová třída (načrtnutá) Analytický model Model nasazení (načrtnutý) Popis architektury Popis architektury (vylepšený) Obrázek 15-8: Složení Architektonického návrhu. Shrnutí kapitoly: Kapitola je stručným popisem architektury založené na komponentách. Komponenty jsou diskutovány s ohledem na jejich vztahy, chování a rozhraní. Na konci kapitoly je vysvětleno pojetí architektonického návrhu. Σ Pojmy k zapamatování: Komponenta, model architektury, architektonický návrh Testy a otázky: 1. Jaká je nejnovější definice komponenty? 2. Co je architektura založená na komponentách? 3. Co se myslí pod vztahy, chováním a rozhraními komponent? 4. Co je architektonický návrh? Úkoly k zamyšlení: V Části II. Architektura software jsme hovořili o tzv. Logické architektuře software. Jak souvisí Logická architektura s Architektonickým návrhem? -65-

243 PŘÍKLAD 16 ROZPRACOVÁNÍ příklad Evidence soukromých zbraní v ČR V této kapitole rozpracujeme z fáze ZAHÁJENÍ jen pracovní postup Požadavky a z fáze ROZPRACOVÁNÍ jen tvorbu analytických tříd a Sekvenčního diagramu pro vybraný případ užití Obecně o problémové doméně Správa soukromých zbraní v ČR. Následující komplexní příklad se týká domény Správa soukromých zbraní v ČR (SSZ v ČR). Ukážeme nejdříve její vymyšlený obecný popis. Proto se popis přísně nedrží současně platného zákona o soukromých zbraních v ČR. SSZ v ČR sama o sobě není IS české policie, ale spíše jeho součástí. Sama o sobě je víceméně samostatná a v bázi IS policie má vydělitelnou část. V této doméně jsou rozhodující informace o majiteli zbrojního průkazu (MZP), o samotných zbrojních průkazech (ZP), o zbraních a průkazech zbraní (PZ). Modifikace a vytváření informace o MZP, ZP, zbrani a PZ náleží jen administrátorovi daného okresu, tj. podle trvalého bydliště MZP. Je-li zbraň zakoupena, musí být podle zákona do jisté doby zavedena do používání. Prodejce vydává ke zbrani výsledek její výrobní kontroly (osvědčení o správné funkcionalitě, nástřelný terč, vše s podpisy státem delegovaných kontrolorů). Zbraň je potom zavedena do systému policejním administrátorem v daném okrese, tj. vytvoří se informace o jejím zavedení a asociaci s MZP. Je-li to zákonem stanoveno, zbraň musí být kontrolována a výsledek zapsán do báze dat. V další části popisu SSZ v ČR jsou uvedeny její některé charakteristiky, týkající se zejména známých procesů a dat.: MZP 1. Každý majitel Zbrojního průkazu je v bázi cílového software evidován, tedy vede se o něm následující informace: MZP = (ID majitele ZP, jméno a příjmení, rodné číslo, fotografie, trvalé bydliště, ID žádosti, ID lékařského vysvědčení, ID vysvědčení o zkoušce). Žádný jiný občan ČR, než ten který má zavedený zbrojní průkaz, není v bázi cílového software evidován. S MZP souvisí Žádost formulář (ŽF) o vydání nového ZP, Lékařské vysvědčení (LV) o způsobilosti používat a vlastnit zbraň dané kategorie, Vysvědčení o zkoušce (VZ) ze znalosti a manipulaci se zbraní dané kategorie/-í a aktuální fotografii (viz dále ZP). ZP 2. Zbrojní průkaz (ZP) je samostatná datová entita se strukturou ZP = (eviden. číslo, platnost do, ID majitele ZP, kategorie zbraní: A F, kdo vydal). Atributy jméno a příjmení, rodné číslo, fotografie a trvalé bydliště, které jsou na kartičce zbrojního průkazu vytištěny, jsou přebírány od MZP. 3. Nový ZP se tiskne speciálním strojem a je neprodyšně zataven (nelze do něj nic doplňovat). 4. Každý ZP je evidován samostatně, podobně jako MZP. 5. Osoba vlastní pouze jeden ZP a nemusí vlastnit žádné zbraně. 6. K vydání nového ZP je nutno předložit několik dokumentů: a. Žádost formulář (ŽF) o vydání nového ZP. b. Lékařské vysvědčení (LV) o způsobilosti používat a vlastnit zbraň dané kategorie. c. Vysvědčení o zkoušce (VZ) ze znalosti a manipulaci se zbraní dané kategorie/-í. d. Aktuální fotografii. -66-

244 7. Se záznamem nového ZP se musí vytvořit nový záznam pro MZP. 8. ZP je možno odebrat (pochopitelně potom i vlastněné zbraně) na základě několika skutečností (zhoršení zdrav. stavu, odsouzení k závažnému nepodmíněnému trestu, nepřípustné použití zbraně,... ). 9. Může dojít k situaci, že ZP je nutno aktualizovat (změna vzhledu, změna příjmení, změna bydliště, rodného čísla, změna oprávnění na kategorie zbraní). Pak se musí aktuální ZP zničit a vyrobit nový, editovaný. Proto se může evidovat i pořadí vydání nového ZP. Zbraň 10. Řízení informace v uvedených procesech je dovoleno jen administrátorovi okresního velitelství policie ČR, tj. stanovenému důstojníkovi na policejním velitelství. 11. Každá zbraň musí být důsledně evidována. Relevantní informace o samotné zbrani, se získají z prodejního dokumentu Prodejka zbraně (PROZ), kde je uvedeno: PROZ = (název zbraně, výrobní číslo zbraně, druh zbraně, ráže, výrobce, kategorie zbraně (A, B, ), datum výroby, datum prodeje, ID majitele zbraně). K Prodejce zbraně je přiložena Výstupní kontrola zbraně (VKZ) z výrobního podniku, která obsahuje identifikaci osoby, která kontrolu provedla a rovněž terč s výsledkem střelby tří ran na vzdálenost 25 metrů. Tedy eviduje se následující informace: VKZ = (ID kontroly, výrobní číslo zbraně, druh zbraně, ráže, ID kontrolora, výsledek kontroly). Entita Zbraň je velmi důležitou datovou entitou systému Správa soukromých zbraní v ČR a rozhodující je výrobní číslo zbraně. Evidence zbraně obsahuje následující informaci: ZBRAN = (výrobní číslo zbraně, ID majitele ZP, datum nabytí zbraně, stav zbraně). V doméně může dojít k situaci, že zbraň je ztracena, nebo ukradena. V každém případě je majitel zbraně povinen situaci hlásit. Informace o ztrátě je vedena v entitě ZTRÁTA= (ID ztráty, výr. č. zbraně, ID majitele, datum hlášení, protokol) Vzhledem k této situaci musí být o zbrani důsledně veden její stav. PZ 12. Ke každé zbrani se musí vytvořit Průkaz zbraně (PZ). Je v něm několik relevantních údajů z Prodejky zbraně (PRZ). Tedy PZ = (eviden. číslo, druh zbraně, výrobce, vzor, ráže, výrobní číslo zbraně, kategorie, ID majitele, registrace u, datum registrace). Průkaz zbraně je tedy vázán na majitele zbraně, přes ID majitele zbraně, a je platný pro celou ČR. Na PZ je informace o majiteli vytištěna (jméno, příjmení a rodné číslo) 13. Každý Majitel zbraně musí být evidován a identifikován (včetně fotografie) a určeno místo jeho pobytu. Mimo jiné musí mít Zbrojní průkaz. 14. Každá zbraň musí být pravidelně předkládána ke kontrole a kontrola musí být evidována. Tedy o Kontrole zbraně by měla být vedena následující informace: KZ = (ID kontroly, datum kontroly, druh zbraně, výrobní číslo zbraně, výsledek kontroly). -67-

245 Zkusme teď uvést známé skupiny procesů a obsazení jednotlivých množin procesů konkrétními procesy. Tyto procesy budou sloužit jako požadavky policie ČR pro komputerizaci SSZ v ČR. Řízení majitelů ZP. o Zavedení nového MZP o Modifikace informací ohledně MZP o Odstranění MZP Řízení ZP. o o o Vydání nového ZP Odebrání ZP Editace stávajícího ZP Řízení zbraní a průkazů zbraní (PZ). o Zavedení zbraně. o Vytvoření průkazu zbraně. o Zrušení zbraně. o Převedení zbraně na jiného vlastníka. o Předložení zbraně ke kontrole. o Hlášení o ztrátě zbraně Vyhledávání a statistiky. o o o Statistiky ohledně majitelů ZP. Statistiky ohledně zbraní. Statistiky ohledně výrobců zbraní. Řízení klientů. o o Řízení krajských a okresních administrátorů. Nastavení práv, povinností a kompetencí majitelů ZP. Procesy v jednotlivých skupinách jistě nevyčerpávají všechny možnosti. Další procesy mohou být průběžně doplňovány. Jako silné informační entity domény Správa soukromých zbraní mohou vystupovat: Zbrojní průkaz - ZP Majitel zbrojního průkazu - MZP Zbraň Průkaz zbraně - PZ Žádost, formulář- ŽF, k vydání nového zbrojního průkazu Lékařské vysvědčení - LV Vysvědčení o zkoušce - VZ Prodejka zbraně - PROZ Výstupní kontrola zbraně - VKZ Pravidelná kontrola zbraně KZ Hlášení o ztrátě zbraně ZTRATA Uvedeme teď stručný vzorový popis procesů skupiny Řízení zbraní a PZ. Nová zbraň se zavádí v procesu Zavedení zbraně. Jde nejen o vytvoření nového záznamu o zbrani, ale rovněž nového Průkazu zbraně-pz. Dále se musí zabezpečit asociace zbraně na její průkaz a rovněž na majitele Zbrojního průkazu-zp. Zrušení zbraně musí být spojeno se zrušením instance zbraně a Průkazu zbraně a tím zabezpečit rovněž zrušení asociace zbraně na majitele Zbrojního průkazu. -68-

246 Proces Převedení zbraně na jiného vlastníka požaduje zrušit asociaci zbraně na původního Majitele ZP, který zbraň prodává, a přepsat asociaci zbraně na Majitele ZP, který zbraň kupuje. Je nutné zrušit stávající Průkaz zbraně a vytvořit nový, protože průkaz je vázán nejen na zbraň, která se nemění, ale rovněž na vlastníka. V procesu Předložení zbraně ke kontrole se zapíše datum a výsledek kontroly jako nová instance kontroly Pracovní postup Požadavky Ukážeme zde vzorové aktivity-úkoly pracovního postupu Požadavky jen na modelování procesů skupiny Řízení zbraní a PZ. Popis těchto procesů jsme uvedli v popisu problémové domény SSZ v ČR. Na základě stručného popisu skupiny Řízení zbraní a PZ vyřešíme jako vzor jen následujících pět úkolů: 1. Namapujeme procesy skupiny Řízení zbraní a PZ na případy užití a využijeme hrubého popisu procesů. Vytvoříme pro skupinu Řízení zbraní a PZ jediný balíček případů užití a nakresleme jeho diagram a aktéra. Využijeme pokročilé kreslení diagramů případů užití. Pokud je to nutné, doplníme balíček případy užití s relacemi <<include >> a <<extend>>. 2. Dále si vybereme jen případ užití Převedení zbraně na jiného vlastníka, pro který vytvoříme detailní tabulku s hlavním scénářem. Hlavní scénář zakreslíme aktivitním diagramem. Načrtneme plavecké dráhy (budou-li potřebné) a znázorníme tok objektů-instancí (pokud instance vznikají). 3. Nalezneme analytické realizační třídy pro celý balíček Řízení zbraní a PZ a vyznačíme třídy, které se přímo účastní realizace případu užití Převedení zbraně na jiného vlastníka. Popíšeme podrobněji operace těchto vyznačených realizačních tříd (parametry) a jejich atributy. 4. Mezi realizačními třídami případu užití Převedení zbraně na jiného vlastníka jistě existuje třída, jejíž instance-objekty prochází relevantními stavy. Pro takovou třídu nakreslíme její stavový diagram a doplníme potřebné operace. 5. Nakreslíme sekvenční diagram (podle bodu 3.), který ponecháme v analytické podobě. Krok: Mapování procesů skupiny Řízení zbraní a PZ Za vhodné mapování procesů skupiny Řízení zbraní a PZ můžeme považovat zobrazení 1:1, které je dáno následující tabulkou. Procesy Zavedení zbraně Vytvoření Průkazu zbraně Zrušení zbraně Převedení zbraně na jiného vlastníka Předložení zbraně ke kontrole Případy užití Zavedení zbraně Vytvoření Průkazu zbraně Zrušení zbraně Převedení zbraně na jiného vlastníka Předložení zbraně ke kontrole V mapování jsme, pro případy užití, využili názvy samotných procesů. Průkaz zbraně nemůžeme zrušit samovolně, je totiž silně asociován se zbraní samotnou. Proto případ užití Zrušení PZ nemůže být spouštěn aktérem samostatně. Podobné je to rovněž s případem užití Vytvoření PZ. -69-

247 Chápejme vzniklé případy užití jako balíček (sémantické vazby případů užití jsou velmi silné). Pokusíme se proto vytvořit balíček případů užití, přičemž jsme zvážili doplnění dalšími případy užití, které jsou nezbytně nutné k životu celého balíčku (Vyhledání zbraně, zrušení PZ). Jsou ovšem další pomocné případy užití, např. Vyhledání MZP, Vyhledání ZP, Vyhledání PZ, Odebrání zbraně, Přidání zbraně, Ztráta zbraně ). Těmito případy užití můžeme diagram balíčku ještě zjemnit. Řízení zbraní a PZ Zavedení zbraně <<extend>> Vytvoření PZ Administrátor Zrušení zbraně Převedení zbraně na jiného vlastníka <<include>> << extend >> <<extend>> Vyhledání zbraně Zrušení PZ Vytvoření PZ Předložení zbraně ke kontrole Krok: Detailní scénář případu užití Převedení zbraně na jiného vlastníka Teď bychom měli v druhém kroku vytvořit detailní scénáře pro všechny případy užití z našeho balíčku. Jako vzorový si vybereme jen případ Převedení zbraně na jiného vlastníka. Není to příliš komplikovaný případ užití. Zajímavé je to, že se netýká změny Zbrojního průkazu, ale Průkazu zbraně. Mění se tedy asociace mezi zbraní a jejím průkazem. Jde v podstatě nejen o změnu asociace mezi entitou Majitel zbrojního průkazu a entitou Zbraň a to jak pro prodávajícího, tak i kupujícího. Změna se musí přenést rovněž na PZ. Vstupní podmínkou případu užití je existence obou platných ZP (prodávajícího a kupujícího), PZ a platná kontrola prodávané zbraně. Sledující tabulka je detailizací případu užití Převedení zbraně na jiného vlastníka Případ užití: Převedení zbraně na jiného vlastníka ID: 6 Stručný popis: Systém umožní převést danou zbraň od jednoho majitele na jiného. Hlavní aktéři: Administrátor policejní důstojník Vedlejší aktéři: Žádní Vstupní podmínky: Platné ZP prodávajícího a kupujícího, platný PZ prodávané zbraně a její kontroly. Hlavní scénář: 1. Zadej výrobní číslo zbraně potom evidenční číslo PZ. 2. Je-li zbraň v pořádku a rovněž v pořádku její průkaz, zjisti kategorii zbraně, majitele a pokračuj na bodu 3. Jestliže nejsou v pořádku (zbraň: není evidovaná v systému, má neplatnou kontrolu, PZ: není evidován v systému), tak oznam závady a ukonči případ užití. -70-

248 3. Zadej evidenční čísla obou ZP, prodávajícího a kupujícího. Jsou-li oba ZP v pořádku (jsou evidované v systému), tak pamatuj identifikaci obou majitelů, jejich kategorie zbraní a jdi na bodu 4. Jinak udělej oznámení chyby a ukonči případ užití. 4. Je-li vše v pořádku (prodávající je evidovaným majitelem zbraně, zbraň má platnou kontrolu, kategorie prodávané zbraně je v souladu s kategoriemi na ZP prodávajícího a kupujícího), tak zruš asociaci dané zbraně (podle výrobního čísla zbraně) na majitele, tj. prodávajícího. 5. Zaveď asociaci zbraně (podle výrobního čísla) na kupujícího a změnu zaveď na nový PZ. 6. Podej zprávu o provedení případu užití a dokumentuj výpisy nové asociace prodávané zbraně. Výstupní podmínky: Žádné Alternativní scénáře: Nejsou zavedeny Relace aktérů k případu užití: Aktér, administrátor se k cílovému software přihlašuje (musí zadat své uživatelské jméno a heslo) a případ užití spouští. K danému hlavnímu scénáři patří následující aktivitní diagram. Určíme pouze dvě odpovědnosti za aktivity v případu užití, které jsou dány Systémem cílového software a Administrátorem. V průběhu případu užití vzniká nová instance objektu průkazu zbraně (je nový majitel) a dochází k přepisu atributů jedné instance datové entity Zbraň (nový majitel). Systém Administrátor evidence? kontrola? Zadej: výr. číslo zbraně, evidenční číslo PZ závady Oznámení o nedostatcích v evidenci a kontrole Zadej evidenční čísla ZP prodávajícího a kupujícího evidence? kategorie? závady Oznam závady Zruš asociaci zbraně na prodávajícího Zaveď asociaci zbraně na kupujícího Dokumentuj správné provedení případu užití pomocí výpisu nové asociace zbraně na majitele a vytiskni nový průkaz zbraně, kde je nový majitel -71-

249 16.3 Pracovní postup Analýza Hlavními úkoly pracovního postupu Analýza je tvorba relevantních objektových diagramů: Diagramy analytických-realizačních tříd pro jednotlivé případy užití a s nimi asociovaných Sekvenčních diagramů. Začneme vzorovým případem užití Převedení zbraně na jiného vlastníka. Potom bychom měli přejít na další případy užití v našem balíčku Řízení zbraní a PZ a sestrojit další analytické diagramy tříd. V pracovním postupu Návrh sloučíme všechny dílčí diagramy analytických tříd a sestrojíme tzv. komplexní návrhový diagram tříd balíčku Řízení zbraní a PZ. Krok: Hledání analytických tříd. V hledání analytických tříd začínáme pozorným čtením detailní tabulky případu užití Převedení zbraně na jiného vlastníka. Současně sledujeme aktivitní diagram pro zmíněný scénář. Postupně nacházíme tyto kandidáty na analytické objektové třídy: MZP, Zbraň, PZ, KZ a ZP. Po krátké úvaze tyto kandidáty (protože budou dostatečně vystihovat data a operace případu užití) prohlásíme za analytické třídy. Nakresleme teď v souladu se sémantikou problémové domény SSZ v ČR asociace mezi třídami. Známe-li dobře doménu, můžeme přijít k následujícímu diagramu. MZP KZ * 1 1..* ZP Zbraň 11 1 PZ 1 Na realizaci případu užití Převedení zbraně na jiného vlastníka se tedy podílí pouze třídy Zbraň, ZP, MZP, PZ a KZ. Navržené atributy: MZP = (ID majitele ZP, jméno a příjmení, rodné číslo, fotografie, trvalé bydliště, ID žádosti, ID lékařského vysvědčení, ID vysvědčení o zkoušce) ZP = (eviden. číslo, platnost do, ID majitele ZP, oprávnění na kategorie zbraní: A F, kdo vydal ZP). Atributy jméno a příjmení, rodné číslo, fotografie a trvalé bydliště, které jsou na ZP vytištěny, jsou přebírány od MZP. PZ = (eviden. číslo, druh zbraně, výrobce, vzor, ráže, výrobní číslo zbraně, kategorie, ID majitele ZP, registrace u, datum registrace). ZBRAN = (výrobní číslo zbraně, ID majitele ZP, datum nabytí zbraně) KZ = ( ID kontroly, datum kontroly, druh zbraně, výrobní číslo zbraně, výsledek kontroly). -72-

250 Prvotní analytický návrh operací: OPERACE TŘÍDA POPIS OPERACE dejzbraň ZBRAN Zadá se výrobní číslo předložené zbraně. Operace vytiskne oznam, že zbraň je, nebo není evidovaná. dejkz KZ Zadá se výrobní číslo předložené zbraně. Operace oznámí platnost, nebo vypršení poslední kontroly zbraně. hledejpz PZ Zadá se evidenční číslo předloženého PZ. Operace vytiskne oznam o evidenci. hledejzp ZP Zadá se evidenční číslo předloženého ZP prodávajícího/kupujícího. Operace potvrdí, nebo nepotvrdí evidenci ZP v systému. přepišzbraň ZBRAN Operace převede zbraň z prodávajícího na kupujícího a podá o tom zprávu. Poznámka: Kvůli zjednodušení situace jsme neuvažovali možnost, že prodávající a kupující jsou z jiných okresů. V tomto případě by měl administrátor požádat jiného administrátora o povolení provedení operace. Krok: Analytické třídy případu užití Převedení zbraně na jiného vlastníka Musíme si uvědomit, že je předložená zbraň a na ní výrobní číslo, které můžeme přečíst. Dále je předložen Průkaz zbraně. Lze okamžitě zjistit, že průkaz patří/nepatří k předložené zbrani. Nechť předložený Průkaz zbraně k dané zbrani patří a není falešný. Jelikož systém správy soukromých zbraní v ČR se zavádí postupně, může se stát, že některé zbraně, jejich průkazy a zbrojní průkazy nejsou v systému elektronicky evidovány. Nejdříve prověříme existenci evidence zbraně a jejího průkazu v bázi dat, zjistíme kategorii zbraně a platnost kontroly. Pokud evidence nejsou, tak je administrátor musí provést. Neplatnost kontroly zbraně ukončuje případ užití. Zbraň se musí prohlédnout technikem a výsledek kontroly zapíše administrátor do systému. Jen zbraň s platnou kontrolou se může prodávat. Dále jsou předloženy dva zbrojní průkazy, prodávajícího a kupujícího. Snadno se zjistí, že nejsou falešné a časově platné. Prověříme jejich evidenci v systému. Pokud v systému nejsou, případ užití končí. Zavedení se provede samostatně. Dále je nutno kategorii předložené zbraně porovnat s kategoriemi na obou Zbrojních průkazech. Jsou-li v souladu, je možné provést převod zbraně prodávajícího na kupujícího. Předpokládejme, že vše je evidováno. Jinak se operace pro evidence dají snadno doplnit, ale případ užití je nejdříve ukončen, protože vyžaduje vše evidované v systému. Na základě potřebných operací můžeme sestavit atributy jednotlivých tříd. Každá třída by měla mít identifikační atribut, který dodá každé generované instance jeho jedinečnou hodnotu. Ostatní atributy navrhneme podle vazeb analytických tříd. V návrhu atributů musíme projevit svou analytickou prozíravost (tak např. stanovíme atribut stav), ale dbáme, aby analytický návrh atributů zahrnoval je ty atributy, které jsou potřebné pro jednotlivé operace analytických tříd. V analytickém návrhu by měly být zejména atributy související s daným případem užití. -73-

251 MZP ID majitele ZP Příjmení jméno Rodné číslo Fotografie Trvalé bydliště KZ ZP evid. číslo platnost do ID majitele ZP Kategorie zbraní Kdo vydal hledejzp ID kontroly Datum kontroly Druh zbraně Výrobní číslo zbraně Výsledek kontroly dejkz Zbraň Výrobní číslo zbraně ID majitele ZP Datum nabytí zbraně stav dejzbraň přepišzbraň PZ Evid. číslo PZ Druh zbraně Výrobce Vzor Ráže Výrobní číslo zbraně Kategorie ID majitele ZP Registrace u Datum registrace hledejpz Krok: Stavový diagram třídy Zbraň Za velmi vhodnou vzorovou třídu, jejíž instance procházejí jistými relevantními stavy, můžeme považovat např. třídu Zbraň. Toto tvrzení je nutné zvážit. Zavedení stavu instancí třídy Zbraň má význam jen tehdy, když existují případy užití, v nichž je stav využíván a je na něj brán ohled. V doméně Správa soukromých zbraní v ČR takové případy užití existují. 3. Je v prodeji... Zbraň byla vyrobena a je vybavena výstupní kontrolou (VKZ). Je zavedena a používána... Byl uskutečněn prodej. Zbraň je doplněna o prodejku (PROZ). Do V souvislosti s třídou Zbraň můžeme tohoto navrhnout stavu se musí např. dostat tyto stavy: po jisté době od prodeje (měřeno počten dnů). Je v kontrole... Je to stav, v kterém zbraň setrvá na policii krátkou dobu. Je uložena na policii... Majitel se vzdal vlastnictví a zbraň je na policii a může být opět prodána. Je zrušena... Zbraň je odevzdána na policii po kontrole, která vyhlašuje další nepoužitelnost zbraně. Je ztracena/ukradena... Zbraň nelze předložit ke kontrole. Následuje stavový diagram (stav Je ztracena není dokončen!): 8 V prodeji 1 Zavedena a používána Je na policii uložena 7 6 V kontrole Je ztracena/ukradena Zrušena -74-

252 Význam označení ve tvaru událost/operace 1... Zbraň je prodána/zavedení zbraně Není žádná závažná okolnost (negativní výsledek technické kontroly, odevzdání zbraně na policii), která by narušila užívání zbraně Zbraň je dobrovolně odevzdaná na policii/realizuj odevzdání Zbraň je předána ke kontrole/zkontroluj zbraň 5... Je pozitivní výsledek kontroly/zaznamenej kontrolu Je negativní výsledek kontroly/realizuj vyřazení zbraně Zbraň je zastaralá/ Realizuj vyřazení zbraně O zbraň je zájem/vybav zbraň pro prodej Zbraň je ztracena-ukradena/realizuj dočasné vyřazení zbraně. Po nalezení, by se zbraň měla nejdříve vrátit do stavu Zkontroluj zbraň. Poznámka: Převedení zbraně z jednoho majitele na druhého jsme za stav nepovažovali. Krok: Tvorba interaktivního diagramu pro případ Převedení zbraně na jiného vlastníka. Jak jsme již naznačili, realizace případu užití Převedení zbraně na jiného vlastníka mají na starosti jen třídy Zbraň, KZ, PZ, KZ a ZP. Jde teď jen o spolupráci tříd, aby pomocí svých operací, které zpracovávají jejich atributy, zabezpečily realizaci případu užití. Příklad případu užití bude spuštěn a řízen administrátorem. Můžeme tedy zvolit velmi jednoduchou strategii, která pro komunikaci s ostatními instancemi používá jen administrátora. Tato strategie je uvedena na následujícím obrázku. Administrátor Zbraň KZ PZ ZP dejzbraň dejkz hledejpz hledejzp majitele hledejzp kupujícího přepišzbraň 16.4 Pracovní postup Návrh Krok: Sestavení návrhového diagramu analytických tříd pro případ Převedení zbraně na jiného vlastníka. V tomto kroku bychom měli již přesně popsat všechny třídy balíčku, jejich operace a rovněž Sekvenční diagramy všech případů užití. Návrhová podoba je již vhodná k programování. Nejdříve provedeme úpravu všech operací tak, že v nich jsou uvedeny všechny parametry. -75-

253 OPERACE TŘÍDA POPIS OPERACE dejzbraň(včz,i) ZBRAN Zadá se výrobní číslo předložené zbraně. Operace vytiskne oznam, že zbraň je, nebo není evidovaná. Je-li zbraň evidována, pak se parametr i naplní identifikátorem majitele ZP. dejkz( včz,j) KZ Zadá se výrobní číslo předložené zbraně. Operace oznámí platnost, nebo vypršení poslední kontroly zbraně. Je-li kontrola platná, je parametr j nastaven na true. hledejpz(ečpz, k) PZ Zadá se evidenční číslo předloženého PZ. Operace vytiskne oznam o evidenci. Je-li evidence, pak parametr k bude obsahovat kategorii zbraně. hledejzp(ečzp 1, IDm 1, K 1 ) ZP Zadá se evidenční číslo ZP prodávajícího. Operace potvrdí, nebo nepotvrdí evidenci ZP v systému. Je-li ZP evidován, pak do IDm 1 se dosadí identit. číslo prodávajícího a K 1 je množina přípustných kategorií. hledej ZP(ečZP 2, IDm 2, K 2 ) ZP Zadá se evidenční číslo ZP kupujícího. Operace potvrdí, nebo nepotvrdí evidenci ZP v systému. Je-li ZP evidován, pak do IDm 2 se dosadí identit. číslo kupujícího. (i= IDm 1 )(kk 2 ) (j=true) přepišzbraň(včz, IDm 1, IDm 2, datum nabytí) ZBRAN Operace převede zbraň s včz z prodávajícího na kupujícího a podá o tom zprávu. Teď upravíme třídy, v kterých upravíme operace a můžeme zavést popisy typů jednotlivých atributů, tj. do tvaru který je žádán ze strany jazyka UML. MZP ID majitele ZP Příjmení jméno Rodné číslo Fotografie Trvalé bydliště KZ ID kontroly Datum kontroly Druh zbraně Výrobní číslo zbraně Výsledek kontroly dejkz( včz,j) ZP Evid. číslo ID majitele ZP Kategorie zbraní Pořadí vydání ZP hledejzp(ečzp, IDm, K) Zbraň Výrobní číslo zbraně ID majitele ZP dejzbraň(včz,i) přepišzbraň(včz, IDm1, IDm2) PZ Evid. číslo Druh zbraně Výrobce Vzor Ráže Výrobní číslo zbraně Kategorie ID majitele ZP Registrace u Datum registrace hledejpz(ečpz, k) Nakonec upravíme do návrhové podoby rovněž Sekvenční diagram případu užití Převedení zbraně na jiného vlastníka. -76-

254 Administrátor Zbraň KZ PZ ZP dejzbraň(včz, i) dejkz(včz, j) hledejpz(ečpz, k) hledejzp(ečzp 1, K 1) hledejzp(ečzp 2, K 2) IF (i= IDm 1) (kk 2) (j=true) THEN přepišzbraň(včz, IDm 1, IDm 2, datum nabytí) Poznámka: 1. Zdá se, že třída MZP je pro realizaci řešeného případu užití jen kontextová. Pro jinou realizaci zájmového případu užití tomu tak nemusí být. 2. Případ užití Převedení zbraně na jiného vlastníka by mohl být řešen jistě lépe. Naším úkolem bylo najít jedno řešení. 3. Jestli bychom našli analytické realizační třídy pro celý balíček Řízení zbraní a PZ, pak je sloučíme do jednoho, který by mohl mít následující tvar. Operace sloučení je velmi jednoduchá. MZP 1 1 ZP 1 KZ 1..* 1 0..* Zbraň 11 1 PZ PROZ 1 1 VKZ -77-

255 17 Literatura [EelCrip011] Eeles, P. Cripps, P.: Architektura software. Nepostradatelný průvodce návrhem softwarové architektury, která funguje. Brno: Computer Press, ISBN [Wieg08] [Kad04] [Jul08] [Ald05] [ArNe03] [Jul08] [ArNe07] [CoHu95] [Gib06] [Kru01] [RJB05] [Vach07] Wiegers, K, E.: Požadavky na software. Od zadání k architektuře aplikace. Brno: Computer Press, ISBN KADLEC, V.: Agilní programování: metodiky efektivního vývoje softwaru. Brno: Computer Press, s. ISBN Julínek, P.: Použití RUP pro malé SW projekty. Diplomová práce. Brno: Masarykova univerzita, Fakulta informatiky, Dostupné na WWW: < ALDORF, F.: Metodika RUP [online], diplomová práce, Dostupné na WWW: < ARLOW, J. - NEUSTADT, I.: UML a unifikovaný proces vývoje aplikací: průvodce analýzou a návrhem objektově orientovaného softwaru. Brno: Computer Press, s. ISBN X. Julínek, P.: Použití RUP pro malé SW projekty. Diplomová práce. Brno: Masarykova univerzita, Fakulta informatiky, Dostupné na WWW: < Arlow, J., Neustad, I. UML 2 a unifikovaný proces vývoje aplikací. Druhé vydání. Průvodce analýzou a návrhem objektově orientovaného software. Brno: Computer Press, ISBN COTTERELL, M. - HUGHES, R.: Software Project Management. Itp New Media, s. ISBN GIBBS, D.: Project Management with the IBM Rational Unified Process. IBM Press, s. ISBN KRUCHTEN, P.: The Rational Unified Process An Introduction. 2nd edition. Boston: Addison-Wesley, s. ISBN RUMBAUGH, J. - JACOBSON, I., BOOCH, G.: The unified modeling language reference manual. 2nd edition. Boston: Addison-Wesley, s. ISBN VACH, D.: IBM Rational [online] Dostupné na WWW: < [KaMu07] Kanisová, H. Muller, M.: UML srozumitelně. Brno: Computer Press, a.s ISBN [Smr010] Smrčka, F.: Disertační práce (školitel Mišovič). Brno: Mendelova univerzita, Provozně ekonomická fakulta, Ústav informatiky, Poměrně zajímavé informace o UML získáte na adrese

256 VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky SOFTWAROVÉ INŽENÝRSTVÍ ČÁST IV. VÝVOJ OBJEKTOVÝCH APLIKACÍ PODLE METODIKY UP 4 FÁZE KONSTRUKCE A ZAVEDENÍ STUDIJNÍ TEXT PRO KOMBINOVANOU FORMU STUDIA Milan Mišovič 2011

257 Prof. RNDr. Milan Mišovič, CSc. SOFTWAROVÉ INŽENÝRSTVÍ 1. vydání Vydala Vysoká škola polytechnická Jihlava, Tolstého 16, Jihlava, 2011 Tisk Ediční oddělení VŠPJ, Tolstého 16, Jihlava Za jazykovou a věcnou správnost obsahu díla odpovídá autor. Text neprošel jazykovou ani redakční úpravou. Milan Mišovič, 2011

258 Obsah Část IV. Vývoj objektových aplikací podle metodiky UP 4 Fáze KONSTRUKCE a ZAVEDENÍ 18 Fáze KONSTRUKCE Úvod Pracovní postup Implementace Fáze ZAVEDENÍ Úvod Krok architektonická implementace Krok tvorba Diagramu nasazení a Modelu nasazení Uzly Artefakty Literatura... 11

259 18 Fáze KONSTRUKCE Cíle: Znát (umět vysvětlit): 1. Primární cíle fáze KONSTRUKCE. 2. Milník fáze KONSTRUKCE. 3. Znát pojetí pracovního postupu Implementace. 4. Složení implementačního modelu. Dovednosti (umět prakticky): 18. Uplatnit znalosti týkající se architektury, pro praktické hledání implementačního modelu 19. Uplatnit znalosti grafických notací UML pro praktické modelování komponentové architektury. Klíčová slova: Komponenta, návrhový model, implementační model, artefakt, uzel, relace <<manifest>> 18.1 Úvod Hlavním cílem fáze KONSTRUKCE je vytvořit zdrojový kód cílového software. Je zřejmé, že závažnou roli zde bude hrát znalost objektového programovacího jazyka a jeho implementace k popisu tříd a k naprogramování sekvenčních diagramů. Pracovním postupem, který má do zmíněného kódu dospět je Implementace. Jsou názory, že modelování, které je v tomto pracovním postupu použito a založeno na UML, nepříliš pomáhá programátorům. Z tohoto důvodu je této problematice v odborné literatuře věnována menší pozornost. My však pracovním postupem Implementace stručně projdeme a navážeme jeho hlavní cíl na výsledky fáze ROZPRACOVÁNÍ. Pochopitelně, je-li použit velmi inteligentní nástroj CASE, který má všechny potřebné podklady pro generování kódu z fáze ROZPRACOVÁNÍ a veškeré technické pokyny, tak toho můžeme využít. Nepočítejme ovšem s tím, že s generovaným kódem budeme výrazně nadšeni Pracovní postup Implementace Implementace je hlavním pracovním postupem ve fázi KONSTRUKCE. Tento pracovní postup má za cíl vytvořit zdrojový kód cílového software. Jestliže tento software má architekturu postavenou na komponentách, tak jsme se postupem Implementace museli zabývat již ve fázi ROZPRACOVÁNÍ, kde bylo našim cílem, vedle jiných, vytvořit kód tzv. spustitelného architektonického základu. Obecně platí, že pracovní postup Implementace spočívá v převodu návrhového modelu do spustitelného zdrojového kódu. Návrhový model Spustitelný kód Cílového software převod Obrázek 18-1: Hrubé naznačení vztahu návrhového modelu a spustitelného kódu. -4-

260 Na začátku pracovního postupu Implementace se obvykle vytváří ještě tzv. Implementační model software. Tento model hlavně říká, do kterých komponent budou umístěny realizační objektové návrhové třídy spolu s asociovanými sekvenčními diagramy a rozhraním. Implementační model je složen z Diagramu jednotlivých komponent, který již respektuje vztah podsystémů a komponent (protože teď bude systém zadán komponentami) a z Diagramu nasazení. Diagram nasazení modeluje fyzické výpočetní uzly informační infrastruktury, na které cílový software nasadíme, a relace mezi nimi. Pro snadnější pochopení vlastního převodu zopakujeme část Obrázku 13-2 (Část IV. 3 Fáze ROZPRACOVÁNÍ) a doplníme ji diagramem nasazení. Diagram komponent Návrhový model <<component>> <<manifest>> <<manifest>> Diagram nasazení Zařízení 1 Artefakt 1 Artefakt 2 Uzel Artefakt <<component>> C 3 <<manifest>> <<manifest>> Zařízení 2 Artefakt 13 Návrhové třídy Návrhová realizace případů užití Obrázek 18-2: Implementační model. Implementační model z obrázku 18-2 nebude teď dostatečně jasný. V další kapitole vysvětlíme Diagram nasazení a k obrázku se můžeme vrátit. Přesto můžeme podat stručné objasnění: artefakty reprezentují např. soubory zdrojového kódu, uzly jsou specifikací hardware, relace <<manifest>> mezi komponentami a artefakty určuje, které artefakty jsou fyzickou reprezentací komponent. komponenty jsou abstraktním vyjádřením artefaktů, artefakty jsou nasazovány na uzly, uzly jsou specifikací hardware nebo prostředí nasazení cílového software. Na fázi KONSTRUKCE se podílí zejména hlavní architekt, systémový integrátor a inženýr komponent. Hlavní cíl fáze KONSTRUKCE: tvorba spustitelného kódu je záležitostí využití programovacích jazyků a vývojových prostředí. Tato problematika zde nebude rozebírána. Shrnutí kapitoly: Nerozsáhlá kapitola uvádí podstatu fáze KONSTRUKCE, v které dominuje tvorba zdrojového kódu. Je vysvětleno, že kód v podstatě vzniká z návrhového modelu. Vzhledem k architektonické složitosti cílového software je vhodné vytvářet tzv. Implementační model vycházející sice z Návrhového modelu, ale doplněného tzv. Diagramem nasazení. Σ -5-

261 Pojmy k zapamatování: Komponenta, návrhový model, implementační model, artefakt, uzel, relace <<manifest>> Testy a otázky: 1. Co je hlavním cílem fáze KONSTRUKCE? 2. Vysvětlete pojetí a vztah dvou modelů, návrhový model a implementační model. 3. Z čeho se skládá diagram nasazení? Úkoly k zamyšlení: Pokuste se vracet po všech fázích a řeknete, kde všude se musíme zabývat architekturou cílového software. <<komponenta>> -6-

262 19 Fáze ZAVEDENÍ Cíle: Znát (umět vysvětlit): 1. Primární cíle a milník fáze ZAVEDENÍ. 2. Znát pojetí pracovního postupu Nasazení. 3. Složení architektonické implementace a podstatu Diagramu nasazení. Dovednosti (umět prakticky): 1. Uplatnit znalosti k provedení architektonické implementace. 2. Uplatnit znalosti grafických notací UML pro praktické modelování Diagramů nasazení. Klíčová slova: Architektonická implementace, Diagram nasazení, uzel, artefakt, komponenta 19.1 Úvod Problematika fáze ZAVEDENÍ již dokončuje všechny aktivity předešlých fází ohledně modelování a tvorby kódu cílového software. Je tedy zřejmé, že je značně dopracovaná (ne-li dokončena) architektura a kód cílového software a jde již jen o nasazení software na informační infrastrukturu organizace. Základem fáze ZAVEDENÍ je dopracování fyzické architektury cílového software. Tím se zabývá právě pracovní postup Nasazení. Obecně je složen alespoň z dvou kroků: architektonická implementace, tvorba Diagramu a modelu nasazení. Proto je kapitola rozdělena na dvě podkapitoly, které zváží jak je daná architektura implementovatelná a jak to bude vypadat konkrétně s jejím nasazením v informační infrastruktuře organizace Krok architektonická implementace Je to jeden z pracovních kroků pracovního postupu Nasazení. Hlavním cílem architektonické implementace je rozpoznat architektonicky významné komponenty a jejich mapování na informační infrastrukturu organizace. Podstata kroku tedy spočívá v modelování fyzické struktury cílového software, to značí jeho rozložení. Pro pochopení architektonické implementace jistě pomůže následující obrázek: Popis architektury (implementace a nasazení) Model nasazení Architektonická implementace Artefakt Model návrhu Popis architektury (návrh a nasazení) <<component>> Artefakt Uzel Obrázek 19-1: Artefakty pracovního kroku architektonická implementace (zdroj [ArNe07]). -7-

263 Ačkoliv mezi výstupními artefakty architektonické implementace není uveden diagram nasazení, je žádoucí alespoň jeden provizorní nakreslit. První představa o spojení komponent, artefaktů a uzlů již specifikuje instalační fyzickou architekturu cílového software. Zde je nutné všimnout si diametrálního rozdílu mezi logickou architekturou a fyzickou architekturou (logická architektura fyzické nasazení cílového software vůbec nezvažuje, jde ji jen o logické členění systému na komponenty). Další nezbytnou aktivitou v rámci architektonické implementace je oprava-aktualizace popisu architektury z podoby návrhu a nasazení (co je plánováno) na podobu implementace a nasazení (jak se to fyzicky uskuteční v dané IIS organizace) Krok tvorba Diagramu nasazení a Modelu nasazení Nasazení je v metodice UP chápáno jako přiřazení artefaktů jednotlivým uzlům v IIS organizace. Diagram nasazení musí proto ukazovat nejen hardware, ale rovněž jak je cílový software na tomto hardware nasazen. Existují dvě verze Diagramu nasazení: 1. Obecný Diagram nasazení (Descriptor form for Deployment diagram), který mapuje logickou architekturu, která je dokončena v pracovním postupu Návrh (viz fáze ROZPRACOVÁNÍ - KONSTRUKCE) na tzv. fyzickou architekturu. Fyzická architektura je tedy silná asociace logické architektury a typů hardware a artefaktů (obecné uzly a artefakty, které můžeme později upřesnit jejich konkrétními instancemivýskyty). 2. Diagram nasazení (Instance form for Deployment diagram) pro konkrétní nasazení cílového software v dané organizaci s konkrétní informační infrastrukturou (IIS) musí obsahovat: a. instance uzlů (specifikovaná část hardware z IIS organizace), relace mezi nimi, b. instance komponent (zastupující konkrétní software instance artefaktů), c. relace mezi instancemi uzlů a instancemi artefaktů. 3. Tvorba potřebných deskripcí (konkrétního specifikovaného hardware, instancí komponent a relací), včetně uložení v prostředku CASE potom dotváří Model nasazení cílového software. Provizorní Diagram nasazení můžeme naznačit již v pracovním postupu Návrh, kde uvažujeme obecné uzly a jejich propojení. Můžeme ovšem naznačit i jejich vztah s logickou architekturou cílového software. Provizorní diagram nasazení potom dopracujeme v pracovním postupu Implementace viz Implementační model Uzly Uzlem se obecně myslí typ výpočetního prostředku, na kterém se dají nasadit a spouštět artefakty. UML 2.0 uvažuje dva stereotypy používané pro uzly: <<device>> pro obecné zařízení, např. desktopový nebo přenosný počítač, <<execution environment>> pro prostředí zpracování, např. webový provozní server. Pochopitelně, s uzly je možno provádět vnořování a asociace (typ asociace, násobnosti, pojmenování asociace, role instancí). Asociace mezi uzly je ilustrací kanálu mezi uzly pro tok informace. Pro konkrétní nasazení používáme instance uzlů z existující IIS organizace. Tyto diagramy potom naznačují implementační možnosti pro fyzickou architekturu nasazovaného cílového software. Stereotypů pro uzly je v UML 2.0 poměrně mnoho a jsou jim rovněž přiřazovány ikony z rozsáhlé knihovny clipartů. To je nesmírně užitečné, protože ikony přímo reprezentují konkrétní hardware a -8-

264 konkrétní Diagramy nasazení jsou dobře čitelné (viz následující obrázek). * 1 server * 1 1 * Cloud Obrázek 19-2: Asociace mezi uzly pro možnost konkrétního nasazení cílového software Artefakty Mezi artefakty se obvykle řadí zdrojové soubory (mnoho překladačů je interpretačních na bázi zdrojového kódu), spustitelné soubory (jsou to binární soubory strojových instrukcí závislé na daném počítači), skripty (jsou to rozumné kusy kódu, většinou zdrojového, které jsou využívány v produkci software na webové platformě jazyka DHTML), databázové tabulky (jde nejen o relační tabulky, ale chápat zde můžeme rovněž jednotky objektových bází dat), dokumenty (jde o jakékoliv dokumenty, které jsou vlastně binární na bytovém základu), výstupy vývojového procesu (myslí se modely, které se připravují nejen v metodikách RUP a UP) Pochopitelně, v seznamu jsou typy artefaktů pojmenovány obecně a je potřeba použitým jménům rozumět v intencích vztahu objektové třídy a generovaných instancí této třídy. Platí, že instance artefaktů jsou nasazovány na instance uzlů. Z hlediska postupného vývoje je zřejmé, že artefakty jsou projevem jedné, nebo několika komponent. V rámci pracovního kroku tvorba Diagramu nasazení můžeme rozvést jednotlivé komponenty spolu s artefakty, které k nim patří. Dostaneme tak velmi zajímavý diagram doplňující Diagram nasazení, dávající dohromady komponenty a jejich artefakty a relace mezi komponentami. Tato problematika by se ovšem měla sledovat v použitém programovacím jazyku. -9-

265 Shrnutí kapitoly: Kapitola je věnována vysvětlení pojetí a obsahu pracovního postupu Nasazení. Jsou podána vysvětlení ke dvěma pracovním krokům architektonická implementace a tvorba Diagramu nasazení. Σ Pojmy k zapamatování: Architektonická implementace, Diagram nasazení, uzel, artefakt, logická a fyzická architektura Testy a otázky: 4. Co je obsahem architektonické implementace? 5. Jaké jsou podstatné rozdíly mezi logickou a fyzickou architekturou. 6. Jaký je význam uzlů a artefaktů? 7. Proč je výhodné kreslit diagram vztahu artefaktů a komponent? Úkoly k zamyšlení: Vyjmenujte místa v metodice UP, v kterých je záhodno mluvit o architektuře cílového software (naznačení: kde ve fázích ZAHÁJENÍ, ROZPRACOVÁNÍ, KONSTRUKCE a ZAVEDENÍ)? -10-

266 20 Literatura [EelCrip011] Eeles, P. Cripps, P.: Architektura software. Nepostradatelný průvodce návrhem softwarové architektury, která funguje. Brno: Computer Press, ISBN [Wieg08] [Kad04] [Jul08] [Ald05] [ArNe03] [Jul08] [ArNe07] [CoHu95] [Gib06] [Kru01] [RJB05] [Vach07] Wiegers, K, E.: Požadavky na software. Od zadání k architektuře aplikace. Brno: Computer Press, ISBN KADLEC, V.: Agilní programování: metodiky efektivního vývoje softwaru. Brno: Computer Press, s. ISBN Julínek, P.: Použití RUP pro malé SW projekty. Diplomová práce. Brno: Masarykova univerzita, Fakulta informatiky, Dostupné na WWW: < ALDORF, F.: Metodika RUP [online], diplomová práce, Dostupné na WWW: < ARLOW, J. - NEUSTADT, I.: UML a unifikovaný proces vývoje aplikací: průvodce analýzou a návrhem objektově orientovaného softwaru. Brno: Computer Press, s. ISBN X. Julínek, P.: Použití RUP pro malé SW projekty. Diplomová práce. Brno: Masarykova univerzita, Fakulta informatiky, Dostupné na WWW: < Arlow, J., Neustad, I. UML 2 a unifikovaný proces vývoje aplikací. Druhé vydání. Průvodce analýzou a návrhem objektově orientovaného software. Brno: Computer Press, ISBN COTTERELL, M. - HUGHES, R.: Software Project Management. Itp New Media, s. ISBN GIBBS, D.: Project Management with the IBM Rational Unified Process. IBM Press, s. ISBN KRUCHTEN, P.: The Rational Unified Process An Introduction. 2nd edition. Boston: Addison-Wesley, s. ISBN RUMBAUGH, J. - JACOBSON, I., BOOCH, G.: The unified modeling language reference manual. 2nd edition. Boston: Addison-Wesley, s. ISBN VACH, D.: IBM Rational [online] Dostupné na WWW: < [KaMu07] Kanisová, H. Muller, M.: UML srozumitelně. Brno: Computer Press, a.s ISBN [Smr010] Smrčka, F.: Disertační práce (školitel Mišovič). Brno: Mendelova univerzita, Provozně ekonomická fakulta, Ústav informatiky, Poměrně zajímavé informace o UML získáte na adrese

267 SCÉNÁŘ FÁZE ZAHÁJENÍ NAD DOMÉNOU SSZ V ČR (20. Dubna 2012) 1 ÚVOD 1.1 Stručný popis problémové domény SSZ v ČR Následující komplexní příklad se týká domény Správa soukromých zbraní v ČR (SSZ v ČR). Ukážeme nejdříve její obecný popis, ale nebudeme se přísně držet současně platného zákona o soukromých zbraních. SSZ v ČR sama o sobě není IS české policie, ale spíše jeho součástí. Sama o sobě je víceméně samostatná a v bázi IS policie má vydělitelnou část. V této doméně jsou rozhodující informace o majiteli zbrojního průkazu (MZP), o samotných zbrojních průkazech (ZP), o zbraních a průkazech zbraní (PZ). Modifikace a vytváření informace o MZP, ZP, zbrani a PZ náleží jen administrátorovi daného okresu, tj. podle trvalého bydliště MZP. Je-li zbraň zakoupena, musí být podle zákona do jisté doby zavedena do používání. Prodejce vydává ke zbrani výsledek její výrobní kontroly (osvědčení o správné funkcionalitě, nástřelný terč, vše s podpisy státem delegovaných kontrolorů). Zbraň je potom zavedena do systému policejním administrátorem v daném okrese, tj. vytvoří se informace o jejím zavedení a asociaci s MZP. Je-li to zákonem stanoveno, zbraň musí být kontrolována a výsledek zapsán do báze dat (viz dále). 1.2 Bližší charakteristiky domény SSZ v ČR 1. Každý majitel Zbrojního průkazu je v bázi cílového software evidován, tedy vede se o něm následující informace: MZP MZP = (ID majitele ZP, jméno a příjmení, rodné číslo, fotografie, trvalé bydliště, ID žádosti, ID lékařského vysvědčení, ID vysvědčení o zkoušce). Žádný jiný občan ČR, než ten který má zavedený zbrojní průkaz, není v bázi cílového software evidován. S MZP souvisí Žádost formulář (ŽF) o vydání nového ZP, Lékařské vysvědčení (LV) o způsobilosti používat a vlastnit zbraň dané kategorie, Vysvědčení o zkoušce (VZ) ze znalosti a manipulaci se zbraní dané kategorie/-í a aktuální fotografii (viz dále ZP). ZP 2. Zbrojní průkaz (ZP) je samostatná datová entita se strukturou ZP = (eviden. číslo, platnost do, ID majitele ZP, kategorie zbraní: A F, kdo vydal). Atributy jméno a příjmení, rodné číslo, fotografie a trvalé bydliště, které jsou na kartičce zbrojního průkazu vytištěny, jsou přebírány od MZP. 3. Nový ZP se tiskne speciálním strojem a je neprodyšně zataven (nelze do něj nic doplňovat). 4. Každý ZP je evidován samostatně, podobně jako MZP. 5. Osoba vlastní pouze jeden ZP a nemusí vlastnit žádné zbraně. 6. K vydání nového ZP je nutno předložit několik dokumentů: a. Žádost formulář (ŽF) o vydání nového ZP. b. Lékařské vysvědčení (LV) o způsobilosti používat a vlastnit zbraň dané kategorie. c. Vysvědčení o zkoušce (VZ) ze znalosti a manipulaci se zbraní dané kategorie/-í. d. Aktuální fotografii. -1-

268 Zbraň 7. Se záznamem nového ZP se musí vytvořit nový záznam pro MZP. 8. ZP je možno odebrat (pochopitelně potom i vlastněné zbraně) na základě několika skutečností (zhoršení zdravotního stavu, odsouzení k závažnému nepodmíněnému trestu, nepřípustné použití zbraně,... ). 9. Může dojít k situaci, že ZP je nutno aktualizovat (změna vzhledu, změna příjmení, změna bydliště, rodného čísla, změna oprávnění na kategorie zbraní). Pak se musí aktuální ZP zničit a vyrobit nový, editovaný. Proto se může evidovat i pořadí vydání nového ZP. 10. Řízení informace v uvedených procesech je dovoleno jen administrátorovi okresního velitelství policie ČR, tj. stanovenému důstojníkovi na policejním velitelství. 11. Každá zbraň musí být důsledně evidována. Relevantní informace o samotné zbrani, se získají z prodejního dokumentu Prodejka zbraně (PROZ), kde je uvedeno: PROZ = (název zbraně, výrobní číslo zbraně, druh zbraně, ráže, výrobce, kategorie zbraně (A, B, ), datum výroby, datum prodeje, ID majitele zbraně). K Prodejce zbraně je přiložena Výstupní kontrola zbraně (VKZ) z výrobního podniku, která obsahuje identifikaci osoby, která kontrolu provedla a rovněž terč s výsledkem střelby tří ran na vzdálenost 25 metrů. Tedy eviduje se následující informace: VKZ = (ID kontroly, výrobní číslo zbraně, druh zbraně, ráže, ID kontrolora, výsledek kontroly). Entita Zbraň je velmi důležitou datovou entitou systému Správa soukromých zbraní v ČR a rozhodující je výrobní číslo zbraně. Evidence zbraně obsahuje následující informaci: ZBRAN = (výrobní číslo zbraně, ID majitele ZP, datum nabytí zbraně, stav zbraně). V doméně může dojít k situaci, že zbraň je ztracena, nebo ukradena. V každém případě je majitel zbraně povinen situaci hlásit. Informace o ztrátě je vedena v entitě ZTRÁTA = (ID ztráty, výr. č. zbraně, ID majitele, datum hlášení, protokol) Vzhledem k této situaci musí být o zbrani důsledně veden její stav. PZ 12. Ke každé zbrani se musí vytvořit Průkaz zbraně (PZ). Je v něm několik relevantních údajů z Prodejky zbraně (PRZ). Tedy PZ = (eviden. číslo, druh zbraně, výrobce, vzor, ráže, výrobní číslo zbraně, kategorie, ID majitele, registrace u, datum registrace). Průkaz zbraně je tedy vázán na majitele zbraně, přes ID majitele zbraně, a je platný pro celou ČR. Na PZ je informace o majiteli vytištěna (jméno, příjmení a rodné číslo) 13. Každý Majitel zbraně musí být evidován a identifikován (včetně fotografie) a určeno místo jeho pobytu. Mimo jiné musí mít Zbrojní průkaz. 14. Každá zbraň musí být pravidelně předkládána ke kontrole a kontrola musí být evidována. Tedy o Kontrole zbraně by měla být vedena následující informace: KZ = (ID kontroly, datum kontroly, druh zbraně, výrobní číslo zbraně, výsledek kontroly). -2-

269 2 Fáze ZAHÁJENÍ 2.1 Pracovní postup PLÁNOVÁNÍ Tento pracovní postup zde nebudeme realizovat celý, protože souvisí s ustanovením softwarového projektu. Zejména nebudeme plánovat iterace, hodnotit rizika, hodnotit obchodní případ. Z tzv. PRVOTNÍCH PŘÍPADŮ ovšem realizujeme následující: Kontextová analýza problémové domény Analýza klientů cílového software Prvotní přístup k architektuře cílového software Prvotní přístup k prostředí nasazení Prvotní přístup k vývojovému prostředí KONTEXTOVÁ ANALÝZA PROBLÉMOVÉ DOMÉNY Nakreslíme-li SSZ v ČR jako černou skříňku a zaměříme se na okolí, potom můžeme nakreslit následující schéma. Doména SSZ v ČR je specifickou doménou s malým počtem prvků v okolí (zbrojní technici, majitelé ZP, administrátoři), je to dáno její povahou. Zbrojní technici Majitelé ZP Administrátoři Výrobní kontroloři SSZ v ČR Doména je součást policejního ředitelství, které má několik organizačních jednotek, věnujících se problematice SSZ v ČR. Zajímavější je procesní struktura domény SSZ v ČR. V ní můžeme rozeznat i více množin procesů než uvádíme v následujícím obrázku. Uvedené množiny ovšem považujme za stěžejní. Správa klientů Správa MZP Správa ZP Statistiky a vyhledávání SSZ v ČR Poznámka: Vzhledem k požadavku dalece širšího sledování problematiky zbraní na teritoriu ČR bychom mohli přidat další skupiny procesů: Správa samoobsluhy Správa ztracených zbraní Správa zbraní odložených na policii Správa výrobních kontrolorů. Správa zbraní a PZ Jen tato skupina bude dále modelována -3-

270 ANALÝZA KLIENTŮ CÍLOVÉHO SOFTWARE Výrobní kontrolor, Majitelé ZP (vlastní/nevlastní zbraně), Administrátoři a Zbrojní technici potom působí jako příjemci informace a zdroje informací. Někteří z nich mají ještě širší práva, např. spouštět procesy v doméně SSZ v ČR. Majitelé ZP sice mohou číst informace o sobě, o svých zbraních, ale nemají právo ji měnit. Nemají právo spouštět jiný proces než ten, který jim dá jim povolené informace. Zbrojní technici přijímají požadavek ke kontrole zbraně a mají právo k zápisu výsledku do báze dat. Mohou tedy spustit proces pro zápis výsledku kontroly. Jiné procesy spouštět nemohou. Výrobní kontroloři vyhotovují záznam o přezkoušení právě vyrobené zbraně, který se přiloží k Prodejce zbraně. Kardinální roli má administrátor. Jeho práva se sice týkají daného okresu, ale může mu být nadřízeným krajským administrátorem povoleno dočasné právo i pro jiný okres, nebo na celé území ČR. Hlavní administrátor je na policejním ředitelství ČR. VIZE O CÍLOVÉM SOFTWARE Cílový software pro SSZ v ČR bude uložen na serveru informační infrastruktury policejního ředitelství ČR v Praze. Zde je rovněž hlavní administrátor, který deleguje administrátory pro kraje a ti pro jednotlivé okresy. Takto určení administrátoři mají práva, kompetence a povinnosti jen na základě územního členění. Distribuce dat mezi cílovým softwarem a klienty je realizována internetem se stanovenou ochranou (aplikační kryptografie). Přímý přístup k cílovému software má jen hlavní administrátor. Cílový software bude bazicky na architektuře Klient-server a vrcholově na architektuře dynamických komponent. Vedle toho bude cílový software typu data-driven přes vytvořenou bázi dat. PRVOTNÍ PŘÍSTUP K ARCHITEKTUŘE CÍLOVÉHO SOFTWARE. Začátek úvah o logické architektuře cílového software vychází z členění fyzické problémové domény na skupiny, nebo množiny procesů. Procesní podstata problémové domény je tedy pro logickou architekturu rozhodující. Pro naši doménu SSZ v ČR má schéma Prvotního pohledu na problémovou doménu následující tvar: Správa soukromých zbraní na teritoriu ČR Statistiky a vyhledávání Správa MZP a ZP Správa ZP Správa klientů Ze znalosti funkcionality problémové domény Evidence soukromých zbraní v ČR můžeme poznat následující skupiny/podsystémy procesů a souvislosti mezi nimi (oddělili jsme Správu MZP od Správy ZP). Vzniklo pět podsystémů. 1. Správa zbraní a Průkazů zbraní. 2. Správa majitelů zbraní. 3. Správa ZP. 4. Správa klientů. 5. Statistiky a vyhledávání. Správa zbraní a PZ -4-

271 <<Podsystém>> Správa zbraní a průkazů zbraní <<využívá>>. 7 <<Podsystém>> Statistiky a vyhledávání <<využívá>>. 2 4 <<využívá>>. 1 <<využívá>>. <<Podsystém>> Správa majitelů zbraní <<využívá>>. 3 <<Podsystém>> 5 Správa zbrojních <<využívá>> průkazů <<využívá>>.. <<využívá>>. 6 <<Podsystém>> Správa klientů Pomocí předchozího schématu jsme sestavili Model hrubé funkční závislosti v problémové doméně se závislostní relací <<využívá>>. Dostáváme tak následující schéma: Sestavili jsme schematický Přehled architektury, který je složen z Prvotního schématu logické architektury a jeho deskripce: a) Prvotní schéma logické architektury pro doménu SSZ v ČR: Komunikace s klienty Správa výstupních sestav Správa zbraní a průkazů zbraní (ZP) Správa statistiky a vyhledávání BD Správa majitelů zbraní Správa zbrojních průkazů (ZP) Správa klientů Uvedené schéma můžeme nazvat schématem podsystémů, nebo modulů cílového software. Budeme používat termín podsystémy. Schéma je opravdu prvotním schématem, protože je oproštěno od zobrazení jakéhokoliv interního života každého z podsystémů a rovněž oproštěno od zobrazení vzájemného, externího života podsystémů. Pokud bychom jen stručně načrtli vizi vývoje cílového software, v souvislosti s uvedeným schématem, tak je nutno říci následující: 1. Procesy, tedy požadavky komputerizace budou rozděleny do jednotlivých podsystémů, podle jejich sémantiky. -5-

272 2. Jestli mapujeme požadavky na případy užití, tak vzniklé případy užití padnou do stejného podsystému jako jejich vzor-požadavek. 3. Jestli nalezneme realizaci případu užití pomocí skupiny svázaných analytických tříd, tak tyto třídy padnou do stejného podsystému, v kterém je vzorový případ užití. 4. Jestliže mapujeme každý z podsystémů do skupiny jeho komponent, přechází prvotní schéma pro logickou architekturu do složitého komponentového modelu. a) Systém potřebuje centrální řízení komunikace s klienty, které umožní nejen autentizaci a autorizaci, ale i organizaci plnění jejich požadavků. Klienti mohou spouštět jednotlivé podsystémy. Veškerá informace podsystémů je uložena v bázi dat. Podsystém Řízení statistiky nebude využívat ostatní podsystémy (jak je ve funkčním modelu), ale jen jejich data z báze dat-bd. Podsystém Řízení výstupních sestav bude organizovat výstup podle připravených výstupních šablon v podsystému Řízení statistiky. PRVOTNÍ PŘÍSTUP K PROSTŘEDÍ NASAZENÍ. Cílový software, jehož relevantní vlastností by měla být jeho komponentová dynamická architektura, může být vyvíjen v jisté softwarové firmě na zakázku. Rozhodující pro nasazení cílového software je způsob jeho poskytnutí zákazníkovi, tj. Policejnímu ředitelství ČR. Je několik možností: 1. Cílový software je Policejnímu ředitelství ČR jednorázově prodán s celoživotní licencí. Vzhledem k možnostem informační infrastruktury Policejního ředitelství ČR, je cílový software buď součástí IS, nebo figuruje samostatně, jako komponentový celek, mimo IS. Takový celek může být nainstalován na jednom ze serverů, nebo je rozložen na více serverů, což je dáno jeho fyzickým nasazením. Potřebné úpravy (modifikace, modernizace) software musí být s produkční firmou řešeno pomocí samostatných smluv. 1. Cílový software je Policejnímu ředitelství ČR poskytován v nájmu (podle nájemního modelu produkční firmy) a není na informační infrastruktuře Policejního ředitelství ČR fyzicky nasazen. Všechny přístupy klientů jsou produkční firmou zabezpečeny. Produkční firma potom, v rámci nájmu, zohlední modernizační požadavky Policejního ředitelství ČR. PRVOTNÍ PŘÍSTUP K POUŽITÍ VÝVOJOVÉHO PROSTŘEDÍ. Jistě je možno najít mnoho vývojových prostředí pro cílový software domény SSZ v ČR. Berme však ohled na plánovanou dynamickou komponentovou architekturu. Zde bychom mohli volit vývojové prostředí jazyka Java, nebo vývojové prostředí Visual Studio. Oba dva vývojové systémy jsou podporovány mohutným Framework systémem se vzorovým systémem správy dynamických komponent. Obě prostředí rovněž disponují progresivním způsobem práce s bází dat a realizací bazické architektury Klient-server. 2.2 Pracovní postup POŽADAVKY Zkusme teď uvést návrh obsazení jednotlivých množin procesů konkrétními procesy. Tyto procesy budou sloužit jako požadavky policie ČR pro komputerizaci SSZ v ČR. -6-

273 Správa majitelů ZP. o o o Správa ZP. o o o Zavedení nového MZP Modifikace informací ohledně MZP Odstranění MZP Vydání nového ZP Odebrání ZP Editace stávajícího ZP Procesy v jednotlivých skupinách jistě nevyčerpávají všechny možnosti. Další procesy mohou být průběžně doplňovány. Správa zbraní a průkazů zbraní (PZ). o o o o o o Zavedení zbraně. Vytvoření průkazu zbraně. Zrušení zbraně, zrušení PZ. Převedení zbraně na jiného vlastníka. Předložení zbraně ke kontrole. Hlášení o ztrátě zbraně. Vyhledávání a statistiky. o o o Statistiky ohledně majitelů ZP. Statistiky ohledně zbraní. Statistiky ohledně výrobců zbraní. Správa klientů. o o Řízení krajských a okresních administrátorů. Nastavení práv, povinností a kompetencí majitelů ZP. Jako silné informační entity domény SSZ v ČR mohou vystupovat (viz 1.1): Zbrojní průkaz - ZP Majitel zbrojního průkazu - MZP Zbraň Průkaz zbraně - PZ Žádost, formulář- ŽF, k vydání nového zbrojního průkazu Lékařské vysvědčení - LV Vysvědčení o zkoušce - VZ Prodejka zbraně - PROZ Výstupní kontrola zbraně - VKZ Pravidelná kontrola zbraně KZ Ztráta zbraně - ZTRÁTA -7-

274 SPECIFIKACE POŽADAVKŮ Všechny procesy, uvedené v předchozím procesním obsazení jednotlivých skupin, považujeme za funkční požadavky na cílový software. Krok: TAXONOMIE POŽADAVKŮ: Funkční požadavky: Zavedení nového MZP Modifikace informací ohledně MZP Odstranění MZP Vydání nového ZP Odebrání ZP Editace stávajícího ZP Zavedení zbraně. Vytvoření průkazu zbraně. Zrušení zbraně, zrušení PZ. Převedení zbraně na jiného vlastníka. Předložení zbraně ke kontrole. Hlášení o ztrátě zbraně. Statistiky ohledně majitelů ZP. Statistiky ohledně zbraní. Statistiky ohledně výrobců zbraní. Řízení krajských a okresních administrátorů. Nastavení práv, povinností a kompetencí majitelů ZP. Nefunkční požadavky: Softwarové: Registrace Přihlášení se Odhlášení se Ostatní požadavky: Změna účtu se nepovoluje! Ochrana informace uložené v bázi dat cílového software (aplikační kryptografie) a ochrana přenosů po internetu. Tvorbu klientských (majitelů ZP) účtů řídí výlučně lokální okresní administrátor. Pro krajské administrátory řídí tvorbu administrátorských účtů hlavní administrátor. Krajský administrátor řídí účty pro podřízené okresní administrátory. Vzhledem k tomu, že jsou procesy rozdělené do pěti skupin/množin, není možné, abychom se najednou zabývali všemi skupinami. Je-li pouze jeden řešitelský tým, tak musí postupovat po ukončení informačního modelování podle metodiky UP od jedné skupiny ke druhé. Chceme-li paralelní vývoj, tak zavedeme několik týmů a každý z nich bude informačně modelovat jen určené skupiny procesů. Krok: Stručná deskripce požadavků všech procesních skupin Informační modelování vyžaduje dobré znalosti o procesech domény SSZ v ČR po jednotlivých skupinách. Vzhledem ke značnému rozsahu skupin a jejich procesů se budeme orientovat jen na požadavky jedné vybrané skupiny Správa zbraní a PZ: Popis: Nová zbraň se zavádí v procesu Zavedení zbraně. Jde nejen o vytvoření nového záznamu o zbrani, ale rovněž nového Průkazu zbraně-pz. Dále se musí zabezpečit asociace zbraně na její průkaz a rovněž na majitele Zbrojního průkazu-zp. Zrušení zbraně musí být spojeno se zrušením instance zbraně a Průkazu zbraně a tím zabezpečit rovněž zrušení asociace zbraně na majitele Zbrojního průkazu. Proces Převedení zbraně na jiného vlastníka požaduje zrušit asociaci zbraně na původního Majitele ZP, který zbraň prodává, a přepsat asociaci zbraně na Majitele ZP, který zbraň kupuje. Je nutné zrušit stávající Průkaz zbraně a vytvořit nový, protože průkaz je vázán nejen na zbraň, která se nemění, ale rovněž na vlastníka. -8-

275 Předložení zbraně ke kontrole se zapíše datum a výsledek kontroly jako nová instance kontroly. Hlášení o ztrátě zbraně se musí nejdříve evidovat jako instance ztráty, zbraň se z evidence nevyřadí, ovšem její nový stav je ztracena. Na základě stručného popisu skupiny Správa zbraní a PZ vyřešíme jako vzor dva následující úkoly: 1. Mapujeme požadavky skupiny Správa zbraní a PZ na případy užití a využijeme hrubého popisu požadavků. Vytvoříme pro skupinu Správa zbraní a PZ jediný balíček případů užití a nakreslíme jeho diagram a aktéra. Využijeme pokročilé kreslení diagramů případů užití. Pokud je to nutné, doplníme balíček případy užití relacemi <<include >> a <<extend>>. 2. Dále si vybereme jen případ užití Převedení zbraně na jiného vlastníka, pro který vytvoříme detailní tabulku s hlavním scénářem. Hlavní scénář zakreslíme aktivitním diagramem. Načrtneme plavecké dráhy (budou-li potřebné) a znázorníme tok objektů-instancí (pokud instance vznikají). 1. Mapování: Za vhodné mapování požadavků skupiny Správa zbraní a PZ můžeme považovat zobrazení 1:1, které je dáno následující tabulkou, v níž přeneseme názvy požadavků na vzniklé případy užití. Požadavky Zavedení zbraně Vytvoření Průkazu zbraně Zrušení zbraně Převedení zbraně na jiného vlastníka Předložení zbraně ke kontrole Hlášení o ztrátě zbraně Případy užití Zavedení zbraně Vytvoření Průkazu zbraně Zrušení zbraně Převedení zbraně na jiného vlastníka Předložení zbraně ke kontrole Hlášení o ztrátě zbraně Chápejme vzniklé případy užití jako balíček (sémantické vazby případů užití jsou velmi silné). Pokusíme se proto vytvořit balíček případů užití, přičemž jsme zvážili doplnění dalšími případy užití, které jsou nezbytně nutné k životu celého balíčku (Vyhledání zbraně, Zrušení PZ). Jsou ovšem další pomocné případy užití, např. Vyhledání MZP, Vyhledání ZP, Vyhledání PZ, Odebrání zbraně, Přidání zbraně, Těmito případy užití můžeme diagram balíčku ještě zjemnit. Správa zbraní a PZ Ztráta zbraně <<include> > Vyhledání zbraně Administrátor Zavedení zbraně Zrušení zbraně <<extend>> <<include>> << extend >> Vytvoření PZ Vyhledání zbraně Zrušení PZ Zbrojní technik Převedení zbraně na jiného vlastníka <<extend>> Vytvoření PZ Předložení zbraně ke kontrole -9-

276 Co lze k vytvořenému balíčku dodat? - je pro celou skupinu Správa zbraní a PZ, - jisto-jistě neobsahuje všechny potřebné případy užití, je to jen první nástin, ale zatím dostatečný. 2. Detailní scénář: Teď bychom měli vytvořit detailní scénáře pro všechny případy užití z našeho balíčku. Stačí ovšem, když si vybereme jeden případ užití. Pro ostatní bychom postupovali obdobně. Jako vzorový si vybereme jen případ Převedení zbraně na jiného vlastníka. Není to příliš komplikovaný případ užití. Zajímavé je to, že se netýká změn Zbrojního průkazu, ale týká se změny Průkazu zbraně (je na něm nový majitel zbraně). Změní se tedy asociace mezi zbraní a jejím novým průkazem. Jde v podstatě jen o změnu asociace mezi entitou Majitel zbrojního průkazu a entitou Zbraň a to jak pro prodávajícího, tak i kupujícího. Vstupní podmínkou případu užití je existence obou platných ZP (prodávajícího a kupujícího), PZ a platná kontrola prodávané zbraně. Následující tabulka je návrh detailizace případu užití Převedení zbraně na jiného vlastníka. Do podrobné tabulky případu užití Převedení zbraně na jiného vlastníka prozatím nezavedeme alternativní scénáře, ačkoliv obecně pro tento případ užití existují. Prvním z nich je alternativní scénář pro situaci, kdy jsou sice prodávající a kupující ze stejného kraje, ale z různých okresů. Potom musí lokální administrátor žádat krajského administrátora o povolení provést operaci mezi okresy. Jisto-jistě existují pro daný případ užití další specifické situace, k nimž je nutno napsat alternativní scénáře, ale na tyto situace jsme zatím nepřišli. Případ užití: Převedení zbraně na jiného vlastníka ID: 6 Stručný popis: Systém umožní převést danou zbraň od jednoho majitele na jiného. Hlavní aktéři: Administrátor policejní důstojník Vedlejší aktéři: Žádní Vstupní podmínky: Platné ZP prodávajícího a kupujícího, platný PZ prodávané zbraně a její kontroly. Oba ZP jsou evidované v lokálním okrese Hlavní scénář: 1. Zadej výrobní číslo zbraně potom evidenční číslo PZ. 2. Je-li zbraň v pořádku a rovněž v pořádku její průkaz, zjisti kategorii zbraně, majitele a pokračuj na bodu 3. Jestliže nejsou v pořádku (zbraň: není evidovaná v systému, má neplatnou kontrolu, PZ: není evidován v systému), tak se oznámí závady a ukonči se případ užití. 3. Zadej evidenční čísla obou ZP, prodávajícího a kupujícího. Jsou-li oba ZP v pořádku (jsou evidované v systému), tak pamatuj identifikaci obou majitelů, jejich kategorie zbraní a jdi na bodu 4. Jinak udělej oznámení chyby a ukonči případ užití. 4. Je-li vše v pořádku (prodávající je evidovaným majitelem zbraně, zbraň má platnou kontrolu, kategorie prodávané zbraně je v souladu s kategoriemi na ZP prodávajícího a kupujícího), tak zruš asociaci dané zbraně (podle výrobního -10-

277 čísla zbraně) na majitele, tj. prodávajícího. 5. Zaveď asociaci zbraně (podle výrobního čísla) na kupujícího. 6. Zruš původní PZ a vytvoř nový s indikací nového majitele. 7. Podej zprávu o provedení případu užití a dokumentuj výpisy nové asociace prodávané zbraně. Výstupní podmínky: Žádné Alternativní scénáře: Nejsou zavedeny Relace aktérů k případu užití: Aktér, lokální okresní administrátor se k cílovému software přihlašuje (musí zadat své uživatelské jméno a heslo) a případ užití spouští. Aktivitní diagram: K danému hlavnímu scénáři patří následující aktivitní diagram. Určíme v něm pouze dvě odpovědnosti za aktivity v případu užití, které jsou dány Systémem cílového software a Administrátorem. V průběhu případu užití dochází ke vzniku nové instance PZ, dochází rovněž k přepisu atributů jedné instance datové entity Zbraň. Systém Administrátor Zadej: výr. číslo zbraně, evidenční číslo PZ závady Oznámení o nedostatcích v evidenci a kontrole Zadej evidenční čísla ZP prodávajícího a kupujícího evidence? kategorie? závady Oznam závad Zruš asociaci zbraně na prodávajícího. Zaveď asociaci zbraně na kupujícího. Vytvoř nový PZ s indikací nového majitele. Dokumentuj jen správné provedení případu užití pomocí výpisu nové asociace zbraně na majitele -11-

278 SCÉNÁŘ FÁZE ROZPRACOVÁNÍ NAD DOMÉNOU SSZ V ČR 1 Fáze ROZPRACOVÁNÍ 1.1 Pracovní postup Analýza realizace případů užití Jelikož jsme se ukázkově ve fázi ZAHÁJENÍ soustředili na skupinu procesů Správa zbraní a PZ, budeme pokračovat v modelování realizace případu užití Převedení zbraně na jiného vlastníka. Kvůli připomenutí tohoto případu užití zde zveřejníme jeho specifikaci, tj. hlavní scénář a k němu náležící Aktivitní diagram. Případ užití: Převedení zbraně na jiného vlastníka ID: 6 Stručný popis: Systém umožní převést danou zbraň od jednoho majitele na jiného. Hlavní aktéři: Administrátor policejní důstojník Vedlejší aktéři: Žádní Vstupní podmínky: Platné ZP prodávajícího a kupujícího, platný PZ prodávané zbraně a její kontroly. Oba ZP jsou evidované v lokálním okrese Hlavní scénář: 1. Zadej výrobní číslo zbraně potom evidenční číslo PZ. 2. Je-li zbraň v pořádku a rovněž v pořádku její průkaz, zjisti kategorii zbraně, majitele a pokračuj na bodu 3. Jestliže nejsou v pořádku (zbraň: není evidovaná v systému, má neplatnou kontrolu, PZ: není evidován v systému), tak se oznámí závady a ukončí se případ užití. 3. Zadej evidenční čísla obou ZP, prodávajícího a kupujícího. Jsou-li oba ZP v pořádku (jsou evidované v systému), tak pamatuj identifikaci obou majitelů, jejich kategorie zbraní a jdi na bodu 4. Jinak udělej oznámení chyby a ukonči případ užití. 4. Je-li vše v pořádku (prodávající je evidovaným majitelem zbraně, zbraň má platnou kontrolu, kategorie prodávané zbraně je v souladu s kategoriemi na ZP prodávajícího a kupujícího), tak zruš asociaci dané zbraně (podle výrobního čísla zbraně) na majitele, tj. prodávajícího. 5. Zaveď asociaci zbraně (podle výrobního čísla) na kupujícího. 6. Zruš původní PZ a vytvoř nový s indikací nového majitele. 7. Podej zprávu o provedení případu užití a dokumentuj výpisy nové asociace prodávané zbraně. Výstupní podmínky: -1-

279 Žádné Alternativní scénáře: Nejsou zavedeny Relace aktérů k případu užití: Aktér, lokální okresní administrátor se k cílovému software přihlašuje (musí zadat své uživatelské jméno a heslo) a případ užití spouští. Systém Administrátor Zadej: výr. číslo zbraně, evidenční číslo PZ závady Oznámení o nedostatcích v evidenci a kontrole Zadej evidenční čísla ZP prodávajícího a kupujícího evidence? kategorie? závady Oznam závad Zruš asociaci zbraně na prodávajícího. Zaveď asociaci zbraně na kupujícího. Vytvoř nový PZ s indikací nového majitele. Dokumentuj jen správné provedení případu užití pomocí výpisu nové asociace zbraně na majitele Krok: Hledání analytických tříd (jejich atributů a operací). V hledání analytických tříd začínáme pozorným čtením Hlavního scénáře v detailní tabulce případu užití Převedení zbraně na jiného vlastníka. Současně sledujeme aktivitní diagram pro zmíněný scénář. V průběhu čtení hlavního scénáře přicházíme na to, že aktivity případu užití se točí kolem majitelů zbrojních průkazů, jejich zbrojních průkazů, potom předložené zbraně, jejího průkazu, její kontroly. Tedy entity MZP, ZP, ZBRAŇ, PZ a KZ můžeme považovat za kandidáty na analytické třídy. Jestliže přečteme hlavní scénář znovu, tak nenajdeme jiné významné entity pro kandidáty tříd. Prohlásíme tedy současné kandidáty za analytické třídy případu užití. -2-1

280 Hlavní scénář čteme znovu a pokusíme se jednotlivým třídám přidat potřebné atributy. Setkáme se pouze s atributy výr. číslo zbraně, evid. číslo PZ a evid. čísla ZP obou přítomných. Další atributy jednotlivým třídám nalezneme v popisu problémové domény. Nakreslíme teď v souladu se sémantikou problémové domény SSZ v ČR asociace mezi třídami. Známe-li dobře doménu, můžeme přijít k následujícímu diagramu. MZP 1 1 ZP 1 KZ 1..* 0..* 1 Zbraň 1 1 PZ Jelikož se na realizaci případu užití Převedení zbraně na jiného vlastníka podílí pouze třídy Zbraň, ZP, MZP, PZ a KZ, tak můžeme využít atributy, které byly k datovým entitám přiřazeny již v popisu problémové domény SSZ v ČR. Provedeme pouze kontrolu, jestli tyto atributy dostačují pro případ Převedení zbraně na jiného vlastníka. To se udělá tak, že si opět čteme hlavní scénář a pozorně sledujeme, co za informaci potřebujeme o MZP, ZP, PZ, KZ a Zbrani. Vyjdou nám následující atributy. MZP = (ID majitele ZP, jméno a příjmení, rodné číslo, fotografie, trvalé bydliště, ID žádosti, ID lékařského vysvědčení, ID vysvědčení o zkoušce) ZP = (eviden. číslo, platnost do, ID majitele ZP, oprávnění na kategorie zbraní: A F, kdo vydal ZP). Atributy jméno a příjmení, rodné číslo, fotografie a trvalé bydliště, které jsou na ZP vytištěny, jsou přebírány od MZP. PZ = (eviden. číslo, druh zbraně, výrobce, vzor, ráže, výrobní číslo zbraně, kategorie, ID majitele ZP, registrace u, datum registrace). ZBRAN = (výrobní číslo zbraně, ID majitele ZP, datum nabytí zbraně) KZ = ( ID kontroly, datum kontroly, druh zbraně, výrobní číslo zbraně, výsledek kontroly). Provedením předešlého postupu zjistíme, že informace v atributech je dostatečná. Prvotní analytický návrh operací: Opět čteme pozorně hlavní scénář a sepíšeme si, jaké provedení operací od tříd potřebujeme. Především potřebujeme prověřit příchozí, jsou-li evidováni a mají-li platné ZP. Potom musíme prověřit zbraň je-li evidována Pro MZP... nalezení majitele ZP, kontrola s občankou, získání ID majitele. (dejmzp) Pro ZP... nalezení konkrétního ZP podle jeho ev. čísla a vyčtení informace o majiteli (hledejzp, vyrobitzp) Pro Zbraň... nalezení zbraně podle jejího výr. čísla, zjistit majitele, datum nabytí a platnost kontroly (dejzbraň, přepišzbraň, DejKZ) Pro PZ... potvrzení majitele a potom přepis na jiného majitele (hledejpz, přepišpz) -3-

281 Počítáme s tím, že nový PZ se vyrábí na speciálním stroji, který je řízen cílovým software domény SSZ v ČR. Krok: Analytické třídy (atributy+operace) případu užití grafická notace Převedení zbraně na jiného vlastníka Musíme si uvědomit, že je předložená zbraň a na ní výrobní číslo, které můžeme přečíst. Dále je předložen Průkaz zbraně. Lze okamžitě zjistit, že průkaz patří/nepatří k předložené zbrani. Jelikož systém správy soukromých zbraní v ČR se zavádí postupně, může se stát, že některé zbraně, jejich průkazy a zbrojní průkazy nejsou v systému elektronicky evidovány. Nejdříve prověříme existenci evidence zbraně a jejího průkazu v bázi dat, zjistíme kategorii zbraně a platnost kontroly. Pokud evidence nejsou, tak je administrátor musí provést. Neplatnost kontroly zbraně ukončuje případ užití. Zbraň se musí prohlédnout technikem a výsledek kontroly zapíše technik do systému. Jen zbraň s platnou kontrolou se může prodávat. Dále jsou předloženy dva zbrojní průkazy, prodávajícího a kupujícího. Snadno se zjistí, že nejsou falešné a časově platné. Prověříme jejich evidenci v systému. Pokud v systému nejsou, případ užití končí. Zavedení se provede samostatně. Dále je nutno kategorii předložené zbraně porovnat s kategoriemi na obou Zbrojních průkazech. Jsouli v souladu, je možné provést převod zbraně prodávajícího na kupujícího. Předpokládejme, že vše je evidováno. Jinak se operace pro evidence dají snadno doplnit, ale případ užití je nejdříve ukončen, protože vyžaduje vše evidované v systému. Na základě potřebných operací můžeme opět prověřit nutnost atributů. Každá třída by měla mít identifikační atribut, který dodá každé generované instance jeho jedinečnou hodnotu. Ostatní atributy navrhneme podle vazeb analytických tříd. V návrhu atributů musíme projevit svou analytickou prozíravost (tak např. stanovíme atribut stav). Je dobré, když dbáme na to, aby analytický návrh atributů zahrnoval je ty atributy, které jsou potřebné pro jednotlivé operace analytických tříd. MZP ZP Zbraň PZ ID majitele ZP Příjmení jméno Rodné číslo Fotografie Trvalé bydliště dejmzp KZ ID kontroly Datum kontroly Druh zbraně Výrobní číslo zbraně Výsledek kontroly dejkz Evid. číslo platnost do ID majitele ZP Kategorie zbraní Kdo vydal hledejzp vyrobitzp Výrobní číslo zbraně ID majitele ZP Datum nabytí zbraně stav dejzbraň přepišzbraň Evid. číslo PZ Druh zbraně Výrobce Vzor Ráže Výrobní číslo zbraně Kategorie ID majitele ZP Registrace u Datum registrace hledejpz přepišpz vyrobitpz Možná je i lepší způsob realizace atributové sestavy použitých tříd. Např. nelíbí se mi, že ID majitele ZP je až na čtyřech místech v nalezených třídách. -4-

282 Protože mnoho tříd mívá stavový charakter, tak jako ukázku rozebereme třídu Zbraň a nakreslíme její stavový diagram. Krok: Stavový diagram třídy Zbraň Za velmi vhodnou vzorovou třídu, jejíž instance procházejí jistými relevantními stavy, můžeme považovat např. třídu Zbraň. Toto tvrzení je nutné zvážit. Zavedení stavu instancí třídy Zbraň má význam jen tehdy, když existují případy užití, v nichž je stav využíván a je na něj brán ohled. V doméně SSZ v ČR takové případy užití existují. Následující stavy můžeme k třídě Zbraň bez problémů přiřadit. 3. Je v prodeji... Zbraň byla vyrobena a je vybavena výstupní kontrolou (VKZ). Je zavedena a používána... Byl uskutečněn prodej. Zbraň je doplněna o prodejku (PROZ). Do V souvislosti s třídou Zbraň můžeme tohoto navrhnout stavu se musí např. dostat tyto stavy: po jisté době od prodeje (měřeno počten dnů). Je v kontrole... Je to stav, v kterém zbraň setrvá na policii krátkou dobu. Je uložena na policii... Majitel se vzdal vlastnictví a zbraň je na policii a může být opět vrácena do prodeje. Je zrušena... Zbraň je odevzdána na policii a po kontrole je vyhlášena další nepoužitelnost zbraně. Je ztracena/ukradena... Zbraň není schopen její majitel předložit a hlásí ztrátu. Je nalezena... Nález je nutno zaznamenat a předložit zbraň ke kontrole. Je možné sestrojit následující stavový diagram: 8 V prodeji Je na policii uložena 7 Zrušena Zavedena a používána V kontrole 12 2 Je nalezena 9 10 Je ztracena/ukradena 11 Význam označení ve tvaru událost/operace 1... Zbraň je prodána/zavedení zbraně Není žádná závažná okolnost (negativní výsledek technické kontroly, odevzdání zbraně na policii), která by narušila užívání zbraně Zbraň je dobrovolně odevzdaná na policii/realizuj odevzdání Zbraň je předána ke kontrole/zkontroluj zbraň nebo dejkz Je pozitivní výsledek kontroly/zaznamenej kontrolu Je negativní výsledek kontroly/realizuj vyřazení zbraně Zbraň je zastaralá/ Realizuj úplné vyřazení zbraně O zbraň je zájem/vybav zbraň pro prodej Zbraň je ztracena-ukradena/realizuj dočasné vyřazení zbraně Zbraň je stále ve stavu ztracena/ukradena Zbraň je nalezena/ Zaznamenej nalezení zbraně Po nalezení je zbraň předložena kontrole/ Zkontroluj zbraň nebo dejkz. -5-

283 Krok: Tvorba interaktivního diagramu pro případ užití (Sekvenční diagram) Převedení zbraně na jiného vlastníka. Jak jsme již naznačili, realizace případu užití Převedení zbraně na jiného vlastníka mají na starosti jen třídy Zbraň, KZ, PZ, KZ a ZP. Jde teď jen o spolupráci tříd, aby pomocí svých operací, které zpracovávají jejich atributy, zabezpečily realizaci celého případu užití. Příklad případu užití bude spuštěn a řízen administrátorem. Můžeme tedy zvolit velmi jednoduchou strategii, která pro komunikaci s ostatními instancemi používá jen administrátora. Tato strategie je uvedena na následujícím obrázku. Jsou ovšem možné i jiné strategie. Sekvenční diagram realizace případu užití Převedení zbraně na jiného vlastníka: Administrátor MZP Zbraň KZ PZ ZP dejmzp dejzbraň dejkz hledejpz hledejzp majitele hledejzp kupujícího přepišzbraň přepišpz Tím jsme udělali to, co je pro realizaci případu užití podstatné (analytické třídy a sekvenční diagram). 1.2 Pracovní postup NÁVRH V analytickém modelu tříd a podobně v komunikačním a sekvenčním diagramu nebyly žádné detaily. V pracovním postupu Návrh se vše musí převést do podoby vhodné k programování. Za detaily návrhových tříd považujeme popis všech jejich atributů a operací, podobně jako v objektovém programovacím jazyku. Tedy notace operace musí mít vstupní a výstupní parametry. Krok: Sestavení návrhového diagramu analytických tříd pro případ Převedení zbraně na jiného vlastníka. V tomto kroku bychom měli již přesně popsat všechny třídy balíčku a jejich operace. Dále všechny sekvenční diagramy všech případů užití. -6-

284 Návrhová podoba je již vhodná k programování. Nejdříve provedeme úpravu všech operací tak, že v nich uvedeme všechny parametry. OPERACE TŘÍDA POPIS OPERACE dejmzp(rod.číslo, a) Dej informaci o majiteli a hlavně jeho ID. Pro prodávajícího to MZP dejmzp(rod.číslo, b) bude veličina a, pro kupujícího veličina b. Zadá se výrobní číslo předložené zbraně. Operace vytiskne oznam, dejzbraň(včz,i) ZBRAN že zbraň je, nebo není evidovaná. Je-li zbraň evidována, pak se parametr i naplní identifikátorem majitele ZP. dejkz( včz,j) KZ Zadá se výrobní číslo předložené zbraně. Operace oznámí platnost, nebo vypršení poslední kontroly zbraně. Je-li kontrola platná, je parametr j nastaven na true, jinak na false. hledejpz(ečpz, k) PZ Zadá se evidenční číslo předloženého PZ. Operace vytiskne oznam o evidenci. Je-li evidence, potom parametr k bude obsahovat kategorii zbraně. hledejzp(ečzp 1, IDm 1, K 1 ) ZP Zadá se evidenční číslo ZP prodávajícího. Operace potvrdí, nebo nepotvrdí evidenci ZP v systému. Je-li ZP evidován, pak do IDm 1 se dosadí ID prodávajícího a K 1 je množina přípustných kategorií. hledej ZP(ečZP 2, IDm 2, K 2 ) ZP Zadá se evidenční číslo ZP kupujícího. Operace potvrdí, nebo nepotvrdí evidenci ZP v systému. Je-li ZP evidován, pak do IDm 2 se dosadí ID kupujícího. K 2 je množina přípustných kategorií kupujícího. (a=i= IDm 1 )(kk 2 ) (j=true)(b=idm 2 ) přepišzbraň(včz, IDm 1, IDm 2, datum nabytí) ZBRAN Operace převede zbraň s včz z prodávajícího na kupujícího a podá o tom zprávu. přepišpz(ečpz, IDm 2 ) PZ Do PZ se napíše nový majitel s IDm 2. Výtisk všech atributů PZ. Teď upravíme třídy, v kterých zapíšeme operace. Můžeme zavést popisy typů jednotlivých atributů, tj. do tvaru, který je žádán ze strany jazyka UML. MZP ZP Zbraň PZ ID majitele ZP Příjmení jméno Rodné číslo Fotografie Trvalé bydliště dejmzp(rod.číslo, a) Evid. číslo ID majitele ZP Kategorie zbraní Pořadí vydání ZP hledejzp(ečzp, IDm, K) KZ ID kontroly Datum kontroly Druh zbraně Výrobní číslo zbraně Výsledek kontroly Výrobní číslo zbraně ID majitele ZP Datum nabytí Stav dejzbraň(včz,i) přepišzbraň(včz, IDm1, IDm2, datum) Evid. číslo Druh zbraně Výrobce Vzor Ráže Výrobní číslo zbraně Kategorie ID majitele ZP Registrace u Datum registrace hledejpz(ečpz, k) přepišpz(ečpz, IDm 2 ) dejkz( včz,j) Nakonec upravíme do návrhové podoby rovněž Sekvenční diagram případu užití Převedení zbraně na jiného vlastníka. -7-

285 MZP Administrátor dejmzp(r.č.,a) dejmzp(r.č.,b) Zbraň KZ PZ ZP dejzbraň(včz, i) dejkz(včz, j) hledejpz(ečpz, k) hledejzp(ečzp 1, K 1) hledejzp(ečzp 2, K 2) IF (a = i = IDm 1) (kk 2) (j = true) (b = IDm 2) THEN přepišzbraň(včz, IDm 1, IDm 2, datum nabytí) přepišpz(ečpz, IDm 2) Teď je jisté, že programátoři již více rozumí tomu, jak případ užití Převedení zbraně na jiného vlastníka vlastně funguje. Krok: Upřesnění diagramu analytických tříd pro případ užití Převedení zbraně na jiného vlastníka (možnost zavedení agregací a kompozic). Následující diagram se ocitne později jako fragment celkového návrhového diagramu balíčku Řízení zbraní a PZ. Tam bude ve tvaru: fragment MZP 1 1 ZP 1 KZ 0..* 1 0..* Zbraň PROZ VKZ PZ -8-

286 1.3 Architektura cílového software Architektonický návrh Tento, dosti roztříštěný a delší pracovní postup, sice patří svým začátkem do pracovního kroku Prvotní přístup k logické architektuře cílového software (vyrábí se Schéma prvního pohledu na problémovou doménu s ohledem na logickou architekturu) ve fázi ZAHÁJENÍ, potom náleží do pracovního postupu Analýza, rovněž fáze ZAHÁJENÍ (mapování případů užití do podsystémů, které není rozporné se Schématem prvního pohledu na problémovou doménu). Nakonec, je součástí fáze ROZPRACOVÁNÍ jako Architektonická analýza, a ještě součástí pracovního postupu Návrh. Tam se dále rozpracovává Schéma prvního pohledu na problémovou doménu na tzv. Prvotní schéma logické architektury. Krok: Logická architektura Na začátku tohoto kroku bychom měli převzít výsledky z pracovního postupu Prvotní přístup k architektuře cílového software a převést Prvotní schéma logické architektury do komponentového modelu (komponentový systém pro cílový software a deskripce jeho systémových vlastností. Tak to proveďme! Pro naši doménu SSZ v ČR má schéma Prvotního pohledu na problémovou doménu následující tvar: Správa soukromých zbraní na teritoriu ČR Statistiky a vyhledávání Správa MZP Správa ZP Správa klientů Správa zbraní a PZ Ze znalosti funkcionality problémové domény Evidence soukromých zbraní v ČR můžeme poznat následující skupiny/podsystémy procesů a souvislosti mezi nimi (oddělili jsme Správu MZP od Správy ZP). Vzniklo pět podsystémů. 1. Správa zbraní a Průkazů zbraní. 2. Správa majitelů zbraní. 3. Správa ZP. 4. Správa klientů. 5. Statistiky a vyhledávání. Pomocí předchozího schématu Prvotní pohled na problémovou doménu jsme sestavili Model hrubé funkční závislosti v problémové doméně se závislostní - relací <<využívá>>. Dostáváme tak následující pracovní schéma. -9-

287 <<Podsystém>> Správa zbraní a průkazů zbraní <<využívá>>. 7 <<Podsystém>> Statistiky a vyhledávání <<využívá>>. 2 4 <<využívá>>. 1 <<využívá>>. <<Podsystém>> Správa majitelů zbraní <<využívá>>. 3 <<Podsystém>> 5 Správa zbrojních <<využívá>> průkazů <<využívá>>.. <<využívá>>. 6 <<Podsystém>> Správa klientů Sestavili jsme rovněž schematický Přehled architektury, který je složen z Prvotního schématu logické architektury a jeho deskripce: a) Prvotní schéma logické architektury pro doménu SSZ v ČR: Komunikace s klienty Správa výstupních sestav Správa zbraní a průkazů zbraní (ZP) Správa statistiky a vyhledávání BD Správa majitelů zbraní Správa zbrojních průkazů (ZP) Správa klientů Deskripce: b) Stálé prvky logické architektury: Za stálé prvky logické musíme považovat především dosud nalezené funkcionální podsystémy. Správa zbraní a PZ, Správa majitelů zbraní, Správa ZP, Správa klientů, Správa statistiky. c) Přidané prvky logické architektury: Především musíme přidat bázi dat, protože budeme chtít konstruovat data-driven aplikaci. Teď se ještě nerozhoduje, jestli to bude báze objektová (tak by to mělo být) nebo relační. Dále, pojetí výstupních sestav vyžaduje rovněž řízení, protože výstupy by měly být např. podle různých šablon a tedy je nutná jistá Správa výstupních sestav. Nakonec, musíme systémově řídit komunikaci s klienty, protože je více typů a každý typ žádá odlišné GUI (Graphical User Interface). Pro přidané prvky je nutno vyřešit návaznosti mezi nimi a návaznosti (relace využívá) na stálé prvky. -10-

288 d) Deskripce schématu: Systém potřebuje centrální řízení komunikace s klienty, které umožní nejen autentizaci a autorizaci, ale i organizaci plnění jejich požadavků. Klienti mohou přes Správu komunikace s klienty spouštět jednotlivé podsystémy a mít rovněž jednoduché dotazy na bázi dat. Veškerá informace podsystémů je uložena v objektové bázi dat. Podsystém Správa statistiky nebude využívat ostatní podsystémy (jak je ve funkčním modelu), ale jen jejich data z objektové báze BD. Podsystém Správa výstupních sestav bude organizovat výstup podle připravených výstupních šablon v podsystému Správa statistiky. Poznámka: Černé vazby jsou od přidaných prvků, modré jsou vazby mezi stálými prvky a červené jsou vazby prvků logické architektury na bázi dat. Krok: Návrhová architektura Základem pro návrhovou architekturu je obecný návrhový metamodel, jehož interpretaci musíme pro SSZ v ČR sestrojit. Neměli bychom mít problémy, protože: 1. Známe závislosti podsystémů (kdo koho využívá). 2. Známe stálé a přidávané prvky logické architektury. K tvorbě Modelu návrhové architektury použijeme Prvotní schéma logické architektury cílového software pro doménu SSZ v ČR a potom Model hrubé funkční závislosti v problémové doméně. Než začneme kreslit Model návrhové architektury, tak popřemýšlíme, jestli budeme každý podsystém mapovat jen na jednu komponentu, nebo na více komponent. Přirozeně, jednoduché je mapování 1:1. Od čeho mapování závisí? K tomu použijeme následujících úvah: 1. Jestliže si myslíme, že nemáme žádné důvody mapovat podsystémy do více komponent, to může být ze začátku přesvědčivé, ale později může být rozvernější a flexibilnější mapování vynuceno. 2. Jestliže pro některý podsystém je namodelováno více balíčků případů užití, tak můžeme podsystém mapovat tak, že každému balíčku náleží jedna komponenta. 3. Jako samostatné komponenty k danému podsystému můžeme mapovat takové případy užití, o kterých víme, že jejich funkcionality se často mění. 4. Dále, podsystémy nakreslíme jako komponenty. Rychle zapomeneme na slovo podsystém a slovo komponenta je pro nás určující. Názvy komponent jsou ovšem totožné s názvy podsystémů. Následující schéma je sice bez interface mezi komponentami, ale to jsme již schopni rychle překreslit. Vznikne tak čistě komponentový Model návrhové architektury. Poznámka: 1. Protože budeme předpokládat, že každá komponenta má svoji vlastní komunikaci s bází dat, tak přidaný prvek báze dat nepovažujeme za komponentu. 2. Model návrhové architektury již neobsahuje nárys koncového počítače. Obsahuje jen komponenty. Pracovní Model návrhové architektury vytvoříme z Prvotního schématu logické architektury -11-

289 Komunikace s klienty Správa zbraní a průkazů zbraní Správa majitelů zbraní Správa výstupních sestav Správa statistiky BD Správa klientů Správa zbrojních průkazů Komunikace s klienty Správa zbraní a průkazů zbraní Správa majitelů zbraní Správa výstupních sestav Správa statistiky Správa zbrojních průkazů Správa klientů Model návrhové architektury (dílčí schéma orchestrace). Model návrhové architektury má sedm komponent, které umožní dostatečnou flexibilitu cílového software co do změn a možností nasazení na informační infrastruktuře zákazníka. Pro návrhovou architekturu musíme dále řešit: 1. Verbálně popsat filosofii aktivit a spolupráce jednotlivých komponent. 2. Na základě bodu 1. Řešit složení rozhraní, tj. co komponenta pro svou práci potřebuje a co dává jako výsledek pro ostatní komponenty. 3. Pokusit se tzv. klišé architektury cílového software uměle naprogramovat jako tzv. spustitelný základ. Tento základ dále jen doplňujeme a neměníme. Jde o naprogramování Modelu návrhové architektury. -12-