MODEL/DIZAIN STRUCTURAT

Designul structurat este procesul de a decide ce componente și interconexiunea

între aceleași, pentru a rezolva o problemă bine definită.

Odată ce au fost stabilite cerințele software-ului (în analiza),

designul software-ului este prima dintre cele trei activități tehnice: design, codare,
și testare. Fiecare activitate transformă informația într-un mod în care, în cele din urmă, se
obține un software valid pentru computer.

Designul structurat tinde să transforme dezvoltarea software-ului într-o

practică artisanală într-o disciplină de inginerie.

Eficiență
Mentenabilitate
Modificabilitate
Flexibilitate
Generalitate
Utilitate

PRINCIPII UTILIZATE DE DESIGNUL STRUCTURAT

Abstracție
Noțiunea psihologică de abstracție permite concentrarea asupra unei probleme la
același nivel de generalizare, indiferent de detaliile irelevante de
nivel scăzut. Utilizarea abstracției permite de asemenea să lucrăm cu concepte și
termeni care sunt familiari cu mediul problemei, fără a fi nevoie să-i transformăm
o structură nefamiliară.

Rafinare succesivă:
Arhitectura unui program se dezvoltă în niveluri successive de rafinare
de detalii procedurale. Se dezvoltă o ierarhie descompunând o
declarație macroscopică a unei funcții de o formă succesivă, până când se
ajunge la sentințele limbajului de programare.

Modularitate
Arhitectura implică modularitate, software-ul este împărțit în componente cu
nume și locații determinate, care se numesc module, și care se
se integrează pentru a satisface cerințele problemei.
Arhitectura software-ului:
Arhitectura software se referă la două caracteristici importante ale
software de computere
. [Link] ierarhică a componentelor procedurale (module)
. 2. structura de date

Ierarhia controlului:
Ierarhia de control, denumită și structură de program, reprezintă
organizația
(Frecvent ierarhică) a componentelor programului (module) și
implică o ierarhie de control. Nu reprezintă aspecte procedurale ale
software, cum ar fi secvențe de procese, sau repetarea operațiunilor.

Structura de date
Structura de date este o reprezentare a relației logice existente între
elementele individuale de date. Deoarece structura informației
va afecta în mod invariabil designul procedural final, structura de date este
la fel de importantă ca structura programului în reprezentarea
arhitectura software-ului.

COMPONENTE
Simboluri grafice; icoane și convenții pentru a identifica și descrie
componente ale unui sistem împreună cu relațiile dintre aceste componente.

• Dicționar de date; descrierile tuturor datelor utilizate în sistem.

• Descrieri ale proceselor și procedurilor; declarații formale care

folosesc tehnici și limbaje care permit analiștilor să descrie activități
importante care fac parte din sistem.

• Reguli;standarde pentru a descrie și a documenta sistemul în mod corect și

completează.

UNELTE
Diagrama de Flux de Date: Este este baza pentru alte componente și
descrie cum navighează datele între procese și elemente legate.

Dicționar de Date: Conține caracteristicile câmpurilor și/sau

descriere detaliată a diferitelor obiecte care compun sistemul

Diagrama de Structuri de Date: descrie relația între

entitățile și obiectele (conjunt de informații pe care le conțin
entități).
 TIPURI DE DESIGNE
•1. Designul datelor.
Transformă modelul de domeniu al informației creat structuri de date
pentru a implementa software-ul.

•2. Designul Interfeței.

software-ul comunică cu el însuși, cu sistemele care operează cu el și cu
operatorii care îi folosesc.

•3. Design Procedural.

Transforma elementele structurale ale programului într-o descriere
proceduri ale software-ului.

•4. Design arhitectural.

importanța designului software-ului rezidă în calitate. este singura modalitate de
traducerea cerințelor clientului pentru un sistem sau produs software.

CARACTERISTICI
Designul trebuie să implementeze toate cerințele conținute în modelul de
analiză și trebuie să se alinieze la toate cerințele implicite pe care le dorește
client
Designul trebuie să fie un ghid pe care să-l poată citi și înțelege cei care
construiesc codul și cei care testează și întrețin software-ul.
Designul ar trebui să ofere o idee completă despre ceea ce este software-ul,
focalizându-se pe domeniile de date, funcțional și de comportament de la
perspectiva implementării.
 Este procesul de a decide ce componente, și
interconexiunea dintre acestea, pentru
rezolva o problemă bine definită.

Abstracție
PRINCIPII Rafinament succesiv
UTILIZAT DE Modularitate
DESIGNUL Ierarhia controlului
STRUCTURAT * Structura de date

*Simboluri grafice

Dicționar de date
COMPONENȚE *Descrieri ale proceselor și
proceduri

*Reguli

MODEL/PROIECT *Diagrama de Structuri de

STRUCTURAT Date
UNELTE Dicționar de Date

Diagrama de Flux de Date:

1. Design de date.

TIPURI DE DESIGN 2. Designul Interfeței.

3. Design Procedural.
4. Proiectare arhitecturală.

CARACTERISTICI:
Trebuie implementa toate los requisitos
conținuturile în modelul de analiză și trebuie
acomodarea tuturor cerințelor implicite
ce dorește clientul
Trebuie să fie un ghid pe care să poată citi și înțelege
cei care construiesc codul și cei care testează și
mențin software-ul.
UNIVERSITATEA MEXIQUENSĂ A BICENTENARULUI.
UNITATEA DE STUDII SUPERIOARE TULTEPEC.
LIC. INFORMATICĂ ADMINISTRATIVĂ Ș I FINANCIARĂ.

MATERIA: SISTEME DE INFORMAȚII II

PROFESOR: REYES SANCHEZ DULCE MARIA.

INTEGRANȚI:

ARELLANO OLMEDO JOSE ELEUTERIO

FLORES RODRIGUEZ NANCY

GALLEGOS HERNANDEZ JANETH GUADALUPE

GONZALEZ MARTINEZ DIEGO ESTEBAN

MEJIA GARCIA ITZEL GABRIELA

SANCHEZ HERNANDEZ GLORIA DEL CARMEN

VAZQUEZ GALOMO GERMAN

VAZQUEZ ORTEGA ADRIAN

MODEL DE ORIENTARE PE OBIECTE (OO)

8/MAI/2016
 MODELU ORIENTAT PE OBIECTE (OO)
Conceptes ș i scopul modelului de structură a obiectelor

OSM este modelul fundamental care oferă un mediu uniform pentru modelare a
sistemul de la capturarea cerințelor în etapa inițială a analizei până la
implementare, traversând întreg ciclul de dezvoltare a sistemului.

Modelul orientat pe obiecte utilizează paradigma orientării pe obiecte pentru

dezvoltarea software-ului. Această abordare realizează construirea de modele ale unui
sistem prin identificarea și specificarea unui set de obiecte
relacionate, care colaborează între ele conform cerințelor stabilite
pentru sistemul de obiecte.

Definiția modelării orientate pe obiect poate să împartă clar abordarea.

în trei dimensiuni:

• Dimensiunea structurală.
• Dimensiunea dinamică.
• La demisie funcțională.

Acest tip de modelare implică realizarea următoarelor activități:

1. Identifică clasele, modelele și obiectele. (obiecte și atribute).

2. A asocia static obiectele. (relații dependente de domeniu)
problema).
3. Specificarea comportamentului obiectelor. (Definiți cum se
se vor comporta obiectele).
4. Definirea ierarhiei de moștenire a claselor. (Definirea ierarhiei de clase,
pentru ca sistemul să rămână cât mai abstract posibil).

Complementații:

5. Clasele de obiecte din aplicație

6. Cum sunt asociate clasele de obiecte între ele
7. Cum comunică obiectele.
8. Detalii despre fiecare clasă de obiecte, inclusiv atributele și operațiile.

În timpul procesului de analiză și design, OSM este definit în niveluri succesive.

incrementale de detaliu, până când nivelul necesar pentru implementare este
atins
Toate celelalte modele captează detalii care hrănesc acest model.

Dezvoltarea OSM este un proces aditiv, diferențiindu-se de această abordare

transformațional caracteristic altor metode precum structurat, unde
DFD-ul analizei este transformat în diagrame de structură în timpul proiectării,
cu problemele corespunzătoare pe care le aduce.

În timpul ciclului de dezvoltare se aduc următoarele elemente în model:

Analiza Afacerii: se recunosc obiecte cheie ale afacerii ș i generează

abstracții în clasele potrivite (obiecte entitate).

Analiza cerinț elor: se identifică asocieri structurale între

obiecte și clase noi (entitate).

Design logic: Se încorporează toate clasele necesare pentru aplicaț ie

includând obiectele de interfață și de control.

Proiectare Fizică: se încorporează toate detaliile rămase pentru

implementarea fizică a fiecărei clase de obiecte.

Caracteristicile modelelor orientate pe obiect.

• Modelarea orientată pe obiect este bazată pe paradigma orientată la
obiecte.
• Tratează stocarea obiectelor (persistența obiectelor).
• Definiți un limbaj pentru definirea și manipularea obiectelor.
• Includează mecanisme pentru optimizarea accesului (Indexare și Clustering),
controlul concurenței, securitate și gestionarea utilizatorilor, ușurință de
consulta și recuperare în caz de erori.
• Datorită faptului că este un schelet orientat pe obiecte, include: Încapsulare,
moștenire, polimorfism, etc.
Componente ale modelului de structură a obiectelor.

Componente de bază al OSM este clasa de obiecte.

Se deosebesc trei tipuri de clase:

Obiecte Entitate
Obiecte de Interfață
Obiecte de Control.

Pentru fiecare clasă identificată se descriu:

· Operațiuni
Atribute
Restricții

În plus, OSM descrie asocierile între obiecte sau clase de

obiecte. Se disting următoarele tipuri de asociații:
Relații Statice
Moștenire
Agregare
Comunicare prin mesaje

Obiecte entitate

Reprezintă ceva real sau abstract despre care sistemul trebuie să stocheze.
date. Reprezintă memoria esențială a afacerii. Obiectele afacerii
(obiecte de afaceri) sunt de obicei obiecte entitate. Exemple de obiecte entitate
pot fi angajat, student, etc.
:

Obiecte Interfaț ă

Reprezentan obiectele tehnice necesare pentru a conecta aplicația cu

mediu. Reprezintă legătura prin care sistemul primește sau furnizează
date și informație în mediu. De obicei includ interfețe cu utilizatorul.

Obiecte de control

Conțin comportamente care nu aparțin natural nici obiectelor entitate nici

de interfață. Sunt de obicei obiecte tranzitorii, cum ar fi un controler de
rapoarte.
Clase abstracte ș i concrete

O clasă din care pot fi generate instanțe particulare (obiecte), se

denomina clase concretă.

O clasă abstractă este cea care nu are instanțe (obiecte) proprii. Clasele
abstractele sunt un mecanism conceptual puternic pentru a defini structuri
atribute comune, operațiuni și restricții, reutilizate prin intermediul
moștenire prin clase multiple concrete.

În diagrama de structură a obiectelor, o clasă abstractă este reprezentată cu un

rectangle punctat.

Model Dinamic.
Modelul dinamic se bazează și este constituit din acele aspecte ale unui sistem
relacionate cu timpul (obiecte și schimbarea lor) de-a lungul timpului.
Modelul dinamic descrie controlul sistemului, asta vrea să spună că,
secvențe care apar ca urmare a utilizării de către utilizatorii finali, fără
ține cont de ceea ce fac operațiile asupra a ce operează și cum se
implementează. Așa cum se întâmplă în modelul orientat pe obiecte, obiectele se
comunică între ei prin intermediul transmiterii de mesaje (parametrii), la această acțiune
modelul dinamic se numește interacțiune între obiecte.

Desgrămările de stat, interacțiune (secvență, comunicare, tempo și viziune)

de ansamblu) sunt utilizate pentru a descrie cum interacționează obiectele
dinamic. Modelul dinamic este constituit în principal din
diagrame de stare și de activitate, urmează să se prezinte principalele
caracteristicile casei unu dintre ele:

• Diagrama de Stare: Acest tip de diagramă indică în ce mod se

comportamentul obiectelor pe parcursul ciclului lor de viață, definește comportamentul
del sistem complet.

Caracteristici ale diagramelor de stare:

Principalele concepte ale unui diagramă de stare sunt:
evenimentele stările. O stare este o valoare a atributelor de
objete.
Modelul dinamic constă în multiple diagrame de stare ș i
afișează modelul de activitate pentru sistemul complet.
 Acest tip de diagrame con ț ine tranzi ț ii care sunt rela ț iile
între obiecte și evenimentele care au loc între ele.
• Diagrama de activitate: Sunt folosite pentru a specifica fluxul de lucru
în cadrul sistemului, spre deosebire de diagrama de secvență, diagrama de
activitatea nu modelează comportamentul unui sistem de software, ci pe altele
procesele și fluxurile la un nivel foarte înalt. Diagrama de activitate definește
următoarele caracteristici:
oProcesul de afaceri: Folosit pentru a defini cum se schimbă obiectele
pentru a defini o viziune de înalt nivel.
oCartas de state: Captura schimbările sistemului de-a lungul
timp.

În rezumat, UML conține uneltele necesare pentru definiția

model dinamic al sistemelor de software prin diverse instrumente care
ajută la definirea comportamentului sistemului de-a lungul timpului. Fiecare
tipul de diagramă ajută la capturarea informațiilor sistemelor ca un întreg
cu toate detaliile acestuia prin diagrame care definesc
comportament

Model Funcț ional.

Modelul funcțional reprezintă toți factorii esențiali ai dezvoltării
software ignorând pe cei care fac parte din detaliile mai specifice ale
sistem. Acest model pleacă de la un scop general bine definit și de
maniera cea mai simplificată posibilă.

Dintr-o perspectivă mai generală, modelul funcțional se leagă de

