1

In ynieria oprogramowania

Wprowadzenie do

przedmiotu

!

↑↑↑↑ "

#

Witam Pa stwa serdecznie na pierwszym wykładzie dotycz cym in ynierii
oprogramowania. Dzisiejszy wykład b dzie troch przypominał ogl danie

okolicy z lotu ptaka. Z tej perspektywy nie wida wielu, by mo e bardzo

wa nych, szczegółów, ale za to ma si obraz cało ci. I ten obraz cało ci, w
odniesieniu do in ynierii oprogramowania, b d si starał w trakcie

dzisiejszego wykładu stworzy .

2

In ynieria oprogramowania

Wprowadzenie (2)

Definicja

$

#

% &

% &

'

%

'

&

#

%

#

(

Zgodnie ze standardowym słownikiem in ynierii oprogramowania opracowanym
przez IEEE, in ynieria oprogramowania jest to zastosowanie systematycznego,

zdyscyplinowanego, ilo ciowego podej cia do rozwoju, eksploatacji i utrzymania

oprogramowania.

3

In ynieria oprogramowania

Wprowadzenie (3)

Definicja

$

#

% &

% &

'

%

'

&

#

%

#

(

Krótko mówi c, jest to zastosowanie in ynierskiego podej cia do oprogramowania.
Taka definicja jest krótka (i to jest jej zalet ), ale – niestety – nie wyja nia zbyt

szczegółowo, co wchodzi w zakres in ynierii oprogramowania.

4

In ynieria oprogramowania

Wprowadzenie (4)

Computing Curricula 2001

Okre leniem zakresu wiedzy dotycz cej ró nych obszarów informatyki, w tym
równie in ynierii oprogramowania, od wielu lat zajmuj si wspólnie dwa,

najwi ksze na wiecie, towarzystwa informatyczne:

IEEE Computer Society

i

Association for Computing Machinery

(w skrócie ACM). Oba powstały tu po II

Wojnie wiatowej w Stanach Zjednoczonych i maj teraz (razem) około 180 tys.

członków na całym wiecie (dla porównania, Polskie Towarzystwo Informatyczne

ma około tysi ca członków). Wydaj wysokiej rangi czasopisma naukowe,
organizuj liczne i bardzo wa ne konferencje oraz zawody dla studentów takie, jak

IEEE Computer Society International Design Competition i ACM International
Collegiate Programming Contest.

5

In ynieria oprogramowania

Wprowadzenie (5)

Computing Curricula 2001

)* + ,

)* - -

Pierwsze rekomendacje dotycz ce studiów informatycznych powstały pod
auspicjami ACM w 1968 roku. IEEE Computer Society opracowało swoje

rekomendacje po raz pierwszy w 1977 roku.

6

In ynieria oprogramowania

Wprowadzenie (6)

Computing Curricula 2001

Pod koniec lat 80-tych oba towarzystwa postanowiły poł czy swoje siły i wspólnie
opracowały standard nauczania zwany Computing Curricula 1991. Dziesi lat

pó niej powstała nowa wersja zwana Computing Curricula 2001.

7

In ynieria oprogramowania

Wprowadzenie (7)

Computing Curricula 2001

%

#

. %

#

' /

.

(

#

#

0

%

1

% #

%

# (

#

2

#

3

4

#

%

5

6 #

7

%

#

6

In ynieria oprogramowania jest jednym z czternastu obszarów informatyki
wyodr bnionych w tym dokumencie.

8

In ynieria oprogramowania

Wprowadzenie (8)

In ynieria oprogramowania

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

6 %

W ramach in ynierii oprogramowania jest osiem jednostek wiedzy o charakterze
obligatoryjnym (czyli ka dy informatyk musi to wiedzie ) i cztery opcjonalne.

9

In ynieria oprogramowania

Wprowadzenie (9)

In ynieria oprogramowania

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

W ród obowi zkowych jednostek wiedzy mamy dwie dotycz ce czynno ci
poprzedzaj cych samo kodowanie programu. Jest to specyfikacja wymaga , czyli

ustalenie co budowany system ma robi i projektowanie oprogramowania, czyli – w

du ym uproszczeniu – zaproponowanie jego struktury.

10

In ynieria oprogramowania

Wprowadzenie (10)

In ynieria oprogramowania

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

Kolejne dwie jednostki dotycz walidacji i weryfikacji oprogramowania (czyli, inaczej
mówi c, kontroli jako ci) i jego ewolucji, czyli utrzymania u yteczno ci programu i

umiej tnego wprowadzania do niego koniecznych zmian.

11

In ynieria oprogramowania

Wprowadzenie (11)

In ynieria oprogramowania

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

In ynieria oprogramowania obejmuje równie takie jednostki wiedzy, jak procesy
wytwarzania oprogramowania (rozpatruje si tutaj, m.in. ró ne modele cyklu ycia

oprogramowania, co ma potem wpływ na planowanie przedsi wzi

programistycznych) i zarz dzanie przedsi wzi ciami programistycznymi.

12

In ynieria oprogramowania

Wprowadzenie (12)

In ynieria oprogramowania

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

Ostatnie dwie obowi zkowe jednostki wiedzy dotycz narz dzi i rodowisk
programistycznych oraz interfejsów programistycznych – w skrócie API od ang.

Application Programming Interface.

13

In ynieria oprogramowania

Wprowadzenie (13)

In ynieria oprogramowania

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

W ród jednostek opcjonalnych s metody formalne (czyli o charakterze
matematycznym), systemy specjalne (np. systemy czasu rzeczywistego steruj ce

prac elektrowni, czy lotem samolotu), komponenty programistyczne i zagadnienia

dot. niezawodno ci oprogramowania.

14

In ynieria oprogramowania

Wprowadzenie (14)

In ynieria oprogramowania

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

Polski standard kształcenia dla kierunku Informatyka, przyj ty przez Rad Główn
Szkolnictwa Wy szego w czerwcu 2006 roku, obejmuje osiem jednostek wiedzy,

które według Computing Curricula 2001 maj charakter obligatoryjny.

15

In ynieria oprogramowania

Wprowadzenie (15)

In ynieria oprogramowania

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

W ramach tego przedmiotu skoncentrujemy si na pierwszych sze ciu obszarach,
natomiast narz dzia, jak i API b d omawiane w ramach innych przedmiotów. Na

przykład takie narz dzia jak kompilatory ró nych j zyków programowania b d

omawiane przy okazji prezentowania paradygmatów programowania, na których te
j zyki si opieraj . W ramach in ynierii oprogramowania b dziemy prezentowa

tylko narz dzia wspomagaj ce dotycz ce takich zagadnie , jak zarz dzanie

konfiguracj , tworzenie modeli w j zyku UML, czy testowanie. Z kolei API b d
prezentowane na przedmiotach zwi zanych z ró nymi obszarami informatyki. Na

przykład API dotycz ce wybranego systemu operacyjnego b dzie prezentowane w
ramach zaj z systemów operacyjnych, API zwi zane z pakietami graficznymi – na

przedmiocie dotycz cym grafiki komputerowej itd.

16

In ynieria oprogramowania

Wprowadzenie (16)

Plan wykładu

$

%

4

#

% :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

W dalszej cz ci wykładu chciałbym krótko omówi tematyk kolejnych wykładów,
jakie nas czekaj w ramach tego przedmiotu.

17

In ynieria oprogramowania

Wprowadzenie (17)

Plan wykładu

$

%

4

#

% :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

Zaczniemy od zasad skutecznego działania.

18

In ynieria oprogramowania

Wprowadzenie (18)

Pracodawcy si skar

6

4 9

1

#

/ &

#

9

%

&

6

#

#

1

'

%

%

9

9

9

Szefowie ameryka skich firm informatycznych skar si , e absolwenci
ameryka skich uczelni nie potrafi si komunikowa , maj niedostateczne

przygotowanie do pracy w zespole i e brak im umiej tno ci skutecznego i

produktywnego zarz dzania ich prac indywidualn . Prawdopodobnie tego typu
zastrze enia mo na by usłysze równie z ust pracodawców polskich. Dlatego

zanim zaczniemy prezentowa ró ne metody i narz dzia in ynierii oprogramowania

postanowiłem najpierw przedstawi ogólne zasady skutecznego działania, które
stanowi podstaw dla szczegółowych rozwi za i bez rozumienia których trudno

oczekiwa satysfakcjonuj cych efektów.

19

In ynieria oprogramowania

Wprowadzenie (19)

Zasady Covey’ego

= >

8

?

1

9

@ -

;

%

A

Zasady te b d oparte na słynnej ksi ce Stephena Covey’ego „7 nawyków
skutecznego działania”. Na slajdzie widzimy okładk do jej wersji d wi kowej.

Ksi ka ta została równie wydana w j zyku polskim.

20

In ynieria oprogramowania

Wprowadzenie (20)

Zasady Covey’ego

= >

$

' /

' /

8

;

' /

Ogólnie mówi c, Stephen Covey proponuje swoim czytelnikom rozwój osobowo ci
od stanu zale no ci od innych osób, poprzez niezale no od innych do

współzale no ci z innymi osobami.

21

In ynieria oprogramowania

Wprowadzenie (21)

Zasady Covey’ego

$

' /

' /

8

;

' /

#

B

0

=

6 B

Zale no od innych osób przejawia si nadmiern tendencj do obarczania tych
innych zadaniem opieki nad sob . Osoby zale ne wierz , e to inni s

odpowiedzialni za ich wykształcenie, brak pracy, czy problemy rodzinne. Oni sami

wydaj si mie niewielki wpływ na swoje ycie. Taka postawa rzadko kiedy (je li
kiedykolwiek) prowadzi do skutecznego działania.

22

In ynieria oprogramowania

Wprowadzenie (22)

Zasady Covey’ego

$

' /

' /

8

;

' /

C #

1 B

1 B

Niezale no to wiara we własne siły i zaufanie do siebie. Osoby niezale ne s
przekonane, e anga uj c własn energi , zdolno ci i emocje s w stanie osi gn

wiele, bardzo wiele.

23

In ynieria oprogramowania

Wprowadzenie (23)

Zasady Covey’ego

$

' /

' /

8

;

' /

D . 6

6

E $

#

9

% 1

) 5 9 ?

