Eindwerk Bachelor Informatica Opdracht
Opleiding Bachelor of Science in Computer Science van de Faculteit Wetenschappen, Universiteit Antwerpen. Nota’s bij de cursus voor academiejaar 2015 - 2016,
VERSIE 2, 3 november2015.
J. Broeckhove, S. Stijven, Dirk De Vos Onderzoeksteam Computationeel Modelleren en Programmeren
Inhoudsopgave
1 Projectopdracht 1.1 Achtergrond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Niet-functionele vereisten . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Functionele vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 2 3 4
HOOFDSTUK
1
Projectopdracht
1.1 Achtergrond Simulatie is vandaag essentieel om systemen van realistische complexiteit te bestuderen en te evalueren. De kracht van simulatie volgt uit de voordelen die het biedt inzake kost, beschikbaarheid, reproduceerbaarheid, flexibiliteit en schaalbaarheid. Het belang van simulatie en de brede inzetbaarheid ervan heeft geleid tot een waaier aan tools, formalismen en software designs om simulatiemodellen te defini¨eren, te integreren, uit te voeren en hun output te analyseren. De studie van plantengroei is belangrijk vanuit strikt wetenschappelijk oogpunt, maar ook omwille van diverse redenen zoals landbouwrendement, biomassaproductie en zo meer. De figuur hieronder geeft aan welke rol modelleren en simuleren spelen in systeembiologie waar men die zeer complexe groei- en ontwikkelingsprocessen probeert te doorgronden. Er zijn meerdere simulatoren in de literatuur beschreven, telkens gekarakteriseerd door conceptuele verschillen zoals de resolutie van de biologische processen, de volledigheid, het plantenorgaan (blad, knop, wortel, ...), maar ook door implementatieverschillen (taal, data formaten, simulatie mogelijkheden, performantie, ...). In dit eindwerkproject zullen we voortbouwen op simPT. Bij de start van het project zal de code repository van simPT voor de project deelnemers beschikbaar zijn. Er zal ook uitleg gegeven worden over basisbegrippen en termen die van toepassing zijn zoals cell, node, wall segment, wall, mesh, leaf file en zo meer.
1.2. NIET-FUNCTIONELE VEREISTEN
3
Figuur 1.1: Systeembiologie cyclus.
1.2 Niet-functionele vereisten • De structuur en organisatie van de projectdirectories moet in stand gehouden worden: er moet voortgebouwd worden op het huidige project. Dat geldt eveneens voor het build en documentatiesysteem. • De draagbaarheid (Linux, Mac OS X, Windows) van het project mag niet in het gedrang komen. Zoek zelf naar mogelijkheden om periodisch op een Mac OS X en een Windows/MinGW systeem een test uit te voeren. • Code moet geformatteerd worden in dezelfde stijl en met dezelfde naam conventies als de bestaande code. • Er mogen enkel bijkomende afhankelijkheden (naast bestaande zoals Qt, headeronly Boost, . . . ) gecre¨eerd worden na voorafgaande goedkeuring van de opdrachtgever. • Toevoeging van FOSS componenten in source vorm (zoals bijvoorbeeld gtest, TCLAP reeds gebruikt worden) kan. Meld dat dan in de LICENSE gerelateerde files van het project. • De voertaal voor de code is C++ en waar mogelijk moeten C++11 taalconstructies gebruikt worden([1], [2]). Compiler afhankelijke dialectconstructies zijn niet toegelaten. • Testing: unit tests dienen voorzien te worden, alsook scenario-gedreven testen
4
1.3. FUNCTIONELE VEREISTEN
1.3 Functionele vereisten 1.3.1 Opdracht: Model specifieke algoritmen afsplitsen naar plugins Het project bevat verschillende modellen die ieder hun eigen karakteristieken hebben. Zo zijn er erg eenvoudige modellen die als demo dienen maar ook modellen die erg complexe processen binnen de plant simuleren. Momenteel zijn al deze klassen (we noemen ze ook wel algoritmische componenten want het zijn van function object klassen) nog aanwezig in een monolithische simulator. Omwille van flexibiliteit in het werken met modellen is het beter dat ieder model in een aparte shared of dynamic link library gemaakt wordt. Hierbij kan van Qt plugins gebruikt gemaakt worden. Ook op niveau van de directory structuur en dus ook van het build systeem moeten modellen losser ge¨ıntegreerd zijn in het het geheel. Als architecturale stap: • Maak gebruik van het Qt plugin systeem om op runtime een shared library te laden en gebruiken. Deze stap moet voor het Kerstreces voltooid zijn.
1.3.2 Opdracht: Protocol Buffers voor Attributes De geometrische beschrijvingsmethode van het plantenorgaan is hetzelfde voor alle modellen die gebruikt worden. Iedere model heeft een aantal attributen voor de Mesh, Cell, Wall, Node. Dat zijn bijvoorbeeld concentraties van chemicalieien of rekbaarheid van de wand enzomeer. Het aantal en de aard van deze attributen verschillen evenwel naargelang het model. In de huidige versie van de implementatie zijn die attributen niet modelspecifiek, m.a.w. alle modellen hebben dezelfde attributen. Dat betekent noodgedwongen dat alle modellen in hun klassen de atrributen hebben van alle andere modellen, al worden ze niet gebruikt in de simulatie. Dit is geen schaalbare aanpak. Het is onoverzichtelijk, niet effici¨ent in geheugengebruik en veroorzaakt vele nodeloze problemen van achterwaartse compatibiliteit. Er bestaan een aantal open source libraries die gebruikt kunnen worden om dit probleem aan te pakken: Google Protocol Buffers, Apache Thrift en Cap'n Proto. Ze laten toe op basis van een meta-beschrijving de data content van klassen vast te leggen en dan, via een pre-compilatie stap, de code te genereren voor de klassen, inclusief i/o en serialisatie functionaliteit. Gebruikmakend van een van deze libraries kunnen de attributen van de Mesh, Cell, Wall en Node definieerbaar per model gemaakt worden. Dat betekent dat ieder model aparte klassen heeft en dus ook dat de simulator nu geparametrizeerd (aan de hand van templates) wordt door die klassen. Aan het build proces zal een pre-compilatie stap toegevoegd moeten worden waarin (met behulp van de hogervermelde library) code gegenereerd wordt voor deze attributen van Mesh, Cell, enz. ). Daarbij moet wellicht ook code gepatcht worden om de impact van te ondervangen (tenzij je alles met templates kan afhandelen). Denk bijvoorbeeld aan de tooltips
1.3. FUNCTIONELE VEREISTEN
5
van de visualisatie, of aan de SWIG wrappers voor de interoperabiliteit met Python en met Java. Er zal door deze ingrepen een omkering plaatsvinden van de relatie tussen executable, simulator en modellen. Momenteel bevat het simulator executable ´e´en exemplaar van het simulator object dat op zijn beurt vastgeknoopt is aan alle modellen. Hierna zal het executable meerdere instanties van de simulator bevatten, ieder ge¨ınstantieerd voor een ander model en worden de model-specifieke algoritmen dynamisch geladen. Als architecturale stappen: • de hogervermelde libraries onderzoeken en verduidelijken naar welke library jullie voorkeur gaat. In overleg met alle groepen zal er n library worden gekozen voor de uiteindelijke implementatie. • ga na of de SWIG technologie overweg kan met getemplatiseerde C++ code en als dit problemen geeft of er alternatieven zijn voor de interoperabiliteit Deze stappen moeten voor het Kerstreces voltooid zijn zodat de implicaties voor de implementatie duidelijk zijn.
1.3.3 Opdracht: Parex verzamelen van resultaten Het framwework bevat de mogelijkheid om in parallel experimenten uit te voeren op verschillende servers. Dit is nodig als we parameter-sweeps willen doen om het gedrag van de modellen te onderzoeken in functie van bepaalde parameterwaarden. Het resultaat van deze experimenten blijft echter momenteel nog staan op de server waarop deze uitgevoerd is. Dit is erg onpraktisch, vooral als er gebruik gemaakt wordt van een groot aantal servers. Pas het Parex protocol aan zodat het mogelijk wordt om de workspaces met resultaten van de verschillende servers op te halen. Hiervoor mag je ook gebruik maken van bestaande file transfer protocollen en frameworks. Hou er rekening mee dat niet iedere server het zelfde besturingssysteem gebruikt en het dus moeilijk wordt om gebruik te maken van de ingebouwde file sharing functionaliteiten van het besturingssysteem. Je kan er vanuit gaan dat de Parex server en client op hetzelfde lokale netwerk aanwezig zijn en dus security geen punt is.
1.3.4 Optionele deelopdracht ivm Parex In het Parex protocol is de data-inhoud van de protocol boodschappen hard coded in diverse source. Ook hier (het is zelfs de originele bestaansreden van protobuf) kunnen tools zoals Google Protocol Buffers, Apache Thrift en Cap'n Proto gebruikt worden om de beschrijving van die data-inhoud naar een descriptief meta-niveau te tillen. Dat biedt naast performantievoordelen ok flexibiliteit in de (onvermijdelijke) evolutie van het protocol en en zijn software implementatie.
1.3.5 Opdracht: Redesign van GUI code In de huidige code is de GUI losgekoppeld van de simulator (vleaf shell versus sim shell). Deze afsplitsing is momenteel niet meer nodig en kan dus best weg-
gewerkt worden. Zorg ervoor dat de GUI functioneel equivalent blijft. Voor deze opdracht moet de compatibiliteit met Qt4 niet meer behouden blijven. Je kan daarom de volledige Qt5 verbeteringen gebruiken zoals lambda function callbacks. Een niet-functionele vereiste hierbij is als volgt. De GUI-code draagt de sporen van het feit dat ze ontwikkeld werd als tool i.p.v. als library met een geschikte API voor het werken met workspaces, projecten, sessie enzomeer. De test-code is daar een voorbeeld van. Een verbetering vestaat erin een duidelijke API te ontwikkelen, de bestaande code daarnaar te refactoren en de GUI van VLeag daarmee te implementeren.
1.3.6 Optionele deelopdracht ivm GUI Redesign Het huidige viewer systeem is hi¨erarchisch opgebouwd. Dit was nodig omdat in het verleden bepaalde viewers gebruikt maakten van andere viewers. In de huidige versie van de code is dit echter niet meer nodig en mag deze structuur vereenvoudigd worden.
1.3.7 Optionele opdracht: Logging Momenteel is de logging in de simulator nog volledig ad-hoc. Op verschillende plaatsen in de code staan cout en cerr statements, maar er is geen gestructureerd logging systeem. Maak gebruik van spdlog of g3log, twwe open source asynchrone logging frameworks, om logging beter te structureren. Zorg er zeker voor dat er verschillende niveaus van logging gehanteerd kunnen worden.
Bibliografie
[1] B. Stroustrup, The C++ Programming Language, Fourth Edition C++11. Pearson Education, Inc., Upper Saddle River, New Jersey, 2013. [2] S. B. Lippman, J. Lajoie, and B. E. Moo, C++ Primer, Fifth Edition C++11. Addison Wesley, Inc., Upper Saddle River, New Jersey, 2013.
