Diagramy klas i obiektów



Podobne dokumenty
Rysunek 1: Przykłady graficznej prezentacji klas.

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

TECHNOLOGIE OBIEKTOWE. Wykład 3

UML. zastosowanie i projektowanie w języku UML

MAS dr. Inż. Mariusz Trzaska

Diagramy klas. dr Jarosław Skaruz

Modelowanie obiektowe

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

Laboratorium 6 DIAGRAM KLAS (Class Diagram)

Diagramy klas. WYKŁAD Piotr Ciskowski

Podstawy projektowania systemów komputerowych

UML w Visual Studio. Michał Ciećwierz

Język UML w modelowaniu systemów informatycznych

Diagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.

Świat rzeczywisty i jego model

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

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

Język UML w modelowaniu systemów informatycznych

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

Podstawy modelowania w języku UML

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

MAS dr. Inż. Mariusz Trzaska

Modelowanie danych, projektowanie systemu informatycznego

Język JAVA podstawy. Wykład 4, część 1. Jacek Rumiński. Politechnika Gdańska, Inżynieria Biomedyczna

Podstawy języka UML UML

Podstawy inżynierii oprogramowania

Podstawy programowania III WYKŁAD 4

Podstawy Programowania Obiektowego

Unified Modeling Language

Paweł Kurzawa, Delfina Kongo

C++ - dziedziczenie. C++ - dziedziczenie. C++ - dziedziczenie. C++ - dziedziczenie. C++ - dziedziczenie C++ - DZIEDZICZENIE.

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

MAS dr. Inż. Mariusz Trzaska. Realizacja różnych modeli dziedziczenia w obiektowych językach programowania

Projektowanie logiki aplikacji

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

UML - zarys 2007/2008

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

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

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

Język UML w modelowaniu systemów informatycznych

Marcin Luckner Politechnika Warszawska Wydział Matematyki i Nauk Informacyjnych

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Laboratorium z przedmiotu: Inżynieria Oprogramowania INP

UML a kod w C++ i Javie. Przypadki użycia. Diagramy klas. Klasy użytkowników i wykorzystywane funkcje. Związki pomiędzy przypadkami.

INŻYNIERIA OPROGRAMOWANIA. laboratorium

Programowanie współbieżne Wykład 8 Podstawy programowania obiektowego. Iwona Kochaoska

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

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

1 Projektowanie systemu informatycznego

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

Język programowania. Andrzej Bobyk

1. Które składowe klasa posiada zawsze, niezależnie od tego czy je zdefiniujemy, czy nie?

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla studentów

2. Klasy cz. 2 - Konstruktor kopiujący. Pola tworzone statycznie i dynamicznie - Funkcje zaprzyjaźnione - Składowe statyczne

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

Programowanie obiektowe - 1.

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

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

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

Podstawy języka UML UML

030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła

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

Wprowadzenie do systemów informacyjnych

Diagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

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

Faza analizy (modelowania) Faza projektowania

NIFIED M L ODELLING ANGUAGE. Diagramy czynności

Programowanie obiektowe

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

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

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.

Typy klasowe (klasy) 1. Programowanie obiektowe. 2. Założenia paradygmatu obiektowego:

Modelowanie i Programowanie Obiektowe

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

DIAGRAM KLAS. Kamila Vestergaard. materiał dydaktyczny

Analiza i projektowanie aplikacji Java

Kurs programowania. Wstęp - wykład 0. Wojciech Macyna. 22 lutego 2016

PHP 5 język obiektowy

Język UML w modelowaniu systemów informatycznych

MODELOWANIE OBIEKTOWE

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

Technologie obiektowe

Programowanie obiektowe

Programowanie obiektowe

Mechanizm dziedziczenia

Informatyka I. Dziedziczenie. Nadpisanie metod. Klasy abstrakcyjne. Wskaźnik this. Metody i pola statyczne. dr inż. Andrzej Czerepicki

MODELOWANIE OBIEKTOWE Z UML

1. Mapowanie diagramu klas na model relacyjny.

Bazy danych TERMINOLOGIA

Technologie i usługi internetowe cz. 2

Java - tablice, konstruktory, dziedziczenie i hermetyzacja

Programowanie obiektowe

Programowanie obiektowe

12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:

Tutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu.

Programowanie obiektowe

Diagram przypadków użycia

Po lewej przykłady klas. Stereotypy zostały tu wykorzystane do metaklasyfikacji metod.

Transkrypt:

Diagramy klas i obiektów zastosowanie do modelowania w języku UML Agnieszka Niegowska & Grzegorz Widziszowski

Klasy Klasa jest miejscem przechowywania cech obiektów, które są niezmienne (inwariantów). Klasa nie jest zbiorem obiektów i nie jest definicją zbioru obiektów. Stosunek klasa/podklasa oznacza, że obiekty podklasy posiadają wszystkie inwarianty nadklasy, plus swoje inwarianty. Np. klasa Student ma wszystkie inwarianty klasy Osoba, plus niektóre własne. najważniejsze inwarianty inne możliwe nazwa typ metody zdarzenia lub wyjątki lista eksportowa Ograniczenia... językowy identyfikator obiektu czyli statyczna budowa obiektu (atrybuty) operacje, które można wykonać na obiekcie mogące zajść w operacjach na obiekcie określająca, które atrybuty dostępne są z zewnątrz którym msi podlegać każdy obiekt

Diagramy klas są odmianą klasyczną diagramów encja-związek (entity-relationship) rozbudowanymi o nowe elementy dużo oznaczeń o charakterze pomocniczym (np.: notatki i ograniczenia) rodzajem diagramów klas są diagramy pakietów (package diagrams) Żadna klasa nie żyje w izolacji działa w kooperacji z innymi, aby zrealizować działanie niemożliwe do wykonania w pojedynkę Diagram klas służy do zobrazowania współpracy klas.

Zastosowanie diagramów klas zapis modelu pojęciowego reprezentują pojęcia w dziedzinie zastosowań, które aktualnie podlegają analizie sformalizowana wizja wyobrażeń powstających podczas myślenia nad problemem sformalizowana specyfikacja danych i metod dotyczy opisu zewnętrznego oprogramowania bez szczegółów implementacyjnych implementacja może bezpośrednio służyć jako graficzny środek pokazujący szczegóły implementacji

Tworzenie diagramu klas Identyfikacja klas i obiektów Identyfikacja związków pomiędzy klasami kolejność wykonywania nie jest ustalona i zależy zarówno od stylu pracy, jak i od konkretnego problemu. Identyfikacja i definiowanie pól (atrybutów) Identyfikacja i definiowanie metod i komunikatów Dobrze zbudowany diagram klas: - uwypukla jeden statyczny aspekt perspektywy projektowej systemu - obejmuje tylko byty niezbędne do zrozumienia tego aspektu - zawiera szczegóły odpowiednie do przyjętego poziomu abstrakcji, z dodatkami koniecznymi do zrozumienia tego, na czym zależy projektantowi - nie jest zbyt ogólny

Reprezentacja graficzna Klasa obrazowana jest za pomocą podzielonego na części prostokąta każda część reprezentuje inwarianty o zbliżonym przeznaczeniu + - # Nazwa_klasy atrybut1 : typ = wart_pocz1 atrybut2 : typ = wart_pocz2 atrybut3 : typ = wart_pocz3 lista atrybutów # - + operacja1(lista arg) : typ operacja2(lista arg) : typ operacja3(lista arg) : typ lista metod Na diagramie klasy dodatkowo określa się widoczność atrybutów i metod przez umieszczanie przed nimi odpowiedniego symbolu: + publiczne (public) - prywatne (private) # chronione (protected)

Dziedziczenie Obiekt pod-klasy automatycznie dziedziczy wszystkie atrybuty, metody, asocjacje i agregacje z wszystkich jej nadklas. strzałka z białym trójkątnym grotem prowadzi od pod-klasy do jej bezpośredniej nadklasy SPECJALIZACJA budowa pojęć bardziej szczegółowych, gdy mamy bardziej ogólne GENERALIZACJA budowa pojęć bardziej ogólnych, gdy mamy bardziej szczegółowe

Dziedziczenie wieloaspektowe Stosuje się specjalne oznaczenia, gdy zakresy znaczeniowe klas nie są rozłączne. Można wtedy zadeklarować aspekt według którego specjalizuje się dany obiekt oraz oznaczyć ten fakt {overlapping} pojazd lądowy środek transportu teren teren napęd napęd pojazd wodny pojazd wiatrowy pojazd silnikowy {overlapping} ciężarówka amfibia żaglówka overlapping podział nierozłączny (przecięcie zakresów znaczeniowych nie jest zbiorem pustym)

Dziedziczenie wieloaspektowe {disjoint, incomplete} drzewo dąb sosna brzoza Dodatkowo można również odnotować fakty, że: podklasy są rozłączne (disjoint) nie pokrywają całego zakresu znaczeniowego ich nadklasy (incomplete)

Dziedziczenie wielokrotne pojazd ciężar gdy klasa wywodzi się bezpośrednio od więcej niż 1 klasy... prędkość_ekspl() pojazd_lądowy ilość_kół max_prędkość... pojazd_wodny wyporność max_prędkość... amfibia Wielokrotnie dziedziczenie prowadzi do anomalii i wad koncepcji. W większości anomalie są konsekwencją faktu, że przy pomocy wielodziedziczenia próbuje się opanować koncepcję dynamicznych ról obiektu.

Ograniczenia Na diagramie klas można zawrzeć ograniczenia dotyczące klas oraz związków między nimi. * jest_członkiem * Osoba {podzbiór} Komitet 1 jest_przewodniczącym * podwładny * 0..1 szef Osoba * Pracuje_dla 0..1 pracownik pracodawca Firma {Osoba.pracodawca= Osoba.szef.pracodawca} Ograniczenie lub adnotacja

Szablony klas Niektóre języki obiektowe, wśród nich C++, wprowadzają użyteczne pojęcie klasy parametryzowanej (zwane też szablonem, template). UML wprowadza specjalne oznaczenie dla klas parametryzowanych, które może być użyte w diagramie klas. class Zbiór <T> { } void wstaw ( T nowyelement ); void usuń ( T pewienelement ); Klasa parametryzowana Zbiór Wstaw(T) Usuń(T) T Parametr (typ)

Asocjacje czyli powiązania pomiędzy obiektami klas Poniżej widoczny jest przykład specyfikacji asocjacji pomiędzy obiektami klasy Osoba i obiektami klasy Firma. Czarny trójkącik określa kierunek wyznaczony przez nazwę powiązania. firma Pracuje_dla osoba Asocjacje mają nazwy, które wyznaczają znaczenie tej asocjacji w modelu pojęciowym. Jeżeli to znaczenie jest oczywiste, wówczas nazwę asocjacji można pominąć.

Liczność oznacza, ile obiektów innej klasy może być powiązane z jednym obiektem danej klasy (para liczb oznaczająca ilość minimalną i maksymalną) Asocjacje - liczność Asocjacje mogą być wyposażone w oznaczenia liczności: A A A A A A A A A A A A A A A B B B A B : min=1, max=1 B A : min=1, max=n A 1..* B B A B : min=1, max=n B A : min=0, max=n A B 0..* B B A B : min=0, max=1 B A : min=0, max=n A B 0..* B B 1..* B 0..1

Przykład

To już połowa Tu jesteś 1 30

Asocjacje nazwy ról Asocjacje mogą być także wyposażone w dodatkowe nazwy ról (przy odpowiednich końcach). firma * Pracuje dla 1..* pracodawca pracownik osoba stanowisko zarobek szef 0..1 podwładny * Kieruje Asocjacje mogą posiadać atrybuty. W tym celu przewidziano linię przerywaną łączącą daną asocjacją z klasą, określaną jako: klasa asocjacji. Wewnątrz klasy asocjacji można zdefiniować atrybuty, operacje i inne cechy asocjacji. Klasa asocjacji może być uważana za samodzielną klasę - w szczególności podlega związkom dziedziczenia i asocjacji. Asocjacje mogą być również n-arne (oznaczenie - pusty w środku romb).

Asocjacje skierowane Na diagramach UML można zaznaczyć kierunek nawigacji wzdłuż danej asocjacji Zamówienie datazłożenia czyzapłacone sumadozapłaty Realizuj() Zamknij() 1 * PozycjaZamówienia ilość cena czyzrealizowana * 1 * 1 Klient nazwisko adres wiarygodność() produkt W takim przypadku asocjacja jest rysowana w postaci strzałki; nawigacja jest możliwa zgodnie z jej kierunkiem, ale nie odwrotnie.

Agregacje szczególny przypadek asocjacji wyrażający zależność: część całość. Oznacza się je za pomocą pustego rombu. Przykład 1 samochód jest agregatem swoich części samochód silnik Przykład 2 Klasa emerytowanych pracowników dziedziczy zarówno od klasy Emeryt, jak i od klasy Pracownik, wówczas obiekt emerytowanego pracownika zawiera jako swoją część inny obiekt grupujący informację o cechach osoby jako emeryta. Mówi się, że obiekty pracownika i emeryta pozostają w związku agregacji (emeryt jest częścią pracownika).

Kompozycja bardziej restrykcyjna agregacja dana część może należeć tylko do jednej całości Co więcej, część nie może istnieć bez całości pojawia się i jest usuwana wraz z całością. Zatem usunięcie całości powoduje automatyczne usunięcie wszystkich części związanych z nią związkiem kompozycji. zamówienie pozycja zamówienia Kompozycje oznacza się za pomocą wypełnionego rombu.

Przykład agregacja i kompozycja Każde wystąpienie obiektu Punkt należy do obiektu Wielobok albo do obiektu Okrąg - nie może należeć do dwóch obiektów naraz a usunięcie obiektu Wielobok (Okrąg) powoduje kaskadowe usunięcie wszystkich związanych z nim obiektów Punkt. 3..* Punkt 1 kompozycja kompozycja Wielobok * * Okrąg promień agregacja 1 Styl kolor czywypełniony 1 agregacja Wystąpienie obiektu Styl może być dzielone przez wiele obiektów Wielobok i Okrąg, których usunięcie nie powoduje usunięcia związanego z nimi obiektu Styl.

Różna postać zapisu kompozycji Okno PasekPrzesuwny[2]:Suwak Tytuł:Nagłówek Ciało:Panel Okno pasekprzesuwny 2 tytuł 1 ciało 1 suwak nagłówek panel Okno Okno PasekPrzesuwny:Suwak 2 2 PasekPrzesuwny Suwak Tytuł:Nagłówek 1 1 Tytuł Nagłówek Ciało:Panel 1 1 Ciało Panel

Stereotypy Idea : ustalenie meta-klasyfikacji obiektów i wprowadzenie oznaczeń graficznych a nią zgodnych Oznaczeniami są ciągi znaków wewnątrz nawiasów (np. «control object») Mogą one występować w różnych kontekstach oraz mogą być zastąpione przez specjalne ikony.(nie są określone - mogą być dowolnie wybrane) Wewnątrz diagramów klas mogą występować stereotypy klas, asocjacji i generalizacji, itd. Stereotypy są pewnymi wspólnymi nazwanymi własnościami tych bytów, dzięki czemu ich definicja może ulec uproszczeniu lub uszczegółowieniu. <<aktor>> Klient To samo znaczenie

Rodzaje stereotypów WĘZŁÓW KLAS I OBIEKTÓW zdarzenie wyjątek interfejs metaklasa udogodnienie TYPU OBIEKTÓW obiekty rzeczywiste obiekty sterujące obiekty interfejsu ZADAŃ proces wątek PAKIETÓW Przykład równoważnych oznaczeń: <<sterowanie>> Pióro świetlne lokalizacja : Punkt uruchom(tryb) <<sterowanie>> Pióro świetlne lokalizacja : Punkt uruchom(tryb) Pióro świetlne lokalizacja : Punkt uruchom(tryb) Pióro świetlne

Diagramy obiektów (Object diagram) podobne do diagramu klas, przedstawiają jednak nie klasy, tylko konkretne obiekty będące instancjami klas systemu. Z punktu widzenia notacji diagramy obiektów używają elementów zapożyczonych z diagramów klas, chociaż często używają prostszej notacji. Skupiają się na obiektach a nie na związkach pomiędzy klasami. Większość z nich używa wyłącznie obiektów i asocjacji. Diagram jest więc wizualizacją hipotetycznego stanu systemu podczas jego działania. Służy do tworzenia przykładów pomagających zrozumieć diagram klas a przede wszystkim powiązań w nim występujących.

Obiekty i asocjacje OBIEKTY są identyfikowane poprzez umieszczenie przykładowej nazwy poprzedzonej dwukropkiem : przed nazwą klasy, którą reprezentują nazwa_obiektu : nazwa_klasy nazwa_atrybutu1 = wartość_atrybutu1 nazwa_atrybutu2 = wartość_atrybutu2... nazwa_atrybutun = wartość_atrubutun ASOCJACJE oznaczane są za pomocą odcinków łączących obiekty. Na odcinkach tych dodatkowo umieszcza się nazwy asocjacji. Obiekt1 nazwa Obiekt2

Przykład diagramu obiektów Diagram reprezentuje Jasia Kowalskiego i jego ulubieńców. Jaś ma 10 lat i mieszka we Wrocławiu. Opiekuje się dwoma zwierzakami: psem-reksiem i kanarkiem-tweedym Jaś : Osoba Imie = Jaś Nazwisko = Kowalski Ile_Lat = 10 Miasto = Wrocław pod_opieką pod_opieką Tweedy : Kanarek Imie = Tweedy Kolor = żółty Reksio : Pies Imie = Reksio Ile_Lat = 5

Diagramy pakietów Pakiety są zestawami elementów modelu wraz z zachodzącymi pomiędzy nimi zależnościami. Diagramy pakietów mogą być istotne dla dużych projektów, składających się z wielu modułów funkcjonalnych ze złożonymi zależnościami pomiędzy modułami. Pakiety mogą być zagnieżdżane. Zależności pomiędzy pakietami są przedstawiane w postaci strzałki z przerywaną linią. Pakiety są traktowane jako obiekty należące do swoich klas, które mogą podlegać związkom dziedziczenia.

Diagramy pakietów edytor Pakiety są rysowane jako prostokąty z etykietą na górze. elementy diagramów graficznych sterownik Jeżeli zawartość pakietu nie jest pokazana to wówczas nazwa pakietu jest wpisana do prostokąta. elementy dziedziny zastosowań rdzeń grafiki System okienkowy rdzeń grafiki Motif Motif rdzeń grafiki Windows MS Windows

Koniec