Analizy systemowe

Slajd nr 2

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele systemu

Zawartość:



Modele kontekstowe



Modele zachowania



Modele danych



Modele obiektowe



Warsztaty CASE

Slajd nr 3

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele systemu



Wymagania użytkownika spisujemy w języku

naturalnym, aby były zrozumiały dla osób, które

nie są ekspertami od technologii.



Bardziej szczegółowe wymagania możemy

definiować w sposób bardziej techniczny.



Jednym ze sposobów jest dokumentowanie

systemu za pomocą zbioru jego modeli.



Dzięki użyciu graficznych środków wyrazu,

modele są bardziej zrozumiałe niż szczegółowy

opis w języku naturalnym.



W procesie analizowania modele mogą służyć do

lepszego zrozumienia istniejącego systemu lub

rzeczywistości.

Slajd nr 4

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele systemu



Zobrazowanie systemu z różnych punktów
widzenia :



Zewnętrzny punkt widzenia – modelujemy kontekst
lub środowisko systemu.



Zachowanie systemu – modelujemy zachowanie
systemu.



Strukturalny punkt widzenia – modelujemy
architekturę systemu lub strukturę przetwarzania
danych.

Slajd nr 5

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele systemu



Najważniejszą cechą modelu systemu jest to, że
pomija szczegóły.

Model systemu jest abstrakcją

badanego systemu a nie jego alternatywną
reprezentacją.

Abstrakcja

to rozmyślne

uproszczenie i wyciąg najbardziej istotnych
charakterystyk.



Różne typy modeli są oparte na innych podejściach
do abstrakcji. Np.

model przepływów

dotyczy

głównie przepływu i funkcjonalnych przekształceń
danych . Pomija się w nim szczegóły struktur
danych. Model

encja-zwiazek

jest dokumentacją

danych systemu i związków między nimi.

Slajd nr 6

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele systemu



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 (kompozycji).

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.

Slajd nr 7

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele kontekstowe



We wczesnej fazie procesu określania i analizowania
wymagań należy ustalić granice systemu. Należy ustalić
co jest systemem a co jego środowiskiem.



Granica pomiędzy systemem a jego środowiskiem nie
zawsze jest czytelna. Granicę między systemem a
środowiskiem należy ustalić w trakcie inżynierii
wymagań.



Na następnym slajdzie widać model architektoniczny
zawierający strukturę systemu informacyjnego
obejmującego sieć bankomatów.



Modele architektoniczne wysokiego poziomu mają
zwykle postać prostych diagramów blokowych.
Podsystem jest reprezentowany przez prostokąt a linie
wskazują na powiązania

Slajd nr 8

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele kontekstowe

System

bankomat

System

księgowy

oddziału

System

obsługi

oddziału

System

konserwacj

System

zabezpiecz

eń

Baza danych

kont

Baza danych

użytkowaniu

Kontekst systemu bankomatu

Slajd nr 9

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele kontekstowe



W modelach architektonicznych opisuje się środowisko

systemu. Nie obejmują one jednak związków pomiędzy

innymi systemami a naszym.



Zewnętrzne systemy mogą produkować dane dla tego

systemu lub je konsumować.



Dane mogą być dzielone między systemami bezpośrednio

lub przez sieć. Mogą być w ogóle nie połączone.



Proste modele architektoniczne są zwykle uzupełniane

innymi modelami, takimi jak modele procesu, w których

zapisuje się czynności procesy wspomagane przez

system, modele przepływu danych. Przedstawia się

przekazywanie danych między systemem i innymi

systemami w środowisku



Na następnym slajdzie przedstawiono model procesu

zakupu wyposażenia dla firmy.

Slajd nr 10

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele kontekstowe

Wyspecyfikuj

potrzebne

wyposażenie

Sprawdź

specyfikację

Zdobądź

oszacowanie

kosztów

Zaakceptuj

protokół

odbioru

Zainstaluj

wyposażenie

Baza danych

z dostawcami

Zaakceptuj

dostarczone

wyposażenie

Sprawdź

dostarczone

towary

Baza danych

o wyposażeniu

Złóż zamówienie

na wyposażenie

Znajdź

dostawców

Wybierz

dostawcę

Specyfikacja

wyposażenia

Sprawdzona

specyfikacja

Protokół

odbioru

Protokół

odbioru

Instrukcja

montażu

Akceptacja

instalacji

Szczegółowe informacje o

wyposażeniu

Szczegóły zamówienia

+ czysty blankiet

zamówienia

Specyfikacja

wyposażenia

Lista

dostawców

Specyfikacja+

dostawca+

oszacowanie

Model procesu zakupu wyposażenia.

Przerywana linia oznacza czynności leżące

wewnątrz systemu

Slajd nr 11

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele zachowania



Modele zachowania są używane do ogólnego
opisywania zachowania systemu.
Przedstawimy dwa modele:



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.

Slajd nr 12

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele przepływu danych



Modele przepływu danych są intuicyjnym sposobem

przedstawienia, jakie 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



przekazywania danych między funkcjami



Modele przepływu danych są stosowane do pokazania, jak

dane przepływają w sekwencji kroków przetwarzania. Dane

ulegają przekształceniu w każdym kroku



Na następnym slajdzie przedstawiono model przepływu

danych, w którym zapisano kroki obsługi zamówienia na

towary dla firmy. Jest to rozwinięcie czynności „złóż

zamówienie na wyposażenie”

Slajd nr 13

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele przepływu danych

Wypełnij

blankiet

zamówienia

Sprawdź

zamówienie

Zaktualizuj budżet

dostępnych środków

Baza danych

z dostawcami

Wyślij do

dostawcy

Baza danych

o wyposażeniu

Szczegóły

zamówienia

+ czysty

blankiet

zamówienia

Zarejestruj

zamówienie

Wypełniony

blankiet

zamówienia

Podpisany

formularz

zamówienia

Podpisany

formularz

zamówienia

Podpisany

formularz

zamówienia

+ szczegóły

zamówienia

Sprawdzone i

podpisane

zamówienie +

informacja

o zamówieniu

Wartość

zamówienia

+ informacje

księgowe

Slajd nr 14

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele przepływu danych



W notacji używanej do opisu przepływu
danych:



owale oznaczają kroki przetwarzania



strzałki z nazwami danych to przepływy



prostokąty są magazynami lub źródłami danych



Modele przepływu danych pozwalają
analitykom zrozumieć działanie systemu



Zaletą diagramów jest to że są proste i
intuicyjne



Opracowywanie przepływu danych powinno
być zstępujące.

Slajd nr 15

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele maszyn stanowych



Modele maszyn stanowych służą do opisywania
reakcji systemu na wewnętrzne i zewnętrzne
zdarzenia.



Model maszyny stanowej zawiera stany i zdarzenia,
które powodują przejście z jednego stanu do innego.
Model nie obejmuje przepływu danych w ramach
systemu.



W modelu maszyny stanowej zakłada się, że w danej
chwili system jest w jednym z kilku dopuszczalnych
stanów. Otrzymany bodziec może spowodować
przejście do innego stanu.



Modele bardzo przydatne w systemach czasu
rzeczywistego ale nie tylko.

Slajd nr 16

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele maszyn stanowych



Omówimy przykład sterowania kuchenki
mikrofalowej. W uproszczeniu kolejność
czynności jest następująca;



Wybierz poziom mocy (połowa lub pełna)



Ustaw czas gotowania



Naciśnij przycisk ‘początek’; potrawa będzie gotowana
przez określony czas.



Ze względów bezpieczeństwa kuchenka
powinna działać przy zamkniętych drzwiach. Po
zakończeniu gotowania odzywa się brzęczyk.



kuchenka ma wyświetlacz alfanumeryczny, który
pokazuje komunikaty alarmowe i ostrzegawcze.

Slajd nr 17

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele maszyn stanowych

Pełna moc

do:

ustaw moc

= 600

Połowa mocy

do:

ustaw moc

= 300

Niegotowy

do:

wyświetlaj

‘czekam’

Ust. czasu

do:

odczyt.

liczbę

exit: ustaw

czas

Działanie

do:

podgrzewanie

Oczekiwanie

do:

wyświetlaj

godzinę

Oczekiwanie

do:

wyświetlaj

godzinę

Gotowy

do:

wyświetlaj

‘gotowy’

Pełna moc

Połowa

mocy

Polowa mocy

Pełna moc

Liczba

Stoper

Otworzono

drzwiczki

Początek

Zatrzymaj

Otworzono

drzwiczki

Slajd nr 18

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele maszyn stanowych



Model na poprzednim slajdzie jest zapisany w
notacji UML przeznaczonej do modelowania
zachowania obiektów.



Prostokąty z zaokrąglonymi rogami oznaczają
stany systemu. Po słowie ‘do:’ (‘wykonaj’)
zawierają krótką informacje o wykonywanej
akcji.



Strzałki z etykietami reprezentują bodźce,
które powodują przejścia między stanami.

Slajd nr 19

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele danych



Modelowanie danych za pomocą programu ERWin
firmy CA. Typowy model encja-relacja.



Encja to logiczny obiekt korespondujący z rzeczami
lub osobami. Encja posiada atrybuty dla każdego
ważnego elementu informacyjnego.



Encje są powiązane między sobą związkami
(relacjami).



relacja jeden do jednego



relacja jeden do wielu



relacja wielu do jednego



relacja wielu do wielu



Encje są przekształcane w tabele a atrybuty w
kolumny

Slajd nr 21

Modele danych

element_id - element_id

klient_id - klient_id

element_id - element_id

zlecenie_id - zlecenie_id

element

element_id: NUMBER

opis: char(64)
koszt: int
cena: int

zapas

element_id: NUMBER

ilosc: NUMBER

kodkreskowy

kodkreskowy: varchar(13)
element_id: NUMBER

liniezlecen

zlecenie_id: NUMBER
element_id: NUMBER

ilosc: NUMBER

zlecenieinfo

zlecenie_id: NUMBER
klient_id: int
element_id: NUMBER

data_dostawy: DATE
data_wysylki: DATE
dostawa: NUMBER

klient

klient_id: int

nazwa: char(32)
adres: varchar(64)
miasto: varchar(32)
kod: varchar(5)
telefon: varchar(16)

Slajd nr 22

Modele obiektowe



Modele obiektowe opracowywane w trakcie
analizy wymagań, mogą być używane do
przedstawiania samego systemu jak i jego
działania.



Modele obiektowe są naturalnym sposobem
odzwierciedlania encji pochodzących ze świata
rzeczywistego.



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.

Slajd nr 23

Modele obiektowe



Opis klasy obiektów w UML (Unified Modeling
Language)

Nazwa klasy

Atrybuty

klasy

Operacje

związane

z klasą

Składnik biblioteki

Numer katalogowy

Data zakupu

Cena

Typ

Stan

Liczba kopii

Nabądź ( )

Skataloguj ( )

Usuń ( )

Udostępnij ( )

Zwróć ( )

Slajd nr 24

Modele dziedziczenia

Składnik biblioteki

Numer katalogowy

Data zakupu

Cena

Typ

Stan

Liczba kopii
Nabądź ( )

Skataloguj ( )

Usuń ( )

Udostępnij ( )

Zwróć ( )

Składnik opublikowany

Tytuł

Wydawca

Składnik utrwalony

Tytuł

Nośnik

Czasopismo

Rok

Numer

Film

Reżyser

Data premiery

Dystrybutor

Książka

Autor

Wydanie

Data wydania

ISBN

Program komput.

Wersja

Platforma

Slajd nr 25

Modele dziedziczenia



Modelowanie obiektowe obejmuje identyfikację
klas obiektów istotnych w badanej dziedzinie.



Znalezione obiekty są następnie
systematyzowane. Systematyka jest schematem
klasyfikacji, w której widać jak klasy obiektów są
powiązane między sobą przez wspólne atrybuty i
usługi.



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.

Slajd nr 26

Warsztaty CASE



Edytory diagramów

, które służą do tworzenia

diagramów przepływu danych, diagramów encja-

związek itd.



Narzędzia do analizy i sprawdzania projektu

, które

przetwarzają projekt i informują o znalezionych

błędach i anomaliach.



Języki zapytań do repozytorium

, które służą

projektantom do wyszukiwania projektów i

powiązanych z nim informacji projektowych w

repozytorium.



Słownik danych

, który przechowuje informacje o

bytach występujących w projekcie systemu.



Narzędzia do definiowania i generowania raportów

które pobierają informację z centralnej składnicy i

automatycznie generują dokumentację systemu.

Slajd nr 27

Warsztaty CASE



Narzędzia do definiowania formularzy

, które

służą do specyfikowania formatów ekranów i
dokumentów.



Udogodnienia do importu i eksportu

, które

umożliwiają wymianę informacji między
centralnym repozytorium a innymi
narzędziami wytwórczymi.



Generatory kodu

, które automatycznie

generują kod albo szkielet kodu na podstawie
projektu zapisanego w centralnej składnicy.

Slajd nr 28

Central

information

repository

Code

generator

Query

language

facilities

Structured

diagramming

tools

Data

dictionary

Report

generation

facilities

Design, analysis

and checking

tools

Forms

creation

tools

Import/export

facilities

Warsztaty CASE

Document Outline