Het communiceren van een waarde is nu vrij simpel:
backOffice.newValue(at.getModuleID(), "LED1", (short)1);
Echter, het verwerken hiervan is een complexere zaak. Dit omdat de klasse BackOfficeImpl het liefst niet geïnstantieert mag worden. De oplossing zit hem in het aanmaken van Watchdog, welke gebruikt wordt door
BackOfficeImpl om aanroepen af te handelen. De argumenten worden daarom ook gewoon doorgegeven.
De daadwerkelijke afhandeling bestaat uit het aanmaken van een Value object, waarin de argumenten gestopt worden. Daarna moet de Queue weten, zonder dat deze direct aangeroepen kan worden, dat er een nieuw
Value object is om op te nemen in de wachtrij.
Om ervoor te zorgen dat Queue deze waarde kan krijgen zonder dat deze een instantie van Watchdog nodig heeft wordt het observer patroon gebruikt. Om dit mogelijk te maken moeten drie zaken geïmplementeerd worden. De eerste twee zaken betreft de definitie van de twee klassen. Watchdog wordt in de gaten gehouden door Queue, wat te zien is aan:
public class Watchdog extends Observable
public class Queue implements Observer
Om ervoor te zorgen dat het programma ook daadwerkelijk weet welke klasse wat in de gaten houdt wordt
addObserver(Observer o) aangeroepen voor Watchdog. Zodra dit is gedaan werkt Code voorbeeld C en zal
deze een Value object opgooien, welke door Queue afgevangen en in de Vector met Values wordt opgeslagen in Code voorbeeld D.
Value v = new Value(type, value, source); setChanged();
notifyObservers(v);
Code voorbeeld C – Value aanmaken in Watchdog voor Queue
public void update(Observable obj, Object arg)
{
Value i = (Value)arg;
myQueue.add(i); }
Queue is een klasse die als nieuwe thread naast het hoofdprogramma kan draaien. Er wordt hierin constant gekeken naar of de Vector leeg is. Is deze dat niet, dan wordt de waarde die als eerste opgeslagen is naar
Acquisition doorgegeven en uit myQueue gehaald. Ook dit gebeurt door middel van het observer patroon.
De verhouding tussen Acquisition en Queue is hierin dezelfde als die tussen Queue en Watchdog. Nu heeft de gebruiker een keuze; of hij kiest ervoor om de eerst toegevoegde waarde uit te lezen, of hij kiest ervoor om alle waarden van een specifieke bron uit te lezen. In het laatste geval kan dus prioriteit worden gegeven aan een module. Hoe dit gebeurt is in Code voorbeeld E te zien.
public Vector<Value> fromSource(String source)
{
Vector<Value> temp = new Vector<Value>(); Iterator<Value> i = myValues.iterator(); Value myVal = null;
while(i.hasNext()) { myVal = i.next(); if(myVal.getSource().equals(source)) temp.add(myVal); } return temp; }
Code voorbeeld E – Waarden van specifieke bron opvragen
De gewenste bron wordt in een simpele String bepaald. Aan de hand van dit argument zal deze methode bepalen of een Value van een bepaalde bron afkomt. Value heeft immers het attribuut source(een String).
Een tijdelijke Vector wordt aangemaakt waarin het gevonden resultaat in opgeslagen wordt om terug te
geven tijdens de aanroep. Met het gebruik van een Iterator is het erg makkelijk om door een Vector te
stappen. De methode doet dit zolang er volgens de Iterator nog een volgend object is. Dit object wordt in
Value myVal opgeslagen. Door dit te doen kan er eerst gekeken worden naar gelijkenis tussen de twee
bronnen en kan daarna, indien de bronnen gelijk zijn, de waarde toegevoegd worden.
Debugging
Tijdens de duur van het project is telkens gebruik gemaakt van RS232 om de embedded applicatie te debuggen. Dit omdat er geen mogelijkheid is om het programma op een vooraf gespecificeerd punt stil te zetten en naar de eigenschappen te kijken, zoals bij een Java programma in Eclipse wel mogelijk is. Hiertoe is in het logging pakket een Debugger klasse aangemaakt. Hoe gelogd wordt is in Code voorbeeld F te zien.
private OutputStream outStream = null;
private StreamConnection sc = null;
public Debugger()
{ try {
sc = (StreamConnection) Connector.open("comm:3;baudrate=115200", Connector.READ_WRITE);
outStream = sc.openOutputStream(); }
catch(Exception e){}
}
public void debug(String s)
{ try { s = s + "\r\n"; outStream.write(s.getBytes()); }
catch(Exception e){}
}
5 Testen van Custodian
®Ook de implementatie van het V-model zoals deze bij het afstudeerbedrijf toegepast wordt bevat het schrijven van een testontwerp en aan de hand hiervan de software testen. Dit staat gepland na voltooiing van het afstudeerdocument. W el is al tijdens het schrijven van het Research Document extensief aan prototyping gedaan voor verschillende oplossingen. Dit heeft geleid tot het testen van kleine onderdelen van de code, zoals het opzetten van een CORBA connectie of RS232 communicatie, nog voordat aan de implementatie van het gehele systeem was begonnen. Voor de prototyping testen en resultaten zie het [Research Document]. Het voordeel van het gebruik van de Watchdog is dat de methoden hierin aangeroepen kunnen worden door zowel de CORBA implementatie als de ontwikkelaar zelf. Om implementatie op de Back Office te kunnen testen is dus gebruik gemaakt van aanroepen rechtstreeks op de Watchdog met zelf opgestelde waarden. Hierdoor worden fouten in de Embedded module en de CORBA overdracht uitgesloten van de werking van de Back Office en kan deze makkelijker getest worden.
Voor de Embedded module is gebruik gemaakt van de bijgeleverde software simulator (te zien in figuur 21). Hierop kan een imlet getest worden zonder gebruik te hoeven maken van een externe server. Met behulp van deze simulator is ook de CORBA functionaliteit te testen zonder gebruik te hoeven maken van een
internetverbinding, wat fouten die worden veroorzaakt buiten de macht van de ontwikkelaar om, grotendeels uitsluit.
6 Resultaten en Conclusies
6.1 Resultaten
In het begin van het project is het belang van het Research Document (Techniekanalyse 1) voor de opdracht onderschat. Dit houdt in dat de planning hierdoor uitgelopen is, zoals in figuur 22 en 23 te zien is. De originele planning is op pagina 15 te vinden.
Figuur 22 - Uiteindelijke planning (1/2)
Figuur 23 - Uiteindelijke planning (2/2)
In eerste instantie werd aangenomen dat het Research Document binnen vier weken klaar zou zijn, maar uiteindelijk is deze periode verdubbeld. Dit is voornamelijk door het verkeerd inschatten van de omvang van dit onderdeel, maar ook omdat het document niet in één poging goedgekeurd is. Echter, een groot deel van de resultaten uit het Research Document zijn rechtstreeks te gebruiken in de implementatie van het monitoring gedeelte. Tijdens deze implementatie staken echter telkens weer problemen met de communicatie van CORBA de kop op. De in het Research Document al beschreven lastige samenwerking met bedrijfsnetwerken is hierbij een grote bottleneck geweest.
Na een tijdje is hierbij ook in overleg besloten om de communicatie in SOAP te implementeren. Ook hier kwamen echter problemen aan het licht: de J2ME library van de 12i module is niet geschikt om van SOAP gebruik te maken (ook dit nadeel is in het Research Document beschreven). Het gebruik van externe bibliotheken was dan ook de volgende stap. Tijdens verder onderzoek naar SOAP implementaties kwam echter een oplossing voor de CORBA implementatie aan het licht. Uiteindelijk is een werkend prototype voor de Custodian® Back Office en Custodian® Embedded opgeleverd.
Ondanks dat tijdens de implementatiefase veel tijd verloren is gegaan aan deze problemen is hierdoor wel veel nieuwe kennis opgedaan. De uitloop heeft ertoe geleid dat het onderzoek doen naar en het
implementeren van de remote updating optie niet tot stand is gekomen. In de planning valt op dat er 23 weken zijn ingepland. Er is in week 15 tijd verloren gegaan met een aantal feestdagen, waar op het moment van planning geen rekening mee gehouden was. Omdat het ziekteverzuim al vrij vroeg in de afstudeerperiode plaatsvond is de planning hier direct op aangepast en de einddatum later gelegd.
Ondanks uitloop van de planning is het merendeel aan deliverables opgeleverd. Ook worden er na het inleveren van dit document meerdere nog gemaakt. De opgeleverde deliverables van de afstudeerperiode van vóór het opleveren van dit document zijn als volgt:
- Oriëntatieverslag (19 pagina’s) - Plan van Aanpak (14 pagina’s) - Research Document (35 pagina’s)
- Software Requirements Document (9 pagina’s) - Architectural Design Document (27 pagina’s) - Custodian® implementatie
Na het opleveren van dit document zullen de volgende deliverables nog opgeleverd worden na het inleveren van dit document:
- Test Design Document - Testrapport
- Handleiding
- Afstudeerpresentatie - Afstudeerposter (+ website)
6.2 Conclusie
De hoofdvraag tijdens de afstudeerperiode was of als Custodian® opnieuw ontworpen en geïmplementeerd zou worden, er dan andere ontwerpbeslissingen met betrekking tot nieuwe technieken genomen zouden worden. Dit is het geval, echter kan me zich dan afvragen of dit van toegevoegde waarde op het oude systeem is. In de laatste jaren zijn er geen grote nieuwe spelers in het RPC veld gekomen en degenen die erbij zijn gekomen hebben geen toegevoegde waarde voor het Custodian® project.
Wat betreft de andere technieken uit de SOAP generatie versimpelt CORBA de implementatie van
communicatie maar vergt van gebruikers dat zij een drietal poorten beschikbaar stellen in hun netwerk, wat een mogelijk beveiligingslek vormt. SOAP gebruikt de HTTP(S) poort maar is op de huidige module lastiger te implementeren. Uiteindelijk gaat het puur om de wens van de klant en hebben zowel CORBA en SOAP voordelen als nadelen. Ook hier is de vraag of het verstandig is om Custodian® compleet opnieuw te implementeren indien er al een werkend SOAP ontwerp bestaat.
Daarnaast is de module zelf sterk verouderd. De Nokia-12i wordt niet meer geproduceerd en wordt ook niet meer ondersteund. Verder zijn de bijgeleverde developer tools instabiel en lastig in het gebruik. Zo is het enige beschikbare programma om imlets (programma’s gecompileerd voor gebruik op de Nokia-12i) naar de module in te laden niet alleen erg langzaam, maar ook erg kwetsbaar. De zogehete Aplicom Configurator mag geen externe invloeden waarnemen tijdens zowel het opstarten als het afsluiten, of deze loopt genadeloos vast. Dit is van aanzienlijke invloed geweest op de voortgang van de ontwikkelcyclus. De tijd die het kost om een imlet te uploaden is te lang.
Samenvattend is de conclusie van dit project dat het wel degelijk mogelijk is om met de huidige hardware een nieuwe implementatie van Custodian® te ontwerpen, maar dat het bedrijf zich erg goed moet afvragen of dit wel verstandig is met betrekking tot tijd en kosten. De mogelijkheid bestaat dat het optimaliseren van het oude systeem wat tijd en kosten betreft voordeliger is.
7 Aanbevelingen
Met betrekking tot het Custodian® project worden hier aan ICT Embedded B.V. een aantal aanbevelingen gedaan. De meeste hebben betrekking op de te gebruiken hardware, maar ook voor het toekomstig gebruik van communicatieprotocollen wordt een aanbeveling gedaan.
7.1 Nokia-12i
Zoals eerder aangegeven is deze module tijdens de loop van het project veelvuldig gebruikt. Hierdoor is duidelijk geworden voor de afstudeerder dat er een groot aantal problemen zich voordoen bij het gebruik hiervan. Dit heeft met drie factoren te maken.
• Een van de grotere hiervan is de gebruikte J2ME library. Normaliter biedt J2ME alle functies die een ontwikkelaar nodig heeft om M2M functionaliteit te implementeren. Nokia heeft hier een eigen variant op gemaakt en alle functionaliteit waarvan het onwaarschijnlijk is dat deze op de 12i gebruikt zal worden weggehaald. Helaas valt ook XML hieronder. Het probleem is dus dat om hiervan gebruik te kunnen maken een externe library gebruikt moet worden, welke meer dan eens te groot zijn voor het beperkte geheugen van de embedded module, of op hun beurt weer gebruik maken van functionaliteit die niet in de J2ME library van de 12i aanwezig is.
• Hiernaast is er de manier waarop een imlet gecompileerd moet worden onhandig. De bijgeleverde SDK biedt geen ondersteuning voor het compileren van de java code naar het bestand dat nodig is om het programma op de module te draaien. Dit houdt dus in dat er een behoorlijk lang XML bestand gemaakt moet worden, waarin de complete procedure van het compileren zelf aangegeven is.
• Tot slot is de Nokia-12i/Aplicom Configurator instabiel en omslachtig in het gebruik. Het bijgeleverde programma moet gebruikt worden om imlets naar de Nokia-12i the uploaden en hier is geen alternatief voor. Zodra het programma opgestart wordt, is het van belang dat de ontwikkelaar niets anders op zijn machine doet, zelfs de Configurator minimaliseren zorgt ervoor dat deze zijn taak niet meer uit kan voeren. Het komt meer dan eens zelfs voor dat in rust een kritieke fout zich voordoet, omdat de
Configurator erg instabiel is. Om een overdracht te starten moeten teveel acties uitgevoerd worden en het opnieuw op laten starten van de imlet bij het afsluiten van het programma is een slechte
ontwerpbeslissing geweest. Dit zorgt er namelijk niet voor dat objecten verwijderd worden en heeft als gevolg dat de imlet niet goed zijn werk doet.
Al met al is de aanbeveling met betrekking tot the Nokia-12i als volgt. Indien er in de toekomst een nieuwe implementatie van het Custodian® project plaats vindt, dan is het van belang dat er eerst nieuwe M2M hardware wordt uitgezocht. Het scheelt niet alleen een hoop ontwikkeltijd, maar vooral veel frustratie.
7.2 Berichtprotocol
Door de grote invloed van de hardware op de werking van de connectie is het verstandig om voor dit en eventueel andere projecten een onderzoek te laten doen naar de werking van berichtprotocollen,
onafhankelijk van hardware. Het kan ook voor komen dat bij een ander project interactie moet plaatsvinden tussen programma’s in verschillende programmeertalen en het is daarbij nuttig om van de aanwezige berichtprotocollen kennis op te doen en de voor- en nadelen tegen elkaar uit te zetten.
Gebeurt dit op één machine, dan is de werking van het internet en eventueel kleinere bibliotheken niet net zo bepalend voor de uitvoering als het bij Custodian® is. Het is dan een stuk simpeler om de werking en
prestaties van SOAP, CORBA en ICE tegenover elkaar te zetten en hier eventueel zelfs Thrift en XINS (RPC specificaties die op het moment nog in ontwikkeling zijn) aan toe te voegen. De kennis die in zo’n onderzoek opgedaan kan worden, is wijdverspreid inzetbaar.
7.3 Custodian
®Indien er geen vervolg komt op bovenstaande aanbevelingen, dan is het verstandig om het reeds bestaande Custodian® systeem te optimaliseren voor werking in plaats van dit opnieuw op te bouwen. In verband met de beschikbare mogelijkheden en de afweging van CORBA tegen SOAP zal een voortzetting op de nieuwe implementatie die uit het afstudeerproject is voortgekomen geen toegevoegde waarde hebben tegenover het oude systeem.
8 Persoonlijke ontwikkeling
8.1 Competenties
In het Oriëntatiedocument heb ik mezelf een aantal leerdoelen gesteld op het persoonlijke vlak. Tijdens de afstudeerperiode ben ik hier continue naar terug gegaan om mezelf eraan te herinneren wat ik had voorgenomen om aan te werken. Niet alle situaties zijn teruggekomen binnen de periode, vandaar dat hieronder de belangrijkste zijn beschreven.
C4.10: “Heeft in onderhandelingssituaties binnen afstudeersituaties oog voor het verschil in de belangen van zichzelf en van de ander en anticipeert op de onderhandelingssituatie door een realistische ondergrens en een onderhandelingsmarge te bepalen.”
Door uitloop in het project werden mijn technisch begeleider en ik gedwongen om bepaalde delen van de opdracht te laten vallen. Ik ben zelf deel geweest van het gesprek hierover en ik heb hiervoor met het oog op de situatie en de verwachtingen vanuit het afstudeerbedrijf een voorstel aangedragen voor de nu opgeleverde producten. Dit heb ik goed gedaan, aangezien mijn technisch begeleider hiermee akkoord ging.
P4.7: “Gaat soepel om met valkuilen, onvoorziene problemen, handhaaft zo veel mogelijk de gemaakte planning in de afstudeersituatie.”
Zoals eerder in dit document te lezen was, is het afstudeerproject niet altijd even soepel verlopen. Toch heb ik in deze periode me daardoor niet uit het veld laten slaan en ben snel met alternatieven en oplossingen gekomen. Dit is ook een positief punt geweest dat mijn proces begeleider aangedragen heeft.
Aan de andere kant verliep daardoor het werken volgens de planning niet perfect, mede door een lange uitloop tijdens het schrijven van het Research Document. Het probleem lag in deze niet zozeer bij het volgen van de planning, maar bij het opstellen hiervan. Het is voor de volgende keer zeer belangrijk om vooraf goed na te gaan wat de omvang van de deliverables is en om uitloop in te plannen.
A4.7: “Benoemt oplossingsalternatieven met bijbehorende kansen, risico’s en consequenties in een afstudeersituatie.”
Hoewel ik in het begin van de afstudeerperiode nog veel aan één oplossing per probleem dacht ben ik gaandeweg het project gaan realiseren dat er meerdere oplossing voor een probleem kunnen zijn, elk met zijn eigen voor- en nadelen. Ik ben dan ook zelf tijdens de implementatie met alternatieven en oplossingen gekomen die na afweging het beste bleken te zijn.
L4.6: “Laat zien te geloven in de eigen capaciteiten in een afstudeersituatie om goed werk af te leveren gericht op het eindprofiel van de opleiding.”
Ondanks de tegenslagen tijdens het afstudeerproject heb ik geen enkel moment getwijfeld aan mijn eigen capaciteiten om de periode tot een geslaagd einde te brengen. Dit is voor mijzelf een enorm belangrijke ontwikkeling, omdat ik nu er zeker van ben dat ik nieuwe uitdagingen altijd met goede moed aan kan pakken en er niet vooraf vanuit ga dat iets buiten mijn bereik ligt. Het zelfvertrouwen wat ik opgebouwd heb zal mij mijn gehele carrière ten goede komen.
8.2 Vaardigheden
Tijdens de afstudeerperiode heb ik veel ervaring opgedaan met een aantal voor mij nieuwe tools en technieken:
- J2ME - CORBA - SOAP - ANT
- Observer patroon in Java implementeren - Nokia-12i
- Filezilla - RealVNC - TortoiseSVN
- Java W ireless Toolkit - StarUML