Vyhodnocování a prezentace diagnostických dat z trvale provozovaných ºelezni ních zabezpe ovacích za ízení. Bc. Jaroslav Bien

eské vysoké u£ení technické v Praze Fakulta elektrotechnická

Diplomová práce

Vyhodnocování a prezentace diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení Bc. Jaroslav Bien

Vedoucí práce:

Ing. Radek Dobiá²

Studijní program: Elektrotechnika a informatika strukturovaný magisterský

Obor: Informatika a výpo£etní technika

kv¥ten 2008

iv

Pod¥kování Rád bych pod¥koval Ing. Radku Dobiá²ovi, vedoucímu této diplomové práce, za jeho p°ipomínky a rady, které p°isp¥ly ke zkvalitn¥ní tohoto textu a zpracování projektu. Rád bych téº vyjád°il pod¥kování svým koleg·m z AD Praha s.r.o. Ing. Janu Konarskému, Ing. Liboru Voto£kovi, Ing. Michaelu Charvátovi, Bc. Michalu Pet°íkovi a Ond°eji Havelkovi za konzultace problém· a dal²í informace vyuºité p°i práci na projektu. V neposlední °ad¥ bych cht¥l pod¥kovat rodi£·m, bratru Radkovi a p°ítelkyni Ivet¥ za jejich podporu p°i tvorb¥ a psaní diplomové práce.

v

vi

Prohlá²ení Prohla²uji, ºe jsem svou diplomovou práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).

V Praze dne 20.5. 2008

.............................................................

vii

viii

Abstract This thesis discusses the design and the implementation of system for evaluation and presentation of diagnostic data from permanently used railway interlocking equipment. Thesis designs eective method for processing and presentation of diagnostic data for any railway interlocking equipment. Compliance of target to design eective method for processing and presentation is validated by implementation of designed system and by creation of modules for processing a presentation of diagnostic data from track circuits KOA1 from company AD Praha s.r.o.

Abstrakt Tato diplomová práce pojednává o návrhu a implementaci systému pro vyhodnocování a prezentaci diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení. Práce navrhuje efektivní zp·sob pro zpracování a prezentaci diagnostických dat z libovolných ºelezni£ních zabezpe£ovacích za°ízení. Spln¥ní cíle návrhu efektivního zpracování a prezentace je ov¥°eno implementací navrºeného systému a vytvo°ením modul· pro zpracování a prezentaci diagnostických dat z kolejových obvod· KOA1 od spole£nosti AD Praha s.r.o.

ix

x

Obsah Seznam obrázk·

xvi

Seznam tabulek

xvii

1 Úvod

1

2 Popis problému a specikace cíle

3

2.1

Deklarace zám¥ru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

Projekt

3

2.3

elezni£ní zabezpe£ovací systémy . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.3.1

Obecn¥

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.3.2

T°íd¥ní

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.3.3

Struktura

2.3.4

Kolejové obvody

2.4

2.5

2.6

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Technická diagnostika

4

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.4.1

Diagnostika a technická diagnostika . . . . . . . . . . . . . . . . . . . . . .

7

2.4.2

Diagnóza, prognóza, geneze

2.4.3

Diagnostické prost°edky, diagnostický systém

2.4.4

Technický stav objektu, strukturní a procesní parametr

. . . . . . . . . .

9

2.4.5

Diagnostická veli£ina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.4.6

Porucha, provozuschopnost, funk£nost

11

2.4.7

Rozpoznávání v diagnostice

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

7 7

. . . . . . . . . . . . . . . . . . . . . . . . . .

11

AD Praha s.r.o. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.5.1

KOA1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.5.2

Lokální diagnostický systém LDS . . . . . . . . . . . . . . . . . . . . . . .

17

2.5.3

KOA Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.5.4

Produk£ní server AD Praha

18

2.5.5

Spider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

Cíle diplomové práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.6.1

Unied Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.6.2

Enterprise Architect

22

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Struktura práce

23

4 Re²er²e stávajících °e²ení

25

4.1

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.2

Diagnostická za°ízení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.3

Remote 96 - univerzální diagnostický systém zabezpe£ovacích za°ízení

. . . . . .

26

4.4

Lokální diagnostický systém LDS . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.5

Shrnutí re²er²e

28

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Poºadavky

31

5.1

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5.2

Specikace systémových poºadavk· . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5.2.1

Ú£el

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5.2.2

Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5.2.3

Nefunk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

5.2.4

Shrnutí poºadavk· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.3

P°ípady uºití

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xi

39

5.4

5.3.1

Modelování

5.3.2

Ú£astnící

5.3.3

Primární p°ípady uºití . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5.3.4

Administrace systému

41

5.3.5

Detaily p°ípad· uºití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.3.6

Matice sledovatelnosti poºadavk· . . . . . . . . . . . . . . . . . . . . . . .

42

Shrnutí

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Analýza

45

47

6.1

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

6.2

Analytické t°ídy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

6.3

6.4

6.5

6.2.1

Hledání analytických t°íd

. . . . . . . . . . . . . . . . . . . . . . . . . . .

47

6.2.2

Analýza podstatných jmen a sloves . . . . . . . . . . . . . . . . . . . . . .

47

6.2.3

Diagram analytických t°íd . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

Architektonická analýza

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3.1

Hledání analytických balí£k·

6.3.2

. . . . . . . . . . . . . . . . . . . . . . . . .

48 49

Diagram analytických balí£k· . . . . . . . . . . . . . . . . . . . . . . . . .

49

Realizace p°ípad· uºití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.4.1

Realizace p°ípadu uºití A1 . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.4.2

Realizace dal²ích p°ípad· uºití

Shrnutí

. . . . . . . . . . . . . . . . . . . . . . . .

49

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

7 Návrh

55

7.1

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

7.2

Architektonický návrh

55

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2.1

Návrhové t°ídy a up°esn¥ní analytických relací

. . . . . . . . . . . . . . .

55

7.2.2

Logická architektura systému

. . . . . . . . . . . . . . . . . . . . . . . . .

55

7.2.3

Datová architektura systému

. . . . . . . . . . . . . . . . . . . . . . . . .

56

Implementa£ní prost°edí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

7.3.1

Volba programovacího jazyka pro implementaci . . . . . . . . . . . . . . .

57

7.3.2

Volba knihoven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

7.3.3

Volba databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

7.4

phpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

7.5

NetBeans IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

7.6

Platforma NetBeans

64

7.7

Modulární programování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

7.7.1

Distribuovaný vývoj

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

7.7.2

Modulární aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

7.7.3

Manifest modulárního programování

68

7.7.4

Entropie vývoje software . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

7.7.5

Moduly vs. Pluginy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

7.8

Zd·vodn¥ní návrhových rozhodnutí . . . . . . . . . . . . . . . . . . . . . . . . . .

73

7.9

Návrh komunikace s aplikací Spider . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

7.10 Návrh zpracování diagnostických dat za°ízení KOA1

. . . . . . . . . . . . . . . .

74 74

7.11 Návrh uºivatelského rozhraní systému zpracování diagnostických dat

. . . . . . .

7.12 Návrh uºivatelského rozhraní modulu prezentace diagnostických dat

. . . . . . .

76

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

7.13 Shrnutí

8 Implementace

76

81

8.1

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

8.2

Rozhraní a komponenty

81

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xii

8.2.1

Fyzická architektura a rozvrstvení . . . . . . . . . . . . . . . . . . . . . . .

81

8.2.2

ZS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

8.2.3

Komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

8.2.4

Datová úloºi²t¥ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

8.2.5

Jádro

8.2.6

P°ístupová rozhraní

8.2.7

XUtilities

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

8.3

Implementace systému Rubicon . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

8.4

Logování a stav systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

8.5

Implementace pluginu Spider

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

8.6

Implementace pluginu KOA1 pro zpracování diagnostických dat . . . . . . . . . .

95

8.7

Implementace pluginu KOA1 pro prezentaci diagnostických dat

8.8

Statistiky a p°ehled implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

8.9

. . . . . . . . . . 100

8.8.1

Zpracování diagnostických dat . . . . . . . . . . . . . . . . . . . . . . . . . 102

8.8.2

Prezentace diagnostických dat . . . . . . . . . . . . . . . . . . . . . . . . . 104

Shrnutí

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

9 Testování

107

9.1

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

9.2

Testovací prost°edí

9.3

Testovací diagnostická data

9.4

Jednotkové testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

9.5

Integra£ní testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

9.6

Valida£ní testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

9.7

Systémové testování

9.8

Zhodnocení testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

10 Nasazení

111

11 Zhodnocení práce a dal²í pokra£ování

113

12 Záv¥r

115

13 Literatura

117

A Seznam pouºitých zkratek

119

B Uºivatelská p°íru£ka

123

B.1

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

B.2

Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

B.3

Rubicon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

B.4

B.3.1

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

B.3.2

Spu²t¥ní aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

B.3.3

Hlavní okno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

B.3.4

P°idání databázového p°ipojení . . . . . . . . . . . . . . . . . . . . . . . . 124

B.3.5

P°idání datového úloºi²t¥

B.3.6

Nastavení aplikace

B.3.7

Instalace plugin· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

B.3.8

Pr·b¥h zpracování diagnostických dat

B.3.9

Ostatní

PServer B.4.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . 124

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 . . . . . . . . . . . . . . . . . . . . 127

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

xiii

B.5

B.6

B.4.2

Spu²t¥ní aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

B.4.3

Hlavní okno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

B.4.4

Prohlíºení za°ízení

B.4.5

Prohlíºení vyhodnocení diagnostických dat . . . . . . . . . . . . . . . . . . 128

Systémové poºadavky

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

B.5.1

Rubicon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

B.5.2

PServer

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Záv¥r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

C Obsah p°iloºeného DVD

137

xiv

Seznam obrázk· 2.1

Logo projektu Rubicon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

Struktura ºelezni£ního zabezpe£ovacího systému . . . . . . . . . . . . . . . . . . .

5

2.3

Paralelní kolejový obvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.4

Systém pro rozpoznávání obraz· technického stavu objektu

. . . . . . . . . . . .

14

2.5

Logo spole£nosti AD Praha s.r.o.

. . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.6

Jedna v¥tev souboru kolejových p°ijíma£· TCR KOA1 . . . . . . . . . . . . . . .

16

2.7

Stojan elektronických kolejových obvod· KOA1 . . . . . . . . . . . . . . . . . . .

17

2.8

Blokové schéma zapojení KOA1 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.9

Stykový transformátor KO v koleji²ti . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.10 Diagnostika KOA1 pomocí p°enosného PC . . . . . . . . . . . . . . . . . . . . . .

20

2.11 Schéma KOA Serveru

20

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.12 Ukázka rozhraní Produk£ního Serveru AD Praha 2.13 Logo aplikace Spider

. . . . . . . . . . . . . . . . .

21

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.14 Logo aplikace Enterprise Architect

. . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.1

Schéma LDS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

5.1

Ú£astnící p°ípadu uºití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.2

Primární p°ípady uºití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.3

P°ípady uºití administrace systému . . . . . . . . . . . . . . . . . . . . . . . . . .

41

6.1

Diagram business objekt·

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

6.2

Diagram analytických t°íd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

6.3

Diagram analytických balí£k· . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

6.4

Realizace p°ípadu uºití A1 - diagram aktivit . . . . . . . . . . . . . . . . . . . . .

52

6.5

Realizace p°ípadu uºití A1 - sekven£ní diagram

. . . . . . . . . . . . . . . . . . .

53

7.1

Logická architektura systému

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

7.2

Detail balí£ku ZS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

7.3

Datová architektura systému

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

7.4

Logo programovacího jazyka Java . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

7.5

Logo projektu Apache Commons

. . . . . . . . . . . . . . . . . . . . . . . . . . .

61

7.6

Logo knihovny SLF4J

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

7.7

Logo knihovny XStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

7.8

Logo databáze MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

7.9

Logo aplikace phpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

7.10 Logo NetBeans IDE

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.11 Ikona aplikace postavené na platform¥ NetBeans 7.12 Platforma NetBeans

. . . . . . . . . . . . . . . . . .

64 64

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

podomácku vytvo°ených framework· . . . . . . . . . . . . . . . . . . . .

66

7.15 Classloadery modul· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

7.16 Závislosti modul· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

7.17 Entropie vývoje software - verze 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . .

71


71


72


72


73


73

7.13 Konec

7.14 Nevymý²lejte znovu kolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xv

67

7.23 Entropie vývoje software - verze x.x

. . . . . . . . . . . . . . . . . . . . . . . . .

74

7.24 Návrh XML Schéma komunikace s aplikací Spider . . . . . . . . . . . . . . . . . .

74

7.25 Schéma datového úloºi²t¥ za°ízení KOA1 . . . . . . . . . . . . . . . . . . . . . . .

75

7.26 Návrh XML Schéma metainformací k souboru s diagnostickými daty

. . . . . . .

76

7.27 Návrh hlavního okna aplikace Rubicon . . . . . . . . . . . . . . . . . . . . . . . .

77

7.28 Návrh okna nastavení aplikace Rubicon

. . . . . . . . . . . . . . . . . . . . . . .

78

. . . . . . . . . . . . . . . . . . . . . . . . .

78

7.30 Návrh hlavního okna aplikace PServer

. . . . . . . . . . . . . . . . . . . . . . . .

79

8.1

Fyzická architektura systému Rubicon

. . . . . . . . . . . . . . . . . . . . . . . .

82

8.2

Ukázka seznamu datových úloºi²´ . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

8.3

Ukázka implementace p°ístupového rozhraní pro ovládání systému Rubicon

. . .

89

8.4

Hlavní okno aplikace Rubicon . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

8.5

Okno nastavení aplikace Rubicon . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

8.6

Ukázka okna p°i chyb¥ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92

8.7

Hlavního okno pluginu Rubicon aplikace PServer

8.8

P°ehled implementace projektu Rubicon . . . . . . . . . . . . . . . . . . . . . . . 103

8.9

P°ehled implementace projektu PServer

7.29 Návrh okna chyby aplikace Rubicon

. . . . . . . . . . . . . . . . . . 102

. . . . . . . . . . . . . . . . . . . . . . . 105

10.1 Diagram nasazení systému Rubicon . . . . . . . . . . . . . . . . . . . . . . . . . . 111 B.1

Uvítací dialog aplikace Rubicon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

B.2

Hlavní okno aplikace Rubicon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

B.3

P°idání databázového p°ipojení v aplikaci Rubicon

B.4

Práce s databází v aplikaci Rubicon . . . . . . . . . . . . . . . . . . . . . . . . . . 126

B.5

Pr·vodce p°idáním datového úloºi²t¥ v aplikaci Rubicon . . . . . . . . . . . . . . 127

B.6

Pohled na p°idaná datová úloºi²t¥ a databáze v aplikaci Rubicon

B.7

Dialog nastavení aplikace Rubicon

B.8

Seznam nainstalovaných plugin· aplikace Rubicon . . . . . . . . . . . . . . . . . . 130

B.9

Dialog instalace staºeného pluginu aplikace Rubicon

. . . . . . . . . . . . . . . . . 126

. . . . . . . . . 128

. . . . . . . . . . . . . . . . . . . . . . . . . . 129 . . . . . . . . . . . . . . . . 130

B.10 Pr·vodce instalací pluginu aplikace Rubicon . . . . . . . . . . . . . . . . . . . . . 131 B.11 Pr·vodce p°idáním aktualiza£ního centra plugin· aplikace Rubicon . . . . . . . . 131 B.12 Seznam dostupných plugin· aplikace Rubicon . . . . . . . . . . . . . . . . . . . . 132 B.13 Bublinová nápov¥da restartu aplikace Rubicon . . . . . . . . . . . . . . . . . . . . 132 B.14 Spu²t¥ní pluginu po restartu aplikace Rubicon . . . . . . . . . . . . . . . . . . . . 133 B.15 Pr·b¥h zpracování diagnostických dat v aplikaci Rubicon B.16 Seznam za°ízení v aplikaci PServer

. . . . . . . . . . . . . 133

. . . . . . . . . . . . . . . . . . . . . . . . . . 134

B.17 Zobrazení vyhodnocení diagnostických dat v aplikaci PServer

. . . . . . . . . . . 134

B.18 Zobrazení vyhodnocení diagnostických dat v aplikaci PServer

. . . . . . . . . . . 135

xvi

Seznam tabulek 5.1

Detail p°ípadu uºití A1 Zpracovat diagnostická data

5.2

Dopl¬ující informace k p°ípadu uºití A1 Zpracovat diagnostická data

. . . . . . .

44

5.3

Matice sledovatelnosti poºadavk· . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

xvii

. . . . . . . . . . . . . . . .

43

xviii

KAPITOLA 1.

ÚVOD

1

1 Úvod S rostoucími poºadavky na spolehlivost, ºivotnost a bezpe£nost provozu technických za°ízení p°i jejich nar·stající sloºitosti a trend sniºování ekonomických náklad· na provozní údrºbu, lze splnit pouze s vyuºitím moderních diagnostických systém·. Jedním ze základních úkol· sou£asné diagnostiky není jen zji²óvat vzniklou poruchu, ale na základ¥ citlivé detekce a lokalizace v²ech zm¥n ve struktu°e objektu a ve zm¥nách jeho chování vznikajícím závadám p°edcházet. Pouºitím technické diagnostiky se zvy²uje spolehlivost a bezpe£nost provozu za°ízení. Sou£asný stav ºeleznice vyºaduje spolehlivost a ºivotnost, ale hlavn¥ i bezpe£nost provozu. Proto se na ºeleznicích pouºívají r·zné diagnostické systémy, které diagnostikují ve²keré za°ízení pouºívané na ºeleznicích, a´ uº se jedná o p°ejezdové zabezpe£ovací za°ízení, p°es stani£ní kolejové obvody a náv¥stidla, aº po elektronický autoblok. Aktuální technický stav objekt· je k dispozici servisním pracovník·m drah, kte°í se o p°ípadných problémech okamºit¥ dozvídají a mohou na n¥ náleºit¥ reagovat. Z d·vodu nep°edvídatelných nehod a jejich nejasných p°í£in je nutné zji²t¥né hodnoty provozních veli£in £i stav· za°ízení po del²í dobu uchovat tak, aby bylo moºno jejich zp¥tnou analýzou a vyhodnocením zjistit p°í£iny poruchy. Takto se lze vyvarovat dané chyby v dal²ím provozu za°ízení. asto aº n¥které nehody odhalí, ºe dané za°ízení je ²patn¥ navrºeno nebo ºe se nepo£ítalo s danou moºností, která zp·sobila problém. Na ºeleznici toto platí dvojnásobn¥, nebo´ historie ukazuje, ºe zm¥ny se d¥lají aº po

po°ádném pr·²vihu . Díky dlouhému vývoji ºeleznice jiº od 19. století jsou dnes ºelezni£ní zabezpe£ovací za°ízení na velmi vysoké úrovni, nicmén¥ i dnes se ur£ité nehody stávají. Proto je nutné pokud moºno uchovávat diagnostická data, která se v p°ípad¥ pot°eby specializovaným softwarem vyhodnotí. Tato data také umoº¬ují zji²óvání r·zných skrytých závislostí pomocí nejmodern¥j²ích analytických metod jako je dolování z dat (data mining). Ty pak mohou pomoci u£init ur£itá rozhodnutí, p°edvídat vývoj stav· za°ízení apod. Vý²e zmín¥n¥ poºadavky na uchování online diagnostických dat pak dávají podn¥t pro tuto diplomovou práci, která se zabývá vyhodnocením a prezentací uchovaných (oine) diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení. Tato práce si klade za cíl navrhnout systém pro vyhodnocování diagnostických dat z r·zných za°ízení efektivním zp·sobem, nebo´ je £asto k dispozici a je nutné zpracovat velké mnoºství dat daného zabezpe£ovacího za°ízení. Je také nutné navrhnout univerzální systém ke zpracování a prezentaci diagnostických dat z r·zných za°ízení, nebo´ jsou vyvíjena nová za°ízení a není efektivní pro kaºdé za°ízení vytvá°et nový speciální software pro analýzu a prezentaci diagnostických dat. Pro návrh systému je vhodné pouºít nejmodern¥j²ích technologií a postup· tak, aby byl p°ípraven práv¥ na moºnost zpracování dat u nových za°ízení stejn¥ jako na import nových p°ístup· k analýze diagnostických dat. Jak bylo zmín¥no vý²e, ºelezni£ní zabezpe£ovací za°ízení pro²la za dobu své existence velkým vývojem. Tento pokrok lze rozd¥lit do t°í etap. Jako první existovala mechanická zabezpe£ovací za°ízení typu pevná páka. Následovala za°ízení reléová, která p°inesla nejen vy²²í komfort obsluhy, ale hlavn¥ bezpe£nost. Sou£asnými zabezpe£ovacími za°ízeními jsou za°ízení elektronická, která p°inesla nové moºnosti v °ízení ºelezni£ní dopravy, stejn¥ jako vy²²í bezpe£nost. K moderním elektronickým za°ízením pat°í také systém elektronických kolejových obvod· KOA1 od spole£nosti AD Praha s.r.o. KOA1 je komplexní systém, který zahrnuje velké mnoºství software i hardware nejr·zn¥j²ího druhu. KOA1 je v dne²ní dob¥ nasazeno ve více neº 30 stanicích a je pln¥ napojeno na diagnostický systém LDS, který se u AD pouºívá. Je tak k dispozici velké mnoºství diagnostických dat, která je nutné vyhodnotit a prezentovat. K dispozici je online diagnostika pro servisní pracovníky. Neexistuje v²ak systém pro analýzu oine diagnostických dat. Pro tato data pak je nutné navrhnout zp·soby vyhodnocení a prezentace a za£lenit je do univerzálního systému pro zpracování a zobrazení vyhodnocení diagnostických dat.

2

KAPITOLA 1.

ÚVOD

Cílem diplomové práce je navrhnout a vytvo°it univerzální systém pro vyhodnocování a prezentaci diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení. Tento systém musí být jednodu²e roz²í°itelný o vyhodnocení diagnostických dat z r·zných za°ízení. Do systému je nutné pak za£lenit £ást, která se týká diagnostiky kolejových obvod· KOA1. Motivací pro realizaci této diplomové práce je moºnost vyuºití nejnov¥j²ích technologií a postup· pro návrh systému, který se bude reáln¥ vyuºívat u nejv¥t²ího £eského dodavatele zabezpe£ovací techniky AD. V neposlední °ad¥ je také nutné uvést týmový projekt, jehoº je diplomová práce sou£ástí. Jedná se o projekt diagnostiky KOA1, který v sob¥ zahrnuje p°enos diagnostických dat ze stani£ních zabezpe£ovacích za°ízení na server KOAS, jejich organizaci a archivaci (viz diplomová práce Bc. Michal Pet°ík), stejn¥ jako p°ehledy stanic a vyuºitých jednotek a práv¥ vyhodnocení diagnostických dat. Server obsahuje ve²keré aplikace a data, které se týkají provozu, diagnostiky a správy za°ízení KOA1. Výsledkem této diplomové práce bude multiplatformní aplikace pro vyhodnocování a prezentaci diagnostických dat z ºelezni£ních zabezpe£ovacích za°ízení, která umoºní budoucí roz²i°ování o vyhodnocení dat z r·zných za°ízení, a s konkrétní implementací vyhodnocení a prezentace dat z diagnostiky kolejových obvod· KOA1.

KAPITOLA 2.

POPIS PROBLÉMU A SPECIFIKACE CÍLE

3

2 Popis problému a specikace cíle 2.1 Deklarace zám¥ru Seznámit se s ºelezni£ními zabezpe£ovacími za°ízeními, zejména systémem KOA1. Seznámit se se strukturou a zp·sobem uloºení diagnostických dat. Navrhnout efektivní zp·sob vyhodnocování a prezentace diagnostických dat a dal²ích informací z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení. Rozpracovat £ást systému týkající se diagnostiky kolejových obvod· KOA1.

2.2 Projekt Projekt nese jméno

Rubicon.

Rubikon (italsky Rubicone) je °eka na Apeninském poloostrov¥

v severní Itálii, kde kdyº Julius Caesar v roce 49 p°. n. l. °eku p°ekro£il, podle °ímského historika Suetonia zde pronesl slavnou frázi

Kostky jsou vrºeny (Alea iacta est). Slovní p°esmy£kou pak vznikne slovo Rubik, coº je autor Rubikovy kostky. Ta je zvolena jako logo projektu, který p°edstavuje n¥kolik odd¥lených oblastí (kaºdou symbolizuje jedna kosti£ka), které dohromady vytvo°í kompletní funk£ní aplikaci (symbolizuje sloºená kostka) s moºností p°idání £i vým¥ny kosti£ky. Logo projektu je zobrazeno na obrázku 2.1.

Obrázek 2.1: Logo projektu Rubicon

2.3 elezni£ní zabezpe£ovací systémy 2.3.1 Obecn¥ elezni£ní zabezpe£ovací za°ízení je soubor technických prost°edk· a vazeb mezi nimi, které p°ispívají k bezpe£nosti ºelezni£ního provozu. P°edev²ím tím, ºe kontrolují p°ípadn¥ i nahrazují £innost dopravních zam¥stnanc· p°i °ízení ºelezni£ní dopravy. Tato kapitola je zpracována dle [22] a [26].

2.3.2 T°íd¥ní •

Podle místa pouºití:

•

Stani£ní zabezpe£ovací za°ízení (SZZ), Traóvé zabezpe£ovací za°ízení (TZZ), P°ejezdová zabezpe£ovací za°ízení (PZZ), Vlaková zabezpe£ovací za°ízení (VZZ), Spádovi²tní zabezpe£ovací za°ízení (SpZZ).

Podle technologie (provedení závislostí):

mechanická, elektromechanická,

4

KAPITOLA 2.


elektrodynamická, elektropneumatická, reléová, hybridní, elektronická.

2.3.3 Struktura Infrastrukturní ºelezni£ní zabezpe£ovací systém má následující uspo°ádání (od nejniº²ího k nejvy²²ímu) - viz obr. 2.2: 1. první úrove¬ První úrove¬ tvo°í periferní za°ízení, která jsou umíst¥na v koleji²ti. Jedná se o:

•

kolejové obvody v£etn¥ prvk· pro vysílání kód· bodového vlakového zabezpe£ova£e,

•

traóvé majáky pro vysílání kód· bodového vlakového zabezpe£ova£e,

•

po£íta£e náprav,

•

náv¥stidla v£. výstraºník· a p°ejezdník·,

•

p°estavníky a výkolejky,

•

p°ejezdové závory.

2. druhá úrove¬ Druhá úrove¬ zaji²úje v plném rozsahu zpracování informací, které p°icházejí z 1. a 3. úrovn¥, a pokud jsou spln¥ny p°íslu²né bezpe£nostní podmínky, umoºní °ízení p°íslu²né periferie z 1. úrovn¥. Tuto úrove¬ tvo°í:

•

provád¥cí £ásti stani£ních zabezpe£ovacích za°ízení,

•

traóvá zabezpe£ovací za°ízení 2. a 3. kategorie,

•

provád¥cí £ásti p°ejezdových zabezpe£ovacích za°ízení,

•

stacionární £ásti vlakových zabezpe£ovacích za°ízení.

3. t°etí úrove¬ T°etí úrove¬ zaji²úje v plném °ízení ºelezni£ního provozu a nouzovou obsluhu p°íslu²ného zabezpe£ovacího za°ízení. Na základ¥ informací, které p°icházejí z 2. úrovn¥, p°íslu²ný dopravní zam¥stnanec nebo automat °ídí ºelezni£ní dopravu. Tuto úrove¬ tvo°í:

•

°ídící £ásti stani£ních zabezpe£ovacích za°ízení, jejichº sou£ástí je rovn¥º obsluha traóvých zabezpe£ovacích za°ízení,

•

kontrolní sk°í¬ky nebo °ídící stanice p°ejezdových zabezpe£ovacích za°ízení,

•

dálkové ovládání zabezpe£ovacích za°ízení v£. p°íslu²ných °ídících automat·.

Na obrázku 2.2 je zobrazena struktura ºelezni£ního zabezpe£ovacího systému. ipky uvedené v obrázku znázor¬ují sm¥ry tok· relevantních informací mezi strukturami jednotlivých úrovní.

2.3.4 Kolejové obvody Kolejový obvod je sou£ástí zabezpe£ovacího za°ízení dráhy. Slouºí k zji²t¥ní volnosti koleje, p°ípadn¥ téº k p°enosu informace na dráºní vozidlo.

KAPITOLA 2.


5

Obrázek 2.2: Struktura ºelezni£ního zabezpe£ovacího systému

Funkce kolejového obvodu Kolejový obvod funguje na principu pr·chodu elektrického proudu p°es kolejnice, dvojkolí dráºních vozidel a relé zabezpe£ovacího za°ízení. Podle zapojení lze rozd¥lit kolejové obvody na

•

sériové (dvojkolí a relé jsou zapojena za sebou - proud prochází vinutím relé p°i obsazené koleji),

•

paralelní (dvojkolí a relé jsou zapojena vedle sebe - proud prochází vinutím relé p°i neobsazené koleji).

V sou£asnosti se pouºívají tém¥° výhradn¥ obvody paralelní, protoºe sériové zapojení nelze povaºovat za bezpe£né.

Kolejové obvody a elektrická trakce P·vodní kolejové obvody pouºívaly pro svou funkci stejnosm¥rný proud. Se zavád¥ním elektrické trakce (a elektrického vytáp¥ní) v²ak vznikl problém, ºe kolejnice musely odvád¥t zp¥tný trak£ní proud. Tento problém byl v praxi vy°e²en následujícími zp·soby:

•

jednopásové kolejové obvody - zp¥tný trak£ní proud je veden pouze jednou kolejnicí zatímco druhá slouºí jako sou£ást KO,

•

dvoupásové kolejové obvody - zp¥tný trak£ní proud je odvád¥n ob¥ma kolejnicemi a pro funkci kolejového obvodu je pouºit st°ídavý proud o jiné frekvenci neº je frekvence trak£ního proudu. Pak je moºné pomocí stykových transformátor· odd¥lit zp¥tný trak£ní proud od signálního proudu kolejového obvodu.

6

KAPITOLA 2.


Princip £innosti kolejového obvodu Princip £innosti je jednoduchý. P°i volném kolejovém obvodu je kolejový obvod napájen a kolejové relé nebo kolejový p°ijíma£ je buzen. Vybuzený stav znamená, ºe daný elektrický kolejový úsek je volný. P°i vjetí vlaku nebo jednoho dvojkolí do elektrického kolejového úseku - objeví se v n¥m relativn¥ malý rezistor R², který zp·sobí pokles nap¥tí na vstupních svorkách takové hodnoty, ºe kolejové relé nebo kolejový p°ijíma£ p°estane být buzen. Nebuzené kolejové relé nebo kolejový p°ijíma£ znamená, ºe kolejový úsek je obsazen. Princip £innosti kolejového obvodu je patrný z obrázku 2.3.

Paralelní kolejové obvody Paralelní kolejový obvod (viz obrázek 2.3) je zapojen následovn¥: Na jednom konci izolovaného úseku trat¥ se nachází zdroj proudu. Na druhém konci je zapojeno relé. Pokud se na koleji nenachází ºádné kolejové vozidlo, prochází proud p°es relé a úsek je povaºován za volný. Pokud je kolej obsazena, prochází proud p°es dvojkolí vozidla, relé se rozpojí a tak ozna£í úsek jako obsazený.

Obrázek 2.3: Paralelní kolejový obvod

Rozd¥lení kolejových obvod· podle bezpe£nostních kategorií (SN 34 2613) •

KO 4. kategorie Vyzna£ují se tím, ºe z vybuzené polohy kolejového p°ijíma£e lze bezpe£n¥ odvodit, ºe elektrický kolejový úsek je volný.

•

KO 3. kategorie

KAPITOLA 2.

7


Platí v²e o 4. kategorii s výjimkou oblastí jazyku výhybek. Oblast výhybek jazyk· nelze uspo°ádat tak, aby bylo moºno pln¥ se spolehnout na správnou funkci KO.

•

KO 2. kategorie Týká se dvoupásových KO. Informace o volnosti KO závisí na elektrické celistvosti elektrického kolejového úseku. Jedná se zpravidla o volné v¥tve na výhybkových kolejových obvodech.

•

KO 1. kategorie Informace o volnosti KO závisí na elektrické celistvosti elektrického kolejového úseku.

2.4 Technická diagnostika Tato kapitola je zpracována dle [30].

2.4.1 Diagnostika a technická diagnostika Diagnostika a diagnóza jsou odvozená slova z dia-gnosis , coº v °eckém jazyku znamená skrze poznání . Technická diagnostika se zabývá metodami a prost°edky zji²óvání technického stavu objektu. Technickou diagnostikou se v¥t²inou rozumí diagnostika bezdemontáºní a nedestruktivní.

2.4.2 Diagnóza, prognóza, geneze Diagnóza je analýza okamºitého stavu objektu neboli vyhodnocení provozuschopnosti objektu za daných podmínek. Základním úkolem diagnostiky je: 1. detekce poruchy (tj. identikace úplné nebo £áste£né poruchy objektu), 2. lokalizace poruchy (tj. ur£ení místa poruchy v objektu). S detekcí resp. lokalizací souvisí tzv. diagnostické pokrytí (hloubka detekce) resp. diagnostické rozli²ení (hloubka lokalizace) udávající po£et detekovaných resp. lokalizovaných poruch daným diagnostickým algoritmem. V¥t²inou se pro vyjád°ení diagnostického pokrytí a diagnostického rozli²ení pouºívá relativní vyjád°ení ruch

L

Lrel

tj. pom¥r detekovatelných resp. lokalizovatelných po-

k celkovému po£tu moºných (tj. na objektu denovaných) poruch

Lrel =

L Lmax

Lmax

neboli

· 100[%]

Prognóza je extrapolace vývoje technického stavu do budoucnosti. Cílem prognózy je nap°. stanovit na základ¥ statistických vyhodnocení pravd¥podobnost bezporuchového stavu v následujícím období nebo na základ¥ postupných poruch stanovení termín· díl£ích a generálních oprav nebo vým¥ny ur£itého bloku objektu. Geneze je analýza p°í£in poruchy nebo p°ed£asného zhor²ení technického stavu objektu.

2.4.3 Diagnostické prost°edky, diagnostický systém Diagnostické prost°edky tvo°í soubor technických za°ízení (nap°. senzorové systémy, testery apod.) a pracovních postup· pro analýzu a vyhodnocení stavu diagnostikovaného objektu. Pracovními postupy jsou diagnostické algoritmy (tj. sled elementárních úkon· diagnostikování) v£etn¥ programového vybavení pro generování a vyhodnocování test·, metody výb¥ru diagnostických veli£in, sestavení matematických model· aj.

8

KAPITOLA 2.


Diagnostické prost°edky mohou být realizovány bu¤ jako sou£ást objektu (tzv. vnit°ní prost°edky) nebo samostatn¥ (tzv. vn¥j²í prost°edky). Sou£asný trend je zabudovávat diagnostické prost°edky p°ímo do objektu, coº je v²ak n¥kdy ekonomicky neúnosné. Pro snímání diagnostických veli£in se stále £ast¥ji pouºívají integrované senzory se zabudovanou elektronikou a vybavené tzv. inteligencí. Jako vn¥j²í prost°edky jsou vhodné univerzální m¥°icí systémy vyuºitelné jak pro diagnostiku, tak pro provozní m¥°ení nebo pro vývojové práce. Do této skupiny pat°í nap°. frekven£ní, logické a p°íznakové analyzátory, £íslicové osciloskopy, £íslicové záznamníky, m¥°icí systémy na bázi PC výpo£etní techniky, testery desek s analogovými a £íslicovými obvody aj. Diagnostický systém je systém tvo°ený diagnostickými prost°edky, diagnostikovaným objektem a obsluhou. Základní rozd¥lení diagnostických systém· je systémy ON LINE a OFF LINE. Diagnostické systémy ON LINE diagnostikují, tj. vyhodnocují, technický stav objektu p°i provozu. Synonymem pojmu ON-LINE systém je pojem provozní diagnostický systém. Monitorovací systém je systém ON LINE, který je trvale p°ipojený k diagnostikovanému objektu. Monitorování je tedy trvalé sledování stavu objektu s pr·b¥ºným vyhodnocováním mezních stav· objektu, p°i kterých je nutno objekt odstavit a u dokonalej²ích systém· je dopln¥no vyhodnocováním trendu postupných poruch. Speciálním p°ípadem systému ON-LINE jsou automatické diagnostické systémy tvo°ící zp¥tnovazební kybernetický systém. Diagnostikovaný objekt lze pak povaºovat za °ízený komplex a diagnostické za°ízení za °ídicí systém. Tyto systémy, v¥t²inou podporované po£íta£em (tzv. CAT - Computer Aided Testing), umoº¬ují v p°ípad¥ pouºití redundantních (tj. záloºních) funk£ních blok· °e²it poruchovou situaci bez lidské obsluhy, automatickou lokalizaci poruchy, interaktivní vedení obsluhy p°i lokalizování poruchy, automatické generování zku²ebních (tj. testovacích) signál·, propojení s expertním diagnostickým systémem aj. Diagnostické systémy OFF-LINE mají strategii odli²nou u r·zných rem. Nej£ast¥ji se pod pojmem systém· OFF-LINE rozumí systémy, u nichº se diagnostikování provádí testem, p°i£emº je diagnostikovaný objekt mimo provoz. Algoritmy diagnostikování testem se d¥lí na nezávislé (tj. kombina£ní) a závislé (sekven£ní). P°i nezávislých testováních je sled jednotlivých krok· testu nezávislý na výsledcích p°edcházejících krok· testu. Hodnocení provozuschopnost je tedy podmín¥no provedením v²ech krok· testu. Naproti tomu závislý algoritmus testu realizuje kroky testu v závislosti na výsledcích p°edcházejících krok·. Je z°ejmé, ºe závislý test je £asov¥ mnohem mén¥ náro£ný. Testovací signály mohou být p°ivedeny na provozní vstupy objektu, p°i£emº lze simulovat cílové chování objektu nebo jsou testovací signály p°ipojeny jak na provozní vstupy tak na pomocné diagnostické vstupy objektu. Oproti vý²e uvedeným systém·m ON-LINE umoº¬ují takto denované systémy OFF-LINE mnohem snadn¥ji lokalizovat poruchy, detekovat poruchové stavy, které se p°i daném provozním vyuºití objektu neprojeví, a vyuºít speciálních metod k diagnostikování postupných poruch. Metody diagnostikování testem lze vyuºít i u systém· ON-LINE za p°edpokladu ,ºe testovací signály na pomocných vstupech nenaru²í °ádný chod objektu. Aby výsledky diagnózy byly srovnatelné, je nutné b¥hem diagnostikování nastavit p°edem denované a £asov¥ nem¥nné hodnoty vstupních a °ídících signál·. N¥které rmy, zabývající se diagnostikou strojních za°ízení, prezentují pod pojmem OFF-LINE systém, u kterého se rozd¥luje diagnostikování do dvou £asových etap. Nejprve se za provozu malým p°enosným diagnostickým za°ízením provede m¥°ení na diagnostikovaném objektu p°i sou£asném vyhodnocení p°ípadného p°ekro£ení p°ípustných mezí. Nam¥°ená a £áste£n¥ zpracovaná data se uloºí do pam¥ti p°enosného za°ízení a vlastní zpracování nam¥°ených dat tj. vyhodnocení stavu objektu, porovnání s minulým stavem s prognózy se v £asovém odstupu realizuje mimo diagnostikovaný objekt na centrálním po£íta£i. Toto uspo°ádání umoº¬uje vytvo°it podobn¥ jako u systém· ON-LINE databanku technického stavu kaºdého objektu, vyhodnocovat na základ¥ trendu postupných poruch optimální £asové okamºiky dal²ích diagnostických m¥°ení

KAPITOLA 2.

9


a zpracovat prognostické údaje o dob¥ ºivota a tedy stanovit dobu nutné opravy jednotlivých blok· objektu. Diagnostické systémy se vlastním provedením dále li²í dle toho, ve které fázi technického ºivota bude objekt diagnostikován. Rozhodujícími fázemi bude výroba (diagnostika p°i vstupní kontrole, v pr·b¥hu výroby, p°i výstupní kontrole), provoz objektu, servis a údrºba objektu. Údrºba se v sou£asné dob¥ realizuje t°emi zp·soby: 1. údrºbou p°i poru²e objektu (run to breakdown), 2. údrºbou dle £asového plánu (time based preventive maintenance), 3. údrºbou dle skute£ného stavu objektu (on condition maintenance). Nejmén¥ vhodným je zp·sob údrºbou p°i poru²e objektu. Úplná porucha funk£ní £ásti objektu má za následek výpadek technologického procesu, moºnost následného poru²ení dal²ích objekt·, naru²ení bezpe£nosti provozu. Nej£ast¥ji je tato údrºba aplikována u elektronických analogových a £íslicových obvod· tj. také u výpo£etní techniky. Pokud nelze výpadek p°ipustit, je nutné pouºít d°íve uvedený systém s automatickým zálohováním. Údrºba dle £asového plánu je vykonávána na základ¥ statistických podklad· oprav jednotlivých komponent· objektu v p°edem pevn¥ stanovených £asových úsecích. Tento zp·sob údrºby je ekonomicky nevýhodný, nebo´ k údrºb¥ objektu dochází bu¤ p°íli² brzo nebo p°íli² pozd¥, p°i£emº je známo, ºe technické parametry za°ízení se velmi £asto zhor²í pouhou demontáºí a montáºí. Nicmén¥ se tento zp·sob praktikuje z bezpe£nostních d·vod· nap°. u letadel, v jaderné energetice aj. Ekonomicky nejvhodn¥j²í je údrºba dle skute£ného stavu objektu.

2.4.4 Technický stav objektu, strukturní a procesní parametr Obecn¥ objekt povaºujeme za systém daný mnoºinou elementárních prvk·, mnoºinou vzájemných vazeb (relací) mezi t¥mito prvky a mnoºinou vazeb (relací) mezi prvky a prvky okolí (tj. vn¥j²ím prost°edím).Takto denovaný systém ozna£ujeme jako rela£ní strukturu objektu. Elementární prvky jsou reálné £ásti objektu a vazby mezi prvky jsou dány nap°. silovým p·sobením, sdílením energie, p°edáváním informace apod. Ve vztahu s okolím lze vy£lenit dv¥ podstatné podmnoºiny prvk· a to vstupní a výstupní prvky s relací v·£i prvk·m okolí. Prvky systému v²ak nemusí být jen reáln¥ existující hmotné prvky, ale také atributy t¥chto prvk· tj. vlastnosti prvk· nebo parametry charakterizující tyto vlastnosti tj. numerické nebo nenumerické prom¥nné. Podobn¥ vazby systému lze nahradit jejich atributy tj. jejich vlastnostmi. Denování rela£ní struktury systému záleºí na ú£elu vyuºití. V diagnostice je ú£elem stanovení technického stavu objektu. Denujeme si tedy diagnostickou rela£ní strukturu

DS

takto:

DS = {A; R}, kde

A = ai

je mnoºina vybraných atribut· tj. vlastností nebo parametr· ur£ujících technický

stav hmotných prvk· objektu, (parametry) prvk· mnoºiny

R = rj

je mnoºina relací nebo jejich atribut· mezi vlastnostmi

A.

Technický stav diagnostikovaného objektu je dán mnoºinou vybraných vlastností prvk· objektu (prvky jsou zvoleny dle diagnostického rozli²ení) a odpovídajících relací v daném £asovém okamºiku. Tyto vlastnosti se £asem m¥ní (v·le v uloºení mechanických díl·, klidový proud opera£ního zesilova£e, proudové zesílení tranzistoru uvnit° integrovaného £íslicového obvodu apod.) aº do okamºiku, kdy elementární prvek svým chováním zp·sobí poruchu celého objektu nebo jeho £ásti. Lze tedy také technický stav objektu specikovat jako schopnost objektu vykonávat poºadované funkce za stanovených podmínek jeho uºívání. Strukturní parametr charakterizuje kvantitativn¥ nebo kvalitativn¥ fyzikální, chemické nebo geometrické vlastnosti prvk· zvoleného subsystému tj. elementárních dále jiº ned¥litelných prvk·

10

KAPITOLA 2.


nebo skupin prvk·. Strukturní parametry se tedy mohou týkat elektrického motoru nebo jeho komponent, tj. elektrického vinutí (nap°. izolace), loºisek (nap°. zad°ení, trhlina), h°ídele (ohyb, nevyváºenost) atd. Ned¥litelnost prvk· znamená, ºe se nebudeme nap°. zabývat strukturními parametry uvnit° integrovaných obvod· apod. Pokud nemají strukturní parametry charakter numerických prom¥nných (nap°. kmitání), je nutné provést zobrazení (transformaci) nenumerických parametr· na parametry numerické (efektivní hodnota rychlosti kmitání). Procesní parametry charakterizují procesní vlastnosti prvk· tj. vlastnosti podstatné pro cílové chování objektu. Procesní parametry lze £lenit na vstupní, výstupní, vnit°ní a stavové u dynamických systém·. Dle pouºitého diagnostického modelu lze denovat

DS

dv¥ma zp·soby:

1. jako mnoºinu pro £innost objektu základních procesních vlastností jednotlivých subsystém· a mnoºinu p°íslu²ných relací. Takto denovaný systém je vhodný pro modely chování neboli funk£ní modely. 2. Jako mnoºinu vstupních a strukturních parametr· a mnoºinu p°íslu²ných relací. Strukturní parametry nesouvisí p°ímo s chováním objektu, ale jsou podstatné pro technický stav objektu a p°i p°ekro£ení ur£itých mezí strukturních parametr· dojde k naru²ení chování objektu. Ob¥ uvedené denice mnoºiny

A

lze kombinovat. Pro diagnostikování je pak nutno mnoºinu

strukturních parametr· doplnit procesními parametry v£etn¥ p°íslu²ných relací. P°i volb¥ procesních a strukturních parametr· je nutno respektovat p°edem denovanou rozli²ovací schopnost (v £ase i amplitud¥) diagnostických prost°edk· tj. m¥°icích systém· a metod.

2.4.5 Diagnostická veli£ina Diagnostická veli£ina je veli£ina, která je nositelem informace o technickém stavu objektu. V technické diagnostice je nejv¥t²ím problémem, ºe p°eváºnou £ást vnit°ních strukturních a procesních parametr· nelze p°ímo m¥°it, protoºe m¥°icí body jsou bez neºádoucí demontáºe nep°ístupné. Nezbývá nám tedy nic jiného, neº se spokojit s p°ístupnými výstupními prvky systému (a´ uº se jedná o hlavní funk£ní výstupy nebo °adu pomocných diagnostických výstup·) a vnit°ní parametry z nam¥°ených diagnostických veli£in prost°ednictvím diagnostických algoritm· více nebo mén¥ p°esn¥ odhadnout. Musíme si uv¥domit, ºe pokud je diagnostická veli£ina nep°ímou funkcí m¥°eného strukturního parametru, pak kauzalita (tj. p°í£ina -> následek) bude mít v¥t²inou stochastický charakter. Stochastické chování v²ak vykazují i p°ímo m¥°itelné prvky systému. Jedné p°í£in¥ m·ºe odpovídat více r·zných následk· a naopak jeden následek m·ºe být vyvolán r·znými p°í£inami. Pokud jsou diagnostickými veli£inami p°ímo m¥°itelné strukturní parametry, pak tyto parametry musí mít charakter numerických prom¥nných. Pokud tomu tak není, je nutno provést zobrazení (tj. transformaci) nenumerických prom¥nných na numerické. Pro vyhodnocení technického stavu jednotlivého prvku jsou n¥kdy vyuºívány statistické charakteristiky nebo veli£iny, které jsou z více diagnostických veli£in vypo£ítány (jedná se o tzv. diagnostické ukazatele). Vlastnosti nedostupných prvk· lze £asto deterministicky nebo statisticky denovat jen na základ¥ mnoºiny p°íznak· technického stavu. Mnoºinu p°íznak· je moºno denovat jako soubor nep°ímo m¥°itelných projev· zm¥n vlastností prvku na dostupném míst¥ tj. mnoºinu nam¥°ených hodnot. Za p°íznaky lze povaºovat nejen hodnoty fyzikálních diagnostických veli£in, ale také hodnoty odvozené z t¥chto veli£in jako nap°. efektivní hodnota, £asová konstanta p°echodové charakteristiky, st°ední hodnota, sloºka frekven£ního spektra aj. Pro p°íznakovou analýzu technického stavu objektu lze vyuºít teorii rozpoznávání obraz·, shlukovou analýzu a faktorovou analýzu.

KAPITOLA 2.

11


2.4.6 Porucha, provozuschopnost, funk£nost Provozuschopnost objektu je stav, ve kterém je objekt schopen vykonávat stanovené funkce dle technických podmínek. Porucha je jev ur£ující ukon£ení provozuschopnosti. Funk£nost objektu je schopnost objektu vykonávat ur£itou funkci dle technických podmínek. Objekt tedy m·ºe být ve stavu funk£ním, ale ne provozuschopném. Objekt je neporu²ený (tj. bez závad, správný), jestliºe technické stavy v²ech elementárních prvk· objektu jsou v mezích technických podmínek. Objekt tedy m·ºe být funk£ní, provozuschopný, ale není bez závad. V technické praxi z°ídka kdy dochází k tzv. Náhlé poru²e (tj. poru²e vzniklé skokovou zm¥nou jednoho nebo více strukturních parametr· objektu). Technický stav se zhor²uje postupn¥ (u strojních objekt· toto zhor²ování zp·sobuje nap°. adhezní, abrazivní, erozivní, kavita£ní, únavové a vibra£ní opot°ebení, koroze, deformace, ²í°ící se mikrotrhlina, u integrovaného obvodu degrada£ní zm¥ny v polovodi£i zp·sobené nedokonalým zapouzd°ením, ne£istým materiálem apod.). Porucha v uvedených p°íkladech vzniká postupn¥ tj. n¥které hodnoty diagnostických parametr· se £asem m¥ní a blíºí se k p°ípustným mezím.

2.4.7 Rozpoznávání v diagnostice Obecn¥ o rozpoznávání Podstatou kaºdého rozpoznávání, identikování nebo rozli²ování objekt· nebo jev· v reálném sv¥t¥ je pozorování. lov¥k toto rozpoznávání d¥lá intuicí tj. na základ¥ ºivotních zku²eností. V technické diagnostice je rozpoznávání technického stavu synonymem projmu diagnóza neboli v²echny diagnostické algoritmy jsou algoritmy rozpoznávání. Nejjednodu²²ím rozpoznáváním je jednozna£n¥ p°i°azení ur£ité hodnoty diagnostické veli£iny ur£ité diagnóze, uloºení této hodnoty do pam¥ti po£íta£e a pouhou komparací vzorové a nam¥°ené hodnoty rozpoznávání stavu objektu. áste£n¥ je tato metoda vyuºívána v algoritmech rozpoznávání stav· v £íslicových a analogových elektronických obvodech. U sloºitých objekt·, u nichº dochází k rozpoznávání stavu na základ¥ nep°ímo zm¥°ených parametr·, lze aplikovat metody neboli

rozpoznávání obraz· .

Pattern Recognition

Základní pojmy z teorie rozpoznávání obraz· Teorie rozpoznávání obraz· je modelování £innosti £lov¥ka neboli je to jedna z metod °e²ících problematiku um¥lé inteligence. Rozpoznávání je za°azování (t°íd¥ní) hmotných p°edm¥t· nebo jev· reálného sv¥ta do t°íd (skupin), které jsou charakterizovány stejnými vlastnostmi. Jevem m·ºe být proces, chování, signál, ale také technický stav objektu, subojektu nebo jednotlivého prvku, p°ípadn¥ i geometrické uspo°ádání objektu. Abychom mohli stanovit, podle jakých vlastností se bude t°íd¥ní realizovat, musíme nejprve denovat nad daným objektem nebo jevem systém. Vlastnosti p°edm¥t· £i jev· zji²újeme m¥°ením nebo pozorováním. P°i vyhodnocování t¥chto vlastností dochází k vícenásobné transformaci informace (zvlá²t¥ u nep°ímých m¥°ení) a výsledkem vyhodnocení je vlastn¥ jen obraz skute£nosti. Z tohoto d·vodu hovo°íme o teorii rozpoznávání obraz·. Teorie rozpoznávání obraz· (tj. r·zné algoritmy klasikátor· a algoritmy výb¥ru a minimalizace po£tu p°íznak·) je velmi rozsáhlá a v celé ²í°i ji není moºné uvést v tomto dokumentu. Obecn¥ existují dv¥ základní skupiny metod rozpoznávání:

1. metody syntaktické, 2. metody p°íznakové.

12

KAPITOLA 2.


Metody syntaktické vyuºívají k rozpoznávání jevu nebo p°edm¥tu tzv. primitiv (symbol·, abeced) ne£íselného (kvalitativního) charakteru. Obrazem zobrazujícím jev nebo p°edm¥t je slovo neboli °et¥zec sestavený ze symbol·. Syntaktické metody jsou pouºívány nap°. v robotice v tzv. Po£íta£ovém vid¥ní. P°íznakové metody vyuºívají k rozpoznávání jevu nebo p°edm¥tu uspo°ádanou mnoºinu £ísel (p°íznak·) charakterizujících vlastnosti objektu. Terminologie p°íznakových metod:

•

vektor p°íznak· je uspo°ádaná n-tice p°íznak· tj. £ísel, která jsou bu¤ reprezentována nam¥°enými daty fyzikálních veli£in nebo charakteristikami vypo£ítanými z nam¥°ených dat. Pokud systém není invariantní, je nutno p°íznaky zm¥°it ve stejném £asovém okamºiku. Vektor p°íznak· lze nap°. geometricky zobrazit spojnicí bodu v n-rozm¥rném Eukleidovském prostoru s po£átkem tohoto prostoru. Jednotlivé sou°adnice v n-rozm¥rném prostoru zobrazují osy jednotlivých prom¥nných (tj. m¥°ených nebo odvozených veli£in). P°íznaky mohou nabývat diskrétních nebo spojitých hodnot. Znamená to tedy, ºe mohou být vyjád°eny i v binární form¥ nebo ve tvaru £íselných interval·.

•

Obraz je popis (reprezentace) konkrétního jevu konkrétním vektorem p°íznak·.

•

Obrazový prostor je daný mnoºinou v²ech moºných obraz·. V geometrické interpretaci je obrazovým prostorem Eukleidovský n-rozm¥rný prostor. Pokud dochází p°ed klasikací k redukci po£tu sloºek vektoru p°íznak· oproti po£tu nam¥°ených dat, zavádí se p°íznakový prostor.

•

T°ída je skupina p°edm¥t· nebo jev·, které mají stejnou, p°edem ur£enou vlastnost (resp. vlastnosti).

•

Proces rozpoznávání je dán rozd¥lením obrazového (resp. p°íznakového) prostoru na vzájemn¥ disjunktní podprostory (tj. podmnoºiny) zobrazující jednotlivé t°ídy, zm¥°ením veli£in a jejich transformaci do vhodného tvaru pro zpracování obrazu a vlastní klasikací.

•

Klasikace je p°i°azení t°ídy (resp. indikátoru t°ídy) konkrétnímu vektoru p°íznak·.

•

Indikátor t°ídy je symbol ozna£ující t°ídu kaºdému vektoru p°íznak·.

•

Klasikátor je za°ízení, které dle rozhodovacího pravidla za°azuje p°edm¥ty nebo jevy do jednotlivých t°íd neboli zobrazuje p°íznakový prostor na mnoºinu (indikátor·) t°íd. Klasikátory lze d¥lit na deterministické a statistické. Dle apriorních znalostí o objektech nebo jevech se d¥lí na pracující s u£itelem a bez u£itele. Dále existují klasikátory s pevným po£tem p°íznak· a sekven£ní. Sekven£ní se vyzna£ují tím, ºe po£et pouºitých p°íznak· je prom¥nlivý a ur£ovaný klasikátorem.

•

Rozhodovací pravidlo je jednohodnotová skalární funkce s vektorovým argumentem, která p°i°azuje kaºdému vektoru p°íznak· t°ídu (resp. indikátor t°ídy).

KAPITOLA 2.

•


13

Diskrimina£ní funkce je skalární funkce s vektorovým argumentem, která denuje v n-rozm¥rném p°íznakovém prostoru nadplochy, které odd¥lují vektory p°íznak· do jednotlivých t°íd.

•

Etalon je reprezentativní vektor p°íznak· pro danou t°ídu.

•

Trénovací mnoºina Algoritmus rozhodování (klasikování)ú lze bu¤ denovat na základ¥ analýzy daného systému (p°ípadn¥ jeho zjednodu²eného modelu) optimálním rozhodovacím pravidlem nebo ho lze získat tzv. U£ením s u£itelem p°i pouºití trénovací mnoºiny obraz·. Není-li k dispozici u£itel neboli apriorní znalosti jsou malé, vychází se z p°edpokladu, ºe obrazy pat°ící do stejné t°ídy tvo°í shluky geometricky si blízkých obraz· (tzv. u£ení bez u£itele). Vyhledáváním shluk· se zabývá teorie shlukové analýzy. Vyhledané shlukly pak ztotoº¬ujeme s pojmem t°ída.

Teorie rozpoznávání obraz· v technické diagnostice V technické diagnostice je rozpoznávání technického stavu základním p°edpokladem pro stanovení diagnózy tj. bu¤ k ur£ení provozuschopnosti £i neprovozuschopnosti objektu nebo k rozli²ení (lokalizaci) poruchových stav· jednotlivých subobjekt·. Z teorie rozpoznávání obraz· se obvykle pouºívají p°íznakové metody. Cílem t¥chto metod je p°i°azení ur£ité diagnózy zm¥°eným p°íznak·m u diagnostikovaných objekt· stejného typu nebo u jednoho objektu v r·zných £asových obdobích. P°i aplikaci teorie rozpoznávání obraz· v diagnostice:

•

Vektor p°íznak· je vektorem hodnot diagnostických veli£in (respektive vektorem charakteristik odvozených z diagnostických veli£in). Jinak °e£eno p°íznakový vektor je obrazem technického stavu, jemuº odpovídá i-tá diagnóza.

•

Obraz je obrazem technického stavu objektu.

•

T°ída je diagnózou tj. skupinou vlastností denujících ur£itý technický stav objektu.

•

Etalon je vzorovým vektorem p°íznak· stanoveným pro ur£itou diagnózu 1. heuristicky, 2. analyticky, 3. m¥°ením na objektu se známou diagnózou, 4. simulací na reálném objektu nebo jeho modelu. Obrazy technického stavu jsou tedy dány n-rozm¥rnými vektory £íselných hodnot diagnostických veli£in, snímaných sou£asn¥ v r·zných £ástech diagnostikovaného objektu. V maticovém zápisu denujeme obraz technického stavu sloupcovým vektorem

~x = [x1 , x2 , ..., xn ]T ,

14

KAPITOLA 2.

kde £ísla

x1 , x2 , ..., xn


jsou hodnoty diagnostických veli£in nebo vypo£ítaných charakte-

ristik udávající sou°adnice vektoru v n-rozm¥rném prostoru. Jednotlivým t°ídám v procesu rozpoznávání odpovídají jednotlivé diagnózy technických stav· diagnostikovaného objektu. Tyto t°ídy neboli diagnózy jsou obvykle p°edem známy. Mnoºin¥ diagnóz

D

D = {D1 , D2 , ..., Dr } je jednozna£n¥ p°i°azena mnoºina indikátor· diagnóz

D

D = {D1 , D2 , ..., Dr }. •

Rozhodovací pravidlo

Di = d(~x) je pravidlo, které p°i°adí kaºdému konkrétnímu vektoru p°íznak· odpovídající indikátor diagnózy.

Za°azování objekt· dle jednotlivých diagnóz se d¥je klasikátorem, coº je za°ízení s tolika vstupy, kolik je snímaných diagnostických veli£in nebo odpovídajících charakteristik a s jedním výstupem, který udává indikátor diagnózy, do které klasikátor dle pouºitého algoritmu za°adil obraz technického stavu (obr. 2.4).

Obrázek 2.4: Systém pro rozpoznávání obraz· technického stavu objektu

Pro aplikaci metody p°íznakového rozpoznávání obraz· je nutné: 1. zvolit optimální mnoºství diagnostických veli£in tak, aby byla získána maximální nebo alespo¬ dostate£ná rozli²ovací (tj. diskrimina£ní) schopnost klasikátoru p°i minimálním mnoºství veli£in a zm¥°ených dat, 2. stanovit algoritmus tj. stanovit dle zvoleného systému nad diagnostikovaným objektem pravidla pro klasikaci do jednotlivých diagnóz.

KAPITOLA 2.


15

2.5 AD Praha s.r.o. AD Praha, s.r.o., je významným ryze £eským dodavatelem a výrobcem zabezpe£ovací, telekomunika£ní, informa£ní a automatiza£ní techniky, zejména se zam¥°ením na oblast kolejové a silni£ní dopravy v£etn¥ telematiky a dal²ích technologií. Spole£nost zaji²úje výzkum, vývoj, projektování, výrobu, montáº, rekonstrukce a servis za°ízení, systém· i investi£ních celk· v t¥chto hlavních oblastech:

•

ºelezni£ní doprava,

•

provoz metra a závodová doprava,

•

oblast telekomunika£ních, informa£ních a radiových systém·,

•

telematické aplikace,

•

silni£ní, signaliza£ní a parkovi²tní systémy,

•

nové telefonní a rozhlasové systémy pro °ízení ºelezni£ní dopravy a pro informování cestujících.

Produkty, které spole£nost vyrábí, zachycují nejnov¥j²í technické a uºitné trendy. Ve rm¥ AD je v sou£asné dob¥ zam¥stnáno tém¥° 2000 pracovník·. Díky své dlouholeté tradici, která se datuje jiº od roku 1954, si rma získala stálou pozici a vedoucí postavení mezi ostatními dodavateli ve svém oboru. Logo spole£nosti je zobrazeno na obrázku 2.5.

Obrázek 2.5: Logo spole£nosti AD Praha s.r.o.

Tato kapitola je zpracována dle [2].

2.5.1 KOA1 Charakteristika •

Jsou dvoupásové kolejové obvody ohrani£ené izolovanými styky,

•

pouºití pro elektrikované trat¥ a pro trat¥ s nezávislou trakcí s elektrickým vytáp¥ním osobních voz·,

•

minimální poºadavky na údrºbu,

•

centralizovaná výstroj,

•

detekce elektrické celistvostí kolejnicových pás·,

•

tvo°en t°emi HW paralelními v¥tvemi.

16

KAPITOLA 2.


Základní technický popis •

Vyhovuje evropským normám organizace CENELEC,

•

systém umoº¬uje snadnou modikaci stávajících KO vým¥nou aº 8 kolejových relé za 1 soubor TCR,

•

sou£ástí systému jsou kolejové p°ijíma£e TCR detekují kolejová nap¥tí s digitálním vyhodnocením,

•

kontrola izolovaných styk· je provád¥na elektronickou detekcí fázového posunu,

•

KOA1 umoº¬ují provoz hnacích vozidel s vy²²ími ohroºujícími proudy v oblastech signálních kmito£t·,

•

p°enos kód· liniového vlakového zabezpe£ova£e.

Obecný popis KOA1 jsou dvoupásové kolejové obvody ohrani£ené izolovanými styky. Pouºití na tratích elektrizovaných trak£ní proudovou soustavou 25 kV, 50 Hz nebo 15 kV, 16 2/3 Hz, na stejnosm¥rných trak£ních proudových soustavách 3 kV nebo 1,5 kV nebo 0,75 kV a na neelektrizovaných tratích. Sou£ástí KOA1 jsou soubory kolejových p°ijíma£· (TCR), které detekují kolejová nap¥tí v£etn¥ jejich fázového nato£ení v·£i místnímu (referen£nímu) nap¥tí a provádí jejich následné digitální vyhodnocení. Systém TCR je tvo°en t°emi HW paralelními v¥tvemi, takºe p°i poru²e jedné z v¥tví je pln¥ zachována funk£nost. Jedna v¥tev systému TCR je zobrazena na obrázku 2.6. P°ijíma£e TCR jsou pak umíst¥ny ve stojanu, který je zobrazen na obrázku 2.7.

Obrázek 2.6: Jedna v¥tev souboru kolejových p°ijíma£· TCR KOA1

Kontrola izolovaných styk· je provád¥na elektronickou detekcí fázového posunu.

KAPITOLA 2.


17

Obrázek 2.7: Stojan elektronických kolejových obvod· KOA1

Systém umoº¬uje snadnou modikaci stávajících KO vým¥nou aº 8 kolejových relé za jeden soubor kolejových p°ijíma£· TCR. Blokové schéma zapojení je zobrazeno na obrázku 2.8. Na obrázku 2.9 je pak vid¥t stykový transformátor kolejových obvod· v koleji²ti. KOA1 umoº¬ují provoz hnacích vozidel s vy²²ími ohroºujícími proudy v oblastech signálních kmito£t· - p°i p°ekro£ení vý²e limitu detekuje TCR obsazení kolejového úseku.

Diagnostika KOA1 Diagnostická data KOA1 jsou uloºena v systému LDS. Jejich staºení je moºné na p°enosný po£íta£ p°ímo ve stanici, viz obrázek 2.10. Diagnostická data budou také ukládána na Produk£ní server KOAS. Za ú£elem správy a koncentrace diagnostických dat je vyvíjena aplikace Spider, která bude data z KOA1, resp. z LDS ve stanici ukládat na server KOAS. Diagnostická data KOA1 se d¥lí na:

•

diagnostická data m¥°ení - nap¥tí a fáze na kanálech (kolejových obvodech),

•

stavová diagnostická data - p°íznaky po startu, lehké poruchy detekované jednotkou mimo blok, lehké poruchy detekované jednotkou ve v¥tvi, p°íznaky základních schopností duálních v¥tví podílet se na funkci (detekováno jednotkou), závaºné poruchy detekované jednotkou v ní samotné, souhrnné p°íznaky poruch detekovaných jednotkami duálních v¥tví, souhrnné p°íznaky p°ipravenosti a chodu jednotek AVR (3x AVR = 1x TCR).

2.5.2 Lokální diagnostický systém LDS Obecn¥ LDS je modulární provozn¥ diagnostický systém pro sb¥r, archivaci, klasikaci a sledování provozních dat lokáln¥ dostupných diagnostikovaných za°ízení. Poºadované m¥°ené hodnoty jsou získávány od m¥°icí úst°edny, distribuovaného m¥°icího systému a inteligentních senzor·. Dal²í informace o systému LDS jsou uvedeny v kapitole re²er²e.

18

KAPITOLA 2.


Obrázek 2.8: Blokové schéma zapojení KOA1

Vlastnosti •

Soust°ed¥ná stavová a m¥°icí diagnostika ºelezni£ních zabezpe£ovacích a ostatních za°ízení,

•

architektura server - klient p°ipravená na roz²í°ení o dal²í diagnostikovaná za°ízení,

•

velký d·raz kladený na vizualizaci dat tak, aby bylo uºivateli poskytnuto maximální mnoºství uºitné hodnoty diagnostického systému v p°ehledné form¥,

•

podpora síóvého °e²ení - sdílení DOZ-1 nebo Intranet D.

2.5.3 KOA Server Obecn¥ Systém KOA Server je tvo°en Produk£ním serverem a klienty Kalibrátor/Tester, Installer, Updater, SpiderDMST, SpiderDMR. KOA Server slouºí také jako úloºi²t¥ diagnostických dat, tj. místo pro jejich koncentraci, zpracování atd. Na serveru je také rela£ní databáze, kterou vyuºívají dal²í aplikace serveru. KOA Server je p°ístupný pro uºivatele v síti internet, a to prost°ednictvím Produk£ního serveru.

Schéma Schéma KOA Serveru je zobrazeno na obrázku 2.11.

2.5.4 Produk£ní server AD Praha Obecn¥ Produk£ní server je internetová aplikace, která je sou£ástí serveru KOAS. Je dostupná p°es uºivatel·v webovský prohlíºe£ [16]. Produk£ní server je modulární aplikace, která obsahuje moduly r·zných ú£el· a pro r·zné uºivatele. Ukázka rozhraní PServeru je zobrazena na obrázku 2.12.

KAPITOLA 2.


19

Obrázek 2.9: Stykový transformátor KO v koleji²ti

2.5.5 Spider Aplikace Spider je sou£ástí KOAS Serveru a slouºí ke sb¥ru a koncentraci diagnostických dat ze stanic, ve kterých jsou umíst¥ny kolejové obvody KOA1. Logo aplikace Spider je zobrazeno na obrázku 2.13.

2.6 Cíle diplomové práce Cílem této diplomové práce je navrhnout univerzální a revolu£ní systém pro vyhodnocování a prezentaci diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení tak, aby bylo moºné ho jednodu²e roz²í°it o vyhodnocování diagnostických dat z dal²ích za°ízení. Následn¥ je cílem tento systém pak implementovat a do systému za£lenit £ást, která se týká diagnostiky kolejových obvod· KOA1. Z vý²e uvedených poºadavk· a cíl· diplomové práce je z°ejmé, ºe pro vývoj je nutné pouºít metodiku vývoje software. To je z d·vodu velikosti projektu, jeho °ádného £asového dokon£ení a kvality výsledného produktu. Optimisté si °íkají: V²ak ono to dopadne dob°e. A za£nou rovnou programovat. Samoz°ejm¥ nejde velký systém naprogramovat rovnou, tak si tipnou základní £ást, nejd°íve naprogramují tu a pak po £ástech systém vyvíjejí dále - podobn¥ jako vla²tovka staví hnízdo. Ov²em instinkty vla²tovek se vyvíjely desítky milión· let, programátorské instinkty se vyvíjely podstatn¥ krat²í dobu. Pokud takový systém funguje, má tyto vlastnosti [13]:

•

D¥lá n¥co trochu jiného neº by m¥l. D¥lá to, co si programátor myslí, ºe mu zadavatel °íkal, nikoliv to, co uºivatelé pot°ebují.

•

Jedna a tatáº v¥c je °e²ena na r·zných místech n¥kolikrát, po kaºdé trochu jinak. To je o£ekávaný d·sledek toho, ºe kaºdý problém se °e²í lokáln¥ - v závislosti na práv¥ realizované £ásti.

•

Opravy a zm¥ny jsou velmi obtíºné a drahé.

20

KAPITOLA 2.


Obrázek 2.10: Diagnostika KOA1 pomocí p°enosného PC

Obrázek 2.11: Schéma KOA Serveru

Chceme-li se vyhnout potíºím, musíme mít celkovou koncepci. Ta ov²em není samoú£elná, musíme mít na v¥domí dva její hlavní cíle:

•

Up°esnit a dob°e pochopit zadání, abychom ned¥lali n¥co zbyte£n¥ (nebo n¥co neopomenuli).

•

Rozd¥lit systém na podsystémy tak, aby jednotlivé podsystémy ²lo d¥lat postupn¥ nebo paraleln¥ - podle toho, kolik skupin projektant· budeme mít. Rozd¥lení systému na podsystémy má mnoho dal²ích funkcí (nap°. samostatné testování p°i zm¥nách, znovupouºitelnost).

Cílem celkové koncepce je pochopit logiku systému, rozd¥lit jej na £ásti a ur£it rozhraní mezi t¥mito £ástmi tak, aby jej nebylo nutno v budoucnu m¥nit. Toho cíle dosáhneme bu¤ tím, ºe zam¥stnáme geniální projektanty, nebo pouºitím metodik. Pro vývoj projektu byla zvolena metodika Unied Process a jako podp·rný nástroj pro tvorbu model· a správu projektu Enterprise Architect (viz dále).

KAPITOLA 2.


21

Obrázek 2.12: Ukázka rozhraní Produk£ního Serveru AD Praha

Obrázek 2.13: Logo aplikace Spider

2.6.1 Unied Process Proces vývoje softwaru (SDP, Software Development Process) známý rovn¥º jako metodika tvorby softwarového vybavení (SEP, Software Engineering Process) denuje p°i vývoji softwaru otázky kdo, co, kdy a jak. SEP je proces, v n¥mº jsou uºivatelské poºadavky realizovány vytvo°eným softwarem. Metodika USDP (Unied Software Development Process) je pr·myslovým standardem SEP (metodiky tvorby softwarového vybavení) pocházejícím od autor· jazyka UML. Ten je b¥ºn¥ ozna£ován jako Unied Process (zkrácen¥ UP, viz publikace Unied Software Development Process (Unikovaná metodika vývoje softwaru)). Projekt UML vznikl z pot°eby nabídnout jak vizuální jazyk, tak proces tvorby softwarového vybavení. To, co známe dnes pod pojmem UML, je jazykovou £ástí projektu, metodika UP je £ástí procesní. Metodika UP není na rozdíl od jazyka UML standardem organizace OMG. Neexistuje tedy ºádný standard metodiky tvorby softwarového vybavení (SEP), který by jazyk UML dopl¬oval. Metodika UP je zaloºena na metodách Ericsson (Ericsson Approach, 1967), Rational (Rational Objectory Process, 1996-1997) a na dal²ích zdrojích vycházejících z nejlep²ích postup·. Je to pragmatická a ov¥°ená metoda vývoje softwaru, která zahrnuje nejlep²í ov¥°ené postupy.

22

KAPITOLA 2.


1

Tato kapitola je zpracována dle [27] .

2.6.2 Enterprise Architect Enterprise Architect je nástroj pro modelování pomocí UML [4]. Enterprise Architect je profesionální nástroj pro snadnou tvorbu vývojových diagram· a dal²ích schémat pot°ebných p°i vývoji aplikací. EA podporuje následující modely - Business Process Model, Class model, Use Case model, Activity model, Sequence model a Component model. Výstup je moºný ve formátu RTF (dokumentace) a ve formátu XMI pro spolupráci s ostatními produkty. Enterprise Architect podporuje mimo jiné i generování zdrojových kód· programovacích jazyk· C++, C#, Java, Delphi, VB.Net, Visual Basic, ActionScript a PHP. Logo aplikace je zobrazeno na obrázku 2.14.

Obrázek 2.14: Logo aplikace Enterprise Architect

1

Kniha je pouºita p°i vývoji projektu i pro popis aktivit pouºitý v dal²ích £ástech této práce

KAPITOLA 3.

23

STRUKTURA PRÁCE

3 Struktura práce V této kapitole bude popsána struktura práce ve vztahu k vyty£eným cíl·m. Struktura práce pak vyplývá z pouºité metodiky vývoje software a z poºadavk· na projekt kladených. Metodika UP je iterativní a p°ír·stková (inkrementa£ní). Iterativní aspekt znamená rozklad projektu na men²í podprojekty (iterace), které systému dodávají funkce dávkov¥, nebo na p°ír·stky (inkrementy), které vedou k tvorb¥ pln¥ funk£ního systému. Jinými slovy to znamená, ºe tvo°íme software v procesu postupných up°es¬ování na²eho kone£ného zám¥ru. Tento postup se zásadn¥ li²í od kaskádové tvorby softwaru, která byla zaloºena na d·sledné posloupnosti analýzy, návrhu a tvorby. Ke klí£ovým pracovním postup·m metodiky UP, jako je analýza, se ve skute£nosti vracíme v pr·b¥hu projektu n¥kolikrát. Ke správnému porozum¥ní metodiky UP je t°eba porozum¥t iteracím. Základní my²lenka je velice prostá - historie ukazuje, ºe £lov¥ku se obecn¥ vzato °e²í lépe men²í problémy neº v¥t²í. Snaºíme se tedy o rozloºení velkého softwarového projektu na °adu men²ích sledek? Snaz²í správa a úsp¥²né dokon£ení. Kaºdý ze zmi¬ovaných za iteraci.

miniprojekt· . Vý miniprojekt· je povaºován

V kaºdé iteraci existuje p¥t základních pracovních postup· (workows), jeº zaru£ují, co je t°eba ud¥lat, a zp·sob, jakým toho dosáhnout: 1. Poºadavky - zachycují to, co by m¥l systém d¥lat. 2. Analýza - vybrou²ení poºadavk· a jejich strukturování. 3. Návrh - realizace poºadavk· v architektu°e systému. 4. Implementace - tvorba softwaru. 5. Testování - ov¥°ení, zda implementace funguje tak, jak se od ní o£ekává. Podle t¥chto fází metodiky je také strukturován dal²í text této diplomové práce. Na po£átku budou denovány poºadavky na projekt, tj. funk£ní a nefunk£ní poºadavky a p°ípady uºití. V dal²í £ásti pak bude popsána dal²í fáze projektu, a to práv¥ analýza. V analýze budou popsány nalezené analytické t°ídy analýzou pojm· business domény. V neposlední °ad¥ bude také uvedena realizace specikovaných p°ípad· uºití. Kapitola návrh pak popisuje vlastní návrh systému, jak bude náln¥ implementován. Sem pat°í volba technologií, knihoven a podp·rných nástroj·. Stejn¥ tak sem pat°í u£in¥ná rozhodnutí vlastního objektového modelování (návrhové vzory GoF [25], GRASP vzory...). Implementace popisuje výslednou implementaci systému a ukazuje r·zné aspekty, které byly pro implementaci vyuºity. Implementace vychází ze zmín¥ného návrhu a jen p°evádí návrh do nální spustitelné podoby, které rozumí po£íta£. P°i jakémkoliv vývoji softwaru je nutné otestovat vytvo°enou aplikaci. Nejinak je tomu i u tohoto projektu. Testování popisuje stejnojmenná kapitola. Následuje kapitola nasazení, která pak popisuje nální nasazení hotového produktu ve spole£nosti AD Praha s.r.o. V této kapitole je popsána struktura umíst¥ní produktu v rámci pracovi²t¥ VPR12, pro které je aplikace vyvíjena. Poslední kapitolou je zhodnocení návrhu a vývoje softwaru s p°ípadným probráním moºného dal²ího pokra£ování projektu. Diplomová práce je zakon£ena záv¥rem, který hodnotí výsledky celého projektu.

