Bài giảng Công nghệ Phần mềm (Software Engineering)

Nội dung text: Bài giảng Công nghệ Phần mềm (Software Engineering)

1. Trường Đại Học Bách Khoa TP.HCM Khoa CƠNG NGHỆ THƠNG TIN BàiBài GiảngGiảng Cơng Nghệ Phần Mềm SoftwareSoftware EngineeringEngineering
2. Giáo viên & Giao tiếp giảng dạy ThS Nguyễn Cao Trí – ngacotri@gmail.com Room 109 A5 – Trung tâm Kỹ thuật Điện tốn Tel: 8647256 – 5370 Mobile: 091 391 6290 Hobbies: Automation , Flying Model • Tài liệu download trên website file: TailieudientuCNPM- 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ệt 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 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) – 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. 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 4
5. Đặc tính của sản phẩm 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 phẩm đĩng gĩi và bán rộng rãi trên thị trường. – Bespoke Product: là sản phẩm được phát triển theo yêu cầu đặc thù của từng khách hàng. • Các đặc tính quan trọng của sản phẩm phần mềm – Maintainability: phần mềm cĩ thể thay đổi thuận tiện theo yêu cầu của người dùng – Dependability: tính ổn định, bảo mật và an tồ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. – 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ùng 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 5
6. Software - Đủ hay Thiếu? • 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 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 cầu của người sử 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ùng 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 6
7. Nguyên nhân khách quan • 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. • 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 hồn tồn người sử 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 đầy đủ 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ùng 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 7
8. Nguyên nhân chủ quan • 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ống lớn cĩ lỗi khi thực thi – 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ã hố, kiểm tra và bảo trì: để lại 15 % lỗi, cĩ 72 % phát hiện được 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 8
9. Nguyên nhân chủ quan (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ự thay đổi về ngơn ngữ, h/w hoặc o/s – 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 – 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ỀM 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 9
10. Định nghĩa “Cơng nghệ phần mềm” • 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. • 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 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). 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 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 mềm vận hành đúng mức độ yêu cầu về cơng việc và thời 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 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à người sử dụng đang cĩ. Chú ý tới giao diện, điều kiện hệ thống, • Modifiability: Phần mềm cĩ thể được thay đổi dể dàng, nhanh chĩng khi yêu cầu của người sử dụng thay đổ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 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. • Testability: Phần mềmcĩ thể d0ược kiểm tra dễ dàng. Tốt nhất là được modul hĩ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 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễ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 giao thuận tiện cho người khác trong quá trình điều chỉnh, nâng cấp hay thay đổi theo yêu cầu. • Interoperability: Phần mềm vận hành ổn định và đúng như mong đợi. Trên hệ 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. • Correctness: Phần mềm phải tính tốn đúng và tạo ra kết quả đúng và đúng với mục tiêu ứng dụng của người dùng. • Các yêu cầu 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 12
13. Nội dung cơng việc của Software Engineering Cơ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 • Thiết kế phần mềm • Dự đốn tài nguyên Viết phần mềm (coding) • 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 • Lập tài liệu • Bảo trì 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 13
14. Một định nghĩa khác của CNPM • 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 đúng thời gian và chất lượng Qui trình Đo lường Thời gian Chất lượng Tiêu chuẩn Quản lý Dịch vụ 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 14
15. Mơ hình phát triển phần mềm Cá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 động của hệ thống. (thu thập yêu cầu và phân tích) • Giai đoạn phát triển: Thiết kế phần mềm (software design), viết code (code generation • Giai đoạn kiểm tra: kiểm tra phần mềm (software testing), kiểm tra tính hợp lý của phần mềm. • Giai đoạn bảo trì: Sửa lỗi (correction), thay đổi mơi trường thực thi (adaptation), tăng cường (enhancement) 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 15
16. Các mơ hình sản xuất phần mềm Tù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. • Mơ hình tuần tự tuyến tính- waterfall • 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ƠN Mỗ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. 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 16
17. Mơ hình WaterFall – Sequency model • 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 Phân tích yêu cầu Thiết kế hệ thống & phần mềm Hiện thức và kiểm tra moduls Tích hợp và kiểm tra tổng thể Chuyển giao và Bảo trì 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 17
18. Mơ hình WaterFall – Sequency model (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 hồn tồn mà cĩ 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 “delay” tích lũy trong nhĩm làm việc -> dự án thường bị trễ. • Chỉ phù hợp cho dự án nhỏ, đơn giả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 18
19. Mơ Hình Prototype Hoạt động sản xuất Bản prototype Đặc tả Mơ tả sơ lược Các bản trung của khách hàng Phát triển gian Kiểm thử Bản cuối cùng 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 19
20. Mơ Hình Prototype – ưu & khuyết • 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í • 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 • 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 hồn thành sản phẩm một khi thấy được các prototype đầu tiê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 20
21. Mơ Hình Prototype – Ứng dụng • Dùng cho các hệ thống nhỏ. Các chi phí khi thay đổi hệ 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 cần được đưa vào ứng dụng từng phần trong khoảng thời gian nhất đị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. 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 21
22. Mơ hình Xoắn Ốc - Boehm’s Spiral Model 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 đề á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 22
23. Mơ hình RAD Application Data Process modeling Testing & Business modeling generation modeling Turnover • 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ứ 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. • Partten system development 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 23
24. Các tiêu chuẩn dùng trong CNpPM • The capability Maturity Model (CMM) của Software Engineering Institue (SEI) - Đại học Carnegie 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 • The European ESPRIT project • International Standards Organisation - ISO 9001 • United Kingdom MOD 0055 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 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ự đốn (Predictability) Managed •Các quy trình quản lý và tiêu chuẩn được chi tiết hĩa (Level 4) Risk 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) Competitiveness Repeatable (Level 2) •Bắt đầu cĩ khả năng quản lý •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â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 25
26. Chương 2 Project Management oSub-Team trong Software Projects oProject Estimation oProject Scheduling oProject Management Tools
27. Tại sao cần Project management o Phát triển phần mềm hiện đại làm theo teamworks o Cần quản lý và kiểm sốt được rủi ro (Risk) trong quá trình sản xuất o 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ác nhau o Tính tích hợp cơng nghệ cao và sự thay đổi nhanh chĩng của cơng nghệ o Phải bảo đảm tính chuyên nghiệp trong phát triển dự án phần mềm: n Bảo đảm lịch trình của dự án n Điều phối và khai thác tối đa nguồn nhân lực hiện cĩ n Bảo đảm chất lượng của sản phẩm n Khả năng khắc phục các sự cố xảy ra khách quan o 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 27
28. SUB-Team trong software engineering o 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 n Khả năng chuyên nghiệp hĩa cao Team Team n Hiệu quả trong quản lý, giao 6 5 tiếp và điều hành Team Team Project 2 o Một software project team 2 được tạo ra từ nhiều sub- 1 teams Team Team n 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 n 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 phần mềm 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 28
29. Các Sub-Team o System analysis o Planning Team o Requirements Team o System Design Team Vai trị o Implementation Team o Tesing & Intergration Team nhiệm vụ o Training Team o Delivery & Installation Team của các o Maintenance Team SUB Team o Quality Assurance Team o Metrics Team o Documentation Team o System Administration Team o Reuse & Reengineering Team 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 29
30. Vai trị & nhiệm vụ các Sub-Team o System analysis o Planning Team System Analysis Xác định tính khả thi của dự án o Requirements Team • Phân tích chi phí (Cost analysis) o System Design Team • Dự đốn lợi nhận (Estimate revenues) o Implementation Team • Tiên liệu các khĩ khăn về kỹ thuật o Tesing & Intergration Team và cơng nghệ o Training Team •Sau khi nghiên cứu khả thi, nhĩm o Delivery & Installation Team này sẽ làm việc với Requirement o Maintenance Team Team để nhận feedbacks o Quality Assurance Team •Nếu dự án được phát triển theo mơ hình tương tác cao như o Metrics Team Prototype/Spiral model thì tính tương o Documentation Team tác và feedback là rất quan trọng kể o System Administration Team cả với các nhĩm khác. o Reuse & Reengineering Team 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 30
31. Các Sub-Team o System analysis o Planning Team o Requirements Team Planning Team Nhĩm này cĩ nhiệm vụ xây dựng tổng o System Design Team thể tất cả các kế hoạch quản trị dự án o Implementation Team và bảo đảm các tiến trình diển ra đúng o Tesing & Intergration Team tiến độ đã định o 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 o Delivery & Installation Team •Kế hoạch sử dụng tài nguyên của hệ o Maintenance Team thống bao gồm cả nhân lực o Quality Assurance Team •Các kế hoạch dự phịng và điều chỉnh o Metrics Team khi cĩ sự cố o Documentation Team o System Administration Team o Reuse & Reengineering Team 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 31
32. Các Sub-Team o System analysis Requirement Team Planning Team Requirement Team o Tiếp xúc khách hàng và xác định đầy o Requirements Team đủ, hồn chỉnh và chính xác các yêu o System Design Team cầu cho dự án o Implementation Team •Dùng các phương thức gặp gở chính Tesing & Intergration Team thức và bên lề để xác định các yêu o cầu của hệ thống o Training Team •Nếu khơng cĩ khách hàng, cĩ thể o Delivery & Installation Team tiếp xúc với các user tiềm năng o Maintenance Team Sau khi xác định các yêu cầu, nhĩm Quality Assurance Team này sẽ làm việc với System Design o Team để nhận các feedback. o Metrics Team Nếu dự án được phát triển theo mơ o Documentation Team hình tương tác cao như o System Administration Team Prototype/Spiral model thì tính tương Reuse & Reengineering Team tác và feedback là rất quan trọng kể o cả với các nhĩm khác 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 32
33. Các Sub-Team o System analysis System Design Team o Planning Team Xây dựng thiết kế chi tiết của hệ o Requirements Team thống sau khi các yêu cầu đã được o System Design Team xác định. o Implementation Team Nếu sử dụng mơ hình Waterfall, nhĩm này phải feedback cho o Tesing & Intergration Team nhĩm Requirement những khĩ o Training Team khăn nếu cĩ. o Delivery & Installation Team Sau khi hồn chỉnh thiết kế, nhĩm o Maintenance Team này phải cộng tác với Implementation Team để nhận o Quality Assurance Team feedback. o Metrics Team Nếu dự án được phát triển theo o Documentation Team mơ hình tương tác cao như o System Administration Team Prototype/Spiral model thì tính tương tác và feedback là rất quan o Reuse & Reengineering Team trọng kể cả với các nhĩm khác 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 33
34. Các Sub-Team o System analysis o Planning Team Implementation Team o Requirements Team Phát triển hệ thống theo thiết kế đã cĩ. o System Design Team • Coding o Implementation Team • Kiểm tra cấp Module o Tesing & Intergration Team Sau khi hồn tất chương trình, o Training Team nhĩm này sẽ cộng tác với nhĩm Tesing & Integration để kiểm tra o Delivery & Installation Team các module o Maintenance Team Nếu dự án được phát triển theo o Quality Assurance Team mơ hình tương tác cao như o Metrics Team Prototype/Spiral model thì tính tương tác và feedback là rất quan o Documentation Team trọng kể cả với các nhĩm khác o System Administration Team o Reuse & Reengineering Team 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 34
35. Các Sub-Team System analysis o Testing & Integration Team o Planning Team Xây dựng thiết kế chi tiết của hệ thống o 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 o System Design Team phải feedback cho nhĩm Requirement o Implementation Team những khĩ khăn nếu cĩ. Sau khi hồn chỉnh thiết kế, nhĩm này o Tesing & Intergration Team phải cộng tác với Implementation Team để o Training Team nhận feedback. o Delivery & Installation Team Nhĩm này cĩ thể tiếp nhận các module rời rạc và kiểm tra sau đĩ tích hợp thành hệ o Maintenance Team thống hồn chỉnh. o 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 o Metrics Team thì tính tương tác và feedback là rất quan o 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 o System Administration Team Control Document để đặc tả các giao diện o Reuse & Reengineering Team và giao tiếp giữa các thành phần trong hệ thống 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 35
36. Các Sub-Team o System analysis o Planning Team o Requirements Team o System Design Team Trainning Team o Implementation Team Chuẩn bị các cơng cụ và tài liệu o Tesing & Intergration Team cho việc trainning cho người o Training Team dùng o Delivery & Installation Team •Kế hoạch trainning o Maintenance Team •Các tài liệu giảng dạy o Quality Assurance Team o Metrics Team o Documentation Team o System Administration Team o Reuse & Reengineering Team 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 36
37. Các Sub-Team o System analysis o Planning Team o Requirements Team o System Design Team o Implementation Team o Tesing & Intergration Team o Training Team o Delivery & Installation Team o Maintenance Team Delivery & Installation o Quality Assurance Team Team Nhiệm vụ là cài đặt hệ thống o Metrics Team cho khách hàng và các hỗ trợ o Documentation Team kỹ thuật trong cài đặt vận hành o System Administration Team hệ thống. o Reuse & Reengineering Team 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 37
38. Các Sub-Team o System analysis o Planning Team o Requirements Team o System Design Team o Implementation Team o Tesing & Intergration Team o Training Team Maintenance Team Bảo trì hệ thống sau khi chuyển o Delivery & Installation Team giao và cài đặt o Maintenance Team •Cập nhật sửa chữa o Quality Assurance Team •Nâng cấp mở rộng o Metrics Team Cộng tác chặt chẻ với nhĩm o Documentation Team implementation để thực hiện o System Administration Team việc maintenance o Reuse & Reengineering Team 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 38
39. Các Sub-Team o System analysis Quality Assurance Team o Planning Team Quality Assurance Team Nhĩm này cĩ 2 nhiệm vụ o Requirements Team 1. Thiết lập các tiêu chuẩn cho các o System Design Team quá trình sản xuất cũng như tiêu o Implementation Team chuẩn thực hiện của sản phẩm o Tesing & Intergration Team phần mềm 2. Cung cấp các cơ chế kiểm tra, o Training Team kiểm sốt nhằm đánh giá khả o Delivery & Installation Team năng thỏa mãn các tiêu chuẩn o Maintenance Team tương ứng của các nhĩm làm việc. o Quality Assurance Team Các tiêu chuẩn này dùng trong nội bộ và khơng chia sẻ với khách hàng. o Metrics Team Các tiêu chuẩn cĩ thể được cơng bố o Documentation Team khi cần thiết, vì vậy cần được lưu o System Administration Team trữ và báo cáo cho project o Reuse & Reengineering Team manager để hoạt động với bộ phận Q&A 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 39
40. Các Sub-Team o System analysis o Planning Team Metrics Team o Requirements Team Lưu trữ các thơng tin thống kê về o System Design Team các hoạt động của các TEAm trong dự án. o Implementation Team •Số lượng các yêu cầu o Tesing & Intergration Team maintenance o Training Team •Số lượng thực hiện dịch vụ o Delivery & Installation Team maintenance •Số dịng code được viết o Maintenance Team •Thời gian thực hiện từng cơng o Quality Assurance Team việc o Metrics Team Nhĩm này làm việc với hầu hết o Documentation Team các nhĩm để cung cấp báo cáo về chất lượng, hiệu quả, đồng thời o System Administration Team feedback cho các nhĩm đĩ về o Reuse & Reengineering Team hiệu quả cơng việc. 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 40
41. Các Sub-Team o System analysis o Planning Team o Requirements Team o System Design Team o Implementation Team o Tesing & Intergration Team Documentation Team o 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 o cho hệ thống o Maintenance Team • Tài liệu về phân tích, thiết o Quality Assurance Team kế, hiện thực, source o Metrics Team code, o Documentation Team • Tài liệu hổ trợ : userguide, o System Administration Team manual, support document o Reuse & Reengineering Team 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 41
42. Các Sub-Team o System analysis o Planning Team o Requirements Team o System Design Team o Implementation Team System Administrationm o Tesing & Intergration Team Team o Training Team Nhĩm này cĩ nhiệm vụ cung o Delivery & Installation Team cấp và bảo đảm các hoạt động của các hệ thống hạ tầng kỹ o Maintenance Team thuật cần thiết cho dự án o Quality Assurance Team Nhĩm này thơng thường bao o Metrics Team gồm cả Network Administration o Documentation Team Team o System Administration Team o Reuse & Reengineering Team 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 42
43. Các Sub-Team o System analysis o Planning Team o Requirements Team o System Design Team o Implementation Team o Tesing & Intergration Team Reuse & Reengineering Training Team o Team o Delivery & Installation Team • Chọn lựa và quyết định việc o Maintenance Team reuse các module đã cĩ o Quality Assurance Team • Việc reengineering cũng cần o Metrics Team thiết khi mà việc phát triển o Documentation Team địi hỏi phải dùng đến các o System Administration Team code cũ khi cơng nghệ đã o Reuse & Reengineering thay đổi. Team 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 43
44. Sub-Team (tt) o Cĩ rất nhiều việc quản lý trong từng nhĩm và từng cơng đoạn. o Cĩ khá nhiều nhĩm -> nhiều manager, tuy nhiên nếu các nhĩm này nhỏ thì thường là một người trong nhĩm sẽ là manager của team. o Việc scheduling giữa các team phụ thuộc vào mơ hình phát triển cụ thể là gì. o Ví dụ nếu dùng mơ hình Waterfall thì các cơng đoạn cĩ thể được tích hợp thành các bước lớn hơn, các nhĩm 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễ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, Reuse & Reengineering CODE:QA, Metrics, Documentation, System Administration, Reuse & Reengineering TESTING & INTEGRATION: QA, Metrics, Documentation, System Administration, Reuse & Reengineering MAINTENANCE: Trainning, Delivery & Instalation,QA, Metrics, Documentation, System Administration, Reuse & Reengineering 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 45
46. Các nhân sự khác trong dự án Bê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 o 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 o Tools Support Person: Người cung cấp và bảo đảo các cơng cụ cần thiết như tools, software, network vận hành theo yêu cầu của quá trình phát triển o 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 hồn tất o 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 o 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ật NHÂ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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 46
47. Các yếu tố ảnh hưởng đến các team o 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. o Các nguyên nhân khách quan khác: n Nhân sự thay đổi cơng việc: chuyên mơn thay đổi, cơng nghệ mới cập nhật n Nhân sự nghĩ do thay đổi việc, bệnh, về hưu n Nhâ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 o 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. 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 47
48. Project management o Dự đốn quy mơ và độ phức tạp của dự án o Xác định các team cần thiết cho hiện thực dự án o Xác định kế hoạch dự đốn thời gian hồn thành dự án o 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, . o Tính tốn chi phí xây dựng dự án o Xây dựng lơ trình thực hiện dự án (smiletone) o 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 48
49. Các cơng việc của Project management trong thời gian thực hiện dự án o Quản trị nhân sự: điều phối, quản lý cơng việc, o Phân bổ các tài nguyên của hệ thống theo kế hoạch o Điều phối nhân sự: trong cơng ty và bên ngồi o Xữ lý các phát sinh về thời gian biểu o Quản lý các thay đổi yêu cầu của dự án o Giải quyết các sự cố ngồi kế hoạch: máy mĩc hư hỏng, nhân sự thay đổi, o Báo cáo cho lãnh đạo về dự án o Giao tiếp với khách hàng o Staffs trainning 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 49
50. Software Project Estimation o Dự đốn điều gì? n Quy mơ của sản phẩm sẽ được phát triển n Các yêu cầu, resource cần thiết để cĩ thể phát triển sản phẩm thành cơng o Để 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 ü Các cơng cụ cho Documentation ü 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 ü Kiểm tra viên ü CASE Tools ü 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 trainning 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 50
51. Project Size o Kích thước được đo bằng “lines of code” o Làm thế nào để dự đốn được kích thước của một đề án phần mềm? n Kính thước đo bằng số dịng code được viết để hồn thành dự án n Dự án chưa thực hiện làm sao biết số dịng code sẽ được viết o Phương pháp Analogy và Reasoning-by-Analogy o Phân bố nhân lực cho dự án phần mềm trên cơ sở lines of code đã dự đốn. n Đánh giá năng xuất của mỗi người trong dự án o Metric data cho vấn đề estimated và phân bổ resource. 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 51
52. Phương pháp Analogy o Analogy là gì ? Suy luận theo analogy? o Điều kiện để sử dụng phương pháp analogy: n Cĩ bài tốn đã biết cĩ bản chất tương tự n Đã cĩ giải pháp của bài tốn đã biết o Cách áp dụng analogy n Xác định được các thơng số tương ứng giữa 2 bài tốn n Áp dụng giải pháp của bài tốn đã biết cho bài tốn mới o Với dự án phần mềm n Xác định các dữ liệu của những vấn đề đã làm nhờ vào metric n Phân tích dự án cần dự đốn thành các thành phần 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 n Tổng kích thước các phần kích thước dự á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 52
53. Dự đốn nhân lực cho dự án Lines of new code Approximate Number of •Thực tế khơng thể tăng tuyến tính 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 đề 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 ngồi dự kiến 100,000 10 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 100 dự án chứ khơng phải chỉ cĩ coding. 2,000,000 200 5,000,000 500 Tính dựa trên thơng số nào? 10,000,000 1,000 100,000,000 10,000 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 53
54. Dự đốn nhân lực theo Metric Lines of new code Approximate •Thiết lập bảng dự liệu theo số liệu thống Number 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ự đốn nhân lực cho dự án (person- 50,000 77 month )dạng 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,480 (Xem cơng thức tính m, b ở trang 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 15,960 Y thời gian thực hiện (person 100,000,000 160,027 month) X kích thước dự á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 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- 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ần phân bổ bao nhiêu người làm trong bao lâu. •Ví dụ bảng tính tố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 4 Graphics Utility 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ÀY 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 55
56. COCOMO Model o Xác định cả 2 thơng số là số nhân lực và thời gian phát triển o Trình tự thực hiện n Phân tích các yêu cầu của dự án n Xác định line of code của từng yêu cầu dự vào metric data n Trừ các phần đã được xác định là reuse code n Tổng các phần cịn lại tính được K line of code n Áp dựng cơng thức tính n E = ab * K * exp(bb) n 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ự á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 56
57. COCOMO Model (tt) o Các hệ số của cơng thức COCOMO Software Project type Ab Bb Cb Db Small project, experienced team, flexible 2.4 1.05 2.5 0.38 requirement Hard real-time rew\quirements and strict 3.6 1.2 2.5 0.32 interoperability A mixture of the other two type of projects 3.0 1.12 2.5 0.35 o 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 57
58. Project Scheduling o Scheduling bao gồm: n Xác dịnh các mốc tiến trình thực hiện dự án n Phân bổ resource cho các tiến trình của dự án o 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 ngồi kế hoạch n Phân bổ lại nguồn resource (thêm người) n 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 o Phương pháp quản trị và điều chỉnh: FUNCTION POINT o Các cơng cụ dùng trong scheduling : MS project, Cocomo2 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 58
59. Activity network model T 3 T 9 M 1 15 ngày 15 ngày 14/7/99 M 4 M 6 25/8/99 T 1 T 6 04/8/99 8 ngày M 3 5 ngày 25/7/99 T 11 7 ngày Start T 2 15 ngày T 7 04/07/99 20 ngày M 8 M 7 5/9/99 11/8/99 T 4 M 2 T 5 T 12 10 ngày 25/7/99 10 ngày T 10 10 ngày M 5 15 ngày 18/7/99 T 8 FINISH 25 ngày 19/09/99 o Thiết lập activity network: gồm các Minestone (M) và Task (T) o Xác định critical path: cĩ tổng thời gian thực hiện dài nhất o Điều chỉnh các M-i để bảo đảm deadline o Đ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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 59
60. Activities Bar Chart –PERL chart 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 M1 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 60
61. Chương 3 PhânPhân tích hệ thống (system(system analysis)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 phân tích hệ thống • 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ả tồ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 nhất với khách hàng về mơ hình và tính năng của hệ thống 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 62
63. Phân tích hệ thống • 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 đồ, • 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. • 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 63
64. Những vấn đề trong phân tích hệ thống • 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ả phân tích 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 64
65. Quy trình phân tích hệ thống • 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ân tích yêu cầu độ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 •Điều kiện hạ tầng: thiết bị, con người 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 65
66. Quy trình phân tích hệ thống • Các bước chính – Thu thập thơng tin hệ thống hiện Xác định các yêu cầu tại – Thu thập yêu cầu •Các yêu cầu về chức năng – Phân tích yêu cầu 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 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 66
67. Quy trình phân tích hệ thống • 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ân tích yêu cầu •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 quy trình cho phù hợp với máy tính •Yều cầu bổ sung các thơng tin 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 67
68. Quy trình phân tích hệ thống • 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 yêu cầu Xác lập tính 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 động 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 68
69. Quy trình phân tích hệ thống • 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ân tích yêu cầu thống – 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ụ •Xác thực các ràng buộc 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 69
70. Quy trình phân tích hệ thống • 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 yêu cầu – Xác lập tính năng hệ thống – Xác thực tính năng hệ thống Phươ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 đồ: DFD, ERD, STD 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 70
71. Phân tích hệ thống theo hướng phát triển 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ượclượ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 đồ •Mơ tả dịng thơng tin di chuyển dịng chảy 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; Hatley & Pirbhai cho realtime 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 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 chảy •Lược đồ dịch chuyển trạng thái Lược đồ quan (STD) thể hiện hệ thực thể dữ liệu 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ống 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 73
74. CÁC YẾU TỐ CĂN BẢN CỦA MƠ HÌNH Đặc tả Process Specification (PSPEC) từ điển dữ liệu Lược đồ ERD •Đặc tả các thơng tin về dữ liệu của hệ thống Lược đồ •Cấu trúc dữ liệu Lược đồ quan dịng chảy 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễ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ển dữ 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 đồ •Nếu lên ý nghĩa và phạm vi sử dịng chảy 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễ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 ngồi biên giới của 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 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 xử lý Kho Dữ Liệu Thực thể Chức năng xử lý Dữ liệu 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 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, 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ệu 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 77
78. Kỹ thuật phân tích hệ thống • 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. – Luơn luơn tuân theo tính liên tục của dịng dữ liệu • Viết PSPEC cho các chức năng của DFD mức cao nhất 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 78
79. Xây dựng DFD – Ví dụ • Phần mềm SafeHome: Thiết lập đoạn văn miêu tả xử lý • DFD mức ngữ cảnh: nhận diện các thực thể và dữ liệu input, output Bả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ện thoại 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 79
80. Xây dựng DFD – Ví dụ Bảng điều khiển DFD mức 1: hình thành Yêu cầu Cấu hình một số chức năng chính Lệ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/ Mật mã Cho phép Thơng báo Thông tin hiể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 Trạng thái cảm ứng Chuơng cảm ứng Tần số của điện thoại Bộ cảm ứng Đường điện thoại 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 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 ố Đọc lệnh th ng máy photocopy Copy xong ———————— Đầy giấy Yêu cầu đọc lệnh ———————— Yêu cầu đọc lệnh Thực hiện copy 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 cầu đọc lệnh Yêu cầu xử lý lỗi Xử lý lỗi 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 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ữ liệu, chức năng, điều khiển • 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 tất cả các phần tử dữ liệu cần thiết cho hệ thống. Các phần tử được định nghĩa chính xác và chặt chẽ sao cho cả phân tích viên và khách hàng cùng chia sẻ một suy nghĩ về 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. • Mỗi phần tử bao gồm những thơng tin: tên, bí danh, được 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễ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 ngồi ] mở rộng địa phương = [ 2001 | 2002 | 2009 ] số bên ngồi = 9 + [ số địa phương | số đường dài ] số địa phương = tiền tố + 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 83
84. Review – Phân tích hệ thống theo cấu trúc • Phân tích yêu cầu theo pp cổ điển bao 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 (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ú ý bảo tồ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ệu 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 84
85. Phân tích hệ thống theo hướng phát triển 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 yêu cầu – mơ hình phân tích
86. Mơ hình nghiệp vụ - Thu thập yêu cầ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 • Lược đồ Use-case : – Actor & Use-case – Các mối quan hệ : Actor – Actor ; Actor-Use-case, - Use-case-Usecase • 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 ngồ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ích cực / Thụ động 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 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 ? – Hệ thống sẽ kiểm số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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 87
88. Biểu diễn ACTOR trong UML • Actor được biểu diễn bằng ký hiệu hình người Tên Actor • Actor được xem là một lớp (class) cĩ stereotype là > • Giữa các actor cĩ thể cĩ quan hệ tổng quá hố – 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íVí dụdụ:: mộtmột hệhệ thốngthống đăngđăng kýký mơnmơn họchọc trongtrong trườngtrường đạiđại họchọc 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 88
89. Các Actor trong hệ thống đăng ký mơn học Sinh viên Phịng đào tạo Hệ thống đăng ký mơn học Giả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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 89
90. Khái niệm Use-case • Use-case biểu diễn một chức năng của hệ thống phần mềm • Use-case được biểu diễn bằng một chuỗi các thơng điệp 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 hồn tất: chuỗi thơng điệp phải kết thúc bằng kết quả cụ thể. • Lỗi thường gặp: chia nhỏ use-case trở thành những chức năng vụn vặt 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 90
91. Khái niệm Use-case • Use-case được biểu diễn bằng hình ellipse: Tên Use-case • Điểm mở rộng là một vị trí trong use-case mà tại đĩ cĩ thể chèn chuỗi sự kiện của một use-case khác • Use-case cĩ thể chứa điều kiện rẽ nhánh, xử lý lỗi, ngoại lệ • Minh dụ của use-case là kịch bản (scenario): miêu tả cụ thể trình tự các sự kiện xảy ra khi Use-case được thực hiệ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 91
92. Tìm kiếm Use-case • 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, xố, 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 quản lý bằng giấy tờ nên được thay thế bằng hệ thống quản lý trên máy tính) ? 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 92
93. Các quan hệ của Use-case • Sau khi xác định các Actor và Use-case thì các quan hệ sẽ được thiết lập để hồn chỉnh lược đồ Use-case • Giữa use-case và actor thường cĩ quan hệ liên kết – 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 quát hố – 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 trường đại học 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 93
94. Ví dụ một Use-case đơn giản > Sinh Viên Quản lý Mơn Học Phịng Đào Tạo Đăng Ký Học Đăng ký dạy > Quản lý Sinh Viên Thêm Sinh Viên Mới Giảng Viê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 94
95. 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 mơn học • Một số tính chất liên quan – Tên của liên kế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 tên (một chiều) > > • Cĩ thể áp dụng stereotype: – > – > – > – 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 95
96. Quan hệ liên kết giữa Actor và Use-case • Liên kết là quan hệ duy hất giữa actor & Use-case • 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 • Quan hệ liên kết phổ biến giữa Actor & Use-case là giao tiếp: stereotype là > dùng liên kết giữa actor và use case mà nĩ kích hoạt 1 > * Đăng ký dạy Đặt hàng Người bán hàng Giảng viê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 96
97. Quan hệ gộp giữa 2 Use-case • Dùng để liên kết 2 Use-case: cĩ stereotype là > • Trong Use-case nguồn cĩ điểm mở rộng mà tại đĩ bắt buộc phải chèn Use-case đích 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 để 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 > Tìm kiếm Đăng nhập 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 97
98. Quan hệ mở rộng giữa 2 Use-case • Dùng để liên kết 2 Use-case: cĩ stereotype là > • Trong use-case nguồn cĩ một điểm mở rộng mà tại đĩ cĩ thể (hoặc khơng) chèn use-case đích vào tùy thuộc vào đ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úc use-case đích, diễn tiến của use-case nguồn lại tiếp tục > 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 98
99. Quan hệ tổng 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 chung của các đối tượng kia • Quan hệ thống quát hĩa giữa các Actor: nhiều actor cĩ chung một số vai trị -> hình than2h actor tổng quát hĩa 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 là trường hợp cụ thể một use-case trừu tượng – 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 trường hợp cụ thể của Use-case trừu trương LOGIN 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 99
100. Xây dựng mơ hình Use-case • Các yêu cầu của phần mềm được mơ tả trong mơ hình use-case • Mơ hình use-case bao gồm lược đồ use-case và (cĩ thể) một số packet (gom một số use-case thành một bộ chức năng con của hệ thống) • Phương pháp thực 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à > • Quan hệ mở rộng hay gộp giữa 2 use-case: quan hệ liên kết với stereotype > hay > • Quan hệ tổng quát hố (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ợp cụ thể của một 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 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 100
101. Xây dựng mơ hình Use-case – VÍ DỤ fee summary Prints timetable Makes timetable Student print request > Finance > timetable command Registers courses People Removes students Administration > Manages course > > Lecturer Reads courses > Manages lecturers > Adds students > > > Login Manages students Undertakes course 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 101
102. Xây dựng mơ hình Use-case – VÍ DỤ > Forwards Removes mailbox Subcriber > > > > Views mail Administrator Replies > > > > Adds mailbox Login 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 102
103. Xây dựng mơ hình Use-case – VÍ DỤ > models imports > initializes > model command import command run command > export command sets appearance exports > save command Viewer toggles light saves model > > close command toggles mode exits sets eye 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 103
104. Mơ hình phân tích – Phân tích yêu cầu • 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- Đố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 • 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 • Lược đồ Class phân tích diễn tả cấu trúc, mố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 trong ngữ cảnh của hệ thống • Nguyên tắc: mơ hình phân tích phải độc lập với o/s, ngơn ngữ lập trình, cơng cụ phát triể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 104
105. Xây dựng mơ hình phân tích • 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 – 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 hố (generalization) • Liên kết (association) • Bao gộp (aggregation) • Biểu diễn thành lược đồ lớp phân tích 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 105
106. Nhập diện đối tượng / lớp • Dựa vào đặc tả của từng use-case để tìm kiếm các đối 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 > < actor 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 106
107. Nhận diện và biểu diễn đối tượng / lớ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ượng điều khiển (control): điều khiển các đối tượng 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ụ • Cĩ thể áp dụng stereotype cho lớp: >, >, > • Đối tượng cũng được biểu diễn bằng hình chữ nhật, thơng thường gồm 2 phần: tên đối tượng + tên lớp (được 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 107
108. Biểu diễn lớp / đối tượng HTMLObject # alignment: int + GetAlignment( ): int + toHTML( ): String HTMLDocument doc : HTMLDocument alignment = MIDDLE - title: String title = “A document” + GetTitle( ): String + toHTML( ): String 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 108
109. Đối tượng / lớp thực thể • 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 ) • Trong UML, được gán stereotype > • Dễ nhận diện các thuộc tính của chúng Ví dụ: Message • Đố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 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 # 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 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 109
110. Đối tượng / lớp biên • Thực hiện chức năng giao tiếp với actor • Thường chứa các phần tử hoặc điều khiển giao diện người dùng (nút nhấn, hộp danh sách, tuỳ chọn, menu ) • Trong UML, được gán stereotype > • Khĩ nhận biết các thuộc tính và tác vụ trong mơ hình phân tích Ví dụ: MailView > •Đố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, StudentForm • Đối với hệ thống mail, nhận diện các đối tượng biên như: MailView, MailCompose 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 110
111. Đối tượng / lớp điều khiển • Cĩ nhiệm vụ điều khiển các lớp khác hoặc Command > • 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( ) > • 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 > > khác + Execute( ) + Execute( ) • Ví 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễ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 nhĩm danh từ liên quan đến đối tượng đang xét • Trả lời câu hỏi: những thành phần nào cấu thành đối tượng đang xét ? – 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 ngồi • 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ác 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 112
113. Xác định mức độ truy cập của thuộc tính • 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. • Thuộc tính nên được truy xuất thơng qua tác vụ get/set 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 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 - StudentInfo LecturerInfo Nhận diện các thuộc tính > > cho các đối tượng: - name: String StudentInfo, LecturerInfo - name: String - code: Long - code: String • Chú ý các mức độ truy - dateOfBirth: Date - dateOfBirth: String cập của các thuộc tính - addr: String - addr: String • Các tác vụ phát sinh - acaYear: Date - degree trong khi nhận diện các - department - title: String - division thuộc tính như Get/Set - home: String - socialAid - health - experience: Date + GetName( ): String + GetName( ): String + GetCode( ): Long + GetCode( ): String 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 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 > > • Nhận diện các thuộc tính cho các đối - courseName: String - acaYear: Date tượng: - courseCode: String - semester - offering: int CourseOffering, - session - credit: int Catalog - prerequisite 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 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ừ 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. • Xem xét mức độ truy xuất của tác vụ tương tự như đối với các thuộc tính; các tác vụ thường cĩ visibility là + hoặc # • 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ượng 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 116
117. Nhận diện lớp cơ sở • 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 hố (generalization) • Lớp cơ sở trừu tượng (khơng thể cụ thể hố tạo ra đối 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 117
118. Nhận diện lớp cơ sở (tt) • Đố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, 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ữa lớp cơ sở và các lớp cụ thể cĩ mối quan hệ thổng quát hĩa cĩ thể biểu diễn được trong UML 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 118
119. Biểu diễn lớp cơ sở và quan hệ tổng quát hĩa • UML định nghĩa quan hệ tổng quát hố 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ả thuộc tính, tác vụ và quan hệ của lớp kia + những thuộc tính/tác vụ riêng Isoquant của nĩ • Ký hiệu: mũi tên cĩ đầu là một tam giác nhỏ Fracture • Lớp tổng quát hơn nằm về phía mũi tê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 119
120. Ví dụ về nhận diện lớp cơ sở Ví dụ: • Trong hệ thống # 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 hố của StudentInfo StudentInfo LecturerInfo và LecturerInfo > > - acaYear: Date - degree - department - title: String - home: String - division - socialAid - health - experience: Date 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 120
121. Nhận diện các mối 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 hố (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ể hố (realization) 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 121
122. 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) – 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ết 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 122
123. Ví dụ - mối quan hệ liên kết Ví dụ: StudentInfo students has Registration > Lớp Registration > 40 80 - acaYear: Date liên kết với lớp - semester StudentInfo LecturerInfo 0 1 reg và lecturer CourseOffering offering LecturerInfo 0 1 > CourseOffering > 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 123
124. 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 – Hồn tồ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ớp 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 124
125. 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 CourseOffering Catalog > > * - acaYear: Date - semester • Cửa sổ giao diện bao gộp hồn tồn thanh cuộn và menu Menu Window ScrollBar 1 * 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 125
126. Xây dựng lược đồ lớ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à hồ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 hố – Xác định các quan hệ liên kết và bao gộp 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 126
127. Ví dụ một lược đồ lớ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 > > * - name: String - altitude: double + wrap( ): Region * fractures points Point2D MapCurve Fracture * - x: double > - ID: int - y: double - open: boolean 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 127
128. Thiết lập PACKAGE • 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 • 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 hố • 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ử bên trong package • UML cho phép biểu diễn các PACKAGE và các mối quan hệ PACKAGE 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 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 LecturerInfo # code: String - degree # dateOfBirth: Date - title: String # addr: String - division - health StudentInfo - experience: Date - acaYear: Date - department - home: String - socialAid 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 129
130. Tổng kết • Phân tích hệ thống cho OOP theo UML chia làm 2 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ơ hình phân tích • Mơ hình phân tích nhận diện các đối tượng/lớp: thực thể, biên, điều khiể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 ( mơ hình thiết kế) • UML hỗ trợ một số phần tử: lớp, đối tượng, lược đồ lớp, package 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 130
131. Thiết kế phần mềm (Software Design) oCƠ SỞ CỦA THIẾT KẾ PHẦN MỀM oGIAO DIỆN & TƯƠNG TÁC NGƯỜI DÙNG oPHƯƠNG PHÁP THIẾT KẾ CỔ ĐIỂN oPHƯƠNG PHÁP THIẾT KẾ OOP
132. Thiết kế phần mềm o Thiết kế phần mềm là cơng việc đầu tiên của giai đoạn phát triển o 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 đĩ o 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. 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 132
133. Trừu tượng hĩa Quá trình thiết kế trải qua nhiều mức trừu tượng hố khác nhau o Mức cao nhất: vấn đề cần thiết kế được mơ tả một cách tổng quát sử dụng thuật ngữ hướng vấn đề o 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 o Mức thấp nhất: vấn đề được mơ tả theo cách cĩ thể hiện thực trực tiếp o Phân loại trừu tượng hố: thủ tục và dữ liệu 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 133
134. Trừu tượng hĩa o Trừu tượng hố 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éo cánh cửa, đi vào ); thêm một phần tử vào danh sách cĩ thứ tự (xác định vị trí, chèn phần tử mới) o Trừu tượng hố 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 o Một số ngơn ngữ lập trình hỗ trợ kiểu ADT và template 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 134
135. Tinh chế o Tinh chế là quá trình làm rõ vấn đề o Tinh chế và trừu tượng hố 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 hố o Thiết kế phần mềm: trừu tượng hĩa rồi tinh chế hố. o Tại sao? 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 135
136. Thiết kế giao diện người dùng o Phần mềm cần cĩ giao diện thân thiện với người sử dụng o Một số tiêu chuẩn giao diện n Thời gian đáp ứng của hệ thống: giá trị trung bình và độ lệch n Phương tiện trợ giúp người sử dụng: tích hợp + add-on n Kiểm sốt thơng tin lỗi: hiện thị cả nguyên nhân lỗi và cách khắc phục n Đặt tên nhãn: ngắn gọn và gợi nhớ o Thường dùng các cơng cụ thiết kế giao diệ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 136
137. Cơng cụ thiết kế giao diện Cơng cụ thiết kế giao diện nên cĩ những tính năng sau o Quản lý thiết bị nhập (bàn phím, chuột) o Hiệu chỉnh thơng tin input o Kiểm sốt lỗi và hiển thị thơng báo lỗi o Cung cấp trợ giúp và hiển thị thơng báo nhắc nhở o Cung cấp feedback (ví dụ như tự động hiển thị ký tự đánh vào) o Kiểm sốt cửa sổ và vùng, khả năng cuộn o Thiết lập giao tiếp giữa chương trình với giao diện (vd: hàm đáp ứng) o Cách ly chương trình với các hàm quản lý giao diện o 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 137
138. Một số định hướng về thiết kế giao diện Một số hướng dẫn chung o Nên đồng nhất (menu, lệnh, hiển thị ) o Nên cung cấp feedback cho người dùng o Yêu cầu xác nhận những tác vụ mang tính phá hoại (xố file, account) o Nên hỗ trợ UNDO, REDO o Hạn chế lượng thơng tin phải ghi nhớ giữa 2 tác vụ liên tiếp o Tối ưu trong trình bày hộp thoại và di chuyển mouse o Chấp nhận lỗi từ phía người sử dụng o Cung cấp trợ giúp trực tuyến o Dùng động từ đơn giản và ngắn gọn để đặt tên các lệnh 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 138
139. Một số định hướng về thiết kế giao diện Đối với thơng tin hiển thị o Chỉ hiển thị những thơng tin phù hợp với ngữ cảnh hiện tại o Dùng tên, từ viết tắt và màu gợi nhớ o Cho phép tương tác trực quan o Tạo thơng báo lỗi cĩ ý nghĩa o Hiển thị dữ liệu ở nhiều dạng khác nhau trong cửa sổ o Thiết lập biểu diễn tương tự o Sử dụng khơng gian màn hình một cách tối ưu 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 139
140. Một số định hướng về thiết kế giao diện Đối với thơng tin input o Hạn chế input trực tiếp (cĩ thể chọn lựa từ một số dữ liệu cĩ sẵn) o Nên đồng nhất giữa thơng tin input và hiển thị o Nên cho phép tuỳ biến input o Cấm các chức năng khơng thích hợp trong ngữ cảnh hiện tại o Cho phép input ở nhiều dạng khác nhau o Để cho người sử dụng kiểm sốt dịng sự kiện tương tác o 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 140
141. Thiết kế phần mềm Phương pháp lập trình cấu trúc Module hố chương trình Phân chia module Kiến trúc phần mềm Thiết kế dữ liệu
142. Thiết kế phần mềm cổ điển o Các cơng đoạn trong thiết kế phần mềm cổ điển n Phân chia module n Thiết kế dữ liệu n Thiết kế kiến trúc n Thiết kế thủ tục n Thiết kế giao diện o Phần mềm phát triển theo mơ hình cổ điễn: quan tâm đến cấu trúc và giải thuật của các module 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 142
143. PHÂN CHIA MODULE o Module là gì? o Khái niệm module đã xuất hiện khoảng 4 thập niên trở lại đây. o Phần mềm được xây dựng bằng cách phân chia thành nhiều module, sau đĩ sẽ được tích hợp lại o Phân chia module làm cho việc quản lý phần mềm khoa học hơn o 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). o 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 143
144. Phân chia module như thế nào? o Số lượng module phụ thuộc vào độ Tổng cơng sức phát triển phức tạp của hệ thống ra phần mềm Vùng tối ưu bỏ cần xây dựng sức o Quá ít hoặc quá nhiều Cơng 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 144
145. Kiến trúc phần mềm o 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 đĩ o Thành phần cĩ thể là n Các module mã nguồn n Các file thực thi (*.dll, *.exe, *.class ) n Các thành phần của kiến trúc hệ thống: ActiveX control, bean n Các trang HTML, *.asp, *.jsp 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 145
146. Kiến trúc phần mềm- Sơ đồ phân cấp M o Sơ đồ Fan-out phân cấp được a b c dùng để Depth 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 Width 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 146
147. Phân chia module hiệu quả o Phân chia module là bắt buộc trong giai đoạn thiết kế o 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 o Tiêu chí quan trọng nhất: tính độc lập chức năng của các module o Tính độc lập chức năng được đo bằng 2 tiêu chuẩn: n Độ kết dính (cohesion) n Sự liên kết (coupling) 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 147
148. Độ kết dính o Độ 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 o Module cĩ độ kết dính cao nhất khi nĩ chỉ đảm nhận đúng một tác vụ kết dính chức năng o Thiết kế kiến trúc phần mềm: cố gắng tăng độ kết dính 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 148
149. Các mức độ kết dính Cĩ nhiều mức độ kết dính (từ thấp đến cao) o Ngẫu nhiên: các tác vụ khơng liên hệ với nhau o Luận lý: các tác vụ liên quan logic với nhau o Nhất thời: các tác vụ phải được thực thi trong một khoảng thời gian o Giao tiếp: các tác vụ cĩ sử dụng chung một dữ liệu nào đĩ 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 o Chức năng: chỉ cĩ một tác vụ 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 149
150. Sự liên kết o 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ơng số gọi thì sự liên kết càng cao o Thiết kế kiến trúc phần mềm: cố gắng giảm sự liên kết 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 150
151. Các mức độ liên kết Cĩ nhiều mức độ liên kết (từ cao đến thấp) o Liên kết nội dung: sử dụng dữ liệu và điều khiển của module khác o Liên kết chung: cĩ sử dụng chung dữ liệu tồn cục o Liên kết ngoại vi: module phụ thuộc vào một I/O nào đĩ o Liên kết điều khiển: thơng số truyền ảnh hưởng đến điều khiển o Liên kết stamp: truyền cấu trúc dữ liệu phức tạp o Liên kết dữ liệu: truyền các thơng số đơn giả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 151
152. Nguyên lý che dấu thơng tin o 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 o Các module giao tiếp với nhau bằng những thơng tin thật sự cần thiết o 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 o Lợi ích: kiểm sốt được thay đổi và sửa lỗi dễ dàng 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 152
153. Các Heuristic trong phân chia module o Sửa lại thiết kế ban đầu để tăng độ kết dính và giảm sự liên kết o Khi chiều sâu tăng, hạn chế fan-out trong khi sử dụng fan-in o 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ĩ o Loại bỏ dư thừa trong giao tiếp của các module o Ưu tiên các module tất định, hạn chế các module nhiều ràng buộc o Đĩ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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 153
154. Thiết kế dữ liệu o 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 o Thiết kế các cấu trúc dữ liệu của chương trình và cơ sở dữ liệu o Thực hiện tinh chế từng bước o Các tiêu chí thiết kế hệ cơ sở dữ liệu n Khơng dư thừa dữ liệu n Tối ưu hĩa khơng gian lưu trữ o Chuẩn hĩa cơ sở dữ liệu bằng lược đồ ERD và dạng chuẩn 3 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 154
155. Cấu trúc dữ liệu Cấu trúc dữ liệu là thiết kế cơ sở dữ liệu động tron hệ thống o Cấu trúc dữ liệu mơ tả sự tổ chức, phương thức truy xuất, mức độ liên kết và các xử lý khác của thơng tin o 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 o Một số dạng phức tạp hơn: vector, ma trận, mảng nhiều chiều, danh sách liên kết, hàng, chồng, cây nhị phân o Được biểu diễn ở các mức trừu tượng hố khác nhau 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 155
156. Mộ số nguyên tắc thiết kế dữ liệu o Một số nguyên tắc o Nhận diện cả cấu trúc dữ liệu và tác vụ truy xuất o Chú ý sử dụng từ điển dữ liệu o Trì hỗn thiết kế dữ liệu mức thấp cho đến cuối giai đoạn này o Che dấu biểu diễn bên trong của cấu trúc dữ liệu o 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 o Nên áp dung kiểu ADT trong thiết kế cũng như trong lập trình 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 156
157. Thiết kế kiến trúc o Mục tiêu là xây dựng sơ đồ phân cấp module từ DFD o Đặt nền mĩng để thiết kế chi tiết thủ tục và dữ liệu o Phân biệt dịng transform và dịng transaction trong DFD o Thực hiện ánh xạ cho từng vùng của DFD tuỳ theo nĩ là dịng transform hay transaction n 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 157
158. Dịng Transform o Dịng transform bao gồm 3 phần: dịng đi vào, dịng xử lý và dịng đi ra Dòng đi vào Dòng đi ra Dòng xử lý 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 158
159. Dịng Transaction Dịng đi vào o Dịng transaction bao gồm: dịng đi vào, T-center và các đường xử lý đầu ra T-center o 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 159
160. Thiết kế thủ tục o Thiết lập thuật giải cho các module đã kiến tạo sao cho cĩ thể dễ dàng mã hố bằng ngơn ngữ lập trình cĩ cấu trúc o Cĩ thể biểu diễn thuât giải bằng n Lưu đồ thuật giải: Flowchart n Ký hiệu dạng bảng n Ngơn ngữ PDL 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 160
161. Ngơn ngữ PDL o 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: o Cú pháp chặt chẽ của các từ khố hỗ trợ đặc tả cấu trúc, khai báo dữ liệu, phân chia module o Cú pháp tự do của ngơn ngữ tự nhiên giúp miêu tả xử lý o Phương tiện mơ tả dữ liệu đơn cũng như dữ liệu tổ hợp o Cơ chế định nghĩa chương trình con và phương cách gọi 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 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” end 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 162
163. Thiết kế phần mềm UML Lược đồ cộng tác Lược đồ tuần tự Lược đồ trạng thái các lớp/đối tượng Lược đồ hành động Hồn chỉnh lược đồ lớp
164. Giới thiệu o Giai đoạn thiết kế quan tâm đến “HOW”: n Thứ tự các thơng điệp trao đổi, thơng số của thơng điệp n Thuật giải của tác vụ đáp ứng n Cấu trúc dữ liệu cho các thuộc tính n Framework (console, document/view, 3-tier ) o Thiết kế cũng chịu ảnh hưởng từ: n Ngơ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 ? ) n 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 hố mơ hình tĩnh 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 164
165. Khái niệm mơ hình động o Lược đồ lớp chỉ mơ tả khía cạnh tĩnh của hệ thống o Hành vi của hệ thống được mơ tả bằng mơ hình động bao gồm n Tương tác giữa các đối tượng: cộng tác hay trình tự n Trạng thái của đối tượng/lớp n Quá trình hoạt động của lớp/đối tượng 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 165
166. Tương tác giữa các đối tượng o Đối tượng tương tác với nhau (interaction) bằng cách gửi/nhận kích thích (stimulus) o Actor cũng cĩ thể gửi kích thích đến đối tượng o 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 o Thơng điệp (message) là đặc tả của kích thích o Các loại thơng điệp n Đơn giản n Đồng bộ n Bất đồng bộ n Trả về của gọi hàm 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 166
167. Sự cộng tác – Lược đồ cộng tác o 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úng o 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 o 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 đĩ o Lược đồ cộng tác (collaboration diagram) được thiết lập để cụ thể hố một use-case hoặc một tác vụ 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 167
168. Lược đồ cộng tác o 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) o Mỗi cạnh liên kết 2 vai trị được biểu diễn bằng một đoạn thẳng o Tương tác được thể hiện bằng gửi/nhận thơng điệp o Hai vai trị liên kết với nhau khi cĩ trao đổi thơng điệp o 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 Nghệ Thơng Tin Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn 168
169. Lược đồ cộng tác (tt) o Các thơng điệp được đánh số theo kiểu phân cấp n 3.4.2 xảy ra sau 3.4.1 và cả hai được lồng (nested) trong 3.4 n 3.4.3a và 3.4.3b xảy ra đồng thời và được lồng trong 3.4 o Cú pháp tổng quát của thơng điệp precedessor guard-condition sequence-expression return- value := message-name argument-list o Ví dụ: 2/ 1.3.1: p := find(specs) 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 169
170. Lược đồ cộng tác (tt) o 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ượng cụ thể, các thơng điệp được trao đổi trên các đường liên kết Dạng đặc tả: mơ tả các lớp; các đường liên kết được ánh xạ vào các thơng điệp o Thiết lập lược đồ cộng tác giúp cụ thể hố (realize) các 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ích 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 170
171. Lược đồ cộng tác – Ví dụ l Ví dụ: lược đồ cộng tác mức cụ thể cho 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) : Database 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 171
172. Lược đồ cộng tác – ví dụ 2 2: register Ví dụ: lược đồ 1: submit(uname, psswd) : LoginForm cộng tác mức 1.2 [succ = true]: : Student welcome cụ thể cho use 3: submit(crsOffering) -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 : Database 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 172