Objectgeoriënteerde modelleertaal UML. Objectgeoriënteerde modellering

Het concept van een objectgeoriënteerde benadering (OOP) OOP OOP is een benadering waarbij gebruik wordt gemaakt van objectdecompositie In OOP wordt de statische structuur van een systeem beschreven in termen van objecten en verbindingen daartussen. De dynamische structuur van een object wordt beschreven in termen van berichtenuitwisseling tussen objecten.

Object Een object is een tastbare realiteit met welomschreven gedrag. Een object heeft staat, gedrag, persoonlijkheid De structuur en het gedrag van vergelijkbare objecten definiëren een gemeenschappelijke klasse voor hen => Object = instantie van een klasse Object = klasse-instantie "> Object = klasse-instantie"> Object = klasse-instantie "title =" (! LANG: Object Object is een tastbare realiteit met een goed gedefinieerd gedrag. Een object heeft een staat, gedrag, persoonlijkheid. them class = > Object = instantie van klasse"> title="Object Een object is een tastbare realiteit met welomschreven gedrag. Een object heeft staat, gedrag, persoonlijkheid De structuur en het gedrag van vergelijkbare objecten definiëren een gemeenschappelijke klasse voor hen => Object = instantie van een klasse"> !}

Objecteigenschappen Objectstatus - een lijst van alle mogelijke (statische) eigenschappen van een object en de huidige (dynamische) waarden van elk van deze eigenschappen Gedrag - het effect van een object op een ander object en vice versa, evenals een relatief verandering in de toestand van deze objecten en verzending van berichten tussen hen Individualiteit is een eigenschap van een object dat het onderscheidt van andere objecten

Verschil tussen klasse en object Veel objecten met vergelijkbare eigenschappen (toestand, gedrag, persoonlijkheid) = KLASSE => Elk object = klasse-instantie Elk object = klasse-instantie "> Elk object = klasse-instantie"> Elk object = klasse-instantie "title =" (! LANG: Verschil tussen klasse en object Veel objecten met vergelijkbare eigenschappen (status, gedrag, persoonlijkheid) = CLASS => Elk object = klasse instantie"> title="Verschil tussen klasse en object Veel objecten met vergelijkbare eigenschappen (toestand, gedrag, persoonlijkheid) = KLASSE => Elk object = klasse-instantie"> !}

Klassenhiërarchie: Bovenliggende klasse heeft phi "title =" (! LANG: OOP-principes. Overerving Overerving is het principe volgens welk kennis van een meer algemene categorie mag worden toegepast op een meer besloten categorie. Overervingsklassehiërarchie Overerving -> klasse hiërarchie: bovenliggende klasse heeft phi" class="link_thumb"> 7 !} OOP-principes. Overerving Overerving - het principe volgens welk kennis over een meer algemene categorie mag worden toegepast op een meer besloten categorie Overervingsklassenhiërarchie Overerving -> klassenhiërarchie: De bovenliggende klasse heeft een vaste set eigenschappen => de afgeleide klasse bevat dezelfde set eigenschappen + extra eigenschappen die uniek zijn klassenhiërarchie: de bovenliggende klasse heeft phi "> klassenhiërarchie: de bovenliggende klasse heeft een vaste reeks eigenschappen => een daarvan afgeleide klasse bevat dezelfde reeks eigenschappen + aanvullende eigenschappen die de uniciteit ervan kenmerken"> klassenhiërarchie: de bovenliggende klasse has phi "title =" ( ! LANG: OOP Principes Overerving Overerving is het principe waarbij kennis van een meer algemene categorie mag worden toegepast op een meer specifieke categorie Overervingsklassenhiërarchie Overerving -> klassenhiërarchie: De bovenliggende klasse heeft phi"> title="OOP-principes. Overerving Overerving is het principe volgens welke kennis van een meer algemene categorie mag worden toegepast op een meer besloten categorie Overervingsklassenhiërarchie Overerving -> klassenhiërarchie: De bovenliggende klasse heeft phi"> !}

OOP-principes. Inkapseling Inkapseling is het verbergen van individuele details van de interne structuur van klassen voor objecten of gebruikers daarbuiten. Inkapseling komt van het verdelen van modules in 2 delen: interface en implementatie.

OOP-principes. Polymorfisme Polymorfisme (Grieks poly - veel, morfos - vorm) is het eigendom van sommige objecten om verschillende uiterlijke vormen aan te nemen, afhankelijk van de omstandigheden. Acties die worden uitgevoerd door methoden met dezelfde naam kunnen verschillen, afhankelijk van tot welke van de klassen deze of gene methode behoort.

Andere OOP-principes Typen is een beperking die wordt opgelegd aan een klasse van objecten die de uitwisselbaarheid van verschillende klassen verhindert (of ernstig beperkt). Parallellisme is de eigenschap van objecten om zich in een actieve of passieve toestand te bevinden en om onderscheid te maken tussen actieve en passieve toestanden. Stabiliteit - de eigenschap van een object om in de tijd te bestaan ​​(ongeacht het proces dat het object heeft gegenereerd) en/of ruimte (wanneer het object wordt verplaatst uit de ruimte waarin het is gemaakt).

De universele modelleertaal UML. Prehistorie Begin jaren 90. 20e eeuw - de creatie van nieuwe objectgeoriënteerde programmeertalen (Smalltalk, C++, Java) Er is een enorm aantal methoden ontwikkeld voor het ontwerpen van objectgeoriënteerde software. Het resultaat is de ontwikkeling van UML, om te combineren de voordelen van verschillende benaderingen in één fabrikantonafhankelijke modelleertaal.

Universal Modeling Language UML UML - Unified Modeling Language is een uniforme modelleringstaal die is ontworpen om objectgeoriënteerde systemen en bedrijfsprocessen te visualiseren en documenteren, met de nadruk op hun latere implementatie in de vorm van software.

Universal Modeling Language UML-auteurs - G. Booch, Jim Rumbaugh (of D. Rumbaugh), I. Jacobson. De eerste versie van de taal verscheen in 1996. Op dit moment zijn alle kwesties van verdere ontwikkeling van de UML geconcentreerd in het kader van het OMG-consortium. In 2004 - UML 2.0.

UML-diagrammen UML omvat 8 soorten diagrammen: 1) use case-diagrammen; 2) klassendiagrammen; 3) toestandsdiagrammen; 4) activiteitendiagrammen; 5) diagrammen van samenwerking; 6) sequentiediagrammen; 7) componentendiagrammen; 8) inzetdiagrammen. Interactiediagrammen Implementatiediagrammen

Sommige softwareproducten (UML-tools) IBM Rational Software Architect (IBM) IBM Rational Rose (IBM) ARIS UML Designer (IDS Sheer) Enterprise Architect (SPARX Software) Altova Umodel KUml, Dia, PowerDesigner Etc. Meer details:

Opdracht Bestudeer zelf het artikel "UML basics: An Introduction to the Unified Modeling Language": /library/769.html?S_TACT=105AGX15&S_ CMP = EDU

Vertaling

1 Laboratoriumwerk 4 "Methodologie van objectgeoriënteerd modelleren" 1. Doel van het werk: Vertrouwd raken met de basiselementen van de definitie, representatie, ontwerp en modellering van softwaresystemen met behulp van de UML-taal. 2. Methodische instructies Het laboratoriumwerk is gericht op het vertrouwd maken met de basiselementen van definitie, representatie, ontwerp en modellering van softwaresystemen met behulp van de UML-taal, en het verwerven van vaardigheden in het gebruik van deze elementen om objectgeoriënteerde IS-modellen te bouwen op basis van vereisten. Eisen aan de resultaten van de laboratoriumpraktijk: het systeemmodel dient te bevatten: een schema van use cases; interactiediagrammen voor elke use case; een klassendiagram waarmee u alle beschreven IS-functionaliteit kunt implementeren; gecombineerd componentdiagram en plaatsing voor klassen om stereotypen aan te geven; afhankelijk van de opdracht moet het lay-outdiagram de locatie van de componenten in de gedistribueerde applicatie of de relatie tussen de embedded processor en apparaten weergeven. 3. Algemene informatie over objectmodellering van IS Er zijn veel technologieën en hulpmiddelen die kunnen worden gebruikt om in zekere zin een optimaal IS-ontwerp te implementeren, vanaf de analysefase tot het maken van de programmacode van het systeem. In de meeste gevallen stellen deze technologieën zeer strenge eisen aan het ontwikkelingsproces en de gebruikte middelen, en pogingen om ze te transformeren voor specifieke projecten zijn niet succesvol. Deze technologieën worden vertegenwoordigd door bovenste CASE-tools of CASE-tools voor de volledige levenscyclus. Ze laten niet toe om activiteiten op het niveau van individuele elementen van het project te optimaliseren, en als gevolg daarvan zijn veel ontwikkelaars overgestapt op de zogenaamde lagere CASE-tools. Ze kregen echter te maken met een nieuw probleem, het probleem van het organiseren van interactie tussen de verschillende teams die het project uitvoeren. De Unified Modeling Language (UML) is de wisselwerking tussen deze benaderingen. Er zijn voldoende tools die de levenscyclus van informatiesystemen die UML gebruiken ondersteunen, en tegelijkertijd is UML flexibel genoeg om de specifieke activiteiten van verschillende ontwikkelingsteams aan te passen en te ondersteunen.

2 De oprichting van de UML begon in oktober 1994, toen Jim Rambeau en Grady Booch van de Rational Software Corporation begonnen te werken aan het combineren van hun OMT- en Booch-methoden. Momenteel omvat het consortium van gebruikers van UML Partners vertegenwoordigers van reuzen van informatietechnologie zoals Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology. UML is een objectgeoriënteerde modelleertaal met de volgende hoofdkenmerken: het is een visuele modelleertaal die de ontwikkeling van representatieve modellen mogelijk maakt voor het organiseren van interactie tussen een klant en een IS-ontwikkelaar, verschillende groepen IS-ontwikkelaars; bevat mechanismen voor het uitbreiden en specialiseren van de basisconcepten van de taal. UML is de standaardnotatie voor visuele modelleringssoftwaresystemen die in de herfst van 1997 door de Object Managing Group (OMG) is aangenomen en wordt nu ondersteund door veel objectgeoriënteerde CASE-producten. De UML bevat een interne set modelleringstools die nu in veel modelleringstechnieken en -tools worden toegepast. Deze concepten zijn nodig in de meeste toepassingen, hoewel niet elk concept nodig is in elk onderdeel van elke toepassing. De gebruikers van de taal krijgen de volgende mogelijkheden: om modellen te bouwen op basis van kerneltools, zonder gebruik te maken van uitbreidingsmechanismen voor de meeste typische toepassingen; voeg zo nodig nieuwe elementen en conventies toe als ze geen deel uitmaken van de kern, of specialiseer componenten, conventies (notatie) en domeinspecifieke beperkingen. UML-taal Afb. 1. Een geïntegreerd model van een complex systeem in de notatie van de UML-taal De UML-standaard biedt de volgende set diagrammen voor modellering: use case-diagrammen voor het modelleren van bedrijfsprocessen van een organisatie en vereisten voor het systeem dat wordt gecreëerd); klassendiagrammen voor het modelleren van de statische structuur van de systeemklassen en de relaties daartussen;

3 gedragsdiagrammen: interactiediagrammen: sequentiediagrammen en samenwerkingsdiagrammen voor het modelleren van de berichtenuitwisseling tussen objecten; statechart-diagrammen voor het modelleren van het gedrag van systeemobjecten tijdens de overgang van de ene toestand naar de andere; activiteitendiagrammen om het gedrag van een systeem in verschillende gebruiksscenario's te modelleren, of om activiteiten te modelleren; implementatiediagrammen: componentdiagrammen voor het modelleren van een hiërarchie van systeemcomponenten (subsystemen); implementatiediagrammen om de fysieke architectuur van een systeem te modelleren. Use Case Diagrams Het concept van een use case werd voor het eerst geïntroduceerd door Ivar Jacobson en kreeg zo'n belang dat de use case nu het belangrijkste element is geworden van projectontwikkeling en planning. Een use case is een opeenvolging van acties (transacties) die door het systeem worden uitgevoerd als reactie op een gebeurtenis die door een externe entiteit (actor) is geactiveerd. Een use case beschrijft een typische interactie tussen een gebruiker en een systeem. In het eenvoudigste geval wordt de use case bepaald door gesprekken met de gebruiker over de functionaliteit die hij wil implementeren. In de UML-taal wordt de use case als volgt weergegeven: Fig. 2. Use Case Een actor is de rol die de gebruiker speelt in relatie tot het systeem. Acteurs vertegenwoordigen rollen, geen specifieke mensen of functietitels. Hoewel ze in use-case diagrammen worden afgebeeld als gestileerde menselijke figuren, kan de actor ook een extern systeem zijn dat informatie uit dat systeem nodig heeft. Laat tekens in het diagram alleen zien als ze echt een aantal use-cases nodig hebben. In de UML-taal worden de karakters weergegeven in de vorm van figuren: Fig. 3. Acteur (acteur) Personages zijn onderverdeeld in drie hoofdtypen:

4 gebruikers; systemen; andere systemen die hiermee in wisselwerking staan; tijd. Tijd wordt een actor als de lancering van gebeurtenissen in het systeem ervan afhangt. Relaties tussen use cases en actoren In UML ondersteunen use case-diagrammen verschillende soorten relaties tussen diagramelementen. Dit zijn communicatie, opnemen, uitbreiden en generaliseren. Een communicatielink is de link tussen een use case en een actor. In de UML worden communicatieverbindingen weergegeven met een unidirectionele associatie (ononderbroken lijn). Afb. 4. Voorbeeld van een communicatielink Een inclusielink wordt gebruikt in situaties waarin er een stuk systeemgedrag is dat in meer dan één use case wordt herhaald. Deze koppelingen worden vaak gebruikt om herbruikbare functionaliteit te modelleren. Een extensierelatie wordt gebruikt om veranderingen in het normale gedrag van een systeem te beschrijven. Het staat een use-case alleen toe om de functionaliteit van een ander te gebruiken wanneer dat nodig is. Afb. 5. Voorbeeld van een inclusie- en uitbreidingsrelatie Met behulp van een generalisatierelatie wordt aangetoond dat verschillende actoren overeenkomsten hebben.

5 Afb. 6. Voorbeeld van een generalisatierelatie Interactiediagrammen Interactiediagrammen beschrijven het gedrag van op elkaar inwerkende groepen objecten. Gewoonlijk dekt een interactiediagram het gedrag van objecten binnen slechts één use-case. Zo'n diagram toont een aantal objecten en de berichten die ze met elkaar uitwisselen. Een bericht is een middel waarmee het afzenderobject het ontvangende object verzoekt om een ​​van zijn bewerkingen uit te voeren. Een informatief bericht is een bericht dat een ontvangend object enige informatie geeft om de status bij te werken. Een vragend bericht is een bericht waarin om informatie over het ontvangende object wordt gevraagd. Een imperatief bericht is een bericht dat de ontvanger vraagt ​​om actie te ondernemen. Er zijn twee soorten interactiediagrammen: sequentiediagrammen en samenwerkingsdiagrammen. Sequentiediagrammen Een sequentiediagram geeft de stroom van gebeurtenissen weer die plaatsvinden binnen een use case. Alle acteurs staan ​​bovenaan het diagram. Pijlen komen overeen met berichten die worden verzonden tussen de actor en het object, of tussen objecten om de vereiste functies uit te voeren. In een sequentiediagram wordt een object getekend als een rechthoek met een gestippelde verticale lijn naar beneden getrokken. Deze lijn wordt de levenslijn van het object genoemd. Het is een fragment van de levenscyclus van een object in het proces van interactie. Elk bericht wordt weergegeven als een pijl tussen de levenslijnen van twee objecten. Berichten verschijnen in de volgorde die op de pagina wordt weergegeven van boven naar beneden. Elk bericht wordt getagd met ten minste de berichtnaam. Optioneel kunt u ook argumenten en wat controle-informatie toevoegen. U kunt een zelfdelegatiebericht weergeven dat een object naar zichzelf verzendt, waarbij de berichtpijl naar dezelfde levenslijn wijst.

6 Afb. 7. Voorbeeld sequentiediagram Samenwerkingsdiagram Samenwerkingsdiagrammen tonen de stroom van gebeurtenissen door een specifiek gebruiksscenario, geordend op tijd, en samenwerkingsdiagrammen richten zich meer op de relaties tussen objecten. Een samenwerkingsdiagram vertegenwoordigt alle informatie die een sequentiediagram bevat, maar een coöperatief diagram beschrijft de stroom van gebeurtenissen anders. Het maakt het gemakkelijker om de relaties tussen objecten te begrijpen, maar het is moeilijker om de volgorde van gebeurtenissen te begrijpen. In een coöperatief diagram, zoals in een sequentiediagram, geven pijlen de berichten aan die binnen een bepaalde use case zijn uitgewisseld. Hun tijdsvolgorde wordt aangegeven door de nummering van de berichten.

7 Afb. 8. Voorbeeld van een samenwerkingsdiagram Klassendiagrammen Algemene informatie Een klassendiagram definieert de soorten klassen in het systeem en de verschillende soorten statische verbindingen die daartussen bestaan. Klassendiagrammen geven ook klasseattributen, klassebewerkingen en beperkingen weer die van toepassing zijn op relaties tussen klassen. Een UML-klassendiagram is een grafiek waarvan de knooppunten de elementen zijn van de statische structuur van het project (klassen, interfaces) en de bogen de relaties tussen de knooppunten (associaties, overerving, afhankelijkheden). De volgende elementen zijn afgebeeld in het klassendiagram: Class Package (pakket) - een set modelelementen die logisch aan elkaar gerelateerd zijn; Klasse - een beschrijving van de algemene eigenschappen van een groep vergelijkbare objecten; Interface is een abstracte klasse die een reeks bewerkingen definieert die een object van een willekeurige klasse die aan een bepaalde interface is gekoppeld, aan andere objecten levert. Een klasse is een groep entiteiten (objecten) die vergelijkbare eigenschappen hebben, namelijk gegevens en gedrag. Een individuele vertegenwoordiger van een klasse wordt een klasse-object of gewoon een object genoemd. Het gedrag van een object in UML wordt opgevat als alle regels voor de interactie van een object met de buitenwereld en met de gegevens van het object zelf. In de diagrammen wordt de klasse weergegeven als een rechthoek met een ononderbroken rand, verdeeld door horizontale lijnen in 3 secties: De bovenste sectie (naamsectie) bevat de klassenaam en andere algemene eigenschappen (met name het stereotype). Het middelste gedeelte bevat een lijst met attributen.Het onderste gedeelte bevat een lijst met klassebewerkingen die het gedrag weergeven (acties die door de klas worden uitgevoerd).

8 Een van de attribuut- en bewerkingssecties wordt mogelijk niet weergegeven (evenals beide). Voor een ontbrekende sectie hoeft u geen scheidslijn te tekenen en op de een of andere manier de aanwezigheid of afwezigheid van elementen erin aan te geven. Aanvullende secties, zoals Uitzonderingen, kunnen naar goeddunken van een bepaalde implementatie worden geïntroduceerd. Klassenstereotypen Afb. 9. Voorbeeld van een klassendiagram Klassenstereotypen zijn een mechanisme waarmee u klassen kunt categoriseren. De UML definieert drie hoofdklasse stereotypen: Boundary; Entiteit Controle. Grensklassen Grensklassen zijn klassen die zich op de grens van het systeem en de gehele omgeving bevinden. Dit zijn displays, rapporten, interfaces met hardware (zoals printers of scanners) en interfaces met andere systemen. Om de grensklassen te vinden, moet u de use case-diagrammen onderzoeken. Voor elke interactie tussen een actor en een use case moet er minstens één grensklasse zijn. Het is deze klasse waarmee de acteur met het systeem kan communiceren. Entiteitsklassen Entiteitsklassen bevatten opgeslagen informatie. Ze zijn van het grootste belang voor de gebruiker en daarom gebruiken ze vaak termen uit het onderwerpgebied in hun naam. Gewoonlijk wordt voor elke entiteitsklasse een tabel in de database gemaakt. Controle klassen

9 Controleklassen zijn verantwoordelijk voor de coördinatie van de acties van andere klassen. Doorgaans heeft elke use-case één besturingsklasse die de volgorde van gebeurtenissen voor die use-case bestuurt. De controlerende klasse is verantwoordelijk voor de coördinatie, maar heeft zelf geen functionaliteit, omdat de andere klassen hem niet veel berichten sturen. In plaats daarvan stuurt hij zelf veel berichten. De managerklasse delegeert eenvoudigweg de verantwoordelijkheid aan andere klassen, om deze reden wordt het vaak de managerklasse genoemd. Er kunnen andere besturingsklassen in het systeem zijn die gemeenschappelijk zijn voor meerdere use-cases. Er kan bijvoorbeeld een SecurityManager-klasse zijn die verantwoordelijk is voor het bewaken van beveiligingsgebeurtenissen. De klasse TransactionManager is verantwoordelijk voor het coördineren van berichten met betrekking tot databasetransacties. Er kunnen andere managers zijn die zich bezighouden met andere elementen van de werking van het systeem, zoals het delen van bronnen, gedistribueerde gegevensverwerking of foutafhandeling. Naast de hierboven genoemde stereotypen, kunt u uw eigen stereotypen maken. Attributen Een attribuut is een stukje informatie dat bij een klasse hoort. Attributen slaan ingekapselde klassegegevens op. Omdat de attributen zich in de klasse bevinden, zijn ze verborgen voor andere klassen. Daarom moet u mogelijk specificeren welke klassen attributen mogen lezen en wijzigen. Deze eigenschap wordt attribuutzichtbaarheid genoemd. Een attribuut kan vier mogelijke waarden hebben voor deze parameter: Public. Deze zichtbaarheidswaarde gaat ervan uit dat het attribuut zichtbaar is voor alle andere klassen. Elke klasse kan de waarde van het attribuut bekijken of wijzigen. In UML-notatie wordt het gemeenschappelijke attribuut voorafgegaan door een "+"-teken. Privé (gesloten, geheim). Het bijbehorende attribuut is voor geen enkele andere klasse zichtbaar. Een privé-attribuut wordt aangeduid met een teken in overeenstemming met de UML-notatie. beschermd Een dergelijk attribuut is alleen beschikbaar voor de klasse zelf en zijn nakomelingen. De UML-notatie voor een beschermd attribuut is het "#"-teken. Pakket of implementatie Gaat ervan uit dat dit attribuut generiek is, maar alleen binnen zijn pakket. Dit type zichtbaarheid wordt niet aangegeven door een speciaal pictogram. Over het algemeen wordt aanbevolen om attributen privé of beschermd te maken. Dit zorgt voor een betere controle over het attribuut zelf en de code. Met behulp van geslotenheid of beveiliging is het mogelijk om een ​​situatie te vermijden waarin de waarde van een attribuut wordt gewijzigd door alle klassen van het systeem. In plaats daarvan wordt de logica voor het wijzigen van een attribuut verpakt in dezelfde klasse als het attribuut zelf. De zichtbaarheidsparameters die u instelt, zijn van invloed op de gegenereerde code. Operations Operations implementeren klassegerelateerd gedrag. Een bewerking bestaat uit drie delen: naam, parameters en retourtype. Parameters zijn de argumenten die worden ontvangen door de bewerking "invoer". Het retourtype verwijst naar het resultaat van de actie van de bewerking.

10 In een klassendiagram kunt u zowel de namen van de bewerkingen als de namen van de bewerkingen weergeven, samen met hun parameters en retourtype. Om de werklast van het diagram te verminderen, is het handig om alleen de namen van bewerkingen op sommige ervan te tonen, en op andere hun volledige handtekening. In de UML hebben bewerkingen de volgende notatie: Bewerkingsnaam (Argument: Argumentgegevenstype, Argument2: Argumentgegevenstype, ...): Retourwaardetype Er zijn vier verschillende soorten bewerkingen waarmee u rekening moet houden: Implementatiebewerkingen; Controle operaties; Toegangshandelingen; Hulpoperaties. Implementatie operaties Implementor operaties implementeren een aantal zakelijke functies. Dergelijke bewerkingen kunnen worden gevonden door interactiediagrammen te onderzoeken. Dit type diagram is gericht op bedrijfsfuncties en elk diagrambericht kan hoogstwaarschijnlijk worden geassocieerd met een implementatiebewerking. Elke implementatiestap moet gemakkelijk herleidbaar zijn naar de bijbehorende behoefte. Dit wordt bereikt in verschillende stadia van de simulatie. De activiteit wordt afgeleid van het bericht in het interactiediagram, de berichten worden afgeleid van de gedetailleerde beschrijving van de gebeurtenisstroom die wordt gegenereerd op basis van de use case en de laatste op basis van vereisten. De mogelijkheid om deze hele keten te traceren zorgt ervoor dat elke vereiste in code wordt geïmplementeerd en dat elk stukje code een vereiste implementeert. Managerbewerkingen Managerbewerkingen regelen het maken en vernietigen van objecten. Class constructors en destructors vallen in deze categorie. Access Operations Attributen zijn meestal privé of beschermd. Andere klassen moeten echter soms hun waarden bekijken of wijzigen. Hiervoor zijn toegangshandelingen. Deze benadering maakt het mogelijk om attributen veilig in een klasse in te kapselen, ze te beschermen tegen andere klassen, maar biedt toch gecontroleerde toegang tot hen. Het is een standaardpraktijk om voor elk klasseattribuut Get- en Set-bewerkingen te maken. Helper-operaties Helper-operaties zijn die operaties van een klasse die het nodig heeft om zijn verantwoordelijkheden te vervullen, maar waar andere klassen niets van hoeven te weten. Dit zijn privé en beschermde operaties van de klasse. Om activiteiten te identificeren, doet u het volgende: 1. Bestudeer volgordediagrammen en samenwerkingsdiagrammen. De meeste berichten in deze diagrammen zijn implementatieactiviteiten. Reflexieve berichten zullen hulpoperaties zijn.

