Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование и разработка информационных систем. Учебное пособие для СПО
.pdf
101
4. Модели отношений, отражающие взаимоотношения
между частями системы, например, поток данных между подсистемами.
3.3.1. Статическая (структурная) модель
В настоящее время существует большое количество хорошо зарекомендовавших себя моделей архитектур, так называемые базовые модели. Очень важно знать эти модели, их недостатки, преимущества и возможности применения.
Вместе с тем архитектуру больших систем невозможно
описать с помощью какой-либо одной модели. При разработке
отдельных частей больших систем можно строить модель архитектуры модели как комбинацию различных архитектурных моделей. Разработчик должен подобрать наиболее подходящую
модель, затем модифицировать ее соответственно требованиям
разрабатываемого ПО. Например, архитектура традиционного
компилятора базируется на комбинации модели репозитория и
модели потоков данных.
В качестве примера рассмотрим две базовые модели:
– модель репозитория;
– модель абстрактной машины.
Модель репозитория
Для того чтобы подсистемы, входящие в структуру системы, работали эффективнее, между ними должен идти обмен информацией. Обмен можно организовать двумя способами:
1. Все совместно используемые данные хранятся в цен-
тральной базе данных, доступной всем подсистемам. Модель
системы, основанная на совместном использовании базы данных, часто называют моделью репозитория (хранилища).
2. Каждая подсистема имеет собственную базу данных.
Взаимообмен данными между подсистемами происходит посредством передачи сообщений.
Большинство систем, обрабатывающих большие объемы
данных, организованы вокруг совместно используемой базы
данных, или репозитория. Такая модель подойдет к приложениям, в которых данные создаются в одной подсистеме, а используются в другой. Примерами могут служить системы управления
102
информацией, системы автоматического проектирования и
CASEсредства.
На рис. 3.13 представлен пример архитектуры интегрированного набора CASE-инструментов, основанный на совместно
используемом репозитории. Считается, что для CASE-средств
первый совместно используемый репозиторий был разработан в
начале 1970-х годов одной английской компанией. Широкую
известность эта модель получила после того, как была применена для поддержки разработки систем, написанных на языке Ada.
С тех пор многие CASE-средства разрабатываются с использованием общего репозитория.
Рис. 3.13 Модель репозитория
Совместно используемые репозитории имеют как преимущества, так и недостатки.
Очевидно, что совместное использование больших объемов данных, эффективно, поскольку не требуется передавать
данные из одной подсистемы в другие.
С другой стороны, подсистемы должны быть согласованы
с моделью репозитория данных. Это всегда приводит к необходимости компромисса между требованиями, предъявляемыми к
каждой подсистеме. Компромиссное решение может понизить
их производительность. Если форматы данных новых подсистем
не подходят под согласованную модель представления данных,
интегрировать такие подсистемы сложно или невозможно.
Подсистемам, в которых создаются данные, не нужно
знать, как эти данные используются в других подсистемах.
Поскольку в соответствии с согласованной моделью данных генерируются большие объемы информации, модернизация
таких систем проблематична. Перевод системы на новую модель
103
данных будет дорогостоящим и сложным, а порой даже невозможным.
В системах с репозиторием такие средства, как резервное
копирование, обеспечение безопасности, управление доступом и
восстановление данных, централизованы, поскольку входят в
систему управления репозиторием. Эти средства выполняют
только свои основные операции и не занимаются другими вопросами.
С другой стороны, к разным подсистемам предъявляются
разные требования, касающиеся безопасности, восстановления и
резервирования данных. В модели репозитория ко всем подсистемам применяется одинаковая политика.
Модель совместного использования репозитория прозрачна:
если новые подсистемы совместимы с согласованной моделью
данных, их можно непосредственно интегрировать в систему.
Однако сложно разместить репозитории на нескольких
машинах, поскольку могут возникнуть проблемы, связанные с
избыточностью и нарушением целостности данных.
В рассматриваемой модели репозиторий является пассивным элементом, а управление им возложено на подсистемы, использующие данные из репозитория. Для систем искусственного
интеллекта разработан альтернативный подход. Он основан на
модели «рабочей области», которая инициирует подсистемы тогда, когда конкретные данные становятся доступными. Такой
подход применим к системам, в которых форма данных хорошо
структурирована.
Модель абстрактной машины
Модель архитектуры абстрактной машины (иногда называемая многоуровневой моделью) моделирует взаимодействие
подсистем. Она организует систему в виде набора уровней, каждый из которых генерирует свои выходные данные.
Каждый уровень определяет абстрактную машину, выходные данные которой используются следующим уровнем абстрактной машины.
Многоуровневый подход обеспечивает пошаговое развитие систем — при разработке какого-либо уровня предоставляемые им сервисы становятся доступны пользовать. Кроме того,
такая архитектура легко изменяема и переносима на разные
104
платформы. Изменение интерфейса любого уровня повлияет
только на смежный уровень. Так как в многоуровневых системах
зависимости от машинной платформы локализованы на внутренних уровнях, такие системы можно реализовать на других
платформах, поскольку потребуется изменить только самые
внутренние уровни.
Недостатком модели абстрактной машины является довольно сложная структура системы.
Основные средства, такие, как управление файлами, необходимые всем уровням, предоставляются внутренними уровнями. Поэтому сервисам, запрашиваемым пользователем, возможно, потребуется доступ к внутренним уровням абстрактной машины. Такая ситуация приводит к разрушению модели, так как
внешний уровень зависит только от предшествующего ему
уровня, но и от более низких уровней.
Примером модели абстрактной машины служит классическая модель протоколов OSI (OpenSystemInterconnection) — это
эталонная модель сетевого взаимодействия подсистем в вычислительной системе. Она включает в себя 7 уровней (рис. 3.14).
Рис. 3.14. Семиуровневая модель OSI
105
Седьмой уровень определяет методы взаимодействия приложений, включая электронную почту.
Шестой уровень определяет методы описаний, форматирования, преобразования, кодирования.
Пятый уровень определяет методы взаимодействия процессов и обеспечивает поддержку сеанса работы в течение необходимого промежутка времени, выполняя при этом функции защитные, административные и по установлению связи.
Четвертый уровень определяет протоколы для структурированных сообщений и обеспечивает проверку правильности
передачи данных.
Третий уровень определяет протоколы маршрутизации в
сети.
Второй уровень обеспечивает целостность потока данных
от одного узла к другому путем синхронизации блока данных.
Первый уровень определяет механизм взаимодействия со
средой передачи данных и интерфейса аппаратного обеспечения.
3.3.2. Статическая модель распределенной
архитектуры
В настоящее время все разрабатываемые в коммерческих
целях ИС имеют распределенную архитектуру, которая подразумевает использование глобальных и (или) локальных сетей.
Исторически первыми получила широкое распространение
файл-серверная архитектура, поскольку ее логика проста, и перевести на такую архитектуру уже находящиеся в эксплуатации
ИС — проще всего. Затем она была трансформирована в архитектуру «сервер — клиент», которую можно трактовать как ее
логическое продолжение. Современные системы, используемые
в глобальной сети «Интернет», в основном относятся к архитектуре распределенных объектов (рис. 3.15).
106
Рис. 3.15. Архитектура распределенных систем
ИС можно представить как состоящую из следующих составных частей (рис. 3.16).
Рис. 3.16. Состав ИС с точки зрения распределения систем
Файл-серверные приложения
Это исторически первая распределенная архитектура. Организуется она предельно просто: на сервере находятся только
данные, а все остальное относится к клиентской машине
(рис. 3.17). Поскольку локальные сети достаточно дешевы, и в
силу того, что при такой архитектуре прикладное ПО автономно,
такая архитектура достаточно часто используется и сейчас.
Можно сказать, что это вариант клиент-серверной архитектуры,
при которой на сервере находятся только файлы данных. Разные
персональные компьютеры взаимодействуют только по средствам общего хранилища данных, поэтому программы, написанные в расчете на один компьютер проще всего адаптировать под
такую архитектуру.
107
Рис. 3.17. Схема файл-серверных приложений
Плюсы файл-серверной архитектуры:
– простота организации;
– не противоречит необходимым требованиям к БД к поддержанию целостности и надежности.
Минусы:
– перегрузка сети;
– непредсказуемость реакции на запрос.
Эти недостатки объясняются тем, что любой запрос к БД
приводит к перекачке по сети к значительным объемам информации. Например, для выборки из таблиц одной или нескольких
строк перекачивается вся таблица на клиентскую машину и уже
там СУБД производит выборку.
Значительный сетевой трафик особенно чреват при организации удаленного доступа к БД.
Клиент-серверные приложения
В данном случае имеется распределение обязанностей
между сервером и клиентом. В зависимости от того, как они
разделены, различают толстого и тонкого клиента (рис. 3.18 и
3.20 соответственно).
Рис. 3.18. Архитектура «толстый» клиент
К «толстому» клиенту относят все связанное с приложением, а к серверу относят все связанное с БД (рис. 3.19).
108
Рис. 3.19. Распределение функций в архитектуре «толстый» клиент
В модели «тонкий клиент» (рис. 3.20) вся работа приложения и управление данными выполняются на сервере. Пользовательский интерфейс в этих системах «переселяется» на персональный компьютер, а программное приложение выполняет
функции сервера, то есть выполняет все процессы приложения и
управляет данными. Модель тонкого клиента можно также реализовать там, где клиенты компьютеры или рабочие станции.
Сетевые устройства запускают интернет-браузер и пользовательский интерфейс, реализованный внутри системы.
Рис. 3.20. Архитектура «тонкий» клиент
Главный недостаток модели «тонкого» клиента —
большая загруженность сервера и сети. Все вычисления выполняются на сервере, а это может привести к значительному сетевому трафику между клиентом и сервером. В современных компьютерах достаточно вычислительной мощности, но она практически не используется в модели «тонкого» клиента.
109
Напротив, модель «толстого» клиента использует вычислительную мощность локальных машин: само приложение помещается на клиентский компьютер. Примером архитектуры
такого типа могут служить системы банкоматов, в которых банкомат является клиентом, а сервер — центральным компьютером, обслуживающим базу данных по расчетам с клиентами.
Двух- и трехуровневые клиент-серверные архитектуры
Все рассмотренные выше архитектуры являются двухуровневыми. В них различается уровень клиента и уровень сервера. Строго говоря, ИС состоит из трех логических уровней:
– уровня пользователя;
– уровня приложения;
– уровня данных.
Поэтому в двухуровневой модели, где задействованы
только два уровня, возникает проблема с масштабируемостью и
производительностью, если выбрана модель «тонкий клиент»,
либо проблемы, связанные с управлением системы, если взята
модель «толстый клиент». Избежать этих проблем можно, если
применять модель, состоящую из трех уровней, где два из них
занимают серверы (рис. 3.21).
Рис. 3.21. Схема трехуровневой архитектуры «сервер — клиент»
Фактически сервер приложения и сервер данных могут
располагаться на одной машине, но выполнять функции друг
друга они не могут. Применение разных типов архитектур для
разных приложений приведены в табл. 3.5.
110
Таблица 3.5
Применение разных типов архитектур
Архитектура
Приложение
Двухуровневая — «тонкий
клиент»
1. Наследуемые системы, в которых нецелесообразно
разделять выполнение приложения и управление
данными.
2. Приложения с интенсивными вычислениями, но
малыми объемами управления данными.
3. Приложения с большими объемами данных, но
малым количеством вычислений
Двухуровневая —
«толстый
клиент»
1. Приложения, где пользователю требуется интенсивная обработка данных, то есть визуализация данных.
2. Приложения с относительно постоянным набором
функций пользователя, применяемых к среде с хорошо отлаженным системным управлением
Трехуровневая —
«сервер —
клиент»
1. Большие приложения с сотнями и тысячами клиентов.
2. Приложения, в которых часто меняются и данные,
и методы их обработки.
3. Приложения, в которых выполняются интеграции
данных из многих источников
Трехуровневая модель хороша тем, что в ней логически
разделены выполнение приложения и управление данными. Такая модель подходит многим типам приложений, но ограничивает разработчиков ИС, которые должна решать, где предоставить
сервисы, обеспечивать поддержку масштабируемости, разрабатывать средства для подключения новых клиентов.
Архитектура распределенных объектов
Более общий подход обеспечивает архитектура распределенных объектов (рис. 3.22), основными компонентами которой
являются объекты. Они предоставляют набор услуг через свои
интерфейсы. Другие объекты посылают запросы, при этом не
делается различий между клиентом и сервером. Объекты могут
располагаться на разных компьютерах в сети и взаимодейство-
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]