UML

Metodyki projektowe

• Proces kaskadowy

• Procesy interakcyjne

- UP

• Rational Unified Process

• Open Unified Process (Eclipse OpenUP)

- Agile – techniki zwinne

• UP – w fofmie uproszczonej (np. OpenUP)

• Scrum

• Kanban

• XP – eXtreme Programming

Charakterystyka metod zwinnych

• Charakterystyka metod zwinnych została przedstawiona w Agile Manifesto (Manifest zwinnego wytwarzania oprogramowania)

• Główne jego założenia to stawianie:

- Ludzi i komunikacji przed procesami i narzędziami

- Działającego oprogramowania przed wyczerpującą dokumentacją – przecież nie można oddać na koniec projektu tylko i wyłącznie, nawet najlepiej, przygotowanej dokumentacji

- Współpracę z klientem przed uzgodnieniem umowy – początkowe wymagania mogą się zmieniać, co więcej nie wszystkie mogą zostać ujawnione. Zaangażowanie klienta jest więc konieczne przez cały czas trwania projektu

- Elastyczne podejście do zmian przed sztywnym planem – szybka reakcja na zmiany projektowe

Założenia technik zwinnych

• Satysfakcja klienta poprzez szybkie i okresowe dostarczanie działającego oprogramowania

• Wprowadzanie zmian, nawet w końcowych fazach budowy oprogramowania

• Działające oprogramowanie jest główną miarą postępów

• Utrzymywanie stałego tempa budowy oprogramowania

• Codzienna i bliska współpraca deweloperów z ludźmi z biznesu

• Bezpośredni kontakt jako najlepsza forma komunikacji

• Nastawienie się na aspekty techniczne i dobry projekt

• Prostota rozwiązania

• Adaptacja do zmieniających się wymagań

Ogólny proces tworzenia oprogramowania w UP

Major Milestones
Inception	Elaboration	Construction	Transition
▬▬▬▬▬▬▬▬▬▬▬▬▬▬TIME▬▬▬▬▬▬▬▬▬▬▬▬▬▬►

• Inception: Zrozum co będziesz budował

- wizja, wysokopoziomowe wymagania, przypadek biznesowy

• Elaboration: Wymyśl jak to zbudujesz

- Bazowa architektura, szczegółowe wymagania, projekt ogólny

• Construction: Zbuduj oprogramowanie

- Działające i przetestowane oprogramowanie

• Transition: Wdróż oprogramowanie użytkownikom

- Zatwierdzenie wykonania projektu przez udziałowców

Dlaczego UML

• Graficzna forma komunikacji – jeden rysunek jest więcej wart niż 1000 słów

• Jest to notacja, która jest zrozumiała przez wszystkich:

- Usuwa większość problemów z prawidłowym zrozumieniem problemu

- Pozwala uchwycić zarówno strukturę jak i zachowanie

- Pokazuje związki pomiędzy poszczególnymi elementami oprogramowania

- Pozwala utrzymać projekt i implementację w spójny sposób

- Ukrywa bądź ujawnia szczegóły w zależności od potrzeb

• UML stosuje się praktycznie w każdej z faz budowy oprogramowania

Diagramy w UML

Charakterystyka diagramów – statyczne

Za pomocą UML można przedstawić ten sam problem z kilku różnych perspektyw. UML dostarcza notacji pozwalającej na stworzenie diagramów:

• Przypadków użycia (Use-Case) do zilustrowania interakcji pomiędzy użytkownikami i systemami oraz ich odpowiedzialności

• Klas (Class) do pokazania logicznej struktury programu

• Pakietów (Package) – uchwycenie struktury pakietów

• Obiektów (Object) do pokazania obiektów i powiązań między nimi

• Komponentów (Components) do zapisania fizycznej struktury programu

• Wdrożeniowych (Deployment) do pokazania powiązania między oprogramowaniem i sprzętem

Charakterystyka diagramów – dynamiczne

• Przypadków użycia

• Czynności (Activity) do pokazania przepływu zdarzeń między elementami oprogramowania

• Stany (Statechart) do opisu zachowań (np. można projektować protokoły komunikacyjne jako maszyny stanowe)

• Interakcji (Interaction) do szczegółowego opisu zachowania:

- Sekwencji (Sequence) opis sekwencji operacji

- Komunikacji (communication)

Korzystając z poszczególnych diagramów jesteśmy w stanie w prosty sposób uchwycić wymagania dla budowanego oprogramowania. Zarówno te najbardziej ogólne jak i szczegółowe.