Typy relacji UML: skojarzenie, zależność, generalizacja

Przestudiujmy je szczegółowo

Rodzaje relacji w diagramie klas UML

Stowarzyszenie

Jest to zbiór łączy łączących elementy modelu UML. Określa także, ile obiektów bierze udział w tej relacji.

Zależność

W relacji zależności, jak sama nazwa wskazuje, dwa lub więcej elementów jest od siebie zależnych. W tego rodzaju związku, jeśli dokonamy zmiany w konkretnym elemencie, wówczas jest prawdopodobne, że zmiana będzie miała wpływ na wszystkie pozostałe elementy.

Uogólnienie

Nazywa się to również relacją rodzic-dziecko. Uogólniając, jeden element jest specjalizacją innego ogólnego komponentu. Można go zastąpić. Jest używany głównie do reprezentowania dziedziczenia.

Realizacja

W relacji realizacji UML jeden podmiot oznacza pewną odpowiedzialność, która sama nie jest realizowana, a drugi podmiot, który ją wdraża. Zależność ta występuje najczęściej w przypadku interfejsy.

Stowarzyszenie

Jest to relacja strukturalna, która przedstawia, że ​​obiekty mogą być połączone lub skojarzone z innym obiektem wewnątrz systemu. Do relacji skojarzenia można zastosować następujące ograniczenia.

• {domniemany} – Ukryte ograniczenia określają, że związek nie jest oczywisty; opiera się na koncepcji.
• {zamówiłem} – Uporządkowane wiązania określają, że zbiór obiektów na jednym końcu skojarzenia jest w określony sposób.
• {zmienny} – Zmienne ograniczenie określa, że ​​połączenia pomiędzy różnymi obiektami w systemie mogą być dodawane, usuwane i modyfikowane zgodnie z wymaganiami.
• {dodaj tylko} – Określa, że ​​nowe połączenia można dodawać z obiektu znajdującego się na drugim końcu skojarzenia.
• {mrożony} – Określa, że ​​po dodaniu połączenia pomiędzy dwoma obiektami nie można go modyfikować, gdy na danym łączu lub połączeniu aktywne jest zamrożone ograniczenie.

Możemy także stworzyć klasę posiadającą właściwości asocjacyjne; nazywa się to klasą asocjacyjną.

Odruchowe skojarzenie

Powiązanie zwrotne jest podtypem relacji powiązania w języku UML. W skojarzeniu zwrotnym instancje tej samej klasy mogą być ze sobą powiązane. Instancję klasy nazywa się także obiektem.

Asocjacja zwrotna stwierdza, że ​​łącze lub połączenie może występować w obiektach tej samej klasy.

Rozważmy przykład owocu klasowego. Klasa Fruit ma dwie instancje, takie jak mango i jabłko. Skojarzenie refleksyjne stwierdza, że ​​może występować związek między mango i jabłkiem, ponieważ są to egzemplarze tej samej klasy, np. owoce.

Stowarzyszenie kierowane

Jak sama nazwa wskazuje, skojarzenie ukierunkowane jest związane z kierunkiem przepływu w klasach skojarzeń.

W skojarzeniu ukierunkowanym przepływ jest kierowany. Powiązania z jednej klasy do drugiej przebiegają tylko w jednym kierunku.

Jest to oznaczone linią ciągłą ze strzałką.

Przykład:

Można powiedzieć, że istnieje ukierunkowane powiązanie pomiędzy serwerem a klientem. Serwer może przetwarzać żądania klienta. Ten przepływ jest jednokierunkowy i przepływa tylko od serwera do klienta. Dlatego też w serwerach i klientach systemu może występować ukierunkowana relacja skojarzenia.

Zależność

Korzystając z relacji zależności w języku UML, można powiązać, w jaki sposób różne elementy w danym systemie są od siebie zależne. Zależność służy do opisu relacji między różnymi elementami w języku UML, które są od siebie zależne.

Stereotypy

• "wiązać" – Powiązanie to ograniczenie określające, że źródło może zainicjować szablon w lokalizacji docelowej, korzystając z podanych parametrów lub wartości.
• "czerpać" – Oznacza, że ​​lokalizację obiektu źródłowego można obliczyć na podstawie obiektu docelowego.
• «przyjaciel» – Określa, że ​​źródło ma unikalną widoczność w obiekcie docelowym.
• "wystąpienie" – Określa, że ​​instancja klasyfikatora docelowego jest obiektem źródłowym.
• «instancja» – Określa, że ​​obiekt źródłowy może tworzyć instancje obiektu docelowego.
• "oczyścić" – Określa, że ​​obiekt źródłowy ma wyjątkowe abstracniż obiekt docelowy.
• "używać" – Jest używany, gdy pakiety są tworzone w języku UML. Stereotyp użycia opisuje, że elementy pakietu źródłowego mogą znajdować się również w pakiecie docelowym. Opisuje, że pakiet źródłowy wykorzystuje pewne elementy pakietu docelowego.
• "zastąpić" – określa, że ​​klient może zastąpić dostawcę w czasie wykonywania.
• "dostęp" – Określa, że ​​pakiet źródłowy ma dostęp do elementów pakietu docelowego zwane także łączeniem prywatnym.
• "Import" – Określa, że ​​cel może importować elementy pakietu źródłowego, tak jak są one zdefiniowane w pliku target, zwany także łączeniem publicznym.
• "zezwolenie" – określa, że ​​element źródłowy ma dostęp do elementu dostawcy niezależnie od zadeklarowanej widoczności dostawcy.
• "rozszerzyć" – Pomaga określić, że cel może rozszerzyć zachowanie elementu źródłowego.
• "włączać" – Umożliwia określenie elementu źródłowego, do którego można uwzględnić zachowanie innego elementu w określonej lokalizacji. (tak samo jak wywołanie funkcji w c/c++)
• "stać się" – Określa, że ​​cel jest podobny do źródła, ale ma różne wartości i role.
• "dzwonić" – Określa, że ​​źródło może wywołać metodę obiektu docelowego.
• "Kopiuj" – Określa, że ​​obiekt docelowy jest niezależną kopią obiektu źródłowego.
• "parametr" – dostawca jest parametrem operacji klienta.
• "wysłać" – klient jest operacją wysyłającą dostawcy jakiś nieokreślony cel.

Stereotypy wśród machiny państwowej

• "wysłać" – Określa, że ​​operacja źródłowa wysyła zdarzenie docelowe.

Uogólnienie

Jest to relacja pomiędzy bytem ogólnym a bytem unikalnym obecnym w systemie.

W relacji uogólnienia koncepcja obiektowa nazywa się dziedzictwo można wdrożyć. Pomiędzy dwoma obiektami, zwanymi także bytami lub rzeczami, istnieje relacja uogólnienia. W relacji uogólnienia jedna jednostka jest rodzicem, a druga mówi się, że jest dzieckiem. Podmioty te można przedstawić za pomocą dziedziczenia.

W przypadku dziedziczenia dziecko dowolnego elementu nadrzędnego może uzyskać dostęp, aktualizować lub dziedziczyć funkcjonalność określoną w obiekcie nadrzędnym. Obiekt podrzędny może dodawać do siebie swoją funkcjonalność, a także dziedziczyć strukturę i zachowanie obiektu nadrzędnego.

Ten typ relacji jest zbiorczo nazywany relacją uogólnienia.

Stereotypy i ich ograniczenia

• "realizacja" – Ten stereotyp jest używany do przedstawienia, że ​​jednostka podrzędna jest implementowana przez jednostkę nadrzędną poprzez dziedziczenie struktury i zachowania obiektu nadrzędnego bez naruszania zasad. Uwaga: Ten stereotyp jest powszechnie używany w pojedynkę dziedzictwo.

Relacja generalizacji zawiera ograniczenia, takie jak kompletność, niekompletność, aby sprawdzić, czy wszystkie encje podrzędne są uwzględnione w relacji, czy nie.

Realizacja

W relacji realizacji UML jeden podmiot oznacza pewną odpowiedzialność, która sama nie jest realizowana, a drugi podmiot, który ją wdraża. Zależność ta występuje najczęściej w przypadku interfejsy.

Urzeczywistnienie można przedstawić na dwa sposoby:

• Korzystanie Forma kanoniczna
• Korzystanie z uchylona forma

Na powyższym schemacie reguły biznesowe konta realizują interfejs IRuleAgent.

Rodzaje realizacji

1. Postać kanoniczna: W relacji realizacji języka UML, forma kanoniczna jest używana do realizacji interfejsów w całym systemie. Używa stereotypu interfejsu do utworzenia interfejsu, a relacja realizacji służy do realizacji konkretnego interfejsu. W formie kanonicznej relacja realizacji jest oznaczona linią przerywaną z szerokim, otwartym grotem strzałki. Na powyższym diagramie interfejs Iruleagent jest realizowany za pomocą obiektu o nazwie Account Business Rules.
2. Forma wymazana: Realizacja w Diagram klas UML Można go również przedstawić za pomocą formy elidowanej. W formie elidowanej interfejs jest oznaczony za pomocą okręgu, zwanego również notacją lizakową. Interfejs ten, realizowany z wykorzystaniem dowolnego elementu obecnego w systemie, tworzy strukturę elidowaną. Na powyższym diagramie interfejs Iruleagent jest oznaczony za pomocą formy elidowanej, realizowanej przez bibliotekę acctrule.dll.

Kompozycja

Nie jest to standardowa relacja UML, ale nadal jest używana w różnych aplikacjach.

Agregacja złożona jest podtypem relacji agregacji o cechach takich jak:

• jest to dwukierunkowe powiązanie pomiędzy obiektami.
• Jest to relacja całość/część.
• Jeśli kompozyt zostanie usunięty, wszystkie inne powiązane z nim części zostaną usunięte.

Agregacja kompozytowa opisywana jest jako binarna asocjacja ozdobiona wypełnionym czarnym rombem na końcu agregatu (w całości).

Folder to struktura, która zawiera n plików. Folder jest używany do przechowywania plików w nim zawartych. Każdy folder może być powiązany z dowolną liczbą plików. W systemie komputerowym każdy pojedynczy plik jest częścią co najmniej jednego folderu w systemie organizacji plików. Ten sam plik może być również częścią innego folderu, ale nie jest to obowiązkowe. Za każdym razem, gdy plik jest usuwany z folderu, folder pozostaje nienaruszony, podczas gdy dane powiązane z tym konkretnym plikiem są niszczone. Jeśli operacja usuwania jest wykonywana na folderze, to wpływa ona również na wszystkie pliki, które są obecne w folderze. Wszystkie pliki powiązane z folderem są automatycznie niszczone po usunięciu folderu z systemu.

Ten typ relacji w UML jest znany jako złożona relacja agregacji.

Zbiór

An zbiór jest podtypem relacji asocjacyjnej w UML. Agregacja i kompozycja to typy relacji asocjacyjnej w UML. Relację agregacyjną można opisać w prostych słowach jako „obiekt jednej klasy może posiadać lub uzyskiwać dostęp do obiektów innej klasy”.

W relacji agregacji obiekt zależny pozostaje w zakresie relacji nawet wtedy, gdy obiekt źródłowy zostanie zniszczony.

Rozważmy przykład samochodu i koła. Samochód potrzebuje koła, aby działać prawidłowo, ale koło nie zawsze potrzebuje samochodu. Można go również używać z rowerem, rowerem lub dowolnym innym pojazdem, ale nie konkretnym samochodem. Tutaj obiekt koła ma znaczenie nawet bez obiektu samochodu. Tego typu relację nazywa się relacją agregacji.

FAQ