Stuur uw goede werk in de kennisbank is eenvoudig. Gebruik onderstaand formulier

Studenten, afstudeerders, jonge wetenschappers die de kennisbasis gebruiken in hun studie en werk zullen je zeer dankbaar zijn.

Gehost op http://www.allbest.ru/

Omsk staats instituut dienst

Modellering informatie Systemen met behulp van de UML-taal

Methodische instructies voor implementatie term papier

IV Tsjervenchuk

• Invoering
• 2 . Uniforme modelleringstaalUML
• 4. Ontwikkeling van een softwaresysteemmodel door middel vanUML
• 5. Problemen met de implementatie van het informatiesysteem
• 6. Thema's van scripties
• Bibliografische lijst

Invoering

Het artikel gaat over de ontwikkeling van informatiesystemen die een uniforme taal gebruiken UML-modellering, wat de basis vormt voor het cursuswerk over de discipline "Informatiesystemen en -processen. Modellering en beheer". De hoofdfasen van een rationeel verenigd proces van het ontwikkelen van informatiesystemen worden uitgewerkt, voorbeelden en illustraties worden gegeven. Gegeven opties voor opdrachten voor cursussen.

De richtlijnen zijn bedoeld voor studenten van het specialisme "Toegepaste Informatica" en kunnen worden gebruikt bij het cursuswerk, de voorbereiding op het examen, maar ook bij het zelfstandig werken.

1. Algemene vereisten voor het cursuswerk

Cursuswerk op de discipline "Informatiesystemen en -processen. Modellering en beheer" is de laatste fase van de studie deze les en is ontworpen om de theoretische basiskennis over het modelleren van informatiesystemen in de praktijk te consolideren. Het werk bestaat uit het ontwikkelen van een model van een informatiesysteem met behulp van de uniforme modelleringstaal UML en de daaropvolgende implementatie ervan. Als standaard variant opdracht wordt voorgesteld om een ​​informatie- en referentiesysteem te ontwikkelen op basis van een databank, maar op verzoek van de leerling kan, in overleg met de docent, de ontwikkeling van een WEB-applicatie, toetssysteem of hardware als opdracht worden voorgesteld. Tegelijkertijd de belangrijkste noodzakelijke vereiste is het gebruik van een objectgeoriënteerde benadering en de constructie van een UML-model.

Een typische titel van een term paper ziet eruit als "Ontwikkeling van een informatie- en referentiesysteem _ Naam _ "

Invoering

1. Een zinvol overzicht van het vakgebied. Basis systeemvereisten

2. Gedetailleerd model van het informatiesysteem

2.1 Bekijk in termen van use cases

2.2 Ontwerpaanzicht

2.3 Uitvoeringsvisie

2.4 Procesoverzicht (indien gewenst)

2.5 Implementatieweergave (indien nodig)

3. Implementatie van het informatiesysteem

Conclusie

Toepassing Lijst van een programma of hoofdmodule

In de inleiding kunt u wijzen op de voordelen van het gebruik van informatietechnologie in verschillende werkterreinen, waaronder de dienstensector elektronische boekhouding, problemen bij het bouwen van gespecialiseerde informatiesystemen, enz.

Gegevens richtlijnen bevatten gedetailleerde aanbevelingen naar de belangrijkste onderdelen van de toelichting en ontwerpvoorbeelden. Opgemerkt moet worden dat het hoofdonderwerp van dit cursuswerk de ontwikkeling van een UML-model van een informatiesysteem is, daarom wordt het ten zeerste aanbevolen om UML-diagrammen in het hoofdgedeelte van de toelichting op te nemen, voorzien van gedetailleerd commentaar, en programmateksten dienen in de aanvraag te worden opgenomen.

Bij het ontwikkelen van multitasking-systemen moet de procesvisie worden gegeven. De implementatieweergave gaat uit van een gedistribueerd informatiesysteem. Deze typen, en de overeenkomstige secties van de toelichting, zijn niet verplicht voor de uitvoering van dit cursuswerk, hun gebruik wordt verondersteld bij het uitvoeren van alleen bepaalde opties natuurlijk werk.

Wanneer problemen met de systeemimplementatie in een notitie worden behandeld, is het wenselijk om de keuze voor een programmeeromgeving te motiveren en een gebruikershandleiding te verstrekken. Verplicht element is het opnemen van schermvormen (screen-shorts) van het geïmplementeerde programma in de tekst, wordt het gebruik van reverse engineering-tools aangemoedigd.

Concluderend worden de belangrijkste resultaten van het werk kort samengevat: er is een UML-model van het systeem ontwikkeld, het systeem is geïmplementeerd met behulp van die en die programmeeromgeving die het ontwikkelde systeem toelaat, de voordelen van de gebruikte benaderingen (gebaseerd op modellering) tot systeemontwerp.

modellering van informatiesysteemtaal

Cursussen moeten 20-30 pagina's gedrukte tekst met illustraties bevatten. Schema's van precedenten, klassen, interacties moeten absoluut worden gegeven.

2. Uniforme modelleringstaal UML

De rationele ontwikkeling van een informatiesysteem omvat een grondige analytische voorstudie. Allereerst is het noodzakelijk om het scala aan taken te schetsen dat door het ontwikkelde systeem wordt uitgevoerd, vervolgens om een ​​model van het systeem te ontwikkelen en ten slotte om de manieren van implementatie te bepalen. Diepgaande studie van de architectuur van het ontwikkelde informatiesysteem op vroege stadia ontwerp loont in de regel later, vooral bij het ontwikkelen van grootschalige projecten met langdurige ondersteuning.

UML-modelleringstaaltools (Unified Model Language, - een uniforme programmeertaal) maken het mogelijk om uitdrukkelijk en vrij gemakkelijk een voorlopige conceptuele ontwikkeling van een informatiesysteem te maken en tegelijkertijd methodisch het hele ontwikkelingsproces te begeleiden, inclusief alle verdere levenscyclus ontwikkeld informatiesysteem als softwareproduct.

UML is een taal voor het visualiseren, specificeren, construeren en documenteren van de artefacten van softwaresystemen op basis van een objectgeoriënteerde benadering.

UML bestaat, net als elke andere taal, uit een vocabulaire en regels waarmee u de woorden erin kunt combineren en zinvolle constructies kunt krijgen. In de modelleringstaal zijn de woordenschat en regels gericht op de conceptuele en fysieke representatie van informatiesystemen. Modellering is nodig om het systeem te begrijpen. Een enkel model is echter nooit genoeg. Integendeel, om een ​​niet-triviaal systeem te begrijpen, moet men een groot aantal onderling gerelateerde modellen ontwikkelen. Wanneer dit wordt toegepast op softwaresystemen, betekent dit dat er een taal nodig is die kan worden gebruikt om representaties van de architectuur van een systeem te beschrijven vanuit verschillende gezichtspunten tijdens de ontwikkelingscyclus.

UML is een visualisatietaal en UML is niet alleen een verzameling van grafische symbolen. Achter elk van hen is het goed bepaalde semantiek(zie ) Een model dat door de ene ontwikkelaar is geschreven, kan dus ondubbelzinnig worden geïnterpreteerd door een andere of zelfs door een tool.

UML is een specificatietaal. Specificeren betekent in deze context nauwkeurig, eenduidig ​​en complete modellen. De UML maakt de specificatie mogelijk van alle belangrijke analyse-, ontwerp- en implementatiebeslissingen die moeten worden genomen tijdens de ontwikkeling en implementatie van een softwaresysteem.

UML is een ontwerptaal. Hoewel UML geen visuele programmeertaal is, kunnen modellen die ermee zijn gemaakt direct worden vertaald in verschillende specifieke programmeertalen. Met andere woorden, het UML-model kan worden toegewezen aan talen zoals Java, C++, Visual Basic en zelfs tabellen. relationele database gegevens of persistente objectgeoriënteerde database-objecten. Die concepten die bij voorkeur grafisch worden overgebracht, worden weergegeven in de UML; degenen die het best in tekstuele vorm kunnen worden beschreven, worden uitgedrukt met behulp van een programmeertaal.

Een dergelijke mapping van het model naar de programmeertaal maakt direct ontwerp mogelijk: codegeneratie van het UML-model naar een specifieke taal. U kunt beslissen en omgekeerd probleem: herstel het model van de bestaande implementatie. Uiteraard wordt bij het model en de uitvoering gebruik gemaakt van een aantal specifieke entiteiten. Daarom vereist reverse engineering zowel tools als menselijke tussenkomst. De combinatie van voorwaartse codegeneratie en reverse engineering stelt u in staat om zowel in grafische als in tekstuele weergaven te werken, zolang de tools consistentie tussen beide weergaven bieden.

Naast directe toewijzing aan programmeertalen, stelt UML u vanwege zijn expressiviteit en eenduidigheid in staat om direct modellen uit te voeren, het gedrag van systemen te simuleren en bestaande systemen te besturen.

UML is een documentatietaal

Een softwarebedrijf produceert naast de uitvoerbare code ook andere documenten, waaronder:

systeem vereisten;

architectuur;

projecteren;

bron;

projectplannen;

proeven;

prototypen;

versies, enz.

Afhankelijk van de gekozen ontwikkelingsmethodologie, worden sommige werken formeler uitgevoerd, andere minder. De documenten waarnaar wordt verwezen, zijn niet alleen leverbare onderdelen van het project; ze zijn nodig voor het beheer, voor het evalueren van het resultaat en ook als communicatiemiddel tussen teamleden tijdens de systeemontwikkeling en na de implementatie ervan.

UML biedt de ontwikkelaar en het management een eigen oplossing voor het probleem van het documenteren van de systeemarchitectuur en al zijn details, biedt een taal voor het formuleren van systeemvereisten en het definiëren van tests, en biedt ten slotte tools voor het modelleren van werk in de fase van projectplanning en versie controle.

Denk aan de ontwikkeling van een informatiesysteemmodel in de UML-taal naar het voorbeeld van de ontwikkeling van een geautomatiseerde werkplek van de secretaresse van de afdeling (hierna: de werkplek van de secretaresse van de afdeling).

3. Beschrijving van het vakgebied

