Разработка клиент-серверного приложения в трехуровневой архитектуре для предметной области автосервис

Размещено на http://www.allbest.ru/

Разработка клиент-серверного приложения в трехуровневой архитектуре для предметной области автосервис

Введение

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

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

Запросы:

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

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

– составить ведомость расхода деталей за указанный период времени, найти те детали, которые за этот период времени вообще не использовались;

– составить ведомость расхода деталей за указанный период времени для заданного мастера;

– найти мастера, который за введенный период времени выполнил ремонтов на наибольшую сумму денег.

Транзакции:

– внести сведения о новом ремонте;

- расширить перечень выполняемых ремонтных операций.

1. Классическая архитектура клиент-сервер

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

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

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

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

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

Большинство современных средств быстрой разработки приложений (RAD), которые работают с различными базами данных, реализует первую стратегию, т.е. «толстый» клиент обеспечивает интерфейс с сервером базы данных через встроенный SQL. Такой вариант реализации системы с «толстым» клиентом, кроме перечисленных выше недостатков, обычно обеспечивает недопустимо низкий уровень безопасности. Например, в банковских системах приходится всем операционистам давать права на запись в основную таблицу учетной системы.

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

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

§ сложность администрирования;

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

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

§ перегружается сеть вследствие передачи по ней необработанных данных;

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

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

§ усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки;

§ производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;

§ программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;

§ получившиеся таким образом программы полностью непереносимы на другие системы и платформы.

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

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

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

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

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

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

Менеджеры транзакций

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

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

· коммуникационный менеджер (Communication Manager) контролирует обмен сообщениями между компонентами информационной системы;

· менеджер авторизации (Authorisation Manager) обеспечивает аутентификацию пользователей и проверку их прав доступа;

· менеджер транзакций (Transaction Manager) управляет распределенными операциями;

· менеджер ведения журнальных записей (Log Manager) следит за восстановлением и откатом распределенных операций;

· менеджер блокировок (Lock Manager) обеспечивает правильный доступ к совместно используемым данным.

Обычно коммуникационный менеджер объединен с авторизационным, а менеджер транзакций работает совместно с менеджерами блокировок и системных записей. Причем такой менеджер редко входит в комплект поставки, поскольку его функции (ведение записей, распределение ресурсов и контроль операций), как правило, выполняет сама база данных (например, Microsoft SQL Server).

3. Проектное решение, реализующее модель реляционной базы данных

Модель представлена в виде диаграммы в нотации Erwin в графическом виде для логического (рис. 1) и физического (рис. 2) уровней представления модели.

Рисунок 1 - Логический уровень представления модели

Рисунок 2 - Физический уровень представления модели

4. Диаграмма функциональных зависимостей

Рисунок 3 - Диаграмма функциональных зависимостей

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

5. Спецификация на разработку интерфейса

Рисунок 4 - Form 1, tabpage1

На рис. 4 textBox1, textBox2 содержат результат выполнения запроса:

select top 1 dbo.orepasii.master_id, sum (dbo. Operations.cena) as sum_den

from dbo.orepasii inner join dbo. Operations on (dbo. Operations.operat_id = dbo.orepasii.operat_id)

where (data1_id >= '2001-02-01') and (data1_id<='2003-01-12')

group by dbo.orepasii.master_id order by 2 desc

textBox1 - содержит master_id мастера, который выполнил ремонтов на наибольшую сумму.

textBox2 - содержит сумму, которую заработал мастер.

Рисунок 5 - Form 1, tabpage2

На рис. 5

textBox1 - содержит входной параметр отвечающий за индекс мастера.

dataGridView1 - содержит результат выполнения запроса:

select dbo.orepasii.data1_id, dbo.orepasii.master_id, dbo. Operations.detail_id, dbo. Operations.kol_detail

from dbo.orepasii inner join dbo. Operations on (dbo.orepasii.operat_id = dbo. Operations.operat_id)

where (data1_id >= '2001-02-01 00:00:00.000') and (data1_id<='2003-01-12 00:00:00.000') and (@Mas=dbo.orepasii.master_id).

Рисунок 6 - Form 1 tabpage3

На рис. 6:

textBox1 - содержит входной параметр, отвечающий индексу мастера.

dataGridView1 - содержит результат выполнение запроса:

select dbo.orepasii.data1_id, dbo.orepasii.operat_id, dbo. Operations.naz_operation, dbo. Operations.cena

from dbo.orepasii inner join dbo. Operations on (dbo.orepasii.operat_id=dbo. Operations.operat_id)

where (data1_id >= '2002-01-01') and (data1_id <= '2002-01-31') and (@Master=dbo.orepasii.master_id) ORDER BY dbo. Operations.cena.



Рисунок 7 - Form 1 tabpage4

На рис. 7 textBox1, textBox2, textBox3 - выходные параметры, соответствуют запросу:

select naz_detail, ob_postavki, srok_postavki from dbo. Details.

Рисунок8 - Form 1 tabpage5

На рис. 8 - dataGridView1 содержит выходной параметр в виде сводной таблицы о расходе деталей:

select dbo. Details.naz_detail, dbo. Details.detail_id from dbo. Details inner join dbo. Operations on (dbo. Details.detail_id = dbo. Operations.detail_id) where exists (select dbo.orepasii.data1_id, dbo.orepasii.master_id, dbo. Operations.detail_id, dbo. Operations.kol_detail from dbo.orepasii right join dbo. Operations on (dbo.orepasii.operat_id = dbo. Operations.operat_id) and (dbo.orepasii.data1_id between '2006-01-01'and '2009-06-01')).

Рисунок 9 - Form 1 tabpage6

На рис. 9 выполняется транзакция по добавлению данных о начале нового ремонта.

comboBox1 - выходной параметр выдающий данные по запросу:

SELECT naz_operation FROM dbo. Operations

textBox1 - выходной параметр, автоматически принимающий значения соответствующее выбраному параметру в comboBox1:

SELECT operat_id FROM dbo. Operations WHERE naz_operation='» + comboBox1. Text + «'

textBox2 - входной параметр соответствующий индексу мастера, который будет заниматся ремонтом.

Рисунок 10 - Form 1 tabpage7

На рис. 10 выполняется транзакция по расширению списка выполняемых ремонтных операций.

textBox1 - входной параметр, содержащий название новой операции.

textBox2 - входной параметр, содержащий индекс этого ремонта.

textBox3 - входящий параметр, содержащий число отвечающее за количество дней проведения ремонта.

textBox4 - входящий параметр, содержащий стоимость ремонтной операции.

comboBox1 - выходной параметр, отвечающий запросу:

SELECT naz_detail FROM dbo. Details

textBox5 - выходной параметр, отвечающий запросу:

SELECT detail_id FROM dbo. Details WHERE naz_detail='» + comboBox1. Text + «'

textBox6 - входной параметр, задающий необходимое количество деталей для ремонта.

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

Рисунок 11 - диаграмма классов

7. Словесное описание процесса выполнения транзакций

В данной работе необходимо было выполнить две транзакции по добавлению сведений о новом виде ремонтной операции и о выполнении нового ремонта. В каждой транзакции участвует по одной таблице dbo.orepasii и dbo. Operations соответственно.

DML - команды выполняются в следующей последовательности: вначале выбираются данные из таблицы с помощью команды SELECT, затем происходит добавление записей с помощью команды INSERT, и последним действием происходит сохранение изменений в таблице с помощью команды UPDATE.

При загрузке формы необходимо выбрать нужную транзакцию 1-ую или 2-ю и последовательно заполнить на форме все требуемые поля. После чего нажать на кнопку «Добавить» в результате чего и происходит добавление соответствующей информации в базу данных, а именно в таблицу dbo.orepasii или dbo. Operations, в зависимости от номера выбранной транзакции.

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

8 специальная часть: «Анонимные делегаты»

Анонимные методы - это практическая языковая конструкция, которая дает возможность программистам создавать блоки кода, которые могут быть инкапсулированы в делегаты и выполняться позже. Они основываются на языковой концепции, называемой лямбда функцией, и подобны конструкциям, используемым в Lisp и Python.

Делегаты

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

Делегат - это тоже класс. Объявление класса делегата начинается ключевым словом delegate и выглядит следующим образом:

ОбъявлениеКлассаДелегата:= [СпецификаторДоступа]

Delegate

СпецификаторВозвращаемогоЗначения ИмяКлассаДелегата (СписокПараметров);

При этом СпецификаторВозвращаемогоЗначения:= ИмяТипа

ИмяКлассаДелегата:= Идентификатор

Делегат - это тип, который определяет подпись метода и его можно связать с любым методом с совместимой подписью. Метод можно запустить (или вызвать) с помощью делегата. Делегаты используются для передачи методов в качестве аргументов к другим методам. Обработчики событий - это ничто иное, как методы, вызываемые с помощью делегатов. Создание пользовательского метода и класса, например элемента управления Windows, может вызывать метод при возникновении определенного события.

Общие сведения о делегатах

Делегаты имеют следующие свойства:

· делегаты похожи на указатели функций в C++, но являются строго типизированными.

· делегаты допускают передачу методов в качестве параметров.

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

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

Пример использования анонимного делегата в данной программе:

button2. Click += delegate (Object sender, EventArgs e)

{

System. Windows. Forms. MessageBox. Show («delegate_button Clicked»);

};

При многократном нажатии на кнопку button2, вызывается делегат и в MessageBox выдается сообщение о повторном вызове запроса. Таким образом, чем больше производится нажатий на button2, тем больше сообщений получает пользователь.

9 Инструкция пользователя по работе с приложением

1) Запускаем приложение;

2) В Form2 необходимо записать нужные параметры для подключения;

3) Нажимаем на button1 «Connection»;

4) Запускается Form1;

5) В tabpage1 можно найти индекс мастера, который совершил ремонтных операций на наибольшую сумму (textBox1), и эту сумму (textBox2) при нажатии button1 выводится требуемый результат.

6) В tabpage2 можно узнать, какие детали использовал интересующий мастер, для этого в textBox вводится индекс мастера и при нажатии button2 в dataGridView 2 выводится какие детали и в каком количестве использовал мастер.

7) В tabpage3 можно узнать, перечень работ, которые выполнил интересующий мастер, для этого в textBox вводится индекс мастера и при нажатии button3 в dataGridView3 выводится когда, какой ремонт выполнял мастер и его стоимость.

8) В tabpage4 при нажатии button4 «Далее» происходит перебор существующих деталей с указанной объема и сроков поставки на них.

9) В tabpage5 при нажатии button5 «Получить» в dataGridView5 выводятся детали, которые использовались мастерами за указанный промежуток времени.

10) В tabpage6 «Транзакция_1» происходит создание заказа на новый ремонт и при нажатии button6 «Добавить» добавление новых параметров в базу данных.

11) В tabpage7 «Транзакция_2» происходит расширение перечня выполняемых ремонтных операций в мастерской и при нажатии button7 «Добавить» добавление новых параметров в базу данных.

сервер архитектура реляционный автосервис

Заключение

Трехуровневая архитектура позволяет еще больше сбалансировать нагрузку на разные узлы и сеть, а также способствует специализации инструментов для разработки приложений и устраняет недостатки двухуровневой модели клиент-сервер. Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистам узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейса, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может реализовываться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов. С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной. Продукты для трехуровневой архитектуры, так называемые мониторы транзакций, являются относительно новыми. В настоящее время появились новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети. Таким образом, многоуровневая архитектура распределенных приложений позволяет повысить эффективность работы корпоративной информационной системы и оптимизировать распределение ее программно-аппаратных ресурсов. Но пока на российском рынке по-прежнему доминирует архитектура клиент-сервер.

Размещено на Allbest.ru

...