Разработка имитационной модели программного обеспечения информационной системы "Центр обслуживания абонентов" (стр. 6 из 7)

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

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

Рис.25. Модель интерфейса для заключения договора

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

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

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

2.8 Диаграмма компонентов

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

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

Рис.26. Диаграмма компонентов

2.9 Проектирование архитектуры приложения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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