Het concept van een database-onderwerp is er een van basisconcepten informatica en heeft geen exacte definitie. Het gebruik ervan in de context van IS veronderstelt het bestaan ​​van een tijdstabiele correlatie tussen namen, concepten en bepaalde realiteiten van de buitenwereld, onafhankelijk van de IS zelf en zijn gebruikerskring. Dus de inleiding tot de overweging van het concept van het onderwerpgebied van de database beperkt en maakt de ruimte zichtbaar informatie ophalen in de IS en stelt u in staat om query's in een eindige tijd uit te voeren.

Door de beschrijving van het onderwerpgebied zullen we de beschrijving begrijpen van de omgeving van het systeem dat wordt ontwikkeld, de soorten gebruikers van het systeem, terwijl we ook de hoofdtaken aangeven waarvan de oplossing aan het systeem is toegewezen.

In de voorlopige beschrijving van het vakgebied worden de belangrijkste termen geïntroduceerd (het woordenboek van het systeem), worden de soorten gebruikers en hun rechten gedefinieerd en worden de taken geformuleerd die het ontwikkelde systeem moet oplossen. Tegelijkertijd wordt verondersteld dat het bij het beschrijven de middelen van een gemeenschappelijke taal en standaard zakelijke afbeeldingen (figuren, diagrammen, tabellen) gebruikt.

Bij het ontwikkelen van een systeemwoordenboek is het noodzakelijk om de namen van entiteiten ("student", "leraar", "discipline") te definiëren. Tegelijkertijd wordt de term entiteit door ons opgevat als een onderdeel van het domeinmodel, dat wil zeggen als een object dat al op conceptueel niveau is geïdentificeerd. De objecten die in het onderwerpgebied zijn toegewezen, worden door de analist omgezet in entiteiten.

Een entiteit is het resultaat van het abstraheren van een reëel object. Er zijn twee problemen met objecten: identificatie en adequate beschrijving. Gebruik voor identificatie de naam, die uniek moet zijn. Tegelijkertijd wordt aangenomen dat er een afwijzing is van de betekenis ervan, die inherent is aan natuurlijke taal. Alleen de functie naamaanwijzer wordt gebruikt. Een naam is een directe manier om een ​​object te identificeren. Indirecte methoden om een ​​object te identificeren, omvatten de definitie van een object door middel van zijn eigenschappen (kenmerken of kenmerken).

Objecten interageren met elkaar via hun eigenschappen, waardoor situaties ontstaan. Situaties zijn relaties die relaties tussen objecten uitdrukken. Situaties in het vakgebied worden beschreven door middel van uitspraken over het vakgebied. Op dit stadium je kunt de methoden van propositierekening en predikaatrekening gebruiken, dat wil zeggen formele, wiskundige logica. De stelling "De programmeur en de manager zijn werknemers van het bedrijf" beschrijft bijvoorbeeld een inclusierelatie. Zo wordt alle informatie over objecten en entiteiten van het vakgebied beschreven aan de hand van uitspraken in natuurlijke taal.

U kunt structurele relaties specificeren, statische en dynamische situaties benadrukken (waardoor een tijdparameter in het model wordt geïntroduceerd), maar voor een gedetailleerde studie van het model is het handiger om geavanceerde tools te gebruiken voor het beschrijven van het onderwerpgebied, bijvoorbeeld UML Taalhulpmiddelen.

Het is dus de taak om een ​​​​systeem "werkstation van de secretaris van de afdeling" te ontwikkelen dat zou kunnen leiden geautomatiseerde boekhouding gegevens over medewerkers en studenten van de afdeling ICT OmSTU, bood flexibiliteit bij het oplossen van geplande en ongeplande specifieke taken van het verwerken van boekhoudkundige gegevens.

Als onderdeel van het oplossen van het probleem van het ontwikkelen van een geautomatiseerde werkplek van de secretaresse van de afdeling, onderscheiden we de volgende entiteiten:

leraren - docenten van de afdeling;

studenten- universitaire studenten van de gegeven specialiteit;

studenten studeren in groepen, groep is een organiserende (verenigende) entiteit voor studenten;

afgestudeerde studenten, hebben de bijzonderheid dat ze enerzijds zelf lessen kunnen geven, anderzijds zelf student zijn en een begeleider hebben;

discipline- aangeleerde discipline (vak, cursus).

Bijgehouden entiteiten hebben een aantal attributen die we later zullen definiëren.

