Беспроводная передача данных

Автор работы: Пользователь скрыл имя, 17 Мая 2012 в 18:08, дипломная работа

Краткое описание

Объектом исследования - является ЛВС, основанная на технологии Ethernet и ультразвуковой акустический тракт «ТРАК» фирмы “Votum”.
Цель работы - разработать программу на языке Delphi, для управления УЗ дефектоскопом с удаленного компьютера при помощи приложения «Клиент - Сервер».
В процессе работы проводились изучение работы ультразвукового акустического тракта «ТРАК».
В результате работы были расширены функциональные возможности УЗ дефектоскопа, в частности, разработано приложений типа «Клиент-Сервер», позволяющее удаленно управлять дефектоскопом и производить сбор данных через ЛВС

Содержание

Введение
Ультразвуковая дефектоскопия
1.1 Теневой метод ультразвуковой дефектоскопии
1.2 Эхо - импульсный метод ультразвуковой дефектоскопии
1.3 ''ТРАК'' Акустический модуль
Параллельный интерфейс: LPT-порт
2.1 Традиционный LPT-порт

Организации удаленного соединения.
3.1 Протоколы сети Интернет
3.2 Приложение Клиент-Сервер
Язык программирования - Delphi
4.1 Функциональные задачи при конструировании интерфейса
4.2 Компоненты среды программирования Delphi, использовынные для создания приложения «Клент-Сервер»
Заключение

Вложенные файлы: 1 файл

Перминов-диплом - исправления(Печать).doc

— 825.50 Кб (Скачать файл)

Итак, рассмотренные  выше модели имеют следующие недостатки. 

1. "Толстый"  клиент:

  • сложность администрирования;
  • усложняется обновление ПО, поскольку его замену нужно производить одновременно по всей системе;
  • усложняется распределение полномочий, так как разграничение доступа происходит не по действиям, а по таблицам;
  • перегружается сеть вследствие передачи по ней необработанных данных;
  • слабая защита данных, поскольку сложно правильно распределить полномочия.

2. "Толстый"  сервер:

  • усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки;
  • производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;
  • программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;
  • получившиеся таким образом программы полностью непереносимы на другие системы и платформы.

Для решения  перечисленных проблем используются многоуровневые (три и более уровней) архитектуры клиент-сервер. 
 
 
 

     3.2.3 Многоуровневые архитектуры клиент-сервер 

Такие архитектуры  более разумно распределяют модули обработки данных, которые в этом случае выполняются на одном или  нескольких отдельных серверах. Эти  программные модули выполняют функции  сервера для интерфейсов с пользователями и клиента - для серверов баз данных. Кроме того, различные серверы приложений могут взаимодействовать между собой для более точного разделения системы на функциональные блоки, выполняющие определенные роли. Например, можно выделить сервер управления персоналом, который будет выполнять все необходимые для управления персоналом функции. Связав с ним отдельную базу данных, можно скрыть от пользователей все детали реализации этого сервера, разрешив им обращаться только к его общедоступным функциям. Кроме того, такую систему очень просто адаптировать к Web, поскольку проще разработать html-формы для доступа пользователей к определенным функциям базы данных, чем ко всем данным.

В трехуровневой  архитектуре "тонкий" клиент не перегружен функциями обработки данных, а выполняет свою основную роль системы представления информации, поступающей с сервера приложений. Такой интерфейс можно реализовать с помощью стандартных средств Web-технологии - браузера, CGI и Java. Это уменьшает объем данных, передаваемых между клиентом и сервером приложений, что позволяет подключать клиентские компьютеры даже по медленным линиям типа телефонных каналов. Кроме того, клиентская часть может быть настолько простой, что в большинстве случаев ее реализуют с помощью универсального браузера. Но если менять ее все-таки придется, то эту процедуру можно осуществить быстро и безболезненно. Трехуровневая архитектура клиент-сервер позволяет более точно назначать полномочия пользователей, так как они получают права доступа не к самой базе данных, а к определенным функциям сервера приложений. Это повышает защищенность системы (по сравнению с обычно архитектурой) не только от умышленного нападения, но и от ошибочных действий персонала.

