1.1 Käsite - "CASE-työkalut"

Aluksi termi "CASE-tekniikka" (Computer - Aided Software Engineering) ymmärrettiin kirjaimellisesti - "automaattinen IS-ohjelmiston kehittäminen tietokoneteknologiaa käyttäen."

Tällä hetkellä termi CASE-tools viittaa laajaan ohjelmistotyökalusarjaan, joka tukee IS:n luomis- ja ylläpitoprosesseja, mukaan lukien vaatimusten analysointi ja muotoilu, sovellusohjelmistojen (sovellusten) ja tietokantojen suunnittelu, koodin generointi, testaus, dokumentointi, laadunvarmistus, konfiguraatioiden hallinta ja projektinhallinta sekä muut prosessit. CASE-työkalut yhdessä järjestelmäohjelmiston ja -laitteiston kanssa muodostavat täydellisen IS-kehitysympäristön.

CASE-teknologiat ovat menetelmiä ja työkaluja analyytikoille, kehittäjille ja ohjelmoijille, jotka on suunniteltu automatisoimaan IS:n suunnittelua ja ylläpitoa koko elinkaaren ajan.

CASE-työkalumetodologia määrittelee projektin toteuttamisen vaiheet ja vaiheet sekä säännöt niiden menetelmien käyttöön, joilla projektia kehitetään. CASE-työkalumenetelmä on menettely tai tekniikka tietojärjestelmän komponenttien kuvausten luomiseksi (virtojen ja tietorakenteiden suunnittelu). CASE-työkalun merkintä - näyttää järjestelmän rakenteen, tietoelementit erityisillä graafisilla symboleilla.

CASE-työkalut ovat erityisiä ohjelmia jotka tukevat yhtä tai useampaa analyysi- ja suunnittelumenetelmää tietojärjestelmä. CASE-teknologiaan sisältyy metodologian puitteissa menetelmiä, joilla kaavioita rakennetaan tietyn CASE-työkalun tukemien merkintöjen perusteella. CASE-teknologioita ei voida pitää itsenäisinä, ne tarjoavat vain korkean sovelluksensa tehokkuuden, joka määräytyy projektin kehitysajankohdan mukaan.

Nykyaikaiset CASE-työkalut kattavat laajan tukialueen lukuisille tietojärjestelmien suunnittelutekniikoille: alkaen yksinkertaisia ​​keinoja analyysi ja dokumentointi täysimittaisiin automaatiotyökaluihin, jotka kattavat ohjelmiston koko elinkaaren. Tietojärjestelmien kehittämisen aikaa vievimmät vaiheet ovat analyysi- ja suunnitteluvaiheet, joiden aikana CASE-työkalut varmistavat tehtyjen teknisten päätösten laadun ja projektidokumentaation valmistelun. Samaan aikaan tiedon visuaalisen esittämisen menetelmillä on tärkeä rooli. Tämä edellyttää rakenteellisten tai muiden kaavioiden rakentamista reaaliajassa, useiden erilaisten kaavioiden käyttöä väripaletti, syntaktisten sääntöjen päästä päähän -tarkistus. Graafisten alueiden mallinnustyökalujen avulla kehittäjät voivat visuaalisesti tutkia olemassa olevaa tietojärjestelmää, rakentaa sitä uudelleen tavoitteiden ja olemassa olevien rajoitusten mukaisesti.

1.2 Tyypillinen CASE-työkalujen rakenne

CASE-työkalut toimivat työkaluina rakenneanalyysimenetelmien tukemiseen ja käyttöön suunnittelussa. Nämä työkalut tukevat käyttäjien työtä graafisen projektin luomisessa ja muokkaamisessa interaktiivinen tila. He osallistuvat hankkeen organisointiin abstraktiotasojen hierarkian muodossa, suorittavat komponenttien vaatimustenmukaisuuden tarkastuksia. Itse asiassa CASE-työkalut ovat uudentyyppisiä graafisia työkaluja, jotka juontavat juurensa ohjelmiston elinkaaren tukijärjestelmästä. Tyypillisesti ne sisältävät minkä tahansa ohjelmistotyökalun, joka tarjoaa automaattista apua ohjelmistokehityksessä, ylläpidossa tai projektinhallinnassa ja sisältää seuraavat lisäominaisuudet:

tehokas grafiikka ohjelmistojärjestelmien kuvaamiseen ja dokumentointiin tietyllä käyttöliittymällä, joka kehittää asiantuntijoiden luovia kykyjä ja ei häiritse suunnitteluprosessia toissijaisten ongelmien ratkaisemiseen;

integraatio, joka helpottaa tiedonsiirtoa työkalujen välillä ja mahdollistaa koko ohjelmiston suunnittelu- ja kehitysprosessin hallinnan suoraan projektin suunnitteluprosessin kautta;

tietokonetallennustilan (arkisto) käyttö projektin osien ja yksittäisten elementtien malleille, joita eri kehittäjät voivat käyttää pohjana ohjelmistojen automaattiselle tuotannolle ja niiden uudelleenkäytölle tulevissa järjestelmissä.

Kaikkien arkiston projektitietojen graafisen orientoinnin, integroinnin ja lokalisoinnin lueteltujen perusperiaatteiden lisäksi CASE-työkalujen käsitteellinen rakenne perustuu seuraaviin säännöksiin:

1. Inhimillinen tekijä, joka määrittelee ohjelmistokehityksen helpoksi, käteväksi ja taloudelliseksi prosessiksi.

2. Muissa sovelluksissa yleistyneiden perusohjelmistotyökalujen (tietokanta ja DBMS, kääntäjät eri ohjelmointikielille, debuggerit, dokumentoijat, julkaisujärjestelmät, asiantuntijajärjestelmän kuoret ja tietokannat, neljännen sukupolven kielet jne.) laaja käyttö.

3. Automaattinen tai automaattinen koodin luominen, varten erilaisia ​​alustoja ja erityyppiset koodit: muunnokset dokumentaation saamiseksi; tietokantarakenteen muodostaminen, tietojen syöttäminen/muokkaus; suoritettavien konekoodien hankkiminen ohjelmistospesifikaatioista; moduulien kokoaminen sanakirjoista ja tietomalleista sekä uudelleenkäytettävistä ohjelmista.

4. Helppokäyttöisyys, jonka avulla saat hallittavia, näkyviä ja ymmärrettäviä komponentteja sekä yksinkertaisen ja selkeän rakenteen.

5. Saatavuus eri käyttäjäryhmille.

6. Kannattavuus.

7. Tehokas tehtävien ratkaisu kehitettyä projektia tukevaksi, tarjoten kykyä sopeutua asiakkaan toimesta projektin vaatimusten ja tavoitteiden muuttuessa.

Lähes kaikki nykyaikaiset CASE-työkalut sisältävät seuraavat elementit:

arkisto, jonka avulla voit varmistaa projektimallien ja sen erityiskomponenttien turvallisuuden, synkronoida eri kehittäjiltä saatuja tietoja ryhmän kehitysprosessissa, tarkistaa metatietojen täydellisyyden ja johdonmukaisuuden;

sovelluskehitystyökalut, jotka käyttävät 4GL-kieliä ja koodigeneraattoreita;

testaustyökalut;

dokumentointivälineet;

graafiset analyysi- ja suunnittelutyökalut, jotka mahdollistavat tietojärjestelmämallien luomisen ja muokkaamisen hierarkkisesti linkitettyjen kaavioiden muodossa tietyn metodologian toteutetuissa merkinnöissä;

uudelleensuunnittelu työkalut;

kokoonpanon hallintatyökalut;

projektinhallinnan työkalut.

1.3 CASE-tekniikoiden kehityksen kehitys

Alusta alkaen CASE-teknologioita on kehitetty tavoitteena voittaa 60-70-luvun rakenneanalyysi- ja suunnittelumetodologian "manuaalisen" soveltamisen rajoitukset automatisoimalla ja integroimalla tukityökaluihin. Näin ollen CASE-teknologioita ei voida pitää itsenäisinä mallinnusmenetelminä, ne vain tehostavat niiden soveltamista kehitysajan suhteen.

Perinteisesti erotetaan kuusi ajanjaksoa, jotka ovat laadullisesti erilaisia ​​sovelletussa tekniikassa ja ohjelmistokehityksen menetelmissä, joille on ominaista käyttö työkaluina:

1. Kokoonpanolaitteet, muistivedot, analysaattorit;

2. Kääntäjät, tulkit, jäljityslaitteet;

3. Symboliset debuggerit, ohjelmistopaketit;

4. Lähdetekstien analysointi- ja hallintajärjestelmät;

5. CASE-työkalut vaatimusten analysointiin, spesifikaatioiden ja rakenteen suunnitteluun, rajapintojen editointiin (CASE-I:n ensimmäinen sukupolvi);

6. CASE:n luontityökalut lähdekoodi ja integroidun ympäristön käyttöönotto ohjelmistokehityksen koko elinkaaren tukemiseksi (toinen sukupolvi CASE-II)

CASE-I on ensimmäinen suoraan järjestelmäanalyytikoille ja suunnittelijoille suunnattu tekniikka, joka sisältää työkaluja graafisten mallien, suunnittelun spesifikaatioiden, näyttöeditorien ja tietosanakirjojen tukemiseen. Sitä ei ole tarkoitettu tukemaan koko elinkaarta ja se keskittyy toiminnallisiin spesifikaatioihin ja projektin alkuvaiheisiin - järjestelmäanalyysiin, vaatimusten määrittelyyn, järjestelmien suunnitteluun, loogiseen tietokannan suunnitteluun.

CASE-II:ssa on huomattavasti kehittyneempiä ominaisuuksia, parannettu suorituskyky ja kattava lähestymistapa kehitettävän ohjelmiston koko elinkaareen. CASE-II-työkalupakki käyttää ensisijaisesti automaattista koodinluontitukea ja tarjoaa täyden toiminnallisen tuen graafisten järjestelmävaatimusten ja suunnittelun vaatimusten täyttämiseksi. Järjestelmätietojen ja suunnittelun hallintatietojen ohjaus, analysointi ja linkittäminen; järjestelmän prototyyppien ja mallien rakentaminen; luotujen ohjelmien testaus, todentaminen ja analysointi; projektiasiakirjojen luominen; standardien noudattamisen valvonta elinkaaren kaikissa vaiheissa. CASE-II voi sisältää yli 100 toiminnallista komponenttia, jotka tukevat elinkaaren kaikkia vaiheita, samalla kun käyttäjät voivat valita tarvittavat työkalut ja integroida ne haluttuun koostumukseen.

1.4 CASE-työkaluissa käytetyt suunnittelumenetelmät

CASE-työkalut ovat tulosta työkalu- (tai teknologia-) teollisuuden luonnollisesta kehityksestä. CASE-tekniikoita alettiin kehittää strukturoidun ohjelmoinnin metodologian rajoitusten voittamiseksi.

Tälle menetelmälle ohjelmoinnin formalisoinnista huolimatta on edelleen ominaista ymmärtämisen monimutkaisuus, korkea työvoimaintensiteetti ja käyttökustannukset sekä suunnittelun spesifikaatioiden muuttamisen vaikeus. Siinä määritellyt periaatteet mahdollistivat tämän metodologian kehittämisen ja tehokkuuden lisäämisen automatisoimalla rutiinisimpia vaiheita (kuva 1.1).

CASE-työkaluissa toteutettujen menetelmien tärkeimmät standardit ovat:

SADT (Structured Analysis and Design Technique) - rakenneanalyysin ja suunnittelun metodologia. Perustuu toiminnallisen mallintamisen käsitteisiin. Heijastaa järjestelmän ominaisuuksia, kuten ohjausta, palautetta ja esiintyjää;

IDEF0 (Integrated Definition Function Modeling) on ​​toiminnallinen mallinnusmenetelmä. Sen avulla luodaan toiminnallinen malli, joka esittää järjestelmän rakenteen ja toiminnot sekä näiden toimintojen muuntaman tiedon ja materiaalien kulkua. Se on osa SADT-metodologiaa;

DFD (DataFlow Diagram) - menetelmä tietovirtojen mallintamiseen.

Kuva 1.1 - Perinteisen kehityksen ja CASE-teknologioiden kehittämisen vertailu

Seuraavia metodologisia standardeja sovelletaan kuvaamaan työnkulkujen välistä tiedonvaihtoa:

IDEF1:tä käytetään tietomallin rakentamiseen, joka näyttää järjestelmän toimintojen tukemiseen tarvittavien tietovirtojen rakenteen ja sisällön;

IDEF2:n avulla voit rakentaa dynaamisen mallin järjestelmän toimintojen, tietojen ja resurssien ajallisesti muuttuvasta käyttäytymisestä;

IDEF3 on työnkulun mallinnusmenetelmä. On yksityiskohtaisempi IDEF0:n ja DFD:n suhteen. Voit tarkastella tiettyä prosessia ottaen huomioon suoritettujen toimintojen järjestyksen. IDEF3 kuvaa kunkin prosessin skenaarion ja toimintosarjan;

IDEF1X (IDEF1 Extended) - tietojen kuvausmenetelmä. Käytetään tietokantojen rakentamiseen. Viittaa metodologian tyyppiin "Entity-Relationship" (ER - Entity-Relationship) ja sitä käytetään pääsääntöisesti mallintamaan kyseessä olevaan järjestelmään liittyviä relaatiotietokantoja;

IDEF4 on olio-menetelmä. Heijastaa esineiden vuorovaikutusta. Voit näyttää visuaalisesti objektien rakenteen ja niiden vuorovaikutuksen taustalla olevat periaatteet. Kätevä ohjelmistotuotteiden luomiseen oliokielillä;

IDEF5 - metodologia monimutkaisten järjestelmien ontologiseen tutkimukseen. IDEF5-metodologialla järjestelmäontologiaa voidaan kuvata käyttämällä erityistä termien ja sääntöjen sanastoa, jonka perusteella voidaan muodostaa luotettavia lausuntoja tarkasteltavana olevan järjestelmän tilasta jossain vaiheessa;

ARIS - kuvaa liiketoimintaprosessia peräkkäisten töiden virtana;

UML - Unified Modeling Language (Unified Modeling Language) yhtenäinen mallinnuskieli, joka perustuu oliolähtöiseen lähestymistapaan. UML:n avulla voit kuvata järjestelmän staattista rakennetta ja sen dynaamista käyttäytymistä sopivilla merkinnöillä.

CASE-työkalut käyttävät laajasti rakenteellisia ja oliopohjaisia ​​suunnittelumenetelmiä. Rakennesuunnittelu perustuu algoritmiseen hajotukseen, kun taas oliosuunnittelu perustuu oliosuuntautuneeseen hajotukseen. Algoritminen hajottaminen antaa sinun määrittää tapahtumien järjestyksen. Oliosuuntautuneen hajotuksen avulla voit määrittää objektiluokkien hierarkian, niiden menetelmät ja ominaisuudet. Olio-suunnittelua tukevat CASE-työkalut käyttävät RUP-metodologiaa (Rational Unified Process) ja UML-merkintöjä.

1.5 CASE-työkalujen metodologia olio-suunnittelussa

Oliokeskeisessä lähestymistavassa oliomallin pääkategoria, luokka, yhdistää alkeetasolla sekä datan että niille suoritettavat toiminnot (menetelmät). Tästä näkökulmasta katsottuna muutokset, jotka liittyvät siirtymiseen rakenteellisesta oliolähtöiseen lähestymistapaan, ovat havaittavissa. Prosessien ja datan erottelu on voitettu, mutta järjestelmän monimutkaisuuden voittamisen ongelma on edelleen olemassa, mikä ratkaistaan ​​komponenttimekanismin avulla.

Prosesseihin verrattuna data on vakaampi ja suhteellisen harvinainen osa järjestelmää. Tämä on oliolähtöisen lähestymistavan tärkein etu, jonka Gradi Booch muotoili seuraavasti: oliojärjestelmät ovat avoimempia ja helpompia muuttaa, koska niiden suunnittelu perustuu vakaisiin muotoihin. Tämä mahdollistaa järjestelmän asteittaisen kehittymisen eikä johda sen täydelliseen käsittelyyn edes silloin, kun alkuperäisissä vaatimuksissa tapahtuu merkittäviä muutoksia.

Booch panee merkille myös joukon seuraavia oliokeskeisen lähestymistavan etuja.

1. Objektihajotus mahdollistaa pienempien ohjelmistojärjestelmien luomisen käyttämällä yhteisiä mekanismeja, jotka tarjoavat tarvittavan ilmaisukeinojen taloudellisuuden. Objektilähestymistavan käyttö lisää merkittävästi ohjelmien, vaan myös projektien kehittämisen yhtenäistämisen tasoa ja uudelleenkäytettävyyttä, mikä johtaa viime kädessä kehitysympäristön luomiseen ja siirtymiseen kokoonpanoohjelmistokehitykseen. Järjestelmät ovat usein kompakteja kuin rakenteelliset vastineet, mikä ei tarkoita vain vähemmän koodia, vaan myös halvempia malleja aiempia malleja hyödyntäen.

2. Objektien hajottaminen vähentää riskiä luoda monimutkaisia ​​ohjelmistojärjestelmiä, koska siihen liittyy järjestelmän kehityskulku, joka perustuu suhteellisen pieniin osajärjestelmiin. Järjestelmän integrointiprosessi venyy koko kehitysjaksolle, eikä se muutu kertaluonteiseksi tapahtumaksi.

3. Objektimalli on varsin luonnollinen, koska se keskittyy ensisijaisesti ihmisen maailmankuvaan, ei tietokonetoteutukseen.

4. Oliomallin avulla voit hyödyntää täysimääräisesti olio- ja olioohjelmointikielten ilmaisukykyä.

Olio-lähestymistavan haittoja ovat ohjelmiston suorituskyvyn heikkeneminen ja korkeat alkukustannukset. Objektien hajoaminen eroaa merkittävästi toiminnallisesta hajoamisesta, joten siirtyminen uuteen tekniikkaan liittyy sekä psykologisten vaikeuksien voittamiseen että lisäkustannuksiin. Tietenkin oliosuuntautunut malli heijastaa parhaiten todellista maailmaa, joka on kokoelma vuorovaikutuksessa (viestinnän kautta) olevia objekteja. Mutta käytännössä UML-kielistandardin muodostuminen oliomallinnukseen jatkuu tällä hetkellä ja oliolähtöistä lähestymistapaa tukevien CASE-työkalujen määrä on pieni verrattuna vastaaviin rakenteellista lähestymistapaa tukeviin työkaluihin.

Lisäksi objektilähestymistavan erityispiirteitä heijastavat kaaviot (luokkakaaviot jne.) ovat paljon vähemmän visuaalisia ja ei-ammattilaisten ymmärtämiä. Siksi yksi CASE-teknologian käyttöönoton päätavoitteista, nimittäin kaikkien projektiin osallistujien (mukaan lukien asiakas) tarjonta yhteinen kieli"välittää ymmärrystä", tarjotaan nykyään vain rakenteellisilla menetelmillä.

Siirtyessäsi rakenteellisesta lähestymistavasta objektilähestymistapaan, kuten kaikissa teknologian muutoksissa, on investoitava uusien työkalujen hankintaan. Tässä tulee ottaa huomioon myös koulutuksen kustannukset (menetelmän, työkalujen ja ohjelmointikielen hallinta). Joillekin organisaatioille nämä olosuhteet voivat olla vakavia esteitä. Oliolähtöinen lähestymistapa ei anna välitöntä tuottoa. Sen soveltamisen vaikutus alkaa näkyä kahden tai kolmen hankkeen kehittämisen ja tämän alueen tyypillisiä suunnitteluratkaisuja heijastavien uudelleenkäytettävien komponenttien kertymisen jälkeen. Organisaation siirtyminen olioteknologiaan on mielenmuutos, ei vain uusien CASE-työkalujen ja ohjelmointikielten oppimista.

On selvää, että tietyssä projektissa on mahdotonta hajottaa monimutkaista järjestelmää kahdella tavalla samanaikaisesti. Hajotus voidaan aloittaa yhdellä tavalla ja sitten tulosten avulla yrittää tarkastella järjestelmää eri näkökulmasta. Siirrytään nyt tarkastelemaan rakenteellisen ja oliolähtöisen lähestymistavan välistä suhdetta. Suhteen perusta on useiden molempien lähestymistapojen kategorioiden ja käsitteiden yhteisyys (prosessi- ja käyttötapaus, entiteetti ja luokka jne.). Tämä suhde voi ilmetä eri muodoissa. Eräs mahdollinen lähestymistapa on siis käyttää rakenneanalyysiä oliosuuntautuneen suunnittelun perustana. Tämä lähestymistapa on tarkoituksenmukainen rakenneanalyysiä tukevien CASE-työkalujen laajan levinneisyyden vuoksi. Rakenneanalyysi jatkuu siihen asti, kun tietovuokaaviot alkavat heijastaa aihealueen lisäksi myös ohjelmistojärjestelmää.

Kun olet suorittanut rakenneanalyysin ja piirtänyt tietovuokaaviot sekä tietorakenteet ja muut analyysitulokset, voit alkaa määritellä luokkia ja objekteja eri tavoilla. Joten jos otamme minkä tahansa erillisen kaavion, niin ulkoiset entiteetit ja tietovarastot voivat olla ehdokkaita objekteille ja tietovirrat voivat olla ehdokkaita luokille.

Toisena suhteen ilmenemismuotona voidaan pitää objekti- ja relaatioteknologian integrointia. Relaatiotietokantajärjestelmät ovat nykyään tärkein keino toteuttaa suuria tietokantoja ja tietovarastoja. Syyt tähän ovat ilmeiset: relaatioteknologiaa on käytetty pitkään, valtava määrä käyttäjiä ja kehittäjiä hallitsee, siitä on tullut alan standardi, siihen on investoitu merkittäviä varoja ja useita yritystietokantoja on luotu eri toimialoilla, relaatiomalli on yksinkertainen ja sillä on tiukka matemaattinen perusta; relaatiotietokantojen suunnitteluun, toteuttamiseen ja käyttämiseen on olemassa laaja valikoima teollisia työkaluja. Tästä johtuen relaatiotietokantoja käytetään pääasiassa objektien tallentamiseen ja etsimiseen niin sanotuissa oliorelaatiojärjestelmissä. Oliosuuntautuneella suunnittelulla on yhteistä perustaa relaatiosuunnittelun kanssa. Esimerkiksi, kuten edellä todettiin, oliomallin luokat voivat jollain tavalla vastata entiteettejä (harjoituksena suositellaan analysoimaan yksityiskohtaisesti kaikki entiteetti-suhdekaavioiden ja luokkakaavioiden väliset yhtäläisyydet ja erot). Yleensä tällainen kirjeenvaihto tapahtuu vain järjestelmän kehittämisen varhaisessa vaiheessa - vaatimusten muodostusvaiheessa. Jatkossa oliosuunnittelun (aihealueen riittävä mallintaminen objektien vuorovaikutuksen kannalta) ja relaatiotietokannan kehittämisen (datan normalisoinnin) tavoitteet tietysti eroavat toisistaan. Siten ainoa mahdollinen keino tämän aukon voittamiseksi on määrittää olio- ja relaatioteknologian välinen vastaavuus, joka periaatteessa tiivistyy relaatiomallin luokkakaavioiden ja entiteetti-suhdekaavioiden näyttämiseen. Yksi esimerkki rakenteellisen ja oliolähestymistavan välisen suhteen käytännön toteutuksesta on ohjelmiston käyttöliittymä(silta) rakenteellisen CASE-työkalun Silverrun ja venäläisen Argussoftin kehittämän olio-CASE-työkalun Rational Rose välillä, joka luo Rational Rose -luokkakaavioita Silverrun RDM (Relational Data Model) -mallin perusteella ja päinvastoin. Samanlaisia ​​rajapintoja on myös ERwin CASE -työkalujen (toisaalta), Rational Rosen ja Paradigm Plusin välillä (toisaalta).

1.6 Rakennesuunnittelun metodologia CASE-työkalut

Tietojärjestelmien kehittämisen rakenteellisen lähestymistavan ydin on sen hajottaminen (osiointi) automatisoiduiksi toiminnoiksi. Automatisoitu järjestelmä on jaettu toiminnallisiin alajärjestelmiin, jotka puolestaan ​​on jaettu alitoimintoihin, jaettu tehtäviin ja niin edelleen. Osiointiprosessi jatkuu tiettyihin toimenpiteisiin asti. Samaan aikaan automatisoitu järjestelmä säilyttää kokonaisvaltaisen näkymän, jossa kaikki komponentit on yhdistetty toisiinsa. Kun kehitetään "alhaalta ylös" -järjestelmää yksittäisistä tehtävistä koko järjestelmään, eheys katoaa, ongelmia syntyy tiedon telakoinnissa yksittäisiä komponentteja.

Kaikki yleisimmät rakenteelliset lähestymistavat perustuvat useisiin yleisiin periaatteisiin. Pääperiaatteet ovat:

hajoamisperiaate - päätösperiaate vaikeita ongelmia jakamalla ne useisiin pienempiin ja itsenäisiin tehtäviin, jotka on helppo ymmärtää ja ratkaista;

hierarkkisen järjestyksen periaate - periaate järjestää ongelman osat hierarkkisiksi puurakenteiksi lisäämällä uusia yksityiskohtia jokaiselle tasolle.

abstraktion periaate - on korostaa järjestelmän oleellisia puolia ja abstraktio ei-olennaisista;

formalisoinnin periaate - on tiukan metodologisen lähestymistavan tarve ongelman ratkaisemiseksi;

johdonmukaisuuden periaate - perustuu järjestelmän elementtien käytön pätevyyteen ja johdonmukaisuuteen;

Tietojen strukturoinnin periaate on, että datan tulee olla jäsenneltyä ja hierarkkisesti järjestettyä.

Rakenneanalyysissä käytetään pääasiassa kahta työkaluryhmää, jotka havainnollistavat järjestelmän toimintoja ja tietojen välisiä suhteita.

Jokainen työkaluryhmä vastaa tietyntyyppisiä malleja (kaavioita), joista yleisimmät ovat seuraavat:

SADT (Structured Analysis and Design Technique) -mallit ja niihin liittyvät toimintakaaviot;

DFD (Data Flow Diagrams) -tietovuokaaviot;

ERD (entity-relationship diagrams)

Tietojärjestelmän (IS) suunnitteluvaiheessa mallit monimutkaistuvat, jalostuvat ja täydennetään ohjelmiston rakennetta ja arkkitehtuuria kuvaavilla kaavioilla, ohjelmien lohkokaavioilla ja näyttömuotojen kaavioilla. Listatut mallit yhdessä antavat täydellisen kuvauksen IS:stä riippumatta siitä, onko se olemassa vai vasta kehitetty. Kaavioiden koostumus kussakin tapauksessa riippuu järjestelmän kuvauksen vaaditusta täydellisyydestä.

2.2 Kehittäminen Havainnemalli tietojärjestelmä.

Käsitteellinen malli edustaa objekteja ja niiden suhteita määrittelemättä, kuinka ne fyysisesti tallennetaan. Siten käsitteellinen malli on pohjimmiltaan aluemalli. Käsitteellistä mallia suunniteltaessa tiedot tulee jäsentää ja niiden väliset suhteet tunnistaa ottamatta huomioon toteutuspiirteitä ja tehokkuuskysymyksiä.

käsittelyä. Konseptuaalisen mallin suunnittelu perustuu mainostoimiston tehtävien analyysiin. Käsitteellinen malli sisältää kuvaukset kohteista ja niiden suhteista, jotka kiinnostavat tarkasteltavalla aihealueella ja tunnistetaan data-analyysin tuloksena.

Tarvittavan mallin rakentamiseksi toimme kaikki saatavilla olevat tiedot kolmanteen normaalimuotoon, jonka tuloksena saimme seuraavat kokonaisuudet:

tyyppisiä ruokia.

· Henkilöstö.

· Asemat.

· Vakioasiakkaat.

· Tilaukset.

Rakennamme mallin loogisella tasolla (katso kuva 2). Kuvasta 2 näkyy, että mallissa on linkkejä. Tarkastellaanpa niitä tarkemmin:

Taulukko "Ruokatyypit" ja taulukko "Ateriat" - yksi-moneen-suhde muodostetaan käyttämällä pääavain"Näytä koodi";

"Positiot"-taulukko ja "Henkilökunta" -taulukko - yksi-moneen-suhde muodostetaan käyttämällä ensisijaista avainta "Sijaintikoodi";

"Dishes"-taulukko ja "Tilaukset"-taulukko - "yksi moneen" -suhde on muodostettu käyttämällä "Dish Code" -pääavainta;

Taulukko "Henkilöstö" ja taulukko "Tilaukset" - yksi-moneen-suhde muodostetaan ensisijaisella avaimella "Työntekijätunnus";

Taulukko "Kantaasiakkaat" ja taulukko "Tilaukset" - yksi-moneen-suhde muodostetaan ensisijaisella avaimella "Asiakastunnus".

Riisi. 2. Käsitteellinen tietomalli

2.3 Tietojärjestelmän loogisen mallin kehittäminen

Tietokannat ja ohjelmistotyökalut niiden luomiseen ja ylläpitoon (DBMS) ovat monitasoisia arkkitehtuuria, josta saa käsityksen kuvasta 1.

Kaavio 1 - Tietokantatietojen monitasoinen esitys alla

DBMS-hallinta

Näillä tietokannoilla on käsitteellinen, sisäinen ja ulkoinen esitystaso, jotka vastaavat samankaltaisia ​​malleja.

Käsitteellinen taso vastaa toimialueen tietojen integroidun esittämisen loogista puolta. Käsitteellinen malli koostuu useista eri tietotyyppien esiintymistä, jotka on jäsennelty DBMS:n tietokannan loogista rakennetta koskevien vaatimusten mukaisesti.

Sisäinen kerros edustaa tietojen vaadittua järjestystä tallennusympäristössä ja vastaa tietojen esittämisen fyysistä puolta. Sisäinen malli koostuu yksittäisistä tietuetapahtumista, jotka on fyysisesti tallennettu ulkoiselle tietovälineelle.

Ulompi kerros tukee vaadittuja yksityisten tietojen esityksiä tietyt käyttäjät. Ulkoinen malli on käsitteellisen mallin osajoukko. Mahdollinen risteys ulkoisia malleja mukaan. Tietyn sovelluksen (tehtävän) tai käyttäjän yksityinen looginen tietorakenne vastaa ulkoista tietokantamallia tai alikaaviota. Ulkoisten mallien avulla tuetaan valtuutettua pääsyä sovellustietokantatietoihin (sovelluksessa saatavilla olevan tietokannan käsitteellisen mallidatan koostumus ja rakenne on rajoitettu, samoin kuin näiden tietojen sallitut käsittelytavat asetetaan: syöttö, muokkaus, poisto, haku).

Tietokannan suunnittelu koostuu toisiinsa yhdistetyn tiedon kompleksin rakentamisesta. Kuva 2 esittää ehdollisesti tietokannan suunnitteluprosessin vaiheet.

Kaavio 2 - Tietokannan suunnitteluprosessin vaiheet

Tietokannan suunnittelun tärkein vaihe on aihealueen informaatioloogisen (infologisen) mallin kehittäminen, joka ei ole suunnattu DBMS:ään. Infologisessa mallissa tietorakenteiden välineet integroidussa muodossa heijastavat tiedon koostumusta ja rakennetta sekä tietotarpeita.

Aihealueen informaatiolooginen (infologinen) malli heijastaa aihealuetta joukon tietoobjekteja ja niiden rakenteellisia suhteita.

Yksi moniin (1:M) -suhteessa yksi tiedon A esiintymä vastaa 0, 1 tai useampaa objektin B esiintymää, mutta jokainen objektin B esiintymä liittyy enintään yhteen objektin A esiintymään.

Esimerkki 1:M-suhteesta on tietoobjektien välinen suhde Sukunimi - Palkka:

Sukunimi Palkka

Tietokanta tallentaa tiedot kaksiulotteisten taulukoiden muodossa. Voit myös tuoda ja linkittää taulukoita muista DBMS- tai taulukkolaskentajärjestelmistä. 1024 pöytää voidaan avata samanaikaisesti.

Tarvittavia tietokantataulukoita määritettäessä on tarpeen antaa kolme ensimmäistä normaalimuotoa, ts. suorittaa normalisointia.

Samat tiedot voidaan ryhmitellä taulukoiksi (relaatioiksi) eri tavoin, ts. on mahdollista järjestää erilaisia ​​toisiinsa liittyvien tietoobjektien suhteita. Attribuuttien ryhmittelyn suhteissa tulee olla rationaalista, ts. päällekkäisten tietojen minimointi ja niiden käsittely- ja päivitysmenettelyjen yksinkertaistaminen.

Tietyllä relaatiojoukolla on paremmat ominaisuudet tietojen sisällyttämiseen, muokkaamiseen, poistamiseen kuin kaikilla muilla mahdollisilla relaatiosarjoilla, jos se täyttää suhteiden normalisoinnin vaatimukset.

Relaatioiden normalisointi on muodollinen relaatioiden (taulukoiden) muodostumisen rajoitusten laite, jonka avulla voit poistaa päällekkäisyyksiä, varmistaa tietokantaan tallennettujen tietojen johdonmukaisuuden ja vähentää tietokannan ylläpidon (syöttäminen, korjaaminen) työvoimakustannuksia.

E. Codd eritteli kolme normaalia suhteiden muotoa ja ehdotti mekanismia, joka mahdollistaa minkä tahansa suhteen muuntamisen kolmanteen (täydellisimpään) normaalimuotoon.

Ensimmäinen normaali muoto. Relaatiota kutsutaan normalisoiduksi tai pelkistetyksi ensimmäiseen normaalimuotoon, jos kaikki sen attribuutit ovat yksinkertaisia ​​(jäljempänä jakamattomia). Relaation muuntaminen ensimmäiseen normaalimuotoon voi johtaa suhteen attribuuttien (kenttien) määrän kasvuun ja avaimen muutokseen.

Toinen normaali muoto. Jotta voidaan tarkastella kysymystä suhteiden pelkistämisestä toiseen normaalimuotoon, on tarpeen antaa selitykset sellaisille käsitteille kuin toiminnallinen riippuvuus ja täydellinen toiminnallinen riippuvuus.

Tietoobjektin kuvaavat attribuutit on loogisesti linkitetty niille yhteiseen avaimeen, tämä suhde on luonteeltaan attribuuttien toiminnallinen riippuvuus.

Attribuuttien toiminnallinen riippuvuus on riippuvuus, jossa vain yksi kuvaavan attribuutin arvo vastaa tiettyä avainattribuutin arvoa tietoobjektin esiintymässä.

Tällainen toiminnallisen riippuvuuden määritelmä mahdollistaa itsenäisten tietoobjektien erottamisen, kun analysoidaan kaikkia aihealueen yksityiskohtien suhteita. Esimerkkinä tarkastellaan graafista esitystä työntekijöiden attribuuttien toiminnallisista riippuvuuksista, joka on esitetty kuvassa 5, jossa avainattribuutti on merkitty tähdellä.

Kuva 1 - Graafinen esitys yksityiskohtien toiminnallisesta riippuvuudesta

Yhdistelmäavaimen tapauksessa otetaan käyttöön toiminnallisesti täydellisen riippuvuuden käsite.

Ei-avainattribuuttien toiminnallisesti täydellinen riippuvuus on, että kukin ei-avainattribuutti on toiminnallisesti riippuvainen avaimesta, mutta ei toiminnallisesti riippuvainen mistään yhdistelmäavaimen osasta.

Relaatio on toisessa normaalimuodossa, jos se on ensimmäisessä normaalimuodossa ja jokainen ei-avainattribuutti on täysin toiminnallisesti riippuvainen yhdistelmäavaimesta.

Kolmas normaalimuoto. Kolmannen normaalimuodon käsite perustuu ei-transitiivisen riippuvuuden käsitteeseen.

Transitiivinen riippuvuus havaitaan, jos toinen kahdesta kuvaavasta attribuutista riippuu avaimesta ja toinen kuvaava attribuutti riippuu ensimmäisestä kuvaavasta attribuutista.

Relaatio on kolmannessa normaalimuodossa, jos se on toisessa normaalimuodossa ja jokainen ei-avainattribuutti ei ole transitiivisesti riippuvainen ensisijaisesta avaimesta.

Kuvaavien yksityiskohtien transitiivisen riippuvuuden eliminoimiseksi on tarpeen "halkaista" alkuperäinen informaatioobjekti. Jakamisen seurauksena jotkin attribuutit poistetaan alkuperäisestä tietoobjektista ja sisällytetään muihin (mahdollisesti uusiin) tietoobjekteihin.

Luodun tietokannan tulee suorittaa toimintoja organisaation tietojen antamisen automatisoimiseksi. Sillä pitäisi olla yksinkertainen ja intuitiivinen käyttöliittymä, ja siinä on oltava vähimmäisjärjestelmävaatimukset.

Työn tarkoituksena on luoda tietokanta, joka tarjoaa:

uusien tietojen nopea syöttö;

jo syötettyjen tietojen tallennus ja haku;

tulostaa tarvittava määrä henkilökohtaisia ​​raportteja.

Tiedot ovat:

Koko nimi;

Syntymäaika;

Tehtävä;

virallinen palkka;

Todellisten työpäivien määrä kuukaudessa.

Yllä määritellyt tehtävät huomioiden voit suunnitella tietokannan päätaulukot.

Käytämme tätä varten Database Desktop -työkaluja.

Tässä ympäristössä luomme kaikki tarvittavat taulukot kehitettävään tietokantaan. Tämän taulukon attribuutit ovat:

Sukunimi, Etunimi, Isännimi, Hyväksymispäivä, Osoite, Puhelin, Vuorot, Poissaolot töistä, Hinta, palkka.

Nykyaikaisen tietotekniikan kehityssuuntaukset johtavat talouden eri osa-alueilla luotujen tietojärjestelmien (IS) monimutkaisuuden jatkuvaan lisääntymiseen. Nykyaikaisille suurille IP-projekteille on pääsääntöisesti tunnusomaista seuraavat ominaisuudet:

kuvauksen monimutkaisuus (melko suuri määrä toimintoja, prosesseja, tietoelementtejä ja niiden välisiä monimutkaisia ​​suhteita), mikä edellyttää tietojen ja prosessien huolellista mallintamista ja analysointia;

joukon läheisesti vuorovaikutuksessa olevia komponentteja (alijärjestelmiä), joilla on omat paikalliset tehtävänsä ja toimintatavoitteensa (esimerkiksi perinteiset tapahtumankäsittelyyn ja rutiiniongelmien ratkaisemiseen liittyvät sovellukset ja analyyttiset käsittelysovellukset (päätöstuki), jotka käyttävät tilapäisiä kyselyitä suuriin tietomääriin);

suorien analogien puuttuminen, mikä rajoittaa mahdollisuutta käyttää vakiomuotoisia suunnitteluratkaisuja ja sovellettavia järjestelmiä;

tarve integroida olemassa olevia ja äskettäin kehitettyjä sovelluksia;

toimii heterogeenisessä ympäristössä useilla laitteistoalustoilla;

yksittäisten kehittäjäryhmien epäyhtenäisyys ja heterogeenisuus taitotason ja tiettyjen työkalujen käytön vakiintuneiden perinteiden suhteen;

projektin merkittävä aikajänne, mikä johtuu toisaalta kehitystiimin rajallisesta kyvystä ja toisaalta asiakasorganisaation laajuudesta ja sen yksittäisten divisioonien vaihtelevasta valmiudesta toteuttaa IS.

Projektin onnistuneen toteuttamisen kannalta suunnittelukohde (IS) on ensin kuvattava riittävästi, rakennettava IS:n täydelliset ja johdonmukaiset toiminta- ja tietomallit. Tähän mennessä kertynyt kokemus IS:n suunnittelusta osoittaa, että kyseessä on loogisesti monimutkainen, työläs ja aikaa vievä työ, joka vaatii korkeasti koulutettuja asiantuntijoita. Kuitenkin viime aikoihin asti IS-suunnittelua tehtiin pääosin intuitiivisella tasolla taiteeseen, käytännön kokemukseen, asiantuntija-arvioihin ja kalliisiin tietojärjestelmien toiminnan laadun kokeellisiin tarkastuksiin perustuvin ei-formalisoiduin menetelmin. Lisäksi IS:n luomisen ja käytön aikana käyttäjien tietotarpeet voivat muuttua tai tarkentua, mikä vaikeuttaa entisestään tällaisten järjestelmien kehittämistä ja ylläpitoa.

70- ja 80-luvuilla IS:tä kehitettäessä käytettiin laajalti rakenteellista metodologiaa, joka tarjoaa kehittäjille tiukat formalisoidut menetelmät IS:n ja tehtyjen teknisten päätösten kuvaamiseen. Se perustuu visuaaliseen graafiseen tekniikkaan: kaavioilla ja kaavioilla kuvataan erilaisia ​​IS-malleja. Rakenneanalyysityökalujen näkyvyys ja tarkkuus mahdollisti järjestelmän kehittäjien ja tulevien käyttäjien alusta alkaen epävirallisen osallistumisen sen luomiseen, keskustelemaan ja lujittamaan ymmärrystä tärkeimmistä teknisistä ratkaisuista. Tämän metodologian laaja käyttö ja sen suositusten noudattaminen tiettyjen IS:iden kehittämisessä oli kuitenkin melko harvinaista, koska se on käytännössä mahdotonta ei-automaattisella (manuaalisella) kehityksellä. Itse asiassa on erittäin vaikeaa manuaalisesti kehittää ja graafisesti esittää järjestelmän tiukat muodolliset spesifikaatiot, tarkistaa niiden täydellisyys ja johdonmukaisuus ja vielä varsinkin muuttaa niitä. Jos kuitenkin on mahdollista luoda tiukka suunnitteluasiakirjojen järjestelmä, sen käsittely vakavien muutosten ilmetessä on käytännössä mahdotonta. Manuaalinen kehitys aiheutti yleensä seuraavia ongelmia:

riittämätön vaatimusten erittely;

epäonnistuminen virheiden havaitsemisessa suunnitteluratkaisut;

dokumentaation huono laatu, joka vähentää suorituskykyä;

pitkä sykli ja epätyydyttävät testitulokset.

Toisaalta IC-kehittäjät ovat historiallisesti aina olleet viimeisiä käyttäjiä Tietokonetekniikat parantaa oman työnsä laatua, luotettavuutta ja tuottavuutta ("suutarin ilman kenkiä" -ilmiö).

Edellä mainitut tekijät vaikuttivat erityisluokan ohjelmistojen ja teknisten työkalujen syntymiseen - CASE-työkalut, jotka toteuttavat CASE-teknologiaa IS:n luomiseen ja ylläpitoon. Termiä CASE (Computer Aided Software Engineering) käytetään tällä hetkellä hyvin laajassa merkityksessä. CASE-termin alkuperäinen merkitys, joka rajoittuu vain ohjelmistojen (ohjelmistojen) kehityksen automatisointiin, on nyt saanut uuden merkityksen, joka kattaa monimutkaisen tietojärjestelmän kehittämisprosessin kokonaisuutena. Nykyisin termi CASE-työkalut viittaa ohjelmistotyökaluihin, jotka tukevat IS:n luomis- ja ylläpitoprosesseja, mukaan lukien vaatimusten analysointi ja muotoilu, sovellusohjelmistojen (sovellusten) ja tietokantojen suunnittelu, koodin generointi, testaus, dokumentointi, laadunvarmistus, konfiguraatioiden hallinta ja projektinhallinta sekä muut prosessit. CASE-työkalut yhdessä järjestelmäohjelmiston ja -laitteiston kanssa muodostavat täydellisen IS-kehitysympäristön.

CASE-teknologian ja CASE-työkalujen ilmestymistä edelsi ohjelmointimetodologian alan tutkimus. Ohjelmointi on muotoutunut järjestelmällinen lähestymistapa korkean tason kielten, strukturoidun ja modulaarisen ohjelmoinnin menetelmien, suunnittelukielien ja niiden tukityökalujen, muodollisten ja epävirallisten kielten järjestelmävaatimusten ja spesifikaatioiden kuvaamiseen jne. kehittämisessä ja toteutuksessa. Lisäksi seuraavat tekijät vaikuttivat CASE-tekniikan syntymiseen:

modulaarisen ja strukturoidun ohjelmoinnin käsitteitä vastaanottavien analyytikoiden ja ohjelmoijien koulutus;

laajalle levinneelle ja jatkuvalle tietokoneen suorituskyvyn kasvulle, mikä mahdollisti tehokkaan käytön graafisia apuvälineitä ja automatisoida useimmat suunnitteluvaiheet;

toteutus verkkotekniikkaa, joka mahdollisti yksittäisten esiintyjien ponnistelujen yhdistämisen yhdeksi suunnitteluprosessiksi käyttämällä yhteistä tietokantaa, joka sisältää tarvittavat tiedot projektista.

CASE-teknologia on IS-suunnittelumetodologia sekä joukko työkaluja, jotka mahdollistavat visuaalisessa muodossa.

CASE työkalut. Yleiset ominaisuudet ja luokitus

Nykyaikaiset CASE-työkalut kattavat laajan tuen useille IS-suunnittelutekniikoille: yksinkertaisista analyysi- ja dokumentointityökaluista täysimittaisiin automaatiotyökaluihin, jotka kattavat ohjelmiston koko elinkaaren.

IS-kehityksen aikaa vievimmät vaiheet ovat analyysi- ja suunnitteluvaiheet, joiden aikana CASE-työkalut varmistavat teknisten ratkaisujen ja valmistelun laadun. projektin dokumentaatio. Samaan aikaan tiedon visuaalisen esittämisen menetelmillä on tärkeä rooli. Tämä sisältää rakenne- tai muiden kaavioiden rakentamisen reaaliajassa, monipuolisen väripaletin käytön ja syntaktisten sääntöjen päästä päähän -tarkistuksen. Graafisten verkkotunnusten mallinnustyökalujen avulla kehittäjät voivat visuaalisesti tutkia olemassa olevaa IS:ää, rakentaa sitä uudelleen tavoitteiden ja olemassa olevien rajoitusten mukaisesti.

CASE-työkalujen kategoriaan kuuluu sekä suhteellisen halpoja järjestelmiä henkilökohtaisiin tietokoneisiin, joiden ominaisuudet ovat hyvin rajalliset, että kalliita järjestelmiä heterogeenisiin laskenta-alustoihin ja käyttöympäristöihin. Siten nykyaikaisilla ohjelmistomarkkinoilla on noin 300 erilaisia ​​CASE-työkaluja, joista tehokkaimpia käyttävät tavalla tai toisella lähes kaikki johtavat länsimaiset yritykset.

Yleensä CASE-työkalut sisältävät minkä tahansa ohjelmistotyökalu, joka automatisoi yhden tai toisen ohjelmiston elinkaaren prosesseja ja jolla on seuraava pää ominaispiirteet:

tehokkaat graafiset työkalut IP:n kuvaamiseen ja dokumentointiin, kätevän käyttöliittymän tarjoaminen kehittäjän kanssa ja hänen luovien kykyjensä kehittäminen;

CASE-työkalujen yksittäisten komponenttien integrointi mahdollistaen IS-kehitysprosessin hallittavuuden;

erityisen organisoidun projektin metatietojen arkiston (arkiston) käyttö.

Integroitu CASE-työkalu (tai joukko työkaluja, jotka tukevat ohjelmiston koko elinkaarta) sisältää seuraavat komponentit;

arkisto, joka on CASE-työkalun perusta. Sen on varmistettava projektin ja sen yksittäisten komponenttien versioiden tallennus, eri kehittäjiltä saatujen tietojen synkronointi ryhmäkehityksen aikana, metatietojen hallinta täydellisyyden ja johdonmukaisuuden vuoksi;

graafiset analyysi- ja suunnittelutyökalut, jotka mahdollistavat IS-malleja muodostavien hierarkkisesti linkitettyjen kaavioiden (DFD, ERD jne.) luomisen ja muokkaamisen;

sovelluskehitystyökalut, mukaan lukien 4GL-kielet ja koodigeneraattorit;

kokoonpanon hallintatyökalut;

dokumentointivälineet;

testaustyökalut;

projektinhallinnan työkalut;

uudelleensuunnittelutyökalut.

Kaikki nykyaikaiset CASE-työkalut voidaan luokitella pääasiassa tyyppien ja luokkien mukaan. Luokittelu tyypin mukaan heijastaa CASE-työkalujen toiminnallista suuntautumista tiettyihin elinkaariprosesseihin. Luokkaluokitus määrittää suoritettujen toimintojen integroinnin asteen ja sisältää yksilölliset paikallisia varoja, joka ratkaisee pieniä itsenäisiä tehtäviä (työkaluja), sarja osittain integroituja työkaluja, jotka kattavat useimmat IP-elinkaarivaiheet (työkalupakki) ja täysin integroidut työkalut, jotka tukevat IP:n koko elinkaarta ja jotka on yhdistetty yhteiseen tietovarastoon. Lisäksi CASE-työkalut voidaan luokitella seuraavien kriteerien mukaan:

sovelletut menetelmät ja järjestelmien ja tietokantojen mallit;

integraatioaste DBMS:n kanssa;

saatavilla oleville alustoille.

Tyyppiluokitus vastaa periaatteessa CASE-työkalujen komponenttikoostumusta ja sisältää seuraavat päätyypit:

analyysityökalut (Upper CASE), jotka on suunniteltu luomaan ja analysoimaan toimialuemalleja (Design/IDEF (Meta Software), BPwin (Logic Works));

analyysi- ja suunnittelutyökalut (Middle CASE), jotka tukevat yleisimpiä suunnittelumenetelmiä ja joita käytetään suunnitteluspesifikaatioiden luomiseen (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Analytic (MacroProject)). Tällaisten työkalujen tuotoksena ovat järjestelmäkomponenttien ja rajapintojen spesifikaatiot, järjestelmäarkkitehtuuri, algoritmit ja tietorakenteet;

tietokannan suunnittelutyökalut, jotka tarjoavat tietojen mallintamisen ja tietokantaskeeman luomisen (yleensä käytössä SQL-kieli) yleisimmille DBMS-järjestelmille. TO ne sisältävät ERwin (Logic Works), S-Designer (SDP) ja DataBase Designer (ORACLE). Tietokannan suunnittelutyökalut sisältyvät myös Vantage Team Builder-, Designer/2000-, Silverrun- ja PRO-IV CASE -työkaluihin;

sovelluskehitystyökalut. Näitä ovat 4GL-työkalut (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) ja koodigeneraattorit, jotka sisältyvät Vantage Team Builderiin, PRO-IV:hen ja osittain Silverruniin;

uudelleensuunnittelutyökalut, jotka mahdollistavat ohjelmakoodien ja tietokantakaavioiden analysoinnin ja niiden pohjalta muodostumisen erilaisia ​​malleja ja suunnittelun tiedot. Tietokantaskeeman analysointi ja ERD-luontityökalut sisältyvät Vantage Team Builderiin, PRO-IV:hen, Silverruniin, Designer/2000:een, ERwiniin ja S-Designoriin. Ohjelmakoodianalyysin alalla käytetään eniten oliopohjaisia ​​CASE-työkaluja, jotka mahdollistavat C++-ohjelmien uudelleensuunnittelun (Rational Rose (Rational Software), Object Team (Cayenne)).

Auttajatyyppejä ovat:

projektin suunnittelu- ja hallintatyökalut (SE Companion, Microsoft Project jne.);

konfiguroinnin hallintatyökalut (PVCS (Intersolv));

testaustyökalut (Laatutyöt (Segue Software));

dokumentointityökalut (SoDA (Rational Software)).

Tähän mennessä Venäjän ohjelmistomarkkinoilla on seuraavat kehittyneimmät CASE-työkalut:

Vantage Team Builder (Westmount I-CASE);

Suunnittelija/2000;

Hopea aikavälillä;

ERwin+BPwin;

S Suunnittelija;

CASE.Analyytikko.

Lisäksi markkinoille tulee jatkuvasti sekä uusia kotimaisille käyttäjille tarkoitettuja järjestelmiä (esim. CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE) että uusia versioita ja muunnelmia näistä järjestelmistä.

1. IS-suunnittelumetodologian perusteet

1.1. IP-ohjelmiston elinkaari

Yksi IS-suunnittelumetodologian peruskäsitteistä on ohjelmiston (LC-ohjelmiston) elinkaaren käsite. Ohjelmiston elinkaari on jatkuva prosessi, joka alkaa siitä hetkestä, kun sen luomisen tarpeesta päätetään, ja päättyy siihen hetkeen, kun se poistetaan kokonaan käytöstä.

Pääasiallinen ohjelmistojen elinkaarta säätelevä säädösdokumentti on kansainvälinen standardi ISO / IEC 12207 (ISO - International Organization of Standardization - International Organisation for Standardization, IEC - International Electrotechnical Commission - International Electrotechnical Commission). Se määrittelee elinkaarirakenteen, joka sisältää ohjelmistokehityksen aikana suoritettavat prosessit, toiminnot ja tehtävät.

ISO/IEC 12207 -standardin mukainen ohjelmiston elinkaaren rakenne perustuu kolmeen prosessiryhmään:

ohjelmiston elinkaaren pääprosessit (hankinta, toimitus, kehitys, käyttö, ylläpito);

apuprosessit, jotka varmistavat pääprosessien toteuttamisen (dokumentaatio, kokoonpanon hallinta, laadunvarmistus, verifiointi, sertifiointi, arviointi, auditointi, ongelmanratkaisu);

organisaatioprosessit (projektinhallinta, projektiinfrastruktuurin luominen, itse elinkaaren määrittely, arviointi ja parantaminen, koulutus).

Kehitykseen sisältyy kaikki ohjelmiston ja sen komponenttien luomiseen liittyvät työt määriteltyjen vaatimusten mukaisesti, mukaan lukien suunnittelu- ja käyttödokumentaation valmistelu, ohjelmistotuotteiden toimivuuden ja asianmukaisen laadun testaamiseen tarvittavien materiaalien valmistelu, henkilöstökoulutuksen järjestämiseen tarvittavat materiaalit jne. Ohjelmistokehitys sisältää yleensä analyysin, suunnittelun ja toteutuksen (ohjelmoinnin).

Käyttöön kuuluu ohjelmistokomponenttien käyttöönottotyöt, mukaan lukien tietokannan ja käyttäjätyöasemien konfigurointi, käyttödokumentaation järjestäminen, henkilöstön koulutus jne. sekä suora käyttö, mukaan lukien ongelmien paikallistaminen ja niiden esiintymisen syiden poistaminen, ohjelmiston muokkaaminen asetettujen määräysten mukaisesti, ehdotusten valmistelu järjestelmän parantamiseksi, kehittämiseksi ja modernisoimiseksi.

Projektijohtaminen liittyy työn suunnitteluun ja organisointiin, kehittäjäryhmien muodostamiseen sekä töiden ajoituksen ja laadun seurantaan. Hankkeen tekninen ja organisatorinen tuki sisältää menetelmien ja työkalujen valinnan projektin toteuttamiseen, menetelmien määrittelyn kehitysvälitilojen kuvaamiseen, menetelmien ja työkalujen kehittämisen ohjelmistotestaukseen, henkilöstön koulutukseen jne. Projektin laadunvarmistus liittyy ohjelmistojen verifioinnin, verifioinnin ja testauksen ongelmiin. Todentaminen on prosessi, jossa määritetään, täyttääkö tietyssä vaiheessa saavutettu kehitysvaihe kyseisen vaiheen vaatimukset. Validoinnin avulla voit arvioida kehitysparametrien yhdenmukaisuutta alkuperäisten vaatimusten kanssa. Todentaminen on päällekkäistä testauksen kanssa, jossa pyritään tunnistamaan erot todellisten ja odotettujen tulosten välillä ja arvioimaan, vastaavatko ohjelmiston ominaisuudet alkuperäisiä vaatimuksia. Projektin toteutusprosessissa yksittäisten komponenttien ja koko järjestelmän identifiointiin, kuvaukseen ja konfiguroinnin valvontaan liittyvät kysymykset ovat tärkeässä asemassa.

Konfiguroinnin hallinta on yksi apuprosesseista, joka tukee ohjelmiston elinkaaren pääprosesseja, ensisijaisesti ohjelmistokehityksen ja -ylläpidon prosesseja. Kun luodaan monimutkaisia ​​IS-projekteja, jotka koostuvat monista komponenteista, joista jokaisella voi olla lajikkeita tai versioita, ongelmana on niiden suhteiden ja toimintojen huomioon ottaminen, yhtenäisen rakenteen luominen ja koko järjestelmän kehityksen varmistaminen. Konfiguroinnin hallinnan avulla voit organisoida, ottaa järjestelmällisesti huomioon ja hallita ohjelmiston muutoksia sen elinkaaren kaikissa vaiheissa. Yleiset periaatteet ja suositukset konfiguraatiolaskentaan, ohjelmistokokoonpanojen suunnitteluun ja hallintaan on otettu huomioon ISO 12207-2 -standardin luonnoksessa.

