SlideShare uma empresa Scribd logo
1 de 22
Baixar para ler offline
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
Despre noi / XOPS
http://flower-platform
http://crispico.com
2
Despre noi / XOPS
http://flower-platform
http://crispico.com
3
Despre noi / Flower Platform
http://flower-platform
http://crispico.com
4
Despre noi / Flower Platform
http://flower-platform
http://crispico.com
5
Despre noi / Flower Platform
http://flower-platform
http://crispico.com
6
http://flower-platform
http://crispico.com
7
http://flower-platform.com
http://flower-platform
http://crispico.com
8
http://flower-platform.com
Subiecte de licenta axate pe
cercetare dezvoltare
http://flower-platform
http://crispico.com
10
Nivel avansat; subiecte
dificile
http://flower-platform
http://crispico.com
11
Acompaniere / coaching
de exceptie
http://flower-platform
http://crispico.com
12
Aplicabilitate in practica
http://flower-platform
http://crispico.com
13
• 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
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)
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
Contact / aplicare
http://flower-platform
http://crispico.com
17
Formular de aplicare:
http://crispico.com/careers
Cristian Spiescu:
cristian.spiescu@crispico.com
Propuneri subiecte licenta, orientate pe
proiecte de cercetare - dezvoltare
Autor: Cristian Spiescu, cristian.spiescu@crispico.com
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.
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):
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.

Mais conteúdo relacionado

Destaque

Social media for communal leaders (3)
Social media for communal leaders (3)Social media for communal leaders (3)
Social media for communal leaders (3)Brainstorm Digital
 
Valor sul amadora
Valor sul amadoraValor sul amadora
Valor sul amadoraPavel Mocan
 
Consumentengedrag perceptie
Consumentengedrag perceptieConsumentengedrag perceptie
Consumentengedrag perceptieM.H.Valk
 
Tópicos literarios
Tópicos literariosTópicos literarios
Tópicos literarioscastelama
 
O lapis
O lapisO lapis
O lapisjv26
 
"Конфетти" коллекция Bremani
"Конфетти" коллекция Bremani"Конфетти" коллекция Bremani
"Конфетти" коллекция BremaniNSP Ukraine
 
Quinto informe Comisión de Turismo
Quinto informe Comisión de TurismoQuinto informe Comisión de Turismo
Quinto informe Comisión de TurismoJulisa Amador Nieto
 
Sistem Informasi Manajemen
Sistem Informasi ManajemenSistem Informasi Manajemen
Sistem Informasi Manajemenjuneydi Raturoma
 

Destaque (10)

Mercado romano
Mercado romanoMercado romano
Mercado romano
 
GM Certificate
GM CertificateGM Certificate
GM Certificate
 
Social media for communal leaders (3)
Social media for communal leaders (3)Social media for communal leaders (3)
Social media for communal leaders (3)
 
Valor sul amadora
Valor sul amadoraValor sul amadora
Valor sul amadora
 
Consumentengedrag perceptie
Consumentengedrag perceptieConsumentengedrag perceptie
Consumentengedrag perceptie
 
Tópicos literarios
Tópicos literariosTópicos literarios
Tópicos literarios
 
O lapis
O lapisO lapis
O lapis
 
"Конфетти" коллекция Bremani
"Конфетти" коллекция Bremani"Конфетти" коллекция Bremani
"Конфетти" коллекция Bremani
 
Quinto informe Comisión de Turismo
Quinto informe Comisión de TurismoQuinto informe Comisión de Turismo
Quinto informe Comisión de Turismo
 
Sistem Informasi Manajemen
Sistem Informasi ManajemenSistem Informasi Manajemen
Sistem Informasi Manajemen
 

Semelhante a Graduation projects in Crispico

Semelhante a Graduation projects in Crispico (20)

Curs1-POO-Loga
Curs1-POO-LogaCurs1-POO-Loga
Curs1-POO-Loga
 
Music Finder
Music FinderMusic Finder
Music Finder
 
Axiologic quark
Axiologic quarkAxiologic quark
Axiologic quark
 
Curs java
Curs javaCurs java
Curs java
 
Cu codul în "nori"
Cu codul în "nori"Cu codul în "nori"
Cu codul în "nori"
 
Dezvoltarea Aplicatiilor Web
Dezvoltarea Aplicatiilor WebDezvoltarea Aplicatiilor Web
Dezvoltarea Aplicatiilor Web
 
Sisteme expert mps2
Sisteme expert mps2Sisteme expert mps2
Sisteme expert mps2
 
Gabriel Voicu - De ce Ruby on Rails este o alegere buna in 2024 (2024.02.06, ...
Gabriel Voicu - De ce Ruby on Rails este o alegere buna in 2024 (2024.02.06, ...Gabriel Voicu - De ce Ruby on Rails este o alegere buna in 2024 (2024.02.06, ...
Gabriel Voicu - De ce Ruby on Rails este o alegere buna in 2024 (2024.02.06, ...
 
Irina Cureraru
Irina CureraruIrina Cureraru
Irina Cureraru
 
Webappdev
WebappdevWebappdev
Webappdev
 
Algoritmi 121014204617-phpapp02
Algoritmi 121014204617-phpapp02Algoritmi 121014204617-phpapp02
Algoritmi 121014204617-phpapp02
 
Practici comune pentru limbajul de programare în C
Practici comune pentru limbajul de programare în CPractici comune pentru limbajul de programare în C
Practici comune pentru limbajul de programare în C
 
Sisteme expert mps
Sisteme expert mpsSisteme expert mps
Sisteme expert mps
 
Webpack
Webpack Webpack
Webpack
 
Curs Visual c++
Curs Visual c++Curs Visual c++
Curs Visual c++
 
Curs C++
Curs C++Curs C++
Curs C++
 
Limbajul java
Limbajul javaLimbajul java
Limbajul java
 
Drupal Basics
Drupal BasicsDrupal Basics
Drupal Basics
 
218359108 programarea aplicatiilor ms office visual basic pentru aplicatii
218359108 programarea aplicatiilor ms office visual basic pentru aplicatii218359108 programarea aplicatiilor ms office visual basic pentru aplicatii
218359108 programarea aplicatiilor ms office visual basic pentru aplicatii
 
baze c++sructura unui program declarare variabilepdf.
baze c++sructura unui program declarare variabilepdf.baze c++sructura unui program declarare variabilepdf.
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
  • 9.
  • 10. Subiecte de licenta axate pe cercetare dezvoltare http://flower-platform http://crispico.com 10
  • 12. Acompaniere / coaching de exceptie http://flower-platform http://crispico.com 12
  • 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
  • 17. Contact / aplicare http://flower-platform http://crispico.com 17 Formular de aplicare: http://crispico.com/careers Cristian Spiescu: cristian.spiescu@crispico.com
  • 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.