Лекция 11 СТРУКТУРНЫЙ АНАЛИЗ ПОТОКОВ ДАННЫХ DFD-МОДЕЛЬ ПРОЦЕССОВ

Лекция 11. СТРУКТУРНЫЙ АНАЛИЗ ПОТОКОВ ДАННЫХ. DFD-МОДЕЛЬ ПРОЦЕССОВ Лекция 11 МЕТОДОЛОГИЯ DFD. НОТАЦИИ DFD Моделирование потоков данных/процессов Gane/Sarson Методологии структурного анализа Йордана/де Марко СИНТАКСИС И СЕМАНТИКА ДИАГРАММ ПОТОКОВ ДАННЫХ Процесс Потоки данных (стрелки) Хранилище данных Внешняя сущность ПОСТРОЕНИЕ ДИАГРАММ ПОТОКОВ ДАННЫХ Контекстная диаграмма и детализация процессов декомпозицией данных ДОПОЛНИТЕЛЬНЫЕ СРЕДСТВА ОПИСАНИЯ ПРОЦЕССОВ Спецификации процессов обработки данных СЛОВАРЬ ДАННЫХ БНФ – нотация ПРИМЕР DFD-ДИАГРАММЫ ДЛЯ ПРЕДПРИЯТИЯ, СТРОЯЩЕГО СВОЮ ДЕЯТЕЛЬНОСТЬ ПО ПРИНЦИПУ «ИЗГОТОВЛЕНИЕ НА ЗАКАЗ» . ПРИМЕР DFD-ДИАГРАММЫ ДЛЯ ПРОЦЕССА «СДАТЬ Лекция 1 1 ЭКЗАМЕН» 1

СТРУКТУРНЫЙ АНАЛИЗ - это систематический пошаговый подход к анализу требований и проектированию спецификаций системы независимо от того, является ли она существующей или создается вновь. Методология структурного анализа определяет работы, которые должны быть выполнены, их последовательность, правила распределения и назначения операций и методов. В настоящее время существует несколько десятков подходов, или стандартов, описания бизнес-процессов — ARIS, IDEF 0 и др. При этом, часто встает трудная задача: разобраться во всем этом многообразии и принять окончательное решение о том, какой стандарт в данной ситуации использовать. Классическая технология описания бизнес-процессов достаточно проста и состоит из двух стандартов описания бизнес-процессов • диаграммы потоков данных (Data flow diagrams или DFD) являются базовым диаграммы потоков данных понятием для многих традиционных методов моделирования. Используется для описания бизнес-процессов верхнего уровня. • стандарт WFD (Work Flow Diagram). Представляет собой диаграмму потоков работ, стандарт WFD используемую для описания бизнес-процессов нижнего уровня. У диаграммы потоков работ имеется и другое название — диаграмма алгоритмов. Большинство других современных стандартов, несмотря на другие названия, представляют разновидности и дополнения двух классических подходов DFD и WFD. Лекция 11 2

Методология разработки процессных диаграмм применяется в проектах информатизации и автоматизации крупных объектов при экспрессобследовании (обычно для составления развернутого плана работ). Так же, как и диаграммы IDEF 0, диаграммы потоков данных моделируют систему как набор действий, соединенных друг с другом стрелками. Внешне методология DFD сходна с методологией SADT, но отличается по набору используемых элементов. В этой методологии исследуемый процесс также разбивается на подпроцессы и представляется в виде сети, связанной потоками данных. Считается, что DFD лучше приспособлена для построения моделей создаваемых систем автоматизации управления, в то время как SADT ориентирована на общие аспекты построения модели системы управления. DFD (Data Flow Diagramming) - это стандарт моделирования, в котором система представляется в виде сети работ, соединенных между собой объектами, взаимодействующими с результатами данных работ. Их можно использовать как дополнение к модели IDEF 0 для наглядного отображения текущих операций в системах обработки информации. Лекция 11 Лекция 1 3 3

DFD - это граф, на котором показано движение значений данных от их источников через преобразующие их процессы к их потребителям в других объектах. Лекция 11 Диаграммы DFD являются средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Согласно методологии моделируется не последовательность работ, а именно потоки информации (данных) между работами и объектами, которые используют, хранят или "рождают" эти данные. 4

Главная цель - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Цели: • построение модели системы в виде набора DFD-диаграмм потоков данных, • правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). • моделирование системы как взаимосвязанного набора действий, которые обрабатывают данные как внутри, так и вне границ моделируемой системы. DFD-диаграммы используется для графического представления движения и обработки информации в любом процессе, чаще всего для отображения третьего и ниже уровня декомпозиции бизнес-процессов (первым уровнем третьего и ниже уровня декомпозиции бизнес-процессов считается идентифицированный перечень бизнес-процессов, а вторым - функции, выполняемые в рамках бизнес-процессов): Лекция 11 Лекция 1 5 5

Применяются как дополнение к модели IDEF 0 • для более наглядного отображения текущих операций документооборота (обмена информацией), поскольку описывают потоки данных, причём не важно — электронным, бумажным или смешанным способом. • позволяют проследить, каким образом происходит обмен информацией как внутри системы между бизнес-функциями, так и системы в целом с внешней информационной средой; • позволяют представить систему с точки зрения данных; • иллюстрируют внешние механизмы подачи данных, которые потребуют наличия специальных интерфейсов; • позволяют представить как автоматизированные, так и ручные процессы системы; • выполняют ориентированное на данные секционирование системы. Лекция 11 6

Созданные модели потоков данных организации могут быть использованы при решении таких задач, как: • определение существующих хранилищ данных (текстовые документы, файлы, СУБД); определение существующих хранилищ данных • определение и анализ данных, необходимых для выполнения каждой функции определение и анализ данных процесса; • подготовка к созданию модели структуры данных организации; созданию модели структуры • выделение основных и вспомогательных бизнес-процессов организации. основных и вспомогательных бизнес-процессов Нотации DFD нужны для описания реально существующих в организации потоков данных. Описания могут создаваться • по процессному признаку - для получения модели бизнес-процессов в формате DFD по процессному признаку • по функциональному признаку – для получения схемы обмена данными между по функциональному признаку подразделениями. Диаграммы потоков данных имеют ограниченный набор графических элементов для представления структуры системы и ее интерфейсов. Несмотря на то, что изначально диаграммы потоков данных предназначались для описания информации и информационных потоков, диаграммы этого типа могут использоваться для описания потоков любого типа, независимо от того базируется система на использовании компьютерной техники или нет. К сожалению, диаграмма потоков данных не отражает один важный поток информации - поток управления. Лекция 1 7 Лекция 11 7

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

Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEFO: • строится физическая модель, отображающая текущее состояние дел; • полученная модель преобразуется в логическую модель, которая отображает требования к существующей системе; • строится модель, отображающая требования к будущей системе; • строится физическая модель, на основе которой должна быть построена новая система. Лекция 11 Подход, применяемый при создании ПО, ПО называемый событийным разделением (event partitioning), в котором диаграммы DFD выстраивают модель системы: • логическая модель строится как совокупность логическая модель процессов и документирования того, что эти процессы должны делать; • модель окружения (environment model) модель окружения содержит описание цели системы, контекстную диаграмму, внешние сущности, с которыми система взаимодействует, ссылки и некоторые стрелки, импортированные из диаграмм IDEF 0. ; • модель поведения (behavior model) модель поведения показывает, как система обрабатывает события. Модель состоит из одной диаграммы, в которой каждый блок изображает событие из модели окружения. могут быть добавлены хранилища для данных, которые необходимо запоминать между событиями. Лекция 1 9 9

Диаграммы потоков данных • хорошо отображают функции и интерфейсы. • отображают в целом потоки данных и функциональность системы; • могут использоваться для определения системных транзакций типа «начало- конец» (end-to-end transactions), хотя и отражают их только косвенно. • хорошо подходят для представления структур, • определяют функции, потоки и хранилища данных; • обеспечивают базу для получения системных требований; • имеют инструментальные средства для работы с ними (специальное ПО); Лекция 11 • широко используются в разработке ПО; • применимы для проектирования системам вообще (не только для ПО). • гораздо менее точны, чем текстовое представление разрабатываемой системы. На диаграмме потоков данных линии связи могут быть неоднозначны, любое слово диаграммы может иметь массу значений. • нельзя корректно отображать ограничения. 10

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

Нотации DFD Диаграммы DFD являются средством моделирования функциональных требований проектируемой системы. С их помощью требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Первоначально диаграммы DFD разрабатывались и использовались при проектировании ИС, (SADT - как средство проектирования систем вообще), поэтому имеют богатый набор элементов, адекватно отражающих их специфику (хранилища данных как прообраз файлов или баз данных). В настоящее время область применения DFD значительно расширилась и их используют: • при проведении обследования деятельности предприятия; • при проведении работ по реинжинирингу; • при анализе и оптимизации бизнес-процессов предприятия; • при внедрении систем электронного документооборота. Лекция 11 Лекция 1 12 12

При построении диаграмм потоков данных используются две методологии, разработанные на основе DFD, и обладающими собственными нотациями: • метод структурного системного анализа Гейна/Сарсона. Авторы - Крис Гейн (Chris Gane) и Триш Сарсон (Trish Sarson). • метод структурного анализа и проектирования Йордана/Де Марко. Авторы - Йордан (Yourdon) и Де Марко (De. Marco). В соответствии с данными методами МОДЕЛЬ СИСТЕМЫ определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Методологии поддерживаются нисходящими методами проектирования спецификаций и обеспечивают один из лучших способов связи между аналитиками, разработчиками и пользователями системы. Целью методологий является преобразование общих, неясных знаний о требованиях к системе в точные (насколько это возможно) определения. Обе методологии фокусируют внимание на потоках данных, их главное назначение - создание базированных на графике документов по функциональным требованиям. Функциональные требования на диаграммах представляются с помощью процессов и хранилищ, связанных потоками данных. Лекция 11 13

В диаграммах DFD используемые символы складываются в картину, которая дает четкое представление о том, какие данные используются и какие функции выполняются системой. При этом используются следующие средства: • DFD-ДИАГРАММЫ потоков данных. Являются графическими иерархическими спецификациями. На диаграмме показываются работы, которые входят в состав описываемого бизнес-процесса, а также показываются входы и выходы каждой из работ. Входы и выходы представляют из себя информационные, либо материальные потоки. Выходы работы могут являться входами. • СЛОВАРИ ДАННЫХ. Являются каталогами всех присутствующих в DFD элементов данных, , включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты. • МИНИСПЕЦИФИКАЦИИ ОБРАБОТКИ. Описывают DFD-процессы нижнего уровня и являются базой для кодогенерации. Миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами. Множество миниспецификаций является полной спецификацией системы. Лекция 1 14 Лекция 11 14

Лекция 11 Пример диаграммы DFD 15

Основные структурные элементы DFD-диаграмм Процессы. Назначение состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя должно содержать глагол в неопределенной форме с последующим дополнением (например, ВЫЧИСЛИТЬ МАКСИМАЛЬНУЮ ВЫСОТУ). Каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Лекция 11 Потоки данных изображаются именованными стрелками, ориентация которых указывает направление движения информации от объекта-источника к объекту-приемнику. Являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую. Стрелками на DFD-диаграмме связываются функции, хранилища и внешние сущности. Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним - двунаправленным. Стрелки могут разветвляться или сливаться, что означает, соответственно, разделение потока данных на части, либо слияние объектов. Лекция 1 16 16

Внешние сущности (или терминатор) Хранилища (накопитель) данных представляет сущность вне контекста системы, с которыми бизнес-процесс взаимодействует. Определяют элементы, которые участвуют в процессе обмена информацией с системой, являющуюся источником или приемником системных данных. Изображают входы в систему и/или выходы из системы на контекстной диаграмме. Представляют собой материальный предмет или физическое лицо. Имя должно содержать существительное: ЗАКАЗЧИК, ПЕРСОНАЛ, ПОСТАВЩИК, КЛИЕНТ, СКЛАД, БАНК. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке. Лекция 11 позволяет определять данные, которые могут быть созданы или изменены процессами, и будут сохраняться в памяти между процессами. Фактически представляет "срезы" потоков данных во времени. Информация, которую содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя должно идентифицировать содержимое и быть существительным. Хранилище данных изображают объекты в покое и данные, которые сохраняются в памяти между последующими процессами. . 17

При интерпретации DFDдиаграммы используются следующие правила: • функции преобразуют входящие потоки данных в выходящие; • хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов; • преобразования потоков данных во внешних сущностях игнорируются. Пример традиционного использования диаграммы потоков данных для моделирования ИС Лекция 11 Лекция 1 18 18

DFD-схема бизнес-процесса "Оформлении и выдача трудовой книжки сотруднику при увольнении" в нотации Гейна-Сарсона Лекция 11 В качестве хранилища данных выступают сейф, в котором хранятся трудовые книжки и архив, в который помещается заполненный обходной лист. В качестве внешней сущности выступает сотрудник, который увольняется и который получает выход рассматриваемого бизнес-процесса – трудовую книжку. 19

Моделирование потоков данных/процессов Gane/Sarson В основе методологии лежит построение модели ИС - проектируемой или реально существующей. Модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Авторами методологии классическая DFD-схема усложнена. Предложено ввести дополнительный объект, с помощью которого показываются места бизнес-процесса, в которых хранится информация, либо материальные ресурсы (ХРАНИЛИЩЕ ДАННЫХ). Примерами таким мест являются: • архив, в котором хранятся документы, • база данных, в которой хранится информация, • склад, на котором хранятся материальные ресурсы. Лекция 11 Лекция 1 20 20

Отличительные признаки методологии: • моделирование от существующей системы до разработки новой (физической и логической моделей); • стратегия построения требований для разработки системы состоит из: стратегия построения требований • моделирования текущих операций; • выявления причин выполнения именно этих операций; • добавления новых требований; • выбора границ автоматизации. • наличие этапа моделирования данных, определяющего содержимое наличие этапа моделирования данных хранилищ данных (БД и файлов) в DFD в третьей нормальной форме. Этот этап включает • построение списка элементов данных, располагающихся в каждом хранилище данных; • анализ отношений между данными и построение соответствующей диаграммы связей между элементами данных; • представление всей информации по модели в виде связанных нормализованных таблиц. Лекция 11 21

Диаграмма основных бизнес-процессов Лекция 11 Лекция 1 22 22

Методологии структурного анализа Йордана/де Марко DFD-схема бизнес-процесса "Оформлении и выдача трудовой книжки сотруднику при увольнении" в нотации Йордона-Де Марко Лекция 11 Лекция 1 В первом приближении эта нотация аналогична нотации Гейна Сарсона, за исключение форм объектов: для описаний операций бизнес-процесса вместо закругленных прямоугольников стали использоваться круги, немного видоизменились и другие объекты – хранилище данных и внешние сущности Из-за того, что процессы на диаграмме представляются в виде кружков, похожих на пузырьки, диаграмму потоков данных часто называют "пузырьковой диаграммой". диаграммой 23 23

Отличительные признаки: • не рекомендуется моделировать текущую ИС; • добавлена предварительная фаза разработки, названная созданием основной модели (essential model); • определена техника "событийного разбиения" (event partitioning), для конструирования DFDсхемы; • больше внимания уделяется информационному моделированию (посредством ER-диаграмм) и моделированию поведения (через STDдиаграмм); • указано место прототипирования в жизненном цикле разработки; • имеется описание семантики потоков и правила преобразования входных данных в выходные. Лекция 11 24

Процесс Понятие «процесс» применяется для описания преобразования входящих потоков данных в выходные потоки данных в соответствии с определенным потоков данных в выходные потоки данных алгоритмом, задаваемым именем процесса. В DFD не показываются процессы, которые управляют потоком данных и не приводятся различия между допустимыми и недопустимыми путями. В реальной жизни процесс может выполняться • подразделением организации, выполняющим обработку входных документов и выпуск отчетов, • отдельным сотрудником, • программой, установленной на компьютере, • Аппаратно-реализованным логическим устройством • и тому подобное. При построении модели процесса с использованием хранилищ данных, необходимо помнить, что данные не могут перемещаться между функциями процесса сами по себе. Они могут быть переданы только посредством определенных посредников – хранилищ данных. Лекция 11 25

Модель процесса в нотации DFD, построенная с использованием понятия «хранилище данных» . Позволяет аналитику строго определить функции, реализуемые структурным элементом, указать на информацию, необходимую для выполнения данных функций. Лекция 11 Лекция 1 26 26

Функциональные блоки DFD и изображаются в виде прямоугольников с закругленными углами, они почти идентичны функциональным блокам IDEF 0 и действиям IDEF 3. Как и действия IDEF 3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения как IDEF 0. В некоторых интерпретациях нотации DFD Гейна — Сарсона механизмы исполнения IDEF 0 моделируются как ресурсы и изображаются в нижней части прямоугольника. В графическом изображении DFD-блока, независимо от применяемой нотации имеется поле для ввода DFD-БЛОКИ – графическое DFD-БЛОКИ имени процесса. изображение операции Имена процессов выбираются таким образом, (процесса, функции, работы) по чтобы выразить некое действие и объект этого обработке или преобразованию действия, который обычно совпадает с выходным информации (данных). потоком данных этого процесса. Функциональный блок DFD Рекомендуется каждой работе присвоить номер или моделирует функцию, которая идентификатор. Этот номер может использоваться преобразует вход в выход. совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Лекция 11 27

Процессы в нотации Йордана/де Марко изображается в виде эллипса, внутри которого помещается имя процесса; каждый процесс имеет фиксированное число входных и выходных данных, изображаемых стрелками. Имя процесса пишется заглавными буквами в кружке и представляет собой указание на действие, выполняемое процессом. Лекция 11 Лекция 1 28 28

ПОТОКИ ДАННЫХ (стрелки) Стрелки в DFD показывают лишь то, как объекты (включая данные) реально перемещаются от одного действия к другому. В DFD диаграммах не используются стрелки управления для обозначения правил выполнения действия и стрелки механизмов для обозначения требуемых ресурсов. ПОТОКИ ДАННЫХ (Data Flow) являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) между участниками процесса информационного обмена (функциями, хранилищами данных, внешними ссылками) из одной части системы в другую через некоторое соединение (кабель, почтовая связь, курьер) от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т. д. Потоки отображают либо информационный, либо материальный обмен между информационный, либо материальный обмен двумя элементами преобразования. В реальной жизни эти потоки могут быть непрерывными, запускаться по запросу, быть асинхронными и т. д. В соответствии с нотацией диаграмма должна сопровождаться текстовым описанием каждого процесса, хранилища данных и потока данных. Лекция 11 29

В DFD также используются двунаправленные стрелки, которые нужны для отображения взаимодействия между блоками (например, диалога типа приказ— результат выполнения). Потоки данных, которыми обмениваются процессы и внешние сущности, выделяются после определения полной таблицы событий. Простейший способ их выделения заключается Стрелки описывают передвижение (поток) в анализе таблиц событий. объектов от одной части системы к другой. События преобразуются в потоки Поскольку все стороны обозначающего данных от инициатора события к функциональный блок DFD запрашиваемому процессу, а прямоугольника равнозначны (в отличие реакции – в обратный поток от IDEF 0), стрелки могут начинаться и событий. заканчиваться в любой части блока. Лекция 11 Лекция 1 30 30

После построения входных и выходных потоков аналогичным образом строятся внутренние потоки. Для их выделения для каждого из внутренних процессов выделяются поставщики и потребители информации. Если поставщик или потребитель информации представляет процесс сохранения или запроса информации, то вводится хранилище данных, для которого данный процесс является интерфейсом. Поток данных соединяет выход объекта (или процесса) с входом другого объекта (или процесса). Он представляет промежуточные данные вычислений. Потоки данных между работами в DFD возможны не только опосредованно, через хранилища данных, но и непосредственно между работами, если данные не поступают сначала в хранилище. Потоки данных на диаграммах (документы, объекты, сотрудники, отделы или иные участники обработки информации) изображаются именованными стрелками между двумя объектами DFD-диаграммы, предпочтительно горизонтальной и/или вертикальной. СТРЕЛКИ указывают направление движения информации (между производителем и потребителем данных), помеченной именами соответствующих данных и являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую. Лекция 11 31

Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним - двунаправленным. Двунаправленные стрелки между функцией и внешней сущностью и/или между внешними сущностями нужны в DFD-диаграммах для описания взаимодействия между блоками типа команды-ответа между операциями (например, диалога типа приказ — результат выполнения). Стрелки могут разветвляться или сливаться, что означает декомпозицию стрелок, т. е. разделение потока данных на части, либо слияние объектов. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя , отражающее его содержание. Это наименование должно быть выбрано таким образом, чтобы в наибольшей степени передавать смысл содержания потока пользователям, которые будут рассматривать диаграмму потоков данных. Набрасывая диаграмму потоков данных, можно опустить наименования, если оно является очевидным для пользователя, но разработчик диаграммы должен в любой момент представить описание потока. Лекция 11 Лекция 1 32 32

Разветвление стрелки в нотации Гейн-Сарсона Лекция 11 Объединение потока в один в нотации Гейн-Сарсона 33

После построения потоков данных диаграмма должна быть проверена на полноту и непротиворечивость: • полнота диаграммы обеспечивается, если в системе нет "повисших" процессов, не используемых в процессе преобразования входных потоков в выходные. • непротиворечивость системы обеспечивается выполнением наборов формальных правил о возможных типах процессов: o на диаграмме не может быть потока, связывающего две внешние сущности – это взаимодействие удаляется из рассмотрения; o ни одна сущность не может непосредственно получать или отдавать информацию в хранилище данных – хранилище данных является пассивным элементом, управляемым с помощью интерфейсного процесса; o два хранилища данных не могут непосредственно обмениваться информацией – эти хранилища должны быть объединены. Лекция 11 Лекция 1 34 34

Потоки данных в нотации Йордана/де Марко Лекция 11 Лекция 1 35 35

Хранилище данных Это пассивный объект в составе DFD, в котором данные сохраняются в памяти между процессами для последующего доступа. В то время как потоки данных представляют объекты в процессе их передвижения, хранилища данных моделируют их во всех ХРАНИЛИЩЕ ДАННЫХ (Data остальных состояниях. Store, Data Storage, накопитель) При моделировании производственных систем - графическое представление хранилищами данных служат места неких абстрактных устройств временного складирования, где хранится для хранения информации, продукция на промежуточных стадиях например, папка с обработки. документами, ящика в В информационных системах хранилища картотеке, таблицы в данных представляют любой механизм, оперативной памяти, файл на магнитном диске, т. е. являются который поддерживает хранение данных для их промежуточной обработки. неким прообразом БД ИС организации. Лекция 11 36

Содержимое хранилища данных существует независимо от активации процесса, который заполняет его данными. Копии данных можно получать из хранилища до тех пор, пока они не будут заменены новыми данными. Таким образом хранилище представляет "срезы" потоков данных во времени, т. е. являются неким прообразом базы данных информационной системы организации. Информацию, которую оно содержит, можно использовать в любое время после ее определения, при этом данные могут выбираться в произвольном порядке. Хранилища данных используются: : • в материальных системах - там, где объекты ожидают обработки, например в очереди; • в системах обработки информации для моделирования механизмов сохранения данных для дальнейших операций. При отображении процесса сохранения данных стрелка потока данных направляется в хранилище данных, и, наоборот – из хранилища, если идет импорт данных. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое. Лекция 11 Лекция 1 37 37

Внутри символа хранилища данных указывается его уникальное в рамках данной модели имя, наиболее точно, с точки зрения аналитика, отражающее информационную сущность содержимого. Имя хранилища должно идентифицировать его содержимое и быть существительным, например, «Поставщики» , «Заказчики» , «Счета-фактуры» , «Накладные» . Каждый номер хранилища данных содержит префикс D (Data Store) и уникальный номер хранилища в модели (например, D 3). В модели может быть создано множество вхождений хранилищ данных, каждое из которых может иметь одинаковое имя и ссылочный номер, что позволяет сократить длину линий потоков данных. Для того, чтобы не усложнять диаграмму потоков данных пересечениями линий, можно изображать дубликаты накопителя данных дополнительными вертикальными линиями с левой стороны квадрата. Содержимое каждого хранилища сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERдиаграмм. Лекция 11 38

Внешняя сущность Внешние сущности обеспечивают необходимые входы для системы и/или являются приемниками для ее выходов. Одна внешняя сущность может одновременно предоставлять входы ВНЕШНЯЯ СУЩНОСТЬ (External Reference, (функционируя как поставщик) и принимать выходы (функционируя как External Entity, External Entities, внешняя получатель). ссылка) – объект диаграммы потоков Внешние сущности изображаются как данных, являющийся источником или прямоугольники и обычно размещаются у приемником информации за пределами краев диаграммы. границ анализируемой информационной Одна внешняя сущность может быть системы (извне модели), под которым размещена на одной и той же диаграмме в понимается сущность (материальный нескольких экземплярах. Этот прием объект) вне контекста системы, являющийся источником или приемником полезно применять для сокращения количества линий, соединяющих объекты информации. Например, “заказчик”, на диаграмме. “банк” и т. д. Лекция 11 Лекция 1 39 39

Без объекта «внешняя сущность» аналитику бывает иногда сложно определить, откуда внешняя сущность пришла в компанию данные документы, или какие документы еще приходят. Внешние сущности: • это окружение системы, то есть множество объектов, взаимодействующих с системой, но не входящих в ее состав • изображают входы и/или выходы, т. е. обеспечивают интерфейс с внешними объектами, находящимися вне моделируемой системы • это логические классы материальных предметов или людей, , являющиеся источником или приемником информации, которые не представляют для анализа интерес в данный момент и служат для ограничения моделируемой части предметной области, например, заказчики, конструкторы, технологи, производственные службы, кладовщики, клиенты, склад, банк и другие и т. д. Это могут быть специфические источники, такие, как бухгалтерия, информационно -поисковая система, служба нормоконтроля, склад. Если поток данных направлен от внешней сущности к процессу, то такая внешняя сущность именуется ИСТОЧНИКОМ ДАННЫХ. Если поток данных направлен от процесса к внешней сущности, то последняя является ПРИЕМНИКОМ ДАННЫХ. Одна и та же внешняя сущность может быть одновременно приемником (функционируя как получатель) и источником данных(функционируя как поставщик). Лекция 11 40

Для всех внешних сущностей строится таблица событий, описывающая их взаимодействие с основным потоком. Таблица событий включает в себя наименование внешней сущности, событие, его тип событий (типичный для системы или исключительный, реализующийся при определенных условиях) и реакцию системы. Внешние сущности выделяются по отношению к основному процессу. Для их определения необходимо выделить поставщиков и потребителей основного процесса, т. е. все объекты, которые взаимодействуют с основным процессом. На этом этапе описание взаимодействия заключается в выборе глагола, дающего представление о том, как внешняя сущность использует основной процесс или используется им. Например, основной процесс – "учет обращений граждан", внешняя сущность – "граждане", описание взаимодействия – "подает заявления и получает ответы". Этот этап является принципиально важным, поскольку именно он определяет границы моделируемой системы. Одна внешняя сущность может быть размещена на одной и той же диаграмме в нескольких экземплярах. Этот прием полезно применять для сокращения количества линий, соединяющих объекты на диаграмме. Каждый номер каждой внешней сущности содержит префикс Е (от английского External entity) и уникальный номер сущности в модели (например, Е 5). Лекция 11 Лекция 1 41 41

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

Сеть процесса дает более полное системное представление о деятельности организации, так как позволяет показать не только элементы организации, но и взаимодействия между ними. Сеть процессов обеспечивает проверку модели деятельности на целостность, правильность выделения бизнес-процессов и описания их окружения. Если выход одного из бизнес-процессов не является входом для другого бизнес-процесса или внешнего субъекта, то это означает • описанный выход бизнес-процесса является либо ошибочным, либо лишним. • нужно найти бизнес-процесс для которого данный выход является входом и доработать схему окружения этого бизнес-процесса. Лекция 1 43 Лекция 11 43

СЕТЬ ПРОЦЕССОВ часто называют СХЕМОЙ ВЗАИМОДЕЙСТВИЯ БИЗНЕС-ПРОЦЕССОВ Отличие сети процессов от классической схемы DFD состоит в том, что на сети нужно показать внешние субъекты, с которым взаимодействуют бизнес-процессы компании - клиенты, поставщики, банки и др. Лекция 11 Лекция 1 44 44

Контекстная диаграмма и детализация процессов декомпозицией данных КОНТЕКСТНАЯ ДИАГРАММА • это диаграмма самого верхнего уровня DFD модели, • устанавливает границы анализируемой системы • моделирует систему наиболее общим образом. Существующие "абстрактные" потоки данных между терминаторами и процессами трансформируются в потоки, представляющие обмен данными на более конкретном уровне. • в центре находится главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Такой контекстный блок имеет имя, совпадающее с именем всей системы • отражает интерфейс системы с внешним миром (границы анализируемой системы), а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана • идентифицирует внешние сущности, а также, как правило, единственный процесс, отражающий главную цель или природу системы насколько это возможно. • представляет требования к системе на самом верхнем уровне - уровне взаимодействия с окружением Лекция 11 45

Обычно при проектировании относительно простых информационных систем строится единственная контекстная диаграмма со звездообразной топологией, на которой представлен моделируемый процесс и все внешние сущности, с которыми он взаимодействует. Если для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать большое количество источников и приемников информации, которые трудно расположить на листе, и кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС: Лекция 11 Лекция 1 46 46

Признаками сложности (в смысле контекста) : • наличие большого количества внешних сущностей (десять и более); • распределенная природа системы; • многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы. • наличием у процесса относительно небольшого количества входных и выходных потоков данных (2 -3 потока); • возможностью описания преобразования данных процессом в виде последовательного алгоритма; • единственной логической функцией преобразования входной информации в выходную; • возможностью описания логики процесса при помощи спецификации небольшого объема (не более 20 - 30 строк). Полная контекстная диаграмма, включающая работы и внешние ссылки, а также диаграмму нулевого уровня, строится для завершения анализа функционального аспекта системы. Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему. Лекция 11 47

Перед построением контекстной DFD необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы. Количество потоков на контекстной диаграмме должно быть по возможности небольшим, поскольку каждый из них может быть в дальнейшем разбит на несколько потоков, на следующих уровнях диаграммы. Внешние входы на DFD-схеме поступают из вне от поставщика процесса, а внешние выходы уходят наружу к клиенту процесса. При построении DFD-схемы их нужно перенести со схемы окружения процесса DFD-диаграмму. Функциональный блок на этой диаграмме обычно имеет имя, совпадающее с именем всей системы. После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами). Для проверки контекстной диаграммы можно составить список событий. Список событий должен состоять из описаний действий внешних сущностей (событий) и соответствующих реакций системы на события. Каждое событие должно соответствовать одному (или более) потоку данных: входные потоки интерпретируются как воздействия, а выходные потоки - как реакции системы на входные потоки. Лекция 11 Лекция 1 48 48

Контекстная диаграмма DFD Лекция 11 49

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

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

Декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня. Цель декомпозиции DFD - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, выявить отношения между этими процессами, сделать требования ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. При построении иерархии DFD переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться тип (непрерывные/дискретные). • для непрерывных данных может указываться единица измерения (кг, см и т. п. ), диапазон значений, точность представления и форма физического кодирования. • для дискретных данных может указываться таблица допустимых значений. Лекция 11 Лекция 1 52 52

Главная цель построения иерархического множества DFD заключается в том, чтобы сделать требования ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. Лекция 11 Процесс построения диаграммы начинается с описания общей картины бизнеса. Затем анализируются отдельные функциональные блоки. Уровень подробности диаграммы определяется поставленной задачей. Данная технология использует метод «сверху вниз» , что позволяет проводить анализ, не отклоняясь от цели моделирования. 53

Дополнительные средства описания процессов Важнейший вопрос при описании бизнес-процессов - выбор способа и инструмента описания. Для более точного описания процессов и потоков данных диаграмму описания необходимо сопроводить двумя дополнительными типами спецификаций : • спецификации процессов (PSPEC - process specification); • словарь данных (DD -data dictionary). • текстовое описание • структурированный естественный язык. Применяется, когда детали СП известны не полностью. Обеспечивает быстрое проектирование СП, прост в использовании, легко понимаем проектировщиками и программистами, конечным пользователем. К его недостаткам относятся отсутствие процедурных возможностей и неспособность к автоматической кодогенерации из-за наличия неоднозначностей. • таблица решений и дерево решений. Позволяют управлять сложными комбинациями условий и действий, обеспечивают визуальное представление СП и легко понимаемы конечным пользователем. . • визуальный язык. Поддерживаются автоматической кодогенерацией, позволяют осуществлять декомпозицию СП. Их недостаток - трудность модификации СП при изменении деталей. • язык программирования Лекция 1 54 Лекция 11 54

Спецификации процессов обработки данных Спецификация (описание логики процесса) создается для процесса, декомпозиция которого не имеет особого смысла, ввиду того, что он достаточно невелик, и его неформальное описание процесса дает больше для проектировщика, чем формальное. Спецификация должна формулировать основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу. СП определяет то, каким образом каждый из определенных в системе процессов преобразует входящие в него потоки данных в выходные потоки данных. Уровень описания этого преобразования соответствует уровню самих потоков данных и может задаваться в виде таблицы решений, граф-схемы алгоритма или в виде текста на структурированном естественном языке. Фактически СП представляют собой алгоритмы описания задач, выполняемых процессами: множество всех СП является полной спецификацией системы. Лекция 11 Лекция 1 55 55

Спецификации содержат • номер или имя процесса, • списки входных и выходных данных • тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Известно большое количество разнообразных методов, позволяющих описать тело процесса. Соответствующие этим методам языки могут варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (МИНИСПЕЦИФИКАЦИИ). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD. Обычно спецификация представляется текстом на структурированном естественном языке, который сочетает в себе строгость традиционного языка программирования с читабельностью текста на естественном языке. Он является разумной комбинацией строгости языка программирования и читабельности естественного языка и состоит из подмножества слов, организованных в определенные логические структуры, арифметических выражений и диаграмм. Лекция 11 56

В состав языка входят следующие основные символы: • глаголы, ориентированные на действие и применяемые к объектам; глаголы • термины, определенные на любой стадии проекта ПО (например, задачи, термины процедуры, символы данных и т. п. ); • предлоги и союзы, используемые в логических отношениях; предлоги союзы • общеупотребительные математические, физические и технические термины; термины • арифметические уравнения; уравнения • таблицы, диаграммы, графы и т. п. ; таблицы, диаграммы графы • комментарии При использовании структурированного естественного языка приняты следующие соглашения: • логика процесса должна быть выражена четко и недвусмысленно в виде комбинации последовательных конструкций, конструкций выбора и итераций. • ключевые слова или фразы, определенные в словаре данных ЕСЛИ, ВЫПОЛНИТЬ, ЕСЛИ ВЫПОЛНИТЬ ИНАЧЕ и т. д. должны быть написаны заглавными буквами. • глаголы должны быть активными, недвусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать). Лекция 11 Лекция 1 57 57

В тексте, написанном на структурированном естественном языке, могут использоваться конструкции управления, соответствующие операторам выбора, цикла и присваивания в языке программирования. Управляющие структуры языка имеют один вход и один выход. К ним относятся: Последовательная конструкция: ВЫПОЛНИТЬ функция 1 ВЫПОЛНИТЬ функция 2 ВЫПОЛНИТЬ функция. З Конструкция выбора: ЕСЛИ <условие> ТО ВЫПОЛНИТЬ функция 1 ИНАЧЕ ВЫПОЛНИТЬ функция 2 КОНЕЦЕСЛИ Конструкция присваивания: присвоить ПЕРЕМЕННАя значение ВЫРАЖЕНИЕ. Лекция 11 Конструкция цикла (итерация): ДЛЯ <условие> ВЫПОЛНИТЬ функция КОНЕЦДЛЯ или ПОКА <условие> ВЫПОЛНИТЬ функция КОНЕЦПОКА или пока УСЛОВИЕ выполнять ДЕЙСТВИЕ конец_цикла. Конструкция, указывающая возможность параллельного выполнения действий: выполнения действий выполнять_параллельно ДЕЙСТВИЕ 1 ДЕЙСТВИЕ 2 ДЕЙСТВИЕ 3 конец_параллельного_вы полнения 58

Независимо от используемой нотации СП процесса должна начинаться с ключевого слова (например, @СПЕЦПРОЦ). Требуемые входные и выходные данные должны быть специфицированы следующим образом: @ВХОД= <имя символа данных> @ВЫХОД= <имя символа данных> @ВХОДВЫХОД= <имя символа данных>, где <имя символа данных> - соответствующее имя из словаря данных. Эти ключевые слова должны использоваться перед определением СП, например: @ВХОД = СЛОВА ПАМЯТИ @ВЫХОД = ХРАНИМЫЕ ЗНАЧЕНИЯ @СПЕЦПРОЦ Для всех СЛОВ ПАМЯТИ выполнить: Распечатать ХРАНИМЫЕ ЗНАЧЕНИЯ @ Ситуация, когда символ данных является одновременно входным и выходным, может быть описана двумя способами: • либо символ описывается два раза с помощью @ВХОДи @ВЫХОД, • либо один раз с помощью @ВХОДВЫХОД. Иногда в СП задаются пред- и постусловия выполнения данного процесса. Лекция 11 Лекция 1 59 59

Спецификации должны удовлетворять следующим требованиям: • для каждого процесса нижнего уровня должна существовать одна и только одна СП; • должна определять способ преобразования входных потоков в выходные; • нет необходимости (определять метод реализации этого преобразования; • должна стремиться к ограничению избыточности - не следует переопределять то, что уже было определено на диаграмме или в словаре данных; • набор конструкций для спецификации должен быть простым и стандартным. Лекция 11 60

МИНИСПЕЦИФИКАЦИЯ - это алгоритм описания задач, выполняемых процессами, множество всех миниспецификации является полной спецификацией системы. Миниспецификация является конечной вершиной иерархии ДПД. Решение о завершении детализации процесса и использовании Миниспецификация принимается аналитиком исходя из следующих критериев: • наличия у процесса относительно небольшого количества входных и выходных потоков данных (2 -3 потока); • возможности описания преобразования данных процессом в виде последовательного алгоритма; • выполнения процессом единственной логической функции преобразования входной информации в выходную; • возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20 -30 строк). Миниспецификации содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Известно большое число разнообразных методов, позволяющих задать тело процесса, соответствующий язык может варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования (типа FLOW-форм и диаграмм Насси. Шнейдермана) и формальных компьютерных языков. Лекция 1 61 Лекция 11 61

Таблицы и деревья решений Структурированный естественный язык неприемлем для некоторых типов преобразований. Например, если действие зависит от нескольких переменных, которые могут продуцировать большое число комбинаций, то его описание будет запутанным и с большим числом уровней вложенности. Для описания подобных действий традиционно используются таблицы и деревья решений Проектирование СП с помощью ТАБЛИЦ РЕШЕНИЙ (ТР) заключается в задании матрицы, отображающей множество входных условий в множество действий. ТР состоит из двух частей. • верхняя часть используется для определения условий. Обычно условие верхняя часть является ЕСЛИ-частью оператора ЕСЛИ-ТО и требует ответа "да-нет". Однако иногда в условии может присутствовать и ограниченное множество значений, например, ЯВЛЯЕТСЯ ЛИ ДЛИНА СТРОКИ БОЛЬШЕЙ, МЕНЬШЕЙ ИЛИ РАВНОЙ ГРАНИЧНОМУ ЗНАЧЕНИЮ? • нижняя часть используется для определения действий, т. е. ТО-части нижняя часть оператора ЕСЛИ-ТО. Так, в конструкции ЕСЛИ ИДЕТ ДОЖДЬ ТО РАСКРЫТЬ ЗОНТ, «ИДЕТ ДОЖДЬ» является условием, а «РАСКРЫТЬ ЗОНТ» - действием. Лекция 11 62

Построение TP рекомендуется осуществлять по следующим шагам: 1. Идентифицировать все условия (или переменные) в спецификации. Идентифицировать все значения, которые каждая переменная может иметь. 2. Вычислить число комбинаций условий. Если все условия являются бинарными, то существует 2 комбинаций N переменных. 3. Идентифицировать каждое из возможных действий, которые могут вызываться в спецификации. 4. Построить пустую таблицу, включающую все возможные условия и действия, а также номера комбинаций условий. 5. Выписать и занести в таблицу все возможные комбинации условий. 6. Редуцировать комбинации условий. 7. Проверить каждую комбинацию условий и идентифицировать соответствующие выполняемые действия. 8. Выделить комбинации условий, для которых СП не указывает список выполняемых действий. 9. Обсудить построенную таблицу. Лекция 11 Лекция 1 63 63

Вариантом таблицы решений является дерево решений (ДР), позволяющее взглянуть на процесс условного выбора с позиции схемы. Обычно ДР используется при малом числе действий и когда не все комбинации условий возможны, а ТР - при большом числе действий и когда возможно большинство комбинаций условий. Лекция 11 64

Лекция 11 Лекция 1 65 65

Лекция 11 Лекция 1 66 66

Лекция 11 67

Лекция 11 Лекция 1 68 68

Лекция 11 69

Лекция 11 Лекция 1 70 70

Лекция 11 71

Лекция 11 Лекция 1 72 72

Лекция 11 73

Лекция 11 Лекция 1 74 74

Лекция 11 75

Визуальные языки проектирования спецификаций Лекция 11 Лекция 1 76 76

Лекция 11 Лекция 1 77 77

Лекция 11 78

Лекция 11 Лекция 1 79 79

Лекция 11 80

Лекция 11 Лекция 1 81 81

Лекция 11 82

Лекция 11 Лекция 1 83 83

Лекция 11 84

Лекция 11 Лекция 1 85 85

Лекция 11 86

Лекция 11 Лекция 1 87 87

Лекция 11 Лекция 1 88 88