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

Đồ á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 (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ốngQuản lý điểm thiTÀI LIỆU ĐẶC TẢ YÊU CẦUPHIÊN BẢN 1.0 TABLE OF CONTENTS1GIỚI THIỆU1.1Mục đích1.2Phạm vi dự án1.3Định nghĩa, viết tắt1.4Tài liệu tham khảo2MÔ TẢ TỔNG THỂ2.1Mô hình hệ thống2.2Các chức năng của hệ thống2.3Người sử dụng3CÁC TÍNH NĂNG CỦA HỆ THỐNG3.1Quản trị3.2Xem thông tin4CÁC YÊU CẦU GIAO TIẾP4.1Giao diện người sử dụng4.2Giao tiếp phần cứng4.3Giao tiếp phần mềm4.4Giao tiếp truyền thông tin5CÁC YÊU CẦU PHI CHỨC NĂNG5.1Yêu cầu thực thi5.2Yêu cầu an toàn5.3Yêu cầu bảo mật5.4Yêu cầu chất lượng phần mềm5.5Yêu cầu môi trường hoạt động5.6Yêu cầu tài liệu người sử dụng6PHỤC LỤC 1GIỚI THIỆU1.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ọc1.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 quanChỉ 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 conNế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àoCó 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ệuNộ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ơn2.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ốngXá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ụngPhâ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ốngMô tả tóm tắt tính năng và mức độ ưu tiên là cao, trung bình hay thấpLiệ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àyLiệ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óa3.1.2Quản lý lớp3.1.3Quản lý sinh viên3.1.4Quản lý môn học3.1.5Quản lý điểm3.2Xem thông tin3.2.1Xem thông tin khóa3.2.2Xem thông tin lớp3.2.3Xem thông tin điểm4CÁC YÊU CẦU GIAO TIẾP4.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ĂNG5.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ợpPhâ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ỤCCá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Ề UMLUnified 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 UMLTrong 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 · 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ânTừ 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ẮTMô tả tóm tắt về Use Case đang xét2.TÁC NHÂNDanh sách các tác nhân tác động lên Use Case đang xét3.LIÊN QUANDanh sách các Use Case, các chức năng liên quan đến Use Case đang xét4.CÁC LUỒNG SỰ KIỆN 4.1.Luồng sự kiện chínhMô tả luồng sự kiện chính của Use Case đang xét4.2.Luồng sự kiện rẽ nhánhMô 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ẮTLogin 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ống2.TÁC NHÂNTá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 QUANKhông có Use Case liên quan4.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 Case4.2.Luồng sự kiện rẽ nhánhLuồ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 CaseLuồ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 CaseLuồ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ả  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+ n