Proiectarea programelor pentru aplicatii de timp real

Proiectarea programelor pentru aplicatii de timp real

1. Consideratii generale privind proiectarea aplicatiilor de timp-real

Desi exista o mare asemanare intre proiectarea programelor pentru aplicatiile de timp-real si cele conventionale, exista unele deosebiri de care trebuie sa se tina cont. In general, o aplicatie trece prin urmatoarele faze:

specificarea cerintelor functionale;

alegerea sau determinarea algoritmilor;

stabilirea cerintelor pentru programe si pentru hardware;

proiectarea preliminara a programelor;

codificarea si depanarea programelor;

instalarea, testarea, evaluarea si masurarea performantelor;

intretinerea programelor.

Trebuie mentionat ca deseori este necesara revenirea dintr-o faza in unele dintre fazele anterioare pentru efectuarea unor modificfiri.

In prima faza se precizeaza functiile si sarciniie pe care trebuie sa le indeplineasca sistemul de calcul pentru procesul condus. Este necesara o cunoastere cat mai detaliata a sistemului condus pentru a putea determina criteriile de decizie si actiunile pe care trebuie sa le efectueze sistemul de calcul.

Se apreciaza timpul maxim de raspuns la modificarea unor marimi variabile ale
proceselor din mediul in care este inglobat calculatorul, indicii (criteriile) de
performanta etc.

Se construieste ceea ce se numeste un model al cerintelor cuprinzand functii, comportamente si constrangeri ale interfetelor. In aceasta faza, se considera ca sistemul de conducere se va implementa pe un calculator cu viteza de calcul si memoria infinite. De asemenea, sistemul de calcul este considerat ca avand eapacitati de prelucrare paralela neiimitate.

Cea de-a doua faza se realizeaza in urma unor analize ale rezultatelor fazei precedente. Determinarea algoritmilor se face tinand cont de tipul aplicatiei de cerintele functionale.

In cea de-a treia faza se determina o structura hardware a sistemului de calcul, urmand a se specifica timpul de raspuns, modurile de realizare a schimbului de informatii cu exteriorul si bazele de date care trebuie construite.

In faza a patra in urma analizei modelului (descrierii) sistemului de conducere, se realizeaza impartirea activitatilor in taskuri si definirea interfetelor dintre ele. La impartirea activitatilor in taskuri se vor avea in vedere relatiile dintre ele.

Daca doua activitati care schimba intre ele informatii sunt cuprinse in taskuri diferite, atunci trebuie rezolvata o problema corespunzatoare de comunicatie.

Activitatile care cuprind un set de functii puternic corelate intre ele se : recomanda sa fie grupate in acelasi task,pentru a evita sporirea timpului de calcul datorita necesitatilor de comunicare.

Daca doua activitati, care trebuie sa urmeze una dupa alta sunt cuprinse in taskuri diferite, atunci trebuie rezolvata problema sincronizatii dintre ele.

Daca doua activitati, care solicita aceeasi resursa, sunt cuprinse in taskuri diferite, trebuie rezolvata problema excluderii mutuale (a accesului la resursa).

Daca doua activitati se executa periodic, dar cu perioade diferite, se recomanda sa fie cuprinse in taskuri diferite.

Daca o activitate depinde critic de timp, se recomanda sa fie cuprinsa intr-un task separat, cu o prioritate mai mare decat cea a celorlalte taskuri.

In aceasta faza se are in vedere ca sistemul de calcul nu are capacitati de prelucrare si memorare infinite. Se vor lua in considerare:

timpul de acces la zonele comune de date din memorie;

intarzierile tratarilor intreruperilor;

timpii pentru comunicarea mesajelor

Se va construi, tinand cont de cerintele specificate un model de proiectare.

Trecerea de la modelul cerinfelor la modelui de proiectare nu se poate face printr-o simpla transformare, ci trebuie construct un model arhitectural de proiectare software. Intre cele doua modele, desi sunt diferite, trebuie sa existe corelatii. Trebuie sa se verifice daca fiecare cerinta a fost cuprinsa in una sau mai multe componente ale proiectului. De asemenea, trebuie sa se verifice daca fiecare componenta a proiectului indeplineste o cerinta si deci nu este in plus.

5. Faza a cincea incepe cu determinarea structurii datelor si a mecanismelor de acces la ele. Se continua cu proiectarea detaliata a taskurilor, tinand cont ca fiecare activitate poate fi realizata ca o unitate de program secventiala. Daca se determina un set de proceduri comune unor activitati din taskuri diferite, se va analiza daca pot, sau nu, sa fie utilizate in comun (daca sunt reentrante). Utilizand un limbaj de programare adecvat si compilatorul corespunzator se efectueaza codarea programelor.

6. Faza a sasea consta din incarcarea programeior, efectuarea legaturilor etc. O operatie deosebita consta in testarea programelor. Deseori, modul in care vor fi testate programeie rezulta din fazele anterioare. Se mentioneaza ca testele ar putea cuprinde verificarile si masurarile:

activitatilor (luate separat);

taskurilor;

comunicarilor intre taskuri;

excluderilor mutuale de la utilizare resurselor;

sincronizairii taskurilor intre ele si cu timpul fizic;

blocarii (interblocarii) taskurilor;

indeplinirii sarcinilor rnentionate in faza de specificare a cerintelor functional.

Uzual, pentru operative de testare sunt necesare programe auxiliare (speciale). Pot fi utilizate tehnicile de testare cunoscute de la programarea conventional, ele trebuind sa fie completate cu verificarea indeplinirii cerintelor de lucru de timp-real.

2. Proiectarea modulara

Din motivele enuntate anterior, aplicatiile mari trebuie partitionate in module. Aceasta permite impartirea sarcinilor intre mai multi proiectanti sau chiar echipe, si permite o mai buna organizare a activitatii de proiectare. Partitionarea sistemului are ca rezultat descompunerea problemei in partti mai usor de manevrat.

Modulele trebuie sa fie simple pentru a permite:

• intelegerea scopului si structurii lor;
• verificarea si validarea corectitudinii lor;
• aprecierea interactiunii lor cu alte module

evaluarea efectului lor asupra sistemului global.

Modulele pot fi definite folosind structurarea functionala, obiectuala sau prin combinarea celor doua. Intre module se recomanda sa fie o cat mai slaba interactiune. Chiar daca informatiile schimbate intre module au o structura foarte complexa, ar fi indicat ca volumul lor sa fie mic.

Exista mai multe tipuri de conexiunii posibile. In figura 1.a. este prezentat cazul unei interactiuni unilateralee prin date, iar in figura 1.b. o interactiune bilaterala. Figura 1.e. reprezinta cazul unei inte-ractiuni de control. Cea mai com-plexa interactiune este cea din figura 1.e. care este una de tip bilateral atat referitor la date cat si la marimile de control.

Fig. 1. Tipuri de conexiuni

In figura 2. este reprezentat modui de descompunere ierarhizata a unui sistem in module.

Fig.2. Structuri ierarhizate de module

De obicei, moduleie trebuie sa comunice intre ele. Metodele de comunicare depind de modul de conexiune a modulelor. Exista urmatoarele forme de conexiune:

Conexiunea prin continut a modulelor

Este cea mai putin recomandata. Ea este adeseori intalnita in cazul programarii in limbaje de asamblare. Fiecare modul are propriul sau cod de date si propria sa zona de memorie. Pot fi utilizate codurile din oricare modul, deoarece nu exista nici un mecanism pentru a preveni aceasta. Un argument al acestei utilizari este evitarea dublarii unei secvente de cod sau a unei zone de date, daca acestea exista deja in alt modui. Doua module astfel conectate par a fi un singur modui (figura ).

Fig. Conexiunea prin continut

Conexiunea prin resurse comune a modulelor

Este considerata o varianta mai buna. Fiecare modul are propriul sau cod si propria sa zona de date. Exista unele resurse care pot fi utilizate in comun, folosind atribute ale limbajului, O astfel de conexiune este reprezentata in figura 4.

