CASE-teknologier for utforming av informasjonssystemer
I løpet av det siste tiåret har en ny retning innen programvareutvikling blitt dannet - CASE (Computer-Aided Software / System Engineering) - i bokstavelig oversettelse - utvikling av programvare for informasjonssystemer med støtte (med hjelp) fra en datamaskin. Foreløpig er det ingen generelt akseptert definisjon av CASE, begrepet CASE brukes i en veldig bred forstand. Den opprinnelige betydningen av begrepet CASE, begrenset til spørsmål om automatisering av utvikling av bare programvare, har nå fått en ny betydning, som dekker prosessen med å utvikle komplekse automatiserte informasjonssystemer som helhet. Nå betyr begrepet CASE-verktøy programvareverktøy som støtter prosessene for å opprette og vedlikeholde IS, inkludert analyse og formulering av krav, design av applikasjonsprogramvare (programvare) (applikasjoner) og databaser, kodegenerering, testing, dokumentasjon, kvalitetssikring, konfigurasjon prosjektledelse og -ledelse, og andre prosesser. CASE-verktøy sammen med systemprogramvare og maskinvare utgjør et komplett IS-utviklingsmiljø.
CASE-verktøy lar deg ikke bare lage de "riktige" produktene, men også gi den "riktige" prosessen for å lage dem. Hovedmålet med CASE er å skille utformingen av IC fra kodingen og påfølgende utviklingsstadier, samt å skjule for utviklerne alle detaljene i utviklingsmiljøet og funksjonen til IC. Ved bruk av CASE-teknologier endres alle stadier av programvarens livssyklus (mer om dette vil bli diskutert nedenfor) av informasjonssystemet, mens de største endringene er knyttet til stadier av analyse og design. De fleste av de eksisterende CASE-verktøyene er basert på strukturelle (for det meste) eller objektorienterte analyse- og designmetodikker som bruker spesifikasjoner i form av diagrammer eller tekster for å beskrive eksterne krav, forhold mellom systemmodeller, dynamikk i systematferd og programvarearkitektur. Slike metodikker gir en streng og beskrivende beskrivelse av det projiserte systemet, som begynner med en generell oversikt og deretter går i detalj, og får en hierarkisk struktur med et økende antall nivåer. CASE-teknologier brukes med hell til å bygge nesten alle typer IP, men de inntar en stabil posisjon på følgende områder:
for å sikre utviklingen av forretningsmessig og kommersiell IP, skyldes den utbredte bruken av CASE-teknologier den massive naturen til dette anvendte feltet, der CASE brukes ikke bare til utvikling av IP, men også for å lage modeller av systemer som hjelper til med å løse problemer med strategisk planlegging, økonomisk styring, fastsettelse av politikken til firmaer, opplæringspersonell og andre (dette området fikk sitt eget navn - forretningsanalyse);
utvikling av system og kontroll IS. Den aktive bruken av CASE-teknologier er assosiert med den store kompleksiteten til dette problemet og med ønsket om å øke effektiviteten i arbeidet.
I tillegg til å automatisere strukturelle metoder og, som en konsekvens, muligheten for å bruke moderne metoder for system- og programvareutvikling, har CASE-verktøyene følgende hovedfordeler:
forbedre kvaliteten på opprettet IS ved hjelp av automatisk kontroll (først av alt, prosjektkontroll);
lar deg lage en prototype av et fremtidig system på kort tid, som lar deg evaluere det forventede resultatet på et tidlig stadium;
fremskynde design- og utviklingsprosessen;
frigjøre utvikleren fra rutinearbeid, slik at han kan konsentrere seg helt om den kreative delen av utviklingen;
støtte utvikling og vedlikehold av utvikling;
støtte gjenbruksteknologier for utviklingskomponenter.
Det skal forstås at vellykket bruk av CASE-verktøy er umulig uten å forstå den underliggende teknologien som disse verktøyene er basert på. I seg selv er CASE-programvareverktøy verktøy for å automatisere designprosesser og vedlikehold av informasjonssystemer. Det er umulig å bruke CASE-verktøy uten å forstå metodikken for å designe IS.
^
Kjennetegn på moderne CASE-verktøy
Moderne CASE-verktøy dekker et bredt område med støtte for en rekke IC-designteknologier: fra enkle analyse- og dokumentasjonsverktøy til fullskala automasjonsverktøy som dekker hele livssyklusen (LC) til en IC.
De mest tidkrevende stadiene i IS-utviklingen er fasene av analyse og design, hvor CASE-verktøy sikrer kvaliteten på de vedtatte tekniske løsningene og utarbeidelsen av prosjektdokumentasjon. Samtidig spiller metoder for visuell presentasjon av informasjon en viktig rolle. Dette innebærer konstruksjon av strukturelle eller andre diagrammer i sanntid, bruk av en mangfoldig fargepalett og ende-til-ende kontroll av syntaksregler. Grafiske verktøy for modellering av fagområdet lar utviklere visuelt studere eksisterende IS, gjenoppbygge det i samsvar med målene og eksisterende begrensninger.
Kategorien CASE-verktøy inkluderer både relativt billige systemer for personlige datamaskiner med svært begrensede muligheter, og dyre systemer for heterogene dataplattformer og driftsmiljøer. Så det moderne programvaremarkedet har rundt 300 forskjellige CASE-verktøy, hvorav de kraftigste, på en eller annen måte, brukes av nesten alle ledende vestlige selskaper.
Vanligvis inkluderer CASE-verktøy et hvilket som helst programvareverktøy som automatiserer et bestemt sett med prosesser i livssyklusen til en IS og har følgende hovedkarakteristiske egenskaper:
kraftige grafiske verktøy for å beskrive og dokumentere IP, gi et praktisk grensesnitt med utvikleren og utvikle hans kreative evner;
integrering av individuelle komponenter av CASE-verktøy, som gir kontrollerbarhet av IS-utviklingsprosessen;
ved hjelp av et spesielt organisert arkiv med prosjektmetadata (repository). Et integrert CASE-verktøy (eller et sett med verktøy som støtter en komplett IS-livssyklus) inneholder følgende komponenter:
depotet som er grunnlaget for CASE-verktøyet. Det skal gi lagring av versjoner av prosjektet og dets individuelle komponenter, synkronisering av informasjonsflyt fra ulike utviklere under gruppeutvikling, kontroll av metadata for fullstendighet og konsistens;
grafiske verktøy for analyse og design, som gir opprettelse og redigering av hierarkisk relaterte diagrammer (DFD, ERD, etc.) som danner IS-modeller;
applikasjonsutviklingsverktøy inkludert 4GL-språk og kodegeneratorer;
verktøy for konfigurasjon;
dokumentasjonsverktøy;
testing verktøy;
prosjektledelsesverktøy;
rekonstruksjonsverktøy.
anvendte metoder og modeller for systemer og databaser;
graden av integrasjon med DBMS;
tilgjengelige plattformer.
analyseverktøy (Upper CASE), designet for å bygge og analysere domenemodeller (Design / IDEF (Meta Software), BPWin (Logic Works));
analyse- og designverktøy (Middle CASE) som støtter de vanligste designmetodikkene og brukes til å lage designspesifikasjoner (Vantage Team Builder (Cayenne), Designer / 2000 (Oracle), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE. Analytiker (Makro- Prosjekt)). Resultatet av slike verktøy er spesifikasjonen av systemkomponenter og grensesnitt, systemarkitektur, algoritmer og datastrukturer;
verktøy for databasedesign, tilby datamodellering og generering av databaseskjemaer (vanligvis i SQL-språket) for de vanligste DBMS. Disse inkluderer ERwin (Logic Works). S-Designor (SDP) og DataBase Designer (Oracle). Databasedesignverktøy er også tilgjengelig som en del av verktøyene Vantage Team Builder, Designer / 2000, Silverrun og PRO-IV CASE;
applikasjonsutviklingsverktøy. Disse inkluderer 4GL-verktøy (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer / 2000 (Oracle), New Era (Informix), SQL Windows (Gupta), Delphi (Borland), etc.) og generatorkoder inkludert i Vantage Team Builder, PRO-IV og delvis i Silverrun;
rekonstruksjonsverktøy, gi analyse av programkoder og databaseskjemaer og dannelse på grunnlag av ulike modeller og designspesifikasjoner. Databaseskjemaanalyse og ERD-genereringsverktøy er inkludert i Vantage Team Builder, PRO-IV, Silverrun, Designer / 2000, ERwin og S-Designor. Innen programkodeanalyse er objektorienterte CASE-verktøy som gir reengineering av C++-programmer (Rational Rose (Rational Software), Object Team (Cayenne)) mest brukt. Hjelpetyper inkluderer:
planleggings- og prosjektstyringsverktøy (SE Companion, Microsoft Project, etc.);
verktøy for konfigurasjonsadministrasjon (PVCS (Intersolv));
testverktøy (Quality Works (Segue Software));
dokumentasjonsverktøy (SoDA (Rational Software)).
Silverrun;
Designer / 2000;
Vantage Team Builder (Westmount I-CASE);
ERwin + BPwin;
S-designer;
CASE-analytiker.
La oss karakterisere hovedfunksjonene til CASE-verktøy ved å bruke eksemplet med det mye brukte Silverrun-systemet.
CASE-verktøyet Silverrun fra det amerikanske selskapet Computer Systems Advisers, Inc. (CSA) brukes til analyse og design av forretningsklasse IS og er mer fokusert på spirallivssyklusmodellen. Den er anvendelig for å støtte enhver metodikk basert på den separate konstruksjonen av funksjons- og informasjonsmodeller (dataflytdiagrammer og entitetsforholdsdiagrammer).
Tilpasning for en spesifikk metodikk er gitt ved å velge den nødvendige grafiske modellnotasjonen og et sett med regler for kontroll av designspesifikasjoner. Systemet har ferdige innstillinger for de vanligste metodikkene: DATARUN (grunnleggende metodikk støttet av Silverrun), Gane / Sarson, Yourdon / DeMarco, Merise, Ward / Mellor, Information Engineering. For hvert konsept introdusert i prosjektet er det mulig å legge til egne deskriptorer. Silverrun-arkitekturen lar deg utvide utviklingsmiljøet ditt etter behov.
Silverrun har en modulær struktur og består av fire moduler, som hver er et frittstående produkt og kan kjøpes og brukes uten kobling til de andre. moduler.
Modul bygge modeller for forretningsprosesser i form av dataflytdiagrammer (BPM - Business Process Modeler) lar deg simulere funksjonen til den undersøkte organisasjonen eller den opprettede IS. BPM-modulen gir muligheten til å arbeide med modeller med stor kompleksitet: automatisk omnummerering, arbeid med prosesstreet (inkludert visuell draing av grener), løsne og feste deler av modellen for kollektiv utvikling. Diagrammer kan gjengis i flere forhåndsdefinerte notasjoner, inkludert Yourdon / DeMarco og Gane / Sarson. Det er også mulig å lage dine egne notasjoner, inkludert å legge til brukerdefinerte felt til antall deskriptorer som vises på skjemaet.
Modul konseptuell datamodellering(ERX - Entity-Relationship eXpert) gir konstruksjonen av enhetsrelasjonsdatamodeller som ikke er knyttet til en spesifikk implementering. Denne modulen har et innebygd ekspertsystem som lar deg lage en korrekt normalisert datamodell ved å svare på meningsfulle spørsmål om forholdet mellom data. Det er mulig å automatisk bygge en datamodell fra beskrivelser av datastrukturer. Analysen av funksjonelle avhengigheter av attributter gjør det mulig å kontrollere modellens samsvar med kravene i den tredje normale formen og sikre at de oppfylles. Den verifiserte modellen overføres til RDM-modulen.
Modul relasjonsmodellering(RDM står for Relational Data Modeler) lar deg lage detaljerte enheter-relasjonsmodeller for implementering i en relasjonsdatabase. Denne modulen dokumenterer alle konstruksjonene knyttet til å bygge en database: indekser, utløsere, lagrede prosedyrer, etc. Fleksibel utskiftbar notasjon og utvidbarhet av depotet lar deg jobbe i henhold til hvilken som helst metodikk. Muligheten til å lage underkretser følger ANSI SPARC-tilnærmingen til å representere et databaseskjema. På språket til underkretser er både distribuerte prosesseringsnoder og brukerrepresentasjoner modellert. Denne modulen gir design og komplett dokumentasjon av relasjonsdatabaser.
^ Depotsjef arbeidsgruppe (WRM - Workgroup Repository Manager) brukes som en dataordbok for lagring av informasjon som er felles for alle modeller, og gir også integrering av Silverrun-moduler i ett enkelt designmiljø.
Prisen for høy fleksibilitet og variasjon av visuelle modelleringsverktøy er en så ulempe ved Silverrun som mangelen på streng gjensidig kontroll mellom komponentene i forskjellige modeller (for eksempel muligheten til å automatisk forplante endringer mellom DFD-er med forskjellige dekomponeringsnivåer). Det skal imidlertid bemerkes at denne ulempen kan være av vesentlig betydning bare ved bruk av kaskademodellen for livssyklusen til IS.
For automatisk generering av databaseskjemaer har Silverrun broer til de vanligste DBMSene: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. For å overføre data til applikasjonsutviklingsverktøy finnes det broer til 4GL-språkene: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Alle broer lar deg laste inn informasjon i Silverrun RDM fra katalogene til de tilsvarende DBMS- eller 4GL-språkene. Dette gjør at eksisterende databaser og applikasjonssystemer kan dokumenteres, redesignes eller porteres til nye plattformer. Når du bruker en bro, utvider Silverrun sitt interne depot med målspesifikke attributter. Etter å ha bestemt verdiene til disse attributtene, overfører applikasjonsgeneratoren dem til den interne katalogen til utviklingsmiljøet eller bruker dem når de genererer SQL-kode. Dermed er det mulig å definere databasemotoren fullt ut ved å bruke alle egenskapene til en spesifikk DBMS: utløsere, lagrede prosedyrer,r. Når du oppretter en applikasjon i 4GL, brukes dataene som overføres fra Silverrun-depotet enten til å generere grensesnittobjekter automatisk eller for å raskt lage dem manuelt.
For å utveksle data med andre designautomatiseringsverktøy, lage spesialiserte prosedyrer for å analysere og sjekke designspesifikasjoner og kompilere spesialiserte rapporter i henhold til ulike standarder i Silverrun-systemet, er det tre måter å utstede designinformasjon til eksterne filer:
rapporteringssystem. Det er mulig, etter å ha definert innholdet i depotrapporten, å sende rapporten til en tekstfil. Denne filen kan deretter lastes inn i et tekstredigeringsprogram eller inkluderes i en annen rapport;
eksport / import system. For mer fullstendig kontroll over strukturen til filer i eksport-/importsystemet, er det mulig å bestemme ikke bare innholdet i eksportfilen, men også skilletegnene til poster, felt i poster, markører for begynnelsen og slutten av tekstfelt . Filer med den angitte strukturen kan ikke bare genereres, men også lastes opp til depotene. Dette gjør det mulig å utveksle data med ulike systemer: andre CASE-verktøy, DBMS, tekstredigerere og regneark;
lagring av depotet i eksterne filer via ODBC-drivere. For å få tilgang til depotdataene fra de vanligste databasestyringssystemene, er det mulig å lagre all prosjektinformasjon direkte i formatet til disse DBMSene.
standard enkeltbrukerversjonen har en mekanisme for kontrollert modelloppdeling og sammenslåing. Ved å dele opp modellen i deler kan du distribuere dem til flere utviklere. Etter detaljert revisjon er modellene kombinert til én enkelt spesifikasjon;
nettverksversjonen av Silverrun tillater engangsgruppearbeid med modeller lagret i et nettverkslager basert på Oracle, Sybase eller Informix DBMS. I dette tilfellet kan flere utviklere jobbe med samme modell, siden objekter er låst på nivået til individuelle modellelementer.
I tillegg til Silverrun-systemet vil vi angi formålet med andre populære CASE-verktøy og deres grupper.
Vantage Team Builder er et integrert programvareprodukt fokusert på implementeringen av fossefallmodellen for IS-livssyklusen og støtte for hele IS-livssyklusen.
Uniface 6.1 - et produkt fra Compuware (USA) - er et utviklingsmiljø for store applikasjoner i "klient-server"-arkitekturen.
CASE-tool Designer / 2000 2.0 fra Oracle er et integrert CASE-verktøy som sammen med Developer / 2000 applikasjonsutviklingsverktøyene gir støtte for et fullstendig livssyklusinformasjonssystem for systemer som bruker Oracle DBMS.
CASE / 4/0-pakken (microTOOL GmbH), som inkluderer strukturelle verktøy for systemanalyse, design og programmering, gir støtte for hele utviklingslivssyklusen (opp til vedlikehold), basert på et nettverkslager som kontrollerer integriteten til prosjektet og støtter det koordinerte arbeidet til alle deltakerne (systemanalytikere, designere, programmerere).
^
Lokale midler
ERWin-pakken (Logic Works) brukes til å modellere og lage databaser med vilkårlig kompleksitet basert på entitetsforholdsdiagrammer. For øyeblikket er ERWin den mest populære datamodelleringspakken på grunn av støtte fra et bredt spekter av DBMS av forskjellige klasser - SQL-servere (Oracle, Informix, Sybase SQL Server, MS SQL Server, Progress, DB2, SQLBase, Ingress, Rdb, etc. .) og "desktop" DBMS som xBase (Clipper, dBase, FoxPro, MS Access, Paradox, etc.).
BPWin er et funksjonelt modelleringsverktøy som implementerer IDEFO-metodikken. En BPWin-modell er en samling av SADT-diagrammer, som hver beskriver en egen prosess, deler den ned i trinn og underprosesser.
S-Designer 4.2 (Sybase / Powersoft) er et CASE-verktøy for utforming av relasjonsdatabaser. Når det gjelder funksjonalitet og kostnad, er den nær ERWin CASE-verktøyet, og skiller seg ut i den utad brukte notasjonen i diagrammer. S-Designer implementerer en standard datamodelleringsmetodikk og genererer en databasebeskrivelse for slike DBMS som Oracle, Informix, Ingres, Sybase, DB2, Microsoft SQL Server, etc.
CASE-Analyst 1.1 (Eytex) er praktisk talt det eneste konkurransedyktige innenlandske CASE-verktøyet for funksjonell modellering og implementerer konstruksjonen av dataflytdiagrammer i samsvar med den tidligere beskrevne metodikken.
^
Objektorienterte CASE-verktøy
Rational Rose - et CASE-verktøy fra Rational Software Corporation (USA) - er designet for å automatisere stadier av analyse og design av IS, samt å generere koder på forskjellige språk og frigi designdokumentasjon. Rational Rose bruker en syntesemetodikk for objektorientert analyse og design, basert på tilnærmingene til tre ledende eksperter på feltet: Booch, Rambeau og Jacobson. Den universelle notasjonen for objektmodellering (UML - Unified Modeling Language) utviklet av dem er nå og vil åpenbart forbli i fremtiden en generelt akseptert standard innen objektorientert analyse og design. Den spesifikke varianten av Rational Rose bestemmes av språket som programkoden genereres på (C ++, Smalltalk, PowerBuilder, Ada, SQLWindows og ObjectPro). Hovedalternativet - Rational Rose / C ++ - lar deg utvikle prosjektdokumentasjon i form av diagrammer og spesifikasjoner, samt generere programkoder i C ++. I tillegg inkluderer Rational Rose programvarerekonstruksjonsverktøy for å muliggjøre gjenbruk av programvarekomponenter i nye prosjekter.
^
Konfigurasjonsadministrasjonsverktøy
Formålet med konfigurasjonsstyring (CM) er å sikre kontrollerbarhet og kontrollerbarhet av prosessene for utvikling og vedlikehold av IS. Dette krever nøyaktig og pålitelig informasjon om tilstanden til IS og dens komponenter til enhver tid, samt om alle forventede og utførte endringer.
For å løse CG-problemer, brukes metoder og midler som gir identifikasjon av komponentenes tilstand, redegjør for nomenklaturen til alle komponenter og modifikasjoner av systemet som helhet, kontroll over endringer som er gjort i komponenter, strukturen til systemet og dets funksjoner. , samt koordinert styring av utvikling av funksjoner og forbedring av egenskaper.
Det vanligste CU-verktøyet er PVCS fra Intersolv (USA), som inkluderer en rekke frittstående produkter: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder og PVCS Notify.
^
Dokumentasjonsverktøy
For å lage dokumentasjon i prosessen med AIS-utvikling brukes en rekke rapporteringsverktøy, samt komponenter i publiseringssystemer. Vanligvis er dokumentasjonsverktøy innebygd i spesifikke CASE-verktøy. Unntakene er noen pakker som gir ytterligere dokumentasjonstjenester. Av disse er SoDA (Software Document Automation) den mest aktivt brukte.
SoDA-produktet er designet for å automatisere utviklingen av prosjektdokumentasjon i alle faser av IS-livssyklusen. Den lar deg automatisk trekke ut en rekke informasjon innhentet på forskjellige stadier av prosjektutviklingen og inkludere den i utdataene. Samtidig overvåkes dokumentasjonens samsvar med prosjektet, forholdet mellom dokumenter er sikret, deres rettidig oppdatering er sikret. Den resulterende dokumentasjonen genereres automatisk fra en rekke kilder, hvor antallet ikke er begrenset.
Pakken inkluderer en grafisk editor for å utarbeide dokumentmaler. Den lar deg angi den nødvendige stilen, bakgrunnen, fonten, bestemme plasseringen av overskrifter, reservere steder hvor informasjon hentet fra forskjellige kilder vil bli plassert. Endringer gjøres automatisk kun i de delene av dokumentasjonen som de berørte i programmet. Dette reduserer tiden som kreves for å utarbeide dokumentasjon ved å eliminere behovet for å regenerere all dokumentasjon.
SoDA er basert på publiseringssystemet FrameBuilder og gir et komplett sett med verktøy for redigering og layout av publisert dokumentasjon.
Det endelige resultatet av SoDA-systemet er et ferdig dokument (eller bok). Dokumentet kan lagres i en fil i SoDA-format (Frame Builder), som er hentet som et resultat av dokumentgenerering. Utskrift av dette dokumentet (eller deler av det) er mulig fra SoDA-systemet.
SoDA-operativmiljøet er et UNIX-type OS på Sun SPARCstation, IBM RISC System / 6000 eller Hewlett Packard HP 9000 700/800 arbeidsstasjoner.
^
Testverktøy
Testing er prosessen med å kjøre et program for å oppdage feil. Regresjonstesting er testing utført etter å ha forbedret funksjonene til et program eller gjort endringer i det.
Et av de mest avanserte QA-testverktøyene (nytt navn - Quality Works) er et integrert multiplattformmiljø for utvikling av automatiserte tester på alle nivåer, inkludert regresjonstester for GUI-applikasjoner.
QA lar deg begynne å teste i alle faser av livssyklusen, planlegge og administrere testprosessen, vise endringer i applikasjonen og gjenbruke tester for mer enn 25 forskjellige plattformer.
Avslutningsvis vil vi gi et eksempel på et CASE-verktøykompleks som gir støtte for en komplett IS-livssyklus. Det er uhensiktsmessig å sammenligne separat tatt CASE-verktøy, siden ingen av dem løser generelt alle problemene med å opprette og vedlikeholde IS. Dette bekreftes også av et komplett sett med evaluerings- og utvalgskriterier som påvirker alle stadier av IS-livssyklusen. Komplekser av metodisk og teknologisk avtalte verktøy kan sammenlignes som støtter en fullstendig livssyklus av IS og som er utstyrt med nødvendig teknisk og metodisk støtte fra leverandørbedriftene (merk at rasjonell integrasjon av verktøy for utvikling av IS er den viktigste betingelse for å sikre kvaliteten på denne IS, og denne bemerkningen gjelder for alle fagområder).
Forelesning nummer 8
Lagdelt arkitektur 9
Internett / Intranett-teknologier 10
Krav til informasjonssystemer 10
Fleksibilitet 11
Pålitelighet 11
Effektivitet 11
Sikkerhet 12
Livssyklusen til informasjonssystemene 16
Oversikt over prosjektledelse 17
^ Klassifisering av prosjekter 18
Hovedfaser av informasjonssystemdesign 18
Konseptfase 19
Utarbeidelse av teknisk forslag 19
Design 19
Utvikling 20
Sette systemet i drift 20
Prosesser gjennom hele livssyklusen til et informasjonssystem 21
^ Grunnleggende livssyklusprosesser 21
Utvikling 21
Operasjon 21
Eskorte 22
Støtte livssyklusprosesser 23
Organisasjonsprosesser 23
Strukturen til livssyklusen til et informasjonssystem 23
Innledende fase 24
Foredlingsstadium 24
^ Byggetrinn 24
Overleveringsfase 24
Livssyklusen til informasjonssystemene 28
Info28
^ Informasjonssystem livssyklus fossefall modell 29
De viktigste utviklingstrinnene for fossefallsmodellen 29
Hovedfordelene med kaskademodellen 29
Ulemper med kaskademodellen 30
^ Spiral livssyklus modell 31
Iterasjon 31
Fordeler med spiralmodellen 32
Ulemper med spiralmodellen 33
Metodikk og teknologi for utvikling av informasjonssystemer 37
RAD 40-metodikk
Nøkkeltrekk ved RAD 40-metodikken
^ Objektorientert tilnærming 41
Visuell programmering 42
Eventprogrammering 43
Livssyklusfaser innenfor RAD 44-metodikken
Kravanalyse og planleggingsfase 44
Designfase 44
Byggefase 45
Implementeringsfase 46
^ Begrensninger for RAD 46-metodikken
Metodikk og teknologi for utvikling av informasjonssystemer 51
Åpne informasjonssystemprofiler 51
Konseptet med en informasjonssystemprofil 52
Prinsipper for å danne en informasjonssystemprofil 53
^ Strukturen til informasjonssystemprofiler 55
Programvareprofil 57
Informasjonssystemmiljøprofil 57
Informasjonssikkerhetsprofil 58
Verktøyprofil 58
^ Metodikk og teknologi for utvikling av informasjonssystemer 63
Standarder og praksis 63
Typer standarder 64
Oracles CDM 65
Generell struktur 66
Funksjoner ved CDM 68-metoden
^ Internasjonal standard ISO / IEC 12207: 1995-08-01 69
Generell struktur 69
Grunnleggende og hjelpeprosesser i livssyklusen 69
Funksjoner i ISO 12207 71
CASE-teknologier for utforming av informasjonssystemer 77
Kjennetegn på moderne CASE-verktøy 80
^ Lokale verktøy 86
Objektorienterte CASE-verktøy 87
Konfigurasjonsadministrasjonsverktøy 87
Dokumentasjonsverktøy 87
Testverktøy 88
Prinsipper for konstruksjon og designstadier av databaser 93
Grunnleggende begreper og definisjoner 93
Beskrivende domenemodell 99
^ Prinsipper for konstruksjon og stadier av databasedesign 111
Konseptuelle datamodeller 111
Datastrukturtyper 112
Dataoperasjoner 113
^ Integritetsbegrensninger 114
Hierarkisk datamodell 115
Nettverksdatamodell 117
Relasjonsdatamodell 118
Binær datamodell 119
Semantisk web 119
Informa124
Systemmodelleringsteknikker 124
^ Matematisk modell av systemet 126
Klassifisering av matematiske modeller 128
Simuleringsmodeller av informasjonssystemer 136
Metodisk grunnlag for anvendelse av simuleringsmetoden 136
^ Simuleringsmodeller av informasjonssystemer 146
Klassifisering av simuleringsmodeller 146
Struktur av en typisk simuleringsmodell med hendelseskalender 153
^ Simuleringsmodeller av informasjonssystemer 161
Random Factor Modeling Technology 161
Generering av pseudo-tilfeldig tall (PRN) 161
Multiplikativ metode 163
Additiv metode 164
Blandet metode 164
^ Modellering av tilfeldige hendelser 165
Sekvensiell simulering 167
Simulering etter foreløpige beregninger 167
Simuleringsmodeller av informasjonssystemer 172
Random Factor Modeling Technology 172
^ Simulering av tilfeldige variabler 172
Modellering av kontinuerlige tilfeldige variabler 173
Invers funksjonsmetode 173
Elimineringsmetode (Neumann) 174
Sammensetningsmetode 176
Modellering av diskrete tilfeldige variabler 177
Metoden for suksessive sammenligninger 177
Tolkningsmetode 178
^ Modellering av tilfeldige vektorer 178
Betinget distribusjonsmetode 179
Elimineringsmetode (Neumann) 180
Lineær transformasjonsmetode 181
Simuleringsmodeller av informasjonssystemer 187
Grunnleggende om organisering av simulering 187
^ Simuleringstrinn 187
Simuleringsmodelltest 188
Innstilling av innledende informasjon 189
Simuleringsmodellverifisering 189
Kontrollerer tilstrekkeligheten til modellen 189
Kalibrerer Simulator 190
Undersøkelse av egenskapene til simuleringsmodellen 190
Estimering av simuleringsfeil knyttet til bruk av pseudo-tilfeldige tallgeneratorer (PRN) i modellen 190
Bestemme varigheten av transienten 191
Evaluering av robustheten til simuleringsresultater 192
Undersøkelse av sensitiviteten til 192-modellen
^
Modelleringsspråk 193
Kjennetegn ved moderne operativsystemer
Strukturen og mulighetene til operativsystemer utvikler seg år etter år. Nylig har nye operativsystemer og nye versjoner av eksisterende operativsystemer inkludert noen strukturelle elementer som har gjort store endringer i disse systemenes natur. Moderne operativsystemer oppfyller kravene til maskinvare og programvare i stadig utvikling. De er i stand til å kontrollere driften av multiprosessorsystemer som kjører raskere enn konvensjonelle maskiner, høyhastighets nettverksenheter og en rekke lagringsenheter, hvor antallet øker stadig. Blant applikasjonene som har påvirket utformingen av operativsystemer, er det verdt å merke seg multimediaapplikasjoner, Internett-tilgangsfasiliteter og klient-/servermodellen.
Den nådeløse økningen i kravene til operativsystemer fører ikke bare til bedre arkitektur, men også til fremveksten av nye måter å organisere dem på. Et bredt utvalg av tilnærminger og byggeklosser har blitt prøvd i eksperimentelle og kommersielle operativsystemer, hvorav de fleste kan grupperes i følgende kategorier.
· Mikrokjernearkitektur.
· Multithreading.
· Symmetrisk multiprosessering.
· Distribuerte operativsystemer.
· Objektorientert design.
Et særtrekk ved de fleste operativsystemer i dag er en stor monolittisk kjerne. Operativsystemkjernen gir de fleste av sine muligheter, inkludert planlegging, filsystemhåndtering, nettverk, enhetsdrivere, minneadministrasjon og mange andre. Vanligvis er en monolitisk kjerne implementert som en enkelt prosess, hvis elementer bruker samme adresserom. I en mikrokjernearkitektur har kjernen bare noen få av de viktigste funksjonene, inkludert adresserom, interprosesskommunikasjon (IPC) og grunnleggende planlegging. Andre operativsystemtjenester drives av prosesser som noen ganger refereres til som servere. Disse prosessene startes i brukermodus og mikrokjernen jobber med dem på samme måte som med andre applikasjoner. Denne tilnærmingen skiller oppgaven med operativsystemutvikling i kjerneutvikling og serverutvikling. Servere kan konfigureres for å møte kravene til spesifikke applikasjoner eller miljøer. Å tildele en mikrokjerne i strukturen til systemet forenkler implementeringen av systemet, gir dets fleksibilitet og passer også godt inn i et distribuert miljø. Faktisk samhandler mikrokjernen med de lokale og eksterne serverne på samme måte, noe som forenkler konstruksjonen av distribuerte systemer.
Multithreading er en teknologi der en prosess som kjører en applikasjon er delt opp i flere samtidig kjørende tråder. Følgende er hovedforskjellene mellom tråd og prosess.
· Strømme. En utsendt arbeidsenhet som inkluderer en prosessorkontekst (som inkluderer innholdet i programtelleren og toppen av stabelpekeren) og sitt eget stabelområde (for organisering av subrutineanrop og lagring av lokale data). Stream-kommandoer utføres sekvensielt; tråd kan avbrytes når prosessoren går over til å behandle en annen tråd 4. Prosess. En samling av en eller flere tråder, samt systemressursene knyttet til disse trådene (for eksempel et minneområde som inneholder kode og data, åpne filer, ulike enheter). Dette konseptet er veldig nært konseptet med et løpende program. Ved å dele opp applikasjonen i flere tråder, drar programmereren full nytte av applikasjonens modularitet og muligheten til å administrere applikasjonsrelaterte timinghendelser.
Multithreading viser seg å være veldig nyttig for applikasjoner som kjører flere uavhengige oppgaver som ikke krever sekvensiell kjøring. Et eksempel på en slik applikasjon er en databaseserver som samtidig aksepterer og behandler flere klientforespørsler. Hvis flere tråder behandles i samme prosess, vil bytte mellom ulike tråder ha mindre CPU-overhead enn å bytte mellom ulike prosesser. I tillegg er tråder nyttige for å strukturere prosesser som er en del av operativsystemkjernen, beskrevet i senere kapitler.
Inntil nylig inneholdt alle en-bruker personlige datamaskiner og arbeidsstasjoner en enkelt generell virtuell mikroprosessor. Som et resultat av de stadig økende kravene til ytelse og senking av kostnadene til mikroprosessorer, har produsentene gått over til multiprosessordatamaskiner. For å forbedre effektiviteten og påliteligheten brukes symmetrisk multiprosesseringsteknologi (SMP). Dette begrepet refererer til maskinvarearkitekturen til en datamaskin, så vel som operativsystemets oppførsel som samsvarer med den arkitektoniske funksjonen. Symmetrisk multiprosessering kan defineres som et frittstående datasystem med følgende egenskaper.
1. Systemet har flere prosessorer.
2. Disse prosessorene, sammenkoblet av en kommunikasjonsbuss eller andre kretser, deler det samme hovedminnet og de samme I/O-enhetene.
3. Alle prosessorer kan utføre de samme funksjonene (derav navnet symmetrisk prosessering).
Et operativsystem som kjører på et symmetrisk multiprosessorsystem distribuerer prosesser eller tråder på tvers av alle prosessorer. Multiprosessorsystemer har flere potensielle fordeler fremfor enprosessorsystemer, inkludert følgende.
· Opptreden... Hvis en jobb som skal utføres av en datamaskin kan organiseres slik at deler av jobben utføres parallelt, vil dette resultere i forbedret ytelse i forhold til et enprosessorsystem med samme type prosessor. Utsagnet ovenfor er illustrert i fig. 2.12. I fleroppgavemodus kan bare én prosess kjøres samtidig, mens resten av prosessene blir tvunget til å vente på tur. I et multiprosessorsystem kan flere prosesser kjøres samtidig, hver av dem kjører på en separat prosessor.
· Pålitelighet. Ved symmetrisk multiprosessering vil en feil på en av prosessorene ikke få maskinen til å stoppe, fordi alle prosessorer kan utføre de samme funksjonene. Etter en slik feil vil systemet fortsette å fungere, selv om ytelsen vil avta litt.
· Bygge opp... Ved å legge til flere prosessorer til systemet, kan brukeren forbedre ytelsen.
· Skalerbarhet. Produsenter kan tilby produktene sine i ulike konfigurasjoner som varierer i pris og ytelse, designet for å fungere med forskjellige antall prosessorer.
Det er viktig å merke seg at fordelene ovenfor er potensielle i stedet for garanterte. For å virkelig realisere potensialet som ligger i multiprosessordatabehandling, må operativsystemet gi et tilstrekkelig sett med verktøy og muligheter.
Ris. 2.12. Multitasking og multiprosessering
Du kan ofte komme over en felles diskusjon om multithreading og multiprosessering, men de to konseptene er uavhengige. Multithreading er et nyttig konsept for å strukturere applikasjons- og kjerneprosesser, selv på en enkelt prosessormaskin. På den annen side kan et multiprosessorsystem ha fordeler fremfor et enprosessorsystem, selv om prosessene ikke er delt opp i flere tråder, fordi et slikt system kan kjøre flere prosesser samtidig. Begge disse mulighetene er imidlertid i god overensstemmelse med hverandre, og deres kombinerte bruk kan gi en merkbar effekt.
Et fristende trekk ved multiprosessorsystemer er at tilstedeværelsen av flere prosessorer er transparent for brukeren - operativsystemet er ansvarlig for å distribuere tråder mellom prosessorer og synkronisere ulike prosesser. Denne boken diskuterer planleggings- og synkroniseringsmekanismene som brukes for å sikre at alle prosesser og prosessorer er synlige for brukeren som et enkelt system. En annen oppgave på høyere nivå er å representere en klynge av flere separate datamaskiner som et enkelt system. I dette tilfellet har vi å gjøre med et sett med datamaskiner, som hver har sitt eget primære og sekundære minne og sine egne I/O-moduler. Et distribuert operativsystem skaper utseendet til en enkelt plass for primær og sekundær lagring, så vel som et enkelt filsystem. Selv om populariteten til klynger vokser jevnt og trutt og flere og flere klyngeprodukter dukker opp på markedet, ligger moderne distribuerte operativsystemer fortsatt etter enkelt- og multiprosessorsystemer. Du vil bli kjent med slike systemer i bokens sjette del.
En av de siste nyvinningene i utformingen av operativsystemer er bruken av objektorienterte teknologier. Objektorientert design hjelper til med å rydde opp i prosessen med å legge til tilleggsmoduler til den lille hovedkjernen. På operativsystemnivå lar en objektorientert struktur programmerere tilpasse operativsystemet uten å gå på akkord med dets integritet. I tillegg letter denne tilnærmingen utviklingen av distribuerte verktøy og fullverdige distribuerte operativsystemer.
2.2 Utvikling av en konseptuell modell av informasjonssystemet.
Den konseptuelle modellen representerer objekter og deres relasjoner uten å spesifisere hvordan de fysisk lagres. Dermed er den konseptuelle modellen i hovedsak en domenemodell. Når du designer en konseptuell modell, bør dataene struktureres og relasjonene mellom dem bør identifiseres uten å ta hensyn til implementeringsfunksjonene og effektivitetsproblemer.
behandling. Utformingen av den konseptuelle modellen er basert på analysen av oppgavene reklamebyrået står overfor. Den konseptuelle modellen inkluderer beskrivelser av objekter og deres innbyrdes relasjoner som er av interesse i det betraktede fagområdet og som identifiseres som et resultat av dataanalyse.
For å bygge modellen vi trenger, brakte vi alle tilgjengelige data til tredje normal form, som et resultat av at vi fikk følgende enheter:
· Typer retter.
· Ansatte.
· Stillinger.
· Faste kunder.
· Ordrene.
Vi bygger modellen på det logiske nivået (se fig. 2). Figur 2 viser at modellen har lenker. La oss vurdere dem mer detaljert:
Tabell "Typer av retter" og tabell "Servis" - etablert et forhold "en-til-mange" ved å bruke primærnøkkelen "Type kode";
"Posisjons"-tabellen og "Personell"-tabellen - en en-til-mange-relasjon ble etablert ved å bruke "Position Code" primærnøkkelen;
Tabell "Servis" og tabell "Bestillinger" - en en-til-mange-relasjon ble etablert ved å bruke primærnøkkelen "Dish ID";
Tabell "Personal" og tabell "Ordre" - en en-til-mange-relasjon ble etablert ved å bruke primærnøkkelen "Ansatt-ID";
Lojale kunder-tabell og ordretabell — En en-til-mange-relasjon ble etablert ved å bruke kunde-ID-primærnøkkelen.
Ris. 2. Konseptuell datamodell
2.3 Utvikling av en logisk modell av informasjonssystemet
Databaser og programvare for deres opprettelse og vedlikehold (DBMS) har en flerlagsarkitektur, en ide om denne kan fås fra figur 1.
Skjema 1 - Multilevel presentasjon av databasedata under
DBMS-administrasjon
Skille mellom konseptuelle, interne og eksterne nivåer av representasjon av disse databasene, som tilsvarer modeller med lignende formål.
Det konseptuelle nivået tilsvarer det logiske aspektet ved å presentere domenedata på en integrert måte. Den konseptuelle modellen består av mange forekomster av ulike typer data, strukturert i samsvar med kravene til DBMS for den logiske strukturen til databasen.
Det indre laget gjenspeiler den nødvendige organiseringen av data i lagringsmediet og tilsvarer det fysiske aspektet ved datapresentasjon. Den interne modellen består av individuelle journalforekomster fysisk lagret i eksterne medier.
Det ytre laget støtter de private visningene av dataene som kreves av spesifikke brukere. Den eksterne modellen er en undergruppe av den konseptuelle modellen. Skjæring av eksterne datamodeller er mulig. En privat logisk datastruktur for en individuell applikasjon (oppgave) eller bruker tilsvarer en ekstern databasemodell eller underskjema. Ved å bruke eksterne modeller støttes autorisert tilgang til applikasjonsdatabasedata (sammensetningen og strukturen til dataene til den konseptuelle databasemodellen som er tilgjengelig i applikasjonen er begrenset, så vel som de tillatte modusene for behandling av disse dataene er satt: inndata, redigering, sletting , Søk).
Databasedesign består i å bygge et kompleks av sammenhengende data. Figur 2 viser stadiene i databasedesignprosessen.
Figur 2 - Trinn i databasedesignprosessen
Det viktigste stadiet i utformingen av en database er utviklingen av en informasjonslogisk (infologisk) modell av domenet, ikke orientert mot DBMS. I en infologisk modell er datastrukturer integrert i en integrert form som gjenspeiler sammensetningen og strukturen til data, samt informasjonsbehov.
Den informasjonslogiske (infologiske) modellen for fagområdet reflekterer fagområdet i form av et sett med informasjonsobjekter og deres strukturelle koblinger.
I en en-til-mange-relasjon (1:M) tilsvarer én forekomst av informasjon A 0, 1 eller flere forekomster av objekt B, men hver forekomst av objekt B er assosiert med maksimalt én forekomst av objekt A.
Et eksempel på relasjon 1: M er en relasjon mellom informasjonsobjekter Etternavn - Lønn:
Etternavn Lønn
I databasen lagres informasjon i form av todimensjonale tabeller. Du kan også importere og koble tabeller fra andre DBMS- eller regnearksystemer. 1024 bord kan åpnes samtidig.
Når du definerer de nødvendige databasetabellene, er det nødvendig å oppgi de tre første normalformene, dvs. gjennomføre normalisering.
De samme dataene kan grupperes i tabeller (relasjoner) på forskjellige måter, dvs. organisering av ulike sett med relasjoner av sammenkoblede informasjonsobjekter er mulig. Grupperingen av attributter i relasjoner bør være rasjonell, dvs. minimere dataduplisering og forenkle prosedyrer for behandling og oppdatering av dem.
Et visst sett med relasjoner har bedre egenskaper når det inkluderer, modifiserer, sletter data enn alle andre mulige sett med relasjoner hvis det oppfyller kravene for normalisering av relasjoner.
Normalisering av relasjoner er et formelt apparat med restriksjoner på dannelsen av relasjoner (tabeller), som eliminerer duplisering, sikrer konsistensen til de som er lagret i databasen, og reduserer arbeidskostnadene for å vedlikeholde (inngå, korrigere) databasen.
E. Codd identifiserte tre normale former for relasjoner og foreslo en mekanisme som gjør at enhver relasjon kan transformeres til den tredje (mest perfekte) normale formen.
Første normalform. En relasjon kalles normalisert eller redusert til første normalform hvis alle dens attributter er enkle (heretter udelelige). Konvertering av en relasjon til første normalform kan føre til en økning i antall attributter (felt) til relasjonen og en endring i nøkkelen.
Andre normalform. For å vurdere spørsmålet om å bringe relasjoner til den andre normale formen, er det nødvendig å gi forklaringer til slike begreper som funksjonell avhengighet og fullstendig funksjonell avhengighet.
De beskrivende detaljene til informasjonsobjektet er logisk forbundet med en felles nøkkel for dem, denne forbindelsen har karakter av detaljenes funksjonelle avhengighet.
Funksjonell avhengighet av attributter er en avhengighet der bare én verdi av et beskrivende attributt tilsvarer en viss verdi av et nøkkelattributt i en forekomst av et informasjonsobjekt.
En slik definisjon av funksjonell avhengighet tillater oss å skille ut uavhengige informasjonsobjekter når vi analyserer alle sammenkoblingene av rekvisita til fagområdet. Som et eksempel kan du vurdere en grafisk representasjon av de funksjonelle avhengighetene til medarbeiderdetaljer vist i figur 5, der nøkkelattributtet er indikert med en stjerne.
Figur 1 - Grafisk representasjon av detaljenes funksjonelle avhengighet
Når det gjelder en sammensatt nøkkel, introduseres begrepet en funksjonelt fullstendig avhengighet.
Den funksjonelt fullstendige avhengigheten av ikke-nøkkelattributter er at hvert ikke-nøkkelattributt er funksjonelt avhengig av nøkkelen, men ikke funksjonelt avhengig av noen del av den sammensatte nøkkelen.
Et forhold vil være i andre normalform hvis det er i første normalform, og hvert ikke-nøkkelattributt er funksjonelt avhengig av den sammensatte nøkkelen.
Tredje normalform. Begrepet tredje normalform er basert på begrepet ikke-transitiv avhengighet.
Transitiv avhengighet oppstår når ett av de to beskrivende attributtene avhenger av nøkkelen, og det andre beskrivende attributtet avhenger av det første beskrivende attributtet.
Et forhold vil være i tredje normalform hvis det er i andre normalform, og hvert ikke-nøkkelattributt er ikke transitivt avhengig av primærnøkkelen.
For å eliminere den transitive avhengigheten av beskrivende attributter, er det nødvendig å "dele" det opprinnelige informasjonsobjektet. Som et resultat av splitting fjernes noen av detaljene fra det opprinnelige informasjonsobjektet og inkluderes i andre (eventuelt nyopprettede) informasjonsobjekter.
Den opprettede databasen skal utføre funksjoner for å automatisere utstedelsen av data om organisasjonen. Den skal ha et enkelt og intuitivt brukergrensesnitt og ha minimumskrav til systemet.
Målet med arbeidet er å lage en database som gir:
rask inntasting av nye data;
lagring og søk av allerede innlagte data;
utskrift av nødvendig antall personlige rapporter.
Dataene er:
Fullt navn;
Fødselsdato;
Stilling inneholdt;
Offisiell lønn;
Antall faktiske arbeidsdager per måned.
Etter å ha vurdert oppgavene definert ovenfor, kan du designe de grunnleggende databasetabellene.
For å gjøre dette bruker vi Database Desktop-verktøyene.
I dette miljøet vil vi lage alle nødvendige tabeller for den utviklede databasen. Attributtene i denne tabellen vil være:
Etternavn, Fornavn, Patronym, Adopsjonsdato, Adresse, Telefon, Skifter, Skal ikke jobbe, Sats, lønn.
CASE-verktøy for design av informasjonssystemer
I moderne forhold er kompleksiteten ved å lage informasjonssystemer veldig høy. Derfor, i utformingen av IC-er, har CASE-teknologien nå blitt mye brukt.
CASE-teknologi Er en programvarepakke som automatiserer hele den teknologiske prosessen med analyse, design, utvikling og vedlikehold av kompleks programvare.
Moderne CASE-verktøy dekker et bredt område med støtte for en rekke IC-designteknologier: fra enkle analyse- og dokumentasjonsverktøy til fullskala automasjonsverktøy som dekker hele programvarens livssyklus.
De mest tidkrevende stadiene av IS-utvikling er fasene av analyse og design, hvor CASE-verktøy sikrer høy kvalitet på tekniske løsninger og utarbeidelse av prosjektdokumentasjon. Samtidig spiller grafiske verktøy for modellering av fagområdet en viktig rolle, som lar utviklere visuelt studere eksisterende IS, gjenoppbygge det i samsvar med målene og eksisterende begrensninger.
Integrerte CASE-verktøy har følgende karakteristiske trekk:
· Sikre styring av IS-utviklingsprosessen;
· Bruk av en spesialorganisert lagring av prosjektmetadata (repository).
De integrerte CASE-verktøyene inneholder følgende komponenter:
· Grafiske analyse- og designverktøy som brukes til å beskrive og dokumentere IS;
· Applikasjonsutviklingsverktøy, inkludert programmeringsspråk og kodegeneratorer;
· Et repository som gir lagring av versjoner av prosjektet som utvikles og dets individuelle komponenter, synkronisering av informasjonsflyt fra ulike utviklere under gruppeutvikling, kontroll av metadata for fullstendighet og konsistens;
· Verktøy for å administrere IS-utviklingsprosessen;
· Dokumentasjonsmidler;
· Testverktøy;
· Reengineering verktøy som gir analyse av programkoder og databaseskjemaer og dannelse av ulike modeller og designspesifikasjoner på grunnlag av disse.
Alle moderne CASE-verktøy er delt inn i to grupper. Første gruppe organisere midler innebygd i implementeringssystemet, der alle design- og implementeringsbeslutninger er knyttet til det valgte databasestyringssystemet. Andre gruppe organisere midler uavhengig av implementeringssystemet, der alle designbeslutninger er fokusert på foreningen av de innledende stadiene av livssyklusen og dokumentasjonsmidlene. Disse verktøyene gir stor fleksibilitet i valg av implementeringsverktøy.
Hoved verdighet CASE-teknologier - støtte for kollektivt arbeid på et prosjekt på grunn av evnen til å jobbe i et lokalt nettverk, eksport og import av individuelle prosjektfragmenter mellom utviklere, organisert prosjektledelse.
Som etapper opprettelse av programvareprodukter for informasjonssystemer, kan følgende skilles:
1. Driftsmiljøet bestemmes. På dette stadiet bestemmes et sett med prosesser for IP-livssyklusen, omfanget av IP-en bestemmes, størrelsen på de støttede applikasjonene bestemmes, dvs. det er satt grenser for slike verdier som antall linjer med programkode, størrelsen på databasen, antall dataelementer, antall kontrollobjekter, etc.
2. Oppbygging av diagrammer og grafisk analyse utføres. På dette stadiet bygges diagrammer som etablerer en forbindelse med informasjonskilder og forbrukere, bestemmer prosessene for datatransformasjon og hvor de lagres.
3. Spesifikasjon og krav til systemet fastsettes (grensesnitttype, datatype, systemstruktur, kvalitet, ytelse, tekniske midler, totale kostnader osv.).
4. Datamodellering pågår; det legges inn informasjon som beskriver dataelementene i systemet og deres relasjoner.
5. Prosessene blir modellert, d.v.s. det introduseres informasjon som beskriver prosessene i systemet og deres relasjoner.
