Model dziedziny

Świat rzeczywisty i jego model Model dziedziny Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Świat obiektów – pewna abstrakcja świata rzeczywistego Inne nazwy modelu dziedziny problemu: - Model konceptualny - Model wiedzy dziedzinowej - Model dziedziny biznesowej Samochód Osoba Modelowanie

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)

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

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

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

Model a diagram - przykład 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

Świat rzeczywisty i jego reprezentacja Model dziedziny Świat rzeczywisty i jego reprezentacja

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

Formalna charakterystyka obiektu 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 W fazie analizy znaczenie ma jedynie tożsamość obiektu oraz stan – czyli zestaw atrybutów i ich wartości Zachowania obiektów zazwyczaj nie modeluje się w fazie analizy

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

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

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

Powiązanie a Asocjacja 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 W wielu opracowaniach używa się terminologii: powiązanie (związek między klasami), wystąpienie powiązania (związek między obiektami) W literaturze angielskjęzycznej na oznaczenia związku między klasami używa się terminu „association”, a na oznaczenie związku między obiektami – „link”

Obiekt, klasa, powiązanie, asocjacja Model dziedziny Obiekt, klasa, powiązanie, asocjacja obiekt = instancja (wystąpienie) klasy powiązanie = instancja (wystąpienie) asocjacji 1. Wiele pojęć UML-owych definiuje się na podobnej zasadzie. Oprócz powyższych wymienić można: Przypadek użycia <–> wystąpienie przypadku użycia (konkretny ciąg akcji , który zostanie wykonany) Aktor <–> wystąpienie aktora (np. aktor: Klient, wystąpienie aktora: Jan Kowalski) 2. Rozróżnianie pojęć klasy i obiektu jest kluczowe dla właściwego zrozumienia filozofii obiektowej. Rozróżnianie pojęć asocjacji i wystąpienia asocjacji (powiązania) już tak ważne nie jest. W wielu opracowaniach używa się terminu powiązanie zamiennie z asocjacją na oznaczenie zarówno związku pomiędzy klasami jak i pomiędzy obiektami. Nie jest to zbyt rażący błąd.

Cechy asocjacji - nazwa 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

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

Cechy asocjacji – krotność 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 – dokładnie 1 0..1 – co najwyżej 1 1..* – przynajmniej 1 2, 4, 6 – konkretne wartości (2 lub 4 lub 6) * – dowolna liczba W zastosowaniach praktycznych najczęściej pojawiają się krotności 0, 1 i *.

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 Określenie „co najwyżej” pojawia się dlatego, że może być np. asocjacja binarna łącząca obiekty tej samej klasy – mamy 2 obiekty, ale jedną klasę. Tego typu asocjacje nazywa binarną rekursywną.

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

Diagram obiektów i diagram klas Model dziedziny Diagram obiektów i diagram klas Diagram obiektów Diagram 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

Analiza a projektowanie 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

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

Rodzaje klas klasy konceptualne (pojęciowe) - faza analizy Model dziedziny Rodzaje klas klasy konceptualne (pojęciowe) - faza analizy klasy projektowe - faza projektowania klasy implementacyjne - faza implementacji Powyższy podział wywodzi się z metodyki RUP

Proces tworzenia modelu dziedziny Model dziedziny Proces tworzenia modelu dziedziny Identyfikacja klas konceptualnych i obiektów Identyfikacja związków między klasami konceptualnymi Identyfikacja atrybutów Uwaga: w modelu dziedziny nie specyfikuje się zachowania obiektów, tj. operacji

Techniki tworzenia modelu dziedziny Model dziedziny 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 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

Lista najczęściej spotykanych klas 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

Analiza dziedziny problemu 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

Identyfikacja fraz rzeczownikowych 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

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

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

Przykład: Organizator 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 Do identyfikacji klas z przykładu nie jest potrzebna specjalistyczna wiedza dziedzinowa

Przykład: Organizator (2) 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.

Przykład: Organizator (3) 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.

Przykład: Organizer (4) 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.

Lista kandydatów książka adresowa osoba kontakt imię nazwisko 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

Lista kandydatów - analiza 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

Model dziedziny – książka adresowa

Model dziedziny - terminarz

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