Znaczenie organizacji przetwarzania i przepływu informacji

Rozpowszechniona struktura blokowa (modułowa) oprogramowania ujawnia swe zalety także w przypadku aplikacji przeznaczonych do interpretacji elektrokardiogramów. Architektura taka umożliwia wielokrotne wykorzystanie poszczególnych bloków, łatwą wymianę kolejnych wersji rozwojowych modułów oraz wysokopoziomowe komponowanie aplikacji z modułów (obiektów) w zależności od przeznaczenia. Jeżeli przed oprogramowaniem postawiony jest cel wykraczający poza detekcje ewolucji serca, to warto jego strukturę rozdzielić na dwa lub więcej modułów i poświęcić uwagę zaprojektowaniu optymalnej komunikacji pomiędzy nimi. Jest to problem krytyczny w przypadku ograniczonych zasobów sprzętowych (np. dostępnej pamięci zmiennych) lub przewidywania programu do pracy w czasie rzeczywistym.

Zagadnieniem wymagającym uwagi jest synchroniczna lub asynchroniczna współpraca procesu interpretacji ze strumieniami danych wejściowym i wyjściowym. Metoda asynchroniczna wymaga buforowania danych i zaprojektowania systemu powiadamiania o zajętości lub gotowości, ale pozwala na budowę aplikacji zorientowanej na usługi (SOA), a zastosowanie wspólnej struktury informacyjnej (zawierającej dane, konfiguracje, rezultaty i status) także na niezależną pracę kilku instancji (wywołań) w systemie wielowątkowym.

 

Najczęściej poruszane problemy

Podczas początkowej fazy projektowania oprogramowania należy rozwiązać następujące problemy projektowe:

czy oprogramowanie będzie miało architekturę modułową?

czy oprogramowanie będzie pracowało w czasie rzeczywistym?

czy moduły oprogramowania mogą być wymieniane podczas trwania interpretacji?

czy dopuszczalna jest zmiana konfiguracji oprogramowania podczas obliczeń?

w jaki sposób będzie monitorowane zaawansowanie procesu interpretacji i sygnalizowane wystąpienie błędów na poszczególnych etapach?

w jaki sposób obsłużyć interwencje operatora?

czy wyposażyć oprogramowanie we własność uczenia się?

Konieczne jest także zaprojektowanie głównych struktur danych na co najmniej trzy typy informacji:

serie czasowe (sygnały), najczęściej wieloodprowadzeniowe,

opisy (atrybuty) i wartości pomiarowe kolejnych ewolucji serca,

serie czasowe (próbkowane nieregularnie) związane z pomiarami wykonywanymi dla serii kolejnych ewolucji serca (np. odcinków ST, odstępów QT, interwałów RR itp.).

Projektowane struktury danych dobrze jest wyposażyć w funkcje (metody) właściwe do ich obsługi: zapisu, odczytu, wyszukiwania i porządkowania.

Niezależnie od wspólnych typów danych, każda procedura diagnostyczna generuje rezultaty w specyficzny dla niej sposób, który wymaga odrębnego obsłużenia. Niekiedy rezultaty diagnostyczne dostępne w formie liczbowej wymagają przetwarzania statystycznego, natomiast rezultaty wyświetlane w formie graficznej wymagają normalizacji względem rozdzielczości okna wykresu.

 

Metody realizacji zadania

Właściwie zaprojektowane oprogramowanie składa się z optymalnie dobranych struktur informacyjnych przechowujących dane oraz z wysokiej jakości procedur, których współpraca jest poprawnie zorganizowana. Projektowanie oprogramowania do analizy EKG najczęściej przebiega metodą dekompozycji zadań (zstępującą), w której zadania złożone dzielone są na prostsze. Częste jest także wykorzystywanie poszczególnych procedur (np. wyznaczania poziomu linii izoelektrycznej) w różnych blokach programu.

Ponieważ oprogramowanie zwykle ma strukturę blokową, poszczególne jego części mogą być projektowane przez pracujące równolegle zespoły programistów. Do tego celu przydatna jest jednak referencyjna baza zapisów i parametry pośrednie uzyskane z oprogramowania referencyjnego. Jeśli dwa zespoły projektują bloki funkcjonalne będące bezpośrednio po sobie następującymi ogniwami łańcucha interpretacji zapisu, zestaw parametrów pośrednich będzie dla jednego z nich referencyjnym zbiorem wyników, a dla drugiego zbiorem zapisów testowych.

Podczas projektowania organizacji pracy oprogramowania należy mieć na uwadze jego przeznaczenie, z którego może wynikać praca w czasie rzeczywistym oraz dostępne zasoby sprzętowe. Analiza propagacji błędów, oszacowanie strumienia danych pomiędzy procedurami i częstotliwości ich wywoływania są bardzo przydatnymi narzędziami optymalizacji wydajności aplikacji. Komunikacja pomiędzy modułami może być efektywnie rozwiązana za pomocą magistral danych przekazujących informacje o podobnych charakterystykach (np. częstości uaktualniania).

Ze względu na mnogość przypadków i patologii najwłaściwszym sposobem efektywnego zaprojektowania aplikacji interpretacyjnej jest zbudowanie jej, a następnie uruchomienie i wstępne przetestowanie dla ograniczonej liczby przypadków. Po uzyskaniu pozytywnych wyników można zwiększać liczność zbiorów testowych aż do osiągnięcia założonej dokładności, a równocześnie zwiększać ilość obsługiwanych patologii. Trudnym zadaniem jest utrzymanie jakości identyfikacji patologii podstawowych wraz z rozszerzeniem zakresu pracy systemu.

Dodatkowe informacje