Ministerul Educaţiei Tineretului şi Sportului al Republicii Moldova

Universitatea Tehnică a Moldovei

Catedra ATI

Lucrarea de curs
la APOO

Tema: Sistem de fișier distribuit.

A efectuat: st. gr TI-051 f/r Gheorghieș Iurie

A verificat: Ciorbă Dumitru

Chişinău 2010
 1. Analiza și Proiectarea Obiect Orientată.
Analiza şi proiectarea obiect orientată (APOO) este o tehnică din ingenerie
software care modelează sistema ca un grup de obiecte interactive. Fiecare obiect
reprezintă o entititate in sitema modelată şi este caracterizată de clasa sa, statutul
(datele), si comportamentul sau. Diverse modele pot fi create pentru a reprezinta
structură statică, comportament dinamic şi run-time deployment a acestor obiecte în
colaborare. Există diverse notaţii de reprezentare a acestor modele, ca spre exemplu
Unified Modeling Language (UML). Analiza obiect orientată (AOO) aplică modelul
obiectual în analiza cerinţelor funcţionale a sistemei. Proiectarea obiect orientă (POO)
eleaborează modele de analiză pentru a produce implementarea specificaţiilor. AOO se
concentrează asupra funcționalitații ce le v-a avea sistemului, POO cum vor fi realizate
aceste funcționalități în sistemă.

1.1 Analiza obiect orientată.

Analiza obiect orientată a unei aplicații implică realizarea mai multor categorii de
modele, dintre care cele mai importante sunt:

a) Modelul de utilizare: realizează modelarea problemelor şi a soluţiilor acestora în

maniera în care le percepe utilizatorul final al aplicaţiei. Diagramă asociată:
diagramă de cazuri de utilizare.

b) Modelul structural: se realizează pe baza analizei statice a problemei şi descrie

proprietăţile statice ale entităţilor care compun domeniul problemei. Diagrame
asociate: diagramă de module, diagramă de clase.

c) Modelul comportamental: priveşte descrierea funcţionalităţiilor şi a succesiunii în

timp a acţiunilor realizate de entităţile domeniului problemei. Diagrame asociate:
diagrama (harta) de stări, diagrama de colaborare, diagrama de interacţiune.

1.2 Proiectarea obiect orientată.

Proiecarea obiect orientată are loc dupa analiza si se bazeaza pe rezultatele
procesului de analiză. Cel mai des proiectarea obiect orientată la intrare necesită
urmatoarele artifacte ce sau obținut in rezultatul analizei: modelul conceptual,
diagramele Use Case, diagrame particulare de secvență a diagramelor Use Case,
interfața grafica, modelul relational si altele. In urma procesului de proiectare ca rezultat
vom obține urmatoarele: diagrama de secvențe si diagrama de clase. In general va avea
loc o analiză in care se vor lua in consideratie mediul exterior si anume, anumiti
algoritmi, anumite arhitecturi, platforma de rulare si alte nuanțe ce pot influența atit
rularea cit si procesul de dezvoltare a aplicației.
 2. Procesul de dezvoltare software
Procesul de dezvoltare software este o structură impusă de dezvoltare a produselor
software. Sinonimele acestuia ar fi ciclul de viaţă software şi procesul software. Sunt
cunoscute cîteva modele pentru astfel de procese, fiecare descrie o varietate de abordări
de activităţi şi sarcini care au loc în timpul procesului. Pe parcursul timpului tot mai
multe companii de dezvoltare software implementează metodologii a procesului. Multe
din ele sunt amplasate sau activează pe piaţa SUA care cere prezenţa unei astfel de
metodologii pentru obţinerea contractului. Standartul internaţional care descrie modul de
selectare, implementare şi monitorizare a ciclul de viaţă a software este ISO 12207.

2.1 Activitațile procesului de dezvoltare software.

Activitațile procesului de dezvoltare software presupune urmatoarele etapele ce sunt
aratate in figura 1. Insa daca vom generaliza vom putea descrie urmatoarele :
1) Planificarea.
2) Implementarea, testarea si documentarea.
3) Deployment și mentenanța.

