Ứng dụng được xây dựng là một ứng dụng hỗ trợ công việc rút trích thông tin từ các trang web Nn với nội dung động theo từng chủ đề riêng biệt. Các thông tin sau khi rút trích có thể được hiển thị cho người dùng một cách phù hợp. Mục đích chính đề tài là các mẫu thiết kế để xây dựng bộ khung cho ứng dụng này.
Các chức năng chính của ứng dụng:
• Rút trích thông tin từ các trang web Nn theo chủ đề.
• Hỗ trợ nhà phát triển quản lý các thông tin về chủ đề, trang web một cách dễ dàng.
Minh họa ứng dụng:
• Tôi minh họa rút trích thông tin ở 3 chủ đề chính là: Job, Paper, Mobiphone. • Áp dụng 2 thuật toán rút trích thông tin: dựa trên XPath (cấu hình bằng tay)
và dựa trên dự giống nhau về cấu trúc trang (heuristic). Mỗi thuật toán áp dụng chung cho các trang web thuộc chủ đề.
• Hỗ trợ 2 component cơ bản của thuộc tính là text và select khi phát sinh giao diện các thuộc tính tự động khi nguời dùng chọn chủ đề cần rút trích.
4.2 Kiến trúc ứng dụng hỗ trợ rút trích thông tin từ web jn theo chủ đề 4.2.1 Quá trình sử dụng ứng dụng rút trích thông tin từ web jn
Đối với người sử dụng: N gười sử dụng có thể yêu cầu rút trích thông tin theo chủ đề chọn lựa. Hình 4-1 là biểu đồ hoạt động khi người sử dụng dùng hệ thống. Trước hết, người sử dụng phải xác định chủ đề cần rút trích thông tin và các yêu cầu thông qua các thuộc tính chung thuộc chủ đề đó. Hệ thống sẽ xây dựng các
câu truy vấn sao cho phù hợp với từng trang web Nn, cụ thể ở đây là các trang tìm kiếm ứng với từng chủ đề và gửi yêu cầu. Thành phần thu thập trang web chịu trách nhiệm nhận kết quả trả về và áp dụng thuật toán để rút trích thông tin. Tất cả các kết quả được hiển thị cho người dùng một cách phù hợp.
Đối với nhà phát triển: nhà phát triển có thể
• Quản lý chủ đề và các giá trị thuộc tính chung của chủ đề.
• Hỗ trợ phân tích trang web Nn, quản lý các trang web Nn thuộc chủ đề và giá trị các thuộc tính của trang web Nn đó.
• Hỗ trợ nhà phát triển map thuộc tính và giá trị của chủ đề với tên biến và giá trị của trang web.
4.2.2 Kiến trúc hệ thống
Controller Thành phần hỗ trợ Model
Thông tin cấu hình Lưu trữ
web
Thành phần điều hướng xử lý
các yêu cầu Thành phần quản lý chủ đề
<<sử dụng>> <<sử dụng>> <<sử dụng>> <<mẫu thiết kế>> Dynamic Factory <<mẫu thiết kế>> Abstract Factory <<mẫu thiết kế>> Strategy View Thành phần giao diện Thành phần lõi Thành phần rút trích thông tin theo chủ đề Thành phần cài đặt các thuật toán rút trích thông tin từ web
<<sử dụng>>
<<mẫu thiết kế>> Data access object
patterns Thành phần xử lý dữ liệu
Hình 4-2 : Kiến trúc hệ thống hỗ trợ rút trích thông tin từ web jn theo chủ đề Mô tả các thành phần:
Ứng dụng được thiết kế theo mô hình MVC (được trình bày ở mục 4.3.1), bao gồm 3 thành phần chính là Model, View và Controller. Hình 4-5 biểu diễn các thành phần con bên trong 3 thành phần chính và các mẫu thiết kế được áp dụng cho các thành phần đó. Mô tả chi tiết các thành phần con như sau:
• Thông tin cấu hình: được lưu trữ trong tệp tin XML. Thông tin cấu hình này lưu trữ yêu cầu và lớp xử lý yêu cầu đó.
• Thành phần điều hướng xử lý các yêu cầu: là một controller tiếp nhận tất cả các yêu cầu. Kết hợp với thông tin cấu hình cho phép điều hướng đến các lớp xử lý yêu cầu. Trong thành phần này, có thể áp dụng mẫu thiết kế Factory method của GoF để khởi tạo các đối tượng. Đây là mẫu cơ sở để cải tiến thành mẫu Dynamic Factory mà chúng tôi áp dụng để có thể khởi tạo đối tượng động.
• Thành phần thu thập nội dung từ trang web jn theo chủ đề: nhiệm vụ của thành phần này là xây dựng câu truy vấn đến các trang web Nn phù hợp, gửi yêu cầu đến các trang web đó và nhận kết quả trả về. Trong thành phần này, chúng tôi áp dụng mẫu thiết kế Abstract Factory để tạo một nhóm các “sản phNm” cho chủ đề.
• Thành phần cài đặt các thuật toán rút trích thông tin: Chúng tôi áp dụng mẫu thiết kế Strategy để đóng gói các thuật toán và cho phép client lựa chọn một trong những thuật toán đó để sử dụng (adsbygoogle = window.adsbygoogle || []).push({});
• Thành phần quản lý thông tin các trang web jn và chủ đề: hỗ trợ nhà phát triển bổ sung các trang web Nn thuộc chủ đề và các thuộc tính của trang web Nn đó dễ dàng hơn. N goài ra còn hỗ trợ nhà phát triển map thuộc tính và giá trị của chủ đề với tên biến và giá trị của trang web.
• Thành phần xử lý dữ liệu: chúng tôi áp dụng mẫu thiết kế Data Access Object Patterns để tách tầng model thành tầng xử lý nghiệp vụ và tầng truy cập dữ liệu để dễ sử dụng hơn.
Trước khi trình bày phần cài đặt hệ thống trong chương 5, trong phần này tôi trình bày tổng quan về những mẫu thiết kế được dùng để xây dựng các thành phần trong ứng dụng và có những lý giải vì sao tôi lại lựa chọn những mẫu thiết kế đó.
4.3 Các mẫu thiết kế được dùng để xây dựng ứng dụng 4.3.1 Mẫu thiết kế MVC 4.3.1 Mẫu thiết kế MVC
Kiến trúc của ứng dụng được thiết kế tuân theo mô hình MVC [21], ứng dụng được tổ chức thành 3 thành phần:
Hình 4-3: Mô hình MVC
Hình 4-3 là mô hình MVC, chi tiết các thành phần như sau
• Mô hình trong (Model): là đối tượng biểu diễn thông tin nghiệp vụ bên trong ứng dụng đang xây dựng. Đối tượng này bao bọc các thành phần dữ liệu và các phương thức liên quan đến ứng xử của nó. Khi phát triển các lớp đối tượng này, người lập trình chỉ quan tâm cài đặt các xử lý hay tiến trình tác nghiệp của ứng dụng mà không cần quan tâm đến việc chúng được hiển thị ra các thiết bị xuất hay lấy vào từ thiết bị nhập như thế nào.
• Hiển thị bên ngoài (View): là thành phần liên quan đến giao diện người dùng. N gười sử dụng “thấy” được đối tượng nghiệp vụ bên trong ứng dụng nhờ phần hiển thị (tức là View) của nó. Đối tượng có thể được hiển thị dưới dạng một trang HTML, một hộp chọn (listbox), hay một danh sách chọn dạng cây (tree view)…
• Bộ điều khiển (Controller): đảm nhiệm việc cập nhật bộ phận hiển thị (View) khi cần thiết. Bộ điều khiển này nhận dữ liệu nhập từ người dùng, truy xuất các thông tin cần thiết từ mô hình trong (Model), và cập nhật thích hợp phần hiển thị (View).
Trong mô hình MVC, sự tách biệt giữa phần trình bày (View và Controller) khỏi phần biểu diễn trong (Model) chính là yếu tố quan trọng góp phần nâng cao chất lượng thiết kế phần mềm. Yếu tố này tách biệt được mã nguồn liên quan đến nghiệp vụ ứng dụng và mã nguồn giao diện người dùng, tạo cơ chế để tránh được mã hóa cứng và trùng lặp mã nguồn, sự sửa đổi về mô hình trong không ảnh hưởng
dây chuyền đưa đến việc sửa đổi nhiều phần giao diện người dùng bên ngoài. Ứng dụng có thể phát triển và mở rộng: với cùng một mô hình trong có thể có nhiều hình thức giao tiếp bên ngoài với người sử dụng (trình duyệt Web, giao tiếp dòng lệnh, hiển thị đồ họa…).
4.3.2 Mẫu Data Access Pattern
Với mong muốn đơn giản hóa việc xây dựng các xử lý trong thành phần Model, và để lập trình các xử lý nghiệp vụ không phụ thuộc vào loại cơ sở dữ liệu nào, các xử lý ở tầng trên sẽ chỉ truy cập thông quan các xử lý nghiệp vụ. Tôi tách tầng Model thành 2 thành phần là Xử lý nghiệp vụ và Truy cập dữ liệu. Do đó, tôi áp dụng mẫu thiết kế Data Access Pattern để giải quyết vấn đề này. Cấu trúc mẫu như sau.
Hình 4-4: Mẫu Data Access Object
Mẫu thiết kế Data Access Object được biểu diễn ở hình 4-4 bao gồm các thành phần chính sau:
• BussinessObject các đối tượng nghiệp vụ, tập trung xử lý các nghiệp vụ của hệ thống.
• Data Access Object (DAO) là thành phần chính của data access layer, dùng để truy nhập cơ sở dữ liệu. Đối với mỗi một Value Object, ta sẽ có một DAO và ngược lại. DAO có thể dùng Value Object để trả dữ liệu cho Business Object, hoặc cũng có thể dựa vào dữ liệu trong Value Object để tiến hành cập nhật dữ liệu cho DataSource.
• Value Object là một đối tượng dùng để lưu trữ thông tin thể hiện của tương ứng một record trong bảng dữ liệu. Với mỗi một bảng dữ liệu ta nên có một lớp DTO.
4.3.3 Mẫu Dynamic Factory
Áp dụng quy tắc “trừu tượng đặt trong code và chi tiết đặt trong metadata” và mẫu Factory Method, tôi sử dụng mẫu Dynamic Factory [13] để giải quyết vấn đề tạo/thay đổi một đối tượng khi đang chạy chương trình bằng cách sử dụng thông tin được lưu trữ trong metadata
Trước khi trình bày mẫu thiết kế Dynamic Factory, tôi trình bày tổng quát về mẫu Factory Method.
4.3.3.1 Mẫu Factory Method
Factory Method [5] là một mẫu thiết kế hướng đối tượng nhằm giải quyết vấn đề tạo một đối tượng mà không cần thiết chỉ ra một cách chính xác lớp nào sẽ được khởi tạo. Factory method giải quyết vấn đề này bằng cách định nghĩa một phương thức cho việc tạo đối tượng, và các lớp con thừa kế có thể cài đặt lại để chỉ rõ đối tượng nào sẽ được tạo.
Áp dụng: mẫu Factory Method thường được áp dụng khi • Một lớp không tham gia vào lớp tạo đối tượng
• Một lớp mong muốn lớp con xác định đối tượng mà nó tạo ra
• Lớp giao trách nhiệm cho một trong các lớp con giải quyết và bạn muốn lớp đó cài đặt lại
Cấu trúc mẫu:
Các thành phần trong hình 4-8 được mô tả chi tiết như sau:
• Product: Định nghĩa giao diện/lớp đối tượng mà factory method tạo ra • ConcreteProduct: Cài đặt giao diện/Kế thừa lớp Product (adsbygoogle = window.adsbygoogle || []).push({});
• Creator:
o Khai báo factory method, trả về đối tượng thuộc kiểu Product o Có thể gọi factory method để tạo đối tượng Product
o ConcreteCreator: cài đặt lại factory method, trả về đối tượng thuộc kiểu ConcreteProduct
Thuận lợi và hạn chế:
• Thuận lợi là đối tượng trả về của factory method là con trỏ đến Product, do đó mà hàm sản xuất có thể trả về bất kỳ đối tượng nào. Điều này loại bỏ việc phải tạo lập một cách trực tiếp một ConcreteProduct trong code, vốn làm hạn chế sự linh động khi sửa đổi chương trình (tight-coupling)
• Hạn chế là mỗi khi cần tạo một đối tượng mới ta phải kế thừa lại lớp Creator và cài đặt phương thức tạo lập
4.3.3.2 Mẫu Dynamic Factory - cải tiến của mẫu Factory Method
Ý nghĩa: N hằm giải quyết vấn đề tạo/thay đổi một đối tượng khi đang chạy chương trình bằng cách sử dụng thông tin được lưu trữ trong metadata.
Cấu trúc mẫu:
Chúng ta nhận thấy cấu trúc mẫu Dynamic Factory trong hình 4-6 và cấu trúc mẫu Factory Method trong hình 4-5 là tương tư nhau. Tuy nhiên trong cấu trúc mẫu ở hình 4-6 có bổ sung 3 thành phần sau:
• MetaData: Thông tin cấu hình trong cơ sở dữ liệu, xml…
• MetaDataReader: Cài đặt giao diện/lớp dùng để đọc thông tin cấu hình. • Information: Cài đặt giao diện/lớp lưu trữ thông tin về concrete Product được
đọc từ metadata.
&hận xét: Mẫu cải tiến này ngoài ưu điểm của Factory Method còn có những ưu điểm sau:
• Tính linh hoạt: Các đối tượng có thể được tạo động với thông tin được lưu trữ trong metadata. Khi sử dụng các kỹ thuật lập trình Reflection trong Java [6] (hay bất kỳ các kỹ thuật tương tự khác), các đối tượng có thể được chỉnh sửa hay xóa và đối tượng mới có thể thêm vào ngay lúc chạy chương trình. • Tính cấu hình: Có thể dễ dàng thay đổi hành vi ứng dụng bằng cách thay đổi
thông tin cấu hình của chúng. Điều này có thể thực hiện mà không cần bất kỳ sự thay đổi code nào cũng như không cần khởi động lại ứng dụng.
• Tuy nhiên mẫu cải tiến này vẫn còn một số hạn chế như: N guy cơ lỗi khi chạy: Các lỗi khi chạy ứng dụng có thể phát sinh khi sử dụng mẫu cải tiến này. Vào lúc biên dịch có thể không phát hiện lỗi nhưng khi thêm hay sửa metadata lúc chạy chương trình thì các lỗi có thể xảy ra.
Áp dụng vào hệ thống đang xây dựng
Tôi áp dụng mẫu Dynamic Factory vào việc xây dựng thành phần controller trong mô hình MVC của ứng dụng. Các nhà phát triển thay vì mã hóa cứng các lớp xử lý ứng với từng yêu cầu của người dùng vào chương trình Java thì có thể lưu trữ thông tin các lớp xử lý của ứng dụng trong tệp tin cấu hình xml. Điều này nhằm mục đích hỗ trợ nhà phát triển không cần phải thay đổi hay biên dịch lại ứng dụng khi cần thay đổi thông tin xử lý. Khi đó, các nhà phát triển web có thể tập trung hơn vào công việc cụ thể của họ mà không cần quan tâm đến tổng thể của hệ thống.
4.3.4 Mẫu Abstract Factory
Khi sử dụng ứng dụng rút trích thông tin từ các trang web Nn với nội dung động, công việc phân loại các trang web Nn đó thuộc một chủ đề nào đó là vô cùng cần thiết. Với mỗi chủ đề, chúng ta có thể xác định được các thuộc tính chung ứng với chủ đề đó. Từ đó có thể xây dựng được các câu truy vấn tương ứng với các trang web Nn nội dung động một cách phù hợp nhất. N goài ra, việc phân loại thành từng chủ đề cũng rõ ràng hơn cho người dùng nhập hay chọn lựa các tiêu chí để hệ thống tiến hành rút trích thông tin
Ứng với mỗi chủ đề, hệ thống phải có giao diện ứng với các thuộc tính chung của chủ đề đó. Sau khi nhận các yêu cầu của nguời dùng, hệ thống sẽ tạo ra các câu truy vấn ứng với từng trang web Nn, gửi yêu cầu, nhận kết quả và tiến hành rút trích thông tin từ kết quả trả về đó.
Ở đây, chúng tôi sử dụng mẫu Abstract Factory để xây dựng quá trình trên. Mỗi khi người dùng có nhu cầu rút trích thông tin một chủ đề nào đó, chỉ cần thay đổi điều kiện tạo lập factory, sẽ có một factory tương ứng với chủ đề đó. Khi đó sẽ phát sinh một nhóm các “sản phNm” tương ứng với chủ đề đó. Mỗi “sản phNm” sẽ tiến hành một công việc có liên quan đến chủ đề đó
Chúng tôi mô tả tổng quan về mẫu Abstract Factory trước khi trình bày phần cài đặt mẫu này trong mục 5.3.2
Ý nghĩa: Abstract Factory [5] cung cấp một giao diện có chức năng tạo ra một tập hợp các đối tượng liên quan hoặc phụ thuộc lẫn nhau mà không chỉ ra đó là những lớp cụ thể nào tại thời điểm thiết kế.
• Một hệ thống cần phải không phụ thuộc vào việc những sản phNm được tạo ra như thế nào.
• Một hệ thống cần được cấu hình với một hoặc nhiều họ sản phNm.
• Các đối tượng cần phải được tạo ra như một tập hợp để có thể tương thích với nhau
• Chúng ta muốn cung cấp một tập các lớp và chúng ta muốn thể hiện các ràng buộc, các mối quan hệ giữa chúng mà không phải là các thực thi của chúng.
Cấu trúc: (adsbygoogle = window.adsbygoogle || []).push({});
Hình 4-7: Mẫu Abstract Factory
Mô tả các thành phần trong hình 4-7 như sau:
• AbstractFactory: định nghĩa một giao tiếp cho thao tác khởi tạo các đối tượng sản phNm.
• ConcreteFactory: cài đặt thao tác để tạo ra đối tượng cụ thể.
• AbstractProduct: định nghĩa một giao diện cho một loại đối tương sản phNm. • ConcreteProduct: kế thừa từ từ lớp "sản phNm" ảo AbstractProduct, các lớp
Product định nghĩa từ đối tượng cụ thể
4.3.5 Mẫu Strategy
Khi áp dụng thuật toán rút trích thông tin, chúng tôi sử dụng nhiều thuật toán