O czym mówimy - definicje kluczowe



System informatyczny.



Oprogramowanie (aplikacja/program
komputerowy).

Zbiór powiązanych ze sobą elementów, którego funkcją jest
przetwarzanie danych przy użyciu techniki komputerowej:

 sprzęt komputerowy

 oprogramowanie

 zasoby ludzkie

 elementy organizacyjne (procedury) i informacyjne (bazy
wiedzy)

Całość informacji w postaci zestawu instrukcji,
zaimplementowanych interfejsów i zintegrowanych danych
przeznaczonych dla komputera do realizacji wyznaczonych
celów.

O czym mówimy – definicje kluczowe



Inżynieria oprogramowania.



Cykl życia oprogramowania.

Dziedzina inżynierii systemów zajmująca się wszelkimi
aspektami wytwarzania oprogramowania: od analizy
potrzeb/wymagań, przez projektowanie i wdrożenie, do
ewolucji gotowego oprogramowania.

Szereg wzajemnie zależnych od siebie etapów, w których
podejmowane są działania, począwszy od ujawnienia potrzeby
wytworzenia oprogramowania, prezentacji jego idei,
wytworzeniu, użytkowaniu, przystosowaniu do ewentualnych
zmian funkcjonowania aż do jego wycofania.

O czym mówimy – definicje kluczowe



Proces wytwarzania oprogramowania.



Modele procesu wytwarzania

oprogramowania.

Proces obejmujący typowo fazy: specyfikacja, projektowanie,

implementacja, integracja, ewolucja (utrzymanie)

PODEJŚCIA KLASYCZNE

 model kaskadowy

 model prototypowy

 model przyrostowy

 model równoległy

model V

model spiralny

PODEJŚCIA ‘ZWINNE’

 programowanie zwinne

programowanie ekstremalne

STANDARDY

 PMBOK

 RUP

Klasy systemów
informatycznych



Systemy wsparcia przedsiębiorstw



Systemy informowania kierownictwa



Systemy wspomagania decyzji



Systemy ekspertowe (sztuczna inteligencja)

Proces wytwarzania oprogramowania

oraz

pozyskiwanie wymagań

Wykład 2

Materiały do wykładu opracowane na podstawie:
software.com.pl/przeglad-modeli-cyklu-zycia-oprogramowania
zasoby.open.agh.edu.pl/~10sdczerner/page/okreslanie_wymagan
wymagania.net/baza-wiedzy

Proces wytwarzania oprogramowania

Grupy działań

(działania programowe rozwoju oprogramowania)

Działania
podstawowe

Działania wsparcia

Planowanie

II.

Ocena/Analiza

III.

Projektowanie

IV.

Programowanie

Walidacja i weryfikacja

Zarządzanie
wymaganiami

II.

Zarządzanie
projektami

III.

Zarządzanie jakością

IV.

Zarządzanie
konfiguracją

Wprowadzenie do
oprogramowania

VI.

Dokumentacja

Planowanie

•Aktywizacja wymagań

•Specyfikacja (wymogi, definicje)

•Oszacowanie wysiłku

•Model procesu

Ocena

•Prototyp wyjściowy

•Analiza procesu

•Object Oriented Analisys (OOA)

Projekt

•Architektura oprogramowania

•Structured Design (SD)

•Object Oriented Desing (OOD)

•Unify Modelling Language

Programowanie

•Standaryzowane metody

programowania

•Programowania strukturalne

•Programowanie obiektowe

•Functionall Programming

Walidacja i

weryfikacja

•Testy jednostkowe

•Testy integracyjne

•Testowanie systemu

•Testowanie odbiorcze

Zarządzanie

wymaganiam

• Zarządzanie wymaganiami

Zarządzanie

projektem

(PM)

• Zarządzanie grupą

• Zarządzanie ryzykiem

• Monitoring i kontrola

• Zarządzanie umową z dostawcami

Zarządzanie

jakością

(QM)

• Capability, Maturity Model

• Spice standard (Software Process Improvement)

• Zarządzanie incydentami

• Zarządzanie problemem

• Pomiar cech oprogramowania

• Analiza statystyczna

• Ergonomiia oprogramowania

Zarządzanie

Konfiguracj

ą (CM)

• Wersjonowanie

• Zarządzanie zmianami

• Zarządzanie wersjami

• Application Management

Wprowadzenie

oprogramowani

• Wprowadzenie do oprogramowania

Dokumentacj

• Dokumentacja techniczna

• Dokumentacja oprogramowania

• Narzędzia dokumentacji oprogramowania

• Dokumentacja systemu

• Dokumentacja operacyjna

• Instrukcja dla użytkowników

• Procesy biznesowe (projekt rozwoju)

• Dokumentacja procesu

Określanie wymagań

Wymagania dotyczą systemu. Są opisem systemu pod względem
wykonywanych przez niego funkcji oraz sposobu realizacji tych funkcji.

Określanie wymagań może odbywać się na różnych etapach realizacji

projektu:



w fazie przeprowadzania studium wykonalności projektu (feasibility study)



po podjęciu decyzji o realizacji projektu, ale przed podpisaniem kontraktu
o jego realizacji (lub ogłoszeniem przetargu),



po podpisaniu kontraktu.

Proces określania wymagań dla systemu informatycznego można podzielić
na następujące fazy:



faza ustalania wymagań (odkrywania wymagań).



faza specyfikacji wymagań (tworzenia opisu wymagań).



faza atestacji (walidacji) wymagań.

Określenie wymagań

Obie strony, klient i wykonawca, muszą porozumieć się co do
wielu elementów, przy czym:



klient często nie rozumie specyfiki funkcjonowania programów,



wykonawca nie zna specyfiki dziedziny zastosowań.

Klient musi ustalić swoje wymagania w kontekście możliwości i
ograniczeń charakterystycznych dla systemów informatycznych.
Wykonawca musi dostosować funkcjonowanie programów do
standardów
i konwencji dziedziny zastosowań.

Klasyfikacja wymagań

Z punktu widzenia rodzaju wymagań można je podzielić na:



wymagania funkcjonalne – dotyczące tego co ma realizować
system, jakie ma spełniać funkcje, jakich dostarczać usług, jak
zachowywać się w określonych sytuacjach;



wymagania niefunkcjonalne – dotyczące tego jak system powinien
realizować swoje zadania; np. wymagania dotyczące koniecznych
zasobów, ograniczeń czasowych, niezawodności, bezpieczeństwa,
przenośności, współpracy z określonymi narzędziami i środowiskami,
zgodności z normami i standardami,
a także przepisami prawnymi, w tym dotyczącymi tajności i
prywatności, itp.

Wymagania funkcjonalne powinny być:



kompletne – opisywać wszystkie usługi żądane od systemu,



spójne – nie zawierać stwierdzeń sprzecznych.

Specjalne grupy wymagań

Ważnym przykładem specyficznej grupy wymagań są
wymagania dotyczące zabezpieczania systemu. Obejmują one
wymagania:



identyfikacji użytkowników,



autentykacji użytkowników,



autoryzacji,



wykrywania ataków,



odporności na ataki (wirusów, robaków, itp.),



integralności danych (odporność na niszczenie danych),



uniemożliwiania zaprzeczaniu uczestnictwa w transakcjach,



prywatności,



sprawdzalności zabezpieczeń,



odporności podsystemu zabezpieczeń na zmiany dokonywane
w innych częściach systemu.

Techniki pozyskiwania wymagań

Pomocnymi technikami w odkrywaniu wymagań są:



poznanie całości otoczenia systemu (poprzez obserwacje,
zaznajomienie z odpowiednimi dokumentami, itp),



wykorzystanie istniejących systemów realizujących podobne
funkcje,



obserwacje i wywiady z przyszłymi użytkownikami systemu,



stosowanie scenariuszy wykorzystania systemu
(przypadków użycia),



modelowanie systemu,



tworzenie prototypów systemu.

Techniki pozyskiwania

wymagań

Przydatną techniką przy odkrywaniu wymagań jest rozważanie tzw.
punktów widzenia (viewpoints).
Punkt widzenia określa dowolną osobę, której w jakiś sposób dotyczy
funkcjonowanie systemu, ewentualnie element szeroko rozumianego
otoczenia wpływający na wymagania systemu.

Punkty widzenia można podzielić następująco:



bezpośrednie – związane z ludźmi bezpośrednio korzystającymi z
systemu bądź obsługującymi system



pośrednie – związane z ludźmi pośrednio zainteresowanymi
funkcjonowaniem systemu (kierownictwo, osoby odpowiedzialne
za bezpieczeństwo)



związane z dziedziną – standardy, przepisy organizacyjne, itp.

Punkty widzenia są źródłem rozmaitych oczekiwań, wizji i
konkretnych wymagań w stosunku do systemu.

Techniki według BABOK

BABOK

- Bussines Analysis Body of Knowledge

Techniki:



Burza mózgów. Technika polegająca na wspólnym tworzeniu
i analizowaniu pomysłów podczas grupowego spotkania.



Analiza dokumentacji. Polega na przeglądaniu istniejącej w organizacji
dokumentacji w celu identyfikacji wymagań obecnych i potencjalnych.



Analiza interfejsów. Analiza zewnętrznych interfejsów polega na identyfikacji i
badaniu zarówno interfejsu użytkownika, jak i interfejsów do/z zewnętrznych
systemów lub urządzeń.



Wywiad. Technika polegająca na zadawaniu pytań dotyczących określonego
obszaru działania danej osoby, procesu czy problemu. Wywiad przeprowadzany jest
przez analityka, zaś osobą pytaną jest ekspert dziedzinowy, przedstawiciel biznesu
czy wręcz użytkownik końcowy projektowanego rozwiązania.



Obserwacja. Technika ta polega na wyciąganiu wniosków na podstawie obserwacji
pracy ludzi wykonujących swoje zadania.



Prototypowanie. Prototypy aplikacji (tworzone np. jako statyczne lub dynamiczne
strony HTML) pozwalają na wizualizację wstępnego projektu analityka
i weryfikację rozwiązania przez przedstawicieli klienta.



Warsztaty. Warsztaty wymagań stanowią ustrukturyzowaną metodę pozyskiwania
wymagań. Warsztaty służą do określania zakresu, identyfikacji, szczegółowego
definiowania i ustalania priorytetów wymagań projektowanego systemu.

Porządkowanie wymagań

Wygodnym sposobem porządkowania informacji uzyskanych z różnych
punktów widzenia jest tworzenie scenariuszy – opisów możliwych sekwencji
zdarzeń związanych z funkcjonowaniem systemu.

Scenariusze można następnie grupować w zbiory odpowiadające
realizacji konkretnych funkcji lub grup funkcji systemu zwanych przypadkami
użycia.

Uporządkowanie i hierarchizacja możliwych punktów widzenia oraz scenariuszy
i przypadków użycia może być podstawą określania konkretnych wymagań.

Zarządzanie wymaganiami Zarządzanie wymaganiami oznacza proces
kontroli zmian wymagań i ich konsekwencji dla systemu w ciągu całego cyklu
życia systemu.

Zarządzanie wymaganiami jest konieczne, gdyż w praktyce wymagania
zawsze się zmieniają z powodu zmian technologicznych, organizacyjnych i
czysto ludzkich.

Modelowanie wymagań

UML – Unified Modelling Language jest rozbudowanym językiem
modelowania systemów oraz tworzenia specyfikacji.

Powstał w wyniku rozwoju notacji graficznych związanych z
trzema metodologiami tworzenia oprogramowania obiektowego:



OOAD (Object Oriented Analysies and Design) Boocha,



OOSE (Object Oriented Software Engeenering) Jacobsona,



OMT (Object Modelling Technique) Rumbaugh.

Obecnie rozwijany jest jako standard organizacji OMG
(Object Management Group).

Modelowanie wymagań

Diagramy przypadków użycia:



definiują granice modelowanego systemu,



określają jego kontekst,



wymieniają użytkowników systemu i jednostki zewnętrzne,



przedstawiają funkcje dostępne dla użytkowników,



określają powiązania i zależności pomiędzy nimi.

W późniejszych fazach tworzenia oprogramowania przypadki użycia (i tworzące je
pojedyncze scenariusze) są przekształcane w bardziej szczegółowe opisy
funkcjonowania systemu, takie jak np.:



diagramy interakcji między obiektami systemu,



diagramy czynności realizowanych przez system,



diagramy stanów,



specyfikacje za pomocą warunków początkowych i końcowych,



mniej lub bardziej sformalizowane opisy w języku naturalnym,



pseudokod.

W ostatecznym kodzie tym co realizuje przypadek użycia jest najczęściej
kooperacja – zbiór klas, interfejsów itp. wspólnie dostarczających funkcjonalność
nieosiągalną w pojedynkę.

Narzędzia CASE

CASE: Computer Aided Software Engineering,

Computer Aided System Engineering.

Narzędzia CASE wspomagające proces określania wymagań związane są
najczęściej z konkretną ustaloną notacją lub metodyką postępowania.

Funkcje narzędzi CASE to analiza, projektowanie i programowanie.

Narzędzia CASE automatyzują metody projektowania, dokumentacji oraz
tworzenia struktury kodu programu w wybranym języku programowania,
najczęściej w programowaniu obiektowym.

Typowymi narzędziami CASE są:



narzędzia do modelowania w języku UML i podobnych,



narzędzia do zarządzania konfiguracją zawierające system kontroli wersji,



narzędzia do refaktoryzacji

Narzędzia CASE

Systemy CASE można podzielić według faz cyklu życia systemu na:



Upper-CASE - wspomaga pierwsze fazy budowy systemu – analizę

organizacyjną i funkcjonalną i procesową, modelowanie funkcji, procesów,
obiektów, modelowanie struktur i potrafi tworzyć wszelkie diagramy. Te
narzędzia zajmują się bardziej opisem i modelowaniem rzeczywistości,
modelowaniem struktury systemu, bez wszelkich faz implementacji.



Lower-CASE, wspomaga rzeczywiste budowanie oprogramowania –

modelowanie bazy danych, generowanie kodu i testy.

Czasami wyróżnia się także systemy Middle-CASE, które pozwalają
określić samą strukturę systemu informatycznego, oraz Integrated-
CASE, czyli systemy łączące Upper- i Lower-CASE.

Według zakresu zastosowań narzędzia CASE można również podzielić na
pakiety narzędziowe oraz pakiety zintegrowane.

Narzędzia CASE

O zaawansowaniu danego systemu i spełnieniu wymagań użytkownika świadczy zakres
oferowanych funkcjonalności.



Słowniki danych (repozytoria) – bazy wszelkich danych o tworzonym systemie wraz z
narzędziami edytującymi, zarządzającymi i wyszukującymi te dane.



Edytor Notacji Graficznych – program graficzny, umożliwiający tworzenie i edycję diagramów dla
faz określania wymagań systemu, analizy i projektowania. Powinien też umożliwiać powiązania
między symbolami w modelu a innymi, zdekomponowanymi modelami, oraz wydruk tych
diagramów.



Moduł Kontroli Poprawności – narzędzie do wykrywania i poprawiania błędów w diagramach i
repozytoriach. Bardzo często działa w czasie rzeczywistym, co znacząco wpływa na komfort pracy.



Moduł Kontroli Jakości – narzędzie do oceny pewnych ustalonych miar jakości projektu –
np. stopnia złożoności lub powiązań składowych modelu.



Generator Raportów – narzędzie tworzące dowolny raport na podstawie danych z repozytorium.



Generator Kodu – narzędzie transformujące projekt na szkielet kodu w wybranym języku
programowania. Usprawnia pracę programistów, pozwala na zautomatyzowanie pewnych
fragmentów kodu, a także na uzupełnienie kodu o dodatkowe informacje ze słownika danych.



Generator Dokumentacji Technicznej – generator ustandaryzowanych dokumentów,
zawierających specyfikację, opisy faz projektu, diagramy oraz wybrane raporty.



Moduł Projektowania Interfejsu Użytkownika – narzędzie do projektowania menu, okien
dialogowych oraz innych elementów interfejsu użytkownika.



Moduł Inżynierii Odwrotnej – narzędzie pozwalające odtworzyć słownika danych oraz diagramów,
na podstawie kodu źródłowego lub struktury bazy danych.



Moduł Importu/Eksportu Danych – narzędzie służące do wymiany danych z innymi CASE'ami czy
też innymi programami.



Moduł Zarządzania Pracą Grupową – narzędzie umożliwiające współpracę grupy osób podczas
pracy nad projektem.

Modele procesu

Wykład 3

Materiały do wykładu opracowane na podstawie:
software.com.pl/przeglad-modeli-cyklu-zycia-oprogramowania
zasoby.open.agh.edu.pl/~10sdczerner/page/okreslanie_wymagan
wymagania.net/baza-wiedzy

Modele cyklu wytwarzania oprogramowania

Model kaskadowy (waterfall)

W modelu kaskadowym kolejne etapy procesu
rozwoju oprogramowania następują po sobie w
ściśle określonym porządku.

Każda następna faza rozpoczyna się dopiero
często po formalnym przyjęciu/zamknięciu fazy
poprzedzającej.

Model kaskadowy

Zalety:



uporządkowanie procesu wytwarzania

Wady:



Uzyskanie efektu zadawalającego klienta jest niezmiernie zależne od
stabilności wymagań ustalonych na początku procesu



Weryfikacja zgodności z wymaganiami i jego użyteczności następuje
dopiero w końcowej fazie procesu



Próba dopasowania produktu do zmieniających się wymagań jest bardzo
droga



Brak elastyczności w zakresie przenikania się faz procesu wytwarzania



Wysoki koszt późnego wykrywania błędów popełnianych we wczesnych
fazach procesu



Zmarginalizowanie roli klienta w procesie wytwarzania oprogramowania

Odmiana modelu kaskadowego:
Realizacja kierowana dokumentami

Model V

Modelowanie

Projektowanie

Implementacj

Testowanie jednostek

oprogramowania i

integracyjne

Testowanie

walidacyjne i

systemu

Model iteracyjny

Analiza wymagań

biznesowych

Analiza wymagań

biznesowych

Zgrubna analiza

wymagań

projektowych

Zgrubna analiza

wymagań

projektowych

Wybór podzbioru

zadań do realizacji

Wybór podzbioru

zadań do realizacji

Szczegółowa

analiza, projekt,

implementacja

i testowanie

Szczegółowa

analiza, projekt,

implementacja

i testowanie

Nowa wersja

systemu

Nowa wersja

systemu

Proces

iteracji

I Etap: Prototyp fitness

Model iteracyjny

Zalety:



Pozwala na szybką implementację przynajmniej części wymaganej
funkcjonalności



Pozwala na bardzo szybką weryfikację realizowalności
wytwarzanego systemu i informację zwrotną od klienta



Pozwala na szybsze uzyskiwanie wpływów finansowych

Wady:



Wymaga bardzo dobrej umiejętności (praktyki) pogrupowania
procesu na właściwe iteracje

Synonimy tego procesu: proces ewolucyjny, przyrostowy, spiralny

Czas

Budżet

Zasob

Analiza
wstępna
realizowalnoś
ci

Model spiralny



Jest pewną próbą formalizacji modelu iteracyjnego.



Główną cechą tego modelu jest analiza ryzyka występująca w każdej fazie tego
procesu.



Główną zaletą jest próba minimalizacji ryzyka niepowodzenia przedsięwzięcia
oraz ciągła weryfikacja produktu przez klienta (użytkownika).

Model spiralny można postrzegać jako cykliczne powtarzanie czterech czynności:



Planowanie – na podstawie wymagań i celów wyznaczonych przez klienta,
dokonuje się określenia alternatyw i ograniczeń oraz planowania iteracji przy
każdorazowym rozpoczęciu kolejnego cyklu spirali



Analiza ryzyka – sprowadza się do oceny rozwiązań alternatywnych oraz próby
identyfikacji i analizy ryzyka związanego z każdą z możliwych konstrukcji
kolejnego wydania



Konstrukcja – ma postać „małego wodospadu”, a jej celem jest wytworzenie
kolejnego wydania systemu.



Ocena przez klienta – walidacja wydania i jego ocena z możliwością modyfikacji
wymagań na system

Model prototypowania

Zbieranie

wymagań

Zbieranie

wymagań

Zgrubna

analiza

wymagań

Zgrubna

analiza

wymagań

Szybki projekt

Budowa

prototypu

Budowa

prototypu

Ocena

prototypu

przez klienta

Ocena

prototypu

przez klienta

Prototyp

spełnia

oczekiwania

klienta

Prototyp

spełnia

oczekiwania

klienta

Modyfikacja

wymagań

Modyfikacja

wymagań

Wymagania

Projektowanie

Implementacja

Testowanie

Wdrożenie

NIE

TAK

Analiza wymagań

Wytworzenie produktu

Model prototypowania



Prototypowanie polega na budowaniu kolejnych „przybliżeń” systemu aż do
momentu, gdy prototyp stanie się dobrym odzwierciedleniem wymagań.



Cechą charakterystyczną modelu jest budowa „szybkiego projektu” bez dbałości
o jego jakość i dostosowanie do środowiska docelowego.



Przy tworzeniu kolejnego prototypu odrzuca się wcześniej przygotowany
kod.



Do budowy prototypu także trzeba wykorzystać jakiś model rozwoju
oprogramowania.

Wady:



częste niezrozumienie przez klienta potrzeb kolejnego prototypowania



możliwość przyzwyczajenia się klienta do funkcjonalności, które oferuje prototyp,
a które nie wynikają z wymagań

Model wytwarzania odkrywczego



Wytwarzanie odkrywcze (exploratory development) jest wariantem modelu
ewolucyjnego, w którym iteracje dotyczą całego cyklu wytwarzania
oprogramowania



Istotą wytwarzania odkrywczego jest stała współpraca z klientem, który
otrzymuje kolejne, coraz bogatsze wersje systemu i na ich podstawie określa i
uszczegóławia swoje wymagania



Wytwarzanie odkrywcze dobrze radzi sobie z występującym powszechnie
faktem zmiany wymagań przez klientów



Wytwarzanie odkrywcze polega na stałej modyfikacji kodu, bez odrzucania
dotychczas wytworzonego oprogramowania (przeciwnie do prototypowania)



Wytwarzanie odkrywcze musi poradzić sobie z dwoma istotnymi problemami:



jak często dokonywać rewizji aktualnego stanu kodu (problem ważny dla
efektywnego zarządzania wytwarzaniem programów)



jak nie dopuścić do utraty jednolitej struktury przez ciągle modyfikowany kod



W przypadku stosowania wytwarzania odkrywczego konieczne jest
wypracowanie strategii zarządzania wersjami, np. takiej, w której istnieją
wersje będące drobnymi poprawkami w stosunku do poprzednich oraz istotne
zmiany, przy których odrzuca się znaczne części poprzedniej wersji kodu
(która może być wtedy traktowana jako prototyp).

Diagramy przypadków użycia

UML

Wykład 4

Diagramy przypadków użycia

Diagramy przypadków użycia zawierają następujące główne
kategorie pojęciowe:



przypadki użycia,



aktorzy,



związki.

Kategorie te w każdym diagramie są ze sobą ściśle powiązane.

Przypadek użycia

Przypadek użycia (use case us) to specyfikacja ciągu akcji i ich
wariantów, które system (lub inna jednostka) może wykonać
poprzez interakcję z aktorami tego systemu.
Jest to więc kompleksowe działanie realizowane w systemie w
konsekwencji określonej aktywności aktora (actor).

Nazwę przypadku użycia stanowi zwięzłe polecenie
wykonania funkcji w projektowanym systemie, sformułowane w
trybie rozkazującym.

Rezerwuj

wycieczk

Sprzedaj

towar

Rezerwuj wycieczkę

Sprzedaj towar

Rezerwuj wycieczkę

Sprzedaj towar

Aktorzy

Aktor jest to spójny zbiór ról odgrywanych przez użytkowników
przypadku użycia w czasie interakcji z tym przypadkiem użycia.

Aktorzy mogą być osobowi (np. osoba, zespół, dział, instytucja,
organizacja, zrzeszenie, itp.) lub nieosobowi (systemy
zewnętrzne, podsystemy, bazy danych, urządzenia oraz czas).

Nazwę aktora wyraża się rzeczownikiem lub określeniem
rzeczownikowym w liczbie pojedynczej. Identyfikując aktorów
należy pamiętać, że reprezentują oni nie indywidualne obiekty ze
świata rzeczywistego, ale pełnione przez nie funkcje.

Aktorzy - stereotypy

Rodzaje aktorów w reprezentacji obiektów:



ludzi oraz zespołów,



systemów zewnętrznych,



urządzeń,



czasu.

Urządzenie

System zewnętrzny

Czas

Konsultant
Sprzedawca
Dział sprzedaży
…

Nagrywarka DVD
Laptop Toschiba
…

System obsługi
kart płatniczych
…

Termin płatności
…

Związek

Związek stanowi semantyczne powiązanie pomiędzy elementami

modelu.

Każdy aktor umieszczony na diagramie przypadków użycia
powinien być bezpośrednio powiązany z co najmniej jednym
przypadkiem użycia.

W diagramie języka UML można wyróżnić cztery rodzaje
związków:



asocjację,



uogólnienie,



zależność,



realizację.

Związek

Asocjacja jest związkiem pomiędzy dwoma lub więcej
klasyfikatorami, opisującym powiązania między ich instancjami.

W diagramie przypadków użycia asocjacja wskazuje zatem
domyślnie na dwukierunkową komunikację pomiędzy
aktorem a przypadkiem użycia.

Może ona dodatkowo występować w formie z kierunkiem
nawigacji (jawne przedstawienie inicjatora interakcji).

Przykładowy DPU aukcji internetowej

Przykładowy DPU obsługi hurtowni

Zaawansowane składniki diagramu

Do zaawansowanych koncepcji diagramów przypadków użycia
należy zaliczyć:



rozbudowę DPU poprzez różnicowanie związków,



zależności zawierania,



zależności rozszerzania,



uogólnienie,



rodzaje aktorów,



liczebność,



nawigację,



realizację,



przypadki użycia typu CRUD,



diagram kontekstowy,



dokumentację przypadków użycia.

Rozbudowa DPU poprzez różnicowanie związków

Zależność to taki związek pomiędzy dwoma elementami modelowania,
w którym zmiana jednego z nich, niezależnego, wpływa na drugi, zależny.

I tak w obrębie pojedynczego diagramu przypadków użycia zależności w DPU
występują w postaci stereotypowanej, przede wszystkim jako zależności:



zawierania,



rozszerzania.

Zależności zawierania (wymagana)

Zależność zawierania «include» przedstawia powiązanie pomiędzy przypadkiem
zawierającym, tj. bazowym przypadkiem użycia, a przypadkiem zawieranym.

Sens tworzenia zależności zawierania na diagramie UML występuje w dwóch
przypadkach, gdy:



istnieje możliwość wydzielenia w formie zawieranego przypadku użycia pewnej

spójnej, wspólnej dla kilku innych przypadków użycia funkcjonalności (czytelność
diagramu); w tym przypadku często występująca funkcjonalność jest
reprezentowana jednokrotnie na diagramie i wykorzystywana przez inne przypadki
użycia;



interakcje aktor-system wyrażone w dokumentacji scenariusza tego przypadku są

bardzo liczne.

«include»

Przypadek użycia

‘zawierany’

dokonywany

każdorazowo dla

przypadku

‘Dokonaj

rezerwacji’

Przypadek

użycia

‘zawierający’

Zależności rozszerzania (opcjonalne)

Zależność rozszerzenia «extend» przedstawia powiązanie pomiędzy
rozszerzanym przypadkiem użycia, tj. przypadkiem bazowym, a
przypadkiem rozszerzającym.

Związek ten, w odróżnieniu od zależności zawierania, ma charakter
opcjonalny.

Funkcjonalność reprezentowana przez rozszerzający przypadek użycia
może, ale nie musi zostać włączona do rozszerzanego przypadku
użycia. Włączenie przypadku rozszerzającego wymaga spełnienia
określonego warunku.

Przypadek

rozszerzan

Przypadek

rozszerzając

y -

opcjonalny

Zależność rozszerzania -
warunki

Miejsca/punk

rozszerzenia

Dodatkowa funkcjonalność zawarta w przypadkach rozszerzających
nie jest
wykonywana automatycznie, a dopiero po spełnieniu określonych
warunków określanych dla przypadku bazowego jako
miejsca/punkty rozszerzenia.

Uogólnienia

Uogólnienie to związek o charakterze taksonomicznym
pomiędzy klasyfikatorem ogólnym a specjalizowanym.

Związki uogólnienia (generalization) dotyczą w kontekście
charakteryzowanego diagramu zarówno przypadków użycia, jak i
aktorów.

Element specjalizowany z założenia dziedziczy wszelkie cechy
elementu ogólnego.

Liczebność i Nawigacja

Diagramy przypadków użycia pozwalają na określenie
liczebności (multiplicity) końcówek związku asocjacji pomiędzy
aktorami i przypadkami użycia.

Nawigacja pozwala wskazać inicjatora interakcji. Używana jest
wyłącznie wtedy, gdy wskazanie inicjatora jest istotne i wymaga
udokumentowania.

Realizacja

Realizacja to związek znaczeniowy między klasyfikatorami, z których
jeden określa kontrakt, a drugi zapewnia wywiązanie się z niego.

Związki realizacji w odniesieniu do przypadków użycia pozwalają
modelować relacje występujące pomiędzy ogólnym, funkcjonalnym
opisem systemu w postaci diagramów przypadków użycia a jego
wdrożeniem.
W ten sposób diagram przypadków użycia pozostaje powiązany z
innymi diagramami, które zawierają informacje niezbędne do jego
poprawnego rozwinięcia i implementacji.

Diagram kontekstowy

Diagram kontekstowy stanowi zestawienie aktorów będących
w interakcji z danym systemem traktowanym w kategorii
pojedynczego procesu.

Dokumentacja przypadków użycia

NAZWA:

Pełna nazwa przypadku użycia

Numer:

Numer identyfikacyjny przypadku użycia

Twórca:

Dane twórcy (imię, nazwisko, stanowisko)

Poziom ważności:

Określony z perspektywy użytkownika (niski, średni, wysoki)

Typ przypadku:

Określony z punktu widzenia złożoności oraz ważności dla
zaspokojenia potrzeb użytkownika

Aktorzy

Lista aktorów będących w związku z przypadkiem użycia

Krótki opis

Krotka ogólna charakterystyka przypadku użycia

Warunki wstępne:

Lista warunków inicjujących przypadek

Warunki końcowe:

Stan systemu po realizacji przypadku użycia

Główny przepływ zdarzeń

Wypunktowana lista przepływów zdarzeń zachodzących podczas
realizacji – scenariusz główny

Alternatywny przepływ
zdarzeń

jw. dotyczy alternatywnych scenariuszy

Specjalne wymagania

Wypunktowana lista dodatkowych zidentyfikowanych wymagań
niefunkcjonalnych, które mogą być istotne przykładowo podczas
projektowania lub implementacji

Notatki

Lista wszelkich komentarzy dotyczących przypadku użycia i lista
pozostałych otwartych kwestii, które powinny zostać rozwiązane.

NAZWA:

Anuluj rezerwację

Numer:

Twórca:

Pani Iksińska, projektant

Poziom ważności:

Średni

Typ przypadku:

Ogólny

Aktorzy

Recepcjonista, Kierownik recepcji

Krótki opis

Anulowanie istniejącej rezerwacji pokoju lub apartamentu

Warunki wstępne:

Co najmniej jedne pokój lub apartament musi być zarezerwowany

Warunki końcowe:

System odnotowuje pokój lub (i) apartament jako dostępny

Główny przepływ
zdarzeń

1. Recepcjonista weryfikuje rezerwację, uruchamiając funkcję

„Rezerwacje”

2. System wyświetla okno z informacjami o rezerwacjach (pokoje i

apartamenty hotelowe)

3. Pracownik recepcji zaznacza rezerwacje do anulowania i uruchamia

funkcję „Anuluj rezerwacje”

4. System wyświetla komunikat „Czy anulować zaznaczone

rezerwacje?”

5. Pracownik recepcji potwierdza operację anulowania zaznaczonych

rezerwacji

6. System potwierdza wykonanie operacji komunikatem „Anulowano

wybrane rezerwacje” i odświeża ekran monitora

Alternatywny przepływ
zdarzeń

2a. System wyświetla komunikat „Brak rezerwacji”
3a. Pracownik recepcji potwierdza operację anulowania zaznaczonych
rezerwacji
3b. Jeśli podczas rezerwacji podany został adres e-mail, pracownik może
wysłać do klienta pocztą elektroniczną informację o anulowaniu
rezerwacji

Specjalne wymagania

1. Wysoka niezawodność systemu
2. Czas przetwarzania operacji anulowania rezerwacji nie może

przekroczyć 5 sekund

Notatki

Brak

UML 2.0 - Diagramy sekwencji

Diagram sekwencji – jeden z podstawowych diagramów interakcji.
Umożliwia modelowanie interakcji pomiędzy obiektami wraz z
komunikatami, jakie między nimi przepływają.

OŚ pozioma
[instancje
klasyfikatorów]

ły

tó

]

Obiekt 1

Obiekt n

. . .
.

Komunikat 1

Komunikat 2

.
.

• Pozwalają uzyskać

odpowiedź na pytanie,
jak w czasie przebiega
komunikacja między
obiektami?

• Stanowią podstawową

technikę modelowania
zachowania systemu,
które składa się na
realizację przypadku
użycia.

Diagramy sekwencji – notacja i
semantyka

klasyfikator

linia życia

ośrodek sterowania

komunikat

dezaktywacja

aktywacja

Instancje klasyfikatorów



Klasy

Klasa jest pojęciem ogólnym. Np. system zarządzania obejmuje szereg pojęć

ogólnych jak: projekty, menadżerów, zespoły, produkty pracy, wymogi,
systemy.

Klasa definiuje zatem typ obiektu i jego właściwości, w tym cechy strukturalne

i behawioralne.

Na diagramie UML klasa jest przedstawiana w postaci prostokąta,

narysowanego linią ciągłą, i zawierającego trzy standardowe przedziały,
odseparowane od siebie liniami poziomymi. W górnym przedziale wpisuje się
nazwę klasy; w środkowym (opcjonalny) listę atrybutów;
w dolnym (opcjonalny) listę operacji.

Na potrzeby diagramów sekwencji stosujemy notację tylko z nazwą klasy.

Pracownik

Projekt

Produkt

pracy

Instancje klasyfikatorów



Rola klasy

W diagramie sekwencji rolę klasy przedstawiamy w tej samej

notacji co klasę lecz nazwę klasy poprzedza prawy ukośnik, po
nim następuje nazwa roli, z którą obiekt musi być zgodny, aby
uczestniczyć w roli,
a następnie dwukropek.

Rysunek przedstawia rolę Organizacja Projektu klasy Organizacja

/Organizacja Projektu:

Organizacja

Instancje klasyfikatorów



Obiekty

Obiekt jest konkretnym pojęciem, inaczej instancją klasy; ma

właściwości zdefiniowane przez klasę, w tym cechy
strukturalne i behawioralne. Cechy strukturalne definiując co
obiekt „wie”, a behawioralne co ten obiekt „może zrobić”. Do
cech strukturalnych należą wartości atrybutów i powiązania.
Do cech behawioralnych należą operacje i metody, wspólne dla
wszystkich obiektów w klasie.

Najważniejszą cechą obiektu jest to, że posiada własną

tożsamość. Dwa obiekty nigdy nie są takie same, nawet jeśli
mają identyczne wartości cech strukturalnych.

Instancje klasyfikatorów



Obiekty

W diagramie UML obiekt jest przedstawiany w postaci prostokąta,

narysowanego linią ciągłą i podzielnego poziomą linią na dwa
standardowe przedziały. Przedział górny zawiera

nazwę

obiektu

, po której następuje dwukropek i

nazwa klasy

obiektu

, a cały ciąg jest podkreślony linią ciągłą. Dwukropek

powinien być obecny tylko wtedy, gdy podajemy nazwę klasy.

Natalia

Student

Natalia:Student

ID=2
Imię= ”Natalia”
-AdresEmail[1]=”nat@wp.pl”
-
AdresEmail[2]=”nat@gmail.co
m

”

Natalia:

:Student

Obiekt anonimowy

Obiekt niesprecyzowany

Instancje klasyfikatorów



Obiekty

W diagramie sekwencji konkretny obiekt z danej klasy, zgodny z

rolą klasy, przedstawia się wpisując nazwę obiektu, a następnie
prawy ukośnik, nazwę roli, dwukropek i nazwę klasy, a całość
jest podkreślona.

Na rysunku Grupa Natalii jest grupą zarządzającą należącą do roli

Grupa Zarządzanie, które wychodzą z klasy Grupa Studencka.

Grupa Natalii/ Grupa

Zarządzanie:

Grupa Studencka

Linia życia i aktywacja



Linia życia i aktywacja

Linia życia przedstawiona w postaci pionowej linii przerywanej

biegnącej od elementu, reprezentuje istnienie tego elementu w
czasie.



Aktywacja

Aktywacja przedstawiana jako wąski wzdłużny prostokąt na linii

życia, reprezentuje okres, w którym element wykonuje operację.
Górny bok prostokąta znajduje się na poziomie chwili inicjacji, a
dolny na poziomie chwili ukończenia.

Komunikacja, komunikat, bodziec

W diagramie sekwencji komunikację przedstawia się w postaci

poziomej strzałki narysowanej linią ciągłą do linii życia lub
aktywacji nadawcy do linii życia lub aktywacji odbiorcy.

Najbardziej podstawowym opisem komunikacji jest nazwa

operacji.

Komunikacja – opis szczegółowy

W języku UML komunikację opisuje się za pomocą następującej składni:

[dozór] *[iteracja] numer_sekwencyjny : zmienna_zwracana := nazwa_operacji

(lista_argumentów)

dozór jest opcjonalny i oznacza warunek, który musi zostać spełniony, aby komunikacja

nastąpiła. Nawiasy prostokątne usuwamy, jeśli dozór nie jest wyspecyfikowany.

iteracja jest opcjonalna i oznacza, ile razy komunikacja zostaje wysłana (występuje).

Gwiazdkę i nawiasy prostokątne usuwamy, jeżeli nie podajemy iteracji.

numer_sekwencyjny jest opcjonalną liczbą całkowitą, która określa kolejność komunikacji.

Następujący po nim dwukropek usuwamy jeżeli nie podajemy numeru.

zmienna_zwracana jest opcjonalna i oznacza nazwę wartości zwracanej przez operację. Jeżeli

nie chcemy przedstawiać zwracanej zmiennej lub operacja nie zwraca zmiennej należy
usunąć dwukropek i znak równości

nazwa_operacji wymagana nazwa operacji, którą należy wywołać
lista_argumentów jest opcjonalna i zawiera oddzielone od siebie przecinkiem argumenty

przekazywane do operacji. Każdy parametr może być konkretną wartością lub zmienną
zwróconą z wcześniejszej komunikacji. Jeżeli operacja nie wymaga żadnych argumentów,
pozostawiamy puste nawiasy.

Komunikacja

Komunikacja wywołuje operację FormatujDanePracownika, która formatuje dane o

pracowniku.

Ta operacja wymaga jednostek pracy i produktów pracownika więc dodane

zostało: (JednostkiPracy, ProduktPracy)

Operacja zwraca też pewne dane w postaci łańcucha sformatowanego tekstu,

więc dodane zostało: DaneWyjściowe :=

Operacja występuje jakoś szósta komunikacja w ogólnej sekwencji, więc 6 :
Projekt może obejmować więcej niż jednego pracownika (operacja ma wystąpić

jednokrotnie dla każdego pracownika) więc zapisano *[Dla każdego
pracownika]

Operacja ma wystąpić tylko wtedy, gdy projekt jest aktywy więc [Projekt jest

aktywny]

Obsługa

Generowania

Raportu Statusu

Projektu

/organizacja

Projektu:Organizac

[Projekt jest aktywny] *[Dla każdego pracownika]
6 : DaneWyjściowe := FormatujDanePracownika
(JednostkiPracy, ProduktPracy)

Komunikat

Rodzaje komunikatów

komunikat opcjonalny

komunikat utracony

komunikat znaleziony

komunikat oczekujący

Rodzaje komunikatów



Komunikat synchroniczny oznacza przekazanie sterowanie od klasyfikatora-
nadawcy do klasyfikatora-odbiorcy. W momencie przesłania tego komunikatu
aktualny przepływ sterowania nadawcy ulega przerwaniu – jest on wznawiany
dopiero po wykonaniu przez odbiorcę operacji wskazanej w komunikacie.



Komunikat asynchroniczny nie powodują przerwania aktualnego przepływu
sterowania nadawcy. Instancja klasyfikatora nadawcy nie oczekuje na
odpowiedź, zatem pozostaje w stanie aktywności, co umożliwia jej dalsze
przetwarzanie lub wysyłanie komunikatów.



Komunikaty zwrotne (opcjonalnie zaznaczane) wskazują na powrót sterowania
do instancji klasyfikatora nadawcy po wykonaniu komunikatu synchronicznego.
Funkcją komunikatu zwrotnego nie jest tylko przekazanie sterowania do danej
instancji, ale też zainicjowanie jej określonej operacji. (zmieńCenę – zwrot:
wyświetl(„Cena uaktualniona”)



Komunikat utracony, występuje wtedy, gdy nadawca jest znany, a odbiorca
jest nieznany



Komunikat znaleziony, występuje wtedy, gdy znany jest odbiorca, a nie jest
znany nadawca



Komunikat opcjonalny, oznacza, że nadawca wysłał do odbiorcy komunikat,
oczekując gotowości do jego niezwłocznej obsługi przez odbiorcę. Jeżeli
komunikat nie może zostać przyjęty w danej chwili przez odbiorcę nie zostaje
wykonany.



Komunikat oczekujący, różni się od opcjonalnego tym, że może poczekać na
obsłużenie przez określony odcinek czasu.

Samowywołanie

Warunek

Rozgałęzienie



Klasyfikator – nadawca kilka klasyfikatorów – odbiorców

[warunek]

Rozgałęzienie



Klasyfikator – nadawca jeden klasyfikator-odbiorca z
rozszczepioną linią życia

[warunek]

Fragmenty wyodrębnione i operatory interakcji

Alternatywa alt

Opcja opt

Iteracja loop

Łączenie klasyfikatorów

RUP (Rational Unified Process)

Wykład 5

Agile (Metodyki zwinne)

Wykład 6

Rozumienie Agile

Ludzie i ich wzajemne interakcje:
w filozofii wytwarzania Agile samoorganizujące się zespoły
oraz ludzka motywacja są bardzo istotne, tak samo jak w
przypadku programowania parami czy kolokacji.

Działające oprogramowanie:
działające oprogramowanie (nawet próbka) jest bardziej
przydatna w prezentacji wyników pracy klientowi, niż tylko
sucha dokumentacja i szkice poglądowe

Współpraca z klientem:
wiedząc, że wymagania nie mogą być w pełni pozyskane
podczas pierwszego spotkania z klientem (tj. na początku
cyklu wytwarzania oprogramowania) dlatego ciągła
współpraca z klientem lub udziałowcami projektu jest
niezbędna dla prawidłowego wykonania projektu

Reagowanie na zmiany: wytwarzanie w filozofii Agile jest
skoncentrowane na szybkim reagowaniu na zmiany
i ciągłym wytwarzaniu.

Podstawowe zasady



osiągnięcie satysfakcji klienta poprzez szybkość wytwarzania
oprogramowania,



działające oprogramowanie jest dostarczane okresowo
(raczej tygodniowo niż miesięcznie),



podstawową miarą postępu jest działające oprogramowanie,



późne zmiany w specyfikacji nie mają destrukcyjnego wpływu
na proces wytwarzania oprogramowania,



bliska, dzienna współpraca pomiędzy biznesem a developerem,



bezpośredni kontakt, jako najlepsza forma komunikacji w
zespole i poza nim,



ciągła uwaga nastawiona na aspekty techniczne oraz dobry
projekt (design),



prostota,



samozarządzalność zespołów,



regularna adaptacja do zmieniających się wymagań.

Najważniejszy element:

zespół projektowy



Mały zespół bez hierarchizacji jak w

przypadku firm korporacyjnych.



Niezbędna częsta (codzienna) komunikacja

między członkami zespołu.



Niezbędne wspólne wypracowywanie

decyzji.



Niezbędne jednakowe zaangażowanie

członków zespołu w realizacji kolejnych
iteracji projektu oraz ustalanie planu
działań.

Praca



Perspektywa czasowa: tydzień (max 4 tygodnie)



Codzienne spotkania: max 15 min



Grupa robocza: od 5 do 9 osób



Grupa uczestników: ‘pośrednik/kontakt’ klienta +
udziałowcy



Odpowiedzialność: każdy przyjmuje grupę zadań do
wykonania i z niej się rozlicza



Wymagania: konieczność ustalenia listy priorytetów
dla całej grupy w porozumieniu z klientem



Wynik: prezentacja wykonanego/działającego
fragmentu oprogramowania

Proces iteracyjny/przyrostowy w Agile

Metody filozofii Agile



Programowanie extremalne



Scrum



Dynamic Systems Developement Method



Adaptive Software Developement



Crystal Clear



Feature Driven Developement



Pragmatic Programming



Light Agile Developement

Programowanie ekstremalne
(eXtrem Programming, XP)



Podejście stosowane do projektów o

wysokim ryzyku, gdzie nie do końca
wiadomo co i jak wytwarzać



Opiera się o dobre praktyki pozyskane

z projektów, które zakończyły się sukcesem



Dobiera się i tworzy hybrydy różnych

metod prowadzenia projektów, dogodnych
w danym momencie wytwarzania



Prowadzone w małych zespołach max 8

osobowych

Programowanie ekstremalne:
główne zasady



Wytwarzać iteracyjnie



Nie projektować z góry: architektura systemu nie jest znana i należy ją
rozbudowywać w miarę przyrostu koncepcji efektu końcowego.



Prowadzić testy jednostkowe: testy jednostkowe pisze się zanim
jeszcze zacznie pisać się kod – najlepiej na początku iteracji. Potem pisze
się kod, który potrafi je wszystkie przejść.



Modyfikować architekturę: architektura systemu nie jest sztywnym
tworem i jeżeli jej modyfikacja nie pogorszy wyników testów
przeprowadzonych w poprzedniej iteracji to należy w razie konieczności ją
zmienić.



Programowanie parami: programiści pracują na przemiennie przy
pisaniu kodu, przy czym jeden zawsze fizycznie wklepuje kod, a drugi w
tym czasie go czyta, weryfikuje, wyłapuje błędy, zadaje pytania kontrolne.



Stały kontakt z klientem



Wady: brak dokładnej specyfikacji, konieczna stała dostępność klienta,
wspólna własność kodu – każdy może zmieniać dowolny fragment
systemu.

Scrum developement



Rozwój produktu podzielony jest na mniejsze, trwające od dwóch to
czterech (max sześciu) tygodni fazy zwane sprintami. Fazy te
następują bezpośrednio po sobie.



Po każdy sprincie zespół powinien być w stanie dostarczyć działający
prototyp projektu.



Obowiązuje zasada, że zmiany wprowadzone w każdym sprincie muszą
być namacalne dla klienta, muszą wnosić wartość funkcjonalną.



Zaleca się stosowanie przebiegu o stałych długościach czasu trwania.



Zespół roboczy jest ciałem samoorganizującym się, nie istnieje odgórne
przypisywanie zadań, członkowie sami dobierają sobie zadania i
realizują je w danym sprincie.

Scrum developement: zasady

Proces iteracji obejmuje:



Zebranie wymagań w postaci ‘historyjek’, z których każda
opisuje jedną cechę sytemu; klient jest zobowiązany dostarczyć
listę priorytetów realizacji funkcji systemu oraz głównego celu
danego sprintu Budowany jest rejestr wymagań, a cel sprintu
zapisywany jest w widocznym miejscu w pokoju roboczym.



Wybór priorytetów w danym sprincie, szacowanie czasu
realizacji każdego zadania. Lista zadań razem z czasem
przebiegu nosi nazwę rejestru zadań przebiegu sprint
backlog.



W trakcie realizacji sprintu nie można modyfikować jego
zawartości ani przebiegu.



Codziennie odbywają się tzw. scrum meeting (max 15 min)



Sprint kończy się tzw. sprint review, na którym prezentowany
jest wynik pracy zespołu w postaci zrealizowanego fragmentu
systemu. Powinni w nim uczestniczyć wszyscy zainteresowani
projektem.