54
2.4. Физическая модель ИС (подробности)
ИС может быть представлена как автоматизированная вычислительная
система – АИС. Она содержит:
информацию как продукт системы управления;
информационную технологию;
средство обработки информации;
персонал реализует информационные процессы, используя
информационные технологии.
АИС способствует:
сокращению потока бумажных носителей;
снижению трудоемкости выполняемых работ;
повышению профессионального уровня персонала;
улучшению комфортности условий работы.
Автоматизированная информационная система реализуется через
создание автоматизированных рабочих мест (АРМ). Автоматизированное
рабочее место – конечная совокупность технических, программных и
математических средств, с помощью которых автоматизируется персональное
рабочее место. Это – технологическое понятие. АРМ – рабочее место
специалиста, оснащенное компьютерной системой с входящими в нее
информационными ресурсами для выполнения профессиональных функций.
Кроме компьютера и комплекса программ, АРМ может содержать обучающую
систему, средства настройки и эксплуатации АРМ.
АРМ руководителя, АРМ специалиста и АРМ технического работника
отличаются уровнем возможностей управления профессиональным процессом.
АРМ специалиста включает в себя:
базу данных с персональной и корпоративной информацией,-
возможность оперативного поиска информации;
средства оперативной связи с внешними источниками информации
55
возможность моделирования процессов с учетом имеющегося
опыта работы;
средства многофункциональности и гибкости системы.
Составляющие АРМ не подвержены жестко регламентированным
стандартам, их возможности могут варьировать в зависимости от
профессиональных задач специалиста.
В результате анализа моделей ИС, описанных ранее, было принято
архитектурное решение: ИС должна быть реализована как клиент-серверное
приложение в трехуровневой архитектуре. Этот факт зафиксирован в виде ряда
UMLдиаграмм, составляющих в совокупности физическую модель ИС.
Клиент-сервер. Термин "клиент-сервер" означает такую архитектуру
программного комплекса, в которой его функциональные части
взаимодействуют по схеме "запрос-ответ". Если рассмотреть две
взаимодействующие части этого комплекса, то одна из них (клиент) выполняет
активную функцию, т.е. инициирует запросы, а другая (сервер) пассивно на них
отвечает. По мере развития системы роли могут меняться, например,
некоторый программный блок будет одновременно выполнять функции сервера
по отношению к одному блоку и клиента по отношению к другому.
Обе части выполняются на разных по мощности компьютерах,
объединенных сетью.
При этом клиент посылает серверу запросы, а сервер их обслуживает
(Рисунок .).
56
Рисунок 6. Клиент-серверная архитектура ИС
Такая технология реализуется в профессиональных СУБД, имеющих
специальный язык структурированных запросов.
Трехуровневая архитектура. Термин "трехуровневая " означает, что, ИС
должна иметь минимум три основные функциональные части - модули
хранения данных, их обработки и интерфейса с пользователем. Каждая из этих
частей может быть реализована независимо от двух других. Например, не
изменяя программ, используемых для хранения и обработки данных, можно
изменить интерфейс с оператором таким образом, что одни и те же данные
будут отображаться в виде таблиц, графиков или гистограмм. Не меняя
программ представления данных и их хранения, можно изменить программы
обработки, например, изменив алгоритм полнотекстового поиска. И наконец, не
меняя программ представления и обработки данных, можно изменить
программное обеспечение для хранения данных, перейдя, например, на другую
файловую систему.
Для обоснования трехуровневой архитектуры ниже приведем
неформальное описание двухуровневой архитектуры и ее недостатки.
57
В классической архитектуре клиент-сервер приходится распределять три
основные части приложения по двум физическим модулям. Обычно ПО
хранения данных располагается на сервере (например, сервере базы данных),
интерфейс с пользователем - на стороне клиента, а вот обработку данных
приходится распределять между клиентской и серверной частями. В этом-то и
заключается основной недостаток двухуровневой архитектуры, из которого
следуют несколько неприятных особенностей, сильно усложняющих
разработку клиент-серверных систем.
При разбиении алгоритмов обработки данных необходимо
синхронизировать поведение обеих частей системы. Все разработчики должны
иметь полную информацию о последних изменениях, внесенных в систему, и
понимать эти изменения. Это создает большие сложности при разработке
клиент-серверных систем, их установке и сопровождении, поскольку
необходимо тратить значительные усилия на координацию действий разных
групп специалистов. В действиях разработчиков часто возникают
противоречия, а это тормозит развитие системы и вынуждает изменять уже
готовые и проверенные элементы.
Чтобы избежать несогласованности различных элементов архитектуры,
пытаются выполнять обработку данных на одной из двух физических частей -
либо на стороне клиента ("толстый" клиент), либо на сервере ("тонкий" клиент).
Каждый подход имеет свои недостатки. В первом случае неоправданно
перегружается сеть, поскольку по ней передаются необработанные, а значит,
избыточные данные. Кроме того, усложняется поддержка системы и ее
изменение, так как замена алгоритма вычислений или исправление ошибки
требует одновременной полной замены всех интерфейсных программ, а иначе
могут возникнуть ошибки или несогласованность данных. Если же вся
обработка информации выполняется на сервере (когда такое вообще возможно),
то возникает проблема описания встроенных процедур и их отладки. Дело в
том, что язык описания встроенных процедур обычно является декларативным
58
и, следовательно, в принципе не допускает пошаговой отладки. Кроме того,
систему с обработкой информации на сервере абсолютно невозможно
перенести на другую платформу, что является серьезным недостатком.
Большинство современных средств быстрой разработки приложений
(RAD), которые работают с различными базами данных, реализует первую
стратегию, т.е. "толстый" клиент обеспечивает интерфейс с сервером базы
данных через встроенный SQL. Такой вариант реализации системы с "толстым"
клиентом, кроме перечисленных выше недостатков, обычно обеспечивает
недопустимо низкий уровень безопасности. Например, приходится всем
пользователям давать права на запись в основную таблицу учетной системы.
Кроме того, данную систему почти невозможно перевести на Web-технологию,
так как для доступа к серверу базы данных используется специализированное
клиентское ПО.
Итак, рассмотренные выше 2-х уровневые модели имеют следующие
недостатки:
1. "Толстый" клиент:
сложность администрирования;
усложняется обновление ПО, поскольку его замену нужно
производить одновременно по всей системе;
усложняется распределение полномочий, так как разграничение
доступа происходит не по действиям, а по таблицам;
перегружается сеть вследствие передачи по ней необработанных
данных;
слабая защита данных, поскольку сложно правильно распределить
полномочия.
2. "Толстый" сервер:
усложняется реализация, так как языки типа PL/SQL не
приспособлены для разработки подобного ПО и нет хороших средств отладки;
59
производительность программ, написанных на языках типа
PL/SQL, значительно ниже, чем созданных на других языках, что имеет
важное значение для сложных систем;
программы, написанные на СУБД-языках, обычно работают
недостаточно надежно; ошибка в них может привести к выходу из строя всего
сервера баз данных;
получившиеся таким образом программы полностью
непереносимы на другие системы и платформы.
Для решения перечисленных проблем при построении описываемой ИС
была использована трехуровневую архитектуру клиент-сервер.
В трехуровневой архитектуре "тонкий" клиент не перегружен
функциями обработки данных, а выполняет свою основную роль системы
представления информации, поступающей с сервера приложений.
Трехуровневая архитектура клиент-сервер позволяет более точно назначать
полномочия операторов, так как они получают права доступа не к самой базе
данных, а к определенным функциям сервера приложений. Это повышает
защищенность системы (по сравнению с обычно архитектурой) не только от
умышленного нападения, но и от ошибочных действий персонала.
Различные части ВС работают на нескольких удаленных друг от друга
серверах. Допустим, что от разработчика поступила новая версия системы, для
установки которой в двухуровневой архитектуре необходимо одновременно
поменять все системные модули. Если же этого не сделать, то взаимодействие
старых клиентов с новыми серверами может привести к непредсказуемым
последствиям, так как разработчики обычно не рассчитывают на такое
использование системы.
В трехуровневой архитектуре (Рисунок ) ситуация упрощается.
Дело в том, что поменяв сервер приложений и сервер хранения данных
(это легко сделать одновременно, так как оба они обычно находятся рядом), мы
сразу меняем набор доступных сервисов. Таким образом, вероятность ошибки
60
из-за несоответствия версий серверной и клиентской частей резко сокращается.
Если в новой версии какой-либо сервис исчез, то элементы интерфейса,
обслуживавшие его в старой системе, просто не будут работать. Следует
отметить и тот факт, что в трехуровневой системе по каналу связи между
сервером приложений и базой данных передается достаточно много
информации. Однако это не замедляет вычислений, так как для связи
указанных элементов можно использовать более скоростные линии. Это
потребует минимальных затрат, поскольку оба сервера обычно находятся в
одном помещении. Таким образом, увеличивается суммарная
производительность системы - над одной задачей теперь работают два
различных сервера, а связь между ними можно осуществлять по наиболее
скоростным линиям с минимальными затратами средств.
Рисунок 7. Физическая модель ВС. UML диаграмма размещения (3-х
уровневая архитектура)
Модули, реализующие логику соответственно располагаются физически
на трех звеньях (уровнях) (Рисунок 8.).
61
Рисунок 8. Физическая модель ВС. UML диаграмма компонент
(3-х уровневая архитектура)
2.5. Физическая модель ИС “FotoDocStyle”
В результате анализа моделей ИС, описанных ранее, было принято
архитектурное решение: ИС должна быть реализована как клиент-серверное
приложение в трехуровневой архитектуре. Этот факт зафиксирован в виде ряда
UMLдиаграмм, составляющих в совокупности физическую модель
проектируемой ИС.
Диаграмма компонентов. Для создания конкретной физической системы
необходимо реализовать все элементы логического представления в
конкретные материальные сущности. Для описания таких реальных сущностей
предназначено физическое представление модели. Базовыми элементами
физического представления системы в нотации UML являются компоненты,
которые представляют собой физически существующие части системы,
которые обеспечивают реализацию классов и отношений, а также
функционального поведения моделируемой программной системы.
На рисунках (Рисунок , 10) показан состав компонентов (фрагменты
системы) в виде диаграммы компонентов.
62
Рисунок 9. Физическая модель. Диаграмма модулей. Компоненты
ИС
Рисунок 10. Физическая модель. Диаграмма размещений
63
Выводы. Итогом Главы 2 является построение (описание) объектной
модели прототипа ИС. Предполагаемая гипотеза для этой главы: Построенная
объектная модели ИС позволит:
сформулировать алгоритм решение задачи текущей ИС;
получить основу для формирования пакета документации и
инструкций для пользователей (заказчика);
моделировать предпроектное решение.