Wykład 7. Projektowanie kodu oprogramowania

Transkrypt

1 Wykład 7 Projektowanie kodu oprogramowania

2 Treść wykładu cykl życiowy oprogramowania zagadnienia inżynierii oprogramowania tworzenie oprogramowania z gotowych elementów tworzenie niezawodnego oprogramowania unikanie błędów niebezpieczne techniki kontrola typów sposoby aktywnej weryfikacji oprogramowania rodzaje testów wykrywanie błędów

3 Cykl życiowy oprogramowania Wymagania Tekst Analiza/Projekt Implementacja Testowanie Pielęgnacja Zarządzanie projektem - Prototypowanie Malarz menu Wydajność Model danych Malarz ekranu Śledzenie Zarządzanie modyfikacjami Model procesu Języki programowania Repozytorium Biblioteka funkcji Śledzenie SQL Testowani e Zarządzanie dystrybucją Zarządzanie wersjami

4 Przejrzysta struktura programu testowanie przenoszenie pielęgnacja rozszerzenie reorganizacja zrozumienie

5 Programiści vs. Projektanci istnieje podejście, że programiści nie powinni podejmować decyzji projektowych a projektanci nie powinni interesować się szczegółami kodowania cechy podejścia niewystarczająca komunikacja między implementatorami a projektantami prowadzi do opóźnień, nieefektywności i wielokrotnie powracających problemów niewystarczające pole do inicjatywy wśród implementatorów prowadzi do braku rozwoju profesjonalnego, braku inicjatywy

6 Kryzys oprogramowania stosowanie technik i i narzędzi ułatwiających pracę nad złożonymi projektami usystematyzowanie procesu wytwarzania oprogramowania planowanie i monitorowanie tworzenie oprogramowania wymaga profesjonalnego podejścia dekompozycja problemu na mniejsze komponenty ponowne użycie gotowych komponentów dostosowanie metod tworzenia oprogramowania do naturalnej ludzkiej percepcji

7 Zagadnienia inżynierii oprogramowania sposoby prowadzenia przedsięwzięć informatycznych techniki zwiększania niezawodności oprogramowania sposoby testowania oprogramowania sposoby przygotowania dokumentacji technicznej i użytkowej procedury kontroli jakości metody redukcji kosztów konserwacji, usuwania błędów, dodawania rozszerzeń techniki pracy zespołowej

8 Tworzenie oprogramowania z gotowych elementów możliwość redukcji nakładów związanych z oprogramowaniem poprzez wykorzystanie podobieństwa gotowego oprogramowania wykorzystywane są biblioteki języki czwartej generacji pełne aplikacje ponowne użycie zakup elementów ponownego użycia od dostawców przygotowanie elementów do ponownego użycia wysoka niezawodność zmniejszenie ryzyka efektywne wykorzystanie zasobów stosowanie standardów koszty związane z przygotowaniem elementów do ponownego użycia uzależnienie się od dostawcy

9 Szacowanie kosztu oprogramowania szacowanie rozwiązania dla każdego alternatywnego rozwiązania koszt oprogramowania koszt sprzętu koszt wyjazdów i szkoleń koszt zakupu narzędzi koszt związany z nakładami pracy

10 Techniki szacowania nakładów pracy modele algorytmiczne atrybuty liczbowe oraz opisowe, przypisywanie różnych wag rozmiar systemu liczony w liniach kodu źródłowego ekspert/eksperci ocena przez analogię dostęp do przedsięwzięć poprzednio realizowanych prawo Parkinsona zaplanowane nakłady zawsze zostaną wyczerpane wycena zgodnie z oczekiwaniami klienta koszty szacowane na podstawie oczekiwań klienta oraz konkurencji szacowanie wstępujące podział na mniejsze zadania

11 Tworzenie niezawodnego oprogramowania niezawodność wzrastające znaczenie niezawodności oprogramowania duże koszty związane z błędnie działającymi funkcjami oprogramowania kompromis między efektywnością a niezawodnością zwiększenie niezawodności unikanie błędów tolerowanie błędów

