Tải bản đầy đủ
Chương 1: TỔNG QUAN VỀ FRAMEWORK

Chương 1: TỔNG QUAN VỀ FRAMEWORK

Tải bản đầy đủ

-5-

1.1.1. Định nghĩa về framework
Thuật ngữ framework hướng đối tượng có thể được định nghĩa theo nhiều
cách. Một framework được định nghĩa như là một phần của thiết kế và thực hiện,
cho một ứng dụng trong một lĩnh vực. Điều này cho thấy: một framework không
phải là một hệ thống hoàn chỉnh. Hệ thống này có thể được điều chỉnh lại để tạo ra
các ứng dụng hoàn chỉnh. Các framework nói chung được sử dụng và được phát
triển khi cần phát triển một vài ứng dụng tương tự. Một framework là phần chung
giữa các ứng dụng này. Do vậy, một framework giảm công sức cần thiết để xây
dựng các ứng dụng.
Phần lớn các định nghĩa đều nhất trí rằng, một framework là một kiến trúc
phần mềm có thể sử dụng lại, bao gồm cả thiết kế và mã thực hiện được. Tuy nhiên,
lại không có định nghĩa nào được thống nhất chung về framework và các thành
phần hợp thành của nó.
Sau đây là một số các định nghĩa khác nhau hoặc tương tự nhau về framework
được nêu ra:
“Một framework ràng buộc các lựa chọn chính xác về sự phân chia trạng thái
và luồng điều khiển, người dùng hoàn thiện hoặc mở rộng framework để tạo ra một
ứng dụng thực tế”
“Một framework là một tập các lớp mà bao gồm một thiết kế trừu tượng cho
các giải pháp của một hoặc các vấn đề liên quan”
“Một framework là một tập các đối tượng mà cộng tác với nhau để tạo ra một
tập các đáp ứng cho một ứng dụng hoặc một vùng hệ thống con”
“Một framework là một tập các ký hiệu của các lớp cộng tác mà đạt được cả
các mẫu phạm vi nhỏ và các cơ chế chủ yếu để thực hiện các yêu cầu chung và thiết
kế trong một phạm vi ứng dụng cụ thể”
“Một tập các lớp cộng tác với nhau mà tạo ra một thiết kế có thể sử dụng lại
cho một lớp cụ thể của phần mềm. Một framework cung cấp các hướng dẫn có tính
kiến trúc bằng cách phân chia thiết kế thành các lớp trừu tượng và định nghĩa các

-6-

đáp ứng và sự cộng tác của chúng. Một nhà phát triển tùy biến framework thành
một ứng dụng cụ thể bằng cách tạo ra các lớp con và tạo ra các phiên bản của các
lớp framework”
Như vậy, một framework bao gồm một tập các lớp mà các thể hiện của chúng
cộng tác với nhau, được dự định để mở rộng, sử dụng lại cho các ứng dụng cụ thể
của một lĩnh vực. Một họ các vấn đề liên quan, cho phép tổng hợp trong một
framework. Hơn nữa, các framework được biểu diễn thành một ngôn ngữ lập trình,
như vậy nó cung cấp cho việc sử dụng lại cả mã thực hiện và thiết kế.

1.1.2. Cấu trúc của một framework
Một framework hướng đối tượng bao gồm các 5 thành phần sau:
• Các tài liệu thiết kế
• Các giao diện
• Các lớp trừu tượng
• Các thành phần
• Các lớp
Mối quan hệ giữa các thành phần khác nhau trong một framework được mô tả
như hình vẽ sau:

Các tài liệu
thiết kế
phản ánh khai

Các giao diện

triển khai

triển khai

Các lớp trừu tượng
thừa kế

Các thành phần
là 1 phần

Các lớp
Hình 1.1: Mối quan hệ giữa các thành phần khác nhau của framework

-7-

