Ở kỳ trước "Tìm hiểu về Use Case Diagram trong UML" mình đã giải thích sơ qua về lý thuyết của Use Case Diagram. Trong kỳ này, chúng ta sẽ thực hành phân tích một số yêu cầu và vẽ thành một Use Case Diagram nho nhỏ nhé. Xây dựng Use Case DiagramBước 1: Thu thập kiến thức liên quan đến hệ thống sẽ xây dựngTrước hết, để phân tích hệ thống trên bạn phải có kiến thức về hệ thống thương mại điện tử, chúng ta có thể tìm hiểu thông qua các nguồn sau: – Xem qua các forum – Xem các hệ thống mẫu – Hỏi những người chuyên về lĩnh vực này Lưu ý: Bạn không thể thiết kế tốt được nếu bạn không có kiến thức về lĩnh vực của sản phẩm mà bạn sẽ xây dựng. Bước 2: Xác định các ActorBạn hãy trả lời cho câu hỏi “Ai sử dụng hệ thống này?” Xem xét Website chúng ta nhận thấy: – Những người chỉ vào để đọc bài viết. Những người này là Người xem (Guest). – Những người vào để đăng topic, bình luận,… v.v.. gọi là Thành viên (Member). Về phía quản trị forum, có những người sau đây tham gia vào hệ thống: – Mod: Quản lý các bài viết, đăng cảnh báo, xóa bài viết, tắt bình luận – S-mod: Quản lý các bài viết, đăng cảnh báo, xóa bài viết, tắt bình luận, đề cử Mod – Admin: Quản lý các bài viết, đăng cảnh báo, xóa bài viết, tắt bình luận, Tạo người dùng, Phân quyền, Ban người dùng, chỉ định Mod, S-mod Tiếp theo chúng ta trả lời câu hỏi “Hệ thống nào tương tác với hệ thống này?” Ví dụ chúng ta sử dụng Facebook, Gmail để thực hiện chức năng Login thì chúng ta sẽ có các Actor tương ứng tương tác với hệ thống Như vậy, chúng ta đã có các Actor của hệ thống gồm: Guest, Member, Mod, S-mod, Admin, Facebook, Google Bạn cần khảo sát và phân tích thêm cũng như hỏi trực tiếp khách hàng để xác định đầy đủ các Actor cho hệ thống. Bước 3: Xác định Use CaseBạn cần trả lời câu hỏi “Actor sử dụng chức năng gì trên hệ thống?”. Trước tiên, xem xét với Actor “Guest” trên trang bkc.vn để xem họ sử dụng chức năng nào? – Xem trang chủ – Xem bài viết – Tìm kiếm bài viết – Đăng ký tài khoản để trở thành Member – ....... Tiếp theo, xem xét Actor “Member” và nhận thấy họ sử dụng chức năng: – Đăng nhập – Bình luận – Đăng bài – ... Tương tự như vậy bạn xác định chức năng cho các Actor còn lại. Bước 4: Vẽ bản vẽ Use CaseTrước hết chúng ta xem xét và phân tích các chức năng của “Guest” chúng ta nhận thấy.Chức năng tìm kiếm bài viết sẽ bao gồm chức năng xem những bài viết đã tìm kiếm ấy. Tuy nhiên chức năng xem bài viết vẫn là một chức năng độc lập. Vì thế mình nối Association vào cả 2. Và đặt mối quan hệ Extend cho chúng. Đặt lại tên cho gọn và xác định các mối quan hệ của chúng, chúng ta có thể vẽ Use Case Diagram cho Actor này như sau:  Tiếp theo, chúng ta xem xét đến Actor "Member", Actor này có những chức năng tương tự với "Guest" nhưng họ có thể tạo bài viết, bình luận, trả lời một bình luận. Ta có thể vẽ như sau: Thay vì nối tất cả như thế sẽ rất rối mắt. "Member" có tất cả Use Case của "Guest", có thể xem "Member" là con của "Guest", vì thế ta có thể sử dụng quan hệ kế thừa. Chúng ta sẽ tối giản sơ đồ như ảnh dưới: Đỡ đau mắt hơn rồi đúng không nào? Tiếp tục xem xét các Actor còn lại, xem cả những hệ thống nào tương tác với phần mềm và xác định các mối quan hệ, thêm những Actor/ Use Case cần thiết hoặc bớt những thứ không liên quan, mở rộng System Boundary khi hết chỗ. Cuối cùng chúng ta có sơ đồ thế này: Kết luậnNhư vậy, chúng ta đã hoàn thành bản vẽ Use Case cho trang web CForum. Hy vọng, các bạn có thể hiểu và sử dụng bản vẽ này trong việc phân tích hệ thống một cách hiệu quả. Tips: Nếu phần mềm của bạn được xây dựng theo mô hình Agile/Scrum, các bạn đã có trong tay Use Story rồi thì việc chuyển chúng thành Use Case sẽ dễ như trở bàn tay. Trong quá trình triển khai xây dựng phần mềm ứng dụng thì giai đoạn phân tích và thiết kế hệ thống rất quan trọng, không thể thiếu được. Hiện nay đang tồn tại song song 2 phương pháp phân tích thiết kế hệ thống: Phân tích thiết kế theo hướng cấu trúc đã ra đời và được đưa vào áp dụng rất sớm, phổ biến rộng rãi bởi kết quả của việc thiết kế là Cơ sở dữ liệu quan hệ mà các quan hệ đã đạt được các chuẩn đặt ra và đã được hỗ trợ bởi các công cụ hữu hiệu phổ biến là các hệ quản trị CSDL quan hệ như: Foxpro, Access, My SQL, SQL Server, Oracle, …. để tạo và lưu trữ dữ liệu hiệu quả cao, đơn giản, nhanh chóng. Tuy nhiên việc phát triển, nâng cấp, mở rộng hệ thống sau này để đáp ứng phù hợp được nhu cầu thực tế thay đổi hàng ngày của người dùng là rất khó khăn bởi tính ràng buộc, toàn vẹn dữ liệu rất chặt chẽ của hệ thống. Phân tích thiết kế hệ thống theo hướng đối tượng với Ngôn ngữ mô hình hoá thống nhất UML (Unified Modeling Language) ra đời sau với sự hỗ trợ đắc lực của công cụ Rational Rose trong việc vẽ và chuyển đổi thành các biểu đồ thiết kế (biểu đồ ca sử dụng Use Case, biểu đồ cộng tác/tuần tự thực thi từng ca sử dụng, biểu đồ lớp thiết kế, …), kết quả của việc thiết kế cho ta các lớp đối tượng (tên lớp, thuộc tính, các thao tác xử lý đối tượng ngay trong lớp, mối quan hệ giữa các lớp) rất tốt có khả năng mở rộng thêm và sử dụng lại sau này mà không ảnh hưởng nhiều lắm đến hệ thống hiện tại đang hoạt động. Tuy nhiên việc lưu trữ dữ liệu cho các lớp là rất khó khăn bởi chưa có các công cụ chuẩn hữu hiệu như trong CSDL quan hệ để hỗ trợ cho việc tạo và lưu trữ dữ liệu. Bởi vậy cần một phương pháp để chuyển đổi được từ biểu đồ lớp trong UML sang mô hình EER (Enhaned Entity Relationship), sau đó chuyển đổi từ mô hình EER sang quan hệ để sử dụng các hệ quản trị CSDL quan hệ để lưu trữ dữ liệu thì hệ thống phân tích thiết kế được sẽ rất tốt hiện nay. 2. PHƯƠNG PHÁP CHUYỂN ĐỔI 2.1. Các thành phần trong UML tương ứng với EER (UML vs. EER Terminology) UML EER UML là ngôn ngữ mô hình hóa thống nhất chuẩn để thiết kế phần mềm hướng đối tượng EER được sử dụng trong mô hình thiết kế cơ sở dữ liệu quan hệ Các thành phần: Biểu đồ lớp trong UML (UML Class Diagram) Lớp (Class) Đối tượng (Object) Thuộc tính (Attribute) Miền giá trị (Domain) Miền cấu trúc (Structured Domain) Thao tác (Operation) Kết hợp (Association) Liên kết (Link) Bản số (Multiplicities) Kết tập (Aggregation) Mô hình EER (EER Diagram) Kiểu thực thể (Entity Type) Thực thể (Entity) Thuộc tính (Attribute) Miền giá trị (Domain) Thuộc tính phức hợp (Composite Attribute) - ~ [Derived Attribute] Kiểu liên kết (Relationship Type) Thể liên kết (Relationship Instance) Tỷ số lực lượng (Cardinality & Participation) Thực thể yếu (Weak entities) Các kí hiệu: - UML hiển thị lớp bằng hình chữ nhật có 3 phần: ü Phần trên cùng: Tên lớp ü Phần giữa: Thuộc tính ü Phần dưới cùng: Thao tác - Kiểu thực thể hiển thị bởi hình chữ nhật ü Tên kiểu thực thể ü Thuộc tính được hiển thị bởi hình elip ü Các thao tác không được hỗ trợ trong mô hình EER Thuộc tính: - Thuộc tính phức hợp được mô hình hóa bởi sự lùi vào ở đầu dòng. - Miền giá trị gán cùng với thuộc tính - Thuộc tính phức hợp được mô hình hóa bởi các hình elip. - Miền giá trị được chỉ rõ riêng rẽ Các mối quan hệ: - Trong UML gọi là các mối quan hệ giữa các lớp. - Lực lượng tham gia vào liên hệ gọi là bản số. Bản số được ghi ở phía đầu đường thẳng thể hiện liên hệ, sát vào lớp là miền áp dụng của nó. Phạm vi số lượng phẩn tử có thể có trong liên hệ. - Trong EER gọi là các mối quan hệ giữa các thực thể. - Tỷ số lực lượng cực đại, cực tiểu tham gia vào liên kết. Bản số và lực lượng: 0..* 1 hoặc 1..1 0,N 1,1 Thuộc tính riêng của quan hệ: Thuộc tính riêng của liên hệ giữa các lớp đối tượng. Thuộc tính riêng của kiểu liên kết giữa các thực thể 2.2. Các bước chuyển đổi Bước 1: Mỗi lớp trong biểu đồ lớp ta tạo ra 1 kiểu thực thể tương ứng. Các thuộc tính của lớp được chuyển thành các thuộc tính của kiểu thực thể. Thuộc tính định danh sử dụng để làm thuộc tính khoá. Bước 2: Quan hệ kết hợp một hay hai chiều được chuyển đổi thành các quan hệ. Tuỳ thuộc vào cơ số của quan hệ kết hợp mà quan hệ tương ứng trong quan hệ thực thể là “1-1”, “1-n”, “n-m”. Bước 3: Quan hệ kết hợp có lớp kết hợp: Lớp kết hợp được chuyển thành mối quan hệ giữa các kiểu thực thể. Thuộc tính của lớp kết hợp chuyển thành các thuộc tính của mối quan hệ. Bước 4: Quan hệ kết tập: Quan hệ kết tập được chuyển thành mối quan hệ “1-n” giữa 2 kiểu thực thể Bước 5: Quan hệ tổng quát hoá: Quan hệ tổng quát hoá giữa 2 lớp thì được chuyển thành quan hệ chuyên biệt hoá giữa 2 kiểu thực thể biểu diễn lớp cha và lớp con. 3. ỨNG DỤNG 3.1. Bài toán Trường Đại học Dân lập Hải Phòng chuyển sang hình thức đào tạo theo chế tín chỉ từ năm 2008, với hình thức đào tạo này sinh viên khi mới nhập trường sẽ được sắp xếp vào các lớp niên chế ban đầu để sinh hoạt quản lý trong toàn khóa học. Trước khi bắt đầu học kỳ mới của năm học (khoảng 1 tháng) dựa vào danh sách các môn học chung và riêng của các ngành đào tạo trong chương trình đào tạo của từng ngành đã được xây dựng, phê duyệt, áp dụng để tạo lập ra các lớp môn học cụ thể cho từng môn học kèm theo thông tin giảng viên được phân công giảng dạy lớp môn học đó, sau đó chuyển cho sinh viên đăng ký học (sinh viên đăng ký học qua mạng Internet, được quyền chủ động lựa chọn đăng ký môn học trong kỳ và giảng viên giảng dạy với sự trợ giúp của cố vấn học tập), hết thời hạn đăng ký học, nếu lớp môn học nào có số sinh viên đăng ký học quá ít không đủ số lượng tối thiểu để mở lớp thì sẽ bị hủy lớp. Giảng viên của trường tham gia giảng dạy bao gồm đội ngũ giảng viên cơ hữu và giảng viên thỉnh giảng. Giảng viên cơ hữu được ký hợp đồng với nhà trường, được hưởng các quyền lợi theo chế độ quy định và phải thực hiện các khối lượng công việc được quy định trong 1 năm (bao gồm: số tiết phải giảng dạy, số giờ phải tham gia nghiên cứu khoa học, số giờ phải tự học tập bồi dưỡng, số giờ sinh hoạt hội họp chuyên môn) tương ứng với từng hệ số lương đang được hưởng. Giảng viên thỉnh giảng tham gia giảng dạy bao gồm giảng viên tại Hải Phòng và ở Hà Nội, các giảng viên khi tham gia giảng dạy lớp môn học nào kết thúc xong sẽ được thanh toán ngay theo giá biểu qui định tương ứng với từng học vị, học hàm của giảng viên và thêm hệ số thu hút. Riêng giảng viên ở Hà Nội sẽ được tính thêm phụ cấp đi lại và hệ số xa nhà. 3.2. Biểu đồ lớp thiết kế 3.3. Mô hình EER chuyển đổi từ biểu đồ lớp thiết kế (áp dụng thuật toán chuyển đổi) 4. KẾT LUẬN
|