Aby przej od zale no ci do niezale no ci Stephen Covey proponuje wdro enie w
swoim yciu trzech zasad: trzeba by proaktywnym, trzeba zaczyna maj c zawsze

koniec (czyli skutki swoich działa ) na wzgl dzie i trzeba tak zarz dza czasem,

aby rzeczy pierwsze w sensie wa no ci były równie pierwsze w przydzielaniu im
naszego czasu. Aby by skutecznym nie wystarczy te zasady zrozumie i zgodzi

si z nimi – trzeba je tak gł boko wdro y , aby stały si naszymi nawykami.

24

In ynieria oprogramowania

Wprowadzenie (24)

Zasady Covey’ego

$

' /

' /

8

;

' /

F

#

#

1 B

5 1

(

Wy szym stopniem rozwoju osobowo ci od niezale no ci jest współzale no .
Współzale no pozwala osi gn rzeczy, które byłyby dla pojedynczej osoby nie

do osi gni cia. Jest to przekonanie, e razem mo emy wi cej.

25

In ynieria oprogramowania

Wprowadzenie (25)

Zasady Covey’ego

$

' /

' /

8

;

' /

+ C 6

% 1

G

1

#

/

H

'

6

;

'

Rozwój polegaj cy na przej ciu od niezale no ci do współzale no ci opiera si na
kolejnych trzech zasadach, które nale y wdro y : trzeba my le o obopólnej

korzy ci, a nie tylko własnej, trzeba najpierw stara si zrozumie partnera (klienta,

szefa, pracownika) a dopiero potem oczekiwa by nas zrozumiano i trzeba dba o
synergi .

26

In ynieria oprogramowania

Wprowadzenie (26)

Zasady Covey’ego

$

' /

' /

8

;

' /

+ C 6

% 1

G

1

#

/

H

'

6

;

'

D . 6

6

E $

#

9

% 1

) 5 9 ?

1

Do tego dochodzi jeszcze jedna, siódma zasada: ostrz pił , czyli dbaj o ci głe
doskonalenia.

27

In ynieria oprogramowania

Wprowadzenie (27)

Zasady Covey’ego

+ C 6

% 1

G

1

#

/

H

'

6

;

'

D . 6

6

E $

#

9

% 1

) 5 9 ?

1

O tych siedmiu zasadach b dzie mowa na nast pnym wykładzie. Ka da z tych
zasad skutecznego działania zostanie do dokładnie przedstawiona. Jednak

ostateczny efekt b dzie zale ał od tego, w jakim stopniu słuchacze zdecyduj si

przeku te zasady w swoje nawyki.

28

In ynieria oprogramowania

Wprowadzenie (28)

Plan wykładu

$

%

4

#

% :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

Tematem nast pnego wykładu b dzie specyfikacja wymaga .

29

In ynieria oprogramowania

Wprowadzenie (29)

Specyfikacja wymaga

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

Wykład ten b dzie wprost nawi zywał do jednostki wiedzy „specyfikacja wymaga ”.

30

In ynieria oprogramowania

Wprowadzenie (30)

Cykl ycia

8

#

%

8

In ynierskie podej cie do wytworzenia jakiego produktu opiera si zazwyczaj na
cyklu ycia obejmuj cym przynajmniej trzy fazy: zebranie wymaga , opracowanie

projektu i wykonanie produktu.

31

In ynieria oprogramowania

Wprowadzenie (31)

Cykl ycia

8

8

#

%

Je li, na przykład, kto my li o przedsi wzi ciu budowlanym, to najpierw trzeba
zebra wymagania inwestora dotycz ce funkcji, jakie budynek ma pełni i trzeba

uwzgl dni ograniczenia sformułowane w warunkach zabudowy.

32

In ynieria oprogramowania

Wprowadzenie (32)

Cykl ycia

8

#

%

8

W nast pnej fazie powstaje projekt architektoniczny, który pokazuje, jak zebrane
wymagania i nało one ograniczenia maj by spełnione.

33

In ynieria oprogramowania

Wprowadzenie (33)

Cykl ycia

8

#

%

8

I wreszcie dochodzi do fazy wykonania, dla której punktem wyj cia jest projekt
opracowany na podstawie wymaga .

34

In ynieria oprogramowania

Wprowadzenie (34)

Cykl ycia

8

#

%

8

Podobnie powinno by z przedsi wzi ciem programistycznym. Na pocz tku nale y
zebra wymagania dotycz ce systemu, który ma by zbudowany.

35

In ynieria oprogramowania

Wprowadzenie (35)

Cykl ycia

8

#

%

8

!!

"

#

$

" !% &

'

! ( ) * ( + ,

Maj c wymagania mo na przej do opracowania projektu systemu. Na slajdzie
widoczny jest projekt systemu informatycznego przedstawiony w j zyku UML.

36

In ynieria oprogramowania

Wprowadzenie (36)

Cykl ycia

8

#

%

8

!!

"

#

$

" !% &

'

! ( ) * ( + ,

W oparciu o projekt programi ci tworz kod systemu. Oczywi cie, potem nale y
jeszcze sprawdzi , czy system nie zawiera defektów i czy spełnia wymagania, o

które chodziło klientowi.

37

In ynieria oprogramowania

Wprowadzenie (37)

In ynieria wymaga

8

#

%

Samo zbieranie i opracowanie wymaga jest tak wa nym i trudnym procesem, e
mówi si wr cz o in ynierii wymaga . Rozumie si przez to fragment in ynierii

oprogramowania odpowiedzialny za wymagania.

38

In ynieria oprogramowania

Wprowadzenie (38)

In ynieria wymaga

8

#

%

$ 6

# % :

.

#

% :

%

# % :

6 #

9

Proces zbierania i opracowywania wymaga ma najcz ciej charakter cykliczny.

39

In ynieria oprogramowania

Wprowadzenie (39)

In ynieria wymaga

8

#

%

$ 6

# % :

.

#

% :

%

# % :

6 #

9

Powinien by poprzedzony sformułowaniem problemu (lub problemów), które
budowany system informatyczny ma rozwi za i nakre leniem bardzo ogólnej wizji

rozwi zania.

40

In ynieria oprogramowania

Wprowadzenie (40)

In ynieria wymaga

8

#

%

$ 6

# % :

.

#

% :

%

# % :

6 #

9

Zasadnicza cz

procesu zbierania i opracowywania wymaga składa si z trzech

faz. Pierwsz faz powinno by zbieranie wymaga . Cz sto wymagania pochodz

od wielu ró nych osób i na dodatek nale y uwzgl dnia ograniczenia wynikaj ce

np. z ró nych przepisów prawa.

41

In ynieria oprogramowania

Wprowadzenie (41)

In ynieria wymaga

8

#

%

$ 6

# % :

.

#

% :

%

# % :

6 #

9

Drug faz powinna by analiza wymaga . Wymagania mog by wzajemnie
sprzeczne, niejednoznaczne itp. – im wcze niej si takie wady wykryje tym lepiej

dla całego przedsi wzi cia.

42

In ynieria oprogramowania

Wprowadzenie (42)

In ynieria wymaga

8

#

%

$ 6

# % :

.

#

% :

%

# % :

6 #

9

Po analizie wymaga potrzebna jest ich negocjacja. Wykryte defekty, takie jak np.
sprzeczno ci mi dzy wymaganiami, nale y usun . Zazwyczaj wymaga to

negocjacji z wieloma zainteresowanymi osobami i mo e by bardzo trudne.
Je li osoby odpowiedzialne za przedsi wzi cie uznaj , e wymagania maj ju

odpowiedni jako i mo na na ich podstawie przej do pracy nad projektem, to
proces zbierania i analizy wymaga mo na zako czy .

43

In ynieria oprogramowania

Wprowadzenie (43)

In ynieria wymaga

8

#

%

8

#

%

4

8

#

%

4

Generalnie wymagania mo na podzieli na funkcjonalne i pozafunkcjonalne.
Wymagania funkcjonalne opisuj funkcje, jakie ma realizowa system. Przykładem

mo e by wymaganie, aby budowany system ksi garni internetowej automatycznie

wysyłał do wydawcy zamówienia na te tytuły, których liczba w magazynie spadnie
poni ej 20 sztuk. Wymagania pozafunkcjonalne dotycz takich aspektów, jak

wydajno (np. szybko wykonania poszczególnych operacji), czy niezawodno .

44

In ynieria oprogramowania

Wprowadzenie (44)

Wykład nt. specyfikacji wymaga

C 6

$

%

4

# % :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

4

# % :

W trakcie wykładu po wi conego specyfikacji wymaga przedstawiona zostanie
metoda specyfikacji wymaga funkcjonalnych zwana przypadkami u ycia. Metoda

ta staje si coraz bardziej popularna, równie w polskich firmach informatycznych.

Zaprezentowane zostan tak e dobre praktyki dotycz ce dokumentu specyfikacji
wymaga , zbierania wymaga , ich analizy i negocjacji oraz opisywania wymaga .

Ta problematyka zostanie rozwini ta w ramach przedmiotu obieralnego
„Zaawansowana in ynieria oprogramowania”.

45

In ynieria oprogramowania

Wprowadzenie (45)

Plan wykładu

$

%

4

#

% :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

Kolejny wykład b dzie po wi cony kontroli jako ci artefaktów.

46

In ynieria oprogramowania

Wprowadzenie (46)

Kontrola jako ci artefaktów

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

Jest on bezpo rednio zwi zany z jednostk wiedzy dotycz c walidacji.
Zagadnienia te nabieraj szczególnego znaczenia w przypadku budowy tzw.

systemów krytycznych, czyli systemów, których awaria mo e doprowadzi do utraty

zdrowia, a nawet ycia ludzkiego lub spowodowa ogromne straty materialne.

47

In ynieria oprogramowania

Wprowadzenie (47)

Artefakty

4

# % :

0

%

#

1

W trakcie pracy nad systemem informatycznym powstaje cały szereg ró nego typu
artefaktów: specyfikacja wymaga , testy akceptacyjne, kod programu, podr cznik

u ytkownika i wiele innych. Oczywi cie, musz to by produkty dobrej jako ci – nie

mog zawiera powa nych defektów.

48

In ynieria oprogramowania

Wprowadzenie (48)

Artefakty

4

# % :

0

%

#

1

Dlatego potrzebna jest kontrola jako ci tych artefaktów.

49

In ynieria oprogramowania

Wprowadzenie (49)

Kontrola jako ci specyfikacji wymaga

$ 6

# % :

.

#

% :

%

# % :

6 #

9

Wiele osób my li o kontroli jako ci, jako ostatniej fazie pracy nad jakim artefaktem.
Nie jest to, ogólnie rzecz bior c, najlepsze podej cie. Omawiaj c proces zbierania i

analizy wymaga przedstawiłem iteracyjny cykl ycia, w którym analiza wymaga – i

zwi zana z ni kontrola jako ci tych wymaga – s wykonywane wielokrotnie.

50

In ynieria oprogramowania

Wprowadzenie (50)

Rodzaje kontroli jako ci

0

% 9

W praktyce kontrola jako ci najcz ciej przyjmuje posta testowania lub
przegl dów. Testowanie mo na wykona tylko w odniesieniu do działaj cego

systemu lub jego prototypu. Przegl dy s bardziej ogólne: mo na je stosowa

zarówno do kodu, jak i do specyfikacji wymaga . Istot przegl du jest analiza
artefaktów. Analiza ta mo e by przeprowadzona przez pojedyncz osob

(nazywamy to recenzj ) lub te przez zespół osób (najpopularniejszym przykładem

tego typu przegl dów s inspekcje).

51

In ynieria oprogramowania

Wprowadzenie (51)

Wykład nt. kontroli jako ci

' /

7

6

4

;

$

%

4

# % :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

'

4

;

W trakcie wykładu po wi conego kontroli jako ci artefaktów przedstawi krótko
najwa niejsze poj cia dotycz ce jako ci i testowania, zaprezentuj sposób

przeprowadzania inspekcji zgodny ze standardem IEEE 1028 i poka , jak mo na

oszacowa liczb defektów, jakie zakradły si do artefaktu (ł cznie z tymi, które nie
zostały w trakcie kontroli jako ci wykryte).

52

In ynieria oprogramowania

Wprowadzenie (52)

Plan wykładu

$

%

4

#

% :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

Kolejny wykład b dzie po wi cony j zykowi UML.

53

In ynieria oprogramowania

Wprowadzenie (53)

J zyk UML

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

UML jest wykorzystywany m.in. przy projektowaniu systemów informatycznych. Jest
te wiele narz dzi komercyjnych i darmowych wspomagaj cych tworzenie modeli w

j zyku UML (w ród narz dzi komercyjnych du popularno ci cieszy si Rational

Rose, a jednym z bardziej popularnych darmowych narz dzi jest ArgoUML).

54

In ynieria oprogramowania

Wprowadzenie (54)

www.uml.org

UML jest stosunkowo nowym j zykiem. Jego pierwsza wersja została
zaakceptowana w 1997 roku. Na slajdzie jest pokazana strona internetowa

dotycz ca j zyka UML, która jest utrzymywana przez mi dzynarodow organizacj

OMG zatwierdzaj c kolejne wersje tego j zyka. Osoby znaj ce j zyk angielski
znajd na tej stronie wiele cennych informacji na temat j zyka UML.

55

In ynieria oprogramowania

Wprowadzenie (55)

Diagramy UML

C

%

#

;

C

%

#

;

C

%

#

C

%

#

'

C

%

#

( ( (

J zyk UML obejmuje wiele ró nego typu diagramów, które pozwalaj w sposób
graficzny modelowa ró ne aspekty systemów informatycznych (i nie tylko

informatycznych). Tytułem wprowadzenia do j zyka UML przedstawione zostan

bardzo proste przykłady diagramu stanów, diagramu przypadków u ycia i diagramu
sekwencji. Zarówno te wymienione diagramy, jak i pozostałe zostan bardziej

szczegółowo omówione w trakcie wykładu po wi conego j zykowi UML.

56

In ynieria oprogramowania

Wprowadzenie (56)

Diagram stanów

1

$

4

I$

I$

I$

%

'

I$

' 6

1

Pierwszym diagramem, który chciałbym pokaza jest diagram stanów. Na slajdzie
widzimy diagram pokazuj cy „przeistaczanie” si maturzysty w studenta – za chwil

dokładniej go omówimy.

57

In ynieria oprogramowania

Wprowadzenie (57)

Diagram stanów

Kluczowym elementem na diagramach stanów s oczywi cie stany. Stan jest
reprezentowany za pomoc owalu z nazw stanu w rodku.

58

In ynieria oprogramowania

Wprowadzenie (58)

Diagram stanów

'

Mi dzy stanami s przej cia reprezentowane za pomoc strzałki. W przypadku
diagramu pokazanego na slajdzie wida , e b d c w stanie „Maturzysta” mo na

przej do stanu „Kandydat”, ale nie odwrotnie.

59

In ynieria oprogramowania

Wprowadzenie (59)

Diagram stanów

I$

.

Z przej ciem mo e by zwi zana akcja. W przykładzie pokazanym na slajdzie
wida , e przej cie od stanu „Maturzysta” do stanu „Kandydat” wi e si ze

zło eniem podania na studia.

60

In ynieria oprogramowania

Wprowadzenie (60)

Diagram stanów

$

<

'

Akcje s poprzedzane znakiem uko nej kreski – tym samym, jaki jest
wykorzystywany jako symbol dzielenia.

61

In ynieria oprogramowania

Wprowadzenie (61)

Diagram stanów

I$

9

Pocz tek jest zaznaczany małym ciemnym kółkiem. St d zaczyna si „chodzenie”
po stanach.

62

In ynieria oprogramowania

Wprowadzenie (62)

Diagram stanów

1

$

4

I$

I$

I$

%

'

I$

' 6

1

Zgodnie z diagramem przedstawionym na slajdzie, najpierw trzeba zda matur i
wtedy zdobywa si status maturzysty (w odniesieniu do wiata rzeczywistego jest to

uproszczenie, ale modele maj to do siebie, e zawsze w jaki sposób upraszczaj

rzeczywisto ). Po zło eniu podania na studia stajemy si kandydatami. Wskutek
akcji, czy zdarze nie pokazanych na diagramie Kandydat uzyskuje status

Zakwalifikowanego (mo na si domy la , e trzeba tutaj pozytywnie przej przez
procedur kwalifikacyjn ) lub te staje si Nieprzyj ty. Po zło eniu podania

Zakwalifikowany staje si Przyj tym, a po zło eniu lubowania uzyskuje on

upragniony status Studenta.

63

In ynieria oprogramowania

Wprowadzenie (63)

Diagram przypadków u ycia

$

4

1

$

6

;

Przejd my teraz do diagramów przypadków u ycia. S one wykorzystywane do
pokazania kto co mo e zrobi .

64

In ynieria oprogramowania

Wprowadzenie (64)

Diagram przypadków u ycia

.

Jednym z głównych elementów wyst puj cych na diagramach przypadków u ycia
s tzw. aktorzy. Na slajdzie pokazano symbol, jakim si oznacza aktorów w j zyku

UML. Aktor jest to rola, jak człowiek lub ewentualnie urz dzenie mo e odgrywa w

kontakcie z opisywanym systemem informatycznym.

65

In ynieria oprogramowania

Wprowadzenie (65)

Diagram przypadków u ycia

$

4

1

Na slajdzie widzimy trzech aktorów: Maturzyst , Zakwalifikowanego i Nieprzyj tego.

66

In ynieria oprogramowania

Wprowadzenie (66)

Diagram przypadków u ycia

.

Aktor mo e mie do czynienia z przypadkiem u ycia opisuj cym pewien cel (np. o
charakterze biznesowym), który aktor chce osi gn w kontakcie z systemem

informatycznym. Nazwy przypadków u ycia zapisuje si w elipsach tak, jak

pokazano to na slajdzie.

67

In ynieria oprogramowania

Wprowadzenie (67)

Diagram przypadków u ycia

$

4

1

$

6

;

Zgodnie z przedstawionym diagramem, Maturzysta mo e zło y podanie, natomiast
zarówno Zakwalifikowany, jak i Nieprzyj ty mog obejrze wyniki rekrutacji.

68

In ynieria oprogramowania

Wprowadzenie (68)

Diagram sekwencji

#

F

=

9

J

9

1

8

1

9

1

Trzecim rodzajem diagramów j zyka UML, jaki chciałbym przedstawi s diagramy
sekwencji. Diagramy te słu do ilustrowania komunikacji mi dzy obiektami.

69

In ynieria oprogramowania

Wprowadzenie (69)

Diagram sekwencji

6

2)

6

2E

6

6

Ka dy obiekt jest reprezentowany przez prostok t zawieraj cy jego nazw i tzw.
lini ycia obiektu.

70

In ynieria oprogramowania

Wprowadzenie (70)

Diagram sekwencji

6

2)

6

2E

#

Komunikaty przesyłane mi dzy obiektami s reprezentowane za pomoc strzałki,
nad któr pisze si nazw komunikatu. Strzałka pokazuje kierunek przepływu

komunikatu. Na pokazanym slajdzie komunikat jest wysyłany przez Obiekt-1 i trafia

do Obiekt-2.

71

In ynieria oprogramowania

Wprowadzenie (71)

Diagram sekwencji

6

2)

6

2E

#

2)

#

2E

#

2D

Diagramy sekwencji zazwyczaj zawieraj wi cej ni jeden komunikat. Komunikaty
s wysyłane w kolejno ci „od góry do dołu”. Na slajdzie wida trzy komunikaty.

Najpierw b dzie wysłany Komunikat-1, potem Komunikat-2 i na ko cu Komunikat-3.

Tak si zło yło, e wszystkie te komunikaty s wysyłane przez Obiekt-1 i trafiaj do
Obiekt-2.

72

In ynieria oprogramowania

Wprowadzenie (72)

Diagram sekwencji

#

F

=

9

J

9

1

8

1

9

1

Diagram pokazany na tym slajdzie opisuje komunikacj mi dzy trzema obiektami:
Maturzyst , Systemem rekrutacji na studia i obiektem o nazwie KReM (chodzi tutaj

o Krajowy Rejestr Matur – system informatyczny udost pniaj cy wyniki matur z

Okr gowych Komisji Egzaminacyjnych). Zgodnie z tym diagramem maturzysta
chc cy dosta si na studia najpierw składa podanie i wprowadza swoje oceny.

Nast pnie system rekrutacji wysyła do KReM-u zapytanie, czy wprowadzone oceny
s poprawne. KReM przesyła komunikat, z którego wynika, e oceny s poprawne.

Wtedy system rekrutacji wysyła do maturzysty komunikat z potwierdzeniem

przyj cia podania i ocen. Teraz maturzysta wnosi opłat rekrutacyjn , a system
rekrutacji potwierdza przyj cie tej opłaty.
Zalet diagramów sekwencji jest pokazanie jakby z globalnego punktu widzenia
(czyli patrz c na wszystkie interesuj ce nas obiekty), jak wygl da komunikacja

mi dzy obiektami. Pomaga to zrozumie działanie opisywanego systemu i jest to
informacja, której nie dostarczaj inne rodzaje diagramów j zyka UML.

73

In ynieria oprogramowania

Wprowadzenie (73)

Diagramy j zyka UML

In ynieria oprogramowani a

Wprowadzeni e (67)

Diag ram przypadków u ycia

$

4

1

$

6

;

In ynieria oprogramowani a

Wprowadzeni e (62)

Diag ram stanów

1

$

4

I$

I$

I$

%

'

I$

' 6

1

In ynieria oprogramowani a

Wprowadzeni e (72)

Diagram sekwen cji

#

F

=

9

J

9

1

8

1

9

1

Jak wida , j zyk UML oferuje ró nego rodzaju diagramy, z których ka dy opisuje
inne aspekty systemu. Jak ju wcze niej wspomniano, tych rodzajów diagramów

jest wi cej i b d one omówione w trakcie wykładu po wi conego j zykowi UML.

74

In ynieria oprogramowania

Wprowadzenie (74)

Plan wykładu

$

%

4

#

% :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

Kolejny wykład b dzie dotyczył metod formalnych.

75

In ynieria oprogramowania

Wprowadzenie (75)

Metody formalne

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

Zgodnie z Computing Curricula 2001, metody formalne s jednostk opcjonaln .
Maj one cisły zwi zek z walidacj oprogramowania. Niektórzy podchodz do nich

sceptycznie, inni upatruj w nich nadziej na istotne podniesienie jako ci

tworzonego oprogramowania, jako ci rozumianej jako zgodno implementacji ze
specyfikacj .

76

In ynieria oprogramowania

Wprowadzenie (76)

Metody formalne

α∧β

α∧β

α∧β

α∧β

αααα

1 (

# (

<

1 (

=

J

%

#

Zasadnicza koncepcja zwi zana z metodami formalnymi polega na tym, by
wykazywa poprawno programów nie w oparciu o testy czy przegl dy, lecz na

gruncie matematycznym, poprzez dowodzenie wła ciwo ci programów.

77

In ynieria oprogramowania

Wprowadzenie (77)

Silnia

K

L M

& N

O P N

O )N

K BO

L M

O

Q )N

O

R N

S

N

S

Spróbujmy udowodni , e przedstawiona na slajdzie funkcja zapisana w j zyku C
oblicza warto n!.

78

In ynieria oprogramowania

Wprowadzenie (78)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

K BO

L M

O

Q )N

O

R N

S

N

IR R R

0

O O

B R R R I

S

Pierwszym krokiem jest zwi zanie z t funkcj warunku wst pnego (po angielsku –

precondition

) i ko cowego (ang.

postcondition

). Poniewa parametr n został

zadeklarowany jako liczba całkowita, to wystarczy doda jako warunek wst pny, e

ma by to liczba nieujemna. St d te umie cili my w tek cie programu komentarz
PRE zawieraj cy warunek „n >= 0”. Warunek ko cowy (POST) okre la relacj , jaka

ma by prawdziwa na ko cu wykonania podprogramu. W przypadku omawianego

programu na ko cu zmienna s powinna mie warto n!.

79

In ynieria oprogramowania

Wprowadzenie (79)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

K BO

L M

O

Q )N

O

R N

S

N

IR R R

0

O O

B R R R I

S

No to teraz wystarczy tylko dowie , e je eli na pocz tku wykonania podprogramu
n >= 0, to na ko cu s b dzie równe n!. Łatwo powiedzie , trudno zrobi . W

przypadku naszego programu najtrudniejszym elementem jest p tla

while

.

Dowodzenie poprawno ci programu zawieraj cych p tle odbywa si metod
niezmienników (ang.

invariant

). Niezmiennik jest to zdanie, które jest prawdziwe za

ka dym razem, kiedy powtarzane jest wykonanie instrukcji zawartych w p tli.

Dokładnie mówi c, niezmiennik powinien by prawdziwy tu przed pierwszym
wykonaniem instrukcji zawartych w p tli, tu przed drugim wykonaniem, przed

trzecim itd. Zasadniczy problem polega na tym by znale (wymy li ) taki
niezmiennik, który zawsze b dzie prawdziwy i jednocze nie pomo e nam w

udowodnieniu warunku ko cowego POST.

80

In ynieria oprogramowania

Wprowadzenie (80)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

Nasz podprogram jest bardzo prosty i nietrudno zauwa y , e niezmiennik (INV) ma
posta nast puj cego zdania: s równa si k!. Najpierw udowodnimy, e to zdanie

jest faktycznie niezmiennikiem, a potem poka emy, jak go wykorzysta do

udowodnienia warunku ko cowego.

81

In ynieria oprogramowania

Wprowadzenie (81)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

) O P B

Pierwsze wyst pienie inwariantu (tu przed wykonaniem instrukcji

while

) jest

prawdziwe, bowiem na mocy definicji funkcji silnia, 0! jest równe 1.

82

In ynieria oprogramowania

Wprowadzenie (82)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

Instrukcja „k= k+1” jest o tyle kłopotliwa, e wyst puje w niej dwa razy ten sam
symbol k i za ka dym razem oznacza inn warto .

83

In ynieria oprogramowania

Wprowadzenie (83)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

eby usun t niejednoznaczno oznaczmy przez k z podkre leniem pocz tkow

warto k, jaka była przed wykonaniem tej instrukcji przypisania, a k bez

podkre lenia niech oznacza now warto , jaka b dzie po wykonaniu tej instrukcji.

84

In ynieria oprogramowania

Wprowadzenie (84)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

O O B

Zatem z pierwszego inwariantu wynika, e przed wykonaniem tej instrukcji
przypisania mamy s równe „k z podkre leniem” silnia.

85

In ynieria oprogramowania

Wprowadzenie (85)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

O O B

O O B

∧∧∧∧ O O Q )

Po wykonaniu omawianej instrukcji przypisania dojdzie nam jeszcze zdanie
mówi ce, e nowa warto k jest równa starej warto ci powi kszonej o 1.

86

In ynieria oprogramowania

Wprowadzenie (86)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

O O B

O O B

∧∧∧∧ O O Q )

O O K V )LB

Czyli po wykonaniu tej instrukcji przypisania b dziemy mieli s równe (k-1)!.

87

In ynieria oprogramowania

Wprowadzenie (87)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

O O K V )LB

W kolejnej instrukcji przypisania mamy podobn niejednoznaczno , jak
poprzednio: dwa razy wyst puje symbol s i za ka dym razem oznacza inn warto .

88

In ynieria oprogramowania

Wprowadzenie (88)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

O O K V )LB

Podobnie jak poprzednio przyjmiemy, e s z podkre leniem oznacza „star ”
warto , a s bez podkre lenia „now ” warto zmiennej s.

89

In ynieria oprogramowania

Wprowadzenie (89)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

O O K V )LB

O O K V )LB

Zatem na mocy poprzednio dowiedzionego faktu mo na powiedzie , e tu przed
wykonaniem tej instrukcji przypisania stara warto s jest równa (k-1)!.

90

In ynieria oprogramowania

Wprowadzenie (90)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

O O K V )LB

∧∧∧∧ O O R

O O K V )LB

Po wykonaniu tej instrukcji b dzie mo na dopisa do poprzedniego zdania jeszcze
jedno: nowa warto s jest równa starej pomno onej przez k.

91

In ynieria oprogramowania

Wprowadzenie (91)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

O O K V )LB

∧∧∧∧ O O R

O O K V )LB R

O O B

O O K V )LB

Je eli zast pimy star warto s przez (k – 1)!, to oka e si , e nowa warto s jest
równa k!.

92

In ynieria oprogramowania

Wprowadzenie (92)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

I w ten sposób dowiedli my, e je eli na pocz tku wykonania instrukcji

while

prawd

jest, e s jest równe k!, to po wykonaniu obu instrukcji przypisania nadal s b dzie

równe k!. Zatem faktycznie jest to niezmiennik tej p tli.

93

In ynieria oprogramowania

Wprowadzenie (93)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

O O

Aby dowie prawdziwo warunku ko cowego (POST) wystarczy zauwa y , e
zaraz po wykonaniu instrukcji

while

prawdziwy jest inwariant „s jest równe k!” oraz

prawdziwe jest zaprzeczenie warunku wyst puj cego w instrukcji

while

, czyli k jest

równe n.

94

In ynieria oprogramowania

Wprowadzenie (94)

Silnia

K

L M

IR R R F

T O P R R R I

& N

O P N

O )N

IR R R 7 U

O O

B R R R I

K BO

L M

O

Q )N

O

R N IR R R 7 U

O O B R R R I

S

N

IR R R

0

O O

B R R R I

S

O O

Podstawiaj c niezmiennik n w miejsce k dostajemy warunek ko cowy i w ten
sposób ko czy si dowód poprawno ci tego podprogramu.

95

In ynieria oprogramowania

Wprowadzenie (95)

Dowodzenie poprawno ci programów

8

4%

% F

4

%

#

4

-

PP

P

=

G

PP

P

=

Do lat 90-tych dowodzenie poprawno ci programów odbywało si jedynie dla
bardzo krótkich programów. W ci gu ostatniej dekady nast pił istotny post p i

powstały bardzo efektywne weryfikatory. Jednak e dowodzenie poprawno ci

programu jest wci bardzo pracochłonne. Ciekawe dane pozyskano w ramach
projektu VSE (Verification Support Environment) finansowanego przez Uni

Europejsk . Jak pisze prof. Wolfgang Reif, dowiedzenie poprawno ci programu

zawieraj cego ok. 7 tys. wierszy wymagało pracochłonno ci około 2 osobolat, a
sama specyfikacja formalna miała ok. 5 tys. wierszy tekstu. Jak wi c wida ,

formalna specyfikacja programów mo e by bardzo obszerna i jej wytworzenie oraz
sprawdzenie jej poprawno ci jest zadaniem samym w sobie.

96

In ynieria oprogramowania

Wprowadzenie (96)

Wykład nt. metod formalnych

4

#

7#

#

%

$

%

4

# % :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

4 #

W trakcie wykładu dotycz cego metod formalnych omówi tzw. specyfikacje
aksjomatyczne i zwi zane z nimi implementacje niestandardowe, maj ce charakter

anomalii. Przedstawi te sieci Petriego jako chyba najbardziej popularne narz dzie

modelowania oprogramowania. Jest to notacja matematyczna o charakterze
graficznym wykorzystywana do modelowania nie tylko systemów informatycznych,

ale tak e np. systemów transportowych.

97

In ynieria oprogramowania

Wprowadzenie (97)

Plan wykładu

$

%

4

#

% :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

Kolejny wykład b dzie po wi cony wzorcom projektowym.

98

In ynieria oprogramowania

Wprowadzenie (98)

Wzorce projektowe

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

Wzorce projektowe s podstaw współczesnego projektowania oprogramowania.

99

In ynieria oprogramowania

Wprowadzenie (99)

Wzorce projektowe

=

.

W

Wzorzec = Sprawdzona koncepcja,

która:

• opisuje problem powtarzaj cy si

wielokrotnie w okre lonym

kontek cie,

• działaj ce na niego siły, oraz
• podaje istot jego rozwi zania w

sposób abstrakcyjny.

Informatyka zawdzi cza koncepcj wzorców profesorowi Christopherowi
Alexandrowi. Zgodnie z jego koncepcj wzorzec jest to sprawdzona koncepcja,

która opisuje problem powtarzaj cy si wielokrotnie w okre lonym kontek cie,

działaj ce na niego siły oraz podaje istot rozwi zania tego problemu w sposób
abstrakcyjny.

100

In ynieria oprogramowania

Wprowadzenie (100)

Wykład nt. wzorców projektowych

5

=

%

;

8

6

$

%

4

# % :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

8

W ramach wykładu powiemy o Bandzie Czterech, czyli tych, którzy wprowadzili
wzorce do in ynierii oprogramowania, omówiony zostanie katalog wzorców

projektowych i przedstawione zostan wybrane wzorce projektowe oraz ich

zastosowania.

101

In ynieria oprogramowania

Wprowadzenie (101)

Plan wykładu

$

%

4

#

% :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

W cyklu wykładowym po wi conym in ynierii oprogramowania nie mo e zabrakn
wykładu dotycz cego zarz dzania konfiguracj .

102

In ynieria oprogramowania

Wprowadzenie (102)

Zarz dzanie konfiguracj

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

Zmiany w oprogramowaniu i towarzysz ca im ewolucja kodu s praktycznie nie do
unikni cia. Wła ciwe zarz dzanie konfiguracj jest podstaw skutecznej ewolucji

oprogramowania i jedn z kluczowych praktyk zarz dzania przedsi wzi ciem

informatycznym.

103

In ynieria oprogramowania

Wprowadzenie (103)

Najprostszy system zarz dzania zmianami

$ #

: #

#

%

(

%

# '

(

(

(

(

Je eli przedsi wzi cie jest małe w sensie rozmiaru kodu oprogramowania,
pracochłonno ci jego wytworzenia i liczby zaanga owanych osób, to zarz dzanie

zmian mo e by bardzo proste. Wystarczy, e proponowana przez klienta zmiana

spotka si z akceptacj programistów (mo e te by odwrotnie: stron proponuj c
zmian mog by programi ci, a akceptuj c – klient) .

104

In ynieria oprogramowania

Wprowadzenie (104)

Formalne podej cie do zarz dzania zmianami

X 9

#

Err

<

4 % (

X 9

#

%

#

F

#

$

9

4 %

9

C

X 9

#

Niestety, jest szereg przedsi wzi programistycznych, które wymagaj bardziej
formalnego podej cia do zarz dzania zmianami. Du e firmy, prowadz ce tak du e

przedsi wzi cia, jak budowa elektronicznej centrali telefonicznej, korzystaj do

cz sto z podej cia prezentowanego na slajdzie, gdzie danie zmiany przechodzi
do długi proces od u ytkownika zgłaszaj cego danie zmiany (np. usterk w

oprogramowaniu), poprzez kierownika konfiguracji, programist oceniaj cego - na

polecenie kierownika konfiguracji - ryzyko i koszty wprowadzenia proponowanej
zmiany, specjalny Komitet Zarz dzania Konfiguracj , który podejmuje ostateczn

decyzj w sprawie proponowanej zmiany i Kierownika projektu, który przydziela
jednemu z programistów zadanie wprowadzenia zaproponowanej zmiany do

oprogramowania.

105

In ynieria oprogramowania

Wprowadzenie (105)

Koncepcja systemu zarz dzania konfiguracj

%

#

Załó my teraz, e trzech programistów dostało trzy ró ne zadania modyfikacji tego
samego programu. Poniewa (jak to cz sto bywa) klientowi bardzo si spieszy,

programi ci ci maj pracowa równolegle. Oczywi cie, je eli zaczn oni

bezpo rednio i do chaotycznie manipulowa kodem programu, to nic dobrego z
tego nie wyniknie.

106

In ynieria oprogramowania

Wprowadzenie (106)

Koncepcja systemu zarz dzania konfiguracj

%

#

Aby temu zaradzi korzysta si z systemów zarz dzania konfiguracj , które chroni
oprogramowanie przed chaotycznymi modyfikacjami i umo liwiaj współbie ne

modyfikowanie ró nych składników oprogramowania w sposób kontrolowany.

107

In ynieria oprogramowania

Wprowadzenie (107)

Wykład nt. zarz dzania konfiguracj

#

= U

;

8

9

4 %

9

$

%

4

# % :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

$

9

4 %

9

W trakcie wykładu omówiony zostanie jeden z najbardziej popularnych systemów
zarz dzania konfiguracj zwany CVS. Przedstawiona tak e zostanie struktura

plików projektu oraz wzorce zarz dzania konfiguracj .

108

In ynieria oprogramowania

Wprowadzenie (108)

Plan wykładu

$

%

4

#

% :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

Kolejne dwa wykłady b d po wi cone testowaniu oprogramowania.

109

In ynieria oprogramowania

Wprowadzenie (109)

Testowanie oprogramowania

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

Testowanie ma cisły zwi zek z weryfikacj , a tak e z walidacj oprogramowania i
dostarcza danych, które mog by wykorzystane do okre lenia niezawodno ci

oprogramowania.

110

In ynieria oprogramowania

Wprowadzenie (110)

Czym jest testowanie?

,

$

$

"

$

#

- ,

-

,. -

-

/

6 1 ;

F 6

5

W literaturze mo na znale wiele definicji testowania. Zgodnie z okre leniem
zawartym w jednej z ksi ek Roberta Bindera, testowanie oprogramowania jest to

wykonanie kodu dla kombinacji danych wej ciowych i wewn trznych stanów

systemu w celu wykrycia bł dów. Warto zwróci uwag , na ostatni cz

zdania –

„w celu wykrycia bł dów”. Wynika z tego jasno, e celem testowania nie jest

pokazanie, e w oprogramowaniu nie ma bł dów – wr cz przeciwnie; w testowaniu

chodzi o to by wykry jak najwi cej bł dów. Im wi cej bł dów si wykryje tym
sprawniejszy jest proces testowania, ale te tym gorzej to wiadczy o procesie

tworzenia kodu.

111

In ynieria oprogramowania

Wprowadzenie (111)

Wykłady nt. testowania

8

.

#

;

$

%

4

# % :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

0

%

#

B d dwa wykłady na temat testowania. Pierwszy z nich b dzie wprowadzeniem w
problematyk testowania, natomiast w ramach drugiego wykładu przedyskutowane

zostanie – bardzo wa ne z praktycznego punktu widzenia – zagadnienie

automatyzacji wykonywania testów.

112

In ynieria oprogramowania

Wprowadzenie (112)

Plan wykładu

$

%

4

#

% :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

Przedostatni wykład b dzie po wi cony bardzo gło nej ostatnio metodyce
programowania zwanej Programowaniem Ekstremalnym (po angielsku

Extreme

Programming

).

113

In ynieria oprogramowania

Wprowadzenie (113)

Programowanie Ekstremalne

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

Programowanie Ekstremalne jest to zestaw praktyk dotycz cych m.in. specyfikacji
wymaga , weryfikacji i walidacji, ewolucji kodu, ró nych procesów zwi zanych z

rozwojem oprogramowania a tak e z zarz dzaniem przedsi wzi ciem

programistycznym.

114

In ynieria oprogramowania

Wprowadzenie (114)

Kryzys oprogramowania

#

;

6

%

' /

Kryzys oprogramowania po raz pierwszy pojawił si w latach 60-tych ubiegłego
wieku. Zaobserwowano wówczas główne zagro enia czyhaj ce na miałków

chc cych w sposób komercyjny zajmowa si wytwarzaniem oprogramowania.

Okazało si , e w bardzo wielu przedsi wzi ciach programistycznych dochodzi do
przekroczenia terminu i bud etu, programi ci s ró nymi metodami zach cani do

pracy w nadgodzinach, co ujemnie si odbija na ich yciu prywatnym, a na dodatek

jako powstaj cego oprogramowania jest kiepska i nie satysfakcjonuje
u ytkowników ko cowych.

115

In ynieria oprogramowania

Wprowadzenie (115)

Reakcja na kryzys oprogramowania

Pierwsz reakcj na kryzys oprogramowania było wprowadzenie dyscypliny do
przedsi wzi informatycznych. Wierzono, e poprzez wprowadzenie formalnych

procesów i ustandaryzowanej dokumentacji uda si zwalczy kryzys

oprogramowania. W rezultacie powstały metodyki przypominaj ce wspaniałe
katedry gotyckie: budziły szacunek i podziw dla kunsztu ich twórców, jednak na co

dzie mało kto z nich korzystał. Głównym winowajc były zmiany. W niektórych

przedsi wzi ciach zmiany s tak cz ste, e klasyczne metodyki okazuj si zbyt
ci kie, by mo na było za tymi zmianami nad y . W miar upływu lat zacz to

zdawa sobie spraw , e potrzeba czego l ejszego.

116

In ynieria oprogramowania

Wprowadzenie (116)

Lekkie metodyki tworzenia oprogramowania

W połowie lat 90-tych zacz ły si pojawia tzw. lekkie metodyki oprogramowania,
które były bardziej zorientowane na nad anie za zmianami ni kurczowe trzymanie

si planu. Jedn z nich jest Programowanie Ekstremalne.

117

In ynieria oprogramowania

Wprowadzenie (117)

Główne zalety Programowania Ekstremalnego

#

(

4

Q

X

%

B

0

6 1 B

W Programowaniu Ekstremalnym najwa niejsza jest komunikacja ustna.
Jedyne artefakty, jakie musz powstawa zostały ograniczone do kodu

programu i testów. Ponadto Programowanie Ekstremalne poci ga obietnic

braku nadgodzin. Nic dziwnego, e wielu ludziom taka propozycja wydaje si
bardzo atrakcyjna. Jednak bardzo wiele osób zapomina, e Programowanie

Ekstremalne ma równie szereg konkretnych wymaga maj cych posta
praktyk, które musz by stosowane, aby przedsi wzi cie zako czyło si

sukcesem. O tych praktykach b dzie mowa w trakcie wykładu po wi conego

Programowaniu Ekstremalnemu.

118

In ynieria oprogramowania

Wprowadzenie (118)

Plan wykładu

$

%

4

#

% :

'

4

;

1

<

4 #

8
$

9

4 %

9

0

%

#

%

#

#

%

#

Ostatni wykład b dzie po wi cony ewolucji oprogramowania.

119

In ynieria oprogramowania

Wprowadzenie (119)

Ewolucja oprogramowania

)(3

%

#

E(

#

D(F

;

9

#

W

H (

1 %

G (

1 %

%

#

+ (F 4

%

#

W trakcie wykładu zostan omówione przyczyny ewolucji oprogramowania,
prawa Lehmana, rozwój j dra systemu Linux, który jest zaprzeczeniem praw

Lehmana, czynniki wpływaj ce na koszt piel gnacji oprogramowania, typowy

proces piel gnacji oprogramowania i refaktoryzacja, jako technika obni enia
kosztów piel gnacji.

120

In ynieria oprogramowania

Wprowadzenie (120)

Plan wykładu

#

Czas na podsumowanie wykładu.

121

In ynieria oprogramowania

Wprowadzenie (121)

In ynieria oprogramowania

8

#

%

8

$

9

1

. 7

(4 #

(

#

(

W trakcie tego wykładu spojrzeli my z lotu ptaka na rozpoczynaj cy si cykl
wykładów na temat in ynierii oprogramowania. Z przedstawionej prezentacji wynika,

e b d omówione wszystkie obowi zkowe jednostki wiedzy oprócz programowania

za pomoc API, a ponadto b dzie tak e jeden wykład po wi cony metodom
formalnym. Dyskusja zagadnie dotycz cych in ynierii oprogramowania, któr

wła nie zacz li my, b dzie kontynuowana w ramach przedmiotu obieralnego pt.
„Zaawansowana in ynieria oprogramowania”.

122

In ynieria oprogramowania

Wprowadzenie (122)

Dzi kuj za uwag . Mam nadziej , e mimo wysokiego poziomu abstrakcji i
pobie no ci prezentacji par istotnych szczegółów dotycz cych in ynierii

oprogramowania udało si Pa stwu dostrzec i ten ogólny obraz pomo e lepiej sobie

przyswoi zagadnienia, o których b dzie mowa na kolejnych wykładach. Serdecznie
na nie zapraszam.