2.6.3. Правила декомпозиции процесса.

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

Можно ожидать, что каждый процесс 1-го уровня потребует расширения схемы на 2-м уровне, хотя некоторые процессы могут не требовать декомпозиции, т.е. будет достаточно составить ОЭП. Аналитик должен больше внимания уделять декомпозиции тех процессов, которые разбиваются на несколько уровней иерархии, а процессы, не требующие этого проверить на возможность объединения. «Идеальная» модель не должна требовать каких-то дополнительных средств и усилий для того, чтобы обеспечить ее восприятие пользователем и интерпретацию в терминах проектируемой бизнес-системы.

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

Разбиение означает уточнение процесса в деталях без нарушения его взаимоотношений с процессами, хранилищами данных и внешними объектами на предыдущих уровнях описания. Это показано на рис. 2.9.

Рис.2.9. Декомпозиция процесса

Аналитик должен проверить схемы нижнего уровня на содержательность и полноту, а также убедиться в том, что СПД верхнего уровня полностью отражает нижний уровень (если нет, то верхний уровень должен быть преобразован). Затем необходимо на неформальной основе обсудить полученные схемы с пользователями. Для аналитика цель такого обсуждения состоит в том, чтобы найти все проблемы непоследовательности, которые могли возникнуть в процессе развития СПД при описании существующей системы, обсудить их с пользователями и отредактировать схемы для устранения ошибок и упущений. Это позволяет быстро определить требования пользователей и внести их в "Каталог требований".

Рекомендуется, чтобы 3-й уровень был самым нижним. Дальнейшее расширение детализации для достижения целен этого метола (определения требований, событий функций и обоснования ЛМД ) нежелательно, т.к. более полная МПД становится менее эффективной. Однако, такая МПД может использоваться в качестве инструмента связи с пользователем и подробного описания процессов получения ЛСПД и СПД ТС.

2.6.5.Декомпозиция других элементов спд

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

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

Рис. 2.10. Декомпозиция внешних объектов и хранилищ данных