1

J.Korczak, UE Wroclaw

1

Jerzy KORCZAK, Barbara SMOKemail :<jerzy.korczak, brabara.smok>@ue.wroc.pl

http://www.korczak-leliwa.plhttp://citi.ae.wroc.pl

Inżynieria Systemów

InformatycznychCASE – metodyki i narzędzia

Narzędzia CASE:

jest to grupa narzędzi

programistycznych tworzących nową technologię konstruowania systemów

informacyjnych, obejmujących cały

cykl życia systemu informatycznego.

Narzędzia CASE:

• CASE (Computer Aided Software Engineering ) oznacza komputerowo wspomaganą inżynierię oprogramowania lub (Computer Assisted System Engineering ) komputerowo wspomaganą inżynierię systemów

• Pod tym pojęciem kryją się wszystkie narzędzia komputerowe wykorzystywane w trakcie prac nad oprogramowaniem jak np. kompilatory, debuggery, edytory tekstu, narzędzia harmonogramowania przedsięwzięć, arkusze kalkulacyjne.

Cechy narzędzi CASE (1):

• duży stopień wizualizacji informacji

• sporządzanie diagramów

• operują diagramami różnych typów wsposób pozwalający uwzględniać różneaspekty opisywanych obiektów

• kompletują informację o opisywanychobiektach oraz reprezentują powiązaniazachodzące między nimi

Cechy narzędzi CASE (2):

• eliminowanie powielania danych i procesów

• badanie poprawności i spójności informacji

zawartych na diagramach

• automatyczna generacja schematu relacji

(definicja baz danych)

• stosowanie konstrukcji programowania

strukturalnego na poziomie języka diagramów

(podprogramy, iteracje, rozgałęzienia)

Cechy narzędzi CASE (3):

• wspomagają projektowanie zewnętrznychobrazów obiektów aplikacji

• automatycznie generują znaczną część proceduraplikacji na podstawie szablonów programowychpodstawowych czynności

• współdzielenie informacji między autoramisystemu

• tworzą centralną encyklopedię systemu zzapewnieniem koordynacji i kontroli informacjiwprowadzanej z różnych stacji roboczych.

2

Narzędzia CASE:

• Zintegrowane pakiety oprogramowania realizującego zbiór technik projektowania

• Dostosowane do konkretnej metodyki lub rodzaju metodyk

• Zazwyczaj wyposażone w repozytoriumDwie główne grupy narzędzi CASE:

• Upper-CASE: wspomaganie wczesnych faz prac nad oprogramowaniem, w szczególności fazy analizy (potrzeby analityków i projektantów). Narzędzia te nie są związane z konkretnym środowiskiem implementacyjnym.

• Lower-CASE: wspomaganie faz projektowania i implementacji (potrzeby programistów). Narzędzia te są z reguły ściśle związane z konkretnym środowiskiem implementacji.

Składowe narzędzi CASE

Funkcje narzędzi CASE:

• określają granice systemu informacyjnego

• umożliwiają analizę i dekompozycję problemu na

składowe odpowiadające elementom tego systemu

• Umożliwiają dobór metod i narzędzi do realizacji tych

składowych

• Pozwalają tworzyć i zapisywać modele oraz zależności

między nimi

• Automatyzują niektóre czynności projektowe

• Kontrolują poprawność i spójność projektu oraz zgodność między modelami

Podział pakietów typu CASE ze względu na

zakres:

• pakiety narzędziowe (Toolkits)

• środowiska (environments)

• pakiety zintegrowane (Workbench):

a) narzędzia specyfikacji i interpretacji opisu systemu

b) generatory struktur baz danych

c) generatory programów wykonywalnych

d) programy dokonujące modyfikacji wersji systemu

Aspekty narzędzi CASE

Narzędzia CASE stosują różne techniki wizualizacji projektów, w szczególności

notacje diagramów encja-związek (ER), OMT, UML i inne.

Obecnie większość producentów określa swoje środowiska jako I-CASE.Są to

narzędzia łączące w sobie możliwości Lower-CASE i Upper-CASE.

Istnieje grupa narzędzi uniwersalnych, które umożliwiają pracę z wieloma

notacjami i wieloma metodykami. Istnieją również narzędzia CASE

przypisane do konkretnych produktów, np. Oracle CASE. Wiele narzędzi

CASE łączy elementy znane z wielu metodyk z własnymi pomysłami.

Przykłady narzędzi CASE (są ich dziesiątki):

Oracle CASE, EasyCASE, CASE 4.0, ObjectiF, Select OMT Professional,

System Architect, ObjectTeam, Paradigm Plus, Rational Rose, Select

Enterprise, Oracle Designer

Ocena narzędzi CASE (kryteria):

•Zakres oferowanych funkcji i ich zgodność z potrzebami firmy

• Koszt

• Niezawodność• Opinia o producencie i dystrybutorze

• Dostępność na rynku pracy specjalistów znających dany pakiet

• Stopień zintegrowania z przyjętym środowiskiem

programistycznym

• Wielośrodowiskowość• Koszt szkoleń• Koszt dostosowania sprzętu do wymagań pakietu

3

Przyczyny trudności z narzędziami CASE

Traktowanie narzędzi CASE wyłącznie jako generatorów kodu. Nie jest to

efektywne przy braku rzetelnego podejścia do analizy i projektowania:

• nakłady na implementację stanowią tylko ok. 15-30% całych nakładów

• koszt błędów popełnionych w fazie implementacji jest stosunkowo niewielki

• istnieją inne, tańsze narzędzia programistyczne (RAD)

Nieznajomość metodyki analizy i projektowania. Narzędzia CASE nie

zwalniają z myślenia, wiedzy i doświadczenia.

Niewłaściwa organizacja i zarządzanie przedsięwzięciem. Nieuporządkowanie

prac, brak planu, brak właściwych ocen, brak monitorowania postępu, itd.

Zbyt wysokie oczekiwania w stosunku do narzędzia CASE. Może ono

zredukować koszty co najwyżej o 50%, koszt wdrożenia jest wysoki, efekty

pojawiają się z pewnym opóźnieniem, wymaga dyscypliny w przedsięwzięciu.

Rozkład kosztów realizacji SI

Modelowanie

1. Ustalenie głównych przepływów informacji (interfejsów) między systemem a obiektami zewnętrznymi

2. Sporządzenie diagramu kontekstowego

3. Identyfikacja podstawowych procesów

4. Dodanie magazynów danych niezbędnych z punktu widzenia logiki systemu

5. Dekompozycja i uszczegóławianie modelu

6. Weryfikacja syntaktyki i semantyki

Metodyki projektowania SI:

• Metodyki strukturalne

• Metodyki obiektowe

Metodyki strukturalne

• Dane i procesy modelują osobno

• Wykorzystują tylko proste typy danych

• Dobrze są dostosowane do relacyjnego modelu danych

• Ich podstawowe techniki to: diagramy przepływu danych (DFD), diagramy związków encji (ERD), hierarchie funkcji (FHD), modele macierzowe

Metodyki obiektowe:

• Dane i procesy modelują łącznie

• Wykorzystują złożone typy danych

• Dostosowane są do obiektowego modelu

danych

• Ich podstawowe techniki to: diagramy klas

UML, przypadki użycia i modele

dynamiczne UML

4

Analiza strukturalna

�Metody strukturalne są szczególnie przydatne w przypadkach,

gdy jeden z aspektów aktywny lub pasywny jest bardziej istotny

�Analiza strukturalna (structured analysis) zw. też analiząwymagań prowadzi do sformułowania specyfikacji systemu

(system specification) w formie zestawienia wymagań i założeń(requirements)

� Główny cel fazy analizy stanowi dekompozycja funkcjonalna SI

oraz opis potrzebnych do jego funkcjonowania danych. Najpierw

przeprowadza się analizę istniejącego systemu i na jej podstawie

buduje się model funkcjonalny nowego systemu.

�

Analiza strukturalna (structured analysis)

rozpoczyna się od budowy dwóch różnych modeli systemu:

- modelu danych będącego opisem pasywnej części systemu

- modelu funkcji opisującego aktywną część systemu

Następnie następuje integracja tych modeli, której wynikiem

jest model przepływu danych (data flows model).

Metodyki strukturalne

MetodykiMetodykiMetodykiMetodyki strukturalnestrukturalnestrukturalnestrukturalne - łączą statyczny opisdanych oraz statyczny opis procesów.

Do tej klasy należą:• Metodyka Yourdona (DeMarco i Ward/Mellor);

• Structured System Analysis and Design Methodology (SSADM);

• Structured Analysis and Design Technique (SADT).

structured methodologies, structured analysis

Metodyki strukturalne

Uważa się, że wadą metodyk strukturalnych są trudności w zintegrowaniu modeli.

Zgodnie z DeMarco, analiza strukturalna używa następujących technik.

• Diagramy Przepływu Danych (Data Flow Diagrams, DFD)

• Słownik Danych (Data Dictionary)

• Strukturalny Angielski (Structured English) -> strukturalny polski

• Tablice Decyzyjne (Decision Tables)

• Drzewa Decyzyjne (Decision Trees)

Dodatkowo:

• Schemat Transformacyjny (Transformation Schema)

• Diagram Przejść Stanów (State Transition Diagram)

• Lista Zdarzeń (Event List)

• Schemat Danych (Data Schema)

• Pre- i post- warunki (Pre- and Post-Conditions)

• Diagramy Encja-Związek (występują w SSADM)

• Historie Życia Encji (występują w SSADM)

Faza analizy

Celem fazy określenia wymagań jest udzielenie odpowiedzi na pytanie:

Co i przy jakich ograniczeniach system ma robić?

Wynikiem tej fazy jest zbiór wymagań na system.

Celem fazy analizy jest ustalenie wszystkich tych czynników lub warunków w dziedzinie

przedmiotowej, w otoczeniu realizatorów projektu, w istniejących lub planowanych systemach

komputerowych, które mogą wpłynąć na decyzje projektowe, na przebieg procesu projektowego i na

realizację wymagań. Wynikiem jest logiczny model systemu, opisujący sposób realizacji przez system postawionych

wymagań, lecz abstrahujących od szczegółów implementacyjnych.

W odróżnieniu, celem fazy projektowania jest udzielenie odpowiedzi na pytanie:

Jak system ma być zaimplementowany? Wynikiem jest opis sposobu implementacji.

Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja

Faza strategiczna AnalizaAnalizaAnalizaAnaliza Instalacja

Dokumentacja

Czynności w fazie analizy

Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie

rzeczywistości lub problemu będącego przedmiotem projektu;

Ustalenie kontekstu projektu;

Ustalenie wymagań użytkowników;

Ustalenie wymagań organizacyjnych

Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie

oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd.

W zasadzie analiza nie powinna stawiać nacisku na zmianę rzeczywistości poprzez

wprowadzenie tam nowych elementów np. w postaci systemu komputerowego. Jej

celem jest rozpoznanie wszystkich tych aspektów rzeczywistości, które mogłyby

mieć wpływ na postać, organizację lub wynik projektu.

5

Tematy i techniki analizy

�Budowa statycznego modelu klas

�Analiza funkcji i przypadków użycia

�Weryfikacja klas i obiektów

�Identyfikacja i definiowanie metod oraz komunikatów

�Modelowanie stanów i przejść między stanami

�Modelowanie procesów i przepływów danych

�Modelowanie przepływu sterowania

�Inne

Podstawowe rezultaty fazy analizy

�Poprawiony dokument opisujący wymagania

�Słownik danych zawierający specyfikację modelu

�Dokument opisujący stworzony model, zawierający:

• diagram klas

• diagram przypadków użycia

• diagramy sekwencji komunikatów (dla wybranych sytuacji)

• diagramy stanów (dla wybranych sytuacji)

• raport zawierający definicje i opisy klas, atrybutów, związków,

metod, itd.

�Harmonogram fazy projektowania

�Wstępne przypisanie ludzi i zespołów do zadań

Analiza strukturalna - modelowanie procesów

• Podstawowa technika są diagramy przepływów

danych (Data Flow Diagrams - DFD)

• DFD pojawiły się w końcu lat 70-tych

• w rezultacie prac:

– T.DeMarco

– Ch.Gane, T.Sarson

– E.Yourdon, Constantine

Cel modelowania danych

(1)

• Otrzymanie dokładnego modelu potrzeb informacyjnych

przedsiębiorstwa

• Dekompozycja i strukturalizacja problemu

• Sformalizowanie opisu z wykorzystaniem języka

graficznego - jednoznaczność i czytelność

• Mechanizm efektywnej komunikacji pomiędzy

analitykiem i użytkownikiem, pomiędzy analitykami

systemu, a nawet pomiędzy użytkownikami

• Poprawa jakości i efektywności projektowania bazy

danych

Cel modelowania danych (2)

• Opis danych niezależny od struktur logicznych i

fizycznych

• Niezależność od implementacji pozwala na zastosowanie

modelu do integracji istniejących baz danych

• Podstawa do zrozumienia procesów realizowanych w

przedsiębiorstwie i jego reorganizacji

• Możliwość prezentacji potrzeb informacyjnych na różnym

poziomie ogólności

Techniki modelowania procesów

diagramy przepływu danych (DFD)

• Są najstarszą techniką stosowaną w CASE

• Należą do najważniejszych działań, które programuje się w pierwszej kolejności.

• Obrazują procesy zachodzące w systemie oraz wymianę danych między nimi, jak również sposób, w jaki te dane są wprowadzane i wyprowadzane z systemu.

• Stanowią podstawowe narzędzie analizy strukturalnej, podczas której powstaje zbiór diagramów DFD.

6

Diagram kontekstowy (0):

• Przedstawia cechy systemu: granice systemu, źródła i odbiorców informacji w systemie, główne wejścia i wyjścia z systemu (informacje płynące między światem zewnętrznym a systemem).

• Jest mapą procesów realizowanych w systemie wraz z powiązaniami zewnętrznymi. Istnieje wiele sposobów tworzenia diagramów przepływu danych.

• Buduje się go w sposób zstępujący (top-down) lub wstępujący (bottom-up).

DFD składa się z:• jednostek zewnętrznych (External Entity) -

reprezentujących osobę, urządzenie lub inny systeminformatyczny będący źródłem lub odbiorcą informacji

• magazynów danych (Data Store) - ukazujących istniejącei przewidywane bazy danych, z których może korzystaćkilka procesów

• procesów - odpowiadają tym składnikom systemu, któreoperują na danych, transformują dane wejściowe nainformacje wyjściowe

• przepływu danych (data flow) - opisują strumieniedanych o określonej zawartości przepływające pomiędzydwoma obiektami (źródłem i przeznaczeniem).

Przykład DFD:

DFD

DFD - przykładObiekty DFD

7

DFD - główne komponenty SSADM Składnica (datastore)

Przepływ danych (dataflow) Przepływ danych (data flow)

Przepływ danych

Łączy wyjście jednego procesu z wejściem innego procesu.

Może także łączyć proces (wejście / wyjście) z interfejsem lub składnicą

danych

Byt zewnętrzny (eksternal)

8

Modelowanie związków encji

• Obejmuje identyfikowanie rzeczy ważnych w

analizowanym przedsiębiorstwie (encji),

własności tych rzeczy (atrybutów) i sposobów,

jakimi te encje są ze sobą powiązane (związków)

Diagram związków encji (ERD):

• jest modelem sieciowym opisującym na

wysokim poziomie abstrakcji układ danych

przechowywanych w systemie

• zw. jest też obiektowo-związkowym

diagramem

• służy do wyrażenia struktury danych

projektowanego lub istniejącego systemu.

Atrybuty encji

• Atrybut jest dowolnym szczegółem służącym do kwalifikowania, identyfikowania, klasyfikowania, określania ilości lub wyrażania stanu encji (atrybut jest dowolnym opisem mającym znaczenie dla encji)

• Atrybut musi opisywać encję, przy której występuje

• Nazwa atrybutu musi być podana w liczbie pojedynczej

• Każda encja musi być jednoznacznie zidentyfikowana przez kombinację atrybutów i/lub związków

Encja (ang. entity)

• Jest bytem, rzeczą lub obiektem mającym dla nas

znaczenie, rzeczywistym bądź wyobrażonym, o którym

informacje muszą być znane lub przechowywane.

• Jej nazwa powinna powinna reprezentować typ lub klasę rzeczy, a nie żadne jej konkretne wystąpienie

Atrybut – cecha służąca do identyfikacji,

klasyfikacji lub wyrażenia stanu encjiEncja

9

Unikalny identyfikator – unique identifier Obiekty na diagramach związków encji

Związek (relationship) – nazwane istotne

powiązanie między encjamiNazywanie związków

Konstrukcje specjalne Hierarchie encji

10

Funkcja (function)Podstawowymi pojęciami modelu ER są:

• encja (jednostka danych lub obiekt) (entity) -rzecz istotna, rzeczywista albo wyobrażalna, októrej informacje muszą być znane lubprzechowywane

• związek (relationship) - istotne powiązaniemiędzy dwiema encjami

• atrybut (attribute) - każdy szczegół służący dokwalifikowania, identyfikowania, klasyfikowania,określania ilości, wyrażania stanu encji lub teżopis “rzeczy istotnej”.

ERDERD

Przykładowy ERD

Przykład ERD:

11

Modelowanie hierarchii funkcji tworzy diagramy, które

pokazują dekompozycję funkcji na różnych poziomach

działalności przedsiębiorstwa

Function Hierarchy Diagrammer

• Dla funkcji można zdefiniować jej

hierarchię

• Każda funkcja jest dekomponowana do

najniższego poziomu (elementary business

function)

• Funkcje elementarne stają się formularzami,

raportami i narzędziami

Function Hierarchy

• Hierarchiczna struktura funkcji stanowi

model funkcjonalny systemu

• Funkcje odzwierciedlają czynności

wykonywane przez użytkownika systemu w

procesie przetwarzania danych

• Funkcja nadrzędna opisuje cały system

produkcji

Function Hierarchy

• Funkcja nadrzędna jest dekomponowana na inne

funkcje, które mogą być też dekomponowane.

• W wyniku podziałów otrzymujemy hierarchię funkcji.

• Z tych diagramów wynikają zależności pomiędzy

funkcjami (FDD) – definiują model dynamiczny –

kolejność wykonywania funkcji w systemie, a

także uwarunkowania jakie muszą być spełnione

przed ich wykonaniem.

Diagram macierzowyMatrix Diagrammer (do analizy jest to narzędzie do weryfikacji

poprawności i spójności modelu) Matrix Diagrammer

12

Poziomy modelowania SI Metody modelowania

Metody analizy

• Rozkład funkcjonalny

• Modelowanie procesów

• Modelowanie danych

• Analiza obiektowa

Rozkład funkcjonalny - pojęcia podstawowe

• cel przedsiębiorstwa

• funkcja

• hierarchia funkcji

• mechanizmy

• zdarzenia

Weryfikacja

• każdy proces musi mieć przepływy do niego wpływające jak i wypływające;

• obiekty zewnętrzne nie mogą komunikować się bezpośrednio z magazynem;

• nie może istnieć magazyn, z którego następuje tylko odczyt;

• przepływy wchodzące i wychodzące z procesu na diagramie wyższego poziomu pojawiają się na niższym poziomie jako przepływy przekraczające granice dekomponowanego procesu;

• nie pojawiają się procesy, których nie było wyżej;

• procesy są numerowane wielopoziomowo

Rola analizy systemowej

• zrozumienie dziedziny problemu;

• uzyskanie aktualnego opisu stanu systemu

informacyjnego;

• ułatwienie komunikacji pomiędzy udziałowcami projektu;

• podstawa mapowania/modelowania

13

Analiza

• jest studium dziedziny problemu prowadzącym do

specyfikacji obserwowalnego zachowania systemu;

• podczas analizy ustala się co system ma robić, aby spełnić wymagania użytkownika

Metody specyfikacji wymagań

• Język naturalny;

• Język ustrukturyzowany;

• Tablice, formularze;

• Diagramy kontekstowe;

• Diagramy blokowe;

• Diagramy przypadków użycia.

FUNCTION HIERARCHY DIAGRAMMER Diagram ERD

Matrix Hierachia funkcji

14

DFD

Geneza obiektowości

Mentalna percepcja świata

rzeczywistego

Model

pojęciowy

Schemat struktury

danych

W modelu relacyjnym model pojęciowy stara się odwzorować świat rzeczywisty, lecz jest ograniczony

dostępną bazą implementacyjną. W rezultacie, schemat struktury danych gubi semantykę danych.

Obiektowość jest nową ideologią która wynika z zaobserwowanych wad istniejącego świata

i podaje jakąś receptę, jak te wady usunąć, a więc przede wszystkim stara się o uzyskanie

jak najmniejszej luki pomiędzy myśleniem o rzeczywistości (dziedzinie problemowej) a

myśleniem o danych i procesach, które zachodzą na danych.

Model obiektowy podtrzymuje te zgodności, przybliżając semantykę danych do świata

rzeczywistego.

Podstawowe zasady obiektowości

Obiekt - struktura danych, występująca łącznie z operacjami dozwolonymi do

wykonywania na niej, odpowiadająca bytowi wyróżnialnemu w analizowanej

rzeczywistości.

Hermetyzacja - rozróżnienie pomiędzy interfejsem do obiektu opisującym co

obiekt robi, a implementacją definiującą, jak jest zbudowany i jak robi, to co ma zrobić.

Klasa - Zgrupowanie obiektów o tych samych charakterystykach.

Dziedziczenie - Wielokrotne użycie tego, co wcześniej zostało zrobione: definiowanie

klas, które mają wszystkie cechy zdefiniowane wcześniej (z nadklasy) plus cechy nowe.

Polimorfizm - Wybór nazwy dla operacji jest określony wyłącznie semantyką operacji.

Decyzja o tym, która metoda implementująca daną operację, zależy od przynależności

obiektu do odpowiedniej klasy.

Tożsamość obiektu Tożsamość obiektu Tożsamość obiektu Tożsamość obiektu ---- wewnętrzny identyfikator, który pozwala na odróżnienie go od innych obiektów.

Obiekt Konto

Numer: 123-4321

Stan konta: 34567 PLN

Właściciel: Jan Kowalski

Upoważniony: ...

Podpis: …

....

WypłaćWpłać

Sprawdźstan

UpoważnijPodaj osoby

upoważnione

Porównaj

podpis

Zlikwiduj

konto

Nalicz

procent

Hermetyzacja; ukrywanie informacji

Zasada inżynierii oprogramowania (Parnas, 1972): programista ma tyle wiedzieć o

obiekcie programistycznym, ile potrzeba, aby go efektywnie użyć. Wszystko, co może być

przed nim ukryte, powinno być ukryte.

Hermetyzacja i ukrywanie informacji jest podstawą pojęć: modułu, klasy i ADT.

Hermetyzacja ortodoksyjna (Smalltalk)

Na zewnątrz są widoczne metody;

atrybuty obiektu są ukryte.

Ergo: prawie każdy atrybut atr jest

obsługiwany przez dwie metody:

czytaj_atr, zmień_atr

Hermetyzacja ortogonalna (C++)

Dowolna własność obiektu

(atrybut, metoda,...) może byćprywatna (ukryta) lub publiczna

Specjalne środki do specyfikowania

własności prywatnych i publicznych.

Hermetyzacja: zgromadzenie elementów struktury i implementacji obiektu w postaci

jednej manipulowalnej bryły; oddzielenie specyfikacji obiektu od jego implementacji.

Hermetyzacja pośrednio oznacza także ukrycie struktury i implementacji obiektu. Tęwłasność określa się jako ukrywanie informacji. Hermetyzacja i ukrywanie informacji

są różnymi pojęciami, choć mocno powiązanymi.

DziedziczenieGeneralizacja-specjalizacja jest takim związkiem pomiędzy klasami, który łączy klasę bardziej ogólną (nadklasę) z jedną lub więcej klas (tzw. podklas), będących jej

specjalizacjami. Klasa, będąca specjalizacją danej klasy, oprócz własności nadklasy może

posiadać (i z reguły posiada) też własności swoje. Związek generalizacji-specjalizacji

może być modelowany za pomocą struktur dziedziczenia, co nie jest jedynym możliwym

rozwiązaniem. Dziedziczenie inwariantów do klas jest tranzytywne (przechodnie).

genera

liza

cja

genera

liza

cja

genera

liza

cja

genera

liza

cja

specja

liza

cja

specja

liza

cja

specja

liza

cja

specja

liza

cja

Pracownik

Asystent

Adiunkt Profesor

Docent

nazwisko

data ur.wiek

pole

atrybutówpole

metod

pensja

Osoba pole nazwy klasy

15

Polimorfizm (1)

Z greckiego, polimorfizm - oznacza “wiele form” (postaci) jednego bytu. Słowo “polimorfizm”

też jest polimorficzne.

aPolimorfizm metod - (co zostało już wyjaśnione wcześniej w punkcie „Operacja a

metoda”) polega na tym, że operacja wywoływana za pośrednictwem komunikatu możebyć różnie wykonana, w zależności od rodzaju obiektu, do którego ten komunikat został

wysłany; innymi słowy: może istnieć wiele metod implementujących daną operację.

a Polimorfizm typów (z teorii typów) - polimorfizm w tzw. polimorficznych językach

programowania - oznacza istnienie funkcji, które mogą zarówno przyjmować wartości

wielu typów jako swoje argumenty, jak też i zwracać wartości wielu typów.

Przykładowo, funkcja daj_pierwszy(lista) zwraca pierwszy element dowolnej listy,

niezależnie od tego, czy jest to lista liczb całkowitych, czy lista liczb rzeczywistych, czy

lista rekordów, czy też inna. Polimorfizm typów jest uważany za podstawęprogramowania ogólnego (generic). Temat pozostaje jednak w strefie akademickiej, gdyżjęzyki z polimorfizmem typów (a w szczególności ML) uważane są za zbyt

wyrafinowane dla przeciętnego programisty.

Polimorfizm

Z greckiego, polimorfizm - oznacza “wiele form” (postaci) jednego bytu. Słowo

“polimorfizm” też jest polimorficzne.

• Polimorfizm metod - (zostało już wyjaśnione w punkcie „Podstawowe zasady obiektowości”)

- operacja wywoływana przez komunikat może być różnie wykonana, w zależności od

rodzaju obiektu, do którego ten komunikat został wysłany.

• Polimorfizm typów (z teorii typów) - polimorfizm w tzw. polimorficznych językach

programowania - oznacza istnienie procedur lub funkcji, które mogą zarówno przyjmowaćwartości wielu typów jako swoje argumenty, jak też i zwracać wartości wielu typów.

Przykładowo, funkcja daj_pierwszy(lista) zwraca pierwszy element dowolnej listy,

niezależnie od tego, czy jest to lista liczb całkowitych, czy lista liczb rzeczywistych, czy

lista rekordów, czy też inna. Polimorfizm typów jest uważany za podstawę programowania

ogólnego (generic). Temat pozostaje jednak w strefie akademickiej, gdyż języki z

polimorfizmem typów uważane są za zbyt wyrafinowane dla przeciętnego programisty, a

w szczególności ML.

polymorphism

Obiekt

Byt (rzecz lub pojęcie) obserwowalny w dziedzinie problemowej (czyli w tym

fragmencie świata rzeczywistego, którego dotyczy dany system informacyjny),

odróżnialny od innych bytów, posiadający dobrze określone granice oraz nazwę jest

odwzorowywany na obiekt w implementacji komputerowej. Obiekt może być złożony,

tj. może składać się z innych obiektów.

Pojęcie obiektu sprzyja lepszemu rozumieniu modelowanego świata rzeczywistego -

byty ze świata rzeczywistego odpowiadają obiektom w programie.

Obiektem może być także pewien zamknięty fragment oprogramowania (dana,

procedura, moduł, dokument, okienko dialogu,...), którym można operować jak zwartąbryłą: usuwać, wyszukiwać, wiązać, kopiować, blokować, indeksować, ...

Obiekt ma przypisany typ, tj. wyrażenie językowe, które określa jego budowę (poprzez

specyfikację atrybutów) oraz ogranicza kontekst, w którym odwołanie do obiektu możebyć użyte w programie.

Obiekt może być powiązany z innymi obiektami związkami skojarzeniowymi,

odpowiadającymi relacjom zachodzącym między odpowiednimi bytami w dziedzinie

problemowej.

Metodyki obiektowe

�Metodyka wykorzystująca pojęcia obiektowości dla celów modelowania

pojęciowego oraz analizy i projektowania systemów informatycznych.

�Podstawowym składnikiem jest diagram klas, będący zwykle wariantem

notacyjnym i pewnym rozszerzeniem diagramów encja-związek.

�Diagram klas zawiera: klasy, w ramach klas specyfikacje atrybutów i metod,

związki generalizacji, związki asocjacji i agregacji, liczności tych związków,

różnorodne ograniczenia oraz inne oznaczenia.

�Uzupełnieniem tego diagramu są inne: diagramy dynamiczne uwzględniające

stany i przejścia pomiędzy tymi stanami, diagramy interakcji ustalające

zależności pomiędzy wywołaniami metod, diagramy funkcjonalne (będące

zwykle pewną mutacją diagramów przepływu danych), itd.

�Koncepcja przypadków użycia (use cases) zakłada odwzorowanie struktury

systemu z punktu widzenia jego użytkownika.

PrzykładyPrzykładyPrzykładyPrzykłady: Express, OODA(Booch), OMT(Rumbaugh), OOSA(Shlaer-Mellor),Objectory(Jacobson), MOSES/OPEN, OOA/OOD(Coad/Yourdon), NotacjaUML.

Notacja a metodyka

Dowolny język, w tym notacje stosowane w metodykach, oprócz składni posiada dwa

znacznie od niej ważniejsze aspekty: semantykę i pragmatykę.

Pragmatyka określa, jak do konkretnej sytuacji dopasować pewien wzorzec notacyjny.

Pragmatyka wyznacza więc procesy prowadzące do wytworzenia zapisów wyników analizy i

projektowania, które są zgodne z intencją autorów tej notacji. Jakakolwiek notacja nie ma

większego sensu bez wiedzy o tym, w jaki sposób może być ona użyta w ramach pewnego

procesu analizy i projektowania.

W metodykach pragmatyka stosowanej notacji (czyli jak i do czego jej użyć) jest sprawąpodstawową. Jest ona zazwyczaj trudna do objaśnienia: nie ma innego sposobu oprócz

pokazania sposobów użycia na przykładach przypominających realne sytuacje. Niestety, realne

sytuacje są zazwyczaj bardzo skomplikowane, co powoduje pewien infantylizm przykładów

zamieszczanych w podręcznikach.

Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami.

Pragmatyka określa, w jaki sposób i do czego należy używać przyjętych oznaczeń.

Składnia określa, jak wolno kombinować ze sobą przyjęte oznaczenia.

Diagramy definiowane w UML

�Diagramy przypadków użycia (use case)

�Diagramy klas, w tym diagramy pakietów

�Diagramy zachowania się (behavior)

�Diagramy implementacyjne

• Diagramy stanów

• Diagramy aktywności

• Diagramy sekwencji

• Diagramy współpracy (collaboration)

• Diagramy komponentów

• Diagramy wdrożeniowe (deployment)

Autorzy UML wychodzą z założenia, że żadna pojedyncza perspektywa

spojrzenia na projektowany system nie jest wystarczająca. Stąd wiele

środków:

Diagramy te zapewniają mnogość perspektyw systemu podczas analizy i rozwoju.

16

Proces tworzenia modelu obiektowegoZadania:

�Identyfikacja klas i obiektów

�Identyfikacja związków pomiędzy klasami

�Identyfikacja i definiowanie pól (atrybutów)

�Identyfikacja i definiowanie metod i komunikatów

Czynności te są wykonywane iteracyjnie. Kolejność ich wykonywania nie jest

ustalona i zależy zarówno od stylu pracy, jak i od konkretnego problemu.

Inny schemat realizacji procesu budowy modelu obiektowego polega na

rozpoznaniu funkcji, które system ma wykonywać. Dopiero w późniejszej fazie

następuje identyfikacja klas, związków, atrybutów i metod. Rozpoznaniu funkcji

systemu służą modele funkcjonalne (diagramy przepływu danych) oraz model

przypadków użycia.

Identyfikacja klas i obiektów

Typowe klasy:

�przedmioty namacalne (samochód, czujnik)

�role pełnione przez osoby (pracownik, wykładowca, student)

�zdarzenia, o których system przechowuje informacje (lądowanie samolotu,

wysłanie zamówienia, dostawa),

�interakcje pomiędzy osobami i/lub systemami o których system przechowuje

informacje (pożyczka, spotkanie, sesja),

�lokalizacje - miejsce przeznaczone dla ludzi lub przedmiotów

�grupy przedmiotów namacalnych (kartoteka, samochód jako zestaw części)

�organizacje (firma, wydział, związek)

�wydarzenia (posiedzenie sejmu, demonstracja uliczna)

�koncepcje i pojęcia (zadanie, miara jakości)

�dokumenty (faktura, prawo jazdy)

�klasy będące interfejsami dla systemów zewnętrznych

�klasy będące interfejsami dla urządzeń sprzętowych

Obiekty, zbiory obiektów i metadane

W wielu przypadkach przy definicji klasy należy dokładnie ustalić, z jakiego

rodzaju abstrakcją obiektu mamy do czynienia.

Np. klasa „samochód”. Może chodzić o:

• egzemplarz samochodu wyprodukowany przez pewną fabrykę• model samochodu produkowany przez fabrykę• pozycję w katalogu samochodów opisujący własności modelu

• historię stanów pewnego konkretnego samochodu

Podobnie z klasą „gazeta”. Może chodzić o:

• konkretny egzemplarz gazety kupiony przez czytelnika

• konkretne wydanie gazety (niezależne od ilości egzemplarzy)

• tytuł i wydawnictwo, niezależne od egzemplarzy i wydań • partię egzemplarzy danej gazety dostarczaną codziennie do kiosku

Należy zwrócić uwagę na następujące aspekty:

• czy mamy do czynienia z konkretnym obiektem w danej chwili czasowej?

• czy mamy do czynienia z konkretnym obiektem w pewnym odcinku czasu?

• czy mamy do czynienia z opisem tego obiektu (dokument, metadane)?

• czy mamy do czynienia z pewnym zbiorem konkretnych obiektów?

UML - przykład notacji

UML (Unified Modeling Language) powstał jako synteza trzech metodyk/notacji:

OMT (Rumbaugh): metodyka ta była dobra do modelowania dziedziny

przedmiotowej. Nie przykrywała jednak dostatecznie dokładnie zarówno aspektu

użytkowników systemu jak i aspektu implementacji/konstrukcji.

OOSE (Jacobson): metodyka ta dobrze podchodziła do kwestii modelowania

użytkowników i cyklu życiowego systemu. Nie przykrywała jednak dokładnie

modelowania dziedziny przedmiotowej jak i aspektu implementacji/konstrukcji.

OOAD (Booch): metodyka dobrze podchodziła do kwestii projektowania,

konstrukcji i związków ze środowiskiem implementacji. Nie przykrywała jednak

dostatecznie dobrze fazy analizy i rozpoznania wymagań użytkowników.

Istniało wiele aspektów systemów, które nie były właściwie przykryte przez żadne z

wyżej wymienionych podejść, np. włączenie prototypowania w cykl życiowy,

rozproszenie i komponenty, przystosowanie notacji do preferencji projektantów, i

inne. Celem UML jest przykrycie również tych aspektów.

Zadania fazy projektowania

� Uszczegółowienie wyników analizy. Projekt musi być wystarczająco

szczegółowy aby mógł być podstawą implementacji. Stopieńszczegółowości zależy od poziomu zaawansowania programistów.

� Projektowanie tych składowych systemu, które nie są związane z

dziedziną problemową.

� Optymalizacja systemu.

� Dostosowanie do ograniczeń i możliwości środowiska

implementacji.

� Określenie fizycznej struktury systemu (projekt architektury

systemu).

Zadania stojace przed wykonawcami w fazie projektowania:

Identyfikacja klas

Właściwa identyfikacja klas (abstrakcji opisujących grupy bytów o podobnych

własnościach, wyróżnialnych w analizowanej rzeczywistości), to kluczowa

umiejętność w obiektowym podejściu do procesu konstrukcji oprogramowania.

Klasy są najbardziej stabilnym elementem dziedziny problemowej. Dobry system

oparty jest tak dalece, jak tylko jest to możliwe, na klasach reprezentujących grupy

bytów wyróżnialnych w dziedzinie problemowej, a nie na funkcjonalności potrzebnej

dziś i to dla specyficznego być może zastosowania. Oprogramowanie

wykorzystujące klasy powstałe w wyniku analizy dziedzinowej jest znacznie bardziej

odporne na zmiany wymagań niż oprogramowanie oparte o jednostki funkcjonalne.

Ma to, tzn. oparcie oprogramowania o wykorzystanie klas, duże znaczenie dla

technologii ponownego użycia.

17

Podstawowe rezultaty fazy analizy

Poprawiony dokument opisujący wymagania

Słownik danych zawierający specyfikację modelu

Dokument opisujący stworzony model, zawierający:

• diagram klas

• diagram przypadków użycia

• diagramy sekwencji komunikatów (dla wybranych sytuacji)

• diagramy stanów (dla wybranych sytuacji)

• raport zawierający definicje i opisy klas, atrybutów, związków,

metod, itd.

Harmonogram fazy projektowania

Wstępne przypisanie ludzi i zespołów do zadań

Poprzednicy UML:

�OMT (Rumbaugh): dobry do modelowania dziedziny przedmiotowej. Nie przykrywa dostatecznie dokładnie zarówno aspektu użytkowników systemu, jak i aspektu implementacji (konstrukcji).

�OOSE (Jacobson): dobrze podchodzi do kwestii modelowania użytkowników i cyklu życiowego systemu. Nie przykrywa dokładnie modelowania dziedziny przedmiotowej jak i aspektu implementacji (konstrukcji).

�OOAD (Booch): dobrze podchodzi do kwestii projektowania, konstrukcji i związków ze środowiskiem implementacji. Nie przykrywa dostatecznie dobrze fazy rozpoznania i analizy wymagań użytkowników.

Język UML

UML (w założeniu swoich twórców) - nie jest wysoce

formalnym językiem do przedstawiania czy udowadniania

nowych teorii.

Ma być przede wszystkim uniwersalnym językiem

modelowania ogólnego zastosowania, przeznaczony do

wykorzystania tam, gdzie tworzy się systemy

oprogramowania.

Najważniejsze modele w UML wykorzystywane

w fazie analizy:

�model przypadków użycia opisujący system widziany z

perspektywy jego przyszłego użytkownika (za pomocą diagramów przypadków użycia),

�model obiektowy przedstawiający statyczną budowę, czyli

strukturę systemu (za pomocą diagramów klas i diagramów

obiektów). Diagram klas może zawierać obiekty. Diagram

obiektów nie zawiera klas, ale wyłącznie obiekty.

Charakterystyka UML:

�Diagramy przypadków

�Diagramy klas

�Diagramy dynamiczne (interakcji, stanu, aktywności)

�Diagramy komponentów

�Diagramy implementacyjne

�Diagramy pakietów

Diagram klas – przykład

18

Diagram klas:

Diagram klas (class

diagram) przedstawia

statyczną strukturę klas oraz

relacji między nimi w

systemie. Diagram klas

może również zawierać interfejsy oraz pakiety, a

nawet instancje klas

Diagram obiektów:

Diagram obiektów (object diagram) przedstawia obiekty i

wartości danych.

Diagram przypadków użycia (use case diagram)

• Przypadek użycia – powinien mieć unikalną nazwę

• Aktor reprezentuje rolę, jaką w systemie może grać określony użytkownik, organizacja lub inny SI.

• Relacja typu <include> lub <extend> - ukazuje związek pomiędzy 2 przypadkami użycia lub przypadkiem i blokiem ponownego użycia

• Blok ponownego użycia – fragment systemu, który jest używany przez kilka przypadków użycia

Wypłata gotówki

Weryfikacja klienta

Diagram sekwencyjny

Diagram sekwencyjny (sequence diagram) pokazuje interakcje

między obiektami w pojedynczych przypadkach użycia. Pozwala

na przedstawienie kolejności zdarzeń dotyczących obiektów

Diagram kolaboracji

Diagram kolaboracji (collaboration diagram) przedstawia

interakcje między obiektami w wielu przypadkach użycia; jest

pomocny w fazie szukania obiektów i związków między nimi

pokazuje sekwencje stanów, przez które przechodzą elementy

modelu (np. obiekty lub interakcje) podczas swojego życia,

pod wpływem zdarzeń zewnętrznych

Diagram stanów (statechart diagram):

19

Diagram czynności (activity diagram):

przedstawia przepływ sterowania; wykorzystywany do opisu

przypadków użycia lub bardziej kompleksowych operacji

Diagram komponentów (component diagram)

przedstawia elementy systemu, które mogą być wielokrotnie użyte, ze ściśle zdefiniowanymi interfejsami

Diagram konfiguracyjny (deployment diagram)

pokazuje konfigurację fizycznych elementów działającego

systemu oraz komponentów programowych, procesów i

obiektów, które w ich ramach istnieją

Literatura

Wrycza St., Marcinkowski B., Wyrzykowski K.: Język UML w

projektowaniu systemów informatycznych, Helion 2006

Subieta K.: Obiektowość w projektowaniu i bazach danych.

Akademicka Oficyna Wydawnicza PLJ Warszawa 1998

Subieta K.: Słownik terminów z zakresu obiektowości. Akademicka

Oficyna Wydawnicza PLJ, Warszawa 1999

Słodzień J., Strzembosz E.: Analiza i projektowanie systemów

informatycznych. PJWSTK, Warszawa 2003

Roszkowski J.: Analiza i projektowanie strukturalne. Helion 2002

Internet