Een objectmodel bouwen. Objecten worden gekenmerkt door attributen

Een objectmodel bouwen van het vakgebied "organisatie van sportclubprocessen" met behulp van de UML-modelleertaal

1. THEORETISCHE BASISBEPALINGEN VAN OBJECTGERICHTE METHODOLOGIE

1.1 Basisconcepten van de objectgeoriënteerde benadering

onderwerp taal programmeermodel

Programmeren heeft lange tijd gebruik gemaakt van een gestructureerd procedureel model. De keuze van de projectdoelstellingen wordt uitgevoerd door een van de twee benaderingen, genaamd "top-down" en dienovereenkomstig "bottom-up"

1. De 'top-down'-benadering houdt in dat de taak wordt opgedeeld in subtaken, die op hun beurt weer in subtaken van het volgende niveau, enzovoort. Dit proces, decompositie genaamd, duurt totdat de vereenvoudiging van deeltaken niet is gereduceerd tot elementaire functies die geformaliseerd kunnen worden.

2. De bottom-upbenadering houdt in dat procedures worden geschreven om eenvoudige problemen op te lossen, waarna ze achtereenvolgens worden gecombineerd tot complexere procedures totdat het gewenste effect is bereikt.

Belangrijke programmeerconcepten zijn procedureel programmeren en objectgeoriënteerd programmeren.

Procedureel georiënteerd programmeren is programmeren in een imperatieve taal, waarin sequentieel uitgevoerde instructies kunnen worden samengevoegd tot subroutines, dat wil zeggen grotere integrale code-eenheden, met behulp van de mechanismen van de taal zelf.

Object Oriented Programming (OOP) is een programmeerstijl die het gedrag van de echte wereld vastlegt op zo'n manier dat de details van de implementatie ervan verborgen zijn.

Een object is een soort afzonderlijke entiteit die zich onderscheidt van andere entiteiten vanwege zijn eigenschappen, gedrag en interactie met andere objecten van de toepassing.

Het gebruik van deze technologie maakt het mogelijk om de structuur van het programma weer te geven in de vorm van een reeks objecten die met elkaar in wisselwerking staan. Als resultaat van een dergelijke interactie, uitgevoerd door berichten tussen objecten door te geven, worden de gespecificeerde programmafuncties geïmplementeerd. Na ontvangst van een bericht kan een object een specifieke actie uitvoeren die een methode wordt genoemd.

Er zijn twee belangrijke verschillen tussen OOP en procedureel programmeren:

1. In OOP selecteert de programmeur eerst klassen uit de beschrijving van het onderwerpgebied, vervolgens wordt een objectmodel gebouwd om het probleem op te lossen, en pas daarna gaat hij verder met de analyse van hun methoden en eigenschappen.

2. Methoden en eigenschappen zijn gekoppeld aan een klasse die bedoeld is om de overeenkomstige bewerkingen uit te voeren.

Als we analyseren hoe een persoon verschillende praktische problemen in de wereld om hem heen oplost, dan kunnen we begrijpen dat deze wereld ook objectgeoriënteerd is. Om bijvoorbeeld naar het werk te gaan, heeft een persoon doorgaans interactie met een object zoals een voertuig. Het voertuig bestaat op zijn beurt uit objecten die, in interactie met elkaar, het in beweging brengen, waardoor een persoon zijn taak realiseert - op het gewenste punt komt. In dit geval hoeft noch de bestuurder, noch de passagier te weten hoe de objecten waaruit het voertuig bestaat, op elkaar inwerken.

Bij objectgeoriënteerd programmeren, zoals in de echte wereld, worden programmagebruikers geïsoleerd van de logica die nodig is om taken uit te voeren. Om bijvoorbeeld een pagina in een teksteditor af te drukken, roept de gebruiker een bepaalde functie aan door op een knop op de werkbalk te drukken, maar ziet hij de interne processen niet plaatsvinden. Wanneer een pagina wordt afgedrukt terwijl het programma draait, vindt er een complexe interactie van objecten plaats, die op hun beurt interactie hebben met de printer.

Bij het maken van een objectgeoriënteerd programma wordt het onderwerpgebied weergegeven als een verzameling objecten die worden gecombineerd tot klassen. De uitvoering van het programma bestaat erin dat de objecten berichten uitwisselen (met elkaar interageren). Bij het presenteren van een echt object dat tot het onderwerpgebied behoort met behulp van een programmaklasse, is het noodzakelijk om de essentiële kenmerken ervan in een echt object te benadrukken en vele andere eigenschappen te negeren, waarbij we ons alleen beperken tot die welke nodig zijn om een praktisch probleem op te lossen. Deze techniek wordt abstractie genoemd.

Abstractie is de selectie van de essentiële kenmerken van een object die het onderscheiden van andere objecten. Bovendien hangt de lijst met essentiële eigenschappen af van de doelen van modellering en kan deze voor verschillende taken compleet anders zijn. Bijvoorbeeld, een object "rat" vanuit het oogpunt van een bioloog die migratie bestudeert, een dierenarts of een kok zal totaal andere kenmerken hebben.

Een klasse is een verzameling objecten die gemeenschappelijke eigenschappen en gedrag delen. Zo kan een klasse worden gedefinieerd als een soort gemeenschap van concrete objecten, als een beschrijving - wat ze zouden moeten zijn en wat ze zouden moeten doen. Als objecten echt bestaan in toepassingen, dan is een klasse een abstractie die objecten in één groep verenigt op basis van hun eigenschappen en gedrag in de omgeving waarin ze bestaan en interageren. Button1 op een formulier met al zijn specifieke eigenschappen en actie is bijvoorbeeld een object van de klasse Button.

Gedrag is een kenmerk van hoe het ene object andere objecten beïnvloedt of zichzelf onder hun invloed verandert. Gedrag beïnvloedt hoe de toestanden van een object veranderen.

Objectgeoriënteerde programmeertechnologie is gebaseerd op drie pijlers: inkapseling, overerving en polymorfisme.

Inkapseling is een eigenschap om toestand en gedrag binnen één structuur te combineren, en om de interne structuur van een object en implementatiedetails te verbergen (van het woord "capsule"). Een belangrijke eigenschap van elk object is zijn isolatie. Uitvoeringsdetails van het object, d.w.z. interne datastructuren en algoritmen voor hun verwerking zijn verborgen voor de gebruiker van het object en zijn niet beschikbaar voor onbedoelde wijzigingen. Een object wordt gebruikt via een interface - een set toegangsregels. Om bijvoorbeeld van televisieprogramma te wisselen, hoeven we alleen het nummer op de afstandsbediening in te toetsen, waardoor een complex mechanisme wordt gestart dat uiteindelijk tot het gewenste resultaat zal leiden. We hoeven niet te weten wat er in de afstandsbediening en de tv gebeurt, we moeten alleen weten dat de tv zo'n mogelijkheid (methode) heeft en hoe deze kan worden geactiveerd. Inkapseling, of implementatie verbergen, is een fundamentele eigenschap van OOP. Hiermee kunt u aangepaste objecten maken met de vereiste methoden en deze vervolgens bedienen zonder in te gaan op de structuur van deze objecten. Inkapseling is dus een mechanisme dat gegevens en methoden voor het verwerken (manipuleren) van deze gegevens combineert en beschermt tegen interferentie of misbruik van buitenaf. Het inkapselen van de code in een klasse zorgt ervoor dat het onmogelijk is om deze code te "breken" in het geval van een wijziging in de implementatiedetails van individuele klassen. Daarom kunt u het object in een andere omgeving gebruiken en ervoor zorgen dat het de geheugengebieden die er niet bij horen, niet bederft. Als er toch iets veranderd of aangevuld moet worden in de klas, dan worden de mechanismen van overerving en polymorfisme gebruikt.

Overerving is het op hiërarchie gebaseerde vermogen van klassen om de eigenschappen en het gedrag van hun voorouderklassen op te nemen en hun eigen gedrag en eigenschappen eraan toe te voegen. Elk jaar worden er in de wereld veel programma's geschreven en het is belangrijk om de reeds geschreven code te gebruiken. Het voordeel van objectgeoriënteerd programmeren is dat u afstammelingen van een object kunt definiëren om het gedrag ervan te wijzigen of aan te vullen. In dit geval is het niet nodig om niet alleen de broncode van het bovenliggende object te herhalen, maar er zelfs toegang toe te hebben. Op deze manier wordt de wijziging van het programma en het maken van nieuwe programma's op basis van het bestaande vereenvoudigd. Alleen door overerving kunt u objecten gebruiken die niet beschikbaar zijn in de broncode, maar die moeten worden gewijzigd. Bij het erven kunt u dus niet alleen nieuwe functionaliteit toevoegen, maar ook de bestaande wijzigen. En dit is grotendeels te wijten aan polymorfisme.

Polymorfisme ("vele vormen") - het vermogen om dezelfde uitdrukkingen te gebruiken om verschillende bewerkingen aan te duiden, het vermogen van overgeërfde klassen om de methode beschreven voor de voorouderklasse anders te implementeren, dwz de mogelijkheid om verschillende acties uit te voeren of te verwijzen naar objecten van verschillende typen tijdens de uitvoering van het programma met dezelfde naam. Polymorfisme wordt geïmplementeerd door een methode in afgeleide klassen te overschrijven (een methode heeft dezelfde naam en dezelfde parameters, maar werkt anders) - dit is een mechanisme van virtuele methoden door dynamische binding. Polymorfisme wordt ook geïmplementeerd als overbelasting van de methode (een methode heeft dezelfde naam en verschillende parameters) - dit is bijvoorbeeld het gebruik van het + -teken om optelling aan te geven in de klasse van reële of gehele getallen en de klasse van strings: soortgelijke berichten geven totaal andere resultaten. Polymorfisme biedt de mogelijkheid om gemeenschappelijke eigenschappen te abstraheren.

Modulariteit is een eigenschap van een systeem dat is ontleed in intern verbonden, maar losjes verbonden modules.
Bij het opdelen van een systeem in modules kunnen twee regels nuttig zijn. Ten eerste, aangezien modules dienen als elementaire en ondeelbare codeblokken die hergebruikt kunnen worden in het systeem, moet hier bij de toewijzing van klassen en objecten aan modules rekening mee worden gehouden. Ten tweede maken veel compilers een apart codesegment voor elke module. Daarom kunnen er beperkingen zijn aan de grootte van de module. De dynamiek van subroutine-aanroepen en de plaatsing van declaraties binnen modules kan grote invloed hebben op de plaats van verwijzingen en het beheer van virtuele geheugenpagina's. Slecht gemodulariseerde routines verhogen inter-segment oproepen, wat resulteert in een verlies van cache-efficiëntie en frequente paginawisselingen.

Het is nogal moeilijk om dergelijke tegenstrijdige vereisten samen te brengen, maar het belangrijkste is om te begrijpen dat de isolatie van klassen en objecten in het project en de organisatie van de modulaire structuur onafhankelijke acties zijn. Het proces van het isoleren van klassen en objecten maakt deel uit van het logische ontwerp van het systeem, en het opdelen in modules is de fase van fysiek ontwerp. Natuurlijk is het soms niet mogelijk om het logische ontwerp van een systeem te voltooien zonder het fysieke ontwerp te voltooien, en vice versa. Deze twee processen worden iteratief uitgevoerd.

Typen is een manier om te waken tegen, of op zijn minst te controleren, het gebruik van objecten van de ene klasse in plaats van de andere.

Parallellisme is een eigenschap die actieve objecten onderscheidt van passieve objecten.

Persistentie is het vermogen van een object om in de tijd te bestaan, het proces te ervaren dat het heeft voortgebracht, en (of) in de ruimte, vanuit zijn oorspronkelijke adresruimte.

Bij het programmeren werden de basisconcepten van OOP overgebracht van andere kennisgebieden, zoals filosofie, logica, wiskunde en semiotiek, en zonder speciale veranderingen te ondergaan, althans wat de essentie van deze concepten betreft. De objectmethode van ontbinding (representatie) is natuurlijk en wordt al vele eeuwen gebruikt. Daarom is het niet verwonderlijk dat het in het proces van evolutie van programmeertechnologie zijn rechtmatige plaats innam.

Bij het ontwikkelen van objectgeoriënteerde programma's is het dus noodzakelijk:

1. bepaal de verzameling klassen van objecten die het vormen (decompositie);

2. specificeer voor elke klasse van objecten een set vereiste gegevens (velden);

3. stel voor elke klasse van objecten een reeks acties (methoden) in die door de objecten worden uitgevoerd;

4. specificeer voor elke klasse objecten de gebeurtenissen waarop de objecten zullen reageren en schrijf de juiste afhandelingsprocedures.

De broncode moet klassebeschrijvingen bevatten voor alle programma-objecten. Daarnaast moeten de variabelen worden beschreven, waarbij de namen van de bijbehorende klassen als typen worden gespecificeerd. Instanties van klassen (objecten) worden gemaakt tijdens de uitvoering van het programma.

Na het maken ervan zou een instantie van de klasse waarden moeten ontvangen voor al zijn velden. Verschillende instanties van dezelfde klasse kunnen verschillende veldwaarden hebben, maar hebben dezelfde methoden. Klasvelden zijn niet beschikbaar voor directe referentie, inclusief toewijzing. Dit wordt gedaan om de betrouwbaarheid van de programma's te verbeteren. In plaats van direct een waarde toe te kennen aan een objectveld, moet er een aanroep gedaan worden naar een speciale methode van de corresponderende klasse, die een dergelijke toewijzing uitvoert en de juistheid van de ingevoerde waarde bewaakt. Evenzo kunnen speciale klassenmethoden ook worden gebruikt om de veldwaarde te lezen. Om velden te associëren met methoden voor het lezen / schrijven van hun waarden, worden klasseleden die eigenschappen worden genoemd, gebruikt. De gebruiker, die gegevens invoert om ze in de velden van een object te schrijven of de waarden van de velden leest, houdt zich bezig met de eigenschappen die deze velden vertegenwoordigen. Daarom wordt meestal de term "eigenschapswaarden" gebruikt in plaats van de term "veldwaarden".

Klasleden kunnen zijn:

1.velden die worden gebruikt om gegevens op te slaan;

2. eigenschappen als verwijzing naar privévelden;

3. methoden die de functionaliteit van objecten definiëren;

4. gebeurtenissen en hun handlers als programmacontroletools.

Automatisering van het oplossen van problemen bij het beheer van de activiteiten van "World of Computers" LLC

Het bouwen van een conceptueel model van het informatiesysteem MUP "RPKHB"

Het Rational Rose-pakket kan bijna elk probleem bij het ontwerpen van informatiesystemen oplossen: van bedrijfsprocesanalyse tot codegeneratie in een specifieke programmeertaal. Stelt u in staat om zowel op hoog niveau ...

Een objectmodel bouwen van het vakgebied "organisatie van sportclubprocessen" met behulp van de UML-modelleertaal

Delphi Programmeren van wiskundige processen

Project van een boekhoudsysteem voor bestellingen voor vrachtvervoer van het transportbedrijf "TransAuto"

Het belangrijkste communicatiekanaal in het bedrijf zijn geschreven berichten in de vorm van rapporten, bulletins, bestaande uit de traditionele (papieren) methode, die de werksnelheid aanzienlijk vermindert. Het belangrijkste werk wordt handmatig gedaan ...

Ontwerp van informatiesystemen door middel van BPwin

Ontwikkeling van een informatiesysteem voor automatisering van de werkplek van de bibliothecaris

Ontwikkeling van een objectgeoriënteerd model van het informatiesubsysteem voor het decanaat van de universiteit (rekening houdend met studievoortgang)

Effectief beheer van studentendatabases is onmogelijk zonder een automatiseringssysteem. Het informatiesysteem "Dean's Office" is bedoeld voor het beheer van persoonlijke zaken van studenten en kan afzonderlijk of als onderdeel van de IS "Electronic Gazette" werken ...

Ontwikkeling van een objectgeoriënteerd model van het educatieve bibliotheekinformatiesysteem

Trends in de ontwikkeling van moderne informatietechnologieën leiden tot een constante toename van de complexiteit van informatiesystemen (IS) die op verschillende gebieden van menselijke activiteit worden gecreëerd ...

De ontwikkeling van OOMD is het ontwikkelen van een datamodel met behulp van een objectgeoriënteerde benadering van modellering ...

Ontwikkeling van een databaseschema voor de taak "Accounting for the library fund" voor het Kharkov College of Textiles and Design

Bij het kiezen van een DBMS voor de implementatie van een bepaald systeem, is het noodzakelijk om rekening te houden met alle kenmerken van de technologieën die vandaag beschikbaar zijn. Dus, aangezien de meest ontwikkelde modellen kunnen worden beschouwd als OO- en ER-modellen ...

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

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

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

INVOERING

1.1 Theoretische basisvoorzieningen van objectgeoriënteerde programmeertechnologie; Basisconcepten van de objectgeoriënteerde benadering

1.2 Conceptobject

2. het bouwen van een objectmodel van het vakgebied "organisatie van sportclubprocessen" met behulp van de uml-modelleringstaal

2.1 Kenmerken van de UML-modelleertaal

2.1.1 Een korte geschiedenis van de UML

2.1.2 UML

2.1.3 UML-vocabulaire

2.1.4 Modelbesturingsaanzicht.

3.1 Beschrijving van de applicatiestructuur

CONCLUSIE

LIJST MET BRONNEN

Bijlage A

INVOERING

De sportvereniging voert allround activiteiten uit voor de ontwikkeling van lichamelijke cultuur en sport bij jongeren en hun gezinnen. Er komen steeds meer sportclubs met veel sportafdelingen. Het inschrijven van jongeren voor deze secties is tijdrovend en complex. Daarom wordt de vraag om dit proces te automatiseren steeds urgenter.

Bij gebruik van een computer wordt dit proces veel nauwkeuriger en sneller, zonder veel overlappingen die optreden bij het handmatig organiseren.

De eigenaardigheden van het organiseren van de processen van een sportclub worden geïdentificeerd met behulp van het objectmodel van het vakgebied. Dergelijke modellen zijn vooral nuttig voor het organiseren van het boekhoudproces voor jongeren die betrokken zijn bij secties van een sportclub, omdat het modelleren van dit vakgebied het mogelijk maakt om een object van alle kanten te bekijken en dus alle mogelijke problemen te voorzien. Zo kun je bij de planning door het objectmodel van de organisatie van het onderwijsproces overlappingen in de urenverdeling voor secties voorkomen, aangezien dit moment tijdens de ontwikkeling wordt voorzien.

Een domeinobjectmodel kan worden gebouwd met behulp van de UML-taal voor visuele objectmodellering of als een softwareproduct in een programmeertaal die objectprogrammeertechnologie ondersteunt, een voorbeeld hiervan is Object Pascal.

Het doel van deze studie is om objectgeoriënteerde methodologie en programmeertechnologie te bestuderen naar het voorbeeld van de Object Pascal-taal, methoden en hulpmiddelen voor het construeren van objectmodellen van vakgebieden, de toepassing van de opgedane kennis om een objectmodel van het vakgebied te construeren "Organisatie van het werk van een sportclub."

Om het doel van dit onderzoek te bereiken, zijn de volgende taken opgesteld:

· Bestudeer de theoretische basisvoorzieningen van de objectgeoriënteerde methodiek;

· Overweeg de UML en bouw een objectmodel van het domein met behulp van deze taal;

· Ontwikkel een applicatie die een reeks klassen gebruikt om informatie over atleten weer te geven.

Het onderzoeksobject van deze cursus is een objectgeoriënteerde ontwerpmethodiek.

Het onderwerp van dit onderzoek is het objectmodel van het vakgebied "Organisatie van het werk van een sportvereniging" en de belangrijkste eigenschappen ervan.

De hypothese van het onderzoek is dat de implementatie van het objectmodel in de visuele ontwikkelomgeving van Delphi, met behulp van de basisvoorzieningen van de objectgeoriënteerde methodologie, het proces van het verzamelen, opslaan en verwerken van informatie over de deelnemers van de sportclub zal vereenvoudigen.

In de fase van het analyseren van het domein en het ontwerpen van de structuur van de applicatie, is het noodzakelijk om een UML-klassendiagram te bouwen.

Bij het schrijven van een cursusproject zijn de volgende onderzoeksmethoden gebruikt:

· De beschrijvende methode wordt gebruikt bij de presentatie van de theoretische aspecten van het probleem en een korte beschrijving van het onderzoeksobject;

· Methode van vergelijking en analyse. Hiermee kunt u verschillende opvattingen over het onderwerp in kwestie vergelijken en het object van onderzoek diagnosticeren;

· Systeem benadering. Het werd gebruikt om de verkregen resultaten samen te vatten en hun logische relatie te identificeren.

1. THEORETISCHE BASISBEPALINGEN VAN OBJECTGERICHTE METHODOLOGIE

1.1 Basisconcepten van de objectgeoriënteerde benadering

onderwerp taal programmeermodel

Programmeren heeft lange tijd gebruik gemaakt van een gestructureerd procedureel model. De keuze van de projectdoelstellingen wordt uitgevoerd door een van de twee benaderingen, genaamd "top-down" en dienovereenkomstig "bottom-up"

1. De 'top-down'-benadering houdt in dat de taak wordt opgedeeld in subtaken, die op hun beurt weer in subtaken van het volgende niveau, enzovoort. Dit proces, decompositie genaamd, duurt totdat de vereenvoudiging van deeltaken niet is gereduceerd tot elementaire functies die geformaliseerd kunnen worden.

2. De bottom-upbenadering houdt in dat procedures worden geschreven om eenvoudige problemen op te lossen, waarna ze achtereenvolgens worden gecombineerd tot complexere procedures totdat het gewenste effect is bereikt.

Belangrijke programmeerconcepten zijn procedureel programmeren en objectgeoriënteerd programmeren.

Procedureel georiënteerd programmeren is programmeren in een imperatieve taal, waarin sequentieel uitgevoerde instructies kunnen worden samengevoegd tot subroutines, dat wil zeggen grotere integrale code-eenheden, met behulp van de mechanismen van de taal zelf.

Object Oriented Programming (OOP) is een programmeerstijl die het gedrag van de echte wereld vastlegt op zo'n manier dat de details van de implementatie ervan verborgen zijn.

Een object is een soort afzonderlijke entiteit die zich onderscheidt van andere entiteiten vanwege zijn eigenschappen, gedrag en interactie met andere objecten van de toepassing.

Het gebruik van deze technologie maakt het mogelijk om de structuur van het programma weer te geven in de vorm van een reeks objecten die met elkaar in wisselwerking staan. Als resultaat van een dergelijke interactie, uitgevoerd door berichten tussen objecten door te geven, worden de gespecificeerde programmafuncties geïmplementeerd. Na ontvangst van een bericht kan een object een specifieke actie uitvoeren die een methode wordt genoemd.

Er zijn twee belangrijke verschillen tussen OOP en procedureel programmeren:

1. In OOP selecteert de programmeur eerst klassen uit de beschrijving van het onderwerpgebied, vervolgens wordt een objectmodel gebouwd om het probleem op te lossen, en pas daarna gaat hij verder met de analyse van hun methoden en eigenschappen.

2. Methoden en eigenschappen zijn gekoppeld aan een klasse die bedoeld is om de overeenkomstige bewerkingen uit te voeren.

Gedrag is een kenmerk van hoe het ene object andere objecten beïnvloedt of zichzelf onder hun invloed verandert. Gedrag beïnvloedt hoe de toestanden van een object veranderen.

Objectgeoriënteerde programmeertechnologie is gebaseerd op drie pijlers: inkapseling, overerving en polymorfisme.

Typen is een manier om te waken tegen, of op zijn minst te controleren, het gebruik van objecten van de ene klasse in plaats van de andere.

Parallellisme is een eigenschap die actieve objecten onderscheidt van passieve objecten.

Persistentie is het vermogen van een object om in de tijd te bestaan, het proces te ervaren dat het heeft voortgebracht, en (of) in de ruimte, vanuit zijn oorspronkelijke adresruimte.

Bij het ontwikkelen van objectgeoriënteerde programma's is het dus noodzakelijk:

1. bepaal de verzameling klassen van objecten die het vormen (decompositie);

2. specificeer voor elke klasse van objecten een set vereiste gegevens (velden);

3. stel voor elke klasse van objecten een reeks acties (methoden) in die door de objecten worden uitgevoerd;

4. specificeer voor elke klasse objecten de gebeurtenissen waarop de objecten zullen reageren en schrijf de juiste afhandelingsprocedures.

Klasleden kunnen zijn:

1.velden die worden gebruikt om gegevens op te slaan;

2. eigenschappen als verwijzing naar privévelden;

3. methoden die de functionaliteit van objecten definiëren;

4. gebeurtenissen en hun handlers als programmacontroletools.

1.2 Conceptobject

De objectgeoriënteerde benadering van programmeren suggereert dat alles wat deel uitmaakt van de applicatie wordt beschouwd als objecten die met elkaar en met de gebruiker interageren in overeenstemming met de eigenschappen en het gedrag gespecificeerd in het programma, en de noodzakelijke functies van de applicatie uitvoeren. Elke applicatie met deze benadering is dus een set onderling verbonden objecten die de noodzakelijke functionele vereisten voor de applicatie implementeren.

Een object is altijd concreet en bestaat echt in een vorm of in een toepassing, terwijl het alleen zijn inherente eigenschappen en gedrag bezit. De attributen van objecten die ze van elkaar onderscheiden, zijn hun eigenschappen en gedrag. In de echte wereld heeft elk object of proces een reeks statische en dynamische kenmerken (eigenschappen en gedrag). Het gedrag van een object hangt af van zijn toestand en externe invloeden. Het object "auto" gaat bijvoorbeeld nergens heen als er geen benzine in de tank zit en als u aan het stuur draait, verandert de positie van de wielen. Een object wordt dus weergegeven als een verzameling gegevens die de toestand karakteriseren en methoden (procedures en functies) van hun verwerking die het gedrag ervan simuleren. Het aanroepen van een procedure of functie voor uitvoering wordt vaak het verzenden van een bericht naar een object genoemd (het aanroepen van een procedure "draai aan het stuur" wordt bijvoorbeeld vaak geïnterpreteerd als het verzenden van een bericht "auto, draai aan het stuur!"). Zo wordt elk object gekenmerkt door de volgende basisconcepten:

1. een methode is een functie of procedure die mogelijke acties met een object implementeert;

2. Een gebeurtenis is een middel tot interactie van objecten met elkaar. Objecten genereren gespecificeerde gebeurtenissen en ondernemen acties in reactie op gespecificeerde gebeurtenissen. Gebeurtenissen zijn analoog aan berichten die objecten ontvangen en verzenden;

3. staat - elk object bevindt zich altijd in een bepaalde staat, die wordt gekenmerkt door een reeks objecteigenschappen. Onder invloed van gebeurtenissen gaat het object in andere toestanden. In dit geval kan het object zelf gebeurtenissen genereren wanneer het overgaat naar een andere toestand;

4. eigenschap - een teken, een aparte kwaliteit (parameter) van een object.

De eigenschappen kunnen bijvoorbeeld de grootte van het object, de titel, de naam zijn. De set eigenschappen van een object bepaalt de staat ervan. Eigenschappen zijn meestal een reeks variabelen en constanten die waarden opslaan die de parameters van een object definiëren.

Opgemerkt moet worden dat naast fysieke objecten ook abstracte objecten kunnen bestaan, typische vertegenwoordigers hiervan zijn getallen. Een object is dus elke fysieke of abstracte duidelijk identificeerbare entiteit van het domein.

Objecten worden gekenmerkt door attributen. De attributen van een auto zijn bijvoorbeeld maximale snelheid, motorvermogen, carrosseriekleur, etc. De attributen van een versterker zijn frequentiebereik, uitgangsvermogen, totale harmonische vervorming, geluidsniveau, etc.

Naast attributen hebben objecten enige functionaliteit die OOP operaties, functies of methoden aanroept. Zo kan een auto rijden, een schip varen, een computer berekeningen uitvoeren.

Een object kapselt dus attributen en methoden in en verbergt de implementatie ervan voor andere objecten die ermee interageren en de functionaliteit ervan gebruiken.

De objectgeoriënteerde benadering is gebaseerd op het systematisch gebruik van modellen voor taalonafhankelijke ontwikkeling van een softwaresysteem, gebaseerd op zijn pragmatiek.

De laatste term behoeft verduidelijking. Pragmatiek wordt bepaald door het doel van het ontwikkelen van een softwaresysteem: voor het bedienen van bankklanten, voor het beheer van de exploitatie van een luchthaven, voor het onderhouden van het WK, enz. Bij het formuleren van het doel worden objecten en concepten uit de echte wereld betrokken die gerelateerd zijn aan het ontwikkelde softwaresysteem (zie figuur 1.2.1).

In de objectgeoriënteerde benadering worden deze objecten en concepten vervangen door hun modellen, d.w.z. bepaalde formele constructies die ze vertegenwoordigen in het softwaresysteem.

Figuur 1.2.1 Semantiek.

Het model bevat niet alle tekens en eigenschappen van het object (concept) dat het vertegenwoordigt, maar alleen die die essentieel zijn voor het softwaresysteem dat wordt ontwikkeld. Het model is dus "armer" en bijgevolg eenvoudiger dan het object (concept) dat het vertegenwoordigt. Maar het belangrijkste is niet eens dit, maar dat het model een formele constructie is: het formele karakter van de modellen maakt het mogelijk om de formele afhankelijkheden ertussen en formele bewerkingen erop te bepalen. Dit vereenvoudigt zowel de ontwikkeling en studie (analyse) van modellen als de implementatie ervan op een computer. In het bijzonder maakt het formele karakter van de modellen het mogelijk om een formeel model van het ontwikkelde softwaresysteem te verkrijgen als een samenstelling van formele modellen van zijn componenten.

Een objectgeoriënteerde benadering helpt dus om complexe problemen aan te pakken zoals:

· Vermindering van softwarecomplexiteit;

· Betrouwbaarheid van software verhogen;

· Zorgen voor de mogelijkheid om individuele softwarecomponenten te wijzigen zonder de rest van de componenten te wijzigen;

· Zorgen voor de mogelijkheid van hergebruik van individuele softwarecomponenten.

De systematische toepassing van de objectgeoriënteerde benadering maakt het mogelijk om goed gestructureerde, bedrijfszekere, vrij gemakkelijk aanpasbare softwaresystemen te ontwikkelen. Dit verklaart de interesse van programmeurs in de objectgeoriënteerde benadering en objectgeoriënteerde programmeertalen. De objectgeoriënteerde benadering is een van de meest intensief ontwikkelende gebieden van theoretisch en toegepast programmeren.

1.3 Implementatiemiddelen van objectgeoriënteerde programmeertechnologie

In OOP-technologie is de relatie tussen gegevens en een algoritme regelmatiger: ten eerste combineert een klasse (het basisconcept van deze technologie) gegevens (gestructureerde variabele) en methoden (functies). Ten tweede is het schema van interactie tussen functies en gegevens fundamenteel anders. Een methode (functie) die op het ene object wordt aangeroepen, roept meestal niet direct een andere functie aan. Om te beginnen moet hij toegang hebben tot een ander object (maken, een pointer ophalen, het interne object in het huidige gebruiken, enz.), waarna hij er al een van de bekende methoden voor kan aanroepen. De structuur van het programma wordt dus bepaald door de interactie van objecten van verschillende klassen met elkaar. In de regel is er een klassenhiërarchie en OOP-technologie kan anders "van klas tot klas" -programmering worden genoemd.

Elke programmering wordt uitgevoerd volgens een van de vier principes:

Het principe van modulariteit

· Principe "van algemeen naar specifiek"

Het principe van stap voor stap:

Het principe van structureren

Modulaire programmering. Het modulariteitsprincipe is geformuleerd als een vereiste voor de ontwikkeling van een programma in de vorm van een set van modules (functies). In dit geval moet de indeling in modules niet mechanisch van aard zijn, maar uitgaan van de logica van het programma:

1. de grootte van de module moet worden beperkt;

2. de module moet een logisch samenhangende en volledige actie uitvoeren;

3. de module moet universeel zijn, dat wil zeggen zo geparametriseerd mogelijk: alle variabele kenmerken van de uitgevoerde actie moeten worden overgedragen via parameters;

4. het is wenselijk om invoerparameters en het resultaat van de module niet via globale variabelen over te dragen, maar via formele parameters en het resultaat van de functie.

Een andere, maar al fysieke eenheid van het programma is een tekstbestand met daarin een aantal functies en definities van datatypes en variabelen. Modulair programmeren op bestandsniveau is de mogelijkheid om een volledige programmacode in meerdere bestanden te splitsen. Het principe van modulariteit is niet alleen van toepassing op programma's, maar ook op gegevens: elke reeks parameters die een logisch of fysiek object kenmerken, moet in het programma worden weergegeven als een enkele gegevensstructuur (gestructureerde variabele).

De belichaming van het principe van modulariteit is de bibliotheek van standaardfuncties. Het biedt meestal een complete set van geparametriseerde acties met behulp van gemeenschappelijke datastructuren. Bibliotheken zijn vergelijkbare programma's, onafhankelijk vertaald en in de bibliotheekdirectory geplaatst.

Programmeren van bovenaf. Top-down ontwerp van een programma is dat de ontwikkeling verloopt van een algemene informele formulering van een actie van een programma in een natuurlijke taal, "van algemeen naar specifiek": om het te vervangen door een van de drie formele constructies van de programmeertaal:

· Een eenvoudige opeenvolging van acties;

· Constructen naar keuze of operator als;

· Herhalings- of cyclusconstructies.

In de opname van het algoritme komt dit overeen met de beweging van de buitenste (omsluitende) structuur naar de binnenste (geneste). Deze constructies kunnen ook informele beschrijvingen van acties in hun onderdelen bevatten, dat wil zeggen dat top-down ontwerp van nature stapsgewijs verloopt. Laten we eens kijken naar de belangrijkste eigenschappen van deze aanpak:

· In eerste instantie wordt het programma geformuleerd in de vorm van een informele actie in natuurlijke taal;

· In eerste instantie worden de invoerparameters en het resultaat van de actie bepaald;

· De volgende stap van detaillering verandert niets aan de structuur van het programma verkregen in de vorige stappen;

Als tijdens het ontwerpproces identieke acties worden verkregen in verschillende branches, betekent dit de noodzaak om deze actie te formaliseren als een afzonderlijke functie;

· Gelijktijdig met de programmadetaillering worden de benodigde datastructuren ontworpen.

Stap voor stap programmeren. Top-down ontwerpen is van nature stapsgewijs, omdat het elke keer een verbale formulering vervangt door een enkele taalconstructie. Maar tijdens het ontwikkelen van een programma kunnen er andere stappen zijn die verband houden met het uitwerken van de zeer verbale formulering in meer gedetailleerde.

Het feit dat dit principe afzonderlijk wordt benadrukt, geeft aan dat het nodig is om de verleiding te weerstaan om het programma van begin tot eind te detailleren en om het vermogen te ontwikkelen om de belangrijkste, in plaats van secundaire details van het algoritme te benadrukken en erop te focussen.

Over het algemeen garandeert een top-down stap-voor-stap programma-ontwerp geen "juist" programma, maar stelt u in staat om terug te keren wanneer een impasse wordt gevonden naar een van de bovenste detailleringsstappen.

Gestructureerd programmeren. Met een aflopende stapsgewijze detaillering van het programma verschijnen de datastructuren en variabelen die nodig zijn voor de operatie als de overgang van informele definities naar taalconstructies, dat wil zeggen, de processen van het detailleren van het algoritme en de gegevens gaan parallel. Dit geldt echter vooral voor individuele lokale variabelen en interne parameters. Vanuit het meest algemene gezichtspunt is een object (in ons geval data) altijd primair in relatie tot de acties die ermee worden uitgevoerd (in ons geval een algoritme). Daarom heeft de manier waarop gegevens in een programma zijn georganiseerd, in feite meer invloed op de algoritmestructuur dan op wat dan ook, en het proces van het ontwerpen van gegevensstructuren moet het proces van het ontwerpen van een algoritme voor hun verwerking overtreffen.

Gestructureerd programmeren is een modulair, top-down, stapsgewijs ontwerp van algoritme- en datastructuren.

Een objectgeoriënteerde benadering van programmeren omvat 3 hoofdcomponenten:

Objectgeoriënteerde analyse (OOA),

Objectgericht ontwerpen (OOD),

· Objectgeoriënteerd programmeren (OOP).

In elke technische discipline wordt ontwerp meestal begrepen als een uniforme aanpak die we gebruiken om manieren te vinden om een specifiek probleem op te lossen, zodat de taak wordt voltooid. In de context van technisch ontwerp wordt het ontwerpdoel gedefinieerd als het creëren van een systeem dat:

· Voldoet aan gegeven (eventueel informele) functionele specificaties;

· Is in overeenstemming met de beperkingen opgelegd door de apparatuur;

· Voldoet aan expliciete en impliciete eisen voor prestaties en resourceverbruik;

· Voldoet aan expliciete en impliciete criteria voor productontwerp;

· Voldoet aan de eisen voor het ontwikkelproces zelf, zoals bijvoorbeeld duur en kosten, evenals de inzet van aanvullende tools.

Design gaat over tegenstrijdige eisen. De producten zijn modellen die ons in staat stellen de structuur van het toekomstige systeem te begrijpen, de vereisten in evenwicht te brengen en een implementatieschema te schetsen.

Het programma is een numeriek model van het ontworpen systeem (Fig. 1.3.1.).

Rijst. 1.3.1. De opbouw van het programma.

Het belang van modelbouw. Modellering is wijdverbreid in alle technische disciplines, grotendeels vanwege het feit dat het de principes van decompositie, abstractie en hiërarchie implementeert. Elk model beschrijft een bepaald deel van het beschouwde systeem en wij bouwen op onze beurt nieuwe modellen op basis van oude, waar we min of meer vertrouwen in hebben. Modellen stellen ons in staat om onze mislukkingen te beheersen. We evalueren het gedrag van elk model in gewone en ongebruikelijke situaties en voeren vervolgens passende verbeteringen door als iets ons niet tevreden stelt.

Elementen van softwareontwerp. Het is duidelijk dat er geen one-size-fits-all methode is die de software-engineer begeleidt van de vereisten van een complex softwaresysteem naar de vervulling ervan. Het ontwerpen van een complex softwaresysteem gaat niet over het blindelings volgen van een reeks recepten. Het is eerder een geleidelijk en iteratief proces. En toch brengt het gebruik van ontwerpmethodologie een zekere mate van organisatie in het ontwikkelingsproces. Software-engineers hebben tientallen verschillende technieken ontwikkeld die we in drie categorieën kunnen indelen. Ondanks de verschillen hebben deze methoden iets gemeen. In het bijzonder zijn ze verenigd door het volgende:

· Symbolen - de taal voor het beschrijven van elk model;

· Proces - regels voor het ontwerpen van een model;

· Tools - tools die het proces van het maken van modellen versnellen en waarin de wetten van het functioneren van modellen al zijn belichaamd. De tools helpen u bij het identificeren van bugs tijdens het ontwikkelingsproces.

Een goede ontwerpmethode rust op een stevige theoretische basis en geeft de programmeur een zekere mate van vrijheid van meningsuiting.

Objectgeoriënteerde modellen. Het is zeer nuttig om modellen te maken die de aandacht vestigen op objecten die in het domein zelf worden gevonden, en die een zogenaamde objectgeoriënteerde ontleding vormen.

Objectgeoriënteerde analyse en ontwerp is een techniek die logischerwijs leidt tot objectgeoriënteerde decompositie. Door gebruik te maken van objectgeoriënteerd ontwerpen ontstaan flexibele programma's die economisch geschreven zijn. Door de toestandsruimte redelijk te verdelen, krijgen we meer vertrouwen in de juistheid van ons programma. Hierdoor verkleinen we het risico bij het ontwikkelen van complexe softwaresystemen.

Aangezien modelbouw uiterst belangrijk is bij het ontwerpen van complexe systemen, biedt objectgeoriënteerd ontwerp een rijke selectie aan modellen (getoond in Fig. 1.3.2). Objectgeoriënteerde ontwerpmodellen weerspiegelen de hiërarchie van zowel klassen als objecten van het systeem. Deze modellen bestrijken het volledige spectrum van kritische ontwerpbeslissingen waarmee rekening moet worden gehouden bij het ontwikkelen van een complex systeem, en inspireren ons dus om projecten te creëren die alle vijf kenmerken van goed georganiseerde complexe systemen hebben.

Rijst. 1.3.2 Objectgeoriënteerde modellen.

OOP is een programmeerideologie gebaseerd op het combineren van gegevens en procedures die met deze gegevens in geaggregeerde vorm kunnen werken, klassen genoemd.

De essentie van OOP is het gebruik van het in het dagelijks leven bekende objectmodel. Elk object heeft zijn eigen eigenschappen en u kunt er kenmerkende acties mee uitvoeren. Een klasse is een type object. De klasse beschrijft en implementeert de eigenschappen en acties. Een object in ons begrip zal een variabele zijn, waarvan het type een klasse zal zijn. We noemen de eigenschappen ervan door velden van een klasse, en acties die kunnen worden uitgevoerd met een instantie van deze klasse (object) door middel van methoden.

Overweeg onder een voorbeeldimplementatie van een klasse de implementatie van het concept van een boek met behulp van een klasse om een weergave van het TBook en een set functies voor het werken met variabelen van dit type te definiëren:

PagesCount: geheel getal;

functie CompareWithBook (OtherBook: TBook): geheel getal;

procedure ToonTitel;

constructor Maken (NewTitle, New

Menselijke cognitieve vermogens zijn beperkt; we kunnen ze uit elkaar duwen met behulp van decompositie, abstractie-accentuering en hiërarchieën.

Complexe systemen kunnen worden onderzocht door te focussen op objecten of processen; er zijn goede redenen om objectgeoriënteerde decompositie toe te passen, waarbij de wereld wordt gezien als een geordende verzameling objecten die, in interactie met elkaar, het gedrag van het systeem bepalen.

Objectgeoriënteerde analyse en ontwerp - een methode die gebruik maakt van objectdecompositie; de objectgeoriënteerde benadering heeft een eigen notatie en biedt een rijke set aan logische en fysieke modellen waarmee we een beeld kunnen krijgen van verschillende aspecten van het betreffende systeem.

2. CONSTRUCTIE VAN HET OBJECTMODEL VAN HET ONDERWERP "ORGANISATIE VAN SPORTCLUBPROCESSEN" MET GEBRUIK VAN DE UML-MODELTAAL

2.1 De UML begrijpen

UML (Unified Modeling Language) is een uniforme grafische modelleertaal voor het beschrijven, visualiseren, ontwerpen en documenteren van objectgeoriënteerde systemen. UML is ontworpen om het proces van het modelleren van software te ondersteunen op basis van een objectgeoriënteerde benadering, om de relatie tussen conceptuele en softwareconcepten te organiseren, om de problemen van het schalen van complexe systemen weer te geven. UML-modellen worden gebruikt in alle stadia van de softwarelevenscyclus, van bedrijfsanalyse tot systeemonderhoud. Verschillende organisaties kunnen UML naar eigen inzicht toepassen, afhankelijk van hun probleemgebieden en gebruikte technologieën.

2.1.1 Een korte geschiedenis van de UML

Tegen het midden van de jaren 90 werden enkele tientallen objectgeoriënteerde modelleringsmethoden voorgesteld door verschillende auteurs, die elk hun eigen grafische notatie gebruikten. Tegelijkertijd had elk van deze methoden hun sterke punten, maar maakte het niet mogelijk om een voldoende compleet model van softwaretools te bouwen, dat het "van alle kanten" liet zien, dat wil zeggen alle noodzakelijke projecties. Bovendien maakte het ontbreken van een objectgeoriënteerde modelleringsstandaard het voor ontwikkelaars moeilijk om de meest geschikte methode te kiezen, wat de wijdverbreide acceptatie van een objectgeoriënteerde benadering van softwareontwikkeling belemmerde.

Op verzoek van de Object Management Group (OMG) - de organisatie die verantwoordelijk is voor de adoptie van standaarden op het gebied van objecttechnologieën en databases, werd het urgente probleem van unificatie en standaardisatie opgelost door de auteurs van de drie meest populaire objectgeoriënteerde methoden - G. Buch, D. Rambo en A. Jacobson, die hun krachten hebben gebundeld om UML 1.1 te creëren, dat de OMG in 1997 als standaard heeft goedgekeurd.

In het kielzog van de groeiende belangstelling voor UML hebben bedrijven zoals Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software zich aangesloten bij de ontwikkeling van nieuwe versies van de taal binnen het UML Partners consortium. , Texas Instruments en Unisys. De samenwerking resulteerde in de UML 1.0-specificatie, uitgebracht in januari 1997. In november van hetzelfde jaar werd het gevolgd door versie 1.1, die zowel notatieverbeteringen als enkele semantische verbeteringen bevatte. UML 1.4.2 is aangenomen als de internationale norm ISO / IEC 19501: 2005.

De formele specificatie voor de nieuwste versie van UML 2.0 werd in augustus 2005 gepubliceerd. De semantiek van de taal is aanzienlijk verfijnd en uitgebreid om de Model Driven Development - MDD-methodologie te ondersteunen. De nieuwste versie van UML 2.4.1 is in augustus 2011 gepubliceerd. UML 2.4.1 is aangenomen als de internationale norm ISO / IEC 19505-1, 19505-2.

2.1.2 UML-taal

Elke taal bestaat uit een vocabulaire en regels voor het combineren van woorden om zinvolle constructies te verkrijgen. Er zijn dus met name programmeertalen geregeld, zoals de UML. Het onderscheidende kenmerk is dat het taalwoordenboek wordt gevormd door grafische elementen. Elk grafisch symbool heeft een specifieke semantiek, dus een model dat door de ene ontwikkelaar is gemaakt, kan door een andere ontwikkelaar ondubbelzinnig worden begrepen, evenals een softwaretool die de UML interpreteert. Hieruit volgt met name dat een PS-model dat wordt weergegeven in UML automatisch kan worden vertaald in een OO-programmeertaal (zoals Java, C ++, VisualBasic), dat wil zeggen als er een goede visuele modelleringstool is die UML ondersteunt , het model bouwen, zullen we ook een voorbereiding ontvangen van de programmacode die bij dit model hoort.

Benadrukt moet worden dat de UML een taal is, geen methode. Het legt uit uit welke elementen je modellen moet bouwen en hoe je ze moet lezen, maar het zegt niets over welke modellen moeten worden ontwikkeld en in welke gevallen. Om een methode op basis van UML te maken, is het nodig deze aan te vullen met een beschrijving van het softwareontwikkelingsproces. Een voorbeeld van een dergelijk proces is het Rational Unified Process, dat in volgende artikelen zal worden besproken.

2.1.3 UML-vocabulaire

Het model wordt weergegeven in de vorm van entiteiten en relaties daartussen, die in diagrammen worden weergegeven.

Entiteiten zijn abstracties die de belangrijkste bouwstenen van modellen zijn. Er zijn vier soorten entiteiten: structureel (klasse, interface, component, use case, samenwerking, knooppunt), gedragsmatige (interactie, status), groepering (pakketten) en annotatie (opmerkingen). Elk type entiteit heeft zijn eigen grafische weergave. Entiteiten zullen in detail worden besproken bij het verkennen van diagrammen.

Relaties tonen verschillende relaties tussen entiteiten. De UML definieert de volgende soorten relaties:

· Afhankelijkheid toont een dergelijke relatie tussen twee entiteiten, wanneer het veranderen van een van hen - onafhankelijk - de semantiek van de andere - afhankelijk kan beïnvloeden. Afhankelijkheid wordt weergegeven door een gestippelde pijl die van de afhankelijke entiteit naar de onafhankelijke entiteit wijst.

· Een associatie is een structurele relatie die aangeeft dat objecten in de ene entiteit gerelateerd zijn aan objecten in een andere. Een associatie wordt grafisch weergegeven als een lijn die de entiteiten verbindt die worden gekoppeld. Associaties worden gebruikt om tussen objecten te navigeren. De koppeling tussen de klassen "Bestelling" en "Product" kan bijvoorbeeld worden gebruikt om alle goederen te vinden die in een bepaalde bestelling zijn gespecificeerd - aan de ene kant, of om alle bestellingen te vinden waarin zich een bepaald product bevindt - aan de andere kant . Het is duidelijk dat de bijbehorende programma's een mechanisme voor een dergelijke navigatie moeten implementeren. Als er maar één richting nodig is om te navigeren, wordt dit aangegeven door een pijl aan het einde van de koppeling. Een speciaal geval van een associatie is aggregatie - een relatie van de vorm "geheel" - "deel". Grafisch wordt het gemarkeerd met een diamant aan het einde in de buurt van het entiteit-geheel.

· Generalisatie is een relatie tussen een bovenliggende entiteit en een onderliggende entiteit. In wezen weerspiegelt deze relatie de overervingseigenschap voor klassen en objecten. De generalisatie wordt weergegeven als een lijn die eindigt in een driehoek die naar de bovenliggende entiteit wijst. Het kind erft de structuur (attributen) en het gedrag (methoden) van de ouder, maar kan tegelijkertijd nieuwe structuurleden en nieuwe methoden hebben. UML staat meerdere overerving toe wanneer een entiteit is gekoppeld aan meer dan één bovenliggende entiteit.

· Implementatie - de relatie tussen de entiteit die de specificatie van gedrag definieert (interface) en de entiteit die de implementatie van dit gedrag definieert (klasse, component). Deze relatie wordt vaak gebruikt bij het modelleren van componenten en zal in volgende artikelen in meer detail worden beschreven.

Diagrammen. De UML biedt de volgende diagrammen:

Diagrammen die het gedrag van het systeem beschrijven:

Staat diagrammen,

Activiteitendiagrammen,

Objectdiagrammen,

Volgorde diagrammen,

· Interactiediagrammen (Samenwerkingsdiagrammen);

Diagrammen die de fysieke implementatie van het systeem beschrijven:

Component diagrammen

Implementatiediagrammen

2.1.4 Modelbesturingsstructuur

Om het model goed te laten begrijpen door een persoon, is het noodzakelijk om het hiërarchisch te organiseren, waarbij een klein aantal entiteiten op elk niveau van de hiërarchie overblijft. UML omvat een manier om de hiërarchische weergave van het model - pakketten - te organiseren. Elk model bestaat uit een set pakketten die klassen, use cases en andere entiteiten en diagrammen kunnen bevatten. Een pakket kan andere pakketten bevatten om hiërarchieën te maken. Er zijn geen aparte pakketdiagrammen in de UML, maar ze kunnen in andere diagrammen voorkomen. Het pakket wordt weergegeven als een rechthoek met een tabblad.

UML biedt.

· Een hiërarchische beschrijving van een complex systeem door pakketten toe te wijzen;

· Formalisatie van functionele vereisten voor het systeem met behulp van het apparaat van use cases;

• De vereisten voor het systeem uitwerken door diagrammen van activiteiten en scenario's te bouwen;

· Toewijzing van dataklassen en opbouw van een conceptueel datamodel in de vorm van klassendiagrammen;

· Toewijzing van klassen die de gebruikersinterface beschrijven, en het creëren van een schermnavigatieschema;

· Een beschrijving van de interactieprocessen van objecten bij het uitvoeren van systeemfuncties;

· Beschrijving van het gedrag van objecten in de vorm van diagrammen van activiteiten en toestanden;

· Beschrijving van softwarecomponenten en hun interactie via interfaces;

· Een beschrijving van de fysieke architectuur van het systeem.

De UML zou moeilijk te gebruiken zijn in echte softwaremodellering zonder visuele modelleringstools. Met dergelijke tools kunt u snel diagrammen op het beeldscherm presenteren, documenteren, blanco programmacodes genereren in verschillende objectgeoriënteerde programmeertalen en databaseschema's maken. De meeste daarvan omvatten de mogelijkheid om programmacodes opnieuw te ontwerpen - het herstellen van bepaalde projecties van het softwaremodel door automatische analyse van programmabroncodes, wat erg belangrijk is om de consistentie van het model en de codes te waarborgen en bij het ontwerpen van systemen die de functionaliteit van voorgaande systemen erven .

2.2 Beschrijving van de werking van het vakgebied "Organisatie van het werk van een sportclub"

Afhankelijk van de aard van de verbindingen tussen de bedrijfsonderdelen worden de volgende soorten organisatiestructuren onderscheiden: lineair, functioneel, lineair-functioneel en matrix.

Deze sportvereniging hanteert een lineaire bestuursstructuur.

De sportvereniging lost de volgende taken op:

· Betrokkenheid van jongeren en hun gezinnen bij systematische lichamelijke opvoeding en sport;

· Opvoeding van fysieke en morele wilskwaliteiten, verbetering van de gezondheid en vermindering van morbiditeit, verhoging van het niveau van professionele paraatheid, sociale activiteit van jongeren;

· Het organiseren en houden van massale gezondheidsbevorderende, fysieke cultuur- en sportevenementen;

· Oprichting van sportamateurverenigingen, clubs, secties en teams door sport;

Bevordering van fysieke cultuur en sport, een gezonde levensstijl, het organiseren van zinvolle vrijetijdsbesteding, het aantrekken van een brede massa jongeren voor massale sociale en politieke evenementen

De sportclub vervult de volgende functies:

· Implementeert de introductie van fysieke cultuur en sport in de activiteiten van jongeren, hun leven en recreatie; bevordert een gezonde levensstijl, vecht om slechte gewoonten te overwinnen;

· Creëert de nodige organisatorische en methodologische voorwaarden voor het beoefenen van verschillende vormen en soorten fysieke cultuur en sport in overeenstemming met de tradities die in het land zijn gevestigd;

· introduceert nieuwe vormen en methoden van lichamelijke opvoeding, geavanceerde ervaring en wetenschappelijke prestaties; maakt rationeel en efficiënt gebruik van de materiële basis;

· Ontwikkelt op alle mogelijke manieren sociale principes in fysieke massacultuur, gezondheidsverbetering en sportwerk;

· Biedt hulp aan middelbare scholen, hogescholen bij het organiseren van massale gezondheidsverbetering, fysieke cultuur en sportwerk;

· Organiseert het onderwijs- en trainingsproces in sportafdelingen (nationale teams);

· Ontwikkelt en implementeert de kalenderplannen van massale recreatieve, fysieke cultuur- en sportevenementen, zorgt voor de veiligheid van hun bedrijf;

· Geeft controle over het onderwijs- en trainingsproces in de secties van de sportclub voor de voorbereiding van atleten met de hoogste sportkwalificatie, draagt bij aan het creëren van de noodzakelijke voorwaarden voor de groei van hun sportvaardigheden;

· Organiseert, samen met de gezondheidsautoriteiten, medische controle over de gezondheidstoestand van degenen die zich bezighouden met lichamelijke cultuur en sport in secties (gecombineerde teams);

· Opstellen van huidige en meerjarenplannen voor de ontwikkeling van massale fysieke cultuur en recreatie en educatief en sportwerk, kostenramingen voor de club.

· voert binnen de grenzen van zijn bevoegdheid de selectie en plaatsing uit van het fysieke cultuurpersoneel;

· Mag een vlag, embleem, sportuniform, postzegel, briefhoofd hebben;

· Houdt massawedstrijden, sportdagen (Universiades), trainingskampen;

· In overeenstemming met de goedgekeurde procedure stuurt teams en individuele atleten naar de competitie;

· Geeft passende certificaten (badges) af aan de leden van de nationale teams van de universiteit;

2.3 Opbouwen van een klassendiagram van het vakgebied "Organisatie van sportverenigingsprocessen"

De sportclub heeft vier sessies op basis van de club:

Basketbal

Volleybal

· Tennissen.

Wanneer kandidaten-atleten zich bij een sportclub aanmelden om zich voor een sectie in te schrijven, wordt de registratie uitgevoerd, wat de volgende acties omvat:

· Gegevens over atleten worden ingevoerd in een tabel met 5 velden: Achternaam, Voornaam, Leeftijd, Telefoon, Sectie.

· Atleten worden toegewezen aan de secties waarin de aanvraag wordt ingediend.

· Ouders van sporters krijgen het rooster van afdelingen van de sportvereniging.

Om het juiste werk van de club te organiseren, het werk van de secties te coördineren, coaches in dienst te nemen, vult de beheerder van de sportclub het schema in.

Bij toetreding tot de club wordt de atleet in de tabel ingevoerd met de aanduiding van de sectie. Alle atleten die bij de club betrokken zijn, moeten in de hoofdtabel worden ingeschreven met een aanduiding van de sectie.

Voor een visuele weergave van de werkprocessen van de sportvereniging is een UML-diagram gebouwd (Fig 2.3.1).

Rijst. 2.3.1 Objectgericht model van een sportclub.

3. BOUW VAN HET OBJECTMODEL VAN HET ONDERWERPGEBIED "ORGANISATIE VAN HET WERK VAN DE SPORTCLUB" MET BEHULP VAN DE VISUELE PROGRAMMEEROMGEVING DELPHI

3.1 Beschrijving van de applicatiestructuur

Deze applicatie maakt deel uit van het Sportpakket. Het bestaat uit een klasse: klasse TPeople.

Met de klas "TPeople" kunt u informatie maken en verzamelen over kinderen die betrokken zijn bij deze sportclub, die "Ogonyok" heette. Het heeft vijf velden: De naam wordt gespecificeerd door de string "Naam"; De achternaam wordt aangegeven door de string "Famil"; Leeftijd wordt opgeslagen in een numerieke variabele (int) "Leeftijd"; de telefoon wordt ingesteld door de tekenreeks "Tel"; De sectie waarin de atleet bezig is, wordt aangegeven door de tekenreeks "Sekc".

TMensen = klasse

Naam: String;

Familie: String;

Leeftijd: geheel getal;

tel: String;

sekc: tekenreeks;

constructor Maken (AName: String);

einde;

In dit geval wordt de invoer van velden op twee manieren gebruikt:

Laad waarde uit opgeslagen bestand met LST-extensie. (Figuur 3.1.1.)

De methode is georganiseerd met behulp van de OpenDlg-functie, waarbij elke regel van de klasse als een afzonderlijke waarde wordt gelezen.

var F: Tekstbestand;

ik: geheel getal;

beginnen

proberen

met OpenDlg doen PersonsList.Items

beginnen

indien niet uitvoeren dan afsluiten;

LoadFromFile (Bestandsnaam);

AssignFile (F, Copy (FileName, 1, Length (FileName) -4) + ". Lso");

Resetten (F);

ik: = 0;

terwijl Niet EOF (F) dat wel doet

beginnen

Objecten [i]: = TPeople.Create ("");

Readln (F, (Objecten [i] als TPeople) .Name);

Readln (F, (Objecten [i] als TPeople) .Familie);

Readln (F, (Objecten [i] as TPeople) .Leeftijd);

Readln (F, (Objecten [i] as TPeople) .tel);

Readln (F, (Objecten [i] als TPeople) .sekc);

Inc (ik);

einde;

SluitBestand (F);

einde;

behalve

op E: EFOpenError do ShowMessage ("Fout bij openen van bestand");

einde; einde;

Rijst. 3.1.1 Bestand downloaden.

De tweede methode om de tabel te vullen, wordt ingevoerd met behulp van de componenten Bewerken (Fig. 3.1.2.)

Rijst. 3.1.2 De tabel vullen met de component Bewerken.

Bovendien wordt de waarde van het veld "Sectie" geselecteerd uit de waarden van de Combobox-component en toegewezen aan de regel "Sekc". (Figuur 3.1.3)

Rijst. 3.1.3 Componenten combobox.

De ingevoerde waarden kunnen worden gecorrigeerd door de gewenste waarde te selecteren en op de knop "Wijzigen" te drukken (Fig. 3.1.4)

Rijst. 3.1.4 Waarden wijzigen.

Het programma voorziet in het wissen van een waarde door één record te wissen (Fig. 3.1.5) en alle records te wissen (Fig. 3.1.6).

Het verwijderen van één record wordt uitgevoerd door een waarde te selecteren en op de knop "Verwijderen" te drukken.

Rijst. 3.1.5 Eén invoer verwijderen.

Om alle records te wissen, drukt u op de knop "Wissen".

Rijst. 3.1.6 "Wissen" knop.

Beide verwijderingsmethoden worden op de volgende manieren uitgevoerd:

procedure TMainForm.ToolButton4Click (Afzender: TObject);

beginnen

doe met PersonsList Items.Delete (ItemIndex);

einde;

procedure TMainForm.ToolButton5Click (Afzender: TObject);

beginnen

PersonenLijst.Artikelen.Wissen;

einde;

Na het invullen van de tabel met atleten, wordt het noodzakelijk om deze op te slaan voor toekomstig gebruik. Dit doet u door op de knop "Opslaan" te klikken (Fig. 3.1.7). Nadat u op deze knop hebt geklikt, wordt een dialoogvenster geopend waarin de bestandsopslagmap en de naam worden aangegeven. (Afb. 3.1.8).

Vergelijkbare documenten

Korte omschrijving van het vakgebied. De relevantie van de ontwikkeling van een objectgeoriënteerd model van een informatiesysteem voor een educatieve bibliotheek. Maak een use case-diagram, een sequentiediagram, een coöperatief diagram, een klassendiagram.

scriptie, toegevoegd 06/01/2009

Ontwikkeling van een objectgeoriënteerd subsysteem voor magazijnboekhouding voor het bedrijf "KavkazYugAvto". Korte omschrijving van het vakgebied. Plotdiagrammen van plaatsing, use cases, volgorde, componenten en klassen. Genereren van C++ programmacode.

scriptie, toegevoegd 26-06-2011

De belangrijkste elementen van het objectmodel. De essentie en voordelen van de objectgeoriënteerde benadering, het concept van een object en een klasse. Uniforme modelleringstaal UML. Klassendiagrammen en interacties: doel, constructie en gebruiksvoorbeelden.

samenvatting, toegevoegd 06/09/2009

Beschrijving van het onderwerp "Winkelverkoop van computercomponenten". Bouwen van ER en relationeel datamodel, entiteiten en relaties. Creatie van ER en relationeel datamodel, queries, views, opgeslagen procedures voor het domein.

scriptie, toegevoegd 15-06-2014

Relevantie en praktische betekenis van de computerclubsoftwaresystemen. Domein analyse. Klassediagram, fysiek model van het systeem. Ontwikkeling van een visueel IS-project met behulp van de UML2.0-taal en de Microsoft Visio-modelleringsomgeving.

scriptie, toegevoegd 21-06-2014

Analyse van het vakgebied "Competition of Poets" op basis van een objectgeoriënteerde benadering. Ontwikkeling van een raamapplicatie en beschrijving van het informatiemodel van het domein. Beschrijving van de ontwikkelde C++ procedures en applicatietestresultaten.

scriptie toegevoegd 18-06-2013

Functioneel modelleren IDEF0. Beschrijving van alle processen van de afdeling technische ondersteuning. Ontleding van contextdiagram en hoofdprocessen. Een model van domeinprocessen bouwen in de IDEF1X-standaard. Interface voor verkeerscontroleprogramma's.

praktijkverslag, toegevoegd 22-11-2014

Het bouwen van een infologisch model van het vakgebied met behulp van de ER-diagrammethode. Creëren van DB-relaties met behulp van de SQL-taal. Het vullen van de database. Creëren van queries naar de database van de computerclub. Maak een rapport met behulp van Microsoft Word en Microsoft Excel.

scriptie, toegevoegd 26/02/2009

Korte omschrijving van het vakgebied. Maak een use case diagram, volgorde, samenwerking, klassen, plaatsing, componenten. Voeg details toe aan bewerkingsbeschrijvingen en definieer KLASSE-attributen. Genereren van C++ programmacode.

scriptie, toegevoegd 29/06/2011

Algemene kenmerken van het magazijn als object van economische activiteit. Maak een use-case en sequentiediagram. Een bedrijfssamenwerkingsdiagram maken. Het doel van het klassen- en componentendiagram. Genereren van C++ programmacode.

INVOERING

De belangrijkste kenmerken van elk systeem zijn de structuur en het werkingsproces. De structuur van een systeem wordt opgevat als een reeks onderlinge relaties tussen zijn elementen of componenten die stabiel is in de tijd. Het is de structuur die alle elementen samenbindt en voorkomt dat het systeem uiteenvalt in afzonderlijke componenten. De structuur van een systeem kan een verscheidenheid aan relaties weerspiegelen, waaronder het nesten van elementen van het ene systeem in het andere. In dit geval is het gebruikelijk om een kleiner of genest systeem een subsysteem te noemen. Het proces van functioneren van een systeem hangt nauw samen met de verandering in eigenschappen of gedrag in de loop van de tijd. In dit geval is een belangrijk kenmerk van het systeem de toestand, die wordt opgevat als een reeks eigenschappen of attributen die op elk moment de meest significante kenmerken van het gedrag van het systeem weerspiegelen. Een gemeenschappelijke eigenschap van alle modellen is hun gelijkenis met het oorspronkelijke systeem. Het belang van bouwmodellen ligt in de mogelijkheid om ze te gebruiken om informatie te verkrijgen over de eigenschappen of het gedrag van het oorspronkelijke systeem. In dit geval wordt het proces van het construeren en vervolgens toepassen van modellen om informatie over het oorspronkelijke systeem te verkrijgen modellering genoemd. Het algemene systeemmodel bevat enkele belangrijke informatie over de functionele kenmerken van dit systeem, die een idee geven van het toekomstige gedrag.

De studie van het modelleringsproces is het onderwerp van onderzoek in dit cursuswerk. De constructie van een specifiek objectmodel, de studie van het gedrag ervan zal worden beschouwd als het onderwerp van onderzoek. Om dit doel te bereiken worden de volgende methoden gebruikt: bestudering van de benodigde literatuur, vergelijking, voorbeelden uit levenservaring Aangezien de constructie van het objectmodel zal worden uitgevoerd aan de hand van het voorbeeld van een autoservice, is het noodzakelijk om het principe van werking van deze organisatie. Om dit te doen, volstaat het om de officiële websites van verschillende autodiensten te bezoeken. Maar om de principes van het bouwen van een objectmodel te bestuderen, bestudeerde ik wetenschappelijke binnen- en buitenlandse literatuur. Het bleek een zeer spannende ervaring te zijn.

Het doel van mijn cursuswerk was dan ook: het bouwen van een objectmodel van het informatiesysteem "Autoservice", het bestuderen van het principe van het bouwen van een objectmodel, het beschrijven van het bouwproces, het aantonen van het belang van het bezitten van deze kennis en het vermogen om het in de praktijk toe te passen.

De opbouw van het cursuswerk is als volgt: eerst wordt de theorie van het construeren van een objectief model bestudeerd, daarna wordt de implementatie van de theorie getoetst aan een praktijkvoorbeeld.

Basisconcepten van de objectgeoriënteerde benadering

De objectgeoriënteerde benadering is gebaseerd op het systematisch gebruik van modellen. Objecten en concepten uit de echte wereld die gerelateerd zijn aan het ontwikkelde softwaresysteem zijn betrokken bij de formulering van het doel. In de objectgeoriënteerde benadering worden deze objecten en concepten vervangen door hun modellen, d.w.z. bepaalde formele constructies die ze vertegenwoordigen in het softwaresysteem.

Het model bevat niet alle tekens en eigenschappen van het object of concept dat het vertegenwoordigt, maar alleen die die essentieel zijn voor het softwaresysteem dat wordt ontwikkeld. Het model is dus eenvoudiger dan het object (concept) dat het vertegenwoordigt. Dit vereenvoudigt zowel de ontwikkeling en studie (analyse) van modellen als de implementatie ervan op een computer. In het bijzonder maakt het formele karakter van de modellen het mogelijk om een formeel model van het ontwikkelde softwaresysteem te verkrijgen als een samenstelling van formele modellen van zijn componenten.

De objectgeoriënteerde benadering helpt dus om complexe problemen het hoofd te bieden, zoals het verminderen van de complexiteit van software; het vergroten van de betrouwbaarheid van software; de mogelijkheid bieden om individuele softwarecomponenten te wijzigen zonder de rest van de componenten te wijzigen; de mogelijkheid van hergebruik van afzonderlijke softwarecomponenten te waarborgen.

De systematische toepassing van de objectgeoriënteerde benadering maakt het mogelijk om goed gestructureerde, bedrijfszekere, vrij gemakkelijk aanpasbare softwaresystemen te ontwikkelen. Dit verklaart de interesse van programmeurs voor de objectgeoriënteerde benadering. De objectgeoriënteerde benadering is een van de meest intensief ontwikkelende gebieden van theoretisch en toegepast programmeren.

Objectgeoriënteerde softwareontwikkeling wordt geassocieerd met de toepassing van objectgeoriënteerde modellen bij de ontwikkeling van softwaresystemen en hun componenten.

Objectgeoriënteerde ontwikkeling kan al in de allereerste fase van de levenscyclus beginnen; het is niet gerelateerd aan de programmeertaal waarin het ontwikkelde softwaresysteem zou moeten worden geïmplementeerd: deze taal mag niet objectgeoriënteerd zijn. In de ontwikkelingsfase zijn objecten enkele formele constructies (bijvoorbeeld rechthoeken met afgeronde hoeken, met behulp waarvan ze worden weergegeven in diagrammen), die op geen enkele manier verband houden met hun toekomstige implementatie in een van de programmeertalen.

Objectgeoriënteerde softwareontwikkeling wordt geassocieerd met de toepassing van objectgeoriënteerde methodieken (technologieën). Meestal worden deze objectgeoriënteerde methodologieën ondersteund door softwaretools, maar zelfs zonder dergelijke tools zijn ze nuttig, omdat ze je in staat stellen om verschillende aspecten en eigenschappen van het softwaresysteem dat wordt ontwikkeld goed te begrijpen, wat vervolgens de implementatie, het testen, onderhoud, ontwikkeling van nieuwe versies en meer ingrijpende modificaties.

Het ontwerpen van een applicatiesoftwaresysteem begint met een analyse van de eisen waaraan het moet voldoen. Een dergelijke analyse wordt uitgevoerd om het doel en de bedrijfsomstandigheden van het systeem te begrijpen en het voorlopige ontwerp te kunnen opstellen.

In de objectgeoriënteerde benadering wordt de analyse van systeemvereisten gereduceerd tot het ontwikkelen van modellen van dit systeem. Het model van een systeem (of een ander object of fenomeen) is een formele beschrijving van het systeem, waarin de belangrijkste objecten waaruit het systeem bestaat en de relaties tussen deze objecten worden benadrukt. Modelbouw is een wijdverbreide manier om complexe objecten en fenomenen te bestuderen. Het model heeft tal van details weggelaten die het moeilijk maken om het te begrijpen. Modellering is wijdverbreid in zowel wetenschap als technologie.

Modellen helpen om de prestaties van het systeem dat wordt ontwikkeld in de vroege stadia van zijn ontwikkeling te controleren, om met de klant van het systeem te communiceren, de vereisten voor het systeem te verduidelijken, om (indien nodig) wijzigingen aan te brengen in het ontwerp van het systeem (beide aan het begin van het ontwerp en in andere fasen van de levenscyclus).

Modellen die zijn ontwikkeld en gedebugd in de eerste fase van de levenscyclus van het systeem, worden nog steeds gebruikt in alle volgende fasen, waardoor systeemprogrammering, debuggen en testen, onderhoud en verdere modificaties worden vergemakkelijkt.

Het objectmodel beschrijft de structuur van de objecten waaruit het systeem bestaat, hun attributen, bewerkingen, relaties met andere objecten. Het objectmodel moet die concepten en objecten van de echte wereld weerspiegelen die belangrijk zijn voor het systeem dat wordt ontwikkeld. Het objectmodel weerspiegelt in de eerste plaats de pragmatiek van het systeem dat wordt ontwikkeld, wat tot uiting komt in het gebruik van de terminologie van het toegepaste gebied dat samenhangt met het gebruik van het systeem dat wordt ontwikkeld.

Laten we eens kijken naar de basisconcepten die worden gebruikt bij het bouwen van een objectmodel.

Een object is een abstractie of iets anders met duidelijk afgebakende grenzen dat logisch is in de context van het toegepaste probleem in kwestie. Het introduceren van objecten heeft twee doelen: het begrijpen van het toegepaste probleem (probleem) en het introduceren van de basis voor implementatie op een computer.

Het doel van het ontwikkelen van een objectmodel is het beschrijven van de objecten waaruit het ontwerpsysteem bestaat, en het identificeren en aangeven van de verschillende afhankelijkheden tussen objecten.

Een klasse is een descriptor voor een set objecten die dezelfde eigenschappen hebben. De klasse beschrijft de eigenschappen van een aantal objecten. Elk object is een instantie van slechts één klasse.

Alle objecten van dezelfde klasse worden gekenmerkt door dezelfde set attributen. De vereniging van objecten in klassen wordt echter niet bepaald door de verzamelingen attributen, maar door semantiek. Een stal en een paard kunnen bijvoorbeeld dezelfde kenmerken hebben: prijs en leeftijd. Bovendien kunnen ze tot dezelfde klasse behoren, als ze in het probleem eenvoudig als handelswaar worden beschouwd, of tot verschillende klassen, wat natuurlijker is.

Door objecten in klassen te combineren, kunt u een abstractie in het probleem introduceren en het in een meer algemene setting beschouwen. Een klasse heeft een naam (bijvoorbeeld paard) die verwijst naar alle objecten van die klasse. Daarnaast introduceert de klasse de namen van de attributen die voor de objecten zijn gedefinieerd. In die zin is de beschrijving van de klasse vergelijkbaar met de beschrijving van het type structuur (record); bovendien heeft elk object dezelfde betekenis als een instantie van de structuur (een variabele of constante van het overeenkomstige type).

Een objectattribuut is een waarde die een object in zijn klasse kenmerkt. Voorbeelden van attributen: merk, bouwjaar, kleur (attributen van objecten van de klasse auto), etc.

Een operatie is een functie (of transformatie) die kan worden toegepast op objecten van een bepaalde klasse. Voorbeelden van bewerkingen: controleren, verwijderen, afleveren (voor objecten van de klasse reserveonderdelen).

Alle objecten van een bepaalde klasse gebruiken dezelfde instantie van elke bewerking (dat wil zeggen, een toename van het aantal objecten van een bepaalde klasse leidt niet tot een toename van de hoeveelheid geladen programmacode). Het object van waaruit de bewerking wordt aangeroepen, wordt eraan doorgegeven als zijn impliciete argument (parameter).

Dezelfde bewerking kan worden toegepast op objecten van verschillende klassen: een dergelijke bewerking wordt polymorf genoemd, omdat deze verschillende vormen kan hebben voor verschillende klassen.

Afhankelijkheden tussen klassen zijn in twee richtingen: alle klassen zijn, afhankelijk van, gelijk. Dit geldt zelfs in gevallen waarin de naam van de afhankelijkheid richting lijkt te geven aan deze afhankelijkheid. Afhankelijkheden tussen klassen komen overeen met afhankelijkheden tussen objecten van deze klassen. Afhankelijkheden kunnen, net als klassen, attributen hebben.

De discriminator is een attribuut van het type "enumeration" dat aangeeft welke van de objecteigenschappen voor deze generalisatie wordt gebruikt.

Rol definieert één kant van de verslaving. Er zijn twee rollen gedefinieerd in een binaire afhankelijkheid. De rolnaam identificeert op unieke wijze één kant van de afhankelijkheid. Rollen maken het mogelijk om een binaire afhankelijkheid te zien als een relatie tussen een object en een set afhankelijke objecten: elke rol is een aanduiding van een object of een set objecten die door een afhankelijkheid gerelateerd zijn aan een object aan de andere kant van de afhankelijkheid. Een rolnaam kan worden gezien als een afgeleid attribuut waarvan de reeks waarden de reeks objecten is die aan die rol zijn gekoppeld. In een binaire afhankelijkheid kan een paar rolnamen worden gebruikt om die afhankelijkheid te identificeren.

Rolnamen moeten worden opgegeven wanneer afhankelijkheden worden vastgesteld tussen objecten van dezelfde klasse. Rolnamen moeten uniek zijn omdat ze worden gebruikt om onderscheid te maken tussen objecten die bij een afhankelijkheid betrokken zijn.

Een kwalificatie is een attribuut waarmee u de effectieve veelvoud van een afhankelijkheid kunt verminderen. Kwalificaties worden gebruikt in een-op-veel of veel-op-veel afhankelijkheden.

Aggregatie is de relatie tussen een klasse van samengestelde objecten en de klassen die de componenten van deze objecten vertegenwoordigen (de relatie "geheel" - "deel").

Generalisatie en overerving stellen u in staat om analogieën tussen verschillende klassen van objecten te identificeren, een classificatie van objecten op meerdere niveaus te definiëren. In grafische systemen kunnen er dus klassen zijn die de omtrek van verschillende geometrische vormen definiëren: punten, lijnen (rechte lijnen, cirkelbogen en krommen gedefinieerd door splines), polygonen, cirkels, enz.

De discriminator is een attribuut van het type "enumeration" dat aangeeft welke van de objecteigenschappen voor deze generalisatie wordt gebruikt.

Opgemerkt moet worden dat uitgebreide gelaagde classificaties moeten worden vermeden, aangezien het gedrag van subklassen van de lagere niveaus van gelaagde classificatie moeilijk te begrijpen kan zijn: de meeste (en vaak alle) attributen en bewerkingen van dergelijke klassen zijn gedefinieerd in hun superklassen op verschillende niveaus. Als het aantal classificatieniveaus onbetaalbaar is geworden, moet de structurering van het systeem enigszins worden geherstructureerd.

Generalisatie en overerving worden veel gebruikt, niet alleen bij de analyse van vereisten voor softwaresystemen en hun voorlopige ontwerp, maar ook bij de implementatie ervan.

Soms is het in een subklasse nodig om een bewerking te overschrijven die is gedefinieerd in een van zijn superklassen. Hiervoor wordt in de subklasse ook de bewerking gedefinieerd die door overerving uit de superklasse kan worden verkregen; deze herdefinitie ervan "verduistert" zijn definitie in de superklasse, dus de subklasse gebruikt niet de overgeërfde bewerking, maar de opnieuw gedefinieerde bewerking. Bedenk dat elke bewerking wordt geïdentificeerd door zijn eigen handtekening; daarom moet de handtekening van de bewerkingsoverschrijving overeenkomen met de handtekening van de bewerking van de superklasse die wordt overschreven door de bewerking.

Overschrijven kan een van de volgende doelen dienen:

extension: de nieuwe operatie breidt de overgeërfde operatie uit, rekening houdend met de invloed van de attributen van de subklasse;

beperking: de nieuwe operatie is beperkt tot het uitvoeren van slechts een deel van de acties van de overgeërfde operatie, gebruikmakend van de specifieke kenmerken van de objecten van de subklasse;

optimalisatie: door de specifieke kenmerken van subklasse-objecten te gebruiken, kunt u de bijbehorende methode vereenvoudigen en versnellen;

gemak.

Het is raadzaam om de volgende semantische overervingsregels in acht te nemen:

alle querybewerkingen (bewerkingen die attribuutwaarden gebruiken, maar deze niet wijzigen) moeten worden overgenomen door alle subklassen;

alle bewerkingen die attribuutwaarden wijzigen, moeten in al hun extensies worden overgenomen;

alle bewerkingen die de waarden van beperkte attributen wijzigen, of attributen die afhankelijkheden definiëren, moeten in al hun extensies worden geblokkeerd;

operaties mogen niet worden overschreven; alle methoden die dezelfde bewerking implementeren, moeten dezelfde attribuutconversie uitvoeren;

geërfde bewerkingen kunnen worden verfijnd door extra acties toe te voegen.

Door deze regels te volgen, die helaas zelden worden ondersteund door objectgeoriënteerde programmeertalen, kunt u het ontwikkelde programma begrijpelijker, gemakkelijker aan te passen, minder vatbaar maken voor verschillende fouten en onoplettendheid.

Een abstracte klasse kan geen objecten hebben, omdat er geen bewerkingen op objecten in zijn gedefinieerd; objecten moeten behoren tot concrete subklassen van de abstracte klasse. Abstracte klassen worden gebruikt om de interfaces van bewerkingen te specificeren (methoden die deze bewerkingen implementeren worden vervolgens gedefinieerd in subklassen van de abstracte klasse). Abstracte klassen zijn handig in het stadium van het analyseren van de vereisten voor het systeem, omdat ze u in staat stellen een analogie te identificeren in schijnbaar verschillende bewerkingen die in het geanalyseerde systeem zijn gedefinieerd.

Met meervoudige overerving kan een klasse meer dan één superklasse hebben door eigenschappen (attributen en bewerkingen) van al zijn superklassen te erven. Een klasse die meerdere superklassen heeft, wordt een samengevoegde klasse genoemd. Eigenschappen van een voorouderklasse die meer dan eens in een overervingsgrafiek voorkomt, worden slechts in één instantie overgeërfd. Conflicten tussen parallelle definities genereren dubbelzinnigheden die tijdens de implementatie moeten worden opgelost. In de praktijk moeten dergelijke dubbelzinnigheden of misverstanden worden vermeden, zelfs wanneer de specifieke programmeertaal die is gekozen om het systeem te implementeren de mogelijkheid biedt om ze op te lossen met behulp van prioriteiten of op een andere manier.

Bij objectgeoriënteerd ontwerpen hebben we te maken met veel onderling verbonden objecten. Elk object kan worden beschouwd als een variabele of constante van een gestructureerd type (in deze overweging worden de in het object beschreven methoden behandeld als adressen van functies die op dit object mogen worden toegepast). Daarom is een set objecten een set onderling verbonden gegevens, d.w.z. iets dat erg lijkt op een database. Daarom is het gebruik van databaseconcepten vaak nuttig bij objectgeoriënteerde analyse en objectgeoriënteerd ontwerp van toegepaste softwaresystemen.

Metadata zijn data die andere data beschrijven. Een klassedefinitie is bijvoorbeeld metadata, aangezien een klasse andere data-objecten van deze klasse beschrijft. Modellen zijn metadata omdat ze de objecten beschrijven die worden gemodelleerd. Een ander voorbeeld van metadata is een abstracte klasse.

Actoren zijn rollen die worden gespeeld door entiteiten die rechtstreeks met het systeem interageren.

De actor definieert de rol die een externe entiteit speelt in directe interactie met dit systeem. Het kan een gebruikersrol vertegenwoordigen of een rol die wordt gespeeld door een ander systeem of stuk hardware dat de grenzen van het systeem raakt.

Ik vond de beschrijving van het concept 'acteur' in het werk 'UML 2 and the Unified Process' van Jim Arlow en Isle Neustadt erg goed: 'Om acteurs te begrijpen, is het belangrijk om het concept van rollen te begrijpen. Een rol kan worden gezien als een hoed die in een bepaalde situatie wordt gedragen." (pagina 92).

Wanneer de basisconcepten bekend zijn, kan de constructie van het model zelf worden overwogen.

Het objectmodel bouwen

Klassen definiëren

Analyse van externe vereisten voor het ontworpen applicatiesysteem stelt u in staat om de objecten en klassen van objecten te bepalen die verband houden met het applicatieprobleem dat dit systeem moet oplossen. U moet beginnen met de mogelijke klassen te markeren uit de schriftelijke verklaring van het toegepaste probleem (technische specificaties en andere documentatie verstrekt door de klant). Dit is een zeer moeilijke en cruciale ontwikkelingsfase, aangezien het verdere lot van het project er grotendeels van afhangt.

Wanneer u mogelijke klassen identificeert, moet u proberen zoveel mogelijk klassen te markeren en de naam op te schrijven van elke klasse die in u opkomt. In het bijzonder kan een klasse overeenkomen met elk zelfstandig naamwoord dat voorkomt in de voorlopige formulering van het probleem. Daarom wordt bij het identificeren van mogelijke klassen elk zelfstandig naamwoord gewoonlijk geassocieerd met een mogelijke klasse.

redundante klassen: als twee of meer klassen dezelfde informatie uitdrukken, mag er slechts één worden behouden;

irrelevante (niet direct gerelateerd aan het probleem) klassen: voor elke naam van een mogelijke klasse wordt beoordeeld hoe noodzakelijk het is in het toekomstige systeem (het is vaak erg moeilijk om dit in te schatten); irrelevante klassen zijn uitgesloten;

vaag gedefinieerde (vanuit het oogpunt van het probleem in kwestie) klassen;

attributen: sommige zelfstandige naamwoorden komen niet meer overeen met klassen, maar met attributen; dergelijke zelfstandige naamwoorden beschrijven in de regel de eigenschappen van objecten (bijvoorbeeld naam, leeftijd, gewicht, adres, enz.);

operaties: sommige zelfstandige naamwoorden komen niet meer overeen met klassen, maar namen van operaties (bijvoorbeeld phone_call betekent bijna geen klasse);

Rollen: sommige zelfstandige naamwoorden definiëren de namen van rollen in het objectmodel (bijvoorbeeld eigenaar, chauffeur, baas, werknemer; al deze namen worden geassocieerd met rollen in verschillende afhankelijkheden van objecten van klassepersoon);

implementatieconstructies: namen die meer worden geassocieerd met programmeren en computerhardware mogen in dit stadium niet worden vergeleken met klassen, omdat ze niet de kenmerken van het ontworpen applicatiesysteem weerspiegelen; voorbeelden van zulke namen: subroutine, proces, algoritme, interrupt, etc.

Na het weglaten van de namen van alle onnodige (onnodige) mogelijke klassen, zal een voorlopige lijst van klassen worden verkregen die het ontworpen systeem vormen.

Een datadictionary voorbereiden

Sommige woorden hebben te veel interpretaties. Daarom is het aan het begin van het ontwerp noodzakelijk om een datadictionary op te stellen met duidelijke en ondubbelzinnige definities van alle objecten (klassen), attributen, bewerkingen, rollen en andere entiteiten die in het project worden overwogen. Zonder een dergelijk vocabulaire heeft een discussie over een project met ontwikkelingscollega's en systeemklanten geen zin, aangezien iedereen de besproken termen op zijn eigen manier kan interpreteren.

2.3. Definitie van afhankelijkheid

In de volgende fase van het bouwen van het objectmodel worden de afhankelijkheden tussen de klassen bepaald. Allereerst worden attributen die expliciete verwijzingen zijn naar andere klassen uitgesloten van klassen; dergelijke attributen worden vervangen door afhankelijkheden. De betekenis van een dergelijke vervanging is dat afhankelijkheden een abstractie zijn van hetzelfde niveau als klassen en daarom geen directe impact hebben op de toekomstige implementatie (verwijzing naar een klasse is slechts een van de manieren om afhankelijkheden te implementeren).

Op dezelfde manier als de namen van mogelijke klassen werden verkregen uit zelfstandige naamwoorden die voorkomen in de voorlopige formulering van het toegepaste probleem, kunnen de namen van mogelijke afhankelijkheden worden verkregen uit werkwoorden of werkwoordzinnen die voorkomen in het gespecificeerde document. Dit is hoe ze gewoonlijk beschrijven: fysieke positie (volgt, is_ een onderdeel, bevat_in), gerichte actie (drijft_beweging), communicatie (praten_met), erbij horen (heeft, is_onderdeel), etc.

Dan moeten onnodige of onjuiste afhankelijkheden worden verwijderd met behulp van de volgende criteria:

afhankelijkheden tussen uitgesloten klassen moeten worden geëlimineerd, of geherformuleerd in termen van de resterende klassen;

irrelevant en implementatieafhankelijkheden moeten worden uitgesloten;

acties: de afhankelijkheid moet de structurele eigenschappen van het toepassingsgebied beschrijven, en geen kleine gebeurtenissen;

Trear-afhankelijkheden: de meeste afhankelijkheden tussen drie of meer klassen kunnen worden ontleed in verschillende binaire afhankelijkheden, indien nodig met behulp van kwalificaties; in sommige (zeer zeldzame) gevallen mislukt een dergelijke ontbinding; bijvoorbeeld de treinafhankelijkheid "De professor geeft een cursus in kamer 628" kan niet worden ontleed in binair zonder verlies van informatie;

afgeleide afhankelijkheden: u moet afhankelijkheden uitsluiten die via andere afhankelijkheden kunnen worden uitgedrukt, omdat ze redundant zijn; bij het elimineren van overbodige (afgeleide) afhankelijkheden, moet je extra voorzichtig zijn, aangezien niet alle dubbele afhankelijkheden tussen klassen overbodig zijn; in sommige gevallen laten andere afhankelijkheden alleen toe om het bestaan van een andere afgeleide afhankelijkheid vast te stellen, maar niet om de veelvoud van deze afhankelijkheid vast te stellen.

Nadat u overbodige afhankelijkheden hebt verwijderd, moet u de semantiek van de resterende afhankelijkheden als volgt verduidelijken:

onjuist benoemde afhankelijkheden: ze moeten worden hernoemd zodat hun betekenis duidelijk wordt;

rolnamen: voeg waar nodig rolnamen toe; de rolnaam beschrijft de rol die de corresponderende klasse speelt in deze afhankelijkheid vanuit het oogpunt van een andere klasse die deelneemt aan deze afhankelijkheid; als de rolnaam duidelijk is uit de klassenaam, kan deze worden weggelaten;

qualifiers: door waar nodig qualifiers toe te voegen, introduceren we contextuele elementen, waardoor we een eenduidige identificatie van objecten kunnen bereiken; qualifiers kunnen ook sommige afhankelijkheden vereenvoudigen door hun multipliciteit te verlagen;

veelvoud: het is noodzakelijk om symbolen toe te voegen voor de veelvoud van afhankelijkheden; er moet aan worden herinnerd dat de veelheid van afhankelijkheden kan veranderen in het proces van verdere analyse van de vereisten voor het systeem;

niet-verantwoorde afhankelijkheden moeten worden geïdentificeerd en aan het model worden toegevoegd.

2.4. Kenmerken verduidelijken

In de volgende fase wordt het systeem van attributen verfijnd: de attributen van de klassen worden gecorrigeerd en zo nodig worden nieuwe attributen geïntroduceerd. Attributen drukken de eigenschappen van objecten van de betreffende klasse uit, of bepalen hun huidige staat.

Attributen komen meestal overeen met zelfstandige naamwoorden; bijv. car_color (objecteigenschap), cursor_position (objectstatus). Attributen hebben meestal weinig effect op de structuur van het objectmodel.

Naast de attributen van objecten is het noodzakelijk om attributen van afhankelijkheden tussen klassen (koppelingen tussen objecten) te introduceren.

Bij het specificeren van attributen worden de volgende criteria gevolgd:

Attributen vervangen door objecten. Als de aanwezigheid van een entiteit belangrijker is dan zijn waarde, dan is dit een object, als de waarde belangrijker is, dan is dit een attribuut: bijvoorbeeld een baas is een object (het maakt niet uit wie de baas is , het belangrijkste is dat iemand dat is), salaris is een attribuut (de betekenis ervan is erg belangrijk); een stad is altijd een object, hoewel het in sommige gevallen lijkt op een attribuut (bijvoorbeeld een stad als onderdeel van een bedrijfsadres); in gevallen waarin u wilt dat de stad een attribuut is, moet u de relatie (laten we zeggen is) definiëren tussen de klassen stevig en stad.

Kwalificaties. Als de waarde van een attribuut contextspecifiek is, moet er een kwalificatie van worden gemaakt.

Namen. Namen komen over het algemeen beter overeen met kwalificaties dan objectattributen; in alle gevallen, wanneer de naam je toelaat om een keuze te maken uit objecten van een bepaalde set, zou het een kwalificatie moeten zijn.

ID's. Object-ID's zijn gekoppeld aan hun implementatie. In de vroege stadia van het ontwerp moeten ze niet als attributen worden beschouwd.

Kenmerken koppelen. Als een eigenschap niet een object op zich kenmerkt, maar de verbinding met een ander object (objecten), dan is dit een attribuut van een verbinding, geen attribuut van een object.

Interne waarden. Attributen die alleen de interne staat van het object bepalen, onzichtbaar buiten het object, moeten buiten beschouwing worden gelaten.

Onbeduidende details. Het wordt aanbevolen om kenmerken weg te laten die de prestaties van de meeste bewerkingen niet beïnvloeden.

2.5. Toewijzing van subsystemen

Een applicatiesysteem is een verzameling onderling afhankelijke objecten. Elk object wordt gekenmerkt door een reeks attributen, waarvan de waarden de status van het object bepalen, en een reeks bewerkingen die op dit object kunnen worden toegepast. Bij het ontwikkelen van applicatiesystemen is het handig om aan te nemen dat alle attributen van objecten privé zijn (dwz dat ze niet beschikbaar zijn buiten het object, en om de waarde van een attribuut van een ander object in een object te achterhalen of te wijzigen, het is noodzakelijk om een van de open bewerkingen van dit object te gebruiken, als natuurlijk een dergelijke bewerking is gedefinieerd). Objectbewerkingen kunnen openbaar of privé zijn.

Elk object heeft dus een strikt gedefinieerde interface, d.w.z. een reeks open bewerkingen die op dit object kunnen worden toegepast. Alle objecten van dezelfde klasse hebben dezelfde interface. De interface van een klasse (en bijgevolg van elk object van deze klasse) wordt gespecificeerd door een lijst van handtekeningen van zijn openbare (openbare) operaties (en methoden die deze implementeren); handtekeningen van privé-bewerkingen zijn niet opgenomen in de interface van objecten van de overeenkomstige klasse.

enzovoort.................

Het bouwen van een objectmodel van het probleem met behulp van de UML-modelleertaal.

WERK IN STARUML

Doorlooptijd:

2 - 3 lessen

Om het werk te verdedigen, moet een project worden geleverd dat is gemaakt in het Rational Rose-pakket, dat drie soorten diagrammen bevat: use-cases, klassen (interface, gegevens) en reeksen voor elke functie.

VOORBEELD OPDRACHT:

Het is noodzakelijk om ervoor te zorgen dat de volgende informatie in de database wordt opgeslagen:

- studenteninformatie

O VOOR-EN ACHTERNAAM.,

O adres,

O paspoort gegevens,

O klas nummer,

O Geboortedatum,

O groep);

- informatie over specialiteiten

O naam van de specialiteit,

O cijfer;

- groepsinformatie

O specialiteit,

O jaar van toelating,

O groepnummer.

Zorg voor de afgifte van het document "Groepslijst" met daarin de velden:

· serienummer,

· VOOR-EN ACHTERNAAM.,

· studenten nummer.

Werkorder

Objectmodelbouw wordt uitgevoerd in het Rational Rose-pakket. Laten we hiervoor een leeg project maken. Begin met een use case-diagram. Het is gebouwd in het hoofdgedeelte van het gedeelte Use Case View, zoals weergegeven in Fig. 9.

Voordat u begint met het bouwen van een diagram, is het noodzakelijk om de rollen van systeemgebruikers (actoren) en hun functies (use cases) te bepalen. In ons geval werken twee actoren met het systeem - dat zijn "Medewerker van de onderwijsafdeling" en "Medewerker van het decanaat". De functies van een medewerker van de educatieve afdeling omvatten het bijhouden van een lijst met specialiteiten (onder een lijst bijhouden we begrijpen het toevoegen van records, corrigeren en verwijderen). De functies van een medewerker van het decanaat zijn onder meer het bijhouden van een studentenlijst en het bijhouden van een lijst met groepen.

Het geconstrueerde diagram wordt getoond in Fig. tien.

Vervolgens moeten in de sectie Logische weergave twee klassendiagrammen worden gemaakt. Om dit te doen, kunt u twee pakketten maken. Het eerste diagram moet de klassen van de interface van de ontworpen applicatie bevatten (zie Fig. 11). In deze figuur zijn in de klassen "Lijst van groepen" en "Lijst van studenten", de bewerkingen van toevoegen, wijzigen en verwijderen weggelaten om te voorkomen dat de figuur rommelig wordt. De lijst van de groep (lagere klas) is het uitvoerdocument (voorafgegaan door de klas "Selecteer een groep", aangezien het nodig is om een lijst met studenten van een bepaalde groep te krijgen). Het tweede diagram zijn de database-entiteiten (zie figuur 12).

Het geconstrueerde klassendiagram toont alle vormen van de toekomstige toepassing en hun relatie.

Sleutelvelden moeten worden ingesteld en er moet een koppeling tot stand worden gebracht (vanuit het contextmenu van de pijl - Multipliciteit).

De volgende stap bij het bouwen van het objectmodel is het maken van sequentiediagrammen. Sequentiediagrammen worden gegenereerd voor elke use case in het use case diagram. Om een sequentiediagram aan een use case toe te voegen, selecteert u het in de boomstructuur en roept u het contextmenu erop (NewàSequence Diagram) zoals getoond in Fig. 13.

In Fig. veertien.

Opgemerkt moet worden dat bij het bouwen van dit type diagram voor het uitvoerdocument "Groepslijst", in ons geval eerst een groep moet worden geselecteerd op het formulier "Groepsselectie" (op zijn beurt moeten gegevens van de entiteit "Groep" er naartoe gaan ), en geef vervolgens het uitvoerformulierdocument weer, dat gegevens ontvangt van de entiteit "Student".

In de objectgeoriënteerde benadering wordt de analyse van systeemvereisten gereduceerd tot het ontwikkelen van modellen van dit systeem. Een model van een systeem (of een ander object of fenomeen) noemen we een formele beschrijving van het systeem, waarin de belangrijkste objecten waaruit het systeem bestaat en de relaties tussen deze objecten worden benadrukt. Modelbouw is een wijdverbreide manier om complexe objecten en fenomenen te bestuderen. Het model heeft tal van details weggelaten die het moeilijk maken om het te begrijpen. Modellering is wijdverbreid in zowel wetenschap als technologie.

Modellen helpen:

Controleer de prestaties van het systeem dat wordt ontwikkeld in de vroege stadia van zijn ontwikkeling;

Communiceer met de klant van het systeem en verduidelijk zijn vereisten voor het systeem;

Breng (indien nodig) wijzigingen aan in het systeemontwerp (zowel aan het begin van het ontwerp als in andere fasen van de levenscyclus).

Momenteel zijn er verschillende technologieën voor objectgeoriënteerde ontwikkeling van toegepaste softwaresystemen, die gebaseerd zijn op de constructie en interpretatie van modellen van deze systemen op een computer. Een daarvan wordt in dit project gebruikt - OMT (Object Modeling Techniques). Bovendien is het objectmodeldiagram gebouwd in de UML-taal.

Objectmodelklassen definiëren

De analyse van externe vereisten voor het ontworpen systeem stelt u in staat om de objecten en klassen van objecten te bepalen die verband houden met het toepassingsprobleem, dat door dit systeem moet worden opgelost. Alle klassen moeten worden begrepen in het betreffende toepassingsdomein; klassen met betrekking tot een computerimplementatie, zoals een lijst, een stapel, enz. mag in dit stadium niet worden ingevoerd.

Laten we beginnen met het benadrukken van de mogelijke klassen uit de schriftelijke formulering van het toegepaste probleem. Wanneer u mogelijke klassen identificeert, moet u proberen zoveel mogelijk klassen te markeren en de naam op te schrijven van elke klasse die in u opkomt. In het bijzonder kan een klasse overeenkomen met elk zelfstandig naamwoord dat voorkomt in de voorlopige formulering van het probleem. Daarom wordt bij het identificeren van mogelijke klassen elk zelfstandig naamwoord gewoonlijk geassocieerd met een mogelijke klasse.

Als resultaat krijgen we de volgende lijst met mogelijke klassenamen:

Een andere proxy;

Document;

Externe webserver;

Configuratie;

Informatie over het document;

Informatie over de externe webserver;

Koptekst aanvragen;

Reactiekop.

Een objectmodel bouwen. Objecten worden gekenmerkt door attributen

Een objectmodel bouwen van het vakgebied "organisatie van sportclubprocessen" met behulp van de UML-modelleertaal

1. THEORETISCHE BASISBEPALINGEN VAN OBJECTGERICHTE METHODOLOGIE

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

INVOERING

Bij gebruik van een computer wordt dit proces veel nauwkeuriger en sneller, zonder veel overlappingen die optreden bij het handmatig organiseren.

Een domeinobjectmodel kan worden gebouwd met behulp van de UML-taal voor visuele objectmodellering of als een softwareproduct in een programmeertaal die objectprogrammeertechnologie ondersteunt, een voorbeeld hiervan is Object Pascal.

Om het doel van dit onderzoek te bereiken, zijn de volgende taken opgesteld:

· Bestudeer de theoretische basisvoorzieningen van de objectgeoriënteerde methodiek;

· Overweeg de UML en bouw een objectmodel van het domein met behulp van deze taal;

· Ontwikkel een applicatie die een reeks klassen gebruikt om informatie over atleten weer te geven.

Het onderzoeksobject van deze cursus is een objectgeoriënteerde ontwerpmethodiek.

Het onderwerp van dit onderzoek is het objectmodel van het vakgebied "Organisatie van het werk van een sportvereniging" en de belangrijkste eigenschappen ervan.

In de fase van het analyseren van het domein en het ontwerpen van de structuur van de applicatie, is het noodzakelijk om een ​​UML-klassendiagram te bouwen.

Bij het schrijven van een cursusproject zijn de volgende onderzoeksmethoden gebruikt:

· De beschrijvende methode wordt gebruikt bij de presentatie van de theoretische aspecten van het probleem en een korte beschrijving van het onderzoeksobject;

· Methode van vergelijking en analyse. Hiermee kunt u verschillende opvattingen over het onderwerp in kwestie vergelijken en het object van onderzoek diagnosticeren;

· Systeem benadering. Het werd gebruikt om de verkregen resultaten samen te vatten en hun logische relatie te identificeren.

1. THEORETISCHE BASISBEPALINGEN VAN OBJECTGERICHTE METHODOLOGIE

1.1 Basisconcepten van de objectgeoriënteerde benadering

onderwerp taal programmeermodel

Programmeren heeft lange tijd gebruik gemaakt van een gestructureerd procedureel model. De keuze van de projectdoelstellingen wordt uitgevoerd door een van de twee benaderingen, genaamd "top-down" en dienovereenkomstig "bottom-up"

2. De bottom-upbenadering houdt in dat procedures worden geschreven om eenvoudige problemen op te lossen, waarna ze achtereenvolgens worden gecombineerd tot complexere procedures totdat het gewenste effect is bereikt.

Belangrijke programmeerconcepten zijn procedureel programmeren en objectgeoriënteerd programmeren.

Procedureel georiënteerd programmeren is programmeren in een imperatieve taal, waarin sequentieel uitgevoerde instructies kunnen worden samengevoegd tot subroutines, dat wil zeggen grotere integrale code-eenheden, met behulp van de mechanismen van de taal zelf.

Object Oriented Programming (OOP) is een programmeerstijl die het gedrag van de echte wereld vastlegt op zo'n manier dat de details van de implementatie ervan verborgen zijn.

Een object is een soort afzonderlijke entiteit die zich onderscheidt van andere entiteiten vanwege zijn eigenschappen, gedrag en interactie met andere objecten van de toepassing.

Er zijn twee belangrijke verschillen tussen OOP en procedureel programmeren:

1. In OOP selecteert de programmeur eerst klassen uit de beschrijving van het onderwerpgebied, vervolgens wordt een objectmodel gebouwd om het probleem op te lossen, en pas daarna gaat hij verder met de analyse van hun methoden en eigenschappen.

2. Methoden en eigenschappen zijn gekoppeld aan een klasse die bedoeld is om de overeenkomstige bewerkingen uit te voeren.

Gedrag is een kenmerk van hoe het ene object andere objecten beïnvloedt of zichzelf onder hun invloed verandert. Gedrag beïnvloedt hoe de toestanden van een object veranderen.

Objectgeoriënteerde programmeertechnologie is gebaseerd op drie pijlers: inkapseling, overerving en polymorfisme.

Typen is een manier om te waken tegen, of op zijn minst te controleren, het gebruik van objecten van de ene klasse in plaats van de andere.

Parallellisme is een eigenschap die actieve objecten onderscheidt van passieve objecten.

Persistentie is het vermogen van een object om in de tijd te bestaan, het proces te ervaren dat het heeft voortgebracht, en (of) in de ruimte, vanuit zijn oorspronkelijke adresruimte.

1.2 Conceptobject

1. een methode is een functie of procedure die mogelijke acties met een object implementeert;

2. Een gebeurtenis is een middel tot interactie van objecten met elkaar. Objecten genereren gespecificeerde gebeurtenissen en ondernemen acties in reactie op gespecificeerde gebeurtenissen. Gebeurtenissen zijn analoog aan berichten die objecten ontvangen en verzenden;

3. staat - elk object bevindt zich altijd in een bepaalde staat, die wordt gekenmerkt door een reeks objecteigenschappen. Onder invloed van gebeurtenissen gaat het object in andere toestanden. In dit geval kan het object zelf gebeurtenissen genereren wanneer het overgaat naar een andere toestand;

4. eigenschap - een teken, een aparte kwaliteit (parameter) van een object.

De eigenschappen kunnen bijvoorbeeld de grootte van het object, de titel, de naam zijn. De set eigenschappen van een object bepaalt de staat ervan. Eigenschappen zijn meestal een reeks variabelen en constanten die waarden opslaan die de parameters van een object definiëren.

Opgemerkt moet worden dat naast fysieke objecten ook abstracte objecten kunnen bestaan, typische vertegenwoordigers hiervan zijn getallen. Een object is dus elke fysieke of abstracte duidelijk identificeerbare entiteit van het domein.

Objecten worden gekenmerkt door attributen. De attributen van een auto zijn bijvoorbeeld maximale snelheid, motorvermogen, carrosseriekleur, etc. De attributen van een versterker zijn frequentiebereik, uitgangsvermogen, totale harmonische vervorming, geluidsniveau, etc.

Naast attributen hebben objecten enige functionaliteit die OOP operaties, functies of methoden aanroept. Zo kan een auto rijden, een schip varen, een computer berekeningen uitvoeren.

Een object kapselt dus attributen en methoden in en verbergt de implementatie ervan voor andere objecten die ermee interageren en de functionaliteit ervan gebruiken.

De objectgeoriënteerde benadering is gebaseerd op het systematisch gebruik van modellen voor taalonafhankelijke ontwikkeling van een softwaresysteem, gebaseerd op zijn pragmatiek.

In de objectgeoriënteerde benadering worden deze objecten en concepten vervangen door hun modellen, d.w.z. bepaalde formele constructies die ze vertegenwoordigen in het softwaresysteem.

Figuur 1.2.1 Semantiek.

Een objectgeoriënteerde benadering helpt dus om complexe problemen aan te pakken zoals:

· Vermindering van softwarecomplexiteit;

· Betrouwbaarheid van software verhogen;

· Zorgen voor de mogelijkheid om individuele softwarecomponenten te wijzigen zonder de rest van de componenten te wijzigen;

· Zorgen voor de mogelijkheid van hergebruik van individuele softwarecomponenten.

1.3 Implementatiemiddelen van objectgeoriënteerde programmeertechnologie

Elke programmering wordt uitgevoerd volgens een van de vier principes:

2. CONSTRUCTIE VAN HET OBJECTMODEL VAN HET ONDERWERP "ORGANISATIE VAN SPORTCLUBPROCESSEN" MET GEBRUIK VAN DE UML-MODELTAAL

2.1 De UML begrijpen

2.1.1 Een korte geschiedenis van de UML

2.1.2 UML-taal

2.1.3 UML-vocabulaire

Het model wordt weergegeven in de vorm van entiteiten en relaties daartussen, die in diagrammen worden weergegeven.

Relaties tonen verschillende relaties tussen entiteiten. De UML definieert de volgende soorten relaties:

Diagrammen. De UML biedt de volgende diagrammen:

2.1.4 Modelbesturingsstructuur

UML biedt.

· Een hiërarchische beschrijving van een complex systeem door pakketten toe te wijzen;

· Formalisatie van functionele vereisten voor het systeem met behulp van het apparaat van use cases;

• De vereisten voor het systeem uitwerken door diagrammen van activiteiten en scenario's te bouwen;

· Toewijzing van dataklassen en opbouw van een conceptueel datamodel in de vorm van klassendiagrammen;

· Toewijzing van klassen die de gebruikersinterface beschrijven, en het creëren van een schermnavigatieschema;

· Een beschrijving van de interactieprocessen van objecten bij het uitvoeren van systeemfuncties;

· Beschrijving van het gedrag van objecten in de vorm van diagrammen van activiteiten en toestanden;

· Beschrijving van softwarecomponenten en hun interactie via interfaces;

· Een beschrijving van de fysieke architectuur van het systeem.

2.2 Beschrijving van de werking van het vakgebied "Organisatie van het werk van een sportclub"

Afhankelijk van de aard van de verbindingen tussen de bedrijfsonderdelen worden de volgende soorten organisatiestructuren onderscheiden: lineair, functioneel, lineair-functioneel en matrix.

Deze sportvereniging hanteert een lineaire bestuursstructuur.

De sportvereniging lost de volgende taken op:

· Betrokkenheid van jongeren en hun gezinnen bij systematische lichamelijke opvoeding en sport;

· Opvoeding van fysieke en morele wilskwaliteiten, verbetering van de gezondheid en vermindering van morbiditeit, verhoging van het niveau van professionele paraatheid, sociale activiteit van jongeren;

In de fase van het analyseren van het domein en het ontwerpen van de structuur van de applicatie, is het noodzakelijk om een UML-klassendiagram te bouwen.