Šta je CASE-TOOLS
Inženjering) su alati
Automatizacija IC dizajna.
CASE TOOLS su tehnike softverskog inženjeringa za
dizajn softver, koji
omogućiti da se obezbedi visoka kvaliteta programi,
bez grešaka i lako održavanje
softverskih proizvoda.
CASE se takođe shvata kao skup fondova
projektovanje informacionih sistema sa
koristeći CASE alate.

Slučaj znači

Alati za kućište uključuju bilo koji softver koji
automatizuje razne fazeživotni ciklus
Softver ima sljedeće karakteristike:
1. Postoji moćan grafički alat za
Opis IS koji omogućava praktičnost rada
korisnik,
2. Postoji integracija pojedinačne komponente
Slučaj znači
3. Koristi se centralizirano skladište
Repozitorijum projektnih podataka.

Dizajnirajte funkcije koje se najčešće automatiziraju unutar CASE alata:

-
analiza i formulacija zahtjeva za intelektualnu svojinu;
Dizajn baze podataka i aplikacija;
generacije programski kod;
testiranje;
osiguranje kvaliteta softvera;
Upravljanje konfiguracijom IS;
upravljanje projektima itd.

Rezultat korištenja CASE-alata:

optimizacija strukture IS-a;
smanjeni troškovi razvoja;
poboljšanje efikasnosti IS;
smanjenje vjerovatnoće grešaka kada
IS dizajn.

Arhitektura tipičnog alata Case

spremište

Srž svakog softverskog inženjerskog sistema je spremište.
Repozitorijum je specijalizovana baza podataka,
koji se koristi za prikaz stanja sistema u bilo kom trenutku
vrijeme i sadrži informacije o svim objektima projekta IS:
Imena dizajnera i njihova prava pristupa,
organizovane strukture,
Komponente grafikona i grafikon općenito,
strukture podataka,
Odnosi između dijagrama,
Programski moduli, procedure i biblioteke modula.

Klasifikacija fondova Modern Case:

1. Klasifikacija sredstava predmeta prema
podržane metodologije:
-
funkcionalno ili strukturno orijentisano;
-
objektno orijentisan;
-
kompleksno orijentisan.

2. Klasifikacija fondova Modern Case po vrstama:

Odražava funkcionalnu orijentaciju sredstava za
procesi životni ciklus razvoj softvera
sigurnost:
alati za analizu - dizajnirani za izgradnju i
analiza modela domena;
Alati za dizajn baze podataka;
Alati za razvoj aplikacija;
Alati za reinženjering procesa;
alati za planiranje i upravljanje projektima;
Alati za testiranje;
alati za dokumentaciju.

Primjeri alata Case različitih tipova:

Alati za analizu (Dizajn, BpWin);
Alati za analizu i dizajn (Dizajner - Oracle);
Alati za dizajn baze podataka (ErWin, Designer - Oracle);
Alati za razvoj aplikacija (Developer - Oracle,
Delphi);
Alati za reinženjering (ErWin, Rational Rose).

3. Klasifikacija fondova Modern Case po kategorijama:

Definira funkcije koje izvršavaju alati i uključuje:
odvojeno lokalni fondovi, rješavanje malih autonomnih
zadataka, skup djelomično integriranih alata koji pokrivaju
većinu faza životnog ciklusa i potpuno integrisani
alati koji pokrivaju čitav životni ciklus informacija
sistemi i povezani zajedničkim repozitorijumom.
Tipični CASE alati su:
Alati za upravljanje konfiguracijom;
Alati za modeliranje podataka;
alati za analizu i dizajn;
alati za konverziju modela;
Alati za uređivanje koda;
generatori kodova;
alati za pravljenje UML dijagrama.

Druge vrste klasifikacije padeža-znači:

4.
Klasifikacija alata za kućište prema podršci
grafičke oznake;
5.
Klasifikacija padežnih sredstava prema stepenu
integracija pojedinačnih alata;
6.
Klasifikacija alata kućišta prema vrsti i arhitekturi
korištena kompjuterska tehnologija;
7.
Klasifikacija padežnih sredstava prema vrsti kolektiva
razvoj;
8.
Klasifikacija kućišta-alata prema korištenoj vrsti
operativno okruženje.

Prilikom odabira fondova Case uzmite u obzir sljedeće aspekte:

Dostupnost baze podataka, arhive ili rječnika;
Dostupnost interfejsa sa drugim Case sistemima;
Mogućnost izvoza i uvoza informacija;
Otvorena arhitektura;
Dostupnost potrebnih metodologija;
Dostupnost grafičkih alata za podršku projektima;
Mogućnost automatskog generisanja koda programa;
Sposobnost planiranja i upravljanja projektom.

Alat za slučaj Univerzalni jezik za modeliranje UML

Stvaranje UML jezika imalo je sljedeće ciljeve:
omogućiti programerima jedan vizuelni jezik
modeliranje;
obezbijediti mehanizme za proširenje i specijalizaciju jezika;
osigurati nezavisnost jezika od programskih jezika i
razvojni procesi.

Odnos UML dijagrama

Dijagram opcija
koristiti
Dijagram
sekvence
Dijagram
casovi
Dijagram
saradnju
Dijagram
komponente
Dijagram
države
Dijagram
raspoređivanje
Dijagram
aktivnosti

IBM Rational Rose Case Tool

Rational Rose je moderan i moćan alat za analizu,
modeliranje i razvoj softverskih sistema,
pokrivaju čitav životni ciklus softvera
od analize poslovnih procesa do generisanja koda
dati programski jezik.
Takav arsenal omogućava ne samo dizajniranje novog
informacioni sistem, ali i modifikovati stari,
kroz proces obrnutog inženjeringa.

Glavne karakteristike paketa Rational Rose:

naprijed i nazad inženjering na jezicima: ADA,
Java, C, C++, Basic;
podrška za COM, DDL, XML tehnologije;
sposobnost generiranja Oracle i SQL shema baze podataka.

Verzije proizvoda Rational Rose:

Izdanje Rational Rose Modeler vam omogućava da analizirate poslovne procese i
dizajnirati sistem. Ali ne podržava generiranje koda.
Rational Rose Professional edition Ovisno o odabranom programskom jeziku
omogućava vam izvođenje naprijed i nazad inženjeringa. Naručeno samo u
specifična konfiguracija (na primjer, Rose Professional C++ ili Rose Professional C++
Data Modeler). Ne generiše 100% izvršni kod. Kao rezultat, programer dobiva
okvirni kod informacionog sistema na određenom (naručenom) jeziku
programiranje, koje kasnije treba dalje razvijati.
Izdanje Rational Rose RealTime je posebno dizajnirano da bude 100% izvršno.
kod u realnom vremenu, omogućava vam da izvršite napred i nazad
projektovanje u C ili C++. Na izlazu se model automatski kompajlira
i kompajlira se u izvršnu datoteku.
Rational Rose Enterprise verzija Ova verzija proizvoda pokriva čitav niz zadataka za
dizajn, analiza i generisanje koda. Podržane su sve funkcije drugih
izdanja, osim mogućnosti 100% generiranja koda.
Verzija Rational Rose DataModeler je varijanta proizvoda za dizajn baze podataka.
DataModeler karakteristike su uključene u Rose Enterprise ili Professional.
U MS paketu vizuelni studio 6.0 izgrađen Visual Modeler - skraćena verzija Rational Rose 98.

Dodatne informacije o paketu Rational Rose:

Besplatna verzija proizvoda Rational Rose nije
postoji;
za obrazovne ustanove sav softver
IBM softver je dostupan besplatno;
besplatno korištenje u obrazovne svrhe možda
kao dio IBM akademske inicijative.

Hijerarhijski CASE modeli mnogo bolje odgovaraju velikoj dimenziji problema. Akronim CASE (Computer-Aided Software/System Engineering) označava dizajn softvera ili sistema zasnovanih na računarskoj podršci.

CASE-tehnologija je aktuelna i intenzivno razvijajuća oblast kreiranja CAD-a u oblasti softverskih proizvoda i sistema za obradu informacija. Gotovo nijedan veći strani softverski proizvod trenutno nije kreiran bez upotrebe CASE-alata.

Među domaćim sistemima kreiranim korišćenjem CASE-alata, treba istaći sistem BOSS-CORPORATION IT Co. U svim fazama kreiranja ovog sistema korišćeni su razvojni alati koji pripadaju porodici Oracle 2000 (Designer/2000, Developer/200, Programmer/2000).

Obim CASE-tehnologija odnosi se na stvaranje, prije svega, ekonomskih informacionih sistema, što se objašnjava masovnošću ovih sistema.

Treba napomenuti da se CASE-tehnologije koriste ne samo za kreiranje automatizovanih kontrolnih sistema, već i za razvoj modela sistema koji pomažu u donošenju odluka u oblasti strateškog planiranja, finansijskog upravljanja kompanijom, obuke osoblja itd. Ovo područje primjene CASE-tehnologija dobilo je svoje ime - poslovna analiza.

CASE-tehnologije se koriste i tamo gde su problemi predmetne oblasti veoma složeni, na primer, u razvoju sistemskog softvera.

Razmotrite metodološke osnove CASE-tehnologija.

Osnova CASE metodologije je modeliranje. CASE tehnologija je model metoda za automatizaciju dizajna sistema.

