Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 1 Modele systemu l Abstrakcyjny opis systemów pomocniczych w analizowaniu wymagań stawianych.

Podobne prezentacje


Prezentacja na temat: "©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 1 Modele systemu l Abstrakcyjny opis systemów pomocniczych w analizowaniu wymagań stawianych."— Zapis prezentacji:

1 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 1 Modele systemu l Abstrakcyjny opis systemów pomocniczych w analizowaniu wymagań stawianych tym systemom.

2 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 2 Cele l wiedzieć, dlaczego modelowanie kontekstu systemu jest takie ważne; l znać pojęcie modelowania zachowania, modelowania danych i modelowania obiektowego; l 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; l wiedzieć, w jaki sposób warsztaty CASE wspomagają modelowanie systemu.

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

4 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 4 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 wyrazu modele są zwykle bardziej zrozumiałe niż szczegółowy opis wymagań systemowych w języku naturalnym. l 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 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 5 Metody strukturalne l Są podstawą szczegółowego modelowania systemu w ramach analizy i określania wymagań. l Określają proces, który może być użyty do opracowania tych modeli, oraz zbiór dotyczących ich reguł i wskazówek. l Tworzy się standardową dokumentację systemu. l 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 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 6 Słabości metody analizy strukturalnej l Niewystarczająco wspomagają rozpoznawanie i modelowanie niefunkcjonalnych wymagań systemowych. l 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. l Często nie obejmują porad, jak przystosować wybraną metodę do ustalonego środowiska. l Prowadzą zwykle do utworzenia zbyt obszernej dokumentacji. Istota wymagań systemowych może być ukryta w masie zapisanych szczegółów. l Opracowane modele są bardzo szczegółowe i użytkownikom trudno jest je zrozumieć. Tacy użytkownicy nie mogą autentycznie sprawdzić realizmu tych modeli.

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

8 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 8 Modele kontekstowe l We wczesnej fazie procesu określania i analizowania wymagań należy ustalić granice systemu. l W niektórych wypadkach granica między systemem, a jego środowiskiem jest dość czytelna. l Granice między systemem a jego środowiskiem należy ustalić w trakcie procesu inżynierii wymagań.

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

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

11 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 11 Modele zachowania l Modele zachowania są używane do ogólnego opisywania zachowania systemu. l 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 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 12 Modele przepływu danych l Są intuicyjnym sposobem przedstawienia, jak dane są przetwarzane przez system. l Na etapie analizy należy ich użyć do modelowania przetwarzania danych w istniejącym systemie. l Notacje używane w tych modelach służą do przedstawiania przetwarzania funkcjonalnego, magazynów danych i przekazywania danych między funkcjami. l Modele przepływu danych są powszechnie stosowane w analizie o analizie strukturalnej systemów.

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

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

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

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

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

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

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

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

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

22 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 22 Modele danych l Często korzystamy z wielkich baz danych. Definiowanie logicznego formatu przetwarzanych danych jest ważną częścią modelowania takich systemów. l 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. l W UML nie są zawarte specjalne notacje do tego rodzaju modelowania danych, ponieważ jest językiem przystosowanym do obiektowego procesu tworzenia.

23 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 23 Znaczeniowy model danych projektu oprogramowania Projekt Węzeł Etykieta nazwa opis data-u data-m nazwa treść ikona nazwa typ nazwa typ n n Wiązanie 1 ma-wiązanie n 2 wiązania 1 ma-etykietki ma-wiązania n 1 1 n ma-węzły ma-etykietki 1 Jest Jest Jest 1

24 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 24 Słownik danych l Jest to alfabetyczna lista nazw, które pojawiły się w różnych modelach systemu. l 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. l 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. l Większość narzędzi CASE, które wspomagają modelowanie systemu, zawiera wsparcie do obsługi słownika danych.

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

26 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 26 Modele obiektowe l Są obecnie powszechnie stosowane, zwłaszcza w wypadku systemów interaktywnych. l 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++. l 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 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 27 Modele obiektowe l Są naturalnym sposobem odzwierciedlania encji pochodzących ze świata rzeczywistego, które są przetwarzane przez system. l 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. l Modele obiektowe opracowywane w trakcie analizy wymagań z pewnością upraszczają przejście do projektowania i programowania obiektowego. l 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 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 28 Modele dziedziczenia l Systematyka jest obrazowana w postaci hierarchii dziedziczenia, w której wyżej stoją bardziej ogólne klasy obiektów. l Bardziej szczegółowe obiekty dziedziczą ich atrybuty i usługi. l Te specjalizowane obiekty maja też własne atrybuty i usługi.

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

30 Fragment hierarchii w systemie biblioteki Version Platfor Computer program itle Publihe ubished item um cored ite Składnik biblioteki Numer katalogowy Data zakupu Cena Typ Stan Liczba kopii Nabądź() Skataloguj() Usuń() Udostępnij(0 Zwróć() Składnik opublikowany Tytuł Wydawca Składnik utrwalony Tytuł Nośnik Książka Autor Wydanie Data wydania ISBN Czasopismo Rok Numer Film Reżyser Data ukazania się Dystrybutor Program Komputerowy Wersja Platforma

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

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

33 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 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 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 34 Agregacja obiektów l Niektóre obiekty są utworzone z innych obiektów, tzn. obiekt jest agregacja zbioru innych obiektów. l Klasy tych obiektów mogą być modelowane za pomocą agregacji. l W UML-u agregację oznacza się za pomocą rombu umieszczonego przy źródle wiązania.

35 ©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 Przezrocza Notatki Tekst Kaseta wideo Id kasety Rozwiązania Tekst Diagramy Ćwiczenia Liczba zadań Opis

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

37 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 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 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 38 Warsztaty CASE l Są to zbiory narzędzi, które wspomagają konkretny etap procesu tworzenia oprogramowania, np. projektowanie, implementowanie lub testowanie. l 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. l Wspólne usługi mogą być zaimplementowane i wykorzystywane przez wszystkie narzędzia. l Narzędzia warsztatu można zintegrować przez dzielone pliki, dzielone repozytorium albo dzielone struktury danych.

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

40 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 40 Warsztaty do analizy i projektowania l Edytory diagramów l Narzędzia do analizy i sprawdzania projektu l Języki zapytań do repozytorium l Słownik danych l Narzędzia do definiowania i generowania raportów l Narzędzia do definiowania formularzy l Udogodnienia do importu i eksportu l Generatory kodu

41 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 41 Główne tezy 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. l 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. l 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. l Modele maszyn stanowych są używane do modelowania zachowania systemu, gdy reaguje na zewnętrzne i wewnętrzne zdarzenia.

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


Pobierz ppt "©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 7 Slide 1 Modele systemu l Abstrakcyjny opis systemów pomocniczych w analizowaniu wymagań stawianych."

Podobne prezentacje


Reklamy Google