1 / 42

Modele systemu

Modele systemu. Abstrakcyjny opis systemów pomocniczych w analizowaniu wymagań stawianych tym systemom. Cele. wiedzieć, dlaczego modelowanie kontekstu systemu jest takie ważne; znać pojęcie modelowania zachowania, modelowania danych i modelowania obiektowego;

abia
Télécharger la présentation

Modele systemu

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 System zabezpieczeń System księgowy oddziału Baza danych kont System bankomatu System obsługi oddziału Baza danych o użytkowaniu System konserwacji

  10. Znajdź dostawców Model procesu zakupu wyposażenia Protokółodbioru P Specyfikacja wyposażenia Sprawdzona specyfikacja Protokół odbioru Zaakceptuj protokół odbioru Wyspecyfikuj potrzebne wyposażenie Sprawdź dostarczone towary Sprawdź specyfikację Zdobądź oszacowanie kosztów Informacja o zamówieniu Specyfikacja + dostawca + oszacowanie Instrukcja montażu Specyfikacja wyposażenia Listadostawców Złóż zamówienie na wyposażenie Wybierz dostawcę Baza danych zdostawcami 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 Bazadanych 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 Sprawdzone i podpisane zamówienie + informacja o zamówieniu Podpisany formularz zamówienia 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-aw 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 Raport dla użytkownika Wstępny projekt Edytor projektów Weryfikator projektów Analizator projektów Generator raportów i Wykorzystywane projekty Sprawdzony projekt Kod wynikowy Baza danych z projektami Generator Szkieletukodu 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 Zatrzymaj Stoper 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 Działanie Czas Sprawdzenie do: sprawdź stan OK Gotowanie do: praca generatora Awaria talerza obrotowego Koniecczasu Awaria źródłafal 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 Projekt nazwa opis data-u data-m 1 1 ma-węzły ma-wiązania 1 Jest Jest n 1 n Węzeł 1ma-wiązanien Wiązanie nazwa typ nazwa typ 2wiązania1 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. 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 Program Komputerowy Wersja Platforma Czasopismo Rok Numer Film Reżyser Data ukazania się Dystrybutor 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. 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 Kaseta wideo Id kasety Zadanie Punkty Przezrocza Przezrocza Notatki Tekst Ć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: Serwersieciowy : Użytkownikbiblioteki 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.

More Related