baze c++sructura unui program declarare variabilepdf.
Graduation projects in Crispico
1. Diagrame si modelare
software
… de la Arduino pana la aplicatii enterprise
Teme de proiecte de licenta orientate catre
cercetare-dezvoltare
http://flower-platform
http://crispico.com
1
2. Despre noi / XOPS
http://flower-platform
http://crispico.com
2
3. Despre noi / XOPS
http://flower-platform
http://crispico.com
3
4. Despre noi / Flower Platform
http://flower-platform
http://crispico.com
4
5. Despre noi / Flower Platform
http://flower-platform
http://crispico.com
5
6. Despre noi / Flower Platform
http://flower-platform
http://crispico.com
6
14. • Anexa cu detalii (contine si un bla-bla important despre viziunea noastra
in modelarea de soft)
• 01. Modelarea specificatiei/documentatiei. Sincronizare bi-directionala
intre documentatie (e.g. wiki), task-uri (e.g. issue tracker) si cod (e.g.
JavaDoc)
• 02. Parser/generator de cod, configurat usor de catre utilizatori pe baza de
reguli RegEx. Folosirea de mind maps pentru modelare
• 03. Diagrame inteligente, oferind atat perspectiva statica cat si dinamica.
E.g. combinarea diagramelor UML de clasa, secventa si activitate
• 04. Super-puteri pentru diff: Structure Diff (SDiff). Astfel vom putea face
review la design/gandire, si apoi la cod
• 05. Prototipare rapida de aplicatii. Acelasi model, multiple tehnologii
• 06. Mecanism inteligent pentru optimizarea ocuparii resurselor umane (in
cadrul unui sistem de management de resurse umane)
http://flower-platform
http://crispico.com
14
15. Tehnologii folosite
http://flower-platform
http://crispico.com
15
• Java (Standard, Enterprise)
• Eclipse (scriere de
pluginuri)
• Antlr & other compiler /
grammar goodies
• Hibernate, Spring & other
server side goodies
• Angular JS, Polymer JS &
other client HTML5 goodies
• Apache Flex
• C++ (Arduino, Raspberry PI)
16. Beneficii
• Nivel avansat; challenge intelectual
• Coaching the exceptie
• Salariu interesant
• Locatie: zona Cora Militari; aprox 15 min pana la
UPB
• Flexibilitate
• Posibilitate de angajare
http://flower-platform
http://crispico.com
16
18. Propuneri subiecte licenta, orientate pe
proiecte de cercetare - dezvoltare
Autor: Cristian Spiescu, cristian.spiescu@crispico.com
Data: 15/10/2015
Versiune: 3
19. 2
Introducere
La Crispico Resonate, facem cercetare/dezvoltare axata pe unelte de modelare software din 2008.
Am avut reusite, am avut esecuri. Provocarea principala: dorim sa gasim algoritmi si metode care sa
aduca valoare in design-ul si ciclul de viata a software-ului, dar care sunt simplu de folosit, adauga
minim de overhead procesului de lucru si care ar avea sanse sa se bucure de o adoptie larga.
Temele de licenta propuse (mai jos) se axeaza in principal pe cercetare/dezvoltare in jurul acestei
tematici.
Inainte, haidem sa dam un pic de context discutiei:
Proiectare si modelare in inginerie software: state of the art.
I.e. de ce avem nevoie acuta de unelte de modelare software?
Ingineria este in acelasi timp o stiinta dar si un teren de creatie. Indiferent de demeniu, de regula se
aplica urmatorul algoritm: a) se gandeste ceva, b) se analizeaza/proiecteaza acel ceva si c) se
realizeaza. Sa analizam punctul b):
• In inginerie civila: se face proiectul unei constructii (cu calcule de rezistenta, etc.), si se
construieste. O constructie mai lejera (e.g. o magazie de lemne, o casa cu un nivel, etc.):
poate necesita mai putin un proiect. Dar la polul opus: un bloc, un zgaraie-nori, un pod: un
proiect solid este obligatoriu.
• In inginerie electronica: se lucreaza cu scheme electronice. Un montaj simplu (e.g. un
microcontroller care aprinde un led): poate nu are nevoie. Insa montaje mai complexe, si mai
critice, spre exemplu electronica unui automobil sau a unui avion: necesita mult mai multa
precizie in proiectare.
• In inginerie mecanica: se lucreaza de asemenea cu schite si diagrame. Daca obiectele simple
poate nu necesita multa proiectare, sa ne gandim la unele mai complexe. Sa zicem un
automobil, o macara, un ascensor.
In ingineria software insa, lucrurile nu stau tocmai asa. Pentru ca se poate. Nu este bine, dar se
poate. Sa analizam un tablou relativ clasic. Desi in general se pleaca de la o specificatie si o analiza
initiala, acestea devine rapid invechita („obsolete”). Pe masura ce se gasesc erori, acestea se
peticesc. Poate ele ascund probleme mai grave, de arhitectura a aplicatiei care nu a fost reanalizata
odata cu modificarea/evolutia nevoilor. Dar cine are curaj sa faca modificari care impacteaza mii de
linii de cod? Scrise probabil de oameni care nu mai sunt in echipa? Care nu sunt documentate. Si care
contin bug fixuri la zeci de probleme si cazuri particulare concrete gasite in productie?
Este o retorica care se poate dezvolta. Insa cauza este lipsa unui design, unor diagrame care sa redea
esentialul programului, actualizat la momentul prezent. Facand o analogie, putem spune:
20. 3
• ca locuim intr-un bloc cu 10 etaje, care initial a fost o casa cu un nivel. Se mai darama
cladirea din cand in cand? Nici o problema; dupa cateva sesiuni de bug-fixing, totul e din nou
in picioare.
• ca zburam cu un avion. A fost mic si a tot crescut. Din cand in cand, el se mai prabuseste, insa
se mai peticeste din „codul sau”, si se reia zborul.
Totusi, unelte de modelare in software exista. Exista UML, diagrame de baze de date si multe alte
formalisme. Dar ele nu sunt folosite la scara larga intrucat adauga overhead procesului de lucru. Nu
sunt mereu intuitive, mananca timp, si sub presiunea livrarilor care TREBUIE facute, ele sunt primele
care sunt date la o parte. Si apoi, cand dorim sa comunicam cu echipa, „the plain old” hartie si creion
sar rapid in ajutor.
Propuneri teme licenta
01. Modelarea specificatiei/documentatiei. Sincronizare bi-
directionala intre documentatie (e.g. wiki), task-uri (e.g. issue tracker)
si cod (e.g. JavaDoc)
De multe ori un software incepe cu specificatie functionala si/sau tehnica scrisa. Spre exemplu intr-
un wiki, document Word, etc. Propunem un mecanism care:
• se conecteaza la diverse sisteme care gestioneaza continut. E.g. wiki, issue tracker (multa
informatie este tinuta ca descriere are unor issue/task), documente text,
• parseaza informatia (e.g. titlu, paragraf, bloc de text),
• reprezinta informatia sub forma unei diagrame mind map,
• anumite noduri (i.e. „bucati de continut”) pot fi asociate codului sursa (care a fost in prealabil
parsat si transformat in Abstract Syntax Tree),
• tot acest flow este bi directional.
E.g. un document contine cateva paragrafe. Putem lua aceste paragrafe si sa le asociem unor
clase/functii (e.g. in Java ca documentatie JavaDoc). Daca modificam documentul original (e.g. in
wiki), automat se actualizeaza si in JavaDoc. Si invers: modificarea JavaDoc actualizeaza sectiunea
corespunzatoare in documentul original.
02. Parser/generator de cod, configurat usor de catre utilizatori pe
baza de reguli RegEx. Folosirea de mind maps pentru modelare
Dorim realizarea unui parser/generator de cod care sa foloseasca o gramatica bazata pe reguli RegEx
(expresii regulate). Vedem cateva avantaje fata de parserele „clasice” de tip AbstractSyntaxTree
(AST):
21. 4
A. Sunt mai „light-weight”, deoarece regulile noastre vor parsa doar structura de baza (clase,
metode, atribute). Expresiile din blocuri de cod (e.g. IF, WHILE, etc) sunt sarite pentru ca nu ne
intereseaza. De aici obtinem viteza de executie sporita si gramatica mult mai simpla si robusta.
B. Fiind usor de configurat, useri isi pot crea cu usurinta gramatici. Atat pentru limbaje bine
structurate (Java, Python, Ruby), dar mai ales pentru limbaje dinamice, precum JavaScript.
E.g. in JavaScript, exista pe putin 5 modalitati in care se poate realiza mostenire (si POO). Acestea
sunt dictate de conventii, nu de structura limbajului. Cu o astfel de unealta, am putea cu usurinta
scrie reguli pentru diverse conventii.
Bazandu-ne pe acest parser, putem usor modela aplicatia folosind mind maps: unelte care sunt
simplu de folosit, keyboard-oriented.
03. Diagrame inteligente, oferind atat perspectiva statica cat si
dinamica. E.g. combinarea diagramelor UML de clasa, secventa si
activitate
Diagramele UML de clasa sunt niste instrumente convenabile. Sunt relativ simplu de inteles. Exista
numeroase unelte grafice care se pot folosi si de asemenea se pot desena cu usurinta si pe hartie.
Daca se dezvolta o functionalitate sau un mecanism, se poate crea una (sau mai multe) diagrame,
pentru a sublinia clasele si functiile care participa in respectivul mecanism. Totusi, ele nu sunt
suficiente, intrucat ele nu prezinta si interactiunile (i.e. dinamicitatea, flow-ul programului; ce
metode sunt apelate de catre cine). In general se foloseste naratiunea (viu grai) pentru a explica
flow-ul de runtime. Diagramele de secventa/activitate/scheme logice, sunt prea putin folosite pentru
ca sunt mai greu de desenat, si mult mai greu de intretinut.
Propunem extinderea diagramelor de clasa cu conceptul de scenariu/scenarii. Un scenariu,
reprezinta un flow in care participa mai multe din metodele de pe diagrama. Preconizam o
ergonomie studiata pentru crearea si vizualizarea acestor scenarii. Astfel, vom reusi sa capturam intr-
o singura diagrama atat structura statica cat si pe cea dinamica.
04. Super-puteri pentru diff: Structure Diff (SDiff). Astfel vom putea
face review la design/gandire, si apoi la cod
Diff-ul (e.g. compararea unor commit-uri/modificari GIT, in vederea integrarii in branch-ul master)
este util pentru code-review. Iar code-review este o practica excelenta. Probleme:
A. parcugerea unui diff necesita mult timp; iar timpul este pretios pentru toata lumea; de aici si
tendinta de a NU se face code-review
B. daca se detecteaza probleme mari/de gandire/structura/arhitectura: este tarziu. Deja mult cod a
fost scris; mult timp (si deci bani) au fost deja consumati.
22. 5
Propunem o modalitate prin care se poate face review la design. Se folosesc diagrame de tip mind
map, pentru a descrie modificarile dorinte la nivel de structura: e.g. adaugari de clase, metode;
modificari, etc. Folosind un cod de culori, astfel de diagrame de structura s-ar putea crea foarte usor,
s-ar putea citi usor si apoi ar putea sa genereze deja cod/schelet. Un review-er poate deci intelege
propunerea de implementare cu usurinta, si probleme de arhitectura se pot detecta rapid, pana cand
s-a inceput scrierea de cod.
Apoi, dupa implementare, pe baza diff-ului (comparatia codului sursa initial/final), se mai poate
genera un nou diff de structura (sdiff). El captureaza modificarile efectiv realizate, si poate fi
comparat cu sdiff-ul initial. Astfel reviewer-ul poate vedea rapid deraieri de la ideea initiala (care pot
fi legitme, sau pot ascunde la randul lor probleme de structura).
05. Prototipare rapida de aplicatii. Acelasi model, multiple tehnologii
Aplicatiile enterprise probabil ca reprezinta peste 90% din codul existent pe pamant. Indiferent de
sectorul de business (bancar, comercial, procese de productie, transport, etc) ele se bazeaza in
general pe un model de date si pe o baza de date. In jurul acestora, exista multe functionalitati
recurente. Spre exemplu ecrane de tip tabel pentru afisarea datelor. Ecrane de tip formular, pentru
editare. Etc.
Propunem o unealta de design al modelului de date. Care apoi sa fie capabila sa genereze cod pentru
diverse tehnologii populare. Spre exemplu backend folosing Java Enterprise Edition, PHP, Ruby,
Python, etc. Frontend folosind HTML5, AngularJS, Polymer, Backbone.js, React.JS, etc.
06. Mecanism inteligent pentru optimizarea ocuparii resurselor
umane (in cadrul unui sistem de management de resurse umane)
In programele care gestioneaza resurse (umane, tehnice) se pune deseori problema optimizarii lor
prin alocare automata de catre un algoritm de calcul.
Avand ca baza un astfel de sistem folosit in domeniul aeroportuar, ne propunem sa experimentam un
algorim automat de alocare. Pe langa partea algoritmica, principala provocare este elaborarea unui
sistem de reguli, flexibil si usor de utilisat de catre useri.