Що таке діаграми класів UML, що таке граничні класи, класи управління та класи сутності?

Зараз я використовую NetBeans як свій вибір IDE, і він має плагін для моделювання UML. У діаграмі класів, є елементи моделі , відомі як Boundary Class, Control Classі Entity Class. Однак я не можу знайти хорошого їх визначення, але я знайшов цей сайт на діаграмах класів UML.

Часто використовується з / як частина OOAD та бізнес-моделювання. Визначення Ніла є правильним, але воно в основному ідентичне MVC, але лише абстрактно для бізнесу. "Гарне резюме" добре зроблено, тому я не буду його копіювати тут, оскільки це не моя робота, більш детальна, але відповідає крапкам Ніла.

Хороший підсумок - Conceito: Суб’єкт-Контроль-Шаблон меж

ЗАВАНТАЖИТИ

Діаграми стійкості пишуться після випадків використання та до діаграм класів. Вони допомагають визначити ролі етапів використання. Ви можете використовувати їх, щоб переконатися, що ваші випадки використання достатньо надійні, щоб відповідати вимогам до використання системи, яку ви будуєте.

Вони включають:

1. Актори
2. Використовуйте кейси
3. Суб'єкти
4. Межі
5. Елементи управління

У той час як шаблон Model-View-Controller використовується для користувальницьких інтерфейсів, шаблон Entity-Control-Boundary Pattern (ECB) використовується для систем. Наступні аспекти ЄЦБ можна порівняти з абстрактною версією MVC, якщо це корисно:

Суб'єкти (модель)
Об'єкти, що представляють системні дані, часто з моделі домену.

Межі (перегляд / співавтор служби)
Об'єкти, що взаємодіють із системними акторами (наприклад, користувач або зовнішня служба ). Windows, екрани та меню - це приклади меж, які взаємодіють з користувачами.

Елементи керування (контролер)
Об'єкти, які посередничать між межами та сутностями. Вони служать клеєм між граничними елементами та елементами сутності, реалізуючи логіку, необхідну для управління різними елементами та їх взаємодії. Важливо розуміти, що ви можете вирішити впровадити контролери у своєму дизайні як щось інше, ніж об’єкти - багато контролерів досить прості, щоб, наприклад, бути реалізованими як метод сутності або граничного класу.

До їх спілкування застосовуються чотири правила:

1. Актори можуть розмовляти лише з граничними об'єктами.
2. Обмежені об'єкти можуть розмовляти лише з контролерами та акторами.
3. Об'єкти сутності можуть спілкуватися лише з контролерами.
4. Контролери можуть розмовляти з граничними об'єктами та об'єктами сутності та з іншими контролерами, але не з акторами

Дозволено спілкування:

         Entity    Boundary   Control
Entity     X                     X
Boundary                         X
Control    X          X          X

Це стереотипи класів, що використовуються в аналізі.

• граничні класи - це ті, що знаходяться на межі системи - класи, з якими ви або інші системи взаємодієте

• класи класів сутностей - це ваші типові господарські сутності, такі як "особа" та "банківський рахунок"

• класи управління реалізують певну ділову логіку чи інше

Шаблон сутності сутності контролю має дві версії:
- стару структурну, описану в 127 (сутність як елементи моделі даних, керуючу функцію, межу як інтерфейс програми)
- нову візерункову структуру


як візерунок об'єкта:
- межа є інтерфейсом для " інший світ "
- Керування в будь-якій внутрішній логіці (наприклад, служба в шаблоні DDD)
- Сутність є сервером стійкості для об'єктів (як сховище в шаблоні DDD).
Усі класи мають операції (див. Анти-шаблон моделі анемічного домену Фаулера).
Усі вони є компонентом Model у шаблоні MVC. Правила:
- Лише Boundary надає послуги для "іншого світу"
- Boundary може дзвонити лише для контролю
- Control може зателефонувати будь-кому
- Суб'єкт не може зателефонувати нікому (!), Лише викликати.

jz

Насправді діаграми стійкості (або діаграми аналізу, як їх іноді називають) є лише спеціалізованими діаграмами класів. Вони є частиною UML і були з самого початку (див. Книгу Якобсона "Уніфікований процес розробки програмного забезпечення - частина серії книг" Три аміго "). Вищезгадана книга має гарне визначення цих трьох класів на с. 183-185.