11 2. Overweeg controlehandelingen. Mogelijk moet u constructors en destructors toevoegen. 3. Overweeg toegangsoperaties. Voor elk klassekenmerk waarmee andere klassen moeten werken, moet u Get- en Set-bewerkingen maken. Relaties Een relatie is een semantische relatie tussen klassen. Het stelt een klasse in staat om te leren over de attributen, bewerkingen en relaties van een andere klasse. Met andere woorden, wil de ene klasse een bericht naar een andere kunnen sturen in een sequentiediagram of een coöperatief diagram, dan moet er een relatie tussen beide zijn. Er zijn vier soorten relaties die tussen klassen kunnen worden vastgesteld: associaties, afhankelijkheden, aggregaties en generalisaties. Associaties Een associatie is een semantische relatie tussen klassen. Ze worden in het klassendiagram getekend als een gewone lijn. Rijst. 10. Associatie Associaties kunnen bidirectioneel zijn, zoals in het voorbeeld, of unidirectioneel. In de UML worden bidirectionele associaties getekend als een eenvoudige lijn zonder pijlen of met pijlen aan weerszijden. Op een unidirectionele associatie wordt slechts één pijl afgebeeld die de richting aangeeft. De richting van de associatie kan worden bepaald door sequentiediagrammen en coöperatieve diagrammen te onderzoeken. Als alle berichten naar hen door slechts één klasse worden verzonden en alleen door een andere klasse worden ontvangen, maar niet omgekeerd, vindt er een unidirectionele relatie tussen deze klassen plaats. Als ten minste één bericht in de tegenovergestelde richting wordt verzonden, moet de koppeling bidirectioneel zijn. Verenigingen kunnen reflecterend zijn. Reflexieve associatie gaat ervan uit dat een instantie van een klasse interageert met andere instanties van dezelfde klasse. Afhankelijkheden Afhankelijkheidsrelaties weerspiegelen ook de relatie tussen klassen, maar ze zijn altijd unidirectioneel en laten zien dat de ene klasse afhankelijk is van de definities die in de andere zijn gemaakt. Klasse A gebruikt bijvoorbeeld methoden van klasse B. Wanneer klasse B verandert, is het nodig om de overeenkomstige wijzigingen aan te brengen in klasse A. het begin van deze pijl.

Afb. 12 11. Afhankelijkheid van koppelingen Bij het genereren van code voor deze klassen worden er geen nieuwe attributen aan toegevoegd. De taalspecifieke verklaringen die nodig zijn om de communicatie te ondersteunen, worden echter gegenereerd. Aggregaties Aggregaties zijn een strakkere vorm van associatie. Aggregatie is de verbinding tussen het geheel en zijn deel. U kunt bijvoorbeeld een klasse voor auto hebben, evenals klassen voor motor, banden en klassen voor andere delen van de auto. Als resultaat zal een object van de klasse Auto bestaan ​​uit een object van de klasse Motor, vier objecten van Banden, enz. Aggregaties worden gevisualiseerd als een lijn met een ruit voor een klasse die een geheel is: Fig. 11. Relatie-aggregatie Naast eenvoudige aggregatie introduceert de UML een sterkere vorm van aggregatie, compositie genaamd. Volgens de compositie kan een object-deel slechts tot één geheel behoren, en bovendien valt de levenscyclus van delen in de regel samen met de cyclus van het geheel: ze leven en sterven ermee. Elke verwijdering van het geheel strekt zich uit tot zijn delen. Deze trapsgewijze verwijdering wordt vaak gezien als onderdeel van de definitie van aggregatie, maar wordt altijd geïmpliceerd wanneer de veelheid aan rollen gelijk is aan 1..1; als het bijvoorbeeld nodig is om een ​​Klant te verwijderen, dan moet deze verwijdering van toepassing zijn op Orders (en op zijn beurt op Orderregels). Generalisaties (Overerving) Generalisatie (Overerving) is een publiek-private relatie tussen modelelementen. Toon met behulp van generalisatie de overervingsrelatie tussen twee klassen. De meeste objectgeoriënteerde talen ondersteunen het concept van overerving rechtstreeks. Hiermee kan een klasse alle attributen, bewerkingen en relaties van een andere overnemen. Pakketovererving betekent dat in een overgenomen pakket alle entiteiten van het bovenliggende pakket zichtbaar zijn onder hun eigen naam (d.w.z. naamruimten worden samengevoegd). Overerving wordt weergegeven door een ononderbroken lijn die van de afstammelingsklasse naar de voorouderklasse gaat (in OOP-terminologie, van afstammeling naar voorouder, van zoon naar vader, of van subklasse naar superklasse). Een grote holle driehoek wordt getekend vanaf de zijkant van het meer algemene element.

Afb. 13 12. Voorbeeld van een overervingsrelatie Naast overerving heeft elke subklasse zijn eigen unieke kenmerken, bewerkingen en relaties. Multipliciteit Multipliciteit geeft aan hoeveel instanties van een klasse op een bepaald moment via deze relatie interageren met één instantie van een andere klasse. Als u bijvoorbeeld een cursusregistratiesysteem aan een universiteit ontwerpt, kunt u de klassen Cursus en Student definiëren. Daartussen is een verbinding tot stand gebracht: cursussen kunnen studenten hebben en studenten kunnen cursussen hebben. Vragen die beantwoord moeten worden door de multipliciteitsparameter: “Hoeveel cursussen kan een student momenteel volgen? Hoeveel studenten kunnen één vak tegelijk volgen?" Omdat veelvoud het antwoord op beide vragen biedt, zijn de indicatoren aan beide uiteinden van de communicatielijn geïnstalleerd. In het voorbeeld van cursusregistratie hebben we besloten dat één student nul tot vier cursussen kan volgen en één cursus kan worden gevolgd door 0 tot 20 studenten. De UML gebruikt bepaalde notaties om meervoud aan te duiden. Tabel 1 - UML-aanduidingen van meerdere relaties Relatienamen Relaties kunnen worden gekwalificeerd met behulp van relatienamen of rolnamen. De naam van een link is meestal een werkwoord of werkwoorduitdrukking die beschrijft waarom deze nodig is. Er kan bijvoorbeeld een verband bestaan ​​tussen de klasse Persoon en de klasse Bedrijf. In dit verband kunt u de vraag stellen of het object van de klasse Persoon een klant van het bedrijf is, zijn

14 werknemer of eigenaar? Om dit te definiëren, kan de vereniging "werkt" worden genoemd: Rollen Afb. 13. Voorbeeld van relatienamen Rolnamen worden gebruikt in associatie- of aggregatierelaties in plaats van namen om te beschrijven waarom de relatie nodig is. Terugkerend naar het voorbeeld met de klassen Persoon en Bedrijf, fungeert de klasse Persoon als een werknemer van de klasse Bedrijf. Namen van rollen zijn meestal zelfstandige naamwoorden of woordgroepen die daarop zijn gebaseerd, en ze worden weergegeven in het diagram naast de klas die de overeenkomstige rol speelt. Meestal wordt de rolnaam of de relatienaam gebruikt, maar niet beide. Net als relatienamen zijn rolnamen optioneel en worden ze alleen gegeven als het doel van de relatie niet duidelijk is. Een voorbeeld van rollen wordt hieronder gegeven: Pakket. Pakketmechanisme Afb. 14. Voorbeeld van relatierollen In de context van klassendiagrammen is een pakket een vergaarbak voor een reeks klassen en andere pakketten. Het pakket is zijn eigen naamruimte. Rijst. 15. Pakketaanduiding in UML Er zijn geen beperkingen in de UML op de regels waarmee ontwikkelaars klassen in pakketten kunnen of moeten groeperen. Maar er zijn enkele standaardgevallen waarin zo'n groepering geschikt is, bijvoorbeeld nauw op elkaar inwerkende klassen, of het meer algemene geval - het opsplitsen van een systeem in subsystemen. Een pakket bevat fysiek de entiteiten die erin zijn gedefinieerd (er wordt gezegd dat "entiteiten bij het pakket horen"). Dit betekent dat als een pakket wordt vernietigd, de hele inhoud ervan wordt vernietigd. Er zijn verschillende gemeenschappelijke benaderingen voor groepering. Ten eerste kun je ze groeperen op stereotype. In dit geval krijgt u één pakket met entiteitsklassen, één met grensklassen, één met beheerklassen, enz. Deze benadering kan nuttig zijn voor het hosten van het voltooide systeem, aangezien alle grensklassen op de clientcomputers al in hetzelfde pakket zitten.

15 Een andere benadering is om klassen te combineren op basis van hun functionaliteit. Het Security-pakket bevat bijvoorbeeld alle klassen die verantwoordelijk zijn voor het beveiligen van een applicatie. In dit geval kunnen de andere pakketten Employee Maintenance, Reporting en Error Handling heten. Het voordeel van deze aanpak is de herbruikbaarheid. Het pakketmechanisme is van toepassing op elk modelelement, niet alleen op klassen. Als sommige heuristieken niet worden gebruikt om de klassen te groeperen, wordt het willekeurig. Een die meestal wordt gebruikt in UML is afhankelijkheid. Er bestaat een afhankelijkheid tussen twee pakketten als er een afhankelijkheid bestaat tussen twee klassen in de pakketten. Een pakketdiagram is dus een diagram dat klassenpakketten en de afhankelijkheden daartussen bevat. Strikt genomen zijn pakketten en afhankelijkheden elementen van een klassendiagram, dat wil zeggen, een pakketdiagram is een vorm van een klassendiagram. Rijst. 16. Voorbeeld van een pakketdiagram Een afhankelijkheid tussen twee elementen ontstaat wanneer veranderingen in de definitie van het ene element kunnen leiden tot veranderingen in het andere. Wat klassen betreft, kunnen de redenen voor afhankelijkheden heel verschillend zijn: de ene klasse stuurt een bericht naar de andere; een klasse bevat een stuk gegevens uit een andere klasse; de ene klasse gebruikt de andere als een bewerkingsparameter. Als een klasse zijn interface verandert, kan elk bericht dat het verzendt zijn geldigheid verliezen. Pakketten geven geen antwoord op de vraag hoe u het aantal afhankelijkheden in uw systeem kunt verminderen, maar ze helpen deze afhankelijkheden te isoleren, en nadat ze allemaal in zicht zijn, is het enige dat overblijft om te werken aan het verminderen van hun aantal. U kunt pakketdiagrammen zien als het belangrijkste hulpmiddel voor het beheren van de algehele structuur van een systeem. Pakketten zijn een essentieel hulpmiddel voor grote projecten. Ze moeten worden gebruikt in gevallen waarin een klassendiagram dat het hele systeem bestrijkt en dat op een enkel vel A4-papier is geplaatst, onleesbaar wordt. Toestandsdiagrammen Toestandsdiagrammen definiëren alle mogelijke toestanden waarin een bepaald object kan zijn, evenals het proces van het veranderen van de toestanden van een object als gevolg van het optreden van bepaalde gebeurtenissen. Er zijn veel vormen van toestandsdiagrammen met een iets andere semantiek. Er zijn twee speciale toestanden in het diagram: start en stop. De begintoestand wordt gemarkeerd met een zwarte stip, deze komt overeen met de toestand van het object,

16 toen het net werd gemaakt. De eindtoestand wordt aangegeven door een zwarte stip in een witte cirkel, deze komt overeen met de toestand van het object net voor de vernietiging. Er kan één en slechts één begintoestand in een toestandsdiagram zijn. Tegelijkertijd kunnen er zoveel eindtoestanden zijn als u nodig heeft, of helemaal geen. Wanneer een object zich in een bepaalde staat bevindt, kunnen verschillende processen worden uitgevoerd. Processen die plaatsvinden wanneer een object zich in een bepaalde staat bevindt, worden acties genoemd. Er zijn vijf soorten gegevens die u aan een status kunt koppelen: activiteit, invoeractie, uitvoeractie, gebeurtenis en statusgeschiedenis. Activiteit Een activiteit is het gedrag dat een object implementeert terwijl het zich in een bepaalde staat bevindt. Activiteit is onderbroken gedrag. Het kan worden uitgevoerd totdat het is voltooid, terwijl het object zich in deze staat bevindt, of het kan worden onderbroken door de overgang van het object naar een andere staat. De activiteit wordt afgebeeld binnen de staat zelf, het moet worden voorafgegaan door het woord do en een dubbele punt. Invoeractie Een invoeractie is het gedrag dat wordt uitgevoerd wanneer een object een bepaalde status binnengaat. Deze actie wordt niet uitgevoerd nadat het object deze status heeft bereikt, maar eerder als onderdeel van deze overgang. In tegenstelling tot activiteit wordt invoeractie als ononderbroken beschouwd. De invoeractie wordt ook weergegeven binnen de staat, voorafgegaan door het woord invoer en een dubbele punt. Exit-actie De exit-actie is vergelijkbaar met de invoer. Het wordt echter uitgevoerd als een integraal onderdeel van het proces om uit deze toestand te komen. Het maakt deel uit van het transitieproces. Net als de invoeractie is de uitvoeractie niet-onderbreekbaar. De exit-actie wordt weergegeven binnen de staat, voorafgegaan door het woord exit en een dubbele punt. Het gedrag van een object tijdens een activiteit, tijdens invoer- en uitvoeracties, kan het verzenden van een gebeurtenis naar een ander object omvatten. In dit geval wordt de beschrijving van de activiteit, invoeractie of uitvoeractie voorafgegaan door een "^"-teken. De corresponderende regel in het diagram ziet eruit als Do: ^ Target.Event (Argumenten) Hier is Target het object dat de gebeurtenis ontvangt, Event is het bericht dat moet worden verzonden en Argumenten zijn de parameters van het bericht dat moet worden verzonden. Een activiteit kan ook worden uitgevoerd als gevolg van het ontvangen van een gebeurtenis door een object. Wanneer een bepaalde gebeurtenis wordt ontvangen, wordt een bepaalde activiteit uitgevoerd. Overgang verwijst naar het verplaatsen van de ene staat naar de andere. De reeks diagramovergangen laat zien hoe een object tussen zijn toestanden kan bewegen. In het diagram zijn alle overgangen weergegeven als een pijl, beginnend bij de begintoestand en eindigend met de volgende.

17 Overgangen kunnen reflecterend zijn. Het object kan naar dezelfde staat gaan waarin het zich momenteel bevindt. Reflexieve overgangen worden weergegeven als pijlen die beginnen en eindigen in dezelfde toestand. De overgang heeft verschillende specificaties. Deze omvatten gebeurtenissen, argumenten, insluitende voorwaarden, acties en verzonden gebeurtenissen. Gebeurtenissen Een gebeurtenis is de oorzaak van een overgang van de ene toestand naar de andere. De gebeurtenis wordt op het diagram langs de overgangslijn geplaatst. In een diagram kunt u de naam van de bewerking of een gewone zin gebruiken om een ​​gebeurtenis weer te geven. De meeste overgangen moeten gebeurtenissen hebben, aangezien zij degenen zijn die de overgang in de eerste plaats laten plaatsvinden. Er zijn echter ook automatische overgangen die geen gebeurtenissen hebben. In dit geval beweegt het object zelf van de ene toestand naar de andere met een snelheid die de implementatie van invoeracties, activiteiten en uitvoeracties mogelijk maakt. Bewakingscondities Bewakingscondities bepalen wanneer een overgang wel en niet kan plaatsvinden. Anders mislukt de overgang. De omsluitende voorwaarden zijn in het diagram uitgezet langs de overgangslijn achter de naam van het evenement, tussen vierkante haken. Het is optioneel om de bijsluitervoorwaarden op te geven. Als er echter meerdere automatische statusovergangen zijn, moet u elkaar uitsluitende omsluitende voorwaarden hiervoor definiëren. Dit zal de lezer van het diagram helpen begrijpen welk overgangspad automatisch wordt geselecteerd. Actie Een actie, zoals besproken, is niet-onderbreekbaar gedrag dat optreedt als onderdeel van een transitie. Invoer- en uitvoeracties worden weergegeven binnen statussen omdat ze bepalen wat er gebeurt wanneer een object het binnenkomt of verlaat. De meeste acties worden echter langs de overgangslijn weergegeven, omdat ze niet moeten worden uitgevoerd bij het binnengaan of verlaten van een toestand. De actie wordt getekend langs de overgangslijn achter de gebeurtenisnaam, voorafgegaan door een schuine streep. Een gebeurtenis of actie kan een gedrag binnen een object zijn, of het kan een bericht zijn dat naar een ander object wordt verzonden. Als een gebeurtenis of actie naar een ander object wordt gestuurd, wordt er een ^ voor geplaatst in het diagram.

Afb. 18 17. Voorbeeld Statechart Statecharts hoeven niet voor elke klasse te worden aangemaakt, ze worden alleen gebruikt in complexe gevallen. Als een object van een klasse in verschillende toestanden kan bestaan ​​en zich in elk ervan anders kan gedragen, kan een dergelijk diagram daarvoor nodig zijn. Implementatiediagrammen Een implementatiediagram geeft de fysieke relaties weer tussen de software- en hardwarecomponenten van een systeem. Het is een goed hulpmiddel om de bewegingsroutes van objecten en componenten in een gedistribueerd systeem te tonen. Elk knooppunt in het lay-outdiagram vertegenwoordigt een type computerapparaat, in de meeste gevallen een stuk hardware. Deze hardware kan een eenvoudig apparaat of een sensor zijn, of het kan een mainframe zijn. Een plaatsingsdiagram toont de fysieke locatie van het netwerk en de locatie van de verschillende componenten daarbinnen. Rijst. 19. Voorbeeldlay-outdiagram Een lay-outdiagram wordt gebruikt door de projectmanager, gebruikers, systeemarchitect en operationeel personeel om de fysieke lay-out van een systeem en de locatie van zijn individuele subsystemen te begrijpen.

19 Componentdiagrammen Componentdiagrammen laten zien hoe het model er op de fysieke laag uitziet. Ze verbeelden softwarecomponenten en de relaties daartussen. Tegelijkertijd worden in zo'n diagram twee soorten componenten onderscheiden: uitvoerbare componenten en codebibliotheken. Elke modelklasse (of subsysteem) wordt geconverteerd naar een broncodecomponent. Eenmaal gemaakt, worden ze onmiddellijk toegevoegd aan het componentendiagram. Afhankelijkheden worden weergegeven tussen afzonderlijke componenten, overeenkomend met afhankelijkheden tijdens het compileren of tijdens de uitvoering van het programma. Rijst. 18. Voorbeeld Componentdiagrammen Componentdiagrammen worden gebruikt door de projectdeelnemers die verantwoordelijk zijn voor het samenstellen van het systeem. Het laat zien in welke volgorde de componenten moeten worden gecompileerd en welke uitvoerbare componenten door het systeem worden gemaakt. Dit diagram toont de overeenstemming van de klassen met de geïmplementeerde componenten. Het is nodig waar het genereren van code begint. Component- en implementatiediagrammen combineren In sommige gevallen wilt u misschien een componentdiagram in een implementatiediagram plaatsen. Hiermee kun je laten zien welke componenten draaien en op welke nodes. 4. Procedure voor het uitvoeren van het werk 1. Bestudeer de voorgestelde theoretische stof. 2. Maak een use case diagram voor het geselecteerde informatiesysteem. 3. Implementeer de use case in termen van op elkaar inwerkende objecten en is een set diagrammen: klassendiagrammen die de use case implementeren; interactiediagrammen (sequentiediagrammen of coöperatieve diagrammen) die de interactie van objecten weergeven tijdens de implementatie van een use case. 4. Verdeel klassen in pakketten met behulp van een van de splitsingsmechanismen.

20 5. Bouw een toestandsdiagram voor specifieke objecten van het informatiesysteem. 6. Maak een rapport met alle verkregen niveaus van het model, een beschrijving van functionele blokken, datastromen, opslag en externe objecten.

FEDERAAL AGENTSCHAP VOOR ONDERWIJS KEMEROVSK STAATSUNIVERSITEIT UNESCO Leerstoel nieuwe informatietechnologieën А.М. Gudov, S.Yu. Zavozkin, S.N. Trofimov TECHNOLOGIE SOFTWARE ONTWIKKELING

Methodologische instructies voor het uitvoeren van computationeel en grafisch werk Doel van het werk: Vertrouwd raken met de belangrijkste elementen van de definitie, presentatie, ontwerp en modellering van informatiesystemen met behulp van

BASISINFORMATIE OVER UML-TOOLS UML De Unified Modeling Language (UML) is een taal voor het definiëren, presenteren, ontwerpen en documenteren van softwareprogramma's.

4 Unified Modeling Language (UML)-diagrammen in UML. Klassen en klassenstereotypen. Associatieve lessen. De belangrijkste elementen van interactiediagrammen zijn objecten, berichten.

Lezing 2.1 De UML-taal. Use Case Diagrams 1. UML-inhoud 2. Use Case Diagrams Use Case Actors Relatie 3. Voorbeeld Use Case Diagram Graphic

Federaal Agentschap voor Spoorwegvervoer, afdeling van de federale staatsbegrotingsinstelling voor hoger beroepsonderwijs "Siberian State University"

CASE-technologieën Lezing 5 1 De UML-taal: soorten diagrammen UML 1.5 definieerde twaalf soorten diagrammen, verdeeld in drie groepen: vier soorten diagrammen vertegenwoordigen de statische structuur van de applicatie; vijf vertegenwoordigen

Hoofdstuk 1. De UML begrijpen Het beste hulpmiddel is een groot diagram dat aan de muur is vastgemaakt. Doug Scott 1.1. Doelstellingen en geschiedenis van de creatie van de UML-taal Unified modelleertaal UML (Unified

12_Stappen van IS-ontwerp met UML De belangrijkste soorten UML-diagrammen die worden gebruikt bij het ontwerp van informatiesystemen. Relaties tussen grafieken. UML-ondersteuning voor iteratief ontwerpproces

Samenvatting over de UML-taal Samengesteld door E.A. Leichenok gr.521701 Unified Modeling Language (UML) is een grafische taal voor visualisatie, specificatie, ontwerp

Lab 1 "Use Case Diagram" Inhoudsopgave De UML begrijpen ... 3 Usecase Diagram ... 6 Use Case ... 7 Actoren ... 7 Interfaces ...

Hoorcollege 3, deel 6: Elementen van de grafische notatie van een componentendiagram Annotatie: Het doel van een componentendiagram, zijn belangrijkste elementen. Kenmerken van de fysieke representatie van softwaresystemen. Componenten

Lab-activiteitsdiagram van use cases Doelstelling: Bekendheid met de basisconcepten van UML 2. Bekendheid met de Rational Rose modelleeromgeving 3. Verkennen van de componenten van het model 4. Bouwen

FEDERALE STAATS BUDGETTAIRE ONDERWIJSINSTELLING HOGER ONDERWIJS STAVROPOL STAAT AGRARISCHE UNIVERSITEIT Faculteit Economie Departement Informatiesystemen GOEDGEKEURD

UML-diagrammen Klassendiagram (2) Use case-diagram (22) Activiteitendiagram (35) Interactiediagram (51) Klassendiagram Een klasse is een categorie van dingen die gemeenschappelijke kenmerken hebben en

Diagrammen van interactie van objecten in UML Dit artikel bespreekt in detail het samenwerkingsdiagram en het sequentiediagram

CASE-technologieën Lezing 4 1 UML: prehistorie midden jaren 70 eind jaren 80 De opkomst en bloei van objectgeoriënteerd ontwerpen (OOP) "Method War"-ontwerp midden jaren 90

Hoorcollege 3 deel 2: Relaties en hun grafische weergave op een klassendiagram Trefwoorden: UML, associatie, associatierelatie, generalisatie, generalisatierelatie, aggregatie, compositie, presentatie,

Hoorcollege 3 deel 4 Elementen van de grafische notatie van het diagram Annotatie: Doel van het diagram. Objecten, hun grafische weergave. Levenslijn en focus van het management. Kenmerken van het beeld van de momenten van creatie

ObAn en PRS Lezing 1 pagina 1 van 7 Grafische primitieven van de UML-standaard Paradigma's van de UML-standaard A Taalwoordenboek B Regels over het woordenboek C Mechanismen Taalwoordenboek Entiteiten Gedragsentiteiten Groepering

Lab 2 "Klassediagram" Inhoudsopgave Algemeen concept ... 3 Klasse ... 3 Attributen ... 4 Bediening ... 6 Relaties tussen klassen ... 7 Afhankelijkheidsrelaties ... 7 Associatierelaties ... 8 Relaties

Lab 3 "Status- en activiteitsdiagrammen" Inhoudsopgave STAATSCHEMA ... 3 Algemeen concept ... 3 Toestand ... 4 Overgang ... 6 Samengestelde toestand en substaat ... 8 Voorbeelden van diagrammen

Objectgeoriënteerde analyse en ontwerp Copyright Mukhortov V.V., Nianchuk-Tatarsky N.A., 2001-2004 Copyright LLC "Intex", 2003-2004 Classes Class is een verzameling objecten met een gemeenschappelijke structuur en gedrag Interface

LABORATORIUM 4 ONTWIKKELING VAN EEN FYSIEKE VERTEGENWOORDIGING VAN HET BEDRIJFSPROCES VAN DE SOFTWARE MET GEBRUIK VAN UML 1 Lesdoel Leren hoe u componentdiagrammen en implementatiediagrammen kunt genereren

Federaal Communicatieagentschap Federale Staat Onderwijsbegrotingsinstelling voor Hoger Beroepsonderwijs POVOLGA STAAT UNIVERSITEIT VAN TELECOMMUNICATIE EN INFORMATICA

Doel: Lab 7: Grondbeginselen van de UML Het doel van dit werk is om vertrouwd te raken met de basistechnieken voor het ontwerpen van systemen en processen met behulp van de Universal Modeling Language (UML) Opdracht:

Zolotov Sergey Yurievich Ph.D., universitair hoofddocent van de afdeling Automated Control Systems Designing Information Systems Webinar 3 "De essentie van de objectgeoriënteerde benadering van het ontwerp van informatiesystemen" Webinarplan De betekenis van objectgeoriënteerd

SOFTWARE ENGINEERING CASE IMPLEMENTATIE RADCHENKO G.I., AFDELING SP YURGU ANALYSE VAN HET PRECEDENT Een analytisch klassenmodel is een statische structuur van het systeem, en de implementatie van precedenten laat zien hoe

Voorwoord Inleiding tot UML en UP Wat is UML? Wat is UML? De geboorte van de UML MDA - de toekomst van de UML Waarom "verenigd"? Objecten en UML UML-structuur UML-bouwstenen Gemeenschappelijke UML-mechanismen Architectuur

Lab 4 "Inleiding tot het rationele verenigde proces. Patronen ”Het doel van het werk is om te leren workflowmodellen te ontwikkelen; de plaats van dit model begrijpen bij het bepalen van de functies van het systeem dat wordt ontwikkeld

CASE-TOOLS VOOR ONTWIKKELING VAN INFORMATIEVOORZIENING CAD Lezing 5 "Ontwikkeling van vereisten voor informatieondersteuning" Objectgeoriënteerde benadering van OOP is gebaseerd op de representatie van het domein van het probleem

UML - Universal Modeling Language algemene informatie UML - Universal Modeling Language is een universele modelleertaal die is ontworpen om uniforme beschrijvingen van modellen van systeemobjecten te creëren. Zijn

St. Petersburg State University of Information Technologies, Mechanics and Optics Beschrijving van het onafhankelijke werk van studenten (IWS) "Analyse en ontwerp in UML" FA Novikov, Cand. fysieke-mat.

1 1. Inleiding ... 3 2. Basis ... 4 3. Soorten diagrammen ... 5 3.1 Use-case diagram. 5 3.2 Volgordediagram ... 13 3.3 Klassediagram ... 19

Lezing 2.5 Inzetdiagram. Synchronisatieschema 1 Implementatieschema 2 1.1 Artefact 3 1.2 Knooppunt 3 1.3 Verbindingen 5 1.3.1 Afhankelijkheidsrelaties 6 1.4 Aanbevelingen voor

LABORATORIUMWERKZAAMHEDEN AAN DE CURSUS THEORIE VAN INFORMATIEPROCESSEN EN SYSTEMEN 1. Doel van het werk LABORATORIUMWERK 4 Creatie van interactiediagrammen Verkrijg de vaardigheden om volgordediagrammen te bouwen en samen te werken

SOFTWARE-ENGINEERING OBJECTGERICHTE ANALYSE GI RADCHENKO, AFDELING VAN JV YURGU CASE-CASE ANALYSIS UP's activiteit "Use Case Analysis" omvat: creatie van analyseklassen voor de implementatie van use cases Klassen

Hoofdstuk 5 Basisprincipes van bedrijfsprocesmodellering Voor probleemanalyse in een IS/IT-omgeving is bedrijfsprocesmodellering de meest geschikte methode. Het bedrijfsprocesmodel helpt ons bij het bepalen van

Inhoud Voorwoord 19 Inleiding 21 Educatieve en webbronnen 22 Wie zou dit boek moeten lezen 22 Wat u moet weten 22 Java-voorbeelden 22 Boekstructuur 23 Over de auteur 23 Contact 24 Supplementen

Grafische diagrammen van SObjectizer-agentia Boris Sivko Intervale 2007.11.20 Inhoud 1 Inleiding 1 2 Soorten diagrammen 2 3 Werkingsdiagram 2 3.1 Gebruikte elementen .................... 2 3.1. 1 Agenten ..........................

SOFTWARE-ENGINEERING Analyseklassen GI RADCHENKO, AFDELING VAN SP YURGU OBJECTGERICHT ONTWERP MET UML RADCHENKO G.I., AFDELING VAN SP YURGU 2 NOTATIE VAN UML-OBJECTEN Rechthoek met twee

Relationeel datamodel Basisconcepten van het relationele model Een domein is een verzameling waarden waaruit de waarden van de bijbehorende attributen van een bepaalde relatie worden gehaald. Vanuit een programmeringsoogpunt,

Stromen modelleren 1 Stromen modelleren Deze methodiek (Gane / Sarson-methodologie) is gebaseerd op de constructie van een model van de geanalyseerde IS, ontworpen of feitelijk bestaande. Volgens de methodologie

IP-ONTWIKKELING IP-levenscyclus Definitie 1: De IP-levenscyclus is het proces van het bouwen en ontwikkelen ervan. Definitie 2: De levenscyclus van een IP is de tijdsperiode die begint vanaf het moment dat een beslissing is genomen over de noodzaak

Gegevensmodellering Behandelde problemen met entiteit-relatiemodel: Elementen van entiteit-relatiemodel Entiteit-relatiediagrammen Zwakke entiteiten Behandelde problemen met entiteitssubtypen: voorbeeld ER-diagrammen

Ministerie van Onderwijs van de Republiek Belarus Onderwijsinstelling "Belarusian State University of Informatics and Radioelectronics" Department of Electronic Computing Machines A.V. Otvagin, N.A.

GOU VPO Vladimir State University vernoemd naar Alexander Grigorievich en Nikolai Grigorievich Stoletovs VISUAL MODELING LANGUAGE UML Methodologische richtlijnen voor cursuswerk in de discipline

Lab 3 BEHEER VAN GEAUTOMATISEERDE SYSTEEMVEREISTEN MET BEHULP VAN IBM RATIONAL REQUISITE PRO. CREATIE VAN GEBRUIKSCENARIO'S Doel van het werk: ontwikkelen van scenario's voor het gebruik van software

Ministerie van Onderwijs en Wetenschappen van de Russische Federatie Federale staatsbegrotingsinstelling voor hoger beroepsonderwijs "Vladimir State University vernoemd naar

Hoorcollege 2 Tools voor het modelleren van bedrijfsprocessen 2.1 Inleiding BPMN (Business Process Modeling Notation) grafische notatie voor het modelleren van bedrijfsprocessen. BPMN is ontwikkeld door Business Process Management

KAZAN (Volga Regio) FEDERAAL UNIVERSITEITSINSTITUUT VOOR COMPUTATIONAL WISKUNDE EN INFORMATIETECHNOLOGIEN Visuele modellering van systemen in StarUML Kazan 2013 UDC 004.4 "22 519.682.6 Gedrukt door

Vichugova Anna Aleksandrovna, assistent van de afdeling Automatisering en Computersystemen, Instituut voor Cybernetica, TPU. E-mail: [e-mail beveiligd] Onderzoeksinteresses: bedrijfsmodellering, structurele analyse, databases

FEDERAAL COMMUNICATIEAGENTSCHAP Federale Staatsbegrotingsinstelling voor Hoger Onderwijs "POVOLGA STAATSUNIVERSITEIT VAN TELECOMMUNICATIE EN INFORMATICA"

De metataal van het construeren van visuele modelleringstalen L.N. Lyadova, A.O. Staatsuniversiteit van Sukhov Perm [e-mail beveiligd], [e-mail beveiligd] Inleiding Met het toenemende aantal eisen voor aanpasbare

SOFTWARE ENGINEERING ANALYSE EN ONTWERP RADCHENKO G.I., AFDELING VAN JV YURGU ONTWERP VOLGENS RADCHENKO GI, AFDELING VAN JV YURGU 2 WAT IS SOFTWARE ONTWERPEN? Softwareontwerp is een bewuste keuze voor oplossingen

Laboratoriumwerk 7. VOLGORDE DIAGRAMMEN. Een sequentiediagram toont de volgorde waarin objecten communiceren om berichten uit te wisselen. Volgordediagrammen

Onderwerp: BENADERING VAN HET ONTWERP VAN COMPLEXE SYSTEMEN. Jacksons techniek. Inhoud: inleiding tot gestructureerd programmeren. Jackson-methode "10 regels" 1. Inleiding Momenteel overal ter wereld

Mikhail Vasiliev, Igor Khomkov, Sergey Shapovalenko

Bijna in alle stadia van de levenscyclus van informatiesystemen (IS) - zowel ontwerp, wanneer de basiskenmerken van het systeem worden gelegd, als onderhoud en beheer van een reeds gebouwd IS - doen zich veel zaken voor die van het grootste belang zijn. Zal deze IP-architectuur voldoen aan de groeiende behoeften? Welke knelpunten vragen de meeste aandacht? Welke investeringen zijn nodig om het IP over een jaar operationeel te houden? .. drie jaar .. vijf jaar? Wat is het rendement van het gebruikte IP?

Al deze vragen zijn verre van eenvoudig te beantwoorden. Nog moeilijker is het om ze correct te beantwoorden. Het analyseren van een bedrijfsinformatiesysteem in elk stadium van zijn bestaan ​​is een complexe aangelegenheid.

We kunnen stellen dat de complexiteit van bedrijfsinformatiesystemen geen toeval is, maar eerder een noodzakelijke eigenschap. Het wordt bepaald door een aantal redenen, waaronder de volgende:

De complexiteit van het probleem dat wordt opgelost;

Complexiteit van IS-ontwikkeling;

De complexiteit van het verstrekken van parameters zoals toereikendheid, schaalbaarheid, betrouwbaarheid, kosteneffectiviteit en veiligheid;

De complexiteit van de beschrijving van individuele IS-subsystemen.

Een objectieve beoordeling kan worden gegeven door de toepassing van modelleringstechnologieën. Een model bouwen, analyseren en antwoorden krijgen op de vragen "wat gebeurt er als ...?" maken het mogelijk om het gedrag van IP in verschillende situaties te voorspellen. De meest gebruikte zijn bench prototyping en constructie van computermodellen van IS.

Momenteel zijn er drie leiders op de markt voor het modelleren van informatiesystemen. Dit zijn de Amerikaanse bedrijven MIL3 (OPNET-modelleringssysteem), Make Systems (NetMaker XA-systeem) en CACI Products Company (COMNET-systeem). In afb. 1 toont het hoofdvenster van het OPNET-systeem. (In PC Week / RE, nr. 34/98, p. 36, Fig. 2 toont een venster voor grafische presentatie van resultaten in het OPNET-systeem.) Laten we in meer detail stilstaan ​​​​bij een van deze systemen en de aanpak die erin is geïmplementeerd .

IC-simulatietechnologie met COMNET III

De voor de hand liggende manier om complexe systemen te modelleren is om ze te ontleden volgens het oude principe van Divide et impera (verdeel en heers. - Lat.). De hiërarchische representatie van complexe IS in de vorm van een reeks gerelateerde subsystemen is de sleutel tot het onthullen van de situatie. Subsystemen die als resultaat van een dergelijke decompositie zijn verkregen, kunnen op hun beurt worden onderverdeeld in subsystemen van het volgende niveau van de hiërarchie, enzovoort tot in het oneindige. Het is het vermogen om complexe systemen te ontleden dat ons in staat stelt hun modellen te creëren. Op dit pad is het echter uiterst belangrijk om op tijd te kunnen stoppen.

De laatste fase van het ontbindingsproces wordt bepaald door het laagste abstractieniveau dat in elk specifiek model wordt toegepast. Te gedetailleerde fragmentatie kan leiden tot precies het tegenovergestelde van het verwachte resultaat: in plaats van het gemodelleerde systeem te vereenvoudigen, kan men tot de complicatie ervan komen, tot wat wordt genoemd "door de bomen het bos niet meer". Het juiste abstractieniveau is dus van cruciaal belang voor succesvolle modellering.

De volgende stap om het modelleren van complexe systemen gemakkelijker te maken, is het ontdekken en isoleren van algemene abstracties. Stel dat we de decompositie van de gemodelleerde IS al hebben uitgevoerd en een bepaalde hiërarchie van entiteiten hebben ontvangen. Een Cisco 7500-router en een NS7000-computer met meerdere netwerkkaarten en softwarerouting kunnen bijvoorbeeld worden gezien als twee totaal verschillende entiteiten of als twee entiteiten die tot dezelfde klasse routers behoren. Decompositie van het systeem met behulp van de klassenmetafoor in combinatie met het correct gekozen abstractieniveau maakt het mogelijk om de constructie van het IS-model radicaal te vereenvoudigen.

Rijst. 1. Het hoofdvenster van het OPNET-systeem

Gewoonlijk worden twee hoofdtypen decompositie beschouwd: algoritmisch, dat het bestudeerde systeem scheidt volgens zijn actieve principes, dat wil zeggen de processen die erin plaatsvinden in een bepaalde volgorde, en objectgeoriënteerd, waardoor het bestudeerde systeem kan worden verdeeld in klassen van hetzelfde type abstracties. Beide soorten ontbinding hebben hun weg gevonden naar COMNET III.

De COMNET III-benadering van modelbouw kan worden weergegeven als een standaardopeenvolging van stappen:

Beschrijving van IS-topologie en definitie van apparatuurparameters;

Beschrijving van verkeersbronnen en hun gedrag, beschrijving van netwerkbelasting;

Bepaling van het simulatiescenario.

De definitie van de IS-topologie en de verbindingen van verkeersbronnen met de knooppunten van de topologie is een ideaal veld om objectgeoriënteerde ontleding toe te passen. Om het gedrag van verkeersbronnen en veranderingen in netwerkbelasting in de tijd te beschrijven, is een algoritmische decompositie vereist.

Zoals eerder vermeld, zijn de randvoorwaarden voor IS-decompositie afhankelijk van het vereiste abstractieniveau. Abstractie stelt de ontwikkelaar die het IP-project maakt, of de systeembeheerder die het onderhoudt, in staat om de meest essentiële kenmerken van zijn gedrag te scheiden van hoe ze worden geïmplementeerd. "Een goede abstractie is er een die de nadruk legt op details die essentieel zijn voor overweging en gebruik, en die details weglaat die momenteel niet relevant of afleidend zijn" * 1. Dus in de ene situatie is het bij het beschrijven van een computer voldoende om deze als verkeersbron te definiëren zonder in te gaan op een gedetailleerde beschrijving van de architectuur; in een andere situatie een gedetailleerde overweging van kenmerken zoals bijvoorbeeld het aantal processors en parameters van het schijfsubsysteem kan nodig zijn.

*1. Shaw M. Abstractietechniek in moderne programmeertalen. - IEEE Software, okt. 1984, vr. 1 (4), blz. 10.

In het COMNET-systeem is de objectgeoriënteerde ontledingsmethode volledig toepasbaar, wat de modelleringstijd aanzienlijk kan verminderen en het proces intuïtief kan maken, duidelijk gecorreleerd met het echte systeem. Het model is gemaakt van objecten, een soort 'bouwstenen' die de gebruiker uit de praktijk kent. Het COMNET-systeem wordt geleverd met een grote bibliotheek van dergelijke objecten - modellen van echte netwerkapparatuur en methoden voor toegang tot de omgeving. Laten we het COMNET-objectmodel eens nader bekijken (Fig. 2).

Rijst. 2. De basis COMNET III-klassebibliotheek:

Objecten in dit systeem kunnen worden onderverdeeld in twee klassen: ten eerste gebruikt om de topologie te beschrijven en ten tweede om verkeers- en netwerkbelastingskenmerken te beschrijven. Het basis COMNET III-scherm met een set bibliotheekklassen wordt getoond in Fig. 3.

Rijst. 3. Het hoofdscherm van het COMNET-systeem

Beschrijving van de topologie in COMNET III

De basisconcepten van de topologie in het COMNET III-systeem, zoals knooppunten, verbindingen, bogen, werden beschreven in PC Week / RE, nr. 34/98, p. 34.

Naast knooppunten, verbindingen en bogen, voor het beschrijven van hiërarchische topologieën en het modelleren van onafhankelijke routeerbare domeinen, bevat COMNET nog een extra klasse, waarvan de objecten zich ook op de hoekpunten van de grafiek kunnen bevinden - een subnet.

Door gebruik te maken van het overervingsmechanisme, inclusief meervoudige overerving, wordt het aantal gebruikte klassen uitgebreid.

De node-klasse wordt overgenomen door vier nieuwe klassen.

Klasse "Computer- en communicatieknooppunt" (C&C-knooppunt, computer- en communicatieknooppunt)

Deze objecten kunnen dienen als bronnen of putten van verkeer en worden ook gebruikt om complexe softwaresystemen te modelleren die rekening houden met de belasting van de processor en schijfsubsystemen. De IS-nodes beschreven met de C&C Node kunnen ook worden gebruikt om softwarerouters te modelleren.

Klasse "Groep computers" (Computergroepknooppunt)

Het object kan alleen worden gebruikt voor het modelleren van computersystemen, omdat hun functionaliteit alleen de bron en bestemming van verkeer omvat. In de regel wordt het gebruikt om groepen computers te beschrijven die identiek gedrag vertonen.

Router Node-klasse

Objecten van dit type worden gebruikt om hardwarerouters te modelleren. Net als C&C Node kan Router Node zowel als bron als ontvanger van verkeer fungeren en toepassingen uitvoeren die de hardwarebronnen van het knooppunt gebruiken (processors, schijfsubsystemen). Voor een meer gedetailleerde beschrijving van de hardware-implementatie van de gesimuleerde objecten zijn een aantal extra eigenschappen geïntroduceerd, zoals de aanwezigheid en parameters van de interne bus, die het mogelijk maakt om de interne doorgang van verkeer tussen de input en output te simuleren poorten van het object.

Switch Node-klasse

Switch Node-objecten, met hun routeringscapaciteit, worden gebruikt om switches te simuleren die verwaarloosbare tijd besteden aan het overbrengen van verkeer tussen interne poorten. Deze objecten kunnen echter, in tegenstelling tot de drie voorgaande, niet worden gebruikt als bron of als een put van verkeer.

Objecten van de C&C Node-, Computer Group Node- en Router-knooppuntklassen voor het modelleren van complexe softwaresystemen omvatten een opslagplaats van opdrachten die gebruik maken van dergelijke objecten die al zijn genoemd, zoals de kenmerken van het schijfsubsysteem. De constant bijgewerkte bibliotheek met objecten van verschillende klassen die deel uitmaken van COMNET, omvat een breed scala aan modellen van real-life hardwareapparaten.

Het link-object erft twee nieuwe objecten.

Point-to-Point Link-klasse

Deze klasse wordt gebruikt om kanalen tussen twee knooppunten te beschrijven. Een voorbeeld van dergelijke verbindingen kunnen huurlijnen zijn die routers in wide area-netwerken met elkaar verbinden of verbindingen in circuitgeschakelde netwerken.

Koppelingsklasse voor meerdere toegangen

Het veld voor de toepassing van deze klasse zijn situaties waarin meerdere knooppunten toegang hebben tot hetzelfde datatransmissiemedium. Dit object wordt op zijn beurt overgenomen door een aantal nieuwe objecten die specifieke feiten van de implementatie van de mediumtoegangsmethode beschrijven, zoals Carrier Detection, Token Passing, SONET, enzovoort (zie figuur 2).

Tot nu toe hebben we gekeken naar gevallen waarin een bovenliggend object wordt overgenomen door een enkel onderliggend object. De objectgeoriënteerde benadering maakt echter complexere situaties met meervoudige overerving mogelijk. Deze vorm van overerving geldt ook voor COMNET. Hier wordt meervoudige overerving gebruikt om objecten van zulke belangrijke klassen als het Transit Network en de WAN Cloud te creëren.

Beide klassen erven van twee bovenliggende klassen - Subnet en Link. De vorm van overerving wordt getoond in Fig. 2. Laten we deze optie in meer detail bekijken.

Subnetklasse

Een uiterst belangrijke klasse. Het wordt gebruikt om hiërarchische IS-topologieën te maken en stelt u in staat om subnetten correct te beschrijven met verschillende routeringsalgoritmen en onafhankelijk van het algoritme dat op de backbone wordt gebruikt. Daarnaast worden subnetten gebruikt om onnodige details te verbergen bij het modelleren van complexe IC's. In COMNET worden ze gebruikt om systemen met een willekeurige nestdiepte te beschrijven. De verbindingen tussen de interne subnet-topologie en de backbone-topologie worden gemaakt met behulp van toegangspunten, waarvan het aantal willekeurig kan zijn (zie figuur 3).

Transit Netto klasse

Een kind van subnetten en verbindingen is een object dat de eigenschappen van de bovenliggende objecten combineert. Een transitnetwerk kan tegelijkertijd worden gezien als zowel een verbinding als een subnet. Als verbinding stuurt het pakketten door van de uitvoerbuffer van het ene knooppunt naar de invoerbuffer van een ander. Als subnet creëert het transitnetwerk een gebied binnen zijn grenzen met zijn eigen routeringsalgoritme.

Klasse "Cloud" (WAN Cloud)

Objecten van deze klasse, waarmee u abstracte representaties voor wereldwijde netwerken kunt maken, erven ook de eigenschappen van bovenliggende objecten - Subnet en Link. In termen van topologie functioneert het WAN Cloud-object als een verbindingsobject, het pictogram maakt rechtstreeks verbinding met de knooppunten. Wat de interne structuur betreft, bestaat de cloud uit een reeks virtuele circuits en toegangslinks, een soort punt-naar-punt-verbinding voor het modelleren van wereldwijde netwerken.

Beschrijving van verkeer en netwerkbelasting in COMNET III

Zoals we al zeiden, omvat het IS-model in COMNET twee delen: een beschrijving van de systeemtopologie en een beschrijving van de bronnen van verkeer en netwerkbelasting. We hebben een basisbereik van topologiegerelateerde objecten behandeld. Laten we nu eens kijken naar verkeersobjecten.

COMNET biedt een breed scala aan hulpmiddelen voor het beschrijven van verkeer.

Bericht klasse

Met objecten die tot deze klasse behoren, kunt u een enkel bericht verzenden naar één doelobject of naar meerdere objecten. Het doorsturen van dergelijke berichten wordt gezien als een reeks datagrammen, waarbij elk pakket onafhankelijk van de andere wordt gerouteerd.

Reactieklasse

Objecten van deze klasse kunnen alleen worden gebruikt om antwoordberichten te verzenden. Ze worden gecontroleerd door de aankomst van berichten die worden gegenereerd door objecten van de klassen Message of Response. De ontvanger van berichten van de klasse Response zal altijd het object zijn van de klasse Node waarop de bron van de besturingsberichten (van de klasse Response of Bericht) is aangesloten.

Bel klasse

Objecten van de klasse Call worden gebruikt om modellen van circuitgeschakelde netwerken te maken. De oorsprong van de oproep wordt beschreven door een reeks parameters zoals distributiewet, duur en, rekening houdend met de routeringsklasse, bandbreedtevereisten.

Sessie klasse

Deze objecten worden gebruikt om sessies te modelleren met berichtensets of berichten die via virtuele verbindingen worden gerouteerd. Een sessie wordt gestart door een sessie-setuppakket te verzenden en een bevestigingspakket te ontvangen. In de toekomst kan in het kader van de sessie een willekeurig aantal berichten worden verzonden, ook beschreven in het object van de klasse Session. Deze berichten worden gerouteerd als datagrammen of als virtuele verbindingen, afhankelijk van het routeringsalgoritme op de trunk of op het subnet dat het object bevat.

Merk ook op dat COMNET III zogenaamde externe verkeersbestanden gebruikt, die kunnen worden verkregen met behulp van verschillende verkeersanalysatoren.

Van bijzonder belang zijn objecten van de klasse Application, die het resultaat is van meervoudige overerving van de klassen Message, Response, Call en Session (zie figuur 2). De objecten maken de meest flexibele beschrijving van de netwerkbelasting en het gedrag van verkeersbronnen binnen het model mogelijk. Bovendien kunnen, wanneer ze worden gebruikt, bijna elk soort softwaresysteem, inclusief gedistribueerde systemen, zoals DBMS, mailsystemen, enz., gemakkelijk worden gemodelleerd.

Een echte toepassing beschreven door objecten van deze klasse omvat drie samenstellende delen. Ten eerste zijn dit de parameters van het knooppunt waarmee het klasseobject Application is verbonden. Deze parameters worden gebruikt om de kenmerken en het aantal vereiste processors en schijfsubsystemen in te stellen. Ten tweede zijn dit de zogenaamde command repositories die gebruik maken van de bovengenoemde kenmerken van het knooppunt. En ten derde is dit het Application-object zelf, dat de volgorde van uitvoering van deze opdrachten bepaalt.

De repository voor node-opdrachten, en dus het klasseobject Application, kan de volgende opdrachten bevatten:

Transportbericht Deze opdracht is het resultaat van de toepassingsklasse die wordt geërfd van het bovenliggende berichtobject.

Setup is het resultaat van overerven van de Session-klasse.

Answer Message erft van de klasse Response.

Bericht filteren Met deze opdracht kunt u alle bewerkingen die zijn beschreven in het object van de klasse Application opschorten totdat een bericht wordt ontvangen dat voldoet aan de filtervoorwaarden.

Proces Deze opdracht simuleert verwerking die een belasting van de processor veroorzaakt.

Lezen en schrijven Met deze twee opdrachten kan ook de bezetting van de processor van het knooppunt worden gesimuleerd, maar deze keer in de context van interactie met het schijfsubsysteem voor het lezen en schrijven van bestanden.

Met behulp van de klassen Application, Message, Response, Session en Call is dus zowel flexibele modellering van de huidige netwerkbelasting als een gedetailleerde beschrijving van het gedrag van de softwaresystemen die deel uitmaken van de IS mogelijk. Het is van cruciaal belang dat u met deze klassen complexe gedistribueerde softwaresystemen en hun impact op de bestaande netwerkinfrastructuur van het netwerk kunt modelleren.

COMNET III-objecten: parametrische abstractie

Wanneer we het hebben over de basisset van COMNET III-klassen, is het uiterst belangrijk om de toepasbaarheid van de zogenaamde parametrische abstractie daarop te vermelden. Met deze benadering kunt u nieuwe objecten maken - instanties van een klasse met verschillende eigenschappen. Dergelijke belangrijke technologische beslissingen, zoals bijvoorbeeld Gigabit Ethernet, kunnen heel eenvoudig worden gemodelleerd door de parameters van de beschouwde abstractie te wijzigen - de eigenschappen van de geselecteerde klasse.

Laten we naar een voorbeeld kijken. Laten we zeggen dat we een lokaal netwerk simuleren met behulp van een willekeurige toegangsmethode met carrier sense en collision detection (CSMA / CD, een klasse van verbindingen met meervoudige toegang) op de MAC-sublaag, maar de linklaagstandaard die wordt voorgesteld door de fabrikant van de netwerkapparatuur is iets anders dan de "native" IEEE 802.3. Een dergelijke situatie, bij het gebruik van een product dat geen objectgeoriënteerde benadering implementeert, kan enkele onnauwkeurigheden veroorzaken. De ontwikkelaar zou worden gedwongen om de standaard te gebruiken die wordt aangeboden door de productfabrikant, hoogstwaarschijnlijk de klassieke 802.3. In afb. 4 toont het COMNET III-interfacevenster, waarmee de gebruiker de parameters van deze standaard kan bewerken - het aantal hertransmissies in geval van collisiedetectie, de lengte van de frameheader, enz. Met andere woorden, de gebruiker voert zelf de parametrering uit van het voorwerp.

Rijst. 4. Parametrisering van de 10BaseT-verbinding van de IEEE 802.3-standaard

We beslissen dus over de naleving van de referentienorm en de norm van de fabrikant. Onze verdere acties zijn beperkt tot het aanvullen van de bibliotheek met objecten van de CSMA / CD-klasse met een nieuwe standaard, die door de gebruiker is gedefinieerd. Om dit te doen, hoeft u alleen maar nieuwe parameters toe te voegen. We kunnen hetzelfde doen met hardwareknooppunten, verkeersbronnen, WAN Cloud-parameters, enz.

Hieruit blijkt dat parametrering volop mogelijkheden biedt om de basisbibliotheek van objecten uit te breiden, waardoor de modelontwerper flexibelere beslissingen kan nemen.

U kunt de basisset van klassen uitbreiden met verder gebruik van het overervingsmechanisme.

Intermodel kopieer-plak modus

Stel dat we een groot model bouwen met een zeer complexe topologische beschrijving. Hier kunnen we op twee manieren naartoe: de hele topologie van het systeem combineren in één bestand, of meerdere fragmenten bouwen en deze vervolgens combineren. De tweede optie is om een ​​aantal redenen handiger voor de ontwikkelaar. Dit is het gemak van het debuggen van elk afzonderlijk fragment, de goede zichtbaarheid en, uiteindelijk, de grote betrouwbaarheid.

In de toekomst is het hele probleem om objecten van het ene model naar het andere over te brengen. Om dit op te lossen, is het handig om de COMNET III Intermodel kopieer-plakmodus te gebruiken, die de overdracht van nieuw gemaakte objecten van model naar model biedt met alle eigenschappen behalve die die lokaal zijn voor het bronmodel.

Laten we een voorbeeld geven. Laten we zeggen dat we van het ene model naar het andere een fragment van het netwerk overbrengen dat enige belasting heeft. Verkeer wordt beschreven door objecten van de klasse Message. De eigenschap van dergelijke objecten, lokaal voor het bronmodel, is de bestemming. De rest van de eigenschappen worden zonder wijzigingen overgenomen van objecten die knooppuntklassen erven (C&C-knooppunt, computergroep, router, switch), link, enz., die niet zijn gekoppeld aan het bronmodel.

De parametreringsprocedure is in dit geval zeer eenvoudig. U kunt met name de richting van het bericht specificeren volgens de lijst met namen van het nieuwe model, dat automatisch aan het object wordt gekoppeld.

De toepassing van de beschreven methode biedt volop mogelijkheden bij de constructie van alle modellen uit een flexibel uitbreidbare set objecten - bouwstenen, waardoor u de kosten van modellering aanzienlijk kunt verlagen.

Modulair knooppunt bouwen

Overweeg de procedure voor het maken van een object van een nieuwe klasse op basis van meervoudige overerving.

Stel dat een ontwikkelaar de opdracht krijgt om een ​​gedetailleerd model van een hardwareapparaat te bouwen (bijvoorbeeld een router, waarvan meerdere interfacemodules zijn verbonden door een interfacebus). Het doel van het bouwen van het model is om de vertraging op de interfacebus te bepalen. In de standaard COMNET III-beschrijving wordt een bus beschreven door twee parameters: bandbreedte en frequentie. Het is duidelijk dat een dergelijke beschrijving voor ons niet voldoende is. We hebben echter een object tot onze beschikking waarmee we de bus als een apart apparaat kunnen beschrijven - de verbinding. Over het algemeen is dit geen volledig standaardoplossing, maar nadat we de noodzakelijke parametrering van het object van de Link-klasse hebben uitgevoerd, krijgen we een model van de bus als een volledig uitgerust apparaat dat bijvoorbeeld de arbitragefunctie implementeert . Getoond in afb. 5 het object MPRouter wordt op deze manier gemodelleerd. De interfacebus werkt hier volgens het Token Bus-algoritme.

Rijst. 5. Parametrering van de verkeersbron tijdens migratie

een fragment van een model naar een ander model (Session Source)

Tegelijkertijd moet worden gezegd dat de ontwikkelaar dergelijke technieken niet mag misbruiken, omdat, zoals eerder vermeld, een al te nauwkeurige beschrijving van elk object in sommige situaties het tegenovergestelde effect kan hebben, wat zich uit in een afname van de betrouwbaarheid van het model als geheel. Deze techniek is toepasbaar in gevallen waarin een gedetailleerde beschrijving van de kenmerken van objecten vereist is.

Mogelijkheid om objectstatussen in te stellen

Elk object in COMNET kan zich in verschillende toestanden bevinden. Voor objecten van de klassen Link en Node zijn bijvoorbeeld toestanden omhoog, omlaag, storing mogelijk (aan, uit, fout). U kunt ook de overgangen tussen deze toestanden simuleren en het effect van de overgang op de gesimuleerde IS analyseren (Fig. 6).

Rijst. 6. Bepaling van de parameters van de huidige staat van het object (Node Properties)

Dit geeft de ontwikkelaar ruimschoots de mogelijkheid om dynamische scenario's te creëren zoals "wat als ...?" en verhoogt zo de flexibiliteit van het gecreëerde model aanzienlijk.

We hebben dus gekeken naar de basistools en de meest voorkomende technieken voor het bouwen van modellen in COMNET III. De auteurs zijn van plan meer artikelen te wijden aan het modelleren van verschillende oplossingen die veel worden gebruikt in moderne IC's.

De tutorial bevat: een samenvatting van de UML - dat deel ervan dat kan worden gebruikt als basis van de taal voor het modelleren van complexe dynamische systemen; beschrijving en mogelijkheden van de door de auteurs voorgestelde nieuwe modelleertaal op basis van hybride automaten, die een uitbreiding is van de UML; historisch overzicht en voorbeelden van verschillende benaderingen voor het ontwerpen van modelleertools; objectgeoriënteerde analyse van complexe dynamische systemen. Het boek is het tweede van drie boeken onder de algemene titel System Modeling.

De behoefte aan een uniforme taal voor het beschrijven van modellen.
De traditionele technologie voor het ontwerpen van complexe systemen, die geen voorafgaande computermodellering omvat, omvat de volgende hoofdfasen: het formuleren van vereisten voor het toekomstige systeem, de ontwikkeling van ontwerpdocumentatie op basis daarvan, het maken van een prototype, het testen ervan voor het voldoen aan de eisen en het onderhoud van het industrieel ontwerp.

In het ideale geval is een volledige functionele specificatie, ontwikkeld door systeemanalisten of automatisch met behulp van computertechnologie, al een ontwerpoplossing, er blijft weinig over om een ​​fysiek model te bouwen volgens deze specificatie, wat het ontworpen systeem zal zijn. Helaas is dit niet zo. Het creëren van een echt systeem dat voldoet aan de ontwikkelde functionele specificaties vereist creatieve, niet-geformaliseerde technische oplossingen en handarbeid.

Zelfs het schijnbaar volledig geformaliseerde "zachte deel" van moderne technische systemen - ingebedde software - wordt meestal uitgevoerd op speciale ingebedde computers of microprocessors met speciale uitwisselingskanalen, speciale besturingssystemen en andere functies die "handmatige" foutopsporing van de ontwikkelde software impliceren. Zonder deze "handmatige", slecht geformaliseerde fase, is het moeilijk om te voldoen aan de speciale vereisten voor een betrouwbare werking van het systeem bij bepaalde temperaturen, trillingen, overbelastingen, stralingsniveaus, volume- en gewichtsbeperkingen. Hoofdstuk 5 bespreekt de voorwaarden waaronder automatische generatie van firmware maar functionele specificatie mogelijk is, en deze voorwaarden zijn nog ver verwijderd van de huidige realiteit.

Inhoudsopgave
Inhoudsopgave
Voorwoord
Hoofdstuk 1. Objectgeoriënteerde benadering van modellering
De behoefte aan een uniforme taal voor het beschrijven van modellen
Klassen, instanties en systemen met meerdere componenten
De UML gebruiken in de vroege ontwerpfase
Klassendiagrammen
attributen
Gedrag
Bewerkingen en methoden
Abstracte en concrete lessen. Interfaces
Klassen en relaties
Vereniging
Generalisatie
Aggregatie
Erfenis
Polymorfisme
Gedrag. Staatsdiagrammen
Gestructureerde classificaties
Componenten
Gebeurtenissen en signalen
Pakketjes
Model
Hoofdstuk 2. Objectgeoriënteerde modellering van complexe dynamische systemen gebaseerd op het formalisme van een hybride automaat
Actieve klasse en actief dynamisch object
Pakketten en Model
Passieve objecten gebruiken
Variabelen
Gegevenstypen
scalaire typen
Echte type
Integer typen
Booleaans type
opgesomde typen
Karaktertypes
Reguliere soorten
Vectoren
matrices
arrays
Lijsten
Gecombineerd type (schrijven)
Expliciet gedefinieerde typen
signalen
Automatisch type gieten
Stelsel van vergelijkingen
Gedragskaart
Staten
Overgangen
structureel schema
Voorwerpen
verbindingen
Reguliere structuren
klasse overerving
Nieuwe beschrijvingselementen toevoegen
Overgenomen items overschrijven
Polymorfisme
Geparametriseerde klassen
Hoofdstuk 3. Modelleren van hybride systemen en objectgeoriënteerde benadering in verschillende pakketten
Hybride systemen modelleren in tools voor "grote" computers
SLAM II-taal
NEDIS-taal
Hybride modellen in moderne modelleringstools
Simulatie van hybride systemen in het Simulink-pakket ("bloksimulatie")
Modellering van hybride systemen in Modelica-taal ("fysieke modellering")
Hybride richting
Objectgeoriënteerde modelleringstalen
Simula-67 en NEDIS
ObjectWiskunde
Omola
Modelica
Blokmodelleringstools
Analyse van bestaande OOM-talen zoals toegepast op het modelleren van complexe dynamische systemen
Hoofdstuk 4. Modellen met meerdere objecten
Hoofdstuk 5. Objectgeoriënteerde modellering en objectgeoriënteerde analyse
Complex technisch systeem
Objectgeoriënteerde analyse bij de ontwikkeling van complexe technische systemen
Objectgeoriënteerde modellering in de volgende stadia van ontwikkeling en onderhoud van een complex technisch systeem
Systeemanalytisch model als basis van "end-to-end" ontwerptechnologie
Literatuur
Verder lezen voor hoofdstuk 1
Verder lezen voor hoofdstuk 2
Verder lezen voor hoofdstuk 3
Verder lezen voor hoofdstuk 4
Verder lezen voor hoofdstuk 5
Onderwerp index.

Download gratis een e-book in een handig formaat, bekijk en lees:
Download het boek System Modeling, Object-Oriented Approach, Yu. Kolesov, Yu. Senichenkov, 2012 - fileskachat.com, snel en gratis te downloaden.

Download PDF
Hieronder kunt u dit boek kopen tegen de beste gereduceerde prijs met levering in heel Rusland.

7. Geometrische modellering. Soorten modelleringssystemen. Interne weergave van modellen.

Geometrische modellering.

Er zijn 2 taken:

1. Een geometrisch model bouwen van een bestaand lichaam.

2. Synthese van een geometrisch model van een nieuw object.

Bij het oplossen van het 1e probleem is het nodig om een ​​groot aantal punten in te stellen die bij het oppervlak van het object horen. Bij het oplossen van het tweede probleem van geometrische modellering, uitgevoerd in een interactieve modus, is de belangrijkste vereiste voor de middelen om een ​​geometrisch model te vormen en weer te geven het gemak van het manipuleren van het model. Er zijn 3 soorten geometrische modellen: wireframe, oppervlakte, solide.

Een draadmodel vertegenwoordigt vele hoekpunten en vele randen die deze hoekpunten verbinden.

Oppervlaktemodel: Eerst wordt een driedimensionaal draadframe gemaakt, waarop vervolgens verschillende soorten wiskundige oppervlakken worden "uitgerekt". Oppervlaktemodelleringssystemen ondersteunen verschillende soorten oppervlakken: gelijnde oppervlakken, kinematische oppervlakken en gebeeldhouwde oppervlakken. De volgende bewerkingen kunnen over oppervlakken worden uitgevoerd: het oppervlak afsnijden met een ander oppervlak of een ruimtelijke kromming op het oppervlak, vloeiende overgangen of afrondingen tussen de oppervlakken maken.

Het voordeel van oppervlaktemodellering: Geom kan worden gegenereerd. objecten van enige mate van complexiteit.

Nadeel: oppervlakken hebben geen dikte en echte objecten zijn een soort gesloten volume.

Het oppervlaktemodel van een object is een "schaal" met een leegte aan de binnenkant, hierdoor ontstaan ​​problemen bij het verdelen van een object in eindige elementen bij het berekenen van massatraagheidskarakteristieken en bij het regelen van de interpenetratie van onderdelen in een samenstel. Oppervlaktemodellering yavl. Een nauwgezet proces - vereist kennis van de tekening. en ontwikkeld ruimtelijk denken.

Een solide model wordt opgebouwd uit basiselementen met behulp van de juiste bewerkingen: Booleaanse bewerkingen, extrusie, rotatie, lofting, solide scheiding. CAD staat de volgende toevoeging toe. activiteiten:

constructie van filets, constructie van gaten op vlakken, constructie van verstijvers, constructie van afschuiningen.

Het solide model wordt als constructieboom in de CAD opgeslagen.

Het voordeel van solide modellering:

1. Eenvoud van parametrering.

2. Mogelijkheid om massatraagheidskarakteristieken te berekenen en op te splitsen in een netwerk van eindige elementen.

3. Relatieve eenvoud van modelleren.

Nadeel: beperkte ontwerpvormen van de gemaakte modellen.

Gegevenspagina's die worden gebruikt om vaste lichamen te beschrijven, zijn meestal onderverdeeld in: drie soorten afhankelijk van of welke lichamen? ze worden beschreven.

1 pagina vertegenwoordigt hout , beschrijft de geschiedenis van prim-I booleaanse operaties voor primitieven. Het activiteitenlogboek heet constructieve weergave van volumetrische geometrie (constructief Stevig Geometrie – CSG vertegenwoordiging). De boom heet boomCSG (GSG boom).

2 pagina's bevat informatie over de grenzen van het volume (hoekpunten, randen, vlakken en hun verbinding met elkaar). Deze weergave heet grens representatie (grens vertegenwoordiging- V-rep), en de datastructuur is structuurB- rep (B- rep gegevens structuur).

derde structuur vertegenwoordigt volume als een combinatie van elementaire volumes (bijvoorbeeld kubussen). Je kunt veel ontledingsmodellen bedenken door verschillende elementaire volumes te kiezen, maar geen van hen kan een volumetrisch lichaam nauwkeurig beschrijven.

Modelleren - een van de belangrijkste methoden van cognitie, die verschijnt in de scheiding van sommige delen van een complex fenomeen (object) en hun verwijdering door andere objecten die begrijpelijker en handiger zijn om te begrijpen, uit te leggen en te ontwikkelen.

Model- een echt fysiek object of proces, een theoretische analyse, een geordende reeks gegevens die enkele elementen of eigenschappen van het bestudeerde object of fenomeen weerspiegelen die essentieel zijn vanuit het oogpunt van modellering.

Wiskundig model model van een object, proces of fenomeen. die wiskundige wetten vormt met behulp waarvan de belangrijkste kenmerken van het gemodelleerde object, proces of

Geometrische modellering deel van de wiskunde

modellering stelt u in staat om een ​​verscheidenheid aan problemen op te lossen in tweedimensionale, driedimensionale en. in het algemeen in een multidimensionale ruimte.

Geometrisch model omvat stelsels van vergelijkingen en algoritmen voor hun implementatie. De wiskundige basis voor het bouwen van een model zijn de vergelijkingen die de vorm en beweging van objecten beschrijven. De hele verscheidenheid aan geometrische objecten is een combinatie van verschillende primitieven - van de eenvoudigste vormen, die op hun beurt bestaan ​​uit grafische elementen - punten, lijnen en oppervlakken.

Momenteel wordt geometrische modellering met succes gebruikt in management en andere gebieden van menselijke activiteit. Er zijn twee belangrijke toepassingsgebieden voor geometrische modellering; ontwerp en onderzoek.

Geometrische modellering kan worden gebruikt om numerieke gegevens te analyseren. In dergelijke gevallen wordt enige geometrische interpretatie in overeenstemming gebracht met de initiële numerieke gegevens, die vervolgens worden geanalyseerd, en worden de resultaten van de analyse geïnterpreteerd in termen van de initiële gegevens.

Stadia van geometrische modellering:

Verklaring van een meetkundig probleem dat overeenkomt met het oorspronkelijk toegepaste probleem of een deel ervan:

Ontwikkeling van een geometrisch algoritme om het probleem op te lossen;

Implementatie van het algoritme met behulp van tools:

Analyse en interpretatie van de verkregen resultaten. Geometrische modelleringsmethoden:

Analytisch:

Grafisch;

Grafisch, met behulp van machine graphics:

Grafisch-analytische methoden.

Grafo-analytische methoden zijn gebaseerd op computationele secties !! meetkunde zoals de theorie van R-functies. theorie van Koons-oppervlakken. theorie van Bezier-curven, theorie van splines, enz.

Modern wetenschappelijk onderzoek kenmerkt zich door het gebruik, naast tweedimensionale en driedimensionale, multidimensionale geometrische modellen (fysica van elementaire deeltjes, kernfysica, enz.).

8. Grafische talen op hoog niveau.

Er zijn twee benaderingen voor het bouwen van programmeersystemen met machinegeometrie en grafische talen op hoog niveau. Eerst de aanpak is om een ​​op zichzelf staande taal te creëren, tweede- in de noodzakelijke wijziging van een of andere algoritmische brontaal.

Met de eerste benadering kunt u een taal maken die het beste aansluit bij de specifieke kenmerken van het werken met grafische en geometrische informatie, maar alleen in de klasse van toepassingen waarvoor de taal bedoeld was. Historisch gezien is het belangrijkste toepassingsgebied van dergelijke talen:

automatisering van programmering voor CNC-apparatuur;

automatiseringssystemen voor ontwerp- en constructiewerkzaamheden die hulpmiddelen vereisen voor het werken met gegevens die in wijdverbreide algoritmische talen ontbreken;

geometrische modelleringssystemen.

Een van de eerste probleemgeoriënteerde talen die de middelen had om geometrische informatie te beschrijven, was de taal KUNST(GEAUTOMATISEERDE PROGRAMMEERHULPMIDDELEN). Deze taal diende als basis voor de ontwikkeling van verschillende prvoor CNC-bewerkingsmachines.

Systemen voor geometrische modellering van driedimensionale lichamen - COMPAC en SIMAC-D - kunnen ook dienen als voorbeelden van systemen met een autonome taal op hoog niveau.

Systeem COMPAC(COMPUTERGEORINTEERDE DEELCODERING) is ontworpen om een ​​beschrijving te vormen van vaste lichamen uit volumetrische vormelementen - (methode van constructieve geometrie). Naast de drie volumetrische basiselementen (kubussen, cilinders, kegels), kunnen geprofileerde delen worden gebruikt, verkregen door een gesloten contour langs een rechte lijn of boog te verplaatsen, evenals omwentelingslichamen verkregen door een gesloten contour rond een as te roteren . Elementen worden gedefinieerd, gepositioneerd en op maat gemaakt met taalconstructies die doen denken aan ART. Het samenstellen van een onderdeel uit volumetrische elementen wordt uitgevoerd met behulp van de bewerkingen van samenvoegen, aftrekken en trimmen.

Verschillen SIMAK-D van COMPAC zijn samengesteld uit een iets andere invoertaal en een andere set basisvormelementen, waaronder een punt, een vlak, een rechthoekig parallellepipedum, cirkelvormige cilinders en een kegel.

Op zichzelf staande grafische talen zijn, zoals elke gespecialiseerde ontwikkeling, zeer efficiënt in hun toepassingsgebied, maar de ontwikkeling en het gebruik van dergelijke talen brengt een aantal problemen met zich mee:

vrij aanzienlijke kosten voor het maken van een taal en een vertaler ervan;

de kosten van implementatie, het opnemen van de taal in een werkend programmeersysteem en het opleiden van gebruikers die niet altijd bereid zijn een andere taal te leren, maar liever procedurele uitbreidingen gebruiken van de algoritmische talen die ze kennen: ALGOL, FORTRAN , PL-1, PASCAL, enz. .;

problemen met de daaropvolgende uitbreiding van de taal;

de momenteel bekende talen van machinegeometrie en grafische afbeeldingen, in tegenstelling tot procedurele uitbreidingen, bieden in de regel geen interactieve modus, maar zijn bedoeld voor het schrijven van passieve programma's;

het is moeilijk om grafische en geometrische bewerkingen en gewone berekeningen te combineren binnen één applicatieprogramma, dat gemakkelijk kan worden geïmplementeerd in het geval van procedurele uitbreidingen.

9. Objectgeoriënteerde modellering.

Objectgeoriënteerd modelleren (functie- gebaseerd modellering) stelt de ontwerper in staat om volumetrische lichamen te creëren met behulp van vertrouwd vormelementen (Kenmerken). Het gecreëerde lichaam bevat informatie over deze elementen naast informatie over gewone geometrische elementen (hoekpunten, randen, vlakken, enz.). De ontwerper kan bijvoorbeeld commando's geven als "maak een gat van die en die grootte op die en die plaats" of "maak een afschuining van die en die grootte op die en die plaats", en de resulterende figuur bevat informatie over de aanwezigheid van een gat (of afschuining) van een bepaalde maat. De set vormelementen die in een bepaald programma beschikbaar is, hangt af van het toepassingsgebied van dit programma.

De meeste objectgeoriënteerde modelleringssystemen ondersteunen dergelijke elementen die worden gebruikt bij de vervaardiging van onderdelen: afschuiningen, gaten, filets, groeven, inkepingen, enz. Dergelijke elementen worden productie omdat ze elk kunnen worden verkregen als resultaat van een specifiek productieproces. Zo ontstaat er een gat door te boren en een inkeping door te frezen. Daarom kunt u op basis van de informatie over de beschikbaarheid, omvang en locatie van productie-elementen proberen om automatisch een plan van het technologische proces te genereren. Automatische procesplanning, indien ontwikkeld op praktisch niveau, zal de kloof overbruggen tussen CAD en CAM, die momenteel afzonderlijk van elkaar bestaan. Op dit moment is het dus beter om objecten te modelleren zoals getoond in Fig. 5.20, waarbij de objectgeoriënteerde modelleringsopdrachten Knippen en Gaten worden gebruikt in plaats van alleen Booleaanse bewerkingen. Het model dat met deze opdrachten is gemaakt, maakt het plannen van de workflow eenvoudiger als deze niet volledig automatisch wordt. Het gebruik van productie-elementen bij het modelleren wordt geïllustreerd in Fig. 5.21.

Een van de nadelen van objectgeoriënteerde modellering is dat het systeem niet alle elementen kan bieden die nodig zijn voor alle mogelijke toepassingen. Elke taak kan een andere set elementen vereisen. Om dit nadeel te elimineren, ondersteunen de meeste objectgeoriënteerde modelleringssystemen een soort taal waarin de gebruiker zijn eigen elementen kan definiëren als dat nodig is. Nadat u het element hebt gedefinieerd, moet u parameters instellen die de grootte aangeven. Elementen, zoals primitieven, kunnen verschillende groottes hebben en de groottes worden ingesteld door parameters op het moment dat het element wordt gemaakt. Het maken van elementen van verschillende groottes door verschillende waarden toe te wijzen aan de bijbehorende parameters is een soort parametrische modellering.

Discipline "Taal- en CAD-software" (Bespalov V.A.)

Het concept van ontwerpautomatisering en de taalkundige ondersteuning ervan

Basis- en controle-linguïstische ondersteuning.

Organisatie van een dialoog in CAD, middel om een ​​dialoogmodus aan te bieden.

Principes van het organiseren van vertalers.

Gegeneraliseerde compilerstructuur.

Syntactische analysator.

Ontwerp- en programmeertalen.

Grondslagen van de theorie van talen en formele grammatica's.

Manieren om de syntaxis van de taal te schrijven. Organisatie van lexicale analyse.

Principes van lexicale en syntactische analysatoren.

Het concept van ontwerpautomatisering en de taalkundige ondersteuning ervan.

Ontwerpautomatisering kenmerkt elke activiteit waarbij een computer wordt gebruikt voor het uitvoeren van arbeidsintensieve berekeningen, het organiseren van het ophalen en opslaan van informatie, geometrische modellering en grafische weergave van resultaten, evenals het bewerken van documentatie om analyses te ontwikkelen en producten en processen aan te passen. Design Automation wordt geïmplementeerd met behulp van CAD.

LO CAD - een reeks talen, termen, definities die nodig zijn voor de implementatie van een geautomatiseerd project-i. LO vindt plaats samen met: technische, wiskundige, informatieve, softwarematige, methodologische en organisatorische ondersteuning van CAD. De basis van LO CAD bestaat uit specials. taaltools (ontwerptalen) ontworpen om de automatiseringsprocedures te beschrijven. pr-I en ontwerpoplossingen. Meestal worden ze probleemgeoriënteerde talen (PYL) genoemd. 2 soorten constructie van de POI:

1. Beschrijving van elke taak met termen van fysieke en functionele inhoud. De overgang naar programma's wordt uitgevoerd met behulp van een vertaler.

2. POYA combineert de tools van een algoritmische taal met speciale taaltools voor het modelleren van geometrische objecten.

POYA is een complex van taalkundige en softwaretools, cat. moet een spoor bevatten. elementen:

een set terminalsymbolen POYA

POYA tolk

parser

richtlijn verpakkingsfaciliteiten

bibliotheken met basisfuncties van POYA

interface voor communicatie met DBMS

Tolk een programma of apparaat dat de operator-per-operator vertaling en uitvoering van het originele programma uitvoert.

Een macroprocessor is een programma dat de ene reeks tekens door een andere vervangt.

Basis- en controle-linguïstische ondersteuning.

De taalkundige ondersteuning van goed ontwikkelde CAD-systemen kan worden onderverdeeld in twee relatief afzonderlijke delen: basis en management, communicatie tussen die wordt uitgevoerd met behulp van gespecialiseerde taalverwerkers-compilers, tolken, enz.

Basis taalkundige ondersteuning is de taalkundige basis van CAD-software en bestaat voornamelijk uit operationele programmeertalen, met behulp waarvan, in het complex van CAD-tools, reken- en modelleringsprocedures van een gegeneraliseerd ontwerpalgoritme worden geïmplementeerd, evenals de oplossing van serviceproblemen .

Taalondersteuning regelen bestaat uit gespecialiseerde probleemgeoriënteerde talen die een gegeneraliseerd ontwerpalgoritme beschrijven in termen van ontwerpbewerkingen, procedures en taken. In deze talen worden woordenschat, syntaxis en semantiek gevormd die significant gerelateerd zijn aan een specifiek ontwerpdomein. Het creëren en gebruiken van probleemgeoriënteerde talen maakt het mogelijk om een ​​zeer efficiënt en ergonomisch proces van computerondersteund ontwerpbeheer te organiseren. In het bijzonder wordt het mogelijk om een ​​dialooginteractie te implementeren tussen een ontwerper en een complex van technische CAD-middelen, dicht bij de natuurlijke spraakverzoek-antwoordontwerpmodus.

In de regel vereisen verzoeken om een ​​veralgemeend ontwerpalgoritme, zelfs op het niveau van ontwerpbewerkingen met hun tussenresultaten, de complexe implementatie van een verscheidenheid aan reken- en modelleringsprocedures, dwz de systemische activering van een aantal elementen en fragmenten van taalkundige en CAD-software. De talen van het besturingsgedeelte van de taalondersteuning moeten dus overeenkomen met een bepaald systeem aggregatie

... "Overweeg om te bouwen subsystemen CAD meteorologische ondersteuning (MP ... praktische oefeningen op discipline“Het concept van moderne... intellectueel data-analyse. intellectueel analyse, parallelle algoritmen, intellectueel ...