Softwarové inženýrství (IUS)

Na této stránce je můj elektronický sešit do předmětu IUS. Při jeho vytváření jsem čerpal informace z přednášek a ze studijní opory k předmětu IUS od Ing. Bohuslava Křenu, Ph.D. a Ing. Radka Kočího, Ph.D.

Tématické okruhy

Vznik softwarového inženýrství, softwarová krize.
Vlastnosti softwaru, problémy při jeho vývoji.
Životní cyklus softwaru, charakteristika jeho etap.
Modely životního cyklu softwaru.
Analýza a specifikace požadavků, diagram případů užití.
Objektová orientace, diagram tříd.
Strukturovaná analýza a návrh, ER diagram.
Jazyk UML, statické a dynamické diagramy.
Implementace a testování softwaru.
Agilní metodologie tvorby softwaru.
Řízení softwarových projektů.
Kvalita a měření v softwarovém inženýrství.
Ochrana intelektuálního vlastnictví.

2. Softwarové inženýrství

Softwarové inženýrství: Systematický přístup k vývoji, nasazení a údržbě softwaru

Softwarová krize: Pojem zaveden spolu s pojmem SW inženýrství v 60. letech, když se začaly objevovat problémy s vývojem rozsáhlejším programů.

Historie

60. léta: Softwarová krize se projevovala (a stále projevuje) neúnosným prodlužováním a prodražováním projektů, nízkou kvalitou výsledných produktů, problematickou údržbou a nízkou produktivitou práce programátorů. Hledání jednoduchého a účinného řešení na existující problémy vedlo k zavedení strukturovaného programování.

70. léta: Dochází k dalšímu rozvoji metodologií.; Je kladen větší důraz na úvodní etapy životního cyklu SW.; Abstraktní datový typ

80. léta: Vývoj nových programovacích jazyků a paradigmat.; První CASE (Computer Aided Software Engineering) nástroje; Větší podpora nasazení a údržby - správa verzí

90. léta: Snaha zvýšit efektivitu vývoje - znovupoužitelnost (reusability); Sledování kvality SW s použitím metrik; Návrhové vzory; Umělá inteligence; Java

Současnost

UML = Unified Modelling Language

Outsourcing: Zajišťování neklíčových operací externími pracovníky

Odlehčené metodologie (light-weight metodologies): Klasické metodologie neúnosně prodražují vývoj menších projektů.

Formální verifikace, simulace a analýza: Cílem je zvýšit bezpečnost SW nasazeného v kritických oblastech.

Softwarový produkt

Softwarový produkt: Pokud členové jedné komunity vytvářejí SW (ve smyslu výrobku) pro členy jiné komunity (pro uživatele), nazveme takový SW softwarovým produktem. Softwarový produkt však nejsou jenom počítačové programy, nýbrž softwarový produkt zahrnuje i požadavky, specifikace, popisy návrhu, zdrojové texty programů, testovací data, příručky, manuály, ...

Kvalita: Kvalita je souhrn vlastností a charakteristik výrobku, procesu nebo služby, které ukazují jeho schopnost splnit určené nebo odvozené potřeby.; Kvalita však není definována jako absolutní míra, nýbrž jako stupeň splnění požadavků či potřeb.

Krabicový software (generický): SW je vyroben a potom prodáván libovolnému zájemci.; Musí být velmi dobře otestován před vypuštěním do prodeje.; Dodatečné opravy jsou velmi drahé.

Zákaznický software: Šitý na míru pro konkretního zákazníka.; Cena zákaznického SW je vyšší - mohou si dovolit větší firmy.; Typicky systémy pro řízení výroby, leteckého provozu, ...

Vlastnosti SW z hlediska použití

Správnost: Míra, do jaké software vyhovuje specifikaci.

Spolehlivost

Efektivnost

Použitelnost

Bezpečnost

Vlastnosti SW z hlediska přenosu

Přenositelnost: jak velké úsilí je nutné pro přenos SW na jinou platformu

Znovupoužitelnost: do jaké míry je možné znovu použít jednotlivé části SW

Interoperabilita: Zohledňuje úsilí potřebné k zajištění spolupráce systému s jinými systémy.

Vlastnosti SW z hlediska změn

Udržovatelnost: schopnost reagovat na měnící se potřeby zákazníka nebo např. změny legislativy

Modifikovatelnost

Dokumentovanost

Problémy při vývoji softwaru

Složitost: Není možné pochopit všechny stavy systému, důsledky jeho úprav. Problém komunikace v týmech.

Syndrom 90% hotovo: Při posuzování hotové části se vychází z odpracovaného (podle plánu), nikoliv ze skutečně hotového.

Specifikace požadavků

Náchylnost softwaru k chybám: Hodně chyb se projeví až při provozu SW systému, ne při vývoji.

Práce v týmu: komunikační problémy při vývoji velkých projektů

Tvorba dokumentace: Velké projekty vyžadují mnohem více dokumentace. Těžko se pak udržuje její aktuálnost.

Stárnutí softwaru: Postupné přidávání nových funkcí a časté opravy chyb vedou k degradaci struktury a ke snižování spolehlivosti SW.

Syndrom druhého systému: Autor povzbuzen úspěchem prvního systému chce nový systém udělat dokonalý. Nový systém je pak příliš složitý, nepřehledný a neefektivní.; Systém není dokonalý, když k němu nelze nic přidat, ale tehdy, když z něho nelze nic odstranit.

3. Modely životního cyklu softwaru

Proces vývoje softwaru

Softwarový proces definuje, kdo kdy co má dělat, aby bylo dosaženo požadovaného cíle.

Dekompozice (Divide and conquer): Dekompozice přináší lépe zvládnutelné podsystémy, které jsou vyvíjeny nezávisle na sobě. Na druhou stranu však vyžaduje zavedení vhodného rozhraní mezi podsystémy. Po integraci všech podsystémů je nutné otestovat systém jako celek.

Životní cyklus softwaru

Model životního cyklu softwaru definuje etapy vývoje softwaru a pro každou etapu dále definuje nutné činnosti a její vstupy a výstupy.

Analýza a specifikace požadavků	8%
Architektonický a podrobný návrh	7%
Implementace	12%
Integrace a testování	6%
Provoz a údržba	67%

Etapy životního cyklu softwaru

Analýza a specifikace požadavků: Přání zákazníka je potřeba analyzovat a zapsat je v jasné a strukturované podobě. Pozornost je věnována pouze požadavkům samotným, nikoliv jejich realizaci.; Součástí této etapy by měla být studie proveditelnosti a analýza rizik.

Architektonický návrh: Architektonický návrh slouží k ujasnění koncepce systému a k jeho dekompozici. Plánuje se akceptační testování a nasazení do provozu (včetně zaškolování uživatelů).

Podrobný návrh: Podrobný návrh se soustřeďuje na podrobnou specifikaci softwarových součástí, na výběr algoritmů, na stanovení struktury dat a ošetřování chybových a neočekávaných stavů.; Dále se specifikují požadavky na lidské zdroje, odhaduje se doba trvání a náklady na projekt. Výsledkem by měl být také návrh testů součástí včetně testovacích dat.

Implementace a testování součástí: Programová realizace softwarových součástí, vypracování dokumentace k součástem a otestování implementovaných součástí.

Integrace a testování systému: Spojení součástí do jediného celku, otestování celého systému a oprava chyb v součástech, které se projevily až při integraci.

Akceptační testování a instalace: Otestování systému uživatelem/zákazníkem. Po akceptaci systému zákazníkem následuje instalace systému a školení uživatelů.

Provoz a údržba: Průběžné řešení problémů souvisejících s používáním softwaru.

Modely životního cyklu softwaru

Vodopádový model: Základní model životního cyklu softwaru - jednotlivé etapy jsou řazeny za sebou. Problém tohoto modelu představuje uživatel, který není schopný na začátku přesně specifikovat požadavky. Tento model neodpovídá vývoji reálných projektů.

Iterativní model: Proces vývoje softwaru je rozdělen do iterací. Jednotlivé iterace lze chápat jako instance vodopádového modelu. Po každé iteraci má uživatel k dispozici spustitelnou verzi SW s neúplnou funkcionalitou.

Inkrementální model: Na základě specifikace systému jsou stanoveny ucelené části systému, které se uživateli odevzdávají postupně.

Spirálový model

Spirálový model do procesu vývoje SW zavádí prototypování a klade značný důraz na analýzu rizik. Jednotlivé etapy se opakují, vždy na vyšším stupni zvládnuté problematiky. Na rozdíl od iterativního modelu dostává uživatel vždy pouze prototyp.

Prototyp: Prototyp se od verze s omezenou funkcionalitou liší tím, že se po použití vždy zahodí.

RUP = Rational Unified Process: RUP je na rozdíl od předchozích modelů použitelný pro řízení reálných softwarových projektů. RUP je výsledkem výzkumu řady velkým firem koordinovaným firmou Rational.; RUP klade důraz na vizualizace softwarového systému pomocí jazyka UML(Unified Modelling Language).

Agilní metodologie: Klasické metodologie neúnosně komplikují vývoj malých projektů. Agilní metodologie kladou hlavní důraz na člověka jako na určující faktor pro kvalitu výsledného produktu.; viz. Kapitola 10 - Agilní metodologie

4. Objektová orientace

Výhodou objektově orientovaných přístupů k návrhu je především stabilita navrhovaných prvků (z pohledu neustále se měnících požadavků) a jednoduchost jejich změn.

S cílem zjednodušení komunikace mezi vývojáři byl v roce 1995 definován jazyk UML(Unified Modelling Language). Tento jazyk neposkytuje sám o sobě žádnou metodologii, nabízí pouze prostředky pro unifikovanou tvorbu modelů různých aspektů navrhovaného systému. UML je však součástí různých metodologií návrhu, např. RUP.

Jazyk UML

Pohled (view)

Pohled je projekce systému na jeden z jeho aspektů, ostatní aspekty jsou pohledem ignorovány. Nad jedním systémem je vhodné vytvářet celou řadu pohledů:

Strukturální pohled (structural view): Strukturální pohled popisuje vrstvu mezi objekty a třídami a jejich vztahy.

Pohled chování (behavioral view): Pohled chování popisuje, jak objekty interagují a charakterizuje reakce na vnější podněty.

Datový pohled (data view): Datový pohled popisuje stavy objektů a jejich vazby.

Pohled rozhraní (interface view): Pohled rozhraní popisuje zapouzdření komponent systému a jejich potenciální použití okolím systému.

Objektová orientace

