Podstawy Inżynierii Oprogramowania
Wykład 3
Specyfikacja wymagań  inaczej
- historie użytkownika
- diagramy aktywności
User story (US)- opis wymagań projektowanej aplikacji.
- krótko opisana pojedyncza funkcjonalność aplikacji lub
- zestaw funkcjonalności, wzajemnie zależnych.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
1
Podstawy Inżynierii Oprogramowania
Historia użytkownika - rozmiar, struktura
Wzorzec opisu historii:
 Jako , chcÄ™ aby 
równoważna - powszechnie stosowana - wersja krótsza:
 Jako , chcÄ™ 
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
2
Podstawy Inżynierii Oprogramowania
Historie użytkownika- przykłady
1. Jako kierownik chcę wyszukiwać klienta podając ich imię i
nazwisko.
2. Jako użytkownik chcę modyfikować swój harmonogram lecz nie
można nic modyfikować innym użytkownikom.
3. Kient sklepu internetowego może dodać do swojego koszyka
produkt, którego szczegóły ogląda na stronie.
4. Pracownik BOK może zmienić na życzenie klienta zamówienie o
podanym numerze. Wymaga to wcześniejszej autentykacji
klienta sklepu
5. Użytkownik może wysłać powiadomienie email o nowo
zdefiniowanym spotkaniu.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
3
Podstawy Inżynierii Oprogramowania
Historia użytkownika w MS TFS
Zaleta User Stories
1. pokazują projektowaną aplikację z punktu widzenia przyszłego użytkownika. Co pozwoli na
dostarczenie funkcjonalnego produktu.
2. zwięzła forma, dzięki której zebranie wymagań nie jest czasochłonne, ale pozwala na wyrobienie
opinii co do wyglądu przyszłego systemu.
3. pozwalają na bezpośrednie wpisywanie ich do (Backlog- Scrum).
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
4
Podstawy Inżynierii Oprogramowania
Przypadki użycia vs. historie użytkownika
Historia użytkownika
Przypadek użycia
" zapewnia niewielka rozmiarowo i " Opisuje proces i jego kroki w
łatwą w użyciu prezentacje szczegółach i może być opisana w
informacji. postaci formalnego modelu
" zwykle formułowana w codziennym " PU w swoim zamierzeniu jest samo-
języku użytkownika ; wystarczający do pełnego
zrozumienia wymagania.
" obejmuje mało detali, co pozwala na
ich doprecyzowanie, ale powinny " Uogólniony zbiór interakcji między
pozwolić czytelnikowi na aktorem i systemem.
[1]
zrozumienie, co ma wykonywać
oprogramowanie.
" Samodzielny dokument.
" skojarzona z testami akceptacyjnymi,
które doprecyzowują rozumienie
wymagania.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
5
Podstawy Inżynierii Oprogramowania
Specyfikacja zachowania
" diagramy aktywności
" diagramy maszyny stanów
WIDOK FUNKCJONALNY
CO!
Z CZYM! JAK!
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
6
WIDOK ZACHOWANIA
WIDOK STRUKTURALNY
Podstawy Inżynierii Oprogramowania
Aktywność
Przeznaczenie
 modeluje (koordynuje) wykonanie zachowania, stosujÄ…c
modele: przepływu sterowania jak i przepływu danych
 może być wykorzystana do opisu procesu biznesowego,
przypadku użycia lub operacji
 uszczegółowienie maszyny stanów
Elementy (specyficzne)
 akcja : podstawowa jednostka zachowania; przekształca
zbiór dane_wej w zbiór dane_wyj; czasami modyfikuje
stan systemu, w którym akcja się wykonuje; akcja jest
niepodzielna, jej trwanie nie podlega przerwaniu.
 przepływ sterowania
 przepływ obiektów; pin
 partycje (partition)
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
7
Podstawy Inżynierii Oprogramowania
Diagram przypadków użycia vs. diagram aktywności
żðPrzypadki użycia pokazujÄ…, co powinien robić system
żðDiagramy aktywnoÅ›ci umożliwiajÄ… okreÅ›lenie tego, w jaki
sposób system będzie osiągał swoje zamierzone cele
żðJakie akcje sÄ… wykonywane?
żðJak te akcje sÄ… poÅ‚Ä…czone ?
Diagramy aktywności stosuje się w modelowaniu:
" procesów biznesowych
" scenariuszy przypadków użycia
" procesów systemowych charakteryzujących się dużą liczbą
równoległych czynności i decyzji
" operacji
" algorytmów
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
8
Podstawy Inżynierii Oprogramowania
Diagram Aktywności  notacja podstawowa
Aktywność jest opisywana diagramem aktywności
reprezentowanym przez graf, którego wierzchołkami są
węzły akcji, obiektu bądz
węzły sterowania.
Krawędzie reprezentują przepływ sterowania między
węzłami.
Decyzja/ PoczÄ…tek
scalenie
Koniec
Rozwidlenie/
aktywności przepływu
złączenie
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
9
Podstawy Inżynierii Oprogramowania
Diagram Aktywności  przykład
[brak coli]
[brak kawy]
Znajdz

napój
[jest kawa]
[jest cola]
Daj kawÄ™
do filtru
Dodaj wodÄ™ Daj
do zbiornika filiżankę
Wstaw filtr Daj puszki
do ekspresu coli
WÅ‚Ä…cz
Ekspres
Parz kawÄ™
Napełnij kawą Odbierz
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
12
Podstawy Inżynierii Oprogramowania
Diagram Aktywności - sygnały
Czynności uruchamiane jako reakcja na sygnał czasowy
Rezerwacja
biletu
Nadanie sygnału
Odebranie sygnału
Upływ 48h
Akcept
acja
rezerw
acji
Kasowanie
rezerwacji
Potwierdzenie
rezerwacji
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
13
Podstawy Inżynierii Oprogramowania
Diagram Aktywności 
przykład z przepływem danych i przepływem sterowania
Recepcja Lekarz Laboratorium Zewnętrzne
Laboratorium
Rejestracja
Karta
informacyjn
a
Diagnoza
Karta
[Potrzeba analizy zewnętrznej?]
informacyjn
Gromadze
Formularz
a
-nie Zapytanie
[niewypeł-
danych
niony]
[Potrzeba analizy laboratoryjnej?]
Zapytanie
Przygotowanie formularza
Przekazanie
Analiza
formularza
zapytania
Wyniki
Analiza
analizy
Odpowiedz

Formularz
Odpowiedz
[wypełnio-
ny]
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
14
Podstawy Inżynierii Oprogramowania
Diagram Aktywności - przykład (proces biznesowy)
Czynność
Składanie
zamówienia
Węzeł
Decyzja
poczÄ…tkowy
(warunek)
Przydzielanie
miejsc
[zamówienie bezpośrednie]
[zamówienie - subskrypcja]
Wątek/krawędz

[stały klient?]
Przydzielanie
Obciążanie karty
miejsc
kredytowej
Udzielanie
rabatu
Obciążanie
rachunku
Rozwidlenie/złączenie
(równoległe)
Scalenie
Węzeł końcowy
Przesłanie
biletów
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
15
Podstawy Inżynierii Oprogramowania
Dekompozycja aktywności
na podaktywności
DostawaProdukt
Zwykłe
[else]
Zamówien Zamówien
[pilne]
48h
Parametr
Wejściowy Wyjściowy
Osiągnięcie precyzyjnego opisu - konieczna
dekompozycja aktywności.
Aktywności mogą dekomponowane na
zhierarchizowane podaktywności
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
16
Podstawy Inżynierii Oprogramowania
Modelowanie biznesowe*
" Motywacja: SK
D WYMAGANIA
Własności systemu powinny wynikać z potrzeb klientów i rozwiązywać ich
rzeczywiste problemy
Cele modelowania biznesowego:
- zrozumienie struktury i dynamiki organizacji
- zapewnienie jednolitego rozumienia organizacji przez wytwórców i uczestników
procesu (opracowanie wspólnego słownika)
- wyprowadzenie wymagań systemu niezbędnych do wsparcia organizacji
Formy modelowania biznesowego
(a) uproszczona, w której buduje się jedynie model domenowy, ilustrujący
podstawowe byty i związki pomiędzy nimi, występujące w dziedzinie zastosowań,
(b) pełna, w której buduje się model biznesowych przypadków użycia oraz model
obiektów biznesowych.
* materiał dodatkowy
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
19
Podstawy Inżynierii Oprogramowania
Procesy biznesowe
PB: naprawa zestawów komputerowych
PB: zakup części komputerowych
PB: sprzedaż zestawów
Sprzedaż
komputerowych
Księgowość
Firma
Magazyn
komputerowa
Montownia
Serwis
Proces biznesowy Dział przed. Zadania działu służące wykonaniu procesu
Sprzedaż urządzeń Sprzedaż Pozyskanie klienta, przyjęcie zamówienia,
złożenie zamówienia montowni, sporządzenie
dokumentów sprzedaży
Księgowość Zbadanie zdolności kredytowej klienta
Montownia Złożenie zamówienia zestawów
Magazyn Dostarczenie elementów do montażu zestawów
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
20
Podstawy Inżynierii Oprogramowania
Definicje podstawowych artefaktów modelu
biznesowego
" Słownik pojęć dziedzinowych
" Model biznesowych przypadków użycia:
" Biznesowe przypadki użycia (procesy biznesowe)  zbiór instancji
(scenariuszy) akcji wykonywanych w przedsiębiorstwie dających mierzalną
wartość aktorowi biznesowemu; wyróżnia się przypadki biznesowe jądra
(tzw. core)  składające się na podstawowy zbiór usług organizacji,
postrzeganych przez aktorów biznesowych oraz przypadki biznesowe
pomocnicze, wspierające podstawową działalność biznesową
" Aktorzy biznesowi  reprezentuje rolÄ™ granÄ… przez kogoÅ› lub przez coÅ› w
otoczeniu przedsiębiorstwa
" Notacja: diagramy przypadków użycia; opisy tekstowe przypadków użycia
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
21
Podstawy Inżynierii Oprogramowania
Definicje podstawowych artefaktów modelu
biznesowego, c.d.
" Model obiektów biznesowych:
" Jednostki organizacyjne  element grupujÄ…cy inne elementy modelu
(odpowiednik pakietu)
" Realizacje biznesowych przypadków użycia  sposób wykonania
danego procesu biznesowego:
" Pracownicy biznesowi  klasa modelująca człowieka pracującego w
organizacji
" Byty (encje) biznesowe  pasywna klasa reprezentująca obiekty, które
są wytwarzane/modyfikowane/przetwarzane przez pracowników
biznesowych
Notacja: diagramy klas (również zawierające pakiety)  aspekt statyczny,
diagramy aktywności, diagramy sekwencji lub współdziałania  aspekt
dynamiczny
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
22
Podstawy Inżynierii Oprogramowania
Przykład dokumentacji procesu
biznesowego
Used by:
Zamawiajacy usluge transportowa
Description:
Usługa transportowa polega na przetransportowaniu chorego, krwi lub organów z miejsca
wskazanego przez Osobę zamawiającą usługę transportową do szpitala lub innego
wskazanego miejsca. Kierowca realizujący kurs ma obowiązek wypełniania karty drogowej.
Przepływ :
1. Osoba zamawiająca usługę transportową dzwoni do Dyspozytorni z poleceniem
wykonania usługi transportowej.
2. Dyspozytor przyjmuje zlecenie, podejmuje decyzję o wysłaniu odpowiedniego pojazdu.
3. Dyspozytor wybiera jednego z dostępnych kierowców i zleca mu wykonanie kursu.
4. Kierowca realizuje zlecony kurs, po czym wypełnia Kartę drogową.
Proponowane usprawnienia: ewidencja Kart drogowych
Intent:
Celem usługi jest przewiezienie chorego, krwi lub organów do przeszczepów z miejsca
wskazanego przez Zamawiającego usługę do szpitala lub innego wskazanego miejsca
Pre Conditions:
Podpisana umowa ze Szpitalem
Post Conditions:
Zrealizowany kurs, wypełniona karta drogowa.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
23
Podstawy Inżynierii Oprogramowania
Realizacja procesu biznesowego -diagram
aktywności
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
24
Podstawy Inżynierii Oprogramowania
Przykład
Model obiektów biznesowych  diagram klas
(jednostki organizacyjne)
WÅ‚adze
Biuro prorektora
Zespół domów studenckich
Domy studenckie
Wydziały
Władze uczelni  organ odpowiedzialny za działalność Politechniki Wrocławskiej
Wydział - podstawowa jednostka organizacyjna uczelni. Jego zadaniem jest samodzielne
prowadzenie działalności dydaktycznej i naukowej. W kontekście bieżącego opracowania wydział,
którego pracami steruje dziekanat, zajmuje się głównie rozpatrywaniem podań studentów.
W ramach Politechniki Wrocławskiej istnieje 12 wydziałów.
Domy studenckie - mieszkalne budynki będące własnością Politechniki Wrocławskiej, w których
zamieszkują studenci. Za każdy akademik odpowiada jego Kierownik.
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
25
Podstawy Inżynierii Oprogramowania
Przykład (cd)  opis procesu
diagramem aktywności
Dziekanat Student
Składanie
podań
Podanie
Pula miejsc
wydzi ału
Rozpatrywanie
podań
Byty biznesowe
Składanie podań -
uzupełnienia
Promesa Lista
rezerwowa
Podanie
Uzupełnienie
i
weryfikacja
Lista Lista
rezerwowa ostateczna
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
26
Podstawy Inżynierii Oprogramowania
Modelowanie biznesowe - podsumowanie
Kontekst systemu można opisać:
- Pełnym modelem biznesowym
- Modelem domenowym
Zarówno model biznesowy, jak i wizja systemu służą do
wyprowadzenia (identyfikacji i opracowania) specyfikacji
wymagań
Instytut Informatyki, Wydział Informatyki i Zarządzania,
2012/2013
29