ГОСЫ / Bilety

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

1.Требований заказчика и итоговой реализации ПО;

2.Итоговой реализации ПО и технического задания;

3.Действительной работоспособности алгоритмов в итоговой реализации ПО.

Модели ЖЦ:

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

1. каскадная модель («водопад») – все стадии выполняются последовательно, переход от одной стадии к другой осуществляется после полного завершения предыдущей стадии, завершением каждой стадии является полный пакет документов.

Достоинства:

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

легкая передача проекта от одной группы разработчиков к другой.

Недостатки:

модель не работает в связи с наличием обратных связей;

затягивание процесса по времени.

Основным недостатком каскадного подхода является существенное запаздывание с

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

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

101

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

Достоинство: межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью.

Недостаток: время жизни каждого из этапов растягивается на весь период разработки.

3. спиральная модель – переход с одной стадии на другую происходит по истечении времени, независимо от завершенности процесса.

Недостатки:

неоконченность пакетов документов на каждой стадии;

большое количество копий.

Можно отметить следующие преимущества спиральной модели:

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

Ориентация на развитие и модификацию ПО в процессе его проектирования;

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

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

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

3. смешанная модель заключается в применении на первых стадиях спиральной модели и каскадного подхода на последнем витке.

Т.е. эта модель делает упор на начальные этапы ЖЦ:

анализ требований;

проектирование спецификаций;

предварительное проектирование;

детальное проектирование.

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

102

3.Основные принципы нотации функционального проектирования IDEF0. Смысловые примитивы. Связи. Декомпозиция. Диаграммы.

Нотация IDEF0 как средство функционального моделирования

IDEF0 может быть	использована для	моделирования	широкого класса систем.
В основе лежит модель SAD. Она предназначена для создания бизнес-поцессов. Результатом
применения IDEF0 к	некоторой системе	является модель	этой системы, состоящая из

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

(Input) Стрелки входа (входят в левую грань работы) - изображают данные или объекты, изменяемые в ходе выполнения работы.

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

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

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

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

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

Принцип декомпозиции

103

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

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

Впроцессе декомпозиции функциональный блок А-0 подвергается детализации на дочерней диаграмме. По отношению к дочерней диаграмме и всем блокам на ней декомпозируемый блок является родительским блоком.

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

Диаграмма самого верхнего уровня иерархии - А-0, описывает наиболее общее представление моделируемой системы. Она является родителем для Диаграммы А0.

Диаграмма А0 является декомпозицией (Диаграммой - потомком) для А-0. Дает более детальное представление функции в Блоке 0. Декомпозированный Блок 3, является родительским для Диаграммы А3.

Диаграмма А3 является декомпозицией Блока 3 Диаграммы А0 и иллюстрирует внутреннее содержание Блока на родительской Диаграмме. Декомпозированный на Диаграмме А3 Блок 1 является родительским для Диаграммы А31.

104

5.Основные принципы нотации проектирования последовательности работ IDEF3. Смысловые примитивы. Связи. Декомпозиция. Перекрёстки.

Нотация IDEF3 как средство моделирования потоков работ

IDEF3 (workflow diagramming) используется для проектирования сценарии развития бизнес процесса. Метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития

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

процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных

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

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

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

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

Модель, выполненная в IDEF3, может содержать следующие элементы:

Единицы работы (Unit of Work) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.

Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей:

o Связь предшествования (Precedence) - показывает, что прежде чем начнется работаприемник, должна завершиться работа-источник. Обозначается сплошной линией.

o Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.

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

o Перекрестки (Junctions) - перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во время его выполнения. Различают два типа перекрестков: синхронные и асинхронные. Синхронность отображает требования к одновременности протекания процессов. Также перекрестки делятся по виду логич. ф-ции, которую выполняют.

Типы перекрестков

Исключающий ИЛИ:

– запускается (завершается) только одна последующая (предшествующая) работа

И:

 Асинхронный:

– запускаются (завершаются) все последующие (предшествующие) работы

 Синхронный

105

– все последующие (предшествующие) работы запускаются (завершаются) одновременно

ИЛИ:

 Асинхронный:

– запускаются (завершаются) одна или несколько последующих (предшествующих) работ

 Синхронный

– одна или несколько последующих (предшествующих) работ запускаются (завершаются)

одновременно

Примеры неправильных перекрестков

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

1.Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.

2.Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа синхронного или асинхронного "ИЛИ". Действительно, после работы 1 может запускаться только одна работа - 2 или 3, а для запуска работы 4 требуется окончание обеих работ-2 и 3. Такой сценарий не может реализоваться.

Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления "ИЛИ"

3. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ".

Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ"

4. Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И" (рис. 1.4.14). Здесь после завершения работы 1 запускаются обе работы - 2 и 3, а для запуска работы 4 требуется, чтобы завершилась одна и только одна работа - или 2, или 3.

106

Неверное размещение перекрестков. Перекресток для слияния типа исключающего "ИЛИ" не может следовать

5. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.

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

Предназначение IDEF3

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

В IDEF3 декомпозиция используется для детализации работ.

Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ.Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ

107

7.Принципы нормализации и денормализации модели данных. Аномалии. Основные нормальные формы.

Отношение – двумерная таблица, обладающая набором свойств:

1.Каждый столбец таблицы имеет уникальное имя.

2.Порядок расположения столбцов несущественен.

3.Каждая строка уникальна.

4.Порядок расположения строк несущественен.

5.Каждая ячейка хранит атомарное значение.(ФИО, Адрес – не атомарные)

6.В столбце хранятся данные одного типа.

Критерием правильности отношений может служить нормализация.

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

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

Первая нормальная форма (1НФ)

Любая таблица, являющаяся отношением, находится в первой нормальной форме. Виды нарушений атомарности:

1. в атрибут помещены разные по смыслу значения 2. присутствует скрытое групповое значение

Вторая нормальная форма (2НФ)

Таблица находится во второй нормальной форме, если она находится в 1НФ и каждый неключевой атрибут зависит от ключа целиком. Вторую нормальную форму имеет смысл рассматривать только с составным ключом.

Третья нормальная форма (3НФ)

Таблица находится в третьей нормальной форме, если она находится в 2НФ и в ней нет транзитивных функциональных зависимостей, т.е. все неключевые атрибуты взаимно независимы.

Нормальная форма Бойса-Кодда (НФБК)

Отношение находится в нормальной форме Бойса-Кодда, если оно находится в 3НФ и каждый детерминант является ключом-кандидатом. Если атрибут В функционально зависит от атрибута А, то атрибут А называют детерминантом, а атрибут В – зависимой частью. Если в отношении существует определенное количество атрибутов (один или более), однозначно определяющее каждую строку, то такой набор атрибутов является ключом-кандидатом в Primary key. Причем, по выбору, любой из них станет Primary key, остальные – Alternative key.

Четвертая нормальная форма (4НФ)

Отношение находится в четвертой нормальной форме, если оно находится в НФБК и в нем нет многозначных зависимостей.

Доменно-ключевая нормальная форма (ДКНФ)

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

В контексте ДКНФ под доменом подразумевается только физическое описание допустимых значений атрибута

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

только одну тему.

108

КИС Романова

2. Резервирование корпоративных данных

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

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

Простейшим из этих способов, который поддерживает любая СУБД, является создание полной резервной копии (full backup, database backup) – точной копии базы данных на текущий момент времени.

ПОЛНАЯ КОПИЯ является стандартным типом резервного копирования. Этот тип резервирования предполагает полное копирование всей информации, имеющейся в БД – все объекты, системные таблицы и данные. В качестве приемника данных может выступать магнитный диск (device) большого объема или устройство резервного копирования - стример (streamer - устройство потоковой записи на магнитную ленту, применяется для резервного копирования и архивирования данных). Создание полной копии является необходимым условием реализации плана резервного копирования, независимо от выбранной стратегии.

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

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

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

109

РАЗНОСТНОЕ КОПИРОВАНИЕ было разработано с целью уменьшения времени, необходимого для получения копии базы данных. В основе разностной копии лежит отслеживание изменений, вносимых пользователями в базу данных. Достаточно применить ее после восстановления полной резервной копии (которая делается один раз в большой промежуток времени), чтобы целиком восстановить систему в актуальном состоянии. В больших базах данных с относительно небольшим количеством изменений разностное копирование является наиболее оптимальным методом резервирования данных.

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

Третий тип создания резервной копии, предоставляемый СУБД (теми, которые в принципе поддерживают механизм транзакций), называется резервированием журнала транзакций (transaction log backup). В журнал транзакций записываются все транзакции, выполненные после последнего резервного копирования журнала транзакций.

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

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

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

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

110