Quản lý điểm thi của một trường ĐH (P.4)

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
    – Tác nhân tương tác với hệ thống như không thuộc về hệ thống
    – Một tác nhân giao tiếp với hệ thống bằng cách gửi hoặc là nhận thông điệp, 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
  • 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

  • Hệ thống có 3 tác nhân chính: khách, quản lý viên và quản trị viên
  • Đặc tả chi tiết các tác nhân
  • 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ệ < > được gọi là quan hệ sử dụng giữa các Use Case: A < > 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

Ở đâ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
-Hiển thị thông báo lỗi
-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ả p:


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à:

  • Khái niệm Lớp: khái niệm lớp này tương tự lớp trong lý thuyết OOP


-Xác định các lớp đối tượng ban đầu liên quan đến hệ thống, mô tả sơ lược về các lớp đối tượng
-Xác định các mối quan hệ giữa các lớp đối tượng trên

Các qui tắc xác định lớp
Có nhiều phương pháp được đề xuất để xác định lớp

Có phương pháp đề nghị tiến hành phân tích phạm vi bài toán, chỉ ra tất cả các lớp thực thể (thuộc phạm vi bài toán) với mối quan hệ của chúng với nhau. Sau đó nhà phát triển sẽ phân tích từng trường hợp sử dụng và phân bổ trách nhiệm cho các lớp trong mô hình phân tích (analysis model), nhiều khi sẽ thay đổi chúng hoặc bổ sung thêm các lớp mới.
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 ừng cử viên, sau đó xác định các thuộc tính (thường là các danh từ) và các phương thức (thường là các động từ) cho lớp

Việc xác định các lớp ừng cử viên này cùng các mối liên hệ giữa chúng tạo thành 1 biểu đồ lớp ở mức quan niệm


Trên là các lớp ứng cử viên ta xác định được từ các phát biểu của bài toán, sau quá trình tìm các lớp ứng cử viên, ta xác định các thuộc tính và phương thức của chúng(trong giai đoạn này chủ yếu các lớp chỉ có các thuộc tính – đây là các lớp thực thể, đến phần tiếp theo ta sẽ xác định thêm các lớp đòng vai trò xử lý – sẽ xuất hiện các phương thức)


Phần các liên hệ giữa các lớp, các bản số cần có kiến thức về lý thuyết CSDL
Trong các lớp ứng của viên, ta nhận thấy giữa các lớp Guests, Managers, Admin có mối quan hệ kế thừa, và sự có mặt của các lớp này trong hệ thống là không rõ ràng, bằng quá trình khái quát hóa, ta xây dựng lại các lớp như sau (lam sao nhận ra và xây dựng lại được ấy à ! làm nhiều thì được p:)


Một user sẽ đóng 1 nhóm vai trò: admin, manager hay guest, một vai trò sẽ được phân cho một số quyền (right), một quyền chỉ thuộc 1 nhóm vai trò, các vai trò có quan hệ kế thừa : admin kế thừa manager, manager kế thừa guest => các quyền của chúng được kế thừa

2.3Xây dựng biểu đồ tuần tự
-Xây dựng biểu đồ tuần tự theo các Use Case (nếu cần thiết)
Biểu đồ tuần tự cho ta thấy luồng thực hiện một hành vi (operation) theo trình tự thời gian, qua biểu đố tuần tự ta sẽ thấy được trình tự thực hiện của một chức năng của hệ thống

Trước hết ta sẽ demo với hành vi ‘login’

-Đặc tả các hành vi trên mỗi biểu đồ tuần tự theo mẫu template đặc tả hành vi
Ta đặc tả hành vi ‘login’ theo mẫu đặc tả hành vi như sau


1.TÊN
login(String userName, String password)
2.NHIỆM VỤ
Xác nhận username và password của một người dùng có hợp lệ hay không để cho phép người sử dụng này thực hiện các chức năng của hệ thống quản trị điểm thi
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

,

  1. Để lại bình luận

Gửi phản hồi

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s

%d bloggers like this: