You are on page 1of 19

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

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. In general va avea loc o analiză in care se vor lua in consideratie mediul exterior si anume. Analiza obiect orientată a unei aplicații implică realizarea mai multor categorii de modele. diagrama de interacţiune. 1. diagrame particulare de secvență a diagramelor Use Case. 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. Analiza obiect orientată (AOO) aplică modelul obiectual în analiza cerinţelor funcţionale a sistemei. Fiecare obiect reprezintă o entititate in sitema modelată şi este caracterizată de clasa sa. Diagramă asociată: diagramă de cazuri de utilizare. diagramele Use Case. Analiza și Proiectarea Obiect Orientată. Proiectarea obiect orientă (POO) eleaborează modele de analiză pentru a produce implementarea specificaţiilor. Există diverse notaţii de reprezentare a acestor modele. Analiza şi proiectarea obiect orientată (APOO) este o tehnică din ingenerie software care modelează sistema ca un grup de obiecte interactive.2 Proiectarea obiect orientată. Diagrame asociate: diagrama (harta) de stări. AOO se concentrează asupra funcționalitații ce le v-a avea sistemului. Diverse modele pot fi create pentru a reprezinta structură statică. ca spre exemplu Unified Modeling Language (UML). diagrama de colaborare. anumiti algoritmi. comportament dinamic şi run-time deployment a acestor obiecte în colaborare. Proiecarea obiect orientată are loc dupa analiza si se bazeaza pe rezultatele procesului de analiză.1 Analiza obiect orientată. si comportamentul sau. interfața grafica. anumite arhitecturi. . b) Modelul structural: se realizează pe baza analizei statice a problemei şi descrie proprietăţile statice ale entităţilor care compun domeniul problemei. statutul (datele). Diagrame asociate: diagramă de module. 1. platforma de rulare si alte nuanțe ce pot influența atit rularea cit si procesul de dezvoltare a aplicației. POO cum vor fi realizate aceste funcționalități în sistemă. 1. modelul relational si altele. Cel mai des proiectarea obiect orientată la intrare necesită urmatoarele artifacte ce sau obținut in rezultatul analizei: modelul conceptual. In urma procesului de proiectare ca rezultat vom obține urmatoarele: diagrama de secvențe si diagrama de clase.

2. 3) Deployment și mentenanța.1 Activitațile procesului de dezvoltare software. 2) Implementarea. Pe parcursul timpului tot mai multe companii de dezvoltare software implementează metodologii a procesului. Sunt cunoscute cîteva modele pentru astfel de procese. Activitațile procesului de dezvoltare software presupune urmatoarele etapele ce sunt aratate in figura 1. Sinonimele acestuia ar fi ciclul de viaţă software şi procesul software. Insa daca vom generaliza vom putea descrie urmatoarele : 1) Planificarea. . testarea si documentarea. implementare şi monitorizare a ciclul de viaţă a software este ISO 12207. Activitațile procesului de dezvoltare software. 2. 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. Figura 1. Procesul de dezvoltare software Procesul de dezvoltare software este o structură impusă de dezvoltare a produselor software. fiecare descrie o varietate de abordări de activităţi şi sarcini care au loc în timpul procesului.

în scopul întreţinerii viitoare şi ameliorare. Această parte a procesului trebuie să asigure depistarea bug-urilor cât mai curând posibil.1 Planificarea. în funcţie de costuri sau ca urmare a cerinţelor neclar la începutul dezvoltării. 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ă. orice ambiguitate a ceea ce sa promis la client pot fi clarificate. dacă nimeni în organizaţie nu ajunge să o utlizeze. Sarcină importantă în crearea unui produs software este de extragere a cerinţelor sau analiza cerinţelor. poate lua timp mult mai mult decât dezvoltarea iniţială a software-ului. în faza de deployment.2 Implementarea. Acesta . 2. 2.1. acest document poate fi considerat un document legal. Suportul este important. 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. În cazul în care dezvoltarea se face pe plan extern. sunt recunoscute de ingineri software calificaţi şi cu experienţă în acest moment. După ce cerinţele generale sunt stabilite din partea clientului. Întreţinere şi îmbunătăţirea software-ul pentru a face faţă problemelor de nou descoperite sau cerinţe noi. dacă există vreodată dispute. astfel că. 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. ambigue. Acest lucru este adesea numit în document domeniul de aplicare.1. 2. Oamenii sunt adesea rezistente la schimbare şi de a evita aventurează într-o zonă necunoscută.1. o analiză a domeniului de aplicare si dezvoltare ar trebui să fie determinată şi în mod clar. se face pe intreaga durata de dezvoltare. Demonstrarea frecvent a codului pot ajuta la reducerea riscului precum că cerinţele sunt incorecte. Acest lucru poate include. Anumite funcţionalităţi pot fi în afara domeniului de aplicare a proiectului. Ar putea fi necesară adăugarea de cod care nu se potriveşte design original. sau chiar cerinţe contradictorii. Incomplete.3 Deployment și mentenanța. Documentarea este procesul de desriere a structurii interne a proiectului. testarea si documentarea. este foarte important să avem cursuri de formare pentru noii clienţi a software-ului dumneavoastră. descrierea unui API. fie ea internă sau externă. Testarea Software-ul este o parte integrantă şi importantă a procesului de dezvoltare software. Implementarea este parte a procesului unde inginerii software-ul de fapt programeza codul pentru proiect. 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. de asemenea.

înainte de a costurilor de întreţinere este de sub control. atunci este probabil ca calitatea globală. Sistemul de gestiune al problemelor instrumente sunt adesea utilizate în această etapă a procesului. a fost suficient de extinsă pentru a descoperi problemele înainte de a face clienţii.este timpul acestei faze în care clientul solicită veni în şi veţi vedea dacă testarea dvs. pentru a permite echipelor de dezvoltare. În continuare vom descrie patru din cele mai utilizate. Aceste instrumente software. atât open source şi comercial. să asigure un proces de personalizabil să achiziţioneze. Modelul Iterativ. În acest caz. . este slabă. recunosc. 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. pentru a interfaţă cu client / echipele de teren de testare software-ul pentru a identifica orice probleme reale sau percepute. În prezent sunt cunoscute un număr de modele inventate pentru analiza şi proiectarea obiect orientată. Figura 2. 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.2 Modele existente. sub licenţă. revizuire.1 Model Iterativ. In figura 2 este prezentat schematic modelul iterativ. managementul ar trebui să ia în considerare posibilitatea de a reconstruirii sistemului (sau porţiuni). şi să răspundă la problemele raportate.2. 2. a cel puţin o fază înainte. 2. În cazul în care costul forţei de muncă din faza de întreţinere depăşeşte 25% din costul fazele anterioare "de munca.

Doar sistema incompletă dar funcţională este demonstrată utilizatorului. 2. Feedbackul stă în spatele a testurilor şi realizărilor frecvente a produsului software. care este finalizată cînd toate testele sunt trecute şi programatorii pot să mai elaboreze ceva teste dacă este necesar. Modelul XP. Programarea extremă (XP) este cel mai cunoscut proces iterativ. Procesul agile software development este construit pe baza a procesului iterativ. ele vin după codare.3 Extreme Programming (XP). Doar la această etapa se începe scrierea a noi test-uri pentru următoarea parte a sistemei. Procesul agile foloseşte feedback. Urmează codarea (de o pereche de programatori). 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. mai apropiate viziunii omului decîte cele tradiţionale. 2. fazele sunt expulzate în afară. La acest fundament ei au adăugat abordări mai simple. Proiectarea este făcută de aceaşi persoane care au şi scris codul.2. În XP. Figura 3. Prima este în crearea a testurilor automate. pentru a obţien ţinte concrete pentru dezvoltare. în paşi extrem de mici (sau continue) în comparație cu procesul „batch”.2 Model Agile. Proiectarea şi arhitectura merg spre refactoring. . ca mecanizm primordial de control. şi nu planificarea.2.

Crearea unei specificatii și apicații de tip server ce ar realiza un sistem de tip 'Sistem distribuit de fișiere' (DFS). cum ar fi NFS.2. 3. Sarcina lucrarii. 3) Construcţie. 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. 4) Integrare. Există multe realizări a unui DFS. astfel apar intrebari cum se vor rezolva problemele depistatate in etapele anterioare. . AFS si multe alte fiscare avind realizarea si specificațiile lor.1 Descrierea sarcinei. 5) Testare şi depanare. 7) Mentinanţă. 6) Instalare. Metoda de realizare a procesului de dezvotare este ales la dorința. 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. SMB. 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. 2) Proiectarea. După fiecare pas procesul continuă cu următorul pas. 2. Modelul Waterfall (cădere de apă) demonstrează procesul unde dezvoltatorii sunt obligaţi să urmeze următoarele etape în ordine: 1) Colectarea specificaţiilor. aceasta impune 3.4 Waterfall process.

Clientul fiind user-ul care v-a naviga in contentul deschis din rețea al userului pe care ruleaza partea Server.2 Analiza cerinței. . 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. Pentru aceasta voi incerca sa realizez un simplu protocol și o aplicație care ar depași acest neajuns. În general pentru realizarea unui server de acest gen nu e neaparat proiectarea unui intreg protocol de comunicare. adica serverul v-a avea un fișier de configurații unde se vor descrie nodurile care sunt. În figura 4 este reprezentată aceasta idee. Deoarece rolul de client imi aparține desrierea sarcinei este specificata in desrierea sarcinei. Sistemul va avea o structura de tip clientserver. În continuare vor urma diagramele Use Case care și vor specifica necesitățile impuse. Ideea de baza pe care o voi realiza in acest proiect este de a abstractiza noțiunea de fișier. 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. 3. Schema conceptului DFS. ierarhia și resursele pe care le poseda. Figura 4.

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

3. Figura 6. .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. Operațiile de administrare.

Figura 8. Pentru configurarea clientului se vor cere IP serverului si port-ul pe care ruleaza serverul. . Conexiunea client. Iar procedeul de transmitere a comenzilor este reprezentat in figura 8. Executarea comenzilor. Figura 7.

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. 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.

. Cu rezultatele din procesul de analiza și deoarece aceasta este prima iterație putem crea o diagrama a claselor abstracta in figura 10.4 Procesul de proiectare. 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 9. Aceasta diagramă nu va reprezenta diagrama finală. 3. scoate se redefini unele componente clase. La fiecare iterație se pot adauga. Propagarea mesajului.

Pentru realizarea acestui proiect voi utiliza ca limbaj de programare Python. C++ și altele. in caz de depistare a botleneck-urilor componenta va putea fi rescrisa in alt limbaj ce poseda o platformă runtime mai rapidă precum C. Diagrama Claselor. . Figura 10. deoarece este simplu in utilizare și o buna baza pntru schițarea apliației.

Î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. Concluzie Pentru realizarea sarcinii propuse am studiat diferite metodologii de proiectare și analiza. Kim Hamilton [Resursă electronică] .org/wiki/Objectoriented_ analysis_and_design [Resursă electronică] http://en.org/wiki/Object-oriented_design [Resursă electronică] http://en. Fiecare metoda posedă plusuri și minusuri.0. 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.wikipedia. Bibliografie http://en. sau altele de acest gen.org/wiki/Distributed_file_system [Resursă electronică] Learning UML 2.wikipedia.wikipedia.

__parent = self def del_child(self. name): '''get child path object from name if not exist then None''' for ch in self.__class__ != Node: raise 'Not a node!!!' if self.__child: if ch. child): '''delete child path''' if child.__resources = {} def get_name(self): '''node name''' return self.path class Node(): def __init__(self.py ''' import os. Anexa A Codul Sursă **************************************** ''' Created on Sep 7.__class__ != Node: raise 'Not a node!!!' self.__child = [] self.__name def add_child(self.__child. name): self.__parent = None self.remove(child) def get_child(self.__name = name self.__child: if ch. child): '''add a child path''' if child.__child. 2009 @author: gheorghies unit fsclass.__name == name: return ch return None def child_exist(self.append(child) child.__child.__contains__(child): self.__name == name: return True return False . name): for ch in self.

__curent_dir = root self.__resources.__getport = getport def exec_comand(self.CommandParser() self.user_pass_dict.getport): self.root.__user_pass_dict = user_pass_dict self.py ''' import commandparser import sender class Sesion(): def __init__(self.__resources[name] def resource_exist(self.__child) + '\n' def lr(self): '''white space delimited resource names''' return ' '.__resources.__name for ch in self. name.has_key(name): return True return False def get_resource_file(self. name): '''delete resource''' del self.name): if self.isfile(path): self. path): '''add resource''' # check if file exist !!! if os.command): '''command --> Code + command''' .join(ch. name): '''check if resource with name 'name' exist''' if self.__resources[name] = path return True return False def delete_resource(self.__flaglogged = False self.__resources[name] def ln(self): '''white space delimited child names''' return ' '.path.__parent def add_resource(self.keys()) + '\n' ''' Created on Sep 7.join(rs for rs in self.def get_parent(self): return self.resource_exist(name): return self. 2009 @author: gheorghies unit sesion.__cmdparser = commandparser.

__flaglogged: if len(cmdtuple) != 4: return '0 Bad command\n' if cmdtuple[0] == 'usr' and cmdtuple[2] == 'pwd': if not self.get_child(cmdtuple[1]) return '1 OK\n' else: return '0 No such folder\n' elif cmdtuple[0] == 'lr': return self.__curent_dir.__curent_dir = self.__curent_dir.get_parent() != None: self.__curent_dir.__curent_dir.__getport.ln() #cd elif cmdtuple[0] == 'cd': if cmdtuple[1] == '.__curent_dir.__curent_dir.try: cmdtuple = self.getParams(command) except: return '0 Bad command\n' # if not cmdtuple: # return '0 Bad command\n' # logging if not self.__curent_dir.child_exist(cmdtuple[1]): self.__flaglogged = True return '1 OK\n' else: return '0 Bad command\n' #ls if cmdtuple[0] == 'ln': return self.': if self.__curent_dir = self.get_resource_file(cmdtuple[ .has_key(cmdtuple[1]) or not self.Sender(self.self.lr() #get elif cmdtuple[0] == 'get': if self.__user_pass_dict.resource_exist(cmdtuple[1]): snd = sender.get_parent() return '1 OK\n' else: return '0 Bad command\n' if self.__user_pass_dict[cmdtuple[1]] == cmdtuple[3]: return '0 Logon failed\n' else: self.__curent_dir.__cmdparser.

start() return str(self.1])) snd.__getport) + '\n' else: return '0 Bad command\n' else: return '0 Bad command\n' .