Ce este CASE-TOOLS
Inginerie) sunt instrumente
Automatizare proiectare IC.
CASE TOOLS sunt tehnici de inginerie software pentru
proiecta software, care
face posibilă furnizarea calitate superioară programe,
fara erori si intretinere usoara
produse software.
CASE este, de asemenea, înțeles ca un set de fonduri
proiectarea sistemelor informatice cu
folosind instrumentele CASE.

Fonduri de caz

Instrumentele de caz includ orice software care
automatizează diverse etape ciclu de viață
Software-ul are următoarele caracteristici:
1. Există un instrument grafic puternic pentru
Descriere IS care oferă confort de lucru
utilizator,
2. Există integrare componente individuale
Caz înseamnă
3. Se utilizează stocarea centralizată
Depozitul de date de proiectare.

Funcții de proiectare care sunt cel mai adesea automatizate în cadrul instrumentelor CASE:

-
analiza și formularea cerințelor IP;
proiectare baze de date și aplicații;
generaţie codul programului;
testare;
Asigurarea Calității Software-ul;
managementul configurației IS;
management de proiect etc.

Rezultatul utilizării instrumentelor CASE:

optimizarea structurii IS;
costuri reduse de dezvoltare;
îmbunătățirea eficienței SI;
reducând probabilitatea erorilor când
Design IS.

Arhitectura unui instrument tipic Case

repertoriu

Miezul oricărui sistem de inginerie software este depozitul.
Depozitul este o bază de date specializată,
care este folosit pentru a afișa starea sistemului în orice moment
timp și conține informații despre toate obiectele proiectului ESTE:
Numele designerilor și drepturile lor de acces,
structuri organizate,
Componentele diagramei și diagrama în general,
structuri de date,
Relații între diagrame,
Module de program, proceduri și biblioteci de module.

Clasificarea fondurilor Modern Case:

1. Clasificarea fondurilor de caz după
metodologii suportate:
-
funcțional sau orientat pe structură;
-
orientat pe obiecte;
-
orientat spre complex.

2. Clasificarea fondurilor Modern Case după tip:

Reflectă orientarea funcțională a fondurilor pentru
proceselor ciclu de viață dezvoltare de software
Securitate:
instrumente de analiză – concepute pentru a construi și
analiza modelului de domeniu;
instrumente de proiectare a bazelor de date;
instrumente de dezvoltare a aplicațiilor;
Instrumente de reinginerire a proceselor;
instrumente de planificare și management de proiect;
instrumente de testare;
instrumente de documentare.

Exemple de instrumente Case de diferite tipuri:

Instrumente de analiză (Design, BpWin);
Instrumente de analiză și proiectare (Designer - Oracle);
Instrumente de proiectare a bazelor de date (ErWin, Designer - Oracle);
Instrumente de dezvoltare a aplicațiilor (Developer - Oracle,
Delphi);
Reproiectarea instrumentelor (ErWin, Rational Rose).

3. Clasificarea fondurilor Modern Case pe categorii:

Definește funcțiile îndeplinite de instrumente și include:
individual fonduri locale, rezolvarea mici autonome
sarcini, un set de instrumente parțial integrate care acoperă
majoritatea etapelor ciclului de viață și complet integrate
instrumente care acoperă întregul ciclu de viață al informațiilor
sisteme și conectate printr-un depozit comun.
Instrumentele tipice CASE sunt:
instrumente de management al configurației;
instrumente de modelare a datelor;
instrumente de analiză și proiectare;
instrumente de conversie a modelelor;
instrumente de editare a codului;
generatoare de coduri;
instrumente pentru construirea diagramelor UML.

Alte tipuri de clasificare a mijloacelor de caz:

4.
Clasificarea instrumentelor de caz după suport
notații grafice;
5.
Clasificarea mijloacelor de caz după grad
integrarea instrumentelor individuale;
6.
Clasificarea instrumentelor de caz după tip și arhitectură
tehnologie informatică utilizată;
7.
Clasificarea mijloacelor de caz după tipul de colectiv
evoluții;
8.
Clasificarea case-instrumente după tipul utilizat
Mediul de operare.

Atunci când alegeți fondurile Case, luați în considerare următoarele aspecte:

Disponibilitatea unei baze de date, arhive sau dicționar;
Disponibilitatea interfețelor cu alte sisteme Case;
Abilitatea de a exporta și importa informații;
Arhitectură deschisă;
Disponibilitatea metodologiilor necesare;
Disponibilitatea instrumentelor grafice de suport pentru proiecte;
Posibilitatea generarii automate de cod a programelor;
Abilitatea de a planifica și gestiona un proiect.

Case Tool Universal Modeling Language UML

Crearea limbajului UML a urmărit următoarele obiective:
oferi dezvoltatorilor un singur limbaj vizual
modelare;
asigurarea mecanismelor de extindere și specializare a limbii;
asigurarea independenței limbajului față de limbajele de programare și
procesele de dezvoltare.

Relația diagramelor UML

Diagrama de optiuni
utilizare
Diagramă
secvente
Diagramă
clase
Diagramă
cooperare
Diagramă
componente
Diagramă
state
Diagramă
implementare
Diagramă
Activități

Instrumentul IBM Rational Rose Case

Rational Rose este un instrument de analiză modern și puternic,
modelarea si dezvoltarea sistemelor software,
care acoperă întregul ciclu de viață al software-ului
de la analiza proceselor de afaceri până la generarea de coduri
limbajul de programare dat.
Un astfel de arsenal permite nu numai proiectarea unui nou
sistem informatic, dar și să modifice cel vechi,
prin procesul de inginerie inversă.

Principalele caracteristici ale pachetului Rational Rose:

inginerie directă și inversă în limbi: ADA,
Java, C, C++, Basic;
suport pentru tehnologii COM, DDL, XML;
capacitatea de a genera scheme de baze de date Oracle și SQL.

Versiuni de produs Rational Rose:

Ediția Rational Rose Modeler vă permite să analizați procesele de afaceri și
proiectează sistemul. Dar nu acceptă generarea de cod.
Rational Rose Professional editie In functie de limbajul de programare selectat
vă permite să efectuați inginerie directă și inversă. Comandat doar in
configurație specifică (de exemplu, Rose Professional C++ sau Rose Professional C++
Data Modeler). Nu generează cod executabil 100%. Drept urmare, dezvoltatorul primește
cod cadru al unui sistem informatic într-o limbă specifică (ordonată).
programare, care ulterior trebuie dezvoltată în continuare.
Ediția Rational Rose RealTime este concepută special pentru a fi executabilă 100%.
cod în timp real, vă permite să efectuați înainte și înapoi
proiectarea în C sau C++. La ieșire, modelul este compilat automat
și este compilat într-un fișier executabil.
Versiunea Rational Rose Enterprise Această versiune a produsului acoperă întreaga gamă de sarcini pentru
proiectare, analiză și generare de cod. Toate funcțiile altora sunt acceptate
ediții, cu excepția posibilității de generare a codului 100%.
Versiunea Rational Rose DataModeler este o variantă de produs de proiectare a bazei de date.
Caracteristicile DataModeler sunt incluse cu Rose Enterprise sau Professional.
În pachet MS Studio vizual Visual Modeler construit 6.0 - o versiune trunchiată a Rational Rose 98.

Informații suplimentare despre pachetul Rational Rose:

Versiunea gratuită a produsului Rational Rose nu este
există;
pentru instituțiile de învățământ toate programele
Software-ul IBM este disponibil gratuit;
utilizare gratuită în scopuri educationale poate
ca parte a Inițiativei Academice IBM.

Modelele ierarhice CASE corespund mult mai bine dimensiunii mari a problemei. Acronimul CASE (Computer-Aided Software/System Engineering) înseamnă proiectarea de software sau sisteme bazate pe suport computerizat.

Tehnologia CASE este o zonă actuală și în curs de dezvoltare a creării CAD în domeniul produselor software și sistemelor de procesare a informațiilor. Practic, niciun produs software străin major nu este creat în prezent fără utilizarea instrumentelor CASE.

Dintre sistemele casnice create cu ajutorul CASE-tools, trebuie remarcat sistemul BOSS-CORPORATION al IT Co. La toate etapele de realizare a acestui sistem au fost utilizate instrumente de dezvoltare aparținând familiei Oracle 2000 (Designer/2000, Developer/200, Programmer/2000).

Domeniul de aplicare al CASE-tehnologii se referă la crearea, în primul rând, de sisteme informaționale economice, ceea ce se explică prin natura de masă a acestor sisteme.

De remarcat faptul că tehnologiile CASE sunt folosite nu numai pentru a crea sisteme automate de control, ci și pentru a dezvolta modele de sisteme care ajută la luarea deciziilor în domeniul planificarii strategice, managementului financiar al companiei, pregătirii personalului etc. Această zonă de aplicare a tehnologiilor CASE și-a primit propriul nume - analiză de afaceri.

Tehnologiile CASE sunt de asemenea folosite acolo unde problemele domeniului sunt foarte complexe, de exemplu, în dezvoltarea software-ului de sistem.

Luați în considerare bazele metodologice ale tehnologiilor CASE.

Baza metodologiei CASE este modelarea. Tehnologia CASE este o metodă model pentru automatizarea proiectării sistemului.

Tehnologia CASE se bazează pe paradigma: metodologie - metoda - notatie - mijloace

Metodologia definește abordări generale ale evaluării și selecției unei opțiuni de sistem, succesiunea etapelor și etapelor de proiectare, abordări ale alegerii metodelor.

Metoda specifică ordinea proiectării componentelor individuale ale sistemului (de exemplu, sunt cunoscute metode de proiectare a fluxurilor de date în sistem, stabilirea specificațiilor (descrierilor) proceselor, reprezentarea structurilor de date în stocare etc.).

Notațiile sunt mijloace grafice de notare și reguli concepute pentru a descrie structura unui sistem, etapele de procesare a informațiilor, structurile de date etc. Notațiile includ grafice, diagrame, tabele, organigrame, limbaje formale și naturale.

În cele din urmă, instrumentele sunt instrumente, instrumente de automatizare a proiectării sub formă de produse software pentru furnizarea unui mod de proiectare interactiv (crearea și editarea unui proiect grafic al unui sistem informațional) și generarea de coduri de program (crearea automată a codurilor de program de sistem).

Metodologia de proiectare bazată pe suport informatic necesită evident construirea unei descrieri formalizate a sistemului informațional sub forma unui model informațional. Construirea unui model CASE al sistemului prevede descompunerea sistemului și ordonarea ierarhică a subsistemelor descompuse.

Modelul sistemului ar trebui să reflecte:

Partea funcțională a sistemului;

Relații între date;

Starea sistemului trece în timpul funcționării în timp real. Pentru a modela un sistem informatic sub aceste trei aspecte se folosesc trei tipuri de instrumente grafice cu anumite notatii.

1. Diagrame de flux de date - DFD (Data Flow Diagrams). Ele sunt utilizate împreună cu dicționarele de date și specificațiile de proces.

2. Diagrame entitate-relație - ERD (Entity Relationship Diagrams), care arată relațiile dintre date.

3. Diagrame de tranziție de stat - STD (State Transitign Diagrams) pentru a reflecta comportamentul dependent de timp al sistemului (în timp real).

Rolul principal în modelare îi revine DFD.

DFD este conceput pentru a reflecta relația dintre sursele de date și receptorii (așa-numitele entități externe în raport cu sistemul informațional), fluxurile de date, procesele de prelucrare (procesele de calcul corespunzătoare funcțiilor sistemului), stocările de date (stocarele).

Reprezentarea grafică a diagramei fluxului de date pe ecranul de afișare oferă claritatea modelării și confortul ajustării principalelor componente ale modelului în mod interactiv.

Deoarece reprezentarea grafică nu este suficientă pentru a identifica cu exactitate componentele unui DFD, sunt utilizate descrieri textuale și alte mijloace de specificare a proceselor de prelucrare și a structurilor de date.

Astfel, fluxurile de date sunt specificate în ceea ce privește structura lor în dicționarele de date. Fiecare proces (funcție de sistem) poate fi analizat folosind un DFD de nivel scăzut, unde este împărțit în mai multe procese, în timp ce fluxurile de date sunt analizate în același timp.

Detalierea procesului se termină atunci când descrierea fiecărui proces detaliat poate fi făcută folosind metoda de scriere a algoritmului de proces aleasă. Specificația procesului conține numărul și numele procesului, liste de nume de date de intrare și de ieșire din dicționarul de date și un algoritm de proces care transformă fluxurile de date de intrare în fluxuri de date de intrare. Tehnologia CASE folosește astfel de metode pentru setarea algoritmilor de proces precum:

descriere text;

Limbajul natural structurat;

tabele de decizie;

Arbori de decizie;

limbaje vizuale;

Limbaje de programare.

Limbajele de programare (C, Cobol etc.) provoacă dificultăți în scrierea algoritmilor pentru DFD, deoarece necesită utilizarea dicționarelor de date pe lângă fluxurile de date și necesită ajustarea sincronă a specificațiilor procesului în timpul ajustării DFD.

Limbajul natural structurat este ușor de înțeles nu numai de designeri și programatori, ci și de utilizatorii finali. Acesta este meritul lui. Cu toate acestea, nu oferă generarea automată a codului din cauza ambiguităților.

Tabelele și arborii de decizie, deși reflectă vizual conexiunea unei combinații de condiții cu acțiunile necesare, nu au capacități procedurale pentru generarea de cod a programelor.

Limbajul vizual oferă generarea automată a codului, dar specificațiile procesului prezentate cu ajutorul lor sunt greu de ajustat.

Conținutul fiecărui depozit de date reprezentat în diagrama fluxului de date este descris de un dicționar de date și un model de date ERD. În cazul funcționării sistemului în timp real, DFD este completat de STD.

Structura ierarhică a modelului CASE este prezentată în fig. 11.9.

Un principiu metodologic important al tehnologiei CASE pentru crearea unui sistem informațional este o împărțire clară a procesului de creare a unui sistem în 4 etape:

Pre-proiect (etapa de analiză, prototipare și construirea unui model al cerințelor pentru sistem);

Proiectare, care implică proiectarea logică a sistemului (fără programare);

Etapa de programare (inclusiv proiectarea bazei de date fizice);

Post-proiect, inclusiv punerea în funcțiune, operarea și întreținerea sistemului.

În etapa de pre-proiectare, se construiește un model de cerințe pentru sistem, adică o descriere detaliată a ceea ce ar trebui să facă, fără a specifica modul în care cerințele vor fi implementate.

La etapa de proiect se perfecționează modelul cerințelor (dezvoltarea unui model ierarhic detaliat bazat pe DFD și specificații de proces) și extinderea acestuia la modelul de implementare la nivel logic. La finalul acestei etape are loc un control atent al proiectului la nivelul modelului logic de implementare.

Următoarea etapă (programare) este proiectarea fizică a sistemului. Această etapă prevede generarea automată a codului în conformitate cu specificațiile proceselor software de sistem și designul fizic al bazei de date.

Etapa finală post-proiect începe cu teste de acceptare. Aceasta este urmată de punerea în funcțiune, întreținerea și dezvoltarea sistemului.

Secvența operațiilor de realizare a unui sistem informațional bazat pe tehnologia CASE este prezentată în fig. 11.10.

Luați în considerare factorii de eficiență ai tehnologiei CASE.

1. Trebuie remarcat faptul că tehnologia CASE creează o oportunitate și asigură transferul centrului de greutate în complexitatea creării unui sistem la etapele de pre-proiectare și proiectare. Elaborarea atentă a acestor etape într-un mod interactiv cu suport informatic reduce numărul posibile eroriîn proiectare, care sunt greu de corectat în etapele ulterioare.

2. Forma grafică a reprezentării modelului, accesibilă pentru înțelegere de către utilizatorii non-programatori, face posibilă implementarea principiului designului utilizatorului, care prevede participarea utilizatorilor la crearea sistemului. Modelul CASE permite obținerea înțelegerii reciproce între toți participanții la crearea sistemului (clienți, utilizatori, designeri, programatori).

3. Prezența unui model formalizat al sistemului în etapa de pre-proiectare creează o oportunitate de analiză multivariată cu prototipare și o evaluare aproximativă a eficacității opțiunilor. Analiza sistemului prototip vă permite să ajustați viitorul sistem înainte ca acesta să fie implementat fizic. Această abordare accelerează și reduce costul creării unui sistem.

4. Fixarea cerințelor de sistem într-o formă oficială scutește proiectanții de nevoia de a face numeroase ajustări la noile cerințe ale utilizatorilor.

5. Separarea proiectării sistemului de programare creează stabilitatea soluțiilor de proiectare pentru implementare pe diferite platforme software și hardware.

6. Prezența unui model formal de implementare a sistemului și a instrumentelor de automatizare adecvate permite generarea automată a codului software-ului de sistem și crearea unei structuri raționale a bazei de date.

7. In stadiul de functionare a sistemului devine posibila efectuarea de modificari la nivel de model, fara a se face referire la textele programelor, eventual de catre fortele specialistilor din departamentul de automatizari a firmei.

8. Modelul de sistem poate fi folosit nu numai ca bază pentru crearea sa, ci și în scopul instruirii automate a personalului folosind diagrame.

9. Pe baza modelului sistemului actual, analiza de business poate fi efectuată pentru a sprijini deciziile de management și reinginerirea afacerii la schimbarea direcției companiei.

Luați în considerare instrumentele software care oferă tehnologia CASE. În funcție de scopul funcțional, acestea sunt împărțite în următoarele grupuri de clasificare, oferind:

Analiza si proiectarea sistemului informatic;

Proiectarea bazei de date;

Programare;

Întreținere și reinginerie;

Managementul procesului de proiectare.

Instrumentele de analiză și proiectare sunt utilizate pentru a construi un model CASE al sistemului de control actual și implementat. Ele sprijină construcția grafică și controlul modelului ierarhic al diagramelor fluxului de date și descrierea componentelor acestuia. Aceste instrumente permit analiștilor și proiectanților să acceseze baza de date a sistemului proiectat (depozitul).

Aceste instrumente includ: pachetul CASE intern. Analist, Design/IDEF (Meta Software), Dezvoltatorul (ASYST Technologies), etc.

Pentru a corespunde cerințelor utilizatorilor, sunt create prototipuri de interfețe cu utilizatorul, inclusiv meniuri, formulare de ecran și rapoarte sub formă de tabele sau grafice. Un exemplu de instrument software de interfață cu utilizatorul este Developer/2000 (Oracle).

Instrumentele de proiectare a bazelor de date asigură modelarea logică a datelor, conversia automată a modelelor de date la a treia formă normală și generarea de scheme de baze de date. Exemple de astfel de instrumente sunt Designer/2000 de la Oracle, ERWin (Logic Works), etc.

Instrumentele de programare acceptă generarea automată de cod din specificațiile procesului, testare și documentația programului. Acestea includ Programmer/2000 (Oracle), DECASE (DEC), APS (Software Sage), etc.

Instrumentele de întreținere și reinginerie vă permit să faceți modificări sistemului la nivel de model în condiții de afaceri în schimbare (Adpac CASE Tools de la Adpac etc.).

Instrumentele de management al procesului de proiectare sprijină planificarea și controlul unui set de lucrări de proiectare, precum și interacțiunea analiștilor, designerilor și programatorilor pe baza unei baze de date comune a proiectelor (de exemplu, Project Workbench by Applied Business Technology). Relevanța creării unui pachet integrat de instrumente care să susțină tehnologia CASE în toate etapele ciclului de viață al unui sistem informațional este evidentă.

Agenția Federală pentru Educație

stat federal instituție educaționalăÎnvățământ profesional superior „Universitatea de Stat Chuvash. I.N. Ulyanova»

Institutul Economic și Financiar

Facultatea de Economie

Rezumat pe subiect: CASE-tehnologii pentru proiectarea sistemelor informatice automatizate

Completat de un student

Grupe EK 22-06

Evgrafova I.A.

Verificat de: Pavlova S.Yu.

Ceboksary 2007

Introducere…………………………………………………………………..3

Ciclul de viață al software-ului sistemului informațional………………………………………………………………….5

Tehnologii RAD pentru aplicații de prototipare…………...7

· Metoda structurală de dezvoltare software……10

Literatură folosită………………………………………..17

Introducere

În ultimul deceniu, s-a format o nouă direcție în ingineria software - CASE (Computer-Aided Software / System Engineering) - în traducere literală - dezvoltarea software-ului sistemelor informaționale cu sprijinul (cu ajutorul) unui computer. În prezent nu există o definiție general acceptată a CASE, termenul CASE este folosit într-un sens foarte larg. Sensul inițial al termenului CASE, limitat la problemele de automatizare a dezvoltării numai a software-ului, a căpătat acum un nou sens, acoperind procesul de dezvoltare a sistemelor informatice automatizate complexe în ansamblu. Acum, termenul CASE-tools se referă la instrumentele software care sprijină procesele de creare și menținere a SI, inclusiv analiza și formularea cerințelor, proiectarea aplicațiilor software (aplicații) și baze de date, generarea de cod, testare, documentare, asigurare a calității, management al configurației și managementul proiectelor, precum și alte procese. Instrumentele CASE, împreună cu software-ul și hardware-ul de sistem, formează un mediu complet de dezvoltare AIS.

Instrumentele CASE permit nu numai crearea produselor „corecte”, ci și furnizarea procesului „corect” de creare a acestora. Scopul principal al CASE este acela de a separa proiectarea software-ului de codare și etapele ulterioare de dezvoltare, precum și de a ascunde de dezvoltatori toate detaliile mediului de dezvoltare a software-ului și de funcționare. Atunci când se utilizează tehnologii CASE, toate etapele ciclului de viață al software-ului (mai multe despre aceasta vor fi discutate mai jos) ale sistemului informațional se modifică, cele mai mari modificări referitoare la etapele de analiză și proiectare. Majoritatea instrumentelor CASE existente se bazează pe metodologii de analiză și proiectare structurale (în cea mai mare parte) sau orientate pe obiecte, folosind specificații sub formă de diagrame sau texte pentru a descrie cerințele externe, relațiile dintre modelele de sistem, dinamica comportamentului sistemului și arhitecturile software. Astfel de metodologii oferă o descriere riguroasă și vizuală a sistemului proiectat, care începe cu privirea generală a acestuia și apoi detaliile, dobândind o structură ierarhică cu toate un numar mare niveluri. Tehnologiile CASE sunt folosite cu succes pentru a construi aproape toate tipurile de sisteme software, dar ocupă o poziție stabilă în următoarele domenii:

♦ asigurarea dezvoltării de software de afaceri și comercial, utilizarea pe scară largă a tehnologiilor CASE datorită caracterului de masă al acestei zone de aplicații, în care CASE este utilizat nu numai pentru dezvoltarea de software, ci și pentru crearea modelelor de sistem care ajută la rezolvarea problemelor de planificarea strategică, managementul financiar, determinarea politicii firmelor, instruirea personalului etc. (această direcție și-a primit propriul nume - analiză de afaceri);

♦ dezvoltarea de software de sistem și control. Utilizarea activă a tehnologiilor CASE este asociată cu marea complexitate a acestei probleme și cu dorința de a crește eficiența muncii.

CASE nu este o revoluție în inginerie software, ci rezultatul dezvoltării evolutive naturale a întregii industrii de instrumente, numite anterior instrumentale sau tehnologice. De la bun început, tehnologiile CASE au evoluat pentru a depăși limitările utilizării metodologiilor de proiectare structurală din anii 60 și 70. Secolului 20 (complexitatea înțelegerii, intensitatea ridicată a forței de muncă și costul utilizării, dificultatea de a efectua modificări ale specificațiilor de proiectare etc.) datorită automatizării acestora și integrării instrumentelor suport. Astfel, tehnologiile CASE nu pot fi considerate metodologii independente, ci doar dezvoltă metodologii structurale și eficientizează aplicarea acestora prin automatizare.

Pe lângă automatizarea metodologiilor structurale și, ca urmare, posibilitatea utilizării metodelor moderne de inginerie de sistem și software, instrumentele CASE au următoarele avantaje principale:

♦ îmbunătățirea calității software-ului creat prin intermediul controlului automat (în primul rând control al proiectului);

♦ fac posibilă realizarea unui prototip al unui viitor sistem într-un timp scurt, ceea ce face posibilă evaluarea rezultatului așteptat într-un stadiu incipient;

♦ accelerarea procesului de proiectare și dezvoltare;

♦ eliberați dezvoltatorul de munca de rutină, permițându-i să se concentreze în totalitate pe partea creativă a dezvoltării;

♦ sprijinirea dezvoltării și menținerii dezvoltării;

♦ Sprijinirea tehnologiilor de reutilizare a componentelor de dezvoltare.

Apariția tehnologiei CASE și a instrumentelor CASE a fost precedată de cercetări în domeniul metodologiei de programare. Programarea a dobândit trăsăturile unei abordări sistematice cu dezvoltarea și implementarea de limbaje de nivel înalt, metode de programare structurată și modulară, limbaje de proiectare și instrumentele lor suport, limbaje de descriere formale și informale Cerințe de sistemşi caietul de sarcini etc. În anii 70-80. o metodologie structurală a început să fie aplicată în practică, oferind dezvoltatorilor metode strict formalizate pentru descrierea AIS și a acceptat - solutii tehnice. Se bazează pe o tehnică grafică vizuală: diagramele și diagramele sunt folosite pentru a descrie diferite tipuri de modele AIS. Vizibilitatea și rigoarea instrumentelor de analiză structurală au permis dezvoltatorilor și viitorilor utilizatori ai sistemului de la bun început să participe informal la crearea acestuia, să discute și să consolideze înțelegerea principalelor soluții tehnice. Cu toate acestea, utilizarea pe scară largă a acestei metodologii și respectarea recomandărilor sale în dezvoltarea AIS de contact a fost destul de rară, deoarece este practic imposibil cu dezvoltarea neautomatizată (manuală). Acest lucru a contribuit la apariția unei clase speciale de software și hardware - instrumente CASE care implementează tehnologia CASE pentru crearea și menținerea AIS.

Trebuie înțeles că utilizarea cu succes a instrumentelor CASE este imposibilă fără o înțelegere a tehnologiei de bază pe care se bazează aceste instrumente. În sine, instrumentele software CASE sunt instrumente pentru automatizarea proceselor de proiectare și întreținere a sistemelor informaționale. Fără înțelegerea metodologiei de proiectare IS, este imposibil să utilizați instrumentele CASE.

1. Ciclul de viață al software-ului sistemului informațional

Unul dintre conceptele de bază ale metodologiei de proiectare AIS este conceptul de ciclu de viață al software-ului său (software LC). Ciclul de viață al software-ului este un proces continuu care începe din momentul în care se ia o decizie cu privire la necesitatea creării acestuia și se termină în momentul retragerii complete din funcționare.

Structura ciclului de viață al software-ului se bazează pe trei grupuri de procese:

♦ principalele procese ale ciclului de viață al software-ului (achiziție, furnizare, dezvoltare, exploatare, întreținere);

♦ procese auxiliare care asigură implementarea principalelor procese (documentare, managementul configurației, asigurarea calității, verificarea, certificarea, evaluarea, auditul, rezolvarea problemelor);

♦ procese organizatorice (managementul de proiect, crearea infrastructurii proiectului, definirea, evaluarea și îmbunătățirea ciclului de viață în sine, instruire).

Dezvoltarea include toate lucrările de creare a software-ului și a componentelor acestuia în conformitate cu cerințele specificate, inclusiv pregătirea documentației de proiectare și operaționale, pregătirea materialelor necesare pentru a testa operabilitatea și calitatea corespunzătoare a produselor software, materialele necesare pentru organizarea personalului instruire etc. Dezvoltarea software include de obicei analiză, proiectare și implementare (programare).

Funcționarea include lucrări privind implementarea componentelor software în funcțiune, inclusiv configurarea bazei de date și a stațiilor de lucru ale utilizatorilor, furnizarea de documentație operațională, efectuarea de instruire a personalului etc. și operarea directă, inclusiv localizarea problemelor și eliminarea cauzelor apariției acestora, modificarea software-ului în cadrul reglementari stabilite, intocmirea propunerilor de imbunatatire, dezvoltare si modernizare a sistemului.

Managementul proiectelor este legat de problemele de planificare și organizare a muncii, crearea de echipe de dezvoltatori și monitorizarea timpului și calității muncii efectuate.

Sprijinul tehnic și organizatoric al proiectului include alegerea metodelor și instrumentelor de implementare a proiectului, definirea metodelor de descriere a stărilor intermediare de dezvoltare, dezvoltarea de metode și instrumente pentru testarea software-ului, pregătirea personalului etc. Asigurarea calității proiectului este asociată cu probleme de verificare, verificare și testare software. Verificarea este procesul prin care se stabilește dacă starea actuală de dezvoltare atinsă într-o anumită etapă îndeplinește cerințele etapei respective. Validarea vă permite să evaluați conformitatea parametrilor de dezvoltare cu cerințele originale. Verificarea se suprapune cu testarea, care se preocupă de identificarea diferențelor dintre rezultatele reale și cele așteptate și de evaluarea dacă caracteristicile software îndeplinesc cerințele originale. În procesul de implementare a proiectului, problemele de identificare, descriere și control al configurației componentelor individuale și a întregului sistem în ansamblu ocupă un loc important.

Managementul configurației este unul dintre procesele auxiliare care susțin procesele principale ale ciclului de viață al software-ului, în primul rând procesele de dezvoltare și întreținere software. La crearea unor proiecte IS complexe constând din multe componente, fiecare dintre ele putând avea varietăți sau versiuni, se pune problema luării în considerare a relațiilor și funcțiilor acestora, crearea unei structuri unificate și asigurarea dezvoltării întregului sistem. Managementul configurației vă permite să organizați, să luați în considerare sistematic și să controlați modificările aduse software-ului în toate etapele ciclului de viață. Principiile generale și recomandările pentru contabilitatea configurației, planificarea și gestionarea configurațiilor software sunt reflectate în proiectul standardului ISO 12207-2.

Fiecare proces este caracterizat de anumite sarcini și metode de rezolvare a acestora, datele inițiale obținute în etapa anterioară și rezultatele. Rezultatele analizei, în special, sunt modele funcționale, modele de informații și diagramele corespunzătoare. Ciclul de viață al software-ului este de natură iterativă: rezultatele etapei următoare provoacă adesea schimbări în deciziile de proiectare dezvoltate în etapele anterioare.

Modelele de ciclu de viață existente determină ordinea de execuție a etapelor în timpul dezvoltării, precum și criteriile de trecere de la o etapă la alta. În conformitate cu aceasta, următoarele trei modele de ciclu de viață sunt cele mai utilizate pe scară largă:

♦ model în cascadă (1970-1980) - oferă trecerea la etapa următoare după finalizarea lucrărilor la etapa anterioară;

♦ model în etape cu control intermediar (1980-1985) - un model iterativ de dezvoltare software cu bucle de feedback între etape. Avantajul acestui model este că ajustările între etape asigură o intensitate mai mică a forței de muncă în comparație cu modelul în cascadă, totuși, durata de viață a fiecărei etape este prelungită pe întreaga perioadă de dezvoltare;

♦ model în spirală (1986-1990) - pune accent pe etapele inițiale ale ciclului de viață: analiza cerințelor, proiectarea caietului de sarcini, proiectarea preliminară și detaliată. În aceste etape se verifică și se justifică fezabilitatea soluțiilor tehnice prin realizarea de prototipuri. Fiecare tură a spiralei corespunde unui model pas cu pas pentru crearea unui fragment sau a unei versiuni a unui produs software, pe care sunt specificate obiectivele și caracteristicile proiectului, calitatea acestuia este determinată și munca următoarei ture a spirala este planificată. Astfel, detaliile proiectului sunt aprofundate și concretizate în mod consecvent, iar în consecință, este selectată o opțiune rezonabilă, care este adusă la implementare.

Experții notează următoarele avantaje ale modelului în spirală:

♦ acumulare și reutilizare instrumente software, modele și prototipuri;

♦ concentrarea pe dezvoltarea și modificarea software-ului în procesul de proiectare a acestuia;

♦ analiza riscului și costurilor în procesul de proiectare.

caracteristica principală Industria de dezvoltare software constă în concentrarea complexității în etapele inițiale ale ciclului de viață (analiza, proiectare) cu complexitate relativ scăzută și intensitatea muncii a etapelor ulterioare. Mai mult, problemele nerezolvate și erorile făcute în fazele de analiză și proiectare dau naștere la probleme dificile, adesea de nerezolvat în etapele ulterioare și, în cele din urmă, duc la eșecul întregului proiect.

2. RAD - tehnologii de prototipare a aplicațiilor

Una dintre posibilele abordări ale dezvoltării software în cadrul modelului ciclului de viață în spirală este metodologia recent utilizată pe scară largă pentru dezvoltarea rapidă a aplicațiilor RAD (Rapid Application Development). Acest termen se referă de obicei la un proces de dezvoltare software care conține trei elemente:

♦ echipă mică de programatori (de la 2 la 10 persoane);

♦ program de producție scurt, dar atent elaborat (de la 2 la 6 luni);

♦ un ciclu iterativ în care dezvoltatorii, pe măsură ce aplicația începe să prindă contur, solicită și implementează în produs cerințele primite prin interacțiunile cu clientul.

Echipa de dezvoltare ar trebui să fie un grup de profesioniști cu experiență în analiză, proiectare, generare de cod și testare software folosind instrumente CASE. Membrii echipei trebuie să fie capabili să transforme propunerile utilizatorilor finali în prototipuri funcționale.

Ciclul de viață al software-ului conform metodologiei RAD constă din patru faze:

♦ fazele de analiză și planificare a cerințelor;

♦ faze de proiectare;

♦ faze de construcție;

♦ faze de implementare.

În etapa de analiză și planificare a cerințelor, utilizatorii sistemului determină funcțiile pe care trebuie să le îndeplinească, evidențiază cea mai mare prioritate dintre acestea care necesită elaborarea în primul rând și descriu nevoile de informații. Determinarea cerințelor este efectuată în principal de utilizatori sub îndrumarea dezvoltatorilor specialiști. Amploarea proiectului este limitată, se determină intervalul de timp pentru fiecare dintre fazele ulterioare. În plus, se determină însăși posibilitatea implementării acestui proiect în cadrul de finanțare stabilit, pe aceste hardware etc.. Rezultatul acestei etape ar trebui să fie o listă și prioritate a funcțiilor viitorului AIS, modele preliminare funcționale și informaționale ale IS.

În timpul fazei de proiectare, unii utilizatori participă la proiectarea tehnică a sistemului sub îndrumarea dezvoltatorilor specialiști. Instrumentele CASE sunt folosite pentru a obține rapid prototipuri de aplicații funcționale. Utilizatorii, interacționând direct cu aceștia, clarifică și completează cerințele pentru sistem care nu au fost identificate în faza anterioară. Procesele sistemului sunt analizate mai detaliat. Modelul funcțional este analizat și, dacă este necesar, corectat. Fiecare proces este luat în considerare în detaliu. Dacă este necesar, se creează un prototip parțial pentru fiecare proces elementar: un ecran, un dialog, un raport care elimină ambiguitățile sau ambiguitățile. Sunt determinate cerințele de diferențiere a accesului la date. În aceeași fază se stabilește setul de documentație necesară.

După o definire detaliată a compoziției proceselor, numărul de elemente functionale a sistemului dezvoltat și se ia decizia de a împărți AIS în subsisteme care pot fi implementate de o echipă de dezvoltatori într-un timp acceptabil pentru proiectele RAD - aproximativ 60-90 de zile. Folosind CASE-tools, proiectul este distribuit între diferite echipe (modelul funcțional este împărțit). Această fază ar trebui să aibă ca rezultat:

♦ modelul informativ general al sistemului;

♦ modele funcționale ale sistemului în ansamblu și subsisteme implementate de echipele individuale de dezvoltare;

♦ Interfețe definite de CASE între subsisteme dezvoltate autonom;

♦ a construit prototipuri de ecrane, rapoarte, dialoguri.

Toate modelele și prototipurile trebuie obținute folosind acele instrumente CASE care vor fi utilizate ulterior la construirea sistemului. Această cerință datorită faptului că, în abordarea tradițională, la transferul informațiilor despre proiect de la o etapă la alta, poate apărea o distorsiune a datelor practic necontrolată. Utilizarea unui singur mediu de stocare a informațiilor despre proiect evită acest pericol.

