Wprowadzenie do metodyk obiektowych

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>>

<<extend>>

Diagramy aktywności

Wejście

Zapytanie

Pytanie ocenę

Płacenie

Wyjście

[ brak akceptacji ceny ]

[ cena odpowiada ]

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

(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

Brief Description

Basic Flow of Events

Alternative Flows

3.1

3.1.1

< A1 First Alternative Flow >

3.1.2

< A2 Second Alternative Flow >

3.2

3.2.1

< AN Another Alternative Flow >

Subflows

4.1

4.2

< S2 Second Subflow >

Key Scenarios

Preconditions

6.1

< Precondition One >

Postconditions

7.1

< Postcondition One >

Extension Points

8.1

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>>

<<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

Functionality

2.1

Usability

3.1

Reliability

4.1

Performance

5.1

Supportability

6.1

Design Constraints

7.1

Online User Documentation and Help System Requirements

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( )

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( )

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

+Formularze

+Obliczenia

0..n

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

Raport_Stanu

Interfejsy

Związki komponentów z

klasami

Raporty

Formularze

Raport_Stanu

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