Etapy tworzenia oprogramowania1.Negocjacja z klientem(ważne żeby dobrze rozpoznać potrzeby klienta, co umożliwi szybkie tworzenie kodu2.Zarzadzanie czasem powstawania projektu(celem jest oszacowanie czasu potrzebnego na utworzenie modeli obiektowych, kodu programu oraz jego testów. Dokonuje tego osoba dobrze znająca zespól programistow oraz ich umiejętności w tworzeniu kodu do określonych zastosowań. Zajmuje się tym opiekun projektu3. Tworzeni projektu w postaci zależności obiektowych(tworzenie algorytmów właściwych, które będą implementowane w programie 4. Tworzenie kodu programu(Tworzenie wlaściwego kodu na podstawie ostatecznej wersji diagramów UML. Debugowanie, sprawianie poprawności kodu. 5.Testowanie oprogramowania(sprawdzanie zgodności z wymogami klienta)
Najważniejsza uwaga odnośnie jakości Należy prawidłowo ocenić koszt jakości, w tym:● czas poświęcony na osiągnięcie określonego poziomu jakości,● koszty jej uzyskania,● określić taki poziom ryzyka, przy którym ewentualne błędy i braki
w funkcjonalności nie byłyby zbyt kosztowne dla użytkownika.
Zarządzanie projektem Planowanie: -jakość tworzonego kodu -czas jego pisania -osobiste zwyczaje programistów -podział żądań -nadzór nad poszczególnymi etapami -odpowiednie motywowanie
Narzędzia zarządzania proj. Inf. Powinny posiadać funkcjonalność: -planowanie, organizowanie, motywowanie, kontrolę
RBS(Resource Breakdown Structure.)- struktura podziału zasobów zależności pomiędzy zasobami w ogólności, a osobami w szczególności
Diagram Gautta Służy do planowania zdarzeni] tym zaznaczania i wykrywania tzw. krytycznych ścieżek. Natomiast za pomocą diagramu Gantta nie jest możliwe przedstawienie złożoności danego procesu. Możliwe jest tylko zarządzanie czasem. Czas potrzebny na wykonanie określonych zadań musi być oszacowany innymi metodami. Najczęściej stosowane pojęcia w wykresach Gantta to:Zadania krytyczne(zadania istotne(zacieniowany prostokąt)) 2 Zadania niekrytyczne(mniej istotne(pusty prostokąt)) 3.Podsumowanie(etap projektu, który składa sie z zadań wymienionych wcześniej(zacieniowany prostokąt z ząbkami)) 4.Kamien milowy(bez tego zadania, prace nie mogą posunąć się dalej(kopnięty zacieniowany kwadrat)). Wady: 1.Dla dużej liczby zadań jest trudny do interpretacji. Z tego
względu stosuje się go zazwyczaj tylko do 30 zadań.
2.W przypadku złożonego procesu zarządzania, trudno zauważyć
ścieżkę krytyczną - czyli taką, która determinuje wykonanie
wszystkich pozostałych zadań.
3.Czasy wykonywania poszczególnych zadań muszą być
deterministyczne - a nie zawsze tak jest w przypadku tworzenia
oprogramowania.
Zarządzanie wiedzą (zespół sformalizowanych sposobów
gromadzenia i wykorzystania wiedzy formalnej i wiedzy
cichej uczestników organizacji (firmy).)Wiedza formalna - jest możliwa do wyrażenia za pomocą jednoznacznych słów i symboli. Wiedzą formalną są na przykład schematy organizacyjne lub wiedza z przedmiotów ścisłych. Wiedza milcząca (tacit knowledge) - to pojęcie wywodzące się z filozofii nauki - istnieje wiedza niezwerbalizowana, niemożliwa do wypowiedzenia za pomocą symboli. Oba rodzaje wiedzy są bardzo istotne dla zarządzania wiedzą, jak również w przypadku tworzenia oprogramowania.
Metryka kodu - jest to miara, pozwalająca na oszacowanie złożoności kodu, prawdopodobieństwa popełnienia błędu podczas pisania kodu, oraz ewentualnie czas powstawania kodu. Własności: * prosta i możliwa do obliczenia przez komputer, * przekonująca, * konsekwentna i obiektywna, * spójna pod względem użytych jednostek, * niezależna od języka programowania, * dająca przydatne informacje. Najczęściej stosowaną metryką jest liczba linii kodu
Programu inne: 2) szybkość pisania kodu 3) prawdopodobieństwo popełnienia błędu
Inne metryki kodu. a) przeznaczone do programowania strukturalnego (metryka liczby linii kodu, ale też inne metryki, na przykład tokenowa)b) przeznaczone do programowania obiektowego( Zestaw metryk CK. W tej grupie analizuje się nie tylko liczbę kodu, ale przede wszystkim powiązania pomiędzy klasami i obiektami. )
Jak oszacować szybkość tworzenia nowego algorytmu? 1)Zagadnienie bardzo trudne i wymaga dodatkowych badań - czas należy liczyć w latach.2)Zagadnienie całkiem nowe, ale rozwiązanie go nie wymaga przeprowadzenia badań naukowych- kilka miesięcy.3)Zagadnienie jest nowe, ale poszczególne elementy
rozwiązania są obecne już w gotowych bibliotekach- od kilku godzin do kilku dni.
Narzędzia CASE wspomagające tworzenie kodu schematy blokowe, a zwłaszcza język UML umożliwiają stosunkowo łatwą konwersję algorytmu na kod. Do tego celu używa się narzędzi CASE (Computer-aided software engineering), umożliwiających tego typu manipulacje. Obecnie narzędzia CASE stosuje się w czterech dziedzinach:● Life-cycle support (wspomaganie tworzenia i utrzymania programów)●Integracja● Konstrukcja● Systemy bazujące na wiedzy
Gotowe biblioteki (na przykład systemowe) są niezbędne do działania programu. Jednakże użycie gotowych bibliotek ma swoje wady. Najważniejsze z nich:● Dokumentacja - może być niepełna lub nieprecyzyjna ● Problem licencji. Jakie są warunki do korzystania z niej? Czy nie trzeba płacić twórcy biblioteki za każdy egzemplarz sprzedanego oprogramowania, które z niej korzysta? ● Cena biblioteki - trzeba sprawdzić, czy dla celów komercyjnych, zastosowana biblioteka nie jest zbyt droga.
łasna biblioteka
Jeżeli firma informatyczna będzie pisać podobne oprogramowanie dla wielu klientów należy w kodzie wyodrębnić części wspólne i z nich stworzyć własną bibliotekę.
umożliwia to sprawniejsze tworzenie kodu niż w przypadku pisania wszystkiego od nowa jeszcze raz. bardzo ważna jest sprawa dokumentacji. Źle napisana dokumentacja zmusza programistę do przeglądania całej biblioteki w celu zrozumienia (lub przypomnienia sobie) klas, metod czy funkcji w niej umieszczonej.
Grafy PERT(Program/Project Evaluation and ReviewTechnique) są rozszerzeniem wykresów Gantta dokonanym poprzez wprowadzenie rozrzutu czasowego, (czyli inaczej ulosowienia czasu wykonania poszczególnego zadania) i zamienieniu wykresu Gantta na graf skierowany. Każdy z wierzchołków grafu PERT jest kamieniem milowym. Wierzchołkowi grafu perta przypisane są cztery następujące zmienne czasowe:● Czas optymistyczny wykonania zadania (Optimistic time), oznaczany literą O.● Czas pesymistyczny wykonania zadania (Pessimistic time), oznaczany literą P.● Najbardziej pożądany czas wykonania zadania (Most likely time), oznaczany literą M,● Oczekiwany czas wykonania zadania (Expected time), oznaczany symbolem TE ;Parametr TE = (0 + 4M + P)/6. WADA: nie nadają się do dynamicznej modyfikacji.
Wykresy sieciowe -Rozszerzenie grafów PERT-są to graficzne reprezentacje zależnościpomiędzy poszczególnymi elementami procesu. W przypadku wykresów sieciowych wprowadza się możliwość interakcji elementów ze sobą, co w konsekwencji umożliwia dynamiczne tworzenie zależności. W wykresie sieciowym, zamiast wierzchołków grafu są określone elementy z charakterystycznymi dla siebie własnościami.
UML(Unified Modeling Language) umożliwia opisanie bardzo wielu aspektów
rzeczywistego obiektu, wygenerowanie szkieletu (lub nawet
trochę więcej) kodu programu, oraz wprowadza interakcję.
Przyjmuje się następujący podział w UML diagramy przypadków użycia,● Diagramy klas i obiektów,,● Diagramy czynności,● Diagramy maszyny stanowej,● Diagramy sekwencji,● Diagramy komunikacji,● Diagramy harmonogramowania,● Diagramy sterowania interakcją,● Diagramy wdrożeniowe (komponentów i rozlokowania),● Diagramy struktur połączonych,● Diagramy pakietów
debugger program umożliwiający śledzenie polecenie po poleceniu działającego programu, jak również uzupełnianie go o inne polecenia. Obecnie słowo „debugger” oznacza również program, ale umożliwiający znacznie więcej niż tylko podgląd i mała
modyfikacja programu w asemblerze. Debugger umożliwia w wielu przypadkach dekompilację kodu i dokładne śledzenie wykonywanego programu.
Struktura procesu debugowania: -Zgłoszenie(Zgłoszenie nazywa się również
raportowaniem. Raportowanie powinno być jak najdokładniejsze, gdyż
w przypadku zbyt ogólnego sformułowania, nie wiadomo co spowodowało niepożądane działanie aplikacji) - reprodukcja(jest to próba odtworzenia błędu na podstawie danych z raportu, w warunkach laboratoryjnych.) - diagnoza (szukanie przyczyn)- naprawa - refleksja (podsumowanie i analiza błędów które były w projekcie. Analiza tego typu ma posłużyć w przyszłości,aby nie popełniać tego samego błędu następnym razem.
Tworzenie użytecznego raportu o błędzieUżyteczny raport o błędzie musi umożliwić odtworzenie danej sytuacji w warunkach laboratoryjnych, czyli na
przykład w trybie debugowania kodu. Dlatego priorytetem jest następny etap - reprodukcja błędu 1.Potrzebna jest dokładna informacja o czynnościach
wykonanych przez użytkownika,2.W przypadku problemów ze sprzętem, potrzebna jest dokładna specyfikacja komputera 3.Należy się dowiedzieć jak najwięcej szczegółów na temat komunikatów, jakie podawał program lub system
operacyjny.4.Komunikaty pojawiające się w razie błędów muszą być
bardzo precyzyjne! To akurat zależy od twórcy programu!
Testowanie oprogramowania polega na sprawdzeniu czy aplikacja zachowuje się zgodnie z wymaganiami dla różnych przypadków.W tym celu przeprowadza się eksperyment, polegający na wprowadzeniu danych do programu, a następnie porównaniu uzyskanych wyników z oczekiwanymi. Eksperyment ten nazywa się przypadkiem testowym) Zbiór danych wejściowych i oczekiwanych wyjściowych określa się często nazwą wektora testowego. Ważnym pojęciem są też testy regresji. Regresja oznacza w tym przypadku zmiany w kodzie programu, które polegają na dodawaniu nowej funkcjonalności lub usuwaniu starej. Ponieważ jest to proces rozciągnięty w czasie, to sprawdzanie każdej nowej wersji użyciem tego samego przypadku testowego, nazywa się regresją Każde testowanie oprogramowania musi odbywać się w środowisku zapewniającym pełną kontrolę nad wykonywanym kodem. Miejsce, w którym testuje się program, nazywa się środowiskiem testowym.
Piaskownica” - jest to wydzielona część systemu informatycznego, służącego do bezpiecznego uruchamiania programów, bez dostępu do zasobów strategicznych z punktu widzenia ochrony systemu operacyjnego czy sieci komputerowych.
Wirtualizacja - jest to w ogólności uruchamianie jednego systemu operacyjnego w drugim. W przypadku testów oprogramowania jest to bardzo użyteczne narzędzie, gdyż pracując w trybie wirtualizacji, wrażliwe dane nie ulegają uszkodzeniu w razie awarii
Test jednostkowy to program, sprawdzający poprawność działania pojedynczej metody, funkcji, procedury lub co najwyżej klasy. Do testowania jednostkowego używa się specjalnych programów (symulatorów), albo własnych programów lub też specjalnych modułów testujących. Możliwe wyniki testu, to: udany test, nieudany test lub zignorowany test. Ten ostatni odnosi się do kodu, który musi być wykorzystany, ale jeszcze nie jest kompletny. Zagadnieniem krytycznym jest takie zaprojektowanie testu, aby nie był zbyt złożony i rzeczywiście umożliwiał znalezienie nieprawidłowości w kodzie. Symulator - jest to program podobny do debuggera, różniący się od niego tym że umożliwia uruchomienie i śledzenie programu w środowisku innym niż ten w którym tworzony program docelowo ma powstać.
Testy integracyjne Integracja - jest pojęciem, za pomocą którego opisuje się
czynność tworzenia całości z mniejszych elementów.W informatyce kod jest dzielony na wiele małych grup,począwszy od tych, które w językach c-podobnych oznacza
się nawiasami klamrowymi, poprzez metody i funkcje, aż do klas i pakietów.
Pisząc kod od najmniejszych części, z testowaniem jednostkowym, można zapewnić stosunkowo łatwo poprawność funkcjonalną.
trzy podstawowe metody testów integracyjnych już napisanego kodu.Są to:1. Metoda „wielkiego wybuchu”( polega na złożeniu wszystkichfragmentów programu w całość, po uprzednimprzeprowadzeniu testów jednostkowych- ryzykowna wykorzystywana rzadko)2. Metoda zstępująca(W metodzie zstępującej, integrację rozpoczynamy od interfejsu użytkownika. Na pierwszym etapie testujemy tylko jego działanie, korzystając z namiastek pozostałych obiektów lub klas.
Namiastka - jest to metoda, klasa lub funkcja bądź procedura, która nie jest wypełniona kodem. Po przetestowaniu interfejsu użytkownika, zamieniamy
namiastki na właściwy kod. Test się kończy gdy wypełnimy już najmniej istotny kod i wszystko będzie się dobrze komunikowało.3. Metoda wstępująca(Metoda wstępująca polega na stopniowym łączeniu ze sobą
fragmentów kodu, począwszy od tych najprostszych, poprzez te bardziej skomplikowane. Na samym końcu następuje integracja całości z interfejsem
użytkownika.używa się także namiastek ale ich liczba jest mała)
Testy integralności służą do testowania komunikacji, czyli wymiany informacji
pomiędzy poszczególnymi fragmentami programu.
Testy systemowe Podczas testowania systemowego dokonuje się analizy wpływu programu na system, jak i również działania w drugą stronę, czyli szuka się odpowiedzi na pytanie, jak system wpływa na działanie programu.Wtedy też sprawdza się odporność oprogramowania na różne sytuacje, które nie są wprost związane z wymaganiami klienta.To ostatnie podlega sprawdzeniu dopiero w teście akceptacyjnym. Rodzaje testów systemowych typowo wyróżnia się siedem rodzajów testów:● Testy funkcjonalne (służą do sprawdzenia poprawności działania wszystkich funkcji systemu, współpracujących z programem lub wykorzystywanych w testowanej aplikacji.)● Testy wydajnościowe (służą do sprawdzenia, w jaki sposób oprogramowanie wpływa na szybkość pracy całości.)● Testy przeciążeniowe(służą do badania zachowania się programu w warunkach dużego obciążenia systemu.)● Testy bezpieczeństwa(dotyczą zagadnienia nieautoryzowanego dostępu do danych.) Testy odporności(jak system i program radzą sobie w warunkach ekstremalnych. Są to na przykład gwałtowne wyłączenia zasilania) Testy zgodności (dotyczą oprogramowania mającego pracować na różnych platformach czy to sprzętowych, czy to systemowych)Testy dokumentacji(jest sprawdzianem czy program działa dokładnie tak jak to zostało zapisane w wymaganiach)
Test akceptacyjny polega na doprecyzowanie wymagań klienta, i przeprowadzenia testów poprawek, wynikłych ze zmiany pewnych założeń. jest to ostateczna weryfikacja oprogramowania przed wdrożeniem. Najczęściej spotyka się dwa etapy testów. Pierwszym z nich, określanym mianem „alfa”, dotyczy testów przeprowadzanych wewnątrz firmy tworzącej oprogramowanie. Drugi test - „beta”, dotyczy przede wszystkim programów dostępnych dużej grupie użytkowników. W tego typu teście musi brać udział reprezentatywna statystycznie grupa osób, które będą korzystać z aplikacji w przyszłości.
Test wdrożeniowy - którego głównym celem jest przewidywanie niestandardowych zachowań użytkownika programu lub innego produktu oraz badanie, jak dany produkt się będzie wtedy zachowywał(skróty klawiszowe, albo specyficzny sposób rozumowania)
Metryki używane do testowania oprogramowania dzieli się na dwie główne grupy:● Metryki pokrycia wymagań (testów akceptacyjnych (alfa oraz beta), celem sprawdzenia zgodności produktu z zamówieniem.) Do testów „białej skrzynki” zalicza się wszystkie te, które wykorzystują testowe metryki kodu. Testy „czarnej skrzynki” to już etap akceptacyjny, gdzie testuje się nie kod programu, ale działanie aplikacji. ● Metryki pokrycia kodu((w %)testach wewnętrznych, sprawdzających poprawność działania wszystkich fragmentów kodu. Rodzaje: Pokrycie bloków instrukcji, Pokrycie decyzji, Pokrycie ścieżek.)
Metryki pokrycia kodu- stosowane w testach wewnętrznych sprawdzających poprawność działania wszystkich fragmentów kodu.
Rodzaje:
-pokrycie bloków instrukcji - jest to metryka pozwalająca objąć całe bloki instrukcji
(+)relatywna prostota tworzenia
(-)nie wykrywa błędów wprowadzających dodatkowe funkcjonalności do programu
-pokrycie decyzji - tak jak wyżej oraz dodatkowo umożliwia wykrycie błędów typu „utworzenie” niezamierzonego rozgałęzienia.
(+) możliwość oszacowania błędu gdy x jest losowany od -100 do 100. Możliwość wykrycia błędu który w poprzedniej metryce może być całkowicie przeoczony
(-) wymaga pisania stosunkowo dużego kodu. Jest czasochłonne i kosztowne. Wykrywa błędy które przy normalnym użytkowaniu mogą się w ogóle nie pojawić.
-pokrycie ścieżek - definiuje się ją jako iloraz liczby ścieżek sprawdzanych w testach i liczby wszystkich ścieżek istniejących w programie. Stosowana głównie w tych językach programowania które umożliwiają kompilacje warunkową
Metryki pokrycia wymagań- stosuje się w przypadku testów akceptacyjnych (alfa oraz beta) celem sprawdzenia zgodności produktu z zamówieniem.
Zarządzanie- to zestaw działań (planowanie, organizowanie, motywowanie, kontrola) skierowanych na zasoby organizacji (ludzie, finansowe, rzeczowe, informacyjne) wykorzystywanych z zamiarem osiągnięcia celów organizacji.
namespace pokaz_testow
{class MainClass
{public static void Main (string[] args)
{
Console.WriteLine ("Hello World!");
}
public float ŚredniaArytmetyczna(float[] Tablica) //Metoda przeznaczona do testowania!
{
int indeks;
float Średnia;
Średnia = 0;
for(indeks=0;indeks<Tablica.Length;indeks++)
{
Średnia = Średnia + Tablica[indeks];
}
Średnia = Średnia/((float)Tablica.Length);
return Średnia;
}//Koniec obliczania średniej arytmetycznej
}//Koniec klasy main
}//Koniec pakietu
namespace pokaz_testow
{[TestFixture()]
public class pokaz_test_srednia
{[Test()]
public void TestCase ()
{float[] TablicaTestowa;
MainClass ObiektTestowany;
float WynikPoprawny;
float WynikWyliczony;
TablicaTestowa = new float[10];
ObiektTestowany = new MainClass(); //Utworzenie nowego obiektu
WynikWyliczony = 0;
TablicaTestowa[0] = 1; //Wektor testujący
TablicaTestowa[1] = 2;
TablicaTestowa[2] = 3;
TablicaTestowa[3] = 4;
TablicaTestowa[4] = 5;
TablicaTestowa[5] = 6;
TablicaTestowa[6] = 7;
TablicaTestowa[7] = 8;
TablicaTestowa[8] = 9;
TablicaTestowa[9] = 10;
WynikPoprawny = 5.5f; //Koniec wektora testującego
//f na końcu liczby 5.5 musi byc podane, gdyż domyślnie 5.5 jest typu double
//Teraz test
WynikWyliczony = ObiektTestowany.ŚredniaArytmetyczna(TablicaTestowa);
if(WynikPoprawny == WynikWyliczony) //Wyprowadzenie rezultatu testu
{
Console.WriteLine("Średnia została obliczona poprawnie!");
}else
{
Console.WriteLine("Średnią wyliczono z błędem!");
}//Koniec wyprowadzania rezultatu testowania
Assert.AreEqual(WynikPoprawny,WynikWyliczony,"Średnia została wyliczona błędnie!");
}//Koniec metody testującej
}//Koniec klasy testującej
}//Koniec pakietu
METODA TESTOWANA
public class testowana{
public double MetodaBezBłędu(double x){
double wynik;
wynik = 0;
if(x>10) //Funkcja porównująca{
wynik = x * x;
}else{
wynik = (x * x) - 10;
}
return wynik;
}//Koniec funkcji bez błędu
public double MetodaZBłędem(double x){
double wynik;
wynik = 0;
if(x>10) //Funkcja porównująca{
wynik = x * x;
}//Błąd - brak polecenia else!!!{
wynik = (x * x) - 10;
}
return wynik;
}//Koniec funkcji z błędem
}
}
using System;
namespace pokrycie_decyzji{
public class test{
public int RezultatPrawidłowyTest1;//Zmienne dla testu bez błędu
public int RezultatNieprawidłowyTest1;
public int LiczbaPowtórzeń;
public int RezultatPrawidłowyTest2;//Zmienne dla testu z błędem
public int RezultatNieprawidłowyTest2;
private bool CzyPrawidłowy(double x, double UzyskanyWynik){
bool wynik;
double Pomocnicza;
wynik = false;
if(x>10) //Funkcja porównująca - analizujemy przedziałami!!!!!!!!{
Pomocnicza = x * x;}else{
Pomocnicza = (x * x) - 10;
}
if(Pomocnicza == UzyskanyWynik) wynik = true;
return wynik;
}//Koniec porównania
public void UruchomTest(int LiczbaPrób){
int i;
double WartośćLosowa;
double WyliczonaWartość;
testowana MetodyTestowane;
Random GeneratorLosowy;
i = 0;
WartośćLosowa = 0;
LiczbaPowtórzeń = LiczbaPrób;
GeneratorLosowy = new Random();
MetodyTestowane = new testowana();
RezultatNieprawidłowyTest1 = 0;
RezultatPrawidłowyTest1 = 0;
RezultatNieprawidłowyTest2 = 0;
RezultatPrawidłowyTest2 = 0;
for(i=0;i<LiczbaPowtórzeń;i++) //Pętla testująca
{
WartośćLosowa = (200*GeneratorLosowy.NextDouble()) - 100;
WyliczonaWartość = MetodyTestowane.MetodaBezBłędu(WartośćLosowa);
if(CzyPrawidłowy(WartośćLosowa,WyliczonaWartość) == true) //test1{
RezultatPrawidłowyTest1++;
}else
{
RezultatNieprawidłowyTest1++;
}//Koniec testu 1
WyliczonaWartość = MetodyTestowane.MetodaZBłędem(WartośćLosowa);
if(CzyPrawidłowy(WartośćLosowa,WyliczonaWartość) == true) //test2{
RezultatPrawidłowyTest2++;
}else{
RezultatNieprawidłowyTest2++;
}//Koniec testu 2
}//Koniec pętli testującej -- next i
}//Koniec testu
}//Koniec klasy test
}
PROSTOKĄT
[TestMethod]
public void TestMethod1()
{
prostokątMC pr = new prostokątMC();
Assert.AreEqual(pr.ObliczPowierzchnię(1.0, 1.0), 1.0);
}
class Program
{
static void Main(string[] args){
ProstokatTest pt = new ProstokatTest();
pt.TestCase();
Console.ReadLine();
} }
public class ProstokatTest
{
public void TestCase()
{
int dobre=0;
int zle=0;
// te 3 ponizej - wektor testowy
double[] testoweA = { 1, 2, 3, 5.5, 12, 6, 0.1, 1000, 2000 };
double[] testoweB = { 4, 12, 1, 6, 2.5, 3, 0.2, 4000, 0.01 };
double[] testoweP = { 4, 24, 3, 33, 30, 18, 0.02, 4000000, 20 };
prostokątMC obTestowy = new prostokątMC();
double dokl = 0.01;
for (int i = 0; i < testoweA.Length; i++)
{
double poleMC = obTestowy.ObliczPowierzchnię(testoweA[i], testoweB[i]);// metoda Monte-Carlo jest oparta na prawdopodobienstwie, dopuszczamy pewna niedokladnosc, tak przypuszczam przynajmniej...
if (Math.Abs(poleMC - testoweP[i]) < dokl * testoweP[i])
{Console.WriteLine("Przypadek poprawny: {0}*{1}={2}", testoweA[i],testoweB[i], poleMC);
dobre++;
}
else
{
Console.WriteLine("Przypadek niepoprawny: {0}*{1}!={2}", testoweA[i], testoweB[i], poleMC);
zle++;
}
}
Console.WriteLine("Ogolem: {0} dobrze, {1} zle", dobre, zle);
return; }
}
public class prostokątMC
{
public double ObliczPowierzchnię(double a, double b)
{
double PomocniczeA;
double PomocniczeB;
Random Generator;
double x;
double y;
int LiczbaRzutów;
int LiczbaTrafień;
int i;
double wynik;
PomocniczeA = 2 * a;
PomocniczeB = 2 * b;
Generator = new Random();
x = 0;
y = 0;
wynik = 0;
LiczbaRzutów = 100000;
LiczbaTrafień = 0;
i = 0;
for (i = 0; i < LiczbaRzutów; i++)
{
x = PomocniczeA * Generator.NextDouble();
y = PomocniczeB * Generator.NextDouble();
if ((x < a) && (y < b)) LiczbaTrafień++;
}//Koniec rzucania
wynik = ((double)LiczbaTrafień / (double)LiczbaRzutów) * PomocniczeA *
PomocniczeB;
return wynik;
}//Koniec obliczania powierzchni
}
}