Softwarové inženýrství

Životní cyklus software
(dle unifikovaného procesu)

·        Požadavky

·        Analýza

·        Design/návrh

·        Implementace

·        Testování

Každá fáze cyklu se dále probíhá v etapách:

·        Zahájení

·        Rozpracování

·        Konstrukce

·        Zavedení

Životní cyklus software
(jiný pohled)

·        Nápad

·        Neformální specifikace (odborný článek, úvodní studie)

·        Formální specifikace (analýza)

·        Dekompozice (návrh)

·        Řešení komponent (modulů)

·        Implementace komponent

·        Testování komponent

·        Integrace komponent do celku

·        Testování celku (akceptační test)

·        Instalace

·        Provoz a údržba

Náročnost fází životního cyklu

Ze statistik pro velký systém o řádově stovky tisíc řádků kódu vyplývá, že úsíli věnované těmto fázím by mělo být rozděleno zhruba v poměru:

·        Analýza 40%

·        Návrh 40%

·        Implementace 20%

Softwarové inženýrství

Proces

·        Je vodítkem k vytvoření kvalitního sw produktu

·        Poskytuje rámec pro řízení a organizování aktivit, které se snadno mohou vymknout kontrole

·        Různé projekty vyžadují různé procesy

·        Sw procesy jsou uzpůsobovány konkrétním potřebám

·        Sw produkty (programy, dokumentace, data) jsou výsledkem aktivit definovaných SW procesem

·        Dobrými indikátory funkčního sw procesu jdou kvalita, dodržení času a dlouhodobá realizovatelnost produktu.

Proč je proces důležitý?

·        Umožnuje rozdělení práce

o   Každý člen týmu ví co má dělat

·        Podporuje týmovou/individuální práci/komunikaci

o   Porozumění tomu, co se děje

·        Usnadňuje řízení projektu

o   Manažéři vědí lépe, co se děje

·        Umožnuje znovupoužití zkušenosti

o   Přenos mezi různými projekty

·        Usnadňuje trénink

o   Lze ho standardizovat

·        Podporuje zvyšování produktivity

o   Vývoj se může stát opakovatelným

Obecné (generické) fáze SW procesu

·        Definice

o   Co?

§  Information enginnering

§  Software project planning

§  Requirements analysis

·        Vývoj

o   Jak?

§  Software design

§  Code generatiob

§  Software testing

·        Podpora a údržba

o   Změny

§  Corrective maintenance

§  Adaptive maintenance

§  Perfective maintenance

§  Preventative maintenance

Obecný procesní rámec (OPR)

·        Ustanovuje základní obecný rámec pro procesy

·        Definuje

o   Rámcové aktivity

o   Množiny úloh

§  Úkoly

§  Milníky

§  Kontrolní body

o   Zastřešující činnosti

Obecný procesní rámec: zastřešující činnosti

·        Monitorování a kontrola

·        Formální technické revize a kontroly (review)

·        Zajišťování kvality SW

·        Řízení a správa konfigurace

·        Příprava dokumentů

·        Management znovupoužití ( Reusability management)

·        Používání metrik

·        Řízení rizik

Úroveň vyspělosti procesu

·        CMM definuje jednotlivé úrovně vyspělosti SW

·        Level 1 : Iniciální

o   Ad hoc sw proces, základní řízení projektu

·        Level 2 : Opakovatelný

o   Schopný opakovat předchozí úspěchy, integrovaný proces řízení projektu

·        Level 3 : Definovaný

o   Řídící a inženýrský procesy jsou zdukumentovány, standardizovány a integrovány s širšími organizačními procesy

·        Level 4 : Řízený

o   K procesům a produktům je přistupováno pomocí detailních kvantitativních metrik a jsou pomocí nich měřeny

·        Level 5: Optimalizující

o   Samozlepšujícíc se proces

o   Zpětná vazba

Modely životního cyklu SW

·        Existují zavedené modely, např.

o   Lineární

o   Model vodopád

o   Spirálový model

o   Přírůstkový model

·        Model životního cyklu určuje základní schéma postupu

·        Životní cyklus by měl vždy začínat dostatečně přesnou specifikací a návrhem

·        Není nutno realizovat celý systém najednou – naopak přírůstky poskytují uživateli dobrý pocit postupu práce

Lineární model (model vodopád)

·        Nevrací se zpět

·        Vhodný v případě jasného zadání

·        Problémy:

o   Měření

o   Kontrola

o   skluzy

Prototypy

·        v cyklech

·        výsledkem fází jsou prototypy

·        výhody

o   postup

o   měření

o   zpětná vazba

·        problémy

o   zahození prototypu

o   poněkud vágní metody

Rapid Application Devolopement (RAD)

·        krátký cyklus

·        adaptace lineárního modelu

·        týmy

·        paralelní běh

·        podprojekty

 

Evoluční (iterativní) modely

·        řada modelů

·        proces probíhá typicky v iteracích

·        výsledek iterací bývají funkční produkty s omezenou funkcionalitou

o   tím se liší od lineárního i od prototypů

Metodika Rational Unified Process (RUP)

Základní činnosti                                             Fáze

1.       požadavky                                                         Zahájení

2.       analýza                                                               rozpracování

3.       design                                                                 konstrukce

4.       implementace                                                 zavedení

5.       testování

Interativní vývoj v RUP

·        objektivní posouzení stavu projektu

·        rovnoměrnější pracovní vytížení vývojářského týmu

·        testování meziverzí

·        spolupráce s uživateli v průběhu celého projektu

·        včasné rozpoznání nesrovnalostí mezi požadavky, návrhem a implementaci

·        Snazší zapracování změn požadavků

4G metody  (taky agilní metody)

·        Metody 4. Generace

·        Cílem je

o   Rychlé,

o   Automatizované,

o   Vysokoúrovňové

·        Generování, vytváření produktů, dokumentů

·        Nástroje

o   CASE systems

o   Database query language

o   Report generator

o   Screen painter

o   Charting/graphing tools

o   Spreadsheet

o   Application generator

 

Extrémní programování – XP (ne windows!!! – ani Vista)

·        Pracuje se čtyřmi proměnnými

o   Kvalita

o   Čas

o   Náklady

o   Šíře zadání

·        Hodnoty

o   Komunikace

o   Jednoduchost

o   Zpětná vazba

o   Odvaha

o   Respekt

Postupy XP

·        plánovací hra

o   průzkum

o   závazek

o   řízení

·        malá verze

·        metafora (příběh vývoje)

·        jednoduchý návrh

·        testování

·        refaktorizace

·        párové programování

·        společné vlastnictví

·        nepřetržitá integrace

·        40-ti hodinový pracovní týden

·        Zákazník na pracovišti

·        Standardy pro psaní zdrojového kódu

Řízení projektů

 

Projekty obecně

Vznik SW dílá je typicky ralizován jako 1 nebo více projektů

Projekt je dobře definovaná posloupnost činností, která má určen začátek a konec, je zaměřena na dosažení určitého cíle a je uskutečňována pomocí zdrojů – lidí, věcí, nástroje a prostředků.

Řízení projektů

·        Řízení projektů zahrnuje:

o   Plánování

o   Monitorování

o   Kontrolu

§  Lidí, procesů, událostí

o   Každý něco řídí, rozsah závisí na konkrétní roli v rámci projektu

·        Každý něco řidí, rozsah závisí na konkrétní roli v rámci projektu

·        SW musí vznikat řízeně

o   Příliš komplexní

o   Dlouhodobá činnost

4P

·        Úspěšní manažeři se musí zaměřit na tzv. 4P:

o   Personál (people)

o   Produkt

o   Proces

o   Projekt

·        Plán projektu:

o   Dokument definující 4P s cíle zajistit finanční a časovou efektivitu

Lidé – typické úlohy

·        Nábor, výběr, výkonnost, trénink, vzdělání, školení, odměňování, karierní růst/vývoj, organizace, práce v týmu, vývoj.

Lidé a hráči

·        Senior manažeři

o   Klíčové obchodní vize a myšlenky

·        Projektový manažeři

o   Plány, motivace, organizace a kontrola „praktiků“

·        Praktici/inženýři

o   Znalosti a dovednosti

·        Zákazníci

o   Požadavky

·        Koncoví uživatelé

o   Interakce, zpětná vazby

Vedoucí týmu

·        Intenzivní a náročná činnost

·        Vyžaduje člověka

o   Zkušeného

o   Talentovaného

o   Odborně zdatného

o   Vhodný temperament a povahový tup

·        Zkušení praktici nebývají často dobrými vedoucími projektu

·        Není dobré techniky a programátory nutit do role vedoucího týmu

Úlohy vedoucího týmu (J. Weinberg)

·        Motivace

o   Schopnost ostatbí motivovat k tomu, aby pracovali, jak nejlépe umí

·        Organizování

o   Práce s procesy, plánování, kontrola

·        Myšlenky a inovace

o   Schopnost motivovat spolupracovníky ke kreativitě a i v prostředí s danými hranicemi a omezeními

Dovednosti dobrého vedoucího týmu

·        Schopnost řešit problémy

o   Identifikace, diagnóza, nacházení relevantních a přiměřených řešení

·        Identita manažera

o   Na strunu jednu je třeba čídit a vést

o   Na stranu druhou důvěřovat lidem a nechat jim dostatek autonomie

·        Ocenění úspěchů

o   Jednak ocenění dílčích úspěchů členů

o   Netrestat podstupování kontrolovaného rizika

·        Týmová komunikace

o   Verbální i neverbální

·        Sebeovládání

Tým

·        Neexistuje optimální organizace týmu

·        Závisí na okolnostech, projektu, lidech

·        Typy

o   Demokratický decentralizovaný

o   Kontrolovaný decentralizovaný

o   Kontrolovaný centralizovaný

·        Dobře fungující tým

o   Vzájemná důvěra mezi členy

o   Přiměřené rozložení dovedností

o   Konfliktní typy mohou být vyloučeny z týmu

·        Manažer musí na začátku jasně stanovit odpovědnost a role týmu

Selský rozum radí k projektům

·        Začněte „pravou nohou“

o   Pracuj tvrdě a smysluplně

·        Udržuj vysoukou hybnost (rychlost)

o   Tempo má tendenci klesat

·        Měř postup

·        Dělej rozumná rozhodnutí

o   KISS (keep is simple and stupid)

o   Používej již hotové

·        Pouč se z chyb

o   Dělej zpětnou analýzu

W5HH princip

12 Essential Attributes for Successful software

1. effective project planning

2. effective project cost estimating

3. effective project measurements

4. effective project milestone tracking

5. effective project quality control

6. effective project change management

7. effective development processes

8. effective communications

9. capable project managers

10. capable technical personnel

11. significant use of specialists

12. substantial volumes of reusable materiál

 

Proces vývoje SW Objektově orientované modelování v UML

Co je to UML

·        Unified Modeling Language

·        Obecný jazyk (notace) určený k modelování systémů

·        Zahrnuje současné nejlepší postupy (best practices) v modelování (vychází z řady předchozích vizuálních modelovacích technik)

·        Je neutrální vůču metodologiím a jazykům

·        Průmyslový standard pro modelování OO systémů

·        Standardizační orgán: OMG (Object Managemend Group)

·        Základní předpoklad OO modelování

o   SW může být modelován jako soubor spolupracujících objektů

Proč unifikovaný

·        Snaží se o unifikaci různých domén

·        Vývojový cyklus

·        Aplikační doména

o   Realtimové systémy, distribuované systémy

·        Implementační jazyky

o   C++, Java, #

o   Je nezávislý na jazyce

·        Vývojové procesy

o   Např. Unified Process (UP), Rational Unified Process (RUP)

·        Vlastní interní pojmy

o   Vnitřní jednota  a konzistence

Oblasti pokrývaní  UML

·        Funkční model

o   Diagramy popisující fungování systému

·        Objektový model

o   Popis struktury systému pomocí tříd, objektů, atributů, operací, relací, vazeb, asociací

·        Dynamický model

o   Popisuje dynamické aspekty systému

o   Interakce, chování systém v čase, spolupráce tříd, sekvence volání, stavy systému a přechody mezi nimi

 

Struktura jazyka UML

Zaoblený obdélník: UML

 

 

 

 


 

Zaoblený obdélník: Stavební bloky
Zaoblený obdélník: Společné mechanismy
Zaoblený obdélník: Architektura

 

 

 

 

 


 

·        Stavební bloky

o   Předměty

o   Vztahy

o   Diagramy

·        Společné mechanismy

o   Specifikace

o   Ozdoby

o   Podskupiny

o   Mechanismy rozšiřitelnosti

·        Architektura

o   Pohled případů užití

o   Logický pohled

o   Procesní pohled

o   Implementační pohled

o   Pohled nasazení

Struktura jazyka UML II

·        Stavební bloky        - základní modelovací elementy

o   Předměty: modelovací elementy – třídy, rozhraní, případy užití, interakce, balíčky, poznámky

o   Vztahy (relace): specifikují sémantickou souvislost 2 a více předmětů

o   Diagramy: pohled na UML modely: zobrazující soubory předmětů vizualizující CP resp. Jak bude systém řešen

·        Společné mechanismy – společné způsoby dosahování specifických cílů

o   Specifikace: textové popisy sémantiky modelovaných elementů

o   Ozdoby: doplňující vizuální detaily modelovaných elementů

o   Podskupiny (common division): specifické způsoby přemýšlení o světě (vidění/modelovíní světa) – např. vztahy klasifikátor – instance, rozhranní-implementace

o   Mechanismy rozšiřitelnosti: specifikuje mechanismy pro rozšíření modelovacích elementů jazyka pro specifické účely (omezení, stereotypy, označené hodnoty)

·        Architektura – zachycení strategických aspektů struktury systému jako celku pomocí UML:

o   Pohled případu užití: zachycuje základní požadavky na systém a poskytuje východisko pro tvorbu dalších pohledů

o   Logický pohled: zachycuje slovník problémové oblasti (domény) pomocí sady tříd a objektů a jejich vztahů

o   Procesní pohled: modeluje vykonavatelná vlákna a procesy v systému

o   Implementační pohled: modeluje soubory a komponenty, které utvářejí kódový základ systému

o   Pohled nasazení: modeluje fyzické nasazení komponent na výpočetní uzly jako jsou počítač a jiné HW zařízení

Modelování

·        SYSTÉM  organizovaná množina komunikujících (propojených) součástí

o   Přirozený X umělý systém

o   Podsystém

·        MODELOVÁNÍ           - PROSTŘEDKY PRO ZVLÁDNUTÍ KOMPLEXNÍHO A SLOŽITÝCH SYSTÉMŮ

o   Vytváření abstrakce systému

o   Zaměření na důležité aspekty systému

o   Model systému je sada všech modelů vytvořených během vývoje

·        POHLED – zaměřuje se na část modelu a zobrazuje ji tak, aby byla jasní a srozumitelná

Abstrakce

Proces výběru některých aspektů a charakteristik systému a vyloučení jiných irelevantních

·        Abstrakce je vždy dělána s účelem

·        Je možných mnoho různých abstrakcí

·        Všechny jsou neúplným popisem reality

·        Nepotřebujeme úplnost, ale adekvátnost modelu vzhledem k jeho účelu!

Typy abstrakce

·        Klasifikace- seskupuje podobné instance objektů

o   Najdeme společné vlastnosti a ignorujeme jedinečné

·        Agregace – seskupení různých objektů objektů

o   Ignorujeme odlišnosti a zaměříme se na to, že dohromoday utvářejí celek

·        Generalizace – seskupení podobných množin objektů

o   Rozdíl mezi klasifikací a generalizací

o   Klasifikace – aplikuje na individuální instance objektů

o   Generalizace – aplikuje se na množiny objektů (třídy)

 

Datové typy, abstraktní DT a instance

·        Datový typ:

o   Abstrakce v kontextu programovacího jazyka

o   Jednoznačné jméno

o   Vymezuje množinu přípustných hodnot (členů, instancí)

o   Definuje množinu přípustných operací

o   P5.:

§  Integer

§  String

§  Zamestnanec

·        Abstraktní datový typ

o   DT definovaný pomocí implementačně nezávislé specifikace

o   Např. matematické pojmy

§  Množiny, mapa, sekvence

o   Nemůže mít instance

Třídy a objekty

·        Třída:

o   abstrakce v OO modelování zachycuje koncept, jeho hranice, význam a operace

o   Prostředky jazyka pro definici nových datových typů

o   Explicitně propojuje datové struktury (viz. Např. C a stuct) s operacemi na nich (funkce, metody)

o   Třída definuje

§  Operace

§  Atributy

·        Objekty

o   Je instancí třídy

o   Např. třída Zamestnanec a její konkrétní instance Karel Novák, instlalatér.

Proč jsou třídy užitečné?

·        Užitečná prostředek konceptualizace světa a jeho modelování

o   Neboli nazýváme věci jejich jmény (např. typy kočka, pes, zvíře…)

o   Spojení operací s odpovídajícími daty

o   Vhodná základ pro modularizaci kódu

·        Snižuje složitost problému

 

·        Dědičnost (inheritance)

·        Zapouzdření (encapsulation)

·        Polymorfismus (pomymorphism)

 

OO modelování

·        Aplikační doména

o   Reprezentuje všechny aspekty z uživatelského pohledu

o   Např. procesy, účastníky, uživaele,…

o   Pozor: v čase se vyvíjí

·        Domény řešení

o   Modelujem prostor všech možných systémů řešících problém

o   Návrh objektů, tříd, procesů atp.

o   Bohatší na AD

 

·        Objektově orientovaná analýza

o   Zabývá se modelováním aplikační domény

·        Objektově orientovaný design

o   Modelování démy řešení

Diagram případů užití (Use Case diagram)

·        Zachycuje chování systému z pohledu uživatele

·        Definuje hranice systému, uživatele systému a jednotlivé případy užití

·        Vyvíjen společně s modelem tříd

·        Pomáhá:

o   Zaznamenat data a funkční požadavky

o   Plánování iterací vývoje

o   Kontrola a validace systému

·        Dynamický model začíná analýzou use-case

o   Řídí celý vývojový proces

o   Veškeré požadovaná funkcionalita je popsána v use-casech

§  Use-case model je vyvíjen inkrementálně

Use case – uživatel (actor)

·        Externí entity, která interaguje ses sytémem

·        Může to být člověk nebo jiný systém

·        Poskytuje vstupy a přijímá výstupy systému

·        Spíš než konkrétního uživatele se jedná o role

o   Více rolí na 1 uživatele;

o   Více uživatelů v 1 roli

·        Uživatel je v podstatě třídou (klasifikátor)

o   Konkrétní uživatel pak jeho instancí

Případ užití (PU)

·        Část systému realizující jeho určitou specifickou funkcionalitu z hlediska uživatele

·        Specifikuje

o   Interakce s uživatelem

o   Sekvence akcí/událostí iniciovaných uživatelem

o   Ignorujeme zatím výjimky chybové stavy

o   Dále volitelně též

§  Vstupní a výstpuní podmínky

§  Jiné kvalitativní požadavky

o   Shrnuje v sobě více možných scénářů řešící tentýž případ užití

Specifikace případu užití

·        Textová specifikace jednotlivých případů užití

·        Není přesně definováno v UML

·        Má možná větší význma než samotný diagram

·        Specifikuje

o   Název případu užití (PU)

o   Účastnící (iniciátor, komunikující učastník)

o   Tok událostí (co se bude dít během PU)

§  Má podobu číslovaného seznamu událostí

§  Potřebná data

§  Interakce s uživatelem

o   Vstupní podmínka (např. uživatel je přihlášen)

o   Výstupní podmínka (uživatel zaplatil)

o   Kvalitativní požadavky (např. systém odpoví do 30 vteřin)

Scénaře

·        PU je poměrně abstraktní specifikace která může být realizována různými scénáři

o   Např. výběr zboží

§  Na základě doporučení

§  Vyhledávání

§  Přehled kategorií

o   Obsah scénáře

§  Název

§  Účastníci

§  Tok událostí

Use case Model Detaily – Includy

·        Více PU může sdílet tutéž funkcionalitu- použijeme

·        Rozdělíme use-casy a pak je znovu- používáme

 

Use case model detaily – Extend

·        Umožňuje rozšířit chování PU pomocí jiného případu užití

·        Vhodné např. pro ošetření výjimečných stavů

 

Diagram tříd

·        Popisuje strukturu systému pomocí tříd a jejich vztahů

·        Příklad dědičnosti:

 

Třídy v UML notaci

Objekty v UML

 

Asociace

 

 

Sekvenční diagram

·        Reprezentuje účastníky a objekty a jejich interakce v čase

·        Prvky diagramu

o   Objekty – znázorněné obvykle jako sloupce

o   Interakce mezi objekty (zprávy) – orientované šipky mezi objekty

o   Události – události, které vyvolaly interakci

o   Reakce – odezvy na události (výstupy)

o   Časová osa – pro vyznačení sledu událostí

 

 

Diagram aktivit

·        Používá se pro dokumentaci případu užití (workflow)

·        Popisuje chování systému prostřednictvím aktivit

·        Aktivitua je modelovací element reprezentující sadu operací

·        Je podobný diagramu toků (ten v UML není)

·        Prvky diagramu

o   Počáteční a koncový stav – tlustá tečka (v kolečku pro konc.stav)

o   Aktivity – elipsy

o   Přechody mezi aktivitami – šipky

o   Synchronizační body – tlusté obdélníky

o   Rozhodnutí – kosočtverec

Stavový diagram

·        Popisuje dynamiku chování individuálního objektu (nikoliv skupiny objektů)

·        Primitivy jsou

o   Stavy a

o   Přechody mezi stavy

·        Stav reprezentuje určitou množinu hodnot daného objektu (stav objektu)

·        Je vhodný zejména pro popis složitějšího chování objektů, kde chceme přesně specifikovat toto chování

 

 

Získávání a zpracování požadavků

Sběr a zpracování požadavků – aktivity dle unified Process

·        Modelování domény

·        Modelování případu užití

·        Specifikace uživatelského rozhraní a modelů

·        Validace požadavků

Sběr požadavků

Požadavek
vlastnosti, kterou musí systém mít, nebo omezení které musí splňovat, aby byl akceptován zákazníkem

Zachycování požadavků

Vyžaduje spolupráci různých skupin účastníků   => DISPROPORCE ZNALOSTÍ

Výzva: Jak překonat disproporci

Zahrnuje

·        Identifikace

o   Uživatelů scénaře

o   Případu užití

o   Upřesnění PU

o   Vztahů mezi PU a uživateli

o   Analytických tříd

o   Nefunkčních požadavků

Proč je zpracování požadavků těžké?

Cílem je vytvořit správný systém

                    Systém splňující požadavky uživatelů

Ale, uživatelé často neví, co potřebují

·        Mnoho kategorií uživatelů (znají jen své potřeby a doménu)

·        Nevidí „ucelený“ obraz systému

·        Nemusí vědět, které aspekty jejich práce lze zpracovat počítačově

 

Z hlediska softwarového inženýra se při zpracování požadavků jedná o často p
proces „objevování a učení“

·        Je třeba uživatelům vysvětlit, co jsme zjistili aby mohli schválit, že to splňuje jejich potřeby

o   Uživatelé musí rozumět naší specifikaci

·        Leč, uživatel není SW specialistou

Proces zpracování požadavků – přehled

·        Identifikace a pochopení uživatelských potřeb

o   Definice cílů systému

o   Vytvořit kandidáty požadavků

o   Definice systémových omezení

o   Definice hranic systému

