1.1 Mõiste mõiste - "CASE-tööriistad"

Algselt mõisteti mõistet "CASE-technology" (Computer - Aided Software Engineering) sõna-sõnalt - "IS-i tarkvara automatiseeritud arendus arvutitehnoloogia abil".

Praegu tähistab mõiste CASE-tööriistad ulatuslikku tarkvaratööriistade komplekti, mis toetavad IS-i loomise ja hooldamise protsesse, sealhulgas nõuete analüüsi ja formuleerimist, rakendustarkvara (rakenduste) ja andmebaaside kujundamist, koodi genereerimist, testimist, dokumenteerimist, kvaliteeti. tagamine, konfiguratsioonihaldus ja projektijuhtimine ning muud protsessid. CASE tööriistad koos süsteemitarkvara ja riistvaraga moodustavad tervikliku IS-i arenduskeskkonna.

CASE-tehnoloogiad on analüütikutele, arendajatele ja programmeerijatele mõeldud metoodikate ja tööriistade kogum, mis on loodud IS-i kujundamise ja hooldamise protsesside automatiseerimiseks kogu perioodi vältel. eluring.

CASE tööriista metoodika määratleb projekti elluviimise etapid ja sammud, samuti reeglid, kuidas kasutada meetodeid, mille abil projekti arendatakse. CASE tööriista meetod on protseduur või tehnika infosüsteemi komponentide kirjelduste genereerimiseks (voogude ja andmestruktuuride kujundamine). CASE tööriista tähistus - süsteemi struktuuri, andmeelementide kuvamine spetsiaalsete graafiliste sümbolite abil.

CASE tööriistad on eriprogrammid mis toetavad ühte või mitut analüüsi- ja disainimetoodikat infosüsteemid. CASE-tehnoloogia hõlmab metoodika raames meetodeid, mille abil koostatakse diagrammid konkreetse CASE-tööriista poolt toetatud märgete alusel. CASE-tehnoloogiaid ei saa pidada iseseisvaks, need tagavad ainult nende rakendamise kõrge efektiivsuse, mille määrab projekti väljatöötamise aeg.

Kaasaegsed CASE-tööriistad katavad suure hulga infosüsteemide projekteerimise tehnoloogiate tugivaldkonda: alates lihtsad vahendid analüüs ja dokumentatsioon täismahuliste automatiseerimistööriistadeni, mis hõlmavad kogu elutsüklit tarkvara. Infosüsteemide arendamise 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, mitmesuguste skeemide kasutamist värvipalett, süntaktiliste reeglite täielik kontroll. Graafilised simulaatorid ainevaldkond võimaldada arendajatel olemasolevat infosüsteemi visuaalselt uurida, see vastavalt eesmärkidele ja olemasolevatele piirangutele ümber ehitada.

1.2 CASE-tööriistade tüüpiline struktuur

CASE tööriistad on vahendid struktuurianalüüsi meetodite toetamiseks ja kasutamiseks projekteerimisel. Need tööriistad toetavad kasutajate tööd graafilise projekti loomisel ja redigeerimisel interaktiivses režiimis. Nad aitavad kaasa projekti korraldamisele abstraktsioonitasemete hierarhia vormis, kontrollivad komponentide vastavust. Tegelikult on CASE-tööriistad uut tüüpi graafilisele orienteeritud tööriistad, mis pärinevad tarkvara elutsükli tugisüsteemist. Tavaliselt hõlmavad need mis tahes tarkvaratööriista, mis pakuvad automaatset abi tarkvara arendamise, hoolduse või projektijuhtimise toimingutes ning millel on järgmised lisaomadused:

võimas graafika spetsiifilise kasutajaliidesega tarkvarasüsteemide kirjeldamiseks ja dokumenteerimiseks, arendades spetsialistide loomingulisi võimeid ja mitte segades neid projekteerimisprotsessist teisejärguliste probleemide lahendamiseni;

integratsioon, mis tagab andmeedastuse lihtsuse tööriistade vahel ja võimaldab hallata kogu tarkvara projekteerimise ja arendamise protsessi otse läbi projekti planeerimise protsessi;

arvutisalvestuse (hoidla) kasutamine osade mallide ja üksikud elemendid projekt, mida erinevad arendajad saavad kasutada aluseks tarkvara automaatseks tootmiseks ja taaskasutamiseks tulevastes süsteemides.

Lisaks loetletud graafilise orientatsiooni, kogu projektiteabe integreerimise ja lokaliseerimise põhimõtetele hoidlas, põhineb CASE-tööriistade kontseptuaalne ülesehitus järgmistel sätetel:

1. Inimfaktor, mis määratleb tarkvaraarenduse kui lihtsa, mugava ja ökonoomse protsessi.

2. Teistes rakendustes (DB ja DBMS, kompilaatorid erinevatest programmeerimiskeeltest, silujad, dokumenteerijad, avaldamissüsteemid, ekspertsüsteemide kestad ja teadmusbaasid, keeled) laialt levinud põhitarkvaratööriistade laialdane kasutamine neljas põlvkond ja jne).

3. Automaatne või automaatne koodi genereerimine, erinevatele platvormidele ja erinevat tüüpi koodidele: teisendused dokumentatsiooni saamiseks; andmebaasi struktuuri kujundamine, andmete sisestamine/muutmine; käivitatavate masinakoodide hankimine tarkvara spetsifikatsioonidest; moodulite kokkupanek sõnastikest ja andmemudelitest ning taaskasutatavad programmid.

4. Kasutuslihtsus, mis võimaldab hankida hallatavaid, nähtavaid ja arusaadavaid ning lihtsa ja selge ülesehitusega komponente.

5. Saadavus erinevatele kasutajakategooriatele.

6. Kasumlikkus.

7. Tööülesannete efektiivne lahendamine väljatöötatud projekti toetamiseks, pakkudes kohanemisvõimet, kui kliendi poolt projekti nõuded ja eesmärgid muutuvad.

Peaaegu kõik kaasaegsed CASE-tööriistad sisaldavad järgmisi elemente:

hoidla, võimaldab tagada projektimallide ja selle spetsiifiliste komponentide ohutuse, teabe sünkroonimise erinevad arendajad rühma arendamise protsessis metaandmete täielikkuse ja järjepidevuse kontrollimine;

rakenduste arendustööriistad, mis kasutavad 4GL-keeli ja koodigeneraatoreid;

testimisvahendid;

dokumenteerimisvahendid;

graafilise analüüsi ja disaini vahendid, mis võimaldavad luua ja redigeerida infosüsteemi mudeleid hierarhiliselt seotud diagrammide kujul konkreetse metoodika realiseeritud tähistuses;

ümberehitustööriistad;

konfiguratsioonihaldustööriistad;

projektijuhtimise tööriistad.

1.3 CASE-tehnoloogiate arendamise areng

CASE-tehnoloogiaid on algusest peale välja töötatud eesmärgiga ületada 60-70ndate struktuurianalüüsi ja projekteerimismetoodika "käsitsi" rakendamise piirangud, automatiseerides ja integreerides tugitööriistadesse. Seega ei saa CASE-tehnoloogiaid pidada iseseisvateks modelleerimismetoodikateks, need muudavad nende rakendamise ainult arendusaja mõttes efektiivsemaks.

