Document

1. Jak można strukturalizować diagramy zmian stanu?
Diagramy zmian stanów można stukturalizować za pomocą agregacji lub generalizacji.
Diagramy wchodzące w skład agregacji odpowiadają obiektom zagregowanym w obiekcie bazowym, są odwzorowaniem agregacji z diagramu klas. Natomiast generalizacja to zagnieżdżenie
diagramów stanów, co jest wynikiem uszczegółowiania diagramów.
Generalizacja pozwala na opis na wysokim poziomie i potem uszczegółowianie na coraz niższych poziomach.
Tworzy sie wtedy struktura hierarchiczna z dziedziczeniem wspólnych zachowań i struktury.
Stany mogą mieć podstany, które dziedziczą przejścia superstanów. Przejście, akcja superstanu dotyczy wszystkich jego podstanów.
2. Typy powiązań w diagramach klas.
Powiązanie to fizyczne lub konceptualne zalezności pomiędzy obiektami (ważne rzeczowniki z dziedziny problemu). Typy relacji to:
- asocjacja (poprzez to połączenie, klient prosi o usługę inny obiekt lub poprzez połączenie może sterować innym obiektem. modeluje relacje takie jak: "dotyczy", "komunikuje się", "obsługuje".
Asoscjacja może być dwukierunkowa lub jednokierunkowa, wtedy wskazujemy kierunek przepływu informacji),
- agregacja (modeluje relacje takie jak "składa się z", "jest zbudowany z", "jest częścią". Istnieje silniejsza wersja agregacji zwana kompozycją, która wskazuje, że obiekty częściowe są zależne od
jednej całości. Kiedy całość ginie, gina także jej części np: książka i kartki.)
- generalizacja (jest związkiem między klasą a"ulepszeniem", podklasami. atrybuty i operacje wspólne są umieszczane w superklasie. Podklasy dziedziczą operacje i atrybuty z klasy nadrzędnej
oraz rozszeżają podklasę o bardziej szczegółowe definicje, atrybuty)
3. Podać przykłady agregacji i opisać.
KSIĄZKA <>---* ROZDZIAŁ<>---*PARAGRAF
4. Do czego służy diagram zmian stanów?
Służą do modelowania zachowania obiektu. Diagramy stanów powinny być deterministyczne, tj. jednoznacznie określone.
Diagram określa reakcję obiektu na zdarzenia. Reakcja może być różna dla różnych stanów.
Odpowiedzią na zdarzenia może być akcja lub zmiana stanu obiektu.
Zdarzenia reprezentują chwilę czasu a stany- interwały czasu. Stan obieku zależy od sekwencji zdarzeń jakie obiekt otrzymał w przeszłości.
Stany charkteryzują: - nazwa stanu,- sekwencja zdarzeń powodująca wejście do tego stanu, - oczekiwane zdarzenia,- reakcje na zdarzenia - wykonanie akcji lub przejście do stanów następnych stan początkowy, - stan końcowy.
Podać diagramy klas dla następujących zdań:
7. "Aparat fotograficzny i kamera są urządzeniami do rejestracji obrazu"GENERALIZACJA
8. "Plik składa się z rekordów"AGREGACJA
9. "W plecaku są książki"ASOCJACJA
10. "Klient kupuje książki".ASOCJACJA
11. Jak organizować aktorów w diagramach (strukturalizować) use cas'y UML?
12. Jakie znacz typy relacji asocjacji i ich ograniczenia?
Typy:- asocjacja zwrotna – zachodzi pomiedzy obiektami tej samej klasy, - asocjacja ternarna- zachodzi po miedzy przynajmniej 3 klasami, jesli nie może być podzielony na związki binarne, bez
zutraty informacji, -asocjacja uporzadkowana - istotna jest kolejność w związku.
Ograniczenia:
- {subset}- wskazuje ze pewien zbior (kolekcja) jest wlaczony w inny zbior
- {exclusive or}- wskazuje ze dla danego obiektu jedynie jedna relacji asocjacji spośród relacji jest wlasciwa.
13.) Wymienić elementy składowe (fazy?) modelu warstwowego.
- specyfikacja wymagan (określanie funkcji systemu) - projektowanie oprogramowania - implementacja - testowanie - użytkowanie i pielegnacja.
Zalety: można przygotowac dokladna specyfikacje wymagan, możliwa jest weryfikacja systemun, łatwsc zarzadzania projektem, kazda faza konczy się czyms „fizycznie” istniejacym. Wady:
koszt usunieciabledow z poprzednich faz jest duzy, zadki kontakt z klientem, trudno okreslic koszt poszczegulnych faz.
14.) Co pokazuje diagram zmian stanów?
Model zachowania obiektow w czasie na skutek pewnych zdarzen.
15). Prototypowanie
Stosuje się w przypadku braków w specyfikacji, trudności w określeniu wymagan lub w nieporozumien z klientem i projektantem systemu.demonstracja pracujacego systemu, szkolenia zanim
zostanie zbudowany pełen system. Realizuje sie prototyp interfejsu użytkownika korzystając z generatorów interfejsów użytkownika.
Kroki:- ogólne określanie wymagan prototypowanego systemu. - opracowanie szybko działającego prototypu, - weryfikacja prototypu przez klienta, - określanie szczegolowych wymagan.
16). Testowanie strukturalne(testowanie „bialych skrzynek”)
Przy projektowaniu przypadkow testowych można korzystac ze znajomosci testowanego kodu. Osoba testujaca może analizowac kod, kozystac ze struktury komponentu do opracowania testu.
Znajomosc alg. Pozwala na znalezienie dalszych podzialow. Np. testowanie sciezek.
17). Wymagania funkcjonalne
Sa to uslugi oczekiwane przez uzytkownika (bez uwag implementacyjnych). WF Powinny być: - pełne, czyli zawierac wszystkie wymagania uzytkowanika, - spojne (nie sprzeczne).
18). Wymagania niefunkcjonalne
Sa to ograniczenia w jakich system ma pracowanic, standardy jakie spelniac np. –czas odp, -zajetosc pamieci, -niezawodnosc.
19). Harmonogamowanie
Polega na okreslaniu dl. Realizacji kazdego z zadan oraz ich kolejnosci przy uwzglednieniu zaleznowsci pomiedzy nimi.
20). Testowanie funkcjonalne
Polega na przeprowaniedziu testow na podstawi specyfikacji systemu. Dane wej. dzielimy na grupy o wspulnej charakterystyce. Nastepnie testujemy system dla wszystkich grup danych wyj.
21). Testowanie porownawcze
Stosujemy dostepna jest wiecej niż jedna wersja systemu. TP polega na dostarczeniu tych samych danych wej. „starej” i zmodyfikowanej wersji systemu.
22). Testowanie stresowe
Stosujemy kiedy mamy do wykonania system, który musi wytrzymac wieksze obciazenia np. 100 tranzakcji/sek. Testujemy az do maksymalnego planowanego obciazenia systemu i badamy jakie
wystapily sefekty. Testujemy tez w systemach rozproszonych.
23). Model ewolucyjny
Zastosowanie: gdy nie jest możliwe okreslenie dokladnych wymagan klienta, systemy tymczasowe.
Wady: zagmatwana struktura systemu, wprowadzanie kolejnych zmian jest coraz trudniejsze, brak dokumentacji (brak mozliwosci pielegnacji systemu), systemy male (do 100tys lini kodu) lub
srednie (do 500tys lini kodu).
Zalety: szybka produkcja szybkiego systemu, klient nie musi okreslis dokladnych wymagan.
24). Model spiralny
Kazda spirala sklada się z 4-ech sektorow: 1. okreslenie celow, identyfikacja ograniczen, poszukiwanie alternatywnych rozw. 2. analiza ryzyka zwiazanego z proponowanymi rozwiazaniami,
reduksja ryzyka. 3. Po okresleniu ryzyka wybiera się najlwpsze rozwiazanie (najmniejsze ryzyko). 4.Planowanie nastepnej spirali, podjecie decyzji dotyczacej kontynulacji.
25). Montaz gotowych elem.
Polega na wykorzystaniu wczesniej uzytego kodu (moduly- procedury), który już się sprawdzil. Często się lekko modyfikuje.
26). Do prototypowanie
Polega na stworzeniu „na szybko” prototypu danego projektu w celu przedstawienia go klientowi do weryfikacji.
27). Walidacja- okteslenie cze system spelnia oczekiwania uzytkownikow.
28). Weryfikacja- sprawdzenie czy system spelnia specyfikacjie.
29). Realizacja przyrostowa- (model tradycyjny).
-realizacja systemu w skonczonej zaplanowanej liczbie krokow; -okresla się wymagania i ich piorytety; -opracowywuje się dokladna specyfikacje, projekt, nastepuje implementacja, testowanie; dostarcza się klientowi zrealizowana czesc systemu, nastepnie realizuje się kolejna funkcje. Zalety: czesty kontakt z klientem, mozliwosc wczestego wykorzystania czesci systemu. Wady:
dodatkowy koszt zwiazany z reazlizacja fragmentow systemu.