Fig. 4. Concxiunea prin resurse commit

Conexiunea prin date structurate a modulelor

Se bazeaza pe existenta unei zone de date utilizata in comun (figura 5.5). Modulele implicate in comunicatie trebuie sa 'cunoasca' structure acelei zone, iar informative din module, referitoare la acea zona de memorie, trebuie sa fie compatibile.

Fig. 5. Conexiunea prin date structurate

Conexiunea prin valori ale datelor

Este aplicabila in cazul unor module independente, care pot sa-si transmita unul altuia date printr-un mecanism software (figura 6.). Aceasta este cea mai sigura metoda de comunicare. Datele pot fi modificate la un moment dat numai de citre un singur modul, cel care defineste controlul lor.

Fig. 6. Conexiunea prin valori ale datelor

Conexiunea prin adresele datelor

Se bazeaza pe schimbul valorilor de referina a datelor respective. Modulul care receptioneaza datele foloseste mecanismul de acces prin valori de referinta.

Fig. 7. Conexiunea prin adresele datelor

Aprecierea calitatii descompunerii sistemului in module se poate face prin analiza coeziunii dintre module. Exista urmatoarele forme de coeziune:

Coeziunea incidentala

Se intalneste atunci cand elementele unui modul sunt legate intre ele. Daca elementele unui modul nu sunt legate intre ele, s-a obtinut coeziunea zero, in cazul in care doua secvente diferite de program implica utilizarea unei a treia secvente este rational ca cele doua secvente sa fie cuprinse intr-un singur modul (care o contine si pe a treia), pentru a putea astfel evita scrierea unei secvente de doua ori.

2. Coeziunea logica

Se intalneste in cazul in care un modul este un set de functii separate, dar grupate impreuna din considerente logice. Aceasi grupare este implicate de cerintele sistemului. Situatia este des intalnita la sisteme inglobate.

Coeziunea temporala

Este intalnita in cazut incare elementele unui modul sunt legate de aceleasi valori ale timpului.

Coeziunea procedurala

Se intalneste in cazul unui modul in care fiecare parte a sa este organizata ca o procedura. Toate elementele unei proceduri trebuie sa existe daca se cere sa se realizeze functia ei. Uzual, procedurile sunt utilizate pentru implementarea unor subtaskuri apaitinand unor taskuri mai mari.

Coeziunea comunicationala

Se refera la cazul in care elementele unui modul actioneaza asupra unor date comune. Actiunile efectuate asupra datelor realizeaza conexiunea dintre elemente.

Coeziunea secventiala

Corespunde cazului cand elementele unui modul sunt organizate ca o secventa de operatii.

Coeziunea functionala

Se intalneste in cazul unui modul care realizeaza o singura functie. Acest tip de structura are cea mai mare coeziune deoarece toate elementele sunt esentiale pentru comportamentul modulului.

5. Proiectarea orientata pe obiecte

Un obiect este un bloc de date si de operatii pe care trebuie sa le realizeze in functie de invocare si de starea lui. Obiectul are variabile instantiate si proceduri pentru manevrarea lor, formand o unitate indivizibila. Numai serviciile oferite sunt vizibile in afara obiectului. Implementarea interna a datelor si a serviciilor este ascunsa si bine incapsulata. Fiecare obiect are o zona de memorie unde sunt memorate datele. Ea este alocata la crearea obiectului sau la instantiere. Variabilele stocate in zona de memorie se numesc variabile instantiate si reprezinta parametrii care descriu starea obiectului.

Operatiile de invocare a obiectelor se realizeaza prin schimb de mesaje sau prin apelul unor functii. Un obiect poate transmite altui obiect un mesaj, prin care sa ceara efectuarea unor servicii. Mesajele pot contine:

• diferite tipuri de date simple;
• inregistrari;
• alte obiecte.

