Modele systemu l Abstrakcyjny opis systemw sucych do

Modele systemu l Abstrakcyjny opis systemów służących do analizy wymagań ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 1

Cele l l wiedzieć, dlaczego modelowanie systemu jest takie ważne; znać pojęcie modelowania kontekstu, 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 2

Zawartość l Modele strukturalne Modele kontekstowe Modele zachowania Modele danych, w tym słowniki Modele obiektowe l Warsztaty CASE l l ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 3

Modelowanie systemu l Graficzne prezentacje, w których przedstawia się problem do rozwiązania i system do zbudowania. Dzięki użyciu graficznych środków modele są zwykle bardziej zrozumiałe niż szczegółowy opis wymagań systemowych w języku naturalnym. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 4

Użycie modelowania systemu l Modele systemu 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 5

Modele strukturalne l l l Metody strukturalne takie jak analiza strukturalna systemów i analiza obiektowa 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. 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 6

Przykłady różnych typów modeli strukturalnych systemu l l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 8

Modele kontekstowe l l l 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ń. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 9

Kontekst systemu bankomatu System księgowy oddziału System zabezpieczeń System bankomatu System obsługi oddziału ©Ian Sommerville 2000 Baza danych kont Baza danych o użytkowaniu System konserwacji Inżynieria oprogramowania, Rozdział 7 Slide 10

Modele zachowania l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 12

Modele przepływu danych l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 13

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

Elementy UML-a w diagramach przepływu danych l l l Owale oznaczają kroki przetwarzania. Strzałki z nazwami danych to przepływy. Prostokąty są magazynami danych lub źródłami danych. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 15

Diagram przepływu danych dla zestawu narzędzi CASE Gotowy Sprawdzony Analiza Raport dla projektu użytkownika Edytor Weryfikator Analizator Generator projektów i projektów raportów Wykorzystywane Sprawdzony projekt Wstępny projekt Kod wynikowy Baza danych z projektami ©Ian Sommerville 2000 Generator szkieletu kodu Inżynieria oprogramowania, Rozdział 7 Baza danych z projektami Slide 16

Modele maszyn stanowych l l l 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ą notacji używanej do modelowania maszyn stanowych w UML. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 17

Model maszyny stanowej dla prostej kuchenki mikrofalowej Pełna moc Oczekiwanie do: wyświetlaj godzinę Połowa mocy Pełna moc Do: ustaw moc = 600 Stoper Liczba Pełna Ustawienie czasu Działanie moc do: odczytaj liczbę do: Exit: ustaw czas podgrzewanie Połowa mocy Zamknięto Zatrzymaj Stoper drzwiczki Otworzono Początek Połowa mocy do: ustaw moc = 300 ©Ian Sommerville 2000 drzwiczki Zamknięto Gotowy drzwiczki do: wyświetlaj „Gotowy” Niegotowy do: wyświetlaj „Czekam” Inżynieria oprogramowania, Rozdział 7 Otworzono drzwiczki Oczekiwanie do: wyświetlaj godzinę Slide 18

Opis stanów dla kuchenki mikrofalowej ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 19

Opis bodźców dla kuchenki mikrofalowej ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 20

Notacja UML stosowana w modelach maszyn stanowych l l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 21

Rozwinięcie stanu działanie kuchenki mikrofalowej Działanie Sprawdzenie OK do: sprawdź stan Awaria talerza obrotowego Czas Gotowanie do: praca generatora Koniec czasu Awaria źródła fal Alarm do: wyświetlaj zdarzenie Wykonano do: włącz brzęczek na 5 sekund Otworzono drzwiczki Niegotowy ©Ian Sommerville 2000 Zatrzymaj Oczekiwanie Inżynieria oprogramowania, Rozdział 7 Slide 22

Modele danych l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 23

Słownik danych l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 25

Przykłady haseł słownika danych ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 26

Modele obiektowe l l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 27

Modele obiektowe l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 28

Modele dziedziczenia l l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 29

Notacja UML l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 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óć() Składnik opublikowany Składnik utrwalony ub ished item Tytuł itle Wydawca Publi he Książka Autor Wydanie Data wydania ISBN cor ed ite um Tytuł Nośnik Czasopismo Film Rok Numer Reżyser Version Data ukazania się Platfor Dystrybutor Computer program Program Komputerowy Wersja Platforma

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

Modele dziedziczenia wielokrotnego l l Klasa może mieć kilku przodków. Dziedziczone przez nią atrybuty i usługi są połączeniem tych odziedziczonych po nadklasach. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 33

Dziedziczenie wielokrotne Książka Zapis mowy Autor Wydanie Data wydania ISBN Mówca Czas trwania Data zapisu Mówiąca książka Liczba taśm ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 34

Agregacja obiektów l l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 35

Obiekt złożony (agregacja) reprezentujący wykład Pakiet do nauki Tytuł wykładu Numer Rok Wykładowca Zadanie Punkty Ćwiczenia Liczba zadań Opis ©Ian Sommerville 2000 Przezrocza Notatki Tekst Kaseta wideo Id kasety Rozwiązania Tekst Diagramy Inżynieria oprogramowania, Rozdział 7 Slide 36

Modelowanie zachowania obiektów l l Modelując zachowanie obiektów, musimy wykazać, jak korzysta się z operacji dostarczonych przez obiekty. W UML zachowanie jest modelowane za pomocą scenariuszy. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 37

Prośba o składnik elektroniczny Ekat: Katalog : Składnik biblioteki Lib 1: Serwer sieciowy : Użytkownik biblioteki Wyszukaj Wyświetl Zamów Zaakceptuj warunki Wyślij warunki Skompresuj Dostarcz ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 38

Warsztaty CASE l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 39

Warsztat do analizy i projektowania Słownik danych Generator kodu Narzędzia do tworzenia formularzy ©Ian Sommerville 2000 Strukturalne narzędzia do rysowania diagramów Centralne repozytorium informacji Narzędzia do analizy i sprawdzania projektów Inżynieria oprogramowania, Rozdział 7 Udogodnienia do generowania raportów Udogodnienia do stawiania zapytań Udogodnienia do importu i eksportu Slide 40

Warsztaty do analizy i projektowania l l l l 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 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 41

Główne tezy l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 42

Główne tezy l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 43