Objekt vytvořený v OO programovacím prostředí je abstrakcí reálného objektu. Modelování nějaké části reálného světa je vytváření abstrakcí nad objekty dané části reality.

Objektově orientované přístupy nejsou cílem našeho snažení, ale prostředkem k dosahování cílů.

Objekt: Objekt spojuje data a funkcionalitu do uzavřené jednotky. Na objekt můžeme pohlížet jako na černou skříňku (black box), jejíž vnitřní realizace je nám skryta. Objekt má stav, chování a identitu.

Atribut: Atribut reprezentuje vlastnost objektu a je definován množinou hodnot, kterých může nabývat. Atribut může být složený z více proměnných objektu nebo může být vypočítaný.

Stav objektu: Stav objektu je reprezentován množinou hodnot jeho atributů.

Rozhraní objektu: Rozhraní objektu je definováno množinou operací, které objekt nabízí.

Komunikace objektů (message passing): Objekty mezi sebou komunikují zasíláním zpráv. Zpráva obsahuje identifikátor příjemce, název metody a argumenty.

Identita objektu: Díky identitě objektu je každý objekt jedinečný, bez ohledu na jeho stav. Na základě toho rozlišujeme mezi testem shodnosti a testem identity objektu.

Objektově orientované techniky

Abstrakce: Smyslem abstrakce je zjednodušit pohled na celý systém bez ztráty jeho významu. Každému objektu pak odpovídá určitá zodpovědnost za řešení identifikované části problému - objekt je abstrakcí části řešeného problému.

Zapouzdření: Pomocí zapouzdření jsou skrývány implementační detaily objektu.

Dědičnost: Dědičnost umožňuje vytvářet nové objekty na základě již existujících objektů. Vyjadřuje hierarchický vztah mezi objekty.

Polymorfismus: Stejné zprávy mohou být zpracovány různým způsobem v závislosti na typu objektu.; Rozlišujeme statický/dynamický polymorfismus a na základě toho říkáme že vzniká časná/pozdní vazba. Při časné vazbě je metoda vybrána v čase kompilace. Při pozdní vazbě je metoda vybrána za běhu programu.

Třídně založené jazyky

Třída: Třída je generická definice pro množinu objektů, které mají stejné chování a stejnou množinu atributů. Jde tedy o abstrakci nad objekty. Každý objekt je potom instancí své třídy.

Dědičnost: Dědičnost je relace uspořádání na množině tříd. Jednoduchá / vícenásobná dědičnost, víme...

Identita objektu: Identita objektu nesouvisí s třídou. Dva objekty téže třídy mohou být shodné, ne však identické.

Prototypově založené jazyky

Prototypově založené jazyky pracují pouze s objekty. Typickými představiteli jsou jazyky Self a Javascript.

Existuje vždy minimálně jeden počáteční objekt. Nové objekty se vytváření klonováním již existujících. Dědičnost objektů je vyjádřena prostřednictvím delegování zpráv na nadřazené objekty.

Typování

Staticky typované jazyky: Typová kontrola probíhá v době kompilace.

Dynamicky typované jazyky: Typová kontrola probíhá za běhu programu.

Asociace

Asociace je základní typ vztahu mezi třídami. Asociace má svůj název, v názvu upřednostňujeme podstatné jméno. Dále je možné definovat roli objektů ve vztahu a násobnost vztahu.

Mohutnost vztahu: Mohutnost vztahu udává, kolik instancí jedné třídy může být svázáno s instancí třídy druhé.

Stupeň asociace: Stupeň asociace vyjadřuje, kolik tříd se podílí na jedné asociaci. Nejčastěji se používají vztahy binární. Vyšší stupně asociace se během návrhu transformují na vztahy binární.

Povýšení asociace na třídu: Používá se v případech, kdy je potřeba přiřadit atributy samotnému vztahu, nebo při eliminaci asociací vyššího stupně.

Kompozice a agregace

Kompozice a agregace sou speciální typy asociace, které říkají, že jeden objekt je složen z jiných objektů. Rozdíl mezi kompozicí a agregací spočívá v síle vztahu.

Agregace (seskupení)

Agregace vyjadřuje slabší vztah mezi objektem a jeho částmi. Objektu reprezentujícímu celek se říká agregační (seskupený) objekt, jeho částem pak konstituční objekty (konstituenty). Vlastnosti agregace jsou:

Seskupený objekt může existovat bez svých konstitučních objektů.
Konstituent může být součástí více seskupení.
Implicitní násobnost vazby se nedá předpokládat.

Kompozice (složení)

Kompozice vyjadřuje silnější vztah mezi objektem a jeho částmi. Objektu reprezentujícímu celek se říká kompozitní (složený) objekt, jeho částem pak komponentní (složkové) objekty. Vlastnosti kompozice jsou:

Složený objekt nemůže existovat bez svých komponent.
Komponentní objekt může být součástí pouze jedné kompozice.
Implicitní násobnost každé složky je 1.

Závislost

Závislost vyjadřuje jiné různé vztahy mezi objekty či třídami. Typ závislosti se v diagramech označuje pomocí stereotypů. Pokud není stereotyp uveden, implicitně se předpokládá <<use>>. Další možné stereotypy jsou:

`<<instantiate>>`	používá se pro znázornění vztahu mezi třídou a objekty
`<<trace>>`	obecná vazba mezi objekty na různé úrovni abstrakce (např. analytická vs. návrhová třída)
`<<friend>>`	řízené narušení zapouzdření (viz. klíčové slovo `friend` v C++).

Realizace

Realizace je vztah mezi třídou a rozhraním, který říká, že třída implementuje všechny operace z daného rozhraní.

Rozhraní: Rozhraní je speciální typ třídy, která specifikuje pouze množinu operací, ne však jejich implementaci. Na místě rozhraní lze pak použít kteroukoliv třídu, která rozhraní implementuje. Rozhraní se označují pomocí <<interface>>.; Pomocí rozhraní lze omezit počet vazeb mezi třídami.

5. Analýza a specifikace požadavků

Cíle etapy specifikace požadavků

Získání požadavků od uživatele: Zjistit, o jaký produkt má zákazník zájem, vymezit jeho funkcionalitu, ... Důraz je kladen na požadavky uživatele, nikoliv na způsob jejich realizace.

Transformace požadavků uživatele do strukturované podoby: Požadavky od uživatele je potřeba převést do částečně formálního, strukturovaného popisu. Cílem je jednoznačné zadání odsouhlasené zákazníkem, které slouží jako výchozí bod. Změny požadavků se od této chvíle musí dokumentovat.

Studie vhodnosti, analýza rizik: Na základě dostupných informací je třeba odhadnout, zda jsme schopni požadovaný produkt vytvořit za předpokládanou cenu v předpokládané době.

Plánování akceptačního testování: Plán akceptačního testování by měl být součástí smlouvy se zákazníkem. Tento plán říká, jak se bude SW produkt testovat při přebírání zákazníkem, jaké výsledky testů budou považovaný za úspěšné, atd.

Typy požadavků

Funkcionální požadavky: Funkcionální požadavky určují, co má systém dělat.

Požadavky na provoz systému: Požadavky na provoz systému definují podmínky, za jakých má SW pracovat.

Požadavky na výsledný systém: počítačové vybavení, OS, programovací jazyk, spolehlivost, přenositelnost, bezpečnost, ...

Požadavky na vývojový proces: požadavky zákazníka na dodržování norem během vývoje a předávání systému

Požadavky na rozhraní: rozhraní systému se svým okolím (včetně GUI)

Externí požadavky: etické požadavky, ochrana osobních údajů, ...

Specifikace požadavků

Metody získávání informací

interview, dotazník
pozorování prací u zákazníka
analýza existujícího SW

Problémy při specifikaci požadavků

Vyřazení: V době specifikace je nějaká entita implicitní, avšak s odstupem času se může tato implicitní informace vytratit.

Deformace (zkreslení): Získaná informace může vyvolávat zavádějící výklad.

Zobecnění: Věta je příliš obecná a v důsledku toho nepravdivá.

Slovníček pojmů: Slovníček pojmů je jeden z prostředků, který napomáhá předcházet nedorozuměním.

RUP - Specifikace požadavků

diagram případů užití
detaily případů užití
specifikace (strukturovaný text)
slovníky pojmů

Případ užití (use case): Případ užití je chápán jako funkce, kterou systém vykonává jménem jednotlivých účastníků nebo v jejich prospěch. Zvláštním případem účastníka může být také čas (např. periodické výpisy z banky).

Detail případu užití: Samotné diagramy případů užití ukazují pouze, které operace je možné v systému vykonávat. Detail případu užití poskytuje konkrétní informace ke každé takové operaci - zejména vstupní a výstupní podmínky a tok událostí.; Alternativní tok je aktivován kdykoliv během hlavního toku, pokud jsou splněny jeho počáteční podmínky.

Zobecnění účastníka: Zobecnění účastníka znázorňuje vztah generalizace/specializace mezi účastníky. Cílem je zpřehlednění diagramu.

Zobecnění případu užití: Zobecnění účastníka znázorňuje vztah generalizace/specializace mezi případy užití. Cílem je zpřehlednění diagramu.

Relace <<include>>: Relace <<include>> vyjadřuje situaci, kdy jeden případ užití v sobě zahrnuje jeden či více jiných případů užití.

Relace <<extend>>: Relace <<extend>> vyjadřuje situaci, kdy jeden případ užití může rozšiřovat funkcionalitu jiných případů užití. Na rozdíl od relace <<include>> je však případ v relaci <<extend>>nepovinný.

RUP - Analýza

Analytické třídy: Analytická třída (na rozdíl od návrhové) slouží pouze pro identifikaci entit v řešené problematice a ujasnění vztahů mezi nimi. Jedna analytická třída se může během návrhu transformovat na několik tříd návrhových.

Objektové diagramy: Objektové diagramy jsou dynamické diagramy, které zachycují konkrétní instance tříd a jejich vazby v určitém čase. V objektovém diagramu nalézají využití stereotypy <<instantiate>>.

Analytické balíčky: Analytické balíčky umožňují souběžnou práci vývojářů na různých částech systému v době návrhu (dekompozice). Jednotlivé balíčky oddělují prostory jmen a definují viditelnost zapouzdřených elementů (public, private, protected).

Diagram interakce: Diagramy interakce se rozlišují na statické/dynamické podle toho, jestli znázorňují vztahy tříd nebo jejich instancí. Nejčastějším typem tohoto diagramu je diagram spolupráce(collaboration diagram).

