Wykład 11

dr in . Włodzimierz D browski

P

olsko

J

apo ska

W

y sza

S

zkoła

T

echnik

K

omputerowych

Katedra Systemów Informacyjnych, pokój 310

e-mail:

[e-mail]

Materiał wył cznie do u ytku przez studentów PJWSTK kursu BYT.

Copyright © 2002 – 2004 by W. D browski - wszelkie prawa zastrze one.

Materiał ani jego cz

nie mo e by w adnej formie i za pomoc jakichkolwiek rodków technicznych reprodukowany bez zgody wła ciciela praw autorskich.

Wersja PB

Budowa i integracja

systemów informacyjnych

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 2

marzec, 2004;

PB

Okre lenie niezawodno ci oprogramowania

Miary niezawodno ci:

Prawdopodobie stwo bł dnego wykonania podczas realizacji transakcji.

Ka de bł dne wykonanie powoduje zerwanie całej transakcji. Miar jest

cz sto wyst powania transakcji, które nie powiodły si wskutek bł dów.

Cz stotliwo wyst powania bł dnych wykona : ilo bł dów w jednostce

czasu. Np. 0.1/h oznacza, e w ci gu godziny ilo spodziewanych bł dnych

wykona wynosi 0.1. Miara ta jest stosowana w przypadku systemów, które nie

maj charakteru transakcyjnego.

redni czas mi dzy bł dnymi wykonaniami - odwrotno poprzedniej miary.

Dost pno : prawdopodobie stwo, e w danej chwili system b dzie dost pny

do u ytkowania. Miar t mo na oszacowa na podstawie stosunku czasu, w

którym system jest dost pny, do czasu od wyst pienia bł du do powrotu do

normalnej sytuacji. Miara zale y nie tylko od bł dnych wykona , ale tak e od

narzutu bł dów na niedost pno systemu.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 3

marzec, 2004;

PB

Oszacowanie niezawodno ci

Niekiedy poziom niezawodno ci (warto pewnej miary lub miar) jest okre lany

w wymaganiach klienta.

Cz ciej, jest on jednak wyra ony w terminach jako ciowych, co bardzo utrudnia

obiektywn weryfikacj . Jednak e informacja o niezawodno ci jest przydatna

równie wtedy, gdy klient nie okre lił jej jednoznacznie w wymaganiach.

Dlaczego?

Cz stotliwo wyst powania bł dnych wykona ma du y wpływ na koszt

konserwacji oprogramowania (serwis telefoniczny + wizyty u klienta).

Znajomo niezawodno ci pozwala oszacowa koszt serwisu, liczb

personelu, liczb zgłosze telefonicznych, ł czny koszt serwisu.

Znajomo niezawodno ci pozwala oceni i polepszy procesy wytwarzania

pod k tem zminimalizowania ł cznego kosztu wynikaj cego z kosztów

wytwarzania, kosztów utrzymania, powodzenia na rynku, reputacji firmy.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 4

marzec, 2004;

PB

Wzrost niezawodno ci oprogramowania

Rezultatem wykrycia przyczyn bł dów jest ich usuni cie.

Je eli przy tym nie wprowadza si nowych bł dów, to mo na mówi o wzro cie

niezawodno ci.

Je eli wykonywane s testy czysto statystyczne to wzrost niezawodno ci okre la

si nast puj cym wzorem (logarytmiczny wzrost niezawodno ci):

Niezawodno = Niezawodno pocz tkowa ×××× exp(-C ×××× liczba testów)

Miar niezawodno ci jest cz stotliwo wyst powania bł dnych wykona .

Stała C zale y od konkretnego systemu. Mo na j okre li na podstawie

obserwacji statystycznych niezawodno ci systemu, stosuj c np. metod

najmniejszych kwadratów.

Szybszy wzrost niezawodno ci mo na osi gn je eli dane testowe s dobierane

nie w pełni losowo, lecz w kolejnych przebiegach testuje si sytuacje, które dot d

nie były testowane.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 5

marzec, 2004;

PB

Wykrywanie bł dów - rodzaje testów

Dynamiczne testy zorientowane na wykrywanie bł dów dzieli si na:

Testy funkcjonalne (functional tests, black-box tests), które zakładaj

znajomo jedynie wymaga wobec testowanej funkcji. System jest

traktowany jako czarna skrzynka, która w nieznany sposób realizuje

wykonywane funkcje. Testy powinny wykonywa osoby, które nie były

zaanga owane w realizacj testowanych fragmentów systemu.

Testy strukturalne (structural tests, white-box tests, glass-box tests), które

zakładaj znajomo sposobu implementacji testowanych funkcji.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 6

marzec, 2004;

PB

Testy funkcjonalne

Pełne przetestowanie rzeczywistego systemu jest praktycznie niemo liwe z powodu

ogromnej liczby kombinacji danych wej ciowych i stanów. Nawet dla stosunkowo

małych programów ta liczba kombinacji jest tak ogromna, e pełne testowanie

wszystkich przypadków musiałoby rozci gn si na miliardy lat.

Zwykle zakłada si , e je eli dana funkcja działa poprawnie dla

kilku danych

wej ciowych, to działa tak e poprawnie dla

całej klasy danych wej ciowych.

Jest to wnioskowanie czysto heurystyczne. Fakt poprawnego działania w kilku

przebiegach nie gwarantuje zazwyczaj, ze bł dne wykonanie nie pojawi si dla

innych danych z tej samej klasy.

Podział danych wej ciowych na klasy odbywa si na podstawie opisu wymaga , np.

Rachunek o warto ci do 1000 zł mo e by zatwierdzony przez kierownika.
Rachunek o warto ci powy ej 1000 zł musi by zatwierdzony przez prezesa.

Takie wymaganie sugeruje podział danych wej ciowych na dwie klasy w zale no ci

od wysoko ci rachunku. Jednak przetestowanie tylko dwóch warto ci, np. 500 i

1500 jest zazwyczaj niewystarczaj ce. Konieczne jest tak e przetestowanie warto ci

granicznych, np. 0, dokładnie 1000 oraz maksymalnej wyobra alnej warto ci.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 7

marzec, 2004;

PB

Kombinacja elementarnych warunków

Z poprzedniego przykładu wida , e testy tylko dla jednej danej wej ciowej

musz by przeprowadzone dla pi ciu warto ci: np. 0, 500, 1000, 1500, max.

Je eli takich danych jest wiele, to mamy do czynienia z kombinatoryczn

eksplozj przypadków testowych.

Dziel c dane wej ciowe na klasy nale y wi c bra pod uwag rozmaite kombinacje

elementarnych warunków. Np. do wymienionego warunku doł czony jest

nast puj cy:

Kierownik mo e zatwierdzi miesi cznie rachunek o ł cznej warto ci do 10 000 zł.
Ka dy rachunek przekraczaj cy t warto musi by zatwierdzony przez prezesa.

W ród danych wyj ciowych mo na teraz wyró ni nast puj ce klasy:

• rachunek do 1000 zł nie przekraczaj cy ł cznego limitu 10 000 zł.

• rachunek do 1000 zł przekraczaj cy ł czny limit 10 000 zł.

• rachunek powy ej 1000 zł nie przekraczaj cy ł cznego limitu 10 000 zł.

• rachunek powy ej 1000 zł przekraczaj cy ł czny limit 10 000 zł.

Uwzgl dnienie przypadków granicznych powoduje dalsze rozmno enie
przypadków testowych: (0, 500, 1000, 1500, max)

× (<10000, 10000, >10000)

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 8

marzec, 2004;

PB

Eksplozja kombinacji danych testowych

W praktyce przetestowanie wszystkich kombinacji danych wej ciowych (nawet

zredukowanych do “typowych” i “granicznych”) jest najcz ciej niemo liwe.

Konieczny jest wybór tych kombinacji.

Ogólne zalecenia takiego wyboru s nast puj ce:

Mo liwo wykonania funkcji jest wa niejsza ni jako jej wykonania.

Brak mo liwo ci wykonania funkcji jest powa niejszym bł dem ni np.

niezbyt poprawne wy wietlenie jej rezultatów na ekranie.

Funkcje systemu znajduj ce si w poprzedniej wersji s istotniejsze ni

nowo wprowadzone. U ytkownicy, którzy posługiwali si dana funkcj w

poprzedniej wersji systemu b d bardzo niezadowoleni je eli w nowej wersji

ta funkcja przestanie działa .

Typowe sytuacje s wa niejsze ni wyj tki lub sytuacje skrajne. Bł d w

funkcji wykonywanej cz sto lub dla danych typowych jest znacznie bardziej

istotny ni bł d w funkcji wykonywanej rzadko dla dla nietypowych danych.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 9

marzec, 2004;

PB

Testy strukturalne

W przypadku testów strukturalnych, dane wej ciowe dobiera si na podstawie

analizy struktury programu realizuj cego testowane funkcje.

Kryteria doboru danych testowych s nast puj ce:

Kryterium pokrycia wszystkich instrukcji. Zgodnie z tym kryterium dane

wej ciowe nale y dobiera tak, aby ka da instrukcja została wykonana co

najmniej raz. Spełnienie tego kryterium zwykle wymaga niewielkiej liczby

testów. To kryterium mo e by jednak bardzo nieskuteczne.

if x > 0 then begin ... end; y := ln( x);

Dla x >0 wykonane b d wszystkie instrukcje, ale dla x <= 0 program jest bł dny.

Kryterium pokrycia instrukcji warunkowych. Dane wej ciowe nale y dobiera

tak, aby ka dy elementarny warunek instrukcji warunkowej został co najmniej raz

spełniony i co najmniej raz nie spełniony. Testy nale y wykona tak e dla ka dej

warto ci granicznej takiego warunku. Zastosowanie tego warunku pozwoli wykry

bł d z poprzedniego przykładu, gdy zmusi do testu dla x = 0 oraz x < 0.

Istnieje szereg innych kryteriów prowadz cych do bardziej wymagaj cych testów.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 10

marzec, 2004;

PB

Testowanie programów zawieraj cych

p tle

Kryteria doboru danych wej ciowych mog opiera si o nast puj ce zalecenia:

Nale y dobra dane wej ciowe tak, aby nie została wykonana adna iteracja

p tli, lub, je eli to niemo liwe, została wykonana minimalna liczba iteracji.

Nale y dobra dane wej ciowe tak, aby została wykonana maksymalna liczba

iteracji.

Nale y dobra dane wej ciowe tak, aby została wykonana przeci tna liczba

iteracji.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 11

marzec, 2004;

PB

Programy uruchamiaj ce

debuggers

Mog by przydatne dla wewn trznego testowania jak i dla testowania przez osoby

zewn trzne. Zakładaj testowanie na zasadzie białej skrzynki (znajomo kodu).

Własno ci programów uruchamiaj cych:

Wy wietlenie stanu zmiennych programu i interakcja z testuj cym z u yciem

symboli kodu ródłowego.

Wykonywanie programów krok po kroku, z ró n granulowo ci instrukcji

Ustanowienie punktów kontrolnych w programie (zatrzymuj cych wykonanie)

Ustanowienie obserwatorów warto ci zmiennych

Zarz dzanie plikiem ródłowym podczas testowania i ewentualna poprawa

wykrytych bł dów w tym pliku.

Tworzenie dziennika testowania, umo liwiaj cego powtórzenie testowego

przebiegu.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 12

marzec, 2004;

PB

Analizatory przykrycia kodu

coverage analysers

S to programy umo liwiaj ce ustalenie obszarów kodu ródłowego, które były

wykonane w danym przebiegu testowania. Umo liwiaj wykrycie martwego

kodu, kodu uruchamianego przy bardzo specyficznych danych wej ciowych oraz

(niekiedy) kodu wykonywanego bardzo cz sto (co mo e by przyczyn w skiego

gardła w programie).

Bardziej zaawansowane analizatory przykrycia kodu umo liwiaj :

Zsumowanie danych z kilku przebiegów (dla ró nych kombinacji danych

wej ciowych) np. dla łatwiejszego wykrycia martwego kodu.

Wy wietlenie grafów sterowania, dzi ki czemu mo na łatwiej monitorowa

przebieg programu

Wyprowadzenie informacji o przykryciu, umo liwiaj ce poddanie przykrytego

kodu dalszym testom.

Operowanie w rodowisku rozwoju oprogramowania.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 13

marzec, 2004;

PB

Programy porównuj ce

S to narz dzia programistyczne umo liwiaj ce porównanie dwóch programów,

plików lub zbiorów danych celem wykrycia cech wspólnych i ró nic. Cz sto s

niezb dne do porównania wyników testów z wynikami oczekiwanymi. Programy

porównuj ce przekazuj w czytelnej postaci ró nice pomi dzy aktualnymi i

oczekiwanymi danymi wyj ciowymi.

Ekranowe programy porównuj ce mog by bardzo u yteczne dla testowania

oprogramowania interakcyjnego. S niezast pionym rodkiem dla testowania

programów z graficznym interfejsem u ytkownika.

comparators

Pozostałe narz dzia do testowania:

Du a ró norodno narz dzi stosowanych w ró nych fazach rozwoju

oprogramowania. Np. wspomaganie do planowania testów, automatyczne

zarz dzania danymi wyj ciowymi, automatyczna generacja raportów z testów,

generowanie statystyk jako ci i niezawodno ci, wspomaganie powtarzalno ci

testów, itd.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 14

marzec, 2004;

PB

Testy statyczne

Polegaj na analizie kodu bez uruchomienia programu. Techniki s nast puj ce:

• dowody poprawno ci

• metody nieformalne

Dowody poprawno ci nie s praktycznie mo liwe dla rzeczywistych programów.

Istniej wył cznie w urojeniach (pseudo-?) teoretyków informatyki. Stosowanie

ich dla programów o obecnej skali i zło ono ci jest pozbawione sensu.

(Niestety, nadal wyst puje nacisk rodowiska akademickiego na rozwój i nauczanie tych

od dawna martwych metod.)

Statyczne metody nieformalne polegaj na analizie kodu przez programistów.

Dwa niewykluczaj ce si podej cia:

• ledzenie przebiegu programu (wykonywanie programu “w my li” przez

analizuj ce osoby)

• wyszukiwanie typowych bł dów:

Testy nieformalne s niedocenione, chocia bardzo efektywne w praktyce.

Testy funkcjonalne s bardziej skuteczne ni testy strukturalne.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 15

marzec, 2004;

PB

Typowe bł dy wykrywane statycznie

• Niezainicjowane zmienne

• Porównania na równo liczb zmiennoprzecinkowych

• Indeksy wykraczaj ce poza tablice

• Bł dne operacje na wska nikach

• Bł dy w warunkach instrukcji warunkowych

• Nieko cz ce si p tle

• Bł dy popełnione dla warto ci granicznych (np. > zamiast >=)

• Bł dne u ycie lub pomini cie nawiasów w zło onych wyra eniach

• Nieuwzgl dnienie bł dnych danych
Strategia testów nieformalnych:
Programista, który dokonał implementacji danego modułu w nieformalny sposób

analizuje jego kod.

Kod uznany przez programist za poprawny jest analizowany przez

do wiadczonego programist . Je eli znajdzie on pewn liczb bł dów, moduł jest

zwracany programi cie do poprawy.

Szczególnie istotne moduły s analizowane przez grup osób.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 16

marzec, 2004;

PB

Ocena liczby bł dów

Bł dy w oprogramowaniu niekoniecznie s bezpo rednio powi zane z jego

zawodno ci . Oszacowanie liczby bł dów ma jednak znaczenie dla producenta

oprogramowania, gdy ma wpływ na koszty konserwacji oprogramowania.

Szczególnie istotne dla firm sprzedaj cych oprogramowanie pojedynczym lub

nielicznym u ytkownikom (relatywnie du y koszt usuni cia bł du).

Podstawy szacowania kosztu konserwacji zwi zanego z usuwaniem bł dów:

Szacunkowa liczba bł dów w programie

redni procent bł dów zgłaszanych przez u ytkownika systemu, na podstawie

danych z poprzednich przedsi wzi .

redni koszt usuni cia bł du na podstawie danych z poprzednich przedsi wzi .

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 17

marzec, 2004;

PB

Technika “posiewania bł dów”.

Polega na tym, e do programu celowo wprowadza si pewn liczb bł dów

podobnych do tych, które wyst puj w programie. Wykryciem tych bł dów

zajmuje si inna grupa programistów ni ta, która dokonała “posiania” bł dów.

Załó my, e:

N oznacza liczb posianych bł dów

M oznacza liczb wszystkich wykrytych bł dów

X oznacza liczb posianych bł dów, które zostały wykryte

Szacunkowa liczba bł dów przed wykonaniem testów: (M - X) * N/X

Szacunkowa liczba bł dów po usuni ciu wykrytych

(“posiane” bł dy zostały te usuni te):

(M - X) * (N/X - 1)

Szacunki te mog by mocno chybione, je eli “posiane” bł dy nie b d podobne

do rzeczywistych bł dów wyst puj cych w programie.

Technika ta pozwala równie na przetestowanie skuteczno ci metod testowania.

Zbyt mała warto X/N oznacza konieczno poprawy tych metod.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 18

marzec, 2004;

PB

Testy systemu

Techniki:

- testowanie wst puj ce

- testowanie zst puj ce

Testowanie wst puj ce: najpierw testowane s pojedyncze moduły, nast pnie

moduły coraz wy szego poziomu, a do osi gni cia poziomu całego systemu.

Zastosowanie tej metody nie zawsze jest mo liwe, gdy cz sto moduły s od

siebie zale ne. Niekiedy moduły współpracuj ce mo na zast pi

implementacjami szkieletowymi.

Testowanie zst puj ce: rozpoczyna si od testowania modułów wy szego

poziomu. Moduły ni szego poziomu zast puje si implementacjami

szkieletowymi. Po przetestowaniu modułów wy szego poziomu doł czane s

moduły ni szego poziomu. Proces ten jest kontynuowany a do zintegrowania i

przetestowania całego systemu.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 19

marzec, 2004;

PB

Testy pod obci eniem, testy odporno ci

Testy obci eniowe (stress testing). Celem tych testów jest zbadanie wydajno ci i

niezawodno ci systemu podczas pracy pod pełnym lub nawet nadmiernym

obci eniem. Dotyczy to szczególnie systemów wielodost pnych i sieciowych.

Systemy takie musz spełnia wymagania dotycz ce wydajno ci, liczby

u ytkowników, liczby transakcji na godzin . Testy polegaj na wymuszeniu

obci enia równego lub wi kszego od maksymalnego.

Testy odporno ci (robustness testing). Celem tych testów jest sprawdzenie

działania w przypadku zaj cia niepo danych zdarze , np.

• zaniku zasilania

• awarii sprz towej

• wprowadzenia niepoprawnych danych

• wydania sekwencji niepoprawnych polece

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 20

marzec, 2004;

PB

Bezpiecze stwo oprogramowania

Pewnej systemy s krytyczne z punktu widzenia bezpiecze stwa ludzi, np.

aparatura medyczna, oprogramowanie wspomagaj ce sterowanie samolotem.

Mo e to by tak e zagro enie po rednie, np. systemy eksperckie w

dziedzinie medycyny, systemy informacji o lekach.

Bezpiecze stwo niekoniecznie jest poj ciem to samym z niezawodno ci .

System zawodny mo e by bezpieczny, je eli skutki bł dnych wykona nie

s gro ne.

Wymagania wobec systemu mog by niepełne i nie opisywa zachowania

systemu we wszystkich sytuacjach. Dotyczy to zwłaszcza sytuacji

wyj tkowych, np. wprowadzenia niepoprawnych danych. Wa ne jest, aby

system zachował si bezpiecznie tak e wtedy, gdy wła ciwy sposób reakcji

nie został opisany.

Niebezpiecze stwo mo e tak e wynika z awarii sprz towych. Analiza

bezpiecze stwa musi uwzgl dnia oba czynniki.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 21

marzec, 2004;

PB

Analiza bezpiecze stwa

Zaczyna si od okre lenia potencjalnych niebezpiecze stw zwi zanych z

u ytkowaniem systemu: mo liwo ci utraty ycia, zdrowia, strat materialnych,

złamania przepisów prawnych.

Np. dla programu podatkowego mog wyst pi nast puj ce niebezpiecze stwa:

- bł dne rozliczenie si z urz dem podatkowym

- nie zło enie zeznania podatkowego

- zło enie wielu zezna dla jednego podatnika

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 22

marzec, 2004;

PB

Drzewo bł dów

fault tree

Korzeniem drzewa s jest jedna z rozwa anych niebezpiecznych sytuacji.

Wierzchołkami s sytuacje po rednie, które mog prowadzi do sytuacji

odpowiadaj cej wierzchołkowi wy szego poziomu.

Bł dne rozliczenie

podatnika

Bł dne rozliczenie

podatnika

Wprowadzenie bł dnych

danych

Wprowadzenie bł dnych

danych

Bł d

obliczeniowy

Bł d

obliczeniowy

Bł dny wydruk

rozliczenia

Bł dny wydruk

rozliczenia

Bł dnie obliczona

podstawa opodatkowania

Bł dnie obliczona

podstawa opodatkowania

Bł dnie obliczony

podatek

Bł dnie obliczony

podatek

Bł dnie obliczona

nadpłata/dopłata

Bł dnie obliczona

nadpłata/dopłata

Bł dnie zsumowane

dochody

Bł dnie zsumowane

dochody

Bł dnie zsumowane

ulgi

Bł dnie zsumowane

ulgi

lub

lub

lub

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 23

marzec, 2004;

PB

Techniki zmniejszania niebezpiecze stwa

Poło enie wi kszego nacisku na unikanie bł dów podczas implementacji

fragmentów systemu, w których bł dy mog prowadzi do niebezpiecze stw.

Zlecenie realizacji odpowiedzialnych fragmentów systemu bardziej

do wiadczonym programistom.

Zastosowanie techniki programowania N-wersyjnego w przypadku

wymienionych fragmentów systemu.

Szczególnie dokładne przetestowanie tych fragmentów systemu.

Wczesne wykrywanie sytuacji, które mog by przyczyn niebezpiecze stwa i

podj cie odpowiednich, bezpiecznych akcji. Np. ostrze enie w pewnej fazie

u ytkownika o mo liwo ci zaj cia bł du (asercje + zrozumiałe komunikaty o

niezgodno ci).

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 2, Slajd 24

marzec, 2004;

PB

Czynniki sukcesu, rezultaty testowania

Czynniki sukcesu:

Okre lenie fragmentów systemu o szczególnych wymaganiach wobec

niezawodno ci.

Wła ciwa motywacja osób zaanga owanych w testowanie. Np. stosowanie

nagród dla osób testuj cych za wykrycie szczególnie gro nych bł dów,

zaanga owanie osób posiadaj cych szczególny talent do wykrywania bł dów

Podstawowe rezultaty testowania:

Poprawiony kod, projekt, model i specyfikacja wymaga

Raport przebiegu testów, zawieraj cy informacj o przeprowadzonych testach i

ich rezultatach.

Oszacowanie niezawodno ci oprogramowania i kosztów konserwacji.