Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên
Tài liệu đính kèm:
- bai_giang_phat_trien_van_hanh_bao_tri_phan_mem_chuong_4_cac.ppt
Nội dung text: Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 4: Các tác vụ yêu cầu bảo trì - Nguyễn Thị Thanh Trúc
- TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN KHOA CÔNG NGHỆ PHẦN MỀM PHÁT TRIỂN VẬN HÀNH BẢO TRÌ PHẦN MỀM ThS. NGUYỄN THỊ THANH TRÚC UIT-VNUHCM 2009 1
- Nội dung (Chương 4) HIỂU CHƯƠNG TRÌNH NGƯỜI BẢO TRÌ VÀ CÁC NHU CẦU THÔNG TIN MÔ HÌNH QUI TRÌNH NẮM BẮT THÔNG TIN REVERSE ENGINEERING Thảo luận và làm bài tập UIT-VNUHCM 2009 Company Logo 2
- Chương 4: CÁC TÁC VỤ YÊU CẦU BẢO TRÌ 4.1 HIỂU CHƯƠNG TRÌNH 4.2 NGƯỜI BẢO TRÌ VÀ CÁC NHU CẦU THÔNG TIN 4.3 MÔ HÌNH QUI TRÌNH NẮM BẮT THÔNG TIN 4.4 REVERSE ENGINEERING UIT-VNUHCM 2009 3
- Chương 3: CÁC TÁC VỤ YÊU CẦU BẢO TRÌ 1. HIỂU CHƯƠNG TRÌNH o Mục tiêu của nắm bắt chương trình ü Phạm vi vấn đề ü Hiệu quả thực thi ü Mối liên hệ Nhân – Quả (Cause-Effect) ü Mối liên hệ sản phẩm – Môi trường ü Đặc trưng Quyết định – Hỗ trợ 2. NGƯỜI BẢO TRÌ VÀ CÁC NHU CẦU THÔNG TIN o Managers o Analysts o Designers o Programmers 3. MÔ HÌNH QUI TRÌNH NẮM BẮT THÔNG TIN o Chiến lược nắm bắt chương trình ü Top-Down Model Ill ü Bottom-Up / Chunking Model ü Opportunistic Model 4. REVERSE ENGINEERING o Định nghĩa o Mục đích và mục tiêu của reverse engineering o Các mức của reverse engineering o Kỹ thuật hỗ trợ o Các lợi điểm UIT-VNUHCM 2009 4
- 4.1 HIỂU CHƯƠNG TRÌNH qMục tiêu của nắm bắt chương trình o Phạm vi vấn đề o Hiệu quả thực thi o Mối liên hệ Nhân – Quả (Cause-Effect) o Mối liên hệ sản phẩm – Môi trường o Đặc trưng Quyết định – Hỗ trợ UIT-VNUHCM 2009 5
- Phạm vi vấn đề q Nắm bắt được kiến thức phạm vi khá quan trọng. Vì sự tăng nhanh của máy tính tác động đến vấn đề vùng phạm vi chuyên biệt, cụ thể. Vd: môi trường điều trị bệnh nhân q Trong hệ thống lớn ví dụ chăm sóc sức khoẻ, viễn thông, tài chính được phân nhỏ thành vấn đề nhỏ, thành phần nhỏ hơn, được quản lý thành đơn vị chương trình như mô đun, thủ tục, hàm. Ví dụ Trình biên dịch bao gồm thành phần parser, phân tích, phát sinh code, mỗi thành phần được phân rà thành phần nhỏ hơn . q Tác động đến sự thay đổi hay đơn giản hơn là ước tính nguồn tài nguyên đòi hỏi cho tác vụ bảo trì, kiến thức phạm vi vấn đề nói chung và vấn đề nhỏ cụ thể là cần thiết tác động trực tiếp nhân sự bảo trị trong việc chọn lựa thuật toán phù hợp, phương pháp luận, và công cụ. q Việc chọn lựa nhân sự với mức độ chuyên gia và kỹ năng phù hợp là khía cạnh khác. Thông tin bao gồm từ nguồn khác nhau – tài liệu hệ thống, end-users, và chương trình nguồn UIT-VNUHCM 2009 6
- Hiệu quả thực thi q Ở mức cao trừu tượng, nhân sự bảo trì cần phải nắm (dự đoán) kết quả chương trình sẽ được phát sinh kết quả gì từ đầu vào được cho mà không cần biết đơn vị chương trình được xây dựng để có kết quả tổng thể và kết quả được cho như thế nào. q Ở mức thấp, họ cần biết kết quả mỗi đơn vị chương trình sẽ được tạo và thực thi. q Kiến thức data flow, control flow, và thuật toán có thể thuận tiện hoàn thành thực thi mục tiêu này. q Ví dụ người lập trình muốn biết ở mức trù tượng, đầu ra của qui trình hoàn tất biên dịch và ở mức thấp, đầu ra từ parser. Trong khi, thông tin này sẽ giúp cho người bảo trì xác định những thay đổi đã thực thi có đạt hiệu quả như mong đợi hay không UIT-VNUHCM 2009 7
- Mối liên hệ Cause-Effect Trong chương trình lớn và phức tạp,kiến thức của mối liên hệ này là quan trọng: qCho phép nhân sự bảo trì đưa ra lý do làm thế nào thành phần của sản phẩm phần mềm tương tác trong khi thực thi. qCho phép người lập trình dự đoán phạm vi một thay đổi và bất kỳ hệ quả phát sinh từ thay đổi. qMối liên hệ cause-effect có thể được sử dụng để lưu vết luồng thông tin qua chương trình. Tại điểm mà nơi có những sự gián đoạn bất thường của luồng thông tin này mang dấu hiệu nguồn phát sinh bug chương trình UIT-VNUHCM 2009 8
- Ví dụ: A string reversing program MODULE StringReversing: FROM InOut IMPORT WriteString, Write, Read, EOL,WriteLn; FROM StacksLibrary IMPORT StackType, Create, IsEmpty, Pop, Push; VAR Stack: StackType; Char, Response: CHAR; BEGIN REPEAT Create (Stack); WriteString ("Enter string to be reversed"); WriteLn; UIT-VNUHCM 2009 9
- Ví dụ: A string reversing program (tt) Read (Char); < Segment A WHILE Char # EOL DO 4 Push (Stack, Char); Read (Char); END (* While *) WriteLn; WriteString ("Reversed string is: "); WHILE NOT IsEmpty (Stack) DO < Segment B Pop (Stack, Char); 4 Write (Char); END (* While *) WriteLn; WriteString ("Process another string (Y or N)? "); Read (Response); UNTIL CAP (Response) # 'Y' END StringReversing. UIT-VNUHCM 2009 10
- Mối liên hệ sản phẩm và môi trường qSản phẩm là hệ thống phần mềm. Môi trường là toàn bộ tất cả điều kiện và ảnh hưởng mà hành động từ bên ngoài sản phẩm. Ví dụ: qui định nghiệp vụ, qui định chính phủ, mẫu công việc, platform điều hành của phần mềm và phần cứng qNó cần thiết cho nhân sự bảo trì để biết không chỉ mở rộng mối liên hệ. qKiến thức này dùng để dự đoán những thay đổi trong những thành phần này sẽ tác động như thế nào với sản phẩm nói chung và dưới chương trình cụ thể nói riêng UIT-VNUHCM 2009 11
- Đặc trưng Quyết định – Hỗ trợ q Thuộc tính của sản phẩm phần mềm như độ phức tạp và khả năng dễ bảo trì là ví dụ hướng dẫn nhân sự bảo trì trong kỹ thuật và qui trình ra quyết định như phân tích, ra quyết định ngân sách, và cấp phát nhân lực. q Đo độ phức tạp của hệ thống xác định thành phần hệ thống đòi hỏi nhiều tài nguyên cho kiểm thử q Reverse engineering được dùng để nghiên cứu hiểu để trích chọn các loại thông tin. q Có nhiều yếu tố tác động mở rộng mà nhân sự bảo trì có thể yêu cầu danh mục kiến thức đã nêu về hệ thống. Bao gồm chiến lược nắm bắt thông tin, sự thông thạo phạm vi, chất lượng sưu liệu, báo cáo thuyết trình và tổ chức, thực nghiệm chương trình, và vấn đề thực thi, công cụ hỗ trợ UIT-VNUHCM 2009 12
- Một tiếp cận phân tích chương trình mới dựa trên trên thông tin bổ trợ qTheo kinh nghiệm phát triển,với các hệ thống lớn được sự hỗ trợ bởi luồng hệ thống, sơ đồ cấu trúc mô đun, luồng dữ liệu và tham chiếu, ngoài công cụ tự động còn cần bởi bảo trì bằng tay và kỹ năng của người bảo trì: o Nắm bắt thủ tục, biến toàn cục, mối liên hệ lỗi và mở rộng chức năng cục bộ, môđun o Độ phức tạp của chương trình o Ngữ nghĩa các vòng lặp, mối liên hệ input/output o Vấn đề gì là quan trọng khi phân tích chương trình o What-How-Why cho một đối tượng (object) của chương trình cho việc hiểu chương trình UIT-VNUHCM 2009 13
- (WHAT) Đối tượng trong chương trình là gì? qTrước khi cố gắng phân tích được chương trình theo tiếp cận W-H-W (What, How, Why), chúng ta nên suy nghĩa các đối tượng (object): o Lớp dữ liệu, cấu trúc, bảng, cờ, chuỗi và các biến thể hiện kiến thức phạm vi o Tên của các chức năng hay chu trình (routines) hay qui trình cho chúng ta gắn kết với chức năng của chúng o Thành phần liên quan được cung cấp bởi thư viện và môi trường chương trình qRõ ràng WHW(What,How,Why) sẽ giúp người bảo trì phần mềm hiểu một cách hiệu quả. Hiển nhiên mô tả hình thức là khó trong khi công cụ tự động là không thể. Hiểu chương trình sẽ thực hiện tiếp diễn cùng với kiến thức phạm vi tốt của người bảo trì UIT-VNUHCM 2009 14
- Ví dụ 1 static void print_url(String spec) { try { System.out.println(spec); URL url = new URL(spec); String proto = url.getProtocol(); String host = url.getHost(); String file = url.getFile(); String ref = url.getRef(); System.out.println(‘ ‘, proto=’ ’+proto+’ ’,host=’ ’+host+’ ’, file=’ ’+file+’ ’,ref=’ ’+ref); } catch (Exception e) { System.out.println(e); } } UIT-VNUHCM 2009 15
- Ví dụ 1 For example, this following is a php program array01.php3 . /* Create an associate array based on data of file */ $fname = "report" ; $MAXLN = 256 ; /* Check file */ if (file_exists($fname)) { $fd = fopen($fname,"r"); } else { print "Cann’t open file $fname"; return; } $i = 0; $assAry = ""; while ($buf=fgets($fd,$MAXLN)) { $element = explode("\t",$buf); $esize = count($element); $valstr[] = "" ; $j = 0 ; while ($j $vall[0] "; } UIT-VNUHCM 2009 16
- UIT-VNUHCM 2009 17
- UIT-VNUHCM 2009 18
- Các bước thực hiện: Thuật toán chung(GA) qGA1. Liệt kê tất cả các đối tượng với mức khác nhau qGA2. Sắp xếp đối tượng quan trọng dựa trên tài liệu khác nhau và kiến thức của người bảo trì . Câu Trả lời: đối tượng là gì (WHAT) qGA3. Nếu đối tượng được chọn làm bùng nổ đối tượng khác thì được bỏ vào danh sách. Câu trả lời: mối liên hệ Chuồng bồ câu của các đối tượng được chọn qGA4. Nếu có mối liên hệ từ và đến đối tượng khác, tạo mối liên hệ đến đối tượng mới sau đó lặp lại từ GA1 UIT-VNUHCM 2009 19
- Kết luận tiếp cận 1. Hiểu chương trình là một qui trình khó liên quan đến lập trình viên và người bảo trì, có kiến thức chương trình từ góc nhìn khác nhau 2. Công cụ nên được cung cấp nhiều có thể để hỗ trợ khám phá thông tin cho việc hiểu chương trình. Tư động hoá thì thích hợp hơn nhưng tự động hoàn toàn thì hiển nhiên không khả thi 3. Phương pháp phân tích chương trình sẽ đạt được đối với chương trình và kiểu ứng dụng 4. Restructuring hay refactoring chương trình có thể là tác vụ quan trọng trong qui trình bảo trì Bài tập: Tìm hiểu các kỹ thuật refactoring UIT-VNUHCM 2009 20
- 4.2 NGƯỜI BẢO TRÌ VÀ CÁC NHU CẦU THÔNG TIN q Managers q Analysts q Designers q Programmers UIT-VNUHCM 2009 21
- Managers qTrách nhiệm quản lý là thực hiện ra quyết định qMức độ hiểu biết đòi hỏi sẽ phụ thuộc vào quyết định thực thi qƯớc tính chi phí, thời gian cải thiện chính, kiến thức của độ lớn chương trình (thuật ngữ line of code, điểm chức năng (function point)) qƯớc tính này để xác định xem có kinh tế để thay thế hệ thống cho khách hàng qKhông cần biết kiến trúc thiết kế của hệ thống hay thực thi chương trình ở mức thấp chi tiết để thực thi nhiệm vụ công việc của người quản lý q"Nobody can seriously have believed that executives could read programs“ Weinberg UIT-VNUHCM 2009 22
- Analysts q Hiểu phạm vi vấn đề (vd tài chính hay health care) để chịu trách nhiệm xác định yêu cầu chức năng và phi chức năng, và thiết lập mối liên hệ giữa hệ thống và thành phần môi trường. q Trong suốt bảo trì, xem xét môi trường thay đổi thế nào (ví qui định, hệ thống điều hành mới). q Như vậy, trước khi thực hiện thay đổi, người phân tích cần có cái nhìn tổng thể hệ thống, đó là bức tranh tổng thể tương tác giữa các đơn vị chức năng chính. q Người Phân tích cũng đòi xác định mối gắn kết thay đổi trên hiệu năng của hệ thống q Giống nhà quản lý, không cần cái nhìn cục bộ - bức tranh cục bộ những phần của hệ thống và chúng thực thi như thế nào. q Sử dụng mô hình vật lý như sơ đồ ngữ cảnh để triển khai và thể hiện thành phần chính và chúng liên hệ với môi trường, như vậy giúp nhà phân tích thu được hiểu biết tốt hệ thống mà không cần lãng phí xem chi tiết thiết kế mức thấp và code. UIT-VNUHCM 2009 23
- Designers q Thiết kế kiến trúc (Architectural design) kết quả trong sản phẩm thành phần chức năng, cấu trúc dữ liệu mức khái niệm và tương tác giữa các thành phần khác nhau q Thiết kế chi tiết (Detailed design) kết quả trong thuật toán chi tiết, thể hiện dữ liệu, cấu trúc dữ liệu, giao diện giữa các thủ tục và chu trình. q Khi bảo trì, người thiết kế: o trích rút thông tin và xác định cải tiến có thể được cung cấp bởi kiến trúc, cấu trúc dữ liệu, luồng dữ liệu và luồng kiểm soát của hệ thống hiện tại, o thông qua chương trình nguồn để lấy ý tưởng độ lớn công việc, vùng phạm vi của hệ thống bị tác động, và kiến thức và kỹ năng đòi hỏi bởi nhóm lập trình q Dùng khái niệm che dấu thông tin, mô đun, phân rà chương trình, dữ liệu trừu tượng, hướng đối tượng, lý thuyết thiết kế tốt, sơ đồ luồng dữ liệu, sơ đồ luồng kiểm soát, sơ đồ cấu trúc, qui trình phân cấp đầu vào/đầu ra có thể giúp người thiết kế thu được hiểu biết tốt về hệ thống trước khi thiết kế thay đổi UIT-VNUHCM 2009 24
- Programmers 1. Quyết định restructure hay rewrite phân đoạn chương trình cụ thể hay không 2. Dự đoán dễ dàng bất kỳ tác động khi thực hiện thay đổi tác động những phần khác của hệ thống 3. Đưa ra những giả thiết vị trí và nguyên nhân gây ra lỗi 4. Xác định tính khả thi của những thay đổi đề xuất và cho thông báo cấp quản lý bất kỳ những vấn đề thấy trước. UIT-VNUHCM 2009 25
- Thảo luận qExercise 6.1 Mục tiêu đạt được của bạn là gì khi cố găng hiểu chương trình qExercise 6.2 Tại sao hiểu chương trình là quan trọng? qExercise 6.3 Giả sử bạn là lập trình viên, bạn được yêu cầu như sau (i) cung cấp tiện ích quản lý thông điệp cho hệ thống vận hành quản lý thông tin (MIS), và (ii) tích hợp hệ thống MIS vào gói văn phòng tự động. Những thông tin về MIS bạn cần làm gì, có tác động đến thay đổi không? Chỉ ra lý do. UIT-VNUHCM 2009 26
- 4.3 MÔ HÌNH QUI TRÌNH NẮM BẮT THÔNG TIN qChiến lược nắm bắt chương trình oTop-Down Model (Brook’s model) oBottom-Up / Chunking Model oOpportunistic Model qBài tập: đọc tìm hiểu các mô hình trên trong tài liệu ebook chính UIT-VNUHCM 2009 27
- Mô hình qui trình nắm bắt thông tin Hình 6.2 UIT-VNUHCM 2009 28
- Các bước nắm bắt thông tin chương trình qNgười lập trình có cách để suy nghĩ, giải quyết vấn đề, chọn lựa kỹ thuật và công cụ. Tuy nhiên có ba bước cơ bản để hiểu chương trình: o Bước 1: Đọc chương trình o Bước 2: Đọc chương trình nguồn (source code) o Bước 3:Chạy chương trình (Run) qThảo luận exercise 6.4: Mô hình qui trình nắm bắt thông tin Hình 6.2 (như 3 bước trên) có khác biệt và tương tư với những cách mà bạn đã sử dụng. Nêu rõ lý do? UIT-VNUHCM 2009 29
- Phạm vi kiến thức trong nắm bắt thông tin UIT-VNUHCM 2009 30
- Các hướng dẫn cho chương trình q Internal to the program text 1. Prologue comments, including data and variable dictionaries 2. Variable, structure, procedure and label names 3. Declarations or data divisions 4. Interline comments 5. Indentation or pretty-printing 6. Subroutine or module structure 7. I/O formats, headers, and device or channel assignments q External to the program 1. Users' manuals 2. Program logic manuals 3. Flowcharts 4. Cross-reference listings 5. Published descriptions of algorithms or techniques UIT-VNUHCM 2009 31
- Bottom-up UIT-VNUHCM 2009 32
- Điểm yếu của top-down và bottoom-up qNhững điểm yếu chính của cả chiến lược nắm bắt thông tin bằng top-down and bottom-up: o Thiếu xem xét chú ý đến đóng góp những yếu tố như công cụ hỗ trợ sẵn để hiểu chương trình; o Những sự kiện mà qui trình hiểu chương trình hiếm khi tham dự như vai trò các mô hình được định nghĩa tốt. Trái lại người lập trình hướng đến bất kỳ mối liên gắn kết có trước mà được xảy ra như cách tình cờ cơ hội. UIT-VNUHCM 2009 33
- Kỹ thuật đọc hiểu qExercise 6.5: Liệt kê những loại khác nhau của chiến lược hiểu chương trình, phân biệt giữa chúng qExercise 6.6: Những chiến lược gì bạn đã dùng và trong những hoàn cảnh nào? UIT-VNUHCM 2009 34
- Các yếu tố tác động đến đọc hiểu qPhạm vi kiến thức: Chuyên gia, Vấn đề, Ứng dụng, hệ thống qThực nghiệm chương trình, vấn đề thực thi: Độ phân rã, tính môđun, tính che dấu thông tin, Thuật toán, Chương trình, cách đặt tên, ghi chú qTài liệu: bên ngoài, bên trong tổ chức qTổ chức/ thuyết trình: qCông cụ hỗ trợ nắm bắt thông tin: công cụ phân tích tĩnh/ động UIT-VNUHCM 2009 35
- Chuyên gia q“Experts differ from novices in both their breadth and their organisation of knowledge: experts store information in larger chunks organised in terms of underlying abstractions. This organisation apparently facilitates quick recognition of problem types and recall of associated solution strategies.“ Petre qNgười lập trình càng có kinh nghiệm phạm vi ứng dụng với ngôn ngữ lập trình, càng dễ và nhanh chóng hiểu chương trình và cũng như toàn bộ hệ thống hiệu quả UIT-VNUHCM 2009 36
- Vấn đề thực thi qKiểu/ cách thức đặt tên qGhi chú chương trình qCơ chế phân rã o Phân rã mô đun o Lập trình có cấu trúc q Đề xuất document standard và coding standard, phong cách lập trình => viết bằng văn bản thực thi cho nhóm dự án (Bài tập) UIT-VNUHCM 2009 37
- Tài liệu qTài liệu hệ thống rất hữu ích và quan trọng bởi nó không chỉ đầu mối liên lạc tác giả gốc của hệ thống thông tin. qĐó là phần báo cáo trang trọng trong công nghiệp phần mềm: từ dự án khác, phòng ban, và công ty khác. Như vậy, khi người bảo trì cần truy xuất vào hệ thống tài liệu để có thể hiểu chức năng, thiết kế, thực thi vàvấn đế liên quan đến bảo trì thành công. qĐôi khi, tài liệu hệ thống không chính xác, quá lỗi thời chưa cập nhật. Trong trường hợp như vậy, người bảo trì phải thường xuyên xem sưu liệu nội bộ với chính chương trình nguồn – ghi chú chương trình. UIT-VNUHCM 2009 38
- Tổ chức/ thuyết minh chương trình qThuyết minh chương được cải tiến có thể cải thiện khả năng hiểu chương trình: qThuận tiện biểu thức rõ ràng và chính xác mô hình chương trình và truyền thông của các mô hình này đối với người đọc chương trình qNhấn mạnh đến luồng kiểm soát, cấu trúc phân cấp chương trình và tính logic và tổng hợp của người lập trình – mục đích gạch dưới cấu trúc và cải thiện tính dễ nhìn của chương trình nguồn qua cách sử dụng ngắt dòng, khoảng trắng, khối và tô bóng UIT-VNUHCM 2009 39
- Công cụ hỗ trợ nắm bắt thông tin qCó công cụ được sử dụng để tổ chức và thể hiện chương trình nguồn theo cách thực hiện càng rõ ràng càng dễ đọc và như vậy càng dễ hiểu. q'Book Paradigm' là pretty-printer, static analyser và browser. qNhiều công cụ đọc hiểu được thiết kế phục vụ trợ giúp cho người đọc hiểu, tăng tốc độ, qui trình hiểu. Tuy nhiên, đầu ra của công cụ này không cung cấp sự giải thích chức năng của mỗi thành phần. Ở đây mô tả Book Paradigm và một số đặc chưng của nó UIT-VNUHCM 2009 40
- Ví dụ UIT-VNUHCM 2009 41
- Ví dụ Hình 6.10 FROM BasicIO IMPORT WriteReal, WriteString, WriteLn, Readlnt, Writelnt; CONST max = 20; VAR a : ARRAY [L.max] OF INTEGER; number: INTEGER; total: INTEGER; BEGIN WriteString("Type in 20 numbers"); number := 0; WHILE number 0 DO total := total + a[number]; DEC (number); END; WriteString ("The average for the 20 numbers is "); WriteReal (FLOAT (total) / FLOAT (max), 12); END AddNumbers UIT-VNUHCM 2009 42
- Bài tập thảo luận qExercise 6.7 Liệt kê và giải thích các yêu tố chính tác động đến việc hiểu một chương trình qExercise 6.8 Bạn có thể cải thiện khả năng đọc hiểu chương trình Hình 6.10 bằng những cách xử lý nào? qExercise 6.9 Liệt kê tất cả công cụ bảo trì đã có trong hệ thống của bạn. Có gắng thử 3 trong những công cụ này, với mỗi loại chức năng chính của chúng là gì và làm thể nào nó cải thiện khả năng đọc. qExercise 6.10 Tại sao quan trọng đối với người bảo trì thu được hiểu biết tốt chiến lược nắm bắt chương trình khác nhau và vấn đề dựa trên kinh nghiệm UIT-VNUHCM 2009 43
- 4.4 REVERSE ENGINEERING qĐịnh nghĩa qMục đích và mục tiêu của reverse engineering qCác mức của reverse engineering qKỹ thuật hỗ trợ qCác lợi ích UIT-VNUHCM 2009 44
- Định nghĩa qAbstraction –là mô hình tóm tắt chi tiết chủ đề được tái thể hiện qForward engineering – tiếp cận công nghệ phần mềm truyền thống bắt đầu với phân tích yêu cầu và tiến hành thực thi hệ thống. qReengineering – Qui trình kiểm tra và thông báo nơi hệ thống thay đổi lần đầu bởi reverse engineering và sau đó forward engineering. qRestructuring – chuyển đổi một hệ thống từ hình thức này sang hình thức khác. qReverse engineering – Qui trình phân tích một hệ thống: nhận diện thành phần hệ thống và mối liên hệ bên trong và tạo thể hiện hệ thống trong hình thức khác ở mức trừu tượng cao hơn. UIT-VNUHCM 2009 45
- Tính trừu tượng qTrừu tượng chức năng qTrừu tượng dữ liệu qTrừu tượng qui trình UIT-VNUHCM 2009 46
- Mục đích và mục tiêu của reverse engineering qKhôi phục thông tin mất mát : qTo facilitate migration between platforms: qCải thiện và cung cấp sưu liệu : qTo provide alternative views: qTrích rút thành phần có thể dùng lại : qĐối phó với độ phức tạp : qDò hiệu ứng phụ: qGiảm nỗ lực bảo trì : UIT-VNUHCM 2009 47
- Tóm tắt mục tiêu và lợi ích UIT-VNUHCM 2009 48
- Các mức của reverse engineering UIT-VNUHCM 2009 49
- Các mức của reverse engineering qRedocumentation qKhôi phục thiết kế qKhôi phục đặc tả qNhững điều kiện cho Reverse Engineering UIT-VNUHCM 2009 50
- Kỹ thuật hỗ trợ qForward Engineering qRestructuring o Control-flow-driven restructuring: o Efficiency-driven restructuring: o Adaption-driven restructuring: qReengineering UIT-VNUHCM 2009 51
- Các lợi ích qBảo trì o Corrective Change o Adaptive Change/Perfective change o Preventive Change qTính sử dụng lại phần mềm qReverse Engineering và kỹ thuật kết hợp trong thực nghiệm UIT-VNUHCM 2009 52
- Case study 7.8 qĐọc hiểu case study 7.8 qPhân tích vấn đề hiện trạng đã nêu: o Vấn đề tự động hóa : o Vấn đề đặt tên : o ??? qThực hiện bài tập theo sau: UIT-VNUHCM 2009 53
- Bài tập (1) qExercise 7.1 Giải thích khác nhau giữa những loại khác nhau kỹ thuật reverse engineering và cho ví dụ thích hợp. qExercise 7.2 Thực hiện khôi phục đặc tả và thiết kế trên tất cả hay các phần của hệ thống phần mềm mà bạn không quen (hệ thống nên có ít nhất 2K dòng code độ lớn). o Những kỹ thuật bạn dùng nhận diện đặc tả và thiết kế là gì và tại sao? o Những hình thức thể hiện bạn xem là phù hợp cho những tác vụ này là gì? Chỉ ra lý do. o Bài học kinh nghiệm mà bạn đã học được trong các công việc này là gì? UIT-VNUHCM 2009 54
- Bài tập (2) qExercise 7.3 Một ngân hàng có substantial investment trong hệ thống phần mềm viết bằng Cobol ít nhất 1 triệu dòng code và chạy trên 20 năm. Nó được dùng cơ bản mỗi ngày để thực thi thao tác khác nhau như quản lý tài khoản khách hàng và loans. Sau vài năm cập nhật, cả dự định và không hoạch định – hệ thống trở nên quá đắt tiền để bảo trì. Kết quả là, ngân hàng muốn vài lời khuyên ở các bước tiếp để làm. Giả sử bạn được thuê làm việc như nhân viên tư vấn bảo trì. Bạn sẽ cho Ngân hàng lời khuyên gì? Chỉ ra lý do cho bất kỳ đề nghị mà bạn đã thực hiện UIT-VNUHCM 2009 55
- Yêu cầu thực hiện tuần tiếp theo qViết lại các báo cáo cho các thảo luận trên lớp và các bài tập qTiếp tục chuẩn bị công việc cho nhóm qMỗi nhóm tự chuẩn bị tìm hiểu và thử nghiệm một trong các công cụ hỗ trợ qui trình bảo trì hướng dẫn sử dụng và demo trước lớp UIT-VNUHCM 2009 56