Složitost IS.

Prezentace na téma: "Složitost IS."— Transkript prezentace:

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 Po dokonč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.

13

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, ,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 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

22

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 Po dokonč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
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í.