Xem mẫu
- CHƯƠNG 2
PHÁT TRIỂN PHẦN MỀM
Mục đich: Chương này tập trung vào các
hoạt động và các nguyên tắc để phát
triển phần mềm theo hướng cấu trúc và
hướng đối tượng
- NỘI DUNG
2.1 Các hoạt động phát triển p/mềm
2.1.1 Thiết kế phần mềm
2.1.2 Sinh mã – hiện thực, triển khai
2.1.3 Kiểm thử phần mềm
2.2 Nghệ thuật gỡ rối
2.2.1 Brute-force (ép buộc)
2.2.2 Loại trừ nguyên nhân
2.2.3 Theo vết
- 2.1 Các hoạt động phát triển p/mềm
• Các giai đoạn p/triển gồm:
2.1.1 Thiết kế phần mềm (software
design);
2.1.2 Sinh mã (code generation);
2.1.3 Kiểm thử phần mềm (software
testing)
- 2.1.1 Thiết kế phần mềm
• Là công việc đầu tiên của giai đoạn ↑
• Nhằm tạo ra các biểu diễn và dữ kiện
của hệ thống p/mềm cần x/dựng từ kết
quả phân tích yêu cầu để có thể dễ
dàng thực hiện sau đó
• Là lĩnh vực tương đối mới mẻ và đang
phát triển với nhiều phương pháp khác
nhau
- 2.1.1 Thiết kế phần mềm
2.1.1.1 Cơ sở của thiết kế p/mềm
2.1.2.2 Phân chia module hiệu quả
2.1.2.3 Các hoạt động thiết kế
2.1.2.3 Phương pháp thiết kế cổ điển
2.1.2.4 Phương pháp thiết kế hướng
đối tượng
- 2.1.1.1 Cơ sở của thiết kế p/mềm
• a) Trừu tượng hóa
• b) Tinh chế
• c) Phân chia moddule
• d) Kiến trúc phần mềm
• e) Cấu trúc dữ liệu
• f) Thủ tục
• g) Che dấu thông tin
- a) Trừu tượng hóa
• Quá trình thiết kế trải qua nhiều mức độ
trừu tượng hóa khác nhau:
– Mức cao nhất: Vần đề cần thiết kế được mô
tả một cách tổng quát sử dụng thuật ngữ
hướng vấn đề
– Mức thấp hơn: Hướng đến thủ tục xử lý chi
tiết; kết hợp các thuật ngữ hướng đến hiện
thực
– Mức thấp nhất: Vấn đề được mô tả theo cách
có thể thực hiện trực tiếp
- a) Trừu tượng hóa
• Phân loại giữa trừu tượng hóa thủ tục và
dữ liệu
* Trừu tượng hóa thủ tục: Là chuỗi các lệnh liên
tiếp thực hiện một chức năng nào đó.
Ví dụ:
- Mở cửa bao gồm: đi đến cửa, cầm lấy tay
nắm, xoay tay nám, kéo cánh cửa ra
- Thêm một phần tử vào danh sách có thứ tự:
Xác định vị trí, chèn phần tử mới
- a) Trừu tượng hóa
• * Trừu tượng hóa dữ liệu: Là tổ hợp dữ
liệu mô tả một đối tượng dữ liệu
• Ví dụ: một đối tượng thực thể là sự trừu
tượng hóa của các tính chất và hành vi
- b) Tinh chế
• Tinh chế là quá trình làm rõ vấn đề. Tinh
chế và trừu tượng hóa là 2 khái niệm bù
trừ nhau thể hiện: Càng tinh chế thì càng
hạ thấp mức độ trừu tượng hóa
- c) Phân chia moddule
• p/mềm được thực hiện bằng cách phân chia
thành nhiều module, sau đó sẽ được tích hợp lại
• Phân chia module làm cho việc quản lý phần
mềm khoa học hơn. Thật vậy:
– Giả sử C(x) là độ phức tạp của X, E(X) là công sức
để thực hiện X. Rõ ràng nếu C(p1)>C(p2) thì
E(p1)>E(p2). Nếu phân chia p = p1+p2 ta thấy (một
cách trực quan) C(p1+p2) >C (p1)+C(p2)
E(p1+p2)>E(p1) +E(p2)
- c) Phân chia moddule
• Số lượng module phụ thuộc vào độ phức
tạp của hệ thống phần mềm cần xây
dựng. Quá ít hay quá nhiều module đều
không tốt
Công sức bỏ ra
Vùng tối ưu
Công sức tích hợp Công sức từng module
Số lượng module
- d) Kiến trúc phần mềm
• Kiến trúc phần mềm mô tả các thành phần kiến
tạo nên hệ thống phần mềm và sự giao tiếp
giữa các thành phần đó.
=> Kiến trúc p/m = tập hợp các module/thành phần
và quan hệ giữa chúng
– Các thành phần/module có thể là:
• Các module mã nguồn: hàm/nhóm hàm/lớp
• Các file thực thi (*.dll. *.exe; *.class)
• Các thành phần của kiến trúc hệ thống: ActiveX control,
bean, ...
• Các trang html: *.asp, *.jsp
– Quan hệ: Sử dụng/gọi/kế thừa, ….
- d) Kiến trúc phần mềm
Phần mềm nhìn từ cấu trúc phân cấp
• Cấu trúc phần mềm là cấu trúc phân cấp
(hierarchical structure): mức trên là hệ thống
(system), dưới là các hệ thống con
(subsystems)
• Dưới hệ thống con là các chương trình
• Dưới chương trình là các Modules hoặc
Subroutines với các đối số (arguments)
- d) Kiến trúc phần mềm
Phần mềm nhìn từ cấu trúc phân cấp
System
Subsystem
Master files
Subsystem Job unit
Program Tem porary Program Jobstep unit
files
Module Module Subroutine
Arguments Arguments Member unit
Common Module
- d) Kiến trúc phần mềm
Phần mềm nhìn từ cấu trúc và thủ tục
• Hai yếu tố cấu thành của phần mềm
– Phương diện cấu trúc
– Phương diện thủ tục
• Cấu trúc phần mềm: biểu thị kiến trúc các
chức năng mà phần mềm đó có và điều kiện
phân cấp các chức năng (thiết kế cấu trúc)
• Thiết kế chức năng: theo chiều đứng (càng sâu
càng phức tạp) và chiều ngang (càng rộng
càng nhiều chức năng, qui mô càng lớn)
- d) Kiến trúc phần mềm
• Sơ đồ phân cấp module được dùng để mô
tả sự phân rã,quan hệ phụ thuộc giữa các
môđun và giao diện (interface) giữa chúng
Chiều sâu Hệ số phân chia đẩu ra (fan - out)
Hệ số gộp đầu vào (fan - in)
Chiều rộng
- d) Kiến trúc phần mềm
Sơ đồ phân cấp
– Không liên quan đến trình tự gọi các môđun, nhưng ngầm
định là từ trái qua phải
– Mỗi môđun xuất hiện trong cấu trúc 1 lần, có thể được gọi
nhiều lần
– Quan hệ trên dưới: không cần nêu số lần gọi
– Tên môđun biểu thị chức năng (“làm gì”), đặt tên sao cho
các môđun ở phía dưới tổng hợp lại sẽ biểu thị đủ chức
năng của môđun tương ứng phía trên
– Biến số (arguments) biểu thị giao diện giữa các môđun,
biến số ở các môđun gọi/bịgọi có thể khác nhau
– Mũi tên với đuôi tròn trắng biểu thị dữ liệu, đuôi tròn đen
(hồng) biểu thị flag
– Chiều của mũi tên là hướng truyền tham số
- d) Kiến trúc phần mềm
Module A
1
Module B Module C Module D
Luồng dữ liệu Module E
Luồng flag
- d) Kiến trúc phần mềm
• Các loại kiến trúc:
Xét 3 mô hình kiến trúc thường được sử
dụng:
– Chia sẻ dữ liệu: Mô hình kho dữ liệu dùng
chung (repository)
– Chia sẻ dịch vụ: Mô hình client/server
– Mô hình phân lớp (layered model)
nguon tai.lieu . vn