Projektowanie

systemów

informatycznych

Obiektowa metodyka TSI

Obiektowość

Obiektowość

jest podejściem, które wynika z

zaobserwowanych wad istniejącego świata i podaje receptę jak
te wady usunąć.
Wady:



złożoność: przekleństwo ciążące na większości projektów i

produktów informatyki,



kryzys softwerowy: oprogramowanie i jego utrzymanie kosztuje

zbyt dużo i problemem jest zawodne współdziałanie pomiędzy
produktami programowymi,



niedopasowanie metodyk analizy i projektowania systemów

informacyjnych do bazy realizacyjnej systemów (języków
programowania, systemów zarządzania bazami danych).

Głównym problemem systemów stał się człowiek (analityk,
projektant, programista).
Technologie komputerowe powinny być bardziej zorientowane
na ludzi, nie na maszyny

Co
robić
?

Podwyższyć poziom abstrakcji w projektowaniu i
programowaniu.
Dopasować wszystkie fazy projektu do uwarunkowań
technicznych i ludzkich.

2

GK (PSI(3) - 2009)

Obiektowość - oczekiwania

Większa wydajność i krótszy tworzenia systemów
informatycznych, mniejsze koszty tworzenia i utrzymywania
systemu.



Mechanizmy abstrakcji dostarczone projektantowi,
pozwalające budować coraz większe systemy i operować
tymi jednostkami bez wnikania w ich wewnętrzną strukturę;
oddzielenie specyfikacji od implementacji,



mechanizmy kompozycji i dekompozycji:

•

zamykanie detali projektu lub oprogramowania w coraz
większe jednostki,

•

dekomponowanie złożonych struktur na fragmenty i
rozpatrywanie tych fragmentów niezależnie od siebie i
niezależnie od całości,



ponowne użycie (reuse) wcześniej wytworzonych
komponentów. może ono dotyczyć wszystkich elementów
danych, funkcji i oprogramowania.



podstawowe mechanizmy tworzenia wyspecjalizowanych klas
oraz tworzenia agregatów.

Efekty:

Jakość, niezawodność, testowalność, rozszerzalność,
łatwa pielęgnacja
systemu, szybkie prototypowanie, współdziałanie,
przenaszalność.

3

GK (PSI(3) - 2009)

Obiekt

Obiektem

jest

rzecz

lub

pojęcie

obserwowane w świecie

rzeczywistym, którego dotyczy system informatyczny. Obiekt

jest odróżnialny od innych obiektów, ma dobrze określone

granice i nazwę.

Obiektem

może być także pewien zamknięty fragment

systemu (dana, procedura, moduł, dokument, okienko

dialogu,...), którym można operować jako zwartym tworem

(wyszukiwać, wiązać, kopiować, blokować, usuwać,

indeksować, ...).

Obiekt

posiada swoją

tożsamość

, która wyróżnia go

spośród innych obiektów. Tożsamość obiektu jest niezależna

od wartości jakichkolwiek jego atrybutów i od jego lokacji w

świecie rzeczywistym lub w przestrzeni adresowej komputera

(praktycznie: tożsamość = trwały wewnętrzny identyfikator

obiektu).

Obiekt

posiada

stan

, który może zmieniać się w czasie

(bez zmiany tożsamości obiektu).

Obiekt

może być

złożony

, tj. może składać się z

mniejszych obiektów, przy czym obiekt złożony zawiera w

sobie wszelkie dane, które składają się na jego stan.

Obiekt

może być

powiązany

z innymi obiektami

związkami asocjacyjnymi.

Obiekt

ma przypisane zachowanie, tj. zestaw operacji,

które wolno do niego stosować (implementacja operacji jest

zwana metodą).

Obiekt

ma przypisany

typ

, tj. wyrażenie językowe, które

ogranicza dopuszczalną budowę obiektu oraz ustala operacje,

które wolno wykonać na obiekcie.

4

GK (PSI(3) - 2009)

Obiekt

Obiekt

- struktura złożona z:

• danych,
• operacji tj. czynności (funkcji)

wykonywanych na tych danych.

Cechy obiektu:

• tożsamość

– cecha umożliwiająca jego

identyfikację,

• stan

– aktualne wartości danych,

• zachowanie

– zbiór operacji wykonujących

działania na tych danych.

5

GK (PSI(3) - 2009)

Klasa

Klasa

jest nazwanym

zbiorem obiektów

o podobnych

własnościach. Własności te (zestaw atrybutów, metody) są
określone w definicji klasy. Stosunek klasa/podklasa oznacza
zawieranie się zakresów znaczeniowych. Np. zbiór obiektów
Student zawiera się w zbiorze obiektów Osoba.

Klasa

jest miejscem przechowywania cech grupy

obiektów, które są niezmienne (inwariantów). Klasa nie jest
zbiorem obiektów i niekoniecznie jest definicją zbioru
obiektów. Stosunek klasa/podklasa oznacza, że obiekty
podklasy posiadają wszystkie inwarianty nadklasy, plus swoje
inwarianty. Np. klasa Student ma wszystkie inwarianty klasy
Osoba, plus niektóre własne.

Najważniejsze:

Nazwa, czyli językowy identyfikator obiektu.
Typ, czyli statyczna budowa obiektu (atrybuty).
Metody, czyli operacje, które można wykonać na
obiekcie.

6

GK (PSI(3) - 2009)

Klasa



Zbiór wszystkich cech obiektów o tej samej

strukturze i zachowaniu oraz definicji

rodzajów tych zachowań.



Określa strukturę oraz zachowania obiektów,

które będą należały do danej klasy.



Identyfikowana przez nazwę.



Stanowi pewien rodzaju „typu danych”.



Klasa stanowi szablon dla obiektu (zawiera

cechy obiektu oraz opis jego zachowania).



Na podstawie klasy tworzony jest obiekt (tzw.

instancja klasy).



Definicja obiektu zawiera cechy zdefiniowane

przez klasę (atrybuty oraz operacje).

7

GK (PSI(3) - 2009)

Obiektowość – podstawowe

założenia

Złożone obiekty

- system powinien składać się z małych,

zrozumiałych modułów, zawierających struktury danych i
dozwolone na nich operacje, czyli

obiektów

.

Powiązania

- obiekty mogą być powiązane związkami

asocjacyjnymi.

Hermetyzacja

– jednoznaczne rozróżnienie pomiędzy

interfejsem do obiektu opisującym co obiekt zawiera i co
robi, a implementacją definiującą jak on jest zbudowany i jak
on to robi.

Typy i klasy

- zgrupowanie obiektów o tych samych

charakterystykach i traktowanie ich jako bytów tej samej
klasy; sprawdzanie typologicznej poprawności użycia
obiektów.

Dziedziczenie

- r

elacja między klasami mówiąca o tym, że

dana klasa (podklasa) współdzieli strukturę i zachowanie
zdefiniowane w jednej lub wielu klasach (nadklasach).
Podklasa najczęściej jest specjalizacją swojej nadklasy
poprzez doprecyzowanie lub rozszerzenie odziedziczonej
struktury i zachowania.

Komunikaty

- obiekt wykonuje jedną z jego funkcji po

wysłaniu do niego odpowiedniego komunikatu, który nie
zależy od tego jak obiekt jest zaimplementowany.

Polimorfizm

- wybór nazwy dla operacji jest określony

wyłącznie jej zewnętrznym, pojęciowym znaczeniem. Obiekt
sam decyduje, którą operację wybrać, jeżeli w skierowanym
do niego komunikacie została użyta ta nazwa.

8

GK (PSI(3) - 2009)

Metodyka obiektowa

Własności obiektowej metodyki TSI:



wykorzystuje pojęcia obiektowości dla celów modelowania
pojęciowego oraz analizy i projektowania systemów
informatycznych,



podstawowym składnikiem jest diagram obiektów, będący
zwykle wariantem notacyjnym i pewnym rozszerzeniem
diagramów encja-związek,



diagram obiektów zawiera takie elementy jak: klasy, w ramach
klas specyfikacje atrybutów i metod, strukturę dziedziczenia
pomiędzy klasami, związki asocjacji i agregacji, liczności tych
związków, różnorodne ograniczenia oraz inne oznaczenia,



uzupełnieniem tego diagramu są inne, np. diagramy dynamiki
uwzględniające stany poszczególnych procesów przetwarzania i
przejścia pomiędzy tymi stanami, diagramy zależności
pomiędzy wywołaniami metod, np. diagram tropów
komunikatów, diagramy funkcjonalne (będące zwykle pewną
mutacją diagramów przepływu danych),



odwzorowanie struktury systemu z punktu widzenia jego
użytkownika za pomocą diagramów przypadków użycia (use
cases).

Podejście obiektowe

- paradygmat rozwiązywania problemów

projektowych z wykorzystaniem obiektów, sposób

interpretacji problemu jako zbioru obiektów i relacji

pomiędzy nimi.

9

GK (PSI(3) - 2009)

Główna różnica pomiędzy podejściem obiektowym w
tworzeniu systemów informatycznych, a podejściem
tradycyjnym (strukturalnym):



podejście obiektowe nie opiera się na funkcjonalnej