Serviciiie efectuate depind nu numai de parametrii transmisi ci si de starea (interna) obiectului. La primirea unui mesaj, sau efectuarea unui serviciu, starea interna a obiectului (adica variabilele instantiate) se poate schimba. Starea interna a obiectului este statica si persistenta de la efectuarea unui serviciu pana la o noua solicitare.

Mesajele sau apelurile de servicii ajung la proceduri simple, care implementeaza metodele care definesc comportamentul obiectului. Obiectul 'alege' care este procedura corecta ce raspunde serviciului solicitat.

Un obiect poate raspunde la un numar limitat de apeluri, care constitute setul serviciilor pe care le realizeaza s.i care definesc comportamentul lui.

Uzual, in cazul programarii obiectuale se foloseste notiunea de clasa care este un sablon cu care pot fi create (sau instantiate) obiecte avand proprietati specificate. O clasa consta din deflnitie, continand una sau mai multe superclase pe care o mosteneste impreuna cu variabilele instantiate si metodele respective. Unele limbaje (precum C++) admit mostenirea multipla, iar altele (precum Java) admit numai mostenirea simpla.

O subclasa incorporeaza toate atributele si metodele superclasei sale. Aceasta includere se poate continua in scopul obtinerii altor clase. Conceptul de mostenire poate fi implementat prin copierea codului. Astfel, fiecare obiect va contine nu numai datele sale proprii ci si codul sau propriu. Aceasta solutie duce la risipirea spatiului de memorie. O alta solutie se bazeaza pe utitizarea in comun a codului, prin legarea dinamica.

Intr-un sistem de timp-real, care din motive de reactivitate trebuie sa aiba mai multe secvente de executie, obiectele trebuie sa fie implementate concurent. Executia concurenta a acestora implica realizarea unei functii de sincronizare. Obiectele se pot sincroniza prin asteptarea unor mesaje sau prin apelurile unor functii de sincronizare. Transmiterea unui mesaj unui obiect sau apelul unei metode dintr-un obiect se poate face numai daca destinatarui este pregatit pentru operatia de schimb de informatit sau de efectuare a metodei.

In limbajele asincrone orientate pe obiecte, mostenirea este implementata prin coduri comune obiectelor. Exista numai un bloc al codului pentru fiecare metoda, iar acest bloc este executat cu variabile instantiate proprii obiectului. Mostenirea si controlul concurentei interfereaza una cu alta creand dificultati de programare. Copierea codului nu presupune controlul dinamic al mostenirii.

Proiectarea orientate pe obiecte implica urmatorii pasi mai semniflcativi:

• specificarea obiectelor si a trasaturilor lor;
• specificarea relatiilor si a legaturilor dintre obiecte;
• definirea interfetei fiecarui obiect si
• implementarea obiectelor.

1. Specificarea obiectelor

Un obiect trebuie sa fie:

• capabil de a reprezenta corect functiile sistemuiui;
• usor de construit;
• simplu de integrat in sistemul global;
• potrivit pentru testare si depanare ca o unitate separata;
• simplu de intretinut si reactualizat.
• in  cadrul obiectelor se aplica principiile mentionate de coeziune,
• conectare, abstractizare s. i ascunderea datelor.

Specificarea relatiilor si a legaturilor dintre obiecte

Din punctul de vedere al controlului exista doua tipuri de obiecte:

obiecte active;

obiecte pasive.

Un obiect activ este acelea care solicita altui obiect (pasiv) efectuarea unei activitati, ii transfera controlul executiei, dar de indata ce activitatea a fost efectuata, solicitantul activitatii reprimeste controlul. Prin urmare, obiecteie active au initiativa efectuarii unor activitati. Activitatile obiecteior active pot fi antrenate de timp sau de evenimente.

Un obiect pasiv efectueaza activitati numai cand un alt obiect (activ sau pasiv) ii solicita aceasta. El nu poate pastra controlul dupa efectuarea sarcinilor. Un obiect pasiv nu este antrenat in mod direct nici de timp nici de evenimente.

Interfetele obiectelor

Un obiect se compune din doua parti:

partea vizibila - care poate fi accesata prin interfata si

partea ascunsa - care nu este accesibila altui obiect decat prin intermediui metodelor obiectului.

Un obiect are proprietati statice care caracterizeaza ce face obiectul si proprietati dinamice care exprima cum isi realizeaza comportamentul.

4. Metoda de proiectare MASCOT

Sistemu! MASCOT (Modular Approach to Software Construction Operation and Test) a fost elaborat initial in Anglia de catre Ministerial Apararii si preluat pentru dezvoltare ulterior, in alte tari ale Comunitatii Europene. El este adoptat nu numai ca metoda pentru proiectarea (in sens restrans) aplicatiilor de timp-real complexe, ci si pentru gestionarea generala a proiectelor software.

Caracteristicile care au determinat utilizarea acestei metode sunt:

definirea unei metode formale pentru reprezentarea structurii programului independent de tipul sistemuiui de calcul si de limbaju! de programare folosit;

utitizarea unei abordari sistematice a proiectarii, bazate pe o structura modularizata;

asigurarea unei corespondente stranse intre elementele functionate de proiectare s.i elementele constructive de realizare; '

incurajarea utilizarii unei strategii de receptionare a programelor bazate pe testarea si verificarea modulelor individuale sau a ansamblurilor de module functional interdependente.

Desi a fost uneori descrisa ca o metoda formala, ea este mai corect caracterizata ca o metoda semiformala. Ea defineste numai un cadru an care sa se lucreze si nu este un limbaj de programare complet. Ramane la latitudinea utilizatorilor sa aleaga mai multe detaiii de proiectare. Ca orice metoda formala, impune constrangeri utilizatorilor asupra ce pot, sau ce nu pot sa faca. Au fost efectuate mai multe studii pentru utilizarea metodei MASCOT in conexiune cu limbajul de programare ADA. Exista o varietate de componente software comerciale care translateaza diagramele MASCOT din forma grafica in reprezentarea lor textuala sau invers.

Sistemele de timp-real sunt uzual partitionate in taskuri cu inalta modularitate, comunicand intre ele sub controlul sistemului de operare. Modularitatea este rezolvata prin partitionarea sistemuiui in componente reutilizabile. Sunt posibile doua abordari ale partitionarii:

• descompunerea functionala;
• modularizarea constructiva.

In descompunerea functionala, un modul este determinat prin identificarea scopurilor cu parti ale sistemului. In modularizarea constructiva, modulele sunt definite respectand partile care pot fi compilate separat. Ele vor fi 'legate' in timpul construirii sistemului. Ideal ar fi ca modutele sa fie definite astfel meat sa existe o puternica corelare intre unitatile functionate si cele constructive.

Abordarea proiectarii sistemelor in timp-real folosind metoda MASCOT implica definirea unui cadru si a unor notatii grafice pentru a permite integrarea in timp-real a activitatii sistemului. O activitate este un proces care este independent de alte activitati si prin urmare poate fi planificat sa fie executat simultan cu alte activitati. Tehnica MASCOT ofera un set util de mecanisme de sincronizare si comunicare care permit dezvoltarea separata a modulelor individuale.

Procedeul are doua reprezentari echivalente: prin diagrame si textuala. In continuare se va dezvolta in special forma de reprezentare prin diagrame si mai putin cea textuala. in locul celei din urma se prefera descrierea folosind retele Petri. Formalismul este folosit pentru determinarea structurii proiectului unui sistem soft. El serveste cu succes la testarea programelor in timpui fazei de dezvoltare si celei ulterioare ei.

Metoda se concentreaza pe reprezentarea concurentei si a fluxului de date (engl.: dataflow), deoarece aceste caracteristici sunt prezente in mediul in care astfel de sisteme sunt inciuse. Un sistem de conducere este compus dintr-un numar mare de senzori, traductoare si eliemente de execute, generind, respectiv consumand date. Ele opereaza in aceiasi timp, prin urmare concurent.

Reprezentarea prin diagrame sau reprezentarea textuala permit descrierea proiectului intr-o forma ierarhizata. Proiectul poate fi dezvoltat de sus in jos (engl.: top-down), de jos in sus (engl.: bottom-up), sau combinamd cele doua metode.

Tehnica MASCOT cuprinde urmatoarele module;

1. specificatii - interfete de acces;

2. sabloane compuse:

sisteme;

subsisteme;

- zone de date pentru comunicare compuse;

servere compuset

- activitati compuse.

sabloane simple

activitati simple;

- zone de date pentru comunicare simple;

- serveri simpli.

Sablonul unui sistem arata cum este structurata colectia de subsisteme, zone de date pentru comunicare, activitati si serveri. Un sistem este considerat un obiect complet in sensul ca nu are conexiuni externe (porturi sau ferestre). El poate interactiona cu anumite dispozitive externe. Se considera ca serverii care controleaza aceste activitati fac parte din structure sistemului. Sistemul se reprezinta prin dreptunghiuri cu colturile rotunjite. Reprezentarea poate sa nu cuprinda detalieri (figura 8) sau sa fie cu detalieri (figura 9.).

Fig. 8. Reprezentarea unui sistem

Fig. 9. Descompunerea unui sistem

Sistemul reprezentat in figura 9 este descompus intr-un numar de subsisteme (subsist1, subsit2 si subsist3) interconectate intre ele, doua dispozitive (disp1 si disp2) hardware In afara, precum si o zona de date pentru comunicare (ZDC; engt.: Intercommunication Data Areas). Conexiunile sunt numite cai (engl.: path) si arata legaturile dintre porturi si ferestre (engl.: windows). Porturile sunt reprezentate prin cercuri mici umplute, iar ferestrele prin dreptunghiuri mici umplute. Fiecare port indica, pentru subsistemul care fl contine, necesitatea utilizarii unei interfete de acces specifice (acelui port). Fiecare fereastra indica, pentru subsistemul care o contine, ca furnizeaza o interfata de acces specifica (acelei ferestre). Datele pot circula fie de la un port la o fereastra, fie invers, fie in ambele sensuri. Controlul fluxului de date este realizat de portul continut in 'cale', folosind o procedura de interfata si de o fereastra realizand o implementare a interfetei. Astfel, exista notiunea de porturi, reprezentand elemente active, adica capabib sa starteze o interactiune. Ferestreie sunt pasive. Ele nu pot starta operatii de schimb de informatii daca nu exista porturi care sa le solicite. Daca o fereastra este conectata cu trtai multe porturi, atunci interacfiunile se pot suprapune in timp. Aceasta duce la accesul concurent la o components avand o fereastra. Interfata procedurala dintre un port si o fereastra este definita de catre un modul separat numit interfata de acces si de catre proceduri cunoscute ca procedure de acces, in descrierea sistemelor si subsistemelor se utilizeaza sabloane (engl.: template) care precizeaza cum sunt construite acestea. S-a utilizat termenul de sablon in loc de modul pentru a accentua ca este reutilizabil. Unele sabloane sunt unice si sunt utilizate o singura data, in trap ce altele vor fi utilizate to mai multe parti ale sistemului, sau chiar in sisteme diferite. Se adauga module cu specifkatii indicand cum sunt interconectate intre ele subsistemele. Fiecare subsistem din diagrams are doua nume asociate lui. Numele marcat in interior desemneaza tipul sablonului, iar numele marcat in afara precizeaza componenta produsa cu acest tip de sablon. Sablonul defineste porturile, ferestreie si tipurile de interfere de acces asociate care constrang conexiunea astfel incat fiecare port trebuie sa fie conectat cu o fereastra care realizeaza o interfata de acces corespunzatoare.

Un port nu poate fi legat la mai multe ferestre, dar la o fereastra pot fi legate mai multe porturi. Prin urmare, o fereastra poate realiza aceieasi servicii pentru mai multe porturi.

Numele atasate porturilor si ferestrelor reprezinta nume locate pentru interactiuni (via interfata de acces). Aceasta permite ca la un sablon sa se poata face distinctie intre cateva interactiuni de acelasi tip, de la o interfata. Interactiunile dintre sabloane depind numai de interfata de acces si deci sunt independente de alte sabloane.

Un subsistem este o colectie de activitati, zone de date pentru comunicare, served si alte subsistence, formand impreuna o diviziune logica a unui sistem. Subsistemele comunica intre ele prin intermediul porturilor si ferestrelor. Activitatile si zonele comune de date pentru comunicare pot fi considerate ca fiind cazuri speciale de subsisteme. Descompunerea sistemului continua prin definirea detaliilor interne ale fiecarui subsistem (bloc). Unele dintre aceste blocuri (activitati, ZDC-uri si serveri) pot fi descompuse in continuare.

Un subsistem poate fi activ si poate implica concurenta. Subsistemele sunt reprezentate prin dreptunghiuri cu colpjrile rotunjite. Reprezentarea poate sa nu cuprinda detalii, precum cea din figura 10, sau sa contina detalieri ca din figura 11.

Fig. 5.10. Reprexentarea unui subsistero Fig. 5.11, Descompunerea unui subsistem

Activitatile sunt reprezentate prin cercuri (ca ace la din figura 5.11 notat cu activ). Acestea sunt unitati de baza ale executiei concurente intr-un sistem MASCOT. Ele sunt considerate ca avand initiativa, in sensul ca pot efectua actiuni inaintea receptionarii unui mesaj care sa solicite aceasta. ActivitStile sunt programate separat. In interior ele vor fi programate secvential si cuprind numai date care nu sunt 'vizibile' pentru alte activitati. Activitatile pot avea porturi pentru a putea comunica cu zone de date pentru comunicare sau serveri, dar nu pot avea ferestre.

Activitatile compuse pot fi descompuse, in etape uiterioare, fn activitati simple. O astfel de activitate compusa poate cuprinde o radacina (engl: root) si una sau mai multe subradacini (engl.: subroots)

Fig 12. Descompunerea unei activitati

Diagrama din 'figura 12 reprezinta o astfel de activitate compusa. Radacinile si subrada-cinile folosesc forme distincte de interfete procedurale. Se observa in figura reprezentarea distincta a interfetelor de subradacini. Se accepta existenta porturi ior cuprinse in subradacini si a unor porturi comune mai multor subradacini. In general, nu se poate deduce din reprezentarea unei activitati ordi-nea in care sunt activate porturile. O activitate compusa are un singur fir de executie. Intre radacina si subradacini, sau intre subradacini, exista legaturi (si nu cai) aratand ierarhia apelurilor. Radacina si subradacinile lucreaza asemanator cu un program principal si subrutineie sale din prograraarea convemionala (figura 5.12).

Zonele de date pentru comunicare (ZDC) se reprezinta in diagrame prin dreptunghiuri precum in figura 1

Fig 13 Reprezentarea unei zone de date comune

S-au notat cu w_h, w₄ interfere de acces. ZDC-urile sunt utilizate pentru memorarea si transportul datelor intre activitati. Ele pot avea ferestre pentru comunicare. O fereastra poate fi conectata cu unul sau mai multe porturi. O ZDC poate avea si porturi, pentru a putea comunica cu alte zone de date pentru comunicare. Structurile ZDC pot accepta accesul concurent la date. Ele sunt pasive adica executa numai raspunsuri la apelul unei proceduri de acces. Datele cuprinse in blocuriie ZDC sunt statice.

Ele sunt ini|ializate mainte de inceperea executiei si raman pe toata durata existentei sistemuiui. Se cere sa se proiecteze sistemul astfel meat sa se asigure integritatea lor in timpui accesului concurent.

Exista doua subclase de ZDC-uri: canale (eragl: chanels) si depozite ..: pools).

Fig. 14 Reprezentarea unui depozit

Un depozit se reprezinta ca in figura 14. El este un spatiu de memorie unde sunt refinute dateie pentru a fi utilizate de catre una sau mai multe activitati. Esenfial este cS datele nu sunt consumate in urma citirii, prin urmare citirea dintr-un depozit este nedistructiva, }n timp ce scrierea este distructiva, Un depozit are o fereastra prin care comunica cu iumea exterioara lui.

Fig 15.

Un canal (vezi figura 15) este utiiizat pentru comunicarea intre activitati pe principiul producator -consumator. Un canal are (uzual) doua interfete unidirectionale, una pentru introducarea datelor (patch) si alta pentru extragerea lor (getch), Ele se impiementeaza prin intermediul ferestrelor. Scrierea intr-un canal este nedistructiva, dar citirea din el este distructiva. Un canal este caracterizat de o constanta intreaga nmax care reprezinta capacitatea canalului. Depasirea acestei capacitaji duce la suprascriere, deci

scrierea devine distructiva in acest caz. Scrierea si citirea se efectueaza dupa metoda primul introdus, primut extras (FIFO).

Fig. 16. Descrierca utilizarii unui canal

Figura 16 reprezinta o structura tipica de utilizare a unui canal intre doua activitati A sj B.

Sunt acceptate si alte structuri precum cele din figurile 17 si 18. Desi aceste structuri par a fi echivalente, totusi fntre ele exists o mare diferenta func|:ionala. Daca in cazul din figura 17 activitatea D preia prima data introdusa in canal (indiferent care dintre activitatile A, B sau C au efectuat operatia), pentru figura 18 activitatea D poate alege care dintre canale sa fie utilizat mai intai pentru preluarea unei date, Celelalte date urmeaza s3 fie preluate in secvenfeie ulterioare. Daca datele nu sunt disponibile la un anumit canal, se poate inrautati performanta sistemuiui.

Fig.17. Utilizarea multipla a unui canal Fig. 18. Conexiunea dintre mat multe activitati

In figura 19 se propune o alta solutie pentru problema ridicata anterior. Blocul ZDC este responsabil pentru rezoivarea problemei intercomunicarii. Daca este necesar acest bloc ar putea implementa si o procedura care nu este de tip FIFO.

Fig. 3,19. Reprezentarea generala a conexiunii dintre mat multe activitati

Un server (a se vedea figura 20) este un modul care interactioneaza cu lumea exterioara.

Fig. 3,20

El poate trata intreruperi de la dispozitive hardware si poate comunica cu celelalte elemente dintr-o structura MASCOT. Serverii pot cuprinde atat porturi cat si ferestre. Serverii (avand

reprezentarea in forma de D) realizeaza controlui interactionarii cu dispozitivele hardware. Ei contin subrutine pentru tratarea intreruperilor de la dispozitive si pentru transformarea codurilor, astfel incat sa se poata comunica cu dispozitivele cu care surtt in conexiune.

Elaborarea programelor prin metoda MASCOT se divide in 6 etape.

Etapa 1. Cerinte si constrangeri

Se stabilesc cerintele generate si constrangerile externe,

Etapa 2. Propunerea unui proiect

La nivelul superior se construieste o propunere pentru un proiect, care sa respecte cerinteie si constrangeriie externe. Fiecare componenta este specificata prin termenii functiei sale si a modului in care contribute la proiectul general.

Etapa Descompunerea sistemului

Se continua cu elaborarea progresiva a eiementelor componente specificandu-se activitatile, ZDC-urile si serverii. Fiecare componenta trebuie precizata tinand cont de datele de irrteractiune. Se descriu porturile si ferestrele etementelor.

Etapa 4. Descompunerea elementelor

Proiectarea continua cu descompunerea fiecarei activity compuse identificate in etapa anterioara. Se precizeaza fiecare radacina si subradacina, interactiunile cu alte subradacini si porturile activitatilor.

Etapa 5. Programarea

Se detaliaza specificatiile fiecarui tip de interfata, iar algoritmul fiecarui sablon este codificat foiosind interfetele definite.

Etapa 6. Integrarea si testarea

Se compileaza si se testeaza mai intai componentele simple, apoi se testeaza retelele. sabloaneie compuse se testeaza fiecare imparte folosind reteaua sa specifica.