Tài liệu Xây dựng ngôn ngữ mẫu cho lập trình dựa trên thành phần

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN HẢI BÌNH XÂY DỰNG NGÔN NGỮ MẪU CHO LẬP TRÌNH DỰA TRÊN THÀNH PHẦN LUẬN VĂN THẠC SĨ Hà Nội – 2010 MỤC LỤC Trang MỞ ĐẦU ........................................................................................................... 1 Chương 1. Khái quát về phát triển hệ thống dựa trên thành phần ............... 2 1.1 Tiến trình công nghệ phần mềm dựa trên thành phần ................................... 2 1.2 Phát triển hệ thống dựa trên thành phần ........................................................ 4 1.2.1 Định phẩm, thích ứng và hợp thành thành phần ..................................... 5 1.2.2 Chế tạo thành phần ................................................................................. 8 1.2.3 Phân tích và thiết kế cho dùng lại ........................................................... 8 1.2.4 Phân loại và tìm kiếm thành phần........................................................... 9 1.3 Mô hình vòng đời tiến trình dựa trên thành phần ........................................ 11 Chương 2. Mô hình thành phần .................................................................... 16 2.1 Cơ sở cho mô hình thành phần ................................................................... 16 2.2 Thiết kế ...................................................................................................... 22 2.3 Giao diện và hợp đồng................................................................................ 24 2.4 Thành phần ................................................................................................. 28 Chương 3. Ngôn ngữ mẫu đặc tả thành phần ............................................... 31 3.1 Ví dụ hệ thống ParcelCall ........................................................................... 31 3.2 Đặc tả giao diện .......................................................................................... 32 3.2.1 Giao diện sơ cấp ................................................................................... 32 3.2.2 Kết hợp và thừa kế giao diện ................................................................ 33 3.3 Đặc tả hợp đồng ......................................................................................... 34 3.3.1 Sự đặc tả của một phương thức ............................................................ 34 3.3.2 Kết hợp, làm mịn và thừa kế hợp đồng ................................................. 36 3.4 Đặc tả thành phần ....................................................................................... 38 3.4.1 Ngữ nghĩa của thành phần ................................................................... 38 3.4.2 Sự làm mịn, che dấu giao diện và kết hợp các thành phần. ................... 42 Chương 4. Ví dụ về đặc tả thành phần.......................................................... 45 4.1 Khái quát về hệ thống ................................................................................. 45 4.2 Phân tích ca sử dụng và đặc tả thành phần .................................................. 47 KẾT LUẬN ..................................................................................................... 54 TÀI LIỆU THAM KHẢO.............................................................................. 55 1 MỞ ĐẦU Một ý tưởng là lợi dụng và sử dụng lại các thành phần để xây dựng và để bảo trì các hệ thống phần mềm hình thành từ “lập trình cấu trúc” trong nhưng năm 70. Đó là một luận cứ mạnh để phát triển các phương pháp và các ngôn ngữ hướng đối tượng trong những năm 80, và ngày nay với sự phát triển các hệ thống lớn đã khiến chúng ta quay lại ý tưởng này và biến nó thành hiện thực. Kỹ thuật hướng đối tượng và kỹ thuật dựa trên thành phần đã trở thành phổ biến và được sử dụng rộng rãi trong mô hình hóa và thiết kế cho hệ thống phần mềm phức tạp. Chúng cung cấp khả năng hỗ trợ cho việc phân rã một ứng dụng thành các đối tượng và các thành phần, những thứ có thể sử dụng lại và mở rộng những thiết kế dựa trên những thành phần đã tồn tại. Sự phân tích và kiểm chứng những hệ thống như vậy sẽ là dễ dàng bởi tính kết hợp trong kiến trúc thành phần. Một số minh chứng tiêu biểu cho kỹ thuật hướng đối tượng và kỹ thuật dựa trên thành phần là CORBA, EJB, J2EE, COM và .NET. Bên cạnh đó những ngôn ngữ mô hình hóa hình thức và bán hình thức như UML, JML và BIP đã trở thành phổ biến với việc hỗ trợ phát triển hệ thống dựa trên mô hình. Tuy nhiên những mô hình này hoặc là không hỗ trợ mức trừu tượng hóa hoặc thiếu ký hiệu ngữ nghĩa, là thứ có thể được sử dụng để tích hợp với ngôn ngữ lập trình khác, và đến bây giờ chúng vẫn chưa cung cấp đủ sự hỗ trợ cho việc mô hình hóa và phân tích chất lượng tổng thể những dịch vụ của hệ thống được phát triển từ những thành phần. Chúng ta cần tìm kiếm một kỹ thuật mô hình hóa, có thể hỗ trợ việc đặc tả hệ thống thành phần ở mức trừu tượng hóa cao, và có thể cung cấp một nền tảng cơ sở để phát triển một ngôn ngữ mẫu có khả năng tích hợp vào các ngôn ngữ lập trình khác nhau để hỗ trợ cho việc lập trình dựa trên thành phần. Với mục đích đó, luận văn tập trung đi vào tìm hiểu việc thiết lập mô hình toán học cho thành phần, đưa ra những định nghĩa hình thức cho giao diện, hợp đồng, thành phần, và cả những vấn đề liên quan đến chúng như làm mịn, thừa kế, kết hợp. Luận văn cũng đề xuất cách biểu diễn giao diện, hợp đồng và thành phần dưới dạng ngôn ngữ đặc tả, và làm rõ những vấn đề được trình bày thông qua việc xem xét một ví dụ về hệ thống hỗ trợ bán hàng trong siêu thị. 2 CHƯƠNG 1. KHÁI QUÁT VỀ PHÁT TRIỂN HỆ THỐNG DỰA TRÊN THÀNH PHẦN 1.1 Tiến trình công nghệ phần mềm dựa trên thành phần Công nghệ phần mềm dựa trên thành phần (CBSE – Component Based Software Engineering) là một tiến trình nhấn mạnh tới thiết kế và xây dựng hệ thống dựa trên máy tính bằng việc dùng các “thành phần” phần mềm dùng lại được. Về bề ngoài, CBSE dường như hoàn toàn tương tự với công nghệ phần mềm hướng đối tượng. Tiến trình này bắt đầu khi tổ phần mềm thiết lập yêu cầu cho hệ thống được xây dựng bằng việc dùng các kĩ thuật thu thập yêu cầu, sau đó thiết kế kiến trúc được thiết lập nhưng thay vì đi ngay vào các nhiệm vụ thiết kế chi tiết, thì lại xem xét các yêu cầu để xác định những gì trực tiếp chịu trách nhiệm cho việc hợp thành, thay vì xây dựng mới. Tức là, tổ phần mềm đưa ra những câu hỏi sau cho từng yêu cầu hệ thống:  Các thành phần đã được cung cấp (COTS - commercial off the shelf) có sẵn cho việc thực hiện yêu cầu hay không?  Các thành phần dùng lại được phát triển trước đây có sẵn để thực hiện yêu cầu hay không?  Giao diện cho các thành phần có sẵn có tương hợp với kiến trúc của hệ thống cần được xây dựng hay không? Tiến trình CBSE phải được đặc trưng theo cách không chỉ nhận diện ra các thành phần ứng cử viên mà còn định lượng từng giao diện của các thành phần, thích ứng các thành phần để loại bỏ sự không tương thích với kiến trúc, lắp ráp các thành phần vào trong một kiểu cách kiến trúc đã được lựa chọn, và cập nhật các thành phần theo yêu cầu thay đổi của hệ thống. Mô hình tiến trình cho công nghệ phần mềm dựa trên thành phần nhấn mạnh vào các việc song song mà theo đó công nghệ miền được sử dụng đồng thời với việc phát triển dựa trên thành phần [1, 3]. Nội dung của công nghệ miền là xác định, xây dựng, phân loại và phát hiện một tập các thành phần phần mềm có khả năng ứng dụng vào việc phát triển phần mềm hiện tại và tương lai trong miền ứng dụng đặc biệt. Mục tiêu tổng thể là thiết lập những cơ chế làm cho người kĩ sư phần mềm chia sẻ những thành phần này, dùng lại chúng trong khi làm việc với hệ thống mới và hệ thống hiện có. 3 Hình 1.1 minh họa cho mô hình tiến trình CBSE điển hình. Công nghệ miền tạo ra mô hình của miền ứng dụng được dùng làm cơ sở cho việc phân tích yêu cầu người dùng trong luồng công nghệ phần mềm, và sau khi các thành phần dùng lại đã được mua, được chọn từ thư viện hiện có, hay được xây dựng (như một phần việc của công nghệ miền), chúng được trở thành công cụ đã sẵn sàng cho người kĩ sư phần mềm trong việc phát triển hệ thống dựa trên thành phần. Hình 1.1 Mô hình tiến trình hỗ trợ CBSE Các bước trong tiến trình tiếp cận tổng thể tới việc phân tích miền được xác định là:      Định nghĩa miền được khảo sát. Phân loại các yếu tố được trích ra từ miền. Thu thập mẫu đại diện của các ứng dụng trong miền. Phân tích từng ứng dụng trong mẫu. Phát triển mô hình phân tích cho các mẫu. 4 Điều quan trọng cần lưu ý là việc phân tích miền được áp dụng cho bất kỳ mô thức công nghệ phần mềm nào và có thể được áp dụng tốt cho cả việc phát triển hướng đối tượng. Prieto-Diaz mở rộng bước phân tích miền thứ hai trong công nghệ miền nêu trên [1], và gợi ý cách tiếp cận tám bước tới việc xác định và phân loại các thành phần dùng lại như sau: (1) Lựa các chức năng hay sự vật đặc thù. (2) Trừu tượng hoá chức năng hay sự vật. (3) Xác định phân loại. (4) Định danh các tính năng chung. (5) Định danh các quan hệ đặc biệt. (6) Trừu tượng hoá các quan hệ. (7) Suy dẫn ra mô hình chức năng. (8) Định nghĩa ngôn ngữ miền. Đôi khi khó xác định được rằng liệu với một thành phần dùng lại tiềm năng nào đó trong thực tế có áp dụng được cho một tình huống đặc biệt hay không. Để tiến hành việc xác định này, cần phải định nghĩa ra một tập các đặc trưng miền được dùng chung cho mọi phần mềm bên trong một miền. Đặc trưng miền định nghĩa ra thuộc tính chung nào đó cho mọi sản phẩm tồn tại trong miền đó, chẳng hạn, các đặc trưng chung có thể là tầm quan trọng của tính an toàn, tính tin cậy, ngôn ngữ lập trình, tương tranh trong xử lí, và nhiều điều khác nữa. 1.2 Phát triển hệ thống dựa trên thành phần Phát triển dựa trên thành phần là hoạt động CBSE xuất hiện song song với công nghệ miền. Bằng việc dùng các phương pháp phân tích và thiết kế kiến trúc, tổ phần mềm làm mịn kiến trúc thích hợp cho mô hình phân tích đã được tạo ra cho ứng dụng được xây dựng. Một khi kiến trúc đã được thiết lập, nó phải đưa các thành phần vào. Các thành phần này là có sẵn từ thư viện dùng lại hoặc được chế tạo mới để đáp ứng nhu cầu riêng biệt này. Do đó, luồng nhiệm vụ cho việc phát triển hệ thống dựa trên thành phần có hai việc song song như ở hình 1.1. Khi các thành phần dùng lại được là có sẵn cho việc tích hợp tiềm năng vào trong kiến trúc, thì chúng phải được định tính và thích nghi. Khi thành phần mới cần tới, thì chúng phải 5 được chế tạo. Sau đó chúng được tích hợp vào trong kiến trúc và được kiểm thử kĩ càng. 1.2.1 Định phẩm, thích ứng và hợp thành thành phần Như ta đã thấy, công nghệ miền cung cấp thư viện các thành phần dùng lại được cần cho công nghệ phần mềm dựa trên thành phần. Một số trong những thành phần dùng lại được này được phát triển bởi đội ngũ sở tại, số khác có thể được trích từ những ứng dụng đã có, và số khác nữa thì có thể kiếm được từ bên thứ ba. Tuy nhiên sự tồn tại của các thành phần dùng lại được không đảm bảo rằng các thành phần này có thể được tích hợp một cách dễ dàng hay hiệu quả vào kiến trúc được chọn cho ứng dụng mới. Chính bởi lí do này mà trình tự các hoạt động phát triển dựa trên thành phần được áp dụng khi một thành phần được đề nghị sử dụng. Định phẩm thành phần: Định phẩm thành phần đảm bảo rằng một thành phần ứng cử viên sẽ thực hiện chức năng được yêu cầu, sẽ “khớp” đúng vào phong cách kiến trúc đã xác định cho hệ thống, và sẽ phải có các đặc trưng phẩm chất (như hiệu năng, độ tin cậy, tính sẵn sàng) cần cho ứng dụng. Mô tả giao diện cung cấp thông tin có ích về thao tác và sử dụng thành phần phần mềm, nhưng nó không cung cấp tất cả các thông tin cần để xác định xem một thành phần được đề nghị trong thực tế có dùng lại được một cách có hiệu quả trong ứng dụng mới hay không. Dưới đây là một số nhân tố được xem xét khi định phẩm thành phần:  Giao diện lập trình ứng dụng (API).  Các công cụ phát triển và tích hợp được thành phần cần tới.  Các yêu cầu khi chạy, kể cả việc dùng tài nguyên (như bộ nhớ hay lưu trữ), thời gian hay tốc độ, và giao thức mạng.  Tính năng an toàn, kể cả kiểm soát truy nhập và giao thức xác minh.  Các giả thiết thiết kế nhúng.  Giải quyết các trường hợp ngoại lệ. Thích ứng thành phần: Trong trường hợp lí tưởng, công nghệ miền tạo ra một thư viện các thành phần mà có thể dễ dàng được tích hợp vào kiến trúc ứng dụng. Điều ngụ ý “dễ tích hợp” là ở chỗ: 6  Các phưong pháp nhất quán về quản lý tài nguyên đã được thực hiện cho mọi thành phần trong thư viện.  Các hoạt động chung như quản lí dữ liệu đã có cho mọi thành phần.  Giao diện bên trong kiến trúc và với môi trường bên ngoài đã được thực hiện theo cách nhất quán. Trong thực tế, ngay sau khi thành phần đã được định phẩm để dùng bên trong một kiến trúc ứng dụng, thì nó có thể bộc lộ ra những xung đột không tương thích với một hay nhiều vùng phải được chú ý. Để làm giảm bớt những xung khắc này, một kĩ thuật thích ứng được gọi là bọc gói thành phần [1, 3] thường được sử dụng. Khi tổ phần mềm đã có quyền truy nhập hoàn toàn vào thiết kế bên trong và mã cho thành phần (thường không phải là trường hợp khi thành phần COTS được dùng) thì việc bọc gói hộp trắng sẽ được áp dụng. Giống như phần tương ứng của nó trong kiểm thử phần mềm, bọc gói hộp trắng xem xét các chi tiết xử lí bên trong của thành phần này và làm những thay đổi mức mã để loại bỏ các xung khắc. Bọc gói hộp xám được áp dụng khi thư viện thành phần được cung cấp một một ngôn ngữ mở rộng thành phần hay API có khả năng loại bỏ hay che mặt nạ cho các xung khắc. Bọc gói hộp đen đòi hỏi đưa vào tiền và hậu xử lí tại giao diện thành phần để loại bỏ hay làm mặt nạ cho các xung khắc. Tổ phần mềm phải xác định xem liệu nỗ lực được yêu cầu bao gói thích hợp thành phần có thể được thực hiện không hay là thành phần chuyên biệt hoá (được thiết kế để khử bỏ xung khắc gặp phải) nên được chế tạo ra. Hợp thành thành phần: Nhiệm vụ hợp thành thành phần là lắp ráp các thành phần đủ phẩm chất, đã thích ứng hay đã chế tạo vào kiến trúc đã thiết lập cho ứng dụng. Để thực hiện điều này, phải thiết lập một kết cấu nền để gắn các thành phần thành một hệ thống vận hành. Kết cấu nền này (thường là thư viện các thành phần đã khu biệt hoá) đưa ra một mô hình cho việc điều phối các thành phần lẫn nhau và thực hiện các nhiệm vụ chung. Trong số nhiều cơ chế để tạo ra một kết cấu nền hiệu quả thì tập bốn “chất liệu kiến trúc” cần có để đạt tới việc hợp thành thành phần là:  Mô hình trao đổi dữ liệu. Cơ chế để người dùng và ứng dụng có khả năng tương tác và truyền dữ liệu (như kéo và thả, cắt và dán) nên được định nghĩa cho mọi thành phần dùng lại. Cơ chế trao đổi dữ liệu này không chỉ cho phép việc truyền dữ liệu người - phần mềm và thành phần - thành phần mà còn truyền giữa các tài nguyên hệ thống (như kéo một tệp sang biểu tượng máy in để in ra). 7  Tự động hoá. Nhiều loại công cụ, macro và script nên được cài đặt để làm thuận tiện cho tương tác giữa các thành phần dùng lại.  Lưu trữ có cấu trúc. Dữ liệu không thuần nhất (như dữ liệu đồ hoạ, tiếng nói, video, văn bản và số) chứa trong “tài liệu hợp thành” nên được tổ chức và truy nhập như một cấu trúc riêng lẻ, thay vì một tuyển tập các tệp tách biệt. Dữ liệu có cấu trúc duy trì một mô tả cho các cấu trúc lồng nhau mà ứng dụng có thể tự do uốn nắn để định vị, tạo ra hay sửa đổi từng nội dung dữ liệu.  Mô hình đối tượng nền. Mô hình đối tượng đảm bảo rằng các thành phần được phát triển trong các ngôn ngữ lập trình khác nhau nằm ở các nền khác nhau có thể liên tác được. Tức là, các đối tượng phải có khả năng trao đổi qua mạng. Để làm được điều này, mô hình đối tượng định nghĩa ra một chuẩn cho tính liên tác thành phần. Do tác động tiềm năng của việc dùng lại và vai trò của CBSE đối với nền công nghiệp phần mềm là cực kì lớn, nên một số công ty chính và các liên đoàn công nghiệp đã đề nghị các chuẩn cho phần mềm thành phần [1], bao gồm:  OMG/CORBA. Nhóm quản lí đối tượng Object Management Group (OMG) đã công bố kiến trúc trung gian yêu cầu đối tượng chung (CORBA - common object request broker architectures). Một đối tượng trung gian yêu cầu sự vật (ORB) cung cấp nhiều thứ về các dịch vụ làm cho các thành phần dùng lại (đối tượng) có khả năng trao đổi với các thành phần khác, bất kể tới vị trí của chúng trong hệ thống. Khi các thành phần được xây dựng có dùng chuẩn OMG/CORBA, thì việc tích hợp các thành phần đó bên trong hệ thống được đảm bảo nếu có một ngôn ngữ định nghĩa giao diện (IDL) được tạo ra cho mọi thành phần. Bằng việc dùng mô hình client/server, các đối tượng bên trong ứng dụng khách có thể yêu cầu một hay nhiều dịch vụ từ nguồn phục vụ ORB. Các yêu cầu được thực hiện qua một IDL hay theo cách động vào lúc chạy, và một kho giao diện chứa tất cả các thông tin cần thiết, dịch vụ yêu cầu và dịch vụ đáp ứng.  Microsoft COM. Microsoft đã phát triển một mô hình đối tượng thành phần (COM – component object model) cung cấp đặc tả cho việc dùng các thành phần do nhiều nhà sản xuất tạo ra trong một ứng dụng chạy dưới hệ điều hành Windows. COM bao gồm hai phần tử: giao diện COM và một tập hợp cơ chế để đăng kí và truyền thông báo giữa các giao diện COM. Theo quan điểm ứng dụng, sự quan tâm không phải là 8 cách các đối tượng COM được cài đặt, mà chỉ tập trung vào sự kiện đối tượng có một giao diện mà nó đăng kí với hệ thống, và nó dùng hệ thống thành phần này để trao đổi các sự vật COM khác.  Sun JavaBean. Hệ thống thành phần JavaBean là kết cấu nền CBSE độc lập, khả chuyển, đã được phát triển bằng việc dùng ngôn ngữ lập trình Java. Hệ thống JavaBean mở rộng tiện ích Java cho phù hợp với các thành phần phần mềm phức tạp hơn được yêu cầu cho việc phát triển dựa trên thành phần. Hệ thống thành phần JavaBean bao gồm một tập các công cụ, được gọi là Bean Development Kit (BDK), cho phép phát triển, phân tích cách các thành phần Bean làm việc, chuyên biệt hoá hành vi và dáng vẻ của chúng, thiết lập cơ chế điều phối và trao đổi, phát triển các Bean chuyên biệt để dùng trong ứng dụng đặc biệt và kiểm thử, đánh giá hành vi Bean. Có thể thấy, vào thời điểm này chưa có câu trả lời cho thấy chuẩn nào trong số các chuẩn trên sẽ chi phối nền công nghiệp phần mềm. Mặc dầu nhiều nhà phát triển đã chuẩn hoá theo một trong các chuẩn này, nhưng rất có thể là các tổ chức phần mềm lớn có thể chọn dùng tất cả các chuẩn đó, tuỳ theo loại ứng dụng và nền phát triển được dùng. 1.2.2 Chế tạo thành phần Tiến trình CBSE khuyến khích việc dùng thành phần phần mềm hiện có. Tuy nhiên, điều không tránh được là có những lúc cần phải chế tạo thành phần. Tức là thành phần phần mềm mới phải được phát triển và tích hợp bằng COTS có sẵn và thành phần tự làm. Bởi vì những thành phần mới này trở thành thành viên của thư viện thành phần dùng lại của cơ quan sở tại, nên chúng được phải chế tạo để dùng lại. Không có gì quá khó về việc tạo ra thành phần phần mềm có thể được dùng lại. Các khái niệm thiết kế như trừu tượng hoá, che giấu, độc lập chức năng, làm mịn và lập trình có cấu trúc, cùng với phương pháp hướng đối tượng, kiểm thử, SQA, kiểm chứng tính đúng đắn, tất cả đều đóng góp cho việc tạo ra thành phần phần mềm dùng lại được. Chúng ta sẽ không xét lại những điểm đó mà thay vì thế chúng ta xem xét vấn đề chuyên về dùng lại để bổ sung cho công nghệ phần mềm thực tế. 1.2.3 Phân tích và thiết kế cho dùng lại Các mô hình dữ liệu, chức năng và hành vi (được biểu diễn trong nhiều kí pháp khác nhau) có thể được tạo ra để mô tả cho một ứng dụng đặc biệt phải 9 thực hiện những gì, do đó những đặc tả được dùng để mô tả cho các mô hình này. Mô tả đầy đủ cho yêu cầu là kết quả của việc phân tích, mô hình được phân tích để xác định những yếu tố đó của mô hình, nhằm trỏ tới các thành phần phần mềm dùng lại được. Vấn đề là trích ra thông tin từ các yêu cầu mô hình dưới dạng có thể đưa tới tầm “sánh đúng đặc tả”. Nếu việc so sánh đúng cho lại các thành phần khớp với nhu cầu của ứng dụng hiện tại, thì người thiết kế có thể lấy ra các thành phần này từ thư viện dùng lại và dùng chúng trong thiết kế hệ thống mới. Nếu thành phần thiết kế không tìm được, thì kỹ sư phần mềm phải áp dụng phương pháp thiết kế để tạo ra chúng. Chính tại điểm này, khi người thiết kế bắt đầu tạo ra thành phần mới, thì thiết kế cho dùng lại cần được xét tới. Thiết kế cho dùng lại đòi hỏi người kỹ sư phần mềm phải áp dụng các khái niệm và nguyên tắc thiết kế. Nhưng đặc trưng của miền ứng dụng cũng phải được xem xét tới. Một số vấn đề mấu chốt tạo nên cơ sở cho thiết kế dùng lại là:  Dữ liệu chuẩn. Miền ứng dụng nên được nghiên cứu và các cấu trúc dữ liệu toàn cục chuẩn (như cấu trúc tệp hay cơ sở dữ liệu đầy đủ) nên được nhận diện. Tất cả các thành phần thiết kế có thể được đặc trưng để dùng các cấu trúc dữ liệu chuẩn này.  Giao thức giao diện chuẩn. Ba mức của giao thức giao diện chuẩn nên được thiết lập: bản chất của giao diện giữa các môđun, thiết kế giao diện kĩ thuật ngoài, và giao diện người/máy.  Tiêu bản chương trình. Mô hình kiến trúc hiện tại có thể làm tiêu bản cho thiết kế kiến trúc của chương trình mới. Một khi dữ liệu chuẩn, giao diện và tiêu bản chương trình đã được thiết lập, thì người thiết kế có một khuôn khổ để theo đó tạo ra thiết kế. Các thành phần mới tuân theo khuôn khổ này có tính khả chuyển cao cho việc dùng lại về sau. 1.2.4 Phân loại và tìm kiếm thành phần Ta hãy xét một thư viện đại học, với số lượng lớn các sách, tạp chí và những nguồn thông tin khác đều có sẵn cho việc sử dụng. Nhưng để truy nhập vào thư viện đó, cần phải xây dựng một lược đồ danh mục. Để tìm kiếm trong khối lượng lớn thông tin này, thủ thư đã định nghĩa ra một lược đồ phân loại bao gồm cả mã phân loại, từ khoá, tên tác giả và các chỉ mục khác. Tất cả đều tạo khả năng cho người dùng tìm ra nguồn tài liệu cần thiết một cách nhanh chóng và dễ dàng. 10 Bây giờ, ta hãy xét một kho thành phần lớn với nhiều thành phần phần mềm dùng lại nằm trong nó. Nhưng làm sao người kĩ sư phần mềm tìm được thành phần mình cần? Để trả lời câu hỏi này, một câu hỏi mới nảy sinh: Làm sao chúng ta có thể mô tả các thành phần phần mềm theo thuật ngữ không mơ hồ, có thể phân loại được? Đây là những câu hỏi khó, và còn chưa có câu trả lời xác định. Ở đây chúng ta xem xét xu hướng hiện nay mà có thể giúp người kĩ sư phần mềm tìm kiếm được thành phần cần thiết qua các thư viện thành phần dùng lại. Mô tả thành phần dùng lại được: Thành phần phần mềm dùng lại có thể được mô tả theo nhiều cách, nhưng một mô tả lý tưởng bao gồm ba điều được gọi là mô hình 3C (concept, content, context – khái niệm, nội dung, hoàn cảnh).  Khái niệm về một thành phần phần mềm là “một mô tả về điều thành phần thực hiện, tức là mô tả chức năng”. Giao diện cho thành phần được mô tả đầy đủ về mặt cú pháp còn ngữ nghĩa được biểu diễn bằng nhiều phương pháp, hình thức nhưng phổ biến là bên trong ngữ cảnh của tiền và hậu điều kiện. Khái niệm nên truyền đạt ý định của thành phần.  Nội dung của thành phần mô tả ngữ nghĩa cho cách mà các khái niệm được thực hiện. Về bản chất, nội dung là thông tin được giấu kín với người dùng bình thường và chỉ cần được biết tới đối với những người có ý định thay đổi hay kiểm thử thành phần.  Hoàn cảnh đặt thành phần phần mềm dùng lại được vào trong miền ứng dụng của nó. Tức là, bằng việc xác định các tính năng khái niệm, vận hành và thực hiện, hoàn cảnh làm cho người kĩ sư phần mềm có khả năng tìm ra thành phần thích hợp để đáp ứng các yêu cầu ứng dụng. Để dùng trong thực tế, thì khái niệm, nội dung và hoàn cảnh phải được chuyển thành lược đồ đặc tả cụ thể. Các phương pháp được đề nghị có thể được phân loại thành ba vùng chính: các phương pháp thư viện và khoa học thông tin, các phương pháp trí tuệ nhân tạo, hệ thống siêu văn bản. Đại đa số công việc được thực hiện cho tới nay đều gợi ý việc dùng phương pháp khoa học thư viện cho phân loại thành phần. Hình 1.2 giới thiệu một phân loại theo phương pháp chỉ số khoa học thư viện. Các từ vựng chỉ số có kiểm soát giới hạn các thuật ngữ hay cú pháp có thể được dùng để phân loại thành phần. Từ vựng chỉ số không kiểm soát thì không đặt 11 hạn chế nào vào bản chất của mô tả. Đa số các lược đồ phân loại cho thành phần phần mềm đều rơi vào trong ba loại: phân loại liệt kê, phân loại nhiều mặt, phân loại giá trị - thuộc tính. Hình 1.2 Phân loại về phương pháp tạo chỉ số Môi trường dùng lại: Việc dùng lại thành phần phần mềm phải được hỗ trợ bởi một môi trường bao gồm các yếu tố sau:  Một cơ sở dữ liệu thành phần có khả năng cất giữ các thành phần phần mềm và thông tin phân loại cần thiết để tìm lại chúng.  Một hệ quản trị thư viện cung cấp việc truy nhập vào cơ sở dữ liệu này.  Một hệ thống tìm kiếm thành phần phần mềm làm cho ứng dụng khách có khả năng tìm lại các thành phần và dịch vụ từ nguồn phục vụ thư viện.  Công cụ CBSE hỗ trợ cho việc tích hợp các thành phần được dùng lại vào thiết kế hay cài đặt mới. 1.3 Mô hình vòng đời tiến trình dựa trên thành phần CBSE chú tâm vào những thách thức tương tự trong kỹ nghệ phần mềm thông thường. Nhiều phương pháp, công cụ và nguyên lý của kỹ nghệ phần mềm sử dụng trong các hệ thống khác nhau cũng được dùng với cách tương tự hoặc có chút đổi khác trong CBSE. Cho dù có sự khác biệt nhưng CBSE rõ ràng 12 tập trung vào các câu hỏi liên quan đến thành phần và nó phân biệt tiến trình của “phát triển thành phần” so với “phát triển hệ thống dựa trên thành phần”. Ý tưởng chính của tiếp cận dựa trên thành phần là xây dựng hệ thống từ những thành phần đã tồn tại trước đó. Đầu tiên, các tiến trình phát triển hệ thống dựa trên thành phần là tách biệt khỏi các tiến trình phát triển thành phần; các thành phần đã phải được phát triển và sẵn sàng có thể sử dụng trong những sản phẩm khác nhau khi tiến trình phát triển hệ thống khởi động. Thứ hai, một tiến trình riêng biệt sẽ xuất hiện, đó là tìm kiếm và đánh giá các thành phần. Thứ ba, các hoạt động trong các tiến trình sẽ khác với các hoạt động trong sự tiếp cận không dựa trên thành phần; với phát triển hệ thống, sự quan tâm là tìm những thành phần phù hợp và thẩm định chúng, đồng thời với sự phát triển thành phần, thiết kế để sử dụng lại sẽ là mối quan tâm chủ yếu. Phát triển hệ thống với thành phần tập trung vào sự nhận biết các thực thể có thể dùng lại và mối quan hệ giữa chúng, bắt đầu từ các yêu cầu hệ thống và từ các thành phần đã tồn tại, đã sẵn sàng sử dụng. Nhiều nỗ lực thực hiện trong phát triển hệ thống sẽ không còn quá nặng nhọc trừ nỗ lực giải quyết yêu cầu đối với các thành phần, định vị chúng, lựa chọn những thành phần thích hợp nhất, kiểm thử chúng và cứ thế phát triển hệ thống tăng dần. Những khác biệt này có thể được xem xét một cách chi tiết hơn ở hình 1.3 chỉ ra mô hình chữ V được dùng trong sự tiếp cận dựa trên thành phần. Mô hình chữ V được sử dụng rộng rãi trong nhiều tổ chức, tiêu biểu là xây dựng các sản phẩm phức tạp, dùng trong thời gian dài, như là xe hơi hoặc robot. Trong những mô hình này, tiến trình bắt đầu theo cách thông thường bởi các yêu cầu kỹ nghệ và các yêu cầu đặc tả theo sự đặc tả hệ thống. Trong sự tiếp cận không dựa trên thành phần, tiến trình sẽ tiếp tục với thiết kế đơn vị, thực thi và kiểm thử. Thay vì thực hiện những hoạt động này một cách thường xuyên, thì CBSE đơn giản là lựa chọn những thành phần thích hợp và tích hợp chúng vào hệ thống. Tuy nhiên, có hai vấn đề nảy sinh: thành phần để lựa chọn là không rõ ràng, và thành phần đã chọn chỉ thích hợp một phần với thiết kế tổng thể. Thực tế đầu tiên chỉ ra rằng chúng ta phải có một tiến trình để tìm kiếm các thành phần, tiến trình này gồm các hoạt động cho tìm kiếm và đánh giá các thành phần. Thực tế thứ hai cho biết sự cần thiết một thành phần được chấp nhận và kiểm thử trước khi nó được tích hợp vào hệ thống, và tất nhiên nó là một tiến trình của sự phát triển thành phần, độc lập với tiến trình phát triển hệ thống. 13 Hình 1.3 Tiến trình phát triển chữ V cho phát triển dựa trên thành phần Hình 1.3 vẫn chỉ ra một tiến trình đơn giản và lý tưởng hóa. Nó giả sử rằng các thành phần được chọn và được sử dụng là đầy đủ, thích đáng, gần với các đơn vị được xác nhận trong tiến trình thiết kế, cũng là thích hợp với những yêu cầu, và sẽ làm giảm công sức thực hiện của các đơn vị. Bây giờ, chúng ta sẽ xem xét các hoạt động tại các pha khác nhau trong tiến trình phát triển một cách chi tiết hơn như sau: Phân tích và đặc tả yêu cầu: Ở pha này, một hoạt động quan trọng là phân tích những gì có thể và xác nhận những giải pháp đáp ứng những đòi hỏi này. Trong sự tiếp cận dựa trên thành phần điều này là cần thiết để phân tích xem những yêu cầu này là có được hay không, có thể đáp ứng bởi những thành phần sẵn có hay không. Điều này có nghĩa rằng các yêu cầu phải được nhận biết bởi các thành phần có thể được sử dụng. Từ đó, không phải rằng các thành phần thích hợp có thể luôn được tìm thấy, và khi đó các thành phần mới phải được bổ sung. Để giữ sự tiếp cận dựa trên thành phần và tận dụng những thuận lợi của nó thì có thể dàn xếp bằng cách sửa đổi các yêu cầu và làm cho chúng có thể sử dụng những thành phần đang tồn tại. Thiết kế hệ thống: Giống như pha đặc tả các yêu cầu, thiết kế và đặc tả hệ thống là quan hệ chặt chẽ với những thành phần đã có. Những thành phần tiềm năng tuân theo một mô hình thành phần riêng biệt, trên lý thuyết thì có thể sử dụng những thành phần được thực hiện trong các công nghệ thành phần khác, nhưng trong thực tế rất khó để đạt được kết quả giữa những mô hình thành phần 14 khác nhau. Mô hình thành phần thực hành đòi hỏi một mẫu kiến trúc thực hành, và điều này ảnh hưởng đến các quyết định kiến trúc. Thí dụ, nếu mô hình thành phần đòi hỏi một kiểu kiến trúc client/server, thì thật là rõ ràng rằng ứng dụng sẽ dùng kiểu đó và không dùng kiểu khác. Điều này sẽ đặt sự giới hạn lên thiết kế hệ thống, những tính chất khác của các thành phần có thể có một ảnh hưởng trực tiếp lên các quyết định thiết kế. Vì lý do này, tiến trình thiết kế là được kết nối chặt chẽ tới tính sẵn sàng của thành phần. Thực thi và kiểm thử đơn vị: Khi xây dựng hệ thống dựa trên thành phần, một trường hợp lý tưởng là xây dựng một ứng dụng bằng sự tích hợp, kết nối trực tiếp các thành phần. “Mã lệnh gắn kết” (glue code) là mã lệnh đặc tả kết nối này. Trong thực tế triển khai, vai trò của mã lệnh gắn kết cũng sẽ bao gồm sự kết nối của các thành phần, và cả sự thực thi của các hàm chức năng mới. Trong một trường hợp lý tưởng là các thành phần đã được xây dựng sẵn sàng và đã được kiểm thử, tuy nhiên thành phần kiểm thử trong môi trường cô lập là không đủ. Thông thường thiết kế các đơn vị sẽ được thi hành như sự lắp ghép của vài thành phần và có thể với một mã lệnh gắn kết. Các sự gắn kết này phải được kiểm thử tách biệt nhau, vì một sự gắn kết đúng các thành phần có thể không đúng mặc dù từng thành phần là đúng. Tích hợp hệ thống: Tiến trình tích hợp bao gồm sự tích hợp các thành phần kiến trúc cơ bản chuẩn, xây dựng một thành phần khung và các thành phần ứng dụng. Sự tích hợp của một thành phần đơn lẻ vào một hệ thống được gọi là triển khai thành phần. Trong một cách khác để tích hợp toàn bộ hệ thống, một sự triển khai thành phần là một kỹ thuật để tích hợp các thành phần đơn lẻ, nó gồm việc kết nạp và đăng ký của thành phần. Xác minh và thẩm định hệ thống: Kiểm thử chuẩn mực và kỹ thuật xác minh được dùng ở đây. Vấn đề đặc tả cho tiếp cận dựa trên thành phần là vị trí của lỗi, đặc biệt khi các thành phần là kiểu hộp đen và được phân phối từ các bên khác nhau. Thông thường, một thành phần có thể lộ ra một lỗi, nhưng nguyên nhân của sự cố lại nằm ở những thành phần khác. Các giao diện hợp đồng thực hiện một vai trò quan trọng trong sự kiểm tra sự đúng đắn của đầu vào và đầu ra từ các thành phần. Các giao diện này cho phép một sự đặc tả của đầu vào, đầu ra và kiểm tra tính đúng đắn của dữ liệu. Hỗ trợ hoạt động và bảo trì: Tiến trình bảo trì bao gồm vài bước tương tự như tiến trình tích hợp: một thành phần mới hoặc đã chỉnh sửa được triển khai trong hệ thống. Nó cũng có thể cần thay đổi mã lệnh gắn kết. Hầu hết các trường hợp là một thành phần đang tồn tại sẽ được chỉnh sửa hoặc một phiên bản mới 15 của thành phần tương tự sẽ được tích hợp vào hệ thống. Khi đó lại xuất hiện những vấn đề mới bởi sự không tương thích giữa các thành phần, hoặc bởi các sự phụ thuộc giữa chúng bị đứt gãy. Điều này có nghĩa là, hệ thống cần phải được xác minh lại lần nữa (hoặc là bằng phương pháp hình thức, hoặc là mô phỏng, hoặc là kiểm thử). Hình 1.4 Mô hình chữ V chi tiết của tiến trình phát triển dựa trên thành phần Trong sự so sánh với các tiếp cận không dựa trên thành phần, một tiến trình phát triển dựa trên thành phần giúp giảm bớt đáng kể công việc trong lập trình, nhưng trong xác minh và kiểm thử đòi hỏi nhiều công sức hơn. Hoạt động xác minh lặp lại trong vài pha, với sự khác nhau chút ít về mục tiêu là: xác minh thành phần trong sự cô lập, xác minh các thành phần trong sự ghép nối, xác minh hệ thống khi một thành phần được triển khai trong hệ thống. 16 CHƯƠNG 2. MÔ HÌNH THÀNH PHẦN 2. 1 Cơ sở cho mô hình thành phần Ở những năm 70, một phương pháp lập trình mới được giới thiệu, đó là phương pháp lập trình làm tăng hiệu suất của các lập trình viên và trở thành một phương pháp kinh điển. Phương pháp này được biết đến với tên phương pháp lập trình có cấu trúc và nó vẫn được sử dụng cho đến bây giờ để viết các module chương trình nhỏ. Cũng ở thời điểm này một nhóm ở Pháp giới thiệu một ngôn ngữ mẫu để hỗ trợ lập trình có cấu trúc gọi là EXCEL [6]. Một chương trình trong EXCEL được xem là một hộp đen với một đầu vào duy nhất và một đầu ra duy nhất. Một nhiệm vụ cơ bản ứng với một hộp đen đơn thể, còn một hộp đen hợp thành được xây dựng từ những hộp đen khác sử dụng cấu trúc ghép tuần tự “;”, cấu trúc rẽ nhánh có điều kiện “IF-THEN-ELSE-FI” và cấu trúc lặp “DOOD”. Ngôn ngữ lập trình cấu trúc là không phù hợp cho sự phát triển công nghệ thông tin hiện tại, khi mà hệ thống phần mềm là trưởng thành nhanh cả về giới hạn của kích thước và độ phức tạp, điều này cần những kỹ thuật lập trình phải tốt hơn tính module, nó cần phải hỗ trợ tính dùng lại và tính kết hợp. Tuy nhiên, vẫn có nhiều điều có thể học được từ phương pháp lập trình cấu trúc để áp dụng cho sự phát triển một mô hình thành phần:  Một hộp đen trong EXCEL là một dịch vụ chức năng theo lý thuyết với điều kiện trước (precondition) và điều kiện sau (post condition) có thể được dùng lại trong một chương trình khác.  Một phương pháp cấu trúc cho sự xây dựng một dịch vụ phức tạp hơn từ những dịch vụ khác nhỏ hơn. Chúng ta không xem một hộp đen trong EXCEL được coi như một thành phần bởi vì nó chia sẻ các biến chương trình với toàn bộ các hộp đen khác của chương trình, điều này có nghĩa là nó gây cản trở và phụ thuộc quá nhiều vào môi trường, thêm nữa nó không hỗ trợ tính dùng lại. Chúng ta muốn các hộp đen phải độc lập hơn. Để phục vụ mục đích này, chúng ta thử chia các biến chương trình thành các nhóm và phân tán chúng giữa các hộp đen bằng cách nhóm các biến được sử dụng nhiều bởi các câu lệnh trong một hộp đen sẽ được định vị trong hộp, và các hộp có cùng nhóm biến sẽ được kết hợp cùng nhau tới một module với vài chức năng hành động trên tập các biến giống nhau, sắp xếp lại các hộp đen, giữ các kết nối giống nhau. Cách nhóm các hộp này không làm 17 thay đổi ngữ nghĩa của chương trình, nhưng tạo ra một cách mới cho sự module hóa, mỗi module được tăng cường sự tự trị (xem hình 2.1). Tóm lại, một module được tạo ra bằng cách có: các biến, vài hàm, các cổng vào, các cổng ra, các cổng vào trung gian, và các cổng ra trung gian. Hình 2.1 Từ các hộp EXCEL đến các thành phần Các cổng vào và ra trung gian là cho trường hợp một dịch vụ hỗn hợp có vài dịch vụ con được định vị trong những module khác nhau và luồng điều khiển (được biểu diễn như cách cạnh trực tiếp) đi ra từ module và sau cùng quay trở lại. Thuận lợi chính của loại module này là chúng có thể được dùng trong một hệ thống theo kiểu “plug and play”, và kể từ đây chúng được gọi là các thành phần. Các biến, các hàm, các cổng của chúng hình thành nên giao diện (interface) của thành phần. Do đó, giao diện thành phần là một phần tử có cú pháp mới được sử dụng trong một ngôn ngữ hỗ trợ lập trình thành phần. Để dùng lại một thành phần, một điều cần biết là thành phần làm những gì. Cho nên, một đại lượng được dùng để trình bày thuộc tính của biến (như kiểu của chúng và giá trị khởi tạo), và các điều kiện trước (pre-condition), điều kiện sau (post-condition) cho những hàm của nó (ở tại các cổng vào và ra) phải được cung cấp với giao diện của nó. Các cổng trung gian được kết nối tới các hàm tương ứng với các hộp đen con của nó để thành phần hoạt động đúng đắn. Các cổng trung gian này và các hàm tương ứng của chúng được gọi là “giao diện yêu cầu” (required interface) và sự đặc tả những hàm này cần phải được cung cấp với giao diện. Sự đặc tả các hàm của một thành phần hình thành nên khái niệm “hợp đồng” (contract) của thành phần. 18 Chúng ta phải đi tới việc làm rõ những khái niệm của thành phần, giao diện và hợp đồng của chúng. Thành phần có cấu trúc đơn giản với các lớp trong lập trình hướng đối tượng, nhưng có giao diện rõ ràng, chức năng cần mở rộng cho một thành phần là rành mạch trong giao diện yêu cầu của thành phần, và điều này làm sự phát triển một thành phần trở nên độc lập hơn so với các thành phần khác. Các khái niệm thành phần, giao diện là quan trọng nhất nhưng vẫn chưa có định nghĩa chung cho hai khái niệm này trong CBSE. Ở phần này, chúng ta sẽ thảo luận những cách nhìn khác nhau như thế nào đối với những khái niệm này để có thể làm cho chúng trở nên thống nhất dưới dạng mô hình toán học [6]. Thành phần: xem trong từ điển Oxford Advanced Learners, chúng ta thấy “một thành phần là bất kỳ phần nào của thứ được tạo ra” [10]. Trong kỹ nghệ phần mềm, điều này sẽ cho phép một hệ thống phần mềm được hiểu như là “các thành phần”: các câu lệnh ngôn ngữ assembly, các thủ tục, các module, các gói phần mềm, các tiến trình, các hệ thống con,...định nghĩa này rõ ràng là quá tổng quát. Để giải quyết những gì được coi là nguyên tắc và những gì ngoài nguyên tắc, chúng ta đầu tiên lọc ra những mục đích sử dụng “các thành phần” trong sự phát triển phần mềm, và sau đó tìm hiểu các ràng buộc liên quan của chúng hoặc những thuộc tính cần thiết. Như đã nói trước, mục đích được chấp nhận chủ yếu của phát triển dựa trên thành phần là để xây dựng và bảo trì hệ thống phần mềm bằng cách sử dụng các thành phần phần mềm đã tồn tại. Nó được hiểu rằng các thành phần là cần có khả năng sử dụng lại, chúng phải tương tác với các thành phần khác trong một kiến trúc hệ thống. Mục tiêu này của CBSE hàm ý 4 tính chất đặc trưng sau đây cho một thành phần thực sự có khả năng dùng lại:  (P1) Hợp đồng đặc tả các giao diện  (P2) Các ngữ cảnh phụ thuộc đầy đủ rõ ràng  (P3) Sự triển khai độc lập  (P4) Tích hợp hãng thứ ba Dựa trên những điều kiện ấy, nó diễn đạt rằng một câu lệnh ngôn ngữ assembly và các gói phần mềm sẽ không được coi như những thành phần, nhưng các lớp trong thư viện lớp là những thành phần. Tuy nhiên, các lớp có thể khó là các thành phần nếu chúng ta đòi hỏi P3 khi sự kết hợp các thành phần không truy cập tới mã nguồn. Một cách khác, chúng ta có thể lấy một lớp để có thể sử