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

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. 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 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 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; 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. 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. Chương trình để cấu trúc lại Chương trình đã được cấu trúc lại Công cụ sinh chương trình Công cụ phân tích và xây dựng biểu đồ Trình diễn biểu đồ 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. 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 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ố 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. 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ó. Chương trình 1 Chương trình 3 Chương trình 2 Tệp 5 Tệp 4 Tệp 3 Tệp 2 Tệp 1 Tệp 6 Chương trình 6 Chương trình 5 Chương trình 4 Chương trình 7 Trở thành Chương trình 5 Chương trình 4 Chương trình 3 Chương trình 7 Chương trình 2 Hệ thống quản lý CSDL Mô tả Chương trình 1 Chương trình 6 Mô hình dữ liệu vật lý và logic Hình 1-11: Chuyển đổi dữ liệu 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 đó. Chương trình được tái kỹ nghệ Phân tích dữ liệu 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 Bảng tổng hợp thay đổi Dữ liệu sửa đổi Đị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 Phân tích dữ liệu Chuyển đổi dữ liệu Giai đoạn 3 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 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 đố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ệ 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 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ìn