Cơ sở lý luận về phân tích thiết kế hệ thống thông tin quản lý khách hàng.docx
Chuong 3. cnpm
1. CHƯƠNG 3. QUY TRÌNH XÂY
DỰNG PHẦN MỀM
Bộ môn Công nghệ thông tin
Trường Đại học Thương mại
1
2. Nội dung
3.1. Phân tích và đặc tả yêu cầu phần 3.4. Kiểm thử
mềm 3.4.1. Khái niệm
3.1.1. Đặc tả yêu cầu phần mềm 3.4.2. Các phương pháp kiểm thử
3.1.2. Phân tích yêu cầu hệ thống 3.4.3. Các kỹ thuật kiểm thử
3.2. Thiết kế phần mềm 3.4.4. Các loại kiểm thử
3.2.1. Thiết kế giao diện 3.4.5. Các hoạt động kiểm thử
3.2.2. Thiết kế chương trình 3.5. Cài đặt phần mềm
3.2.3. Thiết kế các tập tin dữ liệu 3.5.1. Lập kế hoạch cài đặt
3.3. Lập trình 3.5.2. Biến đổi dữ liệu
3.3.1. Khái niệm 3.5.3. Biên soạn tài liệu hệ thống
3.3.2. Phương pháp lập trình 3.6. Bảo trì phần mềm
3.3.3. Ngôn ngữ lập trình
3.3.4. Phong cách lập trình
2
3. 3.1. Phân tích và đặc tả yêu cầu phần mềm
Phân tích và đặc tả yêu cầu là bản đặc tả các dịch
vụ mà hệ thống cung cấp và các ràng buộc để xây
dựng và vận hành hệ thống.
Quá trình tìm kiếm, phân tích, tư liệu hoá, và
kiểm tra các dịch vụ và các ràng buộc của hệ
thống được gọi là kỹ thuật xác định yêu cầu
(Requirements Engineering - RE).
3
4. 3.1. Phân tích và đặc tả yêu cầu phần mềm
Chúng ta cần phải viết các yêu cầu ở các mức chi
tiết khác nhau vì có nhiều người sử dụng khác
nhau sử dụng chúng theo những cách khác nhau.
Phân tích yêu cầu là khâu kỹ thuật đầu tiên trong
quá trình xây dựng phần mềm. Bên phát triển và
khách hàng cần phối hợp thực hiện, tìm hiểu xem
hệ thống cần làm gì.
4
5. 3.1.1. Đặc tả yêu cầu phần mềm
Yêu cầu phần mềm: là tất cả các yêu cầu về phầm mềm
do khách hàng - người sử dụng phần mềm - nêu ra, bao
gồm: các chức năng của phần mềm, hiệu năng của phần
mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc
biệt khác.
Thông thường các yêu cầu phần mềm được phân loại theo
4 thành phần của phần mềm:
– Các yêu cầu về phần mềm (Software)
– Các yêu cầu về phần cứng (Hardware)
– Các yêu cầu về dữ liệu (Data)
– Các yêu cầu về con người (People, Users)
5
6. 3.1.1. Đặc tả yêu cầu phần mềm
Mục đích: mục đích của yêu cầu phần mềm là xác
định được phần mềm đáp ứng được các yêu cầu và
mong muốn của khách hàng - người sử dụng phần
mềm.
Lý do: Khách hàng chỉ có những ý tưởng còn mơ hồ
về phần mềm cần phải xây dựng để phục vụ công
việc của họ, người phát triển phải sẵn sàng, kiên trì
theo đuổi để đi từ các ý tưởng mơ hồ đó đến “Phần
mềm có đầy đủ các tính năng cần thiết”.
– Khách hàng rất hay thay đổi các đòi hỏi của mình,
người phát triển cần nắm bắt được các thay đổi đó
và sửa đổi các mô tả một cách hợp lý
6
8. 3.1.1. Đặc tả yêu cầu phần mềm
Mục tiêu của quy trình xác định yêu cầu là đưa ra
các tài liệu yêu cầu của hệ thống.
Quy trình xác định yêu cầu biến đổi phụ thuộc
vào miền ứng dụng, con người và tổ chức xây
dựng yêu cầu. Tuy nhiên, những quy trình này
vẫn có chung một số hoạt động sau: phát hiện yêu
cầu, phân tích yêu cầu, đánh giá yêu cầu và quản
lý yêu cầu.
8
9. 3.1.1. Đặc tả yêu cầu phần mềm
Nội dung
– Phát hiện các yêu cầu phần mềm (Requirements
elicitation)
– Phân tích các yêu cầu phần mềm và thương lượng với
khách hàng (Requirements analysis and negotiation)
– Mô tả các yêu cầu phần mềm (Requirements
specification)
– Mô hình hóa hệ thống (System modeling)
– Kiểm tra tính hợp lý các yêu cầu phần mềm
(Requirements validation)
– Quản trị các yêu cầu phần mềm (Requirements
management)
9
10. 3.1.1. Đặc tả yêu cầu phần mềm
Tuy nhiên, trong thực tế, các yêu cầu luôn luôn
thay đổi, thậm chí ngay cả khi đang xây dựng hệ
thống. Vì vậy, người ta thường sử dụng mô hình
xoắn ốc để xác định các yêu cầu. Mô hình này
cho phép việc xác định yêu cầu và cài đặt hệ
thống được thực hiện cùng lúc.
10
11. Mô hình xắn ốc trong quy trình xác định
yêu cầu
Mô hình xắn ốc trong quy trình xác định yêu cầu
11
12. Phân tích và phát hiện yêu cầu PM
Xác định các phương pháp sử dụng phát hiện
các yêu cầu phần mềm: phỏng vấn, làm việc
nhóm, các buổi họp, gặp gỡ đối tác, v.v.
Tìm kiếm các nhân sự (chuyên gia, người sử
dụng) có những hiểu biết sâu sắc nhất, chi
tiết nhất về hệ thống giúp người phát triển
xác định yêu cầu phần mềm.
Xác định “môi trường kỹ thuật” (technical
environment)
12
13. Phân tích và phát hiện yêu cầu PM
Xác định các “ràng buộc lĩnh vực” (domain
constraints)
Thu hút sự tham gia của nhiều chuyên gia, khách
hàng để người phát triển có được các quan điểm
xem xét phần mềm khác nhau từ phía khách hàng
Thiết kế các kịch bản sử dụng của phần mềm
Phân tích dựa trên khung nhìn cho phép phát hiện
nhiều khía cạnh khác nhau của một vấn đề và giúp
phát hiện ra sự xung đột giữa các yêu cầu.
13
14. Phân tích và phát hiện yêu cầu PM
Khung nhìn được chia thành 3 loại chính và mỗi
loại sẽ cung cấp các yêu cầu khác nhau.
– Khung nhìn tương tác: là những người hoặc hệ thống khác
tương tác với hệ thống. Trong hệ thống ATM, khách hàng
và CSDL tài khoản là những khung nhìn tương tác
– Khung nhìn gián tiếp: là những stakeholder không sử dụng
hệ thống trực tiếp nhưng có ảnh hưởng tới hệ thống. Trong
hệ thống ATM, nhân viên quản lý và bảo mật là những
khung nhìn gián tiếp.
– Khung nhìn miền ứng dụng: là những đặc điểm và ràng
buộc của miền ứng dụng, có ảnh hưởng tới các yêu cầu.
Trong hệ thống ATM, các chuẩn để giao tiếp giữa nhiều
ngân hàng là một ví dụ.
14
15. Phân tích và phát hiện yêu cầu PM
Ta có thể phát hiện khung nhìn dựa trên:
– Người cung cấp và người nhận các dịch vụ của hệ
thống
– Các hệ thống tương tác trực tiếp với hệ thống cần xây
dựng.
– Các chuẩn và các quy tắc
– Tài nguyên và các yêu cầu phi chức năng
– Marketing và các khung nhìn nghiệp vụ khác.
15
16. Ví dụ
Ví dụ về hệ thống quản lý thư viện (HTQLTV) có
yêu cầu sau:
– Trường đại học X cần xây dựng một Hệ thống thư viện
có chức năng cung cấp một giao diện đơn giản để lưu
cơ sở dữ liệu về các bài báo trên các thư viện khác
nhau. Người sử dụng có thể tìm kiếm, download và in
những tài liệu này.
16
18. Phân tích và phát hiện yêu cầu PM
Phỏng vấn hình thức hoặc phi hình thức là một
trong những phần quan trọng nhất của quy trình
xác định yêu cầu. Trong quá trình phỏng vấn,
những người xác định yêu cầu sẽ đặt ra các câu
hỏi cho các bên liên quan về hệ thống hiện tại họ
đang sử dụng và hệ thống sẽ được xây dựng. Và
các yêu cầu sẽ được lấy ra từ những câu trả lời
của người sử dụng.
18
19. Phỏng vấn được chia thành hai loại:
– Phỏng vấn đóng: tập các câu hỏi đã được định nghĩa
trước và có nhiều đáp án để người sử dụng lựa chọn trả
lời.
– Phỏng vấn mở: tất cả các vấn đề không được xác định
trước và người sử dụng phải tự giải thích và phát biểu
theo quan điểm của mình.
19
20. 3.1.1. Đặc tả yêu cầu phần mềm
Kết quả của giai đoạn đặc tả yêu cầu phần mềm chúng ta
thu được các tài liệu sau:
– Bảng kê (statement) các đòi hỏi và chức năng khả thi
của phần mềm
– Bảng kê phạm vi ứng dụng của phần mềm
– Mô tả môi trường kỹ thuật của phần mềm
– Bảng kê tập hợp các kịch bản sử dụng của phần mềm
– Các nguyên mẫu xây dựng, phát triển hay sử dụng
trong phần mềm (nếu có)
– Danh sách nhân sự tham gia vào quá trình phát hiện
các yêu cầu phần mềm - kể cả các nhân sự từ phía công
ty- khách hàng
20
21. 3.1.1. Đặc tả yêu cầu phần mềm
Đặc tả các yêu cầu phần mềm là công việc xây dựng
các tài liệu đặc tả, trong đó có thể sử dụng tới các
công cụ như: mô hình hóa, mô hình toán học hình
thức (a formal mathematical model), tập hợp các kịch
bản sử dụng, các nguyên mẫu hoặc bất kỳ một tổ hợp
các công cụ nói trên
Chất lượng của hồ sơ đặc tả đánh giá qua các tiêu
thức
– Tính rõ ràng, chính xác
– Tính phù hợp
– Tính đầy đủ, hoàn thiện
21
22. 3.1.1. Đặc tả yêu cầu phần mềm
Các thành phần của hồ sơ đặc tả
– Đặc tả phi hình thức (Informal specifications) được
viết bằng ngôn ngữ tự nhiên
– Đặc tả hình thức (Formal specifications) được viết
bằng tập các ký pháp có các quy định về cú pháp
(syntax) và ý nghĩa (sematic) rất chặt chẽ
– Đặc tả vận hành chức năng (Operational
specifications) mô tả các hoạt động của hệ thống
phần mềm sẽ xây dựng
– Đặc tả mô tả (Descriptive specifications) – đặc tả các
đặc tính đặc trưng của phần mềm.
22
23. 3.1.1. Đặc tả yêu cầu phần mềm
Các yêu cầu của hệ thống phần mềm thường được
chia thành ba loại: yêu cầu chức năng, yêu cầu phi
chức năng và yêu cầu miền ứng dụng. Tuy nhiên,
trong thực tế chúng ta rất khó phân biết ba loại yêu
cầu này một cách rõ ràng.
Trong phần này chúng ta tìm hiểu:
– a. Các loại đặc tả
– b. Phương pháp xác định các yêu cầu hệ thống
– c. Đặc tả miềm ứng dụng
– d. Một số kỹ thuật đặc tả yêu cầu HT
23
24. a. Đặc tả chức năng
Đặc tả chức năng (Operational Specifications): Yêu cầu
chức năng mô tả hệ thống sẽ làm gì. Nó mô tả các chức
năng hoặc các dịch vụ của hệ thống một cách chi tiết.
Đặc điểm của yêu cầu chức năng:
– Tính mập mờ, không rõ ràng của các yêu cầu: Vấn đề này xảy ra
khi các yêu cầu không được xác định một cách cẩn thận. Các yêu
cầu mập mờ có thể được người xây dựng và người sử dụng hiểu
theo nhiều cách khác nhau.
– Tính hoàn thiện và nhất quán: Về nguyên tắc, yêu cầu phải chứa
tất cả các mô tả chi tiết và không có sự xung đột hoặc đối ngược
giữa các yêu cầu. Tuy nhiên, trong thực tế rất khó có thể đạt được
điều này.
24
25. a. Đặc tả chức năng
Thông thường khi đặc tả các chức năng của phần
mềm người ta sử dụng các công cụ tiêu biểu sau
– Biểu đồ luồng dữ liệu (Data Flow Diagrams)
– Máy trạng thái hữu hạn (Finite State Machines)
– Mạng Petri (Petri nets)
25
26. a. Đặc tả chức năng
Ví dụ xác định các yêu cầu chức năng của
HTQLTV
– Người sử dụng có thể tìm kiếm tất cả CSDL hoặc một
tập con của CSDL.
– Hệ thống sẽ cung cấp những giao diện thích hợp để
người sử dụng đọc tài liệu.
– Tất cả những hoá đơn mà người sử dụng đăng ký để in
sao tài liệu có một mã duy nhất.
26
27. b. Đặc tả phi chức năng
Đặc tả phi chức năng không đề cập trực tiếp tới các chức
năng cụ thể của hệ thống. Yêu cầu phi chức năng thường
định nghĩa các thuộc tính như: độ tin cậy, thời gian đáp
ứng, các yêu cầu về lưu trữ …và các ràng buộc của hệ
thống như: khả năng của thiết bị vào/ra, giao diện …
Một số đặc tả phi chức năng còn có liên quan đến quy
trình xây dựng hệ thống. Ví dụ: các chuẩn được sử dụng,
các công cụ CASE, ngôn ngữ lập trình …
Các đặc tả phi chức năng có thể là hạn chế hơn những đặc
tả chức năng. Nhưng nếu nó không được thoả mãn thì hệ
thống sẽ không sử dụng được.
27
28. b. Đặc tả phi chức năng
Các đặc tả phi chức năng xuất hiện là do yêu cầu của
người sử dụng, ràng buộc về ngân sách, các chính sách
của tổ chức sử dụng hệ thống, yêu cầu tương thích giữa
phần cứng và phần mềm và đặc tả phi chức năng như sau:
– Các đặc tả về sản phẩm xác định ứng xử của sản phẩm
như: hiệu năng, khả năng sử dụng, độ tin cậy … của
sản phẩm.
– Các đặc tả về tổ chức: các đặc tả này được lấy từ
những chính sách và quy tắc của khách hàng hoặc tổ
chức sử dụng hệ thống.
– Các đặc tả ngoài: được xác định từ các tác nhân ngoài
của hệ thống.
28
30. b. Đặc tả phi chức năng
Khó xác định chính xác và rất khó thẩm tra những
yêu cầu phi chức năng mập mờ. Do đó, trong tài liệu
đặc tả yêu cầu, người ta thường bổ sung các mục
tiêu. Mục tiêu rất hữu ích đối với người phát triển hệ
thống khi nó truyền tải được những mong muốn của
người sử dụng hệ thống. Còn với những đặc tả phi
chức năng có thể thẩm định được là những yêu cầu
có thể kiểm thử một cách khách quan.
Tuy nhiên, trong nhiều trường hợp thường xảy ra
xung đột giữa các đặc tả phi chức năng đối với
những hệ thống phức tạp.
30
31. b. Đặc tả phi chức năng
Ví dụ xác định các đặc tả phi chức năng của
HTQLTV
– Đặc tả về sản phẩm: HTQLTV phải được cài đặt bằng
HTML mà không có frame hoặc Java applets.
– Đặc tả về mặt tổ chức: Quy trình xây dựng hệ thống và
các tài liệu chuyển giao phải thoả mãn các quy tắc đã
được định nghĩa trong phần phụ lục của tài liệu
HTQLTV.
– Yêu cầu ngoài: Hệ thống không được để lộ các thông
tin cá nhân của khách hàng.
31
32. Các đặc tả phi chức năng có thể thẩm định được
của HTQLTV
– Mục tiêu của hệ thống là dễ sử dụng đối với những
người sử dụng có kinh nghiệm và được tổ chức để sao
cho tối thiểu hoá được lỗi.
– Các đặc tả phi chức năng có thể thẩm định được:
Những người sử dụng có kinh nghiệm có thể sử dụng
được tất cả các chức năng của hệ thống chỉ sau hai
tiếng tập huấn. Sau khoá huấn luyện này, số lỗi chương
trình gây ra bởi người sử dụng là không quá hai lỗi một
ngày.
32
33. c. Đặc tả miền ứng dụng
Đặc tả miền ứng dụng được xác định từ miền ứng
dụng của hệ thống và phản ánh các thuộc tính và
ràng buộc của miền ứng dụng. Nó có thể là yêu
cầu chức năng hoặc phi chức năng.
33
34. c. Đặc tả miền ứng dụng
Nếu đặc tả miền ứng dụng không được thoả mãn
thì có thể hệ thống sẽ không làm việc được. Một
số vấn đề liên quan:
– Khả năng có thể hiểu được: các yêu cầu được biểu diễn
dưới ngôn ngữ của lĩnh vực ứng dụng.
– Ẩn ý: Các chuyên gia có hiểu biết về lĩnh vực của họ
nhưng họ không biết cách xây dựng những yêu cầu
miền ứng dụng một cách rõ ràng, mang tính kỹ thuật.
34
35. c. Đặc tả miền ứng dụng
Ví dụ về đặc tả miền ứng dụng của HTQLTV:
– Giao diện người dùng chuẩn cho tất cả các CSDL đều
dựa trên chuẩn phù hợp với mô hình mạng Client-
Server.
– Vì vấn đề bản quyền nên một số tài liệu phải xoá ngay
khi vừa chuyển đến.
– Phụ thuộc vào yêu cầu của người sử dụng, những tài
liệu đó có thể được in ngay trên server và chuyển đến
cho người sử dụng hoặc gửi đến cho máy in mạng.
35
36. d. Một số kỹ thuật đặc tả yêu cầu HT
1. Đặc tả bằng ngôn ngữ hướng cấu trúc:
– Sử dụng ngôn ngữ hướng cấu trúc sẽ yêu cầu người
viết đặc tả tuân theo những mẫu được định nghĩa trước.
Tất cả các yêu cầu đều được viết theo chuẩn và các
thuật ngữ được sử dụng có thể bị hạn chế.
– Ưu điểm của phương pháp này là đạt được mức độ
diễn tả cao nhất của ngôn ngữ tự nhiên nhưng mức độ
đồng nhất lại bị lạm dụng trong các đặc tả.
36
37. d. Một số kỹ thuật đặc tả yêu cầu HT
2. Đặc tả dựa biểu mẫu (Form-based):
– Đặc tả dựa biểu mẫu định nghĩa các chức năng hoặc
thực thể, mô tả đầu vào và nơi xuất phát của nó, mô tả
đầu ra và nơi nó sẽ đến. Đặc tả dựa biểu mẫu chỉ rõ
những thực thể cần thiết, các điều kiện trước và sau
(nếu thích hợp), các ảnh hưởng của chức năng.
3. Biểu đồ trình tự:
– Biểu đồ trình tự biểu diễn trình tự các sự kiện xảy ra
khi người sử dụng tương tác với hệ thống. Nếu ta đọc
biểu đồ này từ đầu đến cuối thì ta sẽ thấy được thứ tự
của các hành động được thực hiện.
37
38. 3.1.1. Đặc tả yêu cầu phần mềm
Đặc tả mô tả (Descriptive Specifications)
– Biểu đồ thực thể liên kết (Entity-Relationship
Diagrams)
– Đặc tả Logic (Logic Specifications)
– Đặc tả đại số (Algebraic Specifications)
38
39. Tài liệu đặc tả yêu cầu
Tài liệu đặc tả yêu cầu là những yêu cầu chính
thức về những gì cần phải thực hiện bởi đội phát
triển hệ thống.
Tài liệu đặc tả yêu cầu nên bao gồm cả các định
nghĩa về yêu cầu của người sử dụng và đặc tả yêu
cầu hệ thống.
Tài liệu đặc tả yêu cầu không phải là tài liệu thiết
kế hệ thống. Nó chỉ thiết lập những gì hệ thống
phải làm, chứ không phải mô tả rõ làm như thế
nào.
39
40. Các yêu cầu của một đặc tả tốt
Dễ hiểu với người dùng
Có ít điều nhập nhằng
Có ít quy ước khi mô tả, có thể tạo đơn giản
Với phong cách từ trên xuống (topdown)
Dễ triển khai cho những pha sau của vòng đời:
thiết kế hệ thống và thiết kế chương trình và giao
diện dễ làm, đảm bảo tính nhất quán, . . .
40
41. Ví dụ tài liệu đặc tả yêu cầu dựa theo chuẩn IEEE:
– 1. Giới thiệu
1.1. Mục đích của tài liệu yêu cầu
1.2. Phạm vi của sản phẩm
1.3. Các định nghĩa, từ viết tắt
1.4. Các tham chiếu
1.5. Tổng quan về tài liệu yêu cầu
– 2. Mô tả chung
2.1. Giới thiệu chung về sản phẩm
2.2. Các chức năng của sản phẩm
2.3. Đặc điểm của người sử dụng
2.4. Các ràng buộc
2.5. Giả thiết và các phụ thuộc
– 3. Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi chức năng, miền
ứng dụng và giao diện.
– 4. Phụ lục
– 5. Chỉ mục
41
44. 3.1.2. Phân tích hệ thống
Xác định khách hàng, cùng khách hàng phát triển các
yêu cầu
Xây dựng mô hình phân tích (hiểu bài toán):
– dữ liệu
– chức năng
– trạng thái
Làm bản mẫu đối với các chức năng chưa rõ ràng
Tạo đặc tả yêu cầu phần mềm
Thẩm định đặc tả yêu cầu
44
45. 3.1.2. Phân tích hệ thống
Các nguyên lý phân tích
Các phương pháp mô hình hóa
45
46. Nguyên lý 1
Nội dung: Mô hình hóa miền thông tin
Phải hiểu và biểu diễn được miền thông tin (problem
domain)
– định danh dữ liệu (đối tượng, thực thể)
– định nghĩa các thuộc tính
– thiết lập các mối quan hệ giữa các dữ liệu
Từ điển dữ liệu, mô hình thực thể mối quan hệ,
mô hình khái niệm
46
47. Nguyên lý 2
Nội dung: Mô hình hóa chức năng
Bản chất của phần mềm là biến đổi thông tin
– định danh các chức năng (biến đổi thông tin)
– xác định cách thức dữ liệu (thông tin) di chuyển trong hệ
thống
– xác định các tác nhân tạo dữ liệu và tác nhân tiêu thụ dữ
liệu
Mô hình phân rã chức năng, mô hình luồng dữ liệu
47
48. Nguyên lý 3
Nội dung: Mô hình hóa hành vi
Phần mềm (hệ thống) có trạng thái (hành vi)
xác định các trạng thái của hệ thống
xác định các dữ kiện làm thay đổi hành vi hệ thống
ví dụ: bàn phím, chuột, các cổng thông tin...
Biểu đồ trạng thái
48
49. Nguyên lý 4
Nội dung: Phân hoạch các mô hình
Làm mịn, phân hoạch và biểu diễn các mô hình ở
các mức khác nhau
– làm mịn các mô hình dữ liệu
– tạo cây (mô hình) phân rã chức năng
– biểu diễn hành vi ở các mức chi tiết khác nhau
Mô hình luồng dữ liệu các mức 1,2,3,..
49
50. Mô hình hóa
Biểu đồ phân rã chức năng (FDD)
Biểu đồ luồng dữ liệu (DFD)
Biểu đồ thực thể mối quan hệ (ER)
50
51. Mô hình hóa với FDD
Biểu đồ phân rã chức năng
(Function Decomposition Diagram)
• Xác định phạm vi của hệ thống
• Phân hoạch chức năng
• Tạo nền tảng cho thiết kế kiến trúc hệ thống
chức năng
liên kết
51
52. Mô hình hóa với FDD (2)
• Ví dụ
bán hàng
nhận đơn hàng xử lý đơn hàng gửi hàng
52
53. Ví dụ mô hình phân cấp chức năng đối với HTQLTV
HỆ THỐNG
QUẢN LÝ THƯ VIỆN
CẬP NHẬT TÌM KIẾM XỬ LÝ THỐNG KÊ
Cập nhật Cập nhật Tìm kiếm Tìm kiếm Xử lý Xử lý Xử lý Thống kê Thống kê
bạn đọc Sách bạn đọc sách mượn Trả Sách mất Sách bạn đọc
Nhập Sửa, Nhập Sửa Tìm Tìm Tìm Tìm Tìm Tìm Tìm TK TK TK TK TK TK TK
thông Xoá thông ,Xoá theo theo theo theo theo tên nhà Nhà Sách Loại sách tên bạn bạn
tin thông tin thông mã tên mã tên Loại tác xuất xuất bổ sách đang tác đọc đọc
bạn tin sách tin mượn đang
bạn bạn sách sách sách giả bản bản sung giả quá
đọc bạn sách mượn
đọc đọc sách hạn
đọc
53
54. Mô hình hóa với DFD
Biểu đồ luồng dữ liệu - Data Flow Diagram
• Cách thức dữ liệu được xử lý trong hệ thống
• Có nhiều mức chi tiết khác nhau (có cấu trúc)
• Có nhiều biến thể và mở rộng khác nhau
54
56. Mô hình hóa với DFD (3)
• Các đối tượng trong DFD
(cã nhiÒu c¸ch biÓu diÔn kh¸c nhau)
Luång d÷ liÖu
- luång th«ng tin di chuyÓn trong hÖ thèng
Kho d÷ liÖu
- n¬i l−u tr÷ d÷ liÖu
56
59. Mô hình ngữ cảnh HTQLTV
Yêu cầu
Nhà xuất bản
Yêu cầu cấp thẻ đặt sách
Yêu cầu hủy thẻ
Lý do từ chối
Phiếu thu /chi Từ chối
Bạn đọc Hệ thống Cung cấp sách
Cấp thẻ quản lý
thư viện
Nhắc trả sách
Kết qủa Yêu cầu
Yêu cầu mượn - trả
Báo cáo Chỉ đạo
Yêu cầu tìm kiếm
Kết quả Ban giám đốc
59
60. Biểu đồ DFD mức đỉnh của HTQLTV
Kết quả Y / C tìm kiếm
NHÀ XUẤT BẢN
BAN GIÁM ĐỐC
Y/C Cung Y/C
Sách mượn Từ Kết
đặ t cấ p tìm
Yêu cầu cấp thẻ chối quả
sách sách kiếm
Yêu cầu hủy thẻ
Bạn đọc TÌM KIẾM
Lý do từ chối CẬP NHẬT
(2)
(1)
Cấp thẻ
Phiếu thu
Yêu cầu mượn– trả Phiếu thu chi Sách
BẠN ĐỌC
XỬ LÝ MƯỢN THỐNG KÊ
Lý do từ chối TRẢ
(4)
(3)
Thông tin về sách Kết
Y/C
Phiếu chi quả,
Bạn đọc chỉ báo
đạo cáo
Sách mượn BAN GIÁM ĐỐC 60
Nhắc trả sách
61. DFD mức dưới đỉnh chức năng QLTT
Bạn đọc
Yêu cầu cấp thẻ
Lý do từ chối Bạn đọc
Thêm thông
Cấp thẻ tin bạn đọc
Phiếu thu ( 1.1.1 )
Bạn đọc Yêu cầu hủy - sửa thẻ
Phiếu thu chi
Lý do từ chối Sửa, xóa
thông
Phiếu chi tin bạn đọc
Thông tin bạn đọc ( 1.1.2 )
Bạn đọc
Sách mượn
61
62. DFD mức dưới đỉnh chức năng Xử lý
mượn trả
Yêu cầu mượn - trả
Lý do từ chối Xử lý
Thông tin sách Mượn - Trả
( 3.1 )
Bạn đọc
+ Sách mất
Sách mượn + Số thẻ
Bạn đọc
Sách
Xử lý
Phiếu thu
Sách mất
( 3.2 )
Phiếu thu chi 62
63. DFD mức dưới đỉnh chức năng Tìm
kiếm sách
Tìm kiếm Yêu cầu tìm kiếm
Yêu cầu tìm kiếm theo
mã sách Kết quả
Kết quả ( 2.2.1)
Sách
Bạn đọc Ban quản lý
Yêu cầu tìm kiếm Kết quả
Tìm kiếm
Kết quả Yêu cầu tìm kiếm
theo
Tên sách
( 2.2.2 )
63
64. DFD mức dưới đỉnh chức năng Thống
kê bạn đọc
Yêu cầu
Thống kê BĐ Nhắc trả sách
Báo cáo quá hạn
( 4.1.1 )
Bạn
Ban Sách mượn Bạn đọc
đọc
quản lý
Yêu cầu
Thống kê BĐ
đang mượn
Báo cáo ( 4.1.2 )
64
65. Mô hình hóa với ER
Mô hình dữ liệu được sử dụng để mô tả cấu trúc
logic của dữ liệu được xử lý bởi hệ thống.
Thông thường, chúng ta hay sử dụng mô hình
quan hệ -thực thể (ER) nhằm thiết lập mối quan
hệ giữa các thực thể và thuộc tính của các thực
thể. Mô hình này được sử dụng trong thiết kế
CSDL và thường được cài đặt trong các CSDL
quan hệ.
65
66. Mô hình hóa với ER
Biểu đồ thực thể mối quan hệ
(Entity Relationship Diagram)
• Mô tả mối quan hệ vốn có của thế giới thực
o Thực thể
o Mối quan hệ
Phân tích dữ liệu độc lập với xử lý
Tạo ra mô hình trừu tượng hướng khách hàng
66
67. Mô hình hóa với ER (2)
•Các đối tượng
Thùc thÓ
- lµ c¸c ®èi t−îng thÕ giíi thùc mµ chóng ta muèn xö lý
- cã thÓ lµ ®èi t−îng thùc hoÆc trõu t−îng
Thuéc tÝnh
- ®Æc ®iÓm cña thùc thÓ
67
68. Mô hình hóa với ER (3)
• Các đối tượng
Mối quan hệ
- mèi liªn hÖ gi÷a c¸c thùc thÓ
- lµ th«ng tin cÇn l−u tr÷/xö lý
KÕ thõa
- quan hÖ kÕ thõa gi÷a c¸c thùc thÓ
68
69. Mô hình hóa với ER (4)
• Ví dụ
tªn m· sv
®Þa chØ
sinh viªn
phim l−u bản sao
tr÷
69
70. Mô hình hóa với ER (5)
• Lực lượng tham gia mối quan hệ
(0, m)
object1 relationship object 2
(1, 1)
object1 relationship
object 2
(0, m) (1, 1)
70
72. Mô hình hóa với ER (7)
• Các bước mô hình hóa với ER
o Xác định các thực thể và các thuộc tính của các thực
thể
o Xác định các mối quan hệ giữa các thực thể
o Mô tả các thực thể, mối quan hệ và các thuộc tính
72
74. Từ điển dữ liệu
Trên thực tế, mô hình dữ liệu thường không chi
tiết. Người phát triển có thể sử dụng từ điển dữ
liệu làm công cụ bổ trợ. Từ điển dữ liệu là danh
sách tất cả các tên gọi được sử dụng trong các mô
hình hệ thống. Đó có thể là các thực thể, quan hệ
và các thuộc tính …
Ưu điểm của từ điển dữ liệu là:
– hỗ trợ quản lý tên và tránh trùng lặp tên,
– lưu trữ kiến thức một cách có tổ chức kết nối pha phân
tích, thiết kế và cài đặt.
74
75. Ví dụ: từ điển dữ liệu của HTQLTV
Tên Mô tả Kiểu
Sach Tên quyển sách có Thực thể
trong thư viện
Tacgia Tên tác giả viết Thuộc tính
sách
NXB Địa chỉ nhà xuất Thuộc tính
bản quyển sách
… … …
75
76. 3.2. Thiết kế phần mềm
3.2.1. Thiết kế giao diện
3.2.2. Thiết kế chương trình
3.2.3. Thiết kế các tập tin dữ liệu
76
77. 3.2. Thiết kế phần mềm
Là thiết kế cấu hình phần cứng và cấu trúc phần
mềm (gồm cả chức năng và dữ liệu) để có được
hệ thống thỏa mãn các yêu cầu đề ra.
Đặc điểm:
– Phân chia mô hình phân tích ra các hệ con
– Tìm ra sự tương tranh (concurrency) trong hệ thống
– Phân bố các hệ con cho các bộ xử lý hoặc các nhiệm
vụ (tasks)
– Phát triển thiết kế giao diện
– Chọn chiến lược cài đặt quản trị dữ liệu
77
78. 3.2. Thiết kế phần mềm
Đặc điểm:
– Tìm ra nguồn tài nguyên chung và cơ chế điều khiển
truy nhập chúng
– Thiết kế cơ chế điều khiển thích hợp cho hệ thống, kể
cả quản lý nhiệm vụ
– Xem xét các điều kiện ràng buộc được xử lý như thế
nào
78
79. 3.2. Thiết kế phần mềm
Lưu ý trong quá trình thực hiện thiết kế phần
mềm:
(1) Có thể trích được luồng dữ liệu từ hệ thống: đó
là phần nội dung đặc tả yêu cầu và giao diện
(2) Xem xét tối ưu tài nguyên kiến trúc lên hệ
thống rồi quyết định kiến trúc
(3) Trong quá trình biến đổi dữ liệu, hãy xem
những chức năng được kiến trúc như thế nào
(4) Từ kiến trúc các chức năng theo (3), hãy xem
xét và chỉnh lại, từ đó chuyển sang kiến trúc
chương trình và thiết kế chi tiết
79
80. 3.2. Thiết kế phần mềm
(5) Quyết định các đơn vị chương trình theo các chức
năng của hệ phần mềm có dựa theo luồng dữ liệu và
phân chia ra các thành phần
(6) Khi cấu trúc chương trình lớn quá, phải phân chia
nhỏ hơn thành các môđun
(7) Xem xét dữ liệu vào-ra và các tệp dùng chung của
chương trình. Truy cập tệp tối ưu
(8) Hãy nghĩ xem để có được những thiết kế trên thì nên
dùng phương pháp luận và những kỹ thuật gì?
80
81. 3.2.1. Thiết kế giao diện
Giao diện người dùng cần phải được thiết kế sao
cho phù hợp với kỹ năng, kinh nghiệm và sự
trông đợi của người sử dụng nó.
Người sử dụng hệ thống thường đánh giá hệ
thống thông qua giao diện hơn là chức năng của
nó. Giao diện hệ thống nghèo nàn có thể khiến
người sử dụng tạo ra các lỗi hết sức nghiêm trọng.
Đó là lý do tại sao nhiều hệ thống phần mềm
không bao giờ được sử dụng.
81
82. 3.2.1. Thiết kế giao diện
Tác nhân con người trong thiết kế giao diện
– Một nhân tố quan trọng ảnh hưởng tới quá trình thiết
kế giao diện đó chính là người sử dụng hệ thống. Do
đó, chúng ta phải tìm hiểu một số đặc điểm của người
sử dụng có liên quan đến giao diện hệ thống:
Khả năng nhớ tức thời của con người bị hạn chế: con người
chỉ có thể nhớ ngay khoảng 7 loại thông tin. Nếu ta biểu diễn
nhiều hơn 7 loại, thì có thể khiến người sử dụng không nhớ
hết và gây ra các lỗi.
82
83. – Người sử dụng có thể gây ra lỗi: khi người sử dụng
gây ra lỗi khiến hệ thống sẽ hoạt động sai, những thông
báo không thích hợp có thể làm tăng áp lực lên người
sử dụng và do đó, càng xảy ra nhiều lỗi hơn.
– Người sử dụng là khác nhau: con người có những khả
năng khác nhau. Những người thiết kế không nên chỉ
thiết kế giao diện phù hợp với những khả năng của
chính họ.
– Người sử dụng thích các loại tương tác khác nhau: một
số người thích hình ảnh, văn bản, âm thanh …
83
84. 3.2.1. Thiết kế giao diện
Các nguyên tắc thiết kế giao diên
– Sự quen thuộc của người sử dụng: giao diện phải được xây
dựng dựa trên các thuật ngữ và các khái niệm mà người sử
dụng có thể hiểu được hơn là những khái niệm liên quan
đến máy tính. Ví dụ: hệ thống văn phòng nên sử dụng các
khái niệm như thư, tài liệu, cặp giấy … mà không nên sử
dụng những khái niệm như thư mục, danh mục …
– Thống nhất: hệ thống nên hiển thị ở mức thống nhất thích
hợp. Ví dụ: các câu lệnh và menu nên có cùng định dạng …
– Tối thiểu hoá sự bất ngờ: nếu một yêu cầu được xử lý theo
cách đã biết trước thì người sử dụng có thể dự đoán các thao
tác của những yêu cầu tương tư.
84
85. 3.2.1. Thiết kế giao diện
Các nguyên tắc thiết kế giao diên
– Khả năng phục hồi: hệ thống nên cung cấp một số khả
năng phục hồi từ lỗi của người sử dụng và cho phép
người sử dụng khôi phục lại từ chỗ bị lỗi. Khả năng
này bao gồm cho phép làm lại, hỏi lại những hành
động như xoá, huỷ …
– Hướng dẫn người sử dụng: như hệ thống trợ giúp,
hướng dẫn trực tuyến …
– Tính đa dạng: hỗ trợ nhiều loại tương tác cho nhiều
loại người sử dung khác nhau. Ví dụ: nên hiển thị
phông chữ lớn với những người cận thị
85
86. 3.2.1. Thiết kế giao diện
Biểu diễn thông tin
– Biểu diễn thông tin có liên quan tới việc hiển thị các
thông tin trong hệ thống tới người sử dụng. Thông tin
có thể được biểu diễn một cách trực tiếp hoặc có thể
được chuyển thành nhiều dạng hiển thị khác như: dạng
đồ hoạ, âm thanh …
– Thông tin cần biểu diễn được chia thành hai loại:
– Thông tin tĩnh: được khởi tạo ở đầu của mỗi phiên. Nó
không thay đổi trong suốt phiên đó và có thể là ở dạng
số hoặc dạng văn bản.
– Thông tin động: thay đổi trong cả phiên sử dụng và sự
thay đổi này phải được người sử dụng quan sát
86
87. 3.2.1. Thiết kế giao diện
Quy trình thiết kế giao diện người dùng
– Thiết kế giao diện người dùng là một quy trình lặp lại
bao gồm sự cộng tác giữa người sử dụng và người thiết
kế. Trong quy trình này gồm 3 hoạt động cơ bản:
Phân tích người sử dụng: tìm hiểu những gì người sử dụng sẽ
làm với hệ thống.
Lập mẫu thử hệ thống: xây dựng một tập các mẫu thử để kiểm
thử
Đánh giá giao diện: kiểm thử các mẫu thử cùng với người sử
dụng.
87
89. 3.2.1. Thiết kế giao diện
Thiết kế về các thủ tục người dùng và các giao diện
b1. Thủ tục người dùng/chức năng thủ công
– Gồm:
Mã hoá thông tin thu nhập
Kiểm soát và sửa chữa thông tin
Nhập thông tin
Kiểm tra tài liệu xuất
Phân phối tài liệu xuất
– Yêu cầu thiết kế chức năng thủ công:
Miêu tả nội dung công việc rõ ràng: Mục đích cần đạt
đáp ứng yêu cầu của hệ thống, các bước thực hiện, yêu
cầu của mỗi bước
Thông tin chính xác; Ấn định độ chính xác phải đạt
Ấn định mức năng suất cần thiết (gõ phím ít nhất),
hướng dẫn mức xử lý khi có sai sót 89
90. 3.2.1.Thiết kế giao diện
b2. Thiết kế việc thu nhập dữ liệu thông qua các biểu mẫu (tờ khai, các
phiéu điều tra, v..v)
– Chọn phương thức thu nhập :
On-line
Trì hoãn
Từ xa
– Xác định khuôn mẫu thu nhập:
Khung (để điền)
Câu hỏi (câu hỏi đóng: trả lời xác định trước, câu hỏi
mở: gợi ý)
– Yêu cầu biểu mẫu:
Thuận tiện cho người điều tra
Thuận tịện mã hoá
Thuận tiện người gõ phím
Nội dung đơn giản, rõ ràng, chính xác 90
91. 3.2.1.Thiết kế giao diện
b3. Thiết kế các tài liệu xuất
Tài liệu xuất:
– Các bảng biểu thống kê, tổng hợp
– Các chứng từ giao dịch (đơn hàng, hóa đơn v..v)
Xác định:
– Phương tiện: giấy, màn hình, đĩa, v..v
– Phương thức: lập tức hay trì hoãn
– Dạng tài liệu xuất : có cấu trúc hay không có cấu trúc
– Cách trình bày: đầu _ thân_cuối
Yêu cầu:
– Đủ, chính xác (kiểm tra không nhập nhằng), dễ hiểu, dễ
đọc.
91
92. 3.2.1.Thiết kế giao diện
b4. Thiết kế các màn hình và đơn chọn: giao diện đối thoại giữa người
dùng và máy tính
– Dựa trên yêu cầu của người dùng và việc hiển thị chi tiết về dữ
liệu, các dạng hội thoại thường gồm:
Câu lệnh, câu nhắc: Máy hỏi hay nhắc, người đáp lại
Đơn chọn (Menu): Người dùng chọn một mục trong nhiều
mục
Điền mẫu: Người dùng điền thông tin vào ô mẫu trên màn
hình
Sử dụng các biểu tượng (Icon) để tăng tính trực quan
– Yêu cầu thiết kế:
Vào / ra gần nhau
Thông tin thường tối thiểu (cần đâu lấy đấy)
Sáng sủa (dễ nhìn, dễ đọc)
Lệnh phải rành mạch (muốn gì? Làm gì?) 92
101. Giao diện chức năng Thông kê bạn đọc
mượn sách quá hạn
101
102. 3.2.2.Thiết kế chương trình
Thiết kế nội dung của chương trình mà không
phải viết chương trình cụ thể. Người phát triển
cần thiết kế:
– Chức năng như trong BLD. Ngoài ra:
– Chức năng đối thoại
– Chức năng xử lí lỗi
– Chức năng xử lí vào/ ra
– Chức năng tra cứu CSDL
– Chức năng Module điều hành
102
103. 3.2.2.Thiết kế chương trình
Nội dung chủ yếu trong giai đoạn thiết kế chương
trình là:
– Xác định cấu trúc tổng quát
– Phân định các Module CT
– Xác định mối liên quan giữa các Module đó (thông qua
lời gọi và các thông tin trao đổi)
– Đặc tả các Module chương trình
– Gộp các Module thành chương trình
– Thiết kế các mẫu thử
103
104. 3.2.2.Thiết kế chương trình
Thiết kế chương trình theo mô hình kiến trúc
client-server
– Là một mô hình hệ thống trong đó hệ thống bao gồm
một tập hợp các server cung cấp dịch vụ và các client
truy nhập và sử dụng các dịch vụ đó. Các thành phần
chính của mô hình này bao gồm:
Tập hợp các server sẽ cung cấp những dịch vụ cụ thể
như: in ấn, quản lý dữ liệu…
Tập hợp các client truy nhập đến server để yêu cầu cung
cấp dịch vụ.
Hệ thống mạng cho phép client truy cập tới dịch vụ mà
server cung cấp.
104
105. Mô hình Client – Server
Client (máy khách) phải biết tên của Server (máy
chủ) và các dịch vụ mà server cung cấp. Nhưng
server thì không cần xác định rõ client và hiện
tại có bao nhiêu client. Client tạo ra một yêu cầu
tới server và chờ server trả lời.
Ưu điểm của mô hình client - server:
– Phân tán dữ liệu rõ ràng
– Sử dụng các hệ thống được kết nối mạng một cách
hiệu quả và chi phí dành cho phần cứng có thể rẻ hơn.
– Dễ dàng bổ sung hoặc nâng cấp server
105
106. Mô hình Client – Server
Nhược điểm của mô hình client - server:
– Không phải là mô hình dữ liệu dùng chung nên các hệ
thống con có thể sử dụng các tổ chức dữ liệu khác
nhau. Do đó, việc trao đổi dữ liệu có thể không hiệu
quả.
– Quản lý mỗi server không thống nhất, dư thừa.
– Không đăng ký tên và dịch vụ tập trung. Điều này làm
cho việc tìm kiếm server hoặc các dịch vụ rất khó
khăn.
106
107. Mô hình Client – Server của hệ thống thư viện phim và ảnh
107
108. 3.2.3. Thiết kế các tập tin dữ liệu
Thiết kế tập tin dữ liệu phải dựa vào:
– Biểu đồ cấu trúc dữ liệu: mô hình quan hệ, mô
hình quan hệ thực thể liên kết E-R
– Biểu đồ luồng dữ liệu trong đó đặc biệt quan
tâm đến kho dữ liệu.
– Hệ Quản trị CSDL có sẵn: Mỗi hệ quản trị
CSDL đều có ngôn ngữ định nghĩa dữ liệu sẵn.
108
109. 3.2.3. Thiết kế các tập tin dữ liệu
Khi thiết kế các tập tin dữ liệu/CSDL phải đảm
bảo sao cho các dữ liệu phải đủ, không trùng lặp,
việc truy cập đến các tập tin dữ liệu phải thuận
tiện, tốc độ nhanh.
– Bổ xung thêm một số thuộc tính tính toán, lặp lại một
số thuộc tính, ghép một số thực thể thành một tập tin....
– Đôi khi đã chuẩn hóa dữ liệu đạt chuẩn 3 NF, BCNF..
nhưng để phục vụ các thao tác tìm kiếm, xử lý nhanh
chóng, thì các chuẩn trên có thể bị phá vỡ thành các
chuẩn mức thấp hơn.
109
110. 3.3. Lập trình
3.3.1. Khái niệm
3.3.2. Phương pháp lập trình
3.3.3. Ngôn ngữ lập trình
3.3.4. Phong cách lập trình
110
111. 3.3.1. Khái niệm
Lập trình là quá trình chuyển đổi từ thiết kế chi
tiết sang mã lệnh
Lựa chọn ngôn ngữ lập trình
- Phụ thuộc vào cấu hình máy
– Phụ thuộc vào số lượng ngôn ngữ lập trình sẵn có
– Phụ thuộc vào thói quen sử dụng ngôn ngữ lập trình
– Phụ thuộc vào khách hàng
111
112. 3.3.1. Khái niệm
Người lập trình cần xây dựng thông tin tối thiểu
cho một mô-đun chương trình, bao gồm:
– Tên mô-đun
– Mô tả vắn tắt các công việc mô-đun phải thực hiện
– Tên lập trình viên
– Ngày viết
– Ngày chỉnh sửa
– Danh sách các tham số
– Danh sách các biến
112
113. 3.3.2. Phương pháp lập trình
Lập trình tuyến tính
Lập trình cấu trúc
Lập trình Hướng đối tượng
113
114. Lập trình tuyến tính
Chương trình được viết tuần tự với các câu lệnh
thực hiện từ đầu đến cuối.
Không có/thiếu các lệnh có cấu trúc (for, while..)
Thiếu khả năng khai báo biến cục bộ
Ngôn ngữ lập trình: assembly, basic..
114
115. Lập trình tuyến tính
Ngôn ngữ lập trình tuyến tính không có khả năng kiểm
soát phạm vi nhìn thấy của các dữ liệu. Mọi dữ liệu trong
chương trình đều là dữ liệu toàn cục, nghĩa là chúng có thể
bị sửa đổi ở bất kỳ phần nào của chương trình. Việc dò
tìm các thay đổi không mong muốn đó của các phần tử dữ
liệu trong một dãy mã lệnh dài thường làm cho các lập
trình viên mất rất nhiều thời gian.
Lập trình tuyến tính được sử dụng trong các phần mềm
còn rất đơn giản. Hiện nay, khoa học máy tính ngày càng
phát triển, các phần mềm đòi hỏi ngày càng phức tạp và
lớn hơn rất nhiều, phương pháp lập trình tuyến tính được
coi là kém hiệu quả.
115
116. Lập trình cấu trúc
Phương pháp lập trình thủ tục hay lập trình cấu
trúc: hệ thống chia các chức năng (hàm) thành các
chức năng nhỏ hơn. Các chức năng nhỏ này lại
được chia tiếp thành các chức năng nhỏ hơn nữa
cho đến khi được các khối (hàm) chương trình đủ
nhỏ. Việc phân tích này được thể hiện trực quan
theo sơ đồ khối. Chương trình được tổ chức thành
các chương trình con.
Chương trình = Cấu trúc dữ liệu + giải thuật
116
117. Lập trình cấu trúc
Lập trình có cấu trúc sử dụng các lệnh có cấu
trúc, sử dụng chương trình con, biến cục bộ.
Các ngôn ngữ hỗ trợ lập trình hướng cấu trúc phổ
biến là Pascal, C, Foxpro
Lập trình hướng cấu trúc đã trở nên rất phổ biến
trong những năm 80 và đầu những năm 90, nhưng
do những hạn chế và những nhược điểm rõ ràng
khi lập trình hệ thống lớn, lập trình hướng cấu
trúc đã dần bị thay thế cho phương pháp lập trình
hướng đối tượng
117
118. Lập trình cấu trúc
Những ngôn ngữ lập trình hướng cấu trúc chỉ còn
được sử dụng để dạy học và lập trình những
chương trình nhỏ mang tính chất cá nhân. Trong
thương mại, nó đã không còn được dùng đến
nhiều.
118
119. Lập trình Hướng đối tượng
Lập trình hướng đối tượng (Object Oriented
Programming-OOP): Là phương pháp lập trình
lấy đối tượng làm nền tảng để xây dựng thuật
giải, xây dựng chương trình.
OOP là kĩ thuật lập trình hỗ trợ công nghệ đối
tượng. OOP được xem là giúp tăng năng suất, đơn
giản hóa độ phức tạp khi bảo trì cũng như mở
rộng phần mềm bằng cách cho phép lập trình viên
tập trung vào các đối tượng phần mềm ở bậc cao
hơn.
119
120. Lập trình Hướng đối tượng
Dữ liệu + Hành vi của dữ liệu = Đối tượng
Những đối tượng trong một ngôn ngữ OOP là sự
kết hợp giữa mã và dữ liệu mà chúng được nhìn
nhận như là một đơn vị duy nhất. Mỗi đối tượng
có một tên riêng biệt và tất cả các tham chiếu đến
đối tượng đó được tiến hành qua tên của nó.
120
121. Lập trình Hướng đối tượng
Như vậy, mỗi đối tượng có khả năng nhận vào
các thông báo, xử lý dữ liệu (bên trong của nó),
và gửi ra hay trả lời đến các đối tượng khác hay
đến môi trường.
Các ngôn ngữ hỗ trợ lập trình hướng đối tượng
phổ biến là: C#, C++, Java, Perl, PHP, Smalltalk..
121
122. 3.3.3. Ngôn ngữ lập trình
Lập trình là một trong những giai đoạn không thể
thiếu trong công nghệ phần mềm. Ngôn ngữ lập
trình là phương tiện để liên lạc giữa con người và
máy tính. Tiến trình lập trình - sự liên lạc thông
qua ngôn ngữ lập trình - là một hoạt động con
người.
122
123. 3.3.3. Ngôn ngữ lập trình
Đối với từng dự án phần mềm khác nhau người ta
sẽ lựa chọn ngôn ngữ lập trình phù hợp. Tuy
nhiên, ngôn ngữ lập trình được lựa chọn cần có
các đặc trưng sau:
– dễ dịch thiết kế sang chương trình,
– có trình biên dịch hiệu quả,
– khả chuyển chương trình gốc,
– có sẵn công cụ phát triển:
– dễ bảo trì.
123
124. Lựa chọn ngôn ngữ lập trình
Dựa vào:
– Đặc trưng của ngôn ngữ:
Năng lực (kiểu biến, các cấu trúc): Có cấu trúc, câu lệnh
phong phú, hỗ trợ nhiều kiểu dữ liệu, hỗ trợ con trỏ, đệ qui, hỗ
trợ hướng đối tượng, thư viện phong phú..
Tính khả chuyển: khi thay đổi phần cứng, thay đổi OS
Mức độ hỗ trợ của các công cụ (editor, debugger, linker,
make..): nhằm hỗ trợ biên dịch tốc độ cao, khả năng tối ưu
cao, khả năng khai thác các tập lệnh, kiến trúc phần cứng mới.
– Miền ứng dụng của ngôn ngữ
– Năng lực, kinh nghiệm của nhóm phát triển
– Yêu cầu của khách hàng
124
125. Lựa chọn ngôn ngữ lập trình
Các đặc trưng của ngôn ngữ lập trình sẽ quyết định miền
ứng dụng của ngôn ngữ. Miền ứng dụng là yếu tố chính để
chúng ta lựa chọn ngôn ngữ cho một dự án phần mềm.
Ngôn ngữ FORTRAN: có khả năng tính toán với độ chính
xác cao và thư viện toán học phong phú thường được sử
dụng trong các dự án phần mềm trong lĩnh vực khoa học
kỹ thuật.
COBOL: là ngôn ngữ cho ứng dụng kinh doanh và khai
thác CSDL lớn. Tuy nhiên, hiện nay các ngôn ngữ thế hệ
thứ tư đã dần dần chiếm ưu thế so với COBOL.
125
126. Lựa chọn ngôn ngữ lập trình
PASCAL và C: là ngôn ngữ hay được chọn cho việc phát
triển phần mềm hệ thống
LISP, PROLOG hay OPS5: là ngôn ngữ thường được
dùng trong các ứng dụng trí tuệ nhân tạo.
C++: Với đặc trưng hướng đối tượng, tính hiệu quả thực
hiện cũng như có nhiều công cụ và thư viện, C++ hiện
đang được sử dụng rộng rãi trong lĩnh vực phát triển các
ứng dụng nghiệp vụ.
Smalltalk, C++, Java: là các ngôn ngữ lập trình hướng đối
tượng được dùng rộng rãi nhất trong việc phát triển phần
mềm hướng đối tượng.
126
127. Java: là ngôn ngữ hướng đối tượng đang được sử
dụng rộng rãi cho phát triển các dịch vụ Web và
phần mềm nhúng vì các lý do độ an toàn cao, tính
trong sáng, tính khả chuyển và hướng thành phần.
ASP, JavaScript, PERL: là các ngôn ngữ biên
dịch (script) với những câu lệnh và thư viện
mạnh. Các ngôn ngữ này hiện đang được sử dụng
rộng rãi trong lập trình Web.
127
128. 3.3.4. Phong cách lập trình
Phong cách lập trình được coi là tốt khi:
– Tuân theo các chuẩn thông dụng
– Chú giải đầy đủ mỗi khi không tuân theo chuẩn
Tuân theo chuẩn:
– Cách đặt tên hàm và biến
– Cách xây dựng câu lệnh, cấu trúc chương trình
– Các viết chú thích
– Cách xử lý lỗi
Nhằm hướng tới phong cách làm cho mã nguồn:
dễ hiểu, dễ sửa đổi, an toàn (ít lỗi)
128
129. Cách đặt tên hàm và biến
Đặt tên biến, tên hàm có nghĩa, gợi nhớ
– Sử dụng các ký hiệu, từ tiếng Anh có nghĩa
– Viết tên hàm dễ đọc: ví dụ viết DateOfBirth thay cho
dateofbirth
– Tránh đặt tên quá dài
– Thống nhất cách dùng biến trong toàn bộ chương trình
129
130. Cách xây dựng cấu trúc chương trình
Chương trình cần được chia thành nhiều mô đun
(hàm). Không viết hàm quá dài:
– không quá 2 trang màn hình
– tạo ra các hàm thứ cấp để giảm độ dài từng hàm
– Không dùng quá nhiều biến cục bộ: vì lập trình viên
khó có thể theo dõi đồng thời hoạt động của nhiều biến
(thông thường một mô đun không quá 7 biến cục bộ).
130
131. Cách viết chú thích
Mọi thứ trong chương trình đều được chú thích:
– Mục đích sử dụng của các biến
– Chức năng của khối lệnh, câu lệnh
các lệnh điều khiển
các lệnh phức tạp
– Chú thích các mô đun
mục đích, chức năng của mô đun
tham số, giá trị trả lại (giao diện) - các mô đun thuộc cấp
cấu trúc, thuật toán
nhiệm vụ của các biến cục bộ - tác giả, người kiểm tra, thời
gian
131
132. Cách xử lý lỗi
Nhất quán trong xử lý lỗi:
– phân loại lỗi
– thống nhất định dạng thông báo lỗi,…
Có thể phát hiện lỗi trong khi thực hiện, ví dụ lỗi
chia cho 0
Các hàm thư viện nên tránh việc tự đưa ra thông
báo lỗi.
132
133. 3.4. Kiểm thử
3.4.1. Khái niệm
3.4.2. Các phương pháp kiểm thử
3.4.3. Các kỹ thuật kiểm thử
3.4.4. Các loại kiểm thử
3.4.5. Các hoạt động kiểm thử
133
134. 3.4.1. Khái niệm
Kiểm thử là một trong những giai đoạn quan
trọng trong phát triển phần mềm, là mấu chốt của
đảm bảo chất lượng phần mềm
Kiểm thử là tiến trình xem xét lại đặc tả, thiết kế
và mã hoá…nhằm phát hiện lỗi phần mềm.
Kiểm thử thành công khi phát hiện ra lỗi; kiểm
thử không phát hiện ra lỗi là kiểm thử dở (Theo
Sue A.Conger- The New SE)
134
135. 3.4.1. Khái niệm
Một phép thử được gọi là thành công nếu nó phát hiện ra
khiếm khuyết của phần mềm. Kiểm thử chỉ chứng minh
được sự tồn tại của lỗi trong hệ thống chứ không
chứng minh được hệ thống không có lỗi. Một phép kiểm
thử (ca kiểm thử) bao gồm
– tên của mô đun kiểm thử
– dữ liệu vào
– dữ liệu ra mong muốn (kết quả đúng)
– dữ liệu ra thực tế (khi đã tiến hành kiểm thử)
Các ca kiểm thử nên được thiết kế khi chúng ta tạo các tài
liệu phân tích và thiết kế, chứ không phải là khi đã viết
xong mã nguồn.
135
136. Những lưu ý khi kiểm thử
1) Chất lượng phần mềm do khâu thiết kế quyết
định là chủ yếu, chứ không phải khâu kiểm thử
(2) Tính dễ kiểm thử phụ thuộc vào cấu trúc chương
trình
(3) Người kiểm thử và người phát triển nên khác
nhau.
136
137. Những lưu ý khi kiểm thử
(4) Dữ liệu thử cho kết quả bình thường thì
không có ý nghĩa nhiều, cần có những dữ liệu
kiểm thử mà phát hiện ra lỗi.
(5) Khi thiết kế trường hợp thử, không chỉ dữ
liệu kiểm thử nhập vào, mà phải thiết kế trước cả
dữ liệu kết quả sẽ có.
(6) Khi phát sinh thêm trường hợp thử thì nên thử
lại những trường hợp thử trước đó để tránh ảnh
hưởng lan truyền sóng khi kiểm thử.
137
138. 3.4.2. Các phương pháp kiểm thử
Kiểm thử tĩnh
Kiểm thử trên máy
138
139. Kiểm thử tĩnh
Kiểm thử tĩnh (hay kiểm thử trên bàn): sử dụng
giấy và bút, kiểm tra logic, lần từng chi tiết ngay
sau khi lập trình xong. Kiểm thử tĩnh thường
được tiến hành trước nhằm tạo ra kịch bản cho
kiểm thử động. Có 2 kỹ thuật được sử dụng
– Đi xuyên suốt (walk through)
– Thanh tra (inspection)
139
140. Kiểm thử trên máy
Kiểm thử trên máy hay kiểm thử động: Dùng máy
chạy chương trình để điều tra trạng thái từng động
tác của chương trình.
9 bước của trình tự kiểm thử bằng máy:
(1) Thiết kế trường hợp thử theo kiểm thử tĩnh
(2) Trường hợp thử phải có cả kết quả kỳ vọng sẽ thu
được
(3) Dịch chương trình nguồn và tạo môđun tải để thực
hiện
140
141. (4) Khi trường hợp thử có xử lý tệp vào-ra, phải làm
trước trên bàn việc xác định miền của các tệp
(5) Nhập dữ liệu đã thiết kế cho trường hợp kiểm thử
(6) Điều chỉnh môi trường thực hiện môđun tải (tạo
thủ tục đưa các tệp truy cập tệp vào chương trình)
(7) Thực hiện môđun tải và ghi nhận kết quả
(8) Xác nhận kết quả với kết quả kỳ vọng
(9) Lặp lại thao tác (5)-(8)
141
142. 3.4.3. Các kỹ thuật kiểm thử
Kiểm thử hộp trắng hay kiểm thử cấu trúc
Kiểm thử hộp đen (black box testing) hay kiểm
thử chức năng (functional testing)
142
143. Kiểm thử hộp trắng
Kiểm thử hộp trắng (white box testing): sử dụng
các ca kiểm thử để kiểm tra mã nguồn ở mức các
mô đun đơn vị nhằm mục đích phát hiện ra các lỗi
trong các chi tiết thủ tục (thuật toán), các luồng
điều khiển, các trạng thái của chương trình (dữ
liệu).
Kiểm thử hộp trắng là sự kiểm thử dựa trên việc
phân tích chương trình. Kỹ thuật chính ở đây là
xác định đường đi của chương trình (điều khiển)
từ đầu vàô (input) đến đầu ra (output).
143
144. Kiểm thử hộp trắng
Mục đích của kiểm thử hộp trắng là kiểm tra
tất cả các đường đi có thể. Tức là đảm bảo mọi
lệnh đều được thực hiện ít nhất một lần trong
một ca thử nhiệm nào đó.
Kiểm thử hộp trắng chú trọng vào phân tích
các cấu trúc rẽ nhánh và các vòng lặp..
144
145. Kiểm thử hộp đen
Kiểm thử hộp đen (black box testing) hay kiểm
thử chức năng: sử dụng các ca kiểm thử được
thiết kế dựa trên đặc tả yêu cầu, tài liệu người
dùng nhằm mục đích phát hiện ra các khiếm
khuyết, các lỗi của từng mô đun chương trình và
toàn bộ hệ thống.
145
146. Kiểm thử hộp đen
Kiểm thử chức năng nhìn nhận mô đun được
kiểm thử như là một hộp đen, và chỉ quan tâm
đến chức năng (hành vi) của mô đun, tức là
kiểm tra xem có hoạt động đúng với đặc tả hay
không.
Các ca kiểm thử bao gồm các trường hợp bình
thường và không bình thường (dữ liệu không
hợp lệ...) của mô đun.
146
147. 3.4.4. Các loại kiểm thử
1. Kiểm thử đơn vị: là bước kiểm thử đối với từng
chức năng (hàm) nhằm mục đích chính phát hiện
lỗi lập trình. Người ta thường sử dụng nhiều
kiểm thử cấu trúc.
2. Kiểm thử mô đun: là hình thức kiểm thử từng
mô đun riêng lẻ hoặc có thể liên kết với một số
hàm, mô đun khác có liên quan.
3. Kiểm thử hệ con: nếu hệ thống bao gồm một số
hệ con độc lập thì đây là bước tiến hành kiểm
thử với từng hệ con riêng biệt.
147
148. 3.4.4. Các loại kiểm thử
4. Kiểm thử hệ thống (tích hợp): kiểm thử sự hoạt
động tổng thể hệ thống, kiểm tra tính đúng đắn
của giao diện, tính đúng đắn với đặc tả, và tính
dùng được. Chủ yếu sử dụng kiểm thử chức
năng.
5. Kiểm thử thu (alpha): kiểm thử được tiến hành
bởi một nhóm nhỏ người sử dụng dưới sự hướng
dẫn của người phát triển, sử dụng các dữ liệu
thực, thẩm định tính dùng được của hệ thống.
148
149. 3.4.4. Các loại kiểm thử
6. Kiểm thử beta: là mở rộng của kiểm thử alpha,
được tiến hành với một số lớn người sử dụng
không có sự hướng dẫn của người phát triển,
kiểm tra tính ổn định, điểm tốt và không tốt của
hệ thống.
149
150. 3.4.5. Các hoạt động kiểm thử
Bắt đầu
Lập kế hoạch Lập kế hoạch Test
Thiết kế Test
Chuẩn bị
Cài đặt và chuẩn bị
Test
Test tích hợp
Test Xem xét và Đánh
giá kết quả test
Test hệ thống Phân tích kết quả
Tổng hợp, báo cáo
Kết thúc
150
151. 3.4.5. Các hoạt động kiểm thử
Bắt đầu
Lập kế hoạch Test Kế hoạch test
Test case
Thiết kế Test
Test procedure
Test scrip
Cài đặt và chuẩn bị
Test data
Test
Môi trường
Test tích hợp
Lỗi Xem xét và Đánh giá Bcáo KQ test
Biên bản test kết quả test Đề xuất
Test hệ thống
Tổng hợp, báo cáo
Bcáo tổng hợp test
Hồ sơ
Kết thúc
151
152. 3.4.5. Các hoạt động kiểm thử
Bắt đầu Initiation (khởi động)
Definition (Xác định yêu cầu)
Definition Lập kế hoạch Test Xác định yêu cầu
Solution Thiết kế kiến trúc Solution (Thiết kế kiến trúc)
Thiết kế Test
Cài đặt và chuẩn bị Construction (Xây dựng)
Construction Lập trình
Test
Coding (lập trình)
Construction Thử nghiệm
Test tích hợp
Xem xét và Đánh giá Testing (thử nghiệm)
kết quả test
Test hệ thống
Tổng hợp, báo cáo
Kết thúc Transition (Triển khai)
Termination (Kết thúc)
152
153. 3.5. Cài đặt phần mềm
3.5.1. Lập kế hoạch cài đặt
3.5.2. Biến đổi dữ liệu
3.5.3. Biên soạn tài liệu hệ thống
153
154. 3.5.1. Lập kế hoạch cài đặt
Từ HTTT cũ sang HTTT mới, cần phải:
Chuyển đổi phần cứng
Chuyển đổi phần mềm
Chuyển đổi cơ sở dữ liệu
Chuyển đổi công nghệ quản lý
Chuyển đổi hệ thống biểu mẫu (thông dụng)
Chuyển đổi các phương pháp truyền đạt thông tin
Chuyển đổi các phương thức lưu trữ dữ liệu, thông tin
Chuyển đổi tác phong của lãnh đạo và các nhân viên
154
155. 3.5.1. Lập kế hoạch cài đặt
Trong quá trình lập kế hoạch cài đặt, việc
chuyển đổi kỹ thuật tương đối đơn giản.
Tuy nhiên, việc chuyển đổi về con người
tương đối phức tạp và kéo dài do sức ỳ và
tâm lý ngại thay đổi của người sử dụng.
Vì vậy, phải lập kế hoạch chuyển đổi tỷ
mỷ, bao quát tất cả các lĩnh vực của hệ
thống thông tin.
155
156. 3.5.2. Biến đổi dữ liệu
Dữ liệu giữa hai hệ thống cũ và mới thường
không tương thích với nhau về phương thức lưu
trữ cũng như quy cách truy cập. Do đó rất dễ dẫn
đến sai sót khi biến đổi dữ liệu.
Qúa trình biến đổi dữ liệu:
Xác định khối lượng và chất lượng của dữ liệu
(độ chính xác, tính đầy đủ và thứ tự).
Làm ổn định một bản dữ liệu và tổ chức những
thay đổi cho phù hợp.
156
157. 3.5.2. Biến đổi dữ liệu
Qúa trình biến đổi dữ liệu:
Tổ chức và đào tạo đội ngũ thực hiện
công việc biến đổi dữ liệu.
Lập lịch thời gian của quá trình biến
đổi dữ liệu.
Bắt đầu quá trình biến đổi dữ liệu
dưới sự chỉ đạo thống nhất.
157
158. 3.5.2. Biến đổi dữ liệu
Thực hiện những thay đổi trong các tệp dữ liệu;
Nếu trong hệ thống cũ có các tệp dữ liệu thì tốt
nhất tổ chức biến đổi các tệp dữ liệu này trước,
sau đó mới đến các tệp mới chuyển từ phương
thức tổ chức thủ công sang.
Thực hiện bước kiểm chứng lần cuối cùng để
đảm bảo các tệp dữ liệu đã biến đổi phù hợp với
các yêu cầu của hệ thống quản lý mới.
158
159. 3.5.3. Biên soạn tài liệu hệ thống
Một phần mềm khi được chuyển giao cho phía
khách hàng (người sử dụng) thường kèm theo 2
loại tài liệu sau:
– Tài liệu hướng dẫn sử dụng, thông tin được thu thập
từ các nguồn khác nhau bao gồm các báo cáo xác
định vấn đề, nghiên cứu tính thức thi, đề xuất hệ
thống và
– Tài liệu kỹ thuật cho người lập trình và bảo trì hệ
thống.
159
160. 3.6. Bảo trì phần mềm
Là pha cuối cùng của vòng đời hệ thống
Các hoạt động cần thực hiện
– Quản lý hoạt động bảo trì
– Chuẩn hóa hoạt động bảo trì (IEEE 840-1992)
160
161. Các hoạt động bảo trì phần mềm
Các yêu
cầu bảo
trì
Chăm sóc Yêu cầu
Khách hàng khách hàng bảo trì được đề xuất
Yêu cầu
bào trì
được chấp nhận
Ban quản lý thay đổi
Kỹ sư bảo trì Mã nguồn
& tài liệu hiện thời
Mã nguồn
& tài liệu đã được sửa
161
162. Các hoạt động bảo trì phần mềm
Marketing
Các yêu
cầu bảo
trì
Chăm sóc Yêu cầu
Khách hàng khách hàng bảo trì được đề xuất
Quản lý
bảo trì
Yêu cầu
bào trì
được chấp nhận
Ban quản lý thay đổi
Kỹ sư bảo trì Mã nguồn
& tài liệu hiện thời
Yêu cầu bị
Mã nguồn
từ chối
& tài liệu đã được sửa
162
163. Các hoạt động bảo trì phần mềm
Các công việc cần thực hiện:
1. Hiểu kĩ yêu cầu bảo trì
2. Phân loại yêu cầu: sửa đổi hay nâng cấp?
3. Thiết kế các sửa đổi được yêu cầu
4. Kế hoạch chuyển đổi từ thiết kế cũ
5. Đánh giá các ảnh hưởng của sửa đổi lên ứng dụng
6. Triển khai các sửa đổi
7. Thực hiện các kiểm thử đơn vị cho các phần thay đổi
8. Tiến hành kiểm thử tăng dần, thực hiện kiểm thử hệ thống
với các khả năng mới
9. Cập nhật các tài liệu cấu hình, yêu cầu, thiết kế và
kiểm thử.
163
164. Ví dụ về chi phí hoạt động bảo trì
Đánh
Đánh giá
giá
Hoạt động (person- Hoạt động
(person-
days) days)
1. Hiểu yêu cầu và xác định
chức năng cần sửa đổi hay 2-5 6. Dịch và tích hợp 2-3
thêm vào
7. Kiểm thử chức năng
2. Thay đổi thiết kế 1-4 2-4
thay đổi
3. Phân tích ảnh hưởng trình
1-4 8. Kiểm thử trình diễn 2-4
diễn
4. Triển khai các thay đổi 9. Đưa ra bản mới và
1-4 1
thành mã nguồn báo cáo kết quả
5. Thay đổi thông tin cấu hình 2-6 TỔNG 14 - 35
164
165. Chuẩn hóa hoạt động bảo trì
Hiện nay, chuẩn IEEE 840-1992 thường được
dùng trong các hoạt động bảo trì phần mềm.
Các bước bảo trì phần mềm theo chuẩ 840-1992
1. Xác định vấn đề
2. Phân tích
3. Thiết kế
4. Triển khai
5. Kiểm thử hệ thống
6. Kiểm thử chấp nhận
7. Chuyển giao phần mềm
165
166. Ví dụ bảo trì phần mềm đối với giai đoạn thiết kế
•Tài liệu dự án gốc
a. Đầu vào
•Các phân tích từ pha trước
•Tạo ra các trường hợp kiểm thử (test cases)
b. Tiến trình
•Duyệt (các yêu cầu; kế hoạch triển khai)
c. Điều khiển •Kiểm chứng thiết kế
•Kiểm tra thiết kế và các trường hợp kiểm thử
•Duyệt( các sửa đổi; phân tích chi tiết; kế hoạch triển khai)
d. Đầu ra •Cập nhật(thiết kế gốc; kế hoạch kiểm thử)
•Độ linh hoạt (của thiết kế)
e. Nhân tố chất •Khả năng lần vết (traceability)
lượng liên quan •Khả năng sử dụng lại (Reusability)
•Khả năng có thể hiểu (Comprehensibility)
•Chi phí người-giờ
f. Độ đo •Thời gian
•Số lượng tiếp nhận thay đổi 166
167. Câu hỏi ôn tập
1. Nhiệm vụ chính của giai đoạn phân tích và đặc tả
yêu cầu? Các công việc cần thực hiện? Các tài liệu
cần bàn giao sau giai đoạn phân tích và đặc tả yêu
cầu?
2. Các mô hình sử dụng trong quá trình phân tích và
đặc tả yêu cầu?
3. Trình bày tầm quan trọng của thiết kế giao diện khi
xây dựng phần mềm. Những điểm cần chú ý trong
thiết kế giao diện
4. Các nguyên tắc thiết kế tập tin dữ liệu, những lưu ý
khi thiết kế tập tin dữ liệu là gì?
167
168. Câu hỏi ôn tập
5. Người phát triển lựa chọn ngôn ngữ lập trình
dựa trên những yếu tố nào? Phong cách lập trình
ảnh hưởng tới chất lượng phần mềm như thế
nào?
6. Trình bày các hoạt động kiểm thử phần mềm?
7. Những lưu ý trong quá trình lập kế hoạch cài đặt
phần mềm?
8. Bảo trì phần mềm là gì? Hoạt động nào trong
bảo trì phần mềm là chính yếu ?
168
