Zgryźliwość kojarzy mi się z radością, która źle skończyła.
Rozdział 14
RENTMAN- po narodzinach
Zakładamy, że skompletowaliście Państwo program RENTMAN zgodnie z planem
opracowanym we wcześniejszych rozdziałach książki. Faza analizy, planowania
i konstruowania aplikacji jest w zasadzie za nami.
Zgodnie z założonym, pięciofazowym modelem pracy nad aplikacją, pozostały
nam jeszcze etapy testowania i konserwacji. Zbadamy i omówimy liczne problemy
związane z życiem aplikacji po jej skonstruowaniu.
Testowanie aplikacji
Istnieją liczne sposoby testowania programów i zapewniania ich jakości, jednakże
kilka ogólnych wytycznych pozostaje prawdziwymi, niezależnie od założonej
drogi postępowania. Oto wskazówki, odnoszące się do testowania aplikacji:
Należy stwierdzić, czy program realizuje całkowicie założone wcześniej
zadania. Nie ograniczajmy się jedynie do wyszukiwania typowych błędów
w oprogramowaniu („pluskiew”); pełny proces sprawdzania wymaga spojrzenia
na aplikację jak na wielki obraz, powinniśmy wiedzieć, co program miał robić,
kiedy go planowaliśmy i porównać z efektem końcowym.
Przyjrzyjmy się kluczowym funkcjom, które program ma realizować
i zastanówmy się, czy aplikacja spełnia swoje zadania, czy jej funkcje są
realizowane tak, jak zaplanowaliśmy. Należy również przemyśleć sposób
zbadania, wjaki każda funkcja realizuje przypisane jej cele. Rzetelne
testowanie wymaga porównania aplikacji zoryginalną specyfikacją jej
właściwości.
Po autorskiej weryfikacji należy przeprowadzić zarówno testy wewnętrzne, jak
i zewnętrzne. Wewnętrzne są prowadzone przez autora i jego zespół programistów.
Zewnętrzne mogą wykonywać ludzie z tej samej grupy, lecz w żaden sposób nie
związani z projektem (członkowie grupy prowadzącej beta testy oraz wszelkie inne
zespoły spoza przedsiębiorstwa). Oto kilka wskazówek przydatnych przy
prowadzeniu testów wewnętrznych:
Sprawdzić, czy więzy nałożone na bazę danych są realizowane prawidłowo.
434
Część II
Sprawdzić obiekty umiejscowione na serwerze, takie jak procedury pamiętane
(
stored procedures
) i perspektywy (
views
), upewniając się, czy wykonują
założone zadania.
Przetestować działanie programu podczas pracy z wieloma użytkownikami.
Zweryfikować, czy zdefiniowane prawa dostępu prawidłowo sterują
uprawnieniami.
Sprawdzić program na komputerze możliwie jak najbardziej podobnym do
maszyny użytkownika.
Poniższa lista zawiera kilka dodatkowych wskazówek do testów zewnętrznych:
Ustalić sformalizowaną procedurę raportowania obłędach wprogramie
i zasadach reakcji na takie informacje.
Zaplanować sposób łatwej dystrybucji aktualizacji i pakietów poprawiających
błędy.
Zapewnić pomoc techniczną ludzi nie związanych z testowaniem aplikacji.
Ustanowić małą grupę kluczowych użytkowników do prowadzenia beta testów.
Prowadzić testy przydatności z użytkownikami o różnym poziomie
zaawansowania.
Pamiętać, że to użytkownicy decydują, czy aplikacja im odpowiada oraz spełnia
ich Szczegółowa analiza zewnętrznego testowania programów wykracza poza
ramy tej książki.
Pierwsze i najważniejsze pytanie: Czy aplikacja realizuje zadanie, do którego
została zaprojektowana? W rozdziale 8 określono przeznaczenie programu
RENTMAN: ma być systemem ułatwiającym zarządzanie wynajmowanymi
nieruchomościami.
Czy program wywiązuje się z postawionego zadania? Wydaje się, że tak, ale
jedynie Allodium może naprawdę stwierdzić, czy aplikacja robi to w stopniu
przynajmniej dostatecznym.
Przejdźmy do funkcji kluczowych. Zgodnie z tym, co napisano w rozdziale 8,
aplikacja powinna:
Umożliwiać zapisywanie i konserwowanie danych o wynajmie nieruchomości.
Pozwalać na śledzenie realizacji prac związanych z ich utrzymaniem.
Umożliwiać rozliczanie najemców.
Dostarczać informacji o historii nieruchomości.
RENTMAN- po narodzinach
435
I znów musimy stwierdzić, że RENTMAN wydaje się spełniać wszystkie założone
funkcje oraz że jedynie Allodium może w pełni ocenić w jakim zakresie.
Przed rozpoczęciem testowania aplikacji przyjrzyjmy się oddzielnie każdej
wskazówce do przeprowadzania kontroli wewnętrznej, i zobaczmy, jak mogą być
one zastosowane w przypadku programu RENTMAN.
Sprawdzić więzy nałożone na bazę danych aplikacji
Należy sprawdzić (próbując je złamać), czy nałożone więzy istnieją, są wzajemnie
spójne i działają zgodnie z założeniami. Przy sprawdzaniu programu RENTMAN
powinniśmy spróbować:
Usunąć z pliku tabeli LEASE najemców, którzy utrzymują dzierżawę.
Wprowadzić do pola City tabeli PROPERTY wartość inną niż Richardson,
Dallas, Plano, Norman, Oklahoma City i Edmond.
Usunąć z tabeli PROPERTY rekord, opisujący nieruchomość, która zgodnie
z danymi z tabeli LEASE jest aktualnie wynajmowana.
Pominąć pole Deposit przy wprowadzaniu danych do tabeli PROPERTY.
Wprowadzić niewłaściwą datę do pola StartDate tabeli WORDER.
Dodać do tabeli PROPERTY nieruchomość mającą sześć sypialni.
Nie ma chyba wątpliwości, na czym polega ten etap testowania. Sprawdzamy
warunki konieczne poprawnego działania aplikacji, nałożone poprzez więzy bazy
danych.
Sprawdzić obiekty umiejscowione na serwerze
Jeśli zaimplementowany program wykorzystuje procedury pamiętane (
stored
procedures
), perspektywy (
views
) lub inne obiekty umiejscowione na serwerze, to
należy sprawdzić ich pracę. Testowanie systemów klienta jest dla wszystkich
oczywiste, tymczasem konieczność kontroli działania obiektów osadzonych na
serwerze jest przez wielu programistów aplikacji klient/serwer zaniedbywana lub
minimalizowana. A przecież SQL jest językiem, takim samym jak Object Pascal
czy C++. Oto kilka spraw, na które należy zwrócić uwagę:
Jeśli mamy zbudowany raport końcowy, który jest produkowany przez
procedurę pamiętaną lub inny obiekt umiejscowiony na serwerze, to należy
uruchomić procedurę poza aplikacją lub kreatorem raportów, aby się upewnić,
że działa zgodnie z oczekiwaniami. Nawet jeśli sprawdziliśmy pracę procedury
za pośrednictwem naszego programu, to uruchomienie jej bezpośrednio
pozwala zobaczyć ewentualne komunikaty serwera oraz inne informacje, które
436
Część II
mogą być ignorowane przez aplikację lub oprogramowanie dostępu do bazy
danych.
Jeśli wykonujemy operacje DML (
Data Manipulation Language
- język
operowania danymi), wykorzystując procedury pamiętane, to powinniśmy
dokonać zabronionych dla bazy danych lub procedury prób modyfikacji danych
(np. wprowadzić błędną wartość). Umieszczając w procedurach pamiętanych
elementy oprogramowania typu DML, bierzemy odpowiedzialność za
upewnienie się o ich poprawnym działaniu.
Przeprowadzanie testów w środowisku wielodostępnym
Implementując system wielodostępny, musimy uwzględnić przede wszystkim dwa
czynniki. Pierwszy to współbieżność. Duża liczba użytkowników próbujących
uzyskać dostęp do tych samych zasobów bazy danych może powodować
różnorodne problemy, zktórych najważniejsze związane są zzatorami
i blokowaniem dostępu. Użytkownicy mogą sobie wzajemnie blokować dostęp do
zasobów, których potrzebują. Za zatory mogą być również odpowiedzialne
działające w systemie procesy.
Drugim wyzwaniem, stawianym przez środowisko sieciowe, są ograniczenia
zasobów systemu. Układ poprawnie działający przy dziesięciu użytkownikach
może zawieść, gdy korzysta z niego dwadzieścia osób. Podłączenie się każdego
nowego użytkownika obciąża system, nawet jeśli w danej chwili nie korzysta on
z zasobów i nie blokuje połączeń. Istnieją po prostu fizyczne ograniczenia
spowodowane wydajnością przetwarzania danych przez serwer, szybkością
transmisji, oraz maksymalną liczbą transakcji możliwych do zrealizowania w sieci.
W czasie przeprowadzania testów powinno się przyjąć najgorszy scenariusz (jeśli
w systemie docelowym nie będzie pracowało więcej niż dwustu użytkowników, to
w czasie weryfikacji aplikacji należy ją sprawdzać przy czterystu odbiorcach).
Istotną sprawą jest zbadanie granic możliwości konstruowanego systemu. Planując
wydajność aplikacji warto się oprzeć na oszacowaniu zasobów dostępnych dla
użytkownika.
Sterowanie współbieżnością i model klient/serwer
Dostęp do danych na serwerze SQL, inaczej niż w lokalnych bazach danych, nie
jest zazwyczaj możliwy na zasadzie rekord po rekordzie. Niektóre serwery nie są
nawet w stanie blokować dostępu do pojedynczych wierszy, blokowane są większe
obiekty: strony lub segmenty celem zabezpieczenia przed zakłóceniami podczas
modyfikowania danych przez użytkownika.
Uniemożliwia to innym użytkownikom jakiekolwiek zmiany w zbiorze.
RENTMAN- po narodzinach
437
Programista musi wiedzieć, wjaki sposób jest realizowane sterowanie
współbieżnością na platformach DBMS. Powinniśmy ograniczać do minimum
liczbę zatorów. Za wszelką cenę należy unikać przetwarzania danych rekord po
rekordzie. Rozważmy poniższą procedurę, służąca do modyfikacji tabeli LEASE
i ustawiania wartości danych z kolumny
LawnService
na
False
:
With taLease do
While not EOF do begin
If taLEASEPetDeposit.AsFloat<>0 then
taLEASELawnservice.AsBoolean:=False;
Next;
end;
To standardowe na lokalnych tabelach rozwiązanie jest jednak powodem
problemów na serwerach baz danych, bowiem powoduje zablokowanie tabeli
Lease
w trakcie modyfikacji pola LawnService. Zamyka na chwilę dostęp do
danych dla innych użytkowników i działa relatywnie wolno. Zachodzi również
możliwość, że serwer rozszerzy blokadę rekordów lub strony na całą tabelę,
uniemożliwiając na czas jej trwania jakikolwiek dostęp do tabeli dla innych
użytkowników.
Aby wykonać podobne aktualizacje, należy stosować SQL: zarówno procedury
pamiętane, jak izwykłe zapytania. Należy trzymać się zasady: „Unikać
indywidualnego przetwarzania rekordów”. Niech robi to serwer, tak jest lepiej.
Oto zapytanie w języku SQL, które wykonuje to samo zadanie:
UPDATE LEASE
SET LawnService=’F’
WHERE PetDeposit<>0 AND LawnSerwice<>’F’
Zadanie zostanie wykonane wjednym przejściu, ablokady (blokada) będą
zwolnione tak szybko, jak to jest możliwe.
Transakcje i serwery baz danych
Przypomnijmy, że transakcja to grupa zmian bazy danych przetwarzana jako
pojedyncza porcja (
batch
). Zmiany są wykonywane albo w komplecie, albo wcale.
Zostało to zaimplementowane przy wykorzystaniu protokołów odtwarzania
transakcji (
transaction/redo logs
). Prawidłowe określenie rozmiaru protokołu
transakcji, ostrożność, aby nie przekraczać ich obszaru, wydajne zapisywanie
i odtwarzanie transakcji - to tylko niektóre realne problemy, które muszą być brane
pod uwagę przez projektanta aplikacji klient/serwer.
Delphi umożliwia sterowanie transakcjami, opartymi na serwerze, poprzez
komponent
TDatabase
. Aby rozpocząć transakcję, należy wywołać metodę
StartTransaction
, do jej zakończenia metodę
Commit
, a do odtworzenia
Rollback
. Wywołanie tych metod w środowisku klient/serwer daje ten sam
zanotowane.pl doc.pisz.pl pdf.pisz.pl hannaeva.xlx.pl
RENTMAN- po narodzinach
Zakładamy, że skompletowaliście Państwo program RENTMAN zgodnie z planem
opracowanym we wcześniejszych rozdziałach książki. Faza analizy, planowania
i konstruowania aplikacji jest w zasadzie za nami.
Zgodnie z założonym, pięciofazowym modelem pracy nad aplikacją, pozostały
nam jeszcze etapy testowania i konserwacji. Zbadamy i omówimy liczne problemy
związane z życiem aplikacji po jej skonstruowaniu.
Testowanie aplikacji
Istnieją liczne sposoby testowania programów i zapewniania ich jakości, jednakże
kilka ogólnych wytycznych pozostaje prawdziwymi, niezależnie od założonej
drogi postępowania. Oto wskazówki, odnoszące się do testowania aplikacji:
Należy stwierdzić, czy program realizuje całkowicie założone wcześniej
zadania. Nie ograniczajmy się jedynie do wyszukiwania typowych błędów
w oprogramowaniu („pluskiew”); pełny proces sprawdzania wymaga spojrzenia
na aplikację jak na wielki obraz, powinniśmy wiedzieć, co program miał robić,
kiedy go planowaliśmy i porównać z efektem końcowym.
Przyjrzyjmy się kluczowym funkcjom, które program ma realizować
i zastanówmy się, czy aplikacja spełnia swoje zadania, czy jej funkcje są
realizowane tak, jak zaplanowaliśmy. Należy również przemyśleć sposób
zbadania, wjaki każda funkcja realizuje przypisane jej cele. Rzetelne
testowanie wymaga porównania aplikacji zoryginalną specyfikacją jej
właściwości.
Po autorskiej weryfikacji należy przeprowadzić zarówno testy wewnętrzne, jak
i zewnętrzne. Wewnętrzne są prowadzone przez autora i jego zespół programistów.
Zewnętrzne mogą wykonywać ludzie z tej samej grupy, lecz w żaden sposób nie
związani z projektem (członkowie grupy prowadzącej beta testy oraz wszelkie inne
zespoły spoza przedsiębiorstwa). Oto kilka wskazówek przydatnych przy
prowadzeniu testów wewnętrznych:
Sprawdzić, czy więzy nałożone na bazę danych są realizowane prawidłowo.
434
Część II
Sprawdzić obiekty umiejscowione na serwerze, takie jak procedury pamiętane
(
stored procedures
) i perspektywy (
views
), upewniając się, czy wykonują
założone zadania.
Przetestować działanie programu podczas pracy z wieloma użytkownikami.
Zweryfikować, czy zdefiniowane prawa dostępu prawidłowo sterują
uprawnieniami.
Sprawdzić program na komputerze możliwie jak najbardziej podobnym do
maszyny użytkownika.
Poniższa lista zawiera kilka dodatkowych wskazówek do testów zewnętrznych:
Ustalić sformalizowaną procedurę raportowania obłędach wprogramie
i zasadach reakcji na takie informacje.
Zaplanować sposób łatwej dystrybucji aktualizacji i pakietów poprawiających
błędy.
Zapewnić pomoc techniczną ludzi nie związanych z testowaniem aplikacji.
Ustanowić małą grupę kluczowych użytkowników do prowadzenia beta testów.
Prowadzić testy przydatności z użytkownikami o różnym poziomie
zaawansowania.
Pamiętać, że to użytkownicy decydują, czy aplikacja im odpowiada oraz spełnia
ich Szczegółowa analiza zewnętrznego testowania programów wykracza poza
ramy tej książki.
Pierwsze i najważniejsze pytanie: Czy aplikacja realizuje zadanie, do którego
została zaprojektowana? W rozdziale 8 określono przeznaczenie programu
RENTMAN: ma być systemem ułatwiającym zarządzanie wynajmowanymi
nieruchomościami.
Czy program wywiązuje się z postawionego zadania? Wydaje się, że tak, ale
jedynie Allodium może naprawdę stwierdzić, czy aplikacja robi to w stopniu
przynajmniej dostatecznym.
Przejdźmy do funkcji kluczowych. Zgodnie z tym, co napisano w rozdziale 8,
aplikacja powinna:
Umożliwiać zapisywanie i konserwowanie danych o wynajmie nieruchomości.
Pozwalać na śledzenie realizacji prac związanych z ich utrzymaniem.
Umożliwiać rozliczanie najemców.
Dostarczać informacji o historii nieruchomości.
RENTMAN- po narodzinach
435
I znów musimy stwierdzić, że RENTMAN wydaje się spełniać wszystkie założone
funkcje oraz że jedynie Allodium może w pełni ocenić w jakim zakresie.
Przed rozpoczęciem testowania aplikacji przyjrzyjmy się oddzielnie każdej
wskazówce do przeprowadzania kontroli wewnętrznej, i zobaczmy, jak mogą być
one zastosowane w przypadku programu RENTMAN.
Sprawdzić więzy nałożone na bazę danych aplikacji
Należy sprawdzić (próbując je złamać), czy nałożone więzy istnieją, są wzajemnie
spójne i działają zgodnie z założeniami. Przy sprawdzaniu programu RENTMAN
powinniśmy spróbować:
Usunąć z pliku tabeli LEASE najemców, którzy utrzymują dzierżawę.
Wprowadzić do pola City tabeli PROPERTY wartość inną niż Richardson,
Dallas, Plano, Norman, Oklahoma City i Edmond.
Usunąć z tabeli PROPERTY rekord, opisujący nieruchomość, która zgodnie
z danymi z tabeli LEASE jest aktualnie wynajmowana.
Pominąć pole Deposit przy wprowadzaniu danych do tabeli PROPERTY.
Wprowadzić niewłaściwą datę do pola StartDate tabeli WORDER.
Dodać do tabeli PROPERTY nieruchomość mającą sześć sypialni.
Nie ma chyba wątpliwości, na czym polega ten etap testowania. Sprawdzamy
warunki konieczne poprawnego działania aplikacji, nałożone poprzez więzy bazy
danych.
Sprawdzić obiekty umiejscowione na serwerze
Jeśli zaimplementowany program wykorzystuje procedury pamiętane (
stored
procedures
), perspektywy (
views
) lub inne obiekty umiejscowione na serwerze, to
należy sprawdzić ich pracę. Testowanie systemów klienta jest dla wszystkich
oczywiste, tymczasem konieczność kontroli działania obiektów osadzonych na
serwerze jest przez wielu programistów aplikacji klient/serwer zaniedbywana lub
minimalizowana. A przecież SQL jest językiem, takim samym jak Object Pascal
czy C++. Oto kilka spraw, na które należy zwrócić uwagę:
Jeśli mamy zbudowany raport końcowy, który jest produkowany przez
procedurę pamiętaną lub inny obiekt umiejscowiony na serwerze, to należy
uruchomić procedurę poza aplikacją lub kreatorem raportów, aby się upewnić,
że działa zgodnie z oczekiwaniami. Nawet jeśli sprawdziliśmy pracę procedury
za pośrednictwem naszego programu, to uruchomienie jej bezpośrednio
pozwala zobaczyć ewentualne komunikaty serwera oraz inne informacje, które
436
Część II
mogą być ignorowane przez aplikację lub oprogramowanie dostępu do bazy
danych.
Jeśli wykonujemy operacje DML (
Data Manipulation Language
- język
operowania danymi), wykorzystując procedury pamiętane, to powinniśmy
dokonać zabronionych dla bazy danych lub procedury prób modyfikacji danych
(np. wprowadzić błędną wartość). Umieszczając w procedurach pamiętanych
elementy oprogramowania typu DML, bierzemy odpowiedzialność za
upewnienie się o ich poprawnym działaniu.
Przeprowadzanie testów w środowisku wielodostępnym
Implementując system wielodostępny, musimy uwzględnić przede wszystkim dwa
czynniki. Pierwszy to współbieżność. Duża liczba użytkowników próbujących
uzyskać dostęp do tych samych zasobów bazy danych może powodować
różnorodne problemy, zktórych najważniejsze związane są zzatorami
i blokowaniem dostępu. Użytkownicy mogą sobie wzajemnie blokować dostęp do
zasobów, których potrzebują. Za zatory mogą być również odpowiedzialne
działające w systemie procesy.
Drugim wyzwaniem, stawianym przez środowisko sieciowe, są ograniczenia
zasobów systemu. Układ poprawnie działający przy dziesięciu użytkownikach
może zawieść, gdy korzysta z niego dwadzieścia osób. Podłączenie się każdego
nowego użytkownika obciąża system, nawet jeśli w danej chwili nie korzysta on
z zasobów i nie blokuje połączeń. Istnieją po prostu fizyczne ograniczenia
spowodowane wydajnością przetwarzania danych przez serwer, szybkością
transmisji, oraz maksymalną liczbą transakcji możliwych do zrealizowania w sieci.
W czasie przeprowadzania testów powinno się przyjąć najgorszy scenariusz (jeśli
w systemie docelowym nie będzie pracowało więcej niż dwustu użytkowników, to
w czasie weryfikacji aplikacji należy ją sprawdzać przy czterystu odbiorcach).
Istotną sprawą jest zbadanie granic możliwości konstruowanego systemu. Planując
wydajność aplikacji warto się oprzeć na oszacowaniu zasobów dostępnych dla
użytkownika.
Sterowanie współbieżnością i model klient/serwer
Dostęp do danych na serwerze SQL, inaczej niż w lokalnych bazach danych, nie
jest zazwyczaj możliwy na zasadzie rekord po rekordzie. Niektóre serwery nie są
nawet w stanie blokować dostępu do pojedynczych wierszy, blokowane są większe
obiekty: strony lub segmenty celem zabezpieczenia przed zakłóceniami podczas
modyfikowania danych przez użytkownika.
Uniemożliwia to innym użytkownikom jakiekolwiek zmiany w zbiorze.
RENTMAN- po narodzinach
437
Programista musi wiedzieć, wjaki sposób jest realizowane sterowanie
współbieżnością na platformach DBMS. Powinniśmy ograniczać do minimum
liczbę zatorów. Za wszelką cenę należy unikać przetwarzania danych rekord po
rekordzie. Rozważmy poniższą procedurę, służąca do modyfikacji tabeli LEASE
i ustawiania wartości danych z kolumny
LawnService
na
False
:
With taLease do
While not EOF do begin
If taLEASEPetDeposit.AsFloat<>0 then
taLEASELawnservice.AsBoolean:=False;
Next;
end;
To standardowe na lokalnych tabelach rozwiązanie jest jednak powodem
problemów na serwerach baz danych, bowiem powoduje zablokowanie tabeli
Lease
w trakcie modyfikacji pola LawnService. Zamyka na chwilę dostęp do
danych dla innych użytkowników i działa relatywnie wolno. Zachodzi również
możliwość, że serwer rozszerzy blokadę rekordów lub strony na całą tabelę,
uniemożliwiając na czas jej trwania jakikolwiek dostęp do tabeli dla innych
użytkowników.
Aby wykonać podobne aktualizacje, należy stosować SQL: zarówno procedury
pamiętane, jak izwykłe zapytania. Należy trzymać się zasady: „Unikać
indywidualnego przetwarzania rekordów”. Niech robi to serwer, tak jest lepiej.
Oto zapytanie w języku SQL, które wykonuje to samo zadanie:
UPDATE LEASE
SET LawnService=’F’
WHERE PetDeposit<>0 AND LawnSerwice<>’F’
Zadanie zostanie wykonane wjednym przejściu, ablokady (blokada) będą
zwolnione tak szybko, jak to jest możliwe.
Transakcje i serwery baz danych
Przypomnijmy, że transakcja to grupa zmian bazy danych przetwarzana jako
pojedyncza porcja (
batch
). Zmiany są wykonywane albo w komplecie, albo wcale.
Zostało to zaimplementowane przy wykorzystaniu protokołów odtwarzania
transakcji (
transaction/redo logs
). Prawidłowe określenie rozmiaru protokołu
transakcji, ostrożność, aby nie przekraczać ich obszaru, wydajne zapisywanie
i odtwarzanie transakcji - to tylko niektóre realne problemy, które muszą być brane
pod uwagę przez projektanta aplikacji klient/serwer.
Delphi umożliwia sterowanie transakcjami, opartymi na serwerze, poprzez
komponent
TDatabase
. Aby rozpocząć transakcję, należy wywołać metodę
StartTransaction
, do jej zakończenia metodę
Commit
, a do odtworzenia
Rollback
. Wywołanie tych metod w środowisku klient/serwer daje ten sam