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 luôn 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) để phân biệt cán bộ thuộc loại nào trong cơ sở dữ liệu.
Trường hợp 2: Sử dụng ba bảng tương ứng cho ba lớp. Tuy nhiên, nhằm mô tả sự kế thừa trong các bảng GiảngViên và CánBộĐàoTạo chúng ta thêm vào tất cả các thuộc tính của bảng CánBộ cho mỗi bảng. Các thể hiện tương ứng của nhóm các đối tượng giảng viên hay các cán bộ đào tạo sẽ được lưu trong bảng tương ứng.
Trường hợp 3: Chỉ dùng hai bảng GiảngViên và CánBộĐàoTạo. Tuy nhiên, tất cả các thuộc tính của lớp CánBộ sẽ được đưa vào hai bảng này để thể hiện sự thừa kế. Nếu muốn truy xuất thơng tin về lớp CánBộ, ta có thể tạo một bảng hợp của hai bả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
iii. Triển khai hệ thống OCRS
Hệ thống OCRS là một ứng dụng Web chạy trên môi trường Internet và đặc thù của hệ thống này được thiết kế cho phép các đối tượng khác nhau có thể sử dụng các chức năng khác nhau với những cấp độ bảo mật khác nhau. Chính vì những lý do đó vấn đề bảo mật cho hệ thống được nhóm phát triển rất quan tâm ngay trong giai đoạn phân tích và thiết kế kiến trúc hệ thống.
Hiện nay, trong môi trường công nghệ thông tin của Việt Nam các ngơn ngữ lập trình Web được sử dụng rất đa dạng như PHP, JSP, ASP,… các ngôn ngữ được nêu ở trên là những ngôn ngữ được sử dụng phổ biến nhất trong các ứng dụng Web hiện nay. Mỗi ngơn ngữ đều có những mặt mạnh và mặt yếu riêng, tuy nhiên chúng em quyết định chọn ngơn ngữ ASP.Net
2.0 của Microsoft vì những tính năng linh hoạt trong việc xử lý dữ liệu thơng qua mơ hình
ADO.Net cũng như khả năng bảo mật cho ứng dụng khá cao dựa trên nền .Net Framework
2.0. Và sơ đồ sau sẽ minh họa cho điều này.
Hình IV.45: Sơ đồ triển khai của hệ thống OCRS
iv. Giải thuật và độ phức tạp giải thuật
Như hiện tại trường ĐHBK đang áp dụng, nhà trường phát sổ tay sinh viên cho mỗi sinh viên vào đầu mỗi học kỳ, vẫn cho phép sinh viên chọn lớp học phần muốn đăng ký, nhưng trên hết vẫn là khuyến cáo sinh viên nên học theo đúng chương trình đào tạo cho mỗi ngành ở mỗi học kỳ. Sau khi đăng ký, sinh viên phải nộp lại kết quả đăng ký của mình cho phịng đào tạo, và các cán bộ đào tạo phải kiểm tra thật chính xác trên cơ sở kết quả học tập của sinh viên từ khi vô trường đến thời điểm xét, cũng như ba điều kiện của từng học phần, và nhiều những điều kiện khác.
Vì vậy, với những quy định của cơ chế đào tạo tín chỉ, một vấn đề vơ cùng quan trọng và