Transcript Model
Model dziedziny 2 Model dziedziny Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Modelowanie Osoba 3 Model dziedziny Byty i obiekty • Byt - element świata rzeczywistego (dziedziny problemu), którego dotyczy system informatyczny. Może mieć charakter namacalny (rzecz) lub nienamacalny (pojęcie) • Obiekt – element modelu dziedziny, będący odwzorowaniem konkretnego bytu ze świata rzeczywistego (dziedziny problemu) 4 Model dziedziny Alternatywa obiektowego modelu dziedziny • Modele związków encji • Modele ontologiczne 5 Model dziedziny Modelowanie dziedziny Modelowanie - odwzorowywanie bytów świata rzeczywistego i powiązań między nimi w obiekty i powiązania miedzy obiektami • Model dziedziny odzwierciedla statyczne aspekty świata rzeczywistego • Modelowanie „z definicji” upraszcza rzeczywistość • Modeluje się tylko wybrane aspekty rzeczywistości 6 Model dziedziny Model a diagram • Model – pewna abstrakcja projektowanego systemu, widziana z określonej perspektywy, na określonym poziomie szczegółowości • Diagram - środek służący do opisu modelu. Dany model może być opisany przy pomocy wielu diagramów 7 Model dziedziny Model a diagram - przykład • Model przypadków użycia obejmuje: ▫ Scenariusze przypadków użycia ▫ Diagram przypadków użycia • Model dziedziny obejmuje: ▫ Diagram klas ▫ Diagram obiektów 8 Świat rzeczywisty i jego reprezentacja Model dziedziny 9 Model dziedziny Co to jest obiekt? • Obiekt reprezentuje określony byt ze świata rzeczywistego • Byt ze świata rzeczywistego może mieć wiele reprezentacji • Byty świata rzeczywistego posiadają zazwyczaj wiele cech • Obiekt odwzorowuje tylko te cechy, które mają znaczenie z punktu widzenia projektowanego systemu • Obiekt może być złożony, tzn. zawierać inny obiekt 10 Model dziedziny Formalna charakterystyka obiektu • Tożsamość – element wyróżniający dany obiekt pośród innych. W praktyce do wyróżnienia obiektu używa się identyfikatorów • Stan – zbiór wartości wszystkich cech (atrybutów) obiektu oraz powiązań między obiektami. Stan obiektu może się zmieniać • Zachowanie – zbiór wszystkich usług, jakie obiekt potrafi wykonać na rzecz innych obiektów 11 Model dziedziny Stan obiektu Atrybut – cecha (własność) obiektu, przyjmująca określoną wartość. Obiekty mogą posiadać wiele atrybutów. Wartość atrybutu opisuje bieżący stan obiektu Powiązanie - związek (fizyczny lub pojęciowy) miedzy obiektami, odwzorowywujący związek pomiędzy bytami w dziedzinie problemu 12 Model dziedziny Model Dziedziny - diagram obiektów Diagram obiektów - przedstawia obiekty i powiązania miedzy nimi w określonej chwili 13 Model dziedziny Pojęcie klasy Klasa – jest nazwanym opisem (specyfikacją, wzorcem, definicją) obiektów mających identyczną strukturę (atrybuty, powiązania) i zachowanie • Obiekt jest instancją (egzemplarzem, wystąpieniem) klasy • Klasa może posiadać wiele instancji • Klasa nie jest zbiorem obiektów • Pomiędzy klasami mogą istnieć związki 14 Model dziedziny Powiązanie a Asocjacja • Powiązanie - związek (fizyczny lub pojęciowy) miedzy obiektami, odwzorowywujący związek pomiędzy bytami w dziedzinie problemu • Asocjacja – związek między klasami wynikający z istnienia powiązań między obiektami tych klas 15 Model dziedziny Obiekt, klasa, powiązanie, asocjacja obiekt = instancja (wystąpienie) klasy powiązanie = instancja (wystąpienie) asocjacji 16 Model dziedziny Cechy asocjacji - nazwa Nazwa - określa znaczenie (istotę) asocjacji w modelu dziedziny • Może być uzupełniona o znacznik wskazujący kierunek odczytywania • Jako nazw asocjacji używa się fraz czasownikowych • Należy unikać zbyt ogólnych nazw 17 Model dziedziny Cechy asocjacji - role Rola - powinność jaką pełni obiekt jednej klasy wobec obiektu innej klasy • Nazwy ról umieszcza się przy każdej z klas • Jako nazw ról używa się rzeczowników lub fraz rzeczownikowych 18 Model dziedziny Cechy asocjacji – krotność Krotność (liczebność, liczność) przy jednej z klas określa maksymalną i minimalną liczbę obiektów tej klasy powiązanych z jednym obiektem innej klasy • Przykłady: 1 0..1 1..* 2, 4, 6 * – dokładnie 1 – co najwyżej 1 – przynajmniej 1 – konkretne wartości (2 lub 4 lub 6) – dowolna liczba 19 Model dziedziny Rodzaje asocjacji • Asocjacja binarna – asocjacja, której wystąpienia łączą 2 obiekty co najwyżej dwóch klas • Asocjacje n-arna - asocjacja, której wystąpienia łączą n obiektów co najwyżej n klas 20 Model dziedziny Model Dziedziny - diagram klas Diagram klas – przedstawia klasy oraz związki pomiędzy klasami (asocjacje) 21 Model dziedziny Diagram obiektów i diagram klas Diagram obiektów Diagram klas Wizualizuje statyczne aspekty modelu dziedziny Wizualizuje statyczne aspekty modelu dziedziny Przedstawia obiekty i powiązania obiektów istniejące w określonej chwili Przedstawia klasy oraz asocjacje, które są niezależne od czasu Jest opcjonalny - używa się w celu lepszego zrozumienia diagramu klas Jest obowiązkowym elementem większości projektów UML-owych 22 Model dziedziny Analiza a projektowanie • Analiza koncentruje się na badaniu dziedziny problemu oraz wymagań stawianych przed systemem. Wynikiem analizy jest model dziedziny problemu, który odzwierciedla ważne z punktu widzenia systemu byty świata rzeczywistego, ich najważniejsze cechy oraz zależności miedzy nimi • Projektowanie polega na szukaniu rozwiązania dla problemu, którego dotyczy system informatyczny. W wyniku otrzymujemy model projektowy, będący w istocie zbiorem powiązanych klas, wyposażonych w metody odpowiedzialne za realizacje zidentyfikowanego we wcześniejszej fazie zakresu funkcjonalności 23 Model dziedziny Analiza a projektowanie Analiza – Zrozumienie problemu Projektowanie = propozycja rozwiązania 24 Model dziedziny Rodzaje klas • klasy konceptualne (pojęciowe) - faza analizy • klasy projektowe - faza projektowania • klasy implementacyjne - faza implementacji 25 Model dziedziny Proces tworzenia modelu dziedziny 1. Identyfikacja klas konceptualnych i obiektów 2. Identyfikacja związków między klasami konceptualnymi 3. Identyfikacja atrybutów Uwaga: w modelu dziedziny nie specyfikuje się zachowania obiektów, tj. operacji 26 Techniki tworzenia modelu dziedziny Model dziedziny • Lista typowych klas • Analiza dziedziny problemu • Identyfikacja fraz rzeczownikowych Komentarz: Najlepsze efekty osiąga się stosując techniki mieszane 27 Model dziedziny Lista typowych klas • Technika opiera się na obserwacji, że w wielu systemach pojawiają się te same klasy, a problem z którym mamy do czynienia był już wielokrotnie analizowany • Lista tych najczęściej spotykanych klas jest dobrym źródłem klas w naszym systemie • Proces identyfikacji klas konceptualnych polega na przeglądaniu listy i poszukiwaniu podobnych klas w projektowanym systemie 28 Model dziedziny Lista najczęściej spotykanych klas Kategoria Przykład Transakcje Sprzedaż, Rezerwacja, Wynajęcie Pozycje transakcji PozycjaSprzedaży, PozycjaZamówienia Przedmiot transakcji Produkt, Usługa, Bilet Role odgrywane przez osoby Sprzedawca, Kupujący, Pracownik Organizacje Firma, Odział, Uczelnia Katalogi, grupy KatalogProduktów, KatalogOsób Instrumenty finansowe Gotówka, Czek, KartaKredytowa Opisy OpisProduktu, OpisFilmu Zdarzenia Sprzedaż, Płatność, Seans Dokumenty Faktura, Zamówienie 29 Model dziedziny Analiza dziedziny problemu • Technika polega na próbie odkrycia klas konceptualnych poprzez analizę wszelkiej dostępnej dokumentacji • Kandydatów na klasy konceptualne wyszukuje się w dokumentach specyfikacji systemu, przypadkach użycia • Dobre efekty uzyskuje się korzystając z wiedzy ekspertów lub wiedzy zawartej w literaturze związanej z dziedziną problemu 30 Model dziedziny Identyfikacja fraz rzeczownikowych • Technika opiera się na opisie (w języku naturalnym) dziedziny problemu sporządzonym przez eksperta posiadającego odpowiednią wiedzę • Jako potencjalne klasy konceptualne przyjmuje się rzeczowniki i frazy rzeczownikowe występujące w tekście • Ze względu na dużą niejednoznaczność języka naturalnego metoda może prowadzić do nadmiarowości 31 Tworzenie modelu dziedziny – uwagi (1) Model dziedziny • Dobre efekty daje iteracyjnie wykonywanie etapów • Kolejność wykonania może być dowolna • Warto rozpocząć analizę od próby znalezienia klasy konceptualnej, która pełni rolę nadrzędną (jeśli taka istnieje) • W modelu mogą pojawiać się klasy konceptualne, które nie posiadają atrybutów • Należy wystrzegać się klas konceptualnych reprezentujących elementy interfejsu użytkownika 32 Tworzenie modelu dziedziny – uwagi (2) Model dziedziny • Z listy potencjalnych klas konceptualnych należy wykreślić te, które w rozpatrywanym kontekście oznaczają to samo oraz te, które wydają się zbyt abstrakcyjne • Dane pojęcie z dziedziny problemu jest kandydatem na atrybut, jeśli potrafimy przydzielić mu jakiś prosty typ danych, np. liczba, tekst. Jeśli tego nie da się zrobić, jest to najprawdopodobniej klasa • Stosunkowo łatwo identyfikuje się klasy reprezentujące fizyczne przedmioty (Samochód, Piłka, Dom), znacznie trudniej zidentyfikować klasy reprezentujące pojęcia abstrakcyjne (Transakcja, Połączenie, Spotkanie) 33 Model dziedziny Przykład: Organizator • Organizator - jest aplikacją przeznaczoną do użytku osobistego lub pracy w grupie. W skład aplikacji wchodzi: ▫ Książka adresowa ▫ Terminarz ▫ Rocznice 34 Model dziedziny Przykład: Organizator (2) • Książka adresowa - służy do przechowywania danych osób, z którymi utrzymujemy kontakt. Wśród tych danych znajdują się m.in. adres domowy, adres miejsca pracy, telefony (stacjonarne, komórkowe, itp. ), adres poczty elektronicznej. 35 Model dziedziny Przykład: Organizator (3) • Terminarz - służy do przechowywania informacji o zdarzeniach. Zdarzenie informuje nas: (i) co się zdarzy, (ii) gdzie oraz (iii) kiedy. Do zdarzenia można dopisać uczestników, tj. osoby które będą brały udział w tym zdarzeniu. Aplikacja pozwala na automatyczne rozsyłanie poczty o nadchodzącym terminie spotkania. Istnieje również możliwość potwierdzania spotkania dla każdego z uczestników. 36 Model dziedziny Przykład: Organizer (4) • Terminarz c.d. - Do każdego zdarzenia można dodać alarm, który powiadomi właściciela organizera o nadchodzącym terminie spotkania. Powiadomienie może mieć charakter sygnału dźwiękowego, wywołania określonej aplikacji lub też wysłania SMS-a. Niektóre zdarzenia mogą mieć charakter cykliczny (np. w każdy czwartek). Dla wygody użytkownika aplikacja pozwala definiowanie powtarzalności dla każdego zdarzenia. 37 Model dziedziny Lista kandydatów • • • • • • • • • • • • • książka adresowa osoba kontakt imię nazwisko książka telefoniczna adres ulica numer domu adres zamieszkania adres miejsca pracy telefon stacjonarny telefon komórkowy 38 Model dziedziny Lista kandydatów - analiza • książka adresowa i książka telefoniczna w rozpatrywanym kontekście oznaczają to samo – kandydat na klasę konceptualną • osoba i kontakt – również oznaczają to samo – kandydat na klasę konceptualną • imię, nazwisko, ulica, numer domu, telefon stacjonarny, telefon komórkowy – kandydaci na atrybuty (reprezentują podstawowe typy danych – zmienne tekstowe) • adres – kandydat na klasę konceptualną - reprezentuje coś bardziej złożonego 39 Model dziedziny – książka adresowa Model dziedziny 40 Model dziedziny Model dziedziny - terminarz 41 Model dziedziny Projektowanie - wprowadzenie Funkcjonalność Statyka Specyfikacja wymagań Przypadki użycia Obiektowy model dziedziny Dynamika Diagram sekwencji systemowych (SSD) Kontrakty operacji 42 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 43 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 44 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 45 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) Scenariusz główny: 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 46 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() 47 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 48 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 49 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 50 Model dziedziny Przykład (1) Organizator: Utworzyć kontrakt dla następujących operacji systemowych: DodajWydarzenie(co, gdzie, kiedy) DodajUczestnika(idWydarzenie, idOsoba) 51 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 52 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 53 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). 54 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