integracijski vzorci in protivzorci · vzorci predstavljajo mehanizem za učenje in reševanje...

Darko Poberţnik

INTEGRACIJSKI VZORCI IN PROTIVZORCI

Diplomsko delo

Maribor, september 2009

I

Diplomsko delo univerzitetnega študijskega programa Računalništvo in informatika, smer

Informatika


Študent: Darko Poberţnik

Študijski program: UN ŠP Računalništvo in informatika

Smer: Informatika

Mentor: red. prof. dr. Marjan Heričko

Lektorica: Jasna Ledinek, prof. slovenščine in zgodovine

Maribor, september 2009

III

ZAHVALA

Zahvaljujem se mentorju red. prof. dr. Marjanu

Heričku za pomoč in vodenje pri opravljanju

diplomskega dela. Zahvala tudi lektorici za hitro in

strokovno delo. Posebna zahvala velja staršem, ki so

mi omogočili študij, in obema bratoma, ki sta mi

kazala pravo pot.

IV


Ključne besede: Integracijski vzorci, protivzorci, integracija sistema, sporočilni sistemi,

sporočilni kanal

UDK: (659.2:004):004.4(043.2)

Povzetek

Diplomsko delo podaja predstavitev in uporabo posameznih vzorcev ter protivzorcev, ki se

uporabljajo pri integraciji informacijskih sistemov. Prav tako podrobneje spoznamo načine

integracij sistemov z uporabo integracijskih vzorcev. Na drugi strani je pomembna tudi

ozaveščenost o tem, kakšni načini niso primerni za integracijo, zato so opisani tudi

najpogostejši protivzorci. Pri tem je poudarek predvsem na pomenu in umestitvi vzorcev,

tipih, nivojih in klasifikacijah vzorcev. V praktičnem delu je predstavljena integracija spletne

trgovine in sistema ERP ter analizirana uporaba določenih vzorcev.

V

INTEGRATION PATTERNS AND ANTIPATTERNS

Key words: Integration patterns, antipatterns, system integration, messaging system, messaging channel

UDK: (659.2:004):004.4(043.2)

Abstract

This diploma covers mainly the presentation and use of some patterns and antipatterns,

that are used throughout the integration of different information systems. There is also a

detailed decription of all the methods, that are used for the system integration with the use of

integration patterns. Things, that are pointed out here are: review of the meaning, placement

of the patterns, types, levels and classifications. It is also good to know, what methods are not

that good for integration. That is why also the most common antipatterns are described. The

practical part covers the introduction of the integration of an existing web application (web

store) and an existing ERP system. Also the use of some patterns in this integration is

analysed.

VI

VSEBINA

1. UVOD ..........................................................................................................................................1

2. VZORCI INTEGRACIJE ...................................................................................................................2

2.1 Uvod ...................................................................................................................................2

2.2 Integracija sistemov .............................................................................................................2

2.3 Tipi integracij .......................................................................................................................3

2.4 Seznam vzorcev ...................................................................................................................5

2.5 Stili integracije .....................................................................................................................7

2.6 Sporočilni sistemi (angl. Messaging systems) .....................................................................10

2.6.1 Sporočilni kanal (angl. Message channel) ...................................................................10

2.6.2 Sporočilo (angl. Message) ..........................................................................................11

2.6.3 Cevi in filtri (angl. Pipes and filters) ............................................................................11

2.6.4 Usmerjevalnik sporočil (angl. Message router) ...........................................................12

2.6.5 Prevajalnik sporočil (angl. Message translator) ...........................................................13

2.6.6 Končna točka sporočil (angl. Message Endpoint) ........................................................13

2.7 Sporočilni kanali (angl. Message channels).........................................................................14

2.7.1 Odločitev o izbiri sporočilnega kanala ........................................................................15

2.7.2 Kanal tipa točka do točke (angl. Point-to-Point channel).............................................16

2.7.3 Kanal objavi - naroči (angl. Publish-Subscribe channel) ...............................................16

2.7.4 Kanal podatkovnega tipa (angl. Datatype channel) .....................................................17

2.7.5 Kanal neveljavnih sporočil (angl. Invalid message channel).........................................18

2.7.6 Kanal mrtvih sporočil (angl. Dead letter channel) .......................................................19

2.7.7 Zagotovljena dostava (angl. Guaranted delivery) ........................................................19

2.7.8 Kanalni adapter (angl. Channel adapter) ....................................................................20

2.8 Konstrukcija sporočil (angl. Message construction) ............................................................21

2.8.1 Ukazno sporočilo (angl. Command message)..............................................................22

2.8.2 Zahteva - odgovor (angl. Request-Reply) ....................................................................23

2.8.3 Zaporedje sporočil (angl. Message sequence) ............................................................23

2.8.4 Zapadlost sporočila (angl. Message expiration) ..........................................................23

2.9 Usmerjevanje sporočil (angl. Message routing) ..................................................................24

2.9.1 Seznam prejemnikov (angl. Recipient list) ..................................................................25

2.9.2 Načrt poti (angl. Routing slip) .....................................................................................26

2.9.3 Posrednik sporočil (angl. Message Broker) .................................................................26

VII

2.10 Preoblikovanje sporočil (angl. Message transformation) ....................................................27

2.11 Končne točke sporočil (angl. Message endpoints) ..............................................................28

2.11.1 Sporočilna vrata (angl. Messaging gateway) ...............................................................29

2.11.2 Konkurirajoči potrošniki (angl. Competing consumers) ...............................................30

2.12 Upravljanje sistema (angl. System management) ...............................................................31

3. PROTIVZORCI ............................................................................................................................32

3.1 Referenčni model protivzorcev ..........................................................................................34

3.2 Predloge vzorcev in protivzorcev .......................................................................................36

3.3 Razvojni protivzorci ...........................................................................................................38

3.4 Arhitekturni protivzorci .....................................................................................................42

3.5 Protivzorci upravljanja projektov programske opreme .......................................................48

3.6 Integracijski protivzorci ......................................................................................................50

3.6.1 Neredno posredovanje kode (angl. Infrequent check in) ............................................52

3.6.2 Pokvarjena verzija (angl. Broken build) .......................................................................52

3.6.3 Minimalna povratna informacija (angl. Minimal feedback) .........................................53

3.6.4 Vsiljena povratna informacija (angl. Spam feedback)..................................................54

3.6.5 Počasni stroj (angl. Slow machine) .............................................................................54

3.6.6 Razširjena verzija (angl. Bloated build) .......................................................................55

3.6.7 Posredovanje kode pred odhodom (angl. Bottleneck commits) ..................................55

3.6.8 Neprekinjena ignoranca (angl. Continuous ignorance)................................................56

3.6.9 Predvidene izdelave verzij (angl. Scheduled builds) ....................................................56

3.6.10 Delovanje na lastnem računalniku (angl. Works on my machine) ...............................56

3.6.11 Delovanje v lokalnem okolju (angl. IDE-only build) .....................................................57

3.6.12 Ozkomiselno okolje (angl. Myopic environment) ........................................................57

3.6.13 Onesnaženo okolje (angl. Polluted environment) .......................................................58

4. PRAKTIČNI DEL ..........................................................................................................................59

4.1 Uporabljeni vzorci integracije ............................................................................................60

4.2 Izbira potencialnih vzorcev za uporabo ..............................................................................65

5. SKLEP ........................................................................................................................................67

6. VIRI ...........................................................................................................................................68

7. PRILOGE ....................................................................................................................................70

7.1 Naslov študenta.................................................................................................................70

7.2 Kratek življenjepis študenta ...............................................................................................70

VIII

SEZNAM SLIK

Slika 2.1: Grafični prikaz razdelitve kategorij ........................................................................... 6

Slika 2.2: Model prenosa datotek med dvema aplikacijama ..................................................... 8

Slika 2.3: Model deljene podatkovne baze ................................................................................. 9

Slika 2.4: Model sporočilnega stila ............................................................................................. 9

Slika 2.5: Primer oddajanja in prejemanja sporočila skozi sporočilni kanal.......................... 10

Slika 2.6: Pošiljanje sporočila ................................................................................................... 11

Slika 2.7: Cevi in filtri ............................................................................................................... 12

Slika 2.8: Primer usmerjevalnika sporočil ................................................................................ 12

Slika 2.9: Primer prevajanja sporočila iz enega podatkovnega formata v drugega ............... 13

Slika 2.10: Povezava aplikacije s sporočilnim kanalom preko končne točke sporočila ........ 14

Slika 2.11: Primer kanala od točke do točke ............................................................................ 16

Slika 2.12: Primer kanala objavi - naroči ................................................................................. 17

Slika 2.13: Primer kanalov podatkovnega tipa......................................................................... 18

Slika 2.14: Primer kanala za neveljavna sporočila .................................................................. 18

Slika 2.15: Delovanje kanala mrtvih sporočil .......................................................................... 19

Slika 2.16: Model vzorca zagotovljene dostave ....................................................................... 20

Slika 2.17: Uporaba kanalnega adapterja ................................................................................. 21

Slika 2.18: Model vzorca zahteva - odgovor ............................................................................ 23

Slika 2.19: Odločitveno drevo za izbiro usmerjevalnika (prirejeno po [4]) ........................... 25

Slika 2.20: Uporaba vzorca seznam prejemnikov .................................................................... 26

Slika 2.21: Povezovanje formatov aplikacij brez kanoničnega modela in z njim ................. 28

Slika 2.22: Diagram zaporedja pri uporabi sporočilnih vrat ................................................... 30

Slika 2.23: Model vzorca konkurirajoči potrošniki ................................................................. 31

IX

Slika 3.1: Model SDLM [7]....................................................................................................... 36

Slika 3.2: Protivzorec dovod do sistema................................................................................... 44

Slika 3.3: Model rešitve protivzorca zunanje odvisnosti ......................................................... 45

Slika 3.4: Koraki tehnike preprečevanja pokvarjene verzije [9] ............................................. 53

Slika 4.1: Arhitektura sistema ApplicationBridge ................................................................... 59

Slika 4.2: Primer vsebinsko pogojenega usmerjevalnika v spletni trgovini ........................... 62

Slika 4.3: Legenda odločitvene sheme integracijskih vzorcev ............................................... 65

Slika 4.4: Odločitvena shema za izbiro integracijskih vzorcev .............................................. 66

SEZNAM PREGLEDNIC

Tabela 2.1: Seznam vzorcev integracije ..................................................................................... 6

Tabela 2.2: Uporaba vzorcev za konstrukcijo sporočil............................................................ 22

Tabela 2.3: Uporaba vzorcev končnih točk sporočila .............................................................. 29

Tabela 2.4: Seznam vzorcev upravljanja sistema po kategorijah ........................................... 31

Tabela 3.1: Stopnje vpliva glede na vrsto upravljanja ............................................................. 35

Tabela 3.2: Primer predloge protivzorca špagetasta koda ....................................................... 41

Tabela 3.3: Seznam upravljalskih protivzorcev ....................................................................... 49

Tabela 3.4: Integracijski protivzorci ......................................................................................... 51

Tabela 4.1: Seznam uporabljenih vzorcev integracije ............................................................. 61

X

SEZNAM PRIMEROV

Primer 2.1: Ukazno sporočilo tipa SOAP ................................................................................. 22

Primer 3.1: Konfiguracijska datoteka za nastavljanje naslovnikov notifikacij ...................... 54

Primer 4.1: Primer ukaznega sporočila ..................................................................................... 63

Primer 4.2: Primer funkcije za pošiljanje dokumentov spletni storitvi (C#) [12].................. 63

Primer 4.3: Dogodkovno sporočilo o spremembi podatkov stranke....................................... 64

Primer 4.4: Primer uporabe vzorca obogatitev vsebine ........................................................... 64

XI

UPORABLJENE KRATICE

ERP – Enterprise Resource Planning

EAI – Enterprise Application Integration

B2B – Business to Business

SOA – Service-Oriented Architecture

RMI – Remote Method Invocation

ebXML – Electronic Business using eXtensible Markup Language

HTTP – HyperText Transfer Protocol

TCP – Transmission Control Protocol

API – Application Programming Interface

SOAP – Simple Object Access Protocol

IT – Information Technology

SDLM – Software Design Level Model

WSI – Web Service Interface

DLL – Dynamic Link Lybrary

XML – Extensible Markup Language

XSLT – Extensible Stylesheet Transformations

IDE – Integrated Development Environment

WAR – Web Application Archive

JAR – Java Archive

EAR – Enterprise Archive

URL – Uniform Resource Locator

http://en.wikipedia.org/wiki/Information_technology

Integracijski vzorci in protivzorci Stran 1

1. UVOD

Še ne dolgo tega so nekatera najpomembnejša podjetja za programsko opremo trdila, da je z

uvedbo celovitih rešitev (ERP – Enterprise Resource Planning) konec teţav s povezovanjem

informacijskih rešitev. Danes vemo, da je prav v povezovanju ključ do hitrega prilagajanja

trga. Povečanje poslovne vrednosti današnjih informacijskih sistemov lahko zagotovimo samo

z vse večjim povezovanjem posameznih namenskih programov, poslovnih procesov in

celotnih organizacij [1]. Zagotoviti moramo nadzorovano in učinkovito izmenjavo podatkov

in poslovnih procesov med namenskimi programi in viri podatkov znotraj organizacije in

širše. Čim višja je stopnja integracije in krajši so odzivni časi, tem večje učinke lahko

pričakujemo od integriranega sistema.

Namen diplomskega dela je, da spoznamo različne principe integracije in da ugotovimo,

katere principe oz. vzorce se izplača uporabiti, saj so se v preteklosti ţe večkrat izkazali za

primerne rešitve določenih problemov pri integraciji. Prav tako bomo spoznali načine

integracij, ki niso najboljši za rešitev problemov, zato bi se morali uporabi teh vzorcev

izogibati.

V drugem poglavju bomo spoznali vzorce integracije. Predstavili bomo njihove kategorije

in jih podrobneje opisali. V tretjem poglavju bomo na podoben način spoznali njim nasprotne

protivzorce. Opisali bomo razvojne, arhitekturne, upravljavske in integracijske protivzorce. V

četrtem poglavju bo opisan praktičen primer integracije specifične spletne trgovine s

sistemom ERP, ki se imenuje Pantheon. Prav tako bodo predstavljeni posamezni primeri

vzorcev iz te integracije. Spoznali bomo tako dobre kot slabe prakse, ki so se v mnogih

projektih v preteklosti izkazale za pozitivne (vzorci) oz. negativne (protivzorci).


2. VZORCI INTEGRACIJE

2.1 Uvod

Najprej moramo razloţiti, kaj vzorci sploh so. Vzorci pri integraciji lahko pomagajo na

različne načine. Vzorci niso deli kode, ki jih samo skopiramo iz podobnega problema (vzorec

kopiraj - prilepi), ampak so nek nasvet o rešitvah pri ponavljajočih se problemih. Vzorci

predstavljajo mehanizem za učenje in reševanje problemov, na katere pogosto naletimo pri

razvoju programske opreme. Uporaba vzorcev se je v praksi močno razširila po letu 1995, ko

je izšla knjiga Design Patterns: Elements of Reusable Object-Oriented Software [2]. V tej

knjigi so vzorci razdeljeni v tri skupine:

Arhitekturni vzorci

Predstavljajo osnovno strukturo oz. shemo sistema, definirajo podsisteme in dajejo

napotke za definiranje odgovornosti in relacij med temi podsistemi.

Načrtovalski vzorci

So neke vrste predloga za rešitev določenega problema, ki se lahko uporabi v več

situacijah in je neodvisna od programskega jezika. Objektno orientirani načrtovalski

vzorci običajno definirajo povezave med objekti ali razredi. Algoritmov ne

obravnavamo kot del načrtovalskih vzorcev.

Idiomi

So vzorci na najniţjem nivoju abstrakcije, saj definirajo rešitev problema v točno

določenem programskem okolju.

2.2 Integracija sistemov

Projekte zdruţevanja v glavnem delimo na tiste znotraj organizacije (EAI – Enterprise

Application Integration) in na projekte povezovanja z zunanjimi sistemi (B2B – Business to

Business). Pri povezovanju posameznih informacijskih sistemov je ključen proces definicije

in izgradnje integracijske arhitekture. Čim večji je projekt in čim večje je število povezujočih


sistemov, tem pomembnejša je temeljna arhitektura. Zato je zelo pomembno, da si izberemo

pravilno pot integracije. Čeprav je okolje integracijskega projekta zelo heterogeno in

praviloma unikatno, se kljub temu pojavljajo določeni vzorci integracije. Glede na hierarhijo

abstrakcije jih lahko razdelimo na podatkovno, procesno in storitveno integracijo. Podatkovni

pristop k integraciji sistemov kot pripomoček za integracijo uporablja podatke, ki si jih

sistema izmenjujeta. Taka integracija je danes najbolj znana, uporablja se praktično od prvega

trenutka, ko je bilo potrebno povezati različne informacijske sisteme. Procesna integracija

predstavlja novo raven na podlagi podatkovne integracije. Predstavlja moţnost povezovanja

procesov in s tem avtomatizacije procesov, ki se trenutno izvajajo ročno. V osnovni shemi

procesne integracije vsak sistem prevzema nadzor nad poslovnim procesom samo v jasno

določenih točkah. Skupaj z globalno določeno poslovno logiko in določenimi delovnimi

tokovi procesna integracija ponuja moţnost optimizacije izvajanja procesov. Storitvena

integracija omogoča namenskim programom, da objavijo in proţijo skupne aplikacijske

storitve. To lahko doseţemo s pomočjo definicije skupnih metod ali z uporabo infrastrukturne

rešitve za integracijo ob pomoči storitev [2].

Vendarle pa imajo vsi trije pristopi en sam končni cilj – zagotoviti razpoloţljivost

funkcionalnosti posameznega sistema drugim sistemom. Posamezni pristopi različno vplivajo

na sisteme, ki jih ţelimo integrirati. Tako podatkovna integracija praviloma ne zahteva

sprememb izvornega ali ciljnega sistema. Na drugi strani pa storitvena integracija terja

spremembo velike večine sistemov in s tem povezane stroške dopolnitev sistemov [2].

2.3 Tipi integracij

Podjetja imajo običajno več različnih aplikacij, ki so bile razvite posebej za njih. Zato

nastopi velika zmešnjava, ko je potrebno pridobiti podatke iz teh aplikacij. Obstaja odprto

vprašanje, zakaj se podjetja sploh spuščajo v takšno zmedo. V nadaljevanju bomo pojasnili,

zakaj pride v vedno več podjetjih, predvsem večjih, do takšnih situacij. Najprej moramo

povedati, da je pisanje in predvsem načrtovanje informacijskih sistemov zelo teţavno. Skoraj

nemogoče je narediti sistem, ki bi pokril vse funkcionalnosti poslovanja, ki smo si ga zamislili

v posameznem podjetju. Celo največji in najbolj priznani sistemi, kot so SAP, Oracle,

PeopleSoft, podpirajo le peščico funkcionalnosti, ki si jih posamezniki v podjetju zamislijo.

Zato prihaja do največ integracij predvsem v povezavi s posameznimi sistemi ERP. Po


definiciji integracija poteka med različnimi platformami na različnih lokacijah. Največ

problemov običajno nastane zaradi prodajalcev integracij, saj le-ti ponujajo različne

integracijske pakete, ki so neodvisni od platforme in programskega jezika, kar pa vedno ni

mogoče [3].

Imamo več tipov integracij, ki se med sabo razlikujejo. Najpogostejši tipi so [3]:

Informacijski portali

Tukaj moramo dostopati do več sistemov hkrati, da lahko dobimo določene

informacije ali izvedemo določeno poslovno funkcijo.

Podvojitev podatkov

V tem primeru je potrebno vsako spremembo podatkov na določenem sistemu

prenesti tudi na drug sistem, ki uporablja iste podatke, npr. če se spremeni naslov

stranke na enem sistemu, se mora spremeniti tudi na drugem sistemu, kjer

uporabljajo iste informacije o stranki.

Skupna poslovna funkcija

Določena funkcija se lahko kliče iz več sistemov, saj vsi sistemi potrebujejo iste

podatke, npr. funkcija, ki preverja, če je poštna številka pravilna, se lahko uporablja

v več sistemih hkrati.

Storitveno orientirana arhitektura (SOA – Service-Oriented Architecture)

S SOA lahko omogočimo zdruţevanje in prost pretok informacij med različnimi

aplikacijami za podporo pri poslovanju, module storitev lahko uporabljajo različne

skupine uporabnikov znotraj podjetja, lahko pa jih odpremo tudi za zunanje

uporabnike.

Porazdeljeni poslovni proces

Večkrat se zgodi, da določena sprememba v enem sistemu vpliva na več ostalih

sistemov, zato potrebujemo koordinacijo med vsemi temi sistemi, na katere vpliva.

Imeti moramo nekakšno komponento, ki upravlja med temi poslovnimi procesi in

skrbi za vse potrebne spremembe v ostalih sistemih.


Integracija poslovanja med podjetji (B2B – Business to Business)

Podjetje omogoča določeno funkcionalnost, ki je dostopna izven lastnih aplikacij. V

tem primeru je potrebno povezati določene funkcionalnosti nekega sistema z drugim.

Takšno integracijo uporabljajo predvsem poslovni partnerji, npr. dostavna sluţba

omogoča funkcijo za izračunavo stroškov dostave, ki jo lahko poslovni partner

uporabi in tako izda stranki predračun ali račun, v katerega je vključena tudi

vrednost dostave.

2.4 Seznam vzorcev

Opisali bomo nekaj najpogostejših vzorcev integracije iz kataloga [4], kot so agregator,

mediator, sporočilno vodilo, posrednik, zahteva - odgovor, sporočilni most, garantirana

dostava. Te vzorce bomo razdelili v osem kategorij in jih tako tudi predstavili v nadaljnjih

poglavjih. Seznam najbolj uporabljanih vzorcev, ki so razdeljeni v posamezne kategorije, je

prikazan v Tabeli 2.1. Imena vzorcev so navedena v izvornem angleškem jeziku.


Tabela 2.1: Seznam vzorcev integracije

Kategorije Vzorci

Integracijski

stili

File Transfer, Shared Database, Remote Procedure Invocation, Messaging.

Sporočilni

sistemi

Message, Message Channel, Pipes and Filters, Message Router, Message

Translator, Message Endpoint.

Sporočilni

kanali

Point-to-Point Channel, Publish-Subscribe Channel, Datatype Channel,

Invalid Message Channel, Dead Letter Channel, Guarantied Delivery,

Channel Adapter, Messaging Bridge, Message Bus.

Konstrukcija

sporočila

Command Message, Document Message, Event Message, Request-Reply,

Return Address, Correlation Identifier, Message Sequence, Message

Expiration, Format Indicator.

Usmerjanje

sporočil

Content-based router, Message Filter, Dynamic Filter, Recipient List,

Splitter, Aggregator, Resequencer, Composed Message Processor, Scatter-

Gather, Routing Slip, Process Manager, Message Broker.

Preoblikovanje

sporočil

Envelope Wrapper, Content Enricher, Content Filter, Claim Check,

Normalizer, Canonical Data Model.

Končna točka

sporočil

Messaging Gateway, Message Mapper, Transactional client, Polling

Consumer, Event-driven consumer, Competing consumers, Message

dispatcher, Selective consumer, Durable subscriber, Idempotent Receiver,

Service activator.

Upravljanje

sistema

Control bus, Detour, Wire tap, Message History, Message store, Smart

Proxy, Test Message, Channel purger.

Na Sliki 2.1 imamo grafični prikaz razdelitve omenjenih kategorij integracijskih vzorcev; na

sliki ni prvih dveh omenjenih v tabeli, saj se ti dve kategoriji ne nanašata neposredno na

sporočila.

Slika 2.1: Grafični prikaz razdelitve kategorij


2.5 Stili integracije

Če bi imeli samo eno samostojno aplikacijo, ki bi zadovoljevala vse potrebe podjetja, se

nam ne bi bilo potrebno ukvarjati z integracijo. V realnosti pa je vsaka še tako enostavna

aplikacija odvisna od drugih in vse med seboj odvisne aplikacije morajo delovati pravilno in

usklajeno. Pri izbiri določenega pristopa imamo na voljo kar nekaj osnovnih kriterijev:

Sklopljenost aplikacij

Najbolje je, da je med aplikacijami čim manj odvisnosti, to pomeni, da moramo

zmanjšati tesno medsebojno odvisnost in sklopljenost aplikacij.

Spreminjanje aplikacij

Razvijalci naj teţijo k temu, da pri integraciji čim manj spreminjajo kodo aplikacije,

prav tako naj bo integracijske kode čim manj.

Izbira tehnologije

Različni pristopi integracije uporabljajo različne tehnologije, uporaba teh tehnologij

nas lahko preveč stane, prav tako lahko nove tehnologije povečajo čas integracije

zaradi potrebe po novih tehnologijah in spoznavanju le-teh.

Format podatkov

Aplikacije, ki jih integriramo, morajo imeti nek skupen format podatkov, ki si jih

izmenjujejo, da se le-ti ne izgubijo oz. napačno interpretirajo.

Pravočasnost podatkov

Integracija bi naj minimalizirala čas med trenutkom, ko ena aplikacija da podatke na

razpolago za procesiranje, in trenutkom, ko druga te podatke dejansko procesira.

Podatki ali funkcionalnost

Poleg podatkov lahko pri integraciji določena aplikacija nudi tudi funkcionalnosti.

Oddaljeno procesiranje

Računalniško procesiranje je običajno sinhrono, kar pomeni, da procedura čaka, da

se vse podprocedure izvedejo, ker pa je izvajanje oddaljenih procedur časovno

zahtevnejše, je bolje, da izvajamo klice oddaljenih procedur asinhrono – v tem


primeru še vedno kličemo oddaljeno proceduro, a ne čakamo, da se le-ta konča,

temveč nadaljujemo izvajanje svojih procedur.

Zanesljivost

Oddaljeno proţenje funkcij je zelo nezanesljivo in počasno, zato je priporočljivo, da

vedno preverimo, če je oddaljena funkcija sploh dosegljiva v določenem času, in

tako izvajamo druge stvari, ki niso odvisne od te nedosegljive funkcije.

Ţal ne obstaja takšen pristop k integraciji, ki bi upošteval vse naštete kriterije. Zato so se

skozi čas razvili številni pristopi. Pristope integracij lahko povzamemo v štiri glavne

integracijske stile [4]:

Prenos datotek

Za izmenjavo podatkov med aplikacijami uporabljamo datoteke, trenutno najbolj

razširjen format za izmenjavo datotek je XML. Na Sliki 2.2 je prikazan model

prenosa datotek med dvema aplikacijama.

Slika 2.2: Model prenosa datotek med dvema aplikacijama

Deljena podatkovna baza

Vse aplikacije uporabljajo isto podatkovno bazo, kar pomeni, da bo baza tudi ves čas

dosledna oz. konsistentna. Glavna teţava pri tem stilu je načrtovanje podatkovne

baze, saj mora upoštevati vse moţne podatke vseh aplikacij, ki jo uporabljajo. Na

Sliki 2.3 je prikazan model deljene podatkovne baze.


Slika 2.3: Model deljene podatkovne baze

Oddaljeno proženje metod

Kratica za ta integracijski stil je RMI (angl. Remote Method Invocation). Stil temelji

na enkapsulaciji integracije aplikacij. Če neka aplikacija potrebuje podatke od katere

druge, potem komunicira z njo neposredno s klici njenih funkcij.

Sporočilni stil

Prednost tega stila je, da je delovanje sistema asinhrono, kar pomeni, da ni potrebno,

da sistem, ki mora sprejemati sporočilo, v trenutku pošiljanja deluje in lahko to

sporočilo interpretira kasneje. Na Sliki 2.4 vidimo, da ima več aplikacij povezavo do

sporočilnega sistema [5].

Slika 2.4: Model sporočilnega stila


2.6 Sporočilni sistemi (angl. Messaging systems)

Kot večina tehnologij je tudi sporočanje sestavljeno iz nekaj osnovnih konceptov. Ko enkrat

razumemo te koncepte, si ţe lahko predstavljamo tehnologijo, čeprav še ne vemo točno, kako

bomo to tehnologijo uporabili. Osnovni koncepti sporočanja so: sporočilni kanal (angl.

Message channel), sporočilo (angl. Message), cevi in filtri (angl. Pipes and Filters),

usmerjevalnik sporočil (angl. Message router), prevajalnik sporočil (angl. Message translator)

in končna točka sporočila (angl. Message endpoint) [4].

2.6.1 Sporočilni kanal (angl. Message channel)

Sporočilni sistem ima več sporočilnih kanalov, skozi katere gredo le določeni tipi podatkov.

Ko ţeli določena aplikacija posredovati podatke nekemu drugemu sistemu, ne komunicira

neposredno s sporočilnim sistemom, temveč preko točno določenega sporočilnega kanala, ki

je določen za tako vrsto podatkov. Prav tako mora aplikacija, ki sprejema določene podatke,

le-te pridobiti iz konkretnega sporočilnega kanala, ki je določen za takšne podatke. Na Sliki

2.5 je prikazano potovanje sporočila od oddajajoče aplikacije do sprejemne aplikacije skozi

sporočilni kanal [4].

Slika 2.5: Primer oddajanja in prejemanja sporočila skozi sporočilni kanal


2.6.2 Sporočilo (angl. Message)

Vsak del podatkov, ki potuje preko sporočilnega sistema, mora biti oblikovan v sporočilo, ki

se pošlje skozi sporočilni kanal. Sporočilo je sestavljeno iz dveh delov [4]:

Glava sporočila (angl. Header)

Vsebuje informacije o sporočilu, npr. kaj, kam in od kod se pošilja.

Telo sporočila (angl. Body)

Vsebuje dejanske podatke sporočila.

Za vsak sporočilni sistem so sporočila enaka, telo sporočila se mora prenesti po navodilih,

ki so opisana v glavi sporočila. Vendar obstajajo različni tipi sporočil, ki jih bomo podrobneje

spoznali v poglavju o konstrukciji sporočil. Na Sliki 2.6 lahko vidimo primer pošiljanja

sporočila, ki je sestavljeno iz glave in telesa [4].

Slika 2.6: Pošiljanje sporočila

2.6.3 Cevi in filtri (angl. Pipes and filters)

V večini primerov integracij sistemov pride do stanja, ko mora en sam dogodek sproţiti

neko zaporedje procesov. Z vzorcem cevi in filtrov razdelimo večje opravilo na manjše med

seboj neodvisne korake (filtre), ti koraki pa so med seboj povezani preko cevi. Vsak filter ima

nalogo, da sprejme sporočilo vhodne cevi, ga sprocesira in posreduje rezultate izhodni cevi.

Posamezna cev povezuje filtre med sabo. Na Sliki 2.7 imamo primer treh filtrov in štirih cevi

[4].


Slika 2.7: Cevi in filtri

2.6.4 Usmerjevalnik sporočil (angl. Message router)

Usmerjevalnik je zelo podoben filtru, le da ima več izhodov. Naloga usmerjevalnika je samo

sprejeti sporočilo in ga usmeriti v pravilni sporočilni kanal (cev) glede na dane pogoje. Ta

koncept torej ne spreminja sporočila, ki ga je dobil preko vhodne pipe, ampak ga samo

usmerja. Poznamo več tipov usmerjevalnikov [4]:

Fiksni usmerjevalnik

Ima samo en izhod.

Vsebinsko pogojen usmerjevalnik

Izhod se določi na podlagi vsebine sporočila.

Kontekstno pogojen usmerjevalnik

Izhod se določi na podlagi okolja, npr. če se je določen proces končal z napako, ga

poskušamo ponoviti.

Na Sliki 2.8 imamo primer usmerjevalnika, ki usmerja sporočila iz ene vhodne vrste v več

izhodnih [4].

Slika 2.8: Primer usmerjevalnika sporočil


2.6.5 Prevajalnik sporočil (angl. Message translator)

Različne aplikacije na trgu imajo različne podatkovne modele, zato pri integraciji dveh ali

več različnih sistemov pridemo do problema usklajevanja teh modelov. Določena entiteta ene

aplikacije ima lahko drugačne atribute, kot jih ima enakovredna entiteta v podatkovnem

modelu druge aplikacije. Zato integrirane rešitve običajno komunicirajo med sabo z nekimi

standardiziranimi podatkovnimi formati, kot sta ebXML in RosettaNet, ki temeljita na notaciji

XML. Slika 2.9 prikazuje primer prevajanja sporočila, kjer za vhod dobimo podatek v

določenem podatkovnem formatu, ki ga moramo transformirati v drugega [4].

Slika 2.9: Primer prevajanja sporočila iz enega podatkovnega formata v drugega

2.6.6 Končna točka sporočil (angl. Message Endpoint)

Namen končne točke sporočila je, da ogradi sporočilni sistem od ostalega dela aplikacije.

Ostali del aplikacije ne ve veliko o formatih sporočil, sporočilnih kanalih ali kakršnihkoli

drugih informacijah o komuniciranju aplikacije preko sporočilnega sistema; vsebuje le

zahtevo ali del podatkov, ki jih mora poslati drugi aplikaciji, ali pa pričakuje podatke od

druge aplikacije. Naloga končne točke sporočil je, da vzame dano zahtevo oz. podatke, ki se

morajo poslati, jih spravi v pravilni format in jih pošlje po določenem sporočilnem kanalu.

Prav tako je naloga končne točke sporočil, da sprejema podatke od druge aplikacije, izlušči iz

podatkov ţeljeno vsebino in jo posreduje aplikaciji v obliki, ki jo bo aplikacija znala

sprocesirati. Na Sliki 2.10 lahko vidimo primer povezave aplikacij s sporočilnim kanalom

preko končne točke sporočila [4].


Slika 2.10: Povezava aplikacije s sporočilnim kanalom preko končne točke sporočila

2.7 Sporočilni kanali (angl. Message channels)

Odločitev, ali bomo uporabili sporočilni kanal ali ne, je zelo enostavna. Če ima aplikacija

podatke, ki jih mora pošiljati oz. sprejemati, mora uporabiti kanal. Veliko teţje se je odločiti,

kateri kanal bomo izbrali in kako bomo le-tega uporabili. Imamo več tem, ki jih je potrebno

raziskati pri načrtovanju aplikacije. Te teme so [4]:

Fiksen nabor kanalov

Običajno ima aplikacija vnaprej določen nabor kanalov, ki jih bo uporabljala. Pri

načrtovanju je potrebno vedeti, kam bo usmerjena določena vrsta podatkov in

seveda tudi kje iskati podatke, ki pridejo iz drugih aplikacij. Sporočilni kanali so

večinoma določeni statično z redkimi izjemami, npr. pri kanalu za odgovor v vzorcu

zahteva - odgovor.

Določitev nabora kanalov

Vprašanje je, kdo odloča o tem, kateri kanali bodo uporabljeni – sporočilni sistem

ali aplikacija. Smiselno je, da nabore kanalov načrtujemo iterativno. Najprej

aplikacija določi, katere kanale bo sporočilni sistem potreboval, kasneje se lahko ob

spremembi aplikacije ali dodajanju nove aplikacije po potrebi dodajo novi kanali.

Usmerjenost kanalov

Vprašanje je, ali bo kanal enosmeren ali dvosmeren. Pri enosmernem kanalu

sporočilo potuje od ene aplikacije do druge, torej samo v eno smer. Če bi bil kanal

dvosmeren, bi to pomenilo, da bi aplikacija tako sprejemala kot tudi pošiljala

sporočila po istem kanalu in bi tako tudi sprejemala svoja sporočila, kar pa v


praktičnem smislu uporabe kanalov ne bi imelo smisla, saj je bistvo sporočilnih

kanalov komunikacija med različnimi aplikacijami.

2.7.1 Odločitev o izbiri sporočilnega kanala

Zdaj ko vemo, kaj sporočilni kanali sploh so, lahko pogledamo, katere odločitve je potrebno

sprejeti pri izbiri kanala. Te odločitve so [4]:

Smer 1:1 ali smer 1:N

Tukaj moramo ugotoviti, ali ţelimo, da se podatki delijo le z eno aplikacijo ali z več

aplikacijami. V prvem primeru izberemo kanal tipa točka do točke (angl. Point-to-

Point Channel), v drugem primeru pa uporabimo kanal tipa objavi - naroči (angl.

Publish-Subscribe Channel). Oba tipa kanalov bomo opisali kasneje.

Določitev tipa podatkov

Vsaka oblika podatkov v aplikaciji mora biti določenega tipa, saj le tako lahko

sprejemna aplikacija razume te podatke. Prav to nam govori vzorec kanal

podatkovnega tipa (angl. Datatype Channel), saj morajo po logiki tega vzorca biti vsi

podatki na posameznem kanalu določenega tipa.

Neveljavna in mrtva sporočila

Sporočilni sistem omogoča, da se določeno sporočilo prenese od pošiljatelja do

prejemnika, vendar ni zadolţen za to, da prejemnik sporočila zna razpoznati

sporočilo. V tem primeru lahko uporabimo kanal neveljavnih sporočil (angl. Invalid

Message Channel), ki da to nerazvozlano sporočilo v ta kanal, in nadzorni sistem bo

to sporočilo kdaj kasneje poskusil obdelati. Podobno deluje tudi kanal mrtvih

sporočil (angl. Dead Message Channel) za sporočila, ki so uspešno poslana, a

neuspešno sprejeta.

Odpornost na napake

V primeru napake v sistemu moramo vseeno zagotoviti, da so sporočila poslana in

sprejeta. Za to obstojnost skrbi vzorec zagotovljene dostave (angl. Guaranted

Delivery), ki poskrbi za to, da se vsako sporočilo shrani na disk in tako sporočilo

tudi v primeru napake ni izgubljeno.


Odjemalci brez povezave

Lahko imamo aplikacijo, ki se ne more povezati s sporočilnim sistemom in vseeno

hoče sodelovati pri sporočanju. V tem primeru lahko uporabimo kanalni adapter

(angl. Channel Adapter) ali sporočilni most (angl. Messaging Bridge).

Komunikacijska hrbtenica (angl. Communications backbone)

Vedno več aplikacij se povezuje s sporočilnim sistemom, zato sporočilni sistem slej

ko prej postane t. i. sporočilno vodilo (angl. Message Bus), ki omogoča dostop do

vseh aplikacij in funkcionalnosti integracije.

2.7.2 Kanal tipa točka do točke (angl. Point-to-Point channel)

Kanal tipa točka do točke skrbi za to, da določeno sporočilo dobi samo en prejemnik. Sicer

lahko obstaja več prejemnikov, a le en prejemnik bo to sporočilo lahko sprejel. Ti prejemniki

lahko med seboj tekmujejo in tako postanejo t. i. konkurenčne stranke (angl. Competing

customers). Na Sliki 2.11 lahko vidimo primer tega kanala, ki usmerja sporočila samo enemu

prejemniku [4].

Slika 2.11: Primer kanala od točke do točke

2.7.3 Kanal objavi - naroči (angl. Publish-Subscribe channel)

Ta kanal deluje tako, da ima en vhod in več izhodov, za vsakega naročnika en izhod. Ko

pride sporočilo do tega kanala, ta pošlje kopijo sporočila naprej vsem naročnikom tega kanala

in vsak naročnik lahko to sporočilo prejme le enkrat. Na Sliki 2.12 prikazujemo, kako ta kanal

posreduje sporočilo več naročnikom [4].


Slika 2.12: Primer kanala objavi - naroči

2.7.4 Kanal podatkovnega tipa (angl. Datatype channel)

Včasih se soočimo s problemom, ko istemu prejemniku pošiljamo sporočila, ki niso istega

podatkovnega tipa. Če bi vse te različne podatkovne tipe ţeleli pošiljati po istem kanalu,

prejemnik ne bi vedel, kakšnega tipa bo sporočilo, in bi moral najprej pridobiti podatek o tipu

sporočila, šele nato bi lahko sporočilo razvozlal. Za ta problem obstaja zelo enostavna rešitev.

Izognemo se mu lahko, če uporabimo za vsak predviden podatkovni tip svoj kanal in tako po

vsakem kanalu potujejo samo sporočila istega podatkovnega tipa, tako bo tudi prejemnik znal

vsako sporočilo razvozlati, saj bo vedel, kakšnega tipa je. Na Sliki 2.13 imamo prikazan

primer več kanalov za posamezne podatkovne tipe [4].


Slika 2.13: Primer kanalov podatkovnega tipa

2.7.5 Kanal neveljavnih sporočil (angl. Invalid message channel)

Zgodi se, da prejemnik določenega sporočila ne zna procesirati. V takem primeru je rešitev

sledeča: taka sporočila se enostavno posredujejo v poseben kanal, ki je rezerviran za

sporočila, ki niso bila uspešno procesirana. Sporočilni sistem lahko ima več takih kanalov in s

pomočjo njih lahko kasneje ugotovimo, kaj je šlo narobe, saj imamo ta sporočila še vedno

shranjena. Slika 2.14 kaţe primer, ko prejemnik neveljavno sporočilo usmeri v ta kanal [4].

Slika 2.14: Primer kanala za neveljavna sporočila


2.7.6 Kanal mrtvih sporočil (angl. Dead letter channel)

Pri pošiljanju sporočila lahko pride do napake in kanal ne uspe dostaviti sporočila do

prejemnika. V tem primeru mora sporočilni sistem z nedostavljenim sporočilom nekaj

narediti. Ena izmed moţnosti je, da usmeri nedostavljeno sporočilo v t. i. kanal mrtvih

sporočil in sistem kasneje poskuša ugotoviti, zakaj sporočilo ni bilo dostavljeno. Na Sliki 2.15

imamo prikazan model kanala mrtvih sporočil [4].

Slika 2.15: Delovanje kanala mrtvih sporočil

2.7.7 Zagotovljena dostava (angl. Guaranted delivery)

Največja prednost asinhronega sporočanja je, da pošiljatelju in prejemniku ni potrebno

delovati v istem času. Če je prejemnik nedosegljiv, lahko sporočilni sistem shrani sporočilo v

pomnilniku, dokler prejemnik ne postane dosegljiv in mu takrat posreduje sporočilo. Problem

nastane, če se v tem času sistem zruši in se tako vsi podatki iz pomnilnika izgubijo. Zato

aplikacije uporabljajo datoteke in podatkovne baze, da podatki kljub izpadu sistema ostanejo

shranjeni. Tako je tudi pri vzorcu zagotovljene dostave. Vsak sistem, ki ima sporočilni sistem,

shranjuje podatke lokalno, šele nato pošlje podatke prejemniku, ki najprej shrani podatke

lokalno v datoteko ali podatkovno bazo in jih nato posreduje predvidenemu prejemniku.

Poudarek je seveda na tem, da je vedno potrebno imeti shranjene podatke vsaj na enem


sistemu lokalno. S tem vzorcem sicer pridobimo obstojnost podatkov, a povečuje se

zasedenost sistema, saj je potrebno veliko zmogljivosti za dodatno shranjevanje podatkov,

dodatno zasedamo tudi lokalne diske. Na sliki 2.16 imamo model vzorca zagotovljene dostave

[4].

Slika 2.16: Model vzorca zagotovljene dostave

2.7.8 Kanalni adapter (angl. Channel adapter)

Veliko aplikacij ni bilo načrtovanih z namenom, da bi uporabljale sporočilne sisteme. Da bi

komunicirali z drugimi sistemi, uporabljajo bolj generične rešitve, kot so podatkovne baze,

izmenjava datotek ali komunikacije preko protokolov, kot sta HTTP ali TCP. Ena od rešitev

je tudi uporaba kanalnega adapterja. Z uporabo le-tega lahko dostopamo do podatkov

aplikacije in do t. i. programskega vmesnika aplikacije (angl. API-Application Programming

Interface). Ta adapter deluje kot odjemalec sporočilnega sistema, lahko posluša interne

dogodke v aplikaciji in pošilja oz. sprejema podatke od sporočilnega sistema in tako lahko

vsako aplikacijo poveţemo s sporočilnim sistemom, če le uporabimo pravilni kanalni adapter.

Na Sliki 2.17 je prikazan primer povezovanja aplikacije po vzorcu kanalnega adapterja do

sporočilnega sistema [4].


Slika 2.17: Uporaba kanalnega adapterja

2.8 Konstrukcija sporočil (angl. Message construction)

V tem poglavju se bomo osredotočili na oblikovanje sporočila. Namen oblikovanja

sporočila je, da bo vsebina sporočila pravilno interpretirana, da bo sprejemni sistem sporočila

vrnil odgovor, če bo to zahtevano, da pri veliki količini podatkov sporočilo razbijemo na

manjše dele in jih pošljemo kot neko zaporedje sporočil in da določena sporočila dostavimo

pravočasno, saj bi v nasprotnem primeru lahko prišlo do napake v sistemu. V podpoglavjih

bodo predstavljeni primeri rešitev tovrstnih teţav pri oblikovanju sporočila. Znani vzorci za

konstrukcijo sporočil so: ukazno sporočilo (Command Message), dokumentno sporočilo

(Document Message), dogodkovno sporočilo (Event Message), zahteva - odgovor (Request-

Reply), vračanje naslova (Return Address), korelacijski identifikator (Correlation Identifier),

sekvenca sporočil (Message Sequence), zapadlost sporočila (Message Expiration), pokazatelj

formata (Format Indicator). V Tabeli 2.2 je opisano, kdaj se ti vzorci uporabljajo [4].


Tabela 2.2: Uporaba vzorcev za konstrukcijo sporočil

Ime vzorca Uporaba

Ukazno sporočilo Pri proţenju funkcionalnosti druge aplikacije.

Dokumentno sporočilo Za zanesljiv prenos podatkovnih struktur med aplikacijami.

Dogodkovno sporočilo Za zanesljivo asinhrono obvestilo o dogodku med aplikacijami.

Zahteva - odgovor Kadar pošiljatelj potrebuje odgovor na poslano sporočilo.

Povratni naslov Kadar ţelimo, da se odgovor pošlje na drug naslov.

Korelacijski

identifikator

Kadar moramo specificirati, na katero zahtevo se nanaša

odgovor.

Sekvenca sporočil Ko podatki presegajo velikost enega samega sporočila.

Zapadlost sporočila Kadar je pomemben čas do odziva na sporočilo.

Pokazatelj formata Če moramo specificirati format sporočila, da ta format prejemnik

laţje interpretira.

2.8.1 Ukazno sporočilo (angl. Command message)

Včasih je potrebno skozi sporočilni sistem klicati funkcionalnosti sprejemne aplikacije. To

najlaţje rešimo z vzorcem ukaznega sporočila, ki ogradi to zahtevo po funkcionalnosti

drugega sistema v objekt. Na Primeru 2.1 imamo sporočilo podano v protokolu SOAP (angl.

Simple Object Access Protocol), ki kliče metodo GetLastTradePrice s parametrom symbol

[4].

Primer 2.1: Ukazno sporočilo tipa SOAP


2.8.2 Zahteva - odgovor (angl. Request-Reply)

Ta vzorec velja za enega izmed najpogosteje uporabljanih vzorcev pri spletnih storitvah.

Uporabi se, ko pošiljatelj potrebuje odgovor glede na sporočilo, ki je bilo poslano. Pošiljatelj

pošlje sporočilo oz. zahtevo (angl. Request) po določenemu kanalu prejemniku in čaka na

odgovor. Prejemnik sprejme to sporočilo, ga sprocesira in vrne odgovor (angl. Reply) po

drugem kanalu, kar je prikazano na Sliki 2.18 [4].

Slika 2.18: Model vzorca zahteva - odgovor

2.8.3 Zaporedje sporočil (angl. Message sequence)

Včasih se zgodi, da podatki, ki jih ţelimo poslati naslovniku, presegajo velikost enega

samega sporočila. To najlaţje rešimo z zaporedjem sporočil. Kadarkoli ţelimo poslati večjo

količino podatkov, to najprej razčlenimo v manjše rezine, ki so primerne za eno samo

sporočilo, in tako najprej pošljemo predvideno zaporedje sporočil in označimo vsa sporočila z

identifikacijo zaporedja ter nato pošljemo še posamezna sporočila enega za drugim [4].

2.8.4 Zapadlost sporočila (angl. Message expiration)

Pogosto je vsebina sporočila za prejemnika veljavna le določen čas. Hitra časovna odzivnost

je pomembna predvsem pri interakciji s strankami, kadar ţelijo neposredno dobiti določene

podatke, bodisi preko kakšne aplikacije bodisi preko telefona. Zato lahko sporočilu dodamo

tudi podatek o tem, v kolikšnem času prejemnik sporočilo sploh lahko sprejme in ga


sprocesira, ne da bi to vplivalo na slabo delovanje sistema [4]. V primeru, da se ta čas izteče,

se sporočilo usmeri v kanal mrtvih sporočil, ki smo ga opisali v poglavju 2.7.6.

2.9 Usmerjevanje sporočil (angl. Message routing)

V tem poglavju bomo razloţili, kako se je najbolje lotiti usmerjevanja sporočil pri

integraciji. Vzorce v zvezi z usmerjevanjem sporočil lahko kategoriziramo v naslednje

skupine [4]:

enostavni usmerjevalniki (en vhod ter en izhod ali več izhodov),

sestavljeni usmerjevalniki (kombiniranih je več enostavnih usmerjevalnikov) in

arhitekturni vzorci (opisujejo arhitekturne stile usmerjevanja sporočil).

Na Sliki 2.19 imamo skicirano odločitveno drevo za izbiro pravilnega usmerjevalnika. Če bi

npr. potrebovali enostaven usmerjevalnik, ki lahko sprocesira več sporočil hkrati in vrne manj

sporočil, kot jih je bilo sprocesiranih, bi se odločili za usmerjevalnik tipa agregator. Na skici

ni vzorca dinamični usmerjevalnik, saj lahko vsak usmerjevalnik implementiramo tako, da le-

ta postane dinamična različica. Prav tako ni arhitekturnega vzorca posrednik sporočil (angl.

Message broker). Podrobneje bomo predstavili tri vzorce, in sicer iz vsake kategorije enega

[4].


Slika 2.19: Odločitveno drevo za izbiro usmerjevalnika (prirejeno po [4])

2.9.1 Seznam prejemnikov (angl. Recipient list)

Včasih ţelimo poslati sporočila več prejemnikom hkrati. Dober primer je pošiljanje

elektronskega sporočila več naslovnikom. Vendar pri tem uporabnik sam navede seznam vseh

naslovnikov. Problem nastane, ko mora sistem sam sestaviti seznam prejemnikov. To se

najlaţje rešuje z vzorcem seznam prejemnikov. Logika tega vzorca je sestavljena iz dveh

delov: prvi del sestavi seznam prejemnikov po implementirani logiki, drugi del pa enostavno

gre po tem seznamu in pošlje kopijo sporočila vsakemu prejemniku. Na Sliki 2.20 imamo

model uporabe tega vzorca [4].


Slika 2.20: Uporaba vzorca seznam prejemnikov

2.9.2 Načrt poti (angl. Routing slip)

Ta vzorec se uporabi, kadar se ţelimo izogniti številnim komponentam usmerjanja, ki sproti

usmerjajo sporočilo od enega procesa do drugega. Namesto tega na začetku vsako sporočilo

pošljemo skozi to komponento in ta izračuna ter doda sporočilu točen načrt poti oz. določeno

zaporedje korakov, po katerem mora potovati sporočilo. Po vsakem opravljenem koraku se

pogleda v to zaporedje in to spremenjeno sporočilo usmeri k naslednjemu navedenemu

koraku v zaporedju [4].

2.9.3 Posrednik sporočil (angl. Message Broker)

Če imamo veliko število aplikacij in posledično veliko število sporočilnih kanalov, ki so

med seboj povezani po vzorcu kanala od točke do točke (vsak z vsakim), potem ugotovimo,

da smo dobili neobvladljivo število povezav brez nadzora. Temu se najlaţje izognemo, če

uvedemo centralni posrednik sporočil. Ta bo dobival sporočila od številnih kanalov, ugotovil

pravilno destinacijo in usmeril sporočilo v ustrezni kanal. Če je število povezav še vedno

neobvladljivo, lahko uvedemo več takšnih pogajalcev in jih med seboj poveţemo [4].


2.10 Preoblikovanje sporočil (angl. Message transformation)

Pri preoblikovanju sporočil iz enega formata v drugega moramo upravljati s t. i.

metapodatki. Metapodatki so informacije o dejanskih podatkih, ki jih pošiljamo kot npr.

format, v katerem so podatki. Metapodatki igrajo tako pomembno vlogo pri integraciji, da je

večina integracijskih rešitev načrtovana tako, da se prepletata dva paralelna sistema. Eden je

zadolţen za dejanske podatke, drugi za metapodatke. Večina vzorcev je načrtovanih tako, da

lahko upravljamo metapodatke. Najpogostejši vzorci preoblikovanj sporočil so [4]:

Ovojnica pisma (angl. Envelope wrapper)

Sporočilo se pred pošiljanjem ovije v ovojnico in se ob prispetju na cilj odvije iz

ovojnice.

Obogatitev vsebine (angl. Content enricher)

Ta vzorec uporabimo, kadar potrebujemo nek zunanji izvor podatkov, da dopolnimo

sporočilo z manjkajočimi podatki.

Filter vsebine (angl. Content filter)

Nasprotno od vzorca obogatitev vsebine deluje vzorec filter vsebine: iz sporočila

odstrani nepotrebne podatke in obdrţi le pomembne podatke.

Potrdilo sporočila (angl. Claim check)

Deluje tako, da shranimo sporočilo v neko obstojno zbirko podatkov (disk), potrdilo

sporočila posredujemo določeni komponenti, ta komponenta tako lahko dostopa do

tega sporočila s tem potrdilom (Dober primer iz realnega sveta je oddaja prtljage na

letališču, saj dobimo potrdilo o svoji prtljagi, ki ima identifikacijsko številko oddane

prtljage, in ko prispemo na cilj, lahko prtljago s tem potrdilom tudi dvignemo.).

Normalizator (angl. Normalizer)

Ta vzorec preoblikovanja sporočil uporabimo, kadar ţelimo dobiti isti format

podatkov za vhodna sporočila, ki so različnih tipov. To doseţemo tako, da vsak

določen tip sporočila usmerimo v za to namenjen prevajalnik sporočil, ki sporočila

prevede v skupni podatkovni tip, za usmerjanje pa skrbi ustrezni usmerjevalnik.


Kanonični podatkovni model (angl. Canonical data model)

Ta vzorec uporabimo, kadar imamo oz. pričakujemo več aplikacij, ki med seboj

komunicirajo, in te aplikacije nimajo nekega skupnega podatkovnega formata, kar

pomeni, da potrebujemo prevajalnike sporočil, ki bodo spremenili posamezno

sporočilo v pravilni podatkovni format. Ta vzorec ima osrednji format podatkov, kar

pomeni, da vsaka aplikacija pošilja in sprejema podatke tega modela. Obstaja torej

vmesni sloj med posameznimi formati aplikacij in vsakič, ko se doda nova

aplikacija, se mora ustvariti le transformacija med tem modelom in novo aplikacijo.

Tako pri velikem številu aplikacij potrebujemo veliko manj transformacij, kot bi jih

v primeru, če ne bi uporabili tega modela. Za šest aplikacij bi brez uporabe modela

potrebovali trideset transformacij, z uporabo pa le dvanajst, ta razlika je lepo vidna

na Sliki 2.21 [6].

Slika 2.21: Povezovanje formatov aplikacij brez kanoničnega modela in z njim

2.11 Končne točke sporočil (angl. Message endpoints)

Obstaja veliko moţnosti, da priredimo aplikacijo v končno točko sporočil (angl. Message

endpoint), in to poglavje bo razloţilo, kakšne so te moţnosti ter kako jih najbolje izkoristiti.

Vzorci končnih točk se najpogosteje nanašajo na naslednja dva elementa:

Sporočilni sistem v splošnem (ograditev kode sporočilnega sistema, prevajanje

podatkov, zunanje kontrolirane transakcije)

Sprejemanje sporočil


Najpogostejši tovrstni vzorci so: sporočilna vrata (angl. Messaging gateway), distributer

sporočil (angl. Messaging mapper), transakcijski odjemalec (angl. Transactional client),

izbirajoči potrošnik (angl. Polling consumer), dogodkovno usmerjen potrošnik (angl. Event-

driven consumer), konkurirajoči potrošniki (angl. Competing consumers), razpečevalec

sporočil (angl. Message dispatcher), selektiven potrošnik (angl. Selective consumer), obstojen

naročnik (angl. Durable subscriber), idempotenten prejemnik (angl. Idempotent receiver) in

aktivator storitev (Service activator). V Tabeli 2.3 je opisano, kdaj se ti vzorci uporabljajo [4].

Tabela 2.3: Uporaba vzorcev končnih točk sporočila

Ime vzorca Uporaba

Sporočilna vrata Če ţelimo ločiti sporočilni del od ostalega dela aplikacije.

Distributer sporočil Kadar ţelimo prenašati podatke med domenskimi objekti in

sporočilno infrastrukturo, ne da so le-ti odvisni med sabo.

Transakcijski

odjemalec

Če ţelimo, da odjemalec nadzoruje transakcije s sporočilnim

sistemom.

Izbirajoči potrošnik Kadar ţelimo, da potrošnik izbira, kdaj bo prejel sporočilo.

Dogodkovno

usmerjen potrošnik

Sporočilo se preda prejemniku, ko to prispe do kanala.

Konkurirajoči

potrošniki

Kadar ţelimo, da potrošniki procesirajo več sporočil hkrati.

Razpečevalec sporočil Ko moramo distribuirati sporočila različnim prejemnikom.

Selektiven potrošnik Kadar ţelimo, da potrošnik izbira, katera sporočila bo sprejel.

Obstojen naročnik Če ţelimo, da se sporočila shranijo, tudi ko prejemnik ni aktiven,

in le-te prejme, ko spet postane aktiven.

Idempotenten

prejemnik

Kadar ţelimo, da potrošnik prejme eno in isto sporočilo večkrat in

je rezultat isti, kot če bi le-to prejel samo enkrat.

Aktivator storitev Če ţelimo, da sporočila poveţemo s kanali storitev, ki so bile

dostopane.

2.11.1 Sporočilna vrata (angl. Messaging gateway)

Včasih mora enostavna sporočilna funkcija poslati več kot samo eno sporočilo. Npr.

funkcija, ki ţeli dostopati do podatkov stranke, lahko ustvari več sporočil za te informacije,


eno sporočilo za naslov, eno za osebne podatke, spet eno za zgodovino naročil itd. Zato je

najbolje, da uporabimo vzorec sporočilnih vrat, ki ogradi kodo, ki je specificirana za

sporočanje, in tako ločimo sporočilni del od ostalega dela aplikacije. Na Sliki 2.22 imamo

prikazan diagram zaporedja pri uporabi sporočilnih vrat. Aplikacija za vse podatke, ki jih

potrebuje od sporočilnega sistema, zadolţi sporočilna vrata, ki komunicirajo s sporočilnim

sistemom in vrnejo podatke aplikaciji [3].

Slika 2.22: Diagram zaporedja pri uporabi sporočilnih vrat

2.11.2 Konkurirajoči potrošniki (angl. Competing consumers)

Sporočila se skozi sporočilne kanale vrstijo zaporedno in naravno jih tudi potrošnik

procesira zaporedno. To pa je običajno prepočasno in večkrat se zgodi, da takšno procesiranje

sporočil privede do t. i. ozkega grla, kar pomeni, da potrošnik ne more procesirati sporočil

tako hitro, kot jih kanal dobiva, in tako se le-ta nabirajo v kanalu. Kar potrebujemo v takem

primeru, je, da ima kanal več moţnih prejemnikov sporočil. To rešimo z vpeljavo vzorca

konkurenčnih potrošnikov, ki sočasno procesirajo več sporočil. Ti potrošniki so ustvarjeni

zato, da prejemajo in procesirajo sporočila samo od določenega kanala. Ko ta kanal dostavi

sporočilo, ga lahko prejme katerikoli izmed potrošnikov. Kateri pa ga bo prejel v resnici, je

odvisno od implementacije sporočilnega sistema. Ta rešitev deluje samo pri uporabi kanala


točka do točke, ki smo ga opisali v enem izmed prejšnjih poglavjih. Na Sliki 2.23 imamo

prikazan model tega vzorca. Vidimo, da imamo več sporočil in več potrošnikov, ki med seboj

tekmujejo in kasneje tudi prejmejo ta sporočila [4].

Slika 2.23: Model vzorca konkurirajoči potrošniki

2.12 Upravljanje sistema (angl. System management)

Pri spremljanju sporočilnih rešitev lahko spremljamo sporočila na dveh nivojih abstrakcije.

Tipični upravljalni sistem spremlja, koliko sporočil je bilo poslanih in kako dolgo je trajalo,

da so bila procesirana. Drugače deluje sistem za spremljanje poslovnih aktivnosti, saj je

osredotočen na ostale podatke, ki jih vsebuje sporočilo, kot npr. vrednost vseh pošiljk, ki so

bila poslana na današnji dan. V Tabeli 2.3 so navedeni najbolj znani vzorci upravljanja

sistema, razdeljeni po kategorijah [4].

Tabela 2.4: Seznam vzorcev upravljanja sistema po kategorijah

Kategorije Vzorci

Spremljanje in kontroling Kontrolno vodilo (angl. Control bus), ovinek (angl.

Detour).

Opazovanje in analiza

prometa sporočil

Zgodovina sporočil (angl. Message history), shranjevanje

sporočil (angl. Message store), pameten namestnik (angl.

Smart Proxy).

Testiranje in razhroščevanje Testno sporočilo (angl. Test message), čistilec kanalov

(angl. Channel purger).


3. PROTIVZORCI

Protivzorec je nek koncept, ki opisuje pogosto uporabljeno rešitev nekega problema in

ustvari izrazito negativne posledice. Običajno je rezultat načrtovalca ali razvijalca, ki nima

dovolj izkušenj in znanja za reševanje določenega problema ali pa izbere napačen vzorec

glede na kontekst problema. Protivzorec predstavlja t. i. negativen vzorec, ki povzroča razne

prepreke pri razvoju. Protivzorci imajo torej dva namena, in sicer da identificirajo probleme in

pomagajo pri implementaciji rešitve problema. Ponujajo izkušnje mnogih v realnem svetu, ki

delujejo v industriji programske opreme in so se srečali s podobnimi ponavljajočimi se

problemi, podajo pa tudi najboljše rešitve najpogostejših problemov. Poudarjajo najpogostejše

napake in ponujajo razna orodja za prepoznavo le-teh ter določajo njihove glavne vzroke.

Poleg tega predstavljajo učinkovite ukrepe, ki jih lahko izvedemo na različnih nivojih z

namenom izboljšanja razvoja aplikacij, načrtovanja IT-sistemov in uspešnega upravljanja s

projekti programske opreme. Razlika med vzorci in protivzorci je torej v kontekstu.

Protivzorec je vzorec, uporabljen v neprimernem kontekstu. Protivzorci se delijo glede na

perspektive [7]:

Razvojni protivzorci (angl. Development antipatterns)

Obsegajo tehnične probleme in rešitve, ki jih srečajo predvsem programerji.

Arhitekturni protivzorci (angl. Architectural antipatterns)

Identificirajo in odpravljajo probleme glede strukture sistema.

Upravljavski protivzorci (angl. Managerial antipatterns)

Obsegajo procese programske opreme in organizacijo razvoja.

Izvor protivzorcev

Jezik načrtovalskih vzorcev (Design Pattern) je v trenutku navdušil programsko skupnost, k

čemur je najbolj prispevalo hrepenenje razvijalcev informacijskih rešitev po izboljšanju

kvalitete in standardov IT-industrije. Glede na vse bolj naraščajoče število projektov ni

mogoče razpravljati o notranji vrednosti in morebitni prednosti pri vpeljavi vzorcev v projekt.

Vzorci so se najprej pojavljali v arhitekturi, v IT-industriji pa so se prvič pojavili leta 1987, ko

sta Ward Cunningham in Kent Beck razvila jezik načrtovalskih vzorcev za razvoj

uporabniških vmesnikov v programskem jeziku Smalltalk [7]. V letih zatem je veliko ljudi, ki


je imelo enake ideje o uporabi načrtovalskih vzorcev, poskušalo na podoben način ter z njuno

pomočjo raziskati in razviti stvari z namenom ponovne uporabe vzorcev. V osemdesetih letih

je bilo očitno, da ni dovolj talentiranih arhitektov v objektno orientiranem razvoju programske

opreme in da bo treba to nekako spremeniti. Prav tako je vse več izkušenih zaposlenih tratilo

čas z mentorstvom drugih manj izkušenih zaposlenih, namesto da bi reševalo bolj zahtevne in

kritične probleme. Vse to je pripeljalo do vse večje potrebe po obliki ponovne uporabe, ki bo

zajela znanje izkušenih strokovnjakov in se bo lahko uporabila za ponavljajoče učenje drugih

manj izkušenih sodelavcev. Šele leta 1994 so postali načrtovalski vzorci glavna zanimivost

skupnosti razvoja programske opreme. Takrat je namreč skupina Hillside imela prvo in še

vedno legendarno konferenco o načrtovalskih vzorcih. Industrija se je na njih odzvala nadvse

pozitivno, saj so IT-strokovnjaki iz nivoja podatkovnih struktur in programskih idiomov

prestavili svojo osredotočenost na višji nivo, in sicer na arhitekturni del, in tako so izrazi, kot

so fasade, obiskovalci, adapterji, postali vse pogosteje uporabljani v razpravah na temo

snovanja programske opreme. Po letu 1994 so objave v zvezi z načrtovalskimi vzorci

eksponentno rasle, kar ima tako pozitivne kot negativne posledice. Pozitivno je to, da je bilo

vedno več vzorcev, ki so bili dokumentirani in so jih lahko arhitekti uporabljali pri razvoju

programske opreme. Negativno pa je, da mnogo ljudi, ki je uporabljalo načrtovalske vzorce,

ni dobro uvrstilo vzorca in ocenilo, v kolikšni meri je določen vzorec primeren glede na

določen kontekst in stanje aplikacije.

Leta 1996 se je prvič formalno pojavila beseda protivzorec, in sicer na konferenci »Object

World West«, kjer je Michael Akroyd imel predstavitev z naslovom »Antipatterns«.

Predstavitev je bila osredotočena na prepoznavo škodljivih konstruktov programske opreme,

ki so se ponavljajoče pojavljali skozi različne projekte. Protivzorci so torej vedno obstajali.

Rečemo lahko, da so naraven korak v razvoju vzorcev, saj jih dopolnjujejo in nadgrajujejo.

Glede na pogostost napak in neuspehe projektov lahko rečemo, da so negativne rešitve

bogatejše z raziskovalno vsebino, saj se pogosteje srečamo z napačno zasnovanimi projekti in

moramo odkriti napake, torej poiskati protivzorce ter jih odpraviti, kot pa z razvojem od

začetka, kjer lahko uporabimo vzorce glede na kontekst problema [7, 8].


3.1 Referenčni model protivzorcev

Kadar naletimo na kakšen protivzorec, je dobro imeti pravilen pristop, ki pomaga izboljšati

rešitev in odpraviti pomanjkljivosti. Ta proces sprememb, migracij in razvoja se imenuje

preoblikovanje (angl. Refactoring). Pri preoblikovanju spremenimo neko rešitev v drugo

rešitev z izboljšano strukturo, ki prinaša več prednosti. Najpomembnejša pri vzorcih je

njihova berljivost. Običajno ima vzorec dokaj obseţno dokumentacijo, čeprav je rešitev

pogosto zelo očitna in tako obširna dokumentacija sploh ne bi bila potrebna. To je moţno

zaradi uporabe referenčnega modela, ki definira konceptualno ogrodje in splošne koncepte

med vsemi vzorci. Referenčni model sestavljajo trije ključni koncepti:

Glavni vzroki (angl. Root causes)

To so napake pri razvoju programske opreme, katerih rezultat so ponesrečeni

projekti, prekoračitev sredstev oz. urnika ali neizpolnjene poslovne potrebe.

Zagotavljajo osnovni kontekst protivzorcev. Ţal so te napake zelo pogoste, saj je

kar ena tretjina projektov neuspešno prekinjenih, pet od šestih projektov je

neuspešnih [7]. Ti vzroki temeljijo na t. i. sedmih smrtnih grehih: naglica, apatija,

ozkomiselnost, lenoba, pohlep, ignoranca in ponos. Če ţelimo uspešno zaključiti

projekt, se moramo tem pastem izogibati.

Prvotne motivacije (angl. Primal forces)

Predstavljajo vidike, ki jih je potrebno upoštevati pri odločitvi. Če te vidike

pravilno naslovimo, pridobimo prednosti v projektu, v nasprotnem primeru se

pojavijo negativne posledice. So ključni motivatorji za odločitev glede izbire

protivzorca. V Tabeli 3.1 so podane stopnje vpliva glede na vrsto upravljanja,

navedene so hierarhično glede na skupnosti, na katere vplivajo [7].


Tabela 3.1: Stopnje vpliva glede na vrsto upravljanja

Vrsta

upravljanja

Globalna

industrija

Podjetje Sistem Aplikacija

Funkcionalnost nepomembno delno pomembno pomembno kritično

Zmogljivost pomembno pomembno kritično kritično

Kompleksnost pomembno kritično pomembno delno pomembno

Spremembe nepomembno kritično kritično pomembno

IT-viri nepomembno kritično pomembno delno pomembno

Prenosljivost

tehnologij

kritično pomembno pomembno delno pomembno

Nivojsko načrtovalski model (angl. Software design-level model, SDLM)

Če se lotimo razvoja kakšnega sistema nesistematično, brez celostne arhitekture,

le-ta zaradi vedno širše funkcionalnosti in nenehne potrebe po spremembah ter

dodajanja novih tehnologij postaja vedno bolj neobvladljiv. Ključna prednost

uvedbe arhitekture je ločitev različnih vidikov v posamezne rešljive elemente, kar

je na koncu veliko laţje rešljivo kot reševanje vseh problemov naenkrat. Na Sliki

3.1 imamo prikazan model, kjer je sedem arhitekturnih nivojev, ki so podani

hierarhično od najvišjega (globalno-industrijski nivo) do najniţjega (razredi in

objekti). Globalni nivo je zadolţen za koordinacijo med vsemi organizacijami, ki

med seboj sodelujejo in si delijo informacije. Podjetniški nivo je osredotočen na

komunikacijo in koordinacijo znotraj lastnega podjetja. Sistemski nivo skrbi za

komunikacijo in koordinacijo med aplikacijami. Aplikacijski nivo je osredotočen

na organizacijo aplikacij, da le-te zadoščajo merilom in zahtevam uporabnikov.

Nivo ogrodij skrbi za organizacijo in razvoj ogrodij, ki ga potrebujejo posamezne

aplikacije. Mikroarhitekturni nivo je zadolţen za razvoj programskih komponent,

ki rešujejo ponavljajoče se programske probleme. Nivo objektov in razredov pa

skrbi za razvoj objektov oz. razredov, ki jih je moţno ponovno uporabljati [7].


Slika 3.1: Model SDLM [7]

3.2 Predloge vzorcev in protivzorcev

Predloge vzorcev oz. protivzorcev omogočajo, da odgovorimo na najpomembnejša

vprašanja o posameznem vzorcu oz. protivzorcu v jeziku vzorcev, katalogu vzorcev ali

sistemu vzorcev. Brez predloge ne moremo vedeti, ali je določena rešitev opravljena z

vzorcem, saj nimamo argumentov, ki bi kazali na to, saj brez določene strukture ne moremo

reči, kaj je vzorec in kaj ne. In to zato, ker ni velikih razlik med navadno tehnično razpravo in

literaturo vzorcev. Najbolj znane predloge vzorcev so [7, 8]:

Degenerirana oblika

Poda samo avtorjevo subjektivno mnenje.

Aleksandrova forma

Sestavljena je iz treh sekcij: imena, problema in rešitve.

Minimalna predloga

Podobno kot Aleksandrova forma je sestavljena iz imena (definira enotno

terminologijo), problema (definira kontekst ter uporabnost) in rešitve (opiše

predvideno rešitev problema).


Induktivna mini predloga

Sestavljena je iz imena, konteksta, motivacij in rešitve.

Deduktivna mini predloga

Sestavljena je iz imena, problema, rešitve, moţnih koristi in posledic.

Predloga GoF – Gang of Four Pattern

Sestavljena je iz imena, klasifikacije, namena, alternativnih poimenovanj,

motivacije, uporabnosti, strukture, seznama udeleţencev, opisa sodelovanja

objektov, moţnih posledic, implementacije, vzorca kode, znane uporabe vzorca in

seznama sorodnih vzorcev.

Predloga sistema vzorcev

Sestavljena je iz imena, primera uporabe vzorca, konteksta, problema, rešitve,

alternativnih poimenovanj, strukture, dinamike objektov, rešenega primera uporabe

vzorca, variacije vzorca, moţnih posledic, implementacije, znane uporabe vzorca

in seznama podobnih vzorcev.

Predloga načrtovalskega vzorca CORBA

Sestavljena je iz imena, tipa, namena, alternativnih poimenovanj, seznama prvotnih

motivacij, uporabnosti, moţnih koristi, moţnih posledic, ozadja vzorca in seznama

podobnih vzorcev.

Prav tako obstajajo predloge protivzorcev:

Predloga psevdoprotivzorca

Podana sta samo ime in opis problema, je zelo neuporabna, saj je podan le opis

problema, ne pa tudi opis rešitve.

Mini predloga

Sestavljena je iz imena, opisa problema in opisa preoblikovane rešitve.

Celotna predloga protivzorca

Sestavljena je iz imena, alternativnih poimenovanj, uporabe v različnih nivojih

modela SDLM, imena preoblikovane rešitve, tipa preoblikovane rešitve, seznama


glavnih vzrokov, seznama neuravnoteţenih vzrokov motivacij, ozadja vzorca,

osnovne oblike, seznama simptomov in posledic, seznama tipičnih vzrokov,

seznama znanih izjem, preoblikovanih rešitev, seznama variacij, raznih primerov,

seznama podobnih vzorcev in uporabnosti protivzorca pri ostalih nivojih oz. z

drugih perspektiv.

3.3 Razvojni protivzorci

Glavni cilj razvoja protivzorcev je opisati uporabne oblike preoblikovanja programske

opreme. S preoblikovanjem modificiramo programsko kodo z namenom izboljšanja

programske strukture, da kasneje laţje nadgrajujemo in vzdrţujemo sistem. Preoblikovanje je

zelo priporočljivo ravno pred optimizacijo sistema, saj optimizacije pogosto vsebujejo

kompromise glede programske strukture. Razvojni protivzorci uporabljajo različne formalne

in neformalne pristope preoblikovanja. V nadaljevanju so našteti najbolj znani razvojni

protivzorci in opisani njihovi problemi [7, 8]:

Mehurček (angl. The Blob)

Proceduralni stil snovanja vodi do objekta, ki ima veliko preveč odgovornosti,

medtem ko drugi objekti le vsebujejo določene podatke ali izvajajo enostavne

procese.

Neprekinjena zastarelost (angl. Continuous Obsolescence)

Tehnologija se spreminja tako hitro, da imajo razvijalci pogosto teţave z

vzdrţevanjem najnovejših verzij programske opreme.

Tok lave (angl. Lava Flow)

Pri tem protivzorcu t. i. mrtva koda in pozabljeni načrtovalski podatki ostajajo v

programu. Rešitev vsebuje konfiguracijske upravljavske procese, ki eliminirajo

mrtvo kodo in s preoblikovanjem poskušajo izboljšati kakovost.

Dvoumno stališče (angl. Ambiguous viewpoint)

Modeli objektno orientirane analize in načrtovanje so pogosto opisani brez točno

definiranega stališča, ki je predstavljeno z določenim modelom. Po privzetem je to

implementacijsko stališče, ki je najmanj uporabno.


Funkcionalna razgradnja (angl. Functional decomposition)

Ta protivzorec je rezultat izkušenih neobjektno orientiranih programerjev, ki

poskušajo načrtovati in implementirati v objektno orientiranem jeziku.

Nočni duh (angl. Poltergeist)

Predstavljajo razrede, ki z zelo omejenimi vlogami in ţivljenjskimi cikli pogosto

zaganjajo procese za druge objekte. Rešitev je v ponovni dodelitvi odgovornosti za

dolgotrajnejše objekte.

Sidro (angl. Boat anchor)

To je del programske ali strojne opreme, ki za projekt nima večjega pomena in je

pogosto zelo drag.

Zlato kladivo (angl. Golden hammer)

Je znana tehnologija ali koncept, ki se dosti uporablja pri več programerskih

projektih. Rešitev je razširitev znanja razvijalcev z izobraţevanjem, da le-te

izpostavimo alternativnim tehnologijam in pristopom.

Slepa ulica (angl. Dead end)

Do t. i. slepe ulice pridemo, kadar ţelimo modificirati ponovno uporabljeno

komponento, katere ponudnik ne nudi več vzdrţevanja in podpore. Tako se delo

podpore in vzdrţevanja prenese na lastne razvijalce in podpornike.

Špagetasta koda (angl. Spaghetti code)

Struktura programa onemogoča razširitev in optimizacijo kode, pogosto so razredi

zelo veliki in imajo funkcionalnosti, ki bi morale biti v novoustvarjenem razredu.

Rešitev je v pogostem preoblikovanju kode.

Vhodna neumnost (angl. Input kludge)

Programska oprema, ki ne opravi enostavnega testa obnašanja sistema, kar se

pojavi, če so za vhode podatkov implementirani t. i. algoritmi AD HOC.

Hoja po minskem polju (angl. Walking through a minefield)

V izdanih programskih produktih najdemo številne hrošče. Poznavalci ocenjujejo,

da lahko na vrstico kode najdemo od dva do pet hroščev [7].


Programiranje izreži in prilepi (angl. Cut-and-Paste programming)

Kodo ponovno uporabljamo z navadnim kopiranjem kode, kar privede do velikih

teţav pri vzdrţevanju. Rešitev je v alternativnih vrstah ponovne uporabe, testiranju

in dokumentaciji.

Gobarsko upravljanje (angl. Mushroom management)

Razvijalci ne smejo nikoli priti v stik s končnimi uporabniki sistema, ki ga

razvijajo, saj lahko razvijejo napačen sistem.

V Tabeli 3.2 imamo primer predloge protivzorca špagetaste kode, kjer so podane nekatere

točke predloge.


Tabela 3.2: Primer predloge protivzorca špagetasta koda

Ime vzorca Špagetasta koda.

Najprimernejši nivo

modela SDLM

Aplikacija.

Rešitve preoblikovanja Preoblikovanje kode, čiščenje kode.

Tip rešitve preoblikovanja Programska.

Glavni vzroki Ignoranca, lenoba.

Neuravnotežene sile Upravljanje kompleksnosti, sprememb.

Ozadje Je klasika med programerji, še posebej med manj izkušenimi.

Splošna oblika Ima zelo malo programskih struktur (objektov, funkcij itd.).

Simptomi in posledice Minimalne povezave med objekti, redko za ponovno uporabo,

prednosti objektov so izgubljene (ni dedovanja,

polimorfizma).

Tipični vzroki Neizkušenost, ni mentorstva, ni načrtovanja, izoliranost

razvijalcev.

Znane izjeme Kadar so vmesniki skladni in je le implementacija

»špagetasta«.

Preoblikovane rešitve Najboljši način je seveda preprečevanje nastajanja takšne

kode, drugače pa s preoblikovanjem in čiščenjem kode

ohranimo skladno programsko strukturo, ki podpira razširitve.

Podobni vzorci Paraliza pri analizi (angl. Analysis Paralysis), tok lave (angl.

Lava Flow).

Primer (Zgoraj imamo

trivialni primer špagetaste

kode, spodaj pa rešitev

tega protivzorca.)

Primer špagetaste kode:

10 i = 0

20 i = i + 1

30 PRINT i; " squared = "; i * i

40 IF i >= 10 THEN GOTO 60

50 GOTO 20

60 PRINT "Program Completed."

70 END

Rešitev:

FOR i = 1 TO 10

PRINT i; " squared = "; i * i

NEXT i

PRINT "Program Completed."

END


3.4 Arhitekturni protivzorci

Arhitekturni protivzorci so osredotočeni na sistemski in poslovni nivo aplikacij in

komponent. Strokovnjaki vedno znova ugotavljajo, kako velik pomen ima arhitektura pri

programskem razvoju. Programska arhitektura je nabor celotne sistemske arhitekture, ki

vsebuje vse načrtovalske in implementacijske vidike, tudi izbiro strojne opreme in

tehnologije. Programska arhitektura se razlikuje od programiranja na več načinov. Najbolj

očitna je razlika med glavnima akterjema, torej med arhitektom in programerjem. Arhitekt

vedno upošteva stroške svojih odločitev, medtem ko programerju to ni potrebno. Programska

arhitektura je osredotočena na tri vidike programskega načrtovanja, in sicer na funkcionalno

razdelitev programskih modulov, programske vmesnike med posameznimi moduli ter izbiro

in karakteristiko tehnologije, ki se uporablja za vmesniške povezave med programskimi

moduli. Če ţelimo uporabljati takšno arhitekturo, moramo imeti na voljo veliko več

razvijalcev in vzdrţevalcev oz. morajo biti le-ti zelo izkušeni. Učinkovito upravljanje s temi

elementi predstavlja velik izziv za arhitekte, prav tako sta zelo pomembna upravljanje in

komunikacija z ljudmi. Arhitekturni protivzorci, ki jih bomo omenili v podpoglavjih, so

osredotočeni na splošne probleme in napake pri kreaciji, implementaciji ali upravljanju

arhitekture. Nezmoţnost zagotavljanja interoperabilnosti in ponovne uporabe pri povezanih

sistemih je posledično vzrok za veliko frustracij udeleţencev projekta. To lahko rešimo prav s

planiranjem izboljšane podjetniške arhitekture, kar kasneje prinaša veliko prednosti v smislu

spreminjanja in razširitve sistema. Najbolj znani arhitekturni protivzorci so [7, 8]:

Avtogeneriran dovod (angl. Autogenerated stovepipe)

Ta vzorec se pojavi, kadar migriramo obstoječi sistem v porazdeljeno infrastrukturo,

bolj točno pri pretvorbi obstoječih v razširjene vmesnike. Obstoječi vmesniki so

običajno implementacijsko specifični in bi pri večjem porazdeljenem sistemu

povzročili odvisnosti od podsistemov, prav tako lokalne operacije vsebujejo veliko

predpostavk glede lokalnih argumentov, kot so razni naslovi ali dostop do podatkov

na disku. Problem rešimo tako, da pri načrtovanju razširitve vmesnikov obstoječe

programske opreme ponovno modeliramo vmesnike, najpogosteje se to naredi z


večjim objektnim modelom, pri tem bi moral biti poudarek na interoperabilnosti med

številnimi podsistemi [7, 8].

Dovod do podjetja (angl. Stovepipe enterprise)

Glavna značilnost takšnega sistema je, da zavira spremembe. Razvidno je tudi to, da

so sistemi znotraj podjetja načrtovani neodvisno na vsakem niv

integracijski vzorci in protivzorci · vzorci predstavljajo mehanizem za učenje in reševanje...

Documents