Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  


AccessAdobe photoshopAlgoritmiAutocadBaze de dateC
C sharpCalculatoareCorel drawDot netExcelFox pro
FrontpageHardwareHtmlInternetJavaLinux
MatlabMs dosPascalPhpPower pointRetele calculatoare
SqlTutorialsWebdesignWindowsWordXml

STUDIU APROFUNDAT AL METODOLOGIILOR DE ELABORARE A SISTEMELOR INFORMATICE

calculatoare

+ Font mai mare | - Font mai mic



DOCUMENTE SIMILARE

Trimite pe Messenger
PROIECT BAZELE PROGRAMARII PE OBIECTE
Schimbarea dimensiunii unui proces
Porturi
Importanta informaticii ca stiinta
Retele de calculatoare. Internet
SISTEMELE DE OPERARE
9 PASI PENTRU A APLICA PATCH-URILE CU Setool
MANUAL ASAMBLARE CALCULATOR
World Wide Web
SHDSL


STUDIU APROFUNDAT AL METODOLOGIILOR DE ELABORARE A SISTEMELOR INFORMATICE

Metodologia MERISE - un exemplu de corelare a

ciclului de dezvoltare cu nivelul si cu viziunea asupra sistemului



In cursul precedent am vazut ce este ciclul de dezvoltare de sisteme si am amintit despre modelare si modelul informational. Acum trebuie sa remarcam ca nivelul de la care privim sistemul informational difera de la o etapa la alta a ciclului de dezvoltare de sisteme, iar modelul sistemului informational evolueaza de la o etapa la alta reflectand nivelul de la care privim sistemul informational. Astfel, daca ar fi sa ne referim la etapele metodei Merise, ar trebui sa distingem un nivel global (asociat studiului de evaluare) si apoi nivelele conceptual, organizational, logic si fizic, carora le vor corespunde modelele global, conceptual, organizational, logic si respectiv modelul fizic. Aceasta evolutie a modelulului sistemului informational spre un model de sistem informatic este continua si logica, in sensul ca fiecare din modelele de mai sus, n-ar putea fi construit daca nu avem definitivat modelul etapei precedente.

A sti sa proiectam sisteme informatice indeamna sa stim CE si CUM trebuie facut in cadrul fiecarei etape a ciclului de dezvoltare de sisteme pentru ca sa obtinem modelul specific acelei etape, iar raspunsul la aceste intrebari il ofera metodologiile.

Pentru a realiza o modelare eficienta a sistemului informational, agentii (persoanele care joaca un rol oarecare intr-un proces ce trebuie modelat) ca si entitatile care opereaza in sistem ( de exemplu documentele de intrare), trebuie implicate in model impreuna cu functiiile pe care le indeplinesc, cu comportamentul lor si cu datele referitoare la ele.

Prin comportament in cazul agentilor se intelege ceea ce fac ei in anumite imprejurari in contextul functiilor lor, iar in cazul documentelor de intrare – se intelege ce efecte au ele (in contextul fluxului in care sunt implicate) asupra datelor.

In ce priveste datele, exista date care determina starea agentilor sau entitatilor, date de care au nevoie pentru a-si indeplini functiile (respectiv procesul in care sunt implicate) si date pe care le modifica sau le produc prin activitatea lor.

Diversitatea metodelor de abordare a sistemelor informationale are de a face si cu nevoia de a surprinde functiile, comportamentul si datele implicate in sistem, in sensul ca unele metode surprind mai usor functiile, altele redau mai usor comportamentul, iar altele evidentiaza mai bine datele. Daca am imagina un spatiu cu cele trei dimensiuni ce caracterizeaza o entitate (functia, comportamentul sau datele de care este legata), atunci pozitia oricarei entitati in acest spatiu va depinde de ponderea pe care o au in existenta acelei entitati, functia, comportamentul si datele de care este legata.

Cand analistii incep sa studieze un sistem informational, in vederea trecerii acestuia pe calculator, ei trebuie sa identifice care este trasatura dominanta a sistemului (coordonata cu valoarea cea mai mare) si sa aleaga metoda de abordare, respectiv metodologia cea mai potrivita.

Odata aleasa metoda de abordare a sistemului informational, ar trebui identificat ciclul de viata al dezvoltarii sistemului (ciclul asociat metodologiei respective), asa cum apare el in literatura de specialitate si ar trebui sa efectuam operatiile specificate in cadrul metodologiei, pentru fiecare etapa.

Am precizat mai sus ca de fapt in cadrul fiecarei etape, metodologia precizeaza CE si CUM trebuie facut. Pentru a preciza CE trebuie facut, in metodologie sunt enumerate obiectivele urmarite in cadrul fiecarei etape, iar pentru a preciza CUM trebuie facut, este precizata forma sub care se considera ca se poate prezenta fiecare din aceste obiective, in cadrul documentatiei de faza. Uneori aceasta forma de prezentare poate fi una grafica, dar nu una oarecare ci respectand forme si inscrisuri tipizate, prevazute in metodologie. O astfel de forma tipizata se formalism.

Formalism, in sensul de mai sus, inseamna un set de definitii si reguli, combinat cu un set de tipuri de diagrame si/sau de tabele. Cele mai sofisticate formalisme le contine metoda Merise, dar si diagramele de flux ale datelor (DFD) sau cele de tip entitate_relatie (DER) sunt tot niste formalisme.

Numai dupa ce proiectantul aplica situatiei concrete, oferita de sistemul analizat, formalismul specific etapei, el poate indeplini cerintele de proiectare privind documentatia de faza.

Documentatia de faza are pe de o parte rolul de a valorifica constatarile etapei curente pentru a putea fi folosite ca punct de plecare pentru etapa urmatoare, iar pe de alta parte ea are si un rol comunicativ in relatia cu beneficiarul pentru ca prin consensul dintre proiectant si beneficiar, proiectantul are garantia ca a inteles cerintele beneficiarului si va realiza un sistem care sa satisfaca aceste cerinte. Legat de acest aspect, documentatia de faza mai are si o utilitate juridica, in sensul ca poate constitui baza legala pentru plata muncii efectuate de proiectant, iar in caz de litigii ulterioare intre proiectant si beneficiar, documentatia de faza poate constitui un factor care inclina balanta in favoarea uneia sau alteia din parti, dupa cum situatia din teren corespunde sau nu cu ceea ce s-a aprobat de catre beneficiar prin avizarea documentatiei de faza.

Avizarea documentatiei de faza are loc inainte de a se trece la faza urmatoare.

Revenind la ideea de a realiza sistemul informatic numai prin simpla traducere in viata a specificatiilor privind CE si CUM trebuie facut in fiecare etapa a CVDS, trebuie spus ca din nefericire, lucrurile nu sunt atat de simple si aceasta pentru ca foarte rar ciclul de viata al dezvoltarii sistemului informatic se deruleaza secvential si o singura data. De cele mai multe ori ciclurile se reiau din diferite puncte si uneori chiar de mai multe ori si din puncte diferite, ducind la aparitia unor modele ale ciclurilor de viata. Cu alte cuvinte ciclurile de viata difera odata de la un mod de abordare la altul, ceea ce se concretizeaza printr-o anumita structura a etapelor ciclului de dezvoltare (structura materializata printr-un anume numar de etape si succesiune), dar apoi ele difera si de la un model la altul al ciclului de dezvoltare, prin modul cum vor fi reluate si repetate anumite faze. Motivul pentru care se complica lucrurile in acest fel este acela ca de cele mai multe ori, prima varianta a softului produs initial nu este satisfacatoare.

Cauzele acestei situatii sunt multiple. Iata doar cateva dintre ele:

- pe timpul elaborarii unei variante, in sistemul analizat pot sa intervina schimbari de structura sau de functionare;

- este mai greu sa perfectionezi o aplicatie care inca nu functioneaza, aflata doar pe hartie, decat una care a inceput sa functioneze; ca urmare incepem cu ceva care urmeaza a fi perfectionat;

- cand am dat primul program in functiune, incepem sa comunicam mai bine cu beneficiarul; s-ar putea ca el sa constate ca n-a fost bine inteles, sau ceea ce a cerut nu era ceea ce dorea.

Cele mai reprezentative modele ale ciclurilor de viata sunt urmatoarele: modelul cascada, modelul V, modelul incremental, modelul spirala, modelul evolutiv, modelul piramida (specific ingineriei informatiei orientate-obiect).

In sectiunea 2 sunt prezentate in detaliu cele mai reprezentative modele ale ciclurilor de viata.

Presupunand ca am identificat elementul care va fi supus analizei (functie, proces, date, obiecte, etc.), adica am ales orientarea si am ales si modelul ciclului de dezvoltare, deci avem o secventa clara de faze ce trebuie parcurse pentru a realiza sistemul informatic, am putea trece la indeplinirea activitatilor prevazute pentru fiecare etapa, numai ca inainte de aceasta urmeaza sa mai luam in calcul inca un element: viziunea (view) sau aspectul pe care-l analizam la un moment dat pentru a realiza abstractizarea impusa de modelare, adica pentru a elabora modelul informational. Inainte de a explica ce este viziunea, merita sa remarcam ca spre deosebire de alte entitati cu care operam in viata cotidiana sistemele informatice implica mai multe puncte de vedere (views). Asa de exemplu un motor poate fi privit din punct de vedere al principiului de functionare, al componentelor sale majore, deci a subansamblelor sale si cam atat, in timp ce sistemul informatic implica si forme abstracte si mai ales forme abstracte si aceasta pentru ca el nu este realitatea pura ci este o abstractizare a realitatii.

Viziunea este legata de faptul ca sistemul informational se va materializa sub forma a cel putin patru aspecte diferite la care va trebui sa facem referire in fiecare din etapele CVDS. Cu alte cuvinte o etapa se considera parcursa daca pe timpul sau am facut referirile ce se impun la urmatoarele aspecte:

- descrierea si definirea elementelor aditionale si auxiliare specifice etapei;

- comunicatii implicate in sistem;

- datele ce se vehiculeaza in sistem;

- prelucrarile specifice fiecarei etape;

Cu etapele ciclului de dezvoltare dispuse pe verticala si cu aspectele sau viziunile enumerate mai sus, dispuse pe orizontala (sub forma unui cap de tabel), am putea obtine o matrice pe care s-o completam cu activitati sau obiective ce trebuie atinse in fiecare etapa CVDS, pentru fiecare aspect sau viziune. De regula matricea (un rezultat al interferentei dintre etapele CVDS si viziuni) este completata de catre cei care au elaborat metoda cu obiective (mai exact cu CE trebuie facut in cadrul fiecarei etape). Partea privitoare la CUM trebuie facut, este una descriptiva si prea voluminoasa pentru a fi inclusa in matrice. Un exemplu de astfel de model tabelar este matricea oferita de metoda Merise. Cat priveste nivelul de la care privim aceasta matrice, acesta ar putea constitui o a treia dimensiune, ceea ce ar insemna aparitia unui cub! Un asemenea exemplu se intalneste la modelul propus de CIMOSA – un cunoscut concept de arhitectura de referinta. De fapt si autorii metodei Merise au introdus un CVDS pe trei dimensiuni, dar a treia dimensiune este nivelul decizional cu privire la mersul proiectului (ceea ce nu a prins la specialisti!)

In ce priveste nivelul de la care se face analiza sistemului, in cadrul metodei Merise, acesta poate fi reprezentat de-a lungul axei etapelor CVDS, in sensul ca un nivel va cuprinde cel putin una din etapele CVDS, astfel ca pe latura verticala a matricii putem materializa atat etapele CVDS cat si nivelul la care trebuie vazut sistemul.

Pentru ilustrarea interferentei dintre metoda, CVDS, nivel si viziune prezentam mai jos matricea Merise completata nu cu obiective de studiat, ci cu conceptele specifice fiecarei etape, la nivelul corespunzator, pentru fiecare viziune sau aspect. Aceste tabele sunt utile numai pentru a surprinde mai usor interferenta tuturor aspectelor ce trebuie avute in vedere pe timpul proiectarii sistemelor informatice, dar indicatiile metodologice concrete sunt prea voluminoase pentru a fi stocate intr-o matrice.

In practica, activitatile dintr-un astfel de tabel ar trebui detaliate si comentate pe parcursul a catorva capitole. De regula fiecare etapa CVDS este tratata pe cate un capitol.

Cu privire la diversitatea modelelor ciclurilor de viata, trebuie sa tragem urmatoarele concluzii:

- modelele sunt diferite, in functie de tehnologiile folosite in procesul de realizare a sistemelor; un salt considerabil se observa in mediile orientate-obiect;

- modelele depind de marimea proiectelor dar si de domeniile de care apartin sistemele;

- la alegerea unui model trebuie sa tinem seama nu numai de ordinea in care se deruleaza etapele de elaborare a sistemului, ci si de proportia in care modelul presupune abordarea sistemului, adica pe parti sau global. Unele modele cum ar fi cel in cascada, presupune parcurgerea tuturor etapelor la nivelul intregului sistem, in timp ce modelul evolutiv de exemplu, permite derularea marii majoritati a etapelor pe parti/componente ale sistemului;

- alegerea modelului va depinde si de experienta echipei ce efectuiaza proiectarea sistemului;

Viziuni

Nivele Etape

Descrieri si

definitii

auxiliare

Comunicatie

Date

Prelucrari

Nivel

global

Studiu

de evaluare

DDG

- obiectivele sistemului informational (SI)

- functiile specifice

- atributele conducerii

MGC

- aspecte si principii generale ale comunicatiei asociate special pentru SIO, SII si SIG

MGD

-solutii previzibile

- date

- cunostinte

- organizarea posibila

- BD, BT, BC

- combinatii

MGP

- tip

- topologie

- amplasare pentru:

- prelucrari

locale;

- teletransmisie

- retele de

calculatoare

Nivel

con-cep-

tual

Proiectare

concep-

tuala

DDC

- domeniile activitatii

- documente de intrare

- situatii de iesire

- indici sintetici

- grafice

- algoritmi

-sisteme de comunicare

MCC

-servicii functionale (actori)

-fluxuri informationale

documente,

situatii folosite

MCD

- entitate/tip

entitate

- relatie/tip

relatie

-proprietate/tip

proprietate

- cardinalitate

(maxima, minima)

MCP

- proces

- operatie

- eveniment

- sincronizare

- reguli de gestiune

Nivel

organi-zatio-nal

Proiectare

organiza-

tionala

DDO

- corelatia date –

prelucrari –

comunicari

- grila de coerenta globala: MCD–MOD

MCD –MOP

-reguli de prelucrare

-algoritm de validare

MOC

-comunicatii manuale/auto-mate/mixte

comunicatii intre:

- compartimente

- compartimente-

conducere

- unitate- alte unit.

MOD

- tipul proprietatilor

- numar de inregis-trari pentru entitati si relatii

- cardinalitate (maxima, maxima la 95%, modala, medie)

- tip de acces

(creare, adaugare, modificare, stergere)

MOP

- repartitia organizatorica a proceselor de prelucr. pe:

compartimente posturi de lucru

sarcini/faze

grad de auto-

matizare (manual, automat, mixt)

- mod de functionare

Nivel

logic

Proiectare

logica

DDL

- dictionarul datelor

- descrierea BD/BD/BC

- ordinea de prelucrare a Bd/BT

MLC

lista serviciilor implicate

- corelatia servicii - docu-mente - situatii

- organizarea generala a co-municatiei de date si prelucrari

MLD

MLP

- lista de reguli

- lista module

- lista comparti-

mente;

- lista sarcini;

- lista evenimente;

- lista tabele

model

relational

spread

sheet

- entitate

- dependenta functionala

- cheie primara externa

- tabela

- celula

- zona de celula

- depen-

denta

functionala

- cheie primara

secundara

Nivel

fizic

Proiectare fizica

Implemen-tare

DDF

- SO, SGBD, SGBT, GSE

- meniuri de prelucrare

- videoformate de I/E

-tranzactii de: I, E, I/E

MFC

- lista echipamente

- rolul si functiile FS si WS

- protocoale de comunicatie

- parole de acces

-drepturi de prelucr.

MFD

MFP

- procedura

- subprocedura

- model

- aspect:

- functional

- semantic

- timp real/diferit

BD

BT

tabela

- atribut

- tuplu

- cardinalitate

- dimens.

- cheie

indexar

tabela

- celula

- tuplu

- cardinalitate

- dimensiune

Exploa-tare

Exploatare crt.

Intretinere

Dezvoltare de noi versiuni

DDE

definitii asociate

RC si RD

- elemente aditionale pentru RC

RC/RD

- topologie RC

- topologie RD

BD

BT

BD

BT

- volume alocate

(C:, ………..Z:)

- cataloage folosite

- identificatori

(*.dbf, *.xls)

- volume alocate

(C:, …….Z:)

- cataloage folosite

- identificatori

(*.prg, *.exe, *.xlm

- cerintele functionale isi pun de asemenea, amprenta pe tipul de model; sistemul poate fi abordat in intregime sau pe componente functionale;

- complexitatea sistemului se va reflecta in mare masura in tipul modelului selectat.

In afara de aspectele a caror interferenta in cadrul procesului de analiza si proiectare a sistemelor informatice a fost analizata mai sus, mai exista si alte aspecte a caror interferenta nu poate fi formalizata, dar trebuie luata in calcul de proiectantii de sisteme informatice. Este vorba de noutatile care s-au inregistrat in informatica pe planul tehnicilor de programare, a retelelor de calculatoare si mai ales in domeniul CASE.

In cursul precedent au fost enumerate cateva instrumente CASE asociate principalelor metodologii de elaborare a sistemelor informatice. Este bine ca atunci cand ne hotaram sa aprofundam o metodologie de elaborare a sistemelor informatice, sa ne informam daca dispune de instrumente CASE si daca acestea sunt accesibile. Bineinteles ca orice metodologie poate fi aplicata si fara a dispune de instrumentele CASE asociate acelei metodologii, dar daca se poate sa folosim si instrumentele CASE ritmul de munca va fi mult mai mare.

2. Modele reprezentative ale ciclurilor de viata ale dezvoltarii de sisteme (Optional)

Modelul cascada. Asigura trecerea de la o etapa la alta, in ordine secventiala.

Definirea

cerintelor

Analiza

Proiectarea

Implementarea

Testarea

Utilizarea si

intretinerea

Fazele sunt structurate pe activitati si subactivitati. Punctul sau slab este ca se aplica la nivel sistem si nu se poate trece la etapa urmatoare pana ce nu au fost aduse la zi toate aplicatiile; in practica se solicita decalaje intre aplicatii.

Modelul V. Latura din stanga este cea de la modelul cascada, iar pe cea din dreapta se realizeaza verificarile si validarile. Ea se parcurge ascendent.


Definirea

cerintelor

Proiectare Testare

sistem sistem

Proiectare Testare

subsistem subsistem

(componenta) (componenta)

Codificare

asamblare componente

Modelul incremental. Permite livrarea sistemului pe componente, dar si global. Definirea cerintelor si analiza se executa totusi la nivelul intregului sistem.

Este o metoda de tip top-down, ceea ce implica cunoasterea si formularea cerintelor pentru intregul sistem inca din faza encipienta de abordare a sistemului, chiar daca ulterior se vor rezolva doar parti din el. De regula adaugarea unei parti presupune testarea a tot ce este realizat pana in acel moment, ceea ce poate duce la modificari multiple ale componentelor realizate printre primele.


Definirea Proiectare Instalare

cerintelor componenta-1 componenta-1

Analiza Implementare Intretinere

componenta-1 componenta-1

Arhitectura --- ---

sistemului

Proiectare Instalare

componenta-n componenta-n

Implementare Intretinere

componenta-n componenta-n

Modelul spirala. Este modelul cel mai des folosit in toate domeniile proiectarii, acolo unde este vorba de obiective complexe.

Modelul realizeaza validarea cat mai devreme posibil, de cat mai multe ori, prin construirea prototipurilor, ca in figura din stanga.

Tine seama de natura iterativa a dezvoltarii si ia in consideratie nevoia de planificare si evaluare a riscurilor fiecarei iteratii.

Necesita profesionalism, flexibilitate in actiune, in alocarea de fonduri si in definirea activitatilor de intreprins.

 


Prototip-1

Prototip-2

Prototip-3

Prototip-4

Modelul evolutiv. Necesita efectuarea unei investigatii initiale pe baza careia sa se poata elabora o strategie de descompunere a proiectului in parti/segmente, fiecare cu o valoare deosebita pentru client.

Acestea sunt sunt realizate si livrate in mod iterativ si contribuie la sporirea

treptata a performantelor sistemului. Se are in vedere posibilitatea aplicarii unor

adaptari sau modificari ulterioare.

Studiul initial  Integrare

Descompunere  segmente

in segmente

Segment-1 Segment-2

Definire cerinte Implementare  Definire cerinte Implementare

Analiza Testare  Analiza  Testare

Proiectare  Utilizare Proiectare Utilizare 

Metoda are succes deoarece se bazeaza pe o arhitectura deschisa, flexibila, elaborata prin participarea tuturor partilor interesate, inclusiv a utilizatorilor si a unor specialisti profesionisti.

Modelul X. In partea de sus a X-ului este aplicat modelul cascada si V, iar in partea de jos sunt avute in vedere actiuni de valorificare a softului creat anterior. Aceasta preocupare este din ce in ce mai extinsa pe plan mondial si pare foarte rationala deoarece softul prezinta o mare suplete in ce priveste adaptarea de la o problema la alta. De fapt nu conteaza decat asemanarea structurilor, semnificatia variabilelor fiind la libera alegere a celui care foloseste softul.

In partea de sus, modelul ia in consideratie utilizarea unor specificatii de sistem, a proiectului arhitectural si de detaliu , codificarea, testarea pe componente, integrarea si testarea sistemului. Parte inferioara a X-ului este un V intors, pentru a sugera notiunea de gestiune patrimoniala a depozitelor reutilizabile la nivel componenta, structura, domeniu si chiar aplicatie.

Avand in vedere ca partea inferioara a modelului se aplica practic doar in fazele de proiectare fizica, modelul - ca si modelul tridimensional al autorilor metodei Merise, nu este prea popular. Dealtfel metoda Merise mai prezinta un model in doua dimensiuni in care pe abscisa este trecut sistemul actual si cel viitor, iar pe ordonata sunt trecute nivelele global, conceptual, organi-zational, logic, fizic si de exploatare, dar dupa cum s-a putut vedea, din cele prezentate in sectiu-nea 1 a acestui capitol, metoda Merise este aplicata de fapt pe un model in doua dimensiuni, sub forma de matrice care este foarte riguros si se preteaza la exigentele ingineriei softului.

3. Automatizarea dezvoltarii sistemelor prin instrumente CASE

Acronimul CASE vine de la de la Computer Aided System Engineering si are ca obiectiv punerea in practica a produselor- program de proiectare si realizare a softului cu ajutorul calculatorului. Instrumentele oferite de CASE (ca de exemplu EXCELERATOR, aparut pe la mijlocul anilor '80), sunt utilizabile din faza de definire a cerintelor pana la intretinerea fizica a sistemului informatic, dar prioritate au analiza si proiectarea bazate pe conceptele si metodele structurate. In ultimii ani, acestora li s-au adaugat analiza, proiectarea si programarea orientata pe obiecte. Instrumentele CASE implica utilizarea calculatorului ca mijloc de sustinere a activitatilor de planificare, definire, proiectare si realizare a softului. Ele se bazeaza pe logica structurata, pe descompunerea functionala si reprezentarea prin diagrame a fluxurilor de date ale aplicatiilor.

Mijloacele CASE realizeaza proceduri si metode ce prezinta diferente majore fata de metodele clasice si care se constituie in performate ale acestor produse, cum ar fi:

- prezentarea logicii de proiectare a sistemului;

- posibilitati de vizualizare a datelor;

- sprijin in definirea obiectivelor;

- definirea si utilizarea unor termeni de referinta;

- folosirea unui depozit partajat de date;

- usurinta efectuarii unor schimbari;

- realizarea unei documentatii flexibile si dinamice;

- aplicarea unor reguli de verificare a consistentei;

- folosirea reprezentarilor grafice simple;

- construirea de pseudocoduri structurate;

- sprijinirea modularizarii;

- folosirea pe scara larga a prototipurilor;

- constituirea unei interfete pentru generatoarele de coduri;

- construirea bibliotecilor de module si documente.

Pe masura evolutiei lor, sistemele CASE au devenit mai complexe, permitand ca procesele de proiectare si realizare a aplicatiilor sa se desfasoare intr-un mediu informatic interactiv, oferind utilizatorilor un intreg arsenal de instrumente si proceduri, prin care pot proiecta, realiza, testa, documenta, intretine/actualiza si exploata sistemul.

Utilizarea sistemelor CASE a inceput cu introducerea diagramelor fluxurilor de date, care fac posibila realizarea unui model al derularii proceselor sistemului/aplicatiei care se proiecteaza. A urmat folosirea dictionarului de date ca un depozit al tuturor datelor privind sistemul sau aplicatia Au aparut ecranele predefinite pentru a prezenta ce poate sa obtina utilizatorul prin exploatarea sistemului. S-a apelat la facilitati grafice, care pot folosi simbolurile logicii structurate si care permit proiectantului sa realizeze o diagrama coerenta a fluxurilor de date.

Primele sisteme CASE erau un set de aplicati neintegrate, cu functii distincte, fara a fi interconectate. Aceste limite au fost eliminate, in cea mai mare parte, prin generatiile actuale, care incearca sa realizeze o integrare completa si usoara a tuturor elementelor, integrarea reprezentand de fapt, factorul cel mai imoprtant al metodologiei CASE.

CASE se bazeaza pe doua functii fundamentale:

- prima este bazata pe posibilitatea descompunerii de sus in jos (top-down) a sistemului informatic in procese si module distincte, fiecare avand definite responsabilitatile functionale si/sau operationale; odata cu orientarea spre obiecte, functiile se inlocuiesc cu obiectele care indeplinesc functia, ceea ce usureaza controlul procesului;

- a doua se refera la faptul ca sistemele informationale pot fi reprezentate intr-o forma grafica concisa, folosind cateva simboluri de baza

Importanta acestor functii rezida in posibilitatea utilizarii modularitatii aplicatiilor, a diagramelor, obtinerea unei documentatii privind realizarea, evaluarea arhitecturii si utilizarea sistemului.

Pentru definirea si construirea sistemelor, produsele CASE presupun stabilirea si respectarea unei anumite discipline. Metodologia ofera o interfata intre crearea si verificarea/validarea proiectului logic, dezvoltarea unei biblioteci cu documentatii, care include si integreaza caracteristicile proceselor si pasii de parcurs, pentru descrierea modului de lucru; ofera un model al produsului final, ce poate fi folosit in realizarea operatiilor de exploatare si intretinere a sistemului/aplicatiei si ofera o interfata pentru pastrarea evolutiei proiectului.

Folosirea reprezentarilor grafice in logica CASE ofera posibilitatea descompunerii aplicatiei in mai multe componente logice.

Prin atasarea unei baze de date la elementele grafice, se va obtine un depozit ce va contine pasii si functiile reprezentate in diagramele construite. Daca aceste elemente sunt corect stabilite, ele vor sta la baza descrierii proceselor, ce vor constitui procedurile de prelucrare a sistemului /aplicatiei.

Modelarea grafica in sistemele CASE prezinta o interactivitate ridicata, permitand construirea diagramelor, deplasarea de la o diagrama la alta , modificarea, extinderea, copierea, evaluarea si descrierea elementelor unei aplicatii. Modelele grafice permit conectarea fluxurilor logice intre activitatile si functiile specifice aplicatiei, relatii care pot fi testate si validate in mod automat.

Din punct de vedere al momentului in care a avut loc automatizarea fazelor din ciclul de viata al sistemelor, se considera ca analiza si proiectarea reprezinta faze superioare, adica au fost automatizate mai recent. Instrumentele CASE referitoare la aceste faze se numesc Upper CASE sau Front End, iar cele referitoare la fazele care au fost automatizate primele se numesc Lower CASE sau Back End.

C

A

S

E

V

E

R

T

I

C

A

L

U

P

P

E

R

C

A

S

E

- analiza cerintelor sistemului/programului;

- descrierea sistemului;

- proiectarea si modelarea functionala si procedurala;

- modelarea datelor si proiectarea bazei de date;

- generarea de coduri.

F

R

O

N

T

E

N

D

C

A

S

E

P

R

O

P

R

I

U

-

Z

I

S

L

O

W

E

R

C

A

S

E

- editoare, de regula folosite de limbaje de programare;

- instrumente de folosire a codurilor si modulelor;

- instrumente de referinta incrucisata;

- mijloace de testare;

- instrumente de analiza a rezultatelor;

- depanare coduri.

B

A

C

K

E

N

D

O

C R

I

A Z

O

S N

T

E A

L

- instrumente pentru managementul proiectelor;

- mijloace de documentare;

- mijloace de gestionare a configuratiei;

- instrumente de revizuire a cerintelor.

Clasificarea instrumentelor CASE

Pentru ca exista instrumente CASE care nu pot fi legate de fazele ciclului de viata a dezvoltarii de sisteme, cele din categoria Upper si Lower CASE sunt denumite CASE Vertical, iar celelalte se numesc CASE Orizontal

Clasificarea instrumentelor CASE este data in tabelul de pe pagina urmatoare.

Caracteristicile mediilor moderne de tip CASE:

- reprezinta un set de instrumente specifice pentru realizarea sistemelor;

- diversitatea modurilor de interactiune;

- semnificatia reprezentarilor grafice;

- elemente de tip verificare si validare (V & V);

- natura bidirectionala, deplasari pe verticala in structura sistemului;

- deschiderea pentru interconectarea instrumentelor CASE;

- sprijin pentru lucru cu utilizatori multipli;

- descompunerea;

- performante de deplasare, pe orizontala, de la un instrument la altul;

- grade diferite de automatizare;

- integrare.

4. Cateva provocari ale tehnologiei informatice actuale

4.1 Programarea orientata pe obiecte. In cursul precedent este prezentat un scurt istoric al evolutiei analizei si proiectarii sistemelor prin metodologii orientate obiect, dar se cuvine o precizare: sintagma 'orientare-obiect' are acceptiuni diferite in diverse discipline: una in modelarea informatiilor, alta in programare si alta in analiza si proiectarea sistemelor. Pentru a proiecta si implementa soft orientat spre obiecte trebuie cunoscuta metoda de abordare specifica acestei paradigme si bineinteles un limbaj de programare adecvat.

Cat priveste utilizarea acestei orientari in analiza si proiectarea sistemelor, trebuie subliniat ca actualele SGBD de tip Visual, in speta Visual Fox si Access sunt foarte usor de manevrat, mai ales ca bazele de date din aceste medii de programare se realizeaza sub forma de baze de date relationale, iar utilizarea obiectelor se face foarte subtil, la nivel camp. Obiectele intervin vizibil numai in realizarea controalelor. Totusi pentru cei care cunosc programarea pe obiecte este pacat sa nu stie sa foloseasca si proiectarea obiectuala a sistemelor informatice, mai ales ca exista si instrumente CASE bine puse la punct si pentru metodologiile orientate obiect (Rational Rose, Visual Modeler, etc.)

4.2 Aparitia aplicatiilor si a bazelor de date multimedia, mai ales in legatura cu bazele de date distribuite sau cu comunicatiile pe WWW, este o chestiune care trebuie sa ne puna in stare de veghe si daca sistemul la care lucram o impune, trebuie sa avem in vedere si alte aspecte cum ar fi reclama pe Internet, utilizarea paginilor WEB, e-learning, punerea la dispozitia utilizatorilor a unui help profesionist, documentatie online, s. a.

4.3 Un element deloc lipsit de importanta este softul pe care vom realiza si pe care va fi implemetat sistemul informatic (este vorba de interfata grafica/sistem de operare si de SGBD). Poate este util de stiut ca in tarile occidentale se lucreaza mai mult sub UNIX si LYNUX si mai rar sub Windows, iar ca SGBD se foloseste foarte mult - ORACLE. Pentru o aplicatie care sa reziste 'afara', vom folosi daca nu UNIX sau LYNUX cel putin Windows NT.

4.4 Aparitia inteligentei artificiale. Aceasta, in ciuda valului de 'elita' in care este infasurata nu trebuie sa-i alerteze prea mult pe realizatorii de sisteme informatice obisnuite pentru ca acestea se pot realiza si fara inteligenta artificiala, dar daca se pune problema unor aplicatii menite sa coordoneze procese, sau sa ofere mijloace de invatare cu ajutorul calculatorului, sau sa operam activ pe Internet, atunci s-ar putea ca apelarea la inteligenta artificiala sa fie inevitabila. De aceea, inainte de a incepe detalierea etapelor de proiectare a sistemelor informatice, vom dedica cate un curs sistemelor support de decizie si respectiv sistemelor expert.



5. Rolul sistemelor informatice in conducerea

organizatiilor economice

Remarcam faptul ca in conditiile create de Internet, sistemul informatic se detaseaza de intreprindere si chiar iese din cadrul ei facand legatura directa cu bancile, cu furnizorii si ofera conducerii date despre miscarile pe care le executa concurenta. Conducerea intreprinderii moderne nu se mai multumeste cu o informare operativa ci doreste prognoze, doreste sa prevada viitoarele miscari ale concurentei si viitoarea evolutie a pietei tinand cont de ceea ce se petrece in prezent. Deaceea chiar daca nu proiectam sisteme suport de decizie sistemele informatice moderne trebuie sa iasa din perimetrul intreprinderii.

In [1] Dumitru Oprea vede relatia sistemului informatic cu intreprinderea ca in figura de pe pagina urmatoare.


Date

Concepte de baza ale proiectarii sistemelor informatice

  2. METODE SISTEMICE DE PROIECTARE

2.1. Nivele de abstractizare si modelare

Modele

Nivele

Date

Prelucrari

Conceptual

Model conceptual MCD

Model conceptual MCP

Organizational

Model logic MLD

Model organizational MOP

Fizic

Model fizic MFD

Model operational MOpP

2.2. Modelarea conceptuala a datelor. Modelul entitate-asociere.

2.2.1. Concepte de baza

Entitate:

- reprezentarea unui 'obiect' concret sau abstract care:

- apartine spatiului problemei de rezolvat (face parte sau este relevant

pentru realitatea observata);

- are o existenta de sine statatoare;

- poate fi identificat in raport cu celelalte obiecte de acelasi tip.

Exemple: angajat, produs, utilaj, operatie tehnologica, client, factura

O entitate este reprezentata printr-un ansamblu de atribute.

Atribut: caracteristica sau proprietate a unei entitati, semnificativa pentru spatiul problemei de rezolvat.

Exemplu:

Atribute

 


Entitatea este perceputa aici ca un tip de “obiecte”. Fiecare obiect individual constituie o realizare a entitatii respective.

Atributele au, la randul lor, aceeasi conotatie tipologica, in sensul ca despre orice realizare a unei anumite entitati se cunosc aceleasi atribute, dar pentru fiecare dintre acestea continutul sau valoarea atributelor respective difera.


Tip de valori: un anumit ansamblu de valori, definite fie printr-o proprietate fie printr-o enumerare.

Exemplu:

Stare civila = (necasatorit, casatorit, vaduv, divortat)

Zile lucratoare = (luni, marti, miercuri, joi, vineri)

An studii = (a : a intreg, 1 £ a £ 5)

Un atribut poate fi:

- simplu: atunci cand pentru o entitate sau o asociere poate lua o singura valoare;

- repetitiv: daca pentru o entitate sau o asociere poate lua mai multe valori (ex: limbi straine cunoscute)

Reguli privitoare la atribute:

1. fiecare atribut poate apare intr-o singura entitate (principiul nonredondantei)

2. un atribut poate avea numai valori elementare.

Exemplu incorect: deoarece 'prenume copii' poate avea mai multe valori pentru o anumita persoana.

Identificatorul entitatii: un atribut sau un grup de atribute care primesc valori unice pentru fiecare realizare a entitatii respective si pot servi astfel pentru identificarea fara echivoc a acestora.

Pentru simplitate se recurge frecvent la coduri care sunt atribute construite special astfel incat sa raspunda cerintelor de identificare (ex: marca salariat) sau la atribute de tip 'numar de ordine' sau 'numar de aparitie' (ex: numarul de inventar al unui mijloc fix).

In reprezentarea grafica, identificatorul entitatii se subliniaza.

Asocierea: reprezentarea legaturii sau corespondentei existente intre doua sau mai multe realizari de entitati.

O asociere nu are existenta de sine statatoare, depinzand de existenta realizarilor de entitati pe care le leaga.; in consecinta, nu are identificatori specifici.

O asociere poate avea atribute proprii.

Entitatile care participa la o asociere constituie colectia acesteia.

Numarul de entitati care participa la o asociere formeaza dimensiunea sau gradul acesteia (mai mare sau egala cu numarul de entitati al colectiei).

Cardinalitatea minimala / maximala exprima modul de participare al realizarilor fiecarei entitati la asociere ( valori uzuale:0,1; 1,1; 0,n; 1,n ).

Reprezentarea grafica:

Intre realizarile acelorasi entitati pot exista mai multe asocieri diferite, cu semantica si cardinalitati distincte.

Asociere reflexiva: o asociere care leaga realizari diferite ale aceleiasi entitati (colectie = 1). In asemenea cazuri, este indispensabila specificarea in schema a rolurilor jucate de entitate.

Rol al entitatii nume care serveste pentru a desemna participarea entitatii la o asociere.

Restrictii de integritate: reguli suplimentare, nereprezentabile direct in formalismul EA, care trebuie respectate permanent de date.

Restrictii de integritate structurale: inerente conceptelor folosite la modelare:

- integritatea entitatii: valorile luate de identificatorul entitatii trebuie sa fie unice si nenule;

  - integritatea referentiala: pentru orice realizare a unei asocieri este obligatorie existenta realizarile entitatilor participante.

Cardinalitatea:

Cardinalitatile minimale

1. Cardinalitatea minimala 0 : pot exista realizari ale entitatii care nu narticipa la nici o realizare a asocierii;

Ex:

Un client poate exista chiar daca nu a emis nici o comanda

2. Cardinalitatea minimala 1: toate realizarile entitatii trebuie sa participe la o realizare a asocierii.

Exemplu de mai sus: Orice comanda trebuie sa fie emisa de un client.

Cardinalitatile maximale:

3. Cardinalitatea maximala : legatura este modificabila sau daca nu, legatura poate fi notata prin sageata.

Ex: O comanda nu-si poate schimba ulterior clentul.


4. Cardinalitatea maximala n: valoarea lui n poate fi precizata

2.2.2. Restrictii de integritate

Restrictii de integritate: reguli suplimentare, nereprezentabile direct in formalismul EA, care trebuie respectate permanent de date.

Alaturi de elementele oferite de reprezentarea de mai sus, corespunzatoare cazului unei biblioteci universitare, mai sunt de luat in considerare urmatoarele reguli suplimentare (care constituie restrictii de integritate - RI):

- cele mai vechi carti aflate in posesia bibliotecii sunt din anul 1910.

- biblioteca grupeaza cititorii in urmatoarele categorii: studenti, cadre didactice, doctoranzi, diversi (cu varste cuprinse intre 18 si 70 ani).

- drepturile de imprumut ale cititorilor sunt diferentiate astfel:

Categorie

Nr. carti

imprumutate

Studenti

Cadre didactice

Doctoranzi

Diversi

- un cititor poate trece de la o categorie la alta (de exemplu, de la student la doctorand sau cadru didactic) .

- un imprumut este individual, include unul sau mai multe exemplare din lucrarile care pot fi imprumutate (in limita drepturilor conferite de categoria cititorului si a numarului de carti imprumutate anterior si nerestituite inca.) si are o durata maxima de 20 zile.

- nu pot fi imprumutate mai multe exemplare din aceeasi lucrare de catre acelasi cititor.

- la restituirea unei carti imprumutate, se inregistreaza data restituirii si, daca a fost depasit termenul de 20 de zile, se blocheaza dreptul de imprumut al cititorului respectiv pe o durata egala cu numarul de zile de intarziere.

Dupa momentul in care actioneaza, exista doua clase de RI: statice si dinamice.

R.I. Statice: conditii care trebuie sa se verifice permanent:

Ex:

An editie ³

R.I. Dinamice: privesc evolutia in timp a datelor.

Ex:

Categorie cititor poate evolua in felul urmator:


2.2.2.1. Restrictii de domeniu

RI de domeniu sunt conditii impuse asupra ansamblului de valori acceptate pentru un atribut in cadrul tipului sau domeniului sau. Acestea pot viza:

continutul unui singur atribut al unei entitati sau asocieri;

ex: Categorie = studenti, cadre didactice, doctoranzi, diversi}

corelatii intre valorile mai multor atribute ale aceleiasi entitati sau asocieri;

ex: pentru Categorie = 'studenti', Limita impr = 3,

corelatii intre atributele mai multor entitati sau asocieri diferite;

ex: pentru acelasi exemplar si acelasi cititor, Data restituire > Data imprumut;

corelatii cu valori obtinute pe baza unor operatii de sintetizare (numarare, insumare, medie etc) a unui ansamblu de entitati;

ex: pentru un cititor, numarul de asocieri IMPRUMUT fara asocieri RESTITUIRE corespunzatoare <= Limita impr

2.2.2.2. Restrictii structurale

RI structurale sunt: restrictii inerente conceptelor folosite la modelare.

In cadrul restrictiilor structurale amintim: identificarea entitatilor, identificarea asocierilor, cardinalitatilor

Identificarea entitatilor: valorile luate de identificatorul entitatii trebuie sa fie unice si nenule.

Cazuri particulare:

a). Un tip de entitate poate fi identificat prin rolul (sau rolurile) asumate de alte entitati in cadrul unei asocieri la care participa si acesta.

STOC nu are identificator propriu; identificarea se face prin intermediul rolului Mat-stocat al tipului de entitate MATERIAL .

Identificarea prin rol se poate realiza in urmatoarele conditii:

- asocierea implicata nu trebuie sa fie ciclica;

- cardinalitatea in asociere a tipului de entitate identificat trebuie sa fie 1,1;

- cardinalitatea in asociere a tipului de entitate identificator poate fi 0,1 sau 1,1.

Identificarea asocierilor: prin definitie, fiecare asociere este identificata prin rolurile asumate de entitatile participante. Prin urmare, existenta unei asocieri este conditionata de existenta entitatilor participante.

Cardinalitatile:

cardinalitatea minimala 0 : pot exista entitati care nu participa la nici o asociere.

cardinalitatea minimala 1: toate realizarile entitatii trebuie sa participe la o realizare a asocierii.

Ex anterior: Orice comanda trebuie sa fie emisa de un client.

cardinalitatea maximala 1: legatura este modificabila sau nu ? Daca   nu, legatura poate fi notata prin sageata.

Ex:

cardinalitatea maximala n: valoarea lui n poate fi precizata.

Exemplu:


O comanda poate specifica maximum 6 produse diferite

2.2.2.3. Incluziune, excluziune, egalitate de roluri

Unele restrictii de integritate formuleaza reguli referitoare la rolurile jucate de un tip de entitate in diverse asocieri.

Incluziunea: daca o entitate E joaca un rol r1 intr-o asociere a1, atunci trebuie sa joace si rolul r2 intr-o asociere a2.

Notatia grafica:

Ex: Un client poate beneficia de un credit numai daca a depus o cerere pentru aceasta: intre rolurile beneficiaza si depune ale aceluiasi client exista o restrictie de incluziune.


Depunerea unei cereri nu implica si acordarea imprumutului dar acordarea acestuia implica intotdeauna existenta cererii corespunzatoare.

Obs RI de incluziune este redondanta in cazurile in care cardinalitatea minimala a rolului indus este mai mare de zero (analizata depusa in exemplul anterior).

Egalitatea: restrictia de incluziune intre rolurile r1 si r2 ale entitatii este reciproca.

Notatia grafica:

Ex: Orice client care este beneficiarul unui credit trebuie sa constituie o garantie pentru acesta si, reciproc, constituirea unei garantii de catre un client se face atunci cand acesta devine beneficiarul unui credit.


Excluziunea: rolurile r1 si r2 ale entitatii se exclud reciproc.

Notatia grafica:


Ex: un apartament nu poate apartine simultan unei persoane fizice si unei societati (persoane juridice).


2.2.2.4. Incluziune, excluziune, egalitate de asocieri

Aceste restrictii impun conditii care actioneaza asupra tuturor rolurilor dintr-o asociere; cu alte cuvinte, este vizata asocierea si toate entitatile participante si nu numai participarea unei anumite entitatti, ca in cazul anterior.


Incluziune

Ex: Orice produs livrat trebuie sa corespunda unui produs comandat. In acest caz restrictia implica cele doua asocieri in totalitate, nu numai anumite roluri.

Obs. Unei comenzi ii pot corespunde mai multe livrari diferite, fapt reflectat prin asocierea LIVR-CDA; pentru ca restrictia de incluziune mentionata sa fie valida, cardinalitatea rolului bazata-pe trebuie sa fie 1,1.


I

Excluziune

Ex: In aceeasi tranzactie imobiliara, nu este posibil ca vanzarea si cumpararea sa fie facute de aceeasi persoanaa Aceasta nu impiedica insa ca o persoana sa fie si vanzator si cumparator, dar in tranzactii diferite (restrictia opereaza asupra asocierii si nu asupra rolurilor).


Egalitatea

Ex: Fiecarui imprumut de catre un cititor al exemplarului unei carti trebuie sa-i corespunda o restituire si reciproc, fiecarei restituiri trebuie sa-i corespunda un imprumut.


2.2.3. Reprezentarea timpului

Timpul, cel mai frecvent sub forma datei calendaristice, intervine in numeroase probleme. Modelarea EA nu poseda formalisme specifice pentru aspectul temporal. Astfel, reprezentarea este uniforma atat pentru entitati durabile (permanente) cum sunt, spre exemplu, clientii, produsele, angajatii etc. cat si pentru cele de tip 'eveniment' care au caracterul unei schimbari, modificari, asocieri produse la un moment dat (comenzi, facturi, plati, incasari etc).

In privinta reprezentarii evenimentelor nu apar probleme deoarece, prin definitie, acestea sunt punctuale si au o data (sau un moment) de producere. Cum in activitatea curenta de gestiune acestea sunt reflectate in documente carora li se atribuie numere unice ce pot servi ca identificatori, data apare ca un simplu atribut. Spre exemplu, o comanda, o factura, o plata vor fi identificate prin numarul documentului in care sunt consemnate si vor poseda un atribut care sa specifice data producerii lor (data comenzii, data facturarii, data platii).

Asocierile repetitive sau de scurta durata ce apar intre entitatile stabile ridica insa probleme specifice. Sa consideram, spre exemplu, asocierea care apare intre un angajat si compartimentul in care lucreaza. O prima solutie este cea reprezentata in schema de mai jos, care are insa dezavantajul de a nu arata decat ultimul loc de munca al fiecarei persoane. In cazul in care o persoana trece de la un compartiment la altul (problema fiind similara si la trecerea de la o functie la alta), asocierea corespunzatoare noului loc de munca o va inlocui pe cea anterioara, deci vechiul loc de munca va fi 'uitat'.


Ce se intampla insa daca este necesar sa se cunoasca toate locurile de munca ale unui angajat ?

Introducerea unui nou tip de asociere intre cele doua entitatti pentru a indica locurile de munca anterioare nu este o solutie valida, deoarece realizarile acesteia risca sa nu poata fi identificate: nimic nu impiedica o persoana sa revina la un loc de munca la care a mai lucrat candva (deci aceeasi pereche de valori 'Marca, Cod compartiment', care trebuie sa identifice fiecare asociere, apare de mai multe ori).


Doua solutii sunt posibile aici: fie introducerea unui nou tip de entitate DATA pentru reprezentarea timpului, ceea ce face ca Data calendaristica sa completeze Marca si Codul compartimentului in identificarea asocierilor, fie transformarea asocierii in entitate, aceasta avand semnificatia de istoric al locurilor de munca ocupate de fiecare persoana.

In acest din urma caz, identificarea entitatilor ISTORIC-L-M se face prin atributul propriu Data incepere si prin rolurile entitatilor ANGAJAT si COMPARTIMENT.

Solutiile ilustrate prin acest exemplu pot fi generalizate, in sensul ca:

- cea mai avantajoasa solutie consta in plasarea timpului sub forma de atribute in cadrul entitatilor sau asocierilor corespunzatoare;

- daca acest lucru nu e posibil, fie se introduce o entitate abstracta pentru reprezentarea timpului fie se transforma asocierea dintre entitatile durabile intr-un nou tip de entitate care sa reflecte derularea relatiilor dintre acestea in timp (istoric).

Alaturi de gasirea unor modalitati de reprezentare temporala de genul celor prezentate mai sus, s-au facut propuneri de extensie a modelului EA care sa ia in considerare in mod explicit problema timpului. In mod concret, in spatiul unei aplicatii este necesar sa se poata manipula cu urmatoarele referinte temporale:

- trecut;

- viitor.

O asemenea extensie introduce distinctia dintre 'obiectele' conceptuale (echivalente entitatilor) si temporale. Entitatile sunt aici obiecte persistente care, odata aparute, nu dispar niciodata. Obiectele temporale materializeaza rolurile active jucate de un obiect conceptual in timp. Spre exemplu, o persoana este o entitate. Pe durata unui anumit numar de ani din viata sa, persoana a fost elev, dupa care a fost student iar apoi angajat. Aceste stari sunt reflectate prin entitati temporale destincte.

Existenta unei entitati este caracterizata numai de momentul aparitiei sale. Spre deosebire de aceasta, durata de viata a unei entitati temporale este intotdeauna un interval inchis la stanga - momentul de debut al rolului nu poate fi niciodata necunoscut - si inchis sau deschis la dreapta - existenta acestuia s-a incheiat si, in consecinta, se cunoaste momentul terminarii, sau continua

2.2.4. Subtipuri de entitati

In numeroase cazuri, in ansamblul entitatile ce apartin unui anumit tip exista subgrupuri cu o anumita relevanta pentru realitatea reflectata si care, in consecinta, trebuie reprezentate explicit.

Grupurile de entitati sunt numite subclase ale TE, acesta fiind, la randul sau, superclasa acestora. Spre exemplu, entitatile apartinand TE ANGAJAT pot fi grupate in MUNCITOR, TEHNICIAN, INGINER, ECONOMIST etc. Fiecare entitate a unui asemenea grup este, in acelasi timp, o entitate a tipului ANGAJAT.

Definirea de subclase se poate face in doua moduri:

- pe baza valorilor unui anumit atribut

- pe baza unor criterii definite de utilizator.

Prin definirea de subclase se efectueaza specializarea entitatilor superclasei acestora (TE). Acestea mostenesc toate atributele superclasei si pot avea atribute proprii specifice, inexistente la nivelul superclasei.

Spre exemplu, in subclasele MUNCITOR si INGINER ale TE ANGAJAT dintr-o intreprindere, alaturi de atributele comune, aferente oricarui angajat (Marca, Nume, Prenume, Data nasterii, etc), pentru muncitori pot exista, suplimentar, atributele specifice Meserie si Nivel calificare iar pentru ingineri, atributul Specialitate.

Delimitand subansambluri de entitati ale aceluiasi tip de entitate, subclasele constituie subtipuri ale acestuia. Reprezentarea grafica uzuala este:


Generalizarea este procesul invers, prin care doua sau mai multe tipuri de entitati sunt generalizate, pe baza proprietatilor comune, intr-un nou tip. In aceasta relatie, TE initiale devin subtipuri ale tipului obtinut prin generalizare. Spre exemplu, tipurile de entitati ANGAJAT si STUDENT dintr-o universitate pot fi generalizate prin tipul PERSOANa, care va prelua atributele comune ale acestora: Nume, Prenume, Data nasterii, Adresa etc.

Maniera in care se procedeaza - prin specializare sau generalizare - depinde exclusiv de cerintele unei cat mai fidele reprezentari a realitatii.

Specializarea poate fi totala (orice entitate a tipului face parte, obligatoriu, dintr-un subtip) sau partiala (pot exista entitati care sa nu apartina nici unui subtip).

In exemplul anterior, specializarea este partiala, deoarece exista si alti angajati in afara muncitorilor si inginerilor. Aceasta este o restrictie de integritate specifica, reprezentata grafic prin utilizarea unei linii simple pentru o specializare partiala si a unei linii duble pentru o specializare totala. Cum generalizarea se obtine grupand tipuri de entitati deja existente, nu poate fi decat totala.

Intre subtipuri poate exista un raport de excluziune, ceea ce traduce faptul ca fiecare entitate poate apartine unui singur subtip (ca in exemplul anterior). Exista insa si cazuri in care aceeasi entitate poate apartine mai multor subtipuri diferite (cu alte cuvinte, submultimile entitatilor apartinand subclaselor respective nu sunt disjuncte). Aceasta RI este reprezentata grafic prin intermediul simbolului de excluziune. In cazul in care nu exista exclusivitate, este foarte probabila existenta unei RI de incluziune, care sa precizeze conditiile in care are loc 'suprapunerea' entitatilor apartinand fiecarui subtip.

Presupunand, spre exemplu, ca STUDENT si CADRU-DIDACTIC sunt subtipuri ale TE PERSONAL-UNIVERSITATE, se poate formula urmatoarea restrictie de incluziune: pot fi cadre didactice (preparatori, in speta) numai studentii de la studii aprofundate.

Cele doua restrictii de integritate sunt total independente. Orice combinatie intre ele este posibila: partial-exclusiv, partial-inclusiv, total-exclusiv, total-inclusiv.

Introducerea de subtipuri prin specializare/generalizare prezinta doua avantaje principale:

- factorizeaza proprietatile comune la nivelul tipului (superclasei);

- face mult mai clara reprezentarea unor tipuri asocieri la care participa numai o parte dintre entitati.

Ex: O intreprindere fabrica si livreaza produse finite si subansamble. O cantitate unitara dintr-un anumit produs sau subansamblu se fabrica din alte subansamble si/sau materii prime, in cantitati bine precizate.


Un model EA in aceasta forma impune introducerea de restrictii de integritate de genul:

daca Tip articol este 'produs finit' atunci nu poate juca rolul component-in; daca Tip articol este 'materie prima' atunci nu poate juca rolul compus-din s.a.m.d.

Un model mult mai clar (desi mai voluminos) se poate obtine introducand specializarea pe baza continutului atributului Tip articol (TE ARTICOL factorizeaza proprietatile comune).




Un anumit tip de entitate poate face obiectul mai multor specializari diferite, in masura in care aceasta prezinta semnificatie pentru reprezentarea problemei modelate.

Ex: O societate de valori imobiliare ofera clientilor sai bunuri imobiliare (apartamente, case, vile) pentru vanzare sau inchiriere. Pentru vanzare, se cunosc pretul si starea bunului (liber, disponibil ulterior). Pentru inchiriere, se cunosc chiria lunara, durata minima a inchirierii si avansul.

Un bun imobiliar face aici obiectul unei duble specializari, in functie de tip (apartament la bloc sau casa/vila) si in functie de natura ofertei facute de proprietarul sau (vanzare sau inchiriere).

Prima dintre specializari aduce avantajul factorizarii atributelor comune in TE BUN-IMOBILIAR si plaseaza atributele specifice in subtipul corespunzator (spre exemplu, Suprafata gradina exista numai pentru casa sau vila). In absenta acestei specializari, atat atributele specifice numai apartamentelor cat si cele specifice numai caselor ar fi trebuit sa figureze in TE BUN-IMOBILIAR, desi ele nu pot avea niciodata valori simultan (un bun imobiliar nu poate fi, in acelasi timp, si apartament la bloc si casa). Un atribut suplimentar -Tip bun - ar fi fost necesar pentru a face distinctia adecvata si un set de RI de domeniu ar fi trebuit sa controleze valorile luate de atribute in functie de continutul acestui atribut.

A doua specializare face mai clara tipul de tranzactie la care poate participa fiecare bun. Asa cum se observa in schema, numai bunurile oferite spre vanzare pot face obiectul unei vanzari; aici avantajul nu vine din factorizarea atributelor ci din claritatea (si simplitatea) reprezentarii. Specializarea elimina nevoia unui atribut care sa precizeze natura ofertei facute si a RI de rol care sa precizeze ca numai un bun pentru care natura ofertei este 'de vanzare' poate fi vandut.


Specializarea TE CLIENT aduce avantaje de acelasi tip, indicind, de exemplu, ca nu poate fi ofertant decat un client care este proprietarul unui bun imobiliar (intermediarii sunt exclusi in aceasta schema).

  Absenta RI de excluziune dintre cele doua specializari precizeaza ca aceeasi persoana poate fi atat ofertant cat si solicitant. RI dintre asocierile CUMPARA si VINDE precizeaza ca, pentru o anumita vanzare, cumparatorul si vanzatorul trebuie sa fie persoane diferite.

2.2.5. Reguli referitoare la Modelul Conceptual al Datelor (MCD )

Unicitatea numelor.

Regula de unicitate a numelor se aplica tutoror elementelor ce apar in MCD: TE, TA, atribute, roluri, RI. Prin urmare, se vor elimina eventualele posibile ambiguitati prin utilizarea de nume complete (ex: Nume angajat, Nume produs si nu, simplu, Nume, in ideea ca apartenenta acestui atribut la un tip de entitate sau altul inlatura de la sine ambiguitatea).

Eliminarea omonimelor si sinonimelor. Atribute derivabile

Atributele derivabile sunt cele ale caror valori se obtin din valorile altor atribute, de regula prin relatii de calcul (ex: Limita imprumut care poate fi determinat pe baza continutului atributului Categorie cititor; Valoare produs comandat care poate fi obtinut inmultind Cantitatea comandata cu Pretul produsului respectiv).

In mod normal, aceastea trebuie eliminate din MCD, fiind redondante. Daca insa prezinta o semnificatie particulara pentru problema studiata (facand, spre exemplu, obiectul unor RI distincte), este posibila mentinerea lor in schema, insotite de specificarea relatiilor de calcul sau derivare sub forma de RI.

Atribute repetitive sau decompozabile

Prezenta acestora poate indica existenta unor structuri care trebuie reprezentate ca atare. Ex: pentru un student, reprezentarea rezultatelor la examene constituie un atribut repetitiv si decompozabil care indica existenta unei asocieri intre student si disciplinele pentru care trebuie sa sustina examene


Aceasta regula nu trebuie aplicata pentru orice atribut repetitiv sau decompozabil decat in masura in care conduce la evidentierea unor elemente, entitati sau asocieri semnificative pentru problema reprezentata.

Spre exemplu, descompunerea atributului Adresa in Localitate, Strada, Numar etc va fi facuta numai daca delimitarea lor prezinta interes in raport cu perceptia existenta in realitatea modelata.

Minimalitatea identificatorilor

Aceasta regula prevede ca, in cazul identificatorilor compusi dintr-un grup de atribute sau roluri, sa nu existe un subgrup in interiorul acestora care sa poata indeplini functia de identificator. Nerespectarea acestei reguli poate fi usor evidentiata prin examinarea dependentelor functionale dintre atributele sau rolurile ce compun identificatorul.

Existenta unor atribute ale caror valori devin 'nule' pentru anumite valori luate de alte atribute.

Aceasta situatie semnaleaza, in general, existenta de subtipuri.

O asociere nu poate exista decat o singura data intre aceleasi entitati

Ca si entitatile, asocierilor trebuie sa fie identificabile si identificarea lor se face prin entitatile participante (mai precis, prin identificatorii acestora). Conditiile impuse identificatorilor: valori nenule si unice pentru fiecare element, trebuie respectate si in cazul asocierilor.

Considerand ca ar exista cardinalitati si pentru asociere (nu numai pentru entitati), acestea ar trebui sa fie intotdeauna 1,1.

Daca pentru aceleasi entiati apar mai multe asocieri (de acelasi tip), inseamna ca restrictia de unicitate este incalcata. Solutia consta, in acest caz, in transformarea asocierii intr-o noua entitate.


Spre exemplu, fiecare imprumut si fiecare restituire din schema de mai sus trebuie sa fie unice pentru un anumit exemplar si un anumit cititor. Daca insa un cititor imprumuta de mai multe ori acelasi exemplar, restrictia de unicitate este incalcata. Rezolvarea consta in introducerea unui TE IMPRUMUT care sa individualizeze imprumutul.


Aici, fiecare imprumut este identificat prin atributul Data imprumut si prin rolul CITITOR:imprumuta. Un imprumut este facut de un singur cititor si poate cuprinde unul sau mai multe exemplare. Exemplarele imprumutate pot fi restituite toate odata sau pe rand.

Aceeasi solutie se impune si in cazul in care participarea anumitor entitati este optionala, ceea ce face ca o parte din identificatorul asocierii sa devina nedeterminata (nula). Spre exemplu, produsele comandate de clienti sunt livrate si facturate.


Cum facturarea nu este facuta in acelasi moment cu formularea comenzii, cardinalitatea acesteia este 0,1. Rezolvarea consta si aici in transformarea asocierii in entitate.


2.2.5.1. Dependente functionale

a) Dependente functionale simple.

Intre doua atribute A si B exista o dependenta functionala notata A B

daca fiecarei valori a lui A ii corespunde o singura valoare a lui B.

Spre exemplu, pentru un angajat se poate defini urmatoarea dependenta

functionala: Marca Nume

care exprima faptul ca unui angajat (identificat printr-un numar de

marca) ii corespunde un singur nume. Relatia inversa: Nume Marca

nu este adevarata, deoarece pot exista mai multe persoane cu acelasi nume dar cu numere de marca diferite.

Pentru un angajat mai pot fi definite si alte DF:

Marca Prenume

Marca Data nasterii

Marca Functie

Atributul aflat in stanga DF este numit determinant. Determinantul poate fi compus din unul sau mai multe atribute.

Ex: Pretul unitar de aprovizionare este determinat de felul materialului si de numele furnizorului, deoarece acelasi material se poate aproviziona la preturi diferite de la furnizori diferiti.

Cod material,Cod furnizor Pret aprovizionare

O dependenta functionala X Y este elementara daca pentru orice X’ strict inclus in X, dependenta functionala X’ Y nu este verificata.

b. Dependente functionale multivaloare

Intre doua atribute A si B exista o dependenta functionala multivaloare, notata:

A B

daca o valoare a lui A determina un ansamblu de valori al lui B.

Ex: Un anumit zbor al unei companii aeriene se efectueaza in mai multe zi ale saptamanii (luni, vineri, duminica).

Nr zbor Zi saptamana

Considerind cazul general al unui TE E in care A,B sunt atribute/grupuri de atribute apartinand acestuia iar C = E -(A B),

A B daca:

- A determina mai multe valori pentru B;

- A determina mai multe valori pentru C;

- B si C sunt independente unul fata de celalalt.

In alti termeni, daca A B atunci A C.

Dependenta functionala este un caz particular al dependentei functionale multivalore.

Daca A B atunci A B

In contextul modelului EA, DFM corespunde existentei atributelor repetitive sau multivaloare.

Proprietatile dependentelor functionale:

Reflexivitatea:

X X.

Ex: Cod client Cod client

Dezvoltarea:

Daca X Y atunci X,Z Y.

Ex: Cod client Den client

Cod client, Localitate Den client

Tranzitivitatea:

Daca X Y si Y Z atunci X Z.

Ex: Cod client Localitate, Localitate Judet

Cod client Judet

Aditivitatea:

Daca X Y si X Z atunci X Y,Z.

Ex: Cod client Den client, Cod client Adresa client

Cod client Den client, Adresa client

Proiectia:

Daca X Y,Z atunci X Y si X Z.

Ex: Cod client Den client, Adresa client

Cod client Den client,

Cod client Adresa client

Pseudo-tranzitivitatea:

Daca X Y si W,Y Z atunci X,W Z.

Ex: Marca persoana Loc munca, Loc munca, Functie Indemnizatie conducere

Marca persoana, Functie Indemnizatie conducere

Dependentele functionale reprezinta RI.

Identificatorul unei entitati este un atribut sau un grup de atribute fata de care toate celelate atribute depind functional.

Dependentele functionale pot exista si intre entitati si asocieri.

Cardinalitatile 1,1 corespund intotdeauna unor DF.

2.2.5.2. Normalizarea

Normalizarea este un proces care asigura:

- eliminarea redondantelor fara pierdere de informatie semnificativa

- eliminarea anomaliilor manifestate in procesul actualizarii.

Anomaliile se pot manifesta in procesul actualizarii in cursul operatiilor de adaugare, stergere si modificare.

Exemplu: Fie entitatea CaMINE definita sa retina modul de repartizare a studentilor in cadrul caminelor:


anomalie la inserare: introducerea datelor privitoare la un nou camin, pentru care s-a fixat taxa de cazare, nu se poate face pana cand nu este repartizat primul student in acest camin.

anomalie la stergere: la stergerea informatiei privind studentul Popescu Ioan se pierde informatia privind taxa de cazare la caminul Moxa 1.

anomalie la modificare: majorarea taxei pentru studentii din caminul Moxa 2 va impune modificarea tuturor tuplurilor implicate, in caz contrar aparand inconsistente.

Aceasta inseamna ca entitatea CaMINE nu a fost bine definita si ea va trebui supusa procesului de normalizare.

Exista cinci forme de normalizare (FN) si una intermediara intre forma 3 si 4 numita NFBC dupa numele lui Boyce Codd - fondatorul modelului relational al bazelor de date..

FN1: O entitate este in FN1 daca toate atributele sale sunt elementare si nerepetitive.

FN2: O entitate este in FN2 daca respecta cerintele FN1 si toate atributele non-identificator sunt dependente de intregul identificator.

Ex de FN1:

 


FN3: impune FN2 + sa nu existe dependente functionale tranzitive intre caracteristicile non-cheie. Pentru detalii despre celelalte forme de normalizare consultati anexa 1 din lucrarea de laborator nr. 10.


FNBC (BOYCE_CODD ): O entitate este in FNBC daca respecta cerintele FN3 si in plus

nici un atribut ce compune identificatorul nu depinde functional de un alt atribut.

FN4: O entitate este in FN4 daca:

- respecta cerintele FNBC;

- nu prezinta dependente multivaloare.

Normalizarea entitatilor

Normalizarea are drept scop eliminarea redondantelor si a anomaliilor de actualizare. Deoarece prin cele mentionate anterior se elimina o parte dintre cazurile de nerespectare a conditiilor de normalizare (existenta unui identificator, eliminarea atributelor repetitive sau compuse), este necesar sa se asigure o atentie deosebita urmatoarelor doua situatii:

a) existenta de DF tranzitive intre atribute (FN3);

b) existenta de DF partiale intre atributelor neidentificatoare si identificator

(atunci cand acesta este compus din mai multe atribute).

Ex: DF tranzitive existente intre atributele entitatii UTILAJE conduc la descompunerea acesteia in doua tipuri de entitati si la introducerea asocierii corespunzatoare dintre ele.


Normalizarea asocierilor

Situatia este similara entitatilor, cu observatia ca pentru asocieri nu exista identificatori proprii, rolul acestora fiind indeplinit de identificatorii entitatilor participante.

Exemplu:

In schema urmatoare, fiecare asociere REPARATIE este identificata prin Nr op interventie si Nr inventar (identificatorii entitatilor participante). Atributul Durata normata depinde insa functional de o parte a cheii (Nr op interventie), incalcand astfel conditiile de normalizare. Solutia corecta consta in plasarea sa in entitatea INTERVENTIE.


2.3. Modelarea conceptuala al prelucrarilor

Modelul conceptual al prelucrarilor prezinta succesiunea in timp a operatiilor de cautare la care este supus modelul conceptual al datelor, adica:

- ce trebuie facut la nivel conceptual fara a indica

- cine, cand si unde se realizeaza aceste prelucrari (conceptul organizational);

- cum se vor realiza ele in mod concret (conceptul fizic);

- are drept scop sa descrie continutul (ce operatii ?, ce rezultate ?) si dinamica (derularea in timp) unei prelucrari intr-o maniera independenta de utilizare a mijloacelor utilizate

Modelul conceptual al prelucrarilor este modelul 'eveniment-rezultat' al metodei Merise, ce repune in discutie procedurile (elementele) abordate de MCD formuland pentru fiecare element intrebari de forma:

- acest element este indispensabil si ce se intampla daca il suprimam;

- exista posibilitatea de a-l suprima (atentie la normele juridice si reglemantarile legale);

- cat costa mentinerea acestui elemet in procedura sau ce avantaje se obtin din mentinerea lui.

Modelul conceptual al prelucrarilor, vede intreaga prelucarare ca o succesiune ordonata si logica de proceduri inlantuite, toate in concordanta stricta cu legislatia in vigoare (este vorba de un demers tipic de analiza a valorilor).

Nu se poate trece cu vederea impactul utilizarii instrumentului informatic (SGBD) asupra MCP. Astfel, anumite validari pot fi efectuate inca de la culegerea datelor, in loc sa se constate ulterior ca datele sunt complete sau eronate, deci anumite operatii din MCP pot fi eliminate.

2.3.1. Concepte de baza

Ca si in cazul modelului conceptual al datelor, formalismul modelelor de prelucrare se bazeaza pe construirea unei diagrame avand trei elemente de baza:

a) evenimentul declansator, reprezentat grafic printr-o elipsa, de la care pleaca o sageata de legatura pentru simplificare, daca este necesar, elipsa poate fi omisa

b) operatia, reprezentata grafic printr-un dreptunghi ;

c) rezultatul (evenimentul emis), reprezentat tot printr-o elipsa

d) sincronizarea, reprezentata grafic printr-un triunghi orientat catre operatie.

Evenimentul declansator

Desemneaza un fapt a carui aparitie declanseaza o reactie in cadrul organizatiei; aparitia unui eveniment va antrena derularea de activitati, de operatii, reprezentand “motorul” unei actiuni, al unei operatii ( de ex. sosirea unui document).

Pentru ca MCP sa fie cat mai stabil, el trebuie sa fie independent de aspectele organizatorice si tehnologice, chiar geografice.

De ex. Sosirea unei comenzi de la un client este un eveniment declansator, de natura extern. A satisface aceasta cerere inseamna a o transforma intr-o livrare de produse. Descrierea continutului prelucrarilor necesare trebuie sa fie independenta de:

- aspectele tehnologice (se utilizeaza calculatorul sau nu ?)

- aspectele “geografice” (comanda este prelucrata la depozit sau in alta parte ?)

- aspecte organizatorice (livrarea este facuta de X la serviciul comercial sau de Y la magazie ?)

- aspecte temporale (livrarea se face dimineata sau seara ?).

Tip eveniment

Este un concept generic descriind toate aparitiile evenimentelor de aceeasi natura. Capacitatea sistemului de a percepe aceste aparitii este exprimata de doi parametri :

capacitatea indica numarul maxim de aparitii ale acestui tip de eveniment care pot fi percepute de sistem si

frecventa indica legea de manifestare a acestor aparitii.

Categorii de evenimente

Un eveniment poate fi :

Ø      extern (receptionat din exterior) : primirea unui CEC, a unui aviz de plata, solicitarea unui credit, etc.

Ø      intern (generat de activitatea sistemului intreprindere) : pana unei masini, gasirea unei solutii, etc.

Pentru a avea un eveniment trebuie sa coexiste anumite conditii:

- sa se intample ceva (in afara sau in interiorul intreprinderii)

- acest ceva trebuie sa fie perceput de sistem (care trebuie sa fie dotat cu mijloace capabile sa il perceapa)

- intreprinderea sa fie interesata, vazand in el un posibil eveniment declansator al activitatii sale.

Operatia

Se numeste operatie orice actiune (sau secventa continua de actiuni), producatoare de evenimente rezultat, care se executa fara intrerupere, ca reactie la un eveniment declansator (sau a mai multor evenimente declansatoare sincrone). O operatie constituie un bloc neintrerupt (nu trebuie sa apara rezultate intermediare in interiorul unei operatii).

Tip de operatie

O categorie de operatii ce prezinta aceleasi caracteristici. Un anumit numar de parametri caracteristici permit specificarea unui anumit tip de operatie:

- desemnarea operatiei insasi;

- durata exprimata in unitati de timp

- actiunile elementare constitutive

- evenimentele emise si conditiile de emitere.

O operatie se finalizeaza intotdeauna prin emiterea de evenimente functie de situatiile identificate pe parcurs si de conditiile exprimate de aceste situatii (asa-numitele reguli de emisiune).

Remarca. O operatie se desfasoara in timp, avand o anumita durata. La un moment dat ea poate fi :

- in asteptarea executiei;

- in curs de executie si

- terminata.

Rezultatul (evenimentul emis)

Numim rezultat produsul executarii unei operatii. Intotdeauna trebuie respectata urmatoarea regula: o operatie produce unul sau mai multe rezultate. Descompunerea unei operatii in mai multe operatii distincte implica aparitia unor rezultate intermediare. Un eveniment emis poate fi in acelasi timp un eveniment declansator pentru o alta operatie ( sau alte operatii). De aceea se si utilizeaza acelasi formalism.

Reguli de obtinere a rezultatului

In MCP toate operatiile trebuie sa aiba rezultat. In anumite cazuri obtinerea unuia sau mai multor rezultate poate fi supusa indeplinirii anumitor conditii. In aceasta situatie este necesar sa fie definite, formulate asa numitele reguli de emisiune sau reguli de actiune. (vezi fig. de mai sus). Exemple :

- Relatia date-rezultate este supusa anumitor conditii logice : daca valoarea facturata este mai mare de 1 milion, atunci se acorda o remiza de 1o%, daca nu, se acorda un scont de 2%.

- Lansarea unei livrari poate fi diferita daca stocul este insuficient. In acest caz comanda este plasata in asteptare (nu se intocmeste dispozitie de livrare). Conditia “stoc suficient” defineste o regula de emisiune a rezultatului cu doua cazuri diferite (“stoc suficient”; “stoc insuficient”).

Reprezentarea regulilor de emisiune

Conform figurii de mai jos, diferitele reguli de emisiune   sunt repre-zentate in partea inferioara a dreptunghiului ce descrie operatia.

Reprezentarea este analoga unei formu-lari de genul :

Daca regula de emisiune 1

atunci Rezultat A si Rezultat B

altfel (regula de emisiune 2)

Rezultat B si Rezultat C

Sincronizarea

In anumite cazuri, declansarea unei operatii poate solicita producerea simultana a mai multor evenimente. Cu alte cuvinte, o anumita operatie nu poate avea loc decat daca sunt indeplinite anumite conditii privind manifestarea evenimentelor ce concura la declansarea operatiei respective. Expresia acestor conditii se numeste sincronizare.

Principiul sincronizarii

Sincronizarea exprima sub forma unei propozitii logice faptul ca operatia poate fi declansata sau nu. Ea se exprima printr-o expresie booleana ce leaga evenimentele ce declanseaza operatia.

Modul de functionare

Daca E1, E2 si E3 sunt evenimente declansatoare pentru operatia Oi si daca a, b, c sunt aparitii corespunzatoare evenimentelor E1, E2 si respectiv E3, atunci sincronizarea :

a si ( b sau c) , adica a Ù ( b c)

indica faptul ca operatia Oi este declansata daca o aparitie a evenimentului E1 exista simultan cu una din aparitiile evenimentelor E2 sau E3.

Sincronizarea se exprima deci sub forma unei propozitii logice care trebuie sa respecte anumite reguli, dintre care cele mai importante sunt:

- conditia trebuie pusa pe evenimentele participative conjugate si

- trebuie sa existe situatii care permit declansarea.

Conceptul de sincronizare exprima o logica si o dinamica a prelucrarilor. La un moment dat, propozitia logica poate fi verificata. Atunci sincronizarea este activa si operatia este declansata. La un alt moment este posibil ca un singur eveniment declansator sa fie realizat; in acest caz sincronizarea este in asteptarea realizarii altor evenimente care sa declanseze operatia. Daca nici un eveniment nu are loc, sincronizarea este inactiva.

Timp

 


Sincronizarea reprezinta concordanta intre doua sau mai multe evenimente. Ea face ca evenimentele sa aiba loc simultan, in acelasi timp, concomitent, sincron.

Nu trebuie uitat faptul ca evenimentele “sincronizate”, prin sincronizare, declanseaza o singura operatie. Totodata, pentru ca un eveniment sa participe la o sincronizare, el trebuie sa fie utilizat in aceasta declansare.

Exemplu

Vom considera ca exemplificare procedura de acordare a unui credit.

Utilizand formalismul de mai sus vom defini modelul din figura urmatoare.

Schema din figura de mai jos constituie un model conceptual al prelucrarilor tipic; el descrie ceea ce se face, fara a preciza nici cine face si nici cu ce instrument.

Comentarii la figura de mai jos

O data cu primirea cererii de credit (eveniment) , are loc o operatie de instruire formala a deschiderii unui dosar de creditare care se finalizeaza dupa caz (functie de regulile de emisiune care au valorile c1 si respectiv c2 si c3) printr-un refuz (cerere nerezolvabila), prin deschiderea efectiva a unui dosar de creditare si in sfarsit, printr-o cerere de informare suplimentara.

c1 : nu exista plafon de credite

c2 : exista plafon de credite pe termen scurt c3 : exista de credite pe termen lung

Acest dosar face sistematic obiectul unei operatii de instruire, care, functie de solvabilitatea clientului (c4 - client nesolvabil sau C5 - client solvabil) se finalizeaza printr-o respingere sau acceptare a dosarului.

Notiunea de “Proces”

Un proces descrie dinamica prelucrarilor dintr-o activitate determinata. El este format din operatii executate ca reactie la evenimente si producand rezultate.

Un proces este:

- omogen : operatiile si rezultatele concura la o finalitate comuna.

- limitat : are granite marcate de evenimentele de origine si de rezultatele

terminale.

Etapele elaborarii unui proces.

Procesul este MCP ce corespunde unui domeniu de activitate. El este construit printr-un demers metodologic de modelare (analiza, abstractizare, conceptie), ce cuprinde urmatoarele etape:

1. Delimitarea obiectului de activitate

In cadrul acestei etape trebuie precizate granitele domeniului de care sunt legate activitatile care intereseaza.

2. Identificarea principalelor evenimente.

Aici trebuie revazute principalele evenimente externe si interne ale procesului; acestea sunt elemente cheie in realizarea modelului.

3. Construirea tabelului evenimente-rezultate.

Acest tablou permite definirea continutului procesului, precizand pe coloane, evenimentele, actiunile induse si rezultatele.

4. Identificarea si descrierea operatiilor.

Tabloul evenimente-rezultate, in coloana centrala, permite deja identificare actiunilor induse de evenimentele declansatoare. O analiza mai completa a contextului permite relevarea regulilor de gestiune, care sunt adesea elemente ale operatiilor.

5. Reperarea sincronizarilor.

Aparent, mai multe evenimente distincte pot sa declanseze aceeasi operatte. Odata stabilite aceste elemente se poate construi schema de baza pentru fiecare operatie. Aceasta schema se numeste bloc operatie.

6. Precizarea conditiilor de obtinere a rezultatelor.

Se cauta, printre regulile de gestiune, acelea care definesc conditii de obtinere a rezultatelor. Se completeaza apoi schema de baza cu elementele respective.

7. Ordonarea blocurilor-operatie.

Structura generala a procesului decurge din cronologia evenimentelor. Deci evenimentele trebuie ordonate cronologic. Acest fapt permite ordonarea diferitelor blocuri-operatie si legarea lor conform principiului: un rezultat (al operatiei n-1) declanseaza operatia urmatoare (operatia n).

8. Verificarea si validarea modelului.

Se verifica daca:

- orice operatie duce la cel putin un rezultat;

- orice operatie este declansata de cel putin un eveniment;

- toate blocurile sunt legate.

Validarea modelului se face de catre persoanele implicate in proces. Numai ele pot judeca pertinenta modelului propus.

Exemplu.

Etapa 1.

Domeniul care ne intereseaza este gestiunea clientilor privind comenzile pentru produse de panificatie (figura 2). Deci nu vor fi luate in considerare nici actualizarea stocurilor, nici activitatile contabile, intrucat nu apartin strict de gestiunea clientilor.

Etapa 2.

Pot fi identificate in principal:

trei evenimente externe :

1. Sosirea unei comenzi de la un client.

2. Existenta unui mijloc de transport disponibil in care sa se incarce

marfa.

3. Sfarsitul zilei;

trei evenimente interne:

1. Acceptarea comenzii.

2. Decizia de livrare.

3. Sfarsitul activitatii de livrare.

Etapa 3. Tabloul evenimente -rezultate.

EVENIMENTE

ACTIUNI INDUSE

REZULTATE

1. Sosirea comenzii de la ghiseu

Controleaza identitatea si pretul

Comanda acceptata sau nu

2. Existenta unui mijloc de transport disponibil

Efectueaza livrarea

Livrare efectuata

3. Sfarsitul zilei



Examineaza comenzile in asteptare

Comanda de fabricatie

1. Acceptarea comenzii

Consultarea stocurilor de produs

Comanda livrabila sau nu

2. Decizie de livrare

Pregatirea livrarii

Marfa gata de plecare

3. Sfarsitul activitatii de livrare

Expedierea marfii si pregatirea facturii

Livrare expediata

Factura

4.Comanda in asteptare

Examinarea comenzilor in asteptare

Comanda de fabricatie


Etapa 5

Vom exemplifica lucrul din aceasta etapa doar pentru un singur bloc operatie, si anume cel corespunzator operatiei 2 (“efectueaza livrarea”).

Etapa 6.

Putem avea de ex. urmatoarele reguli de gestiune:

a) “daca comanda este acceptata”. Aceasta regula defineste controlul de identitate si pret si conditioneaza rezultatul (comanda acceptata , respectiv refuzata);

b) “daca stocul este suficient”, regula asemanatoare  referitoare la marimea stocurilor.

Etapa 7.

Schema procesului este prezentata in figura 2.

Etapa 8.

Se constata in figura de mai sus ca sunt indeplinite regulile de modelare in sensul ca orice operatie este declansata de cel putin un eveniment si fiecare operatie are cel putin un rezultat (eveniment emis).

 


Descrierea detaliata a procesului

Schema procesului prezentata in figura de mai jos permite o perceptie rapida a ansamblului prelucrarilor. Daca se doreste insa o prezentare mai detaliata atunci este recomandat ca aceasta detaliere sa se faca la nivel de bloc operatie, fara sa mai urmeze o inlantuire a blocurilor detaliate, intrucat o schema detaliata a procesului ar fi greu de urmarit, de perceput. In acest caz se utilizeaza pentru eveniment urmatorul formalism.


Descrierea operatiei Denumire: Examinarea comenzilor in asteptare

Numar : 6

Proces : Gestiunea clientilor

Mod de sincronizare

- la sfarsitul zilei (ora 17)

- pentru toate comenzile in asteptare

Descrierea regulilor de gestiune

R1. Pentru fiecare produs:

- daca totalul cerut este mai mic decat cantitatea din stoc

solicitati livrarea;

- daca nu, cereti fabricarea.

R2. Comenzile de fabricatie sunt emise cel mai tarziu a doua zi dupa examinarea comenzilor.

Descrierea regulilor de emisiune

R1. Starea cererilor de fabricatie

Astfel de scheme trebuie elaborate pentru fiecare operatie. Se aplica aici principiul cunoscut al ierarhizarii, mergand de la general (schema procesului) catre particular (descrierea operatiei).

Revenind la reprezentarea grafica de mai sus putem afirma ca parametri exprimand dinamica procesului puneau restrictii doar la nivelul “nodurilor” si anume:

- la nivelul sincronizarii (propozitia logica, durata limita) si

- la nivelul operatiilor pentru emisiunea de rezultate (reguli de emisiune care orienteaza fluxurile catre o cale sau alta).

Acesti parametri pot fi completati cu altii plasati pe sagetile de legatura, in amonte si in aval de operatie. Astfel vom avea ca parametri suplimentari:

- participarea si durata limita (pe sageata eveniment --> sincronizare) si

- cardinalitatea (pe arcul operatie --> rezultat)

Participare si durata limita (reglarea in amonte)

Uneori sincronizarea, pentru a fi activata, are nevoie de existenta unui “lot” de aparitii ale evenimentului declansator. Acest numar constituie participarea tipului de eveniment la tipul de sincronizare. Timpul de activabilitate a acestui lot se numeste durata limita.

Cardinalitatea evenimentelor (reglarea in aval)

  Operatiile emit rezultate (evenimente emise). Uneori este posibil ca acestea sa fie emise in mai multe exemplare identice. Numarul de exemplare exprima cardinalitatea tipului de eveniment rezultat al operatiei.

2.4. Validarea modelelor

2.4.1. Modelele externe ale datelor

Fiecare prelucrare are propriul/propriile sale modele externe (subscheme) de date º MCD construit prin prisma unei singure prelucrari. MED se construieste independent de MCD.


O prelucrare are ME distincte pentru fiecare consultare si pentru fiecare actualizare. Atat pentru consultare cat si pentru actualizare, ME se construiesc pe baza blocurilor logice de date corespunzatoare.

Blocuri logice de date (BLD): fluxurile de date vehiculate de o anumita prelucare.

Evenimentele care activeaza o sincronizare si care nu constituie o cerere de consultare constituie un BLD.

Combinatia de evenimente produse printr-o regula de emitere a rezultatelor constituie un BLD.


Reguli pentru construirea ME

1) Un ME pentru fiecare consultare sau actualizare efectuata de o prelucrare. 2) Fiecare ME se construieste pe baza BLD folosind formalismul EA.

3) Entitatile din ME pot sa nu aiba identificatori.

4) Atributele, entitatile si asocierile externe pot sa nu fie atribute, entitati sau asocieri conceptuale.

5) Atributele externe echivalente atributelor conceptuale trebuie sa aiba acelasi nume.




Exemplu MCD


2.4.3. Reguli de validare in consultare

Atributele externe trebuie sa fie atribute conceptuale. Daca nu:

- omisiuni Þ se completeaza MCD;

- date calculate Þ se inlocuieste in ME cu atributele conceptuale necesare calcularii sale; daca acestea nu apar in totalitate in MCD, se adauga;

- date ce nu trebuie memorate Þ se elimina din ME, urmand sa fie tastate direct.

Trebuie sa existe posibilitatea de-a avea acces la date in structura necesara

Accesul poate fi facut:

- pe baza identificatorului;

- prin parcurgerea entitatilor sau asocierilor, una cate una Þ se verifica existenta criteriilor de selectie necesare si se compeleteaza MCD daca este nevoie.

Daca se fac consultari pentru care criteriul de acces nu este identificatorul, se adauga in MCD o noua entitate al carei identificator este acest criteriu de acces si asocierea necesara pentru consultare (cai de acces impuse de utilizare si nu de DF).

Cardinalitatile asocierilor externe trebuie sa fie incluse in cardinalitatile asocierilor conceptuale ce le corespund semantic

2.4.4. Reguli de validare in actualizare

Orice atribut extern trebuie sa serveasca fie la identificarea elementului conceptual de actualizat fie la obtinerea valorii de adaugat sau de modificat a unui atribut conceptual:

- se suprima atributele externe care nu servesc nici unuia din scopurile amintite;

- se adauga cele absente.

Cardinalitatile asocierilor externe trebuie sa fie incluse in cardinalitatile asocierilor conceptuale ce le corespund semantic.

Orice atribut conceptual trebuie sa poata fi inserat (modificat sau sters) prin cel putin un model extern. Daca nu, se adauga modelele externe adecvate.

Ex: entitati si asocieri inserate prin ME acceptare comanda de la client


Trebuie adaugate MCP si ME corespunzatoare pentru actualizarea produselor si clientilor.

2.5. Modelarea logica a datelor (MLD)

2.5.1. Cadru general

Trecerea de la MCD, care este un model universal, spre o solutie informatica se face gradat, luand in considerare un anumit tip de solutie si apoi, in cadrul tipului respectiv, o solutie direct implementabila.

Expresia MCD in termenii unui anumit tip de solutie informatica constituie modelul logic al datelor (MLD).

Deoarece aplicatiile informatice de gestiune se caracterizeaza prin stocarea si prelucrarea relativ simpla a unor volume mari sau foarte mari de date, tipurile de solutii luate in considerare vizeaza modalitatile de gestionare a datelor pe suporturile de memorie externa.


2.5.2. Modelul relational

Domeniu: o multime de elemente de tip similar.

Exemple:

NUME

ZILE

ORARE

Ionescu

Mateescu

Vasilescu

Popescu

Bunescu

Costescu

Dumitrescu

luni

marti

miercuri

joi

vineri

sambata

duminica

Bucuresti

Timisoara

Arad

Paris

Barcelona

Madrid

Roma

Atribut:

- o submultime a unui domeniu careia i s-a atribuit un nume. Numele exprima rolul sau semnificatia atribuite elementelor domeniului respectiv.

Ex:

- pentru domeniul Orase, pot fi definite atributele aeroport origine, aeroport destinatie, aeroport escala etc.

Aeroport origine

Aeroport destinatie

Escala

Bucuresti

Arad

Bucuresti

Barcelona

Paris

Bucuresti

Timisoara

Relatie: o multime

R = unde A1,A2An sunt domenii.

Ex 1: A1: domeniul compozitorilor; A2: domeniul simfoniilor;

P(a1,a2) = 'a1 est autorul simfoniei a2'.

P(Beethoven,Eroica)=adevarat;

P(Vivaldi,Simfonia fantastica)=fals.

Ex 2:

personal(MARCA,NUME,PRENUME,DATA-NASTERII)

daca (m,n,p,d) I personal

atunci o persoana cu marca (m), numele (n), prenumele (p) este nascuta la data (d).

Relatiile se reprezinta grafic sub forma de tabele, in care se disting:

gradul relatiei: numarul de atribute utilizate

cardinalitatea relatiei: numarul de tupluri (linii in tabel).


Cardinalitatea unei relatii este variabila in timp datorita operatiilor de actualizare care pot adauga sau sterge tupluri.

Pentru o relatie pot exista 3 tipuri de chei:

cheie primara: cel mai mic ansamblu de atribute (eventual unul singur) care permite identificarea fara echivoc al fiecarui tuplu al unei relatii; atributele care compun cheia primara nu pot avea valori nule.

cheie candidat: o alta posibila cheie primara, care nu a fost insa retinuta ca atare.

cheie externa: un ansamblu de atribute (eventual unul singur) care este cheie primara intr-o alta relatie.

Restrictie de integritate referentiala:

daca intre un atribut A si o cheie primara B exista o RIR atunci A nu poate lua decat valori care exista si in B. Prin definitie, cheile externe sunt supuse RIR in raport cu cheile primare corespunzatoare.

2.5.3. Trecerea de la MCD la MLD relational

a. ENTITATI

Fiecare entitate devine o relatie.

Atributele entitatii devin atribute ale relatiei.

Identificatorul entitatii devine cheia primara a relatiei


b. ASOCIERI

b.1 Cazul general

1) Asocierea devine o relatie.

2) Atributele proprii ale asocierii (daca exista) devin atribute ale relatiei.

3) Cheile primare ale entitatilor participante la asociere devin chei externe.

4) Identificatorul asocierii devine cheia primara a relatiei.


Ex 1

STUDENT(Nr matricol, Nume, Prenume)

DISCIPLINA(Cod disciplina, Nume disciplina)

EXAMEN(Nr matricol*, Cod disciplina*, Data examen, Nota)

Ex : 2

ARTICOL(Cod articol, Den articol, Tip articol, UM)

STRUCT-FABRICATIE(Cod articol compus*, Cod articol component*, Cantitate necesara)

b.2. Asocieri binare avand cel putin o cardinalitate maximala 1.

Se adauga la atributele relatiei corespunzatoare entitatii cu cardinalitatea maximala 1 identificatorul celeilalte entitati (cheia primara a relatiei corespunzatoare acesteia), care devine cheie externa.

Daca asocierea are atribute proprii, acestea se adauga la randul lor relatiei care reprezinta entitatea cu cardinalitate maximala 1.


Exemplul 1


COMPARTIMENT(Cod compartiment, Den compartiment)

ANGAJAT(Marca,Nume, Prenume, Data nasterii, Salariul lunar, Cod compartiment*, Data incadrarii)

Exemplu 2

PERSOANA(Cod persoana, Nume, Prenume, Data nasterii, Sex, Cod persoana tata*)

c. Subtipuri de entitati (Generalizarea/specializarea)

c.1. Reprezentarea simpla a legaturilor dintre tip si subtip

Se aplica regulile de la b.2. conform urmatoarei schemei generale:


c.2. Reprezentarea mostenirii

Reprezentarea mostenirii ca proces de transfer al proprietatilor generice ale tipului spre subtipuri nu beneficiaza de o solutie relationala dedicata. Din aceasta cauza, este necesar sa se recurga la defactorizarea proprietatilor comune.

a) se favorizeaza specializarea: tipul de entitate generica dispare iar atributele sunt adaugate la fiecare dintre subtipuri.

b) se favorizeaza generalizarea:

tipul de entitate generica preia si atributele specializate care, in functie de subtipul reprezentat, primesc valori nule.

BUN-IMOBILIAR(Nr bun, Adresa, Suprafata, Pret solicitat, Stare, Chirie lunara, Avans minimal, Durata minima, Nr client*)

atat tipul cat si subtipurile sunt conservate ca atare.

BUN-IMOBILIAR(Nr bun, Adresa, Suprafata, Nr client*)

BUN-DE-VANZARE(Nr bun vanzare, Pret solicitat, Stare)

BUN-DE-INCHIRIAT(Nr bun inchiriat, Chirie lunara, Avans minimal, Durata minima)

Nr bun vanzare si Nr bun inchiriat trebuie sa respecte restrictiile de integritate referentiala in raport cu Nr bun.

Modelarea Logica a Prelucrarilor (MLP)

a)      Modelul logic de prelucrare are rolul de a preciza:

frecventa de prelucrare;

actorii implicati;

fazele si sarcinile asociate acestora, inclusiv evenimentele si sincronizarile aferente;

tipul fazelor: A (automate) si M (manuale).

Pentru aceasta se pleaca de la MCP. Mai exact operatiile complexe sunt transformate in faze iar operatiile elementare sunt transformate in sarcini:






Politica de confidentialitate



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 2601
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2022 . All rights reserved

Distribuie URL

Adauga cod HTML in site