Podstawy Inżynierii Oprogramowania. Wykład 6 Modele systemu

Transkrypt

1 Podstawy Inżynierii Oprogramowania Wykład 6 Modele systemu

2 2

3 3

4 4

5 Dla klienta Dla projektanta 5

6 6

7 Agenda Modelowanie pojęciowe Modele kontekstowe Modele zachowania, danych, obiektowe Język UML (ang. Unified Modeling Language) Narzędzia CASE wspierające modelowanie systemu. 7

8 Modelowanie pojęciowe Projektant i programista muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowania. Pojęcia modelowania pojęciowego (ang. conceptual modeling) oraz modelu pojęciowego (ang. conceptual model) odnoszą się procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem. Modelowanie pojęciowe jest wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnię. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzących w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu. 8

9 Czy zawsze musimy modelować? Mniej istotne Ważniejsze Papierowy samolot Myśliwiec 9

10 Dlaczego zespoły programistów nie modelują? Wiele zespołów podchodzi do wytwarzania złożonego oprogramowania jak do budowy papierowego samolociku. Zaczynają pisać kod na podstawie wymagań. Pracują długie godziny i piszą dłuższy kod programu. Architektura nie jest planowana... Mówi się, że nad projektami informatycznymi wisi fatum porażki (ang. doom of failure). Często jest to związane z traktowaniem myśliwca w kategoriach papierowego samolociku. 10

11 Cztery zasady modelowania Wybór modelu ma wpływ na to jak będziemy postrzegać rzeczywistość. Każdy model może być wyrażony na dowolnym poziomie szczegółowości Najlepsze model są bezpośrednio odnoszą się do rzeczywistości Pojedynczy model jest niewystarczający. 11

12 Perspektywy w modelowaniu pojęciowym odwzorowanie odwzorowanie Percepcja rzeczywistego świata Analityczny model rzeczywistości Model struktur danych i procesów SI Trwałą tendencją w rozwoju metod i narzędzi projektowania oraz konstrukcji SI jest dążenie do minimalizacji luki pomiędzy myśleniem o rzeczywistym problemie a myśleniem o danych i procesach zachodzących na danych. 12

13 Modelowanie analityczne systemu Modelowanie systemu pomaga analitykowi w zrozumieniu funkcjonalności systemu oraz w komunikacji z klientem. Modele mogą prezentować system z różnych punktów widzenia Zewnętrznego pokazuje kontekst lub środowisko systemu; Zachowania modeluje zachowanie systemu; Strukturalnego modeluje architekturę systemu lub strukturę przetwarzania danych. 13

14 Typy modeli Model przetwarzania danych jak dane są przetwarzane na różnych etapach pracy systemu. Model kompozycji jak elementy systemu komponowane są z mniejszych fragmentów. Model architektoniczny z jakich zasadniczych podsystemów składa się system. Model klasyfikacji wspólne cechy poszczególnych elementów systemu. Model bodziec-reakcja w jaki sposób system reaguje na zdarzenia zachodzące tak poza nim jak i w jego wnętrzu. 14

15 Modele kontekstowe Ilustrują operacyjny kontekst systemuotoczenie. Context models Kwestie społeczne i organizacyjne mogą mieć wpływ na ustalenia co do systemu należy a co jest poza jego granicami. Modele architektoniczne pokazują system i jego powiązania z innymi systemami. 15

16 Kontekst systemu bankomatu System zabezpieczeń System księgowy oddziału System bazy danych kont System bankomatu System obsługi oddziału System bazy danych o użytkowaniu System konserwacji 16

17 Modele procesu Process models Pokazują czynności wspierane przez system. Uzupełniają model kontekstowy i pomagają w podjęciu decyzji, które czynności będą wykonywane automatycznie. 17

18 Model procesu zakupu wyposażenia dla firmy Protokół odbioru Wyspecyfikuj potrzebne wyposażenie Specyfikacja wyposażenia Sprawdź specyfikację Sprawdzona specyfikacja Wykonaj oszacowanie kosztów Zaakceptuj protokół odbioru Protokół odbioru Sprawdź dostarczone towary Specyfikacja wyposażenia Lista dostawców Specyfikacja + dostawca + oszacowanie Informacja o zamówieniu Instrukcja montażu Baza danych z dostawcami Znajdź dostawców Wybierz dostawcę Złóż zamówienie Szczegóły zamówienia + czysty formularz zamówienia Zainstaluj wyposażenie Akceptacja instalacji Sprawdzony i podpisany formularz zamówienia Zaakceptuj dostarczone wyposażenie Szczegółowe informacje o wyposażeniu Baza danych o wyposażeniu 18

