Inynieria oprogramowania

Transkrypt

1 Inynieria oprogramowania

2 Wstp Inynieria oprogramowania (software engineering), wiedza i umiejtno przydatna do budowy programów, szczególnie duych systemów oprogramowania. Obejmuje tworzenie specyfikacji, metody programowania, aspekty uruchamiania i testowania oraz opracowywanie dokumentacji. Odrbnymi dzia$ami inynierii oprogramowania s% dowodzenie poprawnoci programów oraz zagadnienia przenonoci. Znajomo inynierii oprogramowania pomaga w wydajnym konstruowaniu niezawodnego oprogramowania, take w sposób automatyczny. 2

3 Wstp Dziaania skadajce si na inynieri oprogramowania: specyfikowanie, tworzenie, zarz%dzanie, rozwijanie systemów komputerowych. System komputerowy sk$ada si z programów, plików konfiguracyjnych, dokumentacji systemowej, dokumentacji uytkownika. 3

4 Wstp Istniej dwa rodzaje produktów programowych: powszechne, dostosowane. Inynieria systemów komputerowych obejmuje wszystkie aspekty wytwarzania i ewolucji systemów komputerowych w których oprogramowanie odgrywa g$ówn% rol: tworzenie oprogramowania, opracowywanie strategii, projektowanie procesu wytwarzania, wdroenie systemu, inynieri oprogramowania. 4

5 Wstp Proces tworzenia oprogramowania: specyfikacja oprogramowania (funkcjonalno i ograniczania), tworzenie oprogramowania, zatwierdzanie oprogramowania (kontrola spe$nienia specyfikacji wymaga+) ewolucja oprogramowania (wynikaj%ca ze zmian dokonywanych przez klienta w specyfikacji wymaga+) 5

6 Faza strategiczna Studium dopuszczalno!ci przedsiwzicia -cis$y zwi%zek z zagadnieniami zarz%dzania przedsiwziciem. Sposób realizacji: dokonanie serii rozmów (wywiadów) z przedstawicielami klienta, okrelenie celów przedsiwzicia z punktu widzenia klienta, okrelenie zakresu oraz kontekstu przedsiwzicia, ogólne okrelenie wymaga+, wykonanie zgrubnej analizy i projektu systemu, propozycja kilku moliwych rozwi%za+, tj. sposobów realizacji systemu, oszacowanie kosztów oprogramowania, analiza rozwi%za+; wybór rozwi%zania, które przedstawi si klientowi prezentacja wyników fazy strategicznej przedstawicielom klienta oraz korekcja wyników na podstawie uzyskanych uwag, okrelenie wstpnego harmonogramu przedsiwzicia oraz struktury zespo$u realizuj%cego przedsiwzicie, okrelenie standardów zgodnie, z którymi realizowane bdzie przedsiwzicie. 6

7 Faza strategiczna Najwaniejsze zagadnienia dotyczce studium wykonalno!ci: 1. Czy system przyczyni si do realizacji ogólnych celów przedsibiorstwa? 2. Czy system moe by zaimplementowany z uyciem dostpnych technologii w ramach ustalonego budetu i ogranicze+ czasowych? 3. Czy system moe by zintegrowany z istniej%cymi systemami, które ju funkcjonuj%? 7

8 Faza strategiczna Okre!lenie celów przedsiwzicia z punktu widzenia klienta oraz zakresu, kontekstu i wymaga%. Cel wywiadu: Uzyskanie informacji potrzebnych do podjcia decyzji o wykonalnoci przedsiwzicia, oraz poznanie celów strategicznych klienta w zakresie wymaga+ funkcjonalnych oraz ogranicze+. Rozmówca: Wyszy i redni szczebel zarz%dzania firmy - merytorycznie przygotowany, posiadaj%cy wystarczaj%ce kompetencje w zakresie wyraania wymaga+ klienta. Metody realizacji: Bezporednie rozmowy. 8

9 Faza strategiczna Cel: Przedstawienie klientowi bardzo ogólnego, zwartego, uporz%dkowanego i spójnego opisu wyraaj%cego jego potrzeby w stosunku do realizowanego przedsiwzicia oraz przedstawienie zakresu dzia$a+. Wykonawca: analitycy opracowuj%cy strategi. Metody realizacji: uogólnienie opisów, uporz%dkowanie wg aspektów przedsiwzicia, okrelenie wstpnych ogranicze+ dot. podstawowych zasobów (koszty, czas). 9

10 Faza okrelania wymaga+ Zamiana celów klienta na wymagania realizujcych te cele. Poziomy ogólnoci opisu wymaga+: definicja wymaga+ (opis w jzyku naturalnym), specyfikacja wymaga+ (opis czciowo sformalizowany), specyfikacja oprogramowania (opis w pe$ni sformalizowany). Cechy w$aciwego opisu wymaga+: kompletno oraz niesprzeczno, przedstawienie zewntrznego opisu zachowania bez wchodzenia w zagadnienia implementacji, zawiera ograniczania zewntrzne jakim podlega system, $atwo modyfikacji, zawiera zachowanie systemu w niepo%danych sytuacjach. 10

11 Faza okrelania wymaga+ Wymagania dzieli si pod wzgldem charakteru operacji na dwa rodzaje: funkcjonalne (opisuj% funkcje, czynnoci, zadania, operacje wykonywane przez system), niefunkcjonalne (opisuj% ograniczania, przy zachowaniu których system powinien realizowa swoje funkcje, niezawodno, czas reakcji, zajmowanie pamici, moliwoci urz%dze+ we-wy, reprezentacja danych wymagania dotycz%ce systemu jako ca$oci) 11

12 Faza okrelania wymaga+ Rodzaje wymaga% niefunkcjonalnych: 12

13 Faza okrelania wymaga+ +róda i adresaci wymaga%: 13

14 Faza okrelania wymaga+ Struktura dokumentu opisujcego wymagania: 1. Wprowadzenie (cele, zakres i kontekst systemu, opis i wyniki fazy strategicznej). 2. Opis ewolucji systemu. 3. Opis wymaga+ funkcjonalnych. 4. Opis wymaga+ niefunkcjonalnych. 5. Model systemu (faza okrelania wymaga+ i faza modelowania czciowo si nak$adaj%). 6. S$ownik (dokument ten musi by zrozumia$y zarówno dla pracowników firmy programistycznej jak i dla klienta). 7. Dodatki: 8. Specyfikacja wymaga+ funkcjonalnych. 9. Specyfikacja wymaga+ niefunkcjonalnych. 10. Wymagania sprztowe. 11. Wymagania dotycz%ce bazy danych. 12. Indeks (u$atwia przegl%danie dokumentów). 14

15 Faza okrelania wymaga+ Rozkad funkcjonalny ma na celu zbudowanie systemu sk$adaj%cego si z funkcji. Funkcje rozk$adane s% na podfunkcje oraz interfejsy funkcjonalne. Podstaw% rozk$adu funkcjonalnego jest wybór kroków i podkroków przetwarzania. Specyfikacja funkcji i podfunkcji nie daje si bezporednio odwzorowa na zagadnienie. Analiza obiektowa korzysta z rozk$adu funkcjonalnego przy definiowaniu us$ug tj. specjalnych zachowa+, które ma wykazywa obiekt. Moe by poyteczne stosowanie diagramu przep$ywu np. podczas konstruowania z$oonej us$ugi, któr% warto podzieli na mniejsze czci realizuj%ce poszczególne wymagania funkcjonalne. 15

16 Faza okrelania wymaga+ Metod radzenia sobie z du ilo!ci funkcji jest konstrukcja hierarchii wymaga% funkcjonalnych: podejcie zstpuj%ce - zaczyna si od ogólnej funkcji, nastpnie rozbija si j% na mniejsze, a dochodzi si do funkcji elementarnych. podejcie wstpuj%ce - zaczyna si od okrelenia funkcji elementarnych, które nastpnie si grupuje dochodz%c do funkcji najwyszego poziomu. metoda mieszana - specyfikuje si informacje zarówno o funkcjach elementarnych (te trzeba grupowa) jak i o funkcjach ogólnych (te trzeba rozbija) 16

17 Faza okrelania wymaga+ Metoda zstpuj%ca: 17

18 Faza okrelania wymaga+ Metoda wstpuj%ca: 18

19 Faza okrelania wymaga+ Metoda mieszana: 19

20 Faza okrelania wymaga+ Przykady wymaga% niefunkcjonalnych: - ograniczanie edycji poprzez popuszczenie uycia przez uytkownika tylko klawiatury, - realizacja danej funkcji musi by uwzgldnia okrelon% norm, - zabrania si dokonywania zmian w strukturze bazy danych. 20

21 Faza okrelania wymaga+ Kontrolna realizacji celów klienta wymaga zdefiniowania parametrów kontrolujcych sposób wykonania zadania. Kady ze zdefiniowanych parametrów powinien posiada nastpuj%ce parametry: nazwa opis cechy któr% mierzy, miar, jednostk, uwagi dodatkowe. 21

22 Faza okrelania wymaga+ Przyk$adowy opis parametru kontrolnego. Cecha parametru Nazwa Opis Miara Jednostka Uwagi dodatkowe Wydajno obliczeniowa Czas potrzebny do przeliczania jednej pozycji w tabeli funduszu p$ac -redni czas oblicze+ pojedynczego rekordu sekunda Zawarto!/ cechy parametru Cecha obliczana jest dla komputera opisanego w specyfikacji. 22

23 Faza okrelania wymaga+ Gówne problemy zapisu wymaga% za pomoc jzyka naturalnego. 1. Brak jasnoci 2. Sprzecznoci 3. F%czenie wymaga+ Notacje specyfikacji wymaga%: 1. Strukturalny jzyk naturalny (formularze, szablony) 2. Jzyki opisu projektu (jzyki podobne do jzyków programowania lecz posiadaj%ce bardziej abstrakcyjne elementy 3. Notacje graficzne (np. SADT) 4. Specyfikacje matematyczne (sko+czone maszyny stanowe, zbiory) 23

24 Faza okrelania wymaga+ Podstawowe elementy standardowego formularza specyfikacji wymaga%. 1. Nazwa funkcji 2. Opis dzia$ania 3. Dane wejciowe 4. Dane wyjciowe 5. Przeznaczenie 6. Wymagania 7. Warunek pocz%tkowy 8. Warunek ko+cowy 9. Efekty uboczne 24

25 Faza okrelania wymaga+ Lista postulatów, które powinny by/ spenione przez dokumentacj wymaga% (Heninger 1980). Dokumentacja powinna: 1. okrela zachowanie systemu jedynie z zewn%trz, 2. okrela ograniczania implementacji, 3. by $atwo modyfikowalna, 4. by informatorem dla konserwatorów systemu, 5. obejmowa przewidywania przysz$ego cyklu ycia systemu, 6. charakteryzowa akceptowalne reakcje na niepo%dane zdarzenia. 25

26 Faza okrelania wymaga+ Struktura dokumentacji wymaga%: 1. Wstp 1. Przeznaczenie tej dokumentacji wymaga+ 2. Zakres produktu 3. Definicje, akronimy i skróty 4. Odnoniki 5. Przegl%d pozosta$ej czci dokumentu 2. Ogólny opis 1. Wizja produktu 2. Funkcje produktu 3. Charakterystyka uytkowników 4. Ogólne ograniczania 5. Za$oenia i zalenoci 3. Szczegó$owe wymagania 4. Dodatki 5. Skorowidz. 26

27 Inynieria wymaga+ 1. Studium wykonalnoci 2. Okrelanie i analizowanie wymaga+ 3. Zatwierdzanie wymaga+ 4. Zarz%dzanie wymaganiami 27

28 Inynieria wymaga+ Okre!lanie i analizowanie wymaga%: 28

29 Inynieria wymaga+ Metod VORD (Viewpoint-Oriented Requirements Definition) 29

30 Inynieria wymaga+ Szablon formularz punktów widzenia: Nazwa cechy Opis Odno!nik Nazwa punktu widzenia Atrybuty Atrybuty z informacj% o punkcie widzenia Zdarzenia Usugi Odnonik do zbioru scenariuszy zdarze+ opisuj%cych, jak system reaguje na zdarzenia w ramach tego punktu widzenia Odnonik do zbioru opisów us$ug Podrzdne punkty widzenia Nazwy podrzdnych punktów widzenia 30

31 Inynieria wymaga+ Szablon formularza usug: Nazwa cechy Opis Odno!nik Nazwa us$ugi Uzasadnienie Przyczyna oferowania us$ugi Specyfikacja Punkty widzenia Wymagania niefunkcjonalne Dostawca Odnonik do listy specyfikacji us$ug, które mog% by opisane za pomoc% rónych notacji Lista nazw punktów widzenia, których reprezentanci korzystaj% z us$ugi Odnonik do zbioru wymaga+ niefunkcjonalnych ograniczaj%cych us$ug Odnonik do listy obiektów systemu, które oferuj% t us$ug 31

32 Inynieria wymaga+ Strukturalizacja punktów widzenia (przyk$ad) 32

33 Inynieria wymaga+ Zarzdzanie wymaganiami Istotne kwestie dotycz%ce zarz%dzania wymaganiami: 1. Oznakowanie wymaga+ 2. Proces zarz%dzania zmianami 3. Strategia ledzenia pochodzenia 4. Uycie narzdzi CASE Rodzaje informacji o pochodzeniu wymaga+: 1. Informacje o pochodzeniu 2. Informacje o uzalenieniu wymaga+ 3. Informacje o uzalenieniu projektu 33

34 Inynieria wymaga+ Macierz zaleno!ci: Identyfikator wymagania U R 1.2 U R U 1.3 R R R U 2.2 U 2.3 R U R 3.2 R 34

35 Faza analizy Modelowanie Analiza procedura studiowania dziedziny problemu, prowadz%ca do wyspecyfikowania zachowania moliwego do zaobserwowania z zewn%trz; ; kompletne, zgodne i wykonalne stwierdzenie, czego potrzebujemy; okrelenie zarówno funkcjonalnoci,, jak i ilociowych charakterystyk operacyjnych (np. niezawodnoci, dostpnoci, wydajnoci). W fazie analizy wymagania zebrane od klienta s% przetwarzane na sformalizowan% specyfikacj opisuj%c% dzia$anie systemu widzian% z zewn%trz, wic nie zawieraj%c% szczegó$ów dot. implementacji. Wynikiem analizy jest logiczny model systemu opisuj%cy sposób realizacji przez system postawionych wymaga+. 35

36 Faza analizy W procesie analizy istotne jest przejcie pomidzy perspektyw% z jakiej widzi system klient na perspektyw, któr% w wyniku analizy zobaczy projektant. Zmiana skali Wywietlanie opisu symbolu Edycja parametrów mapy Zarz!dzanie mapami Wywietlanie mapy Zamkniêcie mapy Edycja/wybór sów kluczowych Edycja ta Wybór sów kluczowych Wywietlanie opisu mapy Uytkownik Odczyt mapy Projektant Edycja/wybór wzorów symboli Edycja symboli graficznych 36

37 Faza analizy Przyk$ady diagramów funkcji: Dodawanie symbolu Edycja/wybór sów kluczowych Dodawanie sowa kluczowego Edycja sowa kluczowego uses uses uses uses Edycja/wybór wzorów symboli uses uses Edycja symbolu Odczyt mapy uses uses Tworzenie nowej mapy uses Edycja/wybór sów kluczowych uses uses uses uses Edycja symboli graficznych uses uses Zarz!dzanie mapami uses Wywietlanie mapy Usuwanie sów kluczowych Modyfikacja symboli uses uses Zaznaczanie i przesuwanie symboli Zamkni'cie mapy Zapis mapy uses Usuwanie symboli uses uses Wywietlanie mapy uses Usuni'cie wszystkich symboli 37

38 Faza analizy Najwaniejsze rezultaty fazy analizy to: poprawiony dokument opisuj%cy wymagania, s$ownik danych wype$niony specyfikacj% modelu, dokument opisuj%cy stworzony model, który w przypadku stosowania metod obiektowych sk$ada si z: diagramów klas, diagramów interakcji obiektów, diagramów przej stanów, raportów: definicji klas, definicji pól, definicji danych z$oonych oraz elementarnych, definicji metod, harmonogram fazy projektowania. 38

39 Faza analizy Punkty widzenia procesu analizy: Zewntrzny (modelowanie kontekstu lub rodowiska systemu), Zachowania (modelowanie zachowania systemu, przep$yw danych, maszyny stanowe), Strukturalny (modelowanie architektury systemu lub przetwarzania danych) 39

40 Faza analizy Modele kontekstowe We wczesnej fazie procesu modelowania naley ustali granice systemu. W tym celu tworzone s% modele architektoniczne uzupe$niane przez modele procesu. 40

41 Faza analizy Modele zachowania S% one uywane w celu ogólnego opisu zachowania systemu. Podstawowymi modelami tego typu s% modele przep$ywu danych oraz modele maszyn stanowych. Modele przep$ywu danych: S% stosowane do pokazania, jak dane przep$ywaj% w sekwencji kroków przetwarzania. Opracowywanie tego rodzaju modeli powinno by procesem zstpuj%cym. Modele te odpowiadaj% funkcjonalnemu punktowi widzenia. Przydaj% si do obrazowania kontekstu systemu. Modele maszyn stanowych S$u% do opisywania zachowania systemu, gdy reaguje na wewntrzne lub zewntrzne: zdarzenia, które powoduj% przejcia z jednego stanu do drugiego. Nie obejmuj% one przep$ywu danych. 41

42 Faza analizy Metoda przepywu danych Przepyw danych sk$ada si z nastpuj%cych elementów: - modyfikacja danych - magazynowanie danych - opisy procesów - s$owniki danych - magazyny danych Bardzo poyteczne okazuj si roz$oenie zdarzenia (np. %dania transakcji) i okrelenie kroków podjtych w odpowiedzi na te zdarzenia. W analizie obiektowej stosuje si takie podejcie przy wybieraniu us$ug i krokówk sk$adaj%cych si na dan% us$ug. Metoda przep$ywu danych k$adzie silny nacisk na funkcje,, natomiast bardzo s$aby na struktury danych. Diagramy przep$ywu danych przywi%zuj% niewielk% wag do magazynów danych. 42

43 Faza analizy Diagramy przepywu danych skadaj si z nastpujcych elementów: proces przep$yw sk$adnica obiekt zewntrzny 43

44 Faza analizy Zaleno!ci pomidzy podstawowymi elementami DFD. Obiekt zewntrzny Przepyw danych Proces Przepyw danych Skadnica danych 44

45 Faza analizy Przyk$ad DFD dla procesu zamawiania towarów. S1 TOWARY zamówienie 2.1 zamówienie hurtowe KLIENT ZAMAWIANIE TOWARÓW HURTOWNIA faktura Dzia zamówie list przewozowy S2 DOSTAWCY 45

46 Faza analizy Przyk$ad diagramu maszyny stanowej. 46

47 Faza analizy Modele danych Podstawowym narzdziem modelowania informacji jest diagram powi%za+ danych (ERD): Elementy modelowania informacji - obiekty - atrybuty - zwi%zki - supertypy/subtypy subtypy - obiekty skojarzone W metodzie tej brakuje realizacji idei: - us$ug - komunikatów - dziedziczenia - struktury: gen-spec, ca$o-cz cz 47

48 Faza analizy Przyk$ady diagramów ERD KLIENT przesya jest zoone moe zoy+ ZAMÓWIENIE SKLEP i zamawia MAGAZYN jest przewoony POJAZD PRACOWNIK kieruje TOWAR lub jest przechowywany MAGAZYN 48

49 Faza analizy Modele obiektowe Elementy modelowania obiektowego: klasy i obiekty dziedziczenie porozumiewanie si za pomoc% komunikatów 49

50 Faza analizy Podsumowanie: 50

51 Faza projektowania Projektowanie dzia$anie polegaj%ce na wziciu specyfikacji obserwowanego z zewn%trz zachowania systemu komputerowego i dodanie do niej szczegó$ów potrzebnych do rzeczywistej realizacji tego systemu, $%cznie ze szczegó$ami wspó$dzia$ania z cz$owiekiem oraz zarz%dzania zadaniami i danymi. Wynikiem fazy projektowania jest opis sposobu implementacji. Po zako+czeniu pracy nad systemem projekt (w sensie dokumentu) staje si dokumentacja techniczn% produktu. 51

52 Faza projektowania Na projektowanie skada si: uszczegó$owienie wyników analizy, projektowanie sk$adowych systemu nie zwi%zanych z dziedzin% problemu (s% to m.in.: interfejs uytkownika, zarz%dzanie danymi - sk$adowe te s% konieczne z punktu widzenia prawid$owej pracy systemu), optymalizacja systemu, dostosowanie do ogranicze+ i moliwoci rodowiska implementacji, okrelenie fizycznej struktury systemu (podzia$ kodu Nród$owego na modu$y, a w systemach rozproszonych take umieszczenie odpowiednich sk$adowych na odpowiednich serwerach). 52

53 Faza projektowania Najwaniejsze rezultaty fazy projektowania to: poprawiony dokument opisuj%cy wymagania, poprawiony model, uzupe$niona i uszczegó$owiona specyfikacja projektu zawarta w s$owniku danych, dokument opisuj%cy opracowany projekt, który w przypadku stosowania metod obiektowych sk$ada si z: diagramów klas, diagramów interakcji obiektów, diagramów przej stanów, innych diagramów o charakterze projektowym, np. diagramów Boocha, raportów: definicji klas, definicji pól, definicji danych z$oonych oraz elementarnych, definicji metod, zasoby interfejsu uytkownika, np. menu, dialogi..., projekt bazy danych, projekt fizycznej struktury systemu, poprawiony plan testów, harmonogram fazy implementacji. 53

54 Faza projektowania Uszczegóowienie wyników analizy Cz konstrukcji powsta$ych w fazie analizy nie mona w sposób bezporedni przekszta$ci w posta kodu Nród$owego. Uszczegó$owienie specyfikacji: Okrelenie typów danych. Okrelenie nag$ówków metod (parametry wraz z typami oraz typ wyniku) Uszczegó$owienie opisu algorytmów. Okrelenie które metody mog% by zdefiniowane jako wirtualne. Okrelenie sposobu implementacji zwi%zków klas. Pola implementuj%ce zwi%zki mog% by: obiektami powi%zanej klasy (agregacja), wskannikami do obiektów powi%zanej klasy (najczciej), identyfikatorami obiektów powi%zanej klasy (w przypadku baz danych). Jeeli obiekty danej klasy zwi%zane s% z wicej ni jednym obiektem innej klasy, to naley stosowa z$oone struktury danych bd%ce: tablicami obiektów, listami obiektów, tablicami nazw. 54

55 Faza projektowania Zwizki wielokrotne 55

56 Faza projektowania Projektowanie skadowych systemu nie zwizanych z dziedzin problemu. sk$adowa interfejsu uytkownika, odpowiedzialna za realizacj komunikacji z uytkownikiem (w projektowaniu systemów dedykowanych sprztowo interfejs uytkownika wchodzi do dziedziny problemu), sk$adowa zarz%dzania danymi, odpowiedzialna za realizacj (na poziomie fizycznym) sposobu przechowywania trwa$ych danych, sk$adowa zarz%dzania pamici% operacyjn%, sk$adowa zarz%dzania zadaniami, odpowiedzialna za przydzia$ czasu procesora (procesorów) do poszczególnych zada+. 56

57 Faza projektowania Projektowanie skadowych systemu nie zwizanych z dziedzin problemu. 57

58 Faza projektowania Projektowanie skadowej kontaktu z uytkownikiem. Nowoczesne systemy zarz%dzania interfejsem uytkownika: interaktywne projektowanie dialogów, okien, menu, map bitowych, ikon oraz pasków narzdziowych z wykorzystaniem bogatego zestawu gotowych elementów, definiowanie reakcji systemu na zajcie pewnych zdarze+, tj. akcji podejmowanych przez uytkownika (np. wybór opcji z menu), symulacja pracy interfejsu, generowanie kodu, czsto z moliwoci% wyboru jednego z kilku rodowisk docelowych. Dwa podstawowe sposoby realizacji komunikacji z uytkownikiem: za pomoc% linii komend, w pe$noekranowym rodowisku okienkowym. 58

59 Faza projektowania Projektowanie skadowej kontaktu z uytkownikiem. Komunikacja uytkownika z systemem komputerowym polega na: wydawaniu przez uytkownika polece+, przep$ywie danych pomidzy uytkownikiem a systemem. Typowe sposoby wydawania przez uytkownika polece% systemowi to: wpisywanie polece+ za pomoc% linii komend, wybór opcji z menu, wcinicie odpowiedniej kombinacji klawiszy (skrótu), korzystanie z ikon w paskach narzdziowych, wybór przycisku w dialogu, korzystanie z przycisków myszy. 59

60 Faza projektowania Projektowanie skadowej kontaktu z uytkownikiem. Typowe sposoby wprowadzania danych to: podawanie parametrów polece+ w przypadku systemów z lini% komend, wprowadzanie danych w odpowiedzi na zaproszenia systemu, wprowadzanie danych w dialogach. Typowe sposoby przekazywania uytkownikowi danych to: wywietlanie informacji w dialogach, wywietlanie i/lub wydruki raportów, graficzna prezentacja danych. 60

61 Faza projektowania Projektowanie skadowej kontaktu z uytkownikiem. Podstawowe zasady projektowania interfejsu uytkownika: Spójno (podobny rozk$ad komponentów na wszystkich dialogach, podobne kolory, czcionka, itp.; naley take uwzgldni spójno z innymi aplikacjami oraz z samym rodowiskiem). Skróty klawiszowe dla dowiadczonych uytkowników. Potwierdzanie przyjcia polecenia uytkownika. Prosta obs$uga b$dów. Odwo$ywanie akcji. Wraenie kontroli nad systemem. Nieobci%anie pamici krótkotrwa$ej (nazwy wykonywanych czynnoci powinny by widoczne w tytule okna, aby uytkownik zawsze wiedzia$, jaka operacja jest wykonywana). Grupowanie powi%zanych operacji (kreatory - prowadzenie uytkownika przez szereg dialogów). 61

62 Faza projektowania Projektowanie skadowej kontaktu z uytkownikiem. Przyk$ad: 62

63 Faza projektowania Projektowanie skadowej zarzdzania danymi. B a z y d a n y c h 63

64 Faza projektowania Okre!lenie fizycznej struktury systemu. Dzia$ania podejmowane w ramach okrelania fizycznej struktury systemu: stemu: Okrelenie struktury kodu Nród$owego,, tj. wyrónienie plików Nród$owych, zalenoci pomidzy nimi oraz rozmieszczenie sk$adowych projektu w plikach Nród$owych. Podzia$ systemu na poszczególne aplikacje. Fizyczne rozmieszczenie danych i aplikacji na stacjach roboczych i serwerach. 64

65 Faza projektowania Okre!lenie fizycznej struktury systemu. Notacja Boocha: deklaracja definicja modu$ g$ówny Nazwa Nazwa Nazwa Symbol.h Symbol.c Zalenoci kompilacji: Punkt.h 65

66 Faza projektowania Okre!lenie fizycznej struktury systemu. Due systemy mog% obejmowa: jeden lub wiele serwerów baz danych, jeden lub wiele serwerów aplikacji, wiele stacji roboczych. Serwer baz danych dziau kontroli jakoci Serwer baz danych dziau marketingu Dzia marketingu PC PC Pace PC Gówny serwer bazy danych przedsi'biorstwa Serwer aplikacji dziau marketingu PC PC PC PC Serwer baz danych dziau finansowego PC Zakupy PC PC PC Serwer plików dziau finansowego 66

67 Faza projektowania Poprawno!/ projektu. Poprawno projektu oznacza, e jego opis jest on zgodny z zasadami ami pos$ugiwania si notacjami wykorzystywanymi do jego zapisu. Poprawny projekt musi by/: kompletny, niesprzeczny, spójny, zgodny z regu$ami sk$adniowymi notacji. Kompletno!/ projektu obiektowego oznacza, e zdefiniowane s: wszystkie klasy, wszystkie pola, wszystkie metody, wszystkie dane z$oone i elementarne, a take, e opisany jest sposób realizacji wszystkich wymaga+ funkcjonalnych. 67

68 Faza projektowania Poprawno!/ projektu. Niesprzeczno oznacza, e aden element nie ma dwóch lub wicej sprzecznych definicji. Spójno oznacza semantyczn% zgodno informacji zawartych na rónorodnych diagramach i w specyfikacji. Jako!/ projektu. Kryteria jako!ci projektu: spójno, stopie+ powi%za+ sk$adowych, przejrzysto. 68

69 Faza projektowania Jako!/ projektu. Rodzaje spójno!ci: Spójno przypadkowa.. Powstaje np. wtedy, gdy programista dzieli program na modu$y tylkot dlatego, e umieszczenie wszystkich funkcji w jednym duym pliku utrudnia$o lub uniemoliwia$o jego edycj. Spójno logiczna.. Poszczególne sk$adowe realizuj% podobne funkcje, np. obs$ug b$dów, b wykonywanie podobnych oblicze+. Spójno czasowa.. Sk$adowe s% uruchamiane/wykorzystywane w podobnym czasie, np. przy starcie lub ko+cu pracy systemu. Spójno proceduralna.. Sk$adowe tworz% sekwencj wykonania, czyli s% kolejno uruchamiane. ane. Spójno komunikacyjna. Sk$adowe operuj% wspólnie na tym samym zestawiez danych wejciowych i wspólnie produkuj% ten sam zestaw danych wyjciowych. ch. Spójno sekwencyjna.. Dane wyjciowe jednej sk$adowej s% danymi wejciowymi kolejnej sk$adowej. Spójno funkcjonalna.. Wszystkie sk$adowe s% niezbdne dla wykonania pewnej, daj%cej si logicznie wyróni funkcji. Spójno obiektowa - pola danej klasy opisuj% daj%cy si logicznie wyróni byt, a jejj metody ustawiaj%, modyfikuj% i odczytuj% te pola. 69

70 Faza projektowania Jako!/ projektu Powizania: W przypadku stosowania technik obiektowych powi%zania sk$adowych to: przep$ywy komunikatów, dziedziczenie, zwi%zki klas. Przejrzysto!/ Dobry projekt powinien by przejrzysty, czyli czytelny, $atwo zrozumia$y. Odzwierciedlanie rzeczywistoci. Spójno oraz stopie+ powi%za+ sk$adowych. Zrozumia$e nazewnictwo. Czytelna i pe$na specyfikacja. Odpowiednia z$oono sk$adowych. 70

71 Faza implementacji Implementacja jest to proces kodowania projektu do postaci zgodnej ze specyfikacj% danego jzyka (lub jzyków) programowania. Pojcie programowania czsto bywa, w sposób nies$uszny, utosamiane z pojciem kodowania (implementacji.) Znacz%c% ilo czasu poch$ania nie tyle tworzenie kodu, lecz znajdowanie b$dów. Z tego w$anie powodu sztuka implementacji dzieli si na techniki kodowania, wród których bardzo istotn% rol pe$ni% elementy maj%ce na celu unikanie b$dów. Osobnym zagadnieniem jest umiejtno znajdowania b$dów oraz techniki kodowania, które mog% znacznie przyczyni si do u$atwienia tego zadania. Jedn% z waniejszych jest zasada need-to-know, wg której informacje powinny by udostpnione tylko tym którzy ich naprawd potrzebuj%. 71

72 Faza implementacji Automatyzacja fazy implementacji: Jzyki wysokiego poziomu. Biblioteki procedur, struktur, obiektów. Programowanie komponentowe. Narzdzia typy RAD. Narzdzia typu CASE. Niezawodno!/ oprogramowania: zasada ograniczonego dostpu, kompilatory sprawdzaj%ce zgodno typów, unikanie niebezpiecznych technik. 72

73 Faza implementacji Niebezpieczne techniki: kod niezgodny z zasadami programowania strukturalnego (np. instrukcje typu goto), operacje zmiennopozycyjne prowadz%ce do b$dów zwi%zanych z wielokrotnym zaokr%glaniem, operacje na wskannikach (np. odwo$ywanie si do nieistniej%cych obiektów), programowanie wspó$biene (wspó$dzielenie danych przez wiele procesów), przerwania, rekursja (niesko+czone ptle, przepe$nienie stosu, trudno analizy) z$oone wyraenia wymagaj%ce uwzgldnienia priorytetów operatorów, przenoszenie kodu Nród$owego z jednego rodowiska programowania do innego, unikanie komentowania kluczowych fragmentów kodu. 73

74 Faza implementacji Tolerancja bdów (nieczuo!/ na bdy i stany niepodane): Zadania konieczne do realizacji tolerancji bdów: wykrycie b$du, wyjcie z b$du, ewentualna naprawa b$du. Sposoby realizacji: weryfikacja poprawnoci wartoci zmiennych i atrybutów, wprowadzanie warunków integralnoci (w bazach danych), wartoci domylne, programowanie N-wersyjne technika zapasowych modu$ów. 74

75 Faza implementacji Podsumowanie Kluczowe czynniki sukcesu: zysoka jako i odpowiedni poziom szczegó$owoci projektu, dobra znajomo rodowiska implementacji, zachowanie standardów implementacji, unikanie b$dów. Podstawowe rezultaty fazy implementacji: poprawiony dokument opisuj%cy wymagania, poprawiony model, poprawiony projekt, kod Nród$owy zaimplementowanych modu$ów, raport wstpnych testów dostrojona baza danych, harmonogram fazy testowana. 75

76 Faza dokumentacji Faza dokumentacji czsto wykonywana jest równolegle do innych faz. Na ko+cowym etapie wykonywana jest dokumentacja uytkownika. Istotne problemy tworzenia dokumentacji uytkownika: rónorodno odbiorców, niski poziom znajomoci zagadnie+ informatycznych odbiorców, nieznajomo za$oe+ opracowanego oprogramowania (modelu), zainteresowanie tylko wybranymi obszarami zrealizowanych wymaga+ funkcjonalnych. Ponadto istnieje szereg zagadnie% natury psychologicznej np.: Obszerna instrukcja niech do zapoznania si ( Trzeba powi duo czasu ) Zwiz$a instrukcja Tematy potraktowane pobienie wic i tak wikszo pewnie trzeba bdzie samemu pozna Pojcia informatyczne Nie rozumiem tych poj (nawet jak s% zdefiniowane, ewentualnie nie rozumiem definicji ) 76

77 Faza dokumentacji Odbiorcy dokumentacji: administratorzy systemu, odbiorcy ko+cowi, osoby zatwierdzaj%ce oprogramowanie. Kada z tych grup oczekuje innego sposobu opisu dokumentacji, oraz najczciej nie toleruje elementów zbdnych z ich punktu widzenia. Pewnym rozwi%zaniem jest opracowanie kilku wersji, co w oczywisty sposób zwiksza nak$ad pracy oraz utrudnia pielgnacj systemu. Innym rozwi%zaniem jest zastosowanie odpowiedniego u$oenia treci dokumentu, które w sposób $atwy pozwoli danemu odbiorcy zdecydowa czy dany fragment jest z jego punktu widzenia istotny. 77

78 Faza dokumentacji Elementy skadowe dokumentacji uytkowej: Opis funkcjonalny (przeznaczenie oprogramowania, moliwoci, ograniczenia, wymagania) Podrcznik uytkowania (sposoby uruchamiania i ko+czenia pracy z programem, sposób wykorzystania poszczególnych funkcjonalnoci, opis interfejsu uytkownika, opis przyjtych standardów komunikacji z uytkownikiem, sposób korzystania z pomocy) Kompletny opis (szczegó$owy opis wszystkich funkcji w raz ze sposobami wywo$ania i efektami ich dzia$a+, opisy formatów danych, opis b$dów, informacje o wszelkich ograniczeniach) Opis instalacji. Podrcznik administratora (zarz%dzanie, pielgnacja). S$ownik uywanych poj. Indeks. 78

79 Faza dokumentacji Zasady dotyczce sposobu pisania dokumentacji uytkownika: Stosowanie formy aktywnej i zwracanie si do uytkownika (mniej formalny i w naszym obszarze kulturowym nie zawsze dobrze przyjmowany) Poprawno jzykowa (gramatyka, ortografia, stylistyka). Komunikatywno (krótkie zdania, krótkie akapity, oszczdno s$ów, unikanie skomplikowanych form jzykowych oraz wtr%ce+) Precyzyjna, ale i czytelna definicja poj. Powtórzenia w zakresie istotnych oraz trudniejszych fragmentów. Czsto stosowanie tytu$ów, podtytu$ów, wylicze+ i wyrónie+. Czytelne i funkcjonalne odwo$ania do innych rozdzia$ów (nie po numerze rozdzia$u, a poprzez tytu$ i stron) Wyrónienie fragmentów tekstu wg wanoci oraz trudnoci. Stosowanie opisów opatrzonych licznymi rysunkami (zrzuty ekranów, diagramy). Bardzo wyranne podkrelanie co jest konieczne do realizacji opisywanego zadania, a co jest moliwe. 79

80 Faza testowania W skad testowania wchodz dwa gówne procesy: Atestowanie (czsto zwane walidacj% validation) testowanie czy oprogramowanie spe$nia rzeczywiste potrzeby uytkownika. Jest to odpowiedz na pytanie czy budowane oprogramowanie jest naprawd potrzebne uytkownikowi. Weryfikacja (veryfication) testowanie zgodnoci systemu z wymaganiami okrelonymi w fazie okrelania wymaga+. Jest to odpowiedz na pytanie czy we w$aciwy sposób realizowane s% wymagania uytkownika. Celem testowania jest: wykrycie i usunicie b$dów w oprogramowaniu, ocena niezawodnoci oprogramowania. Z punktu widzenia cyklu ycia oprogramowania wyrónia si testy: ALFA, BETA, GAMMA. 80

81 Faza testowania Rodzaje testów: dynamiczne funkcjonalne strukturalne statyczne dowody poprawnoci metody nieformalne Typowe bdy: niezainicjowane zmienne, b$dne porównania liczb zmiennopozycyjnych, przekroczenie zakresu tablicy, operacje na wskannikach, b$dy w wyraeniach logicznych instrukcji warunkowych i iteracyjnych, b$dy dotycz%ce warunków granicznych (>=, >, <=, <), nawiasy w z$oonych wyraeniach, nieuwzgldnienie b$dów w danych. 81

82 Faza testowania Strategie prowadzenia testów: wstpuj%ce zstpuj%ce Specyficzne rodzaje testów: Testy wydajnociowe pod obci%eniem, przy przeci%eniu. Testy odpornociowe zanik zasilania, awaria sprztowa, wprowadzenie niepoprawnych danych, niepoprawna obs$uga programu. 82

83 Faza testowania Bezpiecze%stwo oprogramowania Skoro niemoliwe jest wykonanie oprogramowania nie zawieraj%cego b$dów, naley d%y do wytworzenia produktu bezpiecznego. W oprogramowaniu bezpiecznym zak$ada si istnienie nie wykrytych b$dów jednak b$dy te nie mog% powodowa b$dnego dzia$ania programów w kluczowych aspektach jego funkcjonalnoci. W tym celu nale utworzy list krytycznych czynników sukcesu, które zawieraj% kluczowe postulaty, których spe$nienie jest konieczne, aby oprogramowanie zakwalifikowa jako bezpieczne. Bezpiecze+stwo oprogramowania moe posiada klika poziomów. W zalenoci od roli danego programu dla funkcjonowania ca$ego systemu ustala si oczekiwane poziomy bezpiecze+stwa. Istotnym elementem analizy bezpiecze+stwa s% drzewa b$dów (fault trees). 83

84 Faza instalacji Faz instalacji rozpoczyna si, gdy przynajmniej cz oprogramowania jest gotowa. Na faz instalacji skada si: szkolenie pracowników ko+cowych i administratorów, instalacja sprztu i oprogramowania, konfiguracja, wstpne wype$nienie baz danych, wstpne uruchomienie oprogramowania (nadzorowane korzystanie), usuwanie usterek w oprogramowaniu oraz uzupe$nianie i poprawianie dokumentacji, przekazanie systemu klientowi. 84

85 Faza konserwacji Konserwacja oprogramowania polega na wprowadzaniu zmian. Ze wzgldu na róne cele, modyfikacje moemy podzieli/ na nastpujce rodzaje: poprawiaj%ce (usuwanie b$dów), ulepszaj%ce (poprawa jakoci), dostosowuj%ce (reagowanie na zmiany modelu). Decyzja o wprowadzeniu lub nie danej modyfikacji powinna uwzgldnia/: istotno dokonywanych zmian z punktu widzenia funkcjonalnoci, koszt, zalenoci midzy zmian% i innymi elementami oprogramowania i sprztu. wp$yw zmiany na uytkowników ko+cowych, wp$yw zmiany na model i ewentualna celowo przekszta$cenia modelu, wielko zmian w dokumentacji. 85

86 Faza konserwacji Inynieria odwrotna. Inynieria odwrotna jest dzia$aniem maj%cym na celu uzyskanie dokumentacji na podstawie istniej%cego kodu lub struktur danych. 86

87 Modele cyklu ycia oprogramowania Procedura kaskadowa wszystkie w%tpliwoci s% rozwi%zywane na czas. Zalety: Fatwo zarz%dania Ekspoatacja Wady: Narzucenie twórcom cis$ej kolejnoci dzia$a+ Wysoki koszt b$dów pope$nianych na wstpnych etapach D$uga przerwa w kontaktach z klientem Zaawansowanie pracy Analiza Projekt Testowanie Sformuowanie problemu czas 87

88 Modele cyklu ycia oprogramowania Procedura odkrywcza klient nie wie czego chce, my nie wiemy co bdziemy w stanie zrealizowa. Czsto spotykana w programowaniu na potrzeby nauki. Efektem dzia$a s% praktycznie tylko prototypy. Zalety: Moliwo stosowania w przypadku trudnoci w okreleniu wymaga+. Wady: Prawie niemoliwe zachowanie prawid$owej struktury systemu. Testowanie jest moliwe praktycznie tylko przy pe$nym udziale klienta. 88

89 Modele cyklu ycia oprogramowania Procedura spiralna metoda kolejnych przyblie+. Najbardziej ogólny model. Z tego powodu trudno wyrannie okreli jego zalety i wady. Kady z elementów cyklu moe by wykonywany na wiele sposobów. Tworzenie wielu prototypów daje gwarancj czstego weryfikowania potrzeb, ale powoduje te wiksze koszty oraz spowalnia prace zespo$u. Kolejne wersje w kolejnych cyklach s% coraz doskonalsze, jednak naley wybra moment w którym system zostanie ostatecznie przekazany klientowi. W przeciwnym wypadku wpadnie si w nieko+cz%c% ptl przeróbek i dodatków co spowoduje ci%g$e zwikszanie kosztów. Jest to zjawisko bardzo niekorzystne niezalenie od tego kto te koszty ponosi. Nieprzyjemn% pu$apk% moe te by nadmierne dostosowanie produktu do konkretnego klienta. PLANOWANIE WERYFIKACJA Plan caoci Wdroenie ANALIZA RYZYKA Prototyp 1 Symulacja Testowanie Integracja Prototyp 2 Kodowanie Prototyp 3 KONSTRUOWANIE 89

90 Modele cyklu ycia oprogramowania Procedura ewolucyjna programowanie nad%ne. Jest to sposób dzia$ania maj%cy na celu ci%g$e dostosowywanie produktu w sytuacji, gdy ostateczny cel podlega modyfikacjom. Zmiany mog% mie charakter kosmetyczny, ale s% sytuacje gdy zaczynano prace nad jednym systemem, a gdy prace s% na uko+czeniu okazuje si, e jest on jest zupe$nie inny. Najczciej dotyczy to niekontrolowanego rozwoju oprogramowania. W wyniku ca$ej serii drobnych zmieni$ si powanie zakres funkcjonalny programu. Duo rzadziej, cele si minimalizuje, tzn. z ambitnych przedsiwzi powstaje tylko ich fragment. Jeeli ju tak si dzieje, to g$ównie z przyczyn ekonomicznych, a nie technicznych. C4 C3 Cel C2 C1 Start t1 t2 t3 t4 czas 90

91 Modele cyklu ycia oprogramowania Procedura przyrostowa programowanie etapami. Jest to model kaskadowy z dopuszczeniem iteracji. Zalety: Krótkie przerwy w kontaktach z klientem. Moliwo wczesnego wykorzystania przez klienta dostarczonych fragmentów systemu. Moliwo elastycznego reagowania na opónnienia (gospodarka zasobami) Wady: Pewne dodatkowe koszty zwi%zane z niezalenym realizowaniem poszczególnych fragmentów. Wymagania Analiza Architektura systemu Projekt Projekt Zastosowania Zastosowania Testowanie Testowanie Projekt Zastosowania Testowanie Testowanie ca$oci Instalacja Eksploatacja 91