03_Diagramy UML(3).pdf

RAFAŁ KASPRZYK, copyright reserved

DIAGRAMY PRZYPADKÓW UŻYCIA

Przypadki użycia były w sposób intuicyjny stosowane w tradycyjnym

projektowaniu systemów informatycznych na długo przed pojawieniem się

metodyk obiektowych. Zasługą Jacobsona jest zarówno wyodrębnienie przypadków

użycia jako metody projektowania, jak i stworzenie metodyki i notacji graficznej dla tego

paradygmatu. Jak często bywa z powszechnie stosowanymi, lecz nie nazwanymi

rzeczami, kariera przypadków użycia w literaturze z zakresu projektowania systemów

informatycznych (SI) zaczęła się od wprowadzenia dla nich specjalnej nazwy,

przypisaniu tej nazwie określonego znaczenia i rozpropagowanie tego pojęcia jako

swego rodzaju paradygmatu projektowania SI.

Przypadek użycia jest to pewna nazwana, dobrze określona interakcja pomiędzy

użytkownikiem a systemem komputerowym . Przypadek użycia odwzorowuje

pewną funkcjonalność systemu w taki sposób, w jaki będą ją widzieć jego

przyszli użytkownicy . Jakkolwiek w tym stwierdzeniu można podejrzewać banał,

rzecz tak oczywistą, że nie warto o niej mówić, okazuje się, że dla dużych systemów o

wielu złożonych i wzajemnie powiązanych funkcjach tego rodzaju podejście ma ogromny

sens. Pozwala ono zapomnieć o detalach technicznych (nawet abstrahować od

architektury) i skoncentrować się na logice systemu. Podejście do projektowania od

strony przypadków użycia jest uważane za znacznie bardziej zdrowe od podejść

„technokratycznych”, ponieważ sprzyja ono punktowi widzenia, w którym

centralnym ośrodkiem zainteresowania staje się człowiek - przyszły użytkownik

systemu. Jak pokazały doświadczenia wielu projektów, jedną z głównych przyczyn ich

niepowodzeń było zbytnie skoncentrowanie się projektantów na detalach technicznych,

z pominięciem lub brakiem dostatecznej uwagi dla interakcji pomiędzy użytkownikami, a

systemem komputerowym.

Reasumując przypadek użycia można definiować na wiele sposobów. Oto kilka definicji:

 Przypadek użycia to wycinek funkcjonalności , którą system musi realizować,

aby spełnić wymagania

 Przypadek użycia jest zbiorem ciągów akcji wykonywanych przez system

w celu dostarczenia określonemu aktorowi godnego uwagi wyniku

 Przypadek użycia to zbiór scenariuszy powiązanych wspólnym celem

użytkownika . Przez scenariusz rozumiany jest tu ciąg kroków opisujących

interakcje między użytkownikiem, a systemem

Podejście przypadków użycia ma przede wszystkim na względzie określenie wymagań

funkcjonalnych na projektowany system. Celem tej metody jest:

 Identyfikacja wymagań funkcjonalnych

o Każdy przypadek użycia powinien opisywać realizację jakiegoś celu

biznesowego opisanego z punktu widzenia aktora używającego system

o Zbiór przypadków użycia stanowi podstawę do umowy między klientem, a

dostawcą

RAFAŁ KASPRZYK, copyright reserved

o Przypadki użycia ułatwiają zadanie ustalenia priorytetów dla wymagań

funkcjonalnych

 Odpowiedź na pytanie, co system ma robić bez określania sposobu realizacji

 Umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami

systemu

 Określenie granic systemu

 Ustalenie praw dostępu do zasobów

 Ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu

 Przygotowanie podstaw do szczegółowej analizy i projektowania

o Podstawa do identyfikacji klas i obiektów

o Określenie odpowiedzialności i współpracy obiektów

o Definicja przepływu komunikatów miedzy obiektami

 Weryfikacja poprawności i kompletności projektu

 Dostarczenie podstaw do sporządzenie planu testów systemu

Pomiędzy przypadkami użycia można wyróżnić przynajmniej trzy podstawowe relacje:

 Zawieranie

o Pozwala na współdzielenie fragmentu funkcjonalności pomiędzy

kilkoma przypadkami użycia. Do relacji zawierania dochodzi wówczas, gdy

kilka przypadków użycia ma wspólną sekwencję podobnych kroków, której