Jokaiselle prosessille on ominaista tietyt tehtävät ja menetelmät niiden ratkaisemiseksi, edellisessä vaiheessa saadut lähtötiedot ja tulokset. Analyysin tulokset ovat erityisesti toiminnallisia malleja, tietomalleja ja niitä vastaavia kaavioita. Ohjelmiston elinkaari on luonteeltaan iteratiivinen: seuraavan vaiheen tulokset aiheuttavat usein muutoksia aikaisemmissa vaiheissa kehitettyihin suunnittelupäätöksiin.

2. Rakenteellinen lähestymistapa IS-suunnitteluun CASE tarkoittaa

2.1. Rakenteellisen lähestymistavan ydin

IS:n kehittämisen rakenteellisen lähestymistavan ydin on sen hajottaminen (osiointi) automatisoiduiksi toiminnoiksi: järjestelmä on jaettu toiminnallisiin alijärjestelmiin, jotka puolestaan ​​​​jaetaan alitoimintoihin, jaetaan tehtäviin ja niin edelleen. Osiointiprosessi jatkuu tiettyihin toimenpiteisiin asti. Samaan aikaan automatisoitu järjestelmä säilyttää kokonaisvaltaisen näkymän, jossa kaikki komponentit on yhdistetty toisiinsa. Kun järjestelmää kehitetään "alhaalta ylös" yksittäisistä tehtävistä koko järjestelmään, eheys menetetään, ongelmia syntyy yksittäisten komponenttien tiedolliseen telakointiin.

Kaikki yleisimmät rakenteellisen lähestymistavan menetelmät perustuvat useisiin yleiset periaatteet. Kahtena perusperiaatteet käytetään seuraavia:

"hajaa ja hallitse" -periaate - periaate ratkaista monimutkaisia ​​ongelmia jakamalla ne moniin pienempiin itsenäisiin tehtäviin, jotka on helppo ymmärtää ja ratkaista;

hierarkkisen järjestyksen periaate - periaate järjestää ongelman osat hierarkkisiksi puurakenteiksi lisäämällä uusia yksityiskohtia jokaiselle tasolle.

Kahden perusperiaatteen valinta ei tarkoita sitä, että muut periaatteet olisivat toissijaisia, sillä minkä tahansa niistä huomiotta jättäminen voi johtaa arvaamattomiin seurauksiin (mukaan lukien koko projektin epäonnistuminen). Tärkeimmät näistä periaatteista ovat seuraavat:

abstraktion periaate - on korostaa järjestelmän oleellisia puolia ja abstraktio ei-olennaisista;

formalisoinnin periaate - on tiukan metodologisen lähestymistavan tarve ongelman ratkaisemiseksi;

johdonmukaisuuden periaate - piilee elementtien pätevyydestä ja johdonmukaisuudesta;

Tietojen strukturoinnin periaate on, että datan tulee olla jäsenneltyä ja hierarkkisesti järjestettyä.

Rakenneanalyysissä käytetään pääasiassa kahta työkaluryhmää, jotka havainnollistavat järjestelmän toimintoja ja tietojen välisiä suhteita. Jokainen rahastoryhmä vastaa tietyntyyppiset mallit (kaaviot), joista yleisimmät ovat seuraavat:

SADT (Structured Analysis and Design Technique) -mallit ja niihin liittyvät toimintakaaviot (alajakso 2.2);

DFD (Data Flow Diagrams) -tietovuokaaviot (alajakso 2.3);

ERD (Entity-Relationship Diagrams) -kaaviot "entity-relationship" (alajakso 2.4).

IS:n suunnitteluvaiheessa malleja laajennetaan, jalostetaan ja täydennetään kaavioilla, jotka kuvastavat ohjelmiston rakennetta: ohjelmistoarkkitehtuuria, ohjelmien lohkokaavioita ja näyttömuotokaavioita.

Listatut mallit yhdessä antavat täydellisen kuvauksen IS:stä riippumatta siitä, onko se olemassa vai vasta kehitetty. Kaavioiden koostumus kussakin tapauksessa riippuu järjestelmän kuvauksen vaaditusta täydellisyydestä.

2.2. SADT:n funktionaalisen mallinnuksen metodologia ( IDEF 0)

SADT-metodologian on kehittänyt Douglas Ross. Sen pohjalta kehitettiin erityisesti tunnettu IDEF0 (Icam DEFinition) -metodologia, joka on pääosa Yhdysvaltain ilmavoimien käynnistämässä ICAM-ohjelmassa (Integration of Computer and Industrial Technologies).

SADT-metodologia on joukko menetelmiä, sääntöjä ja menettelyjä, jotka on suunniteltu rakentamaan toiminnallinen malli objektista millä tahansa aihealueella. SADT-funktionaalinen malli heijastaa kohteen toiminnallista rakennetta, ts. sen suorittamat toiminnot ja näiden toimintojen väliset yhteydet. Tämän metodologian pääelementit perustuvat seuraaviin käsitteisiin:

lohkomallinnuksen graafinen esitys. SADT-kaavion lohko- ja kaarigrafiikka näyttävät toiminnon lohkona, ja tulo/lähtöliitännät on esitetty lohkoon tulevina ja vastaavasti poistuvina kaareina. Lohkojen vuorovaikutusta toistensa kanssa kuvataan rajapintakaarien avulla, jotka ilmaisevat "rajoituksia", jotka puolestaan ​​määräävät, milloin ja miten toimintoja suoritetaan ja ohjataan;

tiukkuus ja tarkkuus. SADT-sääntöjen toimeenpano edellyttää riittävää kurinalaisuutta ja tarkkuutta asettamatta tarpeettomia rajoituksia analyytikon toiminnalle. SADT-säännöt sisältävät:

lohkojen lukumäärän rajoittaminen kullakin hajotustasolla (sääntö 3-6 lohkoa);

kaavioiden liitettävyys (lohkojen lukumäärä);

tarrojen ja nimien ainutlaatuisuus (ei päällekkäisiä nimiä);

grafiikan syntaktiset säännöt (lohkot ja kaaret);

syötteiden ja ohjausten erottaminen (tietojen roolin määrittelysääntö).

organisaation erottaminen toiminnasta, ts. organisaatiorakenteen vaikutuksen poissulkeminen toimintamalliin.

SADT-metodologialla voidaan mallintaa monenlaisia ​​järjestelmiä ja määritellä vaatimuksia ja toimintoja ja sitten suunnitella järjestelmä, joka täyttää nämä vaatimukset ja toteuttaa ne toiminnot. Jo olemassa olevissa järjestelmissä SADT:tä voidaan käyttää analysoimaan järjestelmän suorittamia toimintoja sekä osoittamaan mekanismeja, joiden kautta ne suoritetaan.

2.2.1. Toiminnallisen mallin koostumus

SADT-metodologian soveltamisen tuloksena on malli, joka koostuu kaavioista, tekstikatkelmista ja sanastosta, joissa on linkkejä toisiinsa. Kaaviot ovat mallin pääkomponentteja, kaikki IS-toiminnot ja rajapinnat esitetään lohkoina ja kaareina. Kaaren liitoskohta lohkoon määrää liitännän tyypin. Ohjaustiedot tulevat lohkoon ylhäältä, kun taas käsiteltävät tiedot näkyvät lohkon vasemmalla puolella ja tulostulokset näkyvät oikealla puolella. mekanismi (henkilö tai automatisoitu järjestelmä), joka suorittaa toiminnon, on esitetty lohkoon alhaalta tulevana kaarena (kuva 2.1).

Yksi SADT-metodologian tärkeimmistä piirteistä on asteittainen lisääntyvien yksityiskohtien käyttöönotto, kun mallia edustavia kaavioita luodaan.

Riisi. 2.1. Toimintolohko ja liitäntäkaaret

Kuva 2.2, joka esittää neljä kaaviota ja niiden välisiä suhteita, esittää SADT-mallin rakenteen. Jokainen mallin komponentti voidaan jakaa eri kaavioksi. Jokainen kaavio kuvaa lohkon "sisäistä rakennetta" pääkaaviossa.

2.2.2. Kaavion hierarkia

SADT-mallin rakentaminen alkaa koko järjestelmän esittämisellä yksinkertaisimman komponentin muodossa - yksi lohko ja kaareet, jotka edustavat rajapintoja järjestelmän ulkopuolisten toimintojen kanssa. Koska yksi lohko edustaa koko järjestelmää kokonaisuutena, lohkossa annettu nimi on yleinen. Tämä pätee myös liitäntäkaareille - ne edustavat myös järjestelmän ulkoisia liitäntöjä kokonaisuutena.

Sitten lohko, joka edustaa järjestelmää yhtenä moduulina, on kuvattu toisessa kaaviossa käyttämällä useita lohkoja, jotka on yhdistetty liitäntäkaareilla. Nämä lohkot edustavat alkuperäisen toiminnon tärkeimpiä alitoimintoja. Tämä jaottelu paljastaa täydellisen joukon alifunktioita, joista jokainen on esitetty lohkona, jonka rajat määritetään liitäntäkaareilla. Jokainen näistä alifunktioista voidaan jakaa samalla tavalla yksityiskohtaisempaa näkymää varten.

Joka tapauksessa jokainen alifunktio voi sisältää vain ne elementit, jotka sisältyvät alkuperäiseen funktioon. Mallista ei myöskään voi jättää pois mitään elementtejä, eli kuten todettiin, emolohko ja sen rajapinnat tarjoavat kontekstin. Siihen ei voi lisätä mitään, eikä siitä voi poistaa mitään.

SADT-malli on sarja kaavioita, joissa on mukana asiakirjoja, jotka jakautuvat monimutkainen esine osiksi, jotka esitetään lohkojen muodossa. Jokaisen päälohkon yksityiskohdat on esitetty lohkoina muissa kaavioissa. Jokainen yksityiskohtainen kaavio on lohkon jakauma yleisemmästä kaaviosta. Jokaisessa hajotusvaiheessa yleisempää kaaviota kutsutaan yksityiskohtaisemman kaavion yläpääksi.

Kaaret, jotka saapuvat ja poistuvat lohkosta kaaviossa huipputaso, ovat täsmälleen samat kuin kaaviossa olevat kaaret alempi taso ja tulee siitä ulos, koska lohko ja kaavio edustavat samaa järjestelmän osaa.

Riisi. 2.2. SADT-mallin rakenne. Kaavion hajoaminen

Kuvat 2.3 - 2.5 esittävät erilaisia ​​vaihtoehtoja toimintojen suorittamiseen ja kaarien liittämiseen lohkoihin.

Riisi. 2.3. Samanaikainen toteutus

Riisi. 2.4. Vaatimustenmukaisuuden tulee olla täydellistä ja johdonmukaista

Jotkut kaaret on kiinnitetty kaaviolaatikoihin molemmista päistä, kun taas toisten toinen pää on jätetty kiinnittämättä. Kytkemättömät kaaret vastaavat päälohkon tuloja, ohjaimia ja lähtöjä. Näiden rajakaarien lähde tai kohde löytyy vain pääkaaviosta. Kiinnittämättömien päiden tulee vastata alkuperäisen kaavion kaaria. Kaikkien rajakaarien on jatkuttava yläkaaviossa, jotta se olisi täydellinen ja johdonmukainen.

SADT-kaaviot eivät osoita selkeästi sekvenssiä tai aikaa. Palautteet, iteraatiot, käynnissä olevat prosessit ja päällekkäiset (ajassa) toiminnot voidaan kuvata kaarien avulla. Palaute voi olla kommentteja, huomautuksia, korjauksia jne. (Kuva 2.5).

Riisi. 2.5. Palauteesimerkki

Kuten todettiin, mekanismit (kaaret alapuolella) osoittavat keinot, joilla toimintoja suoritetaan. Mekanismi voi olla ihminen, tietokone tai mikä tahansa muu laite, joka auttaa tässä toiminnossa (kuva 2.6).

Riisi. 2.6. Esimerkki mekanismista

Jokaisella kaavion lohkolla on oma numeronsa. Minkä tahansa kaavion lohkoa voidaan kuvata tarkemmin alemman tason kaaviolla, jota voidaan puolestaan ​​tarkentaa tarvittavalla määrällä kaavioita. Siten muodostuu kaavioiden hierarkia.

Kaavion numeroita käytetään osoittamaan minkä tahansa kaavion tai lohkon sijainti hierarkiassa. Esimerkiksi A21 on kaavio, joka kuvaa kaavion A2 ruutua 1. Vastaavasti A2 yksityistää ruutua 2 kaaviossa A0, joka on mallin ylin kaavio. Kuva 2.7 esittää tyypillistä kaaviopuuta.

Riisi. 2.7. Kaavion hierarkia

2.2.3. Funktioiden välisten linkkien tyypit

Yksi tärkeimmistä kohdista SADT-metodologiaa käyttävän IS:n suunnittelussa on funktioiden välisten suhteiden tarkka yhdenmukaisuus. Erottuna vähintään seitsemän sidontatyyppiä:

Viestintätyyppi	Suhteellinen merkitys
Satunnainen
looginen
Väliaikainen
menettelyllinen
Viestintä
johdonmukainen
toimiva

Jokainen linkkityyppi määritellään lyhyesti alla ja havainnollistetaan SADT:n tyypillisellä esimerkillä.

(0) Satunnainen yhteystyyppi: vähiten toivottavaa.

Satunnainen yhteys syntyy, kun ominaisuuksien välillä on vähän tai ei ollenkaan erityistä yhteyttä. Tämä viittaa tilanteeseen, jossa saman kaavion SADT-kaarien datanimilla on vain vähän yhteyttä toisiinsa. Tämän tapauksen äärimmäinen versio on esitetty kuvassa 2.8.

Riisi. 2.8. Satunnainen yhteys

(1) Loogisen yhteyden tyyppi.Looginen sitominen tapahtuu, kun tiedot ja funktiot tuodaan yhteen, koska ne kuuluvat yhteiseen luokkaan tai elementtijoukkoon, mutta tarvittavia toiminnallisia suhteita niiden välillä ei löydy.

(2) Ajallisen yhteyden tyyppi.Aikaan liittyvät elementit syntyvät, koska ne edustavat aikaan liittyviä toimintoja, kun dataa käytetään samanaikaisesti tai toiminnot otetaan käyttöön rinnakkain eikä peräkkäin.

(3) Menettelyllisen liitettävyyden tyyppi.Proseduuriin liittyvät kohteet näkyvät ryhmiteltyinä, koska ne suoritetaan silmukan tai prosessin saman osan aikana. Esimerkki proseduurillisesti yhdistetystä kaaviosta on esitetty kuvassa 2.9.

Riisi. 2.9. proseduurin liitettävyys

(4) Viestintäyhteyden tyyppi.Kaaviot näyttävät viestintälinkit, kun lohkot on ryhmitelty, koska ne käyttävät samaa tuloa ja/tai tuottavat samaa lähtöä (kuva 2.10).

(5) Sarjaliitännän tyyppi.Kaavioissa, joissa on sarjalinkkejä, yhden funktion tulos on seuraavan funktion tulo. Kaavion elementtien välinen yhteys on tiiviimpi kuin edellä käsitellyillä linkkien tasoilla, koska syy-seuraus-suhteet mallinnetaan (kuva 2.11).

(6) Toiminnallisen liitännän tyyppi.Kaavio heijastaa täydellistä toiminnallista liitettävyyttä, kun yksi toiminto on täysin riippuvainen toisesta. Puhtaasti toiminnallinen kaavio ei sisällä vieraita peräkkäisen tai heikomman tyyppisen yhteyden elementtejä. Eräs tapa määritellä toiminnallisesti toisiinsa liittyviä kaavioita on tarkastella kahta ohjauskaarella kytkettyä lohkoa, kuten kuvassa 2.12.

Riisi. 2.10. Viestintäyhteydet

Riisi. 2.11. sarjaliitäntä

Kuva 13. Toiminnallinen kaavio tuotesuunnittelun luomiseen ja muokkaamiseen (toinen taso)

Luettavuuden vuoksi on suositeltavaa rajoittaa kaavion lohkojen lukumäärä kolmesta kuuteen. Yläraja pakottaa turvautumaan hajotukseen, alaraja varmistaa, että kaaviossa on tarpeeksi yksityiskohtia sen luomisen perustelemiseksi. On toivottavaa, että lohkon sivua lähestyvien tai siitä lähtevien liitäntäkaarien lukumäärä ei ylitä 4:ää.

IDEF 0 -menetelmä olettaa ryhmätyöprojektin tai hankkeiden yli. Erilaisten asiantuntijoiden ryhmä haastattelee päteviä henkilöitä ja rakentaa karkean mallin. Yrityksen asiantuntijat keskustelevat tästä mallista, arvostelevat sitä kirjallisesti ja siirtävät sen kehitystiimille. Tämä sykli jatkuu, kunnes kehittäjät ja arvioijat sopivat. Seuraavaksi malli hyväksytään virallisesti ja sitä käytetään (esimerkiksi järjestelmän toimintojen uudelleenjärjestelyyn).

Yksi menetelmän eduista IDEF 0 tarkoittaa, että se abstraktioi poiskohteen organisaatiorakenneja analysoi sen toimintoja. Tämä mahdollistaa mallin rakentamisen jälkeen tarkastella näitä toimintoja toteuttavaa organisaatiorakennetta sen täydellisyyden näkökulmasta, tunnistaa samanlaisia ​​ominaisuuksia tai niiden päällekkäisyyksiä ja antaa ehdotuksia järjestelmän uudelleenjärjestelystä.

Jos käytämme termiä "liiketoimintaprosessi", voimme sanoa, että menetelmä IDEF 0 mahdollistaa tunnistamisenliiketoimintaprosesseja, harkita yrityksen toimintaa "sellaisena kuin se on" ja analyysinsä perusteella antaa ehdotuksia "niin kuin pitää", eli katsoa yrityksen työtä uudella tavalla, selventää työntekijöiden vastuita, arvioida resurssien käytön tehokkuutta, nähdä tavanomaiseen organisaatiorakenteeseen taidokkaasti piilotetut puutteet. Siksi liiketoimintaprosessien tunnistamista, analysointia ja muutosten tekemistä voidaan käyttää yrityksen tehokkuuden parantamiseen.

Termin "liiketoimintaprosessi" käyttöönoton jälkeen on syntynyt useita tekniikoita liiketoimintaprosessien parantamiseksi. Suosituin niistä on yrityksen liiketoimintaprosessien uudelleensuunnittelu, joka edellyttää yrityksen liiketoimintaprosessien perusteellista uudelleen ajattelua ja uudelleensuunnittelua. Näiden prosessien tunnistaminen, analysointi ja uudelleensuunnittelu on ehdotetun metodologian sisältö. Yleinen kaava yrityksen liiketoimintaprosessien analysoinnin ja uudelleensuunnittelun metodologia on seuraava (katso kuva 12):

Yritystä koskevien tietojen kerääminen;

• yrityksen liiketoimintaprosessien tunnistaminen ja yrityksen liiketoimintaprosessien toiminnallisen mallin luominen;
• yrityksen liiketoimintaprosessien analysointi ja mahdollinen uudelleensuunnittelu.

Analyysia varten kulujen jakaminenkäytetään IDEF0:aan perustuvaa ABC-menetelmää. ABC-menetelmä perustuu siihen, että kunkin toiminnon suorittamisella yrityksen toiminnan aikana on tietty kustannus, eli se myötävaikuttaa kustannusten ilmenemiseen. АВС on samanlainen kuin FSA:n käsite - toiminnallinen kustannusanalyysi. ABC-menetelmällä lasketaan koko prosessin tai erillisen toiminnon suorittamisen kustannukset, tuotteiden kustannukset prosessin tuotoksessa ja tunnistetaan pääkustannusten lähteet. Hajottavan funktion suorittamisen kustannukset määritellään kaikkien suorittamisen kustannusten summaksi osatekijät tässä toiminnossa.

ABC-menetelmän avulla voit saada kvantitatiivisia arvioita prosessista, jota tarvitaan useiden vaihtoehtojen arvioimiseen. Toisin kuin perinteisessä kirjanpidossa, jossa huomioidaan pääasiassa välittömät kustannukset (välillisten kustannusten kirjanpito on vaikeaa, mutta joissain tapauksissa välttämätöntä), ABC-menetelmän avulla voit ottaa huomioon erilaisia ​​tekijöitä, jotka vaikuttavat yrityksen kustannusten muodostumiseen.

Toimivan mallin rakentamiseksi ehdotetaan valitsemista CASE-Design/IDEF-paketti , koska toiminnallisen mallin luomismahdollisuuksien lisäksi tämä paketti sisältää sisäänrakennetun ABC-mekanismin toimintojen suorittamiskustannusten laskemiseen, jonka avulla voit analysoida liiketoimintaprosesseja ja niiden komponentteja. Jokainen toiminnon kuluttama (käsittelemä) resurssityyppi sekä toimintoa suorittavat mekanismit lisäävät tämän toiminnon kustannuksia samalla kun otetaan huomioon kustannustekijät, jotka jätetään huomioimatta yrityksen tavanomaisessa esittelyssä organisaatiorakenteiden joukkona. Siksi jokainen IDEF0-mallin funktio h voidaan liittää tämän funktion Ex(h) suorituskustannusten arvoon.

Kuva 14. Metodologian yleinen kaavio yrityksen liiketoimintaprosessien analysointiin ja uudelleensuunnitteluun

IDEF0- ja ABC-menetelmien yhdistäminen (kuva 14) mahdollistaa yhden tärkeimmistä tehtävistä - järjestelmän toimintojen täydellisyyden, sen parantamismahdollisuuksien analysoinnin, mikä ei ole siinä määrin sisäistä muissa menetelmissä ja standardeissa.ABC-menetelmän yhdistäminen antaa sinun verrata olemassa olevaa rakennetta (sellaisena kuin se on) järkevään rakenteeseen (kuten sen pitäisi olla), koska samat toiminnot voidaan toteuttaa eri rakenteilla (voit esimerkiksi yhdistää samanlaisia ​​toimintoja suorittavia osastoja merkityksettömällä erolla tai pienellä kuormalla).

Esimerkki f:n rakentamisestaCAD-luontiprosessin toiminnallinen malli on esitetty kuvissa 15…18.

Kuva 15. CAD-luontiprosessin toiminnallinen malli (alku).
IDEF Ensimmäisen tason 0-kaavio.

Kuva 16. IDEF 0-kaavion kyselyyritys.

Kuva 17. IDEF 0-kaavion suunnittelu CAD.

Kuva 18. IDEF 0-kaavio CAD-projektin toteutuksesta.

2.3. Tietovirtojen mallintaminen (prosessit - mallit DFD , IDEF-standardi 1)

Tämä metodologia (Gane/Sarson-metodologia) perustuu analysoidun IS-mallin rakentamiseen - suunniteltu tai olemassa oleva. Metodologian mukaisesti järjestelmämalli määritellään tietovuokaavioiden (DFD tai DFD) hierarkiana, joka kuvaa asynkronista tiedon muunnosprosessia sen syöttämisestä järjestelmään sen antamiseen käyttäjälle. Hierarkian ylempien tasojen kaaviot (kontekstikaaviot) määrittelevät IS:n pääprosessit tai alijärjestelmät ulkoisilla tuloilla ja lähdöillä. Ne on esitetty yksityiskohtaisesti käyttämällä alemman tason kaavioita. Tämä hajottaminen jatkuu luoden monitasoista kaavioiden hierarkiaa, kunnes saavutetaan hajoamistaso, jolla prosesseista tulee alkeellisia ja niitä on mahdotonta tarkentaa.

IDEF1 - simulointimenetelmätiedonkulku järjestelmän sisällä,mahdollistaa järjestelmän rakenteen eli sen elementtien (olioiden), niiden ominaisuuksien (attribuuttien) ja niiden välisten suhteiden (relaatioiden) näyttämisen. Mallintamisen aikana saatu yksityiskohtaiset tiedot mahdollistavat analysoitavan kohteen "pullonkaulojen" tunnistamisen ja ovat perustana järjestelmän rakenteen ja tietovirtojen parantamiseen ja oikean tiedonhallintapolitiikan toteuttamiseen liittyvien päätösten tekemiselle.

Tietolähteet (ulkoiset entiteetit) tuottavat tietovirtoja (tietovirtoja), jotka siirtävät tietoa osajärjestelmiin tai prosesseihin. Ne puolestaan ​​muuntavat tietoa ja synnyttävät uusia virtoja, jotka siirtävät tietoa muihin prosesseihin tai alijärjestelmiin, tietovarastoihin tai ulkoisiin kokonaisuuksiin - tiedon kuluttajiin. Näin ollen tietovuokaavioiden pääkomponentit ovat:

ulkoiset tahot;

järjestelmät/alijärjestelmät;

prosessit;

Tietojen tallennuslaitteet;

datavirtoja.

2.3.1. Ulkoiset kokonaisuudet

Ulkoinen kokonaisuus on aineellinen esine tai yksilöllinen A, joka edustaa tiedon lähdettä tai kohdetta, kuten asiakkaita, henkilöstöä, tavarantoimittajia, asiakkaita, varastoa. Jonkin kohteen tai järjestelmän määritelmä ulkoiseksi kokonaisuudeksi osoittaa sen olevan analysoidun IS:n rajojen ulkopuolella. Analyysin aikana voidaan tarvittaessa siirtää joitain ulkoisia kokonaisuuksia analysoitavan IS:n kaavion sisälle, tai päinvastoin, osa IS-prosesseista voidaan siirtää kaavion ulkopuolelle ja esittää ulkoisena kokonaisuutena.

Ulkoinen kokonaisuus on osoitettu neliöllä (kuva 2.13), joka sijaitsee ikään kuin kaavion "yläpuolella" ja antaa sille varjon erottaakseen tämän symbolin muista merkinnöistä:

Riisi. 2.13. ulkoinen kokonaisuus

2.3.2. Järjestelmät ja alijärjestelmät

Monimutkaista IS-mallia rakennettaessa se voidaan esittää yleisimmässä muodossa ns. kontekstikaaviossa yhtenä järjestelmänä kokonaisuutena tai se voidaan jakaa useiksi osajärjestelmiksi.

Kontekstikaavion osajärjestelmä (tai järjestelmä) on kuvattu seuraavasti (Kuva 2.14).

Riisi. 2.14. Alajärjestelmä

Alajärjestelmän numero tunnistaa sen. Nimikenttään osajärjestelmän nimi syötetään lauseen muodossa aiheen ja sitä vastaavien määritelmien ja lisäysten kera.

2.3.3. Prosessit

Prosessi on syöttötietovirtojen muuntaminen lähtötietovirroiksi tietyn algoritmin mukaisesti. Fyysisesti prosessi voidaan toteuttaa eri tavoin: se voi olla organisaation (osaston) alaosasto, joka käsittelee syöttöasiakirjoja ja laatii raportteja, ohjelma, laitteistolla toteutettu looginen laite jne.

Prosessi tietovuokaaviossa on kuvattu kuvan 2.15 mukaisesti.

Riisi. 2.15. Käsitellä asiaa

Prosessinumeroa käytetään sen tunnistamiseen. Nimikenttään prosessin nimi syötetään lauseena, jossa on aktiivinen yksiselitteinen verbi epämääräisessä muodossa (laske, laske, tarkista, määritä, luo, vastaanota), jota seuraa substantiivit akusatiivissa, esimerkiksi:

"Anna asiakastiedot";

"Anna tietoja juoksevista kuluista";

"Tarkista asiakkaan luottokelpoisuus."

Verbien, kuten "prosessoida", "modernisoida" tai "muokkaa", käyttö osoittaa yleensä prosessin ymmärtämättömyyttä ja vaatii lisäanalyysiä.

Fyysisen toteutuskentän tiedot osoittavat, mitä organisaation, ohjelman tai laitteiston osaa prosessi suorittaa.

2.3.4. Data-asemat

Tiedontallennuslaite on abstrakti tiedon tallentamiseen tarkoitettu laite, joka voidaan sijoittaa asemaan milloin tahansa ja poistaa jonkin ajan kuluttua, ja lisäys- ja poistomenetelmät voivat olla mitä tahansa.

Tietojen tallennuslaite voidaan toteuttaa fyysisesti mikrokortilla, arkistokaapin laatikolla, taulukolla RAM-muisti, tiedosto magneettinen media jne. Tietojen kerääjä tietovuokaaviossa on kuvattu kuvan 2.16 mukaisesti.

Riisi. 2.16. Tietovarasto

Tietojen tallennuslaite tunnistetaan kirjaimella "D" ja mielivaltaisella numerolla. Aseman nimi valitaan suunnittelijan suurimman tietosisällön kannalta.

Tietovarasto on yleensä tulevan tietokannan prototyyppi ja siihen tallennetun tiedon kuvaus tulee linkittää tietomalliin.

2.3.5. Tietovirrat

Tietovirta määrittelee tiedon, joka välitetään jonkin yhteyden kautta lähteestä vastaanottimeen. Varsinainen tietovirta voi olla kahden laitteen välillä kaapelilla siirrettyä tietoa, postitettuja kirjeitä, magneettinauhoja tai levykkeitä, siirretty tietokoneelta toiselle ja niin edelleen.

Kaavion datavirtaa edustaa viiva, joka päättyy nuoleen, joka osoittaa virran suunnan (kuva 2.17). Jokaisella tietovirralla on nimi, joka kuvastaa sen sisältöä.

Riisi. 2.17. Tietovirta

2.3.6. Tiedonkulkukaavioiden hierarkian rakentaminen

Ensimmäinen askel DPD-hierarkian rakentamisessa on kontekstikaavioiden rakentaminen. Yleensä suhteellisen yksinkertaisia ​​IS:itä suunniteltaessa rakennetaan yksittäinen kontekstikaavio tähtitopologialla, jonka keskellä on ns. pääprosessi, joka on kytketty vastaanottimiin ja tietolähteisiin, joiden kautta käyttäjät ja muut ulkoiset järjestelmät ovat vuorovaikutuksessa järjestelmän kanssa.

Jos varten monimutkainen järjestelmä rajoittuen yhteen kontekstikaavioon, se sisältää liian monia informaatiolähteitä ja -nieluja, joita on vaikea järjestää normaalikokoiselle paperiarkille, ja lisäksi ainoa pääprosessi ei paljasta hajautetun järjestelmän rakennetta. Merkkejä monimutkaisuudesta (kontekstin suhteen) voivat olla:

suuren määrän ulkopuolisia kokonaisuuksia (kymmen tai enemmän);

järjestelmän hajautettu luonne;

järjestelmän monitoiminnallisuus, jossa on jo muodostettu tai tunnistettu toimintojen ryhmittely erillisiksi alajärjestelmiksi.

Monimutkaisille IS:lle rakennetaan kontekstikaavioiden hierarkia. Samanaikaisesti ylätason kontekstikaavio ei sisällä yhtä pääprosessia, vaan joukon alijärjestelmiä, joita tietovirrat yhdistävät. Seuraavan tason kontekstikaaviot kuvaavat alijärjestelmien kontekstin ja rakenteen.

Kontekstikaavioiden hierarkia määrittää suunnitellun IS:n tärkeimpien toiminnallisten alijärjestelmien vuorovaikutuksen sekä keskenään että ulkoisten tulo- ja lähtötietovirtojen ja ulkoisten objektien (informaation lähteiden ja vastaanottajien) kanssa, joiden kanssa IS on vuorovaikutuksessa.

Kontekstikaavioiden kehittäminen ratkaisee IS:n toiminnallisen rakenteen tiukan määrittelyn sen suunnittelun varhaisessa vaiheessa ongelman, mikä on erityisen tärkeää monimutkaisissa monitoimijärjestelmissä, joiden kehittämiseen osallistuvat erilaiset organisaatiot ja kehitysryhmät.

Kontekstikaavioiden rakentamisen jälkeen tuloksena olevasta mallista tulee tarkistaa järjestelmän objektien alkutietojen täydellisyys ja objektien eristys (tietolinkkien puute muihin objekteihin).

Jokaisen kontekstikaavioissa esiintyvän alijärjestelmän osalta sen yksityiskohdat suoritetaan DPD:n avulla. Jokainen DPD:n prosessi voidaan puolestaan ​​​​täsmentää käyttämällä DPD:tä tai minispesifikaatiota. Yksityiskohtia tehtäessä on noudatettava seuraavia sääntöjä:

tasapainotussääntö - tarkoittaa, että alijärjestelmää tai prosessia eriteltäessä yksityiskohtaisessa kaaviossa ulkoisina tietolähteinä/vastaanottimina voi olla vain ne komponentit (alijärjestelmät, prosessit, ulkoiset entiteetit, tietovarastot), joihin pääkaavion yksityiskohtaisella osajärjestelmällä tai prosessilla on informaatiolinkkejä;

numerointisääntö - tarkoittaa, että prosesseja eriteltäessä tulee tukea niiden hierarkkista numerointia. Esimerkiksi prosessien numero 12 yksityiskohtaisille prosesseille annetaan numerot 12.1, 12.2, 12.3 ja niin edelleen.

Minispesifikaatiossa (prosessin logiikan kuvauksessa) tulee muotoilla sen päätoiminnot siten, että jatkossa projektin toteuttava asiantuntija voi suorittaa ne tai kehittää sopivan ohjelman.

Minimäärittely on DPD-hierarkian viimeinen huippu. Analyytikko päättää prosessin yksityiskohdan täydentämisestä ja minispesifikaatiosta seuraavien kriteerien perusteella:

prosessissa on suhteellisen pieni määrä tulo- ja lähtödatavirtoja (2-3 virtaa);

mahdollisuus kuvata prosessin suorittamaa datan muuntamista peräkkäisen algoritmin muodossa;

yksittäisen loogisen toiminnon suorittaminen syöteinformaation muuntamiseksi lähdöksi;

mahdollisuus kuvata prosessin logiikkaa pienellä minispesifikaatiolla (enintään 20-30 riviä).

DPD-hierarkiaa rakennettaessa prosessien tarkentamiseen tulee edetä vasta sen jälkeen, kun on selvitetty kaikkien virtojen ja tiedontallennuslaitteiden sisältö, joka kuvataan tietorakenteiden avulla. Tietorakenteet rakennetaan tietoelementeistä ja voivat sisältää vaihtoehtoja, ehdollisia ja iteraatioita. Ehdollinen esiintyminen tarkoittaa, että tätä komponenttia ei välttämättä ole rakenteessa. Vaihtoehto tarkoittaa, että jokin luetelluista elementeistä voidaan sisällyttää rakenteeseen. Iteraatio tarkoittaa minkä tahansa määrän elementtien syöttämistä määritetty alue. Kullekin tietoelementille voidaan määrittää sen tyyppi (jatkuva tai erillinen data). Jatkuville tiedoille voidaan määrittää mittayksikkö (kg, cm, jne.), arvoalue, esitystarkkuus ja fyysisen koodauksen muoto. Erillisille tiedoille voidaan määrittää kelvollisten arvojen taulukko.

Täydellisen järjestelmämallin luomisen jälkeen se on tarkistettava (tarkistetaan täydellisyys ja johdonmukaisuus). Täydellisessä mallissa kaikki sen objektit (alijärjestelmät, prosessit, tietovirrat) on kuvattava ja kuvattava yksityiskohtaisesti. Tunnistetut, ei-yksityiskohtaiset kohteet tulee tarkentaa palaamalla edellisiin kehitysvaiheisiin. Johdonmukaisessa mallissa kaikkien tietovirtojen ja tietovarastojen on noudatettava tiedon säilytyssääntöä: kaikki jonnekin tuleva data on luettava ja kaikki luettu data on kirjoitettava.

2.4. Tietojen mallinnus

IDEF1X - tiedon mallinnus ja relaatiotietokannan suunnittelumenetelmä. Se kuuluu menetelmien tyyppiin "entiteetti-suhde" ( ER-Entity-Relationship ), entiteettejä ei tässä kuitenkaan ymmärretä todellisina objekteina, vaan niiden tyypeinä, joilla on yhteisiä ominaisuuksia. Kokonaisuuksien väliset suhteet ovat monimutkaisempia. Tämän avulla voit tallentaa tietoja abstraktin skeeman (semanttisen mallin) muodossa, joka yhdistää tietokoneeseen tallennetut merkit todelliseen maailmaan ja heijastaa sitä aidosti. Tämä tiedon tallennustapa on suhteellisen itsenäinen, "neutraali" ja mahdollistaa vastauksen saamisen erilaisia ​​pyyntöjä käyttäjälle mallissa kuvatun ympäristön ominaisuuksista. IDEF1X-standardi julkaistiin vuonna 1993 ( FIPS 184).

2.4.1. Barkerin tapausmenetelmä

Tietomallinnuksen tarkoituksena on tarjota IS-kehittäjälle käsitteellinen tietokantaskeema yhden tai useamman mallin muodossa. paikallisia malleja, joka voidaan kartoittaa suhteellisen helposti mihin tahansa tietokantajärjestelmään.

Yleisin tietojen mallinnustyökalu on Entity Relationship Diagrams (ERD:t). Niiden avulla selvitetään aihealueen kannalta tärkeitä esineitä (kokonaisuuksia), niiden ominaisuuksia (attribuutteja) ja suhteita toisiinsa (linkkejä). ERD:itä käytetään suoraan relaatiotietokantojen suunnitteluun.

ERD-merkinnän esitteli ensimmäisenä P. Chen, ja Barker kehitti sitä edelleen. Barkerin menetelmä esitellään esimerkkinä autokaupan yrityksen toiminnan mallintamisesta. Seuraavassa on otteita yrityksen henkilöstön kanssa tehdystä haastattelusta.

Toimitusjohtaja: yksi päätehtävistä on autokiinteistön huolto. Hänen on tiedettävä, kuinka paljon autoista maksetaan ja mitkä ovat yleiskustannukset. Näiden tietojen avulla hän voi asettaa pohjahinnan, jolla hän voisi myydä tämä esimerkki. Lisäksi hän on vastuussa myyjistä ja hänen tulee tietää kuka myy mitä ja kuinka monta autoa kukin myi.

Myyjä: Hänen on tiedettävä, mitä hintaa pyytää ja mikä on alin hinta, jolla kauppa voidaan tehdä. Lisäksi hän tarvitsee perustiedot autoista: valmistusvuosi, merkki, malli jne.

Ylläpitäjä: Hänen tehtävänsä on laatia sopimuksia, mikä edellyttää tietoa ostajasta, ajoneuvosta ja myyjästä, koska sopimuksista kertyy myyjille myyntipalkkioita.

Ensimmäinen mallintamisvaihe on tiedon poimiminen haastattelusta ja kokonaisuuksien poimiminen.

Entiteetti - tarkasteltavalle aihealueelle olennainen todellinen tai kuvitteellinen esine, josta tiedot tallennetaan (kuva 2.18).

Riisi. 2.18. Graafinen esitys kokonaisuudesta

Jokaisella entiteetillä on oltava yksilöllinen tunniste. Jokaisen entiteetin esiintymän on oltava yksilöllisesti tunnistettavissa ja erotettava kaikista muista esiintymistä. tämän tyyppistä kokonaisuuksia. Jokaisella entiteetillä on oltava joitain ominaisuuksia:

jokaisella entiteetillä on oltava yksilöllinen nimi, ja samaa tulkintaa on aina sovellettava samaan nimeen. Samaa tulkintaa ei voi soveltaa eri nimiin, elleivät ne ole aliaksia;

entiteetillä on yksi tai useampi attribuutti, joka joko kuuluu entiteetille tai on peritty suhteen kautta;

entiteetillä on yksi tai useampi attribuutti, joka yksilöi jokaisen entiteettiinstanssin yksilöllisesti;

kullakin entiteetillä voi olla mikä tahansa määrä suhteita muiden mallikokonaisuuksien kanssa.

Edellä oleviin haastatteluotteisiin viitaten on selvää, että pääjohtajaan tunnistettavissa olevat kokonaisuudet ovat moottoriajoneuvot ja myyjät. Myyjä välittää autoista ja niiden myyntiin liittyvistä tiedoista. Ylläpitäjälle ostajat, autot, myyjät ja sopimukset ovat tärkeitä. Tämän perusteella erotetaan 4 entiteettiä (auto, myyjä, ostaja, sopimus), jotka on kuvattu kaaviossa seuraavasti (Kuva 2.19).

Riisi. 2.19.

Seuraava mallinnusvaihe on suhteiden tunnistaminen.

Suhde - nimetty yhteys kahden kokonaisuuden välillä, joka on merkittävä tarkasteltavana olevan aihealueen kannalta. Suhde on entiteettien välinen assosiaatio, jossa pääsääntöisesti yksi entiteetin, jota kutsutaan emokokonaisuudeksi, ilmentymä liittyy mielivaltaiseen määrään (mukaan lukien nolla) toisen entiteetin, jota kutsutaan alikokonaisuudeksi, esiintymiä, ja jokainen alikokonaisuuden esiintymä liittyy täsmälleen yhteen emokokonaisuuden esiintymään. Siten alikokonaisuuden esiintymä voi olla olemassa vain, jos emokokonaisuus on olemassa.

Linkille voidaan antaa nimi, joka ilmaistaan ​​verbin kieliopillisen käänteen perusteella ja sijoittaa linkkirivin viereen. Jokaisen kahden annetun entiteetin välisen suhteen nimen on oltava yksilöllinen, mutta mallissa olevien suhteiden nimien ei tarvitse olla yksilöllisiä. Suhteen nimi muodostuu aina vanhemman näkökulmasta, joten lause voidaan muodostaa yhdistämällä emokokonaisuuden nimi, suhteen nimi, astelauseke ja alakokonaisuuden nimi.

Esimerkiksi myyjän suhde sopimukseen voidaan ilmaista seuraavasti:

myyjä voidaan palkita yhdestä tai useammasta sopimuksesta;

Sopimus on tehtävä tarkalleen yhden myyjän toimesta.

Yhteyden ja sitoutumisen aste on kuvattu graafisesti seuraavasti (Kuva 2.20).

Riisi. 2.20.

Näin ollen 2 lausetta, jotka kuvaavat myyjän suhdetta sopimukseen, ilmaistaan ​​graafisesti seuraavasti (Kuva 2.21).

Riisi. 2.21.

Kun on kuvattu myös muiden entiteettien suhteet, saadaan seuraava kaavio (Kuva 2.22).

Riisi. 2.22.

Viimeinen mallinnusvaihe on attribuutin tunnistaminen.

Attribuutti - mikä tahansa kokonaisuuden ominaisuus, joka on merkittävä tarkasteltavana olevan aihealueen kannalta ja joka on tarkoitettu kokonaisuuden pätevöintiin, tunnistamiseen, luokitukseen, määrällisiin ominaisuuksiin tai ilmaisuun kokonaisuuden tilasta. Attribuutti edustaa ominaisuuden tai ominaisuuden tyyppiä, joka liittyy todellisten tai abstraktien objektien joukkoon (ihmiset, paikat, tapahtumat, tilat, ideat, objektiparit jne.). Attribuutti-ilmentymä on joukon yksittäisen elementin erityinen ominaisuus. Attribuutti-ilmentymä määritellään ominaistyypin ja sen arvon mukaan, jota kutsutaan attribuutin arvoksi. ER-mallissa attribuutit liitetään tiettyihin entiteeteihin. Siten entiteettiinstanssilla on oltava yksi määritetty arvo liittyvälle attribuutille.

Attribuutti voi olla joko pakollinen tai valinnainen (Kuva 2.23). Pakollinen tarkoittaa, että attribuutilla ei voi olla nolla-arvoja. Attribuutti voi olla joko kuvaava (eli normaali kokonaisuuden kuvaaja) tai osa yksilöllistä tunnistetta (ensisijainen avain).

Ainutlaatuinen tunnisteon attribuutti tai attribuuttien ja/tai suhteiden kokoelma, joka on suunniteltu yksilöimään tietyn entiteettityypin jokainen esiintymä. Täydellisen tunnistuksen tapauksessa tietyn entiteettityypin jokainen esiintymä tunnistetaan täysin omilla avainattribuuttillaan, muuten sen tunnistamiseen osallistuvat myös toisen emokokonaisuuden attribuutit (Kuva 2.24).

Riisi. 2.23.

Riisi. 2.24.

Jokainen attribuutti tunnistetaan ainutlaatuisella nimellä, joka ilmaistaan ​​substantiivilauseella, joka kuvaa ominaisuutta, jota attribuutti edustaa. Attribuutit näytetään nimiluettelona yhdistetyn entiteettilohkon sisällä, ja jokainen attribuutti on erillisellä rivillä. Attribuutit, jotka määrittävät ensisijaisen avaimen, sijoitetaan luettelon yläosaan ja on merkitty "#"-merkillä.

Jokaisella entiteetillä on oltava vähintään yksi mahdollinen avain. Mahdollinen entiteettiavain on yksi tai useampi attribuutti, jonka arvot tunnistavat yksilöllisesti jokaisen entiteettiinstanssin. Kun mahdollisia avaimia on useita, yksi niistä on määritetty ensisijaiseksi avaimeksi ja loput vaihtoehtoisiksi avaimille.

Käytettävissä olevat tiedot huomioon ottaen täydennämme aiemmin laadittua kaaviota (kuva 2.25).

Tietomalli voi sisältää lueteltujen perusrakenteiden lisäksi useita lisärakenteita.

Alatyypit ja supertyypit:yksi kokonaisuus on yleistävä käsite samanlaisten entiteettien ryhmälle (kuva 2.26).

Toisensa poissulkevat suhteet:kukin entiteettiinstanssi osallistuu vain yhteen suhteeseen toisensa poissulkevien suhteiden ryhmästä (kuva 2.27).

Riisi. 2.25.

Riisi. 2.26. Alatyypit ja supertyypit

Riisi. 2.27. Toisensa poissulkevia suhteita

Rekursiivinen linkki:kokonaisuus voi olla suhteessa itseensä (Kuva 2.28).

Ei-siirrettävät linkit:entiteettiinstanssia ei voi siirtää suhdeilmentymästä toiseen (Kuva 2.29).

Riisi. 2.28. Rekursiivinen suhde

Riisi. 2.29. Yhteys, jota ei voi siirtää

2.4.2. Metodologia IDEF1

Myös T. Rameyn kehittämä IDEF1-menetelmä perustuu P. Chenin lähestymistapaan ja mahdollistaa kolmannen normaalimuodon relaatiomallia vastaavan tietomallin rakentamisen. Tällä hetkellä IDEF1-metodologian parantamisen perusteella sen uusi versio- IDEF1X-metodologia. IDEF1X on suunniteltu oppimisen ja automatisoinnin helppoutta ajatellen. IDEF1X-kaavioita käyttävät useat yleiset CASE-työkalut (esim. ERwin, Design/IDEF).

IDEF1X-metodologian entiteetti on tunnuksesta riippumaton tai yksinkertaisesti riippumaton, jos jokainen entiteettiinstanssi voidaan tunnistaa yksilöllisesti määrittelemättä sen suhdetta muihin entiteeteihin. Entiteettiä kutsutaan tunnisteriippuvaiseksi tai yksinkertaisesti riippuvaiseksi, jos entiteetin ilmentymän yksilöllinen tunniste riippuu sen suhteesta toiseen entiteettiin (Kuva 2.30).

Riisi. 2.30. Esanssit

Jokaiselle entiteetille on määritetty yksilöllinen nimi ja numero, jotka erotetaan vinoviivalla "/" ja sijoitetaan lohkon yläpuolelle.

Suhde voidaan määritellä tarkemmin määrittämällä aste tai kardinaliteetti (aliliantiteettiinstanssien lukumäärä, joka voi olla olemassa kullekin pääentiteetin ilmentymälle). IDEF1X:ssä voidaan ilmaista seuraavat kardinaalit:

jokaiseen pääentiteetin ilmentymään voi liittyä nolla, yksi tai useampi aliolion ilmentymä;

jokaiseen pääentiteetin ilmentymään on liitettävä vähintään yksi alikokonaisuusilmentymä;

jokaiseen emokokonaisuusilmentymään saa olla liitetty enintään yksi alikokonaisuusilmentymä;

jokainen ylätason entiteetin ilmentymä liittyy johonkin kiinteään määrään alikokonaisuuksia.

Jos alikokonaisuuden ilmentymä määräytyy yksiselitteisesti sen suhteen emokokonaisuuden kanssa, suhdetta kutsutaan tunnistavaksi, muussa tapauksessa sitä kutsutaan ei-identifioivaksi.

Suhdetta edustaa emokokonaisuuden ja alikokonaisuuden välille piirretty viiva, jonka rivin lopussa on piste alikokonaisuuden kohdalla. Linkin teho on merkitty kuvan 1 mukaisesti. 2,31 (oletusteho - N).

Riisi. 2.31. Viestintäteho

Tunnistava suhde ylä- ja alikokonaisuuksien välillä näkyy yhtenäisenä viivana (Kuva 2.32). Tunnistavassa suhteessa oleva alikokonaisuus on identiteetistä riippuvainen entiteetti. Tunnistavassa suhteessa oleva emokokonaisuus voi olla joko itsenäinen tai riippuvainen tunnisteesta (tämä määräytyy sen suhteiden perusteella muihin entiteeteihin).

Riisi. 2.32. Tunnistava linkki

Pisteviiva kuvaa ei-identifioivaa suhdetta (kuva 2.33). Tunnistamattomassa suhteessa oleva alikokonaisuus on tunnuksesta riippumaton, ellei se ole myös alikokonaisuus jossain tunnistavassa suhteessa.

Riisi. 2.33. Tunnistamaton suhde

Attribuutit näytetään nimiluettelona entiteettilohkon sisällä. Ensisijaisen avaimen määrittävät attribuutit sijoitetaan luettelon yläosaan ja erotetaan muista määritteistä vaakaviivalla (kuva 2.34).

Riisi. 2.34. Attribuutit ja ensisijaiset avaimet

Entiteeteillä voi olla myös vieraita avaimia (Foreign Key), joita voidaan käyttää ensisijaisen avaimen tai muun kuin avaimen määritteen osana tai kokonaan. Vieras avain esitetään sijoittamalla attribuuttien nimet entiteettilohkon sisään ja kirjaimet FK suluissa (Kuva 2.35).

Riisi. 2.35. Esimerkkejä vieraista avaimista

2.5. Esimerkki rakenteellisen lähestymistavan käytöstä

2.5.1. Aihealueen kuvaus

Tässä esimerkissä käytetään Vantage Team Builder CASE -työkalussa toteutettua Yourdon-metodologiaa.

Aihealue on videokirjaston työnkuvaus, joka vastaanottaa asiakkaiden elokuvia koskevia pyyntöjä ja asiakkaiden palauttamia nauhoja. Videokirjaston hallinto käsittelee pyynnöt asiakastietojen, elokuvien ja nauhojen avulla. Tämä tarkistaa ja päivittää vuokrattujen nauhojen luettelon ja tarkistaa kirjaston jäsentiedot. Hallinto valvoo myös nauhojen palautuksia elokuvien tiedoilla, nauhoilla ja vuokranauhojen listalla, jota päivitetään. Elokuvapyyntöjen ja nauhapalautusten käsittely sisältää seuraavat asiat: Jos asiakas ei ole kirjaston jäsen, asiakas ei ole oikeutettu lainaan. Mikäli tarvittava elokuva on saatavilla, hallinto ilmoittaa asiakkaalle vuokramaksun. Jos asiakas on kuitenkin ylittänyt omistamiensa nauhojen palautusajan, hän ei saa ottaa uusia elokuvia. Kun nauha palautetaan, hallinto laskee vuokran ja myöhästymismaksun.

Videokirjasto saa uusia nauhoja toimittajiltaan. Kun uusia nauhoja saapuu kirjastoon, niistä tallennetaan tarvittavat tiedot. Kirjaston jäsentiedot säilytetään erillään nauhavuokraustiedoista.

Kirjaston hallinto laatii säännöllisesti raportteja tietty ajanjakso aikaa kirjaston jäsenistä, nauhojen toimittajista, tietyistä nauhalainoista ja kirjaston ostamista nauhoista.

2.5.2. Projektiorganisaatio

Koko projekti on jaettu 4 vaiheeseen: analyysi, globaali suunnittelu (järjestelmäarkkitehtuurin suunnittelu), yksityiskohtainen suunnittelu ja toteutus (ohjelmointi).

Analyysivaiheessa rakennetaan ympäristömalli. Ympäristömallin rakentaminen sisältää:

• järjestelmän käyttäytymisen analysointi (IS:n tarkoituksen määrittäminen, alkuperäisen kontekstitietovuokaavion (DFD) rakentaminen ja tapahtumaluettelomatriisin (ELM) generointi, kontekstikaavioiden rakentaminen);
• data-analyysi (tietovirtojen koostumuksen määrittäminen ja tietorakennekaavioiden (DSD) rakentaminen, globaalin tietomallin rakentaminen ER-kaavion muodossa).

IS:n tarkoitus määrittää suunnittelijoiden ja asiakkaiden välisen sopimuksen tulevan IS:n tarkoituksesta, yleinen kuvaus IP suunnittelijoille itselleen ja IP:n raja. Tehtävä on kiinteä tekstikommentti kontekstikaavion "nolla"-prosessissa.

Esimerkiksi tässä tapauksessa IP:n tarkoitus on muotoiltu seuraavasti: tietokannan ylläpitäminen kirjaston jäsenistä, elokuvista, vuokrauksista ja toimittajista. Samalla kirjaston johdon tulee pystyä vastaanottamaan erilaisia raportteja tehtäviensä suorittamiseksi.

Ennen kontekstuaalisen DFD:n rakentamista on tarpeen analysoida ulkoiset tapahtumat (ulkoiset objektit), jotka vaikuttavat kirjaston toimintaan. Nämä objektit ovat vuorovaikutuksessa IS:n kanssa vaihtamalla tietoja sen kanssa.

Aihealueen kuvauksesta seuraa, että kirjaston prosessissa ovat mukana seuraavat ihmisryhmät: asiakkaat, toimittajat ja johto. Nämä ryhmät ovat ulkoisia kokonaisuuksia. Ne eivät vain ole vuorovaikutuksessa järjestelmän kanssa, vaan myös määrittävät sen rajat ja ne on kuvattu alkuperäisessä kontekstuaalisessa DFD:ssä terminaattoreina (ulkoisina entiteeteinä).

Alkuperäinen kontekstikaavio on esitetty kuvassa 2.42. Toisin kuin Gane/Sarson-merkintä, ulkoiset entiteetit merkitään säännöllisillä suorakulmioilla ja prosessit ympyröillä.

Riisi. 2.42. Alkuperäinen kontekstikaavio

Tapahtumalista on rakennettu matriisin (ELM) muotoon ja se kuvaa erilaisia ​​aktiviteetteja ulkopuoliset entiteetit ja IS:n reaktio niihin. Nämä toimet ovat ulkoisia tapahtumia, jotka vaikuttavat kirjastoon. On olemassa seuraavan tyyppisiä tapahtumia:

Lyhenne	Tyyppi
	Normaali ohjaus
	normaali data
	Normaali ohjaus/data
	Väliaikainen hallinta
	Väliaikaiset tiedot
	Väliaikainen valvonta/tiedot

Kaikki toiminnot on merkitty normaaleiksi tiedoiksi. Nämä tiedot ovat tapahtumia, jotka IS havaitsee suoraan, esimerkiksi asiakkaan osoitteen muutos, joka on rekisteröitävä välittömästi. Ne näkyvät DFD:ssä tietovirtojen sisältönä.

Tapahtumaluettelomatriisi näyttää tältä:

	Kuvaus	Tyyppi	Reaktio
	Asiakas haluaa liittyä kirjaston jäseneksi		Asiakkaan rekisteröinti kirjaston jäseneksi
	Asiakas ilmoittaa osoitteenmuutoksesta		Rekisteröi muuttunut asiakasosoite
	Asiakas pyytää elokuvan vuokrausta		Pyydä tarkistusta
	Asiakas palauttaa elokuvan		Palauta rekisteröinti
	Johto valtuuttaa uuden toimittajan		Myyjän rekisteröinti
	Toimittaja ilmoittaa osoitteenmuutoksen		Muutetun myyjäosoitteen rekisteröinti
	Toimittaja lähettää elokuvan kirjastoon		Hanki uusi elokuva
	Johto pyytää uutta raporttia		Vaaditun raportin laatiminen johdolle