dekompozycji procesów zachodzących w świecie
rzeczywistym, a na opisie obiektów rzeczywistych, które
grają określoną rolę w tym świecie,



obiektowość jest sposobem myślenia i organizacji

systemu, polegającym na wyodrębnianiu dyskretnych
obiektów, które odwzorowują zarówno statyczną strukturę
świata i danych, jak i jego zachowanie (behaviour).

Istotna jest identyfikacja i organizacja pojęć
z dziedziny aplikacyjnej, a nie pojęć z
dziedziny implementacyjnej.

Metodyka obiektowa

10

GK (PSI(3) - 2009)

Metodyki obiektowa

Martin/Odell

BON (Business Object Notation), Nerson & Walden

OODA, Booch

Catalysis, D’Souza & Wills

EROOS (Entity-Relationship Object-Oriented Specification)

Fusion, HP Laboratories

MOSES (Methodology for Object-Oriented Software Engineering of System)

OORAM

OSA

OOSA, Shlaer-Mellor

Sintropy

OMT,
Rumbaugh

Objectory, Jacobson

OOA/OOD, Coad/Yourdon

DOOS, Wirfs-Brock

MainstreamObjects, Yourdon

Express

Goldberg/Rubin

UML (Unified Modelling Language), Booch, Jacobson, Rumbaugh

11

GK (PSI(3) - 2009)

Metodyka

RUP

(Rational Unified Process):



Jest konfigurowalnym procesem wytwórczym inżynierii
systemów.



Jest metodyką wytwarzania systemów opartą na iteracyjności,
najlepszych praktykach i szerokim wykorzystaniu modeli,
której głównym celem jest zagwarantowanie dostarczenia
produktu o wysokiej jakości, który spełnia oczekiwania
zleceniodawcy i jest wykonany w planowanym czasie i
budżecie.



Jest platformą narzędziową wspierającą proces tworzenia
systemu.



Jest przewodnikiem zawierającym bazę wskazówek i
szablonów przydatnych w krytycznych momentach tworzenia
systemu.



Dostarcza zestawu wskazówek dotyczących:

•

zarządzania projektantami i zespołami projektantów

,

•

kolejności wykonywania określonych przedsięwzięć przez
zespół projektowy.



Informuje o tym, które artefakty należy tworzyć i kiedy.



Ustala kryteria oceny realizacji prac projektowych oraz
uzyskiwanych artefaktów.



Nie narzuca jedynej słusznej drogi do celu, ale przedstawia
szereg sprawdzonych metod, które są skuteczne w zależności
od kontekstu organizacji.



Może być dopasowywana do potrzeb.

RUP - czym jest

12

GK (PSI(3) - 2009)

RUP bazuje na kilku ważnych elementach zwanymi

najlepszymi praktykami (ang. best practices), które są ogólnie
znane i stosowane jako dobre rozwiązania w tworzeniu
systemów informatycznych.
Praktykami tymi są:

•iteracyjne tworzenie systemu

– umożliwia stopniowe

zrozumienie problemu i przyrostowe opracowywanie
rozwiązania,

•zarządzanie wymaganiami

- opisuje jak gromadzić,

organizować i dokumentować wymaganą funkcjonalność i
ograniczenia systemu,

•stosowanie architektury opartej na komponentach

– umożliwia

tworzenie elementów systemu przy użyciu dobrze opisanych
komponentów, modułów,

•wizualne modelowanie różnych aspektów systemu

–

przedstawia jak wizualnie modelować system w celu określenia
jego struktury i zachowania architektury,

•weryfikacja jakości oprogramowania

– pomaga w planowaniu,

wykonaniu i oszacowaniu wyników testów,

•kontrola zmian w systemie

– opisuje jak kontrolować wszelkie

zmiany wprowadzane do dokumentów, modeli i kodu.

RUP – metodyka

– najlepsze

praktyki

13

GK (PSI(3) - 2009)

Rozwój przyrostowy:

• w praktyce nie jest możliwe odgadnięcie jakie funkcje

będzie miał tworzony system, gdy zostanie ukończony,

• RUP zaleca sukcesywny przegląd sformułowanych

wymagań i ich realizowanie w sposób iteracyjny,

• początkowo realizuje się najważniejsze wymagania z

punktu widzenia użytkownika, dostarczając możliwie
najwcześniej działające najważniejsze funkcje systemu,

• modyfikacja wymagań, ograniczeń, planowanego czasu

wykonania projektu oraz jego budżetu jest dużo
łatwiejsza przy stosowaniu podejścia przyrostowego,

• klient może oceniać produkt przed jego ukończeniem.

14

GK (PSI(3) - 2009)

RUP – metodyka

– najlepsze

praktyki

Zarządzanie wymaganiami.

Istotna trudność

zarządzania wymaganiami złożonych systemów polega na tym, że
podlegają one ciągłej zmianie przez cały czas procesu tworzenia
systemu, a co za tym idzie – przez cały czas nie można w sposób
precyzyjny określić kosztów utworzenia systemu oraz terminu jego
ukończenia.

Zarządzanie wymaganiami obejmuje trzy cyklicznie

wykonywane działania:

odkrywanie

,

organizowanie

i

dokumentowanie

.

RUP podaje:

•

sposób zapisu, przechowywania i pozyskiwania wymagań
funkcjonalnych oraz niefunkcjonalnych,

•

relacje pomiędzy dokumentem wizji klienta a dokumentami fazy
analizy.

Jako środek wyrazu wymagań użytkownika metodyka RUP zaleca
stosowanie diagramów przypadków użycia (use case) w notacji UML
oraz scenariuszy. Korzystanie z tych form stanowi ułatwienie dla
zespołu projektowego, ale także umożliwia konsultacje wyników fazy
analizy z klientem.

15

GK (PSI(3) - 2009)

RUP – metodyka

– najlepsze

praktyki

Architektura oparta na komponentach.

Specyfikowanie,

budowanie i dokumentowanie złożonych systemów wymaga ich oglądu
oraz przedstawiania z różnych punktów widzenia, charakteryzujących
różnych uczestników procesu TSI: użytkownika, analityka, projektanta,
programisty itp. Jedną z zasadniczych płaszczyzn łączących wszystkie
punkty widzenia na system jest jego architektura, która w RUP jest
określana jako zbiór określonych decyzji dotyczących:



organizacji tworzonego systemu informatycznego,



wyboru elementów i ich interfejsów, z których system będzie budowany,

razem z ich zachowaniem wynikającym z wymagań użytkownika,



tworzenia systemu poprzez hierarchiczne łączenie jego elementów.

Właściwości architektury opartej na komponentach:



dobrze pasuje do koncepcji iteracyjnego wytwarzania oprogramowania,



podstawową jednostkę przy analizie i projektowaniu systemu stanowią

podsystemy i pakiety,



dobrze pasuje do sposobu testowania zalecanego przez RUP, tj.

testowania każdego kawałka z osobna i systemu po integracji jako całości,



łatwość wprowadzania zmian – zgodność z ideą zarządzania

wymaganiami,



łatwość korzystania z dostępnych baz komponentów systemów

informatycznych (także Open Source).

16

GK (PSI(3) - 2009)

RUP – metodyka

– najlepsze

praktyki

Modelowanie wizualne:



modele stanowią uproszczoną reprezentację rzeczywistości
przez co stają się możliwe do realizacji,



większość metodyki RUP dotyczy:

•

tworzenia modeli i zarządzania nimi,

•

określenia ról, które są odpowiedzialne za produkcje modeli,

•

zależności pomiędzy modelami.

Modelowanie wizualne pozwala na stosunkowo łatwe

znalezienie wielu rozwiązań problemów z zakresy TSI:



przypadki użycia i scenariusze określają funkcjonalność i
zachowanie systemu,



modele określają ściśle projekt systemu,



możliwość prezentowania rozwiązań o różnych stopniach
szczegółowości tego samego problemu,



łatwiejsze ujawnianie sprzeczności i niejednoznaczności
rozwiązań projektowych,

Jako narzędzia modelowania RUP używa UML.

17

GK (PSI(3) - 2009)

RUP – metodyka

– najlepsze

praktyki

Ciągłe monitorowanie jakości:



za jakość odpowiedzialna jest cała organizacja i właśnie jakość
powinna stanowić główne kryterium projektowe,



realizowanie polityki jakości nie jest jednym z etapów tworzenia
systemu – jest „sposobem życia zespołu projektowego”,



RUP identyfikuje dwa pojęcia jakości:

•

jakość produktu – jak produkt dopasowuje się do potrzeb
klienta,

•

jakość procesu – poziom „dojrzałości” organizacji.

Ciągłe monitorowanie jakości pozwala na:



obiektywizację oceny jakości z tego względu, że system nie jest
oceniany na podstawie dokumentacji a na podstawie wyników
testów, co pozwala na uwypuklanie ewentualnych niezgodności
pomiędzy wymaganiami, projektem i implementacją,



koncentrowanie testowania i weryfikacji na obszarach systemu
najbardziej zagrożonych,



wczesne wykrycie nieprawidłowości i ich usuwanie znacznie
obniża koszty wytworzenia systemu.

18

GK (PSI(3) - 2009)

RUP – metodyka

– najlepsze

praktyki

Oprogramowanie dostosowujące się do zmian.

Podstawową trudnością tworzenia złożonego systemu
jest to, że pracuje nad nim wielu różnych specjalistów
zebranych w wielu różnych, nieraz rozproszonych
zespołach, wykonujących wspólnie wiele czynności w
kolejnych iteracjach procesu TSI, korzystając z różnych
wersji rozwiązań, produktów i platform. Mając to na
uwadze metodyka RUP:



uwzględnia fakt, że system podlega ciągłym zmianom
oraz rozbudowie,



proponuje, żeby artefakty tworzone podczas całego
procesu były tworzone z pewnym „marginesem”,
pozwalającym na wprowadzanie zmian.

19

GK (PSI(3) - 2009)

RUP – metodyka

– najlepsze

praktyki

Dwie osie RUP:

oś pozioma

reprezentuje
czas i
przedstawia
dynamiczne
aspekty
procesu,

oś pionowa

reprezentuje
statyczne
aspekty
(zawartość)
procesu.

RUP - proces

20

GK (PSI(3) - 2009)

Proces tworzenia systemu podzielony jest na

cykle

. Cykl

obejmuje cztery etapy (fazy):



rozpoczęcie -

inception

,



opracowanie (rozwinięcie) -

elaboration

,



budowanie -

construction

,



przekształcanie (wdrażanie) -

transition

.

W ramach każdego etapu są możliwe

iteracje

. Iteracja jest

kompletną „pętlą” tworzenia pewnej części produktu.

Cechy RUP jako procesu:



cztery następujące po sobie etapy (fazy),



każda faza zakończona

kamieniami milowymi

,



na końcu każdej fazy następuje analiza jej produktów
celem sprawdzenia czy jej założenia zostały osiągnięte,



pozytywna ocena produktów fazy powoduje przejście do
następnej.

RUP - proces

21

GK (PSI(3) - 2009)

Celem

etapu

rozpoczęcia

jest:



ustalenie zakresu projektu oraz przypadków użycia z
punktu widzenia wizji klienta,



określenie uzupełniających danych do każdego przypadku
użycia, obejmujących: kryterium powodzenia, ocenę ryzyka,
szacowany koszt wytworzenia, plan wytworzenia z
zaznaczeniem kamieni milowych,



zidentyfikowanie wszystkich zewnętrznych bytów, z którymi
system powinien współpracować i określenie charakteru tej
współpracy.

Wynikiem tej fazy są :



główne wymagania dotyczące projektu i funkcjonalności
systemu oraz ograniczenia,



początkowy diagram przypadków użycia (zaawansowany w
10%-20%),



analiza ryzyka w projekcie,



plan projektu (ukazujący fazy i iteracje w czasie),



jeden lub więcej prototypów pozwalających na wychwycenie
tak zwanego „ryzyka technicznego” oraz pozostałych
wymagań na system.

RUP – etapy (fazy) procesu

-

rozpoczęcie

22

GK (PSI(3) - 2009)

Celem

etapu opracowania (rozwinięcia)

jest

opracowanie:



szczegółowej analizy problemu,



architektury zgodnej z charakterem tworzonego systemu,



utworzenie planu projektu,



zasad i metod ninimalizacji ryzyka.

Wynikiem tej fazy są :



diagram przypadków użycia z dokładnym opisem oraz
przypisaniem aktorów (powinien być ukończony w 80%),



zestaw wymagań niefunkcjonalnych,



opis architektury systemu,



dokładna analiza ryzyka,



zaktualizowany dokument wizji biznesowej,



wszystkie niezbędne plany projektowe w tym plan
implementacji dla całego projektu,



wstępna wersja podręcznika użytkownika (opcja).

RUP – etapy (fazy) procesu

-

opracowanie

23

GK (PSI(3) - 2009)

Celem

etapu budowania

jest:



budowa elementów systemu,



integracja elementów systemu,



testowanie systemu.

Wynikiem tej fazy są :



produkt zintegrowany z platformą docelową, gotowy do
przekazania użytkownikowi,



podręcznik użytkownika.

Zarządzanie zasobami oraz kontrola działań jest kluczowa

podczas tej fazy w celu optymalizacji planów, kosztów oraz
jakości projektu.

Celem

etapu wdrażania

jest przekazanie produktu

(wersji systemu) użytkownikowi.
Wynikiem tej fazy jest funkcjonująca wersja systemu.

RUP – etapy (fazy) procesu

–

budowanie i wdrażanie

24

GK (PSI(3) - 2009)

RUP – etapy (fazy) procesu

–

iteracje

i kamienie milowe

25

GK (PSI(3) - 2009)

Iteracja

jest pętlą projektową, która kończy się

wypuszczeniem funkcjonujących elementów projektowych,
stanowiących podzbiór kompletnego produktu. Podzbiór ten z
każdą zakończoną iteracją będzie się zbliżał rozmiarami do
finalnych oczekiwań. Iteracje i kamienie milowe:

Zaletami podejścia iteracyjnego są:



ryzyka mogą być szybciej wychwycone,



łatwiej można wprowadzać modyfikacje,



zespół projektowy można szkolić już po rozpoczęciu projektu,



całkowita jakość produktu jest znacznie wyższa niż przy
realizacji analogicznego produktu według modelu
kaskadowego.

26

GK (PSI(3) - 2009)

Do zarządzania realizacją procesu TSI niezbędna jest

możliwość oceniania postępu prac projektowych. Skuteczność
kierowania tymi pracami wymaga też określenia kryteriów
oceny oraz czasu (punktów kontrolnych) jej przeprowadzania.
Takie punkty kontrolne noszą nazwę

kamieni milowych

i

wskazują miejsca zwrotne, w których – po ocenieniu
uzyskanych wyników mogą zapaść decyzje dotyczące
kontynuacji, bądź zmiany kierunku prac. Wyróżnia się

kamienie milowe zewnętrzne

zamykające każdy etap (fazę)

procesy projektowania i

kamienie milowe wewnętrzne

–

kończące iteracje wewnątrz etapu procesu projektowania.
Kamienie milowe

zewnętrzne

:

1.Etap rozpoczęcia

–

zbadanie celów przedsięwzięcia

(kryteria

oceny):

•

zgodność głównych uczestników procesu projektowania co do

zakresu stosowanych pojęć oraz wiarygodności oszacowania
kosztów i czasu tworzenia systemu,

•

zgodność głównych uczestników procesu tworzenia systemu

co do interpretacji przypadków użycia, definiujących
funkcjonalność systemu,

•

wiarygodność oszacowania harmonogramu realizacji procesu

tworzenia systemu oraz jego zagrożeń,

RUP – etapy (fazy) procesu

–

iteracje

i kamienie milowe

27

GK (PSI(3) - 2009)

•

zakres przedmiotowy i funkcjonalny opracowywanych
prototypów architektury,

•

ocena rozbieżności pomiędzy nakładami planowanymi, a
poniesionymi już dotychczas i czy ewentualne
rozbieżności są do zaakceptowania.

2. Etap opracowania

–

opracowanie architektury

(pytania

związane z kryteriami oceny):

•

czy wizja systemu jest niezmienna?

•

czy architektura systemu jest stabilna?

•

czy analiza opracowanego prototypu umożliwiła
identyfikację głównych zagrożeń procesu projektowania i
czy podjęto stosownie do nich właściwe działania?

•

czy następny etap, tj. etap budowy systemu (prototypu
systemu) został szczegółowo zaplanowany i zostały
oszacowane koszty oraz czas jego realizacji?

•

czy wszyscy uczestnicy procesu projektowania systemu są
zgodni co do tego, że obecny prototyp systemu jest
możliwy do zrealizowania i że ta realizacja może być
oparta na istniejącej architekturze?

•

czy występują rozbieżności między planowanym a
rzeczywistym zużyciem zasobów i czy te rozbieżności są
do zaakceptowania?

RUP – etapy (fazy) procesu

–

iteracje

i kamienie milowe

28

GK (PSI(3) - 2009)

3. Etap budowy

–

zapewnienie funkcjonowania początkowej

wersji systemu

(pytania związane z kryteriami oceny):

•

czy przygotowana wersja systemu jest na tyle dobrze
przygotowana, że może być przekazana użytkownikowi?

•

czy wszyscy uczestnicy procesu projektowania są
przygotowani do rozpoczęcia procesu przekazywania?

•

czy występują rozbieżności między planowanym a
rzeczywistym zużyciem zasobów i czy te rozbieżności są do
zaakceptowania?

4. Etap wdrażania

–

udostępnienie produktu

(pytania związane

z kryteriami oceny):

•

czy użytkownik jest zadowolony?

•

czy występują rozbieżności między planowanym a
rzeczywistym zużyciem zasobów i czy te rozbieżności są do
zaakceptowania?

RUP – etapy (fazy) procesu

–

iteracje

i kamienie milowe

Dziedziny

(dyscypliny) RUP obejmują:

• Modelowanie biznesowe,
• Wymagania,
• Analizę i projektowanie,
• Implementację,
• Testowanie,
• Wdrażanie,
• Zarządzanie konfiguracją i zmianami,
• Zarządzanie projektami,
• Środowisko.

RUP – dziedziny (dyscypliny)

procesu

29

GK (PSI(3) - 2009)

Celem

Modelowania Biznesowego

jest:



zrozumienie bieżących problemów organizacji i

ocena możliwości ulepszenia zidentyfikowanych w

niej procesów biznesowych,



ocena wpływu wdrożenia tworzonego systemu

informatycznego na zmiany w organizacji,



uzyskanie pewności, że klienci, użytkownicy i inni

uczestnicy procesu tworzenia systemu

informatycznego jednakowo rozumieją organizację

pod kątem zachodzących w niej procesów

biznesowych,



określenie wymagań do tworzonego systemu,

niezbędnego dla wsparcia procesów biznesowych

organizacji.

RUP – dziedziny

– modelowanie

biznesowe

30

GK (PSI(3) - 2009)

Celem

Wymagań

jest:



specyfikacja ograniczeń projektu,



specyfikacja wymagań funkcjonalnych systemu,



uszczegółowienie scenariuszy przypadków użycia,



specyfikacja wymagań niefunkcjonalnych:

niezawodność, rozszerzalność, bezpieczeństwo itp.,



ustalenia kosztów i określenie czasu wytworzenia

systemu,



specyfikacja interfejs użytkownika.

RUP – dziedziny

– wymagania

31

GK (PSI(3) - 2009)

Celem

Analizy i projektowania

jest zamiana wymagań w

specyfikację implementacji systemu, tj.:



określenie stabilnej architektury systemu,



przystosowanie projektu systemu do środowiska, w którym zostanie

zaimplementowany system,



uwzględnienie własności systemu.

Analiza

to transformacja wymagań do modeli obiektów, dynamiki i

funkcjonalnego na podstawie przypadków użycia i wymagań

funkcjonalnych.

Wynikiem jest model „idealnego” systemu bez uwzględnienia

ograniczeń środowiska implementacji i wymagań niefunkcjonalnych

RUP – dziedziny

– analiza i

projektowanie

Analiza nie zajmuje się zmianą rzeczywistości poprzez
wprowadzenie do niej nowych elementów np. w postaci
systemu informatycznego; jej celem jest dokładne rozpoznanie
wszystkich tych aspektów danej rzeczywistości, które mogłyby
mieć wpływ na postać, organizację lub wynik projektu, tj. na
szeroko rozumiany kształt systemu. Analiza nie powinna
odwoływać się do jakichkolwiek aspektów implementacyjnych.

32

GK (PSI(3) - 2009)

Analiza

- kombinacja technik, notacji i wzorców postępowania

posiadająca następujące cechy:



wyróżnianie w rzeczywistości będącej przedmiotem systemu

informatycznego bytów o określonych granicach, zwanych
“obiektami”,



grupowanie obiektów w klasy,



ustalenie zależności pomiędzy klasami w postaci hierarchii

dziedziczenia,



przypisanie do klas atrybutów obiektów i powiązań

asocjacyjnych obiektów,



przypisanie do klas metod, tj. operacji, funkcji lub procedur

działających na obiektach tych klas.

Techniki:

Modelowanie obiektów i klas, modelowanie zachowania,
modelowanie dynamiki, modelowanie przepływu danych, ...

Notacje:

Konkretna składnia i semantyka służąca do
zapisu modelu:
diagramy obiektów i klas, diagramy dynamiczne,
diagramy przepływu danych (UML).

RUP – dziedziny

– analiza i

projektowanie

33

GK (PSI(3) - 2009)

PROJEKTOWAN
IE

Użytkow
nicy

Tworzenie

wymagań

Projekta
nci

Kierownic
two

Sformułow
anie
wymagań

Budowa

modeli

• Wywiady z

użytkownik
ami

• Wiedza

dotycząca
dziedziny
problemow
ej

• Doświadcz

enie
projektowe

Modele:

• obiektów

• dynamiki

• funkcjonal

ny

RUP – dziedziny

– analiza i

projektowanie

34

GK (PSI(3) - 2009)

Projektowanie

to:



przystosowanie wyników analizy do wymagań

niefunkcjonalnych i ograniczeń środowiska
implementacji,



optymalizacja systemu,



pełne uwzględnienie funkcjonalności.

Projekt zawiera wiele elementów implementacyjnych
odnoszących się do struktury obiektowej oraz
algorytmów (metod) przetwarzania potrzebnych do
implementacji klas.

Wynikowy system jest organizowany w podsystemy

na podstawie wyników analizy jak i założeń co do ogólnej
architektury. Projektant musi podjąć decyzje dotyczące
optymalizacji charakterystyk wydajnościowych, wybrać
strategię rozwiązania tego problemu oraz podjąć decyzje
odnośnie alokacji zasobów. Np. projektant musi określić
charakterystyki monitorów (rozdzielczość, rozmiar
ekranu, kolory), musi wybrać konfigurację sprzętu,
strategię buforowania pamięci, właściwe protokóły
komunikacyjne, itd.

RUP – dziedziny

– analiza i

projektowanie

35

GK (PSI(3) - 2009)

Celem

Implementacji

jest wytworzenie

działającego systemu na podstawie modelu z dyscypliny
projektowania. Implementacja

to etap, w którym obiekty

i klasy wyodrębnione podczas projektowania są
ostatecznie odwzorowane w postaci konstrukcji języka
programowania (najlepiej obiektowego), bazy danych,
oraz konfiguracji sprzętowej.

Zakłada się, że etap programowania powinien być

mniej ważną, w zasadzie pół-automatyczną czynnością,
która nie wypacza jakichkolwiek elementów projektu.
Wszelkie trudne decyzje dotyczące implementacji muszą
być podjęte i udokumentowane na etapie projektu. To
założenie jest szczególnie ważne dla dużych projektów,
gdy pojedynczy programista nie ma możliwości
ogarnięcia jego całościowej logiki.

Odwzorowanie projektu w implementację powinno

być takie, aby każdy fragment oprogramowania mógł
być jednoznacznie przyporządkowany odpowiedniemu
fragmentowi projektu.

RUP – dziedziny

–

implementacja

36

GK (PSI(3) - 2009)

Celem dziedziny

Testy

jest:



sprawdzenie zgodności funkcjonalności systemu z
wymaganiami,



sprawdzenie stabilności działania systemu,



wykrycie i usunięcie błędów,



ocena niezawodności systemu,



ocena bezpieczeństwa systemu.

Na testowanie składają się następujące aktywności:



przygotowanie planu testów,



projektowanie i implementacja testów,



wykonanie testów integracyjnych oraz testów systemowych,



analiza wyników testów.

RUP – dziedziny

– testy

37

GK (PSI(3) - 2009)

Celem

Wdrażania

jest wytworzenie i dostarczenie

oprogramowania, bazy danych i innych elementów systemu
użytkownikowi.
Aktywności dotyczące wdrażania:



fizyczne wytworzenie wersji instalacyjnej oprogramowania i baz

danych,



przygotowanie elementów systemu do dystrybucji i ich dystrybucja,



instalacja systemu,



utworzenie dokumentacji i pomocy dla użytkowników

.

RUP – dziedziny

– wdrażanie

38

GK (PSI(3) - 2009)

Celem

Zarządzania konfiguracją i zmianami

jest:



utrzymanie spójności projektu, tj.:

•

identyfikacja elementów projektu,

•

określenie dostępu do elementów projektu (wprowadza

możliwość śledzenia dlaczego, kiedy i przez kogo dany

artefakt został zmieniony),

•

składowanie, struktura katalogów,

•

udostępnienie stabilnego środowiska, w którym

produkt będzie rozwijany,

•

wprowadzenie zabezpieczeń przed szkodliwymi

zmianami,



kontrola zmian:

•

audyt zmian, stany zgłoszeń,

•

wybór wersji,

•

unikanie konfliktów wersji.

RUP – dziedziny

– zarządzanie

konfiguracją i zmianami

39

GK (PSI(3) - 2009)

Główne cele

Zarządzania projektami

:



dostarczenie wskazówek wspomagających planowanie prac,



organizowanie zespołów,



dostarczenie szablonów.

RUP nie rozwiązuje w pełni problemu zarządzania

projektami.

RUP – dziedziny

– zarządzanie

projektami

40

GK (PSI(3) - 2009)

Celem dziedziny

Środowisko

jest:

• wybór i dostarczenie narzędzi do tworzenia

systemu,

• określenie środowiska systemowego dla

tworzonego systemu.

RUP – dziedziny

– środowisko

41

GK (PSI(3) - 2009)

• Rational SoDA

– automatyzuje tworzenie

dokumentacji dla całego procesu znacząco redukując
czas i koszty dokumentowania.

• Rational ClearCase

– narzędzie zarządzania

konfiguracją, umożliwiające śledzenie ewolucji
projektu.

• Rational TeamTest

– tworzy, utrzymuje i wykonuje

automatyczne testy funkcjonalne, umożliwiając
gruntowne przetestowanie kodu i określenie czy
oprogramowanie spełnia założone wymagania
funkcjonalne.

RUP – narzędzia

42

GK (PSI(3) - 2009)