Сущность–контроль–граница
Архитектурная концепция, используемая при проектировании программного обеспечения

Сущность –управление–граница ( ECB ), или сущность–граница–управление ( EBC ), или граница–управление–сущность ( BCE ) — это архитектурный шаблон , используемый в объектно-ориентированном программировании , основанном на вариантах использования , который структурирует классы, составляющие высокоуровневый объектно-ориентированный исходный код, в соответствии с их обязанностями в реализации варианта использования.

Происхождение и эволюция

Подход «сущность–управление–граница» берет свое начало в  методе объектно-ориентированной программной инженерии (OOSE) , основанном на вариантах использования, разработанном Иваром Якобсоном и опубликованном в 1992 году. [1] [2]  Первоначально он назывался «сущность–интерфейс–управление » ( EIC ), но очень быстро термин « граница » заменил « интерфейс », чтобы избежать возможной путаницы с терминологией объектно-ориентированного языка программирования .

Он далее развивается в унифицированном процессе , который способствует использованию ECB в деятельности по анализу и проектированию с поддержкой стереотипов UML . [3] Гибкое моделирование [4] [5] и процесс ICONIX [6] разработаны на основе шаблона архитектуры ECB с диаграммами надежности. [7]      

Принцип

Шаблон ECB организует обязанности классов в соответствии с их ролью в реализации варианта использования:

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

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

Классы ECB впервые определяются при анализе   вариантов использования :

  • каждый вариант использования представлен в виде контрольного класса;
  • каждое отдельное отношение между вариантом использования и субъектом представлено как граничный класс;
  • сущности выводятся из описания варианта использования.

Затем классы уточняются и реструктурируются или реорганизуются по мере необходимости для проекта, например:  

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

Модель ECB предполагает, что обязанности классов также отражены в отношениях и взаимодействиях между различными категориями классов, чтобы обеспечить надежность конструкции. [8] [9]

Диаграмма надежности

Диаграммы надежности позволяют визуально представлять отношения между сущностями, элементами управления, границами и субъектами. [4] Они используют графические стереотипы, введенные в ранних работах Якобсона:  

ПредставлениеСвязь с
РольСимволАктерГраницаКонтрольСущность
АктерДаДаНетНет
ГраницаДаЧасть/целоеДаНет
КонтрольНетДаДаДа
СущностьНетНетДаДа

Применяются следующие ограничения надежности: 

  • Актеры могут знать и общаться только с границами
  • Границы могут взаимодействовать только с субъектами и элементами управления.
  • Элементы управления могут знать и взаимодействовать с границами и сущностями, а также, при необходимости, с другими элементами управления.
  • Сущности могут знать только о других сущностях, но также могут взаимодействовать с элементами управления;

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

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

Связь с другими архитектурными образцами

Между ECB и model–view–controller (MVC) есть некоторое сходство : сущности принадлежат модели, а представления принадлежат границам. Однако роль ECB-control сильно отличается от MVC-controller, поскольку он инкапсулирует также бизнес-логику варианта использования, тогда как контроллер MVC обрабатывает пользовательский ввод, который был бы обязанностью границы в ECB. ECB-control увеличивает разделение интересов в архитектуре, инкапсулируя бизнес-логику, которая не связана напрямую с сущностью. [2]

ECB может использоваться в сочетании с гексагональной архитектурой , когда границы образуют внешний слой адаптера. [10]  

ECB совместим с чистой архитектурой, которая объединяет принципы ECB с другими парадигмами архитектурного проектирования. [11] [12]  Чистая архитектура помещает сущности в ядро ​​и окружает их кольцом вариантов использования (т. е. контролем ECB) и кольцом со шлюзами и презентаторами (т. е. границами ECB). Однако чистая архитектура требует односторонней зависимости снаружи внутрь, что требует разделения элементов управления ECB на логику вариантов использования и координацию объектов.

Смотрите также

Примечания и ссылки

  1. ^ Якобсон, Ивар. (1992). Объектно-ориентированная разработка программного обеспечения: подход, основанный на вариантах использования. [Нью-Йорк]: ACM Press. С. 130–133. ISBN 0201544350. OCLC  26132801.
  2. ^ ab "Уведомление о чтении по объектно-ориентированной программной инженерии, Ивар Якобсон и др. (1992)". tedfelix.com . Получено 14 августа 2019 г.
  3. ^ Унифицированный процесс разработки программного обеспечения . Якобсон, Ивар., Буч, Грейди., Рамбо, Джим. Рединг, Массачусетс: Addison-Wesley. 1999. стр. 44, 183– 188, 202– 205, 256– 257, 439. ISBN 0201571692. OCLC  636807532.{{cite book}}: CS1 maint: другие ( ссылка )
  4. ^ ab Скотт Эмблер . «Диаграммы надежности: введение в Agile». agilemodeling.com . Получено 14 августа 2019 г.
  5. ^ Эмблер, Скотт В., 1966- (2004). Объектный учебник: гибкая разработка на основе моделирования с использованием UML 2.0 (3-е изд.). Кембридж, Великобритания: Cambridge University Press. ISBN 0521540186. OCLC  54081540.{{cite book}}: CS1 maint: несколько имен: список авторов ( ссылка ) CS1 maint: числовые имена: список авторов ( ссылка )
  6. ^ «Устраните разрыв между анализом и дизайном • The Register». www.theregister.co.uk . Получено 14 августа 2019 г.
  7. ^ Дугердил, Филипп (2013). «Архитектура мобильного корпоративного приложения». Труды семинара ACM 2013 года по жизненному циклу разработки мобильных приложений . Индианаполис, Индиана, США: ACM Press. стр.  9–14 . doi :10.1145/2542128.2542131. ISBN 9781450326032. S2CID  14408662.
  8. ^ "Guideline: Entity-Control-Boundary Pattern". posomas.isse.de . Получено 14.08.2019 .
  9. ^ Дашнер, Себастьян (2017). Архитектура современных приложений Java EE: проектирование легких, ориентированных на бизнес корпоративных приложений в эпоху облаков, контейнеров и Java EE 8. Packt Publishing. стр. раздел «Граница управления сущностями». ISBN 9781788397124. OCLC  1008993521.
  10. ^ "Шаблон Entity-Control-Boundary". www.cs.sjsu.edu . Получено 14 августа 2019 г.
  11. ^ Мартин, Роберт, К. (12 августа 2012 г.). «Чистая архитектура | Блог чистого кодера». blog.cleancoder.com . Получено 12 августа 2019 г.{{cite web}}: CS1 maint: несколько имен: список авторов ( ссылка )
  12. ^ Мартин, Роберт С. (2017). Чистая архитектура: руководство мастера по структуре и дизайну программного обеспечения . Prentice Hall. ISBN 978-0-13-449416-6. OCLC  1004983973.
Получено с "https://en.wikipedia.org/w/index.php?title=Entity–control–boundary&oldid=1260358539"