Для примера  рассмотрим систему, различные части которой работают на нескольких удаленных друг от друга серверах. Допустим, что от разработчика поступила новая версия системы, для установки которой в двухуровневой архитектуре необходимо одновременно поменять все системные модули. Если же этого не сделать, то взаимодействие старых клиентов с новыми серверами может привести к непредсказуемым последствиям, так как разработчики обычно не рассчитывают на такое использование системы. В трехуровневой архитектуре ситуация упрощается. Дело в том, что поменяв сервер приложений и сервер хранения данных (это легко сделать одновременно, так как оба они обычно находятся рядом), мы сразу меняем набор доступных сервисов. Таким образом, вероятность ошибки из-за несоответствия версий серверной и клиентской частей резко сокращается. Если в новой версии какой-либо сервис исчез, то элементы интерфейса, обслуживавшие его в старой системе, просто не будут работать. Если же изменился алгоритм работы сервиса, то он будет корректно работать даже со старым интерфейсом.

Многоуровневые клиент-серверные системы достаточно легко можно перевести на Web-технологию - для этого достаточно заменить клиентскую часть универсальным или специализированным браузером, а сервер приложений дополнить Web-сервером и небольшими программами вызова процедур сервера. Для разработки этих программ можно использовать как Common Gateway Interface (CGI), так и более современную технологию Java.

Следует отметить и тот факт, что в трехуровневой  системе по каналу связи между  сервером приложений и базой данных передается достаточно много информации. Однако это не замедляет вычислений, так как для связи указанных элементов можно использовать более скоростные линии. Это потребует минимальных затрат, поскольку оба сервера обычно находятся в одном помещении. Таким образом, увеличивается суммарная производительность системы - над одной задачей теперь работают два различных сервера, а связь между ними можно осуществлять по наиболее скоростным линиям с минимальными затратами средств. Правда, возникает проблема согласованности совместных вычислений, которую призваны решать менеджеры транзакций - новые элементы многоуровневых систем. 

     3.2.4 Модели взаимодействия клиент-сервер 

Компанией Gartner Group, специализирующейся в области  исследования информационных технологий, предложена следующая классификация двухзвенных моделей взаимодействия клиент-сервер (двухзвенными эти модели называются потому, что три компонента приложения различным образом распределяются между двумя узлами): 
 

Рисунок 5 Модели взаимодействий Клиент-Сервер 

     Исторически первой появилась модель распределенного  представления данных, которая реализовывалась  на универсальной ЭВМ с подключенными  к ней неинтеллектуальными терминалами. Управление данными и взаимодействие с пользователем при этом объединялись в одной программе, на терминал передавалась только "картинка", сформированная на центральном компьютере.

     Затем, с появлением персональных компьютеров (ПК) и локальных сетей, были реализованы  модели доступа к удаленной базе данных. Некоторое время базовой  для сетей ПК была архитектура файлового сервера. При этом один из компьютеров является файловым сервером, на клиентах выполняются приложения, в которых совмещены компонент представления и прикладной компонент (СУБД и прикладная программма). Протокол обмена при этом представляет набор низкоуровненых вызовов операций файловой системы. Такая архитектура, реализуемая, как правило, с помощью персональных СУБД, имеет очевидные недостатки - высокий сетевой трафик и отсутствие унифицированного доступа к ресурсам.

     С появлением первых специализированных серверов баз данных появилась возможность другой реализации модели доступа к удаленной базе данных. В этом случае ядро СУБД функционирует на сервере, протокол обмена обеспечивается с помощью языка SQL. Такой подход по сравнению с файловым сервером ведет к уменьшению загрузки сети и унификации интерфейса "клиент-сервер". Однако, сетевой трафик остается достаточно высоким, кроме того, по прежнему невозможно удовлетворительное администрирование приложений, поскольку в одной программе совмещаются различные функции.

   Позже была разработана концепция активного  сервера, который использовал механизм хранимых процедур. Это позволило  часть прикладного компонента перенести  на сервер (модель распределенного  приложения). Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, что и SQL-сервер. Преимущества такого подхода: возможно централизованное администрирование прикладных функций, значительно снижается сетевой трафик (т.к. передаются не SQL-запросы, а вызовы хранимых процедур). Недостаток - ограниченность средств разработки хранимых процедур по сравнению с языками общего назначения (C и Pascal). На практике сейчас обычно используются смешанный подход:

  • простейшие прикладные функции выполняются хранимыми процедурами на сервере
  • более сложные реализуются на клиенте непосредственно в прикладной программе

Сейчас ряд  поставщиков коммерческих СУБД объявило о планах реализации механизмов выполнения хранимых процедур с использованием языка Java. Это соответствует концепции "тонкого клиента", функцией которого остается только отображение данных (модель удаленного представления данных).

В последнее  время также наблюдается тенденция  ко все большему использованию модели распределенного приложения. Характерной чертой таких приложений является логическое разделение приложения на две и более частей, каждая из которых может выполняться на отдельном компьютере. Выделенные части приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее согласованном формате. В этом случае двухзвенная архитектура клиент-сервер становится трехзвенной, а к некоторых случаях, она может включать и больше звеньев. 

 
 
 

Рисунок 6  Трехуровневая модель взаимодействия 

     4 Язык программирования - Delphi 

     4.1 Функциональные задачи при конструировании интерфейса 

     При создании сложных АСУ велико значение разработки программного обеспечения, т.к. именно программные средства создают интеллект компьютера, решающий сложные научные задачи, управляющий сложнейшими технологическими процессами. В настоящее время при создании подобных систем значительно возрастает роль человеческого фактора, а, следовательно, эргономического обеспечения системы. Основной задачей эргономического обеспечения является оптимизация взаимодействия между человеком и машиной не только в период эксплуатации, но и при изготовлении, и при утилизации технических компонентов. При систематизации подхода проектирования интерфейса пользователя, можно привести некоторые основные функциональные задачи и принципы построения, которые должен решать современный язык программирования и с которыми с успехом справляется Delphi.

     Принцип минимального рабочего усилия, имеющий  два аспекта:

    -минимизация затрат ресурсов со стороны разработчика ПО, что достигается путем создания определенной методики и технологии создания, свойственной обычным производственным процессам;

    -минимизация затрат ресурсов со стороны пользователя; т.е. должен выполнять только ту работу, которая необходима и не может быть выполнена системой, не должно быть повторений уже сделанной работы. 
     
     
     
     

     4.1.1 Программно - технические средства: реализация и создание пользовательского интерфейса 

     MS - Windows предоставляет пользователям оболочку графического интерфейса (GUI), которая обеспечивает стандартную среду пользователя и программиста. (GUI) предлагает более сложное и дружелюбное окружение пользователя, чем командно-управляемый интерфейс DOS. Работа в Windows основана на интуитивно понятных принципах. Легко переключиться с задачи на задачу и осуществлять обмен информацией между ними. Однако разработчики приложений традиционно сталкиваются с трудностями программирования, поскольку организация среды Windows является чрезвычайно сложной.

     Delphi - язык и среда программирования, относящаяся к классу RAD- (Rapid Application Development - «Средство быстрой разработки приложений») средств CASE - технологии.

     Интерфейс Windows обеспечивает полное перенесение CASE-технологий в интегрированную  систему поддержки работ по созданию прикладной системы на всех фазах жизненного цикла работы и проектирования системы.

     Delphi обладает широким набором возможностей, начиная от проектировщика форм  и кончая поддержкой всех форматов  популярных баз данных. Среда  устраняет необходимость программировать такие компоненты Windows общего назначения, как метки, пиктограммы и даже диалоговые панели. Диалоговые панели (например, Choose File и Save File) являются примерами многократно используемых компонентов, встроенных непосредственно в Delphi, который позволяет приспособить эти компоненты к имеющийся задаче, чтобы они работали именно так, как требуется создаваемому приложению. Также здесь имеются предварительно определенные визуальные и невизуальные объекты, включая кнопки, объекты с данными, меню и уже построенные диалоговые панели. С помощью этих объектов можно, например, обеспечить ввод данных просто несколькими нажатиями кнопок мыши, не прибегая к программированию. Это наглядная реализация применений CASE-технологий в современном программировании приложений. Та часть, которая непосредственно связана с программированием интерфейса пользователя системой получила название визуальное программирование.

     Выгоды  от проектирования АРМ в среде Windows с помощью Delphi:

    -устраняется необходимость в повторном вводе данных;

    -обеспечивается согласованность проекта и его реализации;

    -увеличивается производительность разработки и переносимость программ.

Информация о работе Беспроводная передача данных