načítání...
nákupní košík
Košík

je prázdný
a
b

Kniha: Softwarové inženýrství - Ian Sommerville

Softwarové inženýrství
-14%
sleva

Kniha: Softwarové inženýrství
Autor:

Jste studenti a máte povinné či volitelné kurzy softwarového a systémového inženýrství? Pracujete jako softwaroví inženýři? V této publikaci získáte dokonalý přehled v oboru. Ti ... (celý popis)
Titul doručujeme za 5 pracovních dní
Vaše cena s DPH:  1 290 Kč 1 109
+
-
rozbalKdy zboží dostanu
37
bo za nákup
rozbalVýhodné poštovné: 0Kč
rozbalOsobní odběr zdarma

hodnoceni - 71.2%hodnoceni - 71.2%hodnoceni - 71.2%hodnoceni - 71.2%hodnoceni - 71.2% 90%   celkové hodnocení
1 hodnocení + 0 recenzí

Specifikace
Nakladatelství: » Computer press
Médium / forma: Tištěná kniha
Rok vydání: 2013-09-18
Počet stran: 680
Rozměr: 167 x 225 mm
Úprava: 680 stran : ilustrace
Vydání: 1. vyd.
Název originálu: Software engineering
Spolupracovali: překlad Jakub Goner
Vazba: vázaná s laminovaným potahem
Doporučená novinka pro týden: 2013-39
ISBN: 9788025138267
EAN: 9788025138267
Ukázka: » zobrazit ukázku
Popis / resumé

Publikace poskytuje přehled softwarového inženýrství. Zaměřuje se na klíčová témata, která jsou zásadní pro všechny vývojové procesy, a na témata týkající se vývoje spolehlivých distribuovaných systémů.

Popis nakladatele

Jste studenti a máte povinné či volitelné kurzy softwarového a systémového inženýrství? Pracujete jako softwaroví inženýři? V této publikaci získáte dokonalý přehled v oboru. Ti zkušenější si pak mohou osvěžit a doplnit své znalosti témat, jako jsou opakované použití softwaru, návrh architektury, spolehlivost a zabezpečení a zlepšování procesů a mnoha dalších. Kniha je sestavena tak, aby ji bylo možné využít v obecných úvodních kurzech softwarového inženýrství i v kurzech středně pokročilých zabývajících se konkrétními tématy. Zaměřuje se na klíčová témata, která jsou zásadní pro všechny vývojové procesy, a na témata týkající se vývoje spolehlivých distribuovaných systémů. Kombinuje agilní metody i metody „tradičního“ plánovaného softwarového inženýrství. Autor se v knize věnuje mimo jiné následujícím tématům: Softwarové procesy, návrh architektury - Agilní vývoj softwaru i „tradiční metody“ - Testování softwaru a systémové modelování - Inženýrství a zajištění spolehlivosti a zabezpečení - Distribuované softwarové inženýrství - Architektura orientovaná na služby - Řízení a plánování projektu - Kontrola kvality a správa konfigurace - Zlepšování procesů Za každou kapitolou navíc naleznete shrnutí hlavních témat a cvičení. O autorovi: Ian Sommerville je profesorem softwarového inženýrství na St Andrews University ve Skotsku. Učí pokročilé kurzy softwarového inženýrství a inženýrství kritického softwaru. Zabývá se především zkoumáním komplexních systémů.

Předmětná hesla
Kniha je zařazena v kategoriích
Recenze a komentáře k titulu
Zatím žádné recenze.


Ukázka / obsah
Přepis ukázky

117

Systémové

modelování

Cíle

Cílem této kapitoly je představit některé typy systémových modelů, které lze vyvinout v rámci

procesů inženýrství požadavků a návrhu systému. V této kapitole:

 porozumíte tomu, jak lze reprezentovat softwarové systémy pomocí grafických modelů,

 seznámíte se s různými typy modelů a základními perspektivami systémového modelování:

kontextovou, interakční, strukturní a behaviorální,

 setkáte se s některými typy diagramů jazyka UML (Unified Modeling Language) a dozvíte

se, jak lze tyto diagramy uplatnit při systémovém modelování,

 získáte představu o idejích, z nichž vychází inženýrství řízené modely, kde je systémautomaticky generován ze strukturních a behaviorálních modelů.

Proces systémového modelování umožňuje vyvíjet abstraktní modely systému, kdy každý model prezentuje odlišný pohled či perspektivu daného systému. Systémové modelování postupně začaloreprezentovat systémy určitým způsobem grafického zápisu, který je v  současnosti téměř vždy založen na

jazyku UML. Je však rovněž možné vyvinout formální (matematické) modely systému, obvykle jako

podrobné specifikace systému. Grafickým modelováním pomocí jazyka UML se budeme zabývat v této

kapitole a formálním modelováním v kapitole 12.

V  procesu inženýrství požadavků pomáhají modely odvodit požadavky na systém, během procesu

návrhu umožňují popsat systém pro techniky, kteří systém implementují, a  po implementaci slouží

k dokumentování struktury a fungování systému. Lze vyvinout modely stávajících systémů i nověvyvíjených systémů:

1. Modely existujícího systému se používají při inženýrství požadavků. Pomáhají vyjasnit funkcestávajícího systému a mohou sloužit jako základ pro diskusi o jeho silných a slabých stránkách. Tyto

diskuse pak mohou vést k požadavkům na nový systém.

2. Modely nového systému pomáhají při inženýrství požadavků vysvětlit navržené požadavky jiným

osobám zainteresovaným na systému. Technici pomocí těchto modelů rozebírají designové návrhy

5


Část 1: Úvod do softwarového inženýrství

118

Systémové modelování

a dokumentují systém pro implementaci. V procesu inženýrství řízeného modely lze z modelusystému generovat úplnou nebo částečnou implementaci systému.

Nejdůležitějším aspektem modelu systému je to, že vynechává podrobnosti. Model je abstrakcestudovaného systému, nikoli jeho alternativní reprezentace. Reprezentace systému by měla v ideálním případě

zachovat veškeré informace o reprezentované entitě. Abstrakce záměrně zjednodušuje a vybírá pouze

nejdůležitější vlastnosti. Například ve velmi nepravděpodobném případě, že by tato kniha vycházela

na pokračování v novinách, tato prezentace by byla abstrakcí hlavních témat knihy. Český překlad této

knihy představuje její alternativní reprezentaci. Záměrem překladatele je zachovat veškeré informace,

které obsahuje anglický originál.

Můžeme vyvinout různé modely, které budou systém reprezentovat z odlišných hledisek. Například:

1. Externí perspektiva, která modeluje kontext nebo prostředí systému.

2. Interakční perspektiva, která modeluje interakce mezi systémem a  jeho prostředím nebo mezi

komponentami systému.

3. Strukturní perspektiva, která modeluje uspořádání systému nebo strukturu dat, která systémzpracovává.

4. Behaviorální perspektiva, která modeluje dynamické chování systému a to, jak systém reaguje na

události.

Tyto perspektivy mají hodně společných prvků s Krutchenovým pohledem 4 + 1 na systémovouarchitekturu (Kruchten, 1995), v němž navrhuje dokumentovat architekturu a organizaci systému z různých

perspektiv. Uvedeným přístupem 4 + 1 se budeme zabývat v kapitole 6.

V  této kapitole používáme diagramy definované v  UML (Booch et al., 2005; Rumbaugh et al., 2004),

který se etabloval jako standardní modelovací jazyk pro objektově orientované modelování. Jazyk UML

obsahuje mnoho typů diagramů, a umožňuje proto vytvářet mnoho různých typů systémových modelů.

Studie z roku 2007 (Erickson a Siau, 2007) však ukázala, že podle názoru většiny uživatelů jazyka UML

lze základní aspekty systému reprezentovat pomocí pěti typů diagramů:

1. Diagramy aktivity, které znázorňují aktivity související s procesem nebo zpracováním dat.

2. Diagramy případů použití, které zobrazují interakce mezi systémem a jeho prostředím.

3. Sekvenční diagramy, které představují interakce mezi aktéry a  systémem a  mezi komponentami

systému.

4. Diagramy tříd, které ukazují objektové třídy v systému a asociace těchto tříd.

5. Stavové diagramy, které popisují, jak systém reaguje na interní a externí události.

Vzhledem k tomu, že zde nemáme místo na rozbor všech typů diagramů UML, zaměříme se na těchto

pět klíčových typů diagramů, které se používají v systémovém modelování.

Při vývoji systémových modelů lze často způsob použití grafických značek pružně přizpůsobovat.

Pokaždé není nutné se přísně držet detailů dané notace. Úroveň podrobností a striktnost modelu závisí

na tom, jak chceme s modelem pracovat. Grafické modely se běžně používají třemi způsoby:

1. Jako základ pro diskuse o existujícím nebo navrženém systému.

2. Jako způsob dokumentace stávajícího systému.

3. Jako podrobný popis systému, pomocí něhož lze generovat implementaci systému.


Kontextové modely

Kapitola 5: Systémové modelování

119

V prvním případě je účelem modelu stimulovat diskusi mezi softwarovými inženýry, kteří se podílejí na

vývoji systému. Modely nemusí být úplné (za předpokladu, že zahrnují klíčová témata diskuse)a modelovací notaci mohou používat neformálně. Tímto způsobem se modely obvykle uplatňují v takzvaném

„agilním modelování“ (Ambler a Jeffries, 2002). Když modely slouží k dokumentaci, nemusí být úplné,

protože účelem může být vývoj modelu pouze pro některé části systému. Tyto modely však musí být

správné – měly by správným způsobem používat notaci a přesně popisovat systém.

JAZYK UML

Jazyk UML (Unified Modeling Language) je sada 13 různých typů diagramů, které umožňují modelovat

softwarové systémy. Vznikl v 90. letech na základě práce na objektově orientovaném modelování, kdy

došlo k  integraci podobných objektově orientovaných notací. Hlavní revize (UML 2) byla dokončena

roku 2004. Jazyk UML je univerzálně uznáván jako standardní přístup k  vývoji modelů softwarových

systémů. Objevily se také návrhy pro obecnější systémové modelování.

http://www.SoftwareEngineering-9.com/Web/UML/ Ve třetím případě, kdy se modely používají v rámci vývojového procesu založeného na modelech, musí být systémové modely úplné i správné. Důvod spočívá v tom, že se podle těchto modelů generujezdrojový kód systému. Je proto nutné věnovat mimořádnou pozornost tomu, aby nedošlo k záměněpodobných symbolů, jako jsou šipky s čárovými a plnými hroty, které mají odlišný význam. 5.1 Kontextové modely V  rané fázi specifikace systému se musíme rozhodnout, kde budou hranice systému. Přitom musíme spolupracovat s osobami zainteresovanými na systému a určit, které funkce bude systém zahrnovat a co bude poskytovat prostředí systému. Můžeme například požadovat, že pro některé podnikové procesy bude implementována automatizovaná podpora, ale další procesy budou fungovat manuálně nebo jejich podporu zajistí jiné systémy. Měli bychom zjistit, kde se funkčnost systému překrývá se stávajícími systémy, a zvolit, zda se budou nové funkce implementovat. Tato rozhodnutí je potřeba přijmout v rané fázi celého procesu, aby se omezily náklady a zkrátil čas na analýzu systémových požadavků a návrhu. V některých případech vede mezi systémem a jeho prostředím relativně jasná hranice. Pokud například automatizovaný systém nahrazuje stávající ruční nebo počítačový systém, prostředí nového systému zpravidla odpovídá prostředí existujícího systému. V  jiných případech je k  dispozici větší flexibilita a přesnou hranici mezi systémem a jeho prostředím lze určit během procesu inženýrství požadavků. Předpokládejme například, že vyvíjíme specifikaci informačního systému o psychiatrických pacientech. Tento systém má uchovávat informace o pacientech navštěvujících psychiatrické kliniky a o léčbě, která jim byla předepsána. Při vývoji specifikace tohoto systému je potřeba se rozhodnout, zda se má systém zaměřit výhradně na shromažďování informací o konzultacích (kdy se osobní informace o pacientech budou získávat z jiných systémů), nebo zda bude rovněž shromažďovat osobní data pacientů. Pokud se informace o pacientech získávají z jiných systémů, je to výhodné z toho hlediska, že nedocházík duplikování dat. Hlavní nevýhoda však spočívá v  tom, že použití jiných systémů může zpomalit přístup k informacím. Jestliže tyto systémy nejsou dostupné, nelze systém MHC-PMS použít.


Kontextové modely

Část 1: Úvod do softwarového inženýrství

120

Obrázek 5.1 – Kontext systému MHC-PMS

Systémovou hranici nelze definovat nezávisle na hodnotách. Vzhledem ke společenskýma organizačním hlediskům může být pozice systémové hranice určena mimotechnickými faktory. Systémováhranice může být například záměrně umístěna tak, aby bylo možné analytický proces kompletně zajistit

v jedné lokalitě, může být zvolena tak, aby nebylo nutné konzultovat konkrétního manažera, se kterým

se obtížně spolupracuje, může být stanovena tak, aby se zvýšily náklady na systém, a  bylo tedy nutné

rozšířit divizi systémového vývoje, která systém navrhuje a implementuje.

Jakmile jsou přijata rozhodnutí ohledně hranic systému, je potřeba v rámci analytické aktivity definovat

kontext a  závislosti systému na jeho prostředí. Prvním krokem této aktivity zpravidla bývá vytvoření

jednoduchého modelu architektury.

Obrázek 5.1 znázorňuje jednoduchý kontextový model, který představuje informační systémo pacientech a jiné systémy v jeho prostředí. Z obrázku 5.1 je patrné, že systém MHC-PMS je připojen na systém

plánování schůzek a obecnější systém záznamů o pacientech, se kterým sdílí data. Systém je taképřipojen k systémům na správu vykazování a přidělování nemocničních lůžek a statistickému systému, který

shromažďuje informace pro výzkum. Nakonec používá i  systém předepisování léků, který pacientům

generuje recepty na jejich léky.

Kontextové modely obvykle ukazují, že prostředí obsahuje několik dalších automatizovaných systémů.

Neposkytují však informace o  typech vztahů mezi systémy v  prostředí a  o  specifikovaném systému.

Externí systémy mohou poskytovat data pro daný systém nebo přijímat data z tohoto systému. Mohou

se systémem sdílet data nebo je možné připojit je přímo či prostřednictvím sítě a také nemusí býtpřiojeny vůbec. Někdy se nacházejí na stejném místě, případně mohou být v různých budovách. Všechny

tyto vztahy mohou mít vliv na požadavky a návrh definovaného systému a je potřeba je zohlednit.

Jednoduché kontextové modely se proto používají spolu s jinými modely, jako jsou například modely

obchodních procesů. Tyto modely popisují ruční a automatizované procesy, v nichž se určité softwarové

systémy používají.

«system»

Systém MHC-PMS

«system»

Systém záznamů

o pacientech

«system»

Systém plánování

schůzek

«system»

Systém příjmu

pacientů

«system»

Systém

vykazování pro

management

«system»

Systém

předepisování

léků

«system»

Systém statistik

zdravotní péče


Kontextové modely

Kapitola 5: Systémové modelování

121

Obrázek 5.2 – Procesní model nedobrovolného zadržení

Obrázek 5.2 modeluje důležitý systémový proces, který ukazuje způsob, jakým se systém MHC-PMS

používá. Pacienti, kteří trpí duševními problémy, mohou být někdy nebezpeční sobě i jiným. Může být

proto nutné zadržet je v nemocnici proti jejich vůli, aby je bylo možné léčit. Toto zadržení podléhápřís

ným zákonným omezením. Rozhodnutí o  zadržení pacienta je například nutné pravidelně revidovat,

aby lidé nebyli bez dostatečného důvodu dlouhodobě omezováni na svobodě. Jednou z funkcí systému

MHC-PMS je kontrolovat, zda jsou implementovány takové zákonné pojistky.

Na obrázku 5.2 vidíme diagram aktivity UML. Diagramy aktivity mají znázornit aktivity, ze kterých

sestává systémový proces, a  postup, kterým si jednotlivé aktivity vzájemně předávají řízení. Začátek

procesu je symbolizován vyplněným kruhem a  konec je znázorněn vyplněným kruhem uvnitř jiného

kruhu. Obdélníky se zaoblenými rohy reprezentují aktivity, tzn. konkrétní dílčí procesy, které je potřeba

provést. Do grafů aktivity lze umístit i objekty. Na obrázku 5.2 jsou znázorněny systémy, které sepouží

vají na podporu různých procesů. Z funkce stereotypu UML je patrné, že se jedná o samostatné systémy.

Šipky v  diagramu aktivity UML představují tok činností od jedné aktivity k  jiné. Plná čára znamená

koordinaci aktivit. Když tok z více aktivit vede k plné čáře, pak další postup vyžaduje, aby bylydokon

čeny všechny tyto aktivity. Když tok od plné čáry směřuje k  více aktivitám, lze tyto aktivity provádět

paralelně. Na obrázku 5.2 je tedy patrné, že aktivity informování sociální péče a nejbližšího příbuzného

pacienta a aktualizace registru zadržení mohou probíhat zároveň.

K šipkám je možné doplnit popisky informující o podmínce, za které daný tok probíhá. Na obrázku 5.2

se nacházejí popisky, které označují toky pro pacienty podle toho, zda jsou nebo nejsou nebezpeční pro

společnost. Pacienty nebezpečné pro společnost je potřeba zadržet v zabezpečeném zařízení. Pacienty se

sebevražednými sklony, kteří jsou tedy nebezpeční sobě samým, lze však zadržet na vhodnémnemoc

ničním oddělení.

Potvrzení

rozhodnutí

o zadržení

Nalezení

bezpečného

místa

Přijetí do

nemocnice

Převoz na

policejní stanici

Převoz do

zabezpečené

nemocnice

«system»

Systém příjmu

pacientů

Informování

nejbližšího

příbuzného

Informování

sociální péče

Aktualizace

registru

«system»

Systém

MHC-PMS

«system»

Systém

MHC-PMS

Informování

pacienta o jeho

právech

Záznam

rozhodnutí

o zadržení

[Nebezpečný]

[Není k dispozici]

[Není nebezpečný]

[K dispozici]


Modely interakcí

Část 1: Úvod do softwarového inženýrství

122

5.2 Modely interakcí

Ve všech systémech dochází k nějakému druhu interakcí. Může se jednat o uživatelskou interakci, která

spočívá v uživatelském vstupu a výstupu, interakci vyvíjeného systému s jinými systémy nebo interakci

mezi komponentami systému. Modelování uživatelské interakce je důležité, protože pomáhá identifikovat uživatelské požadavky. Modelování interakce mezi systémy ukazuje, jaké problémy mohou nastat

při komunikaci. Modelování interakce komponent pomáhá porozumět tomu, zda navržená struktura

systému pravděpodobně zajistí požadovanou úroveň výkonu a spolehlivosti systému.

V této části se budeme zabývat dvěma souvisejícími přístupy k modelování interakcí:

1. Modelování případů použití, které se používá zejména při modelování interakcí mezi systémem

a externími aktéry (uživateli nebo jinými systémy). 2. Sekvenční diagramy, které slouží k modelování interakcí mezi systémovými komponentami, ačkoli

mohou zahrnovat i externí agenty. Modely případů použití a sekvenční diagramy předkládají interakce na různé úrovni podrobností, a lze je proto používat společně. Sekvenční diagram může dokumentovat podrobnosti interakcí, které se účastní na vysokoúrovňovém případu použití. Jazyk UML zahrnuje také komunikační diagramy, které dovolují modelovat interakce. Těmto diagramům se zde nebudeme věnovat, protože představujíalternativní reprezentaci sekvenčních grafů. Některé nástroje dokážou v praxi generovat komunikační diagram ze sekvenčního diagramu. 5.2.1 Modelování případů použití Modelování případů použití původně vyvinul Jacobson et al. (1993) v 90. letech a toto modelování se dostalo do první verze jazyka UML (Rumbaugh et al., 1999). Jak jsme diskutovali v kapitole 4,modelování případů použití se široce používá na podporu zjišťování požadavků. Případ použití lze považovat za jednoduchý scénář, který popisuje, co uživatel očekává od systému. Každý případ použití reprezentuje diskrétní úkol, který zahrnuje externí interakci se systémem. Ve své nejjednodušší formě je případ použití znázorněn formou elipsy. Aktéři, kteří se na případu použití podílejí, jsou pak reprezentováni schematickými figurkami. Obrázek 5.3 představuje případ použitísystému MHC-PMS. Jedná se o úkol odeslání dat ze systému MHC-PMS do obecnějšího systému záznamů o pacientech. Tento obecnější systém udržuje souhrnná data o pacientech a nikoli data o jednotlivých konzultacích, která jsou ukládána do systému MHC-PMS. Obrázek 5.3 – Případ použití přenosu dat Všimněme si, že v  tomto případu použití vystupují dva aktéři: operátor, který přenáší data, a  systém záznamů o  pacientech. Notace se schematickými panáčky měla sice původně znázorňovat interakci osob, ale nyní umožňuje reprezentovat i jiné externí systémy a hardware. Diagramy případů použití by formálně měly používat čáry bez šipek, protože šipky v jazyce UML označují směr toku zpráv.V případech použití jsou zprávy samozřejmě přenášeny oběma směry. Šipky na obrázku 5.3 však neformálně umožňují označit, že transakci inicializuje nemocniční recepční a data se přenášejí do systému záznamů o pacientech. Nemocniční recepční Systém záznamů o pacientech

Přenos dat


Modely interakcí

Kapitola 5: Systémové modelování

123

Diagramy případů použití poskytují poměrně jednoduchý přehled o  interakci. Chceme-li tedy rozu

mět souvislostem, potřebujeme více podrobností. Tyto detaily mohou mít formu jednoduchého tex

tového popisu, strukturovaného popisu v tabulce nebo sekvenčního diagramu (viz následující rozbor).

Nejvhodnější formát můžeme zvolit v  závislosti na případu použití a  na úrovni podrobností, kterou

podle našeho názoru model vyžaduje. Podle názoru autora je nejužitečnější standardní tabulková forma.

Obrázek 5.4 představuje tabulkový popis případu použití „Přenos dat“.

Jak jsme zmínili v kapitole 4, složené diagramy případů použití znázorňují více různých případů použití.

Někdy lze do jediného složeného diagramu případů použití zahrnout všechny možné interakcev sys

tému. Jindy to však vzhledem k počtu případů použití nemusí být možné. V takových scénářích můžeme

vytvořit několik diagramů, z nichž každý představuje související případy použití. Obrázek 5.5 například

znázorňuje všechny případy použití v  systému MHC-PMS, na kterých se podílí aktér „Nemocniční

recepční“.

MHC-PMS: PŘENOS DAT

Aktéři Nemocniční recepční, systém záznamů o pacientech (PRS)

Popis Recepční může přenést data ze systému MHC-PMS do databáze univerzálního systému záznamů

o pacientech, který provozuje ministerstvo zdravotnictví. Přenášet lze buď aktualizované osobní

údaje (adresa, telefonní číslo atd.) nebo souhrnné informace o diagnóze a léčení pacienta.

Data Osobní údaje o pacientovi, souhrn léčby

Impuls Uživatelský příkaz zadaný nemocničním recepčním

Odpověď Potvrzení o aktualizaci systému PRS

Poznámky Recepční musí mít odpovídající bezpečnostní oprávnění pro přístup k informacím o pacientovi a do

systému PRS.

Obrázek 5.4 – Tabulkový popis případu použití „Přenos dat“

Obrázek 5.5 – Případy použití související s rolí „nemocniční recepční“

Nemocniční

recepční

Registrace

pacienta

Přenos dat

Kontaktování

pacienta

Zobrazení

informací

o pacientovi

Zrušení

registrace

pacienta


Modely interakcí

Část 1: Úvod do softwarového inženýrství

124

5.2.2 Sekvenční diagramy

Sekvenční diagramy v jazyce UML primárně slouží k modelování interakcí mezi aktéry a objektyv systému a  mezi samotnými objekty. Jazyk UML poskytuje bohatou syntaxi sekvenčních diagramů, díky

níž lze modelovat mnoho různých typů interakcí. Nemáme zde místo, abychom se zabývali všemimožnostmi, takže zůstaneme u základů tohoto typu diagramu.

Jak vyplývá z  názvu, sekvenční diagram znázorňuje pořadí interakcí, k  nimž dochází během určitého

případu použití nebo instance případu použití. Obrázek 5.6 představuje příklad sekvenčního diagramu,

z  něhož lze vysledovat základy příslušné notace. Tento diagram modeluje interakce, které se uplatňují

v případu použití Zobrazení pacienta, kdy může nemocniční recepční zobrazit některé údaje o pacientovi.

Zúčastněné objekty a aktéři jsou uvedeni v horní části diagramu a svisle od nich vede tečkovaná čára.

Interakci mezi objekty symbolizují šipky s popisky. Obdélník na tečkované čáře znamená životní čáru

dotčeného objektu (tj. čas, kdy se instance objektu účastní na výpočtu). Sekvenci interakcí lze číst shora

dolů. Poznámky na šipkách popisují volání objektů, jejich parametry a návratové hodnoty. V tomtopříkladu je také znázorněn zápis označující alternativy. Používá se rámeček s názvem „alt“ s podmínkami,

které jsou uzavřeny v hranatých závorkách.

Obrázek 5.6 lze číst takto:

1. Nemocniční recepční aktivuje metodu ZobrazInfo v instanci P třídy objektů PacientInfoa poskytne identifi kátor pacienta PID. P je objekt uživatelského rozhraní, který se zobrazuje jako formulář

s údaji o pacientovi. 2. Instance P zavolá databázi, která vrátí požadované informace. Přitom poskytne identifi kátorrecepčního, který umožní bezpečnostní kontrolu (v této fázi se nezajímáme o to, odkud tentoidentifi kátor UID pochází).

Obrázek 5.6 – Sekvenční diagram pro Zobrazení informací o pacientovi 3. Databáze pomocí autorizačního systému zkontroluje, zda je uživatel oprávněn provést danou akci.

P: PacientInfo

ZobrazInfo (PID)

Vykazuj

(Info, PID, UID)

Autorizuj

(Info, UID)

Údaje o pacientovi

D: MHCPMS-DB AS: Autorizace

Autorizace

Chyba

(nelze získat přístup)

[Autorizace OK]

[Neúspěšná autorizace]

Nemocniční recepční

Alt


Modely interakcí

Kapitola 5: Systémové modelování

125

4. Pokud ano, jsou vráceny informace o  pacientovi, které vyplní formulář na obrazovce uživatele.

Jestliže autorizace není úspěšná, zobrazí se chybová zpráva.

Obrázek 5.7 je dalším příkladem sekvenčního diagramu ze stejného systému, který ilustruje dvě další

funkce. Jedná se o přímou komunikaci mezi aktéry v systému a vytvoření objektů jako součást sekvence

operací. V tomto příkladu je vytvořen objekt typu Souhrn, který uchovává souhrnná data pro odeslání

do systému PRS (systému záznamů o pacientech). Tento diagram lze číst následovně:

1. Recepční se přihlásí do systému PRS.

2. K dispozici jsou dvě možnosti. Dovolují přímý přenos aktualizovaných údajů o pacientovi dosysté

mu PRS a přenos souhrnných zdravotních dat ze systému MHC-PMS do systému PRS.

3. V obou případech se pomocí autorizačního systému kontrolují oprávnění recepčního.

4. Osobní informace lze přenášet přímo z objektu uživatelského rozhraní do systému PRS. Případně

je možné vytvořit souhrnný záznam z databáze a následně přenést tento záznam.

5. Při dokončení přenosu vydá systém PRS stavovou zprávu a uživatel se odhlásí.

Obrázek 5.7: Sekvenční diagram pro přenos dat

Autorizace

Autorizuj (TF, UID)

P: PacientInfo

Přihlas ()

D: MHCPMS-DB AS: Autorizace

[OdešliInfo]

[OdešliSouhrn]

Nemocniční recepční

PRS

OK

AktualizujInfo ()

Aktualizuj PRS (UID)

Aktualizuj (PID)

Aktualizace OK

Zpráva (OK)

Shrň (UID)

Autorizace

Autorizuj (TF, UID)

:Souhrn

Aktualizuj (PID)

AktualizujSouhrn ()

Odhlas ()

Aktualizace OK

Zpráva (OK)

Alt


Strukturní modely

Část 1: Úvod do softwarového inženýrství

126

Pokud sekvenční diagramy neslouží ke generování kódu nebo k podrobnému dokumentování, nemusí

zahrnovat všechny interakce. Vyvíjíme-li na začátku vývojového procesu systémové modely, které

budou podporovat inženýrství požadavků a  vysokoúrovňový návrh, budou obsahovat mnoho interakcí, které závisí na volbách při implementaci. Například na obrázku 5.7 lze odložit rozhodnutí o tom,

jak se bude získávat identifikátor uživatele při kontrole autorizace. Při implementaci se může uplatnit

interakce s objektem Uživatel, ale v této fázi to není důležité, a proto to do sekvenčního diagramu není

nutné umístit.

OBJEKTOVĚ ORIENTOVANÁ ANALÝZA POŽADAVKŮ

Při objektově orientované analýze požadavků se entity reálného světa modelují pomocí objektových

tříd. Můžeme vytvářet různé typy objektových modelů, které ukazují, jak vzájemně souvisejí objektové

třídy, jak lze agregací objektů vytvářet jiné objekty, jak objekty interagují s  jinými objekty atd. Každý

z těchto modelů předkládá jedinečné informace o specifikovaném systému.

http://www.SoftwareEngineering-9.com/Web/OORA/ 5.3 Strukturní modely Strukturní modely softwaru znázorňují organizaci systému z hlediska komponent, které systém tvoří, a jejich vztahů. Strukturní modely mohou být statické, které představují strukturu návrhu systému, nebo dynamické, které ukazují organizaci systému při jeho činnosti. Jedná se o různé pohledy – dynamická organizace systému jako sady interagujících vláken se může značně lišit od statického modelusystémových komponent. Strukturní modely systému lze vytvořit během diskuse a návrhu systémové architektury. Návrharchitektury představuje zvláště důležité téma softwarového inženýrství. Při prezentaci modelů architektury lze použít diagramy komponent, balíčků a nasazení jazyka UML. Jednotlivými aspekty softwarovéarchitektury a modelování architektury se budeme zabývat v kapitolách 6, 18 a 19. V této části se zaměříme na použití diagramů tříd při modelování statické struktury objektových tříd v softwarovém systému. 5.3.1 Diagramy tříd Diagramy tříd se používají při vývoji objektově orientovaného modelu systému. Ukazují třídy v systému a  jejich asociace. Objektovou třídu si můžeme volně představit jako obecnou definici jednoho druhu systémového objektu. Asociace (přidružení) je vazba mezi třídami, která informuje o tom, že tyto třídy nějak souvisejí. Každá třída proto může mít určité informace o svých přidružených třídách. Při vývoji modelů během raných fází procesu softwarového inženýrství reprezentují objekty určité prvky reálného světa, jako je pacient, recept, lékař atd. Jak postupuje vývoj implementace, obvykle je nutné definovat její další objekty, které poskytují požadované funkce systému. Zde se soustředíme namodelování objektů reálného světa v rámci zpracování požadavků nebo procesů počátečních návrhů softwaru. Diagramy tříd v jazyce UML lze vyjádřit na různé úrovni podrobností. Když vyvíjíme model, v první fázi se obvykle podíváme do reálného světa, identifikujeme klíčové objekty a reprezentujeme je formou tříd. Nejjednodušší způsob, jak třídy znázornit, je zapsat jejich název do rámečku. Můžeme také jednoduše zaznamenat existenci přidružení tak, že mezi třídami nakreslíme čáru. Obrázek 5.8 například představuje jednoduchý diagram tříd, který znázorňuje dvě třídy: Pacient a Záznam o pacientovi, mezi nimiž existuje asociace.


Strukturní modely

Kapitola 5: Systémové modelování

127

Obrázek 5.8 – Třídy UML a jejich asociace

Obrázek 5.8 ilustruje další funkci diagramů tříd – schopnost znázornit, kolik objektů se na přidružení

podílí. V  tomto příkladu je každý konec přidružení označen číslem 1, což znamená, že mezi objekty

těchto tříd existuje vztah typu 1:1. To znamená, že každý pacient má přesně jeden záznam a  každý

záznam uchovává informace právě o jednom pacientovi. Jak je patrné z dalších příkladů, mohouexi

stovat i  jiné četnosti. Můžeme definovat, že se na vztahu podílí přesný počet objektů, nebo můžeme

symbolem * (viz obrázek 5.9) označit, že se na asociaci účastní neomezený počet objektů.

Obrázek 5.9 rozvíjí tento typ diagramu tříd a ukazuje, že objekty třídy Pacient se také podílejí na vztazích

s mnoha jinými třídami. Z tohoto příkladu je zřejmé, že přidružení lze pojmenovat, aby čtenáři grafu

získali představu o  typech existujících vztahů. Jazyk UML rovněž dovoluje specifikovat roli objektů,

které se na asociaci podílejí.

Na této úrovni podrobností vypadají diagramy tříd jako sémantické datové modely. Sémantické datové

modely se používají při návrhu databází. Znázorňují datové entity, jejich přidružené atributy a vztahy

mezi těmito entitami. Tento přístup k modelování poprvé navrhl v polovině 70. let Chen (1976). Od té

doby vzniklo několik variant (Codd, 1979; Hammer a McLeod, 1981; Hull a King, 1987), které sdílejí

stejnou základní formu.

Jazyk UML nezahrnuje konkrétní notaci pro toto databázové modelování, protože předpokládáobjek

tově orientovaný vývojový proces a modeluje data pomocí objektů a jejich vztahů. Pomocí jazyka UML

lze však reprezentovat i  sémantický datový model. Entity sémantického datového modelu si můžeme

představit jako zjednodušené objektové třídy (nemají žádné operace), atributy jako atributy objektové

třídy a vztahy jako pojmenovaná přidružení mezi objektovými třídami.

Obrázek 5.9 – Třídy a asociace v systému MHC-PMS

Pacient

Záznam

o pacientovi

11

Pacient

Praktický

lékař

Konzultace

Konzultant

Lék

Léčba

Nemocniční

lékař

Stav

Odkázal

Odkázán-na

Diagnostikován

-s čím

Účastní se

Předepisuje

Předepisuje

Runs

1..*

1

1..* 11..*

1..*

1..*

1..*

1..4

1..*

1..*

1..*

1..*


Strukturní modely

Část 1: Úvod do softwarového inženýrství

128

Obrázek 5.10 – Třída konzultace

Při znázorňování asociací mezi třídami je výhodné reprezentovat tyto třídy co nejjednoduššímzpůsobem. Chceme-li třídy definovat podrobněji, doplníme informace o jejich atributech (vlastnosti objektu)

a  operacích (činnostech, které od objektu požadujeme). Například objekt Pacient bude mít atribut

Adresa a můžeme k němu přidat i operaci označenou ZměňAdresu. Tato operace se bude volat, když

pacient oznámí, že se přestěhoval na jinou adresu. V jazyce UML se atributy a operace znázorňujírozšířením jednoduchého obdélníku, který označuje třídu. To je patrné na obrázku 5.10, kde:

1. Název objektové třídy je umístěn v horní části.

2. Atributy třídy jsou ve střední části. Nesmí zde chybět názvy atributů a volitelně mohou být uvedeny

jejich typy.

3. Operace (které se v jazyce Java a jiných objektově orientovaných programovacích jazycích nazývají

metody) přidružené k objektové třídě jsou v dolní části obdélníka.

Obrázek 5.10 znázorňuje možné atributy a operace třídy Konzultace. V tomto příkladu předpokládáme,

že lékaři nahrávají hlasové poznámky, které jsou později přepisovány za účelem zaznamenánípodrobností o  konzultaci. Při předepsání léku musí příslušný lékař použít metodu Předepiš, která generuje

elektronický recept.

5.3.2 Generalizace

Generalizace je běžná metoda, díky níž zvládáme složitost světa. Místo toho, abychom se seznamovali

s podrobnými vlastnostmi každé entity, se kterou se setkáváme, řadíme tyto entity do obecnějších tříd

(zvířata, auta, domy atd.) a učíme se vlastnosti těchto tříd. Díky tomu můžeme odvodit, že různí členové

těchto tříd mají některé společné vlastnosti (například veverky a krysy jsou hlodavci). Můžeme učinit

obecné závěry, které se vztahují na všechny členy třídy (například všichni hlodavci mají zuby, kterými

dokážou hlodat).

V  modelovacích systémech je často užitečné prozkoumat třídy v  systému a  vyhodnotit, zda neexistuje prostor pro jejich generalizaci. To znamená, že společné informace lze uchovávat jen na jednom

místě. Jedná se o vhodný návrhový postup, protože pokud jsou navrženy změny, není nutné kontrolovat

Konzultace

Lékaři

Datum

Čas

Klinika

Důvod

Předepsané léky

Předepsaná léčba

Hlasové poznámky

Přepis

...

Nové ()

Předepiš ()

ZaznamenejPoznámky ()

Přepiš ()

...


Strukturní modely

Kapitola 5: Systémové modelování

129

všechny třídy v systému, zda na ně příslušná změna bude mít vliv. V objektově orientovaných jazycích,

jako je Java, se generalizace implementuje pomocí mechanismů dědění tříd, které jsou součástí jazyka.

Obrázek 5.11 – Hierarchie generalizace

Jazyk UML má konkrétní typ asociace, který označuje generalizaci (viz obrázek 5.11). Generalizace se

znázorňuje pomocí šipky, která směřuje k obecnější třídě. Z toho je zřejmé, že praktické lékařea nemoc

niční lékaře lze zobecnit jako lékaře a že existují tři typy nemocničních lékařů – ti, kteří nedávnoabsol

vovali lékařskou fakultu a  je nutné na ně dohlížet (zaučující se lékař), ti, kteří mohou pracovat bez

dozoru v rámci konzultačního týmu (registrovaný lékař), a konzultanti, což jsou zkušení lékaři s plnými

rozhodovacími pravomocemi.

Obrázek 5.12 – Hierarchie generalizace s doplněnými podrobnostmi

Při generalizaci se atributy a operace přidružené ke třídám vyšší úrovně přidružují také ke třídám nižší

úrovně. Třídy nižší úrovně jsou v zásadě podtřídami, které dědí atributy a operace od svých nadtříd. Tyto

třídy nižší úrovně pak doplňují konkrétnější atributy a  operace. Například všichni lékaři mají jméno

a telefonní číslo. Všichni nemocniční lékaři mají zaměstnanecké číslo a oddělení, kde jsou zaměstnáni,

Lékař

Praktický

lékař

Nemocniční

lékař

Konzultant Týmový lékař

Zaučující se

lékař

Kvalifikovaný

lékař

Lékař

Jméno

Telefonní číslo

E-mail

Registruj ()

Zruš registraci ()

Nemocniční lékař

Zaměstnanecké

číslo

Číslo pageru

Praktický lékař

Praxe

Adresa


Behaviorální modely

Část 1: Úvod do softwarového inženýrství

130

ale praktičtí lékaři tyto atributy nemají, protože pracují samostatně. Místo toho však používají název

a adresu své praxe. To je patrné na obrázku 5.12, který znázorňuje část hierarchie generalizace, kterou

jsme doplnili o atributy tříd. Operace přidružené ke třídě Lékař mají zajistit registraci a zrušeníregistrace daného lékaře v systému MHC-PMS.

5.3.3 Agregace

Objekty reálného světa se často skládají z různých částí. Například studijní materiály ke kurzu mohou

zahrnovat knihu, prezentace PowerPoint, testy a doporučení další literatury. Někdy je potřeba zajistit,

aby model systému toto složení dokumentoval. Jazyk UML poskytuje speciální typ přidružení třídoznačovaný jako agregace. Znamená, že jeden objekt (celek) se skládá z jiných objektů (částí). Při znázornění

používáme kosočtverec vedle třídy, která reprezentuje celek. To je patrné na obrázku 5.13, kterýznázorňuje, že záznam o pacientovi obsahuje položku Pacient a neomezený počet Konzultací.

5.4 Behaviorální modely

Behaviorální modely znázorňují dynamické chování systému při jeho činnosti. Ukazují, co se děje nebo

má dít, když systém reaguje na impulsy ze svého prostředí. Tyto stimuly můžeme zařadit do dvou typů:

1. Data – doručována jsou určitá data, která musí systém zpracovat.

2. Události – nastávají jisté události, které aktivují systémové zpracování. Události mohou mítpřidružena data, ale neplatí to vždy.

Obrázek 5.13 – Přidružení typu agregace

DIAGRAMY DATOVÉHO TOKU

Diagramy datového toku (DFD – data-flow diagram) jsou systémové modely, které znázorňují funkční

perspektivu, kde každá transformace reprezentuje jedinou funkci nebo proces. Tyto diagramy umožňují znázornit, jak data postupují sekvencí kroků svého zpracování. Krokem zpracování může být

například odfiltrování duplicitních záznamů z  databáze zákazníků. Data se v  každém kroku transformují a následně postupují do další fáze. Tyto kroky či transformace zpracování reprezentují softwarové

procesy či funkce, kdy lze pomocí diagramů datového toku dokumentovat návrh softwaru.

http://www.SoftwareEngineering-9.com/Web/DFDs Mnoho podnikových systémů patří mezi systémy zpracování dat, které primárně slouží k  manipulaci s daty. Jsou řízeny vstupem dat do systému a poměrně v malé míře jsou řízeny zpracováním externích událostí. Zpracování v  tomto případě zahrnuje sekvenci akcí s  daty a  generování výstupu. Například systém účtování telefonních služeb přijímá informace o voláních, která zákazník uskutečnil, počítá cenu těchto volání a generuje fakturu, která bude příslušnému zákazníkovi odeslána. Oproti tomu systémy

Záznam

o pacientovi

Pacient Konzultace

11

1 1..*


Behaviorální modely

Kapitola 5: Systémové modelování

131

fungující v reálném čase jsou často řízeny událostmi a pouze minimálně zpracovávají data. Například

systém ústředny pro pevnou telefonní síť reaguje na různé události – například na zvednuté sluchátko

generováním oznamovacího tónu nebo na stisknutí tlačítek telefonu zaznamenáním telefonního čísla.

5.4.1 Modelování řízené daty

Modely řízené daty znázorňují sekvenci akcí, které se podílejí na zpracování vstupních dat a generování

příslušného výstupu. Hodí se zejména k analýze požadavků, protože umožňují vizualizovat kompletní

postup zpracování v  systému. To znamená, že ukazují celou sekvenci akcí, která probíhá od příjmu

vstupu po generování odpovídajícího výstupu, který představuje odpověď systému.

Modely řízené daty patřily mezi první grafické softwarové modely. V 70. letech byly v rámcistrukturo

vaných metod, jako je DeMarcova strukturovaná analýza (DeMarco, 1978), zavedeny diagramy dato

vého toku (DFD), které umožňovaly ilustrovat kroky zpracování v systému. Modely datového toku jsou

užitečné, protože sledování a dokumentování toho, jak data související s určitým procesem procházejí

systémem, pomáhá analytikům a návrhářům porozumět fungování systému. Diagramy datového toku

jsou jednoduché a  intuitivní a  obvykle je lze vysvětlit potenciálním uživatelům systému, kteří se pak

mohou účastnit na validaci modelu.

Jazyk UML neposkytuje podporu diagramů datového toku, protože byly původně navrženy a použí

valy se k modelování zpracování dat. Důvod spočívá v tom, že diagramy datového toku se zaměřují na

systémové funkce a nerozpoznávají systémové objekty. Vzhledem k tomu, že systémy řízené daty jsou

v podnicích velmi běžné, však jazyk UML 2.0 zavedl diagramy aktivity, které se podobají diagramům

datového toku. Například obrázek 5.14 znázorňuje řetězec akcí zpracování, který se uplatňuje u soft

waru inzulínové pumpy. Na tomto diagramu jsou patrné kroky zpracování (reprezentované jakoakti

vity) a data směřující mezi těmito kroky (reprezentovaná jako objekty).

Obrázek 5.14 – Model aktivity fungování inzulínové pumpy

Alternativní způsob znázornění sekvence zpracování v systému využívá sekvenční diagramy UML. Již

jsme viděli, jak lze tyto diagramy uplatnit při modelování interakcí. Pokud je však nakreslíme tak, aby

zprávy proudily pouze zleva doprava, pak znázorňují sekvenční zpracování dat v systému. To je patrné

na obrázku 5.15, kde se používá sekvenční model zpracování objednávky a  jejího odeslání dodava

teli. Sekvenční modely se zaměřují na objekty v systému, zatímco diagramy datového toku zvýrazňují

funkce. Odpovídající diagram datového toku pro zpracování objednávky je k  dispozici na webových

stránkách knihy.

Senzor cukru

v krvi

Hladina cukru

v krvi

Požadavky

na inzulín

Příkazy na

řízení pumpy

Inzulínová

pumpa

Načtení hodnoty

senzoru

Výpočet

příkazů na řízení

pumpy

Data

senzoru

Výpočet

hladiny cukru

Výpočet

dávky

inzulínu

Řízení

pumpy




       
Knihkupectví Knihy.ABZ.cz - online prodej | ABZ Knihy, a.s.
ABZ knihy, a.s.
 
 
 

Knihy.ABZ.cz - knihkupectví online -  © 2004-2018 - ABZ ABZ knihy, a.s. TOPlist