Programowanie aplikacji WWW.

Robert Plebaniak

14 kwietnia 2014

Warunkiem zalicznia przedmiotu jest:

• uzyskanie pozytywnej oceny z wykładowego projektuzespołowego (no przedostatnich ćwiczeniach);

• uzyskanie pozytywnej oceny z autoprezentacji na ćwiczeniach;

• uzyskanie minimum 12 pkt z obecności na ćwiczeniach (1 pktza obecność na jednych ćwiczeniach).

Zagadnienia do autoprezentacji1. Tworzenie diagramów ERD - dobra baza podstawą dobrej

apliakcji.2. Layaut strony - podstawy HTML i PHP, przekazywanie dancyh

pomiędzy stronami;3. Wspólpraca PHP i MYSQL - modyfikacja danych z poziomu

strony;4. Obiektowość w Php - przykłady klas, zastosowania;5. Sesje, cookies, logowanie na stronę, szyfrowanie haseł;6. Galerie na stronach - gotowe komponenty, własne pomysly;7. Funkcje systemu operacyjnego i dostęp do plików,

automatyczne generowanie plików;8. Glosowania z wykorzystaniem stron WWW - zasady

programowania;9. Liczniki i kalendarz na stronach;10. Zastosowanie Framework’ów w programowaniu stron WWW -

przykłady, konfiguracja;11. HTML 5 nowe znaczniki;12. Wprowadzenie do jQuery;13. Tabele jQuery;

Model i jego własności

Czym jest model?

• modele są budowane w celu lepszego zobrazowania istniejącychlub przyszłych systemów;

• model nigdy nie będzie w pełni odpowiadał rzeczywistości;

• modelowanie jest nierozerwalnie związane z uwypuklaniempewnych cech i pomijaniem innych;

• nie ma uniwersalnej odpowiedzi na pytanie o to, co wyróznić aco pominąć.

Model i jego własności

Model systemu realizuje następujące zadania:

• opisanie modelu komunikacji i powiązań między elementamisystemu;

• zobrazowanie przebiegu wszystkich procesów z punktu widzeniaklientów, specjalistów i użytkowników;

• weryfikacja faktów pod kątem kompletności spójności ipoprawności;

Cel i grupa docelowa

Aby zdefiniować grupę docelową, szukamy odpowiedzi nanastę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ę iinterpretację modelu?

• Jezyk definiowania modelu:• ogólnie występująca terminologia (mniejsza precyzja, alewiększe grono odbiorców);

• terminologia specjalistyczna (duża precyzja, ale znaczącozawężony krąg odbiorców);

• przykład: butelkę z woda można oznaczyć za pomocą „falek,napisu „WODA lub pisząc H20.

Proces analizy

Proces analizy składa się z faz:

• pozyskiwania informacji od dostawców wiedzy;

• reprezentowania (specyfikowanie);

• weryfikacji.

Proces analizy

W procesie analizy i poznawania procesów biznesowych pomocnebywaja 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 wszystkichzaangażowanych grup;

• prowadzenie dyskusji z ekspertami;

• analiza istniejących formularzy, dokumentacji, specyfikacji inarzędzi pracy;

• opisywanie struktury organizacyjnej i zasad przepływuinformacji.

Ź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ścizbliżonej do modelowanego systemu lub związanej z nim;

• klienci;

• eksperci w analizowanej dziedzinie;

• niezależni obserwatorzy.

Podstawowe pojęcia

Informacja - rodzaj zasobów, danych, pozwalający na zmniejszenieniepwewności, nieokreśloności, czyli na zwiększenie naszej wiedzy.

System informatyczny (system przetwarzający informacje ) - jestto zbiór powiązanych ze sobą elementów, którego funkcją jestprzetwarzanie informacji.

System informacyjny - można określić jako posiadającą wielepoziomów strukturę pozwalającą użytkownikowi na przetwarzanie,za pomocą procedur i modeli, informacji wejściowych w wyjściowe.

System informatyczny

Na systemy informatyczne składają się:

• sprzęt - obecnie głównie komputery ( można wymienić tutakże: urządzenia służące do przechowywania informacji,urządzenia służące do komunikacji między sprzętowymielementami systemu, urządzenia służące do komunikacji międzyludźmi a komputerami, urządzenia służące do odbieraniainformacji ze świata zewnętrznego ( nie od ludzi ), i inne;

• oprogramowanie;

• zasoby osobowe;

• elementy organizacyjne - czyli procedury korzystania z systemuinformatycznego, instrukcje robocze itp.

• elementy informacyjne; bazy wiedzy - ontologiedziedziny/dziedzin w której używany jest system informatyczny.

System informacyjnySystem informacyjny danej organizacji oznaczmy przez SI. Wówczas

SI = {P, I ,T ,O,R,M},

gdzie:

• P - zbiór podmiotów, które są użytkownikami systemu;

• I - zbiór informacji o sferze realnej czyli o jej stanie izachodzących w niej zmianach a więc tzw. zasobyinformacyjne;

• T - zbiór narzędzi technicznych stosowanych w procesiepobierania, przesyłania, przetwarzania, przechowywania iwydawania informacji;

• O - zbiór rozwiązań systemowych stosowanych w danejorganizacji, a więc stosowana formuła zarządzania (podsystemzarządzania);

• M - zbiór metainformacji, czyli opis systemu informacyjnego ijego zasobów informacyjnych;

• R - relacje między poszczególnymi zbiorami.

System informacyjny a informatyczny

Wniosek:

System informacyjny - domena człowieka;

System informatyczny - domena maszyny.

Podejscie strukturalne i obiektowe

Analizę oraz projektowanie systemów informatycznych zdominowałydwa podejścia:

• podejście strukturalne;

• podejście obiektowe.

Lata 80-te XX-ego wieku to okres szczególnej dominacji podejściastrukturalnego, które zaowocowało wieloma metodykamiwypracowanymi przez środowiska naukowe i biznesowe. Mimo różnicmiędzy nimi, istniało wiele punktów, kategorii i mechanizmówwspólnych, co stanowiło podstawę dalszego rozwoju. Do tychwspó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.

Unifikacja

Inicjatywy unifikacyjne mające na celu uporządkowanie wiedzy iprocedur modelowania systemów informatycznych:

• podjęta przez International Federation of InformationProcessing (IFIP), w postaci grupy roboczej CRIS(Comparative Review of Information SystemsMethodologies);

• podjęta przez Unię Europejską w ramach zespołureprezentującego autorów metodyk używanych w różnychkrajach członkowskich pod nazwą EuroMethod.

Podejscie obiektowe

Od początku lat 90-tych w centrum zainteresowania twórców iużytkowników systemów znalazły się modele obiektowe. Wzrostznaczenia obiektowości stymulowany był przez:

• wyzwania postępu technologicznego w informatyce, corazbardziej powszechne użytkowanie systemów czasurzeczywistego i systemów wbudowanych;

• różnorodność i powszechność aplikacji internetowych wgospodrace opartej na wiedzy, czyli w takich dziedzinach jake-business, e-health, e-government, e-learning;

• multimedialny charakter aplikacji, wykorzystujących w corazwiekszym 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ówinformatycznych - w telekomunikacji, transporcie, turystyce,bankowości, edukacji.

Podejście obiektowe

Podejście obiektowe ma obecnie największe znaczenie wnastępujących zastosowaniach:

• metodykach tworzenia oprogramowania (przede wszystkimRational Unified Process);

• graficznych jezykach ogólnego przeznaczenia (UML);

• objektowych językach programowania (JAVA, platforma.NET);

• bazach danych (np. Object Store).

Główne pojęcia podstawowego modelu obiektowego

Objekt (and. object) - każdy byt - pojęcie lub rzecz - mającyznaczenie w kontekście rozwiązywania problemu w danej dziedzinieprzedmiotowej.Klasa (and. class) - uogólnienie zbioru obiketów, które mają tesame atrybuty, operacje, związki i znaczenie.Komunikat (and. message) - specyfikacja wymiany informacjimiędzy obiektami, zawierająca zlecenia wykonania określonejoperacji.

Główne pojęcia podstawowego modelu obiektowego

hermetyzacja (and. encapsulation) - różnicowanie dostępu doobiektu poprzez ujawnienie otoczeniu tylko tych informacji o jegoatrybutach lub operacjach, które są niezbędne do efektywnegoodwoływania się do obiektu w systemie za pośrednictwemkomunikatów.polimorfizm (and. polymorphism) - możliwość nadawania tejsamej nazwy różnym atrybutom i operacjom oraz wykonywaniaróż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 ioperacji klasom obiektów na podstawie hierarchicznej zależnościmiędzy nimi. Możliwe jest wielokrotne dziedziczenie, co oznacza, żedana klasa dziedziczy atrybuty i operacje z dowolnej liczby klasnadrzędnych.

UML - geneza i ewolucja

UML - ujednolicony język modelowania systemów informatycznych(and. Unified Modeling Language).Modelowanie systemów informatycznych obejmuje aspektyfunkcjonalne oraz niefunkcjonalne. Możliwość ich modelowania byłai nadal jest motywem ewolucji języka UML, którego kolejne wersjesą wzbogacane o nowe kategorie, będące odpowiedzią nawymagania twórców systemów informatycznych stawiane metodom itechnikom modelowania. Załóżenia autorów języka UML wykraczałypoza dokonanie prostej kompilacji.

UML - geneza i ewolucja

Język modelowania systemów informatycznych pośredniczy międzyludzkim rozumieniem funkcjonowania programów komputerowych aich fizyczną realizacją w postaci kodu źródłowego. Stąd język takipowinien jednocześnie:

• w sposób ścisły definiować podstawowe i zaawansowanekategorie oraz zasady modelowania obiektowego;

• umożliwiać dostosowywanie wykorzystywanej semantyki inotacji do rozwiązywania szerokiego spektrum problemów;

• wykazywać elastyczność wystarczającą do modelowania, oboksystemów oprogramowania, także systemów biznesowych;

• wykazywać daleko posuniętą niezależność od konkretnychjęzyków programowania oraz metodyk tworzenia systemówinformatycznych;

• uwzględniać skalę realizowanych współcześnie projektów,związanych z bardzo rozbudowanymi systemami o kluczowymznaczeniu dla funkcjonowania przedsiębiorstw.

Kalendarium

• październik 1994 - zapoczątkowano pracę nad UML (J.Rumbaugh, G. Boochem UM 0.8, Unifed Method )

• styczeń 1997 - powstanie wersji UM 1.0 -wersja przekazanajako propozycja standardu organizacji OMG (ObjectManagment Group)

• lipiec 1997 - korporacja Rational przedstawia kolejnapropozycję UML-a w wersji 1.1, również przekazaną do OMG

• kwiecień 1999 - OMG RFT publikuje kolejną wersje UML 1.4

• wrezsień 2002 - pojawia się wersja 1.5 (wersja nieoficjalna)

• sierpień 2003 - zaprezentowana zostaje wersja 2.0.

Diagramy UML

Język UML przyjmuje w praktyce postać graficznej reprezentacjitworzonego 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.

Diagramy abstrakcyjne

Diagramy abstrakcyjne są jedynie nazwami uogólniającymi grupydiagramów konkretnych. Do tej kategori zalicza się:

• diagramy struktury;

• diagramy dynamiki;

• diagramy wdrożeniowe;

• kategorię diagramów UML.

Diagramy konkretne

Do diagramów konkretnych zalicza się:

• diagram klas (ang. Class Diagram) - kls (cld) - diagram klas tograficzne przedstawienie statycznych, deklaratywnychelementów dziedziny przedmiotowej oraz związków międzynimi;

• diagram obiektów (Object Diagram) - obk (od) - diagramobiektów to wystąpienie diagramu klas, odwzorowującestrukturę systemu w wybranym momencie jego działania;

• diagram pakietów (ang. Package Diagram) - pkt (pd) -diagram pakietów to graficzne przedstawienie logicznejstruktury systemu w postaci zestawu pakietów połączonychzależnościami i zagnieżdżeniami;

Diagramy konkretne

• diagram struktur połączonych (ang. Composite StructureDiagram) - spl (csd) - diagram struktur połączonych tograficzne przedstawienie wzajemnie współdziałających częścidla 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żkamikomunikowania węzłów z ulokowanymi na nich artefaktami;

Diagramy konkretne

• diagram przypadków użycia (ang. Use Case Diagram) - uzc(ud) - diagram przypadków użycia to graficzne przedstawienieprzypadkó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) - diagramczynności to graficzne przedstawienie sekwencyjnych i (lub)współbieżnych przepływów sterowania oraz danych pomiędzyuporządkowanymi ciągami czynności, akcji i obiektów;

• diagram maszyny stanowej (ang. State Machine Diagram) -stn (sm) - diagram maszyny stanowej to graficzneodzwierciedlenie dyskretnego, skokowego zachowaniaskończonych systemów stan-przejście;

Diagramy konkretne

• diagram sekwencji (ang. Sequence Diagram) - skw (sd) -diagram sekwencji jest rodzajem diagramu interakcji,opisującym interakcjie pomiędzy instancjami klasyfikatorówsystemu w postaci sekwencji komunikatów wymienianychmiędzy nimi;

• diagram komunikacji (Communication Diagram) - kmn (cd) -diagram komunikacji jest rodzajem diagramu interakcji,specyfikującym strukturalne związki pomiędzy instancjamiklasyfikatorów biorącymi udział w interakcji oraz wymianękomunikatów pomiędzy instancjami;

• diagram harmonogramowania (ang. Timing Diagram) - hrm(tm) - diagram harmonogramowania jest rodzajem diagramuinterakcji, reprezentującym na osi czasu zmiany dopuszczalnychstanów, jakie może przyjmować instancja klasyfikatorauczestnicząca w interakcji;

Diagramy konkretne

• diagram sterowania interakcjią (ang. Interaction OverviewDiagram) - sin (iod) - diagram sterowania interakcją jestrodzajem diagramu interakcji, dokumentującym przepływsterowania pomiędzy logicznie powiązanymi diagramami ifragmentami interakcji z wykorzystaniem kategoriimodelowania diagramów czynności.

Klasyfikator i Instancja

Specyfikacja języka UML wprowadza pojęcie klasyfikatora (ang.classifier), które ma zastosowanie w odniesieniu do praktyczniekażdego rodzaju diagramu języka UML 2.0.

• Klasyfikator - to abstrakcyjna kategoria modelowania systemuw języku UML, która uogólnia kolekcję instancji o tych samychcechach.

Na konkretnych diagramach języka UML zamieszcza się instancjeposzczególnych rodzajów klasyfikatorów.

• Instancja - jest wystąpieniem, egzemplarzem klasyfikatora.

W języku UML 2 funkcjonuje również pojęcie klasyfikatoraustrukturyzowanego (ang. structured classifier).

• Klasyfikator ustrukturyzowany zawiera specyfikacjęwewnetrznej struktury.

Prezentacja diagramów

Diagram może być prezentowany w postaci obramowanej inieobramowanej. Każdy diagram w postaci obramowanej zawieranagłówek, o następującej składni:<nagłówek-diagramu>::=[<rodzaj>] <nazwa> [<parametry>]gdzie,

• rodzaj - pełny lub skrótowy wyróżnik diagramu zawartego wramie;

• nazwa - syntetyczna nazwa odzwierciedlająca merytorycznązawartość diagramu;

• parametry - szczegółowe parametry kluczowe dla danegodiagramu.

Perspektywy w opisie architektury systemu

Metodyka RUP proponuje pięć perspektyw architektury systemuinformatycznego:

• perspektywa przypadków użycia - kluczowa i dominująca wobecpozostałych, definuje zakres i oczekiwaną funkcjonalnośćtworzonego systemu;

• perspektywa dynamiczna - wskazuje, w jaki sposób jestrealizowane zachowanie instancji klasyfikatorów w systemie;

• perspektywa logiczna - dokumentuje statystyke systemu;

• perspektywa komponentów - przeznaczona głównie dlaprogramistów, specyfikuje oprogramowanie na poziomiekomponentów;

• perspektywa rozlokowania - specyfikuje sprzęt informatycznyniezbędny do funkcjonowania konkretnych komponentówsystemu.

Koniec wykładu 1

Diagramy przypadków użycia

Znaczenie diagramów przypadków użycia

Diagram przypadków użycia to graficzne przedstawienieprzypadkó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 zaprezentowanana 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).

Zadania diagramów użycia:

Daigramy przypadków użycia:

• identyfikują oraz dokumentacją wymagania;

• umożliwiają analizę obszaru zastosowań, dziedzinyprzedmiotowej;

• pozwalają na opracowanie projektu przyszłego systemu;

• stanowią przystępną i zrozumiałą paltformę komunikacji iwspół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 dozakresu i funkcjionalności przyszłego systemu;

• stanowią podstawę testowania funkcji systemu na dalszychetapach jego cyklu życia.

Podstawowe kategorie pojęciowe

Diagramy przypadków użycia zawierają następujące kategoriepojęciowe:

• Przypadki użycia - to specyfikacja ciągu akcji i ich wariantów,które system (lub inna jednostka) może wykonać poprzezinterakcje z aktorami tego systemu.

• Aktor - jest to spójny zbiór ról odgrywanych przezużytkowników przypadków użycia w czasie interakcji z tymprzypadkiem użycia.

• Związek - stanowi semantyczne powiązanie pomiędzyelementami modelu.

Przypadek użycia

Przypadek użycia (ang. use case) jest kompleksowym działaniemrealizowanym w systemie w konsekwencji określonej aktywnościaktora. Zakres danego przedsięwzięcia determinowany jest przezzestaw wszystkich wzajemnie powiazanych przypadków użycia.Notacja przypadków użycia

Aktor

Aktorzy mogą być osobowi lub nieosobowi. Role aktora osobowegomoże pełnić osoba, zespół, dział, organizacja. Aktoramianieosobowymi zaś są systemy zewnętrzne (podsystemy, bazydanych), urządzenia oraz czas.

AktorNotacja aktorów:

Związek

Każdy aktor umieszczony na diagramie przypadków użycia powinienbyć bezpośrednio powiązany z co najmniej jednym przypadkiemużycia. Każdy przypadek użycia użytkowany jest przez co najmniejjednego aktora, chociaż niejednokrotnie nie są to powiązaniapośrednie. W diagramach języka UML wyróżnić można czteryrodzaje związków:

• asocjację jest związkiem pomiędzy dwoma lub więcejklasyfikatorami, opisującym powiązania pomiędzy ichinstancjami;

• uogólnienie;

• zależność;

• realizację.

Asocjacja

W diagramach przypadków użycia asocjacja wskazuje domyślnie nadwukierunkową komunikację pomiędzy aktorem a przypadkiemużycia. Nie jest ona oznaczeniem konkretnego przepływu, np.dokumentów Może ona dodatkowo występować w formie zewsakzanym kirunkiem nawigacji.

DPU

Granica obszaru zastosowań

Granica obszaru zastosowań reprezentuje zakres funkcjonalnyprzyszłego systemu. Aktorów komunikujących się z systememumieszcza się poza granicą obszaru zastosowan. W celu zaznaczeniagranicy obszaru zastosowań przyszłego systwemu, jego dziedzinyprzedmiotowej, można wprowadzić prostoką grupujący przypadkiuzycia. Zawiera on tytuł określający nazwę analizowanej dziedzinyprzedmiotowej.

Składniki diagramu

Do zaawansowanych koncepcji diagramów przypadków użycia należyzaliczyć:

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

Rozbudowa DPU poprzez róznicowanie związków

Związki asocjacji występują wyłącznie pomiędzy aktorami aprzypadkami użycia. Pozostałe rodzaje związków (zależności,uogólonienia i realizacji) pozwalają pokazać, w jakich relacjachznajduja się poszczególne przypadki użycia. Ponadto związkiuogólnienia umożliwiają udokumentowanie relacji pomiędzyaktorami.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 logiczniepowiązanych diagramów. Porządkującą rolę może tu odegraćdiagram pakietów. Szczególone możliwości rozbudowywaniadiagramów przypadków użycia stawrzają zależności (ang.dependencies).Zależności to taki związek pomiędzy dwoma elementamimodelowania, w którym zmiana jednego z nich, niezależnego,wpływa na drugi, zależny.

Zależność zawieraniaZależność zawierania «include» przedstawia powiązanie pomiędzyprzypadkiem zawierającym, tj. bazowym przypadkiem użycia, aprzypadkiem zawieranym. Jest to związek obligatoryjny. Zawieranyprzypadek uzycia nie jest wykonywany samodzielnie, ale wyłącznieprzy odwołaniu sie do większego, zawierającego przypadek użycia.Zależność zawierania jest skierowana od przypadku zawierającego dozawieranego.

Zawieranie

Zależność rozszerzaniaZależność rozszerzania «extend» przedstawia powiązanie pomiędzyrozszerzanym przypadkiem użycia, tj. przypadkiem bazowym, aprzypadkiem rozszerzającym. Związek ten ma charakter opcjonalny.Funkcjonalność reprezentowana przez rozszerzający przypadekuzycia może, ale nie musi zostać włączona do rozszerzanegoprzypadku użycia. Zależność rozszerzania jest skierowana odprzypadku rozszerzającego do rozszerzanego.

Uogólnienie

Rodzaje zależności

Zależność rozszerzania

Dodatkowa funkcjonalność zawarta w przypadkach rozszerzającychnie jest wykonywana automatycznie. Przypadek bazowy może byćrozszerzany o przypadki rozszerzające po spełnieniu określonychwarunków. warunki te określa się w przypadku bazowym jakomiejsca rozszerzania bądź punkty rozszerzania (ang. extensionpoints). Po wykonaniu wszelkich działań związanayxch zrozszerzeniem kontynuowane są działania należace do przypadkubazowego.

Miejsca rozszerzenia

Uogólnienia

Uogólnienie to związek o charakterze taksonomicznym pomiędzyklasyfikatorem ogólnym a specjalizowanym. Element specjalizowany,z założenia dziedziczy wszelkie cechy elementu ogólnego.

Hierarchia dziedziczenia

Rodzaje aktorów

Język UML jest elastyczny i umożliwaia wprowadzanie nowych pojęćoraz oznaczeń zwanych stereotypami. Notacja aktorów może wszczególności przybierać postać stereotypów graficznych. I takuzasadnione jest wyróznienie czterech rodzajów aktorów:

• ludzi oraz zespołów;

• systemów zewnętrznych;

• urządzeń;

• czasu.

Rodzaje aktorów

Liczebność

Nawigacja

Realizacja

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

Realizacja

Konwencja CRUD

Konwencja CRUD obejmuje:

• CREATE - tworzenie, wprowadzanie;

• READ - odczytywanie;

• UPDATE - aktualizacja, modyfikowanie;

• DELETE - usuwanie, skreślenie.

Diagram kontekstowy

Diagram kontekstowy stanowi zestawienie aktorów będących winterakcji z danym systemem traktowanym w kategoriipojedynczego procesu.Diagramy te, mogą się okazać pomocne w identyfikacji zbiorowościaktorów przed sporządzeniem pełnego diagramu DPU.

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. Dladanego przypadku użycia zawsze należy wyróznić:

• scenariusz główny;

• scenariusz alternatywny.

Scenariusze mogą przybierać postać: niesformalizowanego tekstu;formalnego tekstu strukturalnego; pseudokodu; tabeli.

Dokumentacja przypadków użycia

Dokumentacja szczegółowo opisuje główny scenariusz przypadkuużycia oraz wskazuje alternartywne przepływy zdarzeń. Do jejważnych elementów należą także:

• warunek wstępny;

• warunek końcowy.

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 doopracowania diagramu przypadków użycia;

6. udokumentowanie przypadków użycia z wykorzystaniemszablonów.

Koniec wykładu 2

Znaczenie diagramu klas

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

Podstawowe kategorie pojęciowe

Diagramy klas zawierają następujące kategorie pojęciowe:

• Obiektem - jest każdy byt - pojęcie lub rzecz - mającyznaczenie w kontekście rozwiązywania problemu w danejdziedzinie przedmiotowej.

• Klasa - jest uogólnieniem zbioru obiektów, które mają takiesame atrybuty, operacje, związki i znaczenie.

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ść jednoznacznegowyodrębnienia obiektu ze zbiorowości innych obiektów, nawet gdywszystkie wartości przechowywane przez obiekty są identyczne.

Klasa

Podstawę identyfikacji klasy stanowią grupy obiektówcharakteryzujace się:

• identyczną strukturą danych;

• identycznym zachowaniem;

• identycznymi związkami;

• identycznym znaczeniem w określonym kontekście.

Klasa

W diagramach klasę standardowo przedstawia się jako prostokątzłożony z trzech sekcji:

• nazwy klasy;

• zestawu atrybutów;

• zestawu operacji.

KlasaGraficzna prezentacja klas

Liczba sekcji w klasie

Liczbę sekcji w każdej klasie można zwiększać, dodając na przykładsekcje zawierające zobowiązania bądź wyjątki. Sekcje te możnadodawać opcjonalnie w przypadkach, gdy jest to niezbędne dlapodniesienia precyzji diagramu 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.

AsocjacjaAsocjacji opisuje zbiór powiązań pomiędzy obiektami. Wyróżnia siędwa rodzaje asocjacji:

• asocjacja binarna - dominująca w praktyce;

• asocjacja n-arna.

Asocjacje n-arne

Pełna semantyczna interpretacja związku wymaga wprowadzeniaszeregu dodatkocwych elementów opisu. Asocjację możnasprecyzować poprzez określenie następpujących cech:

• nazwy;

• ról powiązancyh klas;

• nawigacji;

• liczebności;

• agregacji.

Nazwy asocjacji

Asocjacje mogą być:

• nienazwane;

• nazwane, z opcjonalnym zamieszczeniem znacznikawskazującego kierunek interpretacji asocjacji;

• scharakteryzowane poprzez role klasy pełnione w asocjacji;

• nazwane i równocześnie scharakteryzowane przez role.

Role i nawigacjaAsocjacje można interpretować dwustronnie poprzez podanie ról(ang. roles) pełnionych przez powiązane ze sobą klasy. Nazwy rólumieszcza się po obydwu stronach asocjacji. Rola spełniana przezdaną klasę lokowana jest bezpośrednio przy klasie określonej.Dla asocjacji istniejącej pomiędzy klasami komunikowanie domyślnieodbywa się w obydwu kierunkach. Jest to nawigacjadwukierunkowa. W praktyce wystepują sytuację, w którychwskazanie kierunku nawigacji zwiększa efektywność komunikowaniasię. Mamy wtedy sytuację nawigacji jednokierunkowej.

Agregacja

Agregacja opisuje związek całość-część pomiędzy klasami.Wyróżnia się dwa rodzaje agregacji:

• agregację całkowitą - kompozycję (inne nazwy: agregacjasilna lub składowa);

• agregację częściową (inne nazwy: agregacja słaba lubwspółdzielona).

W obu rodzajach agregacji występują dwa pojęcia:

• agregat - obiekt stanowiący całość;

• segment - część.

Agregacja całkowitaW przypadku agregacji całkowitej obiekty-segmenty będąceczęściami agregatów nie mogą samodzielnie i niezależniefunkcjonować. Usunięcie agregatu powoduje automatycznąlikwidację wszystkich segmentów będących jego częściami.

Agregacja częściowaAgregacja częściowa wskazuje na asocjację, w której usunięcieobiektu będącego agregatem nie powoduje likwidacji obiektówbędących jego częściami, czyli obiektów-segmentów. Obiektywspółdzielone mogą zatem funkcjonować samodzielnie, niezależnieod agregatu.

Diagram klas z uwzględnieniem agregacji

Zaawansowane składniki diagramu

Diagram klas charakteryzuje się znaczną liczbą zaawansowanychelementó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ę.

Rodzaje diagramów klas

Poziomy tworzenia diagramów klas:

• poziom konceptualny;

• poziom implementacyjny.

Konceptualny diagram klas zawiera wyłącznie podstawoweelementy, cechując się przystępnością nazewnictwa klas, atrybutów ioperacji.Implementacyjny diagram klas jest stopniowo wzbogacany oelementy opisu niezbędne dla prawidłowej specyfikacji modelu, takiejak: typy danych, zobowiązania, widoczności, statyczność, klasyasocjacyjne, kwalifikacje, uogólnienia, zależności czy też realizacje.

ZobowiązaniaSpecyfikacja zobowiązań pełni rolę pomocniczą w procesieprojektowania diagramów klas, gdyz dostarcza wysokopoziomowegoopisu zadań poszczególnych klas. Klasy ze zobowiązaniami są wnaturalny 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).

Widoczność

Istnieją zróżnicowane wymagania względem dostępu doposzczególonych atrybutów i operacji różnych klas w systemie.Cechę widoczności oznacza poziom dostępności atrybutów ioperacji inncyh klas.

Poziom Symbol Charakterystyka

Publiczny + obiekty wszystkich klas mają dostęp doatrybutu lub operacji

Prywatny − tylko obiekty danej klasy mają dostep doatrybutu operacji

Chroniony ] wyłącznie obiekty klas dziedziczących z danejklasy mają dostep do atrybutu lub operacji

Pakietowy ∼ tylko składowe pakietu, do którego dana klasanależy mają dostep do atrybutu lub operacji

Atrybuty i operacje statyczne

Wszystkie instancje danej klasy mogą przechowywać pewne stałe,identyczne wartości - np. rodzaj waluty, operację tworzenia lubusuwania, stały mnożnik. W przypadku zmiany takiej wartości wjednym obiekcie zmiana ta jest automatycznie wprowadzana winnych obiektach tej klasy.Atrybuty i operacje mogą być:

• egzemplarzowe - indywidualne dla każdego obiektu danej klasy;

• statyczne - identyczne we wszytskich obiekatch klasy.

Nazwy klas, atrybutów i operacji

Atrybut lub operacja Nazwa na poziomie Nazwa na poziomiekonceptualnym implementacyjnym

pojemność kart SIM Pojemność Karty pojemnośćKartyadres salonu Adres Salonu adresSalonunumer telefonu Nr Telefonu Komór. nrTelefonuKomór.komórkowego

zablokowanie karty SIM Zablokuj Kartę zablokujKartę()zmiana aktualnych stawek Zmień Stawki Taryf zmieńStawkiTaryf()wszytstkich taryfwysyłanie krótkiej Wyślij SMS wyślijSMS()wiadomości tekstowej

Notacja atrybutów i składnia operacji

Typ danych Narzędzie Rational Rose Platforma .NET

Logiczne Boolean BooleanStałoprzecinkowe Byte Byte

Integer ShortLong Integer

LongZmiennoprzecinkowe Single Single

Double DoubleDecimal

Znakowe String StringChar

Inne Date DateObject ObjectCurrencyVariant

Notacja atrybutów i składnia operacji

Notacja atrybutów na poziomie implementacyjnym charakteryzujesię 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ślenie-wartości>”}”].

Analogicznie również dla operacji isnieje formuła składniowa:

<operacja>::= [<widoczność>] <nazwa-operacji>[”(”<lista-parametrów)”]”][”:”<określenie-właściwości>].

Notacja atrybutów i składnia operacji

OpcjaFinansowapremiaOpcyjna: Single = 10 000wilekośćKontraktu: Double = 1000000tick: %=0,01wartośćTicku: Byte = 25liczTicki(cenaSprzedaży : Double, cenaNabycia :Double) :Singlerealizuj(ilośćTicków :Single, wartośćTicku :Byte, ilośćKontraktów :Integer):Double

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łyobliczeniowej, która korzysta z wartości innych atrybutów nadiagramie klas. Formuła zazwyczaj jest zapisywana jako notatkaodnosząca się do atrybutu pochodnego.

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

Asocjacje zwrotne i wielokrotnePowią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 ztych asocjacji winna być nazwana lub scharakteryzowana napodstawie ról.

Asocjacje zwrotne i wielokrotne

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

KwalifikacjaKwalifikacja 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ściporządkujązbiór obiektów tej klasy występujących w danej asocjacji.

Uogólnienia, klasy abstarkcyjne oraz konkretneW 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ówkonkretnych 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.

Uogólnienia, klasy abstarkcyjne oraz konkretne

Związkom uogólnienia, występującym pomiędzy klasami obiektówznajdujących się w danej hierarchii klas, przypisać można czterypodstawowe ograniczenia. Obejmują one:

• {complete} - zawiera pełen zestaw podklas dla danej klasy;

• {incomplete} - oznacza, że zestaw podklas przypisanych danejklasie nie jest pełen, wiadomo, że istnieje więcej klasspecjalizowanych nie mających istotnego znaczenia wrozpatrywanym kontekście;

• {disjoint} - domyślny rodzaj uogólnienia, oznaczający, że każdapodklasa w hierarchii klas posiada tylko jedna klasębezpośrednio nadrzędną (jest rozdzielona);

• {overlapping} - oznacza, że w hierarchi klas określone klasymogą mieć wspólne podklasy (dziedziczenie wielokrotne).

Uogólnienia, klasy abstarkcyjne oraz konkretneDyskryminator (ang. generalization set) jest określeniem kryteriumdokonania klasyfikacji w uogólnieniu. Na ogół jest to kryteriumdomyślne, lecz można je wyrazić nie wprost. Dyskryminator stwarzamożliwość systematyzowania związków uogólnień.

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

RealizacjaKlasy mogą brać udział w związkach realizacji - jedna strona tegozwią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 oferowaneprzez klasę lub komponent.

Diagramy obiektów

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

Proces tworzenia diagramu klas

W procesie tworzenia diagramu klas wyróżnic można nastepująceetapy:

• zidentyfikowanie i nazwanie klas;

• opcjonalne określenie zobowiązań klas;

• połączenie poszczególnych klas z wykorzystaniem zwiazkówasocjacji;

• 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 irealizacji);

• pełne, precyzyjne wyspecyfikowanie atrybutów i operacji;

• opcjonalne opracowanie diagramów obiektów.

Koniec wykładu 3

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ówinformatycznych w e-gospodarce.

Stanisław Wrycza, Bartosz Marcinkowski, KrzysztofWyrzykowski, Język UML 2.0 w modelowaniu systemówinformatycznych.

Tańska Halina, Analiza sytsemów informatycznych.

Kisielnicki J., Sroka H., Systemy informacyjne biznesu.Informatyka dla zarządzania, Placet, Warszawa 2005