graduation projects in crispico

Diagrame si modelaresoftware

… de la Arduino pana la aplicatii enterprise

Teme de proiecte de licenta orientate catrecercetare-dezvoltare

http://flower-platform

http://crispico.com1

Despre noi / XOPS



Despre noi / Flower Platform





http://flower-platform.com

Subiecte de licenta axate pecercetare dezvoltare



Nivel avansat; subiectedificile



Acompaniere / coaching de exceptie



Aplicabilitate in practica



• Anexa cu detalii (contine si un bla-bla important despre viziunea noastrain 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)



Tehnologii folosite



• 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)

Beneficii• Nivel avansat; challenge intelectual

• Coaching the exceptie

• Salariu interesant

• Locatie: zona Cora Militari; aprox 15 min pana la

UPB

• Flexibilitate

• Posibilitate de angajare



Contact / aplicare



Formular de aplicare: http://crispico.com/careers

Cristian Spiescu:[email protected]

Propuneri subiecte licenta, orientate pe

proiecte de cercetare - dezvoltare

Autor: Cristian Spiescu, [email protected]

Data: 15/10/2015

Versiune: 3

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:

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.

Propuneritemelicenta

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):

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.

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.

graduation projects in crispico

Education