modelul orientat pe obiecte, acest model se relaționează cu o entitate existentă.
Acest model are trei principii fundamentale:

• Partiționare
• Abstracție
• Proiecție

Acest model se bazează pe concepte de funcții sau procese, astfel încât

acestea devin cel mai important element al acestei abordări. Acest model
descrie calculele din cadrul sistemului, adică ceea ce se întâmplă. Înțelege
următoarele tipuri de funcții:

• Funcție asincronă: O funcție asincronă poate fi activată de alta

obiect sau funcție pentru a efectua o acțiune.
• Funcție asincronă dependentă de un stadiu: Un asincron dependent
din stat este în general o funcție „one-shot” de acțiune, care se
 se execută durante o tranziție de la un stat la alt stat. Această funcție se
activează printr-o transformare de control
• Funcție periodică: O funcție periodică se activează la intervale regulate
pentru a realiza o acțiune. Frecvența cu care se activează o funcție
specifică depinde de aplicație
• Funcție periodică dependentă de un stadiu: O funcție periodică se
active la intervale regulate pentru a realiza o acțiune. Frecvența cu
activarea unei funcții specifice depinde de aplicație. Aceasta
funcția se activează printr-o transformare de control

Un exemplu de programe care utilizează acest tip de modelare poate fi

compilatoare, deoarece în general acest tip de programe efectuează calcule de
operațiile pe care un sistem trebuie să le efectueze. Pe de altă parte, bazele de
datele au adesea un model funcțional trivial, deoarece scopul lor este
a stoca și a organiza datele, nu a le transforma.

Metodologia OOHDM
Este o metodologie orientată pe obiecte care cuprinde 5 faze:

[Link]ținerea cerințelor.
[Link] conceptual.
[Link] navigațional.
[Link] interfetei abstracte.
5. Implementare.

Faza 1 (obținerea cerințelor): Instrumentul pe care se bazează

această fază sunt diagrama de cazuri de utilizare, care sunt proiectate de
scenarii cu scopul de a obține în mod clar cerințele și
acțiuni ale sistemului.

Faza 2 (Modelul conceptual): Se construiește un model orientat pe obiecte care

reprezentați domeniul aplicației folosind tehnicile proprii de
orientare către obiecte.

Faza 3 (Design navigațional): Structura de navigare a unei aplicații

hipermedia este definită printr-un schelet de clase de navigare specifică, care
reflectă o posibilă vedere aleasă.

Faza 4 (designul interfeței abstracte): În această fază se definesc ce obiecte de

interfața va fi percepută de utilizator, calea pe care vor apărea diferitele
obiecte de navigație, ce obiect de interfață va acționa în navigație, forma
de sincronizare a obiectelor multimedia și a interfeței de transformări.
Faza 5 (Implementare): Odată ce cele 4 faze anterioare au fost îndeplinite, rămâne doar
a duce obiectele la un limbaj concret de programare.

SOHDM

Propune un proces pentru modelul conceptual al sistemului, care este reprezentat

printr-un diagramă de clase. Procesul SOHDM continuă să regroupeze
aceste clase pentru a obține un model de clase navigaționale ale sistemului.
Consistă în șase faze: analiza domeniului, modelarea obiectului, proiectarea
viziune, designul navigației, designul implementării și construcției.
Această metodologie are asemănări cu, OOHDM și EORM unde se deosebesc
în utilizarea panoramelor, care descriu activitățile în evenimentele și
primitivă a fluxurilor de activități. Panoramele sunt definite în faza de
analiză și sunt utilizate pentru a modela obiectele

RUP

Procesul Unificat Rațional constă într-un proces de dezvoltare a software-ului

împreună cu Limbajul Unificat de Modelare (UML), acest proces constituie
metodologia standard cea mai utilizată pentru analiza, implementarea și
documentația sistemelor orientate pe obiect. Acest model are 4 faze
principale:

Început: Se face un plan de faze, unde se identifică principalele cazuri de utilizare

şi se identifică riscurile. Se concretizează ideea, viziunea produsului, cum se
Încadrarea în sistem, domeniul de aplicare al proiectului. Elaborare: Se realizează planul
ce va urma proiectul de software, unde sunt luate în considerare toate cazurile de utilizare
de sistem. Construcție: Se realizează un produs complet funcțional și se
elaborarea manualului de utilizare, este în această etapă unde se definește arhitectura
proiect. Tranziție: Proiectul este implementat, în această fază se formează
utilizatori cum trebuie să utilizeze produsul, în această fază proiectul trece de la
dezvoltator utilizatorului (tranziție).

UML

Limbajul de modelare unificat este o specificație de notare orientată la

