Клиент Сервер

Сервер Клиент

БД и серверная часть Клиентская часть БД,

(СУБД и приложения) сетевой доступ, приложение

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

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

Рисунок. Тонкий клиент

Приложение, СУБД, БД

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

(сетевой доступ)

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

Преимуществами клиент – серверных архитектур по сравнению с файл – серверными являются:

1) ее масштабируемость и вообще способность к развитию;

2) возможность реализации качественной БД.

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

23. Архитектура распределенных систем. Архитектура ODBC. Проблемы проектирования распределенных систем. Тиражирование данных.

Распределенная архитектура - архитектура распределенных систем

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

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

2)открытость, т.е. возможность расширять систему путем добавления новых ресурсов;

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

3)параллельность – несколько процессов одновременно выполняются на разных компонентах сети, и эти процессы могут взаимодействовать друг с другом во время выполнения;

4)масштабируемость – систему можно наращивать посредством добавления новых вычислительных ресурсов. На практики наращивание ограничивается пропускной способностью сети;

5)прозрачность – пользователям представлен прозрачный доступ к ресурсам, но скрыта информация о распределении ресурсов в системе.

КС архитектура может быть не только двух (один сервер – много клиентов), но и трех уровневой.

Архитектура распределенных объектов.

В ней стираются различия между клиентом и сервером. Компонентами системы являются объекты. Они представляют набор сервисов через свои интерфейсы. Другие объекты вызывают эти сервисы, не делая различия между клиентом (пользователем сервиса) и сервером (поставщиком сервиса).

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

Существуют для поддержки распределенных объектов два основных стандарта промежуточного ПО:

1) CORBA(Common Object Request Broker Architecture) – архитектура брокеров запросов к общим объектам. Этот стандарт машинно не зависимый. Он поддерживается ОС Unix и Microsoft.

2) DCOM (Distributed Component Object Model) – объектная модель распределенных компонентов. Разработан и реализован Microsoft и применяется на её ОС.

Архитектура ODBC

ODBC– это интерфейс, который представляет ПП доступ к системам управления реляционными БД.

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

1)Диспетчера ODBC.

2)Драйверов ODBC.

Диспетчер ODBC предполагает единый интерфейс всем приложениям, работающим с БД. Он представляет собой набор функций, с помощью которых выполняются все задачи, связанные с СУБД. Интерфейс диспетчера ODBC одинаков независимо от того, с какой СУБД приложение будет взаимодействовать. Драйвер ODBC, напротив, зависит от СУБД. Диспетчер вызывает нужный драйвер. Драйвер преобразует запросы на обслуживание от приложений в запросы на языке конкретной БД. Каждая СУБД, поддерживающая технологию ODBC, должна предоставлять разработчикам приложений драйвер ODBC для этой СУБД.

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

24. Рабочий проект.

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

25. Внедрение, стадии (подготовка объекта к внедрению, опытное внедрение, сдача проекта в пром. эксплуатацию), методы (параллельный, последовательный, смешанный)

На стадии внедрения проекта проводятся подготовка и постепенное освоение разработанной проектной документации ИС заказчиками системы. В процессе выполнения работ на этой стадии выявляются недоработки в проектном решении.
Внедрение может осуществляться с использованием следующих методов:
* последовательный метод, когда последовательно внедряется одна подсистема за другой, и одна задача следует за другой задачей;
* параллельный метод, при котором все задачи внедряются во всех подсистемах одновременно;
* смешанный подход, согласно которому проектировщики, внедрив несколько подсистем первым методом, приступают к параллельному внедрению системы.
Недостатком первого подхода является увеличение длительности внедрения, что ведет за собой рост стоимости проекта. При использовании второго подхода сокращается время внедрения, но возникает возможность пропуска ошибок в проектной документации, поэтому чаще всего используют смешанный метод внедрения проекта ИС.
Внедрение проекта осуществляется в три этапа: подготовка объекта к внедрению; опытное внедрение; сдача проекта в промышленную эксплуатацию.
На этапе подготовки объекта к внедрению осуществляются следующие операции:
* изменяется организационная структура объекта (предприятия);
* набираются кадры соответствующей квалификации в области обработки информации и эксплуатации системы и сопровождения проектной документации;
* оборудуется здание под установку вычислительной техники;
* выполняются закупка и установка вычислительной техники;
* в цехах, отделах устанавливаются средства сбора, регистрации первичной информации и передачи по каналам связи;
* осуществляется установка каналов связи; проводится разработка новых документов и классификаторов;
* осуществляется создание файлов информационной базы с нормативно-справочной информацией.
На вход этого этапа поступают компоненты "Технического проекта" в части плана мероприятий по внедрению, решения по техническому и информационному обеспечению, технологические и инструкционные материалы "Рабочего проекта". В результате выполнения этапа составляется акт готовности объекта к внедрению проекта ЭИС. Затем формируется состав приемной комиссии, разрабатывается Программа проведения опытного внедрения и издается приказ о начале опытного внедрения.
Второй этап - опытное внедрение. На этом этапе внедряются проекты нескольких задач в нескольких подсистемах. В процессе опытного внедрения выполняются следующие работы:
* подготовка исходных оперативных данных для задач, которые проходят опытную эксплуатацию;
* ввод исходных данных в ЭВМ и выполнение запланированного числа реализаций;
* анализ результатных данных на предмет наличия ошибок.
В случае обнаружения ошибок осуществляются поиск причин и источников ошибок, внесение коррективов в программы, в технологию обработки информации, в работу технических средств, в исходные оперативные данные и в файлы с условно-постоянной информацией. Кроме того, выявляется неквалифицированная работа операторов, что служит основанием для проведения комплекса мер по улучшению подготовки кадров.
После устранения ошибок получают Акт о проведении опытного внедрения, который служит сигналом для начала следующего этапа.
На третьем этапе сдаче проекта в промышленную эксплуатацию используют следующую совокупность документов:
* договорная документация;
* приказ на разработку ЭИС; ТЭО и ТЗ;
* исправленный "Техно-рабочий проект";
* приказ о начале промышленного внедрения;
* программа проведения испытаний;
* требования к научно-техническому уровню проекта системы

26. Администрирование ИС.

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

Администрирование ИС – это её инсталляция (установка), управление доступом к ней, обеспечение целостности ИС и др.

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

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

Создание ИС включает следующие операции:

• создание новых файлов данных, или стирание данных, хранившихся в предыдущих файлах данных;
• создание структур, требующихся для доступа и работы с ИС;
• инициализацию управляющих файлов и журнала для ИС.

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

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

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

Прежде чем создавать ИС необходимо:

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

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

1. Установка и настройка сети.
2. Поддержка её дальнейшей работоспособности.
3. Установка базового программного обеспечения.
4. Мониторинг сети.

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

Функции и задачи администратора ИС
Администрирование ИС осуществляется лицом, управляющим этой системой. Такое лицо называется администратором.

Если ИС большая, эти обязанности могут выполнять несколько человек (группа администраторов).

Администратор ИС осуществляет её запуск и останов. Он может использовать табличные пространства для:

• управления распределением памяти для объектов ИС;
• установления квот памяти для пользователей ИС;
• управления доступностью данных, включая режимы (состояния) online или offline;
• копирования и восстановления данных;
• распределения данных по устройствам для повышения производительности.

В процессе своей деятельности администратор ИС взаимодействует с другими категориями её пользователей, а также и с внешними специалистами, не являющимися пользователями ИС.

27. Тестирование проекта на стадиях разработки требований и проектирования

Тестирование на этапе разработки требований

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

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

1. Сравнительный анализ

2. Дискуссионные группы и

3. Обследование объекта.

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

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

• Адекватны ли эти требования? Действительно ли именно такой продукт компания хочет создать?

• Полны ли они? Не упущены ли какие-нибудь еще полезные или даже жизненно необходимые функции? Нельзя ли ослабить какие- либо из перечисленных требований?

• Совместимы ли требования между собой? Требования к продукту (и его функции) могут оказаться логически или психологически несовместимыми. Логическая несовместимость означает их противоречивость, а психологическая — концептуальные разногласия (разоб­равшись с одной из функций, пользователь может не понять другую).

• Выполнимы ли они? Не требуется ли.для нормальной эксплуатации продукта более быстрое аппаратное обеспечение, больший объем памяти, более высокая пропускная способность, большее разреше­ние (и т.д.), чем указано в документации?

• Разумны ли они? К сожалению, качество продукта и его рентабель­ность стоят по разную сторону баррикад: с одной стороны — про­изводительность продукта, его надежность и нетребовательность к ресурсам, а с другой — время и стоимость его разработки. Найдено ли самое оптимальное соответствие между всеми этими характери­стиками? Не требуется ли от продукта абсолютная безупречность, молниеносная работа и готовность конкурировать с программным обеспечением, которого еще нет и в проекте? Отдельные из тих требований вполне достижимы, но не одновременно и не для одного и того же продукта. Поэтому одним из ключевых вопросов планирования является правильная расста­новка приоритетов.

• Поддаются ли они тестированию? Насколько легко можно будет определить, соответствует ли инженерно-проектная документация требованиям к программному продукту.

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

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

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

• Многие языки или системы разработки не подходят для создания быстрого и дешевого прототипа.

• Хороший совет: отложить первый черновик программы и начать ее разработку с чистого листа. Особенно это касается прототипа. Ведь от него не требуется хорошая внутренняя организация. Он может работать медленно и неэффективно, а то и вообще неправильно. Согласитесь, что такая программа не лучшая основа для хорошей разработки. Да и разработчики прототипа будут чувствовать себя гораздо свободнее, если будут думать только о скорости и не беспокоиться, что допущенные ими ошибки и неверные решения впоследствии затруднят программирование.

Дата добавления: 2015-04-24