Đồ án môn học Qui trình phân tích “Hệ
thống quản lý điểm thi trong khoa của
một trường Đại học” bằng UML
Dương Nguyễn
.NET Việt Nam
11:42' PM - Thứ tư, 23/04/2008
Qui trình phân tích “Hệ thống quản lý điểm thi trong khoa của một trường Đại học” bằng
UML
PHÁT BIỂU YÊU CẦU
• Yêu cầu xây dựng một hệ thống quản lý điểm thi học kỳ của sinh viên trong 1 khoa
của một trường đại học.
• Mô tả về tổ chức như sau: một khoa trong trường đại học quản lý các sinh viên theo
khóa K1, K2,… trong mỗi khóa thì lại được chia làm nhiều lớp: K1A, K1B, K2A,
…mỗi lớp thì gồm có ít nhất 20 sinh viên và nhiều nhất là 75 sinh viên
• Khoa quản lý thông tin sinh viên theo khóa, theo lớp và theo mã sinh viên, mã sinh
viên là thông tin duy nhất để phân biệt các sinh viên với nhau, ngoài ra, hệ thống
quản lý điểm quản lý thêm thông tin: họ, tên, ngày sinh của sinh viên. Thông tin
lớp: tên lớp, thuộc khóa nào. Thông tin khóa: tên khóa, từ năm nào đến năm nào
• Việc quản lý thông tin điểm của sinh viên như sau: điểm của sinh viên được tính
theo các môn học
• Điểm thi có các thông tin sau: điểm của môn học nào, của sinh viên nào, điểm cho
phép lần 1, lần 2, lần 3, lần 4, điểm số bao nhiêu
 Chức năng người dùng
 Chức năng quản trị
 Quản trị viên có tất cả các quyền của quản lý viên nhưng ngược lại thì không
 Yêu cầu về hệ thống: xây dựng trên môi trường web, bảo mật, hoạt động 24/24, có thể
cho phép trên 100 lượt truy cập cùng 1 lúc. Sử dụng các giải pháp mã nguồn mở: ngôn ngữ
lập trình, hệ quản trị CSDL…

 ĐẶC TẢ YÊU CẦU
Đây là giai đoạn quan trọng sau khi nhận yêu cầu xây dựng hệ thống, đặc tả yêu cầu

6PHỤC LỤC
1GIỚI THIỆU
1.1Mục đích
Phần này giới thiệu về sản phẩm mà các yêu cầu của nó được đặc tả trong tài liệu này, bao
gồm các xác nhận, số phiên bản của sản phẩm.
Đây là hệ thống quản lý điểm thi của sinh viên trong phạm vi một khoa trong một trường
đại học
1.2Phạm vi dự án
Miêu tả ngắn gọn về sản phẩm được đặc tả: mục đích, các lợi ích, các mục tiêu, kết quả
liên quan
Chỉ ra phạm vi của sản phẩm, đặc biệt khi sản phẩm là một phần của một hệ thống nào đó
hoặc là một hệ thống con
Nếu có thêm các tài liệu mô tả về phạm vi khác thì đề cập nội dung của chúng vào phần
này
Đây là một hệ thống phát triển mới hoàn toàn không xây dựng dựa trên một hệ thống cũ
nào
Có khả năng sẽ phát triển để tích hợp vào hệ thống quản lý đào tạo của một khoa hoặc
trường
1.3Định nghĩa, viết tắt
Định nghĩa các cụm từ viết tắt, các thuật ngữ sử dụng trong tài liệu
Nội dung phần này có thể lưu trong một tài liệu phụ lục nếu như có nhiều nội dung
1.4Tài liệu tham khảo
Liệt kê các tài liệu, các trang web, các nguồn thông tin tham khảo
2MÔ TẢ TỔNG THỂ
2.1Mô hình hệ thống
Miêu tả ngữ cảnh và nguồn gốc của phần mềm được đặc tả trong tài liệu này. Ví dụ, sản
phẩm này đi theo một họ các sản phẩm, hoặc thay thế một hệ thống đã có hoặc là một sản
phẩm mới, độc lập
Đây là một sản tương đối độc lập, nó có khả năng phát triển tích hợp vào một hệ thống lón
hơn

3.2.1Xem thông tin khóa
3.2.2Xem thông tin lớp
3.2.3Xem thông tin điểm
4CÁC YÊU CẦU GIAO TIẾP
4.1Giao diện người sử dụng
Phần này mô tả các ràng buộc về mặt giao diện người sử dụng, các layout, button, hình
ảnh, các loại thông báo lỗi, phím tắt,…
4.2Giao tiếp phần cứng
Phần này mô tả các đặc tính về mặt vật lý của mỗi giao tiếp giữa phần mềm và các thành
phần phần cứng của hệ thống. Có thể bao gồm: các loại thiết bị hỗ trợ, giao thức truyền
thông tin giữa phần cứng và phần mềm
4.3Giao tiếp phần mềm
Mô tả các yêu cầu kết nối giữa sản phẩm với các thành phần phần mềm khác, bao gồm
DataBase, hệ điều hành, các thư viên, các công cụ,…
4.4Giao tiếp truyền thông tin
Mô tả các yêu cầu liên quan đến một vài chức năng truyền thông tin của sản phẩm (nếu
có), như: email, trình duyệt Web, giao thức truyền tin của Network server,…
5CÁC YÊU CẦU PHI CHỨC NĂNG
5.1Yêu cầu thực thi
Phần này mô tả các yêu cầu khi hệ thống thực thi (nếu có), ví dụ: hệ thống có thể phục vụ
đồng thời 100 người sử dụng, hoặc hệ thống hoạt động 24/24 …
Phải mô tả rõ ràng các yêu cầu này để nhóm phát triển có thể hiểu được và đưa ra các giải
pháp thích hợp
Phân mô tả các yêu cầu này theo từng yêu cầu chức năng, hay từng tính năng riêng biệt
5.2Yêu cầu an toàn
Mô tả các khả năng có thể tác động gây hư hại cho sản phẩm, đồng thời đề ra một số giải
pháp an toàn cho sản phẩm
5.3Yêu cầu bảo mật
Mô tả các yêu cầu về bảo mật của sản phẩm
5.4Yêu cầu chất lượng phần mềm

năng hoàn toàn giống nhau nhưng xử lý những kiểu dữ liệu khác nhau phải được
viết lại liên tục.
- Thiếu linh động, phí phạm mã, khó mở rộng, khó thích nghi của phầm mềm xây
dựng dựa vào phương pháp này.
- Việc dựa vào cấu trúc của quá trình chức năng dẫn đến khi chức năng hệ thống
thay đổi, cấu trúc ấy có thể bị thay đổi rất nhiều, thậm chí phải thay đổi toàn bộ
• Phương pháp hướng đối tượng: Phương pháp này xác định rằng, cấu trúc thông tin
trong hệ thống thông tin là ít thay đổi.Thế giới xung quanh dưới dạng đối tượng rời
rạc. Phương pháp đưa ra khái niệm đối tượng để mô tả thông tin. Giới thiệu thêm
mối quan hệ kế thừa cha con. Các chức năng được xây dựng trên hệ cấu trúc đối
tượng nhờ sự kết hợp thông tin và chức năng trên cấu trúc đối tượng
==>Ưu điểm:
- Tăng cường tính sử dụng: qua mối liên kết kế thừa, không chỉ những hành vi,
đoạn mã được tái sử dụng mà cả những thông tin tĩnh của lớp cha cũng được lớp
con tái sử dụng.
- Tăng cường tính mở rộng: việc mở rộng chức năng có thể được thực hiện qua
việc tạo lớp con. Vì vậy không ảnh hưởng đến cấu trúc thông tin đã có. Hơn thế
nữa phần mềm trở nên linh động hơn hẳn.
==>Nhược điểm:
- Do dựa vào cấu trúc thông tin thay vì chức năng. Nếu cấu trúc này thay đổi (lĩnh
vực ứng dụng thay đổi) thì việc xây dựng lại một hệ thống khác là không tránh
khỏi. Do đó phương pháp này thiếu sự linh động với sự thay đổi của thông tin
Trong bài viết này chúng ta sẽ sử dụng phương pháp hướng đối tượng để tiếp cận hệ thống,
do đó chúng ta cần phải có những kiến thức nhất định về lý thuyết hướng đối tượng: lớp,
đối tượng, trừu tượng hóa, cụ thể hóa, kế thừa,…
Mục đích của bài viết là sử dụng ngôn ngữ hình thức UML để phân tích hệ thống, do đó
chúng ta sẽ điểm qua một số kiến thức ccơ bản về UML
MỘT SỐ KIẾN THỨC CƠ BẢN VỀ UML
Unified Modeling Language
• 1.UML là gì

giải pháp liên quan đến chức năng tổng quát của hệ thống.
• Structural model View (static hoặc Logical View)- thể hiện các vấn đề liên quan
đến cấu trúc thiết kế của hệ thống.
• Behavioral model View (Dynamic, Process Concurrent, hoặc Collaboration View)
thể hiện các vấn đề liên quan đến việc xử lý giao tiếp và đồng bộ trong hệ thống.
• Implementation model View (Component View) thể hiện các vấn đề liên quan đến
việc tổ chức các thành phần trong hệ thống.
• Environment model View (Deployment View) thể hiện các vấn đề liên quan đến
việc triển khai hệ thống.
( Trích giáo trình UML của thầy Nguyễn Thanh Bình - Trung tâm CNTT- Đại học
Huế -HITEC)
GIAI ĐOẠN PHÂN TÍCH YÊU CẦU HỆ
THỐNG
Đây là giai đoạn phân tích yêu cầu của hệ thống, chúng ta sẽ nhìn hệ thống theo 2 hướng
nhìn: Use case view và Logic View
- Hướng nhìn Use case là hướng nhìn hệ thống dưới dạng các chức năng tổng quát, từ đây
chúng ta có thể nắm bắt được yêu cầu của người sử dụng, sự giao tiếp với hệ thống…
- Hướng nhìn logic: ta nhìn hệ thống về mặt cấu trúc, sự liên hệ, liên kết giữa các thành
phần, đối tượng trong hệ thống

2.1Xây dựng biểu đồ Use Case
Các khái niệm của UML mà chúng ta cần nắm trong giai đoạn này là:
• Khái niệm Use case
- Là một miêu tả của một trường hợp đơn của hệ thống được sử dụng
- Là một tương tác giữa người sử dụng và hệ thống máy tính
- Một Use Case là đại diện cho một chức năng nguyên vẹn mà một tác nhân nhận
được.
• Tác nhân (actors)
- Một tác nhân là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng
hệ thống

• Đôi lúc nên nghĩ về input và output của hệ thống
• Sự kiện gì hệ thống phải khởi tạo hay đáp ứng
• Sự kiện sẽ giúp tìm ra UC sau đó tìm ra actor
• Đối với mỗi tác nhân, hãy hỏi các câu hỏi sau:
- Tác nhân này cần những chức năng nào từ hệ thống? Hành động chính của tác
nhân là gì ?
- Tác nhân có cần phải đọc, phải tạo, phải hủy bỏ, phải sửa chữa, hay là lưu trữ một
loại thông tin nào đó trong hệ thống?
- Tác nhân có cần phải báo cho hệ thống biết về những sự kiện nào đó? Những sự
kiện như thế sẽ đại diện cho những chức năng nào?
- Hệ thống có cần phải thông báo cho Actor về những thay đổi bất ngờ trong nội bộ
hệ thống?
- Công việc hàng ngày của tác nhân có thể được đơn giản hóa hoặc hữu hiệu hóa
qua các chức năng mới trong hệ thống (thường đây là những chức năng tiêu biểu
chưa được tự động hóa trong hệ thống)?
• Các câu hỏi khác:
- Use Case có thể được gây ra bởi các sự kiện nào khác?
- Ví dụ :
+ Sự kiện thời gian: Cuối tháng, hết hạn đầu tư.
+ Sự kiện bình thường của hệ thống: Tự động chuyển tiền theo các lệnh xác định
trước.
+ Các sự kiện bất bình thường: Hợp đồng đầu tư kết thúc trước thời hạn.
+ Hệ thống cần những thông tin đầu vào/đầu ra nào? Những thông tin đầu vào/đầu
ra đó từ đâu tới và sẽ đi đâu?
+ Khó khăn và thiếu hụt chính trong hệ thống hiện thời nằm ở đâu (thủ công /tự
động hóa)?
2.1.1Xác định các tác nhân của hệ thống
-Xác định các tác nhân
-Đặc tả chi tiết các tác nhân
Từ yêu cầu ta xác định được các tác nhân của hệ thống như sau

Mô tả các luồng sự kiện rẽ nhánh của Use Case đang xét
Ở đây ta chỉ demo một Use Case login, tuy nhiên, trong hệ thống có bao nhiêu Use Case
thì sẽ có bấy nhiêu phần đặc tả Use Case
1.TÓM TẮT
Login là Use Case người sử dụng đăng nhập vào hệ thống quản trị để thực hiện được các
chức năng quản trị của hệ thống
2.TÁC NHÂN
Tác nhân: Khách (trước khi đăng nhập vào hệ thống, tác nhân tác động lên Use Case này
chỉ là khách)
3.LIÊN QUAN
Không có Use Case liên quan
4.CÁC LUỒNG SỰ KIỆN
4.1.Luồng sự kiện chính
-Trên giao diện quản trị hệ thống, người dùng chọn đăng nhập
-Hệ thống hiển thị giao diện đăng nhập, yêu cầu người dùng nhập username và password
-Người sử dụng nhập username và pasword, chọn đồng ý đăng nhập
-Hệ thống tiếp nhận thông tin, kiểm tra username và password của người dùng
-Nếu hợp lệ, hệ thống chấp nhận đăng nhập, hiển thị thông báo đăng nhập thành công
-Kết thúc Use Case
4.2.Luồng sự kiện rẽ nhánh
Luồng 1:
-Tại giao diện đăng nhập, người dùng không muốn tiếp tục, chọn hủy bỏ
-Kết thúc Use Case
Luồng 2:
-Hệ thống kiểm tra thông tin đăng nhập không chính xác
-Hệ thống từ chối đăng nhập, hiển thị thông báo
-Kết thúc Use Case
Luồng 3:
-Hệ thống kết nối cơ sở dữ liệu để kiểm tra thông tin, quá trình kết nối không thành công,
không thực hiện kiểm tra được