Differences

This shows you the differences between two versions of the page.

--- mdd:careful_with_use_cases [2026/08/29 07:53] – Bulk sync migration user
+++ mdd:careful_with_use_cases [2026/08/29 07:59] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== Be Careful With Use Cases ======
+Edward V. Berard. Be Careful With "Use Cases".
+https://www.cs.unc.edu/~stotts/204/usecases/careful.html
+===== Сценарии использования =====
+Определим сценарий использования как последовательность транзакций в системе, чья задача — принести измеримую ценность актеру этой системы. Отметим также, что набор всех сценариев использования описывает функционал системы.
+===== Проблемы локализации информации =====
+Говоря о //локализации//, имеют в виду размещение некоторых объектов близко друг от друга, то есть группировке их в определенные «зоны». Так, в функциональной декомпозиции информация размещается с оглядкой на функции, а в объектно-ориентированной разработке информация заключена в классы и объекты.
+Если представить процесс создания продукта от проектирования интерфейса пользователя (что реализуют функциональные по природе сценарии использования) до непосредственно реализации системы (например, при помощи ООП), становится очевидно, что где-то на этом пути происходит смена парадигмы локализации, что часто приводит к ошибкам.
+Рассмотрим для примера систему, в которой несколько команд работают над своими частями проекта, разделение на которые было выполнено, исходя из сценариев использования. Распространенной проблемой в таких случаях является несовпадение функционально-декомпозированной схемы с реальной реализацией, из-за чего, например, объектам приходится собирать информацию по разным частям системы, обращаясь к реализации из разных функциональных делений.
+Другая возможная проблема — реализация одних и тех же объектов несколько раз, т.е. каждая часть продукта использует свои собственные классы и интерфейсы. Помимо траты времени на создание одной сущности несколько раз, это приводит также и к сложностям с дальнейшей интеграцией компонентов системы.
+В описанных случаях затруднения возникают в тот момент, когда функциональное описание интерфейса пользователя используется для реализации системы. Таким образом, для избежания проблем подобного рода не следует рассматривать сценарии использования как основу создания внутренней архитектуры описываемых объектов.
+===== Вопросы сокрытия данных =====
+К другому классу распространенных проблем со сценариями использования можно отнести нарушение концепции сокрытия данных. В объектно-ориентированном подходе //сокрытием данных// называется невозможность доступа извне класса к деталям его реализации, потому что они могут быть сложны для использования или часто изменяться. Вместо этого предполагается использование специального интерфейса, в идеальном случае хорошо задокументированного и сохраняющего обратную совместимость.
+К последствиям нарушения сокрытия относится сильное сопряжение (и, как следствие, сложности в поддержке, модификации и переиспользовании системы) и увеличение уровня детализации, на котором происходит разработка.
+При создании сценариев использования нужно ограничиться описанием взаимодействия через интерфейсы описываемых объектов и не вдаваться в детали реализации, такие как используемые алгоритмы и внутреннюю структуру.
+===== Поддержка и управление сценариями использования =====
+При развитии системы число сценариев использования возрастает, а с ним усложняется и работа со сценариями. При их создании рекомендуется обратить внимание на следующие пункты:
+  * должны существовать установленные процедуры, стандарты, рекомендации и инструменты для управления всеми компонентами и артефактами, производимыми в процессе разработки и тестирования продукта, причем сценарии использования должны быть тесно интегрированы в эту систему;
+  * при написании сценариев использования следует руководствоваться стандартом их написания (в том числе соглашениями об именовании, стиле и прочем), это уже уменьшает количество потенциальных ошибок при проектировании;
+  * взаимодействие между сценариями использования и требованиями;
+  * должны существовать установленные методы определения, покрывают ли сценарии всею функциональность продукта (а также гарантию отсутствие лишних сценариев);
+  * по мере изменения продукта становится важным наличие какого-либо способа постоянно проверять правильность, согласованность и необходимость всех имеющихся сценариев;
+  * сценарии должны быть выполнены на должном уровне детализации. Так, например, сценарии, результат в которых не несет ценности для конечного пользователя, вероятно, рассматривают слишком мелкие процессы.
+===== Заключение =====
+В этой статье были описаны некоторые распространненные сложности при разработке системы с использованием сценариев использования. Хотя написание сценариев использования является эффективным инструментом описания системы с точки зрения пользователя, нужно проводить границу между внешним интерфейсом и деталями реализации. Кроме того, написание и поддержка сценариев использования должны быть выполнены с должным уровнем строгости и контроля, потому что небрежное их написание приводит к трудностям в использовании этого набора сценариев.