Граница управления объектом
( Граница управления объектом ECB ) , или контроль границы объекта ( EBC ), или граница управления объектом ( BCE ) — это архитектурный шаблон , используемый в вариантами использования управляемом объектно-ориентированном программировании, , который структурирует классы, составляющие высокоэффективные уровень объектно-ориентированного исходного кода в соответствии с их обязанностями в реализации варианта использования.
Происхождение и эволюция
[ редактировать ]Подход «объект-контроль-граница» берет свое начало в Ивара Джейкобсона , опубликованном в 1992 году. (OOSE) , основанном на сценариях использования объектно-ориентированной разработки программного обеспечения методе [1] [2] Первоначально он назывался Entity-Interface-Control (EIC), но очень быстро термин « граница » заменил « интерфейс », чтобы избежать потенциальной путаницы с терминологией объектно-ориентированного языка программирования .
Дальнейшее развитие он получил в Unified Process , который способствует использованию ECB в деятельности по анализу и проектированию с поддержкой стереотипов UML . [3] Гибкое моделирование , [4] [5] и процесс ICONIX [6] разработан на основе шаблона архитектуры ЕЦБ с диаграммами надежности. [7]
Принцип
[ редактировать ]Шаблон ECB организует обязанности классов в соответствии с их ролью в реализации варианта использования:
- сущность представляет долгоживущую информацию, значимую для заинтересованных сторон (т. е. в основном полученную из объектов предметной области, обычно постоянных);
- граница инкапсулирует взаимодействие с внешними субъектами (пользователями или внешними системами);
- элемент управления обеспечивает обработку, необходимую для выполнения варианта использования и его бизнес-логики, а также координирует последовательность действий и управляет другими объектами, участвующими в варианте использования.
Соответствующие классы затем группируются в пакеты услуг, которые представляют собой неделимый набор связанных классов, которые можно использовать в качестве единиц доставки программного обеспечения.
Классы ECB сначала идентифицируются при вариантов использования анализе :
- каждый вариант использования представлен как класс управления;
- каждое отдельное отношение между вариантом использования и действующим лицом представлено как граничный класс;
- сущности выводятся из описания варианта использования.
Затем классы уточняются и реструктурируются или реорганизуются по мере необходимости, например:
- Исключение общего поведения в различных элементах управления вариантами использования
- Определение центрального граничного класса для каждого типа человеческого субъекта и для каждой внешней системы, который обеспечит согласованный интерфейс с внешним миром.
Модель ЕЦБ предполагает, что обязанности классов также отражаются в отношениях и взаимодействии между различными категориями классов, чтобы обеспечить надежность конструкции. [8] [9]
Диаграмма устойчивости
[ редактировать ]Диаграммы устойчивости позволяют визуально представить отношения между сущностями, элементами управления, границами и субъектами. [4] Он использует графические стереотипы, представленные в ранних работах Джейкобсона:
| Представительство | Связь с | ||||
|---|---|---|---|---|---|
| Роль | Символ | Актер | Граница | Контроль | Сущность |
| Актер | 
|
Да | Да | Нет | Нет |
| Граница | 
|
Да | Часть/целое | Да | Нет |
| Контроль | 
|
Нет | Да | Да | Да |
| Сущность | 
|
Нет | Нет | Да | Да |
Применяются следующие ограничения устойчивости:
- Актеры могут знать только границы и общаться с ними
- Границы могут взаимодействовать только с актерами и элементами управления.
- Средства контроля могут знать и взаимодействовать с границами и объектами, а при необходимости и с другими средствами контроля.
- Объекты могут знать только о других объектах, но могут также взаимодействовать с органами управления;
В принципе, организации не должны знать о границах и средствах контроля. Однако на практике некоторые варианты позволяют объектам, границам и элементам управления подписываться на объект в качестве наблюдателя.
Аналогично, ограничение граничного класса, не знающего о других граничных классах, применяется только на самом высоком уровне, а не между классами, которые взаимодействуют для реализации одной и той же границы.
Связь с другими архитектурными шаблонами
[ редактировать ](MVC) есть некоторое сходство Между ECB и моделью-представлением-контроллером : сущности принадлежат модели, а представления принадлежат границам. Однако роль контроллера ECB сильно отличается от контроллера MVC, поскольку он также инкапсулирует бизнес-логику вариантов использования, тогда как контроллер MVC обрабатывает ввод пользователя, за который будет отвечать граница в ECB. Контроль ЕЦБ увеличивает разделение задач в архитектуре за счет инкапсуляции бизнес-логики, которая не связана напрямую с организацией. [2]
ECB можно использовать в сочетании с шестиугольной архитектурой , когда границы образуют внешний слой адаптера. [10]
ECB совместим с чистой архитектурой, которая объединяет принципы ECB с другими парадигмами архитектурного проектирования. [11] [12] Чистая архитектура помещает сущности в ядро и окружает их кольцом вариантов использования (т. е. управлением ECB) и кольцом со шлюзами и презентаторами (т. е. границами ECB). Однако чистая архитектура требует односторонней зависимости снаружи внутрь, что требует разделения элементов управления ЕЦБ на логику вариантов использования и координацию объектов.
См. также
[ редактировать ]- Архитектурные узоры
- Вариант использования
- Единый процесс
- Объектно-ориентированный анализ и проектирование
Примечания и ссылки
[ редактировать ]- ^ Джейкобсон, Ивар. (1992). Объектно-ориентированная разработка программного обеспечения: подход, основанный на сценариях использования . [Нью-Йорк]: ACM Press. стр. 130–133 . ISBN 0201544350 . ОСЛК 26132801 .
- ^ Перейти обратно: а б «Уведомление об объектно-ориентированной разработке программного обеспечения, Ивар Джейкобсон и др. (1992)» . tedfelix.com . Проверено 14 августа 2019 г.
- ^ Единый процесс разработки программного обеспечения . Джейкобсон, Ивар., Буч, Грейди., Рамбо, Джим. Ридинг, Массачусетс: Аддисон-Уэсли. 1999. стр. 44, 183–188, 202–205, 256–257, 439. ISBN. 0201571692 . OCLC 636807532 .
{{cite book}}: CS1 maint: другие ( ссылка ) - ^ Перейти обратно: а б Скотт Эмблер . «Диаграммы устойчивости: гибкое введение» . www.agilemodeling.com . Проверено 14 августа 2019 г.
- ^ Эмблер, Скотт В., 1966- (2004). Учебник по объектам: гибкая разработка на основе моделирования с использованием UML 2.0 (3-е изд.). Кембридж, Великобритания: Издательство Кембриджского университета. ISBN 0521540186 . OCLC 54081540 .
{{cite book}}: CS1 maint: несколько имен: список авторов ( ссылка ) CS1 maint: числовые имена: список авторов ( ссылка ) - ^ «Устранить разрыв между анализом и проектированием • The Register» . www.theregister.co.uk . Проверено 14 августа 2019 г.
- ^ Дугердил, Филипп (2013). «Разработка мобильного корпоративного приложения» . Материалы семинара ACM 2013 по жизненному циклу мобильной разработки . Индианаполис, Индиана, США: ACM Press. стр. 9–14. дои : 10.1145/2542128.2542131 . ISBN 9781450326032 . S2CID 14408662 .
- ^ «Рекомендация: шаблон границ управления объектами» . posomas.isse.de . Проверено 14 августа 2019 г.
- ^ Дашнер, Себастьян (2017). Проектирование современных приложений Java EE: проектирование легких бизнес-ориентированных корпоративных приложений в эпоху облаков, контейнеров и Java EE 8 . Пакт Паблишинг. стр. раздел «Граница управления объектом». ISBN 9781788397124 . OCLC 1008993521 .
- ^ «Шаблон границ управления объектом» . www.cs.sjsu.edu . Проверено 14 августа 2019 г.
- ^ Мартин, Роберт, К. (12 августа 2012 г.). «Чистая архитектура | Блог Clean Coder» . blog.cleancoder.com . Проверено 12 августа 2019 г.
{{cite web}}: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Мартин, Роберт С. (2017). Чистая архитектура: руководство для мастера по структуре и дизайну программного обеспечения . Прентис Холл. ISBN 978-0-13-449416-6 . OCLC 1004983973 .