nie warto wciąż kopiować z jednego przypadku użycia do drugiego.

 Rozszerzanie

o Pozwala na warunkowe rozszerzenie funkcjonalności przypadku

użycia ”osadzone” w punkcie rozszerzenia. Rozszerzenie przypadku użycia

może więc wzbogacić go o dodatkowe zachowanie, ale w takiej sytuacji

podstawowy przypadek użycia musi określić pewne punkty rozszerzenia, a

rozszerzający przypadek użycia może dodać nowe zachowanie tylko w tych

punktach. Przypadek użycia może mieć wiele punktów rozszerzeń, a

rozszerzający przypadek użycia może rozszerzać podstawowy przypadek

użycia w kilku z tych punktów. Relacja rozszerzania służy do opisywania

opcjonalnego przepływu zdarzeń i pozwala na minimalizację liczby

zmian wprowadzanych do podstawowego przypadku użycia.

 Uogólnienie

o Pozwala na zilustrowanie różnych wariantów realizacji tego

samego przypadku użycia . W istocie jest bardzo podobne do

rozszerzania, jest jednak mniej formalne. Relacji uogólnienia używa się

wówczas, gdy dany przypadek użycia jest podobny do innego, ale jest

nieco obszerniejszy. Specjalizowany przypadek użycia może

przesłonić dowolną część podstawowego przypadku użycia , ale

zawsze powinien dotyczyć osiągnięcia tego samego celu użytkownika, co

podstawowy przypadek użycia. Relacja uogólnianie może być traktowana

RAFAŁ KASPRZYK, copyright reserved

jako sposób na przedstawienie szczególnej realizacji uogólnionego

przypadku użycia.

Diagramy przypadków użycia są bardzo proste i głównie dzięki temu tak użyteczne.

RAFAŁ KASPRZYK, copyright reserved

DIAGRAMY KLAS

Diagram klas jest ściśle powiązany z projektowaniem obiektowym systemów

informatycznych. Opisuje wyróżnione w systemie klasy obiektów i statyczne

powiązania między nimi . Zawiera on również takie elementy jak atrybuty i operacje

klas oraz ograniczenia nakładane na klasy obiektów i ich powiązania.

Modelując statyczne aspekty perspektywy projektowej, diagramów klas używa się do:

 Modelowanie słownictwa systemu . Zadanie to polega między innymi na

podejmowaniu decyzji, które abstrakcje są częścią rozważanego systemu, a które

nie i jakie zobowiązania ma każda z tych abstrakcji.

 Modelowanie prostych kooperacji . Kooperacja jest to zestaw klas,

interfejsów i innych bytów istniejących celem realizacji pewnego zespołowego

zachowania wymagającego współpracy wszystkich elementów. Nie należy skupiać

się nad jedną klasą, lecz nad zbiorem współpracujących ze sobą klas, by

zrozumieć, o co chodzi. W tym wypadku diagramy klas wykorzystuje się do

zobrazowania i określenia tego zbioru klas i związków między nimi.

 Modelowanie schematu logicznej bazy danych . Przez schemat rozumiany

jest plan projektu koncepcyjnego bazy danych. W wielu dziedzinach zachodzi

potrzeba trwałego przechowywania informacji w bazach danych. W tym wypadku

diagram klas wykorzystuje się do modelowania schematów takich baz danych.

Klasa jest opisem zbioru obiektów, które mają takie same:

 Atrybuty – opisują stan

o Najczęściej typy proste lub biblioteczne

o Nie posiadają własnych reguł biznesowych

o Ich wartości są istotne dla obiektów klasy

 Operacje – opisują zachowanie

o Usługi oferowane przez każdy obiekt klasy

o Zwykle powodują zmianę stanu obiektu

o Dzielą się na zapytania i polecenia

 Związki – uogólnienie, realizacja, zależność, asocjacja, agregacja, kompozycja

o Umożliwiają obrazowanie faktu, że zachowanie jednej klasy zależy od

zachowania innej klasy

o Powalają na unikanie antywzorów (np. ”BLOB”)

 Znaczenie

Klasa realizuje jeden bądź wiele interfejsów. Interfejs definiuje zewnętrznie

obserwowane zachowanie klasy lub komponentu, określając zbiór deklaracji

operacji, ale nigdy sposobu implementacji.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: