1 . 7 \!a t ęp
Zgodnie z tradycją, mówiąc o narzędziach projektanta, mamy na myśli przede wszystkim deskę kre
ślarską, suwak logarytmiczny, przyrządy kreślarskie itp. Obecnie do zbioru tych narzędzi należy wlączyó także maszynę cyfrową wraz z jej bogatym wyposażeniom w urządzenia peryferyjne, szczegól
nie takie juk monitory ekranowo, plottory, digitizery, nie mówiąc Już o tale podstawowych, jak dru
karka, stacje taśm i dysków, czytniki kart czy taśm perforowanych, bez których maszyna cyfrowa jest prawio bezużytecznym narzędziom. Pojawienie się'togo nowego narzędzia, bardzo drogiego i skomplikowanego, stworzyło potrzebę badań nad metodami jego racjonalnego wykorzystywania. Jedną z bardziej przydatnych metod współpracy człowieka z maszyną cyfrową, szczególnie w procesie pro
jektowania, jest praca w trybie konworsacyjnym.
Należy więc przewidywać, że w najbliższych latach poważnie wzrośnie zapotrzebowanie na progra
my konworsacyjno. Przyczyni się do tego znaczny wzrost liczby sprzętu cyfrowego, umożliwiającego ekonomiozną realizację programów konworsacyjnych. Dotyczy to szczególnie wszelkiego rodzaju mini
komputerów, które szczególnie nadają się do tego typu pracy. Ponadto należy oczekiwać wzrostu li
czby średnich i dużych maszyn cyfrowych wyposażonych w systemy wielodostępne, umożliwiających re
alizację prac w trybie konworsacyjnym.
W niniejszym artykule omóyriono niektóre zagadnienia związane z projektowaniom programów lcon- wersacyjnych, mające wpływ na jakość tego programu.
Probiera projektowania dobrych programów konworsacyjnych jest zadaniem bardzo trudnym i złożo
nym. Projektanci programów, czy też systemów konworsacyJnych nruszą rozwiązać wielo problemów nie
znanych lub nio tak istotnych przy tworzeniu programów tradycyjnych.
Podstawowym problemem jest zapewnienie optymalnego średniego czasu reakcji. Jest to w progra
mach konworsacyjnych bardzo ważne zagadnienie, decydujące o powodzeniu całej pracy włożonej.w o- pracowywanio programu (punkt U.) .
Drugim podstawowym zagadnieniom, na które należy zwrócić szczególną uwagę przy pracy nad pro
gramami konworsacyjnymi jest odporność tych programów na błędy popełniane przez użytkownika. Jest to oczywiście ważno nie tylko w programach konworsacyjnych, lecz w tego typu programach jest szczególnie istotne (punkt 5 )«
2. Rola programów konworsacyjnych w komputeryzacji procesu projektowania
W klasycznej już metodzie przetwarzania danych maszyna realizuje ustalony program i podczas jego wykonywań i a w zasadzie nie ma miejsca na interwencję człowieka. Projektantowi pozostaje Je—
dynio zadanie dostarczenia danych i odbioru wyników (przetwarzanie wsadowe). Metoda ta, obecnie najczęściej stosowana, jest dobra i efektywna dla pewneJ klasy zadaró projektowyćh. Do klasy toj nałożą zadania o dobrzo znanym i jednoznacznie ustalonym procesie projektowania, dającym się łat
wo algorytmizować. ¥ ofekcie otrzymuje się rozwiązania typowe, nieoryginalne, a jedynie tylko czas ich otrzymania jest szybszy od realizacji sposobami' tradycyjnymi i dokładniej mogą byó poli
czono.
Metoda ta jost prawie całkowicie nieprzydatna dla tych procesów projektowania, których struk
tura nio jost dokładnie znana, a więc nie można ich także w pełni zalgorytmizowaó. Maszyna cyfro
wa wówczas może jedynio wspomagać proces,projektowania, Dła projektantów właśnie te nie w pełni
/
określono procesy są szozególnlo intorcsuJąco, ponieważ w wyniku działania tych właśnie procesów otrzymuje się konstrukcjo nietypowo - oryginalno.
V. onulizy przebiegu procesu projoktownnia wynika [*i], żo obliczenia w pełnym tego słowa znacze
niu zajmują niewielką część ogółu oporacji przetwarzania danych w tym procesie. Najwięcej wysił
ku przysparza poszukiwanie rozwiązali zbliżonych, co często ma miejsce w zadaniach optymalizacyj
nych, przeszukiwanie katalogów, poszukiwanie danych liczbowych, a następnie analiza i interpreta
cja zebranych danych. Sprawność procesu projektowego w dużej mierzo założy od sprawnego manipulo
wania dużą ilością danych oraz od łatwości dostępu do dowolnej informacji w dowolnej chwili. Do
tyczy to szczególnie wspomnianych procosów dla zadail nietypowych, nie w pełni zalgorytmizowonych.
U pracach tego typu, w tym w przetwarzaniu dużej ilości danych, maszyny cyfrowe są praktycz
nie niezbędno. Należy jednak zadbać o to, żeby praca projektanta z maszyną cyfrową była łatwa, e- fektywna i przyjemno.
Jak już było powiedziano, trudno, nie w pełni zalgorytmizowano procesy projektowe są nieciąg
łe. Oznacza.to, żo występują w nim fazy obliczeń, fazy przeszukiwania zbiorów danych oraz fazy podejmowania decyzji. Projektant na podstawie -wyników częściowych podejmuje decyzje o dalszym przebiegu procesu pi-o joktowonia. Uylcorzys tywanio maszyny w trybie wsadowym jest w takiej sytuacji prawie niemożliwo, ponieważ utrudnia to i opóźnia proces projektowania. Jedynym efektywnym sposo
bem współpracy człowieka z maszyną cyfrową jest wtedy praca w trybie lconwersacyjnym.
Jak już powiedziano koinputorowo wspomaganie procesu projektowania jest bardziej efektywne przy konworsacyjnoj pracy człowieka z maszyną cyfrową. Warto więc zastanowić się, jakio czynniki wpły
wają ną jakość programu konworsacyjnego, co docydujo o tym, żo joden program jest lepszy od dru
giego? W. 11. Turski w pracy [5 ] pisze, żo dobry program powinien być:
• poprawny, » odporny,
o przystosowalny, • stabilny.
Oczywisto jest, żo warunki to dotyczą także programów konworsacyjnych, lecz nie wyczerpują za
gadnień związanych z jakością tych programów. Dla oceny jakości programów eksploatowanych w try
bie konworsacyJnym należy uwzględnić bardzo istotny elemont działania takiego programu, a miano- ' wicio - człowieka.
Działający^program konworsacyjny tworzy para człowiek - maszyna (program). W programach eksplo
atowanych wsadowo użytkownik ma kontakt z programem dwa razy: na początku - przy przygotowywaniu danych i na końcu - przy interpretacji wyników. Przy pracy w trybie konwersacyjnym tale nie jest, użytkownik i program tworzą jodon "organizm" wzajemnie się uzupełniając i nic mogą pracować nie
zależnie od siebie. Program konwersacyjny ma współpracować z człowiekiem i projektanci tych pro
gramów nio mogą o tym zapominać.*
Wychodząc z togo podstawowogo założenia przy opraćowywaniu programów konwersacyjnych należy u- względniać możliwie najwięcej cech obu partnerów układu człowiek - maszyna. Człowiok w tym ukła
dzie szczególnie w procesie komputerowo wspomaganego projektowania spełnia rolę wiodącą i maszy
na nio może mu w pracy przeszkadzać, a odwrotnie, powinna go zmusić do intensywnej pracy bez szko
dy dla jej jakości. Może to nastąpić wyłącznie wtedy, gdy przy projektowaniu programu konworsa- cyjnego zostaną uwzględnione psycho-fizyczne możliwości człowieka.
Jak twiordzą psychologowie człowiek wylcorzystuje bardzo małą część potencjalnych możliwości swego mózgu. Poprawny program konwersacyjny może wydatnie zwiększyć sprawność działania człowie
ka, pod warunkiem, że będzie uwzględniał jogo możliwości.
Do najważniejszych czynników wpływającycli na jakość programu konworsacyjnogo, a wynikających z uwzględnionia eeeh psyclio-fizycznych człowieka należą:
• budowa dialogu,
• czas reakcji,
• odporność na błędy.
76
-Przystępując do projektowania dialogu człowieka z maszyną cyfrową należy na wstępie określić budowę togo dialogu. J. Martin 1 podajo 2 3 metody prowadzenia dialogu za pomocą alfanumerycz
nych monitorów ekranowych. Podział ton jest bardzo szczegółowy i jednocześnie sztuczny, a kryte
rium tego podziału jest konkretna technika realizacji dialogu. Z doświadczoii autora niniejszego artykułu wynika, żo nie warto tak szczegółowo dzielić motod prowndzonia dialogu. Projektant dia
logu z reguły ograniczony jest dość mocno sprzętem, którym dysponuje i zwykle wybiera wariant op
tymalny dla danego sprzętu. Przy czym mówiąc o sprzęcie ma się na myśli również oprogramowanie podstawowe. Celowo jest natomiast określanie typu projektowanego dialogu wyłącznie z punktu wi
dzenia użytkownika, a nie techniki realizacji. Biorąc za kryterium podziału aktywność użytkowni
ku podczas prowadzeniu dialogu, można wprowadzić dwa podstawowe typy dialogów:
o bierny użytkownik - użytkownik odpowiada na pytania stawiano przez maszynę,
• czynny użytkownik - maszyna wykonuje polecenia użytkownika.
Oczywiście w praktyco, szczególnie przy bardziej Skomplikowanych zadaniach, w jednym dialogu mogą wystąpić obydwa typy razem, będzie to wtedy dialog mioszony. 1/ dialogu takim, w jednej fa
zie stroną aktywną może być maszyna, a w drugim użytkownik.
Budowa projektowanego dialogu ma duży wpływ na jego jakość, a więc na ocenę programu przez u- żytkownika. Warto zatem zastanowić się co ma wpływ na to, że raz lepszy jest dialog bierny, a in
nym razom czynny. Można tu wskazać dwa główne czynniki decydujące o wyborze typu dialogu. Jednym z nich, najważniejszym jest rozwiązywany problem, a drugim przewidywane możliwości potencjalnego użytkowniku.
Z analizy przebiegu procesu rozwiązywania różnego rodzaju zadań za pomocą maszyn cyfrowych wy
niku, żc zadania te można podzielić na dwie podstawowe klasy.
Do pierwszoj klasy można zaliczyć te zadania, dla których proces ich rozwiązywania jest w peł
ni określony. Dla takich zadań wydaje się, że dobre są dialogi typu biernego. Jeżeli ponadto bę
dą to zadania, dla których kolejność wprowadzania danych oraz ich struktura są ściśle określono, to jodynie dialogi bierne będą efektywne. Dialog tego typu uwalnia użytkownika od kłopotliwego i niekiedy trudnego pamiętania o strulcturzo danych i kolejności ich wprowadzania, a więc pozwala na efektywną, szybką i bezbłędną pracę.
Użytkownik, odpowiadając na pytania zadawano przez maszynę wprowadza do programu dane oraz steruje przobiegiom procesu przetwarzania tych danych zwracając szczególną uwagę na to fragmenty, w których należy podejmować decyzje. Maszyna stawiając użytkownikowi poszczególne pytania, przed
stawia mu możliwie bogaty zestaw dotychczas uzyskanych wyników, na podstawie których może on pod
jąć decyzjo dotyczące dalszogo przebiegu procesu projektowania. Tale zorganizowany dialog nie wy
maga od użytkownika dużej inicjatywy, ponieważ nie ma on dużego wpływu na przebieg procesu proje
ktowaniu. Programy konwersacyjne o opisanej powyżej organizacji dialogu będzie wtedy mógł obsłu
żyć użytkownik o nioco mniejszych lcwalifikacJach.
Rozwiązując togo typu zadania konworsacyjnio, zyskujemy na czasie w stosunku do pracy wsado
wej, ponieważ unika się przestojów związanych z przerwami na analizę częściowych wyników i podej
mowanie decyzji.
Do drugiej klasy zadań należy zaliczyć te zadania, których proces rozwiązywania nie jest dok
ładnie znany, a więc nio dają się ono w polni algorytmizować. T/ydaje się, żo dla takach zadań lepszy jest dialog typu czynnego. Można wtedy zaprogramować te elementy przetwarzania danych,któ
rych struktura jest w pclni określona, a proces obliczeniowy ustalony. Użytkownik wykorzystuje maszynę do tych czynności, które może on l/ykonac dając jej polecenia w rodzaju. wykonaj ...",
"policz ..." itp., a maszyna po wykonaniu tych poleceń czeka na dalsze dyspozycje. Organizacja taka ma tę zalotę, żo przebieg procesu rozwiązywania zadania zależy tylko od użytkownika, maszy
na nic narzuca mu kolejności działania. Ponadto organizacja taka zapewnia łatwość rozbudowy sys
temu w miarę coraz lepszego poznawania i określania poszczególnych jego elementów.
78
-k . Cza3 rea-kcji
Drugim podstawowym problemom, jaki musi rozwiązać projektant dialogu człowieka z maszyną cyf
rową jost zupownienle optymalnego średniego czasu reakcji maszyny.
Rozróżnia się trzy poziomy, na których bada się czas reakcji systemu ( p. 6 ) : o poziom leksykalny,
o poziom syntaktyczny, e poziom semantyczny.
Poziom leksykalny jost interesujący dla producentów urządzeń końcowych oraz programistów sys
temowych i nio będziemy się nim zajmować. Poziom syntaktyczny głównie dotyczy programistów syste
mów, twórców systemów operacyjnych, natomiast programistów systemów użytkowych w niewiołkim stop
niu. Można jedyni© powiodzioć, żo maksymalnym czasom reakcji na tym poziomie jest czas ok. 1 s.
Programistów systemów użytkowych, tzn. systemów przeznaczonych do rozwiązywania konkretnych problemów obliczeniowych czy problemów przetwarzania danych typu informacyjnego, a więc obsługi wszolkiogo rodzaju banków danych itp. interesuje przede wszystkim poziom semantyczny. Poziom se
mantyczny dotyczy czasu reakcji maszyny na podstawowe dla danogo typu rozwiązywanego problemu, zadania stawiano maszynie.
Czas reakcji maszyny jost to czas, letóry upływa między naciśnięciom ostatniego klawisza przez użytkownika, a uzyskaniem pierwszego znaku odpowiedzi maszyny ( p. 1).
Wodług badań przeprowadzonych przoz psychologów amerykańskich wynika, że optymalny jest śred
ni czas roakcji od 1 do s. [2 ] . Czasy dłuższo niż sekundy są zwykle zbyt długie, nużą użyt
kownika. Mogą ono powodować zdenerwowanie użytkownika, co nie sprzyja efektywnej pracy. Czasy dłuższe niż 1 5 sekund wykluczają możliwość pracy konwersacyjnej. Stwierdzono także, żo z psycho
logicznego punktu widzenia zbyt krótkie czasy reakcji tależo są niekorzystne. Użytkownik nie nadą
ża za maszyną, co go niepokoi i zmusza do szybszej pracy, co jest źródłem dodatkowych błędów.
Średni czas reakcji maszyny ma bardzo duży wpływ na jakość pracy użytkownika. Prawidłowo dob
rany średni czas reakcji zapewnia połno wykorzystanie możliwości projektanta, a tym samym może decydować o efektach projektowania. Źlo dobrany średni czas reakcji a szczególnie- zbyt duży, znio- chęca użytkownika do pracy konwersacyjnej. Zbyteczne wydłużenie czasu roalccji rozprasza użytkow
nika powodując, żo zaczyna on interesować się innymi, nieistotnymi dla aktualnego procesu projek
towego sprawami. Na skutek tego projektant, gdy w końcu uzyska odpowiedź i musi podjąć decyzję, możo podjąć nie najlepszą lub co gorsze błędną decyzję niwecząc w ton sposób dotychczas wykonaną pracę.
Utrzymanie średniego czasu roakcji w optymalnych granicach nie jest sprawą prostą. Do podsta
wowych czynników mających wpływ na czas reakcji maszyny należą:
o rozwiązywany problem, « sprzęt, na którym program jest eksploatowany,
« organizacja programu, « otoczenie, w którym program jest eksploatowa
ny.
Projektant dialogu nio ma oczywiście wpływu na rozwiązywany problem. Może jodynie starać się o przedstawienie przebiegu procesu przetwarzania danych w postaci najlepszej dla konwersacji. Ma
my tu na myśli głownio rozbicie obliczeń na taicie fragmenty, któro pozwolą na utrzymanie średnie
go czasu roakcji maszyny w optymalnych granicach. Należy jednak brać tu pod uwagę wpływ szybkoś
ci działania maszyny, na któroj eksploatowany będzie dany program. Niezbędno jost tu doświadcze
nie programisty. W niektórych bardziej skomplikowanych sytuacjach celowe może być wykonanie nawet doświadczeń polegających na praktycznym określeniu czasu trwania obliczeń poszczególnych fragmen
tów programu.
Podział programu na elementy, dla których czas obliczeń mieści się w odpowiednich granicach z jednej strony, a stanowiące jednocześnie element dialogu odpowiadający jednej odpowiedzi nio jest proste. Odpowiednim narzędziem do takiej analizy możo być dynamiczny profil programu. Dynamiczny profil programu określa względny czas wykonywania jogo poszczególnych części [3]. Analizując
dy-namiczny profil programu można zorientować się, któro jogo fragmenty będą wykonywano wolno, a któ
re szybko. Projektując dialog należy próbować rozbijać to części programu, które będą wykonywane zbyt długo, oczywiście jeżoli jost to celowo z punktu widzenia budowy' dialogu.
Powstaje jodnak pytanie, co zrobić, gdy przewidywany czas reakcji jost zbyt długi, a danego fragmentu nie można w sposób sensowny rozbić na części-. Niektórzy z- autorów np. fi], zalecają wów
czas stosować tzw« odpowiedzi tymczasowe. Odpowiedź tymczasowa ma za zadanie zająć użytkownika i poinformować go, że wszystko przebiega normałnio i zaraz otrzyma odpowiedź właściwą, a takżo o to, by zatrzymać jego uwagę przy końcówce komputerowej, ponieważ każdo odwrócenie uwagi użytkow
nika od rozwiązywanego problemu działa na' niekorzyść rozwiązywanego zadania.
Należy jednak zdawać sobie sprawę z togo, żo odpowiedzi tymczasowe są jedynie złem koniecznym i można je stosować dopiero po wyczerpaniu innych możliwości, ponieważ nie zapewniają ciągłości myślenia użytkownika, a nawet mogą mu przeszkadzać, jeżeli są zbyt często stosowano.
Warto również wyraźnie podkreślić, żo nio każdy problem nadaje się do rozwiązywania w trybio lconwersacyjuym. Jodnym z czynników dooydujących o tym, czy dany problem nadaje się do rozwiązywa
nia w trybie lconwersacyjnym może być właśnie ozas reakcji. Jeżeli z analizy problemu wynika, że nio można utrzymać średniego czasu reakcji w optymalnych granicach, może to oznaczać, żc rozwią
zywany problem nio nadaje się do rozwiązywania w trybie lconwersacyjnym, a bardziej celowe jo3t przewidzioć eksploatację programu w trybie wsadowym.
Przy analizie rozwiązywanego problemu i projektowaniu dialogu nie można pominąć także maszyny, na której eksploatowany będzie dany program. Jeden i ten sam program eksploatowany na dwóch róż
nych maszynach może dawać bardzo dużo różnice w czasach reakcji. Wynika to z szybkości działania jednostki arytmetycznej, gdy program wykonuje dużo obliczeń matematycznych lub czasu dostępu do pamięci zewnętrznych przy częstych odwołaniach do niej, oo ma miejsce przy przetwarzaniu dużej i—
lości danych. Z togo względu bardzo owocne mogą być doświadcZonia z określeniom czasu wykonywa
nia typowych dla danego problemu oporaoji. Pozwala to uniknąć potem przykrych doświadczeń, gdy czasy reakcji są zło i należy przerabiać gotowy progrąm.
Nie można takżo przy projektowaniu programu lconwersacyjnego pomijać otoczenia, w którym pro
gram będzie eksploatowany. Programy lconwersacyjne z reguły eksploatowano są bądź w systemach wie
lodostępnych, szczególnie na maszynach o dużej i średniej mocy obliczondowoj. Otoczeniom progra
mu lconwersacyjnego nazywać będziemy wszystlcich innych użytkowników mających dostęp do jednostki centralnej lub urządzeń peryferyjnych maszyny, na której eksploatowany jost rozważany program i mających wpływ na czas odpowiedzi maszyny na zadany jej problem do rozwiązania.
Dla przykładu można podać, że w eksploatowanym w IMM systemie wielodostępnym TO-CMS czas reak
cji maszyny przy dziesięciu użytkownikach jest kilkakrotnie dłuzszy niż przy jednym lub dwóch u—
żytlcownikach. Istotno jost takżo, jakie problemy rozwiązują ci użytkownicy. Świadczy to o tym,że problem otoczenia i jego wpływu na czas reakcji jost istotny i nałoży go uwzględniać.
Inaczej kształtują się to problemy gdy program eksploatowany jest w systemie minikomputerowym.
Należy także podkreślić, żo problem wpływu maszyny i otoczenia, w którym eksploatowany ma być dany program jest bardzo ważny, szczególnie przy przenoszeniu programów konwersacyjnych z maszy
ny na maszynę. Nio zawszo i nie wszystkie programy lconwersacyjne będzie można przenieść na inną maszynę, mimo zgodności języków programowania.
5. Czułość na błędy popełniano przez użytkownika
Niezależnie od metody konwersacji użytkownika z maszyną cyfrową bardzo ważnym zagadnieniem jest odporność programu na błędy popełniano przez użytkownika podczas konwersacji. Nie istnieje idealny użytkownik, który nie popełnia błędów. Należy liczyć się z tym, żo użytkownik będzie po
pełniał błędy. Będą to błędy dwojukiego rodzaju: pojawiające się podczas wykonywania programu i powstające przy wprowadzaniu danych (różnego typu pomyłki). Błędy powstające przy wykonywaniu Programu niejednokrotnie użytkownikowi jest bardzo trudno zlokalizować. Należy więc tale
zaplano 8 0 zaplano
-w/ać program aby mógł przokazać w tody wiżytkownilcovi możliwie najbogatszą informację o rodzaju błę
du i miejscu jogo wystąpienia, bardzo istotno jost zapewuionio możliwości wczosnogo wylcrynfania wystąpienia różnego typu błędów. Nałoży unikać sytuacji, po których program przerywa działanie (pada). Pojawiają się wtedy komunikaty od systemu operacyjnego, których przeciętny użytkownik nie jost w stanie w polni wykorzystać.
Najczęstszym źródłem błędów będą błędy powstałe przy wprowadzaniu danych. Należy przyjąć zasa
dę, żo wprowadzenie każdej informacji do maszyny musi być sprawdzone z punktu widzenia poprawnoś
ci. Jednym z podstawowych celów/ projektantów dialogów powinno byó zminimalizowanie prawdopodobień
stwa wystąpienia błędww, po którym program'kończy działanio.
Jako przykład przeds taw/imy rozwiązanie zagadnienia bozpiocznogo w/prow/adzania danych dla progra
mów/ pisanych w/ języku FORTRAN. Standnrdow/o metody w/prow/adzonia danych w/ FORTRAN-io są w/rażliw/o na błędy popełniane przez uż'ytkownika. Wystąpienie błędu w/ danych z reguły pow/odujo przorw/anie*
w/ykonyw/anego programu z odpow/iednlm komunikatem. Użytkow/nilc mwwsi w/tody znaleźć błąd w/ danych, po
praw/i ć go i rozpocząć w/ykonyw/nnio programu od początkww. Przy dialogu człow/ieka z maszyną cyfrow/ą za pomocą szybkiogo urządzenia alfanumerycznego nic''można do togo dopuścić. Dano należy czytać tak, żeby praw/dopodobieństw/o przerwania w/ykónyw/ania programu, na skutek błędu w/ dany cli, było pra
ktycznie rów/no zeru. Można to zrobić w/ ton sposób, żo w/czytuje się całe rekordy formatom A, a na
stępnie je analizuje. Autor opracow/ał taki program, w/ letórym można w/prow/adzać dane Xiczbow/e. Pro
gramom tym można wprow/adzió do 5° liczb dow/olnogo typu. Formatem SOA! w/czytuje się cały rolcord na tablicę o długości 80, a następnie znak po znaku analizuje się w/prow/adzone dane. Poniow/aż do w/prow/adzania liczb nie potrzoba całego alfabetu języka FORTRAN w/ybrano 15-ełementow/y jogo pod
zbiór. Do zbioru togo nałoży 10 cyfr oraz 5 znaków/ specjalnych, którymi są: + - . , .
zbiór. Do zbioru togo nałoży 10 cyfr oraz 5 znaków/ specjalnych, którymi są: + - . , .