24

KAPITOLA 3.

STRUKTURA PRÁCE

KAPITOLA 4.

REERE STÁVAJÍCÍCH EENÍ

25

4 Re²er²e stávajících °e²ení 4.1 Úvod V této £ásti diplomové práce je provedena re²er²e aplikací podobného typu, jako je zadání diplomové práce. Je velice obtíºné nalézt aplikaci, která p°esn¥ odpovídá zadání diplomové práce. V¥t²inou se dají nalézt popisy aplikací, které provád¥jí online diagnostiku. Ale i u nich není snadné nahlédnout

do vnit°ku aplikace, nebo´ jsou samoz°ejm¥ st°eºeným know-how kaºdé rmy. Neexistuje v²ak ºádné standardn¥ dodávané °e²ení pro analýzu oine diagnostických dat, redukci t¥chto dat a vytvá°ení redukovaných formát· dat pro uloºení do databáze. V této kapitole je popsán sou£asný stav diagnostiky ºelezni£ních zabezpe£ovacích za°ízení, tj. online diagnostika.

4.2 Diagnostická za°ízení Diagnostika zabezpe£ovacích za°ízení umoº¬uje okamºité zji²óvání závad na za°ízení v£etn¥ pr·b¥ºné kontroly m¥°ených obvod· a soustav tak, ºe lze tyto závady do jisté míry predikovat. Na diagnostikovaném za°ízení se jednozna£n¥ zvy²uje jeho pohotovost a tím i bezpe£nost a plynulost ºelezni£ního provozu. Nezanedbatelným p°ínosem diagnostiky zabezpe£ovacích za°ízení je taktéº uleh£ení zji²t¥ní závady na daném za°ízení a hlavn¥ vy²²í efektivita a kvalita údrºby. Diagnostická za°ízení jsou umíst¥ny p°ímo v technologii (reléovém sálu, p°ejezdu, sk°íni autobloku) a umoº¬ují diagnostikovat tato za°ízení vzdálená i n¥kolik desítek kilometr· od diagnostického vyhodnocovacího pracovi²t¥. Jsou schopny po°izovat informace o stavech vn¥j²ích za°ízení (náv¥stidel, výhybek, výkolejek, ...) a m¥°it r·zné elektrické i neelektrické veli£iny. Zp·sob snímání informací z diagnostikovaných za°ízení je °e²en tak, aby nemohlo dojít k nebezpe£nému ovlivn¥ní £inností zabezpe£ovacích za°ízení (ZZ) a zhor²ení jejich bezpe£nostních kritérií. Snímané informace ze zabezpe£ovacích za°ízení se p°ená²ejí po metalických, optických vedeních nebo radio p°enosem do diagnostického vyhodnocovacího pracovi²t¥. Zde jsou shromaº¤ovány a je moºno s nimi dále pracovat. Speciální aplikace, které zpracovávají získané informace z diagnostických za°ízení obsahují ²iroké spektrum kvalitních diagnostických nástroj·. Lze jimi provád¥t dálkovou diagnostiku a výsledky sledování diagnostikovaných za°ízení zpracovat do podoby m¥°ících protokol·, retrospektivních výpis· nebo p°ehledných a názorných graf·. Taktéº umoº¬ují provád¥t zp¥tnou animaci chování diagnostikovaných za°ízení (nap°. funkce náv¥stidel, chod p°estavník·, funkce kolejových obvod·, p°ítomnost nap¥tí, stav záloºních zdroj·, ...). Dal²í nep°ehlédnutelnou výhodou je nep°etrºité sledování ur£ených veli£in nap°. nap¥tí, proudu, kmito£tu, st°ídy. P°i p°ekro£ení denovaných mezí diagnostické za°ízení automaticky upozorní pracovníka diagnostického vyhodnocovacího pracovi²t¥ na blíºící se závadu. Díky t¥mto moderním diagnostickým nástroj·m lze v£as odhalit i poruchy, které jsou teprve ve fázi tvorby p°edpoklad·, tedy mnohem d°íve, neº by k nim do²lo, a v£asným zásahem jim takto p°edcházet. Aplikování a následné vyuºívání diagnostických za°ízení vede zcela jednozna£n¥ ke sniºování náklad· na údrºbu a provoz zabezpe£ovacích za°ízení. Kaºdé diagnostické za°ízení musí vyhovovat v²em podmínkám kladeným na diagnostiku p°edpisem D ZTP 6/2000-SZ pe£ovacích za°ízení [33].

Základní technické poºadavky pro diagnostiku ºelezni£ních zabez-

Cena diagnostických za°ízení umíst¥ných v sou£asné dob¥ na trhu se pohybuje v relativn¥ velkém intervalu po£ínaje °ádov¥ od desetitisíce za jedno záznamové za°ízení a kon£e u statisíc· korun £eských za velkoplo²né diagnostické systémy. V dal²ím textu se blíºe seznámíme s univerzálním diagnostickým systémem zabezpe£ovacích za°ízení - Remote 96 a s LDS spole£nosti AD Praha s.r.o. Tato kapitola, stejn¥ jako následující, je p°evzata a zpracována dle [28] a [29]. Ke zpracování

26

KAPITOLA 4.


byly vyuºity také vnit°ní materiály k systému LDS [31] spole£nosti AD Praha s.r.o.

4.3 Remote 96 - univerzální diagnostický systém zabezpe£ovacích za°ízení Obecn¥ Univerzální diagnostický systém Remote 96 je komplex multiprocesorových stanic, které jsou umíst¥ny p°ímo v technologii a diagnostikují tato za°ízení vzdálená i n¥kolik desítek kilometr· od diagnostického centra. Po°izují informace o stavech vn¥j²ích za°ízení (náv¥stidel, výhybek, výkolejek, ...) a m¥°í r·zné elektrické i neelektrické veli£iny. Snímané informace se p°ená²ejí po metalických vedeních, optických vedeních nebo radio p°enosem do diagnostického vyhodnocovacího pracovi²t¥. Zde jsou shromaº¤ovány a je moºno s nimi dále pracovat. Aplikace Remote 96 snímané informace zobrazuje dle symboliky JOP a ZTP-D. Taktéº obsahuje ²iroké spektrum diagnostických nástroj·. Lze jimi provád¥t dálkovou diagnostiku a výsledky sledování diagnostikovaných za°ízení zpracovat do podoby m¥°ících protokol·, retrospektivních výpis· nebo p°ehledných názorných graf·. Také umoº¬uje provád¥t zp¥tnou grackou a textovou animaci chování diagnostikovaných za°ízení (nap°. funkce náv¥stidel, chod p°estavník·, funkce kolejových obvod·, p°ítomnost nap¥tí, stav záloºních zdroj·, ...). Dal²ím nástrojem systému Remote 96 je nep°etrºité sledování ur£ených veli£in nap°. nap¥tí, proudu, kmito£tu, st°ídy. P°i p°ekro£ení denovaných mezí systém automaticky upozorní pracovníka kontrolního centra na blíºící se závadu. Univerzální diagnostický systém Remote 96 vyhovuje v²em podmínkám kladeným na diagnostiku p°edpisem D ZTP 6/2000-SZ [33].

Moºnosti nasazení systému Remote 96 Systém Remote 96 je moºné nasadit do dvou úrovní. Za první úrove¬ lze ozna£it nasazení diagnostického systému na diagnostických vyhodnocovacích pracovi²tích údrºby. V p°ípad¥, ºe se diagnostikuje ucelený traóvý úsek, tzn. v²echna stani£ní, traóvá a p°ejezdová zabezpe£ovací za°ízení daného úseku, tak lze denovat druhou úrove¬ nasazení. Za tu lze povaºovat vyuºívání systému Remote 96 na centrálním diagnostickém pracovi²ti, kde dochází ke sb¥ru a analýze dat z jednotlivých diagnostických vyhodnocovacích pracovi²´ za pomoci tzv. synchroniza£ního kanálu. Obrovská variabilita systému Remote 96 nabízí i dal²í moºnosti nasazení dle specických p°ání zákazníka. Univerzální diagnostický systém Remote 96 lze vyuºívat pro diagnostikování v²ech stani£ních, traóvých a p°ejezdových zabezpe£ovacích za°ízení b¥ºn¥ pouºívaných u D s.o., nap°. stani£ní zabezpe£ovací za°ízení ESA 11/22, p°ejezdové zabezpe£ovací za°ízení AD 71 nebo traóvé zabezpe£ovací za°ízení - centralizovaný autoblok. Uvedený vý£et za°ízení, která je schopen systém Remote 96 diagnostikovat, není kone£ný. Obecn¥ lze °íci, ºe tento univerzální diagnostický systém lze vyuºít pro diagnostikování jakéhokoliv za°ízení, na kterém je moºné sledovat jeho stavy, pop°ípad¥ veli£iny.

Záv¥rem Uvedené funkce a zp·soby moºného nasazení univerzálního diagnostického systému Remote 96 umoº¬ují splnit obecné cíle, které jsou na diagnostiku zabezpe£ovacích za°ízení kladeny zvý²ení pohotovosti za°ízení, uleh£ení zji²t¥ní závady, zvý²ení efektivity a kvality údrºby a tím i zvý²ení bezpe£nosti a plynulosti ºelezni£ního provozu. Diagnostický systém Remote 96 na²el své uplatn¥ní p°i diagnostikování SZZ ESA 11/22 a ETB na koridorových tratích. Na vedlej²ích tratích se uplatnil zejména p°i diagnostikování PZS typu AD 71 a VÚD.

KAPITOLA 4.


27

4.4 Lokální diagnostický systém LDS Obecn¥ Lokální diagnostický systém LDS je modulární provozn¥ diagnostický systém pro sb¥r, archivaci, klasikaci a sledování provozních dat lokáln¥ dostupných diagnostikovaných za°ízení. Portfolio diagnostikovaných za°ízení tvo°í jednotlivá zabezpe£ovací za°ízení dodávaná rmou AD Praha s.r.o.:

•

stani£ní zabezpe£ovací za°ízení typu SZZ-ETB nebo ESA 11,

•

panel elektronického rozhraní EIP,

•

systém kolejových obvod· KOA1,

•

systém automatického bloku elektronického ABE-1,

•

p°ejezdová zabezpe£ovací za°ízení typu AD 71, PZZ-RE, PZZ-AC, PZZ-EA,

•

univerzální napájecí zdroje UNZ-1, UNZ-2, UNZ-3 a m¥ni£e DAK-2.X.

Poºadované m¥°ené hodnoty jsou získávány od:

•

m¥°icí úst°edny DISTA,

•

p°enosového a m¥°icího systému TEDIS,

•

distribuovaného m¥°icího systému DMS,

•

inteligentních senzor· (nap°. teploty).

Základní popis uspo°ádaní a funkce LDS LDS je tvo°en diagnostickým lokálním serverem (DLS), jehoº hlavními úkoly jsou sb¥r dat, jejich dlouhodobá archivace, generování diagnostických hlá²ení na základ¥ jejich analýzy a zp°ístupn¥ní dat diagnostickému lokálnímu p°ístupovému po£íta£i (DLA). Úkolem DLA je vizualizace aktuálních diagnostických dat a zpracování archivovaných dat pro pot°eby uºivatele. DLA umoº¬uje uºivateli denovat krajní meze hodnot sledovaných veli£in, na jejichº základ¥ dojde ke klasikaci poruchy. V roz²í°ené verzi umoº¬uje DLS zasílaní servisních SMS zam¥stnanc·m údrºby prost°ednictvím GSM modulu. Schéma LDS je zobrazeno na obrázku 4.1. LDS m·ºe svými funkcemi ve spolupráci s m¥°ící úst°ednou DISTA nebo s m¥°icími jednotkami DMS nahradit n¥která pravidelná m¥°ení provád¥ná ru£n¥ udrºujícími zam¥stnanci ve smyslu p°edpis· pro údrºbu diagnostikovaného zabezpe£ovacího za°ízení. LDS m·ºe zpracovávat diagnostická data poskytovaná systémem TEDIS. LDS ve spolupráci s TEDIS v²ak nenahrazuje pravidelná m¥°ení provád¥ná ru£n¥ udrºujícími zam¥stnanci. ídicí a archiva£ní procesy DLS jsou °e²eny v prost°edí OS Linux RedHat 6.2 s upraveným realtimovým jádrem. Velký d·raz je kladen na vizualizaci dat tak, aby bylo uºivateli poskytnuto maximální mnoºství uºitné hodnoty diagnostického systému v p°ehledné form¥. Proto je DLA °e²en na v²eobecn¥ známé a obecn¥ zvládnuté softwarové platform¥ Microsoft Windows 2000 (Windows XP). Pro zobrazování a diagnosticky relevantní ovládání systému je pouºita obdobná symbolika a pracovní postupy vycházející ze Základních technických poºadavk· na jednotné obsluºné pracovi²t¥. Plná síla moºností LDS vynikne v rámci liniových staveb, kdy lze s vyuºitím síóvé komunikace zp°ístupnit data v rámci daného úseku (cluster) z libovolného DLS libovolnému DLA. Tato

28

KAPITOLA 4.


vlastnost LDS umoº¬uje provozovateli vznik míst soust°ed¥né údrºby. Jeden úsek obsahuje typicky cca 10 ú£astník· - DLS. Pro komunikaci mezi DLS umíst¥nými v jednotlivých ºelezni£ních stanicích obvykle slouºí komunika£ní prost°edky dálkového p°enosu dat SZZ tvo°ící síóvé prost°edí WAN. Tyto prost°edky jsou obvykle sdílené spole£n¥ s dal²ími systémy. Jednotný £as je po datové síti LDS ²í°en prost°ednictvím standardního protokolu NTP. P°ipojením po£íta£· DLS do Intranetu D (p°ípadn¥ jiné technologické datové sít¥) lze zp°ístupnit diagnostická data vzdáleným po£íta£·m DLA.

Diagnostika systému KOA1 Jednotky analogových p°ijíma£· AVR3, které tvo°í jednotlivé v¥tve p°íslu²ného souboru kolejových p°ijíma£· TCR, obsahují diagnostickou pam¥´ ZPR (Zero Power RAM) se zálohovaným napájením realizovaným ze zabudované baterie a obsahující hodiny reálného £asu, ve které jsou archivována jak stavová, tak diagnostická data v£etn¥ £asového p°íznaku. V p°ípad¥, ºe jednotky analogových p°ijíma£· AVR3 jsou umíst¥ny ve stav¥dlové úst°edn¥ nebo v objektu na trati vybavené lokálním diagnostickým systémem LDS, je moºno p°ená²et diagnostické informace z pam¥ti ZPR prost°ednictvím hlavního procesoru a koprocesoru lokální diagnostiky do lokálního diagnostického systému LDS. Diagnostické informace z pam¥ti ZPR je moºno prost°ednictvím hlavního procesoru a koprocesoru servisní diagnostiky p°ená²et p°es rozhraní RS232 do p°enosného PC. Diagnostickými koprocesory lokální i servisní diagnostiky je realizováno rozhraní k zabrán¥ní neoprávn¥nému p°ístupu z lokální nebo servisní diagnostiky do hlavního procesoru. innost servisní diagnostiky je shodná s £inností lokální diagnostiky s tím rozdílem, ºe tato diagnostika je ur£ena pro servisní £innost. Aktivuje se p°ipojením standardního kabelu

typu nulový modem do sb¥rnice RS232 na konektor, který je umíst¥n na £elní £ásti jednotky analogových p°ijíma£· AVR3, a obsluhou programu KODIAG v p°enosném PC. P°i p°ipojení servisní diagnostiky sou£asn¥ funguje i lokální diagnostický systém LDS.

Záv¥rem Popisovaný systém LDS je univerzální diagnostický systém, který podobn¥ jako Remote 96 umoº¬uje splnit obecné cíle, které jsou na diagnostiku zabezpe£ovacích za°ízení kladeny. Architektura server - klient systému je pak p°ipravena na roz²í°ení o dal²í diagnostikovaná za°ízení. Výhodou systému je také kvalitní vizualizace dat tak, aby bylo uºivateli poskytnuto maximální mnoºství uºitné hodnoty diagnostického systému v p°ehledné form¥. V neposlední °ad¥ je nutné zmínit také podporu síóvého °e²ení (sdílení DOZ nebo Intranet D).

4.5 Shrnutí re²er²e V této £ásti re²er²ních zpracování diagnostiky ºelezni£ních zabezpe£ovacích systém· byly popsány reálné systémy, které se pouºívají na £eských ºeleznicích. Systém Remote 96 od spole£nosti AK Signal Brno a.s. byl velmi pouºívaným systémem pro online diagnostiku v eské republice u provozovatele drah D a.s. Sou£asn¥ nejvyuºívan¥j²ím systémem je popsaný systém LDS od spole£nosti AD Praha s.r.o. Tato kapitola nám také dává p°edstavu o sou£asném stavu diagnostiky zabezpe£ovacích za°ízení, jako je vizualizace diagnostických dat a jejich archivace.

KAPITOLA 4.


Obrázek 4.1: Schéma LDS

29

30

KAPITOLA 4.


KAPITOLA 5.

POADAVKY

31

5 Poºadavky 5.1 Úvod Tato kapitola popisuje poºadavky kladené na projekt Rubicon. Je²t¥ p°edtím, neº se provede objektov¥ orientovaná analýza £i návrh, musí být vytvo°en alespo¬ rámcový p°ehled o tom, £eho vlastn¥ chceme dosáhnout. Musíme zjistit, co má systém vlastn¥ d¥lat. V²e by m¥lo být popsáno v terminologii, kterou pouºívají uºivatelé budoucího systému. Vytvá°í se vy²²í specikace toho, co má systém d¥lat. Tento proces je ozna£ován jako inºenýrství poºadavk· (requirements engineering). Inºenýrství poºadavk· spo£ívá ve stanovení sluºeb, které by m¥l vyvíjený systém poskytovat, a omezení, za nichº musí pracovat. V této kapitole budou denovány funk£ní a nefunk£ní poºadavky, vyhledány akté°i a p°ípady uºití v£etn¥ detail· p°ípad· uºití a popsáno sledování poºadavk· aº k p°ípad·m uºití.

5.2 Specikace systémových poºadavk· 5.2.1 Ú£el Poºadavek lze denovat jako dva typy poºadavk·:

•

specikaci toho, co by m¥lo být implementováno . Rozli²ujeme

Funk£ní poºadavky (functional requirements), jeº ur£ují, jaké chování bude systém nabízet,

•

Nefunk£ní poºadavky (non-functional requirements), které specikují vlastnosti nebo omezující podmínky daného systému.

Specikace systémových poºadavk· pln¥ popisuje funkce systému. Také popisuje nefunk£ní poºadavky, omezení návrhu a dal²í faktory d·leºité z hlediska poskytnutí kompletního a komplexního popisu poºadavk· na software. Kapitola je dále strukturována dle kategorií poºadavk·.

5.2.2 Funk£ní poºadavky Funkce 1. Rubicon bude zpracovávat diagnostická data z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení. 2. Rubicon bude ov¥°ovat validitu diagnostických dat. 3. Rubicon bude analyzovat diagnostická data. 4. Rubicon bude vyhodnocovat diagnostická data. 5. Rubicon bude ukládat vyhodnocení diagnostických dat do persistentního úloºi²t¥. 6. Rubicon bude prezentovat vyhodnocená diagnostická data. 7. Rubicon bude spravovat administrátor systému. 8. Rubicon bude prezentovat stav systému administrátorovi systému.

32

KAPITOLA 5.

POADAVKY

5.2.3 Nefunk£ní poºadavky Pouºitelnost •

Navigace 1. Pro navigaci se vyuºívá naviga£ní panel, který je konzistentní a zobrazen na v²ech stránkách na stejném míst¥. 2. Uºivatel by nikdy nem¥l skon£it na prázdné stránce bez ºádných naviga£ních prvk·. 3. Uºivatel by m¥l být vºdy informován o stavu systému a p°ípadné chyb¥. 4. Na kaºdé stránce by m¥li být v horní £ásti popisky tak, aby uºivatel v¥d¥l, kde se práv¥ nachází. 5. Pro stránky, které je nutné tisknout, musí být výstup p°izp·soben pro tisk. 6. Pokud jsou gracké obrázky nebo ikony pouºity jako odkazy, pak by m¥la být jejich reprezentace uºivateli z°ejmá ze symbolu. 7. Mechanismus vyhledávání by m¥l být exibilní, aby dovoloval uºivatel·m specikovat r·zná kritéria pro vyhledávání. 8. Uºivatelé by nem¥li být nuceni nep°im¥°en¥ vyuºívat posuvník· na stránce, aby shlédli celý obsah stránky. 9. Nápov¥da by m¥la být jednodu²e dostupná z libovolné stránky a instrukce by m¥li být poskytnuty pro v²echny moºnosti, podle kterých uºivatel m·ºe kontaktovat centrum podpory pro více informací.

•

Konzistence 1. Prezentace informací a vzhled stránky by m¥ly být vytvo°eny co nejvíce konzistentní. 2. Snahou je umístit text, tla£ítka a obrázky, které se objevují na více stránkách, na stejnou pozici na kaºdé stránce.

•

Jazyk 1. Pouºitý jazyk by m¥l být pro uºivatele známý. 2. Na stránkách s nápov¥dou by m¥ly být poskytnuty denice pro pojmy, které mohou pot°ebovat vysv¥tlení. 3. M¥lo by být snahou pouºívat pojmy konzistentn¥ nap°í£ stránkami.

•

P°ístupnost 1. Uºivatelé by m¥li být schopni jednotn¥ pouºívat v²echny sekce stránky po p°ihlá²ení. 2. Stránka by m¥la být p°ístupná ze v²ech majoritních prohlíºe£· - Internet Explorer, Mozilla Firefox, Opera a Netscape Navigator. 3. Stránky by m¥ly být zobrazitelné ve v¥t²ích rozli²eních (nap°. 1280*960), i v men²ích rozli²eních (nap°. 800*600). 4. Design stránek musí umoº¬ovat zm¥nu velikosti písma (pro zrakov¥ postiºené).

•

Organizace 1. Z hlavní stránky by m¥l uºivatel jednodu²e mít p°ístup k ve²kerým funkcím.

KAPITOLA 5.

POADAVKY

33

2. Uºivatel by m¥l mít v horní £ásti kaºdé stránky jasnou indikaci v jaké sekci se práv¥ nachází. 3. Stránka by m¥la být exibilní, aby dovolovala uºivatel·m vyhledávat obsah podle r·zných kriterií. 4. O informacích, které nejsou real-time, by m¥l být uºivatel informován, kdy byly naposledy aktualizovány.

•

Design 1. Stránka by m¥la být esteticky p°íjemná. 2. Uºivatel by m¥l být obeznámen, které informace na stránce jsou editovatelné uºivatelem a nem¥l by mít p°ístup k modikaci jiných informací.

Spolehlivost •

Dostupnost 1. Moduly zpracování a prezentace diagnostických dat a ve²kerá funkcionalita dostupná z modulu bude pro své uºivatele dostupná na bázi 24/7. 2. Pokud je plánována n¥jaká nezbytná servisní údrºba, tak bude provedena b¥hem 6 hodin v pátek odpoledne v dob¥ od 12:00 do 18:00 SE. 3. Ve²kerá funkcionalita modul· bude dostupná pro vyuºití 99% £asu krom¥ neo£ekávaného vypnutí. 4. Pokud správce bezpe£nosti zjistí, ºe bezpe£nost systému byla naru²ena, vyhrazuje si právo vypnout systém a anulovat v²echna aktivní p°ístupová konta.

•

St°ední doba mezi poruchami (MTBF) 1. Moduly by m¥ly být navrºeny tak, aby spl¬ovaly kritérium st°ední doby mezi poruchami pr·m¥rn¥ v délce 4 m¥síc· £i déle.

•

St°ední doba pro opravu (MTTR) 1. Pokud nastane selhání systému, pak by m¥l být personál podpory systému ihned informován o problému. Tento poºadavek by m¥l být zaji²t¥n pomocí real-time monitorování systému. 2. Hardware serveru související se selháním systému by m¥l nalezen a systém by m¥l být obnoven b¥hem jedné hodiny. 3. Selhání libovolné externí sluºby by m¥lo být detekováno a systém by m¥l být obnoven b¥hem dvou hodin. 4. Selhání libovolného vlastního software by m¥lo být detekováno a systém by m¥l být obnoven do dvou hodin.

•

Klasikace poruch a chyb 1. Kritická chyba - Kritická chyba zahrnuje kompletní ztrátu dat nebo nemoºnost pouºít ur£ité £ásti systému. Kritické chyby budou vy°e²eny do dvou hodin. 2. Významná chyba - Schopnost vid¥t informace, které jsou podle p°edpoklad· nep°ístupné pro uºivatele zahrnují významné chyby a tyto chyby budou odstran¥ny do dvou hodin. 3. Men²í chyba - Pokud informace zobrazené na uºivatelov¥ obrazovce nejsou korektní, pak je to klasikováno jako men²í chyba a ta by m¥la být vy°e²ena do 24 hodin.

34

KAPITOLA 5.

POADAVKY

Výkonnost •

Doba odezvy na úkon 1. Uºivatel by m¥l být schopen získat zásadní informaci do 2 minut nebo mén¥ za p°edpokladu, ºe je p°ihlá²en. 2. Pr·m¥rná doba p°echodu z obrazovky na obrazovku by m¥la být do 3 sekund. 3. Maximální doba p°echodu z obrazovky na obrazovku by m¥la být 10 sekund.

•

Propustnost 1. Systém by m¥l být schopen obslouºit 50 transakcí za sekundu.

•

Kapacita 1. Systém by m¥l být schopen podpo°it 1 000 uºivatel· systému.

•

Vyuºití zdroj· 1. Vyuºití pam¥ti na serverech by nikdy nem¥lo p°ekro£it 60% dostupné pam¥ti systému. 2. Vyuºití disku na serverech by nikdy nem¥lo p°ekro£it 80% kapacity. 3. Pokud propustnost spojení klesne pod 50 transakcí za sekundu, pak po£et spojení by m¥l být zvý²en, aby byla zlep²ena propustnost.

Podpora •

Údrºba 1. Systém bude umoº¬ovat provedení údrºby systému p°i plánovaných p°eru²eních £innosti mimo pracovní dny. 2. K dispozici bude vzdálený p°ístup k systému, systémoví administráto°i m·ºou provád¥t údrºbu odkudkoli.

•

Roz²í°itelnost 1. Systém by m¥l navrºen a vytvo°en tak, aby mohl být roz²í°en o dal²í funkce v budoucích verzích.

Omezení návrhu •

Programovací jazyk 1. Systém zpracování diagnostických dat Rubiconu bude napsán v jazyce Java. 2. Systém zpracování diagnostických dat Rubiconu bude postaven na Platform¥ NetBeans. 3. Systém zpracování diagnostických dat Rubiconu bude mít uºivatelské rozhraní postavené nad frameworkem Java Swing. 4. Systém zpracování diagnostických dat Rubiconu bude komunikovat se spolupracujícím systémem Spider, který provádí správu a koncentraci diagnostických dat z ºelezni£ních zabezpe£ovacích za°ízení, pomocí zpráv v jazyce XML.

KAPITOLA 5.

POADAVKY

35

5. Systém zpracování diagnostických dat Rubiconu bude validovat zprávy od spolupracujícího systému Spider, který provádí správu a koncentraci diagnostických dat z ºelezni£ních zabezpe£ovacích za°ízení, pomocí jazyka XML Schema. 6. Systém zpracování diagnostických dat Rubiconu bude pouºívat pro p°ístup k rela£ním databázím strukturovaný dotazovací jazyk SQL. 7. Systém prezentace diagnostických dat Rubiconu bude napsán v jazyce PHP. 8. Systém prezentace diagnostických dat Rubiconu bude pouºívat pro p°ístup k rela£ním databázím strukturovaný dotazovací jazyk SQL. 9. Systém prezentace diagnostických dat Rubiconu bude mít uºivatelské rozhraní vytvo°enou pouºitím jazyka XHTML. 10. Systém prezentace diagnostických dat Rubiconu bude mít vzhled uºivatelského rozhraní vytvo°en pomocí jazyka CSS. 11. Systém prezentace diagnostických dat Rubiconu bude pro vykonávání skriptovacích akcí na stran¥ klienta pouºívat jazyk JavaScript.

•

Komunikace 1. Systém zpracování diagnostických dat Rubiconu bude komunikovat se spolupracujícím systémem Spider, který provádí správu a koncentraci diagnostických dat z ºelezni£ních zabezpe£ovacích za°ízení, pomocí protokolu TCP/IP. 2. Systém prezentace diagnostických dat Rubiconu bude komunikovat s uºivatelem pomocí protokolu HTTP.

•

Nástroje 1. Pro plánování projektu bude pouºit nástroj GanttProject. 2. Pro správu a modelování projektu bude pouºit nástroj Enterprise Architect. 3. Pro tvorbu dokumentace projektu bude pouºit kancelá°ský balík OpenOce. 4. Pro vývoj v²ech £ástí systému Rubicon bude pouºito vývojové prost°edí NetBeans IDE. 5. Pro vytvá°ení a úpravu graky bude pouºit nástroj GIMP. 6. Pro správu dat se pouºije rela£ní databáze MySQL. 7. Pro správu rela£ní databáze MySQL se pouºije aplikace phpMyAdmin.

•

Architektura 1. Mezi stránkou, s kterou reaguje uºivatel, a komponentami, které zpracovávají v²echna data a vytvá°ejí z dat nové stránky pro uºivatele, existuje odd¥lující hranice. Prezenta£ní vrstva je vytvo°ená pouºitím XHTML a CSS. Webový server podporuje a obsluhuje tento obsah. 2. Business logika prezentace diagnostických dat je obsaºena p°eváºn¥ v PHP skriptech, které zpracovávají data. PHP skripty jsou vytvo°eny s pouºitím jazyka PHP a jsou zpracovávány aplika£ním serverem Apache. 3. Data, která jsou uloºena v databázi, jsou získávána pomocí PHP funkcí pro práci s databází MySQL. 4. Rela£ní databáze systému obsluhuje v²echny poºadavky, a´ uº uloºení nebo získání informací.

36

KAPITOLA 5.

•

POADAVKY

Ostatní 1. Systém zpracování diagnostických dat Rubiconu bude zpracovávat diagnostická data uloºená v diskovém úloºi²ti serveru KOAS. 2. Systém zpracování diagnostických dat Rubiconu bude ov¥°ovat validitu diagnostických dat b¥hem jejich zpracování. 3. Systém vyhodnocování diagnostických dat Rubiconu bude ukládat vyhodnocení diagnostických dat do rela£ní databáze MySQL na serveru KOAS. 4. Systém zpracování diagnostických dat Rubiconu bude sou£ástí serveru KOAS. 5. Systém zpracování diagnostických dat Rubiconu bude prezentovat stav zpracování administrátorovi systému. 6. Systém prezentace diagnostických dat Rubiconu bude prezentovat vyhodnocená diagnostická data uloºená v rela£ní databázi MySQL na serveru KOAS uºivatel·m serveru KOAS. 7. Systém prezentace diagnostických dat Rubiconu bude sou£ástí aplikace Produk£ní server (PServer) na serveru KOAS.

Online uºivatelská dokumentace a systém nápov¥dy •

Online nápov¥da 1. V²echny stránky p°edkládané uºivateli by m¥ly mít odkaz na online nápov¥du systému. 2. V²echny pojmy pouºívané na stránkách, které mohou vyºadovat vyjasn¥ní uºivateli, by m¥ly být spojeny se stránkou s denicemi. 3. Upozorn¥ní na vypr²ení platnosti hesla bude zasíláno na uºivatelovu hlavní stránku 48 hodin p°edtím, neº platnost hesla vypr²í, s odkazem na stránku pro zm¥nu hesla. 4. V²echny stránky budou mít odkaz na email, který dovolí uºivatel·m komunikovat s personálem údrºby poskytujícím nápov¥du.

•

Centrum podpory zákazník· 1. Podpora uºivatel· je poskytována po telefonu, emailem nebo faxem. 2. Centrum podpory zákazník· bude dostupné na b¥ºné telefonní lince bez ºádných zvlá²tních poplatk· nad rámec uºivatelova telekomunika£ního tarifu. 3. V²echny emailové zprávy zaslané do centra podpory obdrºí zp¥t odpov¥¤ od kompetentní osoby individuáln¥ do 2 pracovních dn·.

Pouºité komponenty •

JDK 1.6

•

NetBeans IDE 6.1

•

NetBeans Platform 6.1

•

Apache Commons Bean Utils 1.7.0

•

Apache Commons Codec 1.3

•

Apache Commons Collections 3.2.1

KAPITOLA 5.

POADAVKY

•

Apache Commons Email 1.1

•

Apache Commons IO 1.4

•

Apache Commons Lang 2.4

•

Apache Commons Math 1.2

•

Apache Commons Net 1.4.1

•

Apache Commons Primitives 1.0

•

jDBI 2.1.0

•

JDOM 1.1

•

RCache 1.0

•

ShiftOne Object Cache 2.0

•

SLF4J 1.5.0

•

XStream 1.3

•

MySQL 5.0.51

•

PHP 5.2.5-17.13

•

phpMyAdmin 2.11.0

•

Apache Web Server 2.2.4-70.4

37

Rozhraní •

Uºivatelské rozhraní 1. Uºivatelské rozhraní systému vyhodnocování diagnostických dat bude zobrazeno v administrátorov¥ opera£ním systému. 2. Uºivatelské rozhraní systému vyhodnocování diagnostických dat bude vytvo°eno ve frameworku Java Swing. 3. Uºivatelské rozhraní systému prezentace diagnostických dat bude zobrazeno v uºivatelov¥ webovském prohlíºe£i. 4. Uºivatelské rozhraní systému prezentace diagnostických dat bude vytvo°eno v jazyce XHTML a CSS. 5. Uºivatelské rozhraní systému prezentace diagnostických dat bude generováno dynamicky pomocí skript· jazyka PHP a JavaScript.

•

Hardwarová rozhraní 1. Systémy vyhodnocování a prezentace diagnostických dat pracují se síóvým rozhraním s vyuºitím protokol· TCP/IP a http.

•

Softwarová rozhraní 1. Systémy vyhodnocování a prezentace diagnostických dat obsahují rozhraní, pomocí kterého lze volat jejich funkce a získávat informace z jiných modul·.

38

KAPITOLA 5.

•

POADAVKY

Komunika£ní rozhraní 1. Systém vyhodnocování diagnostických dat komunikuje s externí aplikací Spider pomocí síóvého protokolu TCP/IP. 2. Systém vyhodnocování diagnostických dat komunikuje s databázi MySQL, která je na stejném serveru, lokáln¥ s vyuºitím standardních prost°edk· programovacího jazyka Java. 3. Systém prezentace diagnostických dat komunikuje s databázi MySQL, která je na stejném serveru, lokáln¥ s vyuºitím standardních prost°edk· programovacího jazyka PHP. 4. Systém prezentace diagnostických dat s uºivatelem komunikuje pomocí protokolu http, p°es který uºivatel pomocí webovského prohlíºe£e zasílá poºadavky a modul uºivateli prezentací informací v jazyce XHTML a CSS.

Licen£ní podmínky •

Licence 1. Pouºívání systému se °ídí standardními pravidly pro provoz informa£ních systému podniku. 2. Registraci uºivatel· do systému provádí správce serveru podle pokyn· manaºera.

Zákony, autorská práva a dal²í poznámky •

Poznámky 1. V dolní £ásti kaºdé stránky bude odkaz na právní odpov¥dnost a autorská práva.

Pouºité standardy •

Standardy dokument· 1. Unied Software Development Process

•

Standardy zdrojových kód· 1. Java code conventions 2. Javadoc doc comments 3. NetBeans coding standards 4. XML coding standards 5. PHP code conventions 6. phpdoc doc comments 7. SQL coding standards 8. XHTML coding standards 9. CSS coding standards

•

Ostatní 1. Human Computer Interface Standards 2. Emailový formát p°ístupný kterémukoliv uºivateli, zobrazitelný v externích systémech (tagy...). P°edm¥t emailu pro administrátory systému obsahuje popis události pro jednoduchou identikaci problém·.

KAPITOLA 5.

POADAVKY

39

5.2.4 Shrnutí poºadavk· Z uvedených poºadavk· vyplývá, ºe navrºeny budou dva systémy. Zpracování diagnostických dat bude jednou £ástí systému a ta bude postavena na Platform¥ NetBeans a implementována v programovacím jazyce Java. Druhá aplikace pro prezentaci diagnostických dat bude postavena na Platform¥ PServer a implementována v programovacím jazyce PHP. Tyto skute£nosti o odli²né implementaci £ástí nebudou dále uvád¥ny, nebo´ analýza a návrh bude proveden nezávisle na výsledné implementa£ní platform¥. Implementace budou vycházet ze spole£ného návrhu, coº zaji²úje moºnost vým¥ny cílové platformy, na které bude implementována daná konkrétní £ást systému.

5.3 P°ípady uºití 5.3.1 Modelování Modelování p°ípad· uºití je dopl¬kovým zp·sobem získávání a dokumentování poºadavk·. Modelování se skládá z následujících aktivit:

•

nalezení hranic systému,

•

vyhledání aktér· (actors),

•

nalezení p°ípad· uºití.

Modely p°ípad· uºití poskytují hlavní zdroj objekt· a t°íd. Jsou prvotním vstupem k modelování t°íd. P°ípad uºití je specikace posloupností £inností, v£etn¥ prom¥nných posloupností a chybových posloupností, které systém, podsystém nebo t°ída m·ºe vykonat prost°ednictvím interakce s vn¥j²ími (externími) aktéry. P°ípad uºití je v podstat¥ n¥co, co aktér od systému o£ekává.

5.3.2 Ú£astnící Aktér, neboli ú£astník, specikuje roli, kterou ur£itá externí entita p°ijímá v okamºiku, kdy za£íná daný systém bezprost°edn¥ pouºívat. M·ºe vyjad°ovat roli uºivatele, roli dal²ího systému, který se dotýká hranic modelovaného systému. Model p°ípadu uºití aplikace Rubicon obsahuje 5 r·zných ú£astník·. Ú£astnící p°ípadu uºití jsou zobrazeny na obrázku 5.1.

Obrázek 5.1: Ú£astnící p°ípadu uºití

40

KAPITOLA 5.

POADAVKY

Administrátor Administrátor instaluje systém, spou²tí a vypíná systém, stará se o jeho údrºbu a nastavení, kontroluje stav systému. Administrátor systému pouºívá systém také stejným zp·sobem jako Pracovníci.

Servisní pracovník Pracovník Servisu spole£nosti AD Praha s.r.o.

Vývojový pracovník Pracovník Vývojového pracovi²t¥ spole£nosti AD Praha s.r.o., resp. Závod Technika - Výzkum a vývoj.

Pracovník Uºivatel systému prohlíºí vyhodnocená diagnostická data z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení.

Spider Spolupracující systém pro sb¥r a koncentraci diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení. Informuje systém o nových, pravideln¥ jedenkrát za 24 hodin, diagnostických datech.

5.3.3 Primární p°ípady uºití Primární p°ípady uºití systému Rubicon jsou patrné z diagramu p°ípadu uºití na obrázku 5.2.

Zpracovat diagnostická data ) tvo°í dal²í 4 dodavatelské p°ípady uºití, které pak tvo°í bázové p°ípady uºití pro p°ípad uºití Informovat o stavu systému, který náleºí do p°ípad· uºití pro administrátora systému (viz dále). Primární p°ípady jsou identikovány prexem A následovaným £íslem p°ípadu Primární p°ípady uºití systému jsou dva (viz dále), p°i£emº první p°ípad uºití (

uºití.

A1 Zpracovat diagnostická data Jedná se o hlavní pouºití systému, a to externím aktérem Spider. Tento p°ípad uºití vytvá°í následující dodavatelské p°ípady uºití:

A2 Validovat diagnostická data A3 Analyzovat diagnostická data A4 Vyhodnotit diagnostická data A5 Uloºit vyhodnocená diagnostická data

A6 Zobrazit vyhodnocená diagnostická data Tento p°ípad uºití modeluje uºití systému Rubicon uºivateli, kte°í cht¥jí prohlíºet oine diagnostická data.

KAPITOLA 5.

41

POADAVKY

Obrázek 5.2: Primární p°ípady uºití

5.3.4 Administrace systému P°ípady uºití administrace systému jsou patrné z diagramu p°ípadu uºití na obrázku 5.3. Tyto p°ípady uºití, jak uº z názvu vyplývá, p°edstavují interakci administrátora se systémem. P°ípady uºití administrace systému jsou identikovány prexem

X

následovaným £íslem p°ípadu uºití.

Obrázek 5.3: P°ípady uºití administrace systému

X1 Spravovat systém Tento p°ípad uºití systému reektuje poºadavek na správu a zm¥ny nastavení systému.

42

KAPITOLA 5.

POADAVKY

X2 Informovat o stavu systému Jak jiº bylo zmín¥no vý²e, tento p°ípad uºití je roz²í°ením dodavatelských p°ípad· uºití primárního p°ípadu uºití

Zpracovat diagnostická data. Tento p°ípad uºití je v²ak také samostatn¥

proveditelný v kterémkoliv jiném p°ípadu uºití £i jako reakce na poºadavek samotného administrátora, který chce zjistit aktuální stav systému. Nejb¥ºn¥j²í spu²t¥ní tohoto p°ípadu uºití pak nastává p°i chybách systému, p°i chyb¥ vyhodnocování diagnostických dat apod.

5.3.5 Detaily p°ípad· uºití Po denici p°ípad· uºití je nutné dále p°ípady uºití specikovat, tj. nalézt hlavní scéná°, alternativní toky, podmínky atd. Specikace se skládá ze základních údaj·, které podrobn¥ ur£ují daný p°ípad uºití. Specikace má podobu tabulky, resp. 2 tabulek pro kaºdý p°ípad uºití, a vyjad°uje pr·b¥h pr·chodu p°ípadem uºití spolu s dal²ími poºadovanými údaji. Pro specikaci p°ípadu uºití se pouºívá ²ablona tabulky, která vychází z [24].

A1 Zpracovat diagnostická data Specikace p°ípadu uºití A1

Zpracovat diagnostická data

je uvedena v tabulce 5.1. Z tabulky je

patrný hlavní scéná° p°ípadu uºití, stejn¥ jako ú£astníci a výsledek úsp¥²n¥ vykonaného p°ípadu uºití. V tabulce 5.2 jsou pak uvedeny dopl¬ující informace k p°ípadu uºití. V této tabulce jsou pak uvedeny informace o spojení k aktér·m a dal²í nezbytné údaje nutné pro realizaci p°ípadu uºití.

Detaily ostatních p°ípad· uºití Detaily ostatních p°ípad· uºití jsou vypracovány v podobném duchu i pro v²echny zbývající p°ípady uºití a jsou k dispozici na p°iloºeném DVD.

5.3.6 Matice sledovatelnosti poºadavk· Sledování poºadavk· propojuje funk£ní poºadavky ve specikaci systémových poºadavk· s modelem p°ípadu uºití. Matice sledovatelnosti poºadavk· je velice uºite£ný nástroj pro ov¥°ování konzistence. Existuje-li poºadavek, jenº není mapován na ºádný p°ípad uºití, znamená to, ºe v modelu p°ípad uºití chybí. Platí to samoz°ejm¥ i obrácen¥. Existuje-li p°ípad uºití, který není mapován na ºádný poºadavek, znamená to, ºe mnoºina poºadavk· není úplná. Matice sledovatelnosti poºadavk· je zobrazena v tabulce 5.3. Z této tabulky vyplývá, ºe v²echny poºadavky jsou pokryty n¥jakým p°ípadem uºití a zárove¬ ºádný poºadavek nechybí. Vysv¥tlivky k tabulce matice sledovatelnosti poºadavk·:

•

P1 - Rubicon bude zpracovávat diagnostická data z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení.

•

P2 - Rubicon bude ov¥°ovat validitu diagnostických dat.

•

P3 - Rubicon bude analyzovat diagnostická data.

•

P4 - Rubicon bude vyhodnocovat diagnostická data.

•

P5 - Rubicon bude ukládat vyhodnocení diagnostických dat do persistentního úloºi²t¥.

•

P6 - Rubicon bude prezentovat vyhodnocená diagnostická data.

•

P7 - Rubicon bude spravovat administrátor systému.

•

P8 - Rubicon bude prezentovat stav systému administrátorovi systému.

KAPITOLA 5.

43

POADAVKY

PÍPAD UITÍ A1 Kontext pouºití

Zpracovat diagnostická data Spider informuje systém o nových diagnostických datech. Systém tato data validuje, analyzuje, vyhodnotí

Rozsah Úrove¬ Primární aktér Ú£astnící a zájmy

a uloºí vyhodnocení dat do persistentního úloºi²t¥. Rubicon Souhrnná Spider Spider

Informuje systém o nových diagnostických datech.

Administrátor

Informován o stavu systému v p°ípad¥ nevalidních diagnostických dat nebo chyby p°i ukládání vyhodno-

Vstupní podmínky Minimální záruky Záruky úsp¥chu Spou²t¥£ POPIS

cení diagnostických dat. ádné. Vytvo°en log o pr·b¥hu zpracování. Diagnostická data jsou validní, analyzována, vyhodnocena a uloºena do persistentního úloºi²t¥. Spider získal nová diagnostická data.

Krok Akce 1

ROZÍENÍ VARIANTY

Spider zadá

2

vyhodnotit diagnostická data . Systém p°ijme typ za°ízení a jeho identikátor.

3

Zahrnout Validovat diagnostická data.

4

Zahrnout Analyzovat diagnostická data.

5

Zahrnout Vyhodnotit diagnostická data.

6

Zahrnout Uloºit vyhodnocená diagnostická data.

Krok Akce v¥tvení ádné.

Krok Akce v¥tvení ádné.

Tabulka 5.1: Detail p°ípadu uºití A1 Zpracovat diagnostická data

44

KAPITOLA 5.

SOUVISEJÍCÍ INFORMACE Priorita Doba reakce etnost uºití Spojení k aktér·m OTEVENÉ PROBLÉMY

POADAVKY

Zpracovat diagnostická data

vysoká prom¥nlivá podle po£tu diagnostikovaných za°ízení Spider - statické soubory s diagnostickými daty Administrátor - GUI, statický soubor s logem Jak zpracovat nevalidní diagnostická data? Jak zajistit uloºení diagnostických dat do persistent-

Datum spln¥ní Nad°azený PU Pod°azený PU

ního úloºi²t¥ po neúsp¥²ném uloºení? verze 1.0 Validovat diagnostická data Analyzovat diagnostická data Vyhodnotit diagnostická data Uloºit vyhodnocená diagnostická data

Tabulka 5.2: Dopl¬ující informace k p°ípadu uºití A1 Zpracovat diagnostická data

P°ípady uºití

P1 P2 P3 Poºadavky

P4 P5 P6

PU-A1

PU-A2

PU-A3

PU-A4

PU-A5

x

x

x

x

x

PU-A6

PU-X1

PU-X2

x x x x x

P7

x

P8

x Tabulka 5.3: Matice sledovatelnosti poºadavk·

KAPITOLA 5.

POADAVKY

45

5.4 Shrnutí V této kapitole byly popsány poºadavky kladené na projekt Rubicon. Byly denovány funk£ní a nefunk£ní poºadavky, vyhledáni akté°i a p°ípady uºití v£etn¥ detail· p°ípad· uºití a popsáno sledování poºadavk· aº k p°ípad·m uºití. Ve²keré poºadavky na systém jsou specikovány a je jasné, co bude systém d¥lat. Je moºné se pln¥ vrhnout do objektov¥ orientované analýzy, která je popsána v následující kapitole.

46

KAPITOLA 5.

POADAVKY

KAPITOLA 6.

47

ANALÝZA

6 Analýza 6.1 Úvod Analýza spo£ívá v tvorb¥ model·, jeº zachycují podstatné poºadavky a charakteristické rysy poºadovaného systému. Zám¥rem analýzy (z pohledu objektov¥ orientovaného analytika) je tvorba analytického modelu. Tento model se zam¥°uje na to, nezabývá se detaily týkajícími se zp·sobu,

jakým

co

systém musí ud¥lat, av²ak

to ud¥lá. Tuto otázku p°enechává aktivit¥

(pracovnímu postupu) Návrh (Design). Výstupem analýzy jsou dva klí£ové artefakty:

•

analytické t°ídy, které tvo°í klí£ové pojmy v obchodní domén¥;

•

realizace p°ípad· uºití, jeº názorn¥ ukazují, jak mohou instance analytických t°íd vzájemn¥ komunikovat s cílem realizovat chování systému specikované p°ípadem uºití.

Je nutné podotknout, ºe analytický model je vytvo°en v obchodním jazyce p°íslu²né problémové domény.

6.2 Analytické t°ídy Analytické t°ídy:

•

reprezentují k°ehkou abstrakci problémové domény,

•

m¥ly by mapovat pojmy skute£ného sv¥ta (jejich názvy by m¥ly být podle toho pe£liv¥ vybrány).

Za problémovou je povaºována doména, ze které vze²el poºadavek na softwarový systém. Prvním krokem p°i tvorb¥ objektov¥ orientovaného díla je objasn¥ní problémové domény. To zahrnuje jasnou denici obchodních pojm· a jednoduchou funk£ní strukturu. Ve²keré pojmy z oblasti ºelezni£ních zabezpe£ovacích za°ízení a technické diagnostiky byly probrány v kapitole 2. Zde bude popsána tedy analýza t¥chto pojm· a uvedeny nalezené analytické t°ídy.

6.2.1 Hledání analytických t°íd Neexistuje ºádný jednoduchý algoritmus nalezení správných analytických t°íd. Kdyby takový existoval, mohl by vést k neomylnému postupu návrhu a tvorby objektov¥ orientovaného softwaru. Existuje v²ak celá °ada ov¥°ených a spolehlivých technik, které vedou ke správným záv¥r·m. Mezi zmi¬ované techniky pat°í analýza textu, rozhovory s uºivateli a s experty p°íslu²ných domén.

6.2.2 Analýza podstatných jmen a sloves Analýza podstatných jmen a sloves je velmi jednoduchým zp·sobem analýzy textu, v n¥mº chceme najít t°ídy, atributy a odpov¥dnosti. Podstatná jména a fráze tvo°ené v textu podstatnými jmény jsou v podstat¥ vyjád°ením odpov¥dností nebo operací t°ídy. Tato analýza je postavena na p°ímé analýze jazyka problémové domény. Provedením analýzy textu na zmín¥ném textu popisu problémové domény (pojmy z oblasti ºelezni£ních zabezpe£ovacích za°ízení a technické diagnostiky) a textu specikace poºadavk· dostaneme business objekty, které jsou zobrazeny na diagramu t°íd na obrázku 6.1. Z obrázku je patrné, ºe levá £ást je tvo°ena t°ídami, které reprezentují doménu ºelezni£ních zabezpe£ovacích za°ízení. Pravá £ást pak popisuje doménu technické diagnostiky.

48

KAPITOLA 6.

ANALÝZA

Obrázek 6.1: Diagram business objekt·

6.2.3 Diagram analytických t°íd Dal²í hlub²í analýzou modelovaného problému spolu s analýzou vytvo°ených business objekt· dostáváme pak diagram analytických t°íd (obrázek 6.2). Tento diagram je dopln¥n oproti diagramu business objekt· o hlub²í analýzu a objevené pojmy problémové domény (datová úloºi²t¥, správce komunikace...). V levé £ásti diagramu jsou vid¥t t°ídy, které popisují problémovou doménu ºelezni£ních zabezpe£ovacích za°ízení. Ve st°ední a pravé £ásti jsou pak vizualizovány pojmy domény technické diagnostiky. V horní £ásti jsou pak zobrazeny pojmy symbolizující interakci s externími uºivateli (komunika£ní a p°ístupová rozhraní), stejn¥ jako datové úloºi²t¥ symbolizující uloºení archivovaných diagnostických dat. Je nutné podotknout, ºe uvedené nalezené analytické t°ídy jsou modelovány a uvaºovány v duchu objektov¥ orientovaného programování, stejn¥ jako vztahy mezi t°ídami v duchu GRASP technik návrhu odpov¥dností mezi t°ídami. Diagram se pak stává nální p°edlohou pro pracovní postup návrh, kde se z n¥ho bude dále vycházet p°i dal²ím návrhu systému.

6.3 Architektonická analýza Balí£ek je abstrakce sdruºování. Je to kontejner a vlastník modelovaných prvk·. Kaºdý balí£ek má vlastní jmenný prostor, uvnit° n¥jº musí být v²echny názvy jedine£né. Je nutné si uv¥domit,

KAPITOLA 6.

49

ANALÝZA

ºe balí£ek je mechanismem pro logické seskupování. Pro fyzické seskupování se pak pouºívají komponenty. Kaºdý modelovaný prvek je pak vlastn¥n jedním balí£kem a hierarchie vlastnictví utvá°í stromovou strukturu, na jejímº vrcholu je ko°enový balí£ek.

6.3.1 Hledání analytických balí£k· V architektonické analýze jsou v²echny t°ídy uspo°ádány do mnoºiny soudruºných analytických balí£k·, jeº jsou dále strukturovány v oddílech a vrstvách. Kaºdý analytický balí£ek v dané vrstv¥ utvá°í oddíl (partition). Analytické balí£ky lze specikovat hledáním skupin modelovaných prvk·, jeº se vyzna£ují silnou sémantickou soudruºností.

6.3.2 Diagram analytických balí£k· Nalezené analytické balí£ky, které denují architekturu modelovaného systému jsou zobrazeny na obrázku 6.3. Z diagramu jsou vid¥t t°i navrºené vrstvy aplikace. Nejniº²í je vrstva datových úloºi²´, která reprezentuje úloºi²t¥ archivovaných diagnostických dat. Nad ní je pak vrstva, která zapouzd°uje pojmy problémové domény, tj. ºelezni£ní zabezpe£ovací za°ízení a jejich vlastní diagnostiku. V nejvy²²í vrstv¥ jsou pak t°ídy reprezentující komunikaci s externími aktéry. Nejvy²²í vrstvu pak tvo°í dva oddíly. V p°ípad¥ komunikace s externími systémy se jedná o balí£ek komunikace [TCP/IP,...]. Naopak v p°ípad¥ komunikace s uºivateli pak o balí£ek p°ístupová rozhraní [GUI, SSH,...]).

6.4 Realizace p°ípad· uºití Druhým klí£em k analýze je po nalezení analytických t°íd také nalezení realizací p°ípad· uºití. Jde o mnoºiny t°íd, které uskute£¬ují chování specikované v p°ípadu uºití. P°i procesu realizace p°ípad· uºití jsou modelovány interakce mezi objekty. Analytické t°ídy umoº¬ují modelovat statickou strukturu systému, zatímco realizace p°ípad· uºití slouºí k popisu spolupráce instancí analytických t°íd pro dosaºení poºadovaného chování systému. To je dynamický pohled systému. Je také nutné podotknout, ºe není nutné vytvá°et realizace v²ech p°ípad· uºití. Vybírají se pouze klí£ové p°ípady uºití a pracuje se pouze s nimi.

6.4.1 Realizace p°ípadu uºití A1 P°ípad uºití A1 realizuje primární p°ípad uºití

Zpracovat diagnostická data.

Základní realizaci

tohoto p°ípadu uºití popisuje diagram aktivit na obrázku 6.4. Z tohoto diagramu je patrný pr·b¥h tohoto p°ípadu uºití. Iniciátorem spou²t¥jícím p°ípad uºití je externí systém Spider, který po získání diagnostických dat informuje systém Rubicon. Za°ízení, jehoº diagnostická data byla získána je identikován ozna£ením za°ízení a identikátorem. Po p°ijetí argument· zpracování je za°ízení nalezeno, p°ípadn¥ vytvo°eno. Následuje vlastní sekvence zpracování diagnostických dat. Prvním krokem je validace, následuje analýza, vlastní vyhodnocení a poslední aktivitou je uloºení vyhodnocení diagnostických dat do persistentního úloºi²t¥. Podrobn¥j²í realizaci p°ípadu uºití pak zobrazuje sekven£ní diagram na obrázku 6.5. Z tohoto diagramu je pak patrný pr·b¥h vlastního zpracování, mj. zobrazuje nap°. to, ºe pro dané za°ízení jsou zpracována v²echna diagnostická data a u nich zase v²echny jejich kategorie.

6.4.2 Realizace dal²ích p°ípad· uºití Jak jiº bylo zmín¥no vý²e, není nutné vytvá°et realizace v²ech p°ípad· uºití. Nicmén¥ realizace zbývajících p°ípad· uºití jsou k dispozici na p°iloºeném DVD (komunika£ní a sekven£ní diagramy). Zde v diplomové práci v²ak uvedeny nejsou z d·vod· niº²í priority £i jednoduchosti realizace t¥chto p°ípad· uºití.

50

KAPITOLA 6.

ANALÝZA

6.5 Shrnutí V této kapitole byla probrána analýza vytvá°eného systému. Byly nalezeny analytické t°ídy a balí£ky. V poslední £ásti byla pak znázorn¥na realizace n¥kterých d·leºitých p°ípad· uºití. Po dokon£ení analýzy je moºné provést evolu£ní p°echod z analytického modelu do modelu návrhového.

KAPITOLA 6.

ANALÝZA

Obrázek 6.2: Diagram analytických t°íd

51

52

KAPITOLA 6.

Obrázek 6.3: Diagram analytických balí£k·

Obrázek 6.4: Realizace p°ípadu uºití A1 - diagram aktivit

ANALÝZA

KAPITOLA 6.

ANALÝZA

Obrázek 6.5: Realizace p°ípadu uºití A1 - sekven£ní diagram

53

54

KAPITOLA 6.

ANALÝZA

KAPITOLA 7.

55

NÁVRH

7 Návrh 7.1 Úvod Analýza je zam¥°ena hlavn¥ na tvorbu logického modelu p°ipravovaného systému, který zachycuje funkce, jeº tento systém musí poskytovat, aby uspokojil poºadavky uºivatel·. Smyslem návrhu je p°esná specikace zp·sobu, jak takové funkce implementovat. Návrhový model je zaloºen na modelu analytickém a je jeho up°esn¥ním a rozpracováním konkrétních technických °e²ení. Analýza spo£ívá v modelování toho, zp·sobu,

jakým

co by m¥l systém d¥lat. Návrh spo£ívá v modelování

má být toto chování implementováno.

V této kapitole je také uveden návrh grackých uºivatelských rozhraní systém·. Stejn¥ tak jsou zde navrºeny procesy zpracování diagnostických dat a denice dat pro vým¥nu informací s externími systémy.

7.2 Architektonický návrh Architektonický návrh spo£ívá ve vytvo°ení ná£rtu architektonicky významných artefakt·. Artefakty jsou pak vstupní branou k aktivitám podrobn¥j²ího návrhu, v nichº budou obaleny konkrétn¥j²í implementací.

7.2.1 Návrhové t°ídy a up°esn¥ní analytických relací Návrhové t°ídy jsou t°ídy, jejichº specikace je na takovém stupni, ºe je lze implementovat. Návrhové t°ídy lze získat ze dvou zdroj·:

•

z problémové domény prost°ednictvím up°es¬ování analytických t°íd. Sou£ástí up°es¬ování je rovn¥º dopl¬ování implementa£ních detail·.

•

Z domény °e²ení - doména °e²ení je sférou knihoven uºitkových t°íd a znovupouºitelných komponent (Date, String, kolekce...).

Up°es¬ování analytických relací je aktivita spojená práv¥ s návrhovými t°ídami, které vycházejí ze t°íd analytických. P°i up°es¬ování relací se up°es¬ují vhodné asociace do relací typu agregace nebo kompozice (skládání), navrhují se asocia£ní t°ídy, obousm¥rné asociace atd. P°i návrhu návrhových t°íd se v této fázi hojn¥ vyuºívají návrhové vzory [25], které p°edstavují °e²ení £astých a opakujících se problém· a pomáhají vytvá°et kvalitní návrh systému pomocí osv¥d£ených postup·.

7.2.2 Logická architektura systému Z hlediska logické architektury lze systém rozd¥lit na 4 £ásti (viz obrázek 7.1). Na nejvy²²í úrovni jsou £ásti, které se mohou m¥nit, resp. p°ibývat nové implementace do systému. Jsou to uºivatelská rozhraní a zásuvné moduly (tzv. pluginy). Zásuvné moduly pak tvo°í Komunikátory a Produkty. Komunikátory slouºí ke komunikaci s externími systémy, které získávají archivovaná diagnostická data od ºelezni£ních zabezpe£ovacích za°ízení. Komunikátory jsou závislé na vrstv¥ domény, resp. na její £ásti Komunikace. Produkty pak tvo°í jednotlivá konkrétní implementace strategie zpracování diagnostických dat daného za°ízení. Produkty jsou závislé na vrstv¥ domény, resp. na její £ásti s ºelezni£ními zabezpe£ovacími za°ízeními. Vrstva domény dále obsahuje £ást, které se týká úloºi²´ archivovaných diagnostických dat.

56

KAPITOLA 7.

NÁVRH

Obrázek 7.1: Logická architektura systému

Nejniº²í vrstvou je pak vrstva technických sluºeb. Tato vrstva obsahuje balí£ky s t°ídami pro práci s databází, soubory a vstupy/výstupy. Poskytuje také balí£ky roz²i°ující funkce jazyka a balí£ek matematických funkcí. Z analytického balí£ku ºelezni£ních zabezpe£ovacích za°ízení pak vychází zmín¥ný balí£ek ºelezni£ních zabezpe£ovacích za°ízení v doménové vrstv¥. Diagram návrhových t°íd ºelezni£ních zabezpe£ovacích za°ízení je zobrazen na obrázku 7.2. Z tohoto diagramu jsou patrné up°esn¥né vazby mezi za°ízeními a jejich diagnostickými daty (kompozice) a diagnostickými daty a jejich

IDevice, které implemenComposite ).

kategoriemi (kompozice). Diagram také zobrazuje vytvo°ené rozhraní tují

Za°ízení

a

KompoziceZa°ízení

(podle návrhového vzoru

7.2.3 Datová architektura systému Datová architektura systému popisuje uloºení provozních dat v rela£ních databázích v datovém skladu. Diagram datové architektury je zobrazen na obrázku 7.3. Z tohoto obrázku je patrné

data_storages )

úloºi²t¥ záznam· o datových úloºi²tích (

devices ).

a za°ízení (

Za°ízení závisí na

úloºi²ti datových úloºi²´ cizím klí£em, který identikuje pro kaºdé za°ízení úloºi²t¥ archivovaných diagnostických dat.

7.3 Implementa£ní prost°edí Jednou z d·leºitých otázek pro návrh aplikací je volba vhodných implementa£ních nástroj·. Jedná se p°edev²ím o programovací jazyk, ale nap°íklad i databázový server, technologie, pouºité

KAPITOLA 7.

57

NÁVRH

Obrázek 7.2: Detail balí£ku ZS

knihovny atd. Pouºití ur£itých technologií bývá v¥t²inou dáno jiº p°i zadání projekt·, resp. p°i denici poºadavk·, kdy zákazník denuje konkrétní poºadavky na vytvá°ený systém. Je tomu tak i v p°ípad¥ této diplomové práce, kdy v kapitole 5 byly denovány konkrétní poºadavky. Dal²í up°esn¥ní a zd·vodn¥ní pouºití daných technologií a podp·rných nástroj· je probráno dále v této kapitole. Tato kapitola je zpracována, pokud není uveden dal²í zdroj, dle [22].

7.3.1 Volba programovacího jazyka pro implementaci Otázka výb¥ru programovacího jazyka, který bude následn¥ pouºit pro implementaci je u projekt· d·leºitá a nesmí být podcen¥na. Z poºadavk· na diplomovou práci vyplývá pouºití programovacích jazyk· Java a PHP.

Java Z poºadavk· na diplomovou práci vyplývá pouºití programovacího jazyka Java pro implementaci aplikace pro zpracování diagnostických dat. Tento jazyk má sice °adu nevýhod, ale také mnoho pozitivních stránek. Java je objektov¥ orientovaný programovací jazyk, který vyvinula rma Sun Microsystems a p°edstavila 23. kv¥tna 1995. Logo Javy je zobrazeno na obrázku 7.4 [21]. Java je jedním z nejpouºívan¥j²ích programovacích jazyk· na sv¥t¥. Díky své p°enositelnosti je pouºíván pro programy, které mají pracovat na r·zných systémech po£ínaje £ipovými kartami (platforma JavaCard), p°es mobilní telefony a r·zná zabudovaná za°ízení (platforma Java ME), aplikace pro desktopové po£íta£e (platforma Java SE) aº po rozsáhlé distribuované systémy pracující na °ad¥ spolupracujících po£íta£· rozprost°ené po celém sv¥t¥ (platforma Java EE).

58

KAPITOLA 7.

NÁVRH

Obrázek 7.3: Datová architektura systému

Tyto technologie se jako celek nazývají platforma Java. Dne 8. kv¥tna 2007 Sun uvolnil zdrojové kódy Javy (cca 2,5 milión· °ádk· kódu) a Java bude dále vyvíjena jako open source. Pro implementaci diplomové práce byl pak zvolen jazyk Java ve verzi 1.6. Tato verze pat°í v dob¥ tvorby diplomové práce k aktuální verzi tohoto jazyka a oproti star²í verzi Javy 1.5, a zejména 1.4 p°iná²í °adu zm¥n a vylep²ení usnad¬ující tvorbu aplikací. Proto jsem se rozhodl svojí diplomovou práci naprogramovat s vyuºitím programovacího jazyka Java SE 1.6 (Dolphin). Mezi negativní vlastnosti tohoto jazyka jist¥ pat°í fakt, ºe se jedná o interpretovaný programovací jazyk. Obecn¥ se soudí, ºe interpretovaný jazyk musí být nutn¥ pomalý. Tento fakt v²ak v sou£asnosti jiº ne zcela odpovídá realit¥. Problém u interpretovaných jazyk· spo£ívá v práci s pam¥tí. Tuto £innost lze rozd¥lit na dv¥ samostatné £innosti: alokace pam¥ti a uvol¬ování pam¥ti. Alokace pam¥ti je u interpretovaných jazyk· s vyuºitím garbage collectoru pozitivní vlastností, jelikoº jsou v této £innosti dokonce rychlej²í neº neinterpretované jazyky jako je C. Naopak uvol¬ování pam¥ti je £innost, kde v sou£asné dob¥ interpretované jazyky zatím zaostávají. Velmi patrný je nap°. jev, kdy garbage collector za£ne uvol¬ovat pam¥´. V tomto okamºiku systém p°estává reagovat nez°ídka dojde k tzv. zamrznutí systému. V celkovém d·sledku jsou tak interpretované programovací jazyky relativn¥ pomalej²í neº neinterpretované. Tento rozdíl ve výkonnosti v²ak není nijak dramatický a výkonnostní decit je pro aplikaci zcela p°ijatelný. Podle údaj· zve°ejn¥ných [20] rmou Sun Microsystems, Inc., která je tv·rcem jazyka Java, je tento jazyk v pr·m¥ru pouze jen o pár % pomalej²í neº neinterpretovaný jazyk C. V poslední dob¥ se objevuje celá °ada projekt·, které pouºívají jazyk Java jako implementa£ní nástroj pro tvorbu her, nap°. Jake 2 (p°ed¥lávka po£íta£ové hry Quake 2). Ve sv¥t¥ podnikových aplikací je jazyk Java jasnou volbou pro mnoho manaºer· pro svojí robustnost, platformní

KAPITOLA 7.

NÁVRH

59

Obrázek 7.4: Logo programovacího jazyka Java

nezávislost atd. V podnikových aplikacích se pak pouºívá verze Java EE (Enterprise Edition). Dal²í nevýhodou interpretovaných jazyk· je pak pam¥óvá náro£nost, která je vy²²í neº u neinterpretovaných jazyk·. Jedním z d·vod· je nap°íklad fakt, ºe je pot°eba sou£asn¥ zajistit nejen b¥h programu, ale i virtuálního stroje. V p°ípad¥ Javy m·ºe být pro b¥ºného uºivatele také významný fakt, ºe virtuální stroj není v sou£asné dob¥ sou£ástí b¥ºn¥ se vyskytujících opera£ních systém·, jako je Microsoft Windows £i Linux, ale musí být dodate£n¥ doinstalován. Jedním ze základních poºadavk· na aplikace v sou£asnosti je platformní nezávislost. Z tohoto d·vodu je vhodné volit n¥který z interpretovaných jazyk· Java £i C#. Jazyk C# má v²ak jednu podstatnou nevýhodu, a to, ºe aplikace vyuºívají GUI postavené na Windows Forms a ty nejsou platformn¥ nezávislé. Dále p°ichází v úvahu Open Sourcová implementace jazyka C#, a to Mono. Mono vyuºívá pro tvorbu GUI knihovny z projektu Gtk+. B¥hové prost°edí Gtk+ je p°ítomné dnes jiº snad ve v²ech distribucích Linuxu. Bohuºel na opera£ním systému Windows se s ním lze setkat velmi sporadicky. Naproti tomu jazyk Java si za dobu své existence vydobyl velmi slu²nou pozici. V podstat¥ lze °íci, ºe Jazyk Java zná dnes jiº kaºdý, minimáln¥ díky aplikacím pro mobilní telefony, které jsou práv¥ v Jav¥ napsány. I tento fakt zajisté p°isp¥l ke skute£nosti, ºe b¥hové prost°edí pro jazyk Java lze dnes nalézt na celé °ad¥ po£íta£·. Toto b¥hové prost°edí je stabilní sou£ástí opera£ních systém· Solaris a Mac OS. Díky £innosti rmy Sun Microsystems, Inc., byla Java vst°ícn¥ p°ijata Open Sourcovou komunitou, coº napomohlo jejímu roz²í°ení v rámci opera£ního systému Linux. I na platform¥ Windows je b¥hové prost°edí pro programy napsané v jazyku Java ²iroce roz²í°eno. Tento fakt navíc podporují i výrobci po£íta£·, jako je HP £i IBM, které toto b¥hové prost°edí dodávají jako standardní sou£ást výrobku. Programovací jazyk Java pat°í mezi vy²²í imperativní programovací jazyky s vysokým stupn¥m abstrakce. Tento fakt následn¥ vede k vysoké efektivit¥ kódování vzhledem k ostatním jazyk·m. Jazyk Java pat°í mezi jazyky se silnou typovou kontrolou. Tato skute£nost p°iná²í mnohem vy²²í bezpe£nost do programování s ohledem na £asté p°etypovávání prom¥nných v programech. Tento rys jazyka Java je pak je²t¥ více zvýrazn¥n práv¥ od verze jazyka Java 1.5, kdy p°ibyly do jazyka generické typy. V sou£asné dob¥ je v²ak velmi pal£ivá otázka bezpe£nosti nejen s ohledem na typovou kontrolu, ale hlavn¥ otázka práce s pam¥tí. P°i chybné práci s pam¥tí, a´ jiº se jedná o alokaci, uvol¬ování pam¥ti £i manipulaci s ní, dochází £asto k chybám, které nejen ohroºují samotný program, ale v £astých p°ípadech umoºní úto£níkovi získat nadvládu nad celým systémem. Chyby jako buer overow a podobné jsou velmi typické nap°. pro jazyk C, který umoº¬uje programátorovi p°ímou manipulaci s pam¥tí. V p°ípad¥ Javy tento problém £áste£n¥ odpadá, jelikoº o správu pam¥ti se stará garbage collector a programátor nemá p°ímý p°ístup k pam¥ti. Podstatnou vlastností jazyka Java je pak kontrola hranic polí a p°ípadného p°ístupu pomocí indexu mimo tyto meze.

60

KAPITOLA 7.

NÁVRH

V neposlední °ad¥ velkou výhodou Javy je intenzivní podpora ze strany programátorské komunity. Tento fakt zp·sobuje, ºe na Internetu lze bez v¥t²ích obtíºí nalézt celou °adu návod· a ukázkových °e²ení. D·leºitý je v²ak také p°ístup ze strany samotného tv·rce jazyka, rmy Sun Microsystems, Inc. Auto°i se snaºí nejen poskytnout kvalitní dokumentaci, ale i celou °adu návod·. Dále je také velmi podstatný fakt, ºe se rma Sun snaºí exibiln¥ reagovat na p°ípadné bezpe£nostní problémy samotného jazyka skrze £asté uvol¬ování nových verzí b¥hového prost°edí JRE (Java Runtime Environment). Je z°ejmé, ºe programovací jazyk Java je vhodný pro implementaci aplikací z n¥kolika d·vod·. Tím hlavním je z°ejm¥ multiplatformnost. Dal²ím podstatným d·vodem je zcela jist¥ typová kontrola p°i práci s objekty a bezpe£nost p°i práci s pam¥tí. V neposlední °ad¥ je to i vysoká efektivita programování. Jazyk Java má sice °adu nevýhod, nap°. rychlost b¥hu aplikací £i pam¥óvé nároky, ale klady hovo°í dostate£n¥ p°esv¥d£iv¥ pro jeho volbu.

PHP Z poºadavk· na diplomovou práci vyplývá pouºití programovacího jazyka PHP pro implementaci aplikace pro prezentaci vyhodnocení diagnostických dat. PHP je jeden z nejpouºívan¥j²ích jazyk· pro tvorbu dynamických webových stránek. PHP (rekurzivní zkratka PHP: Hypertext Preprocessor,

PHP: Hypertextový preprocesor , p· vodn¥ Personal Home Page) [22] je skriptovací programovací jazyk, ur£ený p°edev²ím pro programování dynamických internetových stránek. Nej£ast¥ji se za£le¬uje p°ímo do struktury jazyka HTML, XHTML £i WML, coº je velmi výhodné pro tvorbu webových aplikací. PHP lze ov²em také pouºít i k tvorb¥ konzolových a desktopových aplikací. PHP skripty jsou provád¥ny na stran¥ serveru, k uºivateli je p°ená²en aº výsledek jejich £innosti. Syntaxe jazyka kombinuje hned n¥kolik programovacích jazyk· (Perl, C, Pascal a Java). PHP je nezávislý na platform¥, skripty fungují bez úprav na mnoha r·zných opera£ních systémech. Obsahuje rozsáhlé knihovny funkcí pro zpracování textu, graky, práci se soubory, p°ístup k v¥t²in¥ databázových server· (mj. MySQL, ODBC, Oracle, PostgreSQL, MSSQL), podporu celé °ady internetových protokol· ( http, SMTP, SNMP, FTP, IMAP, POP3, LDAP...). PHP se stalo velmi oblíbeným p°edev²ím díky jednoduchosti pouºití a tomu, ºe kombinuje vlastnosti více programovacích jazyk· a nechává tak vývojá°i £áste£nou svobodu v syntaxi. V kombinaci s databázovým serverem (p°edev²ím s MySQL nebo PosgreSQL) a webovým serverem Apache je £asto vyuºíván k tvorb¥ webových aplikací. Díky velmi £astému nasazení na serverech se vºila zkratka LAMP tedy spojení Linux, Apache, MySQL a PHP nebo Perl. S verzí PHP 5 se výrazn¥ zlep²il p°ístup k objektov¥ orientovanému programování podobný Jav¥. A z tohoto d·vod· je také vhodné PHP 5 zvolit pro implementaci aplikace pro prezentaci vyhodnocení diagnostických dat.

7.3.2 Volba knihoven V této kapitole jsou popsány knihovny, které jsou pouºity p°i implementaci systému. U kaºdé knihovny je stru£ný popis podávající základní informace spolu s odkazem na internetové stránky dané knihovny.

Apache Commons Commons je Apache projekt [1], který je zam¥°en na v²echny aspekty znovupouºitelných komponent pro programovací jazyk Java. Logo projektu je zobrazeno na obrázku 7.5. V²echny knihovny jsou pod licencí Apache License.

•

BeanUtils - Jednodu²e pouºitelné wrappers pro Java reection a introspect API.

KAPITOLA 7.

NÁVRH

61

Obrázek 7.5: Logo projektu Apache Commons

•

Codec - V²eobecné kódovací/dekódovací algoritmy (nap°. phonetic, base64, URL).

•

Collections - Roz²í°ení nebo zv¥t²ení Java Collections Framework.

•

Email - Knihovna pro zasílání emailu z Javy

•

IO - Kolekce I/O utilit.

•

Lang - Poskytuje extra funkcionalitu pro t°ídy v java.lang.

•

Math - Jednoduché samostatné matematické a statistické komponenty.

•

Net - Kolekce síóvých utilit a protokolových implementací.

•

Primitives - Men²í, rychlej²í a jednodu²²í k pouºití pro práci s typy podporujícími Java primitive types.

jDBI jDBI je navrºen pro poskytnutí pohodlného p°ístupu k tabulkovým dat·m v Jav¥ [5]. Pouºívá Java collections framework pro výsledky dotaz·, poskytuje výhodný zp·sob pro vykonání SQL p°íkaz· a poskytuje podporu jmenných parametr· pro pouºití s libovolnou databází. jDBI poskytuje komfortní rozhraní pro SQL operace. jDBI není zamý²leno jako abstraktní vrstva, ale spí²e jako knihovna, která zjednodu²uje b¥ºné operace. Knihovna je k dispozici pod licencí Apache License.

JDOM JDOM poskytuje kompletní na Jav¥ zaloºené °e²ení pro p°ístup, manipulaci a výstup XML dat z Javovského kódu [6]. Knihovna je k dispozici zdarma.

RCache RCache je jednoduchá objektová Java cache zaloºená na slabých referencích [17]. Rcache je k dispozici pod licencí GPL.

ShiftOne Object Cache ShiftOne Object Cache je Java knihovna [18], která implementuje n¥kolik striktních strategií objektové vyrovnávací pam¥ti, dekorátor·, které p°idávají chování, a jednoduchý framework pro jejich konguraci v aplikaci. Implementovány jsou strategie výb¥ru ob¥ti First In First Out (FIFO), Least recently Used (LRU) a Least Frequently Used (LFU) . Knihovna je k dispozici pod licencí GPL.

62

KAPITOLA 7.

NÁVRH

SLF4J Simple Logging Facade for Java (SLF4J) [19] je jednoduchá fasáda pro libovolné logovací API, která dovoluje koncovým uºivatel·m zvolit konkrétní implementaci p°i nasazení Java aplikace. SLF4J API nabízí pokro£ilou abstrakci nejr·zn¥j²ích logovacích systém·, v£etn¥ JDK 1.4 logging, log4j a logback. K dispozici je také parametrizované logování a podpora MDC. Logo knihovny je zobrazeno na obrázku 7.6. Knihovna je k dispozici zdarma.

Obrázek 7.6: Logo knihovny SLF4J

XStream XStream je jednoduchá Java knihovna pro serializaci objekt· do XML a jejich zp¥tnou deserializaci [23]. Logo knihovny je zobrazeno na obrázku 7.7. Knihovna je k dispozici pod licencí BSD.

Obrázek 7.7: Logo knihovny XStream

7.3.3 Volba databáze Pro úloºi²t¥ datových objekt· je nutné zvolit n¥kterou z n¥kolika voln¥ dostupných rela£ních databází. Podle dlouhodobých zku²eností s výkonností a poskytovanými funkcemi byla zvolena databáze MySQL. MySQL [8] je databázový systém, vytvo°ený ²védskou rmou MySQL AB. Jeho hlavními autory jsou Michael Monty Widenius a David Axmark. Je povaºován za úsp¥²ného pr·kopníka dvojího licencování - je k dispozici jak pod bezplatnou licencí GPL, tak pod komer£ní placenou licencí. Logo databáze je zobrazeno na obrázku 7.8.

Obrázek 7.8: Logo databáze MySQL

KAPITOLA 7.

63

NÁVRH

MySQL je multiplatformní databáze. Komunikace s ní probíhá, jak uº název napovídá, pomocí jazyka SQL. Podobn¥ jako u ostatních SQL databází se jedná o dialekt tohoto jazyka s n¥kterými roz²í°eními. Pro svou snadnou implementovatelnost (lze jej instalovat na Linux, Windows, ale i dal²í opera£ní systémy), výkon a p°edev²ím díky tomu, ºe se jedná o voln¥ ²i°itelný software, má vysoký podíl na v sou£asné dob¥ pouºívaných databázích. Velmi oblíbená a £asto nasazovaná je kombinace MySQL, PHP a Apache jako základní software webového serveru. MySQL bylo od po£átku optimalizováno p°edev²ím na rychlost, a to i za cenu n¥kterých zjednodu²ení: má jen jednoduché zp·soby zálohování, a aº donedávna nepodporovalo pohledy, triggery, a uloºené procedury. Tyto vlastnosti jsou dopl¬ovány teprve v posledních letech, kdy za£aly nej£ast¥j²ím uºivatel·m produktu, programátor·m webových stránek, jiº pon¥kud scházet.

7.4 phpMyAdmin phpMyAdmin [14] je nástroj napsaný v jazyce PHP umoº¬ující jednoduchou správu obsahu databáze MySQL prost°ednictvím webového rozhraní. V sou£asné dob¥ umoº¬uje vytvá°et/ru²it databáze, vytvá°et/upravovat/ru²it tabulky, provád¥t SQL p°íkazy a spravovat klí£e. Jedná se o jeden z nejpopulárn¥j²ích nástroj· pro správu databáze. Je k dispozici v 52 jazycích. Logo aplikace je zobrazeno na obrázku 7.9.

Obrázek 7.9: Logo aplikace phpMyAdmin

7.5 NetBeans IDE NetBeans (logo na obrázku 7.10) je open source projekt s rozsáhlou uºivatelskou základnou, komunitou vývojá°· a s více neº 100 partnery po celém sv¥t¥ [9]. Pod rmu Sun Microsystems, která je hlavním sponzorem projektu, p°e²el na základ¥ akvizice stejnojmenné £eské spole£nosti v °íjnu 1999. Pod open-source licencí byl produkt uvoln¥n v £ervnu 2000. V rámci projektu existují dva hlavní produkty: vývojové prost°edí NetBeans (NetBeans IDE) a vývojová platforma NetBeans (The NetBeans Platform). Vývojové prost°edí NetBeans IDE je nástroj, pomocí kterého programáto°i mohou psát, p°ekládat, ladit a ²í°it programy. Vývojové prost°edí je vytvá°eno v jazyce Java - ale m·ºe podporovat jakýkoliv programovací jazyk (nap°. C++). Krom¥ toho také existuje velké mnoºství modul·, které toto vývojové prost°edí roz²i°ují. Vývojové prost°edí NetBeans je bezplatn¥ ²í°ený produkt, který je moºné pouºívat bez jakýchkoliv omezení. Je pouºitelný na opera£ních systémech Windows, Linux, Max OS X a Solaris. Krom¥ vývojového prost°edí je také dostupná vývojová platforma NetBeans Platform, coº je modulární a roz²í°itelný základ pro pouºití p°i vytvá°ení rozsáhlých aplikací. Nezávislí dodavatelé softwaru poskytují zásuvné moduly pro integraci do této platformy. Tyto moduly slouºí pro vývoj jejich vlastních nástroj· a °e²ení. Oba produkty jsou vyvíjeny pod open source licencí a je moºné je bezplatné pouºívat v komer£ním i nekomer£ním prost°edí. Zdrojový kód je dostupný pod licencí Common Development and Distribution License.

64

KAPITOLA 7.

NÁVRH

Obrázek 7.10: Logo NetBeans IDE

7.6 Platforma NetBeans Platforma NetBeans (logo na obrázku 7.10) je v²eobecn¥ pouºitelný framework pro Swingové aplikace. V podstat¥ je to reakce na skute£nost, ºe kaºdá desktopová aplikace má mnoºinu spole£ných pot°eb, jako je menu bar, toolbar, windowing systém, nastavení, úloºi²t¥, p°ístup k soubor·m, aktualizace. NetBeans Platforma (viz obrázek 7.12) poskytuje v²echny tyto v¥ci, coº znamená, ºe je nemusíme znovu psát, a podobn¥ dal²í poºadavky, sami. M·ºeme se pln¥ soust°edit na business logiku vytvá°ené aplikace (7.11).

Obrázek 7.11: Ikona aplikace postavené na platform¥ NetBeans

Dále pak Platforma NetBeans reaguje na pot°eby po°ádné a exibilní aplika£ní architektury. Namísto pot°eby vytvá°et architekturu pro kaºdou novou aplikaci, dává NetBeans Platforma architekturu zadarmo. NetBeans Platforma je modulární. Výsledkem toho je, ºe aplikace, které jsou na ní vytvá°eny jsou robustní a roz²í°itelné. Mimo to existuje spousta hotových plugin·, které lze pouºít v aplikacích na platform¥ postavených. Aplikace zaloºené na Platform¥ NetBeans [10] mohou dynamicky nahrávat moduly, takºe není pot°eba stahovat celou aplikaci, abychom získali novou verzi nebo upgradovali. Namísto psaní kódu znova znovu m·ºeme pouze sestavit aplikaci z jiº hotových existujících modul· a t¥ºit tak z práce, kterou vykonal n¥kdo jiný. Existuje velké mnoºství pouºitelných open-source modul· napsaných NetBeans komunitou, které jsou p°ipravené pro za£len¥ní do aplikací. Aplikace postavené na Platform¥ NetBeans jsou write-once, run-any where. Pouºitím platformy a modul· vyvíjíme podle zásady, která °íká, ºe r·zné aplikace sdílí stejnou logiku. Zabalením modul· do Platformy NetBeans získáme nádhernou, zna£kovou, multiplatformní aplikaci. Platforma NetBeans je pod licencí GPL. Tato kapitola je zpracována dle [10].

7.7 Modulární programování 7.7.1 Distribuovaný vývoj Nikdo uº nepí²e software celý

podomácku (obrázek 7.13). Mimo sv¥t vloºených systém· (em bedded systems), tém¥° kaºdý spoléhá na knihovny a frameworky, které napsal n¥kdo jiný. Jejich pouºitím se m·ºeme koncentrovat na aktuální logiku aplikace, zatímco znovu pouºijeme infrastrukturu, frameworky a knihovny napsané a poskytnuté jinými. Neboli nevymý²líme znovu kolo (obrázek 7.14), ale pouze ho pouºijeme a nad ním postavíme vozidlo. Takto se zkrátí £as pot°ebný pro vývoj software.

KAPITOLA 7.

65

NÁVRH

Obrázek 7.12: Platforma NetBeans

Nár·st open-source softwaru b¥hem posledních deseti let má za následek velkou znovupouºitelnost knihoven. Pro mnoho druh· program· jiº existují °e²ení r·zných problém·, a tato °e²ení jsou dostupná zdarma. Mnoºina open-source zahrnuje software po£ínaje UNIX kernelem, p°es knihovny jazyka C, utility pro p°íkazovou °ádku, a pokra£uje p°es Web servery a webovské prohlíºe£e, aº k Java utilitám jako je Ant, Tomcat, JUnit, Javacc atd. Psaní moderního software je spí²e proces shromaº¤ování, neº jeho tvorba. Shromáºd¥ní dostupných kousk· a jejich sloºení dohromady je velká £ást moderního vývoje aplikací. Místo toho, aby se psalo v²e od za£átku, lidé, kte°í pot°ebují http sever pro svoji aplikaci, zvolí Apache nebo Tomcat. Ti kte°í pot°ebují databázi m·ºou zvolit MySQL nebo PostgreSQL. Aplikace slepují tyto kousky dohromady a p°idají vlastní logiku. Výsledek je pln¥ funk£ní a výkonná aplikace vyvinutá v pozoruhodn¥ krátkém £ase. Podívejme se nap°íklad na to, jak fungují Linuxové distribuce. Fedora od Red Hat, Mandriva, SUSE a Debian v²echny obsahují z velké £ásti stejné aplikace, napsané stejnými lidmi. Distributor je jednodu²e zabalí a poskytne prost°edí pro jejich instalaci. Dodavatelé distribucí £asto napí²í pouze hlavní správu systému a instalací softwaru a poskytnou prost°edí, ve kterém je zaji²t¥no, ºe zvolené komponenty pracují dohromady správn¥. Tento proces funguje dob°e, práv¥ proto Linux vzrostl hodn¥ na popularit¥. Je evidentní smysluplnost tohoto modelu, nap°íklad Mac OS X je ve skute£nosti FreeBSD UNIX s ur£itými dopl¬ky od Apple. Je nutné uvést, ºe probíraný software je vytvá°en pomocí modelu distribuovaného vývoje. Vývojá°i a distributo°i softwaru se nemusí v·bec znát nebo komunikovat s ostatními a £asto ani nejsou ze stejné zem¥. Tento distribuovaný vývoj má specické charakteristiky. První v¥cí je, ºe zdrojový kód aplikace (nebo opera£ního systému) není pod plnou kontrolou vývojá°e. Je rozprost°en po celém sv¥t¥. Vytvá°ení takového softwaru je nesporn¥ odli²né od vytvá°ení aplikace, jejíº zdrojový kód je celý ve vývojá°ov¥ vlastním úloºi²ti. Dále je nutné si uv¥domit, ºe nikdo pln¥ nekontroluje plánování celého produktu. Nejen zdrojový kód, ale také vývojá°i jsou rozprost°eni po celém sv¥t¥ a pracují podle svého vlastního plánu.

66

KAPITOLA 7.

Obrázek 7.13: Konec

NÁVRH

podomácku vytvo°ených framework·

Taková situace není vlastn¥ tak neobvyklá nebo nebezpe£ná, jak se m·ºe zdát. Kaºdý, kdo se pokusil plánovat projekt s týmem s více n¥º padesáti lidmi, ví. e my²lenka mít v²echno pod plnou kontrolou b¥hem procesu je veliká iluze. Musíme být vºdy p°ipraveni upustit od n¥jaké vlastnosti aplikace nebo uvolnit star²í verzi n¥které komponenty. Stejný model funguje s distribuovaným vývojem. Základním pravidlem, které kaºdý má, je svoboda pouºít nov¥j²í nebo star²í verzi knihovny. Schopnost pouºít externí knihovny a vytvo°it z nich aplikace má za následek vytvá°ení komplexn¥j²ího softwaru v krat²ím £ase a s men²ím vytíºením. Kompromisem je nutnost spravovat tyto knihovny a zaru£it jejich kompatibilitu. To v²ak není jednoduchý úkol. Ale není v²ak jiný praktický, nákladov¥ p°íznivý zp·sob sestavení dne²ních komplexních systém·. Tato kapitola je zpracována dle [32].

7.7.2 Modulární aplikace Technologické °e²ení pouºití distribuovaného vývoje je modularizace. Modulární aplikace, v kontrastu k monolitickému kusu pevn¥ svázaného kódu, ve kterém kaºdá jednotka m·ºe pouºít jiné rozhraní p°ímo, je sloºena z malých odd¥lených kousk· kódu, které jsou vzájemn¥ izolované. Tyto kousky mohou pak být vyvíjeny odd¥len¥ r·znými týmy s vlastním ºivotním cyklem a vlastním plánováním. Výsledky mohu pak být sestaveny dohromady odd¥lenou entitou - distributorem. Jiº del²í dobu je moºné p°idat n¥kolik knihoven na classpath Javovské aplikace a spustit aplikace. NetBeans Platforma p°ebírá správu knihoven dále aktivn¥ p°ebíráním £ásti nahrávání knihoven a zaji²t¥ním, ºe minimální verze knihovny, kterou jiná knihovna pouºívá je adekvátní. Takové knihovny jsou nazývány moduly. Modulární systém NetBeans je runtime container, který zaji²úje integritu systému za b¥hu.

Verzování Rozbití aplikace do odli²ných knihoven vytvá°í nové problémy - je pot°eba zajistit, ºe tyto nezávislé £ásti skute£n¥ pracují dohromady. Existuje n¥kolik moºností, jak to provést. Nejpopulárn¥j²í je verzování. Kaºdý kousek modulární aplikace má £íslo verze, £asto mnoºinu £ísel v Dewey decimálním formátu, jako nap°íklad 1.34.8. Pokud je uvoln¥na nová verze, tak vzroste £íslo verze, nap°íklad 1.34.10, 1.35.1 nebo 2.0. Pokud se nad tím zamyslíme, pak je jasn¥ absurdní my²lenka, ºe vzr·stající £íslo verze m·ºe zakódovat rozdíl mezi dv¥ma verzemi kom-

KAPITOLA 7.

67

NÁVRH

Obrázek 7.14: Nevymý²lejte znovu kolo

plexního kousku software. Ale lze to jednodu²e vysv¥tlit a funguje to velice dob°e, navíc je to populární praktika. Ostatní £ásti modulárního systému mohou pak deklarovat své externí závislosti. Mnoho komponent bude mít n¥kolik externích poºadavk·. Nap°íklad komponenta v modulárním systému m·ºe spoléhat na p°ítomnost XML parseru, nebo na nainstalovaný databázový ovlada£, nebo na textový editor £i na p°ítomnost webovského prohlíºe£e. Pro kaºdou takovou komponentu m·ºe jiný modul poºadovat specickou minimální verzi jejího rozhraní. I kdyby závislosti na externích knihovnách byly minimalizovány, kaºdý program v Jav¥ závisí na verzi Javy jako takové. Skute£ný modulární systém by m¥l být schopen specikovat poºadovanou minimální verzi JDK. Modul by mohl vyºadovat JDK >= 1.5, xmlparser >= 3.0 a webbrowser >=1.5. Za b¥hu kód zodpov¥dný za spu²t¥ní aplikace se musí ujistit, ºe poºadované závislosti jsou spln¥ny, ºe XML parser je dostupný ve verzi 3.0 nebo nov¥j²í, webovský prohlíºe£ ve verzi 1.5 nebo vy²²í atd. Toto zaji²úje práv¥ Systém Modul· NetBeans. Pouºitím takového schéma závislosti pro správu závislostí mezi komponentami v modulárním systému m·ºe fungovat pouze, pokud jsou respektována ur£itá pravidla. Prvním pravidlem je zp¥tná kompatibilita. To znamená, ºe pokud je uvoln¥na nová verze, v²echny kontrakty, které fungovali v p°edchozí verzi budou fungovat v nové také. Jednodu²e se to °ekne, ale h·° zajistí. Pravidlo £íslo dv¥ je, ºe komponenty systému pot°ebují p°esn¥ °íct, co pot°ebují. Pokud mnoºina závislostí modulu se zm¥ní, je nutné to také oznámit, aby mohl systém p°esn¥ rozhodnout, jestli jsou spln¥ny. Takºe pokud startuje kousek modulárního systému spoléhající na novou funkcionalitu, jako nap°íklad HTML editor, pak je nutné p°idat novou závislost (nap°. htmleditor >= 1.0). A pokud za£neme pouºívat nové rozhraní ke komponent¥ HTML editor, které bylo p°idáno ve verzi komponenty 1.7, tak je nutné aktualizovat závislost pro vyºádání verze >= 1.7. NetBeans Systém Modul· zaji²úje tuto druhou £ást v praxi relativn¥ jednodu²e tak, ºe classpath modulu p°i kompilaci bude obsahovat pouze ty moduly, na kterých deklaruje závislosti. Takºe pokud nebude seznam závislostí modulu aktualizován, pak se nezkompiluje.

68

KAPITOLA 7.

NÁVRH

Sekundární informace o verzi Verzovací schéma zmín¥né vý²e se odkazuje na specikaci verze knihovny. Popisuje specický obrázek ve°ejného API v knihovn¥. Je fakt, ºe n¥které verze knihoven mohou obsahovat chyby, které musí být odstran¥ny. Z tohoto d·vodu by m¥l být sekundární verzovací identikátor spojen s komponentou. V kontrastu se specikací verze je to obvykle °et¥zec jako Build20050611 , který m·ºe být testován pouze na rovnost. To poskytuje sekundární identikátor, který m·ºe být pouºit pro ur£ení, jestli specický kousek kódu odstra¬uje danou chybu. Skute£nost, ºe chyba je p°ítomná ve (specika£ní) verzi 3.1 neznamená, ºe ºe bude také ve verzi 3.1 ani v jiném buildu verze 3.1. Takºe z d·vod· opravy chyb nebo speciálního o²et°ení verzí, asociující implementa£ní verzi s knihovnou m·ºe být pouºitelné.

Správa závislostí Systém verzí a závislostí pot°ebuje správce, který zajistí, ºe v²echny poºadavky kaºdého kousku v systému jsou spln¥ny. Takový manaºer m·ºe kontrolovat p°i instalaci kaºdého kousku, ºe v²e v systému z·stane konzistentní. Takto fungují RPM nebo Debian balí£kovací systémy v Linuxových distribucích. Metadata o t¥chto závislostech jsou také pouºitelné za b¥hu. Tato metadata umoº¬ují aplikaci dynamicky aktualizovat své knihovny bez nutnosti vypnutí. M·ºe také ur£it, jestli závislosti modulu, který má být dynamicky nahrán, mohou být spln¥ny, a pokud ne, tak m·ºe popsat problém uºivateli. NetBeans IDE je modulární aplikace. Jeho moduly, coº jsou komponentní knihovny, jsou nalezeny a nahrány za b¥hu. Mohou nainstalovat r·znou funkcionalitu, jako nap°íklad komponenty, poloºky menu, nebo sluºby. Nebo mohou pustit kód b¥hem spou²t¥ní pro programovou inicilizaci. Nebo také mohou vyuºít výhodu mechanismu deklarativní registrace, která r·zné £ásti platformy a IDE nabízí pro registraci sluºeb a inicializuje je na p°ání. Systém Modul· NetBeans pouºívá deklarované závislosti instalovaných komponent pro nastavení rodi£ovských classloader· pro kaºdý modul, který má pak vlastní classloader (obrázek 7.15), který rozhoduje jaké JARy budou hledány, pokud se modul pokou²í nahrát t°ídu. To zaji²úje, ºe classpath libovolného modulu nezahrnuje ºádné JARy modul·, které nejsou uvedeny v jeho stromu závislostí a vynucuje deklaraci závislosti kaºdé komponenty (obrázek 7.16), a modul nem·ºe volat kód v cizím modulu, pokud nedeklaruje závislost na tomto cizím modulu, takºe nebude nahrán v·bec, pokud n¥jaká z jeho závislostí nem·ºe být spln¥na.

7.7.3 Manifest modulárního programování Nikoho uº nep°ekvapí, ºe opera£ní systémy a distribuce jsou navrhovány modulárním zp·sobem. Kone£ný produkt je sestaven z nezávisle vyvinutých komponent. Modularita je mechanismus koordinace práce mnoha lidí po sv¥t¥, spravuje vzájemné závislosti mezi jejich £ástmi projektu a sestavuje velmi komplexní systémy pom¥rn¥ spolehlivým zp·sobem. Ocen¥ní tohoto p°ístupu je nakonec ltrována aº na úrove¬ individuálních aplikací. Aplikace se stávají komplikovan¥j²í a komplikovan¥j²í a jsou stále více sestavovány z kousk· vyvíjených nezávisle. Ale stále musí být spolehlivé. Modulární programování umoº¬uje dosáhnout a spravovat tuto komplexnost. Jelikoº aplikace rostou svoji velikostí a funkcionalitou, tak je nutné rozd¥lit je do individuálních kousk· (coº je nazýváno komponentou, modulem nebo pluginem). Kaºdý takto odd¥lený kousek se pak stane jedním elementem modulární architektury. Kaºdý kousek by m¥l být izolovaný a m¥l by exportovat a importovat dob°e navrºená rozhraní. Rozd¥lení aplikace na moduly p°iná²í ú£inek na kvalitu software. Není p°ekvapující, ºe monolitický kousek kódu, kde na kaºdý °ádek v n¥jakém zdrojovém souboru m·ºe p°istupovat jiný zdrojový soubor, se m·ºe stát stále více provázaný, ne£itelný a nakonec nespolehlivý. Pokud

KAPITOLA 7.

69

NÁVRH

Obrázek 7.15: Classloadery modul·

Obrázek 7.16: Závislosti modul·

n¥kdo pracuje na software n¥kolik let, pak pravd¥podobn¥ pracoval na projektu, kde byly ur£ité £ásti kódu, na kterých se kaºdý z týmu bál provést zm¥nu, kde odstran¥ní jedné chyby m·ºe vytvo°it dv¥ nové chyby. To je entropie vývoje software. Existuje ekonomický tlak opravy problém· nejvhodn¥j²ím moºným zp·sobem, ale nejvhodn¥j²í zp·sob není nutn¥ dlouhodobý zájem základny kódu. Modulární software sniºuje nebezpe£í vzniku spojení poºadavkem, aby rozdílné komponenty systém spolupracovali pomocí kontrakt· na dob°e denovaných API. Není to nejefektivn¥j²í, ale je podstatn¥ hor²í mít mnoºství chyb, které p°ípadn¥ zahubí mnoho komplexních aplikací. Porovnání modulárního návrhu a tradi£ního objektov¥ orientovaného návrhu je jako porovnání strukturovaného programování se ²pagety kódem ze ²edesátých let dvacátého století. pagety kód bylo jméno pro Fortran nebo BASIC programy, kde kaºdý °ádek kódu mohl pouºít p°íkaz GOTO pro p°emíst¥ní °ízení na jiné místo v programu. Takovýto kód m¥l sklony k tomu, aby byl napsaný tak chaotickým zp·sobem, ºe pouze autor programu mohl rozum¥t logice programu. Strukturované programování se pokusilo sníºit tento zmatek p°edstavením blok· kódu: for cykly,

70

KAPITOLA 7.

NÁVRH

while cykly, p°íkazy if, procedury a volání procedur. Samoz°ejm¥ to zlep²ilo situaci a £itelnost a spravovatelnost aplikací vzrostla. Kdyº uº nic jiného, bylo alespo¬ jisté, ºe volání metody se

1

bude vracet pouze jednou . Klasický objektov¥ orientovaný styl programování se v n¥kterých p°ípadech podobá situaci p°edtím, neº p°i²lo strukturované programování. Pod termínem klasický objektov¥ orientovaný styl, se má na mysli styl programování typicky dnes vyu£ovaný. Je to také druh kódu, který dostaneme pouºitím UML nástroj·: velké pouºití d¥di£nosti a tém¥° v²echno p°episovatelné a ve°ejn¥ deklarované. V takové aplikaci libovolná metoda v libovolné t°íd¥ m·ºe potenciáln¥ volat tém¥° v²echny metody libovolné jiné t°ídy. Samoz°ejm¥, ºe tam jsou modikátory ve°ejného, soukromého a chrán¥ného p°ístupu, ale granularita povolení p°ístupu je ud¥láno na úrovni jednotlivé t°ídy nebo £lena t°ídy. To je p°íli² vzdálená nízkoúrov¬ová pomoc jako základ tvorby návrhu bloku aplikace. Modularita je o interakci mezi systémy, nikoliv mezi malými £ástmi subsystému. Modulární aplikace jsou sloºeny z modul·. Jeden modul je kolekce Javovských t°íd v Javovských balí£cích. N¥které z t¥chto balí£k· jsou ve°ejné a ve°ejné t°ídy v nich jsou nabízeny jako exportované API, které ostatní moduly mohou volat. Ostatní t°ídy jsou soukromé a nemohou být z venku p°ístupovány. Krom¥ toho, být modulem znamená, ºe knihovna musí vykazovat seznam závislostí ne svého obklopujícího prost°edí (ostatní moduly, JRE atd.). Uvnit° modulu mohou být praktikovány ²patné praktiky návrhu, ale architektura aplikace m·ºe být zachována kontrolou závislostí v²ech obklopujících modul·. Pokud n¥jaký modul není závislý na jiném, pak jeho t°ídy nemohou p°ímo p°istupovat ke t°ídám daného modulu. To zachová architekturu £istou zabrán¥ním GOTO-like kódovacích konstrukcí, coº by mohlo jinak spojit naprosto nesouvisející £ásti základny kódu. N¥kdy lidé °íkají, ºe jejich aplikace jsou p°íli² malé nato, aby pouºili modulární architekturu. Tak tomu samoz°ejm¥ m·ºe být. Ale pokud je to nad úrove¬ studentského projektu, pak je pravd¥podobné, ºe se to bude £asem dále vyvíjet. Jak se aplikace vyvíjí, tak pravd¥podobn¥ roste. A jak roste, je velice pravd¥podobné, ºe bude £elit problému entropie software. Prvním krokem v návrhu komplexní aplikace je návrh její architektury. Z tohoto d·vodu je nutné denovat a rozum¥t závislostem mezi £ástmi aplikace. Je mnohem jednodu²²í to provést zp·sobem modulární aplikace. Tedy vºdy se rozumn¥ za£íná návrhem libovolné aplikace modulárním zp·sobem. Tím se pak vytvá°í infrastruktura, která nám dovolí vytvá°et mnohem robustn¥j²í aplikace a vyhnout se úd¥lu manuálního ú£etnictví. P°epsáním neuspo°ádaných provázaných tradi£ních objektov¥orientovaných aplikací tak, aby m¥li dobrý modulární návrh, je obtíºný úkol. A £asto to je tak, ºe projekt nedovoluje z £asových d·vod· p°epsat nebo znovu navrhnout jeho architekturu. asto programáto°i musí ºít se starým monolitickým kódem se stéle rostoucími náklady na údrºbu, protoºe je známo, ºe kód pracuje správn¥. Modulární návrh se pouºije v prost°edí, kde architektura nem·ºe pomalu upadat do neudrºovatelného stavu, aniº by si toho n¥kdo v²ímal. Pokud je vytvo°ena závislost mezi dv¥ma £ástmi modulární aplikace, pak je nutné ud¥lat ur£ité explicitní úkony pro nastavení závislostí. To se nem·ºe stát náhodou. Pokud není d·vod k úprav¥ neuspo°ádaného návrhu, je to prost°edí, které je promy²len¥ udrºované. Modularita dává systém·m £ist²í návrh a kontroluje provázanost modul·. Dává také vývojá°·m v¥t²í exibilitu v údrºb¥. Je nutné si to uv¥domit, ºe p°i startu nového projektu, bez ohledu na po£áte£ní rozsah projektu. Modulární návrh bude mít velké výhody pro architekturu celé aplikace, jak bude dále bude r·st. Skute£né výhody modulárního programování nemusí být o£ividné v první verzi aplikace. Ale stanou se z°ejmými pozd¥ji sníºením pracnosti tvorby verze 2.0 a 3.0. A£koliv modulární programování nep°idává podstatnou cenu na tvorbu verze 1.0 aplikace, existuje malý d·vod, pro£ nepouºít tento p°ístup na v²echny projekty. Mnoho programátor· je p°ekvapeno (n¥kdy i zd¥²eno) kdyº najdou n¥co, co napsali p°ed patnácti lety, stále pouºívané. 1

Krom¥ okrajových podmínek, kdy se nemusí nikdy vrátit, vyhodit výjimku atd.

KAPITOLA 7.

NÁVRH

71

Jelikoº nem·ºeme p°edpovídat budoucnost na²eho kódu, m·ºeme ji v²ak navrhovat zp¥tn¥ od po£átku.

7.7.4 Entropie vývoje software Tato kapitola je zpracována dle [11]. Ukazuje vývoj systému, která nemá jasn¥ denovaná rozhraní mezi jednotlivými £ástmi. Je to odstra²ující p°íklad a d·vod, pro£ se zabývat modulárním programováním.

Verze 1.0 Verze 1.0 (obrázek 7.17) je £ist¥ navrºena.

Obrázek 7.17: Entropie vývoje software - verze 1.0

Verze 1.1 Ve verzi 1.1 (obrázek 7.18) je pouºito pár d·leºitých hack·, které budou upraveny ve verzi 2.0.


Verze 2.0 Verze 2.0 (obrázek 7.19). Ooops... ale funguje to.

72

KAPITOLA 7.

NÁVRH


Verze 3.0 Verze 3.0 (obrázek 7.20) - pomoc. Kdyº opravím jednu chybu, tak vytvo°ím dv¥ dal²í.


Verze 4.0 Verze 4.0 (obrázek 7.21) je £ist¥ navrºena a kompletn¥ p°epsána. Je to o rok pozd¥ji, ale funguje to.

Verze 4.1 Verze 4.1 (obrázek 7.22) vypadá znám¥.

Verze x.x Verze x.x (obrázek 7.23). Podobný vývoj jako u p°edchozích verzí.

7.7.5 Moduly vs. Pluginy Problémem m·ºe být potenciální terminologický zmatek v pouºívání termín· plugin a modul . Prakticky mezi nimi není ºádný rozdíl. Modul je jednodu²e jednotka kódu, kterou je moºné zasunout ( plug in ) do platformy nebo IDE. Pojem plugin byl zpopularizován r·znými prost°edími a m·ºe být také jednodu²e aplikován na moduly vytvo°ené pro NetBeans Platformu.

KAPITOLA 7.

NÁVRH

73



7.8 Zd·vodn¥ní návrhových rozhodnutí Byly popsány pouºité technologie spolu s jejich zd·vodn¥ním. Aplikace Rubicon je navrºena a bude z n¥kolika d·vod· implementována modulárn¥ na Platform¥ NetBeans. Reektuje to poºadavek na moºnost zpracování diagnostických dat od r·zných za°ízení po ukon£ení vývoje systému. Díky pouºití Platformy NetBeans bude systém Rubicon snadno roz²í°itelný o zpracování diagnostických dat r·zných za°ízení. Platforma NetBeans je vytvo°ena v programovacím jazyce Java a k prezentaci GUI pouºívá framework Java Swing, £ímº je spln¥n dal²í poºadavek. Aplikace pro prezentaci diagnostických dat bude pak implementována v programovacím jazyce PHP a za£l¥n¥na taktéº do modulárního systému, kterým je Produk£ní Server AD Praha. Díky pouºití modul· i zde je moºné vyvíjet ob¥ aplikace zcela odd¥len¥, pouze vyjít z dosavadní analýzy a návrhu obecné infrastruktury vlastního jádra aplikace. Pouºitím modulárních aplikací, do nichº budou vytvo°ené aplikace za£len¥ny, je moºno se soust°edit pouze na implementaci logiky vlastního zpracování a prezentace diagnostických dat. Odpadají £innosti s vývojem základu systém·, nad kterým by bylo postaveno vlastní zpracování a prezentace. Dal²í výhodou modulárního °e²ení systému je moºnost dal²ího roz²i°ování dle nových poºadavk·. Samoz°ejmostí je moºnost implementace nových £ástí aplikací i zcela novými programátory dle denovaných rozhraní v obou systémech. Pouºití modularizace sebou nese i ur£ité poºadavky, které byly probrány vý²e v kapitole

lární programování.

Modu-

Nicmén¥ výhody zmín¥né d°íve pouºití této metodologie vývoje p°evaºují

a její pouºití bude pro systém Rubicon p°ínosné.

74

KAPITOLA 7.

NÁVRH

Obrázek 7.23: Entropie vývoje software - verze x.x

7.9 Návrh komunikace s aplikací Spider Komunikace s aplikací Spider bude probíhat po síti pomocí rozhraní TCP/IP. Díky této koncepci je zaru£ena moºnost b¥hu aplikací na r·zných po£íta£ích s r·znými opera£ními systémy. Vlastní komunikace pak bude probíhat po bajtech a p°éná²et se budou XML zprávy, které by m¥li umoºnit roz²i°ování moºných typ· zasílaných zpráv. Z d·vodu zabezpe£ení aplikací je dále pro tuto komunikaci navrºeno XML Schéma. Kompletní zdroj tohoto schéma je uveden na p°iloºeném médiu. Na obrázku 7.24 je nazna£ena jeho struktura, která reektuje vý²e zmín¥né poºadavky. Hlavní tag

transport

zapouzd°uje celý p°e-

nos zprávy. Pod ním je pak tag symbolizující za°ízení, ke kterému se zpráva vztahuje (zde

koa1.

Dále jsou pak jiº jednotlivé p°íkazy (command), jejichº typ je dán atributem typ p°íkazu

(commandType). Kaºdý p°íkaz pak m·ºe obsahovat libovolné mnoºství parametr· (tag které dopl¬ují p°íkaz a jsou nositeli konkrétní p°ená²ení informace (name).

param),

Obrázek 7.24: Návrh XML Schéma komunikace s aplikací Spider

7.10 Návrh zpracování diagnostických dat za°ízení KOA1 Plugin pro zpracování diagnostických dat.za°ízení KOA1 vychází z návrhu t°íd obecného ºelezni£ního zabezpe£ovacího a technické diagnostiky. Návrh pouze reektuje skute£nosti, které se týkají konkrétního formátu diagnostických dat za°ízení KOA1. P°i návrhu jsou hojn¥ vyuºívány klasické návrhové vzory, díky nimº bude implementace snadná a p°ehledná. Jelikoº jsou diagnostická data uloºena v binárních souborech a procházena sekven£n¥, je nutné v¥d¥t, který soubor byl zpracován jako poslední, aby se po obdrºení zprávy od aplikace Spider

KAPITOLA 7.

75

NÁVRH

zpracoval pouze nový nezpracovaný soubor. Proto byla nad rámec obecného návrhu technické diagnostiky p°idána nová t°ída, a to

SprávceSoubor·TechnickýchStav·.

Tato t°ída má pak

za úkol vlastní algoritmus ur£ující, které soubory s technickými stavy za°ízení nebyly dosud zpracovány. Za°ízení, u kterých jsou zpracovávána diagnostická data, je nutné ukládat do persistentního úloºi²t¥. Obrázek ukazuje datový pohled na objekty za°ízení, které budou umíst¥ny v databázi. Z obrázku 7.25 je patrná závislost tabulky za°ízení koa1 na tabulce obecných za°ízení, která je realizována cizím klí£em. Pro ukládání vyhodnocení diagnostických dat do databáze jsou pak navrºeny tabulky pro kaºdou relaci diagnostických veli£in zvlá²´. Mimo datové úloºi²t¥ je nutné také ukládat vlastní objekty za°ízení. Za tímto ú£elem bude vyuºita knihovna XStream, která zaji²úje objektovou serializaci a deserializaci do XML formátu. Serializované objekty pak budou uloºeny do adresá°e p°íslu²ného za°ízení, kde jsou umíst¥na jeho archivovaná diagnostická data.

Obrázek 7.25: Schéma datového úloºi²t¥ za°ízení KOA1

P°i zpracování diagnostických dat za°ízení KOA1 je d·leºitá informace o £asu. as, který je zaznamenaný v souborech s diagnostickými daty se m·ºe v kaºdé stanici li²it, a je proto nutné tyto £asy synchronizovat. Jako referen£ní £as je v tomto p°ípad¥ zvolen £as na serveru KOAS. Za ú£elem správného zpracování a následného vyhodnocení diagnostických dat je nutné k souboru s diagnostickými daty dodat i informaci o £asovém posunu £asu ve stanici a na serveru. Informace o £asovém posunu jsou uloºeny do souboru se stejným názvem, který má soubor,

76

KAPITOLA 7.

NÁVRH

desc. Soubor obsahuje XML, pro který je navrºeno metainf uvozuje zabaluje vlastní typ za°ízení (zde koa1). Nejd·leºit¥j²í poloºkou v²ak

jehoº se £asový posun týká, spolu s p°íponou

XML Schéma, které je zobrazeno na obrázku 7.26. Hlavní tag informace. Následuje tag reprezentující je tag

time,

který obsahuje UTC £as na serveru KOAS v okamºiku staºení souboru ze stanice

(koas) a £as ve stanici (lds). Mohou být p°ipojeny v budoucnu i dal²í informace, jako nap°íklad kontrolní sou£et MD5 pro ov¥°ení integrity souboru apod.

Obrázek 7.26: Návrh XML Schéma metainformací k souboru s diagnostickými daty

7.11 Návrh uºivatelského rozhraní systému zpracování diagnostických dat Na obrázku 7.27 je zobrazen návrh hlavního okna aplikace Rubicon pro zpracování diagnostických dat. Rozhraní je navrºeno dle b¥ºných zvyklostí, kdy v horní £ásti okna je hlavní menu aplikace, v levém panelu jsou rozbalovací stromy s r·znými informacemi a nastaveními. Nejv¥t²í £ást okna pak tvo°í panel s ovládáním aplikace a zobrazením jejího stavu. Ve spodní £ásti rozhraní je pak patrný panel, který slouºí k zobrazení aktuálních pr·b¥h· zpracování diagnostických dat. Jedním z p°ípad· uºití je moºnost správy systému. Návrh okna pro uspokojení tohoto poºadavku je zobrazen na obrázku 7.28. V horní £ásti okna jsou patrné p°epína£e pro zobrazení r·zných kategorií nastavení. St°ední a nejv¥t²í £ást slouºí k prvk·m pro volbu daných nastavení kategorie. Ve spodní £ásti jsou tla£ítka pro potvrzeni a zru²ení volby nastavení. Dal²ím poºadavkem, pro který je navrºeno uºivatelské rozhraní, je informování o stavu systému, které se pouºívá p°i neo£ekávané události systému. Návrh rozhraní tohoto okna je zobrazen na obrázku 7.29. Z okna je patrný panel, který obsahuje popis chyby. K dispozici jsou ovládací prvky pro zobrazení podrobností chyby s výpisem zásobníku volání a pro zav°ení okna se zobrazením stavu systému.

7.12 Návrh uºivatelského rozhraní modulu prezentace diagnostických dat Na obrázku 7.30 je zobrazen návrh hlavního okna aplikace PServeru, resp. jejího aktuálního stavu. Z obrázku vyplývá umíst¥ní informací o vyhodnocených diagnostických datech. Je vid¥t také hlavní menu aplikace, které je v levé £ásti. Horní £ást pak slouºí k identikaci navigace v systému, zobrazení uºivatelského jména a v neposlední °ad¥ také k zobrazení aktuálního data £asu.

KAPITOLA 7.

NÁVRH

77

Obrázek 7.27: Návrh hlavního okna aplikace Rubicon

7.13 Shrnutí V této kapitole byl popsán návrh systému Rubicon. Systém byl navrºen modulárn¥, a to v obou jeho £ástech (aplikace pro zpracování archivovaných diagnostických dat i aplikace pro prezentaci vyhodnocení diagnostických dat). Podle tohoto návrhu je moºno provést vlastní implementaci, která je popsána v následující kapitole. Vzhledem k návrhu aplikace modulárním zp·sobem budou tedy v dal²í £ásti této diplomové práce popsány jednotlivé podsystémy aplikace Rubicon, které reektují u£in¥ný návrh modulární aplikace a které dohromady vytvo°í funk£ní a robustní systém pro zpracování a prezentaci diagnostických dat. V poslední £ásti této kapitoly byla navrºena gracká uºivatelská rozhraní a formáty dat pro vým¥nu informací s externími systémy, které byly zaloºeny na pouºití XML Schema denition.

78

KAPITOLA 7.

Obrázek 7.28: Návrh okna nastavení aplikace Rubicon

Obrázek 7.29: Návrh okna chyby aplikace Rubicon

NÁVRH

KAPITOLA 7.

NÁVRH

Obrázek 7.30: Návrh hlavního okna aplikace PServer

79

80

KAPITOLA 7.

NÁVRH

KAPITOLA 8.

81

IMPLEMENTACE

8 Implementace 8.1 Úvod Implementace spo£ívá v p°evodu návrhového modelu do spustitelného kódu. Zp·sob provedení závisí na volb¥ konkrétního programovacího jazyka. Sou£ástí implementace je systémová integrace, implementace t°íd a testování jednotek. Jedná se o programátorské aktivity. V podstat¥ cílem implementace je transformace návrhového modelu do spustitelného kódu. Je nutné také poznamenat, ºe není moºné z rozsahových d·vod· popsat ve²keré implementa£ní detaily v této práci. K dispozici je pln¥ dokumentovaný kód dle poºadovaných standard·, tudíº je moºné prohlédnout konkrétní implementaci ve zdrojových souborech, které jsou k dispozici na p°iloºeném DVD.

8.2 Rozhraní a komponenty V této kapitole budou probrány jednotlivá rozhraní a komponenty systému Rubicon. Rozhraní spolu s návrhovými podsystémy umoº¬ují tvorbu exibilních systémových architektur. Podsystém je zvlá²tní typ komponenty. Aktivita navrhnout podsystém spo£ívá v rozbití systému na maximáln¥ autonomní a na sob¥ nezávislé sou£ásti, Tyto sou£ásti se nazývají práv¥ podsystémy (nebo také subsystémy). Interakci mezi podsystémy zprost°edkovávají rozhraní. Cílem návrhu podsystém· je minimalizace vazeb v systému. Vznikají vhodná rozhraní, která zaji²újí, ºe v²echny podsystémy správným zp·sobem realizují chování p°edepsané pomocí rozhraní.

8.2.1 Fyzická architektura a rozvrstvení Kolekce návrhových podsystém· a rozhraní utvá°í fyzickou architekturu modelu. Podsystémy a rozhraní jsou uspo°ádány do spojitých celk· aplikací architektonického vzoru rozvrstvení (layering pattern). Vzor rozvrstvení umoº¬uje uspo°ádat návrhové podsystémy a návrhová rozhraní do podsystém·, jeº jsou sémanticky spojité. Podstatou tvorby robustní rozvrstvené architektury je správa vazeb mezi jednotlivými podsystémy. D·leºitá je také minimalizace vazeb mezi vrstvami. Na obrázku 8.1 je zobrazena fyzická architektura systému Rubicon s vyuºitím vzoru rozvrstvení.

P°ístupová rozhraní ). vlastního jádra aplikace (Já-

V nejvy²²í vrstv¥ prezenta£ní logiky je podsystém p°ístupových rozhraní ( Tento podsystém p°istupuje pomocí návrhového vzoru Fasáda do

dro ).

Vrstvu obchodní logiky systému pak tvo°í komponenty ºelezni£ních zabezpe£ovacích za°ízení

ZS ) a komunikace (Komunikace ). Z t¥chto podsystém· jsou denována rozhraní pro p°ipojení

(

nových implementací pomocí zásuvných modul·, jak bylo zmín¥no v p°edchozí kapitole a plyne z návrhu modulární aplikace.

ZS )

Podsystém ºelezni£ních zabezpe£ovacích za°ízení (

zastupuje

SprávceZa°ízení,

který je

navrºen podle návrhového vzoru Singleton (pro zaji²t¥ní jediné instance správce za°ízení v systému) a Facade. Tento správce pak vyhledává v systému v²echny registrované poskytovatele za°ízení (PoskytovatelZa°ízení), coº je dal²í rozhraní tohoto modulu. Poskytovatelé za°ízení jsou odpov¥dní za správu konkrétních produkt· (za°ízení s danou specikací), které tvo°í práv¥ zásuvné moduly aplikace. Na tyto poskytovatele jsou poté delegovány ºádosti o zpracování diagnostických dat, které p°ichází od správce komunikace Komunika£níhoRouteru. Podsystém ºelezni£ních zabezpe£ovacích za°ízení (

ZS )

dále denuje rozhraní pro vlastní za°í-

zení, která implementují práv¥ zásuvné moduly. Pomocí t¥chto rozhraní je zaji²t¥na nezávislá implementace zpracování archivovaných diagnostických dat v konkrétním dodavatelském pluginu. Správce za°ízení pouze pomocí tohoto rozhraní spou²tí vlastní zpracování diagnostických dat, pokud p°ijde takový poºadavek od správce komunikace. Vlastní zpracování diagnostických

82

KAPITOLA 8.

IMPLEMENTACE

Obrázek 8.1: Fyzická architektura systému Rubicon

dat je pak °e²eno v konkrétním dodavatelském pluginu.

Komunikace ) je odpov¥dný za komunikaci s externími systémy. Systém

Podsystém komunikace (

zastupuje sm¥rova£ komunikace (Komunika£níRouter), který je také navrºen podle návrhového

vzoru Singleton a Facade. Router sm¥ruje zprávy od externích systém· ke správci za°ízení, který, jak bylo zmín¥no vý²e, je forwarduje na p°íslu²né poskytovatele a za°ízení. Podsystém také denuje rozhraní komunika£ní proxy (Komunika£níProxy), pomocí které lze k systému pomocí zásuvného modulu p°ipojit dal²í externí systém, který má na starosti koncentraci archivovaných diagnostických dat. Zásuvné moduly zmi¬ované vý²e tvo°í podle poºadavk· v p°ípad¥ zpracování diagnostických

KOA1 a PServer.

dat za°ízení KOA1 podsystém PServer podsystémy

Spider

a

v p°ípad¥ komunikace s externími systémy Spider a

DatováÚloºi²t¥ ).

Vrstvu domény aplikace kone£n¥ tvo°í i podsystém datových úloºi²´ ( podsystém je op¥t p°ístupný pomocí fasády

SprávceDatovýchÚloºi²´.

odpov¥dnost za správu úloºi²´ archivovaných diagnostických dat.

Tento

Tento podsystém má

KAPITOLA 8.

83

IMPLEMENTACE

Nejniº²í vrstvu aplikace nakonec tvo°í vrstva technických sluºeb, které jsou p°ístupné v²em podsystém·m systému. Tato vrstva tak obsahuje jednak knihovny dostupné v Platform¥ NetBeans, jednak celou kolekci knihoven programovacího jazyka Java, a kone£n¥ knihovnu roz²i°ujících uti-

XUtilites ), která obsahuje dodate£né knihovny pot°ebné pro zaji²t¥ní funkcí systému v£etn¥

lit (

znovupouºitelných knihoven zmín¥ných v p°edchozí kapitole návrhu. Z uvedeného schématu je z°ejmá fyzická architektura systému. Je také z°ejmé rozvrstvení komponent systému. Díky jednotlivým modul·m je odpov¥dnost jednotlivých modul· zapouzd°ena v p°íslu²ném podsystému. V²echny moduly jsou pak umíst¥ny v NetBeans Runtime Containeru v p°ípad¥ aplikace zpracování diagnostických dat, a v PServer Containeru v p°ípad¥ systému prezentace diagnostických dat. Ob¥ modulární platformy nám umoº¬ují roz²í°ení funk£nosti pomocí zásuvných modul·, jak je z°ejmé z architektury. Tím je spln¥n poºadavek na roz²í°itelnost zpracování a prezentace diagnostických dat od r·zných za°ízení. Stejn¥ tak pomocí zásuvného modulu, která implementuje rozhraní komunika£ní proxy lze k systému p°ipojit jiný externí systém, která je odpov¥dný za koncentraci archivovaných diagnostických dat.

8.2.2 ZS Podsystém ºelezni£ních zabezpe£ovacích za°ízení je odpov¥dný za správu v²ech za°ízení registrovaných v systému. Podsystém zastupuje

SprávceZa°ízení,

který je navrºen podle návrhového

vzoru Singleton (pro zaji²t¥ní jediné instance správce za°ízení v systému). Tento správce pak vyhledává v systému v²echny registrované poskytovatele za°ízení (PoskytovatelZa°ízení), coº je dal²í rozhraní tohoto modulu. Ukázka kódu 8.1 ukazuje implementaci správce za°ízení, resp metody, která vyhledává registrované správce za°ízení. V této metod¥ je pouºit mechanismus vyhledávání sluºeb, které registrují jednotlivé zásuvné moduly aplikace. V tomto p°ípad¥ se jedná o pluginy produkt·. Mechanismus vyhledávání se nazývá

/∗ ∗ ∗ ∗ ∗ ∗

/

Lookup

(viz [32]).

Ukázka kódu 8.1: Implementace SprávceZa°ízení

Vraci vsechny poskytovatele zarizeni registrovane v systemu . @return vsechny poskytovatele zarizeni registrovane v systemu

private C o l l e c t i o n g e t D e v i c e P r o v i d e r s ( ) {

// ( vytvorit , pokud nejsou inicializovany , a) v r a t i t instance // poskytovatelu zarizeni registrovanych v systemovem filesystemu

return Lookups

. f o r P a t h ( this .DEVICE_PROVIDERS_FOLDER_IN_SYSTEM_FILESYSTEM) . lookupAll ( DeviceProvider . class ) ;

}

/∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗

/

Zpracovava diagnosticka data zarizeni s danym oznacenim a identifikatorem . @param s p e c i f i c a t i o n oznaceni zarizeni @param id i d e n t i f i k a t o r zarizeni @throws NullPointerException pokud oznaceni nebo i d e n t i f i k a t o r zarizeni je null

public void p r o c e s s D i a g n o s t i c D a t a ( S t r i n g s p e c i f i c a t i o n , S t r i n g i d ) { i f ( s p e c i f i c a t i o n == null | | i d == null ) { throw new N u l l P o i n t e r E x c e p t i o n ( ) ; }

84

KAPITOLA 8.

IMPLEMENTACE

// na ji t poskytovatele zarizeni s danym oznacenim

for ( D e v i c e P r o v i d e r d e v i c e P r o v i d e r : this . g e t D e v i c e P r o v i d e r s ( ) ) { i f ( deviceProvider . providesDevice ( s p e c i f i c a t i o n )) {

// v y t v o r i t zpracovatele diagnostickych dat zarizeni

Processer processer = deviceProvider . getDeviceProcesserNewInstance ( ) ;

// nastavit zarizeni ke zpracovani diagnostickych dat processer . process ( deviceProvider . getDevice ( id ) ) ;

// zpracovat diagnosticka data }

}

}

P r o c e s s i n g M a n a g e r . g e t I n s t a n c e ( ) . run ( p r o c e s s e r ) ;

Druhá metoda pak ukazuje zpracování diagnostických dat, které je forwardováno od sm¥rova£e komunikace. V této metod¥ je patrný pr·chod poskytovateli za°ízení, kdy je podle ozna£ení za°ízení vyhledán konkrétní poskytovatel a následn¥ spu²t¥no zpracování diagnostických dat na za°ízení, které tento poskytovatel vrací. Za°ízení implementuje zmi¬ované rozhraní za°í-

Processer ví, jakou metodu volat pro zpracování diagnostických dat (processDiagnosticData). Vlastní zpracování pak °e²í jiº konkrétní implementace daného po-

zení, tudíº zpracovatel

skytovatele, která je zapouzd°ena v daném zásuvném modulu a implementuje tuto metodu. V tomto podsystému jsou také umíst¥ny t°ídy z domény technické diagnostiky. Závislosti jsou takové, jak byly navrºeny a ukázány v p°edchozí kapitole. Tyto t°ídy pak roz²i°ují práv¥ zásuvné moduly produkt· a implementují konkrétní strategii zpracování diagnostických dat. Implementace t¥chto t°íd je jednoduchá a prohlídnout si ji lze p°ímo ve zdrojových kódech, které jsou k dispozici na p°iloºeném DVD.

8.2.3 Komunikace Komunikace ) je odpov¥dný za komunikaci s externími systémy. Systém

Podsystém komunikace (

zastupuje sm¥rova£ komunikace (Komunika£níRouter), který je také navrºen podle návrhového

vzoru Singleton. Router sm¥ruje zprávy od externích systém· ke správci za°ízení, který, jak bylo zmín¥no vý²e, je forwarduje na p°íslu²né poskytovatele a za°ízení. Podsystém také denuje rozhraní komunika£ní proxy (Komunika£níProxy), pomocí které lze k systému pomocí zásuvného modulu p°ipojit dal²í externí systém, který má na starosti koncentraci archivovaných diagnostických dat. Komunika£ní správce podobn¥ jako správce za°ízení hledá nainstalované pluginy pro komunikaci s externími systémy pomocí mechanismu

Lookup.

Jednotlivé implementace pak zaji²újí

konkrétní interpretaci p°íchozích a odchozích zpráv do r·zných systém·. Takto je moºno komunikovat s jedním systémem nap°. pomocí TCP/IP po bajtech a s druhým po °et¥zcích. V ukázce 8.2 je uvedena implementace sm¥rování zpráv pomocí sm¥rova£e komunikace ve t°íd¥

CommunicationRouter.

Z ukázky kódu je patrný zp·sob ltrování neºádoucích zpráv a také

logování ve²kerého provozu na virtuální síti, kterou router zastupuje.

/∗ ∗ ∗ ∗ ∗ ∗ ∗

Ukázka kódu 8.2: Implementace sm¥rování zpráv

Smeruje zpravu . @param message @param parameters @throws NullPointerException

zprava parametry zpravy pokud je zprava null

KAPITOLA 8.

∗

85

IMPLEMENTACE

/

public void r o u t e ( Message message , S t r i n g . . . p a r a m e t e r s ) { i f ( message == null ) { throw new N u l l P o i n t e r E x c e p t i o n ( ) ; }

switch ( message ) { case PROCESS_DIAGNOSTIC_DATA: this . r o u t e P r o c e s s D i a g n o s t i c D a t a ( p a r a m e t e r s ) ; break ; default :

CommunicationRouter .LOGGER. warn ( "unknown message : " + message . t o S t r i n g ( ) ) ; break ;

// NOI18N

}

}

/∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗

/

Smeruje zpravu " ; Zpracovani diagnostickych dat" ; . @param parameters parametry zpravy @throws NullPointerException pokud parametry zpravy jsou null

private void r o u t e P r o c e s s D i a g n o s t i c D a t a ( S t r i n g . . . p a r a m e t e r s ) { i f ( p a r a m e t e r s == null ) { throw new N u l l P o i n t e r E x c e p t i o n ( ) ; }

CommunicationRouter .LOGGER. i n f o ( " r o u t e − p r o c e s s d i a g n o s t i c data with p a r a m e t e r s " + Arrays . a s L i s t ( p a r a m e t e r s ) ) ;

// NOI18N

DevicesManager . g e t I n s t a n c e ( ) . p r o c e s s D i a g n o s t i c D a t a ( p a r a m e t e r s [ 0 ] , parameters [ 1 ] ) ;

}

8.2.4 Datová úloºi²t¥ Tento podsystém je op¥t p°ístupný pomocí fasády


Tento podsys-

tém má odpov¥dnost za správu úloºi²´ archivovaných diagnostických dat. Pro uchování objekt· datových úloºi²´ je zde vyuºita cache, která je zaloºena na slabých referencích. Tuto cache poskytuje knihovna


/∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗

/

RCache.

Ukázka kódu 8.3 p°edstavuje £ást implementace t°ídy

Ukázka kódu 8.3: Implementace SprávceDatovýchÚloºi²´

Spravce datovych u l o z i s t . @author Jaroslav Bien @version 1.0 2008 −03 −25 @since 1.0

public f i n a l c l a s s DataStoragesManager {

/ ∗ navrhove vzory

−

Singleton , Facade ∗ /

86

KAPITOLA 8.

IMPLEMENTACE

/ ∗ ∗ Instance DataStoragesManager. ∗ / private s t a t i c DataStoragesManager i n s t a n c e ;

/ ∗ ∗ Cache datovych u l o z i s t . ∗ /

private f i n a l Cache STORAGES_CACHE = new WeakCache ( ) ;

/∗ ∗ ∗ Nedovolit nikomu v y t v o r i t instanci teto tridy . ∗/ private DataStoragesManager ( ) {

}

/∗ ∗ ∗ ∗ ∗ ∗

/

Vraci instanci DataStoragesManager. @return instanci DataStoragesManager

public s t a t i c synchronized DataStoragesManager g e t I n s t a n c e ( ) { i f ( i n s t a n c e == null ) { i n s t a n c e = new DataStoragesManager ( ) ; }

}

return i n s t a n c e ;

// . . . } Kaºdé datové úloºi²t¥ je reprezentováno jednozna£ným identikátorem, který je unikátní a pouºívá se v úloºi²ti (viz datová architektura systému). Datové úloºi²t¥ také má své jméno, ale hlavn¥ cestu p°ipojení. Výsledná cesta k datovému úloºi²ti se pak skládá ze £ty° £ástí:

•

kongura£ní £ást systému (nap°.

•

poloºka

•

adresá° stanice - poloºka

•

podadresá°e s daty stanice:

path

z tabulky

/home/koas/

data_storages

nebo

C:\data),

pro specikaci adresá°e úloºi²t¥ (nap°.

device_files_directory

z tabulky

devices

(nap°.

koa1), teplice),

src, build.

Takto sloºená cesta je d·leºitá hned z n¥kolik d·vod·. Je nutné zajistit centrální úloºi²t¥ archivovaných diagnostických dat s externími systémy. Zárove¬ v²ak tyto systémy mohou být spu²t¥ny na r·zných strojích a dokonce i r·zných opera£ních systémech. Vzhledem k této skute£nosti je v cest¥ datového úloºi²t¥ práv¥ první £ást. Druhá £ást pak slouºí v p°ípad¥, kdy je centrální úloºi²t¥ rozd¥leno na více strojích. T°etí poloºka je pak relativní cesta k adresá°i

src místo pro uloºení archivovaných build místo pro ukládání pracovních

za°ízení. Poslední £ást cesty pak ur£uje v p°ípad¥ adresá°e diagnostických dat daného za°ízení a v p°ípad¥ adresá°e

soubor· daného za°ízení. Výsledná cesta k souboru s diagnostickými daty m·ºe vypadat nap°. takto:

/home/koas/koa1/teplice/src/arch_koa1_mereni_1/koa1_0000000001-20061120.

Na obrázku 8.2 je zobrazen list datových úloºi²´, které jsou v systému zaregistrovány. Jak je patrné z obrázku jsou úloºi²t¥ zobrazeny p°ehledn¥ a pomocí tohoto seznamu lze úloºi²t¥ p°idávat, mazat a m¥nit jim jejich parametry. Podrobnosti jsou uvedeny v uºivatelské p°íru£ce.

KAPITOLA 8.

IMPLEMENTACE

87

Obrázek 8.2: Ukázka seznamu datových úloºi²´

8.2.5 Jádro Ukázka kódu 8.4 zobrazuje kompletní implementaci fasády pro p°ístup k systému Rubicon. Tuto fasádu pouºívají p°ístupová rozhraní. V této verzi systému je implementováno gracké uºivatelské rozhraní pro p°ístup k systému, které je zaloºeno na Platform¥ NetBeans, resp. frameworku Java Swing. Nicmén¥ do budoucna m·ºe být implementován nap°íklad vzdálený p°ístup pomocí ssh a i v tomto p°ípad¥ bude pak vyuºita tato fasáda pro vlastní p°ístup do systému Rubicon. Ukázka kódu 8.4: Implementace EngineFacade

package c z . azd . z t e . vav . vpr12 . r u b i c o n . a p i . c o r e . e n g i n e ; import import import import

/∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗

/

c z . azd . z t e . vav . vpr12 . r u b i c o n . a p i . c o r e . e n g i n e . f i n a l i z a t i o n . F i n a l i z e r ; c z . azd . z t e . vav . vpr12 . r u b i c o n . a p i . c o r e . e n g i n e . s t a r t u p . S t a r t e r ; o r g . s l f 4 j . Logger ; org . s l f 4 j . LoggerFactory ;

Fasada pro pristup k systemu Rubcion . @author Jaroslav Bien @version 1.0 2008 −03 −28 @since 1.0

public f i n a l c l a s s EngineFacade {

/ ∗ navrhove vzory − Singleton , Fasada ∗ / / ∗ ∗ Logger tridy EngineFacade. ∗ / private s t a t i c f i n a l Logger LOGGER =

L o g g e r F a c t o r y . g e t L o g g e r ( EngineFacade . c l a s s ) ;

/ ∗ ∗ Instance EngineFacade. ∗ / private s t a t i c EngineFacade i n s t a n c e ;

/∗ ∗ ∗ Nedovolit nikomu v y t v o r i t instanci teto tridy . ∗/ private EngineFacade ( ) {

}

/∗ ∗ ∗ ∗ ∗ ∗

/

Vraci instanci EngineFacade. @return instanci EngineFacade

88

KAPITOLA 8.

IMPLEMENTACE

public s t a t i c synchronized EngineFacade g e t I n s t a n c e ( ) { i f ( i n s t a n c e == null ) { i n s t a n c e = new EngineFacade ( ) ; }

}

return i n s t a n c e ;

/∗ ∗ ∗ Spousti systemovou fasadu . ∗/ public void s t a r t ( ) {

EngineFacade .LOGGER. i n f o ( " s t a r t " ) ;

}

// NOI18N

Starter . getInstance ( ) . start ( ) ;

/∗ ∗ ∗ Zastavuje systemovou fasadu . ∗/ public void s t o p ( ) {

EngineFacade .LOGGER. i n f o ( " s t o p " ) ;

}

// NOI18N

F i n a l i z e r . getInstance ( ) . stop ( ) ;

}

8.2.6 P°ístupová rozhraní P°ístupová rozhraní ) p°edstavuje moºnost pro p°ístup do sys-

Podsystém p°ístupových rozhraní (

tému Rubicon. Jak jiº bylo zmín¥no v této verzi systému je implementováno gracké uºivatelské rozhraní pro p°ístup k systému, které je zaloºeno na Platform¥ NetBeans, resp. frameworku Java Swing. Nicmén¥ do budoucna m·ºe být implementován nap°íklad vzdálený p°ístup pomocí ssh a i v tomto p°ípad¥ bude pak vyuºita tato fasáda pro vlastní p°ístup do systému Rubicon. Na obrázku 8.3 je zobrazena ukázka p°ístupového rozhraní pro ovládání aplikace Rubicon. Z obrázku plyne, ºe okno má pouºitím frameworku Java Swing nativní vzhled hostitelského opera£ního systému a je tak pro uºivatele p°iv¥tivé, nebo´ pracuje v pro n¥j známém prost°edí. Zobrazené okno slouºí k ovládání systému a zobrazení stavu aplikace Rubicon. Dal²í detaily jsou uvedeny v uºivatelské p°íru£ce.

8.2.7 XUtilities Tento podsystém obsahuje dodate£né knihovny pot°ebné pro zaji²t¥ní funkcí systému. Jsou zde znovupouºitelné t°ídy a funkce.

Databáze Tento balí£ek obsahuje t°ídu pro p°ístup k rela£ním databázím. Pro p°ístup k databázím je vyuºita knihovna jDBI. Pouºití této knihovny je nezávislé na konkrétní databázi. Proto je moºné databázi i b¥hem provozu aplikace m¥nit.

KAPITOLA 8.

IMPLEMENTACE

89

Obrázek 8.3: Ukázka implementace p°ístupového rozhraní pro ovládání systému Rubicon

Soubory Balí£ek soubory obsahuje pomocné t°ídy pro práce se soubory uloºenými na pevném disku po£íta£e.

Datové typy Balí£ek datové typy obsahuje pomocné t°ídy, které implementují chyb¥jící pot°ebné funkce pro roz²í°ení datových typ· zabudovaných v jazyce Java. Jsou zde nap°. k dispozici t°ídy pro neznaménková £ísla (unsigned). Mimo n¥ jsou v balíku dal²í t°ídy, které výrazným zp·sobem roz²i°ují funk£nost datových typ· jazyka Java.

Matematické operátory V tomto balí£ku jsou k dispozici t°ídy pro snadný výpo£et matematických operací aritmetický pr·m¥r, maximum a minimum £ísel.

Síóvá komunikace Nejv¥t²í £ást podsystému utilit tvo°í balí£ek síóvá komunikace. Tento balí£ek obsahuje kompletní implementaci t°íd pro síóvou komunikaci pomocí soket·. K dispozici jsou tzv. jednoduché implementaci. Tyto t°ídy slouºí k jednorázové komunikaci, kdy po prvním pád· p°ipojení je komunikace pln¥ ukon£ena. K dispozici je v²ak i tzv. obnovitelná komunikace. P°i ní se po pádu p°ipojení po zadané dob¥ pokusí p°ipojení znovu navázat. Tento balí£ek je výhodný pro snadnou implementaci plugin·, které budou poskytovat komunikaci s externími systémy zaloºenou na spojení TCP/IP.

Ostatní Mimo vý²e uvedené balí£ky jsou v podsystému utilit dal²í balí£ky, které implementují dal²í £asto vyuºívané funkce v nejr·zn¥j²ích modulech £i pluginech aplikace.

90

KAPITOLA 8.

IMPLEMENTACE

8.3 Implementace systému Rubicon Ve fázi návrhu byla zmín¥na Platforma NetBeans, která tvo°í základ modulárního systému Rubicon. Platforma poskytuje ve²keré gracké prvky pro tvorbu kvalitního a robustního uºivatelského rozhraní, stejn¥ jako poskytuje °adu zmín¥ných knihoven pro práci v nejr·zn¥j²ích oblastech (pr·vodci, zobrazení stromové struktury objekt·, práce s databází). Funk£nost aplikace lze jednodu²e roz²í°it, a to bu¤ pluginy vytvo°enými vývojá°i NetBeans, nebo pluginy vytvo°enými komunitou NetBeans [12], p°íp. je moºné vlastní plugin navrhnout a realizovat (viz pluginy pro komunikace, zpracování diagnostických dat atd.). Ukázka rozhraní aplikace Rubicon je zobrazena na obrázku 8.4. Pro tvorbu hlavního okna a jeho vizuálních prvk· je pouºita Platforma NetBeans. V horní £ásti je hlavní menu aplikace, v levém panelu jsou pak rozbalovací listy s databázemi a datovými úloºi²ti. V pravé £ásti je pak panel pro ovládání aplikace. Dal²í £ásti a dopln¥ní funk£nosti okna je moºné vid¥t v uºivatelské p°íru£ce.

Obrázek 8.4: Hlavní okno aplikace Rubicon

Na obrázku 8.5 je pak zobrazeno okno pro nastavení aplikace Rubicon. Okno je implementováno podle návrhu v p°edchozí kapitole a pro jeho implementaci je vyuºita také Platforma NetBeans [10], stejn¥ jako pro jiné £ásti systému Rubicon. Jejich pouºitím se výrazn¥ sníºily nároky na vývoj uºivatelského rozhraní.

KAPITOLA 8.

IMPLEMENTACE

91

Obrázek 8.5: Okno nastavení aplikace Rubicon

8.4 Logování a stav systému Logování aplikací je d·leºité p°i ne£ekaných událostech, které mohou p°i jejich provozu nastat. V t¥chto p°ípadech se pak ukazuje d·leºitost logování £innosti. Pro zaji²t¥ní logování v systému Rubicon se pouºívá knihovna SLF4J. Pouºitím této knihovny je moºné zvolit konkrétní logovací systém aº p°i nasazení systému. Je moºné logovací systém dokonce i po nasazení m¥nit. Jako nální logovací systém pro systém Rubicon byl zvolen a pouºit logovací systém JDK 1.4. Na obrázku 8.6 je zobrazeno okno, které je zobrazeno pokud dojde k jakékoliv chyb¥ p°i b¥hu aplikace Rubicon. Takto je informován administrátor o p°ípadných chybách systému. Okno zobrazuje p°esný popis chyby spolu s výpisem zásobníku volání. Podrobn¥j²í zprávu je moºné pak najít práv¥ v logovacím souboru. Následuje ukázka logovacího souboru, kde jsou umíst¥ny ve²keré identika£ní údaje zaznamenané p°i startu aplikace, jako verze aplikace, hostitelský systém v£etn¥ verze, b¥hové prost°edí, adresá°e a aktivní moduly aplikace. V tomto logu jsou také zaznamenávány upozorn¥ní a chyby, které p°i b¥hu aplikace nastávají. Je tak moºné lokalizovat a ur£it p°esnou p°í£inu chyby b¥hu aplikace.

------------------------------------------------------------------------------>Log Session: Monday, April 28, 2008 08:23:04 AM CEST >System Info:

92

KAPITOLA 8.

IMPLEMENTACE

Obrázek 8.6: Ukázka okna p°i chyb¥

Product Version Operating System Java; VM; Vendor Runtime Java Home System Locale; Encoding Home Directory Current Directory User Directory Installation

= = = = = = = = = =

Rubicon 1.0 (Build 200804280800) Linux version 2.6.22.17-0.1-bigsmp running on i386 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22; Sun Microsystems Inc. Java(TM) SE Runtime Environment 1.6.0_06-b02 /usr/lib/jvm/java-1.6.0.u6-sun-1.6.0.u6/jre cs_CZ (rubicon); UTF-8 /home/koas /home/koas/app/rubicon/bin /home/koas/.rubicon/dev /home/koas/app/rubicon/rubicon /home/koas/app/rubicon/ide9 /home/koas/app/rubicon/platform8 Boot & Ext. Classpath = /usr/lib/jvm/java-1.6.0.u6-sun-1.6.0.u6/jre/lib/resources.jar:... Application Classpath = /home/koas/app/rubicon/platform8/lib/boot.jar:... Startup Classpath = /home/koas/app/rubicon/platform8/core/org-openide-filesystems.jar:... ------------------------------------------------------------------------------INFO [org.netbeans.core.startup.NbEvents]: Turning on modules: org.openide.util [7.12.0.1 1 200804211638] org.openide.modules [7.6 200804211638] org.apache.commons.collections.primitives/1 [1.0 20031105 080510] org.apache.commons.math/1 [1.2 20080218 080510] ... Pouºití logování v podsystémech aplikace je jednoduché a je vid¥t v ukázce 8.5 (ukázka kódu

DataStoragesReposity z podsystému DatováÚloºi²t¥. Ukázka ukazuje zp·sob p°ístupu k loggeru pomocí továrny LoggerFactory z knihovny SLF4J a zp·sob logování. T°ída Exceptions je pak odpov¥dná zobrazení okna s chybovou hlá²kou, které bylo uvedeno vý²e. je ze t°ídy

Ukázka kódu 8.5: Implementace logování

/ ∗ ∗ Logger tridy DataStoragesRepository . ∗ / private s t a t i c f i n a l Logger LOGGER =

LoggerFactory . getLogger ( DataStoragesRepository . class ) ;

/∗ ∗ ∗ Vytvori a vraci soubor pro datove u l o z i s t e s danym identifikatorem , nebo ∗ null , pokud soubor pro datove u l o z i s t e s danym ∗ identifikatorem neexistuje . ∗ ∗ @param id i d e n t i f i k a t o r datoveho u l o z i s t e ∗ @return soubor pro datove u l o z i s t e s danym identifikatorem , nebo ∗ null , pokud se soubor pro datove u l o z i s t e ∗ s danym identifikatorem nepodarilo v y t v o r i t ∗/

KAPITOLA 8.

93

IMPLEMENTACE

private F i l e O b j e c t c r e a t e F i l e O b j e c t F o r ( int i d ) { try { return D a t a S t o r a g e F i l e .DATA_STORAGES_DIRECTORY. c r e a t e D a t a ( this . getFileNameFor ( i d ) ) ; } catch ( IOException ex ) { }

E x c e p t i o n s . p r i n t S t a c k T r a c e ( ex ) ; D a t a S t o r a g e s R e p o s i t o r y .LOGGER. e r r o r ( this . getFileNameFor ( i d ) , ex ) ;

return null ;

}

8.5 Implementace pluginu Spider Plugin Spider je jedním z podsystém· systému Rubicon. Tento plugin má na starosti komunikaci s externí aplikací Spider. Komunikace s aplikací Spider probíhá po TCP/IP spojení, p°i£emº p°ená²eny jsou jednotlivé bajty, které tvo°í zprávu. Zpráva je ve formátu XML.

transport,

P°íklad této zprávy je zobrazen v ukázce 8.6. V ukázce je vid¥t hlavní tag zapouzd°uje celý p°enos. Tag

koa1

který

je pak dop°edn¥ kompatibilní a specikuje p°ípadn¥ p°í-

jemce zprávy a stejn¥ tak za°ízení. Dále vno°eným tagem je tag

command,

který reprezentuje

p°íkaz od systému Spider. V ukázce je to p°íkaz pro zpracování diagnostických dat (viz atribut

processDiagnosticData).

P°íkaz pak m·ºe obsahovat libovolný po£et parametr·, £ímº je za-

ji²t¥n p°enos r·zných zpráv mezi systémy. V tomto p°ípad¥ jsou p°ená²eny parametry dva, a to ozna£ení za°ízení a jeho identikátor. Ukázka kódu 8.6: P°íklad zprávy od externí aplikace Spider

<param name=" s p e c i f i c a t i o n ">AZD−KOA1 <param name=" i d ">11 Pro zprávy od aplikace Spider bylo navrºeno (viz p°edchozí kapitola) a vytvo°eno XML Schema. Pomocí tohoto schéma je zaji²t¥na validita zprávy. Schéma je k dispozici na p°iloºeném DVD v implementaci pluginu Spider v balí£ku zdroj· pluginu. Zprávy XML jsou zpracovávány knihovnou JDOM, která je taktéº vyuºita pro metodu XPath, pomocí které jsou získávány poºadované p°íkazy, které jsou dále sm¥rovány na p°íslu²né místo. Z ukázky 8.7 implementace p°íchozích zpráv od aplikace Spider ve t°íd¥

InInterpreter

je

vid¥t práce s knihovnou JDOM. Knihovna poskytuje ve²keré funkce pro na£ítání, ukládání, vytvá°ení dokument· XML. V zobrazené ukázce je vid¥t práce s dotazovacím jazykem XPath, který knihovna JDOM také poskytuje.

/∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗

/

Ukázka kódu 8.7: Implementace interpretace p°íchozích zpráv od systému Spider

Interpretuje prichozi zpravu od externi aplikace − XML dokument . @param document prichozi zprava − XML dokument @throws JDOMException pokud dojde k chybe behem zpracovani XML dokumentu

public void i n t e r p r e t ( Document document ) throws JDOMException {

94

KAPITOLA 8.

IMPLEMENTACE

i f ( document == null ) { return ;

}

// interpretovat prikazy v prichozi zprave this . interpretCommands ( document ) ;

}

/∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗

/

Interpretuje prikazy v prichozi zprave . @param document prichozi zprava − XML dokument @throws JDOMException pokud dojde k chybe behem zpracovani XML dokumentu

private void interpretCommands ( Document document ) throws JDOMException {

// uzly prikazu

L i s t commandsNodes = XPath . n e w I n s t a n c e ( " / t r a n s p o r t / ∗ /command" ) . s e l e c t N o d e s ( document ) ;

// i t e r a t o r uzlu prikazu

I t e r a t o r commandsNodesIterator = commandsNodes . i t e r a t o r ( ) ;

// p r o j i t vsechny uzly prikazu while ( commandsNodesIterator . hasNext ( ) ) // z i s k a t aktualni element prikaz

{

Element commandElement = ( Element ) commandsNodesIterator . next ( ) ;

// z i s k a t atribut typ aktualniho prikazu

A t t r i b u t e a t t r i b u t e T y p e = commandElement . g e t A t t r i b u t e ( " type " ) ;

// test , j e s t l i je typ aktualniho prikazu zpracovani diagnostickych // dat i f ( attributeType . getValue ( ) . equals ( " processDiagnosticData " ) ) { // typ aktualniho prikazu je zpracovani diagnostickych dat // interpretovat prikaz zpracovani diagnostickych dat }

}

/∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗

/

}

this . i n t e r p r e t C o m m a n d P r o c e s s D i a g n o s t i c D a t a ( commandElement ) ;

Interpretuje prikaz zpracovani diagnostickych dat . @param element element prikaz @throws JDOMException pokud dojde k chybe behem zpracovani XML dokumentu

private void i n t e r p r e t C o m m a n d P r o c e s s D i a g n o s t i c D a t a ( Element e l e m e n t ) throws JDOMException

{

// z i s k a t deti elementu prikaz ( parametry )

L i s t paramsElements = e l e m e n t . g e t C h i l d r e n ( ) ;

// i t e r a t o r deti elementu prikaz ( parametry )

I t e r a t o r p a r a m s E l e m e n t s I t e r a t o r = paramsElements . i t e r a t o r ( ) ;

KAPITOLA 8.

95

IMPLEMENTACE

// oznaceni zarizeni , u ktereho maji byt zpracovana diagnosticka data S t r i n g s p e c i f i c a t i o n = null ;

// i d e n t i f i k a t o r zarizeni , u ktereho maji byt zpracovana diagnosticka // data S t r i n g i d = null ;

// p r o j i t elementy parametry while ( p a r a m s E l e m e n t s I t e r a t o r . hasNext ( ) ) // z i s k a t aktualni element parametr

{

Element paramElement = ( Element ) p a r a m s E l e m e n t s I t e r a t o r . next ( ) ;

// z i s k a t atribut jmeno aktualniho parametru prikazu

A t t r i b u t e attributeName = paramElement . g e t A t t r i b u t e ( "name" ) ;

// test , j e s t l i je jmeno aktualniho parametru oznaceni zarizeni i f ( attributeName . g e t V a l u e ( ) . e q u a l s ( " s p e c i f i c a t i o n " ) ) { // jmeno aktualniho parametru je oznaceni zarizeni // zaznamenat oznaceni zarizeni }

s p e c i f i c a t i o n = paramElement . getText ( ) ;

// test , j e s t l i je jmeno aktualniho parametru i d e n t i f i k a t o r // zarizeni e l s e i f ( attributeName . g e t V a l u e ( ) . e q u a l s ( " i d " ) ) { // jmeno aktualniho parametru je i d e n t i f i k a t o r zarizeni // zaznamenat i d e n t i f i k a t o r zarizeni

}

}

i d = paramElement . getText ( ) ;

// presmerovat prichozi zpravu zpracovat diagnosticka data }

Sp ider Pro xy . g e t I n s t a n c e ( ) . r e d i r e c t I n c o m i n g ( Message .PROCESS_DIAGNOSTIC_DATA, new S t r i n g [ ] { s p e c i f i c a t i o n , i d } ) ;

Komunikace pluginu je implementována pomocí jiº zmín¥ného balí£ku síóvé komunikace z podsystému utilit. Vlastní p°ijetí zpráv pak mají na starosti t°ídy

SpiderHandlerOut.

T°ída

SpiderMessageFactory,

SpiderHandlerIn

a

která je navrºena podle návrhových vzor·

Singleton a Factory je odpov¥dná za tvorbu, resp. zpracování zpráv, které jsou odesílány, resp. sm¥rovány od sm¥rova£e komunikace

CommunicationRouter

z podsystému komunikace.

8.6 Implementace pluginu KOA1 pro zpracování diagnostických dat Plugin KOA1 je implementací produktu spole£nosti AD pro zpracování diagnostických dat kolejových obvod· KOA1 dle poºadavk· na diplomovou práci. Tento podsystém vychází z podsystému denujícím ºelezni£ní zabezpe£ovací za°ízení a zaji²úje konkrétní strategii zpracování diagnostických dat tohoto za°ízení. Vlastní implementace tohoto modulu je pom¥rn¥ rozsáhlá vzhledem k velkému mnoºství r·zných diagnostických dat. Pln¥ vychází ze zmín¥ného podsystému denujícím ºelezni£ní zabezpe£ovací za°ízení a také z popisu vlastního za°ízení KOA1 a jeho diagnostických dat.

96

KAPITOLA 8.

Nejd·leºit¥j²í t°ídou tohoto podsystému je t°ída

Koa1Factory.

IMPLEMENTACE

Tato t°ída je odpov¥dná za

tvorbu instancí za°ízení, s kterými pracuje správce za°ízení z modulu ºelezni£ních zabezpe£ovacích za°ízení. T°ída obsahuje velmi rozsáhlý a obtíºný algoritmus pro vytvo°ení a inicializaci za°ízení podle kongura£ních soubor· stanice, ve které je umíst¥no za°ízení KOA1. Implementace algoritmu pro tvorbu instancí za°ízení vychází z denice kongura£ních soubor·, podle kterých je spu²t¥na lokální diagnostika ve stanici. P°íklad t¥chto soubor· je k dispozici na p°iloºeném DVD. Existují dva druhy kongura£ních soubor·. Prvním druhem je kongurace pro nastavení ukládání diagnostických dat m¥°ení. Druhým druhem je kongurace pro nastavení diagnostiky stav· jednotek. Konkrétní implementace t°ídy s plným popisem algoritmu pro tvorbu instancí za°ízení dané stanice je na p°iloºeném DVD. Je rozsáhlá a není moºné ji zde celou uvád¥t. Zjednodu²en¥ lze °íci, ºe je zaloºena na sekven£ním pr·chodu kongura£ních soubor·, který je proveden vícenásobn¥, a jejich parsováním a hledáním daných terminálních symbol· jsou inicializovány konkrétní instance za°ízení, pro které existují diagnostická data. Plugin obsahuje velké mnoºství balí£k· a t°íd pro zpracování a vyhodnocení diagnostických dat. Pro popis konkrétních diagnostických dat a zp·sobu jejich uloºení je moºné prohlédnout dodate£nou dokumentaci umíst¥nou na p°iloºeném DVD. Diagnostická data jsou, jak jiº bylo zmín¥no, dvou druh· - m¥°ení a stavy. Vlastní data jsou pak uloºena zvlá²´ v binárních souborech. Tyto soubory v²ak obsahují binární reprezentaci datových typ·, které jsou k dispozici v programovacím jazyce C a C++. Obsahují i dal²í v¥ci, které k dispozici v programovacím jazyce Java nejsou v·bec k dispozici (struktury...). Z tohoto d·vodu je vytvo°en znovupouºitelný balí£ek datových typ· v podsystému utilit. Ty zjednodu²ují práci s vý²e uvedenými daty, které jsou v souborech s archivovanými diagnostickými daty. Vyhodnocení diagnostických dat je pak provád¥no sekven£ním pr·chodem binárních soubor·. V nich se vyhledávají poºadované údaje pro dané za°ízení. Zpracování soubor· je pak provád¥no ve t°íd¥

FileProcessingStrategyInterpreter,

která jak je jiº z názvu patrné je navrºena

dle návrhových vzor· Strategy a Interpreter. Denuje jen vlastní zpracování bajt· binárního souboru a základ je implementován ve znovupouºitelném balí£ku v podsystému utilit. V kapitole návrhu byl zmín¥n XML soubor s persistentn¥ uloºeným objektem za°ízení, který je umíst¥n v adresá°i, kde jsou umíst¥na archivovaná diagnostická data. Pro serializaci a deserializaci persistentních objekt· byla pouºita knihovna XStream. P°íklad pouºití této knihovny je uveden v ukázce 8.8. Uvedeny jsou metody pro serializaci i deserializaci objekt· z a do persistentního úloºi²t¥ objekt·. Ukázka kódu 8.8: Implementace serilizace a deserializace objekt·

/∗ ∗ ∗ {@inheritDoc} ∗/ @Override

public void s t o r e ( I D e v i c e d e v i c e ) { try {

// cesta k souboru pro ulozeni persistentniho objektu zarizeni

String serialDeviceFilePath = Koa1DataAccessManager . g e t I n s t a n c e ( ) . getKoa1CompositeDevicePersistenceFilePath ( device . getId ( ) ) ;

// fasada k XStream knihovne

XStream xs = new XStream ( ) ;

// s e r i a l i z o v a t zarizeni

S t r i n g s e r i a l i z e d D e v i c e = xs . toXML( d e v i c e ) ;

// zapsat serializovane zarizeni do souboru

KAPITOLA 8.

97

IMPLEMENTACE

F i l e U t i l s . w r i t e S t r i n g T o F i l e ( new F i l e ( s e r i a l D e v i c e F i l e P a t h ) , serializedDevice ); } catch ( IOException ex ) { }

}

/∗ ∗ ∗ {@inheritDoc} ∗/ @Override

public I D e v i c e r e s t o r e ( S t r i n g i d ) { try {

// cesta k souboru pro nacteni persistentniho objektu zarizeni String deserialDeviceFilePath = Koa1DataAccessManager . g e t I n s t a n c e ( ) . getKoa1CompositeDevicePersistenceFilePath ( id ) ;

// nacist serializovane zarizeni ze souboru String a = F i le U t i ls . readFileToString ( new F i l e ( d e s e r i a l D e v i c e F i l e P a t h ) ) ;

// fasada k XStream knihovne

XStream x = new XStream ( new DomDriver ( ) ) ;

// d e s e r i a l i z o v a t zarizeni

return ( CompositeDevice ) x . fromXML( a ) ; } catch ( IOException ex ) { }

return null ;

}

D·leºitou t°ídou pluginu je t°ída

Koa1DataAccessManager.

Tato t°ída je navrºena dle návrho-

vého vzoru DAO - Data Access Object. Smyslem tohoto návrhového vzoru je odstínit aplika£ní logiku domény od p°ístupu k dat·m. Ve²keré dotazy do databází a dal²ích p°ístup· k dat·m by m¥ly být umíst¥ny v tomto objektu. Ten pak je p°istupován jako Singleton a °e²í vlastní tok dat do a z pluginu. T°ída je implementována jako Singleton s vyuºitím mechanismu jazyka Java slabých referencí. Ty nám zajistí, ºe pokud ºádný objekt k dat·m p°istupovat nepot°ebuje, tak pak nemusí být DAO objekt v pam¥ti, jak by tomu bylo u klasické implementace Singletonu. Tento p°ístup k implementaci Singletonu je vyuºit i v jiných £ástech aplikace, proto je zde uveden p°íklad této pam¥óv¥ výhodné implementace v ukázce 8.9. Ukázka kódu 8.9: P°íklad implementace návrhového vzoru Singleton v Jav¥ pomocí referencí

/∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗

/

Spravce datoveho u l o z i s t e zarizeni KOA1. @author Jaroslav Bien @version 1.0 2008 −03 −05 @since 1.0

public f i n a l c l a s s Koa1DataAccessManager extends DeviceDataAccessManager {

/ ∗ navrhovy vzor − Singleton , Data Access Object ∗ / / ∗ ∗ Instance Koa1DataAccessManager. ∗ /

private s t a t i c R e f e r e n c e i n s t a n c e ;

98

KAPITOLA 8.

IMPLEMENTACE

/∗ ∗ ∗ Nedovolit nikomu v y t v o r i t instanci teto tridy . ∗/ private Koa1DataAccessManager ( ) { super ( ) ;

}

/∗ ∗ ∗ ∗ ∗ ∗

/

Vraci instanci Koa1DataAccessManager. @return instanci Koa1DataAccessManager

public s t a t i c synchronized Koa1DataAccessManager g e t I n s t a n c e ( ) { Koa1DataAccessManager kdam = ( ( i n s t a n c e == null ) ? null : i n s t a n c e . g e t ( ) ) ;

i f ( kdam == null ) { kdam = new Koa1DataAccessManager ( ) ; i n s t a n c e = new WeakReference(kdam ) ;

} }

return kdam ;

// . . . } T°ída T°ída

Koa1DataAccessManager deleguje poºadavky o p°ístup k dat·m na t°ídu DbOperations. DbOperations je Singleton a zast°e²uje vlastní p°ístup do databáze MySQL. Ukázka 8.10

kódu této t°ídy dává p°edstavu o pouºití knihovny jDBI pro p°ístup k databázi, který velice zjednodu²uje. P°ístup je stejný ke v²em typ·m databází, je tedy moºné databázi i v pr·b¥hu nasazení aplikace m¥nit.

/∗ ∗ ∗ ∗ ∗ ∗ ∗

/

Ukázka kódu 8.10: Implementace p°ístupu k databázi

Vraci cestu k datovemu u l o z i s t i s danym identifikatorem . @param dataStorageId i d e n t i f i k a t o r datoveho u l o z i s t e @return cestu k datovemu u l o z i s t i

public S t r i n g g e t D a t a S t o r a g e P a t h ( S t r i n g d a t a S t o r a g e I d ) {

// v y t v o r i t dotaz s e l e c t // SELECT path // FROM data_storages_table // WHERE id = : dataStorageId

S t r i n g s e l e c t Q u e r y = new S t r i n g B u i l d e r ( ) . append ( "SELECT " ) . append ( D a t a S t o r a g e s T a b l e .PATH_COLUMN_NAME) . append ( " FROM " ) . append ( Koa1Options . g e t I n s t a n c e ( ) . getDataStoragesTableName ( ) ) . append ( " WHERE " ) . append ( D a t a S t o r a g e s T a b l e .ID_COLUMN_NAME) . append ( " = : id " ) . toString ( ) ;

// o t e v r i t databazove pripojeni

Handle h a n d l e = this . openHandle ( ) ;

// provest dotaz

Query query = h a n d l e . c r e a t e Q u e r y ( s e l e c t Q u e r y )

KAPITOLA 8.

IMPLEMENTACE

99

. bind ( " i d " , I n t e g e r . v a l u e O f ( d a t a S t o r a g e I d ) ) . map( D a t a S t o r a g e O b j e c t . c l a s s ) ;

// z i s k a t objekt datove u l o z i s t e z dotazu

D a t a S t o r a g e O b j e c t d a t a S t o r a g e O b j e c t = query . f i r s t ( ) ;

// z a v r i t databazove pripojeni this . r e t u r n H a n d l e ( ) ;

// v r a t i t cestu k datovemu u l o z i s t i

return d a t a S t o r a g e O b j e c t . getPath ( ) ;

}

V kapitole návrh byly zmín¥ny nutné dodate£né informace k souboru s archivovanými diagnostickými daty, které se týkají p°edev²ím £asové synchronizace stanice a serveru KOAS. P°íklad moºné podoby metainformací prezentuje ukázka 8.11. Ukázka kódu 8.11: P°íklad XML dokumentu s metainformacemi

<m e t a i n f> 0 60000 V souborech s diagnostickými daty jsou umíst¥ny data sou£asn¥ od n¥kolika za°ízení. Nebylo by efektivní neustále pro kaºdý soubor s daty na£ítat a pomocí XPath knihovny JDOM tato data parsovat. Za tímto ú£elem je pouºit princip ukládání objekt· metainformací k danému souboru do vyrovnávací pam¥ti s omezenou velikostí. Strategie výb¥ru ob¥ti u cache je zvolena LRU (Least Recently Used). Cache s touto strategií je k dispozici v knihovn¥ ShiftOne Object Cache. Díky strategii LRU a omezené velikosti cache nebude po£et uchovávaných objekt· metainformací neustále r·st a zárove¬ je zaji²t¥na efektivnost v na£ítání t¥chto informací, které jsou sdíleny více za°ízeními najednou. P°íklad pouºití LRU cache z knihovny ShiftOne Object Cache je uveden v ukázce 8.12.

/∗ ∗ ∗ ∗ ∗ ∗ ∗

/

Ukázka kódu 8.12: Pouºití LRU objektové cache

Cache metainformaci k souborum s diagnostickymi daty . Cache pouziva s t r a t e g i i vyberu obeti LRU ( Least Recently Used ) , timeout p l a t n o s t i polozky v cache je dana konstantou {@link #CACHE_TIMEOUT CACHE_TIMEOUT} a v e l i k o s t cache je dana konstantou {@link #CACHE_SIZE CACHE_SIZE}.

private f i n a l Cache METAINFS_CACHE = new LruCacheFactory ( ) . newReapableCache ( this . g e t C l a s s ( ) . getName ( ) , this .CACHE_TIMEOUT, this . CACHE_SIZE ) ;

/∗ ∗ ∗ ∗ ∗ ∗ ∗

Parsuje XML soubor s metainformacemi k souboru s diagnostickymi daty . @param f i l e soubor s metadaty @return metainformace k souboru s diagnostickymi daty

100

∗ ∗ ∗ ∗

/

KAPITOLA 8.

IMPLEMENTACE

@throws FileProcessingException pokud se vyskytla chyba pri zpracovani souboru s metainformacemi k souboru s diagnostickymi daty

public synchronized M e t a i n f p a r s e ( F i l e f i l e ) throws F i l e P r o c e s s i n g E x c e p t i o n

{

// z i s k a t metainformace k souboru z cache metainformaci

M e t a i n f m e t a i n f = ( M e t a i n f ) this .METAINFS_CACHE. g e t O b j e c t ( f i l e ) ;

// test , j e s t l i jsou metainformace k souboru v cache metainformaci i f ( m e t a i n f == null ) { // metainformace k souboru v cache neni // v y t v o r i t metainformace m e t a i n f = this . c r e a t e M e t a i n f ( f i l e ) ;

// v l o z i t metainformace do cache }

this .METAINFS_CACHE. addObject ( f i l e , m e t a i n f ) ;

return m e t a i n f ;

}

Dal²í podrobnosti o implementaci a konkrétních pouºitých technologiích a postupech je moºné zhlédnout v dokumentaci pluginu nebo pln¥ dokumentovaném zdrojovém kódu tohoto pluginu, který je dostupný na p°iloºeném DVD.

8.7 Implementace pluginu KOA1 pro prezentaci diagnostických dat Plugin KOA1 pro prezentaci diagnostických dat za°ízení KOA1 byl implementován v programovacím jazyce PHP jako modul do systému Produk£ní Server AD. Implementace tohoto modulu odpovídá implementaci pluginu pro zpracování diagnostických dat za°ízení KOA1 uvedené vý²e. Jsou pouºity stejné principy a konvence, s tím rozdílem, ºe zaji²újí zobrazení vyhodnocení diagnostických dat ve webovském prohlíºe£i. Implementace je zaloºena na objektovém programování v PHP a prezentace dat na XHTML a CSS. Objekty op¥t závisí na modulu ºelezni£ních zabezpe£ovacích za°ízení, který je zde implementován podobn¥ jako v systému zpracování diagnostických dat. Pro p°ístup k databázi je zde vyuºit také DAO objekt, je zde továrna za°ízení atd. K dispozici jsou i r·zné utility, které nabízí systém PServer. Ty jsou v modulu prezentace diagnostických dat pln¥ vyuºívány. Implementace tohoto modulu PServeru je jednoduchá a bohat¥ dokumentována. K dispozici je na p°iloºeném DVD. Pro srovnání implementace DAO objektu v Jav¥ uvedené v p°edchozí £ásti je zde uvedena implementace DAO v programovacím jazyce PHP v ukázce 8.13. Ukázka kódu 8.13: P°íklad implementace návrhové vzoru Singleton v PHP

/∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗

Spravce datoveho u l o z i s t e zarizeni KOA1. @author Jaroslav Bien @version 1.0 2008 −04 −10 @since 1.0 @package device @subpackage da

KAPITOLA 8.

IMPLEMENTACE

101

/

∗ f i n a l c l a s s Koa1DataAccessManager e x t e n d s DataAccessManager { ∗ − ∗

/ navrhove vzory Singleton , Data Access Object / /∗ ∗ ∗ @var object Koa1DataAccessManager ∗ $instance Instance Koa1DataAccessManager. ∗/ private s tatic $instance ;

/∗ ∗ ∗ Nedovolit nikomu v y t v o r i t instanci teto tridy . ∗/

p r o t e c t e d f u n c t i o n __construct ( ) { p a r e n t : : __construct ( ) ; }

/∗ ∗

Vraci instanci Koa1DataAccessManager. @return object Koa1DataAccessManager instanci Koa1DataAccessManager

∗ ∗ ∗ ∗ ∗ public stat ic function getInstance () { i f ( s e l f : : $ i n s t a n c e == NULL) { s e l f : : $ i n s t a n c e = new Koa1DataAccessManager ( ) ; }

/

}

return s e l f : : $instance ;

/∗ ∗ ∗ Nedovolit nikomu v y t v o r i t kopii tohoto objektu . ∗/

p r i v a t e f u n c t i o n __clone ( ) { }

// . . . } ?> Ve fázi návrhu bylo navrºeno uºivatelské rozhraní modulu. Výsledná implementace, která tento návrh reektuje, je zobrazena na obrázku 8.7. Z obrázku je vid¥t hlavní stránku pluginu pro prezentaci diagnostických dat za°ízení KOA1, která zobrazuje seznam stanic, u nichº jsou k dispozici archivovaná a zpracovaná diagnostická data.

8.8 Statistiky a p°ehled implementace Architektura aplikace Rubicon byla navrhnuta modulárním zp·sobem. To by m¥lo umoºnit v budoucnu dal²í roz²i°ování aplikace a funk£nosti systému. V této £ásti budou popsány vlastní

102

KAPITOLA 8.

IMPLEMENTACE

Obrázek 8.7: Hlavního okno pluginu Rubicon aplikace PServer

moduly aplikace Rubicon a jejich funkce a komunikace s ostatními moduly aplikace.

8.8.1 Zpracování diagnostických dat Implementováno bylo 24 podsystému aplikace Rubicon pro zpracování diagnostických dat na Platform¥ NetBeans. Aplikaci Rubicon pak tvo°í 3 pluginy (1 produkt, 2 komunikátory). Celkem aplikace obsahuje cca 750 ve°ejných t°íd v cca 420 balí£cích. Po£et °ádk· aplikace Rubicon dosáhl po£tu cca 67 000. Krom¥ zmín¥ného po£tu t°íd je v programu v²ak i velké mnoºství tzv. anonymních vnit°ních t°íd. Z d·vodu velkého mnoºství t°íd a balí£k· budou v následující £ásti popsány jen základní moduly a t°ídy (rozhraní) v nich. Podrobný popis je moºné najít na p°iloºeném DVD, kde je dokumentace v²ech modul·, balí£ku a t°íd vytvo°ena programem Javadoc. Popis modul· je se°azen dle abecedního po°adí názv· daných modul·. V²echny balí£ky a t°ídy jsou umíst¥ny v základním balí£ku celého projektu Rubicon

cz.azd.zte.vav.vpr12.rubicon.

Balí£ky a názvy t°íd, jakoºto i názvy funkcí, prom¥nných a parametr· se drºí konvencí pro programování v programovacím jazyku Java [3] vydané spole£ností Sun Microsystems, Inc. Stejné konvence jsou pak dodrºovány pro zápis zdrojového kódu v£etn¥ dokumenta£ních komentá°·. P°ehled modul· aplikace Rubicon (viz také obrázek 8.8):

•

Communication API and SPI Modul obsahuje API pro komunikaci - sm¥rova£ komunikace

CommunicationRouter

denuje rozhraní (SPI) pro implementaci komunikace s externími systémy -

CommunicatorProxy. •

Core API

a

KAPITOLA 8.

103

IMPLEMENTACE

Obrázek 8.8: P°ehled implementace projektu Rubicon

Modul denuje fasádu pro p°ístup k systému Rubicon z p°ístupových rozhraní -

EngineFacade. •

Stejn¥ tak je odpov¥dný za inicializaci a °ízení b¥hu jádra aplikace.

DataStorages API Modul obsahuje denici datového úloºi²t¥ -

DataStorage. Modul poskytuje API pro p°íDataStoragesManager. Modul je od-

stup k datovým úloºi²tím pomocí fasády správce

pov¥dný za ukládání a mazání denic úloºi²´ na pevném disku po£íta£e. Modul také poskytuje gracké pr·vodce pro p°idání nových úloºi²´ do systému.

•

EntryInterfaces API Modul obsahuje denici p°ístupových rozhraní pro ovládání a p°ístup k systému Rubicon.

•

KOA1 Plugin pro zpracování archivovaných diagnostických dat. Nejrozsáhlej²í podsystému systému Rubicon. Implementuje rozhraní z modulu Railway Interlocking Systems API and SPI.

•

PServer Plugin komunikátor a denice pro zástupce aplikace PServer.

•

Railway Interlocking Systems API and SPI Modul s denicí ºelezni£ních zabezpe£ovacích za°ízení a technické diagnostiky. Sou£ástí modulu je správce za°ízení

DevicesManager.

Modul denuje rozhraní

Device

a

DeviceProvider, které implementují jednotlivé pluginy pro zpracování diagnostických dat (nap°. plugin KOA1). Mimo tato rozhraní jsou tu dal²í, které denují diagnostická data, kategorie, vyhodnocení a dal²í, která souvisí práv¥ s technickou diagnostikou.

•

Spider Plugin komunikátor pro komunikaci s externí aplikací Spider.

104

•

KAPITOLA 8.

IMPLEMENTACE

XUtilities API and SPI Kolekce utilit a znovupouºitelných komponent pro vyuºití ve v²ech modulech a pluginech aplikace.

•

XUtilities API - Apache Commons BeanUtils, Apache Commons Codec, Apache Commons Collections, Apache Commons Email, Apache Commons IO, Apache Commons Lang, Apache Commons Math, Apache Commons Net, Apache Commons Primitives, jDBI, JDOM, RCache, ShiftOne Object Cache, SLF4J, XStream Knihovny znovupouºitelných komponent.

8.8.2 Prezentace diagnostických dat Implementovány byly 3 podsystémy aplikace pro prezentaci diagnostických dat v rámci aplikace PServer. Celkem aplikace obsahuje cca 130 ve°ejných t°íd v cca 112 balí£cích. Po£et °ádk· aplikace Rubicon dosáhl po£tu cca 18 000. Z d·vodu velkého mnoºství t°íd a balí£k· budou v následující £ásti popsány jen základní moduly a t°ídy (rozhraní) v nich. Podrobný popis je moºné najít na p°iloºeném DVD, kde je dokumentace v²ech modul·, balí£ku a t°íd vytvo°ena programem phpDocumentor. Popis modul· je se°azen dle abecedního po°adí názv· daných modul·. V²echny balí£ky a t°ídy

components. Balí£ek resources obmodules obsahuje pluginy aplikace PSer-

jsou umíst¥ny v základním balí£ku celého projektu PServer sahuje kolekci znovupouºitelných komponent. Balí£ek

ver. Balí£ky a názvy t°íd, jakoºto i názvy funkcí, prom¥nných a parametr· se drºí konvencí pro programování v programovacím jazyku PHP. Stejné konvence jsou pak dodrºovány pro zápis zdrojového kódu v£etn¥ dokumenta£ních komentá°·. P°ehled modul· aplikace PServer (viz také obrázek 8.9):

•

ModWebKoa1Diagnostics Plugin pro prezentaci vyhodnocených diagnostických dat za°ízení KOA1. T°ídy implementují obecná rozhraní z modulu ResIndRailwayInterlockingSystems a ResSysTemplateModWebDevicesDiagnostics.

•

ResIndRailwayInterlockingSystems Modul s denicí ºelezni£ních zabezpe£ovacích za°ízení a technické diagnostiky. Denuje jsou rozhraní, která denují diagnostická data, kategorie, vyhodnocení a dal²í, která souvisí práv¥ s technickou diagnostikou.

•

ResSysTemplateModWebDevicesDiagnostics Modul s denicí plugin· poskytujících prezentaci vyhodnocení diagnostických dat.

8.9 Shrnutí V této kapitole byla probrána implementace aplikace Rubicon a plugin· pro komunikaci s externí aplikací Spider a pro zpracování diagnostických dat za°ízení KOA1. Nebyl uveden úplný vý£et v²ech t°íd a balí£k·, modul· a funk£nosti v jednotlivých £ástech systému, ale pouze toho, £ehoº d·leºitost je nezbytná pro chod systému. Pro podrobn¥j²í informace o implementaci lze pouºít dokumentaci vytvo°enou programem Javadoc, která je p°ítomna na p°iloºeném médiu. Dále je moºné také procházet zdrojové kódy ve²kerých modul· a t°íd aplikace Rubicon, ale i pluginu pro PServer. Zdrojové kódy jsou také na zmín¥ném médiu p°ítomny. Mimo vý£et balí£k· a t°íd pouºitých pro implementaci této diplomové práce byly popsány datové formáty pro uloºení perzistentních informací, pro komunikaci s externí aplikací a také popsán

KAPITOLA 8.

IMPLEMENTACE

105

Obrázek 8.9: P°ehled implementace projektu PServer

p°ístup do databází. Byla taktéº popsána síóvá komunikace. Popsáno bylo i pouºití externích knihoven v£etn¥ ukázek kódu jejich implementace. Byly popsány i ve²keré náleºitosti týkající se této diplomové práce, jako je °e²ení celé aplikace, zobrazování, ovládání, rozd¥lení do jednotlivých podsystém· apod. V záv¥ru byly pak uvedeny a popsány implementace plugin· poºadovaných pro funk£nost diplomové práce spolu s ukázkami implementovaného grackého uºivatelského rozhraní. Implementace byla podle poºadavk· provedena standardními technikami pro programování v programovacím jazyce Java, PHP, na Platform¥ NetBeans. Byly pouºity kódovací i dokumenta£ní konvence, techniky objektov¥ orientovaného programování. Implementován byl modulární systém pro zpracování a prezentaci diagnostických dat, který byl navrºen podle moderních postup·, návrhových vzor· GoF, vzor· p°i°azení odpov¥dností (GRASP) a postaven na Platform¥ NetBeans. Komponentov¥ orientovaný software je pak robustní a jednodu²e roz²í°itelný o zpracování diagnostických dat nových za°ízení £i o komunikaci s dal²ími externími systémy.

106

KAPITOLA 8.

IMPLEMENTACE

KAPITOLA 9.

TESTOVÁNÍ

107

9 Testování 9.1 Úvod V této kapitole bude popsáno testování systému Rubicon. Celkov¥ b¥hem vývoje aplikace a po jejím dokon£ení probíhaly 4 druhy test·. Prvním typem testování bylo testování jednotkové. Následovalo testování integra£ní a valida£ní. Nakonec byly provedeny systémové testy.

9.2 Testovací prost°edí Testování probíhalo na po£íta£i s následujícími parametry:

•

procesor - Intel Pentium M 1,73 GHz,

•

opera£ní pam¥´ - 1 GB,

•

gracká karta - nVidia GeForce Go 7300,

•

pevný disk - 100 GB Serial ATA, 7200 ot./min,

•

opera£ní systém - openSUSE 10.3 (kernel 2.6.22.17, KDE 3.5.7),

•

JRE - 1.6.0_06,

•

MySQL - 5.0.51a,

•

Apache Web Server - 2.2.4-70.4,

•

PHP - 5.2.5-17.13.

9.3 Testovací diagnostická data Testy byly provád¥ny na diagnostických datech za°ízení KOA1 z ºelezni£ní stanice Teplice v echách. Stanice obsahuje celkem 8 r·zných jednotek TCR s r·znými mnoºstvími kanál·. Na p°iloºeném DVD jsou k dispozici diagnostická data spolu s nezbytnými kongura£ními soubory. Stejn¥ tak je k dispozici dokumentace a plán test·.

9.4 Jednotkové testování Úvod Jednotkové testy probíhaly ve dvou fázích. V první fázi probíhalo tzv. white-box testování a ve druhé fázi probíhalo tzv. black-box testování.

White-box testování White-box testování (strukturální testování) se zam¥°uje na testování, zda v²echny vnit°ní komponenty správn¥ fungují. Toto testování probíhalo jiº b¥hem samotného vývoje aplikace pomocí xUnit testovacích framework· JUnit [7] a PHPUnit [15]. Pro kaºdou nov¥ vzniklou funkcionalitu programu byla vytvo°ena mnoºina testovacích dat. D·raz byl kladen p°edev²ím na kontrolu v²ech cykl· a °ídících struktur. Kaºdá °ídící struktura byla provedena ve v²ech moºných v¥tvích. Dále byly testovány v²echny moºné kombinace podmínek v °ídících strukturách.

108

KAPITOLA 9.

TESTOVÁNÍ

Black-box testování Ve druhé fázi jednotkových test· probíhalo black-box testování (funkcionální testování), které se zam¥°ilo na správné fungování v²ech navrºených funkcí programu (ale ne vºdy muselo postihnout v²echny podrobnosti implementace). Toto testování probíhalo také jiº p°i samotném vývoji produktu. Testy se provád¥li vºdy po vytvo°ení nového funk£ního bodu a p°i jeho integraci do jiº existující aplikace. Testování se p°edev²ím zam¥°ilo na nestandardní £innosti spojené s daným funk£ním bodem a na kontrolu vstupních dat. V rámci nestandardního chování se nap°. testovalo ne°ízení se pokyny udanými aplikací a jejich vliv na zobrazení a chování ostatních £ástí aplikace nebo pokus o p°ipojení k serveru na adrese, na které server neb¥ºel, apod. Kontrola vstup· se pak zabývala zejména hrani£ními hodnotami vstup·. V tomto p°ípad¥ se jednalo o prázdné vstupy nebo o hodnoty mimo rozsah povolených vstup·. Dále se také testovala odolnost aplikace nap°. na p°íli² dlouhé vstupy nebo ²patný formát vstupních dat, £i místo poºadovaných £ísel byl zadán text apod. Dále byla kv·li bezpe£nosti systému ov¥°ena ²patná síóvá komunikace, jako nap°. p°enos nesprávných bajt·, £as obsahuje text apod.

Výsledky Jednotkové testy prob¥hly v po°ádku a nebyly nalezeny ºádné závaºné chyby. Chyby odhalené b¥hem testování byly opraveny. V jednotlivých modulech aplikace Rubicon se nevyskytují chyby závaºného charakteru, které by m¥li vliv na funk£nost aplikace pro zpracování a prezentaci diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení.

9.5 Integra£ní testování Úvod K integra£nímu testování byl vyuºit princip inkrementální integrace, neboli metoda zdola nahoru. Postupn¥ byly zapojovány a testovány jednotlivé moduly a spojení jednotlivých modul·. Aº do doby, kdy byl zapojen a funk£ní celý systém.

Testování Toto testování prob¥hlo black-box a £áste£n¥ white box metodami a pokrývá hlavní cesty °ízení. Jednotlivé moduly aplikace Rubicon byli spojovány do v¥t²ích funk£ních celk·, byla pro n¥ vytvo°ena testovací data a testováno jejich chování. Testovalo se nap°. volání metod, okrajové hodnoty, volání funkcí z uºivatelského rozhraní, p°edání dat do prezenta£ní vrstvy. V neposlední °ad¥ byly otestovány chybové události v programu, jejich prezentace uºivateli a reakce a dopad na jednotku slou£ených modul·.

Výsledky Integra£ní testy byly provedeny s ve²kerými moduly aplikace Rubicon a nebyly shledány ºádné závaºné chyby mající vliv na funkci. P°ípadné nalezené chyby byly odstran¥ny a systém spojených modul· byl znova otestován z d·vodu zji²t¥ní, zda nebyla zavle£ena opravou chyba nová. Spojení modul· aplikace fungovalo v po°ádku a integra£ní testy skon£ili pozitivním výsledkem.

9.6 Valida£ní testování Úvod Valida£ní testování probíhalo ve dvou fázích. První fáze bylo alfa testování. Ve druhé fázi pak prob¥hlo beta testování. Valida£ní testování slouºí k ov¥°ení, ºe program vyhovuje poºadavk·m

KAPITOLA 9.

109

TESTOVÁNÍ

na funkci, chování a provedení. Testování je provedeno metodou black-box testování.

Alfa testování Základem alfa testování je, ºe zákazník dostane produkt do uºívání v prost°edí dodavatele a testy probíhají za dohledu vývojá°·. Testy probíhaly na pracovi²ti VPR12 ve spole£nosti AD Praha s.r.o. Byla provedena obsluha celého systému pro zpracování i pro prezentaci diagnostických dat. U aplikace zpracování diagnostických dat se testy zam¥°ili na dv¥ problematiky. První bylo správné fungování GUI aplikace a druhou pak práce uºivatel· s aplikací. B¥hem testování GUI se testovalo nap°. zm¥ny nastavení, manipulace s uzly, instalace plugin·. Testována byla také komunikace s externí aplikací Spider.

Beta testování Rozdíl beta testování oproti alfa testování je v tom, ºe produkt je testován u zákazníka bez p°ítomnosti osob, které se ú£astnily na vývoji systému. Zákazník pak provádí testy a zapisuje p°ípadné chyby a posílá je v £asových intervalech vývojovému týmu. Tyto testy byly provád¥ny jak vedoucím práce, tak vývojá°em modul·, kte°í testovali celý systém. P°ípadné chyby byly zaznamenány a oznámeny na dal²í sch·zce nebo prost°ednictvím ur£ité formy elektronické komunikace. Obsah testování byl totoºný s obsahem a formou testování v rámci alfa testování.

Výsledky Valida£ní testy probíhaly i po celou dobu vývoje aplikace. Ve²keré nalezené chyby byly dokumentovány a oznámeny tv·rci modul·. Nakonec byli v²echny nalezené chyby odstran¥ny a otestovány proti zavle£ení jiné chyby vzniklé opravou. Valida£ní testy vyhov¥li a aplikace byla shledána bezchybnou a vyhovující poºadavk·m na funkci, chování a provedení.

9.7 Systémové testování Úvod Systémový test je záv¥re£ný test systému. Test je proveden v kombinaci s ostatními systémový prvky, jako je hardware, uºivatelé, databáze atd. Systémové testování je série test· prov¥°ující stav a funk£nost celého systému. Systémové testování tvo°í t°i podskupiny test·, a to testování obnovy, bezpe£nostní testování a testování zát¥ºové.

Testování obnovy Testování obnovy (Recovery Testing) je systémové testování ov¥°ující, ºe poruchy byly °ádn¥ o²et°eny v p°edepsaném £ase. Pokud je o²et°ení automatické, vyhodnocuje se reinicializace, mechanismus checkpoint·, obnova dat, restart. Je-li provád¥no manuáln¥, ov¥°uje se, zda time to repair byl v limitu.

mean

U tohoto testování se testovalo chování aplikace Rubicon p°i poruchách komunikace s externími systémy. Byla nap°íklad ov¥°ena reakce systému na chybu síóvé komunikace s externím systémem a dal²í. Kontrolována byla reakce systému, ale i oznámení chyby uºivateli a zp·sob o²et°ení chyby. Podobn¥ byla testována chybná komunikace s databází apod. Testování prob¥hlo s kladným výsledkem. Nebyly zji²t¥ny ºádné chyby. Reakce systému a oznámení vzniklých chyb, které byly um¥le simulovány, byly správné a v p°edepsaném £ase zobrazeny

110

KAPITOLA 9.

TESTOVÁNÍ

uºivateli.

Bezpe£nostní testování Bezpe£nostní testování (Security Testing) je systémové testování, které testuje odolnost systému proti útoku hacker·. Tester supluje roli hackera a snaºí se proniknout do systému. Má-li dost £asu a zdroj·, tak se mu to poda°í. Úlohou systémového návrhá°e je pak, aby cena proniknutí do systému byla v¥t²í neº cena informací, které lze získat. P°i tomto typu testování bylo ov¥°eno, jak systém reaguje nap°íklad na nesmyslné nebo zám¥rn¥ ²patné informace v nastavení, datech apod. Byla také testována odolnost aplikace p°i p°enosu ²patných p°íkaz· po síti. Dále bylo také nap°íklad otestováno, jak aplikace reaguje na ²patná nastavení v souboru s nastavením aplikace. Bylo nap°íklad také p°i p°ihla²ování k prezentaci zadáno neexistující jméno a heslo, existující jméno a ²patné heslo apod. Testy byly úsp¥²né a aplikace je z hlediska bezpe£nostního testování v po°ádku. Systém správn¥ reaguje na v²echny aspekty bezpe£nostních útok· na program. V²echny moºnosti jsou zabezpe£eny a p°ípadn¥ selhání je uºivateli oznámeno.

Zát¥ºové testování P°i zát¥ºovém testování (Stress Testing) je cílem prov¥°it program v abnormální situaci (kvantita, frekvence nebo obsah). Cílem je zjistit, jak dlouho m·ºu systém namáhat, neº padne. P°íkladem je vstupní data zv¥t²it o °ád, neº je dovoleno a vyhodnotit chování vstupní funkce, nebo poºadovat maximální pam¥´ £i jiné zdroje £i zp·sobení problému v opera£ním systému atd. Variantou tohoto testování je sensitivity testing, které se snaºí objevit kombinace dat (v rámci platného omezení), které mohou zp·sobit nestabilitu £i nesprávnou funkci. Existuje i typ zát¥ºového testování nazývaný performance testing, které se pouºívá pro zapouzd°ené systémy nebo systémy reálného £asu. P°i tomto testu bylo otestováno, jak systém reaguje na velké mnoºství poºadavk· od externích systém·. Pak bylo téº otestováno, jak systém reaguje na výpadek pam¥ti nebo její nedostatek. Byl také nap°íklad proveden test zahlcení diskového prostoru, z kterého byl program spu²t¥n apod.

Výsledky Systémové testování prob¥hlo úsp¥²n¥ a nebyly nalezeny ºádné výkonnostní nebo bezpe£nostní problémy. Reakce na p°ípadné chyby vzniklé za provozu jsou bezpe£né a jsou oznámeny uºivateli systému. Systém na n¥ pak reaguje náleºitým zp·sobem.

9.8 Zhodnocení testování Byly provedeny £ty°i typy test·, které m¥li za úkol ov¥°it správnost implementace systému. Bylo za nutné ov¥°it jak bezpe£nost, tak i výkonnost systému. V²echny testy prob¥hly úsp¥²n¥. Pokud byla nalezena chyba, museli být testy provedeny znovu, kv·li ov¥°ení, jestli nebyla do aplikace opravou zanesena chyba jiná. Záv¥re£né testy v²ak byly úsp¥²né a systém je v po°ádku. Testy prob¥hly na dvou r·zných opera£ních systémech a výsledky jsou stejné a systém vyhovuje a je moºné ho bezpe£n¥ vyuºívat.

KAPITOLA 10.

NASAZENÍ

111

10 Nasazení V této kapitole bude popsáno nasazení systému Rubicon. K popisu nasazení systému je vyuºit diagram nasazení (deployment diagram). Tento diagram ukazuje nejen fyzický hardware, na n¥mº bude softwarový systém spu²t¥n, ale i zp·sob, jímº je software na tomto hardwaru nasazen. Diagram nasazení mapuje architekturu softwaru vytvo°enou ve fázi návrhu a implementace na fyzickou architekturu systému, na n¥mº bude software spou²t¥n. Na obrázku 10.1 je vid¥t diagram konkrétního nasazení systému Rubicon ve spole£nosti AD Praha s.r.o.

Obrázek 10.1: Diagram nasazení systému Rubicon

Z tohoto diagramu je patrné umíst¥ní aplikace Rubicon na server KOAS. Server obsahuje centrální úloºi²t¥ archivovaných diagnostických dat, které vyuºívá jak systém Rubicon, tak aplikace Spider. Na serveru je spu²t¥n webový server Apache. Nejd·leºit¥j²í aplikací na serveru je Produk£ní server AD. V rámci této aplikace je za£len¥n i modul pro prezentaci vyhodnocení diagnostických dat. V prost°edí Javy pak b¥ºí vlastní aplikace Rubicon, ale stejn¥ ta i systém Spider. Tyto aplikace mezi sebou komunikují pomocí TCP/IP. Sou£ástí serveru je kone£n¥ i rela£ní databáze MySQL, kterou vyuºívají v²echny t°i aplikace na serveru hostované. Na diagramu je také vid¥t p°ístup uºivatel· k serveru. Ti p°istupují pomocí protokolu http ze svých po£íta£· pomocí webovského prohlíºe£e k aplikaci PServer, která se pak stará o napln¥ní cíl· jednotlivých uºivatel·. Administrátor má p°ímý p°ístup k serveru v jeho umíst¥ní ve spole£nosti, stejn¥ tak m·ºe pracovat s aplikací PServer jako ostatní uºivatelé.

112

KAPITOLA 10.

NASAZENÍ

Popsaný zp·sob nasazení ve spole£nosti bude zaji²óvat zpracování diagnostických dat z kolejových obvod· KOA1. Díky architektu°e aplikace a její losoi je v²ak moºné v budoucnu systém jednodu²e roz²í°it o nový modul pro zpracování diagnostických dat z nových za°ízení.

KAPITOLA 11.

ZHODNOCENÍ PRÁCE A DALÍ POKRAOVÁNÍ

113

11 Zhodnocení práce a dal²í pokra£ování Diplomová práce m¥la zadáno navrhnout efektivní zp·sob pro zpracování diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení. V poºadavcích na diplomovou práci byl také návrh na prezentaci t¥chto vyhodnocení diagnostických dat. Ov¥°ení funk£nosti návrhu pak m¥lo být provedeno implementací vyhodnocení a prezentace diagnostických dat za°ízení KOA1 spole£nosti AD Praha s.r.o. Systém pro vyhodnocování a prezentaci diagnostických dat byl navrºen a implementován jako modulární. Celá aplikace pro zpracování diagnostických dat byla postavena na Platform¥ NetBeans a systém pro prezentaci dat byl vybudován zase na platform¥ PServer. Ob¥ aplikace byly pln¥ otestovány a byla tak ov¥°ena jejich poºadovaná funk£nost. Diagnostická data jsou vyhodnocována statisticky. Ve velkém mnoºství diagnostických dat se v²ak m·ºe vyskytovat ur£itá sekvence indikací technických stav· objekt·, která m·ºe n¥co o za°ízení vypovídat. Tyto sekvence v²ak statistickým zpracováním nelze postihnout. A práv¥ zde je moºné pokra£ování v projektu. Nabízí se moºnost pouºití dolování dat (data mining) - analytické metodologie získávání netriviálních skrytých a potenciáln¥ uºite£ných informací z dat. Cílem je pr·b¥ºné shromaº¤ování co nejv¥t²ího po£tu dat a následné analýzy, které mohou pomoci objevit trendy, na základ¥ nichº lze £init d·leºitá marketingová a obchodní rozhodnutí, p°edvídat poruchy a stavy za°ízení apod. Dal²í moºností pokra£ování v projektu diplomové práce je zpracování diagnostických dat podle poºadavk· uºivatele. V sou£asných poºadavcích na projekt je denováno zpracování diagnostických dat po jejich získání z úloºi²t¥ v prost°edí za°ízení a následném informováním externím systémem Spider, který má za úkol tato data získávat a archivovat. Pokra£ování by umoºnilo získání a zpracování dat podle poºadavk· uºivatel·, nikoliv pouhé prohlíºení vyhodnocených dat. e²ení tohoto úkolu spo£ívá v ur£itém provázání (komunikaci) Produk£ního serveru s aplikací Rubicon nebo Spider. Bylo by také nutné zajistit pravidelné získávání diagnostických dat, aby netrvalo zpracování výsledku neúm¥rn¥ dlouho z d·vodu kopírování dat z prost°edí za°ízení. Tato diplomová práce, jejímº tématem je návrh efektivního zp·sobu pro zpracování a prezentaci diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení, splnila svoje zadání. Navrºená architektura dovoluje snadnou roz²í°itelnost pro zpracování a prezentaci diagnostických dat od nových za°ízení. Modulární aplikace je robustní a poskytuje efektivní zp·sob pro analýzu diagnostických dat. Realizováno bylo vyhodnocení a prezentace diagnostických dat za°ízení KOA1. Zadání diplomové práce bylo tedy spln¥no.

114

KAPITOLA 11.

ZHODNOCENÍ PRÁCE A DALÍ POKRAOVÁNÍ

KAPITOLA 12.

ZÁVR

115

12 Záv¥r Výsledkem této diplomové práce je systém pro efektivní zpracování a prezentaci diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení. Tento systém bude nasazen a pouºíván na vývojovém pracovi²ti VPR12 ve spole£nosti AD Praha s.r.o. Navrºený a implementovaný modulární systém poskytuje robustní architekturu, která je snadno roz²í°itelná a dovoluje tvorbu nových plugin· pro roz²í°ení funk£nosti systému. Modulární architektura také umoº¬uje jednodu²²í správu, stejn¥ jako vývoj nových modul·, snadnou aktualizaci atd. Velkým p°ínosem modulární architektury je také fakt, ºe lze snadno implementovat nové podsystémy pro zpracování diagnostických dat z nových za°ízení a vývoj lze provád¥t v odd¥lených týmech. Celý systém pro zpracování a prezentaci diagnostických dat je sou£ástí projektu pracovi²t¥ VPR12, který si klade za cíl vybudovat centrální úloºi²t¥ pro diagnostiku vyvíjených za°ízení, místo pro obsluºné aplikace a dokumentaci. Vlastní projekt byl pak navrhován a spravován podle metodiky vývoje software Unied Process. Pro návrh systému byly vyuºity návrhové vzory pro uleh£ení práce a vy²²í efektivitu aplikace, nap°íklad Singleton pro instance vyskytující se pouze v jediné instanci v celém systému. Dále byl vyuºit nap°íklad návrhový vzor MVC (Model-View-Controller), který usnadnil ovládání a zobrazení grackých prvk· rozhraní systému. V analýze byly také vyuºity techniky p°i°azení odpov¥dnosti pomocí GRASP vzor·, techniky objektov¥ orientovaného programování atd. Celá aplikace pro zpracování diagnostických dat je naprogramovaná v programovacím jazyce Java, coº umoº¬uje jednoduchou p°enositelnost mezi r·znými platformami a opera£ními systémy. Dává v²ak systému velkou efektivitu a bezpe£nost. Aplikace pak b¥ºí nad Platformou NetBeans, která poskytuje stabilní a výkonnou architekturu pro po£íta£ové systémy. Pro kongura£ní soubory a p°enos zpráv mezi externími systémy jsou vyuºity informace uloºené ve formátu XML, coº umoº¬uje jednoduché roz²í°ení, kontrolu syntaxe a informací v nich obsaºených, £ímº se také zvy²uje bezpe£nost systému. V neposlední °ad¥ je nutné zmínit validaci t¥chto XML dokument· pomocí navrºených XML schémat. Aplikace pro prezentaci diagnostických dat je implementována v programovacím jazyce PHP. Prezenta£ní vrstva je pak realizována v jazyce XHTML s vyuºitím CSS. Systém pro prezentaci diagnostických dat je také modulární. Jsou v n¥m vyuºity stejné principy jako u systému pro zpracování diagnostických dat. Aplikace pro prezentaci diagnostických dat je pak sou£ástí Produk£ního Serveru AD, který je hlavní platformou zmín¥ného projektu na pracovi²ti VPR12 ve spole£nosti AD. Nedílnou sou£ásti projektu je vytvo°ení uºivatelské p°íru£ky, kompletní dokumentace podle metodiky UP, dokumentace zdrojových kódu a model systému v jazyce UML. To zaji²úje moºnost zapojení nových pracovník· do projektu, který se bude v budoucnu pouºívat, ale hlavn¥ také dále vyvíjet a roz²i°ovat. Krom¥ zmín¥ných systém· pro zpracování a prezentaci diagnostických dat byla v rámci projektu vyvinuta celá °ada znovupouºitelných komponent (nap°. roz²í°ení jazyka Java o neznaménkové datové typy, utility pro práci s textovými i binárními soubory, framework pro snadn¥j²í komunikaci po síti). Správnost návrhu a realizace efektivního systému byla ov¥°ena implementací podsystému pro zpracování a prezentaci diagnostických dat za°ízení KOA1 od spole£nosti AD Praha s.r.o. Realizace a následné testy potvrdily správnost a efektivnost návrhu, stejn¥ tak jako snadnou roz²í°itelnost a spravovatelnost systému. Zadání diplomové práce bylo spln¥no a projekt s názvem Rubicon byl úsp¥²n¥ realizován. Práce na projektu v²ak touto diplomovou prací nekon£í. Systém je nastaven pro dal²í roz²i°ování, které bude spo£ívat ve vyuºití analytické metodologie získávání netriviálních skrytých a potenciáln¥ uºite£ných informací z dat, tzv. dolování dat (data mining). Pouºití této techniky m·ºe pomoci

116

KAPITOLA 12.

ZÁVR

objevit trendy, na základ¥ nichº lze £init d·leºitá rozhodnutí, p°edvídat poruchy a stavy za°ízení apod. Zárove¬ budou také vytvo°eny moduly pro zpracování diagnostických dat z nových za°ízení. Zku²enosti získané b¥hem tvorby a implementace diplomové práce se dají vyuºít p°i návrhu dal²ích projekt· podobného typu, ale i jiných síóvých a modulárních aplikací. Cennou zku²eností je také návrh a realizace univerzálního projektu, který musí být snadno roz²í°itelný a spravovatelný. V neposlední °ad¥ musí být zmín¥no seznámení se s vnitrní strukturou softwarové a hardwarové £ásti kolejových obvod· KOA1, na jejichº diagnostických datech byla efektivnost návrhu univerzálního systému pro zpracování a prezentaci diagnostických dat ov¥°ena.

KAPITOLA 13.

117

LITERATURA

13 Literatura [1] Apache Commons. [2] AD Praha s.r.o.

http://commons.apache.org/.

http://www.azd.cz/.

[3] Code Conventions for the Java Programming Language.

http://java.sun.com/docs/codeconv/. [4] Enterprise Architect. [5] jDBI.

http://jdbi.org/.

[6] JDOM. [7] JUnit.

http://www.sparxsystems.com.au/products/ea.html.

http://www.jdom.org/.

http://www.junit.org/.

[8] MySQL.

http://www.mysql.org/. http://www.netbeans.org/.

[9] NetBeans.

[10] NetBeans Platform.

http://platform.netbeans.org/.

[11] NetBeans Platform Certied Training.

http://edu.netbeans.org/courses/nbplatform-certified-training/. [12] NetBeans Plugin Portal.

http://plugins.netbeans.org/.

[13] Objekty - Objektová analýza, návrh a programování. [14] phpMyAdmin.

http://www.phpmyadmin.net/.

http://www.phpunit.de/.

[15] PHPUnit.

[16] Produk£ní Server AD Praha. [17] RCache.

http://objekty.vse.cz/.

http://pserver.azd.cz/.

http://rcache.sourceforge.net/.

[18] ShiftOne Object Cache.

http://jocache.sourceforge.net/.

[19] Simple Logging Facade for Java.

http://www.slf4j.org/.

[20] The Java Language: An Overview.

http://java.sun.com/docs/overviews/java/java-overview-1.html. [21] The Source for Java Developers. [22] Wikipedia. [23] XStream.

http://java.sun.com/.

http://cs.wikipedia.org/wiki.

http://xstream.codehaus.org/.

[24] A. Cockburn.

Use Cases Jak efektivn¥ modelovat aplikace.

[25] E. Gamma, R. Helm, R. Johnson, J. Vlisside.

Object-Oriented Software.

[26] A. Faran.

Design Patterns: Elements of Reusable

Addison Wesley, 1995.

elezni£ní zabezpe£ovací systemy, 2007.

studijní materiály.

Computer Press, Brno, 2002.

Fakulta dopravní, VUT v Praze,

118

KAPITOLA 13.

[27] J. Arlow, Ila Neustadt.

LITERATURA

UML 2 a unikovaný proces vývoje aplikací. Computer Press, Brno,

2007. [28] J. Jan²ta. Remote 96 - univerzální diagnostický systém zabezpe£ovacích za°ízení. Technical report, AK Signal Brno. [29] J. Jan²ta. Záznamové za°ízení BlackBox. Technical report, AK Signal Brno. [30] M. Kreidl, J. Petr, J. Novák, P. Houfek, P. Doubek.

Diagnostické systémy.

Vydavatelství

VUT, Praha, 2001. [31] R. Prokopec. Lokální diagnostický systém LDS. Technical report, AD Praha s.r.o. [32] T. Boudreau, J. Tulach, G. Wielenga.

Platform.

Rich Client Programming: Plugging into the NetBeans

Prentice Hall, Upper Saddle River, New Jersey, USA, 2007.

D ZTP 6/2000-SZ - Základní technické poºadavky pro diagnostiku ºelezni£ních zabezpe£ovacích za°ízení.

[33] D a.s.

DODATEK A.

SEZNAM POUITÝCH ZKRATEK

A Seznam pouºitých zkratek API

Application Programming Interface

AVR

AVR procesor

BSD

Berkeley Software Distribution

CAT

Computer Aided Testing

CDP

Centrální diagnostické pracovi²t¥

CSS D

Cascading Style Sheets eské dráhy, a.s.

DLA

Diagnostic Local Access

DLS

Diagnostic Local Server

DOZ

Dálkov¥ ovládané zabezpe£ovací za°ízení

ESA

Elektrnonické stav¥dlo AD

FIFO

First In First Out

FTP

File Transfer Protocol

GPL

GNU General Public License

GoF

Gang Of Four

GRASP GUI

General Responsibility Assignment Software Patterns

Gracké uºivatelské rozhraní

HTML HTPP I18N IDE

Hypertext Markup Language Hypertext Transfer Protocol

Internationalization Integrated Development Environemnt

IMAP JAR

Internet Message Access Protocol

Java Archive

Java ME

Java Platform, MicroEdition

Java SE

Java Platform, Standard Edition

Java EE

Java Platform, Enterprise Edition

JDK JIT

Java Development Kit

Just In Time Compilation

JOP

Jednotné obsluºné pracovi²t¥

JRE

Java Runtime Envoronment

119

120

DODATEK A.

JVM KO

Java Virtual Machine

Kolejový obvod

KOA1

Kolejový obvod AD

KOAS

KOA Server

LAMP

Linux, Apache, MySQL, PHP

LDAP

Lightweight Directory Access Protocol

LDS

Lokální diagnostický systém

LFU

Least Frequently Used

LRU

Least Recently Used

MTBF

Mean Time Between Failures

MTTF

Mean Time To Failure

NTP

Network Time Protocol

ODBC OOP PC


Open Database Connectivity

objektov¥ orientované programování

Personal Computer

PHP

PHP: Hypertext Preprocessor

POP3

Post Oce Protocol version 3

PServer PZZ

Produk£ní Server AD Praha

P°ejezdové zabezpe£ovací za°ízení

RAM

Random Access Memory

SDP

Software Development Process

SE

St°edoevropský £as

SEP

Software Engineering Process

SMTP

Simple Mail Transfer Protocol

SNMP

Simple Network Management Protocol

SpZZ SQL

Spádovi²tní zabezpe£ovací za°ízení Structured Query Language

SPI

Service Provider Interface

SZZ

Stani£ní zabezpe£ovací za°ízení

TCP/IP TCR

Transmission Control Protocol/Internet Protocol

Track Receivers

DODATEK A.

TZZ

Traóvé zabezpe£ovací za°ízení

UML UP


Unied Modeling Language

Unied Process

USDP UTC

Unied Software Development Process

Coordinated Universal Time

VZZ

Vlaková zabezpe£ovací za°ízení

WAN

World Area Network

WML

Wireless Markup Language

XHTML XMI

Extensible Hypertext Markup Language

XML Metadata Interchange

XML

Extensible Markup Language

XSD

XML Schema Denition

ZPR

Zero Power RAM

ZZ

Zabezpe£ovací zarízení

ST

elezni£ní stanice

ZS

elezni£ní zabezpe£ovací systém

121

122

DODATEK A.


DODATEK B.

123

UIVATELSKÁ PÍRUKA

B Uºivatelská p°íru£ka B.1 Úvod Rubicon slouºí pro zpracování a prezentaci diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení. Systém je tvo°en dv¥ma £ástmi - pro zpracování a pro prezentaci diagnostických dat. Uºivatelská p°íru£ka sestává z následujících £ástí: 1. Instalace 2. Rubicon 3. PServer 4. Systémové poºadavky

B.2 Instalace Aplikace jsou dodávány v archivu

zip. Pro instalaci aplikace pro zpracování diagnostických dat

sta£í rozbalit obsah archivu do libovolného adresá°e na pevném disku. Aplikace se spustí pomocí souboru

rubicon,

který je umíst¥n v adresá°i

bin

(pro platformu Windows i Linux).

Aplikace pro prezentaci diagnostických dat je instalována administrátorem Produk£ního Serveru AD. Pro p°ístup k této aplikaci se vyuºívá webovský prohlíºe£ (viz dále).

B.3 Rubicon B.3.1 Úvod Rubicon slouºí pro zpracování diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení. Aplikace má gracké uºivatelské rozhraní odpovídající platform¥, na které je spu²t¥na.

B.3.2 Spu²t¥ní aplikace P°i startu systému je zobrazen uvítací dialog (neboli SplashScreen) aplikace Rubicon. Na tomto dialogu jsou zobrazovány £innosti, které provádí platforma p°i spou²t¥ní aplikace (na£ítání modul·, nahrávání modul·...). Spolu s výpisem £innosti je zobrazován i ukazatel pr·b¥hu nahrávání, který ukazuje stav spou²t¥ní aplikace. P°íklad uvítacího dialogu aplikace Rubicon je zobrazen na obrázku B.1. Pokud dojde p°i nahrávání modul· do pam¥ti k chyb¥ (nenalezený modul aplikace, ²patná vstupní data modulu), je zobrazena chybová hlá²ka. Chybová hlá²ka informuje uºivatele o vzniklé chyb¥.

B.3.3 Hlavní okno Hlavní okno aplikace Rubicon je zobrazeno na obrázku B.2. V horní £ásti je b¥ºné hlavní ovládací menu aplikace. Po hlavním menu je toolbar, který nap°íklad standardn¥ obsahuje ukazatel velikosti pam¥ti, kterou vyuºívá aplikace Rubicon. V levém panelu jsou stromy s r·znými nastaveními a informacemi (defaultn¥ seznam databázových p°ipojení a datových úloºi²´). V pravé £ásti je pak panel pro ovládání systému pro zpracování diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení.

124

DODATEK B.

UIVATELSKÁ PÍRUKA

Obrázek B.1: Uvítací dialog aplikace Rubicon

B.3.4 P°idání databázového p°ipojení Pro p°idání nového databázového p°ipojení se v levém panelu hlavního okna rozbalí strom databází a stiskem pravého tla£ítka se zvolí moºnost pro p°idání nového databázového p°ipojení. V dialogu, který je zobrazen na obrázku B.3, se zadají poºadované údaje a stiskem tla£ítka

OK se

naváºe spojení s databází. P°i dal²ích spu²t¥ních aplikace není nutné tuto sekvenci opakovat, ale p°ipojení bude k dispozici v rozbaleném stromu, který vypisuje v²echna registrovaná databázová p°ipojení. Pro komunikaci s dal²ími databázemi lze jednodu²e p°idat i ovlada£ p°íslu²né databáze, registrovaná databázová p°ipojení lze ru²it, k dispozici je i zabudovaný editor pro prohlíºení a úpravu databáze (viz obrázek B.4).

B.3.5 P°idání datového úloºi²t¥ Pro p°idání datového úloºi²t¥ se v levém panelu hlavního okna rozbalí strom datových úloºi²´ a stiskem pravého tla£ítka se zvolí moºnost p°idání nového datového úloºi²t¥. V pr·vodci, který je zobrazen na obrázku , se zadají poºadované vlastnosti a stiskem tla£ítka dokon£it se úloºi²t¥ v systému zaregistruje. V pr·vodci lze zadat pouze smysluplné údaje, které v p°ípad¥ nesprávnosti znemoºní dokon£ení pr·vodce (platné jméno, jedine£ný identikátor...). Na zobrazeném p°íkladu dialogu je v dolní £ásti pr·vodce zobrazena chybová hlá²ka informující o problému. U datových úloºi²´ lze m¥nit jejich vlastnosti pomocí pravého tla£ítka, které klikne na uzel daného úloºi²t¥ ve stromu úloºi²´. Samoz°ejm¥ úloºi²t¥ lze také mazat a podobn¥ jako u databázových p°ipojení i zde z·stávají datová úloºi²t¥ registrována i do p°í²tího spu²t¥ní aplikace. Na obrázku B.6 je pak zobrazeno hlavní okno, ve kterém jsou vid¥t p°idaná databázová p°ipojení a datová úloºi²t¥.

B.3.6 Nastavení aplikace Zm¥na nastavení aplikace se provádí v dialogu nastavení, který lze vyvolat z hlavního menu a poloºky nástroje -> nastavení. P°íklad dialogu pro nastavení aplikace je zobrazen na obrázku B.7.

DODATEK B.

125

UIVATELSKÁ PÍRUKA

Obrázek B.2: Hlavní okno aplikace Rubicon

B.3.7 Instalace plugin· Instalace plugin· výrazn¥ roz²i°uje funk£nost aplikace. Nové pluginy lze získat od vývojá°· NetBeans IDE (viz stránky IDE), od komunity NetBeans nebo vytvo°it vlastní plugin. Seznam nainstalovaných modul· a plugin· lze vyvolat v menu nástroje -> pluginy. P°íklad seznamu plugin· je zobrazen na obrázku B.8. V tomto listu lze prohlíºet informace o pluginech, odinstalovat jednotlivé pluginy atd.

Instalace staºeného pluginu Plugin staºený nap°íklad ze stránek NetBeans lze nainstalovat na kart¥ staºených plugin· a stiskem tla£ítka p°idat. Po volb¥ souboru v dialogu, který je zobrazen na obrázku B.9, se po odsouhlasení licen£ních podmínek pluginu plugin nainstaluje. Pr·b¥h instalace zobrazuje pr·vodce, který je zobrazen na obrázku B.10.

Instalace pluginu z internetu Nejpohodln¥j²í zp·sob instalace plugin· je jejich automatické stahování z internetu. Tímto zp·sobem je zaji²t¥na i kontrola aktualizací plugin·, zobrazení v²ech dostupných plugin· atd. Pro získání p°ístupu k plugin·m na internetu je t°eba zaregistrovat nové aktualiza£ní centrum na kart¥ nastavení dialogu plugin·. Po stisku tla£ítka p°idat zadáme poºadované údaje a p°idáme aktualiza£ní centrum (viz obrázek B.11). Nyní se jiº v kart¥ dostupn¥ pluginy zobrazí dal²í pluginy. K dispozici jsou nap°íklad aktualiza£ní centrum

Plugin Portal NetBeans,

adrese

http://plugins.netbeans.org/nbpluginportal/files/nbms/ pluginportal-update-center.xml, a

Plugin Portal NetBeans Development, který je dostupný na adrese

který se nachází na

126

DODATEK B.

UIVATELSKÁ PÍRUKA

Obrázek B.3: P°idání databázového p°ipojení v aplikaci Rubicon

Obrázek B.4: Práce s databází v aplikaci Rubicon

http://deadlock.netbeans.org/hudson/job/javadoc-nbms/lastSuccessfulBuild/ artifact/nbbuild/nbms/updates.xml.gz. Pluginy ze seznamu dostupných plugin· instalujeme jednodu²e zatrhnutím p°íslu²ných plugin· v seznamu a stiskem tla£ítka instalovat (viz obrázek B.12). Stejn¥ jako u instalace staºených plugin· se objeví i zde pr·vodce, který provede uºivatele procesem instalace. Po odsouhlasení podmínek a staºení pluginu se plugin nainstaluje.

Restart po instalaci P°i instalaci n¥kterých plugin· je vyºadován restart aplikace. Tuto skute£nost se uºivatel dozví z pr·vodce instalací, p°ípadn¥ pomocí bublinové nápov¥dy v pravém dolním rohu hlavního okna aplikace (viz obrázek B.13). Po restartu aplikace se pak projeví nový nainstalovaný modul (viz nap°. obrázek B.14, kde byl nainstalován modul pro zobrazení systémových vlastností b¥hového prost°edí Javy).

DODATEK B.

UIVATELSKÁ PÍRUKA

127

Obrázek B.5: Pr·vodce p°idáním datového úloºi²t¥ v aplikaci Rubicon

B.3.8 Pr·b¥h zpracování diagnostických dat P°i zpracování diagnostických dat ºelezni£ních zabezpe£ovacích za°ízení je v pravém dolním rohu aplikace zobrazen indikátor pr·b¥hu zpracování. Po stisku tohoto indikátoru se rozbalí vysouvací okno se v²emi indikátory aktuáln¥ zpracovávaných diagnostických dat (viz obrázek B.15). Indikátor zobrazuje pr·b¥h zpracování v procentech, ale stejn¥ tak zobrazuje identikátor za°ízení spolu se jmény aktuálních diagnostických dat a kategorie, které zpracovává, v£etn¥ fáze zpracování, ve které se nachází.

B.3.9 Ostatní Dal²í informace pro obsluhu aplikace Rubicon lze získat z online nápov¥dy aplikace, která je dostupná v menu nápov¥dy, nebo stiskem klávesy F1.

B.4 PServer B.4.1 Úvod PServer slouºí pro prezentaci diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení. Aplikace je dostupná p°es uºivatel·v webovský prohlíºe£.

B.4.2 Spu²t¥ní aplikace Aplikaci PServer pro prohlíºení vyhodnocení diagnostických dat lze spustit v libovolném webovském prohlíºe£i na internetové adrese

http://pserver.azd.cz.

B.4.3 Hlavní okno V levé £ásti hlavního okna se nachází hlavní menu aplikace. V horní £ásti je pak zobrazena naviga£ní informace, jméno p°ihlá²eného uºivatele a aktuální datum a £as. Nejv¥t²í £ást hlavního okna v²ak tvo°í plocha, n¥které jsou zobrazeny informace z jednotlivých modul· podle poºadavk· uºivatele. Hlavní okno je vid¥t na obrázcích v následujících sekcích.

128

DODATEK B.

UIVATELSKÁ PÍRUKA

Obrázek B.6: Pohled na p°idaná datová úloºi²t¥ a databáze v aplikaci Rubicon

B.4.4 Prohlíºení za°ízení Za°ízení lze prohlíºet po zvolení poloºky p°íslu²ných za°ízení v levém menu hlavního okna aplikace. Po zvolení poloºky se zobrazí okno, které je na obrázku B.16. Zde je zobrazen seznam za°ízení. Po zvolení konkrétního za°ízení lze jiº prohlíºet vyhodnocení diagnostických dat daného za°ízení.

B.4.5 Prohlíºení vyhodnocení diagnostických dat Diagnostická data za°ízení se prohlíºí jeho zvolením (viz p°edchozí odstavce). P°íklad prohlíºení diagnostických dat je zobrazen na obrázku B.17. Horní záloºky okna odpovídají aktuáln¥ prohlíºenému za°ízení. Dále jsou zobrazeny záloºky s diagnostickými daty daného za°ízení. Kaºdá diagnostická data mohou mít libovolné mnoºství kategorií, jejichº záloºky jsou zobrazeny pod záloºkami diagnostických dat (kategorie aktuáln¥ zvolených diagnostických dat). Kaºdá kategorie potom má n¥kolik relací, jejichº záloºky jsou op¥t zobrazeny pod záloºkami kategorií daných diagnostických dat, tedy na nejniº²í úrovni. Pokud je záloºka podbarvena £ern¥, pak je aktuáln¥ vybrána. V opa£ném p°ípad¥ lze na záloºku pomocí my²i kliknout a dojde k p°esm¥rování na danou poloºku (jiná diagnostická data, jiná kategorie, jiná relace, seznam za°ízení...). Mezi jednotlivými vyhodnoceními diagnostických dat lze procházet pomocí zmín¥ných záloºek. Po zvolení konkrétní záloºky diagnostických dat, kategorie a relace je zobrazeno vyhodnocení diagnostických dat dané kategorie a relace pro zvolené za°ízení. P°íklad zobrazení vyhodnocení je zobrazen na obrázku B.17 a na obrázku B.18.

B.5 Systémové poºadavky B.5.1 Rubicon Aplikace Rubicon pro zpracování diagnostických dat je multiplatformní, proto je moºné ji spou²t¥t na libovolné platform¥ po£íta£· a libovolném opera£ním systému bez nutnosti instalace jiné verze aplikace, pokud je k dispozici b¥hové prost°edí Java. Doporu£ená hardwarová a softwarová kongurace po£íta£e:

DODATEK B.

UIVATELSKÁ PÍRUKA

129

Obrázek B.7: Dialog nastavení aplikace Rubicon

•

procesor - procesor srovnatelný s Intel Pentium IV 1,8 GHz

•

opera£ní pam¥´ - 1 GB

•

monitor - barevný monitor, min. 640 x 480 pixel·

•

pevný disk - 100 MB (aplikace + JRE)

•

síóvá karta - 100 Mbit

•

opera£ní systém - libovolný

•

Java - 1.6 nebo nov¥j²í

B.5.2 PServer Aplikace PServer, na které je modul pro prezentaci diagnostických dat, je p°ístupná p°es libovolný webovský prohlíºe£, proto je moºné k ní p°istupovat z libovolné platformy po£íta£· a libovolného opera£ního systému.

•

monitor - barevný monitor, min. 640 x 480 pixel·

•

síóvá karta - 100 Mbit

•

opera£ní systém - libovolný

•

webovský prohlíºe£ - libovolný s podporou XHTML a CSS

B.6 Záv¥r V této uºivatelské p°íru£ce bylo popsáno ovládání aplikací Rubicon a PServer, které slouºí ke zpracování a prezentaci diagnostických dat z trvale provozovaných ºelezni£ních zabezpe£ovacích za°ízení.

130

DODATEK B.

UIVATELSKÁ PÍRUKA

Obrázek B.8: Seznam nainstalovaných plugin· aplikace Rubicon

Obrázek B.9: Dialog instalace staºeného pluginu aplikace Rubicon

DODATEK B.

UIVATELSKÁ PÍRUKA

Obrázek B.10: Pr·vodce instalací pluginu aplikace Rubicon

Obrázek B.11: Pr·vodce p°idáním aktualiza£ního centra plugin· aplikace Rubicon

131

132

DODATEK B.

UIVATELSKÁ PÍRUKA

Obrázek B.12: Seznam dostupných plugin· aplikace Rubicon

Obrázek B.13: Bublinová nápov¥da restartu aplikace Rubicon

DODATEK B.

UIVATELSKÁ PÍRUKA

Obrázek B.14: Spu²t¥ní pluginu po restartu aplikace Rubicon

Obrázek B.15: Pr·b¥h zpracování diagnostických dat v aplikaci Rubicon

133

134

DODATEK B.

UIVATELSKÁ PÍRUKA

Obrázek B.16: Seznam za°ízení v aplikaci PServer

Obrázek B.17: Zobrazení vyhodnocení diagnostických dat v aplikaci PServer

DODATEK B.

UIVATELSKÁ PÍRUKA

Obrázek B.18: Zobrazení vyhodnocení diagnostických dat v aplikaci PServer

135

136

DODATEK B.

UIVATELSKÁ PÍRUKA

DODATEK C.

OBSAH PILOENÉHO DVD

C Obsah p°iloºeného DVD adresá° obsahující text diplomové práce

AT X adresá° obsahující text diplomové práce ve formátu L E adresá° obsahující zdroje pouºité v textu diplomové práce

text diplomové práce ve formátu PDF adresá° obsahující projekt diplomové práce adresá° obsahující vytvo°ené aplikace adresá° obsahující spustitelné aplikace adresá° obsahující aplikace pro instalaci

adresá° obsahující ukázková diagnostická data KOA1 adresá° obsahující dokumentaci projektu diplomové práce adresá° obsahující uºivatelskou p°íri£ku

adresá° obsahující model diplomové práce ve formátu XMI adresá° obsahující dal²í dokumenty adresá° obsahující phpdoc dokumentaci aplikace PServer adresá° obsahující Javadoc dokumentaci aplikace Rubicon

adresá° obsahující dokumenty dle Unied Process adresá° obsahující zdrojové kódy aplikací abstrakt v anglickém jazyce abstrakt v £eském jazyce výchozí stránka projektu soubor obsahující postup instalace aplikací

soubor obsahující popis obsahu DVD a instalace aplikací

137

Vyhodnocování a prezentace diagnostických dat z trvale provozovaných ºelezni ních zabezpe ovacích za ízení. Bc. Jaroslav Bien

Recommend Documents