1 Slezská univerzita v Opavě, FPF Podklady k přednáškám Studijní obor: IVT Ročník: IV. Předmět: Projektování IS Téma: Objektový přístup k vývoji IS (část A) Vyučující: dr. Dušan Kajzar Školní rok: 2020/2021 Obsah: 1. Úvod k objektově orientované analýze a návrhu IS ............................................ 2 2. Modely objektového přístupu k analýze a návrhu IS .......................................... 4 3. Potřeby zákazníka a požadavky na IS.................................................................. 5 4. Diagram případů užití (Use Case Diagram) ........................................................ 6 5. Pokročilé konstrukce v Use Case Diagramu........................................................ 9 6. Shrnutí k Use Case Diagramu............................................................................ 12 Opakování tématu „Strukturovaný přístup ... “ Struktura systému Hledání a návrh struktury systému Struktura dat Struktura okolí Dynamika (pohyb) Modely = různé úhly pohledu na systém Struktura (statika) Yourdonova strukturovaná analýza Funkce (procesy), stavy (+přechody) 2 1. Úvod k objektově orientované analýze a návrhu IS Objektově orientovaný (stručně „objektový“) přístup:  principy „strukturování“ - zůstávají zachovány,  ústřední pojem = objekt. Objekt a systém:  objekt = prvek, zapouzdřující vlastnosti + chování, o vlastnosti jsou dány – daty objektu, tj. hodnotami jeho atributů, o chování je dáno – funkcemi (operacemi, metodami), prací s daty, o příklad - objekt Student Josef Novák (ID=21, JM=Josef, PRI=Novák, DTN=2.2.2002, ...),  systém = množina spolupracujících objektů, o objekty vznikají, pracují, reagují na události, zanikají, o příklad - systém IS SU (studenti, vyučující, předměty, rozvrhy, ...). Poznámka k historii vzniku objekt. přístupu:  historicky mladší - 2. pol. 80.let 20. stol.,  objektové programování => objektová analýza a návrh. Hlavní příčiny úspěchu objekt. přístupu:  řízení systému --> událostmi (řešení okenních rozhraní),  úlohy dávkové --> úlohy interaktivní,  knihovny tříd --> znovu použitelné,  porušení zásad --> syntaktické chyby hlášené překladači. Metody objektového přístupu:  90. léta 20. stol. o množství metod - z vývojové praxe i akademické půdy, o nejvýznamnější - Booch (OOD), OMT, OOSE,  snahy po sjednocení metod v jednu univerzální o Unified Method (Booch, Rumbaugh), o nevedlo k úspěchu => transformace na UML. 3 UML (Unified Modeling Language):  grafický jazyk pro modelování IS,  Booch, Rumbaugh, Jacobson,  notace UML – modely, grafické znaky. Podpora UML:  OMG (Object Management Group),  www.omg.org, www.uml.org,  trh CASE nástrojů - integrace UML. V současnosti:  UML o standard v oblasti notace modelování, o použití i mimo oblast vývoje IS (např. modelování procesů, workflow), o => znalost UML – požadavek mnoha pracovních míst,  metodiky a metody vývoje IS o existují různé metodiky a metody, o odlišnosti metod - notace, zaměření na etapy vývoje, okruh úloh, o dnes nejvýznamnější – RUP, UP,  metodiky a metody nabízí o „klasické“ prostředky pro boj se složitostí, o množinu modelů + postupy jejich tvorby. Důležité pro studium i praxi:  osvojení tzv. „objektového“ způsobu myšlení,  množina modelů UML = dílna nástrojů vývojáře,  dávejte si do souvislosti UML + znalosti z OO programování! 4 2. Modely objektového přístupu k analýze a návrhu IS Přehled modelů objektově orientované analýzy a návrhu IS: Použití modelů k zobrazení:  stávajícího stavu IS – k porozumění současné situaci,  cílového stavu IS - návrh nového (inovovaného) systému. Zobrazení struktury systému Zobrazení chování systému Diagram případů užití (Use Case Diagram) Diagram tříd (Class Diagram) Diagram stavů (State Diagram) Diagram činností - aktivit (Activity Diagram) Diagram komponent (Component Diagram) Diagram nasazení (Deployment Diagram) Diagram objektů (Object Diagram) Diagram balíčků (Package Diagram) Sekvenční diagram (Sequence Diagram) Diagram spolupráce (Collaboration Diagram) Diagram přehledu interakcí (Interaction Overview) Diagram časování (Timing Diagram) Composite Structure Diagram Implementační modely Diagramy interakcí 5 3. Potřeby zákazníka a požadavky na IS Obrázek: Potřeby zákazníka a požadavky na systém Inženýrství požadavků:  proces získávání a dokumentování požadavků na systém,  analýza zákazníkových potřeb => specifikace požadavků. Obrázek: Zdroje chyb v SW (podle Patton, R.: Testování SW, Computer Press, 2002) Požadavky jako základ tvorby systémů:  vyjadřují „CO“ by měl systém dělat,  nemíchat dohromady s otázkou „JAK?“ Požadavky funkční a mimofunkční:  funkční – týkají se uživatelských funkcí,  nefunkční (mimofunkční), např.: o výkon, doba odezvy, vytíženost, dostupnost, spolehlivost, Potřeby zákazníka Požadavky na IS (specifikace) ….. ….. ….. Návrh systému Specifikace IS Programový kód Jiné 6 o zabezpečení, důvěrnost dat, o integrace s jinými IS, provozní standardy, o technická omezení, např. nasazení na dané platformě, o rozpočtová omezení, organizační požadavky, zákonné požadavky. 4. Diagram případů užití (Use Case Diagram) Účel modelu „Use Case“:  zachycení funkčních požadavků na systém,  kdo a co od systému očekává,  kdo a k čemu bude systém používat. Základní prvky modelu:  řešený systém,  aktér (aktor, participant, účastník),  případ užití (use case),  scénáře případů užití. Obrázek: Příklad diagramu případů užití Poznámka k pravé a levé straně:  levá strana diagramu – aktivní aktéři (iniciátoři akce),  pravá strana diagramu - příjemci výstupů, zákazník Automat pro výdej jízdenek Zakoupení jízdenky Doplnění zásobníků Výběr mincí zásobovač výběrčí 7  resp. nerozlišujeme význam levé a pravé strany diagramu. Úkoly vývojáře při tvorbě Use Case:  nalezení hranic systému (odhad hranic + přesvědčit se, že to tak je),  vyhledání (určení) všech aktérů,  zobrazení vazeb (relací) „aktéři <-> případy užití“,  popis případů užití (scénáře a alternativní scénáře). Struktura popisu případu užití (scénáře):  aktér - iniciátor případu užití,  vstupní podmínky,  kroky scénáře (sekvence, větvení, cyklus),  výstupní podmínky - ukončují případ užití,  aktér - příjemce výsledku. Scénář případu užití: Případ užití: Zakoupení jízdenky ID=AS-B-01 Stručný popis: Cílem scénáře je obsloužit zákazníka dopravního podniku. Po volbě typu a zaplacení jízdného zákazník obdrží jízdenku. Hlavní aktéři: Zákazník Vedlejší aktéři: Žádní. Aktor A Nový (inovovaný) IS Funkce F1 Funkce F2 Aktor D Aktor B Aktor A Aktor C .... Funkce F3 Funkce Fn Systém Sy Systém Sx Aktor C 8 Vstupní podmínky: Automat je ve stavu Ready. Hlavní scénář: 1. Zákazník si zvolí typ jízdného dle nabídky na panelu. 2. Automat vypíše požadovanou výši Kč. 3. Zákazník vhodí mince povolené hodnoty do vstupního zařízení automatu. 4. Automat ověří vloženou sumu Kč. 5. Pokud .... 5.1 ... 5.2 ... 6. .... ..... „n“ Zákazník odebere z výstupu jízdenku. Výstupní podmínky: Zákazník obdržel jízdenku. Alternativní scénáře: Zákazník požaduje storno akce. Zákazník vhodil neplatnou minci. .... Větvení ve scénáři:  hlavní tok událostí (ideální případ),  vyjádření odchylek o rozvětvení scénáře „Když ...“, o pomocí alternativních scénářů. Hledání alternativních scénářů:  alternativy hlavního postupu,  reakce na chyby, reakce na přerušení. Přesné formulace ve scénářích:  nikoliv jen „Jsou zadávány údaje o zákazníkovi.“,  nýbrž „Kdo zadává?“, „Co? Kam? Jak ?“,  schéma: bude . Vyjádření pochybností:  vyjádřete své pochybnosti u kategorických formulací zadavatele,  u kvantifikátorů: všichni, každý, vždy, nikdy, nikdo, žádný, ... 9  např.: „Každý, kdo si chce půjčit knihu, musí mít průkazku.“, „Opravdu každý? Neexistuje nějaký výjimečný případ?“ Omezení případů užití:  zachytí funkční požadavky na systém,  nezachytí nefunkční požadavky. Mapování případů užití na požadavky:  matice propojení (Requirements Tracebility Matrix),  požadavky a jejich zahrnutí v případech užití. Požadavky Případy užití P01 P02 P03 P04 P05 P06 .... UC01 + + + UC02 + + UC03 + + .... Dílčí shrnutí základních částí Use Case diagramu: 5. Pokročilé konstrukce v Use Case Diagramu Pokročilé konstrukce s případy užití:  vkládání <>  rozšíření <>  zobecnění – aktérů, případů užití,  seskupování. scénáře matrix 10 Vkládání <> :  bázový use case (klient) - není úplný,  dodavatel funkcionality - úplný, neúplný, Obrázek: Vkládání <> případů užití Rozšíření <> :  bázový use case - vždy úplný,  rozšiřující use case - úplný, neúplný, Obrázek: Rozšíření <> případů užití Automat pro výdej jízdenek <> <> Doplnění zásobníků Výběr mincí zásobovač výběrčí Otevřít vstup Zavřít vstup <> <> Doplnění zásobníku jízdenek Bod rozšíření: Doplnění zásobníku s kontrolou tržby Kontrola tržby <> 11 Zobecnění – aktérů, případů užití: Obrázek: Zobecnění aktérů Obrázek: Zobecnění případů užití Seskupování: Obrázek: Seskupování - Balíček pracovník dopravního podniku zásobovač výběrčí Zakoupení jízdenky Zakoupení jízdenky bez přestupu Zakoupení jízdenky s přestupem Balíček B1 UC03 UC05 UC02 UC04 případy užití (Use Cases) UC01 12 6. Shrnutí k Use Case Diagramu Shrnutí k Use Case Diagramu:  diagram -> scénáře -> matrix,  zobrazuje dynamický pohled na systém zvnějšku,  k popisu hranice a komunikace mezi systémem a jeho okolím, o externí entity (aktéři) – životní i neživotní, o rozčlenění aktérů do skupin (podle používání systému),  k pochopení chování systému vzhledem k jeho okolí, o základní členění systému na případy užití, o popis slovními scénáři případů užití. Use Case Diagram NENÍ určen pro:  znázornění vzájemné komunikace aktérů,  zachycení „vnitřku“ systému o implementace (realizace) případů užití („Jak?“), o realizace případů užití interními procesy (funkcemi) systému, o zobrazení vnitřních stavů systému a změn stavů,  podrobný funkční rozklad systému na subsystémy. Poznámky a doporučení:  cílem je vytvořit srozumitelný model (uživatelům i vývojářům),  vyhýbat se pokročilým konstrukcím, nepřispívají-li srozumitelnosti,  scénáře popisují o „Co“ od systému očekávají aktéři, o nikoliv „Jak“ to systém realizuje,  nejde o zpracování funkční dekompozice (!) Use Case Diagram je také podkladem pro:  návrh uživatelského rozhraní IS,  plán a návrh testů. Proč je Use Case vhodný jako podklad ke zde uvedeným činnostem?