21 Гост р idef0 понятия системного анализа, преимущества недостатки и область применения:

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

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

Преимущества:

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

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

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

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

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

влияние внешней среды предприятия или системы может быть также объектом моделирования и исследования

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

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

Недостатки:

нет возможности задать временные и вероятностные параметры

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

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

дает больше поводов и возможностей сторонникам сопротивлений изменениям притормозить проект по описанию и оптимизации бизнес-процессов и дискредитировать его идею.

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

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

22 ГОСТ Р IDEF0 синтаксис графического языка IDEF0:

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

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

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

Синтаксические правила:

Для блоков установлены следующие синтаксические правила:

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

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

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

Для стрелок установлены следующие синтаксические правила:

ломаные стрелки изменяют направление только под углом 90°

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

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

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

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

23 ГОСТ Р IDEF0 семантика языка IDEF0:

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

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

Сводка семантических правил для блоков и стрелок:

Имя блока должно быть глаголом или глагольным оборотом.

Каждая сторона функционального блока имеет стандартное отношение блокстрелки:

входные стрелки должны связываться с левой стороной блока

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

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

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

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

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

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

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

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

24 ГОСТ Р IDEF0 иерархическая структура диаграмм, ссылочный код:

IDEF0-модели состоят из документов трех типов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга. Графическая диаграмма — главный компонент IDEFO-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть разбиты декомпозированы на составные части и представлены в виде более подробных диаграмм; процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта.

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

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

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

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

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

To, что блок является дочерним и раскрывает содержание родительского блока, на диаграмме предшествующего уровня указывается специальным ссылочным кодом, написанным ниже правого нижнего угла блока. Этот ссылочный код может формироваться несколькими способами, из которых самый простой заключается в том, что код, начинающийся с буквы А по имени диаграммы А-0, содержит цифры, определяемые номерами родительских блоков. Например, А61 А — имя блока А0, 6 — номер блока на диаграмме А0, 1 — номер блока на диаграмме А6.

25 ГОСТ Р IDEF0 отношения блоков на диаграммах, ICOM — кодирование граничных стрелок, туннель:

Существует 6 типов отношений между блоками:

1. доминирование — блоки выше и левее доминируют над нижними, остальные это внутренние стрелки

2. управление

3. выход — вход

4. обратная связь по управлению

5. обратная связь по входу

6. выход-механизм.

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

ICOM — кодирование граничных стрелок: ICOM коды связывают граничные стрелки на дочерней диаграмме, со стрелками родительского блока. . I — вход, C — управление, O — выход, M — механизм. Иногда эти коды могут меняться при переходе к дочерней диаграмме.

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

26 ГОСТ Р IDEF0 правила построения диаграмм:

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

1 В составе модели должна присутствовать контекстная диаграмма А-0, которая содержит только один блок. Номер единственного блока на контекстной диаграмме А-0 должен быть 0.

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

3 Диаграммы кроме диаграммы А-0 должны содержать не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм на уровне, доступном для чтения, понимания и использования. Диаграммы с количеством блоков менее трех вызывают серьезные сомнения в необходимости декомпозиции родительской функции. Диаграммы с количеством блоков более шести сложны для восприятия читателями и вызывают у автора трудности при внесении в нее всех необходимых графических объектов и меток.

4 Каждый блок неконтекстной диаграммы получает номер, помещаемый в правом нижнем углу; порядок нумерации — от верхнего левого к нижнему правому блоку от 1 до 6.

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

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

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

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

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

10 Если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления. Этим подчеркивается управляющий характер данных и уменьшается сложность диаграммы.

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

12 Стрелки связываются сливаются, если они представляют сходные данные и их источник не указан на диаграмме.

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

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

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

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

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

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

19 Тип интерфейса, показанный на рисунке 34, предпочтителен, поскольку в этом случае определяются конкретные данные, относящиеся к каждому блоку.

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

21 Каждая диаграмма IDEF0 изображается на стандартном бланке, именуемом мастер-страницей. Бланк снабжен верхним и нижним штампами, содержащими информацию как о конкретной диаграмме, так и в целом о проекте, в состав которого входит диаграмма..

27 Методика разработки функциональных моделей среде IDEF0 понятия: система, функциональный блок, потоки, информация:

Система: в IDEF0 требуется обязательно вход и выход. Вход — дискретное или непрерывное множество контактов, через которые воздействие среды передается системе. Выход — множество контактов, через которые система воздействует на среду. Любой элемент системы имеет, по крайней мере, один вход и один выход.

Функциональный блок: отображает систему в целом А-0, блоки на дочерних диаграммах — преобразующие — блок IDEF0 диаграммы, преобразующий входы в выходы под действием управления и механизмов. Преобразование — цель и результат работы любого блока на диаграмме любого уровня декомпозиции.

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

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

28 Методика разработки функциональных моделей среде IDEF0 классификация функций, моделируемых блоками IDEF0:

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

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

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

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

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

Субдеятельность — совокупность нескольких процессов, в составе деятельности, объединенная некоторой частной целью.

Подпроцесс — группа операций в составе процесса, объединенная технологически или организационно.

29 Организационно-технические структуры и механизмы IDEF0-моделей:

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

Деятельность Организационно-техническая система

Процесс Организационно-техническая подсистема

Операция Организационно-технический модуль комплекс

Действие Организационно-технический блок

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

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

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

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

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

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

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

30 Методика разработки функциональных моделей среде IDEF0, управление:

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

Управление деятельностью — процесс, состоящий как минимум из следующих операций:

формулирование целей деятельности

оценивание ресурсов, необходимых для осуществления деятельности и их сопоставление с имеющимися ресурсами

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

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

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

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

Управление процессом — операция, состоящая как минимум из следующих действий:

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

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

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

корректировка в случае необходимости директив на выполнение операций.

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

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

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

31 Интегрированная структурная модель расширенная DFD:

Собственно диаграммы потоков данных DFD Data Flow Diagrams — диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями. Дополняются словарями данных и спецификациями процессов нижнего уровня

Диаграммы сущность-связь ERD Entity-Relationship Diagrams — диаграммы, моделирующие данные и их взаимосвязи

Диаграммы переходов состояний STD State Transition Diagrams — диаграммы, моделирующие поведение системы.

32 Базовая нотация DFD:

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

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

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

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

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

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

33 Миниспецификации. Критерии для завершения детализации DFD — модели:

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

Требования к МС:

для каждого процесса нижнего уровня должна существовать одна и только одна спецификация

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

нет необходимости на данном этапе определять метод реализации этого преобразования

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

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

Критерии для завершения детализации:

наличия у процесса относительно небольшого количества входных и выходных потоков данных

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

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

возможности описания логики процесса при помощи МС небольшого объема.

34 Рекомендации оформления DFD:

размещать на каждой диаграмме от 3 до 6-7 процессов

не загромождать диаграммы несущественными на данном уровне деталями

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

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

35 Преимущества DFD:

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

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

Интеграция с последующими этапами. DFD могут быть легко преобразованы в модели проектирования информационной системы структурные карты — это близкие модели. Известен ряд алгоритмов автоматического преобразования иерархии DFD в структурные карты различных видов. Нет формальных методов преобразования SADT-диаграмм в проектные решения системы автоматизации.

36 Этапы построения моделей в DFD-технологии:

Разработка структурной функциональной модели бизнес-системы.

I. Разработка контекстной диаграммы

1. Идентификация внешних объектов, с которыми система взаимодействует.

2. Идентификация основных видов информации, циркулирующей между системой и внешними объектами.

3. Идентификация подсистем бизнес-системы если в этом есть необходимость.

4. Идентификация основных видов информации, циркулирующей между подсистемами в случае выполнения п. 1.3.

5. Построение контекстной диаграммы, на которой подсистемы представляются в виде контекстных процессов, внешние объекты — в виде внешних сущностей, основные виды информации — в виде потоков между внешними сущностями и контекстными процессами а также между контекстными процессами в случае выполнения п. 1.3.

6. Группирование потоков если в этом есть необходимость

II. Разработка диаграммы уровня основных процессов.

1. Идентификация бизнес-процессов с указанием их типов.

2. Группирование процессов по деятельностям.

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

4. Определение информационных потоков между процессами.

5. Идентификация базовых накопителей.

6. Определение информационных потоков между процессами и накопителями.

7. Построение DFD первого уровня на базе деятельностей и процессов.

III. Разработка иерархии диаграмм

1. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

2. Идентификация функций и операций каждого из процессов.

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

4. Определение информационных потоков между функциями.

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

6. Определение информационных потоков между функциями операциями и накопителями уровня процесса.

7. Построение DFD соответствующего уровня на базе функций.

IV. Анализ и оптимизация структурной функциональной модели.

Разработка информационной модели бизнес-системы

I. определение сущностей модели и их атрибутов

II. проведение атрибутного анализа и оптимизация сущностей

III. идентификация отношений между сущностями и определение типов отношений

IV. разрешение неспецифических отношений

V. анализ и оптимизация информационной модели.

Разработка событийной модели бизнес-системы

I. идентификация перечня состояний модели

II. определение возможностей переходов между состояниями

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

IV. анализ и оптимизация событийной модели.

37 Разработка структурной функциональной модели бизнес-системы DFD:

См. вопрос номер 36.

38 ERD-модель преимущества, недостатки, область применения:

Модель сущность-связь Entity-Relationship model, или ER-модель представляет собой высокоуровневую концептуальную модель данных, которая была разработана Ченом Chen в 1976 году с целью упрощения задачи проектирования баз данных. Концептуальная модель данных не зависит от конкретной СУБД или аппаратной платформы, которая используется для реализации базы данных.

Преимущества:

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

наглядность представления

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

интегрирование с DFD и IDEF1X

независимость от опр. СУБД

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

Недостатки:

ловушки разветвления и разрыва

необходимость в квалифицированных кадрах для корректной реализации модели

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

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

Применяется для полноценного проектирования структуры БД.

39 ERD — модель сущности:

Типы сущностей — объект или концепция, которые характеризуются на данном предприятии как имеющие независимое существование.

Сущность — экземпляр типа сущности, который может быть идентифицирован уникальным образом экземпляром сущности entity occurrence или entity instance.

Классификация типов сущности:

1. Слабый тип сущности — тип сущности, существование которого зависит от какого-то другого типа сущности.

2. Сильный тип сущности — тип сущности, существование которого не зависит от какого-то другого типа сущности. Слабые сущности иногда называют дочерними child, зависимыми dependent или подчиненными subordinate, а сильные — родительскими parent, сущностями-владельцами owner или доминантными dominant

Атрибут — свойство типа сущности или типа связи

Домен атрибута — набор значений, которые могут быть присвоены к атрибуту.

Простой атрибут — атрибут, состоящий из одного компонента с независимым существованием

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

Однозначный атрибут — атрибут, который содержит одно значение для одной сущности

Многозначный атрибут — атрибут, который содержит несколько значений для одной сущности

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

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

Первичный ключ — потенциальный ключ, который выбран в качестве первичного ключа.

Составной ключ — потенциальный ключ, который состоит из двух или больше атрибутов.

40 ERD — модель связи:

Тип связи — осмысленная ассоциация между сущностями разных типов.

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

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

Степень связи — количество сущностей, которые охвачены данной связью: бинарная, кватернарная, тернарная.

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

Рекурсивная связь унарная — одни и те же сущности участвуют несколько раз в разных ролях.

Связям могут присваиваться ролевые имена — для указания назначения каждой сущности — участницы данной связи. Ролевые имена могут так же использоваться, когда 2 сущности связанны несколькими связями две сущности связаны двумя связями.

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

41 ERD — модель структурные ограничения:

Показатель кардинальности описывает количество возможных связей для каждой из сущностей-участниц. Наиболее распространенными являются бинарные связи с показателями кардинальности один к одному 1:1, один ко многим 1:М и многие ко многим M:N.

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

Степень участия — определяет, зависит ли существование некоторой сущности от участия в связи некоторой другой сущности. Существует два варианта участия сущности в связи: полное total и частичное partial. Допустимо использование и альтернативного варианта обозначений структурных ограничений, накладываемых на некоторую связь, который предусматривает отображение максимальных Мах и минимальных Min значений в виде надписи Min, Max над линией соединения, обозначающей участие сущности в данной связи.

42 ERD — модель ловушки соединения:

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

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

Рисунки по ловушкам в тетради

43 EER-модель специализация/генерализация:

Специализация — процесс увеличения различий между отдельными членами типа сущности за счет выделения их отличительных характеристик. Нисходящий подход к определению множества классов и связанных с ними подклассов.

Генерализация — процесс сведения различий между сущностями к минимуму путем выделения их общих характеристик восходящий подход.

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

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

Сущность, ее подклассы, подклассы данных подклассов и так далее — иерархия типа type hierarchy.

иерархия специализации specialization hierarchy — например, подкласс Руководитель является специализацией суперкласса Работник

иерархия генерализации generalization hierarchy — например, суперкласс Работник является генерализацией подкласса Руководитель

иерархия принадлежности IS-A hierarchy — например, менеджер подкласс Руководитель является сотрудником принадлежит суперклассу Работник.

Ограничения на специализациюгенерализацию:

Ограничение непересечения

I. Непересекающиеся disjoint-d

II. Пересекающиеся nondisjoint-o.

Ограничение участия:

I. Полное

II. Частичное.

44 EER — модель категоризация:

Категоризация — моделирование одного подкласса со связью, которая охватывает несколько разных суперклассов.

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

45 Методология проектирования:

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

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

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

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

46 Концептуальное проектирование базы данных:

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

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

47 Логическое проектирование базы данных:

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

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

48 Физическое проектирование базы данных:

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

// 49 Факторы успешного завершения проектирования БД:

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

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

Разрабатывайте систему исходя из существующих характеристик данных.

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

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

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

Для описания дополнительных семантических требований к данным используйте средства языка DBDL Database Design Language.

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

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

// 50 Первый этап проектирования БД задачи и подэтапы:

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

Этап 1.1. Определение типов сущностей.

Этап 1.2. Определение типов связей.

Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей.

Этап 1.4. Определение доменов атрибутов.

Этап 1.5. Определение атрибутов, являющихся потенциальными и первичными ключами.

Этап 1.6. Специализация или генерализация типов сущностей необязательный этап.

Этап 1.7. Создание диаграммы сущность-связь.

Этап 1.8. Обсуждение локальных концептуальных моделей данных с конечными пользователями.

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

// 51 Второй этап проектировании БД задачи и подэтапы:

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

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

Этап 2.2. Определение набора отношений исходя из структуры локальной логической модели данных.

Этап 2.3. Проверка модели с помощью правил нормализации.

Этап 2.4. Проверка модели в отношении транзакций пользователей.

Этап 2.5. Создание диаграмм сущность-связь.

Этап 2.6. Определение требований поддержки целостности данных.

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

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

// 52 Третий этап проектирования БД задачи и подэтапы:

Этап 3. Создание и проверка глобальной логической модели данных.

Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных.

Этап 3.2. Проверка глобальной логической модели данных.

Этап 3.3. Проверка возможностей расширения модели в будущем.

Этап 3.4. Создание окончательного варианта диаграммы сущность-связь.

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

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

53 Первый этап проектирования БД характеристика подэтапов:

Этап 1.1. Определение типов сущностей:

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

1. Извлечь существительные.

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

Альтернатива объекты, существующие независимо от других

Документирование типов сущностей

Этап 1.2. Определение типов связей:

Цель: Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе

выбираются все выражения, в которых содержатся глаголы.

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

Документирование типов связей.

Использование средств ER-моделирования.

Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей:

Цель: Связывание атрибутов с соответствующими типами сущностей или связей.

Атрибуты простые и составные.

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

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

Сведения об атрибутах:

имя атрибута и его описание

любые псевдонимы, или синонимы, имеющиеся для данного атрибута

тип данных и размерность значения

значение, принимаемое для атрибута по умолчанию если таковое имеется

является ли атрибут обязательным т.е. может ли он отсутствовать или иметь значение NULL

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

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

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

Этап 1.4. Определение доменов атрибутов:

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

Домены должны содержать следующие данные:

набор допустимых значений для атрибута

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

сведения о допустимых операциях со значениями атрибута,

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

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

Этап 1.5. Определение потенциальных и первичного ключей:

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

Потенциальный ключ слабой сущности.

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

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

Этап 1.6. Специализация или генерализация типов сущностей:

Цель: Определение суперклассов и подклассов для типов сущностей если это необходимо.

Этап 1.7. Создание диаграммы сущность-связь:

Цель: Разработка диаграмм сущность-связь ER-диаграмм, содержащих концептуальное отражение представлений пользователя о предметной области приложения.

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

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

54 Второй этап проектировании БД характеристика подэтапов:

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

Этап 2.1 Преобразование локальной концептуальной модели данных в локальную логическую модель:

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

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

Этап 2.2 Определение набора отношений исходя из структуры локальной логической модели данных:

Цель: Определение набора отношений на основе локальной логической модели данных.

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

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

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

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

Для каждой бинарной связи типа 1:М между сущностями Е1 и Е2, необходимо переслать копию атрибутов первичного ключа сущности Е1 в отношение, представляющее сущность Е2, где они будут играть роль внешнего ключа. Сущность, представляющая единичную сторону связи определяется как родительская. Сущность, представляющая множественную сторону, — как дочерняя.

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

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

Этап 2.3 Проверка модели с помощью правил нормализации:

Цель: Проверка локальной логической модели данных с использованием технологии нормализации.

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

приведение ко второй нормальной форме 2НФ, позволяющее устранить частичную зависимость атрибутов от первичного ключа

приведение к третьей нормальной форме ЗНФ, позволяющее устранить транзитивную зависимость атрибутов от первичного ключа

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

Этап 2.4. Проверка модели в отношении транзакций пользователей:

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

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

Два подхода проверки соответствия логической модели:

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

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

Этап 2.5 Создание диаграмм сущность-связь:

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

Этап 2.6. Определение требований поддержки целостности данных:

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

Этап 2.7. Обсуждение с конечными пользователями:

Цель: Убедиться, что созданные локальные модели данных точно отражают представления пользователей о предметной области приложения.

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

55 Третий этап проектирования БД характеристика подэтапов:

Создание и проверка глобальной логической модели данных.

Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных:

Цель: Объединить отдельные локальные логические модели данных в единую глобальную логическую.

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

Подэтапы:

анализ имен сущностей и их первичных ключей

анализ имен связей

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

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

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

проверка на наличие пропущенных сущностей и связей

проверка корректности внешних ключей

проверка соблюдения ограничений целостности

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

обновление документации

Этап 3.2. Проверка глобальной логической модели данных:

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

Этап 3.3. Проверка возможностей расширения модели в будущем:

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

Этап 3.4. Создание окончательного варианта диаграммы сущность-связь:

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

Этап 3.5. Обсуждение глобальной логической модели данных с пользователями:

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

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

см. вопрос 54, этап 2.1

62 ГОСТ СТ СЭВ 19.201-78, ГОСТ СТ СЭВ 19.101-77, ГОСТ 19.102-77:

ГОСТ 19.101-77: ВИДЫ ПРОГРАММ И ПРОГРАММНЫХ ДОКУМЕНТОВ установлен с 01.01 1980 г.

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

Виды программ.

Виды программных документов.

Виды эксплуатационных документов.

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

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

ГОСТ 19.102-77: СТАДИИ РАЗРАБОТКИ установлен с 01.01 1980 г.

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

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

ГОСТ 19.201-78: ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ установлен с 01.01. 1980 г. Переиздан в ноябре 1987г с изм.1.

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

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

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

Обоснование необходимости разработки программы

Постановка задачи.

Сбор исходных материалов.

Выбор и обоснование критериев эффективности и качества разрабатываемой программы.

Обоснование необходимости проведения научно-исследовательских работ.

Научно-исследовательские работы. Разработка и утверждение технического задания

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

63 Стандарты комплекса ГОСТ 34:

ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Объектами стандартизации являются АС различных видов и все виды их компонентов, а не только ПО и БД. Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO12207 предусмотрено, что заказчик может разрабатывать АС для себя сам если создаст для этого специализированное подразделение. Однако формулировки ГОСТ 34 не ориентированы на столь явное и, в известном смысле, симметричное отражение действий обеих сторон, как ISO12207. Поскольку ГОСТ 34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно делается отталкиваясь от этого содержания.

Стандарты предусматривают стадии и этапы выполнения работ по созданию АС, но не предусматривают сквозных процессов в явном виде.

Стадии разработки АС

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

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

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

Степень обязательности:

Прежняя полная обязательность отсутствует, материалы ГОСТ 34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС. При этом польза ГОСТ34 может многократно возрасти в случае их более гибкого использования при формировании профиля ЖЦ АС.

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

64 ГОСТ 34.602-89:

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ Дата введения с 01.01.1990г.

Настоящий стандарт распространяется на автоматизированные системы АС для автоматизации различных видов деятельности управление, проектирование, исследование и т. п., включая их сочетания, и устанавливает состав, содержание, правила оформления документа Техническое задание на создание развитие или модернизацию системы ТЗ на АС.

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

Дополнительно могут быть разработаны ТЗ на части АС: на подсистемы АС, комплексы задач АС, на комплектующие средства технического обеспечения и программно-технические комплексы, на программные средства, на информационные.

Включаемые в ТЗ на АС требования должны соответствовать современному уровню развития науки и техники.

ТЗ на АС содержит следующие разделы: общие сведения;

назначение и цели создания развития системы; характеристика объектов автоматизации; требования к системе; состав и содержание работ по созданию системы; порядок контроля и приемки системы; требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие; требования к документированию; источники разработки. В ТЗ на АС могут включаться приложения.

65 ЕСПД для ПС преимущества, недостатки, область применения :

Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации ЕСПД. Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е гг. Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС. Стандарты ЕСПД ГОСТ 19 носят рекомендательный характер.

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

Недостатки: Ориентация на единственную, каскадную модель жизненного цикла ЖЦ ПС. Отсутствие четких рекомендаций по документированию характеристик качества ПС. Отсутствие системной увязки с другими действующими отечественными системами стандартов по ЖЦ и документированию продукции в целом, например, ЕСКД. Нечетко выраженный подход к документированию ПС как товарной продукции. Отсутствие рекомендаций по самодокументированию ПС, например, в виде экранных меню и средств оперативной помощи пользователю хелпов. Отсутствие рекомендаций по составу, содержанию и оформлению перспективных документов на ПС, согласованных с рекомендациями международных и региональных стандартов.

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

Где требуется:

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

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

автоматизация изготовления и хранения программной документации

66 Краткое представление стандартов ЕСПД. Обозначение ЕСПД:

Стандарты ЕСПД подразделяют на группы

Обозначение стандарта ЕСПД состоит из:

числа 19 присвоенных классу стандартов ЕСПД;

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

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

В состав ЕСПД входят:

основополагающие и организационно-методические стандарты;

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

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

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

Перечень документов ЕСПД:

ГОСТ 19.001-77. ЕСПД. Общие положения

ГОСТ 19.002-80. ЕСПД. Схемы алгоритмов и программ. Правила выполнения

ГОСТ 19.003-80. ЕСПД. Схемы алгоритмов и программ. Обозначение условные графические

ГОСТ 19.004-80. ЕСПД. Термины и определения

ГОСТ 19.101-77. ЕСПД. Виды программ и программных документов

ГОСТ 19.102-77. ЕСПД. Стадии разработки

ГОСТ 19.103-77. ЕСПД. Обозначение программ и программных документов

ГОСТ 19.104-78. ЕСПД. Основные надписи

ГОСТ 19.105-78. ЕСПД. Общие требования к программным документам

ГОСТ 19.106-78. ЕСПД. Требования к программным документам, выполненным печатным способом

ГОСТ 19.201-78. ЕСПД. Техническое задание. Требования к содержанию и оформлению

ГОСТ 19.202-78. ЕСПД. Спецификация. Требования к содержанию и оформлению

ГОСТ 19.301-79. ЕСПД. Программа и методика испытаний. Требования к содержанию и оформлению

ГОСТ 19.401-78. ЕСПД. Текст программы. Требования к содержанию и оформлению

ГОСТ 19.402-78. ЕСПД. Описание программы

ГОСТ 19.403-79. ЕСПД. Ведомость держателей подлинников

ГОСТ 19.404-79. ЕСПД. Пояснительная записка. Требования к содержанию и оформлению

ГОСТ 19.501-78. ЕСПД. Формуляр. Требования к содержанию и оформлению

ГОСТ 19.502-78. ЕСПД. Описание применения. Требования к содержанию и оформлению

ГОСТ 19.503-79. ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению

ГОСТ 19.504-79. ЕСПД. Руководство программиста. Требования к содержанию и оформлению

ГОСТ 19.505-79. ЕСПД. Руководство оператора. Требования к содержанию и оформлению

ГОСТ 19.506-79. ЕСПД. Описание языка. Требования к содержанию и оформлению

ГОСТ 19.507-79. ЕСПД. Ведомость эксплуатационных документов

ГОСТ 19.508-79. ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению

ГОСТ 19.601-78. ЕСПД. Общие правила дублирования, учета и хранения

ГОСТ 19.602-78. ЕСПД. Правила дублирования, учета и хранения программных документов, выполненных печатным способом

ГОСТ 19.603-78. ЕСПД. Общие правила внесения изменений

ГОСТ 19.604-78. ЕСПД. Правила внесения изменений в программные документы, выполненные печатным способом

48