PHẦN 2:Chu trình sống của phần mềm /Tiến trình phát triển phần mềm       TS. TRẦN CAO ĐỆ           NĂM 2010
Các bước chính trong tiến trình PM               Bài toán  Tìm hiểu yêu cầu                             Đặc tả yêu cầu    ...
Chương 9:    Đặc tả yêu cầuRequirement Engineering
1. Khái niệm đặc tả yêu cầu• The hardest single part of       •   Nội dung đặc tả  building a system is                  –...
2. Yêu cầu về tài liệu đặc tả yêu cầu• Tài liệu đặc tả phải đáp ứng:   – rõ ràng và dễ hiểu đối với khách hàng (dễ thuyết ...
3. Nội dung đặc tả• Phần mềm:                           • Con người: các lớp   – Môi trường làm việc của            người ...
4. Hình thức đặc tả• Dùng ngôn ngữ tự nhiên   – Ngữ nghĩa không rõ ràng, thường có nhiều lỗi     xảy ra   – Ngôn ngữ tự nh...
Case study - Thảo luận• Viết đặc tả yêu cầu cho “hệ thống QL thư  viện”   – Nhóm các user       •   Người thủ thư       • ...
5. Ba bước chính trong đặc tả yêu cầu                                                                         User• Nắm bắ...
6. Phát biểu yêu cầu•   Các yêu cầu phải được phát        • Vai trò người phân tích:    biểu tường minh và tài liệu hóa   ...
7. Các kỹ thuật dùng để phát biểu yêu cầuCÔNG NGHỆ PHẦN MỀM    TS. TRẦN CAO ĐỆ   2010   Trang 11
8. Tài liệu đặc tả yêu cầu•   Tài liệu đặc tả: là sp cuối cùng         – Thay đổi được    của bước đặc tả, là đầu vào     ...
Tài liệu đặc tả yêu cầu (tt)•   Phần 3 “specific requirements”    là phần dài nhất trong tài liệu,    bao trùm nhiều khía ...
9. Kỹ thuật đặc tả yêu cầu•   Tài liệu đặc tả yêu cầu phục vụ        •   Mô hình thực thể quan hệ    cho:     – Người dùng...
Ví dụ về bộ điều khiển an toàn (két sắt)•   J = {Khóa an toàn, A, B, Không khóa an toàn, Chuông báo động }•   K = {1T, 1P,...
Phân tích•   Phân tích là bước trung gian giữa         •   Kết quả của giai đoạn phân    đặc tả và thiết kế               ...
10. Đặc tả các yêu cầu phi chức năng•   Yêu cầu phi chức năng (non-               •   Các yêu cầu phi chức năng đôi khi   ...
11. kiểm tra (verification) và            kiểm tra-xác nhận (validation)• Tài liệu đặc tả phải được:         • Bằng việc k...
Tổng kết chương• Đặc tả yêu cầu:                   • Công cụ để mô tả vấn đề:   – Làm rõ yêu cầu của bài             – Ngô...
Chương 10:Kiến trúc phần mềmSoftware architecture
1. Thiết kế kiến trúc• Xây dựng PM = xây dựng hệ thống                     có thiết  kế    kiến trúc pm.• Kiến trúc = thiế...
Ví dụ một hệ thống máy (robot) đóng góiCÔNG NGHỆ PHẦN MỀM   TS. TRẦN CAO ĐỆ   2010   Trang 22
Yêu cầu của một thiết kế• Một thiết kế tốt   – Dễ đọc, hiểu   – Tin cậy   – Dễ phát triển   – bao trùm tất cả các yêu cầu ...
Đặc trưng của KTPM• Kiến trúc PM ảnh hưởng bởi:   – nhà phát triển.   – kiến thức và kinh nghiệm của người phân tích.   – ...
2. Mô hình kiến trúc• Dùng để tài liệu hóa một kiến trúc.• Mô hình cấu trúc tĩnh: các thành phần  chính của HT.• Mô hình c...
3. Kiểu kiến trúc• Kiến trúc là một sự xếp            – Các kiểu kết nối  đặt hình thức các phần                  • Proced...
Ba kiểu kiến trúc thông dụng   – Data repository (kho dữ liệu);   – Shared services and servers;   – Abstract machine or l...
Mô hình kho dữ liệu (repository)• Các HT con trao đổi  (khối lượng lớn) dữ  liệu• Hai kiểu trao đổi   – CSDL tập trung hoặ...
Đặc trưng của mô hình kho dữ liệu• Thuận lợi   – Hiệu quả để chia sẻ một lượng lớn dữ liệu;   – Các HT con không không cần...
Khách - chủ (Client – server)• Hệ thống phân tán:  dữ liệu và xử lí được  phân bố phân tán  trong các thành phần.• Tập hợp...
Khách - chủ (Client – server)• Thuận lợi   – Phân tán dữ liệu trực tiếp, tường minh.   – Sử dụng hiệu quả mạng. Dùng chung...
Mô hình phân tầng (layered)• Dùng để mô hình tương  tác giữa các hệ thống con• Tổ chức hệ thống thành  tập hợp các tầng (l...
4. Các mẫu thiết kế (design patterns)•   Một mẫu thiết kế là một cấu          •   Các tính chất của các mẫu    trúc lặp lạ...
Các mẫu thiết kế (tt)   – Các mẫu không diễn tả một      •   CGI / ASP / JSP / PHP …     số yêu cầu không chức     năng nh...
4. Kiểm tra và xác nhận• Kiến trúc phần mềm đưa ra các quyết định về thiết kế.  Nó ảnh hưởng đến toàn bộ quá trình phát tr...
Tổng kết chương•   Kiến trúc phần mềm mô tả các phần tử trong hệ thống và tương tác    giữa chúng•   Các mẫu thiết kế (des...
Chương 11:Thiết kế phần mềm Software Design
1. Thiết kế phần mềm•   Từ mô hình phân tích             thiết kế       Entity-       Relationship                        ...
2. Nguyên tắc thiết kế•   Chia hệ thống thành các hệ    thống con và đơn thể    – hệ thống con (sub-system):      bao gồm ...
Phân tách chức năng (functional decomposition)•   Chia để trị (devide and           •   Hướng dẫn của Parnas:    conquer) ...
3. Các khái niệm trong thiết kế•   Abstraction•   Refinement•   Modularity•   Software Architecture•   Control Hierarchy• ...
4. Đánh giá thiết kế• Tối ưu về giá (cost)   – Cost/module   – Cost tích hợp   – Total cost• Đánh giá bằng fan-in,  fan-ou...
Tính hợp nhất (cohesion)• Tính hợp nhất: là mức độ             •   Hợp nhất logic: module làm nhiều                       ...
Độ gắn kết (coupling)• Độ gắn kết chỉ mức độ               – gắn kết nhãn: hai module  phụ thuộc giữa các                 ...
5. Độ phức tạp (complexity)• Độ phức tạp của một bài     • Đo độ phức tạp  toán là mức độ nỗ lực đòi       – Nội module: đ...
Đo độ phức tạp theo size• Số dòng lệnh (LOC)                       •   Độ lớn chương trình (program volume)               ...
Ví dụ1.  Procedure sort(var x:array;           operator              operand    n:integer);                           Proc...
• Áp dụng công thức tính   –   Size of vocabulary:               n=21   –   Program length:                   N=60   –   E...
Đo độ phức tạp theo cấu trúc•   Cyclomatic complexity                   •   Ví dụ: thủ tục sort ở trang 34    (McCabe)    ...
•   Cyclomatic complexity có thể        •   Phản biện về độ đo    xem là số đường đi độc lập              – Chương trình c...
Cấu trúc của hệ thống- Call Graph•   Kiến trúc của hệ thống có thể xem       •   Call graph    như một đồ thị:            ...
Cấu trúc hệ thống-Call graph•   Cấu trúc tốt-đơn giản nhất: call        •   M(G) cho biết độ phức tạp    graph hình cây.  ...
Cấu trúc hệ thống-fan•   Độ phức tạp trong cấu trúc còn           •   Độ đo của Shepperd: độ phức    được đo bằng độ phức ...
5. Phương pháp thiết kế•   Bảng quyết định•   ER•   Dòng dữ liệu (Flowchart)•   Phân tích cấu trúc (Structure Analysis/Str...
6. Tài liệu thiết kế•   7 vai trò của tài liệu thiết kế            •   10 thuộc tính của tài liệu thiết kế     1. Cho ngườ...
Tài liệu thiết kế (tt)• IEEE 1016 nhóm 10 thuộc tính trên vào 4 nhóm sao cho  mỗi vai trò người dùng (user role) chỉ dùng ...
Tổng kết chương•   Nguyên tắc:                        • Các độ đo độ phức tạp    – thiết kế là phân chia hệ thống     của ...
Chương 12: Phân tích & Thiết kế  hướng đối tượng (OOAD)
Khái niệm về đối tượng                                                    BOOK•   Đối tượng (object)                      ...
Phương pháp phân tích và TK HĐT•   Dựa vào đặc tả     – Xác định đối tượng     – Xác định thuộc tính     – Xác định quan h...
Các sơ đồ UML                                                  State                                                   Sta...
Performance                                                       Engineer         Database       Administrator           ...
Các khái niệm trong OOAD• OOAD dùng các ký hiệu đồ họa để vẽ mô hình   –   Trường hợp sử dụng (use case)   –   Sơ đồ lớp: ...
Trường hợp sử dụng•   Mô tả chức năng hệ thống•   Mô tả chi tiết từng chức năng    bằng các kịch bản (senario)            ...
Sơ đồ lớp•   Biểu diễn mối quan hệ giữa các    lớp                                   •   Bản số (multiplicity)     –   Tổn...
Sơ đồ đối tượngCÔNG NGHỆ PHẦN MỀM        TS. TRẦN CAO ĐỆ   2010   Trang 66
Sơ đồ trạng thái•   Sơ đồ trạng thái tương tự như FSM.•   Biểu diễn hành vi của một đối tượng    – Một đối tượng có thể có...
Sơ đồ hoạt động•   Mô tả chi tiết cách thức    hoạt động của hệ thống:     – các hoạt động để tạo ra       một chức năng n...
Sơ đồ tuần tự, hợp tác•    Biểu diễn sự hợp tác giữa các                                     Sơ đồ hợp tác : Giống như    ...
Sơ đồ thành phần componentsCÔNG NGHỆ PHẦN MỀM   TS. TRẦN CAO ĐỆ   2010   Trang 70
Sơ đồ triển khaiCÔNG NGHỆ PHẦN MỀM         TS. TRẦN CAO ĐỆ   2010   Trang 71
Rational Rose• Công cụ hỗ trợ   – Qui trình RUP   – Phân tích & thiết kế theo UMLCÔNG NGHỆ PHẦN MỀM       TS. TRẦN CAO ĐỆ ...
Tổng kết chương•   Đối tượng•   Nguyên tắc PT & TK HĐT•   PP phân tích và TK HĐT: UML     – Các sơ đồ UML     – Rational R...
Chương 13: Kiểm thử phần mềm      Software testing
Kiểm thử phần mềm là gì•   Test:                                 – 60% lỗi thiết kế      – Thường được nghĩ như là        ...
Các chiến lược kiểm thử• Kiểm thử bao trùm (coverage-based testing)• Kiểm thử lỗi (fault-based testing): dựa trên kỹ thuật...
Mục đích kiểm thử• Các khái niệm                     • Verification và validation   – Error: một hành động của         [IE...
Qui trình kiểm thử•   Vấn đề: chọn tập hợp con của input để test (test cases). Test cases    nhằm mục đích phát hiện lỗi.•...
Hoạt động kiểm thử trong tiến trình phần mềm• Hoạt động test diễn ra                   – Cài đặt  trong suốt quá trình phá...
Các giai đoạn test• Mô hình chử V                        • System test• Unit test                                – Test tí...
Testing ToolsCÔNG NGHỆ PHẦN MỀM       TS. TRẦN CAO ĐỆ   2010   Trang 81
Kế hoạch kiểm thử & tài liệu•   Như các công đoạn khác trong    tiến trình phần mềm, kiểm thử    phải có kế hoạch và tài l...
Các kỹ thuật test thủ công•   Đọc (reading)                             – Các thành viên inspection    – Đọc, đọc đi đọc l...
Các kỹ thuật test thủ công(tt)    – Quá trình inspection để phát        • Đánh giá kịch bản      hiện lỗi, không sửa.     ...
Kỹ thuật kiểm thử bao trùm           (coverage-based testing)• Kiểm thử bao trùm   – Số chỉ thị   – Số đường đi / nhánh ch...
Ví dụ về control graph1.    Procedure sort(var x:array;      n:integer);2.    Var i,j,save:integer;3.    Begin4.         f...
Kỹ thuật test dựa trên lỗi (fault)•   Seed fault                                – Một số nguyên tắc thay thế:    – Cài một...
Kỹ thuật test dựa trên sai lầm (error)•   Test các giá trị biên                  •     Vd:     – ON point: điểm nằm trên b...
Các nghiên cứu thực nghiệm• Meyer, 88   – 85% lỗi được phát hiện trong quá trình inspection ở     các giai đoạn đặc tả, th...
Tổng kết chương• Test thủ công                   • Bài tập: 1    14 trang   – Peer review                    442,443   – I...
Chương 14: Bảo trì phần mềmChương 19: Công cụ phần mềm        Tự đọc thêm
Lưu ý ngày thi!
Upcoming SlideShare
Loading in …5
×

Cmpm chuong 9-14 12-2009

2,005 views

Published on

công nghệ phần mềm chương 9-14

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,005
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
73
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Cmpm chuong 9-14 12-2009

  1. 1. PHẦN 2:Chu trình sống của phần mềm /Tiến trình phát triển phần mềm TS. TRẦN CAO ĐỆ NĂM 2010
  2. 2. Các bước chính trong tiến trình PM Bài toán Tìm hiểu yêu cầu Đặc tả yêu cầu Thiết kế Đặc tả chương trình Cài đặt Chương trình Kiểm thử Chương trình làm việc Bảo trìCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 2
  3. 3. Chương 9: Đặc tả yêu cầuRequirement Engineering
  4. 4. 1. Khái niệm đặc tả yêu cầu• The hardest single part of • Nội dung đặc tả building a system is – Yêu cầu chức năng deciding what to build – Yêu cầu không chức năng: hiệu quả của hệ thống, độ tin• Đặc tả yêu cầu phần cậy, tài liệu người dùng, tập mềm huấn, giá thành,… – Bước đầu tiên trong tiến • Kết quả của đặc tả: tài liệu đặc trình phần mềm tả yêu cầu – Các yêu cầu của người – Phản ánh sự hiểu biết dùng về hệ thống tương lai chung về vấn đề cần giải phải được thu thập và tài quyết giữa người phân tích liệu hóa. Chỉ tập trung vào và khách hàng. what và bỏ qua how – Cơ sở để nghiên cứu khả thi.• Đặc tả yêu cầu khác với – Cơ sở để kiểm thử-chấp phân tích yêu cầu và đặc nhận. tả hệ thống.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 4
  5. 5. 2. Yêu cầu về tài liệu đặc tả yêu cầu• Tài liệu đặc tả phải đáp ứng: – rõ ràng và dễ hiểu đối với khách hàng (dễ thuyết phục). – đầy đủ và chi tiết vì đây là nguồn thông tin duy nhất dành cho nhóm phân tích & thiết kế.• Đặc điểm: – Các lỗi xảy ra trong giai đoạn này sẽ ảnh hưởng đến các giai đoạn còn lại của toàn bộ tiến trình. – Là hợp đồng (contract) giữa khách hàng và nhà phát triển. – Phải bao gồm các ràng buộc mà sản phẩm phải đáp ứng – Đặc tả yêu cầu rất khó độc lập với phân tích, thiết kế.• Loại đặc tả – Client – driven – Market – drivenCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 5
  6. 6. 3. Nội dung đặc tả• Phần mềm: • Con người: các lớp – Môi trường làm việc của người dùng, trình độ phần mềm: OS, DBMS – người dùng – Các phần mềm giao tiếp – người quản trị… với phần mềm muốn phát triển: • Tài liệu • Các hệ thống đang tồn tại – Các yêu cầu về tài liệu • Dữ liệu: nguồn dữ liệu, – Các biểu mẫu format, dùng lại CSDL cũ. • Thủ tục • Giải thuật – Qui trình nghiệp vụ• Phần cứng: khả năng của phần cứng. • Chức năng – Các chức năng theo từng – Khả năng lưu trữ nhóm người dùng – Khả năng đáp ứng một tác vụ … • Chất lượng – Yêu cầu chất lượng – Giá thành – Thời gian đáp ứngCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 6
  7. 7. 4. Hình thức đặc tả• Dùng ngôn ngữ tự nhiên – Ngữ nghĩa không rõ ràng, thường có nhiều lỗi xảy ra – Ngôn ngữ tự nhiên không phải là phương cách tốt để đặc tả sản phẩm• Dùng ngôn ngữ qui ước – Bán hình thức/ đồ họa • Phân tích theo cấu trúc • Mô hình thực thể quan hệ • OOP – Ngôn ngữ hình thức • Z, VDM, Petri net.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 7
  8. 8. Case study - Thảo luận• Viết đặc tả yêu cầu cho “hệ thống QL thư viện” – Nhóm các user • Người thủ thư • Đọc giả • Người quản lí • Người quản trị hệ thống – Nhóm các yêu cầu theo • Chức năng • Chất lượng • Công nghệ: DB, bộ nhớ, phần cứngCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 8
  9. 9. 5. Ba bước chính trong đặc tả yêu cầu User• Nắm bắt yêu cầu user feedback (requirement User Models to be elicitation): hiểu các requirements validated by user yêu cầu knowledge Requirements – Nhà phân tích # chuyên model gia của lĩnh vực. elicitation specification validation• Đặc tả các yêu cầu: Request more validation mô tả các yêu cầu Domain knowledge results tài liệu hóa knowledge Domain knowledge• Kiểm tra và xác nhận : Problem – Kiểm tra (verification): domain yêu cầu được phát biểu đúng. – Kiểm tra – xác nhận (validation): yêu cầu đúng đã được phát biểu và tài liệu hóa.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 9
  10. 10. 6. Phát biểu yêu cầu• Các yêu cầu phải được phát • Vai trò người phân tích: biểu tường minh và tài liệu hóa – Phân tích bài toán• Mô hình hóa: một phần của thế – Thương thảo các yêu cầu giới thực được quan tâm: universe of discourse (UoD) • Các yêu cầu về hệ thống• Mỗi người lên quan trong UoD phải được phát biểu đều có một mô hình riêng, chính xác và đầy đủ không tường minh về thế giới – Nhiều người liên quan đó. – Trình độ khác nhau• Phát biểu yêu cầu (requirements elicitation) là – Tầm nhìn khác nhau phát biểu tường minh về mô • Các điểm cần lưu ý hình không tường minh đó. – Con người thường có thành kiến với phỏng vấn – Con người thường không có suy nghĩ logic nhất quán – Người ta thường không thể chính xác hóa cái mình muốnCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 10
  11. 11. 7. Các kỹ thuật dùng để phát biểu yêu cầuCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 11
  12. 12. 8. Tài liệu đặc tả yêu cầu• Tài liệu đặc tả: là sp cuối cùng – Thay đổi được của bước đặc tả, là đầu vào – Lần vết được của bước phân tích-thiết kế hệ • Chuẩn cho tài liệu đặc tả: thống để có đặc tả hệ thống IEEE 830 (kiến trúc hệ thống) • Dàn ý cho một tài liệu đặc tả• Tài liệu đặc tả phải (theo IEEE 830) – Dễ đọc – Dễ hiểu – Đúng đắn (xác nhận bởi user) – Không “mù mờ” – Đầy đủ (chức năng, chất lượng…) – Nhất quán: các yêu cầu không mâu thuẫn nhau. – Có thứ tự: quan trọng ít quan trọng – Kiểm tra được: các đặc tả phải định lượng để có thể testCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 12
  13. 13. Tài liệu đặc tả yêu cầu (tt)• Phần 3 “specific requirements” là phần dài nhất trong tài liệu, bao trùm nhiều khía cạnh: – Mode: chế độ vận hành (thử nghiệm, thí điểm, dùng) – User class: nhóm người dùng – Objects: các đối tượng trong thế giới thực – Response: trả lời (đầu ra) – Functional hierarchy: tổ chức phân cấp các chức năng. (tham khảo một tài liệu đặc tả trang 228-229)CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 13
  14. 14. 9. Kỹ thuật đặc tả yêu cầu• Tài liệu đặc tả yêu cầu phục vụ • Mô hình thực thể quan hệ cho: – Người dùng – Người thiết kế• Tài liệu thường được viết bằng NN tự nhiên và NN của người • Máy trạng thái hữu hạn dùng: – Nhiễu (noise): dư thừa nhiều thông tin không cần thiết – Im lặng (silence): cái chính lại không được đề cập – Đặc tả thừa: đề cập đến cách giải quyết hơn là vấn đề phải giải quyết – Mâu thuẫn: 1 vấn đề đặc tả nhiều lần không nhất quán • SADT – Nhập nhằng • Các sơ đồ UML – Tham khảo về phía sau – Use case – Mơ mộng (wishful thingking): – Class – State mô tả siêu thực – Cooperation – …CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 14
  15. 15. Ví dụ về bộ điều khiển an toàn (két sắt)• J = {Khóa an toàn, A, B, Không khóa an toàn, Chuông báo động }• K = {1T, 1P, 2T, 2P, 3T, 3P}• T = như hình vẽ• S = {Khóa an toàn}• F = {Không khóa an toàn, Chuông báo động}CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 15
  16. 16. Phân tích• Phân tích là bước trung gian giữa • Kết quả của giai đoạn phân đặc tả và thiết kế tích MÔ HÌNH PHÂN TÍCH• Mục đích: – Làm rõ thêm các yêu cầu – Trình bày các yêu cầu bằng các mô hình phân tích – Định nghĩa rõ các thuật ngữ (từ điển dữ liệu)• Phân tích = xây dựng mô hình hệ thống – ERD – DFD – State diagramCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 16
  17. 17. 10. Đặc tả các yêu cầu phi chức năng• Yêu cầu phi chức năng (non- • Các yêu cầu phi chức năng đôi khi functional requirements) còn được xem như yêu cầu về – Giao diện với ht khác( External chất lượng interface) – Phải xác định và test được – Yêu cầu về hiệu quả vd: 80% giao dịch được đáp ứng – Ràng buộc về thiết kế trong 1s; 20% còn lại đáp ứng – Các đặc tính của hệ thống trong 3s.• Giao diện với ht khác và ràng • Lưu ý: buộc về thiết kế được xem như là – Các yêu cầu phi chức năng những yêu cầu bắt buộc, ví dụ: có giá để thực hiện – Phần cứng, phần mềm và giao tiếp giữa chúng phải khả thi trong sự cân – Giao diện người dùng theo chuẩn bằng với ngân sách. của công ty. Phải khả thi trên thực tế – Format của tài liệu, báo cáo – Ràng buộc về qui trình (vd ISO Nếu cần thiết phải nghiên 9000) cứu khả thi trước. – Giới hạn của phần cứngCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 17
  18. 18. 11. kiểm tra (verification) và kiểm tra-xác nhận (validation)• Tài liệu đặc tả phải được: • Bằng việc kiểm tra tài liệu – Kiểm tra (verification): đúng đặc tả yêu cầu đắn, đầy đủ, nhất quán. Nghĩa là tài liệu đặc tả có – Thiết lập test plan chất lượng. – Xác định nguồn lực, pp để – Kiểm tra-xác nhận kiểm thử trong quá trình (validation): tài liệu đặc tả phát triển. mô tả đúng đắn yêu cầu – Xác định kế hoạch kiểm của khách hàng. Xác nhận thử bàn giao (acceptance có hiệu lực/ giá trị. test)• Đối chiếu lại tài liệu đặc tả với một danh sách kiểm tra (checklist). Ví dụ: – đã chỉ rõ các tài nguyên phần cứng? – đã chỉ rõ các tiêu chuẩn chấp thuận ?CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 18
  19. 19. Tổng kết chương• Đặc tả yêu cầu: • Công cụ để mô tả vấn đề: – Làm rõ yêu cầu của bài – Ngôn ngữ tự nhiên toán – Ngôn ngữ bán hình thức: – Làm rõ các ràng buộc trong hình ảnh, biểu đồ giải pháp – Ngôn ngữ hình thức – Xác định cụ thể chức năng • Tài liệu đặc tả phải mô tả: phải bàn giao và các yêu cầu bắt buộc về môi – Yêu cầu chức năng trường hoạt động – Yêu cầu phi chức năng• Đặc tả yêu cầu là quá • Tài liệu đặc tả phải được trình lặp của ba hoạt kiểm tra, xác nhận, phê động chính: chuẩn. – Requirement elicitation: để – Làm cơ sở cho kế hoạch hiểu vấn đề kiểm thử & kiểm thử – Requirement specification: – Làm cơ sở cho hợp đồng & để mô tả vấn đề bàn giao sản phẩm. – Requirement validation: để thống nhất về vấn đề.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 19
  20. 20. Chương 10:Kiến trúc phần mềmSoftware architecture
  21. 21. 1. Thiết kế kiến trúc• Xây dựng PM = xây dựng hệ thống có thiết kế kiến trúc pm.• Kiến trúc = thiết kế – Quá trình xác định các hệ thống con trong hệ thống và khung cho giao tiếp và điều khiển các hệ thống con gọi là TKKT – Sản phẩm của quá trình TKKT là kiến trúc PM. – Kiến trúc của một xác định các thành phần tính toán và tương tác giữa chúng trong hệ thống (Shaw,95) – Kiến trúc pm (của một ct hoặc một ht tính toán) là cấu trúc của hệ thống, bao gồm các thành phần, các tính chất nhìn thấy được của các thành phần và quan hệ giữa chúng.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 21
  22. 22. Ví dụ một hệ thống máy (robot) đóng góiCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 22
  23. 23. Yêu cầu của một thiết kế• Một thiết kế tốt – Dễ đọc, hiểu – Tin cậy – Dễ phát triển – bao trùm tất cả các yêu cầu tường minh – Cung cấp hình ảnh tồng quan về pm• Kiến trúc PM phục vụ: – Trừu tượng hóa về hệ thống. – Trao đổi, thương thảo giữa các bên liên quan. – Trợ giúp quyết định.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 23
  24. 24. Đặc trưng của KTPM• Kiến trúc PM ảnh hưởng bởi: – nhà phát triển. – kiến thức và kinh nghiệm của người phân tích. – Môi trường kỹ thuật và tổ chức.• Một kiến trúc có thể gồm nhiều thành phần có cấu trúc. Mỗi thành phần có cấu trúc có thể xem xét riêng biệt còn gọi là khung nhìn (view) – Conceptual/logical view – Implementation view – Process view – Deployment view.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 24
  25. 25. 2. Mô hình kiến trúc• Dùng để tài liệu hóa một kiến trúc.• Mô hình cấu trúc tĩnh: các thành phần chính của HT.• Mô hình cấu trúc động: cấu trúc của tiến trình trong HT.• Mô hình giao diện: giao tiếp giữa các HT con.• Mô hình quan hệ: quan hệ giữa các HT con.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 25
  26. 26. 3. Kiểu kiến trúc• Kiến trúc là một sự xếp – Các kiểu kết nối đặt hình thức các phần • Procedure call tử kiến trúc. • Dataflow • Implicit invocation: internal• Một kiểu kiến trúc là sự events xếp đặt có luật lệ các • Message passing phần tử kiến trúc • Shared data • Instantiation• Kiến trúc phần mềm dựa • Chương trình chính-ct con trên: • Kiểu dữ liệu tt – Các kiểu thành phần • Implicit invocation (components) • Pipe and filter • Computational • Repository • Memory • Layered • Manager • Controller • Một HT lớn có thể bao gồm nhiều kiểu kiến trúcCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 26
  27. 27. Ba kiểu kiến trúc thông dụng – Data repository (kho dữ liệu); – Shared services and servers; – Abstract machine or layered.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 27
  28. 28. Mô hình kho dữ liệu (repository)• Các HT con trao đổi (khối lượng lớn) dữ liệu• Hai kiểu trao đổi – CSDL tập trung hoặc kho DL (repository): truy cập bởi tất cả HT con Ví dụ về kiến trúc của – Mỗi HT con lưu trữ dữ một CASE toolset liệu của riêng mình và (Rational Rose chẳng hạn) truyền dữ liệu tường minh cho các HT khácCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 28
  29. 29. Đặc trưng của mô hình kho dữ liệu• Thuận lợi – Hiệu quả để chia sẻ một lượng lớn dữ liệu; – Các HT con không không cần quan tâm đến dữ liệu được quản lí thế nào (cập nhật, bảo mật,…). – Lược đồ kho dữ liệu phải được chia sẻ.• Hạn chế – Các HT con phải thống nhất trên mô hình kho dữ liệu, tức là phải có “cam kết và nhất trí”; – Dữ liệu phát triển khó khăn và bảo trì đắt; – Khó khăn khi phải giải quyết các chính sách đặc thù; – Khó phân tán một cách hiệu quả.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 29
  30. 30. Khách - chủ (Client – server)• Hệ thống phân tán: dữ liệu và xử lí được phân bố phân tán trong các thành phần.• Tập hợp các máy chủ chuyên biệt cung cấp các dịch vụ.• Các máy con gọi đến các dịch vụ• Mạng cho phép truy cập các máy chủ.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 30
  31. 31. Khách - chủ (Client – server)• Thuận lợi – Phân tán dữ liệu trực tiếp, tường minh. – Sử dụng hiệu quả mạng. Dùng chung tài nguyên – Dễ thêm máy chủ và nâng cấp máy chủ.• Bất lợi – Không chia sẻ mô hình dữ liệu các hệ thống con dùng dữ liệu khác nhau. Trao đổi dữ liệu khó khăn, không hiệu quả – Quản lí dư thừa trên các máy chủ; – Không có lưu trữ tập trung tên và dịch vụ khó tìm một dịch vụ, cùng với một máy chủ sẳn sàng.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 31
  32. 32. Mô hình phân tầng (layered)• Dùng để mô hình tương tác giữa các hệ thống con• Tổ chức hệ thống thành tập hợp các tầng (layer) hoặc máy ảo (abstract machines); mỗi tầng cung cấp một số dịch vụ.• Hỗ trợ phát triển theo mô hình tăng trưởng các hệ thống con trong các tầng. Khi có thay đổi chỉ có tầng liền kề bị ảnh hương.• Mô hình phân tầng chỉ là kiến trúc nhân tạo.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 32
  33. 33. 4. Các mẫu thiết kế (design patterns)• Một mẫu thiết kế là một cấu • Các tính chất của các mẫu trúc lặp lại của các thành phần thiết kế: tương tác với nhau để giải – Một mẫu có thể coi là dùng lại quyết một vấn đề nào đó trong ý tưởng thiết kế. Nó thực chất một ngữ cảnh cụ thể. là lặp lại ý tưởng thiết kế trong• Mỗi mẫu thường chứa đựng một hoàn cảnh cụ thể nhiều thành phần đơn lẻ. – Một mẫu phải cân nhắc các yêu cầu đối lập; các tính chất• Một mẫu thiết kế điển hình là của bài toán phải được tính Model – view – controller đến trong giải pháp (MVC). MVC gồm 3 thành – Các mẫu là những thiết kế tốt phần đã biết. Nó chứa đựng nhiều – Model: gồm dữ liệu và thao thành phần đơn lẻ nhưng đã tác dữ liệu được biết rõ. Ví dụ: quicksort, – View: cách thức hiển thị dữ FFT,… liệu – Các mẫu là phương tiện để tài – Controller: là cách thức xử lí liệu hóa phần mềm của một view; cách thức điều (documentation). Nó còn là khiển các hành vi từ dữ liệu chuẩn phải tuân theo. đầu vào. Ví dụ update.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 33
  34. 34. Các mẫu thiết kế (tt) – Các mẫu không diễn tả một • CGI / ASP / JSP / PHP … số yêu cầu không chức năng như: tính mềm dẽo • Cache tính thay đổi được và giao • Proxy diện người dùng.• Ví dụ về mẫu thiết kế – Hệ thống quản lí thư viện cho phép độc giả tìm kiếm tài liệu (search) và đặt mượn từ xa. – Với yêu cầu này người thiết kế có thể nghĩ ngay đến kiến trúc client-server (một mẫu kiến trúc) Trong mẫu (pattern) này có nhiều thành phần: - Application trên máy chủ - Application trên máy client - Phương thức giao tiếp (TCP/IP)CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 34
  35. 35. 4. Kiểm tra và xác nhận• Kiến trúc phần mềm đưa ra các quyết định về thiết kế. Nó ảnh hưởng đến toàn bộ quá trình phát triển về sau kiểm tra cẩn thận & phải được phê duyệt.• Xét duyệt (review) và thanh tra (inspections) có thể được dùng• Đánh giá kiến trúc qua các tiêu chí chất lượng• Đánh giá dựa trên đặc tảCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 35
  36. 36. Tổng kết chương• Kiến trúc phần mềm mô tả các phần tử trong hệ thống và tương tác giữa chúng• Các mẫu thiết kế (design patterns) – định hướng cho thiết kế, tức là dàn xếp các phần tử trong hệ thống – dùng lại ý tưởng thiết kế: áp dụng cấu trúc các thành phần đã biết vào một hoàn cảnh cụ thể. – Là phương tiện giao tiếp “chuẩn” trong thảo luận thiết kế• Kiến trúc phần mềm đóng vai trò quan trọng – Nó trình bày một thiết kế của phần mềm. Là sự tích hợp công nghệ vào giải pháp cho bài toán – nó giúp xác định, mô tả, phân loại các thành phần trong hệ thống ở mức trừu tượng – Nó thể hiện các quyết định về thiết kế để có thể xem xét, thảo luận đánh giá giữa/bởi các bên có liên quan – Nó thể hiện sự tương tự với các sp cùng họ trợ giúp quyết định dùng lại (reuse)CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 36
  37. 37. Chương 11:Thiết kế phần mềm Software Design
  38. 38. 1. Thiết kế phần mềm• Từ mô hình phân tích thiết kế Entity- Relationship Procedural Data Flow Diagram design Diagram Data Dictionary Interface design State-Transition Architectural design Diagram Data designCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 38
  39. 39. 2. Nguyên tắc thiết kế• Chia hệ thống thành các hệ thống con và đơn thể – hệ thống con (sub-system): bao gồm các phép toán và dịch vụ/chức năng độc lập – Đơn thể (module): là một thành phần cung cấp dịch vụ cho các thành phần khác nhưng không phải là một hệ thống độc lập• Nguyên tắc module hóa – Trừu tượng hóa: • Proceduce: một chức năng được mô hình hóa • Data: Một đối tượng được mô hình hóa bằng cách thuộc tính phù hợp và cần thiết – Mịn dầnCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 39
  40. 40. Phân tách chức năng (functional decomposition)• Chia để trị (devide and • Hướng dẫn của Parnas: conquer) – Xác định các hệ thống con.• Mịn từng bước (stepwise Bắt đầu với tập hợp đơn giản refinement) nhất. Không thể thu được hình ảnh hoàn hảo của hệ thống – Top-down: từ chức năng ngay từ đầu chính các chức năng cơ bản – Áp dụng nguyên tắc che thông tin/bao gói – Bottom-up: các chức năng cơ bản chức năng chính – Từng bước chia nhỏ các hệ thống con đồng thời thêm các• Cả top-down và bottom up đều chức năng mới vào hệ thống được dùng trong quá trình thiết (mở rộng). kế. – Áp dụng use-relation để thiết lập cấu trúc phân cấp.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 40
  41. 41. 3. Các khái niệm trong thiết kế• Abstraction• Refinement• Modularity• Software Architecture• Control Hierarchy• Structural Partitioning• Data Structure• Software Procedure• Information HidingCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 41
  42. 42. 4. Đánh giá thiết kế• Tối ưu về giá (cost) – Cost/module – Cost tích hợp – Total cost• Đánh giá bằng fan-in, fan-out: Tránh high fan- out; cố gắng xây dựng M cấu trúc phân cấp Fan-out• Đánh giá module hóa a b c – Độc lập chức năng Depth d e f g h – Hợp nhất (cohesion) Fan-in – Gắn kết (coupling) i – Nguyên tắc: High Width cohesion-low couplingCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 42
  43. 43. Tính hợp nhất (cohesion)• Tính hợp nhất: là mức độ • Hợp nhất logic: module làm nhiều chức năng có liên quan logic với gắn kết giữa các phần nhau. VD module chứa tất cả các trong một module thành phần input. • Hợp nhất theo thời gian: Các – Một thiết kế tốt thì module thành phần khác nhau cùng được đơn nhất, tức là các thành khởi tạo vào 1 thời điểm. phần gắn kết chặt chẽ • Hợp nhất thủ tục: nhiều thành nhau để tạo nên chức năng phần độc lập thực hiện theo trình đơn nhất của module tự. • Hợp nhất giao tiếp: nhiều thành – Đánh giá theo 7 cấp độ phần độc lập thực hiện trên cùng (Yourdon) một dữ liệu. • Hợp nhất ngẫu nhiên: các • Hợp nhất tuần tự: nhiều thành phần độc lập thực hiện theo trình thành phần không liên tự, cái này làm đầu vào cho cái quan với nhau kia. • Hợp nhất chức năng: các thành phần gắn kết nhau tạo nên chức nằng đơn nhất của module.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 43
  44. 44. Độ gắn kết (coupling)• Độ gắn kết chỉ mức độ – gắn kết nhãn: hai module phụ thuộc giữa các chia sẽ cùng CTDL. module – Gắn kết dữ liệu: dữ liệu được chuyển từ 1 module• 6 mức độ gắn kết sang 1 module khác. (Yourdon) • Tính hợp nhất & độ gắn – Gắn kết nội dung: module kết là hai tính chất song này làm thay đổi dữ liệu của module khác. hành: nếu tính hợp nhất – Gắn kết chung: chia sẽ dữ trong một module cao liệu (tốt) thì độ gắn kết giữa – Gắn kết ngoài: hai module các module sẽ thấp (tốt) trao đổi dữ liệu thông qua một media (vd file) – Gắn kết điều khiển: module chuyển điều khiển thực hiện cho module khác –CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 44
  45. 45. 5. Độ phức tạp (complexity)• Độ phức tạp của một bài • Đo độ phức tạp toán là mức độ nỗ lực đòi – Nội module: đo dựa trên hỏi để giải bài toán các thuộc tính bên trong 1 module đơn lẻ• Độ phức tạp của PM là – Ngoại module: đo dựa trên mức độ nỗ lực để PTPM các thuộc tính của hệ hoặc bảo trì PM. thống (tức là tập hợp các module) – Đo dựa trên kích thước (size-based) – Đo dựa trên cấu trúc (structure-based)CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 45
  46. 46. Đo độ phức tạp theo size• Số dòng lệnh (LOC) • Độ lớn chương trình (program volume) V= Nlog2n (diễn dịch là số bits tối – Số dòng lệnh lý tưởng thiểu) 30LOC/module (Weiberg,71) • Cấp độ chương trình (program level):• Có những dòng lệnh “khó L=V*/V; V* là biểu diễn Compact nhất của giải thuật đang xét. L được xấp xỉ hơn” những dòng khác bởi L’=(2/n1)(n2/N2) – i:=1; • Công sức viết chương trình – While p^.next<>nil do p:=p^.next; E=V/L• Software science (Halstead) • Thời gian viết chương trình – n1: số toán tử phân biệt T=E/18 s – n2: số toán hạng phân biệt • Halstead ước lượng N bởi N’=n1log2n1+n2log2n2 – N1: tổng số toán tử – N2: tổng số toán hạng – Các độ đo: • n=n1+n2 : số từ vựng • N= N1+N2: độ dài chương trình (program length).CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 46
  47. 47. Ví dụ1. Procedure sort(var x:array; operator operand n:integer); Procedure 1 X 72. Var i,j,save:integer; Sort() 1 N 23. Begin Var 2 I 64. for i:=2 to n do : 3 J 55. for j:=1 to i do Array 1 Save 36. if x[i]<x[j] then begin ; 6 “2” 17. save:=x[i]; Integer 2 “1” 18. x[i]:=x[j]; , 29. x[j]:=save Begin end 210. end For do 211. End; If then 1 := 5 < 1 [] 6 n1=14 n2=7 N1=35 N2=25CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 47
  48. 48. • Áp dụng công thức tính – Size of vocabulary: n=21 – Program length: N=60 – Estimated program length N’=73 – Program volume V=264 – Level of abstraction L=0.044 – Estimated level of abstraction L’=0.040 – Programming effort E=6000 – Time T=333sCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 48
  49. 49. Đo độ phức tạp theo cấu trúc• Cyclomatic complexity • Ví dụ: thủ tục sort ở trang 34 (McCabe) có đồ thị như sau: – Dùng một đồ thị có hướng để biểu diễn các dòng điều khiển chương trình – Trong trường hợp tổng quát thì đồ thị gồm nhiều thành phần liên thông. • Giả sử một thủ tục hoặc một ct chính có một lối vào (start) và một lối ra (end), thì đồ thị là liên thông (chỉ có 1 thành phần liên thông) – Độ phức tạp của chương trình = độ phức tạp của đồ thị: C=e–n+p+1 e: là số cạnh; n: số nút p: số thành phần liên thông Độ phức tạp: C=13-11+1+1=4CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 49
  50. 50. • Cyclomatic complexity có thể • Phản biện về độ đo xem là số đường đi độc lập – Chương trình chứa các IF trong đồ thị. tuần tự là “dễ” hơn các IF lồng• Cách tính khác nhau. Độ đo của McCabe C = D+1 không thể hiện ngữ cảnh các IF lồng nhau không thỏa D là số nút điều kiện (phân điều kiện biểu diễn. nhánh) – Độ đo của Halstead không C= 3+1=4 tính đến các dòng điều khiển.• Khuyến cáo của McCabe – Cyclomatic complexity của một module không nên quá 10. – Có thể dùng độ đo này trong test: tính số đường đi độ lập số test case – Đo độ khó của chương trình= mật độ IF: C/LOC.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 50
  51. 51. Cấu trúc của hệ thống- Call Graph• Kiến trúc của hệ thống có thể xem • Call graph như một đồ thị: – Đồ thị có hướng – Một nút: một module – Có thể có chu trình – Một cạnh: quan hệ giữa 2 module • Nếu Call graph không có chu• Các mối quan hệ giữa hai module: trình ta gọi là cấu trúc phân – A chứa B – A theo sau là B cấp và có thể phân chia thành – A cung cấp dữ liệu cho B các lớp sao cho mỗi module – A dùng B trong một lớp chỉ gọi đến các• Call graph: đồ thị biểu diễn mối modules trong các lớp dưới quan hệ “A dùng B” • Các độ đo trên call graph – Size: số nút, số cạnh – Depth: đường đi dài nhất từ nút gốc tới nút lá (trong đồ thị không có chu trình) – Width: số nút lớn nhất tại một mức.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 51
  52. 52. Cấu trúc hệ thống-Call graph• Cấu trúc tốt-đơn giản nhất: call • M(G) cho biết độ phức tạp graph hình cây. trong cấu trúc của hệ thống = – Cây có n nút sẽ có số cạnh tối độ phức tạp trong quan hệ đa là (n-1) giữa các module.• Cấu trúc không tốt-phức tạp: call graph có chu trình. – Phức tạp nhất là đồ thị mà mỗi căp nút đều nối với nhau, lúc đó số cạnh sẽ là n(n-1)/2• Đo độ phức tạp của call graph (một đồ thị liên thông) tính bằng M(G)=2(e-n+1)/(n-1)(n-2) M(G) biến thiên từ 0 đến 1 M(G)=0 call graph hình cây M(G) = 1 call graph có các đỉnh là nối kết đầy đủ.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 52
  53. 53. Cấu trúc hệ thống-fan• Độ phức tạp trong cấu trúc còn • Độ đo của Shepperd: độ phức được đo bằng độ phức tạp tạp của module M là: trong luồng thông tin giữa các Complexity(M)= module: (fan-in(M)xfan-out(M))2 – Luồng cục bộ (local flow) từ A đến B: ví dụ: • A gọi B và truyền tham số complexity(A)=complexity(E)=0 • B gọi A và A trả về một giá trị complexity(B)=complexity(C)=1 – Luồng toàn cục từ A đến B: A cập nhật dữ liệu toàn cục và B complexity(D)=9 truy cập vào dữ liệu đó.• Fan –in: tất cả các luồng ra• Fan-out: tất cả các luồng vào Fan-in(A)=0 Fan-out(A)=3CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 53
  54. 54. 5. Phương pháp thiết kế• Bảng quyết định• ER• Dòng dữ liệu (Flowchart)• Phân tích cấu trúc (Structure Analysis/Structure Design)• SADT (structured analysis and Design technique)• OOD (object oriented design)• FSM (finite state machine)• …CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 54
  55. 55. 6. Tài liệu thiết kế• 7 vai trò của tài liệu thiết kế • 10 thuộc tính của tài liệu thiết kế 1. Cho người quản lí: biết các 1. Định danh: tên thành phần, chức năng ước lượng chi phí 2. Kiểu: kiểu của thành phần 2. Người quản lí cấu hình: thông 3. Mục đích tin về ráp nối các thành phần 4. Chức năng và kiểm soát thay đổi 5. Hỗ trợ: thực thể hợp thành từ 3. Người thiết kế: chức năng và những thành phần nào thành phần của hệ thống, quan 6. Phụ thuộc hệ giữa các thành phần 7. Giao diện: với thành phần khác 4. Programmer: giải thuật, CTDL, 8. Nguồn lực cần thiết tương tác giữa các thành phần 9. Xử lí: giải thuật, khởi tạo, quản lí 5. Người kiểm tra đơn vị (unit ngoại lệ. tester): thông tin về thành phần, giải thuật được dùng và 10. Dữ liệu: mô tả, formart, ý nghĩa dữ liệu cần thiết Chuẩn IEEE 1016 6. Người kiểm tra tích hợp: quan hệ giữa các thành phần, chức năng và các thành phần có liên quan 7. Người lập trình bảo trì: các thành phần, cách hiện thức hóa các yêu cầu người dùng CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 55
  56. 56. Tài liệu thiết kế (tt)• IEEE 1016 nhóm 10 thuộc tính trên vào 4 nhóm sao cho mỗi vai trò người dùng (user role) chỉ dùng 1 nhóm – Mô tả phân tách – Mô tả phụ thuộc – Mô tả giao diện – Mô tả chi tiếtCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 56
  57. 57. Tổng kết chương• Nguyên tắc: • Các độ đo độ phức tạp – thiết kế là phân chia hệ thống của module thành các thành phần nhỏ, ít phức tạp – Halstead – Bên trong một module phải có – McCabe tính kết hợp cao – Shepperd – Giữa các modules phải có độ – Độ phức tạp của call graph phụ thuộc thấp – Mỗi module phải che dấu • Phương pháp thiết kế thông tin theo cấu trúc – Cấu trúc của hệ thống là phân – Phân tách chức năng cấp (hình cây) – Thiết kế dòng dữ liêu• Một số độ đo chất lượng – Thiết kế cấu trúc dữ liệu,… – Cohesion – Coupling • Bài tập: 1 11 trang 346 và 347CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 57
  58. 58. Chương 12: Phân tích & Thiết kế hướng đối tượng (OOAD)
  59. 59. Khái niệm về đối tượng BOOK• Đối tượng (object) ------------------- – Là một mô hình quan niệm về author: string một phần thế giới thực hoặc Title: string tưởng tượng ISBN: number • Có một ID để phân biệt với -------------------- các đối tượng khác Archive() • Có tính chất để giữ thông tin Borrow (Client) về đối tượng Return() – Object=identity + variables + Dispose() operations – Object= identity + state + behavior • Giữa các đối tượng có mối – Theo quan điểm SE: đối quan hệ với nhau: tượng là sự TTH dữ liệu, bao – Tổng quát hóa/ĐB hóa, is-a gói dữ liệu và các thao tác trên dữ liệu đó • Book is a Document – Whole-part, has • Book has Ttitle – Member-of, has • Library has MemberCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 59
  60. 60. Phương pháp phân tích và TK HĐT• Dựa vào đặc tả – Xác định đối tượng – Xác định thuộc tính – Xác định quan hệ giữa các đối tượng• Dùng phương pháp phân tích HĐT – Booch – OMT – UML UML 2.0 2004 OMT UML (Rumbaugh et al.) 1.4 May 2000 1996 UML Booch UML 1.1 0.9 Nov. 1997 OOSE (Jacobson et al.)CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 60
  61. 61. Các sơ đồ UML State State Class Diagrams Use Case Diagrams Use Case Diagrams State Use Case Use Case Diagrams State Use Case Diagrams Diagrams Object Sequence Diagrams Diagrams Diagrams Diagrams Diagrams Diagrams Scenario State Scenario State Diagrams Collaboration Component Diagrams Diagrams Models Diagrams Diagrams Diagrams Scenario Component Scenario Component Deployment Diagrams Statechart Diagrams Diagrams Diagrams Diagrams Diagrams Activity DiagramsCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 61
  62. 62. Performance Engineer Database Administrator Release Engineer Project Leader Analyst Designer / Tester DeveloperCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 62
  63. 63. Các khái niệm trong OOAD• OOAD dùng các ký hiệu đồ họa để vẽ mô hình – Trường hợp sử dụng (use case) – Sơ đồ lớp: mô hình tĩnh về phân chia hệ thống – Sơ đồ trạng thái: hành vi động của đối tượng – Sơ đồ tương tác • Tuần tự (Sequence) • Colaboration (hợp tác) – CRC (class – responsibility – collaborators)CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 63
  64. 64. Trường hợp sử dụng• Mô tả chức năng hệ thống• Mô tả chi tiết từng chức năng bằng các kịch bản (senario) Ret urn of i tem Librarian Lend item <<uses>> Remove Reservation Borrower Make re servati onCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 64
  65. 65. Sơ đồ lớp• Biểu diễn mối quan hệ giữa các lớp • Bản số (multiplicity) – Tổng quát hóa • Vai trò (role) – Kết hợp (association) – Kết tập (aggregation) – Hợp thành (composition)CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 65
  66. 66. Sơ đồ đối tượngCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 66
  67. 67. Sơ đồ trạng thái• Sơ đồ trạng thái tương tự như FSM.• Biểu diễn hành vi của một đối tượng – Một đối tượng có thể có nhiều trạng thái khác nhau – Các trạng thái được chuyển lẫn nhau Add student[ count < 10 ] Add Student / Initialization Set count = 0 Open do: Initialize course entry: Register student exit: Increment count Cancel Cancel [ count = 10 ] Canceled do: Notify registered students Closed Cancel do: Finalize course Sơ đồ trạng thái của một “lớp học”CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 67
  68. 68. Sơ đồ hoạt động• Mô tả chi tiết cách thức hoạt động của hệ thống: – các hoạt động để tạo ra một chức năng nào đó – chi tiết hóa một use caseCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 68
  69. 69. Sơ đồ tuần tự, hợp tác• Biểu diễn sự hợp tác giữa các Sơ đồ hợp tác : Giống như đối tượng (theo thời gian) để sơ đồ tuần tự nhưng không thực hiện một tác vụ nhấn mạnh vào tính tuần tự• Các đối tượng hợp tác bằng theo thời gian của thông điệp cách “truyền thông điệp” : Maint enance : Borrower : Librarian Window information 1: create borrower ( ) 1: create borrower ( ) 2: create (String, String) : Librarian : Maintenance Window 2: create (String, String) : Borrower informationCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 69
  70. 70. Sơ đồ thành phần componentsCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 70
  71. 71. Sơ đồ triển khaiCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 71
  72. 72. Rational Rose• Công cụ hỗ trợ – Qui trình RUP – Phân tích & thiết kế theo UMLCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 72
  73. 73. Tổng kết chương• Đối tượng• Nguyên tắc PT & TK HĐT• PP phân tích và TK HĐT: UML – Các sơ đồ UML – Rational Rose• Bài tập: dùng Rational Rose để PT và thiết kế PM “đăng kí môn học” (có tài liệu đặc tả)CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 73
  74. 74. Chương 13: Kiểm thử phần mềm Software testing
  75. 75. Kiểm thử phần mềm là gì• Test: – 60% lỗi thiết kế – Thường được nghĩ như là – 40% lỗi cài đặt thực hiện chương trình và • Kinh nghiệm cho thấy kiểm tra xem output có – Càng phát hiện lỗi muộn giá đúng không. sửa lỗi càng cao – Các hoạt động kiểm thử – Không thể test được mọi nhằm để đảm bảo tính trường hợp: đúng đắn của chương trình • số test case rất lớn • Chi phí test cao• Có thể tạo ra phần mềm không lỗi? – 30-85 lỗi/KLOC – Quá trình test phát hiện 0.5-3 lỗi/KLOC• Hầu hết các lỗi xuất phát từ các giai đoạn rất sớm trong qui trình phần mềm [Boemh].CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 75
  76. 76. Các chiến lược kiểm thử• Kiểm thử bao trùm (coverage-based testing)• Kiểm thử lỗi (fault-based testing): dựa trên kỹ thuật phát hiện lỗi.• Kiểm thử sai lầm (error-based testing): dựa trên các lỗi/sai lầm hay mắc phải• Kiểm thử hộp đen (black-box testing) hay kiểm thử chức năng• Kiểm thử hộp trắng (white-box testing) hay kiểm thử cấu trúc• Kiểm thử đơn vị (unit testing)• Kiểm thử hệ thống (integration testing).CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 76
  77. 77. Mục đích kiểm thử• Các khái niệm • Verification và validation – Error: một hành động của [IEEE] con người dẫn đến kết quả – Verification: là quá trình sai; kết quả là chương trình đánh giá một hệ thống chứa lỗi (fault) hoặc một thành phần để – Fault: một thể hiện của lỗi xác định rằng nó thỏa mãn trong chương trình. Fault các điều kiện áp đặt tại giai có thể đưa đến cái không đoạn bắt đầu. mong đợi (failure) Have we build the system• Failure có nguyên nhân là right? fault; fault bắt nguồn từ – Validation: là quá trình error của con người. đánh giá một hệ thống hoặc một thành phần trong – Failure có thể bắt nguồn từ hoặc sau quá trình phát nhiều fault triển để xác định rằng nó – Fault có thể dẫn đến nhiều đúng đặc tả failure. Have we build the right system?CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 77
  78. 78. Qui trình kiểm thử• Vấn đề: chọn tập hợp con của input để test (test cases). Test cases nhằm mục đích phát hiện lỗi.• Kỹ thuật test: xác định các test cases một cách có hệ thống – Chia miền dữ liệu của input làm các lớp• Mục đích test: làm xuất hiện các lỗi (fault)CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 78
  79. 79. Hoạt động kiểm thử trong tiến trình phần mềm• Hoạt động test diễn ra – Cài đặt trong suốt quá trình phát • Kiểm tra sự phù hợp giữa cài đặt với thiết kế triển phần mềm • Cài đặt test – Giai đoạn đặc tả • Sinh ra dữ liệu test chức • Xác định chiến lược năng và kiến trúc • Đặc tả kiểm thử • Thực hiện test • Sinh dữ liệu test chức – Bảo trì năng • Lặp lại các test trên trong – Thiết kế quá trình phát triển lại • Kiểm tra sự phù hợp giữa thiết kế & đặc tả • Đánh giá kiến trúc • Kiểm thử kiến trúc • Sinh ra dữ liệu test chức năng và cấu trúcCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 79
  80. 80. Các giai đoạn test• Mô hình chử V • System test• Unit test – Test tích hợp các module (integration testing) hay test – Test từng module chấp nhận (acceptance test) • Test từ dưới lên – Thường là test tính dùng • Test từ trên xuống được của hệ thống hơn là test – Test từng module nhằm xác định tính đúng đắn của từng module, sự đúng đắn của code với đặc tức là chất lượng của code tả – Test tích hợp có thể bao gồm cả test cài đặt – Test tích hợp còn nhằm kiểm tra độ tin cậy của hệ thốngCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 80
  81. 81. Testing ToolsCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 81
  82. 82. Kế hoạch kiểm thử & tài liệu• Như các công đoạn khác trong tiến trình phần mềm, kiểm thử phải có kế hoạch và tài liệu• Tài liệu bao gồm [IEEE,83] – Test plan: Chuẩn IEEE 1012 – Test design – Test cases: Mỗi test case mô tả • Input • Output mong đợi • Các điều kiện thực hiện – Test procedure: Đặc tả chuỗi các hoạt động để thực hiện test – Test report: Cung cấp thông tin về việc thực hiện test Test plan theo IEEE 1012CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 82
  83. 83. Các kỹ thuật test thủ công• Đọc (reading) – Các thành viên inspection – Đọc, đọc đi đọc lại sẽ đọc code thành từng • Đặc tả yêu cầu, cụm (chunk) và phân tích tìm lỗi: • Design Lỗi dùng dữ liệu: biến – Peer review không khởi tạo, vượt chỉ • Đọc và đánh giá code lẫn số mảng, con trỏ nguy nhau hiểm • Nặc danh Lỗi khai báo: không khai• inspections báo, hoặc khai báo cùng tên trong các khối lồng – Kiểm tra thực hiện bởi một đội nhau (thường là 4 người) Lỗi tính toán: chia 0, tràn – Mỗi người nhận tài liệu và số code Lỗi trong phép toán quan – Sau vài ngày nghiên cứu, cả 4 hệ: dùng > thay vì >=; thứ ngồi lại để inspection tự ưu tiên. Lỗi trong dòng điều khiển: – Tác giả code có mặt nhưng lặp (n+1) lần thay vì n lần! không phát biểu, chỉ trả lời Lỗi giao tiếp: tham số câu hỏi (nếu có) truyền sai kiểu, sai số tham số…CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 83
  84. 84. Các kỹ thuật test thủ công(tt) – Quá trình inspection để phát • Đánh giá kịch bản hiện lỗi, không sửa. – Dựa trên các use case và• Walkthroughs senario (mô tả use case) – Trong quá trình test có thể dùng dữ liệu đơn giản để chỉ • Chứng minh tính đúng lỗi. đắn: {P} S {Q} – Giả lập bằng tay • Trừu tượng hóa từng – Walkthroughs và inspection có thể thực hiện ở bất kỳ giai buớc đoạn nào của tiến trình phần – Ngược lại với stepwise mềm miễn là tài liệu rõ ràng refinement (top-down) và test được. – TTH từng buớc áp dụng – Khuyết điểm của PP: với bottom-up: từ cụ thể • Người tham gia có kiến thức tổng quá hóa lên cái trừu nông cạn tượng • Không đủ kiến thức về lĩnh vực đang xétCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 84
  85. 85. Kỹ thuật kiểm thử bao trùm (coverage-based testing)• Kiểm thử bao trùm – Số chỉ thị – Số đường đi / nhánh chương trình• Chương trình mô hình hóa bởi đồ thị – Control graph: mô hình hóa các dòng điều khiển – Data flow: mô hình hóa dòng xử lí từ khai báo 1 biến tới kết quả – Mô hình hóa đặc tả yêu cầu bởi đồ thị: mô hình dòng dữ liệu (DFD)• Dùng độ đo McCabe để tính số test case – V(G) = số nhánh độc lập = số nút đk + 1CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 85
  86. 86. Ví dụ về control graph1. Procedure sort(var x:array; n:integer);2. Var i,j,save:integer;3. Begin4. for i:=2 to n do5. for j:=1 to i do6. if x[i]<x[j] then begin7. save:=x[i];8. x[i]:=x[j];9. x[j]:=save10. end11. End;Số đường đi độc lập: V(G)=4- 1-2-3-4-11- 1-2-3-4-5-6-7-8-9-10-4-11- 1-2-3-4-5-6-10-4-11- 1-2-3-4-5-4-11CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 86
  87. 87. Kỹ thuật test dựa trên lỗi (fault)• Seed fault – Một số nguyên tắc thay thế: – Cài một số lỗi vào module • Thay hằng bởi hằng khác – Kiểm thử để phát hiện lỗi • Thay biến bởi biến khác • Thay hằng bởi biến – Trong quá trình kiểm thử phát hiện lỗi “cài cắm vào” sẽ phát • Thay phép toán số học bằng phép toán số học khác hiện ra một số lỗi “thật” • Thay phép toán logic bằng• Kiểm tra bằng cách thay thế phép toán logic khác – Giả sử có chương trình P cần • Thêm phép toán một ngôi kiểm thử. P sinh ra kết quả • Xóa một dòng lệnh đúng với một số test case (vd – Ví dụ T1 và T2) • If x<4.5 then – Sửa P tại 1 chổ nào đó P’ Có thể thay thế bởi: – Kiểm thử P’ với T1 và T2 • If x>4.5 then – Giả sử P’(T1)=P(T1) và • If x=4.5 then P’(T2)=P(T2) • If x<4.6 then – T1 có ý nghĩa trong test vì nó • If x<4.4 then có thể cho biết có sai sót trong • … P hoặc P’CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 87
  88. 88. Kỹ thuật test dựa trên sai lầm (error)• Test các giá trị biên • Vd: – ON point: điểm nằm trên biên – Đặc tả của một miền con • Nếu 80%<Tỉ lệ <=100% – OFF point: điểm nằm cạnh “chắc chắn” biên (trong hoặc ngoài) • Nếu 50<= tỉ lệ <= 80% “khá chắc chắn” • Nếu 0<= tỉ lệ <50% “không chắc chắn – Các test case – Nếu có n miền con Di, i=1..n • Test n ON point Tỉ lệ =0% (ON) Tỉ lệ = 70% (OFF) • Test ít nhất 1 OFF point cho Tỉ lệ = -1 % (OFF) Tỉ lệ = 80% (ON) Tỉ lệ = 1% (OFF) Tỉ lệ = 99% (OFF) mỗi biên Tỉ lệ =49% (OFF) Tỉ lệ = 100% (ON) – Lưu ý: các miền có thể có ON Tỉ lệ = 50% (ON) Tỉ lệ = 1000% (OFF) point chung hoặc OFF point chung.CÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 88
  89. 89. Các nghiên cứu thực nghiệm• Meyer, 88 – 85% lỗi được phát hiện trong quá trình inspection ở các giai đoạn đặc tả, thiết kế, code review – Inspection là tốt hơn walkthroughs• Collofello,89 – Phân tích 700000 dòng code phát triển bởi 400 người phát hiện 676 lỗi, trong đó • 54% phát hiện bởi xem xét thiết kế • 33% phát hiện bởi xem xét code • 38% phát hiện bởi testCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 89
  90. 90. Tổng kết chương• Test thủ công • Bài tập: 1 14 trang – Peer review 442,443 – Inspection – Walkthroughs• 3 kỹ thuật – Test bao trùm – Test dựa trên lỗi – Test dựa trên sai lầmCÔNG NGHỆ PHẦN MỀM TS. TRẦN CAO ĐỆ 2010 Trang 90
  91. 91. Chương 14: Bảo trì phần mềmChương 19: Công cụ phần mềm Tự đọc thêm
  92. 92. Lưu ý ngày thi!

×