Technisch ontwerp. Projectteam 6. Project "Web Essentials" 02 april Versie 2.1.0

Transcriptie

1 Projectteam 6 Faculteit Natuur en Techniek Hogeschool Utrecht Projectleider: Hans Allis, hans.allis@student.hu.nl Technisch ontwerp Project "Web Essentials" 02 april 2009 Versie Teamleden: Armin Ghassemi Gerben Strien Hans Allis Max Gramsma Peter Mols Wesley van Vliet

2 Pagina 1 i. Inhoudsopgave i. Inhoudsopgave...1 ii. Versiebeheer...2 Inleiding Software architectuur Use case realisatie...5 1e iteratie e iteratie Ontwerpbeslissingen...6 Inloggen bij elke functie(tijdelijk)... 6 Mapstructuur... 6 Meldingen... 6 MVC... 7 Layout... 7 Menu... 7 Centrale gegevens... 7 Front-end validatie... 7 Inloggen SugarCRM Modules Klassendiagram Code toelichting Proxy object...10

3 Pagina 2 ii. Versiebeheer Auteur Reden van verandering Datum Versienummer Gerben Strien Max Gramsma Start document H1, H2 toegevoegd Hoofdstuk ontwerpbeslissingen + ERD toegevoegd. Gerben Strien - H1 SugarCRM instellingen gewijzigd - H3 ontwerpbeslissingen gewijzigd - H2 hernoemt naar H5 - H2 Beschrijving realisatie toegevoegd - 2 e iteratie toegevoegd Gerben Strien - Inleiding toegevoegd - Alle hoofdstukken gedeeltelijk gewijzigd. - Use case van 2 e iteratie naar 3 e verplaatst - H5 klassendiagram toegevoegd Tabel 1: Gegevens over versies van dit document. 9 maart maart maart april

4 Pagina 3 Inleiding In dit verslag wordt de nodige technische informatie voor ons stage- en afstudeersysteem beschreven zodoende dat deze reproduceerbaar is door derden. Het stage- en afstudeersysteem bestaat uit twee delen namelijk de front-end die bestaat uit een PHP website en een back-end die bestaat uit SugarCRM. In dit verslag komen beide delen aan bod. In de volgende paragraaf is de inhoud van dit document per hoofdstuk kort beschreven. Als eerste wordt de Software architectuur beschreven waarin de gebruikte software en de daarbij horende versienummers staan. En ook de instellingen van SugarCRM de back-end worden hier beschreven. In het volgende hoofdstuk worden de use cases van het functioneel ontwerp erbij gehaald. Hiervan wordt beschreven hoe deze worden gerealiseerd qua programmeren. In het hoofdstuk daarna worden de ontwerpbeslissingen beschreven die wij hebben genomen. In hoofdstuk vier worden de modules beschreven die wij hebben aangepast in SugarCRM. In hoofdstuk 5 volgt een klassendiagram van de door ons ontwikkelde front-end. In het laatste hoofdstuk worden belangrijke code segmenten beschreven.

5 Pagina 4 1. Software architectuur In dit hoofdstuk wordt de software architectuur beschreven. Onze applicatie zal bestaan uit twee delen. Als eerste de front-end. Deze bestaat uit een website waar de gebruiker via een netwerk aangesloten PC bij kan. Als tweede de back-end, SugarCRM, een open-source CRM software pakket. Koppeling De front-end wordt via SOAP gekoppeld aan de back-end. SOAP is de taal om webservices mee aan te spreken. SugarCRM heeft een scala aan functies beschikbaar gesteld via het WSDL bestand. Hierdoor is het erg gemakkelijk om de verschillende functies te gebruiken via de front-end. Nu-SOAP library De Nu-SOAP library bevat een aantal handige PHP klassen die ontwikkelaars kunnen gebruiken om web services aan te roepen die gebruik maken van SOAP 1.1, WSDL 1.1 en HTTP 1.0/1.1. Wij maken gebruik van deze library om de functies van SugarCRM aan te roepen in onze front-end. Wij gebruiken versie voor de Nu-SOAP library. SugarCRM WSDL De verschillende SugarCRM functies zijn beschikbaar gemaakt via een WSDL bestand. Deze is te vinden via het volgende adres Een lijst van de functies en bijbehorende informatie is te vinden op SugarCRM instellingen Gebruikerstype Bij het aanmaken van een nieuwe gebruiker dient er een type gebruiker opgegeven te worden. Hiervoor is een gebruikerstype tekstveld toegevoegd aan de al bestaande Users module in SugarCRM. Relaties Er zijn relaties toegevoegd aan SugarCRM om de relaties op te kunnen slaan, die tussen de verschillende modules bestaan. Deze relaties zijn zowel tussen de eigen modules als de eigen modules van SugarCRM gelegd. Versienummers Doordat software constant in ontwikkeling is en er regelmatig nieuwe versies worden uitgegeven, is hieronder een overzicht te vinden van de versies van de gebruikte applicaties. Naam Versienummer CSS 2.1 MySQL Nu-SOAP library PHP phpunit Server OS FreeBSD 7.0-release-p11 SOAP 1.1 SugarCRM 5.2.0a WSDL 1.1 xhtml 1.1 Tabel 2: Gegevens over de versienummers.

