Politechnika Rzeszowska im. Ignacego Łukasiewicza

Wydział Elektrotechniki i Informatyki

INŻYNIERIA OPROGRAMOWANIA

Prowadzący: Wykonali:
dr inż. Krzysztof Świder Hadam Ewa
Stręk Grzegorz
WYKŁAD 1: 03-10-2007

1) System informacyjny

Dowolny system, w którym jest przetwarzana, przechowywana i udostępniana informacja.
/* domyślamy się,że jest to jakiś zorganizowany system zarzadzania informacją; informacja
jest wszędzie*/

2) System informatyczny

Oznacza komputerowe „odzwierciedlenie” systemu informacyjnego lub jego części.

/* Uwaga: Systemy inforamcyjne są w coraz większym stopniu obsługiwane komputerowo,stąd
często termin system informacyjny bedziemy używac zarówno w sensie ogólnym jak i do
określenia jego informatycznej warstwy – systemu informatycznego */

Inżynieria oprogramowania

dotyczy pewnych metod

tworzenia, oceny i pielęgnacji

oprogramowania

i można ją określić jako dziedzinę, której przedmiotem

jest efektywne

projektowanie, uruchamianie i utrzymanie systemów informatycznych.

Wymagania stawiane programom:

- niezawodność,
- wydajność,
- rozszerzalność,
- przenośność,
- łatwość pielęgnacji,
- odzyskiwalność,
- odporność na włamanie,
- zgodność ze standardami,
- przyjazność,
- dobra dokumentacja,
- zgodność z założoną specyfikacją.

Problem informatyzacji firmy:

1) podejście tradycyjne

W większości dotychczasowych rozwiązań dotyczących informatyzacji instytucji i przedsiębiorstw
przeprowadzano tzw. komputeryzację oddolną, w ramach której poszczególne działy wyposażano w
komputery i odpowiednie do profilu ich działalności oprogramowanie.
/* systemy te dobrze wspierają codzienna działalność operacyjną firmy; mogą być wystarczające.
Mają jednak swoje wady: problem może się pojawić przy potrzebie dostępu do informacji
przekrojowej w celu analizy itp..*/
Wady:

–

wspomaganie decyzji ekonomicznej oganicza się do czytania wykazów danych

–

nie ma współpracy pomiędzy istniejącymi w przedsiębiorstwie bazami danych

–

komputeryzacja obejmuje głównie końcowe efekty działalności firmy

–

niektóre dane mogą w sposób niezamierzony być dublowane (np. zmiana adresu w jednej z baz
danych nie prowadzi ze soba zmian w innych bazach prowadzonych w ramach
przedsiębiorstwa, dochodzi w ten sposób do niespójności danych)

2) podejście współczesne – kompleksowa informatyzacja
Wcześniej w ujęciu tradycyjnym koputeryzowano poszczególne działy osobno, a następnie
starano się te działy jakoś powiązać. Mogły powstac różne bazy danych dla poszczególnych
działów. W informatyzacji kopleksowej dąży się do stworzenia jednolitej bazy danych,która
pomieści dane z kazdego działu.

Etapy kopleksowej informatyzacji firmy
1) Sformułowanie celów,
2) Analiza działalności firmy (w tej fazie zajmujemy się tym co system ma robić)
- realizowane procesy,
- struktura i przepływ informacji,
- obieg dokumentów.
3) Projektowanie (DESIGN) – tworzymy obraz jak system ma to robić
4) Wdrożenie
5) Gotowy system

Punkty od 1) do 5) są często okreslane jako projekt (PROJECT).

Dopiero w końcowej fazie powstawane systemu ma miejsce przenoszenie informacji na nośniki
maszynowe,włączenie istniejących baz danych i instalowanie komputerów (najczęściej
połączonych ze sobą w sieć lokalną).

Wartość systemu informatycznego jest określana stopniem w jakim wspomaga on założone cele
danej firmy. Celem może być m.in. ekspansja firmy na rynku, wdrożenie nowej technologii, itd.

/*Informatyzacja firmy nie jest procesem prostym. Wymaga pewnego przygotowania. Nie kazdy
system informacyjne jest gotowy na przyjęcie systemu informatycznego.Tam gdzie działalnośc jest
uporządkowana w jakiś sposób, wdrożenie informatyczne prowadzi się łatwiej i nie prowadzi to do
zwiększenia zamętu.*/

Obieg dokumentów

i informacji nieformalnej

środkami tradycyjnymi

System rozliczeń

finansowych

Ewidencja

materiałów

i zapasów

Ewidencja osobowa

(kadry)

Przygotowanie

produkcji

Cechy udanego systemu informacyjnego:

podporządkowany

firmie
|

niezawodny -- System Informacyjny – opracowany szybko

|

elastyczny

Nie kazdy system informacyjny udaje się wdrożyć. Istnieje problem niepowodzenia systemu
informacyjnego:

1) Obok opracowania samych programów, inforamtyzacja instytucji, firm i całych baz danych

wymaga przygotowania odpowiedniej infrastruktury w postaci sieci komputerowych oraz
systemów telekomunikacyjnych.

2) Uporządkowania wymaga struktura informacji i drogi jej obiegu, w tym wzory dokumentów

i raportów.

3) Przyjęte modele powinny zachować stabilnośc w razie zmian w gospodarce, systemie

podatkowym, telekomunikacji.

Elementy inżynierii oprogramowania:

- metody,
- narzędzia,
- zarządzanie.

Wprowadzimy istotne w inżynierii oprogramowania pojęcie – cykl życia oprogramowania.
Pod tym abstrakcyjnym pojęciem rozumie się najważniejsze etapy tj. analiza,projektowanie,
wdrożenie oraz użytkowanie systemu, występujące w czasie, gdy pewien system jest wytwarzany i
eksploatowany. Przykładem może być cykl życia z nastepującymi etapami:

1) okreslenie wymagań i analiza,
2) projektowanie,
3) implementacja -> realizacja systemu,
4) testowanie,
5) wdrozenie i utrzymanie.

Metody inzynierii oprogramowania:
Metodą w i.o. będziemy nazywać procedurę służącą realizacji pewnej fazy powstawania systemu.
Często stosuje się pojęcie - metodyka, rozumiane jako zbiór powiązanych ze sobą metod opartych
na wspólnych podstawach.

Narzędzia i.o.
W metodzie często znajduje zastosowanie wiele róznych technik, np. diagramy DFD, język
UML,itp. do tworzenia dokumentacji oraz porozumiewania się (komunikacji).
Techniki te są często komputeryzowane i w ten sposób powstaja narzędzie i.o.

WYKŁAD 2: 10 -10 – 2007

Narzędzia i.o cd.
Systemy CASE (Computer Aided Software Engineering) są to środowiska wspomagające
powstawanie oprogramowania ze szczególnym uwzględnieniem wczesnych faz, takich jak analiza i
projektowanie.

Inną charakterystyczną cechą współczesnych narzędzi i.o. jest podejście obiektowe.
Obiektowość w informatyce oznacza pewein paradygmat(ogólne podejście).Stosowane dotychczas
z powodzeniem w programowaniu oraz w bazach dnych .Charakterystyczne dla podejscia
obiektowego jest zastosowanie klas oraz konkretnych oraz konkretnych wystąpień tych klas
(obiektów) co pozwala na bardziej bezpośrednie odzwierciedlenie rzeczywistości w programach
czy bazach danych.
Podejscie obiektowe od pewnego czasu jest stosowane w analizie i projektowaniu systemów
informatycznych. Są to dziedziny lezące w zakresie współczesnej i.o.

Zarządzanie

Wytwarzanie oprogramowania na skale przemysłową , może być traktowane jako pewien proces
produkcyjny.Związane są z tym zagadnienia takie jak:
-harmonogramowanie,
-kosztorysowanie,
-stosowanie określonych technologii,
-zapewnienie i kontrola jakości,
-zarządzanie personelem,
-itp.kwestie własciwe dla produkcji,przemysłu.

Technologie w i.o.

Produkcja na skalę przemysłowa wymaga opracowania wdrożenia odpowiednich technologii.
Wytwarzanie oprogramowania coraz rzadziej traktuje się jako swobodną twórcza działalnośc
mająca znamiona sztuki.
...
Technologia obejmuje:
-wykaz niezbędnych operacji,
-wpływ operacji na jakość,
-plan wykonania operacji,
-wymagania dla wykonawców,
-dobór narzędzi,
-obowiązuące normy,
-standardy,
-sposób oceny wydajności,
-zapewnienie i kontrola jakości.

Wdrożenie konkretnej technologii tworzenia produktów informatycznych wiąże się z automatyzacją
i standaryzacją prac w poszczególnych fazach cyklu życia ,obejmując m.in. właściwe opracowanie i
opanowanie technologii, w tym dostarczenie narzędzi odpowiednich dla nowej metodyki;pojęcia
metodyki i technologii bywają tutaj utożsamiane.

Okreslenie wielkości programu(produktu)

Sposoby:

-liczba linii kodu(KLOC – kilo lines of code)
-liczba osobolat potrzebnych na jego wytworzenie.
Duże – 200 lub więcej osobolat,
małe ok.2osobolat
średnie od kilkudziesieciu do stu lub więcej osobolat

Rodzaje produktów programistycznych

Produkty:
-eksperymentalne(akademickie): tworzone celem wykonania pewnych
badań,eksperymentów;wspomagające prace naukowców itp. Ich twórcami mogą być np. s

tudenci,naukowcy itp. Nie są powielane w wielu kopiach,a przy ich wytwarzaniu nie obowiązuja
pewne wymogi, konieczne przy tworzeniu produktów przemysłowych;
-przemysłowe(komercyjne,na sprzedaż,wyrób przemyślany i udokumentowany):

*obróbka informacji (z przetwarzaniem danych)
*systemy sterowania: musi posiadać wysoką niezawodność, metody formalnej weryfikacji.

Modele produkcji oprogramowania

Model produkcji oprogramowania oznacza pewną strategię realizacji cyklu życia, szczególnie w
jego części przypadającej na wytworzenie systemu. Do podstawowych strategii planowania cyklu
życia można zaliczyc modele pokazane na diagramie:

Model kaskadowy
Oznacza sytuację w której system jest wytwarzany w wyniku dobrze opanowanego postepowania ,

MODELE PRODUKCJI OPROGRAMOWANIA

Model

wodospadu

(kaskady)

Prototypowanie

Model

spirali

Opracowanie

ewolucyjne

a porządek wykonywania czynności jest w znacznym stopniu sekwencyjny.W praktyce,rzeczywista
praca prawie nigdy nie przebiega sekwencyjnie dlatego możliwe są powroty do poprzednich
faz(etapów).ponad to część prac jednej fazy może być wykonywana równolegle z pracami innej
fazy.Podobnie jednak jak w przypadku ilustrującego to podejście wodospadu zasadniczy kierunek
jest ściśle okreslony.

Model spirali
Może on być zilustrowany nastepującym rysunkiem:

Można go zatem zobrazować za pomocą płaszczyzny podzielonej na przykładowe stany rozwoju
systemu położone w każdej ćwiartce.Po kazdym przejściu przez wszystkie ćwiarki otrzymujemy
pewną wersję systemu, a ponieważ spirala powiększa się, poszerza się zakres realizowanych funkcji
oraz rosną wymagania użytkowników.

Prototypowanie
W tym przypadku nacisk kładzie się na szybkie uzyskanie elementow działającego systemu oraz na
stałe uwzględnianie opinii użytkowanika

Opracowanie ewolucyjne
Stanowi w pewnym sensie przeciwieństwo modelu kaskadowego.Zakłada się tutaj uzyskanie
kolejnych wersji gotowego produktu, z których kazda posiada określoną gotowość operacyjna, ale
przede wszystkim stanowi źródło ewentualnych dalszych badań.

WYKŁAD 3: 17 – 10 – 2007

Dokumentowanie
Typy dokumentów:
specyfikacja wymagań, specyfikacja funkcjonalna, dokumentacja projektowo-programowa,
teksty źródłowe kodu, plany testowania i przebieg testów, informacje o zmianach, dokumenty
administracyjne, dokumenty statystyczne, instrukcje i podręczniki.
Produkt informatyczny jako efekt przetwarzania dokumentów
Zbieranie założeń(etap)

|

specyfikacja wymagań (efekt) -> Analiza problemowa(etap)

|

specyfikacja funkcjonalna(efekt) -> Projektowanie systemu(etap)

|

dokumentacja projektowo-programowa

|

. . .

Schemat ten jest być może trochę przesadzony, ale ma uwzględnić wskazanie jak ważną rzeczą jest
dokumentacja.
W fazie projektowania powstaje dokumentacja projektowo-programowa, która powinna być
sporządzona w sposób ułatwiający dostęp do informacji o każdym module programowym
nazywanym także jednostką projektową.

Atrybuty modułu programowego ( przykładowo )

Moduł

nazwa

Lokalizacja

Przeznaczenie

Żródło

pochodzenia

Kategoria

Relacja

Opis działania

Wymagane zasoby

sprzętowe

Komunikacja

z otoczeniem

Wykaz

zmiennych

Opis procedur

wewnętrznych

Założenia

dodatkowe

Sposób obsługi

błędów

Przykład użycia

Dane o

efektywności

Informacje o

autorach

Użytkownicy dokumentacji

1) Kierownik projektu, autor testów integrujących,
2) Projektanci, autorzy testów funkcjonalnych,
3) Projektanci, autorzy testów jednostkowych,
4) Użytkownicy końcowi (end users)

Ad.1)
-ogólna informacja o składowych oprogramowania,
-źródło pochodzenia fragmentów zapożyczonych,
-zaleznosci pomiędzy jednostkami programowymi, a danymi,
-dane o personelu, kosztach, terminach, wydajności,itp.

Ad.2)
-opis struktury systemu,
-klasyfikacja i identyfikacja składowych,
-interfejs pomiędzy jednostkami programowymi,
-funkcje jednostekprogramowych,
-ch-ka interfejsu.

Ad.3)
-specyfikacja projektu(szczegółowy opis algorytmów i danych),
-szczegółowy opis interfejsów międzymodułowych i odwołań do danych.

Ad.4)
-opis instalacji oprogramowania,
-sposób zainicjowania pracy,
-postać dancyh wejściowych i przewidywanych rezultatów,
-opis sytuacji wyjątkowych i ich obsługi.

Odzyskiwalność oprogramowania i inzynieria odwrotna

Odzyskiwalność – cecha oprogramowania pozwalająca na łatwe wprowadzenie
modyfikacji.Istotnym efektem odzyskiwalności są zwiększone możliwości zrozumienia wcześniej
opracowanych programów.

Sposoby zwiększenia odzyskiwalności

1) Standaryzowanie modlei danych, procesów oraz opisujących je dokumentów,
2) Tworzenie projektów,a następnie kodów wielokrotnego użytku w środowiskach CASE
3) Jakość dokumentowania oraz stosowanie technik projektowanie strukturalnego,
4) Inżynieria odwrotna.

Poziom

konceptualny

Poziom

logiczny

Poziom

fizyczny

Poziom kodu

Inżynieria prosta

Inżynieria odwrotna

Zapewnienie i kontrola jakości
Produkt informatyczny, jak każdy wyrób rynkowy podlega ocenie jakościowej. Organizacje
międzynarodowe takie jak ISO, IEC oraz IEEE przyjęły ustalenia odnośnie zalecanych norm
jakościowych. Zachowanie norm jakościowych nie może być pozostawione jedynie dobrej woli
producenta. Uzyskanie certyfikatu jakości wymaga wprowadzenia systemu zarządzania jakością
zgodnego z normami serii ISO 9000.

Pojęciu jakości systemu informatycznego dotyczy jego cech funkcjonalnych, operacyjnych i
technicznych. Zapewnienie jakości należy do zadań zarządzania.Dla kazdego przedsięwzięcia
powinien być opracowany plan kontroli jakości obejmujący wszystkie kolejne fazy jego tworzenia,
a nie tylko produkt końcowy. Sugeruje się przeprowadzenie od 1 do 4 przeglądów jakościowych w
kazdej fazie. Kazdą kontrolę jakości kończy opracowanie dokumentacji opisującej jej przebieg.

Przykłady terminów związanych z jakościa produktówi usług (ISO8402):
-jakość,
-weryfikacja,
-walidacja

WYKŁAD 4: 24 – 10 – 2007

Modelowanie systemów:
konstruowanie systemu informatycznego jako procesu

Języki modelowania w dość elastyczny, a jednocześnie wystarczająco sformalizowany sposób
opisują system ze szczególnym naciskiem na wczesne fazy jego powstawania(tj.planowanie,analiza,
projektowanie). Dotychczas opracowano sporo języków modelowania wspierających różne fazy
powstawania systemu. Języki te często stanowią element zintegrowanych pakietów
wspomagających inżynierię oprogramowania znanych pod nazwą środowisk CASE. W
szczególności wraz z rozwojem podejścia obiektowego do analizy i projektowania wzrosło
zainteresowanie językiem modelowania UML.

Strategie analizy systemowej
Czynności niezbędne w poczatkowych fazach powstawania systemu polegające na rozpoznaniu i
wyspecyfikowaniu jego zadań określa się terminem analiza systemowa. Wyróżnia się przy tym
szereg strategi analizy systemowej, które można podzielic na dwie klasy:

Współczesna analiza strukturalna reprezentuje tradycyjne podejście do analizy systemu.
Przewiduje ona konkretne badanie systemu z wykorzystaniem technik modelowania procesów i
danych. Charakterystyczne jest przy tym wyraźne oddzielenie modelowania procesów od
modelowania danych, co wyraża się między innymi poprzez wykorzystanie odrębnej techniki do
modelowania procesów ( np. diagramy DFD) w stosunku do modelowania danych, gdzie
wykorzystuje się dość powszechnie diagramy ERD.

Planowanie

Analiza i projektowanie

Budowa

Języki
modelowania

Języki
programowan
ia

Strategie analizy systemowej

Oparte na modelu

Oparte na prototypie

Współczesna

analiza

strukturalna

Inżynieria

informacji

Analiza

obiektowa Prototypowanie

Diagramy przepływu danych ( DFD – data flow diagrams)
Reprezentują funkcje systemu, które są na nich przedstawione jako procesy zdolne do
wykonywania określonych czynności na danych. Podstawowymi elementami na diagramach DFD
są procesy. Poza procesami na diagramach DFD mogą wystąpić jeszcze 3 elementy: przepływy
danych, magazyny danych, encje zewnętrzne(terminatory danych). Na diagramach DFD pojawiają
się zatem elementy danych, które uzupełniaja obraz systemu rozważanego jako zbiór procesów.
Diagramy związków encji ( ERD – entity relationship diagams)
Zawierają dwa podstawowe elementy: encje oraz związki.Stanowią one konceptualny model
danych reprezentujący strukturę informacyjną systemu.

Oprócz modeli procesów i modeli danych w analizie pojawiają się także modele reprezentujące
dynamiczne zachowanie systemu. Modele te pozwalajaą m.in. na uwzględnienie następstwa
zdarzeń odpowiednich sygnałów i procesów sterujących itp. Są z reguły reprezentowane przez
diagramy zmian stanu ( STD – state transition diagrams) oraz grafy przejść (TRG) .

Podsumowując:
Analiza strukturalnadostarcza narzędzi pozwalających na modelowanie trzech aspektów
(wymiarów) systemu.

Wymiary modelowania systemu

Wydaje się że techniki współczesne modelowania systemów są wciąż aktualne.
Inżynieria informacji
Pojęcie to pojawiło się w latach 80-tych i jest związane z nazwiskiem J.Martina..Jest to także
strategia związna z modelowaniem z tym, że preferuje tzw. danocentryczne ujęcie systemu, gdzie
centralną role pełnia dane stanowiące bazę dla pozostałych elementów systemu.

Danocentryczne ujęcie systemu

Procesy (DFD)

Dynamika
(STD, TRG)

Dane (ERD)

Dane

zapis

odczyt

usuwanie

aplikacja

zarządzanie

aktualizacja

Analiza i projektowanie obiektowe
Metody obiektowe są od pewnego czasu z powodzeniem stosowane w programowaniu oraz w
bazach danych.W szczególności wprowadzono komercyjne języki programowania wspierające
obiektowy styl programowania, a także systemy zarządzania bazą danych, gdzie zastosowano
rozwiązania obiektowe. Ważnym zjawiskiem we współczesnej inżynierii oprogramowania jest
przenikanie metdo obiektowych do analizy i projektowania systemu.
Prototypowanie
Strategia oparta na prototypie została zaczerpnięta z tradycyjnych dziedzin wytwarzania jak np.
budowa maszyn.Prototyp to zakończona, działająca wersja systemu, programu nadająca się do
pokazania użytkownikowi celem poznania jego opinii.Może być dalej rozwijany z uwzględnieniem
nowych informacji pozyskanych od użytkownika.Oznacza to , ze zamiast budować szczegółowe
modele w tym podejściu nacisk kładzie się na wystarczająco wczesne uzyskanie prototypu.

Model a diagram
Oba te pojęcia mimo,ze częstosa używane zamiennie, nie są synonimami.
Model stanowi niesprzeczny i uporządkowany opis systemu- może być traktowany zatem jako
obraz tego systemu na pewnym poziomie szczegółowości.Pojedynczy model zazwyczaj nie
wystarcza do przedstawienia wszystkich aspektów systemu, ani też do jego implementacji
(realizacji) stąd z reguły stosuje się szereg modeli, które powinny być: wzajemnie spójne, nie
zawierać informacji nadmiarowych.
Diagram jest pewnym sposobem ukazania modelu.Diagram służy do opisania (przedstawiania)
modelu. Aby przedstawić pewien model w ogólnym przypadku może być potrzebne wiele
diagramów, a pewien element modelu może pojawić się na wielu diagramach.

Perespektywy modelu:
Konstruując model najczęściej uwzględnia się jedna z nastepujących perespektyw:

–

pojęciową (koncepcyjną),

–

projektową,

–

implementacyjna.

WYKŁAD 5 30-10-2007 ( Skrócony : godziny rektorskie)
Perespektywa pojęciowa dotyczy pojęć z dziedziny problemowej, analizowane są operacje
wykonywane na tzw.bytach.

Perespektywa projektowa uwzględnia środowisko implementacji, z tym, że bardziej istotne jest
projektowanie interfejsów niż samo kodowanie.

Perespektywa implementacyjna jest związana bardziej bezpośrednio z wytwarzaniem kodu.

Konstruując model powinno się uwzględnić jedną wyraźnie okresloną perespektywe. Aby
poprawnie zinterpretowac model trzeba wiedzieć jaki model został użyty.

Modele fazy analizy

Modele fazy analizy mają na celu formalne przedstawienie:
-aktualnie wykonywanych funkcji w systemie oraz struktury przetwarzanych danych,
-nowych wymagań zgłoszonych wobec przyszłego systemu

Modele te stanowią dokumentację fazy analizy sporzadzoną z wykorzystaniem przejrzystych
technik graficznych wystarczająco elastycznych, a z drugiej strony odpowiednio sformalizowanych.
Efekty analizy można wykorzystywac w dalszych etapach, szczególnie w fazie projektownia, która
występuje po analizie.

Modele w fazie projektowania

Projekt powstaje na bazie wiedzy uzyskanej o systemie i zapisanej (np. w postaci modeli fazy
analizy). Faza projektowania ma na celu uzyskaie takiej specyfikacji systemu, aby można było
napisać programy.
O ile w podejsciu strukturalnym analiza i projektowanie są dośc wyraźnie oddzielone od siebie
(m.in. przez zastosowanie różnych technik modelowania) to w podejściu obiektowym analiza i
projektowanie są bardziej powiazane.

Modele implementacjne

Faza implementacji dotyczy fizycznej realizcji systemu i ma stanowić praktyczną realizację wielu
wcześniejszych założeń zawartych w specyfikacji.Nowe metody modelowania wspierane m.in.
przez język UML w pewnym zakresie obejmują fazę implementacji.

ANALIZA

Aktualnie wykonywane
funkcje

Wymogi

Uporzadkowany opis
przyszłego systemu

WYKŁAD 6 7-11-2007

Język UML w modelowaniu systemów

Język UML (Unified Modeling Language) jest efektem trwających od około 10 lat prac nad

ujednoliceniem narzędzi do modelowania systemów. Jako główny powód użycia UML do
modelowania systemów można wymienić problem komunikacji. W trakcie realizacji dowolnego
projektu powstaje potrzeba przekazywania idei, pomysłów, a także wyników własnej pracy innym
członkom zespołu,język naturalny jest na tyle nieprecyzyjny,że w bardziej złożonych przypadkach
może powodować nieporozumienia, z kolei kod programu jest wystarczająco precyzyjny ale zbyt
szczegółowy i często nieczytelny. Języka modelowania używa się zatem tam, gdzie wymagana jest
pewna ścisłość wyrazania się, a jednoczesnie chcemy uniknąć „ugrzężnięcia” w szczegółach.
Język modelowania taki jak UML pozwala uzyskac ogólną wizję systemu jeśli użyc np. diagramu
klas, cz diagramu przypadków użycia. Z kolei tam , gdzie niezbędne są bardziej szczegółowe
informacje można wykorzystać np. diagramy interakcji pokazujące w jaki sposób klasy (obiekty)
za sobą współpracują. Język UML 2.0 udostepnia 13 typów diagramów opisujących różne aspekty
modleowanego systemu. Inna przyczyną popularności UML wydaje się pojawienie obiektowości w
metodach informatyki. Towarzyszy temu chętne stosowanie bądź przestawianie się na tzw.
paradygmat obiektowości. Środki wyrazu UML ( techniki UML ) zostały pomyslane tak, aby
pomóc w przejściu do obiektowości.
Przegląd diagramów w UML 2.0
W praktyce UML tworzy graficzną reprezentację systemu w postaci logicznie powiązanych za sobą
diagramów. Diagramy te pozwalają prezentować zarówno modele ogólne jak i bardziej
szczegółowe. Architekt, projektant, czy programista może posłużyc się diagramami UML
analogicznie jak wykonawcy używaja wcześniej opracowanego projektu budynku. Poszczególne
osoby w zespole wykonawców potrzebują spojrzenia na system z róznej perespektywy , co
zapewnia różnorodność diagramów UML.
W wersji UML 1.4 uzywano 8 typów diagramów oraz dodatkowo 2 „nioficjalne”(diagram
pakietów, diagram obiektów). W wersji 2.0 występuje 13 typów diagramów, które umownie można
podzielić na dwie grupy:

1) diagramy reprezentujące strukturę ( statykę systemu ),
2) diagramy reprezentujące dynamikę systemu.

Diagramy UML 2.0 [za Wrycza i inni, 2006]

Diagramy UML 2.0

Elipsy reprezentują pewne (umownie wyodrębnione) grupy diagramów, a zwykłe prostokąty
odpowiadają stosowanym w praktyce 13 następującym typom diagramów:

1) Diagram klas ( class diagram),
2) Diagram obiektów (object diagram),
3) Diagram pakietów (package diagram),
4) Diagram struktur połączonych (composite structure diagram),
5) Diagram komponentów (component diagram),
6) Diagram rozlokowania (deployment diagram),
7) Diagram przypadków użycia (use case diagram),
8) Diagram czynności (activity diagram),
9) Diagram maszyny stanowej (state machine diagram),
10) Diagram sekwencji (sequence diagram),
11) Diagram komunikacji (communication diagram),
12) Diagram harmonogramowania (timing diagram),
13) Diagram sterowania interakcją ( interaction overview diagram).

Diagramy

struktury

Diagramy

dynamiki

Diagramy

wdrożeniowe

Diagramy

interakcji

Diagram

klas

Diagram

obiektów

Diagram

pakietów

Diagram

struktur

połączonych

Diagram

komponentów

Diagram

rozlokowania

Diagram

sterowania

interakcją

Diagram

harmonogramowania

Diagram

komunikacji

Diagram

sekwencji

Diagram

maszyny
stanowej

Diagram

czynności

Diagram

przypadków

użycia

Diagram klas

Stanowi on graficzną reprezentację statycznych, deklaratywnych elementów dziedziny
przedmiotowej z uwzględnieniem związków pomiędzy nimi. Jest on dość mocno powiązany z
projektowaniem obiektowym systemu informatycznego, a nawet z jego implementacją w
okreslonym języku programowania. Podstawowymi elementami diagramu są klasy reprezentowane
przez prostokąty, które mogą zawierać informacje o polach i metodach klasy. Rozważmy prosty
przykład modelu dla biblioteki:

Związki pomiędzy klasami są oznaczone liniami, które mogą mieć opcjonalnie strzałki wskazujące
kierunek związku. Zakonczenia związków mogą także posiadać specjalne oznaczenia krotności,
które pokazują ile obiektów danej klasy może brać udział w związku(relacji), np. istnieje dokłądnie
jeden katalog, z którego może korzystać teoretycznie dowolna liczba użytkowników (0..*). Na
diagramie pokazano także tzw. agregację pomiędzy Ksiązką, a Biblioteką – od strony biblioteki
agregacja jest oznaczona rombem. Agregacja oznacza związek typu „całość-część” pomiędzy tymi
klasami, przy czym całość jest po stronie rombu.

Diagram obiektów

Stanowi wystapienie diagramu klas odwzorowujące strukturę systemu w wybranym momencie jego
działania.

Diagram pakietów

Ma za zadanie przedstawić w przejrzysty sposób logiczną strukturę systemu. Służy do tego zbiór
pakietów połączonych ze soba zależnościami i zagnieżdżeniami. Jednym z celów jest
uporządkowanie struktury zalezności w przypadku, gdzie występuje wiele klas, przypadków użycia
i innych elementów. Przyjmuje się, że pojedynczy pakiet zawiera w sobie pewną liczbe elementów
systemu, które wspólnie opisuje jedno trafnie dobrane okreslenie. Całość wykonuje pewne
sprecyzowane zadanie.

PracownikBiblioteki

+imie: string

+nazwisko: string

Katalog

Bibliotekarz

Wypozyczajacy

+imie: string

+nazwisko: string

Biblioteka

Ksiazka

+autor: string

+tytul: string

+numer: int

+status: int

AsystentBibliotekarza

uzywa

1

0..*

uzywa

wypozycza

Na diagramie umieszcza się pakiety i wskazuje zależności między nimi, w tym także zależnośc
podległości ( czyli generalizacja-specyfikacja) oznaczone strzałką z pustym grotem. Dzięki takiemu
zabiegowi uzyskuje się na jednym diagramie obraz całości, bądź dużej części systemu.
/*zależność podległości oznacza, ze Analiza rezerwacji jest specjalizacją Zarządzania ksiązkami */

MagazynKsiazek

ZarzadzanieKsiazkami

Zamowienia

BazaCzlonkowBiblioteki

AnalizaRezerwacji

WYKŁAD 7, 14-10-2007

Diagram struktur połączonych

Ten rodzaj diagramu pojawił się dopiero w wersji 2.0. Jego zadaniem jest modelowanie
współdziałania(współpracy) klas, interfejsów i komponentów, które są zaangażowane w realizacje
pewnego zadania. Zewnętrznie diagram struktur połączonych jest nieco podobny do diagramu klas,
należy jednak podkreślić,że diagram klas przedstawia statyczny obraz systemu ( fragmentu
systemu) podczas gdy diagram struktur połączonych obrazuje elementy wykonujące wspólne
zadania, typowe sposoby użycia elementów, czy związki między nimi. Wspomniane tutaj aspekty
nie zawsze łątwo jest przedstawić na innych diagramach. Rozważymy prosty przykład
uzasadniający użycie diagramu struktur połączonych oraz stoswane przy tym notacje. Zaczniemu
od elementarnego diagramu klas, który pokazuje związek pomiędzy fakturą, a jej częściami.

Na diagrami widać typowy sposób przedstawienia związku pomiędzy fakturą, a jej
częściami.Zwiazek ten oznaczony jest rombami wypełnionymi od strony całości i nazywa się
kompozycją.Kompozycja jest w pewnym sensie podobna do agregacji użytej wcześniej w diagrami
klas.Różnica między nimi polega nie tylko na oznaczeniu (w przypadku agregacji romb jest pusty
wewnątrz). Oba te rodzaje związków stanowią rózne rodzaje relacji całość-część(romb jest po
stronie całości). W odróżnieniu od agregacji, gdzie części mogą występować samodzielnie, w
przypadku kompozycji części są ściśle uzaleznione od całości (zniknięcia całości oznacza
zniknięcie części).
Diagram klas może okaząc się wystarczający, z tym,że niezbyt praktyczny. Chodzi mianowicie o to,
że wydzielenie nagłówka i danych w obrębie klasy może się wydać zbędnym wówczas, jeśli
chcemy tylko podkreślic fakt, że faktura składa się z takich części. W takim przypadku pomocny
okazuje się odpowiedni diagram struktur połączonych , który przybiera postać pokazaną na
rysunku:

FAKTURA

Naglowek

Dane

FAKTURA

+Naglowek

+Dane

Naglowek

Dane

Naglowek

Dane

1..*

1

Na tym diagrami faktura jest modelowana jako klasa, a nagłówek i dane jako jej części.Łącznik
pokazuje związek pomiędzy częsciami, a podane krotności mówią, że kazda faktura ma jeden
nagłówek i co najmniej jedno pole danych. Istnieje jeszcze jeden typ diagramu struktur
połączonych, który wykorzystuje tzw, element współpracy. Wykorzystuje się przy tym dwie
notacje, pokazane na przykładach.
Notacja1

Notacja 2

Elipsy narysowane przerywaną linią oznaczają element współpracy z którym są połączone lub
wewnątrz którego leżą współpracująe klasy.

Diagram komponentów

Jest to rodzaj diagramu wdrożeniowego, który wskazuje pewna organizację oraz zależności
pomiędzy komponentami. Podobnie jak diagram pakietów (omawiany wczesniej) diagram
komponentów ma prezentować podział systemu na mniejsze elementy i pokazywać zalezności
pomiędzy nimi. O ile jednak diagram pakietów dotyczył logicznego podziału systemu to diagram
komponentów dzieli system na fizyczne komponenty oprogramowania (elementy) tj.: pliki,
biblioteki, programy wykonywalne,itp. Rozważymy następujący przykładowy diagram
komponentów

Student

Zapisy

Kurs

1..*

1

1

1..*

Element wspolpracy

(co llab o r atio n )

Zapisy na kurs

Student

Zapisy

Kurs

1..*

1

1

1..*

Zapisy na kurs

Na diagramie przedstawiono fizyczne komponenty systemu wraz z interfejsami, które udostepniają,
bądź których wymagają, Warto zaznaczyc, ze w UML2.0 zmienil się sposób oznaczenia
komponentów.Obecnie jest to prostokąt z charakterystycznym ideogramem w prawym górnym
rogu.Udostępnione interfejsy są zaznaczonekółkami, natomiast interfejsy, kórych komponent
wymaga są oznaczone półokręgiem (gniazdem). Notacja kółko-gniazdo (ball and socket) pojawiła
się także w UML2.0 i służy do pokazania dwóch komponentów poprzez interfejs np. komponent
DB Manager udostępnia interfejsy do różnych baz danych, a komponent Aplikacja.exe wymaga
wskazania takiego interfejsu.

Diagram rozlokowania

Diagram rozlokowania pokazuje schemat wdrożeniowy konfiguracji oprogramowania.
Przedstawimy to na przykładzie prostej konfiguracji sprzetu i oprogramowania potrzebnej do
połaczenia z interfejsem komputera domowego.

GUI

Szyfrowanie.dllI

Aplikacja.exe

DB Manager

RSA

MS SQL Oracle DBL

MySQL

Postgre SQL

Szyfrowanie
DES

Baza danych

Komputer PC

Modem

Polaczenie telefoniczne

Drukarka

Serwer WWW

Diagramy dynamiki

Diagram przypadków użycia

Ten rodzaj diagramu przedstawia system z punktu widzenia użytkownika tzn. pokazuje, co system
robi, a nie jak to robi. Rozważymy prosty diagram przypadków użycia.

Podstawowe elementy diagramu przypadków użyca to:
-aktorzy
-przypadki użycia
-zwiazki pomiędzy powyzszymi
wystepujące w danej dziedzinie problemowej. Na rys. z naszego przykąłdu aktorzy są
reprezentowani przez ludziki lub ( w jednym przypadku) prostokąt oznaczony tzw. stereotypem
<<Actor>>.Ponad to widac elipsy oznaczające przypadki użycia wraz z krótkim opisem. Aktorzy
(użytkownicy systemu) mogą być zarówno ludżmi jak i systemami zewnętrznymi. W tym drugim
przypadku warto je oznaczac prostokątami.Każdy przypadek użycia jest powiązany z jednym lub
wieloma aktorami. Linia zakończona pustą strzałką oznacza,że jedne aktor jest szczególnym
przypadkiem drugiego. Relacja <<include>> pomiędzy przypadkami uzycia informuje, że jeden
przypadek użycia zawiera drugi. Diagram sam w sobie nie zawiera zbyt wiele informacji, dlatego
potrzebna jest dokumentacja w postaci odpowiednio napisanego przypadku użycia. Przypadki
użycia są skutecznym narzędziem zbierania wymagań, a diagramy przypadków użycia pomimo
swej prostoty mogą służyć jako rodzaj spisu treści dla wymagań modelowanego systemu.

Diagram czynności

Dostarcza on środków do graficznego przedstawienia sekwencyjnych i/lub współbieżnych
przepływów sterowania oraz danych pomiędzy uporządkowanymi ciągami czynności, akcji i
obiektów. Diagram ten może być zastosowany tam, gdzie chcemy przedstwic rolę obiektów w
ramach jakiegoś procesu.

Na diagramie tym zaokraglone prostokąty reprezentuja konkretne zadania(akcje), które powinien
wykonać system, badz jego elemeny. Rombami oznaczono miejsca podejmowania decyzji.
Pogrubione poziome linie natomiast oznaczają sytuacje, w których nastepuje rozgałęzienie w
wywkonywaniu czynności tak, że są one wykonywane równolegle. Przykładowo na diagramie
pokazano, że można równocześnie sprawdzać, czy książka jest dostępna oraz to czy wypożczający
może ją wypożyczyć. Modelując rzeczywisty system należałoby okreslić jakie jego elementy są
odpowiedzialne za kazde z działań, a także zadbac, aby nie było wątpliwości, że wysyłanie ksiązki
następuje tylko wtedy, gdy jest ona dostepna oraz prosi o nią osoba do tego uprawniona.

Kontakt z pracownikiem biblioteki

Przyjecie zamowienia na ksiazke

Sprawdzenie czy ksiazka jest w ksiegarni

Czy klient moze wyposzyczyc ksiake

usun zamowienie

niedostepna

nie moze

dostepna

moze wypozyczyc

wyslanie ksiazki

WYKŁAD 8, 28-11-2007

Diagram maszyny stanowej

Diagram ten reprezenuje skokowe(dyskretne) zachowanie stystemów w odniesieniu do pewnych
stanów ora zprzejsć pomiedzy tymi stanami (zmian stanu, systemy stan-przejscie).

Diagram ten przypomina z wyglądu diagram czynności z tym, że tamten diagram skupia się na
opisywaniu jakiegoś procesu, w którym uczestniczy wiele obiektów, natomiast diagram maszyy
stanowej pokazuje jakie są możliwe stany konkretnego obiektu. W naszym przykładzie dane mogą
znajdować się w róznych stanach pokazywanych tutaj jako zaokraglone prostokąty. Strzałki
oznaczają przejścia pomiędzy stanami. Może się zdarzyć, że istniej więcej niż jedna droga przejscia
pomiędzy stanami. Zarówno rozwidlenie jak i scalenie dwóch ścieżek zaznaczono pogrubioną
poziomą linią.

Diagram sekwencji

Opisuje on interakcję (współdziałanie) pomiędzy instancjami w postaci sekwencji (ciągu)
komunikatów. Jest on także nazywany niekiedy diagramem przebiegów, gdyż pokazuje zarówno
kolejność przesyłania kmunikatów jak i czas istnienia obiektów.

Przegladanie

Edycja

Zmiany zatweirdzone

Zmiany odrzucone

Rozpoczecie pracy z danymi

Wypozyczalnia

Biblioteka

Katalog

Chce wypozyczyc

Wyszukaj

Zwrot wynikow

Wypozycza ksiazke

Czas na diagrami płynie w dół.Podłużne prostokąty narysowane wzdłuż przerywanej linii oznaczają
czas życia obiektu z którego wychodzi linia.

Diagram komunikacji

Diagram ten służy do zobrazowania dynamiki systemu w sensie oddziaływania na siebie obiektów
oraz przesyłania pomiędzy nimi komunikatów. O ile jednak diagram sekwencji pokazywał
kolejność przesyłania komunikatów oraz czas istnienia obiektów, to diagram komunikacji
koncentruje się na współpracy pomiędzy obiektami.

Linie jak zwykle oznaczają związki pomiędzy obiektami. Strzałki pokazują kierunek przesyłania
komunikatów, a numery ich kolejność. Warto zwrócić uwagę, że model wykonany jest na dośc
wysokim poziomie abstrakcji, tzn. pokazane tu związki i komunikaty mogą się znacznie różnić od
tego co zastosuje później projektant, czy programista implementując system. We wstępnej fazie
model przedstawia system od strony konceptualnej (diagram ma być okazany np.kierownictwu)
natomiast w fazie implementacji ważne są takie cechy jak łatwość utrzymania i rozbudowy
systemu.

Diagram harmonogramowania

Jest to diagram, który reprezentuje zmiany dopuszczalnych stanów na osi czasu. Warto zauważyć,
ze jest to nowy typ diagramu interakcji wprowadzony w wersji UML 2.0. Wydaje się, że jego
pojawienie może okazać się pomocne w modelowaniu i projektowaniu systemów czasu
rzeczywistego,a także aplikacji, których działanie jest powiązane z urządzeniami zewnętrznymi.

Diagram harmonogramowania obrazuje zachowanie obiektu z naciskiem na dokładne okreslenie
czasu kiedy obiekt jest poddawany jakimś zmianom lub sam wykonuje pewne działania.
Przykładowy diagram harmonogramowania w dwóch różnych notacjach pokazano na rysunkach
dotyczących użytkowanika karty.

Diagram sterowania interakcją

Podobnie jak poprzednie jest on nowością w UML2.0. Jest on swego rodzaju połączeniem
diagramu czynności z innym diagramem interakcji ( z którymś z tych diagramów). Notację ma
podobną do diagramów czynności z tą róznicą,że zaokrąglone prostokąty, które reprezentowały
akcje systemu zostały zastapione przez zwykłe prostokąty, które mogą mieć dwie postacie

–

prostokąt zawiera jakiś diagram interackji

Notacja czasowa

30sek.

45 sek.

Nic nie robi

Czeka na akceptacje

Czeka na wykonanie

Podaje PIN

U

zyt

ko

w

n

ik

ka

rt

y

Notacja zadaniowa

U

zyt

ko

w

n

ik

ka

rt

y

...

czeka...

czeka...

Podaje
PIN

–

prostoką zawiera odnośnik do już istniejącego diagramu interakcji

W tym wariancie sytuacja upraszcza się , gdyż w prostokątach zamiast diagamu podajemy
odwołanie ( referencję ) do niego
Studium przypadku: Modelowanie fragmentów funkcjonowania lotniska
W dalszej części wykładu omówimy zaczerpnięte z literatury[Graessle i inni,2006] studium
przypadku dotyczące funkcjonowania wybranego fragmentu lotniska. W szeczególności zostaną
wziete pod uwagę takie zagadnienia, z którymi podrózny może zetknąc się w praktyce tj. procedura
odprawy pasażera oraz wejscia na pokład.Ogólnie biorac można wyodrebnic następujący ciąg usług
z jakich korzystają pasażerowie na lotnisku

ref

Dostarcz ksiazke

ref

Wyszukaj ksiazke

Ksiazka nie znaleziona

Ksiazka znaleziona

Podróż taksówką

Pasażer
wypożyca wózek

Pasazer szuka stanowiska

odpraw na panelu info.

Zajmuje przydzielone

miejsce

Zgłasza się przy bramce

przed wejsciem na pokład

Odszukuje bramkę

odprawy jego samolotu

Poddaje się odprawie

i oddaje bagaż

Kupuje cos
do czytania

Poddaje się
kontroli paszpor-
towej

Kupuje alkohol
w sklepie
wolnoclowym

Poddaje się
kontroli
bezpieczeństwa

Wsiada
na pokład

Zapina pasy
i jest gotowy do startu

Jest to schemat operacji, w których z reguły bierze udział pasazer zanim jest gotowy do lotu. Nie
wszystkie etapy tu wyróznione wiążą se z interesującymi nas obszarami pracy lotniska.Te, które są
istotne ujęto w ramki.Warto także zauwazyć,że pokazany scenariusz jest wprawdzie typowy, ale
dotyczy sytuacji, gdzie nie wystapiły sytuacje odbiegające od tego schematu jak np. pasazer ma
tylko bagaz podreczny, nie dokonuje zakupów, spóźnił sę i przechodzi przyspieszoną odprawe itp.
Powstaje pytanie czy tego rodzaju wymienione przypadki maja rzeczywiste znaczenie podczas
odprawy pasażerów. Ponadto, aby pomóc w ilustracji analizowanych zdarzeń można przedstawić
także schematyczny plan lotniska.

Z procedurą odprawy łaczą się pewne obszary pracy lotniska, które sąsiadują z tym dotyczacym
samego pasażera. Należą do nich m.in. kasy biletowe , odprawa paszportowa itp. Procedura
odprawy wymaga wymiany danych z tymi obszarami. Celem naszego studium jest poznanie nieco
bardziej rozbudowanego przykładu zastosowania UML.Tak ogólnie postawione zadanie może być
dalej uszczegółowione nastepująco:

taxi

bus

bramki

Odprawa
tranzytowa

Sklep
wolnoclowy

Punkty odpraw

Wozki
bagażowe

Punkt
kontroli paszportowej

Punkt
kontroli
bezpieczeństwa

Punkt celny

Punkt kontroli
paszportowej
przyloty

Kiosk z prasą

WYKŁAD 9,05-12-2007

1) Bilet lotniczy składa się z biletu własciwego oraz kilku dodatków.Ma on zatem postać

książeczki, gdzie każdemu etapowi podróży poświęcono osobną sekcję, np.bilet może
zawierac jeden kupon na lot Rzeszów-Warszawa, drugi Warszawa-Frankfurt,a trzeci
Frankfurt-Chicago.Podczas poszczególnych odpraw odpowiedni kupon zostaje zamieniony
na kartę pokladową.

2) Rozrózniamy pojęcia: lot i numer lotu. Numer lotu może mieć np.postać LH435 lub

LX016.Okresla on regularny przelot z lotniska początkowego do lotniska docelowego,
czyli,że przewidziano tki lot w rozkładzie. Lot natomiast okresla się przy użyciu numeru
lotu i daty np.LX016 3-12-2007,jest to zatem rzeczywista realizacja numeru lotu.Lot mozę
być odwolany z powodu niekorzystnych warunków atmosferycznych, natomiast numer lotu
obowiązuje przez cały okres wykonywania kursu na stałej trasie i w stałym czasie.

3) Rozróznimy trzy formy odprawy:

- zwykła (z bagazem w punkcie odpraw),
- ekspresowa (bez bagażu w specjalnym punkcie odpraw),
- automatyczna (bez bagazu)

Modele.prerespsktywy diagramy
Modele buduje się w kontekście funkcjonowania firmy (modele biznesowe) lub celem
zobrazowania dzialających lub przyszłych systemów informatycznych (modele systemu
informatycznego).
W rozważanym przypadku można skonstruowac nastepujące 3 modele:

1) model systemu biznesowego „obsługa pasażerów”

Model systemu biznesowego obejmuje problematykę funkcjonowania od strony
przedsiębiorstwa związaną z systemem informatycznym.Obrazuje on procesy biznesowe,
pasażerów, partnerów biznesowych, pracowników itp.

2) model systemu informatycznego

Model ten jest budowany w oparciu o model systemu biznesowego

3) model integracji

model integracji opisuje zwiazki systemu z otoczeniem w szczególności interfejsy ze
światem zewnętrznym.

Model systemu biznesowego stanowi zatem podbudowę dla dwóch pozostałych modeli. Stanowi on
także punkt wyjścia dla wszystkich działań w ramach projektu.
Należy także zwrócić uwagę na zalety zastosowania UML dzięki któremu jeden model będzie
zrozumiały zarówno dla pracowników róznych działów, jak i informatyków. W ten sposób UML
staje się łączem pomiędzy wymaganiami technicznymi, a sferą funkcjonalną systemu
informatycznego.

Modelowanie systemu biznesowego
Systemy informatyczne są w wielu przypadkach wykorzystywane do obsług systemów
biznesowych (gospodarczych), dlatego ich opracowanie oraz integracja powinny być wzajemnie
powiązane. Można wręcz powiedzieć, że system biznesowy i jego procesy są podstawą systemu
informatycznego.

Pojęcie procesu biznesowego
Intuicyjnie proces biznesowy oznacza procedurę bądź zdarzenie realizowane z myślą o osiągnieciu
celu. Można przytoczyc nastepujące procesy biznesowe oraz cele odnoszące się do rozważanego
przykładu z lotniskiem np.:

1) celem pasażera jest wyjazd na wakacje, zrealizowanie celu wymaga rezerwacji lotu i hotelu,

pakowania bagaży, dojazdu na lotnisko, odprawy, wsiadania so samolotu, udania się na

lptnisko docelowe, dojazd do hotelu docelowego, rozpakowanie bagazu

2) celem właściciela kiosku z prasą na lotnisku jest sprzedać towar, w związku z tym kupuje go

po możliwie najniższej cenie i sprzedaje z zyskiem,

3) odbycie lotu wymaga poddania się odprawie – w tym celu pracownicy odpraw odbierają

bilety i bagaże, pytają o preferencje dotyczace miejsca oraz używają systemu
informatycznego. Następnie pasażerowie otrzymuję karty pokładowe z zapisanymi
numerami miejsc oraz bramek.

Pojęcie czynności(activity)

Procesy biznesowe skłądają się z wielu etapów.Etapy te określa się także pojeciem czynnosci
(aktywnosci).Rozważymy proces biznesowy „odprawa pasazerów”. Można w nim wyróżnić pewną
ilośc czynnosci,które muszą być zrealizowane w okreslonej kolejności. Można to przedstawić na
następujęcy schemacie:

Schemat procesu biznesowego „odprawa pasażerów”

Ogólnie biorąc, czynnosci mogą być realizowane sekwencyjnie lub równolegle.Istnieje oficjalna
definicja terminów proces i proces biznesowy, zgodnie z którą:
proces jest skoordynowanym (sekwencyjnym lub równoległym) zbiorem czynności
wykonywanych z myślą o osiągnieciu wspólnego celu;czynności mogą być manualne i/lub
zautomatyzowane;
proces biznesowy jest formą procesu występującego w ramach struktury organizacyjnej i
podporzadkowanego osiągnięciu celów biznesowych.
Systemy biznesowe
Pojęciem system biznesowy okresla się łańcuch elementów generujący wartosć dodaną (zysk). W
skład tego łańcucha wchodzi proces generujący tą wartość np. dostawa towarów lub usług.
Analizowanie i modelowanie systemu biznesowego wymagaja okreslenia granic modelowania.
System biznesowy, który jest modelowany, może obejmować całą organizację jak też jej część. W
naszym studium przypadku przyszły system informatyczny ma być zintegrowany w sferze działań
dotyczacych obsługi pasażerów, dlatego zajmiemy się analizą i modelowaniem jedynie dla tej sfery
pracy lotniska. Zewnętrzne systemy biznesowe są w pewnym stopniu powiązane z systemem
biznesowym „obsługa pasażerów”, lecz nie wchodza w jego skład

Pasażer

wsiada na

pokład

samolotu

Pasażer udaje

się na

stanowisko

odpraw

Pasazer

poddaje się

odprawie

i odprawia

bagaż

Pasażer

udaje się

do bramki

System biz.

„catering”

System biz.

„linia lotnicza”

System biz.

„transport

bagazy”

System biz.

„odprawa celna”

System biznesowy

„obsługa pasażerów:

Zewnętrzne systemy będą nas interesować jako całość. Istotne będą jedynie interfejsy pomiędzy
nimi, a naszym systemem np. pracownicy obsługi pasażerów musżą wiedzieć o tym, że bagażę
powinny być dostarczone do punktu „transport bazgazy”,aby z tamtąd mogły być załadowane do
samolotu.

Dwie perespektywy modelu biznesowego

Analizując system biznesowy rozwazymy dwa rózne punkty widzenia tzn, model będzie składał się
z dwóch różnych perespektyw: zewnetrznej i wewnętrznej. Można to zilustrować na nasępującym
szkicu:

Patrząc na system od zewnątrz jest on postrzegany z perespektywy klienta, partnera biznesowego,
dostawcy, czy innego systemu biznesowego.
Patrząc od wewnatrz widzimy pracowników oraz narzędzie biorące udział w obsłudze procesów
biznesowych. Oprócz samych procesów mamy do czynienia z przepływem informacji oraz
systemami informatycznymi. W warunkach rzeczywistych perespektywa wewnętrzna jest ukryta
przed światem zewnętrznym,

Perespektywy i diagramy
Konstruując perespektywy wykorzystujemy nastepujące typy diagramów:

1) Diagramy przypadków użycia – zawierają aktorów, biznesowe przypadki użycia oraz

związki między nimi. Nie opisują wprawdzie procedur ale stanowią przejrzysty przegląs
funkcji systemu biznesowego.

2) Diagramy czynnosci – opisują procedury biznesowe.Umieszcza się na nich interakcje

pomiedzy aktorami, a systemem, przy czym w oparciu o te diagramy zewnętrzni
użytkownicy mogą poznać sposoby interakcji z systemem.

3) Diagramy sekwencji – opisują przebieg interackji w sposób chronologiczny, natomiast nie

zajmuja się poszczególnymi zdarzeniami, w tym rozgalęzieniami i zrównolegleniami
operacji. Skupiają się na informacji przekazywane pomiedzy stronami interakcji. Mogą być
użyte do opisu wymiany informacji pomiędzy systemem,a partnerami i klientami

Lotnisko(organizacja)

Kasy, okienka odpraw

System biznesowy „obsługa pasażerów”

Perespektywa wewnętrzna

System

biznesowy

„transport bagazy”

Inny system biznesowy

Pasażer

Partner

Perespektywa zewnętrzna

Perespektywa
zewnetrzna

Załóżmy, ze sporządzono następujący podstawowy diagram przypadków użycia dla naszego
systemu biznesowego:

Czytanie tego diagramu odbywa się w zalezności od potrzeb. Można przyjać,że początek aktora lub
przypadek uzycia. Jeśli za poczatek przyjmiemy aktora (pasażera) natrafimy np. na dwa zwiazki: z
przypadkiem odprawa oraz odprawa ekspresowa(gdy pasażer nie ma bagażu i w specjalnym
punkcie odpraw).Aktor (przedstawiciel) ma związek z przypadkiem użycia odprawa,wyraźnie
zatem widać,że przedstwiciel pasażera nie może dokonywac odprawy ekspresowej.

Problem konstruowania diagramów przypadków użycia
Aby sporządzić diagram przypadkó użycia niezbędne jest wykonanie szeregu kroków, do których
należą:

1) Gromadzenie żródeł informacji

Polega ono na zidentyfikowaniu źródeł wiedzy. Analityk wraz z dostawcami wiedzy w
kolejnych krokach będą opracowywac model. Dostawcami wiedzy mogą być osoby
zaangażowane w realizacje procesów biznesowych, użytkownicy obsługujący takie same
bądź podobne systemy, klienci, partnerzy biznesowi, bądź eksperci w analizowanej
dziedzinie,itp.

2) Identyfikowanie potencjalnych aktorów

Należy tutaj ustalić, którzy partnerzy bądź klienci wykorzystują towary (usługi) świadczone
przez modelowany system biznesowy. W naszym studium przypadku w pierwszym etapie
analizy wyodrębniono dwóch potencjalnych aktorów tj. Pasażer i przedstawiciel pasażera.
Aktor „pasażer” reprezentuje wszystkich podróżnych, „przedstawiciel pasażera” nie jest
pasażerem w tym sensie,że nie odbywa on podróży, a jedynie w imieniu pasażera realizuje
część formalnosci zwiazanych z odprawą.

3) Identyfikowanie potencjalnych przypadków użycia

Należy ustalić, które tpwry i usługi są dostępne dla potencjalnych aktorów. Wyodrębniono
nastepujące przypadki użycia:
a) procedura odprawy – oznacza wydanie biletu, odprawe bagaży oraz wydanie karty
pokadowej,
b) odprawa ekspresowa – jest przeznaczona dla pasażerów posiadających tylko bagaż
podręczny; nie odbywa się wtedy odprawa bagażu,
c) wydanie karty pokładowej -odnosi się do sprawdzenia karty pokładowej przed wejsciem
na pokład,
d)odprawa automatyczna – odbywa się bez udziałi pracownika odpraw, przy użyciu
komputera;nie ma tu możliwości odprawienia bagażu.
Do identyfikacji przypadków użycia najbardziej efektowną metodą okazuje się być technika
obserwacji.Sporządza się listę czynności które następnie mogą być grupowane w zdarzenia
tworzące zarys przypadków użycia.
Jako kolejne etapy wymiwnic można:

System

przedstawiciel pasażera

Pasażer

Obsługa pasażerów

Odprawa

odprawa automatyczna

odprawa ekspresowa

wydanie karty pokladowej

<<include>>

<<include>>

<<include>>

4) Łączenie przypadków użycia – przyporządkowanie przypadków użycia odpowiednim

aktorom.

5) Opis aktorów – kogo lub co reprezentują.
6) Poszukiwanie kolejnych przypadków użycia.
7) Edycja i wypełnienie treścią przypadków użycia – dokumentowanie.
8) Identyfikacja powiazań pomiedzy przypadkami użycia.
9) Weryfikacja

WYKŁAD 10, 12-12-2007
Rozszerzenie liczby przypadków uzycia
należy zauwazyc, ze pasażer często podróżuje z bagażem, który należy odprawić. Za załadunek
bagażu jest odpowiedzialny dział transportu. Jest to niezależna komórka, która występuje tutaj także
jako aktor, a dokładnie zewnętrzny dostawca usług. Załóżmy, że 10 min. przed odlotem komórka
transportowa oczekuje od działu obsługi pasażerów dostarczenia listy nazwisk odprawionych
pasażerów, którzy nie wsiedli do samolotu.Dodatkowo lista pasażerów jest także potrzebna służbom
celnym.Omówiona tu sytuacja wymaga rozważenia dwóch nowych aktorów reprezentujących
komórkę transportową oraz służby celne lotniska docelowego. W ten sposób otrzymujemu
rozszerzony diagram „biznesowych” przypadków użycia.

Edycja oraz dokumentowanie przypadków użycia
Ponieważ trudno jest oszacować właściwy zakres szczegółowości modelu systemu biznesowego
należy zastosować określone kryteria wyboru szczegółowości. Problem ten wynika np.stąd, ze nie
można zbyt wielu czynności aktora łączyć w jeden diagram przypadków uzycia, gdyż traci on
wtedy na znaczeniu. Z drugiej strony czynności nie należy przedstawiać zbyt szczegółowo, gdyż
diagram zbyt się skomplikuje.Do kryteriów, którymi należy się w tym przypadku kierowąć należą
m.in.

1) ustalenie czy przypadek składa się z sekwencji rzeczywiscie związanych ze sobą interakcji

(współdziałań) – np. elementy wchodzące w skład przypadku użycia musza być ze soba
powiazane podczas gdy wydanie karty pokądowej i poszukiwanie bagażu nie są zwiaznae w
ogóle.Przypadki użycia nie spełniające zasady wzajemnego powiazania należy rozbić na
składowe.

2) Biznesowe przpadki użycia zawierające zbyt wielu aktorów powinny być podzielone
3) czy przypadek użycia jest inicjowany przez aktora - jeśli nie jest to nie powinien być

traktowany jako przypadek użycia lecz wewnętrzna czynność, która może być
przedstawiona w ramach perespektywy wewnętrznej systemu biznesowego.

Aby zrozumieć przypadke użycia nie wystarczy informacja na diagramie, należy bardziej
szczegółowo opisac łańcuch interakcji oraz warunki wykonania,które cechują kazdy przypadke
użycia. Oznacza to, ze musi być opisany łańcuch zdarzeń poprzedzający dostarczenie przez system
kazdego towaru lub usługi.Należy pamiętac, Że opis ten ma być dokonany z zewnątrz, czyli z
punktu widzenia klienta lub partnera biznesowego.

System

przedstawiciel pasażera

celnik na lotnisku docelowym

Pasażer

transport bagaży

Obsługa pasażerów

Odprawa

odprawa automatyczna

odprawa ekspresowa

wsiadanie na poklad

żadanie listy pasazerow

Oprócz czysto tekstowego opisu bardzo użyteczna okazuje się dokumentacja w postaci diagramów
czynności oraz diagramów sekwencji. Użyci tych diagramó omówimy w dalszej części.
Identyfikacja powiązań między przypadkami użycia
Pomiedzy przypadkami użycia są możliwe zwiazki zawierania informujące, że jeden przypadek
uzycia jest zawarty w innym. Uwzględniają związki zawierania otrzymujemy kolejną wersję
naszego diagramu.

Oznaczenie zawierania to strzałka z napisem <<include>>, której zwrot wskazuje na
przypadekzawarty w innym przypadku.

Użycie diagramów czynnosci
W perespektywie zewnętrznej systemu biz. diagramów czynności używa się do opisu procesów
biznesowych. W przeciwieństwie do diagramów przyp. Użycia te diagramy jednoznacznie
informują o tym, czy poszczególni aktorzy biorący udział w procesie wykonują okreslone działania
samodzielnie czy wespół z innymi.Diagramy czynności pozwalają zatem spojrzeć na system pod
kątem wypełnianych funkcji. Można na nich reprezentować zdarzenia zachodzące równolegle.
Diagramy takie tworzy się na różnych poziomach szczegółowości.
Notacja diagramów czynnosci:
Podstawowym pojęciem diagramu jest czynność (activity). Pojedynczy diagram reprezentuje pewna
odbywaną czynność. Czynność można odnieść do modelowanego procesu biznesowego np. pasazer
poddaje się odprawie. Istnieje także pojęcie akcji ( pojedynczy krok) oznaczające pewne działanie,
które nie musi lub nie może być rozłożone na mniejsze elementy.Zaklada się, ze dzielenie akcji na
mniejsze jednostki na potrzeby konkretnego diagramu nie miałoby sensu. Akcje na diagramach
oznacza się następująco:

W ramach pewnej akcji możliwe jest wywołanie czynności co oznacza się następująco

AKCJA

AKCJA

System

przedstawiciel pasażera

celnik na lotnisku docelowym

Pasażer

transport bagaży

Obsługa pasażerów

Odprawa

odprawa automatyczna

odprawa ekspresowa

wydanie karty pokładowej

wsiadanie na poklad

żadanie listy pasazerow

<<include>>

<<include>>

<<include>>

Wywołanie samo w sobie jest akcją zaś efektem jest podjęcie innej czynności co oznacza,że
czynności mogą być w sobie zagnieżdżone. Istnieje akcja typu akceptacja zdarzenia, która jest
związana z oczekiwaniem na zdarzenie. Po zaakceptowanu zdarzenia inicjowany jest przepływ z
niej wynikający. Wiele procesów biz. jest inicjowanych przez zdarzenie.

WYKLAD 11, 19-12-2007

Akceptacja zdarzenia czasowego

Przepływ

Węzeł decyzyjny reprezentuje takie miejsce na diagramie, w którym musi być rozstrzygnięty
pewien warunek. Składa się z wejscia i 2 lub więcej wyjść. Warunki umieszcza się w nawiasie
kwadratowym.Wyjście typu Else jest wykonane gdy nie jest spełniony żaden z warunków

Węzeł łączący reprezentuje takie miejsce w kórym łączy się kilka przepływów. Wejscia nie są
zsynchronizowane w tym sensie że gdy jeden z przepływów dotrze do wejścia przechodzi do
wyjścia niezależnie od tego czy do innych wejść dotarły sygnały.

Złączenie słuzy do konsolidacji dwóch lub więcej przepływów równoległych.W odróżnieniu od
węzła łączącego tutaj przepływy są zsynchronizowane tzn.proces przechodzi do wyjścia dopiero
wówczas gdy dotra do wejść inne procesy.

Rozgałęzienie służy do rozdzielenia przepływu na dwa lub więcej przepływów równoległych

Akceptacja zdarzenia

Wysylanie sygnalu do innej czynnosci

węzeł poczatkowy- czynnosc może mieć więcej niż jeden węzeł poczatkowy ,w takim przypadku
uruchomione jest więcej przepływów.Czynność nie musi mieć węzła poczatkowego może być także
inicjowana przez akcje akceptacja zdarzenia.

Węzeł końcowy czynnosci – sygnalizuej zakończenie

Końcowy węzeł w przeciwieństwie do węzła końcowego czynności który kończy całą czynność,
dotarcie do końca przepływu nie oddziałuje na inne przepływy równoległe

partycja czynności – poszczególne elementy diagramu czynności mogą być podzielone na odrębne
obszary zwane partycjami. Bierze się tu pod uwagę rózne kryteria tj. jednostki organizacyjne,centra
kosztowe,lokalizacje itp. Każda partycja ,a swoją nazwę

Konstruowanie diagramów czynności
W przypadku konstruowania diagramó czynności reprezentujących modele nie tylko w języku
UML występuje dość powszechny problem czytalnosci tych diagramów. Klasycznym przykładem
okazuje się zastosowanie odpowiedniego nazewnictwa. Warto poświęcić więcej czasu
odpowiedniemu dobraniu słów, gdyż zazwyczaj okazuje się to dobrą inwestycją.Warto także
rozpocząć od wyższego poziomu abstrakcji diagramów (niższego poziomu szczegółowości), które
obejmowałyby killka przypadkó użycia. Na takie diagramy można następnie wprowadząć kolejne
szczegóły. Scharakteryzujemy problem budowy diagramów czynności w podobny sposób jak to
było dla diagramów przypadków użycia – poprzez rozwazenie kilku etapów:
A) gromadzenie informacji – ogólnie biorąc można wykorzystać wiedzę wcześniej zgromadzoną
przy okazji tworzenia diagramów przypadków użycia
B)wyodrębnienie czynności oraz akcji – na tym etapie należy określić co należy zrobić, gdy
aktorzy zainicjują dostarczenie towarów lub usług. Także w tym przypadku za ounkt wyjścia
przyjmujemy diagramy przypadkó użycia,a pewnym sposobem określenia czynności oraz akcji
mogłyby być odpowiedzi na następujące pytania:

a) jakie etapy da się wyodrębnić w przypadkach użycia, czyli jakie kroki należy wykonać,
aby dostarczyć wybrane towary i usługi,
b) co robią poszczególni aktorzym jak powiązać aktorów z wyodrębnionymi etapami, jakie
zdarzenia inicjuja poszczególne etapy, czy zdarzają się akcje na tyle skomplikowane, ze
należałoby im poświęcić osobny diagram czynnosci.

W naszym studium przypadku w ramach obsługi pasażerów wyodrebnimy następujące etapy
działań:

1) odprawa pasażera – jest ot etap pozyskany z diagramu przypadków użycia; jest on związany

z wydaniem karty pokładowej.

Partycja

Partycja

2) Pasażer wsiada na pokład (także pozyskany z diagramu przypadków użycia)

Ponadto można wyróznić inne etapy i zdarzenia:

–

pasażer przybywa do punktu odpraw i okazuje bilet – to zdarzenie inicjuje czynność odprawy

–

bagaże są ładowane na pokład samolotu przez komórkę transportową – w pierwszej fazie
czynności mogą być opisane w sposób nieformalny. W firmie często bywa dostępna gotowa
dokumentacja procesów, która można wykorzystać przy identyfikowaniu czynności i akcji

C) łączenie akcji - dochodzimy do momentu w którym należy rozstrzygnąć w jakiej kolejności

następują akcje. Łącząc wspomniane wcześniej akcje i czynności uzyskujemy pierwsze
przybliżenie diagramu czynności

Na diagramie występują przykłady akcji złożonych, które wymagaja uruchomienia odrębnych
czynnosc, są to akcje oznaczone symbolem trójzębu.

D) uszczegółowienie czynności

Jak widać na sporządzonym diagrami niektóre z wyodrębnionych wstępnie etapów
wymagają uszczegółowienia.Przykąłdowo rozważmy czynność „pasazer poddaje się
odprawie”. Gdy pasażer poddaje się odprawie w pierwszej kolejnosci pokazuje bilet.Bilet
jest sprawdzany pod kątem waznosci i jeśli jest ważny pasażer odprawia bagaż. Jeśli bagaż
ma zbyt duża wagę pasażer musi wnieść dodatkową opłatę. Następnie bagaż jest
przekazywany.Po uzupełnieniu szczegółów otrzymujemy dodatkowe akcje przedstawione na
rysunku

Okazanie biletu

Wydanie karty

pokładowej

Wniesienie opłaty

Odprawa bagazy

Przyjęcie bagazy

Skierowanie do

obsługi klienta

Weryfikacja biletu

Pasażer zglasza sie przy punkcie odpraw

Pasazer poddaje sie odprawie

Pasazer wsiada na poklad

Zaladunek bagazy do samolotu

Samolot koluje na pas startowy

[Else]

[Odprawa zakończona
powodzeniem]

E) uwzględnienie aktorów z przypadków użycia

Modelując proces biznesowy należy zwrócić szczególną uwagę na to kto jest
odpowiedzialny za poszczególne akcje i kto je wykonuje.
Wyrażając ten fakt w każdym diagramiw odpowiadającym odprawie pasażerów

uzyskujemy:

Na diagramie czynnościperespektywy zewnętrzne wykorzystano tych samych aktorów co na
diagramiw przypadków użycia. Każdy aktor jest odpowiedzialny za okreslone działanie. Jest on
umieszczany w określonej partycji jako jednostka odpowiedzialna. Podział diagramu czynności na
partycje pozwala zatem dokonać przeglądu zakresu odpowiedzialności.
Ostatnim etapem w budowie diagramu czynności mogłaby być weryfikacja pod kątem
poprawności we współpracy z dostawcami informacji.

Pasazer poddaje się odprawie

Okazanie biletu

w punkcie odpraw

Wydanie karty

pokładowej

Przyjęcie bagazu

Wniesienie opłaty

Skierowanie pasazera

do obslugi klienta

Odprawa bagazy

Weryfikacja biletu

Pasażer

Obsługa

[bilet prawidłowy]

[ELSE]

Bagaż kwalifikuje
się do dopłaty

[Else]

Diagramy sekwencji
UML oferuje dwa typy diagramów reprezentujących interakcję.Należą do nich diagramy sekwencji
i diagramy komunikacji. Ich zadaniem jest pokazanie tego aspektu systemu, który dotyczy wymiany
informacji (komunikowania się). Bardziej szczegółowo w diagramach komunikacji kłądzie się
nacisk na powiązania pomiędzy obiektami i ich topologią, natomiast w diagramach sekwencji
chronolgię (wzajemne nastepstwo czasowe wymiany informacji). W modelowaniu perespektywy
zewnętrznej zostaną wykorzystane diagramy sekwencji.Mogą być one modelowane w oparciu o
kilka wybranych osobnych przypadków użycia. Na diagramach sekwencji występują następuące
elementy:

WYKŁAD , 9-01-2007
Komentarz -służy do wprowadzenia dodatkowych informacji. Element ten może zawierać
informacje o czynnościach towarzyszących lub warunkach wystąpienia sekwencji.
Obiekt - obiekty są nadawcami i odbiorcami komunikatów. W perespektywie zewnętrznej systemu
biz.obiekty reprezentują aktorów tego systemu oraz sam system.
Komunikaty na diagramach sekwencji są wprowadzone w kolejności od góry do dołu
diagramu.Kierunek strzałkiinformuje o skierowaniu komunikatu. Obiekt biznesowy jest opisany w
nawiasach i stanowi rodzaj całości wraz z komunikatem.

Rysunek ten przedstawia diagram sekwencji z obiektami pasażer i obługa pasażerów.Diagramten
dokumentuje proces biznesowego przypadku użycia „odprawa pasażera”.Diagram ten zasadniczo
czytamy od góry.Punkt początkowy 1 jest umieszczony na linii pionowe reprezentującej obiekt
„pasażer” jako nadawce i odbiorce komunikatów.Przepływ rozpoczya się w momencie wręczenia
biletu pracownikowi obsługi w celu weryfikacji.Wywoąłnie akcji weryfikacja następuje przy
pomocy komunikatu. Bilet (3) jest obiektem biznesowym.Grot strzałki informuje o tym, że
nadawcą wiadomości jesr pasażer,a odbiorcą obsługa pasażera (6). Otrzymanie komunikatu przez
obługę pasażerów (6) inicjuje czynność sygnalizowaną przez pionowa linie (7). Diagram nie
zawiera informacji o tym jak przebiega proces obsługi pasażerów (bo nie zawiera odrębnych
czynności). Jedyna wskazówkana ten temat znajduje się w komentarzu oznaczonym jako (5).
Dokładny opis przetwarzania zawierać powinien odpowiedni diagram czynności. W dalszej części
sekwencji obsługa pasażerów wydaje kartę pokąłdową (9). Sytuacja ta jest sygnalizowana
zakończeniem pionowej linii(10).
Interakcje zilustrowane diagramem kończą się po obu stronach, stąd kończą się pogrubione linie
pionowe.
UML oferuje więcej możliwosci na diagramach tego typu.W przypadku jednak modelu biz. można
ograniczyć się przedstawionym podzbiorem.

Konstruowanie diagramów sekwencji
Kilka podstawowych etapów:

1) Identyfikacja aktorów i systemu biznesowego

Chodzi tutaj o to, aby istalić kto bierze udział w sekwencji.Zadaniem tych diagramów jest
przedstawić interakcję (współdziałanie) pomiędzy aktorami,a systemem biz.. Strony
interakcji odpowiadają aktorom z diagramów przypadków użycia bądź pewnym systemom
biznesowym. W naszym studium przypadku zidentyfikowano następuące strony interakcji:
pasażer, obsługa pasażera. Zostaną one wykorzystane na diagramie sekwencji jako obiekty.

2) Identyfikacja inicjatora

Należy ustalić aktora, który rozpoczyna interakcję w sekwencji. Inicjatora wybiera się
spośród wszystkich wykorzystywanych w diagramach przypadków użycia aktorów. W

PASAZER

Obsługa

pasażerów

Weryfikazja (bilet)

Wydanie
(karta pokładowa)

(1)

(5)IF bilet nie jest w porządku
skieruj do punktu obslugi
klienta

(9)

(8

(7

(6)

(2)

(4)

(3)

(10)

naszym przypadku interakcja jest inicjowana przez pasażera.

3) Opis wymiany komunikatów

Chodzi tutaj o identyfikację kolejnych etapów sekwencji, a w szczególności przekazywaną
informację,Odbywa się to za pomocą tzw. komunikatów. Wspólnie z komunikatami
przekazywane są tzw.obiekty biznesowe, które należy także zidentyfikować.

4) Ustalenie chronologii komunikatów

Załóżmy, że zidentyfikowano następującą chronologię komunikatów

5) Wprowadzenie dodatkowych informacji

mogą to być komentarze np. taki jk (5) lub inne np. jeśli nadmiar bagażu to dopłata. Należy
jednak uważać, aby nadmiar komentarzy nie przeciążył diagramów.

6) Weryfikacja

Polega na sprawdzeniu czy wszystko zostało wykonane prawidłowo np.:
-czy kazdy aktor wymieniony na diagramie przypadków użycia został opisany na
przynajniej jednym diagrami sekwencji,
- czy nie można zmniejszyć liczby komentarzy, zwiekszając tym samym czytelność
diagramów.

Bardziej ogólne diagramy sekwencji
Do zobrazowania procesów biznesowych na wyższym poziomie abstrakcji można użyć diagramó z
większą liczbą biznesowych przypadków użycia. Diagramy takie pozwalaja lepiej zrozumieć
interakcje w systemi.Przedstawimy teraz diagram ilustrujący obsługę pasażerów na któym ujęto
dwa biznesowe przypadki uzycia: odprawa i wsiadanie na pokład

PASAZER

Obsługa

pasażerów

Weryfikazja (bilet)

Załadunek bagazu

Zgłoszenie
preferencji
dot. miejsca

Wydanie
(karta pokładowa)

można zatem stwierdzić,że diagramy sekwencji mogą posłużyć do tworzenia scenariuszy
zastosowania przypadków użycia. Pomagają one w uszczegółowieniu i definiowniu biznesowyc
przypadków użycia kładąc nacisk na wymianę komunikatów. Przedstawimy jeszcze jeden diagram
sekwencji dla przypadku użycia pod nazwą „odprawa”. Przedstawia on scenariusz działań
związanych z odprawą pasażera z punktu widzenia komunikacji pomiędz partnerami biorącymi
udział w sekwencji. Diagramy sekwencji podobnie kal diagramy czynności pokazują, czy
poszczególne etapy przypadków użycia są realizowane przez aktorów wspólnie, czy tez
niezależnie. Może w tym ostatnim przypadku na diagramie sekwencji nie pojawiłyby się interakcje.

PASAZER

Transport

bagaży

Obsługa

pasażerów

odprawa

Weryfikacja (blilet)

Bilet w porzadku

Załadunek bagazu
Wniesienie opłaty

Zgłoszenie
preferencji
dot. miejsca

Wydanie
(karta pokładowa)

Załadunek
(bagaz)

IF bilet nie
jest w
porządku
skieruj do
obsługi
pasażerów

IF nadmiar
bagazu

PASAZER

Transport

bagaży

Obsługa

pasażerów

odprawa

Weryfikazja (bilet)

Bilet w porzadku
Załadunek bagazu

Zgłoszenie
preferencji
dot. miejsca

Wydanie
(karta pokładowa)

Załadunek
(bagaz)

Obsługa

pasażerów

wsiadanie na

pokład

Weryfikacja (karta pokaldowa)

Karta pokładowa poprawna

Wykład. , 16-01-2007

Wykład prowadzony przez mgr. J. Sadolewskiego.
Krótki przegląd języków i technik programowania oraz praktyczny krótki przegląd tworzenia
aplikacji w Delphi itp.