Složitost IS

1. Složitost IS

2. pojmy • Stupnice: • Absolutní – měřená hodnota vyjádřena poměrem k nějakému celku ( např. %) • Poměrová – výpočet míry celku ze známých komponent (průměr, rozptyl) • Intervalová (např. stupnice teploty) • Ordinální – subjektivní odhad a pouhé porovnání • Nominální – klasifikace do tříd bez závěrů

3. Metriky • vnitřní – data se získávají analýzou návrhu kódu • vnější – data se získávají za běhu programu

4. Jakost IS • Atribut – měřitelná fyzická či abstraktní vlastnost entity. • Funkčnost • = schopnost IS či softwarového produktu obsahovat funkce, které zabezpečují předpokládané či stanovené potřeby uživatele při užívání systému • Přiměřenost – schopnost poskytovat funkce pro zajištění úloh a potřeb. • Přesnost – schopnost poskytnout správné výsledky s potřebnou úrovní přesnosti • Schopnost spolupráce – spolupráce s jedním či více jinými specifikovanými systémy • Bezpečnost – chránit informace a data proti neautorizovanému čtení, změně • Shoda funkčnosti – pracovat ve shodě s normami, standardy, zákony, konvencemi

5. Bezporuchovost • = schopnost zachovat specifikovanou úroveň výkonu • Zralost – schopnost vyvarovat se poruchám v důsledku závad systému nebo důsledky takovýchto selhání minimalizovat • Odolnost vůči vadám – schopnost zachovat si při selhání nebo při nedodržení požadovaného rozhraní určitou úroveň výkonu (služeb) • Schopnost zotavení – schopnost obnovit úroveň výkonu a zachovat data po odstranění poruchy • Shoda v bezporuchovosti

6. Použitelnost • = schopnost být srozumitelný, snadno obsluhovatelný a atraktivní • Srozumitelnost – vlastnost, která umožňuje rozhodnout se, zda se systém hodí pro řešení konkrétních problémů a úloh uživatele a za jakých podmínek. • Naučitelnost –vlastnost charakterizující míru úsilí, potřebné vynaložit pro rutinní využívání SW • Provozovatelnost – vlastnost, usnadňující jeho obsluhu a řízení práce se systémem. • Atraktivnost – schopnost umožnit příjemnou obsluhu a učinit jeho používání přitažlivým. • Shoda v použitelnosti

7. Účinnost • = poskytovat potřebný výkon vzhledem k množství použitých zdrojů, za stanovených podmínek • Časové chování – schopnost zajistit požadovanou propustnost úloh za dané časové období, dobu výpočtu nebo odezvu systému • Využití zdrojů –charakteristic. počet typů a množství zdrojů, potřebný k zabezp. práce systému • Shoda v účinnosti

8. Udržovatelnost • = schopnost být modifikován (opravy nedostatků, vylepšování, adaptace na prostředí, změny) • Analyzovatelnost – schopnost usnadnit nalezení závady v případě poruch a schopnost určit, co má být změněno pro odstranění závady • Měnitelnost – schopnost systému usnadňující provedení modifikace • Stabilnost – schopnost zabránit nežádoucím efektům provedených modifikací • Testovatelnost – schopnost zabezpečit snadnou validaci po provedení modifikace • Shoda v udržovatelnosti

9. Přenositelnost • = schopnost být přenesen z jednoho prostředí do jiného • Přizpůsobitelnost – schopnost být vlastními prostředky v průběhu používání přizpůsoben různým prostředím. • Instalovatelnost – vlastnost být instalován tak, aby vyhovoval práci v konkrétním prostředí • Slučitelnost – schopnost pracovat společně s jinými systémy v témže prostředí a využívat společné zdroje • Nahraditelnost – schopnost nahradit funkci jiných systémů, určených pro stejný účel a pracujících ve shodném prostředí • Shoda v přenositelnosti

10. Hodnocení složitosti IS • Výpočetní složitost • Není to úsilí potřebné k navržení algoritmu, ale pracnost a nároky na jeho provedení. • Časová – závislost doby na provedení úlohy na rozsahu úlohy (počet kroků turingova stroje, aby úlohu vyřešil) • Prostorová – závislost spotřebované paměti na rozsahu úlohy (závislost použité oboustranné pásky turingova stroje na rozsahu úlohy) • Modul – samostatná jednotka, kterou je možné spojovat s dalšími moduly (algoritmus, objekt) • Programování v malém – nižší úroveň návrhu, realizace jednotlivých modulů • Programování ve velkém – vyšší úroveň, řešení vztahů mezi moduly • Směr programování shora-dolů (programování ve velkém –> programování v malém)

11. Hodnocení složitosti IS v různých etapách životního cyklu • Na začátku (specifikace) – použití funkčních jednic • V průběhu programování – graf řízení, hierarchický rozklad atd., objektová složitost • Podokončení – metody založené na počtu řádků kódu atd.

12. Složitost v etapě specifikace • Hodnocení složitosti v etapě specifikace nebo před ní je obtížné protože nevíme co budeme řešit nebo jak. Známe však obecné postupy (metoda funkčních jednic) pomocí kterých můžeme určit složitost.

14. Funkční jednice • Složit. je odhadována na základě dvou faktorů – na funkcích a podmínkách. Jako součin funkcí, které jsou od produktu vyžadovány a podmínek, které jsou pro vytvoření produktu. • Objem funkcí V, odhadneme tak, že zjistíme počty: • IN, OUT – počet log. různých vstupů ; FILE – počet interních log. souborů ; INTF – počet log. souborů sdílených ; INQ – počet log. různých výstupů s čekáním na vstup (dotazů) • Stanovíme váhy pro jednotlivé počty a výslednou složitost získáme jako součet všech těchto jednic • Zjistíme podmínky realizace, když vezmeme v úvahu faktory oklasifikované př. dle ord. st. (0-5). Hodnocení sečteme a získáme PF a hodnocení podmínek dle faktorů získáme vzorcem: F = 0,65 + 0,01 . PF Výsledná složitost ve funkčních jednicích se pak počítá: FP = b . V . F, kde beta je konstanta závisející na jednotkách, v kterých byla složitost měřena.

15. Složitost projektování v malém • Složitost lze zjišťovat na základě: • Fyzikálních údajů software (počet řádků programu atd.,) - vstupní data pro složitost jsou až po implementaci • Grafu řízení algoritmu (programu) – příkazy dělají totéž, ale jsou různě složité, zneužití programátorem při hodnocení práce • Strukturálního rozkladu algoritmu

16. Hodnocení složitosti na základě analýzy grafu řízení • Atomické transformace grafu řízení (graf řízení) • Drobné změny grafu řízení. Slouží pro posouzení, do jaké míry metrika vycházející z grafu řízení dobře či špatně odráží naši představu o složitosti (nově doplněný uzel do grafu, doplnění hrany do grafu) • McCabeovy metriky v grafu řízení (graf řízení) • Tato míra je zvaná též cyklomatická složitost grafu řízení. Udává max. počet „lineárně nezávislých“ cest z uzlu Z do K. Každá cesta od Z do K prochází některými hranami grafu(některými i vícekrát). Lze ji tedy přiřadit vektor card(H), který bude udávat, kolikrát byla při této cestě užita daná hrana. Cesta prochází při testu složitosti každou hranou alespoň jednou. • MCC (G) = card (H) – card (V) + 2

17. Harrisonova, Mengelevova metrika SCOPE (graf řízení) • Metrika každému uzlu přiřazuje č. NL(x) – hloubka vnoření uzlu. • NL(x) = PŘED(x)+1 , kde PŘED(x) je počet uzlů, které mohou ovlivnit provedení uzlu x. Celková složitost SCOPE (G) je pak součtem x NL (x).

18. Piwowarsky (graf řízení) • Bere v úvahu ne všechny, ale jen rozhodovací uzly. Každému z nich se přidá Piw. doplňková složitost. Ta se rovná počtu kontextu jiných rozhodovacích vrcholů, v kterých uvažovaný vrchol leží. PIWO (G) = card (H) +  NL (x) + 1

19. Hodnocení složitosti na základě přehledného hierarch. rozkladu • výhody • hierarch. rozklad se opírá o postup shora dolů • není příliš snadné přizpůsobit uměle návrh, aby při hodnocení bylo dosaženo výsledků dle přání řešitele • nevýhody • metodu lze užít jen pro strukturovaný návrh

20. Rozklad na přehledně mnoho dílčích položek (například 7). Rozklad lze provádět selekcí, sekvencí, iterací atd. Návrh se jeví jako orientovaný graf, který je orientovaný strom. Má vrchol – kořen (řešený program), listy (akce, příkazy programovacího jazyka) a další dílčí celky. U každého uzlu máme k dispoz. údaje na základě kterých můžeme stanovit příspěvek daného uzlu ke složitosti: • a) Hloubka vnoření (počet hran od kořene k uzlu) • b) Typ uzlu (selekce, iterace, sekvence) • c) exekutivní složitost zpracování daného příkazu • d) Složitost předávaných dat, jejich objem a strukturu • Součet složitostí a,b,c,d nám udává příspěvek tohoto vrcholu k celkové složitosti. Sečtením hodnot pro vš. vrcholy stromu dostaneme celkovou složitost návrhu daného modulu

21. Složitost projektování ve velkém • Složitost spolupráce modulů je tím jednodušší, čím se podaří dodržet následující zásady • Soudržnost modulů – každý modul řeší pouze vzájemně svázané úkoly, které spolu úzce souvisejí (jediná metrika v ordinální stupnici) • Funkční soudržnost • Sekvenční soudržnost • Komunikační soudržnost • Procedurální soudržnost • Logická soudržnost • Náhodná soudržnost

23. Spřaženost modulů – dva různé moduly spolu spolupracují jednoduchým a snadno srozumitelným způsobem. Hodnocení pomocí fentonových stupnic: • Prvá – hodnotí typ komunikace (1-nespoluprac. až 7 –zasahují si do programových kódů) • Druhá – hodnotí objem komunikace, jako přirozené č. N – počet předávaných či sdílených objektů.

24. Složitost v objektovém prostředí • Chidamver a Kemerer navrhli metriku, která řeší jen programování ve velkém. Intramodulární složitost je třeba stanovit klasickými metrikami pro programování v malém

25. metriky: • Váha metod pro třídu WMC – součet složitosti cj všech metod třídy C. • Hloubka stromu dědičnosti DIT – max délka cesty od kořene stromu k uzlu, který odpovídá dané třídě • Počet synů NOC – počet přímých potomků uzlu, který ve stromu dědičnosti představuje třídu C • Spřažení mezi třídami CBO – udává počet tříd, na nichž závisí třída C tím, že volá jejich metody • Odezva třídy RFC – počet metod které třída C volá(vlastní i z jiné třídy) • Nedostatečná soudržnost tříd v metodách – LCOM

26. Složitost v etapě implementace a provozu • Po implementaci programového produktu či IS. • Délka programu – metriky typu LOC – počet řádků zdroj. kódu • Halsteadovy metriky – složitost na zákl. počtu elementárních binárních rozhodnutí, ke kterým dojde při sestavování textu programu.

27. Odhady pracnosti IS v různých etapách životního cyklu • Na začátku (specifikace) – použití funkčních jednic • V průběhu programování – graf řízení, hierarchický rozklad atd., objektová složitost • Podokončení – metody založené na počtu řádků kódu atd.

28. Pro další úvahy bereme složitost jako počet řádků. Vliv větvení atd. je zohleděn vynásobením vhodnou konstantou. • Do návrhů na pracnost zahrnujeme i dokumentaci. Údržba, rozšiřování funkcí a školení uživatelů se musí zahrnout zvlášť, dle konkrétní situace. • Při posuzování pracovní náročnosti musíme brát v úvahu, že části programů nelze dělit na nekonečné množství samostatně vypracovávaných částí. (Příklad se zedníkama a zdí) • Pracnost v závislosti na objemu software roste superaditivně. tzn. Rychleji než lineárně, což vede ke krizi software a řešením je právě objektové programování.