• Integrarea cu un mod arhitectural de a rezolva o problemă reală
• Aprofundarea noțiunilor de Design Patterns:
  • Singleton pattern - folosit pentru Server și Factory
  • Factory pattern - folosit pentru a separa logica de instanțiere
  • Observer pattern - folosit pentru a notifica Server-ul de o nouă ecuație de rezolvat
• Aprofundarea noțiunilor de moștenire, agregare și interfațare în contextul implementării unei aplicații reale
• Aprofundarea noțiunilor din cursul de Structuri de Date - forma poloneză a ecuațiilor matematice [1]
• Respectarea unui coding-style adecvat

Va trebui să implementați un calculator, care va primi ca input operații matematice scrise în numere romane, să calculați valoarea transformând în numere arabe [2] și să afișați răspunsul în format roman [3]. În calcularea valorii trebuie să țineți cont de ordinea operațiilor iar pentru acest lucru o să folosiți forma poloneză [1].

Scheletul de cod (directorul src) conține următoarele:

• checker/fileIO - conține logica de I/O și de comparare cu fișierele de referință
• checker/checkstyle - conține utilitarul și regulile de verificare de coding-style
• checker/resources - conține fișierele de input și referință
• homework/interfaces - conține interfețele pe care trebuie să le implementați

În cadrul fiecărui fișier de interfață veți găsi, în comentarii, o explicare laborioasă a fiecărei metode și a fiecărui câmp.

În rădăcina directorului src se află și punctul de intrare al aplicației, clasa Main. În această metodă se inițializează Evaluator-ul și se deschid fișierele de input, output, referință și subscriberi. După care Evaluator-ul face următoarele 3 acțiuni, pe instanța singleton a IServer:

• Apelează metoda subscribe pentru fiecare operator (linie) din fișierul de subscriberi
• Apelează metoda publish pentru fiecare comandă (linie) din fișierul de input
• Apelează metoda getResults și compară cu liniile din fișierul de referință

Rularea se face în felul următor: $ java Main subscribers_file input_file output_file reference_file

• subscribers_file - fișierul de operații suportate de testul curent, cu câte un operator pe linie
• input_file - fișierul de intrare cu operațiile matematice în format roman, cu câte o operație pe linie
• output_file - fișierul de ieșire, cu câte un rezultat în format roman pe linie
• reference_file - fișierul de referință, cu câte un rezultat corect în format roman pe linie

sub42

+
-
*
/
log

• Operațiile suportate pentru acest test sunt: adunare, scădere, înmulțire, împărțire și logaritm

in42

I + II
( XX - X ) + [ V - I ]
[ ( MMM - M ) + sqrt IV ]
II ^ IV
I + II + II + log IV
III / ( I - I )

ref42

III
XIV
IMPOSSIBRU
IMPOSSIBRU
VII
IMPOSSIBRU

• Linia 3 nu se poate executa deoarece scăderea și radicalul nu sunt suportate
• Linia 4 nu se poate executa deoarece ridicarea la putere nu este suportată
• Linia 6 nu se poate executa deoarece împărțirea la zero nu este acceptată

• Alfabetul folosit este următorul:

• Prioritățile operatorilor sunt următoarele:

• cel mai mare număr care poate fi scris în numere romane este 3999 iar cel mai mic număr este -3999
• niciun rezultat final de la o operație nu va sări de 3999 respectiv -3999
• toate intrările din fișierele de text le veți presupune valide din punct de vedere sintactic

• operații posibile: + (adunare), - (scădere), * (înmulțire), / (împărțire), ^ (ridicare la putere), sqrt (radical), log (logaritm natural)
• delimitarii posibili pentru forma poloneză sunt: (, ) (paranteze rotunde), [, ] (paranteze pătrate), {, } (acolade)
• înainte și după fiecare delimitator va fi un spațiu: ”( 2 + 3 )”

• fiecare operator are spațiu între operanzi: “2 + 3”
• operatorii sqrt și log au un singur operand: “sqrt 4”
• operatorul log reprezintă logaritmul natural

• se asigură că parametrul funcțiilor log și sqrt este întotdeauna pozitiv
• se asigură că rezultatul funcțiilor log și sqrt este întotdeauna pozitiv
• în cazul împărțirii inexacte între întregi, se calculează rezultatul exact (ex. 5 / 2 = 2.5)

• 100p = 90p teste publice + 10p README
• 50p
  • numele fișierelor ( ref)
  • organizarea fișierelor ( ref)
  • indentarea pe verticală și orizontală ( ref)
  • declarațiile și inițializările ( ref)
  • numirea claselor, variabilelor, metodelor, etc. ( ref)
  • tratarea cazurilor speciale ( ref)
  • respectarea unui coding style (nu neapărat acesta, important este să fiți consistenți și consecvenți)

Arhiva pe care o veţi urca pe VMChecker va trebui să conţină în directorul rădăcină:

• fișierul README
• fișierul Main.java modificat (apelarea metodei run din Evaluator)
• directorul homework cu interfețele din schelet și implementarea voastră

• Schelet (include ultima versiune a checker-ului)
• Checker v03-01-2017

• 27.12.2016
  • [Cerințe] Adăugare Nu aveți voie să modificați interfețele în niciun fel
  • [Checker] Testul 09, linia 1, parantezele pătrate nu erau închise corespunzător
  • [Precizări] Adăugare tabel cu priorități
  • [Checker] Testul 12/13, linia 4, parantezele rotunde nu erau închise corespunzător
• 28.12.2016
  • [Checker] Verificarea și scoaterea caracterului \r (CR - carriage return)
  • [Schelet] Modificarea semnăturilor metodelor din interfețele de tip factory
  • [Cerințe] Adăugare nouă cerință legat de stiva/coada de operatori/operanzi
  • [Punctaj] Adăugare precizare test bonus
• 29.12.2016
  • [Checker] Rezolvare test bonus
  • [Punctaj] Clarificare precizare test bonus
• 03.01.2017
  • [Precizări] Adăugare clarificare despre păstrarea părții întregi
  • [Checker] Testul 10, linia 1, parantezele pătrate nu erau închise corespunzător
• 15.01.2017
  • [Precizări] Adăugare dată deadline hard

• [1] - Forma poloneză postfixată algoritm
• [2] - Transformarea din numere arabe în numere romane
• [3] - Transformarea din numere romane în numere arabe
• [4] - Validarea automată a codului în Java
• Clean code