I. ZASADY OBIEKTOWEGO PODEJÅšCIA DO PROGRAMOWANIA
Niezależnie od języka implementacji, istnieją ogólne zasady obiektowego podejścia do
tworzenia oprogramowania, nazywane modelem obiektowym. Składa się on z poniższych
pojęć:
obiekt  każdy byt (pojęcie lub rzecz), mający znaczenie w dziedzinie zastosowania
klasa  uogólnienie zbioru obiektów, mających takie same atrybuty, operacje i znaczenie.
Jeśli pewne klasy mają wspólną część, to powinna ona być ich wspólną klasą bazową (lub
inaczej nadklasÄ…).
komunikat (ang. message)  specyfikacja wymiany informacji między obiektami,
zawierająca zlecenie wykonania określonej operacji lub wymiany danych.
abstrakcja proceduralna i abstrakcja danych - polega na ukrywaniu nieistotnych cech
obiektu w trakcie operacji z nim związanych, dzięki temu że obiekt może być wyposażony w
wiedzę o swych operacjach. Dzięki temu ułatwia się operacje i unika błędów, a także skraca
się notację - można lepiej panować nad złożonymi systemami lub algorytmami.
hermetyzacja (ang. encapsulation) - polega na selektywnym dostępie do szczegółów
obiektu (atrybutów i operacji) i dzięki temu zapewnieniu niezależności (braku niepotrzebnych
sprzężeń). Prywatne atrybuty i operacje są niedostępne dla otoczenia, stanowiąc elementy
wewnętrznego mechanizmu działania obiektu. Publiczne atrybuty i operacje są dostępne dla
otoczenia, umożliwiając odwoływanie się do obiektu za pomocą komunikatów. Chronione
atrybuty i operacje są dostępne w ciągu podklas danej klasy. Cechy obiektowego podejścia do
programowania
dziedziczenie (ang. inheritance) ­ polega na przejmowaniu cech pewnych obiektów przez
inne, z równoczesnym dodawaniem nowych cech ­ tworzenie tzw. specjalizacji. Oznacza to
przyporządkowanie atrybutów i operacji do klas zgodnie z hierarchiczną zależnością, jakiej
podlegają klasy. Dzięki temu można budować systemy złożone, lecz elastyczne w
zastosowaniu.
polimorfizm (ang. polymorphism)  polega na nadaniu takiej samej nazwy różnym
operacjom w klasach należących do jednej hierarchii (od nadklasy przez wszystkie podklasy).
Pozwala m.in. na wywołanie tzw. wirtualnej metody (procedury lub funkcji), która może mieć
różne znaczenie w zależności od kontekstu wywołania.
W oparciu o wymienione zasady modelu obiektowego, powstaje język bardziej
zbliżony do opisywanego problemu (w odróżnieniu od zbliżonego do maszyny).
Dzięki tym założeniom program obiektowo zorganizowany może się składać prawie
wyłącznie z deklaracji zmiennych obiektowych (instancji); w trakcie tych deklaracji
wykonywane są wszystkie operacje inicjalizacji obiektów (definiowania ich stanu
początkowego), tak by mogły one zacząć funkcjonować w otoczeniu innych obiektów. Dalsze
funkcjonowanie każdego obiektu polega na odbiorze komunikatów wysyłanych przez inne
obiekty i odpowiednim ich przetwarzaniu, w ramach którego możliwe jest również wysyłanie
własnych komunikatów, czyli oddziaływanie na otoczenie.
Taki model daje większe możliwości, co jest związane głównie z decentralizacją
funkcjonalności (każda klasa odpowiada za swoją część operacji złożonego systemu) i nie jest
potrzebny żaden nadrzędny mechanizm, który musiałby być odpowiednio bardziej złożony.
II. MDA.
Podejście nazwane Model Driven
Architecture zostało opracowane przez Object
Management Group (OMG) i udostępnione w
2001 r., w celu standaryzacji procesu rozwijania
systemów informatycznych. Podejście to
zapewnia, poprzez zdefiniowane w jego ramach
standardy, otwartość i niezależność od producenta
narzędzi wspomagających  producenci tych
narzędzi stosują się do specyfikacji MDA,
zapewniając tym samym ich współpracę.
MDA jest oparte o model niezależny od platformy (platform-independent model, PIM)
aplikacji, określający jej strukturę i funkcjonalność (model biznesowy). Kompletna aplikacja
MDA składa się z końcowego modelu PIM, jednego lub więcej modeli dedykowanych do
platformy (platform-specific model, PSM) i kompletnych implementacji, po jednej dla
obsługiwanych platform. Termin platforma oznacza tu warstwę oprogramowania
systemowego lub użytkowego, która stanowi środowisko w jakim uruchamia się rozwijany
system informatyczny. Przykładami platform są: J2EE, Web Services, XML/SOAP, EJB,
C#/.Net, CORBA, itd.
Proces inżynierii oprogramowania prowadzony w zgodzie z MDA koncentruje się
początkowo na funkcjonalności aplikacji lub systemu, bez wnikania w niuanse technologiczne
platform docelowych. W ten sposób MDA pozwala zupełnie oddzielić szczegóły
implementacji od funkcjonalności. Dzięki temu nie jest potrzebne powtarzanie procesu
definiowania funkcjonalności systemu za każdym razem, gdy jest on przenoszony na nową
lub ewoluujÄ…cÄ… platformÄ™.
Poszczególne architektury są zwykle związane z używanymi technologiami. Zgodnie z
MDA funkcjonalność jest modelowana tylko raz przez PIM, przy zastosowaniu języka UML
lub innego standardu OMG. Przejście od modelu PIM przez model PSM do docelowych
platform jest obsługiwane przez narzędzia zgodne ze specyfikacją QVT stworzoną przez
OMG (Query/View/Transformation), np. M2M zawarte w Eclipse Modeling Framework.
Zastosowanie tych narzędzi znacznie upraszcza obsługę zmieniających się platform i ich
technologii, prowadząc w granicznym przypadku do automatyzacji tych kroków.
StrukturÄ™ procesu zgodnego z MDA przedstawia schemat, pochodzÄ…cy ze strony
internetowej OMG. Jest to model warstwowy, w którego centrum są zawarte główne
składowe podejścia:
1. metamodel MOF (Meta-Object Facility), zawierający specyfikację składni dla
wszystkich modeli obsługiwanych w ramach MDA. Dzięki temu, że wszystkie modele stosują
tą składnię, mogą być automatycznie przetwarzane, od modelu PIM przez PSM do kodu
aplikacji na konkretnej platformie. Aby to umożliwić, MDA wymaga, by modele były
wyrażone w języku o składni zgodnej z MOF. Dzięki temu można zapisywać modele w
repozytorium zgodnym z MOF, wyszukiwać je i przetwarzać (wykonywać transformacje) za
pomocą narzędzi zgodnych z MOF, a także przetwarzać do postaci definiowanej przez XMI,
np. w celu udostępniania przez sieć. To wymaganie nie ogranicza typu modeli  języki
zgodne z MOF obecnie pozwalają tworzyć modele struktury aplikacji, zachowania i danych
2. język UML, będący graficznym językiem modelowania, zgodnym z MOF.
3. wspólny metamodel hurtowni danych CWM (Common Warehouse Model), który
opisuje sposób wymiany danych dotyczących modeli między hurtowniami danych, systemami
zarzÄ…dzania wiedzÄ… i przy zastosowaniu technologii internetowych.
W drugiej warstwie znajdują się obsługiwane platformy, wymieniono tu: Java, .NET,
CORBA, Web Services, XMI/XML. XMI (XML Metadata Interchange) definiuje format
wymiany danych dla modeli wyrażonych w języku UML i innych językach zgodnych z MOF.
Format ten jest oparty na języku XML i w efekcie definiuje odwzorowanie między językiem
UML i XML.
W trzeciej, najbardziej zewnętrznej warstwie znajdują się usługi rozszerzające
(pervasive services), wymieniono tu: katalogowe (directory), transakcyjne (transactions),
obsługi zdarzeń (events) i bezpieczeństwa (security).
Na zewnątrz modelu są wymienione przykładowe dziedziny zastosowań rozwijanych
systemów (Finance, Manufacturing, Space, & )
W typowym procesie realizowanym zgodnie z MDA, wyróżnia się następujące
etapy:
1. Budowa modelu przypadków użycia jest rezultatem identyfikacji i dokumentowania
wymagań. W tym celu tworzy się diagram przypadków użycia, który jest odzwierciedleniem
wymagań funkcjonalnych i zawiera aktorów systemu i skojarzone z nimi przypadki użycia.
Ponadto zawiera on tekstowe opisy przypadków użycia i ich scenariusze. Do wybranych
przypadków użycia można dołączyć diagramy czynności schematycznie pokazujące przebieg
reprezentowanej przez przypadek użycia funkcji systemu;
2. Budowa modelu analitycznego opisującego elementy składowe systemu i ich
współdziałanie. Model analityczny powinien pokazywać realizacje wszystkich przypadków
użycia w postaci diagramów klas obejmujących klasy potrzebne do zrealizowania
modelowanego działania, diagramów interakcji pokazujących podstawowy i alternatywne
przebiegi przypadku użycia. Następnie z klas występujących na tych diagramach tworzy się
diagram klas całego systemu;
3. Budowa modelu projektowego będącego podstawą do wygenerowania szkieletu
kodu aplikacji. Model projektowy jest kompletnym modelem klas powstałym z rozszerzenia
diagramu z modelu analitycznego o wszystkie atrybuty i metody klas.
4. Implementacja rozpoczynajÄ…ca siÄ™ od wygenerowania szkieletu aplikacji.
Utworzony projekt staje się repozytorium kodu aplikacji. Od tej pory każda zmiana w modelu
powoduje zmianę w kodzie aplikacji. Kolejnym krokiem jest uzupełnienie plików z kodem
z
ródłowym odpowiednimi treściami, które pozwolą na funkcjonowanie aplikacji zgodnie z
wymaganiami wyrażonymi w scenariuszach;
5. Uruchomienie wykonywane po zakończeniu etapu kodowania. Ma ono na celu
doprowadzenie do podstawowej, poprawnej pracy. Wykonuje siÄ™ je drogÄ… debugowania;
6. Testowanie mające na celu ujawnienie wszelkich niesprawności działania aplikacji i
niezgodności z wymaganiami. Na podstawie wyników testowania może być konieczne
wprowadzenie korekt w implementacji lub nawet w etapach wcześniejszych (modelach);
wtedy powtarza się cały cykl od najwcześniejszej korekty.
III. UML
UML (Unified Modeling Language) jest językiem umożliwiającym graficzne
projektowanie systemów, który pierwotnie był ukierunkowany na systemy informatyczne, ale
nadaje się do użycia w innych dziedzinach i jest stosowany do modelowania biznesowego,
finansowego, organizacyjnego, itd.
Projekt systemu informatycznego w języku UML składa się z szeregu powiązanych ze
sobą logicznie diagramów, czyli schematów zawierających symbole języka UML.
UML definiuje kilkanaście rodzajów diagramów, które mają różne znaczenie i
zastosowanie. SÄ… to:
" Diagramy struktury  klas, obiektów, pakietów, struktur połączonych, wdrożeniowe
(komponentów, rozlokowania);
" Diagramy dynamiki - przypadków użycia, interakcji (sekwencji, komunikacji,
sterowania interakcją, harmonogramowania), czynności, maszyny stanowej;
" Inne diagramy - wymagań, interfejsu użytkownika.
W zależności od stosowanej metodyki projektowej, diagramy są przyporządkowane do
pewnych grup  powyżej przedstawiono ich oryginalną klasyfikację zdefiniowaną w UML.
Zgodnie z metodyką RUP (Rational Unified Process) można diagramy języka UML
przyporządkować do tzw. perspektyw (view), które odzwierciedlają sposób widzenia projektu
(a więc również architektury systemu) przez różnych jego uczestników.
IV. DIAGRAM PRZYPADKÓW UŻYCIA
Stanowią one graficzne przedstawienie aktorów, przypadków użycia i związków
między nimi, występujących w danej dziedzinie zastosowania.
Diagramy te tworzy się na podstawie wymagań użytkowych sformułowanych dla
systemu. Pozwalają one przedstawić w sposób syntetyczny wszystkie funkcje, jakich
oczekuje się od systemu. Poza tym stanowią punkt wyjścia do tworzenia innych elementów
projektu  diagramów interakcji, klas, itd.
Aktor reprezentuje jedną kategorię obiektów mogących oddziaływać na system. Tę
kategorię można utożsamiać ze spójnym zbiorem ról odgrywanych przez użytkowników
systemu. Zakłada się, że obok aktorów typu osobowego (ludzi) występują aktorzy nieosobowi
(inne systemy).
Przypadek użycia reprezentuje pojedynczą, powtarzalną interakcję aktora z systemem.
W trakcie tej interakcji system wykonuje pewien ciąg akcji, stosownie do działania aktora.
Przypadek użycia typowo zawiera jeden lub więcej scenariuszy, które określają interakcje
między aktorem i systemem, ich wyniki i ewentualne sytuacje wyjątkowe.
Diagram przedstawiony na poprzednim ekranie pokazuje aktorów i związane z nimi
przypadki użycia. Zdefiniowano abstrakcyjnego aktora o nazwie Operator, który jest
związany relacją uogólnienia z konkretnymi aktorami typu Projektant, Administrator i
Użytkownik. Każdy z konkretnych aktorów ma swoja specyfikę, co wyraża się w odmiennie
zdefiniowanych powiązaniach z przypadkami użycia. Przypadek Twórz konfigurację jest
złożony, zawiera przypadek Edycja konfiguracji, który z kolei może być w pewnych
warunkach rozszerzony o przypadek Zapisz konfiguracjÄ™.
Przypadki użycia i aktorzy mogą występować w następujących wzajemnych relacjach
(zwiÄ…zkach):
" powiÄ…zania (inaczej asocjacji)  kiedy jeden element jest zwiÄ…zany z drugim. Dla
diagramu przypadków użycia typowe jest występowanie asocjacji między aktorem i
przypadkiem użycia, która oznacza, że dany aktor może inicjować funkcjonalność zawartą w
tym przypadku użycia.
" uogólnienia (generalizacji)  kiedy pewien przypadek użycia jest szczególnym
aspektem innego przypadku użycia, lub  dla aktorów  kiedy pewien aktor jest szczególnym
aspektem innego aktora.
" zawierania  przypadek użycia może zawierać inne przypadki użycia (jako części
bardziej złożonej interakcji  relacja include). Symbolem tej relacji jest przerywana linia ze
strzałką skierowaną od bardziej złożonego przypadku w stronę przypadku będącego częścią.
Relacja ta jest ponadto opatrzona stereotypem include.
" rozszerzania  przypadek użycia może być rozszerzany przez inne przypadki użycia
(dla obsługi specjalnych sytuacji lub opcji). Symbolem tej relacji jest przerywana linia ze
strzałką skierowaną od przypadku rozszerzającego funkcjonalność do przypadku
rozszerzanego. Relacja ta jest ponadto opatrzona stereotypem extend. Przypadek rozszerzany
posiada zdefiniowane punkty rozszerzenia (extension points), które oprócz opisu zawierają
warunek sterujący rozszerzeniem. Jeśli ten warunek jest spełniony, to dodatkowa
funkcjonalność jest włączona do modelu.
Symbol powiązania może opcjonalnie mieć wartości krotności dla obu końców (ról),
jak na diagramie obok,
zgodnie z którym aktor
Customer może wykonywać
równocześnie conajwyżej
jedną operację wypłaty, ale
bank może równocześnie
obsługiwać wiele takich
operacji.