Universitatea „Dunărea de Jos” Galaţi

Facultatea de Automatică, Calculatoare, Inginerie

Electrică, şi Electronică

Ingineria Programelor

Brainie Game

Profesor coordinator : Student :

dr. inf. Sabina Costache Şerban Sabin-Adrian
Grupa : 22C31

-2014-
 Cuprins

1. Tema proiectului

2. Analiza jocului

2.1 Descrierea jocului

2.2 Implementarea jocului
2.3 Calculul indicelui de instabilitate pentru fiecare pachet

3. Diagrama completă a jocului

4. Implementarea şabloanelor de design

5. Arhitectura sistemului

6. Plan de testare cu Junit

7. Principii şi euristici

Bibliografie
 1.Tema proiectului
http://www.mathplayground.com/brainie.html

Tema proiectului este „Brainie” care este realizat in limbajul de programare Java
( limbaj orientat pe obiect). Jocul va fi creat utilizând trei şabloane de proiectare.
Jocul pe care l-am urmat ca model este aceasta din imaginea de mai jos.
 2. Analiza jocului
Jocul „Brainie” are ca scop să testeze jucătorului abilităţile matematice cât şi atentia
distributivă şi timpul de reacţie prin distrugerea unor pătrate. Începe când se dă click pe
butonul de Start şi la fiecare 5 secunde se generează noi pătrate.

2.1 Descrierea jocului

La inceput se vor explica regulile jocului.

In partea dreapta va aparea o valoare generata aleatoriu de joc. Scopul este

ca jucatorul sa distruga patratele de pe ecran care au valoarea sau suma lor egala
cu valoarea data. Valorile date sunt aleatorii si se vad pe patrate.

Dupa ce se apasa butonul de Start jocul va genera la fiecare 5 secunde cate

un patrat cu o valoare aleatorie pana cand se intalnesc 3 cazuri: utilizatorul termina
toate patratele, aparand un mesaj „You’ve won!”; se ajunge pana in varful ferestrei
de joc cu patratele, caz in care va aparea mesajul „You’ve lost!”; daca se doreste a
se inceta jocul se va da click pe butonul Stop.
Diferitele stări în timpul jocului:
2.2 Implementarea jocului

Jocul „Brainie” este implementat cu ajutorul a 10 clase/interfețe.

Pachete şi clasele componente:

- Brainie: - Brainie.java
- Decorator - Decorator .java
- BorderDecorator.java
- Utils: - Message.java
- MyJButton.java
- Randoms.java
- State: - State.java
- StateOn.java
- StateOff.java
- Context.java

2.3 Calculul indicelui de instabilitate pentru fiecare pachet

Cum poate fi calculată stabilitatea unui pachet? O modalitate este numărarea dependenţelor
care intră şi ies în / din pachet. Aceste numaratori ne vor permite să calculăm stabilitatea
poziţională a pachetului.
0 = stabilitate maximă a pachetului; 1 = instabilitate maximă a pachetului
I=Ca /(Ca+Ce) (I-indice de instabilitate, Ca-cuplaj aferent, Ce-cuplaj eferent)
Ca - Numărul de clase din afara acestui pachet care depind de pachetul măsurat
Ce - Numărul de clase din afara pachetului măsurat de care depind clase din
interiorul acestui pachet

Brainie - Ca=1, Ce=1, I=1/(1+1)=1/2=0,50

Decorator - Ca=1, Ce=3, I=1/(1+3)=1/4=0,25
Utils - Ca=2, Ce=1, I=2/(2+1)=1/2=0,66
State - Ca=2, Ce=3, I=2/(2+3)=2/5=0,4
3.Diagrama completă a jocului

O diagramă de secvenţă prezintă colaborarea dinamică între un număr de

obiecte mai precis secvenţele de mesaje trimise între acestea pe măsura scurgerii
timpului.Obiectele sunt văzute ca linii verticale distribuite pe orizontală, iar timpul
este reprezentat pe axa verticală de sus în jos. Mesajele sunt reprezentate prin
săgeţi între linile verticale ce corespund obiectelor implicate în mesaj.O diagramă a
claselor prezintă structura fizică a claselor identificate în sistem. Clasele reprezintă
“lucruri” gestionate de sistem; clasele pot fi legate în mai multe moduri: associate
(conectate între ele), dependente (o clasa depinde/foloseşte o altă clasă),
specializate (o clasă este specializarea altei clase) sau împachetate (grupate
împreună în cadrul unei unitaţi). Toate aceste relaţii se materializează în structura
internă a claselor în atribute şi operaţii.Diagrama este considerată statică, în sensul
că este validă în orice moment din ciclul de viaţă al sistemului.
4.Implementarea şabloanelor de design

Un şablon reprezintă o soluţie comună a unei probleme într-un anumit context.

Importanţa şabloanelor (standardelor) în construirea sistemelor complexe a fost de
mult recunoscută în alte discipline. În cadrul comunităţii proiectanţilor de software OO
(orientate pe obiecte) ideea de a aplica şabloane se pare că a fost inspirată de
propunerea unui arhitect, Christopher Alexander, care a lansat iniţiativa folosirii unui
limbaj bazat pe sabloane pentru proiectarea clădirilor şi a oraselor. Acesta afirma că:
"Fiecare şablon descrie o problemă care apare mereu în domeniul nostru de
activitate şi indică esenţa soluţiei acelei probleme într-un mod care permite utilizarea
soluţiei de nenumărate ori în contexte diferite".Deşi în domeniul sistemelor OO
soluţiile sunt exprimate în termeni de obiecte şi interfeţe (în loc de ziduri, uşi, grinzi
etc), esenţa noţiunii de sablon este aceeaşi, adică de soluţie a unei probleme într-un
context dat.Şabloanele de proiectare sunt o memorare pentru posteritate a
experienţei în domeniul proiectării sistemelor OO.În realizarea jocului Brainie s-au
folosit următoarele şabloane creaţionale : Singleton, Decorator si State.

Sablonul Decorator
 Şablonul decorator permite unui utilizator să adăuge noi funcționalități la un obiect
existent, fără a modifica structura acestuia. Acest tip de model de proiectare se încadrează
în modelul structural deoarece acest model actioneaza ca un înveliș la clasele deja
existente.
Acest model creează o clasă de decorator care înfășoară clasa originala și oferă
suplimentar funcționalitate şi păstrarea metodelor clasei intacte. O clasă înveleşte altă clasă,
ambele extind aceeaşi clasă abstractă.
Am demonstrat prin adăugarea de imagini la butoane şi schimbarea culoriloe la
jpaneluri şi făcând un border în jurul labelului unde se dă valoarea din joc.

Sablonul Singleton
 Scop : Asigură ca o clasă să aibă doar o singură instanţă şi furnizează un
punct de acces global la ea.
Şablonul singleton este unul dintre cele mai simple şabloane de design în
Java. Acest tip de model de proiectare se încadrează în modelul de creație deoarece
acest model oferă una dintre cele mai bune moduri de a crea un obiect.
Acest model presupune o singură clasă, care este responsabilă cu crearea
unui obiect în timp ce se asigură că doar un singur obiect este creat. Această clasă
oferă o modalitate de a accesa numai obiectul, care poate fi accesate direct, fără a fi
nevoia de a instantia acel obiect al clasei.
Aceasta ridica o problema: este imposibil să se creeze o instanţă, prin urmare
se furnizeaza o metoda accesor printr-o metoda statica (getInstance()). Aceasta
metoda creeaza o singura instanta, daca ea nu exista deja, si returneaza referinta la
respectiva instanta (singleton) catre apelantul metodei. Referinta la singleton este
memorata ca atribut privat static al clasei singleton pentru rezolvarea apelurilor
ulterioare.

Sablonul State
Sablonul State reprezintă fiecare stare a unei entităţi sub forma unui obiect.
Asemenea obiecte sunt rareori descoperite în timpul analizei sau chiar a stadiului
incipient al proiectării. În şablonul de State se vor crea obiecte care reprezintă diferite
stări şi un obiect contextual a cărui comportament se schimbă în acelaşi timp cu
obiectul de stare. Se va găsi ca exemplu labelul în joc care arată starea jucătorului,
adică dacă se aşteaptă ca jucătorul să pornească jocul, dacă joacă sau dacă a oprit
jocul.
5. Arhitectura sistemului
Întregul sistem este fundamentat pe arhitectura orientată obiect folosind proprietăţile
acesteia, cum ar fi: moştenirea, polimorfismul, încapsularea, legarea dinamica.

Sisteme Orientate-Obiect

 Obiectele ca manageri
 conservă integritatea resurselor, i.e. reprezentarea datelor
 Încapsularea
 Ascunde reprezentarea de alte obiecte
 Moştenirea
 stabileste o ierarhie intre abstractiuni inrudite

 Legarea dinamica
 se determina ce operatie se apeleaza la momentul executiei
programului

Jocul prezintă o arhitectură orientate pe obiect (OO) deoarece:

 Schimbă implementarea fără să afecteze clasele

 Descompune problemele în colecţii de metode care colaborează
 Obiectele sunt reprezentări ale entităţilor din lumea reală
 Structura sistemului e uşor de înţeles

Principiile anterior anunțate în capitolul precedent se concretizează prin șabloanele

de design, care la rândul lor oferă o structură frecventă de componente ce comunică
și rezolvă o problemă generală de design într-un context special. Folosirea acestora
conduce la o arhitectură orientată pe șabloane de design.

Întrucât jocul este un sistem interactiv, are nevoie de comenzi de la utilizator,

implementat prin evenimente. În cazul de față, evenimentele tratate sunt cele de click
de mouse pe o componentă ce duce la execuția unei anumite proceduri. De exemplu
executând click pe butonul „IESIRE” va determina iesirea din joc.

6. Plan de testare cu Junit

La jocul Brainie s-au făcut următoarele teste:
package test;

import static org.junit.Assert.assertEquals;

import java.awt.Color;

import javax.swing.JPanel;

import org.junit.Test;

import Decorator.Decorator;
import Utils.MyJButton;
import Utils.Randoms;

public class testjunit {

@Test
public void test() {
MyJButton button = new MyJButton(2);
button.setActionCommand(""+2);
assertEquals(Integer.parseInt(button.getActionCommand()), 2);
}
@Test
public void test2() {
Randoms test = new Randoms();
int result = test.randInt(1,2);
assertEquals(1,result);

}
@Test
public void test3() {
Decorator test = new Decorator();
JPanel panel = new JPanel();
test.colorPanel(panel, Color.BLUE);
assertEquals(panel.getBackground(),Color.BLUE);
 }
}

7. Principii
Întrucât s-au folosit șabloane de design, respectarea principiilor și a euristicilor
programării orientate obiect este posibilă.
Principiul deschis-închis este evident, deoarece se păstrează adesea starea
obiectelor în membrii privați pentru a nu putea fi modificați din greșeală, astfel încât
comportamentul obiectului să fie controlat.

Conform principiului lui Liskov, funcțiile care utilizează pointeri sau referințe la clase
de bază trebuie să poată folosi instanțe ale claselor derivate fără să își dea seama
de acest lucru.

Conform principiului inversării dependențelor, modulele de pe nivelurile ierarhice

superioare nu trebuie să depindă de modulele de pe nivelurile ierarhice inferioare.
Toate ar trebui să depindă doar de module abstract. De asemenea, abstractizările nu
trebuie să depindă de detalii. Detaliile trebuie să depindă de abstractizări. Acest
principiu este prezent în implementarea centrată pe interfețe și prin evitarea
dependențelor tranzitive.

Euristici
Evaluarea utilizatorului interfetei se bazeaza pe o serie de euristici (Jakob Nielsen):

Indeplinirea asteptarilor
- “Potrivirea” cu lumea reala
- Asigurarea consistentei & recurgerea la standarde
- Oferirea de ajutor & documentare
Utilizatorul decide – user is boss
- Controlul & libertatea utilizatorului
- Vizibilitatea starii sistemului
- Asigurarea flexibilitatii & eficientei
Tratarea erorilor
- Prevenirea erorilor
- Recognition, not recall
- Raportarea & diagnosticarea erorilor, recuperarea de dupa eroare (error
recovery)
Pastrarea simplitatii – keep it simple
- Realizarea unui design estetic & minimalist
Aplicare euristicilor formeaza un proces numit evaluare euristica. Acesta este o
metoda de inspectare, realizata de un expert in urmatoarele etape:
- Inspectarea profunda a interfetei
- Evaluarea interfetei conform euristicilor si redactarea listei problemelor survenite.
Fiecare problema trebuie justificata, conform unei euristici. Exemplu : “prea multe
optinuni de navigare in prima pagina a siteului” ( se elucideaza “Realizarea unui
design estetic & minimalist”).Intefata evaluata trebuie analizata macar de 2 ori. In
prima etapa, se pot detecta problemele generale si se poate obtine comportamentele
de ansamblu al sistemului. A doua faza poate aduce date importante privitoare la
elementele particulare.

Bibliografie

1. Suport de curs – Sabina Costache

2. „The design patterns Java companion”, James Cooper

3. „Thinking in patterns”, Bruce Eckel

4. http://www.tutorialspoint.com/design_pattern/
5. http://www.vogella.com/tutorials/JUnit/article.html