Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona19/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   15   16   17   18   19   20   21   22   ...   113

Diagramy przypadków użycia (Use Case diagram)


Przypadek użycia (Use Case) to jest konstrukcja, która pomaga analitykowi wspólnie z użytkownikami określić, jak system ma być używany. Zbiór przypadków użycia opisuje system za pomocą pojęć określających, co użytkownicy zamierzają z nim robić.

Każdy przypadek użycia to jest zbiór scenariuszy opisujących używanie systemu. Każdy scenariusz to jest ciąg zdarzeń. Każdy ciąg jest inicjowany przez osobę, przez inny system, przez jakieś urządzenie lub upływ czasu. Byty, które inicjują ciąg zdarzeń, nazywają się aktorami. Rezultatem zainicjowanego ciągu jest coś, co służy aktorowi, który dokonał inicjacji, albo innemu aktorowi.

Diagram klas jest narzędzie projektanta systemu, odwzorowujące system z punktu widzenia tego projektanta. Użytkownikom często trudno wyrazić słowami, w jaki sposób zamierzają korzystać z systemu. Tworzenie przypadków użycia to jest wspólne działanie użytkowników oraz projektantów. Podstawą omawianego działania jest skłonienie użytkowników do udziału we wczesnym stadium analizowania i projektowania systemu. Zwiększa to prawdopodobieństwo, że system ostatecznie stanie się przydatnym i przyjaznym narzędziem.

Diagramy przypadków użycia – diagram czynnościowy służący do obrazowania zachowania systemu w taki sposób, aby użytkownicy mogli zrozumieć jak z niego korzystać. Na ogół zawierają one takie elementy jak: przypadki użycia, aktorzy, zależności, uogólnienia i asocjacji (powiązania).

Za pomocą diagramów przypadków użycia dokonuje się:


  • modelowania otoczenia systemu (wyznaczenie granicy wokół całego systemu i na wskazaniu leżących poza nim aktorów);

  • modelowania wymagań stawianych systemowi (określenie co system powinien robić, niezależnie od tego jak ma to robić - znane jest otoczenie i sposób porozumiewania się z systemem, ale nie jego wnętrze).

Każdy oddzielny przypadek użycia (element Use Case) odwzorowuje wyznaczony aspekt funkcji systemu. Wszystkie elementy Use Case składają się pełny zbiór tych funkcji. Ten sposób dekompozycji pozwala opracować elementy Use Case dla różnych funkcji, oraz potem zjednoczyć ich razem. To znaczy, że w każdy wyznaczony moment czasu można skupić się na jednym problemu oraz realizować równolegle projektowanie różnych części systemu.

Każdemu zadaniu użytkownika może odpowiadać oddzielny przypadek użycia.

Modelując otoczenie systemu należy postępować zgodnie z podanymi wytycznymi:


  1. Zidentyfikować aktorów działających wokół systemu:

W tym celu należy rozważyć, które grupy:

  • potrzebują pomocy systemu do realizacji swoich zadań,

  • są niezbędne do realizacji systemu,

  • są w interakcji z urządzeniami zewnętrznymi,

  • wypełniają drugorzędne funkcje,

  1. Należy uporządkować podobnych aktorów za pomocą uogólnień.

  2. Dla zwiększenia czytelności modelu można (jeżeli trzeba) dodać stereotypy do aktorów.

  3. Umieścić zdefiniowanych aktorów na diagramach przypadków użycia i zdefiniować powiązania z przypadkami użycia.

Modelowanie otoczenia systemu jest przydatne przy tworzeniu złożonych systemów z wzajemnie powiązanymi podsystemami.

Modelując wymagania stawiane systemowi należy postępować zgodnie z podanymi wytycznymi:



  1. Określić otoczenie systemu i zidentyfikować otaczających go aktorów;

  2. W przypadku każdego aktora należy rozważyć działania, których on oczekuje lub wymaga od systemu i zapisać te działania w postaci przypadków użycia;

  3. Wyselekcjonować powtarzające się fragmenty działań i utworzyć z nich nowe przypadki użycia, które będą dołączane prze inne przypadki użycia;

  4. Wydzielić warianty działań i umieścić je w nowych przypadkach użycia, które rozszerzają główne ciągi zdarzeń innych przypadków użycia;

  5. Do modelowanego systemu można dołączyć notatki określające wymagania niefunkcjonalne;



Wymogi do scenariuszy przypadków użycia