Các thành phần của một framework bao gồm:
Các tài liệu thiết kế: thiết kế của một framework có thể bao gồm các lược đồ
lớp, viết bằng văn bản hoặc chí ít là một ý tưởng trong đầu của nhà phát triển.
Các giao diện: các giao diện mô tả sự đáp ứng với bên ngoài của các lớp. Các
giao diện có thể được sử dụng để mô hình hóa các vai trò khác nhau trong hệ thống,
ví dụ như các vai trò trong một mẫu thiết kế. Một vai trò đại diện cho một nhóm các
phương pháp trong giao diện mà liên quan tới các phương pháp do các phần khác
thực hiện.
Các lớp trừu tượng: một lớp trừu tượng là một sự thực hiện chưa đầy đủ của
một hoặc nhiều giao diện. Nó có thể được sử dụng để định nghĩa cách ứng xử của
một số các thành phần thực hiện một nhóm các giao diện.
Các thành phần: Giống như các lớp, các thành phần có thể được tích hợp với
các lớp khác. Trong hình vẽ, có một mũi tên “là một phần của” giữa các lớp và các
thành phần. Nếu bản thân các lớp có một API được định nghĩa đầy đủ thì tập kết
quả của các lớp sẽ được biểu hiện như là một tổ hợp các thành phần. Một thành
phần được định nghĩa như sau: “Một thành phần phần mềm là một đơn vị kết cấu
với các giao diện được ghi rõ theo hợp đồng và các phụ thuộc ngữ cảnh rõ ràng.
Một thành phần phần mềm có thể được triển khai độc lập và được tổ hợp bằng các
hãng thứ ba”
Các lớp: Mức thấp nhất của một framework là các lớp. Các lớp chỉ khác với
các thành phần là trong thực tế, các API được công khai của nó không được đưa ra
trong các giao diện của một framework. Một cách điển hình là các lớp được các
thành phần sử dụng để đại diện cho chức năng. Ví dụ một người dùng framework
thường không nhìn thấy các lớp này trừ khi anh ta làm việc với các thành phần.
Cách thức làm việc của một framework như sau:
Một framework làm việc bằng cách cung cấp một đặc tả rõ ràng của các tương
tác được mong đợi giữa các thành phần. Ví dụ, một thành phần có thể trông chờ

-8-

những gì từ các thành phần khác và cái gì nên được cung cấp tới chúng? Một
framework định nghĩa các dịch vụ lựa chọn, và cung cấp một giải thích cho việc
định nghĩa thành phần nào là một thành phần cung cấp. Như thế, một thành phần sẽ
có khả năng được mở rộng rất lớn và các thành phần mới có thể tương tác mạnh mẽ
với những cái đã có. Chúng cộng tác với các chi tiết, khía cạnh cụ thể của các vấn
đề được cân nhắc bởi framework. Các thành phần ứng dụng có thể còn chứng minh
cho tính tương thích với các vấn đề khác, như ngữ nghĩa của dữ liệu mà chúng
chuyển qua. Các bộ phận phụ thuộc có thể được giới thiệu như là các thành phần
của framework. Sự thi hành các thành phần này có thể cùng framework xác định
một dịch vụ và cung cấp các dịch vụ này cho các thành phần khác.

1.1.3. Phân biệt framework với các khái niệm khác
Một mẫu thiết kế khác với một framework ở ba điểm. Thứ nhất, một mẫu thiết
kế là trừu tượng hơn một framework, bởi vì một framework được bao gồm cả mã,
trong khi đó chỉ các mẫu thiết kế mới cần được mã hóa. Các mẫu thiết kế thậm chí
chỉ mô tả mục đích, việc cân bằng các yếu tố khác để đạt được sự kết hợp tốt nhất
và các kết quả của một thiết kế. Trong trường hợp này có nghĩa là nó chưa thể là
một thành phần của một framework. Thứ hai, các mẫu thiết kế là những kiến trúc
nhỏ hơn so với các framework. Do vậy, một framework có thể chứa một số các mẫu
thiết kế, nhưng điều ngược lại là không thể. Do vậy, các mẫu thiết kế không có ảnh
hưởng lớn tới kiến trúc của ứng dụng. Cuối cùng, các framework được chuyên môn
hóa hơn so với các mẫu thiết kế. Các framework luôn luôn liên quan đến một miền
ứng dụng cụ thể, trong khi đó các mẫu thiết kế là chung và có thể được ứng dụng
trong bất kỳ miền ứng dụng nào.
Các ngôn ngữ mẫu khác với framework theo cách mà một ngôn ngữ mẫu miêu
tả: làm như thế nào để tạo ra một thiết kế. Trong khi đó, một framework hướng đối
tượng là một thiết kế. Các ngôn ngữ mẫu bổ sung cho một framework, do chúng có
thể hướng dẫn các kỹ sư phần mềm sử dụng framework như thế nào, và mô tả tại
sao nó lại được thiết kế như vậy.

-9-

Một ứng dụng hướng đối tượng khác với một framework ở chỗ, một ứng dụng
mô tả một chương trình thực hiện phức tạp mà thỏa mãn các yêu cầu cụ thể đặt ra.
Framework đạt được các tính năng của một ứng dụng nhưng nó không thể thi hành
được bởi vì nó không bao gồm các tương tác trong trường hợp ứng dụng cụ thể.
Các framework khác với các thư viện lớp ở chỗ: chúng nhắm tới các miền ứng
dụng cụ thể. Trong khi đó, các thư viện lớp cung cấp cho người sử dụng các sự thực
hiện trước của thuật toán. Các thư viện lớp là thụ động, người sử dụng gọi đến các
phương pháp trong thư viện lớp để thực hiện một số hoạt động. Trong khi đó các
framework định nghĩa khung khổ cho một ứng dụng thực tế và quản lý các luồng
điều khiển trong ứng dụng. Các framework có thể khác so với thư viện lớp, nhưng
chúng có thể sử dụng các thư viện lớp đã có sẵn để thực hiện các thuật toán chung
và các cấu trúc dữ liệu.
Các thành phần phần mềm ban đầu đã được dự định là các thành phần chức
năng riêng lẻ mà có thể được đầu tư từ nhà cung cấp và tích hợp vào trong các ứng
dụng. Các framework dường như là những thành phần mà có thể được đầu tư từ nhà
cung cấp và nhiều hơn một framework có thể được sử dụng trong một ứng dụng.
Tuy nhiên, một điểm khác dễ nhận thấy giữa chúng là các framework cung cấp một
bộ rộng hơn các dịch vụ so với các thành phần phần mềm. Chúng có khả năng tùy
biến nhiều hơn, có các giao diện phức tạp hơn và điều quan trọng hơn là chúng thực
sự định nghĩa cho một họ ứng dụng hoặc một diện rộng của các ứng dụng. Do vậy,
các framework là khó học hơn đối với các nhà phát triển, nhưng một khi đã hiểu
được hết framework thì sẽ có được sự linh động cao hơn và với một framework
được thiết kế tốt thì có thể giảm được các nỗ lực cần bỏ ra để xây dựng một ứng
dụng đã được tùy biến một cách đáng kể.
Trong khi các framework và các thành phần là các kỹ thuật khác nhau, chúng
nên được xem và được sử dụng như các kỹ thuật cộng tác với nhau. Với các
framework có thể sử dụng các thành phần và các ứng dụng được phát triển sử dụng
các framework thậm chí có thể tiện dụng hơn các thành phần. Ví dụ, một ứng dụng
Visual C++ được tạo với MFC framework, thậm chí có thể sử dụng các thành phần

-10-

ActiveX trong giao diện của nó giống như việc trao đổi với các thành phần ActiveX
được đóng gói trong MFC framework. Một ví dụ khác cho sự phụ thuộc lẫn nhau
giữa các framework và thành phần là việc sử dụng các framework để tạo các thành
phần mới, ví dụ, framework Active Template Library (ATL) của Microsoft được sử
dụng rộng rãi trong việc tạo các thành phần ActiveX.

1.1.4. Các đặc điểm của framework
Một framework hướng đối tượng có bốn đặc điểm chính sau :
• Khả năng môđun hóa
• Khả năng sử dụng lại
• Khả năng mở rộng
• Sự đổi chiều của điều khiển
Về đặc điểm thứ nhất, các framework tăng cường khả năng môđun hóa bằng
cách đóng gói các chi tiết thực hiện không chắc chắn đằng sau các giao diện chắc
chắn. Khả năng này giúp cho việc tăng cường chất lượng của phần mềm bằng cách
cục bộ hóa các tác động của những thay đổi về kiến trúc và sự thực hiện. Sự cục bộ
hóa này giảm các nỗ lực được yêu cầu để hiểu và duy trì phần mềm hiện có.
Mặt khác, các giao diện chắc chắn được cung cấp bởi các framework còn tăng
cường khả năng sử dụng lại bằng cách định nghĩa các thành phần chung mà có thể
được áp dụng để tạo ra các ứng dụng mới. Khả năng sử dụng lại của framework
tăng cường kiến thức của miền ứng dụng và các nỗ lực của các nhà phát triển có
kinh nghiệm để tránh việc tạo và làm lại các giải pháp chung cho các yêu cầu của
ứng dụng lặp lại và cũng như các thách thức tiến hành trong thiết kế phần mềm.
Việc sử dụng lại các thành phần thiết kế có thể là một sự cải tiến đáng kể trong sản
xuất chương trình, cũng như tốt cho việc nâng cao chất lượng, tính hiệu quả, độ tin
cậy và tính sẵn sàng của phần mềm.
Về khả năng mở rộng, một framework tăng cường khả năng mở rộng bằng
cách cung cấp các điểm nóng tường minh cho phép các ứng dụng mở rộng các giao

-11-

diện chắc chắn và cách ứng xử của vùng ứng dụng với các thay đổi được yêu cầu
cho các trường hợp của ứng dụng trong một ngữ cảnh cụ thể. Khả năng mở rộng
của framework là cần thiết để đảm bảo các sự điều chỉnh có tính thời gian của các
dịch vụ và tính năng ứng dụng mới.
Cuối cùng, đặc điểm của kiến trúc cho thời gian chạy của một framework là sự
đổi chiều của điều khiển, thường được gọi là “Nguyên tắc Hollywood”- Đừng gọi
cho chúng tôi, chúng tôi sẽ gọi cho bạn. Kiến trúc này cho phép ứng dụng hợp với
các quy tắc tiêu chuẩn nhờ việc điều chỉnh từng bước các xử lý thông qua các đối
tượng quản lý sự kiện mà được tham chiếu đến do cơ chế gửi kích họat ngược trở
lại của framework. Khi các sự kiện xảy ra, framework gửi lại kích hoạt bằng cách
chỉ dẫn phương pháp móc nối trên các đối tượng quản lý sự kiện đã được đăng ký
trước để thực hiện việc xử lý ứng dụng cụ thể dựa trên các sự kiện. Việc đổi chiều
điều khiển này cho phép framework định nghĩa một tập các phương pháp ứng dụng
cụ thể để đáp ứng với các sự kiện ở bên ngoài.

1.2. Phân loại khung làm việc
Framework hướng đối tượng có thể được phân loại theo nhiều chiều khác
nhau, trong đó những chiều quan trọng nhất là vùng vấn đề mà framework trỏ tới,
cấu trúc bên trong của framework và việc nó dự định sử dụng như thế nào.
Với cách phân loại thứ nhất, người ta chia các khung làm việc thành các
khung làm việc ứng dụng, khung làm việc miền ứng dụng và khung làm việc trợ
giúp.
Với phân loại theo cách thức dự định sử dụng, các khung làm việc chia thành
các khung làm việc hộp đen, các khung làm việc hộp trắng và các khung làm việc
hộp xám.

1.2.1. Phân loại framework theo vùng vấn đề
Việc phân loại theo vùng vấn đề chia các framework ba loại là các khung làm
việc ứng dụng, các khung làm việc miền ứng dụng và các khung làm việc hỗ trợ.

-12-

Một khung làm việc ứng dụng là một tập của các thành phần với một thiết kế
ứng dụng có thể được sử dụng lại. Điều này có nghĩa rằng, người dùng không
những nhận được một tập con mã chức năng mà còn bắt đầu với cả một thiết kế về
cách mà chúng làm việc như thế nào. Điều này cũng có nghĩa là, một framework
ứng dụng có thể cung cấp nhiều tính năng hơn các thư viện hàm, vì về cơ bản các
thư viện hàm là không phụ thuộc vào nhau.
Loại thứ hai là phân loại khung làm việc theo vùng vấn đề của một miền ứng
dụng. Các framework này đạt được kiến thức và sự tinh thông trong một vùng vấn
đề cụ thể.
Loại cuối cùng theo cách phân loại này là các khung làm việc hỗ trợ. Các
framework hỗ trợ là các framework mà phục vụ cho các dịch vụ mức thấp của hệ
thống như các trình điều khiển cho các thiết bị và bộ điều khiển truy nhập tệp. Nhà
phát triển ứng dụng sử dụng các framework hỗ trợ trực tiếp hoặc sử dụng các sự
điều chỉnh được tạo ra bởi các trình cung cấp của hệ thống. Các framework hỗ trợ
có thể được tùy biến, ví dụ khi phát triển một hệ thống mới hoặc trình điều khiển
thiết bị mới.

1.2.2. Phân loại framework theo cấu trúc nội bộ
Nếu như cấu trúc nội tại của framework được miêu tả thì nó có thể làm cho
việc hiểu cách ứng xử của framework dễ dàng hơn. Cấu trúc nội tại của một
framework liên quan tới các khái niệm về các kiến trúc phần mềm. Những kiến trúc
này được gọi là “các khung làm việc kiến trúc”, do chúng được thiết kế theo cách để
đạt được cấu trúc vững chắc của một kiến trúc phần mềm hướng đối tượng. Nguyên
tắc tổng thể cho cấu trúc nội tại của một framework được mô tả qua đặc trưng kiến
trúc của nó. Các framework có tính kiến trúc đã được mô tả là:
Layered (kiến trúc phân tầng), giúp cho cấu trúc các ứng dụng có thể được
phân rã thành các nhóm của các công việc con với mức trừu tượng khác nhau định
vị ở tầng khác nhau.
Pipes and Filters (kiến trúc ống và bộ lọc), có thể được dùng để cấu trúc các
ứng dụng có thể được chia thành một vài các công việc con hoàn toàn độc lập, được
thực hiện theo trình tự nối tiếp hoặc song song đã được xác định một cách rõ ràng.

-13-

Model-View-Controller (kiến trúc MVC), định nghĩa một kiến trúc cho các
ứng dụng có tính tương tác, chia tách giữa giao diện của ứng dụng với các chức
năng chủ yếu của nó: mô hình xử lý và dữ liệu.
Presentation-Abstraction-Controller (kiến trúc trình diễn-Trừu tượng-Điều
khiển), kiến trúc này là thích hợp để cấu trúc các hệ thống phần mềm mà có tính
tương tác cao với người sử dụng, cho phép những điều khiển và trình diễn của các
mô hình trừu tượng của hệ thống có thể được tạo bên ngoài các chức năng con và
độc lập với mỗi cái khác.
Reflective (kiến trúc phản ánh), có khả năng áp dụng cho các ứng dụng mà cần
phải cân nhắc về một sự thích nghi trong tương lai do sự thay đổi môi trường, công
nghệ và các yêu cầu khác, mà không cần phải thay đổi về kiến trúc và cách thực
hiện của nó.
Microkernel là phù hợp cho các hệ thống phần mềm cần cung cấp các khung
nhìn khác nhau dựa trên các chức năng của chúng và phải thích nghi với các yêu
cầu của hệ thống. Ví dụ của microkernel của các hệ điều hành.
Blackboard (kiến trúc bảng đen), giúp để cấu trúc các ứng dụng phức tạp mà
liên quan tới một vài hệ thống con chuyên biệt cho các lĩnh vực khác nhau. Các hệ
thống con này phải hợp tác để xây dựng các giải pháp cho việc giải quyết các vấn
đề.
Broker (kiến trúc môi giới), cấu trúc các hệ thống phần mềm phân tán, trong
đó các thành phần tương tác khác nhau giao tiếp với nhau khi vận hành thông qua
truyền thông như trong một mô hình chủ khách.
Việc sử dụng các kiến trúc này như là một nguyên tắc thiết kế chủ yếu cho
một framework. Điều đó có nghĩa là, các kiến trúc này là các ứng cử viên tốt cho
việc ứng dụng các mẫu thiết kế hướng đối tượng cũng như cho việc phát triển
framework.

-14-

1.3. Các phương pháp phát triển framework
Quá trình phát triển một framework phụ thuộc vào kinh nghiệm của việc tổ chức
các thành phần trong miền vấn đề mà nó chỉ ra. Tổ chức có nhiều kinh nghiệm hơn
có thể lựa chọn quy trình phát triển hiện đại hơn vì họ sẽ có ít vấn đề hơn với miền
vấn đề. Một số quy trình khả thi cho việc phát triển framework đã được đưa ra:

1.3.1. Quy trình phát triển dựa trên các kinh nghiệm ứng dụng
Hướng phát triển framework mang tính thực dụng được miêu tả [10]. Trước

hết phát triển n ứng dụng, ít nhất từ hai ứng dụng trong miền vấn đề. Khi
chúng làm việc đúng thì việc lắp lại đầu tiên trong quy trình bắt đầu như hình
3.3. Phân loại các đặc điểm chung trong cả hai ứng dụng và kiết xuất chúng
thành một framework. Để đánh giá liệu các đặc điểm được kiết xuất ra có đúng
không, phát triển lại các ứng dụng (n) dựa trên framework đó. Điều này có lẽ khá
dễ dàng nếu các đặc tính chung được phân loại đúng. Nếu việc phát triển lại các ứng
dụng không dễ dàng thì việc viết lại framework là cần thiết và sử dụng kinh
nghiệm đã có để phát triển bản tiếp theo của framework. Đây là cách thức cho lần

lặp thứ hai và tất cả các lần lặp tiếp theo cho ở trong hình 1.2. Dựa trên phiên
bản mới của framework, các ứng dụng mới có thể được phát triển. Các kinh
nghiệm đạt được thông qua các ứng dụng mới cũng được sử dụng như là đầu vào
cho việc bảo trì framework theo tiến độ. Toàn bộ quy trình được thể hiện
trong hình 1.2.

-15-

Hình 1.2: Phát triển framework dựa trên kinh nghiệm ứng dụng [10]

1.3.2. Quy trình phát triển framework dựa trên phân tích miền vấn
đề
Một hướng tiếp cận phức tạp hơn cho việc phát triển một framework là phân
tích miền vấn đề. Quy trình phát triển được chỉ ra trong hình 1.3. Hoạt động đầu
tiên đó là phân tích miền vấn đề để phân loại và hiểu các thành phần trừu tượng nổi
bật trong miền vấn đề. Phân tích tên miền đòi hỏi phân tích các ứng dụng hiện có
(đây là một nhiệm vụ khó thực hiện) và chỉ có thể nếu tổ chức có các ứng dụng
được phát triển trong miền vấn đề. Việc phân tích các ứng dụng hiện có cũng sẽ
chiếm một tỷ lệ lớn ngân sách.

Hình 1.3: Quy trình phát triển framework dựa trên phân tích miền vấn đề [10]

Sau khi các lớp trìu tượng được nhận biết, phát triển framework cùng với một
ứng dụng kiểm tra, (sử dụng mũi tên như trong hình 1.3), sau đó điều chỉnh khung
làm việc nếu cần thiết. Tiếp theo, phát triển một ứng dụng thứ hai dựa trên
framework này. Thay đổi framework nếu cần thiết và sửa đổi ứng dụng đầu tiên để
nó có thể làm việc với những thay đổi đưa ra. Hãy để framework vận hành thông