35466

Проектирование информационных систем

Шпаргалка

Информатика, кибернетика и программирование

Суть: описание обработки потоков данных с определением их переходов от функции к функции хранения внешних обменов. Любая реализация накопления и хранения данных. Построение модели: 1 определение общих данных 2 построение контекстной диаграммы м. 4 Описание: составляются спецификации действий и данных.

Русский

2013-09-15

701 KB

1 чел.

  1.  Стадии проектирования ИС

ЖЦ – период времени от принятия решения о необходимости создания ИС до снятия ее с эксплуатации  

Стадия – часть ЖЦ, ограниченная некоторыми временными рамками и заканчивающаяся переходом ИС к новому состоянию.

Анализ, проектирование, реализация, использование.

Вся разработка делится на стадии. Стадии делятся на этапы.

ГОСТ 34.601-90 – Автоматизированные системы (АС) в стадии создания:

  1.  Формирование требований:
    •  обследование объекта – определяется качество текущего функционирования имеющейся проблемы;
      •  формирование требований - определяются общие требования и требования пользователей;
      •  обоснование целесообразности – оценивается целесообразность системы;
      •  оформление отчета и заявки на разработку С.
    1.  Разработка концепции:
      •  углубленное изучение объекта;
      •  определение возможных вариантов разраб-ой С.;
      •  оценка вариантов и выбор оптимального;
      •  оформление отчета со списанием концепций разработки и ее обоснования;
    2.  Техническое задание – разработка и утверждение ТЗ.
    3.  Эскизный проект – принятие предварительных решений и оформление документации.
    4.  Технический проект:
      •  детализация проектных решений;
      •  разраб-ся документация на получение решения;
      •  оформление документации на приобретение выпускаемых комплектующих или ТЗ на разработку новых комплектующих сторонними организаторами;
      •  разраб-ся документация  на проведение сложных работ (строительно-монтажные и другие виды работ);
    5.  Рабочая документация:
      •  реализация БД и ПО;
      •  разраб-ся документация на ввод и эксплуатацию;
    6.  Ввод в действие:
      •  Подготовка объекта к автоматизации. Подготовка персонала;
      •  Монтажные, строительные работы;
      •  Пуско-наладочные работы;
      •  Опытная эксплуатация. Приемочные испытания.
    7.  Сопровождение – включает выполнение гарантийных обязательств и послегарантийное обслуживание.


2. Модели жизненного цикла ИС.

ЖЦ – период времени от принятия решения о необходимости создания ИС до снятия ее с эксплуатации.

Модель определяет раскладку во времени, стадии и этапах.

Основные модели:

1) Основная модель – каскадная модель (последовательная, модель «водопада»):

-логическая последовательность стадии

Стадии и этапы выполняются последовательно. Результат этапа – завершённый продукт и полная документация.

«+»: 1)простота планирования и контроля; 2)однократность оформления результатов, полная определённость по предыдущим этапам..

«-»: 1)необходимость полного определения и фиксации всех требований в начале проекта; 2)нет равномерности загрузки исполнителей; 3)большое время запуска, фиксированность результатов.

Для возможности частичных улучшений используется каскадная модель с возвратом (возможен возврат на предыдущий уровень стадии для учета изменений):

2) спиральная модель – разработка выполняется по спирали, каждый виток новая версия или фрагмент.

Два варианта:

 1)Инкрементная модель:

Весь продукт делят на очереди и реализуют.

«+»: Улучшился график загрузки исполнителей и срок ввода в действие.

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

    2)  Эволюционная модель (спиральная)

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

Кроме основных моделей ЖЦ могут использоваться смешанные, которые включают черты нескольких основных моделей. Могут добавляться в цикличную спиральную модель итерации, аналогичные представленным типам.

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

Для конкретных проектов выполняется адаптация типовой модели ЖЦ, уточняется содержание стадий этапов, м. добавляться или удаляться отдельные этапы.


3. Процессы жизненного цикла ИС

ЖЦ – период времени от принятия решения о необходимости создания ИС до снятия ее с эксплуатации. Жизненный цикл можно разделить на процессы. Содержание процессов ЖЦ ИС основывается на ГОСТ Р ИСО/МЭК 12207-99 «ИТ процесса ЖЦ ПО».

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

Процессы ЖЦ делятся на 3 группы:

  1.  основные;
  2.  вспомогательные;
  3.  организационные.

Основные процессы (процессы разработки и использования):

1)Заказ выполняется заказчиком:

Подготовка - определение необходимости, выделение требований, выбор способа достижения; Заявка - формулировка требований, направление претендентов, направление заявки; Договор - определение критерия и выбора поставщика, заключение договора; Надзор – выполнение совместного аудита; Приемка – проведение приемных испытаний, закрытие договора.

2)Поставка используется поставщиками. Возможность привлечения 3их лиц.

Подготовка, ответ на заявку; заключение договора и планирование его исполнения; исполнение и контроль; проверка и оценка; поставка и закрытие договора.

3)Разработка: связана с созданием продукта

подготовительные работы; определение требований; архитектура С; определение требований к ПО; архитектура ПО; детальное проектирование; изготовление и отладка, интеграция ПО; квалифицированное тестирование ПО; интеграция С; квалифицированное тестирование С; установка; приемка

4)Процесс эксплуатации

Подготовка; пробная эксплуатация; Эксплуатация; Поддержка пользователей

5)Процесс сопровождения: Предварительные работы; контроль изменений, внесение изменений, проверка изменений, перенос, снятие с эксплуатации.

Вспомогательные процессы: (выполняются для поддержки качества и надёжности основных процессов)

1) документирование 2) управление конфигурацией (способ обозначения элемента, способ учёта изменений, история изменений)3) управление качеством

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

5) аттестация(желательно независимым экспертом)- соответствие С требован.

6)совместная проверка – проверка одной из сторон другой, проверка сроков

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

8)разрешение проблем.

Организационные процессы:

1)управление ходом процессов; 2) создание инфраструктуры (сеть, БД, компы БД); 3)усовершенствование;  4)обучение разработчиков, пользователей


4
. Общая схема проектирования ИС

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

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

Проектирование – это выполнение совокупности взаимосвязанных, упорядоченных во времени, объединенных стадий и этапов работ, необходимо и достаточно для создания ИС, удовлетворяющей заданным требованиям.  

Особенности проектирования:

  1.  многокомпонентность
  2.  учет преемственности (если имеются унаследованные системы) – проектирование «снизу-вверх» и «сверху-вниз»
  3.  ориентация на конечного пользователя
  4.  большой объем и сложность С.
  5.  Высокая типизация средств и решений

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

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


5
. Стандартизация проектирования  

Цель стандартизации:

  •  Ускорение разработки
  •  Повышение надежности
  •  Стабилизация показателей разработки (сроки, стоимость и т.д.)
  •  Упрощение внутреннего и внешнего обмена
  •  Повышение стабильности
  •  Упрощение поддержки, сопровождения, эксплуатации, модификации и масштабирования

Основные позиции стандартизации:

  1.  стандартизация жизненного цикла.
    1.  станд-я основных процессов проектирования: моделирования, разработки.
    2.  станд-я вспомогательных процессов: документирования, управление конфигурациями, управления качеством, решение проблем и процедуры их решения

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

1) международные стандарты

2) национальные стандарты

3) отраслевые стандарты (ОСТ, стандарты де-факто)

4) стандарты предприятия (разрабатываются и применяются на конкретном предприятии)

5) нормативные документы (характер м.б. директивный, указывающий, рекомендательный)

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

Уровни:

1)типовые элементы (типовые решения для отдельных задач)

+гибкость проектирования, min избыточность

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

2)подсистемные типовые решения (тиражируемые решения для группы взаимосвязанных задач)

+проверка реализации работы для целого подразделения или группы лиц

–м.б. проблемы интеграции с другими продуктами

3)системное типовое решение (охватывает деятельность организации)

–большая избыточность, возможность несоответствия принятым процессам, высокая стоимость настройки


6
. Документирование проектирования 

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

Управление документированием определяется стандартом ГОСТ Р ИСО/МЭК ТО 9294-93  «информационная технология, руководство по управлению документир-ем ПО» Документация к проектированию.

Функции документирования:

1) И для управления (планы и контроль, отчеты); 2) продержка связи;

3) поддержка качества; 4)инструкции и подсказки (хэлп для пользователя);

5) поддержка сопровождения (для тех персонала как вести себя при поломке, расширение в процессе эксплуатации, версии).

Для управления документированием необходимо:

  1.  требования к типам документов

- документы продукции; эксплуатационная документация (хэлп); документы управления;  - требования к качеству документа; - формат документа, бланки; -способ обозначения документа.

  1.  Определяются процедуры проектирования, их полный перечень:

Каким образом ведется документирование (обязанности, взаимодействия, последствия, процедуры): планирование, подготовка, проверка, утверждение, изготовление, хранение, дублирование; распространение документа; управление конфигурацией: история изменения  документа.

  1.  Определение ресурсов для документирования:
  •  персонал - те, кто производит, тиражирует, кто ответственный;
  •  средства документирования: какие используются технические средства;
  •  финансы (за счет чего финансироваться): в состав разработки и отдельные;
  1.  План документирования – способ реализации документа:

Дополнительные стандарты, закрывающие отдельные стандарты:

  1.  ГОСТ Р ИСО/МЭК 15910-2002 «ИТ. Процесс создания документации пользователя ПС» описывается структура процесса, требования по стилю документирования, составление плана документирования
  2.  ГОСТ 34.601-90 «АС. Стадии создания»:
  •  на стадии формирования требований оформляется отчет и тактико-ТЗ;
  •  на стадии разработки концепции – отчет о проделанной работе;
  •  ТЗ;
  •  эскизный проекта;
  •  технический проект;
  •  рабочий документ – набор документов по:
  1.  ГОСТ 34.201-89 «Виды. Комплектность обозначения документов при создании АС» (ввод в действие) указывается виды документов по стадиям создания С. Явно указывается документ, либо ссылка на документ.
  2.  РД 50-34.698-90 «АС, требования к содержанию документов» описывается структура и содержание видов документов указанных в 201 стандарте.
  3.  РД 50-34.602-89 «АС, тех. задание на создание АС».


7
. Case-средства

Case-средства – это программные средства, автоматизирующие процессы ЖЦ программного продукта.

Основные автоматизируемые задачи: 1) анализ, 2) создание проектных моделей, 3) реализация ПО, тестирование, управление конфигурацией, управление проектами, управление инфраструктурой, документирование.

Характерные особенности Case-средств:

1. Мощная графика; 2. Использование шаблонов, 3. многопользовательская работа, 4. Использование репозитория для накопления проектных решений.

Наиболее распространенные Case-продукты:

SILVERRAN – автоматизация проектирования.  Имеются:

  •  Модуль разработки бизнес-процессов.
  •  Модуль концептуального проектирования БД.
  •  Модуль реляционного проектирования.
  •  Репозиторий проекта

ALL Fusion Suite (BPWIN+ERWIN) – наиболее распространен в России

ORACLE DESIGNER + DEVELOPER

Функциональное проектирование и проектирование БД, разработка приложений

Rational Rose – пакет для объектно-ориентированного программирования, основана на UML. Позволяет разрабатывать и связывать разные виды диаграмм.

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

Rational Requisite Pro – для анализа исходной информации

Rational Test Studio – для тестирования

Rational Clear Case – управление конфигурацией

Rational SoDA – документирование

Time Line, Open Plan – управление проектами

Внедрение case-средств

«-»: 1) сложность выбора; 2) большая стоимость; 3) длительный срок окупаемости; 4) моральная неготовность персонала, 5) сложность освоения и использования, 6) возможна несовместимость с характером, масштабом проектов, с программно-аппаратной платформой

«+»: 1)повышение производительности 2) повыш надёжности 3) повыш предсказуемости


8. Структурный подход к проектированию ИС

Основная идея: последовательная иерархическая декомпозиция до требуемого уровня детализаций функций.

Методики: IDEF0, IDEF3, DFD. Общее – иерархич.декомпозиция ф-ии. Ф-ия представляется набором более мелких подф-ий. Разное – разл.в наборе эл-в, способах связывания и декомпозиции. Методология IDEF0. Отображает предметную область как набор операций обработки, связанных физическими или информационными объектами.

Элементы: 1. Функциональный блок – обозначает действие над объектами.

2. Стрелки. Потоки связанные с блоком. Виды связей: Выход – обозначает поток, явл-ся рез-м действия. Вход – поток, перерабатываемый в выход. Упр-е – инф-я или объекты, определяющие исполнение действия (отличаются долговременносью и неизменностью). Механизм – опред-т исполнителя операции. Вызов  – для обеспечения коллективной работы.

Особенности IDEF0: жесткая привязка связей разного типа к блоку.

Порядок построения модели: 1) Определение общих сведений: описание содержания, цель разработки, определение масштаба проекта, аудитория. 2) Разработка контекстной диаграммы. Система представляется одним блоком. 3) Выполнение последовательной декомпозиции. 4) Описание элементов модели.

Возможна разработка модели двух видов: 1) AS-IS – описывает функционирование в текущем виде. 2) TO-BE – описание желаемого.

При декомпозиции желательно, чтобы ф-ии в блоке были сильно связаны: Функцион-я связь, Последов-я, Коммутац-я, Процедурная, Временная, лог-я,случайная.

Методология IDEF3. Суть: отображение действий в порядке их возможного следования во времени. Основа работы – событийное срабатывание функции.

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

Элементы: 1. Блоки (указывают действия). 2. Стрелки (указывают временную последовательность). Типы стрелок: временная, объектная (с передачей результата), логическая (предъявляется условие)

3. Логика поддерживается элементом перекрёсток (X, O, &).

4. Указатель может использоваться для указания на ранее описанный блок, на переход на другой блок, на заранее описанный объект, заметка на уточнение действий, заметка на действие логики. Построение модели: (см. IDEF0), но декомпозиция может быть обычная и множественная

Использование IDEF3 – в основном как уточнение к IDEF0. Также можно использовать как основу имитационного моделирования.

Методология DFD. Суть: описание обработки потоков данных с определением их переходов от функции к функции, хранения, внешних обменов.

Элементы: 1. Блок – описывает узел обработки, процесс. 2. Стрелка. Обозначает поток Д. М/б 1напр-е → и 2направл-е ↔. 3. ХД. Любая реализация накопления и хранения данных. 4. Внеш.сущность – любой внеш.источник или получатель И. Прямая связь между внешней сущностью и хранилищем в подавляющем случае недопустима → реализация через контроль. Построение модели: 1) определение общих данных 2) построение контекстной диаграммы (м.б. иерархия) 3) декомпозиция (обычная и множественная). Особенность: возможность переноса в декомпозицию внешних сущностей и хранилищ. 4) Описание: составляются спецификации действий и данных.


9. Объектно-ориентированный подход к проектированию ИС

Принцип – объектная область, представляется набором объектов различных типов. Разные типы описываются как классы. Деятельность предметной области описывается как взаимодействие объектов. Взаимодействие осущ. посылкой сообщений от объекта к объекту. Объектный подход стандар-н UML. Определяет набор диаграмм для описания проектируемой системы, правила использования и последовательность разработки.

Достоинства: Упрощение созд-я и модиф-и сл.систем, Возм-ть многократ.исп-ия накапливаемых решений, Ограничение сложности при создании фрагментов.

Недостатки: Большие начал.трудозатраты, Слож-ть для соглас-я с заказчиками.

Последовательность разработки:

1. На шаге анализа выполняется опред-е функц-ти с помощью диаграммы вариантов. Для уточнения функц-ия некоторые варианты могут поясняться диаграммой деятельности. По функц-нию составляется начальная диаграмма классов.

2. На шаге спецификация уточняется поведение системы и атрибутов класса

3. На шаге проект-я вып-ся уточнение до полного проектного решения. Производится уточнение работы классов с пом.диаграммы взаимод-я. Для классов со сл.поведением опред-ся диаграмма состояний. По полученным рез-м расширяется состав атрибутов класса. Добавляются операции классов. Получается полная проектная диаграмма классов.

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

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

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

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

В названии может быть указан стереотип: <<entity>> - основной объект предметной области, <<boundary>> - граничный класс, <<control>> - управляющий класс.

Классы видимости: <<package>> - пакетный атрибут, <<public>> - открытый атрибут, <<private>> - закрытый атрибут, <<protected>> - защищенный атрибут.

Класс предметной области связывается по нескольким типам: 1. Ассоциация. Описывает связь между экземплярами классов. 2. Агрегация и композиция указывают, что экземпляр класса А как составная часть входит в экземпляр класса В. 3. Обобщение. Указывает, что один класс является наследником другого. 4. Зависимость. Один класс в своем определении использует ссылки на другой класс.

Диаграмма взаимодействия. Показывает послед-ность выполнения действий классами для решения задачи. 2типа:

1) Диаграмма последовательностей. Описывает временную последовательность исполнения одного варианта использования. Решение задачи рассматривается как последовательность обмена сообщениями (вызов одним объектом метода другого объекта)

2) Кооперативная диаграмма. Сообщение не раскладывается по времени, а кооперируется по связям объектов.

Диаграмма состояний. Описывает динамику изменения состояния для одного класса в различных вариантах использования. Эл-ты: начальное состояние, состояние, переходы, конечное состояние. Типы действий: entry - действие, вып-ся при входе в состояние; do - действие, вып-ся при нахождении в состоянии; exit - действие, вып-ся однократно при выходе из состояния. Для состояний м/б указано: событие [условие] / действие. Событие показывает событие, по которому инициализируется выход из состояния, условие показывает требования, при котором допустим переход, действие выполняется при переходе.


10. Концептуальное, логическое и физическое проектирование данных.

Концептуальное проектирование:

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

По требованиям к данным создаётся абстрактная структура хранения. Сод все данные. Формат не связан с последующей реализацией.

Результат – графическое изображение и  спецификация элементов.

Шаги выполнения:

1. Определение сущностей и связывание внутри объектов.

2. Определение связей.

3. Определение атрибутов.

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

Логическое проектирование:

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

Шаги выполнения:

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

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

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

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

Физическое проектирование:

Решаются следующие задачи:

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

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

3)Создание дополнительных объектов БД

4)Реализация ограничений целостности

5)Определение средств, процедур, методов для повышения надёжности хранения данных. Это резервирование, восстановление, зеркалирование.

6)Управление доступом. Определяются группы, роли и права.

7)Создание представлений.


11. Разработка пользовательского интерфейса

1) Соответствие представлениям пользователя. 3 модели поведения системы: ментальная – описывает ожидание пользователя, декларативная – то, что предъявляет интерфейс, модель реализации – что на самом деле происходит

2) Учет уровня пользователя:

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

3) Минимизация труда пользователя (для уменьшения числа действий): минимизация умственных затрат, исключение повторного ввода, замена ввода выбора, выполнить программно всё, что можно сделать автоматически.

4) Согласование с заказчиком. Формы согласования: рисунок, прототип (визуальное представление без реализации функциональности), спецификация.

5) Определение достаточного объёма поддержки пользователя: встроенная и внешняя (пассивные, реактивные, активные).

Общая архитектура. Выбирается основной стиль интерфейса:

1. Классический (главное окно с главным меню, из меню открываются доп. подчинённые окна).

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

3. Проект (главного окна нет, при запуске - меню, возможно с инструментальной панелью, из них вызываются прочие части приложения)

4. Проводник (2 части: навигатор, информационная часть)

5. Блокнот (содержит набор вкладок)

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

Представление Д

1) Отображение Д в табл.форме, в записной, смешанный.

2) Отображение данных в нескольких таблицах. 1:1, 1:М (ведущая таблица дочерняя или родительская). М:М.→ две части 1:М.

Выбор элемента (рекомендации):

  1.  Представление лог-х Д: Индикатор (флаг), кнопка фиксации,
  2.  Выбор одного значения: радиокнопки, списки (Combo), выпадающие списки,
  3.   Выбор нескольких: индикаторы (фиксированный набор), список с отметками (List), сопряженные списки, таблица с отметками.
  4.  Представление числовых данных: текстовое поле, спинер, движок
  5.  Представление дат: специальные элементы, вывод в текстовом формате, вывод в нескольких числовых полях
  6.  Вызов внешнего редактора


12. Проектирование файл-серверных архитектур

БД на общедоступном узле, всё ПО и обработка на рабочих местах. К БД обращение выполняется на файловом уровне.

«+»: 1) простота масштаб-ия из лок. системы; 2)простота тех.оборудования;

3)простота разраб. и поддержки; 4)дешёвые средства разработки и реализации.

«-»: 1) большая загрузка сети; 2)повышенные требования к клиентским местам; 3) низкий уровень поддержки орг-ии  управления данными (многопольз.доступ, НСД). Решение: пароль на ОС, доступ через приложение с паролем.

Предпосылки применения:

  1.  наличие локального варианта;
  2.  поддержка работы малых групп (до 10 раб. мест);
  3.  малая конфликтность между рабочими местами (если система справ-я, инф.поисковая с малым объемом поиска, системы с разделением областей Д-х, системы с разделением функциональности);
  4.  средства разработки:

    Основные – инструменты персональных систем(Access, VisFoxPro, Uarion)

   Неосновные:

  •  универс. языки программ-я;
    •  универс. инструмен-е среды разработки приложений БД(C Builder, C++, VisBasic, VisC++);
  1.  поддержка многопользовательского доступа;

 На примере VisFoxPro:

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

  •  Установка монопольного или разделяемого режима

  •  Установка блокировок при совместном доступе: по установке блокировок - автом-ая; по объему – запись, заголовок таблицы, таблица целиком.

Автоматическая блокировка - устан-ся СУБД при выполнениии опред-х команд

Insert(блокир-ся вся таблица), Append(блок. заголовок таблицы), Delete(блок-ся 1 или несколько записей в завис-ти от условия отбора).

Автоблокировка снимается при выполнении команды.

Ручная блокировка – вып-ся в явном виде с пом. набора команд:

RLOCK() – блокировка записи; FLOCK() – блокировка таблицы;

UNLOCK() – снятие блокировки по текущей таблице;

UNLOCK ALL – снятие всех блокировок.

  •  Поддержка транзакций

BEGIN TRANSACTION,ROLLBACK,END TRANSACTION


13. Проектирование централизованных клиент-серверных систем

Данные хранятся в едином месте на выделенном сервере, доступ через СУБД.

2х уровневая:

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

1)Сервер удалённого доступа. На сервере выполняются только базовые функции. Каждая SQL команда обрабатывается отдельно.

«+»: разгрузка сети; снижение требований к рабочим местам.

«-»: повышенные требования к серверу, раздельно обрабатывается каждая команда, реализуется только обработка SQL команд.

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

«+»: централизация общего программного кода, уменьшение числа передач по линии связи

«-»: увеличение нагрузки на сервер, снижение мобильности

3х и более уровневая архитектура

Вводится промежуточный сервер – сервер-приложений.

«+»: снижение требований к РМ и серверу, централизация основной части обработки, снижение числа соединений к серверу.

«-»: усложнение организации, снижение надёжности

Технологии обмена между уровнями:

1) Через API-интерфейсы

На РМ помещается библиотека API. Приложение обращается к функциям API для подачи команд на сервер.

+ возможность получения макс эфф-ти

- сложность программ-я, отсутствие мобильности

2) Методы, определённые в стандарте SQL (встроенный);

+мобильные приложения, более легкое прогр-е

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

3)стандарт обмена с БД – ODBC

+универсальность приложения

-низкие врем хар-ки, большие затраты памяти.

4) объектные технологии IBX

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


14. Распределенные ИС, способы организации и обработки данных

Распределённая система – это система, позволяющая работать с распределенной БД и обеспечивающая полную или частичную прозрачность распределенности Д.

Распределённая БД – набор связанных м/у собой разделяемых данных физически распределённых в компьютерной сети.

Особенности распределенной системы: распред-е Д лог-ки связаны, БД м/б разделена на части, БД или фрагменты м/и копии (реплики), фрагменты и реплики распределены по узлам сети, на серверах м/вып-ся лок.и глоб.прил-я, каждый узел работает под упр-ем СУБД, каждый узел д/участвовать хотя бы в 1 глоб.прил-ии, на серверах м/автономно вып-ся лок.прил-ия, узлы соединены линиями связи.

Осн.принцип: распред-я система с т.зр.польз-ля д/вести себя как нераспред-я.

Для распределенных систем выполняются следующие правила Дейта: 1. лок-я автономность, 2. отсутствие фиксир-х центральных узлов, решающих общие задачи, 3. непрерывность работы, 4. независ-ть от фрагм-ции Д, репликации Д, места распол-я, 5. поддержка вып-ия распред-ых запросов, 6. поддержка вып-ия распред-х транзакций, 7. независимость от оборуд-я, ОС, сети, СУБД.

Организация работ с распределёнными БД

1) Системы с глоб-й лок-й схемой                2) Системы с частичной глоб-й схемой

Недостатки 1й схемы: хранение общих данных, ненадежность узла, загрузка узла.

3 части глобальной схемы.

Во 2й схеме: к лок-й схеме могут обращаться свои пользователи. В глобальной части, в основном, выполняются запросы, в локальной – изменение данных.

3) Системы, слабо связанные, без глобальной схемы.

1 – утилита доступа. 2 – програм-й шлюз. Запускает на СУБД типовую операцию, либо вызывает операцию и перебрасывает туда Д.


15. Распределение данных. Фрагментация, репликация

Фрагментация – это разделение данных на 2 или более непересекающиеся части.

М.б. на уровне базы, распределяются таблицы. И на уровне таблиц, распределяются части таблиц.

Требования к фрагментации:

  1.  Полнота. Каждый элемент должен войти хотя бы в один фрагмент.
  2.   Непересекаемость: кажд.эл-т д/входить только в 1 фрагмент.
  3.  Восстан-сть: д/сущ-ть процедура точного восстановления базы по фрагментам.

Существуют следующие варианты фрагментации:

  1.  Горизонтальная – таблица делится на подмножества картежей. Фрагм-я вып-ся операцией огран-я по выбранным усл-ям, а дефрагм-я – операцией объединения.
  2.  Вертикальная фрагментация – таблица делится на подмножества атрибутов.

3. Смешанная фрагментация.

4. Производная фрагментация – фрагментация дочерней таблицы в соответствии с фрагментацией родительской таблицы.

Общая последовательность фрагментации:

  1.  Фрагментация по таблицам;
  2.  Определяются нефрагментируемые таблицы;
  3.  Вып-ся фрагментирование основных разделяемых таблиц;
  4.  Производное фрагмент-е подчинённых таблиц.

Репликация – это создание и ведение копий БД или фрагментов (ее частей).

Варианты репликации:

1. По моменту исполнения:

  •  Синхронная. Обновление в реплике вместе с обновлением исх-го варианта.
  •  Асинхронная. Обновление выполняется в отложенном режиме.

2. По масштабу репликации: полная и выборочная.

3. По форме исполения: моментальным снимком, транзакционное. При моментальных снимках полный объём всей основной реплики копируется в удалённые узлы. Транзакционные снимки: копируются только изменения данных. Репликация происходит время от времени.

4. По стороне инициализации: от подчиненной, от главной.

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

6. Принудительный вариант или по запросу. При принудительном варианте репликация выполняется по инициативе ведущего по заданному расписанию. Репликация по запросу выполняется по инициативе ведомого.

PAGE  5


 

А также другие работы, которые могут Вас заинтересовать

34838. Операционный и финансовый рычаги и риск инвестиционного проекта 43 KB
  Величина делового риска оценивается по величине операционного рычага или левериджа. Величина финансового риска зависит от финансового рычага левериджа. Сила воздействия операционного рычага вычисляется как отношение валовой маржи к прибыли после уплаты процентов но до уплаты налога на прибыль: ЭОР=ВМ П где ЭОР – эффект операционного рычага; ВМ – валовая маржа; П – прибыль после уплаты процентов но до...
34839. Инвестиции. Капитальные вложения. Классификация инвестиций 28.5 KB
  Классификация инвестиций Инвестиции – это денежные средства имущество и иные имущественные права ценные бумаги вкладываемые в объекты предпринимательской деятельности в иные объекты с целью получения прибыли или иного полезного результата. Капитальные вложения – это частный случай инвестиций инвестиции в основные средства предприятия. Классификация инвестиций: Тактические и стратегические инвестиции.
34840. Управление инвестициями в Российской Федерации 38.5 KB
  Элементами механизма реализации инвестиций является: Российская венчурная компания венчурные управленческие компании венчурные фонды инновационные предприятия. капитал → венчурные управленческие компании 100 частный капитал → венчурные фонды 5 частный капитал 49 гос. ОАО РВК на конкурентной основе утверждает ВУК венчурные управленческие компании которые в свою очередь учреждают венчурные фонды. Венчурные фонды вкладывают деньги в инновационные предприятия т.
34841. Предварительная оценка коммерческой привлекательности инвестиционного проекта 40 KB
  ценность проекта проверяется в 2 этапа: 1 предварительная экспертиза 2 основная экспертиза проекта Цель предварительной экспертизы – провести формальный и неформальный анализ окружения проекта выявить все угрозы и проблемы которые ожидают проект в будущем. Для этого формируются группы экспертов которые проводят тестирование проблем связанные с реализацией проекта. В результате тестирования машина рассчитывает рейтинг проекта она же вычерчивает профиль проекта.
34842. Основная оценка коммерческой привлекательности инвестиционного проекта 56.5 KB
  Финансовые показатели проекта рассчитываются по трем прогнозным формам: бух. Баланс составляется на первый год проекта помесячно второй год поквартально последующие года – годовые балансы. Из всех финансовых показателей наиболее важными для проекта являются показатели ликвидности и платежеспособности и показатели рентабельности.
34843. Жизненный цикл инвестиционного проекта. Матрица ответственности проекта 36 KB
  Матрица ответственности проекта Жизненный цикл проекта – это промежуток времени от момента начала финансирования проекта до момента утилизации основных средств проекта. Инвестиционный показывает продолжительность подготовительной и производственной стадии проекта. доходы 3 начало конец 1 годы затраты 2 1 – прединвестиционная фаза 2 – инвестиционная фаза 3 – фаза эксплуатации проекта На первой фазе разрабатывается бизнесплан это относительно небольшие деньги.
34844. Чистый денежный поток. Простой срок окупаемости капитальных вложений 49.5 KB
  Простой срок окупаемости капитальных вложений NCF = чистая прибыль амортизация основных средств и нематериальных активов отложенные налоговые платежи Обычно рассчитывают годовые денежные потоки. Если чистый денежный поток имеет знак то это означает что инвестор получает приток амортизации и чистой прибыли NCF. Если чистый денежный поток отрицательный NCF это означает что в проект инвестируются денежные средства либо инвестиции в капитальные вложения либо оборотные средства проекта. На величину NCF влияют отложенные...
34845. Простые методы оценки экономической эффективности капитальных вложений. Достоинства и недостатки 38.5 KB
  Достоинства и недостатки Среди простых методов оценки экономической эффективности капитальных вложений является расчет простых показателей а именно: простого срока окупаемости инвестиций и показателя прибыли на вложенный капитал. Простой срок окупаемости PP – это срок возврата инвестиций. нормативный срок окупаемости РР например если он установлен – не более 3 лет то все проекты со сроком окупаемости более 3 лет отвергаются. В общем случае они зависят: 1 от отрасли ее динамики развития например в электронике нормативы окупаемости...
34846. Дисконтирование и компаундирование денежных потоков. Схемы приведения денежных потоков 50.5 KB
  Дисконтирование и компаундирование денежных потоков. Схемы приведения денежных потоков. i – процентная ставка доходности инвестиций PV FV годы t = 1Т PV – Present Vlue – текущая настоящая стоимость денежных потоков FV– Future Vlue – будущая стоимость денежных потоков Для того чтобы сравнивать денежные потоки зафиксированные в разные моменты времени эти денежные потоки нужно...