Wykad 7 UML jako modelu Ryszard Myhan Poprawno

Wykład 7 UML – jakość modelu Ryszard Myhan

Poprawność modelu Ø Model (diagram) jest poprawny, jeżeli wszystkie występujące na nim pojęcia zostały użyte we właściwy sposób. Ø Wyróżnia się dwa podstawowe rodzaje poprawności: o poprawność syntaktyczną - model/diagram jest poprawny syntaktycznie, jeżeli wszystkie pojęcia zostały przedstawione w sposób zgodny z regułami składniowymi języka, przy pomocy którego wykonano jego opis; o poprawność semantyczną - model/diagram jest poprawny semantycznie, jeżeli odpowiada sytuacji z dziedziny problemowej, która jest analizowana. Modelowanie obiektowe UML – jakość modelu 2

Poprawność modelu Ø Najczęściej popełniane błędy (na przykładzie diagramu klas) naruszające poprawność diagramu, to: o użycie atrybutu zamiast klasy/asocjacji lub odwrotnie; o pominięcie generalizacji lub specjalizacji; o nieprawidłowa arność asocjacji, np. użycie asocjacji binarnej zamiast ternarnej; o użycie klasy zamiast asocjacji lub odwrotnie; o pominięcie atrybutów w asocjacjach; o pominięcie lub nieprawidłowa liczność asocjacji. Modelowanie obiektowe UML – jakość modelu 3

Poprawność identyfikacji klas (1, 2) Klasy nadmiarowe § Jeżeli dwie klasy wyrażają tę samą informację, to wówczas powinna być wybrana ta, która jest bardziej informatywna. Ä Na przykład, jeżeli dla dziedziny problemowej linii lotniczej zdefiniowano klasy Klient i Pasażer, to należy wybrać klasę Pasażer, ponieważ jej nazwa lepiej opisuje byt dziedzinowy. Klasy nierelewantne § Jeżeli klasa ma niewielki związek z rozważanym problemem, to należy ją pominąć, szczególnie w modelu o wysokim poziomie abstrakcji. Ä Na przykład, dla dziedziny problemowej szkoły, klasa Tablica może, ale nie musi, być klasą nierelewantną. Modelowanie obiektowe UML – jakość modelu 4

Poprawność identyfikacji klas (3, 4) Klasy niejednoznaczne § Nazwy klas powinny być dobrane w taki sposób, aby jednoznacznie określały ich przeznaczenie. Ä Na przykład, nazwa "podmiot obsługi" nie jest nazwą właściwą, gdyż w zależności od dziedziny problemowej i kontekstu może być interpretowana jako "klient", "bank", "pasażer", "firma" itp. Atrybuty § Jeżeli atrybut może istnieć niezależnie od obiektu, to należy rozważyć utworzenie w jego miejsce nowej klasy. Ä Na przykład, warto się zastanowić, czy nie byłoby lepiej, gdyby informacja o dzieciach pracownika została przedstawiona jako klasa połączona asocjacją z klasą Pracownik, a nie jako atrybut, np. dzieci pracownika, będący własnością tej klasy. Modelowanie obiektowe UML – jakość modelu 5

Poprawność identyfikacji klas (5, 6) Operacje § W niektórych sytuacjach może okazać się, że operację należy przedstawić w postaci klasy. Ä Na przykład, termin "rozmowa telefoniczna" może oznaczać operację, ale może równie dobrze oznaczać klasę z atrybutami takimi jak: czas, długość, taryfa itd. Klasa zamiast asocjacji § Nazwa klasy powinna wyrażać jej ogólny charakter, a nie rolę, jaką pełni w pewnym związku z inną klasą. Ä Na przykład termin "właściciel" jako określenie osoby posiadającej samochód nie jest właściwą nazwą klasy, ponieważ jest to rola, jaką osoba pełni w stosunku do samochodu. Modelowanie obiektowe UML – jakość modelu 6

Poprawność identyfikacji klas (7) Klasy odnoszące się do implementacji § Model pojęciowy nie powinien zawierać elementów projektowych (konstrukcji związanych ze środowiskiem implementacji), co oznacza, że nie należy definiować w modelu pojęciowym klas nie odnoszących się do dziedziny problemowej. Ä Na przykład, łączenie klas z dziedziny problemowej, np. Osoba, Firma, Budynek, z klasami odnoszącymi się do środowiska implementacji, np. Okno dialogowe, Moduł, Plik, Tablica, Wyjątek, Przerwanie, jest czynnością wykonywaną w fazie projektowania, gdzie i tak opisy obu światów: świata z otoczenia systemu informatycznego (czyli dziedziny problemowej) i świata wnętrza systemu, powinny znaleźć się na oddzielnych, choć wzajemnie powiązanych diagramach. Modelowanie obiektowe UML – jakość modelu 7

Poprawność identyfikacji atrybutów (1, 2) Klasa zamiast atrybutu § Jeżeli pewna własność posiada niezależne znaczenie, powinna być modelowana jako klasa - może wówczas brać udział w związkach z innymi klasami. Ä Na przykład, byt o nazwie "adres" jest raczej klasą niż atrybutem, a z kolei nazwisko i wysokość pensji są raczej atrybutami. Identyfikatory § Model obiektowy z definicji zapewnia tożsamość obiektów, dlatego nie istnieje potrzeba wprowadzania atrybutów pełniących rolę wewnętrznych identyfikatorów. Ä Niezależnie od tego, należy definiować identyfikatory, które występują explicite w dziedzinie problemowej, np. numer PESEL dla osoby. Modelowanie obiektowe UML – jakość modelu 8

Poprawność identyfikacji atrybutów (3, 4) Atrybuty wewnętrzne § Jeżeli atrybut ma charakter wewnętrzny, tzn. z definicji może być wykorzystany tylko przez niektóre operacje (a dla pozostałych operacji jest niewidoczny), to raczej należy go usunąć z modelu pojęciowego. Ä Przykładem mogą być wewnętrzne atrybuty dla metody oblicz podatek (), które przechowują podatek zapłacony w kolejnych latach. Atrybuty rozszczepiające (dyskryminatory) § Jeżeli zadaniem atrybutu jest podzielenie ekstensji danej klasy na podzbiory o (częściowo) różnej semantyce, to należy zamiast niego zdefiniować odpowiednie podklasy, czyli zastosować podział poziomy klasy. Ä Przykładem może być atrybut rodzaj pracownika z wartościami: "uczeń", "stażysta", "etatowy", "na zlecenie", "emerytowany" itd. Modelowanie obiektowe UML – jakość modelu 9

Poprawność identyfikacji atrybutów (5, 6) Atrybuty nieistotne § Należy unikać przedstawiania wszelkich nieistotnych informacji w modelu pojęciowym. Ä Przykładem może być atrybut uwagi do obiektu, który poza zapisaniem i wyświetlaniem jego wartości nie uczestniczy w żadnej istotnej operacji na obiekcie. Atrybuty asocjacji § O ile w przypadku asocjacji wiele-do-wielu zazwyczaj łatwo można rozstrzygnąć, czy dany atrybut należy wprowadzić jako atrybut asocjacji, o tyle dla asocjacji wiele-do-jednego i jeden-do-jednego może to już nie być takie oczywiste. Ä Na przykład, atrybut wysokość pensji w klasie Pracownik, gdy asocjacja pracuje pomiędzy klasami Pracownik i Firma miała liczność wiele-do-wielu, powinien być atrybutem asocjacji. Modelowanie obiektowe UML – jakość modelu 10

Poprawność identyfikacji asocjacji (1, 2) Asocjacje związane z usuwaną klasą § Zazwyczaj usunięcie z modelu klasy implikuje usunięcie wszystkich jej asocjacji. Ä Nie jest to jednak regułą, dlatego dla każdej asocjacji będącej własnością usuwanej klasy należy rozważyć, czy ta asocjacja nie powinna jednak na diagramie pozostać i być przyłączona do innej klasy. Asocjacje nierelewantne lub implementacyjne § Z modelu pojęciowego należy eliminować wszystkie te asocjacje, które nie odnoszą się do dziedziny problemowej. Modelowanie obiektowe UML – jakość modelu 11

Poprawność identyfikacji asocjacji (3, 4) Akcje (czynności, procesy) a asocjacje § Generalnie, asocjacje powinny być stosowane do opisu strukturalnych własności dziedziny problemowej, a nie aspektu działania istniejących w niej bytów. Ä Na przykład, fraza "weryfikacja klienta" opisuje w pewnej dziedzinie problemowej interakcję pomiędzy obiektem klasy Kasjer a obiektem klasy Klient, a nie związek strukturalny pomiędzy tymi obiektami. Asocjacje n-arne § Stosowanie asocjacji o arnościach większych od 2 jest sposobem na wyrażenie na etapie analizy związków zachodzących w obrębie pewnej grupy obiektów. Ä Tego rodzaju asocjacje są jednak zazwyczaj w fazie projektowania dekomponowane na asocjacje binarne, poprzez wprowadzenie klasy pośredniczącej. Modelowanie obiektowe UML – jakość modelu 12

Poprawność identyfikacji asocjacji (5, 6) Akcje pochodne § Ze względu na czytelność diagramu nie należy definiować asocjacji, które wynikają z innych asocjacji. Ä Należy jednak być ostrożnym, ponieważ niekiedy tego rodzaju wynikanie jest pozorne. Asocjacje kwalifikowane § Wartości niektórych atrybutów danej asocjacji pozwalają na dokonanie jednoznacznego podziału zbioru obiektów klasy (na pojedyncze obiekty lub grupy obiektów) powiązanych przez instancje tej asocjacji z jednym obiektem innej klasy. Ä Przykładem może być atrybut nazwa towaru, którego wartość jednoznacznie identyfikuje pewien obiekt klasy Towar w grupie innych obiektów tej klasy powiązanych z jednym obiektem klasy Zamówienie. Modelowanie obiektowe UML – jakość modelu 13

Poprawność identyfikacji asocjacji (6, 7) Dodawanie nazw ról § W pewnych sytuacjach (dla uniknięcia niejednoznaczności diagramu) dopiero opisanie końca asocjacji za pomocą nazwy roli pozwala w jednoznaczny sposób zdefiniować charakter związku. Ä Na przykład, dla asocjacji pracuje dla pomiędzy klasami Firma i Osoba warto dodać rolę pracodawca i/lub pracownik, aby uniknąć wątpliwości co do faktu, kto dla kogo pracuje. Liczność § Ponieważ liczności asocjacji są istotną częścią jej definicji, określenie liczności jest ważną czynnością wykonywaną w trakcie analizy. Ä Nie należy jednak wykonywać tej czynności już na początku tej fazy, gdyż liczności bardzo często ulegają zmianie w miarę rozwijania modelu. Modelowanie obiektowe UML – jakość modelu 14

Kompletność modelu Ø Ø Model (diagram) jest kompletny, jeżeli przedstawia wszystkie relewantne cechy (ważne z jakiegoś punktu widzenia) rozważanej dziedziny problemowej. Poniższe czynności pozwalają zazwyczaj stwierdzić, czy model/diagram jest kompletny: o Przeprowadzenie analizy wymagań użytkownika i sprawdzenie, czy wszystkie zawarte w nich pojęcia zostały wyrażone w modelu/diagramie. o Przeprowadzenie analizy pojęć zobrazowanych w modelu/diagramie i porównanie zgodności ich opisów z opisami zawartymi w wymaganiach. o Przeprowadzenie jednoczesnej analizy różnych modeli/diagramów, np. diagramu klas i diagramów dynamicznych, ze szczególnym uwzględnieniem ich wzajemnej spójności. Modelowanie obiektowe UML – jakość modelu 15

Kompletność modelu – klasy q Może okazać się, iż skonstruowany diagram klas jest niekompletny, gdyż pewne klasy nie zostały na nim umieszczone. Asymetria w asocjacjach i generalizacjach może wskazywać na brak pewnych klas. Ä Na przykład, jeżeli hierarchia dziedziczenia nie jest drzewem zrównoważonym, to należy sprawdzić, czy na pewno wszystkie klasy w ramach tej hierarchii zostały zidentyfikowane. Istnienie rozłącznych grup atrybutów i operacji wewnątrz klasy sugeruje, że warto rozważyć podział klasy na kilka klas, czyli zastosowanie podziału pionowego klasy. Zdublowane asocjacje o tej samej semantyce i strukturze sugerują, że warto utworzyć klasę bardziej ogólną i skorzystać z możliwości dziedziczenia asocjacji. Modelowanie obiektowe UML – jakość modelu 16

Kompletność modelu – klasy Jeżeli pewna klasa pełni kilka zasadniczo różnych ról, to należy rozważyć rozbicie jej na kilka klas odpowiadających tym rolom. Ä Przykładem może być klasa Książka, która z jednej strony modeluje pojedynczy egzemplarz, zaś z drugiej strony odnosi się do książki jako pozycji wydawniczej. W podejściu obiektowym operacje powinny być przypisane do klas, dlatego istnienie operacji, której nie można zastosować do obiektów żadnej z klas już istniejących, sugeruje, że należy wprowadzić dla niej nową klasę. Jeżeli pewna rola klasy zdecydowanie zmienia jej charakter, to być może należy ją przedstawić w postaci osobnej klasy. Ä Przykładem może być rola samochodu, który został wycofany z eksploatacji - przestają mieć znaczenie stare atrybuty charakteryzujące m. in. jego właściwości eksploatacyjne, a nabierają znaczenia nowe, takie jak waga metali itd. Modelowanie obiektowe UML – jakość modelu 17

Kompletność modelu – asocjacje q Aby odpowiedzieć na pytanie, czy model zawiera wszystkie potrzebne asocjacje, należy rozważyć następujące kwestie: Ścieżki dostępu do obiektów - Jeżeli wykonanie pewnych operacji nie jest możliwe ze względu na brak ścieżek dostępu do odpowiednich obiektów, to należy wprowadzić odpowiednie asocjacje modelujące te ścieżki. Brak operacji wykorzystujących daną asocjację - Jeżeli diagram zawiera asocjacje, które nie są wykorzystywane w trakcie wykonywania operacji zdefiniowanych w klasach, to oznacza iż tego rodzaju asocjacje są zbędne. Redundantna informacja w asocjacji - Ponieważ redundancja jest raczej niepożądaną własnością modelu, należy rozważyć, czy pewne informacje (pochodne) nie powinny zostać z niego usunięte. Modelowanie obiektowe UML – jakość modelu 18

Minimalność i czytelność v Model (diagram) jest minimalny, jeżeli każdy z aspektów dziedziny problemowej jest przedstawiony na schemacie dokładnie jeden raz. Innymi słowy, usunięcie dowolnego elementu z modelu/diagramu minimalnego prowadzi do utraty informacji. v Model (diagram) jest czytelny, jeżeli: § § § jego graficzna reprezentacja zawiera jak najmniejszą liczbę punktów percepcji, czyli przecięć, załamań linii; podobne elementy są tej samej wielkości; linie diagramu biegną poziomo i/lub pionowo itp. Modelowanie obiektowe UML – jakość modelu 19

Minimalność i czytelność Minimalność Czytelność Modelowanie obiektowe UML – jakość modelu 20

Samo-tłumaczenie v Model (diagram) jest samo-tłumaczący się (inaczej: samo-opisowy), jeżeli analizowana dziedzina problemowa jest przedstawiona na nim w sposób naturalny, zrozumiały i na tyle wyczerpujący, że nie są wymagane dodatkowe objaśnienia. Ä Na przykład, porównując diagram (b) z diagramem (a) widać, że zastąpienie związków asocjacyjnych generalizacją znacznie lepiej opisuje byty z dziedziny problemowej i istniejące pomiędzy nimi związki. Modelowanie obiektowe UML – jakość modelu 21

Samo-tłumaczenie v Model (diagram) jest samo-tłumaczący się także wtedy, gdy nie istnieje potrzeba stosowania innych, tzn. dodatkowych w stosunku do użytej notacji, formalizmów (np. opisów słownych) w celu reprezentowania cech analizowanego obszaru. Ä Przykładowo: diagram (b) informuje bezpośrednio, w jaki sposób lekarz może pomagać pacjentowi, podczas gdy z diagramu (a) wiadomo tylko ogólnie, że lekarze mogą pełnić różne role, ale nie wiadomo jakie. Modelowanie obiektowe UML – jakość modelu 22

Podatność na modyfikacje i podsumowanie v Model (diagram) jest podatny na modyfikacje, jeżeli zmiana wymagań użytkownika wymaga wprowadzenia do modelu/diagramu tylko niewielkich (bądź żadnych) zmian. Podsumowanie § § § W praktyce rzadko udaje się wypracować dostatecznie rygorystyczne reguły postępowania, które prowadziłyby skutecznie do celu, czyli do zdefiniowania modelu o zadowalającej jakości. Liczba sytuacji, z którymi mają do czynienia analitycy i projektanci jest ogromna i zawsze będą istnieć takie, dla których przestrzeganie omówionych zaleceń nie jest wystarczające. Należy dążyć przede wszystkim do tego, by model był spójny i odzwierciedlał rzeczywiste wymagania klienta. Modelowanie obiektowe UML – jakość modelu 23