1.4.1.2. Studium předmětu Softwarové inženýrství

V rámci přípravy na návrh a realizaci Databáze české moderní architektury absolvoval řešitel práce v letním semestru školního roku 2013/2014 studium předmětu Softwarové inženýrství na Fakultě informačních technologií ČVUT Praha. Cílem studia bylo seznámit se s nejnovějšími poznatky v oblasti návrhu a tvorby databází a softwarových aplikací obecně. Výuka probíhala formou přednášek a seminářů v rozsahu 2 hodiny přednášek a 1 hodina semináře týdně. Přednášky přibližovaly hlavní aspekty, souvislosti a pracovní postupy vývoje softwarových aplikací. Během seminářů měl řešitel možnost konzultovat s vyučujícím jak celkovou koncepci připravované databáze architektury, tak jednotlivé kroky jejího návrhu, který během semestru zpracovával. Zároveň byla s Katedrou softwarového inženýrství Fakulty informačních technologií ČVUT předjednána možnost další spolupráce po dokončení a obhájení databáze formou doktorské práce, pokud bude zájem o další rozvoj databáze.

Znalosti získávané studiem předmětu Softwarové inženýrství si řešitel databáze během semestru rozšiřoval ještě studiem dalších odborných publikací. Jednalo především o tyto publikace - Úvod do softwarového inženýrství (3), Softwarové inženýrství (4), Modely a systémy (5), Návrh databází (6), Destilované UML (7).

Cílem předmětu Softwarové inženýrství je seznámit absolventy s problematikou řešení rozsáhlejších softwarových systémů. Předmět je založen na metodice objektově orientovaného přístupu s využitím jazyka UML (Unified Modeling Language). Absolventi získají znalosti o procesu tvorby softwarového díla, znalosti o životní cyklu tohoto díla, o možných postupech při specifikaci, analýze, návrhu, realizaci a testování softwarového systému a o tom jak při tomto postupu využít jazyk UML.

V následujícím textu je v krátkosti přiblížen obsah a význam těch jednotlivých částí problematiky, které byly v rámci předmětu probírány.

1) Úvod do systémového inženýrství a týmového vývoje
Hlavním cílem předmětu je naučit se pracovní postupy vývoje softwarové aplikace na konkrétním projektu. Softwarová aplikace je zhotovována ve třech etapách - analýza, návrh, realizace. Analýza zahrnuje modelování obchodních procesů, sběr a specifikaci požadavků a tvorbu doménového modelu. Návrh obsahuje volbu technologie, návrh architektury, volbu způsobu ukládání dat a přidělení zodpovědnosti a návrh komunikace. Realizace se skládá z programování (zdrojové kódy), dokumentování (příručky) a sestavení (instalační balíčky). Práce zpracovávané studenty předmětu během semestru v rámci cvičení byly mezi studenty a vyučujícím sdíleny na školním serveru pomocí technologie Trac Wiki. Správa souborů je zajištěna pomocí nástroje SVN. Přidělování úkolů, sledování postupu jejich plnění a sledování chyb je zajištěno pomocí technologie Trac Tickets.

Při analýze a návrhu aplikací se využívají diagramy UML. Rozlišují se dva základní typy UML diagramů - diagramy chování a diagramy struktur. Diagramy struktur zahrnují diagramy, tříd, komponent, nasazení a diagram balíčků. Diagramy chování zahrnují diagramy aktivit, případů užití, interakce a stavový diagram.

2) Modelování obchodních procesů
Systémy se skládají z jednotlivých objektů, mezi nimiž probíhají různorodé procesy. Proces je sadou uspořádaných aktivit objektu. Procesy lze zachytit buďto textovým popisem nebo diagramem (např. diagram aktivit UML, nebo diagram BPMN). Zdrojem informací o procesech je budˇto komunikace zhotovitele softwaru se zákazníkem nebo různorodé standardy či směrnice. Nutno rozlišit stávající procesy v systému od procesů navrhovaných. Business doménový model (BDM) zachycuje entity (objekty), které se v procesech vyskytují. Ke zobrazení BDM se využívá diagram tříd UML.

3) Modelování požadavků
Požadavky na aplikaci se zachycují buďto pomocí strukturovaného textu nebo pomocí diagramu (Use case diagram UML). Požadavky lze rozdělit na funkční a obecné (mimofunkční). Kategorizace FURPS rozlišuje F (functionality) - funkčnost, U (usability) - použitelnost, R (reliability) - výkon, P (performance) a S (supportability) - rozšiřitelnost. Formulace požadavků nesmí být nejednoznačná. Je vhodné stanovit priority požadavků.

Modelování případů užití (Užití = užití systému) Detailně specifikuje požadavky na systém. Je základem pro tvorbu uživatelské příručky a umožňuje zpřesnit odhady pracnosti. Model případu užití = Use case model = model jednání. Model případů užití se skládá ze seznamu účastníků, digramů případů užití, popisů případů užití a ze scénáře (hlavní a alternativní) případů užití.

4) Analýza problémové domény
Problémovou doménou je míněn systém procesů skutečně probíhajících v reálném světě (například procesů při návrhu, realizaci a dokumentaci architektury). Analýzu problémové domény (5) (6)zobrazuje analytický doménový model (DM).Cílem analytického doménového modelu je popis dat, popis vazeb mezi entitami a identifikace stavů entit. Analytický doménový model je základem pro datový model a model tříd. Pro zachycení doménového modelu se využívá diagram tříd UML.

5) Architektura softwarových systémů
Logickou architekturou systému se rozumí způsob organizace jednotlivých tříd aplikace do balíčků a uspořádání balíčků do vrstev. Fyzickou architekturou se rozumí rozložení aplikace do jednotlivých komponent. K vyjádření logické architektury se využívá diagram balíčků UML. Vícevrstvá logická architektura může být jednovrstvá (monoitická) až třívrstvá. Vícevrstvá architektura umožňuje nezávislou správu a vývoj jejdnotlivých vrstev, zvyšuje tak flexibilitu aplikace. Fyzické rozdělení aplikace na nezávislé komponenty zvyšuje vyriabilitu aplikace. Existuje také servisně orientovaná architektura, sloužící k integraci nezávislých systémů.

6) Návrh - návrhové třídy a vzory
Prvním krokem návrhu aplikace je vytvoření návrhového modelu tříd. Návrhový model tříd vychází z hotového doménového modelu, který dále upřesňuje o datové typy atributů a o nové třídy. Následuje vytvoření databázového modelu, který je zpřesněním návrhového modelu tříd o primární a cizí klíče. Dochází zde také k dekompozici m:n vazeb tabulek. Jednotlivé objekty aplikace spolu navzájem spolupracují. Komunikují vzájemným zasíláním zpráv. Vzájemnou komunikaci objektů lze zobrazit pomocí sekvenčních diagramú UML nebo pomocí diagramů komunikace.

Při návrhu aplikace lze také využít návrhové vzory. Návrhový vzor (Design pattern) není knihovnou nebo částí vzorového kódy, která by se dala přímo vložit do programu. Jedná se o popis řešení problému, který lze použít v různých konkrétních situacích. Existují tak vzory pro vytváření objektů (Creational), vzory strukturální (Structural) a vzory chování (Behavioral). Návrhové vzory jsou však již speciální, rozšiřující oblastí návrhu aplikací.

7) Návrh - rozhraní a komponenty
Komponenta je samostatnou částí systému, jednotlivé komponenty jsou navzájem propojeny pomocí rozhraní. Dělení aplikace na komponenty lze zobrazit diagramem komponent. Fyzickou architekturu aplikace lze zobrazit diagramem nasazení, který specifikuje rozmístění komponent, popisuje jednotlivá fyzická zařízení systému a způsob jejich propojení. Přílohou diagramu nasazení může být instatlační příručka.

8) Testování aplikací
Testování je podstatnou součástí vývoje aplikace. Existuje mnoho typů testů - podle rozsahu (jednotkové testy, testy komponent, integrační testy, systémové testy...), podle způsobu provádění (testy statické a dynamické), podle znalosti vnitřní struktury (white box, black box, gray box), podle způsobu vyhodnocování (automatické nebo manuální), podle zaměření (na funkčnost, použitelnost, spolehlivost, výkon, podporovatelnost). Pro provádění testů existuje řada hotových nástrojů (www.unit.org, www.nunit.org, testng.org, www.jmock.org, EasyMock, hudson-ci.org, cruisecontrol.sourceforge.net, seleniumhq.org, www.soapui.org, pmd.sourceforge.net, findbugs.sourceforge.net).

9) OCL a inteligentní omezení
Pomocí diagramů UML nelze popsat vše - proto je součástí specifikace UML i definice OCL (Object Constraint Language). OCL je specifikační jazyk vycházející z metodiky Syntropy (IBM). OCL lze využít například pro vyjádření integritních omezení v datovém modelu. pro popis vstupních a výstupních podmínek operací nebo pro popis operací.

10) Metodiky vývoje software
Při vývoji software lze postupovat různými způsoby. V procesu hledání optimálních postupů jsou vyvíjeny různé metodiky vývoje software. Metodiky lze rozdělit na klasické a agilní. Mezi klasické metodiky patří Moderní strukturovaná analýza - MSA nebo Unifikovaný proces vývoje - UP. Mezi agilní metodiky se počítají Extrémní programování - XP, Metodika SCRUM nebo Modelem řízený vývoj - MDD, MDA. V procesu vývoje software hrají významnou roli jednotlivé softwarové profese, softwarové týmy, které se z těchto profesí vytvářejí a způsob organizace těchto týmů. Je nezbytné zkoumat životní cyklus softwarového díla a fáze jeho tvorby. Životní cyklus softwarového díla lze různými způsoby modelovat (přírůstkový model, model vodopád, spirálový model...). Následně lze pro softwarový proces vytvářet různé metodiky. Pro různá zadání jsou vhodné rozdílné metodiky.

11) Unifikovaný proces vývoje
Unifikovaný proces vývoje (UP) je průmyslový standard vývojového procesu. Využívá notaci UML. Je řízen požadavky kladenými na zhotovovaný software, staví na architektuře, komponentách a principu znovupoužití. Je to iterativní a přírůstkový proces. UP má strukturu charakteristickou jednotlivými navazujícími fázemi vývoje, které jsou odděleny milníky. V každé fázi probíhá minimálně jedna iterace skládající se z různého počtu základních kroků. Unifikovaný proces vývoje je pouze určitým typem metodiky, kterou je nutno v případě jejího využití uzpůsobit danému zadání, firmě a použitým nástrojům.

12) Metody integrace aplikací
V dřívějších dobách byly aplikace vyvíjeny pouze pro splnění přesně specifikovaných úloh konkrétního zadavatele a uživatele. Žádná integrace proto nebyla nutná a ani možná. Dnes je silná potřeba sdílení a vzájemné výměny dat mezi různými aplikacemi. Aplikace lze integrovat buďto na úrovni dat, na úrovni aplikační logiky nebo na úrovni uživatelského rozhraní nebo na úrovni aplikačních služeb. Samostatným typem aplikační architektury je princip servisně orientované architektury (SOA). Existují různorodé webové služby, které můžou využívat různí uživatelé. a existují různé formáty pro výměnu zpráv mezi službami. Jedním z formátů pro výměnu zpráv je SOAP (Simple Object Access Protokol), který je XML aplikací. Pro účely popisu webových služeb existuje XML aplikace WDSL (Web Services Description Language). UDDI (Universal Description, Discovery and Integration Service) poskytuje mechanismus, jehož prostřednictvím mohou klienti dynamicky hledat požadované webové služby. Takto by aplikace měly být schopny se kontaktovat na služby poskytované externími partnery. Registr UDDI spravuje informace o dostupných webových službách.

V rámci seminářů navazujících na přednášky v předmětu Softwarové inženýrství probíhala také základní výuka využití nástroje Enterprise Architekt pro modelování softwarových aplikací.

Databáze architektury není pouhým souhrnem několika tabulek naplněných daty. Je komplexní softwarovou aplikací - informačním systémem pro sběr, správu a prezentaci dat. Pro správný návrh databáze je proto nezbytné mít obdobné vědomosti a znalosti jako pro návrh jakékoli jiné softwarové aplikace. Studium předmětu Softwarové inženýrství napomohlo řešiteli databáze správně definovat postup a jednotlivé kroky návrhu databáze a umožnilo využít při návrhu databáze nejnovější poznatky a postupy.

Literatura
1. Mlejnek Jiří. Softwarové inženýrství I, přednášky a cvičení. FIT ČVUT Praha, 2014.
2. Richta Karel. Softwarové inženýrství, přednášky. FIT ČVUT Praha, 2011.
3. Vondrák, Ivo. Úvod do softwarového inženýrství. Ostrava : VŠB - Technická univerzita Ostrava, 2002.
4. Sommerville, Ian. Softwarové inženýrství, Brno: CPress, 2013.
5. Křemen, Jaromír. Modely a systémy. Praha : Academia ČMT, 2007. 978-80-200-1477-1.
6. Hernandez, Michael. Návrh databází. Praha : Grada, 2006. 80-247-0900-7.
7. Fowler, Martin. Destilované UML. Praha : Grada, 2009. 978-80-247-2062-3.

---

Databáze české moderní architektury
textyclanku.php

NÁVRH DATABÁZE

---

Architekti
Stavby
Technologie
Literatura