SI  dynamika w modelowaniu -
repetytorium; Uzupełnienie:
Wymagania niefunkcjonalne
dr inż. M. Żabińska ([e-mail])
Strukturalne metody analizy
Rozwijane od dawna, lata 80-te
Opierają się na wyróżnianiu w analizowanym
systemie dwóch rodzajów składowych:
Pasywnych  fakt przechowywania w systemie pewnych
danych
Aktywnych  fakt wykonywania w systemie pewnych
operacji
Budowa dwóch modeli: danych (n-cji) i funkcji
(przez różne zespoły); integracja modeli (trudna)
Uzupełnienie modelem dynamiki !
Zasada dekompozycji i modularyzacji 
dekompozycja głównie w warstwie funkcjonalnej
systemu, powiązanie z zasadą modularyzacji
Strukturalne podejście do analizy (1)
Structured Analysis & Design  SA&D lub SA/SD:
Wg modelu cyklu klasycznego (kaskadowego),
Tworzenie logicznego (podstawowego) modelu systemu, tj.
 co system powinien robić, by spełnić postawione
wymagania ,
Problemy i funkcje  iteracyjnie dekomponowane 
mniejsze części (reorganizacja, uszczegółowienie modelu
zgodnie z wymaganiami), top-down
Opis:
funkcji systemu,
struktur danych,
uwzględniając zależności czasowe.
Koncepcja: hierarchiczna dekompozycja logiczna (w sferze
funkcjonalnej)
Strukturalne podejście do analizy (2)
Strukturalne podejście do analizy (3)
Hierarchiczna dekompozycja logiczna
(funkcjonalna)  z wykorzystaniem diagramów
przepływu danych (DFD  Data Flow Diagrams)
i sterowania;
Uzupełnienie o logiczną reprezentację danych
(ERD  Entity Relationship Diagrams)
Oraz model zależności czasowych (STD 
State Transition Diagrams; starsze: ELH 
Entity Life History).
Modelowanie w metodyce strukturalnej (1)
Opis systemu: trzy (aspekty)  trzy modele (rys.)
Model (aspekt) funkcjonalny  transformacje danych
wewnątrz systemu
(Data Flow Diagram DFD graf: węzły  procesy, łuki 
przepływy danych)
Model (aspekt) danych  statyczna struktura systemu
(Entity Relationship Diagram ERD graf: węzły  obiekty
abstrakcja świata rzeczywistego, łuki  relacje/związki
pomiędzy obiektami)
Model (aspekt) dynamiki  zmienność w czasie
(State Transition Diagram STD graf węzły  stany, łuki 
przejścia pomiędzy stanami, wywoływane przez zdarzenia),
lub Entity Life History ELH (obiekty z ERD, zdarzenia 
operacje BD, SSADM)
Modelowanie dynamicznych aspektów
systemu (1)
Cel:
przedstawienie zmian stanu obiektów w
czasie
trzecia płaszczyzna widzenia systemu oparta
na zdarzeniach (z DFD), które oddziałują na
obiekty (z ERD).
DFD przedstawia procesy i dane
ERD koncentruje się wyłącznie na danych
(zawartości Data Stores) - podejście
statyczne
Potrzeba pokazania czasu - dynamiki systemu
Modelowanie dynamicznych aspektów
systemu (2)
Stan [Y] - zbiór okoliczności lub cech
charakteryzujących obiekt w danej chwili
Do opisywania RT (głównie)
Obejmuje trzy typy obiektów: stan, przejście, interface
(warunek/akcja)
Dobre uzupełnienie DFD (pokazuje następstwa
czasowe procesów z DFD): warunki = zdarzenia -
przepływy danych wejściowych (powodują zmianę
stanu); akcje - dane wyjściowe z procesu
Analiza Strukturalna [Y] oraz OOA+OOD [C+Y] i in.,
np. UML
Modelowanie dynamicznych aspektów
systemu (3)
Symbole używane na
START
diagramach STD:
stan
warunek
Pokazywanie warunków
przejście
akcja
akcji:
stan
stan, przejście:
warunek, akcja, interfejs
STOP
[Yourdon  Analiza
strukturalna ]
Modelowanie dynamicznych aspektów
systemu (4)
Związek między DFD a STD
Modelowanie dynamicznych aspektów
systemu (5)
Budowanie STD
Identyfikacja wszystkich możliwych
stanów obiektu/systemu - obraz
graficzny (prostokąty), potem badanie
sensownych połączeń (zmian stanów),
Określenie stanu początkowego dla
obiektu, potem metodyczne
przechodzenie do następnych stanów.
Modelowanie dynamicznych aspektów
systemu (6)
Sprawdzanie diagramów STD
Czy zdefiniowano wszystkie stany,
Czy wszystkie stany są osiągalne (każdy stan
dostępny ze stanu początkowego),
Czy istnieją wyjścia ze wszystkich stanów
(stan końcowy dostępny dla każdego stanu),
Czy warunek przejście ze stanu do tylko
jednego innego stanu,
Czy w każdym stanie poprawna odpowiedz
,
Czy uwzględniono sytuacje nieokreślone.
Modelowanie dynamicznych aspektów
systemu (7)
Diagram przejść/zmian stanów STD (Diagram
Stanów)
Technika opisu zachowania obiektu,
(systemu), różne notacje;
Opis:
wszystkich możliwych stanów, do których
może przejść dany obiekt
jak zmienia się stan obiektu pod wpływem
zdarzeń do niego docierających
Modelowanie dynamicznych aspektów
systemu (8)
Stany:
Stan jest chwilą w życiu obiektu
Stan jest odpowiedzią obiektu na zdarzenia
Stan reprezentuje przedział czasowy między
dwoma zdarzeniami oddziaływującymi na
obiekt
Zdarzenia to punkty w czasie, stany
reprezentują okresy czasu
Modelowanie dynamicznych aspektów
systemu (9)
Na diagramie przejść stanowych:
klasa obiektów w systemie reprezentowana
jako automat skończony,
automat skończony  czyli mechanizm, który
może się znajdować w jednej chwili w jednym
ze skończonej liczby ustalonych stanów.
przykład: Rys. Diagram stanu dla  Towar
Modelowanie dynamicznych aspektów
systemu (10)
Przyjęty
Przyjmij towar
na stan
Wycofany
Zaoferuj towar
Wycofaj ze sprzedaży
Oferuj ponownie
Oferowany
Sprawdzany
Udostępnij na próbę
Przyjmij zwrot
Sprzedaj
Sprzedany
Próbowany
Stan
Stan końcowy
Stan początkowy
Zdarzenie
Modelowanie dynamicznych aspektów
systemu (11)
Techniki obiektowe
Diagramy stanów rysowane dla pojedynczych klas,
aby pokazać cały cykl życia pojedynczego obiektu
Wiele postaci diagramów stanu, każda z nieco inną
semantyką
Postać z UML  oparta na mapach stanów Davida
Harela( Rzecz o istocie informatyki )
Przykład: Rys. Diagram stanu dla  Zamówienie
Modelowanie dynamicznych aspektów
systemu (12)
Syntaktyka etykiety przejścia  trzy części; każda
opcjonalna:
zdarzenie [dozór]/ akcja
dozór= warunek logiczny (przejście gdy zwracana 
prawda , ze stanu można wybrać tylko jedno
przejście, warunki dla zdarzeń wykluczanie)
akcje  związane z przejściami (procesy  szybkie )
czynności  związane ze stanami ( dłuższe ), mogą
być przerwane przez zdarzenie; etykieta: do/
czynność
oba procesy implementowane przez metody klasy
Modelowanie dynamicznych aspektów
systemu (13)
Modelowanie dynamicznych aspektów
systemu (14)
Jeżeli z przejściem nie jest stowarzyszone zdarzenie =>
przejście zaraz po zakończeniu czynności związanych
ze stanem
Np. stan  Sprawdzanie ; Jeśli... należy przejść do
stanu...(trzy warunki)
 Sprawdzanie pobranie pozycji i powrót
 Oczekiwanie bez czynności, czeka na zdarzenie
 Pozycja otrzymana
 Wysyłka  przejście do  Dostarczone
Anulowanie zamówienia przed dostawą: przejścia z
trzech stanów:  Sprawdzanie ,  Oczekiwanie ,
 Wysyłka , lub stan złożony
Zdarzenia: zewnętrzne (nazwane), wewnętrzne (czas,
np. after ..., warunek when ... ), specjalne (entry, exit,
każde we/wy do/ze stanu)
Modelowanie dynamicznych aspektów
systemu (15)
Początek
/pobierz pierwszą pozycję
[Wszystkie pozycje
[Nie wszystkie pozycje
sprawdzone &&
sprawdzone]/pobierz
wszystkie pozycje są
następną pozycję
dostępne]
Sprawdzenie Wysyłka
do/sprawdz
pozycję do/inicjuj dostawę
[Wszystkie pozycje
Czynność
sprawdzone &&
niektórych pozycji
brak w magazynie]
dostarczone
Pozycja otrzymana
Przejście
[niektórych pozycji
brak w magazynie]
Anulowane
Stan
Oczekiwanie
Dostarczone
Anulowane
Diagram stanów dla  zamówienie - zmodyfikowany
(II wariant: można tworzyć stan złożony)
a
n
a
e
j
m
c
y
y
z
z
r
o
t
p
o
]
e
e
a
i
j
n
k
c
p
t
y
e
s
z
t
y
s
o
z
o
s
P
d
w
[
Modelowanie dynamicznych aspektów
systemu (16)
Uwagi:
Przydają się do opisywania zachowania obiektu
obejmującego kilka przypadków użycia systemu
Nie nadają się do opisu zachowań obejmujących
współdziałanie wielu obiektów
Nie należy rysować dla każdej klasy systemu;
dla klas, które mają interesujące zachowanie
Tworzyć, gdy pomagają zrozumieć co się dzieje
Popularny pogląd: zachowanie obiektów
sterujących i obiektów interfejsu warto
przedstawić na STD
(1)
Entity Life History Diagrams (ELH)
Zasady tworzenia diagramów ELH:
tworzenie tablicy krzyżowej
obiekt/zdarzenia przez:
wybranie obiektów z ERD,
identyfikację (na podstawie
DFD) zdarzeń dotyczących
danego obiektu,
dodatkowe rozważenie funkcji
utrzymania w systemie - CRUD
(I, M, D, R)
rozważenie dla każdego obiektu z
ERD:
normalnego cyklu życia,
zdarzeń specjalnych
(wyjątkowych),
sytuacji błędnych.
(2)
Entity Life History Diagrams (ELH)
Analiza strukturalna (SA&D) (1)
Modelowanie  trzy aspekty ! (patrz Rys.)
(Trzech ślepców dotykających słonia  [Y])
Równoważenie modeli
Weryfikacja całości
Sprawdzanie zgodności modeli i specyfikacji
Różne kombinacje:
DFD, ERD, STD,
Data Dictionary(DD), specyfikacja procesów
(pseudokod)
Analiza strukturalna (SA&D) (2)
Bilansowanie w następujących przekrojach:
DFD względem DD
DFD względem specyfikacji procesów,
specyfikacji procesów względem DD,
ERD względem DFD,
ERD względem DD,
DFD względem STD,
Uzupełnienie: Wymagania
niefunkcjonalne (1)
Wymagania niefunkcjonalne: nie dotyczą
bezpośrednio konkretnych funkcji systemu:
ograniczenia usług i funkcji systemu (np.
czasowe, dotyczące procesu tworzenia,
standardy, itd.).
Mogą być związane z właściwościami systemu:
czas reakcji, niezawodność, zajętość pamięci.
Mogą definiować ograniczenia systemu
(możliwości urządzeń wejścia-wyjścia,
reprezentacje danych używane przez interfejsy).
Uzupełnienie: Wymagania
niefunkcjonalne (2)
Wymagania niefunkcjonalne:
Zwykle dotyczą systemu jako całości, nie
poszczególnych cech systemu => bardziej
istotne niż w. funkcjonalne (niespełnienie =
pogorszenie cech systemu ale: niespełnienie
pewnego wymagania niefunkcjonalnego 
system może być bezużyteczny).
Mogą dotyczyć: nie tworzonego systemu lecz
ograniczać proces tworzenia systemu (np.
specyfikacja standardów dla procesu, metodyka,
narzędzia, sposób opisu, itd.).
Uzupełnienie: Wymagania
niefunkcjonalne (3)
Wymagania niefunkcjonalne:
Wynikają z: potrzeb użytkownika, ograniczeń
budżetowych, strategii firmy, konieczności
współpracy z innymi systemami (sprzętu lub
oprogramowania), czynników zewnętrznych jak
przepisy o bezpieczeństwie, ustawy chroniące
prywatność, itd.
Uzupełnienie: Wymagania
niefunkcjonalne (4)
Klasyfikacja:
Wymagania produktowe
Wymagania organizacyjne
Wymagania zewnętrzne
Uzupełnienie: Wymagania
niefunkcjonalne (5)
Klasyfikacja:
Wymagania produktowe  zachowanie
produktu (wymagania efektywnościowe 
szybkość działania systemu i potrzeb pamięci,
w. niezawodności  akceptowalna częstość
awarii),
w. przenośności, wymagania użyteczności.
Uzupełnienie: Wymagania
niefunkcjonalne (6)
Klasyfikacja:
Wymagania organizacyjne  wynikają ze
strategii i procedur
w firmie-kliencie i w firmie-wytwórcy (standardy
procesu, w. implementacyjne: język, metoda
programowania, wymagania dostawy  kiedy
dostarczyć produkt i jego dokumentację).
Uzupełnienie: Wymagania
niefunkcjonalne (7)
Klasyfikacja:
Wymagania zewnętrzne  szeroka kategoria:
wszystkie wymagania wynikające z czynników
zewnętrznych dla systemu i procesu jego
tworzenia (wymagania współpracy: interakcje
z systemami innych firm, prawne, etyczne:
akceptacja).
Uzupełnienie: Wymagania
niefunkcjonalne (8)
Wymagania produktowe:
użyteczności,
sprawnościowe:
efektywności,
pamięci.
niezawodności,
przenośności.
Uzupełnienie: Wymagania
niefunkcjonalne (9)
Wymagania organizacyjne:
dostawy,
implementacyjne,
standardów.
Uzupełnienie: Wymagania
niefunkcjonalne (10)
Wymagania zewnętrzne:
współpracy,
etyczne,
prawne:
ochrony prywatności,
wymagania zabezpieczeń.
Uzupełnienie: Wymagania
niefunkcjonalne (11)
Dobrze sformułowane wymagania
niefunkcjonalne:
powinny być weryfikowalne  możliwość
sprawdzenia czy system je spełnia.
wymagania sformułowane jako stwierdzenia,
np.: łatwy w obsłudze, niezawodny, wydajny -
nie mogą być obiektywnie zweryfikowane;
konieczność wyrażenia wymagań przy pomocy
wielkości mierzalnych
Uzupełnienie: Wymagania
niefunkcjonalne (12)
Przykład formularza opisu wymagań
niefunkcjonalnych (np. porównywanie
rozwiązań)
Cecha: Miary:
Liczba trans. obsłużonych/s.
Wydajność:
Wymagana pamięć RAM;
Rozmiar:
Wymagana pamięć dyskowa
A
atwość użytkowania: Czas na przeszkolenia
Liczba stron dokumentacji
Uzupełnienie: Wymagania
niefunkcjonalne (13)
Cecha: Miary:
Niezawodność:
Prawdopodobieństwo błędnego
wykonania podczas realizacji
transakcji
Częstotliwość błędnych wykonań
Średni czas między błędnymi
wykonaniami
Dostępność (procent czasu)
Uzupełnienie: Wymagania
niefunkcjonalne (14)
Cecha: Miary:
Odporność:
Czas restartu po awarii
systemu
Prawdopodobieństwo
zniszczenia danych w
przypadku awarii
Uzupełnienie: Wymagania
niefunkcjonalne (15)
Cecha: Miary:
Przenośność:
Procent kodu zależnego
od platformy docelowej
Liczba platform
docelowych
Koszt przeniesienia na
nową platformę
Uzupełnienie: Wymagania
niefunkcjonalne (16)
Dobrze sformułowane wymagania
niefunkcjonalne (WNF):
powinny być weryfikowalne - WNF można
stosować jako miary jakości systemu (por.
ocena rozwiązań w fazie strategicznej)
Często nazywane  pożądanymi cechami
systemu informatycznego
Wymagania F. i WNF  tzw. wymagania
dziedzinowe  dotyczą dziedziny zastosowania
systemu i odzwierciedlają charakterystykę
Podsumowanie