Modele systemu Abstrakcyjny opis systemów pomocniczych w analizowaniu wymagań stawianych tym systemom.

Prezentacja na temat: "Modele systemu Abstrakcyjny opis systemów pomocniczych w analizowaniu wymagań stawianych tym systemom."— Zapis prezentacji:

1 Modele systemu Abstrakcyjny opis systemów pomocniczych w analizowaniu wymagań stawianych tym systemom.

2 Cele wiedzieć, dlaczego modelowanie kontekstu systemu jest takie ważne; znać pojęcie modelowania zachowania, modelowania danych i modelowania obiektowego; znać podstawy niektórych notacji zdefiniowanych w Unified Modeling Language (UML) oraz wiedzieć, jak używać tych notacji do budowania różnych typów modeli systemu; wiedzieć, w jaki sposób warsztaty CASE wspomagają modelowanie systemu.

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

4 Modelowanie systemu Graficzne prezentacje, w których przedstawia się problem do rozwiązania i system do zbudowania. Dzięki użyciu graficznych środków wyrazu modele są zwykle bardziej zrozumiałe niż szczegółowy opis wymagań systemowych w języku naturalnym. Mogą być użyte do zobrazowania 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 Są podstawą szczegółowego modelowania systemu w ramach analizy i określania wymagań. Określają proces, który może być użyty do opracowania tych modeli, oraz zbiór dotyczących ich reguł i wskazówek. Tworzy się standardową dokumentację systemu. Zwykle są dostępne narzędzia CASE wspomagające poszczególne metody. Są nimi edytory modeli, automatyczna dokumentacja systemu itd. Mają zwykle pewne udogodnienia do sprawdzania modeli.

6 Słabości metody analizy strukturalnej
Niewystarczająco wspomagają rozpoznawanie i modelowanie niefunkcjonalnych wymagań systemowych. Są ogólne pod tym względem, że zwykle nie zawierają wskazówek pomagających użytkownikom w podjęciu decyzji, czy konkretna metoda jest odpowiednia dla określonego problemu, czy nie. Często nie obejmują porad, jak przystosować wybraną metodę do ustalonego środowiska. Prowadzą zwykle do utworzenia zbyt obszernej dokumentacji. Istota wymagań systemowych może być ukryta w masie zapisanych szczegółów. Opracowane modele są bardzo szczegółowe i użytkownikom trudno jest je zrozumieć. Tacy użytkownicy nie mogą autentycznie sprawdzić realizmu tych modeli.

7 Przykłady różnych typów modeli systemu
Model przetwarzania danych. Na diagramach przepływu danych obrazuje się, jak dane są przetwarzane w różnych krokach pracy systemu. Model składania. Na diagramach encja-związek przedstawia się, w jaki sposób encje systemu są złożone z innych encji. Model architektoniczny. W modelach architektonicznych obrazuje się zasadnicze podsystemy, z których składa się system. Model klasyfikacyjny. Na diagramach klas obiektów i dziedziczenia przedstawia się wspólne cechy encji. Model bodziec-reakcja. Na diagramach stanów obrazuje się, w jaki sposób system reaguje na zdarzenia wewnętrzne i zewnętrzne.

8 Modele kontekstowe We wczesnej fazie procesu określania i analizowania wymagań należy ustalić granice systemu. W niektórych wypadkach granica między systemem, a jego środowiskiem jest dość czytelna. Granice między systemem a jego środowiskiem należy ustalić w trakcie procesu inżynierii wymagań.

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

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

11 Modele zachowania Modele zachowania są używane do ogólnego opisywania zachowania systemu. Dwa typy modeli: modele przepływów danych, w których opisuje się przetwarzanie danych w systemie; modele maszyn stanowych, w których opisuje się reakcje systemu na zdarzenia.

12 Modele przepływu danych
Są intuicyjnym sposobem przedstawienia, jak dane są przetwarzane przez system. Na etapie analizy należy ich użyć do modelowania przetwarzania danych w istniejącym systemie. Notacje używane w tych modelach służą do przedstawiania przetwarzania funkcjonalnego, magazynów danych i przekazywania danych między funkcjami. Modele przepływu danych są powszechnie stosowane w analizie o analizie strukturalnej systemów.

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

14 Elementy UML-a w diagramach przepływu danych
Owale oznaczają kroki przetwarzania. Strzałki z nazwami danych to przepływy. Prostokąty są magazynami danych lub źródłami danych.

15 Diagram przepływu danych dla zestawu narzędzi CASE
Gotowy projekt Sprawdzony projekt Analiza projektu Wstępny projekt Raport dla użytkownika Edytor projektów Weryfikator projektów Analizator projektów Generator raportów i Wykorzystywane projekty Sprawdzony projekt Kod wynikowy Baza danych z projektami Generator Szkieletu kodu Baza danych z projektami

16 Modele maszyn stanowych
Służą do opisywania zachowania systemu, gdy reaguje na wewnętrzne lub zewnętrzne zdarzenia. Zawierają stany i zdarzenia, które powodują przejścia z jednego stanu do innego. Nie obejmuje przepływu danych w ramach systemu. Modele maszyn stanowych są integralna częścią metod projektowania systemów czasu rzeczywistego. W metodzie Harela wprowadzono tzw. grafy stanów (statecharts), które są podstawą notacjo do modelowania maszyn stanowych w UML.

17 Model maszyny stanowej dla prostej kuchenki mikrofalowej
Pełna moc Pełna moc Do: ustaw moc = 600 Oczekiwanie do: wyświetlaj godzinę Stoper Liczba Pełna moc Ustawienie czasu do: odczytaj liczbę Exit: ustaw czas Działanie do: podgrzewanie Połowa mocy Połowa mocy Zamknięto drzwiczki Stoper Zatrzymaj Otworzono drzwiczki Początek Otworzono drzwiczki Połowa mocy do: ustaw moc = 300 Oczekiwanie do: wyświetlaj godzinę Zamknięto drzwiczki Gotowy do: wyświetlaj „Gotowy” Niegotowy do: wyświetlaj „Czekam”

18 Opis stanów dla kuchenki mikrofalowej

19 Opis bodźców dla kuchenki mikrofalowej

20 Notacja UML stosowana w modelach maszyn stanowych
Jest to uniwersalna notacja, która może służyć do modelowania maszyn stanowych rozmaitych typów. Prostokąty z zaokrąglonymi rogami oznaczają stany systemu. Zawierają krótką informację (po słowie „do”) o akcjach wykonywanych w tym stanie. Strzałki z etykietkami reprezentują bodźce, które powodują przejścia między stanami.

21 Działanie kuchenki mikrofalowej
Czas Sprawdzenie do: sprawdź stan OK Gotowanie do: praca generatora Awaria talerza obrotowego Awaria źródła fal Koniec czasu Wykonano do: włącz brzęczek na 5 sekund Alarm do: wyświetlaj zdarzenie Otworzono drzwiczki Zatrzymaj Niegotowy Oczekiwanie

22 Modele danych Często korzystamy z wielkich baz danych. Definiowanie logicznego formatu przetwarzanych danych jest ważną częścią modelowania takich systemów. Najpowszechniej stosowaną metodą modelowania danych jest modelowanie encja-relacja-atrybut (ERA), która obejmuje encje, związane z nimi atrybuty i relacje między tymi encjami. W UML nie są zawarte specjalne notacje do tego rodzaju modelowania danych, ponieważ jest językiem przystosowanym do obiektowego procesu tworzenia.

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

24 Słownik danych Jest to alfabetyczna lista nazw, które pojawiły się w różnych modelach systemu. Oprócz nazwy słownik danych powinien zawierać także opisy nazwanych błędów i opis ich składowych w wypadków bytów złożonych. Zalety słownika danych: jest mechanizmem zarządzania nazwami; służy za składnicę informacji o przedsiębiorstwie, która umożliwia scalenie analizy, projektu, implementacji i ewolucji. Większość narzędzi CASE, które wspomagają modelowanie systemu, zawiera wsparcie do obsługi słownika danych.

25 Przykłady haseł słownika danych

26 Modele obiektowe Są obecnie powszechnie stosowane, zwłaszcza w wypadku systemów interaktywnych. Przy takim podejściu wymagania systemowe są zapisywane w modelu obiektowym, projektowanie odbywa się za pomocą obiektów, a programuje się w jednym z języków programowania obiektowego, np. Javie lub C++. Modele obiektowe opracowane w czasie analizy wymagań mogą być użyte zarówno do przedstawienia samego systemu, jak i jego działania. Pod tym względem łączą w sobie zalety modeli przepływu danych i znaczeniowych modeli danych.

27 Modele obiektowe Są naturalnym sposobem odzwierciedlania encji pochodzących ze świata rzeczywistego, które są przetwarzane przez system. Jest to szczególnie widoczne, gdy system przetwarza informacje o konkretnych encjach, które mają łatwe do zidentyfikowania atrybuty. Takimi encjami są np. samochody , samoloty i książki. Modele obiektowe opracowywane w trakcie analizy wymagań z pewnością upraszczają przejście do projektowania i programowania obiektowego. Klasa obiektów jest abstrakcją zbioru obiektów, która identyfikuje ich wspólne atrybuty (w znaczeniowym modelu danych) oraz usługi i operacje oferowane przez te obiekty.

28 Modele dziedziczenia Systematyka jest obrazowana w postaci hierarchii dziedziczenia, w której wyżej stoją bardziej ogólne klasy obiektów. Bardziej szczegółowe obiekty dziedziczą ich atrybuty i usługi. Te specjalizowane obiekty maja też własne atrybuty i usługi.

29 Notacja UML Dziedziczenie obrazuje się „w górę”, a nie „w dół”, jak to jest w niektórych innych językach obiektowych. Strzałka (w postaci trójkąta) jest skierowana od klasy, która dziedziczy atrybut i operacje, do nadklasy. W UML nie ma pojęcia dziedziczenia, które w tym języku nosi nazwę uogólnienia.

30 Fragment hierarchii w systemie biblioteki
Składnik biblioteki Numer katalogowy Data zakupu Cena Typ Stan Liczba kopii Nabądź() Skataloguj() Usuń() Udostępnij(0 Zwróć() Fragment hierarchii w systemie biblioteki Składnik opublikowany Tytuł Wydawca Składnik utrwalony Tytuł Nośnik u b i s h e d i t e m c o r e d i t e i t l e P u b l i h e u m Książka Autor Wydanie Data wydania ISBN Czasopismo Rok Numer Film Reżyser Data ukazania się Dystrybutor Program Komputerowy Wersja Platforma C o m p u t e r p r o g r a m V e r s i o n P l a t f o r

31 Hierarchia klasy użytkownika
Użytkownik biblioteki Nazwisko Adres Telefon Numer karty Zarejestruj() Wyrejestruj() Hierarchia klasy użytkownika Czytelnik Przynależność Wypożyczający Wypożyczone składniki Limit wypożyczeń Pracownik Dział Telefon działu Student Główny kierunek studiów Adres domowy

32 Modele dziedziczenia wielokrotnego
Klasa może mieć kilku przodków. Dziedziczone przez nią atrybuty i usługi są połączeniem tych odziedziczonych po nadklasach.

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

34 Agregacja obiektów Niektóre obiekty są utworzone z innych obiektów, tzn. obiekt jest agregacja zbioru innych obiektów. Klasy tych obiektów mogą być modelowane za pomocą agregacji. W UML-u agregację oznacza się za pomocą rombu umieszczonego przy źródle wiązania.

35 Obiekt złożony (agregacja) reprezentujący wykład
Pakiet do nauki Tytuł wykładu Numer Rok Wykładowca Zadanie Punkty Przezrocza Notatki Tekst Kaseta wideo Id kasety Ćwiczenia Liczba zadań Opis Rozwiązania Tekst Diagramy

36 Modelowanie zachowania obiektów
Modelując zachowanie obiektów, musimy wykazać, jak korzysta się z operacji dostarczonych przez obiekty. W UML zachowanie jest modelowane za pomocą scenariuszy.

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

38 Warsztaty CASE Są to zbiory narzędzi, które wspomagają konkretny etap procesu tworzenia oprogramowania, np. projektowanie, implementowanie lub testowanie. Zaletą łączenia narzędzi CASE w jeden warsztat jest to, że mogą współpracować i zapewnić wygodniejsze wspomaganie, niż jest to możliwe w wypadku jednego narzędzia. Wspólne usługi mogą być zaimplementowane i wykorzystywane przez wszystkie narzędzia. Narzędzia warsztatu można zintegrować przez dzielone pliki, dzielone repozytorium albo dzielone struktury danych.

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 Warsztaty do analizy i projektowania
Edytory diagramów Narzędzia do analizy i sprawdzania projektu Języki zapytań do repozytorium Słownik danych Narzędzia do definiowania i generowania raportów Narzędzia do definiowania formularzy Udogodnienia do importu i eksportu Generatory kodu

41 Główne tezy Model jest abstrakcyjnym obrazem systemu, który pomija pewne jego szczegóły. Mogą powstawać uzupełniające się modele systemu, które obejmują różne informacje o systemie. W modelach kontekstowych zapisuje się, jak modelowany system jest umiejscowiony w środowisku innych systemów i procesów. Modele architektoniczne, modele procesów i modele przepływu danych mogą być używane jako modele kontekstowe. Diagramy przepływu danych mogą służyć do specyfikowania przetwarzania danych zachodzącego w systemie. System jest przedstawiany w postaci zbioru przekształceń danych z funkcjami działającymi na tych danych. Modele maszyn stanowych są używane do modelowania zachowania systemu, gdy reaguje na zewnętrzne i wewnętrzne zdarzenia.

42 Główne tezy W znaczeniowych modelach danych opisuje się logiczna strukturę danych importowanych lub eksportowanych z systemu. Takie modele obejmują encje systemu, ich atrybuty i związki, w których biorą udział. Mogą być uzupełnione słownikami danych, które zawierają bardziej szczegółowy opis danych. W modelach obiektowych zapisuje się logiczne byty systemu, ich klasyfikacje i agregację. Takie modele łączą w sobie cechy modeli danych i modeli przetwarzania. Modele obiektowe, które można opracować, obejmują modele dziedziczenia, modele agregacji i modele zachowania. Warsztaty CASE wspomagają opracowywanie modeli systemów przez narzędzia do edycji, sprawdzania, generowania raportów i dokumentowania.