Khóa luận Tái kỹ nghệ hệ thống phần mềm
ĐẠ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
1
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ỉ”.
2
Mục lục
Lời cảm ơn
Tóm tắt nội dung
Mục lục
1
2
3
Lời nói đầu
5
Chương 1: Tổng quan về tái kỹ nghệ
1.1 Bảo trì hệ thống phần mềm
7
7
1.2 Tổng quan chung về tái kỹ nghệ
1.3 Qui trình chung tái kỹ nghệ phần mềm
9
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
47
47
48
50
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ỉ
1.2 Những vấn đề cần cải tiến chương trình
Chương 3: Tái kỹ nghệ chương trình sổ địa chỉ
3
3.1 Sơ đồ tiến trình thực hiện tái kỹ nghệ
50
50
3.2 Qui trình thực hiện tái kỹ nghệ chương trình sổ địa chỉ
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
64
64
64
Tài liệu tham khảo
Tiếng Việt
Tiếng Anh
4
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
5
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
6
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
7
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.
8
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õ
9
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
10
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.
Hệ thống mới
Đặc tả hệ thống
Thiết kế và thực thi
Kỹ thuật dịch xuô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
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
11
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.
Tài liệu
chương
trình
Chương
trình
module hóa
Dữ liệu
nguồn
Chương
trình
nguồn
Kỹ nghệ
ngược
Module hóa
Tái kỹ nghệ
chương
dữ liệu
Dịch mã
nguồn
Cải tiến cấu
trúc chương
trình
Chương
trình được
cấu trúc
Dữ liệu
được tái
kỹ nghệ
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.
12
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.
Tổ chức lại chương
trình tự động
Tổ chức lại chương
trình và dữ liệu
Chuyển đổi mã
nguồn tự động
Tổ chức lại tự động với
Tổ chức lại cộng với
thay đổi thủ công
thay đổi kiến trúc
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à:
13
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
(Biến đổi)
Kỹ nghệ
Nghĩ lại
Khái
Kỹ nghệ
ngược
(Trừu
Khái
xuôi
niệm
niệm
(Cải tiến)
Đặc tả lại
Yêu cầu
Yêu cầu
Thiết kế
Triển khai
Thiết kế
Code lại
So sánh
Thiết kế
Triển khai
Hệ thống ban đầu
Hệ thống đích
chất lượng
chức năng
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ừ
14
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:
15
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ệ 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
Dịch mã
tự động
Thiết kế tài
Dịch mã
thủ công
biệt của mã nguồn
liệu chuyển đổi
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
16
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.
17
Thông tin
chương trình
Lấy thông tin
về chức năng
và cấu trúc
Thông tin
Thông tin
yêu cầu
thiết kế
Lấy thông tin
Lấy đặc tả ban
đầu và thay đổi
về luồng dữ
liệu và luồng
điều khiển
Thông tin
yêu cầu
chi tiết
Thông tin
thiết kế
mức cao
Xem lại yêu
cầu
Xem lại thiết
kế
Thông tin
Thông tin
yêu cầu
được phục
hồi
thiết kế
được phục
Tạo ra tài
liệu
Tạo ra tài
liệu
Tài liệu
mới
Tài liệu
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ế.
18
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.
19
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
20
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
21
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;
22
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 < D or not ( E > F) ) )...
-- điều kiện đơn giản
if A <= B and (C>= 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.
23
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ụ phân
tích và xây dựng
biểu đồ
Công cụ sinh
chương trình
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.
24
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
25
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ố
26
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.
27
− 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 2
Chương trình 3
Tệp 1
Tệp 2
Tệp 3
Tệp 4
Tệp 5
Tệp 6
Chương trình 4
Chương trình 5
Chương trình 6
Chương trình 7
Trở thành
Chương trình 4
Chương trình 5
Chương trình 6
Chương trình 7
Chương trình 3
Chương trình 2
Mô hình dữ
liệu vật lý và
logic
Mô tả
Hệ thống quản lý CSDL
Chương trình 1
Hình 1-11: Chuyển đổi dữ liệu
28
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 đó.
Phân tích
Chương trình được tái kỹ nghệ
dữ liệu
- Sửa đổi tên
thực thể
Định dạng lại
dữ liệu
- Thay thế các
giá trị cố định.
- Sắp xếp lại
định nghĩa dữ
liệu
Chuyển đổi giá
trị mặc định
Sửa đổi các qui
tắc hợp lệ
Phân tích
Chuyển đổi
dữ liệu
dữ liệu
Giai đoạn 1
Giai đoạn 2
Bảng tổng hợp thay đổi
Giai đoạn 3
Dữ liệ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
29
Tải về để xem bản đầy đủ
65 trang
18/06/2025
600
Bạn đang xem 30 trang mẫu của tài liệu "Khóa luận Tái kỹ nghệ hệ thống phần mềm", để tải tài liệu gốc về máy hãy click vào nút Download ở trên.
File đính kèm:
- khoa_luan_tai_ky_nghe_he_thong_phan_mem.pdf
