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/


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

y2 = 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


y2 = 1 - x

Solutia la nivel conceptual

Problema la nivel conceptual

Analist

Analiza

Proiectare

(design)

x y = (1-x)

x>1 => impossible

Proiectant

abstractii



Sistemul software


if (x > 1) {

cout



Sistemul software

pentru utilizator: un serviciu oferit

if (x > 1) {

cout



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

y2 = 1 - x

if (x > 1) {

cout 1 => impossible

x 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

Java




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

Documents

Transcript of Curs_ISC_2011_1_v01