Проектирование архитектуры_Эволюция архитектур ИС. Проектирование архитектуры информационной системы. Эволюция архитектур ис
 Скачать 0.53 Mb.
|
|
Проектирование архитектуры информационной системы. Эволюция архитектур ИС. Архитектурное проектирование является начальным этапом процесса проектирования, когда определяются основные подсистемы, процессы и структура управления и взаимодействия. Его результатом должно стать формирование структуры программного обеспечения. Архитектурный вид состоит из двух основных компонентов: структурных элементов и отношений между ними. При этом схематически архитектура может быть представлена в логическом или физическом виде. На рис. 1 приведен пример логической структурной схемы программной архитектуры на примере системы архива электронных документов.  Рисунок 1 – Логическая архитектура программной системы Основными архитектурными компонентами любой системы являются программное и аппаратное обеспечение. При разработке информационной системы необходимо вначале определить основные программные компоненты, а затем распределить их по различным аппаратным компонентам, на которых будет работать система. Каждый из этих компонентов может быть объединен различными способами. Все составляющие информационных систем можно разделить на четыре функциональных компонента. Первый - это компонент хранения данных. Большинство информационных систем требуют хранения и извлечения данных, будь то файл, из которого считываются параметры для вывода данных, или большая база данных, в которой хранятся, например, записи о кадровых ресурсах организации. Это объекты данных документируются в ER-диаграмме. Второй - это логика доступа к данным: обработка, необходимая для доступа к данным, часто означающая запросы к базе данных на языке структурированных запросов (SQL). Третий - это логика приложения, которая документируется в DFD диаграммах, например, вариантах использования и функциональных требованиях. Четвертый - это логика представления: отображение информации пользователю и ввод команд пользователя (пользовательский интерфейс). Эти четыре компонента (хранение данных, логика доступа к данным, логика приложений и логика представления) являются основными строительными блоками любой информационной системы. Тремя основными аппаратными компонентами системы являются клиентские ПК, серверы и компьютерная сеть, которая их соединяет. Клиентские ПК являются устройствами ввода–вывода, используемыми пользователем, и обычно являются настольными или портативными ПК, но также могут быть портативными устройствами, смартфонами, терминалами специального назначения (киоски) и так далее. Серверы обычно представляют собой большие высоко ресурсные компьютеры, используемые для хранения программного обеспечения и данных, доступ к которым может получить пользователь, у кого есть разрешение. Компьютерная сеть, соединяющая компьютеры, может отличаться по скорости передачи данных, по типу (проводная, беспроводная), по используемым протоколам передачи данных. Рассмотрим, как менялась архитектура информационных систем. Первой архитектурой, которая широко использовалась в организациях, была файл-серверная архитектура. В этих архитектурах клиент отвечает за логику представления, в то время как сервер отвечает за логику доступа к данным и хранение данных. Логика приложения может находиться на клиенте, находиться на сервере или быть разделена между обоими. В настоящее время наиболее распространенной моделью является клиент-серверная архитектура, которая бывает нескольких типов: двухзвенная/двухуровневая, трехзвенная/трехуровневая, n-уровневая. В этих архитектурах клиент отвечает за логику представления, в то время как сервер отвечает за логику доступа к данным и хранение данных. Логика приложения может находиться на клиенте, находиться на сервере или быть разделена между обоими. Если клиентское приложение содержит всю логику приложения, то оно называет – «толстый клиент».  Рисунок 2 – Двухзвенная архитектура с «толстым» клиентом «Тонкие» клиенты содержат лишь небольшую часть логики приложения. Данный тип архитектуры популярен из-за малых накладных расходов и простого обслуживания. Например, многие веб-системы разработаны с использованием веб-браузера, выполняющего только функции представления, и только функции минимальной логики приложения с использованием, например, языка программирования, как JavaScript, в то время как на стороне сервера находится большая часть логики приложения, вся логика доступа к данным и хранилище данных. Архитектуры клиент–сервер обладают важными преимуществами. Прежде всего, они являются масштабируемыми. Это означает, что легко увеличить или уменьшить ресурсы хранения и обработки данных на серверах. Например, если один сервер перегружен, то можно добавить дополнительный сервер для выполнения логики приложения. Можно добавить серверы для реализации логики доступа к данным или хранения данных. Затраты на введение их в строй к существующим серверам являются постепенными, и обновлять инфраструктуру можно по этапно. Во–вторых, архитектуры клиент-сервер могут поддерживать множество различных типов клиентских приложений, реализованных на разных платформах, поддерживающих разные операционные системы, и серверов. Для интеграции разнородных платформ используют промежуточное ПО (middleware). Промежуточное программное обеспечение – это тип системного программного обеспечения. Промежуточное программное обеспечение устанавливается как на клиентском компьютере, так и на серверном компьютере. Клиентское программное обеспечение взаимодействует с промежуточным программным обеспечением, которое может переформатировать сообщение на язык, понятный промежуточному программному обеспечению, которое в свою очередь, преобразует сообщения, команды к виду понятному серверному программному обеспечению. В–третьих, для архитектур "тонкий клиент-сервер", использующих интернет-технологии, достаточно просто разделить логику представления, логику приложения и логику доступа к данным и спроектировать каждую из них так, чтобы она была независимой. Например, логика представления может быть разработана в виде HTML- или XML-файлов, которые могут быть изменены без ущерба для логики приложения. Аналогично, можно изменить логику приложения без изменения логики представления или данных, которые хранятся в базах данных и доступны с помощью команд SQL. В свою очередь, в случае выхода из строя аппаратной части сервера, он может быть внесения изменений в клиентской части ИС. Архитектуры клиент–сервер имеют некоторые ограничения, наиболее важным из которых является их сложность. Все клиент-серверные приложения состоят из двух частей: программного обеспечения на стороне клиента (frontend) и программного обеспечения на стороне сервера (backend). Реализация клиент-серверного приложения сложнее, чем написание традиционного программного обеспечения "все в одном", используемого в серверных архитектурах. Обновление ПО системы новой версией влечет за собой сложности, так как необходимо обновить все компоненты клиент-серверного приложения и убедиться, что обновления возможны и применимы на всех устройствах. Типы клиент-серверных архитектур Существует множество способов разделения логики приложения между клиентом и сервером. На следующем рисунке представлена трехзвенная архитектура ИС.  Рисунок 3 – Трехзвенная архитектура ИС В рамках данного типа архитектуры программное обеспечение на клиентском компьютере отвечает за логику представления, сервер(ы) приложений отвечает за логику приложения, а отдельный сервер(ы) базы данных отвечает за логику доступа к данным и хранение данных. Логика приложения может состоять из одного или нескольких отдельных модулей, работающих на рабочей станции на стороне клиента или сервера приложений. Наконец, реляционная СУБД на сервере баз данных выполняет логику доступа к данным и хранения данных. В свою очередь средний уровень может быть разделен еще на несколько составляющих, что приводит к общей архитектуре, называемой «n-уровневой архитектурой».  Рисунок 4 – n-уровневая архитектура Данный тип архитектуры широко распространен, например, в системах электронной коммерции. Когда пользователь помещает выбранный товар в корзину интернет-магазина вызываются определенные компоненты на сервере (ах) приложений, например, метод для определения цены и доступности товаров; вычисления затрат на покупку, налог с продаж и стоимость доставки; формирования платежей и т. д. Эти элементы бизнес-логики или методы для обработки данных хранятся на сервере (серверах) приложений и доступны для любого клиентского приложения. Компонентная бизнес-логика может использоваться несколькими независимыми приложениями, которым требуется определенная бизнес-логика. Серверы баз данных управляют компонентами данных системы. Каждый из этих четырех компонентов является отдельным, что позволяет легко распределять различные компоненты на разных серверах и разделять логику приложения на веб-ориентированный сервер и бизнес-ориентированный сервер. Основное преимущество n-уровневой архитектуры клиент-сервер по сравнению с двухуровневой архитектурой (или трехуровневой с двухуровневой) заключается в том, что она разделяет обработку данных, что позволяет лучше сбалансировать нагрузку на серверы; она более масштабируема. И наоборот, если мы обнаружим, что сервер базы данных используется недостаточно, можно разместить на нем данные другого приложения. У n-уровневой архитектуры есть два основных недостатка по сравнению с двухуровневой архитектурой (или трехуровневой с двухуровневой). Во-первых, большая нагрузку на компьютерную сеть. n-уровневая модель требует больше коммуникаций между серверами; она генерирует больше сетевого трафика, поэтому нужна сеть с большей пропускной способностью. Во-вторых, программировать и тестировать программное обеспечение в n-уровневых архитектурах намного сложнее, чем в двухуровневых архитектурах, поскольку для завершения транзакции пользователя требуется больше устройств, которые должны правильно синхронизировать выполнение действий в системе. Малораспространенные архитектуры Архитектура клиент–сервер стала преобладающей архитектурой, используемой сегодня. Две другие архитектуры встречаются реже, но все же используются в определенных ситуациях. Серверные архитектуры. Самые первые вычислительные архитектуры были серверными, при этом сервер (обычно центральный компьютер мэйнфрейма) выполнял все четыре функции приложения. Клиенты (обычно терминалы) предоставляли пользователям отправлять и получать сообщения на серверный компьютер. Клиенты просто нажимали на клавиши, а обработка этих нажатий осуществлялась на сервере, а также отображали результат инструкций сервера.  Рисунок 5 – Пример серверной архитектуры Эта очень простая архитектура часто работает очень хорошо. Прикладное программное обеспечение разрабатывается и хранится на сервере, а все данные находятся на одном компьютере. Существует одна точка контроля, потому что все сообщения проходят через один центральный сервер. Разработка программного обеспечения и администрирование программного обеспечения упрощаются, поскольку на одном компьютере размещается вся система (операционная система и прикладное программное обеспечение). Серверная архитектура была первой архитектурой, используемой в информационных системах, но не оставалась единственным вариантом по мере развития аппаратного и программного обеспечения. Основная проблема ранних серверных систем заключалась в том, что сервер обрабатывал всю работу в системе. По мере роста потребностей во все большем количестве приложений и числа пользователей серверные компьютеры становились перегруженными и неспособными быстро обрабатывать все запросы пользователей. Время отклика стало медленнее, и менеджерам ИС приходилось тратить все больше денег на обновление серверного компьютера. В первые дни переход на серверный компьютер большего размера (обычно мэйнфрейм) требовал значительных финансовых затрат. Сегодня серверная архитектура остается жизнеспособным выбором архитектуры. Нулевой клиент, или ультратонкий клиент, - это серверная вычислительная модель, которая сегодня часто используется в инфраструктуре виртуальных рабочих столов (VDI). Типичное устройство нулевого клиента представляет собой небольшую коробку, которая соединяет клавиатуру, мышь, монитор и подключение Ethernet/FastEthernet к удаленному серверу. На сервере размещено все: операционная система клиента и все программные приложения. К серверу можно получить доступ по беспроводной сети или с помощью кабеля. На основе такой архитектуры реализованы, например, информационный киоск электронной очереди, информационное табло (инфомат).  Рисунок 6 – Инфомат Основная задача инфомата, как следует из названия, заключается в предоставлении различных информационных (и не только) сервисов. С их помощью можно получить справочную информацию, произвести оплату за те или иные услуги. Инфоматы — источники справочной информации, на выставках, в учебных заведениях, спортивных центрах, автосалонах, музеях. Модель нулевых клиентских вычислений обеспечивает эффективный и безопасный способ предоставления приложений конечным пользователям. Администрирование простое, и несколько виртуальных компьютеров могут быть запущены на оборудовании серверного класса в средах VDI, что значительно сокращает количество физических компьютеров, которые необходимо приобрести и обслуживать. Кроме того, серверная модель с нулевым клиентом ограничивает использование клиентского компьютера в некоммерческих целях. Клиент-ориентированная архитектура В клиент-ориентированных архитектурах клиенты представляют собой микрокомпьютеры в локальной сети, а сервер - серверный компьютер в той же сети. Прикладное программное обеспечение на клиентских компьютерах отвечает за логику представления, логику приложения и логику доступа к данным; сервер просто обеспечивает хранение данных.  Рисунок 7 – Клиент-ориентированная архитектура Эта простая архитектура часто очень хорошо работает в ситуациях с небольшим числом пользователей или ограниченными требованиями к доступу к данным. Основная проблема клиентской архитектуры заключается в том, что все данные на сервере должны передаваться клиенту для обработки. Например, предположим, что пользователь хочет отобразить список всех сотрудников, имеющих страхование жизни компании. Все данные в базе данных сотрудников должны передаваться с сервера, где хранится база данных, по сети клиенту, который затем выполняет запрос для поиска каждой записи, соответствующей данным, запрошенным пользователем. В других вычислительных моделях, которые мы обсуждали, логика доступа к данным выполнялась бы на сервере, и клиенту передавались бы только результаты запроса. В клиентской вычислительной модели логика доступа к данным выполняется в клиентской системе. Поэтому вся база данных должна быть передана клиенту до того, как будет произведена обработка. Это может привести как к перегрузке сети, так и клиентских компьютеров. Достижения в области архитектурных конфигураций Виртуализация. Этот термин в вычислительной области относится к созданию виртуального устройства или ресурса, такого как сервер или устройство хранения данных. Возможно, вы знакомы с этой концепцией, если вы разделили жесткий диск вашего компьютера на несколько отдельных жестких дисков. Хотя в вашей системе есть только один физический жесткий диск, вы относитесь к каждому разделенному «виртуальному» диску так, как если бы это был отдельный физический жесткий диск. Сегодня этот термин стал общепринятым модным словечком, поскольку мы слышим о виртуализации серверов, виртуализации хранилищ, сетевой виртуализации и других разновидностях виртуализации. Виртуализация серверов предполагает разделение физического сервера на более мелкие виртуальные серверы. Программное обеспечение используется для разделения физического сервера на несколько виртуальных сред, называемых виртуальными или частными серверами. Эта возможность преодолевает основное ограничение серверных архитектур старого стиля, которые были основаны на отдельных, больших, дорогих монолитных компьютерах. Сегодня физическое серверное устройство может использоваться для предоставления множества виртуальных серверов, которые независимы друг от друга, но совместно находятся на одном физическом сервере. Каждый виртуальный сервер работает под управлением операционной системы и может быть перезагружен независимо от других виртуальных серверов. Для предоставления набора виртуальных серверов требуется меньше оборудования по сравнению с эквивалентными физическими серверами, поэтому затраты снижаются. Такое расположение также может оптимизировать использование физического сервера, экономя на эксплуатационных расходах. Одно из современных инструментальных средств для виртуализации – Docker контейнеры. Виртуализация хранилища предполагает объединение нескольких сетевых устройств хранения данных в то, что выглядит как единое хранилище. Сеть хранения данных (SAN) использует виртуализацию хранилища для создания высокоскоростной подсети общих устройств хранения данных. В этой среде такие задачи, как резервное копирование, архивирование и восстановление, выполняются проще и быстрее. Облачные вычисления. Организациям больше не нужно владеть собственной вычислительной инфраструктурой, управлять ею и администрировать ее. Мы находимся в эпицентре развития облачных вычислений, когда все — от вычислительной мощности до вычислительной инфраструктуры, приложений, бизнес-процессов - может предоставляться в виде услуги везде и всегда, когда это необходимо. “Облако” в облачных вычислениях можно определить как набор аппаратных средств, сетей, хранилищ, серверов и интерфейсов, которые объединяются для предоставления вычислений как услуги. Облачные сервисы предоставляют программное обеспечение, промежуточное программное обеспечение, инфраструктуры и хранилища через Интернет (либо в виде отдельных компонентов, либо в виде полной платформы) в зависимости от потребностей пользователей. Облачные вычисления могут быть реализованы тремя способами: частное облако, публичное облако и гибридные облака. В общедоступных облаках услуги предоставляются «как услуга» через Интернет практически без контроля над базовой технологической инфраструктурой. Частные облака предлагают действия и функции “как услуга”, но развертываются через корпоративную сеть или размещенный центр обработки данных. Гибридные облака сочетают в себе возможности как публичных, так и частных облаков. В этом сценарии действия и задачи распределяются в частные или общедоступные облака по мере необходимости. Сторонники облачных вычислений указывают на ряд преимуществ модели облачных вычислений. Во-первых, при использовании облака выделяемые ресурсы могут быть увеличены или уменьшены в зависимости от спроса. Эта способность, называемая эластичностью, делает облако масштабируемым — облако может увеличиваться в периоды пикового спроса и уменьшаться в периоды меньшего спроса. Приложения в облаке могут расширяться по мере добавления пользователей и изменения требований приложения. Во-вторых, облачные клиенты могут получать облачные ресурсы простым способом. С поставщиком облачных услуг заключаются соглашения об определенном объеме вычислений, хранилищ, программного обеспечения, процессов или других ресурсов. После использования этих ресурсов они могут быть освобождены, если больше не требуются. В-третьих, облачные сервисы обычно имеют стандартизированные API (интерфейсы прикладных программ). Это означает, что службы стандартизировали способ взаимодействия программ или источников данных друг с другом. Эта возможность позволяет клиенту легче создавать связи между облачными сервисами. Наконец, модель облачных вычислений позволяет клиентам выставлять счета за ресурсы по мере их использования. Использование облака измеряется, и клиенты платят только за используемые ресурсы — так же, как вы используете электричество в своей квартире. Эта функция делает облачные вычисления очень привлекательными с финансовой точки зрения. Поставщики облачных вычислений используют виртуализацию в качестве ключевой технологии, предоставляющей возможности. Однако для заказчиков облачных вычислений смысл заключается в передаче ИТ-технологий, приложений и навыков на аутсорсинг с оплатой за использование. Концепция облачных вычислений привлекла внимание организаций всех размеров. Благодаря модели облачных вычислений мощь виртуализации преобразуется в измеримую ценность для бизнеса. Сравнение архитектур Большинство систем созданы для использования существующей инфраструктуры в организации, поэтому часто текущая инфраструктура ограничивает выбор архитектуры. Например, если новая система будет создана для организации, ориентированной на мэйнфреймы, серверная архитектура может быть лучшим вариантом. Другие факторы, такие как корпоративные стандарты, существующие лицензионные соглашения и отношения между продуктом и поставщиком, также могут повлиять на выбор архитектуры проектной группой. В настоящее время многие организации располагают различными инфраструктурами однако они используются или активно ищут пилотные проекты для тестирования новых архитектур и инфраструктур, что позволяет проектной группе выбирать архитектуру на основе других важных факторов. Каждая из только что рассмотренных архитектур имеет свои сильные и слабые стороны. Архитектуре клиент-сервер отдается предпочтение из-за стоимости инфраструктуры (аппаратного обеспечения, программного обеспечения и сетей, которые будут поддерживать прикладную систему). Архитектура клиент-сервер обладает высокой масштабируемостью, поскольку серверы могут быть добавлены в инфраструктуру (или удалены из нее) при изменении потребностей обработки. Инструменты разработки графического интерфейса, используемые для создания приложений для клиент–серверных архитектур, могут быть интуитивно понятными и простыми в использовании. Разработка приложений для этих архитектур может быть быстрой и безболезненной. Однако имейте в виду, что архитектуры клиент–сервер действительно предполагают дополнительную сложность нескольких уровней аппаратного обеспечения (например, серверов баз данных, веб-серверов, клиентских рабочих станций), которые должны эффективно взаимодействовать друг с другом. Проектные группы часто недооценивают трудности, связанные с созданием безопасных и эффективных клиент–серверных приложений. Создание архитектурного проекта Создание архитектурного проекта начинается с нефункциональных требований. Первым шагом является уточнение нефункциональных требований до более подробных требований, которые затем используются для выбора используемой архитектуры (серверной, клиентской или клиент-серверной) и программных компонентов, которые будут размещены на каждом устройстве. В архитектуре клиент–сервер также необходимо решить, следует ли использовать двухуровневую, трехуровневую или n-уровневую архитектуру. Затем нефункциональные требования и дизайн архитектуры используются для разработки спецификации аппаратного и программного обеспечения. Существует четыре основных типа нефункциональных требований, которые могут быть важны при проектировании архитектуры: эксплуатационные требования, требования к производительности, требования безопасности и культурные требования. Опишем каждый из них по очереди, а затем объясним, как они могут повлиять на архитектурный дизайн. Эксплуатационные требования Эксплуатационные требования определяют операционную среду (среды), в которых должна работать система, и то, как они могут изменяться с течением времени. Обычно это относится к операционным системам, системному программному обеспечению и информационным системам, с которыми система должна взаимодействовать, но иногда также включает физическую среду, если среда важна для приложения (например, в шумном производственном цехе, где не слышно звуковых оповещений). Требования к технической среде Требования к технической среде определяют тип аппаратного и программного обеспечения, на котором будет работать система. Эти требования обычно касаются программного обеспечения операционной системы (например, Windows, Linux), программного обеспечения системы баз данных (например, Oracle) и другого системного программного обеспечения (например, Internet Explorer). Иногда могут возникать особые требования к оборудованию, которые накладывают важные ограничения на систему, такие как необходимость работы на смартфоне с очень маленьким дисплеем. Требования к системной интеграции Требования к системной интеграции - это требования, которые требуют, чтобы система работала с другими информационными системами, как внутри компании, так и за ее пределами. Обычно они определяют интерфейсы, через которые будет осуществляться обмен данными с другими системами. Требования к переносимости информационных систем никогда не остаются постоянными. Потребности бизнеса и операционные технологии меняются, поэтому информационные системы, которые их поддерживают и работают на них, тоже должны измениться. Требования к переносимости определяют, как технические операционные среды могут изменяться с течением времени и как система должна реагировать (например, в настоящее время система может работать в Windows, но в будущем, возможно , придется работать в Linux). Требования к переносимости также относятся к потенциальным изменениям в бизнес-требованиях, которые будут определять изменения в технической среде. Например, многие организации сегодня работают над тем, чтобы их приложения были оптимизированы для таких устройств, как iPad, в ответ на запросы пользователей. Требования к реинжинирингу. Требования к реинжинирингу определяют изменения бизнес-требований, которые можно ожидать. Не все изменения предсказуемы, но некоторые из них предсказуемы. Например, предположим, что небольшая компания имеет только одно производственное предприятие, но планирует строительство второго завода в ближайшие пять лет. Все информационные системы должны быть написаны таким образом, чтобы было легко отслеживать каждое растение в отдельности, будь то для личных целей, составления бюджета или управления запасами. Требование реинжиниринга пытается предвидеть будущие требования, чтобы системы, разработанные сегодня, было легко поддерживать, если и когда появятся эти будущие требования. Определяет цикл обновления системы, например частоту выпуска новых версий. Требования к производительности. Требования к производительности сосредоточены на таких вопросах производительности, как время отклика, пропускная способность и надежность. Поскольку аналитики определяют требования к производительности системы, ключевым вопросом является возможность проверки этих требований. Каждое требование должно быть измеримым, чтобы можно было провести сравнительный анализ. Только таким образом можно проверить выполнение требований к производительности. Фактически, многие системные аналитики пишут спецификацию теста, содержащую четко определенный тест для каждого требования, одновременно с созданием требований. Такое внимание к тестируемости предотвращает создание требований к низкой производительности, таких как “Система должна иметь достаточно быстрое время отклика, чтобы сотрудники могли эффективно выполнять свою работу”. Требования к скорости Требования к скорости - это именно то, что они говорят: насколько быстро должна работать система. В первую очередь, это время отклика системы: Сколько времени требуется системе, чтобы ответить на запрос пользователя? В то время как все предпочли бы низкое время отклика, когда система немедленно реагирует на каждый запрос пользователя, это непрактично. Мы могли бы разработать такую систему, но это было бы дорого. Большинство пользователей понимают, что некоторые части системы будут реагировать быстро, в то время как другие будут работать медленнее. Те действия, которые выполняются локально на компьютере пользователя, должны выполняться практически мгновенно (например, ввод текста, перетаскивание), в то время как другие, требующие связи по сети, могут иметь более высокое время отклика (например, веб-запрос). В целом, время отклика менее 7 секунд считается приемлемым, когда требуется связь по сети. Второй аспект требований к скорости заключается в том, сколько времени требуется для отражения транзакций в одной части системы в других частях. Например, как скоро после размещения заказа товары, содержащиеся в нем, будут показаны как недоступные для продажи кому-либо другому? Если запасы не будут обновлены немедленно, то кто-то другой может разместить заказ на тот же товар, только чтобы позже узнать, что его нет на складе. Или как скоро после размещения заказа он отправляется на склад для отбора из запасов и отправки? В этом случае некоторая задержка по времени может оказать незначительное влияние. Требования к пропускной способности Требования к пропускной способности пытаются предсказать, сколько пользователей система должна будет поддерживать, как в целом, так и одновременно. Требования к пропускной способности важны для понимания размера баз данных, необходимой вычислительной мощности и так далее. Наиболее важным требованием обычно является максимальное количество одновременных пользователей, поскольку это напрямую влияет на вычислительную мощность компьютера (компьютеров), необходимого для поддержки системы. Часто бывает проще предсказать количество пользователей для внутренних систем, предназначенных для поддержки собственных сотрудников организации, чем предсказать количество пользователей для систем, ориентированных на клиента, особенно в Интернете. Как это делает weather.com оцените максимальное количество пользователей, которые будут одновременно запрашивать информацию о погоде? Это такое же искусство, как и наука, поэтому команда часто предоставляет диапазон оценок, причем более широкие диапазоны используются для обозначения менее точной оценки. Требования к доступности и надежности Требования к доступности и надежности сосредоточены на степени, в которой пользователи могут предполагать, что система будет доступна для их использования. В то время как некоторые системы предназначены для использования только в течение 40-часовой рабочей недели, другие системы предназначены для использования людьми по всему миру. Для таких систем членам проектной группы необходимо рассмотреть вопрос о том, как приложение может быть эксплуатируется, поддерживается и обслуживается 24/7 (т.е. 24 часа в сутки, 7 дней в неделю). Это требование 24 × 7 означает, что пользователям может понадобиться помощь или у них могут возникнуть вопросы в любое время, и службы поддержки, доступной 8 часов в день, будет недостаточно. Также важно учитывать, какая надежность необходима в системе. Система, требующая высокой надежности (например, медицинское устройство или телефонный коммутатор), нуждается в гораздо большем планировании и тестировании, чем система, не требующая такой высокой надежности (например, система персонала, веб-каталог). Сложнее предсказать пики и спады в использовании системы с глобальной аудиторией. Как правило, резервное копирование приложений выполняется по выходным или поздним вечерам, когда пользователи больше не имеют доступа к системе. Такие мероприятия по техническому обслуживанию должны быть переосмыслены с учетом глобальных инициатив. Разработка веб-интерфейсов, в частности, усилила потребность в поддержке 24/7; по умолчанию доступ к Интернету может получить любой человек в любое время. Требования к безопасности. Безопасность - это способность защитить информационную систему от сбоев и потери данных, будь то в результате преднамеренного действия (например, хакера или террористической атаки) или случайного события (например, сбой диска, торнадо). Разработчики новых систем должны обеспечить, чтобы требования безопасности системы приводили к разумным исправлениям для предотвращения проблем; разработчики систем несут ответственность за обеспечение безопасности в самих информационных системах. Требования к контролю доступа Некоторые данные, хранящиеся в системе, должны быть конфиденциальными; некоторые данные требуют специального контроля над тем, кому разрешено их изменять или удалять. Например, записи о персонале должны быть доступны для чтения только отделу кадров и руководителю сотрудника; внесение изменений должно разрешаться только отделом кадров. В требованиях к контролю доступа указывается, кто может получить доступ к каким данным и какой тип доступа разрешен — может ли пользователь создавать, читать, обновлять и/или удалять данные. То требования снижают вероятность того, что авторизованный пользователь системы может выполнять несанкционированные действия. Культурные требования. Культурные требования специфичны для стран, в которых будет использоваться система. В современной глобальной бизнес-среде организации расширяют свои системы, чтобы охватить пользователей по всему миру. Хотя это может иметь большой бизнес-смысл, его влияние на разработку приложений не следует недооценивать. Еще одной важной частью проектирования архитектуры системы является понимание глобальных культурных и политических требований к системе Требование поддержки мультиязычности. Первое и наиболее очевидное различие между приложениями, используемыми в одном регионе, и приложениями, предназначенными для глобального использования, заключается в языке. Глобальные приложения часто имеют многоязычные требования, что означает, что они должны поддерживать пользователей, которые говорят на разных языках и пишут нерусскими буквами (например, татарский язык, китайский). Некоторые системы предназначены для работы с несколькими языками на лету, чтобы пользователи в разных странах могли одновременно использовать разные языки; то есть одна и та же система поддерживает несколько разных языков одновременно (многоязычная система). Другие системы содержат отдельные части, написанные на каждом языке, и их необходимо переустановить, прежде чем можно будет использовать определенный язык; то есть каждый язык предоставляется другой версией системы, так что при любой установке будет использоваться только один язык (т.е. отдельная многоязычная система). Любой из подходов может быть эффективным, но эта функциональность должна быть встроена в систему задолго до ее внедрения Требования к настройке. Для глобальных приложений проектной группе необходимо будет подумать о требованиях к настройке: Какая часть приложения будет контролироваться центральной группой, а какая часть приложения будет управляться локально? Например, некоторые компании разрешают дочерним компаниям в некоторых странах настраивать приложение, опуская или добавляя определенные функции. Это решение имеет компромиссы между гибкостью и контролем, поскольку настройка часто усложняет для проектной группы создание и поддержку приложения. Это также означает, что обучение может отличаться в разных подразделениях организации, а индивидуальная настройка может создать проблемы, когда сотрудники переезжают из одного места в другое. Неустановленные нормы. Во многих странах существуют неустановленные нормы, которые не разделяются на международном уровне. Разработчику приложения важно четко сформулировать эти предположения, поскольку в противном случае они могут привести к путанице. В Соединенных Штатах неустановленной нормой для ввода даты является формат даты ММ/ДД/ГГ; однако в Канаде и большинстве европейских стран неустановленной нормой является ДД/ММ/ГГ. Когда вы разрабатываете глобальные системы, крайне важно признать эти неустановленные нормы и четко сформулировать их, чтобы пользователи в разных странах не путались. Валюта - это еще один элемент, который иногда упускается из виду при проектировании системы; глобальные прикладные системы должны указывать валюту, в которой вводится и сообщается информация. Требования к моделям архитектур Для обеспечения эффективного выполнения запросов пользователя – информационная система должна удовлетворять ряду требований, которые можно представить приведенным нижеследующим набором характеристик: 1. Производительность. Требование высокой производительности системы предполагает такую архитектуру, где за все критические операции отвечало бы минимальное число подсистем с ограниченным взаимодействием между ними. В таких случаях лучше использовать компоненты в виде крупных модулей, а не мелкие структурные элементы. 2. Защищенность, для обеспечения которой требуется архитектура с многоуровневой структурой, где наиболее критические системные элементы защищены на внутренних уровнях, а проверка их безопасности осуществляется на более высоком уровне. 3. Безопасность, архитектуру следует спроектировать так, чтобы при этом за операции, влияющие на безопасность системы, должно отвечать как можно меньше подсистем. 4. Надежность, повысить можно путем разработки архитектуры с включением избыточных компонентов, которые можно было бы заменять и обновлять, не останавливая общее функционирование системы. 5. Удобство сопровождения предполагает, что системная архитектура должна основываться на уровне мелких структурных компонентов, которые можно легко заменять и модифицировать. Программные модули, создающие данные, необходимо отделить от модулей, их использующих. Кроме того, нужно избегать структур совместного использования данных. Рассмотрим пример графического представления архитектуры ИС. Каждый веб-сайт, который вы просматриваете, будь то блог Wordpress или веб-приложение, Facebook, Twitter или банковское приложение, построен на архитектуре клиент-сервер. Архитектура работает по модели запрос-ответ. Клиент отправляет запрос на сервер для получения информации, и сервер отвечает на него.  Рисунок 8 – Пример представления архитектуры ИС КОНТРОЛЬНЫЕ ВОПРОСЫ: Вопросы: Перечислите и опишите четыре основных функциональных компонента программного приложения. Перечислите и опишите три основных аппаратных компонента системы. Охарактеризуйте архитектуру клиент–сервер. Охарактеризуйте серверную архитектуру. Охарактеризуйте клиентскую архитектуру. Опишите различия между двухуровневой, трехуровневой и n-уровневой архитектурами клиент–сервер. Сравните серверную, клиентскую и клиент–серверную архитектуры. Что подразумевается под термином «масштабируемый»? Каково его значение при выборе архитектуры? Объясните термин «Виртуализация». |