Simulatiediagrammen. Algemene kenmerken van de UML-taal. Algemene UML-mechanismen

UML is een uniforme grafische modelleringstaal voor het beschrijven, visualiseren, ontwerpen en documenteren van OO-systemen. UML is ontworpen om het proces van het modelleren van software op basis van de OO-benadering te ondersteunen, de relatie tussen conceptuele en programmaconcepten te organiseren en de problemen van het schalen van complexe systemen te weerspiegelen. UML-modellen worden gebruikt in alle stadia van de softwarelevenscyclus, van bedrijfsanalyse tot systeemonderhoud. Verschillende organisaties kunnen UML gebruiken zoals zij dat nodig achten, afhankelijk van hun probleemgebieden en de technologieën die zij gebruiken.

Een korte geschiedenis van UML

Halverwege de jaren negentig hadden verschillende auteurs enkele tientallen OO-modelleringsmethoden voorgesteld, die elk hun eigen grafische notatie gebruikten. Bovendien had elk van deze methoden zijn sterke punten, maar het maakte het niet mogelijk een voldoende compleet model van de PS op te bouwen, om het “van alle kanten” te laten zien, dat wil zeggen, van alle noodzakelijke projecties (zie artikel 1). Bovendien maakte het ontbreken van een OO-modelleringsstandaard het voor ontwikkelaars moeilijk om de meest geschikte methode te kiezen, wat de wijdverbreide adoptie van de OO-benadering van softwareontwikkeling verhinderde.

Op verzoek van de Object Management Group (OMG), de organisatie die verantwoordelijk is voor de adoptie van standaarden op het gebied van objecttechnologieën en databases, werd het urgente probleem van unificatie en standaardisatie opgelost door de auteurs van de drie meest populaire OO-methoden - G Butch, D. Rambo en A. Jacobson, die hun krachten bundelden, creëerden versie UML 1.1, die in 1997 door OMG als standaard werd goedgekeurd.

UML is een taal

Elke taal bestaat uit een woordenschat en regels voor het combineren van woorden om betekenisvolle constructies te creëren. Dit is met name hoe programmeertalen zijn gestructureerd, zoals UML. Het onderscheidende kenmerk is dat het taalwoordenboek wordt gevormd door grafische elementen. Aan elk grafisch symbool is een specifieke semantiek verbonden, zodat een model dat door de ene ontwikkelaar is gemaakt, duidelijk kan worden begrepen door een andere ontwikkelaar, evenals door een softwaretool die UML interpreteert. Hieruit volgt in het bijzonder dat een softwaremodel dat in UML wordt gepresenteerd, automatisch kan worden vertaald in een OO-programmeertaal (zoals Java, C++, VisualBasic), dat wil zeggen, als er een goed hulpmiddel voor visuele modellering bestaat dat UML ondersteunt, met het model heeft gebouwd, ontvangen we ook een voorbeeldprogrammacode die overeenkomt met dit model.

Benadrukt moet worden dat UML een taal is en geen methode. Er wordt uitgelegd uit welke elementen modellen moeten worden gemaakt en hoe ze moeten worden gelezen, maar er wordt niets gezegd over welke modellen moeten worden ontwikkeld en in welke gevallen. Om een methode op basis van UML te maken, is het noodzakelijk om deze aan te vullen met een beschrijving van het softwareontwikkelingsproces. Een voorbeeld van een dergelijk proces is het Rational Unified Process, dat in volgende artikelen zal worden besproken.

UML-woordenboek

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

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

Relatie laat verschillende verbindingen tussen entiteiten zien. UML definieert de volgende relatietypen:

Verslaving toont zo'n verband tussen twee entiteiten wanneer een verandering in een van hen - onafhankelijk - de semantiek van de andere - afhankelijke - kan beïnvloeden. Afhankelijkheid wordt weergegeven door een gestippelde pijl die van de afhankelijke entiteit naar de onafhankelijke entiteit wijst.
Vereniging is een structurele relatie die aantoont dat de objecten van de ene entiteit gerelateerd zijn aan de objecten van een andere. Grafisch wordt een associatie weergegeven als een lijn die de geassocieerde entiteiten verbindt. Associaties dienen om tussen objecten te navigeren. De koppeling tussen de klassen “Bestelling” en “Product” kan bijvoorbeeld worden gebruikt om enerzijds alle producten te vinden die in een specifieke bestelling zijn gespecificeerd, of anderzijds alle bestellingen te vinden die dit product bevatten. Het is duidelijk dat de overeenkomstige programma's een mechanisme moeten implementeren dat voor dergelijke navigatie zorgt. Als navigatie in slechts één richting vereist is, wordt dit aangegeven door een pijl aan het einde van de associatie. Een speciaal geval van associatie is aggregatie - een relatie van de vorm "geheel" - "deel". Grafisch wordt het geaccentueerd met een diamant aan het uiteinde nabij het essentie-geheel.
Generalisatie is de relatie tussen een bovenliggende entiteit en een onderliggende entiteit. In wezen weerspiegelt deze relatie de eigenschap van overerving voor klassen en objecten. De generalisatie wordt weergegeven als een lijn die eindigt met een driehoek die naar de bovenliggende entiteit is gericht. Het kind erft de structuur (attributen) en het gedrag (methoden) van de ouder, maar kan tegelijkertijd nieuwe structuurelementen en nieuwe methoden hebben. UML maakt meervoudige overerving mogelijk, waarbij een entiteit gerelateerd is aan meer dan één bovenliggende entiteit.
Uitvoering– de relatie tussen een entiteit die een specificatie van gedrag definieert (interface) met een entiteit die de implementatie van dit gedrag definieert (klasse, component). Deze relatie wordt vaak gebruikt bij het modelleren van componenten en zal in volgende artikelen gedetailleerder worden beschreven.

Diagrammen. UML biedt de volgende diagrammen:

Diagrammen die het gedrag van het systeem beschrijven:

Staatsdiagrammen
Activiteitendiagrammen,
Objectdiagrammen,
Volgordediagrammen,
Samenwerkingsdiagrammen;

Diagrammen die de fysieke implementatie van het systeem beschrijven:

Componentdiagrammen;
Implementatiediagrammen.

Modelbesturingsweergave. Pakketten.

We hebben al gezegd dat om een model goed te kunnen begrijpen door mensen, het noodzakelijk is om het hiërarchisch te organiseren, waarbij op elk niveau van de hiërarchie een klein aantal entiteiten overblijft. UML omvat een manier om een hiërarchische representatie van een model te organiseren: pakketten. Elk model bestaat uit een reeks pakketten die klassen, gebruiksscenario's en andere entiteiten en diagrammen kunnen bevatten. Een pakket kan andere pakketten bevatten, waardoor hiërarchieën kunnen worden gemaakt. UML biedt geen afzonderlijke pakketdiagrammen, maar deze kunnen wel in andere diagrammen voorkomen. Het pakket wordt afgebeeld als een rechthoek met een bladwijzer.

Wat UML biedt.

hiërarchische beschrijving van een complex systeem door pakketten te identificeren;
formalisering van functionele vereisten voor het systeem met behulp van het apparaat van use cases;
het detailleren van systeemvereisten door activiteitendiagrammen en scenario's te construeren;
het identificeren van dataklassen en het bouwen van een conceptueel datamodel in de vorm van klassendiagrammen;
het identificeren van klassen die de gebruikersinterface beschrijven en het creëren van een schermnavigatieschema;
beschrijving van de interactieprocessen van objecten bij het uitvoeren van systeemfuncties;
beschrijving van objectgedrag in de vorm van activiteiten- en toestandsdiagrammen;
beschrijving van softwarecomponenten en hun interactie via interfaces;
beschrijving van de fysieke architectuur van het systeem.

En het laatste...

Ondanks alle aantrekkelijkheid van UML zou het moeilijk zijn om het in echte softwaremodellering te gebruiken zonder visuele modelleringstools. Met dergelijke tools kunt u snel diagrammen op het beeldscherm presenteren, deze documenteren, programmacodesjablonen genereren in verschillende OO-programmeertalen en databaseschema's maken. De meeste daarvan omvatten de mogelijkheid om programmacodes opnieuw te ontwerpen - het herstellen van bepaalde projecties van het softwaremodel door automatisch de broncodes van programma's te analyseren, wat erg belangrijk is om de overeenstemming tussen het model en de codes te garanderen en bij het ontwerpen van systemen die de functionaliteit van voorgaande systemen overnemen.

11.1. Structuur van de uniforme modelleringstaal

Uniforme modelleringstaal (UML) is momenteel de de facto standaard voor het beschrijven (documenteren) van de resultaten van het ontwerp en de ontwikkeling van objectgeoriënteerde systemen. De ontwikkeling van UML begon in 1994 door Grady Booch en James Rumbaugh, die bij Rational Software werkten. In de herfst van 1995 voegde Ivar Jacobson zich bij hen en in oktober van hetzelfde jaar werd een voorlopige versie 0.8 van de Unified Method uitgebracht. Sinds die tijd zijn er verschillende versies van de UML-specificatie uitgebracht, waarvan er twee een internationale standaardstatus hebben:

UML 1.4.2 – "ISO/IEC 19501:2005. Informatietechnologie. Open gedistribueerde verwerking. Unified modelleringstaal (UML). Versie 1.4.2" (eng. "Informatietechnologie. Open gedistribueerde verwerking. Unified modelleringstaal (UML). Versie 1.4.2");

UML 2.4.1 - "ISO/IEC 19505-1:2012. Informatietechnologie. Object Management Group Unified Modeling Language (OMG UML). Deel 1. Infrastructuur" (eng. "Informatietechnologie - Object Management Group Unified Modeling Language (OMG UML) - Deel 1: Infrastructuur") en "ISO/IEC 19505-2:2012 Informatietechnologie. Unified Modeling Language for Object Management Group (OMG UML) Deel 2. Bovenbouw" (eng. "Informatietechnologie - Object"). Management Group Unified Modeling Language (OMG UML) - Deel 2: Bovenbouw").

De nieuwste officiële taalspecificatie is te vinden op www.omg.org.

De algemene structuur van UML wordt weergegeven in de volgende afbeelding.

Rijst. 11.1. UML-structuur

11.2. UML-semantiek en syntaxis

Semantiek - een tak van de taalkunde die de betekenis van taaleenheden bestudeert, voornamelijk de woorden en zinnen.

Syntaxis – manieren om woorden en hun vormen te combineren tot zinsneden en zinnen, zinnen te combineren tot complexe zinnen, manieren om uitspraken te creëren als onderdeel van een tekst.

Met betrekking tot UML bepalen semantiek en syntaxis dus de presentatiestijl (modelbouw), die natuurlijke en formele talen combineert om basisconcepten (modelelementen) en mechanismen voor hun uitbreiding weer te geven.

11.3. UML-notatie

Notatie is een grafische interpretatie van semantiek vanwege de visuele weergave ervan.

UML definieert er drie entiteitstype :

Structureel - een abstractie die een weerspiegeling is van een conceptueel of fysiek object;

Groeperen – een element dat wordt gebruikt voor een semantische combinatie van diagramelementen;

Verklarend (annotatief) – een commentaar op een diagramelement.

De volgende tabel geeft een korte beschrijving van de belangrijkste entiteiten die in grafische notatie worden gebruikt en de belangrijkste manieren om deze weer te geven.

Tabel 11.1. Entiteiten

Type	Naam	Aanduiding	Definitie (semantiek)
Structureel	(klas)		Een reeks objecten die een gemeenschappelijke structuur en gedrag delen
	(voorwerp)		Een abstractie van een echte of ingebeelde entiteit met duidelijk gedefinieerde conceptuele grenzen, persoonlijkheid, toestand en gedrag. Vanuit UML-oogpunt zijn objecten instanties van een klasse (instanties van een entiteit)
	(acteur)	Ingenieur pad diensten	Een entiteit buiten het systeem die met het systeem interageert en de functionaliteit ervan gebruikt om bepaalde doelen te bereiken of specifieke problemen op te lossen. Een actor is dus een externe bron of ontvanger van informatie
	(gebruiksscenario)		Beschrijving van de acties die door het systeem worden uitgevoerd, wat leidt tot een significant resultaat voor de actor
	(staat)		Een beschrijving van een moment in het leven van een entiteit waarop deze aan een bepaalde voorwaarde voldoet, een activiteit uitvoert of wacht op een bepaalde gebeurtenis.
	Samenwerking (samenwerking)		Beschrijving van een reeks voorbeelden van actoren, objecten en hun interactie tijdens het oplossen van een bepaald probleem
	(onderdeel)		Het fysieke deel van het systeem (bestand), inclusief systeemmodules die zorgen voor de implementatie van een consistente set interfaces
	(interface)	iBerekening	Een reeks bewerkingen die een service (set services) definieert die door een klasse of component wordt geleverd
	(knooppunt)		Het fysieke deel van het systeem (computer, printer, enz.) dat middelen levert om een probleem op te lossen
Groepering	(pakket)		Algemeen mechanisme voor het groeperen van elementen. In tegenstelling tot een component is een pakket een puur conceptueel (abstract) concept. Speciale gevallen van een pakket zijn systeem en model
	(fragment)		Het gebied van specifieke interactie tussen actorinstanties en objecten
	(activiteitenpartitie)		Een groep bewerkingen (verantwoordelijkheidsgebied) uitgevoerd door één entiteit (actor, object, component, knooppunt, enz.)
	(onderbreekbare activiteitsregio)		Een groep bewerkingen waarvan de normale uitvoeringsvolgorde kan worden onderbroken als gevolg van het optreden van een ongebruikelijke situatie
Verklarend	Opmerking (opmerking)		Opmerking voor het element. Wordt met een stippellijn aan het commentaarelement gekoppeld

Sommige bronnen, met name [,], identificeren ook gedragsentiteiten interactie En eindige toestandsmachines, maar vanuit logisch oogpunt moeten ze worden geclassificeerd als diagrammen.

Sommige van de bovengenoemde entiteiten impliceren hun gedetailleerde beschrijving in decompositiediagrammen. In het diagram op het hoogste niveau zijn ze gemarkeerd met een speciaal pictogram of label.

De volgende tabel geeft een beschrijving van alle typen betrekkingen UML gebruikt in diagrammen om relaties tussen entiteiten aan te geven.

Tabel 11.3. Relatie

Naam	Aanduiding	Definitie (semantiek)
Vereniging		Een relatie die een betekenisvolle verbinding tussen twee of meer entiteiten beschrijft. Het meest algemene type relatie
Aggregatie		Een subtype van associatie dat de relatie ‘deel’ – ‘geheel’ beschrijft, waarbij het ‘deel’ afzonderlijk van het ‘geheel’ kan bestaan. De ruit wordt aangegeven vanaf de “hele” kant. De relatie wordt alleen gespecificeerd tussen entiteiten van hetzelfde type
Samenstelling		Een subtype van aggregatie waarbij de ‘delen’ niet los van het ‘geheel’ kunnen bestaan. In de regel worden ‘delen’ gelijktijdig met het ‘geheel’ gemaakt en vernietigd
Afhankelijkheid		Een relatie tussen twee entiteiten waarin een verandering in de ene entiteit (de onafhankelijke) de toestand of het gedrag van de andere entiteit (de afhankelijke) kan beïnvloeden. De pijlzijde geeft een onafhankelijke entiteit aan
Generalisatie		De relatie tussen een gegeneraliseerde entiteit (voorouder, ouder) en een gespecialiseerde entiteit (afstammeling, dochter). De driehoek wordt aangegeven vanaf de kant van de ouder. De relatie wordt alleen gespecificeerd tussen entiteiten van hetzelfde type
Realisatie		Een relatie tussen entiteiten waarbij de ene entiteit een actie specificeert die een andere entiteit op zich neemt om uit te voeren. Relaties worden in twee gevallen gebruikt: tussen interfaces en klassen (of componenten), tussen use cases en samenwerkingen. De pijlzijde geeft de entiteit aan die de actie definieert (interface of use case)

Voor associatie kunnen aggregatie en samenstelling worden gespecificeerd veelheid (eng. multipliciteit), dat het totale aantal instanties van entiteiten karakteriseert die aan de relatie deelnemen. Het wordt meestal aangegeven aan elke kant van de relatie, vlakbij de corresponderende entiteit. De veelheid kan op de volgende manieren worden aangegeven:

- * – elk aantal exemplaren, inclusief geen;

Niet-negatief geheel getal – de veelheid ligt strikt vast en is gelijk aan het opgegeven getal (bijvoorbeeld: 1, 2 of 5);

Bereik van niet-negatieve gehele getallen "eerste getal.. tweede getal" (bijvoorbeeld: 1..5, 2..10 of 0..5);

Een reeks getallen vanaf een specifieke beginwaarde tot een willekeurig uiteindelijk "eerste getal..*" (bijvoorbeeld: 1..*, 5..* of 0..*);

Lijst met niet-negatieve gehele getallen en bereiken, gescheiden door komma's (bijvoorbeeld: 1, 3..5, 10, 15..*).

Als de veelheid niet is gespecificeerd, wordt ervan uitgegaan dat de waarde 1 is. Er wordt altijd aangenomen dat de veelheid aan entiteitsinstanties die deelnemen aan afhankelijkheid, generalisatie en implementatie 1 is.

De volgende tabel geeft een beschrijving uitbreidingsmechanismen , gebruikt om de semantiek van entiteiten en relaties te verduidelijken. Over het algemeen bestaat het uitbreidingsmechanisme uit een reeks tekst tussen haakjes of aanhalingstekens.

Tabel 11.4. Uitbreidingsmechanismen

Naam	Aanduiding	Definitie (semantiek)
Stereotype (stereotype)	« »	Een aanduiding die de semantiek van een notatie-element specificeert (bijvoorbeeld: een afhankelijkheid met het stereotype 'include' wordt beschouwd als een inclusierelatie, en een klasse met het stereotype 'boundary' is een grensklasse)
Bewakingstoestand (bewakingstoestand)		Booleaanse voorwaarde (bijvoorbeeld: of [identificatie voltooid])
Beperking (beperking)	{ }	Een regel die de semantiek van een modelelement beperkt (bijvoorbeeld (uitvoeringstijd minder dan 10 ms))
Gemarkeerde waarde (getagde waarde)	{ }	Nieuwe of verduidelijkende eigenschap van een notatie-element (bijvoorbeeld: (versie = 3.2))

Naast stereotypen die worden aangegeven als een reeks tekst tussen aanhalingstekens, kunnen grafische stereotypen in diagrammen worden gebruikt. De volgende afbeelding toont voorbeelden van standaard- en stereotiepe weergave.


a) standaardaanduiding		b) standaardaanduiding met tekststereotype		c) grafisch stereotype

Rijst. 11.2. Voorbeelden van standaard- en stereotiepe klassenweergave

Diagram is een groep notatie-elementen om een bepaald aspect van het informatiesysteem dat wordt ontwikkeld weer te geven. Diagrammen zijn meestal een samenhangende grafiek waarin entiteiten hoekpunten zijn en relaties bogen. De volgende tabel geeft een korte beschrijving van UML-diagrammen.

Tabel 11.5. Diagrammen

Diagram			Doel
				afhankelijk van de mate van fysieke implementatie	door dynamiek weer te geven	per weergegeven aspect
(gebruiksscenario)			Geeft systeemfuncties, interacties tussen actoren en functies weer	Logisch	Statisch	Functioneel
(klas)			Geeft een reeks klassen, interfaces en relaties daartussen weer	Logisch of fysiek	Statisch	Functioneel en informatief
(pakket)			Geeft een reeks pakketten weer en de relaties daartussen	Logisch of fysiek	Statisch	Onderdeel
Gedrag (gedrag)	(staatsmachine)		Toont de toestanden van een entiteit en de overgangen daartussen tijdens de levenscyclus ervan	Logisch	Dynamisch	Gedragsmatig
	(activiteit)		Geeft bedrijfsprocessen in het systeem weer (beschrijving van gedragsalgoritmen)
	Interacties (interactie)	(reeks)	Toont de volgorde waarin berichten tussen objecten en acteurs worden doorgegeven
		(mededeling)	Vergelijkbaar met een sequentiediagram, maar de nadruk ligt op de structuur van interacties tussen objecten
Implementaties (uitvoering)	(onderdeel)		Geeft systeemcomponenten (programma's, bibliotheken, tabellen, enz.) en verbindingen daartussen weer	Fysiek	Statisch	Onderdeel
	(inzet)		Toont de plaatsing van componenten op netwerkknooppunten, evenals de configuratie ervan

De UML 2.x-standaard definieert ook aanvullende, zeer gespecialiseerde diagrammen:

Objectdiagram - vergelijkbaar, maar objecten worden weergegeven in plaats van klassen;

Timingdiagram - beschrijft de toestand van een object in de loop van de tijd;

Samengesteld structuurdiagram - beschrijft de poorten (inclusief interfaces) van een klasse voor interactie met andere klassen;

Profieldiagram - vergelijkbaar met een beschrijving van de klassen die daarin zijn opgenomen;

Interactieoverzichtsdiagram - vergelijkbaar, maar met verborgen interactiefragmenten (fragmenten met het label ref). Vertegenwoordigt een contextueel (conceptueel) aspect, waarvan de elementen zullen worden gespecificeerd in afzonderlijke decompositiediagrammen.

Met het oog op een uitgebreide conceptuele representatie van de interne architectuur van het systeem, staat de meerderheid tijdens de constructie het gebruik toe van gevestigde grafische stereotypen voor de zogenaamde. Zo'n diagram heet 1, maar behoort niet tot de lijst met diagrammen gedefinieerd door de UML-standaard.

Bij het ontwikkelen van een afzonderlijk model van een systeem worden verschillende soorten diagrammen gebouwd. Bovendien worden bij het ontwikkelen van een model van een complex systeem in de regel meerdere diagrammen van hetzelfde type geconstrueerd. Tegelijkertijd hoeft u geen afzonderlijke typen diagrammen te maken als dat niet nodig is. Diagrammen zijn bijvoorbeeld uitwisselbaar; ze zijn alleen gebouwd voor objecten met complex gedrag. De volgende tabel geeft aanbevelingen over de noodzaak om diagrammen voor systeemmodellen te ontwikkelen (verduidelijken).

Tabel 11.6. Relatie tussen modellen en diagrammen

In de onderstaande tabel is het testmodel niet weergegeven, omdat bij de constructie ervan geen diagrammen worden ontwikkeld, maar gecontroleerd (getest) op volledigheid en consistentie.

Sommige diagrammen vereisen na hun constructie ontwikkeling en verduidelijking als onderdeel van de ontwikkeling van het volgende model (technologisch proces). Ze moeten dus bijvoorbeeld tijdens de ontwikkeling worden verduidelijkt. Bij modellen.

4. Definieer het concept " ".

UML-model(UML-model) is een verzameling van een eindige reeks taalconstructies, waarvan de belangrijkste entiteiten en relaties daartussen zijn.

De modelentiteiten en relaties zelf zijn voorbeelden van metamodel-metaklassen.

Als we het UML-model vanuit de meest algemene posities bekijken, kunnen we zeggen dat het een grafiek is (meer precies, een geladen multi-pseudo-hyper-digraph), waarin hoekpunten en randen worden geladen met aanvullende informatie en een complexe interne structuur kunnen hebben. . De hoekpunten van deze grafiek worden entiteiten genoemd, en de randen worden relaties genoemd.. De rest van deze sectie biedt een snel (voorlopig) maar volledig overzicht van de beschikbare entiteitstypen en relaties. Gelukkig zijn het er niet al te veel. In de volgende hoofdstukken van het boek worden alle entiteiten en relaties opnieuw onderzocht, gedetailleerder en met voorbeelden.

1.4.1. Entiteiten

Voor het overzicht kunnen entiteiten in UML in vier groepen worden verdeeld:

structureel;
gedragsmatig;
groepering;
annotatief.

Structurele entiteiten zijn, zoals je misschien wel vermoedt, bedoeld om structuur te beschrijven. Typisch omvatten structurele entiteiten het volgende.

Voorwerp(object) 1 – een entiteit die uniek is en staat en gedrag inkapselt.

Klas(klasse) 2 – beschrijving van een reeks objecten met gemeenschappelijke attributen die de status definiëren en bewerkingen die gedrag definiëren.

Interface(interface) 3 - een benoemde reeks bewerkingen die een reeks services definieert die door een consument kunnen worden aangevraagd en door een serviceprovider kunnen worden geleverd.

Samenwerking(samenwerking) 4 - een verzameling objecten die samenwerken om een bepaald doel te bereiken.

Karakter(actor) 5 – een entiteit die zich buiten het gemodelleerde systeem bevindt en er rechtstreeks mee interageert.

∇ Zo’n relatie bestaat zeker, wat tot uiting komt in Fig. Hiërarchie van diagramtypen voor UML 1 als een afhankelijkheidsrelatie met het stereotype ‘verfijnen’.

∇∇ In UML 1 ontstond er een onvrijwillige associatie tussen het samenwerkingsdiagram en de entiteit met dezelfde naam, wat niet helemaal waar was en soms misleidend was.

∇∇∇ In UML 2 is de syntactische en semantische lading van het toestandsdiagram zo sterk veranderd dat de naam niet langer de inhoud weerspiegelt.

Hieronder vindt u een lijst met nieuwe diagrammen en hun namen die in dit boek zijn overgenomen.

Samengesteld structuurdiagram
Pakketdiagram
Staatsmachinediagram
Communicatiediagram
Interactieoverzichtsdiagram
Timingdiagram

In afb. Hiërarchie van diagramtypen voor UML 2 (deel 1 en 2) Er is een klassendiagram beschikbaar dat de relatie tussen diagrammen in UML 2 laat zien.

Verderop in dit hoofdstuk zullen we alle dertien canonieke diagrammen heel kort beschrijven, zodat we enige context en woordenschat hebben voor wat volgt. Details worden gegeven in de overige hoofdstukken van het boek.

Maar voordat we naar de volgende sectie gaan, maken we een kleine uitweiding over hoe de standaard vereist dat diagrammen worden ontworpen. Hieronder wordt een algemeen diagrampresentatiesjabloon weergegeven.

Er zijn twee belangrijke ontwerpelementen: een buitenframe en een label met de naam van het diagram. Als alles eenvoudig is met het frame - het is een rechthoek die het gebied beperkt waarin de diagramelementen zich moeten bevinden, dan wordt de naam van het diagram in een speciaal formaat geschreven, weergegeven in Fig. Notatie voor diagrammen.

Deze complexe labelvorm wordt niet door alle tools ondersteund. Dit is echter niet nodig, aangezien de semantiek primair is en de notatie secundair. In wat volgt gebruiken we overal een rechthoek als kaartlabel, en dit mag geen verwarring veroorzaken.

Mogelijke tags (typen) voor diagrammen worden weergegeven in de volgende tabel. De tags die door de standaard worden voorgesteld, worden in de tweede kolom geschreven. Zoals de praktijk heeft geleerd, zijn de door de standaard voorgestelde regels echter niet altijd handig en logisch gerechtvaardigd. Daarom bevat de derde kolom van de tabel een naar onze mening redelijk alternatief.

Tafel Grafiektypen en tags

Titel van diagram	Label (standaard)	Tag (voorgesteld)
Gebruiksdiagram	gebruiksgeval of uc	gebruiksgeval
Klassendiagram	klas	klas
Machinediagram	staatsmachine of stm	staatsmachine
Activiteitendiagram	activiteit of handeling	activiteit
Volgordediagram	interactie of SD	SD
Communicatiediagram	interactie of SD	comm
Componentdiagram	bestanddeel of cmp	bestanddeel
Plaatsingsdiagram	niet gedefinieerd	inzet
Objectdiagram	niet gedefinieerd	voorwerp
Intern structuurdiagram	klas	klas of bestanddeel
Overzichtsdiagram interactie	interactie of SD	interactie
Timingdiagram	interactie of SD	timing
Pakketdiagram	pakket of pakket	pakket

UML of Unified Modeling Language is een grafische beschrijvingstaal voor objectmodellering op het gebied van softwareontwikkeling. Maar het gebruik van UML beperkt zich niet tot IT; een ander groot gebied van praktische toepassing van UML is het modelleren van bedrijfsprocessen, systeemontwerp en het in kaart brengen van organisatiestructuren.

Met UML kunnen softwareontwikkelaars overeenstemming bereiken over grafische notaties om gemeenschappelijke concepten weer te geven en zich te concentreren op ontwerp en ontwikkeling.

UML gebruikt grafische notaties voor de elementen van het systeem dat wordt gemodelleerd, en UML-diagrammen zijn redelijk eenvoudig te begrijpen;
UML maakt het mogelijk om systemen vanuit vrijwel alle mogelijke invalshoeken te beschrijven, rekening houdend met diverse aspecten;
UML is objectgeoriënteerd: de analyse- en constructiemethoden liggen semantisch dicht bij de programmeermethoden die in moderne OOP-talen worden gebruikt;
UML is een open standaard. De standaard ontwikkelt en evolueert van versie tot versie en voldoet aan de modernste eisen voor het beschrijven van systemen;
bevat een uitbreidingsmechanisme waarmee u extra tekst- en grafische typen kunt invoeren, waardoor UML niet alleen op IT-gebied kan worden gebruikt.

UML-diagramtypen

Er zijn 14 soorten diagrammen in UML. Ze kunnen worden onderverdeeld in 2 categorieën:

structureel, die de informatiestructuur vertegenwoordigt;
gedragsmatig, die het gedrag van het systeem en verschillende aspecten van interacties vertegenwoordigt. Er wordt gekeken naar een apart subtype gedragsdiagrammen interactiediagrammen.

Hiërarchie van UML-diagramtypen,
weergegeven door een klassendiagram

Structuurdiagrammen

Klassendiagram is een sleutelelement in objectgeoriënteerde modellering. Met behulp van dit diagram (eigenlijk via klassen, hun attributen, methoden en afhankelijkheden tussen klassen) beschrijft het domeinmodel en de structuur van het gemodelleerde systeem.
Componentdiagram toont de verdeling van programmacode in grote blokken (structurele componenten) en shows afhankelijkheden tussen hen. Componenten kunnen pakketten, modules, bibliotheken, bestanden, enz. zijn.
Objectdiagram toont een volledig of gedeeltelijk segment van het gesimuleerde systeem op een bepaald tijdstip. Het vertegenwoordigt klasse-instanties (objecten), hun status (huidige attribuutwaarden) en de relaties daartussen.
Samengesteld structuurdiagram demonstreert de interne structuur van klassen en, waar mogelijk, de interacties tussen elementen van deze structuur.
Pakketdiagram toont pakketten en relaties daartussen. Dit type diagram dient om de structuur van het model te vereenvoudigen (en er dienovereenkomstig mee te werken) door modelelementen volgens bepaalde criteria in groepen te combineren.
Implementatiediagram modelleert de inzet van softwarecomponenten ( artefacten) over computerbronnen/hardwarecomponenten ( knooppunten).
Profieldiagram beschrijft een uitbreidingsmechanisme waarmee UML kan worden aangepast aan een verscheidenheid aan vakgebieden en industrieën.

Voorbeeld van een UML-klassediagram

Gedragsdiagrammen

Activiteitendiagram toont acties ( acties) waaruit enige activiteit bestaat ( activiteit). Activiteitendiagrammen worden gebruikt om bedrijfsprocessen, technologische processen en sequentieel en parallel computergebruik te modelleren.
Use case-diagram(of use-case-diagram) beschrijft de relatie tussen actoren (actoren) en gebruiksscenario's van het gemodelleerde systeem (de mogelijkheden ervan).
Het belangrijkste doel van het diagram is om een universeel hulpmiddel te zijn voor klanten, ontwikkelaars en eindgebruikers om gezamenlijk het systeem, de mogelijkheden en het gedrag ervan, te bespreken. Staatsdiagram
Communicatiediagram toont het dynamische gedrag van een entiteit en laat zien hoe deze entiteit, afhankelijk van de huidige toestand, op verschillende gebeurtenissen reageert. Dit is in wezen een toestandsdiagram uit de atoomtheorie.(in eerdere versies
Volgordediagram samenwerkingsdiagram
) toont de interacties tussen de delen van de composietstructuur en de rollen van samenwerking. Het diagram geeft expliciet de relaties tussen elementen (objecten) aan. gebruikt om de volgorde van objectinteracties te visualiseren. Toont de levenscyclus van een bepaald object en de interactie van actoren (actoren) binnen een bepaalde use case, de volgorde van berichten die zij uitwisselen.
Timingdiagram Overzichtsdiagram interactie

omvat een deel van het sequentiediagram en het ontwerp van de besturingsstroom. Helpt de interactie van objecten vanuit verschillende gezichtspunten te bekijken.- een apart subtype van interactiediagrammen gespecialiseerd in timing. Dit soort diagrammen worden gebruikt om het gedrag van objecten over een bepaalde periode te bestuderen.

UML (Unified Modeling Language) is een grafische beschrijvingstaal voor objectmodellering op het gebied van softwareontwikkeling. UML is een algemene taal, een open standaard die grafische notatie gebruikt om een abstract model van een systeem te maken, een zogenaamde UML-model. UML is gemaakt om voornamelijk softwaresystemen te definiëren, visualiseren, ontwerpen en documenteren. UML is geen programmeertaal, maar het genereren van code is mogelijk in de middelen voor het uitvoeren van UML-modellen als geïnterpreteerde code.

Wikipedia

Commerciële producten

Microsoft Visio

Type: commerciële software

Een populair softwareproduct van Microsoft waarmee u rijke diagrammen kunt tekenen, inclusief UML: is een gratis programma waarmee u eerder gemaakte Visio-diagrammen kunt bekijken. U kunt downloaden op %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.

%0A

Microsoft%20Visueel%20Studio%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modellering,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Volgorde%20Diagram%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Gebruik%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visueel%20Studio%202010:

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Visualisatie%20en%20Model%20Eigenschap%20Pakket%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:

%0A

%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2
%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0
%D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202,1
%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20laag%20diagrammen%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20laag%20diagrammen

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Visualisatie%20en%20Model%20Eigenschap%20Pakket%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20 http://msdn.microsoft.com/ru-ru/vstudio/ff655021%28en-us%29.aspx.

IBM Rationele Roos

Mogelijkheden:

Use case-diagram;
Implementatiediagram (topologiediagrammen);
Staatskaartdiagram;
Activiteitendiagram;
Interactiediagram;
Volgordediagram;
Samenwerkingsdiagram;
Klassendiagram;
Componentdiagram.

Schermafbeeldingen:

Open source-programma's

SterUML

Mogelijkheden:

UML 2.0-ondersteuning
MDA (modelgestuurde architectuur)
Plug-in-architectuur (u kunt schrijven in COM-compatibele talen: C++, Delphi, C#, VB, ...)

StarUML is voornamelijk in Delphi geschreven, maar componenten kunnen ook in andere talen worden geschreven, bijvoorbeeld C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Hieronder vindt u enkele schermafbeeldingen.

Klassendiagram: