Файл: Архитектура информационной системы.pdf

ВВЕДЕНИЕ

В последние годы развития информационных и аппаратных технологий можно говорить об увеличенном внимании и частых попытках совершенствования приложений клиент-сервер. На сегодняшний день уже реализованы такие приложения, которые обеспечивают поддержку совместной работы нескольких пользователей, при этом источник данных в сети остается один.

Распространение технологии «клиент-сервер» стало повсеместным при начале общения пользователя с компьютером или с системой, также основанной на работе компьютера. Примерами ежедневного применения технологии «клиент-сервер» являются такие повсеместные действия, о которых мы даже не задумываемся, как телефонная связь или совершение покупок. Применяя автоматический кассовый аппарат, осуществляя считывание штрих-кода с товара, расплачиваясь за совершенную покупку,- мы взаимодействуем с системой компьютера «клиент-сервер».

Технология «клиент-сервер» представляет собой архитектуру взаимодействия, при которой одна программа отправляет запрос на выполнение определенного перечня действий, а другая программа реализует непосредственно выполнение этого перечня. Участниками подобного взаимодействия являются клиент и сервер. Зачастую в качестве клиента или сервера выступает компьютер, который обеспечивает функционирование того или иного программного обеспечения.

Для того чтобы подробнее разобраться в приведенной архитектуре, была определена цель выполнения работы – изучение технологии «клиент-сервер».

Объектом исследования будет выступать сама технология «клиент-сервер».

Для достижения поставленной цели необходимо выполнить следующие задачи:

1. охарактеризовать архитектуру информационной системы;
2. рассмотреть архитектуру «файл-сервер»;
3. кратко охарактеризовать архитектуру «клиент-сервер»;
4. изучить классическую двухуровневую архитектуру «клиент-сервер»;
5. проанализировать трехуровневую архитектуру «клиент-сервер»;
6. произвести анализ программного обеспечения технологии «клиент-сервер».

В структуру работы включены такие элементы, как Введение, Заключение и Список использованных источников. Кроме того, работа содержит две главы, каждая из которых состоит из трех параграфов.

Основной теоретической базой исследования выступают работы современных исследователей проблемы, в их числе – Конноли Т., Мельников В., Морозевич А. Н., Зеневич А. М. и Хоморенко А. Д.

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

Общие характеристики архитектуры информационной системы

Приложения и информационные системы, актуальные для современного уровня развития технологий, могут похвастаться достижением настолько сложного и высокого уровня развития, что применение к ним термина «архитектура» уже давно никого не удивляет.

К сегодняшнему дню известно огромное количество понятий определения «архитектура информационной системы». Рассмотрим определение данного понятия из разных источников:

Архитектура представляет собой организационную структуру системы^[1].

Архитектура информационной системы является концепцией, определяющей модель, структуру, выполняемые функции и взаимосвязь составных частей информационной системы^[2].

Архитектура представляет собой базовую организация системы, воплощенную в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы^[3].

Архитектура является набором значимых решений по поводу организации системы программного обеспечения; набором структурных элементов и их интерфейсов, при помощи которых компонуется система, вместе с их поведением, которое определяется во взаимодействии между этими элементами; компоновкой элементов в постепенно укрупняющиеся подсистемы, а также стилем архитектуры, направляющим эту организацию – элементы и их интерфейсы, взаимодействия и компоновку^[4].

Архитектура программы или компьютерной системы – это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними^[5].

Архитектуру информационной системы можно рекурсивно разобрать на части, которые взаимодействуют при помощи интерфейсов, связи, которые соединяют части, и условия сборки частей. Части, которые взаимодействуют через интерфейсы, включают классы, компоненты и подсистемы.

Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания^[6].

Хотя определения несколько отличаются, можно заметить немалую степень сходства. Например, большинство определений указывают на то, что архитектура связана со структурой и поведением, а также только со значимыми решениями, может соответствовать некоторому архитектурному стилю, на нее влияют заинтересованные в ней лица и ее окружение, она воплощает решения на основе логического обоснования.

Под архитектурой программных систем будем понимать совокупность решений относительно:

• организации программной системы;
• выбора структурных элементов, составляющих систему и их интерфейсов;
• поведения этих элементов во взаимодействии с другими элементами;
• объединение этих элементов в подсистемы;
• архитектурного стиля, определяющего логическую и физическую организацию системы: статические и динамические элементы, их интерфейсы и способы их объединения.

Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты, но и правила ее использования и интеграции с другими системами, функциональность, производительность, гибкость, надежность, возможность повторного применения, полноту, экономические и технологические ограничения, а также вопрос пользовательского интерфейса^[7].

По мере развития программных систем все большее значение приобретает их интеграция друг с другом с целью построения единого информационного пространства предприятия. Как можно видеть из вышеприведенных определений интеграция является важнейшим элементом архитектуры.

Для того чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем необходимо четко следовать современным стандартам в этих областях. Без этого велика вероятность создать архитектуру, которая неспособна развиваться и удовлетворять растущим потребностям пользователей ИТ. В качестве законодателей стандартов в этой области выступают такие международные организации как SEI (Software Engineering Institute), WWW (консорциум World Wide Web), OMG (Object Management Group), организация разработчиков Java – JCP (Java Community Process), IEEE (Institute of Electrical and Electronics Engineers) и другие^[8].

Рассмотрим классификацию программных систем по их архитектуре:

• Централизованная архитектура;
• Архитектура «файл-сервер»;
• Двухзвенная архитектура «клиент-сервер»;
• Многозвенная архитектура «клиент-сервер»;
• Архитектура распределенных систем;
• Архитектура Веб-приложений;
• Сервис-ориентированная архитектура.

Необходимо иметь в виду тот факт, что, равно как и любую другую, приведенную классификацию нельзя назвать абсолютной. Так, в архитектуре некоторой ИС зачастую очевидны элементы влияния нескольких разных архитектурных взглядов^[9].

Архитектура файл-сервер

Принято считать, что первой структурой организации работы информационной системы была архитектура файл-сервер. Такая архитектура осуществляет только извлечение информации из файлов базы данных и передачу ее клиенту для последующей обработки.

Усложнение решения задач, повсеместное распространение персональных компьютеров и вычислительных сетей способствовало становлению архитектуры файл-сервер. Технология файл-сервер обеспечивает назначение одного из компьютеров, состоящих в сети, в качестве выделенного сервера. На нем впоследствии и хранятся файлы базы данных.

Файлы, отобранные в соответствии с запросами пользователей, передаются напрямую с сервера на рабочие станции пользователей. После этого, на рабочих станциях пользователей реализуется основная часть обработки информации. В такой технологии центральный сервер является в большинстве случаев только хранилищем файлов, который при этом не участвует в обработке самой информации (Рисунок 1)^[10]

Рисунок 1 Архитектура «файл-сервер»

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

База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера).

Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлены СУБД и приложение для работы с БД.

На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.

Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере.

СУБД инициирует обращения к данным, находящимся на файловом сервере, в результате которых часть файлов БД копируется на клиентский компьютер и обрабатывается, что обеспечивает выполнение запросов пользователя (осуществляются необходимые операции над данными).

При необходимости (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД.

Результат СУБД возвращает в приложение.

Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов^[11].

В рамках архитектуры « файл-сервер « были выполнены первые версии популярных так называемых настольных СУБД, таких, как dBase и Microsoft Access.

В литературе указываются следующие основные недостатки данной архитектуры:

1. При одновременном обращении множества пользователей к одним и тем же данным производительность работы резко падает, т.к. необходимо дождаться пока пользователь, работающий с данными, завершит свою работу. В противном случае возможно затирание исправлений, сделанных одними пользователями, изменениями других пользователей.
2. Вся тяжесть вычислительной нагрузки при доступе к БД ложится на приложение клиента, так как при выдаче запроса на выборку информации из таблицы вся таблица БД копируется на клиентскую машину и выборка осуществляется на клиенте. Таким образом, неоптимально расходуются ресурсы клиентского компьютера и сети. В результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
3. Как правило, используется навигационный подход, ориентированный на работу с отдельными записями.
4. В БД на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения, непосредственно из инструментальных средств (например, из утилиты Database Desktop фирмы Borland для файлов Paradox и dBase); подобная возможность облегчается тем обстоятельством, что фактически у таких СУБД база данных – понятие более логическое, чем физическое, поскольку под БД понимается набор отдельных таблиц, сосуществующих в отдельном каталоге на диске. Все это позволяет говорить о низком уровне безопасности – как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.
5. Недостаточно развитый аппарат транзакций служит потенциальным источником ошибок в плане нарушения смысловой и ссылочной целостности информации при одновременном внесении изменений в одну и ту же запись^[12].