Tái kỹ nghệ trong phát triển phần mềm hướng đối tượng

Những phần mềm đã sử dụng trong một thời gian dài có thể có nhiều nhược điểm như: xây dựng trên ngôn ngữ cũ mà hiện nay không còn dùng nữa, tài liệu viết cho phần mềm này cũng đã bị hỏng

MỤC LỤC

LỜI CẢM ƠN

LỜI CAM ĐOAN

TÓM TẮT

MỤC LỤC

BẢNG CÁC CHỮ VIẾT TẮT

DANH MỤC CÁC HÌNH VẼ

DANH MỤC CÁC BẢNG

MỞ ĐẦU 1

Chương 1 TÁI KỸ NGHỆ PHẦN MỀM 3

1.1 Tổng quan về tái kỹ nghệ 3

1.1.1 Bảo trì 3

1.1.2 Tái kỹ nghệ 4

1.2 Dịch mã nguồn 10

1.3 Kỹ nghệ ngược 11

1.4 Phát triển cấu trúc chương trình 13

1.5 Môdul hóa chương trình 17

1.6 Tái kỹ nghệ dữ liệu 19

1.7 Kết luận 24

Chương 2 CÁC CÔNG CỤ TRỢ GIÚP TÁI KỸ NGHỆ 25

2.1 Giới thiệu công cụ Rational Software Architecture 25

2.2 Công cụ lập trình nhúng 38

2.3 Dịch xuôi, dịch ngược trên Rational Software Architecture 40

2.4 Thiết kế hệ thống bằng Rational Software Architecture 41

2.5 Phát triển ứng dụng C/C++ trên Rational Software Architecture 43

Chương 3 HỆ THỐNG CẢNH BÁO THIÊN TAI 50

3.2 Chức năng và hoạt động của hệ thống 52

3.2.1 Mô tả hoạt động của hệ thống cảnh bảo thiên tai 52

3.2.2 Hệ thống xử lý thông tin truyền về 53

3.3 Những vấn đề đặt ra cần tiến hóa hệ thống 57

3.4 Lựa chọn giải pháp tái kỹ nghệ 59

Chương 4 TÁI KỸ NGHỆ TRONG HỆ THỐNG CẢNH BÁO THIÊN TAI 60

4.1 Tiến trình tái kỹ nghệ hệ thống cảnh báo 60

4.1.1 Sơ đồ tiến trình 60

4.1.2 Các bước thực hiện 60

4.1.2.1 Từ mã nguồn của hệ thống chuyển sang mô hình trực quan 61

4.1.2.2 Từ mô hình trực quan cấu trúc lại chương trình 63

4.1.2.3 Modul hóa chương trình 72

4.1.2.4 Tái kỹ nghệ dữ liệu 74

4.1.2.5 Tiến trình dịch chương trình 77

4.2 Quy trình nạp phần mền cho từng nút mạng và vận hành hệ thống 80

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

4.3.1 Cấp nguồn cho cả nút gốc và các nút mạng 82

4.3.2 Đánh giá kết quả qua các phép đo 84

4.3.3 Nhận xét 85

KẾT LUẬN 86

DANH MỤC CÁC CÔNG TRÌNH CỦA TÁC GIẢ 87

TÀI LIỆU THAM KHẢO 88

BẢNG CÁC CHỮ VIẾT TẮT

1 UML Unified Modelling Language

2 OOA Object Oriented Analysis

3 OOD Object Oriented Design

4 OOP Object Oriented Programming

5 RUP Rational Unified Process

6 WSN Wireless Sensor Network

8 SA/SD Structured Analysis/Structured Design

9 LCD Liquid Crystal Display

10 OO Object Oriented

11 RSA Rational Software Architecture

12 HDF Hardware Definition Files

13 HAL Hardware Abstraction Library

14 CUL Chipcon Utility Library

DANH MỤC CÁC HÌNH VẼ

Hình 1-1 Tiến trình kỹ nghệ phần mềm xuôi và tái kỹ nghệ phần mềm 7

Hình 1-2 Tiến trình tái kỹ nghệ phần mềm 9

Hình 1-3 Các cách tiếp cận tái kỹ nghệ 9

Hình 1-4 Tiến trình dịch chương trình 11

Hình 1-5 Tiến trình kỹ nghệ ngược 12

Hình 1-6 Chương trình điều khiển với ống dẫn điện logic 14

Hình 1-7 Chương trình điều khiển cấu trúc 15

Hình 1-8 Đơn giản hóa điều kiện 16

Hình 1-9 Kiến trúc lại chương trình tự động 16

Hình 1-10 Tiếp cận tới việc tái kỹ nghệ dữ liệu 21

Hình 1-11 Di chuyển dữ liệu 22

Hình 1-12 Tiến trình tái kỹ nghệ dữ liệu 23

Hình 2-1 Biểu đồ Ca sử dụng – Use Case 26

Hình 2-2 Biểu đồ Lớp-Class 27

Hình 2-3 Biểu đồ tuần tự - Sequence 27

Hình 2-4 Biểu đồ truyền thông – Communication 28

Hình 2-5 Biểu đồ máy trạng thái – State Machine 28

Hình 2-6 Biểu đồ hoạt động - Activity 29

Hình 2-7 Biểu đồ thành phần - Component 29

Hình 2-8 Biểu đồ cấu trúc tổng hợp – Composite Structure 30

Hình 2-9 Biểu đồ triển khai - Deployment 30

Hình 2-10 Hỗ trợ trong việc soạn mô hình 31

Hình 2-11 Cửa sổ khung nhìn điều khiển 31

Hình 2-12 Chuyển đổi mô hình 32

Hình 2-13- Khung nhìn khai thác các tài nguyên 32

Hình 2-14 Tìm kiếm và sinh mô hình 33

Hình 2-15 Tạo báo cáo các yêu cầu thực hiện 33

Hình 2-16 Phân tích mô hình và xem lại mã 34

Hình 2-17 Tìm mẫu phù hợp 34

Hình 2-18 Công cụ phát triển Enterprise Java Bean 35

Hình 2-19 Công cụ phát triển và quản trị cơ sở dữ liệu 35

Hình 2-20 Công cụ phát triển XML 36

Hình 2-21 Thiết lập cấu hình môi trường C và C++ 36

Hình 2-22 Trực quan hóa các quan hệ của cở sở dữ liệu 37

Hình 2-23 Mô hình phân cấp chức năng 37

Hình 2-24 Mô hình phần mềm nhúng CC1010 38

Hình 2-25 Dịch xuôi và dịch ngược trong UML 41

Hình 2-26 Một bước lặp của quá trình tái thiết kế với xuất phát là mã nguồn 42

Hình 2-27 Một bước lặp của quá trình tái thiết kế xuất phát là mô hình thiết kế 42

Hình 2-28 Tạo dự án trên C/C++ 43

Hình 2-29 Dịch chương trình 44

Hình 2-31 Gỡ rối chương trình 45

Hình 2-32 Sử dụng bộ soạn thảo UML để trực quan hóa ứng dụng 46

Hình 2-33 Sử dụng bộ soạn thảo UML để soạn ứng dụng trên C/C++ 46

Hình 2-34 Thêm lớp mới vào ứng dụng 47

Hình 2-35 Mô hình UML tự động cập nhật 48

Hình 2-36 Hồ sơ dẫn hướng cho C++ điều khiển quá trình sinh mã 48

Hình 2-37 Sinh mã vào dự án 49

Hình 3-1 Hệ thống cảnh báo cháy rừng 50

Hình 3-2 Cấu trúc mạng cảm nhận không dây 52

Hình 3-3 Hệ thống cảnh báo cháy rừng 53

Hình 3-4 Biểu đồ ca sử dụng của nút mạng cảm nhận không dây 53

Hình 3-5 Biểu đồ ca sử dụng với hệ thống xử lý thông tin 54

Hình 3-6 Biểu đồ hoạt động của nút mạng WSN 55

Hình 3-7 Biểu đồ tuần tự của hệ thống 56

Hình 3-8 Mô hình hệ thống phần mền được mô tả phần mền nhúng trên Rational Error! Bookmark not defined Hình 4-1 Quy trình tái kỹ nghệ hệ thống cảnh báo thiên tai 60

Hình 4-2 Từ mã nguồn hệ thống chuyển sang mô hình trực quan 62

Hình 4-3 Các thành phần của chương trình được chuyển về mô hình 62

Hình 4-4 Cửa sổ màn hình soạn thảo mã nguồn 63

Hình 4-5 Sơ đồ tiến trình cấu trúc chương trình 64

Hình 4-6 Tiến trình kiến trúc lại chương trình 65

Hình 4-7 Thuật toán làm việc thu nhận nút mạng cảm nhận 65

Hình 4-8 Định nghĩa thông tin thiết lập 67

Hình 4-9 Giải thuật nước chảy chỗ trũng ACD Sinh 68

Hình 4-10 Lược đồ giải thuật giá tối thiểu 68

Hình 4-11 Ví dụ lược đồ giải thuật giá tối thiểu 69

Hình 4-12 Lớp setting bổ sung 70

Hình 4-13 Thuật toán tại nút cơ sở 71

Hình 4-14 Mô hình thay đổi bổ sung 72

Hình 4-15 Sơ đồ modul hóa cấu trúc chương trình 73

Hình 4-16 Biểu đồ các lớp thành phần trong chương trình 74

Hình 4-17 Sơ đồ cấu trúc dữ liệu địa chỉ bộ nhớ và thanh ghi 75

Hình 4-18 Đoạn mã thực hiện việc truyền dữ liệu 77

Hình 4-19 Tiến trình dịch chương trình 77

Hình 4-20 Bo mạch tool để nạp phần mềm cho nút mạng 80

Hình 4-21 Cách kết nối vào máy tính 81

Hình 4-22 Chương trình nạp phần mềm cho nút mạng 81

Hình 4-23 Kết quả kiểm tra nút số 1 khi nut gốc chưa hoạt động 82

Hình 4-24 Truyền đơn bước khi nút gốc hoạt động 83

Hình 4-25 Truyền đa bước mức nhiệt độ an toàn 83

Hình 4-26 Nhiệt độ vượt quá mức ngưỡng 84

DANH MỤC CÁC BẢNG

Bảng 4-1 Các thành phần cơ bản của UML chuyển sang mã nguồn 78

Bảng 4-2 Các stereotypes 79

Bảng 4-3 Kết quả sau khi vận hành thử nghiệm 84

Bảng 4-4 Bảng kết quả thử nghiệm khi thay đổi không có tiết kiệm năng lượng 85

MỞ ĐẦU

Chúng ta đang bước vào kỷ nguyên của công nghệ thông tin Máy tính với hàng loạt hệ thống các phần mềm đang ngày càng trở nên thân thiện, cần thiết và không thể thiếu trong mọi lĩnh vực hoạt động của con người

Phần mềm ngày càng được hoàn thiện, nâng cao chất lượng và phát triển với kích thước rất lớn Nhưng bên cạnh đó, sự bùng nổ thông tin làm cho một loạt các hoạt động luôn bị thay đổi Đó là sự thay đổi của môi trường, thay đổi của công nghệ, thay đổi của nghiệp vụ,…Để khắc phục những sự thay đổi đó người ta thường đưa hệ thống vào bảo trì Công việc bảo trì phần mềm được xem xét như là một pha tốn kém nhất trong các pha trong vòng đời của một phần mềm Người ta ước tính chi phí cho nó xấp

xỉ 70% tổng công sức chi phí trong sự phát triển phần mềm[1] Nhưng nếu xây dựng lại hệ thống mới thì chưa phải là giải pháp hay, vì khi đó ta phải bỏ đi cả những phần rất hữu dụng trong phần mềm Hơn thế nữa, chi phí cho việc làm ra phần mềm mới là rất tốn kém

Làm thế nào để hàng loạt những hệ thống phần mềm lớn, cũ, đang hoạt động thích nghi được với những thay đổi với mức chi phí thay đổi chấp nhận được Tái kỹ nghệ phần mềm chính là một sự trả lời cho câu hỏi đó

Tái kỹ nghệ phần mềm là hoạt động tiến hóa hệ thống phần mềm để nó có thể tiếp tục được sử dụng cho hiệu quả, giúp ta dễ dàng và đỡ tốn kém hơn trong việc bảo trì sau này

Những phần mềm đã sử dụng trong một thời gian dài có thể có nhiều nhược điểm như: xây dựng trên ngôn ngữ cũ mà hiện nay không còn dùng nữa, tài liệu viết cho phần mềm này cũng đã bị hỏng và thiếu do việc cất giữ và cập nhật chưa tốt, các tính năng hoạt động bị hạn chế do hoạt động nghiệp vụ đã có những thay đổi, … Giải pháp tốt nhất giúp ta tiếp tục sử dụng phần mềm này là tái kỹ nghệ Tái kỹ nghệ là giải pháp tốt nhất và cũng có thể nói là giải pháp duy nhất để đạt được mục đích với chi phí rẻ Hơn thế nữa, nó đảm bảo an toàn cho hoạt động nghiệp vụ của hệ thống đang làm việc

Về mặt khoa học, tái kỹ nghệ đưa ra một giải pháp tiến hóa hệ thống phần mềm bằng những công cụ và phương tiện mới với quy trình khép kín khá hoàn thiện và tiện dụng Về mặt thực tiễn, nó là một hướng giải quyết tốt, vừa đáp ứng nhu cầu tái thiết

kế hệ thống cũ, vừa đem lại hiệu quả lớn và thiết thực về mặt kinh tế

Với các lý do trên, đề tài “tái kỹ nghệ trong phát triển phần mềm hướng đối tượng” được lựa chọn làm đề tài luận văn tốt nghiệp của tôi

Luận văn đề cập tới việc tái kỹ nghệ phần mềm qua đó minh hoạ sự kết hợp thiết

kế hướng đối tượng với công nghệ tái kỹ nghệ hiện có được sử dụng như một quy trình tái kỹ nghệ cho một ứng dụng cho hệ thống cảnh báo hiểm hoạ thiên tai sử dụng hệ thống mạng cảm nhận không dây WSN

Luận văn được trình bày thành bốn chương:

Chương 1: Trình bày về quy trình tái kỹ nghệ hệ thống phần mềm

Chương 2: Trình bày các công cụ trợ giúp quá trình tái kỹ nghệ phần mềm

Chương 3: Giới thiệu về hệ thống cảnh báo thiên tai sử dụng hệ thống mạng cảm

nhận không dây bao gồm việc: mô tả kiến trúc, các chức năng, hoạt động, các hạn chế hiện có, nhu cầu tiến hóa và giải pháp lựa chọn

Chương 4: Vận dụng quá trình phát triển phần mềm RUP và các công cụ trợ giúp

cho việc tái kỹ nghệ hệ thống cảnh báo thiên tai nhằm đáp ứng được những yêu cầu thay đổi hệ thống Qua đó nêu ra quy trình tái kỹ nghệ một hệ thống phần mềm

Cuối cùng đánh giá kết quả của hệ thống được tái kỹ nghệ và phướng hướng phát triển của đề tài

Chương 1 TÁI KỸ NGHỆ PHẦN MỀM

1.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 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 Trong bài này chúng tôi sẽ trình bày một số vấn đề về tái thiết kế hệ thống phần mềm bằng UML (Unified Modeling Language)

1.1.1 Bảo trì

Bảo trì hệ thống nhằm bảo đảm cho hệ thống được tiếp tục hoạt động sau khi thực hiện trắc nghiệm 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 hệ thống, 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

Các hoạt động trong bảo trì phần mềm bao gồm [8]:

 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 gói tin 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

1.1.2 Tái kỹ nghệ

Trong thập kỷ cuối của thế kỷ 20, việc công bố tái kỹ nghệ mới chỉ hé mở, nhưng

ở trong chính mỗi công ty dù lớn hay nhỏ thì quá trình này vẫn tiếp tục Mối liên hệ giữa tái kỹ nghệ nghiệp vụ và tái kỹ nghệ phần mềm liên kết xuyên suốt trong tầm nhìn hệ thống

Tái kỹ nghệ phần mềm thường là việc làm thực tế hóa các quy tắc của kinh doanh Tác giả Hummer cho rằng, nếu các quy tắc này thay đổi thì phần mềm cũng phải thay đổi theo[16] Ngày nay, các công ty lớn có hàng nghìn chương trình hỗ trợ

các quy tắc trong kinh doanh Khi nhà quản lý mà thay đổi những quy tắc này thì hệ số ảnh hưởng và độ cạnh tranh sẽ đạt được nhiều hơn, và khi đó phần mềm cũng phải hỗ trợ kịp thời Khi đó, những hệ thống mới tương thích sẽ được tạo ra, nhưng nhiều trường hợp khác thì chỉ cần sự thay đổi và xây dựng lại những ứng dụng đã có Ở đây, chúng ta xem xét việc tái kỹ nghệ phần mềm theo kiểu top – down[16]

Vậy tái kỹ nghệ là gì? Hãy quan tâm các sản phẩm công nghệ đang được sử dụng

nhiều, nhưng hơi cổ điển, chúng thường hay bị hỏng, mất nhiều thời gian cho việc sửa chữa và không đạt được trình độ của những công nghệ mới Vậy ta phải làm gì? Nếu sản phẩm là phần cứng thì nó được thay bằng thiết bị mới, còn phần mềm thì các lựa chọn không có sẵn và lúc đó cần thiết phải xây dựng lại Ta sẽ phải tạo ra một sản phẩm mà các chức năng khác có thể được thêm vào, hiệu năng tốt hơn, độ tin cậy cao hơn và khả năng bảo trì được cải thiện Đó được gọi là tái kỹ nghệ[16]

Ở mức công ty, tái kỹ nghệ được các chuyên gia (thường là các công ty tư vấn) thực hiện Ở mức phần mềm thì tái kỹ nghệ được các kỹ sư phần mềm thực thi

Chúng ta sống trong một thế giới đang thay đổi nhanh chóng Các yêu cầu trong công việc luôn thay đổi, và trong mỗi tổ chức thương mại luôn có áp lực cạnh tranh Công nghệ thông tin đã hỗ trợ cho những thay đổi này để thích ứng bằng việc tái kỹ nghệ phần mềm

Quá trình tái kỹ nghệ bao gồm phân tích, cấu trúc lại tài liệu, kỹ nghệ ngược, cấu trúc lại mã, cấu trúc lại dữ liệu, kỹ nghệ xuôi Mục đích của các hoạt động này là tạo ra các phiên bản mới của các chương trình đang tồn tại, để nó có chất lượng cao hơn và bảo trì tốt hơn

Sản phẩm của việc tái kỹ nghệ rất đa dạng như: các mẫu phân tích, các mẫu thiết

kế, các thủ tục kiểm thử, Đầu ra cuối cùng là việc tái kỹ nghệ các tiến trình nghiệp vụ và/hoặc tái kỹ nghệ phần mềm

Trong thực tế, không ít các hệ thống phần mềm thương mại là các hệ thống cũ,

nó cần để hỗ trợ cho các tiến trình nghiệp vụ Các công ty cần các hệ thống này đến mức họ phải giữ chúng trong hoạt động Chiến lược phát triển phần mềm bao gồm việc giữ lại, thay thế và phát triển kiến trúc chính là quá trình tái kỹ nghệ phần mềm Tái kỹ nghệ phần mềm đề cập đến việc làm lại hệ thống đang hoạt động để chúng

có thể tiếp tục hoạt động tốt và dễ bảo trì sau này Tái kỹ nghệ có thể bao gồm việc làm lại tài liệu hệ thống, tổ chức và cấu trúc lại hệ thống, biên dịch hệ thống sang ngôn ngữ lập trình hiện đại hơn, chỉnh sửa, cập nhật cấu trúc và lượng giá dữ liệu hệ thống

Thông thường, các chức năng chính của phần mềm không thay đổi và hệ thống cấu trúc của nó cũng được giữ lại

Từ khía cạnh kỹ thuật, tái kỹ nghệ phần mềm có thể xem như một giải pháp thứ hai cho những vấn đề của tiến hóa hệ thống Kiến trúc phần mềm không được cập nhật như đối với các hệ thống trung tâm được phân tán Nó cũng không thể thay đổi hoàn toàn ngôn ngữ lập trình hệ thống, vì hệ thống cũ không thể được chuyển đổi sang ngôn ngữ lập trình hướng đối tượng như Java hoặc C++ vốn có giới hạn trong hệ thống được giữ lại bởi chức năng phần mềm không thay đổi

Tuy nhiên, từ quan điểm nghiệp vụ, tái kỹ nghệ phần mềm có thể chỉ nhằm để bảo đảm rằng hệ thống cũ có thể tiếp tục sử dụng Nó có thể cũng đắt và gặp nhiều rủi

ro như bất kỳ cách tiếp cận khác cho việc tiến hóa hệ thống Để hiểu điều này, chúng

ta cần đưa ra một đánh giá thô về vấn đề của các hệ thống cũ

Số lượng mã trong hệ thống cũ là rất lớn Năm 1990, nó được ước lượng rằng có

120 nghìn tỉ dòng mã nguồn đang tồn tại Phần lớn trong hệ thống này được viết bằng ngôn ngữ COBOL, một ngôn ngữ lập trình phù hợp nhất cho việc xử lý dữ liệu trong kinh doanh, hoặc FORTRAN FORTRAN là một ngôn ngữ lập trình dùng cho khoa học hoặc toán học Các ngôn ngữ này có các hạn chế về khả năng lập cấu trúc chương trình, và ngôn ngữ FORTRAN có nhiều hạn chế cho việc hỗ trợ cấu trúc dữ liệu[16] Mặc dù nhiều chương trình hiện nay cần thay thế, hầu hết trong số chúng chắc chắn còn được sử dụng Trong khi đó, từ năm 1990, có sự tăng mạnh mẽ về việc máy tính dùng trong hỗ trợ công việc kinh doanh Vì vậy, người ta dự đoán rằng, có sấp xỉ

250 nghìn tỷ dòng mã nguồn tồn tại chúng cần được duy trì Hầu hết trong số chúng không được viết bằng ngôn ngữ hướng đối tượng và phần nhiều trong số đó nó còn chạy trên các máy tính lớn[8,16]

Hầu hết các tổ chức cần phải thay thế hoặc tổ chức lại cơ bản về mặt tài chính Việc duy trì các hệ phần mềm cũ làm tăng giá thành Vì vậy, tái kỹ nghệ các hệ thống này để kéo dài thời gian sống hữu ích của chúng Tái kỹ nghệ một hệ thống mang lại lợi nhuận khi nó có giá trị kinh doanh cao nhưng phải đảm bảo ít tốn kém cho việc bảo trì Tái kỹ nghệ cải tiến cấu trúc hệ thống, tạo tài liệu hệ thống mới và làm cho nó dễ hiểu

Tái kỹ nghệ một hệ thống phần mềm có ưu điểm hơn cách tiếp cận phát triển mới

hệ thống; vì:

1 Giảm rủi ro: có sự rủi ro lớn trong việc phát triển mới một phần mềm, đó là tất

yếu với một tổ chức Các lỗi có thể được tạo ra trong đặc tả hệ thống, có thể nảy sinh các vấn đề, không ổn định hệ thống, v.v

2 Giảm giá thành: Giá thành của việc tái kỹ nghệ là thấp hơn đáng kể so với giá

phát triển phần mềm mới Ulrich (1990) đưa ra một ví dụ của hệ thống cũ, ở đó giá xây dựng mới được ước lượng khoảng 50 triệu đôla Hệ thống được tái kỹ nghệ thành công với giá khoảng 12 triệu đô la Nếu con số này là điển hình thì tái

kỹ nghệ rẻ hơn viết lại[8]

Hình 1-1 Tiến trình kỹ nghệ phần mềm xuôi và tái kỹ nghệ phần mềm

Chu kỳ tái kỹ nghệ phần mềm cũng được kết hợp 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ập đến sự thiết kế lại các tiến trình nghiệp vụ để giảm số các hoạt động dư thừa và cải thiện các tiến trình hiệu quả Nó thường dựa trên sự đưa vào hoặc tăng cường về cơ bản sự hỗ trợ của máy tính cho các tiến trình nghiệp vụ Tiến trình tái kỹ nghệ thường hướng việc phát triển phần mềm như hệ thống cũ, có thể chỉ phụ thuộc vào các tiến trình đang tồn tại Tiến trình này cần được phát hiện và hoàn thiện trước khi tiến trình tái kỹ nghệ Vì vậy, sự cần thiết cho tái kỹ nghệ phần mềm trở lên cấp thiết trong một công ty khi sự thay đổi yêu cầu bởi tái kỹ nghệ tiến trình nghiệp vụ không thể đáp ứng được bằng việc duy trì

hệ thống chương trình thông thường

Tái kỹ nghệ

phần mềm

Sự khác biệt cơ bản giữa tái kỹ nghệ và phát triển phần mềm mới là điểm bắt đầu cho sự phát triển Dĩ nhiên bắt đầu với việc viết các đặc điểm kỹ thuật, hệ thống cũ hoạt động như một bản đặc tả cho hệ thống mới Chikofsky và Cross (1990) quy ước

gọi phát triển kỹ nghệ xuôi (forward engineering) để phân biệt nó với tái kỹ nghệ phần

mềm Sự phân biệt này được minh họa trong hình 1.1[8] Kỹ nghệ xuôi bắt đầu với một hệ thống đặc tả và bao gồm bản thiết kế và sự triển khai hệ thống mới Tái kỹ nghệ bắt đầu với một hệ thống đang tồn tại và phát triển tiến trình để việc thay thế dựa trên sự hiểu và biến đổi hệ thống gốc

Hình 1.2 minh hoạ tiến trình tái kỹ nghệ khả thi Đầu vào của tiến trình là một chương trình kế thừa và đầu ra là một cấu trúc, phiên bản hiệu chỉnh của chương trình

Ở cùng thời điểm như chương trình tái kỹ nghệ, dữ liệu cho hệ thống cũng có thể được tái kỹ nghệ Các hoạt động trong tiến trình tái kỹ nghệ này là:

1 Chuyển đổi mã nguồn: Chương trình được chuyển đổi từ một ngôn ngữ lập trình

phiên bản cũ sang một phiên bản mới hơn hoặc sang một ngôn ngữ khác

2 Kỹ nghệ ngược: Chương trình được phân tích và trích ra các thông tin từ nó để

giúp làm tài liệu về tổ chức và các chức năng của nó

3 Cải tiến cấu trúc chương trình: Cấu trúc điều khiển của chương trình được phân

tích và chỉnh sửa làm cho nó dễ đọc và dễ hiểu hơn

4 Modul hóa chương trình: Việc thay thế các phần của chương trình được nhóm với

nhau và được làm cho phù hợp, bổ sung modul mới và bỏ đi những dư thừa Trong một số trường hợp, giai đoạn này có thể bao gồm cả sự biến đổi kiến trúc

5 Tái kỹ nghệ dữ liệu: Dữ liệu xử lý bởi chương trình được thay đổi tương ứng với

sự thay đổi chương trình

Chương trình tái kỹ nghệ có thể không cần thiết yêu cầu tất cả các bước trong hình 1.2 Việc chuyển mã nguồn có thể không cần thiết nếu ngôn ngữ lập trình dùng

để phát triển hệ thống còn được hỗ trợ bởi công ty cung cấp trình biên dịch Nếu tái kỹ nghệ hoàn toàn dựa vào các công cụ tự động thì tài liệu lấy ra thông qua tái kỹ nghệ có thể là không cần thiết Tái kỹ nghệ dữ liệu chỉ được yêu cầu nếu cấu trúc dữ liệu trong chương trình thay đổi khi tái kỹ nghệ hệ thống đòi hỏi Tuy nhiên, tái kỹ nghệ phần mềm luôn bao gồm một số chương trình được cấu trúc lại

Hình 1-2 Tiến trình tái kỹ nghệ phần mềm

Giá của việc tái kỹ nghệ rõ ràng phụ thuộc vào mức độ khó khăn của công việc thực hiện Có nhiều cách tiếp cận khả thi với tái kỹ nghệ như chỉ ra trong hình 1.3 Giá tái kỹ nghệ tăng từ trái sang phải: từ mức chỉ phải chuyển đổi mã nguồn (là rẻ nhất ) đến mức cao nhất là phải thay đổi lại toàn bộ cấu trúc

Hình 1-3 Các cách tiếp cận tái kỹ nghệ

Chương

trình gốc

Tài liệu chương trình

Chương trình được modul hóa

Dữ liệu gốc

Dữ liệu được tái kỹ nghệ

Chương trình được cấu trúc lại

Dịch sang

mã mới

Kỹ nghệ đảo ngược

Modul hóa chương trình

Tái kỹ nghệ

dữ liệu

Cải tiến cấu trúc chương trình

Giá tăng

Tự động kết cấu lại chương trình

Tự động kết cấu lại với

sự thay đổi thủ công

Cấu trúc lại cùng với sự thay đổi kiến trúc

Kết cấu lại dữ liệu

và chương trình

Tự động chuyển

đổi mã nguồn

Ngoài các yếu tố liên quan đến việc mở rộng hoạt động tái kỹ nghệ, còn có những yếu tố khác về nguyên tắc có ảnh hưởng tới giá của việc tái kỹ nghệ như sau:

1 Chất lượng phần mềm được tái kỹ nghệ: Giá trị chất lượng của phần mềm và tài

liệu của nó cao hơn giá của tái kỹ nghệ

2 Giá trị công cụ hỗ trợ cho việc tái kỹ nghệ: Giá trị hiệu quả cho việc tái kỹ nghệ

một hệ thống phần mềm có thể thấp hơn giá trị công cụ CASE để tự động thay đổi hầu hết các chương trình

3 Phạm vi của yêu cầu chuyển đổi dữ liệu: Nếu tái kỹ nghệ yêu cầu chuyển đổi một

số lớn dữ liệu, điều đó làm tăng đáng kể giá thành thực hiện

4 Giá trị của đội ngũ chuyên môn: Nếu trách nhiệm nhân viên bảo trì hệ thống

không được sử dụng trong tiến trình tái kỹ nghệ, việc này sẽ làm tăng giá thành Đội ngũ chuyên môn tái kỹ nghệ sẽ cần nhiều thời gian để hiểu hệ thống

Nhược điểm chính của tái kỹ nghệ phần mềm là các giới hạn thực tế đối với việc

mở rộng hệ thống có thể nằm trong phạm vi của việc tái kỹ nghệ Điều này là có thể

Ví dụ, chuyển đổi một hệ thống văn bản sử dụng tiếp cận chức năng tới hệ thống hướng đối tượng Kiến trúc chính thay đổi hoặc tổ chức lại căn bản việc quản lý dữ liệu hệ thống không thể được thực hiện tự động, như thế liên quan cao đến việc thêm giá thành Mặc dù tái kỹ nghệ có thể cải tiến việc bảo trì, tái kỹ nghệ hệ thống sẽ không thể duy trì được như hệ thống mới phát triển sử dụng các phương pháp tái kỹ nghệ phần mềm hiện đại

1.2 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 tự động chương trình mã nguồn trong một ngôn ngữ lập trình sang mã nguồn của một số ngôn ngữ khác Cấu trúc và tổ chức chương trình của nó không thay đổi Ngôn ngữ đích có thể là một phiên bản mới cập nhật của ngôn ngữ gốc (ví dụ: COBOL74 tới COBOL85) hoặc có thể được dịch sang một ngôn ngữ hoàn toàn khác (ví dụ: FORTRAN sang C)

Sau đây là các lý do cần dịch mã nguồn:

1 Cập nhật nền phần cứng mới: Tổ chức muốn thay đổi nền phần cứng chuẩn Các

bộ dịch ngôn ngữ gốc không có giá trị trên phần cứng mới

2 Thiếu đội ngũ có kỹ năng: Có thể thiếu đội ngũ bảo trì lành nghề cho ngôn ngữ

gốc Đây là một vấn đề thực tế ở đó các chương trình được viết bằng một ngôn ngữ không chuẩn mà hiện tại không sử dụng

3 Các thay đổi chính sách của tổ chức: tổ chức có thể quyết định chuẩn hóa trên

ngôn ngữ thực tế để giảm thiểu chi phí trợ giúp phần mềm trợ giúp của nó Bảo trì một số phiên bản của bộ dịch cũ có thể rất đắt

4 Sự yếu kém của việc trợ giúp phần mềm: Các nhà cung cấp chương trình dịch có

thể đã bỏ việc kinh doanh hoặc không tiếp tục hỗ trợ sản phẩm của họ nữa

Hình 1-4 Tiến trình dịch chương trình

Hình 1.4 chỉ ra tiến trình dịch mã nguồn Có thể không cần hiểu chi tiết hoạt động của phần mềm hoặc chỉnh sửa kiến trúc hệ thống Phân tích sự liên quan có thể tập trung vào ngôn ngữ lập trình tương đương như cấu trúc điều khiển chương trình Việc dịch mã nguồn chỉ thực sự là kinh tế nếu bộ dịch tự động sẵn sàng để thực hiện với một số lượng lớn Đây 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ừ một ngôn ngữ này sang một ngôn ngữ khác hoặc một hệ thống mẫu thích hợp Trong trường hợp thứ hai, cách thức một tập các lệnh để tạo sự dịch chuyển từ sự trình bày này sang một sự trình bày khác cần được viết các mẫu được tham số hóa trong ngôn ngữ nguồn được xác định và kết hợp 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 hoàn toàn tự động là không thể Các cấu trúc trong ngôn ngữ nguồn không có cấu trúc tương đương trực tiếp trong ngôn ngữ đích

Có thể các lệnh điều kiện biên dịch trong mã nguồn mà không được hỗ trợ trong ngôn ngữ đích Trong trường hợp này, bạn cần tạo ra sự thay đổi thủ công làm cho phù hợp

và cải tiến hệ thống sinh lệnh

Dịch mã

tự động

Dịch mã bằng tay

thay đổi bởi tiến trình kỹ nghệ ngược Mã nguồn phần mềm thường có giá trị như đầu vào cho tiến trình Kỹ nghệ ngược Tuy nhiên, điều này có thể không có và Kỹ nghệ ngược cần bắt đầu với mã thực thi

Kỹ nghệ ngược không hoàn toàn giống như tái kỹ nghệ (re-engineering) Mục tiêu của kỹ nghệ ngược thu được là thiết kế hoặc đặc tả của hệ thống từ mã nguồn của

nó Mục tiêu của tái kỹ nghệ là làm ra một hệ thống phần mềm mới, dễ bảo trì hơn Tất nhiên, như chúng ta có thể thấy trong hình 1.2, kỹ nghệ ngược để có được một sự hiểu biết về hệ thống và thường là một phần của tiến trình tái kỹ nghệ

Kỹ nghệ ngược được dùng trong tiến trình tái kỹ nghệ phần mềm là để phục hồi lại thiết kế chương trình mà sẽ giúp các kỹ sư hiểu tốt một chương trình trước khi tổ chức lại cấu trúc của nó Tuy nhiên, không nhất thiết theo sau kỹ nghệ ngược phải là tái kỹ nghệ:

1 Bản 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ì chúng có thể dùng như một đầu vào cho đặc tả các yêu cầu của chương trình cần thay thế

2 Như một sự lựa chọn, bản thiết kế và đặc tả có thể được kỹ nghệ ngược, vì chúng sẵn sàng để giúp bảo trì chương trình Thông tin này có thể không cần thiết cho việc tái kỹ nghệ mã nguồn hệ thống

Biểu đồ cấu trúc chương trình

Biểu đồ cấu trúc dữ liệu

Ma trận lần vết thực thể chức năng

Phân tích tự động

Diễn giải thủ công

Tạo tài liệu

nhận ra cấu trúc của nó Trong bản thân nó, không đủ để tái tạo hệ thống thiết kế Sau

đó các kỹ sư làm việc với mã nguồn hệ thống và mô hình cấu trúc của nó Họ thêm thông tin vào pha này khi họ hiểu hệ thống Thông tin này được lưu trữ như một đồ thị

có hướng gắn kết tới mã nguồn chương trình

Trình duyệt kho thông tin được dùng để so sánh cấu trúc đồ thị với mã nguồn và diễn giải đồ thị với các thông tin bổ sung Các tài liệu của các kiểu khác nhau như biểu

đồ cấu trúc chương trình và biểu đồ cấu trúc dữ liệu và ma trận lần vết có thể được sinh từ đồ thị có hướng Các ma trận thực thể chức năng chỉ ra nơi các thực thể trong

hệ thống được định nghĩa và tham chiếu Tiến trình sinh tài liệu là một quá trình lặp khi thông tin thiết kế được dùng để thúc đẩy việc tinh lọc thông tin lưu trữ trong kho

dữ liệu

Các công cụ để hiểu chương trình có thể được dùng để hỗ trợ tiến trình kỹ nghệ ngược Công cụ này thường biểu thị sự quan sát hệ thống khác và cho phép dễ dàng điều hướng thông qua mã nguồn Ví dụ, chúng cho phép người dùng lựa chọn định nghĩa dữ liệu, sau đó di chuyển thông qua mã tới nơi dữ liệu được dùng Ví dụ duyệt chương trình được thảo luận bởi Cleveland (1989), Oman và Cook (1990) và Ning (1994)[16]

Sau khi tài liệu thiết kế hệ thống được tạo sinh, nhiều thông tin có thể được thêm vào để giúp tái tạo hệ thống đặc tả Việc này thường liên quan nhiều tới sự diễn giải thủ công cấu trúc hệ thống Đặc tả không thể được suy ra tự động từ mô hình hệ thống

1.4 Phát triển cấu trúc chương trình

Cần sử dụng bộ nhớ tối ưu và sự thiếu hiểu biết về kỹ nghệ phần mềm bởi một số người lập trình, nghĩa là một số hệ thống cũ không được cấu trúc tốt Sau khi cấu trúc điều khiển bị lộn xộn với một số nhánh vô điều kiện và logic điều khiển không rõ ràng Cấu trúc này cũng có thể bị giảm giá trị bởi sự bảo dưỡng thường xuyên Sự thay đổi chương trình có thể được tạo ra

Hình 1.6 minh họa sự phức tạp trong điều khiển, ta có thể tạo một chương trình khác đơn giản hơn để thực hiện Chương trình được viết tựa như FORTRAN Trong hình 1.6 là bộ điều khiển một hệ thống lò sưởi Một bộ công tắc có thể đặt ở một trong

3 trạng thái: on, off, controlled Nếu hệ thống được điều khiển khi nó chuyển On và tắt phụ thuộc vào thời gian đặt và bộ điều nhiệt Nếu lò sưởi là ON thì chuyển công tắc lò sưởi thành OFF và ngược lại

Đặc biệt, các chương trình phát triển này có độ phức tạp logic cấu trúc vì chúng được chỉnh sửa trong khi bảo trì Thêm các điều kiện kết hợp các hoạt động mà không thay đổi cấu trúc điều khiển đang tồn tại Trong một thời hạn ngắn, đây là một giải pháp nhanh và ít mạo hiểm vì nó giảm sự thay đổi lỗi trong hệ thống Tuy nhiên, trong một thời gian dài nó dẫn đến khó hiểu mã chương trình Cấu trúc mã phức tạp có thể cũng xuất hiện do khi những người lập trình cố gắng tránh sự lặp lại mã Điều này, đôi lúc cần thiết khi chương trình bị ràng buộc vì bộ nhớ có giới hạn

Hình 1-6 Chương trình điều khiển với ống dẫn điện logic

Start: Get(Time-on, Time-off, Time, Setting, Temp, Switch)

If Switch=off goto off

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

Hình 1-7 Chương trình điều khiển cấu trúc

Hình 1.7 chỉ ra hệ thống điều khiển tuần tự được viết lại khi sử dụng cấu trúc điều khiển Chương trình có thể đọc liên tục từ trên xuống dưới, như vậy nó khá dễ hiểu Ba vị trí chuyển đổi on, off, và controlled được định nghĩa rõ ràng và liên kết tới

mã của vật liên kết của nó Ta không sử dụng Java khi chương trình nguồn không là chương trình hướng đối tượng

if Heating-status = off then

Switch-heating; Heating-status :=on;

if Time >= Time-on and Time <= Time-off then

if Temp > Setting and Heating-status = on then

Hình 1-8 Đơn giản hóa điều kiện

Hình 1-9 Kiến trúc lại chương trình tự động

Cũng như điều khiển không có cấu trúc, các điều kiện phức tạp có thể cũng được đơn giản hóa khi một phần của chương trình được xử lý lại

Bohm và Jacopini (1966) chứng minh rằng: bất kỳ một chương trình nào đều có

thể viết lại với ngôn ngữ đơn giản là câu lệnh điều kiện if-then-else và vòng lặp while

mà ở đó không dùng câu lệnh goto[16] Định lý này là điều kiện cơ bản cho việc kiến

trúc lại chương trình tự động Hình 1.9 chỉ ra con đường kiến trúc lại tự động của một chương trình Đầu tiên, nó được chuyển đổi thành đồ thị có hướng, sau đó là một chương trình cấu trúc tương đương (không có câu lệnh goto) được sinh ra

Đồ thị có hướng được sinh ra như một biểu đồ luồng chương trình, nó chỉ ra cách điều khiển di chuyển xuyên suốt chương trình Công nghệ đơn giản hóa và biến đổi có thể được áp dụng cho đồ thị này mà không thay đổi ngữ nghĩa của nó Công nghệ này

tự dò tìm và bỏ đi những phần mã không thể tiếp cận được Lần thứ nhất, sự đơn giản

hóa được thực hiện thì một chương trình mới được sinh ra Vòng lặp While và các điều kiện đơn giản được thay thế cho điều khiển goto Chương trình này có thể được để

trong ngôn ngữ gốc hoặc trong ngôn ngữ khác (ví dụ FORTRAN hay C)

Vấn đề cấu trúc lại chương trình tự động bao gồm:

Trình diễn biểu đồ Phân tích và xây

dựng biểu đồ chương trình Bộ sinh mã

1 Mất các lời chú thích: Nếu chương trình có chú thích trong một dòng thì dòng

chú thích này sẽ mất giá trị khi một phần của tiến trình kiến trúc lại

2 Mất tài liệu: Tương tự, sự tương ứng giữa tài liệu chương trình bên ngoài và

chương trình cũng mất Tuy nhiên trong một vài trường hợp, cả phần chú thích

và tài liệu của chương trình đều quá hạn, như vậy đây không phải là một nhân tố quan trọng

3 Yêu cầu tính toán lớn: giải thuật nhúng trong công cụ cấu trúc lại phức tạp Mặc

dù phần cứng hiện đại, nhanh, nó cũng có thể mất một thời gian dài để hoàn thành tiến trình cấu trúc lại cho chương trình lớn

Nếu chương trình là ổ đĩa dữ liệu với các thành phần kết hợp chặt chẽ thông qua chia sẻ cấu trúc dữ liệu, cấu trúc lại mã không thể dẫn tới cải tiến tín hiệu trong sự thông hiểu Điều chỉnh chương trình, như diễn tả trong phần sau, có thể cũng cần thiết Nếu chương trình được viết trong một ngôn ngữ không chuẩn, công cụ cấu trúc lại chuẩn không thể làm việc đúng và các tín hiệu bằng tay có thể được xen vào

Trong một số trường hợp, nó không thể có giá trị hiệu quả khi cấu trúc lại toàn

bộ chương trình trong hệ thống Một vài trường hợp có thể đạt chất lượng tốt hơn chương trình khác và một vài trường hợp không dễ bị thay đổi thường xuyên Arthur (1988) giả thuyết rằng, dữ liệu nên được tập hợp để giúp nhận biết các chương trình

mà nó có thể được lợi nhất từ việc cấu trúc lại Ví dụ, các độ đo sau có thể được sử dụng để nhận biết các ứng cử cho kiến trúc lại

1.5 Môdul hóa chương trình

Mô đul hóa chương trình là tiến trình tổ chức lại chương trình sao cho những phần chương trình được tập hợp với nhau và được xem như là một modul Khi chương trình đã được modul hóa, dễ bỏ đi những phần thừa trong các phần được thay thế, để tối ưu chương trình, để các phần của chương trình tương tác với nhau trong một giao diện đủ đơn giản

Ví dụ, trong một chương trình xử lý dữ liệu địa trấn, tất cả các hoạt động kết hợp với sự trình diễn đồ họa của dữ liệu có thể được tập hợp với nhau trong một modul đơn giản Nếu hệ thống bị phân tán, các modul được tạo có thể được gói gọn như các đối tượng và truy cập thông qua giao diện chung Vài kiểu modul khác nhau có thể được tạo trong khi xử lý modul hóa chương trình Quá trình nay gồm:

1 Trừu tượng dữ liệu: Kiểu dữ liệu trừu tượng được tạo bởi sự kết hợp dữ liệu với

các thành phần tiến trình

2 Modul hóa phần cứng: Thay dữ liệu trừu tượng và tập hợp tất cả các hàm chúng

với nhau một cách chặt chẽ, nó được sử dụng để điều khiển thiết bị phần cứng riêng biệt

3 Modul hóa chức năng: Đó là các modul mà nó tập hợp các chức năng với nhau,

các chức năng này đồng dạng hoặc có các tác vụ gần nhau Ví dụ, tất cả các chức năng có liên quan với đầu vào và giá trị đầu vào có thể được hợp nhất trong một modul đơn giản Kiểu này của sự modul hóa được xét đến khi không cần sửa lại trừu tượng dữ liệu chương trình

4 Modul trợ giúp tiến trình: Đó là các modul mà ở đó tất cả các chức năng và các

mục dữ liệu đặc biệt yêu cầu để trợ giúp tiến trình nghiệp vụ đặc biệt được nhóm lại Ví dụ, trong một hệ thống thư viện, một modul trợ giúp tiến trình có thể gồm tất cả các chức năng yêu cầu để trợ giúp sự phát hành và phản hồi của sách Modul hóa chương trình thường thực hiện thủ công bởi sự kiểm tra và sửa chữa

mã nguồn Để modul hóa một chương trình, bạn cần nhận ra quan hệ, giữa các thành phần và thực hiện những gì mà các thành phần này làm Các công cụ trình diễn và làm trực quan trợ giúp nhưng nó không thể tự động hoàn thành tiến trình này

Phục hồi dữ liệu trừu tượng

Để tiết kiệm không gian nhớ, các hệ thống cũ dựa trên việc sử dụng các bảng chia sẻ và các vùng dữ liệu chung Thông tin trong vùng này có thể truy cập và cũng

có thể được sử dụng ở những phần khác nhau trong hệ thống bằng những cách thức khác nhau Việc thay đổi những vùng dữ liệu tổng thể là chi phí rất đắt vì giá của việc phân tích dẫn đến mọi việc sử dụng dữ liệu đều thay đổi Để giảm bớt giá thành của việc thay đổi trên các vùng dữ liệu chia sẻ này, các modul chương trình xử lý có thể tập trung vào các vùng xác định của dữ liệu trừu tượng Dữ liệu trừu tượng hoặc các kiểu dữ liệu trừu tượng tập hợp các dữ liệu lại với nhau và xử lý liên kết dẫn đến việc thay đổi ngầm Dữ liệu trừu tượng ẩn trong các thể hiện dữ liệu, cung cấp hàm thiết

lập và truy cập tới các hàm để sửa đổi và kiểm tra các dữ liệu Vì các giao diện không thay đổi nên những sự thay trong các kiểu dữ liệu không nên làm ảnh hưởng đến các phần khác của chương trình Các bước có liên quan tới việc chuyển đổi từ các vùng dữ liệu chung tới các đối tượng hoặc tới các kiểu dữ liệu trừu tượng là:

1 Phân tích các vùng dữ liệu chung để xác định được các trừu tượng dữ liệu logic

Nó thường xẩy ra trong các trường hợp, một số trừu tượng được kết hợp trong một vùng dữ liệu chia sẻ đơn Nó nên được xác định và cấu trúc lại logíc

2 Tạo một kiểu hoặc đối tượng dữ liệu trừu tượng cho mỗi trừu tượng này Nếu ngôn ngữ lập trình không có tiện ích dữ liệu ẩn, giả lập một kiểu dữ liệu trừu tượng bởi các hàm điều kiện để cập nhật và truy cập tất cả các trường của dữ liệu

3 Sử dụng hệ thống trình duyệt chương trình hoặc bộ tham chiếu chéo để tìm tới tất

cả những phần liên quan tới dữ liệu này Thay thế cái này bằng việc gọi tới các hàm sấp xỉ

Tiến trình này có vẻ như tốn nhiều thời gian nhưng khá dễ hiểu Tuy nhiên, trong thực tế, nó có thể rất khác bởi cách thức trong vùng dữ liệu chia sẻ được dùng Trong phiên bản cũ của ngôn ngữ như FORTRAN nó có giới hạn những phương thức cấu trúc dữ liệu Những người lập trình có thể thiết kế chiến lược quản lý dữ liệu phức tạp

mà họ cần tiến hành sử dụng các mảng chia sẻ Bởi vậy, trên thực tế mảng có thể được dùng như kiểu khác của cấu trúc dữ liệu Vấn đề tiếp theo có nguyên nhân bởi địa chỉ gián tiếp của cấu trúc chia sẻ và địa chỉ đoạn từ một vài cấu trúc khác

Nếu máy đích cho chương trình gốc có bộ nhớ giới hạn, do nguyên nhân này hay nguyên nhân khác, những người lập trình có thể sử dụng sự hiểu biết về thời gian sống

dữ liệu và việc nhúng nó trong chương trình Để tránh việc cấp thêm không gian, họ sử dụng miền dữ liệu tương tự để lưu các trừu tượng khác ở các điểm khác trong chương trình Việc này có thể chỉ được khám phá sau phân tích tĩnh và phân tích động của chương trình

1.6 Tái kỹ nghệ dữ liệu

Như phần trước, hầu hết sự thảo luận về phát triển phần mềm đều tập chung vào vấn đề thay đổi chương trình và hệ thống phần mềm Tuy nhiên, trong một số trường hợp, đó lại là vấn đề kết hợp phát triển dữ liệu Sự lưu trữ, tổ chức và định dạng dữ liệu xử lý bởi các chương trình kế thừa có thể cần đưa ra để phản hồi sự thay đổi tới

phần mềm Đôi khi, tiến trình phân tích và tổ chức lại của cấu trúc dữ liệu làm cho giá

trị dữ liệu trong hệ thống dễ hiểu được gọi là tái kỹ nghệ dữ liệu

Tái kỹ nghệ dữ liệu sẽ không cần thiết nếu chức năng của hệ thống không đổi Tuy nhiên, trong thực tế, có một số lý do ta cần sửa dữ liệu trong các chương trình của

hệ thống cũ:

1 Sự suy thoái dữ liệu: Như trên, chất lượng của dữ liệu hướng tới sự suy giảm dần

Sự thay đổi dữ liệu mở đầu cho các lỗi, các giá trị giống nhau có thể được tạo ra

và sự thay đổi môi trường bên ngoài không thể được phản ánh vào trong dữ liệu Đây là điều không thể tránh được bởi thời gian sống của dữ liệu thường là rất dài

Ví dụ, dữ liệu phản hồi của cá nhân vào trong dữ liệu đang tồn tại khi một tài khoản được mở và có thể cần tiếp tục tồn tại ít nhất là bằng thời gian sống của khách hàng Khi lý lịch của khách hàng thay đổi, sự thay đổi này có thể không thích hợp với dữ liệu trong nhà băng Tái kỹ nghệ chương trình có thể mang vấn

đề chất lượng dữ liệu tới sự sáng tỏ và đó là điểm mấu chốt cần kết hợp tái kỹ nghệ dữ liệu

2 Các hạn chế vốn có được xây dựng trong chương trình: Khi thiết kế ban đầu,

những người phát triển của nhiều chương trình đã đưa vào những ràng buộc tự xây dựng về số lượng dữ liệu mà nó có thể xử lý Tuy nhiên, ngày nay chương trình thường yêu cầu xử lý nhiều dữ liệu hơn dự tính ban đầu của các nhà phát triển Tái kỹ nghệ dữ liệu có thể được yêu cầu để hủy bỏ các giới hạn đó Ví dụ, Rochester và Douglass (1993) diễn tả hệ thống quản lý tiền, nó được thiết kế ban đầu để lưu giữ 99 loại vốn Công ty chạy hệ thống đang quản lý hơn 2000 loại vốn, và cần chạy 23 bản rời nhau của hệ thống Như vậy, họ quyết định tái kỹ nghệ hệ thống và kết hợp dữ liệu của nó[16]

3 Phát triển kiến trúc: Nếu một hệ thống tập trung chuyển sang một kiến trúc phân

tán, điều cần thiết cốt lõi của kiến trúc đó là một hệ thống quản lý dữ liệu, nó có thể được truy cập từ các máy trạm Điều này có thể yêu cầu một sự cố gắng lớn trong việc tái kỹ nghệ để di chuyển dữ liệu từ các tệp rời vào trong hệ thống quản

lý dữ liệu chủ Sự di chuyển tới một kiến trúc chương trình phân tán có thể được khởi tạo khi một tổ chức quyết định di chuyển từ việc quản lý dữ liệu bằng các tệp cơ sở sang hệ thống quản lý cơ sở dữ liệu

Giống như tái kỹ nghệ chương trình, có một tập các cách tiếp cận tới tái kỹ nghệ

dữ liệu Nó phản ánh lý do tại sao việc tái kỹ nghệ dữ liệu được yêu cầu Điều này được chỉ ra trong hình 1.10

Mở rộng dữ

liệu

Trong trường hợp này, dữ liệu và chương trình được tái kỹ nghệ để

bỏ đi giới hạn trên việc xử lý dữ liệu Việc này có thể yêu cầu thay đổi tới chương trình để tăng chiều dài trường, sửa tăng giới hạn trên bảng,…Sau đó, dữ liệu, tự nó có thể viết lại và làm sạch để phản ánh

sự thay đổi của chương trình

Di chuyển

dữ liệu

Trong trường hợp này, dữ liệu được di chuyển vào sự điều khiển của

hệ quản trị cơ sở dữ liệu hiện đại Dữ liệu có thể được lưu trữ trong các tệp độc lập hoặc có thể được quản lý bởi một kiểu cũ hơn của DBMS Điều này được minh họa trong hình 1.11

Hình 1-10 Tiếp cận tới việc tái kỹ nghệ dữ liệu

Rickets (1993) mô tả một số vấn đề với dữ liệu có thể xuất hiện trong hệ thống

cũ của một vài chương trình hoạt động[16]:

 Vấn đề tên dữ liệu: Tên có thể là bí ẩn và khó để hiểu Các tên khác có thể được

đưa vào cùng một thực thể logíc trong các chương trình khác trong hệ thống Tên tương tự có thể được sử dụng trong chương trình khác với nghĩa khác

 Vấn đề chiều dài trường: Đây là vấn đề khi chiều dài trường trong các bản ghi

được gán trong chương trình Mục tương tự có thể được gán cho chiều dài khác trong các chương trình khác hoặc chiều dài trường có thể cũng ngắn để diễn tả dữ liệu hiện tại Để 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 đến nỗi qua tên trường dữ liệu của chương trình trong

hệ thống là mâu thuẫn nhau

Hình 1-11 Di chuyển dữ liệu

 Vấn đề tổ chức bản ghi: Sự diễn tả các bản ghi tương tự thực thể có thể được tổ

chức khác nhau trong các chương trình khác nhau Đây là một vấn đề trong ngôn ngữ giống như COBOL, ở đó tổ chức vật lý các bản ghi được người lập trình tạo lập và phản chiếu trong các tệp Nó không là một vấn đề trong ngôn ngữ như C++ hoặc Java, ở đó tổ chức vật lý của một bản ghi là trách nhiệm của trình biên dịch

 Các từ ngữ mã cứng: Các giá trị từ ngữ (tuyệt đối), như tỉ lệ đòi hỏi, bao gồm

trực tiếp trong chương trình tốt hơn là tham chiếu sử dụng một số tên ký hiệu

 Từ điển dữ liệu: Có thể có từ điển dữ liệu định nghĩa tên sử dụng diễn tả chúng

Chương trình 4 Chương trình 5 Chương trình 6 Chương trình 7

Chương trình 1 Chương trình 2 Chương trình 3 Chương trình 4

Chương trình 5 Chương trình 6

Chương trình 7

Mô hình dữ liệu vật lý và logíc Diễn tả

Hệ quản trị cơ sở

dữ liệu

Trở thành

được chuyển đổi tới để hợp với cấu trúc mới Rickets cũng diễn tả một số giá trị dữ liệu có thể mâu thuẫn

Phân tích chi tiết chương trình sử dụng dữ liệu là việc làm cần thiết trước khi tái

kỹ nghệ dữ liệu Các phân tích này nên tập trung vào việc tìm hiểu các chức năng của các định nghĩa trong chương trình, tìm các giá trị chữ mà nó nên được thay thế với tên không đổi Các công cụ tham chiếu qua việc phân tích các mẫu có thể sử dụng trợ giúp với các phân tích này Một tập các bảng nên được tạo ra mà ở đó nó chỉ ra các đối tượng dữ liệu được tham chiếu và thay đổi được tạo ra với mỗi tham chiếu này

Hình 1-12 Tiến trình tái kỹ nghệ dữ liệu

Hình 1.12 minh họa tiến trình tái kỹ nghệ dữ liệu, giả định rằng định nghĩa dữ liệu được chỉnh sửa, định danh các giá trị chữ, tổ chức lại định dạng dữ liệu và chuyển đổi các giá trị dữ liệu Bảng tổng hợp thay đổi lưu trữ chi tiết tất cả các thay đổi được tạo ra Vì vậy, chúng được sử dụng ở tất cả giai đoạn của tiến trình tái kỹ nghệ

Trong giai đoạn 1 của tiến trình, định nghĩa dữ liệu trong chương trình được chỉnh sửa cải tiến để có thể hiểu được Dữ liệu tự nó không được chỉnh sửa trong việc sửa đổi này Có thể tự động tiến trình này tới một số phạm vi sử dụng mẫu phù hợp hệ thống như awk (1988) tìm và thay thế các định nghĩa hoặc để phát triển các diễn tả XML của dữ liệu (Laurent và Cerami,1999) và dùng giai đoạn này để điều khiển công

cụ chuyển đổi dữ liệu Tuy nhiên, một số công việc thủ công hầu như là cần thiết để hoàn thành tiến trình[16] Tiến trình tái kỹ nghệ dữ liệu có thể dừng ở giai đoạn này

Chương trình được tái kỹ nghệ Phân tích dữ

liệu

Phân tích

Bảng tổng hợp thay đổi chỉnh sửa Dữ liệu

− Tên thực thể sửa chữa

− Chữ thay thế

− Sắp xếp lại định nghĩa dữ liệu

− Định dạng lại dữ liệu

− Chuyển đổi giá trị mặc định

− Thông qua luật sửa đổi

nếu đích đơn giản chỉ là cải tiến việc hiểu định nghĩ cấu trúc dữ liệu trong chương trình Mặc dù vậy, nếu có vấn đề về giá trị dữ liệu như thảo luận trong phần trước, giai đoạn 2 của tiến trình sau đó có thể được thực hiện

Nếu một tổ chức quyết định tiếp tục giai đoạn 2 của tiến trình, sau đó nó tiếp tục đến giai đoạn 3, chuyển đổi dữ liệu Tiến trình này thường là rất đắt Chương trình cần được viết với sự kết hợp sự hiểu biết giữa tổ chức cũ và mới Đó là sửa đổ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

Chương 2 CÁC CÔNG CỤ TRỢ GIÚP TÁI KỸ NGHỆ

2.1 Giới thiệu công cụ Rational Software Architecture

Công cụ phát triển phần mềm IBM Rational, dựa trên cơ sở mã nguồn mở của Eclipse Rational Software Architecture (RSA) là phần mềm công cụ hỗ trợ mạnh cho xây dựng kiến trúc phần mềm, cho phân tích, thiết kế hệ thống phần mềm và cho xây dựng các ứng dụng phần mềm theo hướng đối tượng Nó giúp mô hình hoá hệ thống đồng thời sinh mã nguồn chương 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 RSA 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 RSA 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, quy trình phát trển phần mềm RUP

Nó cho phép phát sinh mã trình từ mô hình của UML sang một ngôn ngữ và dịch ngược từ một ngôn ngữ sang mô hình UML Rose Eterprise cho phép phát sinh mã trình sang các ngôn ngữ Ada83, Ada95, ANSI C++, CORBA, Java, COM, Visual Basic, Visual C++, C/C++, Oracle, DB2, SQL Server, XML và dịch ngược từ mã nguồn của các hệ trên sang mô hình của UML Hơn nữa Rational Software Architecture cho phép mô hình hoá các ứng dụng trên website và tái thiết kế các ứng dụng trên nó [6,11, 13, 14]

Rational Software Architecture hỗ trợ tiến trình tái kỹ nghệ và tiến trình thiết kế tái kỹ nghệ cả với một số ngôn ngữ lập trình trên mạng như ASP, JSP, J2EE và các trang HTML Nó gán các stereotype thích hợp cho các lớp và tạo các mối quan hệ giữa chúng [10,11,12] Rational Software Architecture còn cho phép tái kỹ nghệ dữ liệu với: IBM DB2, Microsoft SQL Sever, Oracle và Sysbase Adaptive Sever 12.x [10,21] Đặc điểm chức năng của Rational Software Architecture là: mô hình hóa tiến trình nghiệp vụ hệ thống, phân tích và thiết kế hệ thống, kiến trúc hệ thống, lập trình

và kiểm thử hệ thống

Với công cụ phát trển phần mềm Rational Software Architecture Platform, chúng ta có thể sử dụng để mô hình hóa hệ thống phần mềm và tạo ra các loại biểu đồ trong UML như:

 Biểu đồ Ca sử dụng – Use Case

 Biểu đồ Lớp-Class

 Biểu đồ Tuần tự - Sequence

 Biểu đồ Truyền thông – Communication

 Biểu đồ Máy trạng thái – State Machine

 Biểu đồ Hoạt động - Activity

 Biểu đồ Thành phần – Component

 Biểu đồ Cấu trúc tổng hợp – Composite Structure

 Biểu đồ Triển khai - Deployment

Hình 2-1 Biểu đồ Ca sử dụng – Use Case

Hình 2-2 Biểu đồ Lớp-Class

Hình 2-3 Biểu đồ tuần tự - Sequence

Hình 2-4 Biểu đồ truyền thông – Communication

Hình 2-5 Biểu đồ máy trạng thái – State Machine

Hình 2-6 Biểu đồ hoạt động - Activity

Hình 2-7 Biểu đồ thành phần - Component

Hình 2-8 Biểu đồ cấu trúc tổng hợp – Composite Structure

Hình 2-9 Biểu đồ triển khai - Deployment

Rational Software Architecture có một số đặc điểm hỗ trợ mô hình người dùng như là: Thanh hoạt động, các điều khiển bộ kết nối mà người dùng có thể soạn mô hình UML trực tiếp Khi gõ phím tất cả các tên và thuộc tính có liên quan đều được liệt kê

Hình 2-10 Hỗ trợ trong việc soạn mô hình

Cửa sổ khung nhìn điều khiển cho phép thấy toàn cảnh của mô hình và dễ kiểm soát Người dùng có thể sử dụng các mẫu để chuyển đổi giữa các mô hình về phân tích

và thiết kế Để áp dụng một mẫu thiết kế vào mô hình, ta chọn mẫu rồi kéo vào vùng thiết kế sau đó sửa trực tiếp theo từng yêu cầu đặt ra

Hình 2-11 Cửa sổ khung nhìn điều khiển

Rational Software Architecture cho phép chuyển đổi giữa các mô hình, chuyển đổi mô hình sang mã nguồn Để chuyển đổi biểu đồ bấm chuột phải vào mô hình thành

phần rồi chọn Transform, có thể chuyển đổi từng thành phần hay toàn bộ mô hình Từ

đó chúng ta có thể sửa đổi mẫu và các phép chuyển đổi

Hình 2-12 Chuyển đổi mô hình

Hình 2-13- Khung nhìn khai thác các tài nguyên

Khung nhìn khai thác các tài nguyên để lưu trữ và quản lý các mẫu có khả năng dùng lại Cho phép tìm các quan hệ trong mô hình, và các quan hệ phát sinh, dễ dàng tạo các báo cáo của các mô hình

Hình 2-14 Tìm kiếm và sinh mô hình

Ta có thể sửa đổi chọn quá trình lập trình và đưa các quy tắc của mẫu vào lớp

Do đó, có thể tạo các quy ước của việc phát triển bằng việc dùng mẫu được định trước

để điều hướng các nhà phát triển lập trình theo ý định thiết kế

Nó cho phép tạo ra các báo cáo về các yêu cầu trong mô hình dẫn tới việc cài đặt

Nó cho phép phân tích các mô hình và xem lại mã nguồn Khai thác mã nguồn động để khám phá mẫu cấu trúc

Hình 2-15 Tạo báo cáo các yêu cầu thực hiện

Hình 2-16 Phân tích mô hình và xem lại mã

Hình 2-17 Tìm mẫu phù hợp

Ngoài ra Rational Software Architecture cung cấp một môi trường phát triển ứng dụng mạnh như C++ và J2EE Các công cụ về phục vụ Web servicese rất mạnh như Java Beam, DADX, EJBs, URLs Phát triển các chức năng Web site gồm Java Verver Faces, và các công cụ thiết kế Web site Các công cụ phát trển trên JavaBean