·        Zjištění proveditelnosti

o   Ekonomická

o   Technická

o   Operační

o   Organizační dopady

·        Pochopení, zachycení a dokumentace systémových požadavků

o   Statický pohled (persistentní data
(domain model + specifikace)

o   Dynamický (procesy  + omezení)
případy užití + specifikace)

·        Validace požadavků

o   Kritéria pro přijetí kompletního systému uživateli (acceptance tests)

Uživatelské potřeby – identifikace

·        Sběr dat v aplikační doméně

o   Prozkoumání – existující dokumentace

o   Pozorování – pracovní činnosti

o   Rozhovory – dotazníky, osobní

o   Prototypování – rozhraní, funkce

§  Zaměřujeme se na problémy, ne na řešení

§  Rozlišovat potřeb od přání+ hodnotit důležitost potřeb

·        Zpřesnění cílů systému, seznam požadavků, seznam omezení, hranice systému, atd.

·        Návrh rozsah projektu (co je zahrnuto, co nikoliv)

·        Požadavky na specifikaci -à specifikace systémových požadavků (RAD – Requirements Analysis Document)

·        SLOUŽÍ JAKO KONTRAKT MEZI ŘEŠITELI A UŽIVATELI!

Určení proveditelnosti

·        Ekonomická

o   Náklady (vývoj, provozu versus příjmy

·        Technická

o   Dostupnost technologií

o   Riziko nových technologií

·        Operativní

o   Dostupnost sil k provozování systému

o   Úprava pracovník praktit (redesing)

·        Organizační

o   Politika, školení a trénink, přijetí uživateli

·        Právní

o   Ručení a odpovědnost: copyright, patenty

Zachycení a dokumentace systémových požadavků

·        Statické požadavky (persistentní data) – domain model
koncepty a třídy aplikační domény

o   Vznik slovník pojmů (datový slovník) umožňující komunikaci participantů

·        Dynamické požadavky (zpracování + omezení ) à use.case model

Funkční požadavky – popisuje interakce systému s okolím a jeho funkcionalitu (nezávisle na implementaci)

Nefunkční požadavky – požadavky, které nejsou přímo spojeny s funkcionalitou systému, ale přesto ovlivňují jeho chování z pohledu uživatele

          Např. doba odezvy, kapacita, bezpečnost, atd.

Pseudo požadavky – omezení implementace daná zadavatelem

          Např. implementační jazyk, platforma, atd.

                                                                                        SPECIFIKUJE JEN
                                                                                        CO ne, JAK to bude

Artefakty

·        Model domény – třídy a jejich asociace zachycuje datové požadavky

·        Use case model – zachycuje funkční požadavky

·        Uživatelé

·        Slovník

·        Specifikace domény – popis tříd a asociací

·        Specifikace případů užití + scénář

·        Už rozehranní a prototyp

·        Popis architektury

Identifikace tříd

·        Třídami mohou být

o   Obchodní entity (např., objednávky, účty,..)

o   Reální objekty (zákazník,auto,..)

o   Události (rezervace, …)

·        Přirozeně lze s pojmů apl. Domény

o   Classes: podstatná jména( jmenné fráze

o   Asociace: slovesa/ slovesné vazby

·        Vše v jednotném čísle/aktivní formě

Máme správné třídy?

·        Jsou některé třídy redundantní?

·        Nejsou některé třídy irelevantní ve vztahu k aplikační doméně?

·        Nejsou některé třídy vágně/chybně definované?

·        Měly by některé třídy skutečně být ?

·        Nepopisují některé třídy operace?

·        Nepopisují některé třídy role?

·        Nepopisují některé třídy implementační konstrukty?

Identifikování uživatelů

Kdo a jak užívá systém

Jaké role X skupiny se vyskytují

Kdo zadává a poskytuje informace systému

Kdo instaluje, zapíná a vypíná, spravuje systém

Jaké jiné systémy interagují

Stane se něco v čase

                                       Vstupní zařízení nejsou uživateli

                                                                               Čas

                                       Stručně popsat roli, v níž vystupuje.

 

Identifikace scénářů

                    Stejné otázky jako i Use casů

·        Typy

o   As-is

o   Vize

o   Evaluace a testování

o   Trénink

2 přístupy k analýze

1.       Shora-dolů                                    od PU ke scénářů

2.       Zdola-nahoru                               opačně

Scénáře často pro popis chyb a alternativních toků.

Identifikace případů užití

Úlohy vykonávané uživatelem

Jak zpracována actor informace (create, store, change, remove, or read)?

Externí změny

Události o kterých má být uživatel informován

Podpora a správa

                    Názvy: přítomní čas, slovesné fráze in činný rod

V popisu uživat terminologie

                    Extend

                    Include X extend

Nefunkční požadavky

·        výkon

·        spolehlivost a robustnost

·        operační prostředí

·        usability

·        podpora (přízpůsobování, spravovatelnost, přenositelnost)

·        životní cyklus — plán, rozpočet…

·        implementace

·        interface

·        balíčky

·        právní

Validace

·        koreknost

·        úplnost

·        konzistence

·        jednoznačnost

·        reálnost

·        Validační testy + akceptační protokol

 

 

 

 

 

Systémová analýza

Systémová analýza

Cíl: strukturovat model případů užití do formy, která je robustní a spravovatelná během životního cyklu SW.

·        Předpokládáme ideální implementační prostředí

o   Nezohledňujeme: hardware, DBMS, programovací jazyk, atd. to se možná bude měnit

·        Specifikujeme všechny logické třídy v systému, včetně asociací a případně seskupení do balíčků (packages)

·        Distribuujeme chování use.case modelu do tříd analytického modelu

§  Explicitně specifikujeme, která třída je odpovědná za dané chování use-casu

Proč systémová analýza

                    Proč okamžitě neimplementujeme?

Výhody analytického modelu:

·        Přesnější a úplnější specifikace požadavků – odstranění nejednoznační a duplicit

·        Popsána v jazyce vývojáře – formálnější/přesnější

·        Strukturuje požadavky pro lepší porozumění a udržování

·        První přibližní k návrhu

Co dělat s analytickým modelem?

·        Stále udržovat aktuální

·        Po ukončení analýzy zahodit

·        Ani jedna cesta není optimální

USE-CASE MODEL

·        Jazyk zákazníka

·        Externí pohled

·        PU strukturují externí pohled

·        Kontaktn mezi zákazníkem a vývojářem

·        Může obsahovat nejednoznačnosti, duplicity, mezery

·        Zachycuje funkcionalitu systémy

ANALYTICKÝ MODEL

·        Jazyk vývojáře

·        Vnitřní pohled na systém

·        Analytické třídy strukturují vnitřní pohled

·        Užíván vývojáři k pochopení systému

·        Neobsahuje nejednoznačnosti, duplicity, mezery,…

·        Náčrt realizace systému

 

 

 

Výstupy

·        Analytický model – konceptuální strukturovaný model upřesňující požadavky a strukturuje je

·        Popis architektury – globální pohled na systém zohledňující z hlediska architektury důležité prvky

·        Realizace PU-analýza – mapování PU na třídy a jejich interakce

·        Analytické třídy – realizují funkční požadavky, jsou 3 typů:
boundary (hraniční), control (kontrolní/řídící) a entity (entity)

·        Analýza balíčků – organizace tříd do menších skupiny které se lépe spravují

Pracovníci

·        Architekt – architektura, její popis, integrita analytického modelu; zajištuje korektnost, konzistenci, srozumitelnost

·        Use-case inženýr – integrita jedné nebo více realizace případů užití, ručí za to , že budou odpovídat požadavkům

·        Inženýr komponenty – definuje a spravuje odpovědnosti, atributy, vztahy a speciální požadavky jedné nebo více analytických tříd

UP – aktivity

Analýza architektury

– identifikuje: analytické balíčky; evedentní anal. třídy; společné

speciální požadavky

Analýza případů užití

– identifikace anal. tříd

– distribuce chování do anal. tříd

– specifikuje interakce mezi AT

– zachycení speciálních (nefunkčních) požadavků

Analýza tříd

– identifikuje hlavní odpovědnosti tříd (operace)

– …. atributy, vztahy…

– popis netriviálního chování

– zachycení speciálních (nefunkčních) požadavků

Analýza balíčků

– struktura balíčků a vazeb mezi nimi

Činnosti analýzy: od případů užití k objektům

Identifikace analytických objektů

– entity objects

– boundary objects

– control objects

• Mapování objektů na PU pomocí sekvenčních diagramů

• Modelování interakcí pomocí CRC žtítků

• Identifikace

– asociací

– agregací

– atributů

• Modelování chování individuálních objektů

• Modelování vztahů dědičnosti

• Revize a kontrola analytického modelu

Analytické třídy

Abstrakce jedné nebo více finálních tříd

implementujících systém

• popisy jsou konceptuální, nikoliv implementační

atributy: konceptuální, ne konkrétní jazyk

chování: definováno textovými popisy odpovědností

vztahy: konceptuální

• třídy jsou:

– boundary – entity – control

(návrh obsahuje obyčejně mnohem víc tříd — až 5x…)

 zaměřují se jen na funkční požadavky

 

Principy dělení případů užití

Každý use-case rozdělen až na úroveň:

1. boundary tříd funkcionality přímo související s okolím systému

2. entity tříd  ukládání a správa dat a informací

3. control třídypropojení mezi 1. a 2., tok dat, řízení atd.

Cíl: lokalizace změn tak aby výsledkem byl stabilní systém

V praxi mnoho rozhodnutí, kam jaké funkce umístit

Analýza tříd

•                 Identifikace odpovědností

– z rolí v PU

 zvažuj: diagramy tříd, sekvenční, toky událostí

·        Identifikace atributů

boundary třídy

entity třídy

kontrolní třídy
jen zřídka mají atributy

Identifikace asociací, agregací, generalizací

– ze vztahů, zpráv, sekvenčních diagramů

– ze sdílených chování mezi analytickými třídami

CRC štítky — CLASSES, RESPONSIBILITIES,COLLABORATIONS

 

 

 

Balíčky

 

 

Revize analýzy

·        Je vhodné na konci analýzy provést

·        Kritéria

o   Korektnost

o   Úplnost

o   Konzistence

Návrh systému

Návrh – úvod

Přizpůsobování logické struktury analytického modelu na implementační prostředí a příprava na implementace.

·        Zvaž vliv nefunkčního požadavků

·        Zahrň globální požadavky na systém

·        Zvaž implementační prostředí

·        Plně specifikuj každou třídu včetně všech vlastností a operací

·        Rozděl implementační práce do zvládnutelných celků à subsystémy

·        Specifikuj hlavní rozhraní (interface) mezi subsystémy.

Kdy se začít věnovat systémovému designu?

·        Až se ustálí analytický model a je požadováno jen minimum změn

Analytický model

·        Konceptuální model

·        Design à obecný

·        Méně formální

·        Levnější vývoj

·        Méně vrstev

·        Zaměření na interakce

·        Nástin návrhu

·        Nemusí být nutně dále udržován, spravován

Model návrhu

·        Fyzický model

·        Implementace à specifický

·        Více formální

·        Dražší vývoj

·        Více vrstev

·        Zaměření na sekvence

·        Implementace návrhu

·        Udržován a spravován v rámci životního cyklu

Cíle návrhu

Nač se zaměřit (vlastnosti) a co optimalizovat?

Ø  Vlastnosti odvozeny hlavně s nefunkčních požadavků

Ø  Vybrané vlastnosti (cíle) ovlivňují rozhodnutí učiněná během návrhu (zejména jeli třeba dělat kompromisy).

Ø  Obyčejně lze najednou zahrnout jen malou podmnožinu nefunkčních požadavků (jsou často v rozporu)

Ø  Potřeba priorit dílů návrhu

Ø  Příklad: prostor vs. Rychlost; doba vývoje vs. Kvalita, kvalita vs. Cena

Aktivity návrhu

·        Identifikace cílů návrhu

o   Identifikace

o   Přiřazení priorit

o   Dle cílů se optimalizuje

·        Návrh základní dekompozice na podsystém

o   Rozklad na podsystémy

o   Na základě případů užití a analytického modelu

·        Zpřesnění návrh podsystémů

o   Musí se zaměřovat na podporování cílů návrhu

Návrh z hlediska UP

Výstupy a pracovníci

Výstupy

·        Model návrhu – popis fyzické realizace PU; zaměření na funkční i nef. Požadavky, společně s omezením impl. Prostředí

·        Model nasazení – popis fyzické distribuce systému na jednotlivý HW uzly

·        Popis architektury – 2 pohledy na arch. – návrh a nasazení.

·        Realizace PU – návrh – popis realizace PU v pojmech návrhových tříd a objektů

·        Návrh tříd – abstrakce tříd ve vztahu k implementaci systému

o   Již v daném programovacím jazyce.

·        Návrh subsystémů – distribuce komponent da částí

·        Interface – specifikace operací tříd a subsystémů

o   Oddělení rozhraní od implementace

Identifikace dílů – příklady cílů dle různých kritérií

Výkon-

·        Doba odezvy

·        Kapacita

·        Paměť

Spolehlivost-

·        Robustnost

·        Spolehlivost

·        Dostupnost

·        Odolnost vůči chybám

·        Zabezpečení

·        Bezpečnost (neohrozeni)

Uživatelské cíle

·        Užitek

·        Použitelnost

Údržba a spravovatelnost

·        Rozšířitelnost

·        Modifikovatelnost

·        Adaptabilita

·        Portabilita

·        Srozumitelnost

Náklady

·        Vývoje

·        Zavádění

·        Upgrady

·        Údržba

·        Správa

Návrh subsystémů

Název subsystému

Subsystém slouží j rozdělení komponent návrhového modelu do lépe zvládnutelných částí

·        Může obsahovat:

o   Návrhové třídy

o   Jiné subsystémy

o   Realizace use-casů

o   Interface

·        Use case, lze navrhnout jako spolupráci subsystémů

o   Třídový diagram subsystémů

·        Lze je využít v diagramech spolupráce

o   Umožňuje hierarchickou dekompozici

·        Mohou být zpřesněním balíčků nebo přímo součástí návrhového workflow

Heuristicky pro seskupování do subsystémů

·        Objekty z téhož P“ do jednoho subsystému

·        Vytvoř speciální subsystém odpovědný za výměnu dat mezi podsystémy

·        Minimalizuj počet asociací mezi subsystémy

·        Všechny třídy podsystému by měly být funkčně podobné/spřízněné

Návrh subsystémů – vrstvy a členění (partitions)

·        Rekurzivní dělení systému na subsystémy vede k hierarchii subsystémů či vrstev

·        Každá vrstva (subs.) poskytuje vyšší úrovně a využívá služeb nižších vrstev

·        Varianty vrstvené architektury:

o   Uzavřené vrstvy-každá vrstva závisí jen na bezprostředně nižší vrstvě à nižší provázanost (větší režie)

o   Otevřená vrstvená arch.: vrstva může závisle na libovolné nižší vrstvě – větší provázanost (nižší režie)

·        Členění subsystému na menší celky:

o   Dělí služby v 1 vrstvě do dílčích subsystémů

o   Výsledky je peer to peer členění (uvnitř vrstvy)

Vrstvy a jejich členění – příklad

 

SW architektury

·        Rozložení do podsystémů je kritická operace

·        Špatně navržené rozdělení se špatně modifikuje

·        Proto vzniklo několik SW architektur

·        Architektura zahrnuje:

o   Dekompozici systému

o   Řízení toku

o   Komunikační protokoly

o   Vymezení hraničních podmínek

Repository

·        Základem je sdílená datová struktura – REPOSITORY

·        Subsystémy nezávisle interagují s Repository

·        Př. Databáze, bankovní systémy

·        + sdílení dat (centrální), údržba

·        - úzké hrdlo

REPOSITORY – PŘÍKLAD

 

 

MODEL/VIEW/CONTROLLER

·        Model – modeluje doménovou oblast (viz. Analýza a entity třídy)

·        View – pohledy na model

·        Controller – propojení modelu s uživateli, řízené toku

·        + vhodné na interaktivní systémy

KLIENT/SERVER

·        Server – poskytuje služby

·        Klient – využívá služby

·        + vhodné pro distribuované systémy

PEER-TO-PEER

·        Zobecnění klient/server

·        Peer vystupuje v obou rolích – poskytovatel i klient

·        Operace zpětného volání – CALLBACK

TŘÍ-VRSTVÁ,ČTYŘ-VRSTVÁ ARCHITELTURA

·        Častá realizace vícevrstvé architektury

·        Odděluje

o   Ukládání dat,

o   Aplikační logiku,

o   Prezentační vrstvy

 

 

PIPE & FILTER ARCHITEKTURA

·        Každá komponenta definuje formát

o   Vstupy a

o   výstupu

·        Komponenty lze propojovat do front (pipe)

·        Příklad: příkazy v UNIXU

Zpřesnění návrhu naplňování cílů

Aktivity zpřesňování návrhu

·        Výběr hotových komponent a podsystémů

o   Jsou levnější než na míru vytvářený SW

o   Dekompozice je mnohdy potřeba uzpůsobit těmto komponentám

·        Mapování podsystémů na hardware

·        Návrh infrastruktury zpracování persistentních dat

o   Definice storage-systémů a principů

o   Db, objektová db, soubory

·        Specifikace politik přístupových práv

o   Globální access list, table

·        Návrh globálního řízení toku

o   Posloupnosti řízení

·        Specifikace mezních situací

o   Zapínání/vypínání systémy, restarty

o   Zpracování výjimečných stavů

DEPLOYMENT MODEL (model nasazení)

Jméno uzlu

Distribuce komponent na HW uzlu

Diagram nasazení zobrazuje:

·        Uzly: hw zařízení a výpočetní zdroje

·        Vztahy: komunikace mezi uzly

·        Otázky:

o   Kolik a jaké uzly, jaký mají výkon, paměť, ….

o   Propojení, komunikační protokoly,….

o   Vlastností propojení – šířka pásma, dostupnost, kvalita,….

o   Redundance, spolehlivost

DEPLOYMENT – PŘÍKLAD 1

DEPLOYMENT – PŘÍKLAD 2

Další témata zpřesňování návrhu

Management dat – jak jsou zpracována perzistentní data?

                    Soubory? Relační DBMS?                            Objektově orientovaná DBMS?

Kontrola přístupu – jak se specifikována a realizována kontrola přístupu?

                    Globální tabulka práv?                                seznam práv?                               schopnost?

Řízení toku – jak je inicializováno a zpracováváno řízení toku?

                    Procedurální?                              Událostní model?   Vlákna?

Mezní podmínky – jak je řešeno zapínání a vypínání systému a výjimečné stavy?

·        Specifikování systémových administrátorských use-casů pro zapínání a vypínání systému

·        Specifikování mechanismů ošetřování výjimek pro chybové stavy

Implementační prostředí

Potřeba specifikovat technické a organizační omezení na jejichž základě bude systém vybudován

·        Na jakém hardwaru/software systém poběží?

o   Hardware (a jeho omezení)

o   Distribuce SW a HW

o   Systémový SW

·        Jaký programovací jazyk bude použit?

o   Objektově orientovaný, ne OO

o   Správa paměti

·        Jaký existující SW je potřeba použít?

o   DBMS

o   UIMS

o   Síťový SW

o   Aplikační SW, Framework

·        Jací vývojoví pracovníci/organizace se zapojí do vývoje?

o   Distribuovaná pracoviště

o   Týmové kompetence

Návrh tříd – doména řešení

Pro hraniční třídy musíme zvážit

– specifické technologie uživatelského rozhranní

Pro třídy entit musíme zvážit

– specifické technologie správy dat

• návrhové třídy zapouzdřující relační databáze

U kontrolních tříd je třeba zvážit

otázky distribuce –> potřebujeme samostatnou návrhovou třídu na

každém uzlu?

výkonnostní otázky –> nevyplatí se sloučit některé hraniční/entity třídy?

transakční otázky –> je potřeba zahrnout technologii správy transakcí?

Návrh tříd

Návrhové třídy jsou takové třídy, jejichž specifikace je natolik kompletní, že mohou být implementovány.

• návrhové třídy získáváme ze dvou zdrojů:

1. problémová doména

• zpřesnění analytických tříd přidáním implementačních detailů

• analytickou třídu může být potřeba rozdělit do více tříd, které ji budou implementovat

2. doména řešení

• třídy z knihoven, znovupoužitelné komponenty, komponentové rámce (DCOM, CORBA, Enterprise JavaBeans, atd.)

• poskytuje technické nástroje pro řežení systému

Návrh tříd — AKTIVITY

dokončení specifikace identifikováním/definováním:

chybějících atributů, asociací, operací

• ne vžechny zprávy se stanou operacemi (např. účastníci, hraniční třídy)

• ne vžechny operace se objevují v diagramech aktivit

typové signatury a viditelnost atributů a operací

omezení operací –> invarianty; vstupní a výstupní podmínky

výjimky a výjimečné stavy –> hodnoty, které by neměly operace přijímat

výběr znovupoužitelných komponent zahrnuje identifikaci a adaptování:

knihoven –> konverzní/“propojovací” třídy a operace (někdy je jich potřeba k propojení a úpravám chování knihovny)

obecné návrhové mechanismy k vyřežení nefunkčních požadavků

• perzistence; distribuce objektů; bezpečnost; správa transakcí; ožetření chyb, atd.

Návrh tříd — AKTIVITY (pokračování)

restrukturování modelu návrhu

realizace asociací –> často realizované jako proměnné reprezentující reference (resp. ukazatele) na objekty

• zpřesnění násobností, názvy rolí, asociační třídy, kvalifikované role, orientace asociací; zvážení možností programovacího jazyka

zvýžení znovupoužitelnosti pomocí dědičnosti a delegování

optimalizace modelu návrhu

revize přístupových cest s cílem zrychlit přístup k metodám či datům (je možno přidat nové asociace)

spojení tříd –> třídy s malým počtem atributů a jednoduchým chováním

cachování náročných výpočtů –> používání odvozených atributů

odložení drahých výpočtů –> např. zobrazování obrázků, …

Popsáno syntaxí programovacího jazyka.

Vlastnosti dobře navržených tříd návrhu

úplnost

 třída by měla dělat, co od ní uživatel očekává ani méně ani více

„primitivnost“

 třída by měla vždy zpřístupňovat nejjednodužží a nejmenží možnou množinu operací

vysoká soudržnost

 třída by měla modelovat jeden abstraktní koncept a měla by mít operace, které podporují záměr, pro který byla vytvořena

nízká provázanost

 třída by měla být asociována jen a pouze s třídami které jí umožňují realizovat její odpovědnosti

 

Implementace systému

Účel implementace

Převedení návrhu na funkční (vykonatelný) kód.

·        Workflow implementace implementuje systém pomocí komponenty jako:

o   Zdrojový kód

o   Skripty

o   Binární soubory

o   Dávky, atp.

·        Je potřeba:

o   implementovat návrhové třídy a subsystémy z fáze návrhu

o   plánovat integraci systému požadovanou při každé iteraci vývoje

o   integrovat třídy a subsystémy zkompilováním a slinkováním do 1 vykonatelné komponenty

o   distribuovat komponenty na uzly deployment modelu

IMPLEMENTACE – ROLE ŽIVOTNÍHO CYKLU

·        jádrem je fáze konstrukce

·        vykonávána také během:

o   rozpracování: základní skelet architektury

o   zavedení: ošetření pozdních chyb a problémů

·        model implementace je udržován po celou dobu životního cyklu

VÝSTUPY IMPLEMENTACE

model implementace – popisuje

– způsob implementace modelu pomocí komponent jako soubory se zdr. kódem, dávky, binární soubory, …

– organizaci, strukturu komponent, modularizační mechanismy v implementačním prostředí, programovací jazyk(y)

– závislosti komponent

implementační model je často meziproduktem vzniku zdrojového kódu spíše než samostatnou explicitní aktivitou

expl. modelovací aktivita se děje jestliže:

– kód je generován přímo z modelu  potřeba specifikovat detaily jako komponenty, zdrojové soubory atp.

– jsou-li používány existující komponenty (component based developement

- CBD)  alokace návrhových tříd a rozhranní ke komponentám se stává klíčovým tématem.

VÝSTUPY IMPLEMENTACE – POKRAČOVÁNÍ

·        komponenta – fyzický balík elementů návrhového modelu – návrh. třídy

 komponenta může implementovat více návrhových elementů

implementace subsystémů – rozdělení implementace do více zvládnutelných celků

interface – totéž jako v modelu návrhu

popis architektury – subsystémy, rozhranní, závislosti a klíčové komponenty modelu implementace

plán integrace – plán konstrukce systému – měl by být inkrementální

LIDÉ

·        architektura – odpovědná za

o   integritu modelu

o   základní mapování

o   architekturu

·        integrátor – plánuje buildy, iterace, integraci částí systému

·        inženýr komponent – definuje a spravuje zdrojové kódy, soubory, komponenty a integritu subsystémů

Komponenty

 

 

IMPLEMENTACE TŘÍD

Přířazení návrhových tříd komponentám souborů

– zdrojový kód je v komponentě souboru

– rozsah komponenty souboru které návrhové třídy zahrnout

 Rozvržení do souborů závisí na programovacím jazyku a jeho schopnostech.

Generování zdrojového kódu z návrhu

– cílem je pro každou operaci generovat impl. metodu

– je třeba zvolit vhodný algoritmus a vhodné datové struktury

generováno na základě: toku událostí, diagramů aktivit, stavových diagramů, diagramu tříd…

Od návrhu k implementace — OO jazyky

MODEL DO PRG. JAZYKA Z NÁVRHU

Analytický model

Analytická třída

Chování třídy

Atribut (třídy)

Atribut (instance)

Zpráva

Diagram spolupráce

Balíček

Model návrhu

Třída návrhová

Operace

Atribut (třídy)

Atribut (instance)

Zpráva

Sekvenční diagram

Subsystém

C++ zdrojový kód

C++ třída

Členské funkce

Statická proměnná

Proměnná instance

Volání metody třídy

Sekvence volání

Soubory

IMPLEMENTACE SUBSYSTÉMU

·        Organizuje výstupy implementace do lépe zvládnutelných celků

o   Může se skládat z komponent, rozhraní a jiných subsystémů

§  Každý subs. Návrhu je implementován jedním impl. Subs. (vztah 1:1)

§  Každý impl. Subs. je obvykle implementován jako komponenta

·        Potřebujeme „balíčkovací mechanismus“ v prg. Jazyce

o   Příklad:

·        Packegae v Javě

·        Project ve Visual Basicu

·        Adresář souborů v C++

INTEGRACE SYSTÉMU

Sestavení (build):   implementace části funkcionality systému

·        Každý build má kontrolu verzí

o   Umožňuje návrat k předchozí verzi

·        Každá iterace živ. Cyklu ve fázi konstrukce odpovídá nejméně 2 sestavení (obvykle však více)

Plán integrace sestavení:        sekvence požadovaných builu v rámci iterace

·        Specifikuje funkcionality (případy užití/scénaře), které mají být implementovány, subsystémy a komponenty realizující tyto funkcionality.

Obvykle postupuje proces od spodních vrstev a rozšiřuje de do vyšších vrstev (u vrstevnaté architektury).

ZAVÁDĚNÍ (NASAZENÍ) KOMPONENT

SHRNUTÍ

Model implementace obsahuje:

Implementaci subsystémů a jejich závislosti, interface a obsah

Komponenty a jejich závislosti

Mapování vykonatelných komponent na uzly v modelu nasazení

Architektura implementačního modelu

Testování

Úvod: Co to je testování

Proces hledání rozdílů mezi specifikovaným (očekávaným) a pozorovaným (skutečným) chováním systémů.

·        Obyčejně realizováno vývojáři, kteří se nepodíleli na implementaci

·        Ke kvalitnímu otestování systému je nutné systému dobře rozumět a mít dostatek zkušeností

§  Nejedná se o práci pro začátečníky

Cíl: navrhnout testy, které budou systematicky nacházet, chyby Cílem je přimět systém k selhání.

POZNATKY O TESTOVÁNÍ

·        Testování neumí prokázat absenci chyb, ale pouze chyby nalézat!

·        Není možné kompletně otestovat netriviální systém. (většina SW má nutně chyby).

·        Testování je destruktivní aktivita.

·        Tzn., kvalitní testování je opačné povahy proti kvatlinímu SW inženýrství

TESTOVÁNÍ – ZÁKLADNÍ POJMY

·        Spolehlivost – měří schopnost chování systému dle specifikace

·        Spolehlivost SW – pravděpodobnost, že SW systém nezpůsobí po stanovenou dobu a ve stanovených podmínkách selhání systému.

·        Selhání – odchylka systému, po němž chování od očekávaného chování.

·        Chybový stav – stav systému, po němž následuje selhání systému (manifestace závady).

·        Závada (chyba, bug, defekt) – chyba v návrhu nebo v kódu systému, která může způsobit abnormální chování systému.

TESTOVÁNÍ – VERIFIKACE A VALIDACE

·        VERIFIKACE je proces ověřování, zda jsme vytvořili produkt správně (tzn. splňující stanované požadavky).

·        VALIDACE je proces ověřování, zda jsme vytvořili správný produkt (tzn. naplňující daný účel).

o   Validací se zabývají hlavně akceptační testy

·        Testování verifikuje výsledky implementace prostřednictvím testování každého sestavení (build) a finální verze systému

o   Plánování testů je nutné v každé iteraci

o   Návrh a implementace testu zahrnuje

§  Test. Případy specifikujícíc co testovat

§  Test. Procedury specifikující jak otestovat

§  Testovací komponenty sloužící k automatizace testů

VÝSTUPY A PRACOVNÍCI

·        Model testů – soubor test. Případů, procedur a testovacích komponent popisující způsob testování systému.

·        Testovací případ – specifikuje způsob realizace jednoho testu

o   Co testovat, vstupy, očekávané výstupy, podmínky realizace

·        Testovací procedura – definuje realizace jednoho nebo více testů

·        Plán testů – popisuje test. Strategie, zdroje a harmonogramy

·        Vyhodnocení testu – výsledek testovací úsilí

·        Testovací komponenta – automatizuje jednu nebo více testovacích procedur a jejich částí (někdy se nazývá řadič/ovládač/driver testu).

·        Defekt – anomálie systému (např. chyba v programu – bug)

PLÁN TESTŮ

Cíl:             navrhnout sadu testů, která maximalizuje pravděpodobnost odhalení chyb a minimalizuje čas a úsilí.

Proč?        Testování stojí čas a peníze (mnohdy až 40% úsilí bývá věnováno testování).

Strategie testování: specifikuje kritéria a cíle testována

·        Jaké testy a jak?

·        Míra pokrytí testy (úplnost)

·        Síla testů (Kdy skončíme? Požadována míra spolehlivosti).

Odhad potřebných zdrojů: lidských/systémových

Rozvrh testů: kdy který test spustit

NÁVRH TESTŮ

Definuje testovací případy

Testy typu bílá skřínka (White box): „testování v malém“

Verifikace logiky založena na práci se strukturou systému a datovými strukturami à Musí být dostupný zdrojový kód.

                    (testy vycházejí ze znalosti vnitřního fungování systému/komponenty.)

Testy typu černá skřínka (Black Box): „testováním ve velkém“

Verifikování fungování komponent na základě vstupů a výstupů
à Zdrojový k=od není nutný!

Regresní (zpětné) testy : selektivní opětovném testování s cílem ověření, že nebyla opravou (úpravami) zavlečena nová chyba.

TESTY TYPU BÍLÁ SKŘÍŇKA – ÚVOD

Cíl:              zajistit, že jsme vykonali/prověřili všechny:

·        Nezávislé cesty kódem aspoň jednou

·        Logická rozhodnutí podle jejich pravdivostních hodnot

·        Cykly uvnitř a včetně hraničních podmínek

·        Interní datové struktury a jejich validitu

Proč je to důležité?

·        Logické chyby a chybné předpoklady jsou nepřímo úměrné pravděpodobnosti průchodu danou cestou v kódu

o   Více chyb v méně používaných částech kódu

·        Věříme často, že průchod danou cestou je nepravděpodobný

o   Realita je často neintuitivní

·        Překlepy jsou náhodné

o   Netestované cesty pravděpodobně nějaké obsahují

TESTY TYPU BÍLÁ SKŘÍŇKA – PŘEHLED

Můžeme používat následující metody:

1.       Test průchodem cest  -                                alespoň jednou projít každou nezávislou cestou

2.       Test podmínek -                          použít každou podmínek s výsledkem true i false

3.       Test cyklů -                                                       vykonat každý cyklus uvnitř i v jeho krajních podmínek

4.       Test datových toků -                                     použít všechny datové struktury a prověřit tak jejich validitu

TEST PRŮCHODEM NEZÁVISLÝCH CEST

Cíl: alespoň jednou projít každou nezávislou cestou

1.       Analýza kódu a vytvoření diagramu dat. Toků.
(pomůckou může být nakreslení diagramu aktivit.)

2.       Určení složitosti cyklů v daném kódu

3.       Stanovení základní množiny lineárně nezávislých cest.

4.       Příprava testovacích případů, které při vykonání vynutí průchodem danými cestami.

Pozor: netestují se všechny možné kombinaci cest. Chceme zajistit pouze průchod každou cestou alespoň jednou.

TEST PRŮCHODEM NEZÁVISLÝCH CEST – 1

 

 

TESTY TYPU ČERNÉ SKŘÍNKY

Cílem je zjistit/najít:

·        Nekorektní nebo chybějící funkce

·        Chyby nekompability rozhraní

·        Chyby dat. Struktur nebo chyby přístup k DB

·        Výkonnostní chyby

·        Inicializační a koncové chyby

Testovací případy by měly:

·        Snížit alespoň o 1 počet jiných potřebných tes. Případů

·        Vypovědět něco o (ne)přítomnosti určité třídy chyb
(např. všechny vstupy v podobě charu jsou zpracovány správně)

Rozdělení na třídy ekvivalence

Rozdělení vstupů a výstupů do skupin tak, abychom pokryli všechna data a třídy chyb.

JINÉ TECHNIKY TYPU ČERNÁ SKŘÍNKA

Odhad chyb

·        Volba testovacích hodnot na základě znalostí a zkušeností

Grafy příčin a následků

·        Identifikace příčin (vstupní podmínky) a důsledků (akce) subsystému

·        Nakreslení grafu

·        Převod grafu na rozhodovací tabulku

·        Pravidla tabulky jsou převedeny na test. Případy

Srovnávací testování

·        V případě vysoké důležitosti se může vyplatit nasazení duplicitních komponent (SW, HW, verze SW)

·        Stejná data jsou zpracována různými systémy paralelně a vzájemně kontrolována

POZOR:                        v případě chybné specifikace duplicity nepomůžou

DOKUMENTACE TEST. PŘÍPADU

Název  - jednoznačné jméno k identifikaci

Popis testu – co má test ověřovat

Cílová třída/komponent/subsystém – název testované entity

Testovaná operace – název testované operace

Typ testu – black box; validní/nevalidní vstupy

Testovací hodnoty – vstupy testu

Verifikace  - očekávané výsledky

TESTOVACÍ STRATEGIE

INTEGRAČNÍ TESTOVÁNÍ

Proč, integrační testy, když komponenty fungují?

Chyby interakcí nelze odhalit testovacím jednotek?
(např. špatně použité rozhranní, načasování,…)

Přístupy

PŘÍSTUP SHORA-DOLŮ (ROP-DOWN)

 

 

SYSTÉMOVÉ TESTOVÁNÍ

Testování systému jako celku.

Specifické typy testů

Funkční – vývojáři verifikují, že všechny uživatelské fce fungují dle specifikace systémových požadavků

Výkonnostní – vývojáři ověřují, zda jsou splněny nefunkční požadavky

Pilotní – vybraná skupiny uživatelů ověřuje běžnou funkcionalitu systému v cílovém prostředí

Akceptační – zákazník ověřuje použitelnost, funkční a nefunkční požadavky dle specifikace systémových požadavků

Instalační – zákazník ověřuje použitelnost, funkční a nefunkční požadavky v reálném použití

TESTOVÁNÍ VÝKONNOSTI

testování „stresu“  ověření funkčnosti systému v případě mnoha současných požadavků

 Kolik systém „ustojí“? Zkolabuje systém nebo skončí korektně?

objemové testy  ověření schopnosti systému zvládat velké objemy dat, náročné algoritmy, nebo velkou fragmentaci disku

bezpečnostní testy  ověření funkčnosti kontrolních a bezpečnostních mechanismů

 cena průniku do systému by měla být vyšší než hodnota dat

testy rychlosti  ověření schopnosti systému splňovat časová omezení

 obvykle pro real-time a embedded systémy

testy zotavení  ověření schopnosti systému zotavit se po selhání

 zotavení je důležité zejména u databázových systémů

AKCEPTAČNÍ TESTOVÁNÍ

Proces zajištující, že systém odpovídá rozumným uživatelským požadavkům a očekávání

·        Může být velice subjektivní – kvalitní specifikace požadavků je důležitá již v ranních fázích projektu.

·        Metoda řešení nedostatků by měla být stanovena ještě před fází zavedení

·        Akceptační testy (black box) pokrývají následující oblasti:

o   Funkcionalita

o   Výkon

o   Dokumentace

o   Spolehlivost

·        Revize konfigurace (audit)

o   Zajišťuje, že byly všechny SW komponenty dodány zákazníkovy (SW konfigurace) správně vyvinuty a zdokumentovány.

VYHODNOCENÍ TESTŮ

·        Je třeba

o   Vyhodnotiti výsledky provedených testů

o   Porovnat výsledky s cíli dle testovacího plánu

o   Připravit metriky, které umožní testovacím inženýrům stanovit aktuální kvalitu SW

·        Jak poznáme, kdy skončit s testováním?

·        Možno zvážit:

o   Úplnost testů: % provedených test. Případů a % testovaného kódu

o   Spolehlivost: porovnání s mírou chybovosti u předchozích projektů (zmenšování v čase)

TESTOVÁNÍ VE STRESU

VŠECHNY TESTY JSOU DŮLEŽITÉ, ALE MNOHDY JE POTŘEBA TESTOVAT JEN OMEZENĚ

·        Testování schopností systému (funkcionality) je důležitější než testování komponent

o   Identifikuj funkce, které znemožní uživatelům provádět jejich práci (kritické funkce)

·        Testování starých funkcionalit je důležitější než testování nových funkcionalit

o   Uživatelé očekávají, že existující funkcionalita bude nadále fungovat!

·        Testování typických situací je důležitější než testování mezních případů

o   Obvykle scénáře použití jsou důležitější než atypické a méně obvyklé scénáře.

SHRNUTÍ

·        Je třeba dobře plánovat

o   Musíme vědět, co a proč testujeme

·        Použití adekvátních testů

o   White box, black box, regresní testy

·        Systematičnost a důkladnost se vyplácí!

o   Jednotkové, integrační, systémové, akceptační testy

·        Dopředu se rozhodnout, kolik testování bude prováděno.

o   Definice jasného stop-kritéria