Công nghệ phần mềm - Chương 2: Các kỹ thuật xây dựng phần mềm

1 
IT3124- ĐỒ ÁN TIN HỌC 
 (SOFTWARE PROJECT) 
LỚP KSCLC – K56, NĂM HỌC 2013-2014 
Giảng viên: PGS. TS.Huỳnh Quyết Thắng 
BM Công nghệ phần mềm 
Viện CNTT-TT, ĐHBK HN 
Chƣơng II - CÁC KỸ THUẬT XÂY DỰNG PHẦN MÊM 
2.1. Thiết kế chương trình 
2.2. Các kỹ thuật phân chia, thiết kế, xây dựng 
hàm/thủ tục 
2.3. Các kỹ thuật bẫy lỗi và lập trình phòng ngừa 
(defensive programming) 
QUÁ TRÌNH THIẾT KẾ CHƢƠNG TRÌNH 
1. Xác định các thành phần chương trình cần thiết 
 - Hàm/Functions, đối tượng/object 
lớp/classes, xử lý sự kiện/event handlers, 
etc. 
2. Xây dựng các giao diện 
- Sử dụng nguyên lý encapsulation và 
generalization 
QUÁ TRÌNH THIẾT KẾ CHƢƠNG TRÌNH 
3. Xây dựng các kịch bản thử nghiệm (đầu 
vào/đầu ra) 
4. Viết mã nguồn tất cả các thành phần 
phần mềm (hàm/lớp/gói). Kiểm thử và 
gỡ rối từng mô-đun 
5. Viết mô-đun chính của chương trình 
6. Kiểm thử và gỡ rối theo kịch bản 
5 
2.1. Thiết kế chương trình 
Các kỹ thuật thiết kế 
 Các cấp độ thiết kế 
 Level 1: Software System 
 Level 2: Division into Subsystems or Packages 
 Level 3: Division into Classes 
 Level 4: Division into Routines 
 Level 5: Internal Routine Design 
6 
3.1. Thiết kế chương trình 
Các kỹ thuật thiết kế/Design Practices 
1. Iterate 
2. Divide and Conquer 
3. Top-Down and Bottom-Up Design Approaches 
 Argument for Top Down 
 Argument for Bottom Up 
4. Experimental Prototyping 
5. Collaborative Design 
7 
2.1. Thiết kế chương trình 
Các quyết định quan trọng trong thiết kế: 
 Lựa chọn ngôn ngữ lập trình (Choice of 
Programming Language) 
 Các quy ước/quy định về lập trình 
(Programming Conventions) 
 Lựa chọn Technology Platform 
 Áp dụng các nguyên lý thiết kế và xây dựng 
chương trình (Selection of Major 
Construction Practices) 
8 
2.1. Thiết kế chương trình 
Một số điểm lưu ý: 
 Mỗi ngôn ngữ lập trình đều có điểm mạnh/yếu. Việc lựa chọn 
ngôn ngữ phùhợp là rất quan trọng 
 Cần đƣa ra các quy định/quy ƣớc về lập trình trƣớc khi bắt đầu 
lập trình 
 Cần áp dụng các nguyên lý thiết kế và xây dựng phù hợp trong 
từng dự án 
 Luôn đặt câu hỏi cho bản thân là các kỹ thuật lập trình tiêu 
biểu của từng công cụ là gì. Không phải kỹ thuật nào cũng áp 
dụng trong từng ngôn ngữ đƣợc. 
 Cần có lựa chọn công nghệ phù hợp với ứng dụng cần xây 
dựng. 
9 
Các câu hỏi thường xuyên (từ Code Complete) 
1. Coding (Developer) 
 Have you defined how much design will be done 
up front and how much will be done at the 
keyboard, while the code is being written? 
 Have you defined coding conventions for names, 
comments, and layout? 
 Have you defined specific coding practices that 
are implied by the architecture? 
 Have you identified your location on the 
technology wave and adjusted your approach to 
match? 
10 
2.1. Thiết kế chương trình 
2. Teamwork 
 Have you defined an integration procedure—that is, 
have you defined the specific steps a programmer 
must go through before checking code into the master 
sources? 
 Will programmers program in pairs, or individually, 
or some combination of the two? 
11 
2.1. Thiết kế chương trình 
3. Quality Assurance 
 Will programmers write test cases for their code 
before writing the code itself? 
 Will programmers write unit tests for their code 
regardless of whether they write them first or last? 
 Will programmers step through their code in the 
debugger before they check it in? 
 Will programmers integration-test their code before 
they check it in? 
 Will programmers review or inspect each other's 
code? 
12 
2.1. Thiết kế chương trình 
4. Tools 
 Have you selected a revision control tool? 
 Have you selected a language and language version or 
