10 Dezvoltarea bazata pe componenteandrei.clubcisco.ro/cursuri/f/f-sym/4idp/elearn/9... ·...

Platformă de e‐learning și curriculă e‐content g șpentru învățământul superior tehnic

Instrumente pentru Dezvoltarea Programelorp g

9 Instrumente pentru dezvoltarea bazata pe componente9. Instrumente pentru dezvoltarea bazata pe componente

Platformă de e‐learning și curriculă e‐content pentru învățământul superior tehnic

C iConţinut

Reutilizare software Reutilizare software

Dezvoltarea bazată pe componente – metodologie SE

2IDP – Instrumente pentru Dezvoltarea Programelor


Reutilizare Software (a Codului)


“Resistance is Futile - You will be Assimilated”


R tili bilit t ftReutilizabilitate software În majoritatea disciplinelor ingineresti sistemele suntproiectate prin compunerea unor componente preproiectate prin compunerea unor componente pre‐existente ce au fost dezvoltate şi folosite anterior în altesisteme.

Reutilizabilitatea software ‐ proces de dezvoltare bazat perefolosirea de componenterefolosirea de componente

Avantaje:S ft d lit t ( t l t t t t )Software de calitate (componentele sunt testate)Proiecte dezvoltate mai repede (componente sunt dejaimplementate)


implementate)Costuri mai mici de dezvoltare


I i i f b ă f l iIngineria software bazată pe refolosire Refolosirea sistemelor de aplicaţii

U î i f fi f l iUn întreg sistem software poate fi refolosit •prin încorporarea fără nici o modificare într‐un alt sistem (refolosire COTS).•prin dezvoltarea unei noi familii de aplicaţii.

Refolosirea componentelorC t l i li ții d l b i t â ă l bi t t fiComponentele unei aplicații, de la sub‐sisteme până la obiecte, pot fi refolosite.

Refolosirea de obiecte şi funcţiiComponentele software ce implementează un singur obiect sau funcţie pot fi refolosite.



M i iMotivaţie Refolosirea eficientă necesită:Funcţionalitate – precondiţii şi serviciiInterfeţe – modalitatea de plug‐and‐playDependenţe – fără efecte colaterale necunoscute

Component‐based software engineering (CBSE) a p g g ( )apărut în anii ’90 ca modalitatea de adresare a dezvoltării bazate pe refolosire

Notă: design pattern‐urile de asemenea promovează


Notă: design pattern urile de asemenea promovează ideea de refolosire


A j l f l i iiAvantajele refolosirii Sistem de mai mare încredere

Componentele software refolosite sunt mai de încredere – ele au fost anterior încercateşi testate

Management mai exactEstimare mai exactă a costului implicat prin refolosire decât prin implementarea “de laEstimare mai exactă a costului implicat prin refolosire decât prin implementarea de la zero”

Folosirea eficientă a specialiştilorSpecialiştii sunt folosiţi pentru dezvoltarea de componente ce sunt ulterior integrate în diverse proiecte (dispare rutina)p ( p )

Respectarea standardelorUnele standarde pot fi implementate sub forma unui set de componente reutilizabilestandard (ex: componenta de trimis mail‐uri folosind smtp)Ex: O componentă ce implementează funcţii de creare de meniuri poate conduce cătreEx: O componentă ce implementează funcţii de creare de meniuri poate conduce cătreun format unitar de afişare al meniurilor între diverse aplicaţii/proiecte – familiarizareamai uşoară a utilizatorilor

Dezvoltare acceleratăSistemele pot fi aduse mai repede pe piaţă


Sistemele pot fi aduse mai repede pe piaţăDezvoltarea şi validarea implică timp mai mic


D j l f l i ii (1)Dezavantajele refolosirii (1)

Cost mărit pentru mentenanţăDacă sursele unei componente nu sunt disponibile costulpentru mentenanţă poate implica inclusiv eforturi pentruadaptarea componentei la diverse modificări ale cerinţelorp p ţ

Lipsa suportului pentru instrumenteInstrumentele CASE ar putea să nu suporte dezvoltareap pfolosind refolosirea de componente.

Sindromul “nu a fost inventat aici”Unii ingineri software preferă câteodată rescrierea unei componente crezând că o pot îmbunătăţi. Cauza ţine de încrederea în componentele scrise de alţii şi de faptul că rescrierea de la zero poate fi văzută ca o activitate mai


rescrierea de la zero poate fi văzută ca o activitate mai “challenging” decât refolosirea.


D j l f l i ii (2)Dezavantajele refolosirii (2)

Crearea şi menţinerea unei biblioteci de componentePopularea unei biblioteci de componente şi asigurarea f t l i ă d lt t ii i t f l i t fi ţifaptului că dezvoltatorii o şi pot folosi poate fi o operaţie costisitoare –> tehnicile de clasificare, catalogare şi regăsire a componentelor software încă nu sunt suficient de mature.

Găsirea, înţelegerea şi adaptarea componentelor reutilizabileComponentele software trebuie regăsite într‐o bibliotecă, înţelese şi, adesea, adaptate pentru a se potrivi mediului nostru


nostru.


Ab dă i b f l i (1)Abordări bazate pe refolosire (1) Design patterns

Abstracţii generice ce apar între aplicaţiiObiecte şi interacţiuni abstracte şi concrete

Component‐based development Component‐based developmentSistemele sunt dezvoltate prin integrarea de componente (colecţii de obiecte)

Application frameworksColecţii de clase abstracte şi concrete ce pot fi adaptate şi extinse pentru crearea de aplicaţii

Legacy system wrappingg y y pp gSistemul legacy poate fi încapsulat de un set de interfeţe (putem furniza accesul la sistem prin aceste interfeţe)

Service‐oriented systems


Service oriented systemsSistemele sunt dezvoltate pe baza unor servicii distribuite


Ab dă i b f l i (2)Abordări bazate pe refolosire (2)

Application product linespp pDezvoltarea pornind de la o aplicaţie a unei arhitecturi maleabile ce poate fi adaptată ulterior necesităţilor clienţilor

COTS integrationSistemele sunt dezvoltate prin integrarea de sisteme de aplicaţii deja existenteSistemele sunt dezvoltate prin integrarea de sisteme de aplicaţii deja existente

Configurable vertical applicationsDezvoltarea unui sistem generic ce poate fi configurat nevoilor specifice ale clienţilor

Program librariesBiblioteci de clase şi funcţii ce implementează operații des folosite

Program generatorsg gGeneratoare de aplicaţii sau de componente de aplicaţii bazate pe specificul unui anumit domeniu

Aspect‐oriented software developmentComponente partajate întreţăsute într o aplicaţie în diverse locuri la


Componente partajate întreţăsute într‐o aplicaţie în diverse locuri la compilarea programului


R ili b ăReutilizarea bazată pe concepte Când refolosim programe sau componente suntem constrânşi să respectăm deciziile de proiectare ale dezvoltatorilor acestorarespectăm deciziile de proiectare ale dezvoltatorilor acestoraLimitare a oportunităţilor pentru refolosire

Reutilizarea bazată pe concepte (eng concept reuse) o formă Reutilizarea bazată pe concepte (eng. concept reuse) o formă mai abstractă de refolosireO abordare particulară descrisă într‐o formă independentă de implementarePe baza acesteia se dezvoltă o implementare concretă

C l d ă b dă i i i l Cele două abordări principale:Design patternsGenerative programming


Generative programming


D iDesign patterns Pattern – descriere a problemei şi esenţa soluţiilor

t iacesteia

Design pattern – modalitate de refolosire a noţiunilor b t t i l ţiil f it l bl ăabstracte şi soluţiilor referitoare la o problemă

Pattern‐urile se bazează adesea pe caracteristicile bi t l t i i li fiobiectelor precum moştenire şi polimorfism



l l l d lExemplu: Multiple displays



P l ObPattern‐ul Observer

NumeNume

Observer.

Descriere

Separă afişarea stării obiectului de obiect

Descrierea problemei

Necesitatea de a avea mai multe tipuri de afişare a stăriiNecesitatea de a avea mai multe tipuri de afişare a stării

Descriere soluţiei


Slide‐ul următor conţinând descrierea UML


l bPattern‐ul Observer



l f kApplication frameworks Framework‐urile sunt entităţi generice ce sunt extinse pentru crearea unor aplicaţii sau subsisteme particularecrearea unor aplicaţii sau subsisteme particulare Framework – modalitate de construcţie a unui subsistem pe baza unor colecţii de clase (abstracte şi concrete) şi a interfeţelor între acesteaacesteaAdăugarea de componente pentru a suplini părţi din proiect Instanţierea claselor abstracte ale framework‐ului

Framework‐urile sunt entităţi de dimensiuni mari ce pot fi refolosite

Extinderea unui framework implică: Extinderea unui framework implică:Adăugarea de clase concrete ce moştenesc operaţiile claselor abstracte din frameworkAdă d t d t l t î ă l i t


Adăugarea de metode ce sunt apelate în răspuns la evenimente recunoscute de framework


Clase de framework‐uri

System infrastructure frameworksSystem infrastructure frameworksSuportă dezvoltarea de sisteme suport pentru infrastructuri (ex. infrastructura de comunicaţii, interfeţe utilizator, compilatoare)

Middleware integration frameworksStandarde şi clase ce suportă comunicaţia între componente şi ş p ţ p şschimbul de informaţii

Enterprise application frameworksSuportă dezvoltarea de tipuri particulare de aplicaţii (ex. sistemele financiare)



d l llModel‐view controller

Framework pentru proiectarea GUIPermite mai multe reprezentări ale unui obiect şi separarea interacţiunilor de acesteaImplică instanţierea unor pattern‐uri



R f l i i l d li iiRefolosirea sistemelor de aplicaţii

Implică refolosirea unor sisteme de aplicaţii integraleImplică refolosirea unor sisteme de aplicaţii integrale Configurarea unui sistem pentru adaptare la un mediuIntegrarea a două sau mai multe sisteme în scopul creării unei aplicaţii noinoi

Două abordări principale Două abordări principale:Integrarea produselor COTSDezvoltarea bazată pe linii de producţie



R f l i d l COTSRefolosirea produselor COTS

COTS ‐ Commercial Off‐The‐Shelf systemsSisteme complete de aplicaţii ce oferă un API

Construirea sistemelor prin integrarea COTS ‐ strategie de dezvoltare viabilă pentru unele tipuri de sisteme precum cele de comerţ electroniccomerţ electronic

Avantaje:Dezvoltarea mai rapidă a aplicaţiilorDezvoltarea mai rapidă a aplicaţiilorCosturi mai mici de dezvoltare



Sistem E‐procurement



R f l i b ă d COTSRefolosirea bazată pe produse COTS Client – folosirea unor programe standard de e‐mail şi web browsing

Server – integrarea unei platforme de comerţ g p ţelectronic într‐un sistem existent de ordonanţări

Implică scrierea unui adaptor prin intermediul căruia datele p p ppot fi schimbate

Pentru trimiterea de e‐mail‐uri către clienţi se integrează de asemenea un sistem de e‐mail

•Necesită încă un adaptor pentru primirea datelor



Probleme de integrare ale sistemelor COTS

Li d l f i li ă ii i f i Lipsa de control asupra funcţionalităţii şi a performanţei

Probleme legate de interoperabilitatea sistemelor COTSf fProducători diferiţi pot veni cu soluţii de integrare diferite

Nu există control asupra evoluţiei sistemuluiProducătorii (nu utilizatorii) controlează evoluţia

Suportul din partea producătorilorProducătorii pot să nu ofere suport pe întreaga durată de viaţă a produsului



Li ii d d i fLinii de producţie software

Liniile de producţie software sau familii de aplicaţiip ţ p ţFuncţionalităţi generice ce pot fi adaptate şi configurate pentru folosirea într‐un anumit context

Adaptarea poate presupune:Configurarea componentelor şi sistemuluiConfigurarea componentelor şi sistemuluiAdăugarea de noi componente în cadrul sistemuluiSelectarea dintr o librărie de componente existente aSelectarea dintr‐o librărie de componente existente a celor ce se potrivesc cel mai bineModificarea componentelor conform cerinţelor


Modificarea componentelor conform cerinţelor


S i li d l COTSSpecializarea produselor COTS

Specializarea în funcţie de platformăSpecializarea în funcţie de platformăDiverse versiuni ale aplicaţiei sunt dezvoltate pentru diverse platforme

S i li î f i d di Specializarea în funcţie de mediuDiverse versiuni ale aplicaţiei sunt create pentru diverse medii de operare (e.g. diverse tipuri de echipamente de comunicare)

Specializare funcţionalăDiverse versiuni ale aplicaţiei sunt create pentru clienţii având cerinţe diferitecerinţe diferite

Specializarea bazată pe procesDiverse versiuni ale aplicaţiei sunt create pentru a suporta diverse


p ţ p pprocese business


Si t d t lSistem de management a resurselor

Ni l l UINivelul UI

Ni l l ti ii I/ONivelul gestiunii I/O

Nivelul gestiunii resurselor

Nivelul bazelor de date



G i hi l lGestiunea vehiculelor

Sistem de gestiune a resurselor specializat – scopul este de g p pa aloca resurse (vehicule) pentru gesiunea incidentelor

Adaptările includ:pLa nivelul UI există componente pentru afişarea şi comunicarea informaţiilor la nivelul operatorului

l l / ăLa nivelul gestiunii I/O, există componente pentru gestiunea autentificării, raportării şi planificării ruteiLa nivelul gestiunii resurselor există componente pentru localizarea g p pşi trimiterea vehiculelor, gesiunea stării acestora şi logareaincidentelorNivelul bazelor de date include gestiunea informaţiilor privind


Nivelul bazelor de date include gestiunea informaţiilor privind echipamente, vehicule şi hărţi


h l lGestiunea vehiculelor



bl l f l l lProblemele refolosirii: Costul eşecului

• Ariane 5: European Expendable p pLaunch System

• Produs de European Space Agency• A înlocuit Ariane 4, dezvoltarea a

implicat peste 10 ani şi un cost de 7 milioane $milioane $



Costul eşeculuiCostul eşecului

În 1996, la doar 39 de ,secunde de la decolare, Ariane 5 a explodat



Costul eşecului

• Ariane 5 rula software-ul original al Ariane 4 • Totuşi arhitectura hardware era diferită

Si t l d hid j l A i 5 î ă• Sistemul de ghidaj al Ariane 5 încerca să convertească un număr pe 64 de biţi (datele privind viteza) într-un format pe 16 biţi) p ţ– Rezultatul = overflow error

• Ariane 5 a interpretat rezultatul overflow-ului ca dovadă că sistemul era “out of control” şi a iniţiatdovadă că sistemul era out of control şi a iniţiat procedura de self-destruction!



Sumar

Avantajele refolosirii constau în costuri mai mici, dezvoltare mai rapidă de software şi riscuri mai mici

Framework urile de aplicaţii sunt colecţii de obiecte concrete şi Framework‐urile de aplicaţii sunt colecţii de obiecte concrete şi abstracte proiectate pentru refolosire prin specializare

Refolosirea bazată pe produse COTS are la bază sisteme de mari p pdimensiuni off‐the‐shelf

Sistemele ERP sunt create prin configurarea unui sistem generic i f ii i i d b i l li l icu informaţii privind business‐ul clientului

Linii de producţie software sunt aplicaţii înrudite dezvoltate în jurul unui core comun de funcţionalităţi partajate


jurul unui core comun de funcţionalităţi partajate


Dezvoltarea bazată pe componente

"Recently we've seen evidence of new Borg technologies that allow some areas of their

technology to regenerate with extreme speed technology to regenerate with extreme speed, making it very difficult for defenders to

remove the Borg component structures and modifications in order to regain control of

their vessel."Star Trek: Assimilation



D l b ăDezvoltarea bazată pe componente

Component‐based software engineering (CBSE) – abordarebazată pe refolosire

Motivaţia:Abordările orientate‐obiect eşuază să suporte refolosirea software‐ului

•clasele sunt în general orientate spre funcţionalităţi•clasele sunt, în general, orientate spre funcţionalităţispecifice•sunt greu de integrat în proiecte noi

Componentele reprezintă abstractizări ale unor funcţionalităţiFurnizoare de servicii stand‐alone



Refolosirea bazată pe ComponenteRefolosirea bazată pe Componente

Catalog deCatalog de componente

software

Cerinţeclient

Integrator deIntegrator decomponente

AplicaţiasoftwareFurnitori de


Furnitori decomponente


CBSE şi principiile de proiectare

În afara beneficiilor aduse de refolosire, CBSE este bazată pe principii:

Componentele sunt independente şi nu interferă unele cu altele

Implementările componentelor sunt ascunse

Comunicaţia are loc prin interfeţe bine‐definite

Platformele de componente sunt partajate şi implică costuri reduse de dezvoltare



bl lProblemele CBSE

Component trustworthiness – cum putem avea încredere într‐o componentă al cărei cod sursă nu îl cunoaştem?componentă al cărei cod sursă nu îl cunoaştem?

Component certification – cine certifică calitatea unei componente?

Emergent property prediction – cum pot fi prezise proprietăţile emergente ale compunerii de componente?

Requirements trade‐offs – cum putem analiza şi alege între calităţile unei componente sau a alteia?



Ce este o Componentă?“an independently deliverable set of reusable services” (Short `97)an independently deliverable set of reusable services (Short 97)

“a unit of composition with contractually specified interfaces and f p y p f fexplicit context dependencies only. A software component can be deployed independently and is subject to third‐party composition.” (Szyperski `98)

“a software element that conforms to a component model and can be independently deployed and composed without modificationbe independently deployed and composed without modification according to a composition standard” (Heinemand & Councill `01)



Ce este o Componentă?

“ i d d l d li bl f bl i ” (Sh `9 )“an independently deliverable set of reusable services” (Short `97)

“ it f iti ith t t ll ifi d i t f d“a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third‐party composition.” (Szyperski `98)(Szyperski 98)

“a software element that conforms to a component model and cana software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard” (Heinemand & Councill `01)



f l lDefiniţii ale componentelor

Councill şi Heinmann:A software component is a software element that conforms to

t d l d b i d d tl d l d da component model and can be independently deployed and composed without modification according to a composition standard.

Szyperski:A software component is a unit of composition withA software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third‐parties


independently and is subject to composition by third‐parties.


Ce este o Componentă?

Serviciu bine definit (funcţionalitate) Serviciu bine definit (funcţionalitate)

Interfaţă bine definită

D d ţ li it Dependenţe explicite

Standardizare



C M d lComponent Model

Un standard ce defineşte componenteCum pot fi contruite componenteleCum pot fi compuse componentele (asamblate)Cum sunt deployate componentele

D i tă lt t d d fl t î tiţi Dar există multe standarde aflate în competiţie, e.g.Enterprise JavaBeans (EJB) ‐ SunComponent Object Model (COM) .NET ‐Microsoftp j ( ) fCORBA Component Model (CCM) – OMG



Procesul de dezvoltare bazat pe componente

1. Dezvoltarea cerinţelor iniţiale ale aplicaţiei1. Dezvoltarea cerinţelor iniţiale ale aplicaţiei

2. Căutarea componentelor candidat

3 Modificarea cerinţelor în funcţie de componentele candidat3. Modificarea cerinţelor în funcţie de componentele candidat SAU continuarea căutării pentru un candidat mai bun

Balansare între cerinţele ideale şi funcţionalitatea componentelor disponibile


componentelor disponibile


Compunerea componentelor

Procesul de asamblare a componentelor în scopul creării unui sistemsistem

Compoziţie presupune integrarea componentelor între ele şi cu Compoziţie presupune integrarea componentelor între ele şi cu infrastructura

Integrarea poate presupune scrierea de ‘glue code’



Problemele compuneriiProblemele compunerii Funcţionalităţi suprapuseMai multe componente pot furniza aceeaşi funcţionalitateMai multe componente pot furniza aceeaşi funcţionalitateProiectanţii trebuie să o selecteze pe cea mai adecvată

Funcţionalitate lipsăCăutarea unei componente corespunzătoare SAUDezvoltarea unei componente ce implementează funcţionlitatea

Funcţionalitate redundantăCompoziţia poate introduce funcţionalitate suplimentareFuncţionalitatea suplimentară poate fi încorporată SAUFuncţionalitatea suplimentară poate fi încorporată SAU invalidată

Nepotriviri arhitecturale


Nepotrivire între ceea ce oferă o componentă şi ceea ce este aşteptat a fi oferit în contextul aplicaţiei


I t f ţ l C t lInterfeţele Componentelor

component

Requiresinterface

Providesinterface

• Requires interface defineşte serviciul ce trebuie să fie q şdisponibil pentru ca o componentă să poată opera corect

• Provides interface defineşte serviciul furnizat de


componentă


Interfeţele ComponentelorInterfeţele Componentelor

Brake

Controllerctrl

Speed

Majority vote

ctrl

Cruse control systemCruse control system




Necesită: 3 semnale din parteaMajority

vote

Necesită: 3 semnale din partea senzorilor de viteză

Furnizează: valoarea semnalului ales pe principiul majorităţii

Controller

Necesită: • Intrare de tip enable/disable

Controller • Intrare valoare vitezăFurnizează:

S tă i d f â


• Setări de frânare• Setări de accelerare



Brakectrl

Necesită: Setări ale frânei (on/off)Furnizează: Setări ale activatorului

de frână

Speed Necesită: Setări ale vitezeiF i ă S tă i l ti t l ictrl Furnizează: Setări ale activatorului

de accelerare



Nepotriviri între interfeţeNepotriviri între interfeţe• Adesea apar nepotriviri între interfeţe:

• Nepotrivire între tipurile de parametrii• Nepotrivire între tipurile de parametrii

• Nepotriviri ale numelor operatorilor folosiţi

• Interfeţe incomplete– necesită şi/sau furnizeazăInterfeţe incomplete necesită şi/sau furnizează

• Soluţii posibile:• Scrierea de “glue code” – punţi între breşele descoperite SAUg p ţ ş p

• Folosirea de componente adaptor pentru soluţionarea incompatibilităţilor

Adaptorkmph2mph

Speedokmph

Displaymph


p p


Ti i d iTipuri de compuneri

Compunere secvenţială p ţComponentele compuse sunt executate în secvențăCompunerea interfeţelor furnizate de fiecare componentăp ţ p

Compunere ierarhicăO componentă apelează serviciile unei alte componenteO componentă apelează serviciile unei alte componenteInterfaţa furnizată de o componentă este compusă cu interfaţa cerută de o alta

Compunere aditivă Interfeţele a două componente sunt puse împreună pentru


Interfeţele a două componente sunt puse împreună pentru crearea unei noi componente


Ti i dTipuri de compunere



C l i ă ii lCostul proiectării componentelor

Costurile asociate cu dezvoltarea de componente refolosibile vor fi adesea mai mari decât dezvoltările specializate Din perspectiva dezvoltării trebuie considerate beneficiile pe termen lung

C t l t i tă ti i ă i î ti Componentele sunt generice, nu suportă optimizări în timp sau spaţiuÎn funcţie de domeniu poate exista un cost ataşat acestorÎn funcţie de domeniu poate exista un cost ataşat acestor ineficienţe



Prezicerea comportamentului emergent

În mod ideal dacă un sistem este dezvoltat pornind de la componente având comportamente bine definite ar trebui să fie posibilă prezicerea comportamentului emergent al sistemului Realitatea este însă departe de cazul ideal!

Furnizarea de instrumente suport pentru prezicerea comportamentului reprezintă un domeniu de cercetare, e.g.The Carnegie Mellon Software Engineering Institute (SEI)P di bl A bl f C ifi bl C d (PACC)Predictable Assembly from Certifiable Code (PACC)http://www.sei.cmu.edu/pacc/



Î dÎncrederea Fiind dată o componentă fără acces la codul sursă din spatele acesteia, cum putem decida dacă execuţia acesteia este sigură?

Executăm componenta şi vedem Executăm componenta şi vedemBug‐urile latente pot apare doar după ce sistemul este deployat

Avem încredere în furnizor Avem încredere în furnizorNu se iau în considerare defectele, greşelile nedorite oneste şi modificarea în timpul distribuţiei

CertificareCine furnizează certificarea, de ce am avea încredere în ei, de ce am avea încredere în certificat?


avea încredere în certificat?


Î d b C ifi ă iiÎncredere pe baza Certificării



Evidence based CertificationEvidence‐based Certification

Safetycode policy

certifyingcompiler

proofchecker

code+ checker

executed

proofpassuser interaction

codefailmay be required

in general


CustomerProvider Proof Carrying Code


P f C i C d (PCC)Proof Carrying Code (PCC) Clientul şi furnizorul se pun de acord asupra unei politici de securitate partajată Furnizorul dezvoltă codul şi o demonstraţie matematică ce atestă faptul că codul sursă satisface politica de securitatePoate implica ghidarea utilizatorului în scopul înţelegerii politicilor mai

fi ti tsofisticate

Demonstraţia & codul sunt trimise clientului ‐ dispare necesitatea criptării Clientul verifică demonstraţia & codul conform politicii de securitate – verificarea este făcută complet automat Codul este rulat doar dacă verificarea reuşeşteCodul este rulat doar dacă verificarea reuşeşte

PCC este o abordare robustă pentru că nu contează dacă cineva difi ă d l/d t ţi î ti l di t ib ţi i


modifică codul/demonstraţia în timpul distribuţiei Dar verificatorul demonstraţiei trebuie să rămână securizat


SSumar

Noţiuni prezentateComponentele ca bază a reutilizabilităţii softwareModele de componente – standarde pentru furnizori & integratoriP bl l d l il l iProbleme legate de alegerile componentelor şi compunerea acestoraPredictibilitate, încredere şi certificare

Lecturi recomandateD. Budgen, “Software Design”, Addison‐Wesley 2003

K‐K. Lau & Z. Wang “A Survey of Software Component Models” University of Manchester Preprint Series CSPP‐30http://www.cs.man.ac.uk/~kung‐kiu/pub/cspp38.pdf


http://www.cs.man.ac.uk/ kung kiu/pub/cspp38.pdfI. Sommerville, “Software Engineering”, Addison‐Wesley 2007

Date post:	28-Jul-2020
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times

10 Dezvoltarea bazata pe componenteandrei.clubcisco.ro/cursuri/f/f-sym/4idp/elearn/9... ·...

Documents