Het gebruik van case-technologieën bij de ontwikkeling van informatiesystemen. Silverrun door Silverrun Technologies Ltd

1.3.1. Algemene vereisten voor methodologie en technologie

Methodologieën, technologieën en ontwerptools (CASE-tools) vormen de basis van elk IS-project. De methodologie wordt geïmplementeerd door middel van specifieke technologieën en hun ondersteunende normen, methodologieën en tools die de implementatie van de levenscyclusprocessen garanderen.

Ontwerptechnologie wordt gedefinieerd als een combinatie van drie componenten:

• een stapsgewijze procedure die de volgorde van technologische ontwerphandelingen bepaalt (Fig. 1.4);
• criteria en regels die worden gebruikt om de resultaten van technologische operaties te evalueren;
• notaties (grafische en tekstuele middelen) die worden gebruikt om het systeem dat wordt ontworpen te beschrijven.

Rijst. 1.4. Vertegenwoordiging van de technologische werking van design

Technologische instructies, die de hoofdinhoud van de technologie vormen, moeten bestaan ​​uit een beschrijving van de opeenvolging van technologische bewerkingen, de voorwaarden die afhangen van welke een of andere bewerking wordt uitgevoerd, en beschrijvingen van de bewerkingen zelf.

De technologie voor het ontwerpen, ontwikkelen en onderhouden van IS moet voldoen aan de volgende algemene eisen:

• de technologie moet de volledige levenscyclus van de software ondersteunen;
• de technologie moet de gegarandeerde verwezenlijking van de doelstellingen van IS-ontwikkeling garanderen met een bepaalde kwaliteit en op een bepaald tijdstip;
• de technologie moet de mogelijkheid bieden om grote projecten uit te voeren in de vorm van subsystemen (dwz de mogelijkheid om het project op te splitsen in onderdelen die zijn ontwikkeld door groepen uitvoerders van een beperkt aantal met daaropvolgende integratie van de onderdelen). De ervaring met het ontwikkelen van grote IS toont aan dat om de efficiëntie van het werk te vergroten, het nodig is om het project op te delen in afzonderlijke subsystemen die zwak met elkaar verbonden zijn in termen van gegevens en functies. De implementatie van subsystemen dient te worden uitgevoerd door aparte groepen specialisten. Tegelijkertijd is het noodzakelijk om de coördinatie van het totale project te waarborgen en verdubbeling van de resultaten van het werk van elke projectgroep, die kan optreden als gevolg van de aanwezigheid van gemeenschappelijke gegevens en functies, uit te sluiten;
• de technologie moet de mogelijkheid bieden om in kleine groepen (3-7 personen) te werken aan het ontwerp van individuele subsystemen. Dit komt door de principes van teambeheer en productiviteitsverhoging door het aantal externe links te minimaliseren;
• technologie moet voorzien minimale tijd het verkrijgen van een werkende IS. Het gaat niet om de timing van de gereedheid van de hele IS, maar om de timing van de implementatie van individuele subsystemen. De implementatie van IS als geheel in een korte tijd kan de betrokkenheid van een groot aantal ontwikkelaars vereisen, terwijl het effect lager kan zijn dan wanneer individuele subsystemen in kortere tijd door een kleiner aantal ontwikkelaars worden geïmplementeerd. De praktijk leert dat zelfs bij een volledig afgerond project de implementatie consistent verloopt voor individuele subsystemen;
• de technologie moet de mogelijkheid bieden om de projectconfiguratie te beheren, versies van het project en zijn componenten te onderhouden, de mogelijkheid om automatisch projectdocumentatie uit te geven en de versies ervan te synchroniseren met projectversies;
• de technologie moet zorgen voor de onafhankelijkheid van de uitgevoerde ontwerpoplossingen van de middelen voor het implementeren van de IS (databasebeheersystemen (DBMS), besturingssystemen, programmeertalen en systemen);
• de technologie moet worden ondersteund door een reeks gecoördineerde CASE-tools die zorgen voor automatisering van processen die in alle stadia van de levenscyclus worden uitgevoerd. De algemene benadering van de evaluatie en selectie van CASE-tools wordt beschreven in Paragraaf 4, voorbeelden van complexen van CASE-tools - in Paragraaf 5.7.

De echte toepassing van welke technologie dan ook voor het ontwerp, de ontwikkeling en het onderhoud van IS in een bepaalde organisatie en een bepaald project is onmogelijk zonder de ontwikkeling van een aantal standaarden (regels, afspraken) die door alle projectdeelnemers moeten worden nageleefd. Deze normen omvatten het volgende:

• ontwerp standaard;
• ontwerpdocumentatie standaard;
• standaard- gebruikersomgeving.

De ontwerpnorm moet vermelden:

• een reeks noodzakelijke modellen (diagrammen) in elke ontwerpfase en de mate van detaillering;
• regels voor het vastleggen van ontwerpbeslissingen over diagrammen, waaronder: naamgevingsregels voor objecten (inclusief terminologieconventies), een set attributen voor alle objecten en regels voor het invullen ervan in elke fase, diagramontwerpregels, inclusief vereisten voor de vorm en grootte van objecten , enz. .;
• vereisten voor de configuratie van werkstations voor ontwikkelaars, inclusief besturingssysteeminstellingen, CASE-toolinstellingen, Algemene instellingen projecten, enz.;
• mechanisme om gezamenlijk aan het project te werken, waaronder: regels voor het integreren van projectsubsystemen, regels om het project in dezelfde staat te houden voor alle ontwikkelaars (voorschriften voor de uitwisseling van projectinformatie, bevestigingsmechanisme gemeenschappelijke voorzieningen etc.), regels voor het controleren van ontwerpbeslissingen op consistentie, etc.

In de ontwerpdocumentatienorm moet worden vastgelegd:

• volledigheid, samenstelling en structuur van documentatie in elke ontwerpfase;
• eisen voor het ontwerp (inclusief eisen voor de inhoud van paragrafen, subparagrafen, paragrafen, tabellen, enz.),
• regels voor de voorbereiding, beoordeling, goedkeuring en goedkeuring van documentatie, met vermelding van deadlines voor elke fase;
• vereisten voor het opzetten van een publicatiesysteem dat wordt gebruikt als hulpmiddel voor het voorbereiden van ingebedde documentatie;
• vereisten voor het aanpassen van CASE-tools om ervoor te zorgen dat documentatie wordt opgesteld in overeenstemming met vastgestelde vereisten.

In de gebruikersinterfacestandaard moet staan:

• schermontwerpregels (lettertypen en kleurenpalet), compositie en rangschikking van vensters en bedieningselementen;
• regels voor het gebruik van het toetsenbord en de muis;
• regels voor het opmaken van helpteksten;
• lijst met standaardberichten;
• regels voor het verwerken van gebruikersreacties.

In het afgelopen decennium is een nieuwe richting in software-engineering gevormd - CASE (Computer-Aided Software / System Engineering) - in letterlijke vertaling - de ontwikkeling van informatiesysteemsoftware met de ondersteuning (met behulp van) een computer. Momenteel bestaat er geen algemeen aanvaarde definitie van CASE, de term CASE wordt in een zeer brede zin gebruikt. De oorspronkelijke betekenis van de term CASE, beperkt tot het automatiseren van de ontwikkeling van alleen software, heeft nu een nieuwe betekenis gekregen en omvat het proces van het ontwikkelen van complexe geautomatiseerde informatiesystemen als geheel. Nu verwijst de term CASE-tools naar softwaretools die de processen van het creëren en onderhouden van IS ondersteunen, inclusief analyse en formulering van vereisten, ontwerp van applicatiesoftware (SW) (applicaties) en databases, codegeneratie, testen, documentatie, kwaliteitsborging , configuratiebeheer en projectbeheer en andere processen. CASE-tools vormen samen met systeemsoftware en hardware een complete IS-ontwikkelomgeving.

CASE-tools maken het niet alleen mogelijk om de "juiste" producten te maken, maar ook om het "juiste" proces van hun creatie te bieden. Het belangrijkste doel van CASE is om het ontwerp van een IS te scheiden van de codering en de daaropvolgende ontwikkelingsfasen, en om alle details van de ontwikkelomgeving en de werking van de IS voor ontwikkelaars te verbergen. Bij het gebruik van CASE-technologieën veranderen alle fasen levenscyclus software (hieronder meer) van het informatiesysteem, met de grootste veranderingen in de analyse- en ontwerpfase. De meeste bestaande CASE-tools zijn gebaseerd op structurele (meestal) of objectgeoriënteerde analyse- en ontwerpmethodologieën, waarbij specificaties in de vorm van diagrammen of teksten worden gebruikt om externe vereisten, relaties tussen systeemmodellen, dynamiek van systeemgedrag en software-architecturen te beschrijven. Dergelijke methodologieën bieden een rigoureuze en visuele beschrijving van het ontworpen systeem, dat begint met het algemene overzicht en vervolgens met details, en een hiërarchische structuur krijgt met een toenemend aantal niveaus. CASE-technologieën worden met succes gebruikt om bijna alle soorten IS te bouwen, maar ze nemen een stabiele positie in op de volgende gebieden:

om de ontwikkeling van zakelijke en commerciële IS te verzekeren, is het wijdverbreide gebruik van CASE-technologieën te danken aan de massale aard van dit toepassingsgebied, waarin CASE niet alleen wordt gebruikt om IS te ontwikkelen, maar ook om systeemmodellen te creëren die helpen bij het oplossen van de problemen van strategische planning, financieel beheer, het bepalen van het beleid van bedrijven, opleiding van personeel en anderen (deze richting heeft zijn eigen naam gekregen - bedrijfsanalyse);

ontwikkeling van systeem- en controle-IS. Het actieve gebruik van CASE-technologieën hangt samen met de grote complexiteit van dit probleem en met de wens om de efficiëntie van het werk te verhogen.

CASE is geen revolutie in software-engineering, maar het resultaat van de natuurlijke evolutionaire ontwikkeling van de hele industrie van tools, voorheen instrumenteel of technologisch genoemd. Vanaf het allereerste begin zijn CASE-technologieën geëvolueerd om de beperkingen van het gebruik van de structurele ontwerpmethodologieën van de jaren 60 en 70 te overwinnen. 20ste eeuw (complexiteit van begrip, hoge arbeidsintensiteit en gebruikskosten, moeilijkheid om wijzigingen aan te brengen in ontwerpspecificaties, enz.) vanwege hun automatisering en integratie van ondersteunende tools. CASE-technologieën kunnen dus niet als onafhankelijke methodologieën worden beschouwd, ze ontwikkelen alleen structurele methodologieën en maken hun toepassing efficiënter door automatisering.

Naast het automatiseren van structurele methodologieën en daardoor de mogelijkheid om moderne methodes van systeem- en software-engineering toe te passen, hebben CASE-tools de volgende belangrijkste voordelen:

de kwaliteit van gecreëerde IS verbeteren ten koste van geld automatische controle(voornamelijk projectbeheersing);

geef korte tijd de tijd om een ​​prototype van het toekomstige systeem te maken, waardoor: vroege stadia het verwachte resultaat evalueren;

het ontwerp- en ontwikkelingsproces versnellen;

de ontwikkelaar bevrijden van routinematig werk, waardoor hij zich volledig kan concentreren op het creatieve deel van de ontwikkeling;

ondersteuning van de ontwikkeling en het onderhoud van de ontwikkeling;

ondersteuning van technologieën voor hergebruik van ontwikkelingscomponenten.

Aan het verschijnen van CASE-technologie en CASE-tools ging onderzoek op het gebied van programmeermethodologie vooraf. Programmeren kreeg de kenmerken van een systematische aanpak met de ontwikkeling en implementatie van talen op hoog niveau, structurele en modulaire programmeermethoden, ontwerptalen en hun ondersteunende tools, formele en informele talen voor het beschrijven van systeemvereisten en specificaties, enz. In de jaren 70-80. een structurele methodologie begon in de praktijk te worden toegepast, waardoor ontwikkelaars strikte geformaliseerde methoden kregen voor het beschrijven van IS en technische oplossingen. Het is gebaseerd op een visueel grafische techniek: diagrammen en diagrammen worden gebruikt om verschillende soorten IS-modellen te beschrijven. De zichtbaarheid en nauwkeurigheid van de structurele analysetools stelden de ontwikkelaars en toekomstige gebruikers van het systeem vanaf het allereerste begin in staat om informeel deel te nemen aan de totstandkoming ervan, te discussiëren en het begrip van de belangrijkste technische oplossingen te consolideren. Het wijdverbreide gebruik van deze methodologie en het opvolgen van de aanbevelingen bij de ontwikkeling van contact-IC's was echter vrij zeldzaam, aangezien het praktisch onmogelijk is met niet-geautomatiseerde (handmatige) ontwikkeling. Dit droeg bij aan de opkomst van software- en hardwaretools van een speciale klasse - CASE-tools die de CASE-technologie implementeren voor het creëren en onderhouden van IS.

Het moet duidelijk zijn dat het succesvolle gebruik van CASE-tools onmogelijk is zonder begrip van de onderliggende technologie waarop deze tools zijn gebaseerd. Op zichzelf zijn CASE-softwaretools hulpmiddelen voor het automatiseren van de processen voor het ontwerpen en onderhouden van informatiesystemen. Zonder de IS-ontwerpmethodologie te begrijpen, is het onmogelijk om CASE-tools te gebruiken.

Trends in de ontwikkeling van moderne informatie technologieën leiden tot een constante toename van de complexiteit van informatiesystemen (IS) die zijn gecreëerd in verscheidene velden economie. Moderne grote IP-projecten worden in de regel gekenmerkt door de volgende kenmerken:

de complexiteit van de beschrijving (een vrij groot aantal functies, processen, gegevenselementen en complexe relaties daartussen), die zorgvuldige modellering en analyse van gegevens en processen vereisen;

