Сетевое взаимодействие

 

       12.1 Механизм управления обменом.

Компоненты Delphi для контроля передачи данных в трехзвенной архитектуре.

Ошибки обновления данных.

Компоненты сетевого взаимодействия и их протокола.

Методы тестирования сложных программных комплексов.

Проектирование тестовых наборов данных.

Защита лучших курсовых работ.

 

       12.2 Сетевое соединение.

В лекции Архитектуры рассматривали различные технологии, поддерживаемые собственными компонентами для сетевого соединения. Каждый компонент реализуется определенным сетевым протоколом. Большинство компонентов расположено на вкладке DataSnap.

Компонент	Протокол
TDCOMConnection	DCOM
TSocketConnection	Windows sockets (TCP/IP)
TWebConnection	HTTP
TSOAPConnection	SOAP (HTTP and XML)
TcorbaConnection	CORBA (IIOP)

 

 

       12.3 Взаимодействие компонентов.

Компонент сетевого соединения (TXXXConnection, коммуникационный) обеспечивает посредством интерфейса IAPPSERVER взаимодействие (обмен данными) двух основных компонентов трехзвенной архитектуры:

компонент провайдера (TDataSetProvider), расположенный в модуле сервера приложений, для каждого источника данных;

компонентом набора данных приложения клиента (TCientDataSet), позволяющий строить интерфейсную часть приложения.

 

 

       12.4 Механизм обмена.

Обмен данными в трехзвенной архитектуре предусматривает передачу пакетов информации между серверными компонентами TDataSetProvider и клиентскими наборами данных TClientDataSet

 

           

12.5 Свойства провайдера.

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

Определением свойств компонента провайдера производится управление информацией, передаваемой клиенту в пакете данных:

- указываются поля, передаваемые в наборе;

- устанавливаются флаги свойства Options, определяющие состав пакета;

- определяется дополнительная информация для включения в пакет данных.

Компонент провайдера получает клиентский запрос, формирует набор данных и отправляет его клиенту в пакете Data: OleVariant.

На стороне клиента производиться обработка данных, добавление, изменение или удаление, после чего вызывается метод ApplyUpdate.

Происходит формирование пакета изменений Delta, содержащего все вставленные и измененные записи набора данных.

Сервер приложений распаковывает пакет и вносит изменения в БД по одной записи.

 

 

       12.6 Преимущества.

Использование трехзвенной архитектуры предоставляет разработчику следующие дополнительные возможности:

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

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

- кэширования данных на стороне клиента;

- кэширования запросов пользователей на стороне сервера;

- организации брокера ограничений на стороне сервера;

- мониторинга работы пользователей.

 

       12.7 Вопрос.

Использование при проектировании информационной системы трехзвенной клиент – серверной архитектуры не обеспечивает:

1. Снижение требований к клиентским компьютерам.

2. Централизованный доступ к бизнес правилам.

3. Уменьшение сетевого трафика.

4. Контроль и регулирование сетевого обмена.

5. Дополнительный уровень кэширования данных.

 

       12.8 Тестирование ИС.

Тестирование всех компонентов информационной системы и их взаимодействия:

Сервер(ы).

Клиентские станции.

Телекоммуникационные средства.

Серверное ПО

                   Операционная система.

                   СУБД.

                   Система администрирования.

                   Система мониторинга.

Прикладное программное обеспечение (ERP - системы).

Разрабатываемое программное обеспечене.

 

       12.9 Способы тестирования ПО.

Логично - центричный (белый ящик), автоматический анализ программного кода. Стоимость 5 – 15 центов за строку, вероятность пропуска ошибки 10-40%.

Информационно – центричный (черный ящик), тест на реальных наборах данных с генерацией всех сообщений на модули кода. Стоимость 50 центов за строку, вероятность пропуска ошибки снижается до 5%.

 

 

 

       12.10 Проектирование процесса тестирования.

Проектирование процесса тестирования, как правило, следует за процессом функционального проектирования и проектирования схемы базы данных.

       Собственно тесты систем можно разделить на несколько категорий:

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

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

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

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

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

 

 

 

       12.11 Тесты устойчивости системы.

Тесты имитации отказов системы:

- отказ отдельного компонента информационной системы;

- отказ группы компонентов информационной системы;

- отказ основных модулей информационной системы;

- отказ операционной системы;

- «жесткий» сбой (отказ питания, жестких дисков).

Тесты наработки на отказ;

Тесты, имитирующие пиковую нагрузку.

В зависимости от сложности проекта тестирование и исправление ошибок могут занимать треть, половину и больше времени разработки всего проекта.

 

       12.12 Bug tracking.

Чем сложнее проект, тем больше будет потребность в автоматизации системы хранения ошибок - bug tracking, которая обеспечивает следующие функции:

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

- система уведомления о появлении новых ошибок, об изменении статуса известных в системе ошибок (как правило, это уведомления по электронной почте);

- отчеты об актуальных ошибках по компонентам системы, по интервалам времени, по группам разработчиков и разработчикам;

- информация об истории ошибки (в том числе отслеживание похожих ошибок, отслеживание повторного возникновения ошибки);

- правила доступа к ошибкам тех или иных категорий;

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

 

 

       12.13 Выводы.

Основная задача любого успешного проекта заключается в том, чтобы на момент запуска системы и в течение всего времени ее эксплуатации можно было обеспечить:

- требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;

- требуемую пропускную способность системы;

- требуемое время реакции системы на запрос;

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

- простоту эксплуатации и поддержки системы;

- необходимую безопасность.

 

       12.14 Тестирование серверной БД.

Тестирование прав доступа.

Проверка целостности данных.

Тестирование триггеров и хранимых процедур.

Тестирование системных функций СУБД (создание резервных копий, работа с требуемой кодировкой, репликация данных …).

 

 

       12.15 Тестирование клиентского ПО.

Проверка функциональности.

Взаимодействие с операционной системой.

Версия MS Office.

Анализ сообщений об ошибках в log – файлах.

Устойчивость к ошибкам пользователей.

Тестирование производительности.

 

       12.16 Внедрение и сопровождение ИС.

Опытная эксплуатация перекрывает процесс тестирования.

Ввод в эксплуатацию проходит, по крайней мере, три фазы:

- первоначальная загрузка информации;

- накопление информации;

- выход на проектную мощность.

 

Сопровождение:

- исправление обнаруженных ошибок;

- внесение незначительных изменений;

- администрирование системы;

- переход на новые версии ОС, СУБД, прикладного ПО;

- разработка новых версий программного обеспечения.

 

 

       12.17 Вопрос.

На каком этапе производится проектирование тестовых наборов данных?

1. Анализ.

2. Моделирование.

3. Синтез.

4. Тестирование и внедрение.

5. Сопровождение.

 

       12.18 Задание.

Разрабатывают клиентское приложение, реализующее функции пользователя по управлению метаданными и данными в БД SQL – сервера InterBase.

Выбор модели (тип приложения, меню, панели, формы, взаимодействие).

Выбирается набор визуальных компонентов.

Строится модель поиска и навигации по найденному НД с целью управления данными определенной записи.

Программируются необходимые обработчики событий.

Проверяется возможность манипулирования данными одновременно из двух приложений.

Провести анализ режимов видимости данных.

Составить шаблоны системы помощи (help).

 

       12.19 Вопросы по 6 лабораторной.

Какова роль презентационного уровня в архитектуре бизнес-приложения?

Каковы отличительные черты удачного пользовательского интерфейса?

Чем отличается дизайн с высокой и низкой детализацией?

Какие средства доступны разработчикам для организации помощи пользователям?

Типы моделей пользовательского приложения, и их применение.

Основные методы и события компонента отображения данных.

Какие существуют группы компонентов отображения данных?

Общие свойства компонентов отображения данных.

Основные свойства компонентов синхронного просмотра данных.

Табличное представление данных.

 

 

       12.20 Задания СРСП.

1. Тестирование и защита не менее четырех функций, реализуемых в приложении клиента;

2. Ответить на контрольные вопросы модуля;

3. Провести отладку программного кода приложения пользователя;

4. Защитить отчет по шестой лабораторной работе;

5. Защитить отчет по разделу 3.5 курсовой работы;

6. Разработать пример вопроса тестового задания по теме раздела;

7. Защита лучших курсовых работ;

8. Тест рубежного контроля.

 

       12.21 Задания СРС.

1. Изучить конспект 11,12 лекций;

2. Изучить методические указания к лабораторной работе шестого модуля;

3. Ответить на примеры тестовых заданий к шестому модулю;

4. Изучить код модулей, используемых в учебном примере Example;

5. Изучить использование компонентов TDBGrid, TDBEdit, TDBNavigator, TDBMemo, TDBListBox, TDBComboBox, TDBLookupComboBox.

6. Изучение механизма индексов, операторы: CREATE INDEX;

7. Оформление курсовой работы.

 

 

       12.22 Демонстрация.

Управление наборами данных.

Визуальный интерфейс, примеры.

Проектирование формы со связными полями выбора.

Проектирование тестовых наборов данных в IBExpert.

 

 

       12.23 Тренировочный тест, 10 вопросов.

 

Ответы

1	2	3	4	5	6	7	8	9	10