Softwarové inženýrství se zabývá teoriemi, metodami a nástroji pro profesionální vývoj softwaru.
Generické produkty – prodávány všem zákazníkům, kteří si je přejí koupit (grafické progrmy, CAD software)
Customized products – vytvářeny na míru zákazníkovi (vestavěné systémy, systémy kontrolující dopravu)
Stand-alone applications, Embedded control systems, Batch processing systems, Entertainment systems, …
Pozitiva: Vytvořením zevrubné dokumentace se usnadňuje zapojení nových členů do týmu a snižuje závislost na jednotlivých řešitelích. Jednoduše manažersky uchopitelný.
Negativa: Vytváření podrobné dokumentace zabere kapacity, které by byly jinak využitelné. Odhalení chyby či změna v požadavcích v pozdní fázi je velmi nákladné a vyžaduje revizi všech ostatních kroků. Některé technologické limitace, požadavky či rizika nemusí být možné odhalit včas.
Specifikace SW požadavků je začátkem procesu tvorby SW. Obecně se považuje za počáteční vstup k objektové analýze a k následnému objektovému návrhu.
Požadavky uživatelů (User requirements) – tvrzení v přirozeném jazyce a diagramy služeb poskytované systémem a omezení, pro zákazníky.
Požadavky systému (System requirements) – strukturovaný dokument s detailním popisem funkcí systému. Definují, co by mělo být součástí systému.
Formulace toho, co by měl systém dělat. Popisují požadovanou funkci systému. (např. Bankomat bude ověřovat validitu platební karty. Bankomat vydá na každou kartu maximálně 1000 Kč za 24 hodin.)
Omezující podmínky uvalené na daný systém či vlastnost systému. (např. Řídicí systém bankomatu bude napsán v jazyce C++. Řídicí systém bankomatu ověří validitu PIN kódu maximálně do pěti sekund.)
Nefunkční požadavky ovlivňují celou architekturu systému spíše než individuální komponenty. Jeden nefuknční požadavek může vytvářet mnoho dalších souvisejících funkčních požadavků.
Metriky – rychlost, velikost, spolehlivost, robustnost, přenositelnost, …
Obsahuje co by měl systém dělat, spíše než jak by to měl systém dělat. Informace v dokumentech závisí na typu přístupu k tvorbě systému (plan-driven vs. agile approach).
Expresivní, intuitivní, unverzální. Problémy – nejasnosti, zmatek (funkční a nefunkční požadavky mohou být pomíchany), slučování.
Založeny na tabulkách a formulářích.
Identifikace aktérů a interakcí.
Spolupráce s uživateli systému. Hledáme: aplikační doménu, služby poskytované systémem, výkon systému, HW omezení, …
Requirements prioritisation – MoSCoW criteria – Must have, Should have, Could have, Want to have.
Problémy – uživatelé často nevědí, co chtějí; různí uživatelé mohou mít konfliktní požadavky; mohou nastat změny požadavků během analýzy; organizační a politické faktory mohou ovlivňovat požadavky.
Formální a neformální interview. Typy: otevřená interview, uzavřená interview.
Sběr dat v rámci terénního výzkumu.
Prototypování, testování, Reviews – formální a neformální; kontrola srozumitelnosti (Comprehensibility), návaznosti (Traceability), přizpůsobivosti (Adaptability).
Správa požadavků je proces udržování a kontrolování změn.
Diagram případu užití představuje způsob zachycení funkčních požadavků na sysém. Hledáme:
Role přidělené vnějším entitám, které přímo komunikují se systémem. Nejedná se o konkrétní osoby nebo objekty. Jeden objekt může zastávat více rolí současně.
Kdo používá daný systém? Jakou roli hrají při této interakci? Jaké další systémy spolupracují se systémem? Kdo získává/poskytuje informace? Dochází k nějaké události v pevně daném čase?
Popisují chování systému při interakci s externími aktéry. Akce, které aktér požaduje od systému. Případy užití začínají nějakou akcí aktéra, jsou psány z pohledu aktérů.
Jaké funkce požaduje aktér od systému? Ukládá a získává nějaké informace? Co se stane při změně stavu systému? Existují externí události, které ovlivňují daný systém?
Obsahuje název, jedinečný identifikátor, krátký popis, aktéry (hlavní, vedlejší), vstupní podmínky, hlavní scénář, výstupní podmínky, alternativní scénáře.
Vyčlenění chování, které je společné dvěma a více aktérům. Rodičovský aktér je obecnější než jeho potomci. Rodičovský aktér je často abstraktní. Používáme, jen pokud to zjednodušší model.
Umožňuje funkce společné více případům užití vyčlenit do rodičovského případu užití. Odvozené případy užití dědí všechny vlastnosti od svých předků – aktéry, relace, vstupní a výstupní podmínky, tok událostí, … Odvozené případy užití mohou být doplněny o nové funkce a vlastnosti, mohou také překrývat zděděnou charakteristiku.
Relace <<include>> umožňuje kroky opakující se v několika tocích případů užití vyčlenit do samostatného případu užití, který bude moci zahrnout v případě potřeby do bázového případu užití.
Relace <<extend>> přidává do existujícího případu užití nové chování. Bázový případ užití obsahuje místa rozšíření, která jsou umístěna v samostatné vrstvě překrývající hlavní scénář. Bázový případ užití je úplný i bez vkládaných segmentů (neví o nich vůbec nic).
Pravděpodobnost, že systém bude fungovat a dodávat požadovanou službu. Souvisí s:
Může být vyjádřena kvantitativně.
Pravděpodobnost, že systém bude dodávat službu. Souvisí s:
Může být vyjádřena kvantitativně.
Je možné mít systém s nízkou spolehlivostí, který ale musí být dostupný.
Schopnost systému pracovat bez kritickén chyby.
Safety and reliability jsou podobné, ale ne stejné. Existují “unsafe reliable systems”.
Schopnost systému bránit se náhodným nebo mířeným útokům. Ohrožení důvěrnosti systému a dat, integrity systému a dat, dostupnosti systému a dat.
Zabezpečení je nezbytný předpoklad pro dostupnost, spolehlivost a bezpečnost.
Souvisí s časováním – odpovědi na události (přerušení, zprávy, požadavky).
Souvisí s cenou za změnu (cost of change). Co se může změnit? Kdy je změna provedena a kým?
Jak je snadné zjistit chybu pomocí testování?
Jak je pro uživatele snadné provést požadovaný úkon a jaká je poskytována uživatelská podpora?
Diagramy aktivit lze používat k modelování mnoha různých procesů. Jsou objektově orientovanými vývojovými diagramy. Dobrý diagram aktivit popisuje jeden konkrétní aspekt chování systému. Často jsou připojeny k případům užití, třídám, rozhraním, komponentám, spolupracím, operacím.
Aktivity jsou sítěmi uzlů spojených hranami. Kategorie uzlů:
Hrany reprezentují tok skrz aktivitu. Kategorie hran:
Tokeny postupují po síti a mohou představovat: postup řízení, objekt či určitá data.
Tokeny postupují od zdrojového k cílovému uzlu skrze hrany v závislosti na:
Jedná se o obecný způsob seskupování souvisejících akcí. Často představují jednotlivé případy užití při použití vztahů <<include>> a <<extend>>.
Základní i vložený případ užití mají své vlastní oddíly (plavecké dráhy).
Pokud je bod rozšíření mezi Akce1 a Akce2, za Akce1 se vloží rozhodovací uzel, ze kterého se umožní jeden přechod do Akce2 a druhý přechod do rozšiřujícího případu užití. Po jeho ukončení se přejde do Akce2. Každý případ užití může být ve vlastní plavecké zóně.
Jsou spouštěny, mají-li na všech svých vstupních hranách tokeny a jsou-li zároveň splněny všechny jejich vstupní podmínky. Po dokončení nabízejí akční uzly své tokeny simultánně na všech výstupech, jejichž podmínky jsou splněny.
Řídí postup v rámci aktivity.
Zastupují instance klasifikátoru.
Vstupní a výstupní hrany jsou cestami objektů – zastupují jejich postup. Výstupní hrany objektového uzlu soutěží o každý výstupní token. Objektové uzly se chovají jako vyrovnávací paměť. Mohou zastupovat objekty v určitém stavu (musí být konzistentní se stavovým automatem).
Jsou to objektové uzly, které označují vstupy do aktivity nebo výstupy z nich. Jsou kresleny tak, aby překrývaly obklopující rámeček aktivity. Vstupní parametry mají jednu nebo více hran směřujících do aktivity. Výstupní parametry mají jednu nebo více hran směřujících z aktivity.
Jsou to objektové uzly zastupující jeden vstup nebo jeden výstup akce nebo aktivity.
Analýza spočívá v tvorbě modelů, jež zachycují podstatné požadavky a charakteristické rysy požadovaného systému. Design kombinuje analytické modely s implementací. Implementace je proces realizace designu jako programu.
Proces zahrnuje aktivity jako: definování kontextu a modelů použití systému, načrtnutí architektury, identifikaci systémových procesů a entit, tvorbu modelu, specifikaci rozhraní pro komponenty a objekty, dokončení architektury.
Návrh architektury (architectural design) by měl začínat systémovou analýzu nebo končit design systému (často obojí).
Identifikace systémových entit (objektové třídy v OO analýze), jejich rolí a vztahů.
Řízena pomocí Function oriented view v souladu s Data oriented view pomocí funkční dekompozice.
Řízena pomocí Object oriented view.
Rozdělění projektu na malé, dobře definované aktivity a definování pořadí a interakcí aktivit. Efektivní v projektech strukturovaných do malých částí.
Modelování systému jako skupiny interagujících objektů. Každý objekt představuje entity a je charakterizován třídou, stavem a chováním.
Tvorba analytického modelu – co systém dělá, ne jak do dělá. Identifikujeme analytické třídy a realizaci případů užití. Každý objekt je instancí třídy.
Soudržné jednotky, v nichž se snoubí data s funkčností. Objekt zapouzdřuje data. Všechny objekty mají:
Jedná se o ukrývání dat uvnitř objektu poskytující možnost manipulace s nimi prostřednictvím funkcí poskytovaných příslušným objektem.
Objekty jsou instancemi tříd. Tvorba instance je proces, v němž jako šablonu k tvorbě nového objektu používáme třídu.
K tvorbě nových objektů používáme konstruktory. Ty nastavují nebo inicializují objekty. Mají platnost třídy.
Poskytuje přesný a výstižný způsob vyjádření určitých obchodních omezení vztahující se k počtu předmětů účastnících se relace.
Atributy a operace instance se vztahují pouze ke specifickým objektům. Operace instance mohou používat další atributy nebo operace instance. Operace instance mohou používat všechny atributy a operace mající platnost třídy. Atributy a operace se vztahují na celou třídu objektů.
Analytické třídy vyjadřují velmi přesné definované zobecnění entity problémové domény. Měly by být jednoznačným způsobem mapovány na pojem používaný ve skutečném světě.
Analytický model obsahuje pouze analytické třídy.
Hledáme všechna podstatná jména a spojení podstatných jmen = kandidáti na třídy a atributy. Hledáme slovesa = uchazeči o místa odpovědností nebo operací.
Brainstorming + analýza informací. Každý lísteček je rozdělen na tři oddíly: oddíl třídy (název), odpovědnosti, spolupracovníci.
Vztah je spojení mezi elementy.
Ke spojení dochází, pokud jeden objekt obsahuje odkaz na další objekt. Objekty uskutečňují chvoání systému díky spolupráci.
Ukazují objekty a jejich vzájemná spojení v určitém okamžiku. Jsou to snímky běžícího objektově orientovaného systému. Objekty mohou vůči sobě hrát různé role.
Sémantické vazby mezi třídami. Je-li mezi dvěma objekty spojení, musí rovněž existovat asociace. Spojení jsou instancemi asociací.
Asociace mohou mít názvy, názvy rolí, násobnost, navigovatelnost.
Označuje interval objektů, které lze zahrnout do relace v určitém okamžiku. Znamená, že objekty mohou vznikat a zanikat, ovšem omezující je počet aktuálně existujících objektů v daném okamžiku.
Vyjadřuje, že relaci lze řídit ve směru šipky.
Asociační třída je asociací, která má vlastnost třídy.
Jendá se o redukci asociací typu M:N na asociace typu N:1 tím, že se specifikuje jedinečný objekt cílové sady. Slouží k výběru člena z cílové množiny.
Závislost je ralce mezi dvěma prvky, v níž se změna jednoho prvku (dodavatele) promítá do druhého prvku (klienta). Klient je svým způsobem na dodavateli závislý.
Klient používá dodavatele jako argument, návratovou hodnotu nebo jako prvek vlastní implementace (univerzální použití).
Klientská operace volá dodavatelskou operaci.
Dodavatel je argumentem nebo návratovou hodnotou jedné z klientských metod.
Klient odesílá dodavatele (jenž musí být signálem) k určitému cíli.
Klient je instancí dodavatele.
Abstraction dependencies
Modelují závislost mezi předměty, které jsou na různých stupních abstrakce.
Klient je historickým vývojem dodavatele.
Klient dodavatele může být za běhu programu nahrazen.
Klient je další verzí dodavatele.
Klient může být odvozen od dodavatele.
Závislost mezi balíčky, díky níž může klientský balíček používat veškerý obsah dodavatelského balíčku. Jmenné prostory zůstávají odděleny.
Závislost mezi balíčky, v níž může klientský balíček používat veškerý veřejný obsah dodavatelského balíčku. Jmenné prostory jsou sloučeny.
Řízené narušení zapouzdření, kdy může klient používat soukromé členy dodavatele.
Vztah mezi více a méně specifickým elementem. Konkrétnější předměty jsou důsledně konzistentní s obecnějšími předměty. Obecnější předmět lze nahradit konkrétnějším typem.
Potomci dědí:
Potomek definuje novou operaci se stejnou signaturou, jakou má operace předka.
Abstraktní operace slouží jako držitelé prostoru. Abstraktní operace nemá implementaci. Všichni potomci musí implementovat všechny zděděné abstraktní operace.
Abstraktní třída obsahuje alespoň jednu abstraktní operaci. Abstraktní třídy neumožňují tvorbu vlastních instancí.
Mnohotvárnost. Umožňuje návrh systémů, jež využívají abstraktní třídu, kterou pak za běhu programu nahradí jejími konkrétními potomky.
Polymorfní operace mají více implementací. Různé třídy mohou implementovat stejnou polymorfní operaci jiným způsobem. Polymorfismus umožňuje instancím různých tříd reagovat na stejnou zprávu odlišným způsobem.
Čára života zastupuje účastníka interakce. Má jméno, selektor a typ. Musí být jednoznačně identifikovatelná jménem, typem nebo obojím.
Zastupují určitý druh komunikace mezi dvěma čárami života.
Čas běží shora dolů, čáry života jsou vedeny zleva doprava.
Zdůrazňují strukturální aspekty interakce.
Modelování systémů pracujících v reálném čase.
Kontextový diagram je speciálním případem data flow diagramu obsahující jeden proces, který reprezentuje celý systém. Zdůrazňuje:
Specifikuje tok dat modelovaným systémem. Ukazuje, jaký druh informací bude vstupem a výstupem systému, kudy budou data putovat a kde budou uložena. Nenese informaci o časování procesů nebo zda budou procesy paralelní či sekvenční.
Obsahuje procesy, toky dat, datová úložiště a terminátory. Jedná se o grafickou reprezentaci systému jako sítě procesů, které představují systémové funkce a komunikují skrz data.
Proces – část systému, která převádí vstupy na výstupy. Tok dat – modeluje cestu přesunu dat z jednoho systému do druhého. Datová úložiště – modelují statickou kolekci dat, která je sdílena více procesy probíhajícími v různém čase. Terminátory– představují externí entitu komunikující se systémem.
Definuje statické datové struktury, vztahy a atributy. Vzhledem k DFD je tato metoda více stabilní a nese více vhodných informací.
ERD model – představuje systémové entity (abstaktní i konkrétní).
Entita je cokoliv, co chceme o datech ukládat. Musí být identifikovatelná – odlišná od ostatních, potřebná (needed) – má roli v systému. Jsou popsány atributy. Množina entit je množina obsahující entity stejného typu.
Entity se vyskytují v určitých vztazích. Množina vztahů je množina obsahující vztahy stejného typu.
Atribut je fakt, detail, vlastnost entity. Typ atributu je typ domény atributu.
Relace je v první normální formě, pokud každý její atribut obsahuje jen atomické hodnoty.
Relace se nachází v druhé normální formě, jestliže je v první normální formě a každý neklíčový atribut je plně závislý na primárním klíči, a to na celém klíči a nejen na nějaké jeho podmnožině.
V této formě se nachází tabulka, splňuje-li předchází dvě formy a žádný z jejich atributů není tranzitivně závislý na klíči. Jiné vyjádření téhož říká, že relace je v 3.NF, pokud je ve 2.NF a všechny neklíčové atributy jsou navzájem nezávislé.
Odstraňuje podmíněné funkční závislosti. Tabulka je ve čtvrté normální formě, pokud popisuje pouze příčinnou souvislost (jeden fakt).
Funkční závislosti si lze představit jako tvrzení o reálném světě. Například plat zaměstnance závisí na tom, jakou vykonává funkci, tj. plat závisí na funkci, zapisujeme FUNKCE->PLAT.
Triviální funkční závislost – závislost atributu na vlastní nadmnožině. Plná funkční závislost – atribut je závislý na X a není závislý na žádné podmnožině X.
http://is.muni.cz/el/1433/podzim2012/PB007/um/35424437/35424457/pb007-cvicenie-07.pdf
Modeluje strukturu a chování systému – atributy a operace. Obsahuje více různých typů vztahů – asociace, agregace, kompozice, … Je lépe mapovatelný na reálný svět.
Modeluje pouze strukturální pohled na data a malou množinu vztahů. Lépe mapovatelný na databázové tabulky. Umožňuje modelovat primární a cizí klíče a může být normalizován (zjednodušení manipulace s daty).
Jedna třída může být mapována na více než jednu entitu nebo více tříd může být mapováno na více entit. Ne všechny třídy musí být obsaženy v ERD modelu.
ERD je orientován na data a je persistence-specific. Class diagram je zaměřen i na operace a je persistence independent.
Rozhodování o tom, jak budou systémové fuknce implementovány a jak budou zajištěny nefunkční požadavky.
Design model – obsahuje návrhové podsystémy, návrh realizace případů užití, rozhraní, návrhové třídy a první verzi diagramu nasazení. V OO modelu mají všechny atributy typ, viditelnost a výchozí hodnoty. Operace mají návratový typ a seznam parametrů.
Analysis vs. design model – design model může obsahovat 10 krát až 100 krát více tříd. Oba modely potřebujeme pokud se jedná o velký systém (více než 200 tříd), bude dlouho používán, je to strategický systém. Design model postačuje, pokud se jedná o malý systém, má krátkou životnost, nejedná se o strategický systém.
Používáme návrhové vzory. Jedná se o znovupoužití abstraktních znalostí o problému a jeho řešení.
Vývoj probíhá tak, že se vyhýbáme lidským chybám a systémové chyby jsou minimalizovány. Vývoj je organizován tak, že chyby jsou detekovány a opraveny před dodáním systému zákazníkovi.
Verifikační a validační techniky, které slouží k odhalení a odstranění chyb před nasazením systému.
Taktiky: Ping/echo, heartbeat (komponenta periodicky produkuje hearbeat a jiná komponenta ji poslouchá), exceptions.
Systém je navržen tak, že chyby v SW nepovedou k selhání systému. Systém může pokračovat v operaci i v případě selhání SW.
Přidání nadbytečnosti a rozmanitosti zvyšuje komplexitu a může zvyšuje riziko výskytu chyb. Dependable system architecture jsou založeny na nabytečnosti a rozmanitosti (řízení letového provozu, telekomunikační systémy 24/7).
Taktiky: Voting; Active redundancy (hot restart) – všechny komponenty odpovídají na události paralelně, je použita pouze jedna odpověď; Passive redundancy (warm restart) – jedna komponenta odpovídá na události a informuje ostatní komponenty; Spare – náhradní komponenta může nahradit mnoho jiných chybných komponent; Shadow operation – chybná komponenta běží po krátkou dobu v tzv. shadow mode, dokud není nahrazena; Checkpoint/rollback.
N-version programming pattern – kombinuje různé programovací vzory.
Self-monitoring architectures – multi-channel architecture s rozdílnými SW a HW v každém kanále.
Protection systems – speciální systémy, které jsou spojeny s jinými kontrolními systémy a provádějí pohotovostní akce při chybě systému.
Dependable programming – fault avoidance, fault detection, fault tolerance.
Pokud jsou části distribuovány, je nákladnější je chránit. Pokud jsou části chráněny, použitelnost a výkonnost mohou být kompromitovány.
Platform-level protection, Application-level protection, Record-level protection = layered protection architecture.
Útok nemusí vést ke kompletní ztrátě služeb systému. Každá platforma má odlišný způsob ochrany. Distribution je důležitá, pokud je zde risk DoS útoku.
Schopnost systému dodávat služby i v případě útoku nebo zničení části systému.
Strategie – odolnost (resistance), rozpoznání (recognition), obnova (recovery).
Není možné, aby byl každý systém optimalizován pro všechny tyto atributy. Jeden atribut může negativně ovlivnit jiný.
Design classes jsou třídy, jejichž specifikace je v takovém stavu, že mohou být implementovány. Návrhové třídy lze získat z problémové domény nebo z domény řešení.
Návrhové třídy obsahují kompletní specifikaci:
Dobře utvořené návrhové třídy:
Dědičnost určuje trvalý vztah mezi objekty, není možné změnit třídu objektu za běhu. Dědičnost se používá, pokud se jedná o vztah je speciálním druhem … Agregace se používá pro vztah roli, kterou hraje …
Používá je jen jazyk C++. Umožňují tvorbu parametrizovatelných tříd.
Agregace je relace typu součást/celek. V tomto typu relace používá jeden objekt (celek) služby dalšího objektu (součást). Celek bývá dominantní a řídí chod relace, zatímco součást obvykle pouze poskytuje služby a reaguje na požadavky celku.
Agregace je tranzitivní. Agregace je asymetrická. Objekt nemůže být nikdy částí sama sebe.
Kompozice je silnější formou agregace a má podobnou sémantiku (s většími omezeními). Jedná se o relaci typu součást/celek, která je přechodná a asymetrická.
Klíčovým rozdílem je to, že součásti nemohou existovat mimo celek. V tomto typu relaci navíc patří každá součást jen jedinému celku.
Cílem je převedení návrhového modelu do spustitelného systému. Zahrnuje kód, UML Component diagrams a UML Depolyment diagrams.
Zaměření není na programování (i když je také důležitou součástí), ale na jiné implementační problémy.
Tvorba SW pomocí existujících komponent.
Cena znovu použití – cena adaptování a konfigurace systému reflektuje požadavky vytvářeného systému.
Obecný proces údržby a změny SW.
Spousta SW je vytvářena na jednom počítači, ale je spuštěna na jiných strojích. Mluvíme o vývojové platformě a platformě pro spuštění.
Nástroje – integrovaný compiler, language debugging system, grafické nástroje pro tvorbu UML, testovací nástroje, project suppor tools.
Množina nástrojů, které podporují různé aspekty tvorby SW.
Programová komponenta by měla mít přístup k datům, které potřebuje k implementaci.
Kontrola rozsahu, velikosti (např. délka uživatelského jména), reprezentace (jméno nezahrnuje číslice), přiměřenost.
Vyjímka je programová chyba nebo neočekávaná událost. Umožníme zacházet s vyjímkamy bez další kontroly.
Nepodmíněná tvrzení, čísla s pohyblivou desetinnou čárkou, pointery, dynamická alokace paměti, paralelismus, rekurze, přerušení, dědičnost, aliasing, neohraničená pole, zpracování defaultního vsutpu.
Pokud nastane chyba, uživatel nemusí předělávat vše znovu.
Pokud za určenou dobu nedostane systém odpověď, měl by pak předpokládat, že nastala chyba.
Použití pojmenování spíše než použití jejich numerických hodnot.
Balíček je mechanismus jazyka UML pro seskupování předmětů.
Mohou obsahovat případy užití, analytické třídy, realizace případů užití nebo analytické balíčky.
Diagram komponent zobrazuje způsob (hierarchického) rozdělení systému na samostatné části a komunikační vztahy mezi nimi, čímž definuje architekturu systému.
Je tvořen:
Rozhraní umožňují návrh zaměřený na dohodu, nikoliv na specifickou implementaci. Rozhraní odděluje specifikaci od implementace. Realizující klasifikátor má za všechny funkce následující odpovědnosti:
Umožňují modelovat distribuci softwarového systému na fyzickém hardwaru.
Vyjadřuje typ výpočetního prostředku.
Instance uzlu vyjadřuje konkrétní výpočetní prostředek.
Artefakt je specifikací něčeho skutečného, například spustitelného souboru.
Patří sem zdrojové soubory, spustitelné soubory, skripty, databázové tabulky, dokumenty, výstupy vývojového procesu.
HCI je obor, který zkoumá, jak uživatelé interagují s počítačovými systémy. Zahrnuje jak umění, tak vědu. User interface design je zaměřen na design systému s ohledem na uživatelské zkušenosti a interakci.
Hlavní principy:
Aktivity:
Vývojáři by neměli navrhovat rozhraní, protože jsou více zaměřeni na kvalitu než na použitelnost.
Krátkodobá paměť – pravidlo 7+2.
Crap (constrast, repetition, alignment, proximity = sdružování).
Wireframes – první náčrtky. Mockups – modely pro demonstraci a vyhodnocení. Prototypes – částečně fungující příklady softwaru.
Techniky – interview, testování použitelnosti (kvantitativní, kvalitativní), oborová studie.
Přímé pozorování uživatele – kombinace s kvalitativním a kvantitativním měřením.
Eye Tracker – používané v marketingu.
Stavové automaty modelují dynamické chování reaktivního automatu. Diagramy stavových automatů obsahují jeden stavový automat pro každý reaktivní objekt. Reaktivními objekty jsou třídy (nejčastěji), případy užití, podsystémy, celé systémy. Reaktivní objekt poskytuje kontext stavového diagramu.
Reaktivní objekty reagují na externí události; mohou generovat vnitřní události; mají určitý životní cyklus, který lze modelovat jako posloupnost stavů, přechodů a událostí; mají aktuální chování, které vyplývá z předchozího chování.
Existují dva typy stavových automatů:
Stav je podmínka nebo situace, ve které se nachází objekt a splňuje nějakou podmínky, vykonává aktivitu nebo čeká na událost. Je to sémanticky významná podmínka objektu.
Stav je určen:
Událost vstup (entry) proběhne rychle a automaticky při vstupu do stavu – je to první věc, ke které při vstupu do určitého stavu dojde. Zmíněná událost vždy spustí přidruženou akci.
Událost výstup (exit) je úplně poslední událostí, která proběhne rychle a automaticky při odchodu z určitého stavu a která vždy spustí přidruženou výstupní akci.
Interní přechod umožňuje zachytit skutečnost, že dochází k něčemu, co stojí za to modelovat, zároveň ale i skutečnost, že to něco nezpůsobuje přechod do nového stavu.
Interní aktivita je proces, který trvá určitou dobu a lze jej přerušit.
Přechod je posunem z jednoho stavu do dalšího.
Událost je externí nebo interní výskyt, který zahájí přechod. Podmínka (guard) je booleovský výraz, jehož splnění podmiňuje přechod. Akce je část díla přidruženého k přechodu, k níž dochází při zahájení přechodu. Přechodový pseudostav spojuje nebo větví přechody. Pseudostav volby směřuje tok skrze stavový automat podle aktuálních podmínek.
Událost je specifikací něčeho významného, co se stane v reaktivním objektu. Typy událostí:
Dvě klíčová slova: after (after (3 months)), when (when (date = 20/3/2000)).
Složené stavy mohou obsahovat jeden nebo více vnořených stavových automatů – dílčí podstavy dědí od svých předků všechny přechody. Všechny podautomaty existují ve vlastních regionech. Poslední pseudostav platí pouze pro dotyčný region. K ukončení všech regionů se používá ukončovací pseudostav.
Jednoduchý složený stav obsahuje pouze jeden region (jeden vnořený stavový automat).
Obsahují dva nebo více souběžně běžících podautomatů. Vstoupí-li se do složeného stavu, okamžitě se spustí všechny jeho automaty.
Opuštění superstavu, když dojde k ukončení obou regionů.
K ukončení dojde, pokud dojde k ukončení jednoho z regionů.
Testování prokazuje, zda program dělá to, co má dělat a odhaluje chyby před uvedením do provozu. Při testování spouštíme program s použitím “umělých” dat. Kontrolujeme výsledky testů – chyby, anomálie nebo informace o nefunkčních atributech programu. Můžeme tak odhalit přítomnost chyby, ne jejich absenci. Testování je součást obecných validačních a verifikačních procesů a zahrnuje také validační techniky.
Cíl testování:
Ukázka, že SW splňuje požadavky. Úspěšný test ukazuje, že systém funguje tak, jak byl zamýšlen (k čemu byl určen).
Objevení chyb v SW, chybného chování nebo neshod ve specifikaci. Úspěšný test ukazuje nekorektní chování.
Verifikace – produkt byl vytvořen správně – splňuje specifikaci.
Validace – byl vytvořen správný produkt – systém dělá to, co uživatel chce.
SW inspections – Concerned with analysis of the static system representation to discover problems (static verification). These involve people examining the source representation with the aim of discovering anomalies and defects.
Inspekce nevyžaduje spuštění systému, může být využita před implementací. Může být použita na jakoukoliv reprezentaci systému (požadavky, design, ...)
Během testování mohou být skryty jiné chyby. Protože je inspekce statický proces, nezabýváme se interakcí mezi chybami.
SW testing – Concerned with exercising and observing product behaviour (dynamic verification).
Statická analýza je technika verifikace, která nezahrnuje spuštění programu. Inspekce a reviews jsou formou statické analýzy, která zahrnuje i formal verification, model checking, automated program analysis.
Jsou použity, pokud je vytvořena matematická specifikace.
Produkování matematické specifikace vyžaduje detailní analýzu požadavků, což může odhalit chyby. Souběžné systémy mohou být analyzovány a mohou být objeveny běhové podmínky, které vedou k selhání. Je možné objevit chyby před testováním.
Vyžadují speciální notaci (může být složitá). Je velmi nákladné vytvořit specifikaci. Důkazy mohou obsahovat chyby. Je možné dosáhnout stejné míry důvěry i použitím jiných technik.
Zahrnuje vytvoření rozšířeného stavového modelu systému, použití speciálního systému a kontrolu chyb modelu. Model checker prochází všechny možné cesty a kontroluje, zda je požadovaná vlastnost korektní. Metoda je vhodná pro souběžné systémy. Je ale výpočetně velmi nákladná.
Statické analyzátory jsou SW nástroje pro zpracování zdrojového textu. Snaží se projít text a objevit chybné podmínky. Jsou efektivní jako pomocné nástroje, nejsou náhradou inspekcí.
Je vhodná, pokud používáme jazyk, kde compiler neodhalí mnoho chyb. Je vhodná pro kontrolu bezpečnosti – odhalení přetečení bufferu nebo neočekávaného vstupu.
Stages:
Zahrnuje aktivity, které jsou provedeny vývojovým teamem.
Přístup k vývoji software, který je založen na malých, stále se opakujících krocích, vedoucích ke zefektivnění celého vývoje. Prvním krokem je definice funkcionality a následné napsání testu, který tuto funkcionalitu ověřuje. Poté přichází na řadu psaní kódu a nakonec úprava tohoto kódu.
Pozitiva: Tím, že systém dělá právě a jen to, co testuje, dá se považovat na konci programování za otestovaný. Využití automatických testů. Vytváření kódu na základě testů vede k větší modularitě a čistotě kódu.
Negativa: Vyžaduje velmi zkušené/nadané vývojáře. Kromě uživatelských scénářů bez dokumentace. Náročné při velkých projektech. Náročné pro systémy s převažující uživatelskou interakcí. Náročná údržba testovacích scénářů při změnách v původních požadavcích.
Kontrola, že provedená změna nezpůsobí selhání dříve napsaného kódu.
Proces testování konkrétní verze. Jedná se o formu systémového testování.
Testování každého požadavku.
Testování, kde sám uživatel zkouší pracovat se systémem.
U agilních metod je uživatel součástí týmu a je odpovědný za některá rozhodnutí. Tento uživatel nemusí být typickým uživatelem a nemusí mít stejné nároky jako pozdější uživatelé systému.
Performance testing tests system performance properties.
Reliability testing relies on testing the system with a data set that reflects the operational profile of the software.
Security validation may be carried out using experience-based analysis, tool-based analysis or ‘tiger teams’ that simulate attacks on a system.
Změna SW je nevyhnutelná – nové požadavky, změna obchodního prostředí, oprava chyb, nové vybavení, zlepšení výkonu a spolehlivosti.
Evolution – stav, kdy je systém v provozu a jsou navrženy nové požadavky.
Servicing – není přidána nová funkcionalita, ale jsou například opraveny chyby.
Phase-out – SW může být používán, ale nejsou prováděny další změny.
Evoluce závisí na typu udržovaného SW, vývojových procesech, zkušenostech a schopnostech uživatelů.
Agilní metody jsou založeny na inkrementálním vývoji.
Nastávají, pokud týmy používají agilní přístup, ale týmy zajišťující evoluci nejsou seznámeni s agilními metodami a preferují plan-based přístup nebo pokud je použit plan-based přístup a týmy zajišťující evoluci preferují agilní metody.
Zkoumání změn systému. Vytvořeno několik zákonů, ale existuje i několik vhodných pozorování.
Jedná se o změnu SW po uvedení do provozu. Normálně nezahrnuje velké změny systémové architektury. Změny jsou provedeny na existujících komponentách, jež jsou pak přidány do systému.
Cena je vyšší než při vývoji. Roste s údržbou SW. Cenu ovlivňuje:
Předpovědi jsou založeny na posouzení částí systému, jež by mohly způsobovat problémy.
Restrukturalizace nebo přepsání částí nebo celého systému bez změn funkcionalit. Důraz kladen na zjednodušení systému. Systém by měl být restrukturalizován a znovu zdokumentován.
Source code translation – převedení kódu do nového jazyka, reverse engineering – analýza a porozumění programu, program structure improvement – restrukturalizace pro lepší pochopení, program modularization – reorganizace struktury, data reengineering – úklid a restrukturalizace dat.
Cena závisí na kvalitě SW, dostupných nástrojích, rozsah převáděných dat, dostupnost vyškoleného personálu.
Re-engineering – nastává, pokud byl systém již nějakou dobu udržován a zvyšuje se cena údržby.
Refactoring – jedná se o nepřetržitý proces vylepšování při návrhu a evoluci. Snaží se vyhnout degradaci struktury a kódu, což by zvyšovalo náklady na údržbu systému.
A legacy system is an old method, technology, computer system, or application program. The legacy system may or may not remain in use.
Modely jsou často propojovány.
Pozitiva: Vytvořením zevrubné dokumentace se usnadňuje zapojení nových členů do týmu a snižuje závislost na jednotlivých řešitelích. Jednoduše manažersky uchopitelný.
Negativa: Vytváření podrobné dokumentace zabere kapacity, které by byly jinak využitelné. Odhalení chyby či změna v požadavcích v pozdní fázi je velmi nákladné a vyžaduje revizi všech ostatních kroků. Některé technologické limitace, požadavky či rizika nemusí být možné odhalit včas.
Prototyp je iniciální verze systému, pomocí které lze demonstrovat koncept a zkoušet různá nastavení. Může být použit při definici požadavků, návrhu i testování.
Zlepšuje použitelnost, je blíž k potřebám uživatele, zlepšuje kvalitu návrhu, zlepšuje údržbu, zmenšuje úsilí při vývoji.
Pozitiva: Předvedením prototypu zákazníkovi – uživateli je možné získat cennou, zpětnou vazbu a na jejím základě vytvořit finální produkt. Po vytvoření jednorázového prototypu lze snáze sledovat časové odhady. Snížení celkového času vývoje. Rychle postupující vývoj.
Negativa: Zaměření na co nejrychlejší vytvoření prototypu může vést k zanedbání analytické části a výsledkem tak nemusí být nejlepší možné řešení. Zákazníci – uživatelé mohou požadovat od finální verze vše, co je v prototypu, přestože mohou být důvody k provedení změn ve finální verzi. Předvedení prototypu zákazníkovi – uživateli může vytvářet mylný dojem o úrovni dokončení vyvíjeného produktu („vždyť už to je skoro hotové“). Vývojový přístup může vést k ponechání nevhodných částí ve finálním produktu - zanesení „smetí“.
Rozdělění systému na jednotlivé inkrementy. Požadavky uživatelů mají určitou prioritu, nejvyšší priorita je doručena jako první.
Výhody – dřívější doručení některých komponent, prvotní komponenty lze využít jako prototypy, snížení rizika nedokončení projektu, komponenty s větší prioritou jsou více testovány.
Problémy – většina systému vyžaduje více základních komponent, které jsou používány různými částmi systému, podstata iterativních procesů spočívá v tom, že specifikace je vyvíjena v souladu se SW.
Proces je reprezentován jako spirála. Každá smyčka představuje fázi procesu. Neexistují žádné fixní fáze (specifikace, design) – smyčky jsou vybírány podle potřeby.
Použití – pomoc při uvažování nad iteracemi, v praxi používán zřídka.
Pozitiva: Výsledný produkt dle specifikací zákazníka. Analýza rizik může zachytit problémy projektu dříve, než se stanou kritickými.
Negativa: Zdlouhavý vývoj -při špatných odhadech zdrojů se může ukázat jako neúnosný. Systém není prototypován jako celek ale po částech – zákazník nemá celkový pohled na systém až do okamžiku dodání.
Moderní proces odvozen z UML. Většinou je popsán ze tří perspektiv – dynamická (a dynamic perspective) – ukazuje vývojové fáze během určité doby, statická (a static perspective) – ukazuje aktivity, a practive perspective – suggest good practice.
Pozitiva: Výsledná dokumentace usnadňuje orientaci v oblasti při tvorbě rozšíření. Výsledný produkt je založený na interakci se zákazníkem. Metodika je komplexní a škálovatelná.
Negativa: Velká režie při tvorbě dokumentace. Nevhodné na malé projekty. Složitá plánovatelnost.
Agilní metodika softwaru je zastřešující pojem pro iterativní a inkrementální metodiky vývoje, stavějícím důraz na úzké osobní spolupráci mezi týmy, složenými z pracovníků různých zaměření a komunikaci se zákazníkem. Zatímco tradiční metodiky staví funkcionalitu jako fixní veličinu, přičemž čas a zdroje jako veličiny proměnné, agilní přístup považuje za fixní čas a zdroje a jako proměnnou ponechává funkcionalitu.
Jedna z nejznámějších a nejvíce rozšířených agilních metod. Nové verze jsou sestavovány až několikrát denně. Inkrementy jsou doručovány zákazníkům každé dva týdny. Každá verze je testována a přijata, pokud všechny testy projdou úspěšně.
Pozitiva: Krátké iterace usnadňují zákaznickou zpětnou vazbu. Rychle viditelné výsledky.
Negativa: Dokumentace není samostatně prováděnou činností. Sebelépe vytvořený kód není čitelný pro každého, pro údržbu je tento postup problematický. Velmi velká závislost na kvalitním a stálém řešitelském týmu. Ztráta klíčového pracovníka může být kritická. Důraz na osobní komunikaci při může vést k nejasnostem.
Zabývá se aktivitami, které zajišťují, že je SW dodán včas, podle plánu a splňuje požadavky.
Úpěch – doručení SW ve stanovenou dobu, cena odpovídá rozpočtu, SW splňuje očekávání.
Aktivity:
Rozdělění práce na části a přiřazení těchto částí členům týmu. Projektový plán je vytvořen na začátku projektu a popisuje jak bude práce vykonána.
Fáze:
Jak bude práce rozdělena.
Problémy – přesný odhad je složitý, produktivita nezávisí na počtu lidí, přiřazení zaměstnance k rozdělané práci zpomalí projekt (komunikace), neočekávané události.
Funkcionality nejsou plánované, ale jsou přidávány v průběhu vývoje.
Faktory ovlivňující cenu:
Založené na:
The COCOMO 2 model – empirický model založený na zkušenostech.
Efektivitu týmu ovlivňují samotní lidé, orgranizace a komunikace.
Slajdy z přednášek (http://is.muni.cz/el/1433/podzim2012/PB007/um/35424436/).
Slajdy ze cvičení (http://is.muni.cz/el/1433/podzim2012/PB007/um/35424437/35424457/).
UML 2 a unifikovaný proces vývoje aplikací; Jim Arlow, Ila Neustadt; ISBN 978-80-251-1503-9.
Aplikovaná metodika vývoje softwaru v malých a středních (SME) firmách (http://is.muni.cz/th/98664/fi_m/Plny_text_prace.pdf)