de aanwezigheid van een reeks nauw op elkaar inwerkende componenten (subsystemen) die hun eigen lokale taken en doelen hebben om te functioneren (bijvoorbeeld traditionele toepassingen met betrekking tot transactieverwerking en het oplossen van routinetaken, en toepassingen van analytische verwerking (beslissingsondersteuning) met behulp van ad-hocquery's tot grote datavolumes);

de afwezigheid van directe analogen, wat de mogelijkheid beperkt om standaardontwerpoplossingen en toegepaste systemen te gebruiken;

de noodzaak om bestaande en nieuw ontwikkelde applicaties te integreren;

functioneren in een heterogene omgeving op verschillende hardwareplatforms;

verdeeldheid en heterogeniteit van individuele groepen ontwikkelaars in termen van vaardigheidsniveau en gevestigde tradities van het gebruik van bepaalde hulpmiddelen;

aanzienlijke tijdspanne van het project, doordat enerzijds gehandicapt ontwikkelingsteam, en anderzijds de schaal van de klantorganisatie en de variërende mate van bereidheid van de afzonderlijke divisies om IS te implementeren.

Voor een succesvolle uitvoering van het project moet eerst het ontwerpobject (IS) adequaat worden beschreven, moeten volledige en consistente functionele en informatiemodellen van het IS worden gebouwd. De tot nu toe opgebouwde ervaring met het ontwerpen van IS toont aan dat dit een logisch complex, arbeidsintensief en tijdrovend werk is waarvoor hooggekwalificeerde specialisten nodig zijn. Tot voor kort werd IS-ontwerp echter voornamelijk op intuïtief niveau uitgevoerd met behulp van niet-geformaliseerde methoden op basis van kunst, praktische ervaring, expertbeoordelingen en dure experimentele controles van de kwaliteit van IS-functioneren. Bovendien, in het proces van creatie en werking van IS informatiebehoeften gebruikers kunnen worden gewijzigd of verfijnd, wat de ontwikkeling en het onderhoud van dergelijke systemen verder bemoeilijkt.

In de jaren '70 en '80 werd bij de ontwikkeling van IS veel gebruik gemaakt van een structurele methodologie, die ontwikkelaars voorziet van strikt geformaliseerde methoden voor het beschrijven van IS en de genomen technische beslissingen. Het is gebaseerd op een visueel grafische techniek: diagrammen en diagrammen worden gebruikt om verschillende soorten IS-modellen te beschrijven. De zichtbaarheid en nauwkeurigheid van de structurele analysetools stelden de ontwikkelaars en toekomstige gebruikers van het systeem vanaf het allereerste begin in staat om informeel deel te nemen aan de totstandkoming ervan, te discussiëren en het begrip van de belangrijkste technische oplossingen te consolideren. Het wijdverbreide gebruik van deze methodologie en het opvolgen van de aanbevelingen bij de ontwikkeling van specifieke IS's was echter vrij zeldzaam, aangezien het praktisch onmogelijk is met niet-geautomatiseerde (handmatige) ontwikkeling. Het is inderdaad erg moeilijk om handmatig strikte formele specificaties van het systeem te ontwikkelen en grafisch weer te geven, ze te controleren op volledigheid en consistentie, en vooral te veranderen. Als het desalniettemin mogelijk is om een ​​strikt systeem van projectdocumenten te creëren, dan is de verwerking ervan bij ernstige wijzigingen praktisch onmogelijk. Handmatige ontwikkeling meestal gegenereerd de volgende problemen::

onvoldoende specificatie van eisen;

onvermogen om fouten in ontwerpbeslissingen te detecteren;

slechte kwaliteit van documentatie die de prestaties vermindert;

lange cyclus en onbevredigende testresultaten.

Aan de andere kant waren IC-ontwikkelaars van oudsher de laatste die computertechnologie gebruikten om de kwaliteit, betrouwbaarheid en prestaties in hun eigen werk(het fenomeen "schoenmaker zonder laarzen").

Bovenstaande factoren droegen bij aan de opkomst van software en technologische tools van een speciale klasse - CASE-tools die de CASE-technologie implementeren voor het creëren en onderhouden van IS. De term CASE (Computer Aided Software Engineering) wordt momenteel in een zeer brede zin gebruikt. De oorspronkelijke betekenis van de term CASE, beperkt tot het automatiseren van de ontwikkeling van alleen software (software), heeft nu een nieuwe betekenis gekregen en omvat het proces van het ontwikkelen van complexe IS als geheel. Nu verwijst de term CASE-tools naar softwaretools die de processen van het creëren en onderhouden van IS ondersteunen, inclusief analyse en formulering van vereisten, ontwerp van applicatiesoftware (applicaties) en databases, codegeneratie, testen, documentatie, kwaliteitsborging, configuratiebeheer en projectmanagement, evenals andere processen. CASE-tools vormen samen met systeemsoftware en hardware een complete IS-ontwikkelomgeving.

Aan het verschijnen van CASE-technologie en CASE-tools ging onderzoek op het gebied van programmeermethodologie vooraf. Programmeren kreeg de kenmerken van een systematische aanpak met de ontwikkeling en implementatie van talen op hoog niveau, methoden voor gestructureerd en modulair programmeren, ontwerptalen en hun ondersteunende tools, formele en informele talen voor het beschrijven van systeemvereisten en specificaties, enz. Daarnaast hebben de volgende factoren bijgedragen aan de opkomst van de CASE-technologie:

opleiding van analisten en programmeurs die ontvankelijk zijn voor de concepten van modulair en gestructureerd programmeren;

wijdverbreide introductie en constante groei van de prestaties van computers, waardoor het mogelijk werd om effectieve grafische hulpmiddelen te gebruiken en de meeste ontwerpfasen te automatiseren;

introductie van netwerktechnologie, die het mogelijk maakte om de inspanningen van individuele artiesten te combineren in één ontwerpproces door gebruik te maken van een gedeelde database met de nodige informatie over het project.

CASE-technologie is een IS-ontwerpmethodologie, evenals een reeks hulpmiddelen die het mogelijk maken in een visuele vorm.

CASE-tools. algemene karakteristieken en classificatie

Moderne CASE-tools bieden een breed scala aan ondersteuning voor tal van IS-ontwerptechnologieën: van eenvoudige analyse- en documentatietools tot volledige automatiseringstools die de hele levenscyclus van software bestrijken.

De meest tijdrovende stadia van IS-ontwikkeling zijn de stadia van analyse en ontwerp, waarin CASE-tools de kwaliteit van de genomen technische beslissingen en de voorbereiding van projectdocumentatie waarborgen. Tegelijkertijd spelen methoden voor visuele presentatie van informatie een belangrijke rol. Dit omvat de constructie van structurele of andere diagrammen in realtime, het gebruik van een verscheidenheid aan kleurenpalet, end-to-end controle van syntactische regels. Met tools voor grafische domeinmodellering kunnen ontwikkelaars de bestaande IS visueel bestuderen en opnieuw opbouwen in overeenstemming met de doelen en bestaande beperkingen.

De categorie CASE-tools omvat zowel relatief goedkope systemen voor personal computers met zeer beperkte mogelijkheden als dure systemen voor heterogene computerplatforms en besturingsomgevingen. Zo omvat de moderne softwaremarkt ongeveer 300 verschillende CASE-tools, waarvan de krachtigste op de een of andere manier door bijna alle toonaangevende westerse bedrijven worden gebruikt.

Gewoonlijk omvatten CASE-tools elke softwaretool die een bepaalde reeks softwarelevenscyclusprocessen automatiseert en de volgende hoofdkenmerken heeft:

krachtige grafische tools voor het beschrijven en documenteren van IP, een handige interface met de ontwikkelaar en het ontwikkelen van zijn creatieve capaciteiten;

integratie van afzonderlijke componenten van CASE-tools, waardoor het IS-ontwikkelingsproces beheersbaar wordt;

gebruik van een speciaal georganiseerde repository van projectmetadata (repository).

Een geïntegreerde CASE-tool (of een set tools die de volledige levenscyclus van de software ondersteunt) bevat de volgende componenten;

een repository die de basis vormt van een CASE-tool. Het moet zorgen voor de opslag van versies van het project en zijn individuele componenten, de synchronisatie van de ontvangst van informatie van verschillende ontwikkelaars tijdens groepsontwikkeling, de controle van metadata voor volledigheid en consistentie;

grafische analyse- en ontwerptools waarmee hiërarchisch gekoppelde diagrammen (DFD, ERD, enz.) kunnen worden gemaakt en bewerkt die IS-modellen vormen;

applicatie-ontwikkelingstools, waaronder 4GL-talen en codegenerators;

hulpprogramma's voor configuratiebeheer;

middel van documentatie;

testinstrumenten;

hulpmiddelen voor projectbeheer;

re-engineering tools.

Alle moderne CASE-tools kunnen voornamelijk worden ingedeeld naar typen en categorieën. Classificatie naar type weerspiegelt de functionele oriëntatie van CASE-tools voor bepaalde levenscyclusprocessen. De categorieclassificatie bepaalt de mate van integratie door de uitgevoerde functies en omvat afzonderlijke lokale tools die kleine autonome taken oplossen (tools), een set gedeeltelijk geïntegreerde tools die de meeste stadia van de IP-levenscyclus dekken (toolkit) en volledig geïntegreerde tools die ondersteuning bieden de volledige IP-levenscyclus en zijn verbonden door een gemeenschappelijke repository. Bovendien kunnen CASE-tools worden geclassificeerd volgens de volgende criteria:

toegepaste methodieken en modellen van systemen en databases;

mate van integratie met het DBMS;

beschikbare platformen.

De indeling naar typen komt in principe overeen met de componentensamenstelling van CASE-tools en omvat de volgende hoofdtypen:

analysetools (Upper CASE) ontworpen om domeinmodellen te bouwen en te analyseren (Design/IDEF (Meta Software), BPwin (Logic Works));

analyse- en ontwerptools (Middle CASE) die de meest voorkomende ontwerpmethodologieën ondersteunen en worden gebruikt om ontwerpspecificaties te maken (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.analist (MacroProject)). De output van dergelijke tools zijn specificaties van systeemcomponenten en interfaces, systeemarchitectuur, algoritmen en datastructuren;

hulpprogramma's voor databaseontwerp die gegevensmodellering en het genereren van databaseschema's bieden (meestal in SQL) voor de meest voorkomende DBMS. NAAR ze bevatten ERwin (Logic Works), S-Designer (SDP) en DataBase Designer (ORACLE). Database-ontwerptools zijn ook opgenomen in de Vantage Team Builder-, Designer/2000-, Silverrun- en PRO-IV CASE-tools;

hulpmiddelen voor het ontwikkelen van applicaties. Deze omvatten 4GL-tools (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland), enz.) en generatorcodes opgenomen in Vantage Team Builder, PRO-IV en gedeeltelijk in Silverrun;

re-engineeringtools die analyse van programmacodes en databaseschema's en vorming op basis daarvan bieden verschillende modellen en ontwerpspecificaties. Databaseschema-analyse en ERD-generatietools zijn opgenomen in Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin en S-Designor. Op het gebied van programmacode-analyse worden objectgeoriënteerde CASE-tools die re-engineering van C++-programma's (Rational Rose (Rational Software), Object Team (Cayenne)) bieden, het meest gebruikt.

Typen helpers zijn onder meer:

tools voor projectplanning en -beheer (SE Companion, Microsoft Project, enz.);

configuratiebeheertools (PVCS (Intersolv));

testtools (Kwaliteitswerken (Segue-software));

documentatietools (SoDA (Rational Software)).

Tot op heden heeft de Russische softwaremarkt de volgende meest ontwikkelde CASE-tools:

Vantage Team Builder (Westmount I-CASE);

Ontwerper/2000;

Zilverloop;

ERwin+BPwin;

S Ontwerper;

CASE.Analyst.

Daarnaast komen er continu zowel nieuwe systemen voor thuisgebruikers (bijvoorbeeld CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE) als nieuwe versies en aanpassingen van deze systemen op de markt.

1. Grondbeginselen van IS-ontwerpmethodologie

1.1. IP-softwarelevenscyclus

Een van de basisconcepten IS-ontwerpmethodologie is het concept van de levenscyclus van zijn software (LC-software). De levenscyclus van software is een continu proces dat begint vanaf het moment dat er een beslissing is genomen over de noodzaak van het maken ervan en eindigt op het moment dat het volledig uit bedrijf wordt genomen.

Voornaamst normatief document, die de levenscyclus van software regelt, is de internationale norm ISO / IEC 12207 (ISO - International Organization of Standardization - International Organization for Standardization, IEC - International Electrotechnical Commission - International Commission on Electrical Engineering). Het definieert een levenscyclusstructuur die de processen, activiteiten en taken bevat die tijdens de softwareontwikkeling moeten worden voltooid.

De structuur van de softwarelevenscyclus volgens de ISO/IEC 12207-standaard is gebaseerd op drie procesgroepen:

de belangrijkste processen van de softwarelevenscyclus (aankoop, levering, ontwikkeling, exploitatie, onderhoud);

hulpprocessen die zorgen voor de uitvoering van de hoofdprocessen (documentatie, configuratiebeheer, kwaliteitsborging, verificatie, certificering, beoordeling, audit, probleemoplossing);

organisatorische processen (projectmanagement, creatie van projectinfrastructuur, definitie, evaluatie en verbetering van de levenscyclus zelf, opleiding).

De ontwikkeling omvat al het werk aan het creëren van software en zijn componenten in overeenstemming met de gespecificeerde vereisten, inclusief de voorbereiding van ontwerp- en operationele documentatie, de voorbereiding van materialen die nodig zijn om de werking en de juiste kwaliteit van softwareproducten te testen, materialen die nodig zijn voor het organiseren van personeel opleiding enz. Softwareontwikkeling omvat doorgaans analyse, ontwerp en implementatie (programmering).

Exploitatie omvat werkzaamheden aan het in gebruik nemen van softwarecomponenten, waaronder het configureren van de database en gebruikerswerkstations, het verstrekken van operationele documentatie, het geven van personeelstraining, enz., en het direct bedienen, inclusief het lokaliseren van problemen en het wegnemen van de oorzaken van hun optreden, het de vastgestelde regelgeving, het opstellen van voorstellen voor de verbetering, ontwikkeling en modernisering van het systeem.

Projectmanagement heeft te maken met het plannen en organiseren van werk, het creëren van teams van ontwikkelaars en het bewaken van de timing en kwaliteit van het uitgevoerde werk. De technische en organisatorische ondersteuning van het project omvat de keuze van methoden en hulpmiddelen voor de implementatie van het project, de definitie van methoden voor het beschrijven van de tussenstadia van ontwikkeling, de ontwikkeling van methoden en hulpmiddelen voor het testen van software, opleiding van personeel, enz. De kwaliteitsborging van projecten houdt verband met de problemen van softwareverificatie, verificatie en testen. Verificatie is het proces om te bepalen of de huidige staat van ontwikkeling die in een bepaald stadium is bereikt, voldoet aan de eisen van dat stadium. Validatie stelt u in staat om te beoordelen of ontwikkelingsparameters voldoen aan de oorspronkelijke vereisten. Verificatie overlapt met testen, dat zich bezighoudt met het identificeren van verschillen tussen werkelijke en verwachte resultaten en het evalueren of de softwarefuncties voldoen aan de oorspronkelijke vereisten. In het proces van projectimplementatie nemen kwesties van identificatie, beschrijving en controle van de configuratie van individuele componenten en het gehele systeem als geheel een belangrijke plaats in.

Configuratiebeheer is een van de hulpprocessen die de hoofdprocessen van de softwarelevenscyclus ondersteunen, met name de processen van softwareontwikkeling en -onderhoud. Bij het maken van complexe IS-projecten die uit vele componenten bestaan, die elk varianten of versies kunnen hebben, ontstaat het probleem om rekening te houden met hun relaties en functies, een uniforme structuur te creëren en de ontwikkeling van het hele systeem te waarborgen. Configuratiemanagement stelt u in staat om wijzigingen in de software in alle fasen van de levenscyclus te organiseren, systematisch rekening mee te houden en te controleren. Algemene principes en aanbevelingen voor configuratieboekhouding, planning en beheer van softwareconfiguraties worden weerspiegeld in de concept ISO 12207-2-standaard.

Elk proces wordt gekenmerkt door bepaalde taken en methoden om ze op te lossen, de initiële gegevens die in de vorige fase zijn verkregen en de resultaten. De resultaten van de analyse zijn met name functionele modellen, informatiemodellen en de bijbehorende diagrammen. De softwarelevenscyclus is iteratief van aard: de resultaten van de volgende fase leiden vaak tot veranderingen in de ontwerpbeslissingen die in eerdere stadia zijn ontwikkeld.

2. Structurele benadering van IS-ontwerp CASE betekent:

2.1. De essentie van de structurele aanpak

De essentie van de structurele benadering van de ontwikkeling van IS ligt in de decompositie (partitionering) ervan in geautomatiseerde functies: het systeem is verdeeld in functionele subsystemen, die op hun beurt zijn onderverdeeld in subfuncties, onderverdeeld in taken, enzovoort. Het partitioneringsproces gaat door tot aan specifieke procedures. Tegelijkertijd behoudt het geautomatiseerde systeem een ​​holistisch beeld waarin alle componenten met elkaar verbonden zijn. Bij het ontwikkelen van een systeem "bottom-up" van individuele taken naar het gehele systeem, gaat integriteit verloren, ontstaan ​​er problemen bij het informatief koppelen van individuele componenten.

Alle meest voorkomende methodieken van de structurele aanpak zijn gebaseerd op een aantal: algemene principes. als twee Basisprincipes de volgende worden gebruikt:

verdeel en heers principe - het principe van beslissing moeilijke problemen door ze op te splitsen in veel kleinere onafhankelijke taken die gemakkelijk te begrijpen en op te lossen zijn;

principe van hiërarchische ordening - het principe van het organiseren van de samenstellende delen van het probleem in hiërarchische boomstructuren met toevoeging van nieuwe details op elk niveau.

De selectie van twee basisprincipes betekent niet dat de overige principes secundair zijn, aangezien het negeren van een ervan kan leiden tot onvoorspelbare gevolgen (inclusief het mislukken van het hele project). De belangrijkste van deze principes zijn de volgende:

het principe van abstractie - is om de essentiële aspecten van het systeem te benadrukken en abstractie van niet-essentiële;

het principe van formalisering - ligt in de behoefte aan een strikte methodologische benadering om het probleem op te lossen;

het principe van consistentie - ligt in de geldigheid en consistentie van de elementen;

principe van gegevensstructurering - is dat de gegevens gestructureerd en hiërarchisch georganiseerd moeten zijn.

Bij structurele analyse worden voornamelijk twee groepen hulpmiddelen gebruikt, die de functies illustreren die door het systeem worden uitgevoerd en de relaties tussen gegevens. Elke groep tools komt overeen met bepaalde soorten modellen (diagrammen), waarvan de meest voorkomende de volgende zijn:

SADT-modellen (Structured Analysis and Design Technique) en gerelateerde functionele diagrammen (paragraaf 2.2);

DFD (Data Flow Diagrams) datastroomdiagrammen (subparagraaf 2.3);

ERD (Entity-Relationship Diagrams) diagrammen "entiteit-relatie" (subparagraaf 2.4).

In de ontwerpfase van IS worden de modellen uitgebreid, verfijnd en aangevuld met diagrammen die de structuur van de software weerspiegelen: software-architectuur, blokschema's van programma's en diagrammen van schermvormen.

De genoemde modellen geven samen een volledige beschrijving van de IS, ongeacht of deze bestaat of nieuw is ontwikkeld. De samenstelling van de diagrammen is in elk afzonderlijk geval afhankelijk van de vereiste volledigheid van de beschrijving van het systeem.

2.2. SADT Functionele Modelleringsmethodologie ( IDEF 0)

De SADT-methodologie is ontwikkeld door Douglas Ross. Op basis hiervan is met name de bekende methodologie IDEF0 (Icam DEFinition) ontwikkeld, het belangrijkste onderdeel van het ICAM-programma (Integration of computer and industriële technologieën) geïnitieerd door de Amerikaanse luchtmacht.

De SADT-methodologie is een reeks methoden, regels en procedures die zijn ontworpen om een ​​functioneel model van een object in elk vakgebied te bouwen. Het functionele SADT-model weerspiegelt de functionele structuur van een object, d.w.z. de acties die het uitvoert en de verbanden tussen deze acties. De belangrijkste elementen van deze methodologie zijn gebaseerd op de volgende concepten:

grafische weergave van blokmodellering. De blok- en booggrafieken van het SADT-diagram geven de functie weer als een blok, en de invoer/uitvoer-interfaces worden weergegeven door bogen die respectievelijk het blok binnenkomen en verlaten. De interactie van blokken met elkaar wordt beschreven door middel van interfacebogen die "beperkingen" uitdrukken, die op hun beurt bepalen wanneer en hoe functies worden uitgevoerd en gecontroleerd;

strengheid en precisie. De implementatie van de SADT-regels vereist voldoende nauwkeurigheid en precisie zonder onnodige beperkingen op te leggen aan de acties van de analist. SADT-regels omvatten:

beperking van het aantal blokken op elk niveau van ontbinding (regel 3-6 blokken);

connectiviteit van diagrammen (aantal blokken);

uniciteit van labels en namen (geen dubbele namen);

syntactische regels voor afbeeldingen (blokken en bogen);

scheiding van input en controle (de regel voor het bepalen van de rol van data).

scheiding van organisatie en functie, d.w.z. uitsluiting van de invloed van de organisatiestructuur op het functionele model.

De SADT-methodologie kan worden gebruikt om een ​​breed scala aan systemen te modelleren en vereisten en functies te definiëren, en vervolgens een systeem te ontwerpen dat aan die vereisten voldoet en die functies implementeert. Voor al bestaande systemen SADT kan worden gebruikt om de functies van het systeem te analyseren en om de mechanismen aan te geven waarmee ze worden uitgevoerd.

2.2.1. De samenstelling van het functionele model

Het resultaat van het toepassen van de SADT-methodiek is een model dat bestaat uit diagrammen, tekstfragmenten en een verklarende woordenlijst die met elkaar verband houden. Diagrammen zijn de belangrijkste componenten van het model, alle IS-functies en interfaces worden gepresenteerd als blokken en bogen. Het verbindingspunt van de boog met het blok bepaalt het interfacetype. Besturingsinformatie komt het blok van boven binnen, terwijl de informatie die wordt verwerkt aan de linkerkant van het blok wordt weergegeven en de uitvoerresultaten aan de rechterkant. Het mechanisme (menselijk of geautomatiseerd systeem) dat de bewerking uitvoert, wordt weergegeven door een boog die het blok van onderaf binnenkomt (Figuur 2.1).

Een van de belangrijkste kenmerken van de SADT-methodologie is de geleidelijke introductie van toenemende detailniveaus naarmate de diagrammen die het model vertegenwoordigen, worden gemaakt.

Rijst. 2.1. Functieblok en interfacebogen

Figuur 2.2, die de vier diagrammen en hun relaties toont, toont de structuur van het SADT-model. Elk onderdeel van het model kan worden ontleed in een ander diagram. Elk diagram illustreert de "interne structuur" van een blok in het bovenliggende diagram.

2.2.2. Grafiekhiërarchie

De constructie van het SADT-model begint met de weergave van het hele systeem in de vorm van de eenvoudigste component - één blok en bogen die interfaces met functies buiten het systeem vertegenwoordigen. Omdat een enkel blok het hele systeem als geheel vertegenwoordigt, is de naam die in het blok wordt gegeven generiek. Dit geldt ook voor interfacebogen - ze vertegenwoordigen ook de complete set externe interfaces van het systeem als geheel.

Vervolgens wordt het blok dat het systeem als een enkele module vertegenwoordigt, gedetailleerd in een ander diagram met behulp van verschillende blokken die zijn verbonden door interfacebogen. Deze blokken vertegenwoordigen de belangrijkste subfuncties van de oorspronkelijke functie. deze ontleding onthult een complete set van subfuncties, die elk worden weergegeven als een blok, waarvan de grenzen worden gedefinieerd door interfacebogen. Elk van deze subfuncties kan op een vergelijkbare manier worden ontleed voor een meer gedetailleerde weergave.

In alle gevallen kan elke subfunctie alleen die elementen bevatten die in de oorspronkelijke functie zijn opgenomen. Het model kan ook geen elementen weglaten, d.w.z. zoals opgemerkt, het bovenliggende blok en zijn interfaces bieden context. Er kan niets aan worden toegevoegd en er kan niets van worden verwijderd.

Het SADT-model is een reeks diagrammen met bijbehorende documentatie die een complex object opsplitst in zijn samenstellende delen, die als blokken worden gepresenteerd. De details van elk van de hoofdblokken worden weergegeven als blokken in andere diagrammen. Elk gedetailleerd diagram is een ontleding van een blok uit een meer algemeen diagram. Bij elke decompositiestap wordt het meer algemene diagram het bovenliggende diagram van het meer gedetailleerde diagram genoemd.

Bogen die een blok in een diagram binnenkomen en verlaten top niveau, zijn precies hetzelfde als de bogen in het diagram lager niveau en eruit komen, omdat het blok en het diagram hetzelfde deel van het systeem vertegenwoordigen.

Rijst. 2.2. Structuur van het SADT-model. diagram ontleding

Figuren 2.3 - 2.5 tonen verschillende opties uitvoering van functies en verbinding van bogen met blokken.

Rijst. 2.3. Gelijktijdige uitvoering

Rijst. 2.4. Naleving moet volledig en consistent zijn

Sommige bogen zijn aan beide uiteinden aan de diagramvakken bevestigd, terwijl bij andere één uiteinde niet is bevestigd. Niet-verbonden bogen komen overeen met de ingangen, bedieningselementen en uitgangen van het bovenliggende blok. De bron of bestemming van deze grensbogen is alleen te vinden in het bovenliggende diagram. De losse uiteinden moeten overeenkomen met de bogen in het originele diagram. Alle grensbogen moeten doorlopen op het bovenliggende diagram om volledig en consistent te zijn.

De SADT-diagrammen geven niet expliciet de volgorde of tijd aan. Feedbacks, iteraties, lopende processen en overlappende (in de tijd) functies kunnen worden weergegeven met behulp van bogen. Feedback kan in de vorm van opmerkingen, opmerkingen, correcties, etc. (Figuur 2.5).

Rijst. 2.5. Feedback voorbeeld

Zoals opgemerkt, tonen de mechanismen (bogen aan de onderkant) de middelen waarmee functies worden uitgevoerd. Het mechanisme kan een mens zijn, een computer of elk ander apparaat dat bij deze functie helpt (figuur 2.6).

Rijst. 2.6. Voorbeeld van mechanisme

Elk blok in het diagram heeft zijn eigen nummer. Een blok van elk diagram kan verder worden beschreven door een diagram op een lager niveau, dat op zijn beurt verder kan worden gedetailleerd met het vereiste aantal diagrammen. Zo wordt een hiërarchie van diagrammen gevormd.

Om de positie van een diagram of blok in de hiërarchie aan te geven, worden diagramnummers gebruikt. A21 is bijvoorbeeld een diagram dat vak 1 in diagram A2 beschrijft. Op dezelfde manier geeft A2 box 2 in diagram A0 weer, het bovenste diagram van het model. Figuur 2.7 toont een typische diagramboom.

Rijst. 2.7. Grafiekhiërarchie

2.2.3. Soorten koppelingen tussen functies

Een van de belangrijke punten bij het ontwerpen van een IS met behulp van de SADT-methodologie is er een exacte consistentie in de soorten relaties tussen functies. Er zijn ten minste zeven soorten binding:

Elk linktype wordt hieronder kort gedefinieerd en geïllustreerd aan de hand van een typisch voorbeeld van SADT.

(0) Willekeurig verbindingstype: minst wenselijk.

Willekeurige connectiviteit vindt plaats wanneer er weinig of geen specifieke relatie is tussen functies. Dit verwijst naar de situatie waarin gegevensnamen op SADT-bogen in hetzelfde diagram weinig met elkaar te maken hebben. Een extreme versie van dit geval wordt getoond in figuur 2.8.

Rijst. 2.8. Willekeurige verbinding

(1) Type logische verbinding.Logische binding vindt plaats wanneer gegevens en functies bij elkaar worden gebracht omdat ze in een gemeenschappelijke klasse of reeks elementen vallen, maar de noodzakelijke functionele relaties ertussen niet worden gevonden.

(2) Type tijdelijke connectiviteit.Tijdgerelateerde elementen ontstaan ​​omdat ze tijdgerelateerde functies vertegenwoordigen wanneer gegevens gelijktijdig worden gebruikt of functies parallel worden ingeschakeld in plaats van sequentieel.

(3) Type procedurele connectiviteit.Procedureel gerelateerde items worden gegroepeerd weergegeven omdat ze tijdens hetzelfde deel van een lus of proces worden uitgevoerd. Een voorbeeld van een procedureel gekoppeld diagram is weergegeven in figuur 2.9.

Rijst. 2.9. procedurele connectiviteit

(4) Type communicatieverbinding.Diagrammen demonstreren: communicatie links wanneer blokken gegroepeerd zijn omdat ze dezelfde input gebruiken en/of dezelfde output produceren (figuur 2.10).

(5) Type seriële verbinding.In diagrammen met seriële verbindingen is de uitvoer van de ene functie de invoer voor de volgende functie. De verbinding tussen de elementen in het diagram is nauwer dan op de hierboven besproken niveaus van verbanden, omdat oorzaak-gevolgrelaties worden gemodelleerd (Figuur 2.11).

(6) Type functionele connectiviteit.Het diagram geeft de volledige functionele connectiviteit weer, in aanwezigheid van: volledige afhankelijkheid de ene functie van de andere. Een diagram dat puur functioneel is, bevat geen vreemde elementen van sequentiële of zwakkere connectiviteit. Een manier om functioneel gerelateerde diagrammen te definiëren, is door twee blokken te beschouwen die zijn verbonden via besturingsbogen, zoals weergegeven in figuur 2.12.

Rijst. 2.10. Communicatie connectiviteit

Rijst. 2.11. seriële connectiviteit

Afb.13. Functioneel diagram voor het maken en wijzigen van een productontwerp (tweede niveau)

Voor de leesbaarheid wordt aanbevolen om het aantal blokken in het diagram te beperken tot drie tot zes. De bovengrens dwingt iemand zijn toevlucht te nemen tot ontbinding, de onderste zorgt ervoor dat het diagram voldoende details heeft om het maken ervan te rechtvaardigen. Het is wenselijk dat het aantal interface-bogen dat de zijkant van het blok nadert of eruit voortkomt niet groter is dan 4.

De IDEF 0-methode gaat ervan uit: groepswerkover een project of projecten. Een groep van verschillende specialisten interviewt competente personen en bouwt een ruw model op. Dit model wordt besproken door de specialisten van de onderneming, schriftelijk bekritiseerd en overgedragen aan het ontwikkelteam. Deze cyclus gaat door totdat ontwikkelaars en reviewers het erover eens zijn. Vervolgens wordt het model formeel goedgekeurd en gebruikt (bijvoorbeeld voor het herstructureren van systeemfuncties).

Een van de voordelen van de methode: IDEF 0 is dat het abstraheertorganisatiestructuur van het objecten analyseert zijn functies. Dit laat toe om, na het bouwen van het model, te kijken naar de organisatiestructuur die deze functies implementeert vanuit het oogpunt van zijn perfectie, om gelijkaardige functies of hun verdubbeling te identificeren, en om voorstellen te doen voor het reorganiseren van het systeem.

Als we de term "bedrijfsproces" gebruiken, kunnen we zeggen dat de methode IDEF 0 stelt u in staat om te identificerenbedrijfsprocessen, het functioneren van de onderneming beschouwen "zoals het is" en op basis van hun analyse voorstellen doen "zoals het zou moeten zijn", dat wil zeggen een frisse kijk op het werk van de onderneming, de verantwoordelijkheden van werknemers verduidelijken, evalueren de efficiëntie van het gebruik van hulpbronnen, zie de tekortkomingen die kunstig verborgen zijn in de gebruikelijke organisatiestructuur. Daarom kan het identificeren, analyseren en wijzigen van bedrijfsprocessen worden gebruikt om de efficiëntie van de onderneming te verbeteren.

Sinds de introductie van de term "bedrijfsproces" zijn er verschillende technieken ontstaan ​​om bedrijfsprocessen te verbeteren. De meest populaire hiervan is de re-engineering van bedrijfsprocessen, wat een fundamentele heroverweging en herontwerp van bedrijfsprocessen inhoudt. Het identificeren, analyseren en herontwerpen van deze processen vormt de inhoud van de voorgestelde methodologie. Het algemene schema van de methodologie voor het analyseren en opnieuw ontwerpen van de bedrijfsprocessen van een onderneming is als volgt (zie figuur 12):

Verzamelen van informatie over de onderneming;

• identificatie van zakelijke bedrijfsprocessen en het creëren van een functioneel model van zakelijke bedrijfsprocessen;
• analyse en mogelijke re-engineering van zakelijke bedrijfsprocessen.

Voor analyse kosten delende ABC-methode op basis van IDEF0 wordt toegepast. De ABC-methode is gebaseerd op het feit dat de uitvoering van elke functie tijdens de werking van de onderneming bepaalde kosten met zich meebrengt, dat wil zeggen dat het bijdraagt ​​​​aan het verschijnen van kosten. АВС is vergelijkbaar met het concept van FSA - functionele kostenanalyse. Met behulp van de ABC-methode worden de kosten voor het uitvoeren van het gehele proces of een afzonderlijke functie, de kosten van producten aan de output van het proces berekend en worden de bronnen van de belangrijkste kosten geïdentificeerd. De kosten van het uitvoeren van een ontleedbare functie worden gedefinieerd als de som van de kosten van het uitvoeren van alle samenstellende elementen in deze functie.

De toepassing van de ABC-methode stelt u in staat kwantitatieve schattingen te verkrijgen van het proces dat nodig is om verschillende opties te evalueren. In tegenstelling tot traditionele boekhouding, die voornamelijk rekening houdt met directe kosten (het verantwoorden van indirecte kosten is moeilijk, maar in sommige gevallen noodzakelijk), stelt de ABC-methode u in staat rekening te houden met verschillende factoren die van invloed zijn op de vorming van ondernemingskosten.

Om een ​​functioneel model te bouwen, wordt voorgesteld om te kiezen voor: CASE-Design/IDEF-pakket , want naast de mogelijkheden om een ​​functioneel model te maken, bevat dit pakket een ingebouwd ABC-mechanisme voor het berekenen van de kosten van het uitvoeren van functies, waarmee u bedrijfsprocessen en hun componenten kunt analyseren. Elk type resource dat door een functie wordt verbruikt (verwerkt), evenals de mechanismen die de functie uitvoeren, voegen kosten toe aan deze functie, terwijl rekening wordt gehouden met kostenelementen die worden genegeerd in de gebruikelijke presentatie van de onderneming als een reeks organisatiestructuren . Daarom kan elke functie h van het IDEF0-model worden geassocieerd met de waarde van de kosten van het uitvoeren van deze functie Ex(h).

Afb.14. Algemeen schema van de methodologie voor analyse en re-engineering van bedrijfsprocessen van ondernemingen

De combinatie van de IDEF0- en ABC-methoden (Fig. 14) maakt het mogelijk om een ​​van de belangrijkste taken op te lossen - de analyse van de perfectie van de systeemfuncties, de mogelijkheden voor verbetering ervan, wat niet inherent is aan andere methoden en normen voor een dergelijke mate waarin.Door de ABC-methode te verbinden, kun je de bestaande structuur (zoals die is) vergelijken met de rationele structuur (zoals die zou moeten zijn), aangezien dezelfde functies door verschillende structuren kunnen worden geïmplementeerd (je kunt bijvoorbeeld afdelingen die vergelijkbare functies uitvoeren combineren met een onbeduidend verschil of een kleine belasting).

Een voorbeeld van het construeren van ffunctioneel model van het CAD-creatieproces wordt getoond in Figuren 15…18.

Afb.15. Functioneel model van het CAD-creatieproces (begin).
IDEF 0-diagram van het eerste niveau.

Afb.16. IDEF 0-chart enquête onderneming.

Afb.17. IDEF 0-diagram ontwerp CAD.

Afb.18. IDEF 0-diagram van de uitvoering van het CAD-project.

2.3. Modelleren van datastromen (processen - modellen DFD , IDEF standaard 1)

Deze methodologie (Gane/Sarson-methodologie) is gebaseerd op de constructie van een model van de geanalyseerde IS - ontworpen of feitelijk bestaande. In overeenstemming met de methodologie wordt het systeemmodel gedefinieerd als een hiërarchie van gegevensstroomdiagrammen (DFD of DFD) die het asynchrone proces van informatietransformatie beschrijven vanaf de invoer in het systeem tot de uitgifte aan de gebruiker. Diagrammen van de bovenste niveaus van de hiërarchie (contextdiagrammen) definiëren de hoofdprocessen of subsystemen van de IS met externe inputs en outputs. Ze worden gedetailleerd met behulp van diagrammen op een lager niveau. Deze decompositie gaat door, waardoor een hiërarchie van diagrammen op meerdere niveaus ontstaat, totdat een dergelijk niveau van decompositie wordt bereikt waarbij de processen elementair worden en het onmogelijk is om ze verder in detail te beschrijven.

IDEF1 - simulatiemethodeinformatiestromen binnen het systeem,waardoor de structuur van het systeem kan worden weergegeven, dat wil zeggen de elementen (entiteiten), hun eigenschappen (attributen) en de relaties (relaties) daartussen. De gedetailleerde informatie die tijdens het modelleren wordt verkregen, maakt het mogelijk om "bottlenecks" in het geanalyseerde object te identificeren en is de basis voor het nemen van beslissingen over het verbeteren van de inrichting van het systeem en de informatiestromen en het implementeren van het juiste informatiebeheerbeleid.

Informatiebronnen (externe entiteiten) genereren informatiestromen (datastromen) die informatie overbrengen naar subsystemen of processen. Die transformeren op hun beurt informatie en genereren nieuwe stromen die informatie overbrengen naar andere processen of subsystemen, gegevensopslag of externe entiteiten - consumenten van informatie. De belangrijkste componenten van gegevensstroomdiagrammen zijn dus:

externe entiteiten;

systemen/subsystemen;

processen;

apparaten voor gegevensopslag;

datastromen.

2.3.1. Externe entiteiten

Een externe entiteit is een materieel object of individueel A die de bron of bestemming van informatie vertegenwoordigt, zoals klanten, personeel, leveranciers, klanten, voorraad. De definitie van een object of systeem als een externe entiteit geeft aan dat het zich buiten de grenzen van de geanalyseerde IS bevindt. Tijdens de analyse kunnen sommige externe entiteiten indien nodig binnen het diagram van de geanalyseerde IS worden overgebracht, of omgekeerd kan een deel van de IS-processen buiten het diagram worden verplaatst en als een externe entiteit worden gepresenteerd.

Een externe entiteit wordt aangegeven door een vierkant (figuur 2.13), dat zich als het ware "boven" het diagram bevindt en er een schaduw op werpt om dit symbool te onderscheiden van andere aanduidingen:

Rijst. 2.13. externe entiteit

2.3.2. Systemen en subsystemen

Bij het bouwen van een complex IS-model kan het worden weergegeven in de algemeen beeld op het zogenaamde contextdiagram als één systeem als geheel, of kan worden ontleed in een aantal subsystemen.

Het subsysteem (of systeem) in het contextdiagram wordt als volgt weergegeven (Figuur 2.14).

Rijst. 2.14. subsysteem

Het subsysteemnummer dient ter identificatie. In het naamveld wordt de naam van het subsysteem ingevuld in de vorm van een zin met het onderwerp en bijbehorende definities en toevoegingen.

2.3.3. Processen

Het proces is de transformatie van invoergegevensstromen in uitvoerstromen in overeenstemming met een bepaald algoritme. Fysiek kan het proces worden gerealiseerd verschillende manieren: dit kan een onderdeel zijn van de organisatie (afdeling) die invoerdocumenten verwerkt en rapportages uitbrengt, een in hardware geïmplementeerd programma logisch apparaat enzovoort.

Het proces in het datastroomdiagram wordt weergegeven zoals weergegeven in figuur 2.15.

Rijst. 2.15. Werkwijze

Het procesnummer wordt gebruikt om het te identificeren. In het naamveld wordt de naam van het proces ingevoerd als een zin met een actief ondubbelzinnig werkwoord in de onbepaalde vorm (berekenen, berekenen, controleren, bepalen, creëren, ontvangen), gevolgd door zelfstandige naamwoorden in de accusatief, bijvoorbeeld:

"Klantgegevens invoeren";

"Geef informatie over lopende uitgaven";

"Controleer de kredietwaardigheid van de klant."

Het gebruik van werkwoorden zoals "proces", "moderniseren" of "bewerken" duidt meestal op een gebrek aan begrip van het proces en vereist verdere analyse.

De informatie in het veld fysieke implementatie geeft aan welk deel van de organisatie, het programma of het hardwareapparaat het proces uitvoert.

2.3.4. Gegevensschijven

Het gegevensopslagapparaat is een abstract apparaat voor het opslaan van informatie die op elk moment in de schijf kan worden geplaatst en na enige tijd kan worden verwijderd, en de methoden voor invoeging en extractie kunnen elke zijn.

Het gegevensopslagapparaat kan fysiek worden geïmplementeerd in de vorm van een microfiche, een lade in een archiefkast, een tabel in RAM, een bestand op magnetische media enzovoort. De gegevensaccumulator op het gegevensstroomdiagram wordt weergegeven zoals weergegeven in figuur 2.16.

Rijst. 2.16. Data opslag

Het gegevensopslagapparaat wordt geïdentificeerd door de letter "D" en een willekeurig nummer. De naam van de schijf is gekozen vanuit het oogpunt van de grootste informatieve inhoud voor de ontwerper.

De dataopslag is doorgaans een prototype van de toekomstige database en de beschrijving van de daarin opgeslagen data dient gekoppeld te worden aan het informatiemodel.

2.3.5. Gegevensstromen

De gegevensstroom definieert de informatie die via een verbinding van de bron naar de ontvanger wordt verzonden. De feitelijke gegevensstroom kan informatie zijn die via een kabel tussen twee apparaten wordt verzonden, brieven per post, magnetische banden of diskettes, die van de ene computer naar de andere worden overgedragen, enzovoort.

De gegevensstroom in het diagram wordt weergegeven door een lijn die eindigt met een pijl die de richting van de stroom aangeeft (figuur 2.17). Elke datastroom heeft een naam die de inhoud weerspiegelt.

Rijst. 2.17. Data stroom

2.3.6. Een hiërarchie van gegevensstroomdiagrammen bouwen

De eerste stap bij het bouwen van een DPD-hiërarchie is het maken van contextdiagrammen. Meestal wordt bij het ontwerpen van relatief eenvoudige IS's één enkel contextdiagram met een stertopologie gebouwd, met in het midden het zogenaamde hoofdproces, verbonden met ontvangers en informatiebronnen via welke gebruikers en andere externe systemen met het systeem interageren .

Als we ons voor een complex systeem beperken tot één contextdiagram, dan bevat het te veel bronnen en ontvangers van informatie die moeilijk op een vel papier van normaal formaat te plaatsen zijn, en bovendien doet het enige hoofdproces dat niet. de structuur niet onthullen gedistribueerd systeem. Tekenen van complexiteit (qua context) kunnen zijn:

de aanwezigheid van een groot aantal externe entiteiten (tien of meer);

gedistribueerde aard van het systeem;

multifunctionaliteit van een systeem met een reeds vastgestelde of geïdentificeerde groepering van functies in afzonderlijke subsystemen.

Voor complexe IS wordt een hiërarchie van contextdiagrammen gebouwd. Tegelijkertijd bevat het contextdiagram op het hoogste niveau niet één enkel hoofdproces, maar een reeks subsystemen die door gegevensstromen met elkaar zijn verbonden. Contextdiagrammen op het volgende niveau geven de context en structuur van subsystemen weer.

De hiërarchie van contextdiagrammen bepaalt de interactie van de belangrijkste functionele subsystemen van het ontworpen IS, zowel onderling als met externe input- en outputgegevensstromen en externe objecten (bronnen en ontvangers van informatie) waarmee het IS interageert.

Ontwikkeling van contextdiagrammen lost het probleem van strikte definitie op functionele structuur IS in de vroegste fase van zijn ontwerp, wat vooral van belang is voor complexe multifunctionele systemen, in de ontwikkeling waaraan verschillende organisaties en ontwikkelteams deelnemen.

Na het construeren van de contextdiagrammen moet het resulterende model worden gecontroleerd op de volledigheid van de initiële gegevens over de objecten van het systeem en de isolatie van de objecten (gebrek aan informatiekoppelingen met andere objecten).

Voor elk subsysteem dat aanwezig is in de contextdiagrammen, wordt de detaillering uitgevoerd met behulp van DPD. Elk proces op de DPD kan op zijn beurt worden gedetailleerd met behulp van de DPD of minispecificatie. Wanneer detaillering moet worden uitgevoerd regels volgen:

balanceringsregel - betekent dat bij het detailleren van een subsysteem of proces, het detailleringsdiagram als externe gegevensbronnen/ontvangers alleen die componenten (subsystemen, processen, externe entiteiten, gegevensstations) kan hebben waarmee het informatie verbinding een gedetailleerd subsysteem of proces in het bovenliggende diagram;

nummeringsregel - betekent dat bij het detailleren van processen hun hiërarchische nummering moet worden ondersteund. Processen die procesnummer 12 beschrijven, krijgen bijvoorbeeld de nummers 12.1, 12.2, 12.3, enzovoort.

De minispecificatie (beschrijving van de logica van het proces) moet zijn belangrijkste functies zo formuleren dat in de toekomst de specialist die het project uitvoert deze kan uitvoeren of een passend programma kan ontwikkelen.

De minispecificatie is de laatste top van de DPD-hiërarchie. De beslissing om het procesdetail in te vullen en de minispecificatie te gebruiken, wordt door de analist genomen op basis van de volgende criteria:

het proces heeft een relatief klein aantal invoer- en uitvoergegevensstromen (2-3 stromen);

de mogelijkheid om de transformatie van gegevens door het proces te beschrijven in de vorm van een sequentieel algoritme;

uitvoering door het proces van een enkele logische functie van het omzetten van invoerinformatie in uitvoer;

de mogelijkheid om de logica van het proces te beschrijven met behulp van een kleine minispecificatie (niet meer dan 20-30 regels).

Bij het construeren van een DPD-hiërarchie moet men pas overgaan tot de detaillering van processen nadat de inhoud van alle stromen en gegevensopslagapparaten is bepaald, wat wordt beschreven met behulp van gegevensstructuren. Datastructuren zijn opgebouwd uit data-elementen en kunnen alternatieven, conditionals en iteraties bevatten. Voorwaardelijk voorkomen betekent dat deze component niet in de constructie aanwezig mag zijn. Alternatief betekent dat een van de genoemde elementen in de constructie kan worden opgenomen. Iteratie betekent het invoeren van een willekeurig aantal elementen in het opgegeven bereik. Voor elk data-element kan het type (continue of discrete data) worden gespecificeerd. Voor continue gegevens kunnen de meeteenheid (kg, cm, enz.), het bereik van waarden, de nauwkeurigheid van de weergave en de vorm van fysieke codering worden gespecificeerd. Voor discrete gegevens kan een tabel met geldige waarden worden opgegeven.

Na het bouwen van een compleet systeemmodel moet dit worden geverifieerd (gecontroleerd op volledigheid en consistentie). In een compleet model moeten alle objecten (subsystemen, processen, datastromen) worden beschreven en gedetailleerd. De geïdentificeerde niet-gedetailleerde objecten moeten worden gedetailleerd door terug te keren naar de vorige ontwikkelingsstappen. In een consistent model moeten alle gegevensstromen en gegevensarchieven zich houden aan de regel van het bewaren van informatie: alle gegevens die ergens binnenkomen, moeten worden gelezen en alle gelezen gegevens moeten worden geschreven.

2.4. Datamodellering

IDEF1X - datamodellering en relationele database-ontwerpmethode. Het behoort tot het type methodologieën "entiteit-relatie" ( ER-Entiteit-relatie ), worden entiteiten hier echter niet als echte objecten opgevat, maar als hun typen die gemeenschappelijke eigenschappen. Relaties tussen entiteiten zijn complexer. Hierdoor kan informatie worden opgeslagen in de vorm van een abstract schema (semantisch model) dat de symbolen die in de computer zijn opgeslagen relateert aan de echte wereld en er een waarheidsgetrouwe weergave van is. Deze manier van informatie opslaan is relatief onafhankelijk, "neutraal" en stelt u in staat om antwoord te krijgen op verschillende gebruikersvragen over de eigenschappen van de in het model beschreven omgeving. De IDEF1X-standaard werd uitgebracht in 1993 ( FIPS 184).

2.4.1. Barker's case-methode

Het doel van datamodellering is om de IS-ontwikkelaar te voorzien van een conceptueel databaseschema in de vorm van een enkel model of meerdere lokale modellen die relatief eenvoudig kunnen worden toegewezen aan elk databasesysteem.

De meest gebruikte tool voor gegevensmodellering is Entity Relationship Diagrams (ERD's). Met hun hulp worden objecten (entiteiten) die belangrijk zijn voor het vakgebied, hun eigenschappen (attributen) en relaties met elkaar (links) bepaald. ERD's worden rechtstreeks gebruikt om relationele databases te ontwerpen.

De ERD-notatie werd voor het eerst geïntroduceerd door P. Chen en verder ontwikkeld door Barker. De Barker-methode zal worden gepresenteerd aan de hand van het voorbeeld van het modelleren van de activiteiten van een autohandelsbedrijf. Hieronder volgen fragmenten uit een interview met het personeel van het bedrijf.

Algemeen directeur: een van de belangrijkste verantwoordelijkheden is het onderhoud van auto-eigendommen. Hij moet weten hoeveel er betaald wordt voor de auto's en wat de overheadkosten zijn. Met deze informatie kan hij een lagere prijs instellen waarvoor hij deze instantie zou kunnen verkopen. Daarnaast is hij verantwoordelijk voor de verkopers en moet hij weten wie wat verkoopt en hoeveel auto's elk van hen heeft verkocht.

Verkoper: Hij moet weten welke prijs hij moet vragen en wat de bodemprijs is waartegen een transactie kan worden gedaan. Daarnaast heeft hij basisinformatie over de auto's nodig: bouwjaar, merk, model, etc.

Beheerder: Het is zijn taak om contracten op te stellen, waarvoor informatie over de koper, auto en verkoper nodig is, aangezien het de contracten zijn die verkoperscommissies voor verkopen verdienen.

De eerste modelleringsstap is het extraheren van informatie uit het interview en het extraheren van entiteiten.

Entiteit - een echt of denkbeeldig object dat essentieel is voor het betreffende onderwerp, waarover informatie moet worden opgeslagen (Figuur 2.18).

Rijst. 2.18. Grafische afbeelding entiteiten

Elke entiteit moet een unieke identificatie hebben. Elke entiteitsinstantie moet uniek identificeerbaar zijn en zich onderscheiden van alle andere instanties van dat entiteitstype. Elke entiteit moet enkele eigenschappen hebben:

elke entiteit moet een unieke naam hebben en dezelfde interpretatie moet altijd van toepassing zijn op dezelfde naam. Dezelfde interpretatie kan niet van toepassing zijn op verschillende namen, tenzij het aliassen zijn;

een entiteit heeft een of meer attributen die ofwel tot de entiteit behoren ofwel via een relatie worden geërfd;

een entiteit heeft een of meer attributen die elke entiteitsinstantie op unieke wijze identificeren;

elke entiteit kan een willekeurig aantal relaties hebben met andere modelentiteiten.

Verwijzend naar de bovenstaande interviewfragmenten, is het duidelijk dat de entiteiten die kunnen worden geïdentificeerd met de algemeen directeur motorvoertuigen en verkopers zijn. De verkoper geeft om de auto's en de gegevens met betrekking tot hun verkoop. Voor de beheerder zijn kopers, auto's, verkopers en contracten belangrijk. Op basis hiervan worden 4 entiteiten onderscheiden (auto, verkoper, koper, contract) die als volgt in het diagram zijn weergegeven (Figuur 2.19).

Rijst. 2.19.

De volgende modelleringsstap is de identificatie van links.

Relatie - een benoemde associatie tussen twee entiteiten die van belang is voor het betreffende vakgebied. Een relatie is een associatie tussen entiteiten, waarbij in de regel elke instantie van een entiteit, de bovenliggende entiteit genaamd, is gekoppeld aan een willekeurig (inclusief nul) aantal instanties van de tweede entiteit, de onderliggende entiteit genaamd, en elke instantie van de onderliggende entiteit is precies gekoppeld aan één instantie van de bovenliggende entiteit. Een instantie van een onderliggende entiteit kan dus alleen bestaan ​​als de bovenliggende entiteit bestaat.

Een link kan een naam krijgen die wordt uitgedrukt door de grammaticale omzet van het werkwoord en naast de linkregel worden geplaatst. De naam van elke relatie tussen twee gegeven entiteiten moet uniek zijn, maar relatienamen in het model hoeven niet uniek te zijn. De naam van een relatie wordt altijd gevormd vanuit het oogpunt van de bovenliggende entiteit, dus een zin kan worden gevormd door de naam van de bovenliggende entiteit, de naam van de relatie, de graaduitdrukking en de naam van de onderliggende entiteit te combineren.

De relatie van de verkoper tot het contract kan bijvoorbeeld als volgt worden uitgedrukt:

de verkoper kan beloond worden voor 1 of meerdere contracten;

het contract moet worden gestart door precies één verkoper.

De mate van verbondenheid en betrokkenheid wordt als volgt grafisch weergegeven (Figuur 2.20).

Rijst. 2.20.

Dus 2 zinnen die de relatie van de verkoper met het contract beschrijven, worden als volgt grafisch weergegeven (Figuur 2.21).

Rijst. 2.21.

Nadat we ook de relaties van andere entiteiten hebben beschreven, krijgen we het volgende schema (Figuur 2.22).

Rijst. 2.22.

De laatste modelleringsstap is attribuutidentificatie.

Attribuut - elk kenmerk van een entiteit dat significant is voor het onderwerp in kwestie en bedoeld is voor kwalificatie, identificatie, classificatie, kwantitatieve kenmerken of uitdrukking van de toestand van de entiteit. Een attribuut vertegenwoordigt een type kenmerk of eigenschap die is gekoppeld aan een reeks echte of abstracte objecten (mensen, plaatsen, gebeurtenissen, toestanden, ideeën, paren objecten, enz.). Een attribuutinstantie is een specifiek kenmerk van een afzonderlijk element van een set. Een attribuutinstantie wordt gedefinieerd door het kenmerktype en zijn waarde, de attribuutwaarde genoemd. In het ER-model zijn attributen gekoppeld aan specifieke entiteiten. Een entiteitsinstantie moet dus een enkele gedefinieerde waarde hebben voor het bijbehorende kenmerk.

Een attribuut kan verplicht of optioneel zijn (Figuur 2.23). Verplicht betekent dat het attribuut geen null-waarden mag hebben. Een attribuut kan ofwel beschrijvend zijn (d.w.z. een normale entiteitsdescriptor) of deel uitmaken van een unieke identifier (primaire sleutel).

Unieke identificatoris een attribuut of verzameling attributen en/of relaties die zijn ontworpen om elke instantie van een bepaald entiteitstype op unieke wijze te identificeren. In het geval van volledige identificatie wordt elke instantie van een bepaald type entiteit volledig geïdentificeerd door zijn eigen sleutelattributen, anders zijn attributen van een andere moederentiteit ook betrokken bij de identificatie (Figuur 2.24).

Rijst. 2.23.

Rijst. 2.24.

Elk kenmerk wordt geïdentificeerd door een unieke naam, uitgedrukt door een zelfstandig naamwoord dat het kenmerk beschrijft dat het kenmerk vertegenwoordigt. Attributen worden weergegeven als een lijst met namen binnen een bijbehorend entiteitsblok, waarbij elk attribuut een aparte regel inneemt. Attributen die de primaire sleutel definiëren, worden boven aan de lijst geplaatst en zijn gemarkeerd met een "#"-teken.

Elke entiteit moet ten minste één mogelijke sleutel hebben. Een mogelijke entiteitssleutel is een of meer attributen waarvan de waarden elke entiteitsinstantie op unieke wijze identificeren. Als er meerdere mogelijke sleutels zijn, wordt één ervan aangewezen als de primaire sleutel en de rest als alternatieve sleutels.

Rekening houdend met de beschikbare informatie vullen we het eerder opgestelde schema (Figuur 2.25) aan.

Naast de genoemde basisstructuren kan het datamodel nog een aantal aanvullende bevatten.

Subtypen en supertypen:één entiteit is een generaliserend concept voor een groep vergelijkbare entiteiten (figuur 2.26).

Wederzijds uitsluitende relaties:elke entiteitsinstantie neemt slechts aan één relatie deel uit de groep van wederzijds uitsluitende relaties (Figuur 2.27).

Rijst. 2.25.

Rijst. 2.26. Subtypen en supertypen

Rijst. 2.27. Wederzijds uitsluitende relaties

Recursieve link:een entiteit kan aan zichzelf worden gerelateerd (figuur 2.28).

Niet-overdraagbare links:een instantie van een entiteit kan niet van de ene relatie-instantie naar de andere worden verplaatst (Figuur 2.29).

Rijst. 2.28. recursieve relatie

Rijst. 2.29. Niet-verplaatsbare verbinding

2.4.2. Methodologie IDEF1

De IDEF1-methode, ontwikkeld door T. Ramey, is ook gebaseerd op de benadering van P. Chen en stelt u in staat een gegevensmodel te bouwen dat equivalent is aan een relationeel model in de derde normaalvorm. Op dit moment is, op basis van de verbetering van de IDEF1-methodologie, de nieuwe versie, de IDEF1X-methodologie, gecreëerd. IDEF1X is ontworpen met het oog op leergemak en automatisering. IDEF1X-diagrammen worden gebruikt door een aantal veelgebruikte CASE-tools (bijv. ERwin, Design/IDEF).

Een entiteit in de IDEF1X-methodologie is onafhankelijk van identifiers, of eenvoudigweg onafhankelijk, als elke entiteitsinstantie uniek kan worden geïdentificeerd zonder de relatie met andere entiteiten te definiëren. Van een entiteit wordt gezegd dat ze afhankelijk is van identifiers of eenvoudigweg afhankelijk is als de unieke identificatie van een instantie van een entiteit afhangt van de relatie met een andere entiteit (Figuur 2.30).

Rijst. 2.30. Essenties

Elke entiteit krijgt een unieke naam en nummer toegewezen, gescheiden door een schuine streep "/" en boven het blok geplaatst.

Een relatie kan verder worden gedefinieerd door een graad of kardinaliteit op te geven (het aantal instanties van onderliggende entiteiten dat kan bestaan ​​voor elke instantie van de bovenliggende entiteit). In IDEF1X kunnen de volgende kardinaliteiten worden uitgedrukt:

elke instantie van een bovenliggende entiteit kan nul, een of meer instanties van een onderliggende entiteit hebben;

aan elke instantie van een bovenliggende entiteit moet ten minste één instantie van een onderliggende entiteit zijn gekoppeld;

aan elke instantie van een bovenliggende entiteit mag niet meer dan één instantie van een onderliggende entiteit zijn gekoppeld;

elke instantie van de bovenliggende entiteit is gekoppeld aan een vast aantal instanties van de onderliggende entiteit.

Als een instantie van een onderliggende entiteit op unieke wijze wordt bepaald door zijn relatie met de bovenliggende entiteit, wordt de relatie identificerend genoemd, anders wordt deze niet-identificerend genoemd.

De relatie wordt weergegeven door een lijn tussen de bovenliggende entiteit en de onderliggende entiteit met een punt aan het einde van de lijn bij de onderliggende entiteit. Het verbindingsvermogen wordt aangegeven zoals getoond in Fig. 2.31 (standaard vermogen - N).

Rijst. 2.31. Communicatiekracht:

Een identificerende relatie tussen een bovenliggende entiteit en een onderliggende entiteit wordt weergegeven als een ononderbroken lijn (Figuur 2.32). Een onderliggende entiteit in een identificerende relatie is een identiteitsafhankelijke entiteit. De bovenliggende entiteit in een identificerende relatie kan onafhankelijk of afhankelijk zijn van de identifier (dit wordt bepaald door haar relaties met andere entiteiten).

Rijst. 2.32. Identificerende link

De stippellijn geeft een niet-identificerende relatie weer (Figuur 2.33). Een onderliggende entiteit in een niet-identificerende relatie zal identifier-onafhankelijk zijn, tenzij het ook een onderliggende entiteit is in een identificerende relatie.

Rijst. 2.33. Niet-identificerende relatie

Attributen worden weergegeven als een lijst met namen binnen een entiteitsblok. Attributen die de primaire sleutel definiëren, worden bovenaan de lijst geplaatst en van andere attributen gescheiden door een horizontale balk (figuur 2.34).

Rijst. 2.34. Attributen en primaire sleutels

Entiteiten kunnen ook externe sleutels hebben (Foreign Key), die kunnen worden gebruikt als een deel van of het hele primaire of niet-sleutelattribuut. Een refererende sleutel wordt weergegeven door attribuutnamen in een entiteitblok te plaatsen, gevolgd door de letters FK tussen haakjes (Figuur 2.35).

Rijst. 2.35. Voorbeelden van buitenlandse sleutels

2.5. Een voorbeeld van een structurele aanpak

2.5.1. Beschrijving van het vakgebied

V dit voorbeeld Er wordt gebruik gemaakt van de Yourdon-methodiek die is geïmplementeerd in de Vantage Team Builder CASE-tool.

Het onderwerpgebied is de functiebeschrijving van de videotheek die verzoeken ontvangt voor films van klanten en tapes die door klanten worden geretourneerd. Aanvragen worden beoordeeld door de administratie van de videotheek aan de hand van informatie over klanten, films en tapes. Deze controleert en actualiseert de lijst met gehuurde banden en controleert de lidmaatschapsgegevens van de bibliotheek. De administratie controleert ook de teruggave van tapes met behulp van informatie over films, tapes en een lijst met gehuurde tapes, die wordt bijgewerkt. Het verwerken van filmverzoeken en taperetouren omvat het volgende: Als de klant geen lid is van de bibliotheek, komt de klant niet in aanmerking voor de lening. Indien de benodigde film aanwezig is, informeert de administratie de opdrachtgever over de huurprijs. Als de klant echter de deadline voor het retourneren van de banden die hij heeft overschreden, mag hij geen nieuwe films meer meenemen. Bij het inleveren van het bandje berekent de administratie de huur plus boetes bij laattijdige inlevering.

De videotheek krijgt nieuwe banden van haar leveranciers. Wanneer nieuwe banden in de bibliotheek aankomen, wordt de nodige informatie daarover opgenomen. De informatie over het lidmaatschap van de bibliotheek wordt gescheiden gehouden van de bandhuurrecords.

De bibliotheekadministratie stelt voor een bepaalde periode regelmatig rapportages op over bibliotheekleden, tapeleveranciers, uitleen van bepaalde tapes en door de bibliotheek aangekochte tapes.

2.5.2. Project organisatie

Het hele project is opgedeeld in 4 fasen: analyse, globaal ontwerp (systeemarchitectuurontwerp), gedetailleerd ontwerp en implementatie (programmering).

De analysefase bouwt het Milieumodel op. Het bouwen van een omgevingsmodel omvat:

• analyse van systeemgedrag (bepalen van het doel van IS, bouwen van een initieel contextueel datastroomdiagram (DFD) en genereren van een gebeurtenislijstmatrix (ELM), bouwen van contextdiagrammen);
• data-analyse (bepalen van de samenstelling van datastromen en het construeren van datastructuurdiagrammen (DSD), het construeren van een globaal datamodel in de vorm van een ER-diagram).

Het doel van de IS bepaalt de afspraak tussen ontwerpers en klanten over het doel van de toekomstige IS, een algemene beschrijving van de IS voor de ontwerpers zelf en de grenzen van de IS. De toewijzing wordt vastgelegd als tekstcommentaar in het "null"-proces van het contextdiagram.

In dit geval is het doel van IP bijvoorbeeld als volgt geformuleerd: het onderhouden van een database van bibliotheekleden, films, verhuur en leveranciers. Tegelijkertijd moet de bibliotheekdirectie verschillende soorten rapportages kunnen ontvangen om hun taken te kunnen vervullen.

Alvorens een contextuele DFD te bouwen, is het noodzakelijk om externe gebeurtenissen (externe objecten) te analyseren die de werking van de bibliotheek beïnvloeden. Deze objecten interageren met de IS door er informatie mee uit te wisselen.

Uit de beschrijving van het vakgebied volgt dat de volgende groepen mensen bij het proces van de bibliotheek betrokken zijn: klanten, leveranciers en management. Deze groepen zijn externe objecten. Ze hebben niet alleen interactie met het systeem, maar definiëren ook de grenzen ervan en worden op de initiële contextuele DFD afgebeeld als terminators (externe entiteiten).

Het initiële contextdiagram wordt getoond in figuur 2.42. In tegenstelling tot de Gane/Sarson-notatie worden externe entiteiten aangeduid met regelmatige rechthoeken en processen met cirkels.

Rijst. 2.42. Initieel contextdiagram

De lijst met gebeurtenissen is opgebouwd in de vorm van een matrix (ELM) en beschrijft de verschillende acties van externe entiteiten en de reactie van de IS daarop. Deze acties zijn externe gebeurtenissen die van invloed zijn op de bibliotheek. Er zijn de volgende soorten evenementen:

Alle acties worden gemarkeerd als normale gegevens. Deze gegevens zijn gebeurtenissen die de IS direct waarneemt, bijvoorbeeld een wijziging van het adres van de klant, die onmiddellijk moet worden geregistreerd. Ze verschijnen in DFD als de inhoud van gegevensstromen.

De gebeurtenislijstmatrix ziet er als volgt uit:

Om de analyse van het functionele aspect van het systeemgedrag te completeren, wordt een compleet contextdiagram gebouwd, inclusief een nulniveaudiagram. Tegelijkertijd wordt het "bibliotheek"-proces opgedeeld in 4 processen, die de belangrijkste soorten administratieve activiteiten van de bibliotheek weerspiegelen. De bestaande "abstracte" datastromen tussen terminators en processen worden omgezet in stromen die data-uitwisseling op een meer concreet niveau representeren. De lijst met gebeurtenissen laat zien welke stromen er op dit niveau zijn: elke gebeurtenis uit de lijst moet een bepaalde stroom vormen (een gebeurtenis vormt een invoerstroom, een reactie vormt een uitvoerstroom). Een "abstracte" draad kan worden opgesplitst in meer dan één "betonnen" draad.

In de DFD die wordt weergegeven in Afbeelding 2.43, is de "bibliotheek"-datastore globaal of abstract idee gegevensopslag.

Een analyse van het functionele aspect van het gedrag van het systeem geeft een idee van de uitwisseling en transformatie van gegevens in het systeem. De relatie tussen 'abstracte' datastromen en 'concrete' datastromen in het nulniveaudiagram wordt uitgedrukt in datastructuurdiagrammen (Figuur 2.44).

In de analysefase wordt een globaal datamodel gebouwd, gepresenteerd in de vorm van een entiteit-relatiediagram (Figuur 2.45).

Tussen verschillende types diagrammen zijn er de volgende relaties:

• ELM-DFD: gebeurtenissen - invoerstromen, reacties - uitvoerstromen
• DFD-DSD: gegevensstromen - gegevensstructuren op het hoogste niveau
• DFD-ERD: gegevensverzamelaars - ER-diagrammen
• DSD-ERD: Gegevensstructuren op laag niveau - Entiteitskenmerken

In de architectuurontwerpfase wordt een onderwerpsmodel gebouwd. Het proces van het bouwen van een onderwerpmodel omvat:

• een gedetailleerde beschrijving van de werking van het systeem;
• verdere analyse van de gebruikte data en het opstellen van een logisch datamodel voor het latere ontwerp van de database;
• het bepalen van de structuur van de gebruikersinterface, de specificatie van formulieren en de volgorde waarin ze verschijnen;
• verduidelijking van gegevensstroomdiagrammen en de lijst met gebeurtenissen, selectie van interactieve en niet-interactieve tussen de processen op een lager niveau, definitie van minispecificaties voor hen.

Rijst. 2,43. Context diagram

Rijst. 2.44. Gegevensstructuren diagram

De resultaten van architectuurontwerp zijn:

• procesmodel (systeemarchitectuurdiagrammen (SAD) en minispecificaties in een gestructureerde taal);
• datamodel (ERD en ERD subschema);
• gebruikersinterfacemodel (classificatie van processen in interactieve en niet-interactieve functies, formuliervolgordediagram (FSD - Form Sequence Diagram), dat laat zien welke formulieren in de applicatie verschijnen en in welke volgorde. De FSD legt de set en de structuur van schermformulieroproepen vast. FSD-diagrammen vormen een hiërarchie, met daarbovenop: belangrijkste vorm applicatie die het subsysteem implementeert. Op het tweede niveau zijn er formulieren die de processen van het lagere niveau van de functionele structuur implementeren, vastgelegd op de SAD-diagrammen.

Rijst. 2.45. Entiteit-relatiediagram

Tijdens de detailontwerpfase wordt een modulair model gebouwd. Een modulair model wordt opgevat als een reëel model van het toegepaste systeem dat wordt ontworpen. Het bouwproces omvat:

• verfijning van het databasemodel voor latere generatie van SQL-statements;
• verfijning van de gebruikersinterfacestructuur;
• bouw blokdiagrammen, die de logica van de gebruikersinterface en het bedrijfslogicamodel (Structure Charts Diagram - SCD) weerspiegelen en aan formulieren koppelen.

De resultaten van een gedetailleerd ontwerp zijn:

• procesmodel (structurele diagrammen van interactieve en niet-interactieve functies);
• datamodel (definitie in ERD van alle noodzakelijke parameters voor toepassingen);
• gebruikersinterfacemodel (Form Sequence Diagram (FSD) dat laat zien welke formulieren in de applicatie voorkomen en in welke volgorde, de relatie tussen elke vorm en een specifiek structureel diagram, de relatie tussen elke vorm en een of meer entiteiten in de ERD).

Tijdens de implementatiefase wordt een implementatiemodel gebouwd. Het bouwproces omvat:

• genereren van SQL-instructies die de structuur van de doeldatabase definiëren (tabellen, indexen, integriteitsbeperkingen);
• verfijning van blokdiagrammen (SCD) en vormvolgordediagrammen (FSD) gevolgd door het genereren van applicatiecode.

Op basis van de analyse van datastromen en de interactie van processen met datawarehouses, wordt de uiteindelijke toewijzing van subsystemen uitgevoerd (voorlopig had dit moeten gebeuren en vastgelegd in het stadium van het formuleren van eisen in de taakomschrijving). Bij het selecteren van subsystemen moet u zich laten leiden door het principe van functionele connectiviteit en het principe van minimalisatie informatie afhankelijkheid. Hierbij moet bedacht worden dat op basis van elementen van het subsysteem als processen en data in de ontwikkelfase, een applicatie gemaakt moet worden die zelfstandig kan functioneren. Aan de andere kant moet bij het groeperen van processen en gegevens in subsystemen rekening worden gehouden met de vereisten voor het configureren van het product, als deze tijdens de analysefase zijn geformuleerd.

CASE-tools maken het niet alleen mogelijk om de "juiste" producten te maken, maar ook om het "juiste" proces van hun creatie te bieden. Het belangrijkste doel van CASE is om het ontwerp van een IS te scheiden van de codering en de daaropvolgende ontwikkelingsfasen, en om alle details van de ontwikkelomgeving en de werking van de IS voor ontwikkelaars te verbergen. Bij het gebruik van CASE-technologieën veranderen alle stadia van de softwarelevenscyclus (hierover wordt hieronder meer besproken) van het informatiesysteem, waarbij de grootste veranderingen betrekking hebben op de stadia van analyse en ontwerp. De meeste bestaande CASE-tools zijn gebaseerd op structurele (meestal) of objectgeoriënteerde analyse- en ontwerpmethodologieën, waarbij specificaties in de vorm van diagrammen of teksten worden gebruikt om externe vereisten, relaties tussen systeemmodellen, dynamiek van systeemgedrag en software-architecturen te beschrijven. Dergelijke methodologieën bieden een rigoureuze en visuele beschrijving van het ontworpen systeem, dat begint met het algemene overzicht en vervolgens met details, en een hiërarchische structuur krijgt met alle een groot aantal niveaus. CASE-technologieën worden met succes gebruikt om bijna alle soorten IS te bouwen, maar ze nemen een stabiele positie in op de volgende gebieden:

• 
  om de ontwikkeling van zakelijke en commerciële IS te verzekeren, is het wijdverbreide gebruik van CASE-technologieën te danken aan de massale aard van dit toepassingsgebied, waarin CASE niet alleen wordt gebruikt om IS te ontwikkelen, maar ook om systeemmodellen te creëren die helpen bij het oplossen van de problemen van strategische planning, financieel beheer, het bepalen van het beleid van bedrijven, opleiding van personeel en anderen (deze richting heeft zijn eigen naam gekregen - bedrijfsanalyse);
• 
  ontwikkeling van systeem- en controle-IS. Het actieve gebruik van CASE-technologieën hangt samen met de grote complexiteit van dit probleem en met de wens om de efficiëntie van het werk te verhogen.

Naast het automatiseren van structurele methodologieën en daardoor de mogelijkheid om moderne methodes van systeem- en software-engineering toe te passen, hebben CASE-tools de volgende belangrijkste voordelen:

• 
  de kwaliteit van het gecreëerde IS verbeteren door middel van automatische sturing (voornamelijk projectbeheersing);
• 
  geef een korte tijd de tijd om een ​​prototype van het toekomstige systeem te maken, waarmee u het verwachte resultaat in een vroeg stadium kunt evalueren;
• 
  het ontwerp- en ontwikkelingsproces versnellen;
• 
  de ontwikkelaar bevrijden van routinematig werk, waardoor hij zich volledig kan concentreren op het creatieve deel van de ontwikkeling;
• 
  ondersteuning van de ontwikkeling en het onderhoud van de ontwikkeling;
• 
  ondersteuning van technologieën voor hergebruik van ontwikkelingscomponenten.

Het moet duidelijk zijn dat het succesvolle gebruik van CASE-tools onmogelijk is zonder begrip van de onderliggende technologie waarop deze tools zijn gebaseerd. Op zichzelf zijn CASE-softwaretools hulpmiddelen voor het automatiseren van de processen voor het ontwerpen en onderhouden van informatiesystemen. Zonder de IS-ontwerpmethodologie te begrijpen, is het onmogelijk om CASE-tools te gebruiken.
^

Kenmerken van moderne CASE-tools

De meest tijdrovende stadia van IS-ontwikkeling zijn de stadia van analyse en ontwerp, waarin CASE-tools de kwaliteit van de genomen technische beslissingen en de voorbereiding van projectdocumentatie waarborgen. Tegelijkertijd spelen methoden voor visuele presentatie van informatie een belangrijke rol. Dit omvat de constructie van structurele of andere diagrammen in realtime, het gebruik van een divers kleurenpalet en end-to-end controle van syntactische regels. Met grafische modelleringstools voor het vakgebied kunnen ontwikkelaars de bestaande IS visueel bestuderen en opnieuw opbouwen in overeenstemming met de doelen en bestaande beperkingen.

De categorie CASE-tools omvat zowel relatief goedkope systemen voor personal computers met zeer beperkte mogelijkheden als dure systemen voor heterogene computerplatforms en besturingsomgevingen. Zo omvat de moderne softwaremarkt ongeveer 300 verschillende CASE-tools, waarvan de krachtigste, op de een of andere manier, door bijna alle toonaangevende westerse bedrijven worden gebruikt.

Gewoonlijk omvatten CASE-tools elke softwaretool die een of andere reeks IP-levenscyclusprocessen automatiseert en de volgende hoofdkenmerken heeft:

• 
  krachtige grafische hulpmiddelen voor het beschrijven en documenteren van IS, een handige interface met de ontwikkelaar en het ontwikkelen van zijn creatieve capaciteiten;
• 
  integratie van afzonderlijke componenten van CASE-tools, waardoor het IS-ontwikkelingsproces beheersbaar wordt;
• 
  met behulp van een speciaal georganiseerde repository van projectmetadata (repository). Een geïntegreerde CASE-tool (of een set tools die de volledige levenscyclus van een IP ondersteunt) bevat de volgende componenten:
• 
  een repository die de basis vormt van een CASE-tool. Het moet zorgen voor de opslag van versies van het project en zijn individuele componenten, de synchronisatie van de ontvangst van informatie van verschillende ontwikkelaars tijdens groepsontwikkeling, de controle van metadata voor volledigheid en consistentie;
• 
  grafische analyse- en ontwerptools waarmee hiërarchisch gekoppelde diagrammen (DFD, ERD, enz.) kunnen worden gemaakt en bewerkt die IS-modellen vormen;
• 
  applicatie-ontwikkelingstools, waaronder 4GL-talen en codegenerators;
• 
  hulpprogramma's voor configuratiebeheer;
• 
  middel van documentatie;
• 
  testinstrumenten;
• 
  hulpmiddelen voor projectbeheer;
• 
  re-engineering tools.

• 
  toegepaste methodieken en modellen van systemen en databases;
• 
  mate van integratie met het DBMS;
• 
  beschikbare platformen.

• 
  analysetools (Hoofdletters) ontworpen voor het bouwen en analyseren van domeinmodellen (Design/IDEF (Meta Software), BPWin (Logic Works));
• 
  analyse- en ontwerptools (Middle CASE), ondersteunt de meest voorkomende ontwerpmethodologieën en wordt gebruikt om ontwerpspecificaties te maken (Vantage Team Builder (Cayenne), Designer / 2000 (Oracle), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE. Analist (Macro - projecten)). De output van dergelijke tools zijn specificaties van systeemcomponenten en interfaces, systeemarchitectuur, algoritmen en datastructuren;
• 
  hulpprogramma's voor databaseontwerp, het bieden van gegevensmodellering en het genereren van databaseschema's (meestal in SQL) voor de meest voorkomende DBMS. Deze omvatten ERwin (Logic Works). S-Designor (SDP) en DataBase Designer (Oracle). Database-ontwerptools zijn ook opgenomen in de Vantage Team Builder-, Designer/2000-, Silverrun- en PRO-IV CASE-tools;
• 
  applicatie-ontwikkeltools. Deze omvatten 4GL-tools (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (Oracle), New Era (Informix), SQL Windows (Gupta), Delphi (Borland), enz.) en generatorcodes opgenomen in Vantage Team Builder, PRO-IV en gedeeltelijk in Silverrun;
• 
  re-engineering tools, het verstrekken van de analyse van programmacodes en databaseschema's en de vorming op basis van verschillende modellen en ontwerpspecificaties. Databaseschema-analyse en ERD-generatietools zijn opgenomen in Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin en S-Designor. Op het gebied van programmacode-analyse worden objectgeoriënteerde CASE-tools die re-engineering van C++-programma's (Rational Rose (Rational Software), Object Team (Cayenne)) bieden, het meest gebruikt. Typen helpers zijn onder meer:
• 
  tools voor projectplanning en -beheer (SE Companion, Microsoft Project, enz.);
• 
  configuratiebeheertools (PVCS (Intersolv));
• 
  testtools (Quality Works (Segue Software));
• 
  documentatietools (SoDA (Rational Software)).

• 
  Zilverloop;
• 
  Ontwerper/2000;
• 
  Vantage Team Builder (Westmount I-CASE);
• 
  ERwin+BPwin;
• 
  S Ontwerper;
• 
  CASE Analist.

Laten we de belangrijkste kenmerken van CASE-tools karakteriseren aan de hand van het veelgebruikte Silverrun-systeem.

De Silverrun CASE-tool van het Amerikaanse bedrijf Computer Systems Advisers, Inc. (CSA) wordt gebruikt voor de analyse en het ontwerp van business-class IS en is meer gericht op het spiraalmodel van de levenscyclus. Het is toepasbaar om elke methodologie te ondersteunen die gebaseerd is op de afzonderlijke constructie van functionele en informatiemodellen(gegevensstroomdiagrammen en entiteit-relatiediagrammen).

Afstemming op een specifieke methodologie wordt geboden door de vereiste grafische notatie van modellen en een set regels voor het controleren van ontwerpspecificaties te kiezen. Het systeem heeft kant-en-klare instellingen voor de meest voorkomende methodieken: DATARUN (hoofdmethodiek ondersteund door Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Voor elk concept dat in het project wordt geïntroduceerd, is het mogelijk om uw eigen descriptoren toe te voegen. De architectuur van Silverrun stelt u in staat uw ontwikkelomgeving naar behoefte te laten groeien.

Silverrun heeft een modulaire structuur en bestaat uit vier modules, die elk een onafhankelijk product zijn en zonder verbinding met de andere kunnen worden gekocht en gebruikt modulen.

module bedrijfsprocesmodellen bouwen in de vorm van datastroomdiagrammen (BPM - Business Process Modeler) simuleert u het functioneren van de organisatie die wordt onderzocht of de IS die wordt gecreëerd. De BPM-module biedt de mogelijkheid om te werken met modellen van grote complexiteit: automatisch hernummeren, werken met de procesboom (inclusief visueel slepen en neerzetten van takken), losmaken en bevestigen van modelonderdelen voor collectieve ontwikkeling. Grafieken kunnen worden getekend in verschillende vooraf gedefinieerde notaties, waaronder Yourdon/DeMarco en Gane/Sarson. Het is ook mogelijk om uw eigen notaties te maken, inclusief het toevoegen van door de gebruiker gedefinieerde velden aan het aantal descriptoren dat in het diagram wordt weergegeven.

module conceptuele gegevensmodellering(ERX - Entity-Relationship eXpert) biedt de constructie van entiteit-relatie datamodellen die niet gebonden zijn aan een specifieke implementatie. Deze module heeft een ingebouwde expert systeem, waarmee u een correct genormaliseerd gegevensmodel kunt maken door zinvolle vragen over de relatie van gegevens te beantwoorden. Het is mogelijk om automatisch een datamodel op te bouwen uit beschrijvingen van datastructuren. Analyse van de functionele afhankelijkheden van attributen maakt het mogelijk om te controleren of het model voldoet aan de vereisten van de derde normaalvorm en om de implementatie ervan te verzekeren. Het gevalideerde model wordt doorgegeven aan de RDM.

module relationele modellering(RDM - Relational Data Modeler) stelt u in staat om gedetailleerde entiteit-relatiemodellen te creëren die bedoeld zijn voor implementatie in een relationele database. Deze module documenteert alle structuren met betrekking tot het bouwen van een database: indexen, triggers, opgeslagen procedures, enz. De flexibele notatie en uitbreidbaarheid van de repository stellen u in staat om met elke methodologie te werken. De mogelijkheid om subschema's te maken is in overeenstemming met de ANSI SPARC-benadering voor het weergeven van een databaseschema. In de taal van subschema's worden zowel gedistribueerde verwerkingsknooppunten als gebruikersviews gemodelleerd. Deze module biedt het ontwerp en de volledige documentatie van relationele databases.

^ Opslagplaatsbeheerder werkgroep (WRM - Workgroup Repository Manager) wordt gebruikt als een datadictionary voor het opslaan van informatie die voor alle modellen geldt, en biedt ook integratie van Silverrun-modules in een enkele ontwerpomgeving.

De prijs die betaald moet worden voor de hoge flexibiliteit en verscheidenheid aan visuele hulpmiddelen voor het bouwen van modellen is zo'n nadeel van Silverrun als het gebrek aan strikte wederzijdse controle tussen de componenten van verschillende modellen (bijvoorbeeld de mogelijkheid om automatisch wijzigingen tussen DFD's door te geven). verschillende niveaus ontleding). Er moet echter worden opgemerkt dat dit nadeel alleen significant kan zijn in het geval van gebruik van het cascademodel van de levenscyclus van een IS.

Voor het automatisch genereren van databaseschema's heeft Silverrun bruggen naar de meest voorkomende DBMS: Oracle, Informix, DB2, Ingres, Progress, SQL-server, SQLBase, Sybase. Om gegevens over te brengen naar applicatie-ontwikkeltools, zijn er bruggen naar 4GL-talen: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Met alle bridges kan Silverrun RDM informatie laden uit de mappen van de corresponderende DBMS- of 4GL-talen. Hiermee kunt u nieuwe platforms documenteren, herontwerpen of overbrengen naar nieuwe platforms die al in operationele databases en applicatiesystemen aanwezig zijn. Bij gebruik van een bridge breidt Silverrun zijn interne repository uit met doelsysteemspecifieke attributen. Na het definiëren van de waarden van deze attributen, brengt de applicatiegenerator ze over naar de interne directory van de ontwikkelomgeving of gebruikt ze bij het genereren van SQL-code. Het is dus mogelijk om de database-engine volledig te definiëren met behulp van alle functies van een bepaald DBMS: triggers, opgeslagen procedures, referentiële integriteitsbeperkingen. Bij het maken van een 4GL-toepassing worden de gegevens die vanuit de Silverrun-repository zijn gemigreerd, gebruikt om automatisch interface-objecten te genereren of om ze snel handmatig te maken.

Om gegevens uit te wisselen met andere ontwerpautomatiseringstools, gespecialiseerde procedures te creëren voor het analyseren en verifiëren van ontwerpspecificaties en om gespecialiseerde rapporten op te stellen in overeenstemming met verschillende standaarden, heeft Silverrun drie manieren om ontwerpinformatie naar externe bestanden te sturen:

• 
  meldsysteem. Door de inhoud van het rapport in de repository te definiëren, is het mogelijk om een ​​rapport naar een tekstbestand te sturen. Dit bestand kan vervolgens in een teksteditor worden geladen of in een ander rapport worden opgenomen;
• 
  export/import systeem. Voor meer volledige controle over de structuur van bestanden in het export-/importsysteem is het mogelijk om niet alleen de inhoud van het exportbestand te definiëren, maar ook scheidingstekens voor records, velden in records, markeringen voor het begin en einde van tekstvelden. Bestanden met de opgegeven structuur kunnen niet alleen worden gegenereerd, maar ook worden geüpload naar de repository. Hierdoor is het mogelijk om gegevens uit te wisselen met verschillende systemen: andere CASE-tools, DBMS, teksteditors en spreadsheets;
• 
  de repository opslaan externe bestanden via ODBC-stuurprogramma's. Om toegang te krijgen tot repositorygegevens uit de meest gangbare databasebeheersystemen, is het mogelijk om alle projectinformatie direct op te slaan in het formaat van deze DBMS.

• 
  de standaardversie voor één gebruiker heeft een mechanisme voor het gecontroleerd splitsen en samenvoegen van modellen. Door het model in delen op te delen, kunt u deze naar verschillende ontwikkelaars distribueren. Na gedetailleerde verfijning worden de modellen gecombineerd tot enkele specificaties;
• 
  netwerkversie Met Silverrun kunt u gelijktijdig groepswerk uitvoeren met modellen die zijn opgeslagen in een netwerkrepository op basis van Oracle, Sybase of Informix DBMS. Tegelijkertijd kunnen meerdere ontwikkelaars met hetzelfde model werken, omdat objectvergrendeling op het niveau plaatsvindt individuele elementen modellen.

Naast het Silverrun-systeem zullen we het doel van andere populaire CASE-tools en hun groepen aangeven.

Vantage Team Builder is een geïntegreerd software, gericht op de implementatie van het cascademodel van de levenscyclus van IP en de ondersteuning van de volledige levenscyclus van IP.

Uniface 6.1 - een product van Compuware (VS) - is een ontwikkelomgeving voor grootschalige toepassingen in de "client-server"-architectuur.

Oracle's Designer/2000 2.0 CASE-tool is een geïntegreerde CASE-tool die, in combinatie met Developer/2000-tools voor applicatieontwikkeling, volledige IS-levenscyclusondersteuning biedt voor systemen die het Oracle DBMS gebruiken.

Het CASE/4/0-pakket (microTOOL GmbH), dat structurele tools omvat voor systeemanalyse, ontwerp en programmering, biedt ondersteuning voor de gehele ontwikkelingslevenscyclus (tot aan onderhoud), gebaseerd op een netwerkrepository die de integriteit van het project controleert en ondersteunt het gecoördineerde werk van al zijn deelnemers (systeemanalisten, ontwerpers, programmeurs).
^

Lokale fondsen

BPWin is een functionele modelleringstool die de IDEFO-methodologie implementeert. Een model in BPWin is een set SADT-diagrammen, die elk een afzonderlijk proces beschrijven en dit opsplitsen in stappen en subprocessen.

S-Designer 4.2 (Sybase/Powersoft) is een CASE-tool voor het ontwerpen van relationele databases. door hun eigen functionaliteit en kosten, het ligt dicht bij de ERWin CASE-tool, die verschilt in de notatie die extern in de diagrammen wordt gebruikt. S-Designer implementeert een standaard datamodelleringsmethodologie en genereert een databasebeschrijving voor DBMS zoals Oracle, Informix, Ingres, Sybase, DB2, Microsoft SQL server, enz.

CASE-Analyst 1.1 (Aytex) is praktisch de enige momenteel concurrerende binnenlandse CASE-tool voor functionele modellering en implementeert de constructie van datastroomdiagrammen in overeenstemming met de eerder beschreven methodologie.
^

Objectgeoriënteerde CASE-tools

Om CG-problemen op te lossen, worden methoden en hulpmiddelen gebruikt die zorgen voor de identificatie van de staat van de componenten, rekening houdend met het bereik van alle componenten en wijzigingen van het systeem als geheel, controle over wijzigingen aan de componenten, de structuur van het systeem en zijn functies, evenals gecoördineerd beheer van de ontwikkeling van functies en verbetering van kenmerkende systemen.

De meest gebruikte KU-tool is PVCS van Intersolv (VS), die een aantal onafhankelijke producten bevat: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder en PVCS Notify.
^

Documentatietools

Het SoDA-product is ontworpen om de ontwikkeling van projectdocumentatie in alle fasen van de IP-levenscyclus te automatiseren. Hiermee kunt u automatisch een verscheidenheid aan informatie die in verschillende stadia van projectontwikkeling is verkregen, extraheren en opnemen in de uitvoerdocumenten. Tegelijkertijd wordt de overeenstemming van de documentatie met het project, de relatie van documenten gecontroleerd, hun tijdige update. De resulterende documentatie wordt automatisch gegenereerd uit verschillende bronnen, waarvan het aantal niet beperkt is.

Het pakket bevat een grafische editor voor het voorbereiden van documentsjablonen. Hiermee kunt u de vereiste stijl, achtergrond, lettertype instellen, de locatie van koppen bepalen, plaatsen reserveren waar informatie uit verschillende bronnen wordt geplaatst. Wijzigingen worden alleen automatisch aangebracht in die delen van de documentatie die van invloed zijn in het programma. Dit vermindert de voorbereidingstijd voor documentatie doordat het niet meer nodig is om alle documentatie opnieuw te genereren.

SoDA wordt geïmplementeerd op basis van het FrameBuilder-publicatiesysteem en biedt een complete set tools voor het bewerken en opmaken van gepubliceerde documentatie.

Het eindresultaat van het SoDA-systeem is een afgewerkt document (of boek). Het document kan worden opgeslagen in een SoDA-bestand (Frame Builder), dat het resultaat is van het genereren van documenten. Printen van dit document (of een deel ervan) is mogelijk vanuit het SoDA systeem.

De SoDA-besturingssysteem is een UNIX-besturingssysteem op Sun SPARCstation, IBM RISC System/6000 of Hewlett Packard HP 9000 700/800 werkstations.
^

Testtools

Een van de meest geavanceerde testtools QA (nieuw genaamd Quality Works) is een geïntegreerde, multi-platformomgeving voor het ontwikkelen van geautomatiseerde tests van elk niveau, inclusief regressietests voor toepassingen met een grafische gebruikersinterface.

QA stelt u in staat om in elke fase van de levenscyclus te beginnen met testen, het testproces te plannen en te beheren, wijzigingen in de applicatie weer te geven en tests opnieuw te gebruiken voor meer dan 25 verschillende platforms.

Ter afsluiting geven we een voorbeeld van een complex van CASE-tools dat ondersteuning biedt voor de volledige levenscyclus van een IS. Het is ongepast om individuele CASE-tools te vergelijken, aangezien geen van hen in het algemeen alle problemen van het creëren en onderhouden van IS oplost. Dit wordt ook bevestigd door een complete set van evaluatie- en selectiecriteria die van invloed zijn op alle stadia van de IP-levenscyclus. Complexen van methodologisch en technologisch consistente tools die de volledige levenscyclus van een IS ondersteunen en die de nodige technische en methodologische ondersteuning krijgen van leveranciersbedrijven, kunnen worden vergeleken (merk op dat de rationele integratie van IS-ontwikkeltools de belangrijkste voorwaarde is om de kwaliteit van deze IS, en deze opmerking geldt voor alle vakgebieden).

Lezing #8

Gelaagde architectuur 9

Internet/intranet-technologieën 10

Eisen aan informatiesystemen 10

Flexibiliteit 11

Betrouwbaarheid 11

Efficiëntie 11

Beveiliging 12

Levenscyclus van informatiesystemen 16

Inleiding tot projectmanagement 17

^ Projectclassificatie 18

Hoofdfasen van het ontwerp van het informatiesysteem 18

Conceptfase 19

Opstellen van een technisch voorstel 19

Ontwerp 19

Ontwikkeling 20

Inbedrijfstelling van het systeem 20

Processen die plaatsvinden gedurende de levenscyclus van een informatiesysteem 21

^ Basis levenscyclusprocessen 21

Ontwikkeling 21

Operatie 21

Escort 22

Ondersteuning van levenscyclusprocessen 23

Organisatorische processen 23

De structuur van de levenscyclus van een informatiesysteem 23

Initiële fase 24

Verduidelijking fase 24

^ Bouwfase 24

Inbedrijfstellingsfase 24

Levenscyclus van informatiesystemen 28

Informatiesysteem levenscyclusmodellen 28

^ Cascademodel van de levenscyclus van het informatiesysteem 29

De belangrijkste ontwikkelingsstadia volgens het watervalmodel 29

De belangrijkste voordelen van het cascademodel 29

Nadelen van het watervalmodel 30

^ Spiraal levenscyclusmodel 31

iteraties 31

Voordelen van het spiraalmodel 32

Nadelen van het spiraalmodel 33

Methodologie en technologie van de ontwikkeling van informatiesystemen 37

RAD 40-methodologie

Belangrijkste kenmerken van de RAD 40-methodologie

^ Objectgeoriënteerde benadering 41

Visuele programmering 42

Evenement programmering 43

Levenscyclusfasen binnen de RAD 44-methodiek

Eisenanalyse en planningsfase 44

Ontwerpfase 44

Bouwfase 45

Uitvoeringsfase 46

^ Beperkingen van de RAD 46-methodologie

Methodologie en technologie van de ontwikkeling van informatiesystemen 51

Profielen van open informatiesystemen 51

Het concept van een informatiesysteemprofiel 52

Principes voor het vormen van een informatiesysteemprofiel 53

^ Structuur van profielen van informatiesystemen 55

Applicatiesoftwareprofiel 57

Omgevingsprofiel informatiesysteem 57

Informatiebeveiligingsprofiel 58

Gereedschapsprofiel 58

^ Methodologie en technologie van de ontwikkeling van informatiesystemen 63

Normen en methoden 63

Soorten normen 64

Oracle CDM 65

Algemene structuur 66

Kenmerken van de CDM 68-techniek

^ Internationale norm ISO/IEC 12207: 1995-08-01 69

Algemene structuur 69

Hoofd- en hulpprocessen van levenscyclus 69

Kenmerken van ISO 12207 71

CASE-technologieën voor het ontwerpen van informatiesystemen 77

Kenmerken van moderne CASE-gereedschappen 80

^ Lokale fondsen 86

Objectgeoriënteerde CASE-tools 87

Configuratiebeheertools 87

Documentatietools 87

Testgereedschap 88

Principes van constructie en stadia van databaseontwerp 93

Basisconcepten en definities 93

Beschrijvend domeinmodel 99

^ Principes van constructie en stadia van databaseontwerp 111

Conceptuele gegevensmodellen 111

Typen gegevensstructuur 112

Bewerkingen op gegevens 113

^ Integriteitsbeperkingen 114

Hiërarchisch datamodel 115

Netwerkgegevensmodel 117

Relationeel datamodel 118

Binair datamodel 119

Semantisch Web 119

Technologie voor het modelleren van informatiesystemen 124

Systeemmodelleringsmethoden 124

^ Wiskundig model van het systeem 126

Classificatie van wiskundige modellen 128

Simulatiemodellen van informatiesystemen 136

Methodologische grondslagen voor de toepassing van de simulatiemethode 136

^ Simulatiemodellen van informatiesystemen 146

Classificatie van simulatiemodellen 146

Structuur van een typisch simulatiemodel met een evenementenkalender 153

^ Simulatiemodellen van informatiesystemen 161

Technologie voor het modelleren van willekeurige factoren 161

Pseudo-willekeurige nummergeneratie (PRN) 161

Multiplicatieve methode 163

Additieve methode 164

Gemengde methode 164

^ Simulatie van willekeurige gebeurtenissen 165

Sequentiële modellering 167

Modellering na voorberekeningen 167

Simulatiemodellen van informatiesystemen 172

Technologie voor het modelleren van willekeurige factoren 172

^ Simulatie van willekeurige variabelen 172

Simulatie van continue willekeurige variabelen 173

Inverse functie methode 173

Eliminatiemethode (Neumann) 174

Samenstellingsmethode 176

Discrete willekeurige variabelen modelleren 177

Sequentiële vergelijkingsmethode 177

Interpretatiemethode 178

^ Willekeurige vectoren modelleren 178

Voorwaardelijke distributiemethode 179

Eliminatiemethode (Neumann) 180

Lineaire transformatiemethode 181

Simulatiemodellen van informatiesystemen 187

Grondbeginselen van de organisatie van simulatiemodellering 187

^ Simulatiestappen 187

Simulatietest 188

Initiële informatie instellen 189

Simulatiemodelverificatie 189

De geschiktheid van het model 189 . controleren

Simulator Kalibratie 190

Eigenschappen simulatiemodel onderzoeken 190

Beoordeling van de simulatiefout geassocieerd met het gebruik van pseudo-random number generators (PRN) in het model 190

Bepaling van de duur van de overgangsmodus 191

De robuustheid van simulatieresultaten beoordelen 192

Gevoeligheidsonderzoek model 192

^ Modelleertalen 193

Op 12 en 13 oktober vond het forum RIF-Voronezh 2018 plaats. In twee dagen schreven zich 4.600 mensen in voor het evenement. Nog eens 3.700 mensen keken naar de online uitzending. Meer dan honderd sprekers spraken het publiek toe, hot topics de gebieden van informatietechnologie werden besproken in de vorm van presentaties en discussies. Op de eerste dag van het forum werden de resultaten van de regionale internetprijs op een rij gezet. En het businessprogramma eindigde met de finale van het eerste studenten IT-kampioenschap voor het oplossen van cases op het gebied van digitale technologieën, design en online communicatie in de Central Black Earth Region. Het VSTU-team werd de winnaar. Het kampioenschap wordt samen met het project Internship.ru georganiseerd.

30 teams uit Voronezh, Kursk, Lipetsk, Orel, Bryansk, St. Petersburg, Moskou, Samara, Almaty namen deel aan de kwalificatieronde van het IT-Generation-kampioenschap. De jongste deelnemer aan het kampioenschap is een leerling van de 8e klas van de school (hij trad toe tot het studententeam). In de finale verdedigden 10 teams hun werk. De jongens hebben echte problemen opgelost waarmee programmeurs in hun werk worden geconfronteerd.

Voor elk geval bepaalden de bedrijven de beste oplossing:

Case van DSR-bedrijf (ontwikkeling van een zakelijke mobiele applicatie) - VSTU-team (Voronezh)

Case van Atos-bedrijf (afronding van het bedrijfsinformatiesysteem) - BGITU-team (Bryansk)

Dr.Web bedrijfscase (zoek verborgen mijnwerker in het bedrijfsnetwerk) - VSU-team (Voronezh)

De experts kozen ook de winnaar van het hele kampioenschap, het VSTU-team werd het! De winnaars werden uitgenodigd voor een stage bij het bedrijf.

Forumresultaten

De organisatoren moeten de resultaten van het forum nog samenvatten. Maar vandaag is duidelijk dat het meer bezocht is dan vorig jaar. Forumsprekers merkten op dat het publiek goed was voorbereid, moeilijke professionele vragen stelde en meedeed aan de dialoog. En alle deelnemers van RIF-Voronezh spraken over de uitstekende organisatie van het evenement.

Het thema digitale communicatie kreeg een nieuwe ontwikkeling op het forum, sprekersrapporten over trends, inhoud en promotie in sociale netwerken, videomarketing, personal branding werden in volle zalen gehouden. Het onderwerp webdesign werd zo breed mogelijk gepresenteerd. Voor de eerste keer werd in Voronezh een miniconferentie gehouden met deelname van sprekers van Baltic Digital Days, experts spraken over zoekmachinepromotie en reputatiebeheer op internet.

Het forum omvatte een groot aantal gespecialiseerde onderwerpen die begrijpelijk zijn voor professionals op bepaalde gebieden: ontwikkeling en testen, SAP, machine learning, digitale transformatie van productie.

In het formaat ronde Tafel besproken kwesties van internetregulering, ontwikkeling van de digitale economie, digitale transformatie van de stad.

RIF-Voronezh-experts in 2018 waren vertegenwoordigers van top-IT-bedrijven: Mozilla Foundation, VKontakte, Yandex, Mail.Ru Group, Rambler&Co, T-Systems, Ingate, Seopult, NLMK-Information Technologies, Severstal-infocom en anderen.

Zoals altijd waren alle evenementen van het jaarlijkse forum gratis. Organisatoren van het forum: Agentschap voor innovatie en ontwikkeling van economische en sociale projecten, ministerie van economische ontwikkeling van de regio Voronezh, aanbevelingsproject "LikenGo!", met de steun van de Russische Vereniging voor Elektronische Communicatie. Turkish Airlines werd de algemene partner van het forum.

Over het forum:

Het Regionale Internet Forum (RIF) wordt sinds 2009 in Voronezh gehouden. In 2013 kreeg het evenement de steun van de regionale staatsinstelling "Agentschap voor innovatie en ontwikkeling van economische en sociale projecten" en het ministerie van economische ontwikkeling van de regio Voronezh, wat de status van een belangrijk evenement voor de regio bevestigde. RIF-Voronezh organiseert ook een internetprijs, met als belangrijkste taak het bevorderen van de ontwikkeling van internettechnologieën in de regio en het demonstreren van heldere marktprojecten.

RIF-organisatoren in 2018:

Regionale staatsinstelling "Agentschap voor innovatie en ontwikkeling van economische en sociale projecten" www.innoros.ru

Afdeling Economische Ontwikkeling van de regio Voronezh www.econom.govvrn.ru

Met de steun van:

ministeries digitale ontwikkeling, communicatie en massacommunicatie Russische Federatie www.minsvyaz.ru
Russische Vereniging van Elektronische Communicatie,