Inleiding tot soorten UML-diagrammen
Unified Modelling Language, dat wil zeggen UML in eenvoudige woorden, wat een algemene modelleringstaal is. Het hoofddoel van UML is het visualiseren van de manier waarop een systeem op een standaard manier is ontworpen. Het is ook vrijwel hetzelfde als blauwdrukken die ook op andere technische gebieden worden gebruikt. Het is geen programmeertaal, maar eerder een beeldtaal. Typen UML-diagrammen worden alleen gebruikt om het gedrag en de structuur van een systeem aan te tonen. UML helpt systeemarchitecten, ondernemers en ook software-ingenieurs bij het modelleren, ontwerpen en analyseren. De OMG, dat wil zeggen Object Management Group, heeft UML al in 1997 als standaard aangenomen. Sindsdien wordt het door hen beheerd. Daarna publiceerde ISO in 2005 UML als een goedgekeurde norm. UML is in de loop van de jaren periodiek herzien en beoordeeld.
Laten we vervolgens de soorten UML-diagrammen bespreken.
Verschillende soorten UML-diagrammen
Er bestaan veel soorten UML-diagrammen en elk heeft een ander doel zonder te overwegen of het vóór de implementatie of na de implementatie is ontworpen.
2 van de breedste categorieën die alle andere typen omvat zijn
- Gedrag UML-diagram
- StructureelUML-diagram.
Zoals u alleen al uit de naam kunt raden, analyseren sommige UML-diagrammen de structuur van een proces, terwijl een andere het gedrag van het systeem, de bouwcomponenten en ook de actoren beschrijft. De verdere gecategoriseerde types zijn als volgt:
Structureel UML-diagram
- Klasse diagram
- Object diagram
- Componenten diagram
- Composiet structuurdiagram
- Implementatiediagram
- Pakketdiagram
- Profieldiagram
Gedrag UML-diagram
- Activiteiten diagram
- Gebruik casusdiagram
- Interactie overzichtsdiagram
- Timingdiagram
- Machineschema staat
- Communicatie diagram
- Volgorde diagram
Laten we ze nu kort bespreken:
1. Activiteitsdiagram
Activiteitsdiagram is de belangrijkste UML-diagrammen die worden gebruikt voor het uitvoeren van bedrijfsprocesmodellering. Het wordt in principe gebruikt om de stroom van verschillende activiteiten en acties in softwareontwikkeling te verklaren. Ook kunnen deze zowel sequentieel als ook parallel zijn.
2. Gebruik casusdiagram
Use case-diagrammen zijn in wezen nodig om de vereisten op hoog niveau van het systeem te analyseren. Nu kunnen deze vereisten worden uitgedrukt met behulp van verschillende gebruiksscenario's.
3. Overzicht van de interactie
Het is degene die het vermogen heeft om de besturingsstroom samen met knooppunten in beeld te brengen, die interactiediagrammen bevat. Het is hetzelfde als het activiteitsdiagram in die zin dat beiden de volgorde van activiteiten visualiseren.
4. Tijdschema
Deze diagrammen zijn in principe nodig om relaties tussen objecten weer te geven wanneer het middelpunt van de tijd op tijd rust. Hoewel we echter niet geïnteresseerd zijn om te weten hoe objecten op elkaar inwerken of elkaar zelfs veranderen, ondanks dat we willen vertegenwoordigen hoe deze objecten moeten worden uitgevoerd, zouden acteurs volgens een lineaire tijdas kunnen handelen.
5. Staatsmachine UML-diagram
UML-diagrammen van de toestandsmachine worden ook toestandsdiagrammen genoemd. Ze worden meestal gebruikt om verschillende toestanden van een component in het systeem te verklaren. Staatsmachine UML-diagrammen hebben de naamstatusmachine, aangezien het diagram in wezen alleen machine is, wat de verschillende toestanden van een object verklaart en ook hoe het verandert afhankelijk van interne en externe gebeurtenissen.
6. Communicatiediagram
Communicatiediagrammen zijn net als de sequentiediagrammen een soort interactiediagram dat laat zien hoe de objecten op elkaar inwerken. Het is een uitbreiding van een objectdiagram dat objecten toont met berichten die van de ene naar de andere reizen.
7. Volgorde UML-diagram
Sequentie UML-diagrammen kunnen ook worden beschouwd als de belangrijkste UML-diagrammen onder modellen op ontwerpniveau voor de ontwikkeling van een zakelijke applicatie. Omdat ze visueel vanzelfsprekend zijn, zijn deze diagrammen de laatste tijd erg populair geworden bij het voorspellen van bedrijfsprocessen.
8. Klasse diagram
Klasse UML-diagram kan ook worden beschouwd als het meest voorkomende diagramtype dat nodig is voor softwaredocumentatie. Aangezien de meeste software die vandaag wordt gemaakt, nog steeds op het OOP-paradigma is gebaseerd, lijkt het daarom een logische oplossing als we klassendiagrammen gebruiken om deze software te documenteren. Dit gebeurt ook omdat OOP afhankelijk is van klassen en de relaties.
9. Objectdiagram
Object UML-diagrammen helpen ontwikkelaars bij het controleren of de generieke abstracte structuur die ze hebben gemaakt, dat wil zeggen klassendiagram, een levensvatbare structuur vertegenwoordigt wanneer deze in de praktijk wordt gebracht, dat wil zeggen wanneer de objecten van een klasse worden geïnstantieerd. Slechts weinig ontwikkelaars zien het echter als een secundair niveau van nauwkeurigheidscontrole.
10. Componenten diagram
Component UML-diagrammen kunnen helpen bij het opdelen van het systeem in kleinere componenten wanneer u te maken hebt met de documentatie van vrij complexe systemen. Vaak is het vrij moeilijk om de architectuur van een systeem te voorspellen, omdat het verschillende afdelingen kan omvatten of ook verschillende technologieën kan gebruiken.
11. Samengesteld structuurdiagram
Een composiet structuurdiagram wordt beschouwd als een type statisch diagram dat de interne structuur van de klas en samenwerkingen weergeeft. Het is een reeks onderling verbonden elementen.
12. Implementatie diagram
Vervolgens worden implementatiediagrammen meestal gebruikt om de relatie tussen de software en de hardware te visualiseren. Als we specifieker praten, kunnen we met behulp van implementatiediagrammen ook een fysiek model construeren van hoe artefacten worden geïmplementeerd op knooppunten die hardwarecomponenten zijn.
Als we het hebben over een typisch vereenvoudigd implementatiediagram in een webtoepassing, zou dit het volgende omvatten:
- Knooppunten, dat wil zeggen toepassingsserver en databaseserver
- Artefacten, dat wil zeggen applicatieclient en databaseschema
13. Pakketdiagram
Het pakketdiagram lijkt meer op een macrocontainer die nodig is voor de implementatie van UML-diagrammen die we al hebben uitgelegd. Nu bevatten verschillende pakketten knooppunten en ook artefacten. Ze organiseren de componenten en modeldiagrammen in groepen op dezelfde manier als een naamruimte verschillende namen zou inkapselen die op een bepaalde manier behoorlijk gecorreleerd zijn.
14. Profieldiagram
Profieldiagrammen kunnen niet worden beschouwd als het typische UML-diagramtype. Desondanks kan het meer als een uitbreidingsmechanisme worden beschouwd en niet als een diagramtype als elk ander.
Als we stereotypen, beperkingen en getagde waarden gebruiken, kunnen we gemakkelijk al bestaande notaties van UML uitbreiden en aanpassen. Profieldiagrammen zijn echter als een taal. Als u bijvoorbeeld Engels spreekt, kunt u eenvoudig nieuwe zinnen maken. Als u profieldiagrammen spreekt, kunt u op dezelfde manier eenvoudig en specifiek nieuwe eigenschappen en semantiek voor UML-diagrammen maken.
Conclusie
UML-diagrammen zijn dus handig wanneer we bedrijfsgegevens modelleren. Klasse-attributen worden toegewezen aan abstracte toegangsmethoden voor persistente velden en associatiefuncties worden toegewezen aan abstracte toegangsmethoden voor relatievelden. Navigeerbaarheid voorspelt of relatietoegangsmethoden verschijnen in beide gerelateerde entiteitbonen of slechts één. Verder bepaalt de multiplicatie-notatie het juiste type voor relatievelden, problemen van een levenscyclus en ook trapsgewijze wiskenmerken.
Aanbevolen artikelen
Dit is een gids voor soorten UML-diagrammen. Hier bespreken we de basisconcepten met de breedste categorieën van UML-diagram. U kunt ook onze andere voorgestelde artikelen doornemen voor meer informatie -
- Wat is C ++
- Wat is Git?
- Wat is JavaScript?
- Wat is PHP Array?