Universitatea Ovidius Constanta, Facultatea de Matematica si Informatica

INGINERIA SISTEMELOR SOFTWARE

Proiect: E-ManagementImobiliare

Profesor indrumator: Lector Dr. Puchianu Crenguta

Studenti:

Specializarea: Informatica
Anul III, seria 1, grupa 1

CUPRINS

1
  TEMA DE PROIECT ….…………………………………………....... pg.3
 CERINTE FUNCTIONALE …………………………………….…... pg.4
 CERINTE NEFUNCTIONALE ………………………………….…... pg.7
 DESCRIEREA A PATRU CAZURI DE UTILIZARE SOFT ….…... pg.8
 DIAGRAMA UML A CAZURILOR DE UTILIZARE ………….…. pg.13
 DIAGRAMA UML DE ACTIVITATI ………………………….……. pg.14
 DIAGRAMA DE CLASE A MODELULUI DE DOMENIU ….……. pg.18
 DIAGRAMA UML DE SECVENTE DE SISTEM ……………….…. pg.19
 DIAGRAMA DE CONTEXT ………………………………………… pg.21
 DIAGRAMA DE SECVENTE (PROIECTARE) …………………… pg.22
 DIAGRAMA DE CLASE (PROIECTARE) …………………………. pg.24
 EXPLICAREA APLICARII MODELELOR DE PROIECTARE
GENERALE DE ATRIBUIRE A RESPNSABILITATILOR ………pg.26

Proiect: E-ManagementImobiliare
Agenţia imobiliară ManagementImobiliare intermediază vânzarea sau închirierea
imobilelor(apartamente, garsoniere, case, vile), a spaţiilor comerciale şi a terenurilor din

2
Constanţa.Pentrugestiunea mai uşoară a intermedierilor, proprietarul agenţiei a decis să cumpere
sistemul software E-ManagementImobiliare.
Orice client poate vizualiza interfaţa grafică principală a sistemului E-
ManagementImobiliare şide a face anumite căutări: după tipul imobilului, zona dorită şi tipul
tranzacţiei (cumpărare sau închiriere). Aplicaţia afişează rezumate ale anunţurilor (împreună cu
pozele) despre imobilele,spaţiile comerciale sau a terenurilor găsite.
Clientul, posibil cumpărător, se prezintă la un agent imobiliar al companiei. La cererea
agentului,aplicaţia printează un acord de confidenţialitate prin care clientul se obligă că nu va da
informaţiidespre imobilele văzute la agenţia ManagementImobiliare în cazul în care se duce şi la
alte agenţii imobiliare. După ce semnează, clientul primeşte un nume de utilizator şi o
parolăgenerate de sistem pentru a fi accesat.
Dupa ce se loghează, posibilul cumpărător completează un formular afişat de aplicaţie cu
datedespre cerinţele pe care trebuie să le îndeplinească imobilul căutat. Aceste cerinţe sunt:
tipulprodusului (imobil, spaţiu comercial sau teren), tip tranzacţie (cumpărare sau închiriere),
numărde camere, materiale folosite (bca, ciment sau caramidă), zona sau zonele dorite, orientare
(unuldin cele 4 puncte cardinale), cu sau fără loc de parcare, cost aproximativ (în euro) şi etajul
sauetajele preferate.
Sistemul caută şi afişează lista rezultatelor găsite. Din aceste rezultate, clientul poate alege
unulsau mai multe imobile pe care vrea să le vadă. In acest caz, sistemul anunţă agenţii imobiliari
care se ocupă cu vânzarea sau închirierea lor şi pe proprietarii (vânzători) care deţin
respectiveleproprietăţi.
Aceştia din urmă sunt anunţaţi automat de către sistem că există un posibil cumpărător şifolosind
aplicaţia E-ManagementImobiliare scriu o listă de date şi ore când sunt disponibili.
Această listă este afişată agentului şi viitorului cumpărător. Acesta alege una sau mai multe date
când ar fi disponibil. Sistemul alege prima din aceste date şi o transmite agentului imobiliar
şivânzătorului.
In plus, orice vânzător poate accesa sistemul E-ManagementImobiliare pentru a posta un
anunţimobiliar. Pentru aceasta, vânzătorul trebuie săcompleteze un formular cu datele (cerinţele
demai sus) despre imobilul pe care-l scoate la vânzare şi o poză jpg de interior al imobilului sau o
poză a terenului. După aceea, aplicaţia generează automat şi afişează un anunţ, pe
careutilizatorul îl poate modifica. Apoi, anunţul este salvat pe suport persistent şi este afişat la
cererea utilizatorului.
Agentul imobilar care se ocupă cu intermedierea vânzării sau închirierii a unor produse
imobiliare poate vizualiza la cerere situaţia sa: dacă au fost vizualizate rezumatele sau
anunţurileproduselor de care se ocupă, etc.
Sistem de intermediere a vanzarilor sau inchirierilor imobilelor, spatiilor
comerciale sau terenurilor

Documentul cerintelor

3
1. Descrierea sistemului: sistemul intermediaza vanzarea sau inchirierea imobilelor,
spatiilor comerciale sau terenurilor.
2. Actori software: client, posibil cumparator (client care are user si parola), agent
imobiliar, vanzator (detinator proprietate)
3. Cerinte functionale:

F1. Vizualizare proprietati

F1.1 Permite vizualizarea anunturilor.
F1.2 Permite cautarea anunturilor dupa anumite criterii: tip imobil, zona,
tiptranzactie (cumparare/inchiriere)
F1.3Afiseaza lista anunturilor conform criteriilor introduse, impreunacu
un rezumat si poze despre imobilele/spatiilecomerciale/terenurile gasite.
F1.4 In cazul in care nu exista anunturi care indeplinesc creteriile de cautare
se afiseaza un mesaj corespunzator.

F2. Logarea in aplicatie

F2.1 Permite introducerea userului si parolei primite pentru autentificare
F2.2 Valideaza existenta contului.
F2.3 In cazul in care una din date nu este completata sau este invalida afiseaza un
mesaj de avertizare.
F2.4 Altfel, autentificarea se face cu succes.

F3. Furnizare acord confidentialitate

F3.1 Permiteprintarea unui acord de confidentialitate.
F3.2 Daca clientul nu semneaza acordul este afisat mesaj de eroare.
F3.3 Altfel, genereaza user si parola pentruaccesarea sistemului.
F3.4 Memoreaza acordul de confidentialitate, userul si parola.

F4. Alegereimobil
F4.1 Permite introducerea cerintelor clientului prin afisarea unui formular: tip
produs (imobil, sp.comercial, teren), tip tranzactie, nr.camere, materiale
folosite, zona, orientare, existenta loc parcare, cost aproximativ, etaj.

4
 F4.2Cauta si afiseaza lista rezultatelor gasite conform criteriilor introduse
F4.3Daca nu sunt rezultate care indeplinesc criteriile mentionate afiseaza
un mesaj corespunzator.
F4.4Altfel, permite alegerea unuia sau mai multor imobile din lista.
F4.5 Anunta agentii imobiliari si vanzatorul de un posibil cumparator.

F5. Vizitare proprietate

F5.1Primeste de la vanzator o lista cu datele si orele la care este disponibil.
F5.2 Afiseaza lista agentului imobiliar si viitorului cumparator.
F5.3Permite clientului alegerea uneia sau mai multor date din lista de
disponibilitate
F5.4Alege prima data din lista si o trimite agenului imobiliar sivanzatorului.

F6. Furnizare lista disponibilitate

F6.1 Anuntaproprietariiin cazul in care exista un posibil cumparator.
F6.2 Permite intocmirea unei liste cu datele si orele la care sunt disponibili.
F6.3 Afiseaza lista agentului si viitorului cumparator.

F7. Administrare anunturi

F7.1 Permite completarea datelor si a unei poze cu proprietatea scoasa la
vanzare, prin afisarea unui formular.
F7.2 Verifica corectitudinea datelor introduse
F7.3 Daca datele nu sunt corecte afiseaza un mesaj de eroare.
F7.4 Altfel, memoreaza datele noului anunt.
F7.5 Genereaza si afiseaza anuntul.
F7.6Permite modificarea anuntului afisat.
F7.7 Verifica corectitudinea datelor modificate
F7.8Actualizeaza si memoreaza datele noului anunt.

F8. Adaugare anunt imobiliar

F8.1 Permite completarea datelor si a unei poze cu proprietatea scoasa la
vanzare, prin afisarea unui formular.
F8.2 Verifica datele introduse

5
F8.3 In cazul in care datele nu sunt corecte din punct de vedere sintactic sau sunt
incomplete afiseaza un mesaj de eroare.
F8.4Altfel, genereaza anuntul si il afiseaza.
F8.5Memoreaza anunt.

F9. Modificare anunt imobiliar

F9.1 Permite introducerea datelor de identificare ale anuntului (ex: cod anunt).
F9.2 Valideaza datele introduse.
F9.3 Daca datele sunt invalide afiseaza mesaj de eroare.
F9.4 Altfel, permite modificarea datelor anuntului: tip produs, nr.camere,
materiale folosite, zona, orientare, loc parcare, cost aproximativ, etaj.
F9.5 Verifica corectitudinea datelor.
F9.6 In cazul in care apar erori afiseaza un mesaj corespunzator.
F9.7Altfel, memoreaza modificarile efectuate si actualizeaza anuntul.

F10. Vizualizare situatie proprie

F10.1 Permiteintroducereadatelor deidentificare ale agentului imobiliar.
F10.2 Vaideaza date
F10.3 In caz ca datele sunt incorecte se afiseaza un mesaj de eroare.
F10.4 Atlfel, permite vizualizarea situatiei proprii: verificarea rezumatelor si
anunturilor de care se ocupa, tranzactii etc.

4. Cerinte nefunctionale:
a. Aplicatia foloseste o baza de date in Access/Oracle pentru gestiunea
datelor persistente.
b. Utilizare:

6
  utiliatorii nu trebuie sa urmeze un instructaj pentru a folosi aplicatia.
 aplicatia foloseste interfete grafice sugestive
 aplicatia trebuie sa ruleze pe orice sistem de operare
c. Robustete: sistemul verifica datele primite de la user. Daca sunt incorecte
este afisat un mesaj de eroare si se ofera posibilitatea reintroducerii
datelor.

Modelul functional

I. Descrierea a patru cazuri de utilizare software

7
1. Cazul de utilizare Alegere imobil
 Nume: Alegere imobil
 Descriere:Descrie comportamentul sistemului si interactiunea lui cu
utilizatorul pentru selectarea unei proprietati care urmeaza a fi vizitata.
 Actor software: posibil cumparator
 Eveniment declansator: Posibilul cumparator solicita cautarea unor proprietati
dupa anumite criterii.
 Preconditii: Dupa logarea in aplicatie este disponibil formularul de cautare
 Postconditii: Sistemul memoreaza imobilului selectat si anunta vanzatorul
(proprietarul) si agentul imobiliar cu privire la un posibil cumparator.
 Referinte incrucisate:
F4.1 -> F4.5

 Flux principal

Utilizator
1. Cere afisarea proprietatilor
3. Completeaza si trimite datele
8. Selecteaza din lista afisata
imobilele pentru vizita [A3]
Sistem
2. Cere completarea criteriilor dorite.
4. Verifica datele primite [A1]
5. Face cautarea dupa criteriile introduse
6. Afiseaza lista rezultatelor obtinute [A2]
7. Permite alegerea unuia sau mai multor imobile din lista
9. Anunta vanzatorul si agentul imobiliar despre un posibil
cumparator.

 Fluxuri alternative:
o [A1]: Datele sunt incomplete sau incorecte d.p.d.p sintactic
1. Sistemul afiseaza un mesaj de eroare
2. Fluxul continua cu pasul 2 din fluxul principal
o [A2]: Nu exista anunturi care indeplinesc criteriile introduse
1. Sistemul afiseaza un mesaj corespunzator

8
 2. Fluxul se incheie
o [A3]: Utilizatorul nu selecteaza nimic din lista afisata
1. Sistemul afiseaza un mesaj de avertizare
2. Fluxul se incheie

9
 2. Cazul de utilizare “Administrare anunturi”

 Nume: Administrare anunturi

 Descriere: Descrie comportamentul sistemului si interactiunea lui cu
utilizatorul in cazul in care acesta doreste adaugarea sau modificarea
unui anunt.
 Actor software:vanzator
 Eveniment declansator:Vanzatorul alege optiune de adaugare a unui nou anunt
 Preconditii:Vanzatorul poate vizualiza si adaugaanunturi.
 Postconditii: Sistemul memoreaza noul anunt si il afiseaza.
 Referinte incrucisate:
F7.1 -> F7.8

 Fluxul principal

Vanzator
1. Cere adaugare anunt
3. Introduce si trimite datele noului anunt
8. Alege modificare anunt
9. Trimite datele noului anunt
Sistem
2. Cere completarea formularului de adaugare anunt
4. Verifica corectitudinea datelor primite [A1]
5. Memoreaza datele noului anunt
6. Genereaza si afiseaza anuntul
7. Permite modificarea anuntului [A2]
10. Verifica noile date [A3]
11. Actualizeaza anuntul conform noilor date.
12. Memoreaza noul anunt.

 Fluxuri alternative:
o [A1]: Date necompletate sau incorecte
1. Sistemul afiseaza un mesaj de eroare
2. Fluxul se continua cu pasul 2 din fluxul principal

o [A2]: Anuntul nu este modificat

1. Sistemul afiseaza un mesaj corespunzator
2. Fluxul se incheie

o [A3]: Datele nu sunt complete sau corecte din punct de vedere sintactic
1. Sistemul afiseaza un mesaj de avertizare

10
 2. Fluxul se continua de la pasul 7 al fluxului principal
3. Cazul de utilizare “Logare in aplicatie“

 Nume: Logare in aplicatie

 Descriere: Descrie comportamentul sistemului si interactiunea lui cu
utilizatorul pentru autentificarea in aplicatiei .
 Actor software:Posibil cumparator
 Eveniment declansator: Posibilul cumparator se logheaza in aplicatie cu userul si
parola furnizate.
 Preconditii: Dupa accesarea aplicatie este disponibila fereastra de logare care permite
introducerea userului si parolei primite pentru autentificare.
 Postconditii:Este disponibil formularul de cautare.
 Referinte incrucisate:
F2.1 -> F2.4

 Flux principal

Utilizator Sistem
1. Cere logarea in aplicatie 2. Afiseaza formularul de autentificare
3. Introduce userul si parola 4. Valideaza datele[A1]
5. Logheaza userul in aplicatie.

 Fluxuri alternative:
o [A1]: Username sau parola incorecte
1. Sistemul afiseaza un mesaj de eroare
2. Fluxul continua cu pasul 2 din fluxul principal

11
 4. Cazul de utilizare “Modificare anunt imobiliar”

o Nume: Modificare anunt imobiliar

o Descriere: Descrie comportamentul sistemului si interactiunea lui cu
utilizatorul pentru modificarea unui anunt imobiliar.
o Actor software: vanzator
o Eveniment declansator: Vanzatorul alege optiune de editare a unui anunt propriu
o Preconditii: Vanzatorul poate vizualiza si edita anunturile proprii.
o Postconditii: Sistemul memoreaza modificarile efectuate de vanzator si
actualizeaza anuntul.
o Referinte incrucisate:
F9.1 -> F9.7

 Fluxul principal

Vanzator
1. Acceseaza optiunea de editare anunt
3. Introduce si trimite date
6. Introduce si trimite noile date
Sistem
2. Cere introducerea datelor de identificare anunt
4. Verifica validitate date primite [A1]
5. Cere introducerea/modificarea datelor anuntului
7. Verifica datele primite [A2]
8. Memoreaza modificarile
9. Actualizeaza anuntul conform noilor date.
10. Memoreaza noul anunt.

 Fluxuri alternative:
o [A1]: Date necompletate sau incorecte
1. Sistemul afiseaza un mesaj de eroare
2. Fluxul se continua cu pasul 2 din fluxul principal

o [A2]: Datele nu sunt complete sau corecte din punct de vedere sintactic
1. Sistemul afiseaza un mesaj de avertizare

12
2. Fluxul se continua de la pasul 5 al fluxului principal

13
 II. Diagrama UML a cazurilor de utilizare software
Vizualizare proprietati

Logare in aplicatie Vizitator

Vizitare proprietate

Alegere imobil Client

Vanzator
Furnizare lista
disponibilitate

Administrare anunturi

<<extend>> <<extend>>

Adaugare anunt Modificare anunt

imobiliar imobiliar

Vizualizare situatie
Furnizare acord
proprie
confidentialitate

Ag.imobiliar

14
 III. Diagrama UML de activitati pentru descrierea cazurilor
deutilizatesoftware

1. Cazul de utilizare Alegere imobil

UTILIZATOR SISTEM

Cere afisare Afiseaza formular cautare

proprietati

Completeaza si trimite
Verifica datele
formularul cu criteriile
introduse
dorite

[Date corecte] [Date incorecte]

[gaseste rezultate] [ nu gaseste]

rezultate]

Selecteaza imobile Afiseaza lista Afiseaza mesaj Afiseaza mesaj de

din lista rezultatelor gasite corespunzator eroare

[Nr=0] [Nr>=1]
Cautare anulata
Nu selecteaza Selecteaza cel
niciun imobil putin un imobil Anunta ag.imobiliari si
vanzatorul de un posibil
cumparator

Cautare anulata
Asteptare lista
disponibilitate

15
 2. Cazul de utilizare Administrare anunturi

VANZATOR SISTEM
Cere adaugare anunt Cere introducere date

Introduce date Verifica datele

proprietate primite

[Date corecte] [Date incorecte]

Memoreaza datele Afiseaza mesaj

noului anunt eroare

Genereaza si Anunt
afiseaza anuntul [Creat]

Registru anunt
[creat]
Memoreaza anuntul

Registru anunt
[actualizat]

Anunt adaugat

Cere modificare Permite modificare

anunt anunt Anunt
[actualizat]

[nu selecteaza] [selecteaza]

Registru anunt
[creat]

16
Registru anunt
[actualizat]
Nu modifica anuntul Modifica date anunt Memoreaza anuntul

Anunt memorat
3. Cazul
Anunt nemodificat de utilizare “Logare in aplicatie”

17
4. Cazul de utilizare “Modificare anunt”

18
Diagrama de clase a modelului de domeniu

19
 - vanzator 1 1
Persoana Client:Persoana
1

- proprietar - Ag.imobiliar
1 completeaza
elibereaza
detine semneaza
0..*
Formular
- tipProdus:String
- tipTranzactie:String
Ag.imobiliara Acord - nrCamere:Integer
ListaDisponibilitate
- denumire:String confidentialitate - materiale: String urmeaza -data: Date
- zona: String 1 1 -ora
- orientare: Char
- parcare: String 1

detine
- cost:Double urmeaza
- etaj: Integer 0..1
Inchiriere/
cumparare

Anunt
1..* Proprietate 1 descrie 1 ListaAnunturi
- descriere:String
- poza:String

Imobil Spatiu Teren

comercial

Diagrama UML de secvente de sistem

1. Cazul de utilizare “Alegere imobil”

20
 :SISTEM
Posibil cumparator
Vanzator
1. cereAfisareAnunturi(): void

2. trimiteDateCautare(tipProdus:String, tipTranzactie:String,
nrCamere:Integer, materiale:String,cost:Double ): ListaAnunturi

ListaAnunturi

3. trimiteListaImobileSelectate(lista:ListaImobile): void

4. anuntaVanzator():void

2. Cazul de utilizare “Administrare anunturi”

:SISTEM
utilizator

1. cereAdaugareAnunt():void

2.trimiteDescriereProprietate(tipProdus:String, tipTranzactie:String,
nrCamere:Integer, materiale:String,cost:Double,poza:Image):Anunt
Anunt

21
3. Cazul de utilizare “Modificare anunt”

4. Cazul de utilizare “Logare in aplicatie”

22
 Diagrama de context

1. Din punct de vedere structural – sistemul este modelat intr-o clasa a

carei operatii sunt operatii de sistem
Client
SISTEM
+ cereVizualizareAnunturi(): ListaAnunturi
+ trimiteDateFiltrare():ListaAnunturi
+ trimiteDateLogare():String
+ printareAcordConfidentialitate():String
+ trimiteListaImobileSelectate():void
Cumparator + trimiteListaDisponibilitate():void
+ trimireDateSelectate():void Agent imobiliar
+ trimiteDescriereProprietate():Anunt
+ trimiteDateIdentificareAnunt():Anunt
+ trimiteDateModificate():Anunt
Vanzator

2. Din punct de vedere functional – sistemul este descris intr-un caz de

utilizare software

Client

E-Management
Imobiliare

Cumparator Ag.imobiliar

Vanzator
23
 Diagrama de secvente realizata in fata de proiectare
Arata interactiunile obiectelor care participa in realizarea fiecarui caz de utilizare
SW proiectat s ordinea in timp in care sunt transmise mesajele dintre obiecte.

1. Cazul de utilizare “Alegere imobil”

24
2. Cazul de utilizare “Administrare anunturi”

25
Diagrama de clase realizata in faza de proiectare
26
1. Alegere imobil

2. Administrare anunturi
27
Explicarea aplicarii modelelor de proiectare generale de
atribuire a responsabilitatilor
28
 Controller – este responsabil de efectuarea operațiilor cerute de utilizator ,
atribuind responsabilitatea “de a face” cu evenimentele de sistem catre o clasa non-UI
care reprezinta sistemul general sau un caz de utilizare. Acesta este responsabil cu
primirea si manipularea evenimentelor sistem.acest obiect este responsabil de
efectuarea operațiilor cerute de utilizator. Controller coordonează (controlează)
operațiile necesare pentru a realiza acțiunea declanșată de utilizator si foloseste, în
general alte obiecte pentru a realiza operația, doar coordonează activitatea.Controllerul
poate încapsula informații despre starea curentă a unui usecase.Are metode care
corespund la o acțiune utilizator.

Creator – descrie modul în care alocăm responsabilitatea de a crea obiecte în

sistem În general o clasa B ar trebui să aibă responsibilitatea de a crea obiecte de tip A
dacă unul sau mai multe (de preferat) sunt adevărate:
● Instanța de tip B conține sau agregă instanțe de tip A
● Instanța de tip B gestionează instanțe de tip A
● Instanța de tip B folosește extensiv instanțe de tip A
● Instanța de tip B are informațiile necesare pentru a inițializa instanța A.

High cohesion – alocă responsabilitățile astfel încât coeziunea în sistem rămâne

ridicată. Este un principiu care se aplică pe pacursul dezvoltării în încercarea de a
menține elementele în sistem:
• responsabile de un set de activități înrudite
• de dimensiuni gestionabile
• ușor de înțeles
Coeziune ridicată (High cohesion) înseamna ca responsabilitățile pentru un element
din sistem sunt înrudite, concentrate în jurul aceluiași concept. Împărțirea programelor în
clase și starturi este un exemplu de activitate care asigură coeziune ridicată în sistem

Low Coupling - alocă responsabilități astfel încât cuplarea rămâne slabă (redusă).
Low Coupling încurajează alocarea de responsabilitați astfel încât avem:
 dependențe puține între clase;
 impact scăzut în sistem la schimbarea unei clase;
 potențial ridicat de refolosire;
Forme de cuplare:
• TypeX are un câmp care este de TypeY.
• TypeX are o medodă care referă o instanță de tipul TypeY în orce formă (parameterii,
variabile locale, valoare returnată, apel la metode)
• TypeX ește derivat direct sau indirect din clasa TypeY.

29
 Expert - alocă responsabilitatea clasei care are toate informațiile necesare pentru a
îndeplini sarcina. Incercăm sa determinăm care sunt informațiile necesare pentru a
realiza ce se cere, determinăm locul în care sunt aceste informații și alocăm
responsabilitatea la clasa care conține informațiile necesare. Expert conduce la alocarea
responsabilității în clasa care conține informația necesară pentru implementare. Ajută să
răspundem la întrebarea Unde se pune – metoda/campul.

Pure fabrication - când un element din sistem încalcă principiul coeziunii ridicate și
cuplare slabă (în general din cauza aplicării succesive a șablonului expert): alocă un set
de responsabilități la o clasă artificială (clasă ce nu reprezintă ceva în domeniul
problemei) pentru a oferi coeziune ridicată, cuplare slabă și reutilizare. Pure Fabrication
este o clasă ce nu reprezintă un concept din domeniul problemei este o clasă introdusă
special pentru a menține cuplare slabă și coeziune ridicată în sistem.

30