This is an old revision of the document!


TerraBot - let's explore and save the planet !

Solutia voastra trebuie OBLIGATORIU sa fie OOP. Nerespectarea acestui format va duce la depunctarea totala a temei.

Daca aveti 100p pe checker, insa solutia voastra nu este OOP, atunci veti obtine 0p pe tema.

Introducere

TerraBot, robotul nostru explorator de la NASA, are misiunea de a descoperi o nouă planetă și de a o pregăti pentru colonizare. El trebuie să parcurgă cât mai mult din suprafața planetei, să colecteze informații utile despre mediu și să contribuie la îmbunătățirea condițiilor de viață. Atenție însă: energia lui TerraBot este limitată, așa că fiecare acțiune trebuie aleasă cu grijă pentru a asigura succesul misiunii!

Obiective

Scopul acestei teme este aplicarea cunoștințelor dobândite până acum, prin utilizarea conceptelor de programare orientată pe obiecte (OOP) în Java. Veți învăța să structurați un proiect într-un mod clar și organizat, să scrieți cod curat, modular și ușor de extins, care să permită adăugarea rapidă de noi funcționalități.

Proiectul propus va simula explorarea unei planete străine și va urmări evoluția mediului acesteia în funcție de anumiți parametri, simulare care se va dezvolta treptat pe măsură ce avansați.

Misiunea lui TerraBot

Odată lansat în misiune, TerraBot intră într-un mediu complet necunoscut, unde fiecare colț de planetă ascunde provocări diferite. Robotul nostru este programat să efectueze simulări, fiecare având scopul de a observa cum evoluează ecosistemul, de a colecta date despre plante, animale, apă și sol, și de a aplica diferite metode pentru a menține mediul sănătos și sustenabil.

În cadrul acestor simulări, TerraBot experimentează, învață și ia decizii bazate pe informațiile colectate. Fiecare simulare reprezintă o rundă completă de explorare: mediul se modifică, resursele sunt limitate, iar robotul trebuie să acționeze eficient pentru a-și atinge obiectivele. Astfel, testele voastre pot conține una sau mai multe simulări, oferindu-vă posibilitatea de a evalua performanța TerraBot în scenarii diferite.

Pașii pentru desfășurarea unui test sunt următorii:

  1. Se generează preambulul – harta cu toate entitățile plasate pe celule (vezi secțiunea Desfășurarea simulării).
  2. Se dau comenzile pentru simulare:
    1. startSimulation → marchează începutul simulării
    2. se rulează pașii propriu-ziși ai simulării (TerraBot primește comenzi, mediul se actualizează)
    3. endSimulation → marchează finalul simulării.
    4. dacă există alte simulări în cadrul aceluiași test, pașii de mai sus se repetă.

Desfășurarea unei simulări

Fiecare simulare trebuie să înceapă cu comanda `startSimulation` și să se încheie cu `endSimulation`. Doar comenzile aflate între aceste două marcaje sunt valide și vor fi executate. Astfel, o simulare este considerată validă numai dacă are atât început, cât și sfârșit.

În timpul explorării, două lucruri se întâmplă în paralel:

  1. Mediul evoluează automat – fenomene naturale care se petrec fără intervenția robotului
    • plantele își schimbă starea (pot crește și se pot ofili)
    • animalele se deplasează și își schimbă starea (consumă plante sau apă ca să nu fie flămânde)
    • calitatea aerului, a apei și a solului se modifică în timp
  2. TerraBot ia decizii și acționează – sub controlul comenzilor primite:
    • se deplasează pe hartă
    • scanează și analizează elementele întâlnite, învățând „facts” pe care le stochează
    • aplică metode de îmbunătățire a mediului (trebuie mai întâi să învețe cum să facă asta pe baza unor „facts” descoperite anterior)
    • colectează plante și le adaugă în inventar
    • explorează noi zone, alegând cel mai bun drum în funcție de calitatea mediului.

Fiecare pas al simulării presupune atât actualizarea automată a mediului, cât și procesarea comenzilor robotului, deci trebuiesc validate toate aceste evenimente!

La începutul fiecărei simulări:

  • TerraBot pornește de la zero cu o baterie nouă și un inventar gol
  • se resetează mediul - se regenerează harta cu noii parametri (tipul de sol pe fiecare celulă, plantele, animalele, calitatea aerului și a apei etc. și implicit pozițiile lor pe hartă)

Practic, fiecare simulare pornește de la zero.

În harta din imagine puteți vedea un exemplu orientativ cu poziționarea robotului și mișcările pe care poate să le efectueze pe hartă. Aceasta are o dimensiune de NxN dată la input, cât și condițiile de mediu și animalele/plantele pentru fiecare căsuță.

Detaliile privind mișcările și acțiunile robotului, precum și schimbările automate ale mediului, sunt descrise în secțiunea Comenzi

Pașii unei simulări

Observații și reguli importante

  • Fiecare simulare este independenta una de cealalta. Asadar, fiecare simulare pornește de la zero: cu hartă, parametri și energie noi. Nu se păstrează resurse sau starea robotului între simulări.
  • Hint: Gândiți-vă la simulări ca la runde succesive de joc: la fiecare rundă, mediul și robotul se resetează complet.
  • Simulările se execută secvențial, pe rând – nu pot rula două simulări în paralel.
  • Între simulări (după endSimulation și înainte de un nou startSimulation) se pot da comenzi, dar acestea nu vor fi executate.
  • Fiecare celulă a hărții poate conține maximum o plantă, un animal și o sursă de apă.

Entități

Plant

Animal

Water

Soil

Air

Comenzi

Comenzi pentru simulare

startSimulation

  • marcheaza inceperea unei simulari
  • robotul porneste mereu de pe pozitia [0, 0] a hartii

Mesaje posibile pentru aceasta comanda:

  • "Simulation has started."
  • "ERROR: Simulation already started. Cannot perform action"
Input

Click pentru input startSimulation

Click pentru input startSimulation

{
    "command": "startSimulation",
    "timestamp": 1
}
Output

Click pentru output startSimulation

Click pentru output startSimulation

{
    "command": "startSimulation",
    "message": "Simulation has started.",
    "timestamp": 1
}

Comenzi pentru mediu

Comenzi pentru TerraBot

Comenzi de debug

Exemplu simulare

Scheletul de cod

În rezolvarea temei va fi nevoie de folosirea unor obiecte pentru stocarea și maparea datelor primite în format JSON. Scheletul temei vă oferă mai multe clase utile pentru citirea și rularea temei. Acestea se regăsesc în cadrul scheletului astfel:

  • Clasele de input din cadrul pachetului fileio : Acestea se vor folosi pentru parsarea datelor de input. Astfel preluați toate informațiile necesare pentru a crea propriile clase pentru rezolvarea temei.
  • Clasa Main care este punctul de intrare pentru logica de rezolvare a temei.

Pentru a întelege mai bine cum funcționează citirea/scrie în fișierele JSON vă recomandăm să citiți Json & Jackson.

Implementarea voastră va începe din funcția Main.action, unde veți adăuga în ArrayNode output pe parcursul execuției toate output-urile comezilor date. De asemenea, aveți un mic exemplu în schelet despre cum puteți face asta.

Output-ul nu trebuie formatat ca în ref-uri, fiindcă se verifică conținutul obiectelor și array-urilor JSON, nu textul efectiv. Cu toate acestea, dacă folosiți Jackson, vă recomandăm să utilizați PrettyPrinter Documentație PrettyPrinter. Totodată, pentru a înțelege cum se poate realiza scrierea în fișierele JSON de output, vă sugerăm să consultați JSON Array.

Aveți în folder-ul “lib” toate dependințele necesare pentru rularea temei, mai exact bibliotecile Jackson.

Execuția temei

  1. Se încarcă datele citite din fișierul de test, în format JSON, în obiecte.
  2. Se primesc secvențial acțiuni și se execută pe măsură ce sunt primite, rezultatul lor având efect asupra Repository-ului.
  3. După executarea unei acțiuni, se afișează rezultatul ei în fișierul JSON de ieșire.
  4. La terminarea tuturor acțiunilor se termină și execuția programului.

  • După ce clonați repo-ul de pe GitHub, vă rugăm să vă faceți un repository propriu privat în care să vă puneți doar conținutul folder-ului “tema” de pe repo-ul echipei de POO. Dacă nu puneți folder-ul cu tema la alta cale, nu o să puteți să faceți schimbări in Git, deoarece vă aflați în rădăcina repository-ului echipei de POO.
  • Pentru ca checker-ul să funcționeze trebuie să deschideți tema din Intellij la calea unde se află folderele “src”, “lib”, “ref”, “input”. Aveți folder-ul .idea pregenerat ca să vă ajute in acest sens. De asemenea, fișier-ul .iml contine calea către bibliotecile Jackson. Dacă aveți probleme stergeți folder-ul .idea si fișierul .iml si generațile voi din nou din Intellij.

Recomandări

  • Tema a fost concepută pentru a vă testa cunoștințele dobândite în urma parcurgerii laboratoarelor 1-3, aceasta putând fi rezolvată doar cu noțiunile invățate din acele laboratoare.
  • Tema fiind o specificație destul de stufoasă recomandăm citirea de cel putin două ori a enunțului inainte de inceperea implementării.
  • Pentru depanarea diferențelor dintre output-ul vostru si fișierele ref, vă recomandăm acest site.

Verificați periodic această pagină, deoarece scheletul/cerința pot suferi modificări în urma unor erori din partea noastră.

Evaluare

Punctajul constă din:

  • 80p implementare - trecerea testelor
  • 10p coding style (vezi checkstyle)
  • 5p README clar, concis, explicații axate pe design (flow, interacțiuni)
  • 5p folosire git pentru versionarea temei

Pe pagina Indicații pentru teme găsiți indicații despre scrierea readme-ului și baremul folosit la corectarea temei. Vă incurajăm să treceți prin el cel puțin odată.

Pentru a primi punctajul pentru Git, după ce ați terminat tema și ați făcut toate commit-urile, executați comanda git log > git_log.txt in rădăcina proiectului și adăugați fisierul in arhiva trimisă.

Pentru folosirea tool-ului Git vă punem la dispoziție un tutorial actualizat și amplu despre el la acest link și aveți de asemenea și un tutorial despre comenzile pe care puteți să le dați din IntelliJ la acest link.

Depunctările pentru designul și organizarea codului se vor scădea din punctajul testelor. Dacă vor apărea depunctări specifice temei în momentul evaluării, nemenționate pe pagina cu depunctări generale, ele se vor încadra în limitele de maxim 10p pentru design, 5p pentru readme. Dacă tema nu respecta cerințele, sau are zero design OOP atunci se pot face depunctari suplimentare.

Folosirea git pentru versionare va fi verificata din folderul .git pe care trebuie să îl includeți în arhiva temei. Punctajul se va acorda dacă ați făcut minim 3 commit-uri relevante și cu mesaj sugestiv. NU este permis să aveți repository-urile de git publice până la deadline-ul hard.

Bonusuri: La evaluare, putem oferi bonusuri pentru design foarte bun, cod bine documentat dar și pentru diverse elemente suplimentare alese de voi.

  • Temele vor fi testate împotriva plagiatului. Orice tentativă de copiere va duce la anularea punctajului de pe parcursul semestrului şi repetarea materiei atât pentru sursă(e) cât şi pentru destinație(ii), fără excepție.
  • Aveți grijă să nu puneți pe Vmchecker fișiere .idea sau .iml.

Checkstyle

Unul din obiectivele temei este învățarea respectării code-style-ului limbajului pe care îl folosiți. Aceste convenții (de exemplu cum numiți fișierele, clasele, variabilele, cum indentați) sunt verificate pentru temă de către tool-ul checkstyle.

Pe pagina de Recomandări cod găsiți câteva exemple de coding style.

Dacă numărul de erori depistate de checkstyle depășește 30, atunci punctele pentru coding-style nu vor fi acordate. Dacă punctajul este negativ, acesta se trunchiază la 0.

Exemple:

  • punctaj_total = 100 și nr_erori = 200nota_finala = 90
  • punctaj_total = 100 și nr_erori = 29nota_finala = 100
  • punctaj_total = 80 și nr_erori = 30nota_finala = 80
  • punctaj_total = 80 și nr_erori = 31nota_finala = 70

Upload temă

Arhiva o veţi urca pe VMChecker, unde sunt si informații despre structura ei.

FAQ

Q: Pot folosi biblioteca “X”?
A: Dacă doriți să folosiți o anumită bibliotecă vă recomandăm să întrebați pe forum, ca apoi să o validăm și să o includem și pe Vmchecker.

Q: Am descoperit edge case-ul “Y”, trebuie să îl tratez?
A: Nu. Toate datele necesare pentru soluționarea temei vă sunt date in cerință. Dacă totuși am omis ceva ne puteți contacta pe forum.

Q: Pot folosi clase de tip “Enum” pentru constante?
A: Da.

Q: Ce JDK recomandați?
A: 25

Q: Pot să fac în orice ordine testele?
A: Da! Testele au fost concepute sa fie cât mai decuplate și să testeze câte o funcționalitate în întregime. Cu toate astea, vă recomandăm să implementați mai întâi testele 01, 02, 03 deoarece reprezintă funcționalitățile de bază pentru rezolvarea următoarelor teste mai complexe.

Resurse și linkuri utile

poo-ca-cd/teme/2025/8e211bfe-f6eb-467c-9e54-f8e6df4c1535/tema-1.1759530650.txt.gz · Last modified: 2025/10/04 01:30 by ioana.tudorache2507
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0