Đồ á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
MỤC LỤC
Đồ á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 1
MỤC LỤC 2
Đồ á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 3
PHÁT BIỂU YÊU CẦU 3
ĐẶC TẢ YÊU CẦU 4
1GIỚI THIỆU 4
1.1Mục đích 5
1.2Phạm vi dự án 5
1.3Định nghĩa, viết tắt 5
1.4Tài liệu tham khảo 5
2MÔ TẢ TỔNG THỂ 2.1Mô hình hệ thống 5
2.2Các chức năng của hệ thống 6
2.3Người sử dụng 6
3CÁC TÍNH NĂNG CỦA HỆ THỐNG 6
Đồ á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

TABLE OF CONTENTS
1GIỚI THIỆU
1.1Mục đích
1.2Phạm vi dự án
1.3Định nghĩa, viết tắt
1.4Tài liệu tham khảo
2MÔ TẢ TỔNG THỂ
2.1Mô hình hệ thống
2.2Các chức năng của hệ thống
2.3Người sử dụng
3CÁC TÍNH NĂNG CỦA HỆ THỐNG
3.1Quản trị
3.2Xem thông tin
4CÁC YÊU CẦU GIAO TIẾP
4.1Giao diện người sử dụng
4.2Giao tiếp phần cứng
4.3Giao tiếp phần mềm
4.4Giao tiếp truyền thông tin
5CÁC YÊU CẦU PHI CHỨC NĂNG
5.1Yêu cầu thực thi
5.2Yêu cầu an toàn
5.3Yêu cầu bảo mật
5.4Yêu cầu chất lượng phần mềm
5.5Yêu cầu môi trường hoạt động
5.6Yêu cầu tài liệu người sử dụng
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.

2.3Người sử dụng
Định nghĩa các nhóm người sử dụng mà ta có thể lường trước được, đó là các nhóm
người sử dụng khác nhau thường xuất hiện trong hệ thống
Xác định các đặc trưng của các nhóm người sử dụng, một số các yêu cầu có thể chỉ gắn
liền với một nhóm người sử dụng
Phân biệt mức độ đặc quyền của các nhóm người sử dụng
-Nhóm quản trị: các chức năng …
-Nhóm quản lý: các chức năng…
-Nhóm người sử dụng bình thường: chức năng…
3CÁC TÍNH NĂNG CỦA HỆ THỐNG
Phần này mô tả các chức năng của hệ thống
Mô tả tóm tắt tính năng và mức độ ưu tiên là cao, trung bình hay thấp
Liệt kê chi tiết các yêu cầu chức năng có liên quan đến tính năng này của hệ thống, đó là
các khả năng mà phần mềm phải có được khi người sử dụng thực hiện các dịch vụ cung
cấp bởi tính năng này
Liệt kê các điều kiện phản hồi lỗi, kiểm tra tính hợp lệ của dữ liệu vào…
Các yêu cầu phải ngắn gọn, súc tích, không mập mờ, có thể xác minh và phải cần thiết
3.1Quản trị
3.1.1Quản lý khóa
<Mô tả>
3.1.2Quản lý lớp
3.1.3Quản lý sinh viên
3.1.4Quản lý môn học
3.1.5Quản lý điểm
3.2Xem thông tin
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

Liệt kê các thành phần của tài liệu người sử dụng (như sổ tay người sử dụng, tài liệu
hướng dẫn on-line, hoặc các khóa hướng dẫn, hướng dẫn cài đặt, cấu hình…)
Định nghĩa một số định dạng, một số mẫu chuẩn cho tài liệu người sử dụng
 6PHỤC LỤC
Các phục lục cho tài liệu đặc tả (nếu có)
-Tài liệu viết tắt, định nghĩa các thuật ngữ
-Các mẫu tài liệu do khách hàng cung cấp
-…

•  Đến giai đoạn này, sau khi đã có bản đặc tả yêu cầu, chúng ta sẽ bắt tay vào
phân tích hệ thống trên
• Có hai phương pháp phổ biến để tiếp cận yêu cầu, phân tích hệ thống này, đó là:
phương pháp phân tích cấu trúc và phương pháp hướng đối tượng
Thông tin về 2 phương pháp này (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-)
• Phương pháp cấu trúc còn được gọi là phương pháp cổ điển, phương pháp này
được nhìn nhận dưới sự phức tạp của các chức năng của hệ thống. Chức năng
được phân rã theo một hệ thống cấu trúc nhất định do người phân tích hệ thống
đưa ra (cấu trúc phân nhánh, lặp…).Bao gồm mô hình quá trình chức năng cũng
như các mô hình dữ liệu. Sự liên kết giữa hai mô hình dữ liệu này còn đơn giản
qua các mối liên kết và luồng thông tin từ quá trình chức năng này sang chức
năng khác
==> Ưu điểm: Phân rã được chức năng, quá trình hoạt động phần mềm được
thực hiện từng bước như thế nào, khá đơn giản và dễ hiểu
==> Nhược điểm:
- Sự tách biệt giữa mô hình chức năng và mô hình dữ liệu dẫn đến những chức
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.

• UML không phải là một phương pháp, đơn thuần nó chỉ là một ngôn ngữ kí hiệu
•Là một tập các kí hiệu
•Là một tập các luật (cú pháp, ngữ nghĩa, kiểm tra) cho việc sử dụng các kí hiệu
•Dùng để hiển thị, đặc tả, xây dựng, làm tài liệu
• UML được tạo ra việc mô hình hướng đối tượng
• Hướng đối tượng sản sinh ra các mô hình thể hiện một lĩnh vực:
• Một lĩnh vực kinh doanh, ví dụ như banking
• Các thuật ngữ và đối tượng của lĩnh vực (ví dụ, tiền, séc)
• UML có thể được sử dụng để mô hình nhiều kiểu hệ thống khác nhau.
2.Mục tiêu của UML
• Cung cấp cho người sử dụng một ngôn ngữ mô hình hoá trực quan có sẵn và gợi
tả (ready to use, expressive ), để người sử dụng có thể phát triển và thay đổi các
mô hình một cách hiệu quả
• Cung cấp các kỹ thuật chuyên môn mở rộng để mở rộng các khái niệm cốt lõi
(core concepts)
• Độc lập với các ngôn ngữ lập trình riêng biệt (particular) và các tiến trình phát
triển
3.Những điểm ngoài phạm vi UML
• UML không là một phương thức
•UML không xác định/hướng vào (address) toàn bộ quá trình
•UML không quy định cách tiếp cận vào việc xác định các lớp,các phương thức
và phân tích các mô hình…
•UML không bao gồm bất kỳ quy tắc thiết kế hay cách thức giải quyết vấn đề nào
4.Các thành phần của UML
Trong hình là các thành phần cơ bản của UML, chúng ta sẽ gặp và đề cập đến
trong phần phân tích hệ thống quản lý điểm thi
Trong hình là 4+1 hướng nhìn của UML
• User model View (Use Case View hoặc Scenario View)- thể hiện các vấn đề và
các 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

giống như khái niệm chúng ta đã quen biết trong lập trình hướng đối tượng
- Một Use Case bao giờ cũng được kích hoạt bởi một tác nhân gửi thông điệp đến
cho nó
Các qui tắc xác định tác nhân
• Lọc ra các thực thể đáng quan tâm theo khía cạnh sử dụng và tương tác với hệ
thống.
• Cố gắng nhận ra các yêu cầu và đòi hỏi của tác nhân đối với hệ thống và xác định
tác nhân cần những Use Case nào.
• Có thể nhận diện ra các tác nhân qua việc trả lời một số các câu hỏi như sau:
- Ai sẽ sử dụng những chức năng chính của hệ thống (tác nhân chính)?
- Ai sẽ cần sự hỗ trợ của hệ thống để thực hiện những tác vụ hàng ngày của họ?
- Ai sẽ cần bảo trì, quản trị và đảm bảo cho hệ thống hoạt động (tác nhân phụ)?
- Hệ thống sẽ phải xử lý và làm việc với những trang thiết bị phần cứng nào?
- Hệ thống cần phải tương tác với các hệ thống khác nào? Nhóm các hệ thống này
được chia ra làm hai nhóm, nhóm kích hoạt cho mối quan hệ với hệ thống, và
nhóm mà hệ thống cần phải xây dựng của chúng ta sẽ thiết lập quan hệ. Khái
niệm hệ thống bao gồm cả các hệ thống máy tính khác cũng như các ứng dụng
khác trong chính chiếc máy tính mà hệ thống này sẽ hoạt động.
- Ai hay cái gì quan tâm đến kết quả (giá trị) mà hệ thống sẽ sản sinh ra?
Các qui tắc xác định Use Case
• Khởi đầu với Actor
- Chức năng gì được actor yêu cầu từ hệ thống ?
- Actor muốn đạt được cái gì ?
- Các sự kiện hệ thống nào tác động đến actor ? Các sự kiện nào actor cần để
thông báo hệ thống ?
- Thông tin gì actor muốn thao tác thông qua hệ thống?
• Mỗi use case phải liên quan đến một actor bằng một cách nào đó.
• Một số UC không phải được khởi tạo bởi actor
• Đô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

• Khách: là những người sử dụng bình thường, nhóm này chỉ có các chức năng cơ
bản, chủ yếu là xem các thông tin lớp, sinh viên, điểm thi
• Quản lý viên: có tất cả các quyền của khách, nhóm này có thêm các chức năng:
quản lý môn học, quản lý điểm thi, quản lý sinh viên
• Quản trị viên: có tất cả các quyền của hệ thống (bao gồm cả khách và quản lý
viên), nhóm này còn có thêm các chức năng quản lý người dùng, quản lý khóa,
quản lý lớp
Giải thích một tí: mối quan hệ giữa các tác nhân trong hình là mối quan hệ kế thừa
2.1.2Xác định các Use Case
-Xác định các Use Case của hệ thống
-Đặc tả chi tiết các Use Case theo mẫu template đặc tả Use Case
Trên đây là những Use Case tổng quát của hệ thống, việc đặc tả các Use Case sẽ theo
mẫu như sau, ta có thể đặc tả trong cùng tài liệu hoặc ở trong một tài liệu khác gọi là Use
Case Specification, chứa trong thư mục đặc tả Use Case và phân cấp theo các thư mục
cha – con
Ghi chú một tí: trong biểu đồ các Use Case trên, mối quan hệ <<include>> được gọi là
quan hệ sử dụng giữa các Use Case: A <<include>> B có nghĩa là UC A khi thực hiện
phải kéo theo UC B (giống quan hệ A => B)
Mẫu đặc tả một Use Case như sau:
1.TÓM TẮT
Mô tả tóm tắt về Use Case đang xét
2.TÁC NHÂN
Danh sách các tác nhân tác động lên Use Case đang xét
3.LIÊN QUAN
Danh sách các Use Case, các chức năng liên quan đến Use Case đang xét
4.CÁC LUỒNG SỰ KIỆN
4.1.Luồng sự kiện chính
Mô tả luồng sự kiện chính của Use Case đang xét
4.2.Luồng sự kiện rẽ nhánh
Mô tả các luồng sự kiện rẽ nhánh của Use Case đang xét

-Kết thúc Use Case
Ta phân tích tiếp các Use Case của hệ thống, sau đây là biểu đồ Use Case chi tiết của
phần quản trị hệ thống, mặc định như đã có phần đặc tả
2.2Xây dựng mô hình quan niệm
Các khái niệm của UML mà chúng ta cần nắm trong giai đoạn này là:
• Có phương pháp đề nghị nên lấy các trường hợp sử dụng làm nền tảng để tìm các
lớp, làm sao trong quá trình phân bổ trách nhiệm thì mô hình phân tích của phạm
vi bài toán sẽ từng bước từng bước được thiết lập.
Một số câu hỏi để tìm lớp
- Những thông tin nào cần lưu trữ hay phân tích ?
+ nếu có thông tin cần lưu trữ, phân tích hay những thông tin cần thiết trong một
số trường hợp thì đó có thể là một lớp
+ những khái niệm được ghi nhận trong hệ thống hoặc là những sự kiện hay
những giao tác xảy ra tại một thời điểm quan trọng
- Có những hệ thống ngoài nào?
+ nếu có, thì cần quan tâm đến chúng khi lập mô hình
+ hệ thống ngoài có thể xem như là các lớp mà hệ thống bao gồm hoặc tương tác
với chúng
- Các mô hình (pattern), các thư viện lớp, các thành phần nào đã có ?
+ nếu có các mô hình, các thư viện lớp, các thành phần của các dự án, các đồng
nghiệp hay các nhà sản xuất trước thì chúng cũng có thể là lớp
- Hệ thống phải điều khiển thiết bị nào ?
+ Các thiết bị kĩ thuật kết nối với hệ thống có thể trở thành một lớp điều khiển
thiết bị
- Các phần tổ chức ?
+ Lớp có thể miêu tả một tổ chức, đặc biệt là trong các mô hình kinh doanh
- Những vai trò nào các tác nhân thực hiện?
+ những vai trò này có thể xem như là những lớp, ví dụ như: người sử dụng,
người điều khiển hệ thống, khách hàng …
Quá trình tìm kiếm được lặp lại nhiều lần để xác định các lớp thực sự từ các lớp

3.KIỂU
Kiểu logic: cho biết người dùng đăng nhập thành công hay thất bại
4.LIÊN QUAN
Ở đây chỉ ra các hành vi liên quan với hành vi login. Trong trường hợp này nó không liên
quan với hành vi nào khác
5.GHI CHÚ
Ở đây là ghi chú về mặt kỹ thuật, thuật toán sử dụng. Trong trường hợp này không có ghi
chú gì khác
6.NGOẠI LỆ
-Trả về ngoại lệ khi có lỗi kết nối cơ sở dữ liệu
7.KẾT XUẤT
- Thông báo đăng nhập thành công nếu đăng nhập hợp lệ
- Ngược lại thông báo không thành công
- Các trường hợp khác:
+ Thông báo lỗi khi nhập thiếu username
+ Thông báo lỗi khi nhập thiếu password
8.TIỀN ĐIỀU KIỆN
- Người dùng chưa đăng nhập hệ thống
9.HẬU ĐIỀU KIỆN
- Sau khi đăng nhập thành công, phải thiết lập quyền thao tác cho người dùng trên hệ
thống
Ta tiếp tục demo với UC ‘create mark’ => tạo điểm thi