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.