Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Model dziedziny. Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Samochód Osoba Dom Modelowanie.

Коpie: 1
Model dziedziny. Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Samochód Osoba Dom Modelowanie.

Podobne prezentacje


Prezentacja na temat: "Model dziedziny. Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Samochód Osoba Dom Modelowanie."— Zapis prezentacji:

1 Model dziedziny

2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Samochód Osoba Dom Modelowanie 2 Model dziedziny

3 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) 3 Model dziedziny

4 Alternatywa obiektowego modelu dziedziny Modele związków encji Modele ontologiczne Model dziedziny 4

5 Modelowanie dziedziny Model dziedziny odzwierciedla statyczne aspekty świata rzeczywistego Modelowanie z definicji upraszcza rzeczywistość Modeluje się tylko wybrane aspekty rzeczywistości 5 Model dziedziny Modelowanie - odwzorowywanie bytów świata rzeczywistego i powiązań między nimi w obiekty i powiązania miedzy obiektami

6 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 6 Model dziedziny

7 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 7 Model dziedziny

8 Świat rzeczywisty i jego reprezentacja 8 Model dziedziny

9 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 Model dziedziny 9

10 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 Model dziedziny 10

11 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 Model dziedziny 11

12 Model Dziedziny - diagram obiektów Model dziedziny 12 Diagram obiektów - przedstawia obiekty i powiązania miedzy nimi w określonej chwili

13 Pojęcie klasy 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 Model dziedziny 13 Klasa – jest nazwanym opisem (specyfikacją, wzorcem, definicją) obiektów mających identyczną strukturę (atrybuty, powiązania) i zachowanie

14 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 Model dziedziny 14

15 Obiekt, klasa, powiązanie, asocjacja Model dziedziny 15 obiekt = instancja (wystąpienie) klasy powiązanie = instancja (wystąpienie) asocjacji

16 Cechy asocjacji - nazwa 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 Model dziedziny 16 Nazwa - określa znaczenie (istotę) asocjacji w modelu dziedziny

17 Cechy asocjacji - role Nazwy ról umieszcza się przy każdej z klas Jako nazw ról używa się rzeczowników lub fraz rzeczownikowych Model dziedziny 17 Rola - powinność jaką pełni obiekt jednej klasy wobec obiektu innej klasy

18 Cechy asocjacji – krotność Przykłady: 1 – dokładnie – co najwyżej 1 1..* – przynajmniej 1 2, 4, 6 – konkretne wartości (2 lub 4 lub 6) * – dowolna liczba Model dziedziny 18 Krotność (liczebność, liczność) przy jednej z klas określa maksymalną i minimalną liczbę obiektów tej klasy powiązanych z jednym obiektem innej klasy

19 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 Model dziedziny 19

20 Model Dziedziny - diagram klas Model dziedziny 20 Diagram klas – przedstawia klasy oraz związki pomiędzy klasami (asocjacje)

21 Diagram obiektów i diagram klas Model dziedziny 21 Diagram obiektówDiagram klas Wizualizuje statyczne aspekty modelu dziedziny Przedstawia obiekty i powiązania obiektów istniejące w określonej chwili Jest opcjonalny - używa się w celu lepszego zrozumienia diagramu klas Wizualizuje statyczne aspekty modelu dziedziny Przedstawia klasy oraz asocjacje, które są niezależne od czasu Jest obowiązkowym elementem większości projektów UML-owych

22 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 Model dziedziny 22

23 Analiza a projektowanie Model dziedziny 23 Analiza – Zrozumienie problemu Projektowanie = propozycja rozwiązania

24 Rodzaje klas klasy konceptualne (pojęciowe) - faza analizy klasy projektowe - faza projektowania klasy implementacyjne - faza implementacji Model dziedziny 24

25 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 Model dziedziny 25

26 Techniki tworzenia modelu dziedziny Lista typowych klas Analiza dziedziny problemu Identyfikacja fraz rzeczownikowych Komentarz: Najlepsze efekty osiąga się stosując techniki mieszane Model dziedziny 26

27 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 Model dziedziny 27

28 Lista najczęściej spotykanych klas Model dziedziny 28 KategoriaPrzykład TransakcjeSprzedaż, Rezerwacja, Wynajęcie Pozycje transakcjiPozycjaSprzedaży, PozycjaZamówienia Przedmiot transakcjiProdukt, Usługa, Bilet Role odgrywane przez osobySprzedawca, Kupujący, Pracownik OrganizacjeFirma, Odział, Uczelnia Katalogi, grupyKatalogProduktów, KatalogOsób Instrumenty finansoweGotówka, Czek, KartaKredytowa OpisyOpisProduktu, OpisFilmu ZdarzeniaSprzedaż, Płatność, Seans DokumentyFaktura, Zamówienie

29 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 Model dziedziny 29

30 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 Model dziedziny 30

31 Tworzenie modelu dziedziny – uwagi (1) 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 Model dziedziny 31

32 Tworzenie modelu dziedziny – uwagi (2) 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) Model dziedziny 32

33 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 Model dziedziny 33

34 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. Model dziedziny 34

35 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. Model dziedziny 35

36 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. Model dziedziny 36

37 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 Model dziedziny 37

38 Lista kandydatów - analiza książka adresowa i książka telefoniczna w rozpatrywanym kontekście oznacz aj ą 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 Model dziedziny 38

39 Model dziedziny – książka adresowa Model dziedziny 39

40 Model dziedziny - terminarz Model dziedziny 40

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

42 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 Model dziedziny 42

43 Diagram sekwencji systemowych Model dziedziny 43 :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 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 Model dziedziny 44

45 Przykład: Książka adresowa Model dziedziny 45 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 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() Model dziedziny 46

47 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 Model dziedziny 47

48 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 Model dziedziny 48

49 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 49

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

51 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 Model dziedziny 51

52 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 Model dziedziny 52

53 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 53

54 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 gramowania Model dziedziny 54


Pobierz ppt "Model dziedziny. Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Samochód Osoba Dom Modelowanie."

Podobne prezentacje


Reklamy Google