17. Диаграмма потоков данных действий (ДПДД).

Типы процессов: аксессоры, генераторы событий, преобразования, проверки. Таблица процессов (ТП). Модель доступа к объектам (МДО).

Диаграмма потоков данных действий (ДПДД).

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

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

  • Нет зависимость по дынным;

  • Неизвестно откуда брать данные.

В 70-ые годы было предложено другое представление алгоритма. Требовалась оценка возможности распараллеливания вычислений. Когда мы говорим о распараллеливании вычислений возникает проблема с доступностью данных. Де-Марко предложил диаграмму, которая позволяет оценить не только алгоритмический порядок действий, но и доступность данных для выполнения того или иного действия. И тогда была предложена ДПДД.

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

Каждое действие мы можем выделить как процесс, который происходит. Каждый процесс отвечает на вопрос: "Что он делает"? Вычисляет, проверяет и так далее. Пишем ключевой литерал - A, номер процесса - 1, определяем, что он делает - Вычислить sum := 0. Таким образом, мы выделили процесс, который вычисляет sum.

Далее, у нас идет цикл. И i равно нулю, для этого выделяем процессA2, Вычислить i := 0. Затем идет условие и здесь новые процесс A3 - Проверить i, но нам надо откуда-то получить данные i, то есть процесс А3 должен выполняться после А2 и указываем поток данных, простой стрелкой, с пометкой (i), а () обозначает, что данные неустойчивые, то есть оно используется только во время выполнения нашего действия.

В зависимости от проверки A3 возможно 2 варианта:

  1. A4 - Вычислить sum := sum + arr[i]^2. Этот процесс использует условие A3. У нас идет условное управление, поэтому перечеркиваем линию и пишем условие i < count. Откуда нам взять count? Данные самого объекта рассматриваются, как архив данных. Доступ должен происходить к данным через процесс, поэтому заведем A5 - Считать count. Так же нам еще нужна сумма, берем её из A1.

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

На выходе получаем результат и отправляем его в терминатор.

Виды поток данных ДПДД:

  1. Условные (штрих-пунктирная с обозначением условия перехода);

  2. C передачей данных;

  3. Безусловные (штрих-пунктирная без обозначения условия);

Важные моменты

  • Стрелками мы показываем потоки данных, если направлены к процессу – то входные данные, если от – то выходные. Мы всегда помечаем стрелочку теми данными, которые передаются. Каждая стрелочка - это одно данное

  • Если мы читаем атрибуты самого объекта, то мы просто записываем имя атрибута. Если это объект того же класса, но это другой объект, ИЛИ это объект другого класса, то имя надо аннотировать впереди идентификатора, например, array.count - это будет говорить о том, что это другой объект, а не тот же самый.

  • Считывание данных атрибута самого объекта, другого объекта того же класса или других классов мы рассматриваем как архив данных.

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

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

  • Устойчивые и неустойчивые данные. Если данное порождается во время выполнения действия, его отмечают как неустойчивое. Данные из архива устойчивы, все другие – неустойчивые(их мы берем в круглые скобки).

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

Выделяют 4 типа процессов

  • Аксессоры – единственная цель – получить доступ к архиву данных 4 вида:

    • Создания/Уничтожения

    • Чтения/Записи

  • Генераторы событий – процесс, который создает на выходе событие:

    • Принять событие

    • Породить событие

  • Преобразования/Вычисления – процесс, который выполняет какие-либо преобразования данных

  • Проверки – результат – условный переход

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

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

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

  • Процессы выполняют одни и те же вычисления

  • Процессы, которые читают или записывают одни и те же атрибуты

  • Создают или уничтожают одни и те же объекты

  • Процессы, которые принимают одни и те же атрибуты от терминаторов

  • Процессы, которые порождают одни и те же события

  • Процессы, которые создают на выходе одни и те же данные

  • Процессы, которые порождают одни и те же выходы условного управления

Чтобы решить эту задачу, все процессы мы объединяем в таблицу процессов состояний (выделяем действия и выносим их для общего использования). Возможно несколько представлений этой таблицы. Сначала мы разбиваем эту таблицу по дпдд: “на данном дпдд происходят такие процессы, другая дпдд - другие процессы и тд.”. Потом пытаемся проанализировать и объединить все те процессы, которые проходят в одной модели состояния. Чтобы было удобнее, можно преобразовать это по типу действия, которое происходит. То есть можно сгруппировать аксессоры, преобразователи и тд. и посмотреть есть ли что-то общее. Обработав так процессы для каждой модели состояния, мы можем объединить это в одно целое. Так мы четко выделяем общие процессы.

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

Правила выполнения процессов:

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

  • Вывод процесса доступен, когда процесс выполнился

  • Данные событий (которые приводят к выполнению) всегда доступны

  • Данные из архивов данных и данные терминаторов всегда доступны

Previous16. Модель взаимодействия объектов (МВО).Next18. Домены.

Last updated