smart telecom Smart Telecom NV Sint Jozefsstraat 14, 8850 Lendelede Academiejaar 2010-2011
Departement Toegepaste Ingenieurswetenschappen Valentin Vaerwyckweg 1, 9000 Gent
Datacheck: Service verbetering voor de zorgsector
Masterproef voorgedragen tot het behalen van het diploma van ¨ MASTER IN DE INDUSTRIELE WETENSCHAPPEN: INFORMATICA
Bert VERHELST Promotoren: Intern: Koen VAN DE WIELE Extern: Krist VANNESTE (SMART TELECOM, 8850 Lendelede)
Voorwoord Tijdens de uitwerking van dit eindwerk heb ik heel wat kunnen bijleren en realiseren. Hierbij wil ik graag de mensen bedanken die mij hebben bijgestaan. Vooreerst mijn externe promotor ing. Krist Vanneste die steeds bereikbaar was voor overleg als er een probleem opdook. Vervolgens wil ik ook mijn interne promotor ing. Koen Van De Wiele bedanken die mij bijstond voor de meer technische kant van het eindwerk. Dankzij hem is de uitwerking professioneler en generischer geworden. Ook dank ik de personeelsleden van het rusthuis Sint Franciscus te Kluisbergen die deelnamen aan het proefproject van Smart Telecom en die het voorgestelde systeem uitvoerig hebben getest. Ten slotte wil ik nog mijn ouders bedanken voor hun steun doorheen deze opleiding en mijn zus voor het zorgvuldig nalezen van dit eindwerk.
i
Abstract • Oproepafhandeling voor rust- en ziekenhuizen. Pati¨enten kunnen de hulp van een verpleegkundige vragen via een drukknopmodule bij het bed. De verpleegkundigen krijgen alle niet afgehandelde oproepen op hun smartphone te zien en kunnen deze accepteren. Bij het aannemen van een oproep wordt het overig verplegend personeel verwittigd dat deze oproep in behandeling is. Ook moet het EPD1 van de pati¨ent kunnen worden opgevraagd. • Automatische facturatie van het gebruik van de telefooncentrale. Analyseren van de CDR2 s. Uit de telefoonnummers het land afleiden, vervolgens bepalen of het een mobiele of vaste lijn betreft. Deze facturen na controle, afdrukken voor verzending of e-mailen naar de desbetreffende klanten. • WiFi3 -netwerk met verscheidene Wireless AP4 ’s automatisch configureren. Naburige AP’s moeten op verschillende frequenties uitzenden anders storen ze elkaar. Bij grotere aantallen kan de configuratie tijdrovend zijn, zeker als het gaat om meer dan ´e´en verdieping. De AP’s kunnen hun omgeving scannen, weergeven welke buren ze detecteren en op welk kanaal ze uitzenden. Aan de hand van deze informatie kan dan de optimale configuratie bepaald worden. 1 ”Elektronisch
Pati¨ enten Dossier” Data Record” bevat informatie over individuele telefoongesprekken, zoals: duur, tijdstip, kostprijs, ... 3 ”Wireless Fidelity” is de standaard draadloze technologie voor draadloze netwerken 4 ”(Wireless) Access Point” stelt draadloze toestellen in staat te communiceren met een bekabeld netwerk 2 ”Call
ii
• Call-handlingsystem for retirement homes and hospitals. Patients can request help by pressing on a buttonmodule near their bed. The nursing staff get all unhandled calls on their smartphone and they can choose the call they want to handle. When they do, the other nurses will be notified. This is indicated because the name of the nurse will appear next to the call on the phone’s display. The nursing staff must be able to request information from the electronic patient file. • Automatic invoice generation for use of the telephone exchange. Analysis of the CDR5 s: Derive the country to where a call was made from, the number and determine if the call was made to a land line or mobile phone. These invoices have to be printed or emailed after being reviewed. • Automatic configuration a WiFi-network6 with multiple Wireless APs7 . Neighbouring APs have to be configured on different frequencies in a way they don’t interfere. This can be very time consuming especially if the WiFi-network is deployed over multiple floors. The APs can scan their surroundings and detect signal strengths and corresponding frequencies of other APs. Using this information, the optimal configuration can be determinated.
5 Call
Data Record contains information about telephone calls, eg: duration, time-stamp, cost, ... 6 Wireless Fidelity is a standard wireless technology for wireless networks. 7 (Wireless) Access Point is a device that allows wireless devices to communicate with a wired network.
iii
Inhoudsopgave Voorwoord
i
Abstract
ii
Inhoudsopgave
v
Lijst van figuren
vii
Lijst van afkortingen
ix
1 Inleiding
1
2 Bestaande situatie
3
3 Behoefte analyse 3.1 Zorgsysteem . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Oproepafhandeling . . . . . . . . . . . . . . . . 3.1.2 Toegang tot het Elektronisch Pati¨enten Dossier 3.1.3 Ondersteuning van de dagelijkse rondes . . . . 3.1.4 Demo-versie . . . . . . . . . . . . . . . . . . . . 3.2 Automatisatie facturatie . . . . . . . . . . . . . . . . . 3.3 Netwerk optimalisatie . . . . . . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
5 5 5 7 7 8 8 8
4 Datacheck 4.1 Keuze technologie¨en . . . . . . . . . . 4.2 Implementatie . . . . . . . . . . . . . . 4.2.1 RS232-analyser . . . . . . . . . 4.2.2 Datacheckwebservice . . . . . . 4.2.2.1 Database . . . . . . . 4.2.2.2 Webservice logica. . . 4.2.2.3 Client proxy-klassen. 4.2.2.4 Klasse diagram . . . . 4.2.3 Datacheckmobile . . . . . . . . 4.3 Problemen tijdens implementatie . . . 4.3.1 RS232-analyser . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
10 10 12 13 18 18 20 20 21 22 25 25
iv
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
4.4
4.3.2 Datacheckwebservice . 4.3.3 Datacheckmobile . . . Resultaten . . . . . . . . . . . 4.4.1 DatacheckWebservice 4.4.2 Datacheckmobile . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
26 26 27 27 28
5 Getuse 30 5.1 implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.2 Problemen tijdens implementatie . . . . . . . . . . . . . . . . . . 34 5.3 Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6 Wificonfigurator 6.1 implementatie . . . . . . . . . . . . . . . . . . 6.1.1 Ophalen/opslaan configuratiegegevens. 6.1.2 Kanaalbepaling van de WAP’s. . . . . 6.1.2.1 Algoritmen . . . . . . . . . . 6.1.2.2 Voorbereiden graaf . . . . . . 6.1.2.3 Totaal algoritme . . . . . . . 6.2 Problemen tijdens implementatie . . . . . . . 6.3 Resultaten . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
38 38 39 40 42 53 56 56 57
7 Besluit 58 7.1 Datacheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.2 Getuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.3 Wificonfigurator . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Literatuurlijst
60
v
Lijst van figuren 2.1
4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 5.1 5.2 5.3 5.4
Bestaande hardware: communicatie tussen hulpbehoevende en verpleegkundige . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vergelijk tussen JDBC (sql) en Hibernate (ORM / HQL) . . . . Datacheck Hardware . . . . . . . . . . . . . . . . . . . . . . . . . Solderingsschema voor een RS232-monitor kabel . . . . . . . . . Input stream van de drukknoppencentrale tijdens oproep vanuit kamer 41 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Omzetten van RS232-bitstream naar berichten in database . . . Klasse diagram van de RS232-analyser. . . . . . . . . . . . . . . Entity relationship diagram van de database voor Datacheck. . . Klasse diagram van de Datacheck webservice. . . . . . . . . . . . Flowdiagram dat de werking van Datacheckmobile weergeeft. . . Klasse diagram van Datacheck mobile op Symbian. . . . . . . . . Programma mist ´e´en karakter en alle berichten zijn foutief. . . . Aanmeldingsscherm bij opstarten. . . . . . . . . . . . . . . . . . Overzicht van enkele oproepen. . . . . . . . . . . . . . . . . . . . Overzicht van de afhandelingscategorie¨en. . . . . . . . . . . . . . Toevoegen van een suggestie. . . . . . . . . . . . . . . . . . . . . Overzicht dat toegang biedt tot de verschillende hoofdpunten van Datacheck mobile. . . . . . . . . . . . . . . . . . . . . . . . . . . Overzicht van recente medicatie van een pati¨ent. . . . . . . . . . Overzicht van de medische geschiedenis van een pati¨ent. . . . . .
3 11 13 14 15 16 17 19 21 23 24 26 28 28 28 28 29 29 29 30 31 33
5.7
Overzicht van GetUse. . . . . . . . . . . . . . . . . . . . . . . . . Reguliere expressie voor mobiele nummers in Belgi¨e. . . . . . . . Klasse diagram van het Getuse facturatie programma. . . . . . . Finite state automaat die telefoonnummers analyseert voor Belgi¨e en Nederland. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grafische interface van het facturatieprogramma Getuse. . . . . . Grafische interface van het wachtwoorden-genererend-programma Pingen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grafische interface van het XML-beveiligingsprogramma Secset. .
6.1
Klasse diagram van het Wificonfigurator programma. . . . . . . .
39
5.5 5.6
vi
35 36 37 37
6.2 6.3 6.4 6.5 6.6
Overzicht van de Wificonfiguratoropstelling . . . . . . . . . . . . Model van de graaf met gekleurde knopen en interferentie . . . . Eerste vier niveaus van de mogelijke kleuringen van de boom . . Volgorde van knopen aflopen bij “Diepte Eerst Zoeken”. . . . . . Splits graaf en bereken de twee delen apart met de grensknopen in beide delen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 Pseudo code voor het Kerninghan-Lin algoritme. . . . . . . . . . 6.8 Drie iteraties om de verst uiteenliggende knopen en de diameter te vinden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9 BEZ methode met wachtrij grootte = 3. . . . . . . . . . . . . . . 6.10 Splitsen van een graaf met “Diepte eerst zoeken”. . . . . . . . . . 6.11 Reduceren graaf door alle knopen met maximum twee buren te verwijderen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.12 Grafische interface om de WAP-configuratie in te stellen. . . . . .
vii
41 42 43 44 46 48 50 52 54 55 57
Lijst van afkortingen AP
”(Wireless) Access Point” stelt draadloze toestellen in staat te communiceren met een bekabeld netwerk
ii, iii, 8, 9, 38– 42, 56, 57, 59
BEZ
”Breedte Eerst Zoeken” is een techniek om alle knopen in een boom te doorlopen. Alleen worden de knopen met deze techniek niveau per niveau overlopen i.p.v. verticaal bij DEZ.
56
CDR
”Call Data Record” bevat informatie over individuele telefoongesprekken, zoals: duur, tijdstip, kostprijs, ...
ii, 8, 30, 31, 33
DECT
”Digital Enhanced Cordless Telecommunications” is een standaard voor digitale draadloze telefoons ”Diepte Eerst Zoeken” is een techniek om alle knopen in een boom te doorlopen. Hierbij start men bij de bovenste knoop (de wortel), men kiest een tak en doorzoekt deze zo ver mogelijk zonder terug te keren op zijn stappen.
3–5, 12, 13, 15 43, 53
EPD
”Elektronisch Pati¨enten Dossier”
ESPA
”European Selective Paging Association”
ii, 1, 7, 12, 18, 28 6
GUI
”Graphical User Interface”
12, 25
HQL
”Hibernate Query Language” heeft hetzelfde doel als SQL, maar werkt met objecten i.p.v. met tabellen ”Hypertext Transfer Protocol” is een netwerk protocol dat de communicatie tussen een webclient (meestal een browser, hier datacheckmobile) en een webservice voorziet.
20
DEZ
HTTP
viii
39, 40
IDE
11, 12, 27
IP
”Integrated Development Environment” is een programma, dat de ontwikkeling van software ondersteunt, zoals: Qt, Netbeans, Eclipse, ... ”Internet Protocol”
JDBC
”Java DataBase Connectivity”
30
ME
”Micro Edition” is een Java versie ontworpen voor embedded computers, zoals bijvoorbeeld GSM
27
ORM
”Object Relational Mapping” voorziet een framework om relationele tabellen in een database om te zetten naar objecten in een programma en omgekeerd.
10
PDF
”Portable Document Format”
8, 33
regexp
34, 35
RESTful RS232
”Reguliere Expressie” is een manier om patronen te beschrijven waarmee een computer tekst kan herkennen. ”Representational State Transfer” ”Recommended Standard 232”
SOAP
”Simple Object Access Protocol”
SSID
”Service Set IDentifier” is een naam die een draadloos netwerk identificeert.
UML
”Unified Modeling Language”
16
VoIP
”Voice over IP” geeft aan dat telefoongesprekken over internet worden verstuurd.
8, 30, 34, 35
WEP WiFi
9 ii, 4, 5
WPA WSDL
”Wired Equivalent Privacy” ”Wireless Fidelity” is de standaard draadloze technologie voor draadloze netwerken ”Wi-Fi Protected Access” ”Web Service Definition Language” bepaalt in een gestandaardiseerd formaat welke methodes opgeroepen kunnen worden in een webservice en welk formaat de objecten hebben die verkregen worden.
XML
”Extensible Markup Language”
ix
8
10 6, 14
32,
13,
10, 18, 25 9
9 20, 22, 27
33, 34
Hoofdstuk 1
Inleiding Kwaliteitsmanagement heeft de laatste jaren voor een enorme productie- en kwaliteitsverhoging gezorgd. Dit wordt enerzijds mogelijk gemaakt door een nauwgezette rapportering van problemen en fouten en anderzijds door een grondige evaluatie ervan anderzijds. In rusthuizen en des te meer in ziekenhuizen is dit een zeer belangrijk onderwerp. Er komen nog te vaak gevallen van verkeerde medicatietoediening voor. Dit heeft dikwijls te maken met communicatieproblemen. De Europese Unie heeft enkele studies laten uitvoeren[3] rond eHealth en zal in de toekomst een richtlijn uitschrijven die de zorgsector verplicht om voor alle oproepen van pati¨enten de reden en de genomen acties bij te houden. Omdat het huidige oproep systeem in vele rust- en ziekenhuizen veroudert geraakt, wil Smart Telecom een up-to-date systeem ontwikkelen. Dit systeem moet het bestaande oproepafhandelingssysteem vervangen en verbeteren, en ook extra functionaliteiten voorzien zoals toegang bieden tot het EPD1 . Voor de ontwikkeling van dit systeem zal voornamelijk op gebruiksvriendelijkheid, stabiliteit en uitbreidbaarheid gelet worden. Kwaliteitsmanagement wordt ook vaak om een andere reden ingevoerd, namelijk omwille van kostenbesparing. Door het personeel beter te ondersteunen haalt deze een hogere productiviteit en kan meer omzet gehaald worden met eenzelfde personeelsbestand. Het is dan ook interessant om te investeren in automatisatieprogramma’s. De ontwikkeling hiervan is een grote investering maar heeft gelukkig een korte terugverdientijd. In dit kader wil Smart Telecom een geautomatiseerde oplossing voor deze problematiek aanbieden. Enerzijds neemt facturatie veel tijd in beslag. Al dit zou kunnen geautomatiseerd worden, zal dit tot een grote kostenbesparing leiden voor het bedrijf. Verder reduceert dit de kans op menselijke fouten die het bedrijf veel geld kunnen kosten. 1 ”Elektronisch
Pati¨ enten Dossier”
1
Anderzijds is het configureren van een draadloos netwerk zeer tijdrovend. Ook dit zal geautomatiseerd worden. Hierdoor kan de installatie kost verlaagd worden wat de concurrentie positie van Smart Telecom verbeterd. Bij dit onderdeel wordt stabiliteit en gebruiksvriendelijkheid gewaardeerd. Deze drie onderdelen hebben onrechtstreeks met elkaar te maken. De verpleegkundigen kunnen met hun smartphone waarop het eerste onderdeel (Datacheck) draait, ook naar elkaar bellen. Externe gesprekken worden gefactureerd met behulp van het tweede onderdeel (Getuse). Deze smartphones werken over een Wifi-netwerk, dat geconfigureerd wordt door het derde onderdeel (Wificonfigurator).
2
Hoofdstuk 2
Bestaande situatie In de rust- en ziekenhuizen is er een oproep-afhandelingssysteem aanwezig. In elke kamer is er voor de pati¨ent een drukknoppenbediening voorzien. Deze wordt door de patient gebruikt als hij hulp nodig heeft. Elke bediening is aangesloten op de server. Deze verwerkt de signalen en stuurt dan berichten naar een DECT1 -centrale. Deze stuurt de berichten over het DECT-netwerk naar een DECT-telefoon van een verpleegkundige. Deze krijgen dan de oproep en het bijhorende kamernummer te zien.
server lokaal
bij verpleegsters
DECT telefoons
DECT server
kamer van de patiënt
drukknoppen server
drukknoppen
draadloos OXYGEN
OXYGEN
Figuur 2.1: Bestaande hardware: communicatie tussen hulpbehoevende en verpleegkundige Bij het aannemen van een oproep dient de verpleegkundige bij het binnenkomen van de kamer het oproepsignaal te stoppen (aparte drukknop). Zoniet blijft de oproep ook actief op de andere telefoons. Indien de verpleegkundige op een derde knop drukt wordt er een assistentieoproep verstuurd. Daarmee vraagt de verpleegkundige om assistentie. Die functie wordt enkel in noodgevallen gebruikt en krijgt dus een hogere prioriteit. 1 ”Digital Enhanced Cordless Telecommunications” is een standaard voor digitale draadloze telefoons
3
De verpleegkundigen kunnen intern communiceren met elkaar via de DECTtelefoons en kunnen ook externe gesprekken ontvangen die hen doorgeschakeld worden vanuit de receptie. Het DECT-netwerk is vrij gelijkaardig aan een WiFinetwerk.
4
Hoofdstuk 3
Behoefte analyse 3.1
Zorgsysteem
Dit onderdeel moet het bestaande oproepafhandelingssysteem vervangen en de functionaliteiten ervan uitbreiden. Dit moet zorgen voor een snellere en meer kwaliteitsvolle service. Verder moet het menselijke fouten reduceren en alle genomen acties bijhouden in een logboek. Dit onderdeel moet uitgewerkt worden op smartphones van de verpleegkundigen, maar er moet ook een versie voor een desktop-pc gecre¨eerd worden als back-up, mocht het WiFi-netwerk uitvallen. De drie functionaliteiten die dit onderdeel moet voorzien, zijn:
3.1.1
Oproepafhandeling
Het huidige oproep-afhandelingssysteem met DECT-toestellen is veroudert en heeft enkele tekortkomingen: • Bij ontvangen van oproepen van de pati¨enten kan je slechts ´e´en oproep tegelijkertijd zien. • Een oproep kan worden beantwoord door meerdere verpleegkundigen. Er is geen co¨ ordinatie ingebouwd in het systeem om ervoor te zorgen dat slechts ´e´en verpleegkundige een oproep beantwoord. • Het systeem werkt slechts in ´e´en richting: van de server naar de clients toe. Client kunnen geen informatie doorgeven voor een betere co¨ordinatie. • De DECT-telefoons kunnen enkel het kamernummer tonen. Geen verschillende prioriteiten of andere nuttige informatie. Het nieuwe systeem moet als volgt werken. Wanneer er een pati¨ent een oproep doet via de drukknopmodule in zijn kamer, moet dit verschijnen op de smartphones van de verpleegkundigen. Dit kan door de signalen, die verstuurd worden tussen de drukknoppen-server en de DECT-centrale op te vangen en door te sturen naar de smartphones. Deze berichten worden verstuurd over een 5
RS2321 -kabel m.b.v. het ESPA2 4.4.4 protocol. Het formaat van deze berichten moet kunnen vastgelegd worden via de database van het systeem. Dit zorgt ervoor dat het systeem kan werken met verscheidene oproepsystemen. Van iedere oproep wordt volgende info opgeslagen: • het tijdstip (datum + tijdstip) • het kamernummer • de locatie binnen de kamer (sanitair of normaal) • de prioriteit (zie verder) Deze informatie moet ook zichtbaar zijn op de smartphones van de verpleegkundigen. Verder moet de verpleegkundige een oproep kunnen aannemen en moet bij deze actie een verwittiging gestuurd worden naar de rest zodat slechts ´e´en verpleegkundige per oproep reageert. Dit verhoogt de productiviteit. Ook moeten de verschillende prioriteiten van de oproepen zichtbaar zijn op de smartphones: 1. Normale prioriteit (groen): dit is een oproep van een pati¨ent. De verpleegkundigen kunnen deze best inschatten uitgaande van het verleden van de pati¨ent. 2. Hoge prioriteit (oranje): dit is een assistentie-oproep. Verpleegkundigen, bezig met niet-kritische zaken, geven assistentie. 3. Hoogste prioriteit (rood): dit zijn de automatisch gegenereerde oproepen. Hieronder vallen het brandalarm, hartslagmeter, ... . De verschillende prioriteiten krijgen een specifiek geluidssignaal wanneer ze door de smartphones worden ontvangen. Dit zorgt ervoor dat de verpleegkundigen de prioriteit van een nieuwe oproep horen, zonder het scherm te moeten bekijken. Als een oproep wordt aangenomen moet deze ook worden afgehandeld. Bij het bepalen van de genomen acties moet, waar mogelijk, het intypen van tekst vermeden worden. Dit om de workflow te versnellen en frustratie te vermijden bij mensen die niet zo vertrouwd zijn met gegevensinvoer op een smartphone. Het bepalen van de acties gebeurt d.m.v. een reeks vragen, die kunnen geconfigureerd worden door de hoofdverpleegkundige via een configuratieprogramma. Dit programma moet volgende functionaliteiten ondersteunen: • Aanpassen vragenlijst bij afhandelen van een oproep. • Bekijken en toevoegen van vragen die door de verpleegkundigen worden voorgesteld. • Mobiele toestellen activeren/deactiveren (van belang bij diefstal). 1 ”Recommended 2 ”European
Standard 232” Selective Paging Association”
6
• Toelaten/weigeren inloggen personeelsleden al dan niet tijdsafhankelijk (bij ontslag). • Het formaat van de oproepen, zoals ze vanuit de drukknoppen-server, worden verstuurd, aanpassen. • Bekijken van statistieken zoals: gemiddelde oproep-afhandelingsduur per personeelslid, aantal valse oproepen per pati¨ent, trends in eetgewoonten van het pati¨entenbestand, ... Dit programma mag enkel toegankelijk zijn voor de hoofdverpleegkundigen en wordt op hun desktopcomputer ge¨ınstalleerd. De vragenlijst bij afhandeling wordt opgesplitst in verschillende categorie¨en zodat de juiste vraag sneller kan worden beantwoord. Alle antwoorden worden bijgehouden in de database van Smart Telecom en worden zover mogelijk terug in het EPD ingebracht. De afhandeling kan ook verschillen naargelang de prioriteit. Zo is het bij een assistentieoproep niet nodig dat beide verpleegkundigen de afhandeling van de oproep in het systeem inbrengen.
3.1.2
Toegang tot het Elektronisch Pati¨ enten Dossier
Aangezien het nieuwe systeem tweerichtingsverkeer ondersteunt kan er ook informatie via de clients worden opgevraagd. Dit maakt het mogelijk het mogelijk om raadplegingen van het EPD te doen via de smartphones. Dit kan nuttig zijn om ondermeer: • Snel contactgegevens van naasten op te vragen. • Een medische tijdslijn op te vragen die de gezondheidstoestand van de pati¨ent weergeeft. • Een tijdslijn weer te geven met recent toegediende medicatie. • De verantwoordelijke artsen voor een bepaalde pati¨ent op te vragen. • ...
3.1.3
Ondersteuning van de dagelijkse rondes
Ten slotte moet Datacheck de verpleegkundigen ondersteunen tijdens hun dagelijkse ronde. De verpleegkundige geeft aan in welke kamer hij/zij zich bevindt en dan toont het systeem een lijst met taken die afgewerkt moeten worden. Elke taak dient afgevinkt te worden. Dit zorgt voor een hogere kwaliteit van de dienst en vermindert de kans op vergeten- of foutieve behandelingen.
7
3.1.4
Demo-versie
Dit programma is een dummy3 van de client op de smartphones van het Datacheck systeem. Het zal worden gebruikt door Smart Telecom bij verkoopsgesprekken waar de connectie met de server onhandig is. De database connectie moet dus worden vervangen door een programma-klasse die de database simuleert. Zodoende worden een aantal dummy oproepen gegenereerd telkens het programma opstart, en deze worden vervolgens op normale wijze afgehandeld.
3.2
Automatisatie facturatie
Dit programma zal de facturen genereren voor de telefooncentrale die geplaatst wordt in een rust- of ziekenhuis. Ze werkt met VoIP4 . Met deze centrale is het mogelijk om binnen het lokale netwerk kosteloos te bellen (interne gesprekken). Externe gesprekken zijn ook mogelijk maar daarvoor is een VoIP-provider vereist. Deze zorgt ervoor dat de gesprekken zover mogelijk over internet worden verstuurd en net voordat ze hun bestemming bereiken, worden ze terug op het normale telefoonnetwerk gezet. Hierdoor heeft de ontvanger geen VoIP apparatuur nodig en zijn gesprekken in binnen- en buitenland heel wat voordeliger dan over het normale telefoonnetwerk. Het facturatieprogramma heeft de gespreksgegevens nodig van alle externe gesprekken. Deze worden gelukkig bijgehouden door de VoIP-provider. Uit de CDR’s kan de informatie opgehaald worden om facturen op te stellen. De functionaliteit van dit onderdeel bestaat uit: • Inlezen en analyseren van de CDR’s; • Toevoegen en aanpassen van klanten; • Genereren van facturen in PDF5 - en Excel formaat; • Versturen van facturen naar e-mailadressen van klanten of, indien gewenst, deze af te drukken.
3.3
Netwerk optimalisatie
Dit programma is een configuratie-tool die alle variabelen van een AP instelt. Dit programma zal enkel gebruikt worden binnen Smart Telecom. Het programma gaat als volgt te werk: 1. Als input krijgt het de IP6 -adressen van alle AP’s in het netwerk met hun wachtwoord (gelijk voor alle AP’s). 3 Met dummy wordt een versie van het programma bedoeld dat ogenschijnlijk dezelfde functionaliteit biedt als zijn tegenhanger, maar achter de schermen anders/eenvoudiger in elkaar zit om welke reden dan ook. 4 ”Voice over IP” geeft aan dat telefoongesprekken over internet worden verstuurd. 5 ”Portable Document Format” 6 ”Internet Protocol”
8
2. Vervolgens voert het programma een scan uit op iedere AP. Deze scan geeft alle buren weer waarvan de AP signaal opvangt, elk met hun respectievelijke signaalsterkte. 3. Voor een goede ontvangst doorheen het hele gebouw moeten alle naburige AP’s op een apart kanaal gezet worden. Helaas zijn er van de dertien kanalen slechts drie die niet met elkaar interfereren. Alle AP’s moeten dus een kanaal- en zendsterkte toegewezen krijgen, die ervoor zorgt dat er overal dekking is en toch de interferentie tot een minimum beperkt. Het berekenen van de configuratie is niet tijdkritisch zolang deze binnen aanvaardbare normen (enkele uren) blijft. 4. Verder moeten er ook nog enkele globale variabelen worden ingesteld, zoals: • SSID7 • Wachtwoord om toegang te krijgen tot het netwerk • Beveiligingstype (vb: WEP8 ,WPA9 ,WPA2) • Tijdzone • ... 5. Toon een visualisatie van de gekozen configuratie (optioneel).
7 ”Service
Set IDentifier” is een naam die een draadloos netwerk identificeert. Equivalent Privacy” 9 ”Wi-Fi Protected Access” 8 ”Wired
9
Hoofdstuk 4
Datacheck De implementatie van de nieuwe versie van het oproepafhandelingssysteem wordt hier uitgelegd.
4.1
Keuze technologie¨ en
De RS232-analyser geprogrammeerd in Java om platformonafhankelijkheid te behouden. Dit is van belang aangezien dit onderdeel vaak in testfase eerst uitgevoerd wordt op een test computer en daarna pas op de server wordt geplaatst. Deze hebben niet perse hetzelfde besturingssysteem. De Datacheckwebservice wordt geschreven in het SOAP1 -framework. Hier wordt gekozen voor SOAP, aangezien deze meer mogelijkheden biedt dan een RESTful2 -webservice en omdat de clients toch genoeg rekenkracht3 bezitten om de SOAP-berichten te parsen4 . Verder heeft SOAP krachtigere beveiligingsmechanismen en kan het verzekeren dat berichten op bestemming geraken (Reliable Messaging). De interactie met de database zal gebeuren d.m.v. een ORM5 architectuur, namelijk Hibernate6 . Dit om het programma overzichtelijker te houden en toekomstige uitbreidingen te versnellen. Zie de vergelijking in figuur 4.1 1 ”Simple
Object Access Protocol” State Transfer” 3 de gebruikte Symbian smartphones hebben een 434 MHz processor en de android phones een 1GHz processor 4 parsing of ook wel syntax analyse, is het analyseren van een tekst of bitstream om de structuur ervan te achterhalen. 5 ”Object Relational Mapping” voorziet een framework om relationele tabellen in een database om te zetten naar objecten in een programma en omgekeerd. 6 Hibernate is een ORM-platform voor Java 2 ”Representational
10
JDBC (SQL)
Hibernate (ORM, HQL)
De ontwikkelaar moet zelf de mapping tussen kolommen en object variabelen schrijven
Dit kan bijna XML formaat (of
via mapping-files in es)
Kan database specifieke SQL-opdrachten gebruiken in query’s Bij aanpassingen aan de database of aan de objecten moet de mapping herschreven worden op alle plaatsen waar deze tabellen/objecten werden gebruikt
HQL is een database-
Caching6 is de verantwoordelijkheid van het programma en moet zelf geschreven worden
Hier kan auto bij een query de objecten in een cache gestoken worden zodat ze in het vervolg sneller kunnen worden opgevraagd.
ke taal
Bij aanpassingen moeten één keer de beïnvloede XML-mapping-files aangepast worden
Efficiënter in het algemeen maar ook efficiënter in het verwijderen in bulk en maken van een join tussen twee tabellen. he type conversie tussen types die in het programma gebruikt worden en in de database Overzichtelijker, alle mapping in afzonderlijke mapping-files
Figuur 4.1: Vergelijk tussen JDBC (sql) en Hibernate (ORM / HQL) Bij Datacheckmobile koos Smart Telecom voor Android en Symbian als besturingssystemen voor de smartphones. Op deze twee platformen moet dezelfde functionaliteit beschikbaar zijn en zoveel mogelijk dezelfde gebruikerservaring. • Android Het Android besturingssysteem is gecre¨eerd als opensourceproject door Google. In vergelijking met Symbian is het een vrij jong besturingssysteem. Op Android wordt geprogrammeerd in Java-syntax7 . Als IDE8 is er gekozen voor Eclipse, aangezien dit ondersteund wordt door Google d.m.v. een plug-in. Alle documentatie is aan de hand van Eclipse uitgelegd. • Symbian 6 Caching is de techniek waar data lokaal wordt opgeslagen zodat ze bij toekomstige aanvragen sneller toegankelijk wordt. Het vermindert ook het netwerkverkeer en verhoogt de responssnelheid. 7 Dit is geen echte Java, maar enkel dezelfde syntax met een andere back-end om kosten aan SUN (Oracle) te vermijden. 8 ”Integrated Development Environment” is een programma, dat de ontwikkeling van software ondersteunt, zoals: Qt, Netbeans, Eclipse, ...
11
Het Symbian besturingssysteem is ontworpen door Nokia9 . Als ontwikkelingstaal voor dit platform kan men kiezen uit: C++, Java, Assembler, C, OPL, Web/WAP scripting, ... Hier werd als programmeer-omgeving gekozen voor Qt (C++ als taal) omdat ze een goede ondersteuning biedt bij ontwikkeling van GUI10 ’s op dit platform. Qt is ook ontwikkeld door Nokia en is ontworpen om zoveel mogelijk onafhankelijk te zijn van de gebruikte taal en van het platform waarvoor geprogrammeerd wordt. Vrij recent (maart 2011) is het Qt platform geport11 naar Android. Misschien kan de C++ code van de Symbian versie van Datacheck ook gecompileerd worden voor Android. De Datacheckconfigurator zal ge¨ımplementeerd worden in Java gezien dit op verschillende computers moet ge¨ınstalleerd worden en Java platform onafhankelijk is. Er wordt gebruik gemaakt van Netbeans als IDE. Ten slotte wordt de Datacheckdummy op ´e´en van de twee mobiele platformen naar het einde toe uitgewerkt. De reden hiervoor is dat de functionaliteit identiek moet zijn aan die van de volwaardige programma’s zonder de connectie met de server. Indien de programmeur een goede stijl aanhoudt kan deze dummy volledig verwezenlijkt worden door enkel de datalaag te herschrijven.
4.2
Implementatie
Datacheck heeft drie functionele toepassingen: 1. Overbrengen van de berichten van de drukknoppenbediening in de kamers van de pati¨enten naar de smartphones. 2. De verpleegkundigen ondersteunen bij hun dagelijkse ronde. Welke acties in iedere kamer moeten ondernomen worden. 3. Informatie uit het EPD opvragen. Bijvoorbeeld: recente medicatie, contactgegevens van naasten, ... maar ook toevoegingen doen, zoals: opmerkingen over de pati¨ent noteren, maaltijd voorkeuren vastleggen, ... De implementatie gebeurt in 3 fasen: 1. Oproep-afhandeling naast bestaande DECT-infrastructuur. 2. Oproep-afhandeling en opvragingen uit het EPD. 3. Pas in de laatste fase wordt het DECT-systeem weggenomen. 9 Eigenlijk door: Nokia , Ericsson, Panasonic en Samsung. Oorspronkelijk ook door Motorolla en PSion. Nu wordt het echter hoofdzakelijk nog gebruikt door Nokia. 10 ”Graphical User Interface” 11 Porting, het proces van software aanpassen zodat deze compatibel wordt met andere besturingssystemen en/of hardware architecturen.
12
DECT telefoons
DECT server
drukknoppen server
OXYGEN
drukknoppen
OXYGEN
RS232 Analyser Databank
Database
Electronisch Patiënten Dossier
Datacheck
Configuratie programma
Datacheck
Datacheck WebService
DatacheckMobile
DatacheckDesktop
OXYGEN
Figuur 4.2: Datacheck Hardware De implementatie die Datacheck op de smartphones mogelijk maakt, is eigenlijk een keten van programma’s, die de noden van de pati¨ent naar de verpleegkundigen moet overbrengen. De keten start bij de RS232-analyser, die de berichten omzet van een stream, afkomstig uit de drukknoppen-centrale, naar aanroepen in de webservice. Deze laatste slaat de gegevens op in een database. De smartphones “pollen”12 de webservice herhaaldelijk naar updates. Elk nieuw bericht wordt doorgestuurd naar de smartphones en wordt aldus zichtbaar voor de verpleegkundigen.
4.2.1
RS232-analyser
In de eerste fase van de uitvoering van datacheck moest het DECT gedeelte blijven werken. Dus moet de DECT centrale nog steeds berichten kunnen ontvangen van de drukknoppen-centrale. De uitwisseling van data moet afgeluisterd worden zonder deze te verstoren. Hiervoor is een RS232-monitor-kabel[4] nodig. Deze moet slechts half duplex zijn aangezien het programma enkel ge¨ınteresseerd is in data afkomstig van de drukknoppen-centrale. Deze kabel kan volgens onderstaand schema gefabriceerd worden. 12 polling duidt op de activiteit van herhaaldelijk opvragen van de status van een extern toestel of gegevensdrager door een client-programma.
13
8 9
1
2
2
3
3
4
4
5
5
diode 1N4148
weerstand 2.2K
5 4 3 2 1
6 7 8 9
9 8 7 6
DECT-centrale mannelijke
7
1
RS232-analyser vrouwlijke
Drukknoppen centrale vrouwlijke
6
Figuur 4.3: Solderingsschema voor een RS232-monitor kabel Het programma zelf krijgt dan, met behulp van een RS232-package13 , de bitstream binnen. Deze reeks bevat een hele reeks niet afdrukbare karakters. Indien deze wordt bekeken met een geavanceerde tekstverwerker14 , wordt de betekenis duidelijk: ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ2ACK ! SYN STX51 NOR K041 DLE RS® ACK DLE ETB ENQ2ACK ! SYN STX52 NOR K041 DLERS¯ ! SYN STX52 NOR K041 DLERS¯ ACK DLE ETB ENQ1NAK STX NAK ETX ENQ1 !&EOT51 DLERS± ACK DLE ETB ENQ1NAK ETX ENQ1 !&EOT52 DLE RS² ACK DLE ETB ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ1NAK ETX ENQ2ACK ! SYN STX53 NOR K041 DLERS° ACK DLE ETB ENQ2ACK ! SYN STX54 NOR K041 DLE RS± ! SYN STX54 NOR K041 DLE RS± ACK DLE ETB ENQ1NAK STX NAK ETX
Figuur 4.4: Input stream van de drukknoppencentrale tijdens oproep vanuit kamer 41 Op de eerste regel duiden de enen op een normale situatie. Indien de DECTcentrale een bepaalde tijd geen antwoord geeft, zal dit veranderen naar tweetjes. Andere herkenbare gegevens zijn: 13 RXTX is een native bibliotheek die seri¨ ele en parallelle communicatie voorziet voor Java: http://users.frii.com/jarvi/rxtx/ 14 In dit geval werd Notepad++ gebruikt
14
• Het kamernummer: 41. • Het type van de oproep: normaal(NOR), sanitair-(SAN), verpleegpost(VP), assistentie-oproepen(ASS) en brandalarm(BRAND). • De DECT-telefoonnummers (staan voor iedere oproep: 51,52,53,...). Deze worden niet opgeslagen. Al deze informatie is van belang voor Datacheck en wordt dus via een webservice opgeslagen in een database. Waarom dit via een webservice gebeurt, wordt verderop uitgelegd: 4.2.2.2. Omdat iedere bit belangrijke informatie kan bevatten, moet de verwerking kunnen volgen met de verzendingssnelheid van de bits. Om dit te verzekeren werden extra buffers ingebouwd tussen de ontvangst van de karakters en de verwerking ervan. Dit gebeurt volgens het onderstaande schema:
15
RS232 port
Read and store in buffer
Buffer
Read char from buffer
char = START_MESSAGE_ CHAR?
No
building message?
No
Drop char
Yes
Yes - drop message - make new message - add char
Add char to current message
message length = MAX_SIZE?
No
Yes get matchingpatterns from database
Analyse message
Found match?
No
Drop message
Yes Add to database
Figuur 4.5: Omzetten van RS232-bitstream naar berichten in database De buffer zorgt ervoor dat geen bits verloren gaan als de verwerking van de vorige bit meer tijd zou vergen dan beschikbaar. Het formaat van de berichten kan met een reguliere expressie in de database worden vastgelegd. Bij de start 16
van de RS232-analyser worden deze patronen ingeladen en vooraf gecompileerd, waardoor de herkenning zo effici¨ent mogelijk gebeurt. Het mechanisme werkt met een start-karakter, waarop een bericht volgt van maximaal MAX SIZE15 karakters. Dit mechanisme wordt verder besproken bij 4.5. Ten slotte wordt het UML16 -schema nog vermeldt. 15 MAX SIZE is een constante die in het programma wordt vastgelegd. Deze bevat de maximale bericht lengte. 16 ”Unified Modeling Language”
17
gui
message
Main
Message
-txtConsole : JTextPane -scroll : JScrollPane -null : MessagePrinter -client : HttpClient -method : GetMethod -LINK : String = "http://localhost:8080/DatacheckWeb_1/addCall?call=" -sc : StyleContext = StyleContext.getDefaultStyleContext()
-message : String -time : int +Message(message : String, time : int) +compareMessage(message : String) : boolean +decreaseTime(period : int) : boolean Reciever
-Main() +connect() : void +showMessage(message : String) : void +clear() : void +addLetter(letter : int) : void +addError(text : String) : void -append(s : String, c : Color) : void +run() : void +main(args : String []) : void
~in : InputStream +Reciever(in : InputStream) +run() : void
MessageExtractor
1
-queue : ArrayBlockingQueue
= new ArrayBlo... +logger : Logger = Logger.getLogger("rs232") +MAX_MESSAGE_SIZE : int = 19 -messageInConstruction : StringBuilder -messageLength : int = -1 -messagePatterns : ArrayList<java.util.regex.Pattern> -replacePatterns : ArrayList<String>
1 MessagePrinter -console : JTextPane ~scroll : JScrollPane -sc : StyleContext = StyleContext.getDefaultStyleContext() +MessagePrinter(owner : JFrame) +addText(text : String) : void +addError(text : String) : void -append(s : String, c : Color) : void +clear() : void
+MessageExtractor() +run() : void -GetCharFromQueue() : int +add(letter : int) : void
database
ConfigurationConstants
DatabaseConnector -DatabaseConnector() +getConnection() : Connection +getMessageFormats() : ArrayList<String[]> +logMessage(stream : String, message : String) : void
Figuur 4.6: Klasse diagram van de RS232-analyser. Hier worden enkele van de belangrijkste klassen beschreven: • Reciever: Deze klasse ontvangt de karakters, afkomstig van de drukknoppencentrale. Deze slaat hij op in een buffer (wachtrij) in de klasse MessageExtractor. Wanneer deze klasse een bericht (Message) herkent zal hij dit via de DataConnector in de database opslaan. • De overige klassen dienen om de berichten ook te tonen op het scherm 18
voor debug doeleinden.
4.2.2
Datacheckwebservice
Het volgende onderdeel is de webservice. Deze vormt het centrale deel van Datacheck. Hij ontvangt berichten van de RS232-analyser en slaat ze op in de database. Hij regelt ook de communicatie tussen de clients en wisselt de gegevens uit met het EPD. Het ontwerpen van de webservice verloopt in verschillende stappen: • Het ontwerp van de MySQL-database. • Mapping17 van de database tabellen naar objecten m.b.v. Object Relational Mapping. • Het ontwerpen van de webservice-logica en de interface voor de clients m.b.v. SOAP[5]. • Het genereren van de proxy klassen voor de clients. 4.2.2.1
Database
Het ontwerp van de MySQL-database: 17 Data mapping is het bepalen van de regels om van de ene datastructuur over te kunnen gaan naar een andere.
19
Figuur 4.7: Entity relationship diagram van de database voor Datacheck. Hier worden enkele van de belangrijkste databasetabellen beschreven • staffmember: deze tabel bevat alle verpleegkundigen die met de smartphones moeten werken. Hier wordt ook hun login gegevens bewaard. • callalert: hierin komen alle nieuwe oproepen die gedetecteerd worden door de RS232analyser (de tabel heet “callalert” aangezien call een gereserveerd woord is in MySQL). • callfinished: als een oproep afgehandeld is wordt ze hiernaartoe verplaatst als logboek. 20
• question/answer: bevatten de vragen die de verpleegster moet beantwoorden om de oproep af te handelen. • roomgroup: definieert de koppeling tussen de verpleegkundigen en kamers waarvoor ze verantwoordelijk zijn. 4.2.2.2
Webservice logica.
Vervolgens dient webservice logica geschreven te worden. Deze is vrij eenvoudig. De meeste methodes halen objecten op m.b.v. HQL18 en geven deze door aan de client. De client controleren de server iedere paar seconden op updates (polling). Omdat het teveel werk zou zijn om steeds alle oproepen op de server te vergelijken met de oproepen op de client om te zien of er nieuwe zijn bijgekomen, wordt het volgende mechanisme gebruikt. Er wordt een teller bij gehouden op de server. Deze wordt steeds verhoogt als er een update binnenkomt op de server. De clients houden hun eigen teller bij en vergelijken deze bij iedere up-to-date check. Pas als ze verschillen worden alle oproepen voor dat toestel opgevraagd. Nieuwe updates in de webservice kunnen voor komen als er een nieuwe oproep (via RS232-analyser) wordt toegevoegd, maar ook als een andere verpleegkundige een oproep aanneemt of afhandelt. Dit is ook de reden waarom RS232-analyser niet rechtstreeks de database mag aanspreken. Want dan zou de webservice niet weten wanneer een nieuwe oproep is toegevoegd. Dit mechanisme zal naar de toekomst nog verfijnd worden. Aangezien er verschillende groepen gebruikers bestaan. Iedere groep krijgt een aantal kamers toegekend. Dus is het effici¨enter om een teller toe te voegen per groep. Dan moeten vele clients minder keren alle oproepen ophalen. Dit beperkt het netwerkverkeer en verhoogt slechts minimaal de belasting op de webservice. 4.2.2.3
Client proxy-klassen.
Daarna moeten de proxy-klassen gegenereerd worden voor de clients. Deze worden in Qt19 geschreven m.b.v. C++. Evenzo voor de proxy-klassen die in C++ gegenereerd worden. Dit kan vrij eenvoudig met gSOAP20 . Aan gSOAP wordt het adres van de WSDL21 van de webservice meegegeven en dan genereert deze alle benodigde klassen. 18 ”Hibernate Query Language” heeft hetzelfde doel als SQL, maar werkt met objecten i.p.v. met tabellen 19 Qt is een programmeeromgeving waarbij dezelfde code kan gecompileerd worden voor verschillende platformen. 20 gSOAP kan van een webservice de proxy-klassen automatisch genereren, of omgekeerd de webservice cre¨ eren. 21 ”Web Service Definition Language” bepaalt in een gestandaardiseerd formaat welke methodes opgeroepen kunnen worden in een webservice en welk formaat de objecten hebben die verkregen worden.
21
4.2.2.4
Klasse diagram
Ten slotte wordt de opbouw van de uiteindelijke implementatie van de webservice nog besproken.
Figuur 4.8: Klasse diagram van de Datacheck webservice. Hier worden enkele van de belangrijkste klassen beschreven: • datacheck: dit is de belangrijste klasse die de volledige logica van de webservice bevat. Hierin kan men makkelijk de WSDL-structuur herkennen. zie resultaten: 4.4.1. 22
• De objecten komen nagenoeg overeen met de database tabellen die eerder al besproken werden: 4.2.2.1. Deze objecten kunnen automatisch vanuit de database gegenereerd worden.
4.2.3
Datacheckmobile
Dit is het programma dat als client dient voor de webservice van Datacheck. Het draait op de smartphones van het verplegend personeel. Dit moet zowel voor het Android als voor het Symbian platform geschreven worden. Aangezien de programmeerverschillen zich toch slechts in de details voordoen, worden deze samen besproken op een algemener niveau. De volgende figuur geeft de verschillende onderdelen van het programma met hun interacties in vereenvoudigde vorm weer.
23
start program Login dialog
Login
No
Login checks out?
Yes Notify error second thread Start Poller
Webservice Poller
Call dialog
is Call beeing handeled by another nurse?
Select Call
Yes
No
Back Call update availible on webservice?
Yes
Abort Call
Call refresh
Category dialog Select Category
No
Back Question dialog
Wait POL_INTERVAL Select Question
Back
Finish Call
Question is multiple answer or yes/no
Yes/No
Multiple answer
Answer dialog
Class/Dialog
Action
Choise
Figuur 4.9: Flowdiagram dat de werking van Datacheckmobile weergeeft. Na inloggen kan de verpleegkundige de oproepen zien in volgorde van prioriteit en daarna gesorteerd op starttijd (oudste eerst). Hieronder komen de oproepen die reeds in behandeling zijn, in dezelfde volgorde. Iedere oproep moet worden afgehandeld. Dit gebeurt door een opsomming te geven van alle handelingen. Deze worden als vragen voorgesteld. In het categoriescherm worden de vragen opgedeeld volgens categorie. Na keuze van een bepaalde categorie, krijgt men een reeks vragen te zien waar de verpleegkundige er ´e´en uit kiest. Een vraag kan drie mogelijke types hebben: Ja/Nee, multiple choice of een invoer-vraag. Afhankelijk van het antwoord op de vraag kan nog een bijkomende vraag gesteld worden. Ook kan worden aangegeven of het antwoord op de vraag moet wor-
24
den opgeslagen. Dit is handig om tussenliggende vragen, die leiden naar meer specifieke vragen, niet op te slaan en zo de gegevensredundantie te verlagen. Bij elk vragenmenu kan men een een suggestie geven, als geen enkele vraag de handeling beschrijft. Deze worden vervolgens in een rapport verzonden naar de hoofdverpleegkundige via e-mail. Ten slotte voorziet het programma persoonlijke instellingen. Deze worden bij het inloggen in de applicatie geladen en zorgen ervoor dat de verpleegkundigen meer inspraak krijgen in de werking van Datacheck. Dit wordt op volgende manier ge¨ımplementeerd in klassen:
25
main
CallDialog
CategoryDialog
QuestionsDialog
InputAnswerDialog
-attribute : PollingService* -dynamic_buttons : QList -styles : QStringList* -attribute : CallButton*
-attribute : Call* -buttons : QList
-questions : QHash< int, QList< Questi... -question_menu_id : int -attribute : Call* -dynamic_buttons : QList< QWidget* > *
-ui : InputAnswerDialog* -attribute : Question* -attribute : Call*
LoginDialog +LoginDialog() +~LoginDialog() -eventFilter()
+CallDialog() +~CallDialog() +initCalls() +updateCalls() -clearButtons() -eventFilter()
+CategoryDialog() +~CategoryDialog() +setCall() +setBtnReadyEnabled() +loadQandA() -eventFilter()
+InputAnswerDialog() +~InputAnswerDialog() +initialize()
Call
datacheckPortBindingProxy +soap_endpoint : char* +datacheckPortBindingProxy() +datacheckPortBindingProxy() +datacheckPortBindingProxy() +datacheckPortBindingProxy() +~datacheckPortBindingProxy() +datacheckPortBindingProxy_init() +destroy() +soap_noheader() +soap_fault() +soap_fault_string() +soap_fault_detail() +soap_close_socket() +soap_print_fault() +soap_stream_fault() +soap_sprint_fault() +checkLogin() +getSettings() +getCalls() +getCounter() +send_addCall() +recv_addCall() +recv_addCall_empty_response() +addCall() +increaseCounter() +getQuestions() +getAnswers() +setCallPending() +send_setCallAbort() +recv_setCallAbort() +recv_setCallAbort_empty_response() +setCallAbort() +send_setCallFinished() +recv_setCallFinished() +recv_setCallFinished_empty_response() +setCallFinished() +addCallAnswer() +send_addSuggestion() +recv_addSuggestion() +recv_addSuggestion_empty_response()
+QuestionsDialog() +~QuestionsDialog() +showQuestions() +loadQandA() -eventFilter() -clearButtons()
CallButton -attribute : Call* +CallButton() +~CallButton() +paintEvent() +getCall()
PollingService -attribute : CallDialog* -attribute : QList< Call* > * -updateGui : bool +PollingService() +timerEvent() +setGui() +setUpdateGui() -checkUpdates() -isSoundNeeded()
-id : QString -display : QString -location : QString -priority : int -firstname : QString -lastname : QString -staffAidId : QString -pending : bool +Call() +Call() +Call() +getId() +getDisplay() +getLocation() +getFirstName() +getLastName() +getName() +getPriority() +getStaffAidId() +isPending() +compare()
Question
QuestionButton -attribute : Question* +QuestionButton() +~QuestionButton() +getQuestion()
Answer -questionid_ : int -answerid_ : int -answer_ : QString -nextmenuid_ : int
DataConnector -counter : int +checkLogin() +getCalls() +isUpdateNeeded() +getQuestions() +addCallAnswer() +setCallPending() +setCallFinished() +setCallAbort() +readSettings() +writeSettings() +addSuggestion()
+Answer() +Answer() +getAnswer() +getNextMenuId()
-questionid_ : int -questionlevel_ : int -menuid_ : int -questionstring_ : QString -type_ : int -loganswer_ : bool -units_ : QString -mask_ : QString -maskerror_ : QString -columns_ : int -attribute : QList< Answer* > * +Question() +Question() +getMenuId() +getQuestionId() +getQuestion() +isLogAnswer() +getType() +getUnits() +getMask() +getMaskError() +getColumns() +addAnswer() +getAnswers() +==() +qHash()
ProgramSettings -settings : QHash
Figuur 4.10: Klasse diagram van Datacheck mobile op Symbian. Hier worden enkele van de belangrijkste klassen beschreven: • DataConnector: deze voorziet het programma met de benodigde informa26
tie en verbergt de implementatiedetails van de SOAP-klassen. • datacheckPortBindingProxy: dit is de automatisch gegenereerde proxyklasse die, gemakkelijk informatie van op de server op te halen, toestaat. • Dialog: bovenaan op dezelfde lijn staan alle dialoogvensters. Deze worden meestal in dezelfde volgorde getoond aan de gebruiker, zie: 4.9 • ProgramSettings: bewaard alle instellingen die in het programma gemaakt worden en is aanspreekbaar vanuit elke klasse. • PollingService: deze klasse wordt uitgevoerd in een aparte thread. Het controleert de server op updates en verwittigd de GUI wanneer deze moet worden updatet worden.
4.3
Problemen tijdens implementatie
4.3.1
RS232-analyser
• In de eerste fase van de analyse werden de berichten geselecteerd uit de gegevensstream, door een unieke start/stop-bit te identificeren. Een probleem hierbij ontstaat wanneer een eind-bit gemist wordt om welke reden dan ook. Dan zijn alle opeenvolgende geselecteerde berichten eigenlijk de karakters tussen twee opeenvolgende berichten. Dit werd opgelost door de berichtlengte te beperken tot een vast aantal karakters, en enkel te kijken naar de beginbit. Aangezien de berichten een vaste structuur hebben kan deze maximumlengte ingesteld worden zonder extra beperkingen voor het systeem. Zie figuur: 4.5.
X
A B
X A B
C
C X X
X X A B
A B
C D X
C X X A B
C D X
correct geanalyseerde bit
bit zonder nuttige inhoud A bit met nuttige info
verkeerd geanalyseerde bit
X begin/einde bit van een bericht
gemiste bit
Figuur 4.11: Programma mist ´e´en karakter en alle berichten zijn foutief.
27
4.3.2
Datacheckwebservice
4.3.3
Datacheckmobile
• Tijdens de ontwikkeling van de Android-versie kon er geen verbinding gemaakt worden met de webservice. De code was correct maar de poort waarop de aanvragen aan de server doorgegeven werden stond niet open. • Voor de Symbian versie was eerst gekozen voor Java ME22 . Aangezien de Android versie in Java was geschreven en de twee een identieke functionaliteit moesten hebben, was dit een logische keuze. Helaas bleek na enkele dagen ontwikkelen dat Java ME niet krachtig genoeg meer was voor gebruik op touch-smartphones. Daarom is de keuze van de taal veranderd naar Symbian C++ en de IDE naar Qt.
4.4 4.4.1
Resultaten DatacheckWebservice
De bekomen interface van de webservice wordt beschreven d.m.v WSDL. De mogelijke aanroepen zien er als volgt uit: void addCall(Callalert call); void addCallAnswer(final String username, final String callid, final int answerid, final int questionid, final String value); void addSuggestion(final Suggestion suggestion); List<String> checkLogin(final String username, final String password); List getAnswers(); List getCalls(final String username); Integer getCounter(); List getQuestions(); List<String> getSettings(final String username); Integer increaseCounter(); void setCallAbort(final String callId); void setCallFinished(final String callId); String setCallPending(final String callId, final String username); 22 ”Micro Edition” is een Java versie ontworpen voor embedded computers, zoals bijvoorbeeld GSM
28
4.4.2
Datacheckmobile
Figuur 4.12: Aanmeldingsscherm bij opstarten.
Figuur 4.13: Overzicht van enkele oproepen.
Figuur 4.14: Overzicht van de afhandelingscategorie¨en.
Figuur 4.15: suggestie.
29
Toevoegen van een
Verder zijn er nog een aantal schermen die een idee moeten geven van de toekomstige functionaliteit van het programma. Deze functionaliteiten zijn nog niet ge¨ımplementeerd, aangezien onderhandelingen om toegang te krijgen tot de EPD-database, nog niet zijn afgerond. De afbeeldingen dienen voorlopig enkel om een betere keuze te maken bij de implementatie van de huidige onderdelen.
Figuur 4.16: Overzicht dat toegang biedt tot de verschillende hoofdpunten van Datacheck mobile.
30
Figuur 4.17: Overzicht van recente medicatie van een pati¨ent.
Figuur 4.18: Overzicht van de medische geschiedenis van een pati¨ent.
31
Hoofdstuk 5
Getuse 5.1
implementatie
Dit programma moet automatisch facturen genereren met informatie afkomstig uit de Call Data Records van de gebruikte VoIP-centrale. Dit onderdeel bestaat uit drie delen: • Analyse CDR’s. • Management van klanten. • Genereren van facturen.
Telefoon Logs
E-mail Print PDF Facturatie programma:
GetUse
Database
GetUse
Figuur 5.1: Overzicht van GetUse. Dit onderdeel wordt geprogrammeerd in Java. De database interactie gebeurt m.b.v. JDBC1 . 1 ”Java
DataBase Connectivity”
32
Als eerste onderdeel moeten de CDR geanalyseerd worden. Alle callrecords zijn opgedeeld in verschillende bestanden, ´e´en per maand. Een regel in dit bestand ziet er als volgt uit: 2009-08-25 17:50:14;4;3256374046;003251318853;0.00062. Deze bestaan uit: de datum, het tijdstip, de duur in seconden, het telefoonnummer van de zender, het telefoonnummer van de ontvanger en de kostprijs. De verkoopsprijs wordt bepaald door drie factoren: • Het land van de ontvanger. • Type van de lijn van de ontvanger (vast / mobiel). • De duur van het gesprek, maar deze is reeds gekend. De kostprijs die vermeld staat in de CDR geeft aan wat dit gesprek kost aan Smart Telecom. Om het land te bepalen wordt een lijst van reguliere expressies bijgehouden per land (231 landen). Een tweede om te herkennen of het al dan niet om een mobiele lijn gaat. In de volgende figuur ziet u een voorbeeld van het patroon om mobiele nummers in Belgi¨e te herkennen.
patroon:
0{0,3} 32 4 [0-9]{8} rest van het nummer
0,1,2 of 3 keer een “0” landcode België “0032”
8 keer een willekeurig cijfer
mobiel nummer
0470-0479 Proximus 0484-0489 BASE 0491-0499 Mobistar
bepalen samen met de duur de kostprijs van het telefoongesprek Figuur 5.2: Reguliere expressie voor mobiele nummers in Belgi¨e. De landcode moet 0032 zijn. Alle mobiele nummers in Belgi¨e beginnen met het cijfer vier (nullen niet meegerekend). Dit kan bepaald worden voor bijna alle landen. Bij de landen waar dit onmogelijk te bepalen bleek, is er ook geen verschil in kost/minuut tussen vaste- en mobiele lijnen. Eens het land en het type lijn bepaald zijn, worden deze gegevens opgeslagen in een database. Deze wordt dan later gebruikt bij het genereren van facturen.
33
In het tweede onderdeel van GetUse wordt het beheer van het klantenbestand behandeld. Dit moet ook opgeslagen worden in dezelfde database, maar moet eenvoudig aanpasbaar zijn voor medewerkers van Smart Telecom. Indien men de klantengegevens wil aanpassen, zal het programma de huidige klantengegevens exporteren naar een Excel-bestand en dit bestand automatisch openen. Eens de medewerker klaar is met zijn aanpassingen, slaat hij zijn veranderingen op en sluit Excel. Het programma zal de wijzigingen analyseren. Het bestand wordt regel per regel gecontroleerd. Bij fouten worden deze in een overzicht aan de gebruiker gemeld en opent het excel-document zich opnieuw. Ook als het aantal klanten dramatisch zakt na een aanpassing, wordt er een extra bevestiging aan de gebruiker gevraagd. Dit vermijdt verlies van gegevens door menselijke fouten. In het Excel-document wordt op de eerste regels uitleg gegeven over het formaat van de klantengegevens, zodat geen training vooraf nodig is. Bij het exporteren worden ook de nummers, die bij geen enkele klant horen, uitgeschreven zodat deze gegevens makkelijk aan te vullen zijn. Een klant kan verscheidene nummers hebben. Dit kan meegegeven worden in het document. Als laatste onderdeel blijft de factuur-generatie over. Op een factuur wordt vermeld: de gesprekskosten, huur van de centrale en huur van de telefoonlijnen. Deze dienen als back-up indien de internetverbinding zou uitvallen. Naast de overzichtsfactuur wordt ook een detailfactuur gegenereerd die alle gesprekken weergeeft. Om de gesprekskost te bepalen worden alle gesprekken die nog niet gefactureerd zijn overlopen. De verkoopsprijs van een gesprek wordt berekend aan de hand van de eerder verzamelde gegevens. Dit moet bepaald worden naargelang het abonnement. Voorbeelden zijn: • Een gesprek-setupkost • Een prijs per begonnen minuut • Een korting • ... Tijdens dit proces moeten reeds de overzichten van de gesprekken opgemaakt worden. Deze gegevens worden naar Excel en PDF ge¨exporteerd. Indien er kleine aanpassingen nodig zijn, kan dit in het Excel-document aangepast worden. Een print hiervan gaat naar de klant. Iedere factuur moet een sequentieel nummer krijgen om ontbrekende of dubbele facturen te vermijden. Dit factuurnummer wordt met de andere instellingen van het programma bewaard in een XML2 -bestand. In de database kan bepaald worden of de klant deze facturen via mail of per post wil ontvangen. Detailfacturen zijn enkel via email verkrijgbaar uit ecologische overwegingen. De facturen kunnen trouwens rechtstreeks vanuit het programma naar de default printer gestuurd worden. Dit door het PDF-document als argument mee te geven aan Acrobat Reader. Die stuurt dan op zijn beurt de standaard printer van de computer aan. 2 ”Extensible
Markup Language”
34
settings
input
gui
Downloader
ConfigurationConstants
ProgressDialog
~size : int = 1024
-progressBar : JProgressBar -message : String -number : int
+downloadFile(fAddress : String, localFileName : String, d...
ProgramSettings -settings : HashMap<String, String>
actions
+ProgressDialog(parent : Window, max : int, message : String) +change(number : int) : void +getAantal() : int
DownloadLists +DownloadLists()
CdrReader
+get(key : String) : String +set(key : String, value : String) : void +increase(key : String) : void +decrease(key : String) : void +increase(key : String, amount : int) : v... +read() : void +write() : void +print() : void
-cdrFiles : String[] -parent : JFrame -directory : String -null : CustomProgressBar
CustomProgressBar 1
+CdrReader() #doInBackground() : Void -getCdrEntries(file : String) : ArrayList<String> -addCdrToDatabase(cdrEntries : ArrayList<String>) : void #done() : void
-current : JProgressBar -max : int -label : String +CustomProgressBar(parent : JFrame, label : String, max : int) +propertyChange(evt : PropertyChangeEvent) : void
output
#writeCSV() : void #fixCSV(file : File) : ArrayList<String[]> #checkCSV(file : File) : ArrayList<String[]> #readCSV(customerRows : ArrayList<String[]>) : void #randomRijksReg(isMan : boolean, geboorte : Date) : String
ImportCustomers
EditCustomersAction
+mouseReleased(e : MouseEvent) : void +mouseClicked(e : MouseEvent) : void +mousePressed(e : MouseEvent) : void +mouseEntered(e : MouseEvent) : void +mouseExited(e : MouseEvent) : void
+mouseReleased(e : MouseEvent) : void +mouseClicked(e : MouseEvent) : void +mousePressed(e : MouseEvent) : void +mouseEntered(e : MouseEvent) : void +mouseExited(e : MouseEvent) : void
Main
-instance InvoiceDialog
InvoiceLogic
-rbnStartDate2 : JRadioButton -dchStart : JDateChooser -rbnEndDate2 : JRadioButton -dchEnd : JDateChooser -ckbFormat1 : JCheckBox -ckbFormat2 : JCheckBox <> -instance : InvoiceDialog = new InvoiceDialog()
+mouseReleased(e : MouseEvent) : void +analyseRates() : void +calculateExternalCosts() : void
-InvoiceDialog() +CheckInput() : boolean +getStartDate() : Date +getEndDate() : Date +isPdfSelected() : boolean +isExcelSelected() : boolean +copyFile(in : File, out : File) : void
CustomersIO -rg : Random = new Random()
1
-tableCustomers : JTable -instance-tableNumbers : JTable -tableModelCustomers : DefaultTableModel -tableModelNumbers : DefaultTableModel -status : JMenuBar <> -names : String[] <> -numbers : String[] 1 +formatter : SimpleDateFormat = new SimpleDateFormat("d/M/y") <> -instance : Main = new Main() <> -customers : ArrayList -Main() +UpdateLists() : void +buildConstraints(gbc : GridBagConstraints, x : int, y : int, w : int, h : int, wx : int, wy : int, fill : int, anchor : int) : void +main(args : String []) : void
PdfPrinter +print(file : String, factuurNum : String, cust : Custo... -createHeader(file : String, factuurNum : String, cus... ExcelPrinter +print(file : String, name : String, number : String, ge...
InvoiceDistributer
-customers
-invoiceNumber : int <> -null : ArrayList
InvoicePrinter
InvoiceEmailer
+print(filePath : String) : void
+send(cust : Customer, subject : S...
objects
Customer <> -id : String <> -invoiceName : String <> -name : String <> -BtwPlichtig : boolean <> -firstName : String <> -lastName : String <> -gender : boolean <> -birthday : Date <> -address : String <> -zip : int <> -city : String <> -country : String <> -email : String <> -allowEmail : boolean <> -costCentrale : double <> -CostPhonelines : double <> -numbers : ArrayList<String> <> -invoice : String
PdfPrinterException +PdfPrinterException(message : String)
logic telephoneAnalyse RegexpCountry <> -code : String <> -labelEn : String <> -labelNl : String <> -regexpCountry : String <> -regexpMobile : String <> -priceFix : int <> -priceMobile : int <> -startup_fix : int <> -startup_mobile : int +RegexpCountry(labelNl : String, code : String) +RegexpCountry(code : String, labelEn : String, labelNl : String, regexpCou... +toString() : String 1
*
*
+InvoiceDistributer(invoices : ArrayList, invoiceNumber : int)
+Customer(id : String, invoiceName : String, name : String, BtwPlic... +isCompany() : boolean +setMonthCost(monthCost : Double) : void +addNumber(number : String) : void +getTotalInvoice() : String +getDetailInvoice() : String +toString() : String +getCostPhonelines() : double +setCostPhonelines(CostPhonelines : double) : void +isBtwPlichtig() : boolean +setBtwPlichtig(BtwPlichtig : boolean) : void +isAllowEmail() : boolean
Country <> -code : String <> -labelNl : String <> -labelEn : String <> -rate : int <> -setupCost : int +Country(code : String, labelNl : String) +Country(code : String, labelNl : String, labelEn : String) +Country(code : String, labelNl : String, labelEn : String, rate : int, setupCost : int) +toString() : String
Cdr -date : Timestamp <> -duration : int <> -from : String <> -to : String <> -internalCost : double <> -externalCost : double <> -rate : int <> -setupCost : int -Cdr(date : Timestamp, duration : int, to : String) +Cdr(date : Timestamp, duration : int, to : String, externalCost : double) +Cdr(date : Timestamp, duration : int, to : String, internalCost : double, rate : int, setupCost : int) +Cdr(date : Timestamp, duration : int, from : String, to : String, internalCost : double) +getDate() : String +getDateUSA() : String
FailedToAnalyseNumberException <> -number : String +FailedToAnalyseNumberException(messa...
database DataConnector
TelephoneAnalyser
+init() : void -geefVerbinding() : Connection +addCdrsToDatabase(directory : String) : void -addCdrToDatabase(cdrEntries : ArrayList<String>) : void -getFileLines(file : String) : ArrayList<String> +insertCdr(dateTime : Timestamp, duration : int, fromNumber : String, toNumber : String, cost : dou... +updateCdr(dateTime : Timestamp, toNumber : String, extraDuration : int, extraCost : double) : void +customerExists(id : String, number : String) : boolean +customerExists(id : String) : boolean
-countries : ArrayList> <> -instance : TelephoneAnalyser -null : RegexpCountry +TelephoneAnalyser() +analyse(number : String) : Country
1 -instance
Figuur 5.3: Klasse diagram van het Getuse facturatie programma. Hier worden enkele van de belangrijkste klassen beschreven: • CdrReader: leest alle CDR-bestanden van de gespecificeerde CDR-directory en slaat ze op in de database. • TelephoneAnalyser: deze bepaald het land van de bestemming van een telefoongesprek en of het naar een vaste- of een mobiele lijn is gemaakt. • RegexpCountry: bevat de regexp3 -patronen voor de ieder land. Deze worden voor analyse opgehaald uit de server en gecompileerd. • DataConnector: deze voorziet weer de interactie met de database. 3 ”Reguliere
Expressie” is een manier om patronen te beschrijven waarmee een computer tekst kan herkennen.
35
• CustomerIO: voorziet functies om het Excel-bestand te lezen en te schrijven maar ook om het te openen met Excel. • InvoiceDialog: geeft de opties weer tussen welke data de gesprekken moeten gemaakt zijn die op de gegenereerde facturen komen. • InvoiceDistrubuter: deze geeft de opties weer om de facturen te verdelen naar de klanten: printen, mailen of manueel behandelen. Bij dit onderdeel werden ook enkele kleine configuratieprogramma’s gevraagd: • PinGen De verbinding tussen de smartphones en de VoIP-server wordt beveiligd m.b.v. een wachtwoord. Deze wachtwoorden moeten op een eenvoudige en veilige manier worden bewaard. Iedere technicus die aanpassingen wil maken aan het systeem heeft deze wachtwoorden nodig. Daarom werdt een programma ontworpen dat wachtwoorden genereert a.d.h.v. vertrouwelijke informatie van de klant en een masterkey. Hierdoor kan om het even welke technicus veilig en eenvoudig de wachtwoorden terug genereren. Het programma moet met identieke gegevens steeds dezelfde wachtwoorden genereren. • SecSet De instellingen die in het Getuse programma kunnen worden ingesteld worden opgeslagen in een XML-bestand. Deze instellingen kunnen ook wachtwoorden bevatten. Daarom mogen deze bestanden niet zomaar onbeveiligd op de schijf opgeslagen worden. Hierom wordt een programma gecre¨eerd dat de gebruiker in staat stelt om XML-bestanden te encrypteren en aan te passen. Het programma kan een XML-bestand omzetten naar een ge¨encrypteerd bestand door middel van een ingevoerde sleutel. Wil men het XML-bestand opnieuw bewerken, dan kan dat enkel via dit programma en de eerder ingegeven sleutel.
5.2
Problemen tijdens implementatie
• Hier was de grootste moeilijkheid het herkennen van de landen en het type telefoonlijn in het telefoonnummer. De analyse gebeurt op basis van een regexp per land. De eerste regexp bepaalt of het telefoonnummer afkomstig is van dit bepaalde land. De tweede regexp is bedoeld om te bepalen of het nummer mobiel is of een vaste lijn betreft. Om de effici¨entie te verhogen zou men de regexps kunnen omvormen tot een finite-state automaat. In de huidige implementatie is hier om twee redenen niet verder op ingegaan. Ten eerste is het systeem niet tijdkritisch en is het reeds vrij effici¨ent zolang het aantal te analyseren telefoonnummers beperkt blijft (< 10000). Aangezien enkel unieke telefoonnummers moeten geanalyseerd worden, is de effici¨entie sterk afhankelijk van het belgedrag van de gebruikers van de 36
VoIP-centrale. Verder is het aantal unieke nummers beperkt aangezien de analyse iedere maand zal worden uitgevoerd. Ten tweede is het veel eenvoudiger om aanpassingen door te voeren als ´e´en van de regexps zou veranderen. In een finite-state automaat is dit daarentegen veel moeilijker, zeker als deze geminimaliseerd is. Een optimale oplossing zou zijn om, bij de start van het programma, te kijken of er veranderingen aan de regexps-lijst zijn aangebracht en telkens indien nodig, de automaat te regenereren. Dit is tot nu toe nog niet gebeurd wegens de eerst vernoemde reden.
START 3
0 3
0 3
0 3
3
4
2
0-3,5-9
België mobiele lijn
België vaste lijn
6
0-5,7-9
Nederland mobiele lijn
Nederland vaste lijn
Figuur 5.4: Finite state automaat die telefoonnummers analyseert voor Belgi¨e en Nederland.
37
5.3
Resultaten
Figuur 5.5: Grafische interface van het facturatieprogramma Getuse.
38
Figuur 5.6: Grafische interface van het wachtwoorden-genererend-programma Pingen.
Figuur 5.7: Grafische interface van het XML-beveiligingsprogramma Secset.
39
Hoofdstuk 6
Wificonfigurator 6.1
implementatie
Dit onderdeel moet informatie van een opgegeven aantal Wireless Accesspoints (AP’s) ophalen, de informatie ervan analyseren, de beste configuratie kiezen en deze dan terug opladen. Dit zal geprogrammeerd worden in Java zodat platformonafhankelijkheid behouden blijft.
40
neightboor AbstractAccessPoint
<<Enum>> ChannelStatus
-ssid : String -mac : String #null : Channels -null : ChannelStatus = neightboor.ChannelStatus.UNDECIDED <> IAccessPoint +equal(other : AccessPoint) : boolean +getMac() : String
1
+AbstractAccessPoint(ssid : String, mac : String, channel : int) +equal(other : AccessPoint) : boolean +getSSID() : String -convertChannel(channel : int) : Channels 1
AccessPointNeightboor
<> -UNDECIDED <> -LOCAL_UNDECIDED <> -LOCAL_DECIDED <> -REMOTE
<<Enum>> Channels <> -CH_1 <> -CH_6 <> -CH_11 <> -UNDEF 1
AccessPoint
-distance : int +AccessPointNeightboor(ssid : String, mac : Strin... +compareTo(o : AccessPointNeightboor) : int
+AccessPoint(ssid : String, mac : String, ip : String, ... +addNeightboor(neightboor : AccessPointNeightboo... +setChannel() : Channels +sortAps() : void -resetChannelPreferences() : void +getPreferedChanel() : Channels +getPreferedChanelIndicator() : int +calculateChannelPreferences() : void +compareTo(o : AccessPoint) : int +getPrefs() : String ~setNeightboorStatus(apMac : String, channelStatu... ~printNeightboors() : void ~detectLocalNeightboors(localApMacs : ArrayList<... ~localApMacsContains(localApMacs : ArrayList<St...
Channel -null : Channels -preference : int +Channel(channel : Channels, preference : int) +resetPreference() : void +addPreference(pref : int) : void
NeightboorCollector
*
-username : String -password : String -null : ArrayList
*
~NeightboorCollector(username : String, pass... +start() : void
ChannelConfigurator -un : String -pw : String -null : ArrayList
AccessPointCollector
+ChannelConfigurator(un : String, pw : String, aps : ArrayList... +configure() : ArrayList -calculateChannels() : void -detectLocalNeightboors() : void -existsInterferance(complete : boolean) : boolean -print() : void
+getCurrentData(un : String, pw : String, ip...
gui
snmp
Preferences +accessPointStatus : String = "/setup.cgi?r... +requestScanURL : String = "/setup.cgi?re... +responsScanURL : String = "/setup.cgi?re... +startOfAPDataLine : String = "
Gui
SnmpConnector
-Gui() -getIps() : ArrayList<String> -refreshTable() : void +updateAccessPointInfo(aps : ArrayList
RegExpExpander +ipNumberExpand(regexp : String, ip...
-address : String -snmp : Snmp +SnmpConnector(address : String) +stop() : void -start() : void +getAsString(oid : OID) : String +get(oids : OID []) : ResponseEvent -getTarget() : Target +getTableAsStrings(oids : OID []) : List>
SNMP_OID +sysName : String = "1.3.6.1.2.1.1.5.0" +clientMAC : String = "1.3.6.1.4.1.14125.1.2.30.3.1.3" +clientRSSI : String = "1.3.6.1.4.1.14125.1.2.30.3.1.6"
Figuur 6.1: Klasse diagram van het Wificonfigurator programma. Dit onderdeel valt uiteen in 2 onderdelen:
41
6.1.1
Ophalen/opslaan configuratiegegevens.
Een gebruiker kan een nieuw type AP kalibreren door voorgedefinieerde waarden in te stellen in een AP terwijl het programma het netwerkverkeer in de gaten houdt. Het kalibreren gebeurt voorlopig nog door de programmeur voor een vooraf gedefinieerd type AP. De analyse van het HTTP1 -verkeer gebeurt m.b.v. Wireshark2 . De configuratiegegevens, die voor alle AP’s gelijk zijn, kunnen ingesteld worden in het beginscherm van het programma. Verder kunnen ook de huidige en toekomstige gebruikersnamen en wachtwoorden gespecificeerd worden, die gebruikt worden bij de HTTP-aanvragen. Dit eerste onderdeel is vrij eenvoudig en bestaat uit het sturen van “HTTP-get en post berichten” naar de AP’s, om ze te configureren.
6.1.2
Kanaalbepaling van de WAP’s.
In het tweede onderdeel wordt de optimale kanaalconfiguratie van de AP’s bepaald. Iedere AP kan zijn omgeving scannen en een lijst van buren teruggeven waarvan hij signaal ontvangt. Deze lijst kan via een HTTP-get bericht opgevraagd worden. Hieruit kan een graaf opgesteld worden, waarbij iedere knoop een AP voorstelt en iedere verbinding aangeeft dat beide AP’s elkaars signaal ontvangen. Op iedere verbinding wordt bijgehouden hoe sterk het signaal is tussen de twee AP’s. Bij iedere AP kan het kanaal opgeslagen worden. Er zijn dertien kanalen waarvan er slechts drie niet met elkaar interfereren. Alle AP’s moeten een kanaal krijgen zodat AP’s op hetzelfde kanaal zo ver mogelijk uit elkaar staan, of m.a.w een zo zwak mogelijk signaal van elkaar ontvangen. Dit lijkt in tegenspraak met de manier AP’s met elkaar werken. De interferentie tussen AP’s op hetzelfde kanaal wil enkel zeggen dat AP’s rekening moeten houden met elkaars berichten. Ze moeten afspreken wanneer ze spreken zodat ze elkaars signaal niet storen. Men zou ten onrechte kunnen denken dat het beter is het aantal keer dat zo’n conflict zich voordoet te minimaliseren, ongeacht of de AP’s dicht of ver uit elkaar liggen. Dit klopt evenwel niet gezien de signaalsterkte waarmee de AP’s uitsturen, kan geconfigureerd worden. De conflicten die zich op grotere afstand voordoen kunnen namelijk makkelijk opgelost worden door het zendvermogen te verlagen. 1 ”Hypertext Transfer Protocol” is een netwerk protocol dat de communicatie tussen een webclient (meestal een browser, hier datacheckmobile) en een webservice voorziet. 2 Wireshark is een netwerk-protocol analysator voor Windows / Unix
42
Wireless Access Point
B
Wireless Access Point
Wireless Access Point
A
C
WiFiConfigurator Wireless Access Point
D
Figuur 6.2: Overzicht van de Wificonfiguratoropstelling In bovenstaande figuur kan je zien dat WAP A en B op hetzelfde kanaal ingesteld staan. Aangezien deze AP’s dichter bij elkaar liggen dan de andere twee, is het in dit geval beter om de kanalen te veranderen zodanig dat B en D zich op hetzelfde kanaal bevinden. Opgelet de figuur is slechts ter illustratie bedoeld. De cirkels die het zendbereik voorstellen zullen in werkelijkheid veel groter zijn, anders kunnen de AP’s elkaars kanaal nooit opvangen. Om terug te komen op de graaf, herleidt het probleem zich tot een graafkleuringsprobleem (graph coloring). Kleur een graaf met drie kleuren zodat gelijkkleurige knopen zo ver mogelijk uit elkaar verwijderd zitten. In een vlakke graaf is het mogelijk om een graaf in te kleuren met vier kleuren3 . Helaas is dit hier geen vlakke graaf aangezien verbindingen willekeurig kunnen kruisen (draadloos) en de AP’s op verschillende verdiepingen boven elkaar kunnen staan. Bovendien kunnen er AP’s zijn van buren die op een kanaal ingesteld staan dat onveranderbaar is. Dus de graaf kan reeds ingekleurde knopen bevatten. 3 Het
vier-kleuren probleem is een zeer gekend probleem binnen de grafentheorie.
43
Figuur 6.3: Model van de graaf met gekleurde knopen en interferentie 6.1.2.1
Algoritmen
• 0-Extension[1] Dit algoritme probeert een graaf in te kleuren, vertrekkende vanaf een subgraaf die reeds ingekleurd is. Helaas is de verborgen constante4 veel te groot. Dit wil zeggen dat het algoritme wel snel is in vergelijking met andere algoritmes maar enkel voor zover er genoeg knopen in de graaf zijn. In dit geval moet het programma een netwerk met maximum 64 knopen kunnen configureren. Dit algoritme is dus niet bruikbaar. • Brute Force (DEZ) Aangezien het aantal knopen slechts 64 kan bedragen, kan geprobeerd worden alle mogelijke configuraties te bepalen en dan deze te kiezen met de laagste interferentiewaarde (zie verder). Alle mogelijkheden kunnen in een boom-structuur worden beschouwd waarbij ieder niveau een knoop voorstelt en iedere knoop in de graaf een voorlopige kleuring van de graaf. De bladeren onderaan de boom stellen alle mogelijke kleuringen voor. start
eerste knoop tweede knoop derde knoop vierde knoop
Figuur 6.4: Eerste vier niveaus van de mogelijke kleuringen van de boom De boom wordt doorlopen met DEZ5 , zie ook 6.1.2.1. Steeds een blad 4 Bepaalt 5 ”Diepte
de standaard kost van een algoritme per element (knoop) in het probleem. Eerst Zoeken” is een techniek om alle knopen in een boom te doorlopen. Hierbij
44
bereikt wordt, is een mogelijke kleuring gevonden. Als nu de kleuring met minimale interferentiewaarde bijgehouden wordt, dan zal deze, na overlopen van de hele boom, minimaal zijn. Dit wil zeggen: 364 of 3.4 ∗ 1030 kleuringen te berekenen. Dit is zelfs met snelle desktop computers nog niet haalbaar. Deze methode kan op de gebruikte referentiecomputer een dichte6 graaf met vijfentwintig knopen inkleuren in ongeveer een half uur. Daarbij moet er rekening gehouden worden met een verdrievoudiging van de uitvoeringstijd per extra knoop.
1 2 3
4
6 5
7
8
10 9
11
12 13
Figuur 6.5: Volgorde van knopen aflopen bij “Diepte Eerst Zoeken”. Hoe berekent men nu de interferentiewaarde? Deze wordt gedefinieerd als de som van alle interferentie waarden van alle verbindingen, waarvan de knopen gelijk gekleurd zijn. De interferentiewaarde van een verbinding met gelijkkleurige knopen wordt dan de som van maximale signaalsterkte en signaalsterkte. Signaalsterkte wordt uitgedrukt in dBm7 . Deze waarden zijn steeds negatief, waarbij -1 een sterk signaal is en -90 het zwakste signaal. In het model wordt eerst gecontroleerd of er nergens een signaalsterkte bestaat kleiner dan -90. • Brute Force (DEZ) Optimized De “brute force” kan sterk geoptimaliseerd worden door enkele kleine ingrepen. Bij het afdalen in de boom, kan bij iedere knoop de interferentiewaarde berekend worden. Als deze groter wordt dan de huidig minimale waarde voor een volledige kleuring, dan moet men de rest van die deelboom niet meer uitrekenen aangezien alle kleuringen in die deelboom een grotere interferentiewaarde zullen hebben dan het huidige minimum. Deze techniek van deelbomen wegsnijden wordt ook wel tree pruning genoemd. start men bij de bovenste knoop (de wortel), men kiest een tak en doorzoekt deze zo ver mogelijk zonder terug te keren op zijn stappen. 6 Met een dichte graaf bedoelen we gemiddeld 6 verbindingen per knoop. Het aantal verbindingen zal normaal gezien veel lager liggen: eerder rondt 4 verbindingen per knoop. 7 dBm (soms dBmW) is een afkorting voor de vermogen verhouding in decibel (dB) of gemeten vermogen met als referentie 1 milliwatt (mW).
45
Een andere optimalisatie bestaat erin bij iedere knoop de kinderen in een willekeurige volgorde af te lopen. Bij het origineel wordt gestart met alle knopen eenzelfde kleur te geven en dan in omgekeerde volgorde ´e´en per ´e´en de kleuren aan te passen. Dit zorgt ervoor dan de initi¨ele interferentie maximaal is, en dus geen versterkend effect heeft op de vorige optimalisatie. Door de kleuren in willekeurige volgorde uit te testen zakt de initi¨ele interferentie drastisch en dit heeft een zeer positieve invloed op de uitvoeringstijd dankzij de vorige optimalisatie. Ten slotte zouden het mechanisme zeer eenvoudig multithreaded8 gemaakt kunnen worden. De effecten hiervan zijn evenwel minimaal. Zelfs als door multithreading de snelheid verviervoudigt, dan nog komt dit neer op ´e´en `a twee extra knopen die kunnen berekend worden binnen dezelfde tijd. Het werk weegt dus niet op tegen de tijdswinst. Om locale grote interferentiewaarden te vermijden binnen een goede oplossing, moet nog een optimalizatie toegevoegd worden. Stel een oplossing met ´e´en interferentiewaarde van 90 en ´e´en met 100. Nu wordt sowieso voor de oplossing met de kleinste interferentiewaarde gekozen. Maar stel dat de ene een opeenvolgende reeks interferentiewaarden heeft van: 0,0,0,90,0,0,0,0,0,0 en de andere: 10,10,10,10,10,10,10,10,10,10. Dan is het duidelijk dat deze laatste de beste oplossing is om de zendvermogens aan te passen. Helaas kiest het algoritme nu voor de eerste oplossing. Dit kan verbeterd worden door een strafwaarde in te voeren voor hoge lokale interferentiewaarden. Als bijvoorbeeld alle interferentiewaarden eerst gekwadrateerd worden, zullen de hogere lokale interferentiewaarden een veel hogere waarde krijgen dan de lagere waarden. In het voorbeeld wordt dit: 902 = 8100 en 102 + 102 + ... + 102 = 1000. Nu wordt wel voor de tweede oplossing gekozen. Een andere en laatste methode kan een zeer grote tijdswinst opleveren maar verandert deze wel in een benaderingsalgoritme in plaats van een exact algoritme. De eis is dat bij iedere stap in de graaf de huidige interferentie kleiner moet zijn dan het huidig minimum min een constante. Hoe groter deze constante is, hoe sneller het algoritme, maar ook hoe slechter de oplossing. De grootte van de constante geeft aan hoeveel de interferentiewaarde van de oplossing maximaal kan afwijken van het optimum. Deze methode kan dankzij deze optimalisaties een dichte graaf met dertig knopen verwerken onder de seconde. Om deze techniek tot een praktisch bruikbare methode te maken, moet men vooreerst de graaf opdelen in stukken die binnen een haalbare tijd 8 Dan wordt het werk opgesplitst in onafhankelijke delen en door aparte processoren uitgerekend.
46
berekenbaar zijn en vervolgens het resultaat terug samenvoegen (verdeel en heers methode). Men kan de graaf splitsen in twee delen die ongeveer dezelfde grootte hebben en waarbij de som van de waarden van de verbindingen die over de snijlijn lopen minimaal is9 (rode lijn in de onderstaande figuur). Men gebruikt dan deze methode om het eerste stuk (A) te berekenen binnen een haalbare tijd. Daarna wordt het tweede deel (B) berekend afhankelijk van de eerder berekende kleur van de knopen die in de doorsnede van A en B liggen.
A
B
Figuur 6.6: Splits graaf en bereken de twee delen apart met de grensknopen in beide delen Een heuristische manier om een graaf te splitsen volgens bovenstaande criteria is m.b.v. het Kerninghan-Lin algoritme. Dit algoritme begint met een basis verdeling waarbij beide delen ongeveer even groot zijn en probeert deze te verbeteren door knopen paren te zoeken waarbij de doorsnede kleiner wordt als de paren omgewisseld worden. Het algoritme blijft zoeken tot er geen zo’n knopenpaar meer wordt gevonden. 9 Graph
Bisection.
47
1 function Kernighan-Lin(G(V,E)): 2 determine a balanced initial partition of the nodes into sets A and B 3 do 4 A1 := A; B1 := B 5 compute D values for all a in A1 and b in B1 6 for (i := 1 to |V|/2) 7 find a[i] from A1 and b[i] from B1, such that g[i] = D[a[i]] + D[b[i]] - 2*c[a[i]][b[i]] is maximal 8 move a[i] to B1 and b[i] to A1 9 remove a[i] and b[i] from further consideration in this pass 10 update D values for the elements of A1 = A1 / a[i] and B1 = B1 / b[i] 11 end for 12 find k which maximizes g_max, the sum of g[1],...,g[k] 13 if (g_max > 0) then 14 Exchange a[1],a[2],...,a[k] with b[1],b[2],...,b[k] 15 until (g_max <= 0) 16 return G(V,E)
Figuur 6.7: Pseudo code voor het Kerninghan-Lin algoritme. Aangezien dit algoritme begint met een redelijke verdeling moet men deze nog eerst opstellen. Een heuristische methode om een graaf in 2 delen te splitsen die ongeveer even groot zijn, kan gerealiseerd worden door eerst de twee knopen te zoeken die het verst uit elkaar liggen. Dan laat men deze knopen om beurt een buur kiezen, in volgorde van de dichtste buur eerst, tot alle knopen verdeeld zijn in 2 groepen. Daardoor wordt het probleem opnieuw verschoven, want men dient de twee verst uiteenliggende knopen te vinden. Dit kan met een eenvoudige iteratieve methode. Er wordt willekeurig een knoop gekozen. Dan geeft men zijn buren de waarde ´e´en, en al hun buren, de waarde twee, enz. Een waarde mag nooit overschreven worden. Als men bij de laatste knoop komt, is dit de verste knoop van de eerst geselecteerde knoop. Het proces wordt herhaald tot de waarde van de laatste knoop gelijk blijft aan de waarde van de laatste knoop uit de vorige ronde. Deze waarde is trouwens de diameter10 van de graaf. 10 de diameter van een graaf is de lengte van de langste, kortste weg tussen twee knopen in een graaf. Met “langste kortste” wordt bedoeld: van alle kortste wegen tussen alle mogelijke paren in de graaf, de langste.
48
1
2
1
2
1
1
0
3
2
2
1
4
3
2
3
0 1
2
0
1
2
4 2
1
Iteratie 1
2
3
Iteratie 2
1
Iteratie 3
Figuur 6.8: Drie iteraties om de verst uiteenliggende knopen en de diameter te vinden. • Brute Force (BEZ) Optimized Het probleem kan ook anders benaderd worden. Tijdens afdalen in de mogelijke-kleuringen-boom worden alle kleuringen op ´e´en niveau bepaald en de interferentiewaarde berekend. Hiervan worden dan de beste interferentiewaarden gekozen om verder door te rekenen. Het aantal dat gekozen wordt is perfect instelbaar. Het bepaalt ook de snelheid van het algoritme (hoger is trager) en de kwaliteit van de oplossing (hoger is beter). Deze functionaliteit is zeer eenvoudig te implementeren met een prioriteitswachtrij met vaste grootte. Alle oplossingen worden hieraan toegevoegd en als prioriteit wordt de interferentiewaarde gekozen. Bij het toevoegen van een nieuwe oplossing, als de wachtrij reeds vol is, wordt de slechtste oplossing verwijderd. priority queue size = 3 20
8
10
5
5
30
0
2
0
5
7
20
Figuur 6.9: BEZ methode met wachtrij grootte = 3.
49
8
1
1
17
7
9
12
3
1
Deze methode biedt niet meer gegarandeerd de beste oplossing. Maar zoals eerder uitgelegd is de ideale oplossing een vager begrip dan eerst gedacht. Het is een “trade-off” geworden tussen lokale- en globale optimalisatie. Een voordeel van deze methode is dat ze makkelijk aanpasbaar is aan de snelheid van de computer. Men kan bij ieder niveau nagaan hoeveel tijd het vergt om het te berekenen. Als deze tijd te groot wordt, reduceert men het aantal oplossingen waarmee verder gewerkt wordt. Zo zal het algoritme zich dynamisch aanpassen aan toekomstige krachtigere computers. Hierdoor heeft het ook weinig zit om een tijdsresultaat voor een bepaalde graaf te geven, aangezien de methode zich aanpast aan de toegestane tijd. We kunnen evenwel de 6.1.2.2
Voorbereiden graaf
Ten slotte kan/moet de graaf op voorhand al voorbereid worden onafhankelijk van het gebruikte algoritme. Deze aanpassingen zorgen ervoor dat de algoritmes minder knopen moeten verwerken. Deze methodes kunnen de uitvoering verbeteren maar daar mag hier nooit zomaar van uitgegaan worden. Er moet altijd verondersteld worden dat een graaf zo sterk samenhangt dat hij niet te verbeteren is. Daarom werden voorgaande algoritmes gedefinieerd. Ze zijn trager maar geven wel altijd een oplossing. • Opsplitsen in componenten De opgestelde graaf is niet perse samenhangend. Dit wil zeggen dat de graaf opgesplitst kan worden in delen die geen gemeenschappelijke verbindingen bezitten. Eens opgesplitst in componenten, kunnen bovenstaande algoritmen op iedere component uitgevoerd worden. Dit is in lineaire tijd te bepalen m.b.v. DEZ. Steek alle knopen in een lijst. Begin met de eerste knoop in de lijst, loop door zijn buren met DEZ. Bij iedere bereikte buur wordt deze verwijderd uit de lijst. Als alle knopen via DEZ overlopen zijn, is een volledige component gevonden. Op dezelfde manier wordt verder gegaan tot er geen knopen meer in de lijst zitten.
50
11
1 8
6
2 5 2
3
5
6
9
7
8
8 13
7
12
8
3
5 3
4
10 9
5
7
9 10 11 12 13 4
12
10
3
12
13 10 11 12 13 11
12
4 10
13
12
13 12
11 12 13
Figuur 6.10: Splitsen van een graaf met “Diepte eerst zoeken”. • Reduceren van een component Als een knoop maximaal twee buren heeft kan deze steeds ingekleurd worden, want er zijn drie kleuren. Dus alle knopen met maximaal twee buren worden iteratief gewist uit de component, tot deze niet verder te reduceren valt.
51
12 3
9
8
11
4 10
10
13
7
4 10 11 12 13 11
4
6
2
4
6
2
11
1
9 10 11 12 13
11
1
5
10
13
7
4
4
12
Figuur 6.11: Reduceren graaf door alle knopen met maximum twee buren te verwijderen. Na alle knopen gewist te hebben, blijven er ´e´en of meerdere niet te reduceren kernen over. Deze kunnen dan ingekleurd worden m.b.v. de voorgaande algoritmen. Dit kan een zeer sterke optimalisatie zijn bij een ijle graaf11 . De volgorde van de verwijderde knopen moet worden bijgehouden, zodat de component na het berekenen van de kernen terug kan worden opgebouwd in omgekeerde volgorde. Het reduceren van de graaf versnelt de globale berekening zonder de optimale oplossing op te offeren. 6.1.2.3
Totaal algoritme
Al de bovenstaande algoritmen zijn combineerbaar tot ´e´en zeer effici¨ent algoritme als de graaf ijl is. Dit gebeurt in onderstaande volgorde: • Opdelen van de graaf in zijn componenten (6.1.2.2) • Op alle componenten worden volgende bewerkingen toegepast: – Reductie van de component 6.1.2.2 – Indien er een niet te reduceren kern overblijft, wordt deze gekleurd met 6.1.2.1 – De graaf wordt terug opgebouwd in omgekeerde reduceer-volgorde en worden alle toegevoegde knopen direct met het beschikbare kleur gekleurd • De verscheidene componenten worden terug samen gevoegd in ´e´en graaf Dit algoritme berekent niet perse de optimale oplossing, maar toch zeker een optimale oplossing binnen een zeer kleine tijdsduur. Deze valt perfect te beperken door de wachtrijgrootte bij het BEZ12 -algoritme te beperken. 11 Dit is een graaf met weinig verbindingen tussen de knopen. Tegengesteld aan een dichte graaf, waar het aantal verbindingen tegen het maximum (#knopen2 ) aanloopt. 12 ”Breedte Eerst Zoeken” is een techniek om alle knopen in een boom te doorlopen. Alleen worden de knopen met deze techniek niveau per niveau overlopen i.p.v. verticaal bij DEZ.
52
6.2
Problemen tijdens implementatie
• Hier was het eerste idee om de kanalenconfiguratie met brute force te bepalen. Deze methode is dan O(3n ) (met n het aantal knopen in de graaf) en niet echt effici¨ent bij grotere aantallen AP’s /TODO show results of this method. Als alternatief kan het 0-extention algoritme[1] gebruikt worden. Dit heeft een veel hogere asymptotische effici¨entie O(log(n)) maar biedt slechts een sub-optimale oplossing. De verborgen constante blijkt veel te groot te zijn waardoor dit algoritme met n = 64 niet praktisch bruikbaar is. Een ander vakgebied waar gelijkaardige problemen effici¨ent moeten worden opgelost betreft compilers[2, 8.8.4]. Een belangrijk onderdeel van compilers is het toekennen van registers. Er zijn “k” registers en deze moeten gebruikt worden door de verschillende onderdelen van een programma. Het toekennen kan aanzien worden als het kleuren van een graaf met “k” kleuren. Helaas houden de methodes voor dit probleem geen rekening met de waarde op de verbindingen tussen de knopen, en proberen ze enkel het aantal conflicten te reduceren.
53
6.3
Resultaten
Figuur 6.12: Grafische interface om de WAP-configuratie in te stellen. Hier kan men de IP-adressen van de AP’s en de logingegevens invullen. Dan drukt men op “Collect” om de informatie uit de AP’s op te halen. Vervolgens worden alle gegevens ingevuld en drukt men om “Push” om de optimale configuratie te berekenen en terug in te laden in de AP’s.
54
Hoofdstuk 7
Besluit 7.1
Datacheck
Dit onderdeel wordt reeds in testfase uitgeprobeerd in het rusthuis Sint Franciscus te Kluisbergen. Enkel de oproepafhandeling is volledig af gewerkt. Het verplegend personeel krijgt dus de oproepen op hun smartphones te zien. Ze kunnen deze aannemen en de uitgevoerde acties specificeren. Deze acties worden dan opgeslagen in de database. Dit systeem heeft een aantal voordelen t.o.v. van het huidige systeem: • Alle oproepen die in afhandeling zijn blijven zichtbaar op het scherm. Vroeger zag met enkel de meest recente oproep. • De verpleegkundigen zien welke oproepen door wie worden behandelt. • Er kunnen opmerkingen worden toegevoegd over de toestand van de pati¨ent. Deze kunnen een belangrijke bijdragen geven tot de diagnose van de dokter.
7.2
Getuse
De facturatie werkt reeds is productieomstandigheden. Het wordt gebruikt door Smart Telecom vanaf halverwege 2010. De facturen worden wel nog niet automatisch verstuurd via email, tot het programma volledig stabiel is gebleken. Door dit programma is het ook mogelijk dat de verpleegkundigen telefoneren naar bestemmingen buiten het rusthuis. De kostprijs van deze gesprekken wordt dan door Smart Telecom direct naar de verpleegkundige gefactureerd of dit kan ook via het rusthuis gebeuren. Er wordt reeds een klantenbestand van rond de 40 klanten met dit programma behandelt. Het langst duur de kostprijs berekening voor de gesprekken. Dit zal waarschijnlijk nog verder geoptimaliseerd worden.
55
7.3
Wificonfigurator
Bij dit netwerk configuratie programma is vooral ingegaan op de theoretisch moeilijke delen, zijnde de configuratie van de kanalen dan de wireless AP. Het programma in z’n geheel werkt nog niet maar ook hier zal in de komende jaren aan gewerkt worden. Dankzij het uitgelegde algoritme in sectie 6.1.2.3 is het mogelijk een goede benadering van een optimale configuratie te bereiken, binnen korte berekeningsduur (enkele seconden).
56
Literatuurlijst [1] Calinescu, Karloff, Rabani (2000). Approximation Algorithms for the 0Extension Problem [2] Aho, Lam, Sethi, Ullman (2007). Compilers: principles, techniques & tools. (2de druk). Old Tappan, NJ: Pearson [3] European Commission launches a consultation on the eHealth Action Plan (eHAP). (maart 2011). beschikbaar op 10 juni, 2011, van http://www.ipolicy.org/2011/04/european-commission-launches-a-consultation-on-theehealth-action-plan-ehap-2012-2020.html [4] RS232-monitor kabel, elektronisch schema. (november 2010). beschikbaar op 10 mei, 2011, van http://www.lammertbies.nl/comm/cable/ RS-232-spy-monitor.html [5] Soap specificatie. (2004). beschikbaar op 15 april, 2011, van http://www. w3.org/TR/soap/
57