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