Phân tích thiết kế hệ thống
Như đã nói trên, dưới đây sẽ trình bày các sơ đồ mịn dần của sơ đồ lớp này.
Hình IV.12: Sơ đồ chức năng XemLịchDạy [Mức 2]
Hình IV.13: Sơ đồ chức năng XemThơngTinCáNhân [Mức 2]
Phân tích thiết kế hệ thống
Hình IV.15: Sơ đồ chức năng ThayĐổiPassword [Mức 2]
Giảng viên tương tác với hệ thống thơng qua ba chức năng này, trong đó mỗi chức năng chỉ mang tính truy xuất dữ liệu mà khơng được phép thao tác thay đổi dữ liệu, vì vậy ta sẽ không phân rã nhỏ hơn nữa các chức năng đó của giảng viên.
c. Sơ đồ lớp của nhóm đối tượng giáo vụ khoa
Hình IV.16: Sơ đồ lớp của actor GiáoVụKhoa [Mức 1]
Như đã nói trên, dưới đây sẽ trình bày các sơ đồ mịn dần của sơ đồ lớp này.
Phân tích thiết kế hệ thống
Hình IV.18: Sơ đồ chức năng ThayĐổiPassword [Mức 2]
Hình IV.19: Sơ đồ chức năng XemBáoCáoThốngKê [Mức 2]
Hình IV.20: Sơ đồ chức năng XemThơngTinCáNhân [Mức 2]
Phân tích thiết kế hệ thống
Hình IV.21: Sơ đồ lớp của actor CánBộĐàoTạo [Mức 1]
Trong sơ đồ trên, chúng em sử dụng khn mẫu hiển thị dưới dạng icon với hình vịng trịn có bánh răng quay biểu diễn trang server với ý nghĩa cán bộ đào tạo là đối tượng quản lý tồn bộ q trình đào tạo theo học chế tín chỉ và có khả năng thao tác chính với dữ liệu. Sau đây là các sơ đồ mịn dần của sơ đồ lớp này.
Hình IV.22: Sơ đồ chức năng GiớiHạnĐăngKý [Mức 2]
Phân tích thiết kế hệ thống
Hình IV.24: Sơ đồ chức năng ThayĐổiPassword [Mức 2]
Hình IV.25: Sơ đồ chức năng TạoDữLiệu [Mức 2]
Sơ đồ trên cho biết cán bộ đào tạo có quyền tạo mới các tài khoản sinh viên và giảng viên cả trường cũng như tạo mới các tài khoản về phòng học, học phần, lớp học.
Phân tích thiết kế hệ thống
Hình IV.26: Sơ đồ chức năng Xóa/KhóaDữLiệu [Mức2]
Sơ đồ trên cho biết cán bộ đào tạo có quyền khóa các tài khoản sinh viên và giảng viên cả trường cũng như xóa các tài khoản về phịng học, học phần, lớp học.
Hình IV.27: Sơ đồ chức năng XemThôngTin [Mức 2]
Sơ đồ trên cho biết cán bộ đào tạo có quyền xem thơng tin chi tiết của từng sinh viên và giảng viên trong trường cũng như xem thơng tin cá nhân của chính cán bộ đào tạo và thông tin về các tài khoản về phòng học, học phần, lớp học.
Phân tích thiết kế hệ thống
Hình IV.28: Sơ đồ chức năng CậpNhậtThơngTin [Mức 2]
Sơ đồ trên cho biết cán bộ đào tạo có quyền chỉnh sửa thơng tin các tài khoản sinh viên và giảng viên cả trường cũng như chỉnh sửa thông tin các tài khoản về phịng học, học phần, lớp học.
Hình IV.29: Sơ đồ chức năng CậpNhậtĐiểm [Mức 2]
Phân tích thiết kế hệ thống
Hình IV.30: Sơ đồ lớp của actor QuảnTrịHệThống [Mức 1]
Hình IV.31: Sơ đồ lớp chức năng ThayĐổiPassword [Mức 2]
Hình IV.32: Sơ đồ lớp chức năng XemThôngTinCáNhân [Mức 2] II. Mơ hình hóa hành vi
Hành vi là cách hành động, ứng xử của một hệ thống. Mơ hình hóa hành vi đối với hệ thống là sự diễn tả khía cạnh động của hệ thống, đối lập với mơ hình hóa cấu trúc là sự diễn tả khía cạnh tĩnh của hệ thống.
Chúng ta đã biết, use-case được dùng để mơ hình hóa các chức năng trong hệ thống và xác định cách thức các tác nhân tương tác với hệ thống và mơ hình hóa cấu trúc tĩnh của hệ thống cho phép chúng ta thâm nhập vào bên trong hệ thống đồng thời chỉ ra các đối tượng, các lớp tham gia vào các use-case đó. Tuy nhiên, nếu chỉ dừng lại ở đó chúng ta sẽ khơng thấy được hoạt động của các lớp, mà cụ thể là của các đối tượng của lớp. Vì vậy, trong phần này chúng ta cần mơ hình hóa hệ thống ở mức tương tác thơng qua các sơ đồ hoạt động và sơ đồ tuần tự.
Sơ đồ hoạt động trong mơ hình đối tượng minh họa luồng cơng việc của một hiện thực hóa use-case nghiệp vụ, nó cho biết việc sắp xếp các cơng việc theo một thứ tự nhằm đạt được các mục tiêu của nghiệp vụ. Một hoạt động trong sơ đồ hoạt động có thể là một cơng việc thủ cơng hoặc tự động hóa để hồn thành một đơn vị cơng việc. So với sơ đồ tuần tự có cùng mục đích thì sơ đồ hoạt động tập trung mơ tả cách thức phân chia trách nhiệm thành các lớp, trong khi đó, sơ đồ tuần tự lại mơ tả cách thức các đối tượng tương tác theo trình tự. Sơ đồ hoạt động tập trung vào luồng công việc trong khi sơ đồ tuần tự tập trung vào việc xử lý các thực thể. Chúng bổ sung cho nhau, và lý giải cho mục đích sử dụng hai loại sơ đồ này khi mơ hình hóa hành vi hệ thống.
Về mặt bản chất, sơ đồ cộng tác và sơ đồ tuần tự là như nhau, chúng chỉ khác nhau ở mục đích truyền đạt thơng điệp cần diễn tả cho người đọc, tức là sơ đồ trình tự mơ tả rõ ràng trình tự các sự kiện và nó được sử dụng thích hợp khi use-case phức tạp, cịn sơ đồ cộng tác trình bày các mối liên kết giao tiếp cùng những thông điệp giữa các đối tượng và nó giúp người đọc
Phân tích thiết kế hệ thống
hiểu được tất cả các tác động trên một đối tượng. Và người ta đã đưa ra một khuyến cáo rằng, không nên dùng cả hai sơ đồ này đồng thời để diễn tả cùng một tương tác.
Phân tích thiết kế hệ thống
Phân tích thiết kế hệ thống
Hình IV.34: Sơ đồ hoạt động tổ chức lớp học phần đề nghị của cán bộ đào tạo
Ở đây chúng em chỉ mơ hình hóa hai q trình, đó là q trình đăng ký học phần của sinh viên và việc xem xét các học phần đề nghị từ kết quả đăng ký của sinh viên để tổ chức các lớp học phần mới không thuộc kế hoạch giảng dạy dự kiến của nhà trường nói chung cũng như của phịng đào tạo nói riêng, nhằm nhấn mạnh chức năng chính của chương trình ứng dụng này. Hơn nữa, đây là hai q trình địi hỏi độ phức tạp cao khi sinh viên muốn đăng ký học
Phân tích thiết kế hệ thống
phần và việc tổ chức thêm các lớp học phần được bắt nguồn từ đâu, được tiến hành như thế nào cũng rất quan trọng.
Phân tích thiết kế hệ thống
Phân tích thiết kế hệ thống
Hình IV.36: Sơ đồ trình tự biểu diễn quá trình hủy các học phần đã đăng ký
Như đã phân tích ở trên, khơng chỉ cho phép đăng ký học phần, hệ thống còn cho phép sinh viên có thể hủy những học phần đã đăng ký sau khi đã đăng ký học phần hoặc cũng có thể ngay trong lần sinh viên đang đăng ký học phần. Xét về hoạt động, thì sinh viên chỉ cần hủy chọn lớp học phần đã đăng ký, tuy nhiên quá trình này sẽ rõ ràng hơn rất nhiều khi được mơ hình qua sơ đồ trình tự trên.
III. Xác định mối quan hệ giữa các lớp
Trong môi trường hướng đối tượng, đối tượng đảm nhiệm vai trò chủ động trong một hệ thống. Đối tượng không tồn tại một cách độc lập mà luôn tương tác với những đối tượng khác, sự tương tác này thể hiện thông qua mối kết hợp gồm cả những hoạt động và hành vi của đối tượng.
Từ tập các lớp ứng viên thu được sau quá trình xây dựng lớp cùng với q trình phân tích các hành vi và sự tương tác giữa các đối tượng trong những phần trên, chúng ta đã xác đinh được một số mối quan hệ giữa các lớp. Tuy nhiên các mối quan hệ này vẫn chưa tối ưu và rời rạc, vì vậy việc cần thiết xây dựng một sơ đồ lớp tổng quan với đầy đủ các quan hệ giữa những lớp chính của ứng dụng là hết sức cần thiết.
Với ứng dụng OCRS các đối tượng người dùng giảng viên, giáo vụ khoa, cán bộ đào tạo và quản trị hệ thống về bản chất đều là cán bộ cơng nhân viên của trường và đều có những thông tin lưu trữ giống nhau, mỗi đối tượng chỉ khác nhau về mặt chức năng sử dụng. Đó là nguyên nhân để ta xây dựng một lớp khái quát đại diện cho các đối tượng đã nêu ở trên, mỗi
Phân tích thiết kế hệ thống
đối tượng sẽ kế thừa những thuộc tính và phương thức chung từ lớp khái quát này. Dưới đây là sơ đồ lớp tổng thể hệ thống OCRS.
Phân tích thiết kế hệ thống
Phân tích thiết kế hệ thống
IV. Thiết kế hệ thống
1. Thiết kế lớp
Mục tiêu chính của giai đoạn phân tích là tập trung vào xác định những gì cần được thực hiện. Các đối tượng được phát hiện trong giai đoạn phân tích sẽ làm cơ sở cho giai đoạn thiết kế. Các thuộc tính, phương thức và mối liên kết của lớp được xác định trong giai đoạn phân tích, và được bổ sung từ các mơ hình biểu diễn tương tác giữa các đối tượng, phải được thiết kế cho việc cài đặt như là một thành phần được mô tả theo ngôn ngữ cài đặt.
Trong phần này, chúng ta tập trung chi tiết hóa hướng nhìn logic bằng cách xác định thêm các lớp chi tiết ở cả tầng giao diện và tầng truy cập cơ sở dữ liệu để từ đó hình thành một sơ đồ lớp hồn chỉnh mơ tả đầy đủ các đối tượng của ứng dụng chuẩn bị cho việc cài đặt.
Ngoài ra, dựa trên các kết quả này chúng ta phát triển thiết kế vật lý hệ thống bằng cách xây dựng thêm các hướng nhìn cài đặt và hướng nhìn triển khai nhằm chuyển giao kết quả thiết kế hệ thống gần với một ngơn ngữ và cơng cụ lập trình xác định cho giai đoạn lập trình để có thể cài đặt phù hợp với các thiết bị tài nguyên trong một môi trường hệ thống thực tế một cách hiệu quả nhất.
Hầu hết các hệ thống được phát triển có xu hướng xây dựng một kiến trúc hai tầng đó là giao diện và dữ liệu. Trong kiến trúc hai tầng đó các màn hình giao diện người dùng liên kết để truy cập dữ liệu thông qua các đoạn chương trình được cài trực tiếp trên các đoạn giao diện. Ví dụ: một chương trình viết trên nền Visual Basic có một form giao diện, một thủ tục xử lý sự kiện trong nút “Cập nhật” của form này có tên cmd_CapNhat_Click() có thể thực hiện ln việc truy cập và cập nhật cơ sở dữ liệu trực tiếp, như vậy thủ tục này cài đặt luôn các ngữ nghĩa về tác nghiệp. Việc thiết kế theo mơ hình này tạo ra một sự phụ thuộc rất lớn giữa giao diện và cơ sở dữ liệu, do đó rất khó cải tiến bảo trì và khó sử dụng.
Một cách tiếp cận kiến trúc khác tốt hơn chính là tạo ra sự độc lập giữa giao diện và người sử dụng bằng cách cô lập các chức năng của lớp giao diện với các chức năng của lớp tác nghiệp, của lớp tác nghiệp với lớp truy cập cơ sở dữ liệu. Đó chính là cách tiếp cận ba lớp, từ cách tiếp cận này cho phép chúng ta tạo ra được các đối tượng đại diện cho các đối tượng hữu hình trong thực tế nhưng hoàn toàn độc lập với cách thức mà các đối tượng này trình bày tới người dùng cũng như cách mà dữ liệu của nó được lưu trữ trong cơ sở dữ liệu.
Một chương trình sẽ tạo ra một số dữ liệu trong quá trình thực thi. Mỗi dữ liệu sẽ có một thời gian sống khác nhau. Dữ liệu tạm thời (Transient Data) có thời gian sống phụ thuộc vào thời gian sống của tiến trình sử dụng nó và được giải phóng khi tiến trình như các biến trong một quá trình thực thi thủ tục, kết quả tạm thời để đánh giá biểu thức, biến toàn cục và biến cấp phát động. Dữ liệu liên tục (Persistent Data) có thời gian tồn tại lâu hơn và độc lập với tiến trình sử dụng nó, chúng được quản lý bởi hệ quản trị cơ sở dữ liệu hay hệ thống lưu trữ tập tin. Đa số các lớp trong ứng dụng được chúng em thiết kế là lớp Persistent.
Để phát huy hướng đối tượng ở mức cao nhất, người ta khuyến cáo tất cả các thuộc tính nên được gán cho một phạm vi truy cập nội bộ dạng Protected nhằm đảm bảo tính bao bọc và có thể thừa kế nếu sau này cần phát triển thêm các lớp con. Các phương thức thì nên được truy cập tồn cục như chính bản chất sử dụng phương thức, ngoại trừ một số phương thức chỉ được sử dụng trong nội bộ lớp đó hoặc lớp con kế thừa. Trong Rational Rose quy ước về các phạm vi truy cập như sau:
Phân tích thiết kế hệ thống
Phân tích thiết kế hệ thống
Phân tích thiết kế hệ thống
Phân tích thiết kế hệ thống
Phân tích thiết kế hệ thống
Phân tích thiết kế hệ thống
Phân tích thiết kế hệ thống
ii. Chuyển đổi đối tượng sang mơ hình quan hệ
Trong cơ sở dữ liệu quan hệ, một lược đồ được hình thành bởi các bảng gồm các cột và dịng. Trong mơ hình hướng đối tượng, tương ứng tới một bảng là một lớp hoặc nhiều lớp. Các thành phần tương ứng như sau:
Một cột ứng với một thuộc tính của lớp.
Một dịng của bảng ứng với một đối tượng.
Một thủ tục lưu trữ nội, hay còn gọi là Store Procedure, có thể tương ứng với một phương thức.
Như vậy, việc chuyển đổi sơ đồ lớp sang lược đồ quan hệ gồm những công việc sau:
Chuyển đổi lớp – bảng.
Chuyển đổi mối liên kết bao gồm liên kết kết hợp và liên kết kế thừa.
a. Chuyển đổi lớp – bảng
Trong đa số các trường hợp thì việc chuyển đổi này là một - một, một lớp sẽ chuyển thành một bảng cụ thể như sau:
Một lớp thành một bảng.
Một thuộc tính (persistent) thành một cột: chỉ có các thuộc tính có nhu cầu cần lưu trữ và được đòi hỏi bởi ứng dụng sẽ được chuyển thành cột của bảng.
Một đối tượng (thể hiện) thành một dòng.
b. Chuyển đổi mối liên kết
Chuyển đổi liên kết kết hợp
Trường hợp 1: Trong chuyển đổi mối kết hợp một – một, chúng ta có thể lấy cột khóa chính trong một bảng chuyển qua bảng khác làm khóa ngoại.
Trường hợp 2: Trong chuyển đổi một kết hợp dạng một - nhiều, chúng ta lấy cột khóa chính ứng với lớp phía một trong mối kết hợp đưa vào bảng ứng với lớp phía nhiều làm khóa ngoại.
Trường hợp 3 : Trong chuyển đổi mối kết hợp nhiều – nhiều, chúng ta tạo ra một bảng cho mối kết hợp đó bằng cách lấy các khóa chính của các bảng đưa vào bảng mới này như là khóa ngoại.
Chuyển đổi liên kết kế thừa
Trong lược đồ quan hệ khơng có khái niệm kế thừa mà chúng ta thường dùng liên kết khóa chính – khóa ngoại để diễn đạt điều này. Ví dụ, ta có lớp CánBộ có các thuộc tính (canboid, hoten, ngaysinh) và hai lớp GiảngViên có thuộc (canboid, thuockhoa), CánBộĐàoTạo có thuộc tính (canboid) kế thừa từ lớp CánBộ, với kiểu liên kết này ta có thể chuyển đổi sau:
Trường hợp 1: Chỉ sử dụng một bảng lưu trữ tất cả các loại cán bộ. Do đó, các thuộc tính của bảng được hình thành từ các thuộc tính của lớp CánBộ, GiảngViên, CánBộĐàoTạo. Ngoài ra chúng ta cũng đưa vào thêm một thuộc tính (loaicanbo) để