Wprowadzenie do metodyki
RUP
Implementacja notacji UML
Cel metodyki
Przeprowadzić wykonawcę od celów strategicznych
organizacji zamawiającego do wdrożenia produktu
informatycznego wspierającego wybrane cele
Kroki:
Identyfikacja celów organizacji na różnych poziomach
abstrakcji
Przełożenie celów na procesy, czynności i odpowiedzialności
pracowników
Identyfikacja zakresu (pracowników lub odpowiedzialności)
możliwego wsparcia systemem informatycznym
Modelowanie wymagań na różnych poziomach abstrakcji
Sterowane wymaganiami modelowanie i implementacja
Oparta o wymagania weryfikacja, wdrażanie, walidacja
Fazy i dyscypliny wg RUP
Konsekwencje
Omawiane dalej czynności przedstawione są
zgodnie z kolejnością ich wykonywania
Ale wykonywane są zazwyczaj równocześnie z
intensywnością zależną od iteracji
Czynności są cyklicznie powtarzane dla
realizacji kolejnych wymagań
Istotnymi zmianami w procesie są momenty
przejścia między fazami – warunki przejść są
bardziej precyzyjnie określone
Pięć perspektyw projektu
Perspektywa logiczna
Perspektywa komponentów
Perspektywa procesów
Komponenty
Klasy, interfejsy,
interakcje
Procesy (klasy aktywne)
Perspektywa montażowa
Węzły
Perspektywa
przypadków użycia
Use cases
Modelowanie organizacji
(skrótowo)
Opcjonalne
Na ogólnym poziomie – mało
szczegółów
Jak otoczenie widzi organizację
Jak organizacja funkcjonuje – realizuje
funkcje (procesy) widziane przez
otoczenie
Przypadki użycia organizacji
Elementy otoczenia
Usługi organizacji (procesy)
Wzajemne związki otoczenia i procesów
Hierarchia elementów (specjalizacje)
Struktura elementów (asocjacje)
Uszczegółowienie elementów
Diagramy stanów
Diagramy aktywności
„Tory pływackie”
Diagram przypadków użycia
organizacji
Przyjmowanie dostaw
(from Przypadki użycia)
Dostawca
(f rom Aktorzy )
Zakup z rabatem
(from Przypadki użycia)
Klient specjalny
(f rom Aktorzy )
Kupowanie
(from Przypadki użycia)
Wystawianie faktur
(from Przypadki użycia)
Klient
(f rom Aktorzy )
Struktura przypadków użycia
organizacji
Klient
(f rom Aktorzy )
Oferta
(from Wspólne)
Wybór towaru
(from Wspólne)
Płacenie
(from Wspólne)
Wystawienie faktury
(from Wspólne)
Kupowanie
<<include>>
<<include>>
<<include>>
<<extend>>
Diagramy aktywności
Wejście
Zapytanie
Pytanie ocenę
Płacenie
Wyjście
[ brak akceptacji ceny ]
[ cena odpowiada ]
Oferta
Oferta
alternatywna
[ jest towar ]
[ brak towaru ]
[ towar odpowiada ]
[ brak odpowiadjącego towaru ]
New Sw imlane2 : Sprzedaw ca
New Sw imlane : Klient
Model obiektowy organizacji
Realizacja przypadków użycia
Diagramy sekwencji – dynamiczne
związki (komunikaty)
Diagramy współpracy
Diagramy klas
Operacje z diagramów sekwencji
Związki – z komunikatów + inne
Atrybuty – uszczegółowienie klas
Realizacja przypadku użycia
Kupowanie
Kupowanie
(from Przypadki użycia)
Diagram sekwencji
: Klient
: Sprzedawca
: Magazynier
: Towar
: Kasjer
Powitanie( )
Pytanie o towar( )
Sprawdzenie w magazynie( )
Pobranie z magazynu( )
Zapłacenie( )
Odebranie towaru( )
Diagram współpracy
: Klient
: Sprzedawca
: Magazynier
: Towar
: Kasjer
1: Powitanie( )
2: Pytanie o towar( )
6: Odebranie towaru( )
5: Zapłacenie( )
3: Sprawdzenie w magazynie( )
4: Pobranie z magazynu( )
Diagram klas
I co dalej
Wybór elementów podlegających
informatyzacji (określenie granic
budowanego oprogramowania)
Określenie otoczenia oprogramowania
Przejście do specyfikacji wymagań
Specyfikacja wymagań
Model przypadków użycia (wymagania
funkcjonalne)
Specyfikacje przypadków użycia
Wymagania dodatkowe (głównie
niefunkcjonalne – ilościowe,
jakościowe)
Aktorzy i przypadki użycia
Odczytanie Stanu
(from Odczytanie Stanu)
Użytkownik
(f rom Actors)
Zewnętrzna Baza
Danych
(f rom Actors)
Odczyt Danych
(from Odczyt Danych)
Czujnik
(f rom Actors)
Przeglądy Analityczne
(from Use Cases)
Dyrektor
(f rom Actors)
Ustalenie Uprawnień
(from Use Cases)
Analiza Integralności Systemu
(from Use Cases)
Administrator
(f rom Actors)
Specyfikacja przypadku użycia
Table of Contents
1.
Brief Description
2.
Basic Flow of Events
3.
Alternative Flows
3.1
<Area of Functionality>
3.1.1
< A1 First Alternative Flow >
3.1.2
< A2 Second Alternative Flow >
3.2
<Another Area of Functionality>
3.2.1
< AN Another Alternative Flow >
4.
Subflows
4.1
<S1 First Subflow >
4.2
< S2 Second Subflow >
5.
Key Scenarios
6.
Preconditions
6.1
< Precondition One >
7.
Postconditions
7.1
< Postcondition One >
8.
Extension Points
8.1
<Name of Extension Point>
9.
Special Requirements
9.1
< First Special Requirement >
10.
Additional Information
Uszczegółowienie przypadków
użycia
Użytkownik
(f rom Actors)
Pobranie Danych
(from Pobranie Danych)
Budowanie Raportu
(from Budowani e Raportu)
Obsługa Awarii
(from Obsługa Awarii)
Odczytanie Stanu
<<include>>
<<include>>
<<extend>>
Opis diagramami aktywności
Pobranie parametrów
raportu
Pobranie danych
historycznych
[ Raport przekrojowy ]
Pobranie danych
aktualnych
[ Raport bieżący ]
Wydruk raportu
[ Dane Poprawne ]
Wydruk Informacji
o Błędzie
[ Dane Błędne ]
Opis diagramami stanów
Inicjalizacja
entry/ Inicjuj Zegar
event Czujnik/ null
Start Oprogramowania
Organizacja danych
do/ Porządkowanie Danych
Odczyt
Czujnika
entry/ Pomiar
Czujnik
Odczyt Bazy Danych
entry/ Importuj Dane
exit/ Inicjuj Zegar
Czujnik
Zegar
Czujnik
Koniec Czytania Baz Daych
Koniec Pomiaru[ Z organizacji danych ]
Koniec Pomiaru[ Z czytania bazy danych ]
Start Zegara
Wymagania dodatkowe
Table of Contents
1.
Introduction
1.1
Purpose
1.2
Scope
1.3
Definitions, Acronyms, and Abbreviations
1.4
References
1.5
Overview
2.
Functionality
2.1
<Functional Requirement One>
3.
Usability
3.1
<Usability Requirement One>
4.
Reliability
4.1
<Reliability Requirement One>
5.
Performance
5.1
<Performance Requirement One>
6.
Supportability
6.1
<Supportability Requirement One>
7.
Design Constraints
7.1
<Design Constraint One>
8.
Online User Documentation and Help System Requirements
9.
Purchased Components
10.
Interfaces
10.1
User Interfaces
10.2
Hardware Interfaces
10.3
Software Interfaces
10.4
Communications Interfaces
11.
Licensing Requirements
12.
Legal, Copyright, and Other Notices
13.
Applicable Standards
Analiza
Poszukiwanie klas analitycznych
Wiedza dziedzinowa
Wymagania
Dokumenty źródłowe
...
Budowanie diagramów klas
analitycznych – dla każdego przypadku
użycia
Diagram klas analitycznych
Warstwowa konstrukcja
oprogramowania
Podział na warstwy z hierarchicznym
dostępem do usług
Zazwyczaj trzy/cztery warstwy, nie
więcej niż dziesięć
Projekty pakietów i podsystemów
umieszcza się w warstwach
Typowy model warstw
oprogramowania
Prezentacje
<<layer>>
Logika
<<layer>>
Usługi
<<layer>>
Strukturyzacja projektu
Podział na pakiety
Dla uporządkowania
Wyróżnienie podsystemów
Pakiety, które „widziane” są tylko poprzez
określone usługi
Modelowanie interfejsów – specyfikacja usług
Określenie związków zależności między
pakietami (rozwijane w trakcie projektu)
Diagram klas dla zależności
między pakietami
Projekt oprogramowania
Budowany dla kolejnych przypadków użycia –
wymagań funkcjonalnych
Pierwotnie modelowana dynamika
oprogramowanie – sposób realizacji wymagań
Modelowanie dynamiki oddzielnie dla każdej
ścieżki
Wnioski z modelu dynamicznego służą
zbudowaniu modelu statycznego (klas)
Model statyczny uzupełnia się o potrzebne do
przetwarzania atrybuty
Diagram sekwencji dla ścieżki
głównej
: Użytkownik
: Budowanie_Raportu
: Formularze
: Obliczenia
: IPomiary
Raport_Stanow( )
Wejscie_Raportu_Stanow( )
Przetworz_Pomiary( )
Daj_Pomiar( )
Raport_Stanow( )
Aktualny
Analiza_Poprawnosci( )
Pobranie parametrów
raportu
Pobranie danych
historycznych
[ Raport przekrojowy ]
Pobranie danych
aktualnych
[ Raport bieżący ]
Wydruk raportu
[ Dane Poprawne ]
Wydruk Informacji
o Błędzie
[ Dane Błędne ]
Definicja operacji
: Użytkownik
: Budowanie_Raportu
: Formularze
: Obliczenia
: IPomiary
Raport_Stanow( )
Wejscie_Raportu_Stanow( )
Przetworz_Pomiary( )
Daj_Pomiar( )
Raport_Stanow( )
Aktualny
Analiza_Poprawnosci( )
Dla innego wariantu (można
na jednym diagramie)
: Użytkownik
: Budowanie_Raportu
: Formularze
: Obliczenia
: IPomiary
Wielokrotne
pobranie
danych za
okres
Raport_Stanow( )
Wejscie_Raportu_Stanow( )
Przetworz_Pomiary( )
Daj_Pomiar( )
Raport_Stanow( )
Analiza_Poprawnosci( )
Pobranie parametrów
raportu
Pobranie danych
historycznych
[ Raport przekrojowy ]
Pobranie danych
aktualnych
[ Raport bieżący ]
Wydruk raportu
[ Dane Poprawne ]
Wydruk Informacji
o Błędzie
[ Dane Błędne ]
Dla ścieżki alternatywnej
: Użytkownik
: Budowanie_Raportu
: Formularze
: Obliczenia
: IPomiary
Raport_Stanow( )
Wejscie_Raportu_Stanow( )
Przetworz_Pomiary( )
Daj_Pomiar( )
Formularz_Bledu( )
Dane błędne
Analiza_Poprawnosci( )
Pobranie parametrów
raportu
Pobranie danych
historycznych
[ Raport przekrojowy ]
Pobranie danych
aktualnych
[ Raport bieżący ]
Wydruk raportu
[ Dane Poprawne ]
Wydruk Informacji
o Błędzie
[ Dane Błędne ]
Przejście do diagramu
współpracy (automatyczne)
: Użytkownik
: Budowanie_Raportu
: Formularze
: Obliczenia
: IPomiary
5: Analiza_Poprawnosci( )
1: Raport_Stanow( )
7:
2: Wejscie_Raportu_Stanow( )
6: Raport_Stanow( )
3: Przetworz_Pomiary( )
4: Daj_Pomiar( )
: Użytkownik
: Budowanie_Raportu
: Formularze
: Obliczenia
: IPomiary
Raport_Stanow( )
Wejscie_Raportu_Stanow( )
Przetworz_Pomiary( )
Daj_Pomiar( )
Raport_Stanow( )
Aktualny
Analiza_Poprawnosci( )
Przejście do diagramu klas
(ręczne)
: Użytkownik
: Budowanie_Raportu
: Formularze
: Obliczenia
: IPomiary
5: Analiza_Poprawnosci( )
1: Raport_Stanow( )
7:
2: Wejscie_Raportu_Stanow( )
6: Raport_Stanow( )
3: Przetworz_Pomiary( )
4: Daj_Pomiar( )
Projekt operacji
Opis algorytmów z wykorzystaniem wspólnej
notacji
Pseudokod (PDL)
Składnia znanego, wysokopoziomowego języka
programowania
W formie opisowej:
Warunki
Działania (instrukcje)
Typy zmiennych
...
Perspektywa procesów
Przedstawia podział na procesy i wątki
(ostateczny)
Podstawowym źródłem procesów są klasy
sterujące
Przedstawia
związki między procesami
związki między procesami a klasami i interfejsami
podsystemów
Dla projektów jednoprocesowych
perspektywa jest pomijana
Diagram procesów
Raporty
<<process>>
Raport_Stanu
<<thread>>
Interfejsy
<<process>>
Związek z klasami
Interfejsy
<<process>>
Raporty
<<process>>
Raport_Stanu
<<thread>>
Formularze
(f rom Raporty )
Obliczenia
(f rom Raporty )
Budowanie_Raportu
(f rom Raporty )
0..n
1
0..n
+Formularze
1
+Obliczenia
0..n
1
0..n
1
Perspektywa komponentów
Jest spojrzeniem implementacyjnym
Dla prostych projektów może być pominięta
Przedstawia związek klas z: jednostkami kompilacji
(plikami), np.:
programami
procedurami
pakietami
zadaniami
bazami danych, „jar’ami”, „bin’ami” itp.
Związki między komponentami – importy
Ewentualny podział na pakiety – podsystemy
implementacyjne
Diagram komponentów
Raporty
Formularze
Formularze
Raport_Stanu
Raport_Stanu
Interfejsy
Interfejsy
Związki komponentów z
klasami
Raporty
Formularze
Formularze
Raport_Stanu
Raport_Stanu
Interfejsy
Interfejsy
Perspektywa montażowa
Odzwierciedlenie istotnych dla
oprogramowania cech środowiska
sprzętowego:
Procesory (z charakterystyką przełączania
procesów)
Urządzenia
Powiązania
Związek procesów (w tym programów) z
procesorami
Diagram montażowy
Serwer Obliczeniowy
preemptive
Raporty
Raport_Stanu
Drukarka
Serwer Danych
preemptive
Interfejsy
USB
Ethernet 100
Element aktywny -
procesor
Element
pasywny -
urządzenie
Projektowanie w skrócie
Określenie wymagań (szczególnie UC)
Modelowanie realizacji wymagań jako
sekwencji komunikatów (operacji)
Suma sekwencji jest podstawą do
modelu statycznego (klas)
Projektowanie operacji i uzupełnienie
argumentów klas (wektory stanów)
Inne czynności
Modelowanie organizacji
Budowanie modelu analitycznego
Podział na warstwy
Budowanie perspektywy procesów
Przydział klas do komponentów
Przydział procesów do komputerów
Budowanie modelu danych
Wprowadzenie do metodyki
RUP
Koniec