Inżynieria oprogramowania
Projektowanie systemów informatycznych
Dr inż. Lucjan Miękina
upel.agh.edu.pl/wimir/login/
Katedra Robotyki i Mechatroniki
March 16, 2014
1/1
Cele kursu i jego organizacja
CELE:
Zapoznanie studentów z nowoczesnym podejściem do procesu tworzenia
oprogramowania, w szczególności opartego o model Model-Driven Architecture i
metody obiektowe
Nauczenie się sposobów projektowania z użyciem języka UML (Unified Modeling
Language)
Opanowanie narzędzi wspomagania procesu tworzenia oprogramowania (CASE),
tzn. IBM Rational Rhapsody Developer
Poznanie podstawowych obiektowych wzorców projektowych i ich zastosowań
Zapoznanie z metodami i narzędziami służącymi do testowania oprogramowania
Zapoznanie z metodami i narzędziami wspomagającymi organizację i nadzór nad
procesem wytwarzania oprogramowania - m.in. Rational Unified Process i Scrum
ORGANIZACJA:
wykład (14h) + laboratoria (14h) + indywidualnie realizowany projekt w
środowisku Rhapsody (14h)
Kurs posiada stronę w systemie e-learningu AGH Moodle, dostępną pod adresem:
http://upel.agh.edu.pl/wimir/login/
2/1
Literatura
Booch, Rumbaugh, Jacobson  UML przewodnik użytkownika. WNT, Warszawa
R. Binder - Testowanie systemów obiektowych. WNT, Warszawa
Gamma, Helm, Johnson, Vlissides - Wzorce projektowe. WNT, Warszawa
M. Fowler  UML w kropelce
S. Wrycza i in. - Język UML 2.0 w modelowaniu systemów informatycznych,
Wyd. Helion
The Java Language reference. Sun Microsystems
IBM Rhapsody Users Guide
3/1
Inżynieria Oprogramowania
Wstęp
Zgodnie ze słownikiem inżynierii oprogramowania opracowanym przez IEEE:
Inżynieria oprogramowania
Inżynieria oprogramowania jest to zastosowanie systematycznego, zdyscyplinowanego,
ilościowego podejścia do rozwoju, eksploatacji i utrzymania oprogramowania
Termin  inżynieria oprogramowania (ang. Software Engineering) powstał w trakcie
seminarium zorganizowanego w Niemczech pod auspicjami NATO w 1968 roku.
Dotyczyła ona m.in. kryzysu w dziedzinie tworzenia oprogramowania, jaki w tym
okresie był mocno zauważalny.
Cytat z Edsger Dijsktra:
 The major cause of the software crisis is that the machines have become several
orders of magnitude more powerful! To put it quite bluntly: as long as there were no
machines, programming was no problem at all; when we had a few weak computers,
programming became a mild problem, and now we have gigantic computers,
programming has become an equally gigantic problem
 Edsger Dijkstra, The Humble Programmer (EWD340), Communications of the ACM
4/1
Inżynieria Oprogramowania
Inżynieria oprogramowania jako dziedzina
Inżynieria oprogramowania jest jednym z czternastu obszarów informatyki
wyodrębnionych w standardzie nauczania zwanym Computer Science Curricula 2013,
opracowanym wspólnie przez IEEE Computer Society i ACM.
W ramach inżynierii oprogramowania jest osiem obligatoryjnych jednostek wiedzy
(czyli każdy informatyk musi to wiedzieć) i cztery opcjonalne:
dwie jednostki dotyczące czynności poprzedzających samo kodowanie programu.
Są to specyfikacja wymagań, czyli ustalenie co budowany system ma robić i
projektowanie oprogramowania, czyli  w dużym uproszczeniu  zaproponowanie
jego struktury i dynamiki.
kolejne dwie jednostki dotyczą walidacji i weryfikacji oprogramowania (czyli,
inaczej mówiąc, kontroli jakości) i jego ewolucji, czyli utrzymania użyteczności
programu i umiejętnego wprowadzania do niego wymaganych zmian.
kolejne dwie powiązane ze sobą jednostki to procesy wytwarzania
oprogramowania (m.in. różne modele cyklu życia oprogramowania, co ma potem
wpływ na planowanie przedsięwzięć programistycznych) i zarządzanie
przedsięwzięciami programistycznymi.
ostatnie obowiązkowe jednostki wiedzy dotyczą narzędzi i środowisk
programistycznych oraz interfejsów programistycznych  w skrócie API od ang.
Application Programming Interface.
opcjonalne to: metody formalne (czyli o charakterze matematycznym), systemy
specjalne (np. systemy czasu rzeczywistego sterujące pracą elektrowni, czy lotem
samolotu), komponenty programistyczne i niezawodność oprogramowania.
Polski standard kształcenia dla kier. Informatyka obejmuje osiem obligatoryjnych
jednostek wiedzy.
5/1
Inżynieria Oprogramowania
Cechy 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.
interfejs - zbiór publicznych metod klasy
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.
6/1
Inżynieria Oprogramowania
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 atrybutom i 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.
7/1
Inżynieria Oprogramowania
Przykład hierarchii klas
8/1
Inżynieria Oprogramowania
Architektura oparta na modelu (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ść (czyli tzw. 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)
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.
9/1
Inżynieria Oprogramowania
Architektura oparta na modelu (MDA)
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.
10/1
Inżynieria Oprogramowania
Struktura MDA
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:
metamodel MOF (Meta-Object
Facility), zawierający specyfikację
składni dla wszystkich modeli
obsługiwanych w ramach MDA.
język UML, będący graficznym
językiem modelowania, zgodnym z
MOF.
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.
11/1
Inżynieria Oprogramowania
Struktura MDA
Znaczenie metamodelu MOF
Dzięki temu, że wszystkie modele
posiadają składnię zdefiniowaną przez
MOF, mogą one być automatycznie
przetwarzane, od modelu PIM przez
PSM do kodu aplikacji na konkretnej
platformie. Dzięki temu można zapisywać
modele w repozytorium zgodnym z MOF,
wyszukiwać je i przetwarzać (wykony-
wać 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 wyma-
ganie nie ogranicza typu modeli  języki
zgodne z MOF obecnie pozwalają tworzyć
modele struktury aplikacji, zachowania i
danych.
12/1
Inżynieria Oprogramowania
Struktura MDA
W drugiej warstwie znajdują się obsługi-
wane platformy, wymieniono tu: Java,
.NET, CORBA, Web Services, XMI/XML.
XMI (XML Metadata Interchange) defini-
uje format wymiany danych dla mod-
eli 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 warst-
wie znajdują się usługi rozszerzające (per-
vasive services), wymieniono tu: katalo-
gowe (directory), transakcyjne (transac-
tions), obsługi zdarzeń (events) i bez-
pieczeństwa (security).
Na zewnątrz modelu są wymienione
przykładowe dziedziny zastosowań rozwi-
janych systemów (Finance, Manufactur-
ing, Space, . . . ).
13/1
Inżynieria Oprogramowania
Typowy przebieg procesu zgodnego z MDA
W typowym procesie realizowanym zgodnie z MDA, wyróżnia się następujące etapy:
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.
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 sekwencji. W trakcie ich tworzenia
dochodzi do identyfikacji klas potrzebnych do zrealizowania modelowanego
działania, a także atrybutów i operacji wymaganych w tych klasach. Następnie z
klas występujących na tych diagramach tworzy się diagram klas całego systemu 
model struktury.
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. Klasy mające aspekt dynamiczny (realizujące pewne zachowania) zostają
wzbogacone o diagramy dynamiki (maszyny stanowej lub czynności), które są
konstruktywne - można z nich wygenerować kod w wybranym języku
programowania.
14/1
Inżynieria Oprogramowania
Typowy przebieg procesu zgodnego z MDA
Dalsze etapy to:
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.
Uruchomienie wykonywane po zakończeniu etapu kodowania. Ma ono na celu
doprowadzenie do podstawowej, poprawnej pracy. Wykonuje się je drogą
debugowania.
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.
15/1
Inżynieria Oprogramowania
Ogólna charakterystyka języka 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 i 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.
Istnieją perspektywy: przypadków użycia, projektowa, procesowa, implementacyjna i
wdrożeniowa.
16/1
Inżynieria Oprogramowania
Ogólna charakterystyka języka UML
Zgodnie z metodyką RUP, można diagramy UML-a przyporządkować do tzw.
perspektyw, (ang. view), które odzwierciedlają sposób widzenia projektu (a więc
również architektury systemu) przez różnych jego uczestników.
W ujęciu RUP wyróżniamy następujące perspektywy:
perspektywa przypadków użycia (ang. Use Case View), która jest nadrzędna w
stosunku do pozostałych i definiuje przeznaczenie i funkcjonalność systemu.
Należą tu diagramy: przypadków użycia i pakietów.
perspektywa dynamiczna (ang. Dynamic View) , która definiuje zachowanie
elementów systemu. Należą tu diagramy: interakcji, czynności, maszyny
stanowej, struktur połączonych i pakietów.
perspektywa statyczna (ang. Logical View) , która definiuje postać elementów
systemu. Należą tu diagramy: klas, obiektów, struktur połączonych i pakietów.
perspektywa komponentów (ang. Implementation View) , która jest
przeznaczona głównie dla programistów i definiuje przynależność elementów
systemu do komponentów (biblioteki, moduły programowe). Należą tu diagramy:
komponentów i pakietów.
perspektywa rozlokowania (ang. Deployment View) , która specyfikuje sprzęt
informatyczny niezbędny do działania elementów systemu. Należą tu diagramy:
rozlokowania i pakietów.
Podobnie jak w klasycznym projektowaniu, dla danego systemu tworzy się wybrane
diagramy, przedstawiające elementy i ich zależności istotne dla projektu systemu.
Zwykle diagramy są hierarchicznie uporządkowane  na poziomie najwyższym jest
diagram zbiorczy (najbardziej ogólny), poniżej diagramy bardziej szczegółowe.
17/1
Inżynieria Oprogramowania
Diagramy przypadków użycia
Diagramy przypadków uzycia służą do modelowania funkcjonalności systemu, widzianej
od strony użytkownika. Stanowią one graficzne przedstawienie aktorów, przypadków
użycia i związków między nimi, występujących w danej dziedzinie zastosowania.
18/1
Inżynieria Oprogramowania
Diagramy przypadków użycia
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 swoją 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ę.
19/1
Inżynieria Oprogramowania
Diagramy przypadków użycia
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 (inaczej 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.
20/1
Inżynieria Oprogramowania
Diagramy przypadków użycia
Symbol powiązania może opcjonalnie mieć wartości krotności dla obu końców (ról),
jak na diagramie poniżej, 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.
21/1