1.1 Koncept pojma - "CASE-alati"

U početku se pojam "CASE-tehnologija" (Computer - Aided Software Engineering) shvaćao doslovno - "automatizirani razvoj softvera IS korištenjem računalne tehnologije".

Trenutno se pojam CASE-alati odnosi na opsežan skup softverskih alata koji podržavaju procese stvaranja i održavanja IS-a, uključujući analizu i formuliranje zahtjeva, dizajn aplikacijskog softvera (aplikacija) i baza podataka, generiranje koda, testiranje, dokumentiranje, kvalitetu osiguranje, upravljanje konfiguracijom i upravljanje projektima te druge procese. CASE alati zajedno sa sistemskim softverom i hardverom čine cjelovito razvojno okruženje IS-a.

CASE tehnologije su skup metodologija i alata za analitičare, programere i programere dizajniranih za automatizaciju dizajna i održavanja IS-a tijekom cijelog životnog ciklusa.

Metodologija CASE alata definira faze i korake provedbe projekta, kao i pravila korištenja metoda kojima se projekt razvija. Metoda CASE alata je postupak ili tehnika za generiranje opisa komponenti informacijskog sustava (projektiranje tokova i struktura podataka). Notacija alata CASE - prikaz strukture sustava, podatkovnih elemenata pomoću posebnih grafičkih simbola.

CASE alati su posebni programi koji podržavaju jednu ili više metodologija analize i dizajna informacijski sustavi. CASE tehnologija, u okviru metodologije, uključuje metode kojima se dijagrami grade na temelju notacija koje podržava određeni CASE alat. CASE-tehnologije se ne mogu smatrati neovisnima, one samo pružaju visoku učinkovitost njihove primjene, određenu vremenom razvoja projekta.

Moderni CASE alati pokrivaju široko područje podrške za brojne tehnologije dizajna informacijskih sustava: od jednostavna sredstva analizu i dokumentaciju do potpunih alata za automatizaciju koji pokrivaju cijeli životni ciklus softvera. Najdugotrajnije faze razvoja informacijskih sustava su faze analize i projektiranja, tijekom kojih CASE-alati osiguravaju kvalitetu donesenih tehničkih odluka i izradu projektne dokumentacije. Pritom važnu ulogu igraju metode vizualne prezentacije informacija. To uključuje izradu strukturnih ili drugih dijagrama u stvarnom vremenu, korištenje raznih paleta boja, end-to-end provjera sintaktičkih pravila. Grafički alati za modeliranje domene omogućuju programerima vizualno proučavanje postojećeg informacijskog sustava, njegovu rekonstrukciju u skladu s ciljevima i postojećim ograničenjima.

1.2 Tipična struktura CASE alata

CASE alati služe kao alati za podršku i korištenje metoda analize konstrukcija u projektiranju. Ovi alati podržavaju rad korisnika prilikom izrade i uređivanja grafičkog projekta interaktivni način rada. Oni doprinose organizaciji projekta u obliku hijerarhije razina apstrakcije, vrše provjere usklađenosti komponenti. Zapravo, CASE alati su nova vrsta grafički orijentiranih alata, koji datiraju iz sustava podrške životnog ciklusa softvera. Obično uključuju bilo koji softverski alat koji pruža automatsku pomoć u razvoju softvera, održavanju ili aktivnostima upravljanja projektom i pokazuje sljedeće dodatne karakteristike:

snažna grafika za opisivanje i dokumentiranje softverskih sustava sa specifičnim korisničkim sučeljem, razvijajući kreativne sposobnosti stručnjaka i ne odvlačeći ih od procesa dizajna na rješavanje sekundarnih problema;

integracija koja omogućuje jednostavan prijenos podataka između alata i omogućuje upravljanje cijelim procesom dizajna i razvoja softvera izravno kroz proces planiranja projekta;

korištenje računalne pohrane (repozitorija) za predloške dijelova i pojedinačnih elemenata projekta, koje mogu koristiti različiti programeri, kao temelj za automatsku proizvodnju softvera i njegovu ponovnu upotrebu u budućim sustavima.

Uz navedene temeljne principe grafičke orijentacije, integracije i lokalizacije svih projektnih informacija u repozitoriju, konceptualna konstrukcija CASE-alata temelji se na sljedećim odredbama:

1. Ljudski faktor koji definira razvoj softvera kao jednostavan, praktičan i ekonomičan proces.

2. Raširena uporaba osnovnih programskih alata koji su postali široko rasprostranjeni u drugim aplikacijama (DB i DBMS, prevoditelji za različite programske jezike, debuggeri, dokumentatori, sustavi za izdavanje, ljuske ekspertnih sustava i baze znanja, jezici četvrte generacije itd.).

3. Automatizirano ili automatsko generiranje koda, za razne platforme i razne vrste koda: transformacije za dobivanje dokumentacije; formiranje strukture baze podataka, unos/izmjena podataka; dobivanje izvršnih strojnih kodova iz softverskih specifikacija; sklapanje modula iz rječnika i podatkovnih modela te programa za višekratnu upotrebu.

4. Jednostavnost korištenja, što vam omogućuje da dobijete komponente kojima se može upravljati, koje su vidljive i razumljive, kao i da imaju jednostavnu i jasnu strukturu.

5. Dostupnost za različite kategorije korisnika.

6. Profitabilnost.

7. Učinkovito rješavanje zadataka za podršku razvijenom projektu, pružajući mogućnost prilagodbe kada se zahtjevi i ciljevi projekta promijene od strane kupca.

Gotovo svi moderni CASE alati uključuju sljedeće elemente:

repozitorij, omogućuje vam da osigurate sigurnost predložaka projekta i njegovih specifičnih komponenti, sinkronizaciju informacija različitih programera u procesu grupnog razvoja, provjeru potpunosti i dosljednosti metapodataka;

alati za razvoj aplikacija koji koriste 4GL jezike i generatore koda;

alati za testiranje;

sredstva dokumentacije;

alati za grafičku analizu i dizajn koji omogućuju izradu i uređivanje modela informacijskog sustava u obliku hijerarhijski povezanih dijagrama u implementiranoj notaciji određene metodologije;

alati za reinženjering;

alati za upravljanje konfiguracijom;

alati za upravljanje projektima.

1.3 Evolucija razvoja CASE tehnologija

Od samog početka, CASE tehnologije razvijane su s ciljem prevladavanja ograničenja "ručne" primjene analize konstrukcija i metodologije projektiranja iz 60-ih i 70-ih godina njezinom automatizacijom i integracijom u prateće alate. Stoga se CASE-tehnologije ne mogu smatrati nezavisnim metodologijama modeliranja, one samo čine njihovu primjenu učinkovitijom u smislu vremena razvoja.

Tradicionalno se razlikuje šest razdoblja, kvalitativno različitih u primijenjenoj tehnici i metodama razvoja softvera, koje karakterizira korištenje kao alata:

1. Asembleri, memorijski dumpovi, analizatori;

2. Sastavljači, tumači, tragači;

3. Simbolički debuggeri, programski paketi;

4. Sustavi analize i upravljanja izvornim tekstovima;

5. CASE alati za analizu zahtjeva, projektiranje specifikacija i strukture, sučelja za uređivanje (prva generacija CASE-I);

6. Alati za generiranje CASE-a izvorni kod i implementacija integriranog okruženja za podršku punog životnog ciklusa razvoja softvera (druga generacija CASE-II)

CASE-I je prva tehnologija izravno upućena analitičarima sustava i dizajnerima, a uključuje alate za podršku grafičkim modelima, specifikacijama dizajna, uređivačima zaslona i rječnikima podataka. Nije namijenjen podršci punog životnog ciklusa i fokusiran je na funkcionalne specifikacije i početne korake projekta - analizu sustava, definiranje zahtjeva, dizajn sustava, logički dizajn baze podataka.

CASE-II ima znatno naprednije značajke, poboljšane performanse i sveobuhvatan pristup punom životnom ciklusu softvera koji se razvija. CASE-II set alata prvenstveno koristi podršku za automatsko generiranje koda i pruža punu funkcionalnu podršku za ispunjavanje zahtjeva grafičkog sustava i specifikacija dizajna; kontrola, analiza i povezivanje informacija o sustavu i informacija o upravljanju dizajnom; izrada prototipova i modela sustava; testiranje, verifikacija i analiza generiranih programa; izrada projektne dokumentacije; kontrola usklađenosti sa standardima u svim fazama životnog ciklusa. CASE-II može uključivati ​​preko 100 funkcionalnih komponenti koje podržavaju sve faze životnog ciklusa, a korisnicima je dana mogućnost odabira potrebnih alata i njihove integracije u željeni sastav.

1.4 Metodologije dizajna korištene u CASE alatima

CASE alati rezultat su prirodne evolucije industrije alata (ili tehnologije). CASE tehnologije su se počele razvijati kako bi se prevladala ograničenja metodologije strukturiranog programiranja.

Ovu metodologiju, usprkos formalizaciji u programiranju, još uvijek karakterizira složenost razumijevanja, visok intenzitet rada i trošak korištenja te teškoća unošenja izmjena u specifikacije dizajna. Načela postavljena u njemu omogućila su razvoj ove metodologije i povećanje njene učinkovitosti automatiziranjem najrutinskijih faza (slika 1.1).

Glavni standardi metodologija implementiranih u CASE alate su:

SADT (Structured Analysis and Design Technique) - metodologija strukturne analize i projektiranja. Temeljeno na konceptima funkcionalnog modeliranja. Odražava karakteristike sustava kao što su kontrola, povratna informacija i izvođač;

IDEF0 (Integrated Definition Function Modeling) je metodologija funkcionalnog modeliranja. Koristi se za izradu funkcionalnog modela koji prikazuje strukturu i funkcije sustava, kao i tokove informacija i materijalnih objekata transformiranih tim funkcijama. To je podskup SADT metodologije;

DFD(DataFlow Diagram) - metodologija za modeliranje tokova podataka.

Slika 1.1 - Usporedba tradicionalnog razvoja i razvoja pomoću CASE tehnologija

Za opisivanje razmjene podataka između radnih procesa primjenjuju se sljedeći metodološki standardi:

IDEF1 se koristi za izgradnju informacijskog modela koji prikazuje strukturu i sadržaj tokova informacija potrebnih za podršku funkcijama sustava;

IDEF2 vam omogućuje da izgradite dinamički model vremenski promjenjivog ponašanja funkcija, informacija i resursa sustava;

IDEF3 je metodologija modeliranja tijeka rada. Detaljniji je u odnosu na IDEF0 i DFD. Omogućuje vam da razmotrite određeni proces, uzimajući u obzir redoslijed izvedenih operacija. IDEF3 opisuje scenarij i redoslijed operacija za svaki proces;

IDEF1X (IDEF1 Extended) - metodologija opisa podataka. Koristi se za izradu baza podataka. Odnosi se na tip metodologije "Entity-Relationship" (ER - Entity-Relationship) i u pravilu se koristi za modeliranje relacijskih baza podataka vezanih uz predmetni sustav;

IDEF4 je objektno orijentirana metodologija. Odražava interakciju objekata. Omogućuje vam vizualni prikaz strukture objekata i osnovnih principa njihove interakcije. Pogodno za izradu softverskih proizvoda u objektno orijentiranim jezicima;

IDEF5 - metodologija za ontološka istraživanja složenih sustava. Metodologijom IDEF5 ontologiju sustava moguće je opisati posebnim rječnikom pojmova i pravila na temelju kojih se mogu formirati pouzdani iskazi o stanju promatranog sustava u određenom trenutku;

ARIS - opisuje poslovni proces kao tijek uzastopno obavljenog rada;

UML - (Unified Modeling Language) objedinjeni jezik za modeliranje temeljen na objektno orijentiranom pristupu. UML vam omogućuje da opišete statičku strukturu sustava i njegovo dinamičko ponašanje u odgovarajućim zapisima.

CASE alati u velikoj mjeri koriste strukturne i objektno orijentirane metodologije projektiranja. Strukturni dizajn temelji se na algoritamskoj dekompoziciji, dok se objektno projektiranje temelji na objektno orijentiranoj dekompoziciji. Algoritamska dekompozicija omogućuje određivanje redoslijeda događaja koji se događaju. Objektno orijentirana dekompozicija omogućuje vam definiranje hijerarhije klasa objekata, njihovih metoda i svojstava. CASE alati koji podržavaju objektno orijentirani dizajn koriste RUP (Rational Unified Process) metodologiju i UML notacije.

1.5 Metodologija CASE alata za objektno orijentirano projektiranje

U objektno orijentiranom pristupu, glavna kategorija objektnog modela, klasa, na elementarnoj razini kombinira i podatke i operacije koje se nad njima izvode (metode). Upravo s tog gledišta najuočljivije su promjene povezane s prijelazom sa strukturalnog na objektno orijentirani pristup. Prevladana je odvojenost procesa i podataka, no ostaje problem prevladavanja složenosti sustava koji se rješava korištenjem mehanizma komponenti.

U usporedbi s procesima, podaci su stabilniji i relativno rjeđi dio sustava. To je glavna prednost objektno orijentiranog pristupa, koji je Gradi Booch formulirao na sljedeći način: objektno orijentirani sustavi su otvoreniji i lakše se mijenjaju, jer se njihov dizajn temelji na stabilnim oblicima. To omogućuje postupni razvoj sustava i ne dovodi do njegove potpune obrade, čak ni u slučaju značajnih promjena u početnim zahtjevima.

Booch također primjećuje niz sljedećih prednosti objektno orijentiranog pristupa.

1. Dekompozicija objekta omogućuje stvaranje manjih softverskih sustava korištenjem zajedničkih mehanizama koji osiguravaju potrebnu ekonomičnost izražajnih sredstava. Korištenje objektnog pristupa značajno povećava razinu unifikacije razvoja i ponovne upotrebe ne samo programa, već i projekata, što u konačnici dovodi do stvaranja razvojnog okruženja i prijelaza na montažni razvoj softvera. Sustavi su često kompaktniji od svojih strukturnih ekvivalenata, što znači ne samo manje koda, već i jeftinije dizajne iskorištavanjem prethodnih dizajna.

2. Dekompozicija objekta smanjuje rizik od stvaranja složenih softverskih sustava, budući da uključuje evolucijski put razvoja sustava koji se temelji na relativno malim podsustavima. Proces integracije sustava proteže se kroz cijelo razvojno razdoblje i ne pretvara se u jednokratni događaj.

3. Objektni model je sasvim prirodan, jer je primarno usmjeren na ljudsku percepciju svijeta, a ne na računalnu implementaciju.

4. Objektni model omogućuje vam da u potpunosti iskoristite izražajne mogućnosti objekata i objektno orijentiranih programskih jezika.

Nedostaci objektno orijentiranog pristupa uključuju određeno smanjenje performansi softvera i visoke početne troškove. Objektna dekompozicija bitno se razlikuje od funkcionalne dekompozicije, pa je prelazak na novu tehnologiju povezan s prevladavanjem psihičkih poteškoća i dodatnih financijskih troškova. Naravno, objektno orijentirani model najadekvatnije odražava stvarni svijet, koji je zbirka međusobno (putem poruka) objekata. Ali u praksi se trenutno nastavlja formiranje standarda jezika UML za objektno orijentirano modeliranje, a broj CASE alata koji podržavaju objektno orijentirani pristup je mali u usporedbi sa sličnim alatima koji podržavaju strukturni pristup.