Przypadki użycia to są wymogi funkcjonalne do systemu informatycznego. Przypadek użycia opisuje, co system robi, ale nie określa, jak to robi. Wymogi mogą mieć werbalny oraz formalny kształt. Opisy przypadków użycia mogą być realizowane przez:

  • ciągi zdarzeń

  • scenariusze.

Zapisując ciąg zdarzeń, trzeba uwzględnić informację o tym, jak i kiedy przypadek użycia zaczyna się i kończy, kiedy dochodzi do jego interakcji z aktorami i jakie obiekty są przekazywane. Należy także podać główny ciąg zdarzeń i inne, alternatywne.

Zazwyczaj na początku ciąg zdarzeń przypadku użycia opisuje się tekstowo przez scenariusze. UML pozwoli stworzyć werbalne oraz formalne opisy wymóg do systemu informatycznego, które mogą być przechowywane w specyfikacji każdego przypadku użycia.

Formalny sposób opisu może być realizowany przez diagramy interakcji (przebiegu oraz kolaboracji).

Werbalny sposób może być realizowany przez scenariusze. Często scenariusze nazywają ciągami zdarzeń nie wyróżniając te dwa pojęcia. Scenariusze są dla przypadków użycia tym, czym dla klas obiekty, to znaczy są egzemplarzami przypadków użycia. Scenariusze muszą zawierać następne rodzaje:



  1. Główny wykonawca (aktor) scenariuszu, dla którego jest wyznaczona konsekwentność zdarzeń.

  2. Inne osoby, które są zaciekawione w tym przypadku użycia oraz wymogi tych osób. Scenariusz musi realizować wymogi różnych kategorii użytkowników, które w sposób pośredni mogą otrzymać rezultaty.

  3. Warunki wstępne (precondition). To są warunki, które muszą być spełnione przed uruchomieniem scenariuszy.

  4. Warunki końcowe (postcondition). To są warunki, które muszą być spełnione po uruchomieniu scenariuszy.

  5. Scenariusz główny (główny proces). To jest główna konsekwencja czynności, która wyznacza przypadek użycia. Ta konsekwencja nie zawiera opis algorytmu z warunkami oraz rozgałęzieniem. Scenariusz główny zawiera następne komponenty:

    • współdziałanie między wykonawcami;

    • weryfikacja z boku systemu ( np. sprawdzenie identyfikatora towaru);

    • zmiana stanu systemu, wstawianie lub modyfikacja niektórych bytów.

Każde zdanie scenariusza musi być w krótkiej oraz zrozumiałej formie oraz mieć postać: rzeczownik – czasownik - rzeczownik.

  1. Rozszerzenia lub scenariuszy alternatywne. Scenariusze alternatywne to są rozgałęzienie scenariuszu głównego. W tym rozdziale muszą być wyznaczone warunki rozgałęzienia oraz reakcje na te warunki. Scenariusz alternatywny musi być skojarzony z punktami scenariusza głównego.

  2. Wymogi specjalne. W tym rozdziału są wymogi nie funkcjonalne, ewentualne parametry wydajności, prędkości, efektywności.

  3. Lista technologii i typów danych ( Np. wykorzystanie kart elektronicznych, typy kodowania towarów).

  4. Częstotliwość wykorzystania.

  5. Pytania które jeszcze nie otrzymały rozwiązania.

Przykład scenariuszy przypadku użycia „Sprzedaż towarów”.

Główny wykonawca. Kasjer.

Osoby które są zaciekawione w tym przypadku użycia oraz wymogi tych osób.

  • Kasjer. Chce szybko oraz precyzyjne wprowadzić informacje pro towary oraz wyznaczyć cenę zakupu. Błąd przy wyznaczeniu ceny będzie poprawiony przez pensję kasjera.

  • Klient. Chce kupić towar oraz szybko załatwić zakup, otrzymać paragon dla ewentualnego powrotu towaru.

  • Firma. Chce precyzyjne zachować transakcję pro zakup oraz zadowolić klienta.

Warunki wstępne. Kasjer jest identyfikowany oraz sprawdzony na autentyczność.

Warunki końcowe. Dani pro zakup są przechowywane w bazie danych. Paragon jest stworzony.

Scenariusz główny.

1. Klient wchodzi do sklepu, wybiera towary oraz idzie do aparatu kasowego.

2. Kasjer odkrywa nowy zakup.

3. Kasjer odczyta identyfikator towaru i wprowadzi go do systemu informacyjnego.

4. System informacyjny odczyta nazwę odebranego towaru, go opis i cenę. Kasjer powtórzy czynności p.3,4 dla każdej pozycji towaru.

5. Kasjer informuje klienta pro wartość wypłaty i otrzymuje pieniędzy.

6. Klient płaci się oraz system modyfikuje dani sklepu zgodnie z rezultatami zakupu.

7. System rejestruje zakup w rejestrze sklepu.

8. System drukuje paragon .

Rozszerzenia lub scenariuszy alternatywne.

3a. Błąd identyfikatora.


    1. System komunikuje pro błąd oraz skasuje wprowadzenie towaru.

3-6a. Klient rezygnuje się z zakupu jednego z towarów.

    1. Kasjer wprowadzi identyfikator towaru dla usuwania z zakupu.

    2. System odwzorowuje cenę zakupu bez usuniętego towaru.

5a. Klient komunikuje pro ulgę (jest pracownikiem tego przedsiębiorstwa).

    1. Kasjer formuje zapytanie pro ulgę.

    2. Kasjer wprowadzi dani klienta.

    3. System wyznacza ulgę dla klienta.

Przykłady ewentualnych błędów przy opracowaniu scenariuszy przypadków użycia


1. Zamiast opisu punktu scenariusza w postaci czynności: rzeczownik – czasownik – rzeczownik, piszą wymogi funkcjonalne do systemu.

Wymogi wyznaczają to, co system musi realizować. Scenariusz opisuje czynności użytkownika oraz reakcję na nich systemu. Tekst scenariusza musi być specyfikacją zachowania systemu. Ten tekst może być ewentualne rozmieszczony w lewej części diagramu przebiegu, żeby było zrozumiałe w jaki sposób system ( przedstawiony obiektami oraz komunikatami) realizuje swoje zachowanie.






Scenariusz główny( Use Case – „Zmienić zawartość koszyka”)

Nieprawidłowe

1.Kiedy Klient zachce zmienić ilość towaru w koszyku, to system musi zachowywać nową ilość towaru, oraz potem wylicza i odwzorowuje nową wartość zakupu.

Prawidłowe

1. Na stronie Koszyka Klient zmieni się ilość towaru w koszyku oraz wciśnie się przycisk „Ponowić”.

2. System zachowa dani pro ilość towaru , a potem odwzorowuje na stronie Koszyka nową wartość zakupu.








Scenariusz alternatywny (musi zawierać na początku warunek IF... THEN)

Nieprawidłowe

System usuwa towar z koszyka, kiedy ilość towaru zostanie równą 0

Prawidłowe

Kiedy Klient wpisze wartość 0 jako nową ilość towaru, to system usuwa towar z koszyka.

2. W scenariuszu opisują bezpośrednio same atrybuty oraz metody zamiast sposobów ich wykorzystywania.






Scenariusz główny (Use Case – „Dostarczyć Towar”

Nieprawidłowe

1.Odbiorca towaru zgodnie z każdym Wierszem Zamówienia w Zamówieniu formuje paczkę towarów dla klienta.

2. Odbiorca odczytuje kody kreskowe z listy opakowania.

3.System realizuje metodę „Zmienić stan zamówienia”, żeby zmienić stan zamówienia na „zrealizowane”, oraz potem wywoła metodę „zmienić ilość towaru w bazie danych” dla każdej pozycji towaru.

4.Odbiorca oddaje paczkę dostawce.



Prawidłowe

1.Odbiorca towaru zgodnie z każdym Wierszem Zamówienia w Zamówieniu formuje paczkę towarów dla klienta.

2. Odbiorca odczytuje kody kreskowe z listy opakowania.

3. System zmieni się stan zamówienia na „zrealizowane”.

4. System modyfikuje ilość towarów z listy w bazie danych.






Scenariusz główny (Use Case – „Przegląd listy towarów”

Nieprawidłowe

1.Klient wciśnie się przycisk „Kategoria” na Stronie Przeglądu Artykułów”

2.System wywoła metodę „Odwzorować Podkategorii” obiektu „Kategoria”.



Prawidłowe

1.Klient wciśnie się przycisk „Kategoria” na Stronie Przeglądu Artykułów”

2. System odwzorowuje podkategorii danej kategorii.














1   ...   15   16   17   18   19   20   21   22   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna