Inginerie soft - modelarea aplicațiilor soft

Modelarea reprezinta o metoda utilizata în stiinta si tehnica care consta în reproducerea schematica a unui obiect sau sistem sub forma unui sistem similar sau analog, în scopul studierii proprietatilor si transformarilor structurii originale.

Modelarea informatiilor = Obiecte + Atribute + Relatii + Supertipuri/Subtipuri +Obiecte asociative.

1. Modelul Cascadei

1.1 Cum a aparut Modelul Cascadei?

Modelul cascada se considera a fi primul model introdus si folosit pe scara larga în inginerie soft. Inovatia adusa de acest model consta în împartirea pentru întâia oara, a procesului de dezvoltare a programelor, în faze distincte.

Modelul cascada impune o abordare sistematica, secventiala, a dezvoltarii softului, abordare care porneste de la sistem si parcurge etape de analiza, proiectare, programare, testare si întretinere. Modelul are în vedere întregul ciclu de viata al produsului, exista evaluari pentru fiecare etapa si posibilitati de revenire la etape sau de reluare a ciclului de viata, într-o faza de evolutie ulterioara.

Originea termenului “cascada” este un articol publicat în anul 1970 de catre W.W. Royce. Partea amuzanta este ca Royce propunea în acel articol o abordare iterativa a dezvoltarii softului si nici macar nu a folosit termenul de “cascada”, el descriind ceea ce azi cunoastem ca fiind modelul “cascada” ca fiind o metoda riscanta, un adevarat “magnet” pentru erori. În ciuda intentiilor lui Royce de a modifica modelul cascada într-un model iterativ, utilizarea sa ca un proces pur secvential este înca populara, iar pentru unii “modelul cascada” a ajuns sa defineasca orice abordare inflexibila si non-iterativa de dezvoltare a produselor software. Majoritatea acestor persoane vad “modelul cascada” ca fiind naiv si nepotrivit pentru procesele din “lumea reala”.

1.2 Fazele Modelului Cascada

1.2.1 Definirea si analiza cerintelor (Requirement Analysis & Definition):

În aceasta faza se colecteaza toate cerintele pe care sistemul trebuie sa le îndeplineasca. Ca si în alte modele de procese, cerintele sunt împartite în cerinte functionale si constrângeri pe care sistemul trebuie sa le respecte. Cerintele trebuie sa fie colectate prin analiza nevoilor clientului si verificarea lor pentru a fi valide si posibi de implementat. Scopul acestei etape este generarea Documentului de Specificatie a Cerintelor care este utilizat ca „input” pentru urmatoarea faza.

1.2.2 Designul sistemului (System Design):

Sistemul trebuie sa fie bine descris înainte ca implementarea sa înceapa. Aceasta implica un design arhitectural care defineste si descrie principalele componente ale sistemului, ale interfetei si interactiunile dintre ele. Se prezinta hardware-ul necesar, iar software-ul este împartit pe componente: definirea sau selectia unei platforme, unui sistem de operare, a altor componente hardware periferice, etc. Componentele software trebuie alese în functie de nevoile clientilor. Scopul acestei faze este de a genera un Document pentru Arhitectura Sistemului (System Arhitecture Document) care sa serveasca ca „input” pentru faza de design software a dezvoltarii, dar si ca un „input” pentru design-ul hardware sau selectia activitatilor.

Figura 1.1 Modelul Cascada (The Waterfall Model”)

1.2.3 Design-ul Software (Software Design):

Bazat pe arhitectura sistemului care a definit principalele parti software, design-ul software le va imparti în module de cod. Interfetele si interactiunile modulelor vor fi descrise, precum si functionalitatile lor. Toate modurile sistemului (startup, shutdown, conditiile de eroare si diagnosticul), activitatea si starile acestuia trebuie definite. Output-ul acestei faze este un Document de Design Software care este si baza implementarii ce urmeaza a fi facuta.

1.2.4 Codarea (Coding):

Bazata pe Documentul pentru Arhitectura Sistemului, consta în setarea modulelor sau unitatile definite prin procesul de codare. Sistemul este în primul rând dezvoltat din parti mici numite unituri. Ele sunt create independent din punct de vedere functional si sunt integrate apoi în form, în pachetul software complet.

1.2.5 Integrarea si Verificarea Software (Software Integration & Verification):

Fiecare unitate este prelucrata independent si poate fi testata pentru functionalitatea sa. Acest procedeu se numeste Testarea Unitatii si prin el se verifica daca modulele sau uniturile se încadreaza în specificatii. Procedeul implica teste functionale la nivel de interfata, dar si teste mai detaliate în structura interna a modulelor software. În timpul integrarii, uniturile prelucrate si testate pentru functionalitatile lor sunt combinate si integrate într-un sistem complet, care ulterior este supus testelor pentru a verifica daca functioneaza conform asteaptarilor.