Khóa luận Tái kỹ nghệ hệ thống phần mềm

1 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Trần Thị Hồng Sim TÁI KỸ NGHỆ HỆ THỐNG PHẦN MỀM KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Công Nghệ Phần Mềm Cán bộ hướng dẫn: PGS.TS Nguyễn Văn Vỵ HÀ NỘI - 2010 1 Lời cảm ơn Lời đầu tiên, em muốn bày tỏ sự chân trọng và biết ơn sâu sắc đối với PGS.TS Nguyễn Văn Vỵ, giảng viên bộ môn Công Nghệ Phần Mềm, khoa Công Nghệ Thông Tin, trường Đại học Công Nghệ, Đại học Quốc Gia Hà Nội. Trong suốt quá trình học tập và thực hiện khóa luận này, thầy đã là người trực tiếp hướng dẫn và đưa ra những định hướng cho quá trình nghiên cứu. Chính nhờ sự tận tình chỉ bảo, dành rất nhiều thời gian quí báu của thầy trong suốt quá trình hướng dẫn mà em đã hoàn thành nghiên cứu khóa luận này. Em cũng xin gửi lời cảm ơn chân thành đến các thầy giáo, cô giáo là giảng viên trường Đại học Công Nghệ đã giảng dạy, truyền đạt kiến thức cho em trong suốt bốn năm học tại trường. Những kiến thức mà các thầy cô đã truyền thụ làm nền tảng cho em trong công việc sau này và là những kiến thức tiên quyết trong việc nghiên cứu và tìm hiểu đề tài trong khóa luận. Và cuối cùng, tôi xin gửi lời cảm ơn đến bạn bè, đồng nghiệp và đặc biệt là gia đình, những người đã luôn ở bên động viên, giúp đỡ, tạo điều kiện tốt nhất cho tôi trong suốt quá trình học tập và thực hiện khóa luận. Hà Nội, tháng 5/2010 Trần Thị Hồng Sim 2 Tóm tắt nội dung Ngày nay, công nghệ thông tin đang phát triển rất nhanh. Các hệ thống phần cứng của máy tính đang ngày càng trở nên mạnh mẽ hơn để đáp ứng nhu cầu ngày càng tăng của người sử dụng. Công nghệ thay đổi nhanh chóng theo từng ngày. Một hệ thống phần mềm hôm nay có thể là hiện đại nhưng chỉ sau một thời gian ngắn nó đã trở nên lạc hậu và không sử dụng hết được năng lực to lớn của phần cứng và không đáp ứng đầy đủ nhu cầu sử dụng của con người. Vậy chúng ta đang gặp phải một số lượng các hệ thống phần mềm có những đặc trưng này. Một giải pháp được đưa ra, đó chính là tái kỹ nghệ. Vì vậy đề tài “Tái kỹ nghệ hệ thống phần mềm” được chọn làm đề tài khóa luận của em. Để bảo trì, nâng cấp một hệ thống phần mềm lạc hậu, trong điều kiện cho phép có thể sử dụng giải pháp tái kỹ nghệ. Tuy nhiên, tái kỹ nghệ phải đi đôi với sự trợ giúp của những công cụ mạnh và có một quy trình thích hợp. Khóa luận trình bày một quy trình tái kỹ nghệ phần mềm với sự trợ giúp của công cụ Rational Rose. Bằng cách đó ta có thể nâng cấp một phần mềm cũ thành một phần mềm có khả năng đáp ứng các yêu cầu mới đặt ra và có được kiến trúc tốt, sử dụng hiệu quả nguồn tài nguyên hiện có, làm thuận lợi cho việc bảo trì tiếp tục sau này. Hơn thế nữa, quá trình tái kỹ nghệ hệ thống diễn ra một cách nhanh chóng và hiệu quả, đáp ứng được những thách thức đang đặt ra cho việc phát triển các phần mềm hiện nay.. Trong khóa luận này, những nội dung sau đây sẽ được trình bày: − Giới thiệu tổng quan về tái kỹ nghệ hệ thống phần mềm cùng và qui trình để thực hiện tái kỹ nghệ một hệ thống phần mềm. − Giới thiệu hai công cụ hỗ trợ cho quá trình tái kỹ nghệ trong phạm vi luận văn này là Rational Rose Enterprise Edition 7.0 và ngôn ngữ mô hình hóa (UML). − Sau khi đã hiểu về qui trình và cách thức thực hiện qui trình tái kỹ nghệ với các công cụ hỗ trợ, thực hiện tái kỹ nghệ một ứng dụng nhỏ để áp dụng là chương trình “Sổ địa chỉ”. 3 Mục lục Lời cảm ơn 1 Tóm tắt nội dung 2 Mục lục 3 Lời nói đầu 5 Chương 1: Tổng quan về tái kỹ nghệ 7 1.1 Bảo trì hệ thống phần mềm 7 1.2 Tổng quan chung về tái kỹ nghệ 9 1.3 Qui trình chung tái kỹ nghệ phần mềm 14 1.3.1 Dịch mã nguồn..............................................................................................15 1.3.2 Kỹ nghệ ngược ..............................................................................................17 1.3.2.1 Làm lại tài liệu ..........................................................................................19 1.3.2.2 Phục hồi thiết kế.........................................................................................19 1.3.3 Cấu trúc lại hệ thống ....................................................................................20 1.3.4 Module hóa chương trình..............................................................................25 1.3.5. Tái kỹ nghệ dữ liệu.......................................................................................26 1.4 Các công cụ sử dụng cho tái kỹ nghệ 30 1.4.1 Ngôn ngữ UML .............................................................................................30 1.4.2 Hệ thống phần mềm RATIONAl ROSE ..........................................................33 1.4.3 Tái kỹ nghệ hệ thống với kỹ nghệ đảo ngược của Rational Rose....................41 1.5 Những ưu điểm và hạn hế của tái kỹ nghệ 45 1.5.1 Các ưu điểm..................................................................................................45 1.5.2 Các hạn chế ..................................................................................................45 1.6 Kết luận 46 Chương 2: Bài toán về chương trình “Sổ địa chỉ” 47 2.1 Giới thiệu chương trình sổ địa chỉ 47 1.2 Những vấn đề cần cải tiến chương trình 48 Chương 3: Tái kỹ nghệ chương trình sổ địa chỉ 50 4 3.1 Sơ đồ tiến trình thực hiện tái kỹ nghệ 50 3.2 Qui trình thực hiện tái kỹ nghệ chương trình sổ địa chỉ 50 3.2.1 Xây dựng tài liệu và mô hình thiết kế UML ...................................................51 3.2.2 Cấu trúc lại chương trình..............................................................................55 3.2.3 Tái kỹ nghệ dữ liệu........................................................................................58 3.2.4 Xây dựng mã nguồn ......................................................................................60 3.2.5 Hoàn thiện, cài đặt và sử dụng......................................................................60 3.3 Kết quả đạt được và một số đánh giá 60 3.3.1. Liên quan đến chương trình .........................................................................60 3.3.2. Liên quan đến triển khai...............................................................................62 3.3.3. Một số vấn đề tồn tại....................................................................................62 Kết luận 63 Tài liệu tham khảo 64 Tiếng Việt 64 Tiếng Anh 64 5 Lời nói đầu Ngày nay, chúng ta đang sống trong một kỉ nguyên của công nghệ thông tin. Với sự bùng nổ của công nghệ thông tin, sự hỗ trợ của máy tính cho các hoạt động của con người ngày càng trở nên cần thiết hơn bao giờ hết. Để đáp ứng những nhu cầu thiết yếu này, các phần mềm phục vụ con người ngày càng phổ biến hơn, số lượng lớn hơn và được nâng cấp để có chất lượng tốt hơn. Tuy nhiên, cùng với xu hướng phát triển của phần mềm, các hệ thống phần cứng, các chương trình hỗ trợ cũng như các môi trường phát triển, hay các qui trình nghiệp vụ cũng luôn đổi mới với tốc độ không ngừng. Ngày hôm nay, một hệ thống có thể là hiện đại, tối tân nhưng đến ngày mai nó đã trở nên lạc hậu và còn có thể không dùng được nữa. Trước sự thay đổi nhanh chóng của các công cụ, môi trường hỗ trợ này, các phần mềm cũ có nguy cơ bị bỏ đi. Vậy phải làm sao để giải quyết vấn đề này khi mà số lượng các phần mềm cũ ngày càng lớn? Nhiều giải pháp được đưa ra cho việc bảo trì phần mềm. Bảo trì phần mềm chính là một giai đoạn trong quy trình tiến hóa phần mềm. Đây là giai đoạn có chi phí tốn kém nhất, như ta đã biết, nó chiếm đến 70% trong tổng chi phí phát triển phần mềm. Tuy nhiên, nếu chúng ta thực hiện phát triển mới phần mềm thì chi phí bỏ ra còn lớn hơn rất nhiều. Cho nên một yêu cầu được đặt ra là phải lựa chọn một phương pháp bảo trì phần mềm sao cho có hiệu quả cao và giảm thiểu các rủi ro. Với một chương trình phần mềm đã sử dụng trong thời gian dài, nó có thể gặp phải các vấn đề như ngôn ngữ lập trình không còn được sử dụng, thiếu các công cụ hỗ trợ cần thiết, không đáp ứng đủ yêu cầu của người dùng v.v… Vì vậy, để có thể tiếp tục sử dụng được hệ thống phần mềm, ta thực hiện quá trình bảo trì cần phải có biện pháp xây dựng, cấu trúc lại những phần chương trình đã trở nên lạc hậu và không dùng được nữa. Và một phương pháp rất phổ biến và hiệu quả của ngày nay, đó chính là tái kỹ nghệ lại hệ thống phần mềm. Tái kỹ nghệ là một phương pháp tiến hóa phần mềm có hiệu quả cao trong khi chi phí bỏ ra ít hơn nhiều so với việc xây dựng mới phần mềm cũng như so với một số phương pháp tiến hóa khác. Có được điều này bởi quy trình tái kỹ nghệ được hỗ trợ bởi các công cụ và phương tiện mới với một quy trình khép kín khá hoàn thiện và đầy đủ. Một số công cụ hỗ trợ cho việc tái kỹ nghệ phần mềm như ngôn ngữ mô hình hóa 6 thống nhất UML, Rational Software Architecture, Rational Rose v.v… Trong phạm vi khóa luận tốt nghiệp này, chúng ta sẽ sử dụng hai công cụ hỗ trợ cho việc tái kỹ nghệ là ngôn ngữ UML và Rational Software Architecture. Cùng với việc tìm hiểu về quy trình tái kỹ nghệ, để có thể hiểu sâu hơn các bước thực hiện của quy trình, ta sẽ thực hiện tái kỹ nghệ cho một chương trình đơn giản là: Sổ địa chỉ. Cụ thể khóa luận tốt nghiệp này được xây dựng gồm ba chương: - Chương 1: Trình bày tổng quan về tái kỹ nghệ và phương pháp để tái kỹ nghệ một hệ thống phần mềm - Chương 2: Giới thiệu qua về chương trình “Sổ địa chỉ” - Chương 3: Thực hiện tái kỹ nghệ chương trình “Sổ địa chỉ”, từ đó rút ra những kết quả đánh giá cho chương trình và những hạn chế còn tồn tại trong nội dung khóa luận. Cuối cùng là kết luận và tài liệu tham khảo 7 Chương 1: Tổng quan về tái kỹ nghệ Tính tái dụng là một đặc trưng quan trọng của các thành phần phần mềm chất lượng cao. Tính tái dụng ở đây được hiểu là các thành phần của một hệ thống phần mềm có thể sử dụng lại trong các hệ thống phần mềm khác. Một vấn đề lớn đặt ra là: phải phát triển phần mềm như thế nào để về sau có thể sử dụng lại nhiều nhất và hiệu quả nhất. Nói chung, sau một thời gian sử dụng, các phần mềm cần phải được bảo trì để đáp ứng các yêu cầu phát sinh của người sử dụng, của công nghệ mới, và sự thay đổi của các hoạt động nghiệp vụ theo thời gian... đúng theo nghĩa vòng đời của một hệ thống phần mềm, ta lại bắt đầu các công việc: phân tích, thiết kế, cài đặt, kiểm thử... ở mức cao hơn. Như vậy, việc tái sử dụng các phần đó được xây dựng trước đây có ý nghĩa to lớn cho việc tiết kiệm công sức, thời gian, kinh phí...trong hoạt động phát triển. Có nhiều cách thực hiện việc bảo trì hệ thống phần mềm và cũng có nhiều công cụ để thiết kế lại phần mềm. Mỗi công cụ thiết kế lại phần mềm đều có những ưu và nhược điểm riêng, tuỳ theo hoàn cảnh thực tế mà ta có thể lựa chọn một công cụ sao cho hiệu quả nhất. Dưới đây sẽ trình bày một số vấn đề về tái kỹ nghệ hệ thống phần mềm bằng UML (Unified Modeling Language) và công cụ Rational Rose. 1.1 Bảo trì hệ thống phần mềm Phát triển phần mềm phải trải qua nhiều giai đoạn. Các giai đoạn đó bao gồm: phân tích yêu cầu, kiến trúc hệ thống, thiết kế, cài đặt, kiểm thử, triển khai phần mềm và bảo trì. Bảo trì chính là giai đoạn cuối trong vòng đời phát triển phần mềm. Bảo trì bảo đảm cho hệ thống được tiếp tục hoạt động sau khi thực hiện kiểm thử hay sau khi đưa hệ thống vào hoạt động trong thực tế. Bảo trì phần mềm bao gồm những sửa đổi làm hệ thống thích nghi với những yêu cầu thay đổi của người sử dụng, thay đổi dữ liệu cho phù hợp, gỡ rối, khử bỏ và sửa chữa các sai sót mà trước đây chưa phát hiện ra... Ngày nay, việc xây dựng, phát triển cũng như quá trình bảo trì các hệ thống phần mềm được hỗ trợ nhiều bởi các công cụ, đó là kĩ nghệ phần mềm có máy tính trợ giúp (CASE). Công nghệ CASE đang phát triển mạnh mẽ, bao gồm các công cụ về: lập kế hoạch quản lý dự án, các công cụ trợ giúp phân tích và thiết kế, cài đặt hệ thống, tích 8 hợp và kiểm thử, làm bản mẫu …, Ở đây chúng ta sẽ quan tâm tới một số hoạt động trong quá trình bảo trì phần mềm bằng một số công cụ có sẵn. Các hoạt động trong bảo trì phần mềm bao gồm: − Trong quá trình kiểm thử, theo dõi quá trình hoạt động của hệ thống phần mềm, ta sẽ phát hiện ra tất cả các lỗi, các sai sót tiềm tàng trong hệ thống, tất cả các lỗi đó sẽ được thông báo cho các chuyên gia phát triển phần mềm để họ cập nhật lại. Tiến trình đó được gọi là bảo trì sửa chữa. − Theo thời gian, các khía cạnh xử lý và hệ thống phần cứng thay đổi; môi trường làm việc như hệ điều hành thay đổi; các thiết bị ngoại vi và các phần tử của hệ thống được nâng cấp; các yêu cầu của khách hàng cho hệ thống sẽ thay đổi... Điều đó dẫn tới việc phải thay đổi hệ thống phần mềm sao cho phù hợp với các yêu cầu thay đổi trên, quá trình đó được gọi là bảo trì thích nghi. − Khi hệ thống phần mềm thành công và được đưa vào sử dụng, người ta nhận được các khuyến cáo về khả năng mới, các chức năng cần được bổ sung nâng cao... Đó là quá trình nâng cấp hệ thống phần mềm cho phù hợp và tiện dụng hơn, được gọi là bảo trì hoàn thiện. − Hệ thống cần phải thay đổi để đảm bảo tính tin cậy, an toàn trong tương lai, tạo cơ sở tốt hơn cho việc nâng cao chất lượng trong tương lai, tiến trình đó được gọi là bảo trì phòng ngừa, hoạt động này được đặc trưng bởi các kĩ thuật đảo ngược và tái kĩ nghệ. Các công cụ bảo trì phần mềm có thể được chia theo các chức năng sau: − Kĩ nghệ ngược với các công cụ đặc tả: nhận chương trình gốc làm đầu vào và sinh ra các mô hình phân tích và thiết kế có cấu trúc đồ thị, các thông tin thiết kế khác. − Công cụ tái cấu trúc và phân tích mã: phân tích cú pháp chương trình, sinh ra đồ thị luồng điều khiển, và sinh tự động một chương trình có cấu trúc. − Công cụ tái kĩ nghệ hệ thống trực tuyến: dùng để thay đổi các hệ thống cơ sở dữ liệu trực tuyến. Bảo trì là giai đoạn cuối cùng trong tiến trình kĩ nghệ phần mềm, nó tiêu tốn rất nhiều thời gian, công sức và kinh phí. Tái kỹ nghệ là công nghệ đặc trưng giúp cho việc bảo trì các hệ thống phần mềm hiệu quả và nhanh chóng. 9 1.2 Tổng quan chung về tái kỹ nghệ Bản chất của việc tái kỹ nghệ phần mềm là để cải tiến hoặc biến đổi những phần mềm đã có để nó có thể hiểu, điều khiển hay sử dụng được bằng một cách khác. Ngày nay, số lượng các hệ thống được xây dựng từ đầu đang giảm dần, trong khi đó các hệ thống chúng ta được kế thừa lại ngày càng nhiều. Chức năng của các hệ thống đó vẫn không đổi nhưng hệ thống phần cứng, các công nghệ, môi trường làm việc thì ngày một đổi mới. Những hệ thống phần mềm được kế thừa lại đã trở nên lạc hậu, một số cấu trúc chương trình đã không còn dùng được nữa do đó nhu cầu tái kỹ nghệ phần mềm được tăng lên đáng kể. Việc tái kỹ nghệ phần mềm trở nên rất quan trọng trong việc phục hồi và tái sử dụng lại những phần mềm hiện có, làm cho chi phí bảo trì phần mềm có thể kiểm soát được và tạo ra cơ sở cho việc tiến hóa phần mềm trong tương lai. Thuật ngữ “Tái kỹ nghệ” nhanh chóng trở thành một từ được yêu thích đối với những nhà quản lý và phát triển phần mềm, nhưng nó thực sự có ý nghĩa như thế nào đối với họ? Về cơ bản thì tái kỹ nghệ là lấy các phần mềm được thừa kế hiện có mà việc bảo trì đối với chúng là rất đắt, hoặc là những thành phần, kiến trúc của hệ thống đã không dùng được nữa và làm lại nó bằng những công nghệ phần mềm và phần cứng hiện thời. Vấn đề khó khăn ở đây là phải có sự hiểu biết về những hệ thống đó. Thường thì những tài liệu phân tích yêu cầu, tài liệu thiết kế và tài liệu về mã nguồn của chương trình không còn nữa, hoặc nếu còn thì đã quá lỗi thời. Vì vậy để hiểu các chức năng không còn sử dụng được một cách rõ ràng là một điều khó khăn. Thường thì hệ thống cũ vẫn bao gồm cả những chức năng không cần thiết nữa vì vậy những chức năng này không cần đưa vào hệ thống mới. Vậy thế nào là tái kỹ nghệ? Chikofsky và Cross đã định nghĩa tái kỹ nghệ là: “ kiểm tra, phân tích, biến đổi hệ thống phần mềm hiện thời để xây dựng lại thành một hệ thống mới, và bổ sung thêm một số thành phần mới vào trong đó” (Chikofsky 1990). Định nghĩa này rõ ràng tập trung vào làm sáng tỏ đặc trưng của thuật ngữ, các thay đổi của kết quả phần mềm. Arnold, đã định nghĩa một cách khác về tái kỹ nghệ là: “bất kỳ hoạt động nào làm cải tiến sự hiểu biết về phần mềm, hoặc là hoạt động cải tiến phần mềm và thường tăng khả năng bảo trì, khả năng sử dụng lại, khả năng tiến hóa” (Arnold 1993). Qui trình tái kỹ nghệ thường là sự kết hợp của nhiều qui trình khác nhau như kỹ nghệ ngược, làm lại tài liệu, cấu trúc lại chương trình, chuyển đổi và kỹ nghệ xuôi, dịch hệ thống sang một ngôn ngữ lập trình hiện đại hơn. Mục đích là để có cái nhìn rõ 10 hơn về chương trình hiện thời (đặc tả, thiết kế, thực thi), sau đó tái thực hiện lại để cải thiện các chức năng, hiệu suất, sự thi hành của hệ thống. Mục tiêu là để duy trì các chức năng hiện có và chuẩn bị cho các chức năng mới sẽ được thêm vào sau này. Sau khi sửa đổi, các chức năng chính của phần mềm không thay đổi, và thông thường thì cấu trúc của chương trình vẫn được giữ nguyên như cũ. Đứng từ quan điểm kỹ thuật, tái kỹ nghệ phần mềm chỉ là giải pháp thứ hai trong vấn đề phát triển phần mềm sau lựa chọn giải pháp phát triển mới hệ thống phần mềm. Nguyên nhân là do cấu trúc phần mềm không được nâng cấp vì thế việc phân phối những hệ thống có tính tập trung là một việc khó. Nó thường không thể thay đổi triệt để ngôn ngữ lập trình hệ thống vì hệ thống cũ với ngôn ngữ lập trình thủ tục thì khó có thể chuyển đổi sang những ngôn ngữ lập trình hướng đối tượng như Java hay C++. Do đó, những giới hạn cố hữu tồn tại trong hệ thống vẫn sẽ duy trì bởi vì chức năng của phần mềm không được thay đổi. Tuy nhiên, đứng từ quan điểm nghiệp vụ, tái kỹ nghệ phần mềm là con đường duy nhất có thể đảm bảo rằng một hệ thống cũ vẫn có thể tiếp tục phục vụ. Sẽ là quá đắt và quá rủi ro nếu như chấp nhận một cách tiếp cận khác trong việc phát triển phần mềm. Để hiểu được những lí do cho vấn đề này, chúng ta sẽ đưa ra một đánh giá sơ bộ về những vấn đề của hệ thống phần mềm cũ. Số lượng mã nguồn của một hệ thống cũ là rất lớn. Năm 1990, nó được ước đoán (Ulrich 1990) là có khoảng 120 tỉ dòng mã nguồn tồn tại. Phần lớn những hệ thống này được viết bằng COBOL, một ngôn ngữ lập trình thích hợp nhất cho qui trình dữ liệu nghiệp vụ, hoặc bằng FORTRAN. FORTRAN là một ngôn ngữ lập trình toán học và khoa học. Những ngôn ngữ này có cấu trúc chương trình rất giới hạn, và trong trường hợp của FORTRAN, rất giới hạn trong việc hỗ trợ cấu trúc dữ liệu. Mặc dù nhiều chương trình đã được thay thế, nhưng hầu hết trong số chúng vẫn đang được sử dụng. Trong khi đó, từ năm 1990 đã có một sự gia tăng rất lớn trong việc sử dụng máy tính để hỗ trợ qui trình nghiệp vụ. Do đó đến năm 2000 đã có khoảng 250 tỉ dòng mã nguồn đang tồn tại và phải được duy trì. Phần lớn trong số đó không được viết bằng các ngôn ngữ hướng đối tượng và số nhiều trong đó vẫn được chạy trên các máy tính lớn. Có nhiều hệ thống để tiếp tục tồn tại phải thay đổi hoàn toàn hoặc cấu trúc lại hệ thống căn bản do đó kinh phí sẽ phải bỏ ra là một điều không tưởng được đối với hầu hết các tổ chức. Bảo trì một hệ thống cũ ngày càng đắt tiền, vì vậy tái kỹ nghệ lại những hệ thống này sẽ kéo dài thời gian sử dụng của chúng. Tái kỹ nghệ một hệ thống sẽ có chi phí hiệu quả khi hệ thống đó có giá trị nghiệp vụ cao nhưng lại 11 tốn kém cho việc bảo trì. Tái kỹ nghệ cải thiện cấu trúc hệ thống, tạo ra tài liệu của hệ thống mới và làm cho nó dễ hiểu hơn. Vậy trong trường hợp nào chúng ta nên thực hiện tái kỹ nghệ hệ thống. Câu trả lời là tái kỹ nghệ sẽ có hiệu quả cao nhất khi thực hiện đối với một hệ thống cũ được kế thừa lại (legacy system). Một hệ thống cũ được kế thừa lại có thể là một phương thức, công nghệ đã cũ, một hệ thống máy tính hay một chương trình ứng dụng lạc hậu vẫn đang tiếp tục được sử dụng bởi các chức năng của nó vẫn đang đáp ứng những nhu cầu của người dùng. Tuy nhiên, các hệ thống này sẽ không có hiệu quả cao do công nghệ đã lạc hậu và các thủ tục hay các nền tảng hỗ trợ đã không còn tồn tại. Hơn thế nữa, các hệ thống này thường không còn các tài liệu đặc tả, phân tích, các mô hình thiết kế. Vì vậy, để có thể xây dựng lại hệ thống cần phải có sự hiểu biết sâu sắc về nó. Do đó, tái kỹ nghệ là lựa chọn tốt nhất trong những trường hợp này. Tái kỹ nghệ giai đoạn cũng liên kết với tái kỹ nghệ tiến trình nghiệp vụ (Hammer, 1990). Tái kỹ nghệ tiến trình nghiệp vụ cũng liên quan với tiến trình nghiệp vụ tái thiết kế để giảm số lượng các hoạt động dự phòng và nâng cao hiệu quả của qui trình. Nó thường phụ thuộc vào việc giới thiệu hoặc tăng cường hỗ trợ dựa trên máy tính cho quá trình này. Kỹ thuật dịch xuôi Tái kỹ nghệ phần mềm Hình 1-01 Sự khác biệt then chốt giữa tái kỹ nghệ và phát triển một hệ thống phần mềm mới chính là điểm xuất phát cho việc phát triển. Đối với việc phát triển một hệ thống phần mềm mới, công việc sẽ bắt đầu với việc viết một tài liệu đặc tả cho hệ thống, trong khi đối với tái kỹ nghệ, hệ thống cũ đã đóng vai trò như một bản đặc tả cho hệ thống mới. Chikofsky và Cross (Chikofsky and Cross, 1990) đã đưa ra thuật ngữ “kỹ nghệ xuôi” (forward engineering) trong tiến trình phát triển để phân biệt với tái kỹ nghệ phần Đặc tả hệ thống Thiết kế và thực thi Hệ thống mới Hệ thống phần mềm hiện thời Hệ thống tái kỹ nghệ Hiểu và chuyển đổi 12 mềm. Sự khác biệt này được minh họa ở hình 1-01. Kỹ thuật dịch xuôi bắt đầu với việc đặc tả hệ thống và bao gồm cả việc thiết kế và thực thi trong hệ thống mới. Tái kỹ nghệ bắt đầu với một hệ thống đã tồn tại và sau đó thực hiện các qui trình phát triển để thay thế, biến đổi một số thành phần của hệ thống dựa trên những hiểu biết về hệ thống gốc. Hình 1-02: Qui trình tái kỹ nghệ Hình 1-02 mô tả một qui trình tái kỹ nghệ có khả năng thực hiện được. Đầu vào của qui trình là một chương trình được kế thừa và đầu ra là một phiên bản có các module có cấu trúc rõ ràng của chính chương trình đó. Đồng thời cũng như là tái kỹ nghệ chương trình, dữ liệu cho hệ thống cũng có thể được tái kỹ nghệ lại. Các hoạt động trong qui trình tái kỹ nghệ là: 1 Dịch mã nguồn Chương trình được chuyển đổi từ một ngôn ngữ lập trình cũ sang một phiên bản mới hơn hoặc chuyển sang một ngôn ngữ khác. 2 Kỹ nghệ ngược Chương trình được phân tích và lấy thông tin để làm tài liệu cho tổ chức và các chức năng của chương trình. 3 Cải tiến cấu trúc hệ thống Cấu trúc điều khiển của chương trình được phân tích và sửa đổi để giúp cho việc đọc và hiểu được dễ dàng hơn. Chương trình nguồn Tài liệu chương trình Chương trình module hóa Dữ liệu nguồn Chương trình được cấu trúc Dữ liệu được tái kỹ nghệ Dịch mã nguồn Kỹ nghệ ngược Cải tiến cấu trúc chương trình Module hóa chương Tái kỹ nghệ dữ liệu 13 4 Module hóa hệ thống Liên kết các phần của chương trình thành một nhóm với nhau, và những thành phần riêng biệt, dư thừa được bỏ đi. Trong một vài trường hợp, giai đoạn này có thể bao gồm cả việc biến đổi cấu trúc chương trình. 5 Tái kỹ nghệ dữ liệu Dữ liệu xử lý bởi chương trình được thay đổi để phản hồi lại những thay đổi của chương trình. Tái kỹ nghệ chương trình có thể không cần thiết phải đầy đủ tất cả các bước như trong hình 2. Việc dịch mã nguồn có thể không cần thiết nếu ngôn ngữ chương trình sử dụng để phát triển hệ thống vẫn được các trình biên dịch hiện thời hỗ trợ. Nếu các công cụ tự động phục vụ cho quá trình tái kỹ nghệ có thể tin tưởng hoàn toàn thì những tài liệu có được thông qua hoạt động kỹ nghệ ngược có thể không cần thiết. Tái kỹ nghệ dữ liệu chỉ cần thiết nếu cấu trúc dữ liệu trong chương trình thay đổi trong quá trình tái kỹ nghệ hệ thống. Tuy nhiên, tái kỹ nghệ phần mềm luôn bao gồm việc cấu trúc lại chương trình. Chi phí của tái kỹ nghệ hiển nhiên được quyết định bởi qui mô công việc cần phải được tiến hành. Chi phí của các phương pháp tiếp cận đến tái kỹ nghệ được thể hiện trong hình 1-03. Chi phí tăng từ trái qua phải, vì thế chuyển đổi mã nguồn là lựa chọn rẻ nhất và tái kỹ nghệ chính là một phần của việc chuyển hướng cấu trúc là cái có chi phí cao nhất. Chi phí tăng Hình 1-03: Chi phí tái kỹ nghệ Ngoại trừ qui mô của hoạt động tái kỹ nghệ, các yếu tố ảnh hưởng đến chi phí của tái kỹ nghệ là: Tổ chức lại chương trình và dữ liệu Tổ chức lại chương trình tự động Chuyển đổi mã nguồn tự động Tổ chức lại tự động với thay đổi thủ công Tổ chức lại cộng với thay đổi kiến trúc 14 1 Chất lượng của phần mềm để tái kỹ nghệ. Chất lượng phần mềm và các tài liệu liên quan (nếu có) càng thấp thì chi phí cho việc tái kỹ nghệ sẽ càng cao. 2 Công cụ hỗ trợ có sẵn cho việc tái kỹ nghệ. Hoạt động tái kỹ nghệ sẽ không có chi phí hiệu quả nếu không có các công cụ được sử dụng trong đó. Và Công cụ CASE là một công cụ cần thiết tất yếu cho hoạt động tái kỹ nghệ vì nó có thể tự động trong việc chuyển đổi chương trình, và vì thế làm giảm chi phí đáng kể. 3 Phạm vi của chuyển đổi dữ liệu thiết yếu. Nếu tái kỹ nghệ phụ thuộc lớn vào khối lượng dữ liệu được chuyển đổi, nó làm tăng đáng kể chi phí của tiến trình. 4 Tính sẵn có của đội ngũ nhân viên chuyên môn. Nếu nhân viên chịu trách nhiệm bảo trì hệ thống không thể tham gia vào qui trình tái kỹ nghệ, điều này sẽ làm gia tăng chi phí. Các kỹ sư tái kỹ nghệ hệ thống sẽ phải mất rất nhiều thời gian để có thể thực sự hiểu được hệ thống. 1.3 Qui trình chung tái kỹ nghệ phần mềm Hình 1-04: Mô hình hoạt động tái kỹ nghệ Tái kỹ nghệ sẽ bắt đầu với mã nguồn của chương trình được kế thừa lại và kết thúc với mã nguồn của chương trình đích. Qui trình này có thể chỉ đơn giản là việc sử dụng một công cụ dịch mã để dịch mã nguồn từ ngôn ngữ này sang ngôn ngữ khác (từ Khái niệm Yêu cầu Thiết kế Triển khai Khái niệm Yêu cầu Thiết kế Triển khai Kỹ nghệ ngược (Trừu tượng) Kỹ nghệ xuôi (Cải tiến) (Biến đổi) Nghĩ lại Đặc tả lại Thiết kế Code lại So sánh chất lượng chức năng Hệ thống đích Hệ thống ban đầu 15 FORTRAN sang C ) hay từ hệ điều hành này sang hệ điều hành khác (từ Linux sang Window). Mặt khác, công việc tái kỹ nghệ cũng có thể rất phức tạp: sử dụng mã nguồn chương trình đã có để xây dựng lại thiết kế, xác định các yêu cầu của hệ thống đó sau đó so sánh chúng với yêu cầu hiện tại, từ đó loại bỏ đi những cái không còn khả năng ứng dụng nữa, tổ chức và thiết kế lại hệ thống (sử dụng thiết kế hướng đối tượng), và cuối cùng là xây dựng mã cho hệ thống mới. Chúng ta có thể hình dung rõ hơn về mô hình chung của hoạt động tái kỹ nghệ phần mềm qua hình 1-04. Có thể đưa ra một công thức cho quá trình tái kỹ nghệ dựa trên hình 1-04 như sau: Tái kỹ nghệ = kỹ nghệ ngược + biến đổi + kỹ nghệ xuôi Phải chú ý rằng, đôi khi tái kỹ nghệ và kỹ nghệ ngược được xem như là hai mặt hoàn toàn khác nhau. Nhưng trong thực tế thì kỹ nghệ ngược được xem như là một phần của qui trình tái kỹ nghệ. Thành phần đầu tiên trong qui trình tái kỹ nghệ, “kỹ nghệ ngược”, là hoạt động nhằm xác định những vấn đề trừu tượng và xây dựng lại làm cho hệ thống trở nên dễ hiểu, dễ trình bày hơn. Mục đích chính ở đây là phải nắm bắt được những hiểu biết về hành vi và cấu trúc của hệ thống, và có thể giao tiếp được với những phần khác. Thành phần thứ hai, “thay đổi”, chính là những thay đổi cần thiết cho hệ thống. Những thay đổi này được thể hiện trong hai phạm vi trực giao. Một là những thay đổi ở chức năng và một là những thay đổi công nghệ của các thành phần. Các thay đổi chức năng đến từ các yêu cầu phải thay đổi các qui tắc nghiệp vụ của chương trình. Do đó, khi chúng ta sửa đổi các qui tắc nghiệp vụ sẽ dẫn đến kết quả sửa đổi hệ thống. Còn đối với thay đổi công nghệ của hệ thống thông tin có nghĩa là tổ chức sẽ sử dụng một ngôn ngữ lập trình, một công cụ hay một cơ sở dữ liệu mới để thay thế cho cái cũ. Cuối cùng khi mọi vấn đề đã được hiểu thấu đáo, chúng ta sẽ sử dụng kỹ nghệ xuôi để xây dựng hệ thống mới, với những cải tiến trong qui trình. 1.3.1 Dịch mã nguồn Dạng đơn giản nhất của tái kỹ nghệ phần mềm là dịch mã nguồn từ ngôn ngữ này sang một ngôn ngữ khác bằng các công cụ dịch tự động. Do đó cấu trúc của chương trình hoàn toàn không thay đổi. Ngôn ngữ đích có thể là một phiên bản mới hơn của ngôn ngữ gốc (ví dụ từ COBOL-74 sang COBOL-85) hoặc là một ngôn ngữ hoàn toàn khác (ví dụ từ FORTRAN sang C). Cần phải chuyển đổi mã nguồn vì những lý do sau đây: 16 1 Nền phần cứng được cập nhật. Các tổ chức có thể sẽ muốn thay đổi nền phần cứng tiêu chuẩn của họ. Trong khi đó các trình biên dịch của ngôn ngữ hiện thời lại không được hỗ trợ trên phần cứng mới đó. 2 Thiếu nhân viên có kỹ năng. Có thể sẽ thiếu nhân viên bảo trì lành nghề cho ngôn ngữ hiện tại. Hơn nữa, đây lại là một chương trình được viết bằng một ngôn ngữ không theo tiêu chuẩn chuẩn và hiện tại đã không còn được sử dụng. 3 Những thay đổi chính sách tổ chức. Một tổ chức hoàn toàn có thể quyết định những tiêu chuẩn cho ngôn ngữ lập trình của họ để có thể giảm đến mức tối thiểu chi phí cho phần mềm. Tuy nhiên việc bảo trì các phiên bản cũ của các trình biên dịch đó lại trở nên rất đắt. 4 Thiếu những sự trợ giúp phần mềm. Các nhà cung cấp các trình biên dịch đã từ bỏ việc kinh doanh hoặc đã ngừng hỗ trợ cho sản phẩm của họ. Hình 1-05: Qui trình dịch mã nguồn Hình 1-05 mô tả qui trình dịch mã nguồn. Có thể không cần hiểu hoạt động chi tiết của phần mềm hoặc sửa đổi cấu trúc của hệ thống. Những phân tích liên quan có thể tập trung vào ngôn ngữ lập trình và có thể coi nó tương đương như cấu trúc điều khiển của chương trình. Dịch mã nguồn sẽ chỉ thực sự kinh tế nếu như việc dịch tự động sẵn sàng cho việc dịch một số lượng lớn bản dịch. Nó có thể là một chương trình được viết đặc biệt, một công cụ được mua để chuyển đổi từ ngôn ngữ này sang ngôn ngữ khác hoặc một mô hình hệ thống thích hợp. Trong trường hợp thứ hai, cần phải xây dựng tập hợp những hướng dẫn làm thế nào để chuyển đổi từ sự trình bày này sang sự trình bày Hệ thống được tái kỹ nghệ Hệ thống được tái kỹ nghệ Hệ thống tái kỹ nghệ Xác định sự khác biệt của mã nguồn Thiết kế tài liệu chuyển đổi Dịch mã tự động Dịch mã thủ công 17 khác. Các mẫu tham số trong ngôn ngữ gốc phải được xác định và liên kết với các mẫu tương đương trong ngôn ngữ đích. Trong nhiều trường hợp, việc dịch tự động hoàn toàn là điều không thể. Cấu trúc trong ngôn ngữ nguồn có thể không tương đương với ngôn ngữ đích. Có thể mã nguồn được nhúng vào các lệnh điều kiện trong trình biên dịch mà trong ngôn ngữ đích không được hỗ trợ. Trong những trường hợp này, chúng ta phải thực hiện những thay đổi một cách thủ công để điều chỉnh và cải tiến hệ thống tạo ra. 1.3.2 Kỹ nghệ ngược Kỹ nghệ ngược là qui trình phân tích phần mềm với mục đích để phục hồi những đặc tả và thiết kế của phần mềm đó. Kỹ nghệ ngược không làm thay đổi hệ thống hoặc tạo ra một hệ thống mới, nó chỉ là quá trình kiểm tra mà không thay đổi chức năng tổng thể của chương trình. Trong qui trình kỹ nghệ ngược, mã nguồn của chương trình chính là đầu vào. Tuy nhiên, đôi khi ngay cả mã nguồn cũng không còn thì qui trình kỹ nghệ ngược phải bắt đầu với mã thực thi của chương trình. Nhiều người cho rằng, tái kỹ nghệ và kỹ nghệ ngược là những tên gọi khác nhau của cùng một quá trình, nhưng trong thực tế kỹ nghệ ngược không phải là tái kỹ nghệ. Mục đích của kỹ nghệ ngược là để thu được thiết kế hoặc đặc tả của hệ thống từ mã nguồn của nó. Trong khi đó, mục đích của tái kỹ nghệ là để tạo ra một hệ thống mới có khả năng bảo trì cao xuất phát từ một hệ thống cũ. Như vậy, kỹ nghệ ngược là một quá trình giúp cho nhà phát triển có những cái nhình rõ ràng hơn về hệ thống, và nó chính là một phần của qui trình tái kỹ nghệ. Những ảnh hưởng của quá trình này sẽ ảnh hưởng tới thành công của dự án tái kỹ nghệ. Kỹ nghệ ngược thường được sử dụng trong qui trình tái kỹ nghệ phần mềm để khôi phục lại thiết kế và những đặc tả của chương trình, từ đó giúp cho các kỹ sư tái kỹ nghệ có thể hiểu rõ hơn trước khi bắt tay vào việc tổ chức lại cấu trúc của chương trình. Tuy nhiên, kỹ nghệ ngược không nhất thiết phải luôn có trong qui trình tái kỹ nghệ. 1. Thiết kế và đặc tả của một hệ thống đang tồn tại có thể được kỹ nghệ ngược, vì vậy chúng có thể được sử dụng như một đầu vào, và chính là đặc tả yêu cầu của hệ thống thay thế. 2. Ngoài ra, việc thiết kế và đặc tả có thể được kỹ nghệ ngược, do đó nó luôn sẵn sàng cho việc bảo trì chương trình. Với những thông tin bổ sung, chúng ta có thể không cần thiết phải kỹ nghệ lại mã nguồn của hệ thống. 18 Hình 1-06: Mô hình qui trình kỹ nghệ ngược Qui trình kỹ nghệ ngược được chỉ ra trong hình 1-06, bắt đầu bằng việc lấy ra các thông tin về yêu cầu và thiết kế chi tiết từ mã nguồn của chương trình và các tài liệu còn tồn tại (nếu có). Sau qui trình, chúng ta sẽ thu được một tài liệu yêu cầu và một bản thiết kế trừu tượng ở mức độ cao được thể hiện bằng biểu đồ luồng dữ liệu và luồng điều khiển. Như vậy, hai công việc quan trọng trong kỹ nghệ ngược chính là: làm lại tài liệu và phục hồi thiết kế. Lấy thông tin về chức năng và cấu trúc Lấy đặc tả ban đầu và thay đổi Xem lại yêu cầu Tạo ra tài liệu Lấy thông tin về luồng dữ liệu và luồng điều khiển Xem lại thiết kế Tạo ra tài liệu Thông tin chương trình Thông tin yêu cầu Thông tin yêu cầu chi tiết Thông tin yêu cầu được phục hồi Tài liệu mới Thông tin thiết kế Thông tin thiết kế mức cao Tài liệu mới Thông tin thiết kế được phục hồi 19 1.3.2.1 Làm lại tài liệu Vì các chương trình để tái kỹ nghệ thường không còn tài liệu, thiết kế v.v…, vì vậy việc làm lại tài liệu là một nhiệm vụ cần thiết trong quá trình tái kỹ nghệ. Chikofsky đã định nghĩa quá trình làm lại tài liệu là tạo ra hoặc sửa đổi lại tài liệu hiện thời (nếu có) sang một cách miêu tả có ngữ nghĩa tương đương với mức trừu tượng tương đối. Và kết quả của việc làm này là ta thu được một cái nhìn đan xen nhau về hệ thống (ví dụ như luồng điều khiển, cấu trúc điều khiển, luồng dữ liệu). Làm lại tài liệu là một hình thức đơn giản nhất và là giai đoạn khởi đầu của kỹ nghệ ngược. Và nhiều người cho rằng việc làm lại tài liệu không gây ra thay đổi trong hệ thống. Làm lại tài liệu mã nguồn là sự biến đổi từ mã nguồn (cộng với những hiểu biết về chương trình và các tài liệu khác) sang một tài liệu mã nguồn mới hoặc nâng cấp tài liệu mã nguồn. Thông thường, những tài liệu này sẽ ở dạng văn bản (ví dụ như là những ghi chú trong chương trình), nhưng nó cũng có thể là những tài liệu bằng đồ họa. Việc cải tiến phần mềm bằng cách nâng cấp tài liệu (những chú thích, thiết kế, đặc tả được nhúng trong chương trình) là một trong những kỹ thuật tái kỹ nghệ cũ. Làm lại tài liệu là một hoạt động quan trọng bởi việc bảo trì thường phải dựa vào những chú thích được viết trong chương trình và coi đó là cơ sở để có thể hiểu được những đoạn mã trong chương trình hoạt động như thế nào. Với việc làm lại tài liệu, những kĩ sư bảo trì sẽ có cái nhìn toàn diện và đầy đủ hơn về hệ thống và hoạt động của nó. Ngày nay, việc làm lại tài liệu không phải chỉ thủ công mà đã có rất nhiều công cụ, hỗ trợ cho con người rất nhiều trong việc xây dựng lại tài liệu. Một số công cụ phổ biến như là “máy in chât lượng” là một chương trình có thể hiển thị một danh sách các mã trong dạng cải tiến, hay như máy tạo biểu đồ có thể tạo ra các biểu đồ trực tiếp từ mã, phản ánh các luồng mã và cấu trúc mã, hoặc là máy phát danh sách tham chiếu chéo. Một mục tiêu chính của những công cụ này là giúp cho con người có thể dễ dàng hình dung được mối quan hệ giữa các thành phần của chương trình, từ đó có thể thấy phương hướng rõ ràng để thực hiện công việc. 1.3.2.2 Phục hồi thiết kế Sau bước làm lại tài liệu, việc phục hồi lại thiết kế của chương trình là một việc làm cần thiết. Phục hồi thiết kế là một tập hợp các kỹ thuật đảo ngược trong đó chúng ta phải xây dựng lại thiết kế cho chương trình dựa trên việc trực tiếp kiểm tra hệ thống đó. Ngoài ra, chúng ta phải thu thập thêm các thông tin, kiến thức bên ngoài của hệ thống, các nguyên nhân trích xuất không rõ ràng của hệ thống, từ đó giúp cho hệ thống có khả năng quan sát tổng quát hơn, với mức độ trừu tượng cao hơn. 20 Việc bảo trì phần mềm và thu hoạch những thành phần tái sử dụng lại từ phần mềm đó, cả hai đều cần đến phân tích việc tái cấu trúc lại thiết kế của hệ thống. Nhưng thật không may, mã nguồn của chương trình thường không chứa nhiều các thông tin về thiết kế trong giai đoạn đầu. Qua mã nguồn, ta chỉ có thể cấu trúc lại các thông tin cơ bản nhất. Do vậy, các nguồn thông tin bổ sung, do cả con người hay tự động đều cần thiết. Hơn thế nữa, vì qui mô của một phần mềm để tái kỹ nghệ thường rất lớn (có đến hàng trăm dòng mã hoặc nhiều hơn nữa) cho nên việc phân tích cũng rất cần những hỗ trợ tự động để có thể hiểu được qui trình. Phục hồi lại thiết kế là tạo lại thiết kế ở mức độ trừu tượng từ việc kết hợp mã chương trình, các tài liệu thiết kế của chương trình hiện tại (nếu có), kinh nghiệm của con người và các hiểu biết chung về hệ thống chương trình. Các thiết kế trừu tượng được phục hồi phải bao gồm các thành phần cơ bản của kỹ nghệ phần mềm như là đặc tả hình thức, phân tích module, trừu tượng hóa dữ liệu, luồng dữ liệu và ngôn ngữ đặc tả chương trình. Ngoài ra chúng ta phải bổ sung thêm những thông tin như miền vấn đề ngôn ngữ, cách biểu diễn ứng dụng trong môi trường của chương trình. Tóm lại, phục hồi thiết kế phải sao chép lại toàn bộ các thông tin cần thiết để một người có thể hiểu đầy đủ về chương trình như chương trình làm cái gì, làm như thế nào, tại sao nó lại hoạt động như thế v.v… Vì vậy, việc tập trung vào phục hồi các thông tin xa rộng trong thiết kế cần thiết hơn là tìm ra những đại diện hoặc mã của việc kỹ nghệ phần mềm thông thường. Phục hồi thiết kế diễn ra trong một chuỗi các hoạt động từ phát triển phần mềm đến bảo trì. Các nhà phát triển phần mềm mới dành rất nhiều thời gian để cố gắng hiểu cấu trúc của hệ thống và các thành phần của hệ thống. Việc bảo trì phần mềm dành nhiều thời gian nghiên cứu cấu trúc của một hệ thống để hiểu được bản chất và hiệu quả khi thay đổi yêu cầu. Trong mỗi trường hợp, nhà phân tích đều đang tham gia phục hồi thiết kế. Vì vậy, phục hồi thiết kế là một phần chung, đôi khi là một phần ẩn của các hoạt động rải rác trong suốt chu trình sống phần mềm. 1.3.3 Cấu trúc lại hệ thống Cấu trúc lại hệ thống là một giai đoạn quan trọng và rất cần thiết trong qui trình tái kỹ nghệ. Cấu trúc lại hệ thống không chỉ đơn thuần là xây dựng lại cấu trúc cho hệ thống cũ, mà chúng ta phải thực hiện cải tiến lại hệ thống cũ, tạo ra một hệ thống mới phù hợp với môi trường hiện tại, cung cấp đầy đủ các tính năng mà hiện tại hệ thống được đòi hỏi. Do nhu cầu ngày nay, các hệ thống cần sử dụng bộ nhớ lớn, do đó phải 21 có sự tối ưu hóa việc sử dụng bộ nhớ chương trình. Cộng với việc có nhiều người lập trình thiếu hiểu biết về kỹ nghệ phần mềm dẫn đến hệ thống có cấu trúc không tốt. Cấu trúc điều khiển chương trình có thể sẽ khó hiểu do chương trình có nhiều nhánh rẽ không sử dụng các câu lệnh điều kiện và logic điều khiển chương trình không được tốt. Cũng có thể do chương trình thường xuyên phải bảo trì đã làm xuống cấp cấu trúc của hệ thống. Chúng ta có thể thay đổi để chương trình có thể thực hiện những đoạn mã mà bình thường chúng không hoạt động, tuy nhiên điều này chỉ được phát hiện khi sau khi đã có sự phân tích tổng thể. Các lập trình viên bảo trì thường không dám loại bỏ mã trong trường hợp nó có thể được truy cập gián tiếp. Hình 1-07 mô tả một điều khiển logic phức tạp trong việc xây dựng một chương trình đơn giản nhưng để hiểu được cấu trúc của nó thì lại rất phức tạp. Chương trình được viết bằng một ngôn ngữ tương tự như FORTRAN và nó thường dùng để viết các chương trình thuộc loại này. Tuy nhiên ở đây, chương trình không phải gây khó hiểu bởi những tên biến phức tạp. Trong ví dụ là một bộ điều khiển cho hệ thống làm nóng. Một bảng điều khiển được thiết lập để chuyển đổi giữa các trạng thái bật, tắt và kiểm soát. Nếu hệ thống được kiểm soát thì sau đó nó sẽ được bật và tắt tùy thuộc vào thiết lập của bộ đếm thời gian và bộ điều nhiệt. Nếu hệ thống làm nóng được bật, bộ chuyển đổi của lò sưởi sẽ chuyển thành tắt và ngược lại. Start: Get (Time-on, Time-off, Time, Setting, Temp, Switch) if Switch = off goto off if Switch = on goto on goto Cntrld off: if Heating-status = on goto Sw-off goto loop on: if Heating-status = off goto Sw-on goto loop Cntrld: if Time = Time-on goto on if Time = Time-off goto off if Time < Time-on goto Start if Time > Time-off goto Start if Temp > Setting then goto off if Temp < Setting then goto on Sw-off: Heating-status := off 22 goto Switch Sw-on: Heating-status := on Switch:Switch-heating loop: goto Start Hình 1-07 - Một chương trình điều khiển với logic phức tạp Thông thường, các chương trình có cấu trúc logic phức tạp như thế này là do quá trình phát triển hoặc cũng có thể do chúng được sửa đổi trong thời gian bảo trì. Người ta phải thêm vào các điều kiện và các mối liên kết giữa các hành động của chương trình mà không làm thay đổi cấu trúc điều khiển hiện thời. Trong một phạm vi hẹp thì đây là một giải pháp nhanh hơn và có ít rủi ro hơn vì nó giảm khả năng xuất hiện các lỗi trong hệ thống. Tuy nhiên, về lâu dài nó sẽ không còn phù hợp nữa vì người ta sẽ không thể hiểu được các mã chương trình. Khi người lập trình cố gắng tránh sao chép mã sẽ có khả năng phát sinh ra những cấu trúc mã phức tạp. Với những chương trình bị hạn chế bởi giới hạn bộ nhớ thì đôi khi việc tránh sao chép mã là cần thiết. Hình 1-08 là một đoạn mã của cùng hệ thống điều khiển trên nhưng đã được viết lại bằng cách sử dụng các câu lệnh điều khiển cấu trúc. Đoạn mã này sẽ được đọc tuần tự từ trên xuống dưới, vì vậy nó dễ hiểu hơn nhiều. Ba vị trí chuyển đổi là bật, tắt và điều khiển được xác định rõ ràng và được liên kết với các mã liên quan của chúng. loop -- Câu lệnh Get tìm giá trị cho các biến được đưa ra từ môi -- trường của hệ -- thống. Get (Time-on, Time-off, Time, Setting, Temp, Switch); case Switch of when On => if Heating-status = off then Switch-heating ; Heating-status := on ; end if ; when Off => if Heating-status = on then Switch-heating ; Heating-status := off ; end if; when Controlled => if Time >= Time-on and Time < = Time-off then if Temp > Setting and Heating-status = on then Switch-heating; Heating-status = off; 23 elsif Temp < Setting and Heating-status = off then Switch-heating; Heating-status := on ; end if; end if ; end case ; end loop ; Hình 1-08 – Một chương trình điều khiển có cấu trúc Cũng giống như điều khiển không có cấu trúc, những điều kiện phức tạp cũng có thể được đơn giản hóa như một phần trong qui trình tái cấu trúc một chương trình. Hình 1-09 thể hiện một câu lệnh điều kiện nếu bao gồm cả câu lệnh logic “not” thì có thể sẽ giúp chúng ta dễ hiểu cấu trúc của đoạn mã hơn. -- điều kiện phức tạp if not (A > B and (C F) ) )... -- điều kiện đơn giản if A = D or E > F)... Hình 1-09 – đơn giản hóa điều kiện Bohm và Jacopini (Bohm và Jacopini, 1966) đã chứng minh rằng, bất kỳ chương trình nào cũng có thể được viết lại thành các dạng đơn giản bằng cách sử dụng những câu lệnh điều kiện if – else , vòng lặp while, và những câu lệnh vô điều kiện như goto sẽ không cần thiết trong chương trình. Định lý này là cơ sở cho việc tái cấu trúc chương trình tự động. Hình 1-10 cho thấy các giai đoạn trong việc cấu trúc lại một chương trình bằng phương pháp tự động. Qua lần biến đổi đầu tiên, chương trình sẽ được chuyển đổi thành một đồ thị có hướng, tiếp theo đó nó sẽ được chuyển đổi thành một chương trình mới có cấu trúc tương đương với chương trình cũ nhưng không có câu lệnh goto nào được sinh ra. Các đồ thị có hướng được tạo ra là một đồ thị các luồng chương trình trong đó chỉ ra cách thức điều khiển di chuyển thông qua các chương trình. Đơn giản hoá và chuyển đổi kỹ thuật có thể được áp dụng cho đồ thị này mà không thay đổi ngữ nghĩa của nó. Phải phát hiện và loại bỏ các đoạn mã không cần thiết trong hoạt động của chương trình. Một khi hoàn thành việc đơn giản hóa cấu trúc chương trình, chúng ta đã tạo ra được một chương trình mới. Các vòng lặp while và các câu lệnh điều kiện đơn giản được thay thế cho việc điều khiển chương trình dựa trên các câu lệnh goto. 24 Chương trình mới có thể vẫn giữ ngôn ngữ gốc hoặc được chuyển sang một ngôn ngữ mới (như FORTRAN có thể được chuyển đổi sang C). Tái cấu trúc chương trình tự động sẽ gặp các vấn đề sau: − Mất ghi chú. Nếu chương trình có các dòng ghi chú trong đó, nó sẽ luôn bị mất đi trong quá trình tái cấu trúc. − Mất tài liệu. Tương tự, tài liệu của chương trình cũng sẽ bị mất đi. Tuy nhiên, trong nhiều trường hợp, sau quá trình tái cấu trúc, cả các ghi chú và tài liệu của chương trình đều trở nên lạc hậu. Bởi vậy đây không phải là một nhân tố quan trọng. − Nặng về nhu cầu tính toán. Các thuật toán nhúng trong các công cụ tái cấu trúc rất phức tạp. Thậm chí ngay cả với các phần cứng nhanh và hiện đại cũng phải mất một thời gian dài để hoàn thành qui trình tái cấu trúc cho các chương trình lớn. Hình 1-10: Cấu trúc chương trình tự động Nếu chương trình phụ thuộc vào dữ liệu trong đó các thành phần gắn kết chặt chẽ với nhau thông qua việc chia sẻ cấu trúc dữ liệu, việc cấu trúc lại mã không đưa đến cải tiến sự hiểu biết một cách đáng kể. Do vậy, việc module hóa chương trình có thể cần thiết. Nếu chương trình được viết bằng một hệ ngôn ngữ không chuẩn, các công cụ tái cấu trúc tiêu chuẩn có thể không hoạt động đúng đắn và sự can thiệp thủ công có ý nghĩa vô cùng cần thiết. Chương trình để cấu trúc lại Trình diễn biểu đồ Chương trình đã được cấu trúc lại Công cụ phân tích và xây dựng biểu đồ Công cụ sinh chương trình 25 Trong một số trường hợp, có thể không có chi phí hiệu quả để cấu trúc lại toàn bộ các chương trình trong một hệ thống. Một số có thể có chất lượng tốt hơn so với số khác trong khi đó một vài cái lại không thể tùy thuộc vào các thay đổi thường xuyên. Arthur (Arthur, 1988) cho thấy rằng một dữ liệu phải được thu thập để giúp xác định những chương trình nào có thể hưởng lợi nhiều nhất từ tái cấu trúc. Ví dụ, các thông số sau đây có thể được sử dụng để xác định các chương trình thích hợp cho việc tái cấu trúc: − Ước lượng thất bại − Tỉ lệ phần trăm mã nguồn thay đổi trên mỗi năm − Độ phức tạp của các thành phần Một số nhân tố khác như mức độ để chương trình hoặc các thành phần của chương trình có thể đạt đến tiêu chuẩn như hiện thời cũng có thể dựa vào đó để quyết định cho việc tái cấu trúc. 1.3.4 Module hóa chương trình Module hóa chương trình là quá trình tổ chức lại chương trình sao cho các phần chương trình có liên quan đến nhau được tập hợp lại với nhau trong cùng một module. Một khi việc module hóa chương trình đã được thực hiện, chúng ta có thể dễ dàng loại bỏ được các thành phần dư thừa và tối ưu hóa tương tác giữa các thành phần đồng thời làm giảm giao diện giữa một thành phần với các phần còn lại của hệ thống. Ví dụ, trong chương trình xử lý dữ liệu chấn địa, toàn bộ các toán tử liên kết với thành phần đồ họa thể hiện của dữ liệu có thể tập hợp lại với nhau trong cùng một module. Nếu hệ thống được phân phối, các module được tạo ra lại có thể gói gọn lại thành một đối tượng và có thể được truy cập qua một giao diện chung. Có một vài kiểu module khác nhau có thể được tạo ra trong quá trình module hóa là: − Dữ liệu trừu tượng: Những kiểu dữ liệu trừu tượng này được tạo ra bằng cách liên kết dữ liệu với các thành phần xử lý của nó. − Module phần cứng: Có sự liên quan chặt chẽ đến dữ liệu trừu tượng. Phải tập hợp tất cả các chức năng được sử dụng để điều khiển cùng một thiết bị phần cứng đặc biệt lại với nhau. − Module chức năng: Đây là module tập hợp các chức năng thực hiện tương tự nhau hoặc liên quan đến cùng một nhiệm vụ lại với nhau. Ví dụ, toàn bộ các 26 chức năng liên quan đến đầu vào và xác nhận đầu vào có thể kết hợp lại với nhau trong cùng một module. − Module hỗ trợ cho qui trình: Toàn bộ các chức năng và các thành phần dữ liệu cần thiết cho việc hỗ trợ các qui trình nghiệp vụ đặc biệt được nhóm lại với nhau trong cùng một module. Ví dụ, trong hệ thống thư viện, một module hỗ trợ qui trình là toàn bộ các chức năng cần thiết để hỗ trợ cho việc mượn và trả sách. Module hóa chương trình thường được thực hiện thủ công bằng cách kiểm tra và sửa đổi mã. Để module hóa một chương trình, chúng ta phải xác định mối quan hệ giữa các thành phần và đề ra xem các thành phần này làm những gì. Các công cụ trực quan và các công cụ duyệt có thể giúp chúng ta trong quá trình module hóa, nhưng chúng ta vẫn không thể hoàn toàn thực hiện tự động quá trình này. 1.3.5. Tái kỹ nghệ dữ liệu Cho tới bây giờ, hầu hết các cuộc thảo luận về quá trình phát triển phần mềm đều tập trung vào vấn đề các chương trình và hệ thống phần mềm luôn luôn biến đổi. Tuy nhiên, trong nhiều trường hợp, nó lại liên quan đến vấn đề phát triển dữ liệu. Lưu trữ, tổ chức và định dạng của dữ liệu được xử lý bởi chương trình cũ phải được tiến hóa để phù hợp với những thay đổi của phần mềm. Quá trình phân tích và tổ chức lại cấu trúc dữ liệu và đôi khi là cả giá trị của dữ liệu trong hệ thống làm cho nó trở nên dễ hiểu hơn được gọi là tái kỹ nghệ dữ liệu. Nói chung, tái kỹ nghệ dữ liệu không cần thiết nếu như các chức năng của hệ thống không thay đổi. Tuy nhiên, trong thực tế, có rất nhiều lý do để chúng ta phải sửa đổi dữ liệu khi chương trình của chúng ta là một hệ thống cũ được kế thừa lại: − Sự thoái hóa dữ liệu Qua thời gian, chất lượng của dữ liệu sẽ dần trở nên suy tàn. Thay đổi những dữ liệu có thông báo lỗi, các giá trị sao chép có thể được tạo ra và thay đổi ở môi trường bên ngoài có thể sẽ không được phản hồi trong dữ liệu. Đây là một điều không thể tránh khỏi bởi vì vòng đời của dữ liệu thường rất dài. Ví dụ, một dữ liệu ngân hàng cá nhân hình thành khi một tài khoản được mở và có thể kéo dài ít nhất là suốt đời khách hàng. Khi thông tin của khách hàng thay đổi, những thay đổi này có thể không đúng với dữ liệu của ngân hàng. Tái kỹ nghệ chương trình có thể mang vấn đề chất lượng dữ liệu ra ánh sáng và làm nổi bật sự cần thiết của việc tái kỹ nghệ dữ liệu. − Những giới hạn cố hữu được xây dựng trong chương trình Khi thiết kế ban đầu, những người phát triển chương trình đưa vào những ràng buộc gắn liền với số 27 lượng dữ liệu mà nó có thể xử lý. Tuy nhiên, các chương trình ngày nay cần phải xử lý nhiều dữ liệu hơn so với những dự kiến ban đầu của các nhà phát triển. Vì vậy, tái kỹ nghệ dữ liệu là cần thiết để loại bỏ các hạn chế này. Ví dụ, Rochester và Douglas (Rochester and Douglass, 1993) đã mô tả một hệ thống quản lý quỹ với thiết kế ban đầu chỉ có thể xử lý được 99 quỹ. Công ty đang chạy hệ thống này quản lý hơn 2000 quỹ, vì vậy họ phải chạy 23 hệ thống riêng biệt. Và để xử lý vấn đề này, họ đã quyết định tái kỹ nghệ hệ thống và các dữ liệu liên quan. − Tiến hóa kiến trúc Nếu một hệ thống tập trung được chuyển thành một kiến trúc phân tán, thì điều cần thiết cốt lõi của kiến trúc nên là một hệ thống quản lý dữ liệu mà các khách hàng ở xa có thể truy cập được. Điều này đòi hỏi phải có những nỗ lực lớn trong việc tái kỹ nghệ dữ liệu để di chuyển các dữ liệu từ các tệp riêng biệt vào trong hệ thống máy chủ quản lý cơ sở dữ liệu. Việc di chuyển đến một kiến trúc chương trình có thể bắt đầu khi tổ chức chương trình chuyển đổi từ quản lý dữ liệu dựa trên các tệp sang hệ thống quản lý cơ sở dữ liệu. Rickets và một số tác giả khác (Rickets, DelMonaco et al., 1993) đã mô tả lại rằng một hệ thống kế thừa được tạo thành từ nhiều chương trình phối hợp lại sẽ có một số vấn đề có thể phát sinh với cơ sở dữ liệu của hệ thống là: − Vấn đề đặt tên dữ liệu Một số tên dữ liệu có thể gây khó hiểu. Những cái tên khác (từ đồng nghĩa) có thể đưa ra cho cùng một thực thể logic trong những chương trình khác nhau trong một hệ thống. Cùng một cái tên có thể được sử dụng trong những chương trình khác nhau với những việc có ý nghĩa khác nhau. − Vấn đề độ dài trường Vấn đề này xảy ra khi độ dài của trường trong những bản ghi được chỉ định rõ ràng trong chương trình. Với cùng một mục có thể được gán những độ dài khác nhau trong những chương trình khác nhau hoặc độ dài của trường có thể quá ngắn để hiển thị dữ liệu hiện hành. Để giải quyết vấn đề này, các trường khác có thể được sử dụng lại trong một vài trường hợp vì thế để sử dụng một trường dữ liệu có cùng tên qua các chương trình là không phù hợp. − Vấn đề tổ chức bản ghi Các bản ghi thể hiện cùng một thực thể có thể được tổ chức khác nhau trong các chương trình khác nhau. Nó sẽ trở thành vấn đề trong các ngôn ngữ như là COBOL nơi mà các tổ chức vật lý của bản ghi được thiết lập bởi những người lập trình và được phản ánh trong các tập tin. Tuy nhiên, nó sẽ không phải là vấn đề trong các ngôn ngữ như C++ hay Java nơi mà các tổ chức vật lý của bản ghi là trách nhiệm của trình biên dịch. 28 − Các giá trị cố định mã hóa cứng Các giá trị (tuyệt đối) cố định, chẳng hạn như là mức số thuế, được đưa vào trực tiếp trong chương trình chứ không phải được tham chiếu sử dụng qua một số tên đặc trưng. − Không có từ điển dữ liệu Có thể không có từ điển dữ liệu định nghĩa những cái tên được sử dụng, những đại diện của nó và những cái sử dụng của nó. Hình 1-11: Chuyển đổi dữ liệu Tệp 1 Tệp 6 Tệp 5 Tệp 4 Tệp 3 Tệp 2 Chương trình 1 Chương trình 7 Chương trình 6 Chương trình 5 Chương trình 4 Chương trình 2 Chương trình 3 Hệ thống quản lý CSDL Chương trình 2 Chương trình 3 Chương trình 4 Chương trình 1 Chương trình 5 Chương trình 6 Chương trình 7 Mô hình dữ liệu vật lý và logic Mô tả Trở thành 29 Cũng như định nghĩa dữ liệu không phù hợp, các giá trị dữ liệu cũng có thể được lưu trữ một cách không phù hợp. Sau khi các định nghĩa dữ liệu được tái kỹ nghệ, giá trị của dữ liệu cũng phải được chuyển đổi để phù hợp với cấu trúc mới. Trước khi tái kỹ nghệ dữ liệu của chương trình, điểu cần thiết trước khi làm là phải phân tích chi tiết chương trình. Những phân tích này nên nhằm vào mục đích phát hiện những chức năng định danh trong chương trình, tìm ra các giá trị cố định để thay đổi thành tên hằng số, phát hiện những qui tắc kiểm chứng dữ liệu nhúng và chuyển đổi đại diện của dữ liệu. Các công cụ như là phân tích và mô hình tham chiếu chéo có thể được sử dụng để giúp cho quá trình phân tích được nhanh chóng và đơn giản hơn. Một tập hợp các bảng nên được tạo ra để chỉ ra các mục dữ liệu được tham chiếu và những thay đổi được tạo ra cho mỗi tham chiếu đó. Hình 1-12: Quá trình tái kỹ nghệ dữ liệu Hình 1-12 minh họa quá trình tái kỹ nghệ dữ liệu, giả định rằng những định nghĩa dữ liệu được sửa đổi, các giá trị cố định được đặt tên, định dạng dữ liệu được tổ chức lại và giá trị dữ liệu được chuyển đổi. Bảng tóm tắt các chi tiết trong thay đổi được tạo ra. Do đó chúng được sử dụng ở tất cả các giai đoạn của quá trình tái kỹ nghệ dữ liệu. Trong giai đoạn 1 của quá trình này, các định nghĩa dữ liệu trong chương trình được sửa đổi cho dễ hiểu hơn. Dữ liệu không bị ảnh hưởng bởi các sửa đổi. Có thể tự động quá trình này ở một mức độ nào đó bằng cách sử dụng hệ thống kết hợp mô hình Phân tích dữ liệu Chương trình được tái kỹ nghệ Bảng tổng hợp thay đổi Phân tích dữ liệu Chuyển đổi dữ liệu Dữ liệu sửa đổi - Sửa đổi tên thực thể - Thay thế các giá trị cố định. - Sắp xếp lại định nghĩa dữ liệu Định dạng lại dữ liệu Chuyển đổi giá trị mặc định Sửa đổi các qui tắc hợp lệ Giai đoạn 1 Giai đoạn 2 Giai đoạn 3 30 như là AWK (Aho, Kernighan và một số người khác, 1988) để tìm và thay thế các định nghĩa hoặc để phát triển các mô tả UML của dữ liệu (St Laurent and Cerami, 1999) và sử dụng các công cụ chuyển đổi dữ liệu. Tuy nhiên, một vài việc làm thủ công hầu như là cần thiết để hoàn tất quá trình. Quá trình tái kỹ nghệ dữ liệu có thể dừng lại ở giai đoạn này nếu mục đích chỉ đơn giản là làm tăng hiểu biết về các định nghĩa cấu trúc dữ liệu trong chương trình. Tuy nhiên, nếu có các vấn đề về giá trị dữ liệu như đã được trình bày ở trên thì giai đoạn 2 có thể thực hiện. Nếu tổ chức quyết định tiếp tục giai đoạn 2 của quá trình, sau đó là tập trung vào giai đoạn 3, chuyển đổi dữ liệu. Nó thường là một quá trình rất tốn kém. Chương trình phải được viết với đầy đủ những hiểu biết về tổ chức cũ và mới. Nó thực hiện chuyển đổi dữ liệu cũ và chuyển đổi thông tin đầu ra. Một lần nữa, hệ thống mẫu phù hợp có thể được sử dụng để tiến hành sự chuyển đổi này. 1.4 Các công cụ sử dụng cho tái kỹ nghệ Có khá nhiều các công cụ hỗ trợ cho việc tái kỹ nghệ. Trong mỗi giai đoạn của quy trình lại có một công cụ phục vụ cho các công việc khác nhau. Để dịch mã nguồn sang mô hình thiết kế chúng ta có các công cụ như Rational Software Architecture, Rational Rose v.v.. Bộ công cụ DMS Software Reengineering Toolkit là công cụ tự động phân tích chương trình, tùy chỉnh mã nguồn, sửa đổi, dịch hay phát sinh ra hệ thống phần mềm. Có rất nhiều các công cụ hỗ trợ như thế, nhưng trong phạm vi luận văn này sẽ tập trung vào việc tái kỹ nghệ phần mềm với sự hỗ trợ của công cụ Rational Rose và ngôn ngữ mô hình hóa thống nhất UML. 1.4.1 Ngôn ngữ UML Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language – UML) là một ngôn ngữ mô hình có phần chính bao gồm những ký pháp đồ họa, được các phương pháp hướng đối tượng sử dụng để thể hiện và miêu tả các thiết kế của một hệ thống. Nó là một ngôn ngữ để đặc tả, trực quan hoá, xây dựng và làm tài liệu cho nhiều khía cạnh khác nhau của một hệ thống phần mềm chuyên sâu. UML có thể được sử dụng làm công cụ giao tiếp giữa người dùng, nhà phân tích, nhà thiết kế và nhà phát triển phần mềm. Trong quá trình phát triển có nhiều công ty đã hỗ trợ và khuyến khích phát triển UML có thể kể tới như: Hewlett Packard, Microsoft, Oracle, IBM, Unisys. UML có thể được sử dụng trong nhiều giai đoạn, từ phát triển, thiết kế cho tới thực hiện và bảo trì. Vì mục đích chính của ngôn ngữ này là dùng các biểu đồ hướng 31 đối tượng để mô tả hệ thống nên miền ứng dụng của UML bao gồm nhiều loại hệ thống khác nhau như: − Hệ thống thống tin (Information System) − Hệ thống kỹ thuật (Technical System) − Hệ thống nhúng (Embeded System) − Hệ thống phân bố ( Distributed System) − Hệ thống Giao dịch (Business System) − Phần mềm hệ thống (System Software) Có thể nói UML không phải là một phương pháp mà là một ngôn ngữ mô hình hóa đối tượng đã được công nhận là một phương pháp đối tượng và được sử dụng chung trong cộng đồng công nghệ thông tin. Nó đã trở thành một chuẩn và được sử dụng phổ biến trong qui trình kỹ nghệ phần mềm. Một số các ký pháp sử dụng trong UML − Các thực thể cấu trúc − Các thực thể hành vi − Các ký pháp quan hệ 32 Các biểu đồ trong UML là: − Biểu đồ ca sử dụng − Biểu đồ đối tượng − Biểu đồ lớp − Biểu đồ tuần tự − Biểu đồ trạng thái − Biểu đồ tương tác − Biểu đồ hoạt động − Biểu đồ thành phần − Biểu đồ cài đặt Biểu đồ UML hỗ trợ rất lớn không chỉ trong việc dịch xuôi mà còn trong việc dịch ngược trong qui trình phát triển phần mềm. Dịch xuôi là khả năng phát sinh mã nguồn từ các mô hình thiết kế. Dịch ngược là khả năng tự động hoá việc xây dựng lại các mô hình thiết kế từ các thông tin trong mã nguồn. UML được thiết kế để hỗ trợ việc ánh xạ tất cả các mô hình thiết kế vào các ngôn ngữ triển khai và ngược lại ánh xạ từ mã nguồn về mô hình. Đối với dịch xuôi, mã được phát sinh cho mỗi phần tử mô hình phụ thuộc vào đặc tả các phần tử của mô hình và các thuộc tính của nó. Cũng như vậy, khi dịch ngược, các thông tin trong mã nguồn sẽ quyết định các mô hình được phát sinh. Tuy nhiên kết quả của việc dịch xuôi và dịch ngược còn phụ thuộc vào công cụ biểu diễn thiết kế việc dịch được hỗ trợ tới đâu, và cũng phụ thuộc vào ngôn ngữ lập trình triển khai được chọn để ánh xạ tới nó. UML là ngôn ngữ phong phú hơn bất cứ một ngôn ngữ lập trình hướng đối tượng nào hiện nay. Vì vậy, một số phần tử có trong mô hình sẽ không có phần tử tương ứng với nó trong một ngôn ngữ lập trình cụ thể, các phần tử đó sẽ bị bỏ qua trong cả hai 33 quá trình dịch. Như vậy khi dịch xuôi hay ngược sẽ xẩy ra sự mất thông tin, để có được hệ thống hoàn chỉnh thì cần phải bổ sung thêm các thông tin bị mất mát vào kết quả thu được sau khi dịch. Việc dịch xuôi và ngược được thực hiện dựa trên các nguyên tắc ánh xạ một-một giữa các phần tử trong mô hình thiết kế và các phần tử trong mã nguồn. Kết quả của quá trình dịch xuôi có thể cho mã nguồn thực hiện được hoặc các tệp nhị phân lưu giữ thông tin về mô hình. Kết quả của việc dịch ngược sẽ cho các mô hình thiết kế ban đầu. Ta có thể mô tả quá trình của kĩ thuật đảo ngược trong UML như sau: Hình 1-13: Dịch xuôi và dịch ngược trong UML 1.4.2 Hệ thống phần mềm RATIONAl ROSE Rational Rose là phần mềm công cụ hỗ trợ mạnh cho phân tích, thiết kế hệ thống phần mềm theo hướng đối tượng. Nó giúp mô hình hoá hệ thống trước khi viết mã trình, đảm bảo tính đúng đắn, hợp lý của kiến trúc hệ thống từ khi khởi đầu dự án. Mô hình Rational Rose là bức tranh hệ thống, nó bao gồm toàn bộ các biểu đồ của UML, tác nhân, ca sử dụng, đối tượng, lớp, thành phần và các nút triển khai trong hệ thống. Nó mô tả chi tiết hệ thống bao gồm những gì và chúng làm việc ra sao, để người phát triển hệ thống có thể sử dụng mô hình lập kế hoạch chi tiết cho việc xây dựng hệ thống. Rational Rose hỗ trợ giải quyết nhiều vấn đề quan trọng trong quá trình xây dựng và phát triển hệ thống, chẳng hạn việc đội ngũ dự án giao tiếp với khách hàng hay làm các tài liệu yêu cầu. Rational Rose Enterprise Edition cho phép phát sinh mã trình từ mô hình của UML sang một ngôn ngữ và dịch ngược từ một ngôn ngữ sang mô hình UML. Rose Eterprise cho phép phát sinh mã trình sang các ngôn ngữ Ada83, Ada95, ANSI C++, CORBA, Java, COM, Visual Basic, Visual C++, C++, Oracle, DB2, SQL Server, XML... và dịch ngược từ mã nguồn của các hệ trên sang mô hình của UML. Hơn nữa Rational Rose Enterprise Edition 7.0.0.0 cho phép mô hình hoá các ứng dụng trên website và tái thiết kế các ứng dụng trên nó. Mô hình UML Mã nguồn của một ngôn ngữ Dịch xuôi Dịch ngược 34 Rational Rose Enterprise Edition hỗ trợ tiến trình thiết kế kĩ nghệ đảo ngược cả với một số ngôn ngữ lập trình trên mang như ASP, JSP và các trang HTML. Nó gán các stereotype thích hợp cho các lớp và tạo các mối quan hệ giữa chúng. Ngoài ra, nó còn cho phép phát sinh và thiết kế kĩ nghệ đảo ngược trên các hệ thống cơ sở dữ liệu như: IBM DB2, Microsoft SQL Sever, Oracle và Sysbase Adaptive Sever 12.x. Là một công cụ rất mạnh sử dụng cho UML, Rational Rose Enterprise Edition được sử dụng để tạo ra các biểu đồ trong UML: − Biểu đồ ca sử dụng – use case diagram − Biểu đồ đối tượng – object diagram − Biểu đồ lớp – class diagram − Biểu đồ tuần tự - sequence diagram − Biểu đồ trạng thái – state diagram − Biểu đồ tương tác – collaboration diagram − Biểu đồ hoạt động – activity diagram − Biểu đồ thành phần – component diagram − Biểu đồ cài đặt – deployment diagram Hình 1-14: Biểu đồ ca sử dụng một hệ thống bán hàng qua catalog 35 Hình 1-15: Biểu đồ lớp Hình 1-16: Biểu đồ tuần tự 36 Hình 1-17: Biểu đồ trạng thái của hệ thống bán vé Hình 1-18: Biểu đồ tương tác của một hệ thống trả lương nhân viên 37 Hình 1-19: Biểu đồ hoạt động của hệ thống đặt hàng ở nhà hàng Hình 1-20: Biểu đồ thành phần 38 Hình 1-21: Biểu đồ cài đặt của một hệ thống Không chỉ dừng lại với việc tạo ra các biểu đồ UML, Rational Rose Enterprise Edition còn giúp ta sinh ra mã chương trình từ các biểu đồ đó. Chính nhờ điều này mà qui trình phát triển có thể trở nên tự động hơn, giúp giảm bớt rất nhiều phần việc trong quá trình xây dựng phần mềm. Để có thể sinh ra mã trình từ biểu đồ trong Rational Rose Enterprise Edition ta có thể thực hiện theo các bước cơ bản sau:  Kiểm tra mô hình: Chọn menu Tools -> Check Model, khi đó lỗi mô hình sẽ được hiển thị trong cửa sổ log Hình 1-22  Tạo lập thành phần: Mở Component diagram sau đó sử dụng biểu tượng Component trong thanh công cụ để bổ sung thành phần mới vào biểu đồ  Thực hiện ánh xạ lớp vào thành phần:  Nhấn phím phải trên thành phần trong biểu đồ thành phần hay Browser. 39  Chọn Open Specification.  Chọn tab Realizes  Click chuột phải trên lớp (những lớp) thích ứng và chọn Assign Hình 1-23  Browser sẽ chỉ ra tên thành phần trong dấu > sau tên lớp trong Logical View.  Đặt thuộc tính phát sinh mã trình: Có nhiều thuộc tính cho phát sinh mã nguồn có thể gán cho lớp, thuộc tính và các thành phần khác nhau của mô hình. Các thuộc tính này điều khiển mã trình sẽ được phát sinh như thế nào. Rose cung cấp bộ thuộc tính mặc định. Thí dụ, một đặc tính cho phát sinh mã trình của thuộc tính C++ là GenerateOperation, nó điều khiển các Get( ) sẽ được phát sinh cho thuộc tính này hay không. Để quan sát đặc tính phát sinh mã trình, chọn Tools-> Options, sau đó chọn bảng ngôn ngữ thích ứng. Từ cửa sổ type ta có thể chọn 40 thành phần mô hình như Class, Attribute, Operation…Mỗi ngôn ngữ có thành phần mô hình khác nhau. Hình 1-24  Chọn lớp, thành phần hay gói: Khi phát sinh mã trình ta có thể phát sinh cho lớp, thành phần hay gói vào cùng thời điểm. Mã trình có thể phát sinh từ biểu đồ hay browser. Nếu phát sinh mã từ gói, thì có thể chọn gói Logical view trên biểu đồ lớp hay chọn gói Component view trên biểu đồ thành phần. Cũng có thể phát sinh mã trình đồng thời cho nhiều lớp, thành phần hay gói.  Phát sinh mã trình: Sau khi chọn lớp hay thành phần trên biểu đồ, vào menu Tools sẽ hiển thị ra các ngôn ngữ mà Rational hỗ trợ, chọn ngôn ngữ thích ứng trong thực đơn phát sinh mã trình. Nếu có lỗi xảy ra trong quá trình phát sinh mã trình, chúng được hiển thị trên cửa sổ log. Không phải phát sinh mã trình đối với bất cứ ngôn ngữ nào cũng cần phải thực hiện đầy đủ theo các bước trên. Ví dụ đối với ngôn ngữ C++ ta có thể bỏ qua bước thứ hai, hoặc bước 1 ta không nhất thiết phải thực hiện đối với mọi ngôn ngữ. Tuy nhiên, để có một chương trình chính xác và đầy đủ, ta nên thực hiện đầy đủ theo các bước ở trên. 41 Hình 1-25: Sinh mã nguồn từ mô hình UML của Rational Rose Không chỉ dừng lại ở việc dịch mã nguồn từ biểu đồ, Rational Rose còn hỗ trợ trong việc dịch ra biểu đồ từ mã nguồn của hệ thống. Như vậy, với một chương trình mà ta chỉ có mã nguồn, với sự hỗ trợ của Rational Rose ta sẽ xây dựng lại được các biểu đồ của hệ thống đó. Đây chính là một tính năng quan trọng của Rational Rose phục vụ cho việc tái kỹ nghệ hệ thống. 1.4.3 Tái kỹ nghệ hệ thống với kỹ nghệ đảo ngược của Rational Rose Thiết kế bằng kỹ nghệ đảo ngược là thiết kế lấy thông tin từ mã nguồn của chương trình, rồi tạo hoặc cập nhật lại thành một mô hình trên Rational Rose. Thông qua khả năng tích hợp của Rational Rose với một số ngôn ngữ lập trình khác như: 42 C++/Visual C, Java, Visual Basic, Ada, CORBA, XML ..., Rational Rose hỗ trợ cơ chế thiết kế kỹ nghệ đảo ngược thành một mô hình UML. Một trong những thách thức của các đề án Công nghệ thông tin là giữ cho mô hình đối tượng nhất quán với mã trình. Khi thay đổi các yêu cầu, thường thì ta có khuynh hướng thay đổi mã trực tiếp, thay vì thay đổi mô hình rồi phát sinh mã. Trong Rose, ta có thể tái thiết kế hệ thống phần mềm với kĩ thuật đảo ngược đảm bảo cho mô hình đồng bộ với mã trình. Trong tiến trình thiết kế bằng kĩ thuật đảo ngược, Rose sẽ thu thập các thông tin về: các lớp, các thuộc tính , các tác vụ, các mối quan hệ, các các gói, các thành phần... trong chương trình nguồn. Nó sẽ sử dụng các thông tin này để tạo mới hoặc cập nhật một mô hình đối tượng. Nếu ta có một tệp tin mã nguồn chứa một lớp, tiến trình thiết kế kĩ thuật đảo ngược sẽ tạo ra một lớp tương ứng trong mô hình Rose, mỗi thuộc tính và tác vụ của lớp sẽ xuất hiện dưới dạng các thuộc tính và các tác vụ của lớp mới trong mô hình Rose. Cùng với tên thuộc tính và tên tác vụ, Rose đưa thêm vào các thông tin về tầm hoạt động, kiểu dữ liệu và các giá trị ngầm định. Nếu ban đầu ta dùng Rose để tạo ra các lớp, dùng kĩ thuật dịch xuôi để phát sinh mã trình, sau đó thực hiện một số thay đổi với các lớp trong mã trình, các thay đổi này sẽ được phản ánh trong tiến trình thiết kế với kĩ thuật đảo ngược. Chẳng hạn, nếu xoá hay bổ sung một tác vụ trong mã trình, tác vụ này sẽ bị xoá hay bổ sung vào mô hình nhận được bằng kĩ thuật đảo ngược. Ngoài các lớp, Rose sẽ thu thập thông tin về các mối quan hệ trong mã trình. Nếu một lớp chứa một thuộc tính có kiểu dữ liệu là một lớp khác, Rose sẽ tạo mối quan hệ giữa hai lớp. Với các mối quan hệ kế thừa Rose sẽ tạo các mối quan hệ tổng quát hoá để hỗ trợ mọi quan hệ trong mã trình. Có thể mô tả các quá trình phân tích thiết kế và tái thiết kế như trong các sơ đồ sau đây: Trong hình 1-26a mô tả một bước lặp trong tiến trình tái thiết kế xuất phát là mã nguồn của một ngôn ngữ lập trình được UML hỗ trợ. Trong hình 1-26b mô tả một bước lặp trong tiến trình tái thiết kế xuất phát là mô hình thiết kế của UML đã được thiết lập trước đây. Hình 1-26a mô tả một bước lặp trong tiến trình tái thiết kế. Ban đầu từ chương trình nguồn của hệ thống được lập trước đây, nhờ kĩ nghệ thiết kế đảo ngược của Retional Rose ta chuyển nó sang mô hình thiết kế trên UML. Tiếp đến là cập nhật, sửa đổi, hiệu chỉnh, bổ sung cho bản thiết kế này trên Rose. Sau đó lại sử dụng kĩ nghệt 43 dịch xuôi của Rational Rose để chuyển bản thiết kế này sang mã nguồn. Quá trình lặp trên có thể được thực hiện nhiều lần nếu cần thiết, và sau một bước lặp đó ta sẽ được một thế hệ phần mềm mới có thêm các chức năng và những đặc tính mới. Trong quá trình tái thiết kế hệ thống phần mềm chúng ta có thể kết hợp hai sơ đồ trên với nhau. Hình 1-26a: Một bước lặp của quá trình tái thiết kế với xuất phát là mã nguồn Hình 1-26b: Một bước lặp của quá trình tái thiết kế xuất phát là mô hình thiết kế Quá trình tái thiết kế phần mềm với Rational Rose không những cho ta một hệ thống phần mềm mới hơn hẳn hệ thống ban đầu về tính năng, mà còn cho phép sinh ra hệ thống trong một ngôn ngữ lập trình khác ngôn ngữ ban đầu. Nhờ vậy làm tăng tính khả chuyển (có khả năng hoạt động trên môi trương mới) của hệ thống mới nhận được. Trong điều kiện mà Công nghệ thông tin thay đổi rất nhanh, nhu cầu tái thiết kế các hệ thông phần mềm là rất lớn, và tính khả chuyển trên đây có ý một nghĩa cực kỳ quan trọng trong triển khai thực tế. Sau đây là một ví dụ sử dụng Rational Rose cho một chương trình được viết bằng Java. Chúng ta thực hiện dịch ngược từ mã nguồn của chương trình để thu được mô hình thiết kế của nó. Để làm được điều này chúng ta có thể thực hiện theo các bước sau: − Vào menu Tools / Java/J2EE / Reverse Engineer một hộp thoại được mở ra. − Trong hộp thoại, chọn đường dẫn đến thư mục chứa mã nguồn Java, sau đó add các tệp tin cần kỹ nghệ ngược. Có thể chọn Add all nếu như muốn chọn toàn bộ các tệp tin có trong thư mục. Mã nguồn (Trong ngôn ngữ A) Mã nguồn (Trong ngôn ngữ A) Mô hình thiết kế Dịch ngược Dịch xuôi Mô hình thiết kế Mô hình thiết kế Dịch xuôi Dịch ngược Mã nguồn 44 − Chọn Select All để lựa chọn toàn bộ các tệp tin hoặc có thể lựa chọn một số tệp tin sau đó chọn Reverse, quá trình dịch ngược sẽ bắt đầu được thực hiện Hình 1-27  Sau khi quá trình dịch ngược thực hiện xong, Rational Rose không tự động tạo các biểu đồ lớp và biểu đồ thành phần của chương trình. Vì vậy, để thêm các biểu đồ này vào ta có thể:  Kéo và thả chúng vào trong các biểu đồ có sẵn hoặc vào một biểu đồ mới được tạo ra  Chọn Use Query > Add Classes để thêm biểu đồ vào. Và với các cách thức thực hiện như trên, ta có thể thu được mô hình thiết kế của chương trình từ mã nguồn của nó. Với mô hình thiết kế thu được, ta có thể tiến hành dịch xuôi chương trình một cách dễ dàng cùng với sự hỗ trợ của công cụ Rational Rose. 45 1.5 Những ưu điểm và hạn hế của tái kỹ nghệ 1.5.1 Các ưu điểm Tái kỹ nghệ hệ thống phần mềm có hai ưu điểm chính so với các phương pháp tiếp cận khác trong việc cải tiến hệ thống: 1 Giảm rủi ro. Một điều cơ bản trong các tổ chức là việc tái phát triển phần mềm có nguy cơ rủi ro rất cao. Nếu chúng ta xây dựng lại một hệ thống mới, chúng ta phải bắt đầu với các bước đặc tả hệ thống, xây dựng mô hình thiết kế, phát triển hệ thống v.v... Và chính trong những giai đoạn phát triển thống, lỗi có thể phát sinh. Trong khi đó, với việc tái kỹ nghệ, chúng ta có thể bỏ qua một số quá trình thực hiện, do đó lỗi cũng có thể được giảm thiểu đáng kể. 2 Giảm giá thành. Chi phí của tái kỹ nghệ ít hơn đáng kể so với chi phí của việc phát triển một phần mềm mới. Ulrich (Ulrich 1990) đã trích dẫn ví dụ về một hệ thống thương mại có chi phí thực hiện lại ước tính khoảng 50 triệu đôla. Hệ thống được tái kỹ nghệ thành công chỉ với 12 triệu đôla. Nếu chúng ta lấy những con số này làm điển hình để so sánh thì việc tái kỹ nghệ sẽ rẻ hơn 4 lần so với việc viết lại chương trình. 1.5.2 Các hạn chế Mặc dù không thể phủ nhận những ưu điểm nổi trội của tái kỹ nghệ so với các phương pháp tiếp cận khác trong việc tiến hóa phần mềm, nhưng không phải là nó không có những nhược điểm. Nhược điểm chính của tái kỹ nghệ hệ thống là bị giới hạn trong một phạm vi nhất định của hệ thống cũ mà nó có thể cải tiến bằng tái kỹ nghệ. Ví dụ chuyển đổi một hệ thống văn bản sử dụng cách tiếp cận chức năng tới một hệ thống hướng đối tượng. Không thể thực hiện tự động việc thay đổi kiến trúc chính hay tổ chức lại căn bản việc quản lý dữ liệu hệ thống, do đó giá thành cho việc tái kỹ nghệ sẽ bị tăng lên. Mặc dù tái kỹ nghệ hệ thống có thể cải tiến việc bảo trì, nhưng nó không thể duy trì hệ thống đó giống như một hệ thống được phát triển mới và được sử dụng các phương pháp kỹ nghệ phần mềm hiện đại. Bên cạnh đó, tái kỹ nghệ cũng không thể tránh khỏi những rủi ro chung đối với quá trình phát triển phần mềm. Đó là:  Rủi ro trong tiến trình:  Rủi ro trong kỹ thuật dịch ngược  Rủi ro trong kỹ thuật dịch xuôi 46  Rủi ro nhân công  Rủi ro trong công cụ  Rủi ro chiến lược 1.6 Kết luận Bảo trì phần mềm là một công việc quan trọng đảm bảo cho hệ thống tồn tại và phát triển lâu dài, đỡ tốn nhiều công sức, thời gian và kinh phí... Ta có thể dùng kĩ nghệ đảo ngược của UML để thiết kế lại mô hình hệ thống phần mềm từ các thông tin mã nguồn được viết bằng một ngôn ngữ được chỉ ra. Việc tái kĩ nghệ lấy thông tin thu được và tái cấu trúc lại chương trình cho phép hệ thống đạt chất lượng cao hơn, thời gian ngắn hơn và đặc biệt có được tính ổn định cao. Do UML là ngôn ngữ hỗ trợ mạnh cho phân tích và thiết kế hướng đối tượng, cho nên các hệ thống đó được xây dựng theo hướng đối tượng, thì việc tái thiết các hệ thống đó theo kĩ nghệ đảo ngược của UML sẽ được thực hiện một cách thuận lợi. Và công cụ thực hiện cho việc xây dựng các mô hình UML chính là Rational Rose. Với sự kết hợp của hai công cụ này, chúng ta sẽ có sự hỗ trợ lớn trong việc thực hiện tái kỹ nghệ. Tuy nhiên còn nhiều vấn đề cần được thử nghiệm, đánh giá để có thể đề xuất một quy trình tái tái kỹ nghệ tốt và những kinh nghiệm hữu ích khi tái kỹ nghệ. 47 Chương 2: Bài toán về chương trình “Sổ địa chỉ” 2.1 Giới thiệu chương trình sổ địa chỉ Sau đây là một bài toán đơn giản được sử dụng để thử nghiệm cho quá trình tái kỹ nghệ. Đây là một chương trình sổ địa chỉ “Sổ địa chỉ”. Chương trình “Sổ địa chỉ” là một chương trình được viết bằng ngôn ngữ Java. Đây là một chương trình giúp cho người dùng có thể lưu trữ các thông tin cá nhân của người thân, bạn bè, đồng nghiệp v.v… giúp họ có thể dễ dàng quản lý danh sách các địa chỉ cá nhân của mình. Với việc sử dụng chương trình, ta có thể lưu trữ các thông tin về tên, số điện thoại, email, địa chỉ v.v… Chương trình có các chức năng chính sau:  Thêm mới một địa chỉ  Sửa một địa chỉ đã có  Xóa một địa chỉ đã có  Lưu địa chỉ vừa được thêm mới hoặc vừa được chỉnh sửa Giao diện chính của chương trình như hình: Hình 2-01: Giao diện chương trình “Sổ địa chỉ” Khi click chọn button “New” chương trình sẽ cho phép điền thông tin vào các textbox. Sau khi thực hiện điền đầy đủ thông tin chúng ta lưu dữ liệu lại bằng cách chọn button “Save”. Và tất cả các thông tin này được lưu trữ trong cơ sở dữ liệu của chương trình. Vì vậy chúng ta có thể tùy chọn các chức năng sửa, xóa các thông tin 48 được đưa vào một cách dễ dàng bằng cách bấm chọn các button “Edit”, “Delete” để thực hiện các thao tác trên. Khung cửa sổ chính của chương trình AddressBook là lớp AddressFrame được mở rộng từ lớp JFrame. AddressFrame là một container cho các thành phần đồ họa khác và nó cũng hoạt động như là một bộ điều khiển bằng cách xử lý các sự kiện khác nhau được tạo ra bởi các thành phần con. Các thành phần con ở đây là các lớp con JPanel mà mỗi một lớp có một nhiệm vụ khác nhau: − AddressPanel đại diện cho một bản ghi địa chỉ. Nó cung cấp giao diện cho việc chỉnh sửa một bản ghi hiện thời và tạo một bản ghi mới. Lớp này chứa trường text cho tất cả các thông tin của đối tượng Address. − AddressActionPanel cung cấp các button cho tất cả các ca sử dụng mà ứng dụng hỗ trợ. Trong AddressActionPanel tạo ra các sự kiện mà AddressFrame phải xử lý. Ví dụ khi người dùng ấn nút Save, lớp này sẽ tạo ra một sự kiện. AddressFrame phải lắng nghe và xử lý tất cả các sự kiện quan trọng đến từ lớp này. − AddressListPanel là nơi hiển thị các địa chỉ được thêm vào từ lớp AddressFrame. Danh sách này có kiểu đối tượng ListEntry. Một ListEntry sẽ chứa định danh duy nhất của một bản ghi trong cơ sở dữ liệu. Từ định danh (ID) của bản ghi sẽ cho phép ứng dụng lấy toàn bộ nội dung của bản ghi vào trong AddressPanel. − AddressDao. Việc kết nối và tạo ra cơ sở dữ liệu của chương trình sẽ được xử lý trong lớp AddressDao. Vì vậy, mọi quá trình tái kỹ nghệ dữ liệu sẽ được thực hiện sửa đổi thông qua lớp này. 1.2 Những vấn đề cần cải tiến chương trình Đây là một chương trình đơn giản với một số chức năng cơ bản, vì vậy thực hiện quá trình tái kỹ nghệ đối với chương trình để xây dựng thêm một số tính năng mới, giúp chương trình hoàn thiện hơn. Và những vấn đề cần phải tái ký nghệ được đặt ra đối với chương trình “Sổ địa chỉ” là: − Sửa lại cấu trúc chương trình cho dễ hiểu hơn, bỏ đi các phần mã thừa và sai − Việt hóa lại giao diện của chương trình cho thân thiện với người sử dụng − Thêm chức năng tìm kiếm địa chỉ theo tên, họ, theo số điện thoại v.v… − Sắp xếp các địa chỉ theo tên, họ, theo địa chỉ v.v… 49 Với những vấn đề cần cải tiến một chương trình, chúng ta luôn có rất nhiều phương pháp để thực hiện. Vì vậy cần phải lựa chọn một hướng tiếp cận sao cho phù hợp nhất mà đem lại chi phí hiệu quả nhất chính là vấn đề đặt ra đối với nhà phát triển phần mềm. Cụ thể đối với những yêu cầu trong bài toán này chúng ta có thể đưa ra một số giải pháp như sau: − Xây dựng mới chương trình: chúng ta sẽ thực hiện xây dựng mới lại hoàn toàn chương trình với các chức năng của chương trình ban đầu và các chức năng bổ sung. Nếu thực hiện phương pháp này, chúng ta phải thực hiện việc phân tích, thiết kế và xây dựng toàn bộ chương trình từ đầu mà không sử dụng đến tài nguyên có sẵn là mã nguồn của chương trình cũ. Như vậy việc phát triển này sẽ mất nhiều thời gian và công sức hơn. − Xây dựng thêm các chức năng bổ sung: với phương pháp này, chúng ta có thể giảm tải một phần công việc. Tuy nhiên, việc xây dựng thêm các chức năng không có sự phân tích, tìm hiểu về chương trình ban đầu một cách chi tiết sẽ dễ dàng dẫn đến sai lầm. Chương trình sau khi xây dựng có thể sẽ trở nên phức tạp, chồng chéo nhau, khó hiểu và còn có thể làm hỏng cả hệ thống − Tái kỹ nghệ: Xem xét lại chương trình cũ với các bước thực hiện như đã nêu ở chương 1, qua đó cấu trúc và xây dựng lại chương trình theo các yêu cầu cải tiến như trên. Với các giải pháp đã đưa ra, chúng ta có thể thấy tái kỹ nghệ thể hiện rõ các ưu điểm vượt trội so với các cách tiếp cận khác. Đây là một giải pháp khả thi nhất bởi nó phù hợp với yêu cầu của bài toán, hơn nữa nó vừa ít tốn kém thời gian và công sức, vừa có hiệu quả cao hơn. Qui trình tái kỹ nghệ chương trình “Sổ địa chỉ” sẽ được trình bày chi tiết ở chương 3. 50 Chương 3: Tái kỹ nghệ chương trình sổ địa chỉ 3.1 Sơ đồ tiến trình thực hiện tái kỹ nghệ Tiến trình tái kỹ nghệ chương trình “Sổ địa chỉ” sẽ thực hiện theo sơ đồ sau: Hình 3-01: Sơ đồ tiến trình tái kỹ nghệ “Sổ địa chỉ” 3.2 Qui trình thực hiện tái kỹ nghệ chương trình sổ địa chỉ Ta có thể thực hiện quá trình tái kỹ nghệ chương trình Sổ địa chỉ dựa trên các bước sau: − Giai đoạn 1: từ mã nguồn chương trình xây dựng các tài liệu và mô hình thiết kế cho chương trình. Trong giai đoạn này, chúng ta thực hiện xây dựng các tài liệu đặc tả yêu cầu chương trình, xây dựng mô hình UML cho chương trình từ mã nguồn của nó − Giai đoạn 2: Từ các tài liệu và mô hình thiết kế của chương trình thực hiện cấu trúc lại chương trình: Bỏ đi các cấu trúc thừa và sai, đồng thời thêm một số chức năng mới cho chương trình Mô hình hóa UML Cấu trúc chương trình Làm lại tài liệu Tài liệu chương trình Chương trình được cấu trúc Dữ liệu gốc Cấu trúc dữ liệu Dữ liệu được cấu trúc Xây dựng mã nguồn Mã nguồn hệ thống cũ Mã nguồn hệ thống mới 51 − Giai đoạn 3: Thực hiện tái kỹ nghệ lại dữ liệu − Giai đoạn 4: xây dựng mã nguồn cho chương trình mới: Từ cấu trúc của hệ thống mới thực hiện xây dựng mã nguồn cho chương trình mới − Giai đoạn 5: Hoàn thiện chương trình, cài đặt và sử dụng: Xây dựng hoàn thiện chương trình, thực hiện kiểm tra và đánh giá chương trình so với chương trình cũ. 3.2.1 Xây dựng tài liệu và mô hình thiết kế UML Trong giai đoạn này phải thực hiện việc kỹ nghệ ngược để tạo ra các tài liệu phân tích, thiết kế cho chương trình. Để tạo ra được các tài liệu phân tích, đặc tả hệ thống trước tiên phải có một cái nhìn tổng quan và đầy đủ về hệ thống. Tuy nhiên, với việc xuất phát từ mã nguồn của chương trình, đây không phải là một việc đơn giản. Để xây dựng được tài liệu đặc tả chương trình sử dụng cho quá trình thiết kế cần phải hiểu chương trình có những chức năng, tính năng gì, hoạt động như thế nào, vận hành ra sao. Để có được những thông tin này, trước hết cần dựa trên việc sử dụng chương trình cộng với việc nghiên cứu mã chương trình. Các ghi chú trong mã nguồn cũng là một phần quan trọng giúp cho hiểu hệ thống hơn. Thực hiện xong các bước này, ta có thể xây dựng được một tài liệu đặc tả chương trình hoàn thiện. Sau khi đã có tài liệu phân tích, đặc tả, ta tiếp tục phục hồi các mô hình thiết kế cho chương trình bằng cách sử dụng công cụ Rational Rose. Quá trình xây dựng các mô hình này có thể được thể hiện bằng sơ đồ như hình 3-02 Hình 3-02: Mô hình kỹ nghệ ngược sử dụng Rational Rose Như đã giới thiệu, Rational Rose là một công cụ hỗ trợ rất mạnh trong việc kỹ nghệ ngược. Quá trình kỹ nghệ ngược với Rational Rose sẽ tạo ra mô hình UML thông qua việc phân tích các thư viện hỗ trợ hiện thời và mã nguồn của chương trình. Để thu được mô hình UML của chương trình, ta thực hiện quá trình dịch Mã nguồn chương trình Thư viện hỗ trợ RATIONAL ROSE ENTERPRISE EDITION Mô hình 52 ngược theo các thao tác như đã giới thiệu ở chương 1. Sau khi thực hiện quá trình này, kết quả sẽ thu được một biểu đồ lớp của chương trình như hình 3-03 Hình 3-03: Biểu đồ lớp của chương trình “Sổ địa chỉ” Với việc đã có các tài liệu đặc tả cộng với sự hiểu biết sâu sắc về hệ thống, tiếp tục sử dụng công cụ Rational Rose để xây dựng hoàn thiện các biểu đồ UML cho chương trình. 53 Hình 3-04: Biểu đồ use case Từ biểu đồ use case, ta thực hiện xây dựng biểu đồ tuần tự cho các ca sử dụng của chương trình, cụ thể ở đây là biểu đồ tuần tự cho quá trình thêm một địa chỉ mới, xóa một địa chỉ và sửa một địa chỉ có sẵn. 54 Hình 3-05: Biểu đồ tuần tự cho việc thêm một địa chỉ mới Hình 3-06: Biểu đồ tuần tự cho quá trình xóa một địa chỉ 55 Hình 3-07: Biểu đồ tuần tự cho việc sửa một địa chỉ 3.2.2 Cấu trúc lại chương trình Dựa vào các biểu đồ UML, tài liệu đặc tả chương trình được tạo ra từ giai đoạn trên, đọc tài liệu mã nguồn cùng với việc sử dụng chương trình gốc, chúng ta đã có thể hiểu rõ hơn về hoạt động của chương trình, các chức năng, tình năng cũng như cách thức hoạt động của nó. Và dựa trên những hiểu biết về chương trình gốc này, kết hợp với những yêu cầu tiến hóa hệ thống đưa ra ở trên, chúng ta dễ dàng xây dựng lại cấu trúc mới cho chương trình. Chương trình mới sẽ có các chức năng:  Thêm một địa chỉ mới  Sửa một địa chỉ đã có  Xóa một địa chỉ đã có  Lưu địa chỉ vừa được tạo  Tìm kiếm địa chỉ theo tên, họ, theo số điện thoại v.v… 56  Sắp xếp các địa chỉ theo tên, họ, theo địa chỉ v.v…  Ngoài ra, chương trình mới sẽ có giao diện hoàn toàn bằng tiếng Việt, giúp cho việc sử dụng chương trình được dễ dàng và đơn giản hơn. Trước tiên, thực hiện việc cấu trúc lại mã nguồn của chương trình, bỏ đi các phần mã nguồn không thừa, không cần thiết nữa hoặc những phần mã nguồn sai. Sau đó, dựa trên mô hình thiết kế đã xây dựng ở trên thiết kế lại chương trình với các chức năng mới đã được thêm vào. Cụ thể ở đây sẽ đưa thêm các chức năng tìm kiếm, sắp xếp địa chỉ. Dựa trên các mô hình UML cũ, sử dụng Rational Rose để sửa chữa, tinh chỉnh và nâng cao chương trình với các chức năng mới được thêm vào, đồng thời phải đồng bộ chương trình để các chức năng mới không xung đột với hệ thống, chương trình mới có thể đảm bảo ổn định. 57 Các biểu đồ UML của chương trình mới Hình 3-08: Biểu đồ use case của chương trình mới 58 Hình 3-09: Biểu đồ tuần tự cho chức năng mới tìm kiếm 3.2.3 Tái kỹ nghệ dữ liệu Với chương trình xây dựng ban đầu, một thông tin địa chỉ được lưu trữ gồm có:  Last Name  First Name  Middle Name  Phone  Email  Address 1  Address 2  City  State  ZIP 59  Country Tất cả các thông tin trên được lưu trữ trong bảng cơ sở dữ liệu Address như sau: ID Last Name First Name Middle Name Phone Email Address 1 Address 2 City State Postal Code Country Primary key Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Hình 3-09: Bảng cơ sở dữ liệu địa chỉ của chương trình gốc Trong bảng cơ sở dữ liệu Address, ID chính là khóa chính của bảng và được lấy giá trị tăng dần bắt đầu bằng 1. Tuy nhiên, để sửa đổi lại chương trình cho phù hợp với người sử dụng, các thông tin được lưu trữ cho một cá nhân sẽ được sửa đổi, nó sẽ có các thành phần sau:  ID  Họ  Tên  Ngày sinh  Số điện thoại  Email  Địa chỉ  Quận/Huyện  Tỉnh/Thành phố  Cơ quan  Ghi chú  Phân loại Để lưu trữ các thông tin như đã nêu ở trên, trước tiên cần phải kỹ nghệ lại cơ sở dữ liệu của chương trình. Thực hiện sửa đổi lại dữ liệu ta sẽ có một bảng cơ sở dữ liệu mới như sau: 60 ID Ho Ten Ngaysinh Dienthoai Email Diachi Quanhuyen Tinhthanhpho Coquan Ghichu Phanloai Primarykey Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Hình 3-10: Bảng cơ sở dữ liệu của chương trình mới Sau khi đã xây dựng những sửa đổi, ta có thể thực hiện những thay đổi này thông qua lớp AddressDao trong giai đoạn xây dựng mã nguồn để thu được dữ liệu như mong muốn 3.2.4 Xây dựng mã nguồn Sau khi đã hoàn thiện quá trình cấu trúc lại hệ thống và kỹ nghệ dữ liệu, giai đoạn tiếp theo là thực hiện xây dựng mã nguồn. Sau giai đoạn cấu trúc lại chương trình đã thu được mô hình UML của chương trình mới với đầy đủ các chức năng được cải tiến. Kết hợp với mã nguồn gốc và chức năng sinh mã nguồn của Rational Rose từ mô hình UML, chúng ta sẽ xây dựng mã nguồn cho chương trình với đầy đủ các chức năng kể trên. Để thu được mã nguồn Java từ mô hình UML thông qua Rational Rose, vào Tools/ Java/J2EE / Generate Code, Rational Rose sẽ tự động sinh mã nguồn cho chương trình. Đối với cơ sở dữ liệu của chương trình, thực hiện xây dựng mã nguồn theo cấu trúc của dữ liệu được tạo mới. 3.2.5 Hoàn thiện, cài đặt và sử dụng Sau khi xây dựng mã nguồn, thực hiện cài đặt đầy đủ các nền tảng môi trường cần thiết để hỗ trợ chương trình hoạt động. Thực hiện đánh giá chương trình xem đã có đầy đủ chức năng đã yêu cầu không, đồng thời kiểm thử chương trình để tìm các lỗi trong quá trình hoạt động. Các lỗi ở đây có thể là các lỗi về chức năng, về giao diện chương trình, về hiệu suất thực hiện v.v… Sau khi chương trình đã được đánh giá đầy đủ có thể đưa vào sử dụng. 3.3 Kết quả đạt được và một số đánh giá Quá trình tái kỹ nghệ chương trình thử nghiệm đã đạt được những kết quả sau: 3.3.1. Liên quan đến chương trình - Chương trình được tái kỹ nghệ đáp ứng được các yêu cầu chức năng đặt ra:  Thêm mới các chức năng tìm kiếm và sắp xếp các địa chỉ được lưu trong chương trình 61  Các chức năng cũ vẫn được giữ nguyên và tiếp tục sử dụng - Về cấu trúc của chương trình:  Các lớp của chương trình cũ vẫn được giữ nguyên trong chương trình mới, các quan hệ giữa các lớp vẫn không thay đổi. Tuy nhiên cấu trúc các hàm, các thuộc tính trong các lớp được thay đổi để phù hợp với việc xây dựng thêm các chức năng mới cho chương trình, các quan hệ của các thành phần giữa các lớp cũng được thay đổi.  Một số hàm được cấu trúc lại mã nguồn cho dễ hiểu hơn, tiện cho việc bảo trì tiếp sau này tuy nhiên không làm thay đổi chức năng của hàm. - Trong file mã nguồn được thực hiện đưa thêm các ghi chú để người xem có thể hiểu hơn chương trình, dễ dàng cho việc sửa đổi, bảo trì, kỹ nghệ lại ở lần sau - Cấu trúc dữ liệu của chương trình cũng được thay đổi theo các thay đổi về thông tin của các địa chỉ được lưu trong chương trình. - Về giao diện của chương trình, các thông tin hiển thị, các nút điều khiển, tên chương trình đều được việt hóa, có thêm các chức năng mới được hiển thị. Hình 3-11: Giao diện chương trình mới 62 3.3.2. Liên quan đến triển khai Sau khi chương trình được xây dựng, việc thực hiện triển khai chương trình không có gì thay đổi. Chương trình được xây dựng trên ngôn ngữ Java nên yêu cầu môi trường chạy phải có cài đặt Java. Ngoài ra, vì chương trình được hiển thị giao diện hoàn toàn bằng tiếng Việt nên dễ dàng và tiện lợi hơn cho người sử dụng chương trình 3.3.3. Một số vấn đề tồn tại Vì thời gian để thực hiện khóa luận không có nhiều nên việc tái kỹ nghệ lại chương trình chưa được hoàn thiện, chưa thêm mới được đầy đủ các chức năng theo yêu cầu cho chương trình mới. Chương trình thử nghiệm tương đối đơn giản nên chúng ta có thể chưa nhận thấy hết tầm quan trọng của việc tái kỹ nghệ. Nhưng đối với một hệ thống lớn với số lượng dòng mã nguồn lên đến hàng nghìn, thậm chí là chục nghìn dòng thì việc tái kỹ nghệ sẽ cho chúng ta thấy ưu điểm rõ rệt của nó. Với việc tái kỹ nghệ, chúng ta có thể tiết kiệm được về cả thời gian và nhân lực, giúp giảm thiểu chi phí 63 Kết luận Khóa luận này đi sâu nghiên cứu thử nghiệm công nghệ tái ký nghệ phần mềm. Khóa luận đã thực hiện những kết quả sau: − Trình bày một tổng quan về một quy trình tái kỹ nghệ phần mềm và những công cụ trợ giúp được sử dụng gắn với quy trình này, đó là ngôn ngữ UML và bộ phần mềm công cụ Rational Rose. Tổng quan đã trình bày khá đầy đủ về toàn bộ công nghệ tái kỹ nghệ, cả những mặt mạnh và những mặt hạn chế của nó. − Vận dụng lý thuyết về công nghệ tái kỹ nghệ đã trình bày và nghiên cứu sử dụng các công cụ có được để tiến hành thử nghiệm tái kỹ nghệ một chương trình đã cho. Chương trình được tái kỹ nghệ hoàn toàn đáp ứng yêu cầu đặt ra. Mặc dù chương trình thử nghiệm là nhỏ, nhung qua đó cho thấy việc thực hiện quy trình tái kỹ nghệ với công cụ đã cho là không khó khăn và hoàn toàn thực thi, có thể áp dụng cho những chương trình lớn. − Qua khóa luận này đã giúp em nắm hiểu một lĩnh vực công nghệ rất cần thiết cho hoạt động bảo trì phần mềm và có thể vận dụng nó trong thực tế. 64 Tài liệu tham khảo Tiếng Việt [1] Nguyễn Văn Vỵ, Phân tích và thiết kế các hệ thống thông tin hiện đại hướng cấu trúc và hướng đối tượng, NXB Thống kê 2002 [2] PGS.TS Nguyễn Văn Vỵ, Phân tích và thiết kế hệ thống phần mềm theo hướng đối tượng, Bài giảng trường Đại học Công Nghệ [3] Đặng Văn Đức, Phân tích và thiết kế hướng đối tượng bằng UML, NXB Giáo dục 2002 [4] Trương Ninh Thuận, Phân tích thiết kế hướng đối tượng, Bài giảng trường Đại học Công Nghệ [5] TS. Dương Kiều Hoa – Tôn Thất Hoà, Phân tích và thiết kế HTTT theo UML Tiếng Anh [6] Francesco Bonfiglio, Reverse Engineering Legacy Code with Rational Rose, article. [7] Dr. Linda H. Rosenberg, Software Re-engineering, Engineering Section head Software Assurance Technology Center Unisys Federal Systems. [8] Ian Sommeville, Software Engineering, Sixth Edition, Addisom – Wesley, 2001. [9] E. J. Chikofsky and J. H. Cross, “Reverse Engineering and Design Recovery: A Taxonomy,” IEEE Software, vol. 7, pp. 13–17, January 1990. [10] Rational Rose Corp., Rational Rose 2002, [11] Using Rose Rational Rose® 2001, Rational the e-development company [12]