Monday Assignment 2, Kas van 't Veer (6292437) - matthijsbos/swe2013team5 GitHub Wiki
2
Analyse Sakai
Twee delen
De architectuur van Sakai bestaat uit twee hoofddelen: een abstracte architectuur en een design gebaseerd op Java. Sakai is bedoeld om te worden gebruikt als een client/server koppel. De client heeft enkel een internetbrowser terwijl de daadwerkelijke software op de server staat. Deze abstractielaag is bedoeld om de client en de server aan elkaar vast te koppelen. De abstracte architectuur bestaat uit vier lagen. De 'Aggregator' laag regelt scherm en enkele gebruikersinteracties met de interface. De 'Presentatie' laag combineert data van Sakai-tools met de gebruikersinterface die de aggregatorlaag naar de user stuurt. De 'Tools' laag zijn de geschreven Sakai applicaties, dus programmacode welke gebonden is aan de user interface en zo data kan veranderen van de services. De 'Services' laag staat het dichtste op het systeem zelf en bestaat uit een aantal klassen bij elkaar die de data managen volgens vaste routines.
Lagen
Sakai is een open source project, iedereen die iets in te brengen heeft zou dus in principe kunnen bijdragen. Er zijn dan ook veel hobbyisten die werken aan Sakai. Verder zijn er ook nog enkele toegewijde developementgroepen waaronder het Technical Coordination Committee, wat een groep van enkele personen is die technisch advies en aansturing geven aan het Sakai Collaberation and Learning Environment, geleid door Alan Berg. Deze groep focust op het uitbrengen van geroosterde stabiele community releases. De Sakai Fellows is een groep welke uitblinkende contributors uitzoekt om ze verder te helpen Sakai te ontwikkelen voor een vergoeding. Het Maintenance Team is een groep die zich vooral focust op bugfixes en andere problemen. Ook is er nog de Sakai Open Academic Group welke algeheel toezicht houdt over het project en de andere groepen onderling.
Voor- en nadelen
Ontwikkeling voor Sakai met een grote hoeveelheid mensen is aan de ene kant gemakkelijk omdat het in vele lagen is verdeeld. Ook is het overzichtelijk opgedeeld en duidelijk wie waarin werkt. Echter kan dit ook erg veel overhead brengen als er veel dingen tegelijkertijd voor verschillende doelen herschreven moeten worden omdat andere lagen dan ook weer aangepast moeten worden. Echter lijkt het bij Sakai nog redelijk goed te gaan aangezien er nog vrij vaak updates komen en features worden toegevoegd.
Vergelijking met Eclipse
Bij Eclipse gaat dit een stuk anders. Je kunt zonder enige transparantie zelf of met een groep een stuk functionaliteit ontwikkelen en dit vervolgens als het af is laten goedkeuren door de Eclipse community. Vanwege deze afzonderlijke ontwikkeling is het dan ook goed mogelijk dat het goedkeuren heel lang kan duren omdat deze community dus geen zicht heeft gehad op het project tijdens het ontwikkelen. Dit is aan d eene kant onhandig vanwege minder feedback en de wachttijden, maar dit kan de ontwikkelaars van de te gebruiken functionaliteit wel meer vrijheid bieden.