Лабораторная работа № 2

Тема: Создание контекстной диаграммы для программного продукта.

Цель работы: ознакомиться с правилами создания контекстной

диаграммы для программного продукта.

Методические указания к лабораторной работе

Зачем нужна контекстная диаграмма? Контекстная диаграмма прежде
всего позволяет быстро, кратко и ёмко описать назначение и границы
системы, выявить и устранить коллективные расхождения в их понимании,
показать и договориться о её масштабе и быстрое выявление
функциональных системных требований.
Второе её назначение — служить источником для быстрой генерации
первичного набора системных функциональных требований при
необходимости проектирования системы не «сверху-вниз», от бизнес-
модели, бизнес-требований, модели деятельности организации, требований
заинтересованных лиц, модели использования, как предлагает нам системная
инженерия, а «из середины».
Как устроена контекстная диаграмма
Контекстная диаграмма относится к категории диаграмм,
описывающих систему на уровне «чёрного ящика» — а именно, только
внешние свойства (в данном случае — потоки данных), но не содержание
системы.
Контекстная диаграмма содержит 3 основных компонента:
1. Проектируемый объект (например, система)
2. Взаимодействующие с проектируемым объектом элементы
окружения (группы пользователей, смежные системы)
3. Потоки данных (исходящие и входящие)
Пример контекстной диаграммы для программной системы управления
Заказами в ресторане:
 Потоки данных могут передаваться между окружением и
(программной) системой любым образом — с помощью графического
пользовательского интерфейса (GUI), командной строки (CLI), программных
вызовов (API), почтовых сообщений и т.д.
Если система имеет физические интерфейсы, то это могут быть
разнообразные джойстики, рукоятки управления, специализированные
клавиатуры, датчики распознавания движения, изображения, жестов и т.д.
В стандартной форме не принято указывать виды интерфейсов
взаимодействия и тем более протоколы, чтобы не усложнять диаграмму и не
пытаться принимать вторичные решения, пока не приняты первичные.
Пример контекстной диаграммы для программной системы
автоматизации Единого расчётного центра (ЕРЦ) коммунальных услуг:

Как создавать контекстную диаграмму

 Контекстная диаграмма может разрабатываться в ходе рабочего
семинара, в ходе серии интервью или на основе результатов серии интервью.
Контекстную диаграмму можно рисовать на маркерной доске, в среде
проектирования или в онлайн-инструменте (Google Draw, Draw.io, Miro и
т.д.). Мы рекомендуем маркерную доску или онлайн-инструмент с
совместным редактированием.
Порядок разработки контекстной диаграммы на рабочем семинаре:
1. Из числа заинтересованных лиц собирается рабочая группа (обычно
от 3 до 5 человек)
2. Рабочая группа фиксирует в центре диаграммы название конкретной
системы
3. Рабочая группа выдвигает и отображает группы пользователей,
которые должны взаимодействовать с системой, обсуждает их перечень,
дополняет его
4. Рабочая группа выдвигает и отображает смежные системы, которые
должны взаимодействовать с системой, обсуждает их перечень, дополняет
его
5. Рабочая группа последовательно проходит по каждому элементу
окружения и описывает потоки данных, связывающие его с системой
6. Рабочая группа проводит тестирование контекстной диаграммы,
дополняя диаграмму по ходу тестирования
Для экономии времени участников тестирование можно производить 1-
2 участниками.
Как тестировать контекстную диаграмму
Диаграмму можно тестировать 2-мя способами — через контроль
соответствия входных и выходных данных системы или через сквозной
устный сценарий использования системы.
Тестирование контекстной диаграммы с помощью парных
соответствий
Контроль соответствия входных и выходных данных системы
опирается на принцип (aka «Закон сохранения данных»), что если в систему
попадают какие-то данные (входной поток), они должны как-то
использоваться для как минимум одного выходного потока.
И наоборот, если есть выходной поток, то система либо должна
генерировать эти данные согласно каким-то правилам (например, случайно)
или формировать их на основе каких-то других входных данных.
Более формально парные соответствия можно проконтролировать через
таблицу, например:

Входной поток (Источник. Выходной поток (Получатель.

Поток) Поток)

AD. Учётные записи Администратор. Учётные записи

 Входной поток (Источник. Выходной поток (Получатель.
Поток) Поток)

Оператор. Платёжка Бухгалтер. Ведомость платежей

... ...

Тестирование контекстной диаграммы с помощью сквозного

сценария
В зависимости от сложности системы, можно проводить неформальное
или формальное тестирование диаграммы через сквозной сценарий её
использования.
Как выглядит неформальное тестирование — один из участников
семинара, опираясь на конкретные потоки данных и указывая их на
диаграмме, рассказывает возможный сквозной сценарий использования
системы, начиная с логически более ранних событий и продолжая
последующими, например:
1. Система загружает реестр пользователей из AD
2. Администратор настраивает полномочия пользователей
3. и т.д.
Выявление и контроль полноты (функциональных) системных
требований
При создании системных требований возникает риск упустить что-то
важное или наоборот, избыточно проработать очевидное.
Чтобы не упустить что-то важное среди системных функций, можно
применять:
1. Трассировку системных требований на требования
заинтересованных лиц
2. Модель использования системы (обычно в форме набора сценариев
использования, use case'ов)
3. Контекстную диаграмму системы
Контекстная диаграмма может эффективно использоваться для
выявления первичного набора системных функциональных требований.
Каждый поток данных на диаграмме по сути означает, подразумевает какую-
то функцию.
Наибольшие гарантии даёт применение всех 3-х методов.
Чтобы убедиться в том, что при выявлении первичного набора
системных функциональных требований вы не упустили ни один из
нарисованных потоков данных, бывает полезно развернуть потоки данных в
таблицу, на которую потом страссировать порождённые ей требования:
 Направление Элемент Класс Код
пограничног контекста передаваемы порождённого
о потока х данных системного
функционального
требования

Входящий Active Учётная SFR-234

Directory запись
пользователя

Входящий Администр Полномочия SUC-14

атор пользователя

... ... ... ...

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

такая схема трассировок:

Задание к лабораторной работе

1. Разработать контекстной диаграммы на программный продукт.
2. Оформить работу в соответствии со стандартом.
3. Сдать и защитить работу.

Требование к отчету по лабораторной работе

1. Контекстная диаграмма.
2. Пояснение к контекстной диаграмме.
Защита отчета по лабораторной работе заключается в предъявлении
преподавателю полученных результатов, ответы на вопросы преподавателя.
Контрольные вопросы
1. Особенности контекстной диаграммы
2. Откуда взялась контекстная диаграмма и почему до сих пор
актуальна
3. Что такое  Structured Analysis and Structured Design 
Что такое диаграммы потоков данных — DFD (Data Flow Diagram).