obiecte, care se compun din diferite diagrame, care reprezintă
etape diferite ale dezvoltării proiectului. UML nu preconizează un proces sau
metoda standard pentru a dezvolta un sistem, adică nu specifică una singură
forma de a realiza o operațiune, ci oferă uneltele necesare pentru
definirea, crearea și modelarea diferitelor etape ale unui proiect printr-o serie de
diagrame. Există mai multe metodologii existente; printre cele mai populare se
includ următoarele:
Cataliza: O metodă orientată pe obiecte care fuzionează o mare parte din lucrările recente
în metode orientate pe obiecte și, de asemenea, oferă tehnici specifice pentru
modelarea componentelor distribuite.

Objetory: O metodă de caz de utilizare ghidată pentru dezvoltare, creată de Ivar

Jacobson.

Shlaer/Mellor: Metoda de proiectare a sistemelor în timp real.

Fuzionare: Dezvoltat la Hewlett Packard la mijlocul anilor '90 ca prim

încercarea unei metode de proiectare orientată pe obiecte standard.
OMT: Tehnica de Modelare a Obiectelor a fost dezvoltată de James Rumbaugh
și altele, și publicată în cartea de mare influență. O metodă care propune analiza
și design ‚iterativ’, mai axat pe partea de analiză.

Modelarea cazurilor de utilizare

Un caz de utilizare este modelat pentru toate procesele pe care sistemul trebuie să le realizeze.
cabo. Procesele sunt descrise în cadrul cazului de utilizare printr-o descriere
textual sau o secvență de pași executați. Odată ce comportamentul
sistemul este captat în acest fel, cazurile de utilizare sunt examinate și extinse
pentru a arăta ce obiecte se interrelaționează pentru ca acest comportament să apară.
Cazurile de utilizare sunt cea mai eficientă și ușoară modalitate de a modela cerințele unui
utilizator din punctul de vedere al acestuia. Cazurile de utilizare sunt instrumentul care
descriu cum ar trebui să funcționeze un sistem sau cum s-ar dori să funcționeze. Nu
este realmente o aproximare la orientare către obiecte; este realmente o formă
de modelare a proceselor. Cazurile de utilizare sunt, în general, punctul de plecare al
analiza orientată pe obiecte cu UML.

Booch: Asemănător cu OMT cu caracteristici suplimentare.

 MODELARE ORIENTATĂ PE OBIECTE

MODEL DEFINIȚIE CARACTERISTICI

Orientat pe Obiecte Această abordare utilizează clase, asociază

construcția de modele obiecte definiți una
de un sistem prin intermediul ierarhiei de cazuri.
de la identificare și utilizează paradigma OO:
specificația de clase, obiecte, moștenire
set de obiecte polimorfism,
relacionate ce înseamnă încapsularea, etc.
colaborează între ei de
acord a los
cerințe
established para el
sistem de obiecte.
Model dinamic. Modelul dinamic este Diagrama de stare:
bazat și constituit în definește modul în care
acele aspecte în care se comportă obiectele.
sistem legate de Diagrame de activitate:
timpul (obiecte și Specifică fluxul de
schimbarea acestora) la muncă înăuntru del
de-a lungul timpului. sistemul.
Model Funcțional Modelul funcțional se bazează pe trei
reprezintă toate principiile:
factori esențiali ai partiționării
dezvoltarea software-ului abstracție, proiecție.
ignorând pe cei care este bazat pe
fac parte din conceptele funcțiilor sau
detalii mai specifice procese (fiind acestea
de sistem. Acest model este cel mai important element
parte a unui scop al abordării)
general bine specificat
y de la manera más
simplificată posibil
Metoda Booch consideră că etapele procesului într-o dezvoltare
orientate spre obiecte sunt:

Identificarea cheilor și obiectelor la un anumit nivel de abstracție

Identificarea semantinei acestor clase și obiecte
Identificarea relațiilor dintre clase și obiecte
Specificați interfața și implementarea acestor clase și obiecte

Aceste etape sunt de obicei urmate de majoritatea metodelor de design OO

existente. De fapt, pentru sistemele orientate pe obiect se definește următorul
design în piramidă care ia în considerare metoda Booch.

La capa a subsistemului.-Conține o reprezentare a fiecăruia dintre

subsixteme care permit software-ului să îndeplinească cerințele definite de
client și implementa infrastructura tehnică care le susține.
La capa de clase și Obiecte.-Conține ierarhiile clasei care permit
creați sistemul folosind generalizări și specializări mai bine definite.
Această copertă conține, de asemenea, reprezentări de design pentru fiecare obiect.

La capa de mesaje.-Con ț ine detaliile care îi permit fiecărui obiect

a comunica cu colaboratorii săi. Această strat stabilește interfețele externe și
interni pentru sistem.

La capa de responsabilităților.-Conține structurile de date și designul

algoritmic pentru toate atributele și operațiile fiecărui obiect.
Această piramidă de design se concentrează atunci pe proiectarea unui produs sau sistem
specific

Abordarea conven ț ională ș i abordarea OOP

Abordările convenționale pentru proiectarea software-ului aplică notații și
heuristici diferite pentru a stabili corespondențe între modelul de
analiza și designul. Dacă ne amintim de ingineria software-ului clasic (imperativă),
veremos că fiecare element al modelului de analiză convențional are
corespondența cu una sau mai multe straturi ale modelului de design așa cum il ilustrează
următoarea figură:

Modelul de Analiză
Arhitectura designului OO se concentrează mai mult pe colaborările între
obiecte care cu fluxul de control al datelor. În acest mod, straturile de
piramidele sunt renumite pentru a reflecta mai exact natura DOO.
Figura următoare arată acum corespondența dintre AOO cu ...
straturile corespunzătoare ale piramidei de design OO.
 UES TULTEPEC

PROFESOARA: DULCE MARIA REYES

DEZVOLTARE DE SOFTWARE PE BAZA DE

COMPONENTE

SISTEME DE INFORMARE
INTEGRANȚ I:
GARCIA LONGINOS JESSICA ELENA
LINARES ROMERO EMILIA DEL ROSARIO
MENDOZA RODRIGUEZ ADRIAN
OCHOA DAGDUG JAQUELINE
MOLINA RUIZ CAROLINA
VARGAZ HERNANDEZ LEONARDO
SERRATO AGUILAR VIRIDIANA
VENTURA RODRIGUEZ CARLOS EDUARDO

GRUP: 28LF261

DEZVOLTARE DE SOFTWARE PE BAZA DE COMPONENTE

 DEZVOLTARE DE SOFTWARE PE BAZA DE COMPONENTE

Obiective

Dezvoltarea bazată pe componente este o aplicare a tehnicii; împărț ire ș i cucerire, pentru
a gestiona complexitatea. Principala diferenț ă faț ă de metodele structurate în principal
că analiza ș i designul sunt realizate în cadrul aceluiaș i paradigm decât implementarea. Aceasta
implementarea este relegată la un plan secundar, fiind important să oferim o soluț ie logică la
problema, anterior codificării sale. Acest principiu a fost utilizat în paradigma de orientare către
obiecte, faptul de a combina operaț iuni ș i informaț ii într-o aceeaș i unitate ș i de a dispune de
tehnici de modelare în cadrul aceluiaș i paradigmă, a făcut ca orientarea spre obiect să aibă un
succes important.

OBIECTIVELE PRINCIPALE

1. A ob ț ine reutilizarea (acest fapt este admirabil dar nu este u ș or de realizat).

2. Căuta ț i înlocuirea u ș oară. (Aceasta implică o nouă implementare a componentei pentru

care poate fi utilizată în locul implementării anterioare fără a afecta func ț ionarea
del resto de los componentes.)

COMPONENTE

Un component este o unitate de compunere a aplicaț iilor software, care deț ine un set
de
interfeț e ș i un set de cerinț e, ș i care trebuie să poată fi dezvoltat, achiziț ionat, incorporat
al sistemă ș i compusă cu alte componente în mod independent, în timp ș i spaț iu

DEZVOLTARE DE SOFTWARE PE BAZA DE COMPONENTE

Caracteristici ale unui Component

Identificabil: Trebuie să aibă o identificare care să permită accesul uș or la serviciile sale.

permite clasificarea.
Continut auto: Un component nu trebuie să necesite utilizarea altora pentru a fi finalizat.
funcț ia pentru care a fost proiectat.
Poate fi înlocuit cu un alt component: Poate fi înlocuit cu versiuni noi sau altul
componente care să-l înlocuiască ș i să-l îmbunătăț ească.

Cu acces doar prin intermediul interfeț ei sale: Trebuie să te asiguri că acestea nu se vor schimba pe parcurs.

de implementarea sa.
Serviciile sale nu variază: Funcț ionalităț ile oferite în interfata sa nu trebuie să varieze, dar aceasta
implementare da.
Bine Documentat: Un component trebuie să fie corect documentat pentru a facilita
cercetare dacă se doreș te actualizarea, integrarea cu altele, adaptarea, etc.
Este generic: Serviciile sale trebuie să fie utile pentru mai multe aplicaț ii.

Reutilizat dinamic: Poate fi încărcat la timpul de execuț ie într-o aplicaț ie.

Indiferent de platformă: hardware, software, S.O.

LA INTERFAZA UNUI COMPONENT

O interfaț ă defineș te setul de operaț iuni pe care un component poate să le efectueze; aceste
operatiunile sunt numite de asemenea servicii sau responsabilităț i. Interfeț ele oferă un
mecanism pentru interconectarea componentelor ș i controlul dependenț elor dintre ele.
Natura interfeț ei variază în funcț ie de limbajul de programare utilizat pentru
implementează componenta.
În general, o interfaț ă de programare a aplicaț iilor (API, Application Programming)
Interfaț a) este o specificaț ie, într-un limbaj de programare, a proprietăț ilor unui
modul de software. Clienț ii modulului trebuie să depindă exclusiv de
proprietăț i definite de API într-un mod explicit.

Există două tipuri de interfeț e:

1. interfaț a de afaceri: care reflectă rolul componentului în sistem.

DEZVOLTARE DE SOFTWARE PE BAZA DE COMPONENTE

2. interfata de infrastructura: este impusa de modelul de componente pentru a-i permite
interacț iona cu componenta.
Pe de altă parte, se observă că interfeț ele convenț ionale definesc semnătura operaț iunilor
(numele operaț iei, tipul ș i ordinea argumentelor, ș i modul în care se returnează
rezultate) care oferă un component. Operaț iile sunt cunoscute ș i sub denumirea de Proprietăț i
Funcț ionale. Cu toate acestea, aceste interfeț e nu exprimă în mod adecvat proprietăț i ale
componente relative la, de exemplu, performanț a, precizia, disponibilitatea, latenț a,
securitate, printre altele. Aceste proprietăț i sunt cunoscute sub numele de Proprietăț i Extrafuncț ionale

Este util să diferentiem tipurile de proprietăț i ale componentelor. De exemplu, Beugnard et al.
[25] define patru tipuri de proprietăț i legate de:
[Link]: corespund proprietăț ilor funcț ionale exprimate explicit prin intermediul
interfaț a componentului.
[Link]: definesc condiț iile care trebuie să fie îndeplinite de valorile de intrare
(precondiț ii) ș i ieș ire (postcondiț ii) ale operaț iunilor.
[Link]: exprimă aspecte de concurenț ă.
4. Calitatea Serviciului: cuprinde atribute precum timpul de răspuns, utilizarea memoriei,
precizie, fiabilitate, uș urinț ă în întreț inere ș i reutilizare, printre altele.

DEZVOLTAREA DE SOFTWARE PE BAZA DE COMPONENTE

Paradigma de a asambla componente ș i a scrie cod pentru a face ca aceste componente

funcț iile sunt cunoscute sub numele de Dezvoltare de Software Bazată pe Componente.

Dezvoltarea de software bazat pe componente permite reutilizarea pieselor de cod pre

elaborate care permit realizarea diverselor sarcini, aducând cu sine diverse beneficii precum
îmbunătăț iri ale calităț ii, reducerea ciclului de dezvoltare ș i un randament mai mare asupra investiț iei.

Un component de software poate fi văzut din două perspective distincte, cum ar fi:

1. implementare: componentele pot fi asamblate ș i desfăș urate pentru a crea sisteme ș i

aplicaț ii care rulează pe un calculator.

DEZVOLTARE DE SOFTWARE BAZATĂ PE COMPONENTE

2. abstractizarea arhitecturii: componentele exprimă regulile de design impuse de

model de componente.

CARACTERISTICELE DEZVOLTĂRII PE BAZA COMPONENTELOR

Modelul de dezvoltare bazat pe componente încorporează multe dintre caracteristicile

model în spirală.

Pentru asta trebuie să ne amintim că un model în spirală se dezvoltă într-o serie de versiuni
incrementale. Se împarte în mai multe activităț i de cadru numite de asemenea
regiuni de sarcini care sunt:

Comunicaț ie cu clientul

2_. Planificare

3_. Analiza riscurilor

Inginerie

Evaluarea clientului

6_. Construire ș i livrare

Cu toate acestea, modelul de dezvoltare bazat pe componente configurează aplicaț ii de la

componente pregătite de software (numite „clase”).

Activitatea ingineriei începe cu identificarea claselor candidate. Acest lucru se realizează

examinând datele care urmează să fie gestionate de aplicaț ie ș i algoritmul care se
va aplica pentru a obț ine tratamentul. Datele ș i algoritmii corespunzători se
sunt ambalate într-o clasă.
Clasele create în proiectele de inginerie software anterioare sunt stocate într-o
biblioteca de clase sau dicț ionar de date.
Odată ce sunt identificate clasele candidate, biblioteca de clase este examinată pentru a determina dacă
Aceste clase există deja. În cazul în care ar fi aș a, se extrag din bibliotecă ș i sunt reutilizate.
Dacă o clasă candidată nu reș ede în bibliotecă, se aplică metodele orientate pe obiect.