Järjestelmän käyttäytymisen toiminnallisen näkökohdan analyysin viimeistelemiseksi rakennetaan täydellinen kontekstikaavio, joka sisältää nollatason kaavion. Samaan aikaan "kirjasto"-prosessi on jaettu 4 prosessiin, jotka heijastavat kirjaston hallinnollisten toimintojen päätyyppejä. Olemassa olevat "abstraktit" tietovirrat päättäjien ja prosessien välillä muunnetaan virroiksi, jotka edustavat tiedonvaihtoa konkreettisemmalla tasolla. Tapahtumaluettelo näyttää mitä virtoja tällä tasolla on olemassa: jokaisen luettelon tapahtuman on muodostettava tietty virta (tapahtuma muodostaa tulovirran, reaktio muodostaa lähtövirran). Yksi "abstrakti" lanka voidaan jakaa useampaan kuin yhteen "konkreettiseen" lankaan.

Virtaa ylätason kaaviossa	Virtaa nollatasokaaviossa
Tiedot asiakkaalta	Asiakastiedot, vuokrapyyntö
Tietoa asiakkaalle	Jäsenkortti, Vastaa vuokrapyyntöön
Tiedot johdolta	Uuden jäsenen raporttipyyntö, uusi toimittaja, toimittajaraporttipyyntö, vuokraraporttipyyntö, elokuvaraporttipyyntö
Hallintotiedot	Uuden jäsenen raportti, myyjäraportti, vuokraraportti, elokuvaraportti
Tiedot toimittajalta	Toimittajatiedot, uudet elokuvat

Kuvassa 2.43 esitetyssä DFD:ssä "kirjasto"-tietovarasto on tietovaraston globaali tai abstrakti esitys.

Järjestelmän toiminnan toiminnallisen puolen analyysi antaa käsityksen tietojen vaihdosta ja muuntamisesta järjestelmässä. "Abstraktien" tietovirtojen ja "konkreettisten" tietovirtojen välinen suhde nollatasokaaviossa ilmaistaan ​​tietorakennekaavioissa (Kuva 2.44).

Analyysivaiheessa rakennetaan globaali tietomalli, joka esitetään kokonaisuus-suhdekaavion muodossa (kuva 2.45).

Välillä erilaisia ​​tyyppejä kaavioissa on seuraavat suhteet:

• ELM-DFD: tapahtumat - tulovirrat, reaktiot - lähtövirrat
• DFD-DSD: tietovirrat - huipputason tietorakenteet
• DFD-ERD: tiedonkerääjät - ER-kaaviot
• DSD-ERD: matalan tason tietorakenteet – entiteettiattribuutit

Arakennetaan aihemalli. Aihemallin rakentamisprosessi sisältää:

• Yksityiskohtainen kuvaus järjestelmän toiminta;
• käytetyn tiedon lisäanalyysi ja loogisen tietomallin rakentaminen tietokannan myöhempää suunnittelua varten;
• määritetään käyttöliittymän rakenne, lomakkeiden määrittely ja niiden esiintymisjärjestys;
• tietovuokaavioiden ja tapahtumalistan tarkentaminen, interaktiivisten ja ei-interaktiivisten valinta alemman tason prosesseista, minispesifikaatioiden määrittely niille.

Riisi. 2.43. Kontekstikaavio

Riisi. 2.44. Tietorakenteiden kaavio

Arkkitehtuurisuunnittelun tulokset ovat:

• prosessimalli (järjestelmäarkkitehtuurikaaviot (SAD) ja minispesifikaatiot päällä). jäsenneltyä kieltä);
• tietomalli (ERD- ja ERD-alikaavio);
• käyttöliittymämalli (prosessien luokittelu interaktiivisiin ja ei-interaktiivisiin toimintoihin, lomakesekvenssikaavio (FSD - Form Sequence Diagram), josta näkyy, mitkä lomakkeet näkyvät sovelluksessa ja missä järjestyksessä. FSD vahvistaa näyttölomakekutsujen joukon ja rakenteen. FSD-kaaviot muodostavat hierarkian, jonka yläosassa on päämuoto sovellus, joka toteuttaa alijärjestelmän. Toisella tasolla ovat lomakkeet, jotka toteuttavat toiminnallisen rakenteen alemman tason prosesseja, jotka on kiinnitetty SAD-kaavioihin.

Riisi. 2.45. Entiteetti-suhdekaavio

Yksityiskohtaisessa suunnitteluvaiheessa rakennetaan modulaarinen malli. Modulaarinen malli tarkoittaa oikea malli suunniteltu sovellusjärjestelmä. Rakennusprosessi sisältää:

• tietokantamallin jalostus SQL-lauseiden seuraavaa sukupolvea varten;
• käyttöliittymärakenteen hienosäätö;
• käyttöliittymän logiikkaa ja liiketoimintalogiikkamallia kuvaavat lohkokaaviot (Structure Charts Diagram - SCD) ja linkittäminen lomakkeisiin.

Yksityiskohtaisen suunnittelun tulokset ovat:

• prosessimalli (interaktiivisten ja ei-vuorovaikutteisten toimintojen rakennekaaviot);
• tietomalli (kaikki sovelluksiin tarvittavat parametrit määritetään ERD:ssä);
• käyttöliittymämalli (Form Sequence Diagram (FSD), joka näyttää, mitkä lomakkeet näkyvät sovelluksessa ja missä järjestyksessä, kunkin lomakkeen ja tietyn rakennekaavion välinen suhde, kunkin lomakkeen ja yhden tai useamman ERD:n kokonaisuuden välinen suhde).

Toteutusvaiheessa rakennetaan toteutusmalli. Rakennusprosessi sisältää:

• SQL-lauseiden luominen, jotka määrittelevät kohdetietokannan rakenteen (taulukot, indeksit, eheysrajoitukset);
• lohkokaavioiden (SCD) ja muotosekvenssikaavioiden (FSD) tarkentaminen, jota seuraa sovelluskoodin luominen.

Tietovirtojen ja prosessien vuorovaikutuksen tietovarastojen analyysin perusteella suoritetaan osajärjestelmien lopullinen allokointi (alustava olisi pitänyt tehdä ja korjata jo vaatimusten muotoiluvaiheessa). toimeksianto). Osajärjestelmiä valittaessa on noudatettava toiminnallisen liitettävyyden periaatetta ja tietoriippuvuuden minimoimisen periaatetta. On syytä muistaa, että sellaisten osajärjestelmän elementtien, kuten kehitysvaiheessa olevien prosessien ja datan, perusteella on luotava itsenäisesti toimiva sovellus. Toisaalta prosesseja ja tietoja ryhmiteltäessä osajärjestelmiin on otettava huomioon tuotteen konfiguroinnin vaatimukset, jos ne on muotoiltu analyysivaiheessa.

Nykyaikaisten käyttöjärjestelmien ominaisuudet

Vuosi vuodelta käyttöjärjestelmien rakenne ja ominaisuudet kehittyvät. Viime aikoina uudet käyttöjärjestelmät ja uudet versiot jo olemassa olevista käyttöjärjestelmistä ovat sisällyttäneet joitakin rakenneosat jotka osallistuivat Isoja muutoksia näiden järjestelmien luonteeseen. Nykyaikaiset käyttöjärjestelmät täyttävät jatkuvasti kehittyvien laitteistojen ja ohjelmistojen vaatimukset. Ne voivat hallita nopeampia moniprosessorijärjestelmiä, nopeampia verkkolaitteita ja jatkuvasti kasvavaa valikoimaa tallennuslaitteita. Käyttöjärjestelmien suunnitteluun vaikuttaneista sovelluksista tulee huomioida multimediasovellukset, Internet-käyttötyökalut ja asiakas/palvelinmalli.

Käyttöjärjestelmien vaatimusten tasainen kasvu ei johda pelkästään niiden arkkitehtuurin parannuksiin, vaan myös uusien tapojen syntymiseen niiden organisoimiseksi. Kokeellisissa ja kaupallisissa käyttöjärjestelmissä on kokeiltu monenlaisia ​​lähestymistapoja ja rakennuspalikoita, joista useimmat voidaan ryhmitellä seuraaviin luokkiin.

mikroytimen arkkitehtuuri.

· Monisäikeistys.

· Symmetrinen monikäsittely.

· Hajautetut käyttöjärjestelmät.

· Oliolähtöinen suunnittelu.

Useimpien käyttöjärjestelmien erottuva piirre nykyään on suuri monoliittinen ydin. Käyttöjärjestelmän ydin tarjoaa suurimman osan ominaisuuksistaan, mukaan lukien ajoitus, tiedostojärjestelmän käsittely, verkko, laiteajurit, muistinhallinta ja monet muut. Tyypillisesti monoliittinen ydin toteutetaan yhtenä prosessina, jonka kaikki elementit käyttävät samaa osoiteavaruutta. Mikroytimen arkkitehtuurissa vain muutama tärkeimmistä toiminnoista on osoitettu ytimelle, mukaan lukien osoitetilan hallinta, prosessien välinen viestintä (IPC) ja perusaikataulutus. Muita käyttöjärjestelmäpalveluita tarjoavat prosessit, joita joskus kutsutaan palvelimiksi. Nämä prosessit toimivat käyttäjätilassa ja mikroydin käsittelee niitä aivan kuten muutkin sovellukset. Tämän lähestymistavan avulla voit jakaa käyttöjärjestelmän kehittämistehtävän ytimen kehittämiseen ja palvelinkehitykseen. Palvelimet voidaan räätälöidä tiettyjen sovellus- tai ympäristövaatimusten mukaan. Mikroytimen allokointi järjestelmän rakenteeseen yksinkertaistaa järjestelmän käyttöönottoa, varmistaa sen joustavuuden ja sopii hyvin myös hajautettuun ympäristöön. Itse asiassa mikroydin on vuorovaikutuksessa paikallisten ja etäpalvelin saman kaavan mukaan, mikä yksinkertaistaa hajautettujen järjestelmien rakentamista.

Monisäikeistys on tekniikka, jossa sovellusta suorittava prosessi jaetaan useisiin samanaikaisesti suorittaviin säikeisiin. Seuraavassa on tärkeimmät erot langan ja prosessin välillä.

· Virtaus. Lähetettävä työyksikkö, joka sisältää prosessorikontekstin (joka sisältää ohjelmalaskurin ja pinoosoittimen sisällön) sekä oman pinoalueen (alirutiinikutsujen järjestämiseen ja paikallisten tietojen tallentamiseen). Säiekomennot suoritetaan peräkkäin; säie voidaan keskeyttää, kun prosessori vaihtaa toiseen säikeeseen 4 .Prosessi. Joukko yhdestä tai useammasta säikeestä ja niihin liittyvistä järjestelmäresursseista (kuten koodia ja dataa sisältävä muistialue, avoimet tiedostot, erilaiset laitteet). Tämä konsepti on hyvin lähellä käynnissä olevan ohjelman käsitettä. Jakamalla sovelluksen useisiin säikeisiin ohjelmoija saa kaikki sovelluksen modulaarisuuden edut ja kyvyn hallita sovelluksiin liittyviä ajallisia tapahtumia.

Monisäikeistys on erittäin hyödyllinen sovelluksille, jotka suorittavat useita itsenäisiä tehtäviä, jotka eivät vaadi peräkkäistä suoritusta. Esimerkki tällaisesta sovelluksesta on tietokantapalvelin, joka hyväksyy ja käsittelee useita asiakaspyyntöjä samanaikaisesti. Jos samassa prosessissa käsitellään useita säikeitä, eri säikeiden välillä vaihtaminen kuormittaa vähemmän prosessoria kuin vaihtaminen eri prosessien välillä. Lisäksi säikeet ovat hyödyllisiä käyttöjärjestelmän ytimeen kuuluvien prosessien jäsentämisessä, kuten myöhemmissä luvuissa kuvataan.

Viime aikoihin asti kaikki henkilökohtaiset tietokoneet, joka oli suunniteltu yhdelle käyttäjälle, ja työasemat sisälsivät yhden yleiskäyttöisen virtuaalisen mikroprosessorin. Jatkuvasti kasvavien suorituskykyvaatimusten ja mikroprosessorien kustannusten laskun seurauksena valmistajat ovat siirtyneet valmistamaan tietokoneita, joissa on useita prosessoreita. Symmetric multiprocessing (SMP) -tekniikkaa käytetään tehokkuuden ja luotettavuuden parantamiseen. Tämä termi viittaa tietokoneen laitteiston arkkitehtuuriin sekä tapaan, jolla käyttöjärjestelmä käyttäytyy tämän mukaisesti. arkkitehtoninen ominaisuus. Symmetrinen moniprosessointi voidaan määritellä itsenäiseksi tietokonejärjestelmäksi, jolla on seuraavat ominaisuudet.

1. Järjestelmässä on useita prosessoreita.

2. Nämä prosessorit, jotka on kytketty toisiinsa tietoliikenneväylällä tai jollain muulla piirillä, jakavat saman päämuistin ja samat I/O-laitteet.

3. Kaikki prosessorit voivat suorittaa samoja toimintoja (siis nimi symmetrinen käsittely).

Symmetristä moniprosessointia käyttävässä järjestelmässä toimiva käyttöjärjestelmä jakaa prosessit tai säikeet kaikkien prosessorien kesken. Moniprosessorijärjestelmillä on useita mahdollisia etuja yksiprosessorijärjestelmiin verrattuna, mukaan lukien seuraavat.

· Esitys. Jos tietokoneen tarvitsema työ voidaan järjestää niin, että työn osat toimivat rinnakkain, tämä johtaa parempaan suorituskykyyn kuin yhden prosessorin järjestelmä, jossa on samantyyppinen prosessori. Yllä muotoiltu asento on havainnollistettu kuvassa. 2.12. Multitasking-tilassa vain yksi prosessi voi olla käynnissä samanaikaisesti, kun taas muut prosessit joutuvat odottamaan vuoroaan. Moniprosessorijärjestelmässä useita prosesseja voidaan suorittaa samanaikaisesti, joista jokainen toimii erillisellä prosessorilla.

· Luotettavuus. Symmetrisessä monikäsittelyssä yhden prosessorin vikaantuminen ei pysäytä konetta, koska kaikki prosessorit voivat suorittaa samoja toimintoja. Tällaisen vian jälkeen järjestelmä jatkaa toimintaansa, vaikka sen suorituskyky laskee hieman.

· Rakennus. Lisäämällä järjestelmään muita prosessoreita käyttäjä voi parantaa sen suorituskykyä.

· Skaalautuvuus. Valmistajat voivat tarjota tuotteitaan erilaisissa hinta- ja suorituskykykokoonpanoissa, jotka on suunniteltu toimimaan erilaisten prosessorimäärien kanssa.

On tärkeää huomata, että yllä luetellut edut ovat pikemminkin mahdollisia kuin taattuja. Jotta moniprosessoristen laskentajärjestelmien potentiaali voidaan toteuttaa oikein, käyttöjärjestelmän on tarjottava riittävä joukko työkaluja ja ominaisuuksia.

Riisi. 2.12. Moniajo ja monikäsittely

On tavallista, että monisäikeistä ja moniprosessoinneista keskustellaan yhdessä, mutta nämä kaksi käsitettä ovat toisistaan ​​riippumattomia. Monisäikeistys on hyödyllinen konsepti sovellus- ja ydinprosessien jäsentämiseen jopa yhdellä prosessorikoneella. Toisaalta moniprosessorijärjestelmällä voi olla etuja yksittäiseen prosessorijärjestelmään verrattuna, vaikka prosesseja ei olisikaan jaettu useisiin säikeisiin, koska tällaisessa järjestelmässä on mahdollista ajaa useita prosesseja samanaikaisesti. Molemmat mahdollisuudet sopivat kuitenkin hyvin yhteen ja niiden yhteiskäytöllä voi olla huomattava vaikutus.

Moniprosessorijärjestelmien houkutteleva piirre on, että useiden prosessorien läsnäolo on käyttäjälle läpinäkyvää - käyttöjärjestelmä vastaa säikeiden jakamisesta prosessorien välillä ja eri prosessien synkronoinnista. Tässä kirjassa käsitellään ajoitus- ja synkronointimekanismeja, joilla kaikki prosessit ja prosessorit saadaan käyttäjän nähtäviksi yhtenä järjestelmänä. Toinen korkeamman tason tehtävä on esittää useiden erillisten tietokoneiden klusterin yhtenä järjestelmänä. Tässä tapauksessa kyseessä on joukko tietokoneita, joista jokaisella on oma ensisijainen ja toissijainen muisti ja omat I/O-moduulit. Hajautettu käyttöjärjestelmä luo vaikutelman yhdestä ensisijaisen ja toissijaisen muistin tilasta sekä yhdestä tiedostojärjestelmästä. Vaikka klusterien suosio kasvaa tasaisesti ja markkinoille tulee yhä enemmän klusteroituja tuotteita, nykyaikaiset hajautetut käyttöjärjestelmät ovat edelleen kehityksessä jäljessä yksi- ja moniprosessorijärjestelmistä. Tutustut tällaisiin järjestelmiin kirjan kuudennessa osassa.

Yksi viimeisimmistä innovaatioista käyttöjärjestelmien suunnittelussa on ollut olioteknologian käyttö. Oliolähtöinen suunnittelu auttaa puhdistamaan lisämoduulien lisäämisen pieneen pääytimeen. Käyttöjärjestelmätasolla oliopohjainen rakenne mahdollistaa ohjelmoijien mukauttamisen käyttöjärjestelmä rikkomatta sen eheyttä. Lisäksi tämä lähestymistapa helpottaa hajautettujen työkalujen ja täysimittaisten hajautettujen käyttöjärjestelmien kehittämistä.

Talouskehitysministeriö Venäjän federaation tiede- ja koulutusministeriö Venäjän federaatiossa

State University -

Kauppakorkeakoulu

Yritysinformatiikan tiedekunta

Kuri abstrakti

« Ohjelmistosuunnittelun metodologia»

« CASE-ohjelmistojärjestelmien kehitysteknologiat».

Valmistunut:

Gladyshev I.A.

171 m, URPO

Tarkistettu:

Avdoshin S.M.

Moskova 2008

Johdanto

1. CASE-työkalu: määritelmät ja yleiset ominaisuudet.

2. CASE-tekniikoiden sovellukset: edut ja haitat.

3. CASE-tekniikoiden käyttöönotto.

4. Esimerkkejä CASE-työkaluista ja niiden ominaisuuksista.

4.3 Vantage Team Builder

4.4 Paikalliset työkalut (ERwin, BPwin, S-Designor)

4.5 Olio-CASE-työkalut (Rational Rose)

4.6 Konfiguroinnin hallintatyökalut

4.7 Dokumentointityökalut

4.8 Testaustyökalut

Johtopäätös

Kirjallisuus.

Johdanto

Esseen tarkoitus on pohtia kehitystekniikoita ohjelmistojärjestelmät perustuu CASE-varoihin. 70- ja 80-luvuilla IS:tä kehitettäessä käytettiin laajalti rakenteellista metodologiaa, joka tarjoaa kehittäjille tiukat formalisoidut menetelmät IS:n ja tehtyjen teknisten päätösten kuvaamiseen. Ohjelmoinnin historian aikana ohjelmistoprojektit ovat muuttuneet yhä monimutkaisemmiksi, työn määrä on kasvanut nopeasti ja tarve on yleismaailmallisille työkaluille, jotka voisivat jotenkin jäsentää ohjelmistojen luomista. Perinteiset ohjelmointikielet menettivät tehokkuutensa heikon näkyvyyden, redundanssin ja monisanaisuuden vuoksi, ja 70- ja 80-luvuilla rakenteellista metodologiaa käytettiin laajasti ohjelmistojärjestelmien kehittämisessä. Rakenneanalyysityökalujen näkyvyys ja tarkkuuden ansiosta järjestelmän kehittäjät ja tulevat käyttäjät pystyivät keskustelemaan ja vahvistamaan ymmärrystään tärkeimmistä teknisistä ratkaisuista. Kaikki meni erityisluokan ohjelmistojen ja teknisten välineiden syntymiseen.

1. CASE-työkalu: määritelmät ja yleiset ominaisuudet.

Lyhenne CASE tulee sanoista Computer Aided Software Engineering. Tätä termiä käytetään nykyään laajalti. Tällaisten työkalujen syntyvaiheessa termiä CASE käytettiin vain ohjelmistokehityksen automatisoinnin yhteydessä. Nykyään CASE-työkalut kattavat monimutkaisen IS:n kehittämisprosessin yleisesti: IS:n luomisen ja ylläpidon, analysoinnin, vaatimusten muotoilun, sovellusohjelmistojen ja tietokantojen suunnittelun, koodin generoinnin, testauksen, dokumentoinnin, laadunvarmistuksen, konfiguraationhallinnan ja projektinhallinnan sekä muut prosessit. Näin ollen CASE-teknologiat muodostavat kokonaisen ympäristön IS:n kehittämiselle. Joten CASE-teknologia on menetelmä ohjelmistojärjestelmien suunnitteluun sekä joukko työkaluja, joiden avulla voit visuaalisesti mallintaa aihealueen, analysoida tätä mallia kaikissa IS:n kehittämisen ja ylläpidon vaiheissa sekä kehittää sovelluksia käyttäjien tietotarpeiden mukaisesti. Useimmat olemassa olevat CASE-työkalut perustuvat rakenteellisiin tai oliopohjaisiin analyysi- ja suunnittelumenetelmiin, joissa käytetään kaavioiden tai tekstien muodossa olevia spesifikaatioita ulkoisten vaatimusten, järjestelmämallien välisten suhteiden, järjestelmän käyttäytymisdynamiikan ja ohjelmistoarkkitehtuurien kuvaamiseen. CASE-tuotteen pääkomponentit ovat seuraavat:

metodologia, joka määrittää yhden graafisen kielen ja sen kanssa työskentelyn säännöt.

graafiset editorit, jotka auttavat piirtämään kaavioita; syntyi PC:n ja GUI:n, niin sanottujen "isojen kirjainten teknologioiden" leviämisen myötä

generaattori: Tekijä graafinen esitys mallien avulla voit luoda lähdekoodia eri alustoille (ns. pienikokoinen osa CASE-teknologiasta).

arkisto, eräänlainen tietokanta ohjelmoijien työn tulosten tallentamiseen.

2. CASE-tekniikoiden sovellukset: edut ja haitat.

Erilaiset tilastokatsaukset osoittavat nykyään CASE-työkalujen käytön tehokkuudesta ohjelmistojärjestelmien kehitysprosessissa. Vikaprosentti on kuitenkin edelleen olemassa ja se on melko suuri. Tietysti tekniikan käytöllä on haittoja, merkittäviä ovat liiketoiminnan näkökohdat:

CASE-työkaluilla ei välttämättä ole välitöntä vaikutusta; se voidaan saada vasta jonkin ajan kuluttua;

CASE-työkalujen käyttöönoton todelliset kustannukset ovat yleensä paljon korkeammat kuin niiden hankintakustannukset;

CASE-työkalut tarjoavat mahdollisuuksia saada merkittäviä etuja vasta toteutusprosessinsa onnistuneen loppuun saattamisen jälkeen.

CASE-työkalujen monimuotoisuuden vuoksi olisi virheellistä esittää varauksettomia väitteitä tiettyjen niiden täytäntöönpanoon liittyvien odotusten todellisesta tyydyttämisestä. Voimme luetella seuraavat tekijät, jotka vaikeuttavat CASE-työkalujen käytön mahdollisen vaikutuksen määrittämistä:

laaja valikoima CASE-työkalujen laatua ja ominaisuuksia;

suhteellisen lyhyt aika CASE-työkalujen käyttöön eri organisaatioissa ja kokemuksen puute niiden soveltamisesta;

laaja valikoima eri organisaatioiden täytäntöönpanokäytäntöjä;

yksityiskohtaisten mittareiden ja tietojen puute jo päättyneistä ja käynnissä olevista projekteista;

laaja valikoima hankkeen aihealueita;

CASE-työkalujen erilainen integrointiaste eri projekteihin.

CASE-teknologioiden käytön tehokkuuden määrittämisessä on kaksi mielipidettä: jotkut uskovat, että todellista hyötyä tietyntyyppisten CASE-työkalujen käytöstä voidaan saada vasta yhden tai kahden vuoden kokemuksella, toiset taas uskovat, että vaikutus voi todella ilmetä IC:n elinkaaren käyttövaiheessa, jolloin teknologiset parannukset voivat johtaa käyttökustannusten laskuun. Organisaatiosta on kuitenkin olemassa useita merkkejä, joista ainakin yhden puuttuessa CASE-työkalujen käyttöönotto todennäköisesti päättyy epäonnistumaan:

Teknologia: olemassa olevien valmiuksien rajoitusten ymmärtäminen ja kyky hyväksyä uutta teknologiaa;

Kulttuuri: halu ottaa käyttöön uusia prosesseja ja suhteita kehittäjien ja käyttäjien välillä;

Johtaminen: selkeä ohjaus ja organisointi tärkeimpiin vaiheisiin ja toteutusprosesseihin liittyen.

korkeatasoinen teknologinen tuki ohjelmistokehitys- ja ylläpitoprosesseille;

positiivinen vaikutus joihinkin tai kaikkiin seuraavista tekijöistä: tuottavuus, tuotteiden laatu, standardien noudattaminen, dokumentointi;

CASE-työkaluihin tehdyn sijoitetun pääoman hyväksyttävän tuottotason.

3. CASE-tekniikoiden käyttöönotto.

Termiä "toteutus" käytetään tässä alaotsikossa melko laajassa merkityksessä ja se sisältää toiminnot alustavasta tarpeiden arvioinnista CASE-teknologioiden täysimääräiseen käyttöön käyttäjäorganisaation eri osastoilla. CASE-työkalujen käyttöönottoprosessi koostuu seuraavista vaiheista:

CASE-työkalujen tarpeiden määrittäminen;

CASE-työkalujen arviointi ja valinta;

pilottihankkeen toteuttaminen;

CASE-työkalujen käytännön toteutus.

CASE-työkalujen onnistunut käyttöönotto ei rajoitu vain niiden käyttöön. Itse asiassa se kattaa monien teknisten, organisatoristen ja rakenteellisten prosessien suunnittelun ja toteutuksen, organisaation yleisen kulttuurin muutokset ja perustuu CASE-työkalujen kykyjen selkeään ymmärtämiseen. Tilanne voi vaikuttaa tapaan, jolla käytät CASE-työkaluja. Jos esimerkiksi asiakas pitää tietyn työkalun parempana tai sitä vaaditaan sopimuksessa, toteutusvaiheiden tulee noudattaa tätä ennalta määritettyä valintaa. Muissa tilanteissa työkalun suhteellinen yksinkertaisuus tai monimutkaisuus, johdonmukaisuuden tai ristiriidan aste organisaation olemassa olevien prosessien kanssa, vaadittu integraatioaste muihin työkaluihin, käyttäjien kokemus ja pätevyys voivat johtaa asianmukaisiin säätöihin käyttöönottoprosessiin.

4. Esimerkkejä CASE-työkaluista ja niiden ominaisuuksista.

4.1 Hopeinen juoksu

Amerikkalaisen Computer Systems Advisers, Inc. -yrityksen Silverrun CASE -työkalu. käytetään bisnesluokan IC:n analysointiin ja suunnitteluun. Se soveltuu tukemaan mitä tahansa metodologiaa, joka perustuu toiminnallisten ja tietomallien erilliseen rakentamiseen. Silverrun on modulaarinen ja koostuu neljästä moduulista, joista jokainen on erillinen tuote ja voidaan ostaa ja käyttää ilman yhteyttä muihin moduuleihin: liiketoimintaprosessimallin rakennusmoduuli, käsitteellinen tietomallinnusmoduuli, relaatiomallinnusmoduuli ja työryhmän tietovaraston hallinta. Hinta, joka maksetaan mallien rakentamisen suuresta joustavuudesta ja visuaalisten työkalujen monipuolisuudesta, on Silverrunin haittana sellainen, että eri mallien komponenttien välillä ei ole tiukkaa keskinäistä valvontaa.

JAM-sovelluskehitystyökalu on amerikkalaisen JYACC:n tuote. JAM:n tärkein ominaisuus on sen yhteensopivuus RAD-metodologia, koska sen avulla voit nopeasti toteuttaa sovelluskehityssyklin, joka koostuu sovelluksen prototyypin seuraavan version luomisesta ottaen huomioon edellisessä vaiheessa tunnistetut vaatimukset ja esittelemällä se käyttäjälle. JAM on modulaarinen ja koostuu seuraavista osista:

Järjestelmän ydin;

JAM/DBi - erikoistuneet DBMS-liitäntämoduulit (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC jne.);

JAM/RW - raporttigeneraattorimoduuli;

JAM/CASEi - erikoistuneet liitäntämoduulit CASE-työkaluille (JAM/CASE-TeamWork, JAM/CASE-Innovator jne.);

JAM/TPi - erikoistuneet liitäntämoduulit tapahtumien hallintaan (esimerkiksi JAM/TPi-Server TUXEDO jne.);

Jterm on erikoistunut X-pääteemulaattori.

Järjestelmän ydin (itse asiassa itse JAM) on valmis tuote ja sitä voidaan käyttää itsenäisesti sovellusten kehittämiseen. Kaikki muut moduulit ovat valinnaisia ​​eikä niitä voi käyttää itsenäisesti. JAM:ia käytettäessä sovelluksen ulkoisen käyttöliittymän kehittäminen on visuaalista suunnittelua ja tiivistyy näyttölomakkeiden luomiseen asettamalla niihin käyttöliittymärakenteita ja määrittämällä näytöllä näkyvät tiedon syöttö-/tulostuskentät.

4.3 VantagetiimiRakentaja

Vantage Team Builder on integroitu ohjelmistotuote, joka keskittyy toteuttamaan vesiputousohjelmiston elinkaarimallia ja tukemaan ohjelmiston koko elinkaarta. Universaalin koodinluontijärjestelmän läsnäolo, joka perustuu määritettyihin projektitietovarastoon pääsyyn, mahdollistaa sen, että kehittäjät voivat toteuttaa projektin kurinalaisuutta korkealla tasolla: tiukka menettely mallien luomiseksi; dokumentaation jäykkä rakenne ja sisältö; ohjelmien lähdekoodien automaattinen luominen jne. - kaikki tämä lisää kehitetyn IS:n laatua ja luotettavuutta.

4.4 Paikalliset työkalut (ERwin, BPwin, S-Designor)

ERwin on käsitteellinen tietokannan mallinnustyökalu, joka käyttää IDEF1X-metodologiaa. ERwin toteuttaa tietokantaskeeman suunnittelun, sen kuvauksen luomisen kohdetietokantajärjestelmän kielellä ja olemassa olevan tietokannan uudelleensuunnittelun. ERwin on saatavana useissa eri kokoonpanoissa, jotka on kohdistettu yleisimpiin 4GL-sovelluskehitystyökaluihin. Useille sovellusten kehitystyökaluille (PowerBuilder, SQLWindows, Delphi, Visual Basic) luodaan lomakkeita ja sovellusprototyyppejä. BPwin on toiminnallinen mallinnustyökalu, joka toteuttaa IDEF0-metodologian. S-Designor on CASE-työkalu relaatiotietokantojen suunnitteluun. Se on toiminnallisuudeltaan ja kustannuksiltaan lähellä ERwin CASE -työkalua, ja se eroaa kaavioissa käytetystä ulkoisesta merkinnästä. S-Designor toteuttaa standardinmukaisen tiedon mallinnusmenetelmän ja luo tietokantakuvauksen sellaisille tietokantajärjestelmille kuin ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server jne.

4.5 Olio-CASE-työkalut (Rational Rose)

Rational Rose, Rational Software Corporationin CASE-työkalu, on suunniteltu automatisoimaan ohjelmistoanalyysin ja -suunnittelun vaiheita sekä generoimaan koodeja eri kielillä ja antamaan projektidokumentaatiota. Rational Rose käyttää synteesimetodologiaa olio-analyysiin ja suunnitteluun, joka perustuu kolmen alan johtavan asiantuntijan, Boochin, Rumbaughin ja Jacobsonin, lähestymistapaan. He kehittivät yleisen merkintätavan objektien mallintamiseen (UML - Unified Modeling Language), joka väittää olevansa standardi oliopohjaisen analyysin ja suunnittelun alalla. Rational Rosen erityinen muunnelma määräytyy sen kielen mukaan, jolla ohjelmakoodit luodaan (C++, Smalltalk, PowerBuilder, Ada, SQLWindows ja ObjectPro). Päävaihtoehto - Rational Rose / C ++ - antaa sinun kehittää suunnitteludokumentaatiota kaavioiden ja eritelmien muodossa sekä luoda ohjelmakoodeja C ++ -kielellä. Lisäksi Rational Rose sisältää ohjelmistojen uudelleensuunnittelutyökalut, jotka mahdollistavat ohjelmistokomponenttien uudelleenkäytön uusissa projekteissa.

4.6 Konfiguroinnin hallintatyökalut

Konfiguraatiohallinnan tarkoituksena on tarjota ohjelmistokehitys- ja ylläpitoprosessien hallittavuutta ja ohjattavuutta. Tämä edellyttää tarkkoja ja luotettavia tietoja ohjelmiston ja sen komponenttien tilasta kulloinkin sekä kaikista ehdotetuista ja toteutetuista muutoksista. CG-ongelmien ratkaisemiseen käytetään menetelmiä ja työkaluja, joilla varmistetaan komponenttien tilan tunnistaminen, järjestelmän kaikkien komponenttien ja muutosten ottaminen kokonaisuutena, komponentteihin tehtyjen muutosten, järjestelmän rakenteen ja toimintojen hallinta sekä toimintojen kehittämisen ja järjestelmän ominaisuuksien parantamisen koordinoitu hallinta. Yleisin KU-työkalu on Intersolvin (USA) PVCS, joka sisältää useita itsenäisiä tuotteita: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder ja PVCS Notify.

4.7 Dokumentointityökalut

IS-kehitysprosessin dokumentaation luomiseen käytetään erilaisia ​​raportointityökaluja sekä julkaisujärjestelmien komponentteja. Dokumentointityökalut on yleensä rakennettu tiettyihin CASE-työkaluihin. Poikkeuksen muodostavat jotkin paketit, jotka tarjoavat lisäpalvelua dokumentoinnissa. Näistä SoDA (Software Document Automation) on aktiivisimmin käytetty.

Tuote on suunniteltu automatisoimaan projektidokumentaation kehitystä ohjelmiston elinkaaren kaikissa vaiheissa. Sen avulla voit automaattisesti poimia erilaisia ​​tietoja, jotka on saatu projektin kehittämisen eri vaiheissa ja sisällyttää ne tulosasiakirjoihin. Samalla valvotaan dokumentaation yhteensopivuutta projektin kanssa, asiakirjojen yhteenliittämistä ja varmistetaan niiden oikea-aikainen päivitys. Tuloksena oleva dokumentaatio luodaan automaattisesti useista lähteistä, joiden määrää ei ole rajoitettu.

4.8 Testaustyökalut

Testaus on prosessi, jossa ohjelma suoritetaan virheiden havaitsemiseksi. Regressiotestaus on testausta, joka suoritetaan ohjelman toimintojen parantamisen tai siihen tehtyjen muutosten jälkeen. Yksi edistyneimmistä testaustyökaluista, Quality Works on integroitu monialustainen ympäristö minkä tahansa tason automaattisten testien kehittämiseen, mukaan lukien regressiotestit GUI-sovelluksille. Quality Worksin avulla voit aloittaa testauksen missä tahansa elinkaaren vaiheessa, suunnitella ja hallita testausprosessia, näyttää muutokset sovelluksessa ja käyttää testejä uudelleen yli 25 eri alustalle.

Johtopäätös

Työssä tarkasteltiin teknologioita CASE-teknologioihin perustuvien ohjelmistojärjestelmien kehittämiseen. Näin laajan käsitteen CASE-työkalun määritelmää analysoidaan yksityiskohtaisesti ja tunnistetaan CASE-tuotteen pääkomponentit. Pohdin myös työssäni CASE-työkalujen käytön tärkeimpiä etuja ja mahdollisia haittoja ohjelmistojärjestelmien kehittämisessä niin teknisesti kuin taloudellisestikin. Lisäksi lueteltiin esimerkkejä CASE-tekniikoista ja annettiin niiden ominaisuudet.

Tietotekniikan kehityssuuntaukset nykyään sanelevat vaadittujen tietojärjestelmien monimutkaisuuden uudelle tasolle. Suuret projektit IS:lle on nykyään ominaista näkökohdat, jotka vaativat implisiittisiä mallinnusmenetelmiä. Tällainen ohjelmistojärjestelmien kehittäminen ei ole mahdollista tehokkuutensa täysissä määrin ilman CASE-työkalujen käyttöä. Nykyaikaiset CASE-työkalut kattavat laajan tuen useille IS-suunnittelutekniikoille: yksinkertaisista analyysi- ja dokumentointityökaluista täysimittaisiin automaatiotyökaluihin, jotka kattavat ohjelmiston koko elinkaaren.

Kirjallisuus.

OLEN. Vendrov: CASE-teknologiat. Nykyaikaiset menetelmät ja työkalut tietojärjestelmien suunnitteluun
M.: Talous ja tilastot, 1998. - 176 s.: kuvitus

Kalyanov G.N. tapaus. Rakenteellinen järjestelmäanalyysi(automaatio ja sovellus). M., "Lori", 1998.

Novozhenov Yu.V. Oliopohjaiset teknologiat monimutkaisten ohjelmistojärjestelmien kehittämiseen. M., 1997

Panashchuk S.A. Tietojärjestelmien kehittäminen CASE-järjestelmällä Silverrun. "SUBD", 1997.

Gorchinskaya O.Yu. Designer/2000 on uuden sukupolven ORACLE CASE -tuotteita. "SUBD", 1996.

Gorin S.V., Tandoev A.Yu. CASE-työkalun Erwin 2.0 käyttö tietojen mallintamiseen tietojenkäsittelyjärjestelmissä. "SUBD", 1999.