Een ontwerptool (UML) selecteren. UML-klassediagrammen

UML-- taal grafische beschrijving voor objectmodellering in ontwikkeling software. UML is een algemene taal, dat is het open standaard, dat grafische notatie gebruikt om een abstract model te creëren van een systeem dat een UML-model wordt genoemd. 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.

Het gebruik van UML beperkt zich niet tot softwaremodellering. Het wordt ook gebruikt voor het modelleren van bedrijfsprocessen, systeemontwerp en het in kaart brengen van organisatiestructuren.

Met UML kunnen softwareontwikkelaars ook overeenstemming bereiken over grafische symbolen om algemene concepten te introduceren (zoals klasse, component, generalisatie, aggregatie en gedrag), en zich meer te concentreren op ontwerp en architectuur.

UML is een visuele modelleringstaal voor algemene doeleinden die is ontworpen voor het specificeren, visualiseren, ontwerpen en documenteren van softwarecomponenten, bedrijfsprocessen en andere systemen. De UML-taal is zowel een eenvoudige als krachtige modelleringstool die effectief kan worden gebruikt om conceptuele, logische en grafische modellen te bouwen complexe systemen voor verschillende doeleinden. Deze taal is geabsorbeerd beste kwaliteit methoden software-engineering, die overal met succes zijn gebruikt de afgelopen jaren bij het modelleren van grote en complexe systemen.

De UML-taal is gebaseerd op een aantal basisconcepten die kunnen worden geleerd en toegepast door de meeste programmeurs en ontwikkelaars die bekend zijn met objectgeoriënteerde analyse- en ontwerptechnieken. Tegelijkertijd basisconcepten kan zodanig worden gecombineerd en uitgebreid dat objectmodelbouwers zelfstandig modellen kunnen ontwikkelen van grote en complexe systemen in een grote verscheidenheid aan toepassingsgebieden.

Visuele modellering in UML kan worden weergegeven als een proces van niveau-voor-niveau afdaling van het meest algemene en abstracte conceptuele model origineel systeem naar logisch, en dan naar fysiek model gepast softwaresysteem. Om deze doelen te bereiken wordt eerst een model gebouwd in de vorm van een zogenaamd use case diagram, waarin het functionele doel van het systeem wordt beschreven, oftewel wat het systeem gaat doen tijdens zijn werking. Een use case-diagram is de initiële conceptuele representatie of het conceptuele model van een systeem tijdens het ontwerp- en ontwikkelingsproces.

Het ontwikkelen van een use case-diagram heeft de volgende doelstellingen:

Definieer de algemene grenzen en context van de simulatie vakgebied op beginfasen systeemontwerp;

Formuleren algemene eisen op het functionele gedrag van het ontworpen systeem;

Ontwikkel het origineel conceptueel model systemen voor de daaropvolgende detaillering ervan in de vorm van logische en fysieke modellen;

Bereid de initiële documentatie voor voor de interactie van systeemontwikkelaars met zijn klanten en gebruikers.

De essentie van dit diagram is als volgt: het ontworpen systeem wordt weergegeven als een reeks entiteiten of actoren die met het systeem interageren met behulp van zogenaamde use cases. In dit geval is een actor of actor elke entiteit die van buitenaf met het systeem interageert. Het zou een persoon kunnen zijn technisch apparaat, programma of enig ander systeem dat als bron van invloed kan dienen op het gesimuleerde systeem zoals bepaald door de ontwikkelaar zelf. Een use case dient op zijn beurt om de diensten te beschrijven die het systeem aan de actor levert. Met andere woorden: elke use case definieert een bepaalde reeks acties die door het systeem worden uitgevoerd tijdens een dialoog met de actor. Er wordt echter niets gezegd over de manier waarop de interactie van actoren met het systeem zal worden geïmplementeerd.

Een sequentiediagram is een diagram van interacties dat zich richt op de temporele volgorde van berichten. Grafisch gezien is zo'n diagram een tabel waarin objecten zich langs de X-as bevinden, en berichten in oplopende volgorde van tijd langs de Y-as. Een samenwerkingsdiagram is een interactiediagram dat zich richt op structurele organisatie objecten die berichten ontvangen en verzenden. Grafisch gezien is zo'n diagram een grafiek van hoekpunten en randen.

Volgordediagrammen hebben twee kenmerken die hen onderscheiden van samenwerkingsdiagrammen.

Ten eerste laten ze de levenslijn van het object zien. Dit is een verticale stippellijn die het bestaan van een object in de tijd weergeeft. De meeste objecten die in het interactiediagram worden weergegeven, bestaan gedurende de hele interactie, dus worden ze bovenaan het diagram weergegeven en worden hun levenslijnen van boven naar beneden getekend. Tijdens interacties kunnen ook objecten worden gemaakt. De levenslijnen van dergelijke objecten beginnen met het ontvangen van een bericht met het gecreëerde stereotype. Objecten kunnen ook worden vernietigd tijdens interacties; in dit geval eindigen hun levenslijnen met het ontvangen van een bericht met het vernietigingsstereotype, en wordt het visuele beeld gebruikt hoofdletter X, wat het einde van de levensduur van het object aangeeft.

Het tweede kenmerk van deze diagrammen is de focus van controle. Het wordt weergegeven als een langwerpige rechthoek die de tijdsperiode aangeeft waarin een object een actie uitvoert, direct of via een ondergeschikte procedure. De bovenrand van de rechthoek is uitgelijnd langs de tijdas met het moment waarop de actie begint, de onderrand is uitgelijnd met het moment waarop deze eindigt (en kan worden gemarkeerd met een retourbericht). Het nesten van de besturingsfocus, veroorzaakt door recursie (dat wil zeggen het aanroepen van zijn eigen bewerking) of een terugroep van een ander object, kan worden weergegeven door een andere besturingsfocus iets rechts van zijn ouder te plaatsen (nesten van willekeurige diepte is toegestaan). Als u de locatie van de besturingsfocus met maximale precisie wilt aangeven, kunt u het gebied van de rechthoek arceren dat overeenkomt met de tijd waarin de methode daadwerkelijk werkt en de besturing niet overdraagt aan een ander object.

Een klassendiagram is een diagram dat veel klassen, interfaces, samenwerkingen en relaties daartussen weergeeft. Het wordt afgebeeld als vele hoekpunten en bogen.

Klassendiagrammen komen vaker voor bij het modelleren van objectgeoriënteerde systemen. Dergelijke diagrammen tonen veel klassen, interfaces, samenwerkingen en relaties daartussen.

Klassendiagrammen worden gebruikt om de statische weergave van een systeem vanuit ontwerpperspectief te modelleren. Dit omvat grotendeels het modelleren van de woordenschat, samenwerkingen en circuits van het systeem. Bovendien vormen klassendiagrammen de basis van nog twee diagrammen: componenten en implementatie.

Klassendiagrammen zijn belangrijk voor meer dan alleen visualisatie, specificatie en documentatie structurele modellen, maar ook voor forward en reverse engineering van uitvoerbare systemen.

Activiteitendiagrammen zijn een van de vijf soorten diagrammen die in UML worden gebruikt om de dynamische aspecten van systeemgedrag te modelleren. Een activiteitendiagram is in wezen een stroomdiagram dat laat zien hoe de controlestroom van de ene activiteit naar de andere gaat.

Het samenwerkingsdiagram richt zich op de organisaties van objecten die deelnemen aan de interactie. Om een samenwerkingsdiagram te maken, moet u de objecten die aan de interactie deelnemen, rangschikken in de vorm van hoekpunten van een grafiek. Vervolgens worden de verbindingen die deze objecten verbinden, weergegeven als bogen in deze grafiek. Ten slotte worden verbindingen aangevuld met berichten die objecten ontvangen en verzenden. Dit geeft de gebruiker duidelijkheid visuele representatie over de stroom van controle in de context van de structurele organisatie van samenwerkende objecten.

Een componentdiagram toont een reeks componenten en de relaties daartussen. Grafisch wordt het componentendiagram weergegeven als een grafiek met randen en hoekpunten.

Een implementatiediagram toont de configuratie van de verwerkingsknooppunten waarop het systeem draait en de componenten die zich op deze knooppunten bevinden. Het implementatiediagram wordt weergegeven als een grafiek met randen en hoekpunten.

Toestandsdiagrammen zijn een van de vijf soorten diagrammen in UML die worden gebruikt om de dynamische aspecten van een systeem te modelleren. Het statusdiagram toont de machine. De bijzondere variant ervan is het activiteitendiagram, waarin alle of de meeste toestanden activiteitstoestanden zijn, en alle of de meeste overgangen worden geïnitieerd als resultaat van de voltooiing van de activiteit in originele staat. Dus bij het modelleren levenscyclus Zowel activiteitendiagrammen als toestandsdiagrammen zijn nuttig. Maar terwijl een activiteitendiagram de controlestroom van activiteit naar activiteit laat zien, toont een toestandsdiagram de controlestroom van staat naar staat.

Visuele studio 2010 Ultimate biedt genoeg handige functies voor reverse-engineering. Met behulp van Visual Studio-tools kunnen we een UML-model bouwen op basis van bestaande code en begrijpen hoe alles eigenlijk werkt, maar zonder een enorme inspanning te leveren om diagrammen handmatig te maken en up-to-date te houden.

Alles zou in orde zijn, maar deze tool mist volledig de mogelijkheid om het model met de code te synchroniseren. Dat wil zeggen dat we na het wijzigen van het model de klassen handmatig moeten wijzigen. In het geval dat grote hoeveelheid kleine veranderingen blijken behoorlijk lastig te zijn, en om deze reden wordt volwaardige modellering vaak verlaten.

Microsoft heeft onlangs een add-on uitgebracht voor genaamd Microsoft Visual Studio 2010 Functiepakket 2. Dit hulpmiddel geeft ons een geweldige kans om modelwijzigingen in code te synchroniseren. Ik zal je kort vertellen hoe je dit kunt gebruiken.

Laten we bijvoorbeeld zeggen dat we een primitieve blog hebben. Het vakgebied wordt vertegenwoordigd door twee klassen: Auteur en Artikel. We voegen een nieuw modelleringsproject toe aan de oplossing. We maken er een UML Class Diagram in.

Laten we profiteren van de mogelijkheden van Reverse Engineering. Sleep klassen van Architecture Explorer naar het diagram. In dit geval verschijnt de entiteit samen met zijn attributen in het diagram. Periodiek worden verbindingen gevormd tussen entiteiten die zouden moeten bestaan (en het type verbinding wordt zelfs periodiek correct weergegeven), maar in welke gevallen is nog niet vast te stellen.

Zoals we allemaal weten, definieert de UML 2.0-standaard er vier standaard soort gegevens: Boolean, Integer, String en UnlimitedNatural. De overige typen worden automatisch in pakketten gemaakt op basis van hun locatie in de .NET-naamruimten.

Laten we dus proberen het model in een adequate staat te ‘repareren’ en het tegelijkertijd een beetje uit te breiden. Om dit te doen, maakt u een nieuwe klasse in het diagram, sleept u deze naar het gewenste pakket in de UML Model Explorer en selecteert u het stereotype C# Class (Microsoft heeft verschillende .NET-specifieke stereotypen toegevoegd die worden gebruikt bij het genereren van code).

Let op deze klasse is nog niet aanwezig in de domeinassemblage. Om het daar te registreren en tegelijkertijd al onze wijzigingen toe te passen, moet u het volgende doen.

Selecteer in Model Explorer de Domain-assembly, ga naar Properties en klik in het item Text Template Binding op de knop "...". Toevoegen nieuw element, in het veld Projectpad geven we de naam aan van het project waarin de code zal worden gegenereerd, in het veld Doelmap geven we de map aan die relatief is aan het project (we genereren in de root) en geven we het sjabloonadres aan. Standaard bevinden ze zich in de map "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\Visualization and Modeling Feature Pack\2.0\Templates\Text". U kunt voor alle gelegenheden verschillende sjablonen instellen. In ons geval selecteert u ClassTemplate.t4.

Klik hierna met de rechtermuisknop op vrije ruimte diagrammen en selecteer het item Code genereren.

En - voila! Nieuwe klasse toegevoegd aan de samenstelling, alle wijzigingen worden toegepast volgens het model.

Overigens is het met behulp van stereotypen mogelijk om bijna alles te specificeren: de zichtbaarheid van leden, attributen die worden meegenomen bij het genereren van een naamruimte, enz.

M$ biedt ons dus een geweldig hulpmiddel dat het leven van architecten en ontwikkelaars een stuk eenvoudiger zal maken. Helaas is deze erg benodigde pakket is alleen beschikbaar voor MSDN-abonnees en om de een of andere reden staat het bedrijf niet toe dat alle legale gebruikers het gebruiken. En dit kost VS Ultimate ongeveer 300 duizend roebel. Laten we hopen dat deze stand van zaken in de nabije toekomst zal veranderen.

Alle UML-diagrammen kunnen in twee groepen worden verdeeld, waarvan de eerste algemene diagrammen zijn. Algemene diagrammen zijn vrijwel onafhankelijk van het modelleringsonderwerp en kunnen in elk softwareproject worden gebruikt, ongeacht het onderwerpgebied, het oplossingsgebied, enz.

1.5.1. Gebruiksdiagram

Gebruiksdiagram(use case-diagram) - dit is het meest algemeen idee functioneel doel systemen.

Het gebruiksdiagram is bedoeld om antwoord te geven belangrijkste vraag modellering: wat doet het systeem in de buitenwereld?

Een gebruiksdiagram maakt gebruik van twee soorten kernentiteiten: use cases 1 en actoren 2, waartussen de volgende basistypen relaties tot stand komen:

associatie tussen actor en use case 3;
generalisatie tussen actoren 4 ;
generalisatie tussen gebruiksscenario's 5 ;
afhankelijkheden ( verschillende soorten) tussen gebruiksscenario's 6 .

Een gebruiksdiagram kan, net als ieder ander diagram, commentaar bevatten 7 . Bovendien wordt dit ten zeerste aanbevolen om de leesbaarheid van de diagrammen te verbeteren.

De belangrijkste notatie-elementen die in een gebruiksdiagram worden gebruikt, worden hieronder weergegeven. Gedetailleerde beschrijving gegeven in paragraaf 2.2.

1.5.2. Klassendiagram

Klassendiagram(klassediagram) is de belangrijkste manier om de structuur van een systeem te beschrijven.

Dit is niet verrassend, aangezien UML in de eerste plaats een objectgeoriënteerde taal is en klassen de belangrijkste (zo niet de enige) bouwsteen zijn.

Een klassendiagram gebruikt één basistype entiteit: klassen 1 (inclusief talrijke speciale gevallen van klassen: interfaces, primitieve typen, associatieklassen en vele andere), waartussen de volgende basistypen relaties tot stand worden gebracht:

associatie tussen 2 klassen (met veel aanvullende details);
generalisatie tussen klassen 3;
afhankelijkheden (van verschillende typen) tussen klassen 4 en tussen klassen en interfaces.

Een deel van de notatie die in een klassendiagram wordt gebruikt, wordt hieronder weergegeven. Een gedetailleerde beschrijving vindt u in hoofdstuk 3.

1.5.3. Machinediagram

Machinediagram(state machine diagram) is een van de manieren om gedrag in UML gedetailleerd te beschrijven op basis van de expliciete identificatie van toestanden en beschrijving van overgangen tussen toestanden.

In wezen zijn automaatdiagrammen, zoals de naam al doet vermoeden, een grafiek van toestandsovergangen (zie hoofdstuk 4) boordevol aanvullende details en details.

In een automaatdiagram wordt één hoofdtype entiteit gebruikt - toestanden 1, en één type relatie - overgangen 2, maar voor beide zijn veel varianten, speciale gevallen en aanvullende notaties gedefinieerd. Het heeft geen zin om ze allemaal in een inleidende recensie op te sommen.

Een gedetailleerde beschrijving van alle varianten van automaatdiagrammen wordt gegeven in paragraaf 4.2, en de volgende afbeelding toont alleen de belangrijkste elementen van de notatie die in het automaatdiagram wordt gebruikt.

1.5.4. Activiteitendiagram

Activiteitendiagram (activiteitendiagram) is een manier om gedrag te beschrijven op basis van het specificeren van controlestromen en gegevensstromen.

Een activiteitendiagram is een andere manier om gedrag te beschrijven dat visueel doet denken aan een goed oud algoritmestroomdiagram. Vanwege de gemoderniseerde notatie die consistent is met de objectgeoriënteerde benadering, en vooral vanwege de nieuwe semantische component (vrije interpretatie van Petri-netten), is het UML-activiteitendiagram echter een krachtig hulpmiddel om het gedrag van het systeem te beschrijven.

Het activiteitendiagram gebruikt één hoofdtype entiteit – actie 1, en één type relatie – transities 2 (overdrachten van controle en gegevens). Ook worden constructies gebruikt als vorken, fusies, verbindingen, takken 3, die vergelijkbaar zijn met entiteiten, maar dat in feite niet zijn, maar vertegenwoordigen grafische methode afbeeldingen van enkele speciale gevallen van relaties tussen meerdere plaatsen. De semantiek van activiteitendiagramelementen wordt in hoofdstuk 4 gedetailleerd besproken. De belangrijkste notatie-elementen die in een activiteitendiagram worden gebruikt, worden hieronder weergegeven.

1.5.5. Volgordediagram

Volgordediagram(sequentiediagram) is een manier om het gedrag van een systeem te beschrijven op basis van het aangeven van de volgorde van verzonden berichten.

In feite is een sequentiediagram een registratie van het protocol van een specifieke sessie van het systeem (of een fragment van een dergelijk protocol). Bij objectgeoriënteerd programmeren is het belangrijkste tijdens runtime het doorgeven van berichten tussen communicerende objecten. Het is de volgorde van het verzenden van berichten die in dit diagram wordt weergegeven, vandaar de naam.

Een sequentiediagram gebruikt één hoofdtype entiteit - instanties van interacterende classificatoren 1 (voornamelijk klassen, componenten en actoren), en één type relatie - verbindingen 2 waarlangs berichten worden uitgewisseld 3. Er zijn verschillende manieren berichten verzenden, die in grafische notatie verschillen in het type pijl dat overeenkomt met de relatie.

Een belangrijk aspect Een sequentiediagram is een expliciete weergave van het verstrijken van de tijd. In tegenstelling tot andere soorten diagrammen, behalve misschien synchronisatiediagrammen, is bij een sequentiediagram niet alleen de aanwezigheid van grafische verbindingen tussen elementen belangrijk, maar ook de relatieve positie van de elementen in het diagram. Er wordt namelijk aangenomen dat er een (onzichtbare) tijdas is, standaard gericht van boven naar beneden, en het bericht dat later wordt verzonden, is hieronder getekend.

De tijdas kan horizontaal gericht zijn, waarbij de tijd geacht wordt van links naar rechts te stromen.

De volgende afbeelding toont de basisnotatie die in een sequentiediagram wordt gebruikt. Om de interacterende objecten zelf aan te duiden, wordt een standaardnotatie gebruikt: een rechthoek met de naam van de classificatorinstantie. Stippellijn, die eruit komt, wordt de levenslijn 4 genoemd. Dit is geen weergave van een relatie in een model, maar een grafisch commentaar dat bedoeld is om de lezer van het diagram in de goede richting te leiden. Figuren in de vorm van smalle strepen over de levenslijn heen zijn ook geen afbeeldingen van de entiteiten die worden gemodelleerd. Dit grafische opmerking, waarbij de tijdsperioden worden weergegeven waarin het object eigenaar is van de besturingsstroom (uitvoeringsgebeurtenis) 5 of met andere woorden: activering van het object vindt plaats. Gecombineerde fragmentstappen 6 maken het mogelijk dat het sequentiediagram de algoritmische aspecten van het interactieprotocol weergeeft. Zie Hoofdstuk 4 voor meer details over de notatie van sequentiediagrammen.

1.5.6. Communicatiediagram

Communicatiediagram(communicatiediagram) is een manier om gedrag te beschrijven die semantisch equivalent is aan een sequentiediagram.

In feite is dit dezelfde beschrijving van de volgorde van berichtenuitwisseling van interacterende instanties van classificatoren, alleen uitgedrukt door anderen grafische middelen. Bovendien kunnen de meeste tools automatisch sequentiediagrammen omzetten in communicatiediagrammen en omgekeerd.

Dus zowel in het communicatiediagram als in het sequentiediagram wordt één hoofdtype entiteit gebruikt - instanties van op elkaar inwerkende classificatoren 1 en één type relatie - verbindingen 2.

De nadruk ligt hier echter niet op de tijd, maar op de structuur van verbindingen tussen specifieke instanties.

De figuur toont de belangrijkste notatie-elementen die in een communicatiediagram worden gebruikt. Om de interacterende objecten zelf aan te duiden, wordt een standaardnotatie gebruikt: een rechthoek met de naam van de classificatorinstantie. De relatieve positie van de elementen in het samenwerkingsdiagram doet er niet toe - alleen de verbindingen (meestal gevallen van associaties) waarlangs berichten worden verzonden 3 zijn belangrijk. Hiërarchische decimale nummering wordt gebruikt om de volgorde van berichten in de loop van de tijd weer te geven.

1.5.7. Componentdiagram Componentdiagram

(componentendiagram) - toont de relaties tussen de modules (logisch of fysiek) waaruit het gemodelleerde systeem bestaat.

Het belangrijkste type entiteiten in een componentendiagram zijn de componenten zelf 1, evenals interfaces 2, waarmee de relatie tussen de componenten wordt aangegeven. In een componentendiagram gelden de volgende relaties:
implementaties tussen componenten en interfaces (een component implementeert een interface);

afhankelijkheden tussen componenten en interfaces (de component gebruikt de interface) 3.

De figuur toont de belangrijkste elementen van de notatie die wordt gebruikt in een componentendiagram. Een gedetailleerde beschrijving vindt u in hoofdstuk 3.

1.5.8. Plaatsingsdiagram Plaatsingsdiagram

(implementatiediagram), samen met het weergeven van de samenstelling en verbindingen van systeemelementen, laat zien hoe ze zich tijdens runtime fysiek op computerbronnen bevinden.

De afbeelding toont de belangrijkste elementen van de notatie die in een lay-outdiagram wordt gebruikt. Om aan te tonen dat de ene entiteit deel uitmaakt van een andere, wordt ofwel een 'implementatie'-afhankelijkheidsrelatie toegepast 5 ofwel wordt een figuur van de ene entiteit in een figuur van een andere entiteit geplaatst 6 . Een gedetailleerde beschrijving van het diagram vindt u in hoofdstuk 3.

Een UML-diagram is een gespecialiseerde grafische beschrijvingstaal die is ontworpen voor objectmodellering bij de ontwikkeling van verschillende software. Deze taal heeft een breed profiel en is een open standaard die verschillende grafische notaties gebruikt om te creëren abstract model systemen. UML is gemaakt om de definitie, visualisatie, documentatie en ontwerp van allerlei soorten softwaresystemen mogelijk te maken. Het is vermeldenswaard dat het UML-diagram zelf geen programmeertaal is, maar het biedt de mogelijkheid om op basis daarvan afzonderlijke code te genereren.

Waarom is het nodig?

Het gebruik van UML houdt niet op bij het modelleren van allerlei soorten software. Ook wordt deze taal tegenwoordig actief gebruikt voor het modelleren van verschillende bedrijfsprocessen, het uitvoeren van systeemontwerp en het weergeven van organisatiestructuren.

Met UML kunnen softwareontwikkelaars volledige overeenstemming garanderen in de grafische notatie die wordt gebruikt om algemene concepten weer te geven, zoals: component, generiek, klasse, gedrag en aggregatie. Hierdoor wordt een grotere mate van concentratie op architectuur en design bereikt.

Het is ook vermeldenswaard dat er verschillende soorten van dergelijke grafieken zijn.

Klassendiagram

Diagram UML-klassen is een statisch structuurdiagram dat is ontworpen om de structuur van een systeem te beschrijven en om de attributen, methoden en afhankelijkheden tussen verschillende klassen te tonen.

Het is vermeldenswaard dat er verschillende standpunten zijn over de constructie van dergelijke diagrammen, afhankelijk van hoe ze zullen worden gebruikt:

Conceptueel. IN in dit geval Een UML-klassediagram beschrijft een model van een specifiek onderwerpgebied en biedt alleen klassen van applicatieobjecten.
Specifiek. Het diagram wordt gebruikt bij het ontwerpproces van verschillende informatiesystemen.
Uitvoering. Het klassendiagram bevat allerlei klassen die direct in de programmacode worden gebruikt.

Componentdiagram

Een UML-componentendiagram is een volledig statisch structuurdiagram. Het is bedoeld om de verdeling van een bepaald softwaresysteem in verschillende structurele componenten aan te tonen, evenals de verbindingen daartussen. Een UML-componentendiagram kan allerlei modellen, bibliotheken, bestanden, pakketten, uitvoerbare bestanden en vele andere elementen als zodanig gebruiken.

Composiet/composiet structuurdiagram

Een UML-samengesteld/samengesteld structuurdiagram is ook een statisch structuurdiagram, maar wordt gebruikt om de interne structuur van klassen weer te geven. Indien mogelijk dit diagram kan ook de interactie aantonen van elementen die zich in de ruimte bevinden interne structuur klas.

Een subtype daarvan is het UML-samenwerkingsdiagram, dat wordt gebruikt om rollen te demonstreren, evenals de interactie van verschillende klassen binnen de grenzen van samenwerking. Ze zijn best handig als u ontwerppatronen moet modelleren.

Het is vermeldenswaard dat de weergaven UML-klasse en samengestelde structuurdiagrammen tegelijkertijd kunnen worden gebruikt.

Implementatiediagram

Dit diagram wordt gebruikt om lopende knooppunten te modelleren, evenals allerlei artefacten die daarop zijn ingezet. In UML 2 worden artefacten op verschillende knooppunten geïmplementeerd, terwijl in de eerste versie alleen componenten werden geïmplementeerd. Het UML-implementatiediagram wordt dus voornamelijk gebruikt voor de tweede versie.

Er wordt een manifestatieafhankelijkheid gevormd tussen het artefact en de component die het implementeert.

Objectdiagram

In deze weergave kunt u een volledige of gedeeltelijke momentopname bekijken van het systeem waarin het wordt gemaakt bepaald moment tijd. Het geeft volledig alle exemplaren van klassen van een bepaald systeem weer, met vermelding van de huidige waarden van hun parameters, evenals de verbindingen daartussen.

Pakketdiagram

Dit diagram is structureel van aard en de belangrijkste inhoud ervan bestaat uit allerlei soorten pakketten, evenals de relaties daartussen. In dit geval is er geen strikte scheiding tussen verschillende structurele diagrammen, waardoor het gebruik ervan meestal uitsluitend voor het gemak wordt gevonden en geen enkele semantische betekenis heeft. Het is vermeldenswaard dat verschillende items verschillend kunnen zijn UML-diagrammen(voorbeelden: pakketten en pakketdiagrammen zelf).

Het gebruik ervan wordt uitgevoerd om de organisatie van verschillende elementen in groepen volgens een bepaald criterium te garanderen, om de structuur te vereenvoudigen, en om het werk met het model van een bepaald systeem te organiseren.

Activiteitendiagram

Een UML-activiteitendiagram geeft de ontleding van een specifieke activiteit in meerdere weer componenten. In dit geval is het concept van 'activiteit' de specificatie van een bepaald uitvoerbaar gedrag in de vorm van parallelle, evenals gecoördineerde opeenvolgende uitvoering van verschillende ondergeschikte elementen - geneste soorten activiteiten en diverse acties, verenigd door stromen die van de uitgangen van een bepaald knooppunt naar de ingangen van een ander knooppunt gaan.

UML-activiteitendiagrammen worden vaak gebruikt om verschillende bedrijfsprocessen parallel en parallel te modelleren opeenvolgende berekeningen. Ze simuleren onder meer allerlei technologische procedures.

Machinediagram

Dit type wordt ook een beetje anders genoemd: UML-statusdiagram. Het heeft een gepresenteerde eindige toestandsmachine met eenvoudige en samengestelde toestanden, evenals overgangen.

Staatsmachine is een specificatie van de opeenvolging van verschillende toestanden waar een bepaald object doorheen gaat, of interactie als reactie op bepaalde gebeurtenissen in zijn leven, evenals de reactie van het object op dergelijke gebeurtenissen. Er wordt een statusmachine toegewezen die gebruikmaakt van een UML-statusdiagram bronelement en wordt gebruikt om het gedrag van zijn instanties te bepalen.

Zogenaamde drakendiagrammen kunnen worden gebruikt als analogen van dergelijke diagrammen.

Gebruik casediagrammen

Een UML-use-casediagram geeft alle relaties weer die tussen actoren ontstaan verschillende opties gebruik. Haar belangrijkste taak is het bieden van een volwaardig middel waarmee de klant, eindgebruiker of een ontwikkelaar kan samenwerken om het gedrag en de functionaliteit van een bepaald systeem te bespreken.

Als een UML-use-casediagram wordt gebruikt in het systeemmodelleringsproces, zal de analist:

Maak een duidelijke scheiding tussen het systeem dat wordt gemodelleerd en zijn omgeving.
Identificeer de actoren, de manieren van hun interactie met dit systeem, evenals de verwachte functionaliteit ervan.
Stel de woordenlijst in als onderwerpgebied diverse concepten, die betrekking hebben op gedetailleerde beschrijving functionaliteit van dit systeem.

Als er een gebruiksdiagram in UML wordt ontwikkeld, begint de procedure met een tekstbeschrijving, die wordt verkregen tijdens de samenwerking met de klant. Het is vermeldenswaard dat verschillende niet-functionele vereisten volledig worden weggelaten tijdens het opstellen van een use case-model, en dat er een apart document voor zal worden gegenereerd.

Communicatie

Een communicatiediagram is, net als een UML-sequentiediagram, transitief, dat wil zeggen dat het interactie uitdrukt, maar tegelijkertijd demonstreert op verschillende manieren, en indien nodig kunt u met de vereiste mate van nauwkeurigheid de ene in de andere omzetten.

Een communicatiediagram geeft de interacties weer die plaatsvinden tussen verschillende elementen composietstructuur, evenals de rollen van samenwerking. Het belangrijkste verschil tussen dit diagram en een sequentiediagram is dat het de relaties tussen verschillende elementen vrij expliciet maakt en tijd niet als een afzonderlijke dimensie gebruikt.

Dit type Het beschikt over een volledig vrij formaat voor het ordenen van meerdere objecten en verbindingen, op dezelfde manier als in een objectdiagram. Als het nodig is om de volgorde van berichten in dit gratis formaat te behouden, worden ze chronologisch genummerd. Het lezen van dit diagram begint met het initiële bericht 1.0 en gaat vervolgens verder in de richting waarin berichten van het ene object naar het andere worden verzonden.

Voor het grootste deel tonen deze diagrammen precies dezelfde informatie die een sequentiediagram ons biedt, maar omdat het een andere manier gebruikt om informatie te presenteren, worden bepaalde dingen in het ene diagram veel gemakkelijker te identificeren dan in het andere. Het is ook vermeldenswaard dat het communicatiediagram duidelijker laat zien met welke elementen elk interactief is. afzonderlijk onderdeel, terwijl een sequentiediagram duidelijker laat zien in welke volgorde de interacties plaatsvinden.

Volgordediagram

Een UML-sequentiediagram toont interacties tussen meerdere objecten, geordend op basis van het tijdstip waarop ze voorkomen. Dit diagram toont de tijdgeordende interactie tussen verschillende objecten. In het bijzonder worden alle objecten weergegeven die deelnemen aan de interactie, evenals de volledige reeks berichten die tussen hen worden uitgewisseld.

De belangrijkste elementen in dit geval zijn de aanduidingen diverse voorwerpen, en ook verticale lijnen, die het verstrijken van de tijd weergeeft en rechthoeken die de activiteit van een bepaald object of de uitvoering van een bepaalde functie vertegenwoordigen.

Samenwerkingsdiagram

Met dit type diagram kunt u de interacties tussen verschillende objecten demonstreren, waarbij u abstractie maakt van de volgorde van berichtoverdracht. Dit type diagram geeft in compacte vorm absoluut alle verzonden en ontvangen berichten van een bepaald object weer, evenals de formaten van deze berichten.

Omdat sequentie- en communicatiediagrammen eenvoudigweg verschillende weergaven van dezelfde procedures zijn, biedt Rational Rose de mogelijkheid om van een sequentiediagram een communicatiediagram te maken of andersom, en deze ook volledig automatisch te synchroniseren.

Interactieoverzichtsdiagrammen

Dit zijn diagrammen UML-taal, die een soort activiteitendiagram zijn en zowel Sequence-elementen als controlestroomconstructies bevatten.

Het is vermeldenswaard dat dit formaat combineert samenwerking en volgordediagram, die de mogelijkheid bieden om verschillende punten perspectief om de interactie tussen verschillende objecten in het gevormde systeem te beschouwen.

Timingdiagram

Vertegenwoordigt alternatieve optie sequentiediagram, dat duidelijk de verandering van toestand langs een levenslijn met een bepaalde tijdschaal laat zien. Kan heel nuttig zijn bij diverse toepassingen realtime.

Wat zijn de voordelen?

Het is de moeite waard om verschillende voordelen op te merken die het UML-gebruiksdiagram en andere onderscheiden:

De taal is objectgeoriënteerd, waardoor de technologieën voor het beschrijven van de resultaten van analyse en ontwerp semantisch dicht bij programmeermethoden in allerlei moderne objectgeoriënteerde talen staan.
Met de hulp van deze taal het systeem kan vanuit vrijwel elk mogelijk gezichtspunt worden beschreven, en de verschillende aspecten haar gedrag.
Alle diagrammen zijn relatief gemakkelijk te lezen, zelfs na een relatief snelle introductie in de syntaxis.
Met UML kunt u uw eigen grafische en tekststereotypen uitbreiden en introduceren, wat het gebruik ervan niet alleen in de software-engineering bevordert.
De taal is behoorlijk wijdverspreid geworden en ontwikkelt zich ook behoorlijk actief.

Gebreken

Ondanks het feit dat het maken van UML-diagrammen veel voordelen heeft, worden ze vaak bekritiseerd vanwege de volgende nadelen:

Ontslag. In de overgrote meerderheid van de gevallen zeggen critici dat UML te groot en complex is, en dit is vaak onterecht. Het bevat nogal wat overbodige of praktisch nutteloze structuren en diagrammen, en meestal is dergelijke kritiek gericht op de tweede versie, en niet op de eerste, omdat nieuwere herzieningen meer compromissen ‘ontworpen door de commissie’.
Verschillende onnauwkeurigheden in de semantiek. Omdat UML wordt gedefinieerd door een combinatie van zichzelf, Engels en OCL, heeft het niet de rigiditeit die inherent is aan talen die nauwkeurig worden gedefinieerd door formele beschrijvingstechnieken. In bepaalde situaties begint de abstracte syntaxis van OCL, UML en Engels elkaar tegen te spreken, terwijl ze in andere gevallen onvolledig zijn. Onnauwkeurige beschrijvingen van de taal zelf hebben gevolgen voor zowel gebruikers als aanbieders van tools, wat uiteindelijk leidt tot incompatibiliteit van de tools als gevolg van unieke manier interpretatie van diverse specificaties.
Problemen tijdens het implementatie- en studieproces. Alle bovenstaande problemen zorgen voor bepaalde problemen bij het implementeren en leren van UML, en dit geldt vooral wanneer het management ingenieurs dwingt het te gebruiken als ze geen voorafgaande vaardigheden hebben.
De code weerspiegelt de code. Een andere mening is dat het niet de mooie en aantrekkelijke modellen zijn die belangrijk zijn, maar de werkende systemen zelf, dat wil zeggen dat de code het project is. Volgens deze opvatting is er behoefte aan meer ontwikkeling effectieve manier software schrijven. UML wordt doorgaans gewaardeerd in benaderingen die modellen compileren om uitvoerbare bestanden opnieuw te genereren broncode. Maar in werkelijkheid is dit misschien niet genoeg, omdat de taal geen Turing-volledigheidseigenschappen heeft, en elke gegenereerde code uiteindelijk beperkt zal zijn tot wat de UML-interpretatietool kan raden of bepalen.
Niet-overeenkomende lading. Deze termijn komt uit de theorie van systeemanalyse om het onvermogen van de input van een bepaald systeem te bepalen om een andere output waar te nemen. Zoals in elk ander standaard systemen notatie kan UML bepaalde systemen op een efficiëntere en efficiëntere manier weergeven in het kort vergeleken met anderen. De ontwikkelaar is dus meer geneigd tot die oplossingen die comfortabeler zijn om alles met elkaar te verweven sterke punten UML, evenals andere programmeertalen. Dit probleem ligt meer voor de hand als de ontwikkeltaal niet voldoet aan de basisprincipes van objectgeoriënteerde orthodoxie, dat wil zeggen niet probeert te werken in overeenstemming met de principes van OOP.
Probeert universeel te zijn. UML is een modelleertaal algemeen doel, dat probeert compatibiliteit met elke momenteel bestaande verwerkingstaal te garanderen. Om het uiteindelijke doel van het ontwerpteam te kunnen bereiken, is het in de context van een bepaald project noodzakelijk om de toepasselijke kenmerken van die taal te selecteren. Daarnaast mogelijke manieren De beperkingen van de reikwijdte van UML op een bepaald gebied zijn onderworpen aan een formalisme dat niet volledig is gearticuleerd en dat zelf ook onderhevig is aan kritiek.