Tvorba informačných systémov 3. prednáška modely vývoja informačných systémov
Špecifikácia požiadaviek cieľ: vytvorenie uceleného katalógu požiadaviek na produkt (t.j. čo zadávateľ od produktu požaduje) výsledok (špecifikácia požiadaviek) obsahuje: popis funkcií produktu popis údajov, s ktorými produkt pracuje ostatné vlastnosti produktu a obmedzenia naň kladené (tzv. nie funkčné požiadavky) špecifikácia je záväzná pre zadávateľa aj riešiteľa
Spiral model of the RE process D e c i s i o n p o i n t : A c c e p t d o c u m e n t o r r e - e n t e r s p i r a l I n f o r m a l s t a t e m e n t o f r e q u i r e m e n t s R e q u i r e m e n t s e l i c i t a t i o n R e q u i r e m e n t s a n a l y s i s a n d n e g o t i a t i o n R e q u i r e m e n t s d o c u m e n t a n d v a l i d a t i o n r e p o r t S T A R T A g r e e d r e q u i r e m e n t s R e q u i r e m e n t s v a l i d a t i o n R e q u i r e m e n t s d o c u m e n t a t i o n D r a f t r e q u i r e m e n t s d o c u m e n t 3
Návrh určenie, ako bude daný SW produkt realizovaný návrh prechádza rôznymi etapami (iteratívne) architektonický návrh (rozdelenie na subsystémy) návrh štruktúry subsystémov (rozdelenie na moduly) návrh modulov (rozdelenie na triedy, resp. funkcie) v rámci návrhu sa robí tiež návrh používateľského rozhrania návrh štruktúry spoločnej databázy (stanovenie použitých algoritmov) zaznamenať rozhodnutia! (pre budúcu údržbu) 4
Implementácia naprogramovanie jednotlivých modulov vytvorenie dokumentácie spravidla sa prekrýva s poslednými etapami návrhu (s výnimkou napr. kritických systémov) za súčasť implementácie je považované aj neformálne testovanie a oprava chýb programátorom 5
Validácia (verifikácia a validácia) verifikácia: overenie, že (medzi)produkt spĺňa špecifikované požiadavky (nonconformability) validácia: overenie, že (medzi)produkt spĺňa očakávania používateľa (defects) vykonáva sa v celom procese vývoja SW, avšak najviac prostriedkov sa na V&V vynakladá po implementácii 6
Evolúcia je integrálnou súčasť vývoja treba na ňu myslieť od začiatku pri špecifikácii, pri návrhu, pri písaní kódu, pri dokumentácii 7
Riadenie projektu odhadovanie plánovanie (čas, peniaze, ľudia, technika) organizácia práce sledovanie realizácie plánu a prijímanie potrebných opatrení práca s ľuďmi: výber, motivácia,... 8
Zabezpečovanie kvality zabezpečovanie kvality procesu príprava štandardných pracovných procedúr, najmä procedúr v oblasti V&V kontrola ich uplatňovania meranie efektívnosti procesu 9
Správa konfigurácií a riadenie zmien zabránenie nekontrolovaným zmenám vo vytváraných dokumentoch a programoch všetky dokumenty sú v skrini, ku ktorej je regulovaný prístup zmeny v už vytvorených dokumentoch podliehajú zvláštnemu schváleniu 10
Atribúty procesu vývoja SW = Životný cyklus SW Proces vývoja SW (a čiastočne aj jeho model) má nasledujúce atribúty: pochopiteľnosť viditeľnosť možnosť podpory nástrojmi CASE rýchlosť Nie je možné všetky optimalizovať naraz (napr. rýchlosť vs. viditeľnosť) 11
Všeobecné modely procesu vývoja softvéru vodopádový model evolučný model inkrementálny model vývoj s opakovaným použitím komponentov vývoj formálnymi metódami špirálový model Unified process & Rational unified process agilné metódy open source 12
Vodopádový model Sekvenčne usporiadané etapy zodpovedajúce jednotlivým aktivitám pred začatím etapy musí byť predchádzajúca etapa ukončená (vrátane dokumentácie) návrat je často nevyhnutný (napriek snahe vyhnúť sa mu) Historicky prvý explicitný model procesu (1970), vychádza z procesu v ostatných disciplínach Existuje mnoho variantov
Vodopádový model
Prednosti a nedostatky Prednosti: disciplína dokumentácia viditeľnosť požiadavky sú známe vopred (pred návrhom a implementáciou) Nedostatky: všetky požiadavky treba špecifikovať hneď na začiatku: riziko nesprávneho určenia požiadaviek návraty k predchádzajúcim etapám sú náročné (prepracovávanie a schvaľovanie dokumentov) konkrétne: zmena požiadaviek je ťažko realizovateľná všetko alebo nič Vodopádový model by mal byť použitý len vtedy, keď sú požiadavky na produkt dostatočne jasné.
Evolučný vývoj
Dva druhy evolučného vývoja: prieskumný vývoj (exploratory development) výsledok vývoja sa použije v prevádzke jednorazový prototyp (throw-away prototyping) výsledok sa použije na objasnenie požiadaviek a zahodí sa
Prednosti a nedostatky Prednosti: špecifikácia je vyvíjaná postupne (využijú sa skúsenosti používateľov získané počas prevádzky) Nedostatky: proces nie je viditeľný (neoplatí sa vytvárať dokumenty pre jednotlivé verzie) štruktúra produktu nie je optimálna (vďaka neustálym zmenám) Tento prístup je vhodný pre malé (do 100 KLOC) a stredne veľké (do 500 KLOC) systémy s krátkou dobou života.
Inkrementálny vývoj kombinuje disiplínu, viditeľnosť a manažovateľnosť vodopádového modelu možnosť postupne špecifikovať požiadavky vlastnosť evolučného vývoja charakteristika prístupu: vývoj SW produktu prebieha po jednotlivých inkrementoch inkrement je časť celkovej funkčnosti produktu (do 20 KLOC) zmysluplná pre zákazníka
príklady: predaj kníh cez internet práca s katalógom kníh (zobrazenie, vyhľadávanie,...) registrácia používateľov objednávanie kníh... operačný systém scheduler nie: file system... používateľské rozhranie modul pre prácu s databázou...
proces vývoja pre jednotlivé inkrementy môže byť rôzny
Prednosti a nedostatky Prednosti: prevádzkyschopný medziprodukt je k dispozícii rýchlo skúsenosti s prevádzkou pomáhajú pri špecifikácii požiadaviek lepšia návratnosť investícií možnosť nasadzovať po častiach keď sa vývoj neukončí, je k dispozícií aspoň čiastočný výsledok Nedostatky: v porovnaní s vodopádovým modelom náročnejší na riadenie nezodpovedá úplne štandardnému modelu objednávania (zmluva jej plnenie) vzhľadom na to, že detailné požiadavky nie sú známe vopred, môže byť problémom vytvoriť optimálne jadro spoločné pre celý systém
Vývoj s opakovaným použitím komponentov Štandardný prístup (neformálne opakované použitie) komponenty sa hľadajú pri návrhu alebo pri implementácii Vývoj s opakovaným použitím komponentov: komponenty sa hľadajú už pri špecifikácii
Prednosti a nedostatky Prednosti: nádej na výrazné ušetrenie času a prostriedkov (a zníženie rizika) Nedostatky: nutné sú kompromisy v oblasti požiadaviek (prispôsobenie sa existujúcim komponentom) istá strata kontroly nad budúcim vývojom a podporou produktu (nemožnosť ovplyvniť vývoj použitých komponentov)
Vývoj formálnymi metódami môže byť súčasťou iného (napr. inkrementálneho) modelu
dokázať správnosť čiastkových transformácií je jednoduchšie než dokázať správnosť implementácie vzhľadom k formálnej špecifikácii tento prístup bol úspešne aplikovaný v praxi dosiahla sa vysoká kvalita náklady na vývoj sa podstatne nelíšili od iných prístupov je vhodný pre vývoj (sub)systémov s vysokými požiadavkami na spoľahlivosť a bezpečnosť
Špirálový model Určenie ktitických cieľov a obmedzení produktu vyhodnotenie alternatív projektu a procesov, ktorými sa ciele dosiahnu Určenie rizík Prijatie ekonomicky výhodných riešení pre časť rizík, využívajúc analýzu, emuláciu, benchmarky, modely a prototypy Vytvorenie špecifikácie požiadaviek, návrhu, implementácia a testovanie Plánovanie ďalšieho a nasledujúcich cyklov, aktualizácia celkového plánu projektu, vrátane časového plánu, ceny, a počtu zostávajúcich iterácií stakeholderi zhodnotia dodané výsledky, zaviazanie sa pre ďalšie fázy podľa toho, ako ich ciele boli doposiaľ splnené 1
Špirálový model 2
Unified Process & Rational Unified Process Jacobson+Booch+Rumbaugh, 1999 Objectory + Booch + OMT IBM Rational Software Use-case driven, architecture-centric, iterative and incremental Short iterations (3 weeks), 9 disciplines 3
Unified SW Development Process 4
Unified SW Development Process Inception: establish feasibility, make business case, establish product vision and scope, estimate cost, schedule, and milstones, asses critical risks, build one or more prototypes Elaboration: specify requirements in greater detail, create architecutral baseline, perform iterative implementation of core architecture, refine risk assessment and resolve highest risk items, define metrics, refine project plan, including detailed plan for beginning Construction iterations 5
Unified SW Development Process Construction: complete remaining requirements, do iterative implementation of remaining design, thoroughly test and prepare system for deployment Transition: conduct beta tests, correct defects, create user manuals, deliver the system for production, train end users, customers and support, conduct lessons learned Advantages: most aspects of project are accounted for, mature Disadvantages: too complex for small projects 6
Unified SW Development Process Objectives 7
Nástroje pri analýze, návrhu a implementácii Správa projektu Modelovanie pomocou diagramov CASE Správa verzií súborov Podpora testovania
CASE Computer Aided Software Engineering nástroje podporujúce proces vývoja, napr. špecifikácia požiadaviek upper CASE zachytenie návrhu generovanie kódu editovanie programov (inteligentné editory) generovanie a vyhodnocovanie testov debugovanie automatická analýza programov lower CASE
Architektúra softvérového systému Architektúra = umenie Architektúra softvérového systému je štruktúra alebo štruktúry systému, ktorá zahŕňa softvérové elementy, zvonku viditeľné vlastnosti týchto elementov a relácie medzi nimi Element: podsystém, modul, trieda, databáza, databázová tabuľka, Štruktúra systému: design-time alebo run-time, vzťahy a interakcie elementov Statická softvérové elementy, dátové elmenty, hardvérové elementy Dynamická: tok informácií medzi elementaimi, sekvenčné alebo paralelné vykonanie úloh, akcie na dátach
Architektonické pohľady na systém Funkčný pohľad opisuje funkčné elementy systému, ich zodpovednosti, rozhrania a interakcie Informačný pohľad opisuje spôsob ako systém ukladá, spravuje a distrubuuje informácie Konkurenčný pohľad identifikuje elementy systému, ktoré sa vykonávajú paralelne a súťažia o rovnaké zdroje, spolu so spôsobom riadenia tohto konkurenčného správania Vývojový pohľad opisuje elementy (moduly), do ktorých je členený kód programu a vzájomné väzby elementov Pohľad zavádzania systému opisuje prostredie do ktorého bude systém zavedený, vrátane závislostí, ktoré má systém na tomto prostredí Prevádzkový pohľad opisuje ako sa bude systém prevádzkovať, administrovať, udržiavať v prevádzkovom prostredí
Význam členenia na rôzne pohľady Oddelenie vecí (separation of concerns) Zníženie zložitosti Efektívnejšia komunikácia s rôznymi skupinami zákazníka (doménoví odborníci, pracovníci prevádzky) Zameranie vývojového tímu
Modely softvérových systémov Model je abstrakcia alebo zjednodušená reprezentácia niektorého aspektu architektúry na komunikáciu týchto aspektov so zákazníkom Lepšie porozumenie situácii Prostriedok na komunikáciu Umožňujú analyzovať situácie Pomáhajú pri riadení vývoja
Modelovacie jazyky Špecializované jazyky Všeobecné jazyky Neformálne notácie Zaužívaný štandard združenia OMG s názvom UML Predovšetkým rôzne druhy diagramov Nie je kompletný, je zameraný na objektový návrh
Entitno-relačný diagram Entity http://www.umsl.edu/~sauterv/analysis/er/er_intro.html Relácie Atribúty
Diagramy UML Diagram tried Diagram objektov Diagram používateľských scenárov Sekvenčný diagram Diagram komunikácie Stavový diagram Diagram činností Diagram komponentov Diagram rozmiestnenia elementov
Diagram tried (class diagram) Diagram tried tvorí množina tried, rozhraní a ich vzťahov. Z hľadiska architektúr ide o hlavný jazyk na modelovanie informačného pohľadu na softvérový systém. Diagram tried však modeluje iba statickú štruktúra a nezahŕňa dynamickú štruktúru informačného pohľadu.
Diagram objektov (object diagram) Diagram objektov obsahuje množinu objektov (inštancií) a ich vzťahov. Z hľadiska architektúry ide o doplnkový jazyk, ktorý sa v určitých prípadoch používa na tvorbu príkladov vzťahov inštancií podľa daigramu tried.
Diagram používateľských scenárov (use case diagram) Zobrazuje množinu používateľských scenárov a ich aktérov. Je doplnkovým jazykom na modelovanie funkčného pohľadu. Diagram používateľských scenárov sa však používa predovšetkým na opis funkcionality v počiatočných etapách analýzy pred dekomponzíciou na elementy architektúry.
Sekvenčný diagram (sequence diagram) Ukazuje interakcie medzi objektmi, ktoré majú formu posielania správ. Je špeciálnym prípadom interakčného diagramu s dôrazom na časovú postupnosť posielania správ. Môže slúžiť ako doplnkový jazyk na modelovanie funkčného pohľadu. Sekvenčný diagram sa však používa najmä na modelovanie priebehu interakcie medzi elementmi na nízkej úrovni (objektami tried)
Diagram komunikácie (communication diagram) Podobne ako sekvenčný diagram je špeciálnym prípadom interakčného diagramu. Na rozdiel od sekvenčného diagramu sa sústreďuje na organizáciu objektov. Z hľadiska architektúry má rovnakú úlohu.
Stavový diagram (State diagram) Obsahuje množinu stavov, prechodov medzi stavmi a súvisiace udalosti a činnosti. Z hľadiska architektúry ide o doplnkový jazyk na modelovanie informačného pohľadu (modelovanie životného cyklu elementu) alebo konkurenčného pohľadu.
Diagram činností (activity diagram) Zobrazuje tok riadenia (prípadne tiež tok údajov) medzi aktivitami. Môže slúžiť ako doplnkový jazyk na modelovanie funkčného pohľadu. Jeho hlavné využitie však nie je architektonické. Slúži na modelovanie krokov výpočtu funkcie alebo procesné modelovanie.
Diagram komponentov (component diagram) Ukazuje organizáciu a závislosti medzi komponentmi (architektonickými elementmi). Diagram komponentov je hlavný jazyk na modelovanie funkčného pohľadu aj vývojového pohľadu.
Diagramy rozmiestnienia elementov (deployment diagram) Zobrazuje konfiguráciu výpočtových vrcholov v čase vykonávania programu (run-time) a komponentov, ktoré sú v nich umiestnené. Je to hlavný jazyk na modelovanie pohľadu zavádzania systému. Poznámka: na rôznych úrovniach...