19 Modele zachowania Opisują ogólne zachowanie systemu. Typy: Behavioural models Modele przetwarzania (przepływu) danych pokazują sposób w jaki dane są przetwarzane i jak przepływają przez system; Modele stanów (maszyna stanów) pokazujące reakcje systemu na zdarzenia. Pozwalają spojrzeć na zachowanie systemu z różnych punktów widzenia. 19

20 Model procesu zakupu wyposażenia dla firmy Protokół odbioru Wyspecyfikuj potrzebne wyposażenie Specyfikacja wyposażenia Sprawdź specyfikację Sprawdzona specyfikacja Wykonaj oszacowanie kosztów Zaakceptuj protokół odbioru Protokół odbioru Sprawdź dostarczone towary Specyfikacja wyposażenia Lista dostawców Specyfikacja + dostawca + oszacowanie Informacja o zamówieniu Instrukcja montażu Baza danych z dostawcami Znajdź dostawców Wybierz dostawcę Złóż zamówienie Szczegóły zamówienia + czysty formularz zamówienia Sprawdzony i podpisany formularz zamówienia Zainstaluj wyposażenie Akceptacja instalacji Zaakceptuj dostarczone wyposażenie Szczegółowe informacje o wyposażeniu Baza danych o wyposażeniu 20

21 Obsługa zamówienia diagram przepływu danych Szczegóły zamówienia + czysty formularz zamówienia Wypełnij blankiet zamówienia Wypełniony formularz zamówienia Sprawdź zamówienie Wypełniony formularz zamówienia Szczegóły zamówienia Zarejestruj zamówienie Podpisany formularz zamówienia Wyślij do dostawcy Podpisany formularz zamówienia Zaktualizuj budżet dostępnych środków Sprawdzenie i podpisanie zamówienia + informacje o zamówieniu Wartość zamówienia + informacje księgowe Plik zamówienia Plik budżetu 21

22 Maszyny stanów State machine models Opisują zachowanie systemu w reakcji na wewnętrzne lub zewnętrzne zdarzenia. Pokazują odpowiedzi systemu na określone stymulacje, dlatego często wykorzystywane są do modelowania systemów czasu rzeczywistego. Maszyna stanu pokazuje system w postaci zbioru stanów oraz możliwych przejść pomiędzy nimi wraz ze zdarzeniami, które to przejście powodują. Do graficznego przedstawienia maszyny stanów wykorzystuje się diagramy stanów. 22

23 Diagramy stanów Statecharts Umożliwiają poziomowanie modelu (dekompozycję na pod-modele). W każdym stanie można opisać akcję która jest wykonywana. Mogą być wspomagane tabelami szczegółowo opisującymi stany i pobudzenia. 23

24 Diagram stanów dla mikrofalówki Połowa mocy pełna moc do/ ustaw moc = 300 Timer Liczba Działanie Oczekiwanie do/ wyświetlaj godzinę Połowa mocypełna moc Timer Ustawianie czasu do/ odczytaj liczbę exit/ ustaw czas Otwarto drzwi Zamknięto drzwi Gotowy Start do/ wyświetlaj "Gotowy" do/ podgrzewaj Wstrzymaj Oczekiwanie do/ wyświetlaj godzinę Połowa mocy do/ ustaw moc = 300 Niegotowy do/ wyświetlaj "Niegotowy" Zamknięto drzwi Otwarto drzwi 24

25 Poziomowanie - superstan Działanie Sprawdzanie do/ Sprawdź stan OK Gotowanie do/ do/ Praca generatora Awaria talerza obrotowego Alarm do/ wyświetl zdarzenie Awaria źródła fal Koniec czasu Wykonano do/ włącz sygnał dzwiękowy Otwarto drzwi Wstrzymaj Niegotowy Oczekiwanie 25

26 Modele danych Opisują logiczną strukturę danych, które przetwarza system (np. model Encja-Związek, ang. Entity- Relationship i jego odmiany). Data models Encja koncepcyjnie niezależna jednostka (obiekt) Związek/relacja koncepcyjny związek pomiędzy encjami. Atrybut własność encji Szeroko stosowane w projektowaniu baz danych (mogą być łatwo przekształcone w model relacyjny). 26

27 Diagram Encja-Związek Entity-Relationship diagram 27

28 Słowniki danych Alfabetyczna lista nazw używanych w różnych modelach systemu, również elementów modelu danych ( encji, związków, atrybutów) Zalety Wspiera proces zarządzania nazwami i umożliwia unikanie duplikatów; Przechowuje wiedzę nabywaną podczas projektu; wiąże ze sobą różne poziomy modelowania oraz implementację; Proces tworzenia słownika jest często wspierany przez narzędzia CASE. 28

29 Metodyki modelowania obiektowego Obecnie najbardziej popularne. Oparte o podejście obiektowe. Rozwijane od lat 80-tych, oparte na wyróżnianiu obiektów łącznie z operacjami. Na terenie analizy i projektowania obiektowego istnieje wiele metodyk obiektowych oraz notacji graficznych służących modelowaniu (UML, OODA, OMT, OOSE, Objectory, OOSA, OOA/OOD, Fusion, OSA, OORAM, BON, MOSES/OPEN). 29

30 Obiektowość Obiektowość zmniejsza lukę pomiędzy myśleniem o rzeczywistości (dziedzinie problemowej) a myśleniem o danych i procesach, które zachodzą na danych. Abstrakcja Modularyzacja Hermetyzacja Hierarchizacja 30

31 Zasada abstrakcji Eliminacja lub ukrycie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji. Wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzanie pojęć lub symboli oznaczających takie cechy. Abstrakcja definiuje granice zależne od perspektywy obserwatora. 31

32 Przykłady abstrakcji Student Profesor Kurs Ruchomy pojazd silnikowy, transportujący ludzi z miejsca na miejsce. Urządzenie do bezprzewodowego odbioru sygnałów 32

33 Zasada hermetyzacji ukrywanie informacji Zasada inżynierii oprogramowania (Parnas, 1972): programista ma tyle wiedzieć o obiekcie programistycznym, ile potrzeba, aby go efektywnie użyć. Wszystko, co może być przed nim ukryte, powinno być ukryte. Klient zależy od interfejsu. Hermetyzacja i ukrywanie informacji jest podstawą pojęć modułu, klasy i ADT. 33

34 Zasada modularyzacji - dekompozycja Rozdzielenie czegoś złożonego na małe łatwiejsze do zarządzania fragmenty. Pomaga w zrozumieniu złożonych systemów. 34

35 Przykład System Płacowy Katalog Kursów Course Registration System Zarządzanie Studentami 35

36 Zasada hierarchizacji Porządkowanie (szeregowanie) abstrakcji w strukturę drzewiastą. Rodzaje: hierarcha agregacji, klas, dziedziczenia, typów (Słownik terminów obiektowości, Friesmith, 1995) Byty Ożywione Nieożywione Rośliny Zwierzęta Naturalne Sztuczne 36

37 Obiekt Nieformalnie, obiekt jest to byt obserwowalny w rzeczywistości (jej wycinku), koncepcyjny obraz tej rzeczywistości lub jednostka oprogramowania. Formalnie, obiekt jest jednostką z dobrze zdefiniowanymi granicami, który hermetyzuje stan (ang. state) oraz zachowanie (ang. behaviour). 37

38 Podstawowe własności obiektu Obiekt jest charakteryzowany poprzez: Tożsamość, która odróżnia go od innych obiektów. Tożsamość obiektu jest niezależna zarówno od wartości atrybutów obiektu, jak i od lokacji bytu odwzorowywanego przez obiekt w świecie rzeczywistym czy też lokacji samego obiektu w przestrzeni adresowej komputera. W praktyce: tożsamość = trwały wewnętrzny identyfikator obiektu. Stan, który może zmieniać się w czasie (bez zmiany tożsamości obiektu). Stan obiektu w danym momencie jest określony przez aktualne wartości jego atrybutów i powiązań z innymi obiektami. Obiekt ma przypisane zachowanie, tj. zestaw operacji, które wolno stosować do danego obiektu. 38

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

40 Modele obiektowe Object models Naturalnie odzwierciedlają elementy rzeczywistości, którymi manipuluje system. Opisują system w terminach klas obiektów i relacji pomiędzy nimi. Obiekty mogą być rzeczywiste lub abstrakcyjne. Identyfikacja klas obiektów jest uważana za trudny proces (wymaga głębokie znajomości dziedziny aplikacji). Klasy opisujące obiekty z dziedziny problemowej mają duży potencjał ponownego użycia. 40

41 Unified Modeling Language UML , styczeń wrzesień 1996 UML 1.0, styczeń 1997, przesłany do OMG UML 1.1, koniec 1997, zatwierdzony jako składnik standardu OMG UML 1.3, UML 1.5, marzec 2003 UML 2.0, 2004 UML Połączone siły trzech znanych metodologów oprogramowania: Grady Booch Ivar Jacobson James Rumbaugh

42 UML: Krótka charakterystyka (1) UML cieszy się aktualnie bardzo dużą popularnością. Prawdopodobnie przez wiele najbliższych lat będzie dominował w obszarze analizy i projektowania. UML nie jest metodyką projektowania. Notacja UML, która opiera się o podstawowe pojęcia obiektowości może być wykorzystana w dowolnej metodyce. Pojęcia UML, wynikające z doświadczenia jej twórców, mają w założeniu przykrywać większość istotnych aspektów modelowanych systemów. 42

43 UML: Krótka charakterystyka (2) Wady i zalety metodyk, których autorami są twórcy UML: OMT (Rumbaugh): dobry do modelowania dziedziny przedmiotowej. Nie przykrywa dostatecznie dokładnie zarówno aspektu użytkowników systemu, jak i aspektu implementacji (konstrukcji). OOSE (Jacobson): dobrze podchodzi do kwestii modelowania użytkowników i cyklu życiowego systemu. Nie przykrywa dokładnie modelowania dziedziny przedmiotowej jak i aspektu implementacji (konstrukcji). OOAD (Booch): dobrze podchodzi do kwestii projektowania, konstrukcji i związków ze środowiskiem implementacji. Nie przykrywa dostatecznie dobrze fazy rozpoznania i analizy wymagań użytkowników. Celem UML jest przykrycie również tych aspektów. 43

44 Perspektywy modelowania w UML UML jest określany jako język modelowania z 4+1 perspektywą : Perspektywa przypadków użycia opisuje funkcjonalność systemu widzianą przez użytkowników Perspektywa logiczna sposób realizacji funkcjonalności, struktura systemu widziana przez projektanta Perspektywa implementacyjna zawiera moduły i interfejsy, przeznaczona dla programisty Perspektywa procesowa podział systemu na czynności i jednostki wykonawcze (wątki, procesy, współbieżność) służy głównie programistom i instalatorom Perspektywa wdrożeniowa fizyczny podział elementów systemu i ich rozmieszczenie w infrastrukturze, ważna dla instalatorów 44

45 Diagramy definiowane w UML Diagramy pakietów Diagramy przypadków użycia Diagramy klas Diagramy sekwencji Diagramy obiektów Modele Diagramy współpracy Diagramy komponentów Diagramy stanów Diagramy aktywności Diagramy wdrożeniowe 45

46 Model a diagram Modele w UML Model - pewna abstrakcja projektowanego systemu, widziana z określonej perspektywy, na określonym poziomie szczegółowości. Diagram - środek służący do opisu modelu. Dany model może być opisany przy pomocy wielu diagramów. Dany element modelu może pojawiać się na wielu diagramach jednego modelu. Dwa najważniejsze modele w UML, wykorzystywane w fazie analizy (modelowania), to: model przypadków użycia opisujący system widziany z perspektywy jego przyszłego użytkownika (za pomocą diagramów przypadków użycia), model obiektowy przedstawiający statyczną budowę, czyli strukturę systemu (za pomocą diagramów klas i diagramów obiektów). Diagram klas może zawierać obiekty. Diagram obiektów nie zawiera klas, ale wyłącznie obiekty. 46

47 Modele obiektowe a UML Notacja: Klasy obiektów reprezentowane są jako prostokąty Opis podzielony jest na trzy części Nazwa Atrybuty Operacje Powiązania pomiędzy klasami (zwane asocjacjami) reprezentowane są przez linie łączące klasy; Dziedziczenie, określane mianem związku generalizacji modeluje związek jest rodzaju Agregacja modelująca zależności typu całość - część 47

48 Hierarchia klas w systemie biblioteki Składnik biblioteki Numer katalogowy Data zakupu Cena Typ Stan Liczba kopii Skataloguj() Usuń() Udostępnij() Zwróć() Składnik opublikowany Składnik utrwalony Tytuł Wydawca Tytuł Nośnik Książka Autor Wydanie Data wydania ISBN Czasopismo Rok Numer Film Rezyser Data premiery Dystrybutor Program komputerowy Wersja Platforma 48

49 Hierarchia klas reprezentujących użytkowników Użytkownik biblioteki Nazwisko Adres Telefon Numer karty Zarejestruj() Wyrejestruj() Czytelnik Przynalezność Wypożyczający Wypozyczone składniki Limit wypozyczeń Pracownik Jednostka Telefon Student Kierunek studiów Adres domowy 49

50 Dziedziczenie wielokrotne Praco wn ik Oso b a PracującyStu d en t Stu d en t W systemie wspierającym wielokrotne dziedziczenie klasa może dziedziczyć z więcej niż jednej nad-klasy. Może to prowadzić do konfliktów znaczeniowych gdy w nad-klasach znajdują się takie same nazwy atrybutów/usług o różnej semantyce. Dziedziczenie wielokrotne utrudnia ewentualną reorganizację hierarchii. 50

51 Agregacja obiektów Model agregacji pokazuje jak klasy będące kolekcjami są komponowane z innych klas. Pakiet kształcenia Tytuł wykładu Numer Rok Wykładowca Zadanie Punkty Prezentacje slajdy Tekst Notatki Materiały wizualne -identyfikator Ćwiczenia Liczba zadań Opis Rozwiązania Tekst Diagramy 51

52 Diagram klas z dziedziczeniem i asocjacjami Osoba * Student Pracownik zapisany na 1..* zapisany na Profesor 0..1 poprzedza * Kurs zawiera 1 1..* 1..* Wykład * prowadzi 1 następuje po * 52

53 Modelowanie zachowania obiektów Głównym zadaniem pomocniczego modelu dynamicznego (zachowania) w UML jest wypełnienie diagramu klas metodami wynikającymi z analizy zachowania systemu w trakcie wykonywania zadań, gdzie zadaniem może być np. realizacja przypadku użycia czy też jednego konkretnego scenariusza danego przypadku użycia. W UML do modelowania zachowania wykorzystuje się głównie diagramy sekwencji i współpracy wspomagane diagramami stanów. 53

54 Pobranie składnika elektronicznego : Katalog : Składnik biblioteki : SerwerDostarczania : Użytkownik wyszukaj wyświetl wynik Udostępnij Zarządaj_licencji () Zaakceptuj skompresuj prześlij 54

55 Słabości modeli Nie modelują wymagań niefunkcjonalnych. Zazwyczaj nie zawierają informacji o tym czy dana metoda rozwiązania jest odpowiednia do problemu. Mogą produkować nadmierną liczbę dokumentacji. Czasami modele są zbyt szczegółowe przez co trudne do zrozumienia przez użytkowników. 55

56 Narzędzia CASE Spójny zestaw narzędzi zaprojektowany w celu wsparcia określonej aktywności np. analizy, projektowania czy testowania. Narzędzia do analizy i projektowania wspomagają modelowanie systemu tak w procesie inżynierii wymagań jak i w procesie projektowania systemu. Narzędzia takie mogą wspomagać specyficzne metodyki lub udostępniać możliwość tworzenia wielu różnych typów modeli. 56

57 Struktura narzędzi CASE do analizy i projektowania Słownik danych Narzędzia do rysowania diagramów Generatory raportów Generatory kodu Centralne repozytorium Język zapytań Narzędzia do tworzenia formularzy Narzędzia do analizy i kontroli poprawności modeli Import eksport 57

58 Do poczytania Sommerville I.: Inżynieria Oprogramowania, rozdział 7. Dąbrowski, Subieta: Podstawy Inżynierii Oprogramowania, rozdział 4. O UML u książek jest dużo Tak na początek, Booch G., Rumbaugh J., Jacobson I.: UML przewodnik użytkownika, WNT,

59 Internet UML