Procesy wytwarzania oprogramowaniaSpecyfikacja i projektowanie oprogramowania

dr inż. Marcin Szlenk

Politechnika Warszawska

Wydział Elektroniki i Technik Informacyjnych

2

Wprowadzenie

O mnie

dr inż. Marcin Szlenk

Instytut Automatyki i Informatyki Stosowanej, pok. 555

www.ia.pw.edu.pl/~mszlenk

m.szlenk@ia.pw.edu.pl

O wykładzie

Procesy konstrukcji systemów informatycznych:

kaskadowy, V, konstrukcji prototypów, przyrostowy,

iteracyjny, spiralny, transformacji formalnych

Model Driven Architecture (MDA) a

Domain Specific Modeling (DSM)

3

Kategorie projektów informatycznych

Kastomizacja oprogramowania wdrożeniowego =

(mały) projekt konstrukcyjny

Zapotrzebowanie

Czy na rynku dostępne są

zadowalające nas rozwiązania COTS ?

Projekt wdrożeniowy Projekt konstrukcyjny

Tak Nie

4

Proces wytwórczy systemu

Proces wytwórczy systemu

Zbiór czynności i związanych z nimi wyników, które prowadzą do

powstania systemu

Czynności wspólne dla wszystkich procesów:

Projektowanie

Analiza wymagań

Implementacja

Testowanie

Wdrożenie i pielęgnacja

5

Analiza wymagań

Zebranie i uporządkowanie wymagań użytkownika oraz

określenie, co system będzie robił by je spełnić

Projektowanie

Odwzorowanie wymagań w konstrukcję systemu, czyli

określenie jak system będzie zrealizowany

Implementacja

Zbudowanie działającego systemu

Testowanie

Sprawdzanie poprawności działania i usuwanie błędów

Wdrożenie i pielęgnacja

Instalacja oprogramowania i dalsze utrzymanie

Dobranie architektury,

struktury oprogramowania,

środowiska implementacji

Usuwanie błędów,

wprowadzanie zmian

Wymagania systemowe

6

Wymagania użytkownika i systemowe

Wymaganie użytkownika

1. Oprogramowanie musi zapewnić mechanizmy reprezentowania

i dostępu do plików zewnętrznych tworzonych przez inne

narzędzia

Wymaganie systemowe

1. Użytkownik powinien mieć możliwość definiowania typów plików

zewnętrznych

2. Każdemu typowi pliku zewnętrznego użytkownik może

przypisać narzędzie do obróbki takich plików

3. Każdy typ pliku zewnętrznego powinien być przedstawiony na

ekranie w postaci charakterystycznej ikony

4. Gdy użytkownik wybierze ikonę powiązaną z plikiem

zewnętrznym następuje uruchomienie narzędzia przypisanego

tego typu plikom

Ian Sommerville: Inżynieria oprogramowania, WNT (2003)

7

Wymagania funkcjonalne i pozafunkcjonalne

Wymagania funkcjonalne

Usługi lub funkcje wymagane od systemu

Wymagania pozafunkcjonalne

Ograniczenia jakim ma podlegać tworzenie i działanie systemu:

• niezawodność

• wydajność

• pielęgnowalność

• przenośność

• bezpieczeństwo

8

Studium wykonalności Czy?

Ustalenie możliwości realizacji przedsięwzięcia i

podjęcie decyzji o realizacji dalszych prac

1. Czy system jest w ogóle potrzebny?

2. Czy system da się zrealizować przy użyciu dostępnych

technologii?

3. Czy system jest ekonomicznie opłacalny?

4. Czy system da się zrealizować w ramach ustalonego budżetu i

ograniczeń czasowych?

5. Czy system da się zintegrować z istniejącymi systemami?

Na podstawie

ogólnej analizy

9

Modele procesów wytwórczych

Model procesu wytwórczego

= abstrakcja przebiegu wytwarzania systemu informatycznego

Kluczowe modele:

Model kaskadowy

Model V

Prototypowanie (model konstrukcji prototypów)

Model przyrostowy

Model iteracyjny

Model spiralny

Transformacje formalne

10

Model kaskadowy

Interpretacja ścisła

Fazy nie nakładają się na siebie

Interpretacja ogólna

Sąsiednie fazy nakładają się w czasie, ale w minimalnym stopniu

Projektowanie

Analiza wymagań

Implementacja

Testowanie

Wdrożenie i pielęgnacja

Przejście do fazy n+1

wymaga zakończenia fazy n

Na początku fazy n+1 można

dokonać zmian w fazie n

11

Zalety

naturalność i zrozumiałość

ułatwia planowanie, harmonogramowanie i śledzenie postępów

projektu

Wady

utrudnia reagowanie na:

• zmieniające się wymagania użytkownika

• błędy wymagające cofnięcia się do faz zakończonych

do końca projektu utrzymuje się wysokie ryzyko, że system nie

spełni wymagań użytkownika

wysoki koszt błędów popełnionych w fazie analizy

Sprawdza się w niewielkich projektach o łatwych do określenia i

stabilnych wymaganiach co do systemu

12

Model V

Q – czynności weryfikujące jakość wykonanych prac

Odmiana modelu kaskadowego (fazy wykonywane

sekwencyjnie)

Faza zostaje zamknięta po pozytywnej ocenie jakości

Testy opracowuje się równolegle do prac analitycznych i

projektowych

Analiza wymagań

Projektowanie

Implementacja

Testowanie

weryfikacyjne

Testowanie

walidacyjne

Q

QQ

Q

13

Kilka uwag na temat testowania

Weryfikacja

Czy budujemy system we właściwy sposób?

(Czy system działa poprawnie?)

Walidacja

Czy budujemy właściwy system?

(Czy system realizuje wymagania użytkownika?)

Podstawowe rodzaje testów:

testy jednostkowe

testy integracyjne

testy systemowe

testy akceptacyjne

Wymagania funkcjonalne i

pozafunkcjonalne

Podstawa odbioru

14

Zalety

obniżone ryzyko popełnienia błędów i konieczności nawrotów

dzięki ciągłej kontroli jakości

zapewnienie wysokiej jakości systemu (obniżenie kosztów

dalszego utrzymania)

Wady

narzuty dodatkowej pracy, czasu i kosztu realizacji

silnie rozbudowana dokumentacja

utrudniona adaptacja do zmiennych wymagań lub warunków

prowadzenia projektu (jak w modelu kaskadowym)

15

Prototypowanie

Prototyp systemu

Uproszczenie docelowego systemu, konstruowane przy

względnie niedużym nakładzie środków i czasu

Wstępna analiza wymagań

Konstrukcja prototypu

Weryfikacja prototypu

Określenie wymagań i konstrukcja

właściwego systemu

(model kaskadowy)

16

Zalety

minimalizacja ryzyka błędnego określenia wymagań

Wady

dodatkowy koszt związany z konstrukcją prototypu

problemy z dokonywaniem nawrotów do faz wcześniejszych jak

w modelu kaskadowym

Odmianą prototypowania jest programowanie odkrywcze

17

Model przyrostowy

Podział systemu na mniejsze fragmenty i ich sukcesywna

realizacja

Czynności dotyczące odrębnych fragmentów mogą być

wykonywane równolegle

Projektowanie

Analiza wymagań

Implementacja Projektowanie

Analiza wymagań

Implementacjafragment 1

fragment 2

...

...

Czas

18

Zalety

lepszy kontakt z przyszłym użytkownikiem

możliwość bardziej elastycznego reagowania na opóźnienia

Wady

nie zawsze możliwe rozbicie systemu na niezależne fragmenty

możliwe kłopoty z późniejszą integracją fragmentów

dodatkowe koszty tworzenia atrap brakujących fragmentów

19

Model iteracyjny

Stopniowe dochodzenie do pożądanego rozwiązania

Iteracje względnie krótkie

Zazwyczaj w połączeniu z podejściem przyrostowym

...

Projektowanie

Analiza wymagań

Implementacja

Testowanie

Projektowanie

Analiza wymagań

Implementacja

Testowanie

iteracja 1 iteracja 2

Czas

20

Zalety

mniejsze ryzyko, że końcowy system nie spełni wymagań

użytkownika

łatwiejsza adaptacja do zmian w wymaganiach lub w przyjętych

założeniach projektowych

Wady

problem z zaplanowaniem procesu (określenie potrzebnej liczby

iteracji i harmonogramu prac)

większa czasochłonność (osiągniecie docelowej wersji systemu

bardziej rozłożone w czasie)

21

Model spiralny

Bardzo ogólny model (Boehm 1988)

Nacisk na analizę i redukcję ryzyka

Pasuje do procesu tworzenia oprogramowania rynkowego

Analiza ryzyka

KonstrukcjaAtestowanie

Planowanie

22

Planowanie

Określenie celów, alternatyw i ograniczeń

Analiza ryzyka

Ocena możliwych rozwiązań oraz identyfikacja i oszacowanie

ryzyka dla każdego z nich

Konstrukcja

Konstrukcja kolejnego przybliżenia systemu zgodnie z modelem

kaskadowym

Atestowanie

Ocena przez klienta powstałej wersji systemu

ocena negatywna → kolejny cykl

23

Transformacje formalne

Propozycja teoretyczna

Trudności specyfikowania i dowodzenia

Specyfikacja wymagań

w języku formalnym

Kod

Postać pośrednia

Postać pośrednia

…

Dowód poprawności

Dowód poprawności

Bezbłędny !

24

Model Driven Architecture (MDA)

Proces wytwórczy polega na transformacji jednego modelu w

inny i na końcu w kod

Proces iteracyjno-przyrostowy – transformacje mogą być

wykonywane wiele razy (najlepiej automatycznie)

PIM

CIM

PSM

Kod

iteracje

Model biznesowy

(computation independent)

Model niezależny od

platformy (platform

independent)

Model zależny od

platformy (platform

specific)

Zapisanego w języku UML

(Unified Modeling Language)

25

Dwa słowa o UML ...

Diagram

przypadków użyciaDiagram klas

Diagram stanów

Diagram wdrożenia

Diagram komponentów

Diagram sekwencji

Zalety

praca skupia się na abstrakcyjnych modelach (głównie PIM), co

uniezależnia od platformy

możliwość ponownego użycia fragmentów modelu PIM

automatyzacja zmniejsza ryzyko popełnienia błędów i

przyśpiesza proces tworzenia

Wady

transformacje są zadaniem trudnym i obecnie tylko nieznacznie

wspieranym przez narzędzia

problem zastosowania w przypadku rozwoju już istniejących

systemów (odtworzenie modelu PIM na podstawie PSM)

26

Domain Specific Modeling (DSM)

Model systemu jest zapisywany w dedykowanym języku

(Domain Specific Modeling Language) – język specyficzny dla

danej dziedziny problemu

Wchodzący w skład języka generator kodu przekształca model w

kod całkowicie automatycznie

27

PIM

CIM

PSM

Kod

iteracje

Model dziedzinowy

Kod

Wymagania użytkownika

Wymagania użytkownika

Modele zapisane

w UML

Model zapisany w

języku dziedzinowym

28Źródło: www.metacase.com

Zalety

Modelowanie oprogramowania przy użyciu pojęć z dziedziny

(intuicyjny język modelowania)

Możliwość szybkiego generowania kodu wysokiej jakości

Przydatność w przypadku tzw. linii produktowych (software

product line)

Wady

Konieczność opracowania języka dziedzinowego i generatora

kodu

Wymagane duże umiejętności projektanta języka

Sprawdza się w przypadku gdy opracowany język będzie

wykorzystywany wielokrotnie (np. różne wersje oprogramowanie

urządzeń mobilnych)

29

30

Literatura

Mariusz Flasiński, Zarządzanie projektami informatycznymi,

Wydawnictwo Naukowe PWN (2006)

Ian Sommerville, Inżynieria oprogramowania, WNT (2003)

Andrzej Jaszkiewicz, Inżynieria oprogramowania, Wydawnictwo

HELION (1997)

Stanisław Szejko, Metody wytwarzania oprogramowania,

Wydawnictwo MIKOM (2002)

Alan Monnox, J2EE: Podstawy programowania aplikacji

korporacyjnych, HELION (2006)

Steven Kelly, Juha-Pekka Tolvanen, Domain-Specific Modeling:

Enabling Full Code Generation, Wiley-Interscience (2008)