Затонский А.В. Пособие по полному жизненному циклу информационных систем

Подождите немного. Документ загружается.

301

Архитектура программных средств информационной системы

Архитектура программного средства (ПС) − это его строение как оно

видно (или должно быть видно) извне его, т.е. представление ПС как системы,

состоящей из некоторой совокупности взаимодействующих подсистем. В

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

Разработка архитектуры является первым этапом борьбы со сложностью ПС, на

котором реализуется принцип выделения относительно независимых

компонент.

Основные задачи разработки архитектуры ПС:

• выделение программных подсистем и отображение на них внешних

функций (заданных во внешнем описании) ПС;

• определение способов взаимодействия между выделенными

программными подсистемами.

С учетом принимаемых на этом этапе решений производится дальнейшая

конкретизация и функциональных спецификаций.

Основные классы архитектур программных средств.

Различают следующие основные классы архитектур программных

средств:

• цельная программа;

• комплекс автономно выполняемых программ;

• слоистая программная система;

• коллектив параллельно выполняемых программ.

Цельная программа

Представляет вырожденный случай архитектуры ПС: в состав ПС входит

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

когда ПС должно выполнять одну какую-либо ярко выраженную функцию и ее

реализация не представляется слишком сложной. Естественно, что такая

архитектура не требует какого-либо описания (кроме фиксации класса

архитектуры), так как отображение внешних функций на эту программу

тривиально, а определять способ взаимодействия не требуется (в силу

отсутствия какого-либо внешнего взаимодействия программы, кроме как

взаимодействия ее с пользователем, а последнее описывается в документации

по применению ПС). Однако по некоторым соображениям архитектура цельной

программы может быть выбрана и для многофункциональной ИС, особенно

если ставится задача легко распространять и инсталлировать ИС (в идеале,

копированием).

Комплекс автономно выполняемых программ

Состоит из набора программ, такого, что:

302

• любая из этих программ может быть активизирована (запущена)

пользователем;

• при выполнении активизированной программы другие программы этого

набора не могут быть активизированы до тех пор, пока не закончит

выполнение активизированная программа;

• все программы этого набора применятся к одной и той же

информационной среде.

Таким образом, программы этого набора по управлению не

взаимодействуют − взаимодействие между ними осуществляется только через

общую информационную среду. Как правило, такая архитектура характерна для

однозадачных операционных систем, но не для ИС.

Слоистая программная система

Состоит из некоторой упорядоченной совокупности программных

подсистем, называемых слоями, такой, что:

• на каждом слое ничего не известно о свойствах (и даже существовании)

последующих (более высоких) слоев;

• каждый слой может взаимодействовать по управлению (обращаться к

компонентам) с непосредственно предшествующим (более низким) слоем

через заранее определенный интерфейс, ничего не зная о внутреннем

строении всех предшествующих слоев;

• каждый слой располагает определенными ресурсами, которые он либо

скрывает от других слоев, либо предоставляет непосредственно

последующему слою (через указанный интерфейс) некоторые их

абстракции.

Таким образом, в слоистой программной системе каждый слой может

реализовать некоторую абстракцию данных. Связи между слоями ограничены

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

слою и выдачей результатов этого обращения от нижнего слоя верхнему.

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

Коллектив параллельно действующих программ

Представляет собой набор программ, способных взаимодействовать

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

такие программы, во-первых, вызваны в оперативную память, активизированы

и могут попеременно разделять по времени один или несколько центральных

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

процессе выполнения) взаимодействия, на базе которых производиться их

синхронизация. Обычно взаимодействие между такими процессами

производится путем передачи друг другу некоторых сообщений.

Простейшей разновидностью такой архитектуры является конвейер.

Возможности для организации конвейера имеются, например, в операционной

системе UNIX. Конвейер представляет собой последовательность программ, в

303

которой стандартный вывод каждой программы, кроме самой последней, связан

со стандартным вводом следующей программы этой последовательности (см.

рис. 165). Конвейер обрабатывает некоторый поток сообщений. Каждое

сообщение этого потока поступает на ввод первой программе, которая

переработанное сообщение передает следующей программе, а сама начинает

обработку очередного сообщения потока. Таким же образом действует каждая

программа конвейера: получив сообщение от предшествующей программы и,

обработав его, она передает переработанное сообщение следующей программе

и приступает к обработке следующего сообщения. Последняя программа

конвейера выводит результат работы всего конвейера (результирующее

сообщение). Таким образом, в конвейере, состоящим из n программ, может

одновременно находиться в обработке до n сообщений. Конечно, в силу того,

что разные программы конвейера могут затратить на обработку очередных

сообщений разные отрезки времени, необходимо обеспечить каким-либо

образом синхронизацию этих процессов (некоторые процессы могут

находиться в стадии ожидания либо возможности передать переработанное

сообщение, либо возможности получить очередное сообщение).

Рис. 116. Конвейер параллельно действующих программ.

В общем случае коллектив параллельно действующих программ может

быть организован в систему с портами сообщений. Порт сообщений

представляет собой программную подсистему, обслуживающую некоторую

очередь сообщений: она может принимать на хранение от программы какое-

либо сообщение, ставя его в очередь, и может выдавать очередное сообщение

другой программе по ее требованию. Сообщение, переданное какой-либо

программой некоторому порту, уже не будет принадлежать этой программе (и

использовать ее ресурсы), но оно не будет принадлежать и никакой другой

программе, пока в порядке очереди не будет передано какой-либо программе по

ее запросу. Таким образом, программа, передающая сообщение не будет

находиться в стадии ожидания пока программа, принимающая это сообщение,

не будет готова его обрабатывать (если только не будет переполнен

принимающий порт).

Пример программной системы с портами сообщений приведен на рис.

166. Порт U может рассматриваться как порт вводных сообщений для

представленного на этом рисунке коллектива параллельно действующих

программ, а порт W − как порт выводных сообщений для этого коллектива

программ.

304

Рис. 117. Пример программной системы с портами сообщений.

Программные системы с портами сообщений могут быть как жесткой

конфигурации, так и гибкой конфигурации.

В системах с портами жесткой конфигурации (иногда называемых

системами с фиксированной, или статической, топологией) каждая программа

жестко связывается с одним или с несколькими входными портами. Для

передачи сообщения такая программа должна явно указать адрес передачи: имя

программы и имя ее входного порта. В этом случае при изменении

конфигурации системы придется корректировать используемые программы:

изменять адреса передач сообщений.

В системах с портами гибкой конфигурации (или динамической

топологией) с каждой программой связаны как входные, так и выходные

виртуальные порты. Перед запуском такой системы программы на основании

информации, задаваемой пользователем, должна производиться ее

предварительная настройка с помощью специальной программной компоненты,

осуществляющей совмещение каждого выходного виртуального порта одной

программы с каким-либо входным виртуальным портом другой. Тем самым при

изменении конфигурации системы в этом случае не требуется какой-либо

корректировки используемых программ − необходимые изменения должны

быть отражены в информации для настройки. Однако в этом случае требуется

иметь специальную программную компоненту, осуществляющую настройку

системы.

Архитектура серверной подсистемы.

В любой ИС можно выделить два компонента – собственно программу и

данные. Данные хранятся в так называемой «базе данных» – файле или наборе

305

файлов. Большинство используемых в настоящее время баз данных имеют

реляционную структуру, т.е. состоят из таблиц, связанных между собой.

При работе с данными используется ограниченное число операций:

• Определение структуры данных – создание таблиц, изменение структуры

таблиц, удаление таблиц и т.п.

• Манипулирование данными – добавление, изменение или удаление

данных

• Выборка данных

Механизм этих операций не зависит от того, какой продукт ими

пользуется (Microsoft Access, SAP R/3 или, например, SQL-версия программы

1С:Предприятие). Поэтому удобно осуществление этих операций возложить на

отдельный программный продукт – сервер баз данных. Существует много

серверов баз данных отличающихся друг от друга форматом файлов данных,

алгоритмами выполнения операций и прочими особенностями. Одними из

наиболее популярных серверов баз данных являются Microsoft SQL Server

(обычно читается как «Майкрософт сиквел-сервер») и Oracle Database [48].

Использование готового сервера баз данных даёт разработчику ИС

следующие преимущества:

• Упрощается разрабатываемая программа – вместо того, чтобы писать,

например, механизм записи в файл данных, предусматривая при этом

запрещение записи в файл информации одновременно несколькими

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

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

• Сервер баз данных берёт на себя значительную нагрузку, что уменьшает

стоимость всей системы. Дело в том, что компьютер пользователя

рассчитывается исходя из пиковой (т.е. максимальной) нагрузки. Но

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

компьютеры пользователей нагружены на малую долю их реальной

мощности. Если наиболее ресурсоёмкие операции, а именно к таким

операциям и относятся операции с базами данных, мы делегируем

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

можно будет значительно уменьшить.

• Сервер баз данных оптимизирует операции. Например, он хранит

промежуточные результаты выборки из базы. Если какие-то запросы к

базе данных используются часто, то сервер сохранит результаты этих

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

базе данных.

• С точки зрения компании-пользователя ИС, выбор программы-сервера

баз данных определяется следующими параметрами:

• Стоимость программы. Эта величина зависит от числа одновременных

подключений к серверу баз данных, от количества процессоров в составе

компьютеров-серверов баз данных и прочих параметров

• Стоимость администрирования сервера баз данных (заработная плата

администраторов + затраты на прием на работу администраторов)

306

• Стоимость аппаратных мощностей, необходимы для работы сервера баз

данных (компьютеров-серверов, сетевого оборудования, а также

устройств резервного копирования)

Производительность программ-серверов баз данных во многих случаях

не очевидна. Например, Oracle Database 9 версии позволяет устанавливать

различный приоритет для разных запросов к базе данных. Некоторые

регламентные операции в ИС сильно нагружают сервер баз данных, например,

закрытие склада (пересчёт стоимости всех товаров) или начисление

амортизации основных средств. Во время проведения этих операций загрузка

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

работников, выполняющих текущие операции. Если мы установим более

низкий приоритет для соответствующих запросов, то это повысит время их

выполнения (что может быть не так важно), но заметно понизит время отклика

системы на прочих операциях. Microsoft SQL Server 2000 подобной

возможности нам не предоставляет, но зато предъявляет, в большинстве

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

Так же стоит обратить внимание на способность программы-сервера баз

данных работать в режиме кластера. Кластер – это система из нескольких

компьютеров, одновременно выполняющих одну программу. Кластеры легко

масштабируются – для этого достаточно добавить ещё один компьютер,

установить на него программу и включить компьютер в кластер (программным

путём). Вместе с кластерами выгодно использовать так называемые блэйды

(blade – лезвие) – специальные аппаратные комплексы, представляющие собой

несколько компьютеров в одном корпусе. Они проще в администрировании,

легко масштабируются (достаточно просто вставить ещё одно «лезвие» в

соответствующий слот) и могут быть дешевле набора из «полноценных»

серверов. Подробнее кластеры и их использование рассматриваются в

следующих параграфах.

Терминальные службы

Совокупная стоимость владения системы, состоящей из серверов

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

стоимости серверов и компьютеров пользователей, причём зачастую этот

второй пункт во много раз превосходит первый.

Дело в том, что совокупная стоимость владения клиентскими

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

• Закупку машин. Некоторые программы, установленные у пользователей,

могут предъявлять высокие требования к производительности их

компьютеров, например, Microsoft Excel или Adobe Acrobat, не говоря

уже о графических пакетах.

• Поддержание компьютеров в работоспособном состоянии. Эта статья

затрат может заметно возрасти если в составе информационной системы

компании есть компьютеры удалённых филиалов, расположенных,

например, в других городах.

307

• Установка программного обеспечения на компьютеры пользователей и

его администрирование.

Именно для снижения подобных затрат служит концепция терминалов

(рис. 167) – разделение информационной структуры на терминальные сервера –

мощные компьютеры, выполняющие программы, в стандартной схеме

устанавливаемые на компьютеры пользователей и терминалы – облегчённые

компьютеры, предназначенные только для отображения информации,

передаваемой с терминального сервера и передачи в обратном направлении

информации о действиях пользователя (например, нажатии кнопок на

клавиатуре или движениях мышки).

В этом случае и логика, и ядро доступа к БД реализуются на

терминальном сервере. Ниже будут рассмотрены конкретные примеры

реализации подобной архитектуры.

Схема с использованием терминалов не только позволяет уменьшить

требования к клиентским компьютерам, но, что ещё более важно, значительно

уменьшает затраты на администрирование клиентского программного

обеспечения, и зачастую помогает уменьшить стоимость лицензий на

клиентское ПО (например, офисные приложения). Этот эффект возникает из-за

того, что эти программы в случае использования терминалов устанавливаются

только на терминальные сервера, которых может быть один на 50, а то и

больше клиентских рабочих мест.

Информация о нажатии клавиши

или действии мышью

Изображение экрана пользователя

Терминалы

Рис. 118. Пояснение принципа работы терминальной архитектуры

308

Фирма

www.itk.ru

успешно применяла в течение многих лет подобное

решение, когда на серверной стороне под управлением Linux работало

несколько программ, написанных на Linux-аналоге СУБД «Клиппер» [82]. Это

не только позволяло снизить требования к терминальным ПК и трафик, но и

снимало обычные для DBF-подобных многопользовательских БД проблемы

адекватности индексов, тупиков блокировок и т.п.

Дополнительным плюсом от использования терминальной архитектуры

является наивысший уровень безопасности. Пользователь, фактически, лишен

какой-либо возможности влиять на терминальный сервер, кроме как нажатиями

клавиш в пределах, отведенных ему ИС.

Однако наряду с преимуществами, терминальная архитектура имеет и ряд

недостатков.

• Сложно организовать красивый и, в то же время,

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

GUI-ориентированными средствами наподобие удаленного рабочего

стола Windows или PCAnywhere, но при этом возрастает нагрузка на сеть.

• Невозможно (или, во всяком случае, сложно) использовать ресурсы

своего компьютера. Например, записать результаты работы в файл на

терминале или отправить на принтер, присоединенный к ПК-терминалу.

Соответственно, можно рекомендовать терминальную систему в случаях,

когда на терминалах, в основном, вносится информация, а проблемы

лицензирования и упрощения администрирования являются определяющими.

Файл-серверная архитектура

Может эффективно применяться для решения одной или обеих

следующих задач:

• хранение файлов базы данных на файловом сервере (наподобие *.DBF);

• хранение общих файлов ИС на файловом сервере (*.EXE, *.DLL, *.INI и

т.п.).

Архитектура в современных информационных системах, как правило,

основанных на SQL-сервисах, в «чистом» виде не используется. Однако она

позволяет:

• упростить процедуру настройки ИС (с файлового сервера считываются

общие файлы);

• сэкономить место на рабочей станции или унифицировать

предоставляемые в общий доступ файлы большого объема, например,

стандарты, нормативные документы и т.п.

Использовав в стартовом (*.BAT или *.PIF) файле ИС

последовательность наподобие:

@echo off

if not exist z:\*.* net use z: \\ourserver\d

if exist z:\mail\ourexe.exe xcopy z:\mail\ourexe.exe /d/c/y

ourexe

309

(разобраться в работе этого командного файла предлагается самостоятельно),

получаем возможность записать в папку \\ourserver\d\mail исполняемый файл и

тем самым обеспечить автоматическое обновление версий на всех рабочих

станциях.

К достоинствам использования файл-серверной архитектуры можно

отнести:

• простоту реализации;

• надежность в смысле независимости ИС ни от какого сервера

приложений.

Однако файловая архитектура ведет к:

• большому сетевому трафику;

• ненадежности системы, например, из-за большого количества

одновременно открытых файлов, периодического разрушения индексов

(практически, неизбежного!) и других следствий использования единого

разделимого дискового пространства.

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

всегда есть возможность внести изменения в файлы БД какими-то

внешними средствами, а не только оболочкой ИС.

Таким образом, элементы файл-серверной архитектуры рационально

использовать:

• для устаревших приложений или сетей, где невозможно использование

(развертывание) полноценного сервера приложений;

• при малом количестве пользователей (до 3…5) иногда файл-серверные

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

серверах приложений;

• в случае если ИС нельзя организовать по-другому, например, из

соображений преемственности.

Недостатки файл-серверной архитектуры частично позволяет

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

Многоуровневые архитектуры

В соответствии с современными представлениями, часто архитектуру ИС

можно представить трёхслойной (3-layer) или трёхуровневой (3-tier). Первый

термин относится к логике системы:

• Интерфейс пользователя

• Внутренняя логика приложения

• База данных

Второй термин (трёхуровневая архитектура) относится набору

компонентов, из которых состоит программный продукт:

• Клиентское приложение. Именно эту программу видят пользователи

системы, т.е. она реализует первый слой – интерфейс пользователя. Это

приложение может дополнительно брать на себя обязанность обработки

310

бизнес-логики, всей – при отсутствии сервера приложений или только

части – при его наличии.

• Сервер приложения. Эта программа выполняет значительную часть

работы по выполнению вычислений (опциональный компонент).

• Сервер базы данных. Эта программа управляет хранением данных,

изменением структуры хранимых данных, записью данных в базу и

выборкой данных из неё (Microsoft SQL Server, Oracle Database, MySQL и

т.д.).

Дополнительным и часто обязательным элементом ИС является

библиотека приложения, которая содержит информацию о структуре базы

данных и логике системы. Один из подходов к разработке ИС заключается,

фактически, в редактировании файлов приложения. В этих файлах хранятся

описания классов, таблиц, форм, отчётов и многих других элементов логики

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

написанный в приложении, т.е. клиентская часть представляет собой

неизменяемую часть ИС, а приложение – изменяемую часть. В этом случае

клиентская часть состоит из программы-клиента и конфигурационной утилиты,

используемой для настройки подключения клиента к приложению, серверу

приложений и к базе данных (рис. 168).

Рис. 119. Основные варианты многоуровневых архитектур

Основные варианты многоуровневых архитектур ИС следующие:

• Двухзвенная архитектура – сервер приложений не используется.