12 Unikanie błędów unikanie niebezpiecznych technik programowania stosowanie zasady ograniczonego dostępu hermetyzacja, reguły zakresu, podział pamięci stosowanie języków z kontrolą typów i kompilatorów sprawdzających zgodność typów stosowanie języków o wyższej klasie abstrakcji stosowanie standardów dla interfejsów wymiany danych pomiędzy modułami śledzenie warunków brzegowych - pętle z zerową ilością przebiegów, niezainicjowane zmienne, wartości zerowe wykorzystywanie gotowych komponentów minimalizacja różnic pomiędzy modelem pojęciowym a modelem implementacyjnym

13 Niebezpieczne techniki stosowanie liczb ze zmiennym przecinkiem arytmetyka na wskaźnikach obliczenia równoległe bazujące na zależnościach czasowych - synchronizacja przerwania i wyjątki rekursja przydzielanie oraz zwalnianie pamięci różne działanie tych samych procedur oraz funkcji w zależności od zmiennych parametrów wejściowych brak specyfikacji efektów ubocznych funkcji złożone wyrażenia bez stosowania operatorów priorytetu brak synchronizacji i blokowania transakcji, funkcji działających na wspólnych zasobach

14 Kontrola typów typ jest przypisany do zmiennej, wyrażenia, danej, funkcji, procedury, operacji, metody, parametru, procedury, wyjątku, zdarzenia typ specyfikuje rodzaj przyjmowanej wartości typ narzuca strukturę bytu programistycznego, specyfikuje parametr oraz wynik typ wspomaga kontrolę poprawności programu programista poprzez typ wyraża rolę jak byt programistyczny przyjmuje w programie kontrola typów okazała się skutecznym mechanizmem usuwania błędów programistycznych

15 System statycznej kontroli typów specyfikacje wszystkich typów oraz zmiennych specyfikacje w postaci sygnatur wszystkich parametrów oraz funkcji specyfikacja interfejsów, modułów, klas specyfikacja parametrów wejściowych oraz wyjściowych przekazywanych poprzez wartość lub referencję specyfikacja reguł wnioskowania o typie

16 Tolerowanie błędów program działa nawet wtedy kiedy zawiera błędy tolerowanie błędów oznacza wykrycie przez program błędu wyjścia z błędu poprzez poprawne zakończenie pracy modułu w którym nastąpił błąd naprawa programu poprzez jego zmianę sposoby automatycznego wykrywania błędów asercje sprawdzające poprawność badanych danych w postaci dodatkowych elementów kodu porównywanie wyników różnych wersji modułów: programowanie n-wersyjne przez niezależne zespoły programistów

17 Transakcje transakcja umożliwia powrót do stanu systemu przed rozpoczęciem jej działania po wystąpieniu dowolnego błędu podstawowa technika zwiększenia niezawodności oprogramowania działającego na bazie danych cechy transakcji atomowość - w ramach jednej transakcji wykonują się albo wszystkie operacje albo żadna spójność - transakcja nie narusza spójności bazy danych z przed wykonania transakcji izolacja - wykonywana transakcja nie wie o działaniu innych transakcji i nie musi uwzględniać ich działania, czynności wykonywane przez daną transakcję są niewidoczne dla innych transakcji aż do jej zakończenia trwałość - po zakończeniu transakcji jej skutki działania są trwale zapamiętane w bazie danych i nie mogą być odwrócone przez zdarzenia losowe

18 Języki proceduralne jako środowisko implementacyjne procesy i moduły wysokiego poziomu mogą odpowiadać całym aplikacjom grupy procedur i funkcji odpowiadają poszczególnym funkcjom systemu dają niewielkie możliwości ograniczenia dostępu do danych składnice danych odpowiadają strukturom danych

19 Języki obiektowe jako środowisko implementacyjne proste odwzorowanie modelu konceptualnego do poziomu implementacji wymagają współpracy z bazą danych większość języków obiektowych to języki hybrydowe powstałe w wyniku wzbogacenia języków proceduralnych o cechy obiektowe

20 Relacyjne bazy danych wielodostęp automatyczna weryfikacja więzów integralności autoryzacja dostępu użytkowników niezawodność skalowalność praca w środowisku rozproszonym dostęp do danych z wykorzystaniem SQL, ODBC, JDBC brak hermetyzacji i innych cech obiektowości

21 Obiektowe bazy danych implementacja modelu obiektowego z wykorzystaniem narzędzi o wyższej klasie abstrakcji uproszczenie i usystematyzowanie procesu projektowania i implementacji zmniejszenie dystansu pomiędzy fazami analizy, projektowania i programowania model obiektowy wprowadza wiele pojęć obiektowości wspomagających proces projektowania oraz implementacji pojęcia obiektowe złożone obiekty, tożsamość, powiązania, klasy, hierarchia dziedziczenia, metody, hermetyzacja, późne wiązania, polimorfizm, trwałość

22 Obiektowo-relacyjne bazy danych aspekty obiektowości wprowadzane są do systemów relacyjnych baz danych podejście hybrydowe lub obiektowo-relacyjne zachowanie sprawdzonych technologii relacyjnych wraz z językiem SQL

23 Sposoby aktywnej weryfikacji oprogramowania przeglądy techniczne sprawdzenie czy oprogramowanie jest zgodne z wymaganiami użytkownika sprawdzenie czy komponenty oprogramowania są weryfikowalne z punktu widzenia użytkownika testowanie modułów oprogramowania testowanie integracyjne modułów oprogramowania testowanie oprogramowania przez twórców oprogramowania testowanie oprogramowania przez użytkowników oprogramowania kontrola jakości oprogramowania pod względem przyjętych norm

24 Audyt oprogramowania niezależny przegląd i ocena jakości oprogramowania zapewnienie zgodności z wymaganiami na oprogramowanie oraz ze specyfikacją, założeniami, standardami osoby niezależne od zespołu projektowego

25 Rodzaje testów wykrycie jak największej liczby błędów wykrycie najczęściej powtarzających się błędów wykonywanie programów oraz porównywanie wyników z wynikami poprawnymi analiza kodu źródłowego

26 Fazy w testowaniu oprogramowania testy modułów wykonywane bezpośrednio po zakończeniu kodowania modułu testy systemu integracja modułów wraz z testowaniem poszczególnych podsystemów oraz systemu jako całości testy akceptacyjne przez użytkownika oprogramowanie jest przekazywane użytkownikowi do przetestowania

27 Elementy oprogramowania podlegające testowaniu wydajność systemu oraz jego poszczególnych funkcji zgodność interfejsu z wymaganiami użytkowników własności operacyjne systemu testy zużycia zasobów zabezpieczenie systemu przenośność oprogramowania niezawodność oprogramowania na błędy odtwarzalność oprogramowania po zaistniałych błędach wpływ błędów oprogramowania na inne składniki

28 Elementy oprogramowania podlegające testowaniu c.d. kompletność i jakość funkcji systemu zachowanie zasobów łatwość modyfikacji oprogramowania funkcjonowanie oprogramowania przy dużych obciążeniach skalowalność systemu akceptowalność oprogramowania kompletność i jakość dokumentacji

29 Testy statystyczne losowa konstrukcja danych wejściowych zgodna z prawdopodobieństwem pojawienia się tych danych określenie prawidłowego działania oprogramowania na tych danych porównanie wyników działania systemu z wynikami założonymi

30 Wykrywanie błędów - rodzaje testów testy funkcjonalne znajomość wymagań wobec testowanej funkcji testy powinny wykonywać osoby niezaangażowane w realizowanie funkcji testy strukturalne zakładają znajomość sposobu implementacji testowanych funkcji

31 Testy systemu testowanie wstępujące początkowo testowane są pojedyncze moduły następnie testowane są moduły wyższego poziomu testowanie odbywa się aż do osiągnięcia najwyższego poziomu trudności wynikające z zależności modułów od siebie, wprowadzanie implementacji szkieletowych testowanie zstępujące początkowo testowane są moduły wyższego poziomu moduły niższego poziomu zastępuje się implementacjami szkieletowymi po przetestowaniu modułów niższego poziomu do testowania dołączane są moduły niższego poziomu proces kończy się w momencie zintegrowania oraz przetestowania całego systemu

32 Testy wydajnościowe testy obciążeniowe zbadanie wydajności oraz niezawodności systemu podczas pracy z pełnym lub nadmiernym obciążeniem systemy wielodostępne oraz sieciowe - liczba użytkowników oraz transakcji testy odpornościowe sprawdzenie działania systemu w przypadku wystąpienia niepożądanych zakłóceń - brak zasilania, awaria sprzętowa, wprowadzenie niepoprawnych danych, sekwencja niepoprawnych poleceń