Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

Transkrypt

1 Inżynieria oprogramowania Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

2 Punkt widzenia (Point of View) Systemy oprogramowania mają zwykle kilku różnych użytkowników. Wielu uczestników interesuje się wymaganiami systemowymi. Przykład: system bankomatowy, służy do automatycznego dokonywania operacji bankomatowych. Usługi: Wypłata, Wpłata, Przekazywanie informacji

3 Uczestnicy systemu bankomatowego Klienci banku Klienci innych banków Dyrektorzy oddziałów banków Pracownicy obsługi klienta w oddziałach Administratorzy baz danych Dział bezpieczeństwa banku Dział marketingu banku Inżynierowie pielęgnacji sprzętu i oprogramowania

4 Model zewnętrznych punktów widzenia Bierzemy pod uwagę punkty widzenia takich klas użytkowników, którzy: Otrzymują usługi od systemu Przekazują do niego dane i sygnały sterujące Techniki analizy wymagań metodą punktów widzenia: Metoda VORD Przypadki użycia i diagramy sekwencji UML

5 Metoda VORD (Viewpoint-Oriented Requirements Definition) Identyfikacja punktów widzenia Polega na znajdowaniu punktów widzenia, których reprezentanci są użytkownikami systemu, oraz usług oferowanych tym reprezentantom. Strukturalizacja punktów widzenia Polega na budowaniu hierarchii punktów widzenia. Dokumentowanie punktów widzenia Tworzenie opisu znalezionych punktów widzenia i usług. Przyporządkowywanie punktów widzenia do systemu Znajdowanie w projekcie systemu oprogramowania obiektów, które będą dostarczać usługi.

6 Szablony formularzy Szablon do opisu punktu widzenia Odnośnik (nazwa punktu widzenia) Atrybuty (cechy informujące o punkcie widzenia) Zdarzenia (odnośnik do scenariuszy zdarzeń opisujących) Usługi (odnośnik do zbioru opisów usług) PW (nazwy podrzędnych punktów widzenia) Szablon do opisu usługi Odnośnik (nazwa usługi) Uzasadnienie (przyczyna oferowania usługi) Specyfikacja (odnośnik do listy specyfikacji usług, które mogą być opisane za pomocą różnych notacji) Punkty widzenia (lista nazw punktów widzenia, których reprezentanci korzystają z usługi) Wymagania niefunkcjonalne (odnośnik do zbioru wymagań niefunkcjonalnych ograniczających usługę) Dostawca (odnośnik do listy obiektów, które oferują tę usługę)

7 Burza mózgów w trakcie identyfikacji Pytanie o saldo Zasoby maszyny Interfejs użytkownika Właściciel konta Zdalna diagnostyka punktów widzenia Odczyt transakcji Informacje o koncie Karta skradziona Niezawodność Menedżer Koszt systemu Aktualizacja konta Baza danych klientów Dziennik komunikatów Zwrot karty Przelew środków Wypłata gotówki Zdalna aktualizacja oprogramowania Rozmiar oprogramowania Dziennik transakcji Zamówienie czeków Kasa banku Obcy klient Drukarka Nieuprawniony użytkownik Pielęgnacja Zabezpieczenia Zamówienie oprogramowania Zatrzymanie wyciągu karty Przekazywanie komunikatów Weryfikacja karty

8 Informacja o usługach przypisanych do punktów widzenia Właściciel konta Obcy klient Pracownik banku Lista usług Lista usług Lista usług Wypłata gotówki Pytania o saldo Zamówienie czeków Wysyłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków Wypłata gotówki Pytania o saldo Diagnostyka Dodanie gotówki Dodanie papieru Wysłanie komunikatu

9 Dane związane z punktami widzenia Właściciel konta Dane sterujące Dane wejściowe Rozpocznij transakcje Informacje z karty Anuluj transakcje Zakończ transakcje Wybór usługi PIN Żądana kwota Komunikat

10 Hierarchia punktów widzenia Wszystkie PW Usługi Pytanie o saldo Wypłata gotówki Klient Personel banku Usługi Kasa Menedżer Inżynier Zamówienie czeków Wysłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków Właściciel konta Klient obcy

11 Opis punktu widzenia klienta i usługi wypłaty gotówki Odnośnik: Atrybuty: Zdarzenia: Klient Numer konta PIN Zacznij transakcję Wybierz usługę Anuluj transakcję Zakończ transakcję Odnośnik: Wypłata gotówki Uzasadnienie: Celem jest przyśpieszenie obsługi klienta i zmniejszenie liczby dokumentów papierkowych Specyfikacja: Użytkownicy wybierają tę usługę przez naciśnięcie przycisku wypłata gotówki. Następnie wprowadzają żądaną kwotę. Potwierdza się ją i jeśli na koncie są środki następuje wypłata PW: Klient Usługi: Wypłata gotówki Info o saldo Podrzędne PW: Właściciel konta Wymagania niefunkcjonalne: Wypłać gotówkę najpóźniej po 1 minucie od potwierdzenia kwoty Dostawca: Wypełnić później

12 Scenariusz Szczegółowy opisy poszczególnych interakcji z systemem, obejmuje jedną lub najwyżej kilka możliwych interakcji. Atrybuty scenariusza: Opis stanu systemu na początku scenariusza. Opis normalnego następstwa zdarzeń scenariusza. Opis tego, co może pójść źle, i jak to będzie obsługiwane. Informacje o innych czynnościach, które można wykonywać w tym samym czasie. Opis stanu systemu po zakończeniu scenariusza.

13 Scenariusze zdarzeń w VORD Dokumentowanie zachowania systemu, po zajściu konkretnego zdarzenia. Przykłady zdarzeń: wsunięcie karty do bankomatu wybranie usługi Scenariusze obejmują: opis przepływu danych akcje systemu wyjątki, które mogą się pojawić

14 Diagram scenariusza zdarzeń Event Sequence Diagram (IBM) A session management application

15 Przypadki użycia Metodą określania wymagań opartą na scenariuszach Obecnie podstawowy element notacji UML W najprostszej postaci w przypadku użycia definiuje się aktorów biorących udział w interakcji i wskazuje typ tej interakcji

16 Przypadek użycia Wypłata gotówki Wypłata gotówki Klient

17 Przypadki użycia systemu obsługi bankomatu Klient własny Przelew środków Wypłata gotówki Personel Klient obcy Dodanie gotówki

18 Diagramy sekwencji (UML) Modelują zachowanie systemu (scenariusz), najczęściej jakiś przypadek użycia Uczestnicy (obiekty) prostokąty Strzałki wiadomości przesyłane pomiędzy uczestnikami Strzałki przerywane wartości zwracane Pionowe linie przerywane linie życia obiektów Pionowe prostokąty na liniach życia przetwarzanie obsługujące daną wiadomość

19 Diagram sekwencji: wypłata ATM Database Card PIN request Card number Card OK PIN Option m enu Validate card <<exception>> invalid card Withdraw request Amount request Amount <<exception>> insuf ficient cash Balance request Balance Debit (amount) Debit response Handle request Card Card rem oved Cash Cash rem oved Receipt Complete transaction

20 Sprawdzenie wymagań Sprawdzenie ważności Czy system udostępnia usługi, których potrzebuje klient? Sprawdzenie niesprzeczności Czy wymagania nie są sprzeczne? Sprawdzenie kompletności Czy zdefiniowano wszystkie funkcje i ograniczenia? Sprawdzenie realności Czy wymagania mogą być naprawę zaimplementowane? Możliwość weryfikacji Czy wymagania są napisane tak, że można je później weryfikować? Cel: uniknięcie sporów między klientem a zleceniobiorcą

21 Metody zatwierdzania wymagań Przeglądy wymagań Zespół recenzentów systematycznie analizuje wymagania. Prototypowanie W tym podejściu do zatwierdzania przedstawia się użytkownikom i klientom wykonywalny model systemu. Generowanie testów Idealnie byłoby, aby wymagania dało się testować. Zautomatyzowane sprawdzanie sprzeczności Jeśli wymagania wyrażono w modelu systemu za pomocą strukturalnej lub formalnej notacji, to narzędzia CASE mogą sprawdzić niesprzeczność systemu.

22 Ewolucja wymagań Wstępne zrozumienie problemu Zmienione rozumienie problemu Wstępne wymagania Zmienione wymagania Czas