Curs ISC 2011 1 v01

UPB - ETTI - Curs ISC - an IV - Specializarea RST 07.03.
2011 11:32 1
Inginerie Software pentru Comunicatii
(ISC / RST)
2010 - 2011
UPB - Facultatea ETTI - Curs ISC - an IV Specializarea RST
Titular curs: Eduard-Cristian Popovici
Suport curs: http://discipline.elcom.pub.ro/isc/
Moodle: http://electronica.curs.ncit.pub.ro/
UPB - ETTI - Curs ISC - an IV - Specializarea RST 07.03.2011 11:32 2
Structura cursului
UPB - Facultatea ETTI - Curs ISC - an IV Specializarea RST
Continut curs
Structura cursului
1. Introducere in ingineria software
1.1. Necesitatea unei abordari sistematice a dezvoltarii software
1.2. Abordari si metodologii larg utilizate in ingineria software
2. Introducere in limbajul UML
2.1. Definirea, rolul si istoricul limbajului de modelare unificat (UML)
2.2. Tipuri de diagrame UML. Organizarea ierarhica a diagramelor
3. Diagrame UML statice
3.1. Diagrame UML de clase
3.2. Diagrame UML de obiecte
3.3. Diagrame UML de pachete
3.4. Diagrame UML de componente
3.5. Diagrame UML de structuri compozite
3.6. Diagrame UML de deployment (amplasare)
Continut curs
Structura cursului
4. Diagrame UML dinamice
4.1. Diagramele UML de caz de utilizare
4.2. Diagrame UML de comunicatie si de robustete
4.3. Diagrame UML de secventa si de sumar al interactiunilor
4.4. Diagrame UML de masini de stari
4.5. Diagrame UML de activitati
4.6. Diagrame UML de timp
5. Introducere in procesul de dezvoltare Rational unificat (RUP)
5.1. Organizarea iterativa a proiectelor
5.2. Fazele si activitatile procesului RUP

6. Introducere in managementul si organizarea proceselor de dezvoltare

7. Elemente de reutilizabilitate a software-ului. Pattern-uri de proiectare
Continut laborator
Structura disciplinei
1. Dezvoltarea aplicatiilor Java si ingineria inversa UML in NetBeans IDE
2. Crearea diagramelor UML de clase si cazuri de utilizare in NetBeans IDE
3. Crearea diagramelor UML de comunicatie si secventa (MSC) in NetBeans
IDE
4. Crearea diagramelor UML de activitati in NetBeans IDE
5. Crearea diagramelor UML de masini de stari (FSM) in NetBeans IDE.
Predarea temelor de casa. Colocviu de laborator
Mod de evaluare
Organizarea disciplinei
1. Verificare finala partea de Inginerie Software (30 puncte)
2. Verificare partiala partea de Baze de Date (30 puncte)
3. Laborator (15 puncte) se noteaza prezenta + activitate laborator + teme
documentare
4. Proiect (25 puncte)
se noteaza predare proiect (dosar + format electronic pe CD/mail)
si sustinere proiect
5. Prezenta curs (5 + 5 puncte bonus)
Organizarea disciplinei
Laborator ISC Sala B123
1.1. Necesitatea unei abordari sistematice a dezvoltarii software
1.2. Abordari si metodologii larg utilizate in ingineria software
Structura cursului
Sisteme software (programe de calcul)
Sistemele software (programele de calcul)
Pentru a oferi servicii software utilizatorilor concureaza
sistemul hardware (masina de calcul) si
sistemele software (programele de calcul) de pe masina de calcul

Sistemul software (programul de calcul) este
o secventa de instruciuni (pasi)
care conduc aciunea unei maini programabile (de calcul)
din perspectiva programatorului:
o solutie la o problema pe care o are de rezolvat
din perspectiva utilizatorului:
un serviciu oferit
Sistemul software
pentru programator: o solutie la problema pe care o are de rezolvat

y
2
=1 - x

Problema la nivel conceptual

Analiza
(abstractizare)

daca patratul unui numar este
egal cu diferenta dintre 1 si un
al doilea numar, sa se afle cum
depinde primul numar de al doilea
Problema reala

Domeniul (contextul): matematica

Analist

Utilizator (client)

Cerinte

Enunt

Sistemul software

y
2
=1 - x

Solutia la nivel conceptual


Analist

Analiza

Proiectare
(design)

x<1 =>y = (1-x)
x>1 =>impossible

Proiectant

abstractii

Sistemul software

if (x > 1) {
cout << "impossible" << endl;
} else {
y = sqrt(1-x);
cout << "y is " << y << endl;
}

y
2
=1 - x

Solutia la nivel conceptual


Solutia translatata in limbaj de programare

Programator

transformarea
conceptelor in pasi

Analiza

Proiectare

Programare
(codare si depanare)

I nside the box

x<1 =>y = (1-x)
x>1 =>impossible

Program

Sistemul software
pentru utilizator: un serviciu oferit

if (x > 1) {
cout << "impossible" << endl;
} else {
y = sqrt(1-x);
cout << "y is " << y << endl;
}

Utilizator

Program in limbaj de programare

Serviciu oferit prin interfata
ca urmare a executiei

2B 34 6F FE
24 4C 66 8A
B3 E2 78 9A
CD B1 85 32
99 04 71 00
00 00 00 00
> equation.exe 0
y is 1
> equation.exe 2
impossible
>

cod executabil

compilare (translatie)

proces (program

in executie)

Black Box
(abstractizari)
care are intrari
(linie comanda)
si ofera iesiri
(rezultatele
afisarii)

Outside the box
(lumea reala)

Sistemul software
Black Box
(incapsulare, abstractizare)
White / Glass Box
se vad doar intrarile, iesirile, si
efectele colaterale
(serviciile furnizate, interfetele
oferite si necesare)
se vad si componentele, si
interactiunile dintre ele
(detaliile de implementare)

dezvoltare (analiza,
proiectare, implementare)
utilizare
(cerinte)
Inginerie software
Un sistem software este construit
- ntr-o structur organizatoric denumita
- proiect software

Un proiect software este de succes daca furnizeaz
- produsul planificat (sistemul software)
- n timpul i
- bugetul planificat i
- indeplinind cerinele planificate
- funcionale i
- de calitate
Ingineria sistemelor software
Ingineria software reprezinta
- aplicarea unei abordri ingineresti, adica
- sistematice,
- organizate,
- disciplinate si
- cuantificabile
- in desfasurarea proiectelor software (dezvoltare, utilizare, ntreinere)
- pentru finalizarea lor cu succes

Dincolo de dezvoltarea clasica a sistemelor software, ingineria software actuala
presupune
- aplicarea unei abordri industriale a productiei software
Natura industriala a ingineriei software contemporane
- conduce la o alta definitie a ei

Ingineria software inseamna
- dezvoltarea unor sisteme software in general mari
- pentru a fi utilizate in medii / linii de productie
- dezvoltare realizata pe perioade in general mari
- fiind implicate in general de echipe de oameni
- si care probabil vor necesita multe schimbari
Aceasta abordare se bazeaza pe
metode, unelte (instrumente) si tehnici
create cu scopul cresterii sanselor de succes ale proiectelor software

In acest context ingineria software include, printre altele:
metodele de programare moderne (OOP, CBD, BPM, SOA)
procedurile de testare, verificare i validare a sistemelor software
managementul versiunilor sistemelor software (CVS, Subversion)
managementul configurrii sistemelor software
metodologiile de organizare si management al proiectelor software
(planificare, conducere, ndrumare, control)
procesele de dezvoltare (analiza si proiectare) software (OOAD, OMT, XP, AP,
CATALYST, ICONIX, UP, etc.)
instrumentele software de analiz, proiectare, modelare, testare, validare,
generare teste,
generare cod, etc.
(CASE tools)
notatii si limbaje vizuale
(DFD, MSC, FSM, BPMN,
UML)

In practica se folosesc combinatii de procese, notatii si instrumente CASE
Procese de dezvoltare a sistemelor software complexe
Dezvoltarea software in tunel
Dezvoltarea unei aplicatii poate fi separata in mai multe parti:
- inlantuite secvential de-a lungul unei dezvoltari in cascada
- distribuite in diversele iteratii ale unei dezvoltari iterative
Dezvoltarea software in tunel este o
- modalitate vizuala de reprezentare a absentei metodologiei / procesului

intr-o zi, poate
Procesul de
dezvoltare
este invizibil
(inexistent)
inceputul e cunoscut
lipsa unui proces
Dezvoltarea software in cascada (waterfall)
Dezvoltarea software in tunel nu e potrivita decat pentru
- proiecte mici, cu un numar foarte limitat de participanti

Puncte de vizibilitate ale
procesului de dezvoltare
in cascada
Analiza
Proiectare
Codare
Testare
separarea
responsabilitatilor
fazelor dezvoltarii

Aplicatie
Teste functionale
Teste de integrare
Analiza
Proiectare
Codare Teste unitare
Validat
prin
Dezvoltarea software in V insista pe faptul ca in dezvoltarea in cascada
- testele sunt efectuate sincron cu dezvoltarea sistemului software
Proiectul creat in cascada produce pe parcurs documente
Proba efectiva a functionarii bune sau proaste a sistemului
- este obtinuta tarziu, abia in faza de integrare
Pentru a reusi, calea in cascada ar presupune:
- cunoasterea perfecta a ansamblului de cerinte
- intelegerea completa de catre analist a problemei dintr-un foc
- simplitatea determinarii unei solutii de catre proiectant
Ceea ce nu este cazul pentru sistemele software complexe, solutia fiind
- reintoarcerea la faze anterioare pentru a opera corectii in amonte in functie de
descoperirile facute in aval

Analiza
Proiectare
Codare
Integrare
Partea necunoscuta care
caracterizeaza sistemele
complexe se traduce in

reintoarceri ale
informatiei intre faze

pentru a incorpora
corectiile
Reintoarcerea la faze anterioare
- in functie de descoperirile facute in aval
- pentru a opera corectii in amonte
aval
amonte
Dezvoltarea iterativa
Dezvoltarea software iterativa
In dezvoltarea software iterativa:
- fiecare iteratie reproduce dezvoltarea in cascada, la o scara mai mica
(este o mini-cascada)

Analiza
Proiectare
Codare
Integrare
N ori
reintoarceri planificate,
dupa crearea unui nou
prototip evolutiv
Iteratiile pot fi grupate in 4 faze (conform procesului unificat UP)
iteratie de inceput (inception, exploratorie)
iteratii de elaborare (a arhitecturii)
iteratii de constructie (a versiunii beta)
iteratii de tranzitie (catre produsul final)
Fazele traditionale (cerinte, analiza, proiectare, implementare, testare, etc.)
- sunt acoperite gradual, iteratie dupa iteratie
fluxuri
de
activitati
4 faze
iteratie
Procesul iterativ in cadrul de referinta al rezolvarii problemelor
Sistemele software sunt solutii ale unor probleme de rezolvat intr-un context dat
contextul = domeniul problemei si constrangerile
problema = cerintele utilizatorului si ale aplicatiei
rezolvarea = procesul de dezvoltare (analiza, proiectare, codare)
subsolutii = subsistemele, elementele modelelor, prototipurile
solutia = produsul final (sistemul software)
daca patratul unui numar este
egal cu diferenta dintre 1 si un
al doilea numar, sa se afle cum
depinde primul numar de al doilea
Matematica
y
2
=1 - x

if (x > 1) {
cout << "impossible" << endl; }
else {

> equation.exe 0
y is 1

x<1 =>y = (1-x)
x>1 =>impossible

x<1 =>y = (1-x) x>1 =>impossible


Context
(Domeniu)
Inceput proiect
Final proiect
Lumea reala Abstractizari (concepte, cod)
Problema
Solutie
Procesul iterativ in cadrul de referinta al rezolvarii problemelor
Etapa analizei domeniului (contextului) si a cerintelor

Cerinte Model de Analiza
Inceput proiect
Final proiect
Problema
Solutie
Analiza
Context
(Domeniu)
Etapa proiectarii arhitecturale (de nivel inalt) si de detaliu

Model de Proiectare
Arhitectura

Inceput proiect
Final proiect Pattern-uri de proiectare
Problema
Solutie
Analiza
Proiectare
Context
(Domeniu)
Etapa implementarii (codarii si depanarii)

Model de Proiectare Prototip / Produs
Arhitectura

Inceput proiect
Problema
Solutie
Analiza
Proiectare
Implementare
Context
(Domeniu)
Etapa testarii, validarii si evaluarii

Model de Proiectare Prototip / Produs
Arhitectura

Inceput proiect
Problema
Solutie
Analiza
Proiectare
Implementare
Testare, evaluare
Context
(Domeniu)
Dezvoltarea top-down
Dezvoltarea software prin divizare si reunire (top-down)

divizare
clasificare si
reunire
reunire

Constructia unui sistem software este o secventa de iteratii de tip divizare-reunire,
fiind necesare:
descompunerea (analiza)
pentru a intelege problema si a putea formula o conceptie a solutiei
(re)compunerea (sinteza)
pentru a construi solutia (a realiza efectiv/concretiza conceptia)

Cum corespund fazele de mai jos cu exemplul ecuatiei matematice?

Descompunere
(funcional / OO)
Analiz
(funcional / OO) Construcie a
componentelor
Produs
Compunere
(integrare)
Specificatii

Procesul de descompunere traditional este dirijat de criteriul functional:
considera programul ca fiind un proces imens
care trebuie descompus recursiv in subprobleme (subprocese)
si odata subproblemele rezolvate (sub forma de functii si proceduri)
trebuie combinate solutiile implementate pentru a construi solutia intregii
probleme
Funcie principal
Sub-funcie A Sub-funcie B
Sub-funcie A1 Sub-funcie A2 Sub-funcie B1 Sub-funcie B2
sqrt()
main()

Descompunerea functionala
se bazeaza pe:
programare structurata si
modularizare functionala
Dezavantaje
- datele globale nu sunt protejate si pot deveni usor eronate / incoerente
- modificarea unei structuri de date se propaga in functiile care o folosesc
- evolutiile functionale pot implica modificari structurale puternice
=> functiile cerute trebuie sa fie bine identificate si stabile in timp

In lumea reala
sarcinile sunt realizate in colaborare (intre obiecte = agenti autonomi)

Abordarile actuale bazate pe obiecte (OO), componente(CBD), servicii (SOA)
imita modelele colaborative, sociale
Obiect utilizator
Mesaj
Legtur dinamic
Interaciune a obiectelor
Comunicaie ntre obiecte
Colaborare ntre obiecte
Decuplare intre obiecte
Declanare
(executie)
Referin
Obiect tinta
Comportament global
al sistemului
(multimea de scenarii =
secvene de mesaje =
colaborri ntre obiecte)
Operaie

Abordarea orientata spre obiecte (OO) a programarii
propune descompunere bazat pe integrarea a ceea ce este (structural) i ceea ce
face (comportamental) sistemul
initial a aparut ca o abstractizare (reducere la esential) a entitatilor lumii reale,
are ca scop modelarea caracteristicilor statice si dinamice (atribute si operatii)
ale domeniul problemei

Modelarea OO
formalizeaza perceptia noastra asupra lumii si
pune in corespondenta spatiul problemelor si spatiul solutiilor

Sistemul software OO (orientat spre obiecte)
reprezinta un model al unei parti din lumea reala

Elementele care compun modelul
sunt construite prin analogie cu entitati care apar in lumea reala
(obiecte reale, concepte)
sunt numite obiecte software
trebuie reprezentate in limbajul de programare

Ca si in cazul obiectelor si conceptelor din lumea reala
obiectele software pot fi categorisite (clasificate)

O constructie software (structura complexa) numita clasa
descrie intr-o forma abstracta toate obiectele software de un tip de date
particular

Obiectele si conceptele sunt clasificate (atat in lumea reala cat si in software) pe
baza caracteristicilor esentiale pe care le au :
atributele lor si
operatii care pot fi efectuate asupra lor

Clasele reprezinta obiecte software care au caracteristici similare

Atributele sunt reprezentate ca elemente de date
variabile interne care caracterizeaza obiectele

Ansamblul valorilor atributelor unui obiect la un moment dat reprezinta
starea obiectului

Starea unui obiect poate varia in timp, ca urmare a comportamentului

Comportamentul este
rezultatul executiei operatiilor care pot fi efectuate asupra obiectului

Functiile in abordarea OO
se reprezinta prin forme de colaborare (comunicare, interactiune) intre obiectele
ce compun sistemul

Cuplajul intre obiecte
este dinamic,
obtinut prin apelurile de operatii (trimiterea de mesaje).
Exemplu:

Buton
Cabin U
Bec
Aprindere
Deschidere
Deplasare
Actionare
Lift

Analiza OO
gasirea si descrierea conceptelor din domeniul problemei
in cazul unei biblioteci pot fi gasite obiecte ale domeniului: cartile, biblioteca
Proiectarea OO
reprezinta software obiectele si colaborarile pentru a indeplini sarcinile
obiectele tip Book au atribut comun title si operatie comuna getChapter
Implementarea OO
obiectele software sunt transformate in codurile sursa ale solutiei
categoria obiectelor software de tip Book poate deveni o clasa Java
Diagrama
UML de
clase
Cod sursa
J ava

Abordarea orientata spre obiecte (OO) a programarii
Incapsulare (grupare si
protectie) a datelor si
functiilor (OO)
Cuplaj slab
(dinamic)
Separarea in obiecte pe baza
de responsabilitati (date si
functiile asociate)
Colaborare
intre obiecte
Dezvoltarea
software iterativa

prin divizare si
reunire
(top-down)
Prototip 1
Prototip 2
Prototip 3
Produs
final
Grupuri de
cerinte
prioritizate
Procesul agil (AP/XP)

Procesul de dezvoltare agil (AP/XP) Agile/eXtreme Programming

Dezvoltarea sistemelor software:

in cascada vs iterativa vs agila (AP/XP)
Procesul de dezvoltare agil
Iteratii scurte si
multe
Procesul ICONIX
Flux de activitati
modelare dinamica
Flux de activitati
modelare statica
Procesul de dezvoltare ICONIX fluxurile de activitati
Procesul de dezvoltare ICONIX conceptul cel mai important
Analiza robustetii (proiectarea preliminara) ajuta la umplerea golului dintre
- analiza cerintelor (modelarea UC) si
- analiza si proiectarea sistemului software
prin legarea UC de obiecte
Procesul de dezvoltare ICONIX analiza robustetii
Procesul unificat (UP)
Procesul de dezvoltare unificat (UP) (Rational) Unified Process
- este organizat in 4 faze fiecare continand una / mai multe iteratii
Procesul de dezvoltare unificat (UP)
- in fiecare iteratie fluxurile de activitati (modelare business, cerinte, analiza,
proiectare, implementare, testare, etc.) au o pondere diferita
fluxuri
de
activitati
4 faze
iteratie
UPB - ETTI - Curs ISC - an IV - Specializarea RST 07.03.2011 11:32 62 Curs UML 62
Dezvoltarea
sistemelor
software top-
down

Artefacte
ale UP
Dezvoltarea
top-down a
sistemelor
software
Modelele UP
(Unified Process)
bazate pe UML
si dependentele
intre ele
Modelul UC
Modelele de
analiza si
proiectare
Alte modele
bazate pe
nucleul UML
Modele Business
(optionale, folosesc
extensii UML)
Model de date
(extensii UML)
In practica se folosesc combinatii de procese, notatii si instrumente CASE

Curs ISC 2011 1 v01

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Curs ISC 2011 1 v01

Încărcat de

Drepturi de autor:

Formate disponibile

UPB - ETTI - Curs ISC - an IV - Specializarea RST 07.03.

S-ar putea să vă placă și