Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej

Podobne dokumenty
Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

Świat rzeczywisty i jego model

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

Modelowanie obiektowe - Ćw. 3.

Modelowanie danych, projektowanie systemu informatycznego

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

Podstawy programowania III WYKŁAD 4

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Analiza i projektowanie obiektowe 2016/2017. Wykład 8: Przypisywanie obiektom odpowiedzialności (2)

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

BAZY DANYCH model związków encji. Opracował: dr inż. Piotr Suchomski

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

Język UML w modelowaniu systemów informatycznych

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Inżynieria oprogramowania. Część 5: UML Diagramy klas

Programowanie obiektowe

1 Projektowanie systemu informatycznego

Podejście obiektowe - podstawowe pojęcia

PRZEWODNIK PO PRZEDMIOCIE

Faza analizy (modelowania) Faza projektowania

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Wykład 1 Inżynieria Oprogramowania

Bazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Programowanie obiektowe

Wykład I. Wprowadzenie do baz danych

Modelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Paweł Kurzawa, Delfina Kongo

Diagramy czynności Na podstawie UML 2.0 Tutorial

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 1

Autor: Joanna Karwowska

Spis treúci. 1. Wprowadzenie... 13

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Faza Określania Wymagań

Procesy biznesowe w praktyce. Przykłady użycia z wykorzystaniem jbpm 4.4

problem w określonym kontekście siły istotę jego rozwiązania

Diagramy klas. dr Jarosław Skaruz

Laboratorium 02: Obiektowe modelowanie dziedziny [2h]

Wykorzystanie standardów serii ISO oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Projektowanie BAZY DANYCH

Programowanie obiektowe

Dokument Detaliczny Projektu

PODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"

Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II)

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Charakterystyka oprogramowania obiektowego

TECHNOLOGIE OBIEKTOWE. Wykład 3

Programowanie i projektowanie obiektowe

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)

PRZEWODNIK PO PRZEDMIOCIE

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

PRZEWODNIK PO PRZEDMIOCIE

UML cz. II. UML cz. II 1/38

Analiza i projektowanie aplikacji Java

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji

Tworzenie warstwy zasobów projektowanie metodą strukturalną

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

Laboratorium z przedmiotu: Inżynieria Oprogramowania INEK Instrukcja 2

Bazy danych i usługi sieciowe

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Technologie obiektowe

SCENARIUSZ LEKCJI. Streszczenie. Czas realizacji. Podstawa programowa

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Analiza i projektowanie obiektowe 2017/2018. Wykład 2: Przypadki użycia

Projektowanie logiki aplikacji

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

Inżynieria oprogramowania II

Zasady organizacji projektów informatycznych

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>

Podstawy modelowania programów Kod przedmiotu

Diagramy przypadków użycia

PRZEWODNIK PO PRZEDMIOCIE

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI

Programowanie obiektowe

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Modelowanie i Programowanie Obiektowe

Analiza procesów: notacja UML, modele przypadków użycia, Rich Picture

Modelowanie i analiza systemów informatycznych

Programowanie obiektowe. Grzegorz Jabłoński Katedra Mikroelektroniki i Technik Informatycznych (K-25) Budynek B18

Podstawy projektowania systemów komputerowych

UML w Visual Studio. Michał Ciećwierz

Lista przykładowych pytań do egzaminu z przedmiotu Inżynieria Oprogramowania

Diagram Przepływu Danych - podstawowe bloki składowe i reguły konstrukcji

Uniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013

INŻYNIERIA OPROGRAMOWANIA

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Pytania z przedmiotów kierunkowych

Inżynieria oprogramowania (Software Engineering)

Systemy informatyczne. Modelowanie danych systemów informatycznych

Etapy życia oprogramowania

Transkrypt:

Analiza i projektowanie obiektowe 2017/2018 Wykład 3: Model wiedzy dziedzinowej Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1

Plan wykładu 1. Model wiedzy dziedzinowej 2. Tworzenie modelu wiedzy dziedzinowej 2

Model wiedzy dziedzinowej 3

Wprowadzenie do modelu wiedzy dziedzinowej Model wiedzy dziedzinowej (ang. domain model) ma za zadanie wizualizację pojęć (klas konceptualnych) występujących w rozpatrywanej dziedzinie (kontekst tworzonego systemu). Najważniejszy model tworzony podczas analizy obiektowej! Praca na tym etapie polega na identyfikacji klas konceptualnych. Poprawne zbudowanie tego modelu gwarantuje sukces podczas fazy projektowania i implementacji. Model wiedzy dziedzinowej to wizualna reprezentacja klas konceptualnych lub prawdziwych obiektów występujących w świecie rzeczywistym, który modelujemy. Nie jest to reprezentacja bytów programistycznych tzn. klas i obiektów zapisanych w języku programowania. 4

Model wiedzy dziedzinowej: przykład W UML, model wiedzy dziedzinowej jest zapisywany przy pomocy diagramu klas, który opisuje: Rzeczywiste obiekty z danej dziedziny lub klasy konceptualne, Asocjacje pomiędzy klasami konceptualnymi, Atrybuty klas konceptualnych. Klasa konceptualna Asocjacja Linia Sprzedanych produktów Zawarty w ilość 1..* 1 Informuje o sprzedaży 0..1 1 Produkt * 1 Sklep Składowany w Atrybuty Zapłacone przy pomocy Sprzedaż data czas 1 1 Płatność kwota 1 Zachowana w 1 adres nazwa 1 1..* Kasa Posiada 5

Model wiedzy dziedzinowej: wizualny słownik pojęć abstrakcyjnych Model wiedzy dziedzinowej wizualizuje i łączy klasy konceptualne występujące w danej dziedzinie. Odnosi się do pewnych abstrakcji klas konceptualnych, ponieważ dane pojęcie może reprezentować różne pojęcia w zależności od rozpatrywanego kontekstu. W sposób alternatywny pojęcia zapisane przy pomocy notacji UML mogłyby być zapisywane przy pomocy tekstu w języku naturalnym, bądź słownika. Język wizualny ułatwia jednak zrozumienie opisywanych pojęć oraz jest doskonałym sposobem przekazywania wiedzy o tworzonym systemie pomiędzy członkami zespołu informatycznego. Model wiedzy dziedzinowej może być więc traktowany jako wizualny słownik istotnych elementów rozpatrywanej dziedziny. 6

Model wiedzy dziedzinowej, a model bytów programistycznych Model wiedzy dziedzinowej wizualizuje rzeczy ze świata rzeczywistego, a nie klasy zapisane w językach programowania takich jak C++, bądź Java. W modelach tego typu należy unikać: Bytów programistycznych takich jak Okno, bądź BazaDanych, Odpowiedzialności obiektów i ich metod. 7

Tworzenie modelu wiedzy dziedzinowej 8

Klasy konceptualne Klasa konceptualna to idea, rzecz lub obiekt. Klasy mogą być rozpatrywane w trzech aspektach: Symbol słowo lub element graficzny reprezentujący klasę konceptualną, Intensja definicja klasy konceptualnej, Ekstensja zbiór przykładów do których dana klasa konceptualna się stosuje. Symbol Sprzedaż data czas Intensja Sprzedaż reprezentuje zdarzenie dokonania transakcji nabycia towaru przez klienta. Posiada swoją datę i czas. sprzedaż-1 Ekstensja sprzedaż-3 sprzedaż-2 sprzedaż-4 9

Identyfikacja klas konceptualnych W procesie iteracyjnym model wiedzy dziedzinowej nie jest budowany w jednym kroku, ale etapami odpowiadającymi zakresowi prac z poszczególnych iteracji. Identyfikacja jest realizowana na bazie wyników fazy wymagań (np. na bazie przypadków użycia). Przyjmuje się, że przy identyfikacji klas konceptualnych wskazane jest ponadspecyfikowanie modelu wiedzy dziedzinowej poprzez wprowadzenie wielu (czasami zbyt wielu) bardzo szczegółowych klas konceptualnych, niż niedospecyfikowanie modelu. Częste jest pomijanie (ze względu na ich nie znalezienie) w tej fazie wielu klas konceptualnych, do ich znalezienia służą kolejne fazy służące do wprowadzenia atrybutów i asocjacji. Nie jest zalecane wykluczanie klas konceptualnych z modelu tylko dlatego, że nie pojawiają się one w wymaganiach, bądź nie posiadają atrybutów. 10

Identyfikacja klas konceptualnych: technika użycia listy kategorii (1) Obiekty fizyczne Specyfikacje, projekty lub opisy rzeczy Miejsca Transakcje Pozycje transakcji Kasa Samolot SpecyfikacjaProduktu OpisLotu Sklep Lotnisko Sprzedaż Rezerwacja ElementPozycjiSprzedaży Role ludzi Kontenery innych rzeczy Rzeczy w kontenerze Systemy informatyczne i elektrycznomechaniczne poza danym systemem Kasjer Pilot Sklep Kosz Samolot Towar Pasażer SystemAutoryzacjiPłatności SystemKontroliRuchuLotniczego 11

Identyfikacja klas konceptualnych: technika użycia listy kategorii (2) Koncepty abstrakcyjne opisywalne rzeczownikami Organizacje Zdarzenia Procesy (w większości wypadków nie są reprezentowane jako koncepty) Reguły i zasady postępowania Katalogi Wyniki czynności finansowych, efekty pracy, umów Instrumenty finansowe i usługi Podręczniki, dokumenty, książki Głód Agarofobia DziałSprzedaży LiniaLotnicza Sprzedaż, Płatność, Spotkanie Lot, Start, Lądowanie SprzedażProduktu RezerwacjaMiejsca RegułaZwrotuProduktu RegułaAnulowaniaRezerwacji KatalogProduktów KatalogCzęści Faktura, UmowaOPracę, UmowaSerwisowa LiniaKredytowa Zapasy InstrukcjaObsługi DziennaListaZmianCen 12

Identyfikacja klas konceptualnych: technika identyfikacji fraz rzeczownikowych Technika polega na identyfikacji rzeczowników i fraz rzeczownikowych w tekstowych opisach danej dziedziny i traktowaniu ich jako kandydatów na klasy konceptualne i atrybuty. Opis pełny przypadków użycia jest doskonałym opisem dziedziny na bazie którego można stosować tą technikę. Ponieważ słowa w języku są wieloznaczne i różne rzeczowniki (frazy rzeczownikowe) mogą oznaczać to samo pojęcie nie jest możliwe mechaniczne tworzenie przyporządkowań rzeczownik-klasa. Technika ta wymaga zatem dużej uwagi! Jest zalecane aby technika identyfikacji fraz rzeczownikowych była stosowana razem z techniką użycia listy kategorii. 13

Identyfikacja klas konceptualnych: przykład Obsługa Sprzedaży Zastosowanie techniki użycia listy kategorii oraz techniki identyfikacji fraz rzeczownikowych do analizy przypadku użycia Obsługa sprzedaży może doprowadzić do identyfikacji następujących kandydatów na klasy konceptualne: Kasjer Klient Manager Produkt Sprzedaż OpisProduktu Płatność Kasa KatalogProduktów Sklep ElementPozycjiSprzedaży Nie istnieje pojęcie poprawnej listy!!! Zawsze jest to zbiór arbitralnie wybranych pojęć przez analityka. Jednakże stosując te same techniki zostaną uzyskane przez różnych analityków podobne listy. Problem z uznaniem pojęć za istotne i wprowadzaniem ich do modelu na przykładzie konceptu Faktura: Przeciw: powtórzenie informacji zawartych w innych miejscach modelu, Za: potrzebne podczas ewentualnego zwracania produktu. To czy pojęcie zostanie wprowadzone, czy nie zależy od iteracji i tego czy dane pojęcie jest istotne na aktualnym etapie. 14

Tworzenie modelu wiedzy dziedzinowej: zalecane etapy Krok 1: utwórz listę kandydatów na klasy konceptualne przy użyciu techniki użycia listy kategorii oraz techniki identyfikacji fraz rzeczownikowych w oparciu o aktualnie rozpatrywaną część wymagań do systemu. Krok 2: Zapisz wyniki w diagramie. Krok 3: Dodaj asocjacje niezbędne do opisania związków pomiędzy pojęciami. Krok 4: Dodaj atrybuty niezbędne do zapisania informacji uzyskanych z analizy wymagań. 15

Tworzenie modelu wiedzy dziedzinowej: strategia użycia słownika wiedzy dziedzinowej Przy tworzeniu modelu wiedzy dziedzinowej (strategia kartografa, bądź strategia użycia słownika wiedzy dziedzinowej): Używaj słownictwa danej dziedziny w trakcie nazywania klas i atrybutów. Np. modelując bibliotekę używamy określeń Wypożyczający i Bibliotekarz na opisanie pojęć Klient i PracownikObsługiBiblioteki. Usuwaj z modelu klasy konceptualne, które są uznane za nieistotne z punktu widzenia wymagań do systemu na danym etapie jego tworzenia. Np. wyłączmy z modelu pojęcia Długopis i Reklamówka jako nieistotne z punktu widzenia wymagań do systemu. Nie wprowadzaj do modelu bytów, których nie ma w rozpatrywanej dziedzinie. 16

Tworzenie modelu wiedzy dziedzinowej: błędy przy identyfikacji klas konceptualnych Częstym błędem jest reprezentowanie bytu jako atrybutu zamiast jako klasy konceptualnej. W celu wyeliminowania tego problemu zaleca się korzystanie z reguły: Jeżeli nie myślimy o potencjalnej klasie konceptualnej X jako o liczbie bądź tekście w świecie rzeczywistym, to X jest prawdopodobnie klasą konceptualną, a nie atrybutem. W przypadku wątpliwości wprowadzamy w większości wypadków niezależną klasę konceptualną. Przykład: Sprzedaż sklep czy... Sprzedaż Sklep nrtelefonu POPRAWNE Lot portdocelowy czy... Lot Lotnisko nazwa POPRAWNE 17

Tworzenie modelu wiedzy dziedzinowej: modelowanie świata nierzeczywistego Wiele systemów informatycznych dotyczy dziedzin, które nie posiadają bezpośredniego związku ze światem rzeczywistym np. oprogramowanie tworzone w telekomunikacji. Dla takich zastosowań możliwe jest tworzenie modeli wiedzy dziedzinowej, ale wymaga to wysokiego poziomu abstrakcji i wykorzystywanie analogii z dziedzin dla których modelowanie zostało już zrealizowane. Na przykład w dziedzinie telekomunikacji można używać pojęć: Wiadomość, Połączenie, Port, Dialog, Droga, Protokół. 18

UML w tworzeniu modelu wiedzy dziedzinowej Model wiedzy dziedzinowej może zostać zapisany w oparciu o notację UML. W UML nie ma jednak pojęcia model wiedzy dziedzinowej!!! UML wprowadza jedynie język do opisywania pojęć zidentyfikowanych przez analityków w procesie tworzenia modelu wiedzy dziedzinowej w tym celu wykorzystuje się diagram klas Należy pamiętać że te sama notacja zapisu diagramów może zostać użyta do zapisu trzech różnych typów modeli: Perspektywa konceptualna diagramy reprezentują pojęcia ze świata rzeczywistego i rozpatrywanej dziedziny. Perspektywa specyfikacji diagramy są używane do opisu bytów programistycznych bez odwołań do konkretnego języka programowania, bądź technologii. Perspektywa implementacji diagramy są używane do opisywania bytów programistycznych z odwołaniem do konkretnego języka programowania, bądź technologii (np. C++). 19

UML w tworzeniu modelu wiedzy dziedzinowej: przykład Płatność kwota Zapłacone przy pomocy 1 1 Sprzedaż data czas Model wiedzy dziedzinowej Notacja UML użyta do wizualizacji konceptów (klas konceptualnych) ze świata rzeczywistego Płatność kwota: Pieniądze zwróćreszte():pieniądze Zapłacone przy pomocy 1 1 Sprzedaż data:data czasrozpoczęcia: Czas pobierzkwote: Pieniądze Projekt obiektowy Notacja UML użyta do wizualizacji konceptów bytów programistycznych (klas projektowych) 20

UML: co reprezentujemy przy pomocy symbolu klasy Klasy konceptualne: koncepty, bądź rzeczy ze świata rzeczywistego. Elementy składowe modelu wiedzy dziedzinowej. Klasy projektowe: klasy przedstawiające perspektywę specyfikacyjną, bądź implementacyjną komponentów programistycznych. Element składowy modelu projektowego. Klasy implementacyjne: klasa zapisana w konkretnym języku obiektowym (np. C++, Java). Klasa: termin ogólny w UML oznaczający, byt ze świata rzeczywistego, bądź programistycznego. 21

Zmniejszanie luki reprezentacyjnej Model wiedzy dziedzinowej dostarcza nam wizualną reprezentację słownika dziedzinowego. Z modelu tego powinniśmy czerpać inspirację przy nazywaniu bytów programistycznych podczas fazy projektowania oraz implementacji. Podejście takie pozwala na zmniejszanie luki reprezentacyjnej (luki semantycznej) pomiędzy naszym (czyli analityka) modelem mentalnym danej dziedziny, a jego reprezentacją w konkretnym rozwiązaniu informatycznym. Na poziomie modelu wiedzy dziedzinowej posługujemy się pewnymi konceptami (np. Sprzedaż), na poziomie projektowanie bytami programistycznymi (klasa Sprzedaż). Nie są te te same byty, ale drugi byt był tworzony inspirując się pierwszym. Jest to jedną z głównych zalet podejścia obiektowego!!! 22

Model wiedzy dziedzinowej: przykład (wynik fazy wstępnej) Kasjer Klient ElementPozycjiSprzedaży Manager Sklep Produkt OpisProduktu Płatność Sprzedaż KatalogProduktów Kasa 23