thắc mắc Cảm thấy class UML phi thực tế khi làm application, cần người giải đáp ạ.

xuanduy1508 · 4/12/24

Em cảm thấy là class UML mà em xem trên mạng hay học thì thấy nó khá khó áp dụng thức tế (trừ làm game)

Ví dụ như sơ đồ lớp (class diagram) của hệ thống e-commerce ở trên, em thật sự không hình dung được cách triển khai code thực tế từ đó. Em từng làm một dự án bán hàng online sử dụng Java Spring Boot, và rõ ràng là cách triển khai trong dự án đó không giống như sơ đồ này. Dự án của em phân tách các tầng Controller, Service, và Repository.
Theo em, sơ đồ UML class diagram kiểu này chỉ khả thi nếu chúng ta tải toàn bộ dữ liệu vào ứng dụng Java ngay từ đầu, bất kể người dùng có cần hay không. Tuy nhiên, trong thực tế, phía cilent chỉ yêu cầu một phần dữ liệu cụ thể, và system hường trả đúng phần dữ liệu đó thông qua các DTO.
Em cảm thấy kiểu class diagram này có ý nghĩa hơn khi làm game, vì game thường tải toàn bộ dữ liệu vào ứng dụng một lần khi khởi chạy.
Mong mọi người giải đáp giúp em với ạ, em cảm ơn nhiều.

LmaoSuVuong · 4/12/24

xuanduy1508 đã nói:
Em cảm thấy là class UML mà em xem trên mạng hay học thì thấy nó khá khó áp dụng thức tế (trừ làm game)
Xem tệp đính kèm 2815248

Ví dụ như sơ đồ lớp (class diagram) của hệ thống e-commerce ở trên, em thật sự không hình dung được cách triển khai code thực tế từ đó. Em từng làm một dự án bán hàng online sử dụng Java Spring Boot, và rõ ràng là cách triển khai trong dự án đó không giống như sơ đồ này. Dự án của em phân tách các tầng Controller, Service, và Repository.
Theo em, sơ đồ UML class diagram kiểu này chỉ khả thi nếu chúng ta tải toàn bộ dữ liệu vào ứng dụng Java ngay từ đầu, bất kể người dùng có cần hay không. Tuy nhiên, trong thực tế, phía cilent chỉ yêu cầu một phần dữ liệu cụ thể, và system hường trả đúng phần dữ liệu đó thông qua các DTO.
Em cảm thấy kiểu class diagram này có ý nghĩa hơn khi làm game, vì game thường tải toàn bộ dữ liệu vào ứng dụng một lần khi khởi chạy.
Mong mọi người giải đáp giúp em với ạ, em cảm ơn nhiều.

toàn bộ class này là entity thuộc Repository ứng với 1 table trong database.

xuanduy1508 · 4/12/24

LmaoSuVuong đã nói:
toàn bộ class này là entity thuộc Repository ứng với 1 table trong database. ko phải class trong oop.

vậy mấy cái method như searchProductByName hay sendForShipment mang ý nghĩa gì trong khi cái đó phải dc xử lý trong Service layer chứ nhỉ.

LmaoSuVuong · 4/12/24

xuanduy1508 đã nói:
vậy mấy cái method như searchProductByName hay sendForShipment mang ý nghĩa gì trong khi cái đó phải dc xử lý trong Service layer chứ nhỉ.

mình nhìn cái diagram này các method toàn thao tác với dữ liệu trên database là repository đó fen. service layer chỉ gọi ra xài thôi chứ implement thẳng cái này ở service thì cần gì repo nữa :doubt:

xuanduy1508 · 4/12/24

LmaoSuVuong đã nói:
mình nhìn cái diagram này các method toàn thao tác với dữ liệu trên database là repository đó fen. service layer chỉ gọi ra xài thôi chứ implement thẳng cái này ở service thì cần gì repo nữa

ví dụ Catalog này đi, cái này có ý nghĩa gì gì. Ngta muốn filter by Categories hay filter by Category thì query vào database xong áp dụng pagination gì đó. Còn đây như 1 lần load hết data xong bỏ vào 2 cái Map trong catalog class z.

LmaoSuVuong · 4/12/24

xuanduy1508 đã nói:
Xem tệp đính kèm 2815295
ví dụ Catalog này đi, cái này có ý nghĩa gì gì. Ngta muốn filter by Categories hay filter by Category thì query vào database xong áp dụng pagination gì đó. Còn đây như 1 lần load hết data xong bỏ vào 2 cái Map trong catalog class z.

nãy mình nói nhầm đó, ko phải cứ 1 entity ứng với 1 table đâu :shame:

sin lũi bạn vì sai kiến thức. nhìn sơ qua thì mình cái này nó ứng với cái dạng quan hệ nhiều nhiều trong db, 3 bảng. vẫn là 1 cái entity trong repo thôi.

broshutjava · 4/12/24

em cũng có thắc mắc như bác, ở lớp cũng bắt thiết kế cái này chi tiết lắm, nhưng em tự code thì cũng đâu có triển khai như sơ đồ, nên nhiều lúc lấn cấn thật.

xuanduy1508 · 4/12/24

LmaoSuVuong đã nói:
nãy mình nói nhầm đó, ko phải 1 entity ứng với 1 table đâu sin lũi bạn vì sai kiến thức. nhìn sơ qua thì mình cái này nó ứng với cái dạng quan hệ nhiều nhiều trong db, 3 bảng. vẫn là 1 cái entity trong repo thôi.

nói cụ thể là 3 bảng nào được không, chứ thấy có vẻ ko phải á bạn :'(

LmaoSuVuong · 4/12/24

xuanduy1508 đã nói:
nói cụ thể là 3 bảng nào được không, chứ thấy có vẻ ko phải á bạn :'(

catalog - catalog_product - product , còn cái product category e nhìn thấy nó giống như 2 attribute của product thôi

lct_005 · 4/12/24

Nếu bạn nhìn vô class diagram này mà hiểu được thì đó là mục đích của UML.
Với 1 dự án mới, mọi thứ còn đang mơ hồ, thì cần phải phân tích các requirements, business logic. Rồi từ đó mới lên sơ sơ được các use cases, actors. Rồi sau đó là thiết kế, chuẩn hoá cơ sở dữ liệu, các mối quan hệ,...

xuanduy1508 · 4/12/24

lct_005 đã nói:
Nếu bạn nhìn vô class diagram này mà hiểu được thì đó là mục đích của UML.
Với 1 dự án mới, mọi thứ còn đang mơ hồ, thì cần phải phân tích các requirements, business logic. Rồi từ đó mới lên sơ sơ được các use cases, actors. Rồi sau đó là thiết kế, chuẩn hoá cơ sở dữ liệu, các mối quan hệ,...

mày nói thật nhìn vô mình chả biết implement thành code nó như nào á :'( kiểu cảm giác như phải 1 lần hết data vào application thì cái class uml trên nó mới có ý nghĩa

noitsnot · 5/12/24

xuanduy1508 đã nói:
mày nói thật nhìn vô mình chả biết implement thành code nó như nào á :'( kiểu cảm giác như phải 1 lần hết data vào application thì cái class uml trên nó mới có ý nghĩa

Cái class diagram này, ngoài nó ra còn có spec document nữa, tổng hợp lại hết thì mới code, đi làm thực tế có ai ném bạn nguyên cái class diagram rồi bắt code đâu mà lo, họp hành, thảo luận spec, flow chán chê rồi mới code.
Cái môn này chủ yếu để bạn làm quen với mấy cái diagram, học cách thiết kế, quan hệ giữa các entity thôi. Sau đi làm còn biết mà đọc (nếu gặp)

taytrongtayvoinguoita · 5/12/24

Bạn thử tự vẽ lại class diagram của project bạn làm rồi up lên so sánh giữa 2 thằng xem

luzstar · 5/12/24

Cái class diagram này nó không nhất thiết phải mapping 1-1 với code. Vai lớn nhất của nó chính là tạo ra một chỗ để dev align với nhau về hệ thống cuối cùng. Cái bạn đang hiểu nhầm là phải chuyển hết mớ này về class trong code (class trong java hay C++ gì đó). Nhưng mà thực thế không phải vậy. Mình nói kèm ví dụ cho dễ hiểu nhé:

Ban đầu khi muốn build 1 hệ thống ecom thì phải nắm rõ là hệ thống cần gì, có chức năng gì. Để align mấy cái đó thì sẽ cần phải làm 1 cái use case diagram để align functional và non-functional requirements. Cái diagram này sẽ là high-level spec về feature, là outcome của quá trình thống nhất giữa dev và product. Và là thứ để các dev sau vào có cái nhìn overview về hệ thống
Sau khi đã chốt được use case thì mới cần đi sâu vào các đối tượng cần có trong phần mềm (vd account, bank, admin, …) và mối quan hệ giữa các đối tượng với nhau. Class diagram này chủ yếu sẽ mô tả về cấu trúc của hệ thống ecom (sẽ có các đối tượng/ thành phần nào, đối tượng nào cần làm gì, kế thừa nhau như nào). Cái này là outcome của mấy ông architect với nhau. Để bắt đầu chia việc về cho các team. VD như team DB sẽ code mấy cái entity liên quan, team Bank bắt đầu code các service connect, …
Sau khi chia việc rồi mới bắt đầu viết spec cho từng component. Mấy cái controller, service, repository thì lúc này mới đc define cho riêng từng thằng như Bank, Account. Spec/component diagram/data flow sẽ là outcome của mấy ông senior/middle dev với nhau để chia việc cho từng ông và ra implementation chi tiết

xuanduy1508 · 5/12/24

luzstar đã nói:
Cái class diagram này nó không nhất thiết phải mapping 1-1 với code. Vai lớn nhất của nó chính là tạo ra một chỗ để dev align với nhau về hệ thống cuối cùng. Cái bạn đang hiểu nhầm là phải chuyển hết mớ này về class trong code (class trong java hay C++ gì đó). Nhưng mà thực thế không phải vậy. Mình nói kèm ví dụ cho dễ hiểu nhé:

Ban đầu khi muốn build 1 hệ thống ecom thì phải nắm rõ là hệ thống cần gì, có chức năng gì. Để align mấy cái đó thì sẽ cần phải làm 1 cái use case diagram để align functional và non-functional requirements. Cái diagram này sẽ là high-level spec về feature, là outcome của quá trình thống nhất giữa dev và product. Và là thứ để các dev sau vào có cái nhìn overview về hệ thống

Sau khi đã chốt được use case thì mới cần đi sâu vào các đối tượng cần có trong phần mềm (vd account, bank, admin, …) và mối quan hệ giữa các đối tượng với nhau. Class diagram này chủ yếu sẽ mô tả về cấu trúc của hệ thống ecom (sẽ có các đối tượng/ thành phần nào, đối tượng nào cần làm gì, kế thừa nhau như nào). Cái này là outcome của mấy ông architect với nhau. Để bắt đầu chia việc về cho các team. VD như team DB sẽ code mấy cái entity liên quan, team Bank bắt đầu code các service connect, …

Sau khi chia việc rồi mới bắt đầu viết spec cho từng component. Mấy cái controller, service, repository thì lúc này mới đc define cho riêng từng thằng như Bank, Account. Spec/component diagram/data flow sẽ là outcome của mấy ông senior/middle dev với nhau để chia việc cho từng ông và ra implementation chi tiết

vậy là class diagram như trên nhưng khi implement thì ra một cái hoàn toàn khác hả bác :'( Vậy thì nhìn class diagram vô nghĩa dữ z

JinggeNt · 5/12/24

xuanduy1508 đã nói:
vậy là class diagram như trên nhưng khi implement thì ra một cái hoàn toàn khác hả bác :'( Vậy thì nhìn class diagram vô nghĩa dữ z

Không ai rảnh để đi làm những thứ vô nghĩa đâu bạn. Từ class diagram kết hợp nhiều thứ khác mới tới bước implement code chứ chưa gì đâm đâu vào có mà chết

ooopsvn · 5/12/24

lại lẫn lộn đầu đít. UML là ngôn ngữ hay là 1 bộ các quy tắc và ký hiệu để trực quan hóa (vẽ) thiết kế của cấu trúc dữ liệu, luồng hoặc hệ thống
lôi cái ảnh UML trên mạng về vốn chỉ là ví dụ mô tả cho 1 phần cấu trúc không hoàn chỉnh, ở đây chỉ là các cái data model và các luồng liên quan đến data model, nếu đem map ra code gần như chỉ là 1 cái basic monolithic app, éo đâu tự nhiên đem so với modern ecommerce system đc vậy
thích chi tiết thì tự bôi tự vẽ thêm controller, service, repository... vào. trên mạng ai rảnh mà vẽ hết đến tận cái cọng lông cho ông tướng

luzstar · 6/12/24

JinggeNt đã nói:
Không ai rảnh để đi làm những thứ vô nghĩa đâu bạn. Từ class diagram kết hợp nhiều thứ khác mới tới bước implement code chứ chưa gì đâm đâu vào có mà chết

Bạn ấy chưa đi làm để hiểu tầm quan trọng của việc design system và alignment trước khi code

deonhodangkylanthumaynua · 11/12/24

luzstar đã nói:
Cái class diagram này nó không nhất thiết phải mapping 1-1 với code. Vai lớn nhất của nó chính là tạo ra một chỗ để dev align với nhau về hệ thống cuối cùng. Cái bạn đang hiểu nhầm là phải chuyển hết mớ này về class trong code (class trong java hay C++ gì đó). Nhưng mà thực thế không phải vậy. Mình nói kèm ví dụ cho dễ hiểu nhé:

Ban đầu khi muốn build 1 hệ thống ecom thì phải nắm rõ là hệ thống cần gì, có chức năng gì. Để align mấy cái đó thì sẽ cần phải làm 1 cái use case diagram để align functional và non-functional requirements. Cái diagram này sẽ là high-level spec về feature, là outcome của quá trình thống nhất giữa dev và product. Và là thứ để các dev sau vào có cái nhìn overview về hệ thống

Sau khi đã chốt được use case thì mới cần đi sâu vào các đối tượng cần có trong phần mềm (vd account, bank, admin, …) và mối quan hệ giữa các đối tượng với nhau. Class diagram này chủ yếu sẽ mô tả về cấu trúc của hệ thống ecom (sẽ có các đối tượng/ thành phần nào, đối tượng nào cần làm gì, kế thừa nhau như nào). Cái này là outcome của mấy ông architect với nhau. Để bắt đầu chia việc về cho các team. VD như team DB sẽ code mấy cái entity liên quan, team Bank bắt đầu code các service connect, …

Sau khi chia việc rồi mới bắt đầu viết spec cho từng component. Mấy cái controller, service, repository thì lúc này mới đc define cho riêng từng thằng như Bank, Account. Spec/component diagram/data flow sẽ là outcome của mấy ông senior/middle dev với nhau để chia việc cho từng ông và ra implementation chi tiết

+1 respect.
Mục đích là có thể hiểu được theo từng level của C4. Và vẽ UML vẫn rẻ hơn code

tranh cãi rồi quay xe vẫn rẻ.

ltdh2014 · 23/12/24

UML đâu có phi thực tế nếu mà đội dev các ông không có 1 ông Software architecture(SA hay) nắm đầu

BA làm việc với khách.
SA đảm bảo mọi luồng feature mới nằm trong scope và nằm đúng layer, module. Luồng các module không conflict.
Không có ông SA này đồng nghĩa UML tổng quan éo có, giai đoạn đầu làm feature thì ổn .Giải đoạn sau, làm feature mới lại đập đi xây lại hàng loạt nếu muốn chạy ngon, hoặc ko thì mấy ông dev sẽ chơi code vá cho xong

Giai đoạn maintaince thì coi như project hết sạch tiền lãi luôn

btw cái sơ đồ trên của bác có vẻ hơi chi tiết quá

thắc mắc Cảm thấy class UML phi thực tế khi làm application, cần người giải đáp ạ.

Junior Member

Senior Member

Junior Member

Senior Member

Junior Member

Senior Member

Senior Member

Junior Member

Senior Member

Junior Member

Junior Member

Junior Member

Junior Member

Senior Member

Junior Member

Senior Member

Senior Member

Senior Member

Member

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này