Referat: Diagramy współpracy

Gr. 651

Joanna Gronowska

Tomasz Majkowski

Emilia Matusiak

Anna Monasterska

Krzysztof Sędkowski

Metody Analizy Systemów semestr letni 2004

Agenda

Pojęcie oraz zastosowanie Elementy występujące na diagramach

współpracy Stosowana notacja Sposoby numerowania komunikatów Przykłady Podsumowanie

Diagramy współpracy (kolaboracji)

• Stanowią jeden z rodzajów diagramów interakcji, opisują one w jaki sposób współpracują ze sobą grupy obiektów znajdujące się na diagramie klas.

• Przedstawiają zachowanie systemu w ramach jednego przypadku użycia, bądź tylko pewnego jego fragmentu opisanego jednym z możliwych scenariuszy danego przypadku użycia.

• Podstawowym celem konstruowania diagramów współpracy jest identyfikacja atrybutów, asocjacji między klasami oraz operacji w klasach, co pomaga w uzupełnianiu diagramu klas o brakujące elementy, niezbędne do realizacji zleconych systemowi zadań.

Diagramy współpracy: Zawartość

Prosty diagram współpracy (bez uwidaczniania interakcji między obiektami), stanowi coś w rodzaju “wystąpienia fragmentu diagramu klas”. W skład diagramu współpracy wchodzą inicjator rozpoczynający sekwencję komunikatów niezbędnych do wykonania zadania (aktor), obiekty oraz powiązania między nimi.

Możliwe jest pokazanie na diagramie więcej niż jednego obiektu danej klasy.

:Sprzedawca.

:Klient. :ModelRoweru

:Rower

Diagramy współpracy: Zawartość

Oprócz wymienionych już wyżej elementów na diagramie współpracy może pojawiać się podobnie jak na diagramie klas dodatkowa informacja tj.: kierunki nawigowania, nazwy linków, itp, jednak, tylko pod warunkiem gdy zwiększy, a nie zmniejszy to czytelność diagramu.

Przedstawiane na diagramie obiekty, połączone są “linkami” i stanowią rodzaj “kolektywu”, zwanego tu kolaboracją. Linki odpowiadają powiązaniom, czyli wystąpieniom asocjacji z diagramu klas, a to oznacza, że odpowiednia asocjacja powinna istnieć na diagramie klas.

Interakcja na diagramach współpracy

Diagramy współpracy mogą dodatkowo pokazywać interakcje zachodzące między obiektami zaangażowanymi w realizację danego przypadku użycia. Sekwencja interakcji oznacza tu sekwencję komunikatów przesyłanych między współpracującymi obiektami.

:Sprzedawca.

:Klient. : ModelRoweru

komunikat wysyłanyod aktora do obiektuklasy Klient.

kup (rower)

:Rower

1: Czy może kupić

2: Czy rower jest dostępny

4: Drukuj rachunek3: Czy nie zarezerwowany

Interakcja na diagramach współpracy

Komunikaty przedstawiane są w postaci strzałek etykietowanych nazwą operacji i rysowanych wzdłuż linków między współpracującymi obiektami. Na diagramie nie pokazuje się odpowiedzi na komunikaty, ponieważ odpowiedź na komunikat nie jest komunikatem.

Zalecane jest numerowanie komunikatów kolejnymi liczbami naturalnymi, bądź też wykorzystując numerację zagnieżdżoną. Numeracja zagnieżdżona oznacza, że gdy konkretny obiekt otrzyma komunikat o numerze n, to n będzie dołączane jako prefiks do każdego komunikatu wysyłanego przez ten obiekt.

Jeśli nie jest to konieczne komunikat wysyłany od inicjatora (aktora) nie musi być numerowany.

Diagram klas dla przypadku użycia: zakup roweru

Klient

pożycz (model)czyDostępny ()zarezerwuj (egzemplarzRoweru)

Rower

kupił

0..1

EgzemplarzRoweru

czyBrakRezerwacji ()zarezerwuj (Klient)

1..*

sprzedaj (model, Klient)

Scenariusz przypadku użycia: zakup roweru

Wariant optymistyczny Rower znajduje się w sklepie czyli jest rower który chce kupić klient,Rower który chce kupić klient nie jest zarezerwowany,Rezerwuj rower który chce kupić klient

Wariant pesymistycznyRower nie znajduje się w sklepieRower znajduje się w sklepie ale jest już zarezerwowany

Diagram współpracy odpowiadający diagramowi klas dla przypadku użycia: zakup roweru

:Sprzedawca.

: ModelRoweru

: Rower

1.1: czyDostępny ()

1.2: kup (model, Sprzedawca)

1.2.2: zarezerwujRower (Klient)1.2.1: czyBrakRezerwacji ()

:Klient1.3: zarezerwuj (Rower)

sprzedaj (Rower)

:Sprzedaż

1: kup (Rower)

Diagram klas dla przypadku użycia: wprowadzenie informacji o odbytym szkoleniu

Pracownik

imięnazwiskoNIP

Firma

nazwaadres

jest kierowany Szkolenie

/czas trwania

podpisuje

Umowa

sporządź umowę ()zaksięguj wpłatę ()

dokonuje zwrotu kosztów szkolenia

