Modele systemu

1. Modele systemu • Abstrakcyjne opisy sytemu, którego wymagania są opisywane

2. Cele • Wytłumaczenie, dlaczego modelowanie kontekstu systemu jest takie ważne • Opisanie modelowania zachowania, modelowania danych i modelowania obiektowego • Wprowadzenie niektórych notacji zawartych w Unified Modeling Language (UML) • Pokazanie w jaki sposób warsztaty CASE wspomagają modelowanie systemu

3. Zawartość • Modele kontekstowe • Modele zachowania • Modele danych • Modele obiektowe • Warsztaty CASE

4. Modelowanie systemu • Modelowanie systemu pomaga analitykom zrozumieć funkcjonalność systemu, a modele są używane w komunikacji z użytkownikiem • Różne modele pokazują zachowanie tego samego systemu z różnych punktów widzenia • Zewnętrznego, przy którym modeluje się kontekst lub środowisko systemu • Zachowania, przy którym modeluje się zachowanie systemu • Strukturalnego, ,przy którym modeluje się architekturę systemu lub strukturę przetwarzanych danych

5. Metody strukturalne • Metody strukturalne zawierają modelowanie jako nieodłączną część metody • Metody definiują zbiór modeli, proces powstawania tych modeli i reguły oraz wskazówki, których należy się trzymać • Narzędzia CASE zwykle wspierają poszczególne metody

6. Słabości metod strukturalnych • Nie modelują wymagań niefunkcjonalnych • Nie zawierają zazwyczaj informacji czy konkretna metoda jest stosowna do problemu czy też nie • Prowadzą do zbyt obszernej dokumentacji • Modele są bardzo szczegółowe i użytkownikom trudno je zrozumieć

7. Typy modeli • Model przetwarzania danych pokazujący, jak dane są przetwarzane w różnych krokach pracy systemu • Model składania pokazuje jak encje składają się z innych encji • Model architektoniczny pokazuje zasadnicze podsystemy, z których składa się system • Model klasyfikacyjny przestawiający wspólne cechy encji • Model bodziec-reakcja pokazujący odpowiedzi na zdarzenia wewnętrzne i zewnętrzne

8. Modele kontekstowe • Modele kontekstowe pokazują granice systemu • Czynniki społeczne i organizacyjne mogą wpływać na decyzje o umieszczeniu granic systemu • Model architektoniczny pokazuje system i jego związki z zewnętrznymi systemami

9. Model kontekstowy bankomatu System zabezpieczeń System księgowy oddziału Baza danych kont System bankomatu System obsługi oddziału Baza danych o użytkownikach System konserwacji

10. Modele procesów • Modele procesów pokazują przegląd procesów i opisują wszystkie procesy wspierane przez system • Modele przepływów danych mogą być używane do pokazywania procesów i przepływów danych między nimi

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

12. Modele zachowania • Modele zachowania są używane do ogólnego opisywania zachowania systemu • Przedstawię dwa typy modeli zachowania • Model przepływu danych pokazujący jak dane są przetwarzane przez system • Model maszyny stanowej pokazujący jak system reaguje na zdarzenia wewnętrzne lub zewnętrzne • Oba te modele są potrzebne, aby opisać zachowanie systemu

13. Model przepływu danych • Pokazują jak system przetwarza dane • Dane są przekształcane w każdym kroku • Integralna część wielu metod analitycznych • Prosta i intuicyjna notacja, zrozumiała dla klienta • Pokazują przetwarzanie danych od początku do końca

14. DFD obsługi zamówień Wypełniony blankiet zamówienia Podpisany formularz zamówienia Sprawdzone i podpisane zamówienie +informacja o zamówieniu Podpisany formularz zamówienia Wyślij do dostawcy Wypełnij blankiet zamówienia Sprawdź zamówienie Zarejestruj zamówienie Zaktualizuj budżet dostępnych środków Szczegóły zamówienia + czysty blankiet zamówienia Podpisany formularz zamówienia Wartość zamówienia + informacje księgowe Szczegóły zamówienia Plik zamówień Plik budżetu

15. Diagramy przepływu danych • DFDs modelują system z punktu widzenia funkcjonalności • Śledzenie i dokumentowanie jak dane są przetwarzane przez system pomaga lepiej zrozumieć całość systemu • Diagramy przepływu danych mogą być używane do pokazywania wymiany danych pomiędzy systemem a jego otoczeniem

16. DFD warsztatu CASE Gotowy projekt Sprawdzony projekt Analiza projektu Raport dla użytkownika Edytor projektów Weryfikator projektów Analizator projektów Generator raportów Wstępny projekt Sprawdzony projekt Wykorzystywane projekty Kod wynikowy Baza danych z projektami Generator szkieletu kodu Baza danych z projektami

17. Modele maszyn stanowych • Służą do opisywania zachowania systemu, gdy reaguje na wewnętrzne lub zewnętrzne zdarzenia • Są szczególnie przydatne w systemach czasu rzeczywistego • Modele maszyn stanowych używają węzłów do opisów stanów a strzałek do opisu zdarzeń. Kiedy występuje zdarzenie system przechodzi z jednego stanu do drugiego • Grafy stanów są częścią UML-a.

18. Pełna moc do: ustaw moc = 600 Połowa mocy do: ustaw moc = 300 Działanie do: podgrzewanie Gotowy do: wyświetlaj „Gotowy” Niegotowy do: wyświetlaj „Czekam” Ustawianie czasu do: odczytaj liczbę exit: ustaw czas Oczekiwanie do: wyświetlaj godzinę Oczekiwanie do: wyświetlaj godzinę Model kuchenki mikrofalowej Liczba Stoper Pełna moc Pełna moc Zamknięto drzwiczki Początek Połowa mocy Zatrzymaj Stoper Połowa mocy Otworzono drzwiczki Zamknięto drzwiczki Otworzono drzwiczki

19. Opis stanów modelu

20. Opis bodźców modelu

21. Grafy stanów • Pozwala na dekompozycję modelu na podmodele • Krótka informacja o działaniach zawarta po słowie „do” • Mogą być uzupełniane za pomocą tabel z opisami stanów i bodźców

22. Sprawdzanie do: sprawdź stan Alarm do: wyświetl zdarzenie Gotowanie do: praca generatora Wykonano do: włącz brzęczyk na 5s. Działanie kuchenki mikrofalowej Działanie Czas OK Awaria talerza obrotowego Awaria źródła fal Koniec czasu Otworzono drzwiczki Zatrzymaj Niegotowy Oczekiwanie

23. Znaczeniowe modele danych • Używane do opisu logicznej struktury danych przetwarzanych przez system • Model związków encji przedstawia encje w systemie, związki pomiędzy nimi i ich atrybuty • Szeroko używane w bazach danych. Mogą być bezpośrednio przekształcane w tabele • Brak oddzielnej notacji w UML, ale można wykorzystać w tym celu modele obiektów i ich związków

24. Znaczeniowy model danych projektu oprogramowania Projekt nazwa opis data-u data-m 1 1 ma-wiązania ma-węzły n jest 1 n 1 Wiązanie nazwa typ Węzeł nazwa typ 1 n ma-wiązania 2 wiązania 1 1 1 Etykieta nazwa treść ikona ma-etykietki ma-etykietki n n

25. Słowniki danych • Słownik danych to lista wszystkich nazw użytych w modelu systemu. Zawiera również opisy encji związków i atrybutów • Zalety • Wspomaga zarządzanie nazwami i zapobiega duplikatom • Przechowuje informacje o przedsiębiorstwie łącząc analizę, projekt, implementację i ewolucję • Większość narzędzi CASE zawiera wsparcie dla słowników danych

26. Wpisy w słowniku danych

27. Modele obiektowe • Modele obiektowe opisują system używając obiektów i klas • Klasa jest abstrakcją zbioru obiektów, ze wspólnymi atrybutami i usługami dostarczanymi przez te obiekty • Można stworzyć następujące typy modeli: • Modele dziedziczenia • Modele agregacja • Modele interakcji

28. Modele obiektowe • naturalna metoda odwzorowywania bytów ze świata rzeczywistego przetwarzanych przez system • Byt abstrakcyjne są trudniejsze do wymodelowania • Identyfikacja klas jest uważana za trudny proces wymagający doskonałej znajomości dziedziny • Klasy opisujące byty dziedziny mogą być używane w wielu różnych systemach

29. Modele dziedziczenia • Organizują klasy w hierarchie • Klasy na szczycie reprezentują wspólne cechy wszystkich klas • Obiekty dziedziczą atrybuty i usługi z jednej lub więcej nadklas • Jeśli chce się uniknąć duplikowania w różnych gałęziach, to projektowanie hierarchii klas jest rzeczą skomplikowaną