Sekvenční diagramy (sequence diagrams): Sekvenční diagramy znázorňují časově orientovanou posloupnost předávání zpráv mezi objekty. Každý objekt má svou časovou osu, která se kreslí shora dolů, víme...

Diagram aktivit: Diagram aktivit je speciálním případem diagramu stavů. Obsahuje počátek, konec, stavy aktivity a přechody mezi stavy. Používá se především k modelování manažerských procesů.

6. Strukturovaný přístup k analýze

Strukturovaná analýza: Strukturovaná analýza spočívá v návrhu struktury dat a funkcí pracujících s daty. Naproti tomu objektově orientovaná analýza chápe systém jako kolekci vzájemně komunikujících objektů.

Modely strukturované analýzy

Funkční modelování (procesní): Funkční modelování znázorňuje toky dat mezi systémem a okolím a data ukládaná do systému. Základním modelem je DFD.

Datové modelování: Datové modelování má význam zejména pro modelování databází. Základním modelem je ER diagram.

Modelování dynamického chování: Pro modelování dynamického chování systému se používá diagram stavů, který zachycuje stavový prostor systému a přechody mezi jeho stavy.

Data Flow Diagram (DFD)

DFD se podobá UC diagramu z OO analýzy, navíc však zachycuje toky dat mezi funkcemi systému a datovými sklady. DFD je tedy blíže návrhu (oproti UC diagramu).

Alternativou k detailům UC jsou zde tzv. minispecifikace, které popisují funkce ve formě strukturovaného textu.

DFD je hierarchický model - každá funkce v něm zachycená může být opět modelována pomocí DFD.

Entity Relationship Diagram (ER diagram)

ER diagram slouží k modelování dat, která potřebujeme v systému uchovat, a vztahů mezi nimi. Data jsou popisována na vyšší úrovni abstrakce.

Entita: Entita je objekt reálného světa, který je nějak rozlišitelný od ostatních (např. konkrétní klient banky).

Entitní množina: Entitní množina je množina entit téhož typu. Tyto entity lze charakterizovat pomocí stejných vlastností (např. klient).

Vztah: Vztah vyjadřuje asociaci mezi entitami (např. Jan Novák vlastní účet č.99).

Vztahová množina: Vztahová množina je množina vztahů téhož typu (např. klient vlastní účet).

Atribut entity

Atribut je vlastnost entity, která nás v kontextu řešeného problému zajímá. Atributy lze klasifikovat podle různých kritérií:

Jednoduché a složené: Jednoduchý atribut je prezentován jednoduchým datovým typem.

Jednohodnotové a vícehodnotové: Vícehodnotový atribut může nabývat více různých hodnot současně.

Prázdné atributy

Mouhou nabývat speciální hodnoty NULL. Umožňují zachytit situace, kdy

reálná hodnota atributu existuje, ale neznáme ji.
nevíme, zda reálná hodnota atributu existuje.

Odvozené atributy: Odvozený atribut není definován entitní množinou přímo, ale lze odvodit na základě jiných atributů nebo vztažených entit.

Vztah mezi entitami

Stupeň vztahu: Stupeň vztahu vyjadřuje, kolik entitních množin je zapojeno do jedné vztahové množiny. Nejčastěji se používají vztahy unární (reflexivní) a binární. Ternární vztahy se většinou převádějí na vztahy binární.

Kardinalita vztahu: Kardinalita je maximální počet vztahů daného typu (vztahové množiny), ve kterých může participovat jedna entita.

Členství vztahu

Členství (membership, participation) je minimální počet vztahů daného typu (vztahové množiny), ve kterých musí participovat jedna entita. Typické hodnoty jsou:

1 - povinné členství
0 - volitelné členství

Atributy vztahu: Atributy vztahu vytváříme, nelze-li přiřadit vztahy ani jedné vázané entitě. Vztahovou množinu pak zpravidla povýšíme na entitní množinu, které atributy přiřadíme.

Více vztahů mezi entitami: Mezi stejnými entitami může existovat více různých vztahů, které mohou vyjadřovat různou sémantiku.

Tvorba ER diagramu

Názvy: Pro entitní množiny používáme podstatná jména v jednotném čísle, pro vztahové množiny většinou slovesa nebo předložky. Pokud je jméno vztahové množiny jasné, není nutné ho uvádět.

Primární klíč: Každá entita musí být jednoznačně identifikovatelná - k tomu slouží primární klíč, jehož hodnota musí být v rámci entitní množiny unikátní.

Atribut vs. entitní množina: Je-li hodnota atributu důležitá, i když neexistuje žádná entita s touto hodnotou jako vlastností, pak bychom ji měli modelovat jako entitu.

Vztahy M:N: Vztahy typu M:N se těžko převádějí na schéma relační databáze, proto se transformují na vztahy typu 1:N pomocí vazební entitní množiny.

Slabé entitní množiny (weak)

Slabá entitní množina je existenčně závislá na jiné (silné) entitní množině. Označuje se jako <<weak>>. Identifikátor slabé entitní množiny má následující složky:

dominantní identifikátor silné entitní množiny
diskriminátor slabé entitní množiny

Entitu modelujeme jako slabou, když tato entita kompletně zmizí po odstranění odpovídající identifikující entity. Jsme-li na pochybách, volíme silnou entitní množinu.

7. Návrh

Výstupy etapy návrhu

upřesnění diagramů interakce (z etapy analýzy)
návrhové třídy - upřesňují analytické třídy
návrhové podsystémy - vychází z analytických balíčků
stavové diagramy
rozhraní

Návrhové třídy

Návrhové třídy se vytváří z analytických tříd doplněním implementačně důležitých vlastností. Mohou být závislé na použitém programovacím jazyku, frameworku, atd. Návrhové třídy lze přímo implementovat.

Rozhraní

viz. Objektová orientace - rozhraní

Upřesňování analytických modelů

Diagramy interakce jsou doplňovány o nové třídy, které v analytickém modelu nebyly. Jsou doplněny o implementačně specifické prvky.

Stavové diagramy

Stavový diagram modeluje životní cyklus jednoho reaktivního objektu.

Reaktivní objekt: Reaktivní objekt je takový objekt, který reaguje na vnější události. Jeho životní cyklus je modelován jako řada stavů, přechodů a událostí.

8. Implementace a testování

Implementace softwaru

Implementace softwaru je transformace návrhu jednotlivých modulů a jejich vzájemných vazeb do programové realizace.

Výběr programovacího jazyka

Pro výběr programovacího jazyka se řídíme následujícími kritérii:

zkušenosti programátorů, vhodnost jazyka
rozšířenost jazyka, přenositelnost
dostupnost knihoven, vývojového prostředí, ...
požadavky zákazníka

Strategie implementace

Programy se nevytvářejí tak, aby se lehce psaly, ale tak aby se lehce četly a modifikovaly.

Zdola nahoru: Nejdříve se implementují moduly nejnižší vrstvy aplikace. Odladěné moduly se pak dají přímo využívat při vytváření modulů vyšší úrovně. Nevýhoda spočívá v tom, že chyby v aplikační logice se projeví až při etapě integračního testování.

Shora dolů: Nejdříve se vytvoří moduly na nejvyšší úrovni a pak se postupně implementují moduly nižších vrstev aplikace. Systém lze dříve testovat jako celek a nejzávažnější chyby jsou včas odstraněny. Nevýhoda spočívá v nutnosti simulovat podsystémy, které ještě nejsou implementované.

Verifikace a validace programu

Někdy není nezbytná 100% správnost programu. (viz. zaměstnanec s 11 dětmi)

Verifikace: Verifikace je ověření, zda software vyhovuje specifikaci.

Validace: Validace je ověření, že vyvíjený software splňuje potřeby uživatele.

Statické ověřování: Statické ověřování nevyžaduje běh programu, lze ho tedy provádět v kterékoliv etapě vývoje softwaru.

Dynamické ověřování: Dynamické ověřování (testování) odvozuje vlastnosti softwaru na základě výsledků běhu programu nebo prototypu s vybranými vstupy.

Testování

Nejdříve jsou navrženy testovací vstupy. Testovací vstupy představují množinu dvojic vstupní data / očekávaná výstupní data.
Vstupní data jsou zadány na vstup programu a zaznamenány výsledky (výstupní data).
Výstupní data se porovnají s očekávanými výstupními daty.
Test, který neodhalí nesprávné chování systému, je neúspěšný.

Výběr testovacích vstupů: Snažíme se vybrat takové testovací vstupy, u kterých je velká pravděpodobnost, že způsobí chybu.

Testovací kritérium

Testovací kritérium K je spolehlivé, když všechny množiny testovacích vstupů splňující kritérium K odhalí stejné chyby.

Testovací kritérium K je platné, když pro každou chybu v programu existuje množina testovacích vstupů, která splňuje kritérium K a chybu odhalí.

Náhodné testování: Testovací vstupy jsou vybírány náhodně, například pomocí generátoru náhodných čísel. Nevýhoda spočívá v nedostatečném testování okrajových hodnot. Proto se většinou doplňuje jiným vhodným kritériem.

Funkcionální testování: (Metoda černé skříňky) Funkcionální testování vychází pouze ze specifikace a neuvažuje vnitřní strukturu programu.; Množina vstupních hodnot je rozložena do tříd ekvivalence. Z každé třídy ekvivalence se vybere průměrná hodnota nebo medián, hranice třídy a několik náhodných hodnot.

Strukturální testování

(Metoda bílé skříňky) Strukturální testování vychází z konkrétní implementace.

Mutační testování: Mutační testování slouží pro otestování množiny testovacích vstupů. Když je množina testovacích vstupů vybrána, udělá se v programu úmyslně několik chyb. Podle toho, kolik úmyslně vložených chyb je zachyceno, se dá odhadnout, jak úspěšné bude testování.

Strategie testování

Testování zdola nahoru

Testování shora dolu

Regresní testování: Regresní testování spočívá v opakovaném vyhodnocení testů po každé změně programu. Programátor se pak může přesvědčit, je-li zjištěná chyba skutečně opravena a hlavně, jestli nezanesl do programu chyby nové. Regresní testování musí být zautomatizované, protože se pouští opakovaně.

Akceptační testování: Akceptační testování provádí uživatel na reálných datech. Na základě tohoto testování se zákazník rozhodne, jestli program splňuje zadání. Pokud zákazník software akceptuje, další změny již představují údržbu systému.

Alfa-beta testování: U krabicového SW není možné provádět akceptační testování u každého zákazníka.; Proto se v první fázi provádí alfa testování - vývojový tým si k sobě pozve vybraného uživatele, vývojáři pak sledují jeho práci se systémem. Při alfa testování se objevují chyby vzniklé odlišným způsobem práce uživatele a vývojáře se systémem.; Beta testování provádí uživatelé u sebe. Výsledkem je zpráva uživatele, na jejímž základě je software upraven a uvolněn do prodeje. Při beta testování se objevují chyby, způsobené během programu v neznámém prostředí.

9. Řízení softwarových projektů

Projekt: Projekt je časově ohraničené úsilí, které se vyvíjí s cílem vytvořit jedinečný výsledek - např. výrobek nebo službu. Každý projekt je časově ohraničený - má jednoznačný začátek a konec. Konec projektu je dosažen, jsou-li splněny stanovené cíle.

Parametry softwarového projektu

rozsah, kvalita
cena
čas

Sestavení vývojového týmu

Beran: Beran příliš důrazně prosazuje variantu, kterou považuje za nejlepší. Problém nastává pokud se v týmu potkají 2 berani. Řešením situace je vymezení odpovědnosti každému z nich.

Slabý článek: Slabý článek je člen týmu, který je v porovnání s ostatními členy méně šikovný. Vhodným řešením je zařadit slabý článek na méně zodpovědnou pozici.

Dělnická mentalita: Lidé s dělnickou mentalitou mají dostatečné schopnosti, ale snaží se přežít pracovní dobu s vynaložením co nejmenší námahy. Vedoucí by měl takovým lidem přidělovat dobře měřitelnou práci.

Snaživec: Snaživec odvádí na své pozici dobrou práci, ale má zájem o prestižnější místo, na které nemusí mít předpoklady. Řešením je najít snaživci uspokojivou pozici, ale takovou, která neohrozí úspěšnost projektu.

Management projektů

Management je proces koordinace činností skupiny lidí, který realizuje jednotlivec nebo skupina lidí za účelem dosažení stanovených cílů.

Demingův manažerský cyklus (nekonečná smyčka)

Naplánuj
(vytvoření plánu)
Udělej
(provedení plánu)
Zkontroluj
(zhodnocení výsledků)
Jednej
(zlepšení procesu řízení na základě dosažených výsledků)

Etapy projektu z pohledu managementu

Inicializace: Během inicializace se získávají relevantní informace pro plánování projektu. Součástí této etapy je studie vhodnosti a analýza rizik.

Plánování: Cílem plánování je pochopení cílů projektu a vytvoření základny pro sledování a řízení práce. Plánování je třeba provádět v rozumné míře.

Řízení: Při řízení se sleduje aktuální stav projektu a porovnává se s plánem. Na základě toho se provádějí změny v plánu a odhaduje se další vývoj projektu.

Provádění: Provádění představuje samotnou realizaci plánu. Ze všech etap spotřebuje nejvíce času a peněz.

Ukončení: Ukončení představuje předání výrobků nebo služeb zákazníkovi. Zaznamenávají se nové poznatky z vývoje projektu. Vyčleňují se prostředky na údržbu softwaru.

Řízení kvality softwarových projektů

Kvalita softwarového projektu se může různým účastníkům vývoje různě. Pro uživatele odpovídá kvalita jednoduchosti obsluhy systému, efektivitě práce se systémem a např. jeho spolehlivostí. Pro vývojáře kvalita odpovídá čitelným a modifikovatelným programům a srozumitelné a přesné dokumentaci. Pro manažera kvalita představuje dodání výrobku včas, v rámci rozpočtu a dohodnutých požadavků.

Normy pro systém zajištění kvality

U softwarových produktů nelze jednoduše měřit kvalitu při nějaké výstupní kontrole. Předpokládá se, že když má organizace kvalitní proces tvorby softwaru, bude software kvalitní.

ISO 9000: Soustava norem ISO 9000 je primárně určena pro hromadnou výrobu, ale využívá se i pro tvorbu softwaru. Získání certifikátu znamená pro firmu vyšší konkurenceschopnost a lepší jméno. Zavedení ISO 9000 je však poměrně drahé a časově náročné a může se tak projevit na ceně výrobků.

Měření v softwarovém inženýrství

Měření v softwarovém inženýrství umožňuje softwarové projekty řídit. Samotné měření však může snížit efektivitu práce na softwarovém projektu.

Měření může být přímé a nepřímé (odvozené z přímých měřeních). Pro úspěch projektu je důležitá dohoda na kritériích projektu a tato kritéria musí být měřitelná (viz. přátelské uživatelské rozhraní).

Metriky pro software

LOC = Lines Of Code

kLOC = kilo LOC

MTBF = Mean Time Between Failures

Střední doba mezi výpadky systému - používá se pro měření spolehlivosti. Je dána součtem MTTR a MTTF.

MTTR = Mean Time To Recovery: Střední doba opravy

MTTF = Mean Time To Failure: Střední doba do následujícího výpadku

Dostupnost: Dostupnost je pravděpodobnost, že v daném čase program pracuje správně. Počítá se nepřímo jako MTTF/MTBF.

Chybovost: Chybovost je průměrný počet chyb v jednom kLOC.

10. Agilní metodologie

Metodologie: Disciplinovaný proces nad vývojem softwaru, který ho činí predikovatelný a efektivnější.

Agilní metodologie: Kompromis mezi klasickými metodologiemi a chaotickým přístupem k vývoji. Všechny aktivity vývoje jsou součástí návrhu, klíčovou částí dokumentace je samotný zdrojový kód.; Agilní metodologie jsou adaptivní - reagují na změny, procesy se v čase vyvíjejí. Nevytváří se detailní plány pro delší časová období.; Agilní metodologie jsou orientované na lidi - každý proces se přizpůsobuje vývojovému týmu. Není definována pevná posloupnost kroků.; Agilní metodologie lépe reagují na měnící se požadavky zákazníka, ale vyžadují jeho aktivní spolupráci.

Predikovatelnost požadavků: Existují projekty, o jejichž požadavcích máme na začátku jasnou představu. U některých se ale časem požadavky mění - zejména business projekty. Také existují projekty, kde máme na začátku jen mlhavou představu.; Některé procesně orientované modely s tím počítají - iterativní, inkrementální, spirálový. Důležitá je však délka jedné iterace.

Metody orientované na lidi: Lidé mají problémy fungovat konzistentně v průběhu času. Jsou různí a proměnliví (v místě a čase). Lidé jsou komunikující bytosti...

CRC Cards: (Class-Responsibilities-Collaborators)
Identifikace tříd, jejich zodpovědností a spolupracujících tříd.

Extrémní programování (XP)

Zpětná vazba: Správnost systému je ověřována na základě zpětné vazby. Navrhovaný systém je co nejrychleji vyvinut, předložen zákazníkovi a na základě zpětné vazby upravován.

Jednoduchost: Úspora času na jednoduchých částech pro věci opravdu složité

Komunikace: Testování, párové programování, odhady úkolů, ...

Odvaha: Nebát se provést zásadní změny - i za cenu dočasného snížení úspěšnosti testů.

Testování: Ke každé funkci píšeme testy - nejlépe ještě před její implementací.

Párové programování: Víme...

Refaktorizace: Při refaktorizaci se stávající návrh zjednodušuje a zefektivňuje, nemění se však funkcionalita.

Metriky: Pokud přestane metrika plnit svůj účel, je nahrazena jinou.

Iterace: Délka iterace je 1-4 týdny. Nezbytným výsledkem každé iterace je sada testů.

Crystal

Crystal je také metoda orientovaná na lidi, na rozdíl od XP je však méně striktní. Obecně je však méně produktivní než XP. Na konci každé iterace jsou vloženy prostředky klasických metodologií.

Scrum

Iterace má délku 30 dní a nazývá se sprint. Každý den se konají 15 minutová setkání (scrum), kde se analyzuje, co se udělalo a co je potřeba ještě udělat. Scrum je možné kombinovat s XP.

Light RUP

Light RUP používá měsíční iterace. První tři dny v každé iteraci se využívá UML pro vyjasnění návrhu.

11. Ochrana intelektuálního vlastnictví

Vlastnictví: Vlastnictví je neomezené a výlučné právo k "věci", pomáhá řešit spory o vzácné zdroje. Vlastnictví hmotných zdrojů je přirozené a pro společnost prospěšné.; Vlastnictví nehmotných zdrojů je sporné, protože nehmotné zdroje (=myšlenky) postrádají atribut vzácnosti.

Patent: První patenty byly udělovány v 15. století formou monopolu na určitý výrobek nebo službu. Každý stát má svůj patentový úřad s vlastním polem působnosti. Funkci patentového úřadu pro ČR plní Úřad průmyslového vlastnictví.; Aby bylo technické řešení uznáno vynálezem, musí být nové, nezveřejněné, musí být výsledkem výzkumné činnosti a průmyslově využitelné.; Patent udělený v ČR platí 20 let. Souhlas k využití patentu se uděluje licenční smlouvou. Patent je možné prodat.

Autorské právo: Autorské právo vzniká automaticky počínaje vytvořením díla. Podle Všeobecné úmluvy o autorském právu (uzavřené v Ženevě v roce 1952) jsou autorská práva chráněna ještě 70 let po smrti autora.; Počítačové programy jsou autorským právem chráněny jako dílo literární.

Ochranná známka

Ochranná známka je slovní, obrazové nebo prostorové označení výrobku nebo služby. Plní několik funkcí:

Rozlišovací	Odlišuje výrobce nebo poskytovatele služeb.
Ochranou	Zákazník ví, co dostane.
Propagační	Vytváří poptávku po takto označeném zboží.

Obchodní tajemství: Informace podniku, které nejsou v příslušných obchodních kruzích běžně dostupné.

Licence

Licence slouží k udělení práv k použití intelektuálního vlastnictví.

Public domain	Veřejné dílo, použitelné bez omezení.
Open source	Volně dostupné zdrojové kódy.
Proprietární	Výrobce prodává spustitelnou aplikaci.

Open source licence

Pod licencí Open source je šířen software s volně dostupnými zdrojovými kódy. Nejedná se o software zadarmo :-) Program je možné spouštět, studovat, upravovat, dále šířit a zveřejňovat svá vylepšení.

General Public Licence (GPL)	Vyžaduje, aby SW zůstal pod GPL.
Lesser GPL (LGPL)	Slabší než GPL, využívá se např. pro knihovny.
Free Documentation Licence	Používá se pro dokumentaci.
BSD Licence	Nevyžaduje, aby byl upravený program šířen pod BSD licencí.