Spre deosebire de abordarea tradițională, care folosea instrumente specifice de prototipare care nu sunt destinate construirii de aplicații reale și prototipurile aruncate după ce au finalizat sarcina de a elimina ambiguitățile din proiect, în abordarea RAD, fiecare prototip este dezvoltat într-o parte. viitorul sistem. Astfel, informații mai complete și utile sunt transmise în faza următoare.

În timpul fazei de construire, dezvoltarea rapidă a aplicației în sine se realizează direct. În această fază, dezvoltatorii construiesc în mod iterativ un sistem real pe baza modelelor obținute în faza anterioară, precum și a cerințelor nefuncționale. Codul programului este parțial generat folosind generatoare automate care primesc informații direct din depozitul de instrumente CASE. Utilizatorii finali din această fază evaluează rezultatele obținute și efectuează ajustări dacă, în timpul procesului de dezvoltare, sistemul nu mai îndeplinește cerințele definite anterior. Testarea sistemului se realizează direct în procesul de dezvoltare.

După finalizarea lucrărilor fiecărei echipe individuale de dezvoltare, această parte a sistemului este integrată treptat cu restul, se formează un cod de program complet și se efectuează testarea. munca în comun această parte a aplicației cu restul și apoi testarea sistemului ca întreg. Proiectarea fizică a sistemului este în curs de finalizare:

♦ se determină necesitatea distribuirii datelor;

♦ se efectuează o analiză a utilizării datelor;

♦ proiectarea fizică a bazei de date;

♦ sunt determinate cerințele pentru resursele hardware;

♦ sunt identificate modalităţi de creştere a productivităţii;

♦ elaborarea documentaţiei proiectului este în curs de finalizare. Rezultatul fazei este un sistem finit care satisface toate cerințele convenite.

În faza de implementare se realizează instruirea utilizatorilor, modificări organizaționale și, în paralel cu introducerea noului sistem, se lucrează cu sistemul existent (până la implementarea completă a noului sistem). Deoarece faza de construire este relativ scurtă, planificarea și pregătirea pentru implementare trebuie să înceapă devreme, de obicei în timpul fazei de proiectare a sistemului.

Schema de mai sus pentru dezvoltarea AIS nu este absolută. Posibil diverse opțiuniîn funcţie, de exemplu, de condiții inițiale unde are loc dezvoltarea: dacă se dezvoltă un sistem complet nou; dacă s-a efectuat o anchetă de informare a organizației și dacă există un model al activității acesteia; dacă există un AIS în organizație care poate fi folosit ca prototip inițial sau ar trebui integrat cu cel în curs de dezvoltare etc.

Totuși, trebuie menționat că metodologia RAD, ca oricare alta, nu poate pretinde a fi universală, este bună în primul rând pentru proiecte relativ mici dezvoltate pentru un anumit client. Dacă se dezvoltă un sistem tipic, care nu este un produs finit, ci este un complex de componente tipice, întreținute la nivel central, adaptate platformelor software și hardware, DBMS, telecomunicații, caracteristici organizatorice și economice ale obiectelor de implementare și integrate cu dezvoltările existente, vin în prim-plan parametrii proiectului, cum ar fi gestionabilitatea și calitatea, care pot intra în conflict cu ușurința și viteza de dezvoltare. Astfel de proiecte necesită un nivel ridicat de planificare și o disciplină strictă de proiectare, respectarea strictă a protocoalelor și interfețelor prestabilite, ceea ce reduce viteza de dezvoltare.

Metodologia RAD nu este aplicabilă construcției de programe complexe de calcul, sisteme de operare sau programe de control nave spațiale, adică programe care necesită scrierea unei cantități mari (sute de mii de linii) de cod unic.

Aplicațiile care nu au o parte pronunțată de interfață care definește clar logica funcționării sistemului (de exemplu, aplicații în timp real) și aplicațiile care afectează siguranța oamenilor (de exemplu, controlul unei aeronave sau al unei centrale nucleare) sunt nu este potrivit pentru dezvoltare folosind metodologia RAD, deoarece o abordare iterativă presupune că primele versiuni nu vor fi cel mai probabil complet funcționale, ceea ce în acest caz exclus. Principiile de bază ale metodologiei RAD:

♦ dezvoltarea aplicaţiilor prin iteraţii;

♦ opțională finalizarea completă a lucrărilor la fiecare etapă a ciclului de viață;

♦ Implicarea obligatorie a utilizatorilor în dezvoltarea AIS;

♦ utilizarea necesară a instrumentelor CASE care asigură integritatea proiectului;

♦ utilizarea instrumentelor de management al configurației care facilitează introducerea modificărilor în proiect și întreținerea sistemului finit;

♦ utilizarea necesară a generatoarelor de cod;

♦ utilizarea prototipurilor pentru a înțelege mai bine și a satisface nevoile utilizatorului final;

♦ testarea si dezvoltarea proiectului, realizata concomitent cu dezvoltarea;

♦ dezvoltare condusă de o echipă de profesioniști restrânsă, bine gestionată;

♦ management competent al dezvoltării sistemului, planificare clară și control al muncii.

3. Metodă structurală de dezvoltare software

Esență abordare structurală la dezvoltarea AIS constă în descompunerea (partiționarea) acestuia în funcții automate: sistemul este împărțit în subsisteme funcționale, care, la rândul lor, sunt împărțite în subfuncții, subdivizate în sarcini și așa mai departe. Procesul de partiţionare continuă până la proceduri specifice. În același timp, sistemul automatizat păstrează o viziune holistică în care toate componentele sunt interconectate. La dezvoltarea unui sistem de jos în sus, de la sarcini individuale la întregul sistem, integritatea se pierde, apar probleme în andocarea informațională a componentelor individuale.

Toate metodologiile de analiză structurală se bazează pe un număr de principii generale, dintre care unele reglementează organizarea muncii în etapele inițiale ale ciclului de viață, iar unele sunt utilizate în elaborarea recomandărilor pentru organizarea muncii. Ca doi principii de baza se folosesc: principiul „împarte și cuceri” și principiul ordonării ierarhice. Primul este principiul rezolvării problemelor dificile prin împărțirea lor în multe probleme mai mici, independente, care sunt mai ușor de înțeles și rezolvat. Al doilea principiu declară că aranjarea acestor părți este, de asemenea, esențială pentru înțelegere. Nivelul de înțelegere a problemei crește brusc atunci când părțile sale sunt prezentate sub forma unui copac. structuri ierarhice, adică sistemul poate fi înțeles și construit pe niveluri, fiecare dintre acestea adăugând noi detalii.

Selectarea a două principii de bază ale ingineriei software nu înseamnă că celelalte principii sunt secundare, ignorarea oricăruia dintre ele poate duce la consecințe imprevizibile (inclusiv eșecul întregului proiect). Să aruncăm o privire la câteva dintre principiile principale.

1. Principiul abstracției - constă în evidențierea unor aspecte ale sistemului care sunt semnificative din unele poziții și abstracția de la cele neesențiale pentru a prezenta problema într-o formă generală simplă.

2. Principiul formalizării – constă în necesitatea unei abordări metodologice riguroase a rezolvării problemei.

3. Principiul „ascunderii” – este de a ascunde informații care nu sunt esențiale la o anumită etapă: fiecare parte „știe” doar informațiile de care are nevoie.

4. Principiul comunității conceptuale – este de a urma o singură filozofie în toate etapele ciclului de viață (analiza structurală – proiectare structurală – programare structurală – testare structurală).

5. Principiul completității – este de a controla prezența elementelor redundante.

6. Principiul consistenței – este valabilitatea și consistența elementelor.

7. Principiul independenței logice – este să se concentreze asupra designului logic pentru a asigura independența față de designul fizic.

8. Principiul independenței datelor – este că modelele de date trebuie analizate și proiectate independent de procesele de prelucrare logică a acestora, precum și de structura și distribuția lor fizică.

9. Principiul structurării datelor – este că datele trebuie să fie structurate și organizate ierarhic.

10. Principiul accesului utilizatorului final – este ca utilizatorul trebuie sa aiba acces la baza de date, pe care o poate folosi direct (fara programare).

Respectarea acestor principii este necesară atunci când se organizează munca în etapele inițiale ale ciclului de viață, indiferent de tipul de software dezvoltat și de metodologiile utilizate. Ghidat de toate principiile dintr-un complex, este posibil în stadiile anterioare de dezvoltare să înțelegem ce va fi sistem în curs de creare, pentru a detecta greșelile și neajunsurile, care, la rândul lor, vor facilita munca în etapele ulterioare ale ciclului de viață și vor reduce costurile de dezvoltare.

În analiza structurală sunt utilizate în principal două grupe de instrumente, ilustrând funcțiile îndeplinite de sistem și relațiile dintre date. Fiecare grup de instrumente corespunde anumitor tipuri de modele (diagrame), dintre care cele mai comune sunt următoarele:

♦ SADT (Structured Analysis and Design Technique) - modele și diagrame funcționale aferente;

♦ DFD (Data Flow Diagrams) - diagrame de flux de date;

♦ ERD (Entity-Relationship Diagrams) - diagrame „entity-relationship”;

♦ STD (State Transition Diagrams) - diagrame de tranziție de stări.

În faza de proiectare a IS, modelele sunt extinse, rafinate și completate cu diagrame care reflectă structura software-ului: arhitectura software, diagrame bloc ale programelor și diagrame cu forme de ecran.

Modele listateîmpreună oferă o descriere completă a AIS, indiferent dacă acesta este existent sau nou dezvoltat. Compoziția diagramelor în fiecare caz particular depinde de caracterul complet necesar al descrierii sistemului.

Metodologie SADT

Metodologia SADT a fost dezvoltată de Douglas Ross; pe baza acesteia, a fost dezvoltată binecunoscuta metodologie IDEFO (Icam Definition), care este partea principală a programului Icam (Integration of Computer and Industrial Technologies) inițiat de Statele Unite. Metodologia SADT este un set de metode, reguli și proceduri concepute pentru a construi un model funcțional al unui obiect în orice domeniu. Modelul funcțional SADT afișează structura funcțională a unui obiect, adică acțiunile pe care le efectuează și relațiile dintre aceste acțiuni. Elementele principale ale acestei metodologii se bazează pe următoarele concepte:

♦ reprezentare grafică modelarea blocurilor. Grafica blocurilor și arcelor din diagrama SADT afișează funcția ca bloc, iar interfețele de intrare/ieșire sunt reprezentate de arce care intră și, respectiv, ies din bloc. Interacțiunea blocurilor între ele este descrisă prin intermediul arcelor de interfață care exprimă „constrângeri”, care, la rândul lor, determină când și cum sunt efectuate și controlate funcțiile;

♦ rigoare și precizie. Implementarea regulilor SADT necesită suficientă rigoare și precizie fără a impune restricții nejustificate asupra acțiunilor analistului.

Regulile SADT includ:

♦ limitarea numărului de blocuri la fiecare nivel de descompunere (regula blocurilor 3-b);

♦ conectivitatea diagramelor (numere de blocuri);

♦ unicitatea etichetelor și numelor (absența numelor duplicate);

♦ reguli sintactice pentru grafică (blocuri și arce);

♦ separarea intrărilor și controalelor (regula pentru determinarea rolului datelor);

♦ separarea organizaţiei de funcţie, adică excluderea influenţei structurii organizatorice asupra modelului funcţional.

Metodologia SADT poate fi utilizată pentru a modela o gamă largă de sisteme și pentru a defini cerințele și funcțiile, apoi pentru a proiecta un sistem care satisface acele cerințe și implementează acele funcții. Pentru deja sistemele existente SADT poate fi folosit pentru a analiza funcțiile îndeplinite de sistem, precum și pentru a indica mecanismele prin care acestea sunt realizate.

Rezultatul aplicării metodologiei SADT este un model care constă din diagrame, fragmente de text și un glosar care au legături între ele. Diagramele sunt componentele principale ale modelului, toate funcțiile și interfețele IS sunt prezentate ca blocuri și arce. Punctul de conectare al arcului cu blocul determină tipul de interfață. Informațiile de control intră în bloc din partea de sus, în timp ce informațiile care sunt procesate sunt afișate în partea stângă a blocului, iar rezultatele de ieșire sunt afișate în partea dreaptă. Mecanismul (sistem uman sau automatizat) care efectuează operația este reprezentat de un arc care intră în bloc de jos (Fig. 1.6.1).

Una dintre cele mai importante caracteristici ale metodologiei SADT este introducerea treptată a unor niveluri crescânde de detaliu pe măsură ce sunt create diagramele care reprezintă modelul.

Construcția modelului SADT începe cu reprezentarea întregului sistem sub forma celei mai simple componente - un bloc și arce reprezentând interfețe cu funcții în afara sistemului. Deoarece un singur bloc reprezintă întregul sistem ca întreg, numele dat în bloc este generic. Acest lucru este valabil și pentru arcurile de interfață - ele reprezintă, de asemenea, setul complet de interfețe externe ale sistemului ca întreg.

Apoi blocul care reprezintă sistemul ca un singur modul este detaliat într-o altă diagramă folosind mai multe blocuri conectate prin arcuri de interfață. Aceste blocuri reprezintă principalele subfuncții ale funcției originale. Această descompunere dezvăluie un set complet de subfuncții, fiecare dintre acestea fiind reprezentată ca un bloc, ale căror limite sunt definite de arce de interfață. Fiecare dintre aceste sub-funcții poate fi descompusă într-un mod similar pentru o vedere mai detaliată.

În toate cazurile, fiecare subfuncție poate conține doar acele elemente care sunt incluse în functia originala. În plus, modelul nu poate omite niciun element, adică, așa cum sa menționat deja, așa-numitul bloc părinte și interfețele sale oferă context. Nimic nu poate fi adăugat la el și nimic nu poate fi îndepărtat din el.

Modelul SADT este o serie de diagrame cu documentație însoțitoare care se defalcă obiect complexîn părți componente, care sunt prezentate sub formă de blocuri. Detaliile fiecăruia dintre blocurile principale sunt afișate ca blocuri în alte diagrame. La fiecare pas de descompunere, diagrama mai generală se numește părintele diagramei mai detaliate.

Arcele care intră și ies din casetă din diagrama de nivel superior sunt exact aceleași cu arcele care intră în diagramă nivel inferiorși ieșind din el, deoarece blocul și diagrama reprezintă aceeași parte a sistemului.

Unele arce sunt atașate blocurilor diagramei la ambele capete, în timp ce altele au un capăt neconectat. Arcurile neconectate corespund intrărilor, comenzilor și ieșirilor blocului părinte. Sursa sau destinația acestor arce de limită poate fi găsită numai în diagrama părinte. Capetele libere trebuie să se potrivească cu arcurile de pe graficul original. Toate arcurile de graniță trebuie să continue pe diagrama părinte pentru ca aceasta să fie completă și consecventă.

Diagramele SADT nu indică în mod explicit nici secvența, nici timpul. Feedback-urile, iterațiile, procesele în desfășurare și funcțiile care se suprapun (în timp) pot fi descrise folosind arcuri. Feedback-ul poate fi sub formă de comentarii, observații, corecții etc.

După cum sa menționat, mecanismele (arcurile de pe partea inferioară) arată mijloacele prin care sunt îndeplinite funcțiile. Mecanismul poate fi un om, un computer sau orice alt dispozitiv care ajută la îndeplinirea unei anumite funcții.

Fiecare bloc din diagramă are propriul său număr. Un bloc al oricărei diagrame poate fi descris în continuare printr-o diagramă de nivel inferior, care, la rândul său, poate fi detaliată cu numărul necesar de diagrame. Astfel, se formează o ierarhie de diagrame. Pentru a indica poziția oricărei diagrame sau bloc în ierarhie, se folosesc numerele diagramei.

Modelarea fluxurilor de date (procese)

Instrumentul principal de simulare cerințe funcționale AIS sunt diagrame de flux de date (DFD: - Diagrame de flux de date). Cu ajutorul lor, aceste cerințe sunt defalcate în componente funcționale (procese) și prezentate ca o rețea conectată prin fluxuri de date. obiectivul principal astfel de instrumente trebuie să demonstreze modul în care fiecare proces își transformă intrările în ieșiri și să identifice relațiile dintre aceste procese.

În conformitate cu metodologia, modelul de sistem este definit ca o ierarhie de diagrame de flux de date (DFD, sau DFD) care descriu procesul asincron de transformare a informațiilor de la intrarea acesteia în sistem până la emiterea acesteia către utilizator. Diagramele nivelurilor superioare ale ierarhiei (diagramele de context) definesc principalele procese sau subsisteme ale SI cu intrări și ieșiri externe. Ele sunt detaliate folosind diagrame de nivel inferior. Această descompunere continuă, creând o ierarhie de diagrame pe mai multe niveluri, până când se ajunge la un astfel de nivel de descompunere la care procesele devin elementare și este imposibil să le detaliem mai departe.

Sursele de informații (entități externe) generează fluxuri de informații (fluxuri de date) care transferă informații către subsisteme sau procese. Aceștia, la rândul lor, transformă informațiile și generează noi fluxuri care transferă informații către alte procese sau subsisteme, acumulatori de date sau entități externe – consumatori de informații. Astfel, principalele componente ale diagramelor de flux de date sunt:

♦ entități externe;

♦ sisteme/subsisteme;

♦ procese;

♦ dispozitive de stocare a datelor;

♦ fluxuri de date.

O entitate externă este un obiect material sau individual A care reprezintă sursa sau destinația informațiilor, cum ar fi clienți, personal, furnizori, clienți, stoc. Definirea unui obiect sau a unui sistem ca entitate externă indică faptul că acesta se află în afara granițelor AIS analizate.

Procesul este transformarea fluxurilor de date de intrare în cele de ieșire în conformitate cu un anumit algoritm. Din punct de vedere fizic, procesul poate fi implementat în diverse moduri: poate fi o subdiviziune a unei organizații (departament) care procesează documente de intrare și emite rapoarte, un program, un dispozitiv logic implementat hardware etc. În diferite notații, procesul poate fi reprezentate pe diagrame în moduri diferite. Numărul procesului este utilizat pentru a-l identifica. În câmpul nume, numele procesului este introdus ca o propoziție cu un verb activ fără ambiguitate în formă nedefinită (calculați, calculați, verificați, determinați, creați, primiți), urmat de substantive în cazul acuzativ, de exemplu:

♦ „Introduceți informații despre clienți”;

♦ „Oferiți informații despre cheltuielile curente”;

♦ „Verifică bonitatea clientului”.

Utilizarea verbelor precum „procesează”, „modernizează” sau „editează” înseamnă de obicei că nu există o înțelegere suficientă profundă a acestui proces și necesită o analiză suplimentară.

V În ultima vreme se obișnuiește, de asemenea, să se utilizeze câmpul de implementare fizică, informația în care arată ce departament al organizației, program sau dispozitiv hardware efectuează acest proces.

Stocarea (unitatea de date) este un dispozitiv abstract pentru stocarea informațiilor care pot fi plasate în unitate în orice moment și recuperate după un anumit timp, iar metodele de plasare și regăsire pot fi oricare.

Dispozitivul de stocare a datelor poate fi implementat fizic sub forma unei microfișe, un sertar într-un dulap de fișiere, un tabel în RAM, un fișier pe medii magnetice etc. Unitatea de date este identificată prin litera „D” și un număr arbitrar. Numele unității este ales din punctul de vedere al celui mai mare conținut de informații pentru designer.

Unitatea de date este, în general, un prototip al viitoarei baze de date, iar descrierea datelor stocate în ea ar trebui să fie legată de modelul de informații. Fluxul de date definește informațiile transmise printr-o conexiune de la sursă la receptor. Fluxul real de date poate fi informații transmise printr-un cablu între două dispozitive, trimise prin scrisori de poștă, benzi magnetice sau dischete, transferate de la un computer la altul etc.

Fluxul de date din diagramă este reprezentat de o linie care se termină cu o săgeată care arată direcția. Fiecare flux de date are un nume care reflectă conținutul său.

Primul pas în construirea unei ierarhii DFD este construirea diagramelor de context. De obicei, la proiectarea unui AIS relativ simplu, se construiește o singură diagramă de context cu o topologie în stea, în centrul căreia se află așa-numitul proces principal, conectat la receptori și surse de informații prin care utilizatorii și alții interacționează cu sistemul. sisteme externe. Pentru AIS complexe, se construiește o ierarhie de diagrame de context. În același timp, diagrama contextului de nivel superior nu conține un singur proces principal, ci un set de subsisteme conectate prin fluxuri de date. Diagramele de context de nivel următor detaliază contextul și structura subsistemelor.

Ierarhia diagramelor de context definește interacțiunea principalului subsisteme funcționale proiectat AIS atât între ele, cât și cu fluxuri de date externe de intrare și ieșire și obiecte externe (surse și receptori de informații) cu care interacționează AIS.

Dezvoltarea diagramelor de context rezolvă problema definirii stricte a structurii funcționale a AIS în cea mai timpurie etapă a proiectării sale, care este deosebit de importantă pentru sistemele multifuncționale complexe, în dezvoltarea cărora. diferite organizațiiși echipele de dezvoltare.

După construirea diagramelor de context, modelul rezultat trebuie verificat pentru caracterul complet al datelor inițiale privind obiectele sistemului și izolarea obiectelor (lipsa legăturilor de informații cu alte obiecte). Pentru fiecare subsistem prezent pe diagramele de context, acesta este detaliat folosind DFD. Fiecare proces de pe un DFD, la rândul său, poate fi detaliat folosind un DFD sau o mini-specificație. La detaliere, trebuie respectate următoarele reguli:

♦ regulă de echilibrare - înseamnă că la detalierea unui subsistem sau proces, diagrama de detaliere ca surse/receptoare externe de date poate avea doar acele componente (subsisteme, procese, entități externe, acumulatori de date) cu care are subsistemul sau procesul detaliat din diagrama părinte. link-uri informative;

♦ regulă de numerotare - înseamnă că la detalierea proceselor, numerotarea lor ierarhică ar trebui să fie suportată. De exemplu, proceselor care detaliază numărul de proces 12 li se atribuie numerele 12.1, 12.2, 12.3 și așa mai departe.

Mini-specificația (descrierea logicii procesului) ar trebui să își formuleze principalele funcții în așa fel încât în ​​viitor specialistul care implementează proiectul să le poată realiza sau să dezvolte un program adecvat.

Mini-specificația este vârful final al ierarhiei DFD. Decizia de a completa detaliul procesului și de a utiliza mini-specificația este luată de analist pe baza următoarelor criterii:

♦ procesul are un număr relativ mic de fluxuri de date de intrare și de ieșire (2-3 fluxuri);

♦ posibilitatea de a descrie transformarea datelor printr-un proces în formă algoritm secvenţial;

♦ executarea prin procesul singurei funcţii logice de conversie a informaţiilor de intrare în informaţii de ieşire;

♦ posibilitatea de a descrie logica procesului folosind o mini-specificare a unui volum mic (nu mai mult de 20-30 de linii).

Când se construiește o ierarhie DFD, ar trebui să se procedeze la detalierea proceselor numai după ce s-a determinat conținutul tuturor fluxurilor și depozitelor de date, care este descris folosind structurile de date. Structurile de date sunt construite din elemente de date și pot conține alternative, condiționale și iterații. Apariția condiționată înseamnă că această componentă poate să nu fie prezentă în structură. Alternativ înseamnă că unul dintre elementele enumerate poate fi inclus în structură. Iterația înseamnă introducerea oricărui număr de elemente în intervalul specificat. Pentru fiecare element de date poate fi specificat tipul acestuia (date continue sau discrete). Pentru datele continue, se pot specifica unitatea de măsură (kg, cm etc.), domeniul de valori, precizia reprezentării și forma codificării fizice. Pentru date discrete, se poate specifica un tabel valori admise.

După construirea unui model de sistem complet, acesta trebuie verificat. Într-un model complet, toate obiectele sale (subsisteme, procese, fluxuri de date) trebuie descrise și detaliate în detaliu. Obiectele nedetaliate identificate trebuie detaliate prin revenirea la etapele de dezvoltare anterioare. Într-un model consistent, toate fluxurile de date și depozitele de date trebuie să se supună regulii de conservare a informațiilor: toate datele primite undeva trebuie citite și toate datele citite trebuie scrise.

Modelarea datelor

Scopul modelării datelor este de a oferi dezvoltatorului AIS o schemă conceptuală a bazei de date sub forma unuia sau mai multor modele. modele locale, care poate fi mapat relativ ușor pe orice sistem de baze de date.

Cel mai comun instrument de modelare a datelor este Entity-Relationship Diagrams (ERD). Cu ajutorul lor se determină obiectele (entitățile) importante pentru domeniul subiectului, proprietățile (atributele) și relațiile lor între ele (legături). ERD-urile sunt utilizate direct pentru a proiecta baze de date relaționale (vezi Sec. 2.2).

Notația ERD a fost introdusă pentru prima dată de P. Chen și dezvoltată în continuare de Barker.

Metodologie IDEF 1

Metoda IDEF1, dezvoltată de T. Ramey, se bazează tot pe abordarea lui P. Chen și vă permite să construiți un model de date echivalent cu un model relațional în a treia formă normală. În prezent, pe baza îmbunătățirii metodologiei IDEF1, aceasta o noua versiune- Metodologia IDEF1X. IDEF1X este proiectat având în vedere ușurința de învățare și automatizare. Diagramele IDEF IX sunt utilizate de un număr de instrumente CASE comune (de exemplu, ERWin, Design/IDEF).

Referințe

Fedotova D.E. CAZ - tehnologii: manual - M: Hotline - Telecom, 2007

Trofimov V.E., Lobacheva I.N. Sistemele informaționale în economie - M: Unity-Dana, 2008

· Baldin N.V., Utkin V.B. Sisteme și tehnologii informaționale în economie - M: Unity, 2007

Titorenko T.A. Tehnologii informatice automatizate în economie - M: Unity, 2006

Baranovskaya T.P., Loiko V.I., Semenov M.I., Trubilin I.T. Tehnologii informatice automatizate în economie - M: Finanțe și statistică, 2006

1.3.1. Cerințe generale pentru metodologie și tehnologie

Metodologiile, tehnologiile și instrumentele de proiectare (CASE-tools) stau la baza oricărui proiect IS. Metodologia este implementată prin tehnologii specifice și standardele, metodologiile și instrumentele suport ale acestora care asigură implementarea proceselor ciclului de viață.

Tehnologia de proiectare este definită ca o combinație a trei componente:

• o procedură pas cu pas care determină succesiunea operațiunilor de proiectare tehnologică (Fig. 1.4);
• criteriile și regulile utilizate pentru evaluarea rezultatelor operațiunilor tehnologice;
• notații (grafice și instrumente de text) folosit pentru a descrie sistemul proiectat.

Orez. 1.4. Reprezentarea funcționării tehnologice de proiectare

Instrucțiunile tehnologice, care alcătuiesc conținutul principal al tehnologiei, ar trebui să includă o descriere a secvenței operațiilor tehnologice, condițiile în funcție de care se efectuează una sau alta operație și descrieri ale operațiunilor în sine.

Tehnologia pentru proiectarea, dezvoltarea și întreținerea SI trebuie să îndeplinească următoarele cerințe generale:

• tehnologia trebuie să suporte întregul ciclu de viață al software-ului;
• tehnologia ar trebui să asigure realizarea garantată a obiectivelor dezvoltării SI cu o calitate dată și la un moment dat;
• tehnologia ar trebui să ofere posibilitatea realizării proiectelor mari sub formă de subsisteme (adică posibilitatea descompunerii proiectului în părți componente dezvoltate de grupuri de executanți de un număr limitat cu integrarea ulterioară a părților componente). Experiența dezvoltării unui SI mare arată că, pentru a crește eficiența muncii, este necesar să se împartă proiectul în subsisteme separate, care sunt slab conectate în ceea ce privește datele și funcțiile. Implementarea subsistemelor ar trebui efectuată de grupuri separate de specialiști. În același timp, este necesar să se asigure coordonarea întregului proiect și să se excludă dublarea rezultatelor muncii fiecărui grup de proiect, care poate apărea din cauza prezenței datelor și funcțiilor comune;
• tehnologia ar trebui să ofere posibilitatea de a efectua lucrări de proiectare a subsistemelor individuale în grupuri mici (3-7 persoane). Acest lucru se datorează principiilor managementului echipei și creșterii productivității prin minimizarea numărului de legături externe;
• tehnologia ar trebui să ofere timpul minim pentru obținerea unui IS funcțional. Nu este vorba despre momentul pregătirii întregului IS, ci despre momentul implementării subsistemelor individuale. Implementarea IP în general într-un timp scurt poate necesita implicarea un numar mare dezvoltatori, în timp ce efectul poate fi mai mic decât atunci când subsistemele individuale sunt implementate într-un timp mai scurt de un număr mai mic de dezvoltatori. Practica arată că, chiar și în prezența unui proiect complet finalizat, implementarea decurge constant pentru subsisteme individuale;
• tehnologia ar trebui să prevadă posibilitatea de a gestiona configurația proiectului, menținerea versiunilor proiectului și ale componentelor acestuia, posibilitatea emiterii automate a documentației de proiect și sincronizarea versiunilor acestuia cu versiunile de proiect;
• tehnologia trebuie să asigure independența soluțiilor de proiectare executate față de mijloacele de implementare a SI (sisteme de management al bazelor de date (DBMS), sisteme de operare, limbaje și sisteme de programare);
• tehnologia ar trebui să fie susținută de un set de instrumente CASE coordonate care asigură automatizarea proceselor efectuate în toate etapele ciclului de viață. Abordare generală la evaluarea și selecția instrumentelor CASE este descrisă în Secțiunea 4, exemple de complexe de instrumente CASE - în Secțiunea 5.7.

Aplicarea efectivă a oricărei tehnologii pentru proiectarea, dezvoltarea și întreținerea SI într-o anumită organizație și într-un anumit proiect este imposibilă fără dezvoltarea unui număr de standarde (reguli, acorduri) care trebuie respectate de toți participanții la proiect. Aceste standarde includ următoarele:

• standard de proiectare;
• standard de documentație de proiectare;
• standard de interfață cu utilizatorul.

Standardul de proiectare ar trebui să precizeze:

• trusa modelele necesare(diagrame) la fiecare etapă de proiectare și nivelul lor de detaliu;
• reguli pentru stabilirea deciziilor de proiectare pe diagrame, inclusiv: reguli de numire pentru obiecte (inclusiv convenții terminologice), un set de atribute pentru toate obiectele și reguli de completare a acestora în fiecare etapă, reguli de proiectare a diagramelor, inclusiv cerințe pentru forma și dimensiunea obiectelor , etc.;
• cerințe pentru configurarea stațiilor de lucru pentru dezvoltatori, inclusiv setări sistem de operare, setările instrumentului CASE, Setari generale proiect etc.;
• un mecanism pentru asigurarea lucrului în comun asupra unui proiect, inclusiv: reguli pentru integrarea subsistemelor de proiect, reguli pentru menținerea unui proiect în aceeași stare pentru toți dezvoltatorii (regulamente pentru schimbul de informații despre proiect, un mecanism de fixare a obiectelor comune etc.), reguli pentru verificarea coerenței deciziilor de proiectare etc. d.

Standardul de documentație de proiectare ar trebui să stabilească:

• completitudinea, compoziția și structura documentației la fiecare etapă de proiectare;
• cerințe pentru proiectarea acestuia (inclusiv cerințe pentru conținutul secțiunilor, subsecțiunilor, paragrafelor, tabelelor etc.),
• reguli de pregătire, revizuire, aprobare și aprobare a documentației, cu indicarea termenelor pentru fiecare etapă;
• cerințe pentru crearea unui sistem de publicare utilizat ca instrument de pregătire a documentației încorporat;
• cerințe pentru personalizarea CASE-tools pentru a asigura pregătirea documentației în conformitate cu cerințele stabilite.

Standardul de interfață cu utilizatorul ar trebui să precizeze:

• reguli de proiectare a ecranului (fonturi și paletă de culori), compoziția și aranjarea ferestrelor și comenzilor;
• reguli de utilizare a tastaturii și a mouse-ului;
• reguli pentru formatarea textelor de ajutor;
• lista de mesaje standard;
• regulile de procesare a reacțiilor utilizatorului.

CASE-instrumente pentru proiectarea sistemelor informatice

În condițiile moderne, complexitatea creării sistemelor informaționale este foarte mare. Prin urmare, în proiectarea circuitelor integrate, tehnologia CASE a devenit acum utilizată pe scară largă.

Tehnologia CASE este un pachet software care automatizează întregul proces tehnologic de analiză, proiectare, dezvoltare și întreținere a instrumentelor software complexe.

Instrumentele moderne CASE acoperă o gamă largă de suport pentru numeroase tehnologii de proiectare IC: de la mijloace simple analiză și documentare la instrumente de automatizare la scară completă care acoperă întregul ciclu de viață al software-ului.

Cele mai consumatoare etape ale dezvoltării SI sunt etapele de analiză și proiectare, timp în care CASE-tools oferă soluții tehnice de înaltă calitate și pregătirea documentației de proiect. În același timp, instrumentele de modelare a domeniului grafic joacă un rol important, care permit dezvoltatorilor să studieze vizual IS-ul existent, să îl reconstruiască în conformitate cu obiectivele și limitările existente.

Instrumentele CASE integrate au următoarele trasaturi caracteristice :

· asigurarea managementului procesului de dezvoltare a SI;

Utilizarea unui depozit special organizat de metadate ale proiectului (depozitar).

Instrumentele CASE integrate conțin următoarele componente:

· analiză grafică și instrumente de proiectare utilizate pentru a descrie și documenta IS;

Instrumente de dezvoltare a aplicațiilor, inclusiv limbaje de programare și generatoare de cod;

un depozit care oferă stocarea versiunilor proiectului în curs de dezvoltare și a componentelor sale individuale, sincronizarea informațiilor primite de la diverși dezvoltatori în timpul dezvoltării grupului, controlul metadatelor pentru completitudine și coerență;

· instrumente de management pentru dezvoltarea SI;

mijloace de documentare;

instrumente de testare;

Instrumente de reproiectare care oferă analiza codurilor de program și a schemelor de baze de date și formarea pe baza acestora diverse modeleși specificații de proiectare.

Toate instrumentele moderne CASE sunt împărțite în două grupuri. primul grup organizați instrumente integrate în sistemul de implementare, în care toate deciziile de proiectare și implementare sunt legate de sistemul de management al bazei de date selectat. al doilea grup organizarea mijloacelor independente de sistemul de implementare, în care toate deciziile de proiectare sunt concentrate pe unificare etapele inițiale ciclul de viață și mijloacele de documentare a acestora. Aceste instrumente oferă o mai mare flexibilitate în alegerea mijloacelor de implementare.

Principal demnitate CASE-tehnologii - suport pentru lucrul în echipă pe un proiect datorită capacității de a lucra în el retea locala, export și import de fragmente de proiect individuale între dezvoltatori, management organizat de proiect.

La fel de etape crearea de produse software pentru sisteme informatice, se pot distinge următoarele:

1. Mediul de operare este determinat. În această etapă, se determină un set de procese ale ciclului de viață IS, se determină domeniul de aplicare al IS, se determină dimensiunea aplicațiilor suportate, de exemplu. restricții sunt stabilite pentru valori precum numărul de linii de cod de program, dimensiunea bazei de date, numărul de elemente de date, numărul de obiecte de control etc.

2. Se construiesc diagrame și analiza grafica. În această etapă se construiesc diagrame care stabilesc o conexiune cu sursele de informații și consumatorii, determină procesele de transformare a datelor și locațiile de stocare a acestora.

3. Se determină specificațiile și cerințele pentru sistem (tip de interfață, tip de date, structura sistemului, calitate, performanță, mijloace tehnice, costuri totale etc.).

4. Se realizează modelarea datelor, i.e. sunt introduse informații care descriu elementele de date ale sistemului și relațiile lor.

5. Se realizează modelarea proceselor, adică. sunt introduse informaţii care descriu procesele sistemului şi relaţiile dintre acestea.