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

Nội dung text: 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

1. 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
2. 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
3. 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
4. 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
5. 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
6. 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
7. 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
8. Lịch sử hình thành UML 8
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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
20. 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
21. 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
22. 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
23. 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
24. 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
25. 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
26. 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
27. 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
28. Các khái niệm cơ bản của UML 28
29. Các khái niệm cơ bản của UML 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). 29
30. Các khái niệm cơ bản của UML 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. 30 
31. Các khái niệm cơ bản của UML Hướng nhìn Use case (Use case View)  31
32. Các khái niệm cơ bản của UML 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. 32 
33. Các khái niệm cơ bản của UML  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).  33 
34. Các khái niệm cơ bản của UML 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. 34
35. Các khái niệm cơ bản của UML 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. 35
36. Các khái niệm cơ bản của UML 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. 36
37. Các khái niệm cơ bản của UML 37
38. Các khái niệm cơ bản của UML 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. 38
39. Các khái niệm cơ bản của UML Biểu đồ (Diagram) 39
40. Các khái niệm cơ bản của UML 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. 40
41. Các khái niệm cơ bản của UML 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. 41
42. Các khái niệm cơ bản của UML Biểu đồ (Diagram) Check Balance Card Holder Withdraw Cash 42
43. Các khái niệm cơ bản của UML 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. 43
44. Các khái niệm cơ bản của UML Biểu đồ lớp (Class Diagrams) 44
45. Các khái niệm cơ bản của UML 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ị). 45
46. Các khái niệm cơ bản của UML 46
47. Các khái niệm cơ bản của UML 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 47
48. Các khái niệm cơ bản của UML Biểu đồ đối tượng 48
49. Các khái niệm cơ bản của UML 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. 49
50. Các khái niệm cơ bản của UML 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. 50
51. Các khái niệm cơ bản của UML Biểu đồ trạng thái (State Diagram) Chess game Black wins checkMate White's turn Start staleMate Draw staleMate checkMate Black's turn White wins 51
52. Các khái niệm cơ bản của UML  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. 52
53. Các khái niệm cơ bản của UML Biểu đồ hoạt động (Activity Diagrams)  Dòng điều khiển ở đây chạy giữa các trạng thái hành động liên kết với nhau.  Biểu đồ còn có thể chỉ ra các quyết định, các điều kiện, cũng như phần thực thi song song của các trạng thái hành động.  Biểu đồ ngoài ra còn có thể chứa các loại đặc tả cho các thông điệp được gửi đi hoặc được nhận về, trong tư cách là thành phần của hành động được thực hiện. 53
54. Các khái niệm cơ bản của UML Biểu đồ hoạt động (Activity Diagrams) Receive order Fill order Send invoice Overnight Regular Receive delivery delivery payment Close order End 54
55. Các khái niệm cơ bản của UML Biểu đồ trình tự (Sequence Diagram)  Mô hình hóa các hành vi động của hệ thống và dễ hình dung cách liên lạc giữa các đối tượng.  Biểu đồ tương tác có ích cho việc xác định các đối tượng bổ sung tham gia trong các Use Case. Trong biểu đồ có trình tự các thông điệp (message) được gửi giữa các đối tượng và trình tự tương tác giữa các đối tượng, 55
56. Các khái niệm cơ bản của UML Biểu đồ trình tự (Sequence Diagram) Account Holder ATM Bank Identify Request authentication Provide authentication Authenticate identity Confirm identity 56
57. Các khái niệm cơ bản của UML Biểu đồ cộng tác (Collaboration Diagram)  Việc lựa chọn sử dụng Biểu đồ trình tự hay biểu đồ cộng tác thường sẽ được quyết định theo nguyên tắc chung sau: Nếu thời gian hay trình tự là yếu tố quan trọng nhất cần phải nhấn mạnh thì hãy chọn biểu cộng tác. Trình tự tương tác giữa các đối tượng được thể hiện trong cả hai loại biểu đồ này 57
58. Các khái niệm cơ bản của UML Biểu đồ cộng tác (Collaboration Diagram) 58
59. Các khái niệm cơ bản của UML Biểu đồ thành phần (Component Diagram) miêu tả cấu trúc vật lý của các dòng lệnh (code) theo khái niệm thành phần code.  Một thành phần code có thể là một tập tin source code, một thành phần nhị phân (binary) hay một thành phần thực thi được (executable).  Một thành phần chứa các thông tin về các lớp logic hoặc các lớp mà nó thi hành, như vậy nó tạo ra một ánh xạ từ hướng nhìn logic vào hướng nhìn thành phần. 59
60. Các khái niệm cơ bản của UML Biểu đồ thành phần (Component Diagram) 60
61. Các khái niệm cơ bản của UML Biểu đồ triển khai (Deployment Diagram)  mô tả kiến trúc vật lý của phần cứng cũng như phần mềm trong hệ thống.  Biểu đồ có thể chỉ ra từng máy tính cụ thể và từng trang thiết bị cụ thể (node) với sự kết nối giữa chúng.  Biểu đồ cũng có thể chỉ ra loại của các mối kết nối. d 61
62. Các khái niệm cơ bản của UML Biểu đồ triển khai (Deployment Diagram) 62
63. Các khái niệm cơ bản của UML Phần tử mô hình  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 (model element).  Một phần tử mô hình được định nghĩa với ngữ nghĩa (semantic), đó là một định nghĩa về bản chất phần tử hay là ý nghĩa chính xác xem nó sẽ thể hiện điều gì. Mỗi phần tử mô hình còn có được miêu tả trực quan bằng một ký hiệu hình học. 63
64. Các khái niệm cơ bản của UML Phần tử mô hình 64
65. Các khái niệm cơ bản của UML Kết nối (Association): nối các phần tử và các thực thể nối. Khái quát hóa (Generalization): còn được gọi là tính thừa kế, có nghĩa rằng một phần tử này có thể là một sự chuyên biệt hóa của một phần tử khác. Sự phụ thuộc (Dependency): chỉ ra rằng một phần tử phụ thuộc vào một phần tử khác trong một phương thức nào đó. Kết tập (Aggregation): Một dạng của kết nối, trong đó một phần tử này chứa các phần tử khác. 65
66. Các khái niệm cơ bản của UML Cơ chế chung  UML thể hiện một số các cơ chế chung (general mechanism) trong tất cả các biểu đồ nhằm mục đích cung cấp thêm các thông tin bổ sung, đây thường là những thông tin không thể được thể hiện qua các chức năng và khả năng cơ bản của các phần tử mô hình. 66
67. Các khái niệm cơ bản của UML  Trang trí (adornment) trực quan có thể được sử dụng thêm cho các phần tử mô hình trong biểu đồ.  Động tác trang trí bổ sung ngữ nghĩa cho phần tử.  Ví dụ kỹ thuật để phân biệt một loại thực thể (lớp) và một thực thể: khi thể hiện một loại, tên phần tử sẽ được in đậm; khi chính phần tử đó thể hiện chỉ một thực thể của loại này, tên phần tử sẽ được gạch dưới 67
68. Các khái niệm cơ bản của UML 68
69. Các khái niệm cơ bản của UML  Để bổ sung thêm cho một mô hình những thông tin không thể được thể hiện bằng phần tử mô hình, UML cung cấp khả năng kèm theo lời ghi chú (Note).  Một lời ghi chú có thể được để bất kỳ nơi nào trong bất kỳ biểu đồ nào, và nó có thể chứa bất kỳ loại thông tin nào.  Dạng thông tin của nó là chuỗi ký tự (string). 69
70. Các khái niệm cơ bản của UML Business Use-Case Model The Use-Case Model is traceable to (and deriv es f rom) the Business Model. The sy stem (as described in the Use Case Model) prov ides behav ior that supports the business. Use-Case Model 70
71. Các khái niệm cơ bản của UML Đặc tả (specification) có nhiều hình thức. Các phần tử mô hình có thuộc tính (property) chứa các giá trị dữ liệu về phần tử này.  Một thuộc tính được định nghĩa với một tên và một giá trị đính kèm (tagged value), thường ở trong một dạng thông tin được xác định trước, ví dụ như số nguyên hay chuỗi kí tự. 71
72. Các khái niệm cơ bản của UML Đặc tả (specification) 72
73. Các khái niệm cơ bản của UML Khuôn mẫu (Stereotype) định nghĩa một loại phần tử mô hình mới dựa trên một phần tử mô hình đã tồn tại. • Khuôn mẫu có thể được coi là "tương tự" như một phần tử đã có sẵn, cộng thêm phần quy định ngữ nghĩa (semantic) riêng biệt không có trong phần tử gốc kia. • Khuôn mẫu của một phần tử có thể được sử dụng trong cùng tình huống như phần tử căn bản. 73
74. Các khái niệm cơ bản của UML Khuôn mẫu (Stereotype) 74
75. Các khái niệm cơ bản của UML Giá trị đính kèm (Tagged Value). Các phần tử mô hình UML có nhiều các thuộc tính được định nghĩa trước, nhưng người sử dụng có thể định nghĩa ra các thuộc tính mới để bổ sung thông tin các phần tử mô hình. 75
76. Các khái niệm cơ bản của UML  Một sự hạn chế (Constraint) là một giới hạn về sử dụng hoặc ý nghĩa của một phần tử. Sự hạn chế hoặc sẽ được khai báo trong công cụ và được sử dụng nhiều lần trong nhiều biểu đồ khác nhau, hoặc được định nghĩa và sử dụng chỉ trong một biểu đồ, theo yêu cầu. 76
77. Các khái niệm cơ bản của UML Mô hình hóa với UML  Khi xây dựng hệ thống với UML, người ta không chỉ xây dựng duy nhất một mô hình.  Sẽ có nhiều mô hình trong các giai đoạn phát triển, nhắm đến các mục đích khác nhau. 77
78. Các khái niệm cơ bản của UML Mô hình hóa với UML 78
79. Các khái niệm cơ bản của UML Mô hình hóa với UML Ngôn ngữ UML không phụ thuộc vào giai đoạn, có nghĩa là cùng một nguyên tắc ngôn ngữ và các biểu đồ được sử dụng để mô hình hóa những sự việc trong những giai đoạn khác nhau. 79
80. Các khái niệm cơ bản của UML Mô hình hóa với UML Khi mô hình hóa bằng ngôn ngữ UML, toàn bộ công việc cần phải được thực hiện theo một phương pháp hay một qui trình, xác định rõ các bước công việc cần được tiến hành và cách thực thi từng bước. Một qui trình như vậy thường sẽ chia công việc ra thành các vòng lặp nối tiếp, mỗi vòng lặp bao gồm các công việc: phân tích yêu cầu - phân tích - thiết kế - thực hiện - triển khai. 80
81. Các khái niệm cơ bản của UML Mô hình hóa với UML 81
82. Các khái niệm cơ bản của UML Công cụ UML  Sử dụng một ngôn ngữ mô hình hóa phức tạp và rộng mở như UML cần thiết có trợ giúp của công cụ (tool).  Mặc dù phác thảo đầu tiên của một mô hình có thể được thực hiện bằng bảng, giấy và bút, công việc bảo trì, đồng bộ hóa và đảm bảo sự nhất quán trong một loạt các biểu đồ khác nhau thường lại không thể trở thành khả thi nếu thiếu công cụ. 82
83. Các khái niệm cơ bản của UML Công cụ UML  Công cụ hỗ trợ hiện đang giảm ngắn khi duy trì phụ thuộc hai chiều, đặc biệt là giữa các mô hình phân tích và mã nguồn.  Một số công cụ, chẳng hạn như Cơ sở lý luận Rose [Rational năm 2002 và cùng nhau kiểm soát Trung tâm [TogetherSoft, 2002], thực hiện chức năng này bằng cách nhúng thông tin về Liên hệ và UML cấu trúc khác trong ý kiến mã nguồn. 83
84. Các khái niệm cơ bản của UML Công cụ UML Công cụ mô hình hóa hiện đại cần phải cung cấp các chức năng sau:  Vẽ biểu đồ: cần phải tạo điều kiện dễ dàng vẽ ra các biểu đồ trong ngôn ngữ mô hình hóa.  Hoạt động như một nhà kho (repository): công cụ cần phải hỗ trợ một nhà kho trung tâm lưu tất cả các thông tin về mô hình trong cùng một chỗ. 84
85. Các khái niệm cơ bản của UML Công cụ UML  Hỗ trợ định hướng (navigation): công cụ cần phải tạo điều kiện dễ dàng cho người sử dụng định hướng và chuyển dịch trong mô hình để theo dõi một phần tử từ biểu đồ này sang biểu đồ khác, hoặc để phát triển mô tả của một phần tử. 85
86. Các khái niệm cơ bản của UML Công cụ UML  Hỗ trợ nhiều người sử dụng (multiuser support): Công cụ cần hỗ trợ cho nhiều người sử dụng, và tạo điều kiện cho họ cùng làm việc với một mô hình và kiểm soát để những người trong nhóm không làm hỏng kết quả của nhau.  Tự động tạo code (code generate): khả năng tạo ra code, nơi tất cả các thông tin trong mô hình được chuyển tải thành các khung code 86
87. Các khái niệm cơ bản của UML Công cụ UML  Tái tạo mô hình (reserve engineer): Một công cụ cao cấp cần phải có khả năng đọc những thành phần code đang tồn tại và từ đó xây dựng mô hình tương ứng.  Tích hợp với các công cụ khác: một công cụ cần phải có khả năng tích hợp với những công cụ khác, với môi trường phát triển, 87
88. Các khái niệm cơ bản của UML Công cụ UML  Bao quát mô hình ở các mức độ trừu tượng hóa: công cụ cần phải dễ chuyển tải từ lời miêu tả ở cấp trừu tượng hóa cao nhất của hệ thống đi xuống cho tới cấp của những dòng code thật sự.  Trao đổi mô hình: Một mô hình hay một biểu đồ của một mô hình cần phải có khả năng được xuất ra từ một công cụ này rồi nhập vào một công cụ khác 88
89. DISCUSSION – CÂU HỎI hing/objectorientedanalysisanddesign 89