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

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

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

Недостаток:

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

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

Недостатки:

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

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

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

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

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

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

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

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

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

2. Определение структурного анализа. Основные принципы структурного анализа.

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

Системная спецификация должна включать в себя:

• Выходные отчеты

• Описание структур данных и БД

• Описание внешних файлов

• Описание внутренних массивов

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

Спецификация должна бать точной, проверяемой с формализованной …

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

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

Существует несколько близких версий структурного анализа, объединенных общими принципами:

• нисходящая, иерархическая организация модели;

• «разделяй и побеждай»;

• графические средства общения и документирования.

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

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

Основные идеи, лежащие в основе структурных методов:

• представление системы в виде «черного ящика»; облегчение тестирования системы;

• возможность реконфигурирования;

• облегчение понимания и освоения;

• удобство модификации.

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

3. Понятие бизнес модели. Этапы построения бизнес модели. As is модели, should be модели, to be модели. Моделирование бизнес-процессов (as-is, to-be)

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

При переходе от модели AS-IS к модели TO-BE необходимо зафиксировать точку зрения и не менять ее в процессе проектирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Основные принципы нотации проектирования потоков данных dfd. Смысловые примитивы. Связи. Декомпозиция. Методология dfd

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

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

Всего DFD использует четыре важных элемента:

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

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

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

Хранилища данных.

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

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

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

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

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

Перекрестки

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

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

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

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

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

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

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

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

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

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

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

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

7. Основные принципы нотации информационного проектирования idef1x. Логическая и физическая модели данных. Смысловые примитивы. Сущности. Атрибуты. Связи. Методология idef1x

Для проектирования информационной модели бизнес-процессов используется методология IDEF1X.

Метод моделирования, который поддерживает графическое описание:

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

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

Сущность

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

Экземпляр сущности представляет конкретную сущность; он описывается значениями атрибутов данной сущности.

Атрибут

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

Атрибут может быть либо обязательным, либо необязательным. Обязательность означает, что атрибут не может принимать неопределенных значений (null).

Связь

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

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

Связи отражают взаимоотношения между сущностями.

Существует несколько видов связи:

• идентифицирующая связь;

• неидентифицирующая связь;

• связь «многие ко многим»;

• множественная связь;

• рекурсивная связь;

• категориальная связь

Рассмотрим более подробно следующие виды связей:

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

• Неидентифицирующая связь – проводится между двумя независимыми сущностями. При такой связи null-значения разрешены.

• Связь «многие ко многим» используется в том случае, когда одному экземпляру одной сущности соответствует много экземпляров другой сущности, и наоборот. Связь «многие ко многим» осуществляется через третью сущность, которая хранит наследуемые ключи, которые характеризуют взаимодействие родителей. Это связь требует введение суррогатного ключа. Суррогатный ключ – это счетчик, который меняет значения от 0 до .

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

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

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

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

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

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

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

5. Каждая ячейка хранит атомарное значение.

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

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

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

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

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

Виды нарушений атомарности:

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

2. присутствует скрытое групповое значение

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

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

Детерминант – зная одно значение, определяем второе значение.

А>В (А определяет В).

Функциональная зависимость – атрибут В функционально зависит от атрибута А.

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

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

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

Отношение находится в нормальной форме Бойса-Кодда, если оно находится в 3НФ и каждый детерминант является ключом-кандидатом.

Если атрибут В функционально зависит от атрибута А, то атрибут А называют детерминантом, а атрибут В – зависимой частью.

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

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

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

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

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

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

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

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

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

14