Osim toga, dijagrami koji odražavaju specifičnosti objektnog pristupa (dijagrami klasa, itd.) mnogo su manje vizualni i neprofesionalci ih slabo razumiju. Stoga je jedan od glavnih ciljeva uvođenja CASE tehnologije, a to je opskrba svih sudionika projekta (uključujući i kupca) Česti jezik“prenijeti razumijevanje”, danas je omogućeno samo strukturalnim metodama.

U prijelazu sa strukturalnog pristupa na objektni pristup, kao i kod svake promjene tehnologije, potrebno je ulagati u nabavu novih alata. Ovdje treba uzeti u obzir i troškove obuke (savladavanje metode, alata i programskog jezika). Za neke organizacije ove okolnosti mogu postati ozbiljne prepreke. Objektno orijentirani pristup ne daje trenutačne rezultate. Učinak njegove primjene počinje utjecati nakon razvoja dva ili tri projekta i nakupljanja komponenti za višekratnu upotrebu koje odražavaju tipična dizajnerska rješenja u ovom području. Prijelaz organizacije na objektno orijentiranu tehnologiju je promjena mišljenja, a ne samo učenje novih CASE alata i programskih jezika.

Očito je da je u određenom projektu nemoguće razgraditi složeni sustav na dva načina istovremeno. Može se započeti s dekompozicijom na jedan način, a zatim pomoću rezultata pokušati sagledati sustav s druge točke gledišta. Sada prijeđimo na razmatranje odnosa između strukturalnog i objektno orijentiranog pristupa. Osnova odnosa je zajedništvo niza kategorija i koncepata oba pristupa (proces i slučaj upotrebe, entitet i klasa, itd.). Taj se odnos može manifestirati u različitim oblicima. Stoga je jedan mogući pristup koristiti strukturnu analizu kao osnovu za objektno orijentirano projektiranje. Ovaj pristup je koristan s obzirom na široku rasprostranjenost CASE-alata koji podržavaju strukturnu analizu. Strukturna analiza se nastavlja sve do trenutka u kojem dijagrami protoka podataka počnu odražavati ne samo predmetno područje, već i softverski sustav.

Nakon provedbe strukturne analize i crtanja dijagrama toka podataka, zajedno sa strukturama podataka i drugim rezultatima analize, možete početi definirati klase i objekte na razne načine. Dakle, ako uzmemo bilo koji zasebni dijagram, onda vanjski entiteti i pohrane podataka mogu biti kandidati za objekte, a tokovi podataka mogu biti kandidati za klase.

Drugi oblik manifestacije odnosa može se smatrati integracijom objektnih i relacijskih tehnologija. Relacijski DBMS danas su glavno sredstvo implementacije velikih baza podataka i skladišta podataka. Razlozi za to su očiti: relacijska tehnologija se koristi već dugo, savladao ju je ogroman broj korisnika i programera, postala je industrijski standard, u nju su uložena značajna sredstva i stvorene su mnoge korporativne baze podataka u raznim industrije, relacijski model je jednostavan i ima strogu matematičku osnovu; postoji širok izbor industrijskih alata za projektiranje, implementaciju i rad s relacijskim bazama podataka. Zbog toga se relacijske baze podataka uglavnom koriste za pohranjivanje i traženje objekata u takozvanim objektno-relacijskim sustavima. Objektno orijentirani dizajn ima dodirne točke s relacijskim dizajnom. Na primjer, kao što je gore navedeno, klase u objektnom modelu mogu na neki način odgovarati entitetima (kao vježbu, predlaže se detaljna analiza svih sličnosti i razlika između dijagrama entitet-odnos i dijagrama klasa). U pravilu se takva korespondencija odvija samo u ranoj fazi razvoja sustava - fazi formiranja zahtjeva. U budućnosti se, naravno, razilaze ciljevi objektno orijentiranog projektiranja (adekvatno modeliranje predmetnog područja u smislu interakcije objekata) i razvoja relacijske baze podataka (normalizacija podataka). Stoga je jedini mogući način prevladavanja ovog jaza definiranje korespondencije između objektno orijentiranih i relacijskih tehnologija, što se u osnovi svodi na prikazivanje dijagrama klasa i dijagrama entiteta i odnosa relacijskog modela. Jedan od primjera praktične primjene odnosa između strukturnog i objektno orijentiranog pristupa je softversko sučelje(most) između strukturnog CASE alata Silverrun i objektno orijentiranog CASE alata Rational Rose, koji je razvila ruska tvrtka Argussoft.Ovaj softver stvara Rational Rose dijagrame klasa na temelju Silverrun RDM (Relational Data Model) modela i obrnuto. Slična sučelja također postoje između ERwin CASE alata (s jedne strane), Rational Rose i Paradigm Plus (s druge strane).

1.6 Metodologija projektiranja konstrukcija CASE alati

Bit strukturalnog pristupa razvoju informacijskog sustava leži u njegovoj dekompoziciji (particioniranju) na automatizirane funkcije. Automatizirani sustav je podijeljen na funkcionalne podsustave, koji su pak podijeljeni na podfunkcije, dalje podijeljeni na zadatke i tako dalje. Proces particioniranja nastavlja se do specifičnih postupaka. Istovremeno, automatizirani sustav zadržava holistički pogled u kojem su sve komponente međusobno povezane. Kod razvoja sustava "odozdo prema gore" od pojedinačnih zadataka do cijelog sustava gubi se cjelovitost, nastaju problemi s pristajanjem informacija pojedinačne komponente.

Sve najčešće metodologije strukturnog pristupa temelje se na nizu općih načela. Glavna načela su:

princip dekompozicije – princip odlučivanja teške probleme raščlanjivanjem na mnogo manjih i neovisnih zadataka koje je lako razumjeti i riješiti;

princip hijerarhijskog uređenja - princip organiziranja sastavnih dijelova problema u hijerarhijske strukture stabla uz dodavanje novih detalja na svakoj razini.

načelo apstrakcije – je isticanje bitnih aspekata sustava i apstrakcija od nebitnih;

načelo formalizacije - leži u potrebi za strogim metodološkim pristupom rješavanju problema;

načelo dosljednosti - leži u valjanosti i dosljednosti korištenja elemenata sustava;

princip strukturiranja podataka - je da podaci trebaju biti strukturirani i hijerarhijski organizirani.

U strukturnoj analizi uglavnom se koriste dvije skupine alata koji ilustriraju funkcije koje obavlja sustav i odnose između podataka.

Svaka skupina alata odgovara određenim vrstama 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 (dijagrami entiteta i odnosa)

U fazi projektiranja informacijskog sustava (IS) modeli postaju složeniji, dorađuju se i nadopunjuju dijagramima koji odražavaju strukturu i arhitekturu softvera, blok dijagramima programa i dijagramima ekranskih formi. Navedeni modeli zajedno daju cjelovit opis IS-a, bez obzira radi li se o postojećem ili novorazvijenom. Sastav dijagrama u svakom pojedinom slučaju ovisi o potrebnoj cjelovitosti opisa sustava.

2.2 Razvoj konceptualni model informacijski sistem.

Konceptualni model predstavlja objekte i njihove odnose bez navođenja načina na koji su fizički pohranjeni. Stoga je konceptualni model u biti model domene. Prilikom dizajniranja konceptualnog modela, podaci bi trebali biti strukturirani, a odnosi između njih trebali bi se identificirati bez razmatranja značajki implementacije i pitanja učinkovitosti.

obrada. Izrada konceptualnog modela temelji se na analizi zadataka koji stoje pred reklamnom agencijom. Konceptualni model uključuje opise objekata i njihovih odnosa koji su od interesa za predmetno područje koje se razmatra i koji su identificirani kao rezultat analize podataka.

Da bismo izgradili model koji nam je potreban, sve dostupne podatke doveli smo u treću normalnu formu, čime smo dobili sljedeće entitete:

vrste jela.

· Osoblje.

· Pozicije.

· Stalni kupci.

· Narudžbe.

Gradimo model na logičkoj razini (vidi sliku 2). Slika 2 pokazuje da postoje veze u modelu. Razmotrimo ih detaljnije:

Tablica "Vrste jela" i tablica "Jela" - uspostavlja se odnos jedan prema više pomoću Osnovni ključ"Prikaži kod";

Tablica "Pozicije" i tablica "Osoblje" - uspostavlja se odnos jedan prema više pomoću primarnog ključa "Šifra radnog mjesta";

Tablica "Jela" i tablica "Narudžbe" - uspostavljen je odnos "jedan prema više" pomoću primarnog ključa "Šifra jela";

Tablica "Kadrovi" i tablica "Nalozi" - uspostavlja se odnos jedan prema više pomoću primarnog ključa "ID zaposlenika";

Tablica "Stalni kupci" i tablica "Narudžbe" - uspostavlja se odnos jedan prema više pomoću primarnog ključa "ID kupca".

Riža. 2. Konceptualni model podataka

2.3 Izrada logičkog modela informacijskog sustava

Baze podataka i programski alati za njihovu izradu i održavanje (DBMS) imaju višerazinsku arhitekturu, čiju sliku možete dobiti sa slike 1.

Shema 1 - Višerazinska prezentacija podataka baze podataka pod

upravljanje DBMS-om

Postoje konceptualne, unutarnje i vanjske razine prikaza ovih baza podataka koje odgovaraju modelima slične namjene.

Konceptualna razina odgovara logičkom aspektu prezentiranja podataka domene na integrirani način. Konceptualni model sastoji se od mnogih instanci različitih tipova podataka, strukturiranih u skladu sa zahtjevima DBMS-a za logičku strukturu baze podataka.

Unutarnji sloj predstavlja potrebnu organizaciju podataka u okruženju za pohranu i odgovara fizičkom aspektu prikaza podataka. Interni model sastoji se od pojedinačnih instanci zapisa fizički pohranjenih na vanjskom mediju.

Vanjski sloj podržava potrebne prikaze privatnih podataka specifičnim korisnicima. Vanjski model je podskup konceptualnog modela. Moguće raskrižje vanjski modeli prema. Privatna logička struktura podataka za određenu aplikaciju (zadatak) ili korisnika odgovara vanjskom modelu ili podshemi baze podataka. Uz pomoć vanjskih modela podržan je autorizirani pristup podacima baze podataka aplikacije (ograničava se sastav i struktura podataka konceptualnog modela baze podataka dostupnih u aplikaciji, kao i postavljaju se dopušteni načini obrade tih podataka: unos, uređivanje, brisanje, pretraživanje).

Dizajn baze podataka sastoji se od izgradnje kompleksa međusobno povezanih podataka. Slika 2. uvjetno prikazuje faze procesa projektiranja baze podataka.

Dijagram 2 - Faze procesa projektiranja baze podataka

Najvažnija faza dizajna baze podataka je razvoj informacijsko-logičkog (infološkog) modela predmetnog područja, koji nije orijentiran na DBMS. U infološkom modelu sredstva struktura podataka u integriranom obliku odražavaju sastav i strukturu podataka, kao i informacijske potrebe.

Informacijsko-logički (infološki) model predmetnog područja odražava predmetno područje u obliku skupa informacijskih objekata i njihovih strukturnih odnosa.

U odnosu jedan prema više (1:M), jedna instanca informacije A odgovara 0, 1 ili više instanci objekta B, ali svaka instanca objekta B nije povezana s više od jedne instance objekta A.

Primjer odnosa 1:M je odnos između informacijskih objekata Prezime - Plaća:

Prezime Plaća

Baza podataka pohranjuje informacije u obliku dvodimenzionalnih tablica. Također možete uvesti i povezati tablice iz drugih DBMS ili sustava za upravljanje proračunskim tablicama. Istovremeno se mogu otvoriti 1024 stola.

Prilikom definiranja potrebnih tablica baze podataka potrebno je osigurati prve tri normalne forme, tj. provesti normalizaciju.

Isti podaci mogu se grupirati u tablice (relacije) na različite načine, tj. moguće je organizirati različite skupove odnosa međusobno povezanih informacijskih objekata. Grupiranje atributa u odnosima mora biti racionalno, tj. minimiziranje dupliciranja podataka i pojednostavljenje postupaka za njihovu obradu i ažuriranje.

Određeni skup relacija ima bolja svojstva za uključivanje, modificiranje, brisanje podataka od svih drugih mogućih skupova relacija, ako zadovoljava zahtjeve normalizacije relacija.

Normalizacija relacija je formalni aparat ograničenja formiranja relacija (tablica), koji vam omogućuje uklanjanje dupliciranja, osigurava dosljednost onih pohranjenih u bazi podataka i smanjuje troškove rada za održavanje (unos, ispravljanje) baze podataka.

E. Codd je izdvojio tri normalna oblika odnosa i predložio mehanizam koji omogućuje da se bilo koji odnos pretvori u treći (najsavršeniji) normalni oblik.

Prvi normalni oblik. Relacija se naziva normalizirana ili svedena na prvu normalnu formu ako su svi njeni atributi jednostavni (u daljnjem tekstu nedjeljivi). Pretvaranje relacije u prvi normalni oblik može dovesti do povećanja broja atributa (polja) relacije i promjene ključa.

Drugi normalni oblik. Da bismo razmotrili pitanje redukcije odnosa na drugi normalni oblik, potrebno je dati objašnjenja pojmova kao što su funkcionalna ovisnost i potpuna funkcionalna ovisnost.

Opisni atributi informacijskog objekta logički su povezani sa zajedničkim ključem za njih, ovaj odnos je u prirodi funkcionalne ovisnosti atributa.

Funkcionalna ovisnost atributa je ovisnost u kojoj samo jedna vrijednost opisnog atributa odgovara određenoj vrijednosti ključnog atributa u instanci informacijskog objekta.

Takva definicija funkcionalne ovisnosti omogućuje izdvajanje neovisnih informacijskih objekata pri analizi svih odnosa pojedinosti predmetnog područja. Kao primjer, razmotrimo grafički prikaz funkcionalnih ovisnosti atributa radnika, prikazan na slici 5, u kojem je ključni atribut označen zvjezdicom.

Slika 1 - Grafički prikaz funkcionalne ovisnosti detalja

U slučaju kompozitnog ključa uvodi se koncept funkcionalno potpune ovisnosti.

Funkcionalno potpuna ovisnost ne-ključnih atributa je da je svaki ne-ključni atribut funkcionalno ovisan o ključu, ali nije funkcionalno ovisan ni o jednom dijelu složenog ključa.

Relacija će biti u drugom normalnom obliku ako je u prvom normalnom obliku i svaki ne-ključni atribut potpuno funkcionalno ovisi o složenom ključu.

Treći normalni oblik. Koncept treće normalne forme temelji se na konceptu neprelazne ovisnosti.

Prijelazna ovisnost se promatra ako jedan od dva opisna atributa ovisi o ključu, a drugi opisni atribut ovisi o prvom opisnom atributu.

Relacija će biti u trećem normalnom obliku ako je u drugom normalnom obliku i svaki ne-ključni atribut nije tranzitivno ovisan o primarnom ključu.

Kako bi se eliminirala tranzitivna ovisnost opisnih detalja, potrebno je "razdvojiti" izvorni informacijski objekt. Kao rezultat razdvajanja, neki se atributi uklanjaju iz izvornog informacijskog objekta i uključuju u druge (moguće novostvorene) informacijske objekte.

Izrađena baza podataka trebala bi obavljati funkcije u interesu automatizacije izdavanja podataka o organizaciji. Trebao bi imati jednostavno i intuitivno korisničko sučelje, imati minimalne sistemske zahtjeve.

Svrha rada je kreiranje baze podataka koja pruža:

brzi unos novih podataka;

