Bài giảng công nghệ phần mềm nguyễn thanh bình

spiral model Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototype 3 Opera-tional protoype Concept of Operation Simulations, models, benchmarks S/W

Chương 1: Giớ i thi ệ u Công ngh ệ ph ầ n m ề m

Chương 2: Các mô hình phát triể n ph ầ n m ề m

Chương 3: Phân tích và ñặ c t ả yêu c ầ

M Gaudel, B Marre, F Schlienger, G Bernot, Précis de

génie logiciel, Masson, 2001

Stephen R Schach, Classical and Object-Oriented Software

Engineering, NXB IRWIN, 1996

Ronald Leach, Introduction to Software Engineering, CRC

Press, 1999

G Booch, J Rumbaugh, I Jacobson, The Unified Modeling

Language User Guide, Addision-Wesley, 1999

Craig Larman, Applying UML and Patterns: An Introduction

to Object-Oriented Analysis and Design and Iterative

Development, Third Edition, Addision-Wesley, 2004

Glenford J Myers, The art of software testing, Wiley, 2004

Boris Beizer, Software Testing Techniques, Second Edition

Công ngh ệ ph ầ n m ề m

 nghiên c ứ u và phát tri ể n các ph ươ ng pháp,

k ĩ thu ậ t và công c ụ nh ằ m xây d ự ng các

Các nguyên t ắ c c ơ b ả n

 Ch ặ t ch ẽ (rigor and formality)

 Chia nh ỏ (separation of concerns)

 Mô- ñ un hóa (modularity)

 Tr ừ u t ượ ng (abstraction)

 Phòng ng ừ a s ự thay ñổ i (anticipation of

change)

 T ổ ng quát hóa (generality)

 Gi ả i quy ế t t ừ ng b ướ c (incrementality)

Ch ặ t ch ẽ (rigor and formality)

 s ử d ụ ng mô hình lý thuy ế t và toán h ọ c

• Giải quyết một phần nhỏsẽ ñơn giản hơn

• “chia ñểtrị” (divide and conquer)

 Quan hệmật thiết với nguyên tắc “chia nhỏ”

 Các phương pháp mô-ñun hóa

• chiến lược từtrên xuống (top-down)

• chiến lược từ dưới lên (bottom-up)

 Chất lượng của mô-ñun hóa

• liên kết lỏng lẻo (low coupling)

• kết cốcao (high cohesion)

• mô hình cho người sửdụng

• mô hình cho ngưới phát triển

T ổ ng quát hóa (generality)

 xem xét v ấ n ñề trong ng ữ c ả nh t ổ ng quát

• cài ñặ t các thi ế t k ế b ng ngôn ng ữ l ậ p trình

• không ñơ n thu ầ n ch ỉ là l ậ p trình

• vi ế t tài li ệ

• insertions/invariants

• chu ẩ n l ậ p trình (coding standards)

• l ậ p trình theo c ặ p (pair programming)

• nguồn tài nguyên kiểm thử

 mã nguồn ñược kiểm thửtheo tài liệu thiết kế

 Sản phẩm: báo cáo kiểm thử

• mong ñợi không thực tếvềtiến triển của dựán

 ng ườ i phát tri ể n có s ự ch ọ n l ự a không t ố t

• phù hợp cho nguyên mẫu, nhưng không phù hợp

Phiên bản

ñầu tiên

Phiên b ả n trung gian

(spiral model)

Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototype 3 Opera-tional

protoype

Concept of Operation

Simulations, models, benchmarks S/W

requirements Requirement validation Design V&V

Product design Detailed design Code Unit test Integration test Acceptance test Service Develop, verify

next-level product

Evaluate alternatives identify, resolve risks

Development plan

Requirements plan Life-cycle plan REVIEW

nhấn mạnh việc ñánh giá các rủi ro

phần mềm ñược xây dựng theo nhiều chu kỳ

mỗi chu kỳ tương ứng với một sản phẩm của một giai

ñ ạn phát triển phần mềm

 xác ñịnh các mục tiêu, giải pháp, ràng buộc

 ñánh giá các giải pháp, xác ñịnh các nguy cơ và tìm

cách giải quyết chúng

 phát triển và kiểm thửsản phẩm của chu kỳnày

 lập kếhoạch cho chu kỳti p theo

 th ờ i gian bi ể u và ngân sách không th ự c t ế

• ñ ánh giá th ậ t chi ti ế t, phát tri ể n d ầ n d ầ n, tái s ử d ng, lo ạ i b ỏ ớ t các

yêu c ầ u không c ầ n thi ế t

 phát tri ể n các ch ứ c n ă ng không phù h ợ p

• trao ñổ i th ườ ng xuyên v ớ i ng ườ i s ử d ng, có tài li ệ u h ướ ng d ẫ n s ử

d ng s ớ m

 phát tri ể n giao di ệ n ng ườ i dùng không thích h ợ p

• c ầ n phân tích các công vi ệ c, xây d ự ng các hình m ẫ u tr ướ c,

 thi ế u yêu c ầ u ñặ t ra

• phát tri ể n các ph ầ n ổ n ñị nh tr ướ c

 v ấ n ñề v ề hi ệ u qu ả

• c ầ n ph ả i mô ph ỏ ng, ño lườ ng, th ử nghi ệ m

 ñ òi h ỏ i v ượ t quá s ự ñ áp ứ ng c ủ a công ngh ệ hiên hành

• phân tích k ỹ tính kh ả thi v ề m ặ t k ỹ thu ậ t

Góc nhìn k ỹ thu ậ t: quan tâm ñến

công nghệ, kiểm tra chất lượng,

Phiên bản β

Phiên bản β

Bước lặp chuyển giao

Bước lặp chuyển giao

Bước lặp phát triển

Mẫu thử (maquette)Nguyên mẫu kiến trúcNguyên mẫu kiến trúcNguyên mẫu phát triểnNguyên mẫu phát triển

Phiên bản chính thứcPhiên bản β

Bước lặp Kết quả

Phiên bản β

Giai ñoạn

Khởi ñầuSoạn thảo

Xây dựng

Chuyển giao

Các b ướ c phân tích và ñặ c t ả yêu c ầ u

 Phân tích bài toán

 Thu th ậ p yêu c ầ u

 Phân tích yêu c ầ u

 ðặ c t ả yêu c ầ u

 H ợ p th ứ c hóa yêu c ầ u

m ứ c tr ừ u t ượ ng r ấ t cao v ề d ị ch v ụ hay h ệ

th ố ng cho ñế n m ộ t ñặ c t ả toán h ọ c r ấ t chi

Client man ag ers

Sy stem end -us ersClient en gineers

Co ntracto r man ag ers

Sy stem architects

Sy stem end -us ersClient en gineers

Sy stem architects

So ftware d ev elo pers

Client en gineers (perh ap s)

phát triển áp dụng, yêu cầu cài ñặt,

Yêu cầu bên ngoài

 yêu cầu ñến từcác yêu tốbên ngoài hệthống và tiến

trình phát triển: yêu cầu vềkhả năng tương tác, về

ñạo ñức,

Po rtability requ irement s

Intero perability requirements

Ethical requ irement s

Leg islative requ irements Implementatio n

requ ir ements

Stand ards requ irements Delivery

requ irements

Safety requ irements Priv acy

requ irements

Pro du ct requ ir ements

Or g an izatio nal requ ir ements

Ex ternal requ irement s

No n-fu nctio nal requ ir ements

• tiến trình phát triển phải ñáp ứng chuẩn DO178

 Yêu c ầ u bên ngoài

• hệ thông không ñược ñểlộthông tin cá nhân của khách hàng

ð o l ườ ng yêu c ầ u

Property Measure

Speed Processed transactions/second

User/Event response time Screen refresh time

Robustness Time to restart after failure

Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements

Number of target systems

 không có ki ế n th ứ c chi ti ế t v ề k thu ậ t/tin h ọ c

yêu c ầ u ng ườ i s ử d ụ ng nên ñượ c mô t ả

b ở i:

 ngôn ng ữ t ự nhiên

 bi ể u ñồ , b ả ng bi ể u

2.7 Assumptions and Dependencies

3 External Interface Requirements

5 Other Nonfunctional Requirements

5.1 Performance Requirements 5.2 Safety Requirements 5.3 Security Requirements 5.4 Software Quality Attributes 5.5 Business Rules

6 Other Requirements Appendix A: Glossary Appendix B: Analysis Models Appendix C: To Be Determined List

 mô t ả các lu ồ ng nghi ệ p v ụ , các x ử lý và vai

trò c ủ a con ng ườ i trong h ệ th ố ng hi ệ n t ạ i

Phỏng vấn khách hàng

Thực hiện các hội thảo/thảo luận

Chuẩn bị các bảng câu hỏi ñiều tra

Quan sát hoạt ñộng nghiệp vụ hiện tại

Tham khảo các chuyên gia trong lĩnh

tổ chức các buổi thảo luận

trình bày các yêu cầu của hệ thống

cần phát triển

• khách hàng có hi ể u yêu c ầ u ?

khuyến khích ý kiến của khách hàng

 quay phim các nghiệp vụ

Tham khảo các chuyên gia trong lĩnh vực

 hiểu rỏcác nghiệp vụchuyên môn phức tạ

Yêu c ầ u phi ch ứ c n ă ng th ườ ng không l ộ rõ

 th ườ ng do ng ườ i phát tri ể n ñề xu ấ t

L ỗ i ở bướ c ñặ c t ả yêu c ầ u chi phí r ấ t l ớ n

 chi phí s ử a m ộ t l ỗ i yêu c ầ u sau khi ñ ã giao

s ả n ph ẩ m có th ể l ớ n g ấ p 100 l ầ n l ỗ i cài ñặ t

K ỹ thu ậ t nguyên m ẫ u r ấ t hi ệ u qu ả ñể h ợ p

th ứ c hóa yêu c ầ u

ðiều kiện trước và sau

Kiểu trừu tượng

ðặc tả Z

S ố ñ úng

S ố sai

B ấ m s ố

K ế t n ố ñượ c

t1

một thẻ, thì chuyển tiếp này là có thểvượt qua ñược,

 n u chuyển tiếp này ñược thực hiện thì tất cảcác nút

vào của chuyển tiếp sẽbị ấy ñi một thẻ, và một thẻ

sẽ ñược thêm vào tất cảcác nút ra của chuyển tiế

 n u nhiều chuyển tiếp là có thể vượt qua thì chọn

chuyển tiếp nào cũng ñược

hoặc t3 ñược vượt qua

hoặc t4 ñược vượt qua

rg2red2

yellow2yr2

gy2safe2

safe1

Ví d ụ 2: mô t ả chu k ỳ s ố ng c ủ a m ộ t ng ườ i

thanh niêntrẻ con

send_mail

read_mail

Mô tả trường hợp 1 người viết và 2 người ñọc ?

Ví d ụ 4: tình hu ố ng ngh ẽ n (dead-lock)

2 2

P6

P4

P3 P1

Ví d ụ 4: gi ả i pháp ch ố ng ngh ẽ

2 2

P6

P4

P3 P1

S ả n xu ấ t

P2

C2 C1

 pre-condiition: ñặc tảcác ràng buộc trên các tham

sốtrước khi hàm ñược thực thi

 post-condition: ñặc tảcác ràng buộc trên các tham

sốsau khi hàm ñược thực thi

có thểsửd ng ngôn ngữphi hình thức, hình thức

hoặc ngôn ngữlập trình ñể ñặc tảcác ñiều kiệ

pre ∀i, 1 ≤i ≤n, a[i] ≤a[i+1]

post result = (∃i, 1 ≤i ≤n, a[i] = e)

¬_ : Boolean →Boolean _ ∧∧∧∧_ : Boolean x Boolean →Boolean _ ∨∨∨∨_ : Boolean x Boolean →Boolean

một thao tác không có tham sốlà một hằng số

một giá trịcủa kiểu trừu tượng ñịnh nghĩa ñược biểu diễn bởi kí tự“_”

¬_ : Boolean →Boolean _ ∧∧∧∧_ : Boolean x Boolean →Boolean _ ∨∨∨∨_ : Boolean x Boolean →Boolean

một thao tác không có tham sốlà một hằng số

một giá trịcủa kiểu trừu tượng ñịnh nghĩa ñược biểu diễn bởi kí tự“_”

vect : Integer x Integer →Vector

init : Vector x Integer →Boolean

ith : Vector x Integer →Element

change-ith : Vector x Integer x Element →Vector

supborder : Vector →Integer

infborder : Vector →Integer

infborder(v) ≤≤≤≤i ≤≤≤≤supborder(v) ⇒ith(change-ith(v, i, e), i) = e

infborder(v) ≤≤≤≤i ≤≤≤≤supborder(v) &infborder(v) ≤≤≤≤j ≤≤≤≤supborder(v) &i ≠≠≠≠j ⇒

ith(change-ith(v, i, e), j) = ith(v, j)

init(vect(i, j), k) = false

infborder(v) ≤≤≤≤i ≤≤≤≤supborder(v) ⇒init(change-ith(v, i, e), i) = true

infborder(v) ≤≤≤≤i ≤≤≤≤supborder(v) &i ≠≠≠≠j ⇒init(change-ith(v, i, e), j) = init(v, j)

 các s ơ ñồ thao tác (operation schemas)

• mô tảcác thao tác (thay ñổi trạng thái)

 các toán t ử sơ ñồ (schema operations)

Khởi gán biế

Khai báo thao tác trên biế

 kí hiệu ∆biểu diễn biến trạng thái bị thay ñổi bởi thao

tác

 kí hiệu ‘ (dấu nháy ñơn) biểu diễn giá trịmới của biế

Thao tác có thểcó các tham sốvào và ra

 tên tham sốvào kết thúc bởi kí tự“?”

 tên tham sốra kết thúc bởi kí tự“!”

• tập hợp các nhân viên ñang vào in

• tập hợp các nhân viên ñang ra out

bất biến của hệthống

ðặ c t ả thao tác ki ể m tra m ộ t nhân viên vào hay ra

 Thao tác này cho kết quảlà phần tửcủa kiể

QueryReply == is_in | is_out

 ðặc tảthao tác

Kh ở i t ạ o h ệ th ố ng

• ðiều kiện trên các tham sốvào

• Quan hệgiữa trạng thái trước và sau

• Tham sốkết quả

 Kh ở i gán

Hãy ñặ c t ả các thao tác

 Register: thêm vào m ộ t nhân viên m ớ i

 QueryIn: cho bi ế t nh ữ ng nhân viên ñ ang

vào/làm vi ệ c

 Schema3 == Schema1 ∧Schema2

 Schema4 == Schema1 ∨Schema2

Ví d ụ 1 (ti ế p)

C ả i ti ế n thao tác CheckIn

 X ử lý thêm hai trườ ng h ợ p l ỗ i

1 name? ñã ñược ghi nhậ

2 name? chưa ñược ñăng ký

Ví d ụ 1 (ti ế p)

C ả i ti ế n thao tác CheckIn

 X ử lý thêm hai trườ ng h ợ p l ỗ i

dom(directory) = {mary, john, jim, jane}

 tập hợp các thành phần thứhai trong một quan hệ

Tìm s ố ñiệ n tho ạ i c ủ a m ộ t ng ườ i

Tìm tên theo s ố ñiệ n tho ạ i

có thểcải tiến ?

Xóa s ố ñiệ n tho ạ i c ủ a m ộ t ng ườ i

Xóa các m ụ c trong danh b ạ ứ ng v ớ i m ộ t tên

Xóa các m ụ c trong danh b ạ ứ ng v ớ i m ộ t t ậ p các

tên

Partial Function

là quan h ệ mà m ỗ i ph ầ n t ử trong domain cho m ộ t

giá tr ị duy nh ấ t trong range

Tìm ngày sinh c ủ a m ộ t ng ườ i

 thông báo khi tìm thấy

 khi ñ

Tìm nh ữ ng ng ườ i cùng ngày sinh

• có thể ñược thực hiện bởi nhiều mức trừu tượng

Component design

Data structure design

Algorithm design

Algorithm specification

Requirements

specification

Design activities

Design products

D ự báo thay ñổ i là khó khăn

 s ự thay ñổ i th ườ ng không ñượ c xác ñị nh

Thi ế t k ế hướ ng mô- ñ un

Ph ầ n m ề m là t ậ p h ợ p g ồ m các mô- ñ un

t ươ ng tác v ớ i nhau

Mô- ñ un hóa ñ óng vai trò quan tr ọ ng ñể có

ñượ c ph ầ n m ề m ch ấ t l ượ ng v ớ i chi phí th ấ p

Các tiêu chu ẩ n ñể ñ ánh giá m ộ t ph ươ ng

pháp thi ế t k ế hướ ng mô- ñ un

 tính phân rã (modular decomposability)

 tính t ổ ng h ợ p (modular composability)

 tính d ễ hi ể u (modular understandability)

 tính liên t ụ c (modular continuity)

 tính b ả o v ệ (modular protection)

 các ph ươ ng pháp thi ế t k ế t ừ trên xu ố ng

(to-down design) th ỏ a mãn tiêu chu ẩ n này

tính liên t ụ c (modular continuity)

 m ộ t s ự thay ñổ i trong ñặ c t ả yêu c ầ u ch ỉ d ẫ n

ñế n s ự thay ñổ i trong m ộ t (ho ặ c m ộ t s ố ít)

tính b ả o v ệ (modular protection)

 ki ế n trúc ñươ c thi ế t k ế sao cho n ế u m ộ t ñ i ề u

