Bài giảng Lập trình hướng đối tượng: Chương 9 - ĐH Bách Khoa Hà Nội

Chia sẻ: Elysale Elysale | Ngày: | Loại File: PDF | Số trang:13

Thêm vào BST

Báo xấu

26
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bài giảng Lập trình hướng đối tượng: Chương 9 Tổng quan về UML và phân tích thiết kế hướng đối tượng cung cấp cho người học những kiến thức như: Mô hình hóa; Tổng quan về UML; Phân tích thiết kế hướng đối tượng; Công cụ phát triển OOAD. Mời các bạn cùng tham khảo!

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Lập trình hướng đối tượng: Chương 9 - ĐH Bách Khoa Hà Nội

12/27/17 Nội dung Bộ môn Công nghệ Phần mềm Viện CNTT & TT Trường Đại học Bách Khoa Hà Nội 1. Mô hình hóa 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
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 thấp Mức độ quan trọng cao hơn 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
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) xác định rõ (đặc tả - Specifying) 3. Phân tích thiết kế hướng đối tượng n 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
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 rất nhiều ngôn ngữ lập trình. hóa về kiến trúc, Use Case Diagram Deployment Diagram ºÐ »ê È¯°æ ÀÇ Ç Ïµ å¿ þ¾ î¹× ³× Æ ® ¿ ÷À¸·ÎÀÇ Á¤º¸ ½ Ã½ ºÅÛ ¿ ¬ °á ¸ðµ ¨ - À© µ µ ¿ ì 95 : Å¬ ¶óÀÌ¾ ðÆ ® - À© µ µ ¿ ì N T : ÀÀ¿ ë¼ ¹ö - À¯´Ð ½ º ¸Ó½ Å: ÀÀ¿ ë ¼ ¹ö ¹× µ ¥ÀÌÅ¸ ¼ ¹ö, Åë½ Å ¼ ¹ö - IBM ¸ÞÀÎÇ Á·¹ÀÓ: µ ¥ÀÌÅ¸ ¼ ¹ö, Åë½ Å ¼ ¹ö yêu cầu, kiểm thử, W indow 95 W indow s95 Ánh xạ sang Java, C++, Visual Basic… Use Case 1 W indow s95 ¹® ¼ °ü¸® Å¬ ¶óÀÌ¾ ðÆ ® .EXE n ¹® ¼ °ü¸® ¾ ÖÇ Ã¸´ lập kế hoạch dự án, W indow s NT Actor A Actor B Use Case 2 Solaris ¹® ¼ °ü¸® ¿ £Áø .EXE Alpha Các bảng trong RDBMS hoặc kho lưu trữ trong U N IX ÀÀ¿ ë¼ ¹ö.EXE W indow s NT và quản lý việc bàn Use Case 3 IBM M ainfram e n µ ¥ÀÌÅ¸º£ÀÌ½ º¼ ¹ö OODBMS giao phần mềm user mainW nd fileMgr : F ileMgr document : D ocument gF ile repository F ileM gr D ocum entList add( ) D ocum ent nam e : int Cho phép các kỹ nghệ xuôi (chuyển UML thành fetchD oc( ) delete( ) docid : int sortByN am e( ) num F ield : int 1: D oc view request ( ) get( ) Æ ¯Á¤¹® ¼ ¿ ¡ ´ëÇ Ñ º¸±â¸¦ Các biểu đồ khác »ç¿ ëÀÚ °¡ ¿ äÃ»Ç Ñ ´Ù . read() fill the open( ) code.. close( ) n 2: fetchD oc( ) read( ) F ileList sortF ileList( ) fList create( ) 3: create ( ) n fillD ocum ent( ) add( ) delete( ) 1 4: create ( ) mã nguồn) 5: readD oc ( ) nhau, các ghi chú, ÈÀÏ°ü¸® ÀÚ ´Â ÀÐ ¾ î¿ Â 6: fillD ocum ent ( ) ¹® ¼ ÀÇ Á¤º¸¸¦ Ç Ø´ç ¹® ¼ °´Ã¼ ¿ ¡ ¼ ³Á¤À» ¿ äÃ»Ç Ñ ´Ù . rep 7: readF ile ( ) F ile R epository 8: fillF ile ( ) (from Persistence) read( ) GrpF ile È¸é °´Ã¼ ´Â ÀÐ ¾ îµ éÀÎ 9: sortByN am e ( ) nam e : char * = 0 °´Ã¼ µ é¿ ¡ ´ëÇ Ø ÀÌ¸§º°·Î Á¤·ÄÀ» ½ ÃÄÑ È¸é¿ ¡ read( ) º¸¿ © ÁØ´Ù . readD oc( ) open( ) readF ile( ) Cho phép kỹ nghệ ngược (xây dựng mô hình hệ create( ) fillF ile( ) n 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 OMT (Jim Rumbaugh): Analysis n Các ký pháp đồ họa khác nhau n 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
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 UML UML 1.1 n Lý tưởng: mô tả hệ thống trong 1 bản vẽ duy nhất à Bất khả thi (Sept. ‘97) Partners’ Expertise UML 1.0 (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 (June ‘96) (Oct. ‘96) cạnh khác nhau: chức năng, phi chức năng, các Unified Method 0.8 Public thức hoạt động Feedback à Hệ thống phải được miêu tả theo các (OOPSLA ’95) n Booch ’93 OMT - 2 hướng nhìn khác nhau OOSE Other Booch ‘91 OMT - 1 Methods 20 5
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ỉ rõ các thống dưới yêu góc thể của hệ thống. cầucủa nhìn chức năng người Logical View Implementation View của dùng Chỉ rahệhiệu thống năng, n Một mô hình hệ thống thường có nhiều loại biểu Analysts/Designers Programmers (các Mô tínhtả dịch co các dãnvụ núthệvật và đồ, mỗi loại có nhiều biểu đồ khác nhau. Structure Use-Case View Software management thống lý khác thông cần nhau lượng cung và của End-user cấp Mô các hệ tảcho việc kết thống người tổlẫn nối n Một biểu đồ là một thành phần của một hướng nhìn Functionality sử dụng) Process View Deployment View chức nhau các giữamô-đun chúng cụ thể phần cho cácmềm tĩnh cấu hình System integrators System engineering System topology, delivery, nhằm nền tảngchiađiển thành n 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ấtphâ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) n Biểu đồ lớp (Class Diagram) thống dưới dạng các use case. 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) n Biểu đồ hoạt động (Activity Diagram) ống (use case) và môi trường (actor) của nó. 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
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
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 vật lý trong hệ thố thành phần phần mềm: mã nguồn, mã nhị 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
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 mềm phát triển bởi phương pháp 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 phát triển cho UML trực quan của 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 n Hệ thống thống tin (Information System) 1. Mô hình hóa 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) n Phần mềm hệ thống (System Software) 4. Công cụ phát triển OOAD 35 36 9
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 Cho rằng phần mềm chủ yếu được xây dựng bằng cách n 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ì n Không hiểu hoặc hiểu sai yêu cầu giữa các thành viên trong nhóm phát triển 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
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 sequence design between objects structure using E-R diagram n Mô hình hóa các thực thể, giữ nguyên cấu 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 Người bán hàng n n Thiết kế trên kết quả của OOA n Phiếu đặt hàng n Phiếu (hoá đơn) thanh toán n Cải thiện, tối ưu hóa thêm n Xe ô tô n Thiết kế các n Tương tác và quan hệ giữa các thực thể trên : n Phương thức (operations) n Người bán hàng dẫn khách hàng tham quan phòng trưng bày xe. n Thuộc tính (attributes) n Khách hàng chọn một chiếc xe n Mối quan hệ giữa các lớp (classes) 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/27/17 Thiết kế biểu đồ lớp Thiết kế đối tượng (1/2) Mục tiêu: cần xác định các thành viên của mỗi lớp và n 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 2. Trách nhiệm của lớp: lớp có thể làm gì. Thông thường các n 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 để 3. Tương tác của lớp: lớp này có thể tương tác được với n 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 triển và hoàn thiện lớp trong quá trình giải quyết bài đoạn này chúng ta phát triển các đối tượng, xem xét các 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 Bước 5. Tái sử dụng đối tượng (Object reuse). Đây là một n 3. Việc phát hiện ra các lớp cần thiết cho chương 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
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