Projektowanie - wprowadzenie

Projektowanie - wprowadzenie Model dziedziny Projektowanie - wprowadzenie Funkcjonalność Specyfikacja wymagań Przypadki użycia Statyka Obiektowy model dziedziny Dynamika Diagram sekwencji systemowych (SSD) Kontrakty operacji

Model dziedziny Operacje Systemowe Przypadek użycia jest opisem interakcji aktora z systemem Aktor wchodzący w interakcje z system generuje pewne zdarzenia, zwane zdarzeniami systemowymi Zdarzenia systemowe skutkują wywołaniem operacji, zwanych operacjami systemowymi Operacja systemowa to operacja , którą system udostępnia na zewnątrz

Diagram sekwencji systemowych Model dziedziny Diagram sekwencji systemowych :System OperacjaSystemowa1(a, b, c) Odpowiedź systemu OperacjaSystemowa2() Diagram Sekwencji Systemowych (ang. System Sequence Diagram) przedstawia, w jaki sposób zewnętrzny aktor wchodzi w interakcje z projektowanym systemem Diagram Sekwencji Systemowych w istocie jest wizualizacją wybranego scenariusza przypadku użycia, wzbogaconą o specyfikację operacji systemowych

Identyfikacja operacji systemowych Model dziedziny Identyfikacja operacji systemowych Technika tworzenia diagramów sekwencji systemowych polega na analizie kolejnych kroków scenariusza i próbie „wydobycia” z tego opisu (oraz na podstawie modelu dziedziny) tego, co należy przesłać do systemu, aby osiągnąć rezultat opisany w przypadku użycia System traktuje się jako czarną skrzynkę – nie interesuje nas, w jaki sposób dana operacja jest realizowana w systemie, interesuje nas tylko to, jaki komunikat wysyłamy do systemu i co otrzymujemy w odpowiedzi Z reguły nie ma potrzeby tworzenia diagramów sekwencji systemowych dla wszystkich możliwych scenariuszy. Wybiera się tylko te scenariusze, które mają kluczową wartość dla projektowanego systemu

Przykład: Książka adresowa Model dziedziny Przykład: Książka adresowa UC1: Przeglądaj dane osób Scenariusz główny: 1. Użytkownik prosi system o pokazanie listy wszystkich osób 2. System prezentuje podstawowe dane wszystkich osób 3. Użytkownik wybiera jedną osobę 4. System pokazuje kompletne dane wybranej osoby UC2: Modyfikuj dane osoby Warunek wstępny: Użytkownik wybrał osobę, której dane zamierza zmienić (UC1: Przeglądaj dane osób) 1. Użytkownik prosi System o możliwość edycji danych wybranej osoby 2. System przechodzi w tryb edycji 3. Użytkownik modyfikuje dane wybranej osoby i prosi System o zatwierdzenie 4. System zatwierdza wprowadzone zmiany

Rodzaje operacji systemowych Model dziedziny Rodzaje operacji systemowych command – operacja zmienia stan systemu. Dobrą praktyką jest by tego typu operacje nie zwracały żadnych danych Przykład: ModyfikujOsobe() query – operacja nie zmienia stanu systemu. Służy do uzyskania pewnych danych z systemu. Operacje typu query zwracają dane Przykład: PobierzListeOsob(), PobierzOsobe()

Kontrakty dla operacji wg Larmana Model dziedziny Kontrakty dla operacji wg Larmana Kontrakt dla operacji jest opisem stanu systemu przed i po wykonaniu operacji systemowej Kontrakty tworzy się dla bardziej złożonych operacji systemowych Kontrakty tworzy się w oparciu o model dziedziny

Kontrakt operacji - szablon Model dziedziny Kontrakt operacji - szablon Operacja: nazwa operacji systemowej i jej argumenty Przypadki użycia: lista przypadków użycia, w których występuje operacja systemowa Warunki początkowe: stan systemu w chwili rozpoczęcia operacji systemowej Warunki końcowe: stan systemu po zakończeniu operacji systemowej

Stan systemu Stan systemu opisuje się w kategoriach: Model dziedziny Stan systemu Stan systemu opisuje się w kategoriach: istnieje..., utworzono..., usunięto obiekt x klasy X atrybutom obiektu x przypisano wartości… istnieje…, utworzono…, usunięto powiązanie pomiędzy obiektem x a y

Model dziedziny Przykład (1) Organizator: Utworzyć kontrakt dla następujących operacji systemowych: DodajWydarzenie(co, gdzie, kiedy) DodajUczestnika(idWydarzenie, idOsoba)

Przykład (2) Operacja: DodajWydarzenie(co, gdzie, kiedy) Model dziedziny Przykład (2) Operacja: DodajWydarzenie(co, gdzie, kiedy) Przypadki użycia: UC1 Dodaj wydarzenie Warunki początkowe: Istnieje instancja t klasy Terminarz Warunki końcowe: Utworzono instancje w klasy Wydarzenie Atrybutowi w.IdWydarzenie przypisano unikalna wartość Pozostałym atrybutom w przypisano wartości parametrów co, gdzie, kiedy (w.co := co, w.gdzie := gdzie, w.kiedy := kiedy) Utworzono powiązanie pomiędzy w a instancją klasy Terminarz

Przykład (3) Operacja: DodajUczestnika(idWydarzenie, idOsoba) Model dziedziny Przykład (3) Operacja: DodajUczestnika(idWydarzenie, idOsoba) Przypadki użycia: UC3 Dodaj uczestnika Warunki początkowe: istnieje instancja w klasy Wydarzenie o identyfikatorze idWydarzenie istnieje instancja o klasy Osoba o identyfikatorze idOsoba Warunki końcowe: Utworzono instancje u klasy Uczestnictwo Atrybutowi u.status przypisano wartość „niepotwierdzone” Utworzono powiązanie pomiędzy u i w Utworzono powiązanie pomiędzy u i o

Projektowanie według umowy Model dziedziny Projektowanie według umowy Kontrakty dla operacji systemowych są uproszczoną wersją koncepcji projektowania kontraktowego (inaczej: projektowanie według umowy) W projektowaniu kontraktowym oprócz warunków początkowych i końcowych definiuje się tzw. niezmienniki. Jest to rodzaj ograniczeń, które muszą być spełnione zawsze, przez wszystkie instancje klasy. Przykładowo, atrybut cena dla obiektów klasy Produkt musi zawsze być większa od zera W projektowaniu kontraktowym warunki początkowe, końcowe oraz niezmienniki można definiować zarówno dla klas jak i operacji Do formalnego zapisu warunków początkowych, końcowych oraz niezmienników służy język OCL (ang. Object Constrain Language).

Model dziedziny Literatura Craig Larman: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development Grady Booch, James Rumbaugh, Ivar Jacobson: UML Przewodnik użytkownika Kazimierz Subieta: Projektowanie systemów informatycznych – wykłady http://mediawiki.ilab.pl/index.php/Inżynieria_opro gramowania