ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ KATEDRA KYBERNETIKY DIPLOMOVÁ PRÁCE Informační systém pro řízení projektu vývoje software Praha, 2002 Jan Breznay
Prohlášení Prohlašuji, že jsem zadanou diplomovou práci zpracoval samostatně s přispěním vedoucího diplomové práce a používal jsem pouze literaturu v práci uvedenou. Prohlašuji, že nemám námitek proti využití výsledků této práce fakultou ani proti zveřejňování nebo půjčování se souhlasem vedoucího diplomové práce. V Praze, dne 24.5.2002
Poděkování Na tomto místě bych chtěl poděkovat Ing. Petru Mikšovskému a Ing. Zdeňku Koubovi za vedení mé diplomové práce. Dále pak děkuji mým rodičům a přátelům, kteří za mnou po celou dobu studia stáli a podporovali mě.
Abstrakt Cílem této práce bylo navrhnout a implementovat informační systém pro řízení projektu vývoje software. Byla vytvořena aplikace, která přes rozhraní sítě internet nabízí komplexní přístup k řešení vývoje zejména rozsáhlých softwarových produktů, vznikajících jako výsledek týmové práce skupiny vývojářů. Základním prvkem v aplikaci je projekt, ke kterému mohou být přiřazeny různé komponenty zefektivňující práci na softwarovém projektu (diskusní fórum, seznam úkolů, seznam chyb, zdrojové kódy a zveřejňování vznikajících produktů). Správa uživatelů je podpořena možností sdružovat uživatele do skupin. Informační systém byl vytvořen pro vývoj aplikací v Gernstnerově laboratoři Katedry kybernetiky. Abstract This diploma thesis deals with design and implementation of the Information system for software development project control. Designed application provides through the Internet an integrated access to the large-scale software products development. Application is centered on teamwork. Each registered project can own a few of components to assure teamwork to be effective (mail forum, task list, bug list, file releases, source codes). Application provides user management include availability of user groups. The information system is developed for Gernstner laboratory of the Department of Cybernetics.
Obsah Obsah... 1 1 Úvod... 3 2 Softwarové inženýrství... 4 2.1 Základní pojmy... 4 2.2 Specifikace požadavků... 7 2.3 Nástroje pro analýzu systému a návrh SW produktu... 8 2.3.1 Modely softwarového procesu... 8 2.3.1.1 Vodopádový model... 8 2.3.1.2 Prototypování... 9 2.3.1.3 Spirálový model... 10 2.3.1.4 Další modely... 10 2.3.2 Nástroje analýzy systému... 11 2.3.3 Metody návrhu systému... 13 2.3.4 UML... 13 2.3.4.1 Případy užití... 15 2.3.4.2 Diagramy tříd... 16 2.3.4.3 Diagramy objektů... 18 2.3.4.4 Sekvenční diagramy... 18 2.3.4.5 Diagramy spolupráce... 19 2.3.4.6 Stavové diagramy... 19 2.3.4.7 Diagramy aktivit... 20 2.3.4.8 Diagramy komponent... 20 2.3.4.9 Diagramy rozmístění... 21 2.3.5 SSADM... 21 2.3.5.1 Hlavní složky SSADM... 22 2.3.5.2 Struktura SSADM... 23 2.3.5.3 Techniky a postupy... 24 2.3.5.4 Specifikace požadavků... 26 2.3.5.5 Popis života entit... 28 2.3.5.6 Identifikace uživatelských rolí... 29 2.3.5.7 Identifikace a návrh dialogů... 29 1
2.4 Řízení projektu vývoje software... 30 2.4.1 Metriky softwarového projektu... 30 2.4.2 Odhadování a plánování rozsahu projektu... 31 2.4.3 Řízení rizik a zabezpečení kvality softwarového produktu... 32 2.4.4 Řízení změn softwarového produktu... 32 2.4.5 Testování softwaru... 33 2.4.6 Projektový management... 34 3 IS pro řízení projektu vývoje software... 36 3.1 Návrh a implementace ISSDPC... 37 3.1.1 Specifikace požadavků na ISSDPC... 37 3.1.2 Vývojový nástroj systému... 39 3.1.3 Server ISSDPC... 39 3.1.4 Databáze ISSDPC... 39 3.1.5 Struktura aplikace... 40 3.1.6 Implementace... 41 3.1.7 Inicializace systému... 41 3.2 Popis ISSDPC z pohledu uživatele... 43 3.2.1 Uživatelské role... 44 3.2.2 Skupiny uživatelů... 45 3.2.3 Registrace uživatele... 47 3.2.4 Přihlášení uživatele do systému a odhlášení... 48 3.2.5 Osobní stránka uživatele... 48 3.2.6 Administrace systému... 49 3.2.7 Projekt (Project)... 52 3.2.8 Seznam úkolů (Task list)... 53 3.2.9 Seznam chyb (Bug list)... 56 3.2.10 Diskusní fórum (Mail forum)... 57 3.2.11 Zveřejněné soubory (Releases)... 58 3.2.12 Zdrojové kódy (Source codes)... 59 3.2.13 Přístupová práva k objektům... 59 4 Závěr... 62 5 Literatura... 63 6 Obsah přiloženého CD... 64 7 Přílohy... 64 2
1 Úvod Se vstupem počítačů do rozmanitých odvětví činnosti člověka nabývá na významu otázka vývoje software jako dílčího nástroje pro realizaci určitých cílů lidského snažení. Počítače jsou využívány pro řešení stále důležitějších a komplexnějších úloh, kdy se hlavními ukazateli stávají zejména spolehlivost a cena. V současné době dosahuje hardware počítačů již takové úrovně, že v aplikacích s počítačovými systémy jsou tyto ukazatele převážně určeny právě softwarovým vybavením. Rozsah úloh řešených za pomoci software byl impulsem ke vzniku vědní disciplíny zvané softwarové inženýrství. Jelikož vývoj téměř každého softwarového produktu je náročnou a rozsáhlou prací, neobejde se bez týmové práce řady spolupracovníků, kteří musí vzájemně sdílet zdrojový kód projektu, na kterém společně pracují. Musí komunikovat, zveřejňovat požadavky, připomínky a návrhy, zveřejňovat své dílčí výsledky apod. Právě k tomuto účelu slouží informační systém pro řízení projektu vývoje software. Kapitola 2 pojednává o softwarovém inženýrství. Nejprve jsou zmíněny základní pojmy problematiky vývoje software se zaměřením na vývoj rozsáhlých softwarových produktů. Kapitola pokračuje tématem specifikace požadavků. Následuje část věnovaná nástrojům pro analýzu systému a návrh softwarového produktu. Jsou zmíněny základní pojmy a metody analýzy a návrhu a poté jsou popsány dvě konkrétní, v praxi používané, metody s odlišným přístupem k problematice analýzy a návrhu softwarového produktu. V závěru kapitoly je zmíněn přístup k problematice řízení projektu vývoje software zejména z pohledu manažera projektu. Kapitola 3 popisuje navrženou aplikaci Informačního systému pro řízení projektu vývoje software. Nejprve je popsána analýza, návrh a implementace tohoto systému. Následují informace nutné k uvedení sytému do provozu a kapitola popisující aplikaci z pohledu uživatele. Jsou zmíněny uživatelské role a každý objekt aplikace je popsán z pohledu všech uživatelských rolí. Zvláštní kapitola je věnována nastavování přístupových práv k vytvořeným objektům. V textu je pro názornost umístěno několik obrázků zachycujících aplikaci v různých stavech. 3
2 Softwarové inženýrství Softwarové inženýrství je podle [1] systematický, disciplinovaný a kvalifikovaný přístup k vývoji, provádění a údržbě softwaru. 2.1 Základní pojmy Systém Systém je množina vzájemně souvisejících objektů či komponent, na kterou nahlížíme jako na celek a která byla vytvořena pro určitý účel. Systém je ohraničený a to, co je vně této hranice, se nazývá okolí, s nímž systém interaguje prostřednictvím svých rozhraní. Analýzou systému rozumíme nacházení faktů, zákonitostí a omezení v systému [2]. Projekt Projekt je dobře definovaná posloupnost činností, která má určen začátek a konec. Je zaměřena na dosažení jistého cíle a je uskutečňována pomocí zdrojů lidí a prostředků. Projekt je specifická nerutinní akce, která vyžaduje plánování, neboť je problematické stanovit jeho časovou a finanční náročnost. Plánování projektu má za cíl důkladně promyslet to, čeho chceme dosáhnout. Slouží také k sestavení časového harmonogramu a rozpočtu projektu [3]. Softwarový proces Softwarový proces je sada postupů, pravidel a norem pro řízení softwarového projektu. Definuje fáze projektu, produkty, role pracovníků a jejich zodpovědnost, kvalitativní kriteria, použití nástrojů včetně šablon. Softwarový produkt Softwarový produkt je správním či řídícím systémem nad systémem základním, definovaným výše, jakožto výsledek softwarového procesu definovaného v předchozím odstavci. IEEE definuje software jako souhrn programů, metod, pravidel a přidružené dokumentace a dat [4]. Softwarový produkt tedy není jenom programem používaným pouze autorem programu s minimem dokumentace. Takový produkt by byl pro 4
uživatele nedostačující. Software podle [5] znamená průmyslově-kvalitní software, kdy uvažujeme, že je předmětem zájmu jak týmu vývojářů, tak uživatelů. Jako takový tedy zahrnuje kromě programů (ve smyslu uvedeném výše) s vhodným uživatelským rozhraním také adekvátní množství dokumentace a před uvedením do provozu byl řádně systematicky testován. Programování ve velkém Při programování rozsáhlých softwarových produktů se jedná o řešení rozsáhlých programových celků, které řídí, ovlivňují či spoluvytvářejí složitý systém. Nelze tedy aplikovat pouze metodiky určené pro programování v malém, kterými jsou zejména programovací techniky pro návrh dat a algoritmů. Při programování ve velkém je nutná dekompozice projektu na menší celky do takové míry, kdy lze využít technik programování v malém. Při řešení rozsáhlého softwarového projektu se tedy uplatní jak programování ve velkém, tak i programování v malém. Vývoj takového projektu je obvykle řešen v etapách, jež jsou součástí životního cyklu softwarového produktu. Životní cyklus softwarového produktu Životní cyklus softwarového produktu začíná prvotní představou o programu a končí ve chvíli stažení produktu z používání. Životní cyklus každého rozsáhlého softwarového produktu by měl vždy obsahovat následující etapy: Specifikace problému je prvním krokem ke vzniku softwarového produktu. Tato etapa spočívá v zadání problému, jeho specifikaci, prvotních návrzích komunikace s programem a v závěru spočívá v testování vytvořené specifikace. Kvalita specifikace ovlivňuje další fáze vývoje produktu, je proto velmi důležitá. Její úspěch je založen zejména na hojné komunikaci řešitelů se zadavatelem. Analýza sytému si klade za cíl vytvoření logického modelu stávajícího a požadovaného sytému. V této fázi vývoje je velice důležitá komunikace mezi pracovníky provádějícími analýzu a zadavateli projektu, neboť nepochopení požadavků zadavatele může vést k rozsáhlým nežádoucím časovým i finančním následkům. Při analýze je výhodné použít grafických technik, díky jejich srozumitelnosti i pro osoby neznalé metod softwarového inženýrství, neboť takovými osobami většinou zadavatelé projektu jsou. V etapě návrhu systému se uplatňují metody programování ve velkém. Je nutná dekompozice problémů na problémy dílčí, návrh metod řešení jednotlivých problémů 5
a návrh podpůrných prostředků. Velmi důležitá je volba metody návrhu systému, neboť právě na ní závisí časová náročnost návrhu a tím i výsledná cena softwarového produktu. Třetí etapou je implementace, při které se uplatní metody programování v malém. Nejprve je nutné provést návrhy reprezentace lokálních dat, návrhy algoritmů realizujících dílčí problémy. Poté následuje zápis kódu programu a jeho modulů ve zvoleném programovacím jazyce a ladění programu. Po odladění jednotlivých komponent následuje jejich syntéza do požadovaných výsledných celků. Nedílnou součástí kvalitního softwarového produktu musí být dokumentace produktu. Obsahuje nejen příručku k používání produktu, ale také dokumentaci k programu samotnému, dokumentaci pro údržbu a modifikace systému a případně další dokumenty k bezproblémovému nasazení, užívání produktu či jeho stažení z užívání. V další etapě následuje testování produktu. Spočívá ve validaci či verifikaci produktu proti specifikaci vzniklé v první etapě vývoje produktu a proti dokumentaci vzniklé v předchozí etapě. Teprve nyní následuje zadavateli nejvíce očekávaná etapa, kterou je nasazení, provoz a údržba produktu. Začíná v předání softwarového produktu včetně potřebné dokumentace zadavateli, případně v instalaci produktu u zadavatele, bylo-li tak ujednáno. V případě potřeby výroba médií a dokumentace, školení k produktu a podpora. Po uvedení rozsáhlého softwarového produktu do fungování následují opravy chyb objevených při provozu systému a opravy v dokumentaci k produktu. Dále pak vývoj a údržba verzí produktu. Po určité době používání softwarového produktu nastane situace, kdy produkt již nevyhovuje požadavkům uživatelů sytému a jediným řešením je návrh systému nového. V takovém případě se softwarový produkt dostává do poslední etapy, kterou je stažení produktu z používání. Je zřejmé a ze zkušeností vyplývá, že vývoj rozsáhlých softwarových produktů se neobejde bez zpětných kroků, kdy je nutné některé etapy opakovat. Z hlediska efektivity vývoje produktu je však žádoucí vyloučit zpětné kroky přes více etap. V některých případech je ovšem nutné zopakovat i celý cyklus. Existuje proto několik modelů životního cyklu, viz. kapitola 2.3.1. 6
Objektově orientované programování Základním pojmem objektově orientovaného programování je objekt. Objekt je v obecném slova smyslu cokoliv, co jsme citem schopni označit jako objekt. Objekt má svou identitu, vlastnosti, chování a zodpovědnost. Abstrakcí objektu vznikne tzv. třída, která je jakousi šablonou pro podobné objekty. Vlastnosti objektů určují data třídy a chování objektu definuje metody třídy. Objekt je tedy instancí třídy a definujeme tzv. zapouzdření, které znamená umístění dat a metod pracujících nad těmito daty do jediného objektu. Objektově orientovanému programování předchází objektově orientovaná analýza systému, která se zabývá zkoumáním systémů z pohledu objektů. Výhodou objektového přístupu je fakt, že identifikované objekty v pojetí uživatelů i programátorů znamenají totéž. Na základě nalezených objektů se definují jejich třídy. Hledají se jejich společné rysy a generalizací lze dospět ke vzniku tříd nových a vytvořit určitou hierarchii, ve které budou mezi třídami existovat vztahy dědičnosti. Potomek třídy tak zdědí vlastnosti a chování rodičovské třídy a rozšíří je o své vlastní. Hierarchie tříd založených na dědičnosti vede ke vzniku spolehlivějšího a přehlednějšího kódu programu oproti kódu, ve kterém nebylo generalizace využito. Rozsáhlost kódu je snížena při zachování funkčnosti. 2.2 Specifikace požadavků Na počátku softwarového procesu vždy stojí specifikace požadavků. Obvykle probíhá v několika krocích, kdy výstupem každého kroku je určitý dokument, sloužící jako podklad pro řešení dalších kroků. V prvém kroku je vytvořen návrh požadavků, který je obvykle nazýván neformální specifikace nebo též odborný článek. Odborný článek by měl být prvním psaným dokumentem, ovšem jako základ smlouvy mezi zadavatelem projektu a řešitelem sám o sobě není dostačující, neboť použití pouze přirozeného jazyka neposkytuje dostatečně přesnou formu vyjádření specifikace požadavků na softwarový produkt. Dalším krokem při specifikaci požadavků je vytvoření funkční specifikace softwarového produktu. Tento dokument musí být mnohem přesnější než odborný článek, a proto je žádoucí použít při jeho vytváření mnohem formálnější notaci. 7
Požadavky se dělí na funkční a nefunkční. Funkční požadavky určují, jak bude program fungovat, ostatní požadavky jsou zahrnuty v požadavcích nefunkčních. Více informací o tomto dělení požadavků lze nalézt v kapitole 2.3.5.4. Specifikaci požadavků lze rozdělit na neformální a formální. Neformální specifikace je vyjádřena přirozeným jazykem. Je proto poměrně dobře srozumitelná i pro uživatele nezabývající se vývojem software (zadavatele projektu), ovšem může obsahovat jisté nedostatky, které nejsou na první pohled zřejmé a projeví se až v dalších etapách vývoje produktu. Velkou část těchto problémů lze eliminovat zápisem požadavků ve formálním jazyce, jehož sémantika je jednoznačně definována. Poměrně universálním nástrojem je jazyk predikátové logiky, který však není v běžné praxi příliš použitelný. Lze však využít jiné prostředky, např. známé z teorie automatu, nebo Bacus- Naurovu formu. Pokud máme k dispozici podpůrné nástroje pro zpracování formálních specifikací, je možné je využít k validaci a verifikaci specifikace. 2.3 Nástroje pro analýzu systému a návrh SW produktu 2.3.1 Modely softwarového procesu Model softwarového procesu si klade za cíl naznačit možné způsoby průchodu životním cyklem rozsáhlého softwarového produktu. Modelů existuje hned několik, protože různorodost problematiky vývoje software zabraňuje sjednocení postupů do jediné optimální metody. 2.3.1.1 Vodopádový model Vodopádový model (viz. Obrázek 2.1), též lineární sekvenční model, je základním modelem životního cyklu softwarového produktu. Je složen z činností, které na sebe navazují a vzájemně se neprolínají. Předpokládá, že výchozí požadavky na softwarový produkt se nebudou během vývoje zásadně měnit. Tento model vývoje softwarového produktu popisuje klasický životní cyklus. Má však některé nedostatky, kterými jsou zejména: reálné projekty zřídkakdy sledují jednotlivé kroky v předepsaném pořadí pro zadavatele je ve většině případů obtížné přesně specifikovat požadavky provozuschopná verze je k dispozici až po dlouhé době a většinou s časovou prodlevou. 8
Přes všechny zmíněné nedostatky je vodopádový model vhodnou a používanou šablonou pro přístup k vývoji rozsáhlých softwarových produktů a v každém případě je vhodnější, než náhodný, metodicky neřízený přístup k řešení problému. definice požadavků návrh systému a SW produktu implementace a testování dílčích částí integrace dílčích částí testování celku provoz a údržba Obrázek 2.1: Vodopádový model životního cyklu softwarového produktu. 2.3.1.2 Prototypování Prototypování, na rozdíl od vodopádového modelu, již předpokládá, že nemáme podrobně analyzovaný systém a požadavky na systém nejde dostatečně dobře specifikovat předem. Je založeno na vytváření (programování) prototypů, které slouží k modelování některých vlastností systému. Prototyp je částečnou implementací produktu nebo jeho části v logické či fyzické formě, který prezentuje všechna vnější rozhraní. Prototypování umožní jak zadavateli, tak vývojovému týmu ujasnit si a specifikovat požadavky, včetně jejich interpretace. Prototypování je často využíváno i v jiných modelech a sestává z následujících kroků: 1. sběr a analýza dat 2. rychlý návrh 3. tvorba prototypu 4. vyhodnocení prototypu zadavatelem 5. vylepšení návrhu prototypu 6. jestliže zadavatel není spokojen s prototypem, je nutné opakovat od bodu 2 7. je-li zadavatel projektu spokojen, poté následuje úplný návrh. 9
Prototypování lze většinou aplikovat při vývoji menších systémů anebo na úrovni subsystému systému rozsáhlého, neboť prototypování rozsáhlého systému je obtížné a neekonomické. 2.3.1.3 Spirálový model Spirálový model je založen na kombinaci prototypování a analýzy rizik. Práce na projektu jsou realizovány tak, aby problémy spojené s klasickým vodopádovým modelem byly cílevědomě minimalizovány. Jednotlivé kroky vývoje produktu známé z vodopádového modelu se ve spirále opakují, ale pokud možno na vyšším stupni zvládnutí problematiky. Spirálový model života softwarového produktu začíná v počátku souřadnic. Směrem od středu ubíhá čas. V každé fázi opakování vodopádového modelu (řez spirálou) se provádí identifikace a řešení rizik. Spirálový model je založen na prioritě tvorby verze s vyšší rizikovostí, tedy části produktu s vyšší mírou rizika jsou realizovány dříve. Nevýhodou spirálového modelu je, že nelze přesně stanovit přesné časové termíny a tím pádem ani finanční rozpočet, což jsou ovšem při vývoji software na zakázku velmi důležité ukazatele. Spirálový model je vhodný při vývoji rozsáhlých systémů. 2.3.1.4 Další modely Další typy modelů softwarového procesu budou zmíněny jen krátce, neboť jsou vesměs založeny na výše zmíněných modelech. RAD model (Rapid Application Development) je založen na aplikaci vodopádového modelu a spočívá v krátkém vývojovém cyklu (doba trvání do 3 měsíců). Je vhodný pro dobře srozumitelné a dobře vymezené problémy s nízkou úrovní rizik. Problém je rozdělen na samostatné moduly, jejichž vývoj je přidělen jednotlivým týmům pracovníků. Rychlý vývojový cyklus je umožněn zejména častým využíváním již hotových softwarových komponent. Přírůstkový (evoluční) model kombinuje vodopádový model s iterativní filosofií. Produkt je vytvářen po částech, tzv. přírůstcích, které jsou funkční, na rozdíl např. od prototypu. První přírůstek je označován jako jádro. Tento model je vhodný pro malý tým a rozsáhlý úkol, jehož vývoj lze zvládnout po částech v předem domluvených termínech. 10
Model skládání komponent je založen na spirálovém modelu a je určen pro technologie s objektovým přístupem k softwarovému procesu. Při vývoji se využívá hotových knihoven tříd objektů. Model souběžného vývoje modeluje vývoj softwarového procesu jako paralelní procesy, kdy jsou jednotlivé komponenty vyvíjeny souběžně. Tento model je vhodný např. pro aplikace typu klient/server. Formální metody vývoje spočívají na formálních specifikacích a podporují formální verifikaci produktů. Praktickému nasazení takových metod zatím brání jejich časové a finanční nároky, nároky na vysokou kvalifikaci řešitelů a jejich obtížnost při komunikaci se zadavatelem projektu. Tzv. techniky čtvrté generace jsou založeny na programování s vysokou úrovní abstrakce. Jejich výhodou je zvýšení produktivity a tím rychlosti vývoje. Nevýhodou některých prostředků určených pro tento způsob vývoje je srovnatelná složitost s programovacími jazyky, užívanými při aplikaci předchozích metod. Další nevýhodou je fakt, že výsledný kód generovaný těmito prostředky nemusí být dostatečně efektivní. Perspektivní metody vývoje software by mohli spočívat ve využití CASE nástrojů ve spojení s modelem skládání komponent. 2.3.2 Nástroje analýzy systému Stěžejní část analýzy systému je založena na tvorbě modelů systému. Důvodem modelování je fakt, že nejsme schopni plně pochopit komplexní systém jako celek. Cílem modelování je porozumět problému, komunikovat prostřednictvím modelů se zadavateli a uživateli. Modely umožní odhalit řadu chyb a opomenutí, simulují složité situace, umožní plánovat návrh a generovat kód. Modely odstraňují možnou jazykovou bariéru a umožňují vidění problému všemi zainteresovanými stranami ze stejného pohledu. V první fázi se modeluje stávající systém, poté následuje tvorba modelu systému požadovaného. Vždy lze na systém pohlížet několika způsoby. Vnikají tak různé pohledy na systém a tedy i různé modely systému. Model by měl hovořit slovníkem uživatele modelu, oddělovat podstatné od podružného a oddělovat koncept a implementaci. 11
Diagramy datových toků Nazývány též procesní modely, diagramy toků práce, funkční modely, bublinové diagramy, ale nejčastěji diagramy datových toků, DFD (Data Flow Diagrams). Představují síťovou reprezentaci systému. Reálné systémy jsou většinou natolik rozsáhlé, že je nelze popsat jediným diagramem. Proto se používá stromová struktura, v jejímž kořeni je tzv. kontextový diagram. Existuje několik druhů notací, přičemž jedna z nepoužívanějších je součástí metody SSADM (viz. kapitola 2.3.5.3). Modely vnějšího chování Tyto modely mohou být reprezentovány např. výše zmíněným kontextovým diagramem, dále potom seznamem událostí, které působí na systém z jeho okolí. Datové modely Datové modely, tzv. E-R diagramy jsou jádrem analýzy při návrhu databázových systémů. Datové modelování se uplatňuje zejména u informačních systémů, neboť tyto systémy pracují z rozsáhlým množstvím dat. Modelují objekty v systému a vztahy mezi nimi pomocí tabulek. Obrázek 2.2 znázorňuje logický model vztahu mezi uživatelem a skupinou uživatelů v příkladu informačního systému. Jeden uživatel může být v několika skupinách uživatelů a současně jedna skupina uživatelů může sdružovat několik uživatelů. kardinalita uživatel N (1,N) je ve skupině M (1,M) skupina uživatelů id uživatele jméno uživatele parcialita id skupiny jméno skupiny primární klíč primární klíč Obrázek 2.2: Příklad logického modelu části databáze. 12
2.3.3 Metody návrhu systému Obecně rozeznáváme dva možné přístupy k návrhu systému Přístup zdola nahoru je založen na generalizaci. Začíná identifikací a analýzou několika jednoduchých struktur. Snaží se najít jejich společné charakteristiky a chování a zobecnit je tak, aby původní byly jejich speciálními případy. Typickým příkladem, kde je tento přístup aplikován, je objektově orientovaná analýza. Vychází z objektově orientovaného programování. Pohlíží na svět jako na soustavu spolupracujících objektů. Tento přístup je poměrně blízký lidskému chápání a přináší kvalitativní změnu myšlení při návrhu systémů. Výhodou je možnost rychlého paralelního vývoje prototypového softwaru. Nevýhodou je nedostatek ověřených metodických postupů a hlubší zkušenosti s rozsáhlými systémy. Konkrétní metodou využívající přístup k návrhu systému zdola nahoru je UML (Unified Modeling Language), který je popsán v kapitole 2.3.4. Přístup shora dolů je založen naopak na specializaci. Začíná na úrovni komplexního systému, který postupně dekomponuje na subsystémy. Ty jsou dále dekomponovány až na úroveň, kdy je možná implementace. Analytický proces je zobrazitelný stromovou strukturou s originálním systémem v kořeni. Typickým příkladem tohoto postupu je strukturovaná analýza. Je metodicky velmi dobře zvládnuta. Její nevýhodou je absence možnosti ukončit předčasně analýzu a implementovat konkrétní část systému. Konkrétní metodou využívající k návrhu systému metodu přístup shora dolů je SSADM (Structured Systems Analysis and Design Method), která je popsána v kapitole 2.3.5. 2.3.4 UML UML (Unified Modeling Language) je standardizovaným jazykem pro specifikaci, vizualizaci, konstrukci a dokumentování systémů, nejen softwarových. Jeho použití zefektivňuje softwarový proces na základě standardní notace zejména použitím přehledných a snadno pochopitelných diagramů a schémat, čímž snadno překonává sémantickou mezeru mezi vnímáním skutečností uživateli a řešiteli systému. Dále pak slouží ke zlepšení a zpřesnění komunikace mezi členy vývojového týmu (analytici, vývojáři, testeři, vedoucí pracovníci apod.). Jeho výhodou je podpora celého vývojového cyklu software. UML poskytuje pravidla pro pojmenování, rozsah platnosti, rozsah viditelnosti, integritní omezení a provedení modelu. 13
Základní principy UML lze nastínit následujícími body: na každý složitý problém je vhodné nahlížet z více úhlů pohledu každý model může být vyjádřen s různou přesností nejlepší modely jsou spojeny s realitou. Prvky modelů Rozlišujeme prvky struktury, prvky chování a prvky skládání. Prvky struktury tvoří třídy, rozhraní, spolupráce, případy užití, aktivní třída, komponenta, uzel. Prvky chování jsou interakce a stavový diagram. Prvky skládání jsou package a subsystém. Dalším možným prvkem je poznámka. Vztahy mezi prvky jsou popsány závislostmi, asociacemi, dědičností nebo realizací. Způsoby rozšiřování modelů Jedním ze způsobů rozšiřování modelů jsou stereotypy. Stereotyp je šablona určitého typu prvku či vlastnosti. Význam stereotypu definuje autor modelu. Stereotyp se zapisuje mezi závorky << a >>. Stereotypovaný prvek může mít vlastní grafickou reprezentaci. Dalšími způsoby rozšíření modelu jsou přidané atributy, což jsou textové informace přidané k jednotlivým prvkům modelu. Někdy je nutné rozšířit vazby v modelu o určitá omezení. Omezení je přídavná informace upřesňující danou vazbu. Zapisuje se do složených závorek. Lze ji psát přirozeným jazykem, ale existuje také formální jazyk, označovaný OCL (Object Constraint Language), sloužící k zápisu omezení k prvkům objektově orientovaného modelu. Na základě takto vyjádřených omezení lze testovat konzistenci modelu. UML definuje následujících devět typů diagramů, popisující různé pohledy na model systému [6]. Případy užití, tzv. Use Case diagramy Diagramy tříd Diagramy objektů Diagramy komponent Diagramy rozmístění 14
Sekvenční diagramy Diagramy spolupráce Stavové diagramy Diagramy aktivit Prvních pět typů diagramů modeluje statický pohled na systém, zbývající představují pohled dynamický. Diagramy musí být sémanticky konzistentní s dalšími pohledy na systém. 2.3.4.1 Případy užití Případy užití (Use Cases) zachycují funkce, které systém poskytuje svému okolí a definují využití těchto funkcí. Umožňují zadavateli projektu ověřit, zda systém modelovaný pomocí případů užití splňuje představu o funkcionalitě. Zvyšují porozumění systému a určují jeho rozhraní. Slouží jako základ uživatelské dokumentace a různých testů. Případ užití je popsán dokumentem, který obsahuje jméno, stručný popis, tok událostí (základní, alternativní), speciální požadavky, podmínky před a po případu užití, způsoby rozšíření a vizualizace formou diagramů. Diagramy případu užití jsou tvořeny následujícími UML prvky: případy užití jsou ovály, zachycující funkčnosti systému aktéři jsou schematické postavičky, znázorňující aktéry, kteří pracují se systémem (vstupují do něj, používají ho) asociace jsou čáry, představující vazby mezi aktéry a případy užití vztahy jsou čáry opatřené šipkou, určující vazby mezi jednotlivými případy užití. Každý případ užití představuje určitou funkcionalitu systému, která dává měřitelnou hodnotu uživatelům tohoto systému. Aktéři představují určité zachycení okolí systému. Představují prvky aktivně komunikující se systémem. Aktéry mohou být buď uživatelé, či spíše uživatelské role nebo jiné softwarové systémy. Aktér je stereotypem třídy, je to tedy třída. Pomocí Asociace komunikuje aktér se systémem, vyvolává a účastní se případů užití. U diagramů případů užití obvykle nemají asociace přiřazené jméno. 15
Vztahy mezi případy užití umožňují případům užití vzájemnou spolupráci. Jsou definovány dva typy vztahů include a extend. Jsou rozlišeny pomocí tzv. stereotypů, v tomto případě se jedná o stereotyp závislosti. Vazba typu include definuje, že případ užití A musí povinně vykonávat to, co případ užití B, případně něco navíc. Vazba extend znamená, že případ užití A rozšiřuje chování B. B může tedy za určitých okolností provádět funkčnost A. V diagramech případů užití lze zavést vazbu dědičnosti. Jedná se o tzv. generalizaci, která je definována mezi rodičem a potomky. Generalizace mezi dvěma případy užití se využívá v případě, že jeden případ užití je podobný druhému, přičemž se liší v malých částech, nikoliv zanedbatelných. Specifikace rodiče je základem specifikace potomků, tedy obsahuje základní kostru použitou ve všech potomcích. Specifikace potomků upřesňují popis rodiče (každý potomek má jinou funkčnost). 2.3.4.2 Diagramy tříd Diagramy tříd zachycují slovník systému. Třída je zapouzdřením určitých informací a chování. Informace budeme označovat jako atributy třídy a chování jako metody třídy. Atributy třídy představují informace, které instance třídy (objekty) uchovávají. Metody třídy jsou operace, za které je třída zodpovědná, nebo také zprávy, kterým rozumí. Zdrojem atributů třídy jsou věcné znalosti o dané problematice a analýza podrobných požadavků uživatelů. Atributy třídy by měli být atomické, tedy dále nedělitelné, což částečně odpovídá první normální formě E-R modelu. Pokud by měl být atribut strukturovaný, lze ho nahradit vlastní třídou a asociací. Zdrojem pro hledání operací jsou především scénáře analýzy případů užití. Vytváří se model, který zatím nenavrhuje software, ale zjišťuje, co budoucí software musí umět. Mezi třídami mohou existovat různé vztahy. Sdílení informací mezi třídami lze dosáhnout pomocí asociace a agregace. Komunikaci mezi třídami lze zajistit pomocí asociace, agregace a závislostí. Hierarchii tříd lze vybudovat pomocí vazeb asociace, agregace, dědičnosti a realizace interface. Asociace je slabá vazba mezi třídami. Říká to, že dvě třídy mají mezi sebou vztah, tedy o sobě vědí. Není-li uvedeno jinak, je tato vazba obousměrná. Asociace může mít své jméno, které většinou dává smysl při čtení jedním směrem. Kreslí se plnou čarou spojující příslušné objekty. 16