In ynieria oprogramowania

In ynieria oprogramowania Wst p In ynieria oprogramowania (software engineering), wiedza i umiej tno przydatna do budowy programów, szczególnie du ych systemów oprogramowania. Obejmuje tworzenie specyfikacji, metody programowania, aspekty uruchamiania i testowania oraz opracowywanie dokumentacji. Odr bnymi dzia$ami in ynierii oprogramowania s% dowodzenie poprawno ci programów oraz zagadnienia przeno no ci. Znajomo in ynierii oprogramowania pomaga w wydajnym konstruowaniu niezawodnego oprogramowania, tak e w sposób automatyczny.

2

In ynieria oprogramowania Wst p Dzia ania sk adaj ce si na in ynieri oprogramowania: •

specyfikowanie,

•

tworzenie,

•

zarz%dzanie,

•

rozwijanie

systemów komputerowych. System komputerowy sk$ada si z programów, plików konfiguracyjnych, dokumentacji systemowej, dokumentacji u ytkownika.

3

In ynieria oprogramowania Wst p Istniej dwa rodzaje produktów programowych: •

powszechne,

•

dostosowane.

In ynieria 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,

•

wdro enie systemu,

•

in ynieri oprogramowania.

4

In ynieria oprogramowania Wst p 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

In ynieria oprogramowania Faza strategiczna Studium dopuszczalno!ci przedsi wzi cia -cis$y zwi%zek z zagadnieniami zarz%dzania przedsi wzi ciem. Sposób realizacji: • dokonanie serii rozmów (wywiadów) z przedstawicielami klienta, • okre lenie celów przedsi wzi cia z punktu widzenia klienta, • okre lenie zakresu oraz kontekstu przedsi wzi cia, • ogólne okre lenie wymaga+, wykonanie zgrubnej analizy i projektu systemu, • propozycja kilku mo liwych 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, • okre lenie wst pnego harmonogramu przedsi wzi cia oraz struktury zespo$u realizuj%cego przedsi wzi cie, • okre lenie standardów zgodnie, z którymi realizowane b dzie przedsi wzi cie.

6

In ynieria oprogramowania Faza strategiczna Najwa niejsze zagadnienia dotycz ce studium wykonalno!ci: 1. 2. 3.

Czy system przyczyni si do realizacji ogólnych celów przedsi biorstwa? Czy system mo e by zaimplementowany z u yciem dost pnych technologii w ramach ustalonego bud etu i ogranicze+ czasowych? Czy system mo e by zintegrowany z istniej%cymi systemami, które ju funkcjonuj%?

7

In ynieria oprogramowania Faza strategiczna Okre!lenie celów przedsi wzi cia z punktu widzenia klienta oraz zakresu, kontekstu i wymaga%. Cel wywiadu: Uzyskanie informacji potrzebnych do podj cia decyzji o wykonalno ci przedsi wzi cia, oraz poznanie celów strategicznych klienta w zakresie wymaga+ funkcjonalnych oraz ogranicze+. Rozmówca: Wy szy i redni szczebel zarz%dzania firmy - merytorycznie przygotowany, posiadaj%cy wystarczaj%ce kompetencje w zakresie wyra ania wymaga+ klienta. Metody realizacji: Bezpo rednie rozmowy.

8

In ynieria oprogramowania Faza strategiczna Cel: Przedstawienie klientowi bardzo ogólnego, zwartego, uporz%dkowanego i spójnego opisu wyra aj%cego jego potrzeby w stosunku do realizowanego przedsi wzi cia oraz przedstawienie zakresu dzia$a+. Wykonawca: analitycy opracowuj%cy strategi . Metody realizacji: uogólnienie opisów, uporz%dkowanie wg aspektów przedsi wzi cia, okre lenie wst pnych ogranicze+ dot. podstawowych zasobów (koszty, czas).

9

In ynieria oprogramowania Faza okre lania wymaga+ Zamiana celów klienta na wymagania realizuj cych te cele. Poziomy ogólno ci opisu wymaga+: • definicja wymaga+ (opis w j zyku naturalnym), • specyfikacja wymaga+ (opis cz ciowo sformalizowany), • specyfikacja oprogramowania (opis w pe$ni sformalizowany). Cechy w$a ciwego opisu wymaga+: • kompletno oraz niesprzeczno , • przedstawienie zewn trznego opisu zachowania bez wchodzenia w zagadnienia implementacji, • zawiera ograniczania zewn trzne jakim podlega system, • $atwo modyfikacji, • zawiera zachowanie systemu w niepo %danych sytuacjach.

10

In ynieria oprogramowania Faza okre lania wymaga+ Wymagania dzieli si pod wzgl dem charakteru operacji na dwa rodzaje: • •

funkcjonalne (opisuj% funkcje, czynno ci, zadania, operacje wykonywane przez system), niefunkcjonalne (opisuj% ograniczania, przy zachowaniu których system powinien realizowa swoje funkcje, niezawodno , czas reakcji, zajmowanie pami ci, mo liwo ci urz%dze+ we-wy, reprezentacja danych wymagania dotycz%ce systemu jako ca$o ci)

11

In ynieria oprogramowania Faza okre lania wymaga+ Rodzaje wymaga% niefunkcjonalnych:

12

In ynieria oprogramowania Faza okre lania wymaga+ +ród a i adresaci wymaga%:

13

In ynieria oprogramowania Faza okre lania wymaga+ Struktura dokumentu opisuj cego wymagania: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

Wprowadzenie (cele, zakres i kontekst systemu, opis i wyniki fazy strategicznej). Opis ewolucji systemu. Opis wymaga+ funkcjonalnych. Opis wymaga+ niefunkcjonalnych. Model systemu (faza okre lania wymaga+ i faza modelowania cz ciowo si nak$adaj%). S$ownik (dokument ten musi by zrozumia$y zarówno dla pracowników firmy programistycznej jak i dla klienta). Dodatki: Specyfikacja wymaga+ funkcjonalnych. Specyfikacja wymaga+ niefunkcjonalnych. Wymagania sprz towe. Wymagania dotycz%ce bazy danych. Indeks (u$atwia przegl%danie dokumentów). 14

In ynieria oprogramowania Faza okre lania wymaga+ Rozk ad 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 bezpo rednio odwzorowa na zagadnienie. Analiza obiektowa korzysta z rozk$adu funkcjonalnego przy definiowaniu us$ug tj. specjalnych zachowa+, które ma wykazywa obiekt. Mo e by po yteczne stosowanie diagramu przep$ywu np. podczas konstruowania z$o onej us$ugi, któr% warto podzieli na mniejsze cz ci realizuj%ce poszczególne wymagania funkcjonalne. 15

In ynieria oprogramowania Faza okre lania wymaga+ Metod radzenia sobie z du ilo!ci funkcji jest konstrukcja hierarchii wymaga% funkcjonalnych: • • •

podej cie zst puj%ce - zaczyna si od ogólnej funkcji, nast pnie rozbija si j% na mniejsze, a dochodzi si do funkcji elementarnych. podej cie wst puj%ce - zaczyna si od okre lenia funkcji elementarnych, które nast pnie si grupuje dochodz%c do funkcji najwy szego poziomu. metoda mieszana - specyfikuje si informacje zarówno o funkcjach elementarnych (te trzeba grupowa ) jak i o funkcjach ogólnych (te trzeba rozbija )

16

In ynieria oprogramowania Faza okre lania wymaga+ Metoda zst puj%ca:

17

In ynieria oprogramowania Faza okre lania wymaga+ Metoda wst puj%ca:

18

In ynieria oprogramowania Faza okre lania wymaga+ Metoda mieszana:

19

In ynieria oprogramowania Faza okre lania wymaga+ Przyk ady wymaga% niefunkcjonalnych: -

ograniczanie edycji poprzez popuszczenie u ycia przez u ytkownika tylko klawiatury, realizacja danej funkcji musi by uwzgl dnia okre lon% norm , zabrania si dokonywania zmian w strukturze bazy danych.

20

In ynieria oprogramowania Faza okre lania wymaga+ Kontrolna realizacji celów klienta wymaga zdefiniowania parametrów kontroluj cych sposób wykonania zadania. Ka dy ze zdefiniowanych parametrów powinien posiada nast puj%ce parametry: • nazwa • opis cechy któr% mierzy, • miar , • jednostk , • uwagi dodatkowe.

21

In ynieria oprogramowania Faza okre lania wymaga+ Przyk$adowy opis parametru kontrolnego.

Cecha parametru

Zawarto!/ cechy parametru

Nazwa

Wydajno

obliczeniowa

Opis

Czas potrzebny do przeliczania jednej pozycji w tabeli funduszu p$ac

Miara

-redni czas oblicze+ pojedynczego rekordu

Jednostka

sekunda

Uwagi dodatkowe

Cecha obliczana jest dla komputera opisanego w specyfikacji. 22

In ynieria oprogramowania Faza okre lania wymaga+ G ówne problemy zapisu wymaga% za pomoc j zyka naturalnego. 1. 2. 3.

Brak jasno ci Sprzeczno ci F%czenie wymaga+

Notacje specyfikacji wymaga%: 1. Strukturalny j zyk naturalny (formularze, szablony) 2. J zyki opisu projektu (j zyki podobne do j zyków programowania lecz posiadaj%ce bardziej abstrakcyjne elementy 3. Notacje graficzne (np. SADT) 4. Specyfikacje matematyczne (sko+czone maszyny stanowe, zbiory)

23

In ynieria oprogramowania Faza okre lania wymaga+ Podstawowe elementy standardowego formularza specyfikacji wymaga%. 1. 2. 3. 4. 5. 6. 7. 8. 9.

Nazwa funkcji Opis dzia$ania Dane wej ciowe Dane wyj ciowe Przeznaczenie Wymagania Warunek pocz%tkowy Warunek ko+cowy Efekty uboczne

24

In ynieria oprogramowania Faza okre lania wymaga+ Lista postulatów, które powinny by/ spe nione przez dokumentacj wymaga% (Heninger 1980). Dokumentacja powinna: 1. 2. 3. 4. 5. 6.

okre la zachowanie systemu jedynie z zewn%trz, okre la ograniczania implementacji, by $atwo modyfikowalna, by informatorem dla konserwatorów systemu, obejmowa przewidywania przysz$ego cyklu ycia systemu, charakteryzowa akceptowalne reakcje na niepo %dane zdarzenia.

25

In ynieria oprogramowania Faza okre lania wymaga+ Struktura dokumentacji wymaga%: 1.

2.

3. 4. 5.

Wst p

1. 2. 3. 4. 5.

Przeznaczenie tej dokumentacji wymaga+ Zakres produktu Definicje, akronimy i skróty Odno niki Przegl%d pozosta$ej cz ci dokumentu

1. 2. 3. 4. 5.

Wizja produktu Funkcje produktu Charakterystyka u ytkowników Ogólne ograniczania Za$o enia i zale no ci

Ogólny opis

Szczegó$owe wymagania Dodatki Skorowidz. 26

In ynieria oprogramowania In ynieria wymaga+ 1. 2. 3. 4.

Studium wykonalno ci Okre lanie i analizowanie wymaga+ Zatwierdzanie wymaga+ Zarz%dzanie wymaganiami

27

In ynieria oprogramowania In ynieria wymaga+ Okre!lanie i analizowanie wymaga%:

28

In ynieria oprogramowania In ynieria wymaga+ Metod VORD (Viewpoint-Oriented Requirements Definition)

29

In ynieria oprogramowania In ynieria wymaga+ Szablon formularz punktów widzenia:

Nazwa cechy

Opis

Odno!nik

Nazwa punktu widzenia

Atrybuty

Atrybuty z informacj% o punkcie widzenia

Zdarzenia

Odno nik do zbioru scenariuszy zdarze+ opisuj%cych, jak system reaguje na zdarzenia w ramach tego punktu widzenia

Us ugi

Odno nik do zbioru opisów us$ug

Podrz dne punkty widzenia Nazwy podrz dnych punktów widzenia

30

In ynieria oprogramowania In ynieria wymaga+ Szablon formularza us ug:

Nazwa cechy

Opis

Odno!nik

Nazwa us$ugi

Uzasadnienie

Przyczyna oferowania us$ugi

Specyfikacja

Odno nik do listy specyfikacji us$ug, które mog% by opisane za pomoc% ró nych notacji

Punkty widzenia

Lista nazw punktów widzenia, których reprezentanci korzystaj% z us$ugi

Wymagania niefunkcjonalne

Odno nik do zbioru wymaga+ niefunkcjonalnych ograniczaj%cych us$ug

Dostawca

Odno nik do listy obiektów systemu, które oferuj% t us$ug 31

In ynieria oprogramowania In ynieria wymaga+ Strukturalizacja punktów widzenia (przyk$ad)

32

In ynieria oprogramowania In ynieria wymaga+ Zarz dzanie wymaganiami Istotne kwestie dotycz%ce zarz%dzania wymaganiami: 1. Oznakowanie wymaga+ 2. Proces zarz%dzania zmianami 3. Strategia ledzenia pochodzenia 4. U ycie narz dzi CASE Rodzaje informacji o pochodzeniu wymaga+: 1. Informacje o pochodzeniu 2. Informacje o uzale nieniu wymaga+ 3. Informacje o uzale nieniu projektu

33

In ynieria oprogramowania In ynieria wymaga+ Macierz zale no!ci: Identyfikator wymagania

1 1.1

1

1.1

1.2

1.3

U

R

1.2 1.3 2

2 2.1

2.2

U R

3 2.3

3.1

R

U

R

2.1

R

U

2.2 2.3 3

U R

U

3.1 3.2

3.2

R R 34

In ynieria oprogramowania Faza analizy Modelowanie Analiza – procedura studiowania dziedziny problemu, prowadz%ca do wyspecyfikowania zachowania mo liwego do zaobserwowania z zewn%trz; kompletne, zgodne i wykonalne stwierdzenie, czego potrzebujemy; okre lenie zarówno funkcjonalno ci, jak i ilo ciowych charakterystyk operacyjnych (np. niezawodno ci, dost pno ci, wydajno ci). W fazie analizy wymagania zebrane od klienta s% przetwarzane na sformalizowan% specyfikacj opisuj%c% dzia$anie systemu widzian% z zewn%trz, wi c nie zawieraj%c% szczegó$ów dot. implementacji. Wynikiem analizy jest logiczny model systemu opisuj%cy sposób realizacji przez system postawionych wymaga+.

35

In ynieria oprogramowania Faza analizy W procesie analizy istotne jest przej cie pomi dzy perspektyw% z jakiej widzi system klient na perspektyw , któr% w wyniku analizy zobaczy projektant.

Wy wietlanie opisu symbolu

Zmiana skali

Edycja parametrów mapy

Zarz!dzanie mapami

Wy wietlanie mapy Zamkniêcie mapy

Edycja t a Edycja/wybór s ów kluczowych Wybór s ów kluczowych

Projektant

U ytkownik Odczyt mapy

Wy wietlanie opisu mapy

Edycja/wybór wzorów symboli

Edycja symboli graficznych

36

In ynieria oprogramowania Faza analizy Przyk$ady diagramów funkcji:

Edycja/wybór s ów kluczowych

Dodawanie symbolu

Dodawanie s owa kluczowego

Edycja s owa kluczowego

uses

uses

Edycja/wybór wzorów symboli

uses

Edycja symbolu Edycja symboli graficznych

Tworzenie nowej mapy

Odczyt mapy

uses

uses

uses

Edycja/wybór s ów kluczowych

uses uses

uses

uses

uses Wy wietlanie mapy

Zarz!dzanie mapami uses

uses

uses

Modyfikacja symboli

Usuwanie s ów kluczowych

uses

uses

Zaznaczanie i przesuwanie symboli

Usuwanie symboli uses

uses Zamkni'cie mapy

uses

uses

Zapis mapy

uses

Wy wietlanie mapy

uses

Usuni'cie wszystkich symboli

37

In ynieria oprogramowania Faza analizy Najwa niejsze 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$o onych oraz elementarnych, • definicji metod, harmonogram fazy projektowania.

38

In ynieria oprogramowania Faza analizy Punkty widzenia procesu analizy: • • •

Zewn trzny (modelowanie kontekstu lub rodowiska systemu), Zachowania (modelowanie zachowania systemu, przep$yw danych, maszyny stanowe), Strukturalny (modelowanie architektury systemu lub przetwarzania danych)

39

In ynieria oprogramowania Faza analizy Modele kontekstowe We wczesnej fazie procesu modelowania nale y ustali granice systemu. W tym celu tworzone s% modele architektoniczne uzupe$niane przez modele procesu.

40

In ynieria oprogramowania Faza analizy Modele zachowania S% one u ywane 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 zst puj%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 wewn trzne lub zewn trzne: zdarzenia, które powoduj% przej cia z jednego stanu do drugiego. • Nie obejmuj% one przep$ywu danych. 41

In ynieria oprogramowania Faza analizy Metoda przep ywu danych Przep yw danych sk$ada si z nast puj%cych elementów: modyfikacja danych magazynowanie danych opisy procesów s$owniki danych magazyny danych Bardzo po yteczne okazuj si roz$o enie zdarzenia (np. %dania transakcji) i okre lenie kroków podj tych w odpowiedzi na te zdarzenia. W analizie obiektowej stosuje si takie podej cie przy wybieraniu us$ug i kroków 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

In ynieria oprogramowania Faza analizy Diagramy przep ywu danych sk adaj si z nast puj cych elementów:

proces

przep$yw sk$adnica obiekt zewn trzny 43

In ynieria oprogramowania Faza analizy Zale no!ci pomi dzy podstawowymi elementami DFD. Obiekt zewn trzny

Przep yw danych

Proces

Przep yw danych

Sk adnica danych 44

In ynieria oprogramowania Faza analizy Przyk$ad DFD dla procesu zamawiania towarów. S1

2.1

zamówienie

KLIENT

faktura

TOWARY

ZAMAWIANIE TOWARÓW

Dzia zamówie

S2

zamówienie hurtowe

HURTOWNIA

list przewozowy

DOSTAWCY

45

In ynieria oprogramowania Faza analizy Przyk$ad diagramu maszyny stanowej.

46

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

47

In ynieria oprogramowania Faza analizy Przyk$ady diagramów ERD przesy a

KLIENT jest z o one

SKLEP mo e z o y+

i

MAGAZYN

zamawia

ZAMÓWIENIE

jest przewo ony

PRACOWNIK

kieruje

TOWAR

POJAZD

lub

jest przechowywany

MAGAZYN

48

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

49

In ynieria oprogramowania Faza analizy Podsumowanie:

50

In ynieria oprogramowania Faza projektowania Projektowanie – dzia$anie polegaj%ce na wzi ciu 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

In ynieria oprogramowania Faza projektowania Na projektowanie sk ada si : • •

• • •

uszczegó$owienie wyników analizy, projektowanie sk$adowych systemu nie zwi%zanych z dziedzin% problemu (s% to m.in.: interfejs u ytkownika, zarz%dzanie danymi sk$adowe te s% konieczne z punktu widzenia prawid$owej pracy systemu), optymalizacja systemu, dostosowanie do ogranicze+ i mo liwo ci rodowiska implementacji, okre lenie fizycznej struktury systemu (podzia$ kodu Nród$owego na modu$y, a w systemach rozproszonych tak e umieszczenie odpowiednich sk$adowych na odpowiednich serwerach).

52

In ynieria oprogramowania Faza projektowania Najwa niejsze 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 definicji definicji definicji

klas, pól, danych z$o onych oraz elementarnych, metod,

zasoby interfejsu u ytkownika, np. menu, dialogi..., projekt bazy danych, projekt fizycznej struktury systemu, poprawiony plan testów, harmonogram fazy implementacji.

53

In ynieria oprogramowania Faza projektowania Uszczegó owienie wyników analizy

Cz

konstrukcji powsta$ych w fazie analizy nie mo na w sposób bezpo redni przekszta$ci w posta kodu Nród$owego. Uszczegó$owienie specyfikacji: • Okre lenie typów danych. • Okre lenie nag$ówków metod (parametry wraz z typami oraz typ wyniku) • Uszczegó$owienie opisu algorytmów. • Okre lenie które metody mog% by zdefiniowane jako wirtualne. • Okre lenie 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 (najcz ciej), identyfikatorami obiektów powi%zanej klasy (w przypadku baz danych).

Je eli obiekty danej klasy zwi%zane s% z wi cej ni jednym obiektem innej klasy, to nale y stosowa z$o one struktury danych b d%ce: tablicami obiektów, listami obiektów, tablicami nazw.

54

In ynieria oprogramowania Faza projektowania Zwi zki wielokrotne

55

In ynieria oprogramowania Faza projektowania Projektowanie sk adowych systemu nie zwi zanych z dziedzin problemu. •

• • •

sk$adowa interfejsu u ytkownika, odpowiedzialna za realizacj komunikacji z u ytkownikiem (w projektowaniu systemów dedykowanych sprz towo interfejs u ytkownika wchodzi do dziedziny problemu), sk$adowa zarz%dzania danymi, odpowiedzialna za realizacj (na poziomie fizycznym) sposobu przechowywania trwa$ych danych, sk$adowa zarz%dzania pami ci% operacyjn%, sk$adowa zarz%dzania zadaniami, odpowiedzialna za przydzia$ czasu procesora (procesorów) do poszczególnych zada+.

56

In ynieria oprogramowania Faza projektowania Projektowanie sk adowych systemu nie zwi zanych z dziedzin problemu.

57

In ynieria oprogramowania Faza projektowania Projektowanie sk adowej kontaktu z u ytkownikiem. Nowoczesne systemy zarz%dzania interfejsem u ytkownika: • interaktywne projektowanie dialogów, okien, menu, map bitowych, ikon oraz pasków narz dziowych z wykorzystaniem bogatego zestawu gotowych elementów, • definiowanie reakcji systemu na zaj cie pewnych zdarze+, tj. akcji podejmowanych przez u ytkownika (np. wybór opcji z menu), • symulacja pracy interfejsu, • generowanie kodu, cz sto z mo liwo ci% wyboru jednego z kilku rodowisk docelowych. Dwa podstawowe sposoby realizacji komunikacji z u ytkownikiem: • za pomoc% linii komend, • w pe$noekranowym rodowisku okienkowym.

58

In ynieria oprogramowania Faza projektowania Projektowanie sk adowej kontaktu z u ytkownikiem. Komunikacja u ytkownika z systemem komputerowym polega na: • wydawaniu przez u ytkownika polece+, • przep$ywie danych pomi dzy u ytkownikiem a systemem. Typowe sposoby wydawania przez u ytkownika polece% systemowi to: • wpisywanie polece+ za pomoc% linii komend, • wybór opcji z menu, • wci ni cie odpowiedniej kombinacji klawiszy (skrótu), • korzystanie z ikon w paskach narz dziowych, • wybór przycisku w dialogu, • korzystanie z przycisków myszy.

59

In ynieria oprogramowania Faza projektowania Projektowanie sk adowej kontaktu z u ytkownikiem. 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 u ytkownikowi danych to: • wy wietlanie informacji w dialogach, • wy wietlanie i/lub wydruki raportów, • graficzna prezentacja danych.

60

In ynieria oprogramowania Faza projektowania Projektowanie sk adowej kontaktu z u ytkownikiem. Podstawowe zasady projektowania interfejsu u ytkownika: • Spójno (podobny rozk$ad komponentów na wszystkich dialogach, podobne kolory, czcionka, itp.; nale y tak e uwzgl dni spójno z innymi aplikacjami oraz z samym rodowiskiem). • Skróty klawiszowe dla do wiadczonych u ytkowników. • Potwierdzanie przyj cia polecenia u ytkownika. • Prosta obs$uga b$ dów. • Odwo$ywanie akcji. • Wra enie kontroli nad systemem. • Nieobci% anie pami ci krótkotrwa$ej (nazwy wykonywanych czynno ci powinny by widoczne w tytule okna, aby u ytkownik zawsze wiedzia$, jaka operacja jest wykonywana). • Grupowanie powi%zanych operacji (kreatory - prowadzenie u ytkownika przez szereg dialogów).

61

In ynieria oprogramowania Faza projektowania Projektowanie sk adowej kontaktu z u ytkownikiem. Przyk$ad:

62

In ynieria oprogramowania Faza projektowania Projektowanie sk adowej zarz dzania danymi.

Bazy danych

63

In ynieria oprogramowania Faza projektowania Okre!lenie fizycznej struktury systemu. Dzia$ania podejmowane w ramach okre lania fizycznej struktury systemu: •

Okre lenie struktury kodu Nród$owego, tj. wyró nienie plików Nród$owych, zale no ci pomi dzy 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

In ynieria oprogramowania Faza projektowania Okre!lenie fizycznej struktury systemu. Notacja Boocha: deklaracja

definicja

modu$ g$ówny

Nazwa

Nazwa

Nazwa

Symbol.h

Symbol.c

Zale no ci kompilacji:

Punkt.h

65

In ynieria oprogramowania Faza projektowania Okre!lenie fizycznej struktury systemu. Du e systemy mog% obejmowa : •

jeden lub wiele serwerów baz danych,

•

jeden lub wiele serwerów aplikacji,

•

wiele stacji roboczych.

Dzia marketingu PC

Serwer baz danych dzia u marketingu

Serwer baz danych dzia u kontroli jako ci

PC PC

G ówny serwer bazy danych przedsi'biorstwa

PC Serwer aplikacji dzia u marketingu

P ace PC

Zakupy

PC PC

Serwer baz danych dzia u finansowego

PC

PC

PC

PC

Serwer plików dzia u finansowego

66

In ynieria oprogramowania Faza projektowania Poprawno!/ projektu. Poprawno projektu oznacza, e jego opis jest on zgodny z zasadami 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$o one i elementarne, • a tak e, e opisany jest sposób realizacji wszystkich wymaga+ funkcjonalnych.

67

In ynieria oprogramowania Faza projektowania Poprawno!/ projektu. Niesprzeczno oznacza, e sprzecznych definicji.

aden element nie ma dwóch lub wi cej

Spójno oznacza semantyczn% zgodno diagramach i w specyfikacji.

informacji zawartych na ró norodnych

Jako!/ projektu. Kryteria jako!ci projektu: •

spójno ,

•

stopie+ powi%za+ sk$adowych,

•

przejrzysto . 68

In ynieria oprogramowania Faza projektowania Jako!/ projektu. Rodzaje spójno!ci: • Spójno przypadkowa. przypadkowa. Powstaje np. wtedy, gdy programista dzieli program na modu$y tylko tylko dlatego, e umieszczenie wszystkich funkcji w jednym du ym pliku utrudnia$o lub uniemo liwia$o jego edycj . • Spójno logiczna. logiczna. Poszczególne sk$adowe realizuj% podobne funkcje, np. obs$ug b$ b$ dów, wykonywanie podobnych oblicze+. • Spójno czasowa. czasowa. Sk$adowe s% uruchamiane/wykorzystywane w podobnym czasie, np. przy starcie lub ko+cu pracy systemu. • Spójno proceduralna. proceduralna. Sk$adowe tworz% sekwencj wykonania, czyli s% kolejno uruchamiane. uruchamiane. • Spójno komunikacyjna. Sk$adowe operuj% wspólnie na tym samym zestawie zestawie danych wej ciowych i wspólnie produkuj% ten sam zestaw danych wyj ciowych. ciowych. • Spójno sekwencyjna. sekwencyjna. Dane wyj ciowe jednej sk$adowej s% danymi wej ciowymi kolejnej sk$adowej. • Spójno funkcjonalna. funkcjonalna. Wszystkie sk$adowe s% niezb dne 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 jej jej metody ustawiaj%, modyfikuj% i odczytuj% te pola.

69

In ynieria oprogramowania Faza projektowania Jako!/ projektu Powi zania: 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 rzeczywisto ci. • Spójno oraz stopie+ powi%za+ sk$adowych. • Zrozumia$e nazewnictwo. • Czytelna i pe$na specyfikacja. • Odpowiednia z$o ono sk$adowych. 70

In ynieria oprogramowania Faza implementacji Implementacja jest to proces kodowania projektu do postaci zgodnej ze specyfikacj% danego j zyka (lub j zyków) programowania. Poj cie programowania cz sto bywa, w sposób nies$uszny, uto samiane z poj ciem kodowania (implementacji.) Znacz%c% ilo czasu poch$ania nie tyle tworzenie kodu, lecz znajdowanie b$ dów. Z tego w$a nie powodu sztuka implementacji dzieli si na techniki kodowania, w ród których bardzo istotn% rol pe$ni% elementy maj%ce na celu unikanie b$ dów. Osobnym zagadnieniem jest umiej tno znajdowania b$ dów oraz techniki kodowania, które mog% znacznie przyczyni si do u$atwienia tego zadania. Jedn% z wa niejszych jest zasada need-to-know, wg której informacje powinny by udost pnione tylko tym którzy ich naprawd potrzebuj%.

71

In ynieria oprogramowania Faza implementacji Automatyzacja fazy implementacji: • • • • •

J zyki wysokiego poziomu. Biblioteki procedur, struktur, obiektów. Programowanie komponentowe. Narz dzia typy RAD. Narz dzia typu CASE.

Niezawodno!/ oprogramowania: • zasada ograniczonego dost pu, • kompilatory sprawdzaj%ce zgodno • unikanie niebezpiecznych technik.

typów,

72

In ynieria oprogramowania 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ó$bie ne (wspó$dzielenie danych przez wiele procesów), przerwania, rekursja (niesko+czone p tle, przepe$nienie stosu, trudno analizy) z$o one wyra enia wymagaj%ce uwzgl dnienia priorytetów operatorów, przenoszenie kodu Nród$owego z jednego rodowiska programowania do innego, unikanie komentowania kluczowych fragmentów kodu. 73

In ynieria oprogramowania Faza implementacji Tolerancja b dów (nieczu o!/ na b dy i stany niepo

dane):

Zadania konieczne do realizacji tolerancji b dów: • wykrycie b$ du, • wyj cie z b$ du, • ewentualna naprawa b$ du. Sposoby realizacji: • weryfikacja poprawno ci warto ci zmiennych i atrybutów, • wprowadzanie warunków integralno ci (w bazach danych), • warto ci domy lne, • programowanie N-wersyjne • technika zapasowych modu$ów.

74

In ynieria oprogramowania Faza implementacji Podsumowanie Kluczowe czynniki sukcesu: • zysoka jako i odpowiedni poziom szczegó$owo ci 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 wst pnych testów • dostrojona baza danych, • harmonogram fazy testowana. 75

In ynieria oprogramowania Faza dokumentacji Faza dokumentacji cz sto wykonywana jest równolegle do innych faz. Na ko+cowym etapie wykonywana jest dokumentacja u ytkownika. Istotne problemy tworzenia dokumentacji u ytkownika: • ró norodno odbiorców, • niski poziom znajomo ci zagadnie+ informatycznych odbiorców, • nieznajomo za$o e+ opracowanego oprogramowania (modelu), • zainteresowanie tylko wybranymi obszarami zrealizowanych wymaga+ funkcjonalnych. Ponadto istnieje szereg zagadnie% natury psychologicznej np.: Obszerna instrukcja – niech do zapoznania si („Trzeba po wi du o czasu”) Zwi z$a instrukcja – „Tematy potraktowane pobie nie wi c i tak wi kszo pewnie trzeba b dzie samemu pozna ” Poj cia informatyczne – „Nie rozumiem tych poj ” (nawet jak s% zdefiniowane, ewentualnie „nie rozumiem definicji”) 76

In ynieria oprogramowania Faza dokumentacji Odbiorcy dokumentacji: • administratorzy systemu, • odbiorcy ko+cowi, • osoby zatwierdzaj%ce oprogramowanie. Ka da z tych grup oczekuje innego sposobu opisu dokumentacji, oraz najcz ciej nie toleruje elementów zb dnych z ich punktu widzenia. Pewnym rozwi%zaniem jest opracowanie kilku wersji, co w oczywisty sposób zwi ksza nak$ad pracy oraz utrudnia piel gnacj systemu. Innym rozwi%zaniem jest zastosowanie odpowiedniego u$o enia tre ci dokumentu, które w sposób $atwy pozwoli danemu odbiorcy zdecydowa czy dany fragment jest z jego punktu widzenia istotny.

77

In ynieria oprogramowania Faza dokumentacji Elementy sk adowe dokumentacji u ytkowej: • Opis funkcjonalny (przeznaczenie oprogramowania, mo liwo ci, ograniczenia, wymagania) • Podr cznik u ytkowania (sposoby uruchamiania i ko+czenia pracy z programem, sposób wykorzystania poszczególnych funkcjonalno ci, opis interfejsu u ytkownika, opis przyj tych standardów komunikacji z u ytkownikiem, 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. • Podr cznik administratora (zarz%dzanie, piel gnacja). • S$ownik u ywanych poj . • Indeks.

78

In ynieria oprogramowania Faza dokumentacji Zasady dotycz ce sposobu pisania dokumentacji u ytkownika: • Stosowanie formy aktywnej i zwracanie si do u ytkownika (mniej formalny i w naszym obszarze kulturowym nie zawsze dobrze przyjmowany) • Poprawno j zykowa (gramatyka, ortografia, stylistyka). • Komunikatywno (krótkie zdania, krótkie akapity, oszcz dno s$ów, unikanie skomplikowanych form j zykowych oraz wtr%ce+) • Precyzyjna, ale i czytelna definicja poj . • Powtórzenia w zakresie istotnych oraz trudniejszych fragmentów. • Cz sto 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 wa no ci oraz trudno ci. • Stosowanie opisów opatrzonych licznymi rysunkami (zrzuty ekranów, diagramy). • Bardzo wyraNne podkre lanie co jest konieczne do realizacji opisywanego zadania, a co jest mo liwe. 79

In ynieria oprogramowania Faza testowania W sk ad testowania wchodz dwa g ówne procesy: • Atestowanie (cz sto zwane walidacj% – validation) – testowanie czy oprogramowanie spe$nia rzeczywiste potrzeby u ytkownika. Jest to odpowiedz na pytanie czy budowane oprogramowanie jest naprawd potrzebne u ytkownikowi. • Weryfikacja (veryfication) – testowanie zgodno ci systemu z wymaganiami okre lonymi w fazie okre lania wymaga+. Jest to odpowiedz na pytanie czy we w$a ciwy sposób realizowane s% wymagania u ytkownika. Celem testowania jest: • wykrycie i usuni cie b$ dów w oprogramowaniu, • ocena niezawodno ci oprogramowania. Z punktu widzenia cyklu ycia oprogramowania wyró nia si testy: • ALFA, • BETA, • GAMMA. 80

In ynieria oprogramowania Faza testowania Rodzaje testów: • dynamiczne – –

•

funkcjonalne strukturalne

statyczne – –

dowody poprawno ci metody nieformalne

Typowe b dy: – – – – – – – –

niezainicjowane zmienne, b$ dne porównania liczb zmiennopozycyjnych, przekroczenie zakresu tablicy, operacje na wskaNnikach, b$ dy w wyra eniach logicznych instrukcji warunkowych i iteracyjnych, b$ dy dotycz%ce warunków granicznych (>=, >,