CASE tehnologija je zasnovana na paradigmi: metodologija - metoda - notacija - sredstva

Metodologija definiše opšte pristupe evaluaciji i izboru opcije sistema, redosled faza i faza projektovanja, pristupe izboru metoda.

Metoda specificira redoslijed projektovanja pojedinih komponenti sistema (na primjer, poznate su metode za projektovanje tokova podataka u sistemu, postavljanje specifikacija (opisa) procesa, predstavljanje struktura podataka u memoriji itd.).

Notacije su grafička sredstva notacije i pravila dizajnirana da opišu strukturu sistema, korake obrade informacija, strukture podataka, itd. Notacije uključuju grafikone, dijagrame, tabele, dijagrame toka, formalne i prirodne jezike.

Konačno, alati su alati, alati za automatizaciju dizajna u obliku softverskih proizvoda za obezbeđivanje interaktivnog načina projektovanja (kreiranje i uređivanje grafičkog projekta informacionog sistema) i generisanje programskog koda (automatsko kreiranje sistemskih programskih kodova).

Metodologija projektovanja zasnovana na kompjuterskoj podršci očigledno zahteva izgradnju formalizovanog opisa informacionog sistema u obliku informacionog modela. Konstrukcija CASE-modela sistema omogućava dekompoziciju sistema i hijerarhijsko uređenje dekomponovanih podsistema.

Model sistema treba da odražava:

Funkcionalni dio sistema;

Odnosi između podataka;

Prelazi u stanje sistema tokom rada u realnom vremenu. Za modeliranje informacionog sistema u ova tri aspekta koriste se tri vrste grafičkih alata sa određenim notacijama.

1. Dijagrami toka podataka - DFD (Data Flow Diagrams). Koriste se zajedno sa rječnicima podataka i specifikacijama procesa.

2. Entitetski dijagrami odnosa - ERD (Entity Relationship Diagrams), koji prikazuju odnose između podataka.

3. Dijagrami tranzicije stanja - STD (State Transitign Diagrami) koji odražavaju ponašanje sistema ovisno o vremenu (u realnom vremenu).

Vodeća uloga u modeliranju pripada DFD-u.

DFD je dizajniran da odražava odnos izvora podataka i prijemnika (tzv. eksternih entiteta u odnosu na informacioni sistem), tokova podataka, procesa obrade (računarskih procesa koji odgovaraju funkcijama sistema), skladišta podataka (skladišta).

Grafički prikaz dijagrama toka podataka na ekranu pruža jasnoću modeliranja i pogodnost interaktivnog prilagođavanja glavnih komponenti modela.

Budući da grafički prikaz nije dovoljan za preciznu identifikaciju komponenti DFD-a, koriste se tekstualni opisi i drugi načini specificiranja procesa obrade i struktura podataka.

Dakle, tokovi podataka su specificirani u smislu njihove strukture u rječnicima podataka. Svaki proces (sistemska funkcija) može se razraditi pomoću DFD niskog nivoa, gdje je podijeljen na nekoliko procesa uz istovremenu analizu tokova podataka.

Detalji procesa se završavaju kada se opis svakog detaljnog procesa može izvršiti korištenjem odabrane metode pisanja procesnog algoritma. Specifikacija procesa sadrži broj i naziv procesa, liste imena ulaznih i izlaznih podataka iz rječnika podataka i procesni algoritam koji pretvara ulazne tokove podataka u ulazne. CASE tehnologija koristi takve metode za postavljanje algoritama procesa kao što su:

Tekst opisa;

Prirodno strukturirani jezik;

Tablice odluka;

Decision Trees;

vizuelni jezici;

Programski jezici.

Programski jezici (C, Cobol, itd.) uzrokuju poteškoće u pisanju algoritama za DFD, jer zahtijevaju korištenje rječnika podataka pored tokova podataka i zahtijevaju sinhrono prilagođavanje specifikacija procesa tokom prilagođavanja DFD-a.

Strukturirani prirodni jezik lako razumiju ne samo dizajneri i programeri, već i krajnji korisnici. To je njegova zasluga. Međutim, ne omogućava automatsko generiranje koda zbog nejasnoća.

Tabele i stabla odlučivanja, iako vizuelno odražavaju vezu kombinacije uslova sa potrebnim radnjama, nemaju proceduralne mogućnosti za generisanje koda programa.

Vizuelni jezici omogućavaju automatsko generiranje koda, ali je specifikacije procesa predstavljene uz njihovu pomoć teško prilagoditi.

Sadržaj svakog skladišta podataka predstavljenog u dijagramu toka podataka opisan je rječnikom podataka i ERD modelom podataka. U slučaju rada sistema u realnom vremenu, DFD je dopunjen STD.

Hijerarhijska struktura modela CASE prikazana je na sl. 11.9.

Važan metodološki princip CASE tehnologije za kreiranje informacionog sistema je jasna podjela procesa kreiranja sistema u 4 faze:

Predprojekt (faza analize, izrade prototipa i izgradnje modela zahtjeva za sistem);

Dizajn, koji uključuje logički dizajn sistema (bez programiranja);

Faza programiranja (uključujući dizajn fizičke baze podataka);

Nakon projekta, uključujući puštanje u rad, rad i održavanje sistema.

U fazi predprojektovanja gradi se model zahtjeva za sistem, odnosno detaljan opis onoga što treba da radi, bez preciziranja kako se zahtjevi trebaju implementirati.

U fazi projekta vrši se rafiniranje modela zahtjeva (izrada detaljnog hijerarhijskog modela zasnovanog na DFD i procesnim specifikacijama) i njegovo proširenje na model implementacije na logičkom nivou. Na kraju ove faze slijedi pažljiva kontrola projekta na nivou logičkog modela implementacije.

Sljedeća faza (programiranje) je fizički dizajn sistema. Ova faza omogućava automatsko generisanje koda u skladu sa specifikacijama procesa sistemskog softvera i fizičkog dizajna baze podataka.

Završna faza nakon projekta počinje prijemnim testovima. Nakon toga slijedi puštanje u rad, održavanje i razvoj sistema.

Redoslijed operacija za kreiranje informacionog sistema zasnovanog na CASE tehnologiji prikazan je na sl. 11.10.

Razmotrite faktore efikasnosti CASE tehnologije.

1. Treba napomenuti da CASE-tehnologija stvara mogućnost i omogućava prenošenje težišta u složenosti kreiranja sistema u faze predprojektovanja i projektovanja. Pažljiva razrada ovih faza u interaktivnom režimu sa kompjuterskom podrškom smanjuje broj moguće greške u dizajnu, koje je teško ispraviti u narednim fazama.

2. Grafički oblik prikaza modela, dostupan za razumijevanje korisnicima koji nisu programeri, omogućava implementaciju principa korisničkog dizajna, koji predviđa učešće korisnika u kreiranju sistema. CASE-model omogućava postizanje međusobnog razumijevanja između svih učesnika u kreiranju sistema (kupaca, korisnika, dizajnera, programera).

3. Prisustvo formalizovanog modela sistema u fazi predprojektovanja stvara mogućnost za multivarijantnu analizu sa prototipom i približnom procenom efektivnosti opcija. Analiza prototipa sistema vam omogućava da prilagodite budući sistem prije nego što se fizički implementira. Ovaj pristup ubrzava i smanjuje troškove kreiranja sistema.

4. Fiksiranje sistemskih zahtjeva u formaliziranom obliku oslobađa dizajnere od potrebe za brojnim prilagođavanjima novim zahtjevima korisnika.

5. Odvajanje dizajna sistema od programiranja stvara stabilnost dizajnerskih rješenja za implementaciju na različitim softverskim i hardverskim platformama.

6. Prisustvo formalizovanog modela za implementaciju sistema i odgovarajućih alata za automatizaciju omogućava automatsko generisanje koda sistemskog softvera i stvaranje racionalne strukture baze podataka.

7. U fazi rada sistema, postaje moguće izvršiti izmjene na nivou modela, bez pozivanja na tekstove programa, eventualno od strane stručnjaka iz odjela za automatizaciju kompanije.

8. Model sistema se može koristiti ne samo kao osnova za njegovo kreiranje, već iu svrhu automatizovane obuke osoblja pomoću dijagrama.

9. Na osnovu modela postojećeg sistema može se izvršiti poslovna analiza kao podrška donošenju upravljačkih odluka i reinženjeringu poslovanja pri promeni pravca kompanije.

Razmotrite softverske alate koji pružaju CASE tehnologiju. Ovisno o funkcionalnoj namjeni, dijele se u sljedeće klasifikacijske grupe, koje osiguravaju:

Analiza i dizajn informacionog sistema;

Dizajn baze podataka;

Programiranje;

Održavanje i reinženjering;

Upravljanje procesom projektovanja.

Alati za analizu i projektovanje koriste se za izgradnju CASE-modela kako trenutnog tako i implementiranog sistema upravljanja. Oni podržavaju grafičku konstrukciju i kontrolu hijerarhijskog modela dijagrama toka podataka i opis njegovih komponenti. Ovi alati omogućavaju analitičarima i dizajnerima pristup bazi podataka projektovanog sistema (repozitorijum).

Ovi alati uključuju: domaći CASE paket. Analitičar, Dizajn/IDEF (Meta softver), Programer (ASYST Technologies) itd.

Kako bi se zadovoljili zahtjevi korisnika, kreiraju se prototipovi korisničkih interfejsa, uključujući menije, ekranske obrasce i izvještaje u obliku tabela ili grafikona. Primjer softverskog alata korisničkog sučelja je Developer/2000 (Oracle).

Alati za dizajn baze podataka pružaju logičko modeliranje podataka, automatsku konverziju modela podataka u treći normalni oblik i generiranje šema baze podataka. Primjeri takvih alata su Designer/2000 iz Oraclea, ERWin (Logic Works) itd.

Alati za programiranje podržavaju automatsko generiranje koda iz specifikacija procesa, testiranje i dokumentaciju programa. To uključuje Programmer/2000 (Oracle), DECASE (DEC), APS (Sage Software) itd.

Alati za održavanje i reinženjering vam omogućavaju da izvršite promjene u sistemu na nivou modela pod promjenjivim poslovnim uvjetima (Adpac CASE alati iz Adpac-a, itd.).

Alati za upravljanje procesom dizajna podržavaju planiranje i kontrolu skupa projektantskih radova, kao i interakciju analitičara, dizajnera i programera na osnovu zajedničke baze podataka projekta (na primjer, Project Workbench by Applied Business Technology). Relevantnost kreiranja integrisanog paketa alata za podršku CASE tehnologiji u svim fazama životnog ciklusa informacionog sistema je očigledna.

Federalna agencija za obrazovanje

savezna država obrazovne ustanove Visoko stručno obrazovanje „Čuvaški državni univerzitet. I.N. Uljanova»

Finansijsko-ekonomski institut

Ekonomski fakultet

Sažetak na temu: CASE-tehnologije za projektovanje automatizovanih informacionih sistema

Završio student

Grupe EK 22-06

Evgrafova I.A.

Provjerio: Pavlova S.Yu.

Čeboksari 2007

Uvod…………………………………………………………………………..3

Životni ciklus softvera informacionog sistema…………………………………………………………………..5

RAD-tehnologije za aplikacije prototipa…………...7

· Strukturna metoda razvoja softvera……10

Korištena literatura…………………………………………..17

Uvod

Tokom protekle decenije formirao se novi pravac u softverskom inženjerstvu - CASE (Computer-Aided Software / System Engineering) - u doslovnom prevodu - razvoj softvera informacionih sistema uz podršku (uz pomoć) računara. Trenutno ne postoji opšteprihvaćena definicija SLUČAJA, termin SLUČAJ se koristi u veoma širokom smislu. Prvobitno značenje pojma CASE, ograničeno na pitanja automatizacije razvoja samo softvera, sada je dobilo novo značenje, pokrivajući proces razvoja složenih automatizovanih informacionih sistema u celini. Sada se termin CASE-alati odnosi na softverske alate koji podržavaju procese kreiranja i održavanja IS-a, uključujući analizu i formulaciju zahtjeva, dizajn aplikativnog softvera (aplikacija) i baza podataka, generiranje koda, testiranje, dokumentaciju, osiguranje kvaliteta, upravljanje konfiguracijom i upravljanje projektima, kao i drugi procesi. CASE alati, zajedno sa sistemskim softverom i hardverom, čine kompletno razvojno okruženje AIS-a.

CASE alati omogućavaju ne samo kreiranje "ispravnih" proizvoda, već i obezbjeđivanje "ispravnog" procesa njihovog stvaranja. Glavna svrha CASE-a je da odvoji dizajn softvera od njegovog kodiranja i kasnijih razvojnih faza, kao i da sakrije od programera sve detalje okruženja i rada softvera za razvoj. Prilikom korišćenja CASE tehnologija menjaju se sve faze životnog ciklusa softvera (više o tome će biti reči u nastavku) informacionog sistema, a najveće promene se odnose na faze analize i projektovanja. Većina postojećih CASE alata zasnovana je na strukturnoj (uglavnom) ili objektno orijentisanoj analizi i metodologijama projektovanja, koristeći specifikacije u obliku dijagrama ili tekstova za opisivanje eksternih zahteva, odnosa između modela sistema, dinamike ponašanja sistema i softverske arhitekture. Takve metodologije daju rigorozan i vizuelan opis projektovanog sistema, koji počinje njegovim opštim pregledom, a zatim detaljima, dobijajući hijerarhijsku strukturu sa svim veliki broj nivoa. CASE tehnologije se uspešno koriste za izgradnju skoro svih tipova softverskih sistema, ali zauzimaju stabilnu poziciju u sledećim oblastima:

♦ osiguravanje razvoja poslovnog i komercijalnog softvera, široku upotrebu CASE-tehnologija zbog masovnosti ove aplikativne oblasti, u kojoj se CASE koristi ne samo za razvoj softvera, već i za kreiranje sistemskih modela koji pomažu u rješavanju problema strateško planiranje, finansijsko upravljanje, utvrđivanje politike firmi, obuka kadrova i sl. (ovaj pravac je dobio svoje ime – poslovna analiza);

♦ razvoj sistemskog i upravljačkog softvera. Aktivna upotreba CASE-tehnologija povezana je sa velikom složenošću ovog problema i sa željom da se poveća efikasnost rada.

CASE nije revolucija u softverskom inženjerstvu, već rezultat prirodnog evolucijskog razvoja cjelokupne industrije alata, ranije nazivanih instrumentalnim ili tehnološkim. Od samog početka, CASE tehnologije su evoluirale kako bi prevazišle ograničenja korištenja metodologija konstrukcijskog dizajna iz 60-ih i 70-ih godina. 20ti vijek (složenost razumijevanja, visok intenzitet rada i trošak upotrebe, poteškoće u izmjenama projektnih specifikacija, itd.) zbog njihove automatizacije i integracije pomoćnih alata. Stoga se CASE tehnologije ne mogu smatrati nezavisnim metodologijama, one samo razvijaju strukturalne metodologije i čine njihovu primjenu efikasnijom kroz automatizaciju.

Pored automatizacije strukturnih metodologija i, kao rezultat, mogućnosti korišćenja savremenih metoda sistemskog i softverskog inženjeringa, CASE alati imaju sledeće glavne prednosti:

♦ poboljšati kvalitet kreiranog softvera putem automatske kontrole (prvenstveno projektne kontrole);

♦ omogućiti stvaranje prototipa budućeg sistema u kratkom vremenu, što omogućava procjenu očekivanog rezultata u ranoj fazi;

♦ ubrzati proces dizajna i razvoja;

♦ oslobađanje programera od rutinskog rada, omogućavajući mu da se u potpunosti koncentriše na kreativni dio razvoja;

♦ podrška razvoju i održavanju razvoja;

♦ Podrška tehnologijama ponovne upotrebe razvojnih komponenti.

Pojavi CASE tehnologije i CASE alata prethodila su istraživanja u oblasti metodologije programiranja. Programiranje je dobilo karakteristike sistematskog pristupa razvojem i implementacijom jezika visokog nivoa, metoda strukturiranog i modularnog programiranja, dizajnerskih jezika i njihovih pomoćnih alata, formalnih i neformalnih opisnih jezika. Zahtjevi sustava i specifikacije itd. 70-80-ih godina. strukturalna metodologija je počela da se primenjuje u praksi, pružajući programerima stroge formalizovane metode za opisivanje AIS-a i prihvaćene - tehnička rješenja. Bazira se na vizuelnoj grafičkoj tehnici: dijagrami i dijagrami se koriste za opisivanje različitih tipova AIS modela. Vidljivost i rigoroznost alata za strukturnu analizu omogućila je programerima i budućim korisnicima sistema od samog početka da neformalno učestvuju u njegovom kreiranju, diskutuju i konsoliduju razumevanje glavnih tehničkih rešenja. Međutim, raširena upotreba ove metodologije i poštivanje njenih preporuka u razvoju kontaktnog AIS-a bila je prilično rijetka, jer je to praktično nemoguće neautomatiziranim (ručnim) razvojem. To je doprinijelo nastanku posebne klase softvera i hardvera - CASE alata koji implementiraju CASE tehnologiju za kreiranje i održavanje AIS-a.

Mora se shvatiti da je uspješno korištenje CASE alata nemoguće bez razumijevanja osnovne tehnologije na kojoj su ovi alati zasnovani. CASE softverski alati su sami po sebi alati za automatizaciju procesa projektovanja i održavanja informacionih sistema. Bez razumijevanja metodologije dizajna IS-a, nemoguće je koristiti CASE alate.

1. Životni ciklus softvera informacionog sistema

Jedan od osnovnih koncepata metodologije projektovanja AIS-a je koncept životnog ciklusa njegovog softvera (LC software). Životni ciklus softvera je kontinuirani proces koji počinje od trenutka donošenja odluke o potrebi njegovog stvaranja i završava se u trenutku njegovog potpunog povlačenja iz rada.

Struktura životnog ciklusa softvera zasniva se na tri grupe procesa:

♦ glavni procesi životnog ciklusa softvera (nabavka, nabavka, razvoj, rad, održavanje);

♦ pomoćni procesi koji osiguravaju implementaciju glavnih procesa (dokumentacija, upravljanje konfiguracijom, osiguranje kvaliteta, verifikacija, sertifikacija, procjena, revizija, rješavanje problema);

♦ organizacioni procesi (upravljanje projektom, kreiranje projektne infrastrukture, definisanje, evaluacija i unapređenje samog životnog ciklusa, obuka).

Razvoj uključuje sve radove na izradi softvera i njegovih komponenti u skladu sa navedenim zahtjevima, uključujući izradu projektne i operativne dokumentacije, pripremu materijala potrebnih za testiranje operativnosti i odgovarajućeg kvaliteta softverskih proizvoda, materijala potrebnih za organizaciju kadrova. obuku, itd. Razvoj softvera obično uključuje analizu, dizajn i implementaciju (programiranje).

Operacija uključuje rad na implementaciji softverskih komponenti u rad, uključujući konfiguraciju baze podataka i korisničkih radnih stanica, obezbjeđivanje operativne dokumentacije, izvođenje obuke osoblja i sl. i direktno djelovanje, uključujući lokalizaciju problema i otklanjanje uzroka njihovog nastanka, modifikaciju softvera unutar utvrđena regulativa, priprema predloga za unapređenje, razvoj i modernizaciju sistema.

Upravljanje projektima se odnosi na pitanja planiranja i organizacije rada, kreiranja timova programera i praćenja vremena i kvaliteta obavljenog posla.

Tehnička i organizaciona podrška projekta uključuje izbor metoda i alata za implementaciju projekta, definisanje metoda za opisivanje srednjih razvojnih stanja, razvoj metoda i alata za testiranje softvera, obuku osoblja itd. Osiguranje kvaliteta projekta je povezano sa problemi verifikacije, verifikacije i testiranja softvera. Verifikacija je proces utvrđivanja da li trenutno stanje razvoja postignuto u datoj fazi ispunjava zahtjeve te faze. Validacija vam omogućava da procenite usklađenost razvojnih parametara sa originalnim zahtevima. Verifikacija se preklapa sa testiranjem, koje se bavi identifikovanjem razlika između stvarnih i očekivanih rezultata i procenom da li softverske karakteristike ispunjavaju originalne zahteve. U procesu implementacije projekta važno mjesto zauzimaju pitanja identifikacije, opisa i kontrole konfiguracije pojedinih komponenti i cjelokupnog sistema u cjelini.

Upravljanje konfiguracijom je jedan od pomoćnih procesa koji podržavaju glavne procese životnog ciklusa softvera, prvenstveno procese razvoja i održavanja softvera. Prilikom kreiranja kompleksnih IS projekata koji se sastoje od mnogo komponenti, od kojih svaka može imati varijante ili verzije, nastaje problem uzimanja u obzir njihovih odnosa i funkcija, stvaranja jedinstvene strukture i osiguravanja razvoja cjelokupnog sistema. Upravljanje konfiguracijom vam omogućava da organizujete, sistematski uzimate u obzir i kontrolišete promene softvera u svim fazama životnog ciklusa. Opšti principi i preporuke za računovodstvo konfiguracije, planiranje i upravljanje softverskim konfiguracijama se ogledaju u nacrtu standarda ISO 12207-2.

Svaki proces karakteriziraju određeni zadaci i metode za njihovo rješavanje, početni podaci dobijeni u prethodnoj fazi i rezultati. Rezultati analize su posebno funkcionalni modeli, informacioni modeli i njima odgovarajući dijagrami. Životni ciklus softvera je iterativni po prirodi: rezultati sljedeće faze često uzrokuju promjene u dizajnerskim odlukama razvijenim u ranijim fazama.

Postojeći modeli životnog ciklusa određuju redosled izvođenja faza tokom razvoja, kao i kriterijume za prelazak iz faze u fazu. U skladu s tim, najviše se koriste sljedeća tri modela životnog ciklusa:

♦ kaskadni model (1970-1980) - nudi prelazak u sledeću fazu nakon završetka radova na prethodnoj fazi;

♦ stepenasti model sa srednjom kontrolom (1980-1985) - iterativni model razvoja softvera sa povratnom spregom između faza. Prednost ovog modela je u tome što međufazna prilagođavanja daju manji intenzitet rada u odnosu na vodopad model, međutim, životni vijek svake od faza se produžava kroz cijeli razvojni period;

♦ spiralni model (1986-1990) - naglašava početne faze životnog ciklusa: analiza zahtjeva, dizajn specifikacije, idejni i detaljni projekat. U ovim fazama se provjerava i opravdava izvodljivost tehničkih rješenja izradom prototipova. Svaki zavoj spirale odgovara modelu korak po korak za kreiranje fragmenta ili verzije softverskog proizvoda, na kojem se specificiraju ciljevi i karakteristike projekta, utvrđuje njegova kvaliteta i rad sljedećeg zavoja. spirala je planirana. Tako se detalji projekta produbljuju i dosljedno konkretiziraju, te se kao rezultat bira razumna opcija koja se dovodi u realizaciju.

Stručnjaci primjećuju sljedeće prednosti spiralnog modela:

♦ akumulacija i ponovo koristiti softverski alati, modeli i prototipovi;

♦ fokusiranje na razvoj i modifikaciju softvera u procesu njegovog dizajna;

♦ analiza rizika i troškova u procesu projektovanja.

glavna karakteristika Industrija razvoja softvera se sastoji u koncentraciji složenosti u početnim fazama životnog ciklusa (analiza, dizajn) sa relativno niskom složenošću i radnim intenzitetom u narednim fazama. Štaviše, nerešeni problemi i greške napravljene tokom faza analize i projektovanja dovode do teških, često nerešivih problema u narednim fazama i, na kraju, dovode do neuspeha celog projekta.

2. RAD - tehnologije izrade prototipa aplikacija

Jedan od mogućih pristupa razvoju softvera u okviru modela spiralnog životnog ciklusa je nedavno široko korištena metodologija za brzi razvoj aplikacija RAD (Rapid Application Development). Ovaj termin se obično odnosi na proces razvoja softvera koji sadrži tri elementa:

♦ mali tim programera (od 2 do 10 ljudi);

♦ kratak, ali pažljivo razrađen proizvodni raspored (od 2 do 6 mjeseci);

♦ iterativni ciklus u kojem programeri, kako aplikacija počinje da se oblikuje, traže i implementiraju u proizvod zahtjeve primljene kroz interakciju s kupcem.

Razvojni tim treba da bude grupa profesionalaca sa iskustvom u analizi, dizajnu, generisanju koda i testiranju softvera pomoću CASE alata. Članovi tima također moraju biti u stanju transformirati prijedloge krajnjih korisnika u radne prototipove.

Životni ciklus softvera prema RAD metodologiji sastoji se od četiri faze:

♦ analiza zahtjeva i faze planiranja;

♦ faze projektovanja;

♦ faze izgradnje;

♦ faze implementacije.

U fazi analize i planiranja zahtjeva, korisnici sistema određuju funkcije koje on mora obavljati, izdvajaju one najveće prioritete koje prije svega zahtijevaju razradu i opisuju potrebe za informacijama. Određivanje zahtjeva uglavnom sprovode korisnici pod vodstvom specijalističkih programera. Obim projekta je ograničen, vremenski okvir za svaku od narednih faza je određen. Pored toga, utvrđuje se i sama mogućnost realizacije ovog projekta u okviru utvrđenog finansiranja, na ovim hardverima i sl. Rezultat ove faze treba da bude lista i prioritet funkcija budućeg AIS-a, preliminarni funkcionalni i informacioni modeli IS.

Tokom faze projektovanja, neki korisnici učestvuju u tehničkom dizajnu sistema pod vođstvom specijalizovanih programera. CASE alati se koriste za brzo dobijanje funkcionalnih prototipova aplikacija. Korisnici, u direktnoj interakciji sa njima, pojašnjavaju i dopunjuju zahteve za sistem koji nisu identifikovani u prethodnoj fazi. Detaljnije su razmotreni procesi sistema. Funkcionalni model se analizira i po potrebi koriguje. Svaki proces se detaljno razmatra. Ako je potrebno, za svaki elementarni proces se kreira parcijalni prototip: ekran, dijalog, izveštaj koji eliminiše nejasnoće ili nejasnoće. Utvrđeni su zahtjevi diferencijacije pristupa podacima. U istoj fazi utvrđuje se komplet potrebne dokumentacije.

Nakon detaljnog definisanja sastava procesa, broj funkcionalni elementi razvijenog sistema i donosi se odluka da se AIS podijeli na podsisteme koje može implementirati jedan tim programera u vremenu prihvatljivom za RAD projekte - otprilike 60-90 dana. Koristeći CASE alate, projekat se distribuira između različitih timova (funkcionalni model je podijeljen). Ova faza bi trebala rezultirati:

♦ opšti informacioni model sistema;

♦ funkcionalni modeli sistema u cjelini i podsistema koje implementiraju pojedinačni razvojni timovi;

♦ CASE-definisani interfejsi između autonomno razvijenih podsistema;

♦ konstruisani prototipovi ekrana, izveštaja, dijaloga.

Svi modeli i prototipovi moraju se nabaviti pomoću onih CASE alata koji će se kasnije koristiti prilikom izgradnje sistema. Ovaj zahtjev zbog činjenice da u tradicionalnom pristupu, prilikom prenošenja informacija o projektu iz faze u fazu, može doći do praktično nekontrolisanog izobličenja podataka. Upotreba jednog okruženja za skladištenje informacija o projektu izbjegava ovu opasnost.

Za razliku od tradicionalnog pristupa, koji je koristio specifične alate za izradu prototipa koji nisu namijenjeni za izgradnju stvarnih aplikacija, i odbačeni prototipovi nakon što su završili zadatak eliminacije nejasnoća u dizajnu, u RAD pristupu svaki prototip se razvija u dio budući sistem. Tako se potpunije i korisnije informacije prenose u sljedeću fazu.

Tokom faze izgradnje, brzi razvoj same aplikacije se izvodi direktno. U ovoj fazi programeri iterativno grade pravi sistem na osnovu modela dobijenih u prethodnoj fazi, kao i nefunkcionalnih zahteva. Programski kod je djelomično generiran korištenjem automatskih generatora koji primaju informacije direktno iz spremišta CASE alata. Krajnji korisnici u ovoj fazi ocenjuju dobijene rezultate i vrše prilagođavanja ukoliko tokom procesa razvoja sistem više ne ispunjava prethodno definisane zahteve. Testiranje sistema se vrši direktno u procesu razvoja.

Nakon završetka rada svakog pojedinačnog razvojnog tima, ovaj dio sistema se postepeno integriše sa ostalim, formira se kompletan programski kod i vrši testiranje. zajednički rad ovaj dio aplikacije sa ostatkom, a zatim testiranje sistema u cjelini. Fizički dizajn sistema je u toku:

♦ utvrđuje se potreba za distribucijom podataka;

♦ vrši se analiza upotrebe podataka;

♦ fizički dizajn baze podataka;

♦ utvrđuju se zahtjevi za hardverskim resursima;

♦ identifikovani su načini povećanja produktivnosti;

♦ u toku je izrada projektne dokumentacije. Rezultat faze je gotov sistem koji zadovoljava sve dogovorene zahtjeve.

U fazi implementacije vrši se obuka korisnika, organizacione promjene, a paralelno sa uvođenjem novog sistema radi se i sa postojećim sistemom (do potpune implementacije novog sistema). Pošto je faza izgradnje relativno kratka, planiranje i priprema za implementaciju moraju početi rano, obično u fazi projektovanja sistema.

Gore navedena šema za razvoj AIS-a nije apsolutna. Moguće razne opcije ovisno, na primjer, od početni uslovi gdje se odvija razvoj: da li se razvija potpuno novi sistem; da li je obavljeno informativno istraživanje organizacije i da li postoji model njenog djelovanja; da li u organizaciji postoji neki AIS koji se može koristiti kao početni prototip ili bi trebao biti integriran sa onim koji se razvija itd.

Međutim, treba napomenuti da RAD metodologija, kao i svaka druga, ne može tvrditi da je univerzalna, dobra je prvenstveno za relativno male projekte razvijene za određenog kupca. Ukoliko se razvija tipski sistem, koji nije gotov proizvod, već je kompleks tipskih komponenti, centralno održavanih, prilagođenih softverskim i hardverskim platformama, DBMS-u, telekomunikacijama, organizacionim i ekonomskim karakteristikama objekata implementacije i integrisanih sa postojećim razvojem, u prvi plan dolaze metrike projekta kao što su upravljivost i kvalitet, što može biti u sukobu sa lakoćom i brzinom razvoja. Ovakvi projekti zahtijevaju visok nivo planiranja i strogu dizajnersku disciplinu, striktno pridržavanje unaprijed dizajniranih protokola i interfejsa, što smanjuje brzinu razvoja.

RAD metodologija nije primjenjiva na konstrukciju složenih proračunskih programa, operativnih sistema ili upravljačkih programa svemirski brodovi, odnosno programi koji zahtijevaju pisanje velike količine (stotine hiljada linija) jedinstvenog koda.

Aplikacije koje nemaju izražen dio interfejsa koji jasno definiše logiku rada sistema (npr. aplikacije u realnom vremenu) i aplikacije koje utiču na bezbednost ljudi (npr. kontrola letelice ili nuklearne elektrane) su nije pogodno za razvoj koristeći RAD metodologiju, jer iterativni pristup pretpostavlja da prvih nekoliko verzija najvjerovatnije neće biti potpuno funkcionalne, što u ovaj slučaj isključeno. Osnovni principi RAD metodologije:

♦ razvoj aplikacija po iteracijama;

♦ opciono kompletan završetak posla u svakoj fazi životnog ciklusa;

♦ Obavezno uključivanje korisnika u razvoj AIS-a;

♦ neophodna upotreba CASE alata koji osiguravaju integritet projekta;

♦ korištenje alata za upravljanje konfiguracijom koji olakšavaju uvođenje promjena u projekat i održavanje gotovog sistema;

♦ neophodna upotreba generatora kodova;

♦ korištenje prototipa za bolje razumijevanje i zadovoljavanje potreba krajnjeg korisnika;

♦ testiranje i razvoj projekta, koji se sprovodi istovremeno sa razvojem;

♦ razvoj koji vodi mali, dobro vođen tim profesionalaca;

♦ kompetentno upravljanje razvojem sistema, jasno planiranje i kontrola rada.

3. Strukturna metoda razvoja softvera

Essence strukturalni pristup Razvoj AIS-a leži u njegovoj dekompoziciji (particioniranju) na automatizirane funkcije: sistem je podijeljen na funkcionalne podsisteme, koji su, pak, podijeljeni na podfunkcije, podijeljeni na zadatke, itd. Proces particioniranja se nastavlja do specifičnih procedura. U isto vrijeme, automatizirani sistem zadržava holistički pogled u kojem su sve komponente međusobno povezane. Prilikom razvoja sistema odozdo prema gore, od pojedinačnih zadataka do čitavog sistema, gubi se integritet, javljaju se problemi u informacionom povezivanju pojedinih komponenti.

Sve metodologije strukturalne analize zasnovane su na nizu opšti principi, od kojih neki regulišu organizaciju rada u početnim fazama životnog ciklusa, a neki se koriste u izradi preporuka za organizaciju rada. Kao dvoje osnovni principi koriste se: princip "zavadi pa vladaj" i princip hijerarhijskog uređenja. Prvi je princip rješavanja teških problema raščlanjivanjem na mnogo manjih, nezavisnih problema koje je lakše razumjeti i riješiti. Drugi princip izjavljuje da je raspored ovih dijelova također bitan za razumijevanje. Nivo razumijevanja problema naglo raste kada se njegovi dijelovi predstave u obliku stabla. hijerarhijske strukture, tj. sistem se može razumjeti i izgraditi na nivoima, od kojih svaki dodaje nove detalje.

Izbor dva osnovna principa softverskog inženjeringa ne znači da su ostali principi sekundarni, zanemarivanje bilo kojeg od njih može dovesti do nepredvidivih posljedica (uključujući i neuspjeh cijelog projekta). Pogledajmo neke od glavnih principa.

1. Princip apstrakcije – sastoji se u isticanju aspekata sistema koji su značajni sa nekih pozicija i apstrahovanju sa nebitnih kako bi se problem predstavio u jednostavnom opštem obliku.

2. Princip formalizacije – leži u potrebi za rigoroznim metodološkim pristupom rješavanju problema.

3. Princip "skrivanja" - je skrivanje informacija koje nisu bitne u određenoj fazi: svaki dio "zna" samo informacije koje su mu potrebne.

4. Princip konceptualne zajedništva - je da se prati jedinstvena filozofija u svim fazama životnog ciklusa (strukturalna analiza - konstrukcijsko projektovanje - strukturno programiranje - konstrukcijsko ispitivanje).

5. Princip kompletnosti - je kontrola prisutnosti suvišnih elemenata.

6. Princip konzistentnosti – je valjanost i konzistentnost elemenata.

7. Princip logičke nezavisnosti - je fokusiranje na logički dizajn kako bi se osigurala nezavisnost od fizičkog dizajna.

8. Princip nezavisnosti podataka - je da se modeli podataka moraju analizirati i dizajnirati nezavisno od procesa njihove logičke obrade, kao i njihove fizičke strukture i distribucije.

9. Princip strukturiranja podataka - je da podaci moraju biti strukturirani i hijerarhijski organizovani.

10. Princip pristupa krajnjeg korisnika - je da korisnik mora imati pristup bazi podataka koju može koristiti direktno (bez programiranja).

Usklađenost sa ovim principima je neophodna pri organizaciji rada u početnim fazama životnog ciklusa, bez obzira na vrstu softvera koji se razvija i metodologije koje se koriste. Vođeni svim principima u kompleksu, moguće je u ranijim fazama razvoja shvatiti šta će biti sistem koji se stvara, za otkrivanje grešaka i nedostataka, što će zauzvrat olakšati rad u narednim fazama životnog ciklusa i smanjiti troškove razvoja.

U strukturnoj analizi uglavnom se koriste dvije grupe alata koji ilustruju funkcije koje sistem obavlja i odnose između podataka. Svaka grupa alata odgovara određenim tipovima modela (dijagrama), od kojih su najčešći sljedeći:

♦ SADT (Structured Analysis and Design Technique) - modeli i povezani funkcionalni dijagrami;

♦ DFD (Data Flow Diagrams) - dijagrami toka podataka;

♦ ERD (Entity-Relationship Diagrams) - dijagrami "entitet-odnos";

♦ STD (State Trasition Diagrams) - dijagrami prelaza stanja.

U fazi projektovanja IS-a, modeli se proširuju, usavršavaju i dopunjuju dijagramima koji odražavaju strukturu softvera: softversku arhitekturu, blok dijagrame programa i dijagrame oblika ekrana.

Navedeni modeli zajedno daju potpuni opis AIS-a, bilo da je postojeći ili tek razvijen. Sastav dijagrama u svakom konkretnom slučaju zavisi od zahtevane potpunosti opisa sistema.

Metodologija SADT

SADT metodologiju je razvio Douglas Ross, na osnovu koje je razvijena poznata IDEFO (Icam Definition) metodologija, koja je glavni dio programa Icam (Integracija kompjuterskih i industrijskih tehnologija) koji su pokrenule Sjedinjene Američke Države. SADT metodologija je skup metoda, pravila i procedura dizajniranih za izgradnju funkcionalnog modela objekta u bilo kojoj predmetnoj oblasti. Funkcionalni model SADT prikazuje funkcionalnu strukturu objekta, odnosno radnje koje obavlja i odnose između ovih radnji. Glavni elementi ove metodologije zasnivaju se na sljedećim konceptima:

♦ grafički prikaz blok modeliranje. Grafika blokova i lukova SADT-dijagrama prikazuje funkciju kao blok, a ulazno/izlazni interfejsi su predstavljeni lukovima koji ulaze i izlaze iz bloka. Interakcija blokova međusobno je opisana pomoću lukova interfejsa koji izražavaju "ograničenja", koja zauzvrat određuju kada i kako se funkcije izvode i kontrolišu;

♦ strogost i preciznost. Implementacija SADT pravila zahtijeva dovoljnu rigoroznost i preciznost bez nametanja nepotrebnih ograničenja na radnje analitičara.

SADT pravila uključuju:

♦ ograničavanje broja blokova na svakom nivou dekompozicije (pravilo 3-b blokova);

♦ povezanost dijagrama (broj blokova);

♦ jedinstvenost oznaka i naziva (odsustvo duplikata imena);

♦ sintaktička pravila za grafiku (blokovi i lukovi);

♦ razdvajanje ulaza i kontrola (pravilo za određivanje uloge podataka);

♦ odvajanje organizacije od funkcije, odnosno isključenje uticaja organizacione strukture na funkcionalni model.

SADT metodologija se može koristiti za modeliranje širokog spektra sistema i definiranje zahtjeva i funkcija, a zatim dizajniranje sistema koji zadovoljava te zahtjeve i implementira te funkcije. Za vec postojeći sistemi SADT se može koristiti za analizu funkcija koje sistem obavlja, kao i za ukazivanje na mehanizme kroz koje se one izvršavaju.

Rezultat primjene SADT metodologije je model koji se sastoji od dijagrama, fragmenata teksta i glosara koji imaju veze međusobno. Dijagrami su glavne komponente modela, sve IS funkcije i interfejsi su predstavljeni kao blokovi i lukovi. Tačka povezivanja luka sa blokom određuje tip interfejsa. Kontrolne informacije ulaze u blok odozgo, dok su informacije koje se obrađuju prikazane na lijevoj strani bloka, a rezultati izlaza prikazani su na desnoj strani. Mehanizam (ljudski ili automatizovani sistem) koji izvodi operaciju predstavljen je lukom koji ulazi u blok odozdo (slika 1.6.1).

Jedna od najvažnijih karakteristika SADT metodologije je postepeno uvođenje sve većeg nivoa detalja kako se kreiraju dijagrami koji predstavljaju model.

Konstrukcija SADT modela počinje predstavljanjem čitavog sistema u obliku najjednostavnije komponente – jednog bloka i lukova koji predstavljaju interfejse sa funkcijama izvan sistema. Budući da jedan blok predstavlja cijeli sistem kao cjelinu, ime dato u bloku je generičko. Ovo važi i za lukove interfejsa - oni takođe predstavljaju kompletan skup eksternih interfejsa sistema kao celine.

Zatim je blok koji predstavlja sistem kao jedan modul detaljno prikazan u drugom dijagramu koristeći nekoliko blokova povezanih lukovima interfejsa. Ovi blokovi predstavljaju glavne podfunkcije originalne funkcije. Ova dekompozicija otkriva kompletan skup podfunkcija, od kojih je svaka predstavljena kao blok, čije su granice definisane lukovima interfejsa. Svaka od ovih podfunkcija može se razložiti na sličan način za detaljniji prikaz.

U svim slučajevima, svaka podfunkcija može sadržavati samo one elemente koji su uključeni u originalna funkcija. Osim toga, model ne može izostaviti nijedan element, odnosno, kao što je već napomenuto, takozvani roditeljski blok i njegovi interfejsi daju kontekst. Ništa mu se ne može dodati, niti se iz njega ništa ne može ukloniti.

SADT model je niz dijagrama sa pratećom dokumentacijom koji su raščlanjeni složeni objekat na sastavne dijelove, koji su predstavljeni u obliku blokova. Detalji svakog od glavnih blokova prikazani su kao blokovi u drugim dijagramima. U svakom koraku dekompozicije, opštiji dijagram se naziva roditelj detaljnijeg dijagrama.

Lukovi koji ulaze i izlaze iz okvira u dijagramu najvišeg nivoa su potpuno isti kao i lukovi koji ulaze u dijagram niži nivo i izlazak iz njega, jer blok i dijagram predstavljaju isti dio sistema.

Neki lukovi su pričvršćeni za blokove dijagrama na oba kraja, dok drugi imaju jedan kraj koji je ostao nepovezan. Nepovezani lukovi odgovaraju ulazima, kontrolama i izlazima roditeljskog bloka. Izvor ili odredište ovih graničnih lukova može se naći samo u roditeljskom dijagramu. Labavi krajevi moraju odgovarati lukovima originalni grafikon. Svi granični lukovi moraju se nastaviti na roditeljskom dijagramu da bi bio potpun i dosljedan.

SADT dijagrami ne pokazuju eksplicitno ni sekvencu ni vrijeme. Povratne informacije, iteracije, tekući procesi i funkcije koje se preklapaju (u vremenu) mogu se prikazati pomoću lukova. Povratne informacije mogu biti u obliku komentara, primjedbi, ispravaka itd.

Kao što je navedeno, mehanizmi (lukovi na donjoj strani) pokazuju način na koji se funkcije izvode. Mehanizam može biti čovjek, kompjuter ili bilo koji drugi uređaj koji pomaže u obavljanju određene funkcije.

Svaki blok na dijagramu ima svoj broj. Blok bilo kojeg dijagrama može se dalje opisati dijagramom nižeg nivoa, koji se zauzvrat može dodatno detaljizirati potrebnim brojem dijagrama. Tako se formira hijerarhija dijagrama. Da bi se označila pozicija bilo kojeg dijagrama ili bloka u hijerarhiji, koriste se brojevi dijagrama.

Modeliranje tokova podataka (procesa)

Glavni alat za simulaciju funkcionalni zahtjevi AIS su dijagrami toka podataka (DFD:- Diagrami toka podataka). Uz njihovu pomoć, ovi zahtjevi se raščlanjuju na funkcionalne komponente (procese) i predstavljaju kao mreža povezana tokovima podataka. glavni cilj takvi alati su da pokažu kako svaki proces transformiše svoje inpute u izlaze i da identifikuje odnose između ovih procesa.

U skladu sa metodologijom, model sistema je definisan kao hijerarhija dijagrama toka podataka (DFD, ili DFD) koji opisuju asinhroni proces transformacije informacija od njihovog unosa u sistem do izdavanja korisniku. Dijagrami gornjih nivoa hijerarhije (kontekst dijagrami) definiraju glavne procese ili podsisteme IS-a sa vanjskim ulazima i izlazima. Oni su detaljno prikazani pomoću dijagrama nižeg nivoa. Ova dekompozicija se nastavlja, stvarajući hijerarhiju dijagrama na više nivoa, sve dok se ne postigne takav nivo dekompozicije na kojem procesi postaju elementarni i nemoguće ih je dalje detaljizirati.

Izvori informacija (eksterni entiteti) generišu tokove informacija (tokove podataka) koji prenose informacije do podsistema ili procesa. Oni, zauzvrat, transformišu informacije i generišu nove tokove koji prenose informacije drugim procesima ili podsistemima, akumulatorima podataka ili eksternim entitetima – potrošačima informacija. Dakle, glavne komponente dijagrama toka podataka su:

♦ eksterni subjekti;

♦ sistemi/podsistemi;

♦ procesi;

♦ uređaji za skladištenje podataka;

♦ tokovi podataka.

Eksterni entitet je materijalni objekt ili pojedinac A koji predstavlja izvor ili odredište informacija, kao što su kupci, osoblje, dobavljači, kupci, zalihe. Definicija nekog objekta ili sistema kao eksternog entiteta ukazuje da se nalazi izvan granica analiziranog AIS-a.

Proces je transformacija ulaznih tokova podataka u izlazne u skladu sa određenim algoritmom. Fizički, proces se može implementirati na različite načine: to može biti podjela organizacije (odjela) koja obrađuje ulazne dokumente i izdaje izvještaje, program, hardverski implementiran logički uređaj, itd. U različitim notacijama, proces se može prikazano na dijagramima na različite načine. Za identifikaciju se koristi broj procesa. U polje za naziv upisuje se naziv procesa kao rečenica sa aktivnim nedvosmislenim glagolom u neodređenom obliku (izračunaj, izračunaj, provjeri, odredi, stvori, primi), nakon čega slijede imenice u akuzativu, na primjer:

♦ "Unesite podatke o klijentima";

♦ “Dati informacije o tekućim troškovima”;

♦ "Provjeriti kreditnu sposobnost klijenta".

Upotreba glagola kao što su “obraditi”, “modernizirati” ili “urediti” obično znači da nema dovoljno dubokog razumijevanja ovog procesa i zahtijeva dalju analizu.

IN U poslednje vreme također je uobičajeno koristiti polje fizičke implementacije, informacija u kojoj pokazuje koji odjel organizacije, program ili hardverski uređaj obavlja ovaj proces.

Skladištenje (data drive) je apstraktni uređaj za pohranjivanje informacija koji se u bilo kojem trenutku može staviti u disk i preuzeti nakon nekog vremena, a načini postavljanja i preuzimanja mogu biti bilo koji.

Uređaj za skladištenje podataka može se fizički implementirati u obliku mikrofiša, ladice u ormaru za datoteke, stola u RAM-u, datoteke na magnetni mediji itd. Pogon podataka je identificiran slovom "D" i proizvoljnim brojem. Naziv pogona se bira sa stanovišta najvećeg informativnog sadržaja za dizajnera.

Pogon podataka je općenito prototip buduće baze podataka, a opis podataka pohranjenih u njemu trebao bi biti povezan s informacionim modelom. Tok podataka definira informacije koje se prenose kroz neku vezu od izvora do primaoca. Stvarni tok podataka može biti informacija koja se prenosi kablom između dva uređaja, šalje poštom, magnetnim trakama ili disketama, prenosi sa jednog računara na drugi, itd.

Tok podataka na dijagramu je predstavljen linijom koja se završava strelicom koja pokazuje smjer. Svaki tok podataka ima ime koje odražava njegov sadržaj.

Prvi korak u izgradnji DFD hijerarhije je izgradnja kontekstnih dijagrama. Tipično, kada se projektuje relativno jednostavan AIS, gradi se jedan kontekst dijagram sa topologijom zvijezde, u čijem središtu je takozvani glavni proces, povezan sa prijemnicima i izvorima informacija preko kojih korisnici i drugi komuniciraju sa sistemom. eksterni sistemi. Za složeni AIS, izgrađena je hijerarhija kontekstnih dijagrama. Istovremeno, dijagram konteksta najvišeg nivoa ne sadrži jedan glavni proces, već skup podsistema povezanih tokovima podataka. Kontekstni dijagrami sljedećeg nivoa detaljno opisuju kontekst i strukturu podsistema.

Hijerarhija kontekstnih dijagrama definira interakciju glavnog funkcionalni podsistemi dizajnirani AIS kako među sobom tako i sa eksternim ulaznim i izlaznim tokovima podataka i eksternim objektima (izvorima i prijemnicima informacija) sa kojima AIS komunicira.

Razvoj kontekstnih dijagrama rješava problem striktnog definiranja funkcionalne strukture AIS-a u najranijoj fazi njegovog projektovanja, što je posebno važno za složene multifunkcionalne sisteme u čijem razvoju različite organizacije i razvojni timovi.

Nakon konstruisanja dijagrama konteksta, rezultirajući model treba provjeriti na potpunost početnih podataka o objektima sistema i izolovanost objekata (nedostatak informacionih veza sa drugim objektima). Za svaki podsistem prisutan na dijagramima konteksta, on je detaljan pomoću DFD-a. Svaki proces na DFD-u, zauzvrat, može biti detaljan pomoću DFD-a ili mini-specifikacije. Prilikom detaljiranja potrebno je poštovati sljedeća pravila:

♦ pravilo balansiranja - znači da prilikom detaljiranja podsistema ili procesa detaljni dijagram kao eksterni izvori/prijemnici podataka mogu imati samo one komponente (podsisteme, procese, eksterne entitete, akumulatore podataka) sa kojima detaljni podsistem ili proces na roditeljskom dijagramu ima informativni linkovi ;

♦ pravilo numeracije - znači da prilikom detaljiranja procesa treba podržati njihovo hijerarhijsko numerisanje. Na primjer, procesima s detaljima procesa broj 12 dodijeljeni su brojevi 12.1, 12.2, 12.3, itd.

Mini-specifikacija (opis logike procesa) treba da formuliše svoje glavne funkcije na takav način da ih u budućnosti stručnjak koji implementira projekat može izvršiti ili razviti odgovarajući program.

Mini-specifikacija je konačni vrh DFD hijerarhije. Odluku o dovršavanju detalja procesa i korištenju mini-specifikacije donosi analitičar na osnovu sljedećih kriterija:

♦ proces ima relativno mali broj ulaznih i izlaznih tokova podataka (2-3 toka);

♦ mogućnost opisivanja transformacije podataka procesom u obliku sekvencijalni algoritam;

♦ izvršenje procesom jedine logičke funkcije pretvaranja ulaznih informacija u izlazne informacije;

♦ mogućnost opisivanja logike procesa pomoću mini-specifikacije malog volumena (ne više od 20-30 redova).

Prilikom konstruisanja DFD hijerarhije treba pristupiti detaljima procesa tek nakon određivanja sadržaja svih tokova i skladišta podataka, što je opisano pomoću struktura podataka. Strukture podataka su konstruisane od elemenata podataka i mogu sadržati alternative, uslove i iteracije. Uslovna pojava znači da ova komponenta možda nije prisutna u strukturi. Alternativa znači da jedan od navedenih elemenata može biti uključen u strukturu. Iteracija znači unos bilo kojeg broja elemenata u specificiranom rasponu. Za svaki element podataka može se specificirati njegov tip (kontinuirani ili diskretni podaci). Za kontinuirane podatke, mjerna jedinica (kg, cm, itd.), raspon vrijednosti, preciznost predstavljanja i oblik fizičkog kodiranja mogu biti specificirani. Za diskretne podatke može se specificirati tabela dozvoljene vrijednosti.

Nakon izgradnje kompletnog modela sistema, on mora biti verifikovan. U potpunom modelu, svi njegovi objekti (podsistemi, procesi, tokovi podataka) moraju biti detaljno opisani i detaljno razrađeni. Identifikovani nedetaljni objekti treba da budu detaljno opisani vraćanjem na prethodne razvojne korake. U konzistentnom modelu, svi tokovi podataka i skladišta podataka moraju poštovati pravilo očuvanja informacija: svi podaci koji dolaze negdje moraju biti pročitani, a svi pročitani podaci moraju biti zapisani.

Modeliranje podataka

Svrha modeliranja podataka je da se AIS developeru pruži konceptualna šema baze podataka u obliku jednog ili više modela. lokalni modeli, koji se relativno lako može mapirati u bilo koji sistem baze podataka.

Najčešći alat za modeliranje podataka su dijagrami entitet-odnos (ERD). Uz njihovu pomoć određuju se objekti (entiteti) važni za predmetno područje, njihova svojstva (atributi) i međusobni odnosi (linkovi). ERD se direktno koriste za dizajniranje relacionih baza podataka (videti odeljak 2.2).

ERD notaciju je prvi uveo P. Chen, a dalje je razvio Barker.

Metodologija IDEF 1

Metoda IDEF1, koju je razvio T. Ramey, takođe se zasniva na pristupu P. Chena i omogućava vam da izgradite model podataka koji je ekvivalentan relacionom modelu u trećem normalnom obliku. Trenutno, na osnovu poboljšanja IDEF1 metodologije, njegova nova verzija- IDEF1X metodologija. IDEF1X je dizajniran s lakoćom učenja i automatizacijom na umu. IDEF IX dijagrame koriste brojni uobičajeni CASE alati (npr. ERWin, Design/IDEF).

Reference

Fedotova D.E. SLUČAJ - tehnologije: udžbenik - M: Hotline - Telekom, 2007

Trofimov V.E., Lobačeva I.N. Informacioni sistemi u privredi - M: Unity-Dana, 2008

· Baldin N.V., Utkin V.B. Informacioni sistemi i tehnologije u privredi - M: Jedinstvo, 2007

Titorenko T.A. Automatske informacione tehnologije u privredi - M: Jedinstvo, 2006

Baranovskaya T.P., Loiko V.I., Semenov M.I., Trubilin I.T. Automatizovane informacione tehnologije u privredi - M: Finansije i statistika, 2006

1.3.1. Opšti zahtjevi za metodologiju i tehnologiju

Metodologije, tehnologije i alati za projektovanje (CASE-alati) čine osnovu svakog IS projekta. Metodologija se implementira kroz specifične tehnologije i njihove prateće standarde, metode i alate koji osiguravaju implementaciju procesa životnog ciklusa.

Tehnologija dizajna definira se kao kombinacija tri komponente:

• postupak korak po korak koji određuje redoslijed operacija tehnološkog projektovanja (slika 1.4);
• kriterijume i pravila koja se koriste za vrednovanje rezultata tehnoloških operacija;
• zapisi (grafički i tekstualni alati) koji se koristi za opisivanje sistema koji se projektuje.

Rice. 1.4. Prikaz tehnološke operacije projektovanja

Tehnološka uputstva, koja čine glavni sadržaj tehnologije, treba da se sastoje od opisa redosleda tehnoloških operacija, uslova u zavisnosti od toga koja se jedna ili druga operacija izvodi, i opisa samih operacija.

Tehnologija za projektovanje, razvoj i održavanje IS-a mora ispunjavati sledeće opšte zahteve:

• tehnologija mora podržavati puni životni ciklus softvera;
• tehnologija treba da osigura garantovano postizanje ciljeva razvoja IS-a sa zadatim kvalitetom iu određenom vremenu;
• tehnologija treba da obezbedi mogućnost implementacije velikih projekata u obliku podsistema (tj. mogućnost dekomponovanja projekta na sastavne delove koje su razvile grupe izvođača ograničenog broja uz naknadnu integraciju sastavnih delova). Iskustvo razvoja velikih IS-a pokazuje da je za povećanje efikasnosti rada potrebno projekat podijeliti na zasebne podsisteme koji su slabo povezani u pogledu podataka i funkcija. Implementaciju podsistema treba da obavljaju odvojene grupe stručnjaka. Istovremeno, potrebno je osigurati koordinaciju cjelokupnog projekta i isključiti dupliranje rezultata rada svake projektne grupe, koje može nastati zbog prisustva zajedničkih podataka i funkcija;
• tehnologija treba da pruži mogućnost izvođenja radova na projektovanju pojedinačnih podsistema u malim grupama (3-7 ljudi). To je zbog principa upravljanja timom i povećanja produktivnosti minimiziranjem broja vanjskih veza;
• tehnologija treba da obezbedi minimalno vreme za dobijanje funkcionalnog IS-a. Ovdje se ne radi o vremenu pripravnosti cjelokupnog IS-a, već o vremenu implementacije pojedinih podsistema. Implementacija IP općenito u kratkom vremenu može zahtijevati uključivanje veliki broj programera, dok efekat može biti manji nego kada se pojedinačni podsistemi implementiraju za kraće vrijeme od strane manjeg broja programera. Praksa pokazuje da čak iu prisustvu potpuno završenog projekta, implementacija teče dosljedno za pojedine podsisteme;
• tehnologija treba da obezbedi mogućnost upravljanja konfiguracijom projekta, održavanje verzija projekta i njegovih komponenti, mogućnost automatskog izdavanja projektne dokumentacije i sinhronizacije njenih verzija sa verzijama projekta;
• tehnologija treba da obezbedi nezavisnost izvedenih projektantskih rešenja od sredstava implementacije IS (sistemi za upravljanje bazama podataka (DBMS), operativni sistemi, programski jezici i sistemi);
• tehnologija treba da bude podržana skupom koordinisanih CASE-alata koji obezbeđuju automatizaciju procesa koji se izvode u svim fazama životnog ciklusa. Opšti pristup evaluacija i odabir CASE-alata opisana je u Odjeljku 4, primjeri kompleksa CASE-alata - u Odjeljku 5.7.

Prava primjena bilo koje tehnologije za projektovanje, razvoj i održavanje IS u određenoj organizaciji i konkretnom projektu nemoguća je bez izrade niza standarda (pravila, sporazuma) koje moraju poštovati svi učesnici projekta. Ovi standardi uključuju sljedeće:

• standard dizajna;
• standard projektne dokumentacije;
• standard korisničkog interfejsa.

Standard dizajna treba da sadrži:

• komplet potrebni modeli(dijagrami) u svakoj fazi projektovanja i njihov nivo detalja;
• pravila za fiksiranje dizajnerskih odluka na dijagramima, uključujući: pravila imenovanja za objekte (uključujući terminološke konvencije), skup atributa za sve objekte i pravila za njihovo popunjavanje u svakoj fazi, pravila dizajna dijagrama, uključujući zahtjeve za oblik i veličinu objekata , itd. .;
• zahtjeve za konfiguraciju razvojnih radnih stanica, uključujući postavke operativni sistem, postavke alata CASE, Opšte postavke projekat, itd.;
• mehanizam za osiguranje zajedničkog rada na projektu, uključujući: pravila za integraciju projektnih podsistema, pravila za održavanje projekta u istom stanju za sve programere (propisi za razmjenu informacija o projektu, mehanizam za fiksiranje zajedničkih objekata, itd.), pravila za provjeru konzistentnosti projektnih odluka, itd. d.

Standardom projektne dokumentacije treba utvrditi:

• kompletnost, sastav i struktura dokumentacije u svakoj fazi projektovanja;
• zahtjevi za njegov dizajn (uključujući zahtjeve za sadržaj odjeljaka, pododjeljaka, pasusa, tabela, itd.),
• pravila za pripremu, pregled, odobravanje i odobravanje dokumentacije, sa naznakom rokova za svaku fazu;
• zahtjevi za postavljanje izdavačkog sistema koji se koristi kao ugrađeni alat za pripremu dokumentacije;
• zahtjevi za postavljanje CASE alata kako bi se osigurala priprema dokumentacije u skladu sa utvrđenim zahtjevima.

Standard korisničkog interfejsa treba da kaže:

• pravila dizajna ekrana (fontovi i paleta boja), sastav i raspored prozora i kontrola;
• pravila za korištenje tastature i miša;
• pravila za formatiranje tekstova pomoći;
• lista standardnih poruka;
• pravila obrade korisničkih reakcija.

CASE-alati za projektovanje informacionih sistema

U savremenim uslovima, složenost kreiranja informacionih sistema je veoma visoka. Stoga je u dizajnu IC-a CASE tehnologija sada postala široko korištena.

CASE tehnologija je softverski paket koji automatizuje kompletan tehnološki proces analize, projektovanja, razvoja i održavanja složenih softverskih alata.

Moderni CASE alati pokrivaju širok spektar podrške za brojne tehnologije dizajna IC: od jednostavna sredstva analizu i dokumentaciju do alata za automatizaciju punog opsega koji pokrivaju cijeli životni ciklus softvera.

Najzahtjevnije faze razvoja IS-a su faze analize i projektovanja, tokom kojih CASE-alati pružaju kvalitetna tehnička rješenja i izradu projektne dokumentacije. Istovremeno, značajnu ulogu imaju alati za modeliranje grafičkih domena, koji programerima omogućavaju da vizuelno prouče postojeći IS, da ga rekonstruišu u skladu sa ciljevima i postojećim ograničenjima.

Integrirani CASE alati imaju sljedeće karakteristične karakteristike :

· obezbjeđivanje upravljanja procesom razvoja IS;

Upotreba posebno organizovanog spremišta metapodataka projekta (repozitorija).

Integrirani CASE alati sadrže sljedeće komponente:

· alati za grafičku analizu i dizajn koji se koriste za opisivanje i dokumentovanje IS;

Alati za razvoj aplikacija, uključujući programske jezike i generatore koda;

repozitorijum koji obezbeđuje skladištenje verzija projekta koji se razvija i njegovih pojedinačnih komponenti, sinhronizaciju informacija dobijenih od različitih programera tokom grupnog razvoja, kontrolu metapodataka za potpunost i doslednost;

· alati upravljanja za razvoj IS;

sredstva dokumentacije;

Alati za testiranje;

Alati za reinženjering koji omogućavaju analizu programskih kodova i shema baza podataka i formiranje na njihovoj osnovi razni modeli i specifikacije dizajna.

Svi moderni CASE-alati podijeljeni su u dvije grupe. prva grupa organizovati alate ugrađene u sistem implementacije, u kojima su sve odluke o dizajnu i implementaciji vezane za odabrani sistem upravljanja bazom podataka. druga grupa organizovati sredstva nezavisna od implementacionog sistema, u kojima su sve dizajnerske odluke usmerene na objedinjavanje početne fazeživotni ciklus i način njihove dokumentacije. Ovi alati pružaju veću fleksibilnost u izboru načina implementacije.

Main dostojanstvo CASE-tehnologije - podrška timskom radu na projektu zbog mogućnosti rada lokalna mreža, izvoz i uvoz pojedinačnih fragmenata projekta između programera, organizirano upravljanje projektima.

As faze kreiranjem softverskih proizvoda za informacione sisteme, mogu se razlikovati:

1. Određuje se radno okruženje. U ovoj fazi se utvrđuje skup procesa životnog ciklusa IS-a, određuje se obim IS-a, određuje se veličina podržanih aplikacija, tj. ograničenja su postavljena na vrijednosti kao što su broj linija programskog koda, veličina baze podataka, broj elemenata podataka, broj kontrolnih objekata itd.

2. Grafike se grade i grafička analiza. U ovoj fazi se grade dijagrami koji uspostavljaju vezu sa izvorima informacija i potrošačima, određuju procese transformacije podataka i lokacije njihovog skladištenja.

3. Određuju se specifikacije i zahtjevi za sistem (tip interfejsa, tip podataka, struktura sistema, kvalitet, performanse, tehnička sredstva, ukupni troškovi itd.).

4. Izvodi se modeliranje podataka, tj. unose se informacije koje opisuju elemente podataka sistema i njihove odnose.

5. Izvodi se modeliranje procesa, tj. uvode se informacije koje opisuju procese sistema i njihove odnose.