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
• 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:
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 khác nhau để áp dụng tiến hành rút trích phù hợp. Các nhà phát triển thuờng sẽ có giải pháp là viết trực tiếp (hard- coding) những thuật toán vào ngữ cảnh sử dụng (context). Điều này có những điểm bất lợi sau:
• Tạo liên kết cứng giữa các hành vi và ngữ cảnh sử dụng. Thêm thuật toán và thay đổi thuật toán hiện có trở lên khó khăn vì chúng là một phần mã nguồn
• Khi dùng nhiều thuật toán trở lên hệ thống sẽ phức tạp vì chứa đựng mã nguồn lớn. Điều này làm cho chúng chiếm nhiều tài nguyên và khó duy tu bảo dưỡng.
• Mỗi thuật toán tối ưu cho từng trường hợp nhất định. Chúng ta không thể cài đặt tất cả, trong khi ta chỉ dùng 1 số ít thuật toán.
Chúng ta có thể vượt qua những bất lợi nêu trên bằng cách định nghĩa lớp bao bọc các thuật toán. Do đó, chúng tôi đề xuất sử dụng mẫu strategy ở đây. Mẫu Strategy được trình bày tổng quát như sau.
Mẫu Strategy [5] định nghĩa và bao bọc các thuật toán có cùng mục đích trong những lớp có giao diện chung . Làm cho sự thay đổi thuật toán trở lên linh động và độc lập với khách hàng.
Áp dụng: có thể ứng dụng Strategy trong những trường hợp sau:
• N hiều lớp liên quan chỉ khác nhau ở cách xử lý yêu cầu. Với 1 lựa chọn trong những cách xử lý Strategy giúp ta thực hiện trách nhiệm của 1 lớp. • Có nhiều cách thực hiện cùng một thuật toán. Phải cho khách hàng khả năng
lựa chọn cách ưu việt nhất trong sử dụng tài nguyên như chỗ và thời gian. Lên dùng Strategy khi các thuật toán này được thể hiện như môt cơ cấu lớp của các thuật toán.
• Thuật toán dùng dữ liệu mà khách hàng không biết tới. Dùng Strategy để thay thế việc công khai hoá những cấu trúc dữ liệu phức tạp, đặc thù cho thuật toán.
• Khách hàng định nghĩa nhiều cách xử lý khác nhau và những cách xử lý này có thể coi như câu lệnh chia nhánh ( if-then-elsif, switch) trong phương thức. Thay vì dùng cấu trúc điều kiện ta dùng các lớp Strategy cài đặt riêng từng nhánh.
Hình 4-8: Mẫu Strategy
Mô tả các thành phần tham gia trong hình 4-8 như sau
• Strategy (Compositor): Định nghĩa giao diện chung cho các thuật toán được cài đặt. Context dùng giao diện này để gọi những thuật toán được thực hiện trong những ConcreteStrategy (Strategey cụ thể)
• ConcreteStrategy (SimpleCompositor, TeXCompositor, ArrayCompositor): Cài đặt các thuật toán sử dụng giao diện Strategy.
• Context (Composition):
o Được hiệu chỉnh bằng 1 đối tượng Strategy o Bảo dưỡng tham chiếu tới đối tượng Strategy
o Có thể định nghĩa giao diện cho Strategy dùng được dữ liệu của nó
Thuận lợi và hạn chế:
• Thể hiện họ các thuật toán liên quan. Việc kế thừa giúp hiện thực những chức năng chung của các thuật toán.
• Hỗ trợ sự luân phiên giữa các lớp con. Có thể tạo lớp con của lớp Context một cách trực tiếp để tạo cho nó những hành vi khác. Tuy nhiên cách làm này sẽ tạo thành một liên kết cứng giữa các hành vi và lớp Context. N ó trộn lẫn việc thực thi thuật toán với việc thực thi lớp Context làm cho lớp Context khó hiểu, khó duy trì và khó mở rộng.
• Một sự lựa chọn nhiều cách thực thi. Mẫu này cung cấp nhiều cách thực thi khác nhau cho cùng một hành vi
Chương 5 Cài đặt và kiểm thử
Chương này, chúng tôi trình bày phần cài đặt các mẫu thiết kế hướng đối tượng trong ứng dụng hỗ trợ rút trích thông tin theo chủ đề bằng ngôn ngữ lập trình Java. Theo [11], có 2 quá trình trong xây dựng ứng dụng hỗ trợ rút trích thông tin theo chủ đề:
• Quá trình xây dựng các thuộc tính hỗ trợ rút trích thông tin từ trang web Nn • Quá trình xây dựng công cụ hỗ trợ rút trích thông tin từ các trang web Nn
5.1 Quá trình xây dựng các thuộc tính hỗ trợ rút trích thông tin:
Xây dựng các thuộc tính kèm theo giá trị thường được dùng cho từng lĩnh vực. Có nhiều phương pháp có thể tiến hành để lấy các thuộc tính của form như thống kế thủ công, tự động... Ở đây chúng tôi áp dụng phương pháp thống kê dựa trên kiến thức nhà phát triển.
B1: Phân tích các thuộc tính của các trang web Nn thuộc cùng lĩnh vực. B2: Lập bảng thống kê số lần xuất hiện của từng thuộc tính của mỗi trang. B3: Xây dựng thuộc tính chung thường được các trang sử dụng.
Ví dụ khi áp dụng cho chủ đề về Công việc, chúng tôi khảo sát các trang web sâu và tiến hành thống kê được các thuộc tính như bảng. Các giá trị của thuộc tính nhà phát triển có thể tiến hành thống kê từ các trang web hoặc tự chọn các giá trị theo nhu cầu. Quá trình thống kê thuộc tính theo lĩnh vực Công việc có thể xem phụ lục C.
STT Thuộc tính Giá trị 1 N gành nghề IT - Phần cứng/Mạng
IT Phần mềm Điện/Điện tử Giáo dục/Đào tạo
2 Tỉnh Thành phố Hồ Chí
Minh Hà N ội 3 Loại hình công việc Bán thời gian
Toàn thời gian Tập sự
4 Trình độ học vấn Trung học Cao đẳng Đại học 5 Việc được đăng cách đây 1 Tuần
2 tuần
Bảng 5-1: Minh họa các thuộc tính chung theo chủ đề Việc làm 5.2 Quá trình xây dựng công cụ hỗ trợ rút trích thông tin:
5.2.1 Giao diện ứng dụng:
Hệ thống của chúng tôi hỗ trợ nhà phát triển dễ dàng xây dựng ứng dụng