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 E)
Vyučující: dr. Dušan Kajzar Školní rok: 2020/2021
Obsah:
1. Diagram komponent (Component Diagram) ....................................................... 2
2. Diagram nasazení (Deployment Diagram) .......................................................... 4
3. Další diagramy v UML 2.5.................................................................................. 6
4. Tvorba modelů během vývoje IS......................................................................... 8
5. Několik zásad pro modelování IS........................................................................ 9
6. Přehled historicky významných metod OOP..................................................... 10
7. Metodika RUP ................................................................................................... 12
Kde se nacházíme ?
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í
2
1. Diagram komponent (Component Diagram)
Účel modelu:
 znázornění softwarových komponent vyvíjeného IS,
 znázornění softwarové architektury systému (vazeb programových modulů).
Poznámka:
 srovnejme – model Structure Chart ve strukturovaném přístupu.
Které prvky (komponenty) zde zobrazujeme:
 spustitelné soubory (.exe, ...),
 dynamické knihovny,
 soubory s parametry,
 soubory s daty, …
SW komponenta:
 obrázek - grafické znázornění SW komponenty.
SW komponenty vs. třídy:
 SW komponenta je softwarovou implementací jedné nebo více tříd,
 v diagramu komponent lze znázornit třídy, které daná komponenta
implementuje,
 obrázek - třídy implementované komponentou "Adresář osob".
nebo:
Kalkulačka.exe
Osoby Seznam ulic Telefonní seznam
Adresář osob Adresář osob
Třídy:
Osoby
Seznam ulic
Telef. seznam
3
Rozhraní (interface):
 umožňuje opakované použití SW komponenty v různých subsystémech.
Příklad diagramu komponent:
 obrázek - interakce SW komponent v diagramu komponent.
Znázornění rozhraní:
 obrázek - dva způsoby grafického znázornění rozhraní SW komponent.
Znázornění datových souborů:
 jde o soubory, se kterými SW komponenty pracují,
 využití stereotypu <<popis>>, nebo grafického znaku „Poznámka“.
Zobrazit
Vyhledávač
<<rozhraní>>
Zobrazit
zobraz()
Vyhledávač
Adresář osob
Vyhledávač
Klientský SW
VyhledávačIndex.html Průkaz.tif
4
2. Diagram nasazení (Deployment Diagram)
Účel modelu:
 zobrazení hardwarové architektury systému,
 zobrazuje výpočetní (hardwarové) uzly a vazby mezi nimi.
Typy HW uzlů:
 aktivní uzel (procesor) – umí spouštět softwarovou komponentu,
 pasivní uzel (zařízení) – představuje rozhraní s vnějším světem (například
tiskárna, monitor apod.),
 obrázek - HW uzly a jejich spojení.
Spojení mezi HW uzly:
 může znázorňovat různé druhy vazeb (obdobně jako u diagramu tříd),
 např. agregace, závislost apod.
Přiřazení SW komponent HW uzlům:
Uzel
1
Uzel
2
Adresář osob
Vyhledávač
Klientský SW
Server S1
Klient K8
5
Dvoustupňový proces tvorby:
 1. SW komponenty a vazby mezi nimi,
 2. přiřazení SW komponent HW uzlům => uzly a jejich spojení.
Využití diagramu nasazení:
 modelování SW a HW architektury vyvíjeného systému,
 modelování počítačových sítí.
Zobrazení architektury počítačové sítě:
 obrázek - využití diagramu nasazení pro zobrazení architektury počítačové
sítě.
Obrázky mimo jazyk UML:
 možnost použití jiných grafických symbolů - mimo jazyk UML,
 například obrázky počítačů (klientské stanice, servery),
 tiskárny, aktivní prvky sítě, obláček pro znázornění Internetu apod.,
 cíl - názornost zobrazení.
Poznámka:
 Setkali jsme se s obdobným diagramem v modelech strukturovaného
přístupu?
{Parametry spojení: ....}
Switch 1
Switch 2
PC 1
PC 2 PC 3
PC 4
PC 5 PC 6 PC 7
6
3. Další diagramy v UML 2.5
Přehled:
 zdroj: http://www.uml-diagrams.org/uml-25-diagrams.html
Diagram informačních toků (Information Flow Diagram):
 slouží ke zobrazení toků informací mezi prvky systému,
 mezi odděleními podniku, mezi subsystémy apod.
7
Příklad diagramu inf. toků:
 http://www.uml-diagrams.org/uml-25-diagrams.html
Diagram síťové architektury (Network Architecture Diagram):
 slouží ke zobrazení počítačové sítě, její architektury,
 switche, routery, load balancery, firewally, ...
Poznámky:
 k tomuto účelu může být použit Deployment Diagram,
 ve verzi UML 2.5 hovoříme o spec. diagramu,
 používá grafické symboly mimo UML – obrázky.
Příklad Network Arch. diagramu:
 http://www.uml-diagrams.org/uml-25-diagrams.html
8
4. Tvorba modelů během vývoje IS
Kde se nacházíme?
 seznámili jsme se s modely jazyka UML,
 zkusme se nyní zamyslet nad posloupností jejich využití během vývoje IS,
 zatím bez vazby na konkrétní metodiku, pouze „selským rozumem“.
Mapování podnikových procesů (logika business procesů):
 použití modelů
Počáteční modely systému:

 jakožto výchozí model znázorňující vyvíjený IS ve vztahu k jeho okolí,

 znázorňující základní objekty (třídy) vyvíjeného IS a vztahy mezi nimi.
Rozpracování modelů:
 další rozpracování
 zdokonalujeme (zpodrobňujeme)
 pro popisy činností využijeme
Spolupráce (interakce) mezi objekty během procesů:



Přechod z analytické úrovně do úrovně návrhových modelů:
 doplnění návrhových tříd
 potřebné zpodobnění
Diagramy aktivit
Use Case diagram
Diagram tříd
Diagramy sekvencí
Diagramy spolupráce
doplňování informací
do diagramu tříd
Interaction Overview
Use Case diagram Scénáře případů
užití
Diagramy aktivit
Diagramy tříd
Diagramy tříd
Diagramy sekvencí
Diagramy spolupráce
... začlenění interakcí do kontextu aktivit
9
Úvahy nad životními cykly objektů (tj. instancí vybraných tříd):
 provádíme analýzu stavů objektů a změn stavů
 spolupráce objektů v různých stavech a v čase
Návrh SW architektury:
 vytváříme
Kompletace SW a HW architektury systému:
 HW architektura systému
 kompletace diagramů komponent a nasazení.
Další činnosti:
 návrh a schválení uživatelských rozhraní,
 návrh a schválení postupů testování systému,
 kompletace projektové dokumentace k systému,
 ...
5. Několik zásad pro modelování IS
Několik zásad modelování IS:
 zásada správnosti
o dbát na úplnost, bezespornost, konzistenci modelů,
o dbát na správnost syntaktickou (správné použití grafických znaků jazyka
UML) a sémantickou (významovou),
 zásada důležitosti (závažnosti, relevance) a hospodárnosti (efektivnosti)
o brát v úvahu informační potřebu cílového čtenáře,
o model by neměl obsahovat více informací, než je nutné vzhledem k účelu
jeho použití,
o zvažovat poměr „náklady / využití / účel“,
 zásada srozumitelnosti
o dbát na čitelnost a použitelnost modelů pro cílového čtenáře,
Diagramy stavů
Diagramy komponent
Diagramy nasazení
Diagramy časování
10
o nikoliv čitelný pouze pro specialistu či pro autora,
 zásada srovnatelnosti
o dodržovat stanovené konvence (dohody, úmluvy), standardy,
o metamodely pro popisy obsahu modelů,
 zásada systematické struktury
o modely = různé (doplňující se) úhly pohledu na danou realitu,
o integrace pohledů => pochopení tvořeného systému.
Upozornění na některá nebezpečí:
 používání obecných vyjádření pro popisy činností
o např.: „musí se shromáždit potřebné informace ...“
o Jak shromažďujete potřebné informace? Kdo je shromažďuje? Kdy? ...
 vágní popis požadavků (nejasný, nejednoznačný, nepřesný)
o např. „ovládání systému musí být intuitivní“,
o „systém musí mít rychlé odezvy“, ...
 idealizace procesů a činností
o znázornění, jak by to mělo být, nikoliv jak to skutečně je,
o Skutečně to takhle děláte? Existuje situace, kdy postupujete jinak?
Skutečně je to vždy první věc, kterou uděláte? apod.
6. Přehled historicky významných metod OOP
Poznámka k historii objektového přístupu:
 objektové programování,
 objektově orientovaná analýza a návrh IS.
Přehled významných O-O metod a technik:
 Booch (Object Oriented Design - OOD), publikována v roce 1991,
 Coad/Yourdon,
 OMT (Object Modeling Technique), James Rumbaugh, 1991,
 OMT2,
 OOSE (Objectory/Object-Oriented Software Engineering),
 Shlaer/Mellor,
 CRC (Class, Responsibility, Collaborators),
11
 BON (Business Object Notation), 1994,
 OOMT (Objektově orientované metodiky a technologie), VŠE Praha, 1996,
 BORM (Business Object Relation Modeling),
 RUP (Rational Unified Process), vyvinuta společností Rational Software
Corporation,
 UP (Unified Process) - je otevřeným standardem procesu vývoje IS, vyvinuto
autory jazyka UML.
Doporučená literatura:
 Arlow J., Neustadt I.: „UML2 a unifikovaný proces vývoje aplikací“,
Computer Press,
 Kadlec V: „Agilní programování“, Computer Press, 2004,
 Drbal P.: „Objektově orientované metodiky a technologie“, 1. a 2. díl.
Vysoká škola ekonomická, Praha, 1997,
 Polák J., Merunka V., Carda A.: „Umění systémového návrhu“. Publishing,
Praha, 2003.
12
7. Metodika RUP
RUP (Rational Unified Process):
 rozsáhlá propracovaná metodika,
 vyvinuta firmou Rational Software (byla koupena firmou IBM),
 komerční metodika, platí se za potřebný počet licencí.
Schéma metodiky RUP:
Vertikální osa - aktivity v každé iteraci:
 Business Modeling - modelování podnikových procesů,
 Requirements - práce s uživatelskými požadavky,
 Analysis & Design - analýza a návrh systému,
 Implementation - implementace systému,
 Test - testování, ověřování,
 Deployment - nasazení systému a jeho další rozvoj,
 Configuration & Change Management - řízení změn ve verzích systému
a konfigurační řízení,
 Project Management - aktivity spojené s řízením projektu a řízením rizik,
 Environment - aktivity zaměřené na interní procesy a nástroje vývoje SW.
13
Horizontální osa:
 zahájení, rozpracování, konstrukce (realizace), zavedení.
Zahájení, inicializace (Inception):
 účel etapy
o specifikace vize konečného produktu,
o identifikace projektu, jeho cíle, účelu, koncepce, rozsahu,
o identifikace uživatelských požadavků,
o modelování podnikových procesů,
 hlavní výstupy etapy
o dokumentace koncepce projektu, tj. základních požadavků klienta a
vlastností produktu,
o úvodní (základní) konceptuální model systému („hotový“ z 10% - 20%),
o úvodní (základní) slovník projektu (jako doménový model),
o základní podnikové procesy,
o plán projektu,
o základní analýza rizik projektu,
o návrh jednoho resp. více prototypů.
Rozpracování (Elaboration):
 účel etapy
o analýza a návrh systému,
o rozbor a popis vlastností systému,
o návrh kvalitní architektury systému,
o plánování postupu projektu a potřebných zdrojů,
 hlavní výstupy etapy
o konceptuální model systému (min. z 80% hotový),
o identifikace všech uživatelů systému a služeb poskytovaných systémem,
o úplný seznam uživatelských požadavků,
o přesná architektura systému,
o funkční prototyp systému,
o podrobný další plán projektu,
o revidovaná analýza rizik projektu.
14
Konstrukce, realizace (Construction):
 účel etapy
o tvorba systému (programování),
o inkrementální přidávání funkcionality do struktury systému,
 hlavní výstupy etapy
o softwarový produkt na požadované platformě,
o uživatelská dokumentace k systému,
o popis aktuální verze produktu,
o přesný popis architektury systému,
o funkční prototyp systému,
o podrobný další plán projektu,
o revidovaná analýza rizik.
Zavedení, předání (Transition):
 účel etapy
o dodání produktu koncovému zákazníkovi,
o zaškolení uživatelů,
o zavedení produktu do provozu,
o podpora a další údržba produktu.
Výchozí principy pro práci v RUP (tzv. Best Practises):
 iterativní vývoj (Develop Iteratively)
o vývoj softwaru postupným zjemňováním (refinement),
o postupně pronikáme do řešené problematiky,
o přidávání dalších vlastností (increments) v jednotlivých iteracích,
o průběžně získáváme zpětnou vazbu ze strany uživatele,
o postupným přibližováním se představám uživatele redukujeme rizika
projektu,
 správa uživatelských požadavků (Manage Requirements)
o tzv. přístup řízený případy užití (use-case-driven-approach),
o pohled na výsledek každé činnosti jako na hodnotu pro uživatele,
o neustálé doplňování, třídění a hodnocení požadavků zadavatele,
15
o požadavky jsou dynamické – nutno počítat s jejich změnami,
o celý vývoj IS je podřízen požadavkům zadavatele (uživatele),
 použití architektury komponent (Utilize Component Architectures)
o myšlenka - bývá levnější koupit produkt splňující 75% požadavků, než
vyvinout produkt, který nakonec splňuje také 75% požadavků,
o aplikace vzorů, komponent, nákup a využití hotových modulů a
částečných řešení,
 vizuální modelování (Model Visually)
o postupné vytváření modelů - systému, procesů, ...
o účel – dobré pochopení potřeb a požadavků pro analýzu, návrh,
implementaci a další rozvoj systému,
 neustálé průběžné sledování a hodnocení kvality (Verify Quality)
o kontrola kvality postupu vývoje IS,
o kontrola kvality výsledného produktu,
o snaha nalézt a odstranit problém co nejdříve,
 řízení a kontrola změn (Control Changes)
o neřízené změny – zdroj chaosu, mohou rozvrátit vývojový proces,
o proces řízení změn nutno integrovat do vývojového procesu.
Metodika RUP se také zabývá a popisuje:
 role (roles)
o úlohy a pozice ve vývojovém týmu,
o např. analytik, návrhář, implementátor, tester, manažer, recenzent,
architekt atd.,
 meziprodukty (artifacts)
o ve formě dokumentů, záznamů, požadavků, katalogů, diagramů,
o např. model, prvek modelu (třída, subsystém,...), dokument, zdrojový kód,
spustitelná aplikace,
o jsou dodávané jako vstupy resp. výstupy jednotlivých aktivit,
o vznikají a jsou modifikovány v průběhu procesu vývoje,
 aktivity (activities)
o nejmenší jednotky práce (úkoly) v rámci procesu vývoje,
o vykonávané jednou či více osobami v konkrétních rolích,
16
o výsledkem je i vytvoření nebo modifikace příslušného dokumentu
(např. zápis požadavků, identifikace tříd apod.),
 pracovní procesy (workflow)
o sekvence navazujících aktivit, rolí a dokumentů,
o časová posloupnost aktivit.
Vhodnost použití metodiky RUP:
 pro velké vývojové firmy (nikoliv pro jednoúčelové týmy),
 pro dlouhotrvající velké projekty,
 kde je nutné použít přísné, zdokumentované, propracované vývojové procesy,
 nutno vyčlenit čas na studium a implementaci metodiky RUP,
 adaptabilní – možno přizpůsobit i malým projektům a týmům.
Vztah RUP a UP (Unified Process):
 metodika UP je nekomerční, volně dostupná „varianta“ RUP,
 UP je jednodušší, méně propracovaná,
 UP – viz literatura „UML2 a unifikovaný proces vývoje aplikací“.