Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 1 Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa.

Podobne prezentacje


Prezentacja na temat: "K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 1 Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa."— Zapis prezentacji:

1 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 1 Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Wykład 1 Projektowanie systemów informacyjnych Zadania inżynierii oprogramowania Analiza wymagań Model use cases (przypadków użycia)

2 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 2 Podstawowe pojęcia Dziedzina problemowa (dziedzina przedmiotowa) Cel Zakres odpowiedzialności systemu Kontekst (systemy zewnętrzne, interjfejsy, aktorzy) Wymagania wstępne (wymagania użytkownika) Wymagania na system Wymagania funkcjonalne Wymagania niefunkcjonalne Ewolucja systemu

3 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 3 Co to znaczy jakość oprogramowania Poprawność określa, czy oprogramowanie wypełnia postawione przed nim zadania (tzn., czy spełnia wyspecyfikowane wymagania) i czy jest wolne od błędów. Łatwość użycia jest miarą stopnia łatwości korzyst ania z oprogramowania. Czytelność pozwala na określenie wysiłku niezbędnego do zrozumienia oprogramowania. Ponowne użycie (inne terminy to: wielokrotne użycie lub wielo-użycie) charakteryzuje przydatność oprogramowania, całego lub tylko pewnych fragmentów, do wykorzystania w innych produktach programistycznych. Stopień strukturalizacji (modularność) określa, jak łatwo oprogramowanie daje się podzielić na części o dobrze wyrażonej semantyce i dobrze wyspecyfikowanej wzajemnej interakcji. Efektywność opis uje stopień wykorzystania zasobów sprzętowych i programowych stanowiących podstawę działania oprogramowania. Przenaszalność mówi o łatwości przenoszenia oprogramowania na inne platformy sprzętowe czy programowe. Skalowalność opisuje zachowanie się oprogramowania przy rozroście liczby użytkowników, objętości przetwarzanych danych, dołączaniu nowych składników do systemu, itp. Współdziałanie charakteryzuje zdolność oprogramowania do niezawodnej współpracy z innym niezależnie skonstruowanym oprogramowaniem.

4 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 4 Fazy cyklu życiowego w procesie konstrukcji produktu programistycznego Faza strategiczna Faza specyfikacji i analizy wymagań Faza projektowania Faza konstrukcji (implementacji) Faza testowania Faza konserwacji czas

5 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 5 Modele wg Jacobsona Model przypadków użycia: definiuje zewnętrze (aktorów, systemy zewnętrzne, kontekst) oraz wnętrze (przypadki użycia), określające zachowanie się systemu. Obiektowy model dziedziny odwzorowujący obiekty świata rzeczywistego, tzw. dziedziny problemowej Obiektowy model analityczny opisujący dokładną strukturę istniejącego systemu Obiektowy model projektowy opisujący założenia przyszłej implementacji Model implementacyjny reprezentujący konkretną implementację systemu Model testowania, okreslający plan testów, specyfikacji i raportów Modele wymagają odpowiednich procesów ich tworzenia: Analiza wymagań, składająca się z dwóch podprocesów - proces modelowania przypadków użycia - proces modelowania dziedziny problemowej Proces analizy związany z obiektowym modelem analitycznym Proces projektowania Proces implementacji Proces testowania

6 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 6 Model wymagań Model przypadków użycia Opis interfejsów Obiektowy model dziedziny problemowej Składowe: Model przypadków użycia wprowadza następujące pojęcia: Aktor Przypadek użycia Reprezentuje rolę, którą może grać w sytemie jakiś jego użytkownik; (np. kierownik, urzędnik, klient) Reprezentuje sekwencję operacji, niezbędnych do wykonania zadania zleconego (zainicjowanego) przez aktora, np. potwierdzenie pisma, złożenie zamówienia, itp. Przypadki użycia reprezentują przepływ operacji w systemie. Są one uruchamiane (inicjowane) przez aktorów. Aktorem jest dowolny byt zewnętrzny, który uczestniczy w interakcji z przypadkiem użycia. Kilku fizycznych użytkowników może pełnić rolę jednego aktora i wice- versa. Można stosować struktury generalizacji-specjalizacji dla aktorów. Każdy potencjalny aktor używa (może używać) system na pewną liczbę jemu właściwych sposobów. Każdy z tych sposobów nosi nazwę przypadku użycia. nazwa przypadku (tu) nazwa przypadku (lub tutaj) nazwa aktora

7 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 7 Notacja w modelu przypadków użycia Przypadek użycia. Powinien mieć unikalną nazwę, opisującą przypadek użycia z punktu widzenia jego zasadniczych celów. Lepiej jest stosować nazwę opisującą czynność (sekwencja operacji) niż polecenie. klient Aktor. Powinien mieć unikalną nazwę. Interakcja. Pokazuje interakcję pomiędzy przypadkiem użycia a aktorem. weryfikacja klienta Blok ponownego użycia. Pokazuje pewien fragment systemu, który jest używany w kilku przypadkach użycia. (Może być także oznaczony jako samodzielny przypadek użycia.) wypłata pieniędzy Relacja typu > lub >. Pokazuje związek zachodzący między dwoma przypadkami użycia ( > lub rozszerza>>) lub przypadkiem użycia a blokiem ponownego użycia ( >). System obsługi klienta Nazwa systemu wraz z granicami systemu. Pokazuje granicę pomiędzy systemem i jego otoczeniem....system informacyjny... >

8 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 8 Aktor Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych w jakiś sposób z wykorzystywaniem projektowanego systemem (przyszli użytkownicy, ale nie tylko). Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np. biuro prawne) lub inny system komputerowy. Metoda modeluje aktorów, a nie konkretne osoby. Jedna osoba może pełnić rolę wielu aktorów; np. być jednocześnie sprzedawcą i klientem. I odwrotnie, jeden aktor może odpowiadać wielu osobom, np. strażnik budynku. Aktor jest tu pierwotną przyczyną napędzającą przypadki użycia. Jest on sprawcą zdarzeń powodujących uruchomienie przypadku użycia, jak też odbiorcą informacji wyprodukowanych przez przypadki użycia. Sprawca zdarzeń? Czy system może być aktorem sam dla siebie ?

9 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 9 Przykład diagramu przypadków użycia klient banku wpłata pieniędzy wypłata pieniędzy klient banku wpłata pieniędzy wypłata pieniędzy Oczywiście, w operacjach wpłaty i wypłaty pieniędzy mogą uczestniczyć także inni aktorzy, np. kasjer. Możemy go dołączyć jako kolejny element rozbudowujący nasz model. kasjer

10 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 10 Przykład diagramu przypadków użycia klient operator Automat do sprzedaży papierosów zakup paczki papierosów uzupełnienie towaru operacje pieniężne sporządzenie raportów kontroler

11 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 11 Relacje: > i > naprawa samochodu przegląd samochodu sprzedaż samochodu rejestracja klienta używa umycie samochodu rozszerza przyholowanie samochodu rozszerza używa: wskazuje na wspólny fragment wielu przypadków użycia, wyłączony przed nawias - wykorzystywane w przebiegach podstawowych (funkcje zawsze wykonywane) rozszerza: strzałka prowadzi od przypadku użycia, który czasami rozszerza inny przypadek użycia - wykorzystywane w przebiegach opcjonalnych (funkcje nie zawsze wykonywane) rozszerza

12 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 12 Przykład wykorzystania relacji > podsystem zarządzania bazą danych banku klientadministrator systemu prowadzenie konta klienta informowanie o stanie konta klienta inicjalizacja karty klienta weryfikacja karty i kodu klienta Automat do operacji bankowych >

13 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 13 Rozbudowa modelu przypadków użycia klient banku wpłata pieniędzy wypłata pieniędzy kasjer sprawdź bilans weź pożyczkę zarząd banku klient banku wpłata pieniędzy wypłata pieniędzy kasjer sprawdź stan konta weź pożyczkę zarząd banku > Model przypadków użycia można rozbudowywać poprzez dodawanie nowych aktorów, przypadków użycia czy relacji pomiędzy przypadkami użycia. uaktualnianie stanu konta >

14 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 14 Charakterystyka modelu przypadków użycia Model przypadków użycia dostarcza bardzo abstrakcyjnego spojrzenia na system. Spojrzenia z pozycji aktorów, którzy go używają. Nie włącza zbyt wielu szczegółów, co pozwala wnioskować o fukcjonalności systemu (zbiorze funkcji, które obsługuje) na odpowiednio wysokim, abstrakcyjnym poziomie. Podstawowym zastosowaniem jest tu bowiem dialog z przyszłymi użytkownikami zmierzający do sformułowania poprawnych wymagań na system. edycja programu kompilacja programu wykonanie programu drukowanie pliku programista użytkownik > Tworzenia przypadków użycia jest niezdeterminowane i subiektywne. Na ogół różni analitycy tworzą różne modele. Model zbyt szczegółowy - utrudnia analizę, zbyt ogólny - nie pozwala na wykrycie bloków ponownego użycia.

15 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 15 Zależności czasowe między przypadkami użycia Właściwie nie występuje w tym modelu nacisk na uwzględnianie zależności czasowych między przypadkami użycia, tzn. nie interesuje nas wzajemna kolejność przypadków użycia (co oznacza, że mogą być konstruowane w dowolnej kolejności), ale jeśli... p1 p2 > p1 p2 > Przebieg podstawowy - p1 (przypadek bazowy, podstawowy) zawsze używa p2, a więc p1 musi być pierwsze w kolejności działania. Przebieg opcjonalny - p1 (przypadek bazowy, podstawowy) jest czasami rozszerzane o p2, tutaj też p1 musi być pierwsze w kolejności działania.

16 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 16 Przypadek użycia w postaci diagramu interakcji Przesyłanie komunikatów pomiędzy blokami: k1 k2 k3 k4 k5 Blok 1Blok 2Blok 3Blok 4 Blok: obiekt k i - komunikat, czyli polecenie wykonania operacji; komunikat nosi nazwę tej operacji czas Aktor

17 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 17 Przykład diagramu interakcji wpłata pieniędzy Wypełnij formularz wpłaty Podaj formularz i gotówkę do kasy Zwiększ konto klienta Zwiększ bilans kasy Zwiększ bilans banku Wydaj pokwitowanie dla klienta formularz kasakonto bank wypełnij podaj zwiększ bilans zwiększ bilans wydaj pokwitowanie klient scenariusz

18 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 18 Dokumentacja przypadków użycia 1. Diagramy przypadków użycia (aktorzy, przypadki użycia i relacje zachodzące między przypadkami) 2. Krótki, ogólny opis każdego przypadku użycia: - jak i kiedy przypadek użycia zaczyna się i kończy - opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce i co jest przesyłane. - kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie, lub jak i kiedy zapamiętuje dane w systemie - wyjatki występujące przy obsłudze przypadku - specjalne wymagania, np. czas odpowiedzi, wydajność - jak i kiedy używane są pojęcia dziedziny problemowej 3. Opis szczegółowy każdego przypadku użycia - scenariusz - uczestniczące obiekty - diagram interakcji Dokumentacja przypadków użycia powinna zawierać:

19 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 19 Opis przypadków użycia (cd.) 1. Nieformalnego tekstu bez pokazywania przepływu operacji 2. Tekst nieformalny, łatwy do czytania, z jasno zaznaczonym przepływem operacji 3. Styl formalny z użyciem pseudo-kodu Prace niezbędne do skonstruowania modelu przypadków użycia 1. Wyszczególnienie pojęć (związanych z aktorami i przypadkami użycia) 2. Zdefiniowanie interakcji aktorów z przypadkami użycia 3. Ustanowienie zwiazków > 4. Ustanowienie związków > 5. Szkicowy opis przepływu operacji (utworzenie scenariuszy) 6. Skonstruowanie diagramów interakcji 7. Przedyskutowanie i krytyka modelu 8. Sprawdzenie kompletności modelu Opis przypadków użycia może być w postaci:

20 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 20 Metoda oparta na przypadkach użycia Metoda dotyczy analizy wymagań i opiera się na kilku krokach. Metoda jest oparta na ścisłej współpracy z przyszłym użytkownikiem. Jednocześnie jest budowany obiektowy model dziedziny. Nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika. Ścisła współpraca z przyszłym użytkownikiem implikuje zasadę: Krok Udokumentowany w: Sporządzenie słownika pojęć Słownik pojęć Ustalenie aktorów Ustalenie przypadków użycia Opis każdego przypadku użycia plus: * podział na nazwane części * znalezienie wspólnych części w różnych przypadkach użycia Dokument opisu aktorów Diagram przypadków użycia

21 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 21 Sporządzanie słownika pojęć Słownik dotyczy dziedziny problemowej. Tworzenie go polega na wyłowieniu wszystkich terminów z początkowych wymagań (wymagań wstępnych, wymagań użytkownika). Powinny być zdefiniowane w sposób precyzyjny i jednoznaczny. Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów, operacji, zdarzeń, itd. Terminy ze słownika powinny być normą przy opisie problemu, sytuacji lub modelu. Na co należy zwrócić uwagę przy kwalifikowaniu terminów do słownika: * na rzeczowniki - mogą one oznaczać aktorów lub obiekty dziedziny problemowej * na frazy opisujące funkcje, akcje, zachowanie się - mogą one być podstawą wyróżnienia przypadków użycia.

22 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 22 Ustalanie aktorów Przy ustalaniu aktorów istotne są odpowiedzi na następujące pytania: Jaka grupa użytkowników potrzebuje wspomagania ze strony systemu? Jacy użytkownicy są konieczni do tego, aby system działał i wykonywał swoje funkcje? Należy te funkcje rozbić na funkcje odnoszące się do: - dziedziny przedmiotowej, np. osoba rejestrująca korespondencję, - wspomagania systemu, np. administrator systemu Z jakiego elementów zewnętrznych (innych systemów, komputerów, czujników, sieci, itp.) musi korzystać system aby realizować swoje funkcje. Ustalanie potencjalnych aktorów musi być powiązane z ustalaniem granic systemu, tj. odrzucaniem obszarów dziedziny problemowej, którymi system nie będzie się zajmować (zakres odpowiedzialności systemu). Po wyszukaniu aktorów, należy ustalić: czy jest to aktor konkretny (Jan Kowalski) czy też określenie roli (magazynier) nazwę dla każdego aktora/roli zakresy znaczeniowe dla poszczególnych nazw aktorów oraz relacje pomiędzy zakresami (np. sekretarka pracownik administracji pracownik dowolna osoba). Niekiedy warto ustalić hierarchię dziedziczenia dla aktorów. czy użytkownik może łączyć funkcje kilku aktorów i jakich (minimalizacja aktorów)

23 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 23 Struktury generalizacji-specjalizacji dla aktorów (dziedziczenie) Pracownik administracji ma nie tylko uprawnienia na dostęp do funkcji (przypadków użycia) właściwych dla każdego pracownika, ale posiada też dostęp do funkcji związanych z jego własnym, specyficznym sposobem wykorzystywania systemu. osoba gość pracownik administracji

24 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 24 Analiza aktorów Jakie jest główne zadanie dla każdego aktora? Czy aktor będzie czytał/pisał/zmieniał jakąkolwiek informację w systemie? Czy aktor ma informować system o zmianach na zewnątrz? Czy aktor życzy sobie, aby być poinformowany o nieoczekiwanych zmianach? Wyjaśnienie różnic pomiedzy konkretnymi użytkownikami i aktorami UżytkownikAktor Przypadek użycia Może grać rolę Jest związany z: Jan Kowalski Adam Malina Gość Konkretny klient Administrator systemu Pracownik Osoba informowana Klient Przeładowanie systemu Wejście z kartą i kodem Uzyskanie informacji ogólnych Wypłata z konta

25 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 25 Ustalenie przypadków użycia Dla każdego aktora, znajdź funkcje (zadania), które powinien wykonywać w zwiazku z jego działalnością w zakresie zarówno dziedziny przedmiotowej, jak i wspomagania działalności systemu informacyjnego. Staraj się powiązać w jeden przypadek użycia zespół funkcji wspólnie realizujących ten sam cel. Unikaj rozbicia jednego przypadku użycia na zbyt wiele pod-przypadków, Nazwy dla przypadków użycia: powinny byc krótkie ale jednoznacznie określające charakter zadania lub funkcji. Nazwy powinny odzwierciedlać czynności z punktu widzenia aktorów, a nie systemu, np. wpłacanie pieniędzy, a nie przyjęcie pieniędzy od klienta. Opisz przypadki użycia przy pomocy zdań w języku naturalnym, używając terminów ze słownika. Uporządkuj aktorów i przypadki użycia w postaci diagramu. Niektóre z powstałych w ten sposób przypadków użycia mogą być mutacjami lub szczególnymi przypadkami innych przypadków użycia. Przeanalizuj powiązania aktorów z przypadkami użycia i ustal, które z nich są zbędne lub mogą być uogólnione.

26 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 26 Specyfikacja każdego przypadku użycia Wyodrębnij przypadki bazowe, tj. takie, które stanowią istotę zadania, są normalnym, standardowym użyciem. Pomiń czynności skrajne, wyjątkowe, uzupełniające lub opcyjne. Nazwij te przypadki bazowe. Ustal wzajemne powiązanie przypadków bazowych, poprzez ustalenie ich sekwencji, alternatywy, zależności, związku przyczyna-skutek, itd. Dodaj zachowanie skrajne, wyjątkowe, uzupełniające lub opcjonalne. Ustal powiązanie przypadków bazowych z tego rodzaju zachowaniem. Może ono byc także powiązane w pewną strukturę. Staraj się, aby bloki specyfikowane wewnątrz każdego przypadku użycia nie były zbyt ogólne lub zbyt szczegółowe. Zbyt szczegółowe bloki utrudniają analizę. Zbyt ogólne bloki zmniejszają możliwość wykrycia bloków wielokrotnego użycia. Struktura nie może być zbyt duża i złożona. Staraj się wyizolować bloki wielokrotnego użycia. Przeanalizuj podobieństwo nazw przypadków użycia, podobieństwo nazw i zachowania bloków występujących w ich specyfikacji. Wydzielenie bloku wielokrotnego użycia może być powiązane z określeniem bardziej ogólnej funkcji lub dodaniu nowej specjalizacji do istniejącej funkcji.

27 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 27 Dlaczego wzrasta znaczenie modelu przypadków użycia? Główne zadanie modelu przypadków użycia to prawidłowe określenie wymagań na projektowany system. Prawidłowe określenie wymagań na system uznawane jest za jeden z podstawowych problemów w procesie konstrukcji. Przypadki użycia odwzorowywują strukturę systemu tak, jak ją widzą jego użytkownicy. Model przypadków użycia pozwala na: lepsze zrozumienie możliwych sposobów wykorzystania projektowanego systemu (przypadków użycia), co oznacza zwiększenie stopnia świadomości analityków i projektantów co do celów, czyli innymi słowy - funkcjonalności - tego systemu, ustalenie praw dostępu do zasobów, umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu, weryfikacja poprawności i kompletności projektu, zrozumienie strukturalnych własności systemu, ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu, dostarczenie podstawy do sporządzenia planu testów systemu.

28 K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 28 Przypadki użycia w analizie Potrzeby Pomysły Technologie Koncepcja zastosowania Eksperci Użytkownicy Doświadczenie w dziedzinie przedmiotowej Przypadki użycia Model dziedziny Model zastosowania Kompletny model analizy mocny wpływ słaby wpływ


Pobierz ppt "K.Subieta, Ewa Stemposz. Projektowanie systemów informacyjnych, Wykład 1, Folia 1 Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa."

Podobne prezentacje


Reklamy Google