Figura 1. Activitațile procesului de dezvoltare software.

 2.1.1 Planificarea.
Sarcină importantă în crearea unui produs software este de extragere a cerinţelor
sau analiza cerinţelor. Clienţii au de obicei o idee abstractă a ceea ce doresc ca un
rezultat final, dar nu ceea ce software-ul ar trebui să facă. Incomplete, ambigue, sau
chiar cerinţe contradictorii, sunt recunoscute de ingineri software calificaţi şi cu
experienţă în acest moment. Demonstrarea frecvent a codului pot ajuta la reducerea
riscului precum că cerinţele sunt incorecte. După ce cerinţele generale sunt stabilite din
partea clientului, o analiză a domeniului de aplicare si dezvoltare ar trebui să fie
determinată şi în mod clar. Acest lucru este adesea numit în document domeniul de
aplicare. Anumite funcţionalităţi pot fi în afara domeniului de aplicare a proiectului, în
funcţie de costuri sau ca urmare a cerinţelor neclar la începutul dezvoltării. În cazul în
care dezvoltarea se face pe plan extern, acest document poate fi considerat un document
legal, astfel că, dacă există vreodată dispute, orice ambiguitate a ceea ce sa promis la
client pot fi clarificate.

2.1.2 Implementarea, testarea si documentarea.

Implementarea este parte a procesului unde inginerii software-ul de fapt
programeza codul pentru proiect.
Testarea Software-ul este o parte integrantă şi importantă a procesului de
dezvoltare software. Această parte a procesului trebuie să asigure depistarea bug-urilor
cât mai curând posibil.
Documentarea este procesul de desriere a structurii interne a proiectului, în scopul
întreţinerii viitoare şi ameliorare, se face pe intreaga durata de dezvoltare. Acest lucru
poate include, de asemenea, descrierea unui API, fie ea internă sau externă.

2.1.3 Deployment și mentenanța.

Deployment-ul începe după ce codul este testat în mod corespunzător, este
aprobat pentru eliberarea şi vândute sau distribuite într-un mediu de producţie. Suportul
este important, deoarece un procent mare de proiecte software dă greș deoarece
dezvoltatorii nu reuşesc să-și dea seama că nu contează cât de mult timp şi cită
planificare o echipa de dezvoltare pune în crearea de software, dacă nimeni în
organizaţie nu ajunge să o utlizeze. Oamenii sunt adesea rezistente la schimbare şi de a
evita aventurează într-o zonă necunoscută, în faza de deployment, este foarte important
să avem cursuri de formare pentru noii clienţi a software-ului dumneavoastră.
Întreţinere şi îmbunătăţirea software-ul pentru a face faţă problemelor de nou
descoperite sau cerinţe noi, poate lua timp mult mai mult decât dezvoltarea iniţială a
software-ului. Ar putea fi necesară adăugarea de cod care nu se potriveşte design
original, pentru a corecta o problemă neprevăzute sau se poate ca un client solicită mai
multă funcţionalitate şi un cod pot fi adăugate pentru înregistrarea cererilor lor. Acesta
este timpul acestei faze în care clientul solicită veni în şi veţi vedea dacă testarea dvs. a
fost suficient de extinsă pentru a descoperi problemele înainte de a face clienţii. În cazul
în care costul forţei de muncă din faza de întreţinere depăşeşte 25% din costul fazele
anterioare "de munca, atunci este probabil ca calitatea globală, a cel puţin o fază înainte,
este slabă. În acest caz, managementul ar trebui să ia în considerare posibilitatea de a
reconstruirii sistemului (sau porţiuni), înainte de a costurilor de întreţinere este de sub
control.
Sistemul de gestiune al problemelor instrumente sunt adesea utilizate în această
etapă a procesului, pentru a permite echipelor de dezvoltare, pentru a interfaţă cu client /
echipele de teren de testare software-ul pentru a identifica orice probleme reale sau
percepute. Aceste instrumente software, atât open source şi comercial, sub licenţă, să
asigure un proces de personalizabil să achiziţioneze, revizuire, recunosc, şi să răspundă
la problemele raportate.

2.2 Modele existente.

În prezent sunt cunoscute un număr de modele inventate pentru analiza şi
proiectarea obiect orientată. În continuare vom descrie patru din cele mai utilizate.

2.2.1 Model Iterativ.

Dezvoltarea iterativă prescrie construcţia iniţial mici dar largi bucăţi de proiecte
software pentru a ajuta pe toţi implicaţi să dezvălue problemele importante pînă
problemele să aducă la dizastru. Procesul iterativ este preferat de către dezvoltatorii
comerciali deoarece el permite obținerea de puncte cheia a ceea ce doresc clienții ce nu
ştiu cum să definească ceea ce ei doresc. In figura 2 este prezentat schematic modelul
iterativ.

Figura 2. Modelul Iterativ.

 2.2.2 Model Agile.
Procesul agile software development este construit pe baza a procesului iterativ.
La acest fundament ei au adăugat abordări mai simple, mai apropiate viziunii omului
decîte cele tradiţionale. Procesul agile foloseşte feedback, şi nu planificarea, ca
mecanizm primordial de control. Feedbackul stă în spatele a testurilor şi realizărilor
frecvente a produsului software.

2.2.3 Extreme Programming (XP).

Programarea extremă (XP) este cel mai cunoscut proces iterativ. În XP, fazele
sunt expulzate în afară, în paşi extrem de mici (sau continue) în comparație cu procesul
„batch”. Primul pas poate dura o zi sau o săptămînă în comparaţie cu luni sau ani de zile
pentru fiecare pas complet ca în modelul Waterfall. Prima este în crearea a testurilor
automate, pentru a obţien ţinte concrete pentru dezvoltare. Urmează codarea (de o
pereche de programatori), care este finalizată cînd toate testele sunt trecute şi
programatorii pot să mai elaboreze ceva teste dacă este necesar. Proiectarea şi
arhitectura merg spre refactoring, ele vin după codare. Proiectarea este făcută de aceaşi
persoane care au şi scris codul. Doar sistema incompletă dar funcţională este
demonstrată utilizatorului. Doar la această etapa se începe scrierea a noi test-uri pentru
următoarea parte a sistemei.

Figura 3. Modelul XP.

 2.2.4 Waterfall process.
Modelul Waterfall (cădere de apă) demonstrează procesul unde dezvoltatorii sunt
obligaţi să urmeze următoarele etape în ordine:
1) Colectarea specificaţiilor.
2) Proiectarea.
3) Construcţie.
4) Integrare.
5) Testare şi depanare.
6) Instalare.
7) Mentinanţă.

După fiecare pas procesul continuă cu următorul pas. Principalul argument

impotriva acestui tip costa in faptul ca fiecare iteratie se face o singura data iar aceasta
impune unele probleme deoarece practica spune ca nimic nu este ideal, astfel apar
intrebari cum se vor rezolva problemele depistatate in etapele anterioare, aceasta impune

3. Sarcina lucrarii.
Crearea unei specificatii și apicații de tip server ce ar realiza un sistem de tip
'Sistem distribuit de fișiere' (DFS). Metoda de realizare a procesului de dezvotare este
ales la dorința.

3.1 Descrierea sarcinei.

Există multe realizări a unui DFS, cum ar fi NFS, SMB, AFS si
multe alte fiscare avind realizarea si specificațiile lor. De obicei din
punct de vedere al utilizatorului ele ofera posibilitatea de a face acces
deschis la un folder și conținutul său pentru acces. Aceasta deși
ușureaza configurarea și menținerea contentului in rețea are un
neajuns și anume utilizatorii știu și vad tot ce se petrece in folder.
 Figura 4. Schema conceptului DFS.

Pentru aceasta voi incerca sa realizez un simplu protocol și o aplicație care ar

depași acest neajuns. Ideea de baza pe care o voi realiza in acest proiect este de a
abstractiza noțiunea de fișier, adica serverul v-a avea un fișier de configurații unde se
vor descrie nodurile care sunt, ierarhia și resursele pe care le poseda, adica voi introduce
o noțiune noua ca nod ce ar reprezenta un folder in ințelegerea obișnuita și fiecare nod
care caracterizeaza o resursa fizica ca resursa. În figura 4 este reprezentată aceasta idee.
În general pentru realizarea unui server de acest gen nu e neaparat proiectarea unui
intreg protocol de comunicare, este posibil de a lua un protocol deja existent și de a
rescrie codul sesiunii pentru realizarea lui inlocuind noțiunile generale cu cele propuse.

3.2 Analiza cerinței.

Deoarece rolul de client imi aparține desrierea sarcinei este
specificata in desrierea sarcinei. Sistemul va avea o structura de tip
clientserver. Clientul fiind user-ul care v-a naviga in contentul deschis
din rețea al userului pe care ruleaza partea Server. În continuare vor
urma diagramele Use Case care și vor specifica necesitățile impuse.
 Figura 5. Operațiile de navigare.

În figura 5 sunt arătate operațiile necesare pentru partea

clientului. Principalele fiind acțiunile de tip Browse. Comanda ln va
returna conținutul fișierului curent și nume nodurile de tip folder iar lr
va returna resursursele. Comanda cd schimba starea sesiunii și
anume seteaza nodul curent acel fișier specificat. Serverul va avea
rolul de menținere a sesiunilor și posibilitatea de configurare. Însa
pentru client serverul v-a avea urmatoarea forma prezentata în figura
6.
 Figura 6. Operațiile de administrare.

3.3 Procesul de analiza

Procesul de conexiune la server are o importanţă majoră în
sistemă şi este reprezentă prin diagrama de activităţi din figura 7.
 Figura 7. Conexiunea client.

Pentru configurarea clientului se vor cere IP serverului si port-ul

pe care ruleaza serverul. Iar procedeul de transmitere a comenzilor
este reprezentat in figura 8.

Figura 8. Executarea comenzilor.

 Diagrama de secvență (figura 9) va arăta ordinea in care se va
executa comanda, mai precis spus ce componenete vor interactiona și
cum se vor transmite semnalele de la component la component. In
dependență de comanda obiectul de tip sesiune va returna starea in
care se afla ori va crea o instanta de tip sender care va realiza
procesul de transmitere a fisierului.
 Figura 9. Propagarea mesajului.

3.4 Procesul de proiectare.

Cu rezultatele din procesul de analiza și deoarece aceasta este
prima iterație putem crea o diagrama a claselor abstracta in figura 10.
Aceasta diagramă nu va reprezenta diagrama finală. La fiecare
iterație se pot adauga, scoate se redefini unele componente clase. In
general pentru realizarea acestui proiect este necesara o metodologie
de proiectare de tip iterativ deoarece pot apărea noi cereri față de
apliație atît tehnice și de arhitectură cit și conceptuale.
 Figura 10. Diagrama Claselor.

Pentru realizarea acestui proiect voi utiliza ca limbaj de

programare Python, deoarece este simplu in utilizare și o buna baza
pntru schițarea apliației, in caz de depistare a botleneck-urilor
componenta va putea fi rescrisa in alt limbaj ce poseda o platformă
runtime mai rapidă precum C, C++ și altele.
 Concluzie
Pentru realizarea sarcinii propuse am studiat diferite metodologii
de proiectare și analiza. Fiecare metoda posedă plusuri și minusuri.
Oricum orice metodologie in sine include metodologia iterativa avind
deosebiri doar in accentuarea unor puncte pe care fiecare
metodologie o scoate mai evident ca fiind mai semnificative sau
necesare. În general in cazul aplicaţiei propuse se putea utiliza orice
metodologie chiar și WaterFall in caz de adoptare a unui protocol deja
existent cum ar fi ftp, sau altele de acest gen.

Bibliografie

http://en.wikipedia.org/wiki/Object-oriented_design
[Resursă electronică]
http://en.wikipedia.org/wiki/Objectoriented_ analysis_and_design
[Resursă electronică]
http://en.wikipedia.org/wiki/Distributed_file_system
[Resursă electronică]
Learning UML 2.0, Kim Hamilton
[Resursă electronică]
 Anexa A
Codul Sursă
****************************************
'''
Created on Sep 7, 2009
@author: gheorghies
unit fsclass.py
'''
import os.path
class Node():
def __init__(self, name):
self.__parent = None
self.__child = []
self.__name = name
self.__resources = {}
def get_name(self):
'''node name'''
return self.__name
def add_child(self, child):
'''add a child path'''
if child.__class__ != Node:
raise 'Not a node!!!'
self.__child.append(child)
child.__parent = self
def del_child(self, child):
'''delete child path'''
if child.__class__ != Node:
raise 'Not a node!!!'
if self.__child.__contains__(child):
self.__child.remove(child)
def get_child(self, name):
'''get child path object from name if not exist then None'''
for ch in self.__child:
if ch.__name == name:
return ch
return None
def child_exist(self, name):
for ch in self.__child:
if ch.__name == name:
return True
return False
def get_parent(self):
return self.__parent
def add_resource(self, name, path):
'''add resource'''
# check if file exist !!!
if os.path.isfile(path):
self.__resources[name] = path
return True
return False
def delete_resource(self, name):
'''delete resource'''
del self.__resources[name]
def resource_exist(self, name):
'''check if resource with name 'name' exist'''
if self.__resources.has_key(name):
return True
return False
def get_resource_file(self,name):
if self.resource_exist(name):
return self.__resources[name]
def ln(self):
'''white space delimited child names'''
return ' '.join(ch.__name for ch in self.__child) + '\n'
def lr(self):
'''white space delimited resource names'''
return ' '.join(rs for rs in self.__resources.keys()) + '\n'
'''
Created on Sep 7, 2009
@author: gheorghies
unit sesion.py
'''
import commandparser
import sender
class Sesion():
def __init__(self,user_pass_dict,root,getport):
self.__flaglogged = False
self.__user_pass_dict = user_pass_dict
self.__cmdparser = commandparser.CommandParser()
self.__curent_dir = root
self.__getport = getport
def exec_comand(self,command):
'''command --> Code + command'''
try:
cmdtuple = self.__cmdparser.getParams(command)
except:
return '0 Bad command\n'
# if not cmdtuple:
# return '0 Bad command\n'
# logging
if not self.__flaglogged:
if len(cmdtuple) != 4:
return '0 Bad command\n'
if cmdtuple[0] == 'usr' and cmdtuple[2] == 'pwd':
if not self.__user_pass_dict.has_key(cmdtuple[1]) or not
self.__user_pass_dict[cmdtuple[1]] == cmdtuple[3]:
return '0 Logon failed\n'
else:
self.__flaglogged = True
return '1 OK\n'
else:
return '0 Bad command\n'
#ls
if cmdtuple[0] == 'ln':
return self.__curent_dir.ln()
#cd
elif cmdtuple[0] == 'cd':
if cmdtuple[1] == '.':
if self.__curent_dir.get_parent() != None:
self.__curent_dir = self.__curent_dir.get_parent()
return '1 OK\n'
else:
return '0 Bad command\n'
if self.__curent_dir.child_exist(cmdtuple[1]):
self.__curent_dir = self.__curent_dir.get_child(cmdtuple[1])
return '1 OK\n'
else:
return '0 No such folder\n'
elif cmdtuple[0] == 'lr':
return self.__curent_dir.lr()
#get
elif cmdtuple[0] == 'get':
if self.__curent_dir.resource_exist(cmdtuple[1]):
snd =
sender.Sender(self.__getport,self.__curent_dir.get_resource_file(cmdtuple[
1]))
snd.start()
return str(self.__getport) + '\n'
else:
return '0 Bad command\n'
else:
return '0 Bad command\n'