1. Definicja oprogramowania komunikacyjnego

Transkrypt

1 1. Definicja oprogramowania komunikacyjnego 1.1. Zakres stosowania i definicja pojęcia oprogramowanie komunikacyjne Pojęcie oprogramowania komunikacyjnego nie jest jednoznacznie zdefiniowane. Na potrzeby tego wykładu będzie przyjęta następująca definicja: Oprogramowanie, które: realizuje komunikację między komputerami, wspomaga komunikację między ludźmi, zarządza obiema formami komunikacji. będzie nazywane oprogramowaniem komunikacyjnym Cechy i cykl powstawania oprogramowania komunikacyjnego Lektura rozdziału wymaga przypomnienia sobie podstawowych ideii dotyczących inżynierii oprogramowania 1. Cechy wspólne z innymi typami oprogramowania: pożądane niskie koszty wytwarzania. Cechy wspólne z innymi typami oprogramowania, ale o szczególnym znaczeniu dla orogramowania komunikacyjnego: otwartość na nowe usługi i rozwiązania (nazywana czasami ewolucyjnością). Konstrukcja oprogramowania powinna umożliwiać nadążanie za zmianami w technologii oraz w rozbudowie funkcjonalności oprogramowania. duża złożoność (praca w czasie rzeczywistym, praca współbieżna, często praca rozproszona) i wielkość oprogramowania. Praca w czasie rzeczywistym oznacza uzależnienie skutków działania oprogramowania od upływu czasu mierzonego stosunkowo krótkimi jednostkami czasu. Rezultat działania procesu jest uzależniony od upływu czasu, a nie tylko od danych. Często nie jest najważniejszym celem by oprogramowanie to było jak najszybsze, lecz by można było przewidzieć w jakim czasie będą mogły być otrzymane pożądane rezultaty. Jednostką czasu dla procesów w węzłach sieci komputerowych są pojedyncze mikrosekundy. W przypadku węzłów sieci telekomunikacyjnych (np. ISDN) są to milisekundy. Praca współbieżna oznacza, że z tego oprogramowania może korzystać wielu użytkowników jednocześnie i niezależnie. W węzłach sieci telekomunikacyjnych celem 1 Inżynieria oprogramowania, Red. J.Górski, MIKOM, Warszawa, 1999 Iok_1 2

2 jest obsłużenie jak największej liczby użytkowników i są to wielkości rzędu tysięcy procesów istniejących współbieżnie w jednym węźle. Szybkość działania oprogramowania jest tu wymaganiem dodatkowym i jest niezbędna tylko po to by było jak najwięcej jednocześnie obsługiwanych użytkowników. W węzłach sieci komputerowych liczba aktywnych procesów obsługi jest znacznie mniejsza (kilkadziesiąt), ale za to czas reakcji procesów na zdarzenia w sieci jest wielokrotnie krótszy. Praca rozproszona wynika z istoty funkcjonowania oprogramowania komunikacyjnego, które działa w odległych systemach połączonych kanałami wnoszącymi opóźnienia i błędy oraz z potrzeby efektywnego wykorzystania ich zasobów: np. przepustowości kanału, czasu procesorów, dostępnych pamięci itp. Wielkość oprogramowania jest związana z wielością realizowanych przez to oprogramowanie zadań. Oprócz tych elementów, które wynikają z już omówionych cech tego oprogramowania i powodują rozbudowę środowiska oprogramowania komunikacyjnego, pojawiają się elementy wynikające z zastosowania tego oprogramowania, a więc: różnorodne usługi i oprogramowanie sygnalizacji i protokołów komunikacyjnych oraz oprogramowanie wspomagające utrzymanie i eksploatację węzłów telekomunikacyjnych (nadzorowanie poprawności pracy, badanie statystyk ruchowych opisujących pracę węzła i sieci, wynikająca z nich rekonfiguracja węzła i sieci oraz taryfikacja). długi czas życia oprogramowania narzucający wysokie wymagania jakościowe na: oprogramowanie oraz jego dokumentację oraz powodujący zmienność zespołu programistów nawet u jednego producenta oprogramowania. Czas życia oprogramowania komunikacyjnego obliczany jest na okres rzędu 20 lat, bez względu na to czy jest to oprogramowanie dla sieci telekomunikacyjnych, czy też dla sieci komputerowych. Wynika to z natury sieci komunikacyjnych, w których elementem przesądzającym o czasie korzystania z określonych usług jest nie tyle jej nowoczesność co powszechność. Częsta wymiana wszystkich urządzeń końcowych jest zadaniem trudnym organizacyjnie, a zawsze kosztownym. Konstrukcja oprogramowania (modularna konstrukcja oprogramowania) musi gwarantować oprogramowanie zapewniające wysoką niezawodność systemu telekomunikacyjnego i łagodną degradację możliwości tego systemu w przypadku uszkodzeń jego elementów. Iok_1 3

3 Cecha, która nie jest istotne przy projektowaniu innych typów oprogramowania, ale jest zasadnicza przy projektowaniu oprogramowania komunikacyjnego różni wytwórcy oprogramowania, które musi ściśle i bezbłędnie ze sobą współpracować (dobrym przykładem są protokoły komunikacyjne). Liczbę styków oprogramowania pochodzącego od różnych producentów ilustruje kolejny rysunek. Terminal z oprogramowaniem producenta A Węzęł z oprogramowaniem producenta B Węzęł z oprogramowaniem producenta C Terminal z oprogramowaniem producenta D Rys. 1 Współpraca oprogramowania różnych producentów w sieci telekomunikacyjnej i teleinformatycznej Rozpatrując proces projektowania oprogramowania komunikacyjnego należy wziąć pod uwagę dwa punkty widzenia: punkt widzenia użytkownika oraz punkt widzenia projektanta oprogramowania. To spojrzenie wskazuje, że klient ma w kontekście projektowania oprogramowania komunikacyjnego mniejsze znaczenie. Punkt widzenia użytkownika związany jest z długim okresem eksploatacji systemu, w którym to okresie zmieniają się wymagania funkcjonalne i ruchowe na system. Punkt widzenia projektanta jest zdeterminowany wielkością i różnorodnością zadań, które ma to oprogramowanie realizować oraz niepełną znajomością przyszłych wymagań. Podstawowe cechy charakteryzujące oba punkty widzenia zawiera tabela 1. Tabela 1 Użytkownik Jakość funkcjonowania i utrzymania: łatwość użytkowania, modyfikowalność funkcji, modyfikowalność obciążenia, niezawodność funkcjonowania. Czas zrealizowania Projektant Jakość realizowania: łatwość oprogramowywania, łatwość uruchamiania i testowania, modyfikowalność oprogramowania. Czas zrealizowania Jak widać oczekiwania obu stron nie zawsze są sprzeczne. Wymaganie modyfikowalności oferowanych funkcji stoi co prawda w sprzeczności z łatwością realizacji oprogramowania, lecz nie stoi w sprzeczności z wymaganiem modyfikowalności oprogramowania. Podstawą spełnienia oczekiwań obu stron jest posiadanie: jednolitego sposobu: formułowania wymagań projektowania oprogramowania, implementacji oprogramowania, Iok_1 4

4 testowania oprogramowania i jego weryfikacji. modelu działania oraz metod analizy wykorzystanych algorytmów sterowania i komunikacji. Rysunek 2 ilustruje model cyklu wytwarzania dla oprogramowania komunikacyjnego. Nie różni się on zasadniczo od typowego cyklu kaskadowego z wyjątkiem pętli sprzężenia zwrotnego oraz dwóch elementów, które zostały podkreślone: stosowania nom i zaleceń oraz zarządzania oprogramowaniem. Przy omawianiu elementów modelu ich rola będzie bliżej wyjaśniona. MARKETING SERWIS SPRZEDAŻ PROJEKTOWANIE WYMAGANIA+ NORMY I ZALECENIA INSTRUKCJA SZKOLENIA, PROJEKT (ZACHOWANIE+ PROGRAMOWANIE ZARZADZANIE) OPROGRAMOWANIE PROJEKT TESTOWANIA TESTOWANIE WYNIKI TESTOW Produkt Rys. 2 Cykl powstawania oprogramowania komunikacyjnego Pierwszym elementem cyklu jest sformułowanie wymagań techniczno-ekonomicznych. Wymagania techniczno-ekonomiczne są opracowywane by: być merytoryczną podstawą do podejmowania decyzji: poprawiających rentowność produkcji, zmniejszenia liczby działań zbędnych, ryzykownych lub mało rentownych lub zapewniających korzystniejsze rozłożenie w czasie podejmowanych działań, stworzyć pośrednika pomiędzy projektowaniem oprogramowania i sprzętu, sprzedażą i marketingiem oraz serwisem, który to pośrednik byłby zrozumiały dla wszystkich stron, Iok_1 5

5 sprecyzować, uporządkować i zorganizować zadania dla zespołów projektowych, dokumentalistów (wykonanie instrukcji), serwisu i sprzedaży po podjęciu decyzji o rozpoczęciu procesu produkcyjnego, łatwiej uchwycić i wyegzekwować odpowiedzialność za efekty oraz ocenić odpowiedzialnych za nie. Wyymagania techniczno-ekonomicznych opracowuje się na podstawie: 1. funkcjonujących standardów opisujących protokoły i usługi komunikacyjne. dokumenty normalizacyjnych (ISO, IEEE, ITU itp), książeki i literatura oraz informacji o książkach i literaturze poświęconej protokołom i usługom, dokumentacje innych producentów, udziału (biernego i aktywnego) w pracach organizacji normalizacyjnych np. ATM Forum, 2. życzeń klientów analiza rynku usług komunikacyjnych, kreawanie potrzeb rynku bezpośrednie kontakty z klientami i dystrybutorami zbieranie uwag od własnego serwisu i laboratorium wykonującego testy 3. własnych propozycji i rozwiązań problemów nowych i nierozwiązanych lub nieopisanych 4. analizy produktów oferowanych przez innych producentów, czasopisma, pokazy, akcje promocyjne, funkcjonujące instalacje,7 porównanie specyfikacji technicznych produktów, dostęp do wybranych produktów. Zawartość wymagań to: charakterystyki techniczne i funkcjonalne proponowanych produktów oszacowania kosztów ich wdrożenia obejmujące cały cykl produkcyjny oszacowania kosztów eksploatacji usług u użytkownika Kryteria przyjęcia bądź odrzucenia wymagań: oszacowanie zapotrzebowania rynku na usługi o określonych kosztach eksploatacji koszty realizacji Ze względu na funkcjonowanie norm i zaleceń oraz specyfikę oprogramowania komunikacyjnego bardzo często klient nie dysponuje odpowiednimi kwalifikacjami do wykonania wymagań. W takim przypadku powinien zlecić ich wykonanie, a nie pominąć etap w cyklu wytwarzania oprogramowania (co w praktyce ma miejsce nadzwyczaj często). Pominięcie tego elementu cyklu jest najczęstszym źródłem przedłużenia cyklu i wzrostu kosztów. Stosunkowo często wymagania powstają jako suma (złożenie) funkcjonalności oferowanych przez innych producentów, bez wnikania w sposoby uzyskania tej funkcjonalności oraz możliwości ich realizacji. Prowadzi to do podobnych efektów jak brak wymagań. Iok_1 6

6 Kolejnym elementem cyklu wytwarzania oprogramowania komunikacyjnego jest projekt oprogramowania. Projekty są opracowywane by: zmniejszyć koszty realizacji zadań projektantów poprzez: zmniejszenie liczby błędów i wysokich kosztów ich usuwania w chwili, gdy ujawnią się one w gotowym wyrobie (patrz rozkład Pareto - poprawienie 20% błędów pochłania 80% czasu), zapewnienie właściwej struktury zatrudnienia polegającej na wydzieleniu przynajmniej dwóch grup pracowników inżynieryjnych: 1. nielicznej grupy doświadczonych, lecz kosztownych projektantów i 2. liczniejszej grupy tańszych programistów. urealnienie ocen kosztów wdrożenia projektu. efektywnie i bezpiecznie powiększyć zakresu możliwości funkcjonalnych wyrobów. zrównoleglić z procesem programowania działania innych grup np. opracowujących testy, dokumentację, sprzedaż lub szkolenia. Iok_1 7

7 1.3. Środowisko oprogramowania komunikacyjnego Środowisko oprogramowania komunikacyjnego to różne formy środowiska współbieżnego. Krótkie przypomnienie podstawowych pojęć związanych z funkcjonowaniem w tym środowisku można znaleźć do dodatku A. W dodatku B można znaleźć krótkie przypomnienie zasad komunikacji oprogramowania z otoczeniem systemu komputerowego. W dodatku tym są też krótko omówione techniki pomiaru czasu na potrzeby procesów komunikacyjnych. Zazwyczaj oprogramowanie komunikacyjne jest zbiorem asynchronicznych procesów statycznych wymieniających między sobą komunikaty. Obsługę przerwań z otoczenia też można potraktować jako proces statyczny aktywowany przerwaniami. W środowisku oprogramowania komunikacyjnego szczególną rolę odgrywa pomiar czasu. Każdy proces powinien mieć możliwość odmierzania przynajmniej jedengo przedziału czasu i jego upłynięcie powinno być traktowane jak pojawienie się komunikatu synchronizacyjnego. Dodatki C i D zawierają krótkie opisy przykładowych środowisk. W dodatku C przedstawiony jest prosty scheduler pozwalający zarządzać zdarzeniami wystarczający do realizacji nawet dość złożonego oprogramowania. W dodatku D przedstawiono język programowania CHILL przeznaczony do stosowania przy opracowywaniu oprogramowania komunikacyjnego. Iok_1 8