Trong biểu đồ lớp UML, Lớp ranh giới, Lớp điều khiển và Lớp thực thể là gì?

Hiện tôi đang sử dụng NetBeans làm IDE lựa chọn của mình và nó có một plugin để tạo mô hình UML. Trong sơ đồ lớp, có những yếu tố mô hình được gọi là Boundary Class, Control Class, và Entity Class. Tuy nhiên, tôi không thể tìm thấy định nghĩa chính xác về chúng, nhưng tôi đã tìm thấy trang web này trên Sơ đồ lớp UML.

Thường được sử dụng với / như một phần của OOAD và mô hình kinh doanh. Định nghĩa của Neil là đúng, nhưng về cơ bản nó giống với MVC, nhưng chỉ là trừu tượng hóa cho doanh nghiệp. "Bản tóm tắt tốt" được thực hiện tốt nên tôi sẽ không sao chép nó ở đây vì nó không phải là công việc của tôi, chi tiết hơn nhưng phù hợp với các gạch đầu dòng của Neil.

Tóm tắt hay - Conceito: Entity-Control-Boundary Pattern

OOAD

Biểu đồ độ bền được viết sau ca sử dụng và trước biểu đồ lớp. Chúng giúp xác định vai trò của các bước ca sử dụng. Bạn có thể sử dụng chúng để đảm bảo các trường hợp sử dụng của mình đủ mạnh để thể hiện các yêu cầu sử dụng cho hệ thống bạn đang xây dựng.

Chúng liên quan đến:

1. Diễn viên
2. Trường hợp sử dụng
3. Thực thể
4. Ranh giới
5. Kiểm soát

Trong khi mẫu Model-View-Controller được sử dụng cho giao diện người dùng, thì Entity-Control-Boundary Pattern (ECB) được sử dụng cho các hệ thống. Các khía cạnh sau của ECB có thể được ví như một phiên bản trừu tượng của MVC, nếu điều đó hữu ích:

Thực thể (mô hình)
Các đối tượng đại diện cho dữ liệu hệ thống, thường từ mô hình miền.

Ranh giới (xem / cộng tác viên dịch vụ)
Các đối tượng giao diện với các tác nhân hệ thống (ví dụ người dùng hoặc dịch vụ bên ngoài ). Windows, màn hình và menu là những ví dụ về ranh giới giao diện với người dùng.

Controls (người điều khiển)
Các đối tượng làm trung gian giữa các ranh giới và thực thể. Chúng đóng vai trò là chất kết dính giữa các phần tử ranh giới và các phần tử thực thể, thực hiện logic cần thiết để quản lý các phần tử khác nhau và sự tương tác của chúng. Điều quan trọng là phải hiểu rằng bạn có thể quyết định triển khai các bộ điều khiển trong thiết kế của mình như một thứ gì đó khác với các đối tượng - nhiều bộ điều khiển đủ đơn giản để được triển khai như một phương thức của một thực thể hoặc lớp ranh giới chẳng hạn.

Bốn quy tắc áp dụng cho giao tiếp của họ:

1. Diễn viên chỉ có thể nói chuyện với các đối tượng biên.
2. Đối tượng ranh giới chỉ có thể nói chuyện với bộ điều khiển và tác nhân.
3. Đối tượng thực thể chỉ có thể nói chuyện với bộ điều khiển.
4. Bộ điều khiển có thể nói chuyện với các đối tượng ranh giới và đối tượng thực thể và với các bộ điều khiển khác, nhưng không phải với các tác nhân

Giao tiếp được phép:

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

Đây là những khuôn mẫu lớp được sử dụng trong phân tích.

• các lớp ranh giới là những lớp ở ranh giới của hệ thống - các lớp mà bạn hoặc các hệ thống khác tương tác với

• các lớp lớp thực thể là các thực thể kinh doanh điển hình của bạn như "người" và "tài khoản ngân hàng"

• các lớp điều khiển thực hiện một số logic nghiệp vụ hoặc các

Mẫu thực thể điều khiển ranh giới có hai phiên bản:
- cấu trúc cũ, được mô tả tại 127 (thực thể như một phần tử mô hình dữ liệu, điều khiển như một chức năng, ranh giới như một giao diện ứng dụng)
- mẫu đối tượng mới


như một mẫu đối tượng:
- Boundary là một giao diện cho " thế giới khác "
- Kiểm soát trong một logic nội bộ bất kỳ (như một dịch vụ trong mẫu DDD)
- Thực thể là một serwis liên tục cho các đối tượng (như một kho lưu trữ trong mẫu DDD).
Tất cả các lớp đều có hoạt động (xem phần chống mô hình miền thiếu máu Fowler)
Tất cả chúng đều là một thành phần Mô hình trong mô hình MVC. Các quy tắc:
- Chỉ Boundary cung cấp dịch vụ cho "thế giới bên kia"
- Boundary chỉ có thể gọi đến Controll
- Control có thể gọi cho bất kỳ ai
- Thực thể không thể gọi bất kỳ ai (!), Chỉ được gọi.

jz

Trên thực tế, Sơ đồ độ bền (hoặc Sơ đồ phân tích, như đôi khi chúng được gọi) chỉ là Sơ đồ lớp chuyên biệt. Chúng là một phần của UML, và đã có từ đầu (xem cuốn sách của Jacobson, Quy trình phát triển phần mềm hợp nhất - một phần của loạt sách "Three Amigos"). Cuốn sách nói trên có một định nghĩa tốt về ba lớp này trên trang 183-185.