ki ệ n b ấ t th ườ ng x ả y ra, ch ỉ m ộ t (ho ặ c m ộ t s ố

 chia s ẽ d ữ li ệ u: mô hình “Repository”

 chia s ẽ d ị ch v ụ , servers: mô hình

“Client-Server”

 mô hình l ớ p (layered model)

 mô hình phân tán: d ữ li ệ u và x ử lý ñượ c

phân tán trên nhi ề u thành ph ầ n khác nhau

đóng gói, che dấu thông tin làm cho

hệ thống tin cậy hơn

Thừa kế làm giảm chi phắ, hệ thống có

tắnh mở cao hơn

Xây dựng hệ thống lớn và phức tạp

ðố i t ượ ng : tr ạ ng thái

Mỗi thuộc tính mô tả một ñặc tính

Tại một thời ñiểm cụ thể, các thuộc

tính mang các giá trị trong miền xác

Phương thức: là một thao tác hoặc

ñược thực hiện bởi chính nó, hoặc

thực hiện khi có yêu cầu từ môi

trường (thông ñiệp từ ñối tượng khác)

Hành vi phụ thuộc vào trạng thái

Ví dụ:

• m ộ t xe máy có các hành vi: kh ở i ñộ ng,

ch ạ y, …

Giao ti ế p gi ữ a các ñố i t ượ ng

Các ñố i t ượ ng giao ti ế p v ớ i nhau

 G ử i thông ñ i ệ p (message) cho nhau

changeAge

 Ng ă n c ả n s ự truy c ậ p thông tin t ừ bên ngoài

 Che d ấ u thông tin

 T ổ ng quát hóa/chuyên bi ệ t hóa

• Tổng quát hóa (generalization): ñặt các tính chấ

chung của các lớp khác nhau vào một lớp cha

• Chuyên biệt hóa (specialization): tạo ra một lớp

ðơn thừa kế: một lớp con chỉthừa kếtừmột lớp cha duy

nhất

Lớp trừu tượng hay lớp chung: XeÔtô

Lớp cụthểhay lớp chuyên biệt: XeKhách

Lớp chuyên biệt có thểthay thếlớp chung trong tất cả

Teacher

Student

Phd candidateReseacher

Tiết kiệm thời gian xây dựng, tránh

lặp lại thông tin

cha, và các ph ươ ng th ứ c này có th ể ñượ c s ữ a ñổ i

trong l ớ p con ñể th ự c hi ệ n các ch ứ c n ă ng riêng

trong l ớ p ñ ó

M ộ t ph ươ ng th ứ c (cùng m ộ t tên ph ươ ng th ứ c) có

nhi ề u d ạ ng ( ñị nh ngh ĩ a) khác nhau trong các l ớ p

C ầ n phân bi ệ t các m ụ c tiêu c ủ a ng ườ i s ử d ng và

các t ươ ng tác c ủ a h ọ v ớ i h ệ th ố ng

 Mục tiêu: cái mà người sửd ng mongñợi

 Tương tác: kỹthuật cho phépñápứng mục tiêu

Ví d ụ

 Mục tiêu: cóñược một văn bản trình bàyñẹp

 Tương tác: chọnñịnh dạng trang, chọn font chữ, ñịnh

tiêu nào của người sửd ng.

Mục tiêu của người sửd ng là “Rút tiền”, vậyñó nên

là một ca sửd ng

Tác nhân (Actor)

Tác nhânñóng vai trò một người sửd ng hoặc một

thực thểbên ngoài tương tác với hệthống

 Nhiều người sửd ng có thểtươngứng một tác nhân:

nhiều người bán hàng khác nhauñóng cùng vai trò

ñối với hệthống

 Một người sửd ng có thểtươngứng với nhiều tác

nhân khác nhau: cùng một người có thể ñồng thời

Tác nhân

 Mô tả: Một khách hàng sau khiñã chọn các mặt hàng,

mang giỏhàngñến quầy thu tiền Người bán hàng ghi nhận

các mặt hàng, thông báo tổng sốtiền, thu tiền và trảtiền

còn lại cho khách hàng Khách hàng mang hàngñi

ðặ c t ả ca s ử d ụ ng

ðặc tảca sửd ng có thểthêm:

 Tham chi ế u (reference) ñế n m ụ c liên quan trong ñặ c t ả yêu c ầ

 ð i ề u ki ệ n tr ướ c và ñ i ề u ki ệ n sau khi th ự c hi ệ n ca s ử d ng

 Ca sửd ng: Mua hàng

 Các tác nhân: Khách hàng, Người bán hàng

 Tham chiếu: R1.2, R2.3

 ðiều kiện trước: Ngườ i bán hàng ñ ñă ng nh ậ p thành công.

 ðiều kiện sau: Các mặ t hàng bán ñ ñượ c ghi nh ậ n và ñ ã ghi

nh ậ n thanh toán ti ề n.

 Mô tả : M ột khách hàng sau khiñ ã ch ọ n các m ặ t hàng, mang gi ỏ

hàng ñế n qu ầ y thu ti ền Người bán hàng ghi nhậ n các m ặ t hàng,

thông báo t ổ ng s ố ti ề n, thu ti ề n và tr ả ti ề n còn l ạ i cho khách hàng