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

Projectteam 6 Faculteit Natuur en Techniek Hogeschool Utrecht Projectleider: Hans Allis, [email protected]

Technisch ontwerp Project "Web Essentials" 02 april 2009

Versie 2.1.0 Teamleden: Armin Ghassemi Gerben Strien Hans Allis Max Gramsma Peter Mols Wesley van Vliet

Technisch ontwerp Team 6 Pagina 1

i. Inhoudsopgave

i. Inhoudsopgave ............................................................................................... 1 ii. Versiebeheer ................................................................................................ 2 Inleiding.......................................................................................................... 3 1. Software architectuur ..................................................................................... 4 2. Use case realisatie ......................................................................................... 5 1e iteratie .................................................................................................................. 5 2e iteratie .................................................................................................................. 5

3. 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 ..................................................................................................................... 7

4. SugarCRM Modules.......................................................................................... 8 5. Klassendiagram ............................................................................................. 9 6.Code toelichting ........................................................................................... 10 Proxy object...............................................................................................................10


ii. Versiebeheer Auteur

Reden van verandering

Datum

Versienummer

Gerben Strien

Start document H1, H2 toegevoegd

9 maart 2009

1.0.0

Max Gramsma

Hoofdstuk ontwerpbeslissingen + ERD toegevoegd.

11 maart 2009

1.1.0

H1 SugarCRM instellingen gewijzigd 18 maart 2009 H3 ontwerpbeslissingen gewijzigd H2 hernoemt naar H5 H2 Beschrijving realisatie toegevoegd 2e iteratie toegevoegd

2.0.0

Inleiding toegevoegd Alle hoofdstukken gedeeltelijk gewijzigd. Use case van 2e iteratie naar 3e verplaatst H5 klassendiagram toegevoegd

2.1.0

Gerben Strien

-

Gerben Strien

-

Tabel 1: Gegevens over versies van dit document.

2 april 2009


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.


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 0.7.2 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 http://domeinnaam/SugarCRM/soap.php?wsdl. Een lijst van de functies en bijbehorende informatie is te vinden op http://domeinnaam/SugarCRM/soap.php.

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 CSS MySQL Nu-SOAP library PHP phpunit Server OS FreeBSD SOAP SugarCRM WSDL xHTML Tabel 2: Gegevens over de versienummers.

Versienummer 2.1 5.0.67 0.7.2 5.2.9 3.3.10 7.0-release-p11 1.1 5.2.0a 1.1 1.1


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”.


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/ View/ Stage/ View/ Activedirectory/ View/ Inloggen/ View/ Student/ View/ Bedrijvenbeheer/ View/ Gebruikersbeheer/ View/ Homes/ View/ 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.

Technisch ontwerp Team 6 Pagina 7 MVC 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.


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 Textfield Textfield Textfield Textfield Textfield Textfield Textfield Textfield Textfield Textfield


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.


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');

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

Recommend Documents