Arvutidisaini CASE-tehnoloogiad. Infosüsteemide (IS) projekteerimine CASE vahenditega

Kaasaegsete infotehnoloogiate arengusuundumused toovad kaasa majanduse erinevates valdkondades loodud infosüsteemide (IS) keerukuse pideva suurenemise. Kaasaegseid suuri IP-projekte iseloomustavad reeglina järgmised omadused:

kirjelduse keerukus (üsna suur hulk funktsioone, protsesse, andmeelemente ja nendevahelised keerulised seosed), mis nõuab andmete ja protsesside hoolikat modelleerimist ja analüüsi;

tihedalt interakteeruvate komponentide (alamsüsteemide) komplekti olemasolu, millel on oma kohalikud ülesanded ja toimimiseesmärgid (näiteks tehingute töötlemise ja rutiinsete probleemide lahendamisega seotud traditsioonilised rakendused ning ad hoc päringuid kasutavad analüütilise töötlemise rakendused (otsustustugi). suured andmemahud);

otseste analoogide puudumine, mis piirab standardsete projektlahenduste ja rakendatud süsteemide kasutamise võimalust;

vajadus integreerida olemasolevaid ja äsja arendatud rakendusi;

toimimine heterogeenses keskkonnas mitmel riistvaraplatvormil;

üksikute arendajarühmade ebaühtlus ja heterogeensus oskuste taseme ja väljakujunenud traditsioonide osas teatud tööriistade kasutamisel;

projekti märkimisväärne ajavahemik, mis on ühelt poolt tingitud arendusmeeskonna piiratud võimalustest ja teiselt poolt kliendiorganisatsiooni mastaabist ja selle üksikute osakondade erinevast valmisolekust IS-i juurutamiseks.

Projekti edukaks elluviimiseks tuleb ennekõike adekvaatselt kirjeldada kujundusobjekti (IS), ehitada terviklikud ja järjepidevad IS-i funktsionaalsed ja infomudelid. Senine IS-i projekteerimise kogemus näitab, et tegemist on loogiliselt keeruka, töömahuka ja aeganõudva tööga, mis nõuab kõrgelt kvalifitseeritud spetsialistide kaasamist. Kuid kuni viimase ajani viidi IS-i projekteerimine läbi peamiselt intuitiivsel tasandil, kasutades mitteformaliseeritud meetodeid, mis põhinesid kunstil, praktilisel kogemusel, eksperthinnangutel ja IS-i toimimise kvaliteedi kallitel eksperimentaalsetel kontrollidel. Lisaks võivad IS-i loomise ja käitamise käigus muutuda või täiustuda kasutajate infovajadused, mis muudab selliste süsteemide arendamise ja hooldamise veelgi keerulisemaks.

70ndatel ja 80ndatel kasutati IS-i väljatöötamisel laialdaselt struktuurset metoodikat, mis annab arendajatele ranged formaliseeritud meetodid IS-i ja tehniliste otsuste kirjeldamiseks. See põhineb visuaalsel graafilisel tehnikal: diagramme ja diagramme kasutatakse mitmesuguste IS-mudelite kirjeldamiseks. Struktuurianalüüsi tööriistade nähtavus ja rangus võimaldas süsteemi arendajatel ja tulevastel kasutajatel algusest peale mitteametlikult selle loomises osaleda, arutada ja kinnistada arusaamist peamistest tehnilistest lahendustest. Selle metoodika laialdane kasutamine ja selle soovituste järgimine konkreetsete IS-de väljatöötamisel oli aga üsna haruldane, kuna mitteautomaatse (käsitsi) arendusega on see praktiliselt võimatu. Tõepoolest, väga raske on käsitsi välja töötada ja graafiliselt esitada süsteemi rangeid formaalseid spetsifikatsioone, kontrollida nende täielikkust ja järjepidevust ning veelgi enam muuta. Kui siiski on võimalik luua range projekteerimisdokumentide süsteem, siis selle töötlemine tõsiste muudatuste ilmnemisel on praktiliselt võimatu. Käsitsi arendamine põhjustas tavaliselt järgmisi probleeme:

ebapiisav nõuete spetsifikatsioon;

suutmatus avastada vigu projekteerimisotsuste tegemisel;

dokumentatsiooni halb kvaliteet, mis vähendab jõudlust;

pikk tsükkel ja ebarahuldavad testitulemused.

Teisest küljest on IC-arendajad olnud ajalooliselt viimased, kes kasutasid arvutitehnoloogiat oma töö kvaliteedi, töökindluse ja tootlikkuse parandamiseks ("kingsepp ilma kingadeta" fenomen).

Ülaltoodud tegurid aitasid kaasa eriklassi tarkvara ja tehnoloogiliste tööriistade tekkele - CASE-tööriistad, mis rakendavad CASE-tehnoloogiat IS-i loomiseks ja hooldamiseks. Mõistet CASE (Computer Aided Software Engineering) kasutatakse praegu väga laias tähenduses. Mõiste CASE algne tähendus, mis piirdus ainult tarkvara (tarkvara) arendamise automatiseerimise küsimustega, on nüüdseks saanud uue tähenduse, hõlmates kompleksse IS väljatöötamise protsessi tervikuna. Nüüd tähistab termin CASE-tools tarkvaratööriistu, mis toetavad IS-i loomise ja hooldamise protsesse, sealhulgas nõuete analüüsi ja formuleerimist, rakendustarkvara (rakenduste) ja andmebaaside kujundamist, koodi genereerimist, testimist, dokumenteerimist, kvaliteedi tagamist, konfiguratsioonihaldust ja projektijuhtimine ja muud protsessid. CASE tööriistad koos süsteemitarkvara ja riistvaraga moodustavad tervikliku IS-i arenduskeskkonna.

modulaarse ja struktureeritud programmeerimise kontseptsioonidele vastuvõtlike analüütikute ja programmeerijate koolitamine;

arvuti jõudluse laialdane kasutuselevõtt ja pidev kasv, mis võimaldas kasutada tõhusaid graafilisi tööriistu ja automatiseerida enamikku projekteerimisetappe;

võrgutehnoloogia juurutamine, mis võimaldas ühendada üksikute esinejate jõupingutused ühtseks projekteerimisprotsessiks, kasutades ühist andmebaasi, mis sisaldab projekti kohta vajalikku teavet.

CASE-tehnoloogia on IS-i disainimetoodika, aga ka tööriistade komplekt, mis võimaldab visuaalsel kujul.

CASE tööriistad. Üldised omadused ja klassifikatsioon

Kaasaegsed CASE-tööriistad hõlmavad laia valikut tuge paljudele IS-i disainitehnoloogiatele: alates lihtsatest analüüsi- ja dokumenteerimisvahenditest kuni täismahuliste automatiseerimisvahenditeni, mis katavad kogu tarkvara elutsükli.

IS arenduse kõige aeganõudvamad etapid on analüüsi ja projekteerimise etapid, mille käigus tagavad CASE-tööriistad tehniliste otsuste kvaliteedi ja projektdokumentatsiooni koostamise. Samal ajal mängivad olulist rolli teabe visuaalse esitamise meetodid. See hõlmab struktuursete või muude diagrammide koostamist reaalajas, mitmekesise värvipaleti kasutamist ja süntaktiliste reeglite täielikku kontrollimist. Graafilise domeeni modelleerimise tööriistad võimaldavad arendajatel olemasolevat IS-i visuaalselt uurida, seda vastavalt eesmärkidele ja olemasolevatele piirangutele ümber ehitada.

CASE-tööriistade kategooriasse kuuluvad nii suhteliselt odavad süsteemid väga piiratud võimalustega personaalarvutitele kui ka kallid süsteemid heterogeensetele arvutusplatvormidele ja töökeskkondadele. Seega hõlmab kaasaegne tarkvaraturg umbes 300 erinevat CASE-tööriista, millest võimsamaid kasutavad ühel või teisel viisil peaaegu kõik juhtivad Lääne firmad.

Tavaliselt hõlmavad CASE-tööriistad mis tahes tarkvaratööriista, mis automatiseerivad teatud tarkvara elutsükli protsesse ja millel on järgmised peamised iseloomulikud omadused:

võimsad graafilised tööriistad IP kirjeldamiseks ja dokumenteerimiseks, mugava liidese pakkumiseks arendajaga ja tema loominguliste võimaluste arendamiseks;

CASE-tööriistade üksikute komponentide integreerimine, mis tagab IS arendusprotsessi juhitavuse;

spetsiaalselt organiseeritud projekti metaandmete hoidla (hoidla) kasutamine.

Integreeritud CASE-tööriist (või kogu tarkvara elutsüklit toetav tööriistade komplekt) sisaldab järgmisi komponente;

hoidla, mis on CASE-tööriista aluseks. See peab tagama projekti ja selle üksikute komponentide versioonide salvestamise, erinevatelt arendajatelt teabe saamise sünkroonimise rühma arendamise ajal, metaandmete kontrolli täielikkuse ja järjepidevuse tagamiseks;

graafilise analüüsi ja disaini tööriistad, mis võimaldavad luua ja redigeerida IS-mudeleid moodustavaid hierarhiliselt seotud diagramme (DFD, ERD jne);

rakenduste arendustööriistad, sealhulgas 4GL keeled ja koodigeneraatorid;

konfiguratsioonihaldustööriistad;

dokumenteerimisvahendid;

testimisvahendid;

projektijuhtimise tööriistad;

ümberkujundamise tööriistad.

Kõiki kaasaegseid CASE-tööriistu saab liigitada peamiselt tüüpide ja kategooriate järgi. Klassifikatsioon tüübi järgi peegeldab CASE-tööriistade funktsionaalset orientatsiooni teatud elutsükli protsesside jaoks. Kategooriaklassifikatsioon määrab integreerituse astme teostatavate funktsioonide järgi ja sisaldab eraldi kohalikke tööriistu, mis lahendavad väikeseid autonoomseid ülesandeid (tööriistad), osaliselt integreeritud tööriistade komplekti, mis katavad enamiku IP elutsükli etappe (tööriistakomplekt) ja täielikult integreeritud tööriistu, mis toetavad. kogu IP elutsükkel ja on ühendatud ühise hoidla kaudu. Lisaks saab CASE-tööriistu klassifitseerida järgmiste kriteeriumide alusel:

süsteemide ja andmebaaside rakendatavad metoodikad ja mudelid;

integreeritus DBMS-iga;

saadaolevad platvormid.

Tüüpide järgi klassifitseerimine langeb põhimõtteliselt kokku CASE-tööriistade komponentide koostisega ja sisaldab järgmisi põhitüüpe:

domeenimudelite koostamiseks ja analüüsimiseks mõeldud analüüsitööriistad (Suurtähe), (Design/IDEF (Meta Software), BPwin (Logic Works));

analüüsi- ja disainitööriistad (Middle CASE), mis toetavad levinumaid projekteerimismetoodikaid ja mida kasutatakse disaini spetsifikatsioonide loomiseks (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), Analüütik (MacroProject)). Selliste tööriistade väljundiks on süsteemi komponentide ja liideste spetsifikatsioonid, süsteemi arhitektuur, algoritmid ja andmestruktuurid;

andmebaasi kujundamise tööriistad, mis pakuvad andmete modelleerimist ja andmebaasi skeemi genereerimist (tavaliselt SQL-is) kõige tavalisemate DBMS-ide jaoks. TO nad sisaldavad ERwin (Logic Works), S-Designer (SDP) ja DataBase Designer (ORACLE). Andmebaasi kujundamise tööriistad sisalduvad ka tööriistades Vantage Team Builder, Designer/2000, Silverrun ja PRO-IV CASE;

rakenduste arendustööriistad. Nende hulka kuuluvad 4GL tööriistad (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) jne) ja generaatorite koodid sisaldub Vantage Team Builderis, PRO-IV-s ja osaliselt Silverrunis;

reengineeringu tööriistad, mis pakuvad programmikoodide ja andmebaasiskeemide analüüsi ning nende alusel erinevate mudelite ja disainispetsifikatsioonide moodustamist. Andmebaasiskeemide analüüs ja ERD genereerimise tööriistad sisalduvad Vantage Team Builderis, PRO-IV-s, Silverrunis, Designer/2000-s, ERwinis ja S-Designoris. Programmikoodi analüüsi valdkonnas on enim kasutusel objektorienteeritud CASE-tööriistad, mis pakuvad C++ programmide ümberkujundamist (Rational Rose (Rational Software), Object Team (Cayenne)).

Abistajate tüübid on järgmised:

projekti planeerimise ja juhtimise tööriistad (SE Companion, Microsoft Project jne);

konfiguratsioonihaldustööriistad (PVCS (Intersolv));

testimisvahendid (Kvaliteetsed tööd (Segue tarkvara));

dokumenteerimisvahendid (SoDA (Rational Software)).

Praeguseks on Venemaa tarkvaraturul järgmised enim arenenud CASE-tööriistad:

Vantage Team Builder (Westmount I-CASE);

Disainer/2000;

Hõbedane jooks;

ERwin+BPwin;

S Disainer;

CASE.Analüütik.

Lisaks ilmuvad turule pidevalt nii uued kodukasutajatele mõeldud süsteemid (näiteks CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), kui ka nende süsteemide uued versioonid ja modifikatsioonid.

1. IS-i projekteerimise metoodika alused

1.1. IP-tarkvara elutsükkel

Üks IS-i disainimetoodika põhimõisteid on selle tarkvara (LC-tarkvara) elutsükli kontseptsioon. Tarkvara elutsükkel on pidev protsess, mis algab hetkest, mil tehakse otsus selle loomise vajaduse kohta ja lõpeb selle täieliku tegevuse lõpetamise hetkel.

Peamine tarkvara elutsüklit reguleeriv regulatiivne dokument on rahvusvaheline standard ISO / IEC 12207 (ISO - International Organization of Standardization - International Organisation for Standardization, IEC - International Electrotechnical Commission - International Electrotechnical Commission). See määratleb elutsükli struktuuri, mis sisaldab protsesse, tegevusi ja ülesandeid, mis tuleb tarkvaraarenduse käigus täita.

Tarkvara elutsükli struktuur vastavalt ISO/IEC 12207 standardile põhineb kolmel protsesside rühmal:

tarkvara elutsükli põhiprotsessid (ost, tarnimine, arendus, käitamine, hooldus);

abiprotsessid, mis tagavad põhiprotsesside elluviimise (dokumentatsioon, konfiguratsioonihaldus, kvaliteedi tagamine, verifitseerimine, sertifitseerimine, hindamine, audit, probleemide lahendamine);

organisatsioonilised protsessid (projektijuhtimine, projekti infrastruktuuri loomine, elutsükli enda määratlemine, hindamine ja täiustamine, koolitus).

Arendus hõlmab kõiki töid tarkvara ja selle komponentide loomisel vastavalt kindlaksmääratud nõuetele, sealhulgas projekteerimis- ja töödokumentatsiooni koostamist, tarkvaratoodete toimivuse ja sobiva kvaliteedi testimiseks vajalike materjalide ettevalmistamist, personali organiseerimiseks vajalikke materjale. koolitus jne. Tarkvaraarendus hõlmab tavaliselt analüüsi, disaini ja juurutamist (programmeerimist).

Töö hõlmab tarkvarakomponentide kasutuselevõttu, sealhulgas andmebaasi ja kasutajate tööjaamade konfigureerimist, töödokumentatsiooni pakkumist, personali koolituse läbiviimist jne ning otsest töötamist, sealhulgas probleemide lokaliseerimist ja nende esinemise põhjuste kõrvaldamist, tarkvara muutmist kehtestatud regulatsioone, ettepanekute koostamist süsteemi parendamiseks, arendamiseks ja kaasajastamiseks.

Projektijuhtimine on seotud tööde planeerimise ja korraldamise, arendajameeskondade loomise ning teostatavate tööde ajastuse ja kvaliteedi jälgimisega. Projekti tehniline ja korralduslik tugi hõlmab meetodite ja vahendite valikut projekti elluviimiseks, vahearengu olekute kirjeldamise meetodite määratlemist, tarkvara testimise meetodite ja vahendite väljatöötamist, personali koolitust jne. Projekti kvaliteedi tagamine on seotud tarkvara verifitseerimise, verifitseerimise ja testimise probleemidega. Kontrollimine on protsess, mille käigus tehakse kindlaks, kas antud etapis saavutatud hetkeseis vastab selle etapi nõuetele. Valideerimine võimaldab hinnata arendusparameetrite vastavust esialgsetele nõuetele. Kontrollimine kattub testimisega, mille eesmärk on tuvastada erinevused tegelike ja oodatavate tulemuste vahel ning hinnata, kas tarkvara funktsioonid vastavad algsetele nõuetele. Projekti elluviimise protsessis on olulisel kohal üksikute komponentide ja kogu süsteemi kui terviku identifitseerimise, kirjeldamise ja konfiguratsiooni kontrollimise küsimused.

Konfiguratsioonihaldus on üks abiprotsesse, mis toetavad tarkvara elutsükli põhiprotsesse, eelkõige tarkvara arendamise ja hoolduse protsesse. Keerukate, paljudest komponentidest koosnevate IS-projektide loomisel, millest igaühel võib olla variatsioone või versioone, tekib probleem nende seoste ja funktsioonidega arvestamises, ühtse struktuuri loomises ja kogu süsteemi arengu tagamises. Konfiguratsioonihaldus võimaldab korraldada, süstemaatiliselt arvesse võtta ja kontrollida tarkvara muudatusi elutsükli kõigil etappidel. Konfiguratsiooniarvestuse, tarkvara konfiguratsioonide planeerimise ja haldamise üldpõhimõtted ja soovitused on kajastatud ISO 12207-2 standardi eelnõus.

Iga protsessi iseloomustavad teatud ülesanded ja nende lahendamise meetodid, eelmises etapis saadud lähteandmed ja tulemused. Analüüsi tulemusteks on eelkõige funktsionaalsed mudelid, infomudelid ja neile vastavad diagrammid. Tarkvara elutsükkel on oma olemuselt iteratiivne: järgmise etapi tulemused põhjustavad sageli muutusi varasemates etappides välja töötatud disainiotsustes.

2. Struktuurne lähenemine IS-i disainile CASE tähendab

2.1. Struktuurse lähenemise olemus

IS-i arendamise struktuurse lähenemise olemus seisneb selle lagunemises (partitsioneerimises) automatiseeritud funktsioonideks: süsteem jaguneb funktsionaalseteks alamsüsteemideks, mis omakorda jagunevad alamfunktsioonideks, jaotatakse ülesanneteks jne. Jaotamisprotsess jätkub kuni konkreetsete protseduurideni. Samal ajal säilitab automatiseeritud süsteem tervikliku vaate, milles kõik komponendid on omavahel ühendatud. Süsteemi "alt-üles" arendamisel üksikutelt ülesannetelt kogu süsteemile kaob terviklikkus, tekivad probleemid üksikute komponentide informatiivsel dokkimisel.

Kõik levinumad struktuurse lähenemise metoodikad põhinevad mitmetel üldpõhimõtetel. Kasutatakse kahte järgmist põhiprintsiipi:

"jaga ja valluta" põhimõte – keeruliste probleemide lahendamise põhimõte, jagades need paljudeks väiksemateks iseseisvateks ülesanneteks, mida on lihtne mõista ja lahendada;

hierarhilise järjestamise põhimõte - põhimõte organiseerida probleemi koostisosad hierarhilisteks puustruktuurideks koos uute detailide lisamisega igal tasandil.

Kahe põhiprintsiibi valimine ei tähenda, et teised printsiibid oleksid teisejärgulised, kuna neist ühegi eiramine võib viia ettearvamatute tagajärgedeni (sh kogu projekti läbikukkumiseni). Peamised neist põhimõtetest on järgmised:

abstraktsiooni põhimõte - on tõsta esile süsteemi olulised aspektid ja abstraktsioon ebaolulisest;

vormistamise põhimõte – seisneb vajaduses probleemi lahendamisel range metoodilise lähenemise järele;

järjepidevuse põhimõte - seisneb elementide kehtivuses ja kooskõlas;

Andmete struktureerimise põhimõte – on see, et andmed peavad olema struktureeritud ja hierarhiliselt organiseeritud.

Struktuurianalüüsis kasutatakse peamiselt kahte rühma tööriistu, mis illustreerivad süsteemi poolt täidetavaid funktsioone ja andmete vahelisi seoseid. Iga tööriistade rühm vastab teatud tüüpi mudelitele (skeemidele), millest levinumad on järgmised:

SADT (Structured Analysis and Design Technique) mudelid ja nendega seotud funktsionaalsed diagrammid (alajaotis 2.2);

DFD (Data Flow Diagrams) andmevoo diagrammid (alajaotis 2.3);

ERD (Entity-Relationship Diagrams) diagrammid "entity-relationship" (alajaotis 2.4).

IS-i projekteerimise etapis laiendatakse, täiustatakse ja täiendatakse skeemidega, mis kajastavad tarkvara struktuuri: tarkvara arhitektuur, programmide plokkskeemid ja ekraanivormi diagrammid.

Loetletud mudelid koos annavad IS-i täieliku kirjelduse, olenemata sellest, kas see on olemasolev või äsja välja töötatud. Diagrammide koosseis sõltub igal konkreetsel juhul süsteemi kirjelduse nõutavast täielikkusest.

2.2. SADT funktsionaalse modelleerimise metoodika ( IDEF 0)

SADT metoodika töötas välja Douglas Ross. Selle põhjal töötati välja eelkõige tuntud IDEF0 (Icam DEFinition) metoodika, mis on USA õhujõudude algatatud programmi ICAM (Integration of Computer and Industrial Technologies) põhiosa.

SADT metoodika on meetodite, reeglite ja protseduuride kogum, mis on loodud objekti funktsionaalse mudeli koostamiseks mis tahes ainevaldkonnas. SADT funktsionaalne mudel peegeldab objekti funktsionaalset struktuuri, st. toimingud, mida see teeb, ja seosed nende toimingute vahel. Selle metoodika põhielemendid põhinevad järgmistel kontseptsioonidel:

plokkide modelleerimise graafiline esitus. SADT diagrammi plokk- ja kaargraafika kuvab funktsiooni plokina ning sisend/väljundliideseid kujutavad vastavalt plokki sisenevad ja väljuvad kaared. Plokkide vastastikmõju kirjeldatakse "piiranguid" väljendavate liidesekaaride abil, mis omakorda määravad, millal ja kuidas funktsioone täidetakse ja juhitakse;

rangust ja täpsust. SADT reeglite rakendamine nõuab piisavat rangust ja täpsust ilma analüütiku tegevusele liigseid piiranguid seadmata. SADT reeglid hõlmavad järgmist:

plokkide arvu piiramine igal lagunemistasandil (reegel 3-6 plokki);

diagrammide ühenduvus (plokkide arv);

siltide ja nimede ainulaadsus (dublikaatnimede puudumine);

graafika (plokid ja kaared) süntaktilised reeglid;

sisendite ja kontrollide eraldamine (andmete rolli määramise reegel).

organisatsiooni eraldamine funktsioonist, s.o. organisatsioonilise struktuuri mõju välistamine funktsionaalsele mudelile.

SADT metoodikat saab kasutada paljude süsteemide modelleerimiseks ning nõuete ja funktsioonide määratlemiseks ning seejärel nendele nõuetele vastava süsteemi kavandamiseks ja nende funktsioonide rakendamiseks. Juba olemasolevate süsteemide puhul saab SADT abil analüüsida süsteemi poolt täidetavaid funktsioone, samuti näidata mehhanisme, mille kaudu neid teostatakse.

2.2.1. Funktsionaalse mudeli koostis

SADT metoodika rakendamise tulemuseks on mudel, mis koosneb diagrammidest, tekstifragmentidest ja sõnastikust, millel on omavahel lingid. Diagrammid on mudeli põhikomponendid, kõik IS funktsioonid ja liidesed on esitatud plokkide ja kaarena. Kaare ühenduspunkt plokiga määrab liidese tüübi. Juhtteave siseneb plokki ülevalt, samal ajal kui töödeldav teave kuvatakse ploki vasakus servas ja väljundtulemused kuvatakse paremal. Toimingut sooritav mehhanism (inimene või automatiseeritud süsteem) on kujutatud altpoolt plokki siseneva kaarega (joonis 2.1).

SADT metoodika üks olulisemaid omadusi on mudelit kujutavate diagrammide loomisel järjest suureneva detailitaseme juurutamine.

Riis. 2.1. Funktsiooniplokk ja liidese kaared

Joonis 2.2, millel on kujutatud neli diagrammi ja nende seoseid, näitab SADT mudeli ülesehitust. Mudeli iga komponendi saab laotada erinevaks diagrammiks. Iga diagramm illustreerib põhiskeemi ploki "sisemist struktuuri".

2.2.2. Diagrammi hierarhia

SADT mudeli konstrueerimine algab kogu süsteemi kujutamisega kõige lihtsama komponendi kujul - üks plokk ja kaared, mis kujutavad liideseid süsteemiväliste funktsioonidega. Kuna üks plokk esindab kogu süsteemi tervikuna, on plokis antud nimi üldnimetus. See kehtib ka liidese kaare kohta - need esindavad ka süsteemi kui terviku väliste liideste komplekti.

Seejärel kirjeldatakse plokk, mis kujutab süsteemi ühe moodulina, teises diagrammis, kasutades mitut liidese kaarega ühendatud plokki. Need plokid esindavad algse funktsiooni peamisi alamfunktsioone. See jaotus paljastab täieliku alamfunktsioonide komplekti, millest igaüks on kujutatud plokina, mille piirid on määratletud liidesekaaridega. Kõiki neid alamfunktsioone saab üksikasjalikuma vaate saamiseks sarnaselt lahti võtta.

Igal juhul võib iga alamfunktsioon sisaldada ainult neid elemente, mis sisalduvad algses funktsioonis. Samuti ei saa mudel välja jätta ühtegi elementi, st nagu märgitud, pakuvad konteksti lähteplokk ja selle liidesed. Sellele ei saa midagi lisada ega sealt midagi eemaldada.

SADT-mudel on diagrammide seeria koos kaasasoleva dokumentatsiooniga, mis jagab keerulise objekti osadeks, mis on esitatud plokkidena. Iga põhiploki üksikasjad on näidatud plokkidena teistes diagrammides. Iga üksikasjalik diagramm on ploki lagunemine üldisemast diagrammist. Igas lagunemisetapis nimetatakse üldisemat diagrammi üksikasjalikuma diagrammi vanemaks.

Kõrgema taseme diagrammi plokki sisenevad ja sealt väljuvad kaared on täpselt samad, mis madalama taseme diagrammi sisenevad ja sealt väljuvad kaared, sest plokk ja diagramm esindavad sama süsteemi osa.

Riis. 2.2. SADT mudeli struktuur. Diagrammi lagunemine

Joonistel 2.3 - 2.5 on toodud erinevad võimalused funktsioonide täitmiseks ja kaare ühendamiseks plokkidega.

Riis. 2.3. Samaaegne täitmine

Riis. 2.4. Vastavus peab olema täielik ja järjepidev

Mõned kaared on kinnitatud diagrammikastide mõlemasse otsa, samas kui teistel on üks ots kinnitamata. Ühendamata kaared vastavad põhiploki sisenditele, juhtelementidele ja väljunditele. Nende piirikaarede allika või sihtkoha leiate ainult põhidiagrammist. Kinnitamata otsad peavad vastama originaalskeemi kaaretele. Kõik piirikaared peavad jätkuma põhidiagrammil, et see oleks täielik ja ühtlane.

SADT diagrammid ei näita selgesõnaliselt ei järjestust ega aega. Tagasisidet, iteratsioone, käimasolevaid protsesse ja (ajaliselt) kattuvaid funktsioone saab kujutada kaare abil. Tagasiside võib olla kommentaaride, märkuste, paranduste jms kujul. (Joonis 2.5).

Riis. 2.5. Tagasiside näide

Nagu märgitud, näitavad mehhanismid (kaared alumisel küljel) vahendeid, mille abil funktsioone täidetakse. Mehhanismiks võib olla inimene, arvuti või mõni muu seade, mis seda funktsiooni aitab (joonis 2.6).

Riis. 2.6. Mehhanismi näide

Igal diagrammi plokil on oma number. Mis tahes diagrammi plokki saab täiendavalt kirjeldada madalama taseme diagrammiga, mida saab omakorda vajaliku arvu diagrammidega üksikasjalikumalt kirjeldada. Seega moodustub diagrammide hierarhia.

Mis tahes diagrammi või ploki asukoha näitamiseks hierarhias kasutatakse diagrammide numbreid. Näiteks A21 on diagramm, mis kirjeldab diagrammi A2 kasti 1. Samamoodi kirjeldab A2 kasti 2 diagrammil A0, mis on mudeli kõige ülemine diagramm. Joonis 2.7 näitab tüüpilist diagrammipuud.

Riis. 2.7. Diagrammi hierarhia

2.2.3. Funktsioonide vaheliste linkide tüübid

Üks oluline punkt SADT metoodikat kasutava IS-i kujundamisel on funktsioonide vaheliste seoste tüüpide täpne kooskõla. Köitmisel on vähemalt seitse tüüpi:

Suhtlemistüüp	Suhteline tähtsus
Juhuslik
loogiline
Ajutine
protseduuriline
Suhtlemine
järjekindel
funktsionaalne

Iga lingitüüp on allpool lühidalt määratletud ja illustreeritud SADT tüüpilise näitega.

(0) Juhusliku ühenduse tüüp: kõige vähem soovitav.

Juhuslik ühenduvus tekib siis, kui funktsioonide vahel on vähe spetsiifilist seost või see puudub üldse. See viitab olukorrale, kus sama diagrammi SADT kaare andmenimedel on üksteisega vähe seost. Selle juhtumi äärmuslik versioon on näidatud joonisel 2.8.

Riis. 2.8. Juhuslik ühendus

(1) Loogilise ühenduse tüüp.Loogiline sidumine toimub siis, kui andmed ja funktsioonid tuuakse kokku, kuna need kuuluvad ühisesse klassi või elementide hulka, kuid vajalikke funktsionaalseid seoseid nende vahel ei leita.

(2) Ajalise ühenduse tüüp.Ajaga seotud elemendid tekivad seetõttu, et need esindavad ajaga seotud funktsioone, kui andmeid kasutatakse samaaegselt või funktsioonid on lubatud paralleelselt, mitte järjestikku.

(3) Menetlusliku seotuse liik.Protseduuriliselt seotud üksused kuvatakse rühmitatuna, kuna neid täidetakse tsükli või protsessi sama osa ajal. Protseduuriliselt seotud diagrammi näide on näidatud joonisel 2.9.

Riis. 2.9. protseduuriline ühenduvus

(4) Sideühenduse tüüp.Diagrammid näitavad sidelinke, kui plokid on rühmitatud, kuna need kasutavad sama sisendit ja/või toodavad sama väljundit (joonis 2.10).

(5) Jadaühenduse tüüp.Jadalinkidega diagrammides on ühe funktsiooni väljund järgmise funktsiooni sisendiks. Diagrammi elementide vaheline seos on tihedam kui eelpool käsitletud seoste tasanditel, kuna modelleeritakse põhjus-tagajärg seoseid (joonis 2.11).

(6) Funktsionaalse ühenduvuse tüüp.Diagramm peegeldab täielikku funktsionaalset ühenduvust, kui üks funktsioon on teisest täielikult sõltuv. Puhtalt funktsionaalne diagramm ei sisalda järjestikuse või nõrgema ühenduvuse võõrelemente. Üks võimalus funktsionaalselt seotud diagrammide määratlemiseks on võtta arvesse kahte juhtkaare kaudu ühendatud plokki, nagu on näidatud joonisel 2.12.

Riis. 2.10. Side Ühenduvus

Riis. 2.11. jadaühendus

Joonis 13. Funktsionaalne diagramm toote disaini loomiseks ja muutmiseks (teine tase)

Loetavuse huvides on soovitatav piirata diagrammi plokkide arvu kolmele kuni kuuele. Ülemine piir sunnib kasutama lagunemist, alumine tagab, et diagrammil on piisavalt detaile, et selle loomist õigustada. Soovitav on, et ploki küljele lähenevate või sellest lähtuvate liidesekaaride arv ei ületaks 4.

IDEF 0 meetod eeldab rühmatöödprojekti või projektide üle. Rühm erinevaid spetsialiste küsitleb pädevaid isikuid ja koostab umbkaudse mudeli. Seda mudelit arutavad ettevõtte spetsialistid, kritiseerivad kirjalikult ja edastavad arendusmeeskonnale. See tsükkel jätkub seni, kuni arendajad ja arvustajad nõustuvad. Järgmisena kiidetakse mudel ametlikult heaks ja seda kasutatakse (näiteks süsteemi funktsioonide ümberstruktureerimiseks).

Üks meetodi eeliseid IDEF 0 tähendab, et see abstraktseb äraobjekti organisatsiooniline struktuurja analüüsib selle funktsioone. See võimaldab pärast mudeli koostamist vaadelda neid funktsioone rakendavat organisatsiooni struktuuri selle täiuslikkuse seisukohalt, tuvastada sarnased funktsioonid või nende dubleerimine ning anda ettepanekuid süsteemi ümberkorraldamiseks.

Kui kasutada mõistet "äriprotsess", siis võib öelda, et meetod IDEF 0 võimaldab teil tuvastadaäriprotsesse, kaaluda ettevõtte toimimist "nagu on" ja nende analüüsi põhjal teha ettepanekuid "nagu peab" ehk siis vaadata ettevõtte tööd värske pilguga, selgitada töötajate kohustusi, hinnata ressursikasutuse efektiivsust, näha tavapärases organisatsioonistruktuuris kunstipäraselt peidetud puudujääke. Seetõttu saab äriprotsesside tuvastamist, analüüsimist ja muudatuste tegemist kasutada ettevõtte efektiivsuse tõstmiseks.

Pärast mõiste "äriprotsess" kasutuselevõttu on tekkinud mitmeid äriprotsesside täiustamise tehnikaid. Kõige populaarsem neist on ettevõtte äriprotsesside ümberkujundamine, mis eeldab ettevõtte äriprotsesside põhjalikku ümbermõtestamist ja ümberkujundamist. Nende protsesside tuvastamine, analüüs ja ümberkujundamine on kavandatava metoodika sisu. Ettevõtte äriprotsesside analüüsimise ja ümberkorraldamise metoodika üldskeem on järgmine (vt joonis 12):

Ettevõtte kohta teabe kogumine;

ettevõtte äriprotsesside tuvastamine ja ettevõtte äriprotsesside funktsionaalse mudeli loomine;
ettevõtte äriprotsesside analüüs ja võimalik ümberkujundamine.

Analüüsi jaoks kulude jagaminerakendatakse IDEF0-l põhinevat ABC-meetodit. ABC-meetod põhineb asjaolul, et iga funktsiooni täitmisel ettevõtte toimimise ajal on teatud kulu, see tähendab, et see aitab kaasa kulude ilmnemisele. АВС sarnaneb FSA kontseptsiooniga – funktsionaalne kuluanalüüs. ABC meetodil arvutatakse kogu protsessi või eraldi funktsiooni täitmise kulud, toodete maksumus protsessi väljundis ning selgitatakse välja peamiste kulude allikad. Dekomponeeritava funktsiooni täitmise maksumus on määratletud selle funktsiooni kõigi koostisosade täitmise kulude summana.

ABC-meetodi rakendamine võimaldab saada kvantitatiivseid hinnanguid protsessi kohta, mis on vajalik mitme võimaluse hindamiseks. Erinevalt traditsioonilisest raamatupidamisest, mis arvestab peamiselt otseseid kulusid (kaudsete kulude arvestamine on keeruline, kuid mõnel juhul vajalik), võimaldab ABC meetod arvestada erinevate teguritega, mis mõjutavad ettevõtte kulude kujunemist.

Funktsionaalse mudeli ehitamiseks tehakse ettepanek valida CASE-Design/IDEF pakett , kuna lisaks funktsionaalse mudeli loomise võimalustele sisaldab see pakett funktsioonide täitmise kulude arvutamiseks sisseehitatud ABC mehhanismi, mis võimaldab analüüsida äriprotsesse ja nende komponente. Iga funktsiooni poolt tarbitud (töödeldud) ressursi tüüp, samuti funktsiooni täitvad mehhanismid lisavad sellele funktsioonile kulusid, võttes samal ajal arvesse kuluelemente, mida ettevõtte tavapärasel organisatsioonistruktuuride kogumina eiratakse. . Seetõttu saab IDEF0 mudeli iga funktsiooni h seostada selle funktsiooni täitmise kulu väärtusega Ex(h).

Joonis 14. Ettevõtte äriprotsesside analüüsi ja ümberkorraldamise metoodika üldskeem

IDEF0 ja ABC meetodite kombineerimine (joonis 14) võimaldab lahendada ühe kõige olulisema ülesande - analüüsida süsteemi funktsioonide täiuslikkust, selle täiustamise võimalusi, mis ei ole omane teistele meetoditele ja standarditele. ulatus.ABC-meetodi ühendamine võimaldab võrrelda olemasolevat struktuuri (nagu see on) ratsionaalse struktuuriga (nagu see peaks olema), kuna samu funktsioone saab rakendada erinevate struktuuridega (näiteks saate kombineerida sarnaseid funktsioone täitvaid osakondi ebaoluline erinevus või väike koormus).

Näide f konstrueerimisestCAD loomise protsessi funktsionaalne mudel on näidatud joonistel 15…18.

Joonis 15. CAD loomise protsessi funktsionaalne mudel (algus).
IDEF Esimese taseme 0-skeem.

Joonis 16. IDEF 0-diagrammi uuringuettevõte.

Joonis 17. IDEF 0-diagramm disain CAD.

Joonis 18. IDEF CAD projekti elluviimise 0-skeem.

2.3. Andmevoogude modelleerimine (protsessid - mudelid DFD , IDEF standard 1)

See metoodika (Gane/Sarsoni metoodika) põhineb analüüsitava IS-i mudeli konstrueerimisel – kavandatud või tegelikult olemasolevast. Vastavalt metoodikale on süsteemimudel määratletud kui andmevooskeemide (DFD või DFD) hierarhia, mis kirjeldavad teabe asünkroonset teisendamise protsessi alates selle sisestamisest süsteemi kuni selle kasutajale väljastamiseni. Hierarhia ülemiste tasandite skeemid (kontekstidiagrammid) määratlevad IS-i põhiprotsessid või alamsüsteemid väliste sisendite ja väljunditega. Need on üksikasjalikud madalama taseme diagrammide abil. See lagunemine jätkub, luues diagrammide mitmetasandilise hierarhia, kuni saavutatakse lagunemise tase, kus protsessid muutuvad elementaarseks ja neid on võimatu üksikasjalikumalt kirjeldada.

IDEF1 - simulatsioonimeetodinfovood süsteemi sees,võimaldades kuvada süsteemi struktuuri ehk selle elemente (olemite), nende omadusi (atribuute) ja nendevahelisi seoseid (suhteid). Modelleerimisprotsessi käigus saadud detailne informatsioon võimaldab tuvastada analüüsitava objekti "pudelikaelu" ning on aluseks otsuste langetamisel süsteemi ja infovoogude struktuuri parendamiseks ning õige infohalduspoliitika rakendamiseks.

Infoallikad (välised olemid) genereerivad infovooge (andmevoogusid), mis edastavad informatsiooni alamsüsteemidesse või protsessidesse. Need omakorda muudavad teavet ja genereerivad uusi vooge, mis edastavad teavet teistele protsessidele või alamsüsteemidele, andmesalvestusele või välistele üksustele - teabe tarbijatele. Seega on andmevooskeemide peamised komponendid:

välised üksused;

süsteemid/allsüsteemid;

protsessid;

andmesalvestusseadmed;

andmevoogusid.

2.3.1. Välised üksused

Väline üksus on materiaalne objekt või füüsiline isik, kes on teabe allikas või vastuvõtja, näiteks kliendid, töötajad, tarnijad, kliendid, ladu. Mõne objekti või süsteemi määratlemine välise entiteedina näitab, et see on väljaspool analüüsitava IS piire. Analüüsi käigus saab analüüsitava IS-i diagrammi sees vajadusel üle kanda mõned välised olemid või vastupidi, osa IS-i protsesse viia diagrammist väljapoole ja esitada välise entiteedina.

Välist olemit tähistab ruut (joonis 2.13), mis asub justkui diagrammi kohal ja heidab sellele varju, et eristada seda sümbolit teistest tähistustest:

Riis. 2.13. väline üksus

2.3.2. Süsteemid ja alamsüsteemid

Kompleksse IS-mudeli koostamisel saab seda kõige üldisemal kujul nn kontekstdiagrammil kujutada ühe süsteemina tervikuna või lagundada mitmeks alamsüsteemiks.

Alamsüsteem (või süsteem) kontekstidiagrammil on kujutatud järgmiselt (joonis 2.14).

Riis. 2.14. Alamsüsteem

Alamsüsteemi number on selle tuvastamiseks. Nime väljale sisestatakse alamsüsteemi nimi lause kujul koos teema ja vastavate definitsioonide ja täiendustega.

2.3.3. Protsessid

Protsess on sisendandmevoogude teisendamine väljunditeks vastavalt teatud algoritmile. Füüsiliselt saab protsessi realiseerida mitmeti: selleks võib olla sisenddokumente töötlev ja aruandeid väljastav organisatsiooni (osakonna) allüksus, programm, riistvaraliselt realiseeritav loogikaseade vms.

Protsessi andmevooskeemil on kujutatud joonisel 2.15 näidatud viisil.

Riis. 2.15. Protsess

Selle tuvastamiseks kasutatakse protsessi numbrit. Nimeväljale sisestatakse protsessi nimi lausena, millel on määramata kujul aktiivne ühetähenduslik tegusõna (arvutama, arvutama, kontrollima, määrama, looma, vastu võtma), millele järgneb akusatiivses käändes nimisõnad, näiteks:

"Sisesta kliendi andmed";

"Anna infot jooksvate kulude kohta";

"Kontrollige kliendi krediidivõimet."

Tegusõnade nagu "töötlema", "moderniseerima" või "muutma" kasutamine viitab tavaliselt protsessi mittemõistmisele ja nõuab edasist analüüsi.

Füüsilise juurutamise väljal olev teave näitab, millist organisatsiooni, programmi või riistvaraseadme osa protsess teostab.

2.3.4. Andmedraivid

Andmesalvestusseade on abstraktne seade teabe salvestamiseks, mida saab igal ajal draivi asetada ja mõne aja pärast eemaldada ning sisestamise ja väljavõtmise meetodid võivad olla mis tahes.

Andmesalvestusseadet saab füüsiliselt realiseerida mikrofiši, arhiivikapi sahtli, RAM-i tabeli, magnetkandjal faili jne kujul. Andmekogum andmevooskeemil on kujutatud joonisel 2.16 näidatud viisil.

Riis. 2.16. Andmekogu

Andmesalvestusseade on tähistatud tähe "D" ja suvalise numbriga. Draivi nimi valitakse kujundaja jaoks suurima teabesisu seisukohast.

Andmehoidla on üldjuhul tulevase andmebaasi prototüüp ja sinna salvestatud andmete kirjeldus tuleks siduda infomudeliga.

2.3.5. Andmevood

Andmevoog määratleb teabe, mis edastatakse mõne ühenduse kaudu allikast vastuvõtjale. Tegelik andmevoog võib olla kaabli kaudu kahe seadme vahel edastatav teave, posti teel saadetud kirjad, magnetlintid või disketid, ühest arvutist teise üle kantud jne.

Andmevoogu diagrammil kujutab joon, mis lõpeb noolega, mis näitab voo suunda (joonis 2.17). Igal andmevool on nimi, mis kajastab selle sisu.

Riis. 2.17. Andmevoog

2.3.6. Andmevoo diagrammide hierarhia loomine

DPD hierarhia loomise esimene samm on kontekstidiagrammide koostamine. Tavaliselt ehitatakse suhteliselt lihtsate IS-ide projekteerimisel üles ühtne tähetopoloogiaga kontekstdiagramm, mille keskmes on nn põhiprotsess, mis on ühendatud vastuvõtjate ja infoallikatega, mille kaudu kasutajad ja muud välised süsteemid süsteemiga suhtlevad. .

Kui keerulise süsteemi puhul piirdume ühe kontekstidiagrammiga, sisaldab see liiga palju teabeallikaid ja vastuvõtjaid, mida on raske tavaformaadis paberilehele järjestada, ja lisaks sellele teeb seda ainus põhiprotsess. ei paljasta hajutatud süsteemi struktuuri. Keerukuse märgid (konteksti mõttes) võivad olla järgmised:

suure hulga väliste üksuste olemasolu (kümme või enam);

süsteemi hajutatud olemus;

süsteemi multifunktsionaalsus koos juba väljakujunenud või kindlaksmääratud funktsioonide grupeerimisega eraldi alamsüsteemideks.

Keerulise IS jaoks koostatakse kontekstidiagrammide hierarhia. Samal ajal sisaldab tipptaseme kontekstdiagramm mitte ühte põhiprotsessi, vaid andmevoogudega ühendatud alamsüsteemide kogumit. Järgmise taseme kontekstidiagrammid kirjeldavad üksikasjalikult alamsüsteemide konteksti ja struktuuri.

Kontekstidiagrammide hierarhia määrab kavandatud IS-i peamiste funktsionaalsete alamsüsteemide interaktsiooni nii omavahel kui ka väliste sisend- ja väljundandmevoogude ning väliste objektidega (teabeallikad ja vastuvõtjad), millega IS suhtleb.

Kontekstidiagrammide väljatöötamine lahendab IS-i funktsionaalse struktuuri range määratlemise probleemi selle kavandamise kõige varasemas etapis, mis on eriti oluline keerukate multifunktsionaalsete süsteemide puhul, mille väljatöötamises osalevad erinevad organisatsioonid ja arendusmeeskonnad.

Pärast kontekstidiagrammide koostamist tuleks kontrollida saadud mudelit süsteemiobjektide algandmete täielikkuse ja objektide isolatsiooni suhtes (teabesidemete puudumine teiste objektidega).

Iga kontekstidiagrammidel esineva alamsüsteemi puhul tehakse selle üksikasjad DPD abil. Iga DPD protsessi saab omakorda üksikasjalikult kirjeldada DPD või minispetsifikatsiooni abil. Üksikasjade tegemisel tuleb järgida järgmisi reegleid:

tasakaalustusreegel – tähendab, et alamsüsteemi või protsessi detailiseerimisel võivad detailskeemil väliste andmeallikate/vastuvõtjatena olla ainult need komponendid (allsüsteemid, protsessid, välised olemid, andmesalved), millega põhidiagrammil oleval üksikasjalikul alamsüsteemil või protsessil on informatsiooni. lingid;

numeratsioonireegel – tähendab, et protsesside detailiseerimisel tuleks toetada nende hierarhilist nummerdamist. Näiteks protsessidele, mis kirjeldavad protsessi numbrit 12, määratakse numbrid 12.1, 12.2, 12.3 jne.

Minispetsifikatsioon (protsessi loogika kirjeldus) peaks sõnastama oma põhifunktsioonid nii, et edaspidi saaks projekti elluviija spetsialist neid täita või sobiva programmi välja töötada.

Minispetsifikatsioon on DPD hierarhia viimane tipp. Otsuse protsessi detaili lõpuleviimise ja minispetsifikatsiooni kasutamise kohta teeb analüütik järgmiste kriteeriumide alusel:

protsessil on suhteliselt väike arv sisend- ja väljundandmevooge (2-3 voogu);

võimalus kirjeldada andmete teisendamist protsessi poolt järjestikuse algoritmi kujul;

ühe loogilise funktsiooni täitmine sisendteabe väljundiks teisendamiseks;

võimalus kirjeldada protsessi loogikat väikese minispetsifikatsiooni abil (mitte rohkem kui 20-30 rida).

DPD hierarhia koostamisel tuleks protsesside detailistamise juurde asuda alles pärast kõigi voogude ja andmesalvede sisu kindlaksmääramist, mida kirjeldatakse andmestruktuuride abil. Andmestruktuurid on koostatud andmeelementidest ja võivad sisaldada alternatiive, tingimustingimusi ja iteratsioone. Tingimuslik esinemine tähendab, et seda komponenti ei pruugi struktuuris esineda. Alternatiivne tähendab, et struktuuri saab lisada ühe loetletud elementidest. Iteratsioon tähendab suvalise arvu elementide sisestamist määratud vahemikus. Iga andmeelemendi jaoks saab määrata selle tüübi (pidevad või diskreetsed andmed). Pidevate andmete puhul võib määrata mõõtühiku (kg, cm jne), väärtuste vahemiku, esituse täpsuse ja füüsilise kodeerimise vormi. Diskreetsete andmete jaoks võib määrata kehtivate väärtuste tabeli.

Pärast tervikliku süsteemimudeli koostamist tuleb see kontrollida (kontrollida täielikkust ja järjepidevust). Tervikmudelis peavad kõik selle objektid (allsüsteemid, protsessid, andmevood) olema üksikasjalikult kirjeldatud ja üksikasjalikud. Tuvastatud mittedetailseid objekte tuleks täpsustada, naastes eelmiste arendusetappide juurde. Järjepidevas mudelis peavad kõik andmevood ja andmesalved järgima teabe säilivuse reeglit: kõik kusagilt saabuvad andmed tuleb lugeda ja kõik loetud andmed tuleb kirjutada.

2.4. Andmete modelleerimine

IDEF1X - andmete modelleerimise ja relatsioonilise andmebaasi kujundamise meetod. See kuulub metoodikate tüüpi "üksus-suhe" ( ER-Entity-Relationship , ent olemeid ei mõisteta siin mitte reaalsete objektidena, vaid nende ühiste omadustega tüüpidena. Olemitevahelised suhted on keerulisemad. See võimaldab salvestada teavet abstraktse skeemi (semantilise mudeli) kujul, mis seob arvutisse salvestatud märgid reaalse maailmaga ja peegeldab seda tõetruult. Selline teabe salvestamise viis on suhteliselt sõltumatu, "neutraalne" ja võimaldab saada vastuse erinevatele kasutajate päringutele mudelis kirjeldatud keskkonna omaduste kohta. IDEF1X standard ilmus 1993. FIPS 184).

2.4.1. Barkeri juhtumi meetod

Andmemodelleerimise eesmärk on pakkuda IS-i arendajale kontseptuaalset andmebaasi skeemi ühe mudeli või mitme lokaalse mudeli kujul, mida saab suhteliselt lihtsalt vastendada mis tahes andmebaasisüsteemiga.

Kõige tavalisem andmemodelleerimise tööriist on olemisuhete diagrammid (ERD). Nende abil tehakse kindlaks ainevaldkonna jaoks olulised objektid (olemid), nende omadused (atribuudid) ja omavahelised seosed (lingid). ERD-sid kasutatakse otseselt relatsiooniandmebaaside kujundamiseks.

ERD-tähistus võttis esmakordselt kasutusele P. Chen ja arendas edasi Barker. Barkeri meetodit tutvustatakse autokaubandusettevõtte tegevuse modelleerimise näitel. Järgnevalt on toodud väljavõtted ettevõtte töötajatega tehtud intervjuust.

Peadirektor: üks peamisi kohustusi on autovara korrashoid. Ta peab teadma, kui palju autode eest makstakse ja millised on üldkulud. Selle teabe abil saab ta määrata madalama hinna, mille eest ta saaks selle eksemplari müüa. Lisaks vastutab ta müüjate eest ja peab teadma, kes mida müüb ja kui palju autosid igaüks neist müüs.

Müüja: Ta peab teadma, mis hinda küsida ja mis on alumine hind, millega tehingut teha saab. Lisaks vajab ta autode kohta põhiinfot: tootmisaasta, mark, mudel jne.

Administraator: Tema tööks on lepingute koostamine, mis nõuab teavet ostja, sõiduki ja müüja kohta, kuna just lepingud toovad müüjatele müügitasusid.

Esimene modelleerimise samm on intervjuust teabe hankimine ja olemite eraldamine.

Üksus - vaadeldava ainevaldkonna jaoks hädavajalik reaalne või väljamõeldud objekt, mille kohta soovitakse infot talletada (joonis 2.18).

Riis. 2.18. Olemi graafiline esitus

Igal olemil peab olema kordumatu identifikaator. Iga olemi eksemplar peab olema unikaalselt identifitseeritav ja eristuma kõigist teistest selle olemitüübi eksemplaridest. Igal olemil peavad olema teatud omadused:

igal olemil peab olema kordumatu nimi ja sama nime puhul peab alati kehtima sama tõlgendus. Sama tõlgendus ei kehti erinevate nimede puhul, välja arvatud juhul, kui tegemist on varjunimedega;

olemil on üks või mitu atribuuti, mis kuuluvad olemile või on päritud seose kaudu;

olemil on üks või mitu atribuuti, mis identifitseerivad üheselt iga olemi eksemplari;

igal olemil võib olla suvaline arv seoseid teiste mudelolemitega.

Viidates ülaltoodud intervjuukatkenditele, on selge, et peadirektoriga tuvastatavad üksused on mootorsõidukid ja müügimehed. Müüja hoolib autodest ja nende müügiga seotud andmetest. Administraatori jaoks on olulised ostjad, autod, müüjad ja lepingud. Selle põhjal eristatakse 4 olemit (auto, müüja, ostja, leping), mis on diagrammil kujutatud järgmiselt (joonis 2.19).

Riis. 2.19.

Järgmine modelleerimise samm on suhete tuvastamine.

Suhe - nimeline seos kahe üksuse vahel, mis on vaadeldava valdkonna jaoks oluline. Seos on olemite vaheline seos, milles reeglina seostatakse ühe olemi iga eksemplar, mida nimetatakse emaüksuseks, suvalise (sh null) arvu teise olemi eksemplaridega, mida nimetatakse alamolemiks, ja iga alamolemi eksemplar on seotud täpselt emaolemi ühe eksemplariga. Seega saab alamolemi eksemplar eksisteerida ainult siis, kui emaolemi olemasolu on olemas.

Lingile võib anda verbi grammatilise pöördega väljendatud nime ja panna see lingirea kõrvale. Iga kahe antud olemi vahelise seose nimi peab olema kordumatu, kuid mudeli suhtenimed ei pea olema kordumatud. Suhte nimi moodustatakse alati vanema vaatepunktist, seega saab lause moodustada ülemolemi nime, suhte nime, astmeväljendi ja alamolemi nime kombineerides.

Näiteks võib müüja suhet lepinguga väljendada järgmiselt:

müüjat saab premeerida 1 või enama lepingu eest;

lepingu peab algatama täpselt üks müüja.

Seotuse ja pühendumise aste on graafiliselt kujutatud järgmiselt (joonis 2.20).

Riis. 2.20.

Seega on 2 lauset, mis kirjeldavad müüja suhet lepinguga, graafiliselt järgmiselt (joonis 2.21).

Riis. 2.21.

Olles kirjeldanud ka teiste olemite seoseid, saame järgmise skeemi (joonis 2.22).

Riis. 2.22.

Viimane modelleerimise etapp on atribuudi tuvastamine.

Atribuut - üksuse mis tahes tunnus, mis on vaatlusaluse valdkonna jaoks oluline ja on mõeldud kvalifitseerimiseks, tuvastamiseks, klassifitseerimiseks, kvantitatiivseteks omadusteks või üksuse seisundi väljendamiseks. Atribuut tähistab reaalsete või abstraktsete objektide (inimesed, kohad, sündmused, seisundid, ideed, objektide paarid jne) kogumiga seotud omaduse või omaduse tüüpi. Atribuudi eksemplar on komplekti üksiku elemendi spetsiifiline omadus. Atribuudi eksemplar määratletakse iseloomuliku tüübi ja selle väärtusega, mida nimetatakse atribuudi väärtuseks. ER mudelis on atribuudid seotud konkreetsete olemitega. Seega peab olemi eksemplari seotud atribuudi jaoks olema üks määratletud väärtus.

Atribuut võib olla kohustuslik või valikuline (joonis 2.23). Kohustuslik tähendab, et atribuudil ei tohi olla nullväärtusi. Atribuut võib olla kirjeldav (st tavaline olemi deskriptor) või olla osa kordumatust identifikaatorist (esmane võti).

Unikaalne identifikaatoron atribuut või atribuutide ja/või suhete kogum, mis on loodud antud olemitüübi iga eksemplari unikaalseks tuvastamiseks. Täieliku identifitseerimise korral on antud olemitüübi iga eksemplar täielikult identifitseeritud oma võtmeatribuutide järgi, vastasel juhul kaasatakse selle identifitseerimisse ka teise emaolemi atribuudid (joonis 2.24).

Riis. 2.23.

Riis. 2.24.

Iga atribuut identifitseeritakse kordumatu nimega, mida väljendab nimisõnafraas, mis kirjeldab omadust, mida atribuut esindab. Atribuudid kuvatakse seotud olemiplokis olevate nimede loendina, kusjuures iga atribuut on eraldi real. Primaarvõtit määravad atribuudid paigutatakse loendi ülaossa ja on tähistatud märgiga "#".

Igal olemil peab olema vähemalt üks võimalik võti. Võimalik olemivõti on üks või mitu atribuuti, mille väärtused identifitseerivad iga olemi eksemplari kordumatult. Kui võimalikke võtmeid on mitu, määratakse üks neist esmaseks võtmeks ja ülejäänud alternatiivvõtmeteks.

Võttes arvesse olemasolevat teavet, täiendame eelnevalt koostatud diagrammi (joonis 2.25).

Lisaks loetletud põhistruktuuridele võib andmemudel sisaldada mitmeid täiendavaid struktuure.

Alamtüübid ja supertüübid:üks olem on üldistav mõiste sarnaste olemite rühma jaoks (joonis 2.26).

Üksteist välistavad suhted:iga olemi eksemplar osaleb ainult ühes suhtes üksteist välistavate suhete rühmast (joonis 2.27).

Riis. 2.25.

Riis. 2.26. Alamtüübid ja supertüübid

Riis. 2.27. Üksteist välistavad suhted

Rekursiivne link:olem võib olla seotud iseendaga (joonis 2.28).

Mitteülekantavad lingid:olemi eksemplari ei saa teisaldada ühest seoseksemplarist teise (joonis 2.29).

Riis. 2.28. Rekursiivne suhe

Riis. 2.29. Ümberpaigutamatu ühendus

2.4.2. Metoodika IDEF1

IDEF1 meetod, mille on välja töötanud T. Ramey, põhineb samuti P. Cheni lähenemisel ja võimaldab ehitada andmemudeli, mis on samaväärne relatsioonimudeliga kolmandal normaalkujul. Praeguseks on IDEF1 metoodika täiustamise põhjal loodud selle uus versioon IDEF1X metoodika. IDEF1X on loodud õppimise lihtsust ja automatiseerimist silmas pidades. IDEF1X diagramme kasutavad mitmed levinumad CASE-tööriistad (nt ERwin, Design/IDEF).

IDEF1X metoodikas olem on identifikaatorist sõltumatu või lihtsalt sõltumatu, kui iga olemi eksemplari saab unikaalselt identifitseerida ilma selle seost teiste olemitega määratlemata. Olemit nimetatakse identifikaatorist sõltuvaks või lihtsalt sõltuvaks, kui olemi eksemplari kordumatu identifitseerimine sõltub selle suhtest teise olemiga (joonis 2.30).

Riis. 2.30. Essentsid

Igale olemile määratakse kordumatu nimi ja number, mis eraldatakse kaldkriipsuga "/" ja asetatakse ploki kohale.

Seost saab täpsemalt määratleda, määrates astme või kardinaalsuse (alamolemi eksemplaride arv, mis võib eksisteerida iga ülemolemi eksemplari jaoks). IDEF1X-is saab väljendada järgmisi kardinaalsusi:

iga ülemolemi eksemplariga võib olla seotud null, üks või mitu alamolemi eksemplari;

igal ülemolemi eksemplaril peab olema sellega seotud vähemalt üks alamolemi eksemplar;

igal ülem-olemi eksemplaril ei tohi olla seotud rohkem kui üks alamolemi eksemplar;

iga emaolemi eksemplar on seotud teatud kindla arvu alamolemi eksemplaridega.

Kui alamolemi eksemplari määrab unikaalselt selle seos emaolemiga, nimetatakse seost tuvastavaks, vastasel juhul nimetatakse seda mitteidentifitseerivaks.

Suhet kujutab ema-olemi ja alamolemi vahele tõmmatud joon, mille rea lõpus on punkt alamolemi juures. Ühenduse võimsus on näidatud joonisel fig. 2,31 (vaikevõimsus - N).

Riis. 2.31. Suhtlemisjõud

Identifitseeriv seos ema- ja alamolemi vahel on näidatud pideva joonena (joonis 2.32). Identifitseerimissuhtes olev alamüksus on identiteedist sõltuv olem. Identifitseerimissuhtes olev emaüksus võib olla kas iseseisev või identifikaatorist sõltuv (selle määravad selle suhted teiste olemitega).

Riis. 2.32. Identifitseeriv link

Punktiirjoon kujutab mitteidentifitseerivat seost (joonis 2.33). Mitteidentifitseerivas suhtes olev alamüksus on identifikaatorist sõltumatu, välja arvatud juhul, kui see on ka mõnes tuvastavas suhtes olev alamüksus.

Riis. 2.33. Identifitseerimata suhe

Atribuudid kuvatakse olemiploki sees olevate nimede loendina. Primaarvõtit määravad atribuudid asetatakse loendi ülaossa ja eraldatakse teistest atribuutidest horisontaalse ribaga (joonis 2.34).

Riis. 2.34. Atribuudid ja esmased võtmed

Olemitel võivad olla ka võõrvõtmed (Foreign Key), mida saab kasutada primaarvõtme või mittevõtmeatribuudi osana või täielikult. Võõrvõtit esitatakse atribuutide nimede paigutamisega olemiploki sisse, millele järgnevad tähed FK sulgudes (joonis 2.35).

Riis. 2.35. Võõrvõtmete näited

2.5. Näide struktuurse lähenemise kasutamisest

2.5.1. Teemavaldkonna kirjeldus

See näide kasutab Yourdoni metoodikat, mis on rakendatud tööriistas Vantage Team Builder CASE.

Ainevaldkond on videoteegi töökirjeldus, mis võtab vastu klientidelt filmide päringuid ja klientide tagastatud linte. Taotlused vaatab läbi videoteegi administratsioon, kasutades infot klientide, filmide ja lintide kohta. See kontrollib ja värskendab laenutatud lintide loendit ning kontrollib raamatukogu liikmekirjeid. Administratsioon kontrollib ka lintide tagastamist, kasutades infot filmide, lintide ja laenutatud lintide nimekirja, mida uuendatakse. Filmitaotluste ja linditagastuse töötlemine hõlmab järgmist. Kui klient ei ole raamatukogu liige, ei ole kliendil laenuõigust. Vajaliku filmi olemasolul teavitab administratsioon klienti renditasust. Kui aga klient on oma olemasolevate lintide tagastamise tähtajast möödas, ei tohi ta uusi filme võtta. Lindi tagastamisel arvutab administratsioon üüri, millele lisanduvad viivised.

Videoteek saab tarnijatelt uusi linte. Uute lintide saabumisel raamatukokku salvestatakse nende kohta vajalik info. Teavet raamatukogu liikmesusest hoitakse eraldi lindi laenutusdokumentidest.

Raamatukogu juhtkond koostab regulaarselt teatud aja jooksul aruandeid raamatukogu liikmete, lintide tarnijate, teatud lintide laenutamise ja raamatukogu ostetud lintide kohta.

2.5.2. Projekti korraldamine

Kogu projekt on jagatud 4 faasi: analüüs, globaalne projekteerimine (süsteemiarhitektuuri disain), detailne projekteerimine ja juurutamine (programmeerimine).

Analüüsifaasis luuakse keskkonnamudel. Keskkonnamudeli koostamine hõlmab järgmist:

süsteemi käitumise analüüs (IS-i eesmärgi määramine, lähtekonteksti andmevooskeemi (DFD) koostamine ja sündmuste loendi maatriksi (ELM) genereerimine, kontekstidiagrammide koostamine);
andmeanalüüs (andmevoogude koosseisu määramine ja andmestruktuuri diagrammide (DSD) koostamine, globaalse andmemudeli konstrueerimine ER diagrammi kujul).

IS-i eesmärk määrab disainerite ja tellijate vahelise kokkuleppe tulevase IS-i eesmärgi osas, IS-i üldkirjelduse projekteerijatele endile ja IS-i piirid. Ülesanne fikseeritakse tekstikommentaarina kontekstiskeemi "null" protsessis.

Näiteks sel juhul on IP eesmärk sõnastatud järgmiselt: raamatukogu liikmete, filmide, laenutuste ja tarnijate andmebaasi pidamine. Samas peaks raamatukogu juhtkonnal olema võimalik oma ülesannete täitmiseks vastu võtta erinevat tüüpi aruandeid.

Enne kontekstuaalse DFD ehitamist on vaja analüüsida väliseid sündmusi (väliseid objekte), mis mõjutavad teegi toimimist. Need objektid suhtlevad IS-ga, vahetades sellega teavet.

Ainevaldkonna kirjeldusest järeldub, et raamatukogu protsessi on kaasatud järgmised inimrühmad: kliendid, tarnijad ja juhtkond. Need rühmad on välised objektid. Need mitte ainult ei suhtle süsteemiga, vaid määravad ka selle piirid ja on esialgsel kontekstuaalsel DFD-l kujutatud terminaatoritena (välised olemid).

Esialgne kontekstdiagramm on näidatud joonisel 2.42. Erinevalt Gane/Sarsoni tähistusest tähistatakse väliseid üksusi tavaliste ristkülikutega ja protsesse ringidega.

Riis. 2.42. Esialgne kontekstdiagramm

Sündmuste loend on üles ehitatud maatriksi (ELM) kujul ja kirjeldab väliste üksuste erinevaid tegevusi ja IS-i reaktsiooni neile. Need toimingud on välised sündmused, mis mõjutavad raamatukogu. On järgmist tüüpi sündmusi:

Lühend	Tüüp
	Tavaline kontroll
	tavalised andmed
	Tavaline juhtimine/andmed
	Vahejuhtimine
	Ajutised andmed
	Ajutine kontroll/andmed

Kõik toimingud on märgitud tavalisteks andmeteks. Need andmed on sündmused, mida IS tajub vahetult, näiteks kliendi aadressi muutus, mis tuleb kohe registreerida. Need kuvatakse DFD-s andmevoogude sisuna.

Sündmuste loendi maatriks näeb välja selline:

Kirjeldus	Tüüp	Reaktsioon
Klient soovib astuda raamatukogu liikmeks		Kliendi registreerimine raamatukogu liikmeks
Klient teatab aadressi muutusest		Muudetud kliendi aadressi registreerimine
Klient soovib filmilaenutust		Taotlege ülevaatust
Klient tagastab filmi		Tagasi registreerimine
Juhtkond annab uuele tarnijale volitused		Müüja registreerimine
Tarnija teatab aadressi muutusest		Muudetud tarnija aadressi registreerimine
Tarnija saadab filmi raamatukokku		Uue filmi hankimine
Juhtkond nõuab uut aruannet		Juhtkonnale nõutava aruande koostamine

Süsteemi käitumise funktsionaalse aspekti analüüsi lõpuleviimiseks koostatakse täielik kontekstdiagramm, sealhulgas nulltaseme diagramm. Samal ajal on "raamatukogu" protsess jaotatud 4 protsessiks, mis kajastavad raamatukogu peamisi haldustegevuse liike. Olemasolevad "abstraktsed" andmevood terminaatorite ja protsesside vahel muudetakse voogudeks, mis esindavad andmevahetust konkreetsemal tasemel. Sündmuste loend näitab, millised vood sellel tasemel eksisteerivad: iga loendi sündmus peab moodustama teatud voo (sündmus moodustab sisendvoo, reaktsioon moodustab väljundvoo). Ühe "abstraktse" niidi saab jagada rohkem kui üheks "betooniks" niidiks.

Voolud tipptaseme diagrammis	Voolub nulltaseme diagrammis
Info kliendilt	Kliendi andmed, renditaotlus
Info kliendile	Liikmekaart, Vasta renditaotlusele
Teave juhtkonnalt	Uue liikme aruande taotlus, uue tarnija, tarnija aruande taotlus, rendiaruande taotlus, filmi aruande taotlus
Juhtimisteave	Uue liikme aruanne, müüja aruanne, rendiaruanne, filmiaruanne
Teave tarnijalt	Müüja andmed, uued filmid

Joonisel 2.43 näidatud DFD-s on "teegi" andmesalv andmesalve globaalne või abstraktne esitus.

Süsteemi käitumise funktsionaalse aspekti analüüs annab aimu andmete vahetamisest ja transformatsioonist süsteemis. "Abstraktsete" andmevoogude ja "konkreetsete" andmevoogude seos nulltaseme diagrammil on väljendatud andmestruktuuri diagrammides (joonis 2.44).

Analüüsifaasis koostatakse globaalne andmemudel, mis esitatakse olemi-seoste diagrammi kujul (joonis 2.45).

Erinevat tüüpi diagrammide vahel on järgmised seosed.

ELM-DFD: sündmused - sisendvood, reaktsioonid - väljundvood
DFD-DSD: andmevood – tipptasemel andmestruktuurid
DFD-ERD: andmekogujad – ER diagrammid
DSD-ERD: madala taseme andmestruktuurid – olemi atribuudid

Arhitektuuri kavandamise etapis koostatakse teemamudel. Ainemudeli loomise protsess hõlmab järgmist:

süsteemi toimimise üksikasjalik kirjeldus;
kasutatud andmete edasine analüüs ja loogilise andmemudeli koostamine andmebaasi hilisemaks kujundamiseks;
kasutajaliidese struktuuri, vormide spetsifikatsiooni ja nende ilmumise järjekorra määramine;
andmevooskeemide ja sündmuste loetelu viimistlemine, interaktiivsete ja mitteinteraktiivsete valik madalama taseme protsesside hulgast, nende jaoks minispetsifikatsioonide määratlemine.

Riis. 2.43. Konteksti diagramm

Riis. 2.44. Andmestruktuuride diagramm

Arhitektuuri kujundamise tulemused on järgmised:

protsessi mudel (süsteemi arhitektuuri diagrammid (SAD) ja minispetsifikatsioonid struktureeritud keeles);
andmemudel (ERD ja ERD alamskeem);
kasutajaliidese mudel (protsesside klassifitseerimine interaktiivseteks ja mitteinteraktiivseteks funktsioonideks, vormide jada diagramm (FSD - Form Sequence Diagram), mis näitab, millised vormid ja millises järjekorras ilmuvad rakenduses. FSD fikseerib ekraanivormikutsete komplekti ja struktuuri. FSD diagrammid moodustavad hierarhia, mille tipus on alamsüsteemi realiseeriva rakenduse põhivorm.Teisel tasemel on vormid, mis realiseerivad SAD diagrammidel fikseeritud funktsionaalse struktuuri madalama tasandi protsesse.

Riis. 2.45. Olemi-suhete diagramm

Detailse projekteerimise etapis ehitatakse modulaarne mudel. Moodulmudeli all mõistetakse projekteeritava rakendatava süsteemi reaalset mudelit. Ehitusprotsess sisaldab:

andmebaasi mudeli täiustamine järgnevaks SQL-lausete genereerimiseks;
kasutajaliidese struktuuri viimistlemine;
kasutajaliidese ja äriloogika mudeli loogikat kajastavad plokkskeemid (Structure Charts Diagram – SCD) ning nende sidumine vormidega.

Detailse projekteerimise tulemused on järgmised:

protsessimudel (interaktiivsete ja mitteinteraktiivsete funktsioonide struktuuriskeemid);
andmemudel (rakenduste jaoks kõigi vajalike parameetrite määratlus ERD-s);
kasutajaliidese mudel (Form Sequence Diagram (FSD), mis näitab, millised vormid ja millises järjekorras ilmuvad rakenduses, iga vormi seos konkreetse struktuuriskeemi vahel, seos iga vormi ja ühe või mitme ERD üksuse vahel).

Rakendusfaasis koostatakse rakendusmudel. Ehitusprotsess sisaldab:

SQL-lausete genereerimine, mis määratlevad sihtandmebaasi struktuuri (tabelid, indeksid, terviklikkuse piirangud);
plokkskeemide (SCD) ja kujujärjestusskeemide (FSD) täiustamine, millele järgneb rakenduskoodi genereerimine.

Lähtuvalt andmevoogude analüüsist ja protsesside koosmõjust andmeladudega viiakse läbi alamsüsteemide lõplik jaotamine (oleks pidanud olema tehtud ja fikseeritud lähteülesandes nõuete sõnastamise etapis). Alamsüsteemide valikul tuleb juhinduda funktsionaalse ühenduvuse põhimõttest ja infosõltuvuse minimeerimise põhimõttest. Silmas tuleb pidada, et selliste allsüsteemi elementide nagu arendusjärgus protsessid ja andmed baasil tuleb luua iseseisvalt toimiv rakendus. Seevastu protsesside ja andmete grupeerimisel alamsüsteemidesse tuleb arvestada toote seadistamise nõuetega, kui need on sõnastatud analüüsietapis.

2.2 Infosüsteemi kontseptuaalse mudeli väljatöötamine.

Kontseptuaalne mudel kujutab objekte ja nende seoseid, täpsustamata, kuidas neid füüsiliselt salvestatakse. Seega on kontseptuaalne mudel sisuliselt domeenimudel. Kontseptuaalse mudeli kavandamisel tuleks andmed struktureerida ja nendevahelised seosed tuvastada, võtmata arvesse rakendusomadusi ja tõhususe probleeme.

töötlemine. Kontseptuaalse mudeli kujundamine põhineb reklaamiagentuuri ees seisvate ülesannete analüüsil. Kontseptuaalne mudel sisaldab vaatlusaluses ainevaldkonnas huvi pakkuvate ja andmeanalüüsi tulemusena tuvastatud objektide ja nende seoste kirjeldusi.

Vajaliku mudeli koostamiseks viisime kõik saadaolevad andmed kolmandale normaalvormile, mille tulemusena saime järgmised olemid:

roogade tüübid.

· Personal.

· Positsioonid.

· Püsikliendid.

· Tellimused.

Ehitame mudeli loogilisel tasemel (vt joonis 2). Jooniselt 2 on näha, et mudelis on lingid. Vaatleme neid üksikasjalikumalt:

Tabel "Toitude tüübid" ja tabel "Toidud" - üks-mitmele seos luuakse primaarvõtme "Kind code" abil;

Tabel "Ametikohad" ja tabel "Personal" - üks-mitmele seos luuakse primaarvõtme "Positsioonikood" abil;

Tabel "Road" ja tabel "Tellimused" - "Dish Code" primaarvõtme abil on loodud seos "üks-mitmele";

Tabel "Personal" ja tabel "Tellimused" - üks-mitmele seos luuakse primaarvõtme "Töötaja ID" abil;

Tabel "Püsikliendid" ja tabel "Tellimused" - üks-mitmele suhe luuakse primaarvõtme "Kliendi ID" abil.

Riis. 2. Kontseptuaalne andmemudel

2.3 Infosüsteemi loogilise mudeli väljatöötamine

Andmebaasidel ja nende loomise ja hooldamise tarkvaratööriistadel (DBMS) on mitmetasandiline arhitektuur, millest saab aimu jooniselt 1.

Skeem 1 – andmebaasi andmete mitmetasandiline esitus all

DBMS-i haldus

Nende andmebaaside esitusviisid on kontseptuaalsed, sisemised ja välised, mis vastavad sarnase eesmärgiga mudelitele.

Kontseptuaalne tasand vastab domeeniandmete integreeritud esitamise loogilisele aspektile. Kontseptuaalne mudel koosneb paljudest erinevat tüüpi andmetüüpidest, mis on struktureeritud vastavalt DBMS-i nõuetele andmebaasi loogilise struktuuri jaoks.

Sisekiht esindab andmete nõutavat korraldust salvestuskeskkonnas ja vastab andmete esituse füüsilisele aspektile. Sisemudel koosneb üksikutest kirjeeksemplaridest, mis on füüsiliselt salvestatud välisele andmekandjale.

Välimine kiht säilitab konkreetsete kasutajate nõutavate andmete privaatseid vaateid. Välismudel on kontseptuaalse mudeli alamhulk. Võimalik on väliste mudelite ristumine andmetega. Konkreetse rakenduse (ülesande) või kasutaja privaatne loogiline andmestruktuur vastab välisele andmebaasimudelile või alamskeemile. Väliste mudelite abil toetatakse autoriseeritud juurdepääsu rakenduste andmebaasi andmetele (rakenduses saadaolevate andmebaasi kontseptuaalsete mudeliandmete koostis ja struktuur on piiratud, samuti on seatud nende andmete lubatud töötlemise viisid: sisestamine, redigeerimine, kustutamine, otsing).

Andmebaasi projekteerimine seisneb omavahel ühendatud andmete kompleksi loomises. Joonisel 2 on tinglikult kuvatud andmebaasi kujundamise protsessi etapid.

Diagramm 2 – Andmebaasi kujundamise protsessi etapid

Andmebaasi kujundamise kõige olulisem etapp on ainevaldkonna infoloogilise (infoloogilise) mudeli väljatöötamine, mis ei ole DBMS-ile orienteeritud. Infooloogilises mudelis peegeldavad andmestruktuuride vahendid integreeritud kujul andmete koostist ja struktuuri ning infovajadusi.

Ainevaldkonna infoloogiline (infoloogiline) mudel kajastab ainevaldkonda infoobjektide kogumi ja nende struktuursete seoste kujul.

Üks-mitmele (1:M) seoses vastab üks teabe A eksemplar 0, 1 või enamale objekti B eksemplarile, kuid iga objekti B eksemplar on seotud mitte rohkem kui ühe objekti A eksemplariga.

1:M seose näide on teabeobjektide seos Perekonnanimi - Palk:

Perekonnanimi Palk

Andmebaas salvestab teavet kahemõõtmeliste tabelite kujul. Samuti saate importida ja linkida tabeleid teistest DBMS-i või tabelihaldussüsteemidest. Korraga saab avada 1024 lauda.

Vajalike andmebaasitabelite defineerimisel on vaja ette näha kolm esimest normaalvormi, s.o. viia läbi normaliseerimine.

Samu andmeid saab tabeliteks (seosteks) grupeerida erineval viisil, s.t. on võimalik organiseerida erinevaid omavahel seotud infoobjektide seoste komplekte. Atribuutide rühmitamine suhetes peab olema ratsionaalne, s.t. andmete dubleerimise minimeerimine ning nende töötlemise ja ajakohastamise protseduuride lihtsustamine.

Teatud seoste kogumil on paremad omadused andmete kaasamiseks, muutmiseks, kustutamiseks kui kõigil teistel võimalikel seoste kogumitel, kui see vastab suhete normaliseerimise nõuetele.

Seoste normaliseerimine on formaalne suhete (tabelite) moodustamise piirangute aparaat, mis võimaldab välistada dubleerimise, tagab andmebaasi salvestatute järjepidevuse ja vähendab tööjõukulusid andmebaasi hooldamiseks (sisestamiseks, parandamiseks).

E. Codd tõi välja kolm suhete normaalvormi ja pakkus välja mehhanismi, mis võimaldab mis tahes seose teisendada kolmandaks (kõige täiuslikumaks) normaalvormiks.

Esimene normaalne vorm. Seost nimetatakse normaliseeritud või taandatud esimeseks normaalkujuks, kui kõik selle atribuudid on lihtsad (edaspidi jagamatud). Relatsiooni teisendamine esimeseks normaalkujuks võib kaasa tuua seose atribuutide (väljade) arvu suurenemise ja võtme muutumise.

Teine normaalne vorm. Seoste teisele normaalvormile taandamise küsimuse käsitlemiseks on vaja anda selgitusi sellistele mõistetele nagu funktsionaalne sõltuvus ja täielik funktsionaalne sõltuvus.

Infoobjekti kirjeldavad atribuudid on loogiliselt seotud nende jaoks ühise võtmega, see seos on oma olemuselt atribuutide funktsionaalne sõltuvus.

Atribuutide funktsionaalne sõltuvus on sõltuvus, mille puhul ainult üks kirjeldava atribuudi väärtus vastab võtmeatribuudi teatud väärtusele teabeobjekti eksemplaris.

Selline funktsionaalse sõltuvuse definitsioon võimaldab eristada iseseisvaid infoobjekte, kui analüüsida kõiki ainevaldkonna detailide seoseid. Vaatleme näiteks joonisel 5 näidatud töötajate atribuutide funktsionaalsete sõltuvuste graafilist esitust, kus võtmeatribuut on tähistatud tärniga.

Joonis 1 - Detailide funktsionaalse sõltuvuse graafiline esitus

Liitvõtme puhul võetakse kasutusele funktsionaalselt täieliku sõltuvuse mõiste.

Mittevõtmeatribuutide funktsionaalne täielik sõltuvus seisneb selles, et iga võtmeta atribuut on funktsionaalselt võtmest sõltuv, kuid ei sõltu funktsionaalselt liitvõtme ühestki osast.

Seos on teisel normaalkujul, kui see on esimesel normaalkujul ja iga võtmeta atribuut on funktsionaalselt täielikult liitvõtmest sõltuv.

Kolmas tavavorm. Kolmanda normaalvormi mõiste põhineb mittetransitiivse sõltuvuse kontseptsioonil.

Transitiivset sõltuvust täheldatakse, kui üks kahest kirjeldavast atribuudist sõltub võtmest ja teine kirjeldav atribuut sõltub esimesest kirjeldavast atribuudist.

Seos on kolmandal normaalkujul, kui see on teisel normaalkujul ja iga võtmeta atribuut ei sõltu transitiivselt primaarvõtmest.

Kirjeldavate detailide transitiivse sõltuvuse kõrvaldamiseks on vaja algne infoobjekt “tükeldada”. Tükeldamise tulemusena eemaldatakse osa atribuute algsest infoobjektist ja lisatakse teistesse (võimalik, et vastloodud) infoobjektidesse.

Loodud andmebaas peaks täitma funktsioone organisatsiooni andmete väljastamise automatiseerimise huvides. Sellel peaks olema lihtne ja intuitiivne kasutajaliides, minimaalsed süsteeminõuded.

Töö eesmärk on luua andmebaas, mis sisaldab:

kiire uute andmete sisestamine;

juba sisestatud andmete salvestamine ja otsimine;

vajaliku arvu isiklike aruannete trükkimine.

Andmed on:

Täisnimi;

Sünnikuupäev;

Täidetud positsioon;

ametlik palk;

Reaalselt töötatud päevade arv kuus.

Arvestades ülaltoodud ülesandeid, saate kujundada andmebaasi põhitabelid.

Selleks kasutame Database Desktopi tööriistu.

Selles keskkonnas koostame kõik vajalikud tabelid arendatavale andmebaasile. Selle tabeli atribuudid on järgmised:

Perekonnanimi, Eesnimi, Isanimi, Vastuvõtmise kuupäev, Aadress, Telefon, Vahetused, Töölt puudumine, Hind, palk.

Saada oma head tööd teadmistebaasi on lihtne. Kasutage allolevat vormi

Üliõpilased, magistrandid, noored teadlased, kes kasutavad teadmistebaasi oma õpingutes ja töös, on teile väga tänulikud.

postitatud http://www.allbest.ru/

LOENG

Arvutidisaini CASE-tehnoloogiad

Plaan

- 1. CASE tehnoloogiad

1. CASE tehnoloogiad

postitatud http://www.allbest.ru/

kirjeldamise keerukus (üsna suur hulk funktsioone, protsesse, andmeelemente ja keerukaid seoseid nende vahel), mis nõuab andmete ja protsesside hoolikat modelleerimist ja analüüsi;

Tihedalt interakteeruvate komponentide (alamsüsteemide) komplekti olemasolu, millel on oma kohalikud ülesanded ja toimimiseesmärgid (näiteks tehingute töötlemise ja rutiinsete ülesannete lahendamisega seotud traditsioonilised rakendused ning ad hoc päringuid kasutavad analüütilise töötlemise rakendused (otsuste tugi). suure mahuga andmetele);

· otseste analoogide puudumine, mis piirab standardsete projektlahenduste ja rakendatud süsteemide kasutamise võimalust;

vajadus integreerida olemasolevaid ja äsja arendatud rakendusi;

toimimine heterogeenses keskkonnas mitmel riistvaraplatvormil;

üksikute arendajarühmade ebaühtlus ja heterogeensus oskuste taseme ja väljakujunenud traditsioonide osas teatud tööriistade kasutamisel;

Projekti oluline ajavahemik on ühelt poolt tingitud arendusmeeskonna piiratud võimalustest, teisalt aga kliendiorganisatsiooni mastaapsusest ja selle üksikute osakondade erinevast valmisolekust IS-i juurutamiseks.

Nõuete ebapiisav täpsustamine;

suutmatus avastada vigu projekteerimisotsuste tegemisel;

dokumentatsiooni halb kvaliteet, mis vähendab jõudlust;

pikk tsükkel ja kehvad testitulemused.

Teisest küljest on IC-arendajad olnud ajalooliselt viimased, kes kasutasid arvutitehnoloogiat oma töö kvaliteedi, töökindluse ja tootlikkuse parandamiseks ("kingsepp ilma kingadeta" fenomen).

· modulaarse ja struktureeritud programmeerimise kontseptsioonidele vastuvõtlike analüütikute ja programmeerijate koolitamine;

· arvuti jõudluse laialdane kasutuselevõtt ja pidev kasv, mis võimaldas kasutada tõhusaid graafilisi tööriistu ja automatiseerida enamikku projekteerimisetappe;

· võrgutehnoloogia juurutamine, mis võimaldas ühendada üksikute teostajate jõupingutused ühtseks projekteerimisprotsessiks, kasutades ühist andmebaasi, mis sisaldab projekti kohta vajalikku teavet.

CASE tehnoloogia on metoodikaToIS disain, samuti tööriistade komplekt, mis võimaldab visualiseerida projekteerimise protsessiAniya.

2. CASE tööriistad. Üldised omadused ja klassifikatsioon

arendaja teave vormistatud disain

Tavaliselt hõlmavad CASE-tööriistad mis tahes tarkvaratööriista, mis automatiseerivad teatud tarkvara elutsükli protsesse ja millel on järgmised peamised iseloomulikud omadused:

võimsad graafilised tööriistad IS kirjeldamiseks ja dokumenteerimiseks, mugava liidese pakkumine arendajaga ja tema loominguliste võimete arendamine;

· CASE-tööriistade üksikute komponentide integreerimine, mis tagab IS arendusprotsessi juhitavuse;

Spetsiaalselt organiseeritud projekti metaandmete hoidla (hoidla) kasutamine.

Integreeritud CASE-tööriist (või kogu tarkvara elutsüklit toetav tööriistade komplekt) sisaldab järgmisi komponente;

Repositoorium, mis on CASE tööriista aluseks. See peab tagama projekti ja selle üksikute komponentide versioonide salvestamise, erinevatelt arendajatelt teabe saamise sünkroonimise rühma arendamise ajal, metaandmete kontrolli täielikkuse ja järjepidevuse tagamiseks;

· graafilise analüüsi ja disaini tööriistad, mis võimaldavad luua ja redigeerida IS-mudeleid moodustavaid hierarhiliselt seotud diagramme (DFD, ERD jne);

· rakenduste arendustööriistad, sealhulgas 4GL keeled ja koodigeneraatorid;

konfiguratsioonihaldustööriistad;

dokumenteerimisvahendid;

testimisvahendid;

Projektijuhtimise tööriistad

ümberkujundamise tööriistad.

süsteemide ja andmebaaside rakendatavad metoodikad ja mudelid;

integreeritus DBMS-iga;

saadaolevad platvormid.

Tüüpide järgi klassifitseerimine langeb põhimõtteliselt kokku CASE-tööriistade komponentide koostisega ja sisaldab järgmisi põhitüüpe:

domeenimudelite koostamiseks ja analüüsimiseks mõeldud analüüsitööriistad (Suurtähe), (Design/IDEF (Meta Software), BPwin (Logic Works));

analüüsi- ja disainitööriistad (Middle CASE), mis toetavad levinumaid projekteerimismetoodikaid ja mida kasutatakse disaini spetsifikatsioonide loomiseks (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE .Analüütik (Makroprojekt)). Selliste tööriistade väljundiks on süsteemi komponentide ja liideste spetsifikatsioonid, süsteemi arhitektuur, algoritmid ja andmestruktuurid;

· andmebaasi kujundamise tööriistad, mis pakuvad andmete modelleerimist ja andmebaasi skeemi genereerimist (tavaliselt SQL-is) kõige levinumate DBMS-ide jaoks. Nende hulka kuuluvad ERwin (Logic Works), S-Designor (SDP) ja DataBase Designer (ORACLE). Andmebaasi kujundamise tööriistad sisalduvad ka tööriistades Vantage Team Builder, Designer/2000, Silverrun ja PRO-IV CASE;

· reengineeringu tööriistad, mis võimaldavad analüüsida programmikoode ja andmebaasiskeeme ning kujundada nende alusel erinevaid mudeleid ja disainispetsifikatsioone. Andmebaasiskeemide analüüs ja ERD genereerimise tööriistad sisalduvad Vantage Team Builderis, PRO-IV-s, Silverrunis, Designer/2000-s, ERwinis ja S-Designoris. Programmikoodi analüüsi valdkonnas on enim kasutusel objektorienteeritud CASE-tööriistad, mis pakuvad C++ programmide ümberkujundamist (Rational Rose (Rational Software), Object Team (Cayenne)).

Abistajate tüübid on järgmised:

· projekti planeerimise ja juhtimise tööriistad (SE Companion, Microsoft Project jne);

konfiguratsioonihaldustööriistad (PVCS (Intersolv));

Testimisvahendid (Quality Works (Segue tarkvara));

dokumenteerimisvahendid (SoDA (Rational Software)).

Praeguseks on Venemaa tarkvaraturul järgmised enim arenenud CASE-tööriistad:

· Vantage Team Builder (Westmount I-CASE);

Disainer/2000;

· CASE.Analüütik.

3. IS-i projekteerimise metoodika alused

Tarkvara elutsükli struktuur vastavalt ISO/IEC 12207 standardile põhineb kolmel protsesside rühmal:

tarkvara elutsükli põhiprotsessid (ost, tarnimine, arendus, käitamine, hooldus);

abiprotsessid, mis tagavad põhiprotsesside elluviimise (dokumentatsioon, konfiguratsioonihaldus, kvaliteedi tagamine, verifitseerimine, sertifitseerimine, hindamine, audit, probleemide lahendamine);

organisatsioonilised protsessid (projektijuhtimine, projekti infrastruktuuri loomine, elutsükli enda määratlemine, hindamine ja täiustamine, koolitus).

4. Struktuurne lähenemine IS CASE projekteerimisele vahenditega

Kõik levinumad struktuurse lähenemise metoodikad põhinevad mitmetel üldpõhimõtetel. Kasutatakse kahte järgmist põhiprintsiipi:

· "jaga ja valluta" põhimõte – keeruliste probleemide lahendamise põhimõte, jagades need paljudeks väiksemateks iseseisvateks ülesanneteks, mida on lihtne mõista ja lahendada;

· hierarhilise järjestamise põhimõte - põhimõte organiseerida probleemi koostisosad hierarhilisteks puustruktuurideks koos uute detailide lisamisega igal tasandil.

abstraktsiooni põhimõte - on tõsta esile süsteemi olulised aspektid ja juhtida tähelepanu ebaolulisest;

formaliseerimise põhimõte – on vajadus range metoodilise lähenemise järele probleemi lahendamisel;

järjepidevuse printsiip - on elementide kehtivus ja kooskõla;

Andmete struktureerimise põhimõte seisneb selles, et andmed peavad olema struktureeritud ja hierarhiliselt organiseeritud.

· SADT (Structured Analysis and Design Technique) mudelid ja vastavad funktsionaalskeemid;

· DFD (Data Flow Diagrams) andmevoogude diagrammid;

· ERD (Entity-Relationship Diagrams) diagrammid "entity-relationship".

IS-i projekteerimise etapis laiendatakse, täiustatakse ja täiendatakse skeemidega, mis kajastavad tarkvara struktuuri: tarkvara arhitektuur, programmide plokkskeemid ja ekraanivormi diagrammid.

Majutatud saidil Allbest.ru

Sarnased dokumendid

Infotehnoloogia arengu ajalugu. Klassifikatsioon, tarkvara tüübid. Infosüsteemide projekteerimise metoodikad ja tehnoloogiad. Nõuded metoodikale ja tehnoloogiale. Struktuurne lähenemine infosüsteemide projekteerimisele.

lõputöö, lisatud 02.07.2009

Infosüsteemide projekteerimise metoodika alused, nende elutsükli kontseptsioon. Põhilised elutsükli mudelid. SADT funktsionaalse modelleerimise metoodika. Funktsionaalse mudeli koostis. Andmete modelleerimine, juhtumikeskmiste iseloomustamine.

abstraktne, lisatud 28.05.2015

Andmebaasidel põhinevate infosüsteemide kujundamise tunnused. CASE tööriistade kasutamine ja äriprotsesside kirjeldamine BP-Winis. Kaasaegsete infosüsteemide kujundamise etapid, diagrammide tüübid ja veebilehe visuaalne esitus.

kursusetöö, lisatud 25.04.2012

Automatiseeritud infosüsteemide klassifikatsioon (AIS). AIS-i kujundamine laoarvestuse jaoks, kasutades Rational Rose CASE tööriista. Disaini lähenemisviisid, CASE tööriistade analüüs. Professionaalsele orienteeritud AIS-i tarkvara juurutamine.

kursusetöö, lisatud 03.06.2012

CASE-tööriistade kasutamine infosüsteemide loomise ja hooldamise protsesside toetamiseks. Diagrammide graafilise toimetaja, dokumenteerija ja projektiadministraatori ülesanded. IBM Rational Professional Bundle'i ja IBM Rational Rose'i põhifunktsioonid.

abstraktne, lisatud 30.05.2012

Automatiseeritud infosüsteemide elutsükkel. CASE tehnoloogiatel põhinevate automatiseeritud süsteemide projekteerimise metoodika alused. Analüüsi ja planeerimise etapp, automatiseeritud süsteemi ehitamine ja juurutamine. Kaskaad- ja spiraalmudel.

kursusetöö, lisatud 20.11.2010

Ladu ja zm_st robit infosüsteemide juurutamise etapis. Süsteemi projekteerimise tehnoloogia CASE meetodil. Por_vnyaln_ infosüsteemide omadused juhtimises ja DSS-is. Baasmudelite loomine. Infohaldussüsteemide määramine.

abstraktne, lisatud 03.09.2009

Automaatsed projekteerimissüsteemid. Automatiseeritud infosüsteemide projekteerimise tööriistade võrdlev analüüs. Ekspordi SQL-kood füüsilisse keskkonda ja täida andmebaas sisuga. Juhtumivahendite arenguetapid ja omadused.

kursusetöö, lisatud 14.11.2017

Infosüsteemide komponendid: definitsioon, korrelatsioon, varieeruvus, disaini lähenemise valik. Ettevõttesüsteemide ehitamise põhimõtted. Lokaalsete arvutussüsteemide ehitamise tehniliste lahenduste ülevaade. Infovoogude skeemid.

kursusetöö, lisatud 16.10.2012

CASE-tööriistade kontseptsioon kui tarkvaratööriistad, mis toetavad infosüsteemide (IS) loomise ja hooldamise protsesse. IDEF-tehnoloogiate omadused IS-i arendamiseks. IDEF0 tähistuse kirjeldus. Funktsionaalsete äriprotsesside mudelite väljatöötamine.

Föderaalne Haridusagentuur

Föderaalne kutsealase kõrghariduse õppeasutus “I.I. järgi nime saanud Tšuvaši osariigi ülikool. I.N. Uljanova»

Finants- ja Majandusinstituut

majandusteaduskond

Teema kokkuvõte: CASE-tehnoloogiad automatiseeritud infosüsteemide projekteerimiseks

Lõpetanud õpilane

Rühmad EK 22-06

Evgrafova I.A.

Kontrollis: Pavlova S.Yu.

Cheboksary 2007

Sissejuhatus………………………………………………………………..3

Infosüsteemi tarkvara elutsükkel……………………………………………………………………….5

RAD-tehnoloogiad prototüüpimise rakenduste jaoks……………7

· Tarkvaraarenduse struktuurne meetod……10

Kasutatud kirjandus…………………………………………..17

Sissejuhatus

Viimase kümnendi jooksul on tarkvaratehnikas välja kujunenud uus suund - CASE (Computer-Aided Software / System Engineering) - otseses tõlkes - infosüsteemide tarkvara arendamine arvuti toel (abiga). Praegu puudub CASE üldtunnustatud definitsioon, mõistet CASE kasutatakse väga laias tähenduses. Mõiste CASE algne tähendus, mis piirdus ainult tarkvara arendamise automatiseerimise küsimustega, on nüüdseks saanud uue tähenduse, hõlmates komplekssete automatiseeritud infosüsteemide arendamise protsessi tervikuna. Nüüd tähistab termin CASE-tools tarkvaratööriistu, mis toetavad IS-i loomise ja hooldamise protsesse, sealhulgas nõuete analüüsi ja formuleerimist, rakendustarkvara (rakenduste) ja andmebaaside kujundamist, koodi genereerimist, testimist, dokumenteerimist, kvaliteedi tagamist, konfiguratsioonihaldust ja projektijuhtimine ja muud protsessid. CASE tööriistad koos süsteemitarkvara ja riistvaraga moodustavad tervikliku AIS-i arenduskeskkonna.

CASE-tööriistad võimaldavad mitte ainult luua "õigeid" tooteid, vaid ka pakkuda "õiget" nende loomise protsessi. CASE-i põhieesmärk on eraldada tarkvara disain selle kodeerimisest ja järgnevatest arendusfaasidest, samuti varjata arendajate eest kõiki tarkvara arenduskeskkonna ja toimimise üksikasju. CASE tehnoloogiate kasutamisel muutuvad infosüsteemi kõik tarkvara elutsükli etapid (sellest tuleb pikemalt juttu allpool), kusjuures suurimad muutused on seotud analüüsi ja disaini etappidega. Enamik olemasolevaid CASE-tööriistu põhinevad struktuursetel (enamasti) või objektorienteeritud analüüsi- ja projekteerimismetoodikatel, kasutades spetsifikatsioone diagrammide või tekstide kujul, et kirjeldada väliseid nõudeid, seoseid süsteemimudelite vahel, süsteemi käitumise dünaamikat ja tarkvaraarhitektuure. Sellised metoodikad annavad kavandatud süsteemi range ja visuaalse kirjelduse, mis algab selle üldise ülevaatega ja seejärel üksikasjadega, omandades järjest suurema arvu tasemetega hierarhilise struktuuri. CASE-tehnoloogiaid kasutatakse edukalt peaaegu igat tüüpi tarkvarasüsteemide ehitamiseks, kuid neil on stabiilne positsioon järgmistes valdkondades:

♦ äri- ja kommertstarkvara arendamise tagamine, selle rakendusala massilisusest tulenevalt CASE-tehnoloogiate laialdane kasutamine, milles CASE-d kasutatakse mitte ainult tarkvara arendamiseks, vaid ka süsteemimudelite loomiseks, mis aitavad lahendada probleeme. strateegiline planeerimine, finantsjuhtimine, ettevõtete poliitika kujundamine, personali koolitamine jne (see suund on saanud oma nime – ärianalüüs);

♦ süsteemi- ja juhtimistarkvara arendamine. CASE-tehnoloogiate aktiivne kasutamine on seotud selle probleemi suure keerukusega ja sooviga tõsta töö efektiivsust.

CASE ei ole revolutsioon tarkvaratehnikas, vaid kogu tööriistatööstuse loomuliku evolutsioonilise arengu tulemus, mida varem nimetati instrumentaalseteks või tehnoloogilisteks. CASE-tehnoloogiad on algusest peale arenenud, et ületada 60ndate ja 70ndate konstruktsioonide projekteerimise metoodikate kasutamise piirangud. 20. sajandil (arusaadavuse keerukus, suur töömahukus ja kasutuskulu, raskused pmuudatuste tegemisel jne) tulenevalt nende automatiseerimisest ja abivahendite integreerimisest. Seega ei saa CASE tehnoloogiaid pidada iseseisvateks metoodikateks, need arendavad vaid struktuurseid metoodikaid ja muudavad nende rakendamist automatiseerimise kaudu efektiivsemaks.

Lisaks struktuursete metoodikate automatiseerimisele ja sellest tulenevalt võimalusele kasutada kaasaegseid süsteemi- ja tarkvaratehnika meetodeid, on CASE tööriistadel järgmised peamised eelised:

♦ parandada loodava tarkvara kvaliteeti automaatjuhtimise abil (eelkõige projektijuhtimine);

♦ võimaldavad lühikese ajaga luua tulevase süsteemi prototüübi, mis võimaldab varakult hinnata oodatavat tulemust;

♦ kiirendada projekteerimis- ja arendusprotsessi;

♦ vabastada arendaja rutiinsest tööst, võimaldades tal keskenduda täielikult arenduse loomingulisele osale;

♦ toetada arenduse arendamist ja hoidmist;

♦ Toetada arenduskomponentide taaskasutustehnoloogiaid.

CASE-tehnoloogia ja CASE-tööriistade ilmumisele eelnesid programmeerimismetoodika valdkonna uuringud. Programmeerimine omandas süstemaatilise lähenemise tunnused kõrgetasemeliste keelte, struktuursete ja modulaarsete programmeerimismeetodite, disainikeelte ja nende tugitööriistade, formaalsete ja mitteametlike keelte süsteeminõuete ja spetsifikatsioonide kirjeldamiseks jne arendamise ja rakendamisega. 70-80ndad. hakati praktikas rakendama struktuurset metoodikat, mis pakkus arendajatele rangeid formaliseeritud meetodeid AISi ja vastuvõetud tehniliste lahenduste kirjeldamiseks. See põhineb visuaalsel graafilisel tehnikal: diagramme ja diagramme kasutatakse erinevat tüüpi AIS-mudelite kirjeldamiseks. Struktuurianalüüsi tööriistade nähtavus ja rangus võimaldas süsteemi arendajatel ja tulevastel kasutajatel algusest peale mitteametlikult selle loomises osaleda, arutada ja kinnistada arusaamist peamistest tehnilistest lahendustest. Selle metoodika laialdane kasutamine ja selle soovituste järgimine kontakt-AIS-i väljatöötamisel oli aga üsna haruldane, kuna mitteautomaatse (käsitsi) arendusega on see praktiliselt võimatu. See aitas kaasa tarkvara ja riistvara eriklassi – CASE-tööriistade – tekkele, mis rakendavad AIS-i loomiseks ja hooldamiseks CASE-tehnoloogiat.

Tuleb mõista, et CASE-tööriistade edukas kasutamine on võimatu ilma nende tööriistade aluseks oleva tehnoloogia mõistmiseta. CASE tarkvaratööriistad on iseenesest vahendid infosüsteemide projekteerimise ja hooldamise protsesside automatiseerimiseks. Ilma IS-i projekteerimise metoodikat mõistmata on CASE-tööriistade kasutamine võimatu.

1. Infosüsteemi tarkvara elutsükkel

AIS-i projekteerimismetoodika üks põhikontseptsioone on selle tarkvara (LC-tarkvara) elutsükli kontseptsioon. Tarkvara elutsükkel on pidev protsess, mis algab hetkest, mil tehakse otsus selle loomise vajaduse kohta ja lõpeb selle täieliku tegevuse lõpetamise hetkel.

Tarkvara elutsükli struktuur põhineb kolmel protsesside rühmal:

♦ tarkvara elutsükli põhiprotsessid (ost, tarnimine, arendus, käitamine, hooldus);

♦ abiprotsessid, mis tagavad põhiprotsesside elluviimise (dokumentatsioon, konfiguratsioonihaldus, kvaliteedi tagamine, verifitseerimine, sertifitseerimine, hindamine, audit, probleemide lahendamine);

♦ organisatsioonilised protsessid (projektijuhtimine, projekti infrastruktuuri loomine, elutsükli enda määratlemine, hindamine ja täiustamine, koolitus).

Käitamine hõlmab tööd tarkvarakomponentide kasutuselevõtul, sh andmebaasi ja kasutaja tööjaamade seadistamine, operatiivdokumentatsiooni pakkumine, personali koolituse läbiviimine jne ning vahetu opereerimine, sh probleemide lokaliseerimine ja nende tekkepõhjuste kõrvaldamine, tarkvara muutmine süsteemisiseselt kehtestatud määrused, ettepanekute koostamine süsteemi parendamiseks, arendamiseks ja kaasajastamiseks.

Projektijuhtimine on seotud tööde planeerimise ja korraldamise, arendajameeskondade loomise ning teostatavate tööde ajastuse ja kvaliteedi jälgimisega.

Projekti tehniline ja organisatsiooniline tugi hõlmab projekti elluviimise meetodite ja vahendite valikut, vahearengu olekute kirjeldamise meetodite määratlemist, tarkvara testimise meetodite ja vahendite väljatöötamist, personali koolitust jne. Projekti kvaliteedi tagamine on seotud tarkvara verifitseerimise, kontrollimise ja testimise probleemid. Kontrollimine on protsess, mille käigus tehakse kindlaks, kas antud etapis saavutatud hetkeseis vastab selle etapi nõuetele. Valideerimine võimaldab hinnata arendusparameetrite vastavust esialgsetele nõuetele. Kontrollimine kattub testimisega, mille eesmärk on tuvastada erinevused tegelike ja oodatavate tulemuste vahel ning hinnata, kas tarkvara funktsioonid vastavad algsetele nõuetele. Projekti elluviimise protsessis on olulisel kohal üksikute komponentide ja kogu süsteemi kui terviku identifitseerimise, kirjeldamise ja konfiguratsiooni kontrollimise küsimused.

Olemasolevad olelusringi mudelid määravad arenduse käigus kindlaks etappide teostamise järjekorra, samuti etapist teise liikumise kriteeriumid. Selle kohaselt kasutatakse kõige laialdasemalt järgmist kolme olelustsükli mudelit:

♦ kaskaadmudel (1970-1980) - pakub üleminekut järgmisse etappi pärast eelmise etapi töö lõpetamist;

♦ lavastatud mudel vahepealse juhtimisega (1980-1985) - iteratiivne tarkvaraarenduse mudel, millel on etappidevahelised tagasisideahelad. Selle mudeli eeliseks on see, et etappidevahelised reguleerimised tagavad kosemudeliga võrreldes väiksema töömahukuse, kuid iga etapi eluiga pikeneb kogu arendusperioodi jooksul;

♦ spiraalmudel (1986-1990) – rõhutab elutsükli algetappe: nõuete analüüs, spetsifikatsiooni projekteerimine, eel- ja detailprojekteerimine. Nendel etappidel kontrollitakse tehniliste lahenduste teostatavust ja põhjendatakse prototüüpide loomisega. Iga spiraali pööre vastab tarkvaratoote fragmendi või versiooni loomise samm-sammult mudelile, mille põhjal määratakse projekti eesmärgid ja omadused, määratakse selle kvaliteet ja järgmise pöörde töö. spiraal on planeeritud. Nii süvendatakse ja konkretiseeritakse projekti detaile järjepidevalt ning selle tulemusena valitakse välja mõistlik variant, mis viiakse teostuseni.

Eksperdid märgivad spiraalmudeli järgmisi eeliseid:

♦ tarkvaratööriistade, mudelite ja prototüüpide kogumine ja taaskasutamine;

♦ keskenduda tarkvara arendamisele ja muutmisele selle kujundamise käigus;

♦ riski- ja kuluanalüüs projekteerimisprotsessis.

Tarkvaraarenduse tööstuse põhijooneks on keerukuse koondumine elutsükli algfaasidesse (analüüs, projekteerimine) ning järgnevate etappide keerukus ja töömahukus on suhteliselt madal. Veelgi enam, analüüsi- ja projekteerimisetappidel tehtud lahendamata probleemid ja vead põhjustavad järgmistes etappides keerulisi, sageli lahendamatuid probleeme ja viivad lõpuks kogu projekti läbikukkumiseni.

2. RAD - rakenduste prototüüpide loomise tehnoloogiad

Üheks võimalikuks lähenemiseks tarkvaraarendusele spiraalse elutsükli mudeli raames on viimasel ajal laialt levinud rakenduste kiirarenduse metoodika RAD (Rapid Application Development). See termin viitab tavaliselt tarkvaraarendusprotsessile, mis sisaldab kolme elementi:

♦ väike programmeerijate meeskond (2-10 inimest);

♦ lühike, kuid hoolikalt läbi töötatud tootmisgraafik (2 kuni 6 kuud);

♦ iteratiivne tsükkel, mille käigus arendajad, kui rakendus hakkab kuju võtma, taotlevad ja rakendavad tootes kliendiga suhtlemise kaudu saadud nõudeid.

Arendusmeeskond peaks koosnema professionaalidest, kellel on CASE-tööriistade abil analüüsi, disaini, koodi genereerimise ja tarkvara testimise kogemus. Meeskonnaliikmed peavad samuti suutma lõppkasutaja ettepanekuid töötavateks prototüüpideks muuta.

Tarkvara elutsükkel RAD metoodika järgi koosneb neljast faasist:

♦ nõuete analüüsi ja planeerimise etapid;

♦ projekteerimise etapid;

♦ ehitusetapid;

♦ rakendamise etapid.

Analüüsi ja nõuete planeerimise etapis määravad süsteemi kasutajad kindlaks funktsioonid, mida see peab täitma, tõstavad esile esmatähtsad, mis nõuavad eelkõige läbitöötamist, ning kirjeldavad teabevajadusi. Nõudeid määravad peamiselt kasutajad spetsialistide arendajate juhendamisel. Projekti ulatus on piiratud, iga järgneva etapi ajaraam määratakse kindlaks. Lisaks määratakse kindlaks selle projekti elluviimise võimalus kehtestatud rahastamisraamistikus, nendel riistvaradel jne. Selle etapi tulemuseks peaks olema tulevase AIS-i funktsioonide loetelu ja prioriteet, esialgsed funktsionaalsed ja infomudelid IS-ist.

Projekteerimisetapis osalevad mõned kasutajad spetsialistide arendajate juhendamisel süsteemi tehnilises projekteerimises. Töötavate rakenduste prototüüpide kiireks hankimiseks kasutatakse CASE tööriistu. Kasutajad nendega vahetult suheldes täpsustavad ja täiendavad süsteemile esitatavaid nõudeid, mida eelmises etapis ei tuvastatud. Süsteemi protsesse käsitletakse üksikasjalikumalt. Funktsionaalmudelit analüüsitakse ja vajadusel korrigeeritakse. Iga protsessi käsitletakse üksikasjalikult. Vajadusel luuakse igale elementaarsele protsessile osaline prototüüp: ekraan, dialoog, aruanne, mis kõrvaldab ebaselgused või ebaselgused. Määratakse andmetele juurdepääsu eristamise nõuded. Samas etapis määratakse kindlaks vajalike dokumentide komplekt.

Pärast protsesside koostise üksikasjalikku määratlemist hinnatakse arendatava süsteemi funktsionaalsete elementide arvu ja tehakse otsus jagada AIS alamsüsteemideks, mida saab üks arendajate meeskond RAD-projektidele vastuvõetava aja jooksul rakendada. - umbes 60-90 päeva. CASE-tööriistade abil jaotatakse projekt erinevate meeskondade vahel (funktsionaalne mudel on jagatud). Selle etapi tulemuseks peaks olema:

♦ süsteemi üldinfomudel;

♦ üksikute arendusmeeskondade poolt juurutatud süsteemi kui terviku ja alamsüsteemide funktsionaalsed mudelid;

♦ CASE-määratletud liidesed autonoomselt arendatud allsüsteemide vahel;

♦ konstrueeritud ekraanide, aruannete, dialoogide prototüüpe.

Kõik mudelid ja prototüübid tuleb hankida nende CASE tööriistade abil, mida hiljem süsteemi ehitamisel kasutatakse. See nõue on tingitud asjaolust, et traditsioonilise lähenemise korral võib projekti kohta teabe edastamisel etapist teise tekkida praktiliselt kontrollimatu andmemoonutus. Projekti puudutava teabe jaoks ühtse salvestuskeskkonna kasutamine väldib seda ohtu.

Erinevalt traditsioonilisest lähenemisviisist, mis kasutas spetsiifilisi prototüüpide loomise tööriistu, mis ei olnud mõeldud reaalsete rakenduste loomiseks, ja visati prototüübid kõrvale pärast seda, kui nad olid lõpetanud projekti ebaselguste kõrvaldamise ülesande, arendatakse RAD-lähenemises iga prototüüp tulevase süsteemi osaks. . Seega edastatakse järgmisse faasi täielikum ja kasulikum teave.

Ehitamisetapis toimub rakenduse enda kiire arendamine otse. Selles etapis loovad arendajad iteratiivselt reaalse süsteemi, mis põhineb eelmises etapis saadud mudelitel ja mittefunktsionaalsetel nõuetel. Programmikood genereeritakse osaliselt automaatsete generaatorite abil, mis saavad teavet otse CASE tööriistade hoidlast. Lõppkasutajad hindavad selles faasis saadud tulemusi ja teevad muudatusi, kui arendusprotsessi käigus süsteem ei vasta enam eelnevalt määratletud nõuetele. Süsteemi testimine toimub otse arendusprotsessis.

Pärast iga individuaalse arendusmeeskonna töö lõpetamist integreeritakse see süsteemi osa järk-järgult ülejäänud osaga, moodustatakse täielik programmikood, testitakse selle rakenduse osa ühist tööd ülejäänud osaga ja seejärel süsteem tervikuna testitakse. Süsteemi füüsiline projekteerimine on lõpetamisel:

♦ määratakse andmete levitamise vajadus;

♦ viiakse läbi andmete kasutamise analüüs;

♦ andmebaasi füüsiline kujundus;

♦ määratakse kindlaks nõuded riistvararessurssidele;

♦ selgitatakse välja võimalused tootlikkuse tõstmiseks;

♦ on lõpetamisel projekti dokumentatsiooni väljatöötamine. Etapi tulemuseks on valmis süsteem, mis vastab kõigile kokkulepitud nõuetele.

Juurutamise faasis viiakse läbi kasutajakoolitus, organisatsioonilised muudatused ning paralleelselt uue süsteemi kasutuselevõtuga töötatakse olemasoleva süsteemiga (kuni uue süsteemi täieliku rakendumiseni). Kuna ehitusetapp on suhteliselt lühike, tuleb planeerimist ja juurutamise ettevalmistamist alustada varakult, tavaliselt süsteemi projekteerimisetapis.

Ülaltoodud skeem AIS-i arendamiseks ei ole absoluutne. Võimalikud on erinevad variandid, olenevalt näiteks algtingimustest, milles arendust teostatakse: kas arendatakse täiesti uut süsteemi; kas viidi läbi organisatsiooni infoküsitlus ja kas on olemas selle tegevuse mudel; kas organisatsioonis on mingi AIS, mida saab kasutada esialgse prototüübina või tuleks integreerida arendatavaga jne.

Siiski tuleb märkida, et RAD-i metoodika, nagu iga teinegi, ei saa pretendeerida universaalsusele, see on hea eelkõige konkreetse kliendi jaoks välja töötatud suhteliselt väikeste projektide jaoks. Kui töötatakse välja standardsüsteem, mis ei ole valmistoode, vaid on standardsete komponentide kompleks, mis on tsentraalselt hooldatud, kohandatud tarkvara- ja riistvaraplatvormidele, DBMS-ile, telekommunikatsioonile, rakendusobjektide organisatsioonilistele ja majanduslikele omadustele ning integreeritud olemasolevate arendustega, projekt mõõdikud, nagu juhitavus ja kvaliteet, mis võivad vastuolus arendamise lihtsuse ja kiirusega. Sellised projektid nõuavad kõrget planeerimise taset ja ranget projekteerimisdistsipliini, eelnevalt kavandatud protokollide ja liideste ranget järgimist, mis vähendab arenduskiirust.

RAD-metoodika ei ole rakendatav keeruliste arvutusprogrammide, operatsioonisüsteemide või kosmoseaparaadi juhtimisprogrammide ehitamisel, s.o programmide puhul, mis nõuavad suure hulga (sadu tuhandeid ridu) unikaalse koodi kirjutamist.

Rakendused, millel puudub selgelt väljendunud liidese osa, mis selgelt määratleb süsteemi töö loogika (näiteks reaalajas rakendused) ja rakendused, mis mõjutavad inimeste ohutust (näiteks lennuki või tuumajaama juhtimine) on ei sobi RAD metoodikaga arendamiseks, kuna iteratiivne lähenemine eeldab, et paar esimest versiooni ei tööta kindlasti täielikult, mis on antud juhul välistatud. RAD-i metoodika põhiprintsiibid:

♦ rakenduste arendamine iteratsioonide teel;

♦ valikuline tööde täielik lõpetamine elutsükli igas etapis;

♦ kasutajate kohustuslik kaasamine AISi arendamisse;

♦ projekti terviklikkuse tagavate CASE tööriistade vajalik kasutamine;

♦ konfiguratsioonihalduse tööriistade kasutamine, mis hõlbustavad projekti muudatuste sisseviimist ja valmis süsteemi hooldamist;

♦ koodigeneraatorite vajalik kasutamine;

♦ prototüüpide kasutamine lõppkasutaja vajaduste paremaks mõistmiseks ja rahuldamiseks;

♦ arendusega samaaegselt teostatud projekti testimine ja arendus;

♦ arendustegevust juhib väike hästi juhitud professionaalide meeskond;

♦ süsteemi arenduse pädev juhtimine, töö selge planeerimine ja kontroll.

3. Tarkvaraarenduse struktuurne meetod

AIS-i arendamise struktuurse lähenemisviisi olemus seisneb selle lagunemises (jaotamises) automatiseeritud funktsioonideks: süsteem on jagatud funktsionaalseteks alamsüsteemideks, mis omakorda jagunevad alamfunktsioonideks, ülesanneteks jne. Jaotamisprotsess jätkub kuni konkreetsete protseduurideni. Samal ajal säilitab automatiseeritud süsteem tervikliku vaate, milles kõik komponendid on omavahel ühendatud. Süsteemi arendamisel alt üles, üksikutest ülesannetest kogu süsteemini, kaob terviklikkus, tekivad probleemid üksikute komponentide informatiivsel dokkimisel.

Kõik struktuurianalüüsi metoodikad põhinevad mitmetel üldpõhimõtetel, millest osa reguleerib töökorraldust elutsükli algfaasis ning osa kasutatakse töökorralduse soovituste väljatöötamisel. Kahe põhiprintsiibina kasutatakse järgmist: "jaga ja valluta" ja hierarhilise järjestuse põhimõte. Esimene on põhimõte lahendada keerulisi probleeme, jagades need paljudeks väiksemateks iseseisvateks probleemideks, mida on lihtsam mõista ja lahendada. Teine põhimõte deklareerib, et nende osade paigutus on samuti mõistmiseks hädavajalik. Probleemi mõistmise tase tõuseb järsult, kui selle osad esitatakse puulaadsete hierarhiliste struktuuridena, st süsteemist saab aru saada ja üles ehitada tasanditel, millest igaüks lisab uusi detaile.

Kahe tarkvaratehnika põhiprintsiibi valimine ei tähenda, et teised põhimõtted oleksid teisejärgulised, neist ühegi eiramine võib kaasa tuua ettearvamatuid tagajärgi (sh kogu projekti ebaõnnestumine). Vaatame mõningaid peamisi põhimõtteid.

1. Abstraktsiooni põhimõte - seisneb süsteemi aspektide esiletõstmises, mis on mõnelt positsioonilt olulised, ja abstraheerimises ebaolulistest, et esitada probleem lihtsal üldisel kujul.

2. Formaliseerimise põhimõte – seisneb vajaduses range metodoloogilise lähenemise järele probleemi lahendamisel.

3. "Varjamise" põhimõte - peita teavet, mis ei ole konkreetses etapis hädavajalik: iga osa "teab" ainult seda teavet, mida ta vajab.

4. Kontseptuaalse ühtsuse põhimõte – on järgida ühtset filosoofiat elutsükli kõikidel etappidel (struktuurianalüüs – konstruktsiooniprojekt – struktuurne programmeerimine – struktuuri testimine).

5. Täielikkuse põhimõte - on kontrollida üleliigsete elementide olemasolu.

6. Järjepidevuse põhimõte - on elementide kehtivus ja kooskõla.

7. Loogilise sõltumatuse põhimõte – keskenduda loogilisele disainile, et tagada sõltumatus füüsilisest disainist.

8. Andmete sõltumatuse põhimõte - seisneb selles, et andmemudeleid tuleb analüüsida ja kujundada sõltumatult nende loogilise töötlemise protsessidest, samuti nende füüsilisest struktuurist ja jaotusest.

9. Andmete struktureerimise põhimõte – on see, et andmed peavad olema struktureeritud ja hierarhiliselt organiseeritud.

10. Lõppkasutaja juurdepääsu põhimõte - on see, et kasutajal peab olema juurdepääs andmebaasile, mida ta saab kasutada otse (ilma programmeerimiseta).

Nende põhimõtete järgimine on vajalik töö korraldamisel elutsükli algfaasis, sõltumata arendatava tarkvara tüübist ja kasutatavatest metoodikatest. Kõigist põhimõtetest kui tervikust juhindudes on võimalik juba varasemates arenguetappides aru saada, milline saab olema loodav süsteem, avastada vigu ja puudujääke, mis omakorda hõlbustab tööd elutsükli järgmistel etappidel ja vähendada arenduskulusid.

♦ SADT (Structured Analysis and Design Technique) - mudelid ja nendega seotud funktsionaalsed diagrammid;

♦ DFD (Data Flow Diagrams) - andmevoo diagrammid;

♦ ERD (Entity-Relationship Diagrams) - "olemi-suhete" diagrammid;

♦ STD (State Trasition Diagrams) – oleku ülemineku diagrammid.

IS-i projekteerimise etapis laiendatakse, täiustatakse ja täiendatakse skeemidega, mis kajastavad tarkvara struktuuri: tarkvara arhitektuur, programmide plokkskeemid ja ekraanivormi diagrammid.

Loetletud mudelid koos annavad AIS-i täieliku kirjelduse, olenemata sellest, kas see on olemasolev või äsja välja töötatud. Diagrammide koosseis sõltub igal konkreetsel juhul süsteemi kirjelduse nõutavast täielikkusest.

Metoodika SADT

SADT metoodika töötas välja Douglas Ross, selle alusel töötati välja tuntud IDEFO (Icam Definition) metoodika, mis on põhiosa USA algatatud programmis Icam (Integration of Computer and Industrial Technologies). SADT metoodika on meetodite, reeglite ja protseduuride kogum, mis on loodud objekti funktsionaalse mudeli koostamiseks mis tahes ainevaldkonnas. SADT funktsionaalne mudel kuvab objekti funktsionaalse struktuuri, st selle sooritatavaid toiminguid ja nende toimingute vahelisi seoseid. Selle metoodika põhielemendid põhinevad järgmistel kontseptsioonidel:

♦ plokkide modelleerimise graafiline esitus. SADT diagrammi plokk- ja kaargraafika kuvab funktsiooni plokina ning sisend/väljundliideseid kujutavad vastavalt plokki sisenevad ja väljuvad kaared. Plokkide vastastikmõju kirjeldatakse "piiranguid" väljendavate liidesekaaride abil, mis omakorda määravad, millal ja kuidas funktsioone täidetakse ja juhitakse;

♦ rangus ja täpsus. SADT reeglite rakendamine nõuab piisavat rangust ja täpsust ilma analüütiku tegevusele liigseid piiranguid seadmata.

SADT reeglid hõlmavad järgmist:

♦ plokkide arvu piiramine igal lagunemistasemel (3-b plokkide reegel);

♦ diagrammide ühenduvus (plokkide arv);

♦ siltide ja nimede unikaalsus (dublikaatnimede puudumine);

♦ graafika (plokid ja kaared) süntaktilised reeglid;

♦ sisendite ja kontrollide eraldamine (andmete rolli määramise reegel);

♦ organisatsiooni eraldamine funktsioonist, st organisatsiooni struktuuri mõju välistamine funktsionaalsele mudelile.

SADT metoodika üks olulisemaid omadusi on mudelit kujutavate diagrammide loomisel järjest suureneva detailitaseme juurutamine.

Igal juhul võib iga alamfunktsioon sisaldada ainult neid elemente, mis sisalduvad algses funktsioonis. Lisaks ei saa mudel välja jätta ühtegi elementi, st nagu juba märgitud, pakuvad konteksti nn vanemplokk ja selle liidesed. Sellele ei saa midagi lisada ega sealt midagi eemaldada.

SADT-mudel on diagrammide seeria koos kaasasoleva dokumentatsiooniga, mis jagab keerulise objekti osadeks, mis on esitatud plokkidena. Iga põhiploki üksikasjad on näidatud plokkidena teistes diagrammides. Igas lagunemisetapis nimetatakse üldisemat diagrammi üksikasjalikuma diagrammi vanemaks.

Mõned kaared on kinnitatud diagrammiplokkidele mõlemas otsas, samas kui teistel on üks ots jäetud ühendamata. Ühendamata kaared vastavad põhiploki sisenditele, juhtelementidele ja väljunditele. Nende piirikaarede allika või sihtkoha leiate ainult põhidiagrammist. Kinnitamata otsad peavad vastama originaalskeemi kaaretele. Kõik piirikaared peavad jätkuma põhidiagrammil, et see oleks täielik ja ühtlane.

Nagu märgitud, näitavad mehhanismid (kaared alumisel küljel) vahendeid, mille abil funktsioone täidetakse. Mehhanismiks võib olla inimene, arvuti või mõni muu seade, mis aitab antud funktsiooni täita.

Andmevoogude (protsesside) modelleerimine

AIS-i funktsionaalsete nõuete modelleerimise peamised vahendid on andmevoo diagrammid (DFD: - Data Flow Diagrams). Nende abiga jaotatakse need nõuded funktsionaalseteks komponentideks (protsessideks) ja esitatakse andmevoogudega ühendatud võrguna. Selliste tööriistade peamine eesmärk on näidata, kuidas iga protsess muudab oma sisendid väljunditeks, ning paljastada nende protsesside vahelisi seoseid.

Vastavalt metoodikale on süsteemimudel määratletud kui andmevooskeemide (DFD või DFD) hierarhia, mis kirjeldab teabe asünkroonset teisendamise protsessi alates selle sisestamisest süsteemi kuni selle kasutajale väljastamiseni. Hierarhia ülemiste tasandite skeemid (kontekstidiagrammid) määratlevad IS-i põhiprotsessid või alamsüsteemid väliste sisendite ja väljunditega. Need on üksikasjalikud madalama taseme diagrammide abil. See lagunemine jätkub, luues diagrammide mitmetasandilise hierarhia, kuni saavutatakse selline lagunemise tase, kus protsessid muutuvad elementaarseks ja neid on võimatu üksikasjalikumalt kirjeldada.

♦ välised üksused;

♦ süsteemid/allsüsteemid;

♦ protsessid;

♦ andmesalvestusseadmed;

♦ andmevood.

Protsess on sisendandmevoogude teisendamine väljunditeks vastavalt teatud algoritmile. Füüsiliselt saab protsessi realiseerida mitmel viisil: see võib olla sisenddokumente töötlev ja aruandeid väljastav organisatsiooni (osakonna) allüksus, programm, riistvaraliselt realiseeritav loogiline seade jne. Erinevates tähistustes võib protsess olla kujutatud diagrammidel erineval viisil. Selle tuvastamiseks kasutatakse protsessi numbrit. Nimeväljale sisestatakse protsessi nimi lausena, millel on määramata kujul aktiivne ühetähenduslik tegusõna (arvutama, arvutama, kontrollima, määrama, looma, vastu võtma), millele järgneb akusatiivses käändes nimisõnad, näiteks:

♦ "Sisestage teave klientide kohta";

♦ “Andke teavet jooksvate kulude kohta”;

♦ "Kontrolli kliendi krediidivõimet".

Tegusõnade kasutamine nagu "töötlema", "moderniseerima" või "redigeeri" tähendab tavaliselt, et sellest protsessist ei ole piisavalt sügavat arusaamist ja see nõuab täiendavat analüüsi.

Viimasel ajal on kombeks kasutada ka füüsilist juurutusvälja, mille info näitab, milline organisatsiooni osakond, programm või riistvaraseade seda protsessi teostab.

Salvestus (andmedraiv) on abstraktne seade teabe salvestamiseks, mida saab igal ajal draivi paigutada ja mõne aja pärast välja otsida ning paigutamise ja otsingu meetodid võivad olla mis tahes.

Andmesalvestusseadet saab füüsiliselt realiseerida mikrofišina, arhiivikapi sahtlina, RAM-i tabelina, magnetkandjal failina jne. Andmesalvestusseadet tähistab D-täht ja suvaline number. Draivi nimi valitakse kujundaja jaoks suurima teabesisu seisukohast.

Andmedraiv on üldjuhul tulevase andmebaasi prototüüp ning sinna salvestatud andmete kirjeldus tuleks siduda infomudeliga. Andmevoog määratleb teabe, mis edastatakse mõne ühenduse kaudu allikast vastuvõtjale. Tegelik andmevoog võib olla info, mis edastatakse kaabli kaudu kahe seadme vahel, saadetakse posti, kirjade, magnetlintide või diskettidega, edastatakse ühest arvutist teise jne.

Andmevoogu diagrammil kujutab joon, mis lõpeb suunda näitava noolega. Igal andmevool on nimi, mis kajastab selle sisu.

DFD hierarhia loomise esimene samm on kontekstidiagrammide koostamine. Tavaliselt ehitatakse suhteliselt lihtsa AIS-i projitseerimisel üles üks tähetopoloogiaga kontekstdiagramm, mille keskmes on nn põhiprotsess, mis on ühendatud vastuvõtjate ja teabeallikatega, mille kaudu kasutajad ja muud välised süsteemid suhtlevad süsteem. Keerulise AIS-i jaoks koostatakse kontekstidiagrammide hierarhia. Samal ajal sisaldab tipptaseme kontekstdiagramm mitte ühte põhiprotsessi, vaid andmevoogudega ühendatud alamsüsteemide kogumit. Järgmise taseme kontekstidiagrammid kirjeldavad üksikasjalikult alamsüsteemide konteksti ja struktuuri.

Kontekstidiagrammide hierarhia määrab kavandatud AIS-i peamiste funktsionaalsete alamsüsteemide interaktsiooni nii omavahel kui ka väliste sisend- ja väljundandmevoogudega ning väliste objektidega (teabeallikad ja vastuvõtjad), millega AIS suhtleb.

Kontekstidiagrammide väljatöötamine lahendab AIS-i funktsionaalse struktuuri range määratlemise probleemi selle kavandamise kõige varasemas etapis, mis on eriti oluline keerukate multifunktsionaalsete süsteemide puhul, mille väljatöötamises osalevad erinevad organisatsioonid ja arendusmeeskonnad.

Pärast kontekstidiagrammide koostamist tuleks kontrollida saadud mudelit süsteemiobjektide algandmete täielikkuse ja objektide isolatsiooni suhtes (teabesidemete puudumine teiste objektidega). Iga kontekstidiagrammidel oleva alamsüsteemi kohta on see üksikasjalikult kirjeldatud DFD abil. Iga protsessi DFD-s saab omakorda üksikasjalikult kirjeldada DFD või minispetsifikatsiooni abil. Üksikasjade tegemisel tuleb järgida järgmisi reegleid:

♦ tasakaalustusreegel – tähendab, et alamsüsteemi või protsessi detailiseerimisel võivad detailskeemil andmete väliste allikate/vastuvõtjatena olla ainult need komponendid (allsüsteemid, protsessid, välised olemid, andmeakumulaatorid), millega detailne alamsüsteem või protsess põhidiagrammil on infolingid ;

♦ nummerdamisreegel – tähendab, et protsesside detailiseerimisel tuleks toetada nende hierarhilist nummerdamist. Näiteks protsessidele, mis kirjeldavad protsessi numbrit 12, määratakse numbrid 12.1, 12.2, 12.3 jne.

Minispetsifikatsioon (protsessi loogika kirjeldus) peaks sõnastama oma põhifunktsioonid nii, et edaspidi saaks projekti elluviija spetsialist neid täita või sobiva programmi välja töötada.

Minispetsifikatsioon on DFD hierarhia viimane tipp. Otsuse protsessi detaili lõpuleviimise ja minispetsifikatsiooni kasutamise kohta teeb analüütik järgmiste kriteeriumide alusel:

♦ protsessil on suhteliselt väike arv sisend- ja väljundandmevooge (2-3 voogu);

♦ võimalus kirjeldada andmete teisendamist protsessi poolt järjestikuse algoritmi kujul;

♦ ainsa loogilise funktsiooni täitmine sisendteabe teisendamiseks väljundinformatsiooniks;

♦ võimalus kirjeldada protsessi loogikat väikese mahu (mitte rohkem kui 20-30 rida) minispetsifikatsiooni abil.

DFD hierarhia koostamisel tuleks protsesside detailistamise juurde asuda alles pärast kõigi voogude ja andmehoidlate sisu kindlaksmääramist, mida kirjeldatakse andmestruktuuride abil. Andmestruktuurid on koostatud andmeelementidest ja võivad sisaldada alternatiive, tingimustingimusi ja iteratsioone. Tingimuslik esinemine tähendab, et seda komponenti ei pruugi struktuuris esineda. Alternatiivne tähendab, et struktuuri saab lisada ühe loetletud elementidest. Iteratsioon tähendab suvalise arvu elementide sisestamist määratud vahemikus. Iga andmeelemendi jaoks saab määrata selle tüübi (pidevad või diskreetsed andmed). Pidevate andmete puhul võib määrata mõõtühiku (kg, cm jne), väärtuste vahemiku, esituse täpsuse ja füüsilise kodeeringu vormi. Diskreetsete andmete jaoks võib määrata kehtivate väärtuste tabeli.

Pärast tervikliku süsteemimudeli koostamist tuleb see kontrollida. Tervikmudelis peavad kõik selle objektid (allsüsteemid, protsessid, andmevood) olema üksikasjalikult kirjeldatud ja üksikasjalikud. Tuvastatud mittedetailseid objekte tuleks täpsustada, naastes eelmiste arendusetappide juurde. Järjepidevas mudelis peavad kõik andmevood ja andmesalved järgima teabe säilivuse reeglit: kõik kusagilt saabuvad andmed tuleb lugeda ja kõik loetud andmed tuleb kirjutada.

Andmete modelleerimine

Andmete modelleerimise eesmärk on pakkuda AIS-i arendajale kontseptuaalset andmebaasi skeemi ühe mudeli või mitme kohaliku mudeli kujul, mida saab suhteliselt hõlpsalt vastendada mis tahes andmebaasisüsteemiga.

Kõige tavalisem andmemodelleerimise tööriist on olemi-relatsiooniskeemid (ERD). Nende abil tehakse kindlaks ainevaldkonna jaoks olulised objektid (olemid), nende omadused (atribuudid) ja omavahelised seosed (lingid). ERD-sid kasutatakse otseselt relatsiooniandmebaaside kujundamiseks (vt ptk 2.2).

ERD-tähistus võttis esmakordselt kasutusele P. Chen ja arendas edasi Barker.

Metoodika IDEF 1

IDEF1 meetod, mille on välja töötanud T. Ramey, põhineb samuti P. Cheni lähenemisel ja võimaldab ehitada andmemudeli, mis on samaväärne relatsioonimudeliga kolmandal normaalkujul. Praeguseks on IDEF1 metoodika täiustamise põhjal loodud selle uus versioon IDEF1X metoodika. IDEF1X on loodud õppimise lihtsust ja automatiseerimist silmas pidades. IDEF IX diagramme kasutavad mitmed levinud CASE-tööriistad (nt ERWin, Design/IDEF).

Viited

Fedotova D.E. CASE - tehnoloogiad: õpik - M: Hotline - Telecom, 2007

Trofimov V.E., Lobatševa I.N. Infosüsteemid majanduses - M: Unity-Dana, 2008

· Baldin N.V., Utkin V.B. Infosüsteemid ja tehnoloogiad majanduses - M: Ühtsus, 2007

Titorenko T.A. Automatiseeritud infotehnoloogiad majanduses - M: Ühtsus, 2006

Baranovskaja T.P., Loiko V.I., Semenov M.I., Trubilin I.T. Automatiseeritud infotehnoloogiad majanduses - M: Rahandus ja statistika, 2006

Infosüsteemide projekteerimise ja arendamise protsesside automatiseerimiseks 1970. ja 1980. aastatel kasutati laialdaselt struktuurset metoodikat, mis tähendab formaliseeritud meetodite kasutamist arendatava süsteemi kirjeldamisel ja kasutusele võetud tehnilistel lahendustel. Samal ajal kasutati graafilisi vahendeid erinevate infosüsteemide mudelite kirjeldamiseks diagrammide ja diagrammide abil. See oli üks põhjusi CASE-tööriistadeks nimetatavate tarkvara ja tehnoloogiliste tööriistade tekkeks ja nende juurutamiseks CASE-tehnoloogiateks infosüsteemide loomiseks ja hooldamiseks.

Mõistet CASE (Computer Aided Software/System Engineering) kasutatakse väga laias tähenduses. Mõiste CASE algne tähendus piirdus tarkvaraarenduse automatiseerimise küsimustega. See mõiste on nüüdseks saanud laiema tähenduse, tähenduse infosüsteemide arenduse automatiseerimine.

JUHTUM- rajatised on tarkvaratööriistad, mis toetavad infosüsteemide loomise ja/või hooldamise protsesse, nagu: nõuete analüüs ja sõnastamine, andmebaaside ja rakenduste kujundamine, koodi genereerimine, testimine, kvaliteedi tagamine, konfigureerimine ja projektijuhtimine.

JUHTUM- süsteem saab defineerida kui CASE-tööriistade komplekti, millel on konkreetne funktsionaalne eesmärk ja mida rakendatakse ühes tarkvaratootes.

JUHTUM- tehnoloogia on komplekssete süsteemide analüüsi, projekteerimise, arendamise ja hooldamise metoodikate kogum ning seda toetab omavahel ühendatud automatiseerimistööriistade komplekt.

JUHTUM- tööstuseleühendab sadu ettevõtteid ja erinevate tegevusaladega ettevõtteid. Peaaegu kõik tõsised välismaised tarkvaraprojektid viiakse ellu CASE-tööriistade abil ning levitatud pakettide koguarv ületab 500 nimetust.

esmane eesmärk JUHTUM -süsteemid ja vahendid on tarkvara disaini eraldamine selle kodeerimisest ja järgnevatest arendusetappidest (testimine, dokumenteerimine jne), samuti kogu tarkvarasüsteemide loomise protsessi automatiseerimine või inseneritöö(inglise keelest engineering - development).

Kaasaegsed CASE tööriistad toetavad erinevaid infosüsteemide projekteerimise tehnoloogiaid: lihtsatest analüüsi- ja dokumenteerimisvahenditest kuni täismahuliste automatiseerimisvahenditeni, mis katavad kogu tarkvara elutsükli.

IS arenduse kõige aeganõudvamad etapid on analüüsi ja projekteerimise etapid, mille käigus tagavad CASE-tööriistad tehniliste otsuste kvaliteedi ja projektdokumentatsiooni koostamise. Samal ajal mängivad olulist rolli teabe visuaalse esitamise meetodid. See hõlmab struktuursete või muude diagrammide koostamist reaalajas, mitmekesise värvipaleti kasutamist ja süntaktiliste reeglite täielikku kontrollimist. Graafilise domeeni modelleerimise tööriistad võimaldavad arendajatel olemasolevat infosüsteemi visuaalselt uurida, seda vastavalt eesmärkidele ja olemasolevatele piirangutele ümber ehitada.

СASE-tööriistad on iga IS-projekti aluseks. Metoodikat rakendatakse spetsiifiliste tehnoloogiate ja neid toetavate standardite, metoodikate ja vahendite kaudu, mis tagavad infosüsteemide elutsükli protsesside rakendamise.

CASE-tööriistade iseloomulikud omadused:

- Ühtne graafiline keel. CASE-tehnoloogiad pakuvad kõigile projektis osalejatele, sealhulgas klientidele, ühtset ranget, visuaalset ja intuitiivset graafilist keelt, mis võimaldab saada nähtavaid komponente lihtsa ja selge struktuuriga. Samas on programmid esitletud kahemõõtmeliste diagrammidena (lihtsam kasutada kui mitmeleheküljelisi kirjeldusi), mis võimaldavad kliendil arendusprotsessis osaleda ning arendajatel suhelda aineekspertidega, eraldada süsteemianalüütikute tegevused, disainerid ja programmeerijad, hõlbustades neil projekti kaitsmist juhtkonna ees, samuti hõlbustades süsteemi hooldamist ja muutmist.

- Ühe projekti andmebaas. CASE-tehnoloogia aluseks on projekti andmebaasi (repositooriumi) kasutamine kogu projekti kohta käiva teabe salvestamiseks, mida saab vastavalt nende juurdepääsuõigustele arendajate vahel jagada. Hoidla sisu ei sisalda mitte ainult erinevat tüüpi teabeobjekte, vaid ka nende komponentide vahelisi seoseid, samuti nende komponentide rakendamise või töötlemise reegleid. Repositooriumis saab salvestada erinevat tüüpi objekte: struktuuriskeeme, ekraani- ja menüüde määratlusi, aruannete kujundusi, andmete kirjeldusi ja töötlemise loogikat, aga ka andmemudeleid, korraldust ja töötlemist, lähtekoode, andmeelemente jne.

- fondide integreerimine. Repositooriumil on CASE-tööriistad integreeritud ja süsteemiinfot jagatakse arendajate vahel. Samas tagavad hoidla võimalused mitmel integratsioonitasemel: ühine kasutajaliides kõikidele tööriistadele, andmeedastus tööriistade vahel, arendusetappide integreerimine ühtse süsteemi kaudu elutsükli faaside kujutamiseks, andmete ja tööriistade ülekanne erinevate platvormide vahel. .

- Koostööarenduse ja projektijuhtimise tugi. CASE-tehnoloogia toetab projekti rühmaarendust, pakkudes võimalust töötada võrgus, eksportida ja importida projekti mis tahes fragmente nende arendamiseks ja / või muutmiseks, samuti planeerimist, kontrolli, juhtimist ja interaktsiooni, see tähendab, projektide väljatöötamise ja hooldamise protsessis vajalikud funktsioonid. Neid funktsioone rakendatakse ka hoidla baasil. Eelkõige saab hoidla kaudu teostada turvakontrolli (piirangud ja juurdepääsuõigused), versioonide ja muudatuste juhtimist jne.

- Prototüüpimine. CASE-tehnoloogia võimaldab kiiresti ehitada tulevase süsteemi skeeme (prototüüpe), mis võimaldab kliendil juba varajases arendusetapis hinnata, kas see talle sobib ja kui vastuvõetav on see tulevastele kasutajatele.

- Dokumendi genereerimine. Kogu projekti dokumentatsioon genereeritakse hoidla alusel automaatselt (reeglina vastavalt kehtivate standardite nõuetele). CASE-tehnoloogia vaieldamatu eelis on see, et dokumentatsioon vastab alati asjade hetkeseisule, kuna kõik projekti muudatused kajastuvad automaatselt hoidlas (on teada, et tarkvaraarenduse traditsiooniliste lähenemisviiside korral on dokumentatsioon parimal juhul hiline, ja mitmeid modifikatsioone ei leidu repositooriumist üldse). tema peegeldus).

- Projekti kinnitamine. CASE-tehnoloogia tagab projekti terviklikkuse ja järjepidevuse automaatse kontrolli ja kontrolli arenduse varases staadiumis, mis mõjutab arenduse edukust tervikuna.

- Automaatne koodi genereerimine. Programmikoodi genereerimine toimub hoidla baasil ja see võimaldab teil automaatselt ehitada kuni 85–90% kõrgetasemeliste keelte tekstidest.

- Hooldus ja ümberehitus. Süsteemi hooldust CASE-tehnoloogia raames iseloomustab projekti, mitte programmikoodide hooldus. Reengineeringu tööriistad võimaldavad luua selle koodidest süsteemimudeli ja integreerida saadud mudelid projekti, uuendada automaatselt dokumentatsiooni koodide muutumisel, automaatselt muuta spetsifikatsioone koodide redigeerimisel jne.

Programmi arendamine algab mõne süsteemi esialgse versiooniga. Selline võimalus võib olla spetsiaalselt välja töötatud prototüüp või vananenud süsteem. Viimasel juhul kasutatakse tarkvarasüsteemi teadmiste taastamiseks nende hilisemaks kasutamiseks ümberarendust - ümberkujundamist.

Taasarendus taandub tarkvarasüsteemi esialgse mudeli loomisele, uurides selle programmikoode. Kui teil on mudel, saate seda täiustada ja seejärel uuesti arenduse juurde liikuda. Üks seda tüüpi tuntumaid põhimõtteid on pöördprojekteerimise põhimõte (Round Trip Engineering (RTE)).

Kaasaegsed CASE-süsteemid pakuvad nii esmast kui ka ümberarendust, mis kiirendab oluliselt rakenduste väljatöötamist ja parandab nende kvaliteeti.

Praegu on CASE-tööriistadele esitatavate muude nõuete hulgas järgmised:

Oskus määrata rakendatava ülesande põhimudelit (ärimudel, tavaliselt objektorienteeritud) ja selle käitumisreegleid (ärireeglid);

Projekteerimisprotsessi tugi, kasutades kujunduselementide (objektide ja reeglite) salvestamise, otsimise ja valimise tööriistadega varustatud raamatukogusid;

Tööriistade olemasolu kasutajaliidese loomiseks ja tavaliste programmeerimisliideste hooldamiseks (OLE, OpenDoc standardite tugi, juurdepääs HTML / Java teekidele jne);

Võimaluste olemasolu erinevate hajutatud klient-server rakenduste loomiseks.