СОФИЙСКИ УНИВЕРСИТЕТ

“Св. Климент Охридски”

Факултет по математика и информатика

Катедра “Информационни Технологии”

Специалност Био-медицинска информатика

ДИПЛОМНА РАБОТА

Реализация на програмна среда с отворен код за изпращане на SMS съобщения

от приложения за медицински цели

дипломант Златко Тодоров Костадинов

факултетен номер М21237

научен ръководител Антоний Попов

София

2004 г.

Увод

В наши дни работата с науката отбеляза решителна крачка напред по отношение на изчислителните технологии. Персоналните компютри са ежедневие както в бизнес-отношенията, така и в домашните забавления. След бурното развитие на Интернет технологиите, скоростната обмяна на информация е превърна от лукс е ежедневие. В последните няколко години сферата на информационните технологии се разгръща в посока на мобилните устройства. Техни удобства, а понякога и недостатъци, са малкият размер, безжичната комуникация и простотата на използване. Тези особенности водят след себе си някои характерни функции на подобни устройства. За разлика от настолните изчислителни устройства, които обикновенно служат за обработка на информацията, мобилните устройства се използват предимно за обмяна и изобразяване на данни, а не за сложни изчисления върху тях. Всеки притежател на такова устройство може по всяко време да получи актуалната информация, от която има нужда.

В настоящата работа ще се ориентираме към GSM-устройствата, като най-популярни в нашата страна и предоставящи удобни възможности за предаване на информация. Притежатели на такива устройства са не само хора от “елита” (депутати, бизнесмени, шоумени), но и хора от т.нар. “средна класа” - сервитьори, магазинери, учители. Практически всеки от тези хора може да бъде достигнат посредством мобилни съобщения в случай на нужда и при нужната отзивчивост от негова страна.

Последното свойство е много удобно за използване в медицинската практика. Поради своето естество, медицинските изследвания и различните лечения се нуждаят от точна и навременна комуникация между персонала и пациентите. Понякога тази комуникация се състои в подробни обяснения на диагнозата на пациента, понякога в описание на състоянието на пациента, понякога в обмяна на данни между лекари. Но в някои случаи има кратки съобщения, които трябва да бъдат доставени до получателя максимално бързо. Те могат да бъдат много важни (например съобщение за спешен случай или за непредвидено усложнение при някой пациент) или съвсем рутинни (подсещане за запазен час или уведомяване за резултати от изследвания).

Докато първият вид съобщения обикновено са изолирани случаи и изискват намесата на компетентни лица, вторите са тривиални и подлежат на автоматизирана обработка. Докато обикновеният пациент не получава голямо количество съобщения и може да си позволи лукса да ги обработва на ръка, медицинският персонал трябва да се грижи за обработката/създаването на множество съобщения, правопропорционално по големина на множеството на пациентите. Обикновенно данните за такива съобщения се съхраняват / изчисляват в софтуера, който обслужва съотвеното медицинско заведение. Затова е много удобно да се вгради възможност за автоматично изпращане на такива съобщения в самия софтуер с минимална намеса на потребителя.

Да разгледаме конкретен пример: В зъболекарски кабинет на пациентите се предоставя услуга предварително уведомяване за запазен час. Медицинската сестра в този кабинет се обажда по телефона на пациента един час преди неговото посещение, за да му напомни, че трябва да дойде на преглед или лечение. Това увеличава допълнтелно работата на сестрата в името на еднаполезна, но съвсем тривиална функциналност. В софтуера на кабинета са въведени данните за пациентите и техните посещения. Той може автоматично да изпраа съобщения до пациентите, стига да му осигурим подходяща технология за целта.

За цел на тази работа ще имаме разработването на такава технология, която да позволява изпращането на кратки съобщения до получател включен в GSM мрежа. Използването на технологията трябва да бъде максимално просто, за сметка на ограничената и функционалност. Разработчиците на медицински приложения ще имат възможност да използват нашата разработка в своя продукт с минимални усилия.

Тъй като разработваме приложението за български потребители и трябва да се съобразяваме с настоящите условия в нашата страна ще дефинираме накои рамки за системата:

Ще се ограничим до използване на SMS съобщения. Поддържането на псевдоинтелигентни разговори е интересна възможност, но не излиза извън рамките на текущата пролематика и би била ненужно усложняване на задачата.

Ще използваме прости текстови съобщения. Макар че много устройства поддържат мултимедийни съобщения и те биха били полезни в някои случаи, далеч не всички притежатели на мобилни телефони у нас имат възможност да получават такива. Освен това съществува проблем със стандартизацията на формата на съобщенията и с възможностите предлагани от различните доставчици. Така че поддръжката на мултимедия би довела по-скоро до независещи от нас проблеми с качеството на резулатата, отколкото до улесняване на потребителя и подобряване на качеството на системата.

Ще поддържаме възможно най-лесна смяна на методите за изпращане на съобщения. В момента у нас, а и по света няма разработен стандарт за изпращане на SMS през Интернет. Съществуват различни протоколи, обслужвани от различни доставчици на тази услуга, но те са твърде разнообразни за да бъдат стандартизирани или обобщени. В България доставчиците не предлагат конкретни решения в тази насока. Засега можем да приложим само временни подходи, за които не е сигурно, че ще работят след известно време. Затова нашето решение ще се съсредоточи не към огромна (и излишна в конкретния случай) функционалност, а върху гъвкавостта на имплементацията и поддръжката на различни подходи.

При избора на технология за разработка трябва да се съобразяваме с текущото състояние на софтуерните наличности у нас, които основно се състоят от пиратски копия на MSWindows OS със съответния пиратски софтуер вървящ с него, със софтуерния пазар, който е ориентиран към Windows приложенията и със бъдещето на софтуерната индустрия в глобален план, което ние виждаме в софтуера с отворен формат и евтините решения. При тези съображения .NET технологията изглежда естествен избор.

В изложението ще се придържаме към следния план:

Формална дефиниция на задачата

Избрани технологии за реализиране на решението. Обосновка на избора.

Описание на процеса на разработка и проблемите, с които сме се сблъскали и решенията, които сме приложили.

Описание на реално приложение на създадената библиотека. Подробни инструкции за използването и настройването на системата и принципите на работа с нея.

Анализ на крайния резултат от гледна точка на разработчика, подръжката и потребителя.

Тестване и описание на работата на системата.

В добавка към описаните подходи ще приложим поне основни части от изходният код на системата и данни от процеса на работата и.

Изложение

Дефиниция на задачата

Да се разработи система, която да позволява на разработчиците на софтуер да създадат приложения, които изпращат SMS съобщения използвайки Интернет. Системата ще бъде ориентирана към разработчиците на медицински софтуер и медицинският персонал, който е ангажиран в разработката.

Свойства на системата

Поддръжка на прости текстови съобщения. Съществуват различни SMS/MMS формати и предварително е ясно, че не можем да поддържаме всички налични, а и няма смисъл с огледа на целите, които си поставяме. Едно или няколко съобщения от 128 символа са достатъчни за да предадат информацията, към която сме се ориентирали.

Възможност за използване на различни подходи при изпращане на различните съобщения. Смяната на подхода в иделания случай трябва да става с минимални усилия и без нужда промяна на изходния код на приложението. В момента нито един от двата доставчика не предлага удобна услуга за автоматизирано изпращане на съобщения. Единственото стандартно средство, с което разполагаме е email2sms услугата на Мобилтел, но поради естеството си и презастраховането от страна на доставчика тази услуга не е особенно надеждна. В бъдеще се надяваме да се появят нови методи, които да предоставят възможност за по-сигурни и ефективни реализации. Освен това подходите/реализациите могат да варират в зависимост от доставчика.

Поддръжка на различни операционни системи (ОС). В България не всеки може и не всеки иска да си купи Windows. Макар че тази ОС е все още най-популярната у нас, логиката на свободния пазар ни насочва на мисълта, че все повече български софтуер би трябвало да се разработва за Linux. Така че ние трябва да създадем софуерна библиотека, която да се приема добре както на Windows, така и на Linux, а по възможност и на други ОС. Има множество възможности в това отношение – Java, различни графични среди с отворен код, .NET и други.

Отворен код и публикуване под GPL лиценз – отвореният код на програмата и нейното публикуване под GPL лиценз [10] правят продукта ни общодостъпен и подходящ за внедряване и доразработване. В света на свободния софтуер [9], към който ние сме се ориентирали, няма ограничения и забрани върху подобряванет на даден продукт. Тъй като сме далеч от мисълта, че бихме направили нещо съвършено, ще се погрижим да осигурим възможност на всеки ентусиаст да даде своя принос за усъвършенстването на нашият продукт. От друга страна това е проект с некомерсиална цел създаден в името на обществено полезното, и поради тази причина бихме искали разработените продукти на негова основа да останат общодостъпни [11,12].

Наличност чрез Интернет – не можем да наречем един софтуер публичен, ако той не е достъпен чрез Интернет или не предоставя поне някаква информация за себе си в Мрежата. Поради желанието да разработим проект с отворен код, освен представителна информация ще трябва да публикуваме и изходният код на проекта заедно със съпътстващите го документи.

Пример

Нека продължим нашият пример от уводната част. На всеки кръгъл час медицинската сестра в кабинета отваря приложението в което са записани посещенията за деня и набира номера на следващият пациент. По една нещастна случайност този пациент в момента води важни бизнес преговори с някакъв клиент. Затова благославя наум сестрата и изключва телефона. Но по друга, този път щастлива, случайност този пациент се оказва разработчика на софтуера с който работи зъболекарския кабинет. Преди посещението си той се замисля, че е прекалено разсеян, за да помоли сестрата да не му звъни преди преглед, но от друга страна би било много по-удобно да получава SMS съобщения, които да се запазват на телефона му и да няма нужда да го изключва заради незначителни позвънявания.

Затова той прави предложение да внедри в своя софтуер функционалност, която автоматично да изпраща SMS на клиента вместо телефонното обаждане от сестрата. Персонала на кабинета е доволен, защото ще му се спести едно досадно задължение. Пациентът също е доволен, защото му се удава случай да спечели пари като подобри качеството на продукта си. След това той намира в Интернет нашата система и я интегрира в продукта. От това, разбира се сме доволни и ние. Недоволни са само шефовете на Мобилтел, защото оборотът им пада и отново се оказва, че са назад с технологиите.

Технологии за реализация

Платформа

Като платформа за разработка избираме .NET [5] платформата на Microsoft и в частност езика C#. Причините са няколко. На първо място модерните средства, с които разполага тази технология и които биха ни позволили бърза и качествена разработка на библиотеката. На второ – силната и интеграция с WindowsOS, което предполага лесно внедряване в съществуващите приложения за медицински софтуер. На трето – присъщата непоносимост на Windows ориентираните разработчици към не-Microsoft технологии и продукти. Както виждаме двата последни фактора са чисто пазарни – те не влияят нито на качеството на решението, нито на бързината на разработването му. Но какво да се прави – така се прави бизнес в капиталистическата практика.

Освен това разполагаме с реализация на .NET за MacOS и Linux, удобни и свободни средства за разработка (SharpDevelop, MonoDevelop), имплементация на повечето библиотеки на MS за други ОС различни от Windows. Това превръща .NET в идеалната технология за нашите цели.

Съхранение и интернет достъп

Като всеки IT проект нашият също ще има място в Интернет, където може да бъде прочетена полезна информация за проекта и изтеглена актуалната му версия в компилиран или изходен код. Тук е мястото да изкажем специални благодарности на Васил Колев, Боян Кроснов и останалите от екипа на ludost.net за любезността, с която би предоставиха интернет база за проекта. Освен web-страница проекът ще има също и CVS repository, в което ще държим различните етапи на разработка.

Документация

Документацията на системата ще поддържаме в отворен формат – HTML[4], SXW[6]. Като инструмент при създаването и поддръжката на документацията ще използваме OpenOffice[6]. Актуална версия на този продукт в превод на български може да бъде изтеглена от http://d.linux-bg.org/. За дизайна и описанието на софтуерната част ще използваме ArgoUML[8]

Компилиране и процес на разработка

Microsoft предлагат удобна среда за разработка на софуер с .NET платформата – MS Visual Studio. Но понеже ние търсим истинска многоплатформеност и възможно по-малко обвързване с комерсиални приложения, ще се съсредоточим върху свободни инструменти с отворен код. Нашата библиотека трябва да разполага с автоматична процедура за компилиране от изходен код. За тази цел ще използваме инструмента make, който се използва в повечето приложения с отворен код.

За да опростим процедурата по компилиране на приложението ще използваме стандартни Unix програми (bash, cp, rm и др.). Те могат да се намерят бъдат инсталирани в пакет върху WindowsOS във вид на cygwin дистрибуция. По този начин ще си спестим поддръжката на различни скриптови системи. Трябва да отбележим, че евентуалния разработчик, който би решил да прекомпилира библиотеката не би трябвало да срещне затруднения в използването на горните инструменти.

Подход

Общ програмен интерфейс

За да позволим интегриране на нашата система във външни продукти ще създадем библиотека с методи, които ще могат да бъдат изпълнени програмно. Такава библиотека в WindowsOS се оформя като DLL файл. Библиотеката ще предоставя методи за създаване и инициализиране на обекти от определен вид. Такива обекти ще наричаме изпращачи.

Може да има различни изпращачи, но те ще имат общ интерфейс, който ще предоставя възможности за изпращане на съобщенията. Целта на нашата библиотека е да дефинира този интерфейс, методите за конфигуриране и работа с изпращачите. По този начин ако в даден момент потребителя реши, че трябва да приложи нов (евентуално по-добър) метод за изпращане на съобщенията, той ще трябва само да подмени текущия изпращач без да променя изходният код на продукта си. За тази цел нашата библиотека ще поддържа динамично конфигуриране чрез XML файлове.

Изпращачи

Изпращачите също ще представляват компилиран код, който ще стои в DLL файлове. Няколко изпращача могат да бъдат налични в един и същ момент, но библиотеката ще решава кой точно да използва за конкретното съобщение. Използването на нов изпращач ще става чрез добавяне на съответния DLL и промяна в конфигурационните файлове на библиотеката и евентуално изтриване на стари изпращачи.

Изпращачите представляват абстракция на различните методи за изпращане на съобщение. Например един изпращач може да използва интернет сървър предоставен от съответния GSM оператор и някакъв протокол към него, дори евентуално API (Application Programming Interface), предоставено от оператор. Друг изпращач може да използва някаква web-услуга за изпращане на съобщения, като играе ролята на web-клиент. Например такава услуга предоставя сайтът http://sms.mtel.net. Трети може да използва GSM устройство свързано към персоналния компютър през сериен порт или BlueTooth устройство. Но тъй като всички те ще имплементират един общ минимален интерфейс, съответно достатъчен за изискваната от нас функционалност, потребителят ще може да премине от един към друг без да има нужда да променя продукта си.

Конфигуриране

За да работи с библиотеката без да променя сорсове, потребителят ще се нуждае от способ за задаване на стойности на променливите параметри. Такива параметри са например наличните доставчици, приоритетът на подредба на доставчиците при избор на доставчик за конкретно съобщение, специфични параметри на самите доставчици и др. Например един доставчик използващ услуга email2sms може да има нужда от промяна на SMTP сървъра, домейна на сървъра и др.

Тези параметри и стойностите им ще описваме в конфигурационни файлове във XML формат. При стартиране на програмата и инициализиране на обектите в нашата библиотека те ще прочитат стойностите на параметрите си от тези файлове. .NET средата предоставя стандартен подход за конфигуриране на приложения ( в частност множество от класове System.Configuration), които ще използваме за да реализираме тази функционалност.

Разработка

Дефиниране на функционалността в рамките на избраната технология

За да дадем възможност за използване на библиотеката трябва да опишем функционалността и чрез методите на .NET технологията. Това правим като създаваме няколко интерфейса. Те ще описват основните обекти в нашата система.

IАddress – описва получателя на съобщението (по-конкретно неговият адрес). За сега ни интереува само една стойност за получателя и това е неговият телефонен номер.

ISMS – описва SMS съобщение в контекста на нашата библиотека. Фактически дефинира две стойности за всяко съобщение

string Text { get; } - съдържание на съобщението

IAddress Address { get; } - адрес на получателя

ISender – описва функционалността, която трябва да имплементира всеки изпращач в нашата система. Това включва методите

void init(string config) – инициализира състоянието на изпращача от посоченият текст. Интерпретацията на конфигурационния текст зависи изцяло от конкретният изпращач. Може да съдържа както указател към някакви ресурси, така и всички нужни данни за конфгуриране на изпращача.

void send(ISMS sms) – изпраща посоченото съобщение. Този метод представя основната функция на изпращачите. Подходът за изпращане, който реализира конкретният изпращач, както и настройките, посочени в init метода, се прилагат тук. Би трябвало различните изпращачи, с които е конфигурирана системата да се различават при работата с този метод. В противен случай обектите с еднаква работа в този метод би трябвало да се сведат до един и същ обект. Засега няма да задължаваме метода да връща резултат или да вдига изключение в случай на неуспех, защото в текущите подходи с които разполагаме (email2sms) няма начин да си осигурим знание дали съобщението е получено успешно. Все пак при проблем с изпращането методът може да вдигне изключение, което ще бъде прихващано на по-горно ниво.

bool accept(ISMS sms) – този метод се използва от библиотеката за да определи дали дадено съобщение може да бъде изпратено през конкретният доставчик.

Също така от всеки изпращач се изисква да дефинира общодостъпен конструктор за създаване на обект от конкретния клас, като този конструктор трябва да приема като единствен параметър текст, който служи за конфигуриране на обекта. Смисълът на това изискване е в динамичното създаване на обекти по време на зареждане на библиотеката само на базата на конфигурационни файлове.

SendSMS е клас, който ще служи за инициализиране на библиотеката и работа с нея. В идеалният случай потребителят на библиотеката (фактически разработчикът на медицинския софтуер) няма да се нуждае от познания по другите класове на програмата освен по този и по няколкото елементарни реализации на класовете за адрес и съобщение, които ще опишем малко по-долу. По този начин ще поддържаме работата с библиотеката максимално опростена. Класът SendSMS ще предоставя следните методи:

getInstance() - връща единственият обект от този клас, който би могъл да бъде създаден въобще. За това сме се погрижили, като сме направили конструкторите на класа достъпни само за този клас и сме инициализирали единствената в статичният конструктор (при първото обръщение към класа). Този клас реализира singleton design pattern, като носи всички особенности и предимства на тази конструкция.

send(ISMS sms) – изпраща посоченото съобщение през някой от заредените изпращачи. Изпращачите се подреждат по приоритети. Приоритетите се задават при конфигуриране на системата (на това ще обърнем внимание по-нататък). Проверката се извършва от изпращачите с по-нисък приоритет към тези с по-висок. Ако даден изпращач декларира, че може да изпрати посоченото съобщение (вж. bool accept(ISMS) метода), то се прави опит за изпращане през него (void send(ISMS sms)).

Ако изпращането е неуспешно (вдигнато е някакво изключение) или не е намерен изпращач, който да приеме съобщението, то методът вдига NotSendException, който трябва да бъде уловен от клиентската програма.

Библиотеката предоставя и прости реализации на класове за адрес и съобщение – Address и SMS. Тези класове съдържат само дефинираните атрибути като стойности в реализацията си. Логично е те да бъдат използвани при работа с програмата.

Възниква въпросът защо създадохме интерфейси, след като знаем предварително каква ще бъде реализацията им. За това има две взаимосвързани причини. Първо, на абстрактно ниво са необходими и достатъчни интерфейсите, за да дефинираме работата на програмата. По този начин не принуждаваме разработчиците да ползват конкретни класове и им даваме по-голяма свобода на творчество. От тяхна гледна точка може да е по-удобно или по-логично един обект (например IAddress) да връща различни стойности в зависимост от вътрешното си състояние, без да се налага той да се управлява отвън. Второ, понякога може да се наложи да използваме по-сложни реализации на посочените интерфейси. Например един получател може да има два телефона и в зависимост от системното време да решаваме на кой от двата да пратим съобщение. Накратко – стремим се да натоварваме потребителя с възможно най-малко работа, като му даваме възможно най-голяма свобода на действие.

Описание на използването на системата от клиентският код

Работата с така дефинираните обекти може да изглежда по следния начин. Създава се съобщението.

SMS sms = new SMS();

Поставят се съответните стойности в него.

sms.Text = text;

sms.Address = new Address(phone);

Взема се инстанция на изпращащия клас.

SendSMS.SendSMS instance = SendSMS.SendSMS.getInstance();

Изпраща се съобщението чрез него.

instance.send(sms);

Целият този код се проверява за вдигнато изключение и ако има такова, то се обработва (в нашият случай се показва на потребителя).

try {...}catch (NotSendException e){

Console.WriteLine(e.ToString());

Console.WriteLine(e.StackTrace);

}

Разбира се това е твърде опростен вариант, който трябва да демонстрира използването на библиотеката ни. В реално приложение тези парчета код трябва да са интегрирани с база от данни и потребителски интерфейс, както и със система за автоматизация на изпращанията.

Реализация на елементарен изпращач със “подръчни” средства

Разбира се нашето произведение е безполезно, докато не реализираме поне един единствен изпращач, който да може да изпраща съобщения на някакво множество (па било то само от един елемент) получатели. Този изпращач ще разпространяваме заедно със системата, за да бъде използван за демонстрация както за функционалността на системата, така и за разработката на нови изпращачи. До момента разполагаме с няколко подхода за постигане на тази цел.

Единият е да търсим някакъв вид комуникация през Интернет сървър, който да преведе нашето съобщение на езика на GSM мрежата и да го прати към съответният доставчик

Вторият е да включим свое устройство (например GSM апарат) в GSM мрежата и да комуникираме директно с него.

И двата начина имат своите недостатъци. Първият предполага сървър и протокол, които трябва да предоставят такава услуга. Вторият сътветното устройство и някакъв програмен интерфейс, с който да комуникираме с него. Освен това трябва да имаме впредвид времето за разработка, което би ни отнела избраната реализация, както и цената и. Вторият елемент особено натежава впредвид некомерсиалната цел на проекта.

По тази причина се спираме на първият начин. Ще потърсим сървър, с който да можем да комуникираме през Интернет и който да предоставя възможност за изпращане на SMS съобщения.

Влязохме в контакт с двата доставчика на GSM услуги в България (чуждите нямат отношение към нашия проект), като се опитахме да си набавим информация за подобни сървъри. За съжаление Globul декларират, че нямат намерение да предоставят в скоро време подобна услуга.

Въпреки отсъствието на каквото и да е внимание от страна на “българският GSM оператор” Mtel, се оказва, че само те предоставят подобна услуга на базата на email съобщения. Принципът на работа на тази услуга е следният. Клиентът посещава web-страницата на Mtel и декларира, че желае да използва услугата за да получава съобщения чрез електронна поща. В следствие на това той ще получава всички електронни съобщения изпратени на адрес <неговият-телефонен-номер>@sms.mtel.net. Не е ясно как би работила услугата ако се изпрати съобщение, което съдържа нещо различно от текст, например мултимедиен файл, но ние смятаме, че то няма да бъде правилно интерпретирано от системата. Така разработената услуга ни предоставя някои предимства, например факта, че няма нужда да имплементираме конкретен протокол или да осъществяваме ауторизация е много съществен от гледна точка на разработката. Друго предимство е, че пациентът винаги ще може да изключи получаването на съобщения чрез страницата на Mtel.

Друга услуга, която си заслужава да споменем и която би могла да бъде използвана за реализирането на изпращач е предоставена на базата на HTTP протокола. В основата си тя предоставя възможност на потребителите, които са се идентифицирали в страницата на Mtel да изпращат съобщения до избрани телефонни номера. За съжаление използването на тази услуга би се базирало на обработка на динамично във времето HTML съдържание и генериране на HTTP идентификационни заявки на основа на получената информация, което на практика означава да поддържаме протокол с не-добре дефинирана, но затова пък неизвестно кога променяща се спецификация. Освен това със тази услуга се злоупотребява и Mtel очевидно се страят да я направят възможно по-неудобна за автоматична обработка.

Като вземем впредвид споментатите по-горе особености избираме за реализация първият подход. За целта създаваме клас Email2SMSSender, който ще реализира функционалността изисквана от един изпращач или иначе казано ще имплементира дефинирания по-горе интерфейс. Всеки обект на този клас ще съдържа следните атрибути

string server = "mail.blue-edge.bg"; - SMTP сървъра, чрез който ще се праща съобщението

string from = "zlatko@blue-edge.bg"; - потребителският email, към от чието име ще се праща

string domain = "@sms.mtel.net"; - адреса на сървъра на Мобилтел

Regex phoneRegExp = new Regex("(\+359)|(0)88\d+"); - регулярен израз описващ валидни телефонни номера.със съответните стойности по подразбиране. Регулярният израз ще се използва от init() метода, докато останалите 3 атрибута ще се използват при изпращане на съобщението в email вид. Очевидно стойностите на тези параметри не може да бъдат фиксирани в изходният код на програмата. За това ще ги сложим в XML файл, пътя до който ще подаваме при конструиране на изпращач от този тип. Тук трябва да отбележим, че подобен конструктор е задължителен според конвенцията за изпращач предвидена в нашата библиотека.

Метод на конфигуриране

Конфигуриранете на нашата библиотека ще бъде от решаващо значение, тъй като ще се стараем с негова помощ да избегнем промени в изходния код на продуктите. Вече се ориентирахме към XML конфигурационни файлове, в които ще описваме променливите (в смисъла на подлежащи на доуточняване от страна на различните клиенти) параметри на библиотеката. .NET предоставя стандартизиран подход за конфигуриране на приложенията чрез XML файлове. Принципно той се състои в следното:

При стартиране на .NET приложение то търси в местата, описани в стойността PATH-на системата, файл, който е именуван <име-на-приложението>. Например, ако стартираме приложението си от App.exe и стойността на PATH атрибута е c:/temp то ще се опита да намери файл App.config в директорията c:/temp. Ако такъв файл е намерен, той се разглежда от средата като конфигурационен файл на приложението. Областта System.Configuration; съдържа класове и методи за достъп до стойностите в този файл. Ние ще използваме тези стойности за да инициализираме нашата библиотека.

За да направим конфигурацията на библиотеката максимално независима от конфигурацията на конкретното приложение, в последната ще посочваме друг XML файл, който ще се отнася за библиотеката. Библиотеката ще чете този файл и ще настройва собствените си параметри от него.

Засега параметрите на библиотеката ще описват само множеството от изпращачи, които ще се зареждат в началото. За всеки изпращач ще се задава име на клас, приоритет и конфигурационен текст. Приоритетите на изпращачите се използват за определяне на реда, в който трябва да бъде подавано съобщението за изпращане. Класът и конфигурационния текст се използват при създаване на самият обект-изпращач в .NET средата. При създаването се използва областта System.Reflection, чрез която се изпълнява конструктор на зададения клас, като за стойност на единствения параметър на този конструктор се подава конфигурационния текст. Този текст може да бъде интерпретиран по различен начин от различните изпращачи. Например нашият елементарен изпращач го разглежда като път до файл, съдържащ конфигурацията за конкретния обект.

И така процедурата за конфигуриране е следната:

Библиотеката извлича от конфигурацията на клиентското приложение пътя до файла, който ще съдържа конфигурацията на самата библиотека.

Тази конфигурация описва наредено множество от изпращачи. За всеки изпращач е даден клас и конфигурационен текст.

Всеки от описаните изпращачи се създава, като се извиква конструктора на посочения клас приемащ точно един текстов параметър и за стойност на този параметър се посочва конфигурационния текст.

В конструктора на изпращача се инизиализират параметрите на конкретния изпращач. В случая на нашия изпращач се чете указаният в конфигурационния текст XML файл.

Създаване на тестово приложение

За демонстрация и доказване на функционалността на системата се нуждаем от приложение, което да използва възможностите на разработената система. Не се нуждаем от главозамайващ потребителски интерфейс или огормни източници на данни, а само от елементарен интерфейс, който да дава възможност на потребителя за изпращане на съобщения. За целта ще разработим просто .NET приложение, което ще изпраща съобщения чрез нашата библиотека. Приложението ще е конзолно, тъй като за момента само реализацията на MS за Windows поддържа стандартната библиотека на MS System.Windows.Forms.

Интегриране на системата в реално работещ продукт

Дефиниция на задачата

Нашата библиотека е предназначена да бъде изполвана в напълно функционални решения за медицинската практика. Тук ще приложим пример за интегриране във вече готов продукт, тъй като системата ни е проектирана именно върху такъв случай. За да ни бъде полезен този пример не трябва да се концентрираме върху конкретния продукт, а върху някои негови особености, върху които ще базираме конкретната интеграция. Те са следните:

Работа с релационна база от данни през ODBC интерфейс. В тази база ще се съдържат данни за пациентите и за посещенията, които те трябва да извършат. На основата на тези данни ще бъдат изпращани SMS съобщения до пациентите.

Работа върху операционната система Windows. Това не е изискване, което се налага от нашата библиотека, напротив, но имайки впредвид наличният софтуер на българския пазар можем да си позволим да включими такова изискване, като по този начин си спестим тривиалният труд, наложен от поддръжката на различни операционни системи.

Работа с малка база от данни, където не се грижим за проблеми със скоростта и претоварването на системата. Имайки впредвид капацитетите на медицинските кабинети у нас и на възможностите на съвременния хардуер можем да си спестим грижата за недостиг на ресурси от рода на процесорно време, оперативна памет или дисково пространство. В една по-сериозна (в смисъл на по-обемна) система, подобни проблеми би трябвало да се предвидят и евентуално подходът на интеграция на нашата библиотека би бил по-различен.

Това, което интеграционният процес трябва да осигури на основата на горните параметри е опит за изпращане на съобщение до кой да е пациент в някакъв интервал от време, който се изчислява на основа на данните за този пациент. Съобщението ще се изпраща чрез нашата библиотека.

Резултата от горният процес не трябва да се показва на потребителя в реално време, поради автоматичният характер на работата, но трябва да бъде достъпен за обработка и анализ.

Описано на езика на действието процедурата ще изглежда така. Дадена процедура ще се активира на регулярен интервал от време, като тя ще намира пациентите, на които трябва да се изпрати съобщение и ще се опитва да изпрати такова. Резултатите от изпращането ще се записват в някаква база от данни – например текстов файл.

Възможни подходи

Имаме няколко възможни подхода към задачата. Този , който изглежда най-естествен от потребителска гледна точка е интегрирането на подобен код в клиентското приложение, което така или иначе обработва базата данни. Предимствата на този код ще бъдат, че той ще има директен достъп до връзките с базата данни използвани в приложението, до интерфейса към данните който приложението използва и до потребителският интерфейс, което би било особено приятно в някои случаи. Например ако клиентът не иска съобщенията да бъдат изпращани винаги, а само при потвърждение от потребителя, този подход би бил най-удобен. За съжаление той не е подходящ за целите на автоматичното изпращане, пооради инцидентния характер на работата си. Подобни приложения се стартират при нужда на потребителя и работата им се състои в обработка на заявки от страна на потребителя. Ако потребителя реши да спре приложението в момент, в който дадено съобщение би трябвало да се изпрати, то просто няма да бъде изпратено. От друга страна не можем да принуждаваме потребителите си а не излизат от приложението например от 8 сутринта до 6 вечерта.

Тези недостатъци биха могли да бъдат заобиколени без загуба на полезни качества, ако медицинското приложение има добре обособена обособена клиентска и сървърна част, като клиентската част служи за интерфейс към сървърската. Но такива решения в България все още не се предлагат, поне доколкото е известно на авторите на настоящия текст.

И така, забравяме за комуникацията с потребителя чрез клиентското приложение и за самото приложение за момента. Ще фокусираме усилията си към сървърно приложение, което да извършва посочената дейност.

Фактически системата, която сме описали по-горе разполага със сървърска част. Това е сървъра към релационната база данни. Обикновенно такива сървъри се стартират и спират заедно със стартирането и спирането на операционната система и следователно поне откъм време на работа са много удобни за нашата цел (едва ли бихме могли да си мечтаем за сървър, който да работи и без операционната система :-)). Но забележете, че в горните изисквания не влиза изискване за конкретната реализация на релационната база от данни. В същността си подобни сървъри са проектирани да предоставят интерфейс за управление и извличане на данни, а не за стартиране на процеси във времето. Затова, макар че повечето от тях предоставят тазкива възможности, те са силно специфични за различните системи и не можем да считаме такава реализация за универсална или полезна за демонстрация.

Реализация

Последният подход с който разполагаме е да стартираме отделен процес, който работи самостоятелно с базата. Този процес ще се регистрира като услуга на Windows и ще се стартира и спира заедно със системата. Връзката с базата ще се осъществява през ODBC. Приложението с което ще интегрираме библиотеката ще е gnumed. Това е приложение с отворен код, което идеално пасва на нашите цели и критериите описани по-горе.

... да се доправи ...

Публикуване и документиране на системата

Всичката работа дотук би била безполезна ако не дадем на системата публичност, като към това добавим и подходящ набор от документи ориентирани към потребителите на системата. Сферата към която сме се ориентирали, отвореният код, ни задължава да опишем подробно всички фази на работа със системата и да ги подготвим за евентуалните участници в тях. За съжаление проектите с отворен код се нуждаят от непрекъсната поддръжка на огромно количество документация, което води до остаряване и трудна синхронизация с процеса на разработка. “Без подходящата документация, проектите с отворен код остават със сериозен проблем” [13, 14]. Различните лицензи за документиране на такива проекти отразяват различните философии залегнали в различните лицензи на самият софтуер [15], но понеже в нашият слуай документацията е само приложение към изходният код и не се разглежда като ценност сама по себе си ще пропуснем момента с лицензирането на тази информация.

Документиране

Няма общоприет стандарт за документиране на проект с отворен код, но повечето проекти предоставят информация от един и същ тип. На тази основа ние ще се постараем да оформим някакви рамки, в които нашите документи трябва да се вместят. Трябва да поддържаме поне три такива документа. Тук ще опишем тяхната структура, като на някои места цитираме конкретната реализация:

Описание на системата ориентирано към потенциалните потребители и изобщо казано всеки, който иска да се запознае отблизо с нея. Това включва информация за:

Разработчиците на проекта – адрес за контакти, език за разработка и др.

Лиценза, под който е публикуван проекта. Тук разбира се се включва и самият лиценз, дори да е добре известен (като GPL например).

Функционалността на системата – нейните качества и ползи, евентуално сравнени с другите подобни такива:

Често задавани въпроси. Това е много полезна (и дори необходима) информация в случай, че искаме да спестим излишен труд както на питащия, така и на отговарящия. За съжаление сме в твърде ранна фаза на проекта за да създадем множество от такива въпроси.

Ресурси на системата – документация и помощна информация, методи за сваляне на изходният код и крайния продукт.

Документация на работата със системата. Този документ е ориентиран специално към крайните потребители и се съобразява с техните нужди и потенциални трудности. Тук трябва да се опише:

Най-подробно функционалността на системата. Дори най-незначителните възможности на продукта трябва да бъдат отразени заедно с начина за използването им. Влиянията на всякакви настройки, конфигурационни файлове и други ресурси върху работата на системата трябва да намерят място в този документ:

Първата версия включва само изпращане на прости текстове съобщения. Мултимедийни съобщения евентуално могат да се добавят по-късно. Изпращането може да се извършва по различни начини. Всеки начин на изпращане на съобщение се представя като отделен изпращач, който се използва от библиотеката. Създаден е елементарен изпращач използващ услугата email2sms на Мтел, включен в библиотеката. Друг подобен изпращач може да се създаде на базата на web услугата на сайта http://sms.mtel.net. Добра идея е също създаването на изпращач изполващ GSM телефон свързан с компютъра посредстом подходящо устройство - например USB порт или BlueTooth. Понеже очакваме пазара на IT технологиите и особенно в GSM сферата в близките няколко години у нас да е особенно динамичен, ние целим лесен начин за промяна на използваните услуги. Това се постига чрез рефактиране на конфигурационните файлове и промяна на множеството от налични библиотеки. За информация отностно конфигурирането на изпращачите виж Конфигурация.
В общия случай различните изпращачи могат да изпращат съобщения до различни множества от получатели. Затова един изпращач може да откаже да изпрати конкретно съобщение. Библиотеката обхожда всички конфигурирани изпращачи по ред на приоритета, като ако един някой изпращач приеме да изпрати съобщението, няма да бъдат правени повече опити. Също така изпращането може да пропадне, без изпращача да разбере. За това изпращача не дава гаранция, че съобщението е получено, а само, че е изпратено.
С библиотеката SendSMS се разпространява и демонстационен пакет TestSendSMS, който съдържа примерна програмка използваща нашата библиотека. Всички примери по-долу са взети от нея.

Процедурата за сдобиване с конкретната версия на системата.

Процедурата за инсталирането и:

...

Компилираният DLL файл се разполага в директорията за библиотеки на системата. За Линукс това са директориите описани в LD_LIBRARY_PATH променливата на средата, а за Windows - описаните в PATH променливата. В такава директория се разполагат също и библиотеките за различни изпращачи.
След това във .NET кода на вашата програма добавяте обръщение към метода send на класа SendSMS от областта SendSMS. На този метод се подават IAddress, който съдържа телефонен номер и ISMS, съдържащ текстовото съобщение. В случай, че съобщението не бъде изпратено по някаква причина методът ще вдигне NotSendException.

...

Евентуално процедурата по отстраняване, обновяване или преинсталирането и.

Информация за разработчиците. Тя трябва да включва поне:

Описание на дизайна на изходния код – евентуално UML class диаграми.

Дефиниране на изискванията към системата в термините на разработчика и обосновка на избора на конкретните технологии. Последното е твърде важно за да се работи според първоначално установените принципи и да се постигнат нужните резултати.

Метод за сдобиване с актуалният изходен код на продукта.

Списък с необходими или препоръчани инструменти за работа с този код.

Описание на процедурата по изграждане на крайния продукт:

Checkout the SendSMS module from the CVS repository.

Go to SendSMS dir and edit the makefile.conf file. You should set some proerties like compiler location, path to additional dll files, etc. All those properties should be defined and described in the file - you may need to change their values.

Type make in to build the distribution files. Thos files will be created in the DIST_DIR specified in the previous step.

Описание на изходният код – структура на файловата система, различните изграждащи скриптове и други:

Your files obtained should look like that (some may be skipped):

SendSMS

config - a directory containing the configuration files for the system

Email2SMSSender.xml - config file for the email2sms sender implementation

SendSMS.xml - config file for the SendSMS core

dist - a directory to contain the binary files produced by the make procedure

doc - a directory containing the docs for the system

UserManual.html - a user manual for the system

DeveloperManual.html - the current document

model - directory for the UML modelling projects

SendSMS.zargo - an Argo UML model of the system

src - a directory containing the sources for the system

csharp - a directory for the system source files

email2sms - a direcotry for the Email2SMS sender source files

Email2SMSSender.cs - the sources for Email2SMS sender

Interfaces.cs - the interfaces definition

SimpleImplementations.cs - the simple interfaces implementations

SendSMS.cs - the SendSMS core definition

makefile - a build file for the make tool

makefile.conf - containn some make configuration options

TestSendSMS - the project for testing send sms.

Описание на начина за присъедниняване към проекта.

Голяма част от тази информация вече е изложена в настоящия документ. Но той не може да бъде използван директно за тези цели, тъй като е ориентиран към по-специализиран вид аудитория. Освен това някои важни части не бяхме изложили тук, а други все още не сме. За това като допълнение ще приложим оригиналните документи.

Публикуване

За да постинем максимална достъпност и популярност ще публикуваме системата в Интернет заедно с документацията описана по-горе. Като методи за достъп ще използваме HTTP[3], CVS [2] (и евентуално FTP) протоколите. През HTTP ще са достъпни следните файлове:

Главна страница на проекта – съдържа кратко описание на проекта, списък с контакти и връзки към останалите файлове.

Документ за крайни потребителите

Документ за запознаване с проект

Документ за разработчици

Архив с крайният продукт и документацията за крайни потребители

Архив с крайният продукт, изходният код и пълната документация на проекта.

За да предоставим web достъп ще използваме сървъра на ludost.net.

CVS достъп

През cvs евентуалният разработчик ще има достъп до актуалният изходен код, върху който се работи в момента. Също така за действителните разработчици ще се осигурява възможност да синхронизират своята работа.

http://www.neuron.yale.edu/neuron/sshcvs.html

http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1

или направо да питам дейан дали знае как се прави.

Разбира се в идеалният случай цялата документация и другата публикувана информация би трябвало да бъде налична и на английски език, за да бъде нашата програма наистина общодостъпна в рамките на Интернет обществото. Понеже ние не разполагаме с наличните ресурси за поддръжка на паралелно съдържание на два езика ще се спрем на следният компромисен вариант:

Разбира се цялата информация изложена в настоящия документ ще бъде на български език.

Главната страница на проекта в web ще се поддържа на два езика, като английският вариант ще съдържа връзка само към документацията за разработчици и изходният код за сваляне.

Изходният код ще бъде разработван на английски език. Всеки разработчик, бил той българин, патагонец или извънземен би трябвало да е запознат с този език на някакво елементарно ниво.

Документацията за разработчици ще се подържа също само на английски език по същите съображения.

Документацията за крайните потребители ще бъде на български език. Както вече отбелязахме нашият продукт в качеството си на пазарен такъв ще се съобразява само и единствено с българския пазар. Поне за момента. Предполагаме, че ако някой чужденец се заинтересува от проекта, той или ще бъде запознат с термините и процедурите на създаването на програмен код или би бил готов да се обърне за помощ към компетентно лице, най-малкото към разработчиците на проекта.

Разбира се в една по-късна фаза цялата документация трябва да бъде преведена и на двата езика или поне да поддържа напълно единият език. Но засега ще си спестим този труд и ще се ограничим до текущите си нужди.

Sample Database Table Script

http://www.developer.com/net/csharp/article.php/10918_2173801_1

Приложения

емайла до доставчиците

UML диаграми

различните АПИ-та и провайдъри на подобни услуги в мрежата

да се даде връзка към описанието на услугата на мтел

малко скриишотове от работата с тази страница

MSDN и всякакви други помощи за ресурсите, които съм ползвал – това да отиде към използваната литература

Листинги на сорс файловете и конфигурационните файлове

...

Да се интегрират с текста.

Литература и външни връзки

Това го слагаме в друг файл да не заема място.

Златко Костадинов

2004-10-06T19:35:34

Zlatko Kostadinov