30. Unified Modeling Language • Został stworzony przez twórców używanych metod projektowania i analizy obiektowej • Stał się standardem służącym do obiektowego modelowania systemów • Notacja • Klasy są prostokątami z nazwą na górze, atrybutami w środku i operacjami na dole • Relacje pomiędzy klasami są liniami łączącymi klasy • Dziedziczenie jest nazywane generalizacją i obrazuje się je raczej „w górę”, a nie „w dół” jak w innych metodach

31. Składnik opublikowany Tytuł Wydawca Składnik utrwalony Tytuł Nośnik Książka Autor Data wydania ISBN Czasopismo Rok Numer Film Reżyser Data ukazania się Dystrybutor Program komputerowy Wersja Platforma Hierarchia klas biblioteki Składnik biblioteki Numer katalogowy Data zakupu Cena Typ Stan Liczba kopii Nabądź() Skataloguj() Usuń() Udostępnij() Zwróć()

32. Dziedziczenie wielokrotne • Zamiast dziedziczyć atrybuty i usługi po jednej klasie, systemy, które wspierają dziedziczenie wielokrotne pozwalają jednej klasie dziedziczyć z wielu klas • Mogą prowadzić do konfliktów semantycznych, jeśli atrybuty lub usługi mają te same nazwy w nadklasach, a różną semantykę • Reorganizacja hierarchii klas jest wtedy bardziej skomplikowana

33. Dziedziczenie wielokrotne Książka Zapis mowy Autor Mówca Wydanie Czas trwania Data wydania Data zapisu ISBN Mówiąca książka Liczba taśm

34. Agregacja obiektów • Agregacje pokazują jak klasy będące zbiorami są złożone z obiektów innych klas • Znaczenie podobne do bycia częścią w znaczeniowym modelu danych

35. Agregacja obiektów Pakiet do nauki Tytuł wykładu Numer Rok Wykładowca Przezrocza Notatki Kaseta video Zadanie Przezrocza Zawartość Punkty Tekst Ćwiczenia Rozwiązanie Tekst Liczba zadań Opis Diagramy

36. Modelowanie zachowania obiektów • Model zachowania pokazuje interakcje pomiędzy obiektami, które prowadzą do określonego zachowania systemu wyspecyfikowanego jako przypadek użycia • Diagramy kooperacji są używaną w UML metodą przedstawiania interakcji pomiędzy obiektami

37. Prośba o składnik elektroniczny : Składnik biblioteki Lib1: : E c a t : Serwer sieciowy Katalog : Użytkownik biblioteki Wyszukaj Wyświetl Zamów Zaakceptuj warunki Wyślij warunki Skompresuj Dostarcz

38. Warsztaty CASE • Zbiór narzędzi, które wspólnie wspomagają tworzenie oprogramowania i czynności takie jak: analiza, projektowanie i testowanie • Narzędzia do analizy i projektowania wspierają modelowanie systemu zarówno podczas zbierania wymagań jak i tworzenia systemu • Warsztaty mogą wspierać konkretną metodę projektowania jak również mogą pomagać przy tworzeniu różnych typów modeli

39. Warsztat do analizy i projektowania Słownik danych Strukturalne narzędzia do rysowania diagramów Udogodnienia do generowania raportów Generator kodu Centralne repozytorium informacji Udogodnienia do stawiania zapytań Narzędzia do tworzenia formularzy Narzędzia do analizy i sprawdzania projektów Udogodnienia do importu i eksportu

40. Części warsztatu analitycznego • Edytor diagramów • Narzędzia do analizy i sprawdzania projektu • Repozytorium z językiem zapytań • Słownik danych • Narzędzia do definiowania i generowania raportów • Narzędzia do definiowania formularzy • Udogodnienia do importu i eksportu • Narzędzia do generowania kodu

41. Główne tezy • Model jest abstrakcyjnym obrazem systemu. uzupełniające się typy modeli dostarczają różnych rodzajów informacji • Model kontekstowy przedstawia pozycję systemu w środowisku i otoczeniu innych systemów • Modele przepływów danych pokazują kolejność obrabiania danych przez system • Maszyny stanowe obrazują zachowanie systemu w odpowiedzi na zdarzenia zewnętrzne i wewnętrzne

42. Główne tezy • Znaczeniowe modele danych pokazują strukturę logiczną danych importowanych lub eksportowanych z systemu • Modele obiektowe opisują encje ich klasyfikację i agregację. • Warsztaty CASE wspomagają opracowywanie modeli systemu