Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 2: Khái quát về UML - Đào Nam Anh

PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG OBJECT ORIENTED ANALYSIS AND DESIGN DR. DAO NAM ANH Bài giảng 2: KHÁI QUÁT VỀ UML 1 RESOURCE - REFERENCE 1. Ian Sommerville, Software Engineering, Ninth Edition, 2011 2. Bernd Bruegge & Allen H. Dutoit. Object-Oriented Software Engineering: Using UML, Patterns, and Java, Third Edition, Prentice Hall, 2010 3. Russell C. Bjork, ATM Simulation Links, Gordon College 4. Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado, UML 2 Toolkit, John Wiley & Sons Inc, 2003 5. Dương Kiều Hoa – Tôn Thất Hoà An, Phân tích và thiết kế Hệ thống thông tin với UML, 2006 6. Đào Nam Anh, Giáo Trình Phân Tích Và Thiết Kế Hướng Đối Tượng, Đại học Điện lực, 2013 2 CONTENT – NỘI DUNG Phương pháp hướng đối tượng và quá trình phát triển hệ thống phần mềm 1. Giới thiệu về hệ thống phần mềm 2. Sự phát triển hệ thống 3. Các cách tiếp cận trong phát triển phần mềm 4. Quá trình phát triển phần mềm hợp nhất 3 Ký hiệu (notation)  Ký hiệu (notation) cho phép thể hiện ý tưởng phức tạp một cách ngắn gọn và chính xác.  Trong các dự án liên quan đến nhiều người tham gia, có kiến thức, kỹ thuật và văn hóa khác nhau, trao đổi thông tin có nguy cơ bị hiểu sai lệch, nên sự chính xác và rõ ràng là rất cần thiết. 4 Ký hiệu (notation)  Để một ký hiệu có thể dùng chính xác trong trao đổi thông tin, ký hiệu đó phải có một ngữ nghĩa xác định, phải là đại diện thích hợp cho một khía cạnh nhất định của hệ thống, và nó phải được hiểu rõ với tất các thành viên tham gia dự án.  Khi một ký hiệu trở thành chuẩn mực, được sử dụng bởi một số lượng lớn người tham gia, thì khả năng hiểu sai và mơ hồ là rất ít.  Ngược lại, khi có nhiều ký hiệu có cùng nghĩa, hoặc khi có một ký hiệu rất đặc biệt, người sử dụng dễ hiểu lầm vì mỗi người có cách giải thích riêng của mình. 5 Unified Modeling Language  UML (ngôn ngữ mô hình hóa thống nhất, Unified Modeling Language) cung cấp một dải các ký hiệu đại diện cho các khía cạnh khác nhau của một hệ thống và đã được chấp nhận là một ký hiệu tiêu chuẩn trong công nghiệp. 6 Lịch sử hình thành UML Kết quả của sự thống nhất của  OMT (Object Modeling Technique), Rumbaugh và cộng sự năm 1991,  Booch năm 1994, và  OOSE (Object-Oriented Software Engineering) Jacobson và cộng sự năm 1992.  UML cũng đã bị ảnh hưởng bởi các ký hiệu theo định hướng đối tượng khác, chẳng hạn như Mellor và Shlaer năm 1998, Coad và Yourdon năm 1995,  Wirfs Brock năm 1990, Martin và Odell năm 1992. 7 Lịch sử hình thành UML 8 Unifield Modeling Language - UML  UML là một ngôn ngữ mô hình hóa thống nhất có phần chính bao gồm những ký hiệu hình học, được các phương pháp hướng đối tượng sử dụng để thể hiện và miêu tả các thiết kế của hệ thống.  Đó là một ngôn ngữ để đặc tả, trực quan hoá, xây dựng và làm tư liệu cho nhiều khía cạnh khác nhau của một hệ thống.  UML có thể được sử dụng làm công cụ giao tiếp giữa người dùng, nhà phân tích, thiết kế viên và lập trình viên. 9 Unifield Modeling Language - UML  UML cung cấp hệ thống ký hiệu chuẩn có thể được sử dụng bởi tất cả các phương pháp hướng đối tượng và để lựa chọn và tích hợp các yếu tố tốt nhất của từ các ký hiệu trước đó.  Ví dụ, UML có các biểu đồ Use Case của OOSE và sử dụng nhiều tính năng của các biểu đồ lớp của OMT.  UML cũng bao gồm các khái niệm mới không được trình bày trong các phương pháp khác tại thời điểm đó, chẳng hạn như cơ chế mở rộng và một ngôn ngữ các hạn chế. 10 UML - ngôn ngữ mô hình  UML sử dụng các mô hình để xác định các yêu cầu của người dùng đối với hệ thống và qua đó giúp chúng ta đánh giá tính khả thi của dự án.  Tầm quan trọng của mô hình đã được lĩnh hội một cách thấu đáo trong hầu như tất cả các ngành khoa học kỹ thuật từ nhiều thế kỷ.  Khi muốn xây dựng một vật thể nào đó, đầu tiên cần tạo ra các bản vẽ để quyết định cả hình thức và phương thức hoạt động của nó.  Mô hình nhìn chung là một cách mô tả vật thể. Vật thể đó có thể tồn tại trong một số giai đoạn nhất định, như giai đoạn thiết kế hay giai đoạn xây dựng hoặc chỉ là có trong kế hoạch.  Thiết kế viên cần phải tạo ra các mô hình mô tả tất cả các khía cạnh khác nhau của sản phẩm.  Ngoài ra, một mô hình có thể có nhiều hướng nhìn, mỗi hướng nhìn sẽ mô tả một khía cạnh riêng biệt của sản phẩm hay hệ thống cần được xây dựng.  Một mô hình cũng có thể được xây dựng trong nhiều giai đoạn và ở mỗi giai đoạn, mô hình sẽ được bổ sung thêm một số chi tiết nhất định. 11 UML - ngôn ngữ mô hình Mô hình đảm bảo các yếu tố:  Chính xác (accurate): Mô tả chính xác hệ thống cần xây dựng,  Đồng nhất (consistent): Các mô hình, hướng nhìn khác nhau không được mâu thuẩn với nhau,  Có thể hiểu được (understandable): Dễ hiểu cho những người tham gia phát triển,  Dễ thay đổi (changeable),  Dễ dàng kết nối với các mô hình khác. 12 UML - ngôn ngữ mô hình Mô hình hóa một hệ thống nhằm mục đích:  Hình dung một hệ thống theo thực tế hay theo mong muốn,  Chỉ rõ cấu trúc hoặc cách ứng xử của hệ thống,  Tạo một khuôn mẫu hướng dẫn nhà phát triển trong suốt quá trình xây dựng hệ thống,  Ghi lại các quyết định của nhà phát triển để sử dụng về sau. UML chính là một ngôn ngữ mô hình. 13 Lĩnh vực ứng dụng UML  Hệ thống thống tin (Information system): Cất giữ, lấy, biến đổi biểu diễn thông tin cho người sử dụng. Xử lý dữ liệu lớn có các quan hệ phức tạp, được lưu trữ trong các cơ sở dữ liệu quan hệ hay hướng đối tượng .  Hệ thống kỹ thuật (Technical system): Xử lý và điều khiển các thiết bị kỹ thuật như viễn thông, hệ thống quân sự, hay các quy trình công nghiệp. Đây là loại thiết bị xử lý các giao tiếp đặc biệt, không có phần mềm chuẩn và thường là các hệ thống thời gian thực (real time).  Hệ thống nhúng (Embeded system): Thực hiện trên phần cứng gắn vào các thiết bị như điện thoại di động, điều khiển xe hơi. Điều này được thực hiện bằng lập trình mức thấp với hỗ trợ thời gian thực. Những hệ thống này thường không có các thiết bị như màn hình đĩa cứng. 14 Lĩnh vực ứng dụng UML  Hệ thống phân tán (Distributed system): Được phân bố trên một số máy cho phép truyền dữ liệu từ nơi này đến nơi khác một cách dễ dàng. Hệ thống này có cơ chế liên lạc đồng bộ để đảm bảo sự toàn vẹn dữ liệu và thường được xây dựng trên một số các kỹ thuật đối tượng như CORBA, COM/DCOM, hay Java Beans/RMI.  • Hệ thống giao dịch (Business system): Mô tả mục đích, nguồn lực (con người, máy tính), các quy tắc (luật pháp, chiến thuật, cơ chế), và công việc hoạt động nghiệp vụ.  • Phần mềm hệ thống (System software): Định nghĩa cơ sở hạ tầng kỹ thuật cho phần mềm khác sử dụng, chẳng hạn như hệ điều hành, cơ sở dữ liệu, giao diện người sử dụng. 15 Lĩnh vực ứng dụng UML UML được sử dụng trong ba loại mô hình hệ thống:  Các mô hình chức năng, được thể hiện trong UML với biểu đồ Use Case, mô tả các chức năng của hệ thống từ quan điểm của người sử dụng.  Các mô hình đối tượng, được thể hiện trong UML với biểu đồ lớp, mô tả cấu trúc của hệ thống bằng các đối tượng, các thuộc tính, các liên kết, và các hoạt động.  Các mô hình động, được thể hiện trong UML với biểu đồ tương tác, biểu đồ trạng thái, và biểu đồ hoạt động, mô tả các hành vi nội bộ của hệ thống. 16 UML và các giai đoạn phát triển hệ thống Tập hợp yêu cầu  UML dùng Use Case để nắm bắt các yêu cầu của khách hàng. UML sử dụng biểu đồ Use case (Use Case Diagram) để nêu bật mối quan hệ cũng như sự cách thức giao tiếp với hệ thống.  Trong Use case, các tác nhân (Actor) bên ngoài quan tâm đến hệ thống sẽ được mô hình hóa song song với chức năng mà họ đòi hỏi từ phía hệ thống (tức là Use case). Các tác nhân và các Use case được mô hình hóa cùng với các mối quan hệ và được miêu tả trong biểu đồ Use case của UML. 17 UML và các giai đoạn phát triển hệ thống Giai đoạn phân tích  quan tâm đến quá trình trừu tượng hóa, hình thành các lớp và các đối tượng cũng như cơ chế hiện hữu trong phạm vi vấn đề.  Sau khi nhà phân tích đã nhận biết được các lớp thành phần của mô hình cũng như mối quan hệ giữa chúng với nhau, các lớp cùng các mối quan hệ đó sẽ được miêu tả bằng biểu đồ lớp (class diagram) của UML.  Sự cộng tác giữa các lớp nhằm thực hiện các Use case cũng sẽ được miêu tả nhờ vào các mô hình động (dynamic models) của UML. Trong giai đoạn phân tích, chỉ duy nhất các lớp có tồn tại trong phạm vi vấn đề (các khái niệm đời thực) là được mô hình hóa.  Giai đoạn này chưa xét đến các lớp kỹ thuật, định nghĩa chi tiết cũng như giải pháp trong hệ thống phần mềm, ví dụ như các lớp cho giao diện người dùng, cho ngân hàng dữ liệu, cho giao tiếp. 18 UML và các giai đoạn phát triển hệ thống Thiết kế  Kết quả của giai đoạn phân tích sẽ được mở rộng thành giải pháp kỹ thuật.  Các lớp mới sẽ được bổ sung để tạo thành hạ tầng cơ sở kỹ thuật: Giao diện người dùng, các chức năng để lưu trữ các đối tượng trong ngân hàng dữ liệu, giao tiếp với các hệ thống khác, giao diện với các thiết bị ngoại vi và các máy móc khác trong hệ thống.  Các lớp thuộc phạm vi vấn đề có từ giai đoạn phân tích sẽ được "nhúng" vào hạ tầng cơ sở kỹ thuật này, tạo ra khả năng thay đổi trong cả hai phương diện: Phạm vi vấn đề và hạ tầng cơ sở. Giai đoạn thiết kế sẽ đưa ra kết quả là bản đặc tả chi tiết cho giai đoạn xây dựng hệ thống. 19 UML và các giai đoạn phát triển hệ thống Xây dựng (triển khai lập trình)  Các lớp của giai đoạn thiết kế sẽ được chuyển thành những dòng code trong một ngôn ngữ lập trình hướng đối tượng cụ thể (lưu ý không nên dùng ngôn ngữ lập trình hướng chức năng).  Đây có thể là một công việc khó khăn hay dễ dàng tùy theo khả năng của ngôn ngữ được lựa chọn.  Khi tạo ra các mô hình phân tích và thiết kế trong UML, tốt nhất nên tránh biến đổi ngay lập tức các mô hình này thành các dòng code.  Mô hình được sử dụng để dễ hiểu, dễ giao tiếp và tạo nên cấu trúc của hệ thống trong những giai đoạn trước. 20 UML và các giai đoạn phát triển hệ thống Kiểm thử Các nhóm sử dụng biểu đồ UML khác nhau làm nền tảng cho công việc của mình:  Kiểm thử đơn vị sử dụng biểu đồ lớp (class diagram) và đặc tả lớp,  kiểm thử tích hợp thường sử dụng biểu đồ thành phần (component diagram) và biểu đồ cộng tác (collaboration diagram), và  giai đoạn kiểm thử hệ thống sử dụng biểu đồ Use case (Use Case diagram) để đảm bảo hệ thống có phương thức hoạt động đúng như đã được định nghĩa từ ban đầu trong các biểu đồ này. 21 Các khái niệm cơ bản của UML  Hướng nhìn (view): Hướng nhìn chỉ ra những khía cạnh khác nhau của hệ thống cần phải được mô hình hóa. Một hướng nhìn không phải là một bản vẽ, mà là một sự trừu tượng hóa bao gồm một loạt các biểu đồ khác nhau  Biểu đồ (diagram): Biểu đồ là các hình vẽ miêu tả nội dung trong hướng nhìn. UML có tất cả 9 loại biểu đồ được sử dụng kết hợp để mô tả các hướng nhìn của hệ thống. 22 Các khái niệm cơ bản của UML  Phần tử mô hình (model element): Các khái niệm được sử dụng trong các biểu đồ được gọi là các phần tử mô hình, thể hiện các khái niệm hướng đối tượng quen thuộc.  Cơ chế chung: Cơ chế chung cấp thêm những lời nhận xét bổ sung, các thông tin cũng như các quy tắc ngữ pháp về một phần tử mô hình. Cơ chế chung còn có các cơ chế để có thể mở rộng ngôn ngữ UML 23 Các khái niệm cơ bản của UML Hướng nhìn  Một hệ thống cần phải được miêu tả với nhiều khía cạnh khác nhau: về mặt chức năng (cấu trúc tĩnh cũng như các tương tác động), về mặt phi chức năng (yêu cầu về thời gian, về độ đáng tin cậy, về quá trình thực thi) cũng như về khía cạnh tổ chức (tổ chức làm việc, quan hệ mô hình với dòng code). 24 Các khái niệm cơ bản của UML Hướng nhìn  Mỗi một hướng nhìn được miêu tả bằng nhiều biểu đồ, chứa đựng các thông tin nêu bật khía cạnh đặc biệt đó của hệ thống. Trong thực tế khi phân tích và thiết kế rất dễ xảy ra sự trùng lặp thông tin, cho nên một biểu đồ trên thật tế có thể là thành phần của nhiều hướng nhìn khác nhau. 25 Các khái niệm cơ bản của UML Hướng nhìn  Hướng nhìn Use case (Use Case view): đây là hướng nhìn chỉ ra khía cạnh chức năng của một hệ thống, nhìn từ hướng tác nhân bên ngoài.  Hướng nhìn Logic (logical view): chỉ ra chức năng sẽ được thiết kế bên trong hệ thống như thế nào, qua các khái niệm về cấu trúc tĩnh cũng như ứng xử động của hệ thống. 26 Các khái niệm cơ bản của UML Hướng nhìn  Hướng nhìn Thành phần (component view): chỉ ra khía cạnh tổ chức của các thành phần code.  Hướng nhìn Song song (concurrent view): chỉ ra sự tồn tại song song/ trùng hợp trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong hệ thống.  Hướng nhìn Triển khai (deployment view): chỉ ra khía cạnh triển khai hệ thống 27 Các khái niệm cơ bản của UML 28 Các khái niệm cơ bản của UML 29 Hướng nhìn Use case (Use case View)  miêu tả chức năng của hệ thống sẽ phải cung cấp do được tác nhân từ bên ngoài mong đợi.  Tác nhân là thực thể tương tác với hệ thống; đó có thể là một người sử dụng hoặc là một hệ thống khác.  Biểu đồ Use case (Use Case diagram) và thỉnh thoảng cũng bao gồm cả các biểu đồ hoạt động (activity diagram). Các khái niệm cơ bản của UML 30 Hướng nhìn Use case (Use case View)  Mục tiêu của hệ thống là cung cấp các chức năng được miêu tả trong hướng nhìn này, cùng với một vài các thuộc tính mang tính phi chức năng.  Hướng nhìn Use case có ảnh hưởng đến tất cả các hướng nhìn khác.  Hướng nhìn này cũng được sử dụng để thẩm tra (verify) hệ thống trong kiểm thử, xem hệ thống có các chức năng yêu cầu.  Các khái niệm cơ bản của UML 31 Hướng nhìn Use case (Use case View)  Các khái niệm cơ bản của UML 32 Hướng nhìn logic (Logical View)  miêu tả phương thức mà các chức năng của hệ thống sẽ được cung cấp.  Nó được sử dụng chủ yếu cho các thiết kế viên và nhà phát triển.  Ngược lại với hướng nhìn Use case, hướng nhìn logic nhìn vào phía bên trong của hệ thống.  Các khái niệm cơ bản của UML 33  Cấu trúc tĩnh được miêu tả bằng các biểu đồ lớp (class diagram) và biểu đồ đối tượng (object diagram).  Quá trình mô hình động được miêu tả trong các biểu đồ trạng thái (state diagram), Biểu đồ trình tự (sequence diagram), biểu đồ tương tác (collaboration diagram) và biểu đồ hoạt động (activity diagram).   Các khái niệm cơ bản của UML 34 Hướng nhìn thành phần (Component View)  mô tả việc thực thi các module cũng như sự phụ thuộc giữa chúng với nhau. Nó thường được sử dụng cho nhà phát triển và bao gồm nhiều biểu đồ thành phần.  Thành phần ở đây là các module lệnh thuộc nhiều loại khác nhau, sẽ được chỉ ra trong biểu đồ cùng với cấu trúc cũng như sự phụ thuộc của chúng. Các khái niệm cơ bản của UML 35 Hướng nhìn song song (Concurrency View)  nhắm tới việc chia hệ thống thành các qui trình (process) và các bộ xử lý (processor).  Khía cạnh này vốn là một thuộc tính phi chức năng của hệ thống, cho phép ta sử dụng một cách hữu hiệu các nguồn tài nguyên, thực thi song song, cũng như xử lý các sự kiện không đồng bộ từ môi trường. Các khái niệm cơ bản của UML 36 Hướng nhìn triển khai (Deployment View)  Có các biểu đồ triển khai về mặt vật lý của hệ thống, ví dụ các máy tính, thiết bị và sự liên kết giữa chúng với nhau.  Hướng nhìn triển khai giành cho các nhà phát triển, người tích hợp cũng như người kiểm thử hệ thống và được thể hiện bằng các biểu đồ triển khai. Các khái niệm cơ bản của UML 37 Các khái niệm cơ bản của UML 38 Biểu đồ (Diagram)  là các hình vẽ bao gồm các ký hiệu phần tử mô hình hóa được sắp xếp để minh họa một thành phần cụ thể hay một khía cạnh cụ thể của hệ thống.  Một mô hình hệ thống thường có nhiều loại biểu đồ, mỗi loại có nhiều biểu đồ. Một biểu đồ là một thành phần của một hướng nhìn cụ thể; và khi được vẽ ra, nó thường thường cũng được xếp vào một hướng nhìn. Các khái niệm cơ bản của UML 39 Biểu đồ (Diagram) Các khái niệm cơ bản của UML 40 Biểu đồ (Diagram) Use Case được sử dụng trong quá trình tập hợp yêu cầu và phân tích yêu cầu để mô tả chức năng của hệ thống. Use Case xem các hành vi của hệ thống với góc nhìn từ bên ngoài hệ thống. Một Use Case mô tả chức năng của hệ thống với sự tham gia của tác nhân (actor). Một tác nhân thể hiện một thực thể tương tác với hệ thống. Các khái niệm cơ bản của UML 41 Biểu đồ (Diagram) Việc xác định các tác nhân và các Use Case sẽ định ra phạm vi của hệ thống: phân biệt các nhiệm vụ thực hiện bởi hệ thống và các nhiệm vụ thực hiện bởi môi trường. Các tác nhân đứng ở bên ngoài phạm vi của hệ thống, trong khi các Use Case nằm bên trong phạm vi của hệ thống. Các khái niệm cơ bản của UML 42 Biểu đồ (Diagram) Check Balance Card Holder Withdraw Cash Các khái niệm cơ bản của UML 43 Biểu đồ lớp (Class Diagrams) Các lớp là khái niệm trừu tượng về cấu trúc chung và hành vi của một tập hợp các đối tượng. Đối tượng là các trường hợp của các lớp được tạo ra, sửa đổi, và bị xóa trong quá trình thực hiện của hệ thống. Một đối tượng có trạng thái, bao gồm giá trị của các thuộc tính của nó và liên kết với các đối tượng khác. Các khái niệm cơ bản của UML 44 Biểu đồ lớp (Class Diagrams) Các khái niệm cơ bản của UML 45 Các lớp có thể quan hệ với nhau trong nhiều dạng thức: liên kết (associated - được kết nối với nhau), phụ thuộc (dependent - một lớp này phụ thuộc vào lớp khác), chuyên biệt hóa (specialized - một lớp này là một kết quả chuyên biệt hóa của lớp khác), hay đóng gói (packaged - hợp với nhau thành một đơn vị). Các khái niệm cơ bản của UML 46 Các khái niệm cơ bản của UML 47 Biểu đồ đối tượng  Một biểu đồ đối tượng (Object Diagram) là một phiên bản của biểu đồ lớp và thường cũng sử dụng các ký hiệu như biểu đồ lớp.  Sự khác biệt giữa hai loại biểu đồ này nằm ở chỗ biểu đồ đối tượng chỉ ra một loạt các đối tượng thực thể của lớp, thay vì các lớp. Một biểu đồ đối tượng vì vậy là một ví dụ của biểu đồ lớp Các khái niệm cơ bản của UML 48 Biểu đồ đối tượng Các khái niệm cơ bản của UML 49 Biểu đồ trạng thái (State Diagram)  Không được vẽ cho tất cả các lớp, mà chỉ riêng cho những lớp có một số lượng các trạng thái được định nghĩa rõ ràng và hành vi của lớp bị ảnh hưởng và thay đổi qua các trạng thái khác nhau.  Chỉ ra tất cả các trạng thái mà đối tượng của lớp này có thể có, và những sự kiện (event) nào sẽ gây ra sự thay đổi trạng. Các khái niệm cơ bản của UML 50 Biểu đồ trạng thái (State Diagram)  Một trạng thái đại diện cho một tập hợp các giá trị cho một đối tượng.  Một trạng thái có thể chuyển đổi sang một trạng thái khác khi có thỏa mãn một điều kiện nhất định.  Vòng tròn nhỏ màu đen là trạng thái ban đầu.  Một vòng tròn xung quanh một vòng tròn nhỏ màu đen là trạng thái cuối cùng. Các khái niệm cơ bản của UML 51 Biểu đồ trạng thái (State Diagram) White's turn Black's turn Black wins Draw White wins Start checkMate staleMate staleMate checkMate Chess game Các khái niệm cơ bản của UML 52  Biểu đồ hoạt động (Activity Diagrams)  Chỉ ra một trình tự lần lượt của các hoạt động.  Biểu đồ hoạt động thường được sử dụng để miêu tả các hoạt động được thực hiện trong một thủ tục, mặc dù nó cũng có thể được sử dụng để miêu tả các dòng chảy hoạt động khác, ví dụ như trong một Use case hay trong một trình tự tương tác. Các khái niệm cơ bản của UML 53 Biểu đồ hoạt động (Activity Diagrams)  Dòng điều khiển ở đây chạy giữa các