Traditsiooniliselt eristatakse kuut perioodi, mis on kvalitatiivselt erinevad tarkvaraarenduse tehnika ja meetodite poolest, mida iseloomustab kasutamine tööriistadena:

1. Assemblerid, mälumahutid, analüsaatorid;

2. Koostajad, tõlgendajad, jäljendajad;

3. Sümboolsed silujad, tarkvarapaketid;

4. Lähtetekstide analüüsi ja haldamise süsteemid;

5. CASE tööriistad nõuete analüüsiks, spetsifikatsioonide ja struktuuri kujundamiseks, liideste redigeerimiseks (CASE-I esimene põlvkond);

6. CASE-i genereerivad tööriistad lähtekood ja integreeritud keskkonna rakendamine, et toetada tarkvaraarenduse kogu elutsüklit (CASE-II teine ​​põlvkond)

CASE-I on esimene tehnoloogia, mis on otseselt suunatud süsteemianalüütikutele ja disaineritele ning sisaldab tööriistu graafiliste mudelite, disaini spetsifikatsioonide, ekraaniredaktorite ja andmesõnastike toetamiseks. See ei ole mõeldud toetama kogu elutsüklit ja keskendub funktsionaalsetele spetsifikatsioonidele ja projekti esialgsetele etappidele – süsteemianalüüs, nõuete määratlemine, süsteemide projekteerimine, loogiline andmebaasi disain.

CASE-II-l on oluliselt täiustatud funktsioonid, parem jõudlus ja terviklik lähenemine arendatava tarkvara kogu elutsüklile. CASE-II tööriistakomplekt kasutab peamiselt automaatse koodi genereerimise tuge ja pakub täielikku funktsionaalset tuge, et vastata graafilistele süsteeminõuetele ja disaini spetsifikatsioonidele; süsteemiteabe ja disainihaldusinfo kontroll, analüüs ja sidumine; süsteemi prototüüpide ja mudelite ehitamine; loodud programmide testimine, kontrollimine ja analüüs; projektidokumentide genereerimine; standarditele vastavuse kontroll elutsükli kõigil etappidel. CASE-II võib sisaldada üle 100 funktsionaalse komponendi, mis toetavad kõiki elutsükli etappe, samas antakse kasutajatele võimalus valida vajalikud tööriistad ja integreerida need soovitud kompositsiooni.

1.4 CASE-tööriistades kasutatavad disainimetoodikad

CASE-tööriistad on tööriista (või tehnoloogia) tööstuse loomuliku arengu tulemus. CASE-tehnoloogiad hakkasid arenema, et ületada struktureeritud programmeerimismetoodika piirangud.

Seda metoodikat iseloomustab programmeerimise formaliseeritusest hoolimata siiski arusaamise keerukus, suur töömahukus ja kasutuskulu ning disaini spetsifikatsioonides muudatuste tegemise raskus. Selles sätestatud põhimõtted võimaldasid seda metoodikat arendada ja tõhustada kõige rutiinsemate etappide automatiseerimise kaudu (joonis 1.1).

CASE-i tööriistades rakendatavate metoodikate peamised standardid on järgmised:

SADT (Structured Analysis and Design Technique) – struktuurianalüüsi ja disaini metoodika. Lähtudes funktsionaalse modelleerimise kontseptsioonidest. Peegeldab süsteemi omadusi, nagu juhtimine, tagasiside ja esineja;

IDEF0 (Integrated Definition Function Modeling) on ​​funktsionaalse modelleerimise metoodika. Seda kasutatakse funktsionaalse mudeli loomiseks, mis kuvab süsteemi struktuuri ja funktsioone, samuti teabevooge ja nende funktsioonide poolt muudetud materiaalseid objekte. See on SADT metoodika alamhulk;

DFD(DataFlow Diagram) - andmevoogude modelleerimise metoodika.

Joonis 1.1 - Traditsioonilise arenduse ja arenduse võrdlus CASE tehnoloogiate abil

Töövoogudevahelise andmevahetuse kirjeldamiseks kehtivad järgmised metoodilised standardid.

IDEF1 kasutatakse infomudeli koostamiseks, mis kuvab süsteemi funktsioonide toetamiseks vajalike infovoogude struktuuri ja sisu;

IDEF2 võimaldab luua dünaamilise mudeli süsteemi funktsioonide, teabe ja ressursside ajas muutuvast käitumisest;

IDEF3 on töövoo modelleerimise metoodika. See on IDEF0 ja DFD osas üksikasjalikum. Võimaldab kaaluda konkreetset protsessi, võttes arvesse tehtud toimingute järjestust. IDEF3 kirjeldab iga protsessi stsenaariumi ja toimingute järjestust;

IDEF1X (IDEF1 Extended) - andmete kirjeldamise metoodika. Kasutatakse andmebaaside koostamiseks. Viitab metoodika tüübile "Entity-Relationship" (ER - Entity-Relationship) ja reeglina kasutatakse seda kõnealuse süsteemiga seotud relatsiooniandmebaaside modelleerimiseks;

IDEF4 on objektorienteeritud metoodika. Peegeldab objektide vastasmõju. Võimaldab visuaalselt kuvada objektide struktuuri ja nende koostoime aluspõhimõtteid. Mugav tarkvaratoodete loomiseks objektorienteeritud keeltes;

IDEF5 - komplekssete süsteemide ontoloogilise uurimise metoodika. IDEF5 metoodikat kasutades saab süsteemi ontoloogiat kirjeldada kindla terminite ja reeglite sõnavara abil, mille alusel saab moodustada usaldusväärseid väiteid vaadeldava süsteemi seisukorra kohta mingil ajahetkel;

ARIS – kirjeldab äriprotsessi kui järjestikuste tööde voogu;

UML – (Unified Modeling Language) objektorienteeritud lähenemisel põhinev ühtne modelleerimiskeel. UML võimaldab kirjeldada süsteemi staatilist struktuuri ja selle dünaamilist käitumist sobivates märgetes.

CASE tööriistad kasutavad laialdaselt struktuurseid ja objektorienteeritud projekteerimise metoodikaid. Struktuurne projekteerimine põhineb algoritmilisel dekomponeerimisel, objektorienteeritud projekteerimine aga objektorienteeritud lagunemisel. Algoritmiline lagunemine võimaldab teil määrata sündmuste järjekorra. Objektorienteeritud dekomponeerimine võimaldab määratleda objektiklasside hierarhia, nende meetodid ja omadused. Objektorienteeritud disaini toetavad CASE-tööriistad kasutavad RUP (Rational Unified Process) metoodikat ja tähistusi UML keel.

1.5 Objektorienteeritud disaini CASE-tööriistade metoodika

Objektorienteeritud lähenemise korral ühendab objektmudeli põhikategooria klass elementaartasandil nii andmed kui ka toimingud, mida nendega tehakse (meetodid). Just sellest vaatenurgast on kõige märgatavam muutused, mis on seotud üleminekuga struktuurselt lähenemiselt objektorienteeritud lähenemisele. Protsesside ja andmete eraldatus on ületatud, kuid alles jääb süsteemi keerukuse ületamise probleem, mis lahendatakse komponentide mehhanismi kasutades.

Võrreldes protsessidega on andmed stabiilsem ja suhteliselt harva esinev osa süsteemist. See on objektorienteeritud lähenemisviisi peamine eelis, mille Gradi Booch sõnastas järgmiselt: objektorienteeritud süsteemid on avatumad ja hõlpsamini muudetavad, kuna nende disain põhineb stabiilsetel vormidel. See võimaldab süsteemil järk-järgult areneda ja ei too kaasa selle täielikku töötlemist isegi esialgsete nõuete oluliste muudatuste korral.

Booch märgib ka mitmeid järgmisi objektorienteeritud lähenemisviisi eeliseid.

1. Objektide dekomponeerimine võimaldab luua väiksemaid tarkvarasüsteeme, kasutades selleks levinud mehhanisme, mis tagavad vajaliku väljendusvahendite ökonoomsuse. Objektkäsitluse kasutamine tõstab oluliselt arenduse ühtlustamise taset ja mitte ainult programmide, vaid ka projektide taaskasutatavust, mis viib lõppkokkuvõttes arenduskeskkonna loomiseni ja üleminekuni koostetarkvara arendamisele. Süsteemid on sageli kompaktsemad kui nende struktuursed ekvivalendid, mis ei tähenda ainult mahu vähenemist programmi kood, vaid ka projekti maksumuse vähendamine läbi varasemate arenduste kasutamise.

2. Objekti dekomponeerimine vähendab keeruliste tarkvarasüsteemide loomise riski, kuna see hõlmab suhteliselt väikestel alamsüsteemidel põhinevat süsteemi arendusteed. Süsteemi integreerimise protsess on venitatud kogu arendusperioodi vältel ega muutu ühekordseks sündmuseks.

3. Objektimudel on üsna loomulik, kuna see keskendub eelkõige inimese maailmatajule, mitte arvutirakendusele.

4. Objektimudel võimaldab täielikult kasutada objekt- ja objektorienteeritud programmeerimiskeelte väljendusvõimet.

Objektorienteeritud lähenemisviisi puudused hõlmavad tarkvara jõudluse mõningast vähenemist ja kõrgeid algkulusid. Objekti lagunemine erineb oluliselt funktsionaalsest lagunemisest, seega on üleminek uuele tehnoloogiale seotud nii psühholoogiliste raskuste ületamise kui ka täiendavate rahaliste kuludega. Loomulikult peegeldab objektorienteeritud mudel kõige adekvaatsemalt tegelikku maailma, mis on interakteeruvate (sõnumivahetuse kaudu) objektide kogum. Kuid praktikas jätkub hetkel objektorienteeritud modelleerimise UML-i keelestandardi kujunemine ning objektorienteeritud lähenemist toetavate CASE-tööriistade hulk on väike võrreldes sarnaste struktuurset lähenemist toetavate tööriistadega.

Lisaks on objektikäsitluse spetsiifikat kajastavad diagrammid (klassiskeemid jne) palju vähem visuaalsed ja mitteprofessionaalidele halvasti arusaadavad. Seetõttu on CASE-tehnoloogia juurutamise üks peamisi eesmärke, nimelt kõikide projektis osalejate (kaasa arvatud tellija) varustamist ühise keelega “mõistmise edastamiseks”, praegu vaid struktuursete meetoditega.

Üleminekul struktuurselt lähenemiselt objektkäsitlusele, nagu iga tehnoloogia muudatuse puhul, on vaja investeerida uute tööriistade soetamisse. Siin tuleks arvestada ka koolituskuludega (meetodi, tööriistade ja programmeerimiskeele valdamine). Mõne organisatsiooni jaoks võivad need asjaolud saada tõsiseks takistuseks. Objektorienteeritud lähenemine ei anna kohest tulu. Selle rakendamise mõju hakkab mõjutama pärast kahe või kolme projekti väljatöötamist ja korduvkasutatavate komponentide kogunemist, mis peegeldavad selle valdkonna tüüpilisi disainilahendusi. Organisatsiooni üleminek objektorienteeritud tehnoloogiale on meelemuutus, mitte ainult uute CASE-tööriistade ja programmeerimiskeelte õppimine.

Ilmselgelt on konkreetse projekti puhul võimatu keerulist süsteemi kahel viisil korraga lagundada. Dekomponeerimist saab alustada ühel viisil ja seejärel tulemuste põhjal proovida süsteemi vaadata teisest vaatenurgast. Nüüd jätkame struktuurse ja objektorienteeritud lähenemisviisi vahelise seose käsitlemisega. Seose aluseks on mitmete kategooriate ja mõlema lähenemise kontseptsioonide ühisosa (protsess ja kasutusjuht, olem ja klass jne). See suhe võib avalduda erinevates vormides. Seega on üks võimalik lähenemine objektorienteeritud disaini aluseks võtta struktuuranalüüs. Selline lähenemine on otstarbekas, arvestades struktuurianalüüsi toetavate CASE-tööriistade laialdast levikut. Struktuurianalüüs jätkub hetkeni, mil andmevoo diagrammid hakkavad kajastama mitte ainult ainevaldkonda, vaid ka tarkvarasüsteemi.

Pärast struktuurianalüüsi ja andmevooskeemide koostamist koos andmestruktuuride ja muude analüüsitulemustega saate hakata klasse ja objekte mitmel viisil määratlema. Seega, kui võtta eraldi diagramm, võivad välised olemid ja andmesalved olla objektide kandidaatideks ning andmevood klasside kandidaatideks.

Teiseks suhte avaldumisvormiks võib pidada objekti- ja relatsioonitehnoloogiate integreerimist. Relatsioonilised DBMS-id on tänapäeval suuremahuliste andmebaaside ja andmeladude juurutamise peamised vahendid. Selle põhjused on ilmsed: relatsioonitehnoloogiat on pikka aega kasutatud, seda on valdanud tohutu hulk kasutajaid ja arendajaid, sellest on saanud tööstuse standard, sellesse on investeeritud märkimisväärseid vahendeid ja loodud on palju ettevõtete andmebaase tööstusharudes on relatsioonimudel lihtne ja sellel on range matemaatiline alus; relatsiooniandmebaaside kujundamiseks, juurutamiseks ja käitamiseks on lai valik tööstuslikke tööriistu. Sellest tulenevalt kasutatakse relatsiooniandmebaase peamiselt objektide hoidmiseks ja otsimiseks nn objektrelatsioonisüsteemides. Objektorienteeritud disainil on ühisosa relatsioonilise disainiga. Näiteks, nagu eespool märgitud, võivad objektimudeli klassid mingil viisil vastata olemitele (harjutusena on soovitatav üksikasjalikult analüüsida kõiki olemi-seoste diagrammide ja klassidiagrammide sarnasusi ja erinevusi). Reeglina toimub selline kirjavahetus ainult süsteemi arendamise varases staadiumis - nõuete kujunemise etapis. Edaspidi loomulikult lähevad objektorienteeritud disaini (ainevaldkonna adekvaatne modelleerimine objektide interaktsiooni seisukohalt) ja relatsioonilise andmebaasi arendamise (andmete normaliseerimise) eesmärgid lahku. Seega on ainus võimalik vahend selle lünga ületamiseks määratleda vastavus objektorienteeritud ja relatsioonitehnoloogiate vahel, mis taandub põhimõtteliselt relatsioonimudeli klassidiagrammide ja olemi-seoste diagrammide kuvamisele. Üks näide struktuurse ja objektorienteeritud lähenemise vahelise seose praktilisest rakendamisest on Vene ettevõtte Argussofti poolt välja töötatud Silverruni struktuurse CASE tööriista ja Rational Rose objektorienteeritud CASE tööriista vaheline programmeerimisliides (sild). Rational Rose klassidiagrammid põhinevad RDM-mudelil (Relational Data Model – relatsiooniline andmemudel) Silverrun ja vastupidi. Sarnased liidesed eksisteerivad ka ERwin CASE tööriistade (ühelt poolt), Rational Rose ja Paradigm Plus (teiselt poolt).

1.6 Konstruktsioonide projekteerimise metoodika CASE tööriistad

Infosüsteemide arendamise struktuurse lähenemise olemus seisneb selle lagunemises (partitsioneerimises) automatiseeritud funktsioonideks. Automatiseeritud süsteem jaguneb 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. Üksikutest ülesannetest kogu süsteemile “alt-üles” süsteemi arendamisel kaob terviklikkus, tekivad probleemid üksikute komponentide informatiivsel dokkimisel.

Kõik levinumad struktuurse lähenemise metoodikad põhinevad mitmetel üldpõhimõtetel. Peamised põhimõtted on järgmised:

lagunemise printsiip – otsustuspõhimõte rasked probleemid jaotades need paljudeks väiksemateks ja 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 abstraktsioon ebaolulisest;

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

järjepidevuse põhimõte - seisneb süsteemi elementide kasutamise kehtivuses ja järjepidevuses;

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

IN struktuurianalüüs peamiselt kasutatakse 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;

DFD (Data Flow Diagrams) andmevoo diagrammid;

ERD (olemi-suhete diagrammid)

Infosüsteemi (IS) projekteerimise etapis muutuvad mudelid keerukamaks, viimistletakse ja täiendatakse tarkvara struktuuri ja arhitektuuri kajastavate diagrammide, programmide plokkskeemide ja ekraanivormide diagrammidega. 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 Arendus kontseptuaalne mudel infosüsteem.

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 ülesehitus põhineb ees seisvate ülesannete analüüsil Reklaamiagentuur. 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.

Mudel on üles ehitatud loogiline tase(vt joonis 2). Jooniselt 2 on näha, et mudelis on lingid. Vaatleme neid üksikasjalikumalt:

Tabel "Toidu tüübid" ja tabel "Toidud" - üks-mitmele seos luuakse kasutades esmane võti"Kuva kood";

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 Arendus loogiline mudel infosüsteem

Andmebaasid ja tarkvaratööriistad nende loomiseks ja hooldamiseks (DBMS) on olemas kihiline arhitektuur, mida on näha joonisel 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. Privaatne loogiline struktuur andmed konkreetse rakenduse (ülesande) või kasutaja kohta vastavad välisele mudelile või andmebaasi 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

Kõige olulisem etapp andmebaasi kujundamine on ainevaldkonna infoloogilise (infoloogilise) mudeli väljatöötamine, mitte orienteeritud DBMS. 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 haldussüsteemidest arvutustabelid. Korraga saab avada 1024 lauda.

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

Samad andmed saab rühmitada tabeliteks (seosteks) erinevatel viisidel, st. 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.

Teabeobjekti kirjeldavad atribuudid on loogiliselt seotud nende jaoks ühise võtmega, sellel seosel on iseloom funktsionaalne sõltuvusüksikasjad.

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.

Pilt 1 - Graafiline pilt detailide funktsionaalne sõltuvus

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

funktsionaalne täielik sõltuvus Mittevõtmeatribuutide puhul on see, et iga võtmevaba 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 alus andmed peaksid täitma funktsioone organisatsiooni andmete väljastamise automatiseerimise huvides. See peaks olema lihtne ja selge kasutajaliides, neil on minimaalsed süsteeminõuded.

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

kiire sisenemine uued andmed;

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.

Mõnede CASE-süsteemide ülevaade.

CASE tootjate nimekiri – tööriistad ja seeriad Kasulikud lingid leiate aadressilt http://sunny.aha.ru/~belikov/index.htm, venekeelne konverentsiuudised://fido7.su.dbms.case/ on pühendatud CASE-i kasutamisele, Vendrov A.M. raamat on saadaval ka Internetis. CASE tehnoloogiad. Kaasaegsed meetodid ja infosüsteemide projekteerimise tööriistad.

Power Designer by Sybase.

Power Designer sisaldab järgmisi mooduleid:

· Protsessi analüütik- funktsionaalse modelleerimise tööriist, toetab Yordon - DeMarco, Hein - Sarsoni ja mitmete teiste tähistusi. Andmevoogude ja andmesalvedega seotud andmeelemente (nimed, tüübid, vormingud) on võimalik kirjeldada. Need elemendid antakse edasi järgmisse projekteerimisetappi ja andmesalve saab automaatselt olemiteks teisendada.

· Andmeanalüütik- tööriist olemi-suhete mudeli koostamiseks ja automaatne genereerimine põhineb selle suhtelisel struktuuril. Olemi-seose mudeli sisendi saab hankida moodulis Protsessi analüütik loodud DFD mudelitest. ER-diagrammides on lubatud ainult binaarlingid; linkide atribuutide seadmist ei toetata. Toetatud murded SQL keel umbes 30 relatsioonilise DBMS-i jaoks saab genereerida tabeleid, vaateid, indekseid, päästikuid jne. Selle tulemusena genereeritakse SQL skript (CREATE käskude jada), mille täitmine loob kavandatud andmebaasi skeemi. Samuti on võimalik luua ühendus DBMS-iga läbi ODBC liidese. Muud võimalused: automaatne kontroll mudeli korrektsus, andmebaasi suuruse arvutamine, ümbertöötamine (mudeldiagrammide koostamine juba olemasolevad alused andmed) jne.

· Rakenduse modelleerija- tööriist andmetöötlusprogrammide prototüüpide automaatseks genereerimiseks, mis põhinevad Data Analystis ehitatud relatsioonimudelitel. Saate hankida koodi Visual Basic, Delphi, aga ka sellistele "klient-server" arhitektuuri arendussüsteemidele nagu PowerBuilder, Uniface, Progress jne. Koodi genereerimine põhineb mallidel, genereerimist saab vastavalt juhtida vastava malli muutmisega.

Power Designeri hindamisversiooni, milles ehitatud mudelite salvestamise funktsioonid on blokeeritud, saab hankida ettevõtte Sybase venekeelsest veebiserverist.

Silverrun, Silverrun Technologies Ltd.

Silverrun CASE süsteem koosneb järgmistest tööriistadest:

· BPM- DFD-skeemide koostamine. Toetab Yordon-DeMarco, Hein-Sarsoni, Ward-Mellori märgendeid ja paljusid teisi. See tööriist võimaldab teil automaatselt kontrollida ehitatud mudeli terviklikkust ja kasutaja määrab kontrollikriteeriumide loendi (näiteks: mudeli elementide nimede puudumine, andmevood, mille tüüp on "salvestusruum" või "väline salvestusruum" üksus – väline üksus" jne)

· ERX- "olemi-suhete" diagrammide koostamine. Toetatakse mitte ainult binaarlinke, vaid ka kõrgema järgu linke, linkidele on võimalik määrata atribuute. Välise utiliidi abil ehitatud ER-mudeleid saab teisendada suhteline struktuur(versioonis, millega ma töötasin, läksid kahjuks lingi atribuudid kaduma).

· RDM- relatsioonilise modelleerimise tööriist, mis võimaldab genereerida SQL-skripte tabelite ja indeksite loomiseks umbes 25 siht-DBMS-i jaoks.

Tuleb märkida, et Silverrun Technologies Ltd ei ole ainult CASE tööriistade arendaja, vaid loonud ka oma metoodika infosüsteemide loomiseks, nimega Datarun. See metoodika sisaldab infosüsteemi elutsükli kõigi etappide kirjeldust, tööde loetelu ja järjekorda, nõudeid dokumentide sisule ja täitmisele ning palju muud.

Silverruni hindamisversiooni saab alla laadida Argussofti serverist. Selles versioonis on loodud mudelite elementide arv piiratud.

LogicWorksi BPWin ja ERWin.

LogickWorks annab välja kaks täiendavat infosüsteemide kujundamise tööriista:

· BPWin- IDEF0 metoodikal põhinev funktsionaalne modelleerimine. Yordon-DeMarco tähistuses on lubatud kasutada ka IDEF3 ja DFD tähistusi. Ehitatud mudeleid on võimalik eksportida funktsionaalse kuluanalüüsi süsteemidesse (ABC – Activity Based Costing) ja teabe modelleerimine erwin.

· ERWin- info modelleerimise tööriist, kasutatakse IDEF1X tähistust. Toetatud on rohkem kui 20 sihtmärk-DBMS-i, võimalik on genereerida prototüüpe rakendusprogrammid Visual Basicu, Delphi jne jaoks.

SilverRuni kasutamine

Metoodika

Komplekssete infosüsteemide planeerimine ja arendamine on võimatu ilma hoolikalt läbimõeldud metoodilise lähenemiseta. Millised etapid tuleb läbida, milliseid meetodeid ja mudeleid kasutada, kuidas korraldada kontrolli projekti edenemise ja töö kvaliteedi üle – need küsimused lahendatakse metoodikate abil tarkvaraarendus. Metoodikaid on palju ja nende peamine asi on ühtne töödistsipliin süsteemi elutsükli kõigil etappidel. Kui võtta arvesse kõiki kriitilisi ülesandeid ja kontrollida nende lahendamist, tõuseb loodud süsteemide kvaliteet oluliselt. Üldjuhul pole sel juhul vahet, millised konkreetsed meetodid nende probleemide lahendamiseks valiti.

Erinevad süsteemiklassid kasutavad oma arendusmeetodeid. Need on määratletud tüübina loodud süsteem ja rakendusvahendid. Arendusmahtude poolest on ilmselt levinumad äriklassi infosüsteemid. Peaaegu igas organisatsioonis on spetsialiste, kes arendavad või hooldavad infosüsteeme. Nende süsteemide spetsifikatsioon koosneb enamikul juhtudel kahest põhikomponendist: funktsionaalsest ja informatiivsest. Nende komponentide kombineerimise viisi järgi võib infosüsteemide esitusviisid jagada kahte põhitüüpi – struktuursed ja objektorienteeritud. Muidugi on objektorienteeritud meetodid ka struktuursed selle sõna otseses tähenduses. Kuid ajalooliselt on tarkvaratehnikas seda terminit omistatud mitmetele teadusharudele: struktuurne programmeerimine, struktuurne projekteerimine, struktuurianalüüs. Struktuuritehnoloogiates ehitatakse funktsionaalsed ja infomudelid eraldi, enamasti andmevooskeemide ja olemi-seoste diagrammide kujul. Objektorienteeritud tehnoloogiad peavad teavet selle töötlemisprotseduuride lahutamatuks osaks. Objektorienteeritud tehnoloogiamudelid kirjeldavad süsteemide struktuuri, käitumist ja rakendamist objektiklasside kaudu.

Objektorienteeritud tehnoloogiad domineerivad operatsioonisüsteemide, rakenduste arendamise ja täitmise tööriistade ning reaalajas süsteemide loomise valdkonnas. Objektide kontseptsioon aitab võidelda süsteemide kiiresti kasvava keerukusega. Lisaks suhtlemine elektroonilised seadmed, nagu ka programmi elemendid, on loomulikult esindatud objektidega.

Ärisüsteemide loomise valdkonnas on juhtivad struktuuritehnoloogiad, kuna need on kõige paremini kohandatud suhtlema klientide ja kasutajatega, kes pole infotehnoloogia valdkonna spetsialistid. Ja seda näitas infosüsteemide arendamise kogemuse analüüs aktiivne kaasatus kasutajad nõuete tuvastamise ja probleemide seadmise etapis on kriitiline edutegur suuremad projektid. Äriklassi süsteemide arendamisel kulub põhiline pingutus kasutajanõuete mõistmisele ja täpsustamisele ning juurutamisele, ostetud vahendid rakenduste arendus (enamasti neljanda põlvkonna keeled) ja andmebaasihaldussüsteemid (kõige sagedamini relatsioonilised).

Eelnevast lähtudes saab SILVERRUN süsteemi koha tarkvaratehnika tehnoloogiates määratleda järgmiselt: tegemist on CASE süsteemiga kõrgeim tase, mis on mõeldud äriklassi infosüsteemide loomise struktuursete metoodikate instrumentaalseks toetamiseks. Seega saavad seda süsteemi kasutada ettevõtete analüüsi ja modelleerimisega tegelevad spetsialistid, infosüsteemide arendajad, andmebaaside haldajad.

RAD metoodika

Üheks võimalikuks lähenemiseks tarkvaraarendusele spiraalse elutsükli mudeli raames on viimasel ajal laialt levinud rakenduste kiire arendamise metoodika RAD (Rapid Rakenduste arendus). Seda mõistet mõistetakse tavaliselt tarkvara arendusprotsessina, 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 kujundama, taotlevad ja rakendavad tootes kliendiga suhtlemise kaudu saadud nõudeid.

Arendusmeeskond peaks olema professionaalide rühm, kellel on kogemusi analüüsi, disaini, koodi genereerimise ja tarkvara testimise alal, kasutades CASE tööriistu. 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 etapp;

projekteerimise etapp;

ehitusetapp;

rakendamise etapp.

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 väga võimalus rakendada see projekt kehtestatud rahastamisraamistikus, antud riistvaral jne. Selle faasi tulemuseks peaks olema tulevase IS-i funktsioonide loetelu ja prioriteet, IS-i esialgsed funktsionaalsed ja infomudelid.

Disainifaasis osalevad mõned kasutajad tehniline disain süsteemid spetsialistide-arendajate juhendamisel. CASE tööriistu kasutatakse kiire kviitung töötavad rakenduste prototüübid. 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 otsustatakse jagada IS alamsüsteemideks, mida saab RAD-projektidele vastuvõetava aja jooksul rakendada üks arendajate meeskond. - 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;

· funktsionaalsed mudelid süsteem tervikuna ja individuaalsete arendusmeeskondade poolt juurutatud alamsüsteemid;

liidesed autonoomselt arendatud allsüsteemide vahel, mis on täpselt määratletud CASE tööriista abil;

· ehitatud 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 mis on tingitud asjaolust, et traditsioonilise lähenemise korral võib projekti kohta teabe edastamisel etapist teise tekkida praktiliselt kontrollimatu andmete moonutamine. 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 osaks. tulevane süsteem. Seega edastatakse järgmisse faasi täielikum ja kasulikum teave.

Ehitusfaasis teostatakse seda otse ise kiire areng rakendusi. 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ööriista 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 osa süsteemist järk-järgult ülejäänud osaga, moodustatakse terviklik programmikood ja testimine. ühine töö see osa rakendusest koos ülejäänud osaga ja seejärel süsteemi kui terviku testimine. Süsteemi füüsiline projekteerimine on lõpetamisel:

määrab andmete levitamise vajaduse;

· teostatakse andmekasutuse analüüs;

andmebaasi füüsiline ülesehitus;

määrata kindlaks nõuded riistvararessurssidele;

Määrake tootlikkuse suurendamise viisid

· Lõpetamisel on projekti dokumentatsiooni väljatöötamine.

Etapi tulemuseks on valmis süsteem, mis vastab kõigile kokkulepitud nõuetele.

Rakendusfaasis viiakse läbi kasutajakoolitusi, organisatsioonilisi muudatusi ning paralleelselt uue süsteemi kasutuselevõtuga töötatakse olemasolev süsteem(kuni uue täieliku rakendamiseni). Kuna ehitusetapp on suhteliselt lühike, tuleb planeerimist ja juurutamise ettevalmistamist alustada varakult, tavaliselt süsteemi projekteerimisetapis. Ülaltoodud skeem IP arendamiseks ei ole absoluutne. Võimalik erinevaid valikuid, olenevalt näiteks algtingimustest, milles arendus läbi viiakse: a täielikult uus süsteem; ettevõttes on juba läbi viidud küsitlus ja olemas on selle tegevuse mudel; ettevõttel on juba mõni IS, mida saab kasutada esialgse prototüübina või mis tuleks integreerida arendatavaga.

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 seda arendatakse tüüpiline süsteem, mis ei ole valmistoode, vaid on standardsete komponentide kompleks, mida hooldatakse tsentraalselt, mis on kohandatud tarkvara- ja riistvaraplatvormidele, DBMS-idele, telekommunikatsioonile, rakendusobjektide organisatsioonilistele ja majanduslikele omadustele ning integreeritud olemasolevaid arenguid, tulevad esile sellised projekti näitajad nagu juhitavus ja kvaliteet, mis võivad minna vastuollu arenduse 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 ega juhtimisprogrammide koostamisel kosmoselaevad, st. programmid, mis nõuavad suure hulga (sadu tuhandeid ridu) unikaalse koodi kirjutamist.

Ei sobi rakendused, millel puudub selgelt väljendunud liidese osa, mis selgelt määratleb süsteemi tööloogika (näiteks reaalajas rakendused) ja inimeste turvalisust mõjutavad rakendused (näiteks lennuki või tuumajaama juhtimine). arendamiseks RAD-metoodikat kasutades, kuna iteratiivne lähenemine eeldab, et paar esimest versiooni ei ole kindlasti täielikult funktsionaalsed, mis sel juhul välistatud.

Rakenduste suurust hinnatakse nn funktsionaalsete elementide (ekraanid, sõnumid, aruanded, failid jne) alusel.. Selline mõõdik ei sõltu programmeerimiskeelest, milles arendust teostatakse. Rakenduse suurus, mida saab RAD metoodika järgi käivitada, väljakujunenud IS-i arenduskeskkonna jaoks, kus tarkvarakomponente kasutatakse maksimaalselt, määratakse järgmiselt:

Selle tulemusena loetleme RAD-i metoodika peamised põhimõtted:

rakenduste arendamine iteratsioonide teel;

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

Kasutajate kohustuslik kaasamine IS arendusprotsessi;

Vajalik CASE tööriistade kasutamine, mis tagavad projekti terviklikkuse;

Konfiguratsioonihaldustööriistade kasutamine projekti muutmise ja hoolduse hõlbustamiseks valmis süsteem;

Vajalik koodigeneraatorite kasutamine;

Prototüüpimise kasutamine lõppkasutaja vajaduste paremaks mõistmiseks ja rahuldamiseks;

projekti testimine ja arendus, mis viiakse läbi arendusega samaaegselt;

Väikese hästi juhitud professionaalide meeskonna arendamise juhtimine;

· Süsteemi arenduse pädev juhtimine, selge planeerimine ja tööde teostamise kontroll.

Struktuurne lähenemine

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 konkreetsed protseduurid. 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. Kahena põhiprintsiibid kasutatakse järgmist:

· "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 ülejäänud printsiibid oleksid teisejärgulised, sest ükskõik millise neist eiramine võib kaasa tuua ettearvamatuid tagajärgi (sh kogu projekti ebaõnnestumine). Peamised neist põhimõtetest on järgmised:

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.

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

· 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.

Loetletud mudelid koos annavad Täielik kirjeldus IP, 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.

8. loeng Juhtumifondid infosüsteemide arendamine

Kaasaegsete operatsioonisüsteemide omadused

Aasta-aastalt areneb operatsioonisüsteemide struktuur ja võimalused. Hiljuti on mõned uued operatsioonisüsteemid ja juba olemasolevate operatsioonisüsteemide uued versioonid kaasanud konstruktsioonielemendid mis on nende süsteemide olemuses suuri muudatusi teinud. Kaasaegsed operatsioonisüsteemid vastavad pidevalt areneva riist- ja tarkvara nõuetele. Nad suudavad hallata kiiremaid mitme protsessoriga süsteeme, kiiremaid võrguseadmeid ja üha suuremat valikut salvestusseadmeid. Operatsioonisüsteemide disaini mõjutanud rakendustest tuleks ära märkida multimeediumirakendused, Interneti-juurdepääsu tööriistad ja kliendi/serveri mudel.

Operatsioonisüsteemidele esitatavate nõuete pidev kasv ei vii mitte ainult nende arhitektuuri täiustamiseni, vaid ka uute organiseerimisviiside esilekerkimiseni. Eksperimentaalsetes ja kaubanduslikes operatsioonisüsteemides on proovitud palju erinevaid lähenemisviise ja ehitusplokke, millest enamiku saab rühmitada järgmistesse kategooriatesse.

mikrokerneli arhitektuur.

· Mitmelõimeline.

· Sümmeetriline multitöötlus.

· Hajutatud operatsioonisüsteemid.

· Objektorienteeritud disain.

Enamiku tänapäevaste operatsioonisüsteemide eripäraks on suur monoliitne tuum. Operatsioonisüsteemi tuum pakub enamikku oma funktsioonidest, sealhulgas ajakava koostamine, failisüsteemiga manipuleerimine, võrgundus, seadmedraiverid, mäluhaldus ja paljud teised. Tavaliselt realiseeritakse monoliitne kernel ühe protsessina, mille kõik elemendid kasutavad sama aadressiruumi. Mikrokerneli arhitektuuris vaid mõned kõige enam olulisi funktsioone, mis hõlmavad aadressiruumidega töötamist, protsessidevahelist sidet (IPC) ja põhilist ajastamist. Muid operatsioonisüsteemi teenuseid pakuvad protsessid, mida mõnikord nimetatakse serveriteks. Need protsessid töötavad kasutajarežiimis ja mikrotuum käsitleb neid nagu teisi rakendusi. Selline lähenemine võimaldab jagada operatsioonisüsteemi arendamise ülesanded kerneli arendamiseks ja serveri arendamiseks. Servereid saab kohandada vastavalt konkreetsetele rakendus- või keskkonnanõuetele. Mikrokerneli jaotus süsteemi struktuuris lihtsustab süsteemi juurutamist, tagab selle paindlikkuse ning sobib hästi ka hajutatud keskkonda. Tegelikult suhtleb mikrotuum kohalike ja kaugserver sama skeemi järgi, mis lihtsustab hajutatud süsteemide ehitamist.

Multithreading on tehnoloogia, mille puhul rakendust täitev protsess on jagatud mitmeks samaaegselt käivitavaks lõimeks. Allpool on toodud peamised erinevused niidi ja protsessi vahel.

· Voolu. Saatatav tööüksus, mis sisaldab protsessori konteksti (mis sisaldab programmiloenduri ja pinukursori sisu), aga ka oma pinuala (alamprogrammi kutsete korraldamiseks ja kohalike andmete salvestamiseks). Lõimekäsud täidetakse järjestikku; lõime võib katkeda, kui protsessor lülitub teisele lõimele 4 .Protsess. Ühe või mitme lõime kogum ja nende lõimedega seotud süsteemiressursid (nt koodi ja andmeid sisaldav mälupiirkond, failid avada, erinevaid seadmeid). See kontseptsioon on väga lähedane töötava programmi kontseptsioonile. Jagades rakenduse mitmeks lõimeks, saab programmeerija kõik rakenduse modulaarsuse eelised ja võimaluse hallata rakendusega seotud ajalisi sündmusi.

Multithreading on väga kasulik rakenduste jaoks, mis täidavad mitmeid sõltumatuid ülesandeid, mis ei vaja järjestikust täitmist. Sellise rakenduse näiteks on andmebaasiserver, mis võtab vastu ja töötleb korraga mitu kliendi päringut. Kui ühes protsessis töödeldakse mitut lõime, on erinevate lõimede vahel vahetamisel protsessori jaoks vähem kulu kui erinevate protsesside vahel vahetamisel. Lisaks on lõimed kasulikud operatsioonisüsteemi tuuma osaks olevate protsesside struktureerimiseks, nagu on kirjeldatud hilisemates peatükkides.

Kuni viimase ajani kõik personaalarvutid, mis oli mõeldud ühele kasutajale, ja tööjaamad sisaldasid ühte virtuaalset mikroprotsessorit Üldine otstarve. Pidevalt kasvavate jõudlusnõuete ja mikroprotsessorite kulude vähenemise tõttu on tootjad hakanud tootma mitme protsessoriga arvuteid. Tõhususe ja töökindluse parandamiseks kasutatakse sümmeetrilist mitmetöötluse (SMP) tehnoloogiat. See termin viitab arhitektuurile riistvara arvuti, aga ka sellele vastava operatsioonisüsteemi käitumisele arhitektuurne omadus. Sümmeetrilist multitöötlust võib määratleda kui autonoomset arvuti süsteem järgmiste omadustega.

1. Süsteemil on mitu protsessorit.

2. Need protsessorid, mis on omavahel ühendatud sidesiini või mõne muu vooluringiga, jagavad sama põhimälu ja samu I/O seadmeid.

3. Kõik protsessorid saavad täita samu funktsioone (sellest ka nimi sümmeetriline töötlemine).

Sümmeetrilise multitöötlusega süsteemis töötav operatsioonisüsteem jaotab protsessid või lõimed kõigi protsessorite vahel. Mitmeprotsessorilistel süsteemidel on üheprotsessorisüsteemide ees mitmeid potentsiaalseid eeliseid, sealhulgas järgmised.

· Esitus. Kui töö, mida arvuti peab töötama, saab korraldada nii, et selle osad töötavad paralleelselt, on selle tulemuseks parem jõudlus kui sama tüüpi protsessoriga ühe protsessori süsteem. Eespool sõnastatud asend on illustreeritud joonisel fig. 2.12. Multitegumtöötlusrežiimis saab korraga töötada ainult üks protsess, samas kui teised protsessid on sunnitud oma korda ootama. Mitme protsessoriga süsteemis saab samaaegselt töötada mitu protsessi, millest igaüks töötab eraldi protsessoris.

· Töökindlus. Sümmeetrilise multitöötluse korral ei peata ühe protsessori rike masinat, sest kõik protsessorid saavad täita samu funktsioone. Pärast sellist riket jätkab süsteem tööd, kuigi selle jõudlus väheneb veidi.

· Hoone. Süsteemi lisades täiendavad protsessorid, saab kasutaja selle jõudlust parandada.

· Skaleeritavus. Tootjad saavad pakkuda oma tooteid mitmesugustes hinna- ja jõudluskonfiguratsioonides, mis on mõeldud kasutamiseks erinev summa protsessorid.

Oluline on märkida, et ülaltoodud eelised on pigem potentsiaalsed kui garanteeritud. Multiprotsessori potentsiaali õigeks realiseerimiseks arvutussüsteemid, peab operatsioonisüsteem pakkuma piisavat tööriistade ja võimaluste komplekti

Riis. 2.12. Multitegumtöötlus ja multitöötlus

On tavaline, et mitme lõime ja mitme töötlemise kohta arutatakse koos, kuid need kaks mõistet on sõltumatud. Multithreading on kasulik kontseptsioon rakenduste ja kerneli protsesside struktureerimiseks isegi ühe protsessoriga masinas. Teisest küljest võib mitme protsessoriga süsteemil olla eeliseid ühe protsessori süsteemi ees isegi siis, kui protsessid ei ole jagatud mitmeks lõimeks, kuna sellises süsteemis on võimalik käivitada mitu protsessi korraga. Need kaks võimalust on aga omavahel ja nende vahel hästi kooskõlas jagamine võib avaldada märgatavat mõju.

Mitmeprotsessoriliste süsteemide atraktiivne omadus on see, et mitme protsessori olemasolu on kasutajale läbipaistev – nii protsessorite vahel jaotamiseks kui ka sünkroonimiseks. erinevad protsessid operatsioonisüsteem reageerib. Selles raamatus käsitletakse ajastamis- ja sünkroonimismehhanisme, mida kasutatakse selleks, et muuta kõik protsessid ja protsessorid kasutajale ühtse süsteemina nähtavaks. Veel üks ülesanne kõrge tase- mitmest koosnevast klastrist ühe süsteemi kujutamine üksikud arvutid. Sel juhul on tegemist arvutite komplektiga, millest igaühel on oma esmane ja sekundaarne mälu ning oma I/O moodulid. Hajutatud operatsioonisüsteem loob nähtavuse ühine ruum põhi- ja sekundaarmälu, samuti üksikmälu failisüsteem. Kuigi klastrite populaarsus kasvab pidevalt ja turule ilmub üha rohkem klastritooteid, jäävad kaasaegsed hajutatud operatsioonisüsteemid endiselt arenduses alla ühe- ja mitmeprotsessorilistele süsteemidele. Selliste süsteemidega tutvute raamatu kuuendas osas.

Üks uusimaid uuendusi operatsioonisüsteemide disainis on olnud objektorienteeritud tehnoloogiate kasutamine. Objektorienteeritud disain aitab puhastada peamisele väikesele kernelile täiendavate moodulite lisamise protsessi. Operatsioonisüsteemi tasemel võimaldab objektorienteeritud struktuur programmeerijatel kohandada operatsioonisüsteem ilma selle terviklikkust rikkumata. Lisaks hõlbustab see lähenemine hajutatud tööriistade ja täisväärtuslike hajutatud operatsioonisüsteemide arendamist.

Lähenemisviisid IS-i disainile.

Infosüsteemide kujundamisel on kaks peamist lähenemisviisi:

· struktuurne

· protsessi .

Struktuurne lähenemine lähtudes projekteerimisel ettevõtte organisatsioonilise struktuuri kasutamisest süsteem on tulemas struktuurijaotiste kaupa. Tegevustehnoloogiaid kirjeldatakse sel juhul struktuuriüksuste töötehnoloogiate ja nende koostoime kaudu.

Kui ettevõte on keeruline struktuur ettevõtte tüüpi või ettevõtte võrgustiku jaoks on vaja ka kõigi selle elementide koostoime mudelit, mis ei kajasta mitte ainult tehnoloogilisi, vaid ka finants- ja õiguslikke aspekte.

Peamine puudus Struktuurne lähenemine on lüli organisatsioonilise struktuuriga, mis muutub väga kiiresti, mistõttu tuleb sageli muudatusi teha ka infosüsteemi Süsteemiprojektis. Ja valmis IP muutmine on reeglina üsna töömahukas, pikk ja tüütu protsess.

Protsessi lähenemine keskendunud mitte organisatsiooni struktuurile, vaid äriprotsessidele, s.o. näiteks ettevõte tegeleb seadmete tarnimisega, komponentide ja varuosade tarnimisega, seadmete hooldusega jne. Need on tema äriprotsessid, mida tuleks analüüsida IS-i kavandamise 1. etapis.

Protsessi lähenemine on paljutõotavam, kuna. äriprotsessid muutuvad erinevalt organisatsiooni struktuurist harvemini. Pealegi on ettevõttes vähe peamisi äriprotsesse, tavaliselt mitte rohkem kui kümme.

Kaasaegsetes tingimustes on infosüsteemide loomise keerukus väga kõrge. Seetõttu on IC-de projekteerimisel CASE-tehnoloogiat nüüdseks laialdaselt kasutatud.

CASE tehnoloogia - See tarkvarapakett mis automatiseerib kõik tehnoloogiline protsess kompleksi analüüs, projekteerimine, arendus ja hooldus tarkvara tööriistad.

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-i arendamise kõige aeganõudvamad etapid on analüüsi ja disaini etapid, mille käigus CASE-tööriistad tagavad vastuvõetud andmete kõrge kvaliteedi. tehnilisi lahendusi ja koolitust projekti dokumentatsioon. Samal ajal on oluline roll graafilised abivahendid domeeni modelleerimine, mis võimaldab arendajatel olemasolevat IS-i visuaalselt uurida, seda vastavalt eesmärkidele ja olemasolevatele piirangutele ümber ehitada.

Integreeritud CASE-tööriistadel on järgmised omadused iseloomulikud tunnused :

· IS arendusprotsessi juhtimise tagamine;

Spetsiaalselt organiseeritud projekti metaandmete hoidla (hoidla) kasutamine.

Integreeritud CASE-tööriistad sisaldavad järgmisi komponente:

· IS kirjeldamiseks ja dokumenteerimiseks kasutatavad graafilise analüüsi ja disaini vahendid;

Rakenduste arendustööriistad, sealhulgas programmeerimiskeeled ja koodigeneraatorid;

hoidla, mis pakub arendatava projekti versioonide ja selle üksikute komponentide salvestamist, saadud teabe sünkroonimist erinevad arendajad rühmaarenduses metaandmete kontroll täielikkuse ja järjepidevuse tagamiseks;

· juhtimisvahendid IS-i arendamiseks;

dokumenteerimisvahendid;

testimisvahendid;

Reengineering tööriistad, mis võimaldavad analüüsida programmikoode ja andmebaasi skeeme ning nende alusel moodustamist erinevaid mudeleid ja disaini spetsifikatsioonid.

Kõik kaasaegsed CASE-tööriistad on jagatud kahte rühma. esimene rühm korraldada juurutussüsteemi sisseehitatud tööriistad, milles kõik disaini- ja juurutusotsused on seotud valitud andmebaasihaldussüsteemiga. teine ​​rühm korraldada rakendussüsteemist sõltumatud vahendid, mille puhul kõik disainiotsused on keskendunud ühendamisele esialgsed etapid elutsükkel ja nende dokumenteerimise vahendid. Need vahendid pakuvad suuremat paindlikkust rakendusvahendite valikul.

Peamine väärikust CASE-tehnoloogiad - projekti meeskonnatöö tugi tänu töövõimele kohalik võrk, projekti üksikute fragmentide eksport ja import arendajate vahel, organiseeritud juhtimine projekt.

Nagu etapid infosüsteemide tarkvaratoodete loomisel võib eristada järgmist:

1. Määratakse kindlaks tegevuskeskkond. Selles etapis määratakse IS elutsükli protsesside kogum, määratakse IS ulatus, määratakse toetatavate rakenduste suurus, s.t. seatakse piirangud sellistele väärtustele nagu programmikoodi ridade arv, andmebaasi suurus, andmeelementide arv, juhtobjektide arv jne.

2. Teostatakse skeemide koostamine ja graafiline analüüs. Selles etapis koostatakse diagrammid, mis loovad ühenduse teabeallikate ja tarbijatega, määravad andmete teisendamise protsessid ja nende salvestuskohad.

3. Määratakse kindlaks spetsifikatsioonid ja nõuded süsteemile (liidese tüüp, andmetüüp, süsteemi struktuur, kvaliteet, jõudlus, tehnilised vahendid, kogukulud jne).

4. Teostatakse andmete modelleerimine, s.o. sisestatakse informatsioon, mis kirjeldab süsteemi andmeelemente ja nende seoseid.

5. Teostatakse protsesside modelleerimine, s.o. tutvustatakse teavet, mis kirjeldab süsteemi protsesse ja nende seoseid.

6. Projekteerimisel on tulevase tarkvara arhitektuur.

7. Simulatsioon on pooleli, s.o. modelleerimine erinevaid aspekte süsteemi toimimine nõuete spetsifikatsioonide ja/või palusel.

8. Prototüüpimine, s.o. luuakse kogu süsteemi või selle üksikute komponentide esialgne versioon.

9. Jälgimine, teostatakse süsteemi toimimise analüüs alates nõuete täpsustamisest kuni lõpptulemusteni.

10. Programmikood genereeritakse, kompileeritakse ja silutakse.

11. Saadud tarkvara testimine. Saadud tulemuste analüüs ja hindamine.