MODELAREA UNUI SISTEM SOFTWARE

MODELAREA UNUI SISTEM SOFTWARE

Acaesta modelare foloseste la stabilirea specificului sistemului. In acest fel obtinem un model al realitatii in care se manifesta problema. Acest model este formulat la un nivel abstract conceptual fara foarte multe precizari, pe baza cerintelor derivate din nevoi. Se vor specifica numai serviciile oferite si relatiile intre servicii.

Modelul este important sa fie stabil si pt. ca devine un mediu de comunicare pt. schimbul de info intre cei care procura sist. soft, utilizatorii soft si producatorii soft.

Daca problema este simpla toate activitatiile incep in mintea unui singur om.

In momentul cand apar probleme complexe care necesita achipe de proiectare, atunci este nevoie de un model ca mecanism de comunicare intre cei preocuoati de problema.

Existenta modelului evidentiaza si alte deficiente mentale:

- incomplet, ambigu si cu deficiente logice

Se fac verificarile de completitudine, ambiguitati.

Strategii in constructie

Functionala

Doua paradigme

Obiectuala

Varianta functionala - se extrag datele informatice si se prelucreaza     abstract.

- este posibil cand problema poate fi analizata stiintific.

Varianta obiectuala - ia numai aspectul exterior al unui subsistem.

Metoda de analiza a punctelor de vedere

Se separa modelul de restul lumii si seevidentiaza schimbarile modelului cu restul lumii. Fiecare strapungere se numeste punct de vedere. Acestea pot fi dinspre - utilizator

- sesizori, orice echipament asociat acelui punct de interfata

- sistemul de calcul care comunica cu sistemul nostru.

La fiecare punct de vedere se vor lua interactiune prin punctul respectiv. Punctele de vedere pot fi ierarhizate (pot exista puncte privilegiate si puncte auxiliare).

Puncte - directe -> pe problema

- indirecte ->ating problema (maresc sua micsoreaza gradul de adecvare la problema)

Reduli de analiza a punctelor de vedere

Fiecare punct de vedere va avea o procesare a info

Punctele de vedere nu se vor suprapune

Transferurile de info se fac numai intre punctele identificate (nu se inventeaza alte puncte de vedere)

Fiecare punct va fi independent rezolvat de fiecare.

Contextul unui sistem

Adica ceea ce este in afara sistemului.

Modelul problemei pune in lumina atat sistemul cat si parti de alte sisteme cu care acesta ineractioneaza. Punctele de vedere reprezinta locuri de tangenta intre sistem si subsistem in context. Contextul este cel care va preciza sarcina produsului soft. Problema va fi rezolvata din cauza contextului. In context nu se intervine.

Fiecare punct de legatura cu contextul este chiar punctul de vedere. Stabilirea contextului problemei este sarcina foarte grea. Pt. a putea preciza contextul trebuie sa ne fixam pe punctele de vedere si trebuie ..

Vom preciza fiecare interfata ceruta de un punct de vedere. Interfata este totalitatea interactiunilor care se petrec printr-un punct de vedere.

Exista metode care ajuta la formalizarea, reprezentarea atat a formalitatilor cat si a contextului.

Variante de formalizare - tabelul actiunilor

- diagrama actiunilor

Metodologiile lui Jackson

Procedura de construire a modelului pe baza unor etape:

. Faza de modelare

- se identifica toate actiunile care se evidentiaza la fiecare punct de vedere.

- se face documentarea actiunilor.

. Faza de relatii

- se simuleaza interactiuni asupra modelului. Astfel se pot gasi implicatiile relative intre actiuni.

- se gasesc manifestarile actiunilor.

. Faza de implementare

- modelul se va construi ca o entitate formata pe baza fazei 1 si 2.

- avem o descriere detaliata pe punctul de vedere si manifestare a fiecarei actiuni.

- sincronizarea intre actiuni.

Modelarea pe cale functionala este dificila pt. ca trebuie analizat sistemul in consistenta lui. Din cauza asta solutia pe care o vom studia va fi solutia prin metode obiectuale.

Solutia prin metode obiectuale

Modelul necesar pt. a se captura info pt. specificarea soft . Se rezuma numai la aspectul exterior al entitatilor si la comportarea lor.

Metoda fuziunii

Un model are doua parti - un model obiect

- un model interfata

1. Modelul obiect

Obiectul este ceva identificabil (persoana, masina, eveniment, organizatie). Obiectele asemanatoare difera prin caracteristici numite atribute. Nr. de atribute este constant pentru un obiect.

Proprietati:

Pot exista obiecte diferite cu aceleasi valori de atribute

Exista obiecte diferite cu aceleasi valori de atribute, dar identitatea unui obiect nu se poate schimba.

Obiectul este in aceasta faza o notiune care o definim numai pt. model. Obiectele nu au metode in aceasta faza.

Suntem in faza de modelare - stabilim ce sa faca incetul cu incetul. Proiectarea este faza la care obietele vor fi implementate.

Clasele

- Multimi de obicte asemanatoare

- Abstractizare a acestei multimi

- E necesara pt. a obtine atributele comune obiectelor asemanatoare

- Apartenenta unui obiect la o clasa se face printr-un predicat care caracterizeaza multimea calor care se bucura de aceasta proprietate.

Clasele se noteaza cu litere mari (Clase). Obiectele se noteaza cu litera mica (obiecte).

nune de clasa

atribute

Relatii intre clase

Relatia este o submultime in produsul cartezian a doua multimi de obiecte. Alegem dintre toti numai unii care au relatii. Modelul legaturii intre obiectele din clasa:

predicat

Profesor Cursuri

preda

Constrangeri de cardinelitate in relatii

Acestea specifica un anumit numar de obiecte din clasa ce participa in relatie.

Pt. specificarea cardinalelor avem tipurile de semne;

un numar

gama de numere    4

* (arata ca in relatie avem 0) default

cand toate obiectele din clasa adiacenta participa la relatie