Projektowanie obiektowe

1. Projektowanie obiektowe

2. Uwagi ogólne: Obiektowość jest nową ideologią, która zmienia myślenie realizatorów SI z “zorientowanego na maszynę” na “zorientowane na człowieka”. Obiektowość jest konsekwencją kryzysu oprogramowania: kosztów związanych z oprogramowaniem, jego zawodnością i trudną do opanowania złożonością. Obiektowość przenika wszelkie fazy projektowania, narzędzia i interfejsy. Obiektowość dopracowała się własnej kolekcji pojęć i narzędzi. Obiektowość jest na początku swojej drogi i musi walczyć z konserwą i spuścizną poprzednich ideologii.

3. Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy.Przykład: Diagram przepływu kosztów w metodzie ABC

4. System informacyjny składa się z wielu elementów o zróżnicowanych zadaniach

5. W pełni skonfigurowany system informacyjny zawiera bardzo wiele składników o różnym przeznaczeniu

6. Orientację w tej złożonej materii ułatwia fakt, że większość systemów informacyjnych ma obecnie strukturę warstwową W dodatku każdy nowoczesny system zawiera zarówno składniki wewnętrzne (zintegrowane z jądrem systemu) oraz składniki zewnętrzne (satelitarne)

7. Dzięki temu współczesne systemy informacyjne odznaczają się dużą elastycznością, co oznacza, że można do nich w każdej chwilo dołączać nowe komponenty. Jednak przyłączania każdego nowego urządzenia do systemu wymaga wykonania szeregu zabiegów w jego różnych warstwach, co jest kłopotliwe, chociaż na ogół odbywa się automatycznie.

19. 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 w interakcji z jego zewnętrzem. • Obiektowy model dziedziny: odwzorowywuje byty świata rzeczywistego (czyli dziedziny problemowej) w obiekty istniejące w systemie. • Obiektowy model analityczny: efekt fazy analizy dla konkretnego zastosowania. • Model projektowy (logiczny): opisuje założenia przyszłej implementacji. • Model implementacyjny (fizyczny): reprezentuje konkretną implementację systemu. • Model testowania: określa plan testów, specyfikuje dane testowe i raporty. • Modele wymagają odpowiednich procesów ich tworzenia • Proces analizy wymagań, składa się z dwóch podprocesów: • - proces modelowania przypadków użycia • -Proces analizy związany z obiektowym modelemanalitycznym • Proces projektowania • Proces implementacji • Proces testowania

20. Model analityczny Model analityczny z reguły wykracza poza zakres odpowiedzialności systemu. Przyczyny: • 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 Uwaga: Dostępne środki mogą nie pozwolić na realizację systemu w całości! Model analityczny Zakres odpowiedzialności systemu 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.

21. Model wymagań • Model przypadków użycia • Obiektowy model analityczny Składowe: Model przypadków użycia wykorzystuje dwa podstawowe pojęcia: Aktor 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 przez aktora, np. potwierdzenie pisma, złożenie zamówienia, itp. Przypadek użycia Aktorem jest dowolny byt zewnętrzny, 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.

22. Notacja klient Przypadek użycia: Powinien mieć unikalną 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”) czy polecenie (“wypłać pieniądze”) - zdania sąpodzielone. wypłata pieniędzy Aktor: Powinien mieć unikalną nazwę. Interakcja: Pokazuje interakcję pomiędzy przypadkiem użycia 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. weryfikacja klienta 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. «include» System obsługi klienta Nazwa systemu wraz z otoczeniem systemu: Pokazuje granicę pomiędzy systemem a jego otoczeniem. wnętrze systemu

23. Aktor - konkretny byt czy rola? Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych z wykorzystywaniem projektowanego systemu, czyli określenia “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”. Czy system może być aktorem sam dla siebie ? Aktor to przecież, zgodnie z definicją, byt z otoczenia systemu. Aktor jest tu pierwotną przyczyną napędzającą przypadki użycia. Jest on sprawcą zdarzeń powodujących uruchomienie przypadku użycia, jak też odbiorcą danych wyprodukowanych przez przypadki użycia. Sprawca zdarzeń? Czy np. klient, nie posiadający bezpośredniego dostępu do funkcji systemu jest tu aktorem?

24. zleca Może grać rolę Przeładowanie systemu Jan Kowalski Administrator systemu Wejście z kartą i kodem Adam Malina Pracownik Uzyskanie informacji ogólnych Gość Osoba informowana Wypłata z konta Konkretny klient Klient Analiza aktorów Wyjaśnienie różnic pomiedzy konkretnymi użytkownikami a aktorami Użytkownik Aktor Przypadek użycia

25. klient kasjer wpłata pieniędzy wypłata pieniędzy Przykład diagramu przypadków użycia (1) wpłata pieniędzy ? klient wypłata pieniędzy Czy klient jest aktorem dla przypadku użycia: wpłata pieniędzy - zdania są podzielone. 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.

26. Przykład diagramu przypadków użycia (2) klient Automat do sprzedaży papierosów uzupełnienie towaru operacja pieniężna zakup paczki papierosów operator sporządzenie raportu wnętrze systemu granica systemu kontroler otoczenie systemu

27. Zależności między przypadkami użycia Przypadki użycia mogą być konstruowane w dowolnej kolejności, chyba że występują między nimi relacje typu «include» czy «extend». p1 jest tu przypadkiem bazowym i zawsze występuje jako pierwsze w kolejnościdziałania. «include» p1 p2 Przebieg podstawowy (sekwencyjny): p1 zawsze włącza (używa) p2. p1 p2 «extend» Przebieg opcjonalny (alternatywny): p1 jest czasami rozszerzane o p2 (inaczej: p2 czasami rozszerza p1).

28. Relacja: «include» Automat do operacji bankowych prowadzenie konta klienta podsystem zarządzania bazą danych banku «include» informowanie o stanie konta klienta «include» weryfikacja karty i kodu klienta klient «include» inicjalizacja karty klienta administrator systemu

29. Relacje: «include» i «extend» «include»: wskazuje na wspólny fragment wielu przypadków użycia (wyłączony “przed nawias”); wykorzystywane wprzebiegach podstawowych (operacje zawsze wykonywane) sprzedaż samochodu «include» rejestracja klienta «include» «include» naprawa samochodu przegląd samochodu «extend» «extend»: strzałka prowadzi od przypadku użycia, który czasami rozszerza inny przypadek użycia - wykorzystywane wprzebiegach opcjonalnych (operacje nie zawsze wykonywane) «extend» «extend» przyholowanie samochodu umycie samochodu

30. Rozbudowa modelu przypadków użycia wpłata pieniędzy wpłata pieniędzy kasjer kasjer «include» wypłata pieniędzy wypłata pieniędzy «extend» «include» uaktualnianie stanu konta klient banku sprawdź stan konta sprawdź stan konta klient banku weź pożyczkę weź pożyczkę zarząd banku zarząd banku Model przypadków użycia można rozbudowywać poprzez dodawanie nowych aktorów, nowych przypadków użycia czy też nowych relacji pomiędzy nimi.

31. Diagram interakcji dla przypadku użycia Przesyłanie komunikatów pomiędzy blokami: Aktor Blok 1 Blok 2 Blok 3 Blok 4 k1 k2 k3 czas k4 k5 Bloki-obiekt ki - komunikat, czyli polecenie wykonania operacji; komunikat nosi nazwę tej operacji

32. Przykład diagramu interakcji scenariusz 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 wpłata pieniędzy :Kasa :Konto :Bank :Formularz :Klient wypełnij podaj formularz zwiększ zwiększ bilans zwiększ bilans wydaj pokwitowanie

33. 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ą. Nie włącza zbyt wielu szczegółów, co pozwala wnioskować o fukcjonalności systemu na odpowiednio wysokim poziomie. Podstawowym (choć nie jedynym) zastosowaniem jest tu dialog z przyszłymi użytkownikami zmierzający do sformułowania poprawnych wymagań na system. Model zbyt szczegółowy - utrudnia analizę, zbyt ogólny - nie pozwala na wykrycie bloków ponownego użycia. edycja programu Tworzenie przypadków użycia jest niezdeterminowane i subiektywne. Na ogół, różni analitycy tworzą różne modele. kompilacja programu «include» «include» wykonanie programu drukowanie pliku programista użytkownik

34. 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 model obiektowy. Krok: Udokumentowany w: 1 Sporządzenie słownika pojęć Słownik pojęć 2 Określenie aktorów Dokument opisu aktorów Określenie przypadków użycia 3 4 • Tworzenie opisu każdego przypadku • użycia plus: • podział na nazwane części • znalezienie wspólnych części • w różnych przypadkach użycia Diagram przypadków użycia + dokument opisu przypadków użycia

35. Sporządzanie słownika pojęć • Ważnym jest, by już na tym etapie rozpocząć organizowanie słownika pojęć. • Słownik dotyczy dziedziny problemowej. • Tworzenie go polega na wyłowieniu wszystkich terminów z wymagań użytkownika. • Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów, operacji, zdarzeń, itp. • Terminy w słowniku powinny być zdefiniowane w sposób precyzyjny i jednoznaczny. • Posługiwanie się terminami ze słownika powinny być regułą przy opisie każdego kolejnego problemu, sytuacji czy modelu. Przykład: Konto - pojedyncze konto w banku, w stosunku do którego wykonywane są bieżące transakcje. 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. • Na co należy zwrócić uwagę przy kwalifikowaniu terminów do słownika: • na rzeczowniki - mogą one oznaczać aktorów lub byty z dziedziny problemowej • na frazy opisujące funkcje, akcje, zachowanie się - mogą one być podstawą • wyróżnienia przypadków użycia.

