Bài giảng Lập trình hướng đối tượng - Bài 9: Tổng quan về UML và phân tích thiết kế hướng đối tượng

Nội dung text: Bài giảng Lập trình hướng đối tượng - Bài 9: Tổng quan về UML và phân tích thiết kế hướng đối tượng

1. 12/27/17 Nội dung Bộ môn Công nghệ Phần mềm Viện CNTT & TT 1. Mô hình hóa Trường Đại học Bách Khoa Hà Nội 2. Tổng quan về UML LẬP TRÌNH HƯỚNG ĐỐI TƯỢNG 3. Phân tích thiết kế hướng đối tượng Bài 09. Tổng quan về UML và PTTK 4. Công cụ phát triển OOAD HĐT 2 Nội dung 1.1 Mô hình hóa là gì? n Giúp đơn giản hóa thế giới thực bằng các mô hình n Giúp hiểu rõ hơn về hệ thống dưới một góc nhìn 1. Mô hình hóa nào đó 2. Tổng quan về UML 3. Phân tích thiết kế hướng đối tượng 4. Công cụ phát triển OOAD 3 4 1
2. 12/27/17 1.2. Sự quan trọng của mô hình hóa 1.2. Sự quan trọng của mô hình hóa (2) n Rất nhiều đội dự án tiến hành xây dựng ứng dụng theo hướng tiếp cận của việc gấp máy Mức độ quan trọng cao hơn Mức độ quan trọng thấp bay giấy. n Bắt đầu lập trình ngay khi có được yêu cầu. n Mất rất nhiều thời gian và tạo ra rất nhiều mã nguồn. n Không có bất kỳ một kiến trúc nào. n Phải chịu khổ với những lỗi phát sinh. Máy bay giấy Máy bay phản lực n Mô hình hóa là một con đường dẫn đến thành công của dự án. 6 1.3. Vai trò của mô hình hóa hệ thống 1.4. Yêu cầu khi biểu diễn mô hình n Hình dung một hệ thống theo thực tế hay n Chính xác (accurate): Mô tả đúng hệ thống theo mong muốn của chúng ta . cần xây dựng. n Chỉ rõ cấu trúc hoặc ứng xử của hệ thống. n Đồng nhất (consistent): Các view khác nhau n Tạo một khuôn mẫu hướng dẫn nhà phát không được mâu thuẩn với nhau. triển trong suốt quá trình xây dựng hệ thống. n Có thể hiểu được (understandable): Cho n Ghi lại các quyết định của nhà phát triển để những người xây dựng lẫn sử dụng sử dụng sau này n Dễ thay đổi (changeable) n Dễ dàng liên lạc với các mô hình khác. 7 8 2
3. 12/27/17 Nội dung 2.1. UML là gì? n Ngôn ngữ mô hình hóa thống nhất UML (Unified Modeling Language) 1. Mô hình hóa n UML là ngôn ngữ để: 2. Tổng quan về UML n trực quan hóa (visualizing) n xác định rõ (đặc tả - Specifying) 3. Phân tích thiết kế hướng đối tượng n xây dựng (constructing) 4. Công cụ phát triển OOAD n tài liệu hóa (documenting) các cấu phần (artifact) của một hệ thống phần mềm 9 10 UML là ngôn ngữ trực quan UML là ngôn ngữ để đặc tả n UML là ngôn ngữ thống nhất trực n UML xây dựng các mô hình chính xác, rõ quan giúp công việc được xử lý nhất ràng và đầy đủ. quán, giảm thiểu lỗi xảy ra n Có những thứ mà nếu không mô hình hóa thì không hoặc khó có thể hiểu được n Mô hình trợ giúp hiệu quả trong việc liên lạc, trao đổi n Trong tổ chức n Bên ngoài tổ chức 3
4. 12/27/17 UML là ngôn ngữ để xây dựng HT UML là ngôn ngữ để tài liệu hóa n Các mô hình UML có thể kết nối trực tiếp với n UML giúp tài liệu Use Case Deployment Diagram ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ - À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼¹ö Diagram - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼¹ö ¹× µ¥ÀÌŸ ¼¹ö, Åë½Å ¼¹ö rất nhiều ngôn ngữ lập trình. hóa về kiến trúc, - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼ ¹ö, Åë½Å ¼¹ö Windows95 Window95 Use Case 1 Windows95 ¹®¼°ü¸® Ŭ¶óÀ̾ðÆ®.EXE yêu cầu, kiểm thử, ¹®¼°ü¸® ¾ ÖÇø´ Windows NT Actor A Actor B n Ánh xạ sang Java, C++, Visual Basic Use Case 2 Solaris ¹®¼°ü¸® ¿£Áø.EXE Alpha UNIX ÀÀ¿ë¼¹ö.EXE Windows lập kế hoạch dự án, NT IBM Use Case 3 Mainframe n Các bảng trong RDBMS hoặc kho lưu trữ trong và quản lý việc bàn µ¥ÀÌŸº£À̽º¼¹ö DocumentList OODBMS mainWnd fileMgr : document : gFile repository Document FileMgr FileMgr Document user add( ) nam e : int fetchDoc( ) delete( ) giao phần mềm docid : int sortByName( ) num Field : int get( ) ƯÁ¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦ 1: Doc view request ( ) read() fill the »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù. open( ) code close( ) 2: fetchDoc( ) read( ) FileList sortFileList( ) fList create( ) 3: create ( ) fillDocum ent( ) add( ) delete( ) 1 n Cho phép các kỹ nghệ xuôi (chuyển UML thành 4: create ( ) n Các biểu đồ khác 5: readDoc ( ) ÈÀÏ°ü¸®ÀÚ´Â Àоî¿Â 6: fillDocum ent ( ) ¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù. rep 7: readFile ( ) File Repository 8: fillFile ( ) (from Persistence) read( ) GrpFile mã nguồn) È¸é °´Ã¼´Â ÀоîµéÀÎ 9: sortByNam e ( ) nam e : char * = 0 °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡ read( ) º¸¿©ÁØ´Ù. readDoc( ) open( ) readFile( ) nhau, các ghi chú, create( ) fillFile( ) n Cho phép kỹ nghệ ngược (xây dựng mô hình hệ ràng buộc được đặc Sequence Diagram Class Diagram thống từ mã nguồn) tả trong tài liệu 2.2. Lịch sử phát triển của UML 2.2. Lịch sử phát triển của UML (2) n Vào 1994, có hơn 50 phương pháp mô hình hóa hướng đối n UML được 3 chuyên gia hướng đối tượng: tượng hợp nhất các kỹ thuật của họ n Fusion, Shlaer-Mellor, ROOM, Class-Relation,Wirfs-Brock, Coad- vào năm 1994: Yourdon, MOSES, Syntropy, BOOM, OOSD, OSA, BON, Catalysis, n Booch91 (Grady Booch): Conception, COMMA, HOOD, Ooram, DOORS Architecture n “Meta-models” tương đồng với nhau n OOSE (Ivar Jacobson): Use cases n OMT (Jim Rumbaugh): Analysis n Các ký pháp đồ họa khác nhau n Thiết lập một phương thức thống n Quy trình khác nhau hoặc không rõ ràng nhất để xây dựng và “vẽ” ra các à Cần chuẩn hóa và thống nhất các phương pháp yêu cầu và thiết kế hướng đối tượng trong quá trình PTTK phần mềm à UML được công nhận là chuẩn chung vào năm 1997. 4
5. 12/27/17 UML là một ngôn ngữ hợp nhất UML là một ngôn ngữ thống nhất Rumbaugh Booch Jacobson Meyer Fusion Before and after Operation descriptions, conditions message numbering Harel Embley State charts Singleton classes, High-level view Gamma, et.al Wirfs-Brock Frameworks, patterns, Responsibilities notes Shlaer- Mellor Selic, Gullekson, Ward Odell Object lifecycles ROOM (Real-Time Classification Object-Oriented Modeling) 2.2. Lịch sử phát triển của UML (3) 2.3. Các khung nhìn của UML UML 2.0 (2004) n Không đơn giản để mô hình hóa hệ thống UML 1.5 (March, ‘03) phức tạp n Lý tưởng: mô tả hệ thống trong 1 bản vẽ duy UML UML 1.1 (Sept. ‘97) Partners’ nhất à Bất khả thi UML 1.0 Expertise (Jan. ‘97) n Một hệ thống cần được miêu tả trên các khía UML 0.9 and UML 0.91 cạnh khác nhau: chức năng, phi chức năng, các (June ‘96) (Oct. ‘96) Public thức hoạt động Unified Method 0.8 (OOPSLA ’95) Feedback n à Hệ thống phải được miêu tả theo các Booch ’93 OMT - 2 hướng nhìn khác nhau OOSE Other Booch ‘91 OMT - 1 Methods 20 5
6. 12/27/17 2.3. Các khung nhìn của UML (2) 2.4. Các biểu đồ UML n Khung nhìn của mô hình có ý nghĩa với những n Biểu đồ: người tham gia nào đó Biểu diễn các chức n là các hình vẽ bao gồm các ký hiệu phần tử mô hình hóa năng và môi n 4 + 1 Architectural View trường dự kiến của n minh họa một thành phần cụ thể hay một khía cạnh cụ hệChỉ thống rõ các dưới yêu góc thể của hệ thống. cầu chức năng Logical View Implementation View nhìn của người n Một mô hình hệ thống thường có nhiều loại biểu dùngChỉcủa rahệ hiệu thống năng, Analysts/Designers Programmers (các dịch vụ hệ Structure Software management tínhMô tảco các dãn nút và vật đồ, mỗi loại có nhiều biểu đồ khác nhau. thống cần cung Use-Case View thônglý khác lượng nhau củavà End-user cấp cho người n Một biểu đồ là một thành phần của một hướng nhìn Functionality Môhệcác tảthống kết việc nối tổ lẫn chứcnhausử dụng) các giữa mô chúng-đun cụ thể Process View Deployment View phầncho cácmềm cấu tĩnh hình System engineering n System integrators System topology, delivery, nhằmnền tảng chia điển thành Một số loại biểu đồ có thể là thành phần của nhiều Performance, scalability, throughput installation, communication package,hình nhất phân hướng nhìn khác nhau lớp và quản lý cấu hình 22 2.4. Các biểu đồ UML a. Biểu đồ use case n Biểu đồ use case (Use Case Diagram) n Biểu đồ mô tả các yêu cầu chức năng của hệ n Biểu đồ cấu trúc tĩnh (Static Structure Diagrams) thống dưới dạng các use case. n Biểu đồ lớp (Class Diagram) n Biểu đồ đối tượng (Object Diagram) n Bao gồm các chức năng mong đợi của hệ th n Biểu đồ trạng thái (Statechart Diagram) ống (use case) và môi trường (actor) của nó. n Biểu đồ hoạt động (Activity Diagram) n Biểu đồ tương tác (Interaction Diagrams) n Biểu đồ trình tự (Sequence Diagram) n Biểu đồ giao tiếp/cộng tác (Communication/Collaboration Diagram) n Biểu đồ thực thi (Implementation Diagrams) n Biểu đồ thành phần (Component Diagram) n Biểu đồ triển khai (Deployment Diagram) 24 6
7. 12/27/17 b. Biểu đồ lớp (Class Diagram) c. Biểu đồ đối tượng n Chỉ ra: n Chỉ ra một loạt các đối tượng thực thể của n cấu trúc tĩnh của các lớp trong hệ thống lớp n và các mối quan hệ giữa chúng n Là 1 ví dụ, bổ sung giải thích thêm cho biểu đồ lớp 25 26 d. Biểu đồ trạng thái (State Diagram) e. Biểu đồ hoạt động (Activity Diagram) n Chỉ ra: n Chỉ ra một trình tự n tất cả các trạng thái mà đối tượng của 1 lớp có thể có lần lượt của các hoạt n và những sự kiện (event) nào sẽ gây ra sự thay đổi trạng động trong 1 tiến thái trình xử lý n Ví dụ các trạng thái n Gồm các trạng thái của 1 server: hành động n Một trạng thái hành động sẽ qua đi khi hành động được thực hiện xong 27 28 7
8. 12/27/17 g. Biểu đồ cộng tác (Collaboration f. Biểu đồ trình tự (Sequence Diagram) Diagram) n Chỉ ra một cộng tác động giữa một loạt các n Chỉ ra một sự cộng tác động đối tượng n Giống biểu đồ trình tự (Thường chỉ chọn 1 n Nhấn mạnh trình tự & thời gian các thông trong 2) điệp (message) được gửi giữa các đối n Ưu tiên ngữ cảnh: dùng biểu đồ cộng tác tượng n Ưu tiên thời gian, trình tự: dùng biểu đồ trình tự 29 30 h. Biểu đồ thành phần i. Biểu đồ triển khai (Deployment (Component Diagram) Diagram) n Biểu diễn sự tổ chức và phụ thuộc giữa các n Mô tả các tài nguyên thành phần phần mềm: mã nguồn, mã nhị vật lý trong hệ thố ng, bao gồm các nút phân (binary code) và những thành phần có (node), thành phần v khả năng thực thi à kết nối. n Mỗi mô hình chỉ bao gồm một deployment diagram hiển thị ánh xạ giữa những tiến tr ình xử lý tới thiết bị phần cứng 31 32 8
9. 12/27/17 2.5. Quy trình và UML 2.5. Quy trình và UML (2) n UML là ký pháp n RUP là quy trình chứ không phải là công nghệ phần phương pháp mềm phát triển bởi hãng Rational n UML có thể áp dụng cho tất cả các pha n Là quy trình lặp và của quy trình phát tăng trưởng từng triển phần mềm bước n "Rational Unified n Sử dụng các ký hiệu Process" - quy trình trực quan của UML phát triển cho UML n Phát triển song song với UML 2.6. Ứng dụng của UML trong phân tích thiết kế hệ thống Nội dung n UML được sử dụng để phân tích nhiều loại hệ thống 1. Mô hình hóa n Hệ thống thống tin (Information System) n Hệ thống kỹ thuật (Technical System) 2. Tổng quan về UML n Hệ thống nhúng (Embeded System) 3. Phân tích thiết kế hướng đối n Hệ thống phân tán ( Distributed System) tượng n Hệ thống nghiệp vụ (Business System) 4. Công cụ phát triển OOAD n Phần mềm hệ thống (System Software) 35 36 9
10. 12/27/17 3.1. Tầm quan trọng của OOAD 3.1. Tầm quan trọng của OOAD (2) n Nhiều người phát triển dự án n Cần thiết lập một cơ chế hiệu quả để nắm n Cho rằng phần mềm chủ yếu được xây dựng bằng cách gõ “code” từ bàn phím bắt yêu cầu, phân tích thiết kế n Không dành đủ thời gian cho quá trình phân tích và thiết n Cơ chế này phải như là một “ngôn ngữ thống kế phần mềm nhất” giúp cho quá trình hợp tác hiệu quả n à Họ phải “cày bừa” để hoàn thành chương trình vì giữa các thành viên trong nhóm phát triển n Không hiểu hoặc hiểu sai yêu cầu n Giao tiếp với các thành viên không tốt phần mềm. n Không tích hợp được với module của đồng nghiệp n à OOAD n à Họ nhận ra rằng “Phân tích” và “Thiết kế” cần được coi trọng hơn, nhưng đã quá muộn 37 38 3.2. Mục đích của OOAD 3.3. Phương pháp OOAD n Chuyển các yêu cầu của bài toán thành một bản n OOAD được chia thành 2 giai đoạn thiết kế của hệ thống sẽ được xây dựng n Phân tích hướng đối tượng (OOA) n Tập trung vào quá trình phân tích các YÊU CẦU của n Thiết kế hướng đối tượng (OOD) hệ thống và thiết kế các MÔ HÌNH cho hệ thống đó n OOA là giai đoạn nhằm tạo ra các mô hình cơ trước giai đoạn lập trình bản (mô hình khái niệm) của hệ thống dựa n Được thực hiện nhằm đảm bảo mục đích và yêu theo những gì khách hàng yêu cầu về hệ cầu của hệ thống được ghi lại một cách hợp lý thống của họ trước khi hệ thống được xây dựng n OOD sẽ bổ sung thêm các thông tin thiết kế n Cung cấp cho người dùng, khách hàng, kỹ sư phân chi tiết cho các mô hình nói trên tích, thiết kế nhiều cái nhìn khác nhau về cùng một hệ thống 39 40 10
11. 12/27/17 3.3. Phương pháp OOAD (2) 3.3.1. OOA 1. Use case modeling to define 6. External Specification Design n Tạo được mô hình có các thành phần là đối requirements tượng và khái niệm đời thực, dễ hiểu với người dùng 5. Normalization of the data 2. Object extraction and message n Mô hình hóa các thực thể, giữ nguyên cấu sequence design between objects structure using E-R diagram trúc, quan hệ, hành vi giữa chúng 3. Class design 4. E-R modeling for persistent data 41 42 3.3.1. OOA (2) 3.3.2. OOD n Ví dụ với 1 phòng bán ô tô: n Tổ chức chương trình thành các tập hợp đối tượng n Các thực thể: cộng tác n Khách hàng n Mỗi đối tượng là thực thể của một lớp n Người bán hàng n Thiết kế trên kết quả của OOA n Phiếu đặt hàng n Cải thiện, tối ưu hóa thêm n Phiếu (hoá đơn) thanh toán n Xe ô tô n Thiết kế các n Phương thức (operations) n Tương tác và quan hệ giữa các thực thể trên : n Thuộc tính (attributes) n Người bán hàng dẫn khách hàng tham quan phòng trưng bày xe. n Mối quan hệ giữa các lớp (classes) n Khách hàng chọn một chiếc xe n Khách hàng viết phiếu đặt xe n Đưa ra các biểu đồ tĩnh và động n Khách hàng trả tiền xe n Tĩnh: biểu thị các lớp và đối tượng n Xe ô tô được giao đến cho khách hàng n Động: biểu thị tương tác giữa các lớp & phương thức hoạt động 43 44 11
12. 12/27/17 Thiết kế biểu đồ lớp Thiết kế đối tượng (1/2) n Mục tiêu: cần xác định các thành viên của mỗi lớp và quan hệ giữa các lớp n Trong PT&TK hướng đối tượng người ta đã n Một trong các kỹ thuật được ứng dụng nhiều nhất là Thẻ tổng kết 5 bước để thiết kế đối tượng: Class-Responsibility-Collaboration (CRC) card. n Bước 1. Phát hiện đối tượng (Object discovery). n Mỗi thẻ thể hiện một lớp, trên thẻ chúng ta lưu lại các thông tin sau về các lớp: Bước này được thực hiện ở giai đoạn phân tích n 1. Tên của lớp. Thông thường người ta đặt tên lớp liên quan chương trình. đến vai trò của lớp, chúng ta sẽ sử dụng lớp để làm gì. n n 2. Trách nhiệm của lớp: lớp có thể làm gì. Thông thường các Bước 2. Lắp ráp đối tượng (Object assembly). thông tin ở đây bao gồm tên của các hàm thành phần Bước tìm kiếm các đặc điểm của đối tượng để n 3. Tương tác của lớp: lớp này có thể tương tác được với những lớp nào khác thêm vào các thuộc tính, các hàm thành phần cho đối tượng 45 46 Thiết kế đối tượng (2/2) Lưu ý (1/2) n Trong PT&TK hướng đối tượng người ta đã tổng kết 5 n Một số điểm lưu ý khi phát triển các lớp bước để thiết kế đối tượng: n 1. Cần tạo ra lớp trước, sau đó mới nghĩ tới việc phát n Bước 3. Xây dựng hệ thống (System construction). Trong giai đoạn này chúng ta phát triển các đối tượng, xem xét các triển và hoàn thiện lớp trong quá trình giải quyết bài tương tác giữa các đối tượng để hình thành hệ thống hoạt toán động. n 2. Khi phân tích hay phát triển các lớp không nên tập n Bước 4. Mở rộng hệ thống (System extension). Khi chúng ta trung xác định tất cả thành viên một lớp, chúng ta sẽ thêm vào các tính năng của hệ thống, cần thêm các lớp mới, biết rõ hơn khi phát triển hệ thống (learns as you các đối tượng mới và các tương tác giữa các đối tượng này với go) các đối tượng đã có trong hệ thống. n 3. Việc phát hiện ra các lớp cần thiết cho chương n Bước 5. Tái sử dụng đối tượng (Object reuse). Đây là một trong những thử nghiệm quan trọng của các đối tượng và lớp trình là một trong những nhiệm vụ chính của thiết kế trong thiết kế phần mềm. Chúng ta cần phải sử dụng lại các hệ thống, nếu chúng ta đã có những lớp này (trong lớp và các đối tượng trong phần mềm (thông qua tính kế thừa một thư viện lớp nào đó chẳng hạn) thì công việc sẽ và tương tác giữa các đối tượng) dễ dàng hơn 47 48 12
13. 12/27/17 Lưu ý (2/2) Nội dung n Một số điểm lưu ý khi phát triển các lớp n 4. Khi lập trình cần tuân thủ theo các thiết kế đã làm. Không nên băn khoăn khi không sử dụng 1. Mô hình hóa phương pháp lập trình truyền thống và thấy choáng ngợp trước số lượng lớn các đối tượng. 2. Tổng quan về UML n 5. Luôn giữ nguyên tắc: mọi vấn đề cần giải quyết 3. Phân tích thiết kế hướng đối tượng theo phương án đơn giản nhất, không phức tạp hóa. Sử dụng nguyên lý của Occam Razor: Lớp đơn giản 4. Công cụ phát triển OOAD nhất bao giờ cũng là lớp tốt nhất, hãy bắt đầu bằng những cái đơn giản và chúng ta sẽ kết thúc bằng những hệ thống phức tạp 49 50 4. Công cụ UML – OOAD n Công cụ mã nguồn mở: n EclipseUML n UmlDesigner n ArgoUML n Công cụ thương mại: n Enterprise Architect n IBM Rational Software Architect n Microsoft Visio n Visual Paradigm for UML n SmartDraw 51 13