MERSTRASZ & TSICHRn ZIS OBJECT-ORIENTED SOFTWARE COMPOSITION PR EN T IC E-H A LL 1992 CÂU THÀNH PHẦN MỂM HƯỚNG ĐỔI TƯƠNG HÀ NỒI 1998 Mục lục Lời nói đ ầ u I L i giới th iệ u I I Những Icri cảm n " I X ^ 4.^ ^ 1 ' ' ^ X 7 ' o ' ' Chương 3, Tương tác ứng dụng hướng đối tượng ISử dụng lại đối tượng từ môi trường khác 3.2 Tương ĩác hướng thủ tục 3.3 Tương tác hướng đối tượng 3-4 So sánh cách tiếp cận hỗ trợ tương tác 3.5 Tương tác hướng đối tượng-Kết nối giao diện 3.6 Thích nghi giao d iệ n 3.7 ánh xạ đối tư ợng - 3.8 Những kết luận phương pháp nghiẽn cứu w 2 Chương Tương tranh ngòn ngữ lập trình hướng địi tượng, 2.1 Giới thiệu 2.2 Không gian thiết kế 2.3 Tiêu chuẩn đánh giá lựa chọn thiết kế ngôn ngữ 2.4 Khám phá không gian thiết kế ngỏn ngữ 2.5 Kết luậ n I8 一 Chương !• cỏ n g nghệ phần mém hướng thành phần .1 1.1 Lời giới th iê u 1.2 Đối tượng thành phần 1.3 K ỹ thuật hỗ trợ cho thành phần 1.4 Công nghệ thành phần 18 1.5 Kết luân _ " 22 o ^ « L H 1L t i o o o 1 Ỉ 1 li - Ii ỉ ^ ^ C M l u Chương H àm , Bản ghi tính tương thích phép tính 入N 6.1 Giới thiệu 6.2 Phép tính Lambda vói tham số có tên 6.3 Tính tốn lúc thực 6.4 Mối quan hệ tương th ích s Kết l i i A n 60 66 71 7h 1 Chương Phối cảnh thòi gian đối tượng phức h ọ p ỉ Lòi giới th iệ u 5.2 Logic mênh để có yếu tố thời g ia n 5.3 Đặc tả đặc tính có thời giaiì 5.4 Sự kiểm đ ịn h 5.6 Những nhận xét tổng kết ^ Chương Các kiểu qui cho đối tượng tích c ự c 4.1 Lời giới th iệ u 4-2 Các kiểu khả thay đối cực 4.3 Giao kiểu dịch vụ 4.4 Khả thay yèu cầu 107 4.5 Xem đối iưọìig q trình qui 4.6 Kiểu qui 4.7 Tính thỏa mãn yêu cầu 4.8 Những vấn đề bỏ ngỏ 4.9 Những nhận xét kết luận C hương Sự phân loại thành phan tro ng co sở thòng tin phần m è m ,." 179 7.1 G iới thiệu 179 7.2 Cơ sờ thỏne tin phâiig mềm 181 7.3 Sự khôi phục thồng tin người d ù n g 186 7.4 Sơ đồ phần lớ p 189 7.5 Sắp xếp hợp lý hóa q trình phân lớ p 195 7.6 K inh nghiệm 197 7.7 Kết lu ậ n 202 C hương Quản lý tiến hóa lớp tro n g hệ thống hướng đối tưọng 205 8.1 Thiết kế tái thiết kế đối tượng 205 8.2 May ghép lớ p 207 8.3 Giải phẫu lớ p 209 8.4 Phiên hóa lớp 216 8-5 Tổ chức lại lớ p 222 8.6 Thay đổi hủy bỏ 235 8.7 Sự chuyển đ ổ i 238 8.8 L ọ c 241 8.9 Kêì lu ậ n 245 一 Chương Bộ du vệt thủn thu ộc 251 9.1 G iới thiệu 251 9.2 Yêu cầu duỵột 257 9-3 Bộ duyệt thân thu ộc 258 9.4 Bộ duyệt thân thuộc qua ví d ụ 265 Q s Kết liiA n 278 o s s ữỵ V u T-', i i yc , i ^ Tì ỉ ỉ ChưuTìg 10 Sự họp thành trự c quan ứng dụng phẩn mềm 10-1 Giới thiệu 10.2 Cổng việc liên quan 10.3 Khung họp thàỉìh trực quan 10.4 Vista- mẫu thử công cụ hợp thành trực quan 10.5 Các ứng dụng m ẫ u 10.6 Thảo luận 10 Kết lu A ĩi 06 Chương 11 K thành phần đa phưong tiệ n 310 11.1 Phương tiện số đa phương tiệ n 310 11.2 Hệ thống đa phương tiện hợp thành đa phương tiện 311 11.3 Khung đa phương tiệ n 313 11.4 V í dụ vể khung đa phương tiện-Các thành phần 314 11.5 Các ví dụ ứng dụng Video W idgest 318 11.6 Tóm lươc : 322 I■ Chương 12 Gluons hợp tác thành phần phần mềm 325 12.1 G i^ thiêu :…二 … 二 … r 12.2 Tổng quan vể kiểu mẫu hợp tấc 328 12.3 Yêu cầu cho khung tài 337 12.4 G luons 342 12.5 Gluons khung tài 345 12.6 Kết lu â n .352 Lời nói đầu Có lẽ, "Vượt Đ ối tượng " phải tiêu đề tập sách này, phần lớn Iiội dung trái với hình ảnh "những Đối tượng" quen biết thừa nhận từ lâu Dạiig thức lập trình hướng đối tương chấp nhận vững ĩrong cộng làm phần mềm đề xuất cổng nghệ mạnh hứa hẹn cho phát triển phán mềnì số cơng nghệ hiên có, khả diễn đạt sức mạnh mơ hình hóa đánh giá cao Tuy nhiên, hứa hẹn lớn mà đưa vào giai đoạn đầu cải tiến vượt bậc biên soạn việc sử dụng lại phần mềm, điều mà chưa đạt (Con người địi làm phức tạp hóa với nhữne mạng phftn cấp lớp) Và nghiên cứu liếp diễn Khoảng mười năm vể trước, Dennis Oscar, đến từ Toronto, thành lập Nhóm Hệ thống Đối tượng Trườns đại học Geneva, bắt đầu số dự án nghiên cứu nhằm inở rộng dạng thức hướng đối tượng theo cách khác Chỉ vài năm sau nhóm đă trờ thành tru!ì'j; tâm nghiên cứu cơng nghệ hướng đối tượĩis đáng ý nâng nổ ĩihất châu Au CĨR thời gian đó, phạn nhóm bị hút vào dự án ESPRIT lớn gọi IT H A C A , dự án hướn2 tới việc sản xuất mơi í rường phát triển ứng dụng trên-cư sờ cơng nghệ hướng đối tượng- Tập sách nằv giới íhiội! thành mười năm nghiên cứu phát triển nhóm, sư điều khiển triết học sáng sủa Deiinis nehiẻn cứu sáng tạo Nhóm đà giải vấn đề thực tiễn vấn để có sơ thực tiễn vững Nghể nghiệp trước Deniìis nhà lý thuyết hàm đệ quy học Alonzo Church Princetoỉi, đồng thời khích lệ bỏi cơng việc nềiì tảng nhóm, mơt vài chương trone tập sách nàv giới thiệu kết "Vượt ngồi Đ ối tượng" tiêu đề chương trình thảo luận Hội nghị châu Âu vể lập trình hướng đối tượng (EC00P'91), tổ chức Oscar Nierstrasz Dennis Tsichritzis Geneva vào tháng 7/ 1991 Họ có nhìn rõ ràng việc chúng ta/họ tới đâu từ "những Đối tượng" mà hứa hẹn trước hồn tất phần M ột nhìĩì họ tiếp cận "trên sở thành phần" cho kiến truc phần mểm Xây dựng phần inềm tương ỉai cho ứng dụng mở linh hoạt phải thực hiên hợp thành cấu hình thành phần phần inểm khớp tươim thích mà chúng khái quát hóa đối tượng, thành phần hàm Oscar Laurent giải thích tiếp cận IIày chương đầu tập sách Bây vào thập niên 90’ nhà nghiên cứu tiên phong đấu tranh để vượt "những Đ ối tượng" tìm kiếm cách tiếp cận phát triển phầa mềm tốt Thành phần thông minh, Ngơn ngữ phối hợp, tích hợp ràns buộc Đối tượng, Phát triển Trên sở Thành phần, Những đóng góp tập sách để xuất chìa khóa q giá gợi ý cho người muốn vượt lên ưèn "những Đ ối tượng" ưniversity o f Tokyo, January 1995 A kinori Yonezawa Lời giới thiệu Công nghê Hướng đối tượĩig với từ nâm 1960, bắt đầu có tác đông công nghiệp đáng kể từ năm 1980 Có lý tốt lẫn xấu cho việc tiếp nhận cỏng nghè này, chí câu chuyện thành cơng nói lên thật khơng dẻ dàng để đưa kỹ thuật hướng đối tượng vào nơi mà trước chưa đươc sử dụng Một vài lý đáng ngờ cần phải thảo thuận "việc theo hướng đối tương" là: • "Lập trình hướng đối tượng kiểu tốt lập trình có cấu trúc" Có lẽ, phương pháp lặp trình có cáu trúc khơng giúp bạn nhiểu viêc phát triển ứng dung hướng đối tượng Lập trình hướng đối tượng khơng phầbchỉ lập trình có cấu trúc khốc mũ • X h ú n g ta có khả xây dựiig ứng dụng nhanh chóng đối tượng sử dụng lại được" - có chỗ trống lớn phần mểm viết ừong ngôn ngữ hướng đối tượng cấu lớp đối tượng thật sử dụng lại Các cấu khó phát triển, luôn không dể dàng để sử dụng • "Sẽ dể dàng để bán sản phẩm chúns ta nói với khách hàng ta chúng hướng đối tượng" - chi phí mạo hiểm việc tiếp nhận cơng nghê hướng đơi tượng rát cao, không tiếp nhận dễ dàng Hơn nữa, có lý tốt cho việc tiếp nhận cơng nghệ hướng đối tượng: dường để xuất phương tiên tốt để đối phó với phức tạp biến đổi thống lớn Khi họ pủa hệ (hống giống cần phải xây dưng, hẻ thống đơn độc cần phải trải qua thay đổi thường xuyên theo yẻu cầu, ngôn ngữ hướng đối tượng, cồng cụ phương pháp đề xuất phương tiện để nhìn hệ thốíìs hợp thành linh hoạt thành phần phần mềm Điều vảii cịn u cầu nhiều kỹ nâng xây dựng hệ th ố n g linh h o t m phù hợp với Iihiểu nhu c ầ u k h ác nhau, n h im s lối thiểu cồng nghệ hướng đối tượng đơn giản hóa nhiệnì vụ Sự hợp thành phần mềm hướng đối tượng tiếp nhận quan điểm công nghê hướng đối tượng chủ yếu kiến tạo ứng dụng phần mềm linh hoại từ thành phần phần mềm Mặc dù cịng cụ phương pháp ngơn ngữ hướng đối tượiìg,đã trải qua chặng đường dài kể từ đời lập trình hướng đối tượng, cơng nghê chưa hồn thiện Cuốn sách giới thiệu loạt kết dự án nghiên cứu liên quan tới hợp thành phần mềm hướng dơi tượng mà thực hiên nhóm hệ thống đối tượng Trường đại học Geneva, cộng sư dự ăn nghiên cứu phối hợp, kéo dài khoảng mười năm Cho nên, sách nỗ lực để tổng hợp xếp ý tường mà phát triển nhóm người sát cánh làm việc qua vài năm Mặc dù nhiều chủ đề khác nghiên cứu, trình bày chúiig, dự định ý tưởng nguyên lý liên quan chặt chẽ với họp thành phần mềm, xem xét thiết kế ngôn ngữ lập trình, đạc tả hình thức ， cơng cụ môi trường, phái triển ứng dụng Những sợi đồng hành xuyên suốt sách bao eồm tính tương thích cách hình thức hóa cách có hiệu lực cấu thành thành phán, đối tượng động tảng cho phát triển hệ thống mở, thủ tục khía cạnh cần thiết khớp tùv thích cho đối tượng động, hợp thành chức bậc cao nhir bổ sung tới họp thành đối tượng, tiến triển đối tượng vh khung đối tượng mộl khía cạnh quan trọng bắt nhập chu kỳ sốne phần mểni Quyển sách lôi nhà nghiẽn cứu người hành nghể quen thuộc với công nghệ hướng đối tượng, quan tâm đến phương hướng nghiên cứu có quan hệ tói hợp thànli phán mềm Mạc dù sách chưa thiết kế sách giáo khoa, thích hợp cho xêiniiia tiền tiến nghiên cứu hướng đối tượng Những chương riêng lẻ đọc độc lập Thứ tự giới thiệu lựa chọn chủ yếu để minh họa chuỗi ý tưởng tốt từ thiết kế ngơn ngữ lập trình tới mơi trường ứng dụng K hổng chì "khung nhìn Genever" phát triển hướng đối lượng giới tliiệu, nià đă có cỏ' gắng đáng kể tiên tới đặt cône việc ngữ cảnh, vài chươne chứa đựng kiểm sốt rộne, lớn cơng việc n quan Nhóm Hệ thống Đối tương dược thành lập Dennis Tsichritzis vào năm 1985, sau Ơng ta niấl vài ĩiăm hướng dẫn nghiên cứu ĩĩnh vực Hệ thống Thơng tin Văn phịng Vào lúc đó, ngày rõ ràng (1) mơ hình hướng đối lượng quan trọng cho việc mơ hình hóa hệ íhống văn phịng, rnơ hình kiểu vẫiì chưa phái triển, (2) nguyên mẫu công cụ văn phòng tiền tiến dễ dàng phát triển sử dụng cổng cụ kỹ thuật hướng đối tượng, cơng nshệ chưa có sẩn Hai quan sát cho phép kết hiận rằng, từ tính hưởng đối tượng trở nên nhân tố đặc biệt tới hạn cho việc xây dựng ứng dụng tiền tiến phức tạp, phải tập trung phát triển công nghê nhiều theo đuổi nghiên cứu hệ thống văn phịng với cơng cụ khổng tương xứng hỗ trợ mang tính phương pháp luận Chương sách tổng kết m ối liên hệ cách tiếp cận hướng đối tượng phát triển hướng thành phần, tổng quan Iihững vấ【 i để nghiên cứu nguyên lý thiết kế ngổn ngữ lập trình, cơng cụ, mơi trường phương pháp để hỗ trợ phát triển hợp thành Sự phân biệt đối tượng thành phần tranh luận m ội cách chi tiết ảnh hưởng phát triển tạo dựng vào chu kỳ sống phần mềm giới thiệu Một chủ đề quan trọng xuyên suốt sách khái niệm vể vai trò niột kỹ sư thành phần - người chịu trách nhiẹm xác định khung thành phần - cần phải thể tường minh chu kỳ sống phần mềm Mặc dù qu y ển s c h tập trung vào nội d u n e CƠIÌH nghệ, c ó liến liên quan ngơn ngữ hệ thống lập trình với cơng cụ, khung phương pháp H dự án nghiên cứu đầu nhóm tập trung vào nội dung ngồn ngữ lập trình L a i tạo cố gắng trưóc đâv để tích hợp lớp thừa kế đặc tính "trực giao" khác, chặt chẽ kiểu, trùng tính liên tục Knos đối tưựiig động mà di trú lừ máy tính tới máy tính bên mạng cục bộ, thay hành vi cách động theo quy tắc khởi động điều kiện bên trạng thái nhữns bảng đen truyền tin Knos quan hệ chạt với mà biết "những tác nhân thồng m inh" Cồng việc lai tạp cuối đưa đến khảo sát chi tiết Michael Papathomas mối liên hộ trùng sử dụng iại (chương 2), bời D im itri Konstantas việc hỗ trợ phản tán cho hệ thống inở linh hoạt (chương 3) Công việc ưén Knos dẫa tớ i cóng việc tảng Eduardo Casais vào dạng quy củ tiến hóa thư viện hướng đối tượng tới kỹ thuẠl m ới để tổ chức lai hệ phàĩì cấp lớp (chương 8) Pha khởi đầu ihí nghiệm cho phép có hiểu biết sâu sắc cần thiết nội dung lý thuyết lẩn thực hành hệ thống đối tượng Như hệ đầu tiên, mối quan tàm nhóm khía cạnh hình thức ngữ nghĩa nsỏĩì ngữ lập trình đặc em hệ thống đối tượng trở thành sâu sắc hơii, dẫn dắt đến công việc thực thi Michael Papathomas Oscar Nierstrasz khái niệm ,'khóp tương thích" cho đối tượng động (chương 4), CostasArapis việc mơ hình hóa lập luận vể khía cạnh thường tình việc cộng lác hệ thống đối tượng (chương 5), Laurent Danii vể mô hình khả Iiãng hợp thành, tăng cường lạo kiểu cho Iihữns đối tượng (chương 6) Song song với khảo sát Iv thuyết này, nhóm đà phát Iriển mối quan tâm inới lĩnh vực dựng cụ phần mềm niôi trường phát triểii Eugenc Fiume, (người đến viếng thăm từ Trưởng đại học Toronto,) Laiircnt Dami vào năm 1988 phái triển nguyên mẫu "ngôn ngữ thảo chương tạm thời" cho nhữns đối tượng sống động Đây đột phá đấu ĩiêĩì nhóm vào việc áp dụng cơng nghệ hướng đối tượng cho lĩnh vực ứiig dụng đa phương tiện Khái niệm "nguyên " đặc tả mức cao phối hợp tập đối tượĩiH đóng gói sẵn trở thành đề tài theii chốt nhóm vào ihời gian đó, ý tưởng việc chuyên từ phạm vi lính linh hoạt tơi Iihững đối tượng phần mềm nói chung Vào khoảng thời gian này, chúng tỏi bi lôi vào IT H A C A , Dự án tích hợp Cơng nghê lớn chương trình ESPRIT Cộng đồng châu Au Đối tác N ix d o rí thống thơng tin Berlin (về sau Siemens-NixdorO, cộng tác viên bao gồm Bull (Paris), Datamont (M ilan), T A O - Tècnics en Autom atitzaciò d'oficines (Barcelona) FORTH - Quỹ Nghiên cứu Cơng nghệ, Hellas (H eraklion) Mục đích dự án sản xuất môi trường phát triển ứng dụng đầy đủ, tảng cồng nghệ hướng đối tượng, bao gồm inột ngôn ngữ lập hoạt Cần quan hệ với thành phẩn nhiều mẫu có thể, tầm từ mã ngn tới mã máy thịns qua vài đại diện truiis gian, biên dịch tối ưu hóa phần Một vài ngôn ngữ đại lĩnh vực khác thể xu tiến hành lớn làm cho chiến lược bổ sung Chẳng hạn, ngôn ngữ thảo chương Perl [52] ngôn ngữ hàm C A M L-Light [30] bién dịch vào dạng irung gian mà từ thơng dịch; thật vẠy, chương trình thơng dịch Perl đơi nhanh chương trình biên dịch tươne đương viết c , thao tác trình thồng dịch C A M LLight nhanh phiên biên dịch ngổn ngữ C A M L gốc! V í dụ khác ngón ngữ Self [51], cune cấp mức cao tính linh hoạt thời gian chạy cịn có bổ sung hiêu sở nguyên lý biên dịch-khi-cần: hệ thống chạy bao ồm chương trình dịch Self, phương thức biên dịch cần Việc biên dịch tĩnh phương thức hệ thống hướng đối tượng bị làm phức tạp, người ta cần phải đưa giả thiết ngữ cảnh gọi (tính đến thừa kê); thay \ào phương thức biên dịch chạy, lúc nhiềư thơng tin biết ngữ cảnh (tức là, phương thức thuộc đối tượng nào), mà cung cấp biên dịch phương thức có hiệu Nói cách khác, thời gian bị để biên dịch phương thức chạy nhanh chóns khôi phục thồng qua lời gọi liên tiếp tới phương thức Một cách ly iường, trách nhiệm chuyển đổi mô tả mức cao, người đọc thành phần mô tả mức thấp, tối ưu bên cần phải bỏ môi trườne soạn thảo Tuy nhiên, thực tiễn, người lập trình ln cần phải hướng dẫn lựa chọn Điều có nghĩa tính hạt thành phần thao tác hệ thống dễ nhận thấy người lập trình Tự thản, điểu không thiết bất lợi, vấn đé chỗ tính hạt thường xác định với tính hạt thành phần lốgic cỉia thốns phần mềm Nói cách khác, người lập trình bị bắt buộc phải nghĩ thuật ngữ "các trình biên dịch", thay cho việc nghĩ nhữns thuật ngữ "các mồ đun" Leroy [29] giải thích rõ ràng Ị")hàn biệt này: Sự mơđun hóa q trình phân tích chương trình thành mơ đun nià hiểu bời người lập trình chúng đứng cô lập, làm cho mối liên hệ môđun hiển nhiên người lập trình Biên dịch tách biệt trình việc phân tích chương trình thành đơn vị nhị (những biên dịch) mà soạn thảo sửa chữa biên dịch tách biệt trình biên dịch, việc làm cho m ối liên đơn vị nàv hiển nhiên trình biên dịch kết nối Việc xác định hai khái niệm phổ biến, giới hạn, Leroy ngữ cảnh ngôn ngữ SML [37] Các mổđun - tức là, lơgic chương trình có lẽ phương diện cấu trúc phức tạp nhiều biên dịch, đặc biệt nếu, bàn luận trên, người ta có khả để xem xét chúng giá trị lớp tạo tổ hợp mô đun thứ tự cao hơn, tĩnh chí động Trong phương diện này, SML có iẽ có hệ thống mơđun phức tạp cho ngơn ngừ lập trình hữu, chưa cung cấp biên dịch tách biệt Vài nhà nghiên cứu làm việc loại bỏ hạn chế [29] [16] 1.3.4 s ự kiểm tra biên soạn Bất mà thành phần tập hơp để thực mỏt nhiệm vu thơng thường, ln có giao kết ẩn chúng vể thuật ngữ hơp tác Để xác minh vinh xác mơt cấu hình, giao kết cần phải làm rỏ ràng đươc so với khác biệt xảy Nội dung nhấn mạnh bời hệ thống kiểu Tuy nhiên, hệ thống kiểu thơng thường nói chung khơng thể nắm bắt tất khía cạnh cùa giao kết, khả mô tả han chế chúng Hai cách tiếp cận chấp nhận cho việc giao tiếp với vấn đề M ột cách tiếp cận chấp nhận bời Meyer ngốn ngữ EiíTel [33] phải làm giàu giao diên thành phần ràng buộc bổ sung diễn đạt kỳ vọng lời hứa thành viẻn giao kết M ột phần ràng buộc kiểm tra thống kiểu, phần đươc xác minh thưc hiện, lần mà có hợp tác thực tế (sự chuyển điểu khiển) hai thành phần Cách tiếp cận khác phải cải thiện khả mô tà thống kiểu Nhiêu nghiên cứu thực theo phương hướng này, đặc biột lĩnh vực ngổn ngữ lập trình hàm Phép suy luận kiểu đa tạp ngôn ngữ M L Haskell [21] thật cung cấp mức an toàn cao nhiều ngốn ngữ ưuyền thống giống Pascal, mà không đặt gánh nặng bổ sung lên người lập trình Tuy nhiên, người ta bỏ mơ hình hàm, kết khơng cịn dùng được: hệ thống với việc biên soạn bảng đen (những ngịn ngừ lập trình theo câu lệnh, hè thống tương tranh) người ta suy nhiêu thông tin kiểu Các hệ thống đối tượng liên quan sao, đâv càu hỏi mở, khảo sát chi tiết có kiểm sốt Pisher and M itchell [11] Sự bổ sung việc tạo kiểu làm cho phép suy luận kiểu lẫn kiểm tra kiểu cứng nhắc đáng kể, bời tiến quan trọng làm năm đây, khơng có ngơn ngữ hướng đối tượng với mịt hộ thống kiểu giống M L phát triển Để nắm bắt ngữ nghĩa đê quy đối tượng mức kiểu, hầu hết nhà nghiên cứu sử dụng hiển hệ thống có kiểu với kiểu đệ quy định lượng tồn tại; giải pháp cải thiện trạng cho việc định kiểu đối tượng, chúng dường không áp dụng ngôn ngữ thực, từ phức tạp biểu diễn kiểu phát sinh có lẽ làm kinh sợ hầu hết người lập trình khơng quen thuộc với lý thuyết kiểu Do tin tưởng tính khả thi định kiểu đối tượng đạt qua phép suy luận qua việc định kiểu rõ ràng; kết sơ theo chiều hướng tranh luận [18] Điểm khó, nhiên, phải có khả để suy kiểu mà "tối thiểu" theo quan điểm việc tạo kiểu lấn "nguyên lý" theo quan điểm lược đổ kiểu Carry (một lược đồ kiểu nguyên lý cho thuật ngữ phát sinh tất kiểu khác thuật ngữ thay biến kiểu V ới kiến thức chúng ta, vấn đề mở; vài kết kiểu chính, chủ vếu cho đối tượng chọn [15] Trở lại với vấn đề giao kết hiển thành phần, phải nói đến họ khác giải pháp mà đặt giao kết, bên thành phần mà bên Đ ối với biên soạn liên ngữ, điều chí ( hươỉìị ； chi kha năng, khó đẽ so ‘sánh giao kếĩ trình bàv troiìs ngỏii ngữ mơ hình khác Một ví dụ RÌao kết bén thành phần biểu đồ sị (iữ liệu trình bày nhữne điều kiện mỏt sờ liêu thơng thườĩie truy nhập, cần phải lưu tâm bơi chương trình làm việc giao dịch sờ liệu Trong cung cấp liên kết thành phần hỏn tạp, loại giải pháp có bất lợi hoàn toàn cứng: thuật ngữ giao kết trình bày từ đầu khó lịng thay đổi sau này; ngồi ra, cách tiếp cận khơng thể cung cấp tính biến đổi được, thành phần riêng biệt rõ ràng với cấu hình thành phần nhiéu phán Những giao kết bên iiRồi thành phần tìm troiis ngơn ngữ liên kết niỏđun, mà cóng việc phải thực xác việc hợp thành thành phần phần mềm Số lượng thông tin điều khiển ngôn ngữ thav đổi từ hệ thống sang hệ thống khác; Goguen, chẳng hạn, biện hộ cách tiếp cận đại số để nắm bắt thơng tin Iì ữ nehĩa thành phần [13] Tuy nhiên, cần phải lưu ý lìRổii neữ liên kết mỏđun có phầ:i quan Irọnẹ chúiig tài liệu có lơi cho cách tiếp cận đồng hơn, phâiì biệt thành phầrỉ lắp ráp thành phần xác hơn, Những cách tiếp cận hướng đối tượng rơi vào phạm trù đó, cách tiếp cận hàm rơi vào o mức độ chí cịn lớn Nhữns hệ thống kiểu mô tả đại số tập truỉis vào việc xác minh tính xác theo cách máy kiểm tra nhìn tĩnh vào cấu hình phần mềm Bởi vậy, chúng thuộc vào "thế giới" neữ nghĩa tĩnh Trái lại, số kỹ thuật phát triển cho việc nghiên cứu hành vi động chương trình, giống ngữ nghĩa thực chứng, đại số, hàm liên đề Từ kỹ thuật giao liến với thơng tin động, nói chung khơng dễ định, chiín^ thơng thường sử dụng cho \iệ c nghiên cứu ngôn ngữ mơi trường lẠp trình cấu hình phần mềm đậc biệt Bời khơiis; phải mục đích CỈKI đâv để iranh luận chúng cách chi tiết Tuy nhiôii, phải để ý ràng vài điổm tranh luận o cho việc tiến triển phát triển phán mềm hướng thành phđn có vỉù lác độns lên kv thuật phân tích ChẳuR hạn, pháĩi lớn ngữ nghĩa ngữ nshĩa hợp thành, chúng không ngữ nghĩa mô đun (đối với ngữ nghĩa thực chứng, điéu nẩy thừa nhận Mosses [38]) Trong kịch sư phát triển hợp thành nhiều lần, phải dẩn dần cai tiến ngữ nghĩa thành phần phù hợp vói kiến thức có sẵn vể ngữ cảnh nó: biết nhiều thành phần chèn vào inột cấu hình cho thành phần xem lách biệt Thav cho việc phân biệt thông thường nsữ nghĩa tĩnh, ngữ nghĩa động, với mà Jones [25] gọi "sự phân tích thời gian ràng buộc," phải lại lần có phạm vi tổng thể bước trung gian’ tương ứiig với giai đoạn trung gian khác lắp ráp' Cuối cùng, cần để ý kỹ thuật ngữ nghĩa truyền ihống phát sinh mối quan hệ tương đương thành phần phần mềm - chúng thiết kế cho khả phân biệt liệu hai thành phần khổng 丁rong ngữ cảnh lập trình hướng đối tượng, điểu khơng cịn đủ, k h i ý tưởng phải mơ rộng thành phần tạo thành phần không "bằng" với trước (tương thích), mà cịn theo nghĩa (thành phần mở rộng) "tốt hơn" Giao liếp với khía cạnh này, nhà !v luận ngôn ngữ hướng đối tượng phát triển ý tưởng quan tương đương phần (PERS) [4], làm thành phần phổ thông, liên quan tới kiểu cho: chẳng hạn, ghi (x = l, y=3), (x= 1’ y=4, z=10) tương đương theo kiểu { x :In t}, không theo kiểu {x:Int, y:Int}.M ột cách tiếp cận luân phiên (thay thế’ xoay chiểu) để xuất sách chương 6, thành phần lần liên quan phổ thông, bời trật tự phần tương thích thay cho mối quan hệ tương đương 1.3.5 Các đối tượng n h trình Sớm ưong chương thuyết phục thành phần tương tranh hai khái niệm bản, xem xét "những phụ kiên để mở rộng" cho ngơn ngữ lập trình Vả lại, nội dung ngữ nghĩa tinh tế phức tạp điều quan trọng để có mơ hình đối tượng hình thức tảng ngữ nghĩa học cho lý luận tất đặc tính ngơn ngữ K h i đó, liêu mơ hình đối tượng giống gì, tảng ngữ nghĩa phù hợp gì? ' Hãy xem xét đặc tính mà cần phải mồ hình hóa ngơn ngữ hỗ trợ phát triển hướng thành phần二 Những đối tượng động: đối tượng nhìn tác nhân độc lập trình Những Thành phần: thành phần khái niệm trừu tượng, mức cao hơn, qua khơng gian tính tốn cùa đối tượng tích cực Biên soạn; biên soạn tổng quát hỗ trợ, thừa kế Những Kiểu: đối tượng lẫn thành phần có siao diện kiểu, đối tượng thực thể động thành phần (là) tĩnh thống kiểu cần phải phân biệt chúng Những kiểu con: tạo kiểu phải đặt sờ ý tưởng "tương thích" mà cho phép đối tượng lẫn thành phần thay khách hàng họ làm thỏa mãn [55] M ột mơ hình đối tượng cần phải đối phó với đối tượng lẫn thành phần Các đối tượng đóng gói dịch vụ bao hàm tính đồng nhất, trạng thái hành vi Những dịch vụ thu nhận qua hành vi phù hợp với vài thủ tục khách/chủ M ặt khác, thành phần khái niêm trừu tượng dùng để xày dựng hệ thống đối tượng, tức là; chúng hàm khơng gian đối tượng/q trình Mặc dầu hàm tảng, khơng thể mơ hình hóa đối tượng thực thể hàm chúng sống lâu tương tranh M ột đầu vào đầu tiến triển, đầu vào cho kết khác thời điểm khác nhau, đối tượng quan trọng phi hàm M ột cách lý tường, phép tính đối tượng [41] kết hợp đặc tính hàm phép tính q ưình với đặc tính bièn soạn phép tính X Thật thú vị, tiến việc nghiên cứu phép tính q trình tập trung vào nhiều khía cạnh ngữ nghĩa học hệ thống hướng đối tượng tương tranh Nguyên viết M ilner Phép tính Hệ thống Truyền thông (CCS) [34] dẫn đến phép tính q trình diễn đạt cao song khơng sử dụng để mơ hình hóa " q trình di động" mà trao đổi tên gọi cổng truyền tin chúng thông điệp Điều này, dĩ nhiẽn cần thiết để mỏ hình hỏa nhữns đối tượng Cơng trình viếl Engberg \à Nielseiì [10] đà vav mượn phong theo khái niệm từ phép lính X để xử lý điều này, M iln e r [36] đả tinh lọc đơn giản hóa kết họ để tạo nên phép tính Ã, "phép tính cho q trình di động" thực Trons chờ đợi, Thomsen [48] phát triển "Phép tính cho hộ thống nối kết thứ bậc cao" (CHOCS) mà thực chất bổ sung thuật ngữ chuyển cho CCS Theo quan điểm hệ thống đối tượng, điều cho phép người ta mó hình hóa đối tượng thành phần giá trị chạy M ilner mở rộng phép tính % cho dạng đa adic [35], mà cho phép người ta sùi nhanh thơng tin ìhõim điệp phức hợp, tiến cử hệ thốns kiểu đơn giản cho phép tính ĩiày Dựa theo cống trình viết bời MUner, Saiìgiorgi [46] đă phát triển phép tính q trình thứ bậc cao( HOP), neữ nghĩa học Sangiorgi giữ gìn trung thựch bời mội ánh xạ tới phép tính 7t đơiì giản, Hennessv [17] đă phát triển mỏ hình ký pháp phép tính q trình thứ bậc cao Honda [20] đà đồng thời phát triển v-calculus, phép tính q trình nển tảng thỏii2 tín dị bộ, mà ngữ nehĩa học thu rút gọn đặc tính phép tính X ngịi Đ i theo hướng ngược lạ i’ Dezani et al [9] khảo sát tính song song lính khơng tất định dị phép tính Ằ cổ điển Trong cộnẹ đồng hướng đối tượng, có vài cố gắng khác để phát triểỉi phép tính đối tượng mà lấy cảm hứng ban đầu họ từ phép tính q trình phép tính, hai [8] [20] [41] Chúng la đề xuất mơ hình hình thức đối tượng thành phần trẽn tảng phát triển đâv q trình phép tính phép tính \ phải tạo thành sở tốt khỏng cho hiểu biết RÌải thích khái niệm trừu tượng soạn thảo theo phương pháp phát triển phẩn niém hướng thàiih phần, mà cịn có ihể thật phụng với rư cách máy trừu tượng cho phát triển hệ m ới ngổn ngữ hướng thành phần [43] [44], cũne cách lììà phép lính Ả cung cấp cho Iiền t ả n g n g ữ n eh ĩ a c h o n h ữ n g Iigơĩi n s ữ lập trình h àm đại- Tóm ỉược chủ đ ề nghiên cứu Trong mục nàv liệt ké m ột vài ước muốỉì đầy tham vọng cho tương lai mối trường phát triển hướng thành phần, thời vài phương hướng giới thiêu ngơn ngữ lập trình đại cho m ột tin cậy nịo việc hồn thành chương trình Để tổng kết, đủv có điểm mà xem xét nội dung nghiên cứu quan trọng nhất: , Kết hợp ý tưởng thời khái niêm trừu tượng có phép tính q trình’ ngôn ngữ hàm ngôn ngữ hướng đối tượng vào ý tường đơn thành phẩn, mà lớp sở, thực thể lưu trữ trang bị ý tưởng tham số hóa (rời bỏ vài khía cạnh thành phần "m ò ") thể (khả để phát sinh "bản sao" thàiìh phần ngữ cảnh chạv đă cho), hỗ trợ tính tùy biến (khả để đóng gói m ột cấu hình phần thành phần mỏt thành nhần mớiì Phát triển thao tác cơng cụ phần mềm có khả giải cấu hìiứi bơ phận hỗ trợ q ứình lắp ráp nhiều lần, bời việc sử dụng mức khác đại diện trung gian thành phần Các công việc hiên cùa việc kiểm tra kiểu, biên dịch tới mã máy nối liển thay bời thay đổi gia tăng đại diện trung gian Tìm tháy hệ thống diễn đạt suy diễn kiểu dể định/đánh giá phần, mà có khả đinh ữnh vể tính xác cấu hình phần theo cách suốt (hoặc yêu cầu dạng thông tin xác định kiểu tối thiểu) người lập trình Có thể thấy phương hướng nghiên cứu yêu cầu m ột tích hợp chặt nghiên cứu thời làm mức lý thuyết (ngữ ngiũa kiểu ngơn ngữ lập trình) mức thực hành (các thể nghiệm, thiết kế trình biên dịch/thơng dịch) Công nghệ thành phần M ột k h i có ngốn ngữ mơi trường cho phép phát triển khung thành phần phần mềm, cịn tổn đọng vấn để thành phần phải phát triển, bảo trì ứng dụng V ới việc phát triển phần mểm Cruyền thống, ứng dụng nguyên lý thiết kế để đáp ứng yêu cầu đặc trưng M ật khác, khung thành phần cần phải thiết kế để thỏa mãn nhiều tập hợp yêu cầu khác nhau, chí phải xày dựng để đoán trước yêu cầu chưa biết Xem xét kịch sau [42] việc phát triển ứng dụng: người phát triển ứng dụng truy nhập tới hộ thống thông tin phần mềm(SIS) chứa đựiig không mô tả khung thành phần có sán, mà cịn kiến thức lĩnh vực liên quan miền ứng dụng khác nhau, mơ tả u cầu mơ hình, thiết kế tổng quát, nguyên tắc đạo cho đặc tả yêu cầu ánh xạ không gian vấn đề thiết kế thể nghiệm không gian giải pháp (xem chương cho mô tả hệ thống vậy) M ột hệ thống thông tin phần mểm tâm tưởng gần gũi với hệ thống chuyên gia kho chứa; thực vậy, nguyên lý SIS chỗ phải mã hóa thể kiến thức đạt chuyên gia rinh vực Để sử dụng SIS này, người phát triển ứng dụng tnróc hết thâm nhập vào hộp thoại để xác định lĩnh vực ứng dụng thích hợp Thơng tin gắn liển tới lĩnh vực tham khảo đến tới khung ứng dụng tổng quát (GAP) GAP xác định ngữ cảnh cho việc phát triển ứng dụng Bước hộp thoại phải trình bày yêu cầu M ột GAP bao gồm kiến thức miền mơ hình u cầu, đặc tả yêu cầu thực rộng rãi phù hợp với kiểu mẫu hữu V ì thế, yêu cầu đặc trưng khiến SIS gợi ý (phù hợp với nguyên tắc đạo cất giữ) thiết kế tổng quát khung thành phần sử dụng để xây dựng ứng dụng Những nguyên tắc đạo gợi ý thành phần phải khởi tạo chuyêh môn hóa để đáp ứng yêu cầu đặc trưng (Chương 10 chứa đựng mô tả tóm tắt RECAST, cơng cụ tương tác cho tập hợp yêu cầu đặc tả, dựa kịch này.) Q trình hồn thành đặc tả yêu cầu, tạo thiết kế định bời làm khiết hợp thành thành phần dẫn đến cấu trúc thông tin mà c h iln e 【 a gọi khung ứne dung dác trưng (SAP) SAP khóng phải tạo thành từ ứng dựng hồn thiện ĩĩià cịn íìr tár cà thóng tin phát sinh dọc đường Khi yêu cầu ứng dụng |-)hál triển, SíS lại lần sừ dụng, trường hợp nàv hộp thoại sinh định trước xem xét lại SAP xây dựng lừ cũ K ịch lôi cuốn, gợi ý cảu hịi nhiều trả lời Kiến thức lĩnh vực phải nắm bắt mô tả SIS nàv nào? Những thiết kế tổng quát khung thành phần phát triển đươc mô tả nào? Những nguyên tắc đạo xác định niã hóa làm sao? A i chịu trách nhiệm cho việc tu SIS nội dung nó, nội dung đánh giá tu Kịch thực tiễn trôi chảy không? SỈS nàv cần hồ trợ nhà chuyên gia? Chúng ta tin tuỏ.ng có^ ứng dụng tổng quát thành công khung thành phần tồn lìhinie khơng biết tới mức Iiào kịch thúc đẩy để làm việc l6i ĩrong thực tiễn Phải làin việc lĩnh vực ứns dụne quen biết bị hạn chế, đồiìg thời có hiệu lực lĩnh vực liến triển phức hợp hơn? Điều ỢÌ ý vai trò kỹ thuật thành phần vể càn khác với vai trò truyền thống phát triển ứng títiĩig Mạc dầu cũne ỉìgười trons ：một vài trường hợp đóng hai vai trị’ thật lu quan ^rọns phân chủns để Ìữ tập hợp khác \cu cầu riêng biột Đặc biệt, nhữns khách hàng môi người râì khác Những khnch hàng in i dụng người dùng cuối cùng, khách hàng khune thành phần người phát triển ứng dụng \ cần thiết để nâng kỹ thuâl thành phần tới hoạt động phân biệt? Phải khổng thể tìm thành phán sử dụng lại việc bới kiếm ứng dụng hướng đối tươns hiồii hữu? M ộ t kịch hợp K cho phép người phát triển ứng dụng sử dụng phương pháp truyền thống để đạt tơi thiết kế hướng đối tượng, lúc tìm kiếm lìhữno đối tượng có thc đùng lại rnà tối thiểu gạp phần đặc tả Nhữiig đối tượng "được tìm thấy" lúc "may" lại để phù hợp với nhiệm vu đane làm Vắn dé với kịch chỗ bạn khỏng nhộn từ hư khiêng Các thành phần phần mểm ch? dùng lại chủng thiết kc cho việc sừ dụng lại M ột kho chứa đối tượng phần mềm từ ứug dụng trước tương tự "kho nát phần mềm" khơng chứa đựng mà bạn tìm kiếm Chi phí tìm kiếm viêc tìm mà xấp xỉ đáp ứng nhu cầu, chi phí bổ sung cho việc điều chỉnh cho phù hợp vượt chi phí phát triển từ đầu Tồi tệ hơn, thành phần may sẵn không tu được, cách tiếp cận khuyến khích tăng nhanh phiên rối rắm, khơng tương thích gí tương tự thành phần, không thành phần số cuối cùne; dùng lại Sừ dụng lại phần mềm cách có thống ngẫu nhiên yêu cầu m ột đầu tư việc phát triển khung thành phần việc quản lý thông tin phần mềm [53] 1.4.1 Lợi ích rủi ro M ột thành phần thiết kế cho việc sử dụng lại tạo nên phận khung thành phần dự định để sừ dụng nhau, gần cách mà đồ đạc bao gói làm từ thành phần mà chúng kết hơp theo nhiều cách để thích hợp nhu cầu khác Rõ ràne phát triển khung thành phần thể đầu tư mà cần phải đánh giá lợi nhuận mong đợi Những lợi ích đo theo hai cách: khung thành phần phải làm dễ dàng (1) để lấp đầy (ít phần) nhu cầu nhiều ứng dụng khác nhau, để điều chỉnh ứng dụng đề cập cho nhu cầu thay đổi (Điều điểm tiêu thụ đồ đạc bao gói) Nếu hai yêu cầu diện tới mức độ đủ, đáng giá phát triển khung thành phần, đầu tư việc sử dụng việc thích nghi khung hữu Thật vậy, dễ dàng chứng tỏ khung thành phần sử dụng: ứng dụng trường tồn tất yếu trải qua thay đổi theo yêu cầu với thời gian mà dễ dàng đáp ứng việc sử dụng khung, ứng dụng ngắn hạn buộc phải phát triển cách đặc trưng ràng buộc thời gian chặt chẽ, mà làm cho thuận tiện việc sử dụng Ichung hữu Tuy nhiên, rủi ro cần phải xem xét; M ột đường cong tri thức dốc đứng gắn với việc sử dụng khung Những Người phát triển phải sẩn sàng đầu tư thời gian cố gắng vào việc học khung trước lợ i ích trở thành thực Khơng phải hội chứng được tạo khó khắc phục Sự phát triển khung hoạt động đắt tiền dài hạn Những lợi ích dài hạn phải biện minh thuật ngữ, hội cho việc hoàn vốn đầu tư Những dự án riêng có mục đích ngắn hạn hạn cuối xung đột với mục đích dài hạn kỹ thuật thành phần Sự quản lý phải đàm bảo phát triển sờ hạ tầng hướng dịch vụ để hỗ trợ công việc chuẩn bị trước khung cho dự án [14] Nếu việc sử dụng khung gây nhiều đau đầu, dự án không tiếp nhân chúng Những khung phát triển nhanh chóng vào lúc ban đầu trải qua vài tái thiết kế toàn trước chúng ổn định Những chi phí việc tái sáng chế ứiig dụng khách hàng cùa khung tái thiết kế cao, nhiên lợi ích dài hạn việc tái sáng chế quan trọng, v ề nguyên lý không Iièn sử dụng khung không ổn định cho sờ lớn cũa ứng dụng khách hàng, mặt khác, khung không tiến triển tới chỗ làm ổn định áp dụng cho nhiều loại ứng dụng khác L ý mà điểm xem rủi ro chỗ thực tiễn kỹ thuật phần mền hữu thật ngăn cản phát triển hướng thành phần bời tập trung vào ứng dụng riêng nhìn phận trình phần mềm rộng nhiều Tập trung vào điểm cần phải nghĩ lại cách phần mềm phát triển tiến cử hoạt động vào chu trình sống phần mềm Nếu loại bỏ mơ hình sừ dụng lại phần mềm "phần mềm đồng nát", cịn xem xét điểm xuất phát cho kỹ thuật thành phần M ột kỹ thuật thành phần xử lý tóm lược kết cố gắng phát triển ữiróc để tổng hợp (I) miền kiến thức yêu cầu mơ hình [2 ]’ (II) kiểu mẫu thiết kế [12] kiến trúc chủng loại, (III) khung [24] thư viện thành phần, (IV ) nguyên tắc đạo đế phác họa từ để tới miển giải pháp (tức là, từ yêu cầu tới thiết kế thể nghiệm) Vì vậy, kết kỹ thuật thành phần, giống với sách nấu ăn thiết kế tốt - khơng đơn sưu tập lời dẫn đóng gói sẵn’ mà chứa đựng nhiều thổng tin nền, lời dẫn tổng quát, gợi ý làm để kết hợp may đo lời dẫn, lời khuyên làm để đáp ứng nhu cầu đặc trưng "Sách nấu ăn" dự định để bù đắp cho việc mà cung cấp thời gian phí tổn yêu cầu để trờ thành chuyên gia kiến thức đạt giảm tập nguyên tắc đạo quy tắc chuẩn Chú ý rãng kỹ thuật thành phần khơng chì liên quan với việc phát triển thành phần phần mềm, mà động chạm tất cà khía cạnh phát triển phần mềm từ sưu tập yêu cầu đặc tả' trực tiếp đến thiết kế thể nghiệm Điều mà tạo vật có tiện lợi để sử dụng lại thường tự chúng không thành phần phần mềm mà kiến thức ĩĩnh vực thiết kế tổng quát Sử dụng lại phần mểm thành c-ìng người ta vạch kế hoạch cho trưóc Bởi việc chờ đợi sau vèu cầu rõ hệ thống được thiết kế, nhiều hội cho việc sử dụng lại bị lãng phí, người ta chí khơng thể tìm thấy thành phần thích hợp để sử dụng lại K ỹ thuật thành phần xem thành công kết sử dụng để xây dựng ứng dụng linh hoạt Một cách lý tường, kết thật điều khiển trình phát triển ứiig dụng: người phát triển ứng dụng phải nhanh chóng định vị trone khơng gian thơng tin phần mềm tới GAP hoạt động sưu tập yêu cầu, đặc tả, thiết kế ứng dung Sư chọn lựa tinh chế thành phầii phái từ hộp thoại linh hoạt IIsười phát triển m ột hệ thống thông tin phán mém c sờ nội dung củ a GM 1.4.2 Làm th ế đ ể từ đầy tới Dù hệ thống thơng tin phần mém lơi vậv có, nơ ười ta biết đôi chút việc phải xày dựng thứ mà thành công thực tiễn, (xem chương thay việc thảo luận vài nội dung này) Những kết tốt đạt qua việc tiến cử gọi ỉà "Đội dịch vụ chuyên gia" cá nhân chịu trách nhiệm cho việc tiến cử tài sản sử dụng lại vào dự án [14] Theo cách này, vài kiến thức lĩnh vực hình thức hóa thuật ngữ tài sản sử dụng lại, kiến thức việc làm để áp dụng chúng vào hoàn cành riêng cịn trách nhiệm đơi Những phần khó khăn cịn tổn lại; (I) làm để xác định tài sàn sử dụng lại có khả áp dụng cho tình đề cập tới (sự xác định GAP), (II) tương ứng kết phàn tích cho kiến trúc thiết kế có sẵn, (III) chi tiết hóa hệ thống thành phần thất lạc, (IV ) thích nghi khung cho yêu cầu chưa lường trước Tổng qt hơn’ có khía cạnh khác phát triển hướng thành phần mà xem vấn đề nghiên cứu mở M ột số vấn đề đáng kể là: 1- K ỹ thuật tri thức lĩn h vực: tri thức lìiìh vực phải đừợc năm bắt hình thức hóa để hỗ trợ phát trién hướng thành phần nào? Tính đồng phân tích thiết kế: khôn ngoan kỹ thuật phần mềm truyền thống muốn siữ nội dung thiết kế lách biệt với phân tích, song hội cho việc sử dụng lại bị người ta hoạch định cho Sự phân tích lợi dụng kiến rhức mà khung sử dụng thiết kế hệ thống nào? Thiết kế khung: phương pháp áp dụng cho việc thiết kế khuiig*^ Sự phân tích phương pháp thiết kế hướng đối tượng không nhấn mạnh tới phát triển khune Các nguyên tắc đạo tồn tại, phương pháp khơng [23] Sự tiến hóa khung: khung phát triển chúng ổn định Những nguyên lý cần áp dụng tiến hóa chúng? Chúng ta giải khó khăn kỹ thuật việc tu ứng dụng phát triển khuiie nào? [6] Những thước đo sử dụng lại: thước đo phần mềm truyền thốns việc sử dụng hạn chế việc phát triển phần mềm hướng đối tượng Người ta cịn biết vể đo chi phí việc phát triển phần mềm hướng thàiih phần Người ta đo tiểm năne cho việc sử dụng lại nào? Kích thước chi phí ứng dụng khung? Chi phí việc phát triển bảo trì tài sản sử dụng lại? [14] Những công cụ môi trường: công cụ phán mềm thuận tiện cho việc phát triển hướng thành phần? Không gian thơng tin phần inểm chế ngự theo cách cho cung cấp hổ trợ tốt cho người phát triển ứng dụng lẫn cho thuật thành phần? 1.5 Những kết luận Sự phát triển phần mềm hướng ihàỉih phần dựa vào kỹ thuật phương thức lộp trình hướng đối tượng bời khai thác khái quát hóa đóng gói khả mờ rộng hướĩìg đối tượng, việc chuyển tập trung từ việc lập trình vào hợp thành Cơng nehệ hướng đối tượng thời hạn chế việc hỗ trợ cho phát triển hướng thành phần theo vài cách Trước tiên, ý tưởng thành phần phần mềm khơng hổ trợ tưịrng minh tổng qt bời ngôn ngữ hướng đối tượng M ột thành phần khái niệm trừu tượng phần mểm tĩnh, đối nghịch với đối tượng, mà hợp thành với thành phần khác để tạo nên ứng dụng Những loại khác thành phần xác định ngơn ngữ hướng đối tượng, hạt cát chúng liên kết chặt chẽ cách đặc thù với hạt cát đối tượng - bổ sung cho lóp, khái niệm trừu tượng mịn mằng lẫn khái niệm trừu tượng chia thơ hữu ích thành phần Sự cung cấp hai thành phần, vừa khái niệm trừu tượng phần mểm lẫn đối tượng, m ột khung chung đòi hỏi vài quan tâm đến việc tích hợp dặc tính ngơn ngữ tương ứng khung chung Đặc biệt, thật dễ dàng để nghĩ hệ thống kiểu thỏa đáng mà nắm bắt "tính tương thích khớp" tất dạng hình thức hữu ích Tính tương tranh phát triển hành vi đối tượng đạt khó khăn đặc biệt, thấy chương 2, Chúng ta chứng minh lý cần phải thiết thiết lap nển tảng ngữ nghĩa thích hợp đối tượng, hàm tác nhân mà sử dụng để suy luận vể soạn thảo phần mềm tất mức Dù quan trọng, nội dung tảng tập trung vào bô phận nhỏ khó khăn việc làm phát triển hướng thành phần thực tiễn Thậm chí thành công việc tạo ngôn ngữ máy tính mà thích hợp cho việc trình bày khung thành phần phần mềm tương thích khớp, có m ột phạm vi rộng lớn nội dung công nghệ phương pháp luận phải giải trưóc mong đợi phát triển hướng thành phần trở thành phổ biến Câu hỏi thành phần đến từ đâu? - càu hỏi khó trả lời nhất- Trong chu trình sống phần mểm truyển thống, ứng dụng "các thành phần" may sẵn cho yêu cầu riêng Trong cách tiếp cận hưómg thành phần, hoạt động kỹ thuật thành phần phải hợp hiển vào chu kỳ sống, hỗ trợ bời trình phần mểm, phương thức công CỊL "Sử dụng lại phần mềm" khơng phải mà đạt eách rẻ bời tùy tiện tiến cử thư viện "những kho tàng" vào phương thức hữu Thật vậy, tập trung vào sử dụng lại phần mềm, phải tập trung vào việc sử dụng lại thiết kế, kiến trúc kiến thức chuyên môn K ỹ thuật thành phần hoạt động việc đúc kết đóng gói kiến thức chuyên gia ĩĩnh vực theo cách như việc làm phát triển ứng dụng hướng thành phần Tài liệu tham khảo [1] Pierre America, ,'A Parallel Object-OrieiUed Language with Inheritance and Subtyping；' Proceedings OOPSAL/ECOOP ,90' A C M SIGPLAN Nolices, v o l' 25, no 10, Oct 1990, pp 161-168 [2] Roberto Bdlinzona, Mariagrazia íugini, V ic k i de Mey, "Reuse o f Speciĩications and Designs in a Development Inform ation System," Proceedings IFIP W G 8.1 W orking Conference OII Iníormation System Developmenl Process, ed N Prakash, c Rolland, B Pemici, Como, Ita ly’ Sept 1-3 1993, pp.79-96 [3] Gilad Bracha, 'The Programming Language Jigsaw: M ixins, M odularity and M ultiple Inheritance, " Ph'D thesis, Dept o f Computer Science, U niversitv o f ưtah, March 1992 [4] K im B Bruce and Giuseppe Longo, "A Modest Model o f Records, Inheritance, and Bounded Quantirication," in Infonnation and Coinputation vol 87, 196-240, 1990 [5] Luca Cardelli, "O bliq; A Language with Distributed Scope," prelim iĩiary draft, March 1994 [6] Eduardo Casais, ',An Incremental Class Reorganization Approach Proceedings ECOOP '92, ed O.Lehrmann Madsen, Lecture Notes in Computer Science, vol 615, Springer-Verlag, Utrecht, June/July 1992, pp, 14-132 [7] XVilliam Cook, W alter H ill and Peter Canning, "Inheritance is not Subtypiĩig," Proceedings P O P L '90, San Prancisco, Jan 17-19, 1990, pp 125-135 [8] Laurent Dami, "Software Coinposition: Tovvards an Integration o f Puiictional and Object-Oriented Approaches," Ph.D thesis no 396, University o f Geneva, 1994 [9] M ariangiola Dezani-Cianca lini, Ugo de'Liguoro, A dolfo Pipemo, 'F ully Abstract Semantics for Concurrent Lambda-calculus," in Proceedings TACS '94, Lecture Notes in Computer Science, vol'789, Springer-Verlag, 1*994, PP- 16-35 [10] U ffe Eiigbcrg and M Nielsen, "A Calculus o f communicatiiìg Systems w ith Label Passing," D À IM I PB-208, University o f Aarhus, 1986 [11] Kathleen Pisher and John c M itchell, ,'Notes on Typed Object-Oriented Program inin^," in Proceedings TACS 94, Leclure Notes in Computer Science, vol 789, Spnnger-Verlag, Utrecht, 1994, pp- 844885 [12] Erich Gamma, Richard Helm, Ralpti E Johnson and John Vlissides, "Design Patterns: Abstraction and Reuse o f Object-Oriented Design," Proceedings ECOOP '93, Lecture Notes in Computer Science, Springer-Verlag, vol 707’ 1993, pp, 406-431 [13] Joseph A Goguen, "Reusing and Interconnecting Software Components," in IEEE Computer, Feb.l986, pp 16-27 [14] Adele Goldberg and Kenneth s Rubiii, Succeeding with Objects: Decision Frameworks for Project Management, Addison-Wesley, 1995, íorthcoming [15] Carl A Gunter and John c M itchell, Theoretical Aspects o f ObjectOriented Programming, M IT Press, Cambridge, M ass., 1994 [16] Robert Harper and Mark Lillibrid ge, "A Type-Theoretic Approach lo Higher-Order Modules with Sharing," in Proceedings POPL '95, A C M Press, 1995, pp 123-137 [17] Matthew Hennessy, "A Fully Abstract Denotational Model for HigherOrder Processes," in Information and Computation vol 112(1), pp 55-95, 1994 [18] Andreas Hense, "Polymorphic Type Iníerence for Object-Oriented Programming Languages," Dissertation, Saarbrucken, PÚTOt, 1994 [19] John Hogg, "Islands: Aliasing Protection in Object-Oriented Languages," in Proceedings CXDPSLA 91, A C M SIGPLAN Notices, vol 26, no I I , pp 271­ 285, Nov 1991 [20] Kohei Honda and M ario Tokoro, "An Object Calculus for Asynchronous Communication, " Proceedings ECOOP '91, ed p America, Lecture Notes in Computer Science, vol 512, Springer-Verlag, Geneva, July 15-19’ 1991, pp 133­ 147 [21] Paul Hudak, Simon Peyton Jones and Philip Wadler (eds), "Report on the Programming Language Haskell - A Non-Strict, Purely Punctional Language (Version 1.2)," A C M SIGPLAN Notices, voi 27, no 5’ May 1992 [22] EEEE Software, Software Reuse, vol 11’ no 5’ Sept 1994 [23] Ralph E lohnson and Brian Foote, "Designing Reusable Qasses," Joumal of Object-Oriented Programming, vol I, no 2, 1988, pp 22-35 [24] Ralph E lohnson, "Documenting Frameworks using Pattems," Proceedings OOPSLA '92, A C M SIGPLAN Notices, voi 27’ no 10, OcL 1992, pp 63-76 [25] N eil D Jones, "Static Semantics, Types, and Binding Time Analysis," Theoretical Computer Science, vol 90, 1991, pp 95-118 [26] Dennis G Kafura and Keung Hae Lee, "Inheritance in Actor Baseci Concuưent Object-Oriented Languages," Proceedings ECOOP '89, ed s C o o k ^ Cambridge University Press, Nottingham, July 10-14, 1989, pp 131-145 [27] Gregor Kiczales, Jim des Rividres and Daniel G Bobrovv, The A lt o f Ihc Metaobject Protocol, M IT Press, Cambridge, Mass., 1991 [28] John Lamping, "Typing the Specializanon Intertace, " Proceedings OOPSLA 93, A C M SIGPLAN Notices, vol 28’ no 10, Oct 1993, pp 201-214 [29] Xavier Leroy, "Manifest Types, Modules, and Separate Compilation," in Proceedings POPL'94, A C M Press, 1994, pp 109-122 [30] Xavier Leroy and Pierre Weisổ, Manuel de Référeiice du Langagc C AM L, InterEditions, 1994 Also available by w w \v at http://pauillac.inria.fr/doc-caml-light/refman.html [31] Satoshi Matsuoka and Akinori Yonezawa, "Analysis o f Inheritance Anomaly in Object-Oriented Concurrent Programming Languages," Research Directions in Concuưent Object-Oriented Programming, ed G Agha, p WegncM and A Yonezawa, M IT Press, Cambridge, Mass., 1993, pp 1071 50 [32] M -D - M cllro y, "Mass Produced Software Components," Software Eiis;ineering, ed p Naur and B.Randell, NATO Science Committee, Jan 1969, pp, 138-150 [33] Bertrand Meyer, Object- Oriented Software Conslniction, Prentice Hall, Englewood C liffs, NJ, 1988 [34] Robin M 'lner, Communication and Concuưency, Prentice Hall, Englewood C liffs, NJ, 1989 [35] Robin M ilner, "The Polyadic pi Calculus; a tutorial, " ECS-LFCS-91-180, Computer Science Dept., ưniversity of Edinburgh, Oct 1991 [36] Robin M ilne r' ioachim PaiTO\v and David W alker, "A Calciilus o f M ohile Processes, Part W l’ " lĩiíorm ation and Coinputation, vol 100, 1992, pp 1-77 [37] Robin M iliie r, Mads Tofte and Roberí Harper, The D efiĩiition ofsĩandaid M L , M IT Press, Cainbridge, Mass., 1990 [38] Peter D Mosses, "Denoiational Semantics," in ed J van Leinven Handbook o f Theoretical Computer Science, vol B' Elsevier, Amsterdam, 1990, pp 575-631 [39] NeXTstep Reference Manual, N eXT Computer, Inc., 1990 [40] Next Computer, Inc' and Sunsoft, Inc., Openstep Speciíìcáon' 1994 Available at ftp address ftp :// ftp.next.com/pub/Openstepspec/ [41] Oscar Nierstrasz, 'Towards an Object Calculus," Proceedinss o f the ECOOP ,91 W orkshop on Object-Based Concurrent Computing, ed M Tokoro o Nierstrasz, p Wegner, Lecture Notes in Computer Science, vol 612, SprineerVerlag, pp, 1-20, 1992 [42] Oscar Nierstrasz, Simon Gibbs and Dennis Tsichritzis, "ComponentOrienled Softwure Development'" Communications o f the A C M , vol 35, no Sept 1992’ pp 160-165' [43] Oscar Nierstrasz, " Composiiig Active Objects, " Research Direcrions in Concurreiìĩ Objcct- Orienled Prosramming, ed G Agha, p Wegiìer and A Yonezawa, M IT Press, Cambridee Mass., 1993’ pp 151-171 [44] Oscar Nierstrasz and Theo D irk M eijler, "Requirements for a Composition Laiiguage, " Proceedings o f the ECOOP '94 Workshop on Coordination Languages, ed p Ciancariiii, o Nierstrasz, A Yonezawa, Lecture Notes in Computer Science, Sprinaer-Verlag, 1995, to appear [45] Michael Papathomas and Oscar Nierstrasz’ "Supporting Software Reiise in Concuưenl ObjectOriented Languages: Exploring the Langua^e Desigii Space," Object Composition, ed D Tsichritzis, Centre Unịversitaire d'lnformatique, University o f Geneva, June 1991, pp 189-204 [46] Davide Sangiorgi’ "Expressiiig M o b ility in Process Algebras: First-()rder and Higher-Order Paradigms, " Ph.D thesis, CST-99-93 (aỉso: ECS-LFCS-93266), Computer Science Dept., University o f Edinburgh, May 1993[47] Alan Snyder, "Encapsulation and Inheritance in O bjecl-O riciited Programming Languages," Proceedings OOPSLA '86’ A C M SIGPLAN Noĩices, vol 21, no 11, Nov, 1986, pp 38-45 [48] Bent Thomsen, " Calculi for Higher Order Communicating S ystem s," Ph.D thesis, Imperial College, London, 1990 [49] Dennis Tsichritzis, " Object-Oriented Development for Opeii S vsten is," Infonnation Processing 89 (Proceedings IFIP ,89), North-Holland, San Praỉicisco, Aug 28-Sept 1, 1989, pp 1033-1040 [50] Jon U dell, "Componentxvare," in Byte, vol 19' no 5, May 1994, pp 46­ 56 [51] David Ungar and Randall B Smith, "Self; The Power o f Sỉm plicity," Proceedings OOPSLA 87’ A C M SIGPLAN Notices’ vol 22, no 12, Dec 1987, pp 227-242 [52] Larry W all and Randal L Schwartz, Programming Perl, 'R e illy & Associates, Inc., 1990 [53] Peter Wegner, '*Capitaỉ-Intensive Software Technology, " IEEE Software, vol, 1’ no 3, July 1984 [54] Peter Wegner, "Dimensions 0l Object-Based Language Design， ,’ Proceedings OOPSLA ,87' A C M SIGPLAN Notices, vol 22, no 12, Dec 1987' pp 168-182 [55] Peter Wegner and Stanley B Zdonik, "Inheritance as an Incrementai M odiĩication Mechanism or What Like Is and Isn't Like," Proceedings ECOOP 88, ed s, Gjessing and K Nygaard, Lecture Noies in Computer Science, vol 322, Springer-Verlag, Oslo, Aug 15-17, 1988, pp 55-77 [56] LE W hite, Telescript Technology: The Pounda ... nghệ hướng đối tượng đơn giản hóa nhiệnì vụ Sự hợp thành phần mềm hướng đối tượng tiếp nhận quan điểm công nghê hướng đối tượng chủ yếu kiến tạo ứng dụng phần mềm linh hoại từ thành phần phần mềm. .. bời ngôn ngữ hướng đối tượng M ột thành phần khái niệm trừu tượng phần mểm tĩnh, đối nghịch với đối tượng, mà hợp thành với thành phần khác để tạo nên ứng dụng Những loại khác thành phần xác định... phát triển hướng thành phần? ?? Những đối tượng động: đối tượng nhìn tác nhân độc lập trình Những Thành phần: thành phần khái niệm trừu tượng, mức cao hơn, qua khơng gian tính tốn cùa đối tượng tích