{w przypadku zwolnienia dyscyplinarnego lub złożenia}

*

11

1*dokonaj wpłaty ()

nazwa szkoleniadata rozpoczęciadata zakończeniakoszt

*

* * zawiera

nr {unique}kwotatermin obowiaz.data zawarcia

{umowa jest zawierana z pracownikiem, gdy koszt szkolenia przekracza 4 tys zł.}

Scenariusz przypadku użycia: wprowadzenie informacji o odbytym szkoleniu

Przypadek użycia rozpoczyna się, gdy Pracownik Działu Szkoleń (aktor) wprowadza do systemu informację o odbytym przez pracownika szkoleniu. Wariant pesymistyczny dla przeszkolonego pracownika: cena szkolenia przekracza 4 tys. zł - pracownik podpisuje umowę o zwrocie kosztów za odbyte szkolenie w przypadku złożenia wymówienia z pracy lub zwolnienia dyscyplinarnego. pracownik jest zwalniany dyscyplinarnie i musi zwrócić koszty szkolenia.Wariant optymistyczny nr 1 dla przeszkolonego pracownika: cena szkolenia nie przekracza 4 tys. zł – pracownik nie musi podpisywać umowy.Wariant optymistyczny nr 2 dla przeszkolonego pracownika: cena szkolenia przekracza 4 tys. zł – pracownik podpisuje umowę o zwrocie kosztów za odbyte szkolenie w przypadku złożenia wymówienia z pracy lub zwolnienia dyscyplinarnego.Pracownik nie został zwolniony dyscyplinarnie, ani nie złożył wymówienia w terminie obowiązywania umowy.

Diagram współpracy odpowiadający diagramowi klas dla przypadku użycia: wprowadzenie informacji o odbytym szkoleniu

:Pracownik Działu Szkoleń

Zarządzanie projektami: Szkolenie

Nr :Umowa

1: czyKosztSzkoleniaPrzewyższa 4 tys. zł ()

2: sporządźUmowę

Krzysztof Sędkowski : Pracownik

Sprawdź, czy istnieje konieczność podpisania umowy

Diagram współpracy odpowiadający diagramowi klas dla przypadku użycia

:Pracownik Działu Szkoleń

Zarządzanie projektami: Szkolenie

Nr :Umowa

1: czyKosztSzkoleniaPrzewyższa 4 tys. zł ()

2: sporządźUmowę

Krzysztof Sędkowski : Pracownik

Sprawdź, czy istnieje konieczność podpisania umowy

Diagram klas dla przypadku użycia: wystaw wniosek urlopowy

Wniosek urlopowy

Akceptacja manageraData rozpoczęciaData zakończeniaAkceptacja zastępcy

Pracownik

/ilość dni wykorzystanych/ilość dni pozostałych/ilość dni urlopu zaległegoData przyjęciaImieNazwiskoIdentyfikator/wymiar urlopu/staż

wystawia

Przypisz wymiar urlopu ()Aktualizuj statystyki ()Aktualizuj dane pracownika ()

1*

*

Znajdź zastępcę ()Wyślij do zastępcy ()Wyślij do managera ()Udziel zgody ()

akceptuje zastępstwo 0..1

Scenariusz przypadku użycia: wystaw wniosek urlopowy

Scenariusz rozpoczyna się od wypełnienia przez pracownika formularza wniosku urlopowego, w którym podaje planowaną datę rozpoczęcia urlopu, datę zakończenia oraz zastępcę. Następnie system sprawdza, czy pracownik ma uprawnienia do urlopu we wnioskowanym wymiarze. jeśli nie, pracownik otrzymuje komunikat, że nie posiada wystarczającej liczby dni urlopu do wykorzystania i wniosek zostaje odrzucony jeśli tak, to wniosek zostaje wysłany do akceptacji do osoby wskazanej jako zastępca. Akceptacja wniosku przez zastępcę stanowi odrębny przypadek użycia, w którym aktorem jest zastępca.

Diagram współpracy odpowiadający diagramowi klas dla przypadku użycia: wystaw wniosek urlopowy

:Pracownik

: Pracownik

:Pracownik

1: Czy, możliwy urlop we wnioskowannym wymiarze ?

2: Wyślij wniosek do zastępcy

:Wniosek urlopowy

Wystaw wniosek

Podsumowanie Głównym zadaniem diagramów współpracy jest wsparcie projektanta w

procesie konstruowania modelu obiektowego (konkretnie diagramu klas). Pomoc polega na analizie zachowania systemu w trakcie realizacji jego zadań i identyfikowaniu nowych czy też korekcie już istniejących elementów modelu, np.: klas, ich atrybutów/metod oraz asocjacji między klasami.

Diagramy współpracy, będące wystąpienia fragmentu diagramu klas, bardzo dobrze przedstawiają związki między obiektami biorącymi udział w realizacji danego zadania przez co łatwiej można odwzorowywać efekty oddziaływania na pojedynczy obiekt.

W literaturze mówi się o dwóch kierunkach wykorzystywania diagramów, które pozostają wobec siebie w pewnej sprzeczności:

1. Specyfikacja wymiany komunikatów między obiektami w sposób tak prosty jak to tylko jest możliwe,

2. Generowanie za pomocą narzędzi CASE odpowiedniego kodu.