Modelowanie i analiza systemów informatycznych.

Transkrypt

1 Modelowanie i analiza systemów informatycznych. Robert Plebaniak 14 października 2013 roku

2 Model Model i jego własności Czym jest model? modele są budowane w celu lepszego zobrazowania istniejących lub przyszłych systemów; model nigdy nie będzie w pełni odpowiadał rzeczywistości; modelowanie jest nierozerwalnie związane z uwypuklaniem pewnych cech i pomijaniem innych; nie ma uniwersalnej odpowiedzi na pytanie o to, co wyróznić a co pominąć.

3 Model Model i jego własności Model systemu realizuje następujące zadania: opisanie modelu komunikacji i powiązań między elementami systemu; zobrazowanie przebiegu wszystkich procesów z punktu widzenia klientów, specjalistów i użytkowników; weryfikacja faktów pod kątem kompletności spójności i poprawności;

4 Model Cel i grupa docelowa Aby zdefiniować grupę docelową, szukamy odpowiedzi na następujące pytania: Jakiego poziomu zaawansowania biznesowego należy oczekiwać od odbiorców? Jaki poziom szczegółowości jest potrzebny odbiorcom? Ile czasu może grupa docelowa poświęcić na analizę i interpretację modelu? Jezyk definiowania modelu: ogólnie występująca terminologia (mniejsza precyzja, ale większe grono odbiorców); terminologia specjalistyczna (duża precyzja, ale znacząco zawężony krąg odbiorców); przykład: butelkę z woda można oznaczyć za pomocą falek, napisu WODA lub pisząc H 20.

5 Model Proces analizy Proces analizy składa się z faz: pozyskiwania informacji od dostawców wiedzy; reprezentowania (specyfikowanie); weryfikacji.

6 Model Proces analizy W procesie analizy i poznawania procesów biznesowych pomocne bywaja nastepujace techniki: obserwacja pracowników przy pracy; branie udziału w analizowanych procesach bizensowych; przyjęcie roli uczestnika zewnętrznego, np.klienta; ankiety i przeprowadzanie wywiadów; organizowanie burz mózgów z udziałem wszystkich zaangażowanych grup; prowadzenie dyskusji z ekspertami; analiza istniejących formularzy, dokumentacji, specyfikacji i narzędzi pracy; opisywanie struktury organizacyjnej i zasad przepływu informacji.

7 Model Źródła informacji do procesu analizy Jako dostawcy wiedzy mogą służyć: uczestnicy i kontrolerzy procesów biznesowych; użytkownicy systemów informatycznych o funkcjonalności zbliżonej do modelowanego systemu lub związanej z nim; klienci; eksperci w analizowanej dziedzinie; niezależni obserwatorzy.

8 System informacyjny a informatyczny Podstawowe pojęcia Informacja - rodzaj zasobów, danych, pozwalający na zmniejszenie niepwewności, nieokreśloności, czyli na zwiększenie naszej wiedzy. System informatyczny (system przetwarzający informacje ) - jest to zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie informacji. System informacyjny - można określić jako posiadającą wiele poziomów strukturę pozwalającą użytkownikowi na przetwarzanie, za pomocą procedur i modeli, informacji wejściowych w wyjściowe.

9 System informacyjny a informatyczny System informatyczny Na systemy informatyczne składają się: sprzęt - obecnie głównie komputery ( można wymienić tu także: urządzenia służące do przechowywania informacji, urządzenia służące do komunikacji między sprzętowymi elementami systemu, urządzenia służące do komunikacji między ludźmi a komputerami, urządzenia służące do odbierania informacji ze świata zewnętrznego ( nie od ludzi ), i inne; oprogramowanie; zasoby osobowe; elementy organizacyjne - czyli procedury korzystania z systemu informatycznego, instrukcje robocze itp. elementy informacyjne; bazy wiedzy - ontologie dziedziny/dziedzin w której używany jest system informatyczny.

10 System informacyjny a informatyczny System informacyjny System informacyjny danej organizacji oznaczmy przez SI. Wówczas gdzie: SI = {P, I, T, O, R, M}, P - zbiór podmiotów, które są użytkownikami systemu; I - zbiór informacji o sferze realnej czyli o jej stanie i zachodzących w niej zmianach a więc tzw. zasoby informacyjne; T - zbiór narzędzi technicznych stosowanych w procesie pobierania, przesyłania, przetwarzania, przechowywania i wydawania informacji; O - zbiór rozwiązań systemowych stosowanych w danej organizacji, a więc stosowana formuła zarządzania (podsystem zarządzania); M - zbiór metainformacji, czyli opis systemu informacyjnego i jego zasobów informacyjnych; R - relacje między poszczególnymi zbiorami.

11 System informacyjny a informatyczny System informacyjny a informatyczny Wniosek: System informacyjny - domena człowieka; System informatyczny - domena maszyny.

12 Rozwój i struktura języka UML Podejscie strukturalne i obiektowe Analizę oraz projektowanie systemów informatycznych zdominowały dwa podejścia: podejście strukturalne; podejście obiektowe. Lata 80-te XX-ego wieku to okres szczególnej dominacji podejścia strukturalnego, które zaowocowało wieloma metodykami wypracowanymi przez środowiska naukowe i biznesowe. Mimo różnic między nimi, istniało wiele punktów, kategorii i mechanizmów wspólnych, co stanowiło podstawę dalszego rozwoju. Do tych wspólnych cech można zaliczyć między innymi pojęcia takie jak: cykl życia systemu, prototypowanie, diagramy związków encji, modele relacyjnych baz danych.

13 Rozwój i struktura języka UML Unifikacja Inicjatywy unifikacyjne mające na celu uporządkowanie wiedzy i procedur modelowania systemów informatycznych: podjęta przez International Federation of Information Processing (IFIP), w postaci grupy roboczej CRIS (Comparative Review of Information Systems Methodologies); podjęta przez Unię Europejską w ramach zespołu reprezentującego autorów metodyk używanych w różnych krajach członkowskich pod nazwą EuroMethod.

14 Rozwój i struktura języka UML Podejscie obiektowe Od początku lat 90-tych w centrum zainteresowania twórców i użytkowników systemów znalazły się modele obiektowe. Wzrost znaczenia obiektowości stymulowany był przez: wyzwania postępu technologicznego w informatyce, coraz bardziej powszechne użytkowanie systemów czasu rzeczywistego i systemów wbudowanych; różnorodność i powszechność aplikacji internetowych w gospodrace opartej na wiedzy, czyli w takich dziedzinach jak e-business, e-health, e-government, e-learning; multimedialny charakter aplikacji, wykorzystujących w coraz wiekszym stopniu dźwięk, głos, grafikę, film; powszechność i dostępność aplikacji, zwłaszcza internetowych, dla potrzeb społeczeństwa informacyjnego; globalizację gospodarki, a zatem integrację systemów informatycznych - w telekomunikacji, transporcie, turystyce, bankowości, edukacji.

15 Rozwój i struktura języka UML Podejście obiektowe Podejście obiektowe ma obecnie największe znaczenie w następujących zastosowaniach: metodykach tworzenia oprogramowania (przede wszystkim Rational Unified Process); graficznych jezykach ogólnego przeznaczenia (UML); objektowych językach programowania (JAVA, platforma.net); bazach danych (np. Object Store).

16 Rozwój i struktura języka UML Główne pojęcia podstawowego modelu obiektowego Objekt (and. object) - każdy byt - pojęcie lub rzecz - mający znaczenie w kontekście rozwiązywania problemu w danej dziedzinie przedmiotowej. Klasa (and. class) - uogólnienie zbioru obiketów, które mają te same atrybuty, operacje, związki i znaczenie. Komunikat (and. message) - specyfikacja wymiany informacji między obiektami, zawierająca zlecenia wykonania określonej operacji.

17 Rozwój i struktura języka UML Główne pojęcia podstawowego modelu obiektowego hermetyzacja (and. encapsulation) - różnicowanie dostępu do obiektu poprzez ujawnienie otoczeniu tylko tych informacji o jego atrybutach lub operacjach, które są niezbędne do efektywnego odwoływania się do obiektu w systemie za pośrednictwem komunikatów. polimorfizm (and. polymorphism) - możliwość nadawania tej samej nazwy różnym atrybutom i operacjom oraz wykonywania różnych procedur i akcji poprzez operacje o tych samych nazwach; pozwala na redukcję liczby nazw atrybutów i operacji. dziedziczenie (and. inheritance) - przyporządkowanie atrybutów i operacji klasom obiektów na podstawie hierarchicznej zależności między nimi. Możliwe jest wielokrotne dziedziczenie, co oznacza, że dana klasa dziedziczy atrybuty i operacje z dowolnej liczby klas nadrzędnych.

18 Rozwój i struktura języka UML UML - geneza i ewolucja UML - ujednolicony język modelowania systemów informatycznych (and. Unified Modeling Language). Modelowanie systemów informatycznych obejmuje aspekty funkcjonalne oraz niefunkcjonalne. Możliwość ich modelowania była i nadal jest motywem ewolucji języka UML, którego kolejne wersje są wzbogacane o nowe kategorie, będące odpowiedzią na wymagania twórców systemów informatycznych stawiane metodom i technikom modelowania. Załóżenia autorów języka UML wykraczały poza dokonanie prostej kompilacji.

19 Rozwój i struktura języka UML UML - geneza i ewolucja Język modelowania systemów informatycznych pośredniczy między ludzkim rozumieniem funkcjonowania programów komputerowych a ich fizyczną realizacją w postaci kodu źródłowego. Stąd język taki powinien jednocześnie: w sposób ścisły definiować podstawowe i zaawansowane kategorie oraz zasady modelowania obiektowego; umożliwiać dostosowywanie wykorzystywanej semantyki i notacji do rozwiązywania szerokiego spektrum problemów; wykazywać elastyczność wystarczającą do modelowania, obok systemów oprogramowania, także systemów biznesowych; wykazywać daleko posuniętą niezależność od konkretnych języków programowania oraz metodyk tworzenia systemów informatycznych; uwzględniać skalę realizowanych współcześnie projektów, związanych z bardzo rozbudowanymi systemami o kluczowym znaczeniu dla funkcjonowania przedsiębiorstw.

20 Rozwój i struktura języka UML Kalendarium październik zapoczątkowano pracę nad UML (J. Rumbaugh, G. Boochem UM 0.8, Unifed Method) styczeń powstanie wersji UM 1.0 -wersja przekazana jako propozycja standardu organizacji OMG (Object Managment Group) lipiec korporacja Rational przedstawia kolejna propozycję UML-a w wersji 1.1, również przekazaną do OMG kwiecień OMG RFT publikuje kolejną wersje UML 1.4 wrezsień pojawia się wersja 1.5 (wersja nieoficjalna) sierpień zaprezentowana zostaje wersja 2.0.

21 Diagramy UML Diagramy UML Język UML przyjmuje w praktyce postać graficznej reprezentacji tworzonego systemu, składającej się z logicznie powiązanych z sobą diagramów. Wyróżniamy następujące ich kategorie: diagramy abstrakcyjne; diagramy konkretne. W standardzie UML występuje trzynaście rodzajów diagramów, które charakteryzują statystykę i dynamikę tworzonego systemu.

22 Diagramy UML Diagramy abstrakcyjne Diagramy abstrakcyjne są jedynie nazwami uogólniającymi grupy diagramów konkretnych. Do tej kategori zalicza się: diagramy struktury; diagramy dynamiki; diagramy wdrożeniowe; kategorię diagramów UML.

23 Diagramy UML Diagramy konkretne Do diagramów konkretnych zalicza się: diagram klas (ang. Class Diagram) - kls (cld) - diagram klas to graficzne przedstawienie statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi; diagram obiektów (Object Diagram) - obk (od) - diagram obiektów to wystąpienie diagramu klas, odwzorowujące strukturę systemu w wybranym momencie jego działania; diagram pakietów (ang. Package Diagram) - pkt (pd) - diagram pakietów to graficzne przedstawienie logicznej struktury systemu w postaci zestawu pakietów połączonych zależnościami i zagnieżdżeniami;

24 Diagramy UML Diagramy konkretne diagram struktur połączonych (ang. Composite Structure Diagram) - spl (csd) - diagram struktur połączonych to graficzne przedstawienie wzajemnie współdziałających części dla osiągnięcia pożądanej funkcjonalności współdziałania; diagram komponentów (Component Diagram) - kmp (cod) - diagram komponentów to rodzaj diagramu wdrożeniowego, który wskazuje organizację i zależność między komponentami; diagram rozlokowania (ang. Deployment Diagram) - rzk (dd) - diagram rozlokowania to rodzaj diagramu wdrożeniowego, który przedstawia sieć połączonych ścieżkami komunikowania węzłów z ulokowanymi na nich artefaktami;

25 Diagramy UML Diagramy konkretne diagram przypadków użycia (ang. Use Case Diagram) - uzc (ud) - diagram przypadków użycia to graficzne przedstawienie przypadków użycia, aktorów oraz związków między nimi, występujących w danej dziedzinie przedmiotowej; diagram czynności (Activity Diagram) - czn (ad) - diagram czynności to graficzne przedstawienie sekwencyjnych i (lub) współbieżnych przepływów sterowania oraz danych pomiędzy uporządkowanymi ciągami czynności, akcji i obiektów; diagram maszyny stanowej (ang. State Machine Diagram) - stn (sm) - diagram maszyny stanowej to graficzne odzwierciedlenie dyskretnego, skokowego zachowania skończonych systemów stan-przejście;

26 Diagramy UML Diagramy konkretne diagram sekwencji (ang. Sequence Diagram) - skw (sd) - diagram sekwencji jest rodzajem diagramu interakcji, opisującym interakcjie pomiędzy instancjami klasyfikatorów systemu w postaci sekwencji komunikatów wymienianych między nimi; diagram komunikacji (Communication Diagram) - kmn (cd) - diagram komunikacji jest rodzajem diagramu interakcji, specyfikującym strukturalne związki pomiędzy instancjami klasyfikatorów biorącymi udział w interakcji oraz wymianę komunikatów pomiędzy instancjami; diagram harmonogramowania (ang. Timing Diagram) - hrm (tm) - diagram harmonogramowania jest rodzajem diagramu interakcji, reprezentującym na osi czasu zmiany dopuszczalnych stanów, jakie może przyjmować instancja klasyfikatora uczestnicząca w interakcji;

27 Diagramy UML Diagramy konkretne diagram sterowania interakcjią (ang. Interaction Overview Diagram) - sin (iod) - diagram sterowania interakcją jest rodzajem diagramu interakcji, dokumentującym przepływ sterowania pomiędzy logicznie powiązanymi diagramami i fragmentami interakcji z wykorzystaniem kategorii modelowania diagramów czynności.

28 Diagramy UML Klasyfikator i Instancja Specyfikacja języka UML wprowadza pojęcie klasyfikatora (ang. classifier), które ma zastosowanie w odniesieniu do praktycznie każdego rodzaju diagramu języka UML 2.0. Klasyfikator - to abstrakcyjna kategoria modelowania systemu w języku UML, która uogólnia kolekcję instancji o tych samych cechach. Na konkretnych diagramach języka UML zamieszcza się instancje poszczególnych rodzajów klasyfikatorów. Instancja - jest wystąpieniem, egzemplarzem klasyfikatora. W języku UML 2 funkcjonuje również pojęcie klasyfikatora ustrukturyzowanego (ang. structured classifier). Klasyfikator ustrukturyzowany zawiera specyfikację wewnetrznej struktury.

29 Diagramy UML Prezentacja diagramów Diagram może być prezentowany w postaci obramowanej i nieobramowanej. Każdy diagram w postaci obramowanej zawiera nagłówek, o następującej składni: <nagłówek-diagramu>::=[<rodzaj>] <nazwa> [<parametry >] gdzie, rodzaj - pełny lub skrótowy wyróżnik diagramu zawartego w ramie; nazwa - syntetyczna nazwa odzwierciedlająca merytoryczną zawartość diagramu; parametry - szczegółowe parametry kluczowe dla danego diagramu.

30 Diagramy UML Perspektywy w opisie architektury systemu Metodyka RUP proponuje pięć perspektyw architektury systemu informatycznego: perspektywa przypadków użycia - kluczowa i dominująca wobec pozostałych, definuje zakres i oczekiwaną funkcjonalność tworzonego systemu; perspektywa dynamiczna - wskazuje, w jaki sposób jest realizowane zachowanie instancji klasyfikatorów w systemie; perspektywa logiczna - dokumentuje statystyke systemu; perspektywa komponentów - przeznaczona głównie dla programistów, specyfikuje oprogramowanie na poziomie komponentów; perspektywa rozlokowania - specyfikuje sprzęt informatyczny niezbędny do funkcjonowania konkretnych komponentów systemu.

31 Diagramy UML Koniec wykładu 1

32 Diagram przypadków użycia Diagramy przypadków użycia

33 Diagram przypadków użycia Znaczenie diagramów przypadków użycia Diagram przypadków użycia to graficzne przedstawienie przypadków użycia, aktorów oraz związków między nimi, występujących w danej dziedzinie przedmiotowej. Poprzez interakcję aktorów z przypadkami użycia zaprezentowana na diagramach przypadków użycia, z jednej strony aktorzy pełnią rolę wobec systemu, a z drugiej przypadki użycia określają usługi świadczone przez system na rzecz aktorów (użytkowników, klientów).

34 Diagram przypadków użycia Zadania diagramów użycia: Daigramy przypadków użycia: identyfikują oraz dokumentacją wymagania; umożliwiają analizę obszaru zastosowań, dziedziny przedmiotowej; pozwalają na opracowanie projektu przyszłego systemu; stanowią przystępną i zrozumiałą paltformę komunikacji i współpracy udziałowców (ang. stakeholders) systemu - aktorów, twórców systemu, inwestorów i właścicieli; są rodzajem umowy, kontraktu pomiędzy udziałowcami co do zakresu i funkcjionalności przyszłego systemu; stanowią podstawę testowania funkcji systemu na dalszych etapach jego cyklu życia.

35 Diagram przypadków użycia Podstawowe kategorie pojęciowe Diagramy przypadków użycia zawierają następujące kategorie pojęciowe: Przypadki użycia - to specyfikacja ciągu akcji i ich wariantów, które system (lub inna jednostka) może wykonać poprzez interakcje z aktorami tego systemu. Aktor - jest to spójny zbiór ról odgrywanych przez użytkowników przypadków użycia w czasie interakcji z tym przypadkiem użycia. Związek - stanowi semantyczne powiązanie pomiędzy elementami modelu.

36 Diagram przypadków użycia Przypadek użycia Przypadek użycia (ang. use case) jest kompleksowym działaniem realizowanym w systemie w konsekwencji określonej aktywności aktora. Zakres danego przedsięwzięcia determinowany jest przez zestaw wszystkich wzajemnie powiazanych przypadków użycia. Notacja przypadków użycia

37 Diagram przypadków użycia Aktor Aktorzy mogą być osobowi lub nieosobowi. Role aktora osobowego może pełnić osoba, zespół, dział, organizacja. Aktoramia nieosobowymi zaś są systemy zewnętrzne (podsystemy, bazy danych), urządzenia oraz czas.

38 Diagram przypadków użycia Aktor Notacja aktorów:

39 Diagram przypadków użycia Związek Każdy aktor umieszczony na diagramie przypadków użycia powinien być bezpośrednio powiązany z co najmniej jednym przypadkiem użycia. Każdy przypadek użycia użytkowany jest przez co najmniej jednego aktora, chociaż niejednokrotnie nie są to powiązania pośrednie. W diagramach języka UML wyróżnić można cztery rodzaje związków: asocjację jest związkiem pomiędzy dwoma lub więcej klasyfikatorami, opisującym powiązania pomiędzy ich instancjami; uogólnienie; zależność; realizację.

40 Diagram przypadków użycia Asocjacja W diagramach przypadków użycia asocjacja wskazuje domyślnie na dwukierunkową komunikację pomiędzy aktorem a przypadkiem użycia. Nie jest ona oznaczeniem konkretnego przepływu, np. dokumentów Może ona dodatkowo występować w formie ze wsakzanym kirunkiem nawigacji.

41 Diagram przypadków użycia DPU

42 Diagram przypadków użycia Granica obszaru zastosowań Granica obszaru zastosowań reprezentuje zakres funkcjonalny przyszłego systemu. Aktorów komunikujących się z systemem umieszcza się poza granicą obszaru zastosowan. W celu zaznaczenia granicy obszaru zastosowań przyszłego systwemu, jego dziedziny przedmiotowej, można wprowadzić prostoką grupujący przypadki uzycia. Zawiera on tytuł określający nazwę analizowanej dziedziny przedmiotowej.

43 Diagram przypadków użycia Składniki diagramu Do zaawansowanych koncepcji diagramów przypadków użycia należy zaliczyć: rozbudowę DPU poprzez róznicowanie związków; zależności zawierania; zależności rozszerzania; uogólnienie; rodzaje aktorów; liczebność; nawigację; realizację; przypadki użycia typu CRUD; diagram kontekstowy; dokumentację przypadków użycia.

44 Diagram przypadków użycia Rozbudowa DPU poprzez róznicowanie związków Związki asocjacji występują wyłącznie pomiędzy aktorami a przypadkami użycia. Pozostałe rodzaje związków (zależności, uogólonienia i realizacji) pozwalają pokazać, w jakich relacjach znajduja się poszczególne przypadki użycia. Ponadto związki uogólnienia umożliwiają udokumentowanie relacji pomiędzy aktorami. Dzięki róznym rodzajom związków można tworzyć złożoną strukturę modelu przypadków użycia. Stanowi on wówczas zestaw logicznie powiązanych diagramów. Porządkującą rolę może tu odegrać diagram pakietów. Szczególone możliwości rozbudowywania diagramów przypadków użycia stawrzają zależności (ang. dependencies). Zależności to taki związek pomiędzy dwoma elementami modelowania, w którym zmiana jednego z nich, niezależnego, wpływa na drugi, zależny.

45 Diagram przypadków użycia Zależność zawierania Zależność zawierania «include» przedstawia powiązanie pomiędzy przypadkiem zawierającym, tj. bazowym przypadkiem użycia, a przypadkiem zawieranym. Jest to związek obligatoryjny. Zawierany przypadek uzycia nie jest wykonywany samodzielnie, ale wyłącznie przy odwołaniu sie do większego, zawierającego przypadek użycia. Zależność zawierania jest skierowana od przypadku zawierającego do zawieranego.

46 Diagram przypadków użycia Zawieranie

47 Diagram przypadków użycia Zależność rozszerzania Zależność rozszerzania «extend» przedstawia powiązanie pomiędzy rozszerzanym przypadkiem użycia, tj. przypadkiem bazowym, a przypadkiem rozszerzającym. Związek ten ma charakter opcjonalny. Funkcjonalność reprezentowana przez rozszerzający przypadek uzycia może, ale nie musi zostać włączona do rozszerzanego przypadku użycia. Zależność rozszerzania jest skierowana od przypadku rozszerzającego do rozszerzanego.

48 Diagram przypadków użycia Uogólnienie

49 Diagram przypadków użycia Rodzaje zależności

50 Diagram przypadków użycia

51 Diagram przypadków użycia Zależność rozszerzania Dodatkowa funkcjonalność zawarta w przypadkach rozszerzających nie jest wykonywana automatycznie. Przypadek bazowy może być rozszerzany o przypadki rozszerzające po spełnieniu określonych warunków. warunki te określa się w przypadku bazowym jako miejsca rozszerzania bądź punkty rozszerzania (ang. extension points). Po wykonaniu wszelkich działań związanayxch z rozszerzeniem kontynuowane są działania należace do przypadku bazowego.

52 Diagram przypadków użycia Miejsca rozszerzenia

53 Diagram przypadków użycia Uogólnienia Uogólnienie to związek o charakterze taksonomicznym pomiędzy klasyfikatorem ogólnym a specjalizowanym. Element specjalizowany, z założenia dziedziczy wszelkie cechy elementu ogólnego.

54 Diagram przypadków użycia Hierarchia dziedziczenia

55 Diagram przypadków użycia Rodzaje aktorów Język UML jest elastyczny i umożliwaia wprowadzanie nowych pojęć oraz oznaczeń zwanych stereotypami. Notacja aktorów może w szczególności przybierać postać stereotypów graficznych. I tak uzasadnione jest wyróznienie czterech rodzajów aktorów: ludzi oraz zespołów; systemów zewnętrznych; urządzeń; czasu.

56 Diagram przypadków użycia Rodzaje aktorów

57 Diagram przypadków użycia Liczebność

58 Diagram przypadków użycia Nawigacja

59 Diagram przypadków użycia Realizacja Realizacja to związek znaczeniowy między klasyfikatorami, z których jeden określa kontakt,a drugi zapewnia wywiązanie się z niego. Związki realizacji w odniesieniu do przypadków użycia pozwalają modelować relacje występujące pomiędzy ogólnym, funkcjonalnym opisem systemu w postaci diagramów przypadków użycia a jego wdrożeniem. Modele opisujące wdrożenie przypadku użycia określane są mianem współdziałań (ang. cooperations). Współdziałania mmożna łączyć w ciągi coraz bardziej szczegółowych, dalej idących specyfikacji za pomocą zależności stereotypowanej «refine», która wskazuje, że element docelowy jest bardziej szczegółowy niż element źródłowy.

60 Diagram przypadków użycia Realizacja

61 Diagram przypadków użycia Konwencja CRUD Konwencja CRUD obejmuje: CREATE - tworzenie, wprowadzanie; READ - odczytywanie; UPDATE - aktualizacja, modyfikowanie; DELETE - usuwanie, skreślenie.

62 Diagram przypadków użycia Diagram kontekstowy Diagram kontekstowy stanowi zestawienie aktorów będących w interakcji z danym systemem traktowanym w kategorii pojedynczego procesu. Diagramy te, mogą się okazać pomocne w identyfikacji zbiorowości aktorów przed sporządzeniem pełnego diagramu DPU.

63 Diagram przypadków użycia Dokumentacja przypadków użycia Każdy przypadek użycia powinien być uzupełniony o stosowną dokumentację, charakteryzującą scenariusze tego przypadku użycia (ang. use case scenarios) Scenariusz stanowi ciąg akcji dokumentujących zachowanie. Dla danego przypadku użycia zawsze należy wyróznić: scenariusz główny; scenariusz alternatywny. Scenariusze mogą przybierać postać: niesformalizowanego tekstu; formalnego tekstu strukturalnego; pseudokodu; tabeli.

64 Diagram przypadków użycia Dokumentacja przypadków użycia Dokumentacja szczegółowo opisuje główny scenariusz przypadku użycia oraz wskazuje alternartywne przepływy zdarzeń. Do jej ważnych elementów należą także: warunek wstępny; warunek końcowy.

65 Diagram przypadków użycia Proces tworzenia diagramu przypadków użycia Etapy tworzenia diagramu przypadków użycia: 1. identyfikacja aktorów; 2. opcjonalne opracowanie diagramu kontestowego; 3. identyfikacja przypadków użycia; 4. opracowanie związków w szczególności asocjacji; 5. wykorzystanie wszystkich kategorii zaawansowanych do opracowania diagramu przypadków użycia; 6. udokumentowanie przypadków użycia z wykorzystaniem szablonów.

66 Diagram przypadków użycia Koniec wykładu 2

67 Diagram klas Znaczenie diagramu klas Diagram klas to graficzne przedstawienie statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi.

68 Diagram klas Podstawowe kategorie pojęciowe Diagramy klas zawierają następujące kategorie pojęciowe: Obiektem - jest każdy byt - pojęcie lub rzecz - mający znaczenie w kontekście rozwiązywania problemu w danej dziedzinie przedmiotowej. Klasa - jest uogólnieniem zbioru obiektów, które mają takie same atrybuty, operacje, związki i znaczenie.

69 Diagram klas Obiekt Na obiekt składają się: atrybuty; operacje. Wartości atrybutu reprezentują cechy statyczne danego obiektu, czyli wszystko co wiadomo o tym obiekcie. Operacje określają zachowanie się obiektu, czyli usługi, które dany obiekt oferuje. Obiekt jest wyróżniany przez samo istnienie, a nie cechy opisowe. Unikatowa tożsamość daje więc możliwość jednoznacznego wyodrębnienia obiektu ze zbiorowości innych obiektów, nawet gdy wszystkie wartości przechowywane przez obiekty są identyczne.

70 Diagram klas Klasa Podstawę identyfikacji klasy stanowią grupy obiektów charakteryzujace się: identyczną strukturą danych; identycznym zachowaniem; identycznymi związkami; identycznym znaczeniem w określonym kontekście.

71 Diagram klas Klasa W diagramach klasę standardowo przedstawia się jako prostokąt złożony z trzech sekcji: nazwy klasy; zestawu atrybutów; zestawu operacji.

72 Diagram klas Klasa Graficzna prezentacja klas

73 Diagram klas Liczba sekcji w klasie Liczbę sekcji w każdej klasie można zwiększać, dodając na przykład sekcje zawierające zobowiązania bądź wyjątki. Sekcje te można dodawać opcjonalnie w przypadkach, gdy jest to niezbędne dla podniesienia precyzji diagramu klas.

74 Diagram klas Rodzaje związków między klasami W diagramach klas stosuje się cztery rodzaje związków: asocjację; uogólnienia; zależności; realizacje.

75 Diagram klas Asocjacja Asocjacji opisuje zbiór powiązań pomiędzy obiektami. Wyróżnia się dwa rodzaje asocjacji: asocjacja binarna - dominująca w praktyce; asocjacja n-arna.

76 Diagram klas Asocjacje n-arne Pełna semantyczna interpretacja związku wymaga wprowadzenia szeregu dodatkocwych elementów opisu. Asocjację można sprecyzować poprzez określenie następpujących cech: nazwy; ról powiązancyh klas; nawigacji; liczebności; agregacji.

77 Diagram klas Nazwy asocjacji Asocjacje mogą być: nienazwane; nazwane, z opcjonalnym zamieszczeniem znacznika wskazującego kierunek interpretacji asocjacji; scharakteryzowane poprzez role klasy pełnione w asocjacji; nazwane i równocześnie scharakteryzowane przez role.

78 Diagram klas Role i nawigacja Asocjacje można interpretować dwustronnie poprzez podanie ról (ang. roles) pełnionych przez powiązane ze sobą klasy. Nazwy ról umieszcza się po obydwu stronach asocjacji. Rola spełniana przez daną klasę lokowana jest bezpośrednio przy klasie określonej. Dla asocjacji istniejącej pomiędzy klasami komunikowanie domyślnie odbywa się w obydwu kierunkach. Jest to nawigacja dwukierunkowa. W praktyce wystepują sytuację, w których wskazanie kierunku nawigacji zwiększa efektywność komunikowania się. Mamy wtedy sytuację nawigacji jednokierunkowej.

79 Diagram klas Agregacja Agregacja opisuje związek całość-część pomiędzy klasami. Wyróżnia się dwa rodzaje agregacji: agregację całkowitą - kompozycję (inne nazwy: agregacja silna lub składowa); agregację częściową (inne nazwy: agregacja słaba lub współdzielona). W obu rodzajach agregacji występują dwa pojęcia: agregat - obiekt stanowiący całość; segment - część.

80 Diagram klas Agregacja całkowita W przypadku agregacji całkowitej obiekty-segmenty będące częściami agregatów nie mogą samodzielnie i niezależnie funkcjonować. Usunięcie agregatu powoduje automatyczną likwidację wszystkich segmentów będących jego częściami.

81 Diagram klas Agregacja częściowa Agregacja częściowa wskazuje na asocjację, w której usunięcie obiektu będącego agregatem nie powoduje likwidacji obiektów będących jego częściami, czyli obiektów-segmentów. Obiekty współdzielone mogą zatem funkcjonować samodzielnie, niezależnie od agregatu.

82 Diagram klas Diagram klas z uwzględnieniem agregacji

83 Diagram klas Zaawansowane składniki diagramu Diagram klas charakteryzuje się znaczną liczbą zaawansowanych elementów i koncepcji modelowania. Obejmuja one: rodzaje diagramów klas; zobowiązania; widoczność; atrybuty i operacje statyczne; nazwy klas, atrybutów i operacji; notację atrybutów i składnię operacji; klasy asocjacyjne; asocjacje zwrotne i wielokrotne; kwalifikację; uogólnienia, klasy abstrakcyjne oraz konkretne; zależności; realizację.

84 Diagram klas Rodzaje diagramów klas Poziomy tworzenia diagramów klas: poziom konceptualny; poziom implementacyjny. Konceptualny diagram klas zawiera wyłącznie podstawowe elementy, cechując się przystępnością nazewnictwa klas, atrybutów i operacji. Implementacyjny diagram klas jest stopniowo wzbogacany o elementy opisu niezbędne dla prawidłowej specyfikacji modelu, takie jak: typy danych, zobowiązania, widoczności, statyczność, klasy asocjacyjne, kwalifikacje, uogólnienia, zależności czy też realizacje.

85 Diagram klas Zobowiązania Specyfikacja zobowiązań pełni rolę pomocniczą w procesie projektowania diagramów klas, gdyz dostarcza wysokopoziomowego opisu zadań poszczególnych klas. Klasy ze zobowiązaniami są w naturalny sposób przekształcane w diagram klas z pełną specyfikacją atrybutów i operacji. Klasę której podstawową zawartość stanowią zobowiązania oraz lista współpracujących klas nazywa się kartą CRC (ang. Class-Responsibility-Collaboration card).

86 Diagram klas Widoczność Istnieją zróżnicowane wymagania względem dostępu do poszczególonych atrybutów i operacji różnych klas w systemie. Cechę widoczności oznacza poziom dostępności atrybutów i operacji inncyh klas. Poziom Symbol Charakterystyka Publiczny + obiekty wszystkich klas mają dostęp do atrybutu lub operacji Prywatny tylko obiekty danej klasy mają dostep do atrybutu operacji Chroniony wyłącznie obiekty klas dziedziczących z danej klasy mają dostep do atrybutu lub operacji Pakietowy tylko składowe pakietu, do którego dana klasa należy mają dostep do atrybutu lub operacji

87 Diagram klas Atrybuty i operacje statyczne Wszystkie instancje danej klasy mogą przechowywać pewne stałe, identyczne wartości - np. rodzaj waluty, operację tworzenia lub usuwania, stały mnożnik. W przypadku zmiany takiej wartości w jednym obiekcie zmiana ta jest automatycznie wprowadzana w innych obiektach tej klasy. Atrybuty i operacje mogą być: egzemplarzowe - indywidualne dla każdego obiektu danej klasy; statyczne - identyczne we wszytskich obiekatch klasy.

88 Diagram klas Nazwy klas, atrybutów i operacji Atrybut lub operacja Nazwa na poziomie Nazwa na poziomie konceptualnym implementacyjnym pojemność kart SIM Pojemność Karty pojemnośćkarty adres salonu Adres Salonu adressalonu numer telefonu Nr Telefonu Komór. nrtelefonukomór. komórkowego zablokowanie karty SIM Zablokuj Kartę zablokujkartę() zmiana aktualnych stawek Zmień Stawki Taryf zmieństawkitaryf() wszytstkich taryf wysyłanie krótkiej Wyślij SMS wyślijsms() wiadomości tekstowej

89 Diagram klas Notacja atrybutów i składnia operacji Typ danych Narzędzie Rational Rose Platforma.NET Logiczne Boolean Boolean Stałoprzecinkowe Byte Byte Integer Short Long Integer Long Zmiennoprzecinkowe Single Single Double Double Decimal Znakowe String String Char Inne Date Date Object Object Currency Variant

90 Diagram klas Notacja atrybutów i składnia operacji Notacja atrybutów na poziomie implementacyjnym charakteryzuje się standardową skłądnią. Ich prezentacja na diagramie odbywa się wg następującej formuły: <atrybut>::= [<widoczność>][ / ] <nazwa-atrybutu[ : <typ>] [ [ <liczebność> ] ][ = <wartość-początkowa>][ { <określeniewartości> } ]. Analogicznie również dla operacji isnieje formuła składniowa: <operacja>::= [<widoczność>] <nazwa-operacji> [ ( <lista-parametrów) ] ][ : <określenie-właściwości>].

91 Diagram klas Notacja atrybutów i składnia operacji OpcjaFinansowa premiaopcyjna: Single = wilekośćkontraktu: Double = tick: %=0,01 wartośćticku: Byte = 25 liczticki(cenasprzedaży : Double, cenanabycia :Double) :Single realizuj(ilośćticków :Single, wartośćticku :Byte, ilośćkontraktów :Integer) :Double

92 Diagram klas Notacja atrybutów i składnia operacji Język UML umożliwia obliczanie wartości atrybutów pochodnych (ang. derived attributes). Poprzedzone są znakiem ukosnika /. Ich wartość ustala się na zasadzie przypisania określonej formuły obliczeniowej, która korzysta z wartości innych atrybutów na diagramie klas. Formuła zazwyczaj jest zapisywana jako notatka odnosząca się do atrybutu pochodnego.

93 Diagram klas Klasy asocjacyjne Klasa asocjacyjna (ang. association class) umożliwia bardziej precyzyjny opis związku między klasami. Służy do przedstawiania asocjacji w postaci klas. Zawiera nazwę, atrybut i operacje. Liczbę sekcji można zwiększać. Każdej asocjacji można przypisać co najwyżej jedną instancję tego rodzaju klasy. Na diagramie klasę asocjacyjną wprowadza się poprzez ścieżkę asocjacyjną w postaci linii przerywanej.

94 Diagram klas Asocjacje zwrotne i wielokrotne Powiązane klasy mogą pełnić względem siebie kilka odmiennych ról. Tym samym klasy te mogą być połączone kilkoma asocjacjami. asocjacje takie nazywa się asocjacjami wielokrotnymi. Każda z tych asocjacji winna być nazwana lub scharakteryzowana na podstawie ról.

95 Diagram klas Asocjacje zwrotne i wielokrotne Istnieje możliwość przedstawiania asocjacji wiążącej daną klasę z samą sobą. Asocjacja taka nazywana jest asocjacją zwrotną.

96 Diagram klas Kwalifikacja Kwalifikacja umożliwia wyszukiwanie obiektów związanych z daną asocjacją. Kawlifikacja dokonuje się za pomocą kwalifikatora (ang. qualifier) - atrubutu lub listy atrybutów, których wartości porządkują zbiór obiektów tej klasy występujących w danej asocjacji.

97 Diagram klas Uogólnienia, klasy abstarkcyjne oraz konkretne W hierarchiach klas powiązanych związkami uogólnienia występują klasy abstrakcyjne i konkretne. Klasy abstrakcyjne nie mają konkretnych instancji obiektów, lecz stanowią uogólnienie obiektów konkretnych znajdujących sie na niższych poziomach hierarchii. Nazwy klas abstrakcyjnych pisane są kursywą. Klasy na najniższym poziomie hierarchii - liście leaf. Klasy na najwyższym poziomie hierarchii - korzenie root.

98 Diagram klas Uogólnienia, klasy abstarkcyjne oraz konkretne Związkom uogólnienia, występującym pomiędzy klasami obiektów znajdujących się w danej hierarchii klas, przypisać można cztery podstawowe ograniczenia. Obejmują one: {complete} - zawiera pełen zestaw podklas dla danej klasy; {incomplete} - oznacza, że zestaw podklas przypisanych danej klasie nie jest pełen, wiadomo, że istnieje więcej klas specjalizowanych nie mających istotnego znaczenia w rozpatrywanym kontekście; {disjoint} - domyślny rodzaj uogólnienia, oznaczający, że każda podklasa w hierarchii klas posiada tylko jedna klasę bezpośrednio nadrzędną (jest rozdzielona); {overlapping} - oznacza, że w hierarchi klas określone klasy mogą mieć wspólne podklasy (dziedziczenie wielokrotne).

99 Diagram klas Uogólnienia, klasy abstarkcyjne oraz konkretne Dyskryminator (ang. generalization set) jest określeniem kryterium dokonania klasyfikacji w uogólnieniu. Na ogół jest to kryterium domyślne, lecz można je wyrazić nie wprost. Dyskryminator stwarza możliwość systematyzowania związków uogólnień.

100 Diagram klas Zależność Związek zależności w diagramach klas oznacza, że niezależna klasa obiektów (inaczej zwana docelową), wykorzystuje klasę zależną (inaczej źródłową). Istnieje szereg rodzajów zależności. Ich opis można uszczegółowić poprzez podanie stereotypów dostepnych w języku UML.

101 Diagram klas Realizacja Klasy mogą brać udział w związkach realizacji - jedna strona tego związku wskazuje klasyfikator określający kontakt, natomiast druga - klasyfikator zapewniający wywiązanie sie z niego. Realizacja - wskazuje na związek pomiędzy interfejsem a klasą. Identyfikuje interfejsy, które zapewniają realizację usługi klasy. Interfejs - to zestaw operacji, które wyznaczaja usługi oferowane przez klasę lub komponent.

102 Diagram klas Diagramy obiektów Diagram obiektów to wystapienie diagramu klas, odwzorowujące strukturę systemu w wybranym momencie jego działania.

103 Diagram klas Proces tworzenia diagramu klas W procesie tworzenia diagramu klas wyróżnic można nastepujące etapy: zidentyfikowanie i nazwanie klas; opcjonalne określenie zobowiązań klas; połączenie poszczególnych klas z wykorzystaniem zwiazków asocjacji; zidentyfikowanie oraz nazwanie atrybutów i operacji; wyspecyfikowanie asocjacji z użyciem wszytskich jej cech (nazw, ról, nawigacji, liczebności, agregacji, kwalifikacji); opracowanie innych rodzajów zwiazków (uogólnień, zależności i realizacji); pełne, precyzyjne wyspecyfikowanie atrybutów i operacji; opcjonalne opracowanie diagramów obiektów.

104 Diagram klas Koniec wykładu 3

105 Diagram klas Bibliografia Włodzimierz Dąbrowski, Andrzej Stasiak, Michał Wolski, Modelowanie systemów informatycznych w języku UML 2.1 Wojciech Olejniczak, Zdzisław Szyjewski, Inżynieria systemów informatycznych w e-gospodarce. Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów informatycznych. Tańska Halina, Analiza sytsemów informatycznych. Kisielnicki J., Sroka H., Systemy informacyjne biznesu. Informatyka dla zarządzania, Placet, Warszawa 2005