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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.27. Диаграмма развертывания

Заключение

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

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

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

Дипломная работа был выполнена с использованием case-средств BPWin 4.0 и IBM Rational Rose 2003.

ГЛОССАРИЙ

CASE(Computer-Aided Software/System Engineering) - средства автоматизации методологий структурного системного анализа и проектирования

СУБД - система управления базами данных

БД - база данных

ТфОП - телефонной сети общего пользования

SADT (Structured Analysis and Design Technique) - технология структурного анализа и проектирования и ее подмножество стандарт IDEF0

DFD (Data Flow Diagrams) - диаграммы потоков данных

ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь"

STD (State Transition Diagrams) - диаграммы переходов состояний.

ПО - программное обеспечение

БИБЛИОГРАФИЯ

1. Д.Н. Столбовский. Лекции по проектированию экономических информационных систем.

2. Леоненков. Самоучитель UML.

3. Е.Б. Золотухина, Р.В. Алфимов (c) Interface Ltd., 2001.

4. Доклад компании Yphise "UML-моделирование информационных систем и проектов" ("UML Modeling of Projects and Information Systems") /www.interface.ru/

5. Липаев В.В. "Качество программного обеспечения". -- М.: "Финансы и статистика", 1993.

6. Боэм Б.У. "Инженерное проектирование программного обеспечения". - М.: "Радио и связь", 1985.

7. "Технико-экономическое обоснование дипломных проектов" под редакцией проф. В.К. Беклешова. --М.: "Высшая школа", 1991.

8. Костров А.В. "Основы информационного менеджмента": Учебное пособие. - М.: Финансы и статистика, 2001.

9. Классификационный справочник должностей служащих. - М.: ИНФРА-М, 2001.