35461

Информационные системы (ИС) и их проектирование

Шпаргалка

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

Особенности проектирования ИС: Наличие 4 основных компонентов системы: информация программы техника организационные средства. ЖЦ в общем случае включает: АНАЛИЗ: определяются требования и ограничения для предполагаемой системы ПРОЕКТИРОВАНИЕ: разработка проектной документации необходимой и достаточной для последующей реализации ИС удовлетворяющей поставленным требованиям и ограничения. РЕАЛИЗАЦИЯ: создание рабочей системы по проектным документам. ИСПОЛЬЗОВАНИЕ: работа конечных пользователей и поддержка рабочей системы группами...

Русский

2013-09-15

1.53 MB

20 чел.

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

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

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

  1.  Наличие 4 основных компонентов системы: информация, программы, техника, организационные средства. При проектировании эти компоненты разрабатываются параллельно и согласовано!!!
  2.  Наличие унаследованных систем и средств
  3.  Высокая степени типизации средств и решений (при разработке используются повторные решения)
  4.  Высокая ориентированности на пользователя

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

ЖЦ в общем случае включает:

  1.  АНАЛИЗ: определяются требования и ограничения для предполагаемой системы
  2.  ПРОЕКТИРОВАНИЕ: разработка проектной документации, необходимой и достаточной для последующей реализации ИС, удовлетворяющей поставленным требованиям и ограничения.
  3.  РЕАЛИЗАЦИЯ: создание рабочей системы по проектным документам.
  4.  ИСПОЛЬЗОВАНИЕ: работа конечных пользователей и поддержка рабочей системы группами эксплуатации (отдел или человек, контролирующие работоспобность) и сопровождения (необязательно люди орг-ции-заказчика, а те кто, ее разрабатывал).

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

Существует много вариантов раскладки ЖЦ на стадии.

Microsoft Solution

  •  Анализ
  •  Проектирование
  •  Разработка
  •  Стабилизация

Вендров

  •  Формирование требований
  •  Проектирование
  •  Реализаций
  •  Тестирование
  •  Ввод в эксплуатацию
  •  Эксплуатация
  •  Снятие с эксплуатации

Мацяшек

  •  Определение требований и спецификация требований
  •  Проектирование архитектуры и детальное проектирование
  •  Разработка и интеграция
  •  Эксплуатация и сопровождение

ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»

  1.  Формирование требований к автоматизированной системе

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

- определение требований пользователя к ИС (быстрота, надежность, стоимость)

- оформление отчета и заявки на разработку

  1.  Разработка концепции АС

- углубленное обследование объекта

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

- выбор обоснованного оптимального решения

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

  1.  Техническое задание

- разработка и утверждение технического задания

  1.  Эскизный проект

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

- оформление эскизной документации

  1.  Технический проект

- детализация проектных решений по системе и ее частям (функции персонала и организационной структуры, структура техн средств, организация и ведение инф базы, по ПО)

- оформление документации по системе и частям

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

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

  1.  Рабочая документация

- разработка рабочей документации по вводу и эксплуатации

- разработка и адаптация программ

  1.  Ввод в действие

- подготовка объекта к вводу АС в действие (реализация орг решений)

- подготовка персонала

- комплектация ИС прогр и техн средств

- выполнение смежных работ (стротельно-монтажных) и пусконаладочных работ (наладка прогр и техн средств, загрузка информации в БД)

- проведение предварительных испытаний и опытной эксплуатации

- проведение приемочных испытаний

  1.  Сопровождение

- гарантийное и послегарантийное обслуживание

1,2 – анализ, 3-5 – проектирование, 6-7 – реализация, 8 – использование

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

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

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

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

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

  1.  Каскадная модель

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

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

Устаревшая, но используется для маленьких моделей.

«+»: простота модели, планирования и реализации,

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

однократное оформление документации

«-»: необходимость исходного полного определения требований,

фиксированность требований и промежуточных результатов,

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

большое время запуска (от получения заказа до сдачи системы в эксплуатацию)

  1.  Каскадная модель с возвратом

Возможен возврат на предыдущий уровень стадии для учета изменений.

«+»: первые 3 недостатка предыдущей модели исправлены

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

большое время запуска (за счет зацикливания)

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

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

Т – определение требований

А - аналитический этап

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

«+»: нет неравномерности загрузки персонала,

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

«-»: фиксация требований

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

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

К началу второго витка – улучшенные требования.

При необходимости можно закрыть проект (при непопулярности)

«+»: результат и требования нефиксированы,

Упрощается внесение изменений в проект при изменении требований заказчика

«-»: проблема определения момента перехода на следующий этап, необходимо определять временные рамки этапа, иначе можно совершенствовать до  бесконечности

«?»: загрузка персонала, время запуска зависит от начальных требований

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

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

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

Процесс работы (действия) задачи

ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла ПО»

ЖЦ поддерживается 3 группами процессов:

  •  Основные – наиболее важные процессы, определяют содержание ЖЦ
  •  Вспомогательные – дополнительные работы, поддерживающие основные процессы
  •  Организационные – объединяют процессы на единой организационно-технической базе

Основные процессы

Процессы

Заказ (работы того, кто приобретает систему)

Подготовка - определение требований, вариантов реализации заказа (покупка/разработка)

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

Договор – подготовка договора  (определяем правила выбора исполнителя, выбор, согласование условий), оформление договора

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

Приемка (приемочные испытания) и закрытие договора

Поставка (работу поставщика продукта)

Подготовка поставки (анализ требований заявки)

Подготовка ответа (свои рекомендации по договору)

Оформление договора

Планирование (анализ требований, выбор модели ЖЦ, создание плана управления проектом)

Выполнение и контроль (реализация управления проектом, контроль за разработкой)

Проверка и оценка (проверка выполнения договора, проведение верификации и аттестации)

Поставка (заказчику) и закрытие договора

Разработка (работы того, кто разрабатывает продукт)

Подготовка процесса (выбор стандартов, методов, языка программирования, определение плана процесса разработки)

Анализ требований к системе (уточнение, конкретизация)

Проектирование (общей) архитектуры системы

Анализ требований к ПО

Проектирование архитектуры ПО

Техническое проектирование ПО (технический проект компонентов ПО, интерфейсов, БД; документация)

Программирование и тестирование

Сборка ПО (объединение программных модулей)

Квалификационное испытание ПО

Сборка системы (не только на своей платформе, но и на платформе заказчика)

Квалификационное испытание системы

Ввод ПО в действие

Приемка ПО (поставка продукта заказчику)

Эксплуатация (работы оператора, который обеспечивает эксплуатационное обслуживание)

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

Эксплуатационные испытания

Эксплуатация (в соответствии с документацией)

Поддержка пользователей (помощь и консультации пользователям)

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

Подготовка процесса (разработка плана проведения работ)

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

Внесение изменений

Проверка

Перенос (переход на другую платформу, смена технической базы, перемонтаж сети)

Снятие с эксплуатации (архивация с возможностью восстановления или ликвидация)

Вспомогательные процессы

Документирование

Описание информации, выдаваемой в процессе ЖЦ

Управление конфигурацией

Определение конфигурации (определение схемы обозначения ПОбъекта и их версий, документации)

Контроль (учет изменений)

Учет состояний (количество изменений, учет версий и их сравнение)

Оценка конфигурации (определена функц законченность ПО с точки зрения требований)

Управление выпуском (контроль выпуска и поставки ПО)

Управление качеством

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

Совместная проверка

Заказчик и разработчик проверяют совместно

Аудит

Проверка на соответствие требованиям, условиям договора

Аттестация

Проверка соответствия системы функциональному назначению (удовлетворяет ли заявленным возможностям)

Верификация

Верификация договора (непротиворечивость, наличие гарантий, конфиденциальности)

Верификация процесса (выполнимость, применимость стандартов)

Верификация требований (выполнимость, непротиворечивость)

Верификация проекта (соответствие требованиям, обнаружение ошибок, соответствие методам, реализация требований безопасности, защиты)

Верификация программы, сборки, документации

Решение проблем

Анализ и решение проблем и определение причин возникновения

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

Управление

Планирование, определение контрольных точек, контроль порождения всех процессов, проверка и оценка, отчетность

Обеспечение инфраструктуры

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

Совершенствование процессов

Оценка процесса, по результатам оценки - улучшение процессов ЖЦ

Обучение пользователей

Разработка учебных материалов

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

Другой альтернативный ГОСТ – ГОСТ Р ИСО/МЭК 15280-2002 «Системная инженерия процессов жизненного цикла систем»

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

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

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

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

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

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

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

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

Детализация – детализация и виденье требований пользователей.

КП – концептуальное проектирование.     

ЛП – логическое проектирование.

ФП – физическое проектирование.    

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

СтрКТС – структура комплекса технических средств (сервер/клиент, топология сети…).  Хар-ки эл-ов – детальное определение характеристик элементов.

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

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

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

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

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

ускорение разработки (библиотечные функции, объекты, классы)

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

предсказуемость сроков, стоимости разработки

облегчение внутреннего и внешнего обмена информации

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

упрощение модификации, расширение, масштабирование

 

Основные области стандартизации в ИС:

Стандартизация ЖЦ (ГОСТ 34.601)

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

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

 

Недостатки:

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

 

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

 

Источники формирования профиля:

Международные стандарты (многие международные стандарты перекрываются местными)

Национальные стандарты (СССР, которые еще действуют + Российские)

Отраслевые стандарты, стандарты де-факто (разрабатываются некоторой организацией, но ее стандарты распространяются на другие отрасли)

Стандарт предприятия (возможно несоответствие стандартов стандартом верхнего уровня)

Нормативные документы (руководства, разъяснения)

 

Стандартизация технологии проектирования ИС

Технология объединяет методы и методологии (математический аппарат и логический аппарат, организационные вопросы), стандарты, документы, программные и технический средства.

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

  •  ГОСТ 34.ХХХ
  •  ГОСТ Р ИСО/МЭК 12207 (или 15288 процессы ЖЦ)
  •  технология на основе программирования RADRapidApplicationDevelopment (Технология быстрой разработки приложений) основывается на инкрементном варианте ЖЦ. Задача делится  на главные функции, реализуется разными группами, используются средства быстрой разработки (builder). Цикл разработки -2-3 месяца. Для простых по обработке ИС.
  •  ХР – ExtremeProgramming (Экстремальное программирование) основывается на эволюционной модели, предельно короткий цикл (примерно 2 недели) включает кодирование, тестирование, обсуждение с заказчиком, планирование.
  •  CDMCustomDevelopmentMethod (Технология Oracle) детализирует всю технологическую процедуру для разработки на основе продуктов Oracle, поддерживает классическую каскадную разработку, детализированную до форм выходных документов. Есть упрощенные вариации для маленьких проектов.
  •  MSFMicrosoftSolutionFramework (Технология разработки Microsoft) основывается на унифицированной среде разработки продуктов Microsoft. Для спиральных моделей ЖЦ (больше для эволюционного, но подходит и для инкрементного варианта).
  •  RUPRationalUnifiedProcess (Разработка фирмы Rational – унифицированный процесс) использует эволюционную модель ЖЦ (4 фазы), цикл завершается выпуском версии. Реализует проектирование на основе языка UML.

 

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

Типовое проектное решение – это тиражируемое проектное решение, пригодное к многократному использованию.

Используются типовые проектные решения разного уровня. 3 основные уровня:

элементные типовые решения – реализуют отдельную задачу или вид обеспечения задачи.

«?»:  возможная нестыковка элементов, трудоемкость интеграции (элементов  много – сложно собрать в единое целое).

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

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

решения на уровне объекта (объектные типовые решения) – решение захватывает объект в целом.

«?»: проблема настройки, адаптации, возможно избыточность

Для адаптации типовых решений существует два основных подхода:

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

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

 

Типовое решение любого уровня должно содержать:

собственно реализацию решения

полные описания типового решения и возможности его применения

описание процедуры настройки типового решения

  1.  
    Документирование проектирования ИС

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

Назначение документирования:

Поддержка управления (приказы и проверка исполнения, для этого в ЖЦ расставляются контрольные точки + в каждой стадии должны быть оформлены определенные документы)

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

Обеспечение качества (в документации должно быть описано, как работает продукт)

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

Поддержка сопровождения (документация для группы сопровождения, которая может находить баги и устранять их, ликвидировать недостатки)

Историческая справка (история версия программного продукта, для возвращения к предыдущим версиям в некоторых случаях)

ГОСТ 9294-93 «Информационная технология. Руководство по управлению документированием ПО» – определяет общую стратегию документирования и управления им. Главные направления по документированию: 1) Документирование должно полностью закрывать жизненный цикл. 2) Документирование должно быть управляемым (нужен контроль, контрольные точки, отчеты, приказы). 3) Документирование должно быть составной частью процесса разработки (в виде отдельного плана или входить в общий план). 4) Документирование должно учитывать читательскую аудиторию (либо техническим, либо обычным языком). 5) Документирование должно быть обеспечено стандартами и ресурсами. К документированию должен быть определен набор стандартов и руководств.

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

  •  выбора модели ЖЦ ПО,
  •  определения типов и содержания документов (документация разработки/продукции/управления проектом)
  •  требования по качеству документов (точно, полно, ясно; ориентировано на аудиторию, по структуре – легко осуществлять поиск по документу)
  •  требования к форматам представления документов (это руководство, определяется заказчиком и проектировщиком на бумаге/носителе/интерактивно/в виде презентации, требования к размерам, шрифту и прочее)
  •  требования к обозначениям (обозначающая информация – заглавие, ссылочный номер, реквизиты автора и прочее)

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

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

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

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

 

Документирование поддерживается ГОСТами:

ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» – виды документов на различных стадиях ЖЦ (см. раньше)

ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании АС» стандартизирует виды документов, присваивает им коды и обозначения, для части документов ссылается на гост 34.601-90

РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов» - определяет структуру и содержание гостируемых документов

ГОСТ 34.602-89 «Техническое задание на создание АС» - требования по ТЗ

ГОСТ 19.101 –по программным документам

ГОСТ 2.601 – по эксплуатационным документам

ГОСТ 2.102 – по техническим средствам.

Эти ГОСТы скорее относятся к каскадной модели.

Для спиральной модели подбор документов основан на ГОСТе 12.207.

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

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

Case – средства – программный продукт для автоматизации процессов ЖЦ ИС.

Основные области автоматизации:

  1.  Формирование требований (Rational Require Pro – хранит перечень требований, привязывает их к документами, отслеживает, объединяет)
  2.  Разработка проектных моделей (ERWin+BPWin, Rational Rose, ARIS, Oracle Designer/Developer)
  3.  Реализация (Delphi, Visual Studio, Builder)
  4.  Тестирование (Rational Test Team)
  5.  Ведение документации (Rational SoDA)
  6.  Ведение версий и конфигураций (Rational ClearCase, MS Safe Source)
  7.  Управление планированием (MS Project – контроль за выполнение работ)

Особенности Case-средства:

  •  Широкое использование графики
  •  Использование разнообразных шаблонов и типовых решений
  •  Поддержка групповых работ (использование обычного многопользовательского доступа или разделение между группами разработчиком с последующим слиянием)
  •  Контроль доступа или контроль за выполняющейся разработкой
  •  Использование репозитория для накопления данных для проектирования и текущих проектных решений. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке.

«+» Case-средств:

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

«-»:

  •  Сложность освоения, применения
  •  Быстрая смена версия
  •  Дороговизна, большой срок окупаемости
  •  Несоответствие текущим технологиям проектирования
  •  Несоответствие инфраструктуре, характеру, масштабам проектов
  •  Неготовность персонала к использованию

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

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

Реалистичные ожидания:

• ускорение и повышение согласованности разработки приложений;

• снижение доли ручного труда в процессе разработки и/или эксплуатации;

• более точное соответствие приложений требованиям пользователей;

• лучшее документирование;

• улучшение коммуникации между пользователями и разработчиками;

• последовательное и постоянное повышение качества проектирования;

• более высокие возможности повторного использования разработок;

• последовательное снижение общих затрат;

• лучшая прогнозируемость затрат

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

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

DFD (Data Flow Diagrams) - диаграммы потоков данных;

SADT(Structured Analysis and Design Technique — метод структурного анализа и проектирования,) — модели и соответствующие функциональные диаграммы;

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

 

Совместное использование методологий

При решении новой задачи автоматизации

 

При модернизации уже имеющейся системы: DFD-модель уже имеющейся системы, на основе нее – внесение изменений.

В результате применения этих методологий:

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

На стадии формирования требований к ПО используются для построения модели "AS-IS" и модели "ТО-ВЕ", отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними

На стадии проектирования DFD используются для описания структуры проектируемой системы ПО.

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

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

При объектном подходе предметная область представляется как набор объектов и их взаимодействий. Деятельность предметной области –  взаимодействие объектов.

Объектно-ориентированный подход использует объектную декомпозицию, при этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами

Для объектного проектирования базой является язык UML (унифицированный язык моделирования). UML – графический язык, предназначенный для определения, представления, проектирования  и моделирования различных систем. Определяет набор диаграмм для описания проектируемой системы, правила использования и последовательность разработки.

UML включает набор диаграмм:

 

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

Общая последовательность разработки

Анализ - определяется диаграмма вариантов, начальная диаграмма классов (только основные объекты и основные атрибуты). Возможно дополнение диаграммой деятельности, которая уточняет варианты использования.

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

Реализация - доопределение классов с учетом реализации, разработка диаграмм компонентов и размещения, возможна генерация БД, автогенерация программного кода.

Диаграмма вариантов использования

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

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

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

Вариант использования: обозначение - овал, наименование - глагол или отглагольное существительное, возможно дополнение. Для уточнения содержания варианта создается документ, в котором описывается набор сценариев исполнения этого варианта (описание с точки зрения пользователя, а не программиста).

Связи:

Ассоциация (коммуникация) - связь между действующим лицом и вариантом. Может показываться направление инициализации. В большинстве случаев двусторонний обмен (простая линия).

Варианты могут быть связаны друг с другом:

Расширение (extend)

В2 расширяет возможности В1. Расширяющий вариант добавляет возможности, не являющимися необходимыми.

Включение (include)

Если одни и те же функции у разных вариантов, то их можно вынести в один. Связь обязательная для выполнения. В5 – кусок, который повторяется в В3 и В4

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

 

Диаграмма деятельности

Показывает подробное пооперационное исполнение выбранной задачи/варианта.

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

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

  - выбор одного из нескольких продолжений

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

- завершение задачи.

Диаграмма классов

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

Стереотипы классов: он характеризует принципиальное назначение класса.

<<entity>> (основной прикладной тип, задание объектов предметной области)

<<boundary>> (граничный класс, обеспечивает интерфейс с внешней средой……0

<<control>> (управление, контроль и упорядочивание последовательности действий)

Атрибуты – свойства экземпляров <класс видимости> <имя> : <тип>=<значение по умолчанию>

Классы видимости: public, private (закрытый внутренний), protected (защищенный, виден из самого класса и его наследников), package (пакетный, виден из пакетов, помещенных в классы).

Методы -  набор операций, которые исполняет класс <имя>(<параметры>:<тип>)

 

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

Связанность экземпляров классов группы "ассоциация". Связь может быть двунаправленная и однонаправленная. Показывает, с какой стороны имеются ссылки на связанный класс. Для ассоциации указывается кардинальность связи: 1, 0…1, n...m, 0…*, 1…*, * (сколько экземпляров входит в каждую связь, диапазон)

Структурная связанность. Три вида связи:

Композиция - жесткая связь, часть не может существовать без главного, может входить только в состав одного главного.

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

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

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

 

Диаграмма взаимодействия

(последовательностей и кооперативные)

  1.  Диаграммы последовательности

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

Сообщениянаименование (параметры)[условия*] имеют наименования, возможно параметры, возможно управляющую информацию. Управляющая информация - условие (проверяется допустимость передачи сообщения) или итератор* (необходимость выполнения операции для всех связанных экземпляров, применяется ко всем экземплярам, которые попадают под условия).   

Виды обозначений сообщений:

- Синхронное сообщение (останавливается пока не придет отклик от подпрограммы)

- Асинхронное сообщение (продолжаем работать)

- Автовызов (для внутренних методов)

  1.  Кооперативные диаграммы

По содержанию аналогичны диаграмме последовательности, но без развертки по времени. Явно указываются отношения между объектами. Последовательность подачи сообщений указывается нумерацией. Если могут быть параллельные процессы, то нумерация составная: <инициализирующее сообщение>.<активированное сообщение> 

Диаграмма состояний

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

Действия:

entry:<действие> - входное действие, выполняется при переходе в состояние

do:<действие> - действия, выполняемые при нахождении в данном состоянии

exit:<действие> - действие по выходу

 

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

Событие - инициирует выход из состояния.

Условие - оценивает допустимость выхода из состояния. Условие может определять направление выхода при нескольких выходах. Если событие произошло, но условие не позволяет выйти из состояния, то ждем.

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

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

БД – отображение предметной области. Для создаваемых баз – желательно выполнение 2 противоречащих требований: отсутствие избыточности (нормализация) и высокая эффективность использования.

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

  1.  Анализ предметной области, сбор информации

  1.  Инфологическая модель – формальное описание предметной области, без учета дальнейшей реализации в СУБД. Основной способ представления: ER-модель («сущность-связь»-модель).

Элементы: сущности, свойства, связи.

Этапы:

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

1. Сущность    

2. Свойство

А) Составное свойство – это свойство, которое является заголовком логической группы

Б)  Свойство множественное - задается набором значений 

В) Свойство условное – заполнение в таблице необязательно

3. Связь - экземпляр одной сущности связан с одним (несколькими) экземпляром другой сущности.

Необязательность – необязательно связан с экземплярами сущности

4А. Объект составной

4Б. Объект обобщенный - некоторые свойства общие, некоторые специфические

5 Ассоциация – вводится при:

1) замена связи «многое ко многим»

2) Когда соединяется 3 сущности.

3) Когда к связи необходимо добавить дополнительную информацию. 

  1.  Логическая модель – описание логической структуры данных в допустимых абстрактных структурах хранения. Особенности конкретной СУБД могут учитываться или нет.

4 вида: иерархическая, сетевая, реляционная, объектная.

Этапы перехода к реляционной модели:

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

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

Определяются: обязательность, уникальность, ссылочные отношения.

  1.  Преобразование составного объекта. Вложенные сущности выносятся на уровень главной сущности объекта и соединяются с ней внешними связями.  

2. Преобразование обобщенного объекта

а) сущности категорий выносятся на уровень главной сущности объекта и соединяются с ней внешними связями;

б) сущности категорий объединяются с частями главной сущности с образованием набора независимых сущностей объектов;

в) все сущности объединяются в единую сущность

3. Преобразование ассоциации. Ассоциация рассматривается как обычная сущность, что сводится к простой замене изображения ассоциации на изображение сущности

4. Преобразование составного свойства. Составное свойство представляется как набор простых свойств, ранее составлявших составное свойство.

5. Преобразование множественного свойства. Множественное свойство выносится в новую сущность, связываемую с исходной сущностью связью 1:М

6. Преобразование условного свойства

7. Преобразование связи 1:1.

а) соединение сильно связанных сущностей

б) введение дополнительной связующей сущности для связывания слабо связанных сущностей

8. Преобразование связи М:М. Вводится дополнительная связующая сущность, разбивающая связь М:М на две связи 1:М

  1.  Физическая модель – реализаций в рамках конкретной СУБД. СУБД делятся на несколько типов (по тому, как хранятся данные): реляционные, иерархические, сетевые, объектно-ориентированные, объектно-реляционные.

При физическом проектировании решаются задачи:

  1.  определение основных объектов БД и дополнительных объектов БД
  2.  конкретизация типа, размерности данных
  3.  определение индексов (на логическом уровне - ключи). Значительная часть систем формирует стандартные ключи автоматически. Некоторые системы выполняют для индексов – физическое упорядочивание. Индексы нужны для ускорения поиска, организации связи между таблицами, обеспечения уникальности.
  4.  определение представлений – запросы, только сохраняемые (виртуальные таблицы). Такой запрос нужен для увеличения быстродействия при обработке запросов, так как сохраняется механизм отбора данных по запросы.
  5.  определение служебных операций: процедуры резервирования и восстановления данных
  6.  определение состава пользователей и их прав
  7.  определение  способов реализации ограничений (в приложении или на сервере: декларативный-стандартными способами, программный-создание триггеров)
  8.  распределение физической памяти под базу и объекты

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

Учет мнения пользователя

Модели поведения компьютерной системы:

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

Декларативная модель (что реально предъявляет интерфейс системы пользователю)

Модель реализации (что реально делает система)

Решения по интерфейсу должны согласовываться с пользователем. Формы согласования:

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

Три группы пользователей:

Начинающий пользователь. Интересы – как использовать систему, какие задачи можно решать. Основной инструмент – интерактивное руководство, учебники, методики по применению.

Опытный пользователь. Интересы – как решить определенную задачу, как выполнить определенные действия. Основной инструмент – интерактивная справка, контекстная справка

Эксперт. Интересы – эффективно решать поставленные задачи. Основной инструмент – сочетания горячих клавиш, командное окно (строка), макросы, настройка.

Должен быть выдержан компромисс между контролем пользователя и свободой действий пользователя. Оптимизация может быть:

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

Желательно запоминать индивидуальные настройки + возможность выполнять операцию разными способами.

 

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

  1.  Пассивные – не требуют специальных действий пользователя. Пример: названия, пояснения на формах, всплывающие  подсказки, подсказки в меню по горячим клавишам, строка статуса.
  2.  Реактивные – требуются специальные действия пользователя. Пример: контекстная помощь, контекстное меню, кнопка «Что такое?».
  3.  Активные – отслеживают работу пользователя, прогнозируют ход событий, пытаются создавать подсказки или управлять дальнейшим поведением пользователя. Пример: выскакивание подсказок по набору команд, интерактивные помощники.

Реализация интерфейса

Имеется несколько общепринятых стилей:

Классический интерфейс – единое главное окно, составляющие: меню, инструментальные панели, основное окно. Прочие окна открываются как дочерние.

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

Стиль - проект – главного окна нет, выводится меню, инструментальная панель, все задачи запускаются как самостоятельные приложения. Оформляется в виде каталога, проводника, навигатора и т.д.

 

Дополнительные стили для работы с отдельными формами:

Блокнот – содержит вкладки, можно сложить много информации, но просматривать по частям.

Проводник – в проекте имеется навигатор и информационная часть

Мастер – последовательное по экранам развертывание решения задач (установка ПО, например).

Для представления общей картины рекомендуется разработка схемы структуры интерфейса, где показываются экранные формы интерфейса и переходы между ними. И схемы диалога – с указанием всех возможных переходов.

 

Представление табличных данных в экранных формах

На экранной форме отображается только одна таблица.

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

Позаписный вариант – редактирование, просмотра больших записей.

Можно сделать комбинированный вариант – вынести обе формы на одну экранную форму.

Две таблицы со связью 1:1. Для пользователя полезно объединить в одну виртуальную таблицу для удобного чтения пользователем.

Две таблицы со связью 1:М

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

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

Три и более таблиц – выполняется разбивка на несколько последовательных форм, на каждой форме 1-2 таблицы. При показе двух таблиц возможно наложение данных по формам.

 

Выбор используемых элементов

Зависит от типа информации.

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

  1.  
    Проектирование файл-серверных ИС

  1.  Персональная модель – локальная однопользовательская (то есть все на одном рабочем месте)

«-»: невозможность одновременной работы многих пользователей

  1.  Централизованные модели.

Общий недостаток централизованной модели: работоспособность полностью зависит от работоспособности центральной машины!!!

  1.  Файл-серверная модель. В СУБД прописывается путь на БД. Физически база и СУБД-Приложение могут находится на одном аппаратном узле.

«-»: лишняя нагрузка сети, нет центральной обработки (отсутствие возможности реализации централизованного обслуживания)

Сервер – роли доступа к инф ресурсам.

Вся обработка – на клиентах.

запрос

2а)  Модель удаленного доступа (Remove Date Access). На сервере – БД и СУБД. Сервер-доступ. Приложение – обработка и представление информации (интерфейс).

«+»: сокращаем объемы передачи по сети

«-»: сложнее клиентские приложения

SQL-запрос

2б)  Модель сервера БД (Data Base Server). На сервере – обработка (триггеры, процедуры и прочее). На приложении – представление.

«+»: центральное администрирование, снижение трафика

«-»: большая загрузка сервера

вызов процедуры

3) Модель сервера приложений (Application Server). Добавляется сервер приложений, на нем часть обработки.

Сервер БД и СУБД – доступ и обработка. Приложение – интерактивная обработка.

«+»: убрали большой программный код с клиентской части, общая обработка – вся в одном месте. К СУБД прицеплен один виртуальный пользователь, уменьшение числа соединения с пользователем.

Прикладной компонент СУБД – на сервере приложений (поддержка запросов)

3. Децентрализованная модель. Автономные системы, имеющие связь для согласования общих данных. Децентрализованные модели различаются:

По характеру хранимых в узлах данных

  •  Все хранимые данные глобальны
    •  Часть данных глобальна, часть - локальна
    •  Все хранимые данные формально локальны (только для одного конкретного узла)

По способу хранения глобальных данных

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

Обработка целиком выполняется на клиентах. Сервер – роль доступа к БД.

Необходимо обеспечить МНОГОПОЛЬЗОВАТЕЛЬСКИЙ ДОСТУП, ЦЕЛОСТНОСТЬ, РЕЗЕРВИРОВАНИЕ, КОНТРОЛЬ НСД.

«+»:

  •  Простота развертывания исходных однопользовательских систем
  •  Дешевизна и простота разработки, эксплуатации
  •  Простота аппаратных средств

«-»:

  •  Ограниченное число пользователей
  •  Высокие требования к клиентскому месту
  •  Большая загрузка сети
  •  Низкий уровень поддержки организации управления данными

Область применения:

Поддержка малых групп

Желательна малая конфликтность обращения к данным

Например, информационно-справочные системы (операции разделены во времени).

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

Разделение областей данных между пользователями

 

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

Использование механизма транзакций. Автоматические блокировки устанавливается СУБД при выполнении определенных команд INSERT (блокируется вся таблица), APPEND (заголовок), DELETE (одна или несколько записей). Сохраняются до конца транзакции. Автоматически снимаются при завершении транзакции

BEGIN TRANSACTION,ROLLBACK,END TRANSACTION

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

Использование явного блокирования записей с помощью специальных команд

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

UNLOCK() – разблокировка;

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

Поддержка целостности: во всех персональных СУБД есть свое описание ограничений для исключения потерь, противоречий (NOT NULL, PK, UNIQUE, CHECK).

Резервирование, восстановление, контроль доступа поддерживается нестандартными средствами. Либо используем средства ОС, либо программируем сами эти операции.

Контроль доступа: базу выкладываем на отдельный компьютер, доступ только по сети, ведение таблицы логинов/паролей.

  1.  
    Проектирование централизованных клиент-серверных ИС

Данные хранятся в едином месте на выделенном сервере. На сервере так же хранится программный код основной части СУБД, который обеспечивает служебные функции управления Данными и доступ к Данным.

Сервер удаленного доступа

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

«+»: сокращаем объемы передачи по сети

«-»: сложнее клиентские приложения

Сервер БД

На сервере – прикладные функции СУБД (программные триггеры – запускаются при попытке выполнить команду, процедуры – запускается по явной команде)

«+»: центральное администрирование, снижение трафика

«-»: большая загрузка сервера

Сервер приложений

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

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

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

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

Выбор архитектуры модели (удаленный доступ, сервер БД, сервер приложений)

Выбор СУБД для сервера (зависит от выбранной модели)

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

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

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

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

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

«-»: трудоемкость, отсутствие мобильности

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

«+»: мобильные приложения, более легкое программирование

«-»:  необходимость знания SQL

3)  Стандарт обмена с БД (ADO) – OLE DB

4)  Объектные технологии IBX. Работает напрямую с СУБД. Решение по содержанию сервера: определяется состав и форма хранения основной части базы, определяется состав и содержание ограничений целостности, назначение транзакций, вид триггеров и хранимых процедур

5) Технологии BDE. Варианты: Native (драйверы напрямую работают с БД без СУБД), LinkSQL (обращение к наиболее популярным промышленным СУБД), ODBC (драйвер ODBC).

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

 

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

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

«Грязное» чтение – множественное изменение данных. Во время изменения – считанные данные будут неверными.

«Неповторяющееся» чтение – неоднократное считывание изменяемых данных. При повторной попытке выбора значения будет получен другой результат.

Фантомное чтение – отличается от неповторяющего чтения тем, что результат повторного обращения к данным изменился не из-за изменения/удаления самих этих данных, а из-за появления новых (фантомных) данных.

Далее необходимо выбрать уровни изолированности транзакций, исключающие потерю целостности для выделенных операций (S, RR, RC, RU)

Фантомная вставка

Неповторяющееся чтение

«Грязное» чтение

Потерянное обновление

Serializable (упорядочиваемость)

+

+

+

+

Repeatable Read (повторяемость чтения)

-

+

+

+

Read Committed (чтение подтвержденных данных)

-

-

+

+

Read Uncommited

(свободное чтение)

-

-

-

+

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

Резервирование-восстановление:

Определяется условие для инициализации резервирования (до/после изменений, перед операциями изменения структуры/формата, перед опасными операциями). В общем случае: ДО события, ПОСЛЕ событий и РЕГУЛЯРНОЕ резервирование (по расписанию).

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

Описание процедур резервирования и восстановления

Обеспечение ведения наборов резервных копий

Проверка работоспособности процедур, работоспособности копий, правильности результатов резервирования

Хранение на разных носителях

Контроль доступа:

Основной инструмент - стандартные средства СУБД (GRAND <привилегия> ON <объект> TO <субъект>) и ОС (проверка паролей на уровне ОС).

Определяется ответственность за контроль доступа, желателен 1 человек, при большом объеме может быть несколько.

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

Определяем, роли или группы будем использовать

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

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

«-» централизованных систем, из-за которых могут быть выбраны распределенные системы:

  •  Низкая скорость из-за территориальной удаленности сервера
  •  Уменьшение надежности из-за наличия одного центрального сервера
  •  Возможность перегрузки сервера из-за большого числе пользователей

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

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

Свойства распределенной системы:

  1.  БД можно распределить на фрагменты
  2.  Фрагменты могут иметь копии (реплики)
  3.  Фрагменты и реплики распределены по узлам сети
  4.  Узлы соединены линиями связи. На каждом узле выполняется хотя бы одно глобальное приложение. На каждом узле могут автономно выполняться локальные приложения.
  5.  Для доступа к данным – на каждом узле своя СУБД

Требования к распределенным системам по Дейту:

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

  1.  Локальная автономность – локальные приложения и данные должны управляться автономно
  2.  Отсутствие фиксированных центральных узлов
  3.  Непрерывность работы – работа не прерывается при отключении или изменениях на других узлах
  4.  Прозрачность (независимость) фрагментации – пользователь и программист не видят разбиения данных на фрагменты
  5.  Прозрачность репликаций – фрагментация видна, но не видны разделения на реплики
  6.  Прозрачность местоположения – видна фрагментация, репликация, но не видно конкретного представления (физического размещения) данных на других узлах
  7.  Поддержка распределенности запросов (в запрос могут быть включены данные с нескольких узлов)
  8.  Поддержка распределенных транзакций
  9.  Независимость от оборудования
  10.   Независимость от СУБД
  11.   Независимость от ОС
  12.   Независимость от сети

«+» распределенных систем:

  •  Сочетание локальной автономности и совместного использования данных
  •  Увеличение скорости решения большей части задач
  •  Повышение доступности данных (доступ в любой момент времени)
  •  Повышение надежности хранения

«-»:

  •  Отсутствие общих принципов разработки (стандарты, которые бы описывали все вместе)
  •  Усложнение проектирования
  •  Отсутствие опыта разработки
  •  Увеличение стоимость

«?»: надежность – вероятность потерь больше, НО объем потерь меньше, так как все распределено

Организация операций с распределенными данными

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

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

Для блокирования используемых данных нужно заблокировать одновременно доступ ко всем копиям данных. Простейший вариант – глобальные схемы блокировок. Еще варианты – хранить репликации схемы блокировок на всех узлах, либо хранить блокировки локально в тех местах, где данные создавались.

Для завершения транзакции и фиксации данных используют двухфазный COMMIT.

1 фаза: Голосование – главный узел рассылает подчиненным команду подготовки к фиксации. Подчиненные узлы выполняют подготовку, сообщают о готовности.

2 фаза: Главный узел ожидает откликов в течение таймаута. Если получены все отклики и они положительные, то рассылается команда фиксации. Иначе – команда отката. Далее подчиненные узлы обрабатывают команду фиксации или отката.

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

3 подхода к выполнению доступа к данным.

  1.  Использование глобальной схемы данных

ГВС –внешние схемы - определяет представление данных из всей базы для пользователя (интерфейс, представление)

ГЛС – глобальная логическая модель: описывает структуру всей БД в целом.

СФ – схема фрагментации - описывает разбиение базы на фрагменты.

СР – схема распределения: описывает наличие и количество реплик и их место размещения.

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

ЛЛМ – локальная логическая модель.

ЛФМ – локальная физическая модель-модель для отдельного узла.

«+»: единый механизм передачи данных для любого числа узлов

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

  1.  Системы с частичной глобальной схемой, федеральные распределенные системы

ЛВМ – локальная внешняя схема (интерфейс для локальных пользователей)

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

Удобно, если глобальный каталог используется редко.

  1.  Системы без глобальной схемы. Данные о распределении информации не хранятся. Обмен информации выполняется по фиксированным схемам, исходя из внешней информации о распределении.

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

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

  1.  
    Распределение данных ИС, фрагментация и репликация

Для распределения глобальных данных используется 2 технологии: фрагментация и репликация.

Фрагментация – разделение БД на непересекающиеся фрагменты.

При фрагментации должна соблюдаться:

  •  ПОЛНОТА (каждые данные должны находиться в каком-либо фрагменте)
  •  НЕПЕРЕСЕКАЕМОСТЬ (каждые данные должны находится не более чем в одном фрагменте)
  •  ВОССТАНОВИМОСТЬ (возможность дефрагментации без потерь)

Фрагментация может быть на уровне базы или на уровне таблицы.

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

Горизонтальная – разделение таблицы по группам строк (по выбранным условиям).

Операции ОБЪЕДИНИЕ и ФРАГМЕНТАЦИЯ

Вертикальная – разделение по группам столбцов (по атрибутам).

Операции СОЕДИНЕНИЕ по совпадению первичного ключа.

Смешанная – по строка и столбцам одновременно

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

Последовательность фрагментации:

  1.  Определение нефрагментированных данных;
  2.  Фрагментация основных таблиц;
  3.  Фрагментация дочерних таблиц

Репликация – создание копий для базы в целом или отдельной таблицы.

Основная проблема – необходимость синхронизаций копий.

Репликация классифицируется по нескольким признакам:

  1.  По моменту исполнения:
  •  синхронная – все реплики обновляются одновременно (в рамках одной транзакции)
  •  асинхронная – выполняется с запаздыванием  (по команде пользователя., по событию, по расписанию)
  1.  По захвату репликаций (по объему):
  •  полная (репликация всей БД)
  •  частичная (какой-то части БД)
  1.  По способу обновления:
  •  Моментальный снимок (реплики переписывается на новый вариант полностью)
  •  Репликация изменений (переписываются только изменения)
  •  Репликация команд изменений (репликация команд, примененных к БД)
  1.  По стороне инициализации:
  •  Инициализация от главной реплики
  •  От подчиненной реплики
  1.  По схеме репликаций:
  •  «Ведущий/ведомый» - изменения выполняются только на одном фиксированном сервере, в остальные реплики изменения копируются (ведущий – узел, на котором выполняются обновления, ведомый – получает сообщения от ведущего)
  •  Схема «Рабочий поток» - в каждый момент изменения может вносить только один узел (он ведущий). Это место переменное.
  •  Симметричная схема - одновременное обновление данных на нескольких серверах. При этом возможны конфликты. Методы обнаружения конфликтов: простановка меток обновления (по метке определяется было ли изменение), хранятся старые и новые данные и репликация проверяется по старым данным (то есть храним копию старой версии). Обновление с учетом времени изменения, приоритета обновлений, значений.

PAGE   \* MERGEFORMAT 34


EMBED Visio.Drawing.11

EMBED Visio.Drawing.11  

EMBED Visio.Drawing.11  

  •  

 

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

36510. Теплопровідність газів 248.36 KB
  Вони нагріті до різних температур і ці температури підтримуються сталими. Зміна температури вздовж осі характеризується градієнтом температури. Закон дає зв’язок між кількістю тепла і градієнтом температури. Кількість тепла пропорційна градієнту температури; як можна було б очікувати пропорційна площі площадки .
36511. Загальне рівняння для явищ переносу 184.28 KB
  Запишемо кількість молекул які налітають за одиницю часу на площадку із швидкостями у інтервалі і у межах полярних кутів . Тому записуючи кількість молекул ми додаємо ще два імовірнісні множники . Позначимо кількість величини що переноситься зліва направо через площадку тими молекулами які летять у межах кутів з відстані . Ця кількість буде визначатись добутком значення величини що переносить кожна молекула на кількість молекул : .
36512. Ергодична гіпотеза 175.19 KB
  3 Фазові перетворення ІІ роду. Поглянемо на класифікацію фазових перетворень І і ІІ роду не з точки зору наявності чи відсутності теплообміну а з точки зору стрибкоподібної зміни параметрів стану речовини. Фазові перетворення при яких перші похідні функції змінюються стрибкоподібно називаються фазовими перетвореннями І роду. Фазові перетворення при яких перші похідні функції залишаються неперервними а другі похідні тієї ж функції змінюються стрибкоподібно називаються фазовими перетвореннями ІІ роду.
36513. Закон зростання ентропії. Обчислення зміни ентропії при різних процесах 162.99 KB
  Обчислення зміни ентропії при різних процесах Якщо термодинамічна система адіабатно ізольована то і зміна ентропії у результаті протікання оборотних процесів а під час необоротних процесів які власне тільки і існують у природі як показує досвід і теорія ентропія зростає. Рівність має місце лише для оборотних процесів за означенням ентропії. Властивість зростати притаманна ентропії так само як енергії – зберігатись.
36514. Об’єднана формула Максвелла-Больцмана розподілу молекул за швидкостями 177.18 KB
  Потенціальна енергія молекули залежить від її положення . Зміна потенціальної енергії спричиняє зміну і кінетичної енергії молекул оскільки . Але середня кінетична енергія не змінюється а отже не змінюється і температура газу оскільки вона є мірою кінетичної енергії молекул газу.
36515. Броунівський рух. Теорія Ейнштейна-Смолуховського. Дослід Перена по визначенню числа Авогадро 244.82 KB
  Запишемо рівняння руху такої частинки де нескомпенсована результуюча сила дії з боку молекул середовища яка примушує броунівську частинку рухатись у певному напрямку; сила тертя зумовлена в’язкістю середовища. У проекції на вісь рівняння руху броунівської частинки набуває вигляду . Розв’язок рівняння її руху може нам дати координату руху але хаотичний рух вимагає усереднення за довгий проміжок часу. Давайте використаємо дві очевидні тотожності : і підставимо їх у...
36516. Теплове ковзання. Радіометричний ефект. Радіометричний манометр 207.96 KB
  Капиллярногравитационными волнами называются волны распространяющиеся по поверхности жидкости под действием сил поверхностного натяжения и силы тяжести. рассмотрим случай когда глубина жидкости значительно больше длины волны. Это можно сделать очень просто если воспользоваться следующим результатом вытекающим из уравнений гидродинамики несжимаемой жидкости. В плоской бегущей синусоидальной волне малой амплитуды каждая частица жидкости движется по окружности расположенной в вертикальной плоскости проходящей через направление...
36517. Самодифузія. Коефіцієнт самодифузії, його залежність від тиску і температури 284.09 KB
  Цикл Карно і його к. Теореми Карно. У циклі Карно задача якомога спрощена. Цикл Карно виглядає наступним чином.
36518. В’язкість (внутрішнє тертя). Коефіцієнт в’язкості, його залежність від тиску і температури. Методи визначення коефіцієнту в’язкості. В’язкісний манометр 163.66 KB
  Коефіцієнт в’язкості його залежність від тиску і температури. Методи визначення коефіцієнту в’язкості. Коефіцієнтом пропорційності у цьому рівнянні є величина яка має назву коефіцієнта динамічної в’язкості або коефіцієнта внутрішнього тертя. За одиницю динамічної в’язкості у системі СІ приймається коефіцієнт в’язкості такої речовини у якій за одиницю часу при градієнті швидкості рівному 1 с1 через площадку площею 1 м2 переноситься імпульс рівний 1 кгм с.