8 UML

UML dr inż. Rafał Deja

DLACZEGO ANALIZA I PROGRAMOWANIE OBIEKTOWE?

Dlaczego? Poznanie składni języka nie jest wystarczające, aby skutecznie programować przy pomocy języków zorientowanych obiektowo (C++, Java, C#) - „Posiadanie młotka nie czyni z nas od razu architekta”.  Programowanie w tych językach staje się efektywne w przypadku poprawnego „myślenia obiektowego”. Stąd konieczne jest przed przystąpieniem do programowania przeprowadzenie analizy i projektowania obiektowego (object-oriented analysis and design –OOA/D).  Krytyczną podstawową umiejętnością OOA/D jest umiejętność przypisywania odpowiedzialności (ang. Responsability) poszczególnym obiektom, rozstrzyganie w jaki sposób obiekty powinny pozostawać w interakcji między sobą, określanie co poszczególne klasy powinny realizować.  Zasady analizy i projektowania obiektowego dają się zapisać w postaci zestawu reguł oraz heurystyk. 

Programowanie obiektowe zalety - przypomnienie

Modelowanie świata rzeczywistego Programowanie zorientowane obiektowo polega na zbudowaniu w programie modeli obiektów ze świata rzeczywistego. Praca programisty polega na ożywieniu tych obiektów oraz sprawieniu aby zaczęły ze sobą współpracować.  Powtórne użycie kodu (ang. reusablity) Kod raz zapisany może zostać wykorzystany wielokrotnie. Realizowane jest to dzięki dziedziczeniu (metody z nadklasy są dostępne w klasach pochodnych).  Rozszerzalność (ang. extensibility) Dzięki polimorfizmowi wprowadzenie nowych klas nie wymaga modyfikowania fragmentów kodu już raz zapisanego. Metody polimorficzne są odpowiedzialne za wykonywanie czynności związanych z daną klasą. W przypadku wprowadzenia nowych klas wprowadzone zostaną odpowiednie metody polimorficzne. 

Programowanie obiektowe zalety – przypomnienie (c.d.)

Większa skuteczność w wykrywaniu błędów Dziki związaniu metod z obiektami nie są możliwe błędy niepoprawnego wywołania funkcji z nieuprawnionymi argumentami (metody operuj na danych zwianych z obiektem). Minimalizowana jest więc ilość błędów niepoprawnego użycia funkcji.  Prostota w programowaniu interfejsów użytkownika Programowanie zorientowane obiektowo wprost odpowiada potrzebom tworzenia „okienkowych” interfejsów użytkownika. Okna mogą być postrzegane jako obiekty, składające się z innych obiektów (przyciski, elementy menu, itd.). 

Analiza obiektowa Celem analizy obiektowej (object-oriented analysis) jest udzielenie odpowiedzi na pytanie: jak system ma działać?  Zadania realizowane podczas analizy: 

◦ utworzenie logicznego modelu systemu opisującego sposób realizacji przez system postawionych wymagań (model logiczny pomija większość szczegółów implementacyjnych), ◦ określenie podstawowego „słownika” wiedzy dziedzinowej w celu ułatwienia analizy i następnie konstruowania aplikacji.

Realizowane jest to poprzez znalezienie i opisanie obiektów – rozumianych jako koncepty – w rozpatrywanej dziedzinie.  Tworzone modele zapisywane są przy pomocy notacji definiowanych w językach modelowania (np. UML). 

Projektowanie obiektowe Celem projektowania obiektowego jest udzielenie odpowiedzi na pytanie: jak system ma zostać zaimplementowany?  Zadania realizowane podczas projektowania: 

◦ opracowanie szczegółowego opisu implementacji systemu, ◦ zdefiniowanie obiektów wykorzystywanych w programie.

Realizowane jest to poprzez określenie zasad współpracy obiektów w taki sposób aby zrealizowane były wymagania (określenie atrybutów, metod, itd.).  Struktura tworzonego oprogramowania powinna jak najbardziej zachowywać ogólną strukturę modelu stworzonego w poprzedniej fazie.  W fazie projektowania wykorzystuje się tę samą notację, co w fazie analizy. 

Programowanie obiektowe 

Implementacja (kodowanie) projektu oprogramowania w wybranym środowisku implementacyjnym: ◦ ◦ ◦ ◦



wykorzystanie języka obiektowego, powtórne użycie już istniejących bibliotek obiektowych, wykorzystanie narzędzi szybkiego wytwarzania aplikacji, wykorzystanie generatorów kodu.

Podjęcie kroków mających doprowadzić do wytworzenia niezawodnego oprogramowania: ◦ unikanie niebezpiecznych technik, ◦ zasada ograniczonego dostępu, ◦ stosowanie kompilatorów sprawdzających zgodność typów.

MODELOWANIE

Modelowanie 

Co to jest model? ◦ Model to pewne uproszczenie rzeczywistości.



Dlaczego modelujemy? ◦ Konstruujemy modele, aby lepiej zrozumieć system, który tworzymy.



W czym nam pomaga modelowanie: ◦ w wizualizacji systemu takim jakim jest, bądź takim jakim powinien być, ◦ w specyfikacji struktury lub zachowania systemu, ◦ służy jako wzorzec podczas konstruowania aplikacji, ◦ dokumentuje wyniki prowadzonych prac.



Dlaczego potrzebujemy modeli formalnych (sformalizowanych)? ◦ Zunifikowany język ułatwia komunikację oraz pozwala opisywać tworzony model w jednorodny sposób.

Dlaczego modelować systemy 

Dobre modele są niezbędne: ◦ Aby skomplikowane systemy były bardziej zrozumiałe ◦ Przedstawić graficznie najważniejsze elementy systemu ◦ Dla komunikacji między członkami zespołu projektowego ◦ Dla zapewnienia poprawnej architektury rozwiązania

Dlaczego wiele modeli Nie jesteśmy w stanie objąć, zrozumieć skomplikowanego systemu w całości pojedynczy model jest niewystarczający  Wymagane jest spojrzenie na system z różnych perspektyw 

◦ Różne modele muszą być od siebie niezależne ◦ Każdy model musi istnieć na innym poziomie szczegółowości

Czym jest UML wg OMG 

„The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components."

Czym jest UML 

Język modelowania

◦ Specyfikacja, konstrukcja, wizualizacja i dokumentacja elementów systemu informatycznego ◦ Obejmuje różne aspekty SI (różne modele) ◦ Służy wymianie informacji

Dostarcza użytkownikom informacji o koncepcji rozwiązania  Dostarcza formalne podstawy rozumienia modelu  Wspomaga tworzenie oprogramowania  Integruje najlepsze praktyki 

Czym nie jest UML 

Metodyką ◦ UML nie określa metody modelowania ◦ zaleca jedynie stosowanie podejścia przyrostowego



Narzędziem ◦ UML to specyfikacja dla narzędzi

Historia obiektowych metod analizy

Twórcy UML

UML UML definiuje dwie podstawowe składowe: notację poszczególnych elementów używanych na diagramach, a z drugiej strony – ich semantykę, czyli tzw. metamodel.  Z punktu widzenia analityka istotniejsze jest czytelne i jednoznaczne opisanie modelu tak, aby inne osoby mogły zrozumieć jego znaczenie. Ważniejsza dla niego jest notacja; Metamodel powinien być zrozumiały intuicyjnie.  Przy generowaniu kodu i przejściu do implementacji ważniejsze jest ścisłe rozumienie znaczenia poszczególnych elementów, tak, aby możliwa była automatyczna konwersja modelu do innego formalizmu. 

Widoki (perspektywy UML) 









Perspektywa przypadków użycia – opisuje funkcjonalność, jaką powinien dostarczać system, widzianą przez jego użytkowników. Perspektywa logiczna – zawiera sposób realizacji funkcjonalności, strukturę systemu widzianą przez projektanta Perspektywa implementacyjna – opisuje poszczególne moduły i ich interfejsy wraz z zależnościami; perspektywa ta jest przeznaczona dla programisty Perspektywa procesowa – zawiera podział systemu na procesy (czynności) i procesory (jednostki wykonawcze); opisuje właściwości niefunkcjonalne systemu i służy programistom i integratorom Perspektywa wdrożenia – definiuje fizyczny podział elementów systemu i ich rozmieszczenie w infrastrukturze; perspektywa taka służy integratorom i instalatorom systemu

Diagramy UML UML obejmuje 13 rodzajów diagramów:  Modelowanie strukturalne ◦ ◦ ◦ ◦ ◦ 

diagram pakietów diagram klas i diagram obiektów diagram struktur złożonych diagram komponentów diagram wdrożenia

Modelowanie behavioralne ◦ ◦ ◦ ◦ ◦

diagram przypadków użycia diagram czynności diagram maszyny stanowej diagramy interakcji (sekwencji, komunikacji, przeglądu interakcji) diagram uwarunkowań czasowych

Model wymagań 

Model przypadków użycia wykorzystuje dwa podstawowe pojęcia: ◦ Aktor - reprezentuje rolę, którą może grać w sytemie jakiś jego użytkownik; (np. kierownik, urzędnik, klient) ◦ Przypadek użycia - reprezentuje sekwencję operacji, niezbędnych do wykonania zadania zleconego przez aktora, np. potwierdzenie pisma, złożenie zamówienia, itp.

Notacja wypłata pieniędzy

Przypadek użycia: Powinien mieć unikalną nazwę, opisującą przypadek użycia z punktu widzenia jego zasadniczych celów. Czy lepiej jest stosować nazwę opisującą czynność (“wypłata pieniędzy”) czy polecenie (“wypłać pieniądze”) - zdania są podzielone. Aktor: Powinien mieć unikalną nazwę.

klient

Interakcja: Pokazuje interakcję pomiędzy przypadkiem użycia a aktorem.

weryfikacja klienta

Blok ponownego użycia: Pokazuje fragment systemu, który jest używany przez kilka przypadków użycia; może być oznaczony jako samodzielny przypadek użycia.

«include»

Relacja typu «include» lub «extend»: Pokazuje związek zachodzący między dwoma przypadkami użycia lub przypadkiem użycia a blokiem ponownego użycia.

System obsługi klienta wnętrze systemu

Nazwa systemu wraz z otoczeniem systemu: Pokazuje granicę pomiędzy systemem a jego otoczeniem.

Przykład diagramu przypadków użycia otoczenie systemu

Automat do sprzedaży papierosów

wnętrze systemu

uzupełnienie towaru

zakup paczki papierosów

wykonanie operacji pieniężnej

klient

operator

sporządzenie raportu

granica systemu

kontroler

Relacje między przypadkami użycia 





Przypadki użycia mogą być konstruowane w dowolnej kolejności, chyba że występują między nimi relacje typu «include» czy «extend». W obu poniższych diagramach P1, nazywane przypadkiem bazowym, zawsze występuje jako pierwsze w kolejności działania. Przebieg podstawowy (sekwencyjny): P1 zawsze włącza (używa) P2, zwane tu przypadkiem włączanym. P1

«include» P2

Relacje między przypadkami użycia 

Przebieg opcjonalny (alternatywny): P1 jest czasami rozszerzane o P2 zwane tu przypadkiem rozszerzającym (inaczej: P2 czasami rozszerza P1). Sformułowanie “czasami” oznacza, że warunek na wywołanie P2 musi być spełniony, aby P2 zostało wywołane z P1. O ile warunek nie został wyspecyfikowany, co jest dopuszczalne, P2 będzie wywołane zawsze. «extend» P1

P2

Przykład relacji <> Automat do operacji bankowych

podsystem zarządzania bazą danych banku

obsługa konta klienta

«include»

informowanie o stanie konta klienta

«include»

klient

inicjalizacja karty klienta administrator systemu

«include»

weryfikacja karty i kodu klienta

Relacje: «include» i «extend» rejestracja klienta

«include» «include»

«include» przegląd samochodu

«extend»

«extend» umycie samochodu

sprzedaż samochodu

naprawa samochodu

«extend» przyholowanie samochodu

«include»: wskazuje na wspólny fragment wielu przypadków użycia (wyłączony “przed nawias”); wykorzystywane w przebiegach podstawowych (operacje zawsze wykonywane)

«extend»: strzałka prowadzi od przypadku użycia, który czasami rozszerza inny przypadek użycia wykorzystywane w przebiegach opcjonalnych (operacje nie zawsze wykonywane)

Rozbudowany przykład

Pokazują przebieg przepływu informacji w systemie. Można odzwierciedlić wiele ścieżek często wykonywanych równolegle.

ACTIVITY DIAGRAM

Activity diagram

Diagramy interakcji Diagramy interakcji w UML opisują komunikację między obiektami.  Rodzaje diagramów interakcji w UML: 

◦ ◦ ◦ ◦

diagram sekwencji diagram komunikacji (UML 2.0) diagram przeglądu interakcji diagram uwarunkowań czasowych

Diagram komunikacji przedstawia sposób wymiany komunikatów pomiędzy obiektami uczestniczącymi w interakcji. Jest rozszerzoną wersją diagramu współdziałania.

DIAGRAM KOMUNIKACJI

Stereotypy analityczne

UML dostarcza 3 stereotypów dla klas używanych podczas analizy:  Terminator – modeluje interakcję pomiędzy aktorem a systemem  Sterowanie – prowadzi obliczenia, koordynację, nadzoruje transakcje i przebieg sekwencji Unregistered Trial 5 Unregistered Trial Version encje biznesowe, najczęściej o  Encja – Version modeluje charakterze trwałym (zapisanym w bazie danych) Unregistered Trial Version 5 Unregistered Trial Version 

sd Use Cas...

sd Use Cas...

sd Use Cas...

Unregistered Trial Version 5 Unregistered Trial Version

Unregistered Trial Version 5 Unregistered Trial Version Terminator

Unregistered Trial Version 5 Unregistered Trial Version

Control

SQL

Stereotypy analityczne

5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistere

5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistere

Wizualna reprezentacja stereotypów analitycznych stosowana ze Unregistere 5 Unregistered Trial Version jest EA 7.5najczęściej Unregistered Trial Version EA 7.5 względu na przejrzystość 5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistere  Można stosować reprezentacje opisowe 5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistere

 5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistere

sd Use Case Model

5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistere

1.2: status wyszukaj 1: wypożycz 5 Unregistered Trial Version EA 7.51.1:Unregistered Trial Version EA 7.5 Unregistere 1.3: wypożycz

Katalog

Książka

5 UnregisteredCzytelnik Trial VersionBibliotekarz EA 7.5 Unregistered Trial Version EA 7.5 Unregistere

5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistere

5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistere

Diagram sekwencji przedstawia sposób wymiany komunikatów pomiędzy obiektami z zachowaniem ich kolejności

DIAGRAM SEKWENCJI (SEQUENCE DIAGRAM)

Diagram interakcji dla przypadku użycia Aktor

Obiekt 1

Obiekt 2

Obiekt 3

Obiekt 4

k1

k2 czas

k3 k4

k5

ki - komunikat, czyli polecenie wykonania operacji; komunikat nosi nazwę tej operacji

Rodzaje komunikatów Komunikat to forma kontaktu pomiędzy obiektami, której efektem ma być podjęcie przez docelowy obiekt pewnej akcji. Otrzymanie komunikatu przez obiekt wiąże się z wykonaniem przez niego jego własnego kodu lub wysłaniem kolejnego komunikatu do innego obiektu w celu wykonania przez niego pewnej akcji.  Komunikaty w UML są reprezentowane przez strzałki łączące linie życia poszczególnych obiektów. Każdy komunikat wewnątrz interakcji opatrzony jest kolejnym numerem, co pozwala na łatwe śledzenie jej przebiegu.  Istnieją trzy podstawowe komunikaty, jakie mogą zostać wymienione pomiędzy obiektami: wywołanie procedury, powrót z niej oraz wywołanie asynchroniczne. 

wywołanie procedury powrót z wywołania wyw. asynchroniczne

Blok  

Blok definiuje grupę komunikatów wspólnie posiadającą pewną właściwość. Wskazuje specjalną własność pewnej części interakcji, np. oznaczenie sekcji krytycznej czy pętli. Taką grupę operacji obejmuje się prostokątem, w którego lewym górnym narożniku, w pięciokącie umieszcza się słowo kluczowe lub opis określający znaczenie danego bloku (tzw. operator interakcji), np.: ◦ alt (od alternative) – określający warunek wykonania bloku operacji, odpowiadający instrukcji if-else; warunek umieszcza się wówczas wewnątrz bloku w nawiasach kwadratowych ◦ opt (od optional) – reprezentujący instrukcję if (bez else) ◦ par (od parallel) – nakazujący wykonać operacje równolegle ◦ critical – oznaczający obszar krytyczny ◦ loop – definiujący pętlę typu for (o określonej z góry liczbie iteracji) lub while (wykonywanej dopóki pewien warunek jest prawdziwy)

Blok

Przykłady diagramu sekwencji

Diagram uwarunkowań czasowych koncentruje się na zależnościach czasowych w interakcji pomiędzy grupą obiektów

DIAGRAM UWARUNKOWAŃ CZASOWYCH

Diagram uwarunkowań czasowych

Diagram uwarunkowań czasowych Diagramy uwarunkowań czasowych (ang. timing diagrams) są specjalną formą diagramów interakcji przeznaczoną niemal wyłącznie do prezentowania zależności związanych z czasem wykonywania operacji przez obiekt lub grupę obiektów. Linia czasu jest reprezentowana przez poziomą oś diagramu, natomiast oś pionowa przedstawia kolejne obiekty uczestniczące w interakcji oraz ich zmieniające się stany wewnętrzne.  Odległości pomiędzy momentami zmian stanów wyznaczają uwarunkowania czasowe.  Diagram ten ma duże znaczenie w modelowaniu systemów czasu rzeczywistego. 

MODELE STATYCZNE

Diagram klas Diagram klas przedstawia klasy występujące w systemie i statyczne relacje pomiędzy nimi wraz z ograniczeniami.  Jest podstawowym diagramem struktury logicznej systemu. 

Klasa 

Opisane przez: ◦ Nazwę ◦ Atrybuty ◦ Zachowanie

Opis klasy 

UML definiuje 4 poziomy widoczności cech i metod ◦ + publiczny – element jest widoczny z każdego miejsca w systemie ◦ # chroniony – element jest widoczny we własnej klasie i jej podklasach ◦ – prywatny – element jest widoczny tylko we własnej klasie ◦ ~ publiczny wewnątrz pakietu – element jest widoczny tylko wewnątrz własnego pakietu

Krotność Krotność pozwala określić minimalną i maksymalną liczbę obiektów, jakie można powiązać z daną cechą:  przedział od-do 

◦ ◦ ◦ ◦ ◦

1 – dokładnie jeden obiekt 0..1 – opcjonalnie jeden obiekt 1..* - przynajmniej jeden obiekt 1, 3, 5 – konkretne liczby obiektów * - dowolna liczba obiektów

Właściwości i ograniczenia atrybutów 

Z atrybutem mogą być związane dodatkowe ograniczenia, które określają jego właściwości, np.: ◦ {ordered} – obiekty wewnątrz cechy są uporządkowane ◦ {unordered} – obiekty są nieuporządkowane ◦ {unique} – obiekty wewnątrz cechy nie powtarzają się ◦ {nonunique} – obiekty wewnątrz cechy mogą się powtarzać ◦ {readOnly} – wartość atrybutu służy tylko do odczytu ◦ {frozen} – wartość atrybutu nie może być zmodyfikowana po jej przypisaniu

Zależności między klasami 

Zależności są najprostszym i najsłabszym rodzajem relacji łączących klasy. Oznaczają, że zmiana jednej z nich w pewien sposób wpływa na drugą, np. ◦ «call» - operacje w klasie A wywołują operacje w klasie B ◦ «create» - klasa A tworzy instancje klasy B ◦ «instantiate» - obiekt A jest instancją klasy B ◦ «use» - do zaimplementowania klasy A wymagana jest klasa B

Asocjacja Asocjacja reprezentuje czasowe powiązanie pomiędzy obiektami dwóch klas. Obiekty związane asocjacją są od siebie niezależne.  Asocjacja jest też używana jako alternatywny (obok atrybutu) i równorzędny sposób zapisu cech klasy. 

Nawigowalność asocjacji 

Nawigowalność określa wiedzę o sobie nawzajem obiektów uczestniczących w relacji.

Agregacja i kompozycja Agregacja reprezentuje relację typu całość-część, w której część może należeć do kilku całości, a całość nie zarządza czasem istnienia części. Kompozycja jest relacją typu całość-część, w której całość jest wyłącznym właścicielem części, tworzy je i zarządza nimi.

Klasa asocjacyjna Klasy asocjacyjne są związane z relacją asocjacji i opisują jej właściwości.  Mają dostęp do innych obiektów uczestniczących w relacji 

Asocjacja kwalifikowana 

Asocjacja kwalifikowana pozwala wskazać, który atrybut jednej z klas służy do zapewnienia unikatowości związku (jest jego kwalifikatorem).

Uogólnienie 

Uogólnienie tworzy hierarchię klas, od ogólnych do bardziej szczegółowych. Pozwala wyłączyć części wspólne klas.

Realizacja

Interfejsy i klasy abstrakcyjne Klasa abstrakcyjna deklaruje wspólną funkcjonalność grupy klas. Nie może posiadać obiektów i musi definiować podklasy.  Interfejs deklaruje grupę operacji bez podawania ich implementacji. 

Szablony klas Szablon klasy określa, z jakimi innymi klasami (nie obiektami!) może współpracować EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version podana klasa. Klasy te są przekazywane jako EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version jej parametry.  Klasa będąca uszczegółowieniem takiejTrial klasy EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Version jest klasą związaną. EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version  W C++ Teamplate w C# Generics 

EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version class Class Model EA 7.5 Unregistered Trial Version EALista 7.5 List<> Unregistered Trial Version ListaTow arów

+ +

Add(T) : void Length() : void

EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version



EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version

MODLE DZIEDZINY (DOMAIN MODEL)

Model dziedziny (domain model) 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. 

Model analityczny 

W UML model analityczny (domain model) jest reprezentowany przez zbiór diagramów obiektów. Pokazuje: ◦ Obiekty dziedziny lub klasy koncepcyjne ◦ Połączenie między obiektami ◦ Atrybuty

Model analityczny

Model wiedzy dziedzinowej 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. 

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++, czy Java.  W modelach tego typu należy unikać bytów programistycznych takich jak Okno, BazaDanych, i specyfikowania ich metod. 

TWORZENIE MODELU WIEDZY DZIEDZINOWEJ

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, (np. Sprzedaż - reprezentuje zdarzenie dokonania transakcji nabycia towaru przez klienta. Posiada swoją datę i czas.)

◦ Ekstensja – zbiór przykładów, do których dana klasa konceptualna się stosuje.

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 ponad specyfikowanie modelu wiedzy dziedzinowej poprzez wprowadzenie wielu (czasami zbyt wielu) bardzo szczegółowych klas konceptualnych, niż nie dospecyfikowanie modelu. Częste jest pomijanie (ze względu na ich nieznalezienie) w tej fazie wielu klas konceptualnych, (w ich odkryciu pomogą 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.

Technika użycia listy kategorii Table 10.1. Conceptual Class Category List. Conceptual Class Category Examples physical or tangible objects Register Airplane specifications, designs, or descriptions of ProductSpecification things FlightDescription Places Store Airport transactions Sale, Payment Reservation transaction line items SalesLineItem roles of people Cashier Pilot containers of other things Store, Bin Airplane things in a container Item

Conceptual Class Category other computer or electro-mechanical systems external to the system abstract noun concepts organizations

events processes (often not represented as a concept, but may be) rules and policies catalogs records of finance, work, contracts, legal matters financial instruments and services manuals, documents, reference papers, books

Examples CreditPaymentAuthorizationSystem AirTrafficControl Hunger Acrophobia SalesDepartment ObjectAirline Sale, Payment, Meeting Flight, Crash, Landing SellingAProduct BookingASeat RefundPolicy CancellationPolicy ProductCatalog PartsCatalog Receipt, Ledger, EmploymentContract MaintenanceLog LineOfCredit Stock DailyPriceChangeList RepairManual

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. 

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.

Tworzenie modelu wiedzy dziedzinowej: zalecane etapy 

  

Krok 1: utwórz listę kandydatów na klasy konceptualne przy użyciu techniki 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ń.

Analiza CRC (class responsibility & collaboration) 

Cele: ◦ Znalezienie najważniejszych klas (występujących w większości przypadków użycia) ◦ Określenie odpowiedzialności każdej klasy:  Zachowanie – co instancje klasy robią  Stan – jakie informacje przechowują

◦ Określenie współpracy każdej klasy  Inne klasy potrzebne do wypełnienia odpowiedzialności

Metoda kart CRC – krok1  

Umieszczenie każdej zidentyfikowanej klasy na osobnej karcie CRC (4x6 cali) Stworzenie dodatkowych kart dla aktorów reprezentujących systemy zewnętrzne ◦ Zapisanie odpowiedzialności usług i systemów zewnętrznych, z których będą korzystały klasy systemu ◦ Definicja interfejsów programistycznych pomiędzy modelowanym systemem i systemami zewnętrznymi

Metoda kart CRC – krok 2  

Zapisanie odpowiedzialności i współpracy Cele: ◦ Określenie odpowiedzialności każdej klasy tak aby spełniała wymagania ◦ Zdefiniowanie zależności między klasami



Zadania: ◦ Przegląd wszystkich przypadków użycia ◦ Dla każdej pary żądanie/odpowiedź zapisanie:  Odpowiedzialności w odpowiedniej klasie  Listy klas współpracujących przy wypełnianiu odpowiedzialności

Znajdywanie odpowiedzialności przez odgrywanie ról 

Elementy przedstawienia ◦ Scenariusz to opis przypadków użycia ◦ Role to zidentyfikowane klasy ◦ Reżyserem jest ekspert

Każdy uczestnik zespołu odgrywa rolę jakiejś klasy  Reżyser 

◦ Czyta scenariusze i nadzoruje przebieg akcji

Znajdywanie odpowiedzialności i współpracy 

Opis przypadków użycia punktem startowym: ◦ Wybranie pierwszej operacji w opisie przypadku ◦ Znalezienie klasy odpowiedzialnej za implementację operacji ◦ Zapisanie odpowiedzialności na karcie CRC ◦ Zapisanie innych klas, które mogą być potrzebne przy wypełnieniu odpowiedzialności ◦ Przejście do klasy współpracującej i wypełnienie jej odpowiedzialności oraz współpracy

Ograniczenia kart CRC Bardzo niska skalowalność  Zbyt niedokładne modelowanie związków między klasami  Brak szczegółowych informacji o atrybutach klas.  Po zbudowaniu modelu analitycznego karty stają się bezużyteczne 

Tworzenie modelu wiedzy dziedzinowej: zalecenia 

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.

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łady

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ół.

UML a model 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 ta 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, technologii. ◦ Perspektywa implementacji – diagramy są używane do opisywania bytów programistycznych z odwołaniem do konkretnego języka programowania, technologii (np. C++).

Przykład

Model dziedziny podsumowanie 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ą to te same byty, ale drugi byt był tworzony inspirując się pierwszym. 

DIAGRAM MASZYNY STANOWEJ

Diagram stanu Diagram stanu reprezentuje zachowanie obiektu o skończonej liczbie stanów i zdefiniowanych przejściach między nimi  Podstawowymi elementami diagramu są stany obiektu połączone strzałkami przejść. Obiekt, reagując na nadchodzące zdarzenia, jeżeli spełnione są określone warunki, zmienia swój stan i położenie na diagramie stanu. 

DIAGRAM STRUKTUR ZŁOŻONYCH

Diagram struktur złożonych 

Diagram struktur złożonych (ang. composite structure diagram) przedstawia hierarchicznie wewnętrzną strukturę złożonego obiektu z uwzględnieniem punktów interakcji z innymi częściami systemu.

DIAGRAM KOMPONENTÓW

Diagram komponentów Komponent to wymienny, wykonywalny fragment systemu o hermetyzowanych szczegółach implementacyjnych. Komponenty z natury służą do ponownego wykorzystania poprzez połączenie ich z innymi komponentami, zwykle poprzez ich skonfigurowanie, bez potrzeby rekompilacji.  Funkcjonalność oferowana przez komponent jest dostępna przez interfejsy, które implementuje. Z drugiej strony, komponent może wymagać pewnych interfejsów, które muszą być dostarczone przez inne komponenty.  Diagram komponentów (ang. component diagram) przedstawia komponenty, ich interfejsy oraz zależności pomiędzy nimi. 

Diagram pakietów

MODEL MANAGEMENT VIEW

Model Management View 





Diagramy pakietów służą do modelowania fizycznego i logicznego podziału systemu. Pakiety są elementem strukturalizującym elementy UML i służą do grupowania ich według dowolnego kryterium.W pakiecie można umieścić praktycznie dowolne elementy: klasy, komponenty, przypadki użycia, a także inne pakiety. W ten sposób przedstawiają one drzewiastą strukturę elementów modelu. Pakiety doskonale nadają się do wizualizacji podstawowych zależności pomiędzy częściami systemu, dzięki czemu łatwo ocenić jakość i stopień powiązań pomiędzy nimi. Dobra struktura pakietów, w której zależności są jasno uporządkowane oraz nie występują (lub występują tylko na niskim poziomie) zależności cykliczne, wspiera późniejszą rozbudowę systemu. Diagramy w szczególności przydają się w dużych aplikacjach, podzielonych na wiele podsystemów, ponieważ w prosty sposób obrazują podstawowe zależności pomiędzy nimi.

DIAGRAM WDROŻENIA

Diagram wdrożenia Diagram wdrożenia (ang. deployment diagram) odzwierciedla fizyczną strukturę całego systemu, z uwzględnieniem oprogramowania i sprzętu. Jednostki oprogramowania są reprezentowane przez artefakty (czyli skompilowane wersje komponentu, który można uruchomić), dane i biblioteki. Stronę sprzętową reprezentują węzły, czyli poszczególne urządzenia obliczeniowe, komunikacyjne i przechowujące, powiązane ścieżkami komunikacyjnymi (np. połączeniem TCP/IP).  Diagramy te są rzadko używane przy modelowaniu mniejszych i średnich systemów, dlatego zwykle ich rola jest ograniczona. Ponieważ posługują się zaledwie kilkoma symbolami, dlatego kluczową rolę odgrywają stereotypy nadawane poszczególnym elementom. Pozwalają one doprecyzować znaczenie i funkcję oprogramowania oraz sprzętu. Diagramy wdrożenia istotną rolę odgrywają przy wdrażaniu dużych, rozproszonych systemów. 

ROZSZERZENIA W UML

Mechanizm rozszerzeń UML UML służy obecnie do opisu modeli w wielu dziedzinach zastosowań. Aby umożliwić obejmowanie kolejnych dziedzin bez potrzeby modyfikowania lub rozszerzania języka, wprowadzono do niego mechanizm rozszerzeń.  Pozwala on redefiniować pojęcia i elementy oraz doprecyzowywać ich znaczenie tak, aby odpowiadały potrzebom nowego obszaru zastosowań.  W skład mechanizmu rozszerzeń wchodzą trzy elementy: 

◦ profile, zawierające rozszerzenia do modelowania określonych dziedzin ◦ stereotypy, zmieniające znaczenie poszczególnych elementów ◦ Metki (tagged values), opisujące dodatkowe właściwości elementów

Profile 

Wśród tych mechanizmów najważniejszym są profile, zawierające kompletny i spójny zestaw elementów dedykowanych do modelowania określonej dziedziny, np. systemów czasu rzeczywistego, baz danych, logiki biznesowej etc. Zdefiniowane i zaakceptowane profile pozwalają uniknąć kaskady różnorodnych rozszerzeń dokonywanych przez użytkowników na własną rękę, co znacznie zmniejszało czytelność i komunikatywność modeli.

Stereotypy Stereotypy służą do zmieniania lub doprecyzowania semantyki elementów modelu. Dzięki nim można dokładnie określić ich rolę w systemie.  Stereotypy są reprezentowane przez słowo kluczowe ujęte w "łapki": «stereotyp»  Najczęściej używane stereotypy posiadają także własną ikonę, która jest umieszczana wewnątrz stereotypowanego elementu lub całkowicie go zastępuje. 

Tagged values 

Metki (ang. tagged values) pozwalają dołączyć do elementu dodatkowe właściwości ◦ Metki posiadają postać par klucz : wartość ◦ Stereotypy i profile definiują własne zestawy metek ◦ Metki są zapisywane w postaci notatki dołączonej do elementu, którego dotyczą

W większości narzędzi są one zapisywane w postaci metadanych, zawartych wewnątrz elementu, ponieważ tak łatwiej je przetwarzać. Metki, podobnie jak stereotypy, są zasadniczo definiowane wewnątrz profili (i znajdujących się w nich stereotypów), jednak istnieje także możliwość ich definiowania przez użytkowników.  Najprostszym przykładem metki może być informacja o autorze modelu {autor = "Jan Kowalski"}. 

Wybrane narzędzia: ArgoUML 

ArgoUML ◦ ◦ ◦ ◦ ◦

open source, licencja BSD wsparcie dla UML 1.4 możliwość stałej inspekcji modelu synchronizacja modelu z kodem http://argouml.tigris.org

ArgoUML

Rational 

Rational Rose, Rational Software Modeler ◦ narzędzia komercyjne ◦ integracja z innymi narzędziami Rational ◦ wsparcie dla UML 1.x (Rose) i UML 2.0 (Modeler) ◦ wsparcie dla modelowania wybranych dziedzin i technologii ◦ modelowanie biznesowe ◦ synchronizacja modelu z kodem ◦ http://www-306.ibm.com/software/rational/