We beheren twee soorten gebruikers: gewoon gebruiker(verder gebruiker, En beheerder. Er wordt aangenomen dat gebruiker kan met een verzoek toegang krijgen tot het systeem, rapporten weergeven, beheerder kan de gegevens bovendien wijzigen. Zo kan de adjunct-secretaris van de afdeling optreden als gebruiker, de secretaris zelf of de verantwoordelijke docent als beheerder.

Rekening houdend met de geïntroduceerde termen, zou het ontwikkelde systeem moeten voorzien in:

organisatie van een volledige en betrouwbare boekhouding van alle medewerkers en studenten van de afdeling;

informatieondersteuning voor managementbeslissingen, de vorming van volledige en betrouwbare informatie over educatieve processen en de resultaten van de afdeling;

verlaging van arbeidskosten voor het opstellen van primaire documenten en rapporten;

eliminatie van duplicatie bij het invoeren van informatie en de resulterende mechanische fouten;

handige gebruikersinterface;

differentiatie van bevoegdheden van gewone gebruikers en beheerder.

IN dit voorbeeld we lossen een bepaald probleem op - we ontwikkelen een werkstation voor de secretaresse van de afdeling, dus de structurele eenheid van het hoogste niveau voor ons is de afdeling, die we standaard in gedachten zullen hebben, dat wil zeggen, er wordt van uitgegaan dat alle elementen van het model zijn alleen van toepassing op deze afdeling, die niet expliciet wordt gespecificeerd. Structuren van een hoger niveau, zoals een faculteit, een universiteit, nemen wij niet in behandeling.

4. Ontwikkeling van een softwaresysteemmodel met behulp van UML

UML is een specificatie- en visualisatietaal, de belangrijkste eenheden zijn diagrammen.

Een diagram in UML is grafische weergave een reeks elementen, meestal afgebeeld als een verbonden grafiek met hoekpunten (entiteiten) en randen (relaties). Schema's karakteriseren het systeem vanuit verschillende invalshoeken. Het diagram is in zekere zin een van de projecties van het systeem. In de regel geven diagrammen een samengevouwen weergave van de elementen waaruit het systeem bestaat. Hetzelfde element kan in alle diagrammen aanwezig zijn, of slechts in een paar (de meest voorkomende), of in geen enkele (zeer zeldzaam). Theoretisch kunnen diagrammen elke combinatie van entiteiten en relaties bevatten. In de praktijk wordt echter een relatief klein aantal typische combinaties gebruikt, die overeenkomen met de vijf meest voorkomende typen waaruit de architectuur van een softwaresysteem bestaat (zie de volgende paragraaf). Er zijn dus negen soorten diagrammen in de UML:

klasse diagrammen

objectdiagrammen;

casusdiagrammen gebruiken;

sequentiediagrammen;

samenwerkingsdiagrammen;

toestandsdiagrammen;

actie (activiteit) diagrammen;

component diagrammen;

implementatie diagrammen.

Conceptueel UML-model

Een klassendiagram toont klassen, interfaces, objecten en samenwerkingen, evenals hun relaties. Bij het modelleren van objectgeoriënteerde systemen wordt dit type diagram het meest gebruikt. Klassediagrammen komen overeen met de statische weergave van het systeem vanuit een ontwerpstandpunt. Klassediagrammen die actieve klassen bevatten, komen overeen met de statische weergave van het systeem in termen van processen.

Een objectdiagram vertegenwoordigt objecten en de relaties daartussen. Het zijn statische "foto's" van entiteitsinstanties die worden weergegeven in klassendiagrammen. Objectdiagrammen verwijzen, net als klassendiagrammen, naar de statische weergave van een systeem in termen van ontwerp of processen, maar met een echte of nepimplementatie in gedachten.

Een use case-diagram toont use cases en actoren ( speciaal geval klassen) en de relaties daartussen. Use case-diagrammen verwijzen naar de statische weergave van een systeem in termen van use cases. Ze zijn vooral belangrijk bij het organiseren en modelleren van het gedrag van een systeem.

Volgorde- en samenwerkingsdiagrammen zijn speciale gevallen van interactiediagrammen. Interactiediagrammen geven relaties tussen objecten weer; toont met name de berichten die objecten kunnen uitwisselen. Interactiediagrammen verwijzen naar de dynamische weergave van een systeem. Tegelijkertijd weerspiegelen sequentiediagrammen de temporele ordening van berichten en weerspiegelen samenwerkingsdiagrammen de structurele organisatie van objecten die berichten uitwisselen. Deze diagrammen zijn isomorf, dat wil zeggen dat ze in elkaar kunnen worden omgezet.

Toestandsdiagrammen (Statechart-diagrammen) vertegenwoordigen een automaat die toestanden, overgangen, gebeurtenissen en soorten acties omvat. Toestandsdiagrammen verwijzen naar de dynamische weergave van een systeem; ze zijn vooral belangrijk bij het modelleren van het gedrag van een interface, klasse of samenwerking. Ze richten zich op het gedrag van een object, afhankelijk van de volgorde van gebeurtenissen, wat erg handig is voor het modelleren van reactieve systemen.

Een activiteitendiagram is een speciaal geval van een toestandsdiagram; het vertegenwoordigt de overgangen van de controlestroom van de ene activiteit naar de andere binnen het systeem. Activiteitsdiagrammen verwijzen naar de dynamische weergave van het systeem; ze zijn het belangrijkst bij het modelleren van de werking ervan en weerspiegelen de controlestroom tussen objecten.

Het componentendiagram toont de organisatie van een set componenten en de afhankelijkheden die daartussen bestaan. Componentdiagrammen verwijzen naar de statische weergave van een systeem vanuit een implementatiestandpunt. Ze kunnen verband houden met klassendiagrammen, aangezien een component meestal wordt toegewezen aan een of meer klassen, interfaces of samenwerkingen.

Het implementatiediagram toont de configuratie van de verwerkingsknooppunten van het systeem en de daarin geplaatste componenten. Implementatiediagrammen verwijzen naar een statische weergave van de architectuur van een systeem vanuit een implementatieperspectief. Ze zijn gerelateerd aan componentdiagrammen omdat een knooppunt meestal een of meer componenten bevat.

Dit is een gedeeltelijke lijst van diagrammen die in de UML worden gebruikt. Met de tools kunt u ook andere diagrammen genereren, zoals databaseprofieldiagrammen, webtoepassingsdiagrammen, enzovoort.

4.1 De view ontwerpen in termen van use cases

Modellering begint met het definiëren van de hoofdtaken van het systeem dat wordt ontwikkeld en de acties die het moet uitvoeren. Hiervoor worden use case diagrammen gebruikt. Zoals eerder vermeld, geven use case-diagrammen use cases en actoren aan, evenals de relaties daartussen.

Precedent (Use case) is een beschrijving van de opeenvolging van acties die door het systeem worden uitgevoerd, die een waarneembaar resultaat opleveren dat significant is voor een bepaald Handeling e ra (Acteur). De use case wordt gebruikt om de gedragsentiteiten van het model te structureren. Het precedent geeft alleen een beschrijving van een bepaalde actie van het systeem en beantwoordt de vraag "wat te doen?", maar specificeert niet met welke middelen. De concrete implementatie van het gedrag gespecificeerd door een use case wordt geleverd door een klasse, een klassensamenwerking of een component.

Een actor is een samenhangende reeks rollen die gebruikers van use cases uitvoeren terwijl ze met hen communiceren. Doorgaans vertegenwoordigt een actor een rol die wordt gespeeld door een persoon, een hardwareapparaat of zelfs een ander systeem in een bepaald systeem. In het ontwikkelde systeem "Werkplek van de secretaresse van de afdeling" zijn de actoren de beheerder (beheerder) En gebruiker.

Grafisch wordt een precedent afgebeeld als een ellips die wordt begrensd door een ononderbroken lijn, die meestal alleen de naam bevat. De acteur heeft een "kleine man" -pictogram.

Om een ​​use case-diagram te bouwen, is het noodzakelijk om de elementaire acties die door het systeem worden uitgevoerd te identificeren en deze te vergelijken met de use cases. Tegelijkertijd is het wenselijk om de namen van precedenten te geven, zodat ze het gedrag aangeven, vaak bevatten dergelijke namen werkwoorden, bijvoorbeeld "een rapport genereren", "gegevens zoeken op basis van een criterium", enz. U kunt use cases een naam geven met zelfstandige naamwoorden die een bepaalde actie suggereren, bijvoorbeeld "autorisatie", "zoeken", "controle".

Terugkerend naar het modelleren van het werkstation van de secretaresse van de afdeling, belichten we de precedenten:

Bewerkengegevens,

Zoekopdrachtstudent,

Zoekopdrachtdocent,

uitleveringlijstonderwezendisciplines,

Autorisatie.

Use case-diagramelementen (use cases en actoren) moeten gerelateerd zijn.

De meest voorkomende relatie tussen use cases, use cases en actoren is associatie. In sommige gevallen kunnen generalisatierelaties worden gebruikt. Deze relaties hebben dezelfde betekenis als in het klassendiagram.

Daarnaast zijn er twee specifieke afhankelijkheden gedefinieerd tussen use-cases in de UML - de inclusierelatie en de extensierelatie.

Een inclusierelatie tussen use-cases betekent dat op een bepaald punt in de basis-use-case het gedrag van een andere use-case wordt opgenomen (inbegrepen). Een meegeleverde use case bestaat nooit autonoom, maar wordt alleen geïnstantieerd als onderdeel van een omsluitende use case. U kunt de basisgebruikscase zien als het lenen van het gedrag van de meegeleverde. Vanwege de aanwezigheid van insluitingsrelaties is het mogelijk om meerdere beschrijvingen van dezelfde stroom van gebeurtenissen te vermijden, aangezien het algemene gedrag kan worden beschreven als een onafhankelijk precedent dat is opgenomen in de basis. Een include-relatie is een voorbeeld van delegatie, waarbij een set systeemverantwoordelijkheden op één plaats wordt beschreven (in een opgenomen use case), en andere use cases nemen die verantwoordelijkheden op in hun set als dat nodig is.

Inclusierelaties worden afgebeeld als afhankelijkheden met het stereotype "include". Om een ​​plaats in de stroom van gebeurtenissen te specificeren waar een basis use case het gedrag van een andere bevat, schrijft u eenvoudig het woord include gevolgd door de naam van de use case die moet worden opgenomen.

Een uitbreidingsrelatie wordt gebruikt om delen van een use-case te modelleren die de gebruiker als optioneel gedrag van het systeem waarneemt. Op deze manier kun je vereist en optioneel gedrag scheiden. Uitbreidingsrelaties worden ook gebruikt om individuele deelstromen te modelleren die alleen onder bepaalde omstandigheden worden uitgevoerd. Ten slotte worden ze gebruikt om meerdere threads te modelleren die op een bepaald punt in een script kunnen worden geactiveerd als gevolg van expliciete interactie met een actor.

Een uitbreidingsrelatie wordt afgebeeld als een afhankelijkheid met het stereotype "uitbreiden". Basisscenario-uitbreidingspunten worden vermeld in het optionele gedeelte. Het zijn gewoon labels die kunnen verschijnen in de basis use case-stream.

Een voorbeeld van het gebruik van deze relatie kan toegang zijn tot een database met een operationeel deel en een archief. In dit geval, als het verzoek is voorzien van de gegevens van het operationele deel, wordt de belangrijkste (basis) toegang tot de gegevens uitgevoerd, maar als de gegevens van het operationele deel niet voldoende zijn, wordt toegang tot de archiefgegevens uitgevoerd, dat dat wil zeggen, de toegang verloopt volgens het uitgebreide scenario.

In ons geval het precedent bewerkengegevens omvat precedenten: invoergegevens, verwijderinggegevens, wijziginggegevens.

Het precedentenschema van de werkplek van de secretaresse van de afdeling wordt getoond in Fig.1.

Rijst. 1. Precedentenschema van de werkplek van de secretaris van de afdeling

Precedent zoekopdrachtstudent omvat zoeken op achternaam en zoeken op resultaten van academische prestaties.

Bij het ontwikkelen van een weergave in termen van use-cases is het vaak nodig om een ​​uitgebreide beschrijving van de use-case te geven (in de verkorte versie wordt alleen de naam aangegeven). In de regel wordt aan het begin van het werk de stroom van gebeurtenissen van een use case in tekstvorm beschreven. Naarmate de vereisten voor het systeem nauwkeuriger worden, zal het handiger zijn om over te gaan op een grafische weergave van stromen in activiteits- en interactiediagrammen.

Gebeurtenisstromen kunnen worden beschreven met behulp van ongestructureerde tekst, gestructureerde tekst (met functiewoorden: ALS,VOORDIEPORDOEI enz.), een gespecialiseerde formele taal (pseudocode).

Bij het beschrijven van een use case aan de hand van een stroom van gebeurtenissen, is het ook belangrijk om de hoofd- en aan te duiden alternatieve stromen systeem gedrag.

Denk bijvoorbeeld aan de beschrijving van de stroom van gebeurtenissen van de use case autorisatie.

Eenvoudig stroom evenementen. De use case begint wanneer het systeem de gebruiker om zijn loginnaam (Login) en wachtwoord (Password) vraagt. De gebruiker kan het via het toetsenbord invoeren. Beëindig de invoer door op de toets te drukken Binnenkomen. Daarna controleert het systeem de ingevoerde gebruikersnaam en het wachtwoord en als deze overeenkomen met de beheerder, bevestigt het de bevoegdheid van de beheerder. Hier houdt het precedent op.

Buitengewoon stroom evenementen. De klant kan de transactie op elk moment beëindigen door op de toets te drukken Annuleren. Met deze actie wordt de use case opnieuw gestart. Er is geen toegang tot het systeem.

Buitengewoon stroom evenementen. De Klant kan op elk moment, voordat hij op Enter drukt, zijn Login en paswoord verwijderen.

Buitengewoon stroom evenementen. Als de klant de login en het wachtwoord heeft ingevoerd die niet overeenkomen met de beheerder, wordt hij gevraagd om opnieuw in te voeren of in te loggen als een gewone gebruiker.

Het is duidelijk dat de beschrijving van een precedent door een stroom van gebeurtenissen een algoritme inhoudt dat kan worden weergegeven in een activiteitendiagram (Fig. 2).

Het algoritmediagram moet de begin- en eindpunten bevatten, en slechts één begin en één einde. Het diagram bevat uitvoerbare hoekpunten - activiteiten (aangegeven door afgeronde rechthoeken), voorwaardelijke hoekpunten (beslissing - keuze, herkenning, aangegeven door ruiten) en verbindingen.

Soortgelijke diagrammen kunnen ook de uitvoering van andere use-cases verklaren, waardoor het zicht op het systeem in termen van use-cases wordt aangevuld.

Rijst. 2. Gebruikersautorisatie. Activiteiten diagram.

4.2 Ontwerpaanzicht vanuit een ontwerpstandpunt

De ontwerpweergave is de belangrijkste stap bij het conceptualiseren van een model. In dit stadium worden de belangrijkste abstracties geïntroduceerd, worden klassen en interfaces gedefinieerd waarmee de oplossing van de taken wordt geïmplementeerd. Als de precedenten alleen het gedrag van het systeem aangeven, wordt in het stadium van de ontwikkeling van de visie, vanuit ontwerpoogpunt, bepaald met welke middelen deze precedenten zullen worden geïmplementeerd. Statische aspecten van dit type worden ontwikkeld door middel van klassendiagrammen, dynamisch - door interactie en toestandsdiagrammen (automaat).

Klassediagrammen bevatten klassen, interfaces, samenwerkingen en relaties daartussen. De ontwikkeling van een klassendiagram moet beginnen met de definitie van klassen die overeenkomen met de belangrijkste entiteiten van het systeem, die in de regel worden bepaald in de beginfasen van ontwikkeling bij het beschrijven van het onderwerpgebied. Hier moet u beslissen welke entiteiten handiger zijn om als klassen te modelleren en welke als hun attributen. Als het bijvoorbeeld binnen de faculteit verplicht zou zijn om voor elke afdeling een hoofd te specificeren, zou het beter zijn om de entiteit te specificeren managerafdelingen maak er een class attribuut van afdeling de klasse aangeven leraren (één op één vereniging ), in plaats van een aparte klasse in te voeren managerafdelingen.

Bij het modelleren moet er rekening mee worden gehouden dat elke klasse moet overeenkomen met een echte entiteit of conceptuele abstractie van het gebied waarmee de gebruiker of ontwikkelaar te maken heeft. Een goed gestructureerde klasse heeft de volgende eigenschappen:

is een goed gedefinieerde abstractie van een concept uit het vocabulaire van het probleemdomein of oplossingsdomein;

bevat een kleine, goed gedefinieerde reeks taken en voert ze allemaal uit;

handhaaft een duidelijke scheiding tussen abstractiespecificaties en de implementatie ervan;

duidelijk en eenvoudig, maar maakt tegelijkertijd uitbreiding en aanpassing aan nieuwe taken mogelijk.

Als onderdeel van de ontwikkeling van het AWP-model van de secretaris van de afdeling, definiëren we de klassen: leraren, studenten, afgestudeerde studenten, disciplines, groepen. Vanzelfsprekend hebben de eerste veel gemeenschappelijke attributen, dus introduceren we een abstracte klasse Person, die alle eigenschappen bevat die betrekking hebben op een persoon in de context van het systeem dat wordt ontwikkeld (achternaam, voornaam, adres, enz.). In dit geval een persoon zal een superklasse zijn en door een generalisatierelatie met klassen worden geassocieerd leraren, studenten, afgestudeerde studenten.

Attribuut adres heeft zijn eigen structuur, om deze weer te geven kun je naar binnen bijles, laten we het noemen T_ ADR(zoals gebruikelijk is in veel programmeersystemen, beginnen klassennamen met de letter T). Opgemerkt moet worden dat het attribuut adres klas een persoon is een instantie van de klasse T_ ADR, dat wil zeggen dat er een afhankelijkheidsrelatie tot stand wordt gebracht tussen deze klassen (weergegeven gestippelde pijl met een open punt wordt de pijl van het afhankelijke element naar het onafhankelijke geleid). In ons geval de klassenstructuur wijzigen T_ ADR houdt een klassewisseling in een persoon door de structuur van het corresponderende attribuut ( adres).

Bij het modelleren van een klas T_ ADR attribuut inhoudsopgave ingesteld op primitief type T_ POSTIDX, gedefinieerd als een zescijferig decimaal getal. Primitieve typen worden gemodelleerd door het stereotype " type" , wordt het waardenbereik gespecificeerd door de beperkingen tussen accolades.

In de klas docent Laten we specifieke kenmerken benadrukken die alleen van toepassing zijn op de leraar: functietitel, uh. rang(academische graad), uh. rang ( academische titel) afvoer(categorie van de uniforme tariefschaal). attributen uh. rang En uh. rang het is beter om gespecialiseerde typen te definiëren via een opsomming. Opsommingen worden gemodelleerd door een klasse met het stereotype " opsomming" (opsomming - opsomming), toegestane waarden worden geschreven als attributen, worden de labels die de zichtbaarheid van de attributen bepalen onderdrukt. In het voorbeeld in kwestie introduceren we door de opsomming gespecialiseerde klassen T_Moeten, T_UchSt, T_UchSv, die respectievelijk mogelijke posities, academische graden, academische titels definiëren door middel van opsommingen. In dit geval, zoals elders in vergelijkbare gevallen, worden bij het maken van klassen die de attributen van de hoofdklasse specificeren, afhankelijkheidsrelaties tot stand gebracht.

Voor de les student een specifiek attribuut wordt ingevoerd nummerboeken van studenten. Specifieke attributen zijn gedefinieerd voor de postdoctorale klas formulieraan het leren En datumbonnen. De vorm van training wordt bepaald door een speciale klasse door middel van opsomming T_FormOnderwijs(Voltijd Deeltijd).

Klas groep heeft attributen: Naam, formulier aan het leren, nummerstoeterij. ( aantal leerlingen ). Aangezien de docenten van de betreffende afdeling lessen kunnen geven met groepen van andere faculteiten, wordt een extra klas ingevoerd specialiteit, met attributen nummer(specialiteiten), Naam(specialiteiten ), faculteit, waarvan de typen niet in dit model zijn gespecificeerd, hoewel ze kunnen worden gedefinieerd door middel van opsommingen.

Klas discipline heeft attributen: nummer, Naam, fiets. Attribuut fiets door middel van een gespecialiseerd type geïntroduceerd via een opsomming T_cycli bepaalt tot welke kringloop het vakgebied behoort: tot de kringloop van humanitaire en sociaal-economische disciplines, wiskundige en natuurwetenschappelijke disciplines, algemene vakdisciplines, bijzondere disciplines.

attributen hoeveelheiduur, hoeveelheidsemesters kan niet worden gespecificeerd in de klasse discipline, aangezien ze afhankelijk zijn van de specialiteit, des te meer kun je ze niet specificeren in de klas specialiteit. Deze attributen verwijzen naar een paar specialiteitsdisciplines en zijn gedefinieerd in de klassenassociaties Disciplines-specialiteiten.

Rijst. 3. Klassenschema van de werkplek van de secretaresse van de afdeling (optie 1)

Let bij het visualiseren van de structuur van klassen op de zichtbaarheid van attributen. Alle beschouwde attributen moeten toegankelijk zijn en de zichtbaarheid Openbaar hebben (aangegeven door een "+" teken of een pictogram zonder hangslot). In de beschouwde klassen hebben we ons gericht op de structuur, niet op het gedrag (bewerkingen werden niet beschreven en behoren ook niet te worden beschreven), daarom is het wenselijk om de weergave van bewerkingen te onderdrukken om de perceptie van het diagram te vergemakkelijken.

Op de geïntroduceerde reeks klassen is het noodzakelijk om de koppelingen opnieuw te definiëren. Generalisatierelaties en afhankelijkheden zijn al gedefinieerd, het blijft om associaties te definiëren.

studenten gevormd in groepen, in dit geval ziet de associatie eruit als een aggregatie. Aggregatie impliceert een deel-geheel-relatie, aangegeven door een ononderbroken lijn met een ruit aan het einde vanaf de zijkant van het geheel (in ons geval groepen). De veelheid van de student-groep relatie is veel-op-een. Elk groep verwijst naar een bepaalde specialiteiten, op hun beurt kunnen verschillende groepen overeenkomen met een bepaalde specialiteit, dus de groep-specialiteitsassociatie heeft ook een veel-op-één multipliciteitstype.

In dit geval, zoals in de meeste andere gevallen, is de richting van de associaties tweerichtingsverkeer, dus is het beter om de navigatie te onderdrukken (schakel het veld Navigeerbaar van de optie Detailrol uit)

Laten we een verband definiëren tussen leraren en onderwezen disciplines volgens het type "many-to-many": een leraar kan meerdere disciplines leiden, sommige disciplines kunnen door meerdere leraren worden onderwezen. Tussen disciplines En specialiteiten ook komt er een veel-op-veel-associatie: het curriculum van specialismen bevat veel disciplines, de meeste disciplines zijn terug te vinden in de werkplannen van meerdere specialismen. Aan deze associatie is een associatieklasse gekoppeld. Disciplines-specialiteiten met attributen die de cursus, het aantal semesters en het aantal uren van een bepaalde discipline in een bepaalde specialiteit aangeven.

Evenzo introduceren we een associatie tussen groepen En leraren: leraren geven lessen in groepen, het type multipliciteitsassociatie is veel-op-veel. directe associatie tussen groepen En disciplinen hoeft niet te worden gedefinieerd, aangezien deze relatie wordt getraceerd via de koppelingsklasse specialiteit.

Om de aanwezigheid van een supervisor in een afgestudeerde student weer te geven, is het noodzakelijk om een ​​associatie tussen een afgestudeerde student en een leraar te introduceren volgens het "veel-op-één"-type, één supervisor kan meerdere afgestudeerde studenten hebben. Op deze associatie, van de kant van de leraar, kun je expliciet de rol aangeven: leidinggevende.

Rijst. 4. Klassenschema van de werkplek van de secretaresse van de afdeling (optie 2)

In elke groepene er is een hoofdman van de groep, dit feit kan worden weergegeven door een extra vereniging (laten we het een naam geven hoofdman) van een groep naar studenten met een één-op-één multipliciteitstype. In dit geval kunt u de navigatie expliciet specificeren.

PhD studenten kan ook lessen geven in een bepaalde discipline bij bepaalde groepen: veel-op-veel associaties postdoctorale groepen, afgestudeerde studenten-disciplines. Sommige afgestudeerde studenten geven mogelijk geen lessen, dus het veelvoudstype aan de uiteinden van de associatie is 0. n.

Het uiteindelijke klassendiagram wordt getoond in Fig. 3.

Rijst. 5. Vereenvoudigd klassendiagram

Aangezien zowel afgestudeerde studenten als docenten lessen geven, kun je een extra abstracte klas introduceren, bijvoorbeeld onderwijs, wat een afstammeling is van de klasse een persoon en superklasse voor klassen docent En afgestudeerde student, waardoor het aantal aansluitingen iets zal afnemen. (Afb. 4.). In dit geval van lessen discipline En groep verenigingen gaan naar de les onderwijs, uitgaande van associatie met klassen docent En afgestudeerde student door overerving (generalisatierelatie). Naar de klas onderwijs attributen kunnen worden verwijderd bieden(0,5 inzet, volledige inzet) en afvoer.

Het resulterende diagram is vrij complex en geladen met elementen, maar de klassenmodellering is verre van compleet: sommige hulpprogrammaklassen en interfaces moeten nog worden gedefinieerd. Om het klassediagram te ontladen, bouwen we er een nieuwe weergave van (op een apart diagram) waarbij we het beeld van de hoofdklassen achterlaten en de weergave van de hulpklassen die de soorten attributen bepalen, onderdrukken (Fig. 5).

Op afb. 5, samen met de hoofdklassen die overeenkomen met de conceptuele elementen van het systeem, toont ook de klasse T_ ADR, die de structuur van het adres onthult, is deze klasse ook belangrijk omdat deze bevat noodzakelijke elementen gegevens voor leraren En afgestudeerde studenten- afstammelingen van de klas een persoon.

Laten we verder gaan met het definiëren van interfaces. Klassen communiceren met buitenwereld via interfaces.

Koppel (Interface) is een set bewerkingen die een service (set services) definiëren die wordt geleverd door een klasse of component. Een interface beschrijft dus het extern zichtbare gedrag van een element. Een interface kan het gedrag van een klasse of component geheel of gedeeltelijk weergeven; het definieert alleen specificaties van bewerkingen (handtekeningen), nooit hun implementaties. De grafische interface wordt weergegeven als een cirkel, waaronder de naam is geschreven. Een interface staat zelden op zichzelf - hij is meestal gekoppeld aan een implementerende klasse of bean. Een interface veronderstelt altijd het bestaan ​​van een "contract" tussen de partij die de uitvoering van een aantal bewerkingen aangeeft en de partij die deze bewerkingen uitvoert.

Zet een klasse op het diagram elektronischtafel, dat alle eigenschappen en bewerkingen omvat van een spreadsheet waarmee gegevens kunnen worden bewerkt. Structuur deze klas Vanwege de complexiteit zullen we dit niet bekendmaken. Dus binnen moderne middelen Bij het ontwikkelen van applicaties gebruikt de gebruiker kant-en-klare klassen en sjablonen, die hun mogelijkheden erven. De VCL-bibliotheek (Delphi) bevat bijvoorbeeld de TTable-klasse, die de mogelijkheden van een spreadsheet inkapselt. Klasse afstammelingen elektronischtafel zijn specifieke spreadsheets met specifieke gegevens over docenten, afgestudeerde studenten, studenten, groepen, disciplines en specialiteiten. De overeenkomstige klassen afstammelingen maken van de klasse elektronischtafel, we declareren voor deze klassen alle eigenschappen en bewerkingen die inherent zijn aan spreadsheets (registratie in het systeem, invoegen, verwijderen, bewerken van gegevens, sorteren, enz.).

Voor de les elektronischtafel, en dienovereenkomstig definiëren we voor al zijn nakomelingen de interface bewerken, dit impliceert alle mogelijke bewerkingen voor het bewerken van gegevens (gegevens invoegen, verwijderen, wijzigen). Er wordt van uitgegaan dat in de klas elektronischtafel deze functies zijn geïmplementeerd.

Een speciale klasse gebruiken elektronischtafel en overerving vermeed het definiëren van speciale eigenschappen en gegevensbewerkingsinterfaces voor elke spreadsheet.

Definieer interfaces zoekopdrachtdocent, zoekopdrachtdisciplines, door ze met implementatierelaties aan de overeenkomstige klassen te koppelen. We zullen de samenstelling van de werking van deze interfaces niet onthullen (het is nogal triviaal), dus we zullen de interfaces in verkorte vorm weergeven (in de vorm van een cirkel). Bedenk dat een implementatierelatie die in verkorte vorm aan een interface is gekoppeld, wordt weergegeven als een eenvoudige ononderbroken lijn (als een associatie).

Koppel zoekopdrachtstudent wordt weergegeven met een indicatie van de lijst met bewerkingen via een stereotiepe klasse, terwijl de implementatierelatie wordt weergegeven als een gestippelde pijl met een gesloten punt.

Natuurlijk wordt aangenomen dat de geïntroduceerde interfaces worden geïmplementeerd door middel van de klassen waaraan ze zijn gekoppeld door de implementatierelatie, dat wil zeggen dat de overeenkomstige klassen bewerkingen en methoden bevatten die de gedeclareerde interfaces implementeren. Om de waarneming te vergemakkelijken, worden deze mechanismen niet gevisualiseerd.

Om toegangsrechten en gebruikersautorisatie te beheren, introduceren we de klasse managertoegang. De toegangsbeheerder heeft een kenmerk van het privétoegangstype tafelwachtwoorden, wat een instantie van de klasse is CodirTabel(gecodeerde tabel) met wachtwoorden ( wachtwoord) en invoernamen ( Log in) administrator-gebruikers. Aangenomen wordt dat de mogelijkheden van de utility class CodirTabel voorkomen dat onbevoegde gebruikers gebruikerswachtwoorden lezen. In deze ontwerpfase declareren we eenvoudigweg dergelijke capaciteiten, we blijven niet stilstaan ​​bij het mechanisme voor hun implementatie, maar gaan ervan uit dat ze zijn ingekapseld in een klasse CodirTabel.

Klas managertoegang bevat openstaande transacties invoerwachtwoord en het toekennen van beheerdersrechten, waarmee autorisatie- en toegangsrechtenbeheer wordt uitgevoerd.

Geef de afhankelijkheid aan tussen de gegevensbewerkingsinterface ( bewerken) en een toegangsbeheerder, ervan uitgaande dat volledige mogelijkheden Alleen gebruikers met beheerdersrechten kunnen gegevens bewerken.

Rijst. 6. Het definitieve klassenschema van de werkplek van de secretaresse van de afdeling

Het uiteindelijke diagram wordt getoond in Fig. 6.

Dus het ontwikkelen van een object-georiënteerd model van de werkplek van de secretaresse van de afdeling aan de hand van het schema UML-klassen in dit stadium kan als voltooid worden beschouwd. Uiteraard is het mogelijk om hiernaar terug te keren en enkele elementen te herzien tijdens het systeemontwerp, bij het aanpassen van taken, bij het verduidelijken individuele onderdelen. Het proces van het ontwerpen van informatiesystemen is iteratief. Opgemerkt moet worden dat het ontwikkelde klassendiagram elementen bevat die expliciet of impliciet alle use cases van het use case diagram implementeren. Elke use-case van een use-case-diagram moet overeenkomen met een interface of een interface-operatie (de implementatie wordt verondersteld in de klassen die overeenkomen met de interface), of een public class-operatie, of een reeks publieke operaties (in dit geval de use case wordt rechtstreeks geïmplementeerd door de overeenkomstige klasse of reeks klassen).

Laten we eens kijken naar het proces van het maken van een nieuw record over een student met behulp van reeksdiagrammen.

Voor het maken van een nieuw record zijn beheerdersrechten vereist, dus de actor in deze interactie is de beheerder ( beheerder). Dit element is al ingevoerd in het Use Case Diagram, dus laten we het naar het Sequence Diagram slepen vanuit de Use Case View Browser.

Opgemerkt moet worden dat objecten, dat wil zeggen specifieke instanties van klassen, verschijnen op interactiediagrammen (de naam van het object is altijd onderstreept).

Wij beheren objecten: formulierinvoer, managerverslagen, studentendossier Petrov(als een specifiek voorbeeld van een studentendossier), managertransacties. Deze set objecten is typerend bij het wijzigen van een record in een databasetabel.

Formulierinvoer- onderdeel gebruikersomgeving, is een typisch formulier voor het invoeren van gegevens over een student (achternaam, voornaam, patroniem, adres, enz.). In ons geval vertegenwoordigt het een enigszins vooraf gedefinieerde concrete implementatie standaard interface bewerken klas elektronischtafel. Aangezien we de interface voor het bewerken van leerlinggegevens in het klassendiagram niet specifiek hebben geïntroduceerd, specificeert u daarom expliciet de klasse voor het object formulierinvoer we zullen niet.

Managerverslagen- een object dat een standaard set gegevensbeheermogelijkheden heeft bij het werken met rekenblad. Deze set mogelijkheden wordt geërfd door de klasse studenten uit de klas elektronischtafel. Voor voorwerp Managerverslagen specificeert expliciet de klasse waarvan het een instantie is - studenten.

Petrov- een specifiek record over student Petrov, een nieuw element van de tabel over studenten. Hier geven we expliciet de geïntroduceerde klasse aan dossierOstudent. Dergelijke objecten bestaan ​​meestal tijdelijk om tijdens transacties de relevante informatie naar de database te sturen. Na het einde van de transactie gegeven voorwerp kan worden vernietigd. Het object dat overeenkomt met het record kan opnieuw worden gemaakt als de informatie moet worden bewerkt.

Managertransacties- een object dat zorgt voor de uitvoering van een volledige bewerking op de database, in dit geval het maken van een nieuw record over de student Petrov. Dit object is ook verantwoordelijk voor de uitvoering van een aantal systeem functies bij de transactie horen. Voorbeelden van transactiemanagers zijn bijvoorbeeld BDE (gebruikt voor toegang tot Paradox, Dbase, enz. databases vanuit Delphi-applicaties), ADO (gebruikt voor toegang tot MS Access-databases vanuit verschillende applicaties).

Het diagram van de volgorde van het invoeren van een nieuw record over een student op de werkplek van de secretaresse van de afdeling wordt getoond in Fig. 7.

Rijst. 7. Invoeren leerlinggegevens. Volgorde diagram.

Op het sequentiediagram definiëren we de overdracht van berichten tussen objecten: creërennieuwdossier(uitgezonden van object naar object naar het einde van de keten als een bericht reddendossier); openformulier(naar het invoerformulier); binnenkomenF.EN OVER.,adres. ( gegevensinvoer voor een leerling), dan worden deze gegevens via berichten uitgezonden reddenF.EN OVER.,adres. Van managertransacties er wordt een bericht gestuurd om te verzamelen informatieOstudent, feedback geven aan de database en tot slot een reflectieve boodschap managertransacties benoemd als reddendossierVDB, zorgt voor het einde van de transactie.

Indien gewenst kan dat deze interactie vertegenwoordigen een diagram van samenwerking, dat allereerst het structurele aspect van interactie illustreert (Fig. 8). Deze grafiek kan worden opgebouwd uit de vorige automatische modus(in Rational Rose door op F5 te drukken).

Rijst. 8. Invoeren leerlinggegevens. Samenwerkingsschema.

Indien nodig kan het project worden aangevuld met andere interactiediagrammen die het werk van precedenten onthullen.

4.3 Ontwerpen van een relationeel databaseprofiel

In het geval dat een objectgeoriënteerd DBMS (OODBMS) wordt gebruikt om het systeem te implementeren, is het objectdiagram dat in de vorige sectie is gebouwd het definitieve model en de directe gids voor de implementatie van het informatiesysteem. In hetzelfde geval, wanneer een relationele database (RDB) wordt verondersteld te worden gebruikt als de informatiekern van het informatiesysteem, is het noodzakelijk om een ​​ander diagram te ontwikkelen, een relationeel databaseprofieldiagram.

Het UML-profiel voor een databaseproject is een UML-extensie die het UML-metamodel intact houdt. Een profiel voor een databaseproject voegt stereotypen en getagde waarden toe aan die stereotypen, maar verandert niets aan het onderliggende UML-metamodel. Om de ontwerpelementen van de database en de regels voor het ontwerpen van relationele databases te visualiseren, worden de bijbehorende pictogrammen toegevoegd aan het profiel (hierna simpelweg databases). De database wordt beschreven aan de hand van tabellen, kolommen en relaties. Het profiel heeft elementen die de database uitbreiden, zoals triggers, opgeslagen procedures, beperkingen, typen, gebruiker gedefinieerde(domeinen), weergaven en andere. Het profiel laat zien hoe en waar al deze elementen in het model worden gebruikt. De volgende entiteiten zijn gedefinieerd op het UML-databaseprofiel:

Tafel ( Tabel) - een set records in de database voor een specifiek object, bestaat uit kolommen.

Kolom ( Kolom) is een tabelcomponent die een van de tabelattributen (tabelveld) bevat.

Primair sleutel ( Primaire sleutel) is een mogelijke sleutel die wordt gekozen om tabelrijen te identificeren.

Extern sleutel (vreemde sleutel) - een of meer kolommen van een tabel, die zijn primaire sleutels een andere tafel.

Prestatie ( View) - een virtuele tafel die zich vanuit het oogpunt van de gebruiker op dezelfde manier gedraagt ​​als een gewone tafel, maar die niet op zichzelf staat.

opgeslagen procedure ( Een opgeslagen procedure is een onafhankelijke procedurele functie die op de server wordt uitgevoerd.

Domeinen ( Domains) is een geldige set waarden voor een attribuut of kolom.

Naast deze entiteiten kunnen enkele extra entiteiten worden geïntroduceerd, reflecterend specifieke aspecten database modellen.

Vergelijkbare documenten

Methodologieën voor de ontwikkeling van informatiesystemen in binnen- en buitenlandse literatuur. Nationale en internationale standaarden op het gebied van softwareontwikkeling. Ontwikkeling van een fragment van het informatiesysteem "Educatieve en methodologische hulpbron".

scriptie, toegevoegd 28-05-2009


Definitie van het begrip "systeem". Ontwikkelingsgeschiedenis en kenmerken van moderne informatiesystemen. De belangrijkste fasen in de ontwikkeling van een geautomatiseerd informatiesysteem. Het gebruik van binnenlandse en internationale standaarden op het gebied van informatiesystemen.

presentatie, toegevoegd 14/10/2013


Het belangrijkste idee van de methodologie en principes van RAD-ontwikkeling van informatiesystemen, zijn belangrijkste voordelen. Redenen voor populariteit, kenmerken van de toepassing van technologie. Formulering van de belangrijkste ontwikkelingsprincipes. Ontwikkelomgevingen met behulp van RAD-principes.

presentatie, toegevoegd 04/02/2013


De rol van de managementstructuur in het informatiesysteem. Voorbeelden van informatiesystemen. Structuur en classificatie van informatiesystemen. Informatie Technologie. Stadia van ontwikkeling van informatietechnologieën. Soorten informatietechnologieën.

scriptie, toegevoegd 17-06-2003


Het concept van CASE-tools als softwaretools die de processen van het creëren en onderhouden van informatiesystemen (IS) ondersteunen. Kenmerken van IDEF-technologieën voor IS-ontwikkeling. Beschrijving van IDEF0-notatie. Ontwikkeling van functionele bedrijfsprocesmodellen.

presentatie, toegevoegd 04/07/2013


De essentie van de uniforme modelleringstaal, het conceptuele model en het werkingsprincipe, algemene regels en mechanismen. Modellering van het concept van "competentie". Klassendiagram beschrijven educatief proces. Implementatie van een bepaald informatiesysteem.

scriptie, toegevoegd 17/02/2015


Ontwikkeling van informatiesystemen. Moderne markt financiële en economische applicatiesoftware. Voor- en nadelen van het invoeren van geautomatiseerde informatiesystemen. Methoden voor het ontwerpen van geautomatiseerde informatiesystemen.

proefschrift, toegevoegd 22-11-2015


Het concept van een informatiesysteem, soorten informatiesystemen. Analyse hulpmiddelen voor de ontwikkeling van geautomatiseerde informatiesystemen. Vereisten voor het programma en het softwareproduct. Ontwikkeling van GUI-formulieren en databases.

scriptie, toegevoegd 23-06-2015


Oplossing voor informatiebeveiliging. Systemen voor datacenters. Wat is datacenterapparatuur. Basisconcepten en principes van modellering. Een methode kiezen om problemen op te lossen. Seutendijk toelaatbare richtingsmethode, Frank-Wulf-algoritme.

scriptie, toegevoegd 18-05-2017


Het concept van een informatiesysteem. Stadia van ontwikkeling van informatiesystemen. Processen in het informatiesysteem. Informatiesysteem voor het vinden van marktniches, voor het verlagen van de productiekosten. De structuur van het informatiesysteem. Technische hulp.

"Computerwiskundig modelleren" Problemen bij het bestuderen van de sectie. Beheersing van modellering als een methode om de omringende realiteit te kennen (onderzoekskarakter van de sectie) - het is aangetoond dat modellering in verschillende kennisgebieden vergelijkbare kenmerken heeft, vaak kunnen zeer nauwkeurige modellen worden verkregen voor verschillende processen; - toont voor- en nadelen computerexperiment in vergelijking met het natuurlijke experiment; - dat wordt aangetoond abstract model, en de computer bieden de mogelijkheid om de wereld om ons heen te leren kennen en te beheersen in het belang van de mens. Ontwikkeling van praktische vaardigheden van computermodellering. De algemene methodologie van de computer wiskundige modellering. Aan de hand van een aantal modellen uit verschillende wetenschaps- en praktijkgebieden worden alle stadia van het modelleren praktisch geïmplementeerd, van de formulering van het probleem tot de interpretatie van de resultaten verkregen in de loop van een computerexperiment. Bevordering van beroepskeuzebegeleiding voor studenten. Identificatie van de neiging van de student om onderzoeksactiviteiten, ontwikkeling van creatief potentieel, oriëntatie op de keuze van een beroep gerelateerd aan wetenschappelijk onderzoek. Het overwinnen van onenigheid over onderwerpen, integratie van kennis. Als onderdeel van de cursus worden modellen uit verschillende wetenschapsgebieden bestudeerd met behulp van wiskunde. Ontwikkeling en professionalisering van computervaardigheden. Beheersing van software voor algemene en gespecialiseerde doeleinden, programmeersystemen.

Het concept van een model staat centraal algemene theorie systemen. Modelleren als een krachtige - en vaak de enige - onderzoeksmethode impliceert de vervanging van een reëel object door een ander - materiaal of ideaal.
De belangrijkste vereisten voor elk model zijn de geschiktheid ervan voor het bestudeerde object binnen het kader van een specifieke taak en de haalbaarheid ervan met de beschikbare middelen.
In efficiëntietheorie en informatica is een model van een object (systeem, werking) een materieel of ideaal (mentaal representeerbaar) systeem dat is gemaakt en/of wordt gebruikt bij het oplossen van een specifiek probleem om nieuwe kennis over het oorspronkelijke object te verkrijgen, die daarvoor geschikt is. in termen van de bestudeerde eigenschappen en eenvoudiger dan het origineel in andere aspecten.
De classificatie van de belangrijkste modelleringsmethoden (en de modellen die daarmee overeenkomen) wordt getoond in Fig. 3.1.1.
Bij de studie van economische informatiesystemen (EIS) worden alle modelleringsmethoden gebruikt, maar in deze sectie zal de meeste aandacht uitgaan naar semiotische (teken)methoden.
Bedenk dat semiotiek (van het Griekse semeion - teken, teken) de wetenschap is van algemene eigenschappen tekensystemen, d.w.z. systemen van concrete of abstracte objecten (tekens), waaraan elk een bepaalde waarde is gekoppeld. Voorbeelden van dergelijke systemen zijn alle talen

Rijst. 3.1.1. Classificatie van modelleringsmethoden

(natuurlijk of kunstmatig, bijvoorbeeld databeschrijving of modelleertalen), signaleringssystemen in de samenleving en de dierenwereld, enz.
Semiotiek omvat drie secties: syntactiek; semantiek; pragmatiek.
Syntactiek onderzoekt de syntaxis van tekensystemen zonder rekening te houden met interpretaties en problemen die verband houden met de perceptie van tekensystemen als communicatiemiddel en communicatiemiddel.
Semantiek bestudeert de interpretatie van de uitspraken van een tekensysteem en neemt, vanuit het oogpunt van het modelleren van objecten, de belangrijkste plaats in in de semiotiek.
Pragmatiek onderzoekt de houding van de gebruiker van het tekensysteem ten opzichte van het tekensysteem zelf, in het bijzonder de perceptie van betekenisvolle uitdrukkingen van het tekensysteem.
Van de vele semiotische modellen, vanwege de grootste verspreiding, vooral in de omstandigheden van informatisering van de moderne samenleving en de introductie van formele methoden op alle gebieden van menselijke activiteit, kiezen we wiskundige die echte systemen weergeven met behulp van wiskundige symbolen. Tegelijkertijd, rekening houdend met het feit dat we modelleringsmethoden overwegen in relatie tot de studie van systemen in verschillende operaties, zullen we de bekende methodologie van systeemanalyse, efficiëntietheorie en besluitvorming gebruiken.

Meer over het onderwerp 3. TECHNOLOGIE VAN SIMULATIE VAN INFORMATIESYSTEMEN Methoden voor het modelleren van systemen:

1. Simulatiemodellen van economische informatiesystemen Methodologische grondslagen voor de toepassing van de simulatiemethode
2. Sectie III BASIS VAN HET MODELLEN VAN HET SYSTEEM VAN MARKETINGDIENSTEN
3. HOOFDSTUK 1. GECONTROLEERDE DYNAMISCHE SYSTEMEN ALS OBJECT VAN COMPUTERSIMULATIE
4. Grondbeginselen van structurele modellering van het marketingsysteem van medische diensten
5. Sectie IV VOORBEELD VAN TOEGEPAST GEBRUIK VAN HET MARKETINGSYSTEEMMODEL IN SIMULATIEMODELLING
6. Het concept van het modelleren van de financiële sfeer van marketingsystemen

Leerboek voor universiteiten

2e druk, herzien. en aanvullend

2014 G.

Oplage 1000 exemplaren.

Formaat 60x90/16 (145x215 mm)

Versie: paperback

ISBN-nummer 978-5-9912-0193-3

BBC 32.882

UDC 621.395

Gier UMO
Aanbevolen door de UMO voor onderwijs op het gebied van telecommunicatie als studie gids voor studenten van instellingen voor hoger onderwijs die studeren in de specialiteiten "Netwerken en schakelsystemen", "Meerkanaals telecommunicatiesystemen"

annotatie

Algoritmen voor het modelleren van discreet en continu willekeurige variabelen en processen. De principes en algoritmen van modellering worden vermeld informatie signalen, beschreven door Markov processen met discrete en continue tijd De principes van het modelleren van wachtrijsystemen worden beschouwd. Kenmerken van de beschrijving en het gebruik van fractale en multifractale processen voor het modelleren van telecommunicatieverkeer worden beschreven. Methoden en voorbeelden van het modelleren van informatiesystemen met behulp van gespecialiseerde applicatiepakketten worden geanalyseerd. Matlab-programma's, Opnet, netwerksimulator.

Voor studenten die studeren in de specialiteiten "Netwerken en schakelsystemen", "Meerkanaals telecommunicatiesystemen", "Informatiesystemen en technologieën".

Invoering

1 Algemene principes van systeemmodellering
1.1. Algemene concepten modelleren en simuleren
1.2. Model classificatie
1.3. Structuur van modellen
1.4. Methodologische grondslagen voor het formaliseren van de werking van een complex systeem
1.5. Componentmodellering
1.6. Stadia van vorming van een wiskundig model
1.7. Simulatie
Controle vragen

2 Algemene principes van het bouwen van communicatiesystemen en netwerken
2.1. Het concept van het bouwen van communicatiesystemen en netwerken
2.2. Gelaagde netwerkmodellen
2.2.1. Model met drie niveaus
2.2.2. Architectuur van TCP/IP-protocollen
2.2.3. referentiemodel OSI
2.3. De structuur van communicatienetwerken
2.3.1. wereldwijde netwerken
2.3.2. Lokale netwerken
2.3.3. Topologieën van een computernetwerk
2.3.4. Lokale netwerken ethernet
2.4. Frame relay-netwerken
2.5. IP-telefonie
Controle vragen

3 Willekeurige getallen modelleren
3.1. Algemene informatie over willekeurige getallen
3.2. Programmatische methoden voor het genereren van uniform verdeelde willekeurige getallen
3.3. Vorming van willekeurige variabelen met een gegeven verdelingswet
3.3.1. Inverse functiemethode
3.3.2. Geschatte methoden voor het converteren van willekeurige getallen
3.3.3. Screeningsmethode (Neumann-generatiemethode)
3.4. Methoden gebaseerd op de centrale limietstelling
3.5. Algoritmen voor het modelleren van veelgebruikte willekeurige variabelen
3.6. Algoritmen voor het modelleren van gecorreleerde willekeurige variabelen
3.7. Vorming van implementaties van willekeurige vectoren en functies
3.7.1. Simulatie van een n-dimensionaal willekeurig punt met onafhankelijke coördinaten
3.7.2. Vorming van een willekeurige vector (in het kader van de correlatietheorie)
3.7.3. Vorming van implementaties van willekeurige functies

4 Modellering van discrete distributies
4.1. Bernoulli-distributie
4.2. Binominale verdeling
4.3. Poisson-verdeling
4.4. Simulatie van tests in het schema van willekeurige gebeurtenissen
4.4.1. Simulatie van willekeurige gebeurtenissen
4.4.2. Simulatie van tegenovergestelde gebeurtenissen
4.4.3. Modellering van een discrete willekeurige variabele
4.4.4. Simulatie van een complete groep gebeurtenissen
4.5. Gebeurtenisstromen
4.6. Simulatieresultaten verwerken
4.6.1. Nauwkeurigheid en aantal realisaties
4.6.2. Primair statistische verwerking gegevens
Controle vragen

5 Algoritmen voor het modelleren van stochastische signalen en interferentie in communicatiesystemen
5.1. Algoritme voor het modelleren van niet-stationaire willekeurige processen
5.2. Algoritmen voor het modelleren van stationaire willekeurige processen
5.3. Methoden voor het modelleren van signalen en ruis in de vorm van stochastische differentiaalvergelijkingen
5.4. Voorbeelden van modellen van willekeurige processen in communicatiesystemen
5.4.1. Informatie Proces Modellen
5.4.2. Interferentiemodellen
5.4.3. Kenmerken van de belangrijkste soorten interferentie
Controle vragen

6 Markov stochastische processen en hun modellering
6.1. Basisconcepten van een Markov stochastisch proces
6.2. Basiseigenschappen van discrete Markov-ketens
6.3. Doorlopende Markov-ketens
6.3.1. Basisconcepten
6.3.2. Semi-Markov-processen
6.3.3. De processen van dood en voortplanting
6.4. Modellen van willekeurige Markov-processen met continue waarde op basis van stochastische differentiaalvergelijkingen
6.5. Modellering van Markov stochastische processen
6.5.1. Modellering van discrete processen
6.5.2. Modellering van scalaire processen met continue waarde
6.5.3. Modellering van continu gewaardeerde vectorprocessen
6.5.4. Modelleren van een Gaussiaans proces met fractionele rationele spectrale dichtheid
6.5.5. Modellering van meervoudig verbonden reeksen
6.5.6. Markov-processen modelleren met vormfilters
6.5.7. Algoritme voor statistische modellering van Markov-ketens
Controle vragen

7 Voorbeelden van Markov-modellen
7.1. Markov-modellen van spraakdialoog van abonnees
7.1.1. Spraaktoestanden
7.1.2. Dialoog modellen
7.2. Markov-modellen van spraakmonoloog
7.3. Poisson-proces aangedreven door Markov-proces in spraakmodellen
7.4. Markov-modellen van digitale reeksen aan de uitgang van de G.728-codec
7.5. Statistische multiplexing van de bron van spraakpakketten, rekening houdend met het Markov-model van een telefoondialoog
7.6. Markov-model draadloos kanaal met ARQ/FEC-mechanisme
7.7. Fout verpakking
7.8. Berekening van foutstroomkarakteristieken op basis van modelparameters
7.8.1. Foutstroomparameters schatten
7.8.2. Beoordeling van de adequaatheid van het foutenstroommodel
7.9. Markov-modellen voor het evalueren van de QoS van real-time multimediadiensten op internet
7.9.1. Het concept van real-time multimediadiensten
7.9.2. Analyse en modellering van vertragingen en verliezen
7.10. Modellen van multimediale verkeersstromen
Controle vragen

8 Wachtrijsystemen en hun modellering
8.1. Algemene kenmerken van wachtrijsystemen
8.2. Structuur van het wachtrijsysteem
8.3. Wachtrij systemen
8.3.1. Servicesysteem M/M/1
8.3.2. Servicesysteem M/G/1
8.3.3. Netwerken met een groot aantal knooppunten verbonden door communicatiekanalen
8.3.4. Prioritaire dienst
8.3.5. Servicesysteem M/M/N/m
8.4. Wachtrijsystemen met storingen
8.5. Algemene principes voor het modelleren van wachtrijsystemen
8.5.1. Statistische testmethode
8.5.2. Blokmodellen van systeemfunctionerende processen
8.5.3. Kenmerken van modelleren met behulp van Q-schema's
Controle vragen

9 Modellering van informatiesystemen met standaard technische middelen
9.1. Systeemmodellering en programmeertalen
9.2. De GPSS-taal begrijpen
9.2.1. Dynamische GPSS-objecten. Transactie-georiënteerde blokken (verklaringen)
9.2.2. Hardware-georiënteerde blokken (Statements)
9.2.3. Omnichannel-service
9.2.4. GPSS-statistische blokken
9.2.5. GPSS-bedieningseenheden
9.2.6. Andere GPSS-eenheden
9.3. Simulatiemodellering van het ETHERNET-netwerk in de GPSS-omgeving
Controle vragen

10 Modellering van informatietransmissiesystemen
10.1. Typisch systeem dataoverdracht
10.2. Transmissie-immuniteit discrete signalen. Optimale ontvangst
10.3. Schatting van de waarschijnlijkheid van foutieve ontvangst van discrete signalen met volledig bekende parameters
10.4. Ruisimmuniteit van discrete signalen met willekeurige parameters
10.5. Ruisimmuniteit van discrete signalen met niet-coherente ontvangst
10.6. Ruisimmuniteit van discrete signalen met willekeurige essentiële parameters
10.7. Algoritmen voor het genereren van discrete signalen
10.8. Algoritme voor het genereren van interferentie
10.9. Discreet signaaldemodulatie-algoritme
10.10. De structuur van het simulatiecomplex en zijn subroutines
10.11. Software-omgeving Mathworks Matlab en Simulink visueel simulatiepakket
10.11.1. Technische beschrijving en interface
10.11.2. Simulink visueel simulatiepakket
10.11.3. Subsystemen maken en maskeren
10.11.4. Communications Toolbox-uitbreidingspakket
10.12. Simulatie van blokken van het datatransmissiesysteem van de WiMAX-standaard
10.12.1. Zender simulatie
10.12.2. Modellering van transmissiekanalen
10.12.3. Ontvanger simulatie
10.12.4. Modelimplementatie in Mathlab
10.13. resultaten simulatie modellering WiMAX-systemen
Controle vragen

11 Op zichzelf gelijkende processen en hun toepassing in de telecommunicatie
11.1. Grondbeginselen van de theorie van fractale processen
11.2. Multifractale processen
11.3. Schatting van de Hurst-exponent
11.4. Multifractale analyse met behulp van software
11.4.1. Beschrijving van de programmatuur
11.4.2. Voorbeelden van het beoordelen van de mate van zelfgelijkenis
11.5. Algoritmen en software voor multifractale analyse
11.6. Invloed van verkeerszelfgelijkenis op de kenmerken van het servicesysteem
11.7. Methoden voor het modelleren van zelfgelijkende processen in tv-verkeer
11.8. Onderzoek naar de zelfgelijkende structuur van Ethernet-verkeer
11.9. Congestiebeheer van op zichzelf gelijkend verkeer
11.10. fractale Brownse beweging
11.10.1. RMD FBD Generatie-algoritme
11.10.2. SRA-algoritme voor het genereren van FBD
11.12. Fractale Gaussiaanse ruis
11.12.1. FGN-synthese-algoritme
11.12.2. Evaluatie van simulatieresultaten
Controle vragen

12 Modelleren van een
12.1. Grondbeginselen van het Frame Relay Protocol
12.2. Frame Relay-netwerkknooppuntontwerp
12.3. Simulatieresultaten van FR-router met G.728-codecs aan de ingang
12.4. Impact van verkeerszelfgelijkenis op QoS
Controle vragen

13 Gespecialiseerde systemen voor simulatiemodellering van computernetwerken
13.1. Algemene kenmerken van gespecialiseerde pakketten van toegepaste programma's voor netwerkmodellering
13.2. Algemene principes van modellering in de OPNET Modeler-omgeving
13.3. OPNET-toepassingsvoorbeelden
13.3.1. Model voor het beoordelen van de kwaliteit van de dienstverlening
13.3.2. Implementatie van het lokale netwerkmodel
Controle vragen

14 Simulatie met Netwerksimulator 2
14.1. Aanmaakgeschiedenis en architectuur van het NS2-pakket
14.2. Een simulatorobject maken
14.3. Maak een netwerktopologie
14.4. Generatorparameters instellen
14.4.1. Exponentieel aan/uit
14.4.2. Pareto aan/uit
14.5. Twee belangrijke wachtrij-algoritmen
14.6. Adaptieve routering in NS2
14.6.1. Applicatieprogrammeerinterface op gebruikersniveau
14.6.2. Interne architectuur
14.6.3. Uitbreidingen naar andere klassen
14.6.4. Gebreken
14.6.5. Lijst met opdrachten die worden gebruikt om dynamische scenario's in NS2 te simuleren
14.6.6. Voorbeeld dynamische routering bij NS2
14.7. Een scriptprogramma uitvoeren in NS2
14.8. Procedure voor het verwerken van simulatieresultaten
14.9. Voorbeeld van draadloze netwerksimulatie
14.10. Voorbeeld van simulatie van transmissiekwaliteit video streamen met pakket NS 2
14.10.1. De structuur van het software- en hardwarecomplex voor het beoordelen van de kwaliteit van streaming video
14.10.2. Functionele modules PAK
14.10.3. Beoordeling videokwaliteit

Bij conceptueel ontwerp IS's gebruiken een aantal beschrijvingen van specificaties (eisen, voorwaarden, beperkingen, enz.), waarvan de centrale plaats wordt ingenomen door modellen van transformatie, opslag en overdracht van informatie. De modellen die zijn verkregen tijdens de studie van het vakgebied, tijdens het ontwikkelen van een IS, veranderen en worden modellen van de ontworpen IS.

Er zijn functionele, informatieve, gedrags- en structurele modellen. Het functionele model van het systeem beschrijft de reeks functies die door het systeem worden uitgevoerd. Informatiemodellen weerspiegelen datastructuren - hun samenstelling en relaties. Gedragsmodellen beschrijven informatie processen(dynamiek van het functioneren), ze omvatten categorieën als de toestand van het systeem, de gebeurtenis, de overgang van de ene toestand naar de andere, de overgangsvoorwaarden, de opeenvolging van gebeurtenissen. Structurele modellen karakteriseren de morfologie van het systeem (de constructie ervan) - de samenstelling van subsystemen, hun onderlinge relaties.

Er zijn een aantal manieren om modellen te bouwen en weer te geven, verschillend voor modellen ander type. De basis is structurele analyse - een methode om een ​​systeem te bestuderen, dat begint met zijn Overzicht en dan vindt verfijning plaats, waardoor een hiërarchische structuur ontstaat met steeds meer niveaus.

In deze handleiding gaan we in op de methodologie voor het construeren van structureel-functionele en informatiemodellen van IS en het ontwerpen van een relationele database op basis daarvan, waarbij we dit proces illustreren met een specifiek trainingsvoorbeeld met de volgende inhoud.

In verband met de diversificatie van activiteiten is van het management van Bezenchuk and Companions een opdracht ontvangen voor de ontwikkeling van een informatiesysteem om de efficiëntie van het management te verbeteren.

Het bedrijf houdt zich bezig met de productie en verkoop van meubelen. Er is een catalogus met typische meubels die door het bedrijf zijn geproduceerd. De klant kan meubels uit de catalogus kiezen en/of een bestelling plaatsen eigen omschrijving. Na totstandkoming van de bestelling wordt een contract opgesteld. Het bedrijf accepteert oude meubels van klanten van nieuwe meubels, waarvan de kosten worden afgetrokken van de prijs van de bestelling. Geaccepteerde oude meubels worden te koop aangeboden of kunnen worden gehuurd. Niet-afgehaalde oude meubels worden na een bepaalde periode verhuurd aan een houtmagazijn. Er wordt een archief bijgehouden met informatie over afgeronde bestellingen. Klanten die eerder contracten met het bedrijf hebben afgesloten, krijgen korting bij het afsluiten van een nieuw contract. Het bedrijf koopt materialen en componenten die nodig zijn voor de fabricage van meubels van leveranciers.

Functionele modellering van IC

Er zijn verschillende methoden en hulpmiddelen voor het ontwikkelen van structurele en functionele modellen van IS. Een van de meest voorkomende is de methode die gebaseerd is op de constructie van datastroomdiagrammen (DFD - Data Flow Diagrams).

Gegevensstroomschema

DFD-methode structurele analyse, dat werkt met de concepten "gegevensstroom" en "proces" om het systeem te beschrijven als een reeks functionele componenten (processen) verbonden door gegevensstromen. In overeenstemming met het basisprincipe van structurele analyse, is de beschrijving van het systeem gebaseerd op de sequentiële detaillering van zijn functies, die wordt weergegeven als een hiërarchisch georganiseerde reeks grafische afbeeldingen (diagrammen).

De belangrijkste elementen van gegevensstroomdiagrammen zijn: externe entiteiten; processen; apparaten voor gegevensopslag; gegevensstromen. Elk van deze elementen heeft een standaard grafische afbeelding.

Een externe entiteit is een object dat een bron of ontvanger van informatie is, bijvoorbeeld klanten, personeel, leveranciers, klanten, magazijn. De definitie van een object of systeem als een externe entiteit geeft aan dat het zich buiten de grenzen van de geprojecteerde IS bevindt.

De externe entiteiten in het bovenstaande voorbeeld zijn meubelklanten, materiaalleveranciers, een magazijn en enkele andere domeinobjecten. Voorbeelden van hun grafische afbeeldingen:

De functies van de ontworpen IS in het DFD-model moeten worden gepresenteerd als processen die invoergegevensstromen omzetten in uitvoergegevens in overeenstemming met bepaalde algoritmen. De gegevensstromen zelf zijn een mechanisme dat de overdracht van informatie van een bron naar een ontvanger (van het ene deel van het systeem naar het andere) simuleert. De gegevensstroom in het diagram wordt weergegeven door een lijn die eindigt met een pijl die de richting van de stroom aangeeft. Elke gegevensstroom moet een naam hebben die de inhoud weerspiegelt.

Zo kan de IS-functie bedoeld voor het opstellen van een bestelling voor meubels en het sluiten van een overeenkomst voor de vervaardiging ervan in het diagram worden weergegeven door het proces "Meubelbestelling". Dit proces moet als invoergegevens over de klant ontvangen, noodzakelijk voor het sluiten van het contract en informatie over het door hem bestelde meubilair (type, beschrijving, afmetingen, enz.). Grafische afbeelding dit proces en de bijbehorende datastromen:

Een datadrive (storage) is een abstract apparaat voor het opslaan van informatie die op elk moment in een drive kan worden geplaatst en kan worden opgehaald voor verder gebruik. Informatie in de schijf kan afkomstig zijn van externe entiteiten en processen, ze kunnen ook consumenten zijn van informatie die in de schijf is opgeslagen. Aandrijving grafisch:

Context diagram

Diagram hoogste niveau hiërarchie, het vastleggen van de hoofdprocessen of subsystemen van IS en hun relatie met externe entiteiten (invoer en uitvoer van het systeem), wordt een contextdiagram genoemd. Gewoonlijk wordt bij het ontwerpen van relatief eenvoudige IC's een enkel contextdiagram met een stertopologie gebouwd, met in het midden een hoofdproces dat is verbonden met ontvangers en informatiebronnen (gebruikers en andere externe systemen). Hoewel het contextdiagram misschien triviaal lijkt, ligt het onmiskenbare nut ervan in het feit dat het de grenzen van het te analyseren systeem vastlegt en het hoofddoel van het systeem bepaalt. Dit bepaalt de context waarin diagrammen op een lager niveau bestaan ​​met hun processen, stromen en drijfveren.

Het contextdiagram voor het hierboven beschreven voorbeeld wordt weergegeven in figuur 4.

Opgemerkt moet worden dat voor educatieve doeleinden hieronder een vereenvoudigde versie van de systeemmodellen wordt beschouwd, waarin gegevensstromen en processen met betrekking tot de financiële kant van de activiteiten van het bedrijf niet worden gepresenteerd. Hoewel voor elk bedrijf tijdige, volledige en betrouwbare informatie over zijn financiële toestand natuurlijk van vitaal belang is. In dit voorbeeld is de "financiële component" duidelijk aanwezig in de interactie van het bedrijf met alle externe entiteiten die in het contextdiagram worden weergegeven.

De externe entiteiten die in dit diagram worden gepresenteerd, fungeren als informatiebronnen die worden opgeslagen en verwerkt in de IS van het bedrijf, en als consumenten van deze informatie. In dit model worden twee entiteiten "klant" onderscheiden, namelijk afbeeldingen echte klanten bedrijven: "klant" en "koper", aangezien er aanzienlijke verschillen zijn in de inhoud van de informatie die zij met IS uitwisselen.

Voor de "klant-klant" is de datastroom "catalogus" een beschrijving van de typische meubels die door het bedrijf worden geproduceerd. De bestelgegevensstroom kan bestelinformatie bevatten voor meubelen geselecteerd uit een catalogus en/of een beschrijving door de klant van meubelen die niet in de catalogus staan ​​en mogelijk ook informatie over oude meubelen die door de klant aan een bedrijf zijn verkocht.

Voor de “klant-koper” is de datastroom “oude meubelcatalogus” informatie over de beschikbare oude meubelen ontvangen van klanten. De stroom "koop/huur van oude meubels" is informatie over de oude meubels die door de klant zijn geselecteerd en die hij wil kopen of huren.

Tegelijkertijd zijn er in de praktijk situaties mogelijk waarin de "klant-klant" en "klant-koper" dezelfde persoon zijn.