Projekty, testování a metodiky vývoje

64. hodina MVOP WBF

Matěj Cajthaml — SSPŠ

©

Opakování návrhových vzorů

  • co je to návrhový vzor?
  • k čemu návrhové vzory používáme?
  • co je to refactoring?
  • jaké kategorie návrhových vzorů známe?
  • jaké jsou základní návrhové vzory?

Projekty

  • správa účastníků
  • správa požadavků a problémů (issues)
  • správa souborů (git)

UML

  • Unified Modeling Language
  • standardní jazyk pro modelování
  • používá se pro analýzu, návrh, dokumentaci a komunikaci
  • online nástroje: draw.io, plantuml.com, lucidchart.com
  • offline nástroje: StarUML, Visual Paradigm, Enterprise Architect

Analýza

  • proces před vývojem
  • zjištění, co je cílem systému
  • zjištění požadavků, které musí být splněny
  • zjištění důležitých funkcí a částí systému
  • často celá pozice v týmu
  • často vývojáři nejsou zapojeni

Diagram aktivit

  • popisuje jak jsou různé akce prováděny
  • zůčastněné entity — swimlines
  • prvky:
    • začátek a konec
    • akce
    • rozhodování
    • spojení mezi prvky
    • stav entity
    • počkání

Diagram objednávky

Práce

Navrhněte diagram aktivity pro objednáku produktů na internetovém obchodě až do předání zákazníkovi.

Požadavky

Požadavky jsou základním stavebním kamenem každého projektu. Co se ale požadavky myslí? Jaké existují?

Sběr požadavků

  • součást analýzy
  • zjištění požadavků od zákazníka

Požadavky

  • co systém musí umět
  • co systém musí splňovat
  • co nejvíce konkrétní
  • dělí se na funkční a nefunkční

Funkční požadavky

  • určují jednotlivé funkcionality
  • např. správa knih, přihlášení

Nefunkční požadavky

  • určují jak systém bude fungovat
  • např. rychlost, bezpečnost, přístupnost

Jak se vám líbí definice výše uvedených požadavků?

Správné požadavky

  • konkrétní — co, kdy, kde, proč
  • priorita — jak moc je důležitý
  • složitost — jak moc je složitý

Pozor na vágní požadavky. Např.: systém bude rychlý, systém bude bezpečný, systém bude přístupný, ...

Požadavky

Práce

Zkuste vytvořit požadavky na e-shop pro prodej elektroniky.

Případy užití

Případy užití

  • popisují, jak bude systém používán
  • rozvinují funkční požadavky

  • uživatelská příručka
  • podklady pro tvorbu testů
  • zadání pro programátora

Případ užití

  • aktéry — případné vazby
  • případy užití
  • referují na funkční požadavky

UC1 — Zveřejnění úkolu

Učitel může při zadání úkolu zvolit, kdy bude úkol zveřejněn studentům. Po tomto čase bude úkol viditelný studentům a odešle se upozornění na e-mail.

UC2 — Přihlášení

Hlavní scénář

  1. Uživatel otevře webovou stránku a není přihlášen.
  2. Uživatel zadá uživatelské jméno a heslo.
  3. Uživatel je přihlášen.

UC2 — Přihlášení

Vedlejší scénář

  1. Uživatel otevře webovou stránku a není přihlášen.
  2. Uživatel zadá uživatelské jméno a heslo.
  3. Uživatel má aktivní dvoufázové ověřování.
  4. Uživatelovi je zaslán ověřovací kód.
  5. Uživatel zadá ověřovací kód.
  6. Uživatel je přihlášen.

Co když je scénář příliš dlouhý a nečitelný?

Diagram případu užití není průchod použitím systému.

Každý případ užití popisuje jednu akci. Akce je závislá na určitých funkčních požadavcích.

Matice pokrytí

  • zobrazuje, jaké případy užití jsou pokryté jednotlivými funkcemi
  • pokud nemá případ užití žádný funkční požadavek, je to chyba
  • pokud nemá nějaký funkční požadavek žádný případ užití, je to chyba
  • pokud nemá případ užití žádného aktéra, je to chyba

Ukázková matice pokrytí

(nereálné data)

F1 F2 F3 F4
UC1
UC2
UC3

Doménový model

Doménový model

  • popis dat
  • popis vztahů mezi daty
  • popis významu termínů
  • základ pro návrh
  • nereprezentuje třídy a ani databázi

Kardinality

  • 1:1
  • 1:N
  • N:M
  • povinnost vztahu

Další diagramy analýzy

  • stav entity
  • balíčky

Návrh

Návrh

  • architektura
  • vybrání technologií
  • výběr uložení dat
  • popis komponent, integrace

Co je to programovací paradigma?

Jaký jazyk vybrat pro tvorbu projektu?

Výběr jazyka

  • záleží na týmu
  • analýza potřebných knihoven a frameworků
  • přenositelnost
  • vývojové prostředí
  • operační systém
  • nárok na hostitelský server

Databáze

  • relační databáze
  • dokumentové databáze
  • objektové databáze

Databázový model

  • inspiruje se doménovým modelem
  • zobrazuje vztahy mezi tabulkami
  • zobrazuje primární a cizí klíče
  • určujeme datové typy a vše, co již závisí na DB

Databázový model

Práce

Zkuste si vytvořit databázový model pro doménový model z minulého cvičení.

Architektura

  • logická:
    • určení rozdělení aplikace
    • určení vrstvev (viz. minulé hodiny)
  • fyzická:
    • určení rozdělení na servery
    • např. tenký klient, tlustý klient, cluster

Cílem architektury je vytvořit srozumitelný, rozšiřitelný a udržovatelný systém.

Jak na architekturu

  • každá část má svojí zodpovědnost
  • neexistuje např. třída, co dělá dvě věci
  • určit nestabilní místa, kde by bylo složité aplikaci rozšiřovat
  • abstrakce
  • diagramy tříd

Další diagramy návrhu

  • diagramy tříd

Sekvenční diagramy

Sekvenční diagramy

  • zobrazují postup výpočtu
  • zobrazují postup zpracování požadavku
  • zobrazují postup zpracování dat
  • kde se co vrací, při jakých podmínkách
  • poslední část návrhu

Sekvenční diagramy

Práce

Zkuste si vytvořit sekvenční diagram pro validaci toho, zda student splňuje požadavky na klasifikaci.

Implementace

  • práce — to co jsme dělali doposud
  • rozdělování tříd a metod
  • omezit opakování
  • používat návrhové vzory

Testování

Testování

  • automatické testování
  • testování lidmi

Jaké jsou cíle testování?

Automatické testování nemůže prokázat, že je software bez chyb. Jakto?

Typy testů

  • jednotkové
  • komponentové
  • integrační
  • systémové

Typy testů dle způsobu provedení

  • statické
  • dynamické

Typy testů dle struktury

  • white box
  • black box
  • gray box

Jednotkové testy

  • testuje se pouze jedna třída
  • white box
  • různé knihovny: Jest, Mocha, ...
  • zjistí, že se třída chová jinak, než by měla

Fáze testování

  • začátek
  • před testem
  • po testu
  • konec

Velmi často se používají asserts. Co to je?

Mock

Práce

Zjistěte, co jsou to tzv. Mock objekty a jak se používají. Proč a kdy se používají?

Komponentové testy

  • testuje se jedna komponenta - více tříd
  • typicky white box
  • zaměření na komunikaci mezi třídami

Integrační testy

  • testuje se více komponent
  • simulace reálného prostředí
  • připojení k DB, kontejnery, ...

  • black box: komunikace s jinými dodavateli, knihovnami
  • white box: komunikace s vlastními komponentami

Integrační testy mají problém s návratem do stavu před testem. Jak to řešit?

Systémové testy

  • testuje se celý systém
  • testuje se chování systému
  • testuje se v reálném prostředí
  • testovací scénáře

Statická analýza

  • analyzují se zdrojové kódy
  • kvalita kódu
  • kvalita dokumentace
  • detekce netestovaných částí kódu
  • detekce mrtvých částí kódu, duplicit, ...

Jaké jsou nevýhody a výhody automatických tesůtů?

Testování lidmi ve zkratce

  • seznam nových/opravených funkcí
  • testovací scénáře
  • zápis problémů
  • postup reprodukce

Metodiky vývoje

Metodika vývoje

  • způsob vývoje
  • každý projekt je specifický
  • nutný standard postupu
  • opakovatelnost

Jaké výhody a nevýhody poskytuje používání nějaké metodiky vývoje?

Klasické metodiky vývoje

  • propracované
  • cílí na dokumentaci
  • často zbytečná práce pro malé projekty

  • Unified Process, Modern Structures Analysis, ...

Agilní metodiky vývoje

  • flexibilní
  • cílí na výsledek
  • co nejrychleji dostat produkt do první verze

  • SCRUM, Extrémní programování, Test Driven Development, ...

Sekvence postupů

  • Sběr požadavků
  • Analýza
  • Návrh
  • Implementace
  • Dodání a údržba

SCRUM

  • iterativní
  • agilní vývoj
  • vývoj v iteracích
  • spolupracující zákazník

SCRUM

  • Scrum Team
  • Product Owner
  • Scrum Master
  • backlogy:
    • product backlog (požadavky)
    • sprint backlog (iterace)

Sprint

  • iterace
  • délka 1-4 týdnů
  • plánovací schůzka
  • denní stand-up — co se stalo, jak to bude dál, ...
  • sprint review
  • sprint retrospective

Problém SCRUM jsou velké týmy. Proč?

Děkuji za pozornost!

  • matej.cajthaml@ssps.cz
  • https://ssps.cajthaml.eu/