Transcript System models - Katedra Fizyki Teoretycznej i Informatyki

Modele systemu

Abstrakcyjny opis systemów
służących do analizy wymagań
©Ian Sommerville 2000
Inżynieria oprogramowania, Rozdział 7
Slide 1
Cele




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ść

Modele strukturalne
Modele kontekstowe
Modele zachowania
Modele danych, w tym słowniki
Modele obiektowe

Warsztaty CASE




©Ian Sommerville 2000
Inżynieria oprogramowania, Rozdział 7
Slide 3
Modelowanie systemu

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

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



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






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



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


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




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
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



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
projekt
projekt
projektu
użytkownika
Edytor
Weryfikator
Analizator
Generator
projektów
projektów
i
projektów
raportów
Wykorzystywane
Sprawdzony
projekty
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





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ęt
Zatrzymaj
Stoper
o
Otworzono
Początek
drzwiczki
Otworzono
drzwiczki
Połowa mocy
Oczekiwanie
drzwiczki
do: ustaw moc
do: wyświetlaj
Zamknięto Gotowy
= 300
godzinę
drzwiczki do: wyświetlaj
„Gotowy”
Niegotowy
do: wyświetlaj
„Czekam”
©Ian Sommerville 2000
Inżynieria oprogramowania, Rozdział 7
Slide 18
Opis stanów dla kuchenki
mikrofalowej
Stan
Oczekiwanie
Połowa mocy
Pełna moc
Ustawienie
czasu
Niegotowy
Gotowy
Działanie
Opis
Kuchenka czeka na dane wejściowe. Wyświetlacz pokazuje
aktualną godzinę.
Moc kuchenki ustawiono na 300 watów. Wyświetlacz
pokazuje napis „Połowa mocy”.
Moc kuchenki ustawiono na 600 watów. Wyświetlacz
pokazuje napis „Pełna moc”.
Czas trwania gotowania jest ustawiany na wartość
wprowadzoną przez użytkownika. Wyświetlacz pokazuje
wybrany czas gotowania i jest aktualizowany w miarę
wprowadzania danych.
Kuchenka nie może działać ze względów bezpieczeństwa.
Wewnętrzne światło kuchenki jest włączone. Wyświetlacz
pokazuje napis „Niegotowy”.
Kuchenka jest gotowa do działania. Wewnętrzne światło jest
wyłączone. Wyświetlacz pokazuje napis „Gotowy”.
Kuchenka działa. Wewnętrzne światło jest włączone.
Wyświetlacz odlicza zmniejszający się czas pozostały do
zakończenia gotowania. Po zakończeniu brzęczyk włącza się
na 5 sekund. Światło kuchenki jest wtedy włączone.
Wyświetlacz pokazuje napis „Gotowanie zakończone” w
czasie działania brzęczka.
©Ian Sommerville 2000
Inżynieria oprogramowania, Rozdział 7
Slide 19
Opis bodźców dla kuchenki
mikrofalowej
Bodziec
Opis
Połowa mocy
Użytkownik nacisnął przycisk “Połowa mocy”
Pełna moc
Użytkownik nacisnął przycisk “Pełna moc”
Stoper
Użytkownik nacisnął przycisk “Stoper”
Liczba
Użytkownik nacisnął przycisk z liczbą
Otworzono
drzwiczki
Zamknięto
drzwiczki
Początek
Zatrzymaj
©Ian Sommerville 2000
Przełącznik drzwiowy jest niezamknięty
Przełącznik drzwiowy jest zamknięty
Użytkownik nacisnął przycisk “Początek”
Użytkownik nacisnął przycisk “Zatrzymaj”
Inżynieria oprogramowania, Rozdział 7
Slide 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.
©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


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




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
Nazwa
maetykietki
Etykietka
Wiązanie
nazwa
(etykietki)
nazwa
(węzła)
©Ian Sommerville 2000
Opis
Związek 1:N między encjami typu
Węzeł lub Wiązanie I encjami typu
Etykietka.
Przechowuje
strukturalną
lub
niestrukturalną
informację
o
węzłach lub wiązaniach. Etykietki są
przedstawiane jako ikona (która
może
być
przezroczystym
prostokątem) i treść.
Związek 1:1 między bytami projektu
reprezentowanymi
jako
węzły.
Wiązania mają typy i mogą być
nazwane.
Każda etykietka ma nazwę, która
określa typ etykietki. Nazwa musi
być unikatowa w zbiorze typów
etykietek
w
ramach
jednego
projektu.
Każdy węzeł ma nazwę, która musi być
unikatowa w ramach projektu. Nazwa
może mieć najwyżej 64 znaki.
Inżynieria oprogramowania, Rozdział 7
Typ
Data
Związek
5.10.1998
Encja
8.12.1998
Związek
8.12.1998
Atrybut
8.12.1998
Atrybut
15.11.1998
Slide 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.
©Ian Sommerville 2000
Inżynieria oprogramowania, Rozdział 7
Slide 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.
©Ian Sommerville 2000
Inżynieria oprogramowania, Rozdział 7
Slide 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.
©Ian Sommerville 2000
Inżynieria oprogramowania, Rozdział 7
Slide 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.
©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
cor ed ite
Tytuł
itle
Wydawca
Publi he
Książka
Autor
Wydanie
Data wydania
ISBN
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


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



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
Przezrocza
Notatki
Tekst
Kaseta wideo
Id kasety
Rozwiązania
Tekst
Diagramy
Inżynieria oprogramowania, Rozdział 7
Slide 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.
©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
©Ian Sommerville 2000
Inżynieria oprogramowania, Rozdział 7
Slide 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.
©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








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




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


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