Đồ á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

ĐẶ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 (specification requirement system - SRS) được xem như là một bản hợp đồng giữa khách hàng và nhóm phát triển về các yêu cầu của hệ thống

Quản lý điểm thi
TÀI LIỆU ĐẶC TẢ YÊU CẦU
PHIÊN BẢN 1.0

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.

Đâ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
2.2Các chức năng của hệ thống

Tóm tắt các chức năng chính, các chức năng quan trọng của sản phẩm. Ở đây chỉ tóm tắt ở mức cao nhất để người đọc của thể hiểu được tổ chức các chức năng của sản phẩm: sử dụng các hình ảnh, biểu đồ, …

Có 2 chức năng chính: chức năng quản trị và chức năng của người sử dụng bình thường

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

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

Các yêu cầu về chất lượng của sản phẩm: tính đúng, tính khoa học, tính tin cậy, tính thích nghi,..

5.5Yêu cầu môi trường hoạt động

Môi trường mà hệ thống sẽ vận hành: phần cứng, hệ điều hành,…

5.6Yêu cầu tài liệu 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.
  - 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ì
• UML là một cách phân tích và thiết kế mô hình theo hướng đối tượng
  •Hiểu theo cách thông thường, UML bao gồm các mô hình đặc trưng cho việc phân tích và thiết kế
• 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 đế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

3.1.Xây dựng các biểu đồ cộng tác

Phần xây dựng biều đồ cộng tác có thể hoặc không cần thiết tùy theo từng bài toán cụ thể, với biểu đồ tuần tự ta sẽ thấy được các luồng hoạt động của hệ thống theo thời gian, còn với biểu đồ cộng tác ta sẽ thấy được các luồng hoạt động theo không gian, qua biểu đồ tuần tự và cộng tác ta sẽ có thêm các lớp mới cùng với việc xác định các phương thức của các lớp

Các bước xây dựng biểu đồ cộng tác

Ta xây dựng biểu đồ cộng tác cho UC Đăng nhập:

Ở đây ta thấy xuất hiện thêm các lớp (có thể phát hiện từ biểu đồ tuần tự): GUI, Controller, Process cho phần Login cùng các phương thức của chúng(ta sẽ phát hiện trong phần thiết kế lớp)

Tiếp tục demo với UC Nhập điểm thi

Tiếp tục với các UC khác

Tip: Từ 1 biểu đồ tuần tự của một UC ta có thể nhấn F5 để sinh ra một biểu đồ cộng tác của cùng UC đó

3.2.Xây dựng biểu đồ lớp chi tiết:
Từ các lớp ứng cử viên, chúng ta sẽ phát triển tiếp thành các lớp chi tiết

Tip: trong giai đoạn này chúng ta sẽ quan tâm đến các kiến thức về Design Patterns (các mẫu thiết kế), cái này hay thiệt, có khi còn phải nói là tuyệt thiệt

3.3.Xây dựng biểu đồ thành phần (conponent):
Ta bước sang giai đoạn cài đặt của hệ thống, trong giai đoạn này có 2 loại biểu đồ để mô tả việc cài đặt hệ thống: Biểu đồ thành phần và biểu đồ triển khai
- Biểu đồ thành phần: cho ta mối quan hệ giữa các thành phần trong hệ thống, thông thường là mối quan hệ giữa các file nguồn, giữa các phần mềm đang chạy hoặc giữa file nguồn với các file thi hành tương ứng
- Biểu đồ triển khai: thường được dùng để mô hình các phần cứng của hệ thống

Bắt đầu xây dựng biểu đồ thành phần, ta sẽ xây dựng các gói tương ứng cho các thành phần, sau đó là tạo các thành phần trong từng gói…

Sau khi tạo component, ta sẽ “kéo” lớp tương ứng vào đặc tả của component đó
Lưu ý: Tên component phải trùng với tên lớp

Ở giai đoạn biểu đồ component ta có thể sinh ra code cho hệ thống, ở giai đoạn trước, khi chọn language cho lớp trong phần xây dựng biểu đồ lớp chi tiết, ta chọn ngôn ngữ nào thì Ration Rose sẽ sinh code theo ngôn ngữ đó, ở bài này ta dùng Java






3.3.Thiết kế Cơ sở dữ liệu:
UML là một ngôn ngữ mô hình hướng đối tượng, do đó việc phân tích CSDL quan hệ không được đề cập đến trong phương pháp này, ở đây ta sẽ thiết kế cơ sở dữ liệu của hệ thống theo các kiến thức về CSDL quan hệ, bên dưới chỉ là các bước tại ra CSDL bằng Ration Rose chứ không giới thiệu phương pháp CSDL quan hệ






Tạo Database cho hệ thống, ở đây ta chọn Ms SQL server 2000

Tạo biểu đồ CSDL và các bảng dữ liệu

Tạo các Store procedure

Sinh ra các đoạn mã tạo CSDL, lưu trong các file dll hoặc sql

3.3.Thiết kế giao diện người sử dụng:

Đây là một phần khá quan trọng, phần này có thể thực hiện sau khi đã có phần phân tích hệ thống, ở phần này ta sẽ thiết kế các giao diện cho từng chức năng của hệ thống, mô tả chi tiết: các control, font chữ, màu sắc…

Đến đây với các phần code sinh ra cùng các thiết kế hệ thống ta đã có thể kết thúc giai đoạn phân và thiết kế hệ thống, chuyển tiếp sang giai đoạn Implement hệ thống