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
Phạm vi vấn đề
Nắm bắt được kiến thức phạm vi khá quan trọng. Tác động đến
vấn đề vùng phạm vi chuyên biệt, cụ thể.
o Vd: môi trường điều trị bệnh nhân
Trong hệ thống lớn
o 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.
o 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 .
Tác động đến sự thay đổi, ướ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ụ.
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
Hiệu quả thực thi
Ở 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.
Ở 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.
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.
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
Trang 1
Trang 2
Trang 3
Trang 4
Trang 5
Trang 6
Trang 7
Trang 8
Trang 9
Trang 10
Tải về để xem bản đầy đủ
Tóm tắt nội dung 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
thể hệ thống, bức tranh tổng thể tương tác giữa các đơn vị chức năng chính. Xác định mối gắn kết thay đổi trên hiệu năng của hệ thống 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. 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. 24 UIT-VNUHCM 2009 Designers 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 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. 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 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 25 UIT-VNUHCM 2009 Programmers & thông tin giúp cho họ 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. 26 UIT-VNUHCM 2009 Ví dụ programmer cần biết: Chức năng của thành phần đơn lẻ của hệ thống và mối tương quan. Mỗi khối lệnh làm gì, kết quả thực hiện (control flow), Tác động qua lại trên đối tượng dữ liệu (data flow) và mục đích tập các câu lệnh (functions) 27 UIT-VNUHCM 2009 Thảo luận Exercise 6.1 Mục tiêu đạt được của bạn là gì khi cố găng hiểu chương trình Exercise 6.2 Tại sao hiểu chương trình là quan trọng? Exercise 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. 28 UIT-VNUHCM 2009 4.3 MÔ HÌNH QUI TRÌNH NẮM BẮT THÔNG TIN Mô hình qui trình nắm bắt thông tin o reading about the program o reading its source code o running it Chiến lược nắm bắt chương trình oTop-Down Model (Brook’s model) oBottom-Up / Chunking Model oOpportunistic Model Bài tập: đọc tìm hiểu các mô hình trên trong tài liệu ebook chính 29 UIT-VNUHCM 2009 Mô hình qui trình nắm bắt thôn tin Read about the program o Sưu liệu hệ thống – tài liệu đặc tả và thiết kế o Sơ đồ cấu trúc và dữ liệu và control flow o Phát triển tổng quan và hiểu biết tổng thể hệ thống. o Giai đoạn này có thể bỏ qua nếu tài liệu hệ thống không chính xác, không cập nhật và không tồn tại. 30 UIT-VNUHCM 2009 Mô hình qui trình nắm bắt thông tin Read the source code o Cái nhìn toàn cục top-level understanding of the system xác định phạm vi bất kỳ tác động thay đổi có thể có ở phần khác của hệ thống o Xem xét mức cục bộ tập trung vào phần cụ thể của hệ thống. Thông tin về cấu trúc hệ thống, loại dữ liệu, mẫu thuật toán 31 UIT-VNUHCM 2009 Mô hình qui trình nắm bắt thông tin Run program o to study the dynamic behavior (Ex: trace data) o reveal some characteristics of the system which are difficult to obtain by just reading the source code. 32 UIT-VNUHCM 2009 Mô hình qui trình nắm bắt thông tin Hình 6.2 33 UIT-VNUHCM 2009 Các bước nắm bắt thông tin chương trình Ngườ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) Thả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? 34 UIT-VNUHCM 2009 Mental Models Our understanding of a phenomenon depends on our ability to form a mental representation which serves as a working model of the phenomenon to be understood The content and formation of mental models hinges on cognitive structures and cognitive processes. The mental model is formed after observation, inference or interaction with the target system. 35 UIT-VNUHCM 2009 Chiến lược nắm bắt chương trình 36 UIT-VNUHCM 2009 Phạm vi kiến thức trong nắm bắt thông tin 37 UIT-VNUHCM 2009 Các hướng dẫn cho chương trình 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 External to the program 1. Users' manuals 2. Program logic manuals 3. Flowcharts 4. Cross-reference listings 5. Published descriptions of algorithms or techniques 38 UIT-VNUHCM 2009 Bottom-up 39 UIT-VNUHCM 2009 Điểm yếu của top-down và bottoom-up Nhữ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. 40 UIT-VNUHCM 2009 Kỹ thuật đọc hiểu Exercise 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 Exercise 6.6: Những chiến lược gì bạn đã dùng và trong những hoàn cảnh nào? 41 UIT-VNUHCM 2009 Các yếu tố tác động đến đọc hiểu Phạm vi kiến thức: Chuyên gia, Vấn đề, Ứng dụng, hệ thống Thự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ú Tài liệu: bên ngoài, bên trong tổ chức Tổ chức/ thuyết trình: Công cụ hỗ trợ nắm bắt thông tin: công cụ phân tích tĩnh/ động 42 UIT-VNUHCM 2009 43 UIT-VNUHCM 2009 Chuyên gia “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 Ngườ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ả 44 UIT-VNUHCM 2009 Vấn đề thực thi Kiểu/ cách thức đặt tên Ghi chú chương trình Cơ chế phân rã o Phân rã mô đun o Lập trình có cấu trúc Đề 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) 45 UIT-VNUHCM 2009 Tài liệu Tà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. Đó 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. Đô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. 46 UIT-VNUHCM 2009 Tổ chức/ thuyết minh chương trình Thuyết minh chương được cải tiến có thể cải thiện khả năng hiểu chương trình: Thuậ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 Nhấ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 47 UIT-VNUHCM 2009 Công cụ hỗ trợ nắm bắt thông tin Có 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. 'Book Paradigm' là pretty-printer, static analyser và browser. Nhiề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ó 48 UIT-VNUHCM 2009 Ví dụ 49 UIT-VNUHCM 2009 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 20 DO number := number + 1; Readlnt (afnumber]); END; WriteString ("The 20 numbers in reverse are "); WriteLn; number := 20; REPEAT Writelnt (a[number]),max); WriteLn; number := number - 1 UNTIL number = 0; number := 20 total := 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 50 UIT-VNUHCM 2009 Bài tập thảo luận Exercise 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 Exercise 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? Exercise 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. Exercise 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 51 UIT-VNUHCM 2009 4.4 REVERSE ENGINEERING Định nghĩa Mục đích và mục tiêu của reverse engineering Các mức của reverse engineering Kỹ thuật hỗ trợ Các lợi ích 52 UIT-VNUHCM 2009 Định nghĩa Abstraction –là mô hình tóm tắt chi tiết chủ đề được tái thể hiện Forward 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. Reengineering – 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. Restructuring – chuyển đổi một hệ thống từ hình thức này sang hình thức khác. Reverse 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. 53 UIT-VNUHCM 2009 Tính trừu tượng Trừu tượng chức năng Trừu tượng dữ liệu Trừu tượng qui trình 54 UIT-VNUHCM 2009 Mục đích và mục tiêu của reverse engineering Khôi phục thông tin mất mát : To facilitate migration between platforms: Cải thiện và cung cấp sưu liệu : To provide alternative views: Trích rút thành phần có thể dùng lại : Đối phó với độ phức tạp : Dò hiệu ứng phụ: Giảm nỗ lực bảo trì : 55 UIT-VNUHCM 2009 Tóm tắt mục tiêu và lợi ích 56 UIT-VNUHCM 2009 Các mức của reverse engineering 57 UIT-VNUHCM 2009 Các mức của reverse engineering Redocumentation Khôi phục thiết kế Khôi phục đặc tả Những điều kiện cho Reverse Engineering 58 UIT-VNUHCM 2009 Kỹ thuật hỗ trợ Forward Engineering Restructuring o Control-flow-driven restructuring: o Efficiency-driven restructuring: o Adaption-driven restructuring: Reengineering 59 UIT-VNUHCM 2009 Bài tập 60 UIT-VNUHCM 2009 61 UIT-VNUHCM 2009 Các lợi ích Bảo trì o Corrective Change o Adaptive Change/Perfective change o Preventive Change Tính sử dụng lại phần mềm Reverse Engineering và kỹ thuật kết hợp trong thực nghiệm 62 UIT-VNUHCM 2009 Case study 7.8 Đọc hiểu case study 7.8 Phâ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 ??? Thực hiện bài tập theo sau: 63 UIT-VNUHCM 2009 Bài tập (1) Exercise 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. Exercise 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ì? 64 UIT-VNUHCM 2009 Bài tập (2) Exercise 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. o Giả sử bạn được thuê làm việc như nhân viên tư vấn bảo trì. o Bạn sẽ cho Ngân hàng lời khuyên gì? o Chỉ ra lý do cho bất kỳ đề nghị mà bạn đã thực hiện 65 UIT-VNUHCM 2009 Yêu cầu thực hiện tuần tiếp theo Viế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 Tiếp tục chuẩn bị công việc cho nhóm Mỗ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 Chủ động Đăng ký thuyết trình nhóm với lớp trưởng, để điều phối nhóm thuyết trình ở các buổi học tiếp theo. 66 UIT-VNUHCM 2009
File đính kèm:
- bai_giang_phat_trien_van_hanh_bao_tri_phan_mem_chuong_4_cac.pdf