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

Slides:



Advertisements
Podobne prezentacje
Związki w UML.
Advertisements

Modelowanie przypadków użycia
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28Slide 1 Restrukturyzacja oprogramowania l Reorganizowanie i modyfikowanie istniejącego.
Modele systemu Abstrakcyjne opisy sytemu, którego wymagania są opisywane.
Projektowanie architektoniczne
Projektowanie Aplikacji Komputerowych
Propozycja metodyki nauczania inżynierii oprogramowania
Co UML może zrobić dla Twojego projektu?
Modelowanie i język UML
Tomasz Jabłoński Michał Ziach
Diagram czynności (Activity Diagrams)
Wstęp do programowania obiektowego
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
Praca Inżynierska „Analiza i projekt aplikacji informatycznej do wspomagania wybranych zadań ośrodków sportowych” Dyplomant: Marcin Iwanicki Promotor:
Projektowanie - wprowadzenie
Wykład 4 Analiza i projektowanie obiektowe
Wykład 5 UML - Unified Modeling Language
Wykład 3 Analiza i projektowanie strukturalne
Wykład 2 Cykl życia systemu informacyjnego
C.d. wstępu do tematyki RUP
Unified Modeling Language graficzny język wizualizacji, specyfikowania, tworzenia i dokumentowania systemów informatycznych.
Wykonawcy:Magdalena Bęczkowska Łukasz Maliszewski Piotr Kwiatek Piotr Litwiniuk Paweł Głębocki.
Twoje narzędzie do pracy grupowej
Źródła: podręcznikopracował: A. Jędryczkowski.
Zbiory biblioteczne W bibliotekach gromadzone są różnorodne zbiory, między innymi: książki, filmy na kasetach VHS oraz DVD, różne programy multimedialne,
Podstawy działania wybranych usług sieciowych
Programowanie obiektowe – język C++
Programowanie obiektowe 2013/2014
Modelowanie obiektowe Diagramy czynności
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
1 Każdy obiekt jest scharakteryzowany poprzez: tożsamość – daje się jednoznacznie wyróżnić; stan; zachowanie. W analizie obiektowej podstawową strukturą
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Opracowała: Edyta Guznowska – nauczyciel-bibliotekarz
Unified Modeling Language - Zunifikowany Język Modelowania
Modelowanie obiektowe Diagramy klas
Proces tworzenia oprogramowania
IBUK Libra WIRTUALNA CZYTELNIA
Projektowanie relacyjnych baz danych – postacie normalne
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski 1 informatyka +
Model obiektowy bazy danych
PROCESY W SYSTEMACH SYSTEMY I PROCESY.
Komputerowe wspomaganie projektowania
Diagram przypadków użycia
Diagram klas Kluczowymi elementami są: klasy (class)
Zarządzanie zagrożeniami
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Przykłady analiza i projektowanie
Temat 6: Dokumentacja techniczna urządzeń sieciowych.
Modelowanie obiektowe - system zarządzania projektami.
Diagram obiektów Diagram obiektów ukazuje elementy i związki z diagramu klas w ustalonej chwili. Diagram obiektów jest grafem złożonym z wierzchołków i.
Projektowanie obiektowe. Przykład: Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy. Przykład: Diagram.
Projektowanie architektoniczne
Diagramy przepływu danych
Projektowanie bazy danych z użyciem diagramów UML Obiektowe projektowanie relacyjnej bazy danych Paweł Jarecki.
Część 1.  Pierwszym etapem metodyki strukturalnej jest analiza strukturalna której efektem jest model podstawowy systemu.
Projektowanie oprogramowania czasu rzeczywistego
Platforma .Net.
Projektowanie postaci formularza:
Wstęp do systemów informatycznych Model przypadków użycia.
E. Stemposz. Rational Unified Process, Wykład 10, Slajd 1 wrzesień 2002 Powrót Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 10 Przepływ.
Temat: Tworzenie bazy danych
Analiza, projekt i częściowa implementacja systemu wspomagania pracy Referatu Reprografii Promotor: mgr inż. Dariusz OlczykWykonała: Katarzyna Ściwiarska.
Inżynieria systemów informacyjnych
T. 18. E Proces DGA - Działania (operatorka).
Inżynieria Oprogramowania Laboratorium
Przeczytaj wszystko na temat wiadomości programu Microsoft SharePoint
Zapis prezentacji:

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; 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.

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

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.

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.

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.

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.

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ń.

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

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

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.

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.

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

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.

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

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.

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”

Opis stanów dla kuchenki mikrofalowej

Opis bodźców dla kuchenki mikrofalowej

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.

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

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.

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ł 1 ma-wiązanie n Wiązanie nazwa typ nazwa typ 2 wiązania 1 Etykieta nazwa treść ikona ma-etykietki ma-etykietki n n

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.

Przykłady haseł słownika danych

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.

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.

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.

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.

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

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

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

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

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.

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

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.

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

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.

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

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

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.

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.