Bài giảng Lập trình hướng đối tượng - Chương 9: Tổng quan về UML và PTTK HĐT

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 
 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
 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
 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
 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 
 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
 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
 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
 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/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
 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