Najbardziej popularną metodologią tworzenia

obiektowychobiektowych modeli systemów informatycznych (przydatną

szczególnie na etapie ich projektowania) jest język

UMLUMLi związana z nim i związana z nim metodologiametodologia

MetodologiaMetodologia wspomaga modelowanie dziedziny problemowej

stanowiącej przedmiot projektowanego systemu.

MetodologiaMetodologia dostarcza szeregu pojęć, modeli, diagramów, języków,

technik i sposobów postępowania.

MetodologiaMetodologia jest wykorzystywana zarówno do projektowania

pojęciowego, jak i logicznego czy fizycznego.

Metodologia ustala fazy realizacji projektu, a ponadto dla każdej z faz projektu

wyznacza:

1. role uczestników projektu;

2. scenariusze postępowania;

3. reguły przechodzenia do następnej

fazy;

4. modele, które powinny być

wytworzone;

5. dokumentację, która powinna powstać;

6. notację, którą należy używać.

Proces projektowania systemu informatycznego polega na kolejnym tworzeniu

i wzajemnym przekształcaniu wielu modeli

Światrzeczywisty

Analizawymagań

Modelowaniekoncepcyjne

Modelowanielogiczne

Modelowaniefizyczne

System bazydanych

Modelowanieschematów

Integracjaschematów

Ilość danych, użycie,analiza integralności

Decyzjeimplementacyjne

Etapy tworzenia modeli systemuDiagramyzwiązków

encji

Uzgodnienie

Działalnośćorganizacyjna

Istniejąca bazadanych

Normalizacja

Schemat logiczny

Przejście od modelu do fizycznej realizacji systemu

Analiza ilości danych iużycia

Schemat logiczny Schemat fizyczny

Create Table <>(…)

Create Table <>(…)

Create Table <>(…)

Create Table <>(…)

Podczas projektowania systemu informacyjnego ważną rolę odgrywa notacja

Notacja służy do dokumentowania wyników poszczególnych faz projektu, zarówno pośrednichjak i końcowych.

Notacja wspomaga ludzką pamięć i wyobraźnię.

Właściwa notacja ułatwia komunikację zarówno między członkami zespołu projektowego, jak i między zespołem projektowym a klientem.

Notacja jest ważnym elementem metodologii.

Kiedy notacja nie jest “Kiedy notacja nie jest “tą właściwątą właściwą” - może ” - może zrodzić wiele problemów!zrodzić wiele problemów!

Notacja stosowana w UML jest notacją graficzną, to znaczy większość elementów

projektów ma charakter rysunkowy

Edycja ciągu

Przeprowadzanieobliczeń

Kontrolaparametrów

Obserwator Operator

Przykład: Tak zwany diagram przypadków użycia symulatora sieci neuronowych

Rysunki mogą obrazować poszczególne elementy projektu z większą albo mniejsza

dokładnością

E d y c ja c ią g u

E d y c ja c i ą g u

E d y c ja c ią g ute s to w e g o

E d y c ja c i ą g uu c z ą c e g o

E d y c ja c ią g u

E d y c ja c i ą g u

E d y c ja c i ą g u

U c z e n ie

T e s to w a n ies i e c i

P r z e p ro w a d z a n ieo b l i c z e ń

E d y c ja c ią g u A n im a c ja w a g

Edycja ciągu

Edycja ciągu

U s ta l a n i ef . a k ty w a c j i

P a r a m e tr yu c z e n ia

K o n t r o l ap a ra m e t r ó w

E d y c ja c ią g u A r c h i te k tu ras i e c i

E d y c ja c i ą g u T r y b p r a c yp r o g r a m u O p e r a t o r O b s e r w a t o r

Przykład: Ten sam diagram co poprzednio z większą liczbąszczegółów

Najczęściej rysunki używane w projektowaniu obiektowym pokazują wzajemne relacje elementów systemu

O B IE KTY S TER U JĄ C E

O K NO G ŁÓ W N E

M O D UŁ O BLIC ZE NIO W Y

K LAS Y B IBLIO TEC ZNE

Niestety funkcjonuje kilka różnych notacji prezentujących te zależności

Bardziej znane wcześniejsze metodologie i notacje obiektowe

