Công nghệ phần mềm
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Công nghệ phần mềm

  • 1,408 views
Uploaded on

Slide CNPM DH Bach Khoa TPHCM

Slide CNPM DH Bach Khoa TPHCM

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,408
On Slideshare
1,408
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
61
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Bài Giả GiảngCông Nghệ Phần Mềm Software Engineering
  • 2. Giáo viên & Giao tiếp g g dạy p giảng ạy ThS Nguyễn Cao Trí – caotri@hcmut.edu.vn http://www.cse.hcmut.edu.vn/~caotri Room 109 A5 – Trung tâm Kỹ thuật Điện toán Tel: 8647256 – 5370 Mobile: 091 391 6290 Hobbies: Automation , Flying Model http://www.rc-easy.net • Tài liệu download trên website file: TailieudientuCNPM- file: TailieudientuCNPM- PrintableVersion. PrintableVersion.ppt • Học thế nào? Hỏi ngay trên lớp • Bảng mã sử dụng là Unicode dựng sẵn • Các bài tập nộp bằng email, dạng file *.ZIP • Email phải ghi rõ nội dung file đính kèm là gì bằng tiếng ViệtTrường Đại Học Bách Khoa - Khoa Công Nghệ Thông TinCopyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 2
  • 3. Giới thiệu môn học ệ ọ• Nội dung môn học – Giới thiệu các khái niệm cơ bản về công nghệ phần mềm – Mục tiêu của sản xuất phần mềm và công nghệ phần mềm ấ ầ ề ầ ề – Các mô hình sản xuất phần mềm – Quy trình sản xuất và quản lý dự án phần mềm• Tài liệu tham khảo – Introduction to Software Engineering – Ronald J. Leach – CRC Press (Thư viện A2 MS: 9075802004) ess ( ư v ệ S: 907580 00 ) – Software Engineering – Ian Sommerville – Fifth edition (Thư viện A3 MS: 200032)• Hình thức kiểm tra – Giữa kỳ + Cuối kỳ + Bài tập – Hình thức kiểm tra: trắc nghiệm khách quan – open book – Đánh giá kêt quả: tương đối - phi tuyến Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 3
  • 4. ???????? & !!!!!!!!• Công Nghiệp & Công Nghệ• Công ô Nghiệp Phần Mềm (CNpPM) ệ ầ ề• Công Nghệ Phần Mềm (CNPM)• Công nghiệp phần mềm & các công nghiệp khác – Giống – Khác• Có hay không (những) công nghệ cho sản xuất phần mềm?• Có cần thiết phải có công nghệ cho sản xuất phần mềm không, khi sản xuất phần mềm là hoạt động sản xuất “đặc ô ả ấ ầ ề à ộ ả ấ ặ biệt” vì không thể nói làm một phần mềm như sản xuất một lon coca. coca.Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông TinCopyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 4
  • 5. Đặc tính của sản p ặ phẩm p phần mềm• Software = Program• Software product = Program + Document + Support• Loại sản phẩm phần mềm – Generic Product: là sản phNm đóng gói và bán rộng rãi trên thị trường. – B Bespoke P d t là sản phNm đ k Product: ả hN được phát t iể th yêu cầu đặ thù của hát triển theo ê ầ đặc ủ từng khách hàng.• Các đặc tính quan trọng của sản phẩm phần mềm – M i i bili phần mềm có thể thay đổi thuận tiện theo yêu cầu của Maintainability: hầ ề ó hể h h ậ iệ h ê ầ ủ người dùng – Dependability: tính ổn định, bảo mật và an toàn của phần mềm. Không gây tổn hại về vật chất hay kinh thế cho hệ thống thống. – Efficiency: Sử dụng hiệu quả tài nguyên của hệ thống cho công việc – Usability: giao diện và phương thức phải phù hợp với người dùng đồng thời đáp ứng đúng yêu cầu của người dùngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 5
  • 6. Software - Đủ hay Thiếu? y• Phần mềm được viết ngay từ khi có những máy tính programable đầu tiên. Được quan tâm và phát triền từ rất ầ tiên. ê â à á ề ừ ấ sớm• Có rất nhiều phần mềm đã được viết Không thiếu phần mềm• Thực tế việc sản xuất phần mềm không đáp ứng kịp yêu ự ệ p g p g ịp y cầu của người sử dụng: dụng: – Không đủ về số lượng – Thiếu về chất lượng – Không kịp về thời gian Phần mềm không đáp ứng đủ cho người dùngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 6
  • 7. Nguyên nhân khách quan g y q• Số lượng phần mềm phải được hiểu là số đầu/loại phần mềm được sử dụng cho từng mục tiêu ứng dụng. dụng.• Nhu cầu sử dụng phần mềm là rất lớn – Nhiều ngành nghề cần dùng phần mềm máy tính – Mỗi ngành nghề cần nhiều loại phần mềm khác nhau ỗ ề ầ ề ầ ề – Mội loại phần mềm cần nhiều cấp độ khác nhau theo trình độ người dùng• Chất lượng phần mềm cũng chưa đáp ứng tốt hoàn toàn người sử dụng: dụng: – Tính customize rất cao của sản phẩm phần mềm. – Trình độ sử dụng khác nhau và điều kiện hạ tầng ứng dụng khác nhau• Nhu cầu phần mềm thường rất cấp bách – Tầm nhìn và chiến lược chưa đầu đủ của người sử dụng – Không có kế hoạch lâu dài – Phải thay đổi theo từng đối tượng người dùngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 7
  • 8. Nguyên nhân chủ quan g y q• Tính chuyên nghiệp trong sản xuất phần mềm chưa cao Các dữ liệu quan sát được – Cứ 6 đề án triển khai thì có 2 bị huỷ bỏ – Trung bình thời gian thực hiện thực tế bị kéo dài 50 % (cá biệt 200- 300%) – Các đề án lớn dễ thất bại – 3/4 các hệ thố lớ có lỗi khi th thi á thống lớn ó thực – Quá trình phân tích yêu cầu (5 % công sức): để lại 55 % lỗi, có 18 % phát hiện được – Quá trình thiết kế (25 % công sức): để lại 30 % lỗi, có 10 % phát ế ế ể ỗ hiện được – Quá trình mã hoá, kiểm tra và bảo trì: để lại 15 % lỗi, có 72 % phát hiện đượcTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 8
  • 9. Nguyên nhân chủ quan ( ) g y q (tt)Lý do của những hệ quả trên – Phát triển phần mềm giống như một “nghệ thuật”, chưa được xem ể ầ ề ố ộ như một ngành khoa học – Quy trình phát triển phần mềm chưa được thống nhất – Phải viết l i s/w mỗi khi có sự th đổi về ngôn ngữ, h/ h ặ o/s iết lại / ỗi ó thay ề ô ữ h/w hoặc / – Chưa đạt được 1 chuẩn cho việc đo lường hiệu suất và sản phẩm – Độ phức tạp của phần mềm quá cao đối với 1 “kiến trúc sư” – Kỹ thuật đặc tả để lại sự nhập nhằng trong các yêu cầu phần mềm ỹ ậ ặ ả ể i ậ ằ á ê ầ ầ ề – Làm việc nhóm không đúng kỷ luật gây ra các lỗi CẦN PHẢI CÓ MỘT/NHIỀU CHUẨN QUY TRÌNH TRONG SẢN Ầ Ả Ó Ộ Ề Ẩ Ì Ả XUẤT PHẦN MỀM ĐỂ NÂNG CAO TÍNH CHUYÊN NGHIỆP CỦA NỀN SẢN XUẤT ĐẶC BIỆT NÀY CẦN CÔNG NGHỆ CHO CÔNG NGHIỆP PHẦN MỀMTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 9
  • 10. Định nghĩa “Công nghệ phần mềm” ị g g g ệp• Công Nghệ Phần Mềm là sự thiết lập và sử dụng các nguyên tắc khoa học nhằm mục đích tạo ra các phần ê ắ ằ í á ầ mềm một cách kinh tế mà các phần mềm đó hoạt động hiệu quả và tin cậy trên các máy tính. ệ q ậy y tính.• Công nghệ phần mềm là một quy trình có hệ thống được sử dụng trong quá trình phân tích, thiết kế, hiện thực, kiểm tra và bảo trì để bảo đảm các sản phẩm phần mềm được sản xuất và hoạt động: hiệu quả, tin cậy, hữu động: dụng, nâng cấp dễ dàng (modificable), khả chuyển (portable), khả kiểm tra (testable), cộng tác được với các hệ thống khác (interoperable) và vận hành đúng (correct). (correct).Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 10
  • 11. Cụ thể ụ• Efficiency: Phần mềm được sản xuất trong thời gian và điều kiện vừa phải. Phần Efficiency: phải. mềm vận hành đúng mức độ yêu cầu về công việc và thời gian. gian.• Reliablity: Phần mềm vận hành ổn định và tương tác được với các hệ thống ứng Reliablity: dụng• Usability: Phần mềm có thể dùng được bởi người sử dụng và với môi trường mà Usability: người sử dụng đang có. Chú ý tới giao diện, điều kiện hệ thống,… có. thống,…• Modifiability: Phần mềm có thể được thay đổi dể dàng, nhanh chóng khi yêu cầu Modifiability: của người sử dụng thay đổi. đổi.• Portability: Phần mềm có thể chuyển đổi dễ dàng sang các hệ thống khác mà không Portability: cần phải điều chỉnh lớn. Chỉ cần recompile nều cần thiết là tốt nhất. lớn. nhất.• Testability: Phầ mềmcó thể d0ượ kiể t dễ dà . Tốt nhất là đượ modull hó . Testability: Phần ề ó ược kiểm tra dàng dàng. hất được d hóahóa.• Reusability: Phần mềm hay một phần có thể được tái sử dụng cho các ứng dụng Reusability: khác. khác. Các modul có thiết kế tốt, độc lập và giao tiến đơn giản, cả về tình tương thích công nghệ phát triển Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 11
  • 12. Cụ thể ( ) ụ (tt)• Maintainability: thiết kế của phần mềm có thể được hiểu dễ dàng cũng như chuyển Maintainability: giao th ậ tiệ cho người khá t i thuận tiện h ười khác trong quá trình điề chỉnh, nâng cấp h th đổi th á t ì h điều hỉ h â ấ hay thay theo yêu cầu. cầu.• Interoperability: Phần mềm vận hành ổn định và đúng như mong đợi. Trên hệ Interoperability: đợi. thống nhiều người dùng (multi users) phần mềm vẫn hoạt động được với các vận hành khác của hệ thống. thống.• Correctness: Phần mềm phải tính toán đúng và tạo ra kết quả đúng và đúng với Correctness: mục tiêu ứng dụng của người dùng. dùng.• Các yêu cầu khác: khác: – Đúng tiến độ – Sử dụng hợp lý nguồn nhân lực phát triển – Chi phí phát triển thấp nhất Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 12
  • 13. Nội dung công việc của Software Engineering ộ g g ệ g gCông việc của software engineering bao gồm:• Phân tích hệ thống/vấn đề • Quản lý chất lượng• Xác định các yêu cầu • Huấn luyện yệ• Thiết kế phần mềm • Dự đoán tài nguyên• Viết phần mềm (coding) • Quản trị dự án• Kiểm tra và tích hợp hệ thống• Cài đặt và chuyển giao phần mềm hầ ề• Lập tài liệu• Bảo trìTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 13
  • 14. Một định nghĩa khác của CNPM ộ ị g• CNPM là các quy trình đúng kỷ luật và có định lượng được áp á dụng cho sự phát triển, thực thi và bảo trì các hệ á ể à ả ì á ệ thống thiên về phần mềm• Tập trung vào quy trình, sự đo lường, sản phẩm, tính trình, lường, phẩm, đúng thời gian và chất lượng Qui trình Đo lường Thời gian Chất lượng Tiêu h ẩ Tiê chuẩn Quản lý Dịch vụTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 14
  • 15. Mô hình phát triển phần mềm p pCác công đoạn chính tổng quát bao gồm 4 giai đoạn• Giai đoạn đặc tả: xác định các tính năng và điều kiện hoạt tả: động của hệ thống. (thu thập yêu cầu và phân tích) thống.• Giai đoạn phát triển: Thiết kế phần mềm (software triển: design), viết code (code generation g ), ( g• Giai đoạn kiểm tra: kiểm tra phần mềm (software testing), tra: kiểm tra tính hợp lý của phần mềm. mềm.• Giai đ đoạn bả trì: Sửa lỗ ( bảo trì: ử lỗi (correction), thay đổ môi trường ì ) h đổi ô ờ thực thi (adaptation), tăng cường (enhancement)Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 15
  • 16. Các mô hình sản xuất phần mềm pTùy theo quy mô và công nghệ phát triển, có các mô hình sản xuất khác nhau. ả ấ á nhau.• Mô hình tuần tự tuyến tính- waterfall tính-• Mô hình Prototyping - Evolutionary Development• Mô hình xoắn ốc – Boehm’s Spiral Model• Mô hình RAD – Rapid Application Development MÔ HÌNH NÀO TỐT HƠNMỗi mô hình phù hợp với trình độ phát triển, quy mô sản phẩm và yêu cầu ràng buộc cụ thể về thời gian và tính chất của hệ thống. thống.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 16
  • 17. Mô hình WaterFall – Sequency model q y• Mô hình phát triển phần mềm đầu tiên• Các công việc tiếp nối nhau một cách tuần tự• Đặt nền móng cho các phương pháp phân tích, thiết kế, kiểm tra… tra… Phân tích yêu cầu Thiết kế hệ thống ệ g & phần mềm Hiện thức và kiểm tra moduls Tích hợ à kiểm Tí h hợp và kiể tra tổng thể Chuyển giao và Bảo trìTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 17
  • 18. Mô hình WaterFall – Sequency model ( ) q y (tt)Bộc lộ một số khuyết điểm• Bản chất của phát triển phần mềm là quá trình lặp đi lặp ả ấ ủ á ể ầ ề à á ì ặ ặ lại chứ không phải tuần tự• Các bước thực chất không tách biệt hoàn toàn mà có ự g ệ chồng lấn và tham khảo lại• Bắt buộc khách hàng đặc tả tất cả yêu cầu một cách chính xác và đầy đủ ngay từ ban đầu• Khách hàng thường phải chờ đợi rất lâu để thấy được phiên bản đầu tiên của sản phẩm• Tồn tại “d l ” tích lũ trong nhóm là việc -> d á ồ “delay” í h lũy hó làm ệ dự án thường bị trể. trể.• Chỉ phù hợp cho dự án nhỏ, đơn giản. p ợp ự , g giản.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 18
  • 19. Mô Hình Prototype yp Hoạt động sản xuất Bản prototype Đặc tả Mô tả sơ lược Các bản trungcủa khá h hà ủ khách hàng Phát triển gian Kiểm thử Bản cuối cùngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 19
  • 20. Mô Hình Prototype – ưu & khuyết yp y• Prototype như là một cơ chế để nhận diện chính xác yêu cầu của khách hàng – Bản thân khách hàng chưa hiểu rõ yêu cầu của mình, cũng như các quy trình chưa được xác lập rõ ràng. – Khách hàng chưa hiểu rõ khả năng hổ trợ của hệ thống máy tính• Kích thích sự thích thú của người dùng với dự án• Prototype có thể bị “throw-away” -> Lãng phí ó ể “throw- ã í• Các process không được phân định rõ ràng• Hệ thống thông thường có cấu trúc lỏng lẻo ệ g g g g• Cần có những kỹ năng đăc biệt trong quản lý và phát triển• Khách hàng hối thúc nhà phát triển hoàn thành sản phẩm một khi thấy được các prototype đầu tiênTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 20
  • 21. Mô Hình Prototype – Ứng dụng yp g ụ g• Dùng cho các hệ thống nhỏ. Các chi phí khi thay đổi hệ nhỏ. thống là không quá lớn khia cần phải thay đổi sau khi thực hiệ prototype• Cần sự cấp bách về thời gian triển khai ngắn. Hệ thống ự p g ngắn. ệ g g cần được đưa vào ứng dụng từng phần trong khoảng thời gian nhất định. định.• Trong trường hợp những hệ thống mà việc đặc tả các yêu cầu là rất khó và không rõ ràng ngay từ đầu. đầu.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 21
  • 22. Mô hình Xoắn Ốc - Boehm’s Spiral Model p Xác định công việc á ô ệ Đánh giá rủi ro Hoạch định đề tài Phát triển sản phẩm• Được thực hiện theo một chuỗi lặp kiểu xoắn ốc, mỗi lần ỗ ỗ lặp cải thiện sản phẩm• Có phương pháp đánh giá rủi ro• Có thể áp dụng prototype• Mỗi lần lặp được cải thiện cho thích nghi với bản chất của đề ánTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 22
  • 23. Mô hình RAD Application Testing &Business modeling Data Process modeling generation Turnover modeling• Rapid Application Development là mô hình tuần tự tuyến tính có thời gian phát triển rất ngắn• Sử dụng các thành phần có sẵn càng nhiều càng tốt• Sử dụng công cụ lập trình ở dạng tự động sinh mã chứ ụ g g ụ ập ạ g ự ộ g không phải các ngôn ngữ truyền thống• Ph thuộc vào công nghệ phát triển có tính reusable cao. Phụ h ộ à ô hệ há iể ó í h bl cao.• Partten system development Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 23
  • 24. Các tiêu chuẩn dùng trong CNpPM g g p• The capability Maturity Model (CMM) của Software Engineering Institue (SEI) - Đại học Carnegie Mellon. Mellon. – Chú trọng đến tính hệ thống và khả năng quản trị của các công ty phần mềm hơn là một quy trình (process) cụ thể.• The process Improvement Paradigm (PIP) của Software Engineering Laboratory (SEL) – NASA’s Goddard Space Flight Center – Tương tự như CMM, chú trọng đến tính hệ thống và những hướng dẫn để tăng cường tính năng của các quá trình quản lý.• Các chuẩn khác của Department of Defense – MIL – STD 2167A ; MIL-STD 1574A ; MIL-STD 882C• The electronic Industries Association (EIA) chuẩn SEB-6-A SEB-• The European ESPRIT project• International Standards Organisation - ISO 9001• United Kingdom MOD 0055 Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 24
  • 25. Chuẩn CMM •Continuous Improvement Optimized •Các hệ thống quality control và qualify đã được sử dụng hiệu quả (Level 5) •Có khả năng dự đoán (Predictability) Managed •Các quy trình quản lý và tiêu chuẩn Risk được chi tiết hóa đ hi iế hó (Level 4) Defined •Xác lập các tiêu chuẩn quản lý •Các vấn đề documentation đã xác lập (Level 3) Competiti Repeatable •Bắt đầu có khả năng quản lý Bắt (Level 2) iveness •Quản lý dựa vào kinh nghiệm tương tự Initial •Largely Ad-hoc (Level 1) •Phụ thuộc vào cá nhânTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 25
  • 26. Chương 2 Project ManagementSub-Team trong Software ProjectsProject EstimationP j t E ti tiProject SchedulingProject Management Tools
  • 27. Tại sao cần Project management Phát triển phần mềm hiện đại làm theo teamworks Cần quản lý và kiểm soát được rủi ro (Risk) trong quá trình sản xuất Các dự án phần mềm đòi hỏi nhiều nguồn nhân lực với chuyên môn khá nhau ô khác h Tính tích hợp công nghệ cao và sự thay đổi nhanh chóng của công nghệ Phải bả đả tí h chuyên nghiệp t bảo đảm tính h ê hiệ trong phát t iể dự á phần hát triển án hầ mềm: Bảo đảm lịch trình của dự án Điều phối và khai thác tối đa nguồn nhân lực hiện có Bảo đảm chất lượng của sản phNm Khả năng khắc phục các sự cố xảy ra khách quan Các dự án càng lớn càng cần có sự quản lý chặt chẻ và đồng bộTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 27
  • 28. SUB Team SUB-Team trong software engineering Teamwork là mô hình hiện Công ty phần mềm tại cho hầu hết các dự án phần mềm: Project 1 Khả năng chuyên nghiệp hóa cao Team Team Hiệu quả trong quản lý, giao 6 5 tiếp và điều hành Một software project team ộ p j Team Team Project 2 1 2 được tạo ra từ nhiều sub- teams Team Team Các sub-team không nhất thiết 4 3 là một nhóm người mà có thể là 1 người Các sub-team không nhất thiết tồn tại suốt quá trình của một Project 3 dự án hầ d á phần mềm ềTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 28
  • 29. Các Sub-Team Sub Team System analysis Planning Team Requirements Team System Design Team Vai trò Implementation Team I l t ti T Tesing & Intergration Team nhiệm vụ ệ Training Team Delivery & Installation Team của các Maintenance Team Quality Assurance Team SUB Team Metrics Team Documentation Team System Administration Team Reuse & Reengineering Team g gTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 29
  • 30. Vai trò & nhiệm vụ các Sub-Team Sub Team System analysis Planning Team System Analysis Xác định tính khả thi của dự án Requirements Team • Phân tích chi phí (Cost analysis) System Design Team • Dự đoán lợi nhận (Estimate revenues) Implementation Team I l t ti T • Tiên liệ các khó khăn về kỹ th ật liệu ề thuật Tesing & Intergration Team và công nghệ Training Team •Sau khi nghiên cứu khả thi, nhóm Delivery & Installation Team này sẽ làm việc với Requirement Maintenance Team Team để nhận feedbacks Quality Assurance Team •Nếu dự án được phát triển theo mô hình tương tác cao như Metrics Team Prototype/Spiral model thì tính tương Documentation Team tác và feedback là rất quan trọng kể System Administration Team cả với các nhóm khác. Reuse & Reengineering Team g gTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 30
  • 31. Các Sub-Team Sub Team System analysis Planning Team Requirements Team Planning Team Nhóm này có nhiệm vụ xây dựng tổng System Design Team thể tất cả các kế hoạch quản trị dự án Implementation Team I l t ti T và bảo đảm các tiến trình diển ra đúng Tesing & Intergration Team tiến độ đã định Training Team •Xây dựng các kế hoạch thực hiện •Lập các time frame cho các tiến trình Delivery & Installation Team •Kế hoạch sử dụng tài nguyên của hệ Maintenance Team thống bao gồm cả nhân lực Quality Assurance Team •Các kế hoạch dự phòng và điều chỉnh Metrics Team khi có sự cố Documentation Team System Administration Team Reuse & Reengineering Team g gTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 31
  • 32. Các Sub-Team Sub Team System analysis Requirement Team Planning Team Tiếp xúc khách hàng và xác định đầy Requirements Team đủ, hoàn chỉnh và chính xác các yêu System Design Team cầu cho dự án Implementation Team I l t ti T •Dùng các phương thức gặp gở chính thức và bên lề để xác định các yêu Tesing & Intergration Team cầu của hệ thống Training Team •Nếu không có khách hàng, có thể Delivery & Installation Team tiếp xúc với các user tiềm năng Maintenance Team Sau khi xác định các yêu cầu, nhóm này sẽ làm việc với System Design Quality Assurance Team Team để nhận các feedback. Metrics Team Nếu dự án được phát triển theo mô Documentation Team hình tương tác cao như System Administration Team Prototype/Spiral model thì tính tương tác và feedback là rất quan trọng kể Reuse & Reengineering Team g g cả với các nhóm khácTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 32
  • 33. Các Sub-Team Sub Team System analysis System Design Team Planning Team Xây dựng thiết kế chi tiết của hệ Requirements Team thống sau khi các yêu cầu đã được System Design Team xác định. Implementation Team I l t ti T Nếu sử dụng mô hình Waterfall Waterfall, nhóm này phải feedback cho Tesing & Intergration Team nhóm Requirement những khó Training Team khăn nếu có. Delivery & Installation Team Sau khi hoàn chỉnh thiết kế nhóm kế, Maintenance Team này phải cộng tác với Implementation Team để nhận Quality Assurance Team feedback. Metrics Team Nếu dự án được phát triển theo Documentation Team mô hình tương tác cao như System Administration Team Prototype/Spiral model thì tính tương tác và feedback là rất quan Reuse & Reengineering Team g g trọng kể cả với các nhóm khácTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 33
  • 34. Các Sub-Team Sub Team System analysis Planning Team Implementation Team I l t ti T Phát triển hệ thống theo thiết kế Requirements Team đã có. System Design Team • Coding Implementation Team I l t ti T • Kiểm tra cấp Module ể ấ d l Tesing & Intergration Team Sau khi hoàn tất chương trình, nhóm này sẽ cộng tác với nhóm Training Team Tesing & Integration để kiểm tra Delivery & Installation Team các module á d l Maintenance Team Nếu dự án được phát triển theo Quality Assurance Team mô hình tương tác cao như Prototype/Spiral model thì tính Metrics Team tương tác và f db k là rất quan á à feedback ấ Documentation Team trọng kể cả với các nhóm khác System Administration Team Reuse & Reengineering Team g gTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 34
  • 35. Các Sub-Team Sub Team System analysis Testing & Integration Team Planning Team Xây dựng thiết kế chi tiết của hệ thống Requirements Team sau khi các yêu cầu đã được xác định. Nếu sử dụng mô hình Waterfall, nhóm này System Design Team phải feedback cho nhóm Requirement Implementation Team I l t ti T những khó khă nếu có. hữ khăn ế ó Sau khi hoàn chỉnh thiết kế, nhóm này Tesing & Intergration Team phải cộng tác với Implementation Team để Training Team nhận feedback. Delivery & Installation Team Nhóm này có thể tiếp nhận các module rời ó ày t ể t ếp ậ odu e ờ rạc và kiểm tra sau đó tích hợp thành hệ Maintenance Team thống hoàn chỉnh. Quality Assurance Team Nếu dự án được phát triển theo mô hình tương tác cao như Prototype/Spiral model Metrics Team thì tính tương tác và feedback là rất quan Documentation Team trọng kể cả với các nhóm khác Nhóm này cũng có vai trò trong Interface System Administration Team Control Document để đặc tả các giao diện Reuse & Reengineering Team g g và giao tiếp giữa các thành phần trong hệ thốngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 35
  • 36. Các Sub-Team Sub Team System analysis Planning Team Requirements Team System Design Team Trainning Team g Implementation Team I l t ti T Chuẩn bị các công cụ và tài liệu Tesing & Intergration Team cho việc trainning cho người Training Team dùng Delivery & Installation Team •Kế hoạch trainning Maintenance Team •Các tài liệu giảng dạy Quality Assurance Team Metrics Team Documentation Team System Administration Team Reuse & Reengineering Team g gTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 36
  • 37. Các Sub-Team Sub Team System analysis Planning Team Requirements Team System Design Team Implementation Team I l t ti T Tesing & Intergration Team Training Team Delivery & Installation Team Maintenance Team Delivery & Installation Team Quality Assurance Team Nhiệm vụ là cài đặt hệ thống Metrics Team cho khách hàng và các hỗ trợ Documentation Team kỹ thuật trong cài đặt vận hành System Administration Team hệ thống. Reuse & Reengineering Team g gTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 37
  • 38. Các Sub-Team Sub Team System analysis Planning Team Requirements Team System Design Team Implementation Team I l t ti T Tesing & Intergration Team Training Team Maintenance Team Bảo trì hệ thống sau khi chuyển g Delivery & Installation Team giao và cài đặt Maintenance Team •Cập nhật sửa chữa Quality Assurance Team •Nâng cấp mở rộng Metrics Team Cộng tác chặt chẻ với nhóm Documentation Team implementation để thực hiện System Administration Team việc maintenance Reuse & Reengineering Team g gTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 38
  • 39. Các Sub-Team Sub Team System analysis Quality Assurance Team Planning Team Nhóm này có 2 nhiệm vụ Requirements Team 1. Thiết lập các tiêu chuẩn cho các System Design Team quá trình sản xuất cũng như tiêu Implementation Team I l t ti T chuẩn thực hiện của sản phẩm phần mềm Tesing & Intergration Team 2. Cung cấp các cơ chế kiểm tra, Training Team kiểm soát nhằm đánh giá khả Delivery & Installation Team năng thỏa mãn các tiêu chuẩn Maintenance Team tương ứng của các nhóm làm việc. Các tiêu chuẩn này dùng trong nội bộ Quality Assurance Team và không chia sẻ với khách hàng. Metrics Team Các tiêu chuẩn có thể được công bố Documentation Team khi cần thiết, vì vậy cần được lưu System Administration Team trữ và báo cáo cho project manager để hoạt động với bộ Reuse & Reengineering Team g g phận Q&ATrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 39
  • 40. Các Sub-Team Sub Team System analysis Planning Team Metrics Team Requirements Team Lưu trữ các thông tin thống kê về System Design Team các hoạt động của các TEAm trong dự án. Implementation Team I l t ti T •Số lượng các yêu cầu Tesing & Intergration Team maintenance Training Team •Số lượng thực hiện dịch vụ Delivery & Installation Team maintenance •Số dòng code được viết Maintenance Team •Thời gian thực hiện từng công Quality Assurance Team việc Metrics Team Nhóm này làm việc với hầu hết Documentation Team các nhóm để cung cấp báo cáo về chất lượng, hiệu quả, đồng thời System Administration Team feedback cho các nhóm đó về Reuse & Reengineering Team g g hiệu quả công việc.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 40
  • 41. Các Sub-Team Sub Team System analysis Planning Team Requirements Team System Design Team Implementation Team I l t ti T Tesing & Intergration Team Documentation Team Training Team Nhóm này thực hiện các hoạt động thiết lập các tài liệu Delivery & Installation Team cho hệ thống Maintenance Team • Tài liệu về phân tích, thiết Quality Assurance Team kế, hiện thực, source Metrics Team code,.. code Documentation Team • Tài liệu hổ trợ : userguide, System Administration Team manual, support document Reuse & Reengineering Team g gTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 41
  • 42. Các Sub-Team Sub Team System analysis Planning Team Requirements Team System Design Team Implementation Team I l t ti T System Administrationm Tesing & Intergration Team Team Training Team Nhóm này có nhiệm vụ cung cấp và bảo đảm các hoạt động p ạ ộ g Delivery & Installation Team của các hệ thống hạ tầng kỹ Maintenance Team thuật cần thiết cho dự án Quality Assurance Team Nhóm này thông thường bao Metrics Team gồm cả Network Administration Documentation Team Team System Administration Team Reuse & Reengineering Team g gTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 42
  • 43. Các Sub-Team Sub Team System analysis Planning Team Requirements Team System Design Team Implementation Team I l t ti T Tesing & Intergration Team Reuse & Reengineering Training Team Team Delivery & Installation Team • Chọn l h lựa và quyết đ h việc à ế định ệ Maintenance Team reuse các module đã có Quality Assurance Team • Việc reengineering cũng cần Metrics Team thiết khi mà việc phát triển Documentation Team đòi hỏi phải dùng đến các System Administration Team code cũ khi công nghệ đã g Reuse & Reengineering g thay đổi. TeamTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 43
  • 44. Sub Team Sub-Team (tt) Có rất nhiều việc quản lý trong từng nhóm và từng công đoạn. Có khá nhiều nhóm -> nhiều manager, tuy nhiên nếu các nhóm này nhỏ thì th ờ là một người t á hó à hỏ thường ột ời trong nhóm hó sẽ là manager của team. Việc scheduling giữa các team phụ thuộc vào mô hình phát triển cụ thể là gì. Ví dụ nếu dùng mô hình Waterfall thì các công đoạn có thể đ hể được tích h í h hợp thành các b ớ lớ h hà h á bước lớn hơn, các nhóm á hó tham gia vào từng bước theo chức năng của mình.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 44
  • 45. Các nhóm trong mô hình Waterfall SPECIFICATION: Planning, System Analysis, QA, Metrics, Documentation, System Administration, Reuse & Reengineering DESIGN: QA Metrics, Documentation, System Administration, QA, Metrics Documentation Administration Reuse & Reengineering CODE:QA, Metrics Documentation CODE:QA Metrics, Documentation, System Administration, Reuse Administration & Reengineering TESTING & INTEGRATION: QA, Metrics, Documentation, System Administration, Reuse & Reengineering MAINTENANCE: Trainning, Delivery & Instalation,QA, Metrics, Trainning Instalation QA Metrics Documentation, System Administration, Reuse & ReengineeringTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 45
  • 46. Các nhân sự khác trong dự ánBên cạnh còn có một số nhân sự khác tham gia vào quá trình phát triển dự án nhưng có thể không được nêu tên một cách chính qui ể ể Human-Computer Interface Evaluation: Đánh giá khả năng thích hợp của giao diện cả như người dùng cấp thấp và cấp cao Tools Support P T l S t Person: N ười cung cấp và bả đả các công cụ cần Người ấ à bảo đảo á ô ầ thiết như tools, software, network vận hành theo yêu cầu của quá trình phát triển Software Economist: Sử dụng các mô hình đánh giá cần thiết để ước lượng chi phí phần mềm, phần cứng, resource và thời gian cần cho dự án hoàn tất Project Librarian: Có trách nhiệm lưu trữ và sắp xếp hệ thống tất cả các tài liệu của dự án Chuyên gia hỗ trợ: Một số dự án cần có những chuyên gia trong lĩnh vực tương ứng hổ trợ, tư vấn về mặt chuyên môn hay kỹ thuậtNHÂN SỰ CỦA CÁC TEAM CÓ THỂ THAY ĐỔI THƯỜNG XUYÊN TRONG QUÁ TRÌNH HOẠT ĐỘNG DO NHIỀU YẾU TỐTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 46
  • 47. Các yếu tố ảnh hưởng đến các team Nhân sự cần thay đổi theo từng công đoạn: các công đoạn cần nhiều nhân sự và cần thời gian dài như coding, testing & integration. Các Cá nguyên nhân khá h quan khá ê hâ khách khác: N hân sự thay đổi công việc: chuyên môn thay đổi, công nghệ mới cập nhật N hân sự nghĩ do thay đổi việc, bệnh, về hưu N hân sự mới: mang lại tư duy mới và công nghệ mới tuy nhiên phải cần thời gian tiếp cập g p ập Việc xây dựng các team là linh động theo từng dự án và cần có điều phối giữa các dự án theo từng tiến độ công việc việc.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 47
  • 48. Project management Dự đoán quy mô và độ phức tạp của dự án Xác định các team cần thiết cho hiện thực dự án Xác định kế hoạch dự đoán thời gian hoàn thành dự án Xác định các tài nguyên cần thiết cho dự án bao gồm phần mềm, hệ thống, …. Tính toán hi hí â dựng Tí h t á chi phí xây dự dự á án Xây dựng lô trình thực hiện dự án (smiletone) Thực hiện các công việc quản lý trong thời gian thực hiện dự án để bảo đảm đúng kế hoạch đã đề ra.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 48
  • 49. Các công việc của Project management trong thời gian th hiện dự án t i thực hiệ d á Quản trị nhân sự: điều phối, quản lý công việc,.. Phân bổ các tài nguyên của hệ thống theo kế hoạch Điều phối nhân sự: trong công ty và bên ngoài Xữ lý các phát sinh về thời gian biểu Quản lý các thay đổi yêu cầu của dự án Giải quyết các sự cố ngoài kế hoạch: máy móc hư hỏng, nhân sự thay đổi,.. Báo cáo cho lãnh đạo về dự án Giao tiếp với khách hàng g Staffs trainningTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 49
  • 50. Software Project Estimation Dự đoán điều gì? Quy mô của sản phNm sẽ được phát triển Các yêu cầu, resource cần thiết để có thể phát triển sản phNm thành công Để phát triển sản phẩm cần biết nhiều thông tin Máy tính cần cho phát triển y p Các công cụ cho Documentation g ụ Các phần mềm cơ bản như Thiết bị copy, lưu trữ compiler Công nghệ sử dụng Phương thức giao tiếp giữa các Lập trình viên bộ phận CASE Tools Size of Project Kiểm tra viên ể Quản lý Các gói phần mềm mà hệ thống Nhà thiết kế cần liên kết, tương tác. Các nhân sự khác Máy tính cho tesing ………. Máy tính cho trainningTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 50
  • 51. Project Size Kích thước được đo bằng “lines of code” lines code Làm thế nào để dự đoán được kích thước của một đề án phần mềm? Kính thước đo bằng số dòng code được viết để hoàn thành dự án ằ ố ế ể Dự án chưa thực hiện làm sao biết số dòng code sẽ được viết Phương pháp Analogy và Reasoning-by-Analogy Reasoning by Analogy Phân bố nhân lực cho dự án phần mềm trên cơ sở lines of code đã dự đoán. Đánh giá năng xuất của mỗi người trong dự án Metric data cho vấn đề estimated và phân bổ resource.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 51
  • 52. Phương pháp Analogy Analogy là gì ? Suy luận theo analogy? gy g y ậ gy Điều kiện để sử dụng phương pháp analogy: Có bài toán đã biết có bản chất tương tự Đã có giải pháp của bài toán đã biết Cách áp dụng analogy Xác định được các thông số tương ứng giữa 2 bài toán Áp dụng giải pháp của b i toán đ biế cho b i toán mới Á d i i h bài đã biết h bài i Với dự án phần mềm Xác định các dữ liệu của những vấn đề đã làm nhờ vào metric Phân tích dự án cần dự đoán thành các thành phần Xác định kích thước tương ứng từng phần với thông tin metric đã có loại trừ các kích thước các phần được reuse Tổng kích thước các phần kích thước dự ánTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 52
  • 53. Dự đoán nhân lực cho dự ánLines of new code Approximate Number f N b of •Thực tế không thể tăng tuyến tính Thực Software một cách đơn giản như thế Enginneers •Không phải tất cả nhân lực đều đồng 5,000 1 đều. 10,000 1 •Khi dự án càng lớn thì các vấn đề Khi á à lớ á ấ 20,000 2 quản lý giao tiếp và liên kết sẽ phức tạp hơn làm giảm năng xuất. 50,000 5 •Dự án lớn, các thay đổi ngoài dự kiến ự , y g ự 100,000 00 000 10 0 sẽ nhiều hơn nên năng xuất bị ảnh 200,000 20 hưởng. 500,000 50 •Còn nhiều khâu khác ảnh hưởng đến 1,000,000 1 000 000 100 dự án chứ không phải chỉ có coding. coding 2,000,000 200 5,000,000 500 Tính dựa trên thông số nào? 10,000,000 10 000 000 1,000 1 000 100,000,000 10,000Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 53
  • 54. Dự đoán nhân lực theo MetricLines of new code Approximate •Thiết lập bảng dự liệu theo số liệu thống Number f N b of kê mà metric team đã thực hiện từ trước. ê à ệ ừ ớ Software •Số liệu này chứa đựng các yếu tố khác về Enginneers quản lý và các công đoạn khác nhau của 5,000 7 một đề án tổng thể. 10,000 14 20,000 27 •Xây dựng một hàm dự đoán nhân lực cho dự án (person- 50,000 77 month )dạng 100,000 100 000 144 y = mx + b 200,000 288 với m, b được xác định bằng 500,000 790 phương pháp bình phương tối thiểu 1,000,000 1 000 000 1,480 1 480 (Xem công thức tính m, b ở trang ( ô hứ í h 2,000,000 3,220 71) 5,000,000 8,000 Dựa vào đó ta tính được số nhân lực cần thiết cho dự án. 10,000,000 10 000 000 15,960 15 960 Y thời gian thực hiện (person hời i h hiệ ( 100,000,000 160,027 month) X kích thước dự ánTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 54
  • 55. Ví dụDựa vào bảng trên ta tính được y = 0.002 x + 1.84 .Ví dụ với dự án kích thước 15,000 lines of code ta sẽ cần 32 person- person-month để giải quyết•Xây dựng bảng metric của các dự án tương tự ta tính được là cầnphân bổ bao nhiêu người là t hâ b hiê ười làm trong bao lâu. b lâ•Ví dụ bảng tính toán cho các dự án database Projects Domain Months Effort (person-month) Size Application 1 Graphics Utility 12 30 5000 Application 2 Graphics Utility 10 40 8000 Application 3 Graphics Utility 24 30 10000 Application A li ti 4 Graphics Utility G hi Utilit 36 100 20000 Application 5 Graphics Utility 12 30 5000 Application 6 Graphics Utility 24 30 10000 Application 7 Graphics Utility 48 90 25000 HẠN CHẾ CỦA PHƯƠNG PHÁP NÀYTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 55
  • 56. COCOMO Model Xác định cả 2 thông số là số nhân lực và thời gian phát triển Trình tự thực hiện Phân tích các yêu cầu của dự án ầ Xác định line of code của từng yêu cầu dự vào metric data Trừ các phần đã được xác định là reuse code p ợ ị Tổng các phần còn lại tính được K line of code Áp dựng công thức tính E = ab * K * exp(bb) D = cb * E * exp(db) E là số nhân lực tham gia vào dự án D là thời gian thực hiện dự ánTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 56
  • 57. COCOMO Model (tt) Các hệ số của công thức COCOMO ệ g Software Project type Ab Bb Cb DbSmall project, experienced team, flexible 2.4 1.05 2.5 0.38requirementHard real time real-time rewquirements and strict 3 6 3.6 1.2 12 2.5 25 0.32 0 32interoperabilityA mixture of the other two type of projects 3.0 1.12 2.5 0.35 Các giá trị E và D tính được phụ thuộc vào khả năng estimate giá trị line of code (K) của dự án. ị ( ) ựTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 57
  • 58. Project Scheduling Scheduling bao gồm: g g Xác dịnh các mốc tiến trình thực hiện dự án Phân bổ resource cho các tiến trình của dự án Quản trị và thực hiện các điều chỉnh cần thiết cho các tiến trình khi có sự thay đổi ngoài kế hoạch Phân bổ lại nguồn resource (thêm người) Phân bổ lại milestone của từng tiến trình Mục tiêu là bảo đảm deadline không bị thay đổi Phương pháp quản trị và điều chỉnh: FUNCTION POINT Các công cụ dùng trong scheduling : MS project, Cocomo2Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 58
  • 59. Activity network model T3 T9 15 ngày 15 ngày M1 14/7/99 M4 M6 25/8/99 T1 T6 04/8/99 8 ngày M3 5 ngày 25/7/99 T 11 7 ngày Start S T2 15 ngày T704/07/99 20 ngày M8 M7 5/9/99 11/8/99 T4 M2 T5 T 12 10 ngày 25/7/99 10 ngày à T 10 10 ngày à M5 15 ngày 18/7/99 T8 FINISH 25 ngày 19/09/99 Thiết lậ activity network: gồm các Mi lập ti it t k ồ á Minestone (M) và T k (T) t à Task Xác định critical path: có tổng thời gian thực hiện dài nhất Điều chỉnh các M-i để bảo đảm deadline Điều chỉnh các T-i bằng cách thay đổi/bổ sung nhân sự (Team) ề ỉ á ằ á ổ ổ â Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 59
  • 60. Activities Bar Chart –PERL chart PERL 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 START T4 T1 T4 M1Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 60
  • 61. Chương Ch ơ 3 Phân tích hệ thống (system analysis)•Những vấn đề trong phân tích hệ thống•Thu thập yêu cầu từ người sử dụng•Phân tích yêu cầu•Xác định tính năng hệ thống
  • 62. Mục tiêu của p ụ phân tích hệ thống ệ g• Khách hàng và nhà phát triển gặp nhau để thảo luận về yêu cầu của hệ thống phần mềm cần xây dựng ê ầ ủ ệ ố ầ ề ầ â• Nhà phát triển tìm hiểu, phân tích và kiểm chứng lại (validate) yêu cầu và biểu diễn nó bằng mô hình phân tích• Mô hình phân tích đặc tả toàn bộ nội dung : chức năng, dữ liệu nhập/xuất, các hoạt động của hệ thống cần phát triển ể• Xây dựng các từ điển dữ liệu định nghĩa các khái niệm đặc thù của hệ thống ý nghĩa cấu trúc … thống, nghĩa, trúc,… trúc,• Thống nhất với khách hàng về mô hình và tính năng của hệ thốngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 62
  • 63. Phân tích hệ thống ệ g• Phân tích hệ thống là bước đầu tiên rất quan trọng cho dự án phát triển phần mềm• Công việc phân tích hệ thống bao gồm – Thu thập yêu cầu và quy trình nghiệp vụ hiện tại – Phân tích và xác lập các quy trình sẽ được phát triển/thay thế bằng máy tính ể ế ằ – Xác thực các yêu cầu/tính năng của hệ thống• Kết quả của việc phân tích hệ thống là các tài liệu đặc tả tính năng hệ thống. Các tài liệu này thông thường ở dạng các sơ đồ, biểu đồ,.. thống. á à ệ à ố ô ờ á ồ ể đồ,.. ồ• Kết quả này dùng cho việc xác thực các tính năng của hệ thống với khách hàng• Kết quả này là đầu vào của quá trình tiếp theo là thiết kế hệ thống. thống.• Tùy thuộc vào công nghệ phát triển mà sử dụng các phương pháp phân tích phù hợp : cấu trúc hay OOP Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 63
  • 64. Những vấn đề trong phân tích hệ thống g gp ệ g• Cách biệt về chuyên môn của lĩnh vực cần phân tích• Sự hiểu biết của những người end user về quy trình làm việc và khả năng ứng dụng phần mềm cho công việc của họ• Những vấn đề về điều kiện hạ tầng hổ trợ hoạt động của hệ thống• Tính sẳn sàng thông tin của các hệ thống đang có sẽ tương tác với hệ thống cần xây dựng• Định hướng ứng dụng lâu dài chưa có/ chưa rõ ràng• Công cụ/ngôn ngữ sử dụng để đặc tả hệ thống / kết quả p phân tíchTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 64
  • 65. Q y Quy trình phân tích hệ thống p ệ g• Các bước chính Tìm hiểu và xây dựng lại – Thu thập thông tin hệ thống hiện ậ ô ệ ố ệ hiện trạng của hệ thống ệ ệ ố tại – Thu thập yêu cầu •Các quy trình hoạt – Phâ tí h yêu cầu Phân tích ê ầ động/nghiệp vụ – Xác lập tính năng hệ thống •Phương thức và ý nghĩa của – Xác thực tính năng hệ thống các quá trình xử lý •Dữ liệu của hệ thống Dữ •Điều kiện hạ tầng: thiết bị, con ngườiTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 65
  • 66. Q y Quy trình phân tích hệ thống p ệ g• Các bước chính – Thu thập thông tin hệ thống hiện ậ ô ệ ố ệ tại Xác định các yêu cầu – Thu thập yêu cầu – Phâ tí h yêu cầu Phân tích ê ầ •Các yêu cầu về chức năng Các của hệ thống – Xác lập tính năng hệ thống •Các yêu cầu về môi trường – Xác thực tính năng hệ thống vận hành: thiết bị, con người gTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 66
  • 67. Q y Quy trình phân tích hệ thống p ệ g• Các bước chính – Thu thập thông tin hệ thống hiện ậ ô ệ ố ệ tại – Thu thập yêu cầu Phân tích các yêu cầu – Phâ tí h yêu cầu Phân tích ê ầ •Phân tích các yêu cầu theo – Xác lập tính năng hệ thống quy trình sử lý – Xác thực tính năng hệ thống •Bổ sung các q y trình cho g quy phù hợp với máy tính •Yều cầu bổ sung các thông tinTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 67
  • 68. Q y Quy trình phân tích hệ thống p ệ g• Các bước chính – Thu thập thông tin hệ thống hiện ậ ô ệ ố ệ tại – Thu thập yêu cầu – Phâ tí h yêu cầu Phân tích ê ầ Xác lập tính ă Xá lậ tí h năng của hệ ủ – Xác lập tính năng hệ thống thống – Xác thực tính năng hệ thống •Xác lập các chức năng mà hệ thống sẽ bao gồm •Xác lập các điều kiện và môi trường hoạt độngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 68
  • 69. Q y Quy trình phân tích hệ thống p ệ g• Các bước chính – Thu thập thông tin hệ thống hiện ậ ô ệ ố ệ tại – Thu thập yêu cầu Xác thực tính năng hệ – Phâ tí h yêu cầu Phân tích ê ầ thống thố – Xác lập tính năng hệ thống – Xác thực tính năng hệ thống •Xác thực với người dùng về tính hợp lý và đầy đủ của các tính năng •Xác thực các quy trình nghiệp vụ g ệp ụ •Xác thực các ràng buộcTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 69
  • 70. Q y Quy trình phân tích hệ thống p ệ g• Các bước chính – Thu thập thông tin hệ thống hiện ậ ô ệ ố ệ tại – Thu thập yêu cầu – Phâ tí h yêu cầu Phân tích ê ầ – Xác lập tính năng hệ thống – Xác thực tính năng hệ thốngPhương pháp cấu trúc Phương pháp OOP Các bước được thực hiện Sử dụng UML: lược đồ Use case, Class đồng thời và sen kẽ nhau Thường sử dụng lược đồ: g ụ g ợ DFD, ERD, STD Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 70
  • 71. Phâ tích hệ thống theo h ớ phát triểnPhân í h hố h hướng há iể kỹ thuật lập trình cấu trúc Tiếp cận của phương pháp phát triển cổ điển cho bước phân tích hệ thống Các lược đồ DFD, STD, ERD
  • 72. CÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNH Process Specification (PSPEC) Lược đồ DFD •Mô hình chức năng và dòng thông tin: DFD, PSPEC Lược đồ dòng hả dò chảy •Mô tả dòng thông tin di chuyển Mô Lược đồ quan (flow) xuyên qua các hệ thống hệ thực thể dữ liệu Từ điển thiên về phần mềm. dữ liệu •Diển tả các tương tác xuất nhập dữ liệu với con người và các hệ thống khác Lược đồ dịch chuyển •Lưu đồ dòng chảy dữ liệu DFD trạng thái (Data Flow Diagram) cung cấp 4 ký hiệu cơ bản để mô hình sự di chuyển của dòng thông tin •Mở rộng của Ward & Mellor; ộ g ; Hatley & Pirbhai cho realtimeTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 72
  • 73. CÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNH Process Specification (PSPEC) Lược đồ STD •Mô hình hành vi của hệ thống Lược đồ dòng hả dò chảy •Lược đồ dịch chuyển trạng thái Lược Lược đồ quan hệ thực thể dữ liệu (STD) thể hiện Từ điển • Các trạng thái khác nhau dữ liệu của hệ thống • Sự dịch chuyển giữa các trạng thái đó Lược đồ dịch chuyển trạng thái •Mô tả chi tiết hơn điều kiện xảy ra của các hành vi •Cung cấp một hình ảnh động về Control Specification (CSPEC) hệ thốngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 73
  • 74. CÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNHĐặc tả Process Specification (PSPEC)từ điểndữ liệu Lược đồ ERD •Đặc tả các thông tin về dữ liệu của hệ thống Lược đồ dòng hả dò chảy •Cấu trúc dữ liệu Cấu Lược đồ quan hệ thực thể dữ liệu •Các quan hệ và ràng buộc dữ Từ điển liệu dữ liệu Lược đồ dịch chuyển trạng thái Control Specification (CSPEC) Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 74
  • 75. CÁC YẾU TỐ CĂN BẢN CỦA MÔ HÌNHĐặc tả Process Specification (PSPEC)từ điểndữ liệu Từ điển dữ liệu •Làm rõ các khái niệm và thuật ngữ trong hệ thống Lược đồ dòng hả dò chảy •Nếu lên ý nghĩa và phạm vi sử Nếu Lược đồ quan dụng của các khái niệm này hệ thực thể dữ liệu Từ điển •Xác định các cấu trúc thông tin dữ liệu cần thiết Lược đồ dịch chuyển trạng thái Control Specification (CSPEC) Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 75
  • 76. LƯỢC ĐỒ DÒNG CHẢY DỮ LIỆU ( Ợ Ệ (DFD) )• Được xây dựng từ 4 phần tử chính – Thực thể: tạo ra hoặc tiêu thụ thông tin, nằm bên ngoài biên giới của thể phạm vi thông tin hệ thống – Chức năng xử lý thực hiện chức năng nào đó, tiêu thụ và tạo ra lý: thông tin, nằm bên trong phạm vi thông tin hệ thống – Thông tin hay dữ liệu – Kho dữ liệu lưu trữ dữ liệu mà được sử dụng bởi nhiều chức năng liệu: ệ ệ ợ ụ g g xử lý Chức năng Kho Dữ Liệu Thực thể ể xử lý Dữ liệuTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 76
  • 77. LƯỢC ĐỒ DÒNG CHẢY DỮ LIỆU ( ) Ợ Ệ (t.t)• DFD được xây dựng qua nhiều mức khác nhau: mức 0, 1, nhau: 2…• DFD mức sau chi tiết hơn mức trước• Process Specification (PSPEC) bổ sung cho DFD• Tính liên tục của dòng dữ liệuTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 77
  • 78. Kỹ thuật p ỹ ậ phân tích hệ thống ệ g• Tiếp xúc, phỏng vấn các người dùng trong hệ thống thu thập các thông tin về nghiệp vụ của người dùng ậ á ô ề ệ ủ ờ ù• Thiết lập đoạn văn miêu tả chức năng (processing narrative) cho hệ thống cần xây dựng• Xây dựng DFD ở các mức khác nhau – Thiết lập sơ đồ ngữ cảnh (DFD mức 0) – Phân hoạch DFD vào các mức cao hơn – Sử dụng phương pháp duyệt văn phạm. – L ô l ô t â th tí h liê t của dò dữ liệ Luôn luôn tuân theo tính liên tục ủ dòng liệu• Viết PSPEC cho các chức năng của DFD mức cao nhấtTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 78
  • 79. Xây dựng DFD – Ví dụ y ự g ụ • Phần mềm SafeHome: Thiết lập đoạn văn miêu tả xử lý SafeHome: • DFD mức ngữ cảnh: nhận diện các thực thể và dữ liệu cảnh: input, outputBảng điều khiển Lệnh và dữ liệu Thông tin hiển thị Màn hình SafeHome Kiểu báo động System Chuông Trạng thái cảm ứng Tần số của số điện thoại Bộ cảm ứng Đường điệ th i Đ ờ điện thoại Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 79
  • 80. Xây dựng DFD – Ví dụ y ự g ụBảng điều khiển DFD mức 1: hình thành Yêu cầu một số chức năng chính Cấu hìnhLệnh và dữ liệu cấu hình hệ thống Tương tác Thông số cấu hình với User Start/Stop Màn hình Cấm/ Maät maõ Cho phép Thông báo Thoâng tin hieån thò Xử lý Xác nhận mật mã mật mã Hiển thị Thông tin cảm ứng Theo dõi Kiểu báo động chuông Chuông Traïng thaùi caûm öùng cảm ứng Tần số của điện thoạiBộ cảm ứng Đường điện thoại Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 80
  • 81. Mô hình hành vi STD – Ví dụ ụ Đầy giấy và sẵn sàng Rảnh ———————— ———————— Mô hình hành vi hệ Yêu cầu copy Yêu cầu đọc lệnh thống máy photocopy Đọc lệnh Copy xong ———————— Đầy giấy yg y Yêu cầu đọc lệnh ———————— Yêu cầu đọc lệnhThực hiện copy ự ệ py Nạp giấy Hết giấy ———————— Yâu cầu nạp giấy Kẹt giấy Hết kẹt giấy ———————— ———————— Yêu ầ ử Yê cầu xử lý lỗi Yêu cầu đọc lệnh Xử lý lỗi Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 81
  • 82. Tự điển dữ liệu ự ệ• Nhiều phần tử được tạo ra trong mô hình phân tích: dữ tích: liệu, hứ ă điều khiển liệ chức năng, điề khiể …• Phải có một cách thức quản lý các phần tử đó sao cho hiệu quả Từ điển dữ liệu• Định nghĩa: Từ điển dữ liệu là một danh sách có tổ chức của nghĩa: tất cả các phần tử dữ liệu cần thiết cho hệ thống. Các phần tử thống. được định nghĩa chính xác và chặt chẽ sao cho cả phân tích viên ợ ị g ặ p và khách hàng cùng chia sẻ một suy nghĩ về chúng. chúng.• Từ điển dữ liệu thường được hiện thực như là một phần của công cụ CASE. CASE.• Mỗi phần tử bao gồm những thông tin: tên, bí danh, được tin: dùng ở đâu/như thế nào, đặc tả nội dung và thông tin phụ trợTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 82
  • 83. Tự điển dữ liệu – Ví dụ ự ệ ụ• Ví dụ phần tử dữ liệu số điện thoại Tên: Số điện thoại ố ệ Bí danh: Không Được dùng ở đâu/như thế nào: output của Thiết lập điều kiện báo động ế ề input của Quay số Đặc tả nội dung: số điện thoại = [ mở rộng địa phương | số bên ngoài ] ố ố mở rộng địa phương = [ 2001 | 2002 … | 2009 ] số bên ngoài = 9 + [ số địa phương | số đường dài ] số địa phương = tiền tố + <chuỗi 4 ký số> ố ề ố ố số đường dài = (1) + mã vùng + số địa phương tiền tố = [ 795 | 799 | 874 | 877 ]Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 83
  • 84. Review – Phân tích hệ thống theo cấu trúc ệ g• Phân tích yêu cầu theo pp cổ điển bao gồm: gồm: – Mô hình chức năng và dòng thông tin (DFD), – Mô hình dữ liệu (ERD) – và Mô hình hành vi (S ) à ô ì à i (STD)• Lược đồ DFD cơ bản có 4 ký hiệu và nó được mở rộng để biểu diễn được các hệ thống thời gian thực• Xây dựng DFD mức 0 rồi đến các mức cao hơn; chú ý hơn; bảo toàn tính liên tục của dòng dữ liệu• Từ điển dữ liệu giúp quản lý và tra cứu các phần tử dữ liệuTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 84
  • 85. Phâ tích hệ thống theo h ớ phát triểnPhân í h hố h hướng há iể kỹ thuật lập trình OOP Tiếp cận của phương pháp phát triển OOP cho bước phân tích hệ thống AI / Vị trí như thế nào / Làm Gì / Khi nào Các lược đồ –Lược đồ Use-case: thu thập yêu cầu – mô hình nghiệp vụ –Lược đồ lớp: phân tích hệ yêu cầu – mô hình phân tích
  • 86. Mô hình nghiệp vụ - Thu thập y cầu g ệp ụ ập yêu• Quan điểm thu thập/phân tích yêu cầu của mô hình nghiệp vụ: hệ thống gồm có AI/Làm những gì/Khi nào vụ:• Lược đồ Use-case : Use- – Actor & Use-case – Các mối quan hệ : Actor – Actor ; Actor-Use-case, - Use-case-Usace• Actor xác định một bộ vai trò mà người hoặc vật sẽ đóng vai khi tương tác với hệ thống phần mềm – Actor nằm ngoài phạm vi của hệ thống – Chỉ quan tâm các thông điệp mà actor gửi hay nhận – Không quan tâm cấu trúc bên trong của actor• Phân loại actor – Chủ yếu / Thứ yếu – Tí h cực / Th độ Tích Thụ độngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 86
  • 87. Nhận diện các ACTOR ậ ệ• Trả lời một số câu hỏi như – Ai là người sử dụng chức năng chính của hệ thống ? – Ai cần sự hỗ trợ từ hệ thống để thực hiện công việc thường nhật của họ ? – Ai phải thực hiện công việc bảo dưỡng, quản trị và giữ cho hệ thống hoạt động ? ệ g ạ ộ g – Hệ thống sẽ kiểm soát thiết bị phần cứng nào ? – Hệ thống đang xây dựng cần tương tác với những hệ thống khác hay không ? ố – Ai hoặc vật thể nào quan tâm đến hay chịu ảnh hưởng bởi kết quả mà hệ thống phần mềm tạo ra ?Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 87
  • 88. Biểu diễn ACTOR trong UML g• Actor được biểu diễn bằng ký hiệu hình người Tên Actor• A t Actor đ được xem là một lớ ( l ) có stereotype là ột lớp (class) ó t t <<actor>>• Giữa các actor có thể có quan hệ tổng quá hoá – Ví dụ: Sinh viên, giảng viên và khách đều là độc giả của hệ thống quản lý thư viện: độc giả là actor tổng quát hóa của 2 actor sinh viên và giảng viên• Ví dụ: một hệ thống đăng ký môn học trong dụ: trường đại học g ạ ọTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 88
  • 89. Các Actor trong hệ thống đăng ký môn học g ệ g g ý ọ S Sinh viên ê Phòng đào tạo Hệ thống đăng ký môn h ô họcGiảng viên Hệ thống quản lý học phí Phòng tài vụ Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 89
  • 90. Khái niệm Use-case ệ Use-• Use-case biểu diễn một chức năng của hệ thống phần Use- mềm• Use-case được biểu diễn bằng một chuỗi các thông điệp Use- trao đổi bên trong hệ thống và một hoặc một số thông điệp trao đổi với actor ệ ổ ớ• Một số quy ước – Use-case luôn luôn được bắt đầu bằng thông điệp đến từ actor – Use-case phải hoàn tất: chuỗi thông điệp phải kết thúc bằng bằ kết quả cụ thể ả thể.• Lỗi thường gặp: chia nhỏ use-case trở thành những chức gặp: use- năng vụn vặtTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 90
  • 91. Khái niệm Use-case ệ Use-• Use-case được biểu diễn bằng hình ellipse: Use- ellipse: Tên Use-case Use-• Điểm mở rộng là một vị trí trong use-case mà tại đó có use- thể chèn chuỗi sự kiện của một use-case khác use-• Use-case có thể chứa điều kiện rẽ nhánh, xử lý lỗi, ngoại Use- lệ... lệ...• Minh dụ của use-case là kịch bản (scenario): miêu tả cụ use- (scenario): thể trình tự các sự kiện xảy ra khi Use-case được thực Use- hiện. hiện.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 91
  • 92. Tìm kiếm Use-case Use-• Trả lời một số câu hỏi như – Actor yêu cầu chức năng gì của hệ thống ? – Actor cần phải đọc, tạo, xoá, sửa đổi hoặc lưu trữ thông tin nào đó của hệ thống không ? – Actor cần thiết phải được cảnh báo về những sự kiện trong hệ thống, hay actor cần phải báo hiệu cho hệ thống về vấn đề nào đó không ? – Hệ thống có thể hỗ trợ một số công việc thường nhật của actor nào đó hay không ?• Một số câu hỏi khác cần chú ý – Hệ thống cần dữ liệu input/ouput nào ? Dữ liệu đó đến từ đâu ? – Những khó khăn nào liên quan đến hiện thực của hệ thống hiện tại (chẳng hạn hệ thống q ản lý bằng giấ tờ nên được tha thế bằng hệ quản giấy thay thống quản lý trên máy tính) ?Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 92
  • 93. Các quan hệ của Use-case q ệ Use-• Sau khi xác định các Actor và Use-case thì các quan hệ sẽ Use- được thiết lập để hoàn chỉnh lược đồ Use-case ế ậ ể à ỉ ồ Use-• Giữa use-case và actor thường có quan hệ liên kết use- – Use-case được Actor nào kích hoạt• Giữa các use-case cũng có quan hệ liên kết hoặc tổng use- quát hoá – Quan hệ liên kết: extent , incluse – Quan hệ thổng quát hóa• Ví dụ: một hệ thống đăng ký môn học theo tín chỉ trong dụ: trường đại họcTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 93
  • 94. Ví dụ một Use-case đơn giản ụ ộ Use- g <<communicate>>Sinh Viên Phòng Đào Tạo Quản ý ô Q ả lý Môn Học Đăng Ký Học <<extend>> Đăng ký dạy Quản lý Sinh Viên Thêm Sinh Viên MớiGiảng ViêGiả Viên Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 94
  • 95. Q Quan hệ liên kết ệ• Quan hệ liên kết chỉ ra một quan hệ có ý nghĩa giữa hai bên – Trong thực tế: hành khách với lái xe sinh viên với giáo viên giảng viên với xe, viên, môn học …• Một số tính chất liên quan – Tên của liên kết ê ê ết – Một chiều hay 2 chiều – Bậc: số lượng thực thể tham gia vào liên kết tại mỗi bên• UML biểu diễn liên kết như là một đoạn thẳng (hai chiều) hoặc mũi ộ ạ g ( ) ặ tên (một chiều) <<Stereotype>> <<Stereotype>>• Có thể áp dụng stereotype: stereotype: – <<include>> – <<extend>> – <<communicate>> – ...Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 95
  • 96. Q Quan hệ liên kết g ệ giữa Actor và Use-case Use- • Liên kết là quan hệ duy hất giữa actor & Use-case Use- • Liên kế có thể là 2 chiều hay 1 chiều – actor kích hoạt use-case và nhận kết quả về: liên kết 2 chiều – actor kích hoạt use-case không quan tâm kết quả về: liên kết 1 chiều use-case, • Quan hệ liên kết phổ biến giữa Actor & Use-case là giao Use- tiếp: tiếp: stereotype là <<communicate>> dùng liên kết giữa actor và use case mà nó kích hoạt à ó í 1 <<communicate>> * Đăng ký dạy Đặt hàngNgười bán hàng Giảng viên Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 96
  • 97. Q Quan hệ gộp g ệ giữa 2 Use-case Use-• Dùng để liên kết 2 Use-case: có stereotype là <<include>> Use-case:• Trong Use-case nguồn có điểm mở rộng mà tại đó bắt Use- buộc phải chèn Use-case đích vào. Use- vào. – Tại điểm mở rộng diễn tiến của use-case nguồn tạm thời ngừng lại rộng, để chuyển sang diễn tiến của use-case đích – Khi kết thúc use-case đích, diễn tiến của use-case nguồn lại tiếp tục <<include>>Tìm kiếm Đăng nhậpTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 97
  • 98. Q Quan hệ mở rộng g ệ ộ g giữa 2 Use-case Use-• Dùng để liên kết 2 Use-case: có stereotype là <<extend>> Use-case:• Trong use-case nguồn có một điểm mở rộng mà tại đó có use- thể (hoặc không) chèn use-case đích vào tùy thuộc vào use- điều kiện rẽ nhánh hoặc tương tác từ actor – Tại điểm mở rộng, nếu được mở rộng thì diễn tiến của use-case nguồn tạm thời ngừng lại để chuyển sang diễn tiến của use-case đích – Khi kết thú use-case đí h diễ tiế của use-case nguồn l i tiế t thúc đích, diễn tiến ủ ồ lại tiếp tục <<Extend>>Tìm kiếm Đăng ký đặt chỗ (nếu tìm thấy)Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 98
  • 99. Q Quan hệ tổng q ệ g quát hóa• Là mối quan hệ giữa các đối tượng cùng nhóm tạo nên một đối tượng mang những tính chất ch ng của các đối chung tượng kia• Quan hệ thống quát hóa giữa các Actor: nhiều actor có Actor: chung một số vai trò -> hình than2h actor tổng quát hóa ộ ố ò ì than2 ổ á ó mang vai trò chung đó. đó. – Ví dụ: sinh viên, giáo viên đều có chung use-case login và đều là user của hệ thống -> tạo nên actor user là tổng quát hóa của actor sinh ố ổ viên và actor giáo viên• Quan hệ thổng quát hóa giũa các Use-case: khi có nhiều Use-case: use- use-case là trường hợp cụ thể một use-case trừu tượng à ờ ể ộ use- ừ – Vì dụ: Use-case login của sinh viên , giáo viên có thể được thực hiện theo cơ chế khác nhau nhưng cùng mang chung ý nghĩa là đăng nhập là các t ờ h cụ thể của U á trường hợp ủ Use-case t ừ t trừu trương LOGINTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 99
  • 100. Xây dựng mô hình Use-case y ự g Use-• Các yêu cầu của phần mềm được mô tả trong mô hình use-case use-• Mô hình use-case bao gồm lược đồ use-case và (có thể) một số use- use- packet (gom một số use-case thành một bộ chức năng con của hệ thống) use-• Phương pháp thực hiện: hiện: – Xác định các actor và use-case của hệ thống – Xác lập các quan hệ giữa các đối tượng này • Quan hệ liên kết giữa actor và use-case: một chiều hoặc hai chiều, thường có stereotype là <<communicate>> • Quan hệ mở rộng hay gộp giữa 2 use-case: quan hệ liên kết với stereotype ế <<extend>> hay <<include>> • Quan hệ tổng quát hoá (generalization) giữa các actor: nhiều actor có vai trò của một actor trừu tượng • Quan h tổng quát h giữa các use-case: nhiều use-case l trường h cụ thể của một hệ ổ hoá i hiề là hợp hể use-case trừu tượng – Trình bày thành lược đồ use-case theo chuẩn UML – Có thể xác định các packet ị pTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 100
  • 101. Xây dựng mô hình Use-case – VÍ DỤ y ự g Use- Ụ fee summary Prints timetable Makes timetable Student print request <<communicate>> Finance <<communicate>> timetable command Registers courses People Removes students <<include>> Administration Manages course <<extend>> t d <<include>> Lecturer Reads courses <<include>> Manages lecturers g <<include>> Adds students <<extend>> <<include>> <<include>> Login Manages studentsUndertakes courseTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 101
  • 102. Xây dựng mô hình Use-case – VÍ DỤ y ự g Use- Ụ <<communicate>> Forwards Removes mailbox Subcriber <<communicate>> <<extend>> <<extend>> Views mail <<include>> Administrator Replies<<communicate>> <<extend>> <<include>> <<include>> Adds mailbox Login Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 102
  • 103. Xây dựng mô hình Use-case – VÍ DỤ y ự g Use- Ụ <<extend>> models imports <<communicate>> initializes <<communicate>> model command import command run command i t <<communicate>> export command sets appearance exports <<communicate>> save command d Viewer toggles light saves model <<communicate>> <<extend>> close command toggles mode exits sets eyeTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 103
  • 104. Mô hình phân tích – Phân tích yêu cầu p y • Mô hình nghiệp vụ biểu diễn các chức năng phần mềm cần xây dựng dưới dạng các use- use- Đối tượng/lớp case - quan hệ • Mô hình phân tích sẽ tìm kiếm các đối tượng “sống” trong ngữ cảnh của phần mềm sống • Các đối tượng sẽ tương tác với nhau để tạo nên các chức năng mô tả bởi use-case use- • Lượ đồ Cl Lược Class phân tích diễ tả cấu t ú mối hâ tí h diễn ấ trúc, ối quan hệ giữa các đồi tượng/lớp trong hệ thống • Chưa quan tâm đến hành vi cụ thể và nhiệm vụ chi tiết của chúng t hi ủ hú trong ngữ cảnh của hệ ữ ả h ủ thống • Nguyên tắc: mô hình phân tích phải độc lập tắc: với o/s, ngôn ngữ lậ t ì h công cụ phát t iể ới / ô ữ lập trình, ô hát triểnTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 104
  • 105. Xây dựng mô hình phân tích y ự g p• Mô hình phân tích được diễn đạt trong UML bằng lược đồ lớp phân tích (Class diagrame)• Các công việc xây dựng lược đồ phân tích bao gồm – Tìm kiếm các đối tượng / lớp trong hệ thống • Đối tượng / lớp thực thể • Đối tượng / lớp biên • Đối tượng / lớp control – Xác định các thuộc tính của đối tượng / lớp ị ộ ợ g p – Xác định các tác vụ của đối tượng / lớp – Nhận diện các lớp trừu tượng qua mối quan hệ thổng quát hóa – Xác lập các mối quan hệ giữa các lớp: • Tổng quát hoá (generalization) ổ • Liên kết (association) • Bao gộp (aggregation)• Biể diễn thành lượ đồ lớp phân tí h Biểu lược tíchTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 105
  • 106. Nhập diện đối tượng / lớp ập ệ ợ g p• Dựa vào đặc tả của từng use-case để tìm kiếm các đối use- tượng• Các đối tượng thường xuất hiện trong các danh từ hay nhóm danh từ• Một số lưu ý – Không nên dùng đối tượng để biểu diễn một dữ liệu đơn (nên xem là thuộc tính của đối tượng khác) ố – Đối tượng/lớp phải thực sự cần thiết cho sự hoạt động của hệ thống – Đối tượng/lớp >< bảng cơ sở dữ liệu ợ g p g ệ – Đối tượng/lớp >< actorTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 106
  • 107. Nhận diện và biểu diễn đối tượng / lớp ậ ệ ợ g p• Phân loại đối tượng/lớp – Đối tượng thực thể (entity): biểu diễn các thông tin thiết yếu của hệ ố ể ể ễ ô ế ế ệ thống, có thể được lưu trong cơ sở dữ liệu – Đối tượng biên (boundary): thực hiện chức năng giao tiếp với actor – Đối t tượng điề khiể ( điều khiển (control): điề khiể các đối t t l) điều khiển á tượng khá khác• Trong UML, lớp được biểu diễn bằng một hình chữ nhật gồm 3 phần: tên, các thuộc tính và các tác vụ phần:• Có thể áp dụng stereotype cho lớp: <<entity>>, lớp: <<boundary>>, <<control>>... <<control>>...• Đối tượng cũng được biểu diễn bằng hình chữ nhật nhật, thông thường gồm 2 phần: tên đối tượng + tên lớp (được phần: gạch chân), giá trị các thuộc tính (trạng thái của đối tượng)Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 107
  • 108. Biểu diễn lớp / đối tượng p ợ g HTMLObject j # alignment: int + GetAlignment( ): int + toHTML( ): String HTMLDocument doc : HTMLDocument alignment = MIDDLE - title: String title = “A document” + GetTitle( ): String + toHTML( ): StringTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 108
  • 109. Đối tượng / lớp thực thể ợ g p ự• Biểu diễn cho các thực thể xuất hiện một cách tự nhiên trong hệ thống• Thông tin về các đối tượng thực thể có thể phải được lưu trữ lâu dài (database, file...) file...)• T Trong UML đ UML, được gán stereotype <<entity>> á i• Dễ nhận diện các thuộc tính của chúngVí dụ: dụ: ụ Message g • Đối với hệ thống đăng ký môn học hệ tín <<entity>> chỉ qua WEB, nhận diện các đối tượng thực # subject: String thể như: thông tin SV, thông tin GV, nhóm # sent: Date lớp học đăng ký nhóm sổ tay sinh viên … học, nhóm, # content: String • Đối với hệ thống mail, nhận diện các đối tượng thực thể như: hộp thư, thông điệp + GetSubject( ): String mail… + toString( ) String g( ): gTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 109
  • 110. Đối tượng / lớp biên ợ g p• Thực hiện chức năng giao tiếp với actor• Thườ Thường chứa các phần tử h ặ điề khiể giao diệ người hứ á hầ hoặc điều khiển i diện ười dùng (nút nhấn, hộp danh sách, tuỳ chọn, menu...) menu...)• Trong UML, được gán stereotype <<boundary>>• Khó nhận biết các thuộc tính và tác vụ trong mô hình phân tíchVí dụ: dụ: ụ MailView <<boundary>> •Đối với hệ thống đăng ký môn học hệ tín chỉ qua WEB, nhận diện các đối tượng biên như: RegisterForm, RegisterForm StudentForm… • Đối với hệ thống mail, nhận diện các g đối tượng biên như: MailView, MailCompose...Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 110
  • 111. Đối tượng / lớp điều khiển ợ g p• Có nhiệm vụ điều khiển các lớp khác hoặc Command <<control>>• Những lớp không phải là lớp thực thể và lớp biên + Execute( ) + Reexecute( )• Trong UML, được gán stereotype + Unexecute( ) # Do( ) <<control>>• Lớp biên thường có quan hệ liên PasteCommand BgCommand kết hoặc phụ thuộc với các lớp <<control>> <<control>> khác + Execute( ) ( + Execute( ) (• Ví dụ: dụ: + Reexecute( ) + Reexecute( )• Đối tượng biểu diễn một số lệnh + Unexecute( ) + Unexecute( ) # Do( ) # Do( ) thông thường như cắt, dán, thay đổi thông số nhìn trong hiển thị đồ hoạ …Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 111
  • 112. Nhận điện các thuộc tính ậ ệ ộ• Dựa vào đặc tả của từng use-case, tìm kiếm các danh từ hoặc use- nhóm d h từ liê quan đế đối tượ đ hó danh liên đến tượng đang xét ét• Trả lời câu hỏi: những thành phần nào cấu thành đối tượng hỏi: đang xét ? g – Lưu ý: cùng một đối tượng trong các ngữ cảnh khác nhau chúng ta có thể tìm được các thuộc tính khác nhau• Nên xác định (tuy nhiên không bắt buộc) trong mô hình phân tích – Kiểu của thuộc tính: một số kiểu cơ bản – Bậc của thuộc tính: số ít hoặc số nhiều – Visibility của thuộc tính: mức độ cho phép truy xuất thuộc tính từ bên ngoài• UML: UML: thuộc tính được miêu tả tường minh hoặc thông qua quan hệ với các lớp khácTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 112
  • 113. Xác định mức độ truy cập của thuộc tính ị ộ y ập ộ• Mức độ truy cập và phạm vi mà thuộc tính đó có thể được tham khảo đến trực tiếp ả ế ế• UML định nghĩa 3 mức độ truy xuất thuộc tính (visibility) – public (+): có thể truy xuất thuộc tính từ tất cả các vị trí khác nhau – protected (#): bản thân lớp đang xét và các lớp con của nó có thể truy xuất thuộc tính ể ấ ộ – private (-): chỉ có lớp đang xét có thể truy xuất thuộc tính• Thông thường nên đặt mức độ truy xuất thuộc tính là private hoặc protected (cho các lớp cơ sở), không nên là public. public.• Thuộc tính nên được truy xuất thông qua tác vụ get/setTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 113
  • 114. Ví dụ về nhận diện các thuộc tính ụ ậ ệ ộ• Hệ thống đăng ký môn học hệ tín chỉ qua WEB - LecturerInfo StudentInfo Nhận diện các thuộc tính <<entity>> <<entity>> cho các đối tượng: tượng: - name: String StudentInfo, StudentInfo LecturerInfo - name: String - code: Long - code: String• Chú ý các mức độ truy - dateOfBirth: String - dateOfBirth: Date cập của các thuộc tính - addr: String - addr: String• Các tác vụ phát sinh - acaYear: D Y Date - degree - title: String trong khi nhận diện các - department - division thuộc tính như Get/Set - home: String - health - socialAid - experience: Date + GetN ame( ): String + GetN ame( ): String + GetCode( ): Long + GetCode( ): StringTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 114
  • 115. Ví dụ về nhận diện các thuộc tính ụ ậ ệ ộ • Hệ thống đăng ký môn học hệ tín chỉ qua WEB CourseOfferring Catalog <<entity>> <<entity>> • Nhận diện các thuộc tính cho các đối - courseN ame: String - acaYear: Date tượng: tượng: - courseCode: String - semester - offering: int CourseOffering, - session i - credit: int Catalog - prerequisiteTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 115
  • 116. Nhận diện các tác vụ ậ ệ ụ• Dựa vào đặc tả của từng use-case, tìm kiếm các động từ use- hoặc nhóm động từ liên quan đến đối tượng đang xét ặ ó ộ ừ ê ế ố é• Chú ý xem đối tượng được tạo ra và bị huỷ bỏ đi như thế nào ? Trong thời gian đó nó gửi/nhận thông điệp ra sao ?• Các đối tượng biên có các tác vụ nhận lệnh từ actor. actor.• Xem xét mức độ truy xuất của tác vụ tương tự như đối với ộ y ụ g ự các thuộc tính; các tác vụ thường có visibility là + hoặc # tính;• Một số tác vụ không xuất hiện một cách tự nhiên trong mô hình phân tích mô hình thiết kế sẽ nghiên cứu kỹ trách nhiệm và hành vi của từng đối tượngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 116
  • 117. Nhận diện lớp cơ sở ậ ệ p• Lớp cơ sở (base class) được nhận diện sau khi đã nhận diện các lớp cụ thể ệ á ớ ể• Sự xuất hiện của lớp cơ sở làm cho mô hình phân tích có tính dùng lại cao (reusability) và dễ mở rộng (scalability)• UML hỗ trợ quan hệ tổng quát hoá (generalization)• Lớp cơ sở trừu tượng (không thể cụ thể hoá tạo ra đối p ợ g ( g ụ ạ tượng) có tên in nghiêng• Lớp cơ sở được hình thành bằng cách xác lập các quan hệ tổng quát hóa của các lớp cụ thể có chung một số thuộc tính và/hay một số tác vụTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 117
  • 118. Nhận diện lớp cơ sở (tt) ậ ệ p ( )• Đối với các đối tượng/lớp thực thể, tìm các thuộc tính chung để hình thành lớp cơ sở ể ì à ớ ở• Ví dụ – Trong hệ thống quản lý thư viện qua WEB: các đối tượng Book Book, Magazine có một số thuộc tính chung hình thành lớp LibraryItem – Đối với hệ thống đăng ký môn học tín chỉ qua WEB: lớp PeopleInfo là lớp cơ sở của StudentInfo và LecturerInfo – Chương trình vẽ bề mặt địa hình: lớp MapCurve là lớp cơ sở của đường đồng mức Isoquant và đứt gãy Fracture• Giữ lớ cơ sở và các lớ cụ thể có mối quan hệ thổ Giữa lớp ơ ở à á lớp ó ối thổng quát hóa có thể biểu diễn được trong UMLTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 118
  • 119. Biểu diễn lớp cơ sở và quan hệ tổng quát hóa p q ệ gq • UML định nghĩa quan hệ tổng quát hoá giữa một lớp tổng quá hơn với một lớp ữ ộ ớ ổ á ớ ộ ớ MapCurve cụ thể hơn: lớp cụ thể hơn có tất cả hơn: thuộc tính, tác vụ và quan hệ của lớp ộ , ụ q ệ p kia + những thuộc tính/tác vụ riêng Isoquant của nó • Ký hiệ : mũi tê có đầ là một t hiệu: ũi tên ó đầu hiệu ột tam giác nhỏ Fracture • Lớp tổng quát hơn nằm về phía mũi tênTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 119
  • 120. Ví dụ về nhận diện lớp cơ sở ụ ậ ệ pVí dụ: dụ:• T ong hệ thống Trong # name: String # code: String đăng ký môn học # dateOfBirth: Date tín chỉ qua WEB, # addr: String lớp PeopleInfo là tổng quát hoá của StudentInfo StudentInfo LecturerInfo và LecturerInfo <<entity>> <<entity>> - acaYear: Date - degree - department - title: String - home: String - division - socialAid - health - experience: DateTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 120
  • 121. Nhận diện các mối q ậ ệ quan hệ ệ• Sau khi xác định các lớp/đối tương kể cả các đối tượng cơ sở, các quan hệ giữa các lớp cần được xác lập ở á ệ ữ á ớ ầ á ậ• Trong mô hình phân tích các đối tượng/lớp có quan hệ với nhau• Một số quan hệ mà UML hỗ trợ – Tổng quát hoá (generalization) – Liên kết (association) – Bao gộp (aggregation)• Các quan hệ khác được áp dụng cho mô hình thiết kế – Phụ thuộc (dependency) – Cụ thể hoá (realization)Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 121
  • 122. Q Quan hệ liên kết ệ• Quan hệ liên kết là mối quan hệ giữa 2 đối tượng/lớp• Về ý nghĩa và ký hiệu giống như quan hệ liên kết trong mô hình nghiệp vụ• Áp dụng cho 2 lớp có mối tương quan mang ý nghĩa nhất định• Chú ý ghi rõ (nếu có thể được) g ( ợ ) – Bậc và tên vai trò của mỗi lớp trong quan hệ – Tên của chính quan hệ liên kết• Dựa vào mô hình nhgiệp vụ xác định các mối quan hệ liên kếtTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 122
  • 123. Ví dụ - mối quan hệ liên kết ụ q ệ Registration Ví dụ: dụ: StudentInfo St d tI f students d has h <<entity>> <<entity>> Lớp Registration 40..80 - acaYear: Date liên kết với lớp - semester StudentInfo LecturerInfo 0..1 reg và lecturer CourseOffering LecturerInfo offering 0..1 <<entity>> CourseOffering <<entity>>Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 123
  • 124. Q Quan hệ bao gộp ệ• UML định nghĩa quan hệ bao gộp là trường hợp đặc biệt của quan hệ liên kết, khi mà một đầu nối liên kết trở ủ ệ ê ế à ộ ầ ố ê ế ở thành đầu nối bao gộp (aggregation)• Lớp ở đầu nối bao gộp sẽ bao hàm lớp kia• Ký hiệu của đầu nối bao gộp là một hình thoi tô hoặc không tô đen• Có hai dạng bao gộp – Chia xẻ (shared): chia xẻ giữa các bao gộp khác nhau – Hoàn toàn (composite): sở hữu đầy đủ• Xác lập các mối quan hệ bao gộm và biểu diễn chúng lên lược đồ lớpTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 124
  • 125. Q Quan hệ bao gộp – ví dụ ệ ụ• Đối với hệ thống đăng ký môn học tín chỉ qua WEB, lớp Catalog bao gộp lớp CourseOffering Co seOffe ing CourseOffering Catalog <<entity>> <<entity>> << tit >> * - acaYear: Date - semester• Cửa sổ giao diện bao gộp hoàn toàn thanh cuộn và menu Menu Window ScrollBar 1 *Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 125
  • 126. Xây dựng lược đồ lớp y ự g ợ p• Lược đồ lớp (class diagram) biểu diễn cấu trúc của một số lớp và quan hệ giữa chúng mô tả khía cạnh tĩnh (static) của hệ thống• Hệ thống phức tạp có nhiều lớp cần xây dựng nhiều lược đồ lớp, mỗi lược đồ mô tả một phần của hệ thống ồ ớ ỗ ồ ô ả ộ ầ ủ ệ ố• Lược đồ lớp được bổ sung và hoàn thiện trong mô hình thiết kế (thêm một số lớp, chi tiết các thuộc tính và tác vụ, làm rõ các quan hệ)• Lược đồ lớp được xây dựng qua các bước – Xác định các lớp – Xác định thuộc tính và tác vụ của các lớp – Xác định các lớp cơ sở và quan hệ tổng quát hoá – Xác định các quan hệ liên kết và bao gộpTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 126
  • 127. Ví dụ một lược đồ lớp p ụ ộ ợ p phân tích• một lược đồ lớp của chương trình hiển thị bề mặt địa hình Isoquant isoquants FieldMap entity <<entity>> <<entity>> * - name: String - altitude: double + wrap( ): Region * fractures p points Point2D P i 2D MapCurve Fracture F * <<entity>> - x: double - ID: int - y: double - open: booleanTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 127
  • 128. Thiết lập PACKAGE ập• Package là một cơ chế để tổ chức các phần tử vào các nhóm có liên hệ về ngữ nghĩa với nhau ệ g g• Package có thể import các phần tử từ một package khác• Có thể chỉ ra quan hệ giữa các package – Phụ thuộc – Tổng quát hoá• Mức độ truy xuất của package – Private: chỉ nó và các package import nó có thể truy xuất nội dung – Protected: giống như private nhưng cho phép thêm các package dẫn xuất – Public: các package khác có thể truy xuất nội dung – Implementation: không cho phép import, có thể áp dụng cho các phần tử p g p p p p ụ g p bên trong package• UML cho phép biểu diễn các PACKAGE và các mối quan hệ PACKAGETrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 128
  • 129. Ví dụ về một PACKAGE ụ ộ • package UniPeople chứa các lớp liên quan đến thông tin con người UniPeople PeopleInfo # name: String S i LecturerInfo # code: String - degree # dateOfBirth: Date - title: String # addr: String add : St g - di i i division - health StudentInfo - experience: Date - acaYear: D Y Date - department - home: String - socialAidTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 129
  • 130. Tổng kết g • Phân tích hệ thống cho OOP theo UML chia làm 2 bước: à bước: ớ – Thu thập yêu cầu bằng mô hình nhgiệp vụ – Phân tích và xác định tính năng hệ thống bằng mô ị g ệ g g hình phân tích • Mô hình phân tích nhận diện các đối tượng/lớp: tượng/lớp: thực thể biên điều khiển thể, biên, • Nhận diện các thuộc tính và một số tác vụ, tuy nhiên chưa làm rõ hành vi của chúng y g ( mô hình thiết kế) • UML hỗ trợ một số phần tử: lớp, đối tượng, tử: lược đồ lớp package lớp,Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 130
  • 131. Thiết kế phần mềm (Software Design)CƠ SỞ CỦA THIẾT KẾ PHẦN MỀMGIAO DIỆN & TƯƠNG TÁC NGƯỜI DÙNG Á Ờ ÙPHƯƠNG PHÁP THIẾT KẾ CỔ ĐIỂNPHƯƠNG PHÁP THIẾT KẾ OOP
  • 132. Thiết kế phần mềm Thiết kế phần mềm là công việc đầu tiên của giai đoạn phát triển Thiết kế tạo ra các biểu diễn và dữ kiện của hệ thống phần mềm cần xây dựng từ kết quả phân tích yêu cầu để có thể dễ dàng hiện thực sau đó Thiết kế tạo ra phương thức và quy trình tương tác giữa người dùng với hệ thống phần á ờ ù ớ ệ ố ầ mềm cũng như tương tác giữa các hệ thống khác với phần mềm mềm.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 132
  • 133. Trừu tượng hóaQuá trình thiết kế trải qua nhiều mức trừu tượng hoá khác nhau Mức cao nhất: vấn đề cần thiết kế được mô tả một cách tổ quát sử d á h tổng át ử dụng th ật ngữ h ớ vấn đề thuật ữ hướng ấ Các mức thấp hơn: hướng đến thủ tục xử lý chi tiết; kết hợp các thuật ngữ hướng đến hiện thực Mức thấp nhất: vấn đề được mô tả theo cách có thể hiện thực trực tiếp Phân loại trừu tượng hoá: thủ tục và dữ liệuTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 133
  • 134. Trừu tượng hóa Trừu tượng hoá thủ tục: là chuỗi các lệnh liên tiếp thực hiện chức năng nào đó.Ví dụ: mở cửa (bao gồm đi đến cửa, cầm lấy tay nắm, xoay tay nắm, ké cánh cửa, đi vào…); thê một phần tử vào d h sách ắ kéo á h ử à ) thêm ột hầ à danh á h có thứ tự (xác định vị trí, chèn phần tử mới) Trừu tượng hoá dữ liệu: là tổ hợp dữ liệu mô tả một đối tượng dữ liệu (liên hệ tới đối tượng thực thể trong UML). Ví dụ: hàng, chồng, cánh cửa... Một số ngôn ngữ lập trình hỗ trợ kiểu ADT và templateTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 134
  • 135. Tinh chế Tinh chế là quá trình làm rõ vấn đề Tinh chế và trừu tượng hoá là hai khái niệm bù trừ nhau: càng tinh chế thì càng hạ thấp mức trừu tượng hoá Thiết kế phần mềm: trừu tượng hóa rồi tinh chế hoá hoá. Tại sao?Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 135
  • 136. Thiết kế giao diện người dùng Phần mềm cần có giao diện thân thiện với người sử dụng Một số tiêu chuẩn giao diện Thời gian đáp ứng của hệ thống: giá trị trung bình và độ lệch Phương tiện trợ giúp người sử dụng: tích hợp + add on add-on Kiểm soát thông tin lỗi: hiện thị cả nguyên nhân lỗi và cách khắc phục Đặt tên nhãn: ngắn gọn và gợi nhớ Thường dùng các công cụ thiết kế giao diệnTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 136
  • 137. Công cụ thiết kế giao diệnCông cụ thiết kế giao diện nên có những tính năng sau g ụ g ệ g g Quản lý thiết bị nhập (bàn phím, chuột) Hiệu chỉnh thông tin input Kiểm soát lỗi và hiển thị thông báo lỗi Cung cấp trợ giúp và hiển thị thông báo nhắc nhở Cung cấp feedback (ví dụ như tự động hiển thị ký tự đánh vào) Kiểm soát cửa sổ và vùng, khả năng cuộn ể á ử ổ à ù ả ộ Thiết lập giao tiếp giữa chương trình với giao diện (vd: hàm đáp ứng) Cách ly chương trình với các hàm quản lý giao diện Cho phép tuỳ biến giao diện: màu sắc, kích thước,..Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 137
  • 138. Một số định hướng về thiết kế giao diệnMột số hướng dẫn chung ộ g g Nên đồng nhất (menu, lệnh, hiển thị...) Nên cung cấp feedback cho người dùng Yêu cầu xác nhận những tác vụ mang tính phá hoại (xoá file file, account) Nên hỗ trợ UNDO, REDO Hạn hế lượng thông tin hải hi hớ iữ H chế lượ thô ti phải ghi nhớ giữa 2 tá vụ liê tiế tác liên tiếp Tối ưu trong trình bày hộp thoại và di chuyển mouse Chấp nhận lỗi từ phía người sử dụng Cung cấp trợ giúp trực tuyến Dùng động từ đơn giản và ngắn gọn để đặt tên các lệnhTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 138
  • 139. Một số định hướng về thiết kế giao diệnĐối với thông tin hiển thị Chỉ hiển thị những thông tin phù hợp với ngữ cảnh hiện tại Dùng tên, từ viết tắt và màu gợi nhớ Cho phép tương tác trực quan Tạo thông báo T thô bá lỗi có ý nghĩa ó hĩ Hiển thị dữ liệu ở nhiều dạng khác nhau trong cửa sổ Thiết lập biểu diễn tương tự Sử dụng không gian màn hình một cách tối ưuTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 139
  • 140. Một số định hướng về thiết kế giao diệnĐối với thông tin input g p Hạn chế input trực tiếp (có thể chọn lựa từ một số dữ liệu có sẵn) Nên đồng nhất giữa thông tin input và hiển thị Nên cho phép tuỳ biến input Cấm các chức năng không thích hợp trong ngữ cảnh g g ợp g g hiện tại Cho phép input ở nhiều dạng khác nhau Để cho người sử dụng kiểm soát dòng sự kiện tương tác Tự động tính các giá trị input cho người sử dụng nếu có thể óTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 140
  • 141. Thiết kế phần mềmPhương pháp lập trình cấu trúcModule hoá chương trìnhPhân hiPhâ chia moduled lKiến trúc phần mềmThiết kế dữ liệu
  • 142. Thiết kế phần mềm cổ điển Các công đoạn trong thiết kế phần mềm cổ điển Phân chia module Thiết kế dữ liệu Thiết kế kiến trúc Thiết kế thủ tục Thiết kế giao diện Phần mềm phát triển theo mô hì h cổ đ ễ hầ ề há ể h ô hình ổ điễn: quan tâm đến cấu trúc và giải thuật của các moduleTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 142
  • 143. PHÂN CHIA MODULE Module là gì? g Khái niệm module đã xuất hiện khoảng 4 thập niên trở lại đây. Phần mềm được xây dựng bằng cách phân chia thành nhiề â nhiều module, sau đó sẽ được tích hợp lại Phân chia module làm cho việc quản lý phần mềm khoa học hơn Giả sử C(x): độ phức tạp của x, E(x): công sức để thực hiện x. Rõ ràng: nếu C(p1) > C(p2) thì E(p1) > E(p2). Nếu phân chia p = p1 + p2 ta thấy (một cách trực quan): C(p1 + p2) > C(p1) + C(p2) E(p1 + p2) > E(p1) + E(p2)Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 143
  • 144. Phân chia module như thế nào? Số lượng ợ g module phụ thuộc vào độ Tổng công sức phát triển phức tạp của hệ thốngCông sứ bỏ ra phần mềm Vùng tối ưu cần xây ức dựng dự Quá ít hoặc quá nhiều mod le đề module đều Công sức tích hợp không tốt Tổng công sức từng module Số lượng module Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 144
  • 145. Kiến trúc phần mềm Kiến trúc phần mềm mô tả các thành phần (component) kiến tạo nên hệ thống phần mềm và sự giao tiếp giữa các thành phần đó Thành phần có thể là Các module mã nguồn Các file thực thi (*.dll, *.exe, *.class...) Các thành phần của kiến trúc hệ thống: ActiveX control, t à p ầ ế t úc ệ t ố g: ct ve co t o , bean... Các trang HTML, *.asp, *.jsp...Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 145
  • 146. Kiến trúc phần mềm- Sơ đồ phân cấp mềm M Sơ đồ Fan-out phân cấp b được a cDepth dùng để miêu tả d e k l m sự phân rã các f g h n o p q module. Fan-in i j r WidthTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 146
  • 147. Phân chia module hiệu quả Phân chia module là bắt buộc trong giai đoạn thiết kế Tuy nhiên: phân chia kiến trúc phần mềm thành một bộ các module như thế nào là tốt nhất ? Đạt được vùng tối ưu về tổng chi phí quản lý và phát triển từng module Tiêu hí Tiê chí quan t trọng nhất: tí h độ lậ chức năng của hất tính độc lập hứ ă ủ các module Tính độc lập chức năng được đo bằng 2 tiêu chuẩn: Độ kết dính (cohesion) Sự liên kết (coupling)Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 147
  • 148. Độ kết dính Độ kết dính dùng để đo sự phụ thuộc lẫn nhau giữa những tác vụ (task) của một module Module có độ kết dính cao nhất khi nó chỉ đảm hậ đúng một tá vụ đả nhận đú ột tác kết dí h chức dính hứ năng Thiết kế kiến trúc phần mềm: cố gắng tăng độ kết dínhTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 148
  • 149. Các mức độ kết dínhCó nhiều mức độ kết dính (từ thấp đến cao) Ngẫu nhiên: các tác vụ không liên hệ với nhau Luận lý: các tác vụ liên quan logic với nhau Nhất thời: các tác vụ phải được thực thi trong một khoảng thời gian Giao tiế các tá vụ có sử d Gi tiếp: á tác ó ử dụng chung một dữ liệ h ột liệu nào đó Thủ tục: các tác vụ phải được thực hiện theo một trật tự nhất định Chức năng: chỉ có một tác vụTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 149
  • 150. Sự liên kết Sự liên kết dùng để đo đạc quá trình giao tiếp giữa các module: giao tiếp của module chứa nhiều tác vụ và nhiều thô số gọi thì sự liê kết càng cao hiề thông ố i liên à Thiết kế kiến trúc phần mềm: cố gắng giảm sự liên kếtTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 150
  • 151. Các mức độ liên kếtCó nhiều mức độ liên kết (từ cao đến thấp) Liên kết nội dung: sử dụng dữ liệu và điều khiển của module khác Liên kết chung: có sử dụng chung dữ liệu toàn cục Liên kết ngoại vi: module phụ thuộc vào một I/O nào đó Liên kết điều khiển: thông số truyền ảnh hưởng đến điều khiển Liên kết stamp: truyền cấu trúc dữ liệu phức tạp Liên kết dữ liệu: truyền các thông số đơn giảnTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 151
  • 152. Nguyên lý che dấu thông tin Che dấu thông tin là một trong những nguyên lý quan trọng của việc phân chia module Các module giao tiếp với nhau bằng những thông tin thật sự cần thiết Những thông tin về thủ tục và dữ liệu cục bộ của mỗi module phải được che dấu khỏi các module khác Lợi ích: kiểm soát được thay đổi và sửa lỗi dễ dàngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 152
  • 153. Các Heuristic trong phân chia module Sửa lại thiết kế ban đầu để tăng độ kết dính và giảm sự liên kết Khi chiều sâu tăng, hạn chế fan-out trong khi sử dụng fan-in f i Giữ cho tầm ảnh hưởng của một module nằm bên trong tầm điều khiển của nó Loại bỏ dư thừa trong giao tiếp của các module Ưu tiên các module tất định, hạn chế các module nhiều ràng buộc Đóng gói các module để đạt được tính khả chuyển (portability)Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 153
  • 154. Thiết kế dữ liệu Tìm kiếm biểu diễn luận lý cho các phần tử dữ liệu đã được nhận diện trong giai đoạn phân tích yêu cầu Thiết kế các cấu trúc dữ liệu của chương trình và cơ sở dữ liệ liệu Thực hiện tinh chế từng bước Các tiêu chí thiết kế hệ cơ sở dữ liệu Không dư thừa dữ liệu Tối ưu hóa không gian lưu trữ ố óa ô g g a ưu t ữ Chuẩn hóa cơ sở dữ liệu bằng lược đồ ERD và dạng chuẩn 3Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 154
  • 155. Cấu trúc dữ liệuCấu trúc dữ liệu là thiết kế cơ sở dữ liệu động tron hệ thống Cấu trúc dữ liệu mô tả sự tổ chức, phương thức truy xuất, mức độ liê kết và các xử lý khá của thô ti ất ứ liên à á ử khác ủ thông tin Dữ liệu đơn là dạng cấu trúc dữ liệu đơn giản nhất chỉ bao gồm một phần tử thông tin mà có thể được truy xuất bằng một danh định Một số dạng phức tạp hơn: vector, ma trận, mảng nhiều chiều, d h sách l ê kế hà h ề h ề danh á h liên kết, hàng, chồng, cây nhị hồ â h phân… Được biểu diễn ở các mức trừu tượng hoá khác nhauTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 155
  • 156. Mộ số nguyên tắc thiết kế dữ liệu Một số nguyên tắc Nhận diện cả cấu trúc dữ liệu và tác vụ truy xuất Chú ý sử dụng từ điển dữ liệu Trì hoãn thiết kế dữ liệu mức thấp cho đến cuối giai đoạn này Che dấu biểu diễn bên trong của cấu t ú dữ liệ Ch dấ biể diễ bê t ủ ấ trúc liệu Phát triển một thư viện các cấu trúc dữ liệu + tác vụ thường gặp Nên áp dung kiểu ADT trong thiết kế cũng như trong lập trìnhTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 156
  • 157. Thiết kế kiến trúc Mục tiêu là xây dựng sơ đồ phân cấp module từ DFD Đặt nền móng để thiết kế chi tiết thủ t và dữ liệ ề ó hi tục à liệu Phân biệt dòng transform và dòng transaction trong DFD Thực hiện ánh Thự hiệ á h xạ cho từ vùng của DFD t ỳ th nó h từng ù ủ tuỳ theo ó là dòng transform hay transaction Xác định các module và các mối liên hệ theo DFD quá trình sử lýTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 157
  • 158. Dòng Transform Dòng transform bao gồm 3 phần: dòng đi vào, dòng xử lý và dòng đi ra Doøng ñi vaøo Doøng ñi ra Doøng xöû lyùTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 158
  • 159. Dòng TransactionDòngDò đi vào à Dòng transaction bao gồm: dòng đi vào, T-center vào T center và các đường xử lý đầu raT-centerT t T-center: Chỉ có một đường ra được kích hoạt tại một thời điểm Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 159
  • 160. Thiết kế thủ tục Thiết lập thuật giải cho các module đã kiến tạo sao cho có thể dễ dàng mã hoá bằng ngôn ngữ lập trình có cấu t ú ấ trúc Có thể biểu diễn thuât giải bằng Lưu đồ thuật giải: Flowchart Ký hiệu dạng bảng ý ệu dạ g bả g N gôn ngữ PDLTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 160
  • 161. Ngôn ngữ PDL Ngôn ngữ PDL vay mượn từ vựng của ngôn ngữ tự nhiên và cú pháp của ngôn ngữ lập trình có cấu trúc. Nó có các tính chất sau: Cú pháp chặt chẽ của các từ kh á hỗ t đặ tả cấu há hặt hẽ ủ á khoá trợ đặc ấ trúc, khai báo dữ liệu, phân chia module Cú pháp tự do của ngôn ngữ tự nhiên giúp miêu tả xử lý Phương tiện mô tả dữ liệu đơn cũng như dữ liệu tổ hợp Cơ chế định nghĩa chương trình con và phương cách gọiTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 161
  • 162. Ngôn ngữ PDL – Ví dụprocedure AnalyzeTriangle( a, b, c: in real; type: out string)begin sort a, b, c so that a >= b >= c; if ( c > 0 and a < b + c ) if ( a = c ) type : “Equilateral” := else if ( a = b or b = c ) type := “Isosceles” else if ( a*a = b*b + c*c ) type := “Right” else type : “Scalene” := else type := “Error”endTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 162
  • 163. Thiết kế phần mềm UMLLược đồ cộng tácLược đồ tuần tự ồ ầLược đồ trạng thái các lớp/đối tượngLược đồ hành độngHoàn chỉnh lược đồ lớp
  • 164. Giới thiệu Giai đoạn thiết kế quan tâm đến “HOW”: HOW : Thứ tự các thông điệp trao đổi, thông số của thông điệp Thuật giải của tác vụ đáp ứng Cấu trúc dữ liệu cho các thuộc tính ấ Framework (console, document/view, 3-tier...) Thiết kế cũng chịu ảnh hưởng từ: N gôn ngữ lập trình và thư viện lập trình (Hỗ trợ Vector, List, Map... hay không ? Hỗ trợ template hay không ?...) Kiến trúc hệ thống (COM, CORBA hay EJB) Thiết lập mô hình động (dynamic modeling) và chi tiết hoá mô hình tĩnhTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 164
  • 165. Khái niệm mô hình động Lược đồ lớp chỉ mô tả khía cạnh tĩnh của hệ thống Hành vi của hệ thống được mô tả bằng mô hình động bao gồm Tương tác giữa các đối tượng: cộng tác hay trình tự ố Trạng thái của đối tượng/lớp Quá trình hoạt động của lớp/đối tượngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 165
  • 166. Tương tác giữa các đối tượng Đối tượng tương tác với nhau (interaction) bằng cách gửi/nhận kích thích (stimulus) Actor cũng có thể gửi kích thích đến đối tượng Kích thích khiến một tác vụ thực thi, một đối tượng được tạo ra hay huỷ đi, hoặc gây ra một tín hiệu Thông điệp (message) là đặc tả của kích thích Các loại thông điệp Đơn giản Đồng bộ Bất đồng bộ Trả về của gọi hàmTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 166
  • 167. Sự cộng tác – Lược đồ cộng tác Cộng tác (collaboration) định nghĩa tập hợp các thành phần tham gia và quan hệ giữa chúngg Các thành phần tham gia là vai trò mà đối tượng/lớp đóng vai khi tương tác với nhau Các vai trò của đối tượng thường chỉ có nghĩa đối với một mục đích nào đó Lược đồ cộng tác (collaboration diagram) được thiết lập để cụ thể hoá một use-case hoặc một tác vụ áTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 167
  • 168. Lược đồ cộng tác Lược đồ cộng tác là một đồ thị liên kết các vai trò của các đối tượng hình thành nên các chức năng của hệ thống (các usecase) Mỗi cạnh liê kết 2 vai t ò đ h liên i trò được biể diễ bằ biểu diễn bằng mộtột đoạn thẳng Tương tác được thể hiện bằng gửi/nhận thông điệp Hai vai trò liên kết với nhau khi có trao đổi thông điệp Mỗi thông điệp được thể hiện bằng mũi tên (như đã miêu tả) cộng với phần đặc tảTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 168
  • 169. Lược đồ cộng tác (tt) Các thông điệp được đánh số theo kiểu phân cấp 3.4.2 xảy ra sau 3.4.1 và cả hai được lồng (nested) trong 3.4 y ợ g( ) g 3.4.3a và 3.4.3b xảy ra đồng thời và được lồng trong 3.4 Cú pháp tổng quát của thông điệpprecedessor guard-condition sequence-expression return- value := message-name argument-list Ví d dụ: 2/ 1 3 1 p := find(specs) 1.3.1:Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 169
  • 170. Lược đồ cộng tác (tt) Lược đồ cộng tác có thể được thiết lập ở một trong 2 dạng:Dạng cụ thể: mỗi vai trò được biểu diễn bằng một ký hiệu của đối tượ cụ thể các thô điệ đượ t ủ tượng thể, á thông điệp được trao đổi t ê các trên á đường liên kếtDạng đặc tả: mô tả các lớp; các đường liên kết được ánh xạ ạ g ặ p; g ợ ạ vào các thông điệp Thiết lập lược đồ cộng tác giúp cụ thể hoá (realize) các use-case use case và nhận diện thêm một số tác vụ của các đối tượng/lớp phân tíchTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 170
  • 171. Lược đồ cộng tác – Ví dụ Ví dụ: lược đồ cộng tác mức cụ thể cho use case use-case Login của hệ thống đăng ký môn học tín chỉ qua WEB 1: login(uname,pswd) : People 1.2 [succ = true]: welcome : LoginForm 1.1: succ := Verify(uname,pswd) :D t b DatabaseTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 171
  • 172. Lược đồ cộng tác – ví dụ 2 2: registerVí dụ: lược đồ 1: submit(uname psswd) submit(uname, : LoginForm cộng tác mức 1.2 [succ = true]: : Student welcome cụ thể cho ụ 3: submit(crsOffering) use-case 3.4: beSuccessful 2.1: create Registers 1.1: succ := verify(uname, psswd) regForm : RegisterForm course của hệ thống đăng ký 3.1: reg := FetchReg(crsOffering) 3.3: SetReg(reg) môn học tín 3.2: AddStudent(code) : Registration chỉ qua WEB : DatabaseTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 172
  • 173. Miêu tả trình tự Lược đồ cộng tác miêu tả sự tương tác theo khía cạnh không gian Để nhấn mạnh trình tự của tương tác ・ dùng lược g g đồ tuần tự (sequence diagram) Lược đồ tuần tự miêu tả các đối tượng tương tác với nhau th thời gian sống của nó ới h theo i ố ủ ó Các thông điệp được trao đổi theo trình tự thời gian Các mối liên kết không được thể hiện trong lược đồTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 173
  • 174. Lược đồ tuần tự Lược đồ tuần tự có 2 dạng Dạng tổng quát: thể hiện cả vòng lặp và rẽ nhánh Dạng cụ thể: miêu tả một kịch bản cụ thể Thời gian sống của mỗi đối tượng được mô tả theo một g g ợ g ợ ộ đường thẳng đứng Thông thường thời gian trôi theo chiều từ trên xuống dưới Ít khi quan tâm đến khoảng thời gian thường chỉ quan tâm gian, đến trình tự mà thôi Thanh hình chữ nhật mô tả sự thực thi của một tác vụ để đáp ứng lại thông điệp gửi đến. Độ dài của thanh chữ nhật phản ánh thời gian thực thi của tác vụ và tính chất lồng nhau (nested) giữa chúng Các dòng text phụ trợ (mô tả tác vụ, ràng buộc thời gian...) được viết ở lề tráiTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 174
  • 175. Lược đồ tuần tự - Ví dụ Ví dụ: lược đồ tuần tự dạng tổng quát ob2 : C2 ob3 : C3 ob4 : C4 : People eop e new( ) ob1 : C1 [x<0] op2( ) [x>=0] op3( ) op4( y ) op5( ob3 ) display( )Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 175
  • 176. Lược đồ tuần tự - Ví dụ Lược đồ tuần tự với các ghi chú ràng buộc thời gian ợ ự g g ộ g :Computer :PrinterServer :Printer : Operator print(ps-file ) print(ps-file) a print(ps-file){b - a < 5 seconds} bTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 176
  • 177. Lược đồ tuần tự - Ví dụ Ví dụ: lược đồ tuần tự dạng cụ thể cho use-case Login use case của hệ thống đăng ký môn học tín chỉ qua WEB : LoginForm : Database : People 1: b it( 1 submit(uname, psswd) d) 1.1: verify(uname, psswd) 1.2: welcomeTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 177
  • 178. Lược đồ tuần tự - Ví dụ Lược đồ tuần: Student regForm : RegisterForm : LoginForm : Registration : Database tự dạng 1: submit(uname, psswd) 1.2: 1 2: welcome 1.1: verify(uname, psswd) cụ thể cho use- 2: register 2.1: create case 3. submit(crsOffering) Register 3.1: reg := fetchReg(srcOffering) 3.2: addStudent(code) cou ses courses 3.3: setReg(reg) 3.4: beSuccessful( )Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 178
  • 179. Trạng thái của đối tượng Chuẩn UML đưa ra lược đồ trạng thái để biểu diễn hành vi của một phần tử bất kỳ bằng cách chỉ ra đáp ứng của nó đối với các sự kiện bên p g ự ệ ngoài Thông thường lược đồ trạng thái được áp dụng cho đối tượng/lớp biểu diễn hành vi của lớp ể ễ Trạng thái của mỗi đối tượng (định nghĩa gốc ?) í nhiều sẽ bị thay đổi trong suốt chu kỳ ít ề ổ ố ỳ sống của đối tượngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 179
  • 180. Trạng thái của đối tượng Trong UML ký hiệu của trạng thái là một hình chữ nhật tròn góc và được chia làm nhiều phần phân cách nhau bằng các đoạn thẳng nằm ngang: Phần tên hầ ê Phần miêu tả các hành động bên trong Typing Password entry / set echo visible exit / set echo normal character / handle character help / display helpTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 180
  • 181. Trạng thái của đối tượng Tên trạng thái là duy nhất trong lược đồ; có thể không ạ g y g ợ ; g có tên (trạng thái vô danh) Các hành động bên trong: các hành động hoặc tác vụ được thực hiện khi đối tượng nằm ở trạng thái đang xét; có cú pháp như sau action-label ’/’ action-expression Một ố hã hành động ( i l b l) đ Mộ số nhãn hà h độ (action-label) được quy ước ớ trước: entry: thực hiện hành động tại thời điểm bắt đầu trạng thái exit: thực hiện hành động tại thời điểm kết thúc trạng thái do: thực hiện hành động suốt trạng thái hoặc cho đến khi kết thúc nó include: triệu gọi một máy trạng thái con khácTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 181
  • 182. Trạng thái của đối tượng Các nhãn hành động khác chỉ ra sự kiện kích hoạt hành động tương ứng trong biểu thức hành động (action-expression) Cú pháp của biểu thức hành độngevent-name ’(‘ parameter-list ’)’ ’[‘guard-condition’]’ ’/’ ( ) [ guard-condition ] / action-expressionTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 182
  • 183. Lược đồ trạng thái Trạng thái bắt đầu: khi đối tượng được tạo ra hoặc trạng thái tổng hợp được xác định; ký hiệu Trạng thái kết thúc: khi đối tượng bị huỷ bỏ hoặc trạng thái tổng hợp trở nên không xác định; ký hiệu Trạng thái tổng hợp (composite) được phân rã thành nhiều trạng thái con đồng thời hoặc các trạng thái con loại trừ h l i t ừ nhauTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 183
  • 184. Lược đồ trạng thái – trạng thái tổng hợp Phân rã trạng thái tổng hợp Running Running R nning Forward Backward Slow FastTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 184
  • 185. Lược đồ trạng thái Sự kiện (event) kích hoạt dịch chuyển trạng thái, có thể là Một điều kiện trở nên đúng (chú ý khác với guard-condition) Một đối tượng nhận tín hiệu từ đối tượng khác ố ố Một phép gọi tác vụ Một khoảng thời gian đã trôi qua kể từ một sự kiện nào đó Cú pháp của sự kiện: event-name ’(’ parameter-list ’)’ Sự kiện có tầm vực thuộc về package chứa lớp đang mô tả lược đồ trạng thái, chứ không chỉ thuộc về riêng lớp đóTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 185
  • 186. Lược đồ trạng thái – Dịch chuyển Dịch chuyển trạng thái là quan hệ giữa hai trạng thái theo đó đối tượng đang ở trạng thái thứ nhất sẽ chuyển sang trạng thái thứ hai đồng thời sẽ thực hiện một số hành động khi sự kiện tương ứng xảy ra và thoả mãn một số điều kiện nhất định Được ký hiệu như một mũi tên hướng từ trạng thái ợ ý ệ ộ g ạ g nguồn đến trạng thái đích và được gán nhãn Nhãn có cú pháp: event-signature ’[’ guard-condition ’]’ ’/’ action expression action-expressionTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 186
  • 187. Lược đồ trạng thái – Ví dụ lược đồ trạng thái của lớp Message hightlight Composed focus compose command entry/ assign ID exit/ fill date Read re-fwd cmd / quote / append subject on char/ handle character entry/ convert to rich text save command read command / recover( id )send command[ recipents != null ] / parse unhightlight Sending sending done Stored logout do/ send( repc ) entry/ save into folderTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 187
  • 188. Lược đồ trạng thái – ví dụ 2 import failed No map map loaded[ image invalid ] Modeling run do/ load map do/ model(map, param) do/ load image import / map := create( file ) image loaded exit command Saved modeling done entry/ render import / map := create(file) exit command do/ store import command[ file valid ] model command viewing command save command Dirty exit command / save entry/ renderTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 188
  • 189. Lược đồ hoạt động Lược đồ hoạt động (activity diagram) là một biến thể của lược đồ ợ ạ ộ g( y g ) ộ ợ trạng thái trong đó trạng thái là sự thực thi một hành động và sự dịch chuyển được kích hoạt khi hành động hoàn tất Được dùng để mô tả một thủ tục hay thuật giải ・ tập trung vào ợ g ộ ụ y ậ g ập g các hành động Mỗi hành động được ký hiệu bằng hình vẽ như sau work Quyết Q ết định rẽ nhánh hình thoi có một đường vào và nhiề nhánh ẽ nhánh: ào à nhiều ra, mỗi nhánh được gán một guard-condition Các nhánh ra được nhập lại bằng một hình thoi khác Mỗi “đường bơi” (swimlane) đại diện một lớp hoặc một actor ỗ ờ ệ ộ ớ ặ ộTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 189
  • 190. Lược đồ hoạt động – ví dụ LoginForm Database lược đồ Show input for username hoạt and password động Verify cho tác vụ submit [ psswd invalid ] di lid [ psswd valid ] của Welcome LoginF Reject ormTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 190
  • 191. Lược đồ hoạt động – ví dụ 2 RegForm Database Registration Lược đồ hoạt submit động cho tác Read course offerings Look for registration vụ submit của [ reg found ] RegisterForm [ reg not found ] Create Fetch registration registration Show Update Add success registration studentTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 191
  • 192. Nhận diện một số lớp thiết kế Mô hình thiết kế phần nào chịu ảnh hưởng từ ngôn ngữ lập trình, thư viện hỗ trợ, framework, hệ điều hành và loại máy tính Một số lớ sẽ xuất hiệ khi á d ố lớp ẽ ất hiện áp dụng những yếu tố t ê hữ ế trên N gôn ngữ lập trình: template, CObject... Thư viện hỗ trợ: lớp Date Time List Map vector Date, Time, List, Map, vector, iostream… Framework: Applet, Panel, CDocument, CView, HttpServlet… Hệ điều hành: các lớp thao tác file, mở cầu nối network, các phần tử giao diện diện….Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 192
  • 193. Nhận diện một số lớp thiết kế Một số lớp khác xuất hiện làm chức năng duyệt (iterate) một lớp khác hay thực hiện các tính toán phức tạp... Sử ddụng ttrực tiế các lớ d th viện h ngôn ngữ tiếp á lớp do thư iệ hay ô ữ cung cấp, hoặc Tạo ra lớp mới bằng cách thừa kế hay tích hợp các lớp có sẵn, ví dụ CArray<Isoquant, Isoquant&> Bổ sung các lớp mới vào lược đồ lớp đồng thời cập nhật các mối quan hệ mới (bao gộp, phụ thuộc)Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 193
  • 194. Đặc tả chi tiết các thuộc tính Trong mô hình phân tích g p Message cần phải chỉ rõ kiểu <<entity>> (hoặc cấu trúc dữ liệu) # subject: String và mức độ truy xuất của # content: String các thuộc tính Có thể chọn một lớp + GetSubject( ): String cung cấp bởi thư viện + toString( ): String lập trình để cụ thể hoá ậ ì ể ể á kiểu hay cấu trúc dữ liệu bổ sung lớp của thư viện và q an hệ bao iện à quan gộp vào lược đồ lớp 1 sent CDateTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 194
  • 195. Nhận diện chính xác các tác vụ Các lược đồ mô tả hành vi (cộng tác, tuần tự, trạng thái, hành động) giúp nhận diện chính xác các tác vụ của các lớp Dựa vào các thô D à á thông điệ h hà h độ điệp hay hành động để xác đị h á định signature của các tác vụ Ví dụ: nhận diện một tác vụ của lớp Database fetchStudent( code: Long ): StudentInfo; setReg( reg: Registration );Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 195
  • 196. Nhận diện chính xác các tác vụ (tt) Ví dụ: nhận diện một tác vụ của lớp ChildView render( ); store( ); load( ); model( map: FieldMap, param ); Ví dụ: nhận diện một tác vụ của lớp LoginForm submit( uname: St i b it( String; psswd: St i ) d String ); makeWelcome( );Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 196
  • 197. Hoàn chỉnh lược đồ lớp Cập nhật các lớp mới, thuộc tính, tác vụ và các mối quan hệ mới UML định nghĩa quan hệ phụ thuộc (dependency) giữa 2 lớ h ặ package: th đổi ở một lớ package iữ lớp hoặc k thay ột lớp, k kéo theo thay đổi ở lớp, package kia Ký hiệu của quan hệ phụ thuộc là mũi tên đứt nét: lớp, package ở phía đuôi mũi tên phụ thuộc vào lớp, package phía đầu mũi tên Một số stereotype quy ước trước: <<call>>, ộ ố ớ ớ ll <<instantiate>>, <<import>>, <<refine>>, <<realize>>, <<derive>>, <<trace>> , ,Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 197
  • 198. Hoàn chỉnh lược đồ lớp – Ví dụ thêm lược đồ lớp cho hệ thống đăng ký môn học LoginForm RegisterForm <<boundary>> <<boundary>> + submit(uname: String, psswd: + submit(offering: String) CourseOffering) + makeWelcome( ) + beSuccessful( ) <<call> Database <<call> > > + fetchStudent(code: Long): StudentInfo + setReg(reg: Registration)Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 198
  • 199. Hoàn chỉnh lược đồ lớp – ví dụ 2 # map FieldMap <<entity>> i FractureIterator <<friend>> fi d Item MapIterator MapIterator<Isoquant* + current( ): > Fracture* F * # setBound(b: int) + current( ): Item + operator++() + operator--() () + Last( ) IsoquantIteratorMapIterator<Fracture*> + First( ) + current( ): Isoquant* Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 199
  • 200. Hoàn chỉnh lược đồ lớp - package Chú ý sử dụng package để tổ chức các phần tử liên quan với nhau: các lớp về bản đồ địa hình, về thông tin sinh viên/giảng viên, về cửa sổ giao diện, về các servlet… servlet Các package thể hiện kiến trúc phần mềm, thông thường g chịu ị ảnh hưởng g từ framework (Document/View, 3-tiers...) Mỗi package chứa một hoặc một vài lược đồ lớp, trong đó có thể tham chiếu đến một số lớp thuộc các package khácTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 200
  • 201. Mô hình thiết kế bao trùm cả khía cạnh tĩnh và động của hệ thống phần mềm cần xây dựng UML hỗ trợ một số lược đồ giúp mô Các thành phần tả khía cạnh động: cộng tác, tuần tự, Các thiết bị trạng thái, hành động Miêu Miê tả chính xác th ộ tí h và tá hí h á thuộc tính à tác vụ, bổ sung một số lớp thiết kế hoàn thiện khía cạnh tĩnh Thiết lập các package tạo thành kiến trúc phần mềmTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 201
  • 202. HIỆN THỰC VÀ TRIỂN KHAI Các thành phần Các thiết bị
  • 203. Giới thiệu ệ • Cần phải xây dựng chương trình chạy t ình chạ được từ kết qủa của giai đoạn thiết kế • Các lớp sẽ được cụ thể hoá p ợ ụ vào các thành phần phần mềm như thế nào và bằng ngôn ngữ lập trình gì ? • Chương trình sẽ được cài đặt ra sao trên tài nguyên tính g toán ?Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 203
  • 204. Thành phần (Component) p ( p )• Thành phần (component) biểu diễn một phần hiện thực nào đó của hệ thống• Một số stereotype quy ước trước: trước: – <<file>>: mã nguồn hay dữ liệu – <<executable>>: chương trình chạy được – <<library>>: thư viện liên kết tĩnh hay động ế – <<document>>: tài liệu được thiết lập trong quá trình phát triển – <<table>>: bảng cơ sở dữ liệuTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 204
  • 205. Thành phần (Component) p ( p )• Thành phần phần mềm (software component) bao gồm – Mã nguồn: *.cpp, *.c, *.pas, *.java, *.bas – Mã đối tượng: *.obj ố – Mã nhị phân: *.class – Chương trình thực thi: *.dll, *.exe Ch ơ t ì h th thi * dll *• Thành phần phần mềm có thể tồn tại trong thời gian biên dịch thời gian liên kết chương trình dịch, hoặc thời gian thực thiTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 205
  • 206. Lược đồ thành phần ợ p• Lược đồ thành phần là một đồ thị gồm các thành phần kết nối với nhau bởi quan hệ phụ thuộc ế ố ớ ở ệ ộ• Ký hiệu của thành phần có thể bao gồm một số hình tròn biểu diễn các giao tiếp và chứa các lớp mà nó cụ thể hoá Interface-name Component-name Class-nameTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 206
  • 207. Lược đồ thành phần – Ví dụ ợ p ụ Ví dụ: lược đồ thành phần thể hiện một số module mã nguồn của chương trình hiển thị bề mặt địa hình GeoMap FieldMap <<file>> <<file>> FieldMap Isoquant q MapCurve <<file>> Fracture MapCurveTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 207
  • 208. Lược đồ thành phần – Ví dụ ợ p ụ Ví dụ: lược đồ thành phần thể hiện thời gian thực thi của chương trình hiển thị bề mặt địa hình op12_dp.dll cbsLoader12_dp.dll <<library>> <<library>> FieldVis.exe <<executable>> Cosmo3D12.dll <<library>> IFL0.dll MFC42.dll <<library>> lib <<library>>Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 208
  • 209. Lược đồ thành phần – Ví dụ ợ p ụ Ví dụ: lược đồ thành phần của hệ thống đăng ký môn học People StudentInfo <<file>> Database PeopleInfo LectureInfo Register <<file>> RegisterForm Login <<file>> Index.shtml LoginForm <<page>>Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 209
  • 210. Gán các lớp vào các thành p p phần• Khi thiết lập các thành phần mã nguồn, chú ý gán (bind) các lớp thiết kế và chọn ngôn ngữ lập trình – Gán lớp FieldMap vào thành phần FieldMap (C++) – Gán lớp MapCurve, Isoquant và Fracture vào thành phần MapCurve – Gán lớp PeopleInfo StudentInfo LectureInfo và PeopleInfo, StudentInfo, Database vào thành phần People (Java) – Gán lớp và LoginForm vào thành phần Login (Java)• Ký hiệu của thành phần chứa ký hiệu của lớp được gán• Chú ý: component ≠ packageTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 210
  • 211. Sinh mã nguồn – Sourse code generation g g• Dựa vào đặc tả lớp để viết mã cho từng thành phần mã nguồn theo ngôn ngữ lập trình đã chọn• Viết mã sườn là công việc hơi nhàm chán ⇒ có thể được tự động hoá bởi các công cụ CASETrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 211
  • 212. Node triển khai• Node là một thiết bị vật lý có khả năng tính toán, bao gồm: máy tính, máy in, thiết bị quét card, router… gồm: á í ồ á ế é router…• Node được mô tả ở cả 2 dạng: dạng lớp và dạng instance dạng:• Node được ký hiệu như hình hộp ba chiều• Các minh dụ của thành phần có thể sống trong một minh dụ node ụ Dell Server of 600: Pentium III 600 Dell Pentium III 600Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 212
  • 213. Kết nối giữa các node g Có thể chỉ ra quan hệ liên kết giữa các node để mô tả cấu hình kết nối (connection) :Pentium II <<TCP/IP>> 450 :Silicon :Sun Ultra1 Graphics <<TCP/IP>> :Pentium III 600Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 213
  • 214. Lược đồ triển khai ợ• Lược đồ triển khai cho phép miêu tả cách cài đặt các thành phần thực thi trên các node à ầ ê á• Ví dụ: hệ thống đăng ký môn học qua WEB dụ: Java WEB Server: Client: Pentium MMX 200 Pentium III 600 <<TCP/IP>> Index.shtml CheckApplet <<page>> << >> <<applet>>Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 214
  • 215. Lược đồ triển khai ợ• Ví dụ: chương trình hiển thị bề mặt địa hình dụ: WindowsNT workstation: Pentium II 450 cbsLoader12_dp.dll op12_dp.dll <<library>> <<library>> FieldVis.exe <<executable>> executable IFL0.dll MFC42.dll Cosmo3D12.dll <<library>> <<library>> <<library>>Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 215
  • 216. Tổng kết g • Hiện thực và triển khai tập trung vào ệ ự ập g xây dựng các thành phần chạy được hoặc các thư viện, module mã nguồn, nguồn trang HTML dạng nhị phân... HTML, phân... • Các thành phần mã nguồn cụ thể hoá một số lớp thiết kế và có thể được viết bằng các ngôn ngữ lập ằ trình khác nhau • Cuối cùng triển khai các thành phần chạy được trên các thiết bị tính toánTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 216
  • 217. Kiểm nghiệm phần mềmKỹ thuật kiểm tra phần mềmKiểm tra á đường thựcKiể t các đ ờ th thi độ lậ độc lậpChiến thuật kiểm tra phần mềmAlpha, Beta testing
  • 218. Tại sao phải kiểm tra phần mềm Mặc dù được tự động hoá một ặ ợ ự ộ g ộ phần bởi các công cụ CASE, rất nhiều công đoạn trong quá trình sản xuất phần mềm vẫn được thực hiện bởi con người vẫn có khả năng xảy ra lỗi. Lỗi có thể xảy ra trong tất cả các y g giai đoạn: phân tích yêu cầu, thiết kế, mã hoá Do đó phải kiểm nghiệm chương p g ệ g trình trước khi chính thức sử dụngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 218
  • 219. Một số quan điểm – khái niệm Kiểm nghiệm phần mềm là hoạt động thực thi g ệ p ạ ộ g ự chương trình với mục đích tìm ra lỗi phê phán, không phải để mang tính xây dựng Phân loại: Kiểm nghiệm black-box: kiểm tra các chức năng cụ thể của phần mềm, không quan tâm cấu trúc bên trong, thường áp d ng cho những mod le lớn dụng module lớn. Kiểm nghiệm white-box: kiểm tra cấu trúc điều khiển bên trong chương trình, thường dùng cho những những module nhỏ. Mỗi loại kiểm nghiệm có khả năng tìm ra những nhóm lỗi khác nhau nên kết hợp cả hai ợpTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 219
  • 220. Mục tiêu của kiệm nghiệm phần mềm Mục tiêu của kiểm nghiệm phần mềm là tìm ra lỗi (nếu có) với chi phí thấp nhất. Kiểm nghiệm phần mềm giúp Phát hiện được lỗi trong chương trình (nếu có). Chứng minh được phần mềm hoạt động đúng như đã thiết kế kế. Chứng minh phần mềm được viết đúng C ứ g Chứng minh được phần mềm đáp ứng yêu cầu của user p ầ ề ứ g use Góp phần chứng minh chất lượng của phần mềm.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 220
  • 221. Mục tiêu của kiệm nghiệm phần mềm Quá trình kiểm nghiệm phần mềm là tốt khi Có khả năng tìm ra lỗi cao. Không dư thừa. Biết chọn lọc: chỉ kiểm nghiệm những phần nào có khả năng tìm ra lỗi đặc trưng. Không á hứ tạp ũ không á đơn iả Khô quá phức t cũng khô quá đ giản. Chú ý: Kiểm nghiệm phần mềm không khẳng định được phần mềm không còn khiếm khuyết, chỉ khẳng định được phần mềm có lỗi và giúp giảm thiểu lỗiTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 221
  • 222. Các nguyên lý kiểm nghiệm phần mềm Việc kiểm nghiệm nên hướng về yêu cầu của khách hàng Nên được hoạch định trước một thời gian dài. Áp Á dụng nguyên lý Pareto (nguyên tắc 80-20):80% lỗi có nguyên nhân từ 20% các module cô lập và kiểm tra những module khả nghi nhất nhất. Nên tiến hành từ nhỏ đến lớn: bắt đầu từ những module riêng biệt rồi sau đó tích hợp các module lại. Không thể kiểm nghiệm triệt để một phần mềm. Nên được thực hiện bởi những đối tượng KHÔNG tham gia vào quá t ì h phát t iể phần mềm. i à á trình hát triển hầ ềTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 222
  • 223. Phương pháp kiểm nghiệm – Test case Thiết lập các test case – vận hành thử - so sánh kết quả Khái niệm test-case Dữ liệu input Thao tác kiểm nghiệm Dữ liệ output h đá ứ mong đ i của chương t ì h liệu t t hay đáp ứng đợi ủ h trình Test-case cho kiểm nghiệm black-box: chủ yếu dựa vào các yêu cầu cụ thể của chức năng phần mềm. Test-case cho kiểm nghiệm white-box: chủ yếu dựa vào cấu trúc điều khiển của phần mềm vấn đề đặt ra: số lượ t t ố lượng test-case cần thiết là quá lớ ầ á lớnTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 223
  • 224. Kiểm nghiệm các đường độc lập cơ bản Kiểm nghiệm white-box dựa vào cấu trúc điều khiển white box của thiết kế thủ tục để sinh các test-case với tiêu chí Kiểm nghiệm các đường độc lập cơ bản là một trong những phương cách kiể nghiệm white-box h h á h kiểm hiệ hi b Bảo đảm số phép thử là ít nhất đủ để phát hiện các lỗi Tất cả các đường thực thi độc lập được thử qua ít nhất một lần Thử các điều kiện rẽ nhánh ở cả 2 nhánh true và false Thử qua vòng lặp tại biên cũng như bên trong Thử qua cấu trúc dữ liệu để đảm bảo tính toàn vẹn của nóTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 224
  • 225. Đồ thị dòng chảy Mỗi node hình tròn biểu diễn một hoặc một vài tác vụ (hơi khác so với lưu đồ thuật giải) Cạnh có hướng miêu tả đường thực thi Đồ thị dòng chảy được xây dựng từ lưu đồ thuật giảisequence if until while caseTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 225
  • 226. Xây dựng đồ thị dòng chảy – Ví dụ 1 1 2,3 2 6 4,5 3 7 8 6 4 9 7 8 5 9 10 10 11 11Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 226
  • 227. Xây dựng đồ thị dòng chảy – Ví dụpprocedure: DoSomething g 11: do while x=02: if y=0 then 23: z=0; 44: elseif k=0 then 35: z=1; 6 56: else x=1;7: endif; 7 endif;;8: enddo 89: end 9Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 227
  • 228. Xây dựng đồ thị dòng chảy Phải phân rã tất cả các điều kiện phức trở thành các điều kiện đơn Mỗi node mô tả một điều kiện đơn được gọi là predicate di t a a b b x y x if a and b then y else x while a or b do xTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 228
  • 229. Xây dựng đồ thị dòng chảy – ví dụ procedure AnalyzeTriangle 5 a=c 4 a<b+c 7 2 6 c>0 a=b 10 8 a2=b2+c2 12 1 b=c 9 11 3Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 229
  • 230. Các đường độc lập cơ bản Đường thực thi? Đường thực thi cơ bản Các đường thực thi độc lập cơ bản Từ node bắt đầu đến node kết thúc, các đường thực thi cơ bản được liệt kê theo một thứ tự nào đó để đảm bảo rằng: đường đang liệt kê ít nhất đi qua một cạnh chưa được duyệt qua bởi các đường đã liệt kê trước đó Tổng số đường thực thi cơ bản độc lập nhau được tính bằng V = P + 1; trong đó P là số node phân nhánh (predicate)Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 230
  • 231. Các đường độc lập cơ bản – ví dụ Đối với chươngg trình con 1 DoSomething Tổng số đường : 2 V=3+1=4 Đường 1: 1-9 4 3 Đường 2: 1-2-3-8-1… 6 5 Đường 3: 1-2-4-5-7-8-1… Đườ 3 1 2 4 5 7 8 1 Đường 4: 1-2-4-6-7-8-1… 7Chú ý: dấu 3 chấm (…) mang ý nghĩa “không quan tâm”, từ đó có thể đi ô â ừ ó ó ể 8 theo bất kỳ cạnh nào bởi vì các cạnh sau đó đã được duyệt qua rồi 9Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 231
  • 232. Các đường độc lập cơ bản – ví dụ Đối với chương trình con g 5 AnalyzeTriangle a=c Tổng số đường : 4 a<b+ 7 V=6+1=7 c 2 Đường 1: 1-3-12 c > 6 a=b 10 Đường 2: 1-2-3-12 1 g 0 8 a2=b2 12 Đường 3: 1-2-4-5-12 b=c +c2 9 Đường 4: 1-2-4-6-7-12 3 11 Đường 5: 1-2-4-6-8-7-12 Đườ 5 1 2 4 6 8 7 12 Đường 6: 1-2-4-6-8-9-10-12 Đường 7: 1-2-4-6-8-9-11-12 1 2 4 6 8 9 11 12Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 232
  • 233. Thiết lập các test case Thiết lập một test-case cho mỗi đường thực thi cơ bản ập ộ g ự Dựa vào thuật giải để tìm ra một dữ liệu input, sau đó tính ra dữ liệu output hay đáp ứng mong đợi của thuật giải Chú ý: có thể không tạo ra được test-case cho một đường test case thực thi nào đó Ví dụ Sinh test-case cho chương trình con AnalyzeTriangle Test-case cho đường 1: Input: a = 3, b = 2, c = 0 Output mong đợi: type = “Error” Test-case cho đường 2: Input: a = 17, b = 5, c = 4 Output mong đợi: type = “Error” Test-case cho đường 3: Input: a = 6, b = 6, c = 6 Output O t t mong đợi đợi: type = “E il t l” t “Equilateral”Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 233
  • 234. Tổng kết Mục tiêu của kiểm nghiệm phần mềm là tìm ra lỗi Hai loại kiểm nghiệm: white-box và black-box. Kiểm nghiệm các đường độc lập cơ bản dùng trong kiểm nghiệm white-box, bao gồm các bước Thiết lập đồ thị dòng chảy Liệt kê các đ ờ th thi độ lậ cơ bả á đường thực độc lập bản Sinh các test-case cho các đường thực thi đó Thực hiện các test case và kiểm tra kết quả Kiểm nghiệm Black-box thường dùng trong bước kiểm nghiệm tính năng của phần mềmTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 234
  • 235. Chiến thuật kiểm nghiệm phần mềmVerification & ValidationUnit test Integration t tU it t t & I t ti testKiểm nghiệm hướng đối tượngNghệ thuật gỡ rối
  • 236. Khái niệm Chiến thuật kiểm tra phần mềm tích hợp các phương pháp tạo ra test-case trở thành một chuỗi các bước có thứ tự để có thể kiểm nghiệm phần mềm thành công với chi phí thấp. Bao gồm các công việc Lập kế hoạch kiểm nghiệm Sinh test-case Thực hiệ kiể nghiệm, thu thập kế qủa và đá h giá h hiện kiểm hiệ h hậ kết ủ à đánh iá Verification: các hành động để đảm bảo cho phần mềm được hiện thực đúng theo một chức năng cụ thể nào đó “Are we building the product right ?” Validation: các hành động để đảm bảo cho phần mềm được xây dựng theo đúng yêu cầu của khách hàng “Are we building the Are right product ?”Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 236
  • 237. Một chiến thuật kiểm nghiệm phổ biến Phân tích toàn bộ hệ thống Kiểm nghiệm toàn bộ hệ thống Phân tích yêu cầu Kiểm nghiệm tính năng Thiết kế Kiểm nghiệm tích hợp Mã hóa Kiểm nghiệm đơn vị (module)Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 237
  • 238. Một chiến thuật kiểm nghiệm phổ biến Bắt đầu tại từng module rồi tích hợp lớn dần đến toàn bộ hệ thống. Các kỹ thuật khác nhau được sử dụng thích hợp tại các giai đ i i đoạn khá nhau. khác h Kiểm nghiệm có thể được tiến hành bởi người phát triển phần mềm, nhưng đối với các dự án lớn thì việc kiểm nghiệm phải được tiến hành bởi một nhóm độc lập. Kiểm nghiệm và sửa lỗ là các h ể hệ à ử lỗi á hoạt độđộng độ lậ độc lập nhưng việc sửa lỗi phải phù hợp với các chiến thuật g ệ kiểm nghiệm.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 238
  • 239. Kiểm nghiệm từng module Tiến hành kiểm nghiệm trên từng đơn vị nhỏ nhất của phần mềm, đó là module mã nguồn, sau khi đã thiết kế, mã hoá và biên dịch thành công Thường dùng Th ờ dù kỹ th ật kiể nghiệm white-box thuật kiểm hiệ hit b Có thể tiến hành kiểm nghiệm cùng lúc nhiều module. Một số vấn đề trong việc xây dựng các test case Test case nào? Dữ liệu đầu vào và đầu ra có tử đâu? ữ ệu a Tính độc lập/phụ thuộc hoạt động của các moduleTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 239
  • 240. Kiểm nghiệm module driver interface local data structures Module boundary conditions ………. independent paths ~~~~~~ ~~~~~~ error handling paths ~~~~~~ stub stub test- casesTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 240
  • 241. Kiểm nghiệm module Mỗi module mã nguồn không phải là một chương trình g gp ộ g hoàn chỉnh và đôi khi phải gọi các module chưa được kiểm nghiệm khác có thể phải thiết lập driver và/hoặc stub: phí tổn khá lớn (70%) / ặ p ( ) Driver là một chương trình chính có nhiệm vụ nhận dữ liệu kiểm nghiệm, chuyển dữ liệu đó xuống cho module để kiểm tra và in ra các kết quả kiểm tra tương ứng. Stub thay thế các module được gọi bởi module đang kiểm tra tra.Làm thế nào để giảm các chi phí tạo driver hay stub g p ạ yTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 241
  • 242. Kiểm nghiệm tích hợp Từng module mã nguồn đã hoạt động đúng. Liệu khi kết hợp chúng lại thành một nhóm lớn chúng có hoạt động đúng không ? Phải tiế hà h kiể nghiệm tí h h tiến hành kiểm hiệ tích hợp để phát hiệ lỗi hát hiện liên quan đến giao tiếp giữa các module. Tránh tích hợp kiểu big-bang: tất cả các module được kết hợp lại, và toàn bộ chương trình sẽ được kiểm nghiệm một lú hệ ộ lúc Nên tích hợp tăng dần: từ trên xuống hoặc từ dưới lênTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 242
  • 243. Tích hợp từ trên xuống Module chính được dùng như là driver, và stub được thay thế bởi các module con trực tiếp của của module chính này. Tuỳ thuộc à á h tích hợp th T ỳ th ộ vào cách tí h h theo chiều sâu (d th hiề â (depth- first) hoặc chiều ngang(breath-first), mỗi stub con được thay thế một lần bởi module tương ứng đã kiểm ợ y ộ g g nghiệm. Tiến hành kiểm nghiệm khi có sự thay thế mới Tiến hà h k ể nghiệm hồ quy để phát h ệ các lỗ ế hành kiểm h ệ hồi há hiện á lỗi khác trong từng moduleTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 243
  • 244. Tích hợp từ trên xuống M1 M2 M3 M4 M5 M6 M7 Tích hợp kiểu từ trên xuống theo hình thức depth-first M8 Tiết kiệm được chi phí tạo các driverTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 244
  • 245. Tích hợp từ dưới lên Các module mức thấp nhất được kết hợp thành các nhóm thể hiện một chức năng con đặc biệt của phần mềm. Một d i driver đ được t ra để th tá các t t tạo thao tác á test-case Các module được kiểm nghiệm theo từng nhóm (Cluster): là nhóm các module mà module phía trên cần đến khi kiểm nghiệm Driver được bỏ đi và các nhóm module được kết hợp dần lên hí dầ lê phía trên trong sơ đồ phân cấp của chương ê hâ ấ ủ h trình. Tiết kiệm được chi phí tạo các stubTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 245
  • 246. Tích hợp từ dưới lên Mo Ma Mb D1 D2 D3 cluster 3cluster 1 r cluster 2 Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 246
  • 247. Kiểm nghiệm hồi quy Việc kết hợp các module lại với nhau có thể ảnh hưởng đến vòng lặp điều khiển, cấu trúc dữ liệu hay I/O chia sẻ trong một số module Điều Điề đó là lộ ra một số lỗi khô thể phát hiệ đ làm ột ố không hát hiện được khi tiến hành kiểm nghiệm theo đơn vị Phải kiểm nghiệm hồi quy khi tích hợp Kiểm nghiệm hồi quy có thể được tiến hành thủ công bằng cách thực hiện lại các test-case đã tạo ra. Hoặc có thể dù ó hể dùng một công cụ capture-playback để thực ộ ô l b k h hiện tự độngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 247
  • 248. Kiểm nghiệm tính năng Kiểm nghiệm tính năng hiểu theo cách đơn giản g ệ g g nhất là: kiểm tra các chức năng của phần mềm đáp ứng được nhu cầu của khách hàng đã được xác định trong văn bản đặc tả yêu cầu của phần mềm g ặ y p Áp dụng kỹ thuật black-box Kiểm nghiệm tính năng bao gồm Xem xét lại cấu hình phần mềm theo lược đồ triển khai Kiểm nghiệm alpha Kiểm nghiệm betaTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 248
  • 249. Kiểm nghiệm tính năng Kiểm nghiệm alpha Được tiến hành ngay tại nơi sản xuất phần mềm. N hà phát triển phần mềm sẽ quan sát người sử dụng p p q g ụ g dùng sản phNm và ghi nhận lại những lỗi phát sinh để sửa chữa. Kiểm hiệ beta Kiể nghiệm b t Phần mềm được kiểm tra bên ngoài phạm vi của đơn vị sản xuất xuất. Khách hành trực tiếp sử dụng và ghi nhận lỗi để báo lại cho nhà phát triển sửa chữa.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 249
  • 250. Kiểm nghiệm hướng đối tượng Về cơ bản chiến thuật kiểm nghiệm hướng đối tượng cũng theo thứ tự giống như kiểm nghiệm cổ điển:Kiểm nghiệm đơn vị ể Kiểm nghiệm tích hợp ể Kiểm nghiệm chức năng Kiểm nghiệm toàn bộ hệ thốngTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 250
  • 251. Kiểm nghiệm hướng đối tượng Không thể tách rời từng tác vụ của đối tượng/lớp để kiểm nghiệm Tác vụ được đóng bao trong lớp Các lớp con có thể override một tác vụ nào đó Kiểm Kiể nghiệm đơ vị hướ hiệ đơn ị hướng đối tượ tượng tậ t tập trung vào à các lớp kiểm nghiệm hành vi của lớpTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 251
  • 252. Kiểm nghiệm tích hợp hướng đối tượng Khái niệm sơ đồ phân cấp không còn nhiều ý nghĩa trong chương trình hướng đối tượng kiểm nghiệm tích hợp theo cách khác Hai hình thức kiểm nghiệm tích hợp hướng đối tượng Kiểm nghiệm trên cơ sở thread: tích hợp các lớp tạo thành một thread để phục vụ cho một input nào đó của chương trình Kiểm nghiệm trên cơ sở sử dụng: các lớp client sẽ được tích hợp để sử dụng dịch vụ nào đó cung cấp bởi các lớp serverTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 252
  • 253. Kiểm nghiệm theo kịch bản Dựa vào các use-case để soạn ra các kịch bản use case Ví dụ: một kịch bản cho hệ thống đăng ký môn học qua WEB1. Login với username = “e59306547”, password = “6547”2. Chọn chức năng đăng ký môn học3. Chọn 5 nhóm môn h của 5 môn: CNPM AI XLTHS3 Ch hó ô học ủ ô CNPM, AI, XLTHS, PTTK, XLSS trong đó có 2 nhóm trùng thời khoá biểu4. Nhấn nút SubmitChương trình phải báo lỗi và liệt kê 2 nhóm bị trùng thời khoá biểuTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 253
  • 254. Nghệ thuật gỡ rối - DEBUG Gỡ rối là một quá trình nhằm loại bỏ các lỗi được phát hiện trong quá trình kiểm tra. Gỡ rối được thực hiện như là một kết quả của việc kiểm tra: lỗi phát hiện được tìm kiếm nguyên nhân sửa lỗi Có 3 hình thức gỡ rối: brute force, loại trừ nguyên nhân và theo vết. Nên dùng kết hợp cả 3 hình thức này.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 254
  • 255. Nghệ thuật gỡ rối Gỡ rối là công việc khó khăn và dễ gây tâm lý chán nản bởi nguyêng nhân gây ra lỗi nhiều khi ỗ lại mơ hồ: do timeout, do độ chính xác, do chủ ộ , quan lập trình... Khả năng gỡ rối gần như là bẩm sinh của mỗi ngườiTrường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 255
  • 256. Brute Force Là phương pháp phổ biến nhất nhưng lại ít hiệu quả p g p p p g ạ ệ q nhất cho việc phát hiện nguyên nhân gây lỗi phần mềm. Triết lý của phương pháp này là: “Hãy để máy tính tìm Hãy ra lỗi”. Có 3 cách thực hiện: Lấy d li trong b nhớ để xem xét. ấ dữ liệu bộ h Dùng run-time trace để tìm lỗi. Dùng lệnh WRITE để xuất dữ liệu cần kiểm tra ra màn hình. Áp dụng phương pháp này khi tất cả các phương pháp khác đều thất bại bại.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 256
  • 257. Loại trừ nguyên nhân Phương pháp này dựa trên nguyên tắc phân chia nhị phân. Cách thực hiện: Khi một lỗi được phát hiện, cố gắng đưa ra một danh sách các nguyên nhân có thể gây ra lỗi. Danh sách này được nghiệm lại để loại bỏ dần các nguyên nhân không đúng cho đến khi tìm thấy một nguyên nhân khả nghi nhất. Khi đó dữ liệu kiểm nghiệm sẽ được tinh chế lại để tiếp tục tìm lỗi.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 257
  • 258. Theo vết Là một phương pháp gỡ lỗi khá phổ biến có thể dùng thành công trong các chương trình nhỏ nhưng khó áp dụng cho đối với các chương t ì h rất lớ d h ới á h trình ất lớn. Cách thực hiện: bắt đầu tại dòng mã nguồn có triệu chứng lỗi thực hiện lần ngược trở lại từng dòng mã nguồn cho đến khi tìm thấy dòng gây ra lỗi.Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông TinCopyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn 258
  • 259. Kết thúc môn học Thi cuối kỳ ? ối Giới thiệu-Phân tích Thiết kế - Hiện thực/triển khai Kiểm nghiệm - UML Tất cả nội dungChúc mừng bạn đã hoàn tất môn học Công Nghệ Phần Mềm !