double arrow

Архитектура информационной системы типа « клиент-сервер»

3

Информационные системы с клиент-серверной архитектурой позволяют избежать проблем файл-серверных приложений. При такой архитектуре сервер базы данных, расположенный на компьютере-сервере, обеспечивает выполнение основного объема обработки данных. Клиентское приложение формирует запросы к серверу базы данных, как правило, в виде инструкций языка SQL. Сервер извлекает из базы запрошенные данные и передает на компьютер клиента. Главное достоинство такого подхода — значительно меньший объем передаваемых данных.

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

Структура информационной системы с сервером базы данных

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

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

Ø с помощью самой операционной системы;

Ø с использованием схем, имен входов, ролей, шифрования базы данных и т. д.;

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

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

Преимущества

Ø Отсутствие дублирования кода программы-сервера программами-клиентами.

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

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

Ø Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т. п.

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

Недостатки

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

Ø Поддержка работы данной системы требует отдельного специалиста — системного администратора.

Ø Высокая стоимость оборудования.

Ø Многоуровневая архитектура клиент-сервер

Многоуровневая архитектура клиент-сервер — разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов.

Частные случаи многоуровневой архитектуры:

Ø Трёхуровневая архитектура

Ø Сеть с выделенным сервером

Сеть с выделенным сервером (англ. Client/Server network) — это локальная вычислительная сеть (LAN), в которой сетевые устройства централизованы и управляются одним или несколькими серверами. Индивидуальные рабочие станции или клиенты (такие, как ПК) должны обращаться к ресурсам сети через сервер(ы).

V. Компоненты ИС.

Информационной системой (ИС) называется программно-аппа­ратный комплекс, функционирование которого состоит (1) в надежном хранении информации в памяти компьютера, (2) выполнении специфических для конкретной предметной области преобразований информации и вычислений, (3) предоставлении пользователю удобного и легкоусвояемого интерфейса.

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

1. Любая ИС предназначена для сбора, хранения и обработки информации. Поэтому в основе любой ИС лежит среда хранения и доступа к данным. Среда — совокупность ресурсов, предоставляемых в распоряжение пользователя системы. Среда должна обеспечить уровень надежности хранения и эффективность доступа, соответствующие области применения ИС.

2. ИС ориентируются на конечного пользователя, например, бухгалтера. Такие пользователи могут быть очень далеки от мира компьютеров. Для них персональный компьютер — всего лишь орудие собственной профессиональной деятельности. Поэтому ИС обязана обладать простым, удобным, легко усваиваемым интер­фейсом, который должен предоставить конечному пользователю все необходимые для его работы функции, но в то же время не дать ему возможность выполнять какие-то лишние действия. Обычно этот интерфейс является графическим: с меню, кнопками, подсказками и т. п.

Для функционирования ИС необходимы следующие основные компоненты:

Ø база данных (БД);

Ø схема базы данных;

Ø система управления базой данных (СУБД);

Ø приложения;

Ø пользователи;

Ø технические средства.

Рассмотрим кратко каждый из этих компонентов. Начнем с базы данных. Существует немало определений этого понятия. Вот нестрогое определение БД, которое Крис Дейт (С. J. Date), один из главных экспертов в области баз данных, дает в начале своего учебного курса: «Базу данных можно рассматривать как подобие электронной картотеки, то есть хранилище для некоторого набора занесенных в компьютер файлов данных».

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

Данные — это данные пользователя или предприятия, использующего систему, и связанные с его деятельностью. Например, данные о продукции, счетах, коровах.

Метаданные — это данные о данных или схема базы данных, которая описывает структуру обычных данных и дает о них фундаментальную информацию. Обычно мы не видим эту схему, потому что она спрятана от нас программными средствами.

Пользователей можно разделить на три большие группы: (1) прикладные программисты, (3) пользователи, (3) администраторы.

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

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

В связи с тем, что данные одна из главных ценностей пред­приятия, администратор данных должен разбираться в данных и понимать нужды предприятия по отношению к данным на уровне управления высшего руководства предприятия. В его обязанности входят: принимать решения, какие данные необходимо вносить в БД, обеспечивать поддержание порядка при использовании их после занесения в базу данных.

Техническим специалистом, ответственным за реализацию реше­ний администратора данных, является администратор БД. Его работа заключается в создании самой БД и техническом контроле, необходимом для осуществления решений администратора данных.

Между собственно БД (т. е. данными) и пользователями располагается уровень программного обеспечения — система управления базой данных. Все запросы пользователей на доступ к БД обрабатываются СУБД.

СУБД важный, но не единственный компонент программного обеспечения ИС. Среди других — упомянутые выше бизнес-приложения, утилиты, CASE-средства, генераторы отчетов и форм и т.д.

Технические средства информационных систем могут включать:

Ø средства вычислительной техники (серверное оборудование, рабочие станции, принтеры и т.д.),

Ø локальные вычислительные сети,

Ø копировально-множительную аппаратуру,

Ø средства свя­зи (учрежденческие АТС, каналы связи и канальное оборудование, телефоны, факсимильные аппараты, мобильные средства связи).

VI. Структура программного обеспечения ИС.

ПО ИС состоит из нескольких взаимосвязанных частей, каждая из которых выполняет определенную функцию и определяет в системе заданное свойство. Выделяются следующие блоки:

Ø обеспечение управления

а) Управляющий блок содержит элементы, обеспечивающие управление системой и технологию работы отдельных приложений. Этот блок представляет собой администраторскую и управляющую часть.

Ø обеспечение бизнес-процессов

б) Конвейерный блок - содержит элементы, составляющие группы решения, обеспечивающих производственный цикл работы ИС

в) Учетный блок - содержит элементы, обеспечивающие учетные функции системы.

VII. Жизненный цикл АИС.

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

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

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

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

Поэтапная модель с промежуточным контролем. Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

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

VIII. Этапы универсального процесса разработки ПО.

Программы небольшого и среднего размера (несколько тысяч строк) создаются, как правило, в два этапа. Сначала необходимо точно установить, что надо сделать, продумать соответствующий алгоритм, определить структуры данных, объекты и взаимодействие между ними (это этап системного анализа), а затем выразить этот алгоритм в виде, понятном машине (этап кодирования). Если же разрабатывается крупный проект объемом от десятков тысяч до миллионов строк кода, тогда приходится применять специальные методологии проектирования, охватывающие период разработки ПО.
Период разработки ПО
Рассмотрим классический период разработки ПО.
1. Формируются и анализируются требования к проекту. Этот этап самый важный, так как неправильное формулирование требований приводит к выполнению ненужной работы, а недооценка сложности вызывает перерасход средств и времени. Сегодня около 60 % крупных проектов завершаются неудачей именно из-за ошибок на стадии подготовки требований.
На основе требований по различным методикам определяется примерный объем проекта и его трудоемкость, рассчитываются будущие трудозатраты и определяется его стоимость. Так как требования к проекту во время работы над ним могут уточняться и меняться, а выполнение требований надо отслеживать, применяются специальные программы для управления требованиями.

Часто заказчик не в состоянии точно выразить, чего он хочет, и задача специалистов по системному анализу — помочь ему выразить свои требования в виде, пригодном для формализации. После согласования требований подписывается контракт на разработку ПО. В дальнейшем любые отклонения от сформулированных требований к продукту (как со стороны заказчика, так и со стороны исполнителя) рассматриваются как нарушение контракта.
Каждый этап требует от заказчика вложения собственных трудозатрат и привлечения высокопрофессиональных специалистов, поэтому он обязательно должен оплачиваться—бесплатно выполнять сложную работу никто не будет. Однако, хотя первый этап самый важный, заказчик редко понимает эту важность и не готов платить достаточно большие суммы. Примерный объем работ на этом этапе — 5 % от объема всего проекта.

2.Начинается предпроектное обследование объекта автоматизации. С помощью CASЕ-средств составляется формальная модель его работы, модель базы данных, объектов и потоков информации. На этом этапе привлекаются специалисты заказчика и эксперты, хорошо знакомые с предметной областью, для которой составляется задача. Примерный объем работ второго этапа — 10 % от общего.

3.На основе формальной модели составляется подробное техническое задание для программистов, спецификации отдельных модулей, таблицы баз данных, другая сопроводительная документация. Готовится подробный календарный план работ, где указываются все сроки, конкретные исполнители и выполняемые объемы работ (понедельно, помесячно). Для составления планов работ имеется немало хороших программ, ориентированных как на небольшие группы программистов, так и на коллективы из сотен сотрудников, выполняющих тысячи различных работ в рамках общего плана. Примерный объем работ третьего этапа — 10 % от общего.

4.Выбирается методология разработки ПО и начинается разработка (кодирование). Крупные компании имеют собственные методологии, ориентированные на конкретные задачи (как правило, это задачи автоматизации предприятий), однако все методологии имеют общие черты и более-менее серьезно различающихся известно около двух десятков.

Мы коснулись, в частности, методологий структурного (нисходящего) и объектного проектирования. Хотя объектный подход, безусловно, один из самых передовых, он подразумевает высокую квалификацию всех исполнителей без исключения и поэтому распространен не очень широко.

Достаточно популярна методология итерационного проектирования, ориентированная на использование RAD-средств и систем автоматической генерации исходных текстов на основе созданной формальной модели. Такой подход хорош тем, что позволяет быстро создать первый работающий прототип программы, когда еще требования к ней окончательно не определены, а в дальнейшем, на следующих итерациях (их обычно требуется от двух до пяти), постепенно детализировать и реализовывать конкретные возможности, пропущенные по каким-то причинам на предыдущей итерации. Эта методология немного отличается от нисходящего проектирования тем, что применяется, когда окончательные требования неизвестны и могут меняться, а основные работающие функции нужны заказчику как можно быстрее (заказчик чаще хочет получить приложение, законченное на 80 %, сегодня, чем законченное на 100 % завтра). При нисходящем проектировании основная структура задачи должна быть определена заранее.

Принятие решения о выборе подходящей методологии — очень ответственный процесс. Человек, принимающий такое решение, должен обладать богатым опытом и знаниями в области создания ПО. Многое зависит от инфраструктуры заказчика — какие у него компьютеры, операционные системы, каковы их ресурсы. В соответствии с этим выбираются и средства разработки. Иногда бывает, что лучше всего подходит, например, итерационная методология, но для операционной системы заказчика нет хорошей RAD-среды, и приходится остановиться на менее эффективной методологии.

В процессе разработки необходимо:

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

Ø непрерывно контролировать ход работ в соответствии с планом и при отклонениях от него принимать экстренные меры.

Примерный объем этих работ — 10 % от общего объема проекта.

5.Когда программа закончена (готова работоспособная альфа-версия), она поступает к тестерам компании-исполнителя, которые начинают проверять ее на наличие ошибок и сообщать о найденных ошибках программистам. Анализируется, в частности, устойчивость работы программы при вводе недопустимых или критических значений, при отсутствии информации, при неверных действиях, при сбоях аппаратуры, в стрессовых режимах и т. п. Когда число ошибок, выявляемых за определенный срок (неделя, месяц), снижается ниже экспериментально подобранного уровня (на основе аналогичных проектов), начинается бета-тестирование программы у заказчика. К такому тестированию привлекается максимально возможное число сотрудников, и программа уже начинает частично функционировать в рабочем режиме. Примерный объем этих работ — 10 % от общего объема проекта.

После того как заказчик удовлетворен качеством продукта, начинается его внедрение — подготовка к окончательному запуску в эксплуатацию. Если приложение многопользовательское, нередко требуется сформировать и настроить локальную сеть, установить серверы, инсталлировать вспомогательные программы. Очень много проблем возникает при переходе со старых программ (например, бухгалтерского учета, расчета зарплаты, работы с персоналом), которые создавались разными сотрудниками и покупались в разных фирмах (так называемая лоскутная автоматизация), к новой интегрированной системе. Необходимо выверить, ввести или перенести множество жизненно важной информации: всю бухгалтерскую и финансовую отчетность, данные о хранимом оборудовании и множество других сведений. Этот этап самый трудоемкий и «нудный» и занимает порой до 90 % времени всего проекта. Для систем автоматизации больших предприятий он растягивается на годы.

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

Примерный объем трудозатрат на обучение — 5 % от общего объема проекта.

8. После того как заказчик подписывает акт приемки, проект считается завершенным, но связь с исполнителем не теряется. Особенно в первое время у пользователей системы постоянно будет возникать множество вопросов по работе с ней. Неизбежно и возникновение ошибок, которые требуется устранять. Кроме того, исполнитель может выпускать новые версии системы, и старая система потребует обновления. Сотрудничество с заказчиком по обслуживанию системы называется сопровождением. Оно бесплатно на определенный гарантийный срок (например, год).

Реально объем непосредственного программирования и отладки (тестирования) в цикле разработки невелик. Он составляет 10-20 % от общего объема работ.


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  


3

Сейчас читают про: