2010-04-26 45 views
11

Bước đầu tiên tôi tạo ra một DFD. Sau đó, tôi chuyển sang tạo một Sơ đồ lớp. Và trong khi làm điều đó tôi cảm thấy rằng tôi nên tạo sơ đồ ER đầu tiên. Vì có nhiều chi tiết không thể chụp trong biểu đồ Lớp. Vì vậy, câu hỏi của tôi tôi nên tạo ERD đầu tiên OR Class Diagrams?Nên tạo Sơ đồ ER hoặc Sơ đồ lớp học đầu tiên?

đầu vào có giá trị của bạn được đánh giá cao guys !!! Cảm ơn bạn đã đọc

Trả lời

8

Khi người mẫu, tôi có xu hướng nghĩ về làm sơ đồ trong bất cứ trật tự có ý nghĩa nhất đối với tôi vào thời điểm đó. Đôi khi đó là sơ đồ lớp đầu tiên, đôi khi đó là sơ đồ quan hệ thực thể, đôi khi thậm chí là biểu đồ trình tự. Điều chính cần nhớ là bạn đang cố gắng hiểu mọi thứ và viết chúng xuống để những người khác cũng có thể hiểu chúng; lo lắng về cách tốt nhất để đặt hàng những suy nghĩ của bạn không phải là hữu ích như chỉ nhận được xuống đến nó và viết những phần mà bạn làm hiểu.

[EDIT]: FWIW, tôi cũng có xu hướng bắt đầu mô hình hóa trên giấy hoặc bảng trắng và chỉ chuyển sang sử dụng máy tính khi tôi gần gũi hơn với những gì tôi hiểu đang diễn ra. (Tôi đoán tôi chỉ không thích vẽ trên máy tính.) Điều quan trọng là mô hình là về sự hiểu biết, và không (rất nhiều) về máy tính.

+0

Donal, hiểu biết sâu sắc. thanks –

+0

Vâng, tôi đồng ý rằng bạn cụ thể như bạn có thể vào thời điểm đó. Nếu bạn chưa tìm ra các thuộc tính, bạn có thể thấy các relationhips ánh xạ là bước đầu tiên hợp lý. – Russell

0

Sơ đồ ER hút khi bắt đầu - vì chúng chứa thông tin LESS so với sơ đồ đối tượng, bao gồm nhiều thông tin hơn về các phương pháp trên đối tượng và cây thừa kế - cả hai yếu tố mà biểu đồ ER sẽ bỏ qua.

Như vậy, bạn bắt đầu tốt hơn với hệ thống phân cấp đối tượng (sơ đồ lớp) và sau đó mov sang bên lập bản đồ của sự vật;)

+3

tại sao bắt đầu với thông tin ít hơn (tổng quát hơn) xấu? Đó là một cách phổ biến để bắt đầu ở cấp độ cao hơn và cung cấp thêm chi tiết khi bạn đi cùng. Bạn bắt đầu bằng cách đưa ra các quyết định thiết kế, chẳng hạn như liệu một người có nên liên quan đến thú cưng hay không, cho dù chúng tôi có bao gồm một người và họ trong mô hình đối tượng hay không. – Russell

+0

Russell, cảm ơn những suy nghĩ của bạn. Điều này thật ý nghĩa. –

+1

Nhưng sự thiếu hiểu biết không trả tiền. Bỏ qua thừa kế có nghĩa là bạn kết thúc với thiết kế ngu ngốc như một đối tượng "khách hàng" trong bảng khách hàng, một đối tượng "nhân viên" trong bảng nhân viên, v.v. – TomTom

3

Chủ nghĩa thuần túy OO có xu hướng làm sơ đồ Lớp trước. Những người có nền tảng cơ sở dữ liệu làm sơ đồ ER trước tiên và "lấy được" sơ đồ lớp từ điều này (cách tiếp cận này được cau mày bởi người thuần túy OO)

Tôi thích phương pháp lai.

Xác định các thực thể trước. Điều này sẽ giống nhau từ quan điểm cơ sở dữ liệu và ứng dụng (lớp).

Khi bạn đã đồng ý về các thực thể ở mức cao, hãy tiếp tục với sơ đồ lớp và sơ đồ ER theo các hướng song song - bởi vì "các mối quan hệ" khác nhau trong mỗi. (Nếu bạn là người duy nhất làm việc trên chúng, sau đó bắt đầu với sơ đồ lớp đầu tiên và sau đó là ERD. Nhưng xác định quyền lợi đầu tiên).

Theo tôi, các thực thể cấp cao phải giống nhau, cả trên cơ sở dữ liệu và ứng dụng (Java/C# ...). Và nó rất dễ dàng để tiến hành với các cơ sở chung - đặc biệt là nếu có những người khác nhau làm việc trên các bộ phận khác nhau (các lớp, cơ sở dữ liệu).

2

Tôi sẽ nói điều đó thực sự phụ thuộc vào ứng dụng của bạn. & Tôi biết một chút về UML và tôi biết bạn có thể mô hình hóa mối quan hệ đa dạng cũng như các khóa chính chỉ bằng cách sử dụng sơ đồ lớp UML tiêu chuẩn, vì vậy sơ đồ lớp thường là đủ. Tôi thích bắt đầu với sơ đồ lớp, bởi vì tôi thích sử dụng phân tích và thiết kế hướng đối tượng, các ca sử dụng, sử dụng các trường hợp thực hiện và các lớp phân tích. Ở phía bên kia, thiết kế cơ sở dữ liệu tốt yêu cầu bình thường hóa và đôi khi không chuẩn hóa, tối ưu hóa khác nhau cho truy vấn dữ liệu ... Nhưng trước tiên, tôi cần phải biết tôi sẽ truy vấn cái gì và có thể như thế nào. Cá nhân tôi thấy phần quan hệ của hầu hết các ứng dụng giống như một cơ chế lưu trữ, tôi nghĩ về hệ thống về lập trình hướng đối tượng. Điều này đặc biệt hữu ích với ví dụ Ruby on Rails, nhờ vào mô hình Active Record hoàn toàn tóm tắt từ mô hình quan hệ, vì vậy tôi không phải lập mô hình hai lần.

Các vấn đề liên quan