Inżynieria oprogramowania

część VII – Modele systemu

mgr inż. Piotr Greniewski

Europejska Wyższa Szkoła Informatyczno-

Ekonomiczna

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

u

System

księgowy

oddziału

System

obsługi

oddziału

System

konserwacj

i

System

zabezpiecz

eń

Baza danych

kont

Baza danych

o

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 20

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele danych



Encje dzielimy na;



niezależne (independent) oznaczane prostokątami



zależne (dependent) oznaczone prostokątami o
zaokrąglanych bokach

Slajd nr 21

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele danych

element_id - element_id

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

©Ian Sommerville 2000 - Inżynieria oprogramowania

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

©Ian Sommerville 2000 - Inżynieria oprogramowania

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

©Ian Sommerville 2000 - Inżynieria oprogramowania

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

©Ian Sommerville 2000 - Inżynieria oprogramowania

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

©Ian Sommerville 2000 - Inżynieria oprogramowania

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

©Ian Sommerville 2000 - Inżynieria oprogramowania

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

©Ian Sommerville 2000 - Inżynieria oprogramowania

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