Software Reengineering (Tái kỹ nghệ phần mềm)

HỌC VIỆN THUẬT MẬT MÃ
Khoa Công Nghệ Thông Tin

Bài Tập Lớn
CÔNG NGHỆ PHẦN MỀM
ĐỀ TÀI: Software Re-engineering (Tái kỹ nghệ phần mềm)

Hà Nội, 26/8/2015

Mục lục
Mục lục

2
1


Lời nói đầu

4

Chương 1: Tổng quan về tái kỹ nghệ

5

1.1 Bảo trì hệ thống phần mềm

5

1.2 Tổng quan chung về tái kỹ nghệ

6

1.3 Qui trình chung tái kỹ nghệ phần mềm

10

1.3.1 Dịch mã nguồn.............................................................................................

11

1.3.2 Kỹ nghệ ngược .............................................................................................

12

1.3.2.1 Làm lại tài liệu .........................................................................................

15

1.3.2.2 Phục hồi thiết kế........................................................................................

15

1.3.3 Cấu trúc lại hệ thống ...................................................................................

16

1.3.4 Module hóa chương trình.............................................................................

18

1.3.5. Tái kỹ nghệ dữ liệu......................................................................................

19

1.4 Các công cụ sử dụng cho tái kỹ nghệ..............................................................

22

1.4.1 Ngôn ngữ UML ............................................................................................

22

1.4.2 Hệ thống phần mềm RATIONAl ROSE ........................................................

25

1.4.3 Tái kỹ nghệ hệ thống với kỹ nghệ đảo ngược của Rational Rose..................

29

1.5 Những ưu điểm và hạn hế của tái kỹ nghệ......................................................

30

1.5.1 Các ưu điểm.................................................................................................

30

1.5.2 Các hạn chế .................................................................................................

30

1.6 Kết luận

31

Chương 2: Bài toán về chương trình “Sổ địa chỉ”

32

2.1 Giới thiệu chương trình sổ địa chỉ

32

2.1.2 Những vấn đề cần cải tiến chương trình

33

Chương 3: Tái kỹ nghệ chương trình sổ địa chỉ

35

3.1 Sơ đồ tiến trình thực hiện tái kỹ nghệ

35

3.2 Qui trình thực hiện tái kỹ nghệ chương trình sổ địa chỉ

35

3.2.1 Xây dựng tài liệu và mô hình thiết kế UML .................................................. 35

3.2.2 Cấu trúc lại chương trình.............................................................................

36

3.2.3 Tái kỹ nghệ dữ liệu.......................................................................................

40

3.2.4 Xây dựng mã nguồn .....................................................................................

42

3.2.5 Hoàn thiện, cài đặt và sử dụng.....................................................................

44

3.3 Kết quả đạt được và một số đánh giá

45
2


3.3.1. Liên quan đến chương trình ........................................................................ 45
3.3.2. Liên quan đến triển khai..............................................................................

46

3.3.3. Một số vấn đề tồn tại...................................................................................

46

Tài liệu tham khảo

47

Tiếng Việt

47

Tiếng Anh

47

3


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 thống nhất UML, Rational Software Architecture,
Rational Rose v.v… Trong phạm vi đề tài này, chúng em 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ỉ.
4


Chương 1: Tổng quan về tái kỹ nghệ
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 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

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.

5


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).
Quy 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õ 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
6


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ũ.
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.

7


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.

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.

8


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.
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.

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à:
1.

2.

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.
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ể.

9


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ừ 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.
10


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:
1.

2.

3.

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 đó.
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.
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
11


4.

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.
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 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

12


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.

13


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ế.

14


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
15


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
16

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ể.
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
17


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.
18


− 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.
− 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.

19


− 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.

Hình 1-11: Chuyển đổi dữ liệu
20


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
21


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ư:
22


− 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ệ

23


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ì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:

24


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.
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

25