Największy wpływ na rozwój metodologii obiektowej miały książki trzech znanych

metodologów: Grady Booch'a, Ivara Jacobsona

i James'a Rumbaugh'a. W książkach tych autorzy opisywali swoje

metodologie nadając im nazwy: Booch - OOADAOOADA (ang.: Object-Oriented Analisis and Design with Aplications),

Jacobson - OOSEOOSE (ang.: Object-Oriented Software Engineering),

Rumbaugh - OMTOMT (ang.: Object Modeling Technique).

Każda metodologia Każda metodologia miała mocne oraz słabe miała mocne oraz słabe

strony.strony. OMT było mocne w

analizie, ale słabsze w projektowaniu.

OOADA na odwrót. Natomiast OOSE było

bardzo dobre w analizowaniu potrzeb

użytkownika, czego nie uwzględniono ani w OMT,

ani w OOADA.

Język UML powstał więc jako

powszechnie powszechnie oczekiwana oczekiwana unifikacjaunifikacja

Historia UML

Przypomnienie: podstawowe pojęcia metodologii obiektowej:

ObiektObiekt (ang.: Object) jest podstawowym pojęciem w podejściu obiektowym. Obiekt reprezentuję sobą konkretny pojedynczy byt.

Obiekt jest charakteryzowany poprzez:identyfikator (nazwę), stan (wartości atrybutów obiektu) orazzachowanie (operacje obiektu).

Zachowanie może zmieniać stan obiektu, od którego pochodzi i/lub stany innych obiektów.

Klasa Klasa (ang.: Class) reprezentuje zbiór obiektów, które dzielą strukturę i wspólne zachowanie.

Klasa a obiektOperacjeOperacje i atrybutyatrybuty są definiowane jednorazowo (w klasie).

O obiektach, które należą do danej klasy, mówi się, że są instancjamiinstancjami tej klasy.

Instancje te zawierają określone własne (czasem nawet określane jako “prywatne”) wartościwartości atrybutów klasy.

Współdzielą one natomiast operacjeoperacje klasy. Zachowanie tych instancji jest więc jednolite.

Klasa i jej instancje

Enkapsulacja

Enkapsulacja jest techniką, w której danedane są przechowywane w obiektach razem z operacjamioperacjami, jakie można na nich wykonać.

W dodatku dane są zazwyczaj chronione wewnątrz “kapsuły” utworzonej z operacji, co oznacza, że dowolny obiekt zewnętrzny może wywołać działanie określonej operacji, natomiast nie może bezpośrednio zmienić (ani nawet odczytać) żadnej wewnętrznej danej.

Jedynym sposobem dotarcia do danych ukrytych wewnątrz obiektu jest użycie operacjiużycie operacji należącej do powłoki kapsuły, która na żądanie wykona stosowną operację na danych.

Eliminuje to ryzykoryzyko niepoprawnego użycia danych obiektu, ponieważ operują na nich zawsze wyłącznie “autoryzowane” własne operacje tegoż obiektu.

Przykład enkapsulowanego obiektu

Polimorfizm Polimorfizm jest techniką, w której ukrywa się

szczegóły implementacji we wspólnym interfejsie. Polimorfizm upraszcza komunikację pomiędzy

obiektami.

Model obiektowy oprócz klas i obiektów uwzględnia związki między

nimi. a. związek zależnościzależności (ang.: Dependency) – oznacza wykorzystanie jednego obiektu przez drugi. Najczęściej dotyczy sytuacji użycia obiektu jako argumentu w operacji obiektu drugiego;

b. związek generalizacjigeneralizacji (ang.: Generalization) – jest relacją między jedną klasą a klasami, które są jej udoskonalonymi wersjami. Klasa, która została udoskonalona nazywa się nadklasą, a każda jej wersja nazywa się podklasą. Każda podklasa dziedziczy cechy swojej nadklasy;

c. związek asocjacyjnyasocjacyjny (ang.: Association) - oznacza grupę więzi o wspólnej strukturze i znaczeniu. Więź z kolei to połączenie, jakie istnieje między instancjami. Najważniejszą z cech tego związku jest jego typ wyróżniony ze względu na liczność wystąpienia instancji w związku.

Typy asocjacji:

jeden do jednegojeden do jednego – instancja może mieć tylko jedną więź w danym związku; jeden do wielujeden do wielu – instancja może mieć wiele więzi w danym związku. Jednak ta instancja, która jest z nią powiązana już nie może mieć więzi więcej niż jedną;

wiele do wieluwiele do wielu – zarówno instancja jak i instancje z nią powiązane mogą mieć wiele więzi w danym związku.

Typy asocjacji:

Specjalne typy asocjacji:AgregacjaAgregacja – jest relacją typu całość-część.

Jeden element składa się z innych elementów.

Agregacja jest relacją antysymetryczną. Oznacza to, że element-całość zawiera elementy-części, lecz elementy-części nie mogą zawierać elementu-całości.

Przykładem tego związku jest relacja między linią a punktami. Linia składa się z punktów. Punkty nie zawierają linii. Ponadto punkt może być współdzielony z wieloma liniami

Specjalne typy asocjacji:KompozycjaKompozycja – jest silniejszą formą agregacji.

W agregacji elementy-części mogą być wykorzystywane przez inne elementy, jednak w kompozycji żaden element-część nie może być dzielony. Często także się dzieję, że z chwilą zniszczenia elementu-całości ulega zniszczeniu element-część.

Przykładem tego związku jest relacją między samochodem a silnikiem. Samochód zawiera silnik. Silnik może być wykorzystywany tylko przez jeden samochód jednocześnie.

Czym jest UML?

UML jest językiem do specyfikacji, wizualizacji, konstrukcji i dokumentowania projektów związanych z systemami informacyjnymi intensywnie wykorzystującymi oprogramowanie, a także do modelowania biznesowego wszelkich innych systemów.

UML oferuje standaryzowany sposób

zapisu projektu, obejmującego zarówno

jego konceptualne aspekty, takie jak procesy

biznesowe czy funkcje systemu, jak też

i elementy fizyczne (np. schematy bazy danych).

UML zapewnia:1. semantykę i notacje dotyczącą szerokiej gamy współczesnych aspektów modelowania;2. semantykę adresującą określone aspekty modelowania, które są przewidywane w przyszłości. Szczególnie chodzi tu o aspekty związane z technologią komponentów, przetwarzaniem rozproszonym, szkieletem (ang.: frameworks) oraz wykonywalnością (ang.: executablility);3. mechanizmy rozszerzalności, tak aby poszczególne zespoły projektowe mogły rozszerzać język dla potrzeb ich aplikacji przy zmniejszonym wysiłku;4. semantykę ułatwiającą wymianę danych modelu pomiędzy wieloma narzędziami CASE.

Istotnymi składnikami UML są diagramy

Wyróżnić możemy między innymi Wyróżnić możemy między innymi następujące następujące ważniejszeważniejsze diagramydiagramy::

•Diagramy strukturalneDiagramy strukturalneDiagram klasDiagram komponentów

•Diagramy behawioralneDiagramy behawioralneDiagram przypadków użyciaDiagram sekwencjiDiagram aktywności

W sumie jednak diagramów używanych w tej metodologii jest

więcej. Pełne zestawienie diagramów wykorzystywanych w UML obejmuje:

•diagram przypadków użycia•diagram klas diagram klas •diagram obiektów •diagram sekwencji

•diagram współpracy•diagram stanów•diagram aktywności•diagram komponentów•diagram wdrożeniowy

diagram klas

obrazuje statyczną strukturę systemu wykorzystując klasy i ich relacje. Jest w gruncie rzeczy centralnym centralnym diagramemdiagramem w rozważanej tu metodologii

Zadania przejmowane i delegowane przez diagram klas

diagram przypadków

użyciaobrazuje sposób w jaki aktorzy (np. ludzie) mogą wykorzystać system.

Jego głównym celem jest odwzorowanie funkcji projektowanego systemu w taki sposób, w jaki będą je widzieć jego użytkownicy;

diagram obiektów

obrazuję statyczną strukturę systemu wykorzystując obiekty (instancje) i ich relacje;

diagram sekwencji

obrazuję kolejność w czasie wysyłania komunikatów pomiędzy różnymi obiektami

w systemie

diagram współpracy

podobnie jak diagram sekwencji, obrazuję przepływ komunikatów pomiędzy obiektami. Uzupełnia jednak ten obraz o statyczną strukturę obiektów. Obrazuję sposób współpracy grupy obiektów w celu zrealizowania określonego celu

diagram stanów

obrazuję stany, w których obiekt może się znaleźć w czasie jego istnienia

diagram aktywności

obrazuję akcje, które są wykonywane (w całości lub częściowo) przez system. Umożliwia zaprezentowanie równoległego wykonywania czynności

diagram komponentów

obrazuję komponenty, które składają się na aplikację, system lub przedsięwzięcie. Przedstawia powiązania między komponentami oraz ich publiczne interfejsy

diagram wdrożeniowy

obrazuję architekturę systemu. Prezentuję sposób rozmieszczenia komponentów w określonej konfiguracji sprzętowej

Zbiorcza charakterystyka diagramów

Związki pomiędzy

diagramami

Tworząc diagramy trzeba zadbać o właściwy stopień ich szczegółowości

Liczba elementów na diagramie powinna być adekwatna do jego celu i odbiorcy.

•Zbyt ubogi diagram nie spełni zamierzonego celu,

•zbyt szczegółowy może przysłonić istotne elementy nawet specjaliście, a już na pewno będzie nie czytelny dla osoby nie zaznajomionej ze standardem.

Do tworzenia modeli systemu informatycznego

wykorzystuję się różnorodne techniki. Poczynając od ołówka i kartki papieru,

a kończąc na zaawansowanych

programach komputerowych. Programy takie zalicza się do

narzędzi CASECASE (ang.: Computer-aided Software

Engineering Tools) wspomagających komputerowo inżynierię

oprogramowania.

Korzystanie z narzędzi CASE do tworzenia modeli w UML’u ma wiele zalet:

1. ponowne wykorzystanie - stworzony model można bez ograniczeń ponownie wykorzystywać. W szczególności, jeśli narzędzie wykorzystuję zaawansowany interfejs graficzny implementujący mechanizmy "przeciągnij i upuść" (ang.: Drag & Drop), można eksportować określone elementy z jednego modelu do drugiego;

2. wiele perspektyw - prezentację gotowego modelu można dostosować do wymaganej sytuacji. Przykładowo można ukrywać określone elementy bez ich usuwania;

Zalety CASE - ciąg dalszy:

3. automatyczne generowanie kodu - zwrot z nakładu pracy poniesionego na stworzenie modelu jest dużo większy, gdy wyeliminowana jest konieczność prostej translacji modelu do kodu w języku programowania. Ponadto automatyczna translacja jest mniej podatna na błędy;

4. sprawdzenie poprawności modelu - zdefiniowane reguły biznesowe i ograniczenia są szybciej i pewniej sprawdzone;

5. szybkie utworzenie modelu przez reinżynierię (ang.: Reverse engineering) - tworzenie modelu ze źródeł programu eliminuję żmudny proces translacji kodu do modelu.

Zestawienie przykładowych narzędzi CASE obsługujących notację UML.

Omówimy teraz prosty przykład opisujący system (hipotetyczny)

mający wspomagać przydzielanie pokoi w akademiku.

Na tym przykładzie zilustrowane będą krok po kroku wszystkie

modele i diagramy języka UML.

Jako pierwszy wygodnie będzie zbudować

diagram aktywności

Jak wiadomo obrazuje on akcje, które są wykonywane

(w całości lub częściowo) przez system. Umożliwia

zaprezentowanie równoległego wykonywania

czynności

Całościowy diagram aktywności: schemat funkcjonowania rezerwacji pokoi w akademikach (fragment)

Przykładowy diagram aktywności drobniejszego fragmentu systemu

(cofnięcie rezerwacji pokoju)

Jako następny zbudujemy diagram przypadków

użycia Służy on do prezentacji

przypadków użycia i aktorów, którzy pozostają

w interakcji z tymi przypadkami.

Najważniejsze jest ujawnienie relacji pomiędzy nimi.

Diagram przypadków użycia

Diagram przypadków użycia z większą liczbą szczegółów

Diagramom towarzyszą

opisy.Obok

podano przykładowy wzorzec

opisu przypadku

użycia(część

rutynowa)

ID: 002

Nazwa: Zarezerwuj miejsce

Opraco

wany

przez:

Michał Cabak Ostatnio

aktualizowa

ny przez:

Michał Cabak

Data

opracowani

a:

2004-03-05 Data

ostatniej

aktualizacji:

2004-03-12

Aktorzy: Operator rezerwacji, Mieszkaniec

Opis: Celem tego przypadku jest dokonanie rezerwacji pokoju

dla mieszkańca. Wynikiem jest potwierdzenie rezerwacji

lub zgłoszenie błędu

Warunki

wstępne:

1 Autoryzacja użytkownika powiodła się

2 Pokój do rezerwacji jest w stanie „aktywny”

Warunki

końcowe:

3 Liczba miejsc zarezerwowanych w pokoju jest

mniejsza lub równa liczbie miejsc w pokoju

pomniejszonej o aktualne zakwaterowania

4 Wszyscy mieszkańcy aktualni mają wyznaczone

rezerwacje

Scenariusz

podstawowy:

002.0.1. Wywołanie przypadku użycia 003

002.0.2. System zwraca listę pokoi

002.0.3. Użytkownik wybiera pokój do rezerwacji

002.0.4. System zgłasza, że wybrany pokój jest wolny

002.0.5. Użytkownik potwierdza rezerwację

002.0.6. System dokonuję rezerwacji pokoju

002.0.7. System wykonuję czynności dodatkowe

002.0.8. System zgłasza sukces rezerwacji

Przykładowy wzorzec opisu

przypadku użycia(część

nierutynowa)

Scenariusze

alternatywne:

002.1.1. System zgłasza, że wybrany pokój jest zajęty

002.1.2. System zgłasza, że istnieje możliwość

wycofania rezerwacji, któremuś z mieszkańców pokoju

002.1.3. Użytkownik potwierdza rezerwację

002.1.4. System wykonuję czynności przygotowawcze

Wyjątki: 002.0.E.1.1. System zwrócił pustą listę pokoi

002.0.E.1.2. Użytkownik anuluję rezerwację

002.0.E.2.1. Użytkownik nie potwierdza rezerwacji

002.0.E.2.2. System wycofuję rezerwację

002.0.E.2.3. Użytkownik anuluję rezerwację

002.1.E.1.1. System zgłasza błędy przy wykonaniu

czynności przygotowawczych

002.1.E.1.2. System wycofuję rezerwację

002.1.E.1.3. Użytkownik anuluję rezerwację

Przypadki

zawierane:

003-znajdz miejsce.

Priorytet: Wysoki

Częstotliwoś

ć użycia:

200 razy

Reguły

biznesowe:

Brak

Wymagania

specjalne:

Brak

Założenia: System ma niezbędne dane do dokonania rezerwacji

Informacje Pozostaje kwestia doprecyzowania listy wymaganych

danych. Lista ta jest szczególnie związana z

Teraz przychodzi czas na zbudowanie diagramu

klas.Diagram klas przedstawia

obraz strukturalnych powiązań pomiędzy

klasami modelowanego systemu.

Obraz ten nie uwzględnia upływu czasu. Nie da się więc przy jego użyciu śledzić przepływu zdarzeń i akcji – czyli cech

behawioralnych.

Diagram klas

Struktura rezerwacji z większą liczbą szczegółów - diagram klas

Diagram klas umożliwia już wygenerowanie kodu kodu

programuprogramu, który uwzględnia wyodrębnione klasy

i ich właściwości.Ta część kodu opisuje

statyczne właściwości systemu.

Przykład kodu (w języku java)

wygenerowanego

z diagramu klas

package rezerwacja;

import java.util.Date;

public class MieszkaniecRezerwujacy implements Mieszkaniec, Priorytetowany {public Akademik akademik;public MiejsceRezerwacji miejsceZarezerwowane;/** * @see rezerwacja.Mieszkaniec#getID() * /public int getID() {

return 0;}/** * @see rezerwacja.Mieszkaniec#getNazwisko() * /public String getNazwisko() {

return null;}/** * @see rezerwacja.Mieszkaniec#getImie() * /public String getImie() {

return null;}/** * @see rezerwacja.Mieszkaniec#getDataUrodzenia() * /public Date getDataUrodzenia() {

return null;}/** *@see rezerwacja.Priorytetowany#priorytet(rezerwacja.MieszkaniecRezerwujacy) * /public int priorytet(MieszkaniecRezerwujacy mieszkaniec) {

return 0;}

}

Przykład kodu w języku C++

Nazwa klas y: C_NeuronK las a oparta o:

K ons truk tor/Des truk tor

void ucz enie ((C_Neuron *)[4][101], float [11] [11] [101] [3] , int [101][101] , int );

float wy lic z (float X[11] [11] [101] [3] , int ,int );

float wy lic z ((C_Neuron *)[4] [101] , int );

void ustaw_funk c je_ak ty wac ji ( int );

void wy pis z _wagi (CDC *, int , int ,int , int ,int , int );

void los uj wagi ();

void oblic z _blad((C_Neuron *)[4] [101] , .. . .. . float [11] [11] [101] [3] , int [101][101] ,int );float fa_s igm oidalna(float );float fa_tangens _hiperbolic z ny (float );float fa_liniowa(float );

Dane po m ocnicz e: float fa_s k ok u(float );float wagi_poprz ednie[11] [10] ; float poc hodna_f_liniowa(float );float blad; float poc hodna_f_s igm oidalna( float );

float poc hodna_f_tangens _hiperb.(float );float poc hodna_f_s k ok u( float );

Dane statycz n e: float beta; int ilos c _wars tw; int ilos c _neuronow[4] ; float ws polc z y nnik _uc z enia; float wagi_od; float wagi_do; float m om entum ; int l iniowa;

Dane po d staw o w e:

Teraz nadchodzi pora na uchwycenie działania systemu

w aspekcie behawioralnym.

Podstawowym narzędziem, wykorzystywanym do tego celu

jest diagram sekwencji.

Diagram sekwencji

Rezerwacja miejsca w scenariuszu alternatywnym - diagram sekwencji

Diagram sekwencji

dla symulatora

sieci neuronowej

CM ainF ram e C_SiecD ld C_NeuronCLitera1View

W M _B U TTON

W M _B U TTON

W M _B UTTON

UC Z

W YLIC Z

US TAW

UC Z

W YLICZ

W YLIC Z

US TAW

Użytkownik naciska klawisz “ucz”klais

Wywołanie funkcji obsługi komunikatu WM_BUTTON_UCZUruchomienie metody “wylicz” dla obiektu siećSekwencyjnie wywoływanie metody “wylicz” dla obiektów klasy neuronUruchomienie metody “uczenie” dla obiektu siećSekwencyjnie wywoływanie metody “uczenie” dla obiektów klasy neuronZgłoszenie stanu gotowości

Użytkownik naciska klawisz “testuj”Wywołanie funkcji obsługi komunikatu U_BUTTON_TESTUJUruchomienie metody “wylicz” dla obiektu siećSekwencyjnie wywoływanie metody “wylicz” dla obiektów klasy neuron

Użytkownik naciska klawisz “opcje”Wyświetlenie okna dialogowego DldUżytkownik naciska klawisz zmiany parametruWywołanie metody zmieniającej wartość parametru dla obiektu siećWywołanie metody zmieniającej wartość parametru – zmiennej statycznej, dla obiektów klasy neuronUżytkownik naciska klawisz zamykający okno Dld

Zestawienie informacji zawartych we wcześniej

opisanych diagramach pozwala na opis dynamiki działania

systemu w postaci

diagramu stanów.

Diagram stanów (stany pokoju)

Stany (pokoju) w większych szczegółach -

diagram stanów

Uwaga końcowa:Metodologia obiektowa także

nie jest idealna.nie jest idealna. Wiele celów łatwiej jest czasem

osiągnąć stosując tradycyjne metody projektowania, takie jak

metodologia strukturalna i tradycyjne narzędzie, takie jak

diagramy encji i relacji.

Jednak ze względu na konieczność zapewnienia bezpiecznejbezpiecznej pracy przy

tworzeniu dużych systemów informatycznych przez duże

zespoły projektantów – właśnie ta metodologia będzie zapewne

dominująca w przyszłości.