Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw.

Podobne prezentacje


Prezentacja na temat: "Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw."— Zapis prezentacji:

1 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Wykład 1 Kryzys oprogramowania Model przypadków użycia

2 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 2 Zalecana literatura E. Stemposz, K. SUBIETA: Slajdy do wykładu Projektowanie systemów informacyjnych J. Płodzień, E. Stemposz: Analiza i projektowanie systemów informatycznych, wydawnictwo PJWSTK, 2003 i wydanie II-gie rozszerzone 2005 K. SUBIETA: Obiektowość w projektowaniu i bazach danych, Akademicka Oficyna Wydawnicza PLJ, 1998 K. SUBIETA: Słownik terminów z zakresu obiektowości, Akademicka Oficyna Wydawnicza PLJ, 1999 M. Fowler, K. Scott: UML Distilled, Addison-Wesley 1997 J. Rumbaugh, I. Jacobson, G. Booch: The Unified Modeling Language Reference Manual, Addison-Wesley, 1999 OMG Unified Modeling Language. Specification, Version 1.5, The Object Management Group, 2003, T. Quatrani: Visual Modeling with Rational Rose 2000 and UML, Addison-Wesley, 2000 C. Larman: Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design, Prentice-Hall, Inc., 1998

3 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 3 Zagadnienia Czynniki jakości oprogramowania Notacja Analiza aktorów Analiza przypadków użycia Relacje między przypadkami użycia Relacje między aktorami Określanie aktorów Określanie przypadków użycia Dokumentowanie przypadków użycia Diagram interakcji dla przypadku użycia Podsumowanie Kryzys oprogramowania Zadania inżynierii oprogramowania Model przypadków użycia:

4 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 4 Jakość oprogramowania czynniki Poprawność określa, czy oprogramowanie wypełnia postawione przed nim zadania i czy jest wolne od błędów (niezawodność). Ł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 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, itp. Współdziałanie charakteryzuje zdolność oprogramowania do niezawodnej współpracy z innym niezależnie skonstruowanym oprogramowaniem.

5 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 5 Kryzys oprogramowania symptomy (1) USA: (IEEE Software Development, Aug 94, p.65) Utrzymanie 10 mld. linii istniejących programów kosztuje 70 mld. $ rocznie (Failed technology projects in Investors Business Daily, Los Angeles, Jan. 25, 1995, p. A8) (PC Week, 16 Jan 95, p.68) 31% nowych projektów jest anulowane przed zakończeniem; koszt 81 mld. $ Symptomy kryzysu oprogramowania: 31% projektów jest anulowane jeszcze w trakcie konstrukcji. 53% projektów jest kończone z przekroczeniem zaplanowanego czasu, budżetu i z ograniczeniem planowanego zbioru funkcji systemu. Zaledwie 16% projektów jest kończone w zaplanowanym czasie, bez przekroczenia budżetu i okrajania funkcjonalności.

6 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 6 Kryzys oprogramowania symptomy (2) (Ed Yourdons Guerilla Programmer, Jul 95) Średnia wydajność wykonawców oprogramowania spadła o 13% w ciągu dwóch lat; stosunek najlepszej wydajności do najgorszej od 1990 r. rozszerzył się od 4:1 do 600:1. Uzależnienie organizacji od systemów komputerowych i przyjętych technologii przetwarzania informacji, które nie są stabilne w długim horyzoncie czasowym. Problemy współdziałania niezależnie zbudowanego oprogramowania, szczególnie istotne przy dzisiejszych tendencjach integracyjnych. Problemy przystosowania już istniejących i działających systemów do nowych wymagań, tendencji i platform sprzętowo-programowych. Frustracje informatyków wynikające ze zbyt szybkiego postępu w zakresie narzędzi i metod wytwarzania oraz uciążliwości i długotrwałości procesów produkcji i pielęgnacji oprogramowania. Znaczące zmiany w przemyśle informatycznym następują co 5-7 miesięcy w porównaniu do 5-7 lat w innych dziedzinach.

7 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 7 Kryzys oprogramowania przyczyny Konflikt pomiędzy odpowiedzialnością, jaka spoczywa na współczesnych SI, a ich zawodnością wynikającą ze złożoności i ciągle niedojrzałych metod tworzenia i weryfikacji oprogramowania. Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania. Długi i kosztowny cykl tworzenia oprogramowania, wysokie prawdopodobieństwo niepowodzenia projektu programistycznego. Niska kultura ponownego użycia (ang. reuse) artefaktów wytwarzanych w trakcie realizacji projektów; niski stopień powtarzalności poszczególnych przedsięwzięć. Długi i kosztowny cykl życia SI, wymagający stałych (często znaczących) zmian. Eklektyczne, niesystematyczne środowiska implementacji.

8 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 8 Źródła złożoności oprogramowania Zespół projektantów podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji. Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów. Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów. Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, itd. Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, itd. Oprogramowanie Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność.

9 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 9 Redukcja złożoności oprogramowania (1) Złożoność powoduje, że głównym problemem w procesie konstrukcji produktów informatycznych stał się człowiek (analityk, projektant, programista,...) z jego różnymi uwarunkowaniami fizycznymi, psychologicznymi i mentalnymi. Wniosek: Technologie komputerowe powinny być bardziej zorientowane na ludzi, niż na maszyny. Co robić? Mechanizmy abstrakcji pozwalają operować jednostkami bez wnikania w ich wewnętrzną strukturę, co znacząco ułatwia proces rozumienia: np. poprzez pominięcie mniej istotnych elementów, oddzielenie specyfikacji od implementacji czy też wyodrębnienie cech wspólnych i niezmiennych (inwariantnych) dla pewnego zbioru bytów. Należy wykorzystywać:

10 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 10 Redukcja złożoności oprogramowania (2) Ponowne użycie pozwala na wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd. Efekty: można komponować większe jednostki oprogramowania z mniejszych, można dekomponować złożone struktury na fragmenty a następnie rozpatrywać te fragmenty niezależnie od siebie i niezależnie od całości. Mechanizmy kompozycji i dekompozycji, czyli podział na części o dobrze wyrażonej semantyce i dobrze wyspecyfikowanej wzajemnej interakcji (strukturalizacja oprogramowania): Zasada sprzyjania naturalnym ludzkim własnościom pozwala na dopasowanie modeli pojęciowych i realizacyjnych systemów do mechanizmów percepcji i rozumienia świata przez ludzi. Nie tylko wzrost efektywności procesu wytwarzania produktu programistycznego ale też i wzrost jakości oprogramowania, czyli np. poprawności, niezawodności, czytelności, testowalności, skalowalności, łatwej pielęgnacji, współdziałania, przenaszalności, itp.

11 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 11 Strukturalizacja oprogramowania Nawet ubogi interface do źle skonstruowanego komponentu może uczynić system ( jako całość) łatwiejszym do zrozumienia, a przez to do modyfikacji. Jeśli wystarczy jedynie rozpoznać interface do komponentu, a nie jego szczegółową implementację, musi to zaowocować większą wydajnością pracy. Jeśli można bezpiecznie zignorować niektóre aspekty systemu (objęte przez wykorzystywany komponent) to większą uwagę można przyłożyć do swojej pracy, przez co mniej błędów wprowadza się do systemu. Dzięki strukturalizacji oprogramowania łatwiej znajduje się błędy (zarówno w trakcie budowania, jak i konserwacji systemu); nie wszystkie moduły muszą być testowane przy usuwaniu konkretnego błędu. Dobrze przetestowny, udokumentowany komponent może być wielokrotnie wykorzystywany (ponowne użycie). Modularna budowa ułatwia podział pracy. Korzyści jakie przynosi strukturalizacja oprogramowania: Ze strukturalizacją oprogramowania związane są dwa, opisane dalej, pojęcia: kohezja i skojarzenia.

12 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 12 Kohezja i skojarzenia Kohezja (ang. cohesion) oznacza zwartość, spoistość. Terminu tego używa się np. w odniesieniu do komponentu oprogramowania (klasy, modułu, itp.) na oznaczenie wzajemnego zintegrowania jego elementów składowych. Wysoka, duża kohezja (ang. high cohesion) oznacza silną interakcję wewnątrz i relatywnie słabszą interakcję zzewnętrzem. Komponent powinna cechować duża kohezja, co w praktyce oznacza, że komponent stanowi dobrą, intuicyjną abstrakcję czegoś, czyli posiada precyzyjnie określoną semantykę, jest dobrze wyizolowany z kontekstu (maksymalnie od niego niezależny) oraz posiada dobrze zdefiniowany interface. Skojarzenie (ang. coupling) określa stopień powiązania elementów składowych oprogramowania, np. możemy określić skojarzenie klas w oparciu o poniższe stwierdzenia: jak często obiekty jednej klasy występują razem z obiektami drugiej klasy, jak często obiekty jednej klasy wysyłają komunikaty do obiektów drugiej klasy, itp. Możliwe są skojarzenia silne, słabe czy w ogóle brak skojarzenia. Duża ilość silnych skojarzeń miedzy elementami składowymi (ang. high coupling) jest tym, czego powinno się unikać. Analiza stopnia kohezji i wzajemnych skojarzeń stanowi podstawę do konstruowania architektury systemu, czyli wyróżniania elementów składowych systemu, określania ich wzajemnych interakcji oraz sposobów przesyłania pomiędzy nimi danych.

13 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 13 Zadania inżynierii oprogramowania Propagowanie wykorzystywania technik i narzędzi ułatwiających pracę nad złożonymi systemami; Upowszechnianie metod wspomagających analizę nieznanych problemów oraz ułatwiających wykorzystanie wcześniejszych doświadczeń; Usystematyzowanie procesu wytwarzania oprogramowania, tak aby ułatwić jego planowanie i monitorowanie; Wytworzenie wśród producentów i nabywców przekonania, że budowa dużego systemu wysokiej jakości jest zadaniem wymagającym profesjonalnego podejścia. Zadania stojące przed inżynierią oprogramowania w walce z narastającą złożonością oprogramowania: Redukcja złożoności oprogramowania;

14 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 14 Modele wg Jacobsona Model przypadków użycia: definiuje zarówno zewnętrze systemu (aktorzy systemy zewnętrzne kontekst systemu), jak i jego wnętrze (przypadki użycia); służy określeniu zachowań systemu w odpowiedzi na akcje pochodzące z otoczenia systemu. Obiektowy model dziedziny: odwzorowywuje byty świata rzeczywistego (dziedziny problemowej dziedziny przedmiotowej) w obiekty istniejące w systemie. Obiektowy model analityczny: podzbiór modelu dziedziny (dotyczy konkretnego zastosowania). Model projektowy (logiczny): opisuje założenia przyszłej implementacji. Model implementacyjny (fizyczny): reprezentuje implementację systemu. Model testowania: określa plan testów, specyfikuje procedury, dane testowe, raporty. Modele wymagają odpowiednich procesów do ich tworzenia Proces analizy wymagań, składa się z dwóch podprocesów: - proces modelowania przypadków użycia - proces analizy związany z budową obiektowego modelu analitycznego Proces projektowania Proces implementacji Proces testowania

15 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 15 Model analityczny Model analityczny z reguły wykracza poza zakres odpowiedzialności systemu. Zakres odpowiedzialności systemu Model analityczny Celem budowy modelu analitycznego może być wykrycie tych fragmentów dziedziny problemu, których wspomaganie za pomocą innego oprogramowania będzie szczególnie przydatne. Ujęcie w modelu pewnych elementów dziedziny problemu nie będących częścią systemu czyni model bardziej zrozumiałym. Przykładem jest ujęcie w modelu systemów zewnętrznych, z którymi system ma współpracować. Na etapie modelowania może nie być jasne, które elementy modelu będą realizowane przez oprogramowanie, a które w sposób sprzętowy lub ręcznie. Dziedzina problemu Dostępne środki mogą nie pozwolić na realizację systemu w całości. Przyczyny:

16 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 16 Model wymagań Model przypadków użycia Obiektowy model analityczny Składowe: Model przypadków użycia został oparty o dwa podstawowe pojęcia: Aktor Przypadek użycia Reprezentuje rolę, którą może grać w systemie jakiś jego użytkownik, np. kierownik, urzędnik, klient. Reprezentuje sekwencję operacji (realizowanych przez system), niezbędnych do wykonania zadania zleconego przez aktora, np. potwierdzenie pisma, złożenie zamówienia, itp. Aktorem jest dowolny byt z otoczenia systemu, który uczestniczy w interakcji z systemem. Każdy potencjalny aktor może wchodzić w interakcję z systemem na pewną liczbę jemu właściwych sposobów. Każdy z tych sposobów nosi nazwę przypadku użycia i reprezentuje przepływ operacji w systemie związany z obsługą zadania zleconego przez aktora w procesie interakcji.

17 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 17 Notacja Przypadek użycia: Powinien mieć unikatową nazwę, opisującą przypadek użycia z punktu widzenia jego zasadniczych celów. Czy lepiej jest stosować nazwę opisującą czynność (wypłata pieniędzy/wypłacanie pieniędzy) czy polecenie (wypłać pieniądze) zdania są podzielone. Aktor: Powinien mieć unikatową nazwę. Interakcja: Pokazuje interakcję pomiędzy przypadkiem użycia (systemem) a aktorem. Blok ponownego użycia: Pokazuje fragment systemu, który jest używany przez kilka przypadków użycia; może być oznaczony jako samodzielny przypadek użycia. Relacja typu « include » lub « extend » : Pokazuje związek zachodzący między dwoma przypadkami użycia lub przypadkiem użycia a blokiem ponownego użycia. Nazwa systemu wraz z otoczeniem systemu: Ilustrują granicę pomiędzy systemem a jego otoczeniem. weryfikacja klienta wypłata pieniędzy System obsługi klienta «include» wnętrze systemu klient

18 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 18 Aktor kto (co) może wystąpić w roli aktora? Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych z planowanym wykorzystywaniem projektowanego systemu, innymi słowy wymaga ustalenia zbioru przyszłych użytkowników systemu. Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np. biuro prawne) lub inny system komputerowy. Aktor modeluje grupę osób pełniących pewną rolę, a nie konkretną osobę. Jedna osoba może wchodzić w interakcję z systemem z pozycji wielu aktorów; np. być zarówno sprzedawcą, jak i klientem. I odwrotnie, jeden aktor może odpowiadać wielu konkretnym osobom, np. aktor strażnik budynku. (2) Aktor jest pierwotną przyczyną napędzającą przypadki użycia. Jest sprawcą zdarzeń powodujących uruchomienie przypadku użycia, jest też odbiorcą danych wyprodukowanych przez przypadek użycia. Sprawca zdarzeń? Czy np. klient, nie posiadający bezpośredniego dostępu do funkcji systemu jest aktorem? (1) Czy system może być aktorem sam dla siebie? Aktor to przecież, zgodnie z definicją, byt z otoczenia systemu. (3) Aktor pasywny a interakcja z systemem ?

19 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 19 Analiza aktorów Wyjaśnienie różnicy pomiędzy pojęciem konkretny użytkownik a pojęciem aktor: Konkretny użytkownik AktorPrzypadek użycia Może grać rolę zleca Jan Kowalski Adam Malina Konkretny 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

20 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 20 Przykład diagramu przypadków użycia (1) wpłata pieniędzy wypłata pieniędzy Czy klient jest aktorem dla przypadku użycia: wpłata pieniędzy – to zależy od konkretnego systemu. 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. wpłata pieniędzy wypłata pieniędzy klient kasjer ?

21 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 21 Przykład diagramu przypadków użycia (2) Automat do sprzedaży papierosów zakup paczki papierosów uzupełnienie towaru wykonanie operacji pieniężnej sporządzenie raportu klient operator kontroler otoczenie systemuwnętrze systemu

22 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 22 Relacje między przypadkami użycia (1) Przypadki użycia mogą być konstruowane w dowolnej kolejności, chyba że występują między nimi relacje typu « include » czy « extend ». P1 P2 « include » P1 P2 « extend » Przebieg podstawowy (sekwencyjny): P1 zawsze włącza (używa) P2, zwane tu przypadkiem włączanym. Przebieg opcjonalny (alternatywny): P1 jest czasami rozszerzane o P2, zwane tu przypadkiem rozszerzającym (inaczej: P2 czasami rozszerza P1). Sformułowanie czasami oznacza, że warunek na wywołanie P2 musi być spełniony, aby P2 zostało wywołane z P1. O ile warunek nie został wyspecyfikowany co jest dopuszczalne P2 będzie wywołane zawsze. W obu poniższych diagramach P1, nazywane tu przypadkiem bazowym, zawsze występuje jako pierwsze w kolejności działania.

23 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 23 Relacje między przypadkami użycia (2) «include» wskazuje na wspólny fragment wielu przypadków użycia (wyłączony przed nawias); jest wykorzystywane w przebiegach podstawowych (przypadek włączany jest zawsze wykonywany) strzałka jest skierowana w stronę przypadku włączanego «extend» jest wykorzystywane w przebiegach opcjonalnych (przypadek rozszerzający nie zawsze będzie wykonywany) strzałka jest skierowana w stronę przypadku bazowego naprawa samochodu przegląd samochodu sprzedaż samochodu rejestracja klienta « include » umycie samochodu « extend » przyholowanie samochodu « extend »

24 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 24 Relacje między przypadkami użycia (3) Uwaga: Zabronione jest łączenie relacją «include» (czy «extend») przypadków użycia występujących w różnych przebiegach systemu, jak np. na poniższym diagramie. klient dostawca złożenie zamówienia realizacja zamówienia « extend » Między złożeniem zamówienia a jego realizacją z reguły upływa trochę czasu.

25 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 25 Relacje między aktorami (1) Np. Pracownik administracji dziedziczy dostęp do przypadków użycia wyspecyfikowanych dla każdego pracownika, oraz ma dostęp do przypadków związanych z jego własnym, specyficznym sposobem wykorzystywania systemu. osoba gość pracownik księgowa pracownik administracji symbol oznaczający dziedziczenie dostępu do funkcji systemu

26 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 26 Relacje między aktorami (2) podsystem zarządzania bazą danych banku klient administrator systemu obsługa konta klienta informowanie o stanie konta klienta inicjalizacja karty klienta weryfikacja karty i kodu klienta Automat do operacji bankowych « include »

27 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 27 Relacje między aktorami (3) obsługa konta klienta informowanie o stanie konta klienta inicjalizacja karty klienta weryfikacja karty i kodu klienta Automat do operacji bankowych « include » podsystem zarządzania bazą danych banku klient administrator systemu

28 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 28 Rozbudowa modelu przypadków użycia Model przypadków użycia można rozbudowywać poprzez dodawanie nowych aktorów, nowych przypadków użycia czy też nowych relacji pomiędzy przypadkami. klient banku wpłać pieniędze wypłać pieniędze kasjer sprawdź stan konta weź pożyczkę zarząd banku klient banku wpłać pieniędze wypłać pieniędze kasjer sprawdź stan konta weź pożyczkę zarząd banku « include » uaktualnianie stanu konta « include » « extend »

29 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 29 Stopień szczegółowości diagramów Model przypadków użycia dostarcza bardzo abstrakcyjnego spojrzenia na system spojrzenia z pozycji aktorów, którzy go używają. Z założenia nie włącza zbyt wielu szczegółów, co pozwala wnioskować o funkcjonalności systemu na odpowiednio wysokim poziomie abstrakcji. Podstawowym (choć nie jedynym) zastosowaniem jest tu 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 « include » Tworzenie 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.

30 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 30 Kolejne kroki w konstrukcji modelu Konstrukcja modelu przypadków użycia opiera się na kilku krokach i wymaga ścisłej współpracy z przyszłym użytkownikiem, co implikuje zasadę: nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika. Jednocześnie powinien być budowany obiektowy model analityczny (schemat pojęciowy). Krok: Udokumentowany w: Sporządzenie słownika pojęć Słownik pojęć Określenie aktorów Określenie przypadków użycia Tworzenie opisu 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 + dokument z opisem przypadków użycia

31 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 31 Krok 1: sporządzenie słownika pojęć Słownik dotyczy dziedziny problemowej. Tworzenie go polega na wyłowieniu wszystkich pojęć z wymagań użytkownika. Pojęcia mogą odnosić się do aktorów, przypadków użycia, obiektów, operacji, zdarzeń, itp. Pojęcia w słowniku powinny być zdefiniowane w sposób precyzyjny i jednoznaczny. Posługiwanie się pojęciami ze słownika powinno być regułą przy opisie każdego kolejnego problemu, sytuacji czy modelu. Na co należy zwracać uwagę przy kwalifikowaniu pojęć do słownika: na rzeczowniki mogą oznaczać aktorów lub byty z dziedziny problemowej, na frazy opisujące funkcje, akcje, zachowanie się mogą stanowić podstawę do wyróżniania przypadków użycia. Ważnym jest, by już na tym etapie rozpocząć organizowanie słownika pojęć. Konto – służy do rejestrowania zasobów i wyników transakcji przeprowadzanych przez klienta, będącego właścicielem konta. Konta mogą być różnych typów, a w szczególności: konta indywidualne, małżeńskie, firmowe i inne. Każdy klient może posiadać więcej niż jedno konto. Przykład:

32 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 32 Krok 2: określanie aktorów Przy określaniu aktorów istotne są odpowiedzi na następujące pytania: Jaka grupa użytkowników potrzebuje wspomagania ze strony systemu (np. osoba wysyłająca korespondencję)? Jacy użytkownicy są konieczni do tego, aby system działał i wykonywał swoje funkcje (np. administrator systemu)? Z jakich elementów zewnętrznych (innych systemó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 tych obszarów dziedziny problemowej, którymi system nie będzie się zajmował (ustalenie zakresu odpowiedzialności systemu). 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 dostępu do funkcji systemu dla aktorów. Po wyszukaniu aktorów, należy ustalić:

33 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 33 Krok 3: określanie przypadków użycia (1) Dla każdego aktora, znajdź zadania: (1) w których system może go wesprzeć w działalności związanej z dziedziną przedmiotową, (2) niezbędne dla wspomagania działania systemu jako takiego (np. zakładanie kont użytkowników). Staraj się powiązać w jeden przypadek użycia zespół zadań realizujących podobne cele. Unikaj rozbicia jednego przypadku na zbyt wiele pod-przypadków. 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. Przeanalizuj zarówno wyspecyfikowane przypadki użycia (niektóre z nich mogą byćmutacjami innych przypadków użycia), jak i powiązania aktorów z przypadkami użycia. Ustal, co jest zbędne, a co może być uogólnione. Nazwy dla przypadków użycia powinny być krótkie, ale jednoznacznie określające charakter zadania zlecanego systemowi przez aktora. Ponadto, nazwy powinny odzwierciedlać czynności z punktu widzenia aktorów, a nie systemu, czyli np. wpłacanie pieniędzy, a nie przyjęcie pieniędzy od klienta. funkcja systemu zachowanie systemu zadanie zlecane systemowi przypadek użycia

34 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 34 Określanie przypadków użycia (2) W pierwszym podejściu skup się na tzw. przypadkach krytycznych, czyli takich, które stanowią istotę systemu (są normalnym, standardowym użyciem) lub są ważne z powodu istniejących w projekcie ryzyk (np. ryzyk technologicznych). Pomiń czynności wyjątkowe, uzupełniające lub opcjonalne. Określ wzajemne powiązania przypadków, wyspecyfikuj rodzaj zależności: sekwencja («include») czy alternatywa («extend»). Dodaj zachowania wyjątkowe, uzupełniające i opcjonalne. Ustal związki przypadków krytycznych z tego rodzaju zachowaniami. Tworząc podział każdego przypadku użycia na nazwane części (bloki), staraj się, aby nie były one ani zbyt ogólne ani zbyt szczegółowe. Zbyt szczegółowe bloki utrudniają analizę, a zbyt ogólne zmniejszają możliwość wykrycia fragmentów oprogramowania posiadających potencjał ponownego użycia. Całość diagramu nie może być ani zbyt duża ani zbyt złożona. Przeanalizuj przypadki użycia pod kątem wyizolowania bloków ponownego 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 ponownego użycia może być powiązane z określeniem bardziej ogólnych zadań lub dodaniu nowych elementów do już istniejącego zadania.

35 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 35 Krok 4: dokumentowanie 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: Dokumentacja przypadków użycia powinna zawierać: 3. Opis szczegółowy każdego przypadku użycia: scenariusz(e) specyfikację uczestniczących obiektów, diagram(y) interakcji. 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 oraz jak i kiedy zapamiętuje dane w systemie, wyjątki występujące przy obsłudze przypadku, specjalne wymagania, np. czas odpowiedzi, wydajność, jak i kiedy używane są pojęcia dziedziny problemowej.

36 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 36 Diagram interakcji dla przypadku użycia (1) Przesyłanie komunikatów pomiędzy obiektami: k1 k2 k3 k4 k5 Obiekt 1Obiekt 2Obiekt 3Obiekt 4 ki komunikat, czyli polecenie wykonania operacji na obiekcie, do którego komunikat jest wysyłany; komunikat nosi nazwę tej operacji czas Aktor

37 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 37 Diagram interakcji dla przypadku użycia (2) wpłata pieniędzy :Formularz :Kasa:Konto :Bank wypełnij podaj formularz aktualizuj stan zwiększ bilans zwiększ bilans wydaj pokwitowanie :Klient scenariusz Wypełnij formularz wpłaty Podaj formularz i gotówkę do kasy Aktualizuj stan konta klienta Zwiększ bilans kasy Zwiększ bilans banku Wydaj pokwitowanie dla klienta

38 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 38 Podsumowanie Główne zadanie modelu przypadków użycia to określenie poprawnych wymagań funkcjonalnych na projektowany system, co jest uznawane za jeden z podstawowych problemów w procesie budowy systemu. Przypadki użycia powinny odwzorowywać strukturę systemu tak, jak tę strukturę widzą przyszli użytkownicy systemu. lepsze zrozumienie możliwych sposobów wykorzystania projektowanego systemu (przypadków użycia), lepsze zrozumienie jego funkcjonalności co w efekcie oznacza zwiększenie stopnia świadomości uczestników projektu co do celów systemu, umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu, ustalenie praw dostępu do zasobów, zrozumienie strukturalnych własności systemu, a przez to ustalenie składowych systemu i związanego z nimi planu budowy systemu, dostarczenie podstawy do sporządzenia harmonogramu prac, dostarczenie bazy do budowy planu testów systemu, dostarczenie środków umożliwiających weryfikację poprawności i kompletności projektu. Ponadto, model przypadków użycia pozwala na:

39 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 39 Przypadki użycia w analizie Eksperci Użytkownicy Doświadczenie w dziedzinie przedmiotowej Przypadki użycia Model dziedziny Model zastosowania Model analityczny mocny wpływ słaby wpływ


Pobierz ppt "Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw."

Podobne prezentacje


Reklamy Google