ávrh informa ního systému pro bezpe nostní agenturu

(1)

TECH ICKÁ U IVERZITA V LIBERCI

Fakulta mechatroniky, informatiky a mezioborových studií

Studijní program: N2612 – Elektrotechnika a informatika Studijní obor: Informa&ní technologie

ávrh informa ního systému pro bezpe nostní agenturu

Design of Information System for Security Agency

Diplomová práce

Autor: Bc. Martin Vitouš

Vedoucí práce: doc. Ing. Ji-ina Královcová, Ph.D.

Konzultant: Ing. Miloš Hernych

V Liberci 29. 5. 2009

(2)

2

Zadání

(3)

3

Prohlášení

Byl jsem seznámen s tím, že na mou diplomovou práci se pln6 vztahuje zákon &. 121/2000 o právu autorském, zejména § 60 (školní dílo).

Beru na v6domí, že TUL má právo na uzav-ení licen&ní smlouvy o užití mé diplomové práce a prohlašuji, že s o u h l a s í m s p-ípadným užitím mé diplomové práce (prodej, zap@j&ení apod.).

Jsem si v6dom toho, že užít své diplomové práce &i poskytnout licenci k jejímu využití mohu jen se souhlasem TUL, která má právo ode mne požadovat p-im6-ený p-ísp6vek na úhradu náklad@, vynaložených univerzitou na vytvo-ení díla (až do jejich skute&né výše).

Diplomovou práci jsem vypracoval samostatn6 s použitím uvedené literatury a na základ6 konzultací s vedoucím diplomové práce a konzultantem.

Datum 29.5.2009

Podpis

(4)

4

Pod4kování

Rád bych pod6koval vedoucí mé diplomové práce doc. Ji-in6 Královcové za vedení a za konzultace.

(5)

5

Abstrakt

Tato zpráva popisuje návrh informa&ního systému pro bezpe&nostní agenturu. Primárním cílem práce bylo navrhnout protokol pro komunikaci mezi centrálou bezpe&nostní agentury a bezpe&nostními úst-ednami nainstalovanými v jednotlivých hlídaných objektech.

Sekundárním cílem bylo správn6 navrhnout informa&ní systém podle metodiky popsané René Steinem, využívající UML diagramy a textové popisy k t6mto diagram@m. Sou&ástí práce je i popis realizace celého informa&ního systému v&etn6 komunikace s bezpe&nostními úst-ednami. Vlastní realizace již ovšem není sou&ástí práce.

Celá zpráva je rozd6lena do p6ti kapitol. V první kapitole je popsána architektura celého informa&ního systému, který je pro v6tší p-ehlednost rozd6len na vn6jší a vnit-ní &ást, každá z nich je zde popsána zvlášH. Ve druhé kapitole jsou popsány technologie použité pro návrh a realizaci informa&ního systému. Jsou to p-evážn6 technologie od spole&nosti Microsoft, neboH autor práce je certifikovaný pro vývoj aplikací za použití t6chto technologií a má s nimi již n6kolikaletou zkušenost. Ve t-etí kapitole je obsažen návrh protokolu pro komunikaci mezi centrálou bezpe&nostní agentury a bezpe&nostními úst-ednami. Jsou zde uvedeny požadavky na tuto komunikaci, popis komunikace, typy zpráv a schéma šifrování.

Ve &tvrté a zároveI nejdelší kapitole je popsán návrh informa&ního systému zpracovávajícího zprávy p-ijaté z bezpe&nostních úst-eden a poskytující další služby zákazník@m a pracovník@m bezpe&nostní agentury. Nejprve jsou zde popsány jednotlivé role v systému, následn6 je zde diagram popisující jednotlivé p-ípady užití v systému a podrobný popis t6chto p-ípad@. Následují návrhy jednotlivých vrstev informa&ního systému, které podrobn6 popisují t-ídy použité pro zpracování dat a tabulky pro jejich uložení v databázi.

V poslední páté kapitole je popsána realizace jednotlivých &ásti informa&ního systému. Dále je zde nastín6no použití informa&ního systému pro jednotlivé role uživatel@ a jeho srovnání s návrhem.

Klí&ová slova: informa&ní systém, bezpe&nostní agentura, business analýza, softwarový design

(6)

6

Abstract

This report describes a design of information system for security agency. The primary objective of this work was to design a protocol for communication between the central of the security agency and security board installed in the guarded premises. Secondary objective was to correctly design an information system according to the methodology described by René Stein, using UML diagrams and text descriptions of these diagrams. This work includes a description of the implementation of the entire information system, including communications with the security boards. The implementation is not part of the work.

Full report is divided into five chapters. In the first chapter there is a description of the architecture of the entire information system, which is for greater clarity divided into inner and outer part, each of which is described here separately. The second chapter describes techniques used for designing and implementing an information system. They are predominantly technologies from Microsoft, because the author of the work is certified for the development of applications using these technologies and has many years of experience with them. The third chapter contains the design of protocol for communication between the central of the security agency and security boards. There are listed the requirements for this communication, a description of communication, message types and encryption scheme.

The fourth and longest chapter describes the design of an information system processing messages received from the security boards and providing services for customers and employees of the security agency. At first, there is description of roles in the system and then there is a diagram describing the use cases in the system and a detailed description of these use cases. It is followed by design of various layers of information system, a detail description of the data-processing and data-storage in the database.

The last fifth chapter describes the implementation of each part of the information system.

There are also outlined the uses of the information system for individual user roles compared with the design.

Keywords: information system, security agency, business analysis, software design

(7)

7

Obsah

Seznam obrázk@ ... 9

Seznam tabulek ... 10

Úvod ... 12

1. Architektura informa&ního systému ... 13

1.1 Vn6jší &ást informa&ního systému ... 13

1.2 Vnit-ní &ást informa&ního systému ... 14

2. Technologie pro návrh a realizaci informa&ního systému ... 16

2.1 Platforma opera&ního systému – Microsoft Windows ... 16

2.2 B6hové prost-edí – Microsoft .NET Framework ... 16

2.3 Webový server – Microsoft IIS (Internet Information Services)... 16

2.4 Databázový server – Microsoft SQL Server ... 16

2.5 Vývojové prost-edí – Microsoft Visual Studio ... 17

2.6 Programovací jazyk – C# ... 17

2.7 Jazyk pro psaní webových stránek – ASP.NET ... 17

2.8 Struktura webové stránky – ASP.NET MVC (Model-View-Controler) ... 17

2.9 Objektov6-rela&ní mapper – LINQ to SQL ... 18

3. Komunikace mezi centrálou a bezpe&nostními úst-ednami ... 19

3.1 Požadavky na komunikaci ... 19

3.2 Návrh komunikace ... 19

3.3 Typy zpráv ... 20

3.4 Použité šifrování ... 20

4. Návrh informa&ního systému ... 21

4.1 Uživatelské role v systému ... 21

4.2 Use Case diagram ... 22

4.3 Business analýza ... 24

4.4 Systémový design – Diagram t-íd ... 37

(8)

8

4.5 Systémový design – Stavový diagram ... 39

4.6 Systémový design – Textový popis t-íd ... 41

4.7 Návrh databázové vrstvy – ER diagram ... 46

4.8 Návrh vrstvy pro p-ístup k dat@m... 47

5. Realizace informa&ního systému ... 48

5.1 Použití systému pro roli Zákazník ... 48

5.2 Použití systému pro roli Dispe&er ... 52

5.3 Použití systému pro roli Technik (Ostraha) ... 53

Záv6r... 55

Bibliografie ... 56

(9)

9

Seznam obrázk7

Obrázek 1 - Schéma vn6jší &ásti informa&ního systému ... 13

Obrázek 2 - Schéma vnit-ní &ásti informa&ního systému ... 15

Obrázek 3 - Schéma šifrování a dešifrování ... 20

Obrázek 4 - Use Case diagram neboli diagram p-ípad@ užití... 23

Obrázek 5 - Diagram t-íd ... 38

Obrázek 6 - Stavový diagram ... 40

Obrázek 7 - ER diagram ... 46

Obrázek 8 - Návrh LINQ to SQL ... 47

Obrázek 9 - Titulní stránka aplikace ... 48

Obrázek 10 - Registrace zákazníka ... 49

Obrázek 11 - P-idání hlídaného objektu ... 50

Obrázek 12 - Seznam hlídaných objekt@... 51

Obrázek 13 - Zobrazení hlídaného objektu ... 51

Obrázek 14 - P-ihlášení do systému ... 52

Obrázek 15 - Seznam úkol@ ... 52

Obrázek 16 - P-id6lení hlídaného objektu ... 53

Obrázek 17 - Potvrzení spln6ní úkolu ... 54

(10)

10

Seznam tabulek

Tabulka 1 - Akto-i pro Use Case 1 – Zobrazení informací ... 25

Tabulka 2 - Akto-i pro Use Case 2 – Nastavení osobních údaj@ ... 26

Tabulka 3 - Akto-i pro Use Case 3 – Registrace ... 27

Tabulka 4 – Akto-i pro Use Case 4 – Editace osobních údaj@... 27

Tabulka 5 - Akto-i pro Use Case 5 – Zobrazení seznamu hlídaných objekt@... 28

Tabulka 6 - Akto-i pro Use Case 6 – Nastavení vlastností hlídaného objektu ... 29

Tabulka 7 - Akto-i pro Use Case 7 – P-idání hlídaného objektu ... 30

Tabulka 8 - Akto-i pro Use Case 8 – Editace hlídaného objektu ... 30

Tabulka 9 - Akto-i pro Use Case 9 – Zrušení hlídaného objektu ... 31

Tabulka 10 - Akto-i pro Use Case 10 – Zobrazení hlídaného objektu ... 31

Tabulka 11 - Akto-i pro Use Case 12 – P-id6lení hlídaného objektu... 33

Tabulka 12 - Akto-i pro Use Case 13 – Zamítnutí hlídaného objektu ... 33

Tabulka 13 - Akto-i pro Use Case 14 – Seznam úkol@... 34

Tabulka 14 - Akto-i pro Use Case 16 – Potvrzení spln6ní úkolu ... 36

Tabulka 15 - Akto-i pro Use Case 17 – P-ijetí zprávy ... 36

Tabulka 16 - Atributy t-ídy User ... 41

Tabulka 17 - Statické metody t-ídy User ... 41

Tabulka 18 - Abstraktní metody t-ídy User ... 41

Tabulka 19 - Metody t-ídy User ... 41

Tabulka 20 - Atributy t-ídy Customer ... 42

Tabulka 21 - Konstruktor t-ídy Customer ... 42

Tabulka 22 - Implementace abstraktních metod t-ídy Customer ... 42

Tabulka 23 - Metody t-ídy Customer ... 42

Tabulka 24 - Atributy t-ídy Employee ... 42

Tabulka 25 - Abstraktní metody t-ídy Employee ... 42

Tabulka 26 - Implementace abstraktních metod t-ídy Operator... 43

Tabulka 27 - Implementace abstraktních metod t-ídy TerrainEmployee ... 43

Tabulka 28 - Atributy t-ídy SecurityObject ... 43

Tabulka 29 - Konstruktor t-ídy SecurityObject ... 43

Tabulka 30 - Statické metody t-ídy SecurityObject ... 43

Tabulka 31 - Metody t-ídy SecurityObject ... 44

Tabulka 32 - Atributy t-ídy Branch ... 44

(11)

11

Tabulka 33 - Statické metody t-ídy Branch... 44

Tabulka 34 - Metody t-ídy Branch ... 44

Tabulka 35 - Atributy t-ídy Task ... 44

Tabulka 36 - Statické metody t-ídy Task ... 44

Tabulka 37 - Metody t-ídy Task ... 45

Tabulka 38 - Atributy t-ídy Message ... 45

Tabulka 39 - Konstruktor t-ídy Message ... 45

Tabulka 40 - Statické metody t-ídy Message ... 45

Tabulka 41 - Metody t-ídy Message ... 45

(12)

12

Úvod

Celá tato práce se zabývá problematikou návrhu informa&ního systému pro bezpe&nostní agenturu. V tomto oboru je d@ležité znát v každém okamžiku stav hlídaných objekt@. Ke zjišHování tohoto stavu musí bezpe&nostní úst-edny v jednotlivých hlídaných objektech komunikovat s centrálou.

Tato práce má dva hlavní cíle jedním z nich je navrhnout a realizovat komunikaci mezi centrálou a bezpe&nostními úst-ednami a druhým je podrobn6 navrhnout informa&ní systém zpracovávající data z bezpe&nostních úst-eden a umožIující provád6t další operace, pot-ebné k chodu bezpe&nostní agentury.

První cíl byl stanoven na základ6 požadavk@ firmy A2D z Liberce. Ta požaduje navrhnout protokol pro komunikaci pomocí protokolu IP mezi centrálním po&íta&em s opera&ním systémem Windows a bezpe&nostními úst-ednami Siemens Sintony 60 – IC 60. Tato firma zajišHuje hardwarové napojení úst-eden na Internet a implementaci navrženého protokolu do úst-eden. Jednotlivé požadavky na komunikaci, stejn6 jako návrh samotné komunikace je uveden v kapitole 3.

Druhým a zároveI hlavním cílem této práce je navrhnout informa&ní systém zpracovávající informace získané z bezpe&nostních úst-eden a jsou k n6mu p-idány další požadavky, které by podle autora této práce mohla mít bezpe&nostní agentura na sv@j informa&ní systém. Autor zde dává d@raz hlavn6 na velmi podrobný návrh systému. Chce zde ukázat, jak by se správn6 m6ly navrhovat informa&ní systémy. Postupuje p-itom podle metodologie navržené René Steinem (Stein, 2009). Zatímco v praxi by se n6které &ásti tohoto návrhu konzultovali se zákazníkem, tato první verze systému zatím žádného zákazníka nemá, ale je možné, že ho bude mít v budoucnu a systém se bude dále vyvíjet podle jeho konkrétních požadavk@.

Celý informa&ní systém je v rámci této práce realizován, ale je zde po&ítáno s tím, že pokud by m6l být nasazen v praxi, je pot-eba provést ješt6 další úpravy jak v návrhu, tak i v realizaci.

Tyto úpravy by již byly provád6ny podle požadavk@ zákazníka.

(13)

13

1. Architektura informa ního systému

Architekturou informa&ního systému budeme chápat seznam a rozložení jednotlivých prvk@

systému a vazeb mezi nimi. Obvykle by sem pat-ily ješt6 hardwarové a softwarové požadavky na po&íta&e v systému, ale to v našem p-ípad6 zanedbáme.

Celý systém rozložíme na dv6 &ásti. Vn6jší &ástí budeme rozum6t prvky mimo bezpe&nostní agenturu a vnit-ní &ástí prvky uvnit- bezpe&nostní agentury. Zatímco ve vnit-ní &ásti jsou prvky propojeny pomocí vnit-ní sít6 (nebo i v rámci jednoho po&íta&e), ve vn6jší &ásti je spojovacím prvkem Internet, to se týká i p-ipojení k vnit-ní &ásti.

1.1 Vn4jší ást informa ního systému

Vn6jší &ást informa&ního systému (viz Obrázek 1) obsahuje pracovníky v terénu, zákazníky a hlídané objekty. Na schématu je uvedena i bezpe&nostní agentura, která reprezentuje vnit-ní

&ást informa&ního systému.

Obrázek 1 - Schéma vn4jší ásti informa ního systému

(14)

14 Pracovník v terénu

Pod tímto pojmem myslíme techniky a ostrahu, kte-í vyjížd6jí do hlídaných objekt@ provád6t

&innosti jako instalaci a deinstalaci bezpe&nostních úst-eden, opravy poruch a zásahy p-i narušení bezpe&nosti. Tito p-istupují do informa&ního systému pomocí webového rozhraní na svých p-enosných po&íta&ích.

Zákazník

Pod tímto pojmem myslíme zákazníky, kte-í se již registrovali do systému a také potenciální zákazníky, kte-í se možná v budoucnu zaregistrují a budou využívat služeb bezpe&nostní agentury. Ob6 tyto skupiny p-istupují do systému p-es webové rozhraní.

Hlídaný objekt

Tímto pojmem rozumíme budovu nebo &ást budovy, která je hlídána bezpe&nostní agenturou, je zde nainstalována bezpe&nostní úst-edna a ta komunikuje s bezpe&nostní agenturou pomocí pro tento ú&el navrženého protokolu (viz Komunikace mezi centrálou a bezpe&nostními úst-ednami).

1.2 Vnit=ní ást informa ního systému

Vnit-ní &ást informa&ního systému (viz Obrázek 2) obsahuje webovou aplikaci, databázi, Windows službu a pracovníky v bezpe&nostní agentu-e.

Webová aplikace

Komunikuje s jednotlivými uživateli informa&ního systému, informuje je na základ6 dat uložených v databázi a tato data podle jejich p-íkaz@ m6ní.

Databáze

Slouží jako úložišt6 dat pro informa&ní systém, komunikuje s webovou aplikací a Windows službou

Windows služba

Komunikuje s bezpe&nostními úst-ednami a na základ6 této komunikace ukládá do databáze aktuální stav hlídaných objekt@.

(15)

15

Obrázek 2 - Schéma vnit=ní ásti informa ního systému

Pracovník v agentu=e

Pod tímto pojmem myslíme dispe&ery, kte-í sledují stav hlídaných objekt@ a v p-ípad6 pot-eby p-id6lují objekty technik@m nebo ostraze. P-istupují do informa&ního systému pomocí webového rozhraní.

(16)

16

2. Technologie pro návrh a realizaci informa ního systému

Pokud chceme navrhovat a realizovat informa&ní systém, musíme si uv6domit, jaké technologie k tomu budeme využívat, aH už se jedná o platformu opera&ního systému, b6hové prost-edí, webový a databázový server, vývojové prost-edí, programovací jazyk a další používané technologie.

2.1 Platforma opera ního systému – Microsoft Windows

Jádro informa&ního systému (webová aplikace, databáze a Windows služba) pob6ží na n6kterém z -ady opera&ních systém@ Windows. Pravd6podobn6 to bude n6která ze serverových verzí, nap-. Windows Server 2008. M@že to ovšem být i n6která klientská verze v p-ípad6, že bezpe&nostní agentura nebude po&ítat s velkým množstvím klient@ a nebude chtít velké po&áte&ní investice. Uživatelé systému (pracovník v agentu-e, pracovník v terénu a zákazník), p-istupující do systému p-es webové rozhraní mohou pracovat i na jiném opera&ním systému.

2.2 B4hové prost=edí – Microsoft . ET Framework

V dnešní dob6 je b6žné, že aplikace pot-ebují ke svému spušt6ní nejen opera&ní systém, ale také takzvané b6hové prost-edí, které aplikacím nabízí spoušt6cí rozhraní a pot-ebné knihovny. V našem p-ípad6 to bude Microsoft .NET Framework verze 3.5, které bude pot-eba ke spušt6ní jak webové aplikace tak i Windows služby.

2.3 Webový server – Microsoft IIS (Internet Information Services)

Každá webová aplikace pot-ebuje ke svému b6hu takzvaný webový server. Jedná se o aplikaci, která p-ijme požadavek od klienta pomocí http protokolu a na základ6 n6j vybere p-íslušnou &ást webové aplikace (webovou stránku), zpracuje ji a výsledek op6t pomocí http protokolu odesílá zp6t klientovi. V našem p-ípad6 použijeme jako webový server aplikaci Microsoft IIS verze 7, která je sou&ástí Windows.

2.4 Databázový server – Microsoft SQL Server

Jelikož informa&ní systém je aplikace v6tšího rozsahu a m@že ji používat najednou více uživatel@, je nutné pro uchovávání dat místo prostého souboru použít databázi na databázovém serveru, který bude -ídit p-ístup uživatel@ k dat@m v databázi. V našem p-ípad6

(17)

17 použijeme Microsoft SQL Server 2008. Pro menší bezpe&nostní agenturu posta&í verze Express, která je zdarma, pro v6tší je možno použít nap-íklad verzi Standard &i Enterprise.

2.5 Vývojové prost=edí – Microsoft Visual Studio

Abychom mohli naprogramovat informa&ní systém, je nejlepší použít integrované vývojové prost-edí obsahující textový editor s množstvím funkcí jako doplIování a zvýrazIování syntaxe, kompilátor, debugger, správu projekt@ a další užite&né v6ci. Jelikož jsme se rozhodli pro tvorbu informa&ního systému postaveného na technologiích od spole&nosti Microsoft, bude nejvhodn6jší sáhnout i po vývojovém prost-edí od stejné spole&nosti. Proto použijeme Microsoft Visual Studio 2008. I zde nejspíše sáhneme po verzi Express, která je zdarma, ale máme na výb6r i z dalších verzí jako Standard, Professional nebo Team System.

2.6 Programovací jazyk – C#

Abychom mohli realizovat informa&ní systém, musíme vybrat jeden nebo více programovacích jazyk@, pomocí nichž tuto realizaci provedeme. Protože náš informa&ní systém využívá .NET Framework, musíme zvolit jeden z jazyk@, který je tímto prost-edím podporován. Nej&ast6ji používané jsou C# a Visual Basic. Vybereme si první z nich ve verzi 3.0, která je p-ítomna ve vybrané verzi b6hového prost-edí.

2.7 Jazyk pro psaní webových stránek – ASP. ET

Protože náš informa&ní systém má mít webové rozhraní, je nutné najít jazyk, ve kterém by bylo možno psát webové stránky. Nesta&í nám klasické HTML, protože tyto stránky by m6ly být dynamické a vypisovat data podle požadavku uživatel@. P-ímo se nám nabízí jazyk ASP.NET, který je sou&ástí .NET Framework.

2.8 Struktura webové stránky – ASP. ET MVC (Model-View-Controler) Máme již zvolen jazyk ASP.NET pro tvorbu webových stránek, ale nyní nám vyvstává dilema, jakou strukturu stránek použít, neboH tento jazyk nabízí dv6 varianty. Starší WebForms p-ipomínají tvorbu Windows aplikací, m@žeme zde používat podobné ovládací prvky jako ve Windows. Nevýhodou této varianty je nutnost uchovávání stavu (kontextu).

Proto zvolíme druhou variantu MVC neboli Model-View-Controler. Tento návrhový vzor je již starší, ale spole&nost Microsoft ho p-idala do ASP.NET teprve v nedávné dob6.

(18)

18 Princip této struktury spo&ívá v tom, že existuje ur&ité množství -adi&@ (controler), které mají ur&ité metody. Uživatel namísto klasické webové adresy obsahující jméno souboru s webovou stránkou, zadá adresu obsahující název -adi&e, název metody a p-ípadn6 parametry a systém p-edá -ízení -adi&i a ten provede požadovanou metodu, a pokud tato má n6jaký výstup, zobrazí pohled (view). Pro práci s daty se zde používá takzvaný model, což m@že být skupina t-íd obsahujících data.

2.9 Objektov4-rela ní mapper – LI Q to SQL

Abychom v informa&ním systému nemuseli pracovat p-ímo s rela&ními daty, která jsou uložena v databázi, pomocí SQL p-íkaz@, použijeme takzvaný objektov6-rela&ní mapper, který nám tabulky v databázi namapuje na datové objekty, a s t6mi již m@žeme normáln6 pracovat. V našem p-ípad6 použijeme LINQ to SQL, protože je p-ímo sou&ástí prost-edí .NET Framework a je jednoduchý na použití. K získávání datových objekt@ z databáze používáme dotazovací jazyk LINQ, který je p-ímo integrovaný do jednotlivých jazyk@ v prost-edí .NET Framework.

(19)

19

3. Komunikace mezi centrálou a bezpe nostními úst=ednami

D@ležitým prvkem celého informa&ního systému je komunikace mezi centrálou a bezpe&nostními úst-ednami. Pomocí této komunikace se pracovníci bezpe&nostní agentury dozvídají aktuální stav bezpe&nostních úst-eden a celých hlídaných objekt@.

3.1 Požadavky na komunikaci

Komunikace mezi centrálou a bezpe&nostními úst-ednami musí splIovat následující požadavky:

1) Musí být uskute&n6na pomocí protokolu IP (bude vedena p-es Internet).

2) Musí být p-i ní možné jednozna&n6 identifikovat odesilatele zpráv (aby se p-edešlo zahlcení centrály falešnými zprávami a jiným falešným vysíláním).

3) Musí využívat pouze jednoduché zprávy a šifrování (viz dále).

3.2 ávrh komunikace

Komunikace bude probíhat pomocí protokolu TCP, což je transportní protokol nad síHovým protokolem IP. Tento protokol používáme proto, že je nutné navázat spojení což pomocí protokolu UDP nelze. Komunikace bude vždy za&ínat na stran6 bezpe&nostní úst-edny. Ta bude znát ve-ejnou adresu centrály, ale sama mít ve-ejnou adresu nemusí. Celá komunikace probíhá ve 3 krocích:

1) Úst-edna odešle svoji identifikaci centrále zašifrovanou spole&ným klí&em.

2) Centrála ur&í totožnost úst-edny a odešle ji jednorázový klí& pro zašifrování zprávy zašifrovaný specifickým klí&em úst-edny.

3) Úst-edna vytvo-í zprávu a pro kontrolu k ní ješt6 p-idá svou identifikaci, to celé zašifruje obdrženým jednorázovým klí&em a odešle centrále.

P-itom velikost jednotlivých klí&@ je sedm byt@ a velikost identifikace bezpe&nostních úst-eden je deset byt@.

(20)

20 3.3 Typy zpráv

Bezpe&nostní úst-edna m@že poslat následující typy zpráv:

1) Vše v po-ádku – bezpe&nostní úst-edna pracuje správn6 a nehlásí žádné narušení 2) Poplach – bezpe&nostní úst-edna hlásí narušení bezpe&nosti

3) Porucha – bezpe&nostní úst-edna nepracuje správn6

3.4 Použité šifrování

Pro šifrování bylo použito blokové schéma dle požadavk@ zadávající firmy (viz Obrázek 3) (Papouch s.r.o, 2004).

Obrázek 3 - Schéma šifrování a dešifrování

Jedná se o symetrickou šifru, která se -adí do skupiny blokových šifer. Jako p-edloha pro tvorbu šifrovacího algoritmu je použito blokové šifrování v módu CFB. Šifrování zprávy se provádí tak, že na za&átku použijeme inicializa&ní vektor (pevn6 zvolené &íslo) k zašifrování (XOR) prvního bloku dat otev-eného textu. Výsledek tohoto šifrování se dále šifruje (XOR) s jednotlivými znaky klí&e. Tím vznikne sedm r@zných mezivýsledk@, které se šifrují (XOR) v jeden jediný. Výsledek se použije jako šifrovaná data a také k šifrování dalšího otev-eného textu. IV je inicializa&ní vektor, OT1 a OT2 jsou první a druhý blok otev-eného textu, ŠT1 a ŠT2 jsou dva bloky šifrovaného textu; K1 – K7 jsou jednotlivé znaky klí&e.

(21)

21

4. ávrh informa ního systému

Pokud navrhujeme informa&ní systém, je velmi d@ležité si podrobn6 rozmyslet, jaké všechny funkce má systém splIovat, jaké v n6m budou role a co bude moci každá z rolí v systému d6lat. Nejprve si navrhneme a popíšeme jednotlivé role v našem informa&ním systému. Dále si navrhneme diagram p-ípad@ užití (neboli Use Case diagram), ve kterém jsou vid6t role a co m@že která role v systému d6lat. Následovat bude business analýza neboli podrobný návrh p-ípad@ užití. P-i návrhu reálného systému je tato analýza vypracovávána spolu s klientem a klient ji musí závazn6 odsouhlasit p-ed dalším návrhem systému. V našem p-ípad6 je klient pouze imaginární.

Pokud je celá business analýza vypracována, je možné p-istoupit k návrhu vlastního informa&ního systému. Informa&ní systém bude vícevrstvý a jeho jádrem je business vrstva, která se bude navrhovat jako první. Návrh business vrstvy neboli systémový design se skládá z diagramu t-íd, stavového diagramu a podrobného popisu jednotlivých t-íd.

Mezi vrstvy, které jsou pod business vrstvou a jejichž služby business vrstva využívá, jsou vrstva p-ístupu k dat@m a databázová vrstva. Databázovou vrstvu navrhneme pomocí ER (Entity – Relationship) diagramu neboli diagramu tabulek a vztah@ mezi nimi. Ten vytvo-íme na základ6 diagramu t-íd. Jako vrstvu p-ístupu k dat@m použijeme LINQ to SQL, které p-evezme strukturu z ER diagramu.

Naopak vrstvy, které jsou nad business vrstvou a které používají služby business vrstvy, jsou vrstva aplika&ní a vrstva uživatelského rozhraní. Tyto vrstvy budeme navrhovat na základ6 Use Case diagramu a business analýzy. Jelikož náš systém bude vycházet z architektury MVC budeme jako modely brát t-ídy z business vrstvy, aplika&ní vrstva pak budou -adi&e a vrstvou uživatelského rozhraní budeme rozum6t jednotlivé pohledy.

4.1 Uživatelské role v systému

Potenciální zákazník

Tuto roli má zákazník bezpe&nostní agentury, který se ješt6 nezaregistroval do systému. Po spušt6ní aplikace se jako jediný nep-ihlašuje do systému. Jediné akce, které m@že v systému provád6t, je získávání informací o bezpe&nostní agentu-e a registrace do systému.

(22)

22 Zákazník

Tuto roli má zákazník bezpe&nostní agentury, který se již zaregistroval do systému. Po spušt6ní aplikace se musí p-ihlásit. V systému m@že získávat informace, editovat své osobní údaje, zobrazit si seznam vlastních hlídaných objekt@, p-idávat hlídané objekty, editovat hlídané objekty, rušit hlídané objekty.

Dispe er

Tato role p-edstavuje zam6stnance bezpe&nostní agentury, který -ídí konkrétní pobo&ku a má pod sebou techniky a ostrahu. Na každé pobo&ce je více dispe&er@, ale ti se st-ídají ve sm6ném provozu a vždy pouze jeden je p-ihlášený do systému. Jeho úkolem je reagovat na podn6ty p-icházející buY od zákazník@, nebo od bezpe&nostních úst-eden a p-id6lovat objekty technik@m a ostraze.

Technik

Tato role p-edstavuje zam6stnance bezpe&nostní agentury, který instaluje a opravuje bezpe&nostní úst-edny a další zabezpe&ovací systémy v hlídaných objektech. Pokud je mu p-id6len objekt k instalaci nebo oprav6 provede práci a v systému potvrdí spln6ní úkolu.

Ostraha

Tato role p-edstavuje zam6stnance bezpe&nostní agentury, který provádí zásahy v hlídaných objektech, kde došlo k poplachu. Pokud je mu p-id6len objekt, provede zásah a v systému potvrdí spln6ní úkolu.

4.2 Use Case diagram

Use Case diagram neboli diagram p-ípad@ užití slouží k po&áte&nímu logickému ut-íd6ní množství požadavk@ zákazníka, které &asto bývají mlhavé a chaoticky vyslovované, na funkce, které by m6l informa&ní systém obsahovat. Tento diagram stejn6 jako následná business analýza jsou psány z pohledu zákazníka a nezabývají se technologickými aspekty -ešení. Ne-eší se zde technologická platforma ani použitá databáze. Pouze se zde zjišHuje, jaké procesy budou v systému probíhat a jací uživatelé ho budou používat.

Celý diagram se sestává z aktor@, p-ípad@ užití a vazeb mezi nimi. Pod pojmem aktor nerozumíme konkrétního uživatele systému, ale roli v systému, kterou m@že hrát jedna nebo více osob p-ípadn6 i jiný systém. P-ípadem užití potom myslíme jednu funkci systému. Tato funkce bývá obvykle p-i-azena relací jednomu nebo více aktor@m. M@že se ovšem stát, že

(23)

23

Obrázek 4 - Use Case diagram neboli diagram p=ípad7 užití

(24)

24 n6kolik p-ípad@ užití sdílí stejnou funk&nost, jinak -e&eno zjistíme, že &ást scéná-e se opakuje ve více p-ípadech užití. Spole&nou &ást m@žeme vyjmout do samostatného p-ípadu užití a ostatním p-ípad@m užití ho p-id6líme relací, kterou zna&íme p-erušovanou &arou.

Další v6c, která se m@že v diagramu vyskytnout je generalizace neboli zobecn6ní a to jak aktor@ tak p-ípad@ užití. Tuto v6c si m@žeme p-edstavit jako d6di&nost v objektovém programování. P-edek má p-id6leny n6jaké p-ípady užití a jeho potomci je mají automaticky také, aniž by bylo pot-eba zapisovat tyto relace do diagramu.

V našem diagramu p-ípad@ užití (Obrázek 4) vidíme Potencionálního zákazníka, který si m@že v systému zobrazovat informace nebo se registrovat. Dále je zde Zákazník, který m@že editovat osobní údaje, zobrazovat si seznam hlídaných objekt@ a také p-idávat, editovat a rušit tyto objekty. Vidíme zde, že p-ípady užití „Registrace“ a „Editace osobních údaj@“ využívají spole&nou &ást „Nastavení osobních údaj@“. Stejn6 tak „P-idání hlídaného objektu“ a „Editace hlídaného objektu“ využívají „Nastavení vlastností hlídaného objektu“.

Jelikož zam6stnanci bezpe&nostní agentury v rolích Dispe&er, Technik a Ostraha mají n6kolik spole&ných p-ípad@ užití je v diagramu založen aktor „Zam6stnanec BA“, který m@že zobrazovat seznam hlídaných objekt@, seznam úkol@ a detaily hlídaného objektu. Aktor Dispe&er pak dále m@že p-id6lovat a zamítat hlídaný objekt, zatímco akto-i Technik a Ostraha mohou potvrdit spln6ní svého úkolu. Je zde vid6t, že p-i p-id6lení hlídaného objektu aktorem Dispe&er se zároveI vytvo-í úkol, potvrdí spln6ní úkolu a nastaví stav hlídaného objektu. Stav hlídaného objektu se nastavuje i p-i p-idání hlídaného objektu, jeho zrušení, zamítnutí, potvrzení spln6ní úkolu a p-i p-ijetí zprávy.

4.3 Business analýza

Use Case 1 – Zobrazení informací

V p-ípad6 požadavku na informace je pot-eba tyto zobrazit ve snadno srozumitelné a dostupné form6. Potenciální zákazník musí mít možnost se dozv6d6t základní informace o firm6, o poskytovaných produktech v&etn6 alespoI p-ibližné ceny, kontaktní informace, p-ípadn6 reference na významné zákazníky.

(25)

25

Tabulka 1 - Akto=i pro Use Case 1 – Zobrazení informací

ázev aktora Popis aktora

Potenciální zákazník Aktor, který získává informace o firm6 a na jejich základ6 se rozhoduje, zdali se zaregistruje a stane se zákazníkem firmy.

Zákazník Aktor, který je již zaregistrovaný a pouze si rozši-uje své informace o firm6.

Frekvence užití Jednou za minutu

Základní tok událostí

1. Uživatel spustí aplikaci nebo dá p-íkaz k p-echodu na úvodní obrazovku.

2. Systém zobrazí základní informace v&etn6 názvu firmy, loga, stru&ného popisu firmy, novinek.

3. Uživatel zadá p-íkaz k zobrazení podrobn6jších informací o firm6.

4. Systém zobrazí podrobn6jší informace v&etn6 zam6-ení firmy, stru&né historie firmy a dalších užite&ných informací.

5. Uživatel zadá p-íkaz k zobrazení informací o produktech firmy.

6. Systém zobrazí informace o jednotlivých produktech v&etn6 podrobného popisu produktu, ceny, dostupnosti produktu, ak&ních slev.

7. Uživatel zadá p-íkaz k zobrazení referencí.

8. Systém zobrazí reference na p-edchozí významné zákazníky v&etn6 kontaktních údaj@

na p-íslušné zástupce zákazník@. Všechny informace zde budou zobrazeny až po odsouhlasení p-íslušnými zákazníky.

9. Uživatel zadá p-íkaz k zobrazení kontaktních informací.

10. Systém zobrazí kontaktní informace firmy v&etn6 adresy provozovny, telefon@ na jednotlivá pracovišt6, fax@, emailových adres, mapky zobrazující polohu provozovny.

Poznámka: Uživatel m@že zadávat p-íkazy pro zobrazení informací v r@zném po-adí a systém mu zobrazuje odpovídající informace.

Use Case 2 – astavení osobních údaj7

V p-ípad6 že je v aplikaci pot-eba nastavit osobní údaje zákazníka, je nutné získání pot-ebných informací od uživatele. V p-ípad6 registrace (viz Use Case 3) je nutno získat všechny povinné údaje a dále ty, které jsou nepovinné, ale uživatel je chce uvést. V p-ípad6 editace údaj@ (viz Use Case 4) je nutno získat pouze údaje, které chce uživatel pozm6nit

(26)

26 oproti již uloženým. Všechny údaje vložené uživatelem je nutné zkontrolovat a p-ípadn6 uživatele informovat o špatn6 zadaných.

Tabulka 2 - Akto=i pro Use Case 2 – astavení osobních údaj7

Potenciální zákazník Aktor, který zadává informace o sob6 p-i registraci do systému.

Zákazník Aktor, který pozm6Iuje již d-íve zadané informace.

Frekvence užití Jednou za hodinu

1. Systém zobrazí uživateli formulá- pro zadání osobních údaj@ a p-edvyplní údaje již obsažené v systému (pouze v p-ípad6 editace údaj@).

2. Uživatel zadá své jméno a p-íjmení (povinné pole).

3. Uživatel zadá své p-ihlašovací jméno do systému (povinné pole).

4. Uživatel zadá a potvrdí své heslo do systému (povinné pole).

5. Uživatel zadá svou emailovou adresu (povinné pole).

6. Uživatel zadá svoje telefonní &íslo (povinné pole).

7. Uživatel zadá svoje faxové &íslo.

8. Uživatel zadá svou ulici a &íslo popisné (povinné pole).

9. Uživatel zadá své m6sto (povinné pole).

10. Uživatel zadá své poštovní sm6rovací &íslo (povinné pole).

11. Uživatel vybere sv@j kraj (povinné pole pouze pro &eské zákazníky). Zdrojem dat bude

&íselník kraj@.

12. Uživatel vybere sv@j stát (povinné pole). Zdrojem dat bude &íselník stát@.

13. Uživatel zadá p-íkaz pro uložení údaj@ do systému 14. Systém údaje zkontroluje

15. Systém údaje uloží (v p-ípad6 registrace založí nového zákazníka).

Rozší ení toku událostí

Zadávání hesla

Uživatel p-i zadávání hesla neuvidí znaky, které napíše. Celé heslo musí proto zadat ješt6 jednou a systém zkontroluje shodu. P-i editaci se p@vodní heslo nep-edvyplIuje, ale pokud uživatel nezadá nové heslo, bude p@vodní zachováno.

(27)

27 Kontrola údaj@

Pokud systém najde ve vypln6ných údajích chybu, upozorní na ni uživatele a vyzve ho, aby údaje opravil.

Use Case 3 – Registrace

Pokud se potenciální zákazník rozhodne stát zákazníkem firmy, je nutné, aby se zaregistroval do systému a vyplnil o sob6 všechny pot-ebné informace (viz Use Case 2). Potom se již m@že p-ihlašovat do systému v roli zákazníka a m@že provád6t všechny operace jako zákazník.

Tabulka 3 - Akto=i pro Use Case 3 – Registrace

Potenciální zákazník Aktor, který se registruje do systému.

1. Uživatel zadá p-íkaz pro zaregistrování do systému.

2. Uživatel zadá osobní údaje (viz Use Case 2).

3. Systém oznámí uživateli, že byl úsp6šn6 zaregistrován 4. Uživatel je p-ihlášen do systému jako zákazník.

Use Case 4 – Editace osobních údaj7

V p-ípad6, že se zm6ní n6které informace o zákazníkovi, m6l by co nejd-íve opravit údaje uložené v systému, aby byla zachována správnost uložených údaj@. Uživatel vyplní jednu nebo více informací o sob6, které se zm6nily (viz Use Case 2) a systém zm6ny uloží.

Tabulka 4 – Akto=i pro Use Case 4 – Editace osobních údaj7

Zákazník Aktor, jehož osobní údaje se zm6nily a on tuto zm6nu pot-ebuje uložit do systému.

Frekvence užití Jednou za deset minut

1. Uživatel zadá p-íkaz pro zm6nu osobních údaj@.

2. Uživatel zadá osobní údaje (viz Use Case 2).

(28)

28 3. Systém oznámí uživateli, že údaje byly úsp6šn6 zm6n6ny.

Use Case 5 – Zobrazení seznamu hlídaných objekt7

Každý uživatel si m@že zobrazit seznam hlídaných objekt@, pro které má oprávn6ní.

Zobrazované objekty mohou být r@zn6 filtrovány. Uživatelé zde mohou zadávat r@zné p-íkazy pro práci s hlídanými objekty. Možnosti použití filtr@ a operací s objekty jsou vázány na role v systému.

Tabulka 5 - Akto=i pro Use Case 5 – Zobrazení seznamu hlídaných objekt7

Zákazník Aktor, kterému se zobrazí jím zadané hlídané objekty.

Dispe&er Aktor, kterému se zobrazí všechny objekty z jeho pobo&ky.

Technik Aktor, kterému se zobrazí jemu p-id6lené objekty.

Ostraha Aktor, kterému se zobrazí jemu p-id6lené objekty.

Frekvence užití Každou vte-inu

1. Uživatel zadá p-íkaz pro zobrazení seznamu hlídaných objekt@.

2. Uživatel vybere pobo&ku (Zákazník).

3. Uživatel vybere stav hlídaného objektu (Zákazník, Dispe&er, Technik, Ostraha).

4. Uživatel vybere, zda se mají zobrazit i zamítnuté objekty (Zákazník, Dispe&er).

5. Uživatel zadá p-íkaz k filtrování.

6. Systém vypíše data podle ur&eného filtru.

Výb6r pobo&ky

Systém nabídne uživateli pobo&ky uložené v systému a variantu „všechny“.

Výb6r stavu hlídaného objektu

Systém nabídne uživateli možné stavy hlídaného objektu (viz Use Case 11).

Use Case 6 – astavení vlastností hlídaného objektu

V p-ípad6, že je v aplikaci pot-eba nastavit vlastnosti hlídaného objektu, je nutné získání pot-ebných informací od uživatele. V p-ípad6 p-idání hlídaného objektu (viz Use Case 7) je nutno získat všechny povinné údaje a dále ty, které jsou nepovinné, ale uživatel je chce uvést.

(29)

29 V p-ípad6 editace hlídaného objektu (viz Use Case 8) je nutno získat pouze údaje, které chce uživatel pozm6nit oproti již uloženým. Všechny údaje vložené uživatelem je nutné zkontrolovat a p-ípadn6 uživatele informovat o chybném zadání.

Tabulka 6 - Akto=i pro Use Case 6 – astavení vlastností hlídaného objektu

Zákazník Aktor, který vyplIuje vlastnosti vlastního hlídaného objektu.

1. Systém zobrazí uživateli formulá- pro zadání vlastností hlídaného objektu a p-edvyplní údaje již obsažené v systému (pouze v p-ípad6 editace hlídaného objektu).

2. Uživatel zadá název objektu (povinné pole).

3. Uživatel vybere pobo&ku bezpe&nostní agentury (povinné pole). Zdrojem dat bude seznam pobo&ek na&tený z databáze.

4. Uživatel zadá ulici a &íslo popisné objektu (povinné pole).

5. Uživatel zadá m6sto, kde se objekt nachází (povinné pole).

6. Uživatel zadá poštovní sm6rovací &íslo objektu (povinné pole).

7. Uživatel vybere kraj, kde se objekt nachází (povinné pole pouze pro objekty v \eské republice). Zdrojem dat bude &íselník kraj@.

8. Uživatel vybere stát, kde se objekt nachází (povinné pole).

9. Uživatel zadá telefonní &íslo objektu.

10. Uživatel zadá faxové &íslo objektu.

11. Uživatel zadá emailovou adresu objektu.

12. Uživatel zadá p-íkaz pro uložení údaj@ do systému 13. Systém údaje zkontroluje

14. Systém údaje uloží (v p-ípad6 p-idání objektu vytvo-í v systému nový objekt).

Use Case 7 – P=idání hlídaného objektu

Zákazník m@že do systému p-idávat objekty, které požaduje st-ežit bezpe&nostní agenturou.

Pokud zákazník p-idává nový objekt, musí o n6m vyplnit všechny pot-ebné informace (viz Use Case 6).

(30)

30

Tabulka 7 - Akto=i pro Use Case 7 – P=idání hlídaného objektu

Zákazník Aktor, který p-idává vlastní hlídaný objekt.

1. Uživatel zadá p-íkaz pro p-idání hlídaného objektu.

2. Uživatel nastaví vlastnosti hlídaného objektu (viz Use Case 6).

3. Systém nastaví stav objektu na „Nový“ (viz Use Case 11) 4. Systém oznámí uživateli, že objekt byl úsp6šn6 p-idán.

Use Case 8 – Editace hlídaného objektu

V p-ípad6, že se zm6ní n6které informace o hlídaném objektu, m6l by zákazník co nejd-íve opravit vlastnosti uložené v systému, aby byla zachována správnost uložených vlastností.

Zákazník vyplní jednu nebo více informací o hlídaném objektu, které se zm6nily (viz Use Case 6) a systém zm6ny uloží. Pokud byl hlídaný objekt zamítnut dispe&erem m@že ho zákazník editovat a tím ho znovu p-evést do stavu „Nový“.

Tabulka 8 - Akto=i pro Use Case 8 – Editace hlídaného objektu

Zákazník Aktor, jež vlastní hlídaný objekt, jehož vlastnosti se zm6nily a on tuto zm6nu pot-ebuje uložit do systému.

1. Uživatel zadá p-íkaz pro zm6nu vlastností hlídaného objektu.

2. Uživatel zadá vlastnosti hlídaného objektu (viz Use Case 6).

3. Systém nastaví stav objektu na „Nový“ (pokud byl ve stavu „Zamítnutý“) (viz Use Case 11)

4. Systém oznámí uživateli, že údaje byly úsp6šn6 zm6n6ny.

(31)

31 Use Case 9 – Zrušení hlídaného objektu

Zákazník, který si objednal hlídání svého objektu, m@že toto hlídání zrušit. Objekt již dále nebude hlídán bezpe&nostní agenturou a postupn6 p-ejde do neaktivního stavu.

Tabulka 9 - Akto=i pro Use Case 9 – Zrušení hlídaného objektu

Zákazník Aktor, který ruší vlastní hlídaný objekt.

1. Uživatel zadá p-íkaz pro zrušení hlídaného objektu.

2. Systém nastaví stav objektu na „Zrušený“ (viz Use Case 11) 3. Systém informuje uživatele o úsp6šném zrušení objektu.

Use Case 10 – Zobrazení hlídaného objektu

Uživatel si m@že zobrazit informace o hlídaném objektu. Je zde zobrazen název objektu, adresa, telefon, email, fax, stav objektu. Pro techniky je zde zobrazen i kód hlídaného objektu a bezpe&nostní klí&, tyto údaje jsou automaticky generovány systémem p-i p-idání objektu a technik je musí nastavit na bezpe&nostní úst-edn6 p-i její instalaci v objektu.

Tabulka 10 - Akto=i pro Use Case 10 – Zobrazení hlídaného objektu

Zákazník Aktor, kterému se zobrazí jím zadaný hlídaný objekt.

Dispe&er Aktor, kterému se zobrazí objekt z jeho pobo&ky.

Technik Aktor, kterému se zobrazí jemu p-id6lený objekt.

Ostraha Aktor, kterému se zobrazí jemu p-id6lený objekt.

1. Uživatel zadá p-íkaz pro zobrazení hlídaného objektu.

2. Systém zobrazí informace o objektu.

(32)

32 Use Case 11 – astavení stavu hlídaného objektu

V systému má každý hlídaný objekt p-id6len sv@j stav a tento se v pr@b6hu &asu m6ní. M6ní ho systém jako reakci na provád6né akce (P-idání hlídaného objektu – viz Use Case 7, Zrušení hlídaného objektu – viz Use Case 9, P-id6lení hlídaného objektu – viz Use Case 12, Zamítnutí hlídaného objektu – viz Use Case 13, Potvrzení spln6ní úkolu – viz Use Case 16, P-ijetí zprávy – viz Use Case 17).

V tomto Use Case nejsou žádní akto-i, neboH je provád6n systémem automaticky.

1. Uživatel (Systém) zadá p-íkaz pro nastavení stavu hlídaného objektu v&etn6 hodnoty nového stavu.

2. Systém zm6ní stav hlídaného objektu.

Rozší ený tok událostí

Možné stavy hlídaného objektu

Nový – hlídaný objekt byl zadán zákazníkem a nebyl doposud dále zpracován Instalace – n6který z technik@ byl ur&en pro instalaci zabezpe&ení hlídaného objektu Zabezpe&ený – zabezpe&ení objektu bylo nainstalováno a je v provozu

Poplach – v objektu byl vyvolán poplach a ješt6 nebyl naplánován zásah Zásah – n6který &len ostrahy byl ur&en k provedení zásahu v hlídaném objektu

Porucha – zabezpe&ovací za-ízení se neozývá nebo signalizuje poruchu a ješt6 nebyla naplánována oprava

Oprava – n6který z technik@ byl ur&en pro opravu zabezpe&ení hlídaného objektu Zrušený – hlídaný objekt byl zrušený zákazníkem, ale ješt6 nebyla naplánována deinstalace zabezpe&ovacího za-ízení

Deinstalace – byla naplánována deinstalace zabezpe&ovacího za-ízení v hlídaném objektu

Neaktivní – objekt není již nadále hlídaný Zamítnutý – objekt zamítnutý dispe&erem

(33)

33 Vytvo-ení úkolu

Pokud se objekt dostane do stav@ „Nový“, „Poplach“, „Porucha“ nebo „Zrušený“ je vytvo-en úkol pro dispe&era (viz Use Case 15), který musí dále p-id6lit objekt technikovi nebo ostraze (viz Use Case 12).

Use Case 12 – P=id4lení hlídaného objektu

Pokud je k hlídanému objektu vytvo-en úkol pro dispe&era, musí dispe&er p-id6lit hlídaný objekt technikovi nebo ostraze. Tímto se vytvo-í úkol (viz Use Case 15), který pov6-ený aktor poté musí splnit a potvrdit spln6ní(viz Use Case 16).

Tabulka 11 - Akto=i pro Use Case 12 – P=id4lení hlídaného objektu

Dispe&er Aktor, který p-id6lí hlídaný objekt technikovi nebo ostraze.

Frekvence užití Jednou za minutu

1. Uživatel zadá p-íkaz pro p-id6lení hlídaného objektu.

2. Uživatel vybere technika (ostrahu), kterému má být hlídaný objekt p-id6len.

3. Uživatel potvrdí p-id6lení hlídaného objektu.

4. Systém vytvo-í úkol vybraného technika (ostrahy) (viz Use Case 15).

5. Systém nastaví stav hlídaného objektu (viz Use Case 11).

6. Systém potvrdí spln6ní úkolu dispe&era (viz Use Case 16).

Výb6r technika (ostrahy)

Systém nabídne uživateli možné techniky (ostrahy) z jeho pobo&ky.

Use Case 13 – Zamítnutí hlídaného objektu

Pokud je n6jaký problém s nov6 p-idaným objektem dispe&er ho m@že zamítnout a objekt pak není hlídaný bezpe&nostní agenturou.

Tabulka 12 - Akto=i pro Use Case 13 – Zamítnutí hlídaného objektu

Dispe&er Aktor, který zamítne hlídaný objekt.

(34)

34 Frekvence užití

Jednou za hodinu

1. Uživatel zadá p-íkaz pro zamítnutí hlídaného objektu.

2. Systém nastaví stav hlídaného objektu na „Zamítnutý“ (viz Use Case 11).

3. Systém potvrdí spln6ní úkolu dispe&era (viz Use Case 16).

Use Case 14 – Seznam úkol7

Zam6stnanci bezpe&nostní agentury (Dispe&er, Technik a Ostraha) si mohou nechat zobrazit seznam svých úkol@ a to buY aktuálních anebo již spln6ných. Dispe&er si zároveI m@že nechat zobrazit i úkoly ostatních zam6stnanc@ na pobo&ce.

Tabulka 13 - Akto=i pro Use Case 14 – Seznam úkol7

Dispe&er Aktor, kterému se zobrazí všechny úkoly pro dispe&ery z jeho pobo&ky a také úkoly ostatních zam6stnanc@ na pobo&ce.

Technik Aktor, kterému se zobrazí jemu p-id6lené úkoly.

Ostraha Aktor, kterému se zobrazí jemu p-id6lené úkoly.

1. Uživatel vybere zam6stnance (Dispe&er).

2. Uživatel vybere, zda chce zobrazit i spln6né úkoly.

3. Uživatel zadá p-íkaz pro zobrazení seznamu úkol@.

4. Systém vypíše seznam úkol@.

Výb6r zam6stnance

Systém nabídne uživateli zam6stnance pobo&ky uložené v systému a variantu „dispe&e-i“, která vypíše všechny úkoly pro dispe&ery, a variantu „všichni“, která reprezentuje úkoly pro všechny zam6stnance pobo&ky.

(35)

35 Use Case 15 – Vytvo=ení úkolu

Úkoly se v systému vytvá-ejí automaticky jako reakce na n6které akce. Po zm6n6 stavu objektu (do stav@ „Nový“, „Poplach“, „Porucha“, „Zrušený“ – viz Use Case 11) se vytvo-í úkol pro Dispe&ery. Po p-id6lení hlídaného objektu (viz Use Case) se vytvo-í úkol p-íslušnému Technikovi nebo Ostraze.

V tomto Use Case nejsou žádní akto-i, neboH je provád6n systémem automaticky.

Frekvence užití Každou minutu

1. Systém vybere zam6stnance.

2. Systém vybere pobo&ku.

3. Systém vybere objekt.

4. Systém vybere prioritu úkolu.

5. Systém vytvo-í a uloží úkol.

Výb6r zam6stnance

Systém buY vybere jednoho z technik@ nebo z ostrahy nebo vybere „dispe&ery“ podle toho, na jakou akci reaguje.

Výb6r objektu

Systém vybere objekt podle akce, na kterou reaguje.

Výb6r priority

Pokud jde o reakci na zm6nu stavu na „Poplach“ nebo „Porucha“, p-ípadn6 nápravu t6chto stav@ („Zásah“, „Oprava“), dojde k výb6ru priority „Vysoká“, v ostatních p-ípadech dojde k výb6ru priority „Normální“.

Use Case 16 – Potvrzení spln4ní úkolu

Tento Use Case m@že být proveden aktérem nebo automaticky. K prvnímu p-ípadu dochází v situaci, kdy Technik nebo Ostraha splnili sv@j p-id6lený úkol a cht6jí tuto skute&nost zachytit v systému. Ke druhému p-ípadu dochází ve chvíli, kdy dispe&er p-id6lí hlídaný objekt Technikovi nebo Ostraze a tím splní sv@j úkol, což systém automaticky potvrdí.

(36)

36

Tabulka 14 - Akto=i pro Use Case 16 – Potvrzení spln4ní úkolu

Technik Aktor, který potvrzuje spln6ní jemu p-id6lených úkol@.

Ostraha Aktor, který potvrzuje spln6ní jemu p-id6lených úkol@.

Frekvence užití Každou minutu

1. Uživatel zadá p-íkaz k potvrzení spln6ní úkolu.

2. Uživatel zapíše komentá- ke spln6ní úkolu.

3. Uživatel potvrdí spln6ní úkolu.

4. Systém nastaví stav hlídaného objektu (viz Use Case 11) 5. Systém nastaví úkol jako spln6ný.

Use Case 17 – P=ijetí zprávy

Pokud p-ijde zpráva z bezpe&nostní úst-edny a je ov6-ena její pravost je tato zpráva uložena do systému a podle jejího obsahu je nastaven stav p-íslušného hlídaného objektu (viz Use Case 11). N6které zprávy ovšem pouze potvrzují &innost úst-edny a nem6ní stav p-íslušného hlídaného objektu.

Tabulka 15 - Akto=i pro Use Case 17 – P=ijetí zprávy

Bezpe&nostní úst-edna Aktor, který vkládá zprávy do systému.

1. Uživatel zadá p-íkaz pro vložení zprávy do systému.

2. Systém uloží zprávu.

3. Systém nastaví podle pot-eby stav hlídaného objektu (viz Use Case 11).

Možné typy zpráv

Vše v po-ádku – pravideln6 odesílaná zpráva signalizující, že úst-edna je v po-ádku Poplach – zpráva odeslaná z úst-edny signalizující poplach na úst-edn6

(37)

37 Porucha – zpráva odeslaná z úst-edny signalizující poruchu na úst-edn6

Timeout – úst-edna se neozývá, bráno jako porucha na úst-edn6

4.4 Systémový design – Diagram t=íd

Diagram t-íd (viz Obrázek 5) je použit k návrhu business vrstvy informa&ního systému a znázorIuje t-ídy a &íselníky, ze kterých bude tato vrstva složena. Obvykle se do diagramu t-íd krom6 vlastních t-íd a vazeb mezi nimi uvád6jí i atributy a metody jednotlivých t-íd.

V našem p-ípad6 jsou tyto z d@vodu lepší &itelnosti diagramu vynechány a budou popsány až v další &ásti.

V diagramu t-íd existuje n6kolik typ@ vazeb, které jsou graficky rozlišené. První z nich je takzvaná generalizace neboli zobecn6ní, je znázorn6na uzav-enou šipkou a p-edstavuje d6di&nost mezi t-ídami. Dalším typem vazby je asociace, zna&ená plnou &arou, která m@že a nemusí být ukon&ena otev-enou šipkou. Tato vazba zna&í obecný vztah mezi dv6ma t-ídami a šipka zna&í, že vztah je pouze jednosm6rný. Speciální formou asociace je agregace, zna&ená koso&tvercem, která ur&uje celek a jeho &ásti, mezi nimiž je ovšem volná vazba.

Uživatel informa&ního systému je reprezentován t-ídou User. Od této t-ídy dále d6dí t-ídy Customer, p-edstavující Zákazníka, a Employee, p-edstavující Zam6stnance bezpe&nostní agentury. Od t-ídy Employee dále d6dí t-ídy Operator, p-edstavující Dispe&era, a TerrainEmployee, p-edstavující Technika a Ostrahu. Zákazník má vazbu na hlídané objekty, které zadal do systému (t-ída SecurityObject). Zam6stnanec bezpe&nostní agentury má vazbu na pobo&ku, ve které pracuje (t-ída Branch). Terénní zam6stnanci (Technik a Ostraha) mají vazbu na své úkoly (t-ída Task), které mají provést nebo které již provedli.

Všechny úkoly mají vazbu na hlídaný objekt a pobo&ku, ale n6které nemusí mít vazbu na terénní zam6stnance, toto jsou úkoly pro Dispe&era dané pobo&ky. Hlídaný objekt má vazbu na zprávy p-icházející z jeho bezpe&nostní úst-edny do systému (t-ída Message).

T-ídy User a Employee jsou abstraktní a slouží pouze jako p-edci pro další t-ídy, tato skute&nost je v diagramu vyjád-ena klí&ovým slovem abstrakt.

Krom6 t-íd jsou v diagramu uvedeny i &íselníky (ozna&ené klí&ovým slovem Enum). Každý uživatel má p-i-azenu svoji roli v systému (&íselník Role). Každý zákazník a každý hlídaný objekt mají p-i-azenou zemi (&íselník Country). Na rozdíl od zem6, kraj (&íselník Region) mají p-i-azen pouze n6kte-í zákazníci a n6které hlídané objekty. Jsou to ti, kte-í mají jako zemi p-i-azenou \eskou republiku. Každý hlídaný objekt má dále p-i-azený sv@j stav (&íselník

(38)

38 SecurityObjectState). Každý úkol má p-i-azenu svou prioritu (&íselník Priority). Každá p-ijatá zpráva má p-i-azen typ zprávy (&íselník MessageType).

Obrázek 5 - Diagram t=íd

(39)

39 4.5 Systémový design – Stavový diagram

Stavový diagram obsahuje stavový stroj (stavový automat), který vyjad-uje stavy ur&itého objektu a p-echody mezi t6mito stavy. Stav je situace, kdy modelovaný objekt splIuje n6jakou podmínku, provádí n6jakou operaci nebo &eká na událost. P-echod je spojení dvou stav@

a znázorIuje p-echod z jednoho stavu do druhého p-i spln6ní n6jaké podmínky. Každý stavový stroj za&íná po&áte&ním stavem (zna&í se vypln6ným kruhem) a kon&í jedním nebo více kone&nými stavy (zna&í se dvojitým kruhem).

V našem p-ípad6 se jedná o stavový diagram pro stavy hlídaného objektu (Obrázek 6). Popisy jednotlivých stav@ jsou uvedeny u Use Case 11. P-echody mezi t6mito stavy nastávají v dob6 provád6ní funkcí systému (jejich názvy jsou uvedeny u jednotlivých p-echod@), které volají funkci pro zm6nu stavu objektu.

Popíšeme si život jednoho konkrétního hlídaného objektu (do závorek budeme uvád6t aktuální stav objektu). Nejprve zákazník p-idá hlídaný objekt do systému („Nový“). Dispe&er objekt zamítne („Zamítnutý“) a zákazník znovu edituje jeho obsah („Nový“). Dispe&er již nemá námitky proti hlídanému objektu a p-id6lí ho technikovi („Instalace“). Technik, který dostal objekt p-id6len, zde instaluje bezpe&nostní úst-ednu a poté potvrdí spln6ní p-id6leného úkolu („Zabezpe&ený“). Nyní je objekt ve stavu, ve kterém se objekty obvykle nachází po v6tšinu svého života.

V objektu dojde k narušení bezpe&nosti a bezpe&nostní úst-edna odešle do systému zprávu

„Poplach“, která je p-ijata („Poplach“). Dispe&er zareaguje p-id6lením objektu ostraze („Zásah“). Ostraha zde provede zásah, zjistí p-í&inu narušení bezpe&nosti a p-íslušn6 zareaguje. Následn6 potvrdí spln6ní p-id6leného úkolu („Zabezpe&ený“).

V bezpe&nostní úst-edn6 dojde k poruše a ta odešle do systému zprávu „Porucha“ (p-ípadn6 p-estane odesílat zprávu „Vše v po-ádku“ a v systému se vygeneruje zpráva „Timeout“).

Dispe&er zareaguje p-id6lením objektu technikovi („Porucha“). Technik zde provede opravu a potvrdí spln6ní p-id6leného úkolu („Zabezpe&ený“).

Zákazník se rozhodne, že již nechce sv@j objekt nechat st-ežit bezpe&nostní agenturou a zruší ho („Zrušený“). Dispe&er zareaguje p-id6lením objektu technikovi („Deinstalace“). Technik zde provede deinstalaci bezpe&nostní úst-edny a potvrdí spln6ní p-id6leného úkolu („Neaktivní“). Objekt je dále uchováván v systému pouze z d@vodu archivace a žádný z uživatel@ k n6mu nemá p-ístup.

(40)

40

Obrázek 6 - Stavový diagram

(41)

41 4.6 Systémový design – Textový popis t=íd

Tato &ást systémového designu obsahuje podrobný popis t-íd obsažených v diagramu t-íd, v&etn6 popisu ve-ejných atribut@ a metod t-íd. Všechny t-ídy a &íselníky business vrstvy jsou v namespace (jmenném prostoru) BIS.Business.

Abstraktní t=ída User

Tabulka 16 - Atributy t=ídy User

ázev Typ Popis

Id int? Identifika&ní &íslo uživatele v databázi FullName string Jméno a p-íjmení

Username string P-ihlašovací jméno

Password string Heslo

Email string Emailová adresa

Phone string Telefonní &íslo Role Role Role v systému

Tabulka 17 - Statické metody t=ídy User

ázev Popis User GetUser(string username) Vyhledá a vrátí uživatele daného uživatelského

jména.

bool ValidateUser(string username, string password)

Ov6-í, zdali existuje uživatel s daným jménem a heslem.

Tabulka 18 - Abstraktní metody t=ídy User

ázev Popis List<SecurityObject> GetSecurityObjectList() Implementace této metody vrací seznam

hlídaných objekt@ dostupných danému uživateli.

Tabulka 19 - Metody t=ídy User

ázev Popis bool CheckUsername(string username) Ov6-í, jestli uživatel m@že mít dané uživatelské

jméno (p-i vytvá-ení nebo zm6n6).

(42)

42 T=ída Customer (potomek t=ídy User)

Tabulka 20 - Atributy t=ídy Customer

CustomerId int? Identifika&ní &íslo zákazníka v databázi

Fax string Faxové &íslo

Street string Ulice a &íslo popisné

City string M6sto

Zip string Poštovní sm6rovací &íslo Region Region? Kraj

Country Country Stát

Tabulka 21 - Konstruktor t=ídy Customer

ázev Popis

Customer() Vytvo-í nového zákazníka.

Tabulka 22 - Implementace abstraktních metod t=ídy Customer

ázev Popis List<SecurityObject> GetSecurityObjectList() Vrací seznam hlídaných objekt@ vytvo-ených

a pat-ících zákazníkovi.

Tabulka 23 - Metody t=ídy Customer

ázev Popis

void Save() Uloží zákazníka do databáze (po vytvo-ení nebo

editaci).

Abstraktní t=ída Employee (potomek t=ídy User)

Tabulka 24 - Atributy t=ídy Employee

EmployeeId int? Identifika&ní &íslo zam6stnance v databázi Branch Branch Pobo&ka, kde zam6stnanec pracuje

Tabulka 25 - Abstraktní metody t=ídy Employee

ázev Popis List<Task> GetTaskList() Implementace této metody vrací seznam úkol@

zam6stnance.

(43)

43 T=ída Operator (potomek t=ídy Employee)

Tabulka 26 - Implementace abstraktních metod t=ídy Operator

ázev Popis List<SecurityObject> GetSecurityObjectList() Vrací seznam hlídaných objekt@ v dispe&erov6

pobo&ce.

List<Task> GetTaskList() Vrací seznam úkol@ dispe&era.

T=ída TerrainEmployee (potomek t=ídy Employee)

Tabulka 27 - Implementace abstraktních metod t=ídy TerrainEmployee

ázev Popis List<SecurityObject> GetSecurityObjectList() Vrací seznam hlídaných objekt@ p-id6lených

terénnímu pracovníkovi.

List<Task> GetTaskList() Vrací seznam úkol@ terénního pracovníka.

T=ída SecurityObject

Tabulka 28 - Atributy t=ídy SecurityObject

ázev Typ Popis

Id int? Identifika&ní &íslo hlídaného objektu v databázi Name string Název

Branch Branch Pobo&ka

Street string Ulice a &íslo popisné City string M6sto

Zip string Poštovní sm6rovací &íslo Region Region? Kraj

Country Country Stát

Phone string Telefonní &íslo

Fax string Faxové &íslo

Email string Emailová adresa

Code string Kód SecureKey string Bezpe&nostní klí&

State SecurityObjectState? Stav

CustomerId Int Identifika&ní &íslo zákazníka v databázi

Tabulka 29 - Konstruktor t=ídy SecurityObject

ázev Popis SecurityObject() Vytvo-í nový hlídaný objekt.

Tabulka 30 - Statické metody t=ídy SecurityObject

ázev Popis SecurityObject GetSecurityObject(int id) Vyhledá a vrátí hlídaný objekt s daným id.