compiler version? 
 Have you selected a framework such as J2EE or 
Microsoft .NET or explicitly decided not to use a 
framework? 
 Have you decided whether to allow use of nonstandard 
language features? 
 Have you identified and acquired other tools you'll be 
using—editor, refactoring tool, debugger, test 
framework, syntax checker, and so on? 
13 
2.2. Các kỹ thuật xây dựng hàm/thủ tục 
1. Tại sao phải xây dựng hàm/thủ tục 
 Loại bỏ trùng mã/Avoid duplicate code 
 Hỗ trợ phân chia lớp/Support subclassing 
 Che dấu thứ tự thực hiện / Hide sequences 
 Tăng cƣờng chất lƣợng khả chuyển/ Improve 
portability 
 Tăng cƣờng hiệu quả thực thi / Improve 
performance 
14 
2.2. Các kỹ thuật xây dựng hàm/thủ tục 
2. Design at the Routine Level 
3. Good Routine Names 
4. How Long Can a Routine Be? 
5. How to Use Routine Parameters 
6. Special Considerations in the Use of 
Functions 
7. Macro Routines and Inline Routines 
15 
2.2. Các kỹ thuật xây dựng hàm/thủ tục 
 The most important reason for creating a routine is to 
improve the intellectual manageability of a program, and 
you can create a routine for many other good reasons. 
 Sometimes the operation that most benefits from being 
put into a routine of its own is a simple one. 
 You can classify routines into various kinds of cohesion, 
but you can make most routines functionally cohesive, 
which is best. 
 The name of a routine is an indication of its quality. 
 Functions should be used only when the primary 
purpose of the function is to return the specific value 
described by the function's name. 
 Careful programmers use macro routines with care and 
only as a last resort. 
16 
Các câu hỏi cần thiết khi xây dựng hàm/thủ tục (Code Complete) 
1. Big-Picture Issues 
 Is the reason for creating the routine sufficient? 
 Have all parts of the routine that would benefit from being put 
into routines of their own been put into routines of their own? 
 Is the routine's name a strong, clear verb-plus-object name for 
a procedure or a description of the return value for a function? 
 Does the routine's name describe everything the routine does? 
 Have you established naming conventions for common 
operations? 
 Does the routine have strong, functional cohesion—doing one 
and only one thing and doing it well? 
 Do the routines have loose coupling—are the routine's 
connections to other routines small, intimate, visible, and 
flexible? 
 Is the length of the routine determined naturally by its function 
and logic, rather than by an artificial coding standard? 
17 
Các câu hỏi cần thiết khi xây dựng hàm/thủ tục (Code Complete) 
2. Parameter-Passing Issues 
 Does the routine's parameter list, taken as a whole, 
present a consistent interface abstraction? 
 Are the routine's parameters in a sensible order, 
including matching the order of parameters in similar 
routines? 
 Are interface assumptions documented? 
 Does the routine have seven or fewer parameters? 
 Is each input parameter used? 
 Is each output parameter used? 
 Does the routine avoid using input parameters as 
working variables? 
 If the routine is a function, does it return a valid value 
under all possible circumstances? 
18 
2.3. Các kỹ thuật bẫy lỗi và lập trình phòng ngừa 
1. Đảm bảo loại bỏ lỗi nhập liệu 
Các quy tắc (Code Complete): 
- QT1. Check the values of all data from external 
sources 
- QT2. Check the values of all routine input parameters 
- QT3. Decide how to handle bad inputs 
19 
2.3. Các kỹ thuật bẫy lỗi và lập trình phòng ngừa 
1. Đảm bảo loại bỏ lỗi nhập liệu 
Các quy tắc (Code Complete): 
- QT1. Check the values of all data from external 
sources 
- QT2. Check the values of all routine input parameters 
- QT3. Decide how to handle bad inputs 
20 
2.3. Các kỹ thuật bẫy lỗi và lập trình phòng ngừa 
2. Assertions (kiểm soát/khẳng định) 
Định nghĩa: An assertion is code that's used during 
development—usually a routine or macro—that 
allows a program to check itself as it runs 
Các quy tắc (Code Complete): 
- QT1. Use error-handling code for conditions you 
expect to occur; use assertions for conditions that 
should never occur 
- QT2. Avoid putting executable code into assertions 
- QT3. Use assertions to document and verify 
preconditions and post-conditions 
21 
2.3. Các kỹ thuật bẫy lỗi và lập trình phòng ngừa 
2. Assertions (kiểm soát/khẳng định) 
 C++ Example of an Assertion Macro 
#define ASSERT( condition, message ) 
{ \ if ( !(condition) ) 
{ \ LogError( "Assertion failed: ", \ 
#condition, message ); 
\ exit( EXIT_FAILURE ); \ } \ }