Tập thiết kế một project tốt.

[5diopt]

Dạo này mới nhận ra hồi trước đến giờ mình viết đồ án bậy bạ quá. Nên hè này định thiết kế một project nhỏ nhưng hợp quy trình để sau này viết đề tài tốt hơn. Do ban đầu mù mờ quá, nên làm đến đâu viết đến đó để mọi người góp ý cho.

+ SQL Server 2005.
+ C# .NET 2005.

Nội dung yêu câù:
+ Chương trình quản lý tài chính cho gia đình, số người trong gia đình thường không nhìu nên vấn đề tốc độ không phải bàn.
+ Các User sử dụng gồm: Chủ Hộ và Người Thân.
+ Đảm bảo các chức năng cơ bản cho cơ sở dữ liêụ: Backup, Restore, security. (chưa biết cách)
+ Người dùng có các chức năng chung: Dự toán chi tiêu trong tương lai, quản lý chi tiêu đã thực hiện, tạo các nhắc việc hàng ngaỳ. Các chi tiêu và dự đoán có thể công khai hoặc không công khai.
+ Mỗi thành viên có thể xem các chi tiêu, dự toán chi tiêu, nhắc việc công khai của người khác.
+ Chức năng riêng của chủ hộ: Xem tổng số chi tiêu không công khai của người khác. Backup, restore cơ sở dữ liêụ, toàn quyền quản lý chi tiêu chung của gia đình, Tạo các nhắc việc và các khoản chi tiêu cho người khác, Quản lý các tài khoản người dùng.
+ Thu nhập của gia đình = thu nhập đóng góp của chủ hộ + thu nhập đóng góp của người khác.
+ Định viết viết cho chạy nội mạng, tiếc là cái này chưa làm thử bao giờ.
+ Các chức năng bổ xung: Chương trình đánh giá quá trình chi tiêu của gia đình và đưa ra các ý kiến của mình.

=> Đã thiết kế Use case diagram.
=> Mới viết xong cái yêu cầu, chưa viết bảng chú giaỉ.
=> Mới viết cái class diagram cho chức năng quản lý người dùng.

* Class diaram cơ bản:

{frmMain}
|---agregation---> {Accessor}
|---agregation---> {User Control}

{User Control}
|------<Inheritance>-- {ControlLogin}
|------<Inheritance>-- {Control... }
// Note: Thừa kế để có thể đa xạ tùy biến giao diện cho từng chức năng.

{User Control}----Dêpndency--->{Accessor}


Accessor: Cung cấp những phương thức truy cập và xử lý cơ sở dữ liệu. Các phương thức được cung cấp là static (kể cả constructor để khởi tạo ngầm định).
User Control: Cung cấp những giao diện đại diện cho chức năng.


* Cho hỏi: Nghe nói có cái khuôn mẫu chuẩn của Microsoft cho thiết kế thông tin tài khoản, ai có biết qua xin chỉ giúp.
* Mình code trên Windows nhưng thiết kế thực hiện trên Umbrelo (Fedora core)

* Bất kỳ ý kiến nào xin mọi người đưa ra giúp.
* Nếu không có ý kiến nào mình sẽ xin ngưng topic này .

[SupaTrupa]

Từ cái nội dung yêu cầu, bác cố gắng việc 1 cái SRS (Software Requirement Specifications).

Trước khi bác có (hoặc gần xong) SRS, đừng làm gì cả.

[5diopt]

Bác có biết cách viết Requirement không, chỉ giúp đi hay gửi tài liệu, mình chỉ xem các Requirement trong các ebook hướng dẫn rồi làm theo thôi, cũng không biết có chuẩn không nữa!?
Mình định gửi project lên "step by step" nhưng không biết cách đính kèm file theo bài viết.
Mình đã viết xong phần quản lý User Accounts rồi nhưng đang có vài bug về xử lý dataset.

[SupaTrupa]

Tài liệu về làm sao lấy được requirements thì nhiều lắm, bác kiếm nhựng sách về [software] project management đều có hết.

Bài của bác cũng không khó lắm. Chúng ta có thể viết Requirements liền được.

Requirements cho User
1) User có những tính năng gì. Liệt kê cụ thể từng chức năng.
2) Hệ thống sẽ làm gì khi người dùng lựa chọn những chức năng đó
3) Có dữ liệu nào cần lưu khi người dùng chọn các chức năng không?

Requirements cho chủ hộ
[Tương tự]

Requirements khi login
1) Khi khởi động chương trình, màn hình sẽ hiện ra 1 số ô để người dùng điền thông tin vào [cụ thể là thông tin gì thì bác phải liệt kê ra]
2) Nếu đăng nhập thành công thì như thế nào?
3) Nếu đăng nhập không thành công thì như thế nào

Tới đây, tôi chưa thấy chức năng khởi tạo user ở đâu hết. Vậy thì ai có quyền tạo người dùng bình thường, ai có quyền tạo chủ hộ?

Trong trường hợp của bác, bác có thể vừa viết requirements vừa design (và 1 ít của implementation), với 1 design tốt thì trong vòng 1 ngày là bác có thể có code hoàn chỉnh của chương trình.

Còn làm sao để biết 1 SRS có tốt hay không thì nhìn vào 1 số characteristics của 1 good SRS
1) Are the requirements correct? Requirements có đáp ứng mục đích chương trình hay khôn?
2) Are the requirements complete? Bác có liệt kê tất cả các trường hợp của possible inputs hay chưa (ex invalid input)
3) Are the requirements unambiguous? Có requirement nào mà bác có thể có nhiều cách hiểu khác nhau hay không?
4) Are the requirements feasible? Có thể build được cái system đó hay không với máy của bác.
5) Are the requirements testable? Có thể viết test cases để test cái requirement đó hay không?
6) Are the requirements tracable? Requirements đã được sắp xếp dễ nhìn và tìm kiếm không?

Còn 1-2 cái criteria nữa mà em quên mất rồi.

[5diopt]

Tôi vừa viết xong phần quản lý accounts. Vấn đề của bác nêu ra tôi giải quyết thế này:
+ Chủ hộ có quyền thay đổi và quản lý các account (Thêm, Xóa, Sửa).
+ Khi chạy chương trình, chương trình sẽ kiểm tra trong danh sách csdl có account nào là chủ hộ (family header) không? nếu không có chương trình sẽ yêu cầu người dùng tạo một tài khoản header.
+ (Tất nhiên khi mới cài đặt chương trình, người dùng sẽ được yêu cầu tạo một header. Nên chỉ có người cài đặt chương trình mới gặp yêu cầu trên - bảo mật kiểu này có vẻ không an toàn lắm, nhưng cũng không biết thế nào)
+ Các tài khoản người thân chỉ có quyền điều chỉnh tài khoản của riêng mình (không có quyền xóa).

Hôm trước gặp cái bug trong lúc xóa một hàng trong bảng của csdl:
+ khi bạn muốn xóa một hàng trong DataTable:
Nếu bạn dùng theo kiểu sau:
myTable.Rows.Remove(myRow);
hoặc:
myTable.Rows.RemoveAt(RowID);
thì khi bạn cập nhật lại vào CSDL sẽ không thành công. Lý do là csdl chỉ cập nhật phương thức xóa hàng trong trường hợp hàng vẫn tồn tại nhưng ở trường RowState là Deletion. (Xem RowState trong MSDN).

Nếu bạn muốn xóa hàng thì bạn nên dùng cách sau:
myTabel.Rows[ID].Delete();
UpdateDatabase();

hoặc:
myRow.Delete();
UpdateDatabase();

Cụ thể là thế này, khi bạn gọi phương thức Update(myDataset), thì cái thằng CommandBuilder sẽ tìm trong các hàng của bảng trong dataset, nếu hàng nào chứa trạng thái là Deletetion thì nó sẽ tự động sinh ra SQL delete command. Nếu ta xóa hàng đó bằng phương thức Rows.Remove() hay Rows.RemoveAt() thì khi update nó không tìm thấy hàng, suy ra nó không tìm thấy trạng thái Deletion của hàng, suy ra việc xóa hàng sẽ không được thự thi.

[SupaTrupa]

Wow bác nhảy nhanh quá từ Requirement -> Implementation em hết biết đường luôn

Nếu có thể bác up lên cho em xem mấy cái class diagrams và sequence diagrams mà bác có để em góp ý cho.

[vneye]

Cái này là bệnh nan y của coder khi tập phân tích, luôn tập trung vào công đoạn coding. Ở đây quay trở lại mục đích là bạn đang muốn "xây dựng 1 project tốt", vậy nó phải đi đúng theo những bước để xây dựng project, xong bước này mới chuyển sang bước kết tiếp.

Mình thấy cái requirement vẫn chưa rõ ràng, trong requirement phải xác định được chức năng hệ thống, các actor chính tham gia hệ thống. Từ bản mô tả sơ lược này sẽ tiến hành gom nhóm những actor và sau đó phỏng vấn từng nhóm (bạn tự giả lập để phỏng vấn). Từ đó mới có tư liệu để vẽ UseCase.

[5diopt]

Ah, mình đang tập thiết kế project theo kiểu vòng lặp. Mình viết Requirement, Code, Test cho phần phân quyền và backup, restore cho cơ sở dữ liệu trước, sau đó mới tính đến chuyện khác, nhưng những phần khác mình cũng đã có ý tưởng và viết các document sơ lược rồi.
Các bác chỉ cho mình cách gửi kèm file mình sẽ đưa các phần làm được lên cho mọi người xem (Diagrams, Requirement, Code + Test). Phần test mình chỉ làm được một ít thôi vì chưa biết cách sử dụng các công cụ test sao cho tốt, chỉ là step by step rồi đưa ra các message tương ứng, hoặc là làm bằng debug. Có bác nào biết chỉ dùm.
Phần test mình cũng có đọc qua về test case, phương pháp hộp đen, hộp trắng. Nhưng vẫn chưa hiểu làm thế nào để tạo test case, thực thi test case, tổ chức cơ chế hộp đen, hộp trắng như thế nào (nói chung, kiến thức đang ở dạng... lý thuyết.)

[SupaTrupa]

Mình xin góp 1 vài ý kiến

1) Khi đọc bài của những posts trên của bạn mình cũng đoán được là bác dùng iterative model nhưng cách bác dùng chưa đúng lắm. Cũng như bác vneye đã nói, requirements của bác chưa rõ ràng. Requirements mà bác đã nêu là user requirements chứ không phải là software requirements.

2) Mình không thể bàn về test cases khi chưa thấy được design diagrams.

3) Bác nên quên User Interface và thằng SQL đi. Mấy thằng này chỉ là cái khung tranh thôi, bác còn chưa có bức tranh hoàn chỉnh thì lo cái khung đẹp làm gì.

Còn việc up mấy cái diagrams thì bác up mấy cái screenshots lên là được rồi

[SupaTrupa]

Mình xin góp 1 vài ý kiến

1) Khi đọc bài của những posts trên của bạn mình cũng đoán được là bác dùng iterative model nhưng cách bác dùng chưa đúng lắm. Cũng như bác vneye đã nói, requirements của bác chưa rõ ràng. Requirements mà bác đã nêu là user requirements chứ không phải là software requirements.

2) Mình không thể bàn về test cases khi chưa thấy được design diagrams.

3) Bác nên quên User Interface và thằng SQL đi. Mấy thằng này chỉ là cái khung tranh thôi, bác còn chưa có bức tranh hoàn chỉnh thì lo cái khung đẹp làm gì.

Còn việc up mấy cái diagrams thì bác up mấy cái screenshots lên là được rồi