36. 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, 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ć: • 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.

37. pracownik administracji Struktury dziedziczenia dla aktorów osoba pracownik gość księgowa 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.

38. Określanie przypadków użycia (1) • 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 realizujących podobne cele. Unikaj rozbicia jednego przypadku użycia na zbyt wiele pod-przypadków. • Nazwy dla przypadków użycia: powinny być 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.

39. Określanie przypadków użycia (2) • Wyodrębnij “przypadki bazowe”, czyli te, które stanowią istotę zadań, są normalnym, standardowym użyciem. Pomiń czynności skrajne, wyjątkowe, uzupełniające lub opcyjne. • Nazwij te “przypadki bazowe”. Ustal powiązania “przypadków bazowych” z innymi przypadkami, poprzez ustalenie ich wzajemnej zależności: sekwencji czy alternatywy. • Dodaj zachowania 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 ponownego użycia. Struktura nie może być zbyt duża i złożona. • Staraj się wyizolować bloki ponownego użycia. Przeanalizuj podobieństwo nazw przypadków użycia, podobieństwo nazw i zachowania bloków ponownego użycia występujących w ich specyfikacji. Wydzielenie bloku ponownego użycia może być powiązane z określeniem bardziej ogólnej funkcji lub dodaniu nowej specjalizacji do istniejącej funkcji.

40. Dokumentowanie przypadków użycia Dokumentacja przypadków użycia powinna zawierać: 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 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. 3.Opis szczegółowy każdego przypadku użycia: • scenariusz(e) • specyfikację uczestniczących obiektów, • diagram(y) interakcji.

41. Zadania modelu przypadków użycia Główne zadanie modelu przypadków użycia to prawidłoweokreślenie wymagańfunkcjonalnychna projektowany system. Prawidłowe określenie funkcjonalności systemu uznawane jest za jeden z podstawowych problemów w procesie konstrukcji. 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 systemu, czyli innymi słowy jego funkcjonalności, • 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 konstrukcji systemu, • dostarczenie podstawy do sporządzenia planu testów systemu, • weryfikację poprawności i kompletności projektu. Przypadki użycia odwzorowywują strukturę systemu tak, jak ją widzą jego użytkownicy.

42. Przypadki użycia w analizie Eksperci Doświadczenie w dziedzinie przedmiotowej Model dziedziny Model analizy Przypadki użycia Model zastosowania mocny wpływ słaby wpływ Użytkownicy

43. W projektowaniu obiektowym kluczowym pojęciem jest klasa Takie zamknięcie danych w „pancerzu” skojarzonych z nimi metod nazywa się enkapsulacją Obiekty zewnętrzne mają dostęp wyłącznie do funkcji (nazywanych też metodami) za pomocą których mogą zlecać wykonanie określonych operacji na danych Cechą charakterystyczną koncepcji klasy jest ukrycie danychprzed obiektami zewnętrznymi.

44. Przykład obiektu Wypłać Wpłać Porównaj podpis Sprawdź stan Numer: 123-4321 Stan konta: 34567 PLN Właściciel: Jan Kowalski Upoważniony: ... Podpis: … .... Nalicz procent Zlikwiduj konto Podaj osoby upoważnione Obiekt KONTO Upoważnij

45. Dzięki temu można zmienić tradycyjny układ systemu, w którym wiele programów korzysta z wielu danych W takim systemie każdy z obiektów może być programowany przez oddzielnego programistęi nie ma potrzeby uzgadniania w zespole projektowym wewnętrznych rozwiązań poszczególnych obiektów Na nowy układ, w którym programy i dane są zblokowane razem

46. Sposoby dzielenia danych pomiędzy programy w klasycznych (nie obiektowych) metodach projektowania (1) Kilka podprogramów używa tych samych danych

47. Sposoby dzielenia danych pomiędzy programy w klasycznych (nie obiektowych) metodach projektowania (2) Dane lokalne w podprogramach

48. Sposoby dzielenia danych pomiędzy programy w klasycznych (nie obiektowych) metodach projektowania (3) Podprogram mający własne dane korzysta jednak z danych współdzielonych w pliku

49. Sposoby dzielenia danych pomiędzy programy w klasycznych (nie obiektowych) metodach projektowania (4) Podprogramy mające własne lokalne dane korzystają ze wspólnej bazy danych

50. Przy metodzie obiektowej cały system można budować zestawiając powtarzalne obiekty i klasy w stosowych konfiguracjach na poszczególnych poziomach hierarchii systemu.