Избегайте функциональной декомпозиции

При анализе прецедентов широко встречается следующая ошибка: создается ряд «высокоуровневых» прецедентов, которые затем разбиваются на ряд прецедентов более низкого уровня и т.д. до «элементарных» прецедентов, достаточно детализированных для реализации. Такой подход к разработке программного обеспечения называется функциональной декомпозицией. Он абсолютно ошибочен в применении к моделированию прецедентов.
Рассмотрим пример. Аналитик описал работу библиотечной системы с помощью одного высокоуровневого прецедента RunLibrary (управление библиотекой). Затем путем функциональной декомпозиции разложил его на все более и более детализированные уровни.
Многим не-ОО аналитикам кажется вполне приемлемым.
Однако с точки зрения моделирования прецедентов в предложенном примере содержится много ошибок:
• Модель сосредоточена не на фиксировании требований, а на искусственном структурировании этих требований – существует множество возможных вариантов декомпозиции.
• Модель описывает систему как набор вложенных функций. Однако ОО системы в действительности являются наборами взаимодействующих объектов, обменивающихся сообщениями. Здесь очевидное концептуальное несоответствие.
• Интерес представляют только описания прецедентов самого низкого уровня: AddBook (добавить книгу), DeleteBook (удалить книгу), AddTicket (добавить формуляр), DeleteTicket (удалить формуляр), LendBook (выдать книгу) и ReturnBook (вернуть книгу). Более высокие уровни просто вызывают нижние и ничего не привносят в модель с точки зрения отражения требований.
• Модель сложна и непонятна заинтересованным сторонам: в ней несколько абстрактных прецедентов (RunLibrary, MaintainBooks (обслуживание книг), MaintainTickets (обслуживание формуляров) и MaintainLoans (обслуживание выдачи книг)) и много отношений «include» с более низкими уровнями абстракции.
Применение функциональной декомпозиции говорит о том, что аналитик неправильно продумал систему. Обычно это свидетельствует о том, что он обучен более традиционным методам процедурного программирования и пока что не уловил принципа ОО программирования. В этом случае лучше привлечь опытного разработчика моделей прецедентов в качестве руководителя и консультанта.
Не все примеры функциональной декомпозиции так очевидны. Обычно декомпозицию можно обнаружить в отдельных частях модели, поэтому желательно проверять все части модели прецедентов, имеющие глубокую иерархию.
И наконец, следует заметить, что в процессе моделирования прецедентов иерархии возникают естественным образом. Однако в этих естественных иерархиях, как правило, не более одного (или максимум двух) уровня вложенности, а модель никогда не строится от одного прецедента.

Запись опубликована в рубрике Компьютеры и интернет с метками . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

code