Toon posts:

[Alg] Ontwerp applicatie

Pagina: 1
Acties:

Verwijderd

Topicstarter
Momenteel ben ik samen met mijn collega bezig met het ontwerp achter een tamelijk ingewikkelde applicatie. Er zijn echter nog een aantal heikelpunten. Graag zouden we de mening van onze medetweakers horen. Ik zal de situatie kort omschrijven.

Het gaat om een applicatie die over meerdere locaties gebruikt zal worden. De applicatie moet volledig realtime zijn. Wanneer er gegevens op de ene locatie worden ingevoerd dan moeten deze op het hoofdkantoor meteen zichtbaar zijn.

Verder bestaat er de wens dat er gebruik wordt gemaakt van thinclients op de locaties. Dit om de kosten van het onderhoud zo laag mogelijk te houden. De thinclients en servers moeten allemaal op linux draaien.

Maar er zijn nog meer wensen. De layout van de applicatie moet makkelijk zijn te wijzigen. De taal waarin de applicatie geschreven wordt is C++. De thinclients zullen worden aangestuurd d.m.v. een touchscreen. Tenslotte moet de thinclient in staat zijn externe apparatuur aan te sturen. Dit verklaart deels de keuze voor C++ (tesamen met het gewenste platform).

De grote vragen waar we momenteel nog geen concreet antwoord op hebben weten te vinden:

- Hoe zal de thinclient zijn C++ applicatie starten? Hoe zullen updates worden doorgevoerd? Terminal server? Mini-OS op de thinclient die de applicatie 's avonds van de centrale server ophaalt? Een push vanaf de centrale server?

- Hoe scheiden we de applicatie interface van de applicatie logica? Het ontwerp van de interface zou makkelijk aanpasbaar moeten zijn voor leken. Het bedrijf wil zelf zijn layout aan kunnen passen. Apart configuratie bestand? Gecompileerde module die dynamisch geladen wordt? Zijn hier standaard oplossingen voor waar wij nog niet van op de hoogte zijn?

Wanneer iemand hier creatieve oplossingen voor kan bedenken dan horen wij die uiteraard graag 8)
Bij voorbaat dank :)

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 22-01 23:51

NMe

Quia Ego Sic Dico.

Het scheiden van interface en business logic lijkt me zo'n probleem niet, zeker niet als je met C++ werkt. Simpelweg een MVC implementeren, of een andere vorm van een meerlagenmodel lijkt me redelijk basaal en voldoende om de scheiding die jij wil te realiseren? :)

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


Verwijderd

Topicstarter
Ik ben bekend met MVC en dat is ook niet zo zeer het probleem.
Het probleem zit hem in het feit dat ik de desbetreffende leken niet rechtstreeks in code wil laten trekken. Ik moet de view laag op een dergelijke manier uitvoeren dat grafische mannetjes de grafische kant van de applicatie tot in detail aan kunnen passen.

Dan is het dus geen optie om de view laag geheel in C++ uit te voeren. Dus moet ik hier een andere oplossing voor bedenken. Het werken met losstaande configuratie bestanden vind ik tamelijk rommelig en biedt geen mooie oplossing voor het opslaan van resources.

Een tool om visual studio resource files te laden zou veel beter passen. Echter ben ik me niet bewust van een dergelijke tool. Ik zoek dus eigenlijk een rapid development tool waarmee de desbetreffende grafische mannetjes de grafische schil aan kunnen passen zonder dat er code aan te pas komt.

Ik zou echter geen idee hebben of een dergelijke tool bestaat :P. Iig niet onder het Linux platform ;)

  • zwippie
  • Registratie: Mei 2003
  • Niet online

zwippie

Electrons at work

Verwijderd schreef op woensdag 24 mei 2006 @ 12:22:
Ik zoek dus eigenlijk een rapid development tool waarmee de desbetreffende grafische mannetjes de grafische schil aan kunnen passen zonder dat er code aan te pas komt.

Ik zou echter geen idee hebben of een dergelijke tool bestaat :P. Iig niet onder het Linux platform ;)
Voor linux heb je bijvoorbeeld Glade, een GUI builder (voor gtk+/gnome). Al kan ik zo natuurlijk niet zeggen of dit 'past' bij jullie app ;)

How much can you compute with the "ultimate laptop" with 1 kg of mass and 1 liter of volume? Answer: not more than 10^51 operations per second on not more than 10^32 bits.


  • Sammy
  • Registratie: Maart 2000
  • Laatst online: 16-02 22:25
Verwijderd schreef op woensdag 24 mei 2006 @ 12:22:
Ik moet de view laag op een dergelijke manier uitvoeren dat grafische mannetjes de grafische kant van de applicatie tot in detail aan kunnen passen.
Ben ik de enige die hier veeel problemen zie? Een prachtige requirement natuurlijk en een leuke uitdaging, maar weet je zeker dat je boel niet nauwer kunt specificeren (en IMO dus robuuster kunt maken)?

Verwijderd

Verwijderd schreef op woensdag 24 mei 2006 @ 12:22:
Een tool om visual studio resource files te laden zou veel beter passen. Echter ben ik me niet bewust van een dergelijke tool. Ik zoek dus eigenlijk een rapid development tool waarmee de desbetreffende grafische mannetjes de grafische schil aan kunnen passen zonder dat er code aan te pas komt.
Wellicht dat je een van de vele "skinning"-engines kunt gebruiken op de markt? (Die van WinAMP is erg krachtig, maar ik weet niet of dat wel C++ is -- en of die uberhaupt nog open source is).

  • SPee
  • Registratie: Oktober 2001
  • Laatst online: 19-02 19:02
Of je limiteerd de ontwerpers in hun mogeljikheden.
Bv door te zeggen; die knoppen worden geladen aan de hand van dat plaatje, de background is dat plaatje, etc. en eventueel een tekstbestand dat de diverse kleurmogelijkheiden instelt (ala css). Als je het dan wil aanpassen, moeten ze andere plaatjes gebruiken.
Dan blijven de wijzigingen ook niet zo groot en is het wat makkelijker te doen.
Ik denk dat het andere bedrijf dit ook wel inziet als de kosten te groot gaan worden, ipv volledig aanpasbaar. :)

Hoe het gestart wordt is volgens mij in te stellen door hem in een bepaalde usermode te laten starten. Misschien is dit als zelfs via een netwerkshare te doen.

let the past be the past.


Verwijderd

Wat is reden dat ze de layout zelf aan willen passen? Vaak is het zo dat de layout aangepast moet worden als gevolg van een wijzigende requirement. 99 van de 100 keer heeft dit ook een code change tot gevolg, niet alleen een layout change. Als de programmeur dan toch aan de slag gaat...

Verwijderd

Is het trouwens al duidelijk welke thin-client er zal komen, of mogen jullie dat zelf bepalen? Veel thin-clients draaien wel een OS, bijvoorbeeld Embedded XP, Windows CE, een Linux distributie, etc.

Heeft een thin-client geen OS draaien dan moet hij aangesloten zijn op een server die een instantie van het OS draait voor die client, zoals bijvoorbeeld in een Citrix omgeving gebeurt. Nadeel daarvan is dat het weer lastig is om externe apparaten aan te sturen. Al met al denk ik dat een thin-client met OS het beste werkt in dit geval.

Het installeren van nieuwe versie van de software kun je dan ook doen buiten het touch-screen om dmv administratie op afstand.

Verwijderd

Van grapische Trucs in C++ (Ben zelf .NET/Java Ontwikkelaar) heb ik geen kaas gegeten, maar ik kan wel een adviesje geven over hoe ik het zelf misschien in .NET zou aanpakken.
Gezien het feit de Thin Client met Touchscreen bedient moet worden, kun je waarschijnlijk geen standaard controls gebruiken (te klein), je zal dus de controls zelf moeten bouwen.
Misschien is het mogelijk om elke zelf gebouwde control van meerdere look & Feels te voorzien? De Look & Feel kun je dan switchen door een property?
(Zo maar een idee, zoals ik zei, ik ben niet bekend met C++)

Waar ik het over wilde hebben, is een mogelijke Architectuur.
Misschien is het een goed idee om een Thin Client - (Web) Service Architectuur te gebruiken?
Alle Business Logica bevind zich dan op de server. De Thin client doet niet meer dan verzoeken om informatie en informatie opvragen van de service.
De Thin client zal in jouw geval dan bestaan uit de View laag (voor weergave), een mini control laag (voor communicatie met de service), en de nodige logica voor communiceren met externe aparatuur.

Nadeel van een Service-Oriented Architecture is dat een permanente verbinding met de Service noodzakelijk is. (Alhoewel daarop eventueel ook wat te bedenken valt). Kijkend naar jouw verhaal, is een permanente verbinding zowieso nodig, omdat gegevens altijd up to date moeten zijn.

De Service triggerd geen clients, de clients moeten zelf de service om geupdate gegevens vragen.
Je kan geupdate gegevens opvragen "on-request", wanneer de gebruiker aangeeft de gegevens nodig te hebben, worden ze opgehaald. Wat ook kan, is een client periodiek aan de service laten vragen of er nieuwe gegevens zijn. De laatste optie zal alleen wel je service meer belasten.

Een laatste issue waar je rekening mee moet houden in een Service-Oriented Architecture is hoe wijzigen van gegevens plaats vind. Worden de gegevens iedere keer geupdate wanneer iemand een update stuurt. (Waarbij mensen elkaar gegevens kunnen overschrijven), of blokkeer je gegevens voor wijziging zodra deze voor wijziging opgevraagd worden?

Veel succes in ieder geval!
Pagina: 1