1) Szybkie sprawdzanie koncepcji systemu (proof–of–concept prototy-ping) 2) Projektowanie przez prototypowanie Podział opisu obiektu na poziomy wg stopnia detalizacji opisu – wydzielenie struktury obiektu (strukturyzacji) (design prototyping)
Umożliwia Opracowanie jednorodnych opisów (projektów) poszczególnych elementów Dostosowanie opisu do 3)Budowa systemu poprzez prototypowanie (development prototyping)
możliwości percepcji człowieka Obiekt – układ powiązanych ze sobą systemów
Prototypowanie – zastosowanie:
Zasada dekompozycji:
Niewielki zakres przedsięwzięcia
podział złożonego obiektu na mniejsze części
Krótki czas realizacji SI
możliwość rozłączonego projektowania poszczególnych części z uwzględnieniem ograniczeń i związków z innymi Ograniczone fundusze na realizację SI
elementami
Niezdecydowany i trudny użytkownik
Modelowanie pojęciowe:
Dynamiczność sytuacji gospodarczej, opisywanej w SI
modelowanie pojęciowe (conceptal modeling) o model pojęciowy (conceptal model) powstaje w wyniku procesów Prototypowanie – narzędzia:
myślowych i wyobrażeń towarzyszących nad SI
Generatory interfejsu i oprogramowania
modelowanie pojęciowe jest wspomagane przez wzmacniające ludzką pamięć i wyobraźnię Programowanie wizualne
służy ono do przedstawienia rzeczywistego opisywania danych procesów zachodzących w rzeczywistości, struktur oraz Wykorzystanie gotowych komponentów
programów składających się na konstrukcje
Języki wysokiego poziomu (4GL, SQL)
notacje
Szybkie oprogramowanie
Notacje w IO – rodzaje:
Papier, tablica, mazaki
-Język naturalny -Notacje graficzne
Programowanie odkrywcze
-Specyfikacje,ustrukturalizowany zapis tekstowy numeryczny
Programowanie odkrywcze (Exploratory Programming):
Technika, metoda i metodyka
(+) Szybkie rozpoczęcie prac z trudnym użytkownikiem
Technika – sposób wykorzystania narzędzi (np. aparat pojęciowy, wzory, notacje, oprogramowanie) do rozwiązywania (-) Dodatkowy koszt, brak ścisłej specyfikacji systemu, brak możliwości zachowania sensownej struktury i problemów
niezawodności systemu, brak dokumentacji, amatorski sposób budowy SI
Metoda – celowy sposób posługiwania się i wykorzystywania technik
Montaż z gotowych komponentów
Metodyka – zespół wytycznych dotyczących metod, efektywnych ze względu na określony cel Projekt
Metodyka IO
-Zakup elementów od dostawców -Integracja ich w SI
Fazy projektu, role uczestników projektu
Zalety:
Modele tworzone w każdej z faz
-wysoka niezawodność -zmniejszenie ryzyka
Scenariusze postępowania w każdej z faz
-Efektywność wykorzystania specjalistów
Reguły przechodzenia od fazy do następnej fazy
-Narzucenie standardów
Notacje, których należy używać
Wady:
Dokumentacje powstają w każdej z faz
-Dodatkowy koszt przygotowania elementów
Typy metodyk:
-Ryzyko uzależnienia się od dostawcy elementów
-Strukturalna (model danych i przetwarzań – procesów)
-Niedostatki istniejących narzędzi
-Obiektowe (model obiektów z danymi procesów) -Mieszane
Metodyka ORACLE:
Rodzaje struktur SI:
CASE * Method – własna metodyka firmy ORACLE (dostosowana do wytwarzania SI metodami CASE firmy Funkcjonalna – zakres tematyczny, cele, funkcje SI, podział systemu na podsystemy, moduły, funkcje i zadania ORACLE)
Informacyjna – dane WE i WY, zbiory danych w SI, algorytmy
Analiza strategiczna obejmuje całość prac, następne etapy dotyczą poszczególnych fragmentów systemu Techniczna – środki techniczne, niezbędne do realizacji (konfiguracja, parametry, urządzenia we/wy) Uwarunkowania doboru metodyki projektowania SI:
Przestrzenna – rozmieszczenie obiektów SI
Wielkość przedsięwzięcia (zakres tematyczny SI, rozbudowa SI, wielkość i złożoność struktury, danych, złożoność Oprogramowania – zbiór programów narzędziowych i czynniki określające struktury.
algorytmów)
Cykl życia SI (Software Life Cycle) – proces złożony z ciągu wzajemnie spójnych etapów pozwalający na pełne i Czasokres realizacji przedsięwzięcia
skuteczne stworzenie, a następnie użytkowanie SI, obejmuje okres od momentu uświadomienia potrzeby istnienia Współpraca z użytkownikiem
systemu do momentu jego wycofania z eksploatacji.
Wielkość i umiejętności zespołu projektującego SI (liczba osób, znajomość dziedziny przedmiotowej, znajomość Cykl życia – typowe etapy:
narzędzi projektowo – programowych, CASE)
-Faza strategiczna -Określenie wymagań
Dostępność narzędzi
-Analiza systemowa -Projektowanie (modelowanie) -Implementacja
Cena opracowania systemu (fundusze na użytkowanie SI i fundusze na realizację konkretnego zakresu prac projektowo
-Dokumentacja -Testowanie -Instalacja -Konserwacja, rozwój
– wdrożeniowych)
Modele cyklu życia SI:
Rezultaty wyboru metodyki
-kaskadowy -prototypowanie
-Kolejność i zakres prac -Zawartość dokumentacji
-spiralny -przyrostowy (ewolucyjny) -montaż z gotowych elementów (komponentowych) -inne (ORACLE, RAD, V)
-Koszty -Metodyki modelowania i projektowania, notacje
Model kaskadowy (liniowy, klasyczny, waterfall):
Modelowanie SI:
Założenia: stabilny zestaw potrzeb i ich niezmienność w trakcie budowy SI, modelowa praca zespołów (top – down) rezultat logiczny model systemu
+ Upraszcza zarządzanie u ułatwia planowanie
techniki modelowania SI:
-Narzucenie ścisłej kolejności prac, wysoki koszt błędów popełnionych na początku, długa przerwa w kontaktach z
-strukturalne (diagramy przepływu danych – DF, diagramy związków encji – ERD)
klientem
-obiektowe (diagramy klas i obiektów, diagramy interakcji i przejść stanów)
Model z prototypem:
Projektowanie:
Prototyp – model SI, działający lub demonstrujący działanie SI
Rezultat: jak ma system być zaimplementowany
+Zaangażowanie użytkownika, wczesne wykrycie różnic w rozumieniu SI (funkcji, specyfikacji), możliwości szkoleń na Obszar:
prototypie
-Interfejs użytkownika (układ menu, szata we/wy, komunikacja)
- Dodatkowy koszt, uproszczenia, niebezpieczeństwo poprzestania na prototypie, przekonanie użytkownika o łatwości
-Fizyczna struktura BD i kodu progr. (podsystem, moduły, procedury i funkcje)
tworzenia SI
Optymalizacja projektu dostosowana do wy. Środowiska
Prototypowanie – techniki:
Metodyki strukturalne:
-Kodowanie danych (wartości, algorytmy, weryfikacja i maski)
Uważa się, że wadą metodyk strukturalnych są trudności w zintegrowaniu modeli
Zasady budowy MPB
Metodyki strukturalne nie przystają do obiektowej implementacji SI
Zdarzenia wej. i wyj. (zakończenie procesów)
Metodyki strukturalne są dojrzałe, ale mogą nie być adekwatne do współczesnych tendencji produkcji SI Blok decyzyjny ma minimum 2 wyjścia
Modelowanie procesów:
Po weryfikacji (we. Inform.) – blok decyzyjny
Diagramy przepływu danych DFD – Data Flow Diagram
Dokumenty we i wy (zwrot strzałek)
Strukturalna specyfikacja funkcji systemu („mapa” procesów)
Połączenie pomiędzy poszczególnymi procesami
Identyfikacja zależności między procesami danymi
Poprawność i jednoznaczność opisu
Precyzyjne określenie zakresu systemu, podsystemów i modułów
Dokładność, abstrakcja, czytelność
Zwięzły i czytelny opis funkcji systemu (łatwy do opanowania przez użytkowników, weryfikowalny) Metody rozpoznawania wymagań:
Redukcja redundancji funkcjonalnej systemu
Wywody i przeglądy procesów i zdarzeń (MBP – jeśli było przeprowadzone)
DFD – elementy składowe:
Analiza istniejącego oprogramowania
obiekt zewnętrzny – obiekt (lub grupa obiektów) nie należą do systemu, z którym system wymienia informacje (źródło /
Analiza wymagań innych SI
odbiorca danych dla / z systemu) – terminator, interfejs
Studium osiągalności
proces – element systemu przetwarzającego wejściowy strumień danych na wyjściowy lub tworzących dane wyjściowe Prototypowanie
na podstawie danych wejściowych
Struktura MF (Modelu Funkcjonalnego):
magazyn danych – element systemu umożliwiający gromadzenie danych i przechowywanie danych Identyfikacja zdarzeń, na które ma reagować SI
przepływ danych
Identyfikacja obiektów zewnętrznych generujących zdarzenia (osoby, systemy)
DFD – symbole graficzne
Diagram kontekstowy SI
SSADM – Structured System Analysed and Design Method
Hierarchiczny model funkcji SI
Typy zdarzeń
Diagram kontekstowy – granice systemu
-Pojawienie się danych na granicy systemu (do i z systemu)
Diagram systemowy – DFD0 – diagram ogólny systemu (podsystemy + główne magazyny)
-Wymuszenie z zewnętrznych (wpływ czasu)
Diagram procesów – DFB – rozwinięcie poszczególnych podsystemów aż po procesy elementarne (niepodzielne)
-Sterowanie systemu
Specyfikacja procesów elementarnych – FPD – specyfikacja, opis elementarnego algorytmu Identyfikacja zdarzeń z punktu widzenia otoczenia systemu
Identyfikacja wyjątków zdarzeń niepożądanych
DFD – strumienie, magazyny i ich charakterystyki:
Obiekty zewnętrzne:
Na DFD nie definiuje się sposobu, w jaki obiekt zewnętrzny dostarcza lub pobiera dane obiekty (lub ich grupy), które dostarczają informacji do SI lub też wykorzystują informacje tworzone w rezultacie pracy Magazyn jest elementem programu (nie wymusza obiegu danych) i może mieć złożoną strukturę SI (generują zdarzenia zewnętrzne)
Procesy powinny być wzajemnie niezależne
Granica systemu – otoczenia (jak przepływają dane)
DFD nie wyrażają zależności przyczyn – obiektów czasowo pomiędzy procesami
Model funkcji – zasady:
Nazwy i numery – każdy element na DFD ma swój unikalny identyfikator (adekwatny do elementu: nie proces 1, a np.
Funkcja - działania (czasownik) – otrzymanie
weryfikacja poprawności dokumentów)
Zwięzłość, jednoznaczność opisu, numerowanie funkcji
Przejrzystość i możliwość analizy – ilość procesów na diagramie
Na każdym poziomie ten sam poziom szczegółowości
Kompletność dekompozycji (hierarchia)
„Czarne dziury” – procesy pochłaniające informacje
Kolejność funkcji nie ma znaczenia
„Źródła danych” – procesy bez wejść, a z wyjściami („generują dane z niczego”, jak generator liczb losowych) Funkcji i pozycji użytkownika
„Puchnące” magazyny – pochłaniający dane
Podejście top – down (definiujemy od największego obszaru)
Stałe magazyny – tylko pobiera z nich dane
Techniki modelowania SI
Błędne przepływy:
Strukturalne (diagramy przepływu danych) – DFD i diagramy związków encji ERD)
Magazyn – Magazyn
Obiektowe (diagramy klas i obiektów, diagramy interakcji i przejść stanów)
Obiekt zewnętrzny – Magazyn
Techniki strukturalne:
DFD – bilansowanie:
model procesów – diagramy przepływu danych (DFD–DataFlow Diagram)
Bilans poziomy (procesów i magazynów)
model relacji – (ERD – Entity Relationship Diagram)
Bilans pionowy – suma (zawartości) przepływów danych wpływających do procesu jest równa sumie przepływów model zdarzeń zachodzących w SI – diagramy życia obiektu (ECH – Entity Life History) wpływających do różnych procesów na DFD
model zmiany stanów systemu – diagramy stanów (STD – State Transation Diagram) DFD – struktura procesu:
schematy struktury aplikacji (STC)
Algorytmiczna definicja procesu
słownik danych (Data Dictionary)
Dowodność formułowania, ale zwykle numer i nazwa procesu, dane WE i WY i opis
strukturalny Angielski (Structured English) – strukturalny polski
Opis algorytmów: słowny, pseudokod, makropolecenia, SQL, polecenia 4GL, tablice decyzyjne Metodyki obiektowe:
----------------
Metodyki obiektowe wykorzystują pojęcia obiektowości dla celów modelowania konceptualnego oraz projektowania Co to jest BD?
systemów informatycznych
Zorganizowany zbiór danych przechowywany w zewnętrznej pamięci komputera
Techniki:
Odzwierciedlenie fragmentu rzeczywistości
Diagramy obiektów
Cechy: trwałość zgodność z rzeczywistością
Diagramy dynamiczne
Model implementacyjny – typy:
Diagramy funkcjonalne
-Hierarchiczny -Sieciowy -Kartotekowy -Relacyjny
Angielski używa (USC Cases)
-Obiektowo-relacyjny -Obiektowy -Hypertekst
Diagram obiektów: Wariant notacyjny i rozszerzenie diagramów ERD
RDB – zasady:
Diagram obiektów zawiera:
każda tablica w BD ma jednoznaczną nazwę
klasy, w ramach klas specyfikacji atrybutów
każde pole (kolumna) ma jednoznaczną nazwę w tablicy
wszystkie wartości w kolumnie są tego samego typu
związki⇒ klucze obce(dodawane do encji)
porządek kolumn i wierszy nie jest istotny
Mapowanie złożone:
każdy wiersz musi być różny (wartościowo)
złożone nieoczywiste (związki wielu encji)
pola muszą zawierać wartości atomowe
na pojedynczą tabelę (kodowane)
Klucze:
na oddzielną tabelę
główny (Primary Key) – grupa kolumn o nie powtarzająych się danych
związków wykluczających się
obcy (Foreign Key) – grupa kolumn z jednej tablicy, których wartości odpowiadają kluczowi głównemu innej tablicy Klucze:
(powiązanie)
każda encja może mieć wiele unikalnych identyfikatorów – są to klucze kandydujące Integralność:
spośród kluczy kandydujących wybiera się główny
Poziom pól (dziedzina wartości)
jeżeli brak klucza kandydującego tworzy się klucz sztuczny (generowany automatycznie) Poziom tablic (klucz główny)
Wybór klucza zlecenia:
Integralność referencyjna:
1) klucz główny powinien być atrybutem jak najkrótszym
Obowiązkowość związku
2) klucz główny nie powinien mieć znaczenia dziedzinie przedmiotowej (nawet małe zmiany w dziedzinie biznesu Ograniczone usuwanie
spowodują istotne zmiany w BD) 3) klucz główny raczej powinien być generowany automatycznie (Re, JD, OJD) Usuwanie kaskadowe
Aspekty modelowania SI:
Wstawianie null
Funkcjonalny (DFD, hierarchiczny model funkcji)
Integralność dynamiczna
Co zachodzi w systemie
Dostęp do danych:
Danych(ERD/LDS, obiektowy)
sekwencyjny (rekordy w pliku, który musi być przeglądany od początku)
Dynamiki (ELH, STD) – kiedy zachodzi sterowanie
Bezpośredni (możliwość natychmiastowego odnalezienia potrzebnego rekordu w pliku) Diagram historii życia encji (ELH):
Indeksowany (wykorzystując tablicę – indeks do odszukania miejsca przechowywania rekordu) Odwzorowanie zmian stanów obiektów (encji)
Transakcje na BD:
Oddziaływanie zdarzeń z diagramem DFD na encje ERD
Zmiana stanu bd
Dynamiczny aspekt istnienia obiektu w systemie
Logiczna jednostka pracy w BD
Modelowanie log. pojedynczej encji (obiektu)
W trakcie trwania transakcji – BD nie jest spójna (nazywa się integralność)
Chronologia zdarzeń mających wpływ na encje
Właściwości transakcji (niepodzielność spójność , izolacja i trwałość)
Umożliwia identyfikacje wszystkich zdarzeń związanych z encją
Blokowanie – podstawa realizacji transakcji w środowisku współbieżnym
Umożliwia zdefiniowanie wszystkich błędnych sytuacji oraz zdarzeń wyjątkowych
Transakcja a awaryjność w BD:
ELH – elementy składowe:
Transakcje zatwierdzone – mają być odtworzone
Obiekt – wybrany obiekt (encja) z ERD
Transakcje nie zatwierdzone - wycofane
Zdarzenie sekwencyjne – pojedynczy element zdarzenie związane z obiektem
Metoda osiągnięcia: -Dzienniki transakcji -Redundancja
Zdarzenie złożone – możliwość rozłożenia na prostsze
Mapowanie modelu konceptualnego na implementacyjny:
Zdarzenie powtarzalne – więcej niż jeden raz zachodzi
Konceptualny na implementacyjny model danych
Zdarzenie selektywne – (if) spełnienie pewnych warunków
Konceptualny (niezależny od SZBD, język programowania modelu bazy danych) – ERD
Diagram historii życia obiektu – etapy budowy:
Implementacyjny – fizyczny(w konkretnym modelu bazy danych i SZBD)
Etap1 przygotowawczy
Model implementacyjny służy do wygenerowania skryptu do tworzenia BD wraz z więzami integralności (słownik BD) Wybranie obiektu z ERD
Pojecie relacyjnego modelu implementacji:
Identyfikacja zdarzeń dotyczących danego obiektu na podstawie DFD
Tabela (odpowiednik encji, nazwa l mnoga)
Dodatkowe rozważenia funkcji (bo można było coś pominąć)
Kolumna - pole (odpowiednik atrybutu)
Etap 2 – dla każdego obiektu z ERD
Dziedzina (konkretny typ danych i jego parametry)
Normalny cykl życia obiektu
Rekord (wystąpienie)
Zdarzenie specjalne (wyjątkowe)
Klucz główny (indeks unikalny, klucze sztuczne)
Sytuacje błędne
Klucz obcy (indeks nieunikalny)
Kolejność budowy
Odniesienie - (klucz główny, obcy, więzy integralności, referencyjny)
wybór zdarzeń odziaływujących na obiekt
Klucz alternatywny - (indeks unikalny lub nie)
ustalenie sekwencji zdarzeń
Inne elementy modelu implementacji
sprawdzenie, czy pewne zdarzenia mogą zachodzić warunkowo (selektywnie)
Atrybuty rozszerzone (nie SQL owe) – specyficzny dla danych SZBD:
sprawdzenie czy pewne zdarzenia mogą powtarzać się wielokrotnie
Dodatkowe typy, opisy, etykiety, elementy, wyświetlane na ekranie (komunikaty, helpy) sprawdzenie i ewentualna korekta sekwencji zdarzeń pod wpływem iteracji
Wartości domyślne
ELH – identyfikacja sytuacji wyjątkowych i weryfikacji:
Rozróżnialność (lub nie) wielkości znaków
gdzie mogą wystąpić sytuacje wyjątkowe?
Procedury walidacyjne (trigery)
Czy i w jaki sposób są one rejestrowane w systemie
Typ indeksu (np. słowny), opis, sposób konstrukcji indeksu
Jakie są efekty uboczne sytuacji wyjątkowej (tj. zdarzenia realizowane w systemie) Sekwencyjne
Weryfikacja ELH względem DFD: dla konkretnego zdarzenia na ELH musi istnieć co najmniej jeden przepływ na DFD
Problem mapowania:
mu odpowiadający
nazewnictwo(identyfikatory, nazwy typów, dziedziny)
Modelowanie zależności przyczynowych i czasowych:
ograniczenia ilościowe (np. .na liczbę pól w rekordzie)
Diagram zmian stanów STD (State Transmition Diagram):
brak wielowartowości pól (plaski model)
Uzupełnienie DFD o zależności czasowe
brak zmiennej struktury rekordu (wiersza)
Szczególnie ważne dla systemów czasu rzeczywistego, ale też dla systemów rozproszonych rejestracji i produkcji, Mapowanie proste
rezerwacji miejsc itp.
encja⇒tabela, atrybut⇒pole (kolumna)
Identyfikacja zdarzeń w systemie i ich zależność przyczynowo-skutkowych
unikalny identyfikator=>klucz główny
STD – elementy składowe:
STAN – zbiór określających wartości atrybutów systemu w danym momencie czasu Przyjazność SI (user friendly):
PRZEJŚCIE – zmiana stanu systemu, tj. jego przejście z jednego stanu do drugiego, w wyniku zajścia określonego stopniowe przekazywanie informacji, ukrywanie złożoność systemu
Warunku (C: Condition i wykonania akcji – A: Action)
informowanie użytkownika o wszelkich działaniach systemu (potwierdzanie wprowadzonych informacji, zapytania, SPRZĘG – sprzęg wejścia – wyjścia określającego przejście do/z stanu na innym diagramie (w szczególności stan komunikaty)
początkowy i końcowy sytemu).
wybieranie i wskazywanie zamiast pamiętania i pisania
Zasady sporządzania STD:
duży stopień ochrony przed błędami użytkownika
System musi się zawsze znajdować w jakimś stanie
ekran – drukarka
Sprzęgi wejściowe (START) i wyjście (STOP) – tylko jedne
system podpowiedzi i pomocy (help) dla użytkownika wywoływany na jego życzenie
Każdy stan systemu musi być dostępny ze stanu początkowego
wygoda w użytkowaniu ergonomiczność systemu, właściwa organizacja, ekran (np.: taka organizacja pracy systemu, by Stan końcowy powinien być dostępny dla każdego stanu
ruchy oczu były minimalne)
Dany warunek powinien powodować przejście z każdego stanu do jednego innego stanu (jednoznaczność przejścia) Inne elementy przyjazności:
Diagramy strukturalne STC (Structured Charts):
podział ekranu na stałe strefy
Cel – modelowanie przepływu danych, parametrów i sterowań pomiędzy modułami kodu aplikacji jednolitość komunikatów i znaczeń klawiszy, przycisków, konsekwencja, zgodność z oczekiwaniami Struktura hierarchiczna: moduł nadrzędny (wywołujący) – moduł podrzędny (wywoływany) zróżnicowanie sposobów wyświetlania informacji i komunikatów, adekwatność do statusu Budowa: przekształcenie diagramów DFD w STC
kolejność wprowadzania danych na ekranach wejściowych, grupowanie
Charakterystyki podziału na moduły:
Dokument – projekt SI:
Spójność (niezależność)
wprowadzenie (przedmiot opracowania, nazwa systemu, cel, zakres i kontekst systemu, odwołanie się do specyfikacji Stopień powiązań międzymodułowych (dąży się by był on jak najmniejszy)
wymagań SI)
Rozmiar modułu (np. jedna strona kodu)
projekt struktury funkcjonalnej systemu:
Zakres sterowania (złożoność , wywołanie nie więcej niż 9 modułów)
-diagram systemowy (DFD0)
Jednorodność (zakres funkcjonalny)
-diagram DFD poszczególnych procesów
Projektowanie szczegółowe:
-specyfikacje procesów prostych (algorytmy)
Kodowanie informacji
projekt struktury informacyjnej SI:
Interfejs użytkownika
-kody, symbole, oznaczenia
Formaty dokumentów we/wy
-model danych konceptualny i implementacyjny
Urządzenia we/wy
-specyfikacja i projekt informacji wyjściowych oraz wejściowych
Struktura techniczna i przestrzenna
-projekt diagramu z użytkownikiem (układ menu, formatek, okna, klawisze itp.)
Problemy eksploatacji (autoryzacja dostępu)
struktura techniczno - przestrzenna systemu
Elementy projektu poziomu fizycznego aplikacji
Jakość kodu – parametry:
Kodowanie danych - istota i cele:
poprawność
Istota: zastąpienia danych przez inne, zwykle ustruktualizowane i określonej notacji Cele: wydajność (szybkość wykonania)
Uproszczenie i skracanie wprowadzania danych
efektywność (złożoność czasowa)
Zmniejszenie ryzyka błędów i pomyłek
przenośność (możliwość przeniesienia na różne procesory)
Przeciwdziałanie redundancji
konserwacja (rozwój kodu modyfikacja)
Uproszczenie i przyspieszenie przetwarzań
dokumentowanie – komentarze
Rodzaje kodów:
prostota i jedność stylu (nazw zmiennych)
Zewnętrzne: (pesel , nip ,kod pocztowy)
Niebezpieczne techniki:
Wewnętrzne: (Id_pracownika, nr + czesci,kod operacji)
-GO TO (lub inne o podobnym działaniu EXIT, HALT, BREAK itp.)
Dla celów projektu (we/wy, moduły, oznaczenia)
-Programowanie trickowe (szybsze działanie, efektywność) – stosowanie funkcji nie udokumentowanych, odwołanie się Właściwości metod kodowania:
do przerwań -Skończoność dokładności obliczeń.
Rozszerzalność -Kompletność
-Rekurencje -Wykorzystanie procesów równoległych i przerwań.
Precyzja, jednoznaczność
-Złożone wyrażenia–priorytety.
-Zwięzłość -Czytelność
-Wykorzystanie współdzielonych zasobów (danych urządzeń itp.)
-Wygoda użycia
Błędy w SI - typy: -błędy krytyczne vs niekrytyczne
-Użyteczność (zgodność z istniejącym)
-uciążliwe vs kosmetyczne -losowe vs stabilne -narastające
Typ kodów:
-funkcjonalne vs obliczeniowe -wyjątkowe
Porządkowy (nr kolejny, np. 123)
Dwa typy testowania:
Klasyfikacyjny (pozycyjny np12.56.01)
Atestowanie (walidacja) – zgodność z wymaganiami użytkowników
Mieszany (np. lu\02\0089)
Weryfikacja – zgodność z dokumentacją (np.: specyfikacją systemu)
Kody z cyfrą kontrolną (np. pesel)
Czarna i biała skrzynka:
Kody mnemoniczne (np. NY, WAR)
testy na zasadzie białej skrzynki wykorzystują informację o programie do konstrukcji testów (danych testowych, analizy Kody alfabetyczne, numeryczne i mieszane
kodu) – nie pozwalają odkryć błędów funkcjonalnych
Poprawny interfejs:
testy na zasadzie czarnej skrzynki, traktuje się program jako obiekt o nieznanej konstrukcji spójny (topologia, słownictwo, otoczenie)
Fazy testowania: -test modułów (test kodu i funkcji)
prosta obsługa, ilość obiektów (5-9 obiektów)
-testy systemu(całość) -testy akceptacyjne (końcowa, użytkownik sprawdza zgodność ze specyfikacją wymagań) grupowanie (opcji, działań, kolejność/częstość)
Sposoby testowania kodu:
możliwość skrótów w dostępie do funkcji (doświadczony użytkownik)
statyczne (inspekcje kodu, inny zespół niż programiści tego kodu):
informacja o działaniach (potwierdzanie, aktualność)
-śledzenia wykonania „na sucho” -wyszukiwanie błędów
odwoływanie akcji
dynamiczne (wykonanie + analiza wyników)
poczucie spełnienia (drobne kroki, informacja)
dowód poprawności – obliczenia matematyczne
wrażenie kontroli nad SI
Kryteria doboru danych w testach dynamicznych:
każda instrukcja powinna wykonać się przynajmniej jeden raz – pokrycie testem wszystkich instrukcji pokrycie instrukcji warunkowych (w tym i wartości granicznych)
-testy pętli – minimalna liczba iteracji (w tym i 0) oraz maksymalna ich liczba
Typowe zagrożenia – konstrukcje:
-brak inicjacji wartości zmiennych
-porównania zmiennoprzecinkowe (różne liczby na którym miejscu)
-indeksy tablic -operacje na wskaźnikach -pętle (wyjście z pętli)
-warunki (<zamiast<=) -złożone wyrażenia (stosowanie nawiasów)
-nieuwzględnienie błędnych danych
Testowanie systemu techniki:
Wstępujące (operowanie danych: procedur testujących, hierarchiczność strategii -> brak możliwości zrównoleglenia prac) – testowanie funkcji oddzielnie każdej.
Zstępujące (robienie aplikacji od góry, najpierw ogólna nazwa programu, później drobiazgi, funkcja) – konieczność opracowania „zaślepek” – trudność w testowniu nowego modułu
test pod obciążeniem – (stress testing) – Do jakiego czasu aplikacja pracuje poprawnie dokładając na nią obciążenie (objętość, new users, klienci, obciążenie sieci – efektywność)
test odporności – (na nadzwyczajne zdarzenia). Zasilanie, sprzęt, niepoprawne dane, odłączenie od sieci, wyciągnięcie wtyczki – jak się zachowuje po ponownym uruchomieniu.
Dane testowe:
kryteria wyboru danych testowych:
-testy pozytywne (dane + poprawne wyniki)
-testy negatywne (błędne dane, brak danych)
-testy funkcjonalne (funkcje programów)
-testy strukturalne (testowanie wszystkich ścieżek w programie)
pochodzenie danych:
-dane losowe
-dane deterministyczne
-dane rzeczywiste