6 Pagina 5 2. Use case realisatie In het functioneel ontwerp zijn verschillende use cases beschreven per iteratie. Die worden er in dit hoofdstuk weer bijgehaald en vervolgens wordt toegelicht hoe deze zijn geïmplementeerd. 1e iteratie Inloggen Als eerste zal gecontroleerd worden of de gegevens die de gebruiker in de gebruikersnaam en wachtwoord velden heeft ingevoerd overeenkomen met die uit de database van SugarCRM. Wanneer de gegevens volgens SugarCRM geen geldige combinatie vormen, dan wordt het webmailsysteem van de Hogeschool gebruikt om de inloggegevens te verifiëren. Als de gegevens volgens SugarCRM of het webmailsysteem correct zijn, dan wordt de gebruikersnaam in de sessie opgeslagen. Indien de logingegevens door SugarCRM goedgekeurd worden, dan wordt in de sessie ook het sessionid van SugarCRM opgegeven.. Gebruikers toevoegen (1/2) Dit is stap één van het gebruikers toevoegen waarbij de bestaande SugarCRM users - of "contacts"-module of de zelfgemaakte "student"-module wordt gebruikt om de gegevens in op te slaan. In deze stap wordt enkel het gebruikerstype gekozen, waarna de gebruiker naar stap 2 gestuurd wordt waar de bijbehorende velden worden getoond. 2e iteratie Gebruikers toevoegen (2/2) In deze cyclus wordt de tweede stap gerealiseerd voor het toevoegen van gebruikers. Hierbij wordt aan de hand van de gebruikerstype keuze uit stap één de velden getoond die bij die keuze horen. Stagebedrijven toevoegen Hier zal een apart module voor worden aangemaakt via SugarCRM s Module builder genaamd bedrijven.

7 Pagina 6 3. Ontwerpbeslissingen Er zijn verschillende ontwerpbeslissingen genomen voor en tijdens het ontwikkelen. Deze worden hier beschreven. Inloggen bij elke functie(tijdelijk) Update: Dit probleem is opgelost. Op dit moment wordt er bij elke functie in de code opnieuw het SOAP object aangemaakt. Dit is een tijdelijke oplossing, de bedoeling was om dit object in de sessie te bewaren, maar dit werkt niet goed. Hier zal nog een betere oplossing voor worden bedacht, maar om nu toch door te kunnen gaan maken we het object elke keer opnieuw aan. Mapstructuur De mapstructuur zal er uiteindelijk als volgt uit komen te zien: sugar/ cache/ Modules/ Docent/ Stage/ Activedirectory/ Inloggen/ Student/ Bedrijvenbeheer/ Gebruikersbeheer/ Homes/ Libs/ nusoap/ Klassen/ Functies/ Tests/ css/ images/ Op deze manier blijft alles duidelijk gescheiden van elkaar. Alle verschillende modules krijgen een eigen map waarin de controllerklasse staat met de naam Controller.php. Doordat het lastig is en heel veel bestanden oplevert wanneer een enkele klasse over verschillende bestanden wordt verdeeld is hiervoor gekozen. Per module is een map "View" aanwezig, waarin per methode van de controller een bestand staat dat de benodigde HTML weergeeft aan de gebruiker. Meldingen Verschillende meldingen zoals foutmeldingen worden in een array gestopt zodat die later netjes één voor één getoond kunnen worden op het scherm. Foutmeldingen worden in een andere array gestopt dan de rest van de meldingen. Omdat er dan ook gecontroleerd kan worden of de foutmeldingen array leeg is. Als die leeg is dan zijn er dus geen fouten opgetreden.

8 MVC Technisch ontwerp Pagina 7 Wij hebben er voor gekozen om het Model-View-Controller ontwerppatroon toe te passen. Dit zal de leesbaarheid en herbruikbaarheid van de code bevorderen. De view en controller bestanden zijn binnen de modules geplaatst in de gelijknamige mappen. De model bestanden zijn geschreven in de vorm van klassen en zijn in de Klassen map geplaatst. Layout Ook de opmaak is gescheiden deze is te vinden in het css mapje. De layout voor het geheel wordt in het bestand layout.php aangegeven. Menu Ook het menu is in een apart bestand opgenomen omdat deze op elke pagina zichtbaar is. Op deze manier hoeven we maar één bestand daarvoor te gebruiken en aan te passen indien nodig. Centrale gegevens Al de gebruiker gegevens en de daarbij horende informatie wordt opgeslagen in bestanden die gerelateerd zijn aan de klasse. Er kan bv. een student worden aangemaakt via onze appliatie hiervoor is dan ook een apart bestand te vinden genaamd student. Dit bestand bevat een array met alle informatie die daarbij hoort. Zo hebben we dus een centrale plek voor alle informatie mbt. één object voor de front-end. Wat inhoud dat we alleen hier wijzigingen hoeven aan te brengen die vervolgens voor de gehele front-end gelden. Front-end validatie Via Javascript zijn er verschillende validatiefuncties geschreven die worden aangeroepen als de gebruiker bv. een formulierveld verlaat. Inloggen Door via een formulier de inloggegevens op te vangen kunnen deze doorgestuurd worden naar SugarCRM. Dit wordt gedaan door de inlogfunctie aan te roepen via SOAP. SugarCRM handelt het inloggen verder af. Er wordt nog wel een inlogobject aangemaakt via onze eigen Inloggen klasse waar gebruikersnaam, wachtwoord en sessie ID worden opgeslagen. Dit object wordt gebruikt om de eerdergenoemde gegevens op te roepen indien deze nodig zijn voor een SugarCRM functie aanroep.

9 Pagina 8 4. SugarCRM Modules De volgende modules zijn toegevoegd of gewijzigd binnen SugarCRM. Deze tabellen zouden gebruikt kunnen worden om SugarCRM opnieuw klaar te maken voor gebruik. Dit gebeurt via de Studio en Module builder in het admin menu. Student Uitbreiding op Person Naam parent_name username zkverzekeraar zkpolisnummer ongverzekeraar ongpolisnummer repverzekeraar reppolisnummer waverzekeraar wapolisnummer Type

10 Pagina 9 5. Klassendiagram In dit hoofdstuk wordt het klassendiagram van de front-end getoond. Deze dient om de architectuur van de applicatie duidelijk te maken door de relatie tussen verschillende klassen/objecten te tonen en de daarbij horende attributen en functienamen te vermelden.

11 Pagina 10 6.Code toelichting In dit hoofdstuk worden belangrijke code segmenten beschreven die gebruikt kunnen worden om het product te reproduceren. Proxy object Om via PHP functies te gebruiken van de webservice kan een proxy object gebruikt worden. Hieronder de code die ik gebruikt heb om dit te realiseren. Als eerste wordt er een soap client object aangemaakt met de URL naar het WSDL bestand. Vervolgens wordt het proxy object aangemaakt door getproxy() aan te roepen. $soapclient = new soapclient($soap_url,true); $this->proxy = $soapclient->getproxy(); Een functie zoals bijvoorbeeld login kan zo worden aangeroepen. $this->proxy->login($params,'sugarcrm');