Файл: Проектирование архитектуры информационной системы. Эволюция архитектур ис.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 27.04.2024
Просмотров: 14
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Проектирование архитектуры информационной системы.
Эволюция архитектур ИС.
Архитектурное проектирование является начальным этапом процесса проектирования, когда определяются основные подсистемы, процессы и структура управления и взаимодействия. Его результатом должно стать формирование структуры программного обеспечения.
Архитектурный вид состоит из двух основных компонентов: структурных элементов и отношений между ними. При этом схематически архитектура может быть представлена в логическом или физическом виде.
На рис. 1 приведен пример логической структурной схемы программной архитектуры на примере системы архива электронных документов.
Рисунок 1 – Логическая архитектура программной системы
Основными архитектурными компонентами любой системы являются программное и аппаратное обеспечение. При разработке информационной системы необходимо вначале определить основные программные компоненты, а затем распределить их по различным аппаратным компонентам, на которых будет работать система. Каждый из этих компонентов может быть объединен различными способами.
Все составляющие информационных систем можно разделить на четыре функциональных компонента. Первый - это компонент хранения данных. Большинство информационных систем требуют хранения и извлечения данных, будь то файл, из которого считываются параметры для вывода данных, или большая база данных, в которой хранятся, например, записи о кадровых ресурсах организации. Это объекты данных документируются в ER-диаграмме.
Второй - это логика доступа к данным: обработка, необходимая для доступа к данным, часто означающая запросы к базе данных на языке структурированных запросов (SQL).
Третий - это логика приложения, которая документируется в DFD диаграммах, например, вариантах использования и функциональных требованиях.
Четвертый - это логика представления: отображение информации пользователю и ввод команд пользователя (пользовательский интерфейс). Эти четыре компонента (хранение данных, логика доступа к данным, логика приложений и логика представления) являются основными строительными блоками любой информационной системы.
Тремя основными аппаратными компонентами системы являются клиентские ПК, серверы и компьютерная сеть, которая их соединяет. Клиентские ПК являются устройствами ввода–вывода, используемыми пользователем, и обычно являются настольными или портативными ПК, но также могут быть портативными устройствами, смартфонами, терминалами специального назначения (киоски) и так далее.
Серверы обычно представляют собой большие высоко ресурсные компьютеры, используемые для хранения программного обеспечения и данных, доступ к которым может получить пользователь, у кого есть разрешение. Компьютерная сеть, соединяющая компьютеры, может отличаться по скорости передачи данных, по типу (проводная, беспроводная), по используемым протоколам передачи данных.
Рассмотрим, как менялась архитектура информационных систем. Первой архитектурой, которая широко использовалась в организациях, была файл-серверная архитектура.
В этих архитектурах клиент отвечает за логику представления, в то время как сервер отвечает за логику доступа к данным и хранение данных. Логика приложения может находиться на клиенте, находиться на сервере или быть разделена между обоими.
В настоящее время наиболее распространенной моделью является клиент-серверная архитектура, которая бывает нескольких типов: двухзвенная/двухуровневая, трехзвенная/трехуровневая, n-уровневая. В этих архитектурах клиент отвечает за логику представления, в то время как сервер отвечает за логику доступа к данным и хранение данных. Логика приложения может находиться на клиенте, находиться на сервере или быть разделена между обоими.
Если клиентское приложение содержит всю логику приложения, то оно называет – «толстый клиент».
Рисунок 2 – Двухзвенная архитектура с «толстым» клиентом
«Тонкие» клиенты содержат лишь небольшую часть логики приложения. Данный тип архитектуры популярен из-за малых накладных расходов и простого обслуживания. Например, многие веб-системы разработаны с использованием веб-браузера, выполняющего только функции представления, и только функции минимальной логики приложения с использованием, например, языка программирования, как JavaScript, в то время как на стороне сервера находится большая часть логики приложения, вся логика доступа к данным и хранилище данных.
Архитектуры клиент–сервер обладают важными преимуществами. Прежде всего, они являются масштабируемыми. Это означает, что легко увеличить или уменьшить ресурсы хранения и обработки данных на серверах. Например, если один сервер перегружен, то можно добавить дополнительный сервер для выполнения логики приложения. Можно добавить серверы для реализации логики доступа к данным или хранения данных. Затраты на введение их в строй к существующим серверам являются постепенными, и обновлять инфраструктуру можно по этапно.
Во–вторых, архитектуры клиент-сервер могут поддерживать множество различных типов клиентских приложений, реализованных на разных платформах, поддерживающих разные операционные системы, и серверов. Для интеграции разнородных платформ используют промежуточное ПО (middleware). Промежуточное программное обеспечение – это тип системного программного обеспечения. Промежуточное программное обеспечение устанавливается как на клиентском компьютере, так и на серверном компьютере. Клиентское программное обеспечение взаимодействует с промежуточным программным обеспечением, которое может переформатировать сообщение на язык, понятный промежуточному программному обеспечению, которое в свою очередь, преобразует сообщения, команды к виду понятному серверному программному обеспечению.
В–третьих, для архитектур "тонкий клиент-сервер", использующих интернет-технологии, достаточно просто разделить логику представления, логику приложения и логику доступа к данным и спроектировать каждую из них так, чтобы она была независимой. Например, логика представления может быть разработана в виде HTML- или XML-файлов, которые могут быть изменены без ущерба для логики приложения.
Аналогично, можно изменить логику приложения без изменения логики представления или данных, которые хранятся в базах данных и доступны с помощью команд SQL.
В свою очередь, в случае выхода из строя аппаратной части сервера, он может быть внесения изменений в клиентской части ИС.
Архитектуры клиент–сервер имеют некоторые ограничения, наиболее важным из которых является их сложность. Все клиент-серверные приложения состоят из двух частей: программного обеспечения на стороне клиента (frontend) и программного обеспечения на стороне сервера (backend). Реализация клиент-серверного приложения сложнее, чем написание традиционного программного обеспечения "все в одном", используемого в серверных архитектурах. Обновление ПО системы новой версией влечет за собой сложности, так как необходимо обновить все компоненты клиент-серверного приложения и убедиться, что обновления возможны и применимы на всех устройствах.
Типы клиент-серверных архитектур
Существует множество способов разделения логики приложения между клиентом и сервером.
На следующем рисунке представлена трехзвенная архитектура ИС.
Рисунок 3 – Трехзвенная архитектура ИС
В рамках данного типа архитектуры программное обеспечение на клиентском компьютере отвечает за логику представления, сервер(ы) приложений отвечает за логику приложения, а отдельный сервер(ы) базы данных отвечает за логику доступа к данным и хранение данных. Логика приложения может состоять из одного или нескольких отдельных модулей, работающих на рабочей станции на стороне клиента или сервера приложений. Наконец, реляционная СУБД на сервере баз данных выполняет логику доступа к данным и хранения данных.
В свою очередь средний уровень может быть разделен еще на несколько составляющих, что приводит к общей архитектуре, называемой «n-уровневой архитектурой».
Рисунок 4 – n-уровневая архитектура
Данный тип архитектуры широко распространен, например, в системах электронной коммерции. Когда пользователь помещает выбранный товар в корзину интернет-магазина вызываются определенные компоненты на сервере (ах) приложений, например, метод для определения цены и доступности товаров; вычисления затрат на покупку, налог с продаж и стоимость доставки; формирования платежей и т. д. Эти элементы бизнес-логики или методы для обработки данных хранятся на сервере (серверах) приложений и доступны для любого клиентского приложения. Компонентная бизнес-логика может использоваться несколькими независимыми приложениями, которым требуется определенная бизнес-логика. Серверы баз данных управляют компонентами данных системы. Каждый из этих четырех компонентов является отдельным, что позволяет легко распределять различные компоненты на разных серверах и разделять логику приложения на веб-ориентированный сервер и бизнес-ориентированный сервер.
Основное преимущество n-уровневой архитектуры клиент-сервер по сравнению с двухуровневой архитектурой (или трехуровневой с двухуровневой) заключается в том, что она разделяет обработку данных, что позволяет лучше сбалансировать нагрузку на серверы; она более масштабируема. И наоборот, если мы обнаружим, что сервер базы данных используется недостаточно, можно разместить на нем данные другого приложения.
У n-уровневой архитектуры есть два основных недостатка по сравнению с двухуровневой архитектурой (или трехуровневой с двухуровневой). Во-первых, большая нагрузку на компьютерную сеть. n-уровневая модель требует больше коммуникаций между серверами; она генерирует больше сетевого трафика, поэтому нужна сеть с большей пропускной способностью.
Во-вторых, программировать и тестировать программное обеспечение в n-уровневых архитектурах намного сложнее, чем в двухуровневых архитектурах, поскольку для завершения транзакции пользователя требуется больше устройств, которые должны правильно синхронизировать выполнение действий в системе.
Малораспространенные архитектуры
Архитектура клиент–сервер стала преобладающей архитектурой, используемой сегодня.
Две другие архитектуры встречаются реже, но все же используются в определенных ситуациях.
Серверные архитектуры. Самые первые вычислительные архитектуры были серверными, при этом сервер (обычно центральный компьютер мэйнфрейма) выполнял все четыре функции приложения. Клиенты (обычно терминалы) предоставляли пользователям отправлять и получать сообщения на серверный компьютер. Клиенты просто нажимали на клавиши, а обработка этих нажатий осуществлялась на сервере, а также отображали результат инструкций сервера.
Рисунок 5 – Пример серверной архитектуры
Эта очень простая архитектура часто работает очень хорошо. Прикладное программное обеспечение разрабатывается и хранится на сервере, а все данные находятся на одном компьютере. Существует одна точка контроля, потому что все сообщения проходят через один центральный сервер. Разработка программного обеспечения и администрирование программного обеспечения упрощаются, поскольку на одном компьютере размещается вся система (операционная система и прикладное программное обеспечение).
Серверная архитектура была первой архитектурой, используемой в информационных системах, но не оставалась единственным вариантом по мере развития аппаратного и программного обеспечения. Основная проблема ранних серверных систем заключалась в том, что сервер обрабатывал всю работу в системе. По мере роста потребностей во все большем количестве приложений и числа пользователей серверные компьютеры становились перегруженными и неспособными быстро обрабатывать все запросы пользователей. Время отклика стало медленнее, и менеджерам ИС приходилось тратить все больше денег на обновление серверного компьютера.
