Što su CASE-alati CASE-alati (od engleskog Computer-Aided Software
Inženjering) su alati
Automatizacija IC dizajna.
CASE-TOOLS su tehnike softverskog inženjeringa za
projektiranje softver, koji
dopustiti pružiti visoka kvaliteta programi,
bez grešaka i jednostavan za održavanje
softverskih proizvoda.
CASE se također shvaća kao skup sredstava
projektiranje informacijskih sustava s
pomoću CASE alata.

Sredstva za slučaj

Slučaj znači uključiti bilo koji softver koji
automatizira različite fazeŽivotni ciklus
softver i ima sljedeće karakteristike:
1. Postoji moćan grafički alat za
opis IP-a koji omogućuje upotrebljivost
korisnik,
2. Postoji integracija pojedinačne komponente
Slučaj - znači,
3. Koristi se centralizirana pohrana
Repozitorijum projektnih podataka.

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

-
analiza i formulacija zahtjeva IP;
dizajn baze podataka i aplikacija;
generacija programski kod;
testiranje;
osiguranje kvalitete softvera;
Upravljanje konfiguracijom IC-a;
upravljanje projektima itd.

Rezultat korištenja CASE-alata:

optimizacija strukture IS-a;
smanjenje troškova razvoja;
povećanje učinkovitosti IP-a;
smanjenje vjerojatnosti pogrešaka kada
projektiranje IP-a.

Tipična arhitektura alata kućišta

Repozitorijum

Jezgra svakog sustava za dizajn softvera je spremište.
Repozitorij je specijalizirana baza podataka,
koji se koristi za prikaz stanja sustava u bilo kojem trenutku
vrijeme i sadrži informacije o svim objektima IP projekta:
Imena dizajnera i njihova prava pristupa,
Organizirane strukture,
Komponente grafikona i grafikona općenito,
strukture podataka,
Odnosi između grafikona,
Programski moduli, procedure i knjižnice modula.

Klasifikacija modernih alata za kućište:

1. Klasifikacija fondova predmeta prema
podržane metodologije:
-
funkcionalno ili strukturno orijentirano;
-
objektno orijentirano;
-
kompleksno orijentiran.

2. Klasifikacija fondova Modern Case po vrstama:

Odražava funkcionalnu orijentaciju sredstava za
procesa životni ciklus razvoj softvera
pružanje:
alati za analizu – dizajnirani za izgradnju i
analiza modela domene;
Alati za dizajn baze podataka;
alati za razvoj aplikacija;
Alati za reinženjering procesa;
alati za planiranje i upravljanje projektima;
alati za testiranje;
dokumentacijski alati.

Primjeri alata za kućište raznih vrsta:

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 u kategorije:

Definira funkcije koje izvršavaju alati i uključuje:
odvojeno lokalna sredstva odlučujući mali autonomni
zadataka, skup djelomično integriranih alata koji pokrivaju
većinu faza životnog ciklusa i potpuno integrirani
znači pokrivanje cijelog životnog ciklusa informacija
sustava i povezani zajedničkim repozitorijom.
Tipični CASE alati su:
alati za upravljanje konfiguracijom;
alati za modeliranje podataka;
alati za analizu i dizajn;
alati za transformaciju modela;
alati za uređivanje koda;
generatori kodova;
alati za izradu UML dijagrama.

Ostale vrste klasifikacije Case-fondova:

4.
Klasifikacija fondova predmeta prema potpori
grafičke oznake;
5.
Klasifikacija fondova predmeta po stupnju
integracija pojedinačnih instrumenata;
6.
Klasifikacija Case-alata prema vrsti i arhitekturi
korištena računalna tehnologija;
7.
Klasifikacija fondova predmeta prema vrsti kolektiva
razvoj;
8.
Klasifikacija fondova predmeta prema vrsti korištenih
radno okruženje.

Prilikom odabira sredstava Case treba uzeti u obzir sljedeće aspekte:

Prisutnost baze podataka, arhiva ili rječnika;
Dostupnost sučelja s drugim Case sustavima;
Mogućnosti izvoza i uvoza informacija;
Otvorena arhitektura;
Dostupnost potrebnih metodologija;
Dostupnost grafičkih alata za podršku projektu;
Mogućnost automatskog generiranja programskog koda;
Sposobnost planiranja i upravljanja projektom.

Alat za slučaj Univerzalni jezik za modeliranje UML

UML je stvoren sa sljedećim ciljevima:
pružiti programerima jedinstven vizualni jezik
modeliranje;
osigurati mehanizme za širenje i specijalizaciju jezika;
osigurati jezičnu neovisnost od programskih jezika, i
razvojni procesi.

Odnos UML dijagrama

Varijanta dijagrama
korištenje
Dijagram
sekvence
Dijagram
razreda
Dijagram
suradnja
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 sustava,
pokriva cijeli životni ciklus softvera
od analize poslovnih procesa do generiranja koda
zadanog programskog jezika.
Takav arsenal omogućuje ne samo dizajniranje novog
informacijskog sustava, ali i modificirati stari,
provođenjem procesa obrnutog inženjeringa.

Ključne značajke paketa Rational Rose:

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

Verzije proizvoda Rational Rose:

Rational Rose Modeler vam omogućuje analizu poslovnih procesa i
dizajnirati sustav. Ali ne podržava generiranje koda.
Rational Rose Professional verzija Ovisno o odabranom programskom jeziku
omogućuje naprijed i natrag inženjering. Može se naručiti samo u
specifična konfiguracija (npr. Rose Professional C ++ ili Rose Professional C ++
DataModeler). Ne generira 100% izvršni kod. Kao rezultat toga, programer prima
okvirni kod informacijskog sustava na određenom (uređenom) jeziku
programiranje, koje kasnije još treba doraditi.
Rational Rose RealTime je posebno dizajniran za pružanje 100% izvršne datoteke
kod u stvarnom vremenu, omogućuje kretanje naprijed i nazad
dizajn na C ili C ++ jezicima. Na izlazu se model automatski kompilira
i sastavlja se u izvršnu datoteku.
Rational Rose Enterprise verzija ova verzija proizvoda pokriva cijeli niz zadataka za
dizajn, analiza i generiranje koda. Podržane su sve funkcije drugih
izdanja, osim mogućnosti 100% generiranja koda.
Rational Rose DataModeler verzija proizvoda za dizajn baze podataka.
Funkcionalnost DataModelera uključena je u Rose Enterprise ili Professional.
U MS paket Vizualni studio 6.0 ugrađen Visual Modeler je skraćena verzija Rational Rose 98.

Više informacija o paketu Rational Rose:

Besplatna verzija Rational Rose ne radi
postoji;
za obrazovne ustanove sav softver
IBM softver dostupan je besplatno;
besplatno korištenje u obrazovne svrhe Može biti
u sklopu IBM akademske inicijative.

Hijerarhijski CASE-modeli puno bolje odgovaraju velikoj dimenziji problema. CASE (Computer-Aided Software / System Engineering) označava računalno potpomognut softver ili dizajn sustava.

CASE-tehnologija je aktualan i intenzivno razvijajući smjer razvoja CAD-a u području softverskih proizvoda i sustava za obradu informacija. Gotovo nijedan veći strani softverski proizvod trenutno se ne stvara bez upotrebe CASE-alata.

Među domaćim sustavima stvorenim pomoću CASE-alata treba istaknuti sustav BOSS-CORPORATION IT Co. U svim fazama stvaranja ovog sustava korišteni su razvojni alati koji se odnose na obitelj Oracle 2000 (Designer / 2000, Developer / 200, Programmer / 2000).

Područje primjene CASE-tehnologija odnosi se na stvaranje, prije svega, ekonomskih informacijskih sustava, što se objašnjava masovnošću ovih sustava.

Treba napomenuti da se CASE tehnologije koriste ne samo za stvaranje automatiziranih sustava upravljanja, već i za razvoj modela sustava koji pomažu u donošenju odluka u području strateškog planiranja, financijskog upravljanja tvrtkom, obuke osoblja itd. Ovo područje primjene CASE tehnologija dobilo je svoje ime - poslovna analiza.

CASE-tehnologije se također koriste tamo gdje je problematika predmetnog područja vrlo složena, primjerice u razvoju sistemskog softvera.

Razmotrimo metodološke temelje CASE tehnologija.

Temelj CASE metodologije je modeliranje. CASE-tehnologija je model metoda automatizacije projektiranja sustava.

CASE tehnologija temelji se na paradigmi: metodologija – metoda – notacija – sredstvo

Metodologija definira opće pristupe procjeni i odabiru opcije sustava, slijed faza i faza projektiranja te pristupe odabiru metoda.

Metoda specificira redoslijed projektiranja pojedinih komponenti sustava (na primjer, poznate su metode projektiranja tokova podataka u sustavu, postavljanja specifikacija (opisa) procesa, predstavljanja struktura podataka u skladištu i sl.).

Bilješke su grafičke oznake i pravila koja se koriste za opisivanje strukture sustava, faza obrade informacija, strukture podataka itd. Bilješke uključuju grafikone, dijagrame, tablice, dijagrame toka, formalne i prirodne jezike.

Konačno, alati su alati, alati za automatizaciju dizajna u obliku softverskih proizvoda za pružanje interaktivnog načina dizajna (izrada i uređivanje grafičkog projekta informacijskog sustava) i generiranje koda programa (automatsko generiranje programskih kodova sustava).

Metodologija projektiranja utemeljena na računalnoj podršci, očito, zahtijeva izgradnju formaliziranog opisa informacijskog sustava u obliku informacijskog modela. Konstrukcija CASE-modela sustava osigurava dekompoziciju sustava i hijerarhijski poredak dekomponiranih podsustava.

Model sustava trebao bi odražavati:

Funkcionalni dio sustava;

Odnosi između podataka;

Prijelazi stanja sustava pri radu u stvarnom vremenu. Za modeliranje informacijskog sustava u tri navedena aspekta koriste se tri vrste grafičkih alata s određenim oznakama.

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

2. Dijagrami "entitet-odnos" - ERD (Entity Relationship Diagrams), koji prikazuju odnos između podataka.

3. Dijagrami prolaska stanja - STD (State Transitign Diagrami) koji odražavaju ponašanje sustava ovisno o vremenu (u stvarnom vremenu).

DFD igra vodeću ulogu u modeliranju.

DFD je osmišljen tako da odražava odnos između izvora i primatelja podataka (tzv. vanjski entiteti u odnosu na informacijski sustav), tokova podataka, procesa obrade (računarskih procesa koji odgovaraju funkcijama sustava), pohrane podataka (pohrane).

Grafički prikaz dijagrama toka podataka na zaslonu omogućuje vizualizaciju simulacije i praktičnost ispravljanja glavnih komponenti modela na mreži.

Budući da grafički prikaz nije dovoljan za točno definiranje DFD komponenti, koriste se tekstualni opisi i druga sredstva konkretiziranja procesa obrade i struktura podataka.

Dakle, tokovi podataka su konkretizirani u smislu njihove strukture u rječnicima podataka. Svaki proces (funkcija sustava) može se detaljizirati pomoću DFD-a niže razine, gdje se dijeli na nekoliko procesa uz istovremenu granularnost tokova podataka.

Detalji procesa 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, popise naziva ulaznih i izlaznih podataka iz rječnika podataka i procesni algoritam koji pretvara ulazne tokove podataka u ulazne. CASE tehnologija koristi metode postavljanja procesnih algoritama kao što su:

Opis teksta;

Prirodno strukturirani jezik;

Tablice odluka;

Stabla odluka;

Vizualni jezici;

Programski jezici.

Programski jezici (C, Cobol, itd.) uzrokuju poteškoće u pisanju algoritama u odnosu na DFD, jer zahtijevaju korištenje rječnika podataka, osim tokova podataka, i zahtijevaju sinkronu korekciju specifikacija procesa prilikom ispravljanja DFD-a.

Strukturirani prirodni jezik lako razumiju ne samo dizajneri i programeri, već i krajnji korisnici. Ovo je njegovo dostojanstvo. Međutim, ne omogućuje automatsko generiranje koda zbog prisutnosti nejasnoća.

Tablice i stabla odluka, koji jasno odražavaju odnos kombinacije uvjeta s potrebnim radnjama, nemaju proceduralne mogućnosti za generiranje koda programa.

Vizualni jezici omogućuju automatsko generiranje koda, ali je specifikacije procesa predstavljene uz njihovu pomoć teško ispraviti.

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

Hijerarhijska struktura CASE modela prikazana je na Sl. 11.9.

Važan metodološki princip CASE tehnologije za stvaranje informacijskog sustava je jasna podjela procesa stvaranja sustava u 4 faze:

Preddizajn (faza analize, izrade prototipa i izrade modela zahtjeva sustava);

Projektiranje, uz pretpostavku logičkog dizajna sustava (bez programiranja);

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

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

U fazi predprojektiranja izrađuje se model zahtjeva za sustav, odnosno detaljan opis onoga što bi trebao raditi, bez specificiranja načina implementacije zahtjeva.

U fazi projektiranja dorađuje se model zahtjeva (razvoj detaljnog hijerarhijskog modela na temelju DFD i procesnih specifikacija) i njegovo proširenje na model implementacije na logičkoj razini. Na kraju ove faze, projekt se pomno prati na razini logičkog modela implementacije.

Sljedeća faza (programiranje) je fizički dizajn sustava. Ova faza omogućuje automatsko generiranje koda prema specifikacijama procesa softverskog sustava i fizičkog dizajna baze podataka.

Završna faza post-dizajna počinje testovima prihvaćanja. Nakon toga slijedi puštanje u rad, održavanje i razvoj sustava.

Slijed operacija za izradu informacijskog sustava baziranog na CASE tehnologiji prikazan je na Sl. 11.10.

Razmotrimo čimbenike učinkovitosti CASE tehnologije.

1. Treba napomenuti da CASE-tehnologija stvara priliku i omogućuje prijenos težišta u složenosti stvaranja sustava u fazama predprojektiranja i projektiranja. Pažljiva razrada ovih faza interaktivno uz računalnu podršku smanjuje broj moguće pogreške u dizajnu, koje je teško ispraviti u kasnijim fazama.

2. Grafički oblik prikaza modela, koji je razumljiv za one koji nisu programeri, omogućuje implementaciju principa korisničkog dizajna koji predviđa sudjelovanje korisnika u kreiranju sustava. CASE model omogućuje postizanje međusobnog razumijevanja svih sudionika u kreiranju sustava (kupaca, korisnika, dizajnera, programera).

3. Prisutnost formaliziranog modela sustava u fazi pred-dizajna stvara priliku za multivarijantnu analizu s prototipom i približnu procjenu učinkovitosti opcija. Analiza prototipa sustava omogućuje vam da prilagodite budući sustav prije nego što se fizički implementira. Ovaj pristup ubrzava i smanjuje troškove izrade sustava.

4. Konsolidacija zahtjeva sustava u formaliziranom obliku oslobađa dizajnere od potrebe brojnih prilagodbi za nove zahtjeve korisnika.

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

6. Prisutnost formaliziranog modela za implementaciju sustava i odgovarajućih alata za automatizaciju omogućuje automatsko generiranje koda softvera sustava i stvaranje racionalne strukture baze podataka.

7. U fazi rada sustava postaje moguće izvršiti promjene na razini modela bez pozivanja na tekstove programa, po mogućnosti trudom stručnjaka iz odjela automatizacije tvrtke.

8. Model sustava može se koristiti ne samo kao osnova za njegovu izradu, već i u svrhu automatizirane obuke osoblja pomoću dijagrama.

9. Na temelju modela operacijskog sustava, poslovna analiza može se izvesti za podršku odlukama upravljanja i poslovnom reinženjeringu pri promjeni smjera poslovanja tvrtke.

Razmotrite softver koji nudi CASE tehnologiju. Ovisno o svojoj funkcionalnoj namjeni, dijele se u sljedeće klasifikacijske skupine koje pružaju:

Analiza i projektiranje informacijskog sustava;

Dizajn baze podataka;

Programiranje;

Održavanje i reinženjering;

Upravljanje procesom projektiranja.

Alati za analizu i projektiranje koriste se za izgradnju CASE-modela kako postojećeg tako i implementiranog sustava upravljanja. Podržavaju grafičku konstrukciju i kontrolu hijerarhijskog modela dijagrama toka podataka i opis njegovih komponenti. Ovi alati omogućuju analitičarima i dizajnerima pristup dizajniranoj bazi podataka (repozitoriju) sustava.

Ova sredstva uključuju: domaći CASE paket. Analitičar, Dizajn / IDEF (Meta Software), Razvojni programer (ASYST Technologies) itd.

Kako bi se udovoljilo zahtjevima korisnika, izrađuju se prototipovi korisničkih sučelja, uključujući izbornike, prikaze i izvješća u obliku tablica ili grafikona. Primjer softverskog alata za izradu 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 shema baze podataka. Primjeri takvih alata su Designer / 2000 od Oraclea, ERWin (Logic Works) itd.

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

Alati za održavanje i reinženjering omogućuju vam da izvršite promjene u sustavu na razini modela pod promjenjivim poslovnim uvjetima (Adpac CASE Alati iz Adpaca, itd.).

Alati za upravljanje procesima dizajna podržavaju planiranje i kontrolu provedbe kompleksa projektantskih radova, kao i interakciju analitičara, dizajnera i programera na temelju zajedničke projektne baze podataka (na primjer, Project Workbench of Applied Business Technology). Očigledna je hitnost stvaranja integriranog paketa alata za podršku CASE-tehnologiji u svim fazama životnog ciklusa informacijskog sustava.

Federalna agencija za obrazovanje

Savezna država obrazovna ustanova Visoko stručno obrazovanje „Čuvaško državno sveučilište nazvano U Uljanovi "

Financijsko-ekonomski institut

Ekonomski fakultet

Sažetak na temu: CASE-tehnologije za projektiranje automatiziranih informacijskih sustava

Završio student

EK 22-06 grupe

Evgrafova I.A.

Provjera: Pavlova S.Yu.

Čeboksari 2007

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

· Životni ciklus softvera informacijskog sustava ……………………………………………………………………… .5

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

· Strukturna metoda razvoja softvera …… 10

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

Uvod

Tijekom proteklog desetljeća formirao se novi smjer u softverskom inženjerstvu - CASE (Computer-Aided Software / System Engineering) - u doslovnom prijevodu - razvoj softvera za informacijske sustave uz podršku (uz pomoć) računala. Trenutno ne postoji općeprihvaćena definicija SLUČAJ, pojam SLUČAJ se koristi u vrlo širokom smislu. Izvorno značenje pojma CASE, ograničeno na pitanja automatizacije razvoja samo softvera, sada je dobilo novo značenje, pokrivajući razvoj složenih automatiziranih informacijskih sustava u cjelini. Sada, pojam CASE alati označava softverske alate koji podržavaju procese stvaranja i održavanja IS-a, uključujući analizu i formulaciju zahtjeva, dizajn aplikacijskog softvera (aplikacija) i baza podataka, generiranje koda, testiranje, dokumentiranje, osiguranje kvalitete, upravljanje konfiguracijom i projektom. upravljanja, ali i drugih procesa. Alati CASE zajedno sa softverom i hardverom sustava čine cjelovito razvojno okruženje AIS-a.

CASE alati omogućuju vam ne samo stvaranje "pravih" proizvoda, već i pružanje "pravog" procesa za njihovo stvaranje. Glavni cilj CASE-a je odvojiti dizajn softvera od njegovog kodiranja i kasnijih razvojnih faza, kao i sakriti sve detalje razvojnog okruženja i funkcioniranja softvera od programera. Kod korištenja CASE tehnologija mijenjaju se sve faze životnog ciklusa softvera (o tome će biti više riječi u nastavku) informacijskog sustava, dok se najveće promjene odnose na faze analize i dizajna. Većina postojećih CASE alata temelji se na strukturnoj (uglavnom) ili objektno orijentiranoj analizi i metodologijama dizajna koje koriste specifikacije u obliku dijagrama ili tekstova za opisivanje vanjskih zahtjeva, odnosa između modela sustava, dinamike ponašanja sustava i arhitekture softvera. Takve metodologije daju rigorozan i vizualan opis projektiranog sustava, koji počinje njegovim općim pregledom, a zatim se detaljizira, poprimajući hijerarhijsku strukturu sa svim veliki broj razine. CASE tehnologije se uspješno koriste za izgradnju gotovo svih vrsta softverskih sustava, no zauzimaju stabilan položaj u sljedećim područjima:

♦ osiguravanje razvoja poslovnog i komercijalnog softvera, raširenost uporabe CASE-tehnologija posljedica je masovnosti ovog primijenjenog područja, u kojem se CASE koristi ne samo za razvoj softvera, već i za kreiranje modela sustava koji pomažu u rješavanju problema strateško planiranje, upravljanje financijama, utvrđivanje politike poduzeća, obuka osoblja i sl. (ovo je područje dobilo svoje ime – poslovna analiza);

♦ razvoj softvera sustava i upravljanja. Aktivna uporaba CASE-tehnologija povezana je s velikom složenošću ovog pitanja i željom da se poveća učinkovitost rada.

CASE nije revolucija u softverskom inženjerstvu, već rezultat prirodnog evolucijskog razvoja cijele industrije alata koji su se prije nazivali instrumentalnim ili tehnološkim. Od početka, CASE tehnologije su se razvijale kako bi prevladale ograničenja metodologija konstrukcijskog projektiranja u 1960-im i 1970-im. XX. stoljeće (složenost razumijevanja, visoka radna snaga i trošak korištenja, poteškoće u izmjenama projektnih specifikacija itd.) zbog njihove automatizacije i integracije pratećih alata. Stoga se CASE tehnologije ne mogu smatrati neovisnim metodologijama; one samo razvijaju strukturalne metodologije i čine njihovu primjenu učinkovitijom kroz automatizaciju.

Osim automatizacije strukturnih metodologija i, kao rezultat toga, mogućnosti korištenja modernih metoda sustavnog i softverskog inženjeringa, CASE alati imaju sljedeće glavne prednosti:

♦ poboljšati kvalitetu softvera koji se stvara automatskim upravljanjem (prije svega, kontrolom projekta);

♦ dopustiti za kratko vrijeme stvaranje prototipa budućeg sustava, što vam omogućuje procjenu očekivanog rezultata u ranoj fazi;

♦ ubrzati proces dizajna i razvoja;

♦ osloboditi programera od rutinskog rada, dopuštajući mu da se u potpunosti koncentrira na kreativni dio razvoja;

♦ podržati razvoj i održavanje razvoja;

♦ Podrška tehnologijama ponovne uporabe razvojnih komponenti.

Nastanku CASE-tehnologije i CASE-alata prethodila su istraživanja u području metodologije programiranja. Programiranje je dobilo značajke sistemskog pristupa razvojem i implementacijom jezika visoke razine, metoda strukturnog i modularnog programiranja, dizajnerskih jezika i sredstava njihove podrške, formalnih i neformalnih jezika opisa Zahtjevi sustava i specifikacije itd. 70-80-ih godina. strukturalna metodologija počela se primjenjivati ​​u praksi, pružajući programerima stroge formalizirane metode za opisivanje AIS-a i prihvaćenih tehnička rješenja... Temelji se na vizualnoj grafičkoj tehnici: sheme i dijagrami se koriste za opisivanje različitih vrsta AIS modela. Jasnoća i strogost alata za strukturnu analizu omogućila je programerima i budućim korisnicima sustava od samog početka da neformalno sudjeluju u njegovom stvaranju, raspravljaju i konsolidiraju razumijevanje glavnih tehničkih rješenja. Međutim, raširena uporaba ove metodologije i pridržavanje njezinih preporuka u razvoju kontaktnog AIS-a bila je prilično rijetka, budući da je ručnim (ručnim) razvojem to gotovo nemoguće. To je pridonijelo nastanku posebne klase softverskih i hardverskih alata - CASE-alata koji implementiraju CASE-tehnologiju za stvaranje i održavanje AIS-a.

Treba razumjeti da je uspješna upotreba CASE alata nemoguća bez razumijevanja temeljne tehnologije na kojoj se ti alati temelje. CASE softverski alati sami su po sebi alati za automatizaciju procesa projektiranja i održavanja informacijskih sustava. Nemoguće je koristiti CASE-alate bez razumijevanja metodologije projektiranja IS-a.

1. Životni ciklus softvera informacijskog sustava

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

Struktura životnog ciklusa softvera temelji se na tri skupine procesa:

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

♦ prateći procesi koji osiguravaju izvođenje glavnih procesa (dokumentacija, upravljanje konfiguracijom, osiguranje kvalitete, verifikacija, validacija, procjena, revizija, rješavanje problema);

♦ organizacijski procesi (upravljanje projektom, stvaranje projektne infrastrukture, definiranje, procjena i unapređenje samog životnog ciklusa, obuka).

Razvoj uključuje sve radove na izradi softvera i njegovih komponenti u skladu s navedenim zahtjevima, uključujući izradu projektne i operativne dokumentacije, pripremu materijala potrebnih za provjeru operativnosti i odgovarajuće kvalitete softverskih proizvoda, materijala potrebnih za organizaciju obuke osoblja, itd. Razvoj softvera obično uključuje analizu, dizajn i implementaciju (programiranje).

Operacija uključuje rad na implementaciji programskih komponenti u rad, uključujući konfiguraciju baze podataka i korisničkih radnih stanica, osiguravanje operativne dokumentacije, obuku osoblja i sl. te neposredno djelovanje, uključujući lokaliziranje problema i otklanjanje uzroka njihovog nastanka, modifikaciju softvera u okviru utvrđenih propisa, priprema prijedloga za unapređenje, razvoj i modernizaciju sustava.

Upravljanje projektom vezano je uz planiranje i organizaciju rada, stvaranje timova programera te kontrolu vremena i kvalitete obavljenog posla.

Tehnička i organizacijska podrška projekta uključuje izbor metoda i alata za provedbu projekta, definiranje metoda za opisivanje međustanja razvoja, razvoj metoda i alata za testiranje softvera, obuku osoblja itd. Projekt osiguranje kvalitete povezano je s problemima provjere, provjere i testiranja softvera. Provjera je proces utvrđivanja zadovoljava li trenutno stanje razvoja postignuto u određenoj fazi zahtjeve te faze. Provjera vam omogućuje procjenu usklađenosti razvojnih parametara s izvornim zahtjevima. Provjera se preklapa s testiranjem, koje se bavi utvrđivanjem razlika između stvarnih i očekivanih rezultata i procjenom sukladnosti karakteristika softvera s izvornim zahtjevima. U procesu provedbe projekta važno mjesto zauzimaju pitanja identifikacije, opisa i kontrole konfiguracije pojedinih komponenti i cjelokupnog sustava u cjelini.

Upravljanje konfiguracijom jedan je od pomoćnih procesa koji podržavaju glavne procese životnog ciklusa softvera, prvenstveno procese razvoja i održavanja softvera. Prilikom izrade projekata složenih IS-a, koji se sastoje od mnogih komponenti, od kojih svaka može imati varijante ili inačice, nastaje problem uzimanja u obzir njihovih veza i funkcija, stvaranja jedinstvene strukture i osiguravanja razvoja cijelog sustava. Upravljanje konfiguracijom omogućuje vam da organizirate, sustavno uzimate u obzir i kontrolirate promjene softvera u svim fazama životnog ciklusa. Opća načela i preporuke za računovodstvo konfiguracije, planiranje i upravljanje konfiguracijom softvera odražavaju se u nacrtu standarda ISO 12207-2.

Svaki proces karakteriziraju određeni zadaci i metode njihovog rješavanja, početni podaci dobiveni u prethodnoj fazi, rezultati. Rezultati analize su posebno funkcionalni modeli, informacijski modeli i njima odgovarajući dijagrami. Životni ciklus softvera je iterativne prirode: rezultati sljedeće faze često uzrokuju promjene u dizajnerskim rješenjima razvijenim u ranijim fazama.

Postojeći modeli životnog ciklusa određuju redoslijed izvođenja faza tijekom razvoja, kao i kriterije za prijelaz iz faze u fazu. U skladu s tim, najraširenija su sljedeća tri modela životnog ciklusa:

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

♦ fazni model sa srednjim upravljanjem (1980.-1985.) - iterativni model razvoja softvera s povratnom spregom između faza. Prednost ovog modela je u tome što prilagodbe među fazama pružaju manji intenzitet rada u usporedbi s kaskadnim modelom, ali se životni vijek svake faze proteže kroz cijelo razvojno razdoblje;

♦ Spiralni model (1986-1990) - fokusira se na početne faze životnog ciklusa: analiza zahtjeva, projektiranje specifikacije, idejni i detaljni projekt. U tim se fazama provjerava i opravdava izvedivost tehničkih rješenja izradom prototipa. Svaki zavoj spirale odgovara modelu korak po korak za izradu fragmenta ili verzije softverskog proizvoda, na njemu se specificiraju ciljevi i karakteristike projekta, utvrđuje se njegova kvaliteta i rad sljedećeg zavoja spirala je planirana. Tako se detalji projekta produbljuju i dosljedno specificiraju, te se kao rezultat odabire razumna opcija koja se dovodi u realizaciju.

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

♦ nakupljanje i ponovno koristiti softverski alati, modeli i prototipovi;

♦ usmjerenost na razvoj i modificiranje softvera u procesu njegovog dizajna;

♦ analiza rizika i troškova u procesu projektiranja.

glavna značajka industrija razvoja softvera sastoji se u koncentraciji složenosti u početnim fazama životnog ciklusa (analiza, dizajn) s relativno niskom složenošću i mukotrpnošću sljedećih faza. Štoviše, neriješeni problemi i pogreške napravljene tijekom faza analize i projektiranja dovode do teških, često nerješivih problema u kasnijim fazama i, u konačnici, dovode do neuspjeha cijelog projekta.

2. RAD -tehnologije za aplikacije za izradu prototipa

Jedan od mogućih pristupa razvoju softvera u okviru modela spiralnog životnog ciklusa je nedavno raširena metodologija brzog razvoja aplikacija RAD (Rapid Application Development). Ovaj izraz 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 raspored proizvodnje (od 2 do 6 mjeseci);

♦ ciklus koji se ponavlja u kojem programeri, kako se aplikacija počinje oblikovati, zahtijevaju i implementiraju u proizvod zahtjeve dobivene interakcijom s kupcem.

Razvojni tim trebao bi biti skupina profesionalaca s iskustvom u analizi, dizajnu, generiranju koda i testiranju softvera pomoću CASE alata. Članovi tima također moraju imati prijedloge za krajnje korisnike prevedene u radne prototipove.

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

♦ faze analize i planiranja zahtjeva;

♦ faze projektiranja;

♦ faze izgradnje;

♦ faze provedbe.

U fazi analize i planiranja zahtjeva korisnici sustava određuju funkcije koje mora obavljati, ističu one najprioritetnije koje prije svega zahtijevaju razradu, opisuju informacijske potrebe. Definiranje zahtjeva uglavnom provode korisnici pod vodstvom stručnjaka za razvoj. Opseg projekta je ograničen, određuje se vremenski okvir za svaku od sljedećih faza. Osim toga, utvrđuje se i sama mogućnost realizacije ovog projekta unutar utvrđenog okvira financiranja, na tim hardverima i sl. Rezultat ove faze trebao bi biti popis i prioritet funkcija budućeg AIS-a, preliminarni funkcionalni i informacijski modeli IS-a.

Tijekom faze projektiranja, neki korisnici sudjeluju u tehničkom dizajnu sustava pod vodstvom stručnjaka za razvoj. CASE alati se koriste za brzo dobivanje radnih prototipova aplikacija. Korisnici, u izravnoj interakciji s njima, pojašnjavaju i dopunjuju zahtjeve sustava koji nisu identificirani u prethodnoj fazi. Detaljnije se raspravlja o procesima sustava. Funkcionalni model se analizira i po potrebi korigira. Svaki proces se detaljno pregledava. Po potrebi se stvara djelomični prototip za svaki elementarni proces: ekran, dijaloški okvir, izvješće, eliminirajući nejasnoće ili nejasnoće. Utvrđeni su zahtjevi za razlikovanje pristupa podacima. U istoj fazi utvrđuje se komplet potrebne dokumentacije.

Nakon detaljnog određivanja sastava procesa, broj funkcionalni elementi sustav koji se razvija i donosi se odluka da se AIS podijeli na podsustave koje može implementirati jedan razvojni tim u vremenu prihvatljivom za RAD projekte – oko 60-90 dana. Pomoću CASE-alata projekt se distribuira između različitih timova (funkcionalni model je podijeljen). Rezultat ove faze trebao bi biti:

♦ opći informacijski model sustava;

♦ funkcionalni modeli sustava u cjelini i podsustava koje implementiraju pojedini razvojni timovi;

♦ sučelja između autonomno razvijenih podsustava, precizno definirana pomoću CASE-alata;

♦ izgrađen prototip ekrana, izvještaja, dijaloga.

Sve modele i prototipove treba nabaviti pomoću onih CASE-alata koji će se koristiti u budućnosti prilikom izgradnje sustava. Ovaj zahtjev je uzrokovano činjenicom da u tradicionalnom pristupu, pri prijenosu informacija o projektu iz faze u fazu, može doći do praktički nekontroliranog izobličenja podataka. Korištenjem jedinstvenog okruženja za pohranu informacija o projektu izbjegava se ova opasnost.

Za razliku od tradicionalnog pristupa, koji je koristio specifične alate za izradu prototipa koji nisu bili namijenjeni za izgradnju stvarnih aplikacija, a prototipovi su odbačeni nakon dovršetka zadatka otklanjanja nejasnoća u projektu, u RAD pristupu svaki se prototip razvija u dio budući sustav... Tako se potpunije i korisnije informacije prenose u sljedeću fazu.

U fazi izgradnje vrši se brzi razvoj same aplikacije. U ovoj fazi programeri iterativno grade pravi sustav na temelju modela dobivenih u prethodnoj fazi, kao i nefunkcionalnih zahtjeva. Programski kod je djelomično generiran pomoću automatskih generatora koji primaju informacije izravno iz spremišta CASE alata. Krajnji korisnici u ovoj fazi ocjenjuju dobivene rezultate i vrše prilagodbe ako tijekom procesa razvoja sustav više ne ispunjava prethodno definirane zahtjeve. Testiranje sustava provodi se izravno tijekom procesa razvoja.

Nakon završetka rada svakog pojedinog razvojnog tima, ovaj dio sustava se postupno integrira s ostatkom, formira se kompletan programski kod, provodi se testiranje raditi zajedno ovaj dio aplikacije s ostatkom, a zatim testiranje sustava u cjelini. Fizički dizajn sustava se dovršava:

♦ utvrđuje se potreba za distribucijom podataka;

♦ analizira korištenje podataka;

♦ provodi se fizički dizajn baze podataka;

♦ utvrđuju se zahtjevi za hardverskim resursima;

♦ identificirani su načini povećanja produktivnosti;

♦ izrada projektne dokumentacije je pri kraju. Rezultat faze je kompletan sustav koji zadovoljava sve dogovorene zahtjeve.

U fazi implementacije provode se edukacija korisnika, organizacijske promjene, a paralelno s uvođenjem novog sustava radi se i s postojećim sustavom (do potpune implementacije novog). Budući da je faza izgradnje relativno kratka, planiranje i priprema za implementaciju treba započeti rano, obično tijekom faze projektiranja sustava.

Navedena shema razvoja AIS-a nije apsolutna. moguće različite opcije ovisno o npr početni uvjeti u kojem je razvoj u tijeku: razvija li se potpuno novi sustav; je li provedeno informacijsko istraživanje organizacije i postoji li model za njezino djelovanje; postoji li u organizaciji neki AIS koji se može koristiti kao početni prototip ili bi trebao biti integriran s onim koji se razvija itd.

Međutim, valja napomenuti da RAD metodologija, kao i svaka druga, ne može zahtijevati univerzalnost, dobra je prvenstveno za relativno male projekte razvijene za određenog kupca. Ako se razvija tipični sustav, koji nije cjelovit proizvod, već je kompleks standardnih komponenti, centralno održavanih, prilagodljivih softverskim i hardverskim platformama, DBMS-u, telekomunikacijama, organizacijskim i ekonomskim značajkama implementacijskih objekata i integriranih s postojećim razvojem , u prvi plan dolaze pokazatelji projekta kao što su upravljivost i kvaliteta, što može biti u sukobu s jednostavnošću i brzinom razvoja. Takvi projekti zahtijevaju visoku razinu planiranja i strogu dizajnersku disciplinu, strogo pridržavanje unaprijed razvijenih protokola i sučelja, što smanjuje brzinu razvoja.

RAD metodologija nije primjenjiva na konstrukciju složenih računalnih programa, operacijskih sustava ili upravljačkih programa. svemirski brodovi, odnosno programi koji zahtijevaju pisanje velike količine (stotine tisuća redaka) jedinstvenog koda.

Aplikacije koje nemaju izražen dio sučelja koji jasno definira logiku rada sustava (npr. aplikacije u stvarnom vremenu), te aplikacije o kojima ovisi sigurnost ljudi (npr. upravljanje zrakoplovom ili nuklearnom elektranom) su nije prikladno za razvoj korištenjem RAD metodologije, budući da iterativni pristup pretpostavlja da prvih nekoliko verzija najvjerojatnije neće biti potpuno funkcionalne, što u u ovom slučaju isključen. Osnovna načela RAD metodologije:

♦ razvoj aplikacija po iteracijama;

♦ izborni potpuni završetak posla u svakoj fazi životnog ciklusa;

♦ obvezno uključivanje korisnika u proces razvoja AIS-a;

♦ nužna upotreba CASE-alata kako bi se osigurao integritet projekta;

♦ korištenje alata za upravljanje konfiguracijom kako bi se olakšalo uvođenje promjena u projekt i održavanje gotovog sustava;

♦ nužno korištenje generatora koda;

♦ korištenje prototipa, što omogućuje potpunije razjašnjenje i zadovoljavanje potreba krajnjeg korisnika;

♦ testiranje i razvoj projekta, koji se provodi istovremeno s razvojem;

♦ razvoj od strane malog dobro vođenog tima profesionalaca;

♦ kompetentno upravljanje razvojem sustava, jasno planiranje i kontrola uspješnosti rada.

3. Metoda razvoja strukturnog softvera

Bit strukturalni pristup Razvoj AIS-a sastoji se od njegove dekompozicije (podjele) na automatizirane funkcije: sustav je podijeljen na funkcionalne podsustave, koji su, pak, podijeljeni na podfunkcije, podijeljeni na zadatke itd. Proces particioniranja nastavlja se do specifičnih postupaka. U isto vrijeme, automatizirani sustav zadržava holistički pogled, u kojem su sve sastavne komponente međusobno povezane. Kod razvoja sustava "odozdo prema gore", od pojedinačnih zadataka do cijelog sustava, gubi se integritet, javljaju se problemi u informacijskom spajanju pojedinih komponenti.

Sve metodologije strukturne analize temelje se na nizu generalni principi, od kojih neki reguliraju organizaciju rada u početnim fazama životnog ciklusa, a neki se koriste za izradu 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, neovisnih problema koje je lakše razumjeti i riješiti. Drugi princip izjavljuje da je raspored ovih dijelova također bitan za razumijevanje. Stupanj razumijevanja problema naglo raste kada se njegovi dijelovi predstave u obliku stabla hijerarhijske strukture, odnosno sustav se može razumjeti i izgraditi u razinama, od kojih svaka dodaje nove detalje.

Isticanje dvaju osnovnih 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). Zabilježimo glavna od ovih načela.

1. Načelo apstrakcije - je istaknuti bitne s nekih pozicija aspekata sustava i apstrahirati od beznačajnih kako bi se problem prikazao u jednostavnom općem obliku.

2. Načelo formalizacije – je potreba za rigoroznim metodološkim pristupom rješavanju problema.

3. Princip „skrivanja“ – sastoji se u skrivanju informacija koje su nebitne u određenoj fazi: svaki dio „zna“ samo onu informaciju koja mu je potrebna.

4. Načelo konceptualne zajedništva – je slijediti jedinstvenu filozofiju u svim fazama životnog ciklusa (strukturalna analiza – projektiranje konstrukcije – strukturno programiranje – ispitivanje konstrukcije).

5. Načelo potpunosti - je kontrolirati prisutnost nepotrebnih elemenata.

6. Načelo konzistentnosti – leži u valjanosti i konzistentnosti elemenata.

7. Načelo logičke neovisnosti – usredotočiti se na logički dizajn kako bi se osigurala neovisnost od fizičkog dizajna.

8. Načelo neovisnosti podataka - leži u činjenici da se modeli podataka moraju analizirati i projektirati neovisno o procesima njihove logičke obrade, kao i o njihovoj fizičkoj strukturi i distribuciji.

9. Načelo strukturiranja podataka – je da podaci trebaju biti strukturirani i hijerarhijski organizirani.

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

Poštivanje ovih načela potrebno je prilikom organiziranja rada u početnim fazama životnog ciklusa, bez obzira na vrstu softvera koji se razvija i metodologije koje se u ovom slučaju koriste. Vodeći se svim principima u kompleksu, moguće je u ranijim fazama razvoja razumjeti što će biti sustav koji se stvara, za otkrivanje pogrešaka i nedostataka, što će zauzvrat olakšati rad u narednim fazama životnog ciklusa i smanjiti troškove razvoja.

U strukturnoj analizi uglavnom postoje dvije skupine alata koji ilustriraju funkcije koje sustav obavlja i odnose između podataka. Svaka skupina sredstava odgovara određenim vrstama modela (dijagrama), među kojima su najčešći sljedeći:

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

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

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

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

U fazi projektiranja IS-a modeli se proširuju, usavršavaju i nadopunjuju dijagramima koji odražavaju strukturu softvera: softversku arhitekturu, programske blok dijagrame i zaslonske dijagrame.

Navedeni modeli zajedno daju potpuni opis AIS-a, bilo da je postojeći ili novorazvijen. Sastav dijagrama u svakom konkretnom slučaju ovisi o potrebnoj potpunosti opisa sustava.

Metodologija SADT

Metodologiju SADT razvio je Douglas Ross, a na temelju nje, posebno, razvijena je poznata metodologija IDEFO (Icam Definition), koja je glavni dio programa Icam (Integracija računalnih i industrijskih tehnologija) koji se provodi na inicijativa Sjedinjenih Država. SADT metodologija je skup metoda, pravila i postupaka dizajniranih za izgradnju funkcionalnog modela objekta bilo kojeg predmetnog područja. Funkcionalni model SADT odražava funkcionalnu strukturu objekta, odnosno radnje koje obavlja i veze između tih radnji. Glavni elementi ove metodologije temelje se na sljedećim konceptima:

♦ grafički prikaz blok modeliranje. SADT blok i grafika luka prikazuju funkciju kao blok, a I/O sučelja su predstavljena lukovima koji ulaze i izlaze iz bloka. Interakcija blokova međusobno se opisuje pomoću lukova sučelja koji izražavaju "ograničenja", koja zauzvrat određuju kada i kako se funkcije izvode i kontroliraju;

♦ strogost i točnost. Usklađenost s SADT pravilima zahtijeva dovoljnu strogost i preciznost bez nametanja nepotrebnih ograničenja na radnje analitičara.

SADT pravila uključuju:

♦ ograničavanje broja blokova na svakoj razini dekompozicije (blokovi pravila 3-b);

♦ povezanost dijagrama (brojevi blokova);

♦ jedinstvenost oznaka i naziva (bez duplih naziva);

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

♦ razdvajanje ulaza i kontrola (pravilo za definiranje uloge podataka);

♦ odvajanje organizacije od funkcije, odnosno otklanjanje utjecaja organizacijske strukture na funkcionalni model.

SADT metodologija se može koristiti za modeliranje širokog raspona sustava i definiranje zahtjeva i funkcija, a zatim za dizajn sustava koji zadovoljava te zahtjeve i implementira te funkcije. Za već postojećih sustava SADT se može koristiti za analizu funkcija koje sustav obavlja, kao i za označavanje mehanizama pomoću kojih se one provode.

Rezultat primjene SADT metodologije je model koji se sastoji od dijagrama, fragmenata teksta i pojmovnika koji su međusobno povezani. Dijagrami su glavne komponente modela, sve IC funkcije i sučelja na njima su predstavljeni kao blokovi i lukovi. Veza između luka i bloka određuje vrstu sučelja. Kontrolne informacije ulaze u blok s vrha, dok su informacije koje se obrađuju prikazane s lijeve strane bloka, a rezultati izlaza prikazani su s desne strane. Mehanizam (osoba ili automatizirani sustav) koji izvodi operaciju predstavljen je lukom koji ulazi u blok odozdo (slika 1.6.1).

Jedna od najvažnijih značajki SADT metodologije je postupno uvođenje viših razina detalja kako se generiraju grafikoni koji predstavljaju model.

Izgradnja SADT modela počinje predstavljanjem cijelog sustava kao jednostavne komponente - jednog bloka i lukova koji predstavljaju sučelja s funkcijama izvan sustava. Budući da jedan blok predstavlja cijeli sustav kao cjelinu, naziv dat u bloku je uobičajen. Isto vrijedi i za lukove sučelja - oni također predstavljaju kompletan skup vanjskih sučelja sustava u cjelini.

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

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

SADT model je niz popratnih dijagrama koji se rastavljaju složeni objekt 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ćenitiji dijagram naziva se roditeljski dijagram za detaljniji dijagram.

Lukovi koji ulaze i izlaze iz bloka u dijagramu najviše razine potpuno su isti kao i lukovi koji ulaze u dijagram niži nivo i izvan njega, jer blok i dijagram predstavljaju isti dio sustava.

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

SADT dijagrami ne pokazuju eksplicitno slijed ili 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 osoba, računalo ili bilo koji drugi uređaj koji pomaže u obavljanju ove funkcije.

Svaki blok u dijagramu je numeriran. Blok bilo kojeg dijagrama može se dalje opisati dijagramom niže razine, koji se zauzvrat može dodatno detaljizirati pomoću potrebnog broja dijagrama. Tako se formira hijerarhija dijagrama. Za označavanje položaja bilo kojeg grafikona ili bloka u hijerarhiji, koriste se brojevi grafikona.

Modeliranje tokova podataka (procesa)

Glavni alat za modeliranje funkcionalni zahtjevi AIS su dijagrami toka podataka (DFD: - dijagrami toka podataka). Uz njihovu pomoć, ovi zahtjevi se raščlanjuju na funkcionalne komponente (procese) i predstavljaju kao mreža povezana tokovima podataka. glavni cilj takva sredstva - pokazati kako svaki proces transformira svoje ulaze u izlaze, kao i otkriti odnos između tih procesa.

Sukladno metodologiji, model sustava definiran je kao hijerarhija dijagrama toka podataka (DFD, ili DFD), koji opisuju asinkroni proces transformacije informacija od njihovog unosa u sustav do njihovog izdavanja korisniku. Dijagrami gornjih razina hijerarhije (kontekstni dijagrami) definiraju glavne procese ili podsustave IS-a s vanjskim ulazima i izlazima. Oni su detaljno prikazani pomoću dijagrama niske razine. Ova dekompozicija se nastavlja, stvarajući hijerarhiju dijagrama na više razina, sve dok se ne postigne takva razina dekompozicije na kojoj procesi postaju elementarni i nemoguće ih je dalje detaljizirati.

Izvori informacija (vanjski entiteti) generiraju tokove informacija (tokove podataka) koji prenose informacije do podsustava ili procesa. Oni pak transformiraju informacije i generiraju nove tokove koji prenose informacije drugim procesima ili podsustavima, uređajima za pohranu podataka ili vanjskim entitetima – potrošačima informacija. Dakle, glavne komponente dijagrama toka podataka su:

♦ vanjski subjekti;

♦ sustavi / podsustavi;

♦ procesi;

♦ uređaji za pohranu podataka;

♦ tokovi podataka.

Vanjski entitet je materijalni objekt ili pojedinac, koji je izvor ili primatelj informacija, na primjer, kupci, osoblje, dobavljači, kupci, skladište. Definicija nekog objekta ili sustava kao vanjskog entiteta ukazuje na to da se nalazi izvan granica analiziranog AIS-a.

Proces je transformacija ulaznih tokova podataka u izlaz u skladu s određenim algoritmom. Fizički, proces se može implementirati na različite načine: to može biti odjel organizacije (odjel) koji obrađuje ulazne dokumente i izdavanje izvješća, program, hardverski implementirani logički uređaj itd. U različitim notacijama proces se može prikazane dijagramima na različite načine. Za njegovu identifikaciju koristi se broj procesa. U polje za naziv upišite naziv procesa u obliku rečenice s aktivnim jednoznačnim glagolom u neodređenom obliku (izračunati, izračunati, provjeriti, definirati, stvoriti, dobiti), a zatim imenice u akuzativu, npr. :

♦ "Unesite podatke o klijentima";

♦ “Izdavanje informacija 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 daljnju analizu.

V novije vrijeme također je uobičajeno koristiti polje fizičke implementacije, informacija u kojoj pokazuje koji odjel organizacije, programa ili hardverskog uređaja obavlja ovaj proces.

Pohrana (podatkovni pogon) je apstraktni uređaj za pohranu informacija koji se u bilo kojem trenutku može staviti u pogon i nakon nekog vremena se može dohvatiti, a može postojati bilo koji način postavljanja i dohvaćanja.

Uređaj za pohranu podataka može se fizički implementirati u obliku mikrofiša, kutije u kartoteci, tablice u RAM-u, datoteke na magnetni nosač itd. Uređaj za pohranu podataka identificira se slovom "D" i proizvoljnim brojem. Naziv pogona odabran je iz najinformativnijih razloga za dizajnera.

Općenito, pohrana podataka je prototip buduće baze podataka, a opis podataka pohranjenih u njoj trebao bi biti povezan s informacijskim modelom. Tijek podataka definira informacije koje se prenose putem veze od izvora do ponora. Stvarni protok podataka može biti informacija koja se prenosi kabelom između dva uređaja, pisma poslana poštom, magnetske vrpce ili diskete koje se prenose s jednog računala na drugo, itd.

Tijek podataka u grafikonu predstavljen je linijom koja završava strelicom koja pokazuje smjer. Svaki tok podataka ima naziv koji odražava njegov sadržaj.

Prvi korak u izgradnji DFD hijerarhije je izgradnja kontekstnih dijagrama. Obično se pri projektiranju relativno jednostavnog AIS-a gradi jedan kontekstni dijagram sa topologijom u obliku zvijezde, u čijem je središtu tzv. glavni proces, povezan s prijamnicima i izvorima informacija putem kojih korisnici i drugi komuniciraju s sustav. vanjski sustavi... Za složeni AIS gradi se hijerarhija kontekstnih dijagrama. Istodobno, kontekstni dijagram najviše razine ne sadrži jedan glavni proces, već skup podsustava povezanih tokovima podataka. Kontekstni dijagrami sljedeće razine detaljno opisuju kontekst i strukturu podsustava.

Hijerarhija kontekstnog dijagrama definira interakciju glavnog funkcionalni podsustavi dizajnirani AIS kako među sobom tako i s vanjskim ulaznim i izlaznim tokovima podataka i vanjskim objektima (izvorima i primateljima informacija) s kojima AIS komunicira.

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

Nakon izrade dijagrama konteksta, rezultirajući model treba provjeriti na potpunost početnih podataka o objektima sustava i izoliranost objekata (odsutnost informacijskih veza s drugim objektima). Za svaki podsustav prisutan u kontekstnim dijagramima, on je izbušen pomoću DFD-a. Svaki proces na DFD-u, zauzvrat, može biti detaljan pomoću DFD-a ili minispec. Prilikom detaljiranja potrebno je poštivati ​​sljedeća pravila:

♦ pravilo balansiranja – znači da pri detaljiziranju podsustava ili procesa detaljni dijagram kao vanjski izvori/primatelji podataka mogu imati samo one komponente (podsustavi, procesi, vanjski entiteti, skladišta podataka) s kojima je detaljni podsustav ili proces na roditeljskom dijagramu ima informacijsku vezu;

♦ pravilo numeriranja - znači da prilikom detaljiranja procesa treba podržati njihovo hijerarhijsko numeriranje. Na primjer, procesi s detaljima procesa broj 12 označeni su brojevima 12.1, 12.2, 12.3 itd.

Minispecifikacija (opis logike procesa) treba formulirati svoje glavne funkcije na način da ih u budućnosti može obavljati stručnjak koji provodi projekt ili razviti odgovarajući program.

Minispec je konačni vrh DFD hijerarhije. Odluku o dovršetku detaljizacije procesa i korištenju minispec donosi analitičar, na temelju 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 postupkom jedne logičke funkcije pretvaranja ulaznih informacija u izlazne;

♦ sposobnost opisivanja logike procesa pomoću male minispecifikacije (ne više od 20-30 redaka).

Prilikom izgradnje DFD hijerarhije, potrebno je pristupiti detaljiziranju procesa tek nakon definiranja sadržaja svih tokova i uređaja za pohranu podataka, koji je opisan korištenjem podatkovnih struktura. Strukture podataka konstruirane su od stavki podataka i mogu sadržavati alternative, uvjete i iteracije. Uvjetni unos znači da ova komponenta možda nije prisutna u strukturi. Alternativno znači da struktura može uključivati ​​jedan od navedenih elemenata. Iteracija znači prolazak kroz bilo koji broj elemenata u navedenom rasponu. Za svaki element podataka može se naznačiti njegov tip (kontinuirani ili diskretni podaci). Za kontinuirane podatke može se naznačiti mjerna jedinica (kg, cm itd.), raspon vrijednosti, preciznost prikaza i oblik fizičkog kodiranja. Za diskretne podatke može se odrediti tablica prihvatljive vrijednosti.

Nakon izrade cjelovitog modela sustava potrebno ga je verificirati. U cjelovitom modelu svi njegovi objekti (podsustavi, procesi, tokovi podataka) moraju biti opisani i detaljno opisani. Otkrivene nedetaljne objekte treba detaljno opisati vraćanjem na prethodne razvojne korake. U konzistentnom modelu, za sve tokove podataka i uređaje za pohranu podataka, mora se ispuniti pravilo očuvanja informacija: svi podaci koji negdje pristižu moraju se pročitati, a svi pročitani podaci moraju biti zapisani.

Modeliranje podataka

Svrha modeliranja podataka je pružiti AIS developeru konceptualnu shemu baze podataka u obliku jednog ili više modela. lokalni modeli koje je relativno lako mapirati u bilo koji sustav 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 (veze). ERD-ovi se izravno koriste za dizajn relacijskih baza podataka (vidi odjeljak 2.2).

Oznaku ERD prvi je uveo P. Chen, a dalje je razvijen u djelima Barkera.

Metodologija IDEF 1

Metoda IDEF1, koju je razvio T. Ramey, također se temelji na pristupu P. Chena i omogućuje vam da izgradite model podataka koji je ekvivalentan relacijskom modelu u trećem normalnom obliku. Trenutno je na temelju poboljšanja IDEF1 metodologije kreirana. novu verziju- IDEF1X metodologija. IDEF1X je dizajniran s lakoćom učenja i automatizacijom na umu. IDEF IX dijagrame koriste brojni uobičajeni CASE alati (posebno ERWin, Design / IDEF).

Reference

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

Trofimov V.E., Lobacheva I.N. Informacijski sustavi u ekonomiji - M: Unity-Dana, 2008

Baldin N.V., Utkin V.B. Informacijski sustavi i tehnologije u ekonomiji - M: Jedinstvo, 2007

Titorenko T.A. Automatizirane informacijske tehnologije u ekonomiji - M: Jedinstvo, 2006

Baranovskaya T.P., Loiko V.I., Semenov M.I., Trubilin I.T. Automatizirane informacijske tehnologije u ekonomiji - M: Financije i statistika, 2006

1.3.1. Opći zahtjevi za metodologiju i tehnologiju

Metodologije, tehnologije i alati za projektiranje (CASE-alati) čine osnovu dizajna bilo kojeg IS-a. Metodologija se provodi kroz specifične tehnologije i njihove prateće standarde, metodologije i alate koji osiguravaju provedbu procesa životnog ciklusa.

Tehnologija dizajna definirana je kao kombinacija triju komponenti:

• postupak korak po korak koji određuje slijed operacija tehnološkog projektiranja (slika 1.4);
• kriteriji i pravila za ocjenu rezultata tehnoloških operacija;
• zapisi (grafički i tekstualni alati) koji se koristi za opisivanje projektiranog sustava.

Riža. 1.4. Prikaz operacije tehnološkog projektiranja

Tehnološke upute, koje čine glavni sadržaj tehnologije, trebaju se sastojati od opisa slijeda tehnoloških operacija, uvjeta, ovisno o tome koja se jedna ili druga operacija izvodi, te opisa samih operacija.

Projektiranje, razvoj i održavanje IS tehnologije moraju ispunjavati sljedeće opće zahtjeve:

• tehnologija mora podržavati cijeli životni ciklus softvera;
• tehnologija treba osigurati zajamčeno postizanje ciljeva razvoja IS-a uz zadanu kvalitetu iu određenom roku;
• tehnologija bi trebala osigurati mogućnost izvođenja velikih projekata u obliku podsustava (tj. sposobnost razlaganja projekta na njegove sastavne dijelove, koje su razvile grupe izvođača ograničenog broja uz naknadnu integraciju sastavnih dijelova). Iskustvo razvoja velikih IS-a pokazuje da je za poboljšanje učinkovitosti rada potrebno projekt podijeliti u zasebne podsustave koji su slabo povezani u pogledu podataka i funkcija. Implementaciju podsustava trebaju izvoditi odvojeni timovi stručnjaka. Istodobno, potrebno je osigurati koordinaciju održavanja zajedničkog projekta i isključiti dupliciranje rezultata rada svake projektne skupine, što može nastati zbog prisutnosti zajedničkih podataka i funkcija;
• tehnologija bi trebala osigurati mogućnost izvođenja radova na projektiranju pojedinih podsustava u malim skupinama (3-7 ljudi). To je zbog principa upravljanja timom i povećanja produktivnosti minimiziranjem broja vanjskih odnosa;
• tehnologija bi trebala osigurati minimalno vrijeme za dobivanje funkcionalnog IC-a. Ne govorimo o vremenu pripravnosti cijelog IS-a, nego o vremenu implementacije pojedinih podsustava. Implementacija IP-a općenito u kratkom vremenu može zahtijevati sudjelovanje veliki broj programeri, dok učinak može biti manji nego kada se pojedini podsustavi implementiraju u kraćem vremenskom okviru od strane manjeg broja programera. Praksa pokazuje da se čak iu prisutnosti potpuno dovršenog projekta implementacija odvija uzastopno kroz pojedine podsustave;
• tehnologija treba osigurati mogućnost upravljanja konfiguracijom projekta, održavanje verzija projekta i njegovih komponenti, mogućnost automatskog izdavanja projektne dokumentacije i sinkronizacije njezinih verzija s verzijama projekta;
• tehnologija mora osigurati neovisnost odluka o dizajnu koje se donose od sredstava implementacije IS-a (sustavi za upravljanje bazama podataka (DBMS), operativni sustavi, jezici i programski sustavi);
• tehnologija bi trebala biti podržana skupom koordiniranih CASE-alata koji osiguravaju automatizaciju procesa koji se izvode u svim fazama životnog ciklusa. Opći pristup ocjenjivanje i odabir CASE-alata opisano je u odjeljku 4, primjeri kompleksa CASE-alata - u pododjeljku 5.7.

Prava primjena bilo koje tehnologije za projektiranje, razvoj i održavanje IS-a u konkretnoj organizaciji i konkretnom projektu nemoguća je bez razvoja niza standarda (pravila, sporazuma) kojih se moraju pridržavati svi sudionici projekta. Ovi standardi uključuju sljedeće:

• standard dizajna;
• standard za projektiranje projektne dokumentacije;
• standard korisničkog sučelja.

Standardom dizajna treba utvrditi:

• komplet potrebni modeli(dijagrami) u svakoj fazi projektiranja i stupanj njihove detaljnosti;
• pravila za fiksiranje odluka o dizajnu na dijagramima, uključujući: pravila za imenovanje objekata (uključujući konvencije o terminologiji), skup atributa za sve objekte i pravila za njihovo popunjavanje u svakoj fazi, pravila za dizajn dijagrama, uključujući zahtjeve za oblik i veličinu objekata itd.;
• zahtjeve za konfiguraciju radnih mjesta programera, uključujući postavke operacijski sustav, postavke CASE-alata, Opće postavke projekt itd.;
• mehanizam za osiguranje zajedničkog rada na projektu, uključujući: pravila za integraciju projektnih podsustava, pravila za održavanje projekta u istom stanju za sve programere (pravila za razmjenu informacija o dizajnu, mehanizam za fiksiranje zajedničkih objekata, itd.), pravila za provjeru konzistentnosti projektantskih rješenja itd. .d.

Standardom za projektiranje projektne dokumentacije treba utvrditi:

• cjelovitost, sastav i struktura dokumentacije u svakoj fazi projektiranja;
• zahtjeve za njegov dizajn (uključujući zahtjeve za sadržaj odjeljaka, pododjeljaka, paragrafa, tablica itd.),
• pravila za pripremu, razmatranje, usklađivanje i odobravanje dokumentacije s naznakom rokova za svaku fazu;
• zahtjevi za postavljanje izdavačkog sustava koji se koristi kao ugrađeni alat za pripremu dokumenata;
• zahtjevi za postavljanje CASE-alata kako bi se osigurala priprema dokumentacije u skladu s utvrđenim zahtjevima.

Standard korisničkog sučelja trebao bi navesti:

• pravila dizajna zaslona (fontovi i paleta boja), sastav i raspored prozora i kontrola;
• pravila za korištenje tipkovnice i miša;
• pravila za oblikovanje tekstova pomoći;
• popis standardnih poruka;
• pravila za postupanje s reakcijama korisnika.

CASE-alati za projektiranje informacijskih sustava

U suvremenim uvjetima, složenost stvaranja informacijskih sustava je vrlo visoka. Stoga je u dizajnu IC-a tehnologija CASE postala široko korištena.

CASE tehnologija Programski je paket koji automatizira cjelokupni tehnološki proces analize, projektiranja, razvoja i održavanja složenih programskih alata.

Moderni CASE alati pokrivaju široko područje podrške za brojne tehnologije dizajna IC: od jednostavna sredstva analizu i dokumentaciju do potpunih alata za automatizaciju koji pokrivaju cijeli životni ciklus softvera.

Najzahtjevnije faze razvoja IS-a su faze analize i projektiranja, tijekom kojih CASE-alati osiguravaju visoku kvalitetu tehničkih rješenja i izradu projektne dokumentacije. Istodobno, važnu ulogu imaju grafički alati za modeliranje predmetnog područja koji programerima omogućuju vizualno proučavanje postojećeg IS-a, njegovu obnovu u skladu s ciljevima i postojećim ograničenjima.

Integrirani CASE alati imaju sljedeće karakteristične značajke :

· Osiguravanje upravljanja procesom razvoja IS-a;

· Korištenje posebno organizirane pohrane metapodataka projekta (repozitorija).

Integrirani CASE alati sadrže sljedeće komponente:

· Alati za grafičku analizu i dizajn koji se koriste za opisivanje i dokumentiranje IS-a;

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

· Repozitorij koji osigurava pohranu verzija projekta koji se razvija i njegovih pojedinačnih komponenti, sinkronizaciju protoka informacija od raznih programera tijekom grupnog razvoja, kontrolu metapodataka za potpunost i dosljednost;

· Alati za upravljanje procesom razvoja IS-a;

· Sredstva dokumentacije;

· Alati za testiranje;

Alati za reinženjering koji omogućuju analizu programskih kodova i shema baza podataka te formiranje na njihovoj osnovi različiti modeli i specifikacije dizajna.

Svi moderni CASE alati podijeljeni su u dvije skupine. Prva grupa organizirati sredstva ugrađena u implementacijski sustav, u kojem su sve odluke o dizajnu i implementaciji vezane uz odabrani sustav upravljanja bazom podataka. Druga grupa organizirati sredstva neovisna o sustavu implementacije, u kojima su sve projektne odluke usmjerene na objedinjavanje početnim fazamaživotni ciklus i način njihove dokumentacije. Ovi alati pružaju veliku fleksibilnost u izboru alata za implementaciju.

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

Kao etape stvaranje softverskih proizvoda za informacijske sustave, može se razlikovati sljedeće:

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

2. Konstrukcija dijagrama se izvodi i grafička analiza... U ovoj fazi grade se dijagrami koji uspostavljaju vezu s izvorima informacija i potrošačima, određuju procese transformacije podataka i gdje se oni pohranjuju.

3. Određuje se specifikacija i zahtjevi za sustav (vrsta sučelja, tip podataka, struktura sustava, kvaliteta, performanse, tehnička sredstva, ukupni troškovi itd.).

4. Modeliranje podataka je u tijeku; unose se informacije koje opisuju podatkovne elemente sustava i njihove odnose.

5. Procesi se modeliraju, t.j. uvode se informacije koje opisuju procese sustava i njihove odnose.