Projektowanie systemów informacyjnych

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łaTechnik Komputerowych, Warszawa

Wykład 1

Projektowanie systemów informacyjnych

• Zadania inżynierii oprogramowania• Analiza wymagań • Model use cases (przypadków użycia)


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


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 korzystania 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ść opisuje 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.


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


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


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) przezaktora, 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


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.

weryfikacjaklienta

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 <<używa>> lub <<rozszerza>>. Pokazuje związek zachodzący między dwoma przypadkami użycia (<<używa>> lub rozszerza>>) lub przypadkiem użycia a blokiem ponownego użycia (<<używa>>).

System obsługi klienta

Nazwa systemu wraz z granicami systemu. Pokazuje granicę pomiędzy systemem i jego otoczeniem.

...system informacyjny...

<<używa>>


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 ?


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


Przykład diagramu przypadków użycia

klient operator

Automatdo sprzedażypapierosów

zakup paczkipapierosów

uzupełnienietowaru

operacjepieniężne

sporządzenieraportów

kontroler


Relacje: << rozszerza>> i <<używa>>

naprawasamochodu

przeglądsamochodu

sprzedażsamochodu

rejestracjaklienta

używa

używaużywa

umyciesamochodu

rozszerza

przyholowaniesamochodu

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 odprzypadku użycia, który czasami rozszerza inny przypadek użycia - wykorzystywane w przebiegach opcjonalnych (funkcje nie zawsze wykonywane)

rozszerza


Przykład wykorzystania relacji <<używa>>

podsystem zarządzania bazą

danych banku

klient

administratorsystemu

prowadzeniekonta klienta

informowanie o stanie konta klienta

inicjalizacjakarty klienta

weryfikacja kartyi kodu klienta

Automat do operacji bankowych

<<używa>>

<<używa>

>

<<używa>>


Rozbudowa modelu przypadków użycia

klientbanku

wpłata pieniędzy

wypłata pieniędzy

kasjer

sprawdźbilans

weźpożyczkę

zarządbanku

klientbanku

wpłata pieniędzy

wypłata pieniędzy

kasjer

sprawdźstan konta

weźpożyczkę

zarządbanku

<<używa>>

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

<<używa>>

<<używa>>


Charakterystyka modelu przypadków użyciaModel 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.

edycjaprogramu

kompilacjaprogramu

wykonanieprogramu

drukowaniepliku

programista użytkownik

<<<używa>>

<<używa>>

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.


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 czasowychmiędzy przypadkami użycia, tzn. nie interesuje nas wzajemna kolejność przypadkówużycia (co oznacza, że mogą być konstruowane w dowolnej kolejności), ale jeśli ...

p1 p2<<używa>>

p1 p2<<rozszerza>>

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.


Przypadek użycia w postaci diagramu interakcji

Przesyłanie komunikatów pomiędzy blokami:

k1

k2k3

k4

k5

Blok 1 Blok 2 Blok 3 Blok 4

Blok: obiektki - komunikat, czyli polecenie wykonania operacji; komunikat nosi nazwę tej operacji

czas

Aktor


Przykład diagramu interakcji

wpłata pieniędzy

Wypełnij formularz wpłatyPodaj formularz i gotówkę do kasyZwiększ konto klientaZwiększ bilans kasyZwiększ bilans bankuWydaj pokwitowanie dla klienta

formularz kasa konto bank

wypełnij

podaj

zwiększ

zwiększbilans

zwiększbilans

wydajpokwitowanie

klient

scenariusz


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ć:


Opis przypadków użycia (cd.)

1. Nieformalnego tekstu bez pokazywania przepływu operacji2. Tekst nieformalny, łatwy do czytania, z jasno zaznaczonym przepływem operacji3. 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życia3. Ustanowienie zwiazków <<używa>>4. Ustanowienie związków <<rozszerza>>5. Szkicowy opis przepływu operacji (utworzenie scenariuszy)6. Skonstruowanie diagramów interakcji7. Przedyskutowanie i krytyka modelu8. Sprawdzenie kompletności modelu

Opis przypadków użycia może być w postaci:


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


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.


Ustalanie aktorówPrzy 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)


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

pracownik administracji


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żytkownik Aktor Przypadek użyciaMoż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


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.


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.


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.


Przypadki użycia w analizie

Potrzeby

Pomysły

Technologie

Koncepcjazastosowania

Eksperci

Użytkownicy

Doświadczeniew dziedzinie

przedmiotowej

Przypadkiużycia

Modeldziedziny

Modelzastosowania

Kompletnymodelanalizy

mocny wpływsłaby wpływ

Projektowanie systemów informacyjnych

Documents

Transcript of Projektowanie systemów informacyjnych