ĐẠI HỌC QUỐC GIA TP.HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
KHOA CÔNG NGHỆ PHẦN MỀM – KHÓA 1

Đề tài môn học:
PHÂN TÍCH
THIẾT KẾ HƯỚNG ĐỐI TƯỢNG
Sinh viên thực hiện:
Trần Công Danh 06520068
Võ Đinh Duy 06520112
Nguyễn Thanh Hoàng 06520182
Đoàn Nhật Trực 06520512

Giáo viên hướng dẫn:
Th.S Phan Thi Vương
Thiết kế hướng đối tượng CSMS
TP.Hồ Chí Minh - 13 tháng 01, năm 2010.
Trang 2
Thiết kế hướng đối tượng CSMS
MỤC LỤC
MỤC LỤC 3
LỜI NÓI ĐẦU 6
1.Yêu cầu người dùng 6
1.1.Yêu cầu chức năng 7
1.1.1.Các nghiệp vụ chính 7
1.1.2.Yêu cầu về lưu trữ 7
1.1.3.Chức năng tra cứu 7
1.1.4.Chức năng tra cứu 7
1.1.5.Chức năng kết xuất 7
1.2.Yêu cầu phi chức năng 7
1.2.1.Yêu cầu bảo mật 7

1.2.2.Yêu cầu mã hóa 7
1.2.3.Sao luu định kỳ, phục hồi sự cố 7
1.2.4.Giao diện 7
2.Use Case 7
2.1.Sơ đồ Use Case 7
2.2.Danh sách các Actor 7
3.Sơ đồ phân lớp (Class Diagram) 8
3.1.Sơ đồ lớp (mức phân tích) 8
3.2.Danh sách các lớp đối tượng và quan hệ 8
3.3.Mô tả chi tiết từng lớp đối tượng 8
3.3.1.Người sử dụng 8
3.3.2.Thu ngân 8
3.3.3.Thủ kho 8
3.3.4.Quản lý 8
3.3.5.Phiếu nhập 8
Trang 3
Thiết kế hướng đối tượng CSMS
3.3.6.Biểu mẫu thống kê 8
3.3.7.Thông tin giảm giá 8
3.3.8.Phiếu hẹn 8
3.3.9.Khách hàng 8
3.3.10.Hóa đơn 8
3.3.11.Nhà cung cấp 8
3.3.12.Sản phẩm linh kiện 8
4.Thiết kế cơ sở dữ liệu 10
4.1. Sơ đồ logic 10
4.2.Mô tả chi tiết 10
4.2.1.Employee (Nhân viên) 10
4.2.2.Customer (Khách hàng) 10
4.2.3.Supplier (Nhà cung cấp) 10

4.2.4.Manufacturer (Nhà sản xuất) 10
4.2.5.Receipt (Hóa đơn) 10
4.2.6.ProductType (Loại sản phẩm) 10
4.2.7.Product (Sản phẩm) 10
4.2.8.ReceiptDetail (Chi tiết hóa đơn) 10
4.2.9.ImportInfo 10
4.2.10.ImportInfoDetail 10
4.2.11.Promotion 10
4.2.12.Warranty 10
4.3.Ước lượng rủi ro và giải pháp 13
4.4.Ước lượng chi phí 15
5.Thực thi và kiểm soát dự án 18
5.1.Quản lý chất lượng 18
5.1.1.Coding convention 18
Trang 4
Thiết kế hướng đối tượng CSMS
5.1.2.Document convention 18
5.1.3.Quản lý source code 19
5.1.4.Quy trình áp dụng 20
5.2.Cập nhật tiến độ công việc 21
6.Kết thúc dự án 21
6.1.Bài học kinh nghiệm 21
6.2.Đánh giá kết quả 22
6.3.Hướng phát triển 23
Tài liệu tham khảo 23
Trang 5
Thiết kế hướng đối tượng CSMS
LỜI NÓI ĐẦU
Thiết kế hướng đối tượng là một kỹ thuật rất cần thiết đối với những kỹ sư
công nghệ thông tin khi đi vào làm việc trong thực tế. Kỹ thuật này không chỉ

giúp cho sinh viên có một cách nhìn khái quát, ánh xạ từ các đối tượng thực tế
vào trong chương trình mình; mà còn giúp cho chính sản phẩm phần mềm gần
gũi với thực tiễn và công việc bảo trì, nâng cấp về sau được thực hiện dễ dàng
hơn. Vì chính tầm quan trọng của kỹ thuật này trong tương lai, nên nó trở thành
một môn học rất cần thiết, nhằm giúp sinh viên một phần nào tiếp cận với những
dự án thật sự trong tương lai. Với những kiến thức của môn học, chúng tôi đã
cùng nhau thực hiện dự án CSMS (Computer Store Management Software) để áp
dụng những kiến thức ấy vào thực tiễn, đánh giá và nhận biết sự khác biệt những
khó khăn giữa lý thuyết và thực tiễn.
Nhưng do năng lực nên không thể trình bày đầy đủ và cũng có thể gây
thiếu sót, sai lầm trong cách nhận thức và trình bày. Mong thầy cô và các bạn
góp ý để bài báo cáo và dự án của chúng tôi có thể hoàn thiện tốt hơn.
Sinh viên thực hiện:
Trần Công Danh 06520068
Võ Đinh Duy 06520112
Nguyễn Thanh Hoàng 06520182
Đoàn Nhật Trực 06520512
1. Yêu cầu người dùng
Trước khi bắt tay vào làm một dự án phần mềm ta phải có một bước gọi là
bước khởi động cho dự án sắp bắt đầu . Điều này là cần thiết vì dư án cần bắt đầu
Trang 6
Thiết kế hướng đối tượng CSMS
với một lời tuyên bố , một cuộc họp ra mắt để các thành viên biết rõ họ đang làm
về các gì .
Thêm vào đó là đề ra tiêu chí hoạt động cho các thành viên trước khi bắt tay
vào xây dựng dư án .
1.1.Yêu cầu chức năng
1.1.1. Các nghiệp vụ chính
1.1.1.1. Quy trình bán hàng
1.1.1.2. Quy trình nhập hàng

1.1.1.3. Quy trình bảo hành
1.1.1.4. Tra cứu
1.1.1.5. Thống kê
1.1.2. Yêu cầu về lưu trữ
1.1.3. Chức năng tra cứu
1.1.4. Chức năng tra cứu
1.1.5. Chức năng kết xuất
1.2. Yêu cầu phi chức năng
1.2.1. Yêu cầu bảo mật
1.2.2. Yêu cầu mã hóa
1.2.3. Sao luu định kỳ, phục hồi sự cố
1.2.4. Giao diện
2. Use Case
2.1. Sơ đồ Use Case
2.2. Danh sách các Actor
Trang 7
Thiết kế hướng đối tượng CSMS
3. Sơ đồ phân lớp (Class Diagram)
3.1. Sơ đồ lớp (mức phân tích)
3.2. Danh sách các lớp đối tượng và quan hệ
3.3.Mô tả chi tiết từng lớp đối tượng
3.3.1. Người sử dụng
3.3.2. Thu ngân
3.3.3. Thủ kho
3.3.4. Quản lý
3.3.5. Phiếu nhập
3.3.6. Biểu mẫu thống kê
3.3.7. Thông tin giảm giá
3.3.8. Phiếu hẹn
3.3.9. Khách hàng

3.3.10. Hóa đơn
3.3.11. Nhà cung cấp
3.3.12. Sản phẩm linh kiện
Trang 8
Thiết kế hướng đối tượng CSMS

Trang 9
Thiết kế hướng đối tượng CSMS
4. Thiết kế cơ sở dữ liệu.
4.1. Sơ đồ logic
4.2.Mô tả chi tiết
4.2.1. Employee (Nhân viên)
4.2.2. Customer (Khách hàng)
4.2.3. Supplier (Nhà cung cấp)
4.2.4. Manufacturer (Nhà sản xuất)
4.2.5. Receipt (Hóa đơn)
4.2.6. ProductType (Loại sản phẩm)
4.2.7. Product (Sản phẩm)
4.2.8. ReceiptDetail (Chi tiết hóa đơn)
4.2.9. ImportInfo
4.2.10. ImportInfoDetail
4.2.11. Promotion
4.2.12. Warranty
Trang 10
Thiết kế hướng đối tượng CSMS
Chúng tôi dùng sơ đồ AON để minh họa cho kế hoạch phân bổ thời gian
cho công việc
4.2.13.Giai đoạn 1 : Khởi động dự án
Hình 2.2.1 – 1. Sơ đồ mạng AON cho giai đoạn 1 Khởi tạo dự án
4.2.14.Giai đoạn 2 : Thiết kế

Trang 11
Thiết kế hướng đối tượng CSMS
Hình 2.2.1 – 2. Sơ đồ mạng AON cho giai đoạn 2 Thiết kế
4.2.15.Giai đoạn 3 : Thực thi coding
Hình 2.2.1 – 3. Sơ đồ mạng AON cho giai đoạn 3 Thực thi coding
4.2.16.Giai đoạn 4 : Kết thúc dự án
Trang 12
Thiết kế hướng đối tượng CSMS
Hình 2.2.1 – 4. Sơ đồ mạng AON cho giai đoạn 4 Kết thúc dự án
4.3.Ước lượng rủi ro và giải pháp
Mã rủi ro Nguyên nhân Cách giải quyết
R001 Nhân sự: Một thành viên trong nhóm
bất đồng ý kiến với những thành viên
còn lại nên rời khỏi nhóm.
Tuyển chọn thành viên mới. Xem
xét lại cách thức làm việc nhóm. Cần
thống nhất các tiêu chí giải quyết khi
xảy ra mâu thuẫn.
R002 Nhân sự: Một thành viên trong nhóm
bắt buộc rời khỏi nhóm trong một thời
gian để giải quyết việc cá nhân.
Xem xét lại những công việc của
thành viên ấy, chia sẽ một phần cho
những thành viên khác; kéo dài thời
hạn deadline; hoặc phân công nghiên
cứu những công việc sẽ giúp ích cho
dự án trong tương lai.
R003 Nhân sự: Hai thành viên trong nhóm
xảy ra mâu thuẫn, khi cùng làm việc với
nhau; 2 hướng giải quyết khác nhau cho

cùng một vấn đề, dẫn đến trễ thời hạn
nộp task; năng lực giao tiếp kém.
Nhóm trưởng đứng ra xem xét, lựa
chọn cách giải quyết phù hợp nhất.
Đưa ra những phương hướng giải
quyết chi tiết khi xảy ra mâu thuẫn
như báo cáo nhóm trưởng, tìm hiểu
cách giải quyết vấn đề của thành
viên kia, cũng cố lập luận để trình
bày cách giải quyết của mình.
R004 Nhân lực: Có sự khác nhau về năng lực Tìm hiểu rõ điểm mạnh yếu của từng
Trang 13
Thiết kế hướng đối tượng CSMS
chuyên môn giữa các thành viên. thành viên đối với từng lĩnh vực.
Dành một khoảng thời gian tự
nghiên cứu cho thành viên ấy, xem
đó như là một phần của công việc.
Phân công thành viên mạnh ở lĩnh
vực ấy làm việc cùng với thành viên
yếu hơn. Thống nhất quy tắc làm
việc, giúp đỡ nhau cùng tiến bộ.
R005 Nhân lực: Năng lực quản lý lãnh đạo
của nhóm trưởng không tốt.
Ban đầu các thành viên hỗ trợ cho
nhóm trưởng liệt kê công việc, theo
dõi tiến độ. Sau 2 tuần mà công việc
tiến triển không theo ý muốn, thì cả
nhóm họp lại để lựa chọn nhóm
trưởng mới.
R006 Thời gian dự án: Các thành viên không

giao nộp task đúng thời hạn, dẫn đến
thời gian dự án kéo dài.
Tìm hiểu nguyên nhân dẫn đến việc
trễ hẹn như do năng lực chuyên
môn, giao tiếp giữa các thành viên
kém, việc cá nhân; mà có cách giải
quyết khác nhau. Nhóm trưởng cần
ước lượng, đánh giá thời gian hợp lý
hơn, đưa ra thời gian dự trữ phù hợp.
R007 Quản lý source doe: Các thành gặp khó
khăn trong việc sắp xếp, merge các
phiên bản source code lại với nhau
Dùng công cụ SVN để quản lý
source. Trainning cách update,
commit source, các xử lý khi xảy ra
conflic.
R008 Chi phí dự án: tăng cao, do chi phí vể
nhân sự tăng.
Xác định nguyên nhân:
• Do tiền lương tăng cao
• Do thời gian dự án kéo dài
hơn dự kiến dẫn đến số tiền
phải trả tăng.
 Cần tính toán, phân chia
công việc một các khao học
và hợp lý hơn về thơi gian.
Trang 14
Thiết kế hướng đối tượng CSMS
Hình 2.3 – 1: Mô hình xương cá định vị mức độ rủi ro
4.4.Ước lượng chi phí

Một dự án muốn có lời thì người quản lý phải biết cách ước lượng chi phí cho
dự án đó . Dự án dẫn đến thất bại cũng do một phần ước lượng chi phí sai dẫn
đến dự án thua lỗ.
Trước khi tiến hành ký kết hợp đồng , người quản lý cần ước lượng xem chi
phí đầu tư vào dự án liệu có đủ để hoàn thành dự án hay không . Từ đó đàm phán
với khách hàng nhằm giảm bớt các tính năng của hệ thống hoặc tăng thêm vốn
đầu tư . Điều này phụ thuộc vào sự thỏa thuận giữa hai bên.
Nhóm CSMS đã áp dụng kĩ thuật tính NPV để tính chi phí cho dự án và thời
gian hoàn vốn :
Trang 15
Thiết kế hướng đối tượng CSMS
Hình 2.4 – 1. Bảng ước lượng chi phí cho dự án CSMS
Với bảng trên thì trong tháng đầu , vốn chi phí bỏ ra là 2 triệu để bắt đầu
dự án , lợi nhuân thu về là 0 . ở các tháng tiếp theo vốn đầu tư sẽ ít hơn do dự
án đã ỗn định và thu về lợi nhuận ( lợi nhuận tăng dần ). Tỉ lệ khấu hao là 8%.
NPV = Lợi nhuận khấu hao – chi phí khấu hao
Cash flow khấu hao = lợi nhuận khấu hao – chi phí khấu hao
ROI : tỉ lệ lợi nhuận
Qua bảng trên ta sẽ thấy qua tháng thứ 3 , dự án CSMS sẽ hoàn lại vốn .
Trang 16
Thiết kế hướng đối tượng CSMS
Hình 2.4 – 1. Lược đồ biểu diễn thời gian hoàn vốn
Thời gian hoàn vốn là điểm giao nhau giữa hai đường biễu diễn . Đây chỉ mới
là ước lượng cho 3 tháng đầu của dự án CSMS , cứ mỗi tháng quản lý nhóm dự
án sẽ thêm vào thông tin lợi nhuận các tháng tiếp theo 4, 5,6 …. Để biêt được dự
án đang lời hay lỗ.
Trang 17
Thiết kế hướng đối tượng CSMS
5. Thực thi và kiểm soát dự án
5.1.Quản lý chất lượng

5.1.1. Coding convention
Để đảm bảo dự án làm xong dễ dàng bảo trì và phát triển , cần có một tài
liệu chuẩn về code để các thành viên dựa theo .
Dự án CSMS là một dự án viết bằng ngôn ngữ C# nên nhóm sẽ chọn tài
liệu “Standard Csharp coding convention” để chuẩn hóa code theo khuôn mẫu.
5.1.2. Document convention
Trong quá trình làm việc có phát sinh một số tài liệu cần phải làm , nhưng cần
phải có sự thống nhất giữa các tài liệu ( font, màu sắc , cỡ chữ ) để tài liệu mạch
lạc và xuyên suốt .
Dưới đây là chuẩn viết tài liệu mà nhóm đề ra :
Hình 3.1.2 – 1. Document convention
Trang 18
Thiết kế hướng đối tượng CSMS
5.1.3. Quản lý source code
Để quản lý Source code nhóm dùng server của Google code để tạo một
project và đưa source code của cả dự án lên đó (tham khảo tại
)
Hình 3.1.3 – 1. Tạo một project trên Google code
Thêm vào đó nhóm sử dụng chương trình TotoiseSVN 1.6 để checkout và
commit code .
Hình 3.1.3 – 2. Cấu trúc thư mục trên server
Trang 19
Thiết kế hướng đối tượng CSMS
Dựa vào cấu trúc trên :
• Branches : thư mục chứa các phiên bản của chương trình CSMS ( hiện
tại là 0.2 ) , hoặc là các nhánh khác của chương trình , khi đến cuối sẽ
được merge lại .
• Document : thư mục chứa các tài liệu phân tích thiết kế của CSMS +
file chạy SQL .
• Trunk : là nơi chức sản phẩm cuối cùng.

Một số quy định khi làm việc với SVN :
• Các thành viên Update code trước khi commit
• Chức năng chạy ổn mới được commit
• Mỗi commit phải có một dòng comment ( lời ghi chú ) để biết nội
dung chỉnh sữa .
• Khi bị conflict file thì các thành viên liên quan đến file đó họp lại giải
quyết.
5.1.4. Quy trình áp dụng
Dự án CSMS áp dụng quy trình thác nước cải tiến . Sau mỗi giai đoạn:
khào sát, phân tích, thiết kế, …. Đều có một bước quay lui lại để xác thực lại
yêu cầu phần mềm đề ra , sau đó mới chuyển sang giai đoạn tiếp theo.
Hình 3.1.4 – 1. Mô hình thác nước cải tiến
Trang 20
Thiết kế hướng đối tượng CSMS
5.2.Cập nhật tiến độ công việc
Cách thức tiến hành cập nhật công việc của mỗi thành viên trong dự án
CSMS như sau:
• Nhóm trưởng dựa vào những công việc đã được liệt kê trong WBS để tiến
hành phân chia công việc cho từng thành viên, tùy theo mỗi giai đoạn.
Nhóm trưởng đưa thông tin về những công việc cần phải làm lên Google
group của nhóm, kèm theo thời gian deadline.
• Khi đã hoàn thành thì mỗi thành viên phải gửi thông báo đến group nhằm
báo cáo cho mọi thành viên trong nhóm biết đã hoàn thành và cho nhóm
trưởng biết nhằm để xem xét và thông qua. Đồng thời dùng SVN để đưa
kết quả lên host chung tại GoogleCode.
• Sau khi nhận thông báo, nhóm trưởng sẽ review lại. Nếu chưa thỏa theo
đúng yêu cầu mong muốn, thì sẽ đề nghị thành viên xem xét lại. Ngược lại
thì nhóm trưởng sẽ cập nhật tiến độ hoàn thành trong tập tin
CSMS_WBS.mpp
6. Kết thúc dự án.

6.1.Bài học kinh nghiệm
Sau khi dư án kết thúc cần có một bản tài liệu nhằm rút ra những kinh nghiệm
sau khi trải qua dự án .Mục đích của việc này là để rút ra được những sai sót
Trang 21
Thiết kế hướng đối tượng CSMS
trong quá trình quản lý dự án , tìm ra cách khắc phục tránh được nguy cơ xảy ra
trong các dự án khác .
Bản này được soạn ra nhằm trả lời một số câu hỏi : từ đó đánh giá được
những gì làm được và chưa làm được như :
• Bạn đã đáp ứng được mọi yêu cầu trong bản Scope statement ?
• Bạn đã đáp ứng đúng chi phí và thời gian ?
• Bạn thấy điều gì đúng , chưa đúng ?
• Kinh nghiệm rút ra cho dự án sau .
• Những điều học hỏi được qua dự án hiện tại ?
Hình 4.1 – 1. – Một mẫu lesson learned của CSMS
6.2.Đánh giá kết quả
• Đạt được những những kết quả phù hợp với yêu cầu đặt ra của người
dùng: về mặt tính năng, giao diện.
• Các thành viên đã phần nào quen với cách làm việc quy chuẩn, các xung
đột vì thế cũng ít xuất hiện hơn.
Trang 22
Thiết kế hướng đối tượng CSMS
• Các thành viên trưởng thành hơn trong kỹ năng giao tiếp, kỷ luật làm việc
trong nhóm. Kỹ năng về quản lý dự án được cũng cố, thông qua những
phần tính toán, ước lượng chi phí, thời gian.
6.3.Hướng phát triển
• Mở rộng chương trình có thể quản lý, theo dõi ngày công cùa nhân viên.
• Sử dụng dữ liệu khách hàng nhắm thống kế, lấy tri thức để sử dụng cho
việc đưa ra các kế hoạch kinh doanh.
• Hỗ trợ quản lý nhiều chương trình khuyến mãi.

• Cải tiến giao diện chương trình, nhằm tăng tính thân thiện với người dùng.
Tài liệu tham khảo.
[1] Quản lý dự án, PGS.TS Trương Mỹ Dung, khoa Công Nghệ Thông Tin, Đại
học Khoa Học Tự Nhiên, Đại học Quốc gia TPHCM
[2] www.itpm.com
Trang 23