Wprowadzenie do przedmiotu

Transkrypt

1 Wprowadzenie do przedmiotu! " # Witam Pastwa serdecznie na pierwszym wykładzie dotyczcym inynierii oprogramowania. Dzisiejszy wykład bdzie troch przypominał ogldanie okolicy z lotu ptaka. Z tej perspektywy nie wida wielu, by moe bardzo wanych, szczegółów, ale za to ma si obraz całoci. I ten obraz całoci, w odniesieniu do inynierii oprogramowania, bd si starał w trakcie dzisiejszego wykładu stworzy. 1

2 Definicja $ # % & % & ' % ' & # % # ( Wprowadzenie (2) Zgodnie ze standardowym słownikiem inynierii oprogramowania opracowanym przez IEEE, inynieria oprogramowania jest to zastosowanie systematycznego, zdyscyplinowanego, ilociowego podejcia do rozwoju, eksploatacji i utrzymania oprogramowania. 2

3 Definicja $ # % & % & ' % ' & # % # ( Wprowadzenie (3) Krótko mówic, jest to zastosowanie inynierskiego podejcia do oprogramowania. Taka definicja jest krótka (i to jest jej zalet), ale niestety nie wyjania zbyt szczegółowo, co wchodzi w zakres inynierii oprogramowania. 3

4 Computing Curricula 2001 Wprowadzenie (4) Okreleniem zakresu wiedzy dotyczcej rónych obszarów informatyki, w tym równie inynierii oprogramowania, od wielu lat zajmuj si wspólnie dwa, najwiksze 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 tysica członków). Wydaj wysokiej rangi czasopisma naukowe, organizuj liczne i bardzo wane konferencje oraz zawody dla studentów takie, jak IEEE Computer Society International Design Competition i ACM International Collegiate Programming Contest. 4

5 Computing Curricula 2001 )* - - )* +, Wprowadzenie (5) Pierwsze rekomendacje dotyczce studiów informatycznych powstały pod auspicjami ACM w 1968 roku. IEEE Computer Society opracowało swoje rekomendacje po raz pierwszy w 1977 roku. 5

6 Computing Curricula 2001 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 Dziesi lat póniej powstała nowa wersja zwana Computing Curricula

7 Computing Curricula 2001 % #. % # ' /. ( # # 0 % 1 % # % # ( # 2# 3 4 # % 5 6 # 7 % # 6 Wprowadzenie (7) Inynieria oprogramowania jest jednym z czternastu obszarów informatyki wyodrbnionych w tym dokumencie. 7

8 Inynieria oprogramowania 6 % 8 # % 8 $ (4# # ( ( Wprowadzenie (8) W ramach inynierii oprogramowania jest osiem jednostek wiedzy o charakterze obligatoryjnym (czyli ka dy informatyk musi to wiedzie) i cztery opcjonalne. 8

9 Inynieria oprogramowania 8 # % 8 $ (4# # ( ( Wprowadzenie (9) Wród obowizkowych jednostek wiedzy mamy dwie dotyczce czynnoci poprzedzajcych samo kodowanie programu. Jest to specyfikacja wymaga, czyli ustalenie co budowany system ma robi i projektowanie oprogramowania, czyli w duym uproszczeniu zaproponowanie jego struktury. 9

10 Inynieria oprogramowania 8 # % 8 $ (4# # ( ( Wprowadzenie (10) Kolejne dwie jednostki dotycz walidacji i weryfikacji oprogramowania (czyli, inaczej mówic, kontroli jakoci) i jego ewolucji, czyli utrzymania uytecznoci programu i umiejtnego wprowadzania do niego koniecznych zmian. 10

11 Inynieria oprogramowania 8 # % 8 $ (4# # ( ( Wprowadzenie (11) Inynieria 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 przedsiwzi programistycznych) i zarzdzanie przedsiwziciami programistycznymi. 11

12 Inynieria oprogramowania 8 # % 8 $ (4# # ( ( Wprowadzenie (12) Ostatnie dwie obowizkowe jednostki wiedzy dotycz narzdzi i rodowisk programistycznych oraz interfejsów programistycznych w skrócie API od ang. Application Programming Interface. 12

13 Inynieria oprogramowania 8 # % 8 $ (4# # ( ( Wprowadzenie (13) Wród jednostek opcjonalnych s metody formalne (czyli o charakterze matematycznym), systemy specjalne (np. systemy czasu rzeczywistego sterujce prac elektrowni, czy lotem samolotu), komponenty programistyczne i zagadnienia dot. niezawodnoci oprogramowania. 13

14 Inynieria oprogramowania 8 # % 8 $ (4# # ( ( Wprowadzenie (14) Polski standard kształcenia dla kierunku Informatyka, przyjty przez Rad Główn Szkolnictwa Wyszego w czerwcu 2006 roku, obejmuje osiem jednostek wiedzy, które według Computing Curricula 2001 maj charakter obligatoryjny. 14

15 Inynieria oprogramowania 8 # % 8 $ (4# # ( ( Wprowadzenie (15) W ramach tego przedmiotu skoncentrujemy si na pierwszych szeciu obszarach, natomiast narzdzia, jak i API bd omawiane w ramach innych przedmiotów. Na przykład takie narzdzia jak kompilatory rónych jzyków programowania bd omawiane przy okazji prezentowania paradygmatów programowania, na których te jzyki si opieraj. W ramach inynierii oprogramowania bdziemy prezentowa tylko narzdzia wspomagajce dotyczce takich zagadnie, jak zarzdzanie konfiguracj, tworzenie modeli w jzyku UML, czy testowanie. Z kolei API bd prezentowane na przedmiotach zwizanych z rónymi obszarami informatyki. Na przykład API dotyczce wybranego systemu operacyjnego bdzie prezentowane w ramach zaj z systemów operacyjnych, API zwizane z pakietami graficznymi na przedmiocie dotyczcym grafiki komputerowej itd. 15

16 Plan wykładu $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # Wprowadzenie (16) W dalszej czci wykładu chciałbym krótko omówi tematyk kolejnych wykładów, jakie nas czekaj w ramach tego przedmiotu. 16

17 Plan wykładu $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # Wprowadzenie (17) Zaczniemy od zasad skutecznego działania. 17

18 Pracodawcy si skar # / & # 9 % & 6 # # 1 ' % % Wprowadzenie (18) Szefowie amerykaskich firm informatycznych skar si, e absolwenci amerykaskich uczelni nie potrafi si komunikowa, maj niedostateczne przygotowanie do pracy w zespole i e brak im umiejtnoci skutecznego i produktywnego zarzdzania ich prac indywidualn. Prawdopodobnie tego typu zastrzeenia mona by usłysze równie z ust pracodawców polskich. Dlatego zanim zaczniemy prezentowa róne metody i narzdzia inynierii oprogramowania postanowiłem najpierw przedstawi ogólne zasady skutecznego działania, które stanowi podstaw dla szczegółowych rozwiza i bez rozumienia których trudno oczekiwa satysfakcjonujcych efektów. 18

19 Zasady Covey ego = > 8? 1 - ; % A Wprowadzenie (19) Zasady te bd oparte na słynnej ksice Stephena Covey ego 7 nawyków skutecznego działania. Na slajdzie widzimy okładk do jej wersji dwikowej. Ksika ta została równie wydana w jzyku polskim. 19

20 Zasady Covey ego 8 ; ' / ' / = > $ ' / Wprowadzenie (20) Ogólnie mówic, Stephen Covey proponuje swoim czytelnikom rozwój osobowoci od stanu zalenoci od innych osób, poprzez niezaleno od innych do współzalenoci z innymi osobami. 20

21 # B 0 = 6 B Zasady Covey ego 8 ; ' / ' / $ ' / Wprowadzenie (21) Zaleno od innych osób przejawia si nadmiern tendencj do obarczania tych innych zadaniem opieki nad sob. Osoby zalene 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 (jeli kiedykolwiek) prowadzi do skutecznego działania. 21

22 C # 1 B 1 B Zasady Covey ego 8 ; ' / ' / $ ' / Wprowadzenie (22) Niezaleno to wiara we własne siły i zaufanie do siebie. Osoby niezalene s przekonane, e angaujc własn energi, zdolnoci i emocje s w stanie osign wiele, bardzo wiele. 22

23 Zasady Covey ego 8 ; ' / D. 6 6 E $ # 9 % 1 ) 5 9? ' / $ ' / Wprowadzenie (23) Aby przej od zalenoci do niezalenoci Stephen Covey proponuje wdroenie w swoim yciu trzech zasad: trzeba by proaktywnym, trzeba zaczyna majc zawsze koniec (czyli skutki swoich działa) na wzgldzie i trzeba tak zarzdza czasem, aby rzeczy pierwsze w sensie wanoci 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 wdroy, aby stały si naszymi nawykami. 23

24 Zasady Covey ego F # # 1 B 5 1 ( 8 ; ' / ' / $ ' / Wprowadzenie (24) Wyszym stopniem rozwoju osobowoci od niezalenoci jest współzaleno. Współzaleno pozwala osign rzeczy, które byłyby dla pojedynczej osoby nie do osignicia. Jest to przekonanie, e razem moemy wicej. 24

25 Zasady Covey ego + C 6 % 1 G 1 # / H ' 6 ; ' 8 ; ' / ' / $ ' / Wprowadzenie (25) Rozwój polegajcy na przejciu od niezalenoci do współzalenoci opiera si na kolejnych trzech zasadach, które naley wdroy: trzeba myle o obopólnej korzyci, 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. 25

26 Zasady Covey ego 1 + C 6 % 1 G 1 # / H ' 6 ; ' D. 6 6 E $ # 9 % 1 ) 5 9? 8 ; ' / ' / $ ' / Wprowadzenie (26) Do tego dochodzi jeszcze jedna, siódma zasada: ostrz pił, czyli dbaj o cigłe doskonalenia. 26

27 Zasady Covey ego 1 + C 6 % 1 G 1 # / H ' 6 ; ' D. 6 6 E $ # 9 % 1 ) 5 9? Wprowadzenie (27) O tych siedmiu zasadach bdzie mowa na nastpnym wykładzie. Kada z tych zasad skutecznego działania zostanie do dokładnie przedstawiona. Jednak ostateczny efekt bdzie zaleał od tego, w jakim stopniu słuchacze zdecyduj si przeku te zasady w swoje nawyki. 27

28 Plan wykładu $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # Wprowadzenie (28) Tematem nastpnego wykładu bdzie specyfikacja wymaga. 28

29 Specyfikacja wymaga 8 # % 8 $ (4# # ( ( Wprowadzenie (29) Wykład ten bdzie wprost nawizywał do jednostki wiedzy specyfikacja wymaga. 29

30 Cykl ycia 8 # % 8 Wprowadzenie (30) Inynierskie podejcie do wytworzenia jakiego produktu opiera si zazwyczaj na cyklu ycia obejmujcym przynajmniej trzy fazy: zebranie wymaga, opracowanie projektu i wykonanie produktu. 30

31 Cykl ycia 8 # % 8 Wprowadzenie (31) Jeli, na przykład, kto myli o przedsiwziciu budowlanym, to najpierw trzeba zebra wymagania inwestora dotyczce funkcji, jakie budynek ma pełni i trzeba uwzgldni ograniczenia sformułowane w warunkach zabudowy. 31

32 Cykl ycia 8 # % 8 Wprowadzenie (32) W nastpnej fazie powstaje projekt architektoniczny, który pokazuje, jak zebrane wymagania i nałoone ograniczenia maj by spełnione. 32

33 Cykl ycia 8 # % 8 Wprowadzenie (33) I wreszcie dochodzi do fazy wykonania, dla której punktem wyjcia jest projekt opracowany na podstawie wymaga. 33

34 Cykl ycia 8 # % 8 Wprowadzenie (34) Podobnie powinno by z przedsiwziciem programistycznym. Na pocztku naley zebra wymagania dotyczce systemu, który ma by zbudowany. 34

35 Cykl ycia 8 # % 8!! " # $ "!% & '! ( )* ( +, Wprowadzenie (35) Majc wymagania mona przej do opracowania projektu systemu. Na slajdzie widoczny jest projekt systemu informatycznego przedstawiony w jzyku UML. 35

36 Cykl ycia 8 # % 8!! " # $ "!% & '! ( )* ( +, Wprowadzenie (36) W oparciu o projekt programici tworz kod systemu. Oczywicie, potem naley jeszcze sprawdzi, czy system nie zawiera defektów i czy spełnia wymagania, o które chodziło klientowi. 36

37 Inynieria wymaga 8 # % Wprowadzenie (37) Samo zbieranie i opracowanie wymaga jest tak wanym i trudnym procesem, e mówi si wrcz o inynierii wymaga. Rozumie si przez to fragment inynierii oprogramowania odpowiedzialny za wymagania. 37

38 Inynieria wymaga 8 # % 6 # 9 $ 6 # % :. # % : % # % : Wprowadzenie (38) Proces zbierania i opracowywania wymaga ma najczciej charakter cykliczny. 38

39 Inynieria wymaga 8 # % 6 # 9 $ 6 # % :. # % : % # % : Wprowadzenie (39) Powinien by poprzedzony sformułowaniem problemu (lub problemów), które budowany system informatyczny ma rozwiza i nakreleniem bardzo ogólnej wizji rozwizania. 39

40 Inynieria wymaga 8 # % 6 # 9 $ 6 # % :. # % : % # % : Wprowadzenie (40) Zasadnicza cz procesu zbierania i opracowywania wymaga składa si z trzech faz. Pierwsz faz powinno by zbieranie wymaga. Czsto wymagania pochodz od wielu rónych osób i na dodatek naley uwzgldnia ograniczenia wynikajce np. z ró n ych przepisów prawa. 40

41 Inynieria wymaga 8 # % 6 # 9 $ 6 # % :. # % : % # % : Wprowadzenie (41) Drug faz powinna by analiza wymaga. Wymagania mog by wzajemnie sprzeczne, niejednoznaczne itp. im wczeniej si takie wady wykryje tym lepiej dla całego przedsiwzicia. 41

42 Inynieria wymaga 8 # % 6 # 9 $ 6 # % :. # % : % # % : Wprowadzenie (42) Po analizie wymaga potrzebna jest ich negocjacja. Wykryte defekty, takie jak np. sprzecznoci midzy wymaganiami, naley usun. Zazwyczaj wymaga to negocjacji z wieloma zainteresowanymi osobami i moe by bardzo trudne. Jeli osoby odpowiedzialne za przedsiwzicie uznaj, e wymagania maj ju odpowiedni jako i mona na ich podstawie przej do pracy nad projektem, to proces zbierania i analizy wymaga mona zakoczy. 42

43 Inynieria wymaga 8 # % 8 # % 4 8 # % 4 Wprowadzenie (43) Generalnie wymagania mona podzieli na funkcjonalne i pozafunkcjonalne. Wymagania funkcjonalne opisuj funkcje, jakie ma realizowa system. Przykładem moe by wymaganie, aby budowany system ksigarni internetowej automatycznie wysyłał do wydawcy zamówienia na te tytuły, których liczba w magazynie spadnie poniej 20 sztuk. Wymagania pozafunkcjonalne dotycz takich aspektów, jak wydajno (np. szybko wykonania poszczególnych operacji), czy niezawodno. 43

44 Wykład nt. specyfikacji wymaga $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # C 6 Wprowadzenie (44) W trakcie wykładu powiconego specyfikacji wymaga przedstawiona zostanie metoda specyfikacji wymaga funkcjonalnych zwana przypadkami uycia. Metoda ta staje si coraz bardziej popularna, równie w polskich firmach informatycznych. Zaprezentowane zostan take dobre praktyki dotyczce dokumentu specyfikacji wymaga, zbierania wymaga, ich analizy i negocjacji oraz opisywania wymaga. Ta problematyka zostanie rozwinita w ramach przedmiotu obieralnego Zaawansowana inynieria oprogramowania. 44

45 Plan wykładu $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # Wprowadzenie (45) Kolejny wykład bdzie powicony kontroli jakoci artefaktów. 45

46 Kontrola jakoci artefaktów 8 # % 8 $ (4# # ( ( Wprowadzenie (46) Jest on bezporednio zwizany z jednostk wiedzy dotyczc walidacji. Zagadnienia te nabieraj szczególnego znaczenia w przypadku budowy tzw. systemów krytycznych, czyli systemów, których awaria moe doprowadzi do utraty zdrowia, a nawet ycia ludzkiego lub spowodowa ogromne straty materialne. 46

47 Artefakty 4 # % : 0 % # 1 Wprowadzenie (47) W trakcie pracy nad systemem informatycznym powstaje cały szereg rónego typu artefaktów: specyfikacja wymaga, testy akceptacyjne, kod programu, podrcznik uytkownika i wiele innych. Oczywicie, musz to by produkty dobrej jakoci nie mog zawiera powanych defektów. 47

48 Artefakty 4 # % : 0 % # 1 Wprowadzenie (48) Dlatego potrzebna jest kontrola jakoci tych artefaktów. 48

49 Kontrola jakoci specyfikacji wymaga 6 # 9 $ 6 # % :. # % : % # % : Wprowadzenie (49) Wiele osób myli o kontroli jakoci, jako ostatniej fazie pracy nad jakim artefaktem. Nie jest to, ogólnie rzecz biorc, najlepsze podejcie. Omawiajc proces zbierania i analizy wymaga przedstawiłem iteracyjny cykl ycia, w którym analiza wymaga i zwizana z ni kontrola jakoci tych wymaga s wykonywane wielokrotnie. 49

50 Rodzaje kontroli jakoci 0 % 9 Wprowadzenie (50) W praktyce kontrola jakoci najczciej przyjmuje posta testowania lub przegldów. Testowanie mona wykona tylko w odniesieniu do działajcego systemu lub jego prototypu. Przegldy s bardziej ogólne: mona je stosowa zarówno do kodu, jak i do specyfikacji wymaga. Istot przegldu jest analiza artefaktów. Analiza ta moe by przeprowadzona przez pojedyncz osob (nazywamy to recenzj) lub te przez zespół osób (najpopularniejszym przykładem tego typu przegldów s inspekcje). 50

51 Wykład nt. kontroli jakoci $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # ' / 7 6 4; Wprowadzenie (51) W trakcie wykładu powiconego kontroli jakoci artefaktów przedstawi krótko najwaniejsze pojcia dotyczce jakoci i testowania, zaprezentuj sposób przeprowadzania inspekcji zgodny ze standardem IEEE 1028 i poka, jak mona oszacowa liczb defektów, jakie zakradły si do artefaktu (łcznie z tymi, które nie zostały w trakcie kontroli jakoci wykryte). 51

52 Plan wykładu $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # Wprowadzenie (52) Kolejny wykład bdzie powicony jzykowi UML. 52

53 Jzyk UML 8 # % 8 $ (4# # ( ( Wprowadzenie (53) UML jest wykorzystywany m.in. przy projektowaniu systemów informatycznych. Jest te wiele narzdzi komercyjnych i darmowych wspomagajcych tworzenie modeli w jzyku UML (wród narzdzi komercyjnych du popularnoci cieszy si Rational Rose, a jednym z bardziej popularnych darmowych narzdzi jest ArgoUML). 53

54 Wprowadzenie (54) UML jest stosunkowo nowym jzykiem. Jego pierwsza wersja została zaakceptowana w 1997 roku. Na slajdzie jest pokazana strona internetowa dotyczca jzyka UML, która jest utrzymywana przez midzynarodow organizacj OMG zatwierdzajc kolejne wersje tego jzyka. Osoby znajce jzyk angielski znajd na tej stronie wiele cennych informacji na temat jzyka UML. 54

55 Diagramy UML C % # ; C % # ; C % # C % # ' C % # ( ( ( Wprowadzenie (55) Jzyk 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 jzyka UML przedstawione zostan bardzo proste przykłady diagramu stanów, diagramu przypadków uycia i diagramu sekwencji. Zarówno te wymienione diagramy, jak i pozostałe zostan bardziej szczegółowo omówione w trakcie wykładu powiconego jzykowi UML. 55

56 Diagram stanów I$ I$ 1 $ 4 I$ % ' 1 I$ ' 6 Wprowadzenie (56) Pierwszym diagramem, który chciałbym pokaza jest diagram stanów. Na slajdzie widzimy diagram pokazujcy przeistaczanie si maturzysty w studenta za chwil dokładniej go omówimy. 56

57 Diagram stanów Wprowadzenie (57) Kluczowym elementem na diagramach stanów s oczywicie stany. Stan jest reprezentowany za pomoc owalu z nazw stanu w rodku. 57

58 Diagram stanów ' Wprowadzenie (58) Midzy stanami s przejcia reprezentowane za pomoc strzałki. W przypadku diagramu pokazanego na slajdzie wida, e bdc w stanie Maturzysta mona przej do stanu Kandydat, ale nie odwrotnie. 58

59 Diagram stanów. I$ Wprowadzenie (59) Z przejciem moe by zwizana akcja. W przykładzie pokazanym na slajdzie wida, e przejcie od stanu Maturzysta do stanu Kandydat wie si ze złoeniem podania na studia. 59

60 Diagram stanów < ' $ Wprowadzenie (60) Akcje s poprzedzane znakiem ukonej kreski tym samym, jaki jest wykorzystywany jako symbol dzielenia. 60

61 Diagram stanów 9 I$ Wprowadzenie (61) Pocztek jest zaznaczany małym ciemnym kółkiem. Std zaczyna si chodzenie po stanach. 61

62 Diagram stanów I$ I$ 1 $ 4 I$ % ' 1 I$ ' 6 Wprowadzenie (62) 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łoeniu podania na studia stajemy si kandydatami. Wskutek akcji, czy zdarze nie pokazanych na diagramie Kandydat uzyskuje status Zakwalifikowanego (mona si domyla, e trzeba tutaj pozytywnie przej przez procedur kwalifikacyjn) lub te staje si Nieprzyjty. Po złoeniu podania Zakwalifikowany staje si Przyjtym, a po złoeniu lubowania uzyskuje on upragniony status Studenta. 62

63 Diagram przypadków uycia $ 6 ; $ 4 1 Wprowadzenie (63) Przejdmy teraz do diagramów przypadków uycia. S one wykorzystywane do pokazania kto co moe zrobi. 63

64 Diagram przypadków uycia. Wprowadzenie (64) Jednym z głównych elementów wystpujcych na diagramach przypadków uycia s tzw. aktorzy. Na slajdzie pokazano symbol, jakim si oznacza aktorów w jzyku UML. Aktor jest to rola, jak człowiek lub ewentualnie urzdzenie moe odgrywa w kontakcie z opisywanym systemem informatycznym. 64

65 Diagram przypadków uycia $ 4 1 Wprowadzenie (65) Na slajdzie widzimy trzech aktorów: Maturzyst, Zakwalifikowanego i Nieprzyjtego. 65

66 Diagram przypadków uycia. Wprowadzenie (66) Aktor moe mie do czynienia z przypadkiem uycia opisujcym pewien cel (np. o charakterze biznesowym), który aktor chce osign w kontakcie z systemem informatycznym. Nazwy przypadków uycia zapisuje si w elipsach tak, jak pokazano to na slajdzie. 66

67 Diagram przypadków uycia $ 6 ; $ 4 1 Wprowadzenie (67) Zgodnie z przedstawionym diagramem, Maturzysta moe złoy podanie, natomiast zarówno Zakwalifikowany, jak i Nieprzyjty mog obejrze wyniki rekrutacji. 67

68 Diagram sekwencji # F 1 = 9 J Wprowadzenie (68) Trzecim rodzajem diagramów jzyka UML, jaki chciałbym przedstawi s diagramy sekwencji. Diagramy te słu do ilustrowania komunikacji midzy obiektami. 68

69 6 2) 6 2E Diagram sekwencji 6 6 Wprowadzenie (69) Kady obiekt jest reprezentowany przez prostokt zawierajcy jego nazw i tzw. lini ycia obiektu. 69

70 Diagram sekwencji 6 2) # 6 2E Wprowadzenie (70) Komunikaty przesyłane midzy 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. 70

71 Diagram sekwencji 6 2) # 2) # 2E # 2D 6 2E Wprowadzenie (71) Diagramy sekwencji zazwyczaj zawieraj wicej ni jeden komunikat. Komunikaty s wysyłane w kolejnoci od góry do dołu. Na slajdzie wida trzy komunikaty. Najpierw bdzie wysłany Komunikat-1, potem Komunikat-2 i na kocu Komunikat-3. Tak si złoyło, e wszystkie te komunikaty s wysyłane przez Obiekt-1 i trafiaj do Obiekt-2. 71

72 Diagram sekwencji # F 1 = 9 J Wprowadzenie (72) Diagram pokazany na tym slajdzie opisuje komunikacj midzy trzema obiektami: Maturzyst, Systemem rekrutacji na studia i obiektem o nazwie KReM (chodzi tutaj o Krajowy Rejestr Matur system informatyczny udostpniajcy wyniki matur z Okrgowych Komisji Egzaminacyjnych). Zgodnie z tym diagramem maturzysta chccy dosta si na studia najpierw składa podanie i wprowadza swoje oceny. Nastpnie 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 przyjcia podania i ocen. Teraz maturzysta wnosi opłat rekrutacyjn, a system rekrutacji potwierdza przyjcie tej opłaty. Zalet diagramów sekwencji jest pokazanie jakby z globalnego punktu widzenia (czyli patrzc na wszystkie interesujce nas obiekty), jak wyglda komunikacja midzy obiektami. Pomaga to zrozumie działanie opisywanego systemu i jest to informacja, której nie dostarczaj inne rodzaje diagramów jzyka UML. 72

73 Inynieria oprogramowani a Inynieria oprogramowani a Diagram sekwencji Diagramy jzyka UML # F = 9 J Diagram 1 stanów I$ Inynieria oprogramowani a Diagram przypadków uycia I$ Wprowadzeni e (72) $ 1 $ 4 I$ % ' 1 I$ ' 6 6 ; Wprowadzeni e (62) $ 4 1 Wprowadzeni e (67) Wprowadzenie (73) Jak wida, jzyk UML oferuje rónego rodzaju diagramy, z których kady opisuje inne aspekty systemu. Jak ju wczeniej wspomniano, tych rodzajów diagramów jest wicej i bd one omówione w trakcie wykładu powiconego jzykowi UML. 73

74 Plan wykładu $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # Wprowadzenie (74) Kolejny wykład bdzie dotyczył metod formalnych. 74

75 Metody formalne 8 # % 8 $ (4# # ( ( Wprowadzenie (75) Zgodnie z Computing Curricula 2001, metody formalne s jednostk opcjonaln. Maj one cisły zwizek z walidacj oprogramowania. Niektórzy podchodz do nich sceptycznie, inni upatruj w nich nadziej na istotne podniesienie jakoci tworzonego oprogramowania, jakoci rozumianej jako zgodno implementacji ze specyfikacj. 75

76 1 ( Metody formalne = J # ( % # < 1 ( α β α Wprowadzenie (76) Zasadnicza koncepcja zwizana z metodami formalnymi polega na tym, by wykazywa poprawno programów nie w oparciu o testy czy przegldy, lecz na gruncie matematycznym, poprzez dowodzenie właciwoci programów. 76

77 Silnia K L M & N O P N O )N K BO L M O Q )N O R N S N S Wprowadzenie (77) Spróbujmy udowodni, e przedstawiona na slajdzie funkcja zapisana w jzyku C oblicza warto n!. 77

78 Silnia K L M IRRR F T O P RRRI & N O P N O )N K BO L M O Q )N O R N S N IRRR 0 O O B RRRI S Wprowadzenie (78) Pierwszym krokiem jest zwizanie z t funkcj warunku wstpnego (po angielsku precondition) i kocowego (ang. postcondition). Poniewa parametr n został zadeklarowany jako liczba całkowita, to wystarczy doda jako warunek wstpny, e ma by to liczba nieujemna. Std te umiecilimy w tekcie programu komentarz PRE zawierajcy warunek n >= 0. Warunek kocowy (POST) okrela relacj, jaka ma by prawdziwa na kocu wykonania podprogramu. W przypadku omawianego programu na kocu zmienna s powinna mie warto n!. 78

79 Silnia K L M IRRR F T O P RRRI & N O P N O )N K BO L M O Q )N O R N S N IRRR 0 O O B RRRI S Wprowadzenie (79) No to teraz wystarczy tylko dowie, e jeeli na pocztku wykonania podprogramu n >= 0, to na kocu s bdzie równe n!. Łatwo powiedzie, trudno zrobi. W przypadku naszego programu najtrudniejszym elementem jest ptla while. Dowodzenie poprawnoci programu zawierajcych ptle odbywa si metod niezmienników (ang. invariant). Niezmiennik jest to zdanie, które jest prawdziwe za kadym razem, kiedy powtarzane jest wykonanie instrukcji zawartych w ptli. Dokładnie mówic, niezmiennik powinien by prawdziwy tu przed pierwszym wykonaniem instrukcji zawartych w ptli, tu przed drugim wykonaniem, przed trzecim itd. Zasadniczy problem polega na tym by znale (wymyli) taki niezmiennik, który zawsze bdzie prawdziwy i jednoczenie pomoe nam w udowodnieniu warunku kocowego POST. 79

80 Silnia K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O Q )N O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (80) Nasz podprogram jest bardzo prosty i nietrudno zauway, e niezmiennik (INV) ma posta nastpujcego zdania: s równa si k!. Najpierw udowodnimy, e to zdanie jest faktycznie niezmiennikiem, a potem pokaemy, jak go wykorzysta do udowodnienia warunku kocowego. 80

81 Silnia K L M IRRR F T O P RRRI ) O P B & N O P N O )N IRRR 7 U O O B RRRI K BO L M O Q )N O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (81) Pierwsze wystpienie inwariantu (tu przed wykonaniem instrukcji while) jest prawdziwe, bowiem na mocy definicji funkcji silnia, 0! jest równe 1. 81

82 Silnia K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O Q )N O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (82) Instrukcja k= k+1 jest o tyle kłopotliwa, e wystpuje w niej dwa razy ten sam symbol k i za kadym razem oznacza inn warto. 82

83 Silnia K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O Q )N O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (83) eby usun t niejednoznaczno oznaczmy przez k z podkreleniem pocztkow warto k, jaka była przed wykonaniem tej instrukcji przypisania, a k bez podkrelenia niech oznacza now warto, jaka bdzie po wykonaniu tej instrukcji. 83

84 Silnia O O B K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O Q )N O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (84) Zatem z pierwszego inwariantu wynika, e przed wykonaniem tej instrukcji przypisania mamy s równe k z podkreleniem silnia. 84

85 Silnia O O B K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O O B O O Q ) O Q )N O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (85) Po wykonaniu omawianej instrukcji przypisania dojdzie nam jeszcze zdanie mówice, e nowa warto k jest równa starej wartoci powikszonej o 1. 85

86 Silnia O O B K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O O B O O Q ) O Q )N O O K V )LB O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (86) Czyli po wykonaniu tej instrukcji przypisania bdziemy mieli s równe (k-1)!. 86

87 Silnia K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O Q )N O O K V )LB O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (87) W kolejnej instrukcji przypisania mamy podobn niejednoznaczno, jak poprzednio: dwa razy wystpuje symbol s i za kadym razem oznacza inn warto. 87

88 Silnia K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O Q )N O O K V )LB O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (88) Podobnie jak poprzednio przyjmiemy, e s z podkreleniem oznacza star warto, a s bez podkrelenia now warto zmiennej s. 88

89 Silnia O O K V )LB K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O Q )N O O K V )LB O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (89) Zatem na mocy poprzednio dowiedzionego faktu mona powiedzie, e tu przed wykonaniem tej instrukcji przypisania stara warto s jest równa (k-1)!. 89

90 Silnia O O K V )LB K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O O K V )LB O O R O Q )N O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (90) Po wykonaniu tej instrukcji bdzie mona dopisa do poprzedniego zdania jeszcze jedno: nowa warto s jest równa starej pomnoonej przez k. 90

91 Silnia O O K V )LB K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O O K V )LB O O R O Q )N O O K V )LB R O O B O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (91) Jeeli zastpimy star warto s przez (k 1)!, to okae si, e nowa warto s jest równa k!. 91

92 Silnia K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O Q )N O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (92) I w ten sposób dowiedlimy, e jeeli na pocztku wykonania instrukcji while prawd jest, e s jest równe k!, to po wykonaniu obu instrukcji przypisania nadal s bdzie równe k!. Zatem faktycznie jest to niezmiennik tej ptli. 92

93 Silnia O O K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O Q )N O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (93) Aby dowie prawdziwo warunku kocowego (POST) wystarczy zauway, e zaraz po wykonaniu instrukcji while prawdziwy jest inwariant s jest równe k! oraz prawdziwe jest zaprzeczenie warunku wystpujcego w instrukcji while, czyli k jest równe n. 93

94 Silnia O O K L M IRRR F T O P RRRI & N O P N O )N IRRR 7 U O O B RRRI K BO L M O Q )N O R N IRRR 7 U O O B RRRI S N IRRR 0 O O B RRRI S Wprowadzenie (94) Podstawiajc niezmiennik n w miejsce k dostajemy warunek kocowy i w ten sposób koczy si dowód poprawnoci tego podprogramu. 94

95 Dowodzenie poprawnoci programów G P P P = 4 - P P P = % # 8 4% % F 4 Wprowadzenie (95) Do lat 90-tych dowodzenie poprawnoci programów odbywało si jedynie dla bardzo krótkich programów. W cigu ostatniej dekady nastpił istotny postp i powstały bardzo efektywne weryfikatory. Jednake dowodzenie poprawnoci 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 poprawnoci programu zawierajcego ok. 7 tys. wierszy wymagało pracochłonnoci około 2 osobolat, a sama specyfikacja formalna miała ok. 5 tys. wierszy tekstu. Jak wic wida, formalna specyfikacja programów moe by bardzo obszerna i jej wytworzenie oraz sprawdzenie jej poprawnoci jest zadaniem samym w sobie. 95

96 Wykład nt. metod formalnych $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # 4 # 7# # % Wprowadzenie (96) W trakcie wykładu dotyczcego metod formalnych omówi tzw. specyfikacje aksjomatyczne i zwizane z nimi implementacje niestandardowe, majce charakter anomalii. Przedstawi te sieci Petriego jako chyba najbardziej popularne narzdzie modelowania oprogramowania. Jest to notacja matematyczna o charakterze graficznym wykorzystywana do modelowania nie tylko systemów informatycznych, ale take np. systemów transportowych. 96

97 Plan wykładu $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # Wprowadzenie (97) Kolejny wykład bdzie powicony wzorcom projektowym. 97

98 Wzorce projektowe 8 # % 8 $ (4# # ( ( Wprowadzenie (98) Wzorce projektowe s podstaw współczesnego projektowania oprogramowania. 98

99 Wzorce projektowe =. W Wzorzec = Sprawdzona koncepcja, która: opisuje problem powtarzajcy si wielokrotnie w okrelonym kontekcie, działajce na niego siły, oraz podaje istot jego rozwizania w sposób abstrakcyjny. Wprowadzenie (99) Informatyka zawdzicza koncepcj wzorców profesorowi Christopherowi Alexandrowi. Zgodnie z jego koncepcj wzorzec jest to sprawdzona koncepcja, która opisuje problem powtarzajcy si wielokrotnie w okrelonym kontekcie, działajce na niego siły oraz podaje istot rozwizania tego problemu w sposób abstrakcyjny. 99

100 Wykład nt. wzorców projektowych $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # 5 = % ; 8 6 Wprowadzenie (100) W ramach wykładu powiemy o Bandzie Czterech, czyli tych, którzy wprowadzili wzorce do inynierii oprogramowania, omówiony zostanie katalog wzorców projektowych i przedstawione zostan wybrane wzorce projektowe oraz ich zastosowania. 100

101 Plan wykładu $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # Wprowadzenie (101) W cyklu wykładowym powiconym inynierii oprogramowania nie moe zabrakn wykładu dotyczcego zarzdzania konfiguracj. 101

102 Zarzdzanie konfiguracj 8 # % 8 $ (4# # ( ( Wprowadzenie (102) Zmiany w oprogramowaniu i towarzyszca im ewolucja kodu s praktycznie nie do uniknicia. Właciwe zarzdzanie konfiguracj jest podstaw skutecznej ewolucji oprogramowania i jedn z kluczowych praktyk zarzdzania przedsiwziciem informatycznym. 102

103 Najprostszy system zarzdzania zmianami $ # : # # % ( ( ( ( ( % # ' Wprowadzenie (103) Jeeli przedsiwzicie jest małe w sensie rozmiaru kodu oprogramowania, pracochłonnoci jego wytworzenia i liczby zaangaowanych osób, to zarzdzanie zmian moe by bardzo proste. Wystarczy, e proponowana przez klienta zmiana spotka si z akceptacj programistów (moe te by odwrotnie: stron proponujc zmian mog by programici, a akceptujc klient). 103

104 Formalne podejcie do zarzdzania zmianami Err X 9 # < 4% ( X 9 # % # F C X 9 # # $ 9 4% 9 Wprowadzenie (104) Niestety, jest szereg przedsiwzi programistycznych, które wymagaj bardziej formalnego podejcia do zarzdzania zmianami. Due firmy, prowadzce tak due przedsiwzicia, jak budowa elektronicznej centrali telefonicznej, korzystaj do czsto z podejcia prezentowanego na slajdzie, gdzie danie zmiany przechodzi do długi proces od uytkownika zgłaszajcego danie zmiany (np. usterk w oprogramowaniu), poprzez kierownika konfiguracji, programist oceniajcego - na polecenie kierownika konfiguracji - ryzyko i koszty wprowadzenia proponowanej zmiany, specjalny Komitet Zarzdzania 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. 104

105 Koncepcja systemu zarzdzania konfiguracj % # Wprowadzenie (105) Załómy teraz, e trzech programistów dostało trzy róne zadania modyfikacji tego samego programu. Poniewa (jak to czsto bywa) klientowi bardzo si spieszy, programici ci maj pracowa równolegle. Oczywicie, jeeli zaczn oni bezporednio i do chaotycznie manipulowa kodem programu, to nic dobrego z tego nie wyniknie. 105

106 Koncepcja systemu zarzdzania konfiguracj % # Wprowadzenie (106) Aby temu zaradzi korzysta si z systemów zarzdzania konfiguracj, które chroni oprogramowanie przed chaotycznymi modyfikacjami i umoliwiaj współbiene modyfikowanie rónych składników oprogramowania w sposób kontrolowany. 106

107 Wykład nt. zarzdzania konfiguracj $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # # = U ; 8 9 4% 9 Wprowadzenie (107) W trakcie wykładu omówiony zostanie jeden z najbardziej popularnych systemów zarzdzania konfiguracj zwany CVS. Przedstawiona take zostanie struktura plików projektu oraz wzorce zarzdzania konfiguracj. 107

108 Plan wykładu $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # Wprowadzenie (108) Kolejne dwa wykłady bd powicone testowaniu oprogramowania. 108

109 Testowanie oprogramowania 8 # % 8 $ (4# # ( ( Wprowadzenie (109) Testowanie ma cisły zwizek z weryfikacj, a take z walidacj oprogramowania i dostarcza danych, które mog by wykorzystane do okrelenia niezawodnoci oprogramowania. 109

110 Czym jest testowanie?, $ $ " $ # -, -,.- - / 6 1 ; F 6 5 Wprowadzenie (110) W literaturze mona znale wiele definicji testowania. Zgodnie z okreleniem zawartym w jednej z ksiek Roberta Bindera, testowanie oprogramowania jest to wykonanie kodu dla kombinacji danych wejciowych i wewntrznych 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 wrcz przeciwnie; w testowaniu chodzi o to by wykry jak najwicej błdów. Im wicej błdów si wykryje tym sprawniejszy jest proces testowania, ale te tym gorzej to wiadczy o procesie tworzenia kodu. 110

111 Wykłady nt. testowania $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # 8. # ; Wprowadzenie (111) Bd dwa wykłady na temat testowania. Pierwszy z nich bdzie wprowadzeniem w problematyk testowania, natomiast w ramach drugiego wykładu przedyskutowane zostanie bardzo wane z praktycznego punktu widzenia zagadnienie automatyzacji wykonywania testów. 111

112 Plan wykładu $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # Wprowadzenie (112) Przedostatni wykład bdzie powicony bardzo głonej ostatnio metodyce programowania zwanej Programowaniem Ekstremalnym (po angielsku Extreme Programming). 112

113 Programowanie Ekstremalne 8 # % 8 $ (4# # ( ( Wprowadzenie (113) Programowanie Ekstremalne jest to zestaw praktyk dotyczcych m.in. specyfikacji wymaga, weryfikacji i walidacji, ewolucji kodu, rónych procesów zwizanych z rozwojem oprogramowania a take z zarzdzaniem przedsiwziciem programistycznym. 113

114 Kryzys oprogramowania # ; 6 % ' / Wprowadzenie (114) Kryzys oprogramowania po raz pierwszy pojawił si w latach 60-tych ubiegłego wieku. Zaobserwowano wówczas główne zagroenia czyhajce na miałków chccych w sposób komercyjny zajmowa si wytwarzaniem oprogramowania. Okazało si, e w bardzo wielu przedsiwziciach programistycznych dochodzi do przekroczenia terminu i budetu, programici s rónymi metodami zachcani do pracy w nadgodzinach, co ujemnie si odbija na ich yciu prywatnym, a na dodatek jako powstajcego oprogramowania jest kiepska i nie satysfakcjonuje uytkowników kocowych. 114

115 Reakcja na kryzys oprogramowania Wprowadzenie (115) Pierwsz reakcj na kryzys oprogramowania było wprowadzenie dyscypliny do przedsiwzi informatycznych. Wierzono, e poprzez wprowadzenie formalnych procesów i ustandaryzowanej dokumentacji uda si zwalczy kryzys oprogramowania. W rezultacie powstały metodyki przypominajce 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 przedsiwziciach zmiany s tak czste, e klasyczne metodyki okazuj si zbyt cikie, by mona było za tymi zmianami nady. W miar upływu lat zaczto zdawa sobie spraw, e potrzeba czego lejszego. 115

116 Lekkie metodyki tworzenia oprogramowania Wprowadzenie (116) W połowie lat 90-tych zaczły si pojawia tzw. lekkie metodyki oprogramowania, które były bardziej zorientowane na nadanie za zmianami ni kurczowe trzymanie si planu. Jedn z nich jest Programowanie Ekstremalne. 116

117 Główne zalety Programowania Ekstremalnego B # ( 4 Q X % B Wprowadzenie (117) W Programowaniu Ekstremalnym najwaniejsza jest komunikacja ustna. Jedyne artefakty, jakie musz powstawa zostały ograniczone do kodu programu i testów. Ponadto Programowanie Ekstremalne pociga 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 majcych posta praktyk, które musz by stosowane, aby przedsiwzicie zakoczyło si sukcesem. O tych praktykach bdzie mowa w trakcie wykładu powiconego Programowaniu Ekstremalnemu. 117

118 Plan wykładu $ % 4 # % : ' 4; 1 < 4# 8 $ 9 4% 9 0 % # % # # % # Wprowadzenie (118) Ostatni wykład bdzie powicony ewolucji oprogramowania. 118

119 Ewolucja oprogramowania )(3 % # E( # D(F ; 9 # W H ( 1 % G ( 1 % % # + (F 4 % # Wprowadzenie (119) W trakcie wykładu zostan omówione przyczyny ewolucji oprogramowania, prawa Lehmana, rozwój jdra systemu Linux, który jest zaprzeczeniem praw Lehmana, czynniki wpływajce na koszt pielgnacji oprogramowania, typowy proces pielgnacji oprogramowania i refaktoryzacja, jako technika obnienia kosztów pielgnacji. 119

120 Plan wykładu # Wprowadzenie (120) Czas na podsumowanie wykładu. 120

121 Inynieria oprogramowania 8 # % 8 $ (4# # ( ( Wprowadzenie (121) W trakcie tego wykładu spojrzelimy z lotu ptaka na rozpoczynajcy si cykl wykładów na temat inynierii oprogramowania. Z przedstawionej prezentacji wynika, e bd omówione wszystkie obowizkowe jednostki wiedzy oprócz programowania za pomoc API, a ponadto bdzie take jeden wykład powicony metodom formalnym. Dyskusja zagadnie dotyczcych inynierii oprogramowania, któr włanie zaczlimy, bdzie kontynuowana w ramach przedmiotu obieralnego pt. Zaawansowana inynieria oprogramowania. 121

122 Wprowadzenie (122) Dzikuj za uwag. Mam nadziej, e mimo wysokiego poziomu abstrakcji i pobienoci prezentacji par istotnych szczegółów dotyczcych inynierii oprogramowania udało si Pastwu dostrzec i ten ogólny obraz pomoe lepiej sobie przyswoi zagadnienia, o których bdzie mowa na kolejnych wykładach. Serdecznie na nie zapraszam. 122