ynieria oprogramowania wprowadzenie do przedmiotuwazniak.mimuw.edu.pl/images/6/67/io-1-wyk.pdf ·...

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


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


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


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 InternationalCollegiate Programming Contest.

5


Wprowadzenie (5)


)* + ,

)* - -

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


Wprowadzenie (6)


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


Wprowadzenie (7)


� � �� % ��# ��. �% �� # �� ' /. �� (��# �� # ��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


Wprowadzenie (8)


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


Wprowadzenie (9)


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


Wprowadzenie (10)


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


Wprowadzenie (11)


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


Wprowadzenie (12)


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


Wprowadzenie (13)


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


Wprowadzenie (14)


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


Wprowadzenie (15)


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


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


Wprowadzenie (17)

Plan wykładu

� $ �� % �� 4��# �% �:� ��' �� 4��; � � 1 � ��< � �� 4�� # �� 8 � �� $ �� 9 �� 4�% ��9� 0 ��% ��# �� % ��# �� # �� % ��# ��

Zaczniemy od zasad skutecznego działania.

18


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


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


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


Wprowadzenie (21)

Zasady Covey’ego

$ �� ' /

� �� ' /

8 ��; � �� ' /

� ��# ��B0 �� = ��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


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


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


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


Wprowadzenie (25)

Zasady Covey’ego

$ �� ' /

� �� ' /

8 ��; � �� ' /+ C 6 �� % �1G � ��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� osynergi�.

26


Wprowadzenie (26)

Zasady Covey’ego

$ �� ' /

� �� ' /

8 ��; � �� ' /+ C 6 �� % �1G � ��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


Wprowadzenie (27)

Zasady Covey’ego

+ C 6 �� % �1G � ��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


Wprowadzenie (28)

Plan wykładu

� $ �� % �� 4��# �% �:� ��' �� 4��; � � 1 � ��< � �� 4�� # �� 8 � �� $ �� 9 �� 4�% ��9� 0 ��% ��# �� % ��# �� # �� % ��# ��

Tematem nast�pnego wykładu b�dzie specyfikacja wymaga�.

29


Wprowadzenie (29)

Specyfikacja wymaga�

8 �# �% ��

8 ��

�� $ �� 9 ��

� �� 1 �� . 7

� (4��# �� (��

��# �� (

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

30


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


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


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


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


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


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


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


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


Wprowadzenie (38)


8 �# �% ��

$ 6 ��# �% �:

. ��# �% �:

� �% ��# �% �:

��6 ��# �� 9 � ��

Proces zbierania i opracowywania wymaga� ma najcz��ciej charakter cykliczny.

39


Wprowadzenie (39)


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


Wprowadzenie (40)


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


Wprowadzenie (41)


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


Wprowadzenie (42)


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


Wprowadzenie (43)


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


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


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


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


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


Wprowadzenie (48)

Artefakty

� ��4��# �% �:

0 ��

��% ��# �

��1 ��

Dlatego potrzebna jest kontrola jako�ci tych artefaktów.

49


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


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


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


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


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� RationalRose, a jednym z bardziej popularnych darmowych narz�dzi jest ArgoUML).

54


Wprowadzenie (54)

www.uml.org

UML jest stosunkowo nowym j�zykiem. Jego pierwsza wersja zostałazaakceptowana 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


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


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


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


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


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


Wprowadzenie (60)

Diagram stanów

� ��

��

��$ ��

< ��' ��

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

61


Wprowadzenie (61)

Diagram stanów

� ��

��

I$ ��

�� 9 ��

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

62


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


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


Wprowadzenie (64)


. ��

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


Wprowadzenie (65)


� ��

$ ��4 �� 1 ��

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

66


Wprowadzenie (66)


. ��

� � ��

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


Wprowadzenie (67)


� ��

$ ��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


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


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


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


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


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


Wprowadzenie (73)

Diagramy j�zyka UML

In�ynieria oprogramowani a

Wprowadzeni e (67)


� ��

$ �� 4 �� 1 ��

$ ��

� 6 �� ; ��


Wprowadzeni e (62)

Diagram stanów

� � ��1 ��

� ��

��

$ �� 4 ��

� ��

I $ ��

I $ ��

I $ �� % �� '��

I $ �� ' ��6 � ��

� �� 1 ��


Wprowadzeni e (72)

Diagram sekwencji

� �� # �� 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


Wprowadzenie (74)

Plan wykładu

� $ �� % �� 4��# �% �:� ��' �� 4��; � � 1 � ��< � �� 4�� # �� 8 � �� $ �� 9 �� 4�% ��9� 0 ��% ��# �� % ��# �� # �� % ��# ��

Kolejny wykład b�dzie dotyczył metod formalnych.

75


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


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


Wprowadzenie (77)

Silnia

�� K�� LM

�� &�N�O P N�O )N� �� K�BO �LM

�O �Q )N�O �R �NS

�� NS

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

78


Wprowadzenie (78)

Silnia

�� K�� LMIR R R F � �T O P R R R I

�� &�N�O P N�O )N� �� K�BO �LM


�� NIR R R � � 0 �O O �BR R R IS

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


Wprowadzenie (79)

Silnia


�� &�N�O P N�O )N� �� K�BO �LM



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


Wprowadzenie (80)

Silnia


�� &�N�O P N�O )NIR R R 7� U �O O �BR R R I� �� K�BO �LM

�O �Q )N�O �R �NIR R R 7� U �O O �BR R R IS


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


Wprowadzenie (81)

Silnia





)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


Wprowadzenie (82)

Silnia





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


Wprowadzenie (83)

Silnia



�O � Q )N�O �R �NIR R R 7� U �O O �BR R R IS


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


Wprowadzenie (84)

Silnia





�O O �B

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

85


Wprowadzenie (85)

Silnia





�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


Wprowadzenie (86)

Silnia





�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


Wprowadzenie (87)

Silnia





�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


Wprowadzenie (88)

Silnia



�O �Q )N�O � R �NIR R R 7� U �O O �BR R R IS


�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


Wprowadzenie (89)

Silnia





�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


Wprowadzenie (90)

Silnia





� 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


Wprowadzenie (91)

Silnia





� O O K�V )LB∧∧∧∧ �O O � R �� O O K�V )LBR �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


Wprowadzenie (92)

Silnia





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


Wprowadzenie (93)

Silnia





�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


Wprowadzenie (94)

Silnia





�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


Wprowadzenie (95)

Dowodzenie poprawno�ci programów

8 ��4% ��% F ��4

��% ��#� ��4��

-PP

P��

=

GPP

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


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


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


Wprowadzenie (98)

Wzorce projektowe

8 �# �% ��

8 ��

�� $ �� 9 ��

� �� 1 �� . 7

� (4��# �� (��

��# �� (

Wzorce projektowe s� podstaw� współczesnego projektowania oprogramowania.

99


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 ChristopherowiAlexandrowi. 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


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


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


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


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


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


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


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


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


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


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


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


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


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 ExtremeProgramming).

113


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


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


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


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


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


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


Wprowadzenie (119)

Ewolucja oprogramowania

)(3 �� % ��# ��E( �� # ��D(F �� ; ��9 ��# �� WH (�� 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


Wprowadzenie (120)

Plan wykładu

��# ��

Czas na podsumowanie wykładu.

121


Wprowadzenie (121)


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


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.

ynieria oprogramowania wprowadzenie do przedmiotuwazniak.mimuw.edu.pl/images/6/67/io-1-wyk.pdf ·...

Documents