pohranjivanje i dohvaćanje već unesenih podataka;

ispisivanje potrebnog broja osobnih izvješća.

Podaci su:

Puno ime;

Datum rođenja;

Zauzeta pozicija;

službena plaća;

Broj stvarno odrađenih dana u mjesecu.

Uzimajući u obzir gore definirane zadatke, možete dizajnirati glavne tablice baze podataka.

Da bismo to učinili, koristit ćemo alate Database Desktop.

U ovom okruženju izradit ćemo sve potrebne tablice za bazu podataka koja se razvija. Atributi u ovoj tablici će biti:

Prezime, Ime, Patronim, Datum prijema, Adresa, Telefon, Smjene, Izostanci s posla, Stopa, plaća.

Trendovi razvoja suvremenih informacijskih tehnologija dovode do stalnog povećanja složenosti informacijskih sustava (IS) nastalih u različitim područjima gospodarstva. Moderne velike IP projekte karakteriziraju, u pravilu, sljedeće značajke:

složenost opisa (prilično velik broj funkcija, procesa, podatkovnih elemenata i složenih odnosa među njima), koji zahtijeva pažljivo modeliranje i analizu podataka i procesa;

prisutnost skupa blisko međusobno povezanih komponenti (podsustava) koje imaju vlastite lokalne zadatke i ciljeve funkcioniranja (na primjer, tradicionalne aplikacije povezane s obradom transakcija i rješavanjem rutinskih problema i aplikacije analitičke obrade (podrška odlučivanju) koristeći ad hoc upite za velike količine podataka);

odsutnost izravnih analoga, što ograničava mogućnost korištenja bilo kojih standardnih dizajnerskih rješenja i primijenjenih sustava;

potreba za integracijom postojećih i novorazvijenih aplikacija;

funkcioniranje u heterogenom okruženju na nekoliko hardverskih platformi;

razjedinjenost i heterogenost pojedinih skupina programera u pogledu razine vještina i ustaljenih tradicija korištenja određenih alata;

značajan vremenski raspon projekta, zbog, s jedne strane, ograničenih mogućnosti razvojnog tima, as druge strane, razmjera organizacije korisnika i različitog stupnja spremnosti njegovih pojedinih odjela za implementaciju IS-a.

Za uspješnu provedbu projekta potrebno je prije svega adekvatno opisati projektirani objekt (IS), izgraditi cjelovite i konzistentne funkcionalne i informacijske modele IS-a. Dosadašnje iskustvo u projektiranju IS-a pokazuje da se radi o logički složenom, mukotrpnom i dugotrajnom poslu koji zahtjeva visokokvalificirane stručnjake. No sve do nedavno projektiranje IS-a odvijalo se uglavnom na intuitivnoj razini neformaliziranim metodama temeljenim na umjetnosti, praktičnom iskustvu, stručnim procjenama i skupim eksperimentalnim provjerama kvalitete funkcioniranja IS-a. Osim toga, u procesu kreiranja i rada IS-a, informacijske potrebe korisnika mogu se promijeniti ili doraditi, što dodatno otežava razvoj i održavanje takvih sustava.

U 70-im i 80-im godinama prošlog stoljeća pri razvoju IS-a naširoko se koristila strukturna metodologija koja programerima daje striktno formalizirane metode za opisivanje IS-a i donesenih tehničkih odluka. Temelji se na vizualnoj grafičkoj tehnici: dijagrami i dijagrami koriste se za opisivanje različitih vrsta modela IS. Vidljivost 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, široka primjena ove metodologije i pridržavanje njezinih preporuka u razvoju specifičnih IS-a bila je prilično rijetka, budući da je to kod neautomatiziranog (ručnog) razvoja praktički nemoguće. Doista, vrlo je teško ručno razviti i grafički prikazati stroge formalne specifikacije sustava, provjeriti njihovu cjelovitost i dosljednost, a još više ih promijeniti. Ako je ipak moguće stvoriti strogi sustav projektnih dokumenata, onda je njegova obrada kada se pojave ozbiljne promjene praktički nemoguća. Ručno razvijanje obično dovodi do sljedećih problema:

neadekvatna specifikacija zahtjeva;

neuspjeh otkrivanja grešaka u dizajnerske odluke;

loša kvaliteta dokumentacije koja smanjuje učinkovitost;

dugi ciklus i nezadovoljavajući rezultati ispitivanja.

S druge strane, IC programeri su povijesno uvijek zadnji koristili Računalne tehnologije poboljšati kvalitetu, pouzdanost i produktivnost u vlastitom radu (fenomen "postolar bez cipela").

Navedeni čimbenici doprinijeli su nastanku programsko-tehnoloških alata posebne klase - CASE-alata koji implementiraju CASE-tehnologiju za izradu i održavanje IS-a. Pojam CASE (Computer Aided Software Engineering) trenutno se koristi u vrlo širokom smislu. Izvorno značenje pojma CASE, ograničeno na pitanja automatizacije razvoja samo softvera (softvera), sada je dobilo novo značenje, pokrivajući proces razvoja složenih IS-a u cjelini. Sada se pojam CASE-alati odnosi na softverske alate koji podržavaju procese stvaranja i održavanja IS-a, uključujući analizu i formuliranje zahtjeva, dizajn aplikacijskog softvera (aplikacija) i baza podataka, generiranje koda, testiranje, dokumentiranje, osiguranje kvalitete, upravljanje konfiguracijom i upravljanje projektima, ali i drugim procesima. CASE alati zajedno sa sistemskim softverom i hardverom čine cjelovito razvojno okruženje IS-a.

Pojavi CASE tehnologije i CASE alata prethodila su istraživanja na području metodologije programiranja. Programiranje je poprimilo oblik sistemski pristup s razvojem i implementacijom jezika visoke razine, metoda strukturiranog i modularnog programiranja, dizajnerskih jezika i alata za njihovu podršku, formalnih i neformalnih jezika za opisivanje zahtjeva i specifikacija sustava itd. Osim toga, sljedeći čimbenici pridonijeli su pojavi CASE tehnologije:

osposobljavanje analitičara i programera prijemčivih za koncepte modularnog i strukturiranog programiranja;

široko uvođenje i stalni rast performansi računala, što je omogućilo učinkovito korištenje grafička pomagala i automatizirati većinu faza projektiranja;

implementacija mrežna tehnologija, što je omogućilo kombiniranje napora pojedinačnih izvođača u jedinstven proces projektiranja korištenjem zajedničke baze podataka koja sadrži potrebne informacije o projektu.

CASE-tehnologija je metodologija projektiranja IS-a, kao i skup alata koji omogućuju u vizualnom obliku.

CASE alati. Opće karakteristike i klasifikacija

Moderni CASE alati pokrivaju širok raspon podrške za brojne tehnologije projektiranja IS-a: od jednostavnih alata za analizu i dokumentiranje do alata za automatizaciju u punom opsegu koji pokrivaju cijeli životni ciklus softvera.

Najdugotrajnije faze razvoja IS-a su faze analize i projektiranja tijekom kojih CASE-alati osiguravaju kvalitetu tehničkih rješenja i pripreme projektna dokumentacija. Pritom važnu ulogu igraju metode vizualne prezentacije informacija. To uključuje izradu strukturnih ili drugih dijagrama u stvarnom vremenu, korištenje raznolike palete boja i provjeru sintaktičkih pravila od početka do kraja. Grafički alati za modeliranje domene omogućuju programerima vizualno proučavanje postojećeg IS-a, njegovu rekonstrukciju u skladu s ciljevima i postojećim ograničenjima.

Kategorija CASE alata uključuje kako relativno jeftine sustave za osobna računala vrlo ograničenih mogućnosti, tako i skupe sustave za heterogene računalne platforme i operativna okruženja. Dakle, moderno tržište softvera ima oko 300 razni CASE alati, od kojih najmoćnije koriste na ovaj ili onaj način gotovo sve vodeće zapadne tvrtke.

Obično CASE alati uključuju bilo koji softverski alat, koji automatizira jedan ili drugi skup procesa životnog ciklusa softvera i ima sljedeće glavne karakteristične značajke:

moćni grafički alati za opisivanje i dokumentiranje IP-a, pružajući prikladno sučelje s programerom i razvijajući njegove kreativne sposobnosti;

integracija pojedinačnih komponenti CASE-alata, osiguravajući upravljivost procesa razvoja IS-a;

korištenje posebno organiziranog repozitorija projektnih metapodataka (repozitorij).

Integrirani CASE alat (ili skup alata koji podržavaju puni životni ciklus softvera) sadrži sljedeće komponente;

repozitorij koji je osnova CASE alata. Mora osigurati pohranjivanje verzija projekta i njegovih pojedinačnih komponenti, sinkronizaciju primanja informacija od različitih programera tijekom grupnog razvoja, kontrolu metapodataka za cjelovitost i dosljednost;

alati za grafičku analizu i dizajn koji omogućuju izradu i uređivanje hijerarhijski povezanih dijagrama (DFD, ERD, itd.) koji tvore IS modele;

alati za razvoj aplikacija, uključujući 4GL jezike i generatore koda;

alati za upravljanje konfiguracijom;

sredstva dokumentacije;

alati za testiranje;

alati za upravljanje projektima;

alati za reinženjering.

Svi moderni CASE alati mogu se klasificirati uglavnom prema vrstama i kategorijama. Klasifikacija prema vrsti odražava funkcionalnu orijentaciju CASE-alata za određene procese životnog ciklusa. Klasifikacija kategorija određuje stupanj integracije prema funkcijama koje obavlja i uključuje pojedinca lokalna sredstva, rješavanje malih autonomnih zadataka (alati), skup djelomično integriranih alata koji pokrivaju većinu faza životnog ciklusa IP-a (alati) i potpuno integrirani alati koji podržavaju cijeli životni ciklus IP-a i povezani su zajedničkim repozitorijem. Osim toga, CASE alati mogu se klasificirati prema sljedećim kriterijima:

primijenjene metodologije i modeli sustava i baza podataka;

stupanj integracije sa DBMS-om;

dostupne platforme.

Klasifikacija po vrstama u osnovi se podudara s sastavom komponenti CASE-alata i uključuje sljedeće glavne vrste:

alati za analizu (Upper CASE) dizajnirani za izgradnju i analizu modela domene (Design/IDEF (Meta Software), BPwin (Logic Works));

alati za analizu i dizajn (Middle CASE) koji podržavaju najčešće metodologije dizajna i koriste se za izradu specifikacija dizajna (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Analitičar (MacroProject)). Izlaz takvih alata su specifikacije komponenti sustava i sučelja, arhitekture sustava, algoritama i struktura podataka;

alati za dizajn baze podataka koji omogućuju modeliranje podataka i generiranje sheme baze podataka (obično na SQL jezik) za najčešći DBMS. DO oni uključuju ERwin (Logic Works), S-Designer (SDP) i Dizajner baze podataka (ORACLE). Alati za dizajn baze podataka također su uključeni u alate Vantage Team Builder, Designer/2000, Silverrun i PRO-IV CASE;

alati za razvoj aplikacija. To uključuje 4GL alate (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) itd.) i generatore kodova uključeno u Vantage Team Builder, PRO-IV i djelomično u Silverrun;

alati za reinženjering koji omogućuju analizu programskih kodova i shema baza podataka te formiranje na njihovoj osnovi razni modeli i specifikacije dizajna. Analiza sheme baze podataka i alati za generiranje ERD-a uključeni su u Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin i S-Designor. U području analize programskog koda najviše se koriste objektno orijentirani CASE-alati koji omogućuju reinženjering C++ programa (Rational Rose (Rational Software), Object Team (Cayenne)).

Vrste pomoćnika uključuju:

alati za planiranje i upravljanje projektima (SE Companion, Microsoftov projekt i tako dalje.);

alati za upravljanje konfiguracijom (PVCS (Intersolv));

alati za testiranje (Kvaliteta radi (Segue softver));

alati za dokumentiranje (SoDA (Rational Software)).

Do danas rusko tržište softvera ima sljedeće najrazvijenije CASE alate:

Vantage Team Builder (Westmount I-CASE);

Projektant/2000.;

Srebrna vožnja;

ERwin+BPwin;

S Dizajner;

SLUČAJ.Analitičar.

Osim toga, na tržištu se stalno pojavljuju kako novi sustavi za domaće korisnike (primjerice, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), tako i nove verzije i modifikacije ovih sustava.

1. Osnove metodologije projektiranja IS-a

1.1. Životni ciklus IP softvera

Jedan od osnovnih pojmova metodologije projektiranja IS-a je koncept životnog ciklusa njegovog softvera (LC softver). Životni ciklus softvera je kontinuirani proces koji počinje od trenutka donošenja odluke o potrebi njegove izrade, a završava u trenutku njegovog potpunog povlačenja iz rada.

Glavni regulatorni dokument koji regulira životni ciklus softvera je međunarodna norma ISO/IEC 12207 (ISO - Međunarodna organizacija za standardizaciju - Međunarodna organizacija za standardizaciju, IEC - Međunarodna elektrotehnička komisija - Međunarodna elektrotehnička komisija). Definira strukturu životnog ciklusa koja sadrži procese, aktivnosti i zadatke koji se moraju izvršiti tijekom razvoja softvera.

Struktura životnog ciklusa softvera prema normi ISO/IEC 12207 temelji se na tri skupine procesa:

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

pomoćni procesi koji osiguravaju provedbu glavnih procesa (dokumentacija, upravljanje konfiguracijom, osiguranje kvalitete, verifikacija, certifikacija, procjena, audit, rješavanje problema);

organizacijski procesi (upravljanje projektima, stvaranje projektne infrastrukture, definiranje, evaluacija i poboljšanje samog životnog ciklusa, obuka).

Razvoj obuhvaća sve radove na izradi programske opreme i njezinih komponenti u skladu sa zadanim zahtjevima, uključujući izradu projektne i pogonske dokumentacije, pripremu materijala potrebnih za ispitivanje operativnosti i odgovarajuće kvalitete programskih proizvoda, materijale potrebne za organiziranje osoblja obuka, 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, osiguranje operativne dokumentacije, provođenje obuke osoblja itd., te neposredno djelovanje, uključujući lokalizaciju problema i otklanjanje uzroka njihove pojave, izmjene softvera unutar utvrđene propise, pripremu prijedloga za unapređenje, razvoj i modernizaciju sustava.

Upravljanje projektima odnosi se na pitanja planiranja i organizacije rada, stvaranje timova programera te praćenje vremena i kvalitete obavljenog posla. Tehnička i organizacijska podrška projektu uključuje izbor metoda i alata za provedbu projekta, definiranje metoda za opisivanje međurazvojnih stanja, razvoj metoda i alata za testiranje softvera, obuku osoblja itd. Osiguranje kvalitete projekta vezano je uz probleme verifikacije softvera, provjere i testiranja. Verifikacija je proces utvrđivanja ispunjava li trenutačno stanje razvoja postignuto u određenoj fazi zahtjeve te faze. Validacija 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 ispunjavaju li značajke softvera izvorne zahtjeve. U procesu realizacije 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 složenih projekata IS-a koji se sastoje od mnogih komponenti, od kojih svaka može imati varijante ili inačice, javlja se problem uzimanja u obzir njihovih odnosa i funkcija, stvaranja jedinstvene strukture i osiguravanja razvoja cjelokupnog sustava. Upravljanje konfiguracijom omogućuje organiziranje, sustavno uzimanje u obzir i kontrolu promjena softvera u svim fazama životnog ciklusa. Opća načela i preporuke za računovodstvo konfiguracije, planiranje i upravljanje konfiguracijama softvera odražavaju se u nacrtu norme ISO 12207-2.

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

2. Strukturni pristup projektiranju IS-a CASE znači

2.1. Bit strukturalnog pristupa

Bit strukturalnog pristupa razvoju IS-a leži u njegovoj dekompoziciji (particioniranju) na automatizirane funkcije: sustav se dijeli na funkcionalne podsustave, koji se pak dijele na podfunkcije, dalje dijele na zadatke i tako dalje. Proces particioniranja nastavlja se do specifičnih postupaka. Istovremeno, automatizirani sustav zadržava holistički pogled u kojem su sve komponente međusobno povezane. Kod razvoja sustava "odozdo prema gore" od pojedinačnih zadataka do cijelog sustava gubi se cjelovitost, nastaju problemi u informacijskom spajanju pojedinih komponenti.

Sve najčešće metodologije strukturalnog pristupa temelje se na nizu generalni principi. Kao dvoje Osnovni principi koriste se sljedeće:

načelo „podijeli pa vladaj“ – načelo rješavanja složenih problema razbijanjem na mnogo manjih neovisnih zadataka koje je lako razumjeti i riješiti;

princip hijerarhijskog uređenja - princip organiziranja sastavnih dijelova problema u hijerarhijske strukture stabla uz dodavanje novih detalja na svakoj razini.

Odabir dva temeljna načela ne znači da su ostala načela sekundarna, jer ignoriranje bilo kojeg od njih može dovesti do nepredvidivih posljedica (uključujući i neuspjeh cijelog projekta). Glavni od ovih principa su sljedeći:

načelo apstrakcije – je isticanje bitnih aspekata sustava i apstrakcija od nebitnih;

načelo formalizacije - leži u potrebi za strogim metodološkim pristupom rješavanju problema;

načelo dosljednosti – leži u valjanosti i dosljednosti elemenata;

princip strukturiranja podataka - je da podaci trebaju biti strukturirani i hijerarhijski organizirani.

U strukturnoj analizi uglavnom se koriste dvije skupine alata koji ilustriraju funkcije koje obavlja sustav i odnose između podataka. Svaka grupa sredstava odgovara određene vrste modeli (dijagrami), od kojih su najčešći sljedeći:

SADT (Structured Analysis and Design Technique) modeli i povezani funkcionalni dijagrami (pododjeljak 2.2);

DFD (Data Flow Diagrams) dijagrami toka podataka (pododjeljak 2.3);

ERD (Entity-Relationship Diagrams) dijagrami "entitet-odnos" (pododjeljak 2.4).

U fazi projektiranja IS-a, modeli se proširuju, dorađuju i dopunjuju dijagramima koji odražavaju strukturu softvera: arhitektura softvera, blok dijagrami programa i dijagrami ekranskih formi.

Navedeni modeli zajedno daju cjelovit opis IS-a, bez obzira radi li se o postojećem ili novorazvijenom. Sastav dijagrama u svakom pojedinom slučaju ovisi o potrebnoj cjelovitosti opisa sustava.

2.2. Metodologija funkcionalnog modeliranja SADT ( IDEF 0)

SADT metodologiju razvio je Douglas Ross. Na temelju njega je, naime, razvijena poznata metodologija IDEF0 (Icam DEFinition), koja je glavni dio programa ICAM (Integration of Computer and Industrial Technologies) koji je pokrenulo američko ratno zrakoplovstvo.

SADT metodologija je skup metoda, pravila i postupaka dizajniranih za izgradnju funkcionalnog modela objekta bilo kojeg predmetnog područja. SADT funkcionalni model odražava funkcionalnu strukturu objekta, tj. radnje koje izvodi i veze između tih radnji. Glavni elementi ove metodologije temelje se na sljedećim konceptima:

grafički prikaz blokovskog modeliranja. Blok i lučna grafika SADT dijagrama prikazuju funkciju kao blok, a ulazno/izlazna sučelja predstavljena su lukovima koji ulaze i izlaze iz bloka. Međusobna interakcija blokova je opisana pomoću lukova sučelja koji izražavaju "ograničenja", koja zauzvrat određuju kada i kako se funkcije izvode i kontroliraju;

strogost i preciznost. Provedba SADT pravila zahtijeva dostatnu strogost i preciznost bez nametanja neopravdanih ograničenja na radnje analitičara. SADT pravila uključuju:

ograničavanje broja blokova na svakoj razini dekompozicije (pravilo 3-6 blokova);

povezanost dijagrama (brojevi blokova);

jedinstvenost oznaka i imena (nema duplih imena);

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

odvajanje ulaza i kontrola (pravilo za određivanje uloge podataka).

odvajanje organizacije od funkcije, tj. isključivanje utjecaja organizacijske strukture na funkcionalni model.

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

2.2.1. Sastav funkcionalnog modela

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 funkcije i sučelja IS-a prikazani su kao blokovi i lukovi. Točka spajanja luka s blokom određuje vrstu sučelja. Kontrolne informacije ulaze u blok s gornje strane, dok se s lijeve strane bloka prikazuju informacije koje se obrađuju, a s desne strane izlazni rezultati. mehanizam (osoba ili automatizirani sustav), koji izvodi operaciju, predstavljen je lukom koji ulazi u blok odozdo (slika 2.1).

Jedna od najvažnijih značajki SADT metodologije je postupno uvođenje sve većih razina detalja kako se stvaraju dijagrami koji predstavljaju model.

Riža. 2.1. Funkcijski blok i lukovi sučelja

Slika 2.2, koja prikazuje četiri dijagrama i njihove odnose, prikazuje strukturu SADT modela. Svaka komponenta modela može se rastaviti na drugačiji dijagram. Svaki dijagram ilustrira "unutarnju strukturu" bloka u roditeljskom dijagramu.

2.2.2. Hijerarhija grafikona

Izgradnja SADT modela započinje prikazom cijelog sustava u obliku najjednostavnije 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 generički. Ovo također vrijedi za lukove sučelja - oni također predstavljaju kompletan skup vanjskih sučelja sustava kao cjeline.

Zatim je blok koji predstavlja sustav kao jedan modul detaljiziran u drugom dijagramu pomoću 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 rastaviti 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 izvornu funkciju. Također, model ne može izostaviti nijedan element, tj., kao što je navedeno, nadređeni blok i njegova sučelja daju kontekst. Ništa mu se ne može dodati, niti mu se ništa ukloniti.

SADT model je niz dijagrama s pratećom dokumentacijom koji se raščlanjuju složeni objekt na sastavne dijelove, koji su predstavljeni u obliku blokova. Pojedinosti o svakom od glavnih blokova prikazane su kao blokovi u drugim dijagramima. Svaki detaljni dijagram je dekompozicija bloka iz općenitijeg dijagrama. U svakom koraku dekompozicije, općenitiji dijagram naziva se roditelj detaljnijeg dijagrama.

Lukovi koji ulaze i izlaze iz bloka u dijagramu vrhunska razina, potpuno su isti kao i lukovi uključeni u dijagram niži nivo i izlaz iz njega, jer blok i dijagram predstavljaju isti dio sustava.

Riža. 2.2. Struktura SADT modela. Dekompozicija dijagrama

Slike 2.3 - 2.5 prikazuju različite opcije za izvođenje funkcija i povezivanje lukova s ​​blokovima.

Riža. 2.3. Simultano izvršenje

Riža. 2.4. Sukladnost mora biti potpuna i dosljedna

Neki su lukovi pričvršćeni na okvire dijagrama na oba kraja, dok je drugima jedan kraj ostao nepričvršćen. Nepovezani lukovi odgovaraju ulazima, kontrolama i izlazima nadređenog bloka. Izvor ili odredište ovih graničnih lukova može se pronaći samo u nadređenom dijagramu. Nespojeni krajevi moraju odgovarati lukovima u izvornom dijagramu. Svi granični lukovi moraju se nastaviti na matičnom dijagramu kako bi on bio potpun i dosljedan.

SADT dijagrami ne pokazuju eksplicitno niti redoslijed niti vrijeme. Povratne informacije, iteracije, tekući procesi i preklapajuće (u vremenu) funkcije mogu se prikazati pomoću lukova. Povratne informacije mogu biti u obliku komentara, primjedbi, ispravaka i sl. (Slika 2.5).

Riža. 2.5. Primjer povratne informacije

Kao što je navedeno, mehanizmi (lukovi na donjoj strani) pokazuju način na koji se izvršavaju funkcije. Mehanizam može biti čovjek, računalo ili bilo koji drugi uređaj koji pomaže u ovoj funkciji (slika 2.6).

Riža. 2.6. Primjer mehanizma

Svaki blok u dijagramu ima svoj broj. Blok bilo kojeg dijagrama može se dalje opisati dijagramom niže razine, koji se zauzvrat može dodatno detaljizirati potrebnim brojem dijagrama. Tako se formira hijerarhija dijagrama.

Za označavanje položaja bilo kojeg dijagrama ili bloka u hijerarhiji koriste se brojevi dijagrama. Na primjer, A21 je dijagram koji prikazuje okvir 1 u dijagramu A2. Slično, A2 prikazuje okvir 2 na dijagramu A0, koji je najviši dijagram modela. Slika 2.7 prikazuje tipično stablo dijagrama.

Riža. 2.7. Hijerarhija grafikona

2.2.3. Vrste veza između funkcija

Jedna od važnih točaka u dizajnu IS-a korištenjem SADT metodologije je točna dosljednost tipova odnosa između funkcija. Odlikuje se po barem sedam vrsta vezanja:

Vrsta komunikacije	Relativna važnost
Slučajno
logično
Privremeni
proceduralni
Komunikacija
dosljedan
funkcionalni

Svaka vrsta veze ukratko je definirana u nastavku i ilustrirana pomoću tipičnog primjera iz SADT-a.

(0) Vrsta slučajne veze: najmanje poželjno.

Nasumična povezanost događa se kada postoji mali ili nikakav specifičan odnos između značajki. Ovo se odnosi na situaciju u kojoj imena podataka na SADT lukovima u istom dijagramu imaju malo međusobnog odnosa. Ekstremna verzija ovog slučaja prikazana je na slici 2.8.

Riža. 2.8. Slučajna veza

(1) Vrsta logičke veze.Logičko povezivanje se događa kada se podaci i funkcije spoje jer spadaju u zajedničku klasu ili skup elemenata, ali nisu pronađeni potrebni funkcionalni odnosi među njima.

(2) Vrsta vremenske povezanosti.Elementi povezani s vremenom nastaju jer predstavljaju funkcije povezane s vremenom kada se podaci koriste istovremeno ili su funkcije omogućene paralelno, a ne sekvencijalno.

(3) Vrsta proceduralne povezanosti.Proceduralno povezane stavke pojavljuju se grupirane zajedno zbog činjenice da se izvršavaju tijekom istog dijela petlje ili procesa. Primjer proceduralno povezanog dijagrama prikazan je na slici 2.9.

Riža. 2.9. proceduralnu povezanost

(4) Vrsta komunikacijske povezanosti.Dijagrami prikazuju komunikacijske veze kada su blokovi grupirani jer koriste isti ulaz i/ili proizvode isti izlaz (slika 2.10).

(5) Vrsta serijske veze.U dijagramima koji imaju serijske veze, izlaz jedne funkcije je ulaz u sljedeću funkciju. Povezanost između elemenata u dijagramu tješnja je nego na razinama poveznica o kojima smo govorili, budući da se modeliraju uzročno-posljedične veze (slika 2.11).

(6) Vrsta funkcionalne povezanosti.Dijagram odražava potpunu funkcionalnu povezanost, uz prisutnost potpune ovisnosti jedne funkcije o drugoj. Dijagram koji je čisto funkcionalan ne sadrži strane elemente sekvencijalnog ili slabijeg tipa povezanosti. Jedan od načina za definiranje funkcionalno povezanih dijagrama je razmatranje dvaju blokova povezanih preko kontrolnih lukova, kao što je prikazano na slici 2.12.

Riža. 2.10. Komunikacijska povezanost

Riža. 2.11. serijsko povezivanje

sl.13. Funkcionalni dijagram za kreiranje i modificiranje dizajna proizvoda (druga razina)

Za čitljivost, preporuča se ograničiti broj blokova u dijagramu na tri do šest. Gornja granica tjera na pribjegavanje dekompoziciji, donja osigurava da dijagram ima dovoljno detalja koji opravdavaju njegovu izradu. Poželjno je da broj lukova sučelja koji se približavaju bočnoj strani bloka ili izlaze iz njega ne prelazi 4.

Metoda IDEF 0 pretpostavlja grupni radnad projektom ili projektima. Skupina različitih stručnjaka intervjuira kompetentne osobe i gradi grubi model. Stručnjaci poduzeća raspravljaju o ovom modelu, pismeno ga kritiziraju i prenose razvojnom timu. Ovaj se ciklus nastavlja sve dok se programeri i recenzenti ne dogovore. Zatim se model formalno odobrava i koristi (na primjer, za restrukturiranje funkcija sustava).

Jedna od prednosti metode IDEF 0 je da apstrahiraorganizacijska struktura objektai analizira njegove funkcije. To omogućuje, nakon izgradnje modela, pogled na organizacijsku strukturu koja provodi ove funkcije sa stajališta njezine savršenosti, kako bi se identificirali slične značajke odnosno njihovo dupliciranje te dati prijedloge za reorganizaciju sustava.

Ako koristimo termin "poslovni proces", onda možemo reći da metoda IDEF 0 vam omogućuje identifikacijuposlovne procese, sagledati funkcioniranje poduzeća "kakvo jest" i na temelju svoje analize dati prijedloge "kako bi trebalo biti", odnosno baciti novi pogled na rad poduzeća, razjasniti odgovornosti zaposlenika, ocijeniti učinkovitost korištenja resursa, vidjeti nedostatke vješto skrivene u uobičajenoj organizacijskoj strukturi. Stoga se identificiranje, analiziranje i mijenjanje poslovnih procesa može koristiti za poboljšanje učinkovitosti poduzeća.

Od uvođenja pojma "poslovni proces" pojavilo se nekoliko tehnika za poboljšanje poslovnih procesa. Najpopularniji od njih je reinženjering poslovnih procesa poduzeća, koji podrazumijeva temeljito promišljanje i redizajn poslovnih procesa poduzeća. Identifikacija, analiza i redizajn ovih procesa sadržaj je predložene metodologije. Opća shema metodologija za analizu i reinženjering poslovnih procesa poduzeća je sljedeća (vidi sliku 12):

Prikupljanje informacija o poduzeću;

• identifikacija poslovnih procesa poduzeća i izrada funkcionalnog modela poslovnih procesa poduzeća;
• analiza i mogući reinženjering poslovnih procesa poduzeća.

Za analizu podjela troškovaprimjenjuje se ABC metoda temeljena na IDEF0. ABC metoda temelji se na činjenici da obavljanje svake funkcije tijekom poslovanja poduzeća ima određeni trošak, odnosno doprinosi pojavi troškova. AVS je sličan konceptu FSA - funkcionalne analize troškova. ABC metodom izračunavaju se troškovi izvođenja cjelokupnog procesa ili pojedine funkcije, troškovi proizvoda na izlazu iz procesa, te identificiraju izvori glavnih troškova. Trošak izvršenja rastavljive funkcije definiran je kao zbroj troškova izvršenja svih sastavni elementi u ovoj funkciji.

Primjena ABC metode omogućuje vam da dobijete kvantitativne procjene procesa potrebne za procjenu nekoliko opcija. Za razliku od tradicionalnog računovodstva, koje uzima u obzir uglavnom izravne troškove (računovodstvo neizravnih troškova je teško, ali u nekim slučajevima neophodno), ABC metoda omogućuje vam da uzmete u obzir različite čimbenike koji utječu na formiranje troškova poduzeća.

Za izgradnju funkcionalnog modela predlaže se odabir CASE-Design/IDEF paket , budući da osim mogućnosti izrade funkcionalnog modela, ovaj paket sadrži ugrađeni ABC mehanizam za izračun troškova obavljanja funkcija, koji omogućuje analizu poslovnih procesa i njihovih komponenti. Svaka vrsta resursa koju funkcija troši (obrađuje), kao i mehanizmi koji obavljaju funkciju, dodaju trošak ovoj funkciji, uzimajući u obzir elemente troškova koji se zanemaruju u uobičajenom predstavljanju poduzeća kao skupa organizacijskih struktura. . Stoga se svakoj funkciji h IDEF0 modela može pridružiti vrijednost troška izvršenja te funkcije Ex(h).

sl.14. Opća shema metodologije za analizu i reinženjering poslovnih procesa poduzeća

Kombinacija metoda IDEF0 i ABC (slika 14) omogućuje rješavanje jednog od najvažnijih zadataka - analizu savršenstva funkcija sustava, mogućnosti za njegovo poboljšanje, što nije svojstveno drugim metodama i standardima kao što su opseg.Povezivanje ABC metode omogućuje vam usporedbu postojeće strukture (kakva jest) s racionalnom strukturom (kakva bi trebala biti), budući da iste funkcije mogu implementirati različite strukture (na primjer, možete kombinirati odjele koji obavljaju slične funkcije s beznačajna razlika ili malo opterećenje).

Primjer konstruiranja ffunkcionalni model procesa izrade CAD-a prikazan je na slikama 15…18.

sl.15. Funkcionalni model procesa izrade CAD-a (početak).
IDEF 0-dijagram prve razine.

sl.16. IDEF 0-chart anketno poduzeće.

Sl.17. IDEF CAD dizajn 0-dijagrama.

Sl.18. IDEF 0-dijagram implementacije CAD projekta.

2.3. Modeliranje tokova podataka (procesi - modeli DFD, IDEF standard 1)

Ova metodologija (Gane/Sarson metodologija) temelji se na konstrukciji modela analiziranog IS-a - dizajniranog ili stvarno postojećeg. U skladu s metodologijom, model sustava definiran je kao hijerarhija dijagrama toka podataka (DFD ili DFD) koji opisuju asinkroni proces transformacije informacije od njenog unosa u sustav do izdavanja korisniku. Dijagrami gornjih razina hijerarhije (kontekstni dijagrami) definiraju glavne procese ili podsustave IS-a s vanjskim ulazima i izlazima. Detaljni su pomoću dijagrama niže razine. Ta se dekompozicija nastavlja, stvarajući višerazinsku hijerarhiju dijagrama, sve dok se ne dosegne razina dekompozicije na kojoj procesi postaju elementarni i nemoguće ih je dalje detaljizirati.

IDEF1 - metoda simulacijeprotok informacija unutar sustava,omogućavajući prikaz strukture sustava, odnosno njegovih elemenata (entiteta), njihovih svojstava (atributa) i odnosa (odnosa) među njima. Detaljne informacije dobivene tijekom procesa modeliranja omogućuju prepoznavanje "uskih grla" u analiziranom objektu i temelj su za donošenje odluka o poboljšanju strukture sustava i protoka informacija, te implementaciji ispravne politike upravljanja informacijama.

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 u druge procese ili podsustave, pohranu podataka ili vanjske entitete – potrošače informacija. Dakle, glavne komponente dijagrama protoka podataka su:

vanjski entiteti;

sustavi/podsustavi;

procesi;

uređaji za pohranu podataka;

tokovi podataka.

2.3.1. Vanjski entiteti

Vanjski entitet je materijalni objekt ili pojedinac A koji predstavlja izvor ili odredište informacija, kao što su kupci, osoblje, dobavljači, kupci, skladište. Definicija nekog objekta ili sustava kao vanjske cjeline ukazuje na to da se on nalazi izvan granica analiziranog IS-a. Tijekom analize, po potrebi se neki vanjski entiteti mogu premjestiti unutar dijagrama analiziranog IS-a ili, obrnuto, dio procesa IS-a može se premjestiti izvan dijagrama i prikazati kao vanjski entitet.

Vanjski entitet označen je kvadratom (slika 2.13), koji se nalazi, takoreći, "iznad" dijagrama i baca sjenu na njega kako bi se ovaj simbol razlikovao od drugih oznaka:

Riža. 2.13. vanjski entitet

2.3.2. Sustavi i podsustavi

Prilikom izgradnje složenog modela IS-a, on se u najopćenitijem obliku može prikazati na tzv. kontekstnom dijagramu kao jedan sustav kao cjelina ili se može rastaviti na više podsustava.

Podsustav (ili sustav) na kontekstualnom dijagramu prikazan je na sljedeći način (Slika 2.14).

Riža. 2.14. Podsustav

Broj podsustava služi za njegovu identifikaciju. U polje za naziv upisuje se naziv podsustava u obliku rečenice sa subjektom i pripadajućim definicijama i dopunama.

2.3.3. Procesi

Proces je transformacija ulaznih tokova podataka u izlazne prema određenom algoritmu. Fizički, proces se može implementirati na različite načine: to može biti pododsjek organizacije (odjel) koji obrađuje ulazne dokumente i izdaje izvješća, program, hardverski implementiran logički uređaj itd.

Proces u dijagramu toka podataka prikazan je na slici 2.15.

Riža. 2.15. Postupak

Za identifikaciju se koristi broj procesa. U polje za naziv unosi se naziv procesa kao rečenica s aktivnim jednoznačnim glagolom u neodređenom obliku (izračunati, izračunati, provjeriti, utvrditi, stvoriti, primiti), iza kojeg slijede imenice u akuzativu, npr.:

"Unesite podatke o kupcu";

"Dajte podatke o tekućim troškovima";

"Provjerite kreditnu sposobnost klijenta."

Upotreba glagola kao što su "obraditi", "modernizirati" ili "urediti" obično ukazuje na nerazumijevanje procesa i zahtijeva daljnju analizu.

Informacije u polju fizičke implementacije pokazuju koji dio organizacije, program ili hardverski uređaj proces izvodi.

2.3.4. Podatkovni pogoni

Uređaj za pohranu podataka je apstraktni uređaj za pohranjivanje informacija koji se u bilo kojem trenutku može staviti u pogon i ukloniti nakon nekog vremena, a metode umetanja i izvlačenja mogu biti bilo koje.

Uređaj za pohranu podataka može se fizički implementirati u obliku mikrofiša, ladice u ormaru za dokumente, stola u RAM memorija, datoteka u magnetski mediji itd. Akumulator podataka na dijagramu toka podataka prikazan je na slici 2.16.

Riža. 2.16. Pohrana podataka

Uređaj za pohranjivanje podataka označen je slovom "D" i proizvoljnim brojem. Naziv pogona odabran je s gledišta najveće informativnosti za projektanta.

Pohrana podataka općenito je prototip buduće baze podataka i opis podataka koji se u njoj pohranjuju treba povezati s informacijskim modelom.

2.3.5. Tokovi podataka

Tijek podataka definira informaciju koja se prenosi nekom vezom od izvora do primatelja. Stvarni tok podataka može biti informacija koja se prenosi preko kabela između dva uređaja, poslana pisma, magnetske vrpce ili diskete, prenesena s jednog računala na drugo, i tako dalje.

Tijek podataka na dijagramu je prikazan linijom koja završava strelicom koja pokazuje smjer toka (slika 2.17). Svaki tok podataka ima naziv koji odražava njegov sadržaj.

Riža. 2.17. Tok podataka

2.3.6. Izgradnja hijerarhije dijagrama protoka podataka

Prvi korak u izgradnji DPD hijerarhije je izrada kontekstnih dijagrama. Obično se pri projektiranju relativno jednostavnih IS-a gradi jedan kontekstni dijagram sa zvjezdastom topologijom u čijem je središtu tzv. glavni proces, povezan s primateljima i izvorima informacija preko kojih korisnici i drugi vanjski sustavi komuniciraju sa sustavom. .

Ako za složeni sustav ograničen na jedan kontekstni dijagram, sadržavat će previše izvora i izvora informacija koje je teško rasporediti na listu papira normalne veličine, a osim toga, jedini glavni proces ne otkriva strukturu distribuiranog sustava. Znakovi složenosti (u smislu konteksta) mogu biti:

prisutnost velikog broja vanjskih entiteta (deset ili više);

distribuirana priroda sustava;

multifunkcionalnost sustava s već utvrđenim ili identificiranim grupiranjem funkcija u zasebne podsustave.

Za složeni IS gradi se hijerarhija kontekstnih dijagrama. U isto vrijeme, 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 kontekstnih dijagrama određuje interakciju glavnih funkcionalnih podsustava projektiranog IS-a kako međusobno tako i s vanjskim ulaznim i izlaznim tokovima podataka i vanjskim objektima (izvorima i primateljima informacija) s kojima IS komunicira.

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

Nakon konstruiranja kontekstnih dijagrama, rezultirajući model treba provjeriti na cjelovitost početnih podataka o objektima sustava i izoliranost objekata (nedostatak informacijskih veza s drugim objektima).

Za svaki podsustav prisutan na dijagramima konteksta, njegovo se detaljiziranje izvodi pomoću DPD-a. Svaki se proces na DPD-u može detaljno opisati pomoću DPD-a ili mini-specifikacije. Prilikom izrade detalja potrebno je pridržavati se sljedećih pravila:

pravilo balansiranja - znači da prilikom detaljizacije podsustava ili procesa, detaljni dijagram kao vanjski izvori/primatelji podataka mogu imati samo one komponente (podsustave, procese, vanjske entitete, spremišta podataka) s kojima detaljni podsustav ili proces na nadređenom dijagramu ima informacijske veze. poveznice;

pravilo numeriranja - znači da kod detaljiziranja procesa treba podržati njihovo hijerarhijsko numeriranje. Na primjer, procesima koji detaljno opisuju proces broj 12 dodijeljeni su brojevi 12.1, 12.2, 12.3 i tako dalje.

Mini specifikacija (opis logike procesa) trebala bi formulirati svoje glavne funkcije na takav način da ih u budućnosti stručnjak koji provodi projekt može izvršiti ili razviti odgovarajući program.

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

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

mogućnost opisa transformacije podataka procesom u obliku sekvencijalnog algoritma;

izvršavanje procesom jedne logičke funkcije pretvaranja ulazne informacije u izlaz;

mogućnost opisivanja logike procesa pomoću male mini-specifikacije (ne više od 20-30 redaka).

Prilikom konstruiranja DPD hijerarhije treba prijeći na detaljizaciju procesa tek nakon utvrđivanja sadržaja svih tokova i uređaja za pohranjivanje podataka koji se opisuje korištenjem podatkovnih struktura. Strukture podataka sastoje se od elemenata podataka i mogu sadržavati alternative, uvjete i ponavljanja. Uvjetno pojavljivanje znači da ova komponenta možda nije prisutna u strukturi. Alternativno znači da jedan od navedenih elemenata može biti uključen u strukturu. Iteracija znači unos bilo kojeg broja elemenata navedeni raspon. Za svaki element podataka može se odrediti njegov tip (kontinuirani ili diskretni podaci). Za kontinuirane podatke može se navesti mjerna jedinica (kg, cm itd.), raspon vrijednosti, preciznost prikaza i oblik fizičkog kodiranja. Za diskretne podatke može se navesti tablica valjanih vrijednosti.

Nakon izgradnje cjelovitog modela sustava potrebno ga je verificirati (provjeriti cjelovitost i dosljednost). U cjelovitom modelu svi njegovi objekti (podsustavi, procesi, tokovi podataka) moraju biti detaljno opisani i detaljizirani. Identificirane nedetalizirane objekte treba detaljizirati vraćanjem na prethodne korake razvoja. U konzistentnom modelu, svi tokovi podataka i pohrane podataka moraju poštovati pravilo očuvanja informacija: svi podaci koji negdje dolaze moraju se pročitati, a svi pročitani podaci moraju se zapisati.

2.4. Modeliranje podataka

IDEF1X - modeliranje podataka i metoda dizajna relacijske baze podataka. Pripada vrsti metodologija "entitet-odnos" ( ER-Entitet-Odnos ), međutim, entiteti se ovdje ne shvaćaju kao stvarni objekti, već kao njihovi tipovi koji imaju zajednička svojstva. Odnosi između entiteta su složeniji. To vam omogućuje pohranjivanje informacija u obliku apstraktne sheme (semantičkog modela) koja povezuje znakove pohranjene u računalu sa stvarnim svijetom i njegov je pravi odraz. Ovaj način pohranjivanja informacija je relativno neovisan, "neutralan" i omogućuje vam da dobijete odgovor razne zahtjeve korisnika o svojstvima okoline opisane u modelu. Standard IDEF1X objavljen je 1993. FIPS 184).

2.4.1. Barkerova metoda slučaja

Svrha modeliranja podataka je pružiti razvijaču IS-a konceptualnu shemu baze podataka u obliku jednog ili više modela. lokalni modeli, koji se može relativno lako preslikati na bilo koji sustav baze podataka.

Najčešći alat za modeliranje podataka su dijagrami odnosa entiteta (ERD). Uz njihovu pomoć utvrđ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.

ERD notaciju prvi je uveo P. Chen, a dalje razvio Barker. Barkerova metoda bit će prikazana na primjeru modeliranja djelatnosti poduzeća za trgovinu automobilima. Slijede izvatci iz intervjua obavljenog s osobljem tvrtke.

Generalni direktor: jedna od glavnih odgovornosti je održavanje automobilske imovine. Mora znati koliko se plaćaju automobili i koliki su režijski troškovi. S tim informacijama može postaviti donju cijenu za koju može prodati ovaj primjer. Osim toga, odgovoran je za prodavače i mora znati tko što prodaje i koliko je tko od njih prodao automobila.

Prodavač: On mora znati koju cijenu tražiti i koja je najniža cijena po kojoj se može trgovati. Osim toga, trebaju mu osnovni podaci o automobilima: godina proizvodnje, marka, model itd.

Administrator: Njegov posao je sastavljanje ugovora, za što su potrebni podaci o kupcu, vozilu i prodavatelju, budući da su ugovori ti koji generiraju prodajne naknade za prodavatelje.

Prvi korak modeliranja je izdvajanje informacija iz intervjua i izdvajanje entiteta.

Entitet - stvarni ili imaginarni objekt koji je bitan za predmetno područje koje se razmatra, informacije o kojima treba pohraniti (slika 2.18).

Riža. 2.18. Grafički prikaz entiteta

Svaki entitet mora imati jedinstveni identifikator. Svaka instanca entiteta mora biti jedinstveno prepoznatljiva i različita od svih drugih instanci. ove vrste entiteta. Svaki entitet mora imati neka svojstva:

svaki entitet mora imati jedinstveno ime, a isto tumačenje uvijek se mora primjenjivati ​​na isto ime. Isto tumačenje ne može se primijeniti na različita imena, osim ako su aliasi;

entitet ima jedan ili više atributa koji ili pripadaju entitetu ili su naslijeđeni kroz odnos;

entitet ima jedan ili više atributa koji jedinstveno identificiraju svaki primjerak entiteta;

svaki entitet može imati bilo koji broj odnosa s drugim entitetima modela.

Pozivajući se na gornje izvatke intervjua, jasno je da su subjekti koji se mogu poistovjetiti s generalnim direktorom motorna vozila i prodavači. Prodavatelj brine o automobilima i podacima vezanim uz njihovu prodaju. Za administratora su važni kupci, automobili, prodavači i ugovori. Na temelju toga razlikuju se 4 entiteta (automobil, prodavatelj, kupac, ugovor), koji su prikazani na dijagramu na sljedeći način (slika 2.19).

Riža. 2.19.

Sljedeći korak modeliranja je identifikacija odnosa.

Odnos - imenovana veza između dva entiteta značajna za predmetno područje koje se razmatra. Odnos je asocijacija između entiteta, u kojoj je, u pravilu, svaka instanca jednog entiteta, koji se naziva nadređeni entitet, povezana s proizvoljnim (uključujući nula) brojem instanci drugog entiteta, koji se naziva podređeni entitet, i svaki instanca entiteta djeteta pridružena je točno jednoj instanci entiteta roditelja. Dakle, instanca entiteta djeteta može postojati samo ako postoji entitet roditelj.

Vezi se može dati ime izraženo gramatičkim obratom glagola i postaviti uz liniju veze. Naziv svakog odnosa između dva data entiteta mora biti jedinstven, ali nazivi odnosa u modelu ne moraju biti jedinstveni. Naziv odnosa uvijek se formira sa stajališta roditelja, tako da se rečenica može oblikovati kombinacijom imena nadređenog entiteta, naziva odnosa, izraza stupnja i imena podređenog entiteta.

Na primjer, odnos prodavatelja prema ugovoru može se izraziti na sljedeći način:

prodavatelj može biti nagrađen za 1 ili više ugovora;

ugovor mora inicirati točno jedan prodavač.

Stupanj povezanosti i predanosti grafički je prikazan na sljedeći način (Slika 2.20).

Riža. 2.20.

Dakle, 2 rečenice koje opisuju odnos prodavatelja s ugovorom bit će grafički prikazane na sljedeći način (slika 2.21).

Riža. 2.21.

Nakon što smo opisali i odnose ostalih entiteta, dobivamo sljedeću shemu (slika 2.22).

Riža. 2.22.

Posljednji korak modeliranja je identifikacija atributa.

Atribut - bilo koje obilježje subjekta koje je značajno za predmetno područje koje se razmatra, a namijenjeno je kvalifikaciji, identifikaciji, klasifikaciji, kvantitativnim obilježjima ili izražavanju stanja subjekta. Atribut predstavlja vrstu karakteristike ili svojstva povezanog sa skupom stvarnih ili apstraktnih objekata (ljudi, mjesta, događaji, stanja, ideje, parovi objekata itd.). Instanca atributa je specifična karakteristika pojedinačnog elementa skupa. Instanca atributa definirana je karakterističnim tipom i njegovom vrijednošću, koja se naziva vrijednost atributa. U ER modelu, atributi su povezani s određenim entitetima. Stoga, instanca entiteta mora imati jednu definiranu vrijednost za pridruženi atribut.

Atribut može biti obavezan ili neobavezan (Slika 2.23). Obavezan znači da atribut ne može imati nulte vrijednosti. Atribut može biti opisni (tj. normalni deskriptor entiteta) ili biti dio jedinstvenog identifikatora (primarni ključ).

Jedinstveni identifikatorje atribut ili kolekcija atributa i/ili odnosa dizajniranih za jedinstvenu identifikaciju svake instance danog tipa entiteta. U slučaju potpune identifikacije, svaka instanca danog tipa entiteta u potpunosti je identificirana svojim vlastitim ključnim atributima, inače su atributi drugog nadređenog entiteta također uključeni u njegovu identifikaciju (Slika 2.24).

Riža. 2.23.

Riža. 2.24.

Svaki atribut identificiran je jedinstvenim imenom, izraženim imenskom frazom koja opisuje karakteristiku koju atribut predstavlja. Atributi se prikazuju kao popis imena unutar pridruženog bloka entiteta, pri čemu svaki atribut zauzima zaseban red. Atributi koji definiraju primarni ključ nalaze se na vrhu popisa i označeni su znakom "#".

Svaki entitet mora imati barem jedan mogući ključ. Mogući ključ entiteta je jedan ili više atributa čije vrijednosti jedinstveno identificiraju svaku instancu entiteta. Kada postoji više mogućih ključeva, jedan od njih se označava kao primarni ključ, a ostali kao alternativni ključevi.

Uzimajući u obzir dostupne informacije, dopunit ćemo prethodno izgrađeni dijagram (slika 2.25).

Uz navedene osnovne strukture, podatkovni model može sadržavati niz dodatnih.

Podtipovi i nadtipovi:jedan entitet je generalizirajući koncept za grupu sličnih entiteta (slika 2.26).

Međusobno isključivi odnosi:svaka instanca entiteta sudjeluje samo u jednom odnosu iz grupe međusobno isključivih odnosa (slika 2.27).

Riža. 2.25.

Riža. 2.26. Podtipovi i nadtipovi

Riža. 2.27. Međusobno isključivi odnosi

Rekurzivna veza:entitet se može povezati sam sa sobom (slika 2.28).

Neprenosive veze:instanca entiteta ne može se premjestiti iz jedne instance odnosa u drugu (slika 2.29).

Riža. 2.28. Rekurzivni odnos

Riža. 2.29. Veza koja se ne može premjestiti

2.4.2. Metodologija IDEF1

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. Trenutačno, na temelju poboljšanja metodologije IDEF1, njegova nova verzija- IDEF1X metodologija. IDEF1X je dizajniran s lakoćom učenja i automatizacijom na umu. IDEF1X dijagrame koristi niz uobičajenih CASE alata (npr. ERwin, Design/IDEF).

Entitet u metodologiji IDEF1X neovisan je o identifikatoru ili jednostavno neovisan, ako se svaki primjerak entiteta može jedinstveno identificirati bez definiranja njegovog odnosa s drugim entitetima. Entitet se naziva ovisan o identifikatoru ili jednostavno ovisan ako jedinstvena identifikacija instance entiteta ovisi o njegovom odnosu s drugim entitetom (Slika 2.30).

Riža. 2.30. Esencije

Svakom entitetu dodijeljen je jedinstveni naziv i broj, odvojen kosom crtom "/" i postavljen iznad bloka.

Odnos se može dalje definirati određivanjem stupnja ili kardinalnosti (broj instanci entiteta djeteta koji mogu postojati za svaku instancu entiteta roditelja). U IDEF1X mogu se izraziti sljedeći kardinaliteti:

svaka instanca nadređenog entiteta može imati nula, jednu ili više instanci entiteta djeteta pridruženih sebi;

svaka instanca nadređenog entiteta mora imati najmanje jednu instancu entiteta djeteta pridruženu sebi;

svaka instanca nadređenog entiteta ne smije imati više od jedne instance entiteta djeteta pridružene sebi;

svaka instanca nadređenog entiteta povezana je s nekim fiksnim brojem instanci entiteta djeteta.

Ako je instanca podređenog entiteta jedinstveno određena svojim odnosom s nadređenim entitetom, tada se odnos naziva identifikacijskim, inače se naziva neidentifikirajućim.

Odnos je predstavljen linijom povučenom između nadređenog entiteta i podređenog entiteta s točkom na kraju linije kod podređenog entiteta. Snaga veze je označena kao što je prikazano na sl. 2.31 (zadana snaga - N).

Riža. 2.31. Komunikacijska snaga

Identifikacijski odnos između nadređenog entiteta i podređenog entiteta prikazan je kao puna linija (Slika 2.32). Entitet dijete u odnosu identifikacije je entitet ovisan o identitetu. Nadređeni entitet u identifikacijskom odnosu može biti neovisan ili ovisan o identifikatoru (ovo je određeno njegovim odnosima s drugim entitetima).

Riža. 2.32. Poveznica za identifikaciju

Isprekidana linija prikazuje neidentifikacijski odnos (Slika 2.33). Entitet dijete u neidentifikacijskom odnosu bit će neovisan o identifikatoru osim ako nije također entitet dijete u nekom identifikacijskom odnosu.

Riža. 2.33. Neidentifikacijski odnos

Atributi se prikazuju kao popis imena unutar bloka entiteta. Atributi koji definiraju primarni ključ nalaze se na vrhu popisa i odvojeni su vodoravnom trakom od ostalih atributa (slika 2.34).

Riža. 2.34. Atributi i primarni ključevi

Entiteti također mogu imati strane ključeve (Foreign Key), koji se mogu koristiti kao dio ili cijeli primarni ključ ili atribut koji nije ključ. Strani ključ predstavlja se postavljanjem imena atributa unutar bloka entiteta nakon čega slijede slova FK u zagradama (Slika 2.35).

Riža. 2.35. Primjeri stranih ključeva

2.5. Primjer korištenja strukturalnog pristupa

2.5.1. Opis predmetnog područja

Ovaj primjer koristi metodologiju Yourdon implementiranu u Vantage Team Builder CASE alatu.

Predmetno područje je opis posla videoteke koja prima zahtjeve za filmove od klijenata i vrpce koje klijenti vraćaju. Zahtjeve pregledava uprava videoteke koristeći podatke o kupcima, filmovima i vrpcama. Time se provjerava i ažurira popis iznajmljenih vrpci i provjerava evidencija o članstvu knjižnice. Administracija također kontrolira povrate kazeta koristeći podatke o filmovima, kazetama i popis iznajmljenih kazeta koji se ažurira. Obrada zahtjeva za filmove i vraćanja kaseta uključuje sljedeće: Ako korisnik nije član knjižnice, korisnik nema pravo na posudbu. Ako je potreban film dostupan, administracija obavještava klijenta o visini naknade za najam. Međutim, ako je kupcu istekao rok za vraćanje vrpci koje ima, ne smije preuzeti nove filmove. Kada se vrpca vrati, administracija izračunava najam plus kazne za kasni povrat.

Videoteka dobiva nove vrpce od svojih dobavljača. Kada nove vrpce stignu u knjižnicu, potrebne informacije o njima se bilježe. Podaci o članstvu u knjižnici čuvaju se odvojeno od zapisa o iznajmljivanju vrpci.

Uprava knjižnice redovito priprema izvješća za određeno razdoblje vrijeme o članovima knjižnice, dobavljačima vrpci, određenim posudbama vrpci i vrpcama koje je knjižnica kupila.

2.5.2. Organizacija projekta

Cijeli projekt podijeljen je u 4 faze: analiza, globalni dizajn (dizajn arhitekture sustava), detaljni dizajn i implementacija (programiranje).

Faza analize gradi model okoliša. Izgradnja modela okruženja uključuje:

• analiza ponašanja sustava (određivanje namjene IS-a, izgradnja početnog kontekstnog dijagrama protoka podataka (DFD) i generiranje matrice liste događaja (ELM), izgradnja kontekstnih dijagrama);
• analiza podataka (utvrđivanje sastava tokova podataka i konstruiranje dijagrama strukture podataka (DSD), konstruiranje globalnog modela podataka u obliku ER dijagrama).

Namjena IS-a određuje dogovor između projektanata i kupaca o namjeni budućeg IS-a, Opći opis IP za same dizajnere i granice IP-a. Dodjela je fiksirana kao tekstualni komentar u "nultom" procesu kontekstnog dijagrama.

Na primjer, u ovom slučaju, svrha IP-a formulirana je na sljedeći način: održavanje baze podataka o članovima knjižnice, filmovima, iznajmljivanjima i dobavljačima. Istodobno bi uprava knjižnice trebala moći primati različite vrste izvješća kako bi izvršili svoje zadatke.

Prije izgradnje kontekstualnog DFD-a potrebno je analizirati vanjske događaje (vanjske objekte) koji utječu na funkcioniranje knjižnice. Ti objekti stupaju u interakciju s IS-om razmjenom informacija s njim.

Iz opisa predmetnog područja proizlazi da su u proces rada knjižnice uključene sljedeće skupine ljudi: kupci, dobavljači i menadžment. Ove grupe su vanjski objekti. Oni ne samo da su u interakciji sa sustavom, već također definiraju njegove granice i prikazani su na početnom kontekstualnom DFD-u kao terminatori (vanjski entiteti).

Dijagram početnog konteksta prikazan je na slici 2.42. Za razliku od Gane/Sarsonove notacije, vanjski entiteti su označeni pravilnim pravokutnicima, a procesi kružićima.

Riža. 2.42. Dijagram početnog konteksta

Popis događaja izgrađen je u obliku matrice (ELM) i opisuje razne aktivnosti vanjske entitete i reakciju IS-a na njih. Ove radnje su vanjski događaji koji utječu na knjižnicu. Postoje sljedeće vrste događaja:

Skraćenica	Tip
	Normalna kontrola
	normalni podaci
	Normalna kontrola/podaci
	Privremena uprava
	Privremeni podaci
	Privremena kontrola/podaci

Sve akcije su označene kao normalni podaci. Ti podaci su događaji koje IS izravno percipira, npr. promjena adrese klijenta, što se mora odmah registrirati. Pojavljuju se u DFD-u kao sadržaj tokova podataka.

Matrica popisa događaja izgleda ovako:

	Opis	Tip	Reakcija
	Klijent se želi učlaniti u knjižnicu		Prijava klijenta kao člana knjižnice
	Klijent prijavljuje promjenu adrese		Registracija promijenjene adrese kupca
	Klijent traži iznajmljivanje filma		Zatraži pregled
	Klijent vraća film		Povratna registracija
	Uprava ovlašćuje novog dobavljača		Registracija dobavljača
	Dobavljač prijavljuje promjenu adrese		Registracija promijenjene adrese dobavljača
	Dobavljač šalje film u knjižnicu		Dobivanje novog filma
	Uprava traži novo izvješće		Formiranje potrebnog izvješća za menadžment

Kako bi se dovršila analiza funkcionalnog aspekta ponašanja sustava, izgrađen je kompletan kontekstni dijagram, uključujući dijagram nulte razine. Istodobno, proces "knjižnice" rastavljen je u 4 procesa, odražavajući glavne vrste administrativnih aktivnosti knjižnice. Postojeći "apstraktni" tokovi podataka između terminatora i procesa transformiraju se u tokove koji predstavljaju razmjenu podataka na konkretnijoj razini. Popis događaja pokazuje koji tokovi postoje na ovoj razini: svaki događaj s popisa mora formirati određeni tok (događaj čini ulazni tok, reakcija tvori izlazni tok). Jedna "apstraktna" nit može se podijeliti u više od jedne "konkretne" niti.

Tokovi u dijagramu najviše razine	Tokovi u dijagramu nulte razine
Podaci od klijenta	Podaci o kupcima, zahtjev za najam
Informacije za klijenta	Članska iskaznica, Odgovor na zahtjev za najam
Informacije od uprave	Zahtjev za izvješće o novom članu, novi dobavljač, zahtjev za izvješće o dobavljaču, zahtjev za izvješće o posudbi, zahtjev za izvješće o filmu
Informacije o upravljanju	Izvješće o novom članu, Izvješće o dobavljaču, Izvješće o posudbi, Izvješće o filmu
Podaci od dobavljača	Podaci o dobavljaču, novi filmovi

U DFD-u prikazanom na slici 2.43, pohrana podataka "knjižnice" je globalni ili apstraktni prikaz pohrane podataka.

Analiza funkcionalnog aspekta ponašanja sustava daje ideju o razmjeni i transformaciji podataka u sustavu. Odnos između "apstraktnih" tokova podataka i "konkretnih" tokova podataka u dijagramu nulte razine izražen je u dijagramima strukture podataka (Slika 2.44).

U fazi analize izrađuje se globalni podatkovni model, predstavljen u obliku dijagrama entitet-odnos (Slika 2.45).

Između različite vrste dijagrama, postoje sljedeći odnosi:

• ELM-DFD: događaji - ulazni tokovi, reakcije - izlazni tokovi
• DFD-DSD: tokovi podataka - strukture podataka najviše razine
• DFD-ERD: sakupljači podataka - ER dijagrami
• DSD-ERD: Strukture podataka niske razine - atributi entiteta

U fazi projektiranja arhitekture gradi se model predmeta. Proces izgradnje predmetnog modela uključuje:

• Detaljan opis funkcioniranje sustava;
• daljnja analiza korištenih podataka i izrada logičkog modela podataka za kasniji dizajn baze podataka;
• određivanje strukture korisničkog sučelja, specifikacija obrazaca i redoslijeda njihovog pojavljivanja;
• doradu dijagrama protoka podataka i popisa događaja, odabir interaktivnih i neinteraktivnih među procesima niže razine, definiranje mini specifikacija za njih.

Riža. 2.43. Kontekstni dijagram

Riža. 2.44. Dijagram strukture podataka

Rezultati arhitektonskog projektiranja su:

• model procesa (dijagrami arhitekture sustava (SAD) i mini-specifikacije na strukturirani jezik);
• model podataka (ERD i ERD podshema);
• model korisničkog sučelja (klasifikacija procesa na interaktivne i neinteraktivne funkcije, dijagram sekvence obrazaca (FSD - Form Sequence Diagram), koji prikazuje koji se obrasci pojavljuju u aplikaciji i kojim redoslijedom. FSD popravlja skup i strukturu poziva ekranskih obrazaca. FSD dijagrami tvore hijerarhiju, na vrhu koje je glavni oblik aplikacija koja implementira podsustav. Na drugoj razini nalaze se oblici koji provode procese niže razine funkcionalne strukture, fiksirane na SAD dijagramima.

Riža. 2.45. Dijagram entitet-odnos

Tijekom faze detaljnog projektiranja izrađuje se modularni model. Modularni model znači pravi model dizajnirani aplikacijski sustav. Proces izgradnje uključuje:

• usavršavanje modela baze podataka za naknadno generiranje SQL naredbi;
• dorada strukture korisničkog sučelja;
• građevni blok dijagrami koji odražavaju logiku korisničkog sučelja i model poslovne logike (Structure Charts Diagram - SCD) i njihovo povezivanje s obrascima.

Rezultati detaljnog projektiranja su:

• model procesa (strukturni dijagrami interaktivnih i neinteraktivnih funkcija);
• model podataka (definicija u ERD-u svih potrebnih parametara za aplikacije);
• model korisničkog sučelja (Dijagram slijeda obrasca (FSD) koji pokazuje koji se obrasci pojavljuju u aplikaciji i kojim redoslijedom, odnos između svakog obrasca i određenog strukturnog dijagrama, odnos između svakog obrasca i jednog ili više entiteta u ERD-u).

Tijekom faze implementacije gradi se model implementacije. Proces izgradnje uključuje:

• generiranje SQL naredbi koje definiraju strukturu ciljane baze podataka (tablice, indeksi, ograničenja integriteta);
• usavršavanje blok dijagrama (SCD) i dijagrama sekvence oblika (FSD) nakon čega slijedi generiranje aplikacijskog koda.

Na temelju analize protoka podataka i interakcije procesa sa skladištima podataka provodi se konačna dodjela podsustava (preliminarno je trebalo napraviti i popraviti u fazi formuliranja zahtjeva u projektni zadatak). Pri odabiru podsustava potrebno je voditi se načelom funkcionalne povezanosti i načelom minimiziranja informacijske ovisnosti. Treba imati na umu da se na temelju takvih elemenata podsustava kao što su procesi i podaci u fazi razvoja mora stvoriti aplikacija koja može samostalno funkcionirati. S druge strane, prilikom grupiranja procesa i podataka u podsustave, potrebno je uzeti u obzir zahtjeve za konfiguriranje proizvoda, ako su formulirani u fazi analize.

Karakteristike suvremenih operacijskih sustava

Iz godine u godinu, struktura i mogućnosti operativnih sustava se razvijaju. Nedavno su neki novi operativni sustavi i nove verzije već postojećih operativnih sustava uključeni konstruktivni elementi koji su pridonijeli Velike promjene na prirodu ovih sustava. Moderni operativni sustavi zadovoljavaju zahtjeve hardvera i softvera koji se stalno razvijaju. Oni mogu upravljati bržim višeprocesorskim sustavima, bržim mrežnim uređajima i sve većim brojem uređaja za pohranu podataka. Od aplikacija koje su utjecale na dizajn operacijskih sustava treba istaknuti multimedijske aplikacije, alate za pristup Internetu te model klijent/poslužitelj.

Stalni rast zahtjeva za operacijskim sustavima dovodi ne samo do poboljšanja njihove arhitekture, već i do pojave novih načina njihove organizacije. U eksperimentalnim i komercijalnim operativnim sustavima isproban je širok izbor pristupa i sastavnih dijelova, od kojih se većina može grupirati u sljedeće kategorije.

mikrokernel arhitektura.

· Višenitnost.

· Simetrična višestruka obrada.

· Distribuirani operativni sustavi.

· Objektno orijentirani dizajn.

Posebnost većine današnjih operativnih sustava je velika monolitna jezgra. Kernel operativnog sustava pruža većinu svojih značajki, uključujući planiranje, manipulaciju datotečnim sustavom, umrežavanje, upravljačke programe uređaja, upravljanje memorijom i mnoge druge. Obično se monolitna jezgra implementira kao jedan proces, čiji svi elementi koriste isti adresni prostor. U arhitekturi mikrojezgre samo je nekoliko najvažnijih funkcija dodijeljeno jezgri, što uključuje upravljanje adresnim prostorom, međuprocesnu komunikaciju (IPC) i osnovno planiranje. Ostale usluge operativnog sustava pružaju procesi koji se ponekad nazivaju poslužiteljima. Ovi se procesi izvode u korisničkom načinu rada i mikrojezgra ih tretira kao druge aplikacije. Ovaj pristup vam omogućuje da podijelite zadatak razvoja operativnog sustava na razvoj kernela i razvoj poslužitelja. Poslužitelji se mogu prilagoditi specifičnim zahtjevima aplikacije ili okruženja. Dodjela mikrojezgre u strukturi sustava pojednostavljuje implementaciju sustava, osigurava njegovu fleksibilnost, a također se dobro uklapa u distribuiranu okolinu. Zapravo, mikrojezgra je u interakciji s lokalnim i udaljeni poslužitelj prema istoj shemi, što pojednostavljuje izgradnju distribuiranih sustava.

Multithreading je tehnologija u kojoj je proces koji izvršava aplikaciju podijeljen u nekoliko istovremeno izvršavajućih niti. Slijede glavne razlike između niti i procesa.

· Teći. Jedinica rada koja se može otpremiti i koja uključuje kontekst procesora (koji uključuje sadržaj programskog brojača i pokazivača stoga), kao i vlastito područje stoga (za organiziranje poziva potprograma i pohranjivanje lokalnih podataka). Naredbe niti se izvršavaju sekvencijalno; dretva se može prekinuti kada se procesor prebaci na drugu dretu 4 .Proces. Zbirka jedne ili više niti i sistemskih resursa povezanih s tim nitima (kao što je područje memorije koje sadrži kod i podatke, otvorene datoteke, razne uređaje). Ovaj koncept je vrlo blizak konceptu pokrenutog programa. Dijeljenjem aplikacije u više niti, programer dobiva sve prednosti modularnosti aplikacije i mogućnost upravljanja vremenskim događajima povezanim s aplikacijom.

Multithreading je vrlo koristan za aplikacije koje izvode nekoliko neovisnih zadataka koji ne zahtijevaju sekvencijalno izvršavanje. Primjer takve aplikacije je poslužitelj baze podataka koji prihvaća i obrađuje više zahtjeva klijenata u isto vrijeme. Ako se više niti obrađuje unutar istog procesa, prebacivanje između različitih niti ima manje CPU opterećenja nego prebacivanje između različitih procesa. Osim toga, niti su korisne u strukturiranju procesa koji su dio jezgre operacijskog sustava, kao što je opisano u kasnijim poglavljima.

Sve donedavno osobnih računala, dizajniran za jednog korisnika, a radne stanice su sadržavale jedan virtualni mikroprocesor opće namjene. Kao rezultat stalno rastućih zahtjeva za performansama i sve nižih troškova mikroprocesora, proizvođači su se prebacili na proizvodnju računala s više procesora. Tehnologija simetričnog višeprocesiranja (SMP) koristi se za poboljšanje učinkovitosti i pouzdanosti. Ovaj pojam odnosi se na arhitekturu računalnog hardvera, kao i na način na koji se operativni sustav ponaša u skladu s ovim arhitektonsko obilježje. Simetrično višeprocesiranje može se definirati kao samostalni računalni sustav sa sljedećim karakteristikama.

1. Sustav ima više procesora.

2. Ovi procesori, međusobno povezani komunikacijskom sabirnicom ili nekim drugim sklopom, dijele istu glavnu memoriju i iste I/O uređaje.

3. Svi procesori mogu obavljati iste funkcije (otuda naziv simetrična obrada).

Operativni sustav koji radi na sustavu sa simetričnim višeprocesiranjem distribuira procese ili niti među svim procesorima. Višeprocesorski sustavi imaju nekoliko potencijalnih prednosti u odnosu na jednoprocesorske sustave, uključujući sljedeće.

· Izvođenje. Ako se posao koji računalo treba pokrenuti može organizirati tako da se dijelovi posla izvode paralelno, to će rezultirati boljom izvedbom od sustava s jednim procesorom s istom vrstom procesora. Gore formuliran položaj ilustriran je na sl. 2.12. U multitasking modu, samo jedan proces može biti pokrenut u isto vrijeme, dok su ostali procesi prisiljeni čekati svoj red. Na višeprocesorskom sustavu više procesa može se izvoditi istovremeno, a svaki se izvodi na zasebnom procesoru.

· Pouzdanost. Sa simetričnim multiprocesiranjem, kvar jednog od procesora neće zaustaviti stroj, jer svi procesori mogu obavljati iste funkcije. Nakon takvog kvara, sustav će nastaviti raditi, iako će se njegove performanse malo smanjiti.

· zgrada. Dodavanjem dodatnih procesora u sustav korisnik može povećati njegove performanse.

· Skalabilnost. Proizvođači mogu ponuditi svoje proizvode u različitim konfiguracijama cijena i performansi dizajniranim za rad s različitim brojem procesora.

Važno je napomenuti da su gore navedene dobrobiti potencijalne, a ne zajamčene. Kako bi se pravilno realizirao potencijal sadržan u višeprocesorskim računalnim sustavima, operativni sustav mora osigurati odgovarajući skup alata i mogućnosti.

Riža. 2.12. Multitasking i multiprocessing

Uobičajeno je vidjeti da se o višenitnosti i višeprocesiranju raspravlja zajedno, ali ta su dva koncepta neovisna. Multithreading je koristan koncept za strukturiranje procesa aplikacije i kernela, čak i na stroju s jednim procesorom. S druge strane, višeprocesorski sustav može imati prednosti u odnosu na jednoprocesorski sustav čak i ako procesi nisu podijeljeni u više niti, jer je moguće pokrenuti više procesa u isto vrijeme na takvom sustavu. Međutim, obje ove mogućnosti međusobno se dobro slažu i njihova zajednička uporaba može imati zamjetan učinak.

Primamljiva značajka višeprocesorskih sustava je da je prisutnost nekoliko procesora transparentna za korisnika - operativni sustav je odgovoran za distribuciju niti između procesora i za sinkronizaciju različitih procesa. Ova knjiga govori o mehanizmima zakazivanja i sinkronizacije koji se koriste da bi svi procesi i procesori bili vidljivi korisniku kao jedan sustav. Drugi zadatak više razine je predstavljanje klastera nekoliko zasebnih računala kao jedinstvenog sustava. U ovom slučaju imamo posla sa skupom računala, od kojih svako ima svoju primarnu i sekundarnu memoriju i svoje I/O module. Distribuirani operacijski sustav stvara dojam jedinstvenog prostora primarne i sekundarne memorije, kao i jednog sustava datoteka. Iako je popularnost klastera u stalnom porastu i na tržištu se pojavljuje sve više klasteriranih proizvoda, moderni distribuirani operacijski sustavi još uvijek zaostaju u razvoju za jednoprocesorskim i višeprocesorskim sustavima. S takvim sustavima upoznat ćete se u šestom dijelu knjige.

Jedna od najnovijih inovacija u dizajnu operativnih sustava je korištenje objektno orijentiranih tehnologija. Objektno orijentirani dizajn pomaže očistiti proces dodavanja dodatnih modula glavnoj maloj jezgri. Na razini operacijskog sustava, objektno orijentirana struktura programerima omogućuje prilagodbu operacijski sustav bez narušavanja njegovog integriteta. Osim toga, ovaj pristup olakšava razvoj distribuiranih alata i punopravnih distribuiranih operativnih sustava.

Ministarstvo gospodarskog razvoja Ministarstvo znanosti i obrazovanja Ruske Federacije Ruske Federacije

Državno sveučilište -

Srednja ekonomska škola

Fakultet poslovne informatike

Sažetak discipline

« Metodologija programskog inženjerstva»

« Tehnologije razvoja softverskog sustava CASE».

Završeno:

Gladyshev I.A.

171m, URPO

Provjereno:

Avdošin S.M.

Moskva 2008

Uvod

1. CASE alat: definicije i opće karakteristike.

2. Primjene CASE tehnologija: prednosti i nedostaci.

3. Implementacija CASE-tehnologija.

4. Primjeri CASE alata i njihove karakteristike.

4.3 Vantage Team Builder

4.4 Lokalni alati (ERwin, BPwin, S-Designor)

4.5 Objektno orijentirani CASE alati (Rational Rose)

4.6 Alati za upravljanje konfiguracijom

4.7 Alati za dokumentiranje

4.8 Alati za testiranje

Zaključak

Književnost.

Uvod

Svrha mog eseja je razmatranje razvojnih tehnologija programski sustavi na temelju CASE sredstava. U 70-im i 80-im godinama prošlog stoljeća pri razvoju IS-a naširoko se koristila strukturna metodologija koja programerima daje striktno formalizirane metode za opisivanje IS-a i donesenih tehničkih odluka. Kroz povijest programiranja softverski projekti postajali su sve kompliciraniji, količina posla se rapidno povećavala, a pojavila se i potreba za univerzalnim alatima koji bi mogli nekako pomoći u strukturiranju izrade softvera. Tradicionalni programski jezici, zbog slabe vidljivosti, redundantnosti i opširnosti, izgubili su na učinkovitosti, au 70-im i 80-im godinama strukturna metodologija se naširoko koristila u razvoju programskih sustava. Vidljivost i strogost alata za strukturnu analizu omogućili su programerima i budućim korisnicima sustava da raspravljaju i konsolidiraju svoje razumijevanje glavnih tehničkih rješenja. Sve je išlo na pojavu softvera i tehnoloških sredstava posebne klase.

1. CASE alat: definicije i opće karakteristike.

Kratica CASE je kratica za Computer Aided Software Engineering. Ovaj izraz je danas u širokoj upotrebi. U fazi nastanka takvih alata, pojam CASE korišten je samo u odnosu na automatizaciju razvoja softvera. Danas CASE alati općenito pokrivaju proces razvoja složenih IS-a: stvaranje i održavanje IS-a, analizu, formuliranje zahtjeva, dizajn aplikacijskog softvera i baza podataka, generiranje koda, testiranje, dokumentiranje, osiguranje kvalitete, upravljanje konfiguracijom i upravljanje projektima, kao kao i drugi procesi. Dakle, CASE-tehnologije čine cjelokupno okruženje za razvoj IS-a. Dakle, CASE tehnologija je metodologija za projektiranje softverskih sustava, kao i skup alata koji vam omogućuju vizualno modeliranje predmetnog područja, analizu ovog modela u svim fazama razvoja i održavanja IS-a i razvoj aplikacija u skladu s informacijama potrebama korisnika. Većina postojećih CASE alata temelji se na strukturnoj ili objektno orijentiranoj analizi i metodologijama projektiranja, koristeći specifikacije u obliku dijagrama ili tekstova za opisivanje vanjskih zahtjeva, odnosa između modela sustava, dinamike ponašanja sustava i softverske arhitekture. Glavne komponente CASE proizvoda su sljedeće:

metodologija, koji definira jedan grafički jezik i pravila za rad s njim.

grafički urednici, koji pomažu crtati dijagrame; nastao je širenjem PC-a i GUI-a, takozvanih "tehnologija velikih slova".

generator: Autor grafički prikaz modela, možete generirati izvorni kod za različite platforme (tzv. low case dio CASE tehnologije).

spremište, svojevrsna baza podataka za pohranjivanje rezultata rada programera.

2. Primjene CASE tehnologija: prednosti i nedostaci.

Razni statistički pregledi danas svjedoče o učinkovitosti korištenja CASE alata u procesu razvoja programskih sustava. Međutim, postotak kvarova još uvijek postoji i prilično je velik. Naravno, postoje nedostaci u korištenju tehnologije, značajni su nedostaci s aspekta poslovanja:

CASE alati ne moraju nužno imati trenutačni učinak; može se dobiti tek nakon nekog vremena;

stvarni troškovi implementacije CASE alata obično su puno veći od troškova njihove nabave;

CASE-alati pružaju mogućnosti za dobivanje značajnih koristi tek nakon uspješnog završetka procesa njihove implementacije.

Zbog raznolike prirode CASE alata, bilo bi pogrešno davati bilo kakve neuvjetne tvrdnje o stvarnom zadovoljenju određenih očekivanja od njihove implementacije. Možemo navesti sljedeće čimbenike koji kompliciraju određivanje mogućeg učinka korištenja CASE-alata:

širok izbor kvalitete i mogućnosti CASE-alata;

relativno kratko vrijeme korištenja CASE-alata u različitim organizacijama i nedostatak iskustva u njihovoj primjeni;

širok izbor u praksi provedbe različitih organizacija;

nedostatak detaljnih metrika i podataka za već dovršene i projekte koji su u tijeku;

širok raspon tematskih područja projekta;

različit stupanj integracije CASE-alata u različite projekte.

Postoje dva mišljenja oko utvrđivanja učinkovitosti korištenja CASE tehnologija: neki vjeruju da se prava korist od korištenja određenih vrsta CASE alata može dobiti tek nakon jedne ili dvije godine iskustva, drugi vjeruju da se učinak može stvarno očitovati. sama u radnoj fazi životnog ciklusa IP-a, kada tehnološka poboljšanja mogu dovesti do nižih operativnih troškova. Međutim, postoji niz znakova organizacije, s odsutnošću barem jednog od njih, implementacija CASE alata vjerojatno će završiti neuspješno:

Tehnologija: razumijevanje ograničenja postojećih sposobnosti i sposobnost prihvaćanja nove tehnologije;

Kultura: spremnost na implementaciju novih procesa i odnosa između programera i korisnika;

Upravljanje: jasno vodstvo i organizacija u odnosu na najvažnije faze i procese provedbe.

visoka razina tehnološke podrške za procese razvoja i održavanja softvera;

pozitivan utjecaj na neke ili sve od sljedećih čimbenika: produktivnost, kvaliteta proizvoda, sukladnost sa standardima, dokumentacija;

prihvatljiva razina povrata ulaganja u CASE-alate.

3. Implementacija CASE-tehnologija.

Pojam "implementacija" se u ovom podnaslovu koristi u prilično širokom smislu i uključuje aktivnosti od početne procjene potreba do pune upotrebe CASE tehnologija u različitim odjelima korisničke organizacije. Proces uvođenja CASE-alata sastoji se od sljedećih koraka:

utvrđivanje potreba za CASE-alatima;

evaluacija i izbor CASE alata;

provedba pilot projekta;

praktična implementacija CASE-alata.

Proces uspješne implementacije CASE-alata nije ograničen samo na njihovu upotrebu. Zapravo, pokriva planiranje i implementaciju mnogih tehničkih, organizacijskih, strukturnih procesa, promjene u cjelokupnoj kulturi organizacije, a temelji se na jasnom razumijevanju mogućnosti CASE alata. Na način na koji implementirate CASE alate može utjecati specifična situacija. Na primjer, ako klijent preferira određeni alat ili je potreban ugovorom, koraci implementacije trebaju slijediti taj unaprijed definirani izbor. U drugim situacijama, relativna jednostavnost ili složenost alata, stupanj dosljednosti ili sukoba s postojećim procesima u organizaciji, potreban stupanj integracije s drugim alatima, iskustvo i kvalifikacije korisnika mogu dovesti do odgovarajućih prilagodbi implementacije postupak.

4. Primjeri CASE alata i njihove karakteristike.

4.1 Srebrna vožnja

Alat Silverrun CASE američke tvrtke Computer Systems Advisers, Inc. koristi se za analizu i dizajn poslovne klase IC. Primjenjiv je za podršku bilo kojoj metodologiji koja se temelji na odvojenoj konstrukciji funkcionalnih i informacijskih modela. Silverrun ima modularnu strukturu i sastoji se od četiri modula, od kojih je svaki samostalan proizvod i može se kupiti i koristiti bez povezivanja s drugim modulima: modul za izgradnju modela poslovnih procesa, modul za konceptualno modeliranje podataka, modul za relacijsko modeliranje i upravitelj repozitorija radne grupe. Cijena koju treba platiti za visoku fleksibilnost i raznolikost vizualnih alata za izradu modela takav je nedostatak Silverruna kao nedostatak stroge međusobne kontrole između komponenti različitih modela.

Alat za razvoj aplikacija JAM proizvod je američke tvrtke JYACC. Glavna značajka JAM-a je njegova usklađenost RAD metodologija, budući da vam omogućuje brzu implementaciju ciklusa razvoja aplikacije, koji se sastoji od generiranja sljedeće verzije prototipa aplikacije, uzimajući u obzir zahtjeve identificirane u prethodnom koraku, i njezino predstavljanje korisniku. JAM ima modularnu strukturu i sastoji se od sljedećih komponenti:

Srž sustava;

JAM/DBi - specijalizirani moduli sučelja DBMS (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC, itd.);

JAM/RW - modul za generiranje izvješća;

JAM/CASEi - specijalizirani moduli sučelja za CASE alate (JAM/CASE-TeamWork, JAM/CASE-Innovator, itd.);

JAM/TPi - specijalizirani moduli sučelja za upravitelje transakcija (na primjer, JAM/TPi-Server TUXEDO, itd.);

Jterm je specijalizirani emulator X terminala.

Jezgra sustava (zapravo, sam JAM) je gotov proizvod i može se samostalno koristiti za razvoj aplikacija. Svi ostali moduli su opcijski i ne mogu se koristiti samostalno. Kod korištenja JAM-a, razvoj vanjskog sučelja aplikacije je vizualni dizajn i svodi se na kreiranje ekranskih formi postavljanjem struktura sučelja na njih i definiranjem polja za unos/izlaz informacija na ekranu.

4.3 PrednosttimGraditelj

Vantage Team Builder je integrirani softverski proizvod usmjeren na implementaciju vodopada modela životnog ciklusa softvera i podršku punog životnog ciklusa softvera. Prisutnost univerzalnog sustava za generiranje koda koji se temelji na određenim načinima pristupa repozitoriju projekta omogućuje održavanje visoke razine discipline izvršenja projekta od strane programera: stroga procedura za generiranje modela; kruta struktura i sadržaj dokumentacije; automatsko generiranje izvornih kodova programa itd. - sve to osigurava povećanje kvalitete i pouzdanosti razvijenog IS-a.

4.4 Lokalni alati (ERwin, BPwin, S-Designor)

ERwin je konceptualni alat za modeliranje baze podataka koji koristi IDEF1X metodologiju. ERwin implementira dizajn sheme baze podataka, generiranje njenog opisa na jeziku ciljanog DBMS-a i reinženjering postojeće baze podataka. ERwin je dostupan u nekoliko različitih konfiguracija ciljajući na najčešće 4GL alate za razvoj aplikacija. Za brojne alate za razvoj aplikacija (PowerBuilder, SQLWindows, Delphi, Visual Basic) generiraju se obrasci i prototipovi aplikacija. BPwin je alat za funkcionalno modeliranje koji implementira IDEF0 metodologiju. S-Designor je CASE alat za projektiranje relacijskih baza podataka. Po svojoj funkcionalnosti i cijeni blizak je alatu ERwin CASE, a razlikuje se po vanjskoj notaciji koja se koristi na dijagramima. S-Designor implementira standardnu ​​metodologiju modeliranja podataka i generira opis baze podataka za DBMS kao što su ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL poslužitelj i tako dalje.

4.5 Objektno orijentirani CASE alati (Rational Rose)

Rational Rose, CASE alat tvrtke Rational Software Corporation, dizajniran je za automatizaciju faza analize i dizajna softvera, kao i za generiranje kodova na različitim jezicima i izdavanje projektne dokumentacije. Rational Rose koristi metodologiju sinteze za objektno orijentiranu analizu i dizajn, temeljenu na pristupima tri vodeća stručnjaka u ovom području: Boocha, Rumbaugha i Jacobsona. Razvili su univerzalnu notaciju za modeliranje objekata (UML - Unified Modeling Language) koja tvrdi da je standard u području objektno orijentirane analize i dizajna. Specifična varijanta Rational Rose određena je jezikom u kojem se generiraju programski kodovi (C++, Smalltalk, PowerBuilder, Ada, SQLWindows i ObjectPro). Glavna opcija - Rational Rose / C ++ - omogućuje vam razvoj projektne dokumentacije u obliku dijagrama i specifikacija, kao i generiranje programskih kodova u C ++. Uz to, Rational Rose uključuje alate za reinženjering softvera koji omogućuju ponovno korištenje softverskih komponenti u novim projektima.

4.6 Alati za upravljanje konfiguracijom

Svrha upravljanja konfiguracijom je osigurati upravljivost i mogućnost kontrole procesa razvoja i održavanja softvera. Za to su potrebne točne i pouzdane informacije o stanju softvera i njegovih komponenti u bilo kojem trenutku, kao io svim predloženim i provedenim promjenama. Za rješavanje CG problema koriste se metode i alati koji osiguravaju identifikaciju stanja komponenti, uzimanje u obzir raspona svih komponenti i modifikacija sustava u cjelini, kontrolu nad promjenama na komponentama, strukturu sustava i njegovih funkcija te koordinirano upravljanje razvojem funkcija i poboljšanjem karakteristika sustava. Najčešći KU alat je PVCS tvrtke Intersolv (SAD), koji uključuje brojne neovisne proizvode: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder i PVCS Notify.

4.7 Alati za dokumentiranje

Za izradu dokumentacije u procesu razvoja IS-a koriste se različiti alati za izvješćivanje, kao i komponente izdavačkih sustava. Alati za dokumentaciju obično su ugrađeni u posebne CASE alate. Izuzetak su neki paketi koji pružaju dodatnu uslugu prilikom dokumentiranja. Od njih se SoDA (Software Document Automation) najaktivnije koristi.

Proizvod je dizajniran za automatizaciju razvoja projektne dokumentacije u svim fazama životnog ciklusa softvera. Omogućuje vam automatsko izdvajanje raznih informacija dobivenih u različitim fazama razvoja projekta i njihovo uključivanje u izlazne dokumente. Istodobno se kontrolira usklađenost dokumentacije s projektom, međusobna povezanost dokumenata, te osigurava njihovo pravovremeno ažuriranje. Rezultirajuća dokumentacija automatski se generira iz različitih izvora, čiji broj nije ograničen.

4.8 Alati za testiranje

Testiranje je proces izvršavanja programa kako bi se otkrile pogreške. Regresijsko testiranje je testiranje koje se provodi nakon poboljšanja funkcija programa ili promjena u njemu. Jedan od najnaprednijih alata za testiranje, Quality Works je integrirano višeplatformsko okruženje za razvoj automatiziranih testova bilo koje razine, uključujući regresijske testove za GUI aplikacije. Quality Works vam omogućuje početak testiranja u bilo kojoj fazi životnog ciklusa, planiranje i upravljanje procesom testiranja, prikaz promjena u aplikaciji i ponovno korištenje testova za više od 25 različitih platformi.

Zaključak

U radu su razmatrane tehnologije za razvoj softverskih sustava temeljenih na CASE tehnologijama. Detaljno se analizira definicija tako širokog koncepta kao što je CASE alat, identificiraju se glavne komponente CASE proizvoda. Također sam u svom radu razmatrao glavne prednosti i moguće nedostatke u procesu korištenja CASE alata u razvoju programskih sustava, kako s tehničkog tako i s ekonomskog aspekta. Nadalje, navedeni su primjeri CASE tehnologija i dane su njihove karakteristike.

Trendovi razvoja informacijskih tehnologija danas diktiraju novu razinu složenosti traženih informacijskih sustava. Veliki projekti IS danas karakteriziraju aspekti koji zahtijevaju implicitne metode modeliranja. Ovakav razvoj programskih sustava nije moguć u punoj mjeri učinkovitosti bez korištenja CASE alata. Moderni CASE alati pokrivaju široki raspon podrške za brojne tehnologije projektiranja IS-a: od jednostavnih alata za analizu i dokumentiranje do alata za automatizaciju u punom opsegu koji pokrivaju cijeli životni ciklus softvera.

Književnost.

prije podne Vendrov: CASE-tehnologije. Suvremene metode i alati za projektiranje informacijskih sustava
M.: Financije i statistika, 1998. - 176 str.: ilustracija

Kalyanov G.N. slučaj. Strukturalni analiza sustava(automatizacija i primjena). M., "Lori", 1998.

Novozhenov Yu.V. Objektno orijentirane tehnologije za razvoj složenih programskih sustava. M., 1997. (monografija).

Panashchuk S.A. Razvoj informacijskih sustava korištenjem CASE-sustava Silverrun. "SUBD", 1997. (monografija).

Gorchinskaya O.Yu. Designer/2000 je nova generacija ORACLE CASE proizvoda. "SUBD", 1996.

Gorin S.V., Tandoev A.Yu. Primjena CASE-alata Erwin 2.0 za informacijsko modeliranje u sustavima za obradu podataka. "SUBD", 1999. (enciklopedijska natuknica).