1

Obiektowe modelowanie

i analiza

Informacje zaczerpnięto z książki

„Inżynieria oprogramowania w projekcie

informatycznym”, Janusz Górski, Mikom 2001,

rozdział 4

2

Wstęp

•

Analiza potrzeb jako reprezentacji rzeczywistego

świata

•

Język formułowania problemu jako język dziedziny

problemowej

•

Projekt jako rozwiązanie w dziedzinach technologii

informatycznej

•

Identyfikacja i zrozumienie problemu jest

zagadnieniem pierwszoplanowym

•

Opis wymagań funkcjonalnych przedstawiony jest w

dokumencie nazwanym Specyfikacja Wymagań

systemowych

•

Podejście obiektowe jedną z technik przedstawienia

problemu (możliwość przejścia od wymagań po

implementacje)

•

Modelowanie to naturalny środek do lepszego

poznania modelowanego obiektu

3

Wstęp

• Problematyka orientacji obiektowej w

analizie systemów informatycznych:

Object Modelling Technique (OMT)
Objectory
Unified Modelling Language (UML)

• Podejście obiektowe opisuje rzeczywistość

z trzech różnych perspektyw:

Strukturalnej
Behawioralnej
Transformacyjne

4

Wstęp

• W modelu strukturalnym podstawą jest obiekt i

klasa obiektów oraz wzajemne relacje między nimi,

• Istnieje również model usług który pokazuje system

od strony użytkownika

Wymagania
(modele
obiektowe)

Oprogramowanie

obiektowe

System komputerowy

Projektowanie i
programowanie

obiektowe

Rozwiązanie

problemu

Projekt

informatyc

zny

Problem
świata
rzeczywistego

Identyfikacja

problemu

5

Perspektywa strukturalna –

model obiektów

• Podstawowymi składnikami modelu obiektów są:

• Obiekty
• Klasy obiektów
• Atrybuty
• Operacje i metody
• Związki i wiązania

• Obiekty mogą świadczyć usługi innym obiektom

(klientom) wobec tego są postrzegane różnie

przez te obiekty (różne abstrakcje

charakteryzowane przez zestaw usług i stan)

6

Perspektywa strukturalna –

model obiektów

• Klient kontaktuje się z obiektem poprzez

wywołanie jego usług (identyfikacja usługi i
konkretna operacja), przekazywane są
parametry wywołania a otrzymywane są
rezultaty

• Każdy obiekt posiada identyfikator będący

wskaźnikiem, który jest niezmienny w
czasie

• Usługi wykonywane przez różne klasy

obiektów to operacje ogólne – generic

7

Perspektywa strukturalna –

model obiektów

• Obiekty aktywne mogą spontanicznie

wywoływać usługi a obiekty pasywne mogą
jedynie na nie reagować.

• Grupa obiektów może mieć wspólną

definicję danych lub usług
wykorzystywanych do definicji interfejsu,
wobec tego stanowią wcielenie (instancje)
wspólnej definicji zwanej klasą obiektów

.

8

Perspektywa strukturalna –

model obiektów

• Zestaw usług oferowany innym obiektom

to interfejs obiektów do innych obiektów

• Pojęcie dziedziczenia przez nowo

utworzoną klasę, stanów i usług

zdefiniowanych w innej klasie

• Pojęcie klasy umożliwia wyróżnienie

podobnej grupy obiektów według pewnego

kryterium (pewnych cech którymi są

atrybuty operacje)

9

Perspektywa strukturalna –

model obiektów

• Pojęcie klasy umożliwia wyróżnienie podobnej

grupy obiektów według pewnego kryterium
(pewnych cech którymi są atrybuty operacje)

Graficzna reprezentacja klasy obiektów:

Nazwa klasy

nazwa atrybutu : typ danych = wartość

domyślna

nazwa operacji(lista argumentów) : typ

wyników

10

Perspektywa strukturalna –

model obiektów

• Atrybuty to cechy obiektów które mogą być

charakteryzowane wartościami danych.

• Operacje które nie zmieniają wartości atrybutów to

zapytania które kierowane są do obiektów docelowych

• Ilość argumentów operacji, ich typy oraz typ wartości

zwracanej przez operacje stanowi sygnaturę operacji

• Zależności pomiędzy obiektami reprezentuje wiązanie a

grupa wiązań mająca ten sam sens i strukturę to związek,
który może łączyć ze sobą kilka klas i jest najczęściej
dwukierunkowy.

• Krotność związku mówi nam ile obiektów danej klasy jest

równocześnie związana z obiektami innej klasy

11

Perspektywa strukturalna –

model obiektów

• Dwa rodzaje związków odgrywają szczególną

role w programowaniu obiektowym:

dekompozycja
specjalizacja

• Dekompozycja polega na rozłożeniu obiektu

na mniejsze bloki a specjalizacja umożliwia

modelowanie podobieństw między klasami
(rozróżnienie między klasami nadrzędnymi i

podrzędnymi)

• Klasa podrzędna dziedziczy cechy klasy

nadrzędnej i tworzy się hierarchia

dziedziczenia

12

Perspektywa behawioralna-

model dynamiczny

• Celem modelu dynamicznego jest opisanie, w jaki

sposób stan obiektów może podlegać zmianom w

odpowiedzi na pojawiające się zdarzenia oraz w

jaki sposób zdarzenia te są wytwarzane.

• Zdarzenia nie podlegają dekompozycji oraz ich

czas trwania wynosi zero

• Podstawową zależnością pomiędzy zdarzeniami

jest przyczynowość (uszeregowanie zdarzeń w

czasie)

• Zdarzenia nie powiązane przyczynowo mogą być

współbieżne (ich układ w czasie może być

dowolny)

13

Perspektywa behawioralna-

model dynamiczny

• Zdarzenia występujące w systemie mogą

mieć charakter scenariusza i związujemy z

nim zawsze obiekt wysyłający i odbierający

• Odpowiedz na zdarzenie zależy od stanu

obiektu-odbiorcy. Dla wielu stanów może

być ona identyczna i mówimy wtedy o

stanach uogólnionych

• Stany uogólnione oraz zdarzenia są

reprezentowane przez diagram stanów, a

zmiana stanu pod wpływem zdarzenia

nazywamy przejściem stanu

14

Perspektywa behawioralna-

model dynamiczny

• W diagramie stanów wyróżniony jest stan

początkowy i końcowy. Model dynamiczny definiuje
wszystkie scenariusze zdarzeń i odpowiadające im
ciągi stanów należące do różnych obiektów przy
czym z założenia, są to obiekty niezależne.

Nazwa
stanu
do:
aktywność

Nazwa
stanu
do:
aktywność

zdarzenie (atrybuty)

(dozór) / akcja

15

Perspektywa behawioralna-

model dynamiczny

• Aktywność opisuje jak długo obiekt

znajduje się w danym stanie z kolei akcje
opisują zmiany dokonane w wyniku zdarzeń.

• W związku z tym ze powstałe diagramy

stanów mogą być mało czytelne
wprowadzono dodatkową notacje
umożliwiająca bardziej zwarty zapis:

• uogólnienie / specjalizacja
• agregacja / dekompozycja

16

Perspektywa behawioralna-

model dynamiczny

• Przebywanie w stanie nadrzędnym oznacza

przebywanie we wszystkich jego

podstanach współbieżnych.

• Współbieżność może występować wewnątrz

obiektu w stanach złożonych, które składają

się z dwóch lub więcej stanów podrzędnych.

• Niekiedy zdarza się potrzeba aby zdarzenie

łączyło się z akcją a umożliwia to słowo w

schemacie graficznym action/nazwa akcji .

17

Perspektywa behawioralna-

model dynamiczny

• Sprawne przechodzenie do i ze stanu

podrzędnego umożliwiają następujące

reguły:

• Akcje etykietujące przejścia wejściowe
• Akcje wymienione po słowie kluczowym

entry/(nazwa akcji)

• Aktywności wymienione po słowie do
• Akcje wymienione po słowie kluczowym

exit

• Akcje etykietujące przejścia wyjściowe

18

Perspektywa transformacji

danych – model

funkcjonalny

• Celem modelu funkcjonalnego jest opisanie

dokonywanych przekształceń danych (zależność
między danymi wejściowymi a wyjściowymi)

• Podstawowym pojęciem stosowanym w tym modelu

jest transformacja danych (proces)

• Transformacja odpowiada operacji w modelu

obiektowym lub akcji (aktywności) w modelu
dynamicznym

• Nie rozróżniamy zależności czasowych z zastrzeżeniem,

że skutek nie może poprzedzać przyczyny.

• Przepływy danych umożliwiają wykorzystywanie

danych między transformacjami

19

Perspektywa transformacji

danych – model

funkcjonalny

• Pierwotne źródła danych i miejsca docelowe dla

danych nazywane są aktorami.

• Pojemnik danych jest to pamięć która przechowuje

powierzone mu dane aby mogły być wykorzystane
przez inne transformacje w różnej kolejności

• Możliwe jest wykonanie w ramach pojemnika

agregacji różnych danych i wysłanie ich jako jeden
element.

• Podejście pojemnikowe przypomina model

obiektowy. Niektóre przepływy danych mogą być
obiektami, aczkolwiek posiadają one tylko wartości a
nie własną tożsamość.

20

Perspektywa transformacji

danych – model

funkcjonalny

• Model funkcjonalny jest zbiorem

diagramów przepływu danych, w skład
których wchodzą transformacje, aktorzy
oraz pojemniki danych. Diagramy te
składają się na hierarchie poziomów.

• Poziom najwyższy odnosi się do całego

systemu i jest poziomem najwyższej
abstrakcji a zawarte w nim transformacje
mogą być np. funkcjami matematycznymi i
nie mieć skutków ubocznych.

21

Perspektywa transformacji

danych – model

funkcjonalny

• Metody definiowania przekształceń nie mających

skutków ubocznych obejmują:

• podanie wzoru matematycznego łączącego dane

wejściowe z wyjściowymi

• podanie zależności we / wy w formie

tabelarycznej

• podanie warunków wejściowych i wyjściowych
• specyfikacje w postaci tablicy decyzyjnej
• abstrakcyjny program (pseudocode)

specyfikujący sekwencje kroków obliczeniowych

• opis w języku naturalnym

22

Perspektywa transformacji

danych – model

funkcjonalny

• Transformacje reprezentują bardziej złożone

obliczenia posiadające efekty uboczne. Dla
każdej takiej sytuacji tworzony jest
oddzielny diagram przepływu danych.

• Proces ten może być kontynuowany aż do

momentu gdy dane transformacje nie będą
wymagać dalszej dekompozycji

• Stosuje się rozwidlenia jeśli dana

informacja ma być przesłana na wejścia
różnych transformacji

23

Perspektywa usług – model

przypadków użycia

• Przypadek użycia ( use case) reprezentuje

ciągi interakcji między użytkownikiem a
systemem i stanowi ich opis.

• Modele przypadków wymagają komunikacji

między wykonawcami projektu a
potencjalnymi użytkownikami.

24

Perspektywa usług – model

przypadków użycia

• Pełny opis przypadków użycia wymaga identyfikacji

następujących elementów:

• użytkowników pracujących z systemem w ramach

danego przypadku

• obiektów systemu które pozostają w interakcjach z

użytkownikami

• zdarzenia, które rozpoczyna sekwencje interakcji
• warunków początkowych od których uzależnione

jest występowanie danego przypadku

• opisu interakcji między użytkownikami a systemem
• opisu niestandardowych przebiegów
• warunków końcowych

25

Perspektywa usług – model

przypadków użycia

• Punktem wyjścia dla użycia tego modelu jest

rozpoznanie użytkowników mających współpracować
z systemem (Specyfikacja Wymagań Systemowych)

• Użytkownicy i związane z nimi przypadki użycia są

reprezentowani w ramach diagramu przypadków
użycia

• Diagramy śladów jako szczegółowa specyfikacja

przypadków użycia

• Zależność między przypadkami użycia (może się

zdarzyć ze dany przypadek jest rozszerzeniem
istniejącego już przypadku)

• Model ten jako opracowanie testów akceptacyjnych

26

Zależności między

modelami

• Zależność miedzy modelem obiektowym a dynamicznym

wynika z tego, że dla każdej klasy w modelu obiektowym
istnieje diagram stanów w modelu dynamicznym

• Hierarchia klas odpowiada hierarchii stanów w modelu

dynamicznym

• Zależność między modelem dynamicznym i obiektowym

określa względną kolejność wykonywania operacji,
natomiast efekty wykonywanych operacji zdefiniowane
są w modelu funkcjonalnym.

• Identyfikacja celu operacji (transformacji w modelu

funkcjonalnym) prowadzi do przypisania tej operacji
odpowiedniemu obiektowi w modelu obiektowym

27

Zależności między

modelami

• Kluczowe zagadnienia dotyczące

opisywanych modeli

28

Zależności między

modelami

Ustalenie celu operacji reprezentowanych przez transformacje

danych

29

Metodyka obiektowa

• Metodyka inżynierii oprogramowania stanowi

przepis postępowania skutkujący pożądanym
produktem programowym. Poniżej przedstawiono
podstawowe kroki składające się na metodykę
OMT.

Analiza

Projekt systemu

Projekt Obiektow

Implementacja

Metodyka

obiektowa

30

Analiza

• Analiza nie jest procesem, który można wykonać

mechanicznie, istotą analizy jest zrozumienie
problemu.

• Jest to proces iteracyjny, w którym kolejne

modele odzwierciedlają głębokość zrozumienia
problemu.

• W każdym kroku zbliżamy się do rozwiania przez

działania: integracji, walidacji i weryfikacji
zapewniające wewnętrzną i zewnętrzną
spójność.

31

Struktura etapu analizy

Budowa modelu obiektowego

Budowa modelu dynamicznego

Budowa modelu funkcjonalnego

Ite

ra

cy

jn

e:

In

te

gr

ac

ja

m

o

de

li,

w

e

ry

fik

ac

ja

i

w

al

id

a

cj

a

32

Budowa modelu

obiektowego:

Identyfikacja klas obiektów

• Koncentruje się na dziedzinie aplikacyjnej.

Pomijamy szczegóły implementacyjne oraz

szczegóły konkretnego rozwiązania

projektowego

.

• Podejście praktyczne polega na

wyselekcjonowaniu rzeczowników z Specyfikacji

Wymagań Systemowym i potraktowaniu ich jako

identyfikatorów klas obiektów.

• Innym źródłem identyfikacji obiektów

:

– specyfikacja przypadków użycia.
– dodatkowe klasy obiektów wynikające z

ogólnej wiedzy na temat problemu.

33

Budowa modelu

obiektowego

• Budowa słownika danych:

– Słownik danych zawiera wszystkie

nazwy reprezentujące elementy modelu
wraz z ich opisami.

• Identyfikacja związków:

– Identyfikacja związków pomiędzy

klasami. Wstępna identyfikacja przez
rozpatrzenie fraz z specyfikacji wymagań
zawierających czasowniki.

34

Budowa modelu

obiektowego

• Identyfikacja atrybutów:

– Atrybuty opisują własności obiektów, ale same

nie są obiektami.

– Wstępna identyfikacja atrybutów polega na

rozważeniu przymiotników, wyrażeń

dzierżawczych odnoszących się do już

definiowanych klas i związków.

• Identyfikacja relacji dziedziczenia

:

– Zależności dziedziczenia mogą być identyfikowane

przez wprowadzanie klas będących uogólnieniami

klas istniejących lub przez specjalizację klas już

istniejących i wyrażenia ich w terminach klas

bardziej szczegółowych.

35

Budowa modelu

obiektowego

• Weryfikacja ścieżek dostępu:

– Związki reprezentują możliwe ścieżki wzajemnych

odwołań między obiektami. Powinny one
umożliwiać uzyskanie odpowiedzi na istotne z
punktu widzenia użytkownika pytania.

• Grupowanie klas w moduły:

– Jeśli budujemy duży system wskazane jest

podzielenie go na moduły.

– Moduły reprezentują grupy silnie związanych ze

sobą klas.

– Nad poszczególnym modułami mogą pracować

niezależne zespoły programistów.

36

Budowa modelu

obiektowego:

Weryfikacja, walidacja i

uszczegóławianie

• Za wyjątkiem najprostszych projektów,

model obiektowy nie będzie wynikiem
jednorazowego zabiegu analitycznego.

• Powyższe kroki powinny być powtarzane w

celu usuwania niespójności oraz
poprawienia wykrytych błędów, aż do
momentu gdy uznamy że model
odzwierciedla własności strukturalne
budowanej aplikacji oraz obejmuje jej
pełen zakres.

37

Budowa modelu

dynamicznego

• Identyfikacja scenariuszy:

– Zbiór scenariuszy, które opisują typowe

interakcje systemu ze światem zewnętrznym.

– Punktem wyjścia jest tu specyfikacja przypadków

użycia systemu, o ile została ona sprecyzowana
w Specyfikacji Wymagań Systemowych. Jeśli nie
została należy je jawnie zidentyfikować i
rozpatrzyć różne przypadki użycia systemu.

• Identyfikacja zdarzeń:

– Dla danego scenariusza powstaje odpowiadający mu

ślad zdarzeń oraz diagram przepływu zdarzeń,
przedstawiające drogi przepływu zdarzeń pomiędzy
obiektami systemu.

38

Budowa modelu

dynamicznego

• Budowa diagramów stanu:

– Dla każdej klasy modelu obiektowego

tworzony jest diagram stanów opisujących

jej zachowanie. Jeśli zachowanie obiektu

klasy jest trywialne można pominąć jawną

specyfikacje ich diagramów stanu.

• Integracja modelu:

– Celem tego kroku jest zapewnienie, że zbiór

powstałych diagramów stanów jest wewnętrznie
spójny, a wytworzony model dynamiczny jest
zgodny ze zidentyfikowanymi wcześniej
interakcjami systemu z jego otoczeniem.

39

Budowa modelu

funkcjonalnego

• Model funkcjonalny koncentruje się na

przetwarzaniu danych.

• Opisuje przepływy danych oraz związane z

nimi transformacje.

• Uwidocznione są tylko zależności

wejściowe i wyjściowe, z pominięciem

kolejności występowania przekształceń.

• Transformacje danych reprezentują

operacje poszczególnych obiektów lub

łączne efekt kilku operacji.

40

Budowa modelu

funkcjonalnego

• Identyfikacja wejść i wyjść:

– Powstaje diagram uwidaczniający

przepływ danych z i do obiektów systemu.

• Budowa diagramu przepływu danych:

– W tym kroku powstaje diagram

przepływu danych, który uwidacznia
obliczenia mające na celu wywiedzenie
danych wyjściowych na podstawie
odpowiednich wejść.

41

Budowa modelu

funkcjonalnego

• Specyfikacja podstawowych transformacji

danych:

– Definiujemy podstawowe (nie podlegające

dalszej dekompozycji) transformacje danych

opisywane jako zależności funkcyjne między

danymi wejściowymi i wyjściowymi

(transformacje nie zleżą od stanu systemu).

• Identyfikacja ograniczeń:

– Identyfikacja zależności między przepływami

danych, których nie da się wyrazić w

terminach relacji wejście – wyjście.

42

Koniec etapu analizy

• Integracja modeli:

– W wyniku analizy trzech modeli powstaje

model obiektowy z ostateczną listą operacji.

• Uszczegóławianie modeli:

– Proces analizy jest zwykle iteracyjny.
– Kolejne wersje modeli są bardziej szczegółowe i

coraz bliższe rozwiązania rozważanego problemu.

– W kolejnych krokach usuwane są nieścisłości i

braki z poprzednich wersji.

43

Po ukończeniu analizy

• Interpretacja wymagań w terminach modelu:

– Większość wymagań funkcjonalnych

zawartych w specyfikacji wymagań

systemowych da się wyrazić w terminach

zbudowanych modeli.

– Taka wypowiedź dodaje tym wymaganiom

dodatkowej precyzji i eliminuje

niejednorodności.

– Dzięki temu zbudowany model jest

środkiem ułatwiającym efektywną

komunikację z klientem i przyszłymi

użytkownikami systemu.