DEZVOLTARE DE SOFTWARE BAZAT PE COMPONENTE

Se compune astfel prima iteraț ie a aplicaț iei care urmează să fie construită, prin clasele extrase d
e
biblioteca ș i noile clase construite pentru a îndeplini nevoile unice ale aplicaț iei
.
Fluxul procesului revine la spirală ș i va reintroduce în cele din urmă iteraț ia asamblorului
a de componente prin activitatea de inginerie

ARHITECTURĂ

Termenul 'arhitectură' este moș tenit din alte discipline ale ș tiinț ei. Se înț elege prin
arhitectură a unui ansamblu de piese de diferite tipuri, care se potrivesc între ele ș i îndeplinesc o
funcț ie determinată. Arhitectura prezintă de asemenea impactul schimbării uneia dintre
piese. În cadrul paradigmei componentelor, piesele (sau blocurile de construcț ie) sunt
componente. Arhitectura componentelor va spune cu ce tipuri de componente ș i în ce
relaț ia de dependenț ă se găsesc. Aș a cum a fost menț ionat anterior, metodologia aici
propunerea caută să utilizeze paradigma componentelor în sisteme enterprise de mari dimensiuni.
Pentru aceasta, considerăm arhitecturi distribuite, pe mai multe niveluri, care incorporază surse de
date heterogene, sisteme legate ș i pachete din comerț . Stilul arhitectural în straturi
este aplicabil acestui tip de sisteme. Fiecare strat sugerează un tip diferit de componente ș i indică
rolul pe care îl joacă componentele care rezidă în ea

Abordarea metodologică se concentrează pe acele straturi care reprezintă funcț ionalităț ile
sistem, adică, stratul de Servicii al Sistemului ș i stratul de Servicii al Afacerii. La
definiț ia arhitecturii de componente acoperă aspecte doar logice ș i este totală
independent de tehnologia cu care vor fi implementate componentele ș i pe care se
va realiza implementarea sistemului. Această vedere logică ne permite să măsurăm nivelul de cuplaj al
sistemă ș i a raț iona despre efectele modificării sau înlocuirii unui component. Independenț a
tehnologia ne permite să ne abatem de la tehnicismul acestora, precum ș i să alegem cea mai potrivită

DEZVOLTARE DE SOFTWARE BAZAT PE COMPONENTE

în funcț ie de sistemul care se dezvoltă

BENEFICII.

1. Reutilizarea software-ului. Ne conduce la atingerea unui nivel mai mare de reutilizare a software-ului.

re.
2. Simplifică testele. Permite ca testele să fie executate testând fiecare dintre ele.
componentele înainte de a testa setul complet de componente asamblate.
3. Simplifică întreț inerea sistemului. Când există o legătură slabă între
componente, dezvoltatorul este liber să actualizeze ș i/sau să adauge componente după cum este
necesar, fără a afecta alte părț i ale sistemului.
4. Calitate mai bună. Deoarece un component poate fi construit ș i apoi îmbunătăț it
continuu de către un expert sau o organizaț ie, calitatea unei aplicaț ii bazate pe
componente se va îmbunătăț i odată cu trecerea timpului.

DEZVOLTARE DE SOFTWARE PE BAZA DE COMPONENTE

 ETAPELE MODELULUI BAZAT PE COMPONENTE

Se realizează studiul proceselor de

dezvoltare bazată pe componente, în
1.- Analiza ș i compararea proceselor în special cei care folosesc tehnici de
Dezvoltarea Software-ului Bazat pe Componente. modelare. Cu extensii specifice
pentru componente, în scopul de a defini
adaptări ș i/sau extensii
aproape de cele same

În această etapă se realizează studiul ș i comparaț ia diferitelor

stiluri ș i modele arhitecturale, analizând avantaje ș i dezavantaje
de utilizarea pentru dezvoltarea acestui tip de sisteme, precum ș i
2.- Analiză arhitecturală de arhitecturi existente ș i standarde cele mai utilizate în
actualitate.

Această etapă cuprinde identificarea interfeț elor de

sistem, de interfeț e ale afacerii, identificarea de
componente ș i descrierea iniț ială a
3.- Identificarea componentelor
specificaț iile componentelor, precum ș i
specificaț ia arhitecturii iniț iale a componentelor.

Se va lucra la specificarea de
interfeț e ș i componente, definind
4.- Specificaț ia principalelor componente Contracte de utilizare ș i Contracte de
realizare. Se efectuează în această etapă,
Modele de informaț ii pentru interfeț e.

DEZVOLTARE DE SOFTWARE PE BAZA DE COMPONENTE