Języki i metodyka oprogramowania

Języki i metodyka
oprogramowania
Automatyka i Robotyka sem.2 (część I)
Rok akademicki 2010/2011
Dr inż. Wojciech Koziński
Literatura
A. Januszkiewicz. Inżynieria oprogramowania. Helion
1997.
W. Dąbrowski, A. Stasiak, M. Wolski. Modelowanie
systemów informatycznych w języku UML2.1. PWN
S.A. 2007.
G. Booch, J.Rumbaugh, I.Jacobson. UML przewodnik
użytkownika. WNT 2001, 2002. (Seria: inżynieria
oprogramowania).
F. P. Brooks: The Mythical Man-Month. Addison
Wesley Publishing Company. 1995 (Anniversary
Addition) (jest polskie tłumaczenie).
J. Hunt. The Unified Process for Practitioners. Object
Oriented Design, UML and Java. Springer, 2000.





JIMO 2010/2011
2
Kariera zawodowa

Kariera zawodowa w informatyce:




Programista (tester),
Projektant (projektant testów),
Analityk.
Kierownik (osoba zarządzająca):


Zadaniem,
Projektem (coraz większym).
JIMO 2010/2011
3
1
Inżynieria oprogramowania a dobre
oprogramowanie


Inżynieria oprogramowania jako nauka
praktyczna mówiąca o sposobie (metodyce)
tworzenia dobrego oprogramowania.
Cechy dobrego oprogramowania:





Zgodne z wymaganiami użytkownika,
Niezawodne,
Efektywne,
Łatwe w konserwacji,
Ergonomiczne.
JIMO 2010/2011
4
Dobre oprogramowanie

Dlaczego jest trudno zrobić dobre oprogramowanie?




Duża złożoność systemów informatycznych.
Niepowtarzalność poszczególnych przedsięwzięć.
Nieprzejrzystość procesu budowy oprogramowania
(trudność w ocenie stopnia zaawansowania prac). Co to
znaczy, że prace są zaawansowane w 90%? Jak mierzyć
postęp w realizacji przedsięwzięcia?
Pozorna łatwość wytwarzania produktu i dokonywania
poprawek (1 dzień – 100 linii, 10 dni – 1000 linii, 100 dni –
10.000 linii, 10 osób razy 100 dni – 100.000 linii).
JIMO 2010/2011
5
Inżynieria oprogramowania

Inżynieria oprogramowania opisuje między innymi:
 Sposoby prowadzenia przedsięwzięć informatycznych,
 Techniki planowania, szacowania kosztów, harmonogramowania
i monitorowania przedsięwzięć informatycznych,
 Metody analizy i projektowania systemów,
 Techniki zwiększania niezawodności oprogramowania,
 Sposoby testowania systemów i szacowania niezawodności,
 Sposoby przygotowania dokumentacji technicznej i użytkowej,
 Procedury kontroli jakości,
 Metody redukcji kosztów konserwacji (usuwania błędów,
modyfikacji i rozszerzeń),
 Techniki pracy zespołowej i czynniki psychologiczne wpływające
na efektywność pracy.
JIMO 2010/2011
6
2
Modele cyklu życia oprogramowania







Model kaskadowy,
Realizacja sterowana dokumentami (ang.
document driven).
Prototypowanie,
Programowanie odkrywcze,
Realizacja przyrostowa,
Montaż z gotowych elementów,
Model spiralny.
JIMO 2010/2011
7
Cykl życia oprogramowania (fazy)
Model wodospadowy









Strategia,
Określenie wymagań.
Analiza (modelowanie).
Projektowanie.
Implementacja.
Dokumentacja (produkcyjna,
użytkownika).
Testowanie.
Instalacja, szkolenie.
Konserwacja
oprogramowania.
JIMO 2010/2011
8
Narzędzia wspomagające

Narzędzia wspomagające tworzenie
oprogramowania – (narzędzia CASE):




Do zarządzania całym cyklem życia (OracleCASE, RUP IBM).
Do analizy i projektowania z wykorzystaniem UML,
(Posejdon, wtyczki do NetBeans, Eclipse).
Do kodowania, uruchamiania, testowania (Eclipse,
NetBeans, JBuilder).
Rozwój graficznych metod tworzenia
oprogramowania, aż do pełnej generacji kodu.
JIMO 2010/2011
9
3
Podstawowe wiadomości o UML
(Unified Modelling Language)


Diagramy (rysunki) tworzące model systemu.
Do diagramów konieczne są definicje, opisy,
słowniki. Zespół diagramów daje całkowity
opis systemu (miejmy nadzieję).
UML jest językiem przeznaczonym do:




Wizualizacji,
Specyfikacji,
Opisu,
Dokumentacji oprogramowania.
JIMO 2010/2011
10
UML – podstawowe diagramy









Diagram przypadków użycia (ang. use case
diagram),
Diagram klas (ang. class diagram),
Diagram obiektów (ang. object diagram),
Diagram działania (ang. activity diagram),
Diagram sekwencji (ang. sequence diagram),
Diagram współpracy (ang. collaboration diagram),
Diagram przejść stanów (ang. state charts),
Diagram składowych (ang. component diagram)
Diagram rozmieszczenia (ang. deployment
diagram).
JIMO 2010/2011
11
Tradycyjny sposób tworzenia
oprogramowania



Projekt przebiega według modelu
wodospadowego, w kolejności wykonując
wymagania, analizę, projekt, implementację,
a następnie utrzymując system.
Projekt ma tylko jeden cykl.
Projekt ma tylko jedną iterację w jednym
kroku (przykładowo – w analizie).
JIMO 2010/2011
12
4
Wada tradycyjnego sposobu wytwarzania
oprogramowania


Podstawowym problemem (wadą) modelu
kaskadowego (wodospadowego) jest to, że
wymagania są analizowane raz, powinny być
więc dobrze zdefiniowane na początku.
W takim procesie nie ma miejsca na zmiany
w wymaganiach, czyli odbiorca może
otrzymać produkt niedostosowany do
zmienionych (w czasie budowy systemu)
warunków.
JIMO 2010/2011
13
Podstawowe wiadomości o
Rational Unified Process (RUP).








Hierarchiczna struktura RUP
Cykle (ang. Cycles)
Fazy (ang. Phases)
Iteracje (ang. Iterations)
Prace (ang. Workflows)
Czynności (ang. Activities)
Cztery fazy RUP
Inception -> Elaboration -> Construction -> Transition
JIMO 2010/2011
14
Rational Unified Process (RUP)




Inception - Definiuje zakres projektu i cel tego
przedsięwzięcia w terminach biznesowych. Określa
możliwość wykonania projektu (ang. feasibility).
Elaboration - Opisuje i analizuje wymagania
funkcjonalne, specyfikuje wymagania
niefunkcjonalne, ustala podstawową architekturę
systemu.
Construction - Wytworzenie produktu (systemu).
Transition - Przeniesienie produktu do środowiska
produkcyjnego.
JIMO 2010/2011
15
5
Rational Unified Process (RUP)
JIMO 2010/2011
16
Rational Unified Process (RUP)
JIMO 2010/2011
17
Rational Unified Process (RUP)
Inception (olśnienie, pomysł).
Faza ta koncentruje się na wygenerowaniu opisu z punktu widzenia
potrzeb użytkownika (business case), oceny czy jest to
wykonalne i opłacalne. Zdefiniowane są tu przypadki użycia,
zakres działania systemu, a także nowe, ryzykowne bądź trudne
elementy systemy, mogące mieć wpływ na końcowy sukces.
W fazie tej powstaje koncepcja architektury (na najwyższym
poziomie), dla oceny stopnia komplikacji. Należy też ocenić
wykonalność projektu oraz oszacować nakłady czasu, siły
roboczej, finansowe.
Podstawową pracą są tu prace nad wymaganiami, jednakże by
rzetelnie ocenić architekturę konieczne są pewne prace
analityczne, projektowe, a nawet implementacyjne.
Podstawowym pytaniem jest jednak wykonalność
przedsięwzięcia.

JIMO 2010/2011
18
6
Rational Unified Process (RUP)
Elaboration (podstawowa architektura – zarys systemu)
Podstawowym zadaniem tej fazy jest zrozumienie (i formalne
zapisanie) jak wymagania przekładają się na podstawową
architekturę systemu i jak mogą przebiegać dalsze prace.
Wszystkie przypadki użycia powinny być dokładnie opisane.
Zidentyfikowane powinny być elementy obarczone ryzykiem
(nieznane). Powinny one być opracowane jako pierwsze w
następnej fazie (construction). Rozważeniu powinny podlegać
też zagadnienia związane z niezawodnością oraz szybkością
działania. Odpowiednio wysokie wymagania mogą mieć istotny
wpływ na architekturę systemu.
W fazie tej powinna być zaprojektowana, zaimplementowana i
przetestowana przewidywana architektura systemu. Jak w każdej
fazie powinny być określone elementy o najwyższym ryzyku
(najwyższej trudności).

JIMO 2010/2011
19
Rational Unified Process (RUP)
Construction (w pełni funkcjonalna wersja beta)
Produktem końcowym tej fazy jest w pełni
funkcjonalna wersja beta systemu. Może ona
zawierać pewne błędy, wymagać pewnych
niedużych poprawek. Poprawki te nie powinny
zmieniać podstawowej funkcjonalności.
Powodzenie tej fazy zależy głównie od rozwiązania
problemów wykrytych we wcześniejszych fazach.
Faza ta zawiera prace głownie projektowe i
implementacyjne, chociaż prace nad wymaganiami i
analityką są dopuszczalne.

JIMO 2010/2011
20
Rational Unified Process (RUP)
Transition (produkt końcowy - wersja
produkcyjna)
Faza ta zaczyna się instalacji beta wersji
systemu, uzyskaniu opinii użytkownika i
wprowadzeniu żądanych zmian i usprawnień.
Mogą być tu prowadzone prace projektowe i
implementacyjne. Faza ta kończy się
oddaniem wersji produkcyjnej systemu.

JIMO 2010/2011
21
7
Rational Unified Process (RUP)
Faza
(ang. Phase)
Inception
Czas
trwania
Zużycie
zasobów
10-20%
5-10%
Elaboration
30-40%
20-25%
Construction
40-50%
60-65%
Transition
5-10%
5-10%
JIMO 2010/2011
22
Rational Unified Process (RUP)
Liczby iteracji dla projektu o średnim stopniu złożoności:




Inception. Jedna iteracja, składająca się głównie z prac nad
wymaganiami.
Elaboration. Dwie iteracje, pierwsza identyfikująca przypadki
użycia i zarys architektury, druga uszczegółowiająca przyjętą
architekturę.
Construction. Trzy, cztery lub pięć iteracji w zależności od
wykrytych zagrożeń i złożoności systemu. Każda z iteracji
zawiera prace projektowe, implementacyjne i testowanie. Mogą
też wchodzić prace analityczne (wprowadzanie zmian).
Transition. Jedna lub dwie iteracje w zależności od sukcesu
wersji beta.
JIMO 2010/2011
23
Metodyka SCRUM

SCRUM to iteracyjny, przyrostowy sposób budowy/rozwoju produktu. Po każdej
iteracji powinien powstać produkt o nowej funkcjonalności, gotowy do
przekazania zamawiającemu. Cechy charakterystyczne metodyki SCRUM:

SCRUM jest zwinną metodyką zarządzania produkcją oprogramowania,

SCRUM obejmuje (zawiera) istniejące (stosowane) metodyki,

SCRUM jest metodyką dla zespołu wytwarzającego produkt, którego
wymagania zmieniają się gwałtownie,

SCRUM jest procesem, który uwzględnia i rozwiązuje konfliktowe
sytuacje,

SCRUM jest sposobem na poprawę komunikacji w zespole i osiągnięcie
dobrej współpracy.

SCRUM jest sposobem na eliminację przeciwności w procesie
tworzenia produktu.

SCRUM jest sposobem zwiększenia produktywności zespołu,

SCRUM jest skalowany, od pojedynczych produktów do całych
organizacji,

SCRUM powoduje, że każdy członek zespołu czuje się przydatny.
JIMO 2010/2011
24
8
Metodyka SCRUM
JIMO 2010/2011
25
Zarządzanie metodyką SCRUM
JIMO 2010/2011
26
Metodyka SCRUM i eXtreme programmning
JIMO 2010/2011
27
9
Obiektowy sposób myślenia

Języki programowania, rys historyczny






kod maszynowy,
języki asemblera,
języki wysokiego poziomu,
języki generacyjne.
Programowanie strukturalne i obiektowe.
Obiektowy sposób myślenia ang. object oriented analysis, design, programming
(OOA - OOD – OOP)
JIMO 2010/2011
28
Wymagania – przypadki użycia
(ang. use cases)

Wyniki zastosowania przypadków użycia to:




Opis wszystkich interakcji z systemem,
Aktorzy, którzy współdziałają z systemem,
Inne artefakty (takie jak GUI i wymagania niefunkcjonalne).
Podstawowe czynności analizy przypadków użycia:





Znaleźć i opisać aktorów występujących w systemie,
Znaleźć wszystkie przypadki użycia,
Właściwie opisać przypadki użycia,
Opisać cały model przypadków użycia,
Przygotować słownik terminów.
JIMO 2010/2011
29
Przypadki użycia (przykład)
JIMO 2010/2011
30
10
Przypadki użycia (przykład)
JIMO 2010/2011
31
Przypadki użycia - aktor


Aktor to cokolwiek, co współdziała (ma
interakcję) z naszym systemem. Aktor nie
reprezentuje konkretnego użytkownika,
reprezentuje jedynie rolę użytkownika.
Aktor może mieć dodatkowe cechy jak
identyfikatory, dozwolone operacje, znaczniki
(ang. tagged values), ograniczenia.
JIMO 2010/2011
32
Przypadki użycia - aktor

Aktor - jak go znaleźć – trzeba poszukać
odpowiedzi na pytania:







Kto jest zainteresowany systemem?
Kto potencjalnie będzie używał systemu?
Kto będzie czerpał korzyści z działania systemu?
Kto dostarcza informację do systemu?
Kto otrzymuje informację z systemu?
Kto pielęgnuje informację w systemie?
Gdzie jest miejsce systemu w organizacji?
JIMO 2010/2011
33
11
Przypadki użycia

Reguły, które muszą być spełnione przy
poszukiwaniu aktorów:



Zawsze powinien być przynajmniej jeden użytkownik
dla każdego aktora.
Role poszczególnych aktorów powinny być rozłączne.
Przypadki użycia specyfikują sekwencję akcji z
wariantami, które system może wykonać i które
w rezultacie dają wymierny (obserwowalny)
rezultat dla aktora.
JIMO 2010/2011
34
Przypadki użycia

Przypadki użycia zawierają (opisują):





Sekwencję wykonywanych akcji,
Opcjonalny zbiór jednej lub wielu alternatywnych
sekwencji akcji,
Krótką definicję przyczyny przypadku użycia,
Sposób komunikacji z jednym lub wieloma
aktorami,
Ograniczenia w użyciu.
JIMO 2010/2011
35
Przypadki użycia

Przypadki użycia i sposób ich zidentyfikowania.



Zbiór wszystkich przypadków użycia definiuje
funkcjonalność systemu i stanowi postawę do
ustalenia testów końcowych (!).
Identyfikacja przypadków użycia bazuje na
identyfikacji aktorów.
Każdy aktor musi posiadać przynajmniej jeden
przypadek użycia.
JIMO 2010/2011
36
12
Przypadki użycia

W identyfikacji przypadków użycia pomocne mogą być
odpowiedzi na pytania:




Jakie są główne zadania każdego aktora?
Czy aktor zapisuje, odczytuje lub zmienia informację w systemie?
Czy rozpatrywany przypadek użycia powoduje utworzenie,
zapamiętanie, zmianę, usunięcie, odczytanie informacji?
Dla każdego aktora:




Czy aktor ma informować system o zmianach na zewnątrz?
Czy aktor chce być informowany o zmianach na zewnątrz?
Czy przypadki użycia zawierają utrzymanie systemu?
Czy wszystkie wymagania funkcjonalne dla systemu są zawarte
w aktualnych przypadkach użycia?
JIMO 2010/2011
37
Przypadki użycia


Nazwy przypadków użycia muszą mieć
znaczące nazwy.
Do poprawnego zidentyfikowania
przypadków użycia pomocne są techniki:



Wywiadów z aktualnymi lub przyszłymi
użytkownikami systemu,
Tablice poglądowe (rysunki w dużej skali),
Seminaria połączone z burzą mózgów nad
możliwymi scenariuszami zdarzeń w systemie.
JIMO 2010/2011
38
Przypadki użycia

Zdarzenia w przypadkach użycia:







Warunki wstępne do użycia przypadku (logowanie).
Kiedy i jak przypadek zaczyna się i kończy się?
Jakie interakcje przypadku użycia występują z
aktorami?
Jakie dane są potrzebne do przypadku użycia?
Jaki jest normalny ciąg (sekwencja zdarzeń)?
Jakie są sekwencje alternatywne bądź związane z
obsługą wyjątków?
Jakie są warunki po zakończeniu przypadku użycia?
JIMO 2010/2011
39
13
Przypadki użycia

Doskonalenie modeli przypadków użycia.




Model nie powinien być zbyt mały bądź zbyt obszerny.
Celem jest zrozumiałość modelu.
Model powinien być kompletny i zwarty. Nie powinien
odwoływać się do dodatkowego materiału, by móc
określić jego funkcjonalność.
Przypadki użycia powinny dostarczać „wartość
dodatkową” dla użytkowników systemu (aktorów).
Każdy przypadek użycia musi być skojarzony z
przynajmniej jednym aktorem. Przypadek użycia bez
aktora nigdy nie będzie użyty.
JIMO 2010/2011
40
Przypadki użycia



Słowniki (konieczne definicje).
Opisy (konieczne objaśnienia),
Projekty interfejsów :



Interfejsy graficzne z użytkownikiem (GUI), dla
języka Java – pakiet Swing,
Interfejsy z innymi systemami (budowane na
zamówienie – specyfikacja).
Interfejsy oparte na standardach wymiany
informacji (np. XML, webMethods).
JIMO 2010/2011
41
14