Сущность-контроль-граница - Википедия - Entity-control-boundary

Не путать с Стереотип (UML).

В объект-контроль-граница (ЕЦБ), или же объект-граница-контроль (EBC), или же пограничный контрольный объект (До н.э.) является архитектурный образец используется в вариант использования ведомый объектно-ориентированное проектирование программного обеспечения который структурирует классы, составляющие программного обеспечения в соответствии со своими обязанностями при реализации варианта использования.

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

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

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

Принцип

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

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

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

Классы ECB впервые идентифицируются, когда сценарии использования анализируются:

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

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

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

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

Диаграмма устойчивости

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

ПредставлениеОтношения с
РольСимволАктерГраницаКонтрольЮридическое лицо
АктерДиаграмма устойчивости Actor.svgдадаНетНет
ГраницаДиаграмма устойчивости Boundary.svgдаЧасть / целоедаНет
КонтрольДиаграмма устойчивости Control.svgНетдадада
Юридическое лицоДиаграмма устойчивости Entity.svgНетНетдада

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

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

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

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

Отношение к другим архитектурным образцам

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

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

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

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

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

  1. ^ Якобсон, Ивар. (1992). Объектно-ориентированная разработка программного обеспечения: подход на основе вариантов использования. [Нью-Йорк]: ACM Press. стр.130–133. ISBN  0201544350. OCLC  26132801.
  2. ^ а б "Информация о прочтении объектно-ориентированной разработки программного обеспечения, Ивар Якобсон и др. (1992)". tedfelix.com. Получено 2019-08-14.
  3. ^ Единый процесс разработки программного обеспечения. Джейкобсон, Ивар., Буч, Грейди., Рамбо, Джим. Ридинг, Массачусетс: Эддисон-Уэсли. 1999. С. 44, 183–188, 202–205, 256–257, 439. ISBN  0201571692. OCLC  636807532.CS1 maint: другие (связь)
  4. ^ а б Скотт Эмблер. «Диаграммы устойчивости: введение в Agile». agilemodeling.com. Получено 2019-08-14.
  5. ^ Эмблер, Скотт В., 1966- (2004). Учебник по объектам: разработка на основе гибкого моделирования с использованием UML 2.0 (3-е изд.). Кембридж, Великобритания: Издательство Кембриджского университета. ISBN  0521540186. OCLC  54081540.CS1 maint: несколько имен: список авторов (связь)
  6. ^ «Устранение разрыва между анализом и дизайном • Регистр». www.theregister.co.uk. Получено 2019-08-14.
  7. ^ Дугердил, Филипп (2013). «Архитектура мобильного корпоративного приложения: подход к моделированию для адаптации корпоративных приложений к мобильным устройствам». Материалы семинара ACM 2013 по жизненному циклу мобильной разработки - MobileDeLi '13. Индианаполис, Индиана, США: ACM Press: 9–14. Дои:10.1145/2542128.2542131. ISBN  9781450326032.
  8. ^ "Рекомендация: шаблон" сущность-контроль-граница ". posomas.isse.de. Получено 2019-08-14.
  9. ^ Дашнер, Себастьян (2017). Архитектура современных приложений Java EE: проектирование легких бизнес-ориентированных корпоративных приложений в эпоху облаков, контейнеров и Java EE 8. Packt Publishing. стр. раздел «Граница контроля за организацией». ISBN  9781788397124. OCLC  1008993521.
  10. ^ "Паттерн" сущность-контроль-граница ". www.cs.sjsu.edu. Получено 2019-08-14.
  11. ^ Мартин, Роберт, К. (2012-08-12). "Чистая архитектура | Блог чистого кодера". blog.cleancoder.com. Получено 2019-08-12.
  12. ^ Мартин, Роберт С. (2017). Чистая архитектура: руководство по структуре и дизайну программного обеспечения. Прентис Холл. ISBN  978-0-13-449416-6. OCLC  1004983973.