Hướng dẫn phân tích thiết kế hệ thống theo hướng đối tượng UML. Help me!

[rong_do]

Chào các bạn! Mình đang làm luận văn tốt nghiệp, mình muốn phân tích thiết kế hệ thống theo hướng đối tượng UML. Mình đã học UML nhưng do cũng học lâu rồi nên quên và nó lý thuyết nhiều chưa có dịp dùng đến. Bây giờ mình đang cần phân tích bằng UML. Nếu ai biết xin chỉ giúp, mình cũng đang cần gấp. Hãy chỉ rõ giúp mình các bước cụ thể để phân tích.
Ví dụ như :
Bước 1 : làm gì?
Bước 2 : làm gì?
.........
Chi tiết chút nhé!
Thank!

[Wazi Armstrong]

Bước một: Phân tích. Đọc requirements để tìm ra các actor và use case tương ứng (hướng phân tích của mình dựa trên use case, lấy use case làm cái nhìn trung tâm) Sản phẩm của bước này là 1 use case diagram và các tài liệu liên quan gồm có: Use case specification (giải thích use case), Glossary (từ điển thuật ngữ) và các tài liệu khác...
Bước 2: Từ use case diagram, với mỗi usecase chúng ta vẽ biểu đồ Interaction để thấy được hoạt động của use case đó (Sequence Diagram hoặc Communication Diagram)
Bước 3: Từ Interation Diagram vẽ Class Diagram tương ứng với từng biểu đồ ở trên. Sau đó tổng hợp các class digram tương ứng với từng use case lại thành 1 class diagram lớn. Bước này đòi hỏi nhiều tư duy thiết kế. Sau đó thiết kế và chuẩn hóa mô hình csdl, thiết kế đặc tả ngoài, các tài liệu giải thích kèm theo...
Hết rồi!
Chúc bạn thành công!
PS: Đây chỉ là hướng đi cơ bản nhất, tùy từng dự án người ta có thể có những diagram khác hay những thứ tự có khác đôi chút.
PS2: Sau mỗi bước luôn luôn có review.

[lonesome_007]

Bác tìm đi, em thấy có một ebook thường, gặp ở dạng chm về uml rất hay, bác kiếm cái đó về đọc cho dễ ngấm chứ cái oop này em nghĩ trong một vài dòng nói hết được thì khó lắm, lúc nào em tìm thấy em up lên cho @__@

[rong_do]

Thank all! Tài liệu thì nhiều lắm nhưng đọc thì chỉ hiểu các thành phần của UML chứ không biết phải làm những bước như thế nào thôi.

[Wazi Armstrong]

Vấn đề của bạn là gì bạn có thể post lên đây mọi người cũng tìm cách giải quyết (hi vọng cái project bạn làm nó không quá lớn )
(Đính kèm hình ảnh + file của enterprice architect thì càng tốt)

[anhnt3]

Anh em có cần 1 khóa dạy về phân tích và thiết kế hướng đối tượng UML trong thực tế va Design pattern không ?
Hoặc chúng tự tạo group trao đổi về Design Pattern cũng hay.

[rong_do]

Vấn đề của bạn là gì bạn có thể post lên đây mọi người cũng tìm cách giải quyết (hi vọng cái project bạn làm nó không quá lớn )
(Đính kèm hình ảnh + file của enterprice architect thì càng tốt)

Vấn đề của bọn mình là. Sau khi đã có được sự góp ý của bạn và đã đọc thêm trong quyển phân tích thiết kế hệ thống thống tin của học viện bưu chính viễn thông, trong đó cũng đã chỉ ra các bước để phân tích và thiết kế nhưng khi phân tích lại gặp những vấn đề sau :
Sau khi phân tích và đã có được biểu đồ usecase -> biểu đồ lớp -> đến chỗ này là vẽ biểu đồ trạng thái cho đối tượng. Nhưng mình lại không hiểu cái biểu đồ này có nhất thiết phải có ko, và với mỗi đối tượng đã xác định được đều phải có biều đồ trạng thái cho nó? và nếu có thì phải xác định trạng thái cho đối tượng như thế nào. Xem nhiều báo cáo luận văn của khóa trước thì mỗi người làm 1 kiểu nên không thấy được cách xác định chung.
Ví dụ :Mìnhh có cái db như này

Mình muốn xác định các trạng thái cho các lớp. Bạn thử xác định ví dụ giúp mình 1 hoặc 2 lớp làm mẫu xem sao.

Nếu bạn không phiền thì có thể cho mình xin cái yahoo hoặc cái mail để tiện liên lạc. Mình đang rất cần cuối tháng là nộp báo cáo rồi. Cảm ơn nhiều!

Nếu được bạn có thể PM hoặc email cho mình nhé.
yahoo : back_version4
mail :back_version4@yahoo.com

[Wazi Armstrong]

Hic, vẽ biểu đồ trạng thái sao lại dựa vào DB làm gì. Mà cái DB này chui đâu ra vậy. Nếu làm bằng Enterprise Architect thì tốt.
Biểu đồ trạng thái nó như là cái otomat ý mà. Chuyển trạng thái khi mà một điều kiện nào đó được thỏa mãn. Biểu đồ này cũng không nhất thiết phải có nhưng thường thấy và có thì tốt hơn giúp cho lúc làm test case
PS: Kinh nghiệm của mình cũng chưa nhiều nên tốt nhất là nên bàn bạc trên forums. Sẽ có nhiều người có nhiều kinh nghiệm hơn.
Phân tích thiết kế là việc làm của nhóm, phải có nhiều ý kiến, phản biện mới thành sản phẩm tốt được, chứ đừng chỉ nghe theo lời 1 ai đó (kể cả của mình)

[rong_do]

Hic, vẽ biểu đồ trạng thái sao lại dựa vào DB làm gì. Mà cái DB này chui đâu ra vậy. Nếu làm bằng Enterprise Architect thì tốt.
Biểu đồ trạng thái nó như là cái otomat ý mà. Chuyển trạng thái khi mà một điều kiện nào đó được thỏa mãn. Biểu đồ này cũng không nhất thiết phải có nhưng thường thấy và có thì tốt hơn giúp cho lúc làm test case
PS: Kinh nghiệm của mình cũng chưa nhiều nên tốt nhất là nên bàn bạc trên forums. Sẽ có nhiều người có nhiều kinh nghiệm hơn.
Phân tích thiết kế là việc làm của nhóm, phải có nhiều ý kiến, phản biện mới thành sản phẩm tốt được, chứ đừng chỉ nghe theo lời 1 ai đó (kể cả của mình)

Thì trạng thái là trạng thái của đối tượng mà. Mình đọc thì thấy bảo khi xác định được các lớp rồi thì bắt đầu vẽ biểu đồ trạng thái cho các đối tượng đã xác định được(tức là trong vòng đời của đối tượng của hệ thống đã xác định - biều đồ lớp sơ bộ). Sau cái này sang phần thiết kế sẽ bắt đầu xây dựng biều đồ động gồm biều đồ tuần tự và cộng tác, tiếp theo sẽ xây dựng biểu đồ lớp chi tiết và cuối cùng là 2 biều đồ triển khai và biều đồ thành phần.

Các bước thì như vậy nhưng chi tiết các bước phải xây dựng như thế nào thì mình lại ko hiểu đc. Như cái biều đồ trạng thái thì lại ko biết xác định trạng thái như thế nào.

[anhnt3]

Như bạn Wazi Armstrong nói về biểu đồ trạng thái đó -> quan trọng là có cần phải dùng biểu đồ trạng thái hay không và không nhất thiết phải vẽ cho toàn bộ các đối tượng.

Thường thì sẽ vẽ biểu đồ trạng thái cho toàn bộ hệ thống trước ơ mức high level design.
Sau đó bạn mới mapping event và trạng thái sang các đối tượng chứ tớ không làm kiểu thiết kế ra class chi tiết rồi mới vẽ trạng thái cho nó.
Ngoài ra nếu hệ thống hoặc subsystem có nhỏ hơn 5 trạng thái thì tỡ cũng không vẽ.

Design sao cho khách hàng hiểu được requirment của họ đã có trong déign và coder từ design code được chứ không phải vẽ toàn bộ UML đâu bạn.