<!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:14.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} p.MsoHeader, li.MsoHeader, div.MsoHeader {mso-style-unhide:no; mso-style-link:"Header Char"; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; tab-stops:center 3.0in right 6.0in; font-size:14.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} p.MsoFooter, li.MsoFooter, div.MsoFooter {mso-style-unhide:no; mso-style-link:"Footer Char"; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; tab-stops:center 3.0in right 6.0in; font-size:14.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} p {mso-style-unhide:no; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} p.cap1, li.cap1, div.cap1 {mso-style-name:cap1; mso-style-unhide:no; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; mso-pagination:widow-orphan; font-size:14.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman"; color:#006600; text-transform:uppercase; font-weight:bold;} span.HeaderChar {mso-style-name:"Header Char"; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:Header; mso-ansi-font-size:14.0pt; mso-bidi-font-size:14.0pt;} span.FooterChar {mso-style-name:"Footer Char"; mso-style-unhide:no; mso-style-locked:yes; mso-style-link:Footer; mso-ansi-font-size:14.0pt; mso-bidi-font-size:14.0pt;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} @page Section1 {size:595.35pt 842.0pt; margin:1.0in 56.7pt 1.0in 85.05pt; mso-header-margin:51.05pt; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} -->

Mô Hình Hướng Đối tượng

            Mô hình hóa hướng đối tượng là phương pháp xây dựng mô hình dựa trên tư duy hướng đối tượng . Tư tưởng cơ bản ở đây là cách nhìn nhận và phân tích thế giới thực trên cơ sở chính các đối tượng thực, không phải trên cơ sở các cấu trúc dữ liệu hay hàm, thủ tục. Thật ra, mỗi thế giới thực đều được tạo  thành bởi các đối tượng và mỗi quan hệ giữa chúng. Vì vậy mô hình hướng đối tượng được sử dụng rộng rãi.

            Trước hết, mô hình hóa hướng đối tượng giúp ta hiểu tốt hơn các yêu cầu của bài toán đặt ra, bởi cách thức tiến hành gần với tư duy con người hơn là mô hình hóa hướng dữ liệu hoặc hướng hàm. Từ đó, ta có thể đưa ra giải pháp thiết kế và thực thi phù hợp hơn cho bài toán.

             Thứ hai, các mô hình hướng đối tượng cũng là những phần mềm có giá trị sử dụng lại cao, không những xuyên suốt cả qui trình công nghệ phần mềm, mà còn cho nhiều dự án tiếp theo(tính kế thừa ). Và môt điều nữa của mô hình hóa hướng đối tượng, cũng như phân tích và thiết kế hướng đối tượng không có nghĩa là sau này bắt buộc ta phải lập trình hướng đối tượng với một ngôn ngữ hướng đối tượng.

            Tìm hiểu mô hình hướng đối tượng giúp cho việc phân tích và thiết kế phần mềm . Nó là một mô hình đặt trưng và đang được sử dụng rộng rãi kể cả trong việc thiết kế dữ liệu.

Việc chọn đề tài về mô hình hướng đối tượng sẽ giúp có kiến thức cơ bản về cách thức xây dựng mô hình cũng như cách biểu diễn của nó trong  ngôn ngữ UML. Trong bài tiểu luận còn có giới thiệu sơ về mô hình hướng đối tượng sử dụng ngôn ngữ UML một ngôn ngữ chính trong  mô hình hóa hệ thống . Việc tìm hiểu này sẽ giúp chúng em có kiến thức về mô hình hướng đối tượng nó sẽ rất cần thiết cho các dự án phần mềm .

            Trong bài tiểu luận có sử dụng một số tài liệu tìm kiếm được trên mạng. Bài tiểu luận sẽ đưa ra các vấn đề sau trong mô hình hướng đối tượng.

1 .Lớp ,đối tượng và quan hệ - các thành phần cơ bản của mô hình.

2. Tìm lớp

3. Lớp đối tượng trong UML

4 .Mối quan hệ giữa các lớp

- Liên hệ (Association)

- Khái quát hóa (Generalization)

- Phụ thuộc (Dependency)

-Nâng cấp (Refinement

5. Các lưu ý khi xây dựng mô hình hướng đối tượng.

6 .Tóm tắt về mô hình hướng đối tượng

1- LỚp, đỐi tưỢng và quan hỆ – các thành phẦn cơ bẢn cỦa mô hình

            Trong mô hình hóa hướng đối tượng, những phần tử cấu thành căn bản nhất của mô hình là lớp, đối tượng và mối quan hệ giữa chúng với nhau. Lớp và đối tượng sẽ mô hình hóa những gì có trong hệ thống mà chúng ta muốn miêu tả, các mối quan hệ sẽ biểu thị cấu trúc.

1.1- Đối tượng (Object)

            Một đối tượng là một sự tượng trưng cho một thực thể, hoặc là thực thể tồn tại trong thế giới đời thực hoặc thực thể mang tính khái niệm. Một đối tượng có thể tượng trưng cho cái gì đó cụ thể, ví dụ như một đồ vật cụ thể như máy tính, xe máy…hoặc  tượng trưng cho một khái niệm ví dụ  một giao dịch trong nhà băng, một lời đặt hàng.

            Cũng có những đối tượng (ví dụ như các đối tượng thực thi một trong hệ thống phần mềm) không thật sự tồn tại ở ngoài thế giới thực, nhưng là kết quả dẫn xuất từ quá trình nghiên cứu cấu trúc và ứng xử của các đối tượng ngoài thế giới thực.

            Một đối tượng là một khái niệm, một sự trừu tượng hóa, hoặc là một đồ vật với ranh giới và ý nghĩa được định nghĩa rõ ràng cho một ứng dụng nào đó. Mỗi đối tượng trong một hệ thống đều có ba đặc tính: trạng thái, ứng xử và sự nhận diện.

1.2- Trạng thái, ứng xử và nhận diện của đối tượng

            Trạng thái (state) của một đối tượng là một trong những hoàn cảnh nơi đối tượng có thể tồn tại. Trạng thái của một đối tượng thường sẽ thay đổi theo thời gian, và nó được định nghĩa qua một tổ hợp các thuộc tính, với giá trị của các thuộc tính này cũng như mối quan hệ mà đối tượng có thể có với các đối tượng khác.

            Ứng xử (Behaviour) xác định một đối tượng sẽ phản ứng như thế nào trước những yêu cầu từ các đối tượng khác, nó tiêu biểu cho những gì mà đối tượng này có thể làm. Ứng xử được thực thi qua loạt các Phương thức (operation) của đối tượng.

            Sự nhận diện (Identity) đảm bảo rằng mỗi đối tượng là duy nhất – dù trạng thái của nó có thể giống với trạng thái của các đối tượng khác.

1.3- Lớp (Class):

            Một lớp là một lời miêu tả của một nhóm các đối tượng có chung thuộc tính, chung phương thức (ứng xử), chung các mối quan hệ với các đối tượng khác .Nói như thế có nghĩa lớp là một khuôn mẫu để tạo ra đối tượng. Mỗi đối tượng là một thực thể của một lớp nào đó và một đối tượng không thể là kết quả thực thể hóa của nhiều hơn một lớp.

            Một lớp tốt sẽ nắm bắt một và chỉ một sự trừu tượng hóa - nó phải có một chủ đề chính

Hình 1- Mỗi thực thể trong mô hình trên là một lớp

            Khi tạo dựng mô hình cũng như thật sự xây dựng các hệ thống doanh nghiệp, các hệ thống thông tin, máy móc hoặc các lọai hệ thống khác, chúng ta cần sử dụng các khái niệm của chính phạm vi vấn đề để khiến cho mô hình dễ hiểu và dễ giao tiếp hơn. Nếu chúng ta xây dựng hệ thống cho một công ty bảo hiểm, mô hình cần phải dựa trên các khái niệm của ngành bảo hiểm.

            Một hệ thống dựa trên các khái niệm chính của một ngành doanh nghiệp nào đó có thể dễ được thiết kế lại cho phù hợp với những qui chế, chiến lược và qui định mới, bởi chúng ta chỉ cần cân bằng và khắc phục sự chênh lệch giữa công việc cũ và công việc mới. Khi các mô hình được xây dựng dựa trên các khái niệm lấy ra từ cuộc đời thực và dựa trên các khái niệm thuộc phạm vi vấn đề, hướng đối tượng sẽ là một phương pháp rất thích hợp bởi nền tảng của phương pháp hướng đối tượng là các lớp, đối tượng và mối quan hệ giữa chúng.

            Một lớp là lời miêu tả cho một dạng đối tượng trong bất kỳ một hệ thống nào đó – hệ thống thông tin, hệ thống kỹ thuật, hệ thống nhúng thời gian thực, hệ thống phân tán, hệ thống phần mềm và hệ thống doanh thương.

            Ví dụ Các hệ thống phần mềm thường có các lớp đại diện cho các thực thể phần mềm trong một hệ điều hành:

- File

- Chương trình chạy được

- Trang thiết bị

- Icon

- Cửa sổ

- Thanh kéo

1.4- Biểu đồ lớp (Class diagram):

            Một biểu đồ lớp là một dạng mô hình tĩnh. Một biểu đồ lớp miêu tả hướng nhìn tĩnh của một hệ thống bằng các khái niệm lớp và mối quan hệ giữa chúng với nhau. Mặc dù nó cũng có những nét tương tự với một mô hình dữ liệu, nhưng các lớp không phải chỉ thể hiện cấu trúc thông tin mà còn miêu tả cả hành vi. Một trong các mục đích của biểu đồ lớp là tạo nền tảng cho các biểu đồ khác, thể hiện các khía cạnh khác của hệ thống (ví dụ như trạng thái của đối tượng hay cộng tác động giữa các đối tượng, được chỉ ra trong các biểu đồ động). Một lớp trong một biểu đồ lớp có thể được thực thi trực tiếp trong một ngôn ngữ hướng đối tượng có hỗ trợ trực tiếp khái niệm lớp.

Hình 2-Mô hình lớp trong UML

Hình 3- Một lớp cụ thể với các thuộc tính

2- Tìm lỚp:

             Đi tìm các lớp  là một công việc khó khăn trong quá trình xây dựng mô hình nó đòi hỏi người phân tích phải lắm rõ được mô hình đang thiết kế . Vì qui trình phân tích và thiết kế mang tính vòng lặp, nên danh sách các lớp sẽ thay đổi theo thời gian. Vì thế, thường người ta hay sử dụng đến khái niệm các lớp ứng cử viên (Candidate Class) để miêu tả tập hợp những lớp đầu tiên được tìm ra cho hệ thống.

            Có nhiều phương pháp khác nhau để thực hiện công việc đó. Có phương pháp đề nghị tiến hành phân tích phạm vi bài toán, chỉ ra tất cả các lớp thực thể (thuộc phạm vi bài toán) với mối quan hệ của chúng với nhau. Sau đó nhà phát triển sẽ phân tích từng trường hợp sử dụng và phân bổ trách nhiệm cho các lớp trong mô hình phân tích (analysis model), nhiều khi sẽ thay đổi chúng hoặc bổ sung thêm các lớp mới. Có phương pháp đề nghị nên lấy các trường hợp sử dụng làm nền tảng để tìm các lớp, làm sao trong quá trình phân bổ trách nhiệm thì mô hình phân tích của phạm vi bài toán sẽ từng bước từng bước được thiết lập.

2.1.1- Nhận dạng lớp và đối tượng

            Nắm vững khái niệm lớp, chúng ta có thể tương đối dễ dàng tìm thấy các lớp và đối tượng trong phạm vi vấn đề. Một nguyên tắc thô sơ thường được áp dụng là danh từ trong các lời phát biểu bài toán thường là các ứng cử viên để chuyển thành lớp và đối tượng.

Một số gợi ý thực tế cho việc tìm lớp trong phạm vi vấn đề:

Bước đầu tiên là cần phải tập trung nghiên cứu kỹ:

- Các danh từ trong những lời phát biểu bài toán

- Kiến thức chuyên ngành thuộc phạm vi bài toán

- Các Trường hợp sử dụng

Thứ hai, chúng ta cần chú ý đến các nhóm vật thể trong hệ thống hiện thời như:

- Các thực thể vật lý của hệ thống: những vật thể tương tác với hệ thống, ví dụ khách hàng.

- Các vật thể hữu hình: các vật thể vật lý mà ta có thể nhìn và sờ thấy. Ví dụ như công cụ giao thông, sách vở, một con người, một ngôi nhà,….

- Các sự kiện (Events): Một chiếc xe bị hỏng, một cái cửa được mở ra.

- Các vai trò (Role): Ví dụ như mẹ, khách hàng, người bán hàng, ….

- Các sự tương tác (Interactions): Ví dụ việc bán hàng là một chuỗi tương tác bao gồm khách hàng, người bán hàng và sản phẩm.

- Vị trí (Location): Một đồ vật nào đó hoặc một người nào đó được gán cho một vị trí nào đó. Ví dụ: Ôtô đối với nhà để xe.

- Đơn vị tổ chức (Organisation Unit): Ví dụ các phòng ban, phòng trưng bày sản phẩm, các bộ phận.

Bên cạnh đó, còn nhiều câu hỏi khác giúp ta nhận dạng lớp. Ví dụ như :

- Ta có thông tin cần được lưu trữ hoặc cần được phân tích không? Nếu có thông tin cần phải được lưu trữ, biến đổi, phân tích hoặc xử lý trong một phương thức nào đó thì chắc chắn đó sẽ là ứng cử viên cho lớp. Những thông tin này có thể là một khái niệm luôn cần phải được ghi trong hệ thống hoặc là sự kiện, giao dịch xảy ra tại một thời điểm cụ thể nào đó.

- Ta có các hệ thống ngoại vi không? Nếu có, thường chúng cũng đáng được quan tâm tới khi tạo dựng mô hình. Các hệ thống bên ngoài có thể được coi là các lớp chứa hệ thống của chúng ta hoặc tương tác với hệ thống của chúng ta.

- Chúng ta có các mẫu, thư viện lớp , thành phần và những thứ khác không? Nếu chúng ta có mẫu, thư viện, thành phần từ các dự án trước (xin được của các bạn đồng nghiệp, mua được từ các nhà cung cấp) thì chúng thường cũng sẽ chứa các ứng cử viên lớp.

- Có thiết bị ngoại vi mà hệ thống của chúng ta cần xử lý không? Mỗi thiết bị kỹ thuật được nối với hệ thống của chúng ta thường sẽ trở thành ứng cử viên cho lớp xử lý loại thiết bị ngoại vi này.

- Chúng ta có phần công việc tổ chức không? Miêu tả một đơn vị tổ chức là công việc được thực hiện với các lớp, đặc biệt là trong các mô hình doanh nghiệp.

2.1.2- Tổng kết về các nguồn thông tin cho việc tìm lớp:

Nhìn chung, các nguồn thông tin chính cần đặc biệt chú ý khi tìm lớp là :

- Các lời phát biểu yêu cầu

- Các Trường hợp sử dụng

- Sự trợ giúp của các chuyên gia ứng dụng

- Nghiên cứu hệ thống hiện thời

2.2- Các lớp ứng cử viên:

            Theo các bước kể trên trong phần đầu giai đoạn phân tích, ta đã miêu tả được một số lớp khác nhau. Những lớp này được gọi là các lớp ứng cử viên, chúng thể hiện những lớp có khả năng tồn tại trong một hệ thống cho trước. Mặc dù vậy, đây vẫn có thể chưa phải là kết quả chung cuộc, một số lớp ứng cử viên có thể sẽ bị loại bỏ trong các bước sau vì không thích hợp.

2.3- Loại bỏ các lớp ứng cử viên không thích hợp:

            Có rất nhiều loại lớp ứng cử viên không thích hợp cần phải được loại bỏ:

            Lớp dư, thừa: Khi có hơn một lớp định nghĩa cùng một thực thể, nên giữ lại lớp tốt nhất và loại bỏ những lớp khác.

            Lớp không thích hợp: Lớp định nghĩa ra những thực thể không liên quan đến vấn đề thực tại. Mọi lớp không xuất phát từ phạm vi ứng dụng cần phải được loại bỏ. 

            Lớp không rõ ràng: Lớp không có chức năng cụ thể được gọi là các lớp không rõ ràng. Lớp tồn tại và có giá trị sử dụng trong một hệ thống là lớp có một chức năng đã được nhận diện và xác định rõ ràng. Các lớp không rõ ràng cần phải được định nghĩa lại hoặc loại bỏ. 

- Tương tự, những thuộc tính và phương thức không rõ ràng cần phải được loại ra khỏi danh sách các lớp ứng cử viên. Chúng không cần phải bị xoá hẳn, nhưng cần được đưa ra ngoài để ta có thể nhìn rõ các lớp cần thiết đã được nhận diện. Các ứng xử đó sau này có thể được gán cho các lớp thích hợp hơn.

- Các lớp chỉ là vai trò (Role) đối với một lớp khác: Hãy loại bỏ tất cả các vai trò và giữ lại lớp chính.

- Một lớp không cung cấp ứng xử cần thiết hoặc thuộc tính cần thiết có thể sẽ là lớp không cần thiết. Nhiều khi, có thể có một lớp chẳng cung cấp một thuộc tính hoặc ứng xử nào mà chỉ định nghĩa một tập hợp các mối quan hệ. Những lớp như thế cần phải được nghiên cứu kỹ để xác định sự liên quan với hệ thống.

3- LỚp và đỐi tưỢng trong UML

            UML thể hiện lớp bằng hình chữ nhật có 3 phần. Phần thứ nhất chứa tên lớp. Trong phần thứ hai là thuộc tính và các dữ liệu thành phần của lớp và trong phần thứ ba là các phương thức hay hàm thành phần của lớp.

3.1- Tên lớp (lass name) :

Tên lớp được in đậm (bold) và căn giữa. Tên lớp phải được dẫn xuất từ phạm vi vấn đề và rõ ràng như có thể. Vì thế nó là danh từ, ví dụ như tài khoản, nhân viên, ....

3.2- Thuộc tính (attribute):

            Lớp có thuộc tính miêu tả những đặc điểm của đối tượng. Giá trị của thuộc tính thường là những dạng dữ liệu đơn giản được đa phần các ngôn ngữ lập trình hỗ trợ như Integer, Boolean, Floats, Char, …

            Thuộc tính có thể có nhiều mức độ trông thấy được (visibility) khác nhau, miêu tả liệu thuộc tính đó có thể được truy xuất từ các lớp khác, khác với lớp định nghĩa ra nó. Nếu thuộc tính có tính trông thấy là công cộng (public), thì nó có thể được nhìn thấy và sử dụng ngoài lớp đó. Nếu thuộc tính có tính trông thấy là riêng (private), bạn sẽ không thể truy cập nó từ bên ngoài lớp đó. Một tính trông thấy khác là bảo vệ (protected), được sử dụng chung với công cụ khái quát hóa và chuyên biệt hóa. Nó cũng giống như các thuộc tính riêng nhưng được thừz kế bởi các lớp dẫn xuất. (Trong UML, thuộc tính công cộng mang kí hiệu "+" và thuộc tính riêng mang dấu "-". )

            Giá trị được gán cho thuộc tính có thể là một cách để miêu tả trạng thái của đối tượng. Mỗi lần các giá trị này thay đổi là biểu hiện cho thấy có thể đã xảy ra một sự thay đổi trong trạng thái của đối tượng.

            Lưu ý: Mọi đặc điểm của một thực thể là những thông tin cần lưu trữ đều có thể chuyển thành thuộc tính của lớp miêu tả loại thực thể đó.

3.3- Phương thức (methods):

            Phương thức định nghĩa các hoạt động mà lớp có thể thực hiện. Tất cả các đối tượng được tạo từ một lớp sẽ có chung thuộc tính và phương thức. Phương thức được sử dụng để xử lý thay đổi các thuộc tính cũng như thực hiện các công việc khác. Phương thức thường được gọi là các hàm (function), nhưng chúng nằm trong một lớp và chỉ có thể được áp dụng cho các đối tượng của lớp này. Một phương thức được miêu tả qua tên, giá trị trả về và danh sách của 0 cho tới nhiều tham số. Lúc thi hành, phương thức được gọi kèm theo một đối tượng của lớp. Vì nhóm các phương thức miêu tả những dịch vụ mà lớp có thể cung cấp nên chúng được coi là giao diện của lớp này. Giống như thuộc tính, phương thức cũng có tính trông thấy được như công cộng, riêng và bảo vệ.

Hình 4- Một lớp với các thuộc tính tiêu biểu

Hình 5- Một lớp với các thuộc tính chung và riêng

Hình 6- Một lớp với các thuộc tính và gía trị mặc nhiên

Hình 5.8- Một lớp gồm các thuộc tính với gía trị mặc nhiên và thuộc tính phạm vi lớp

Hình 7- Một thuộc tính với liệt kê gía trị (status)

3.4- Kí hiệu đối tượng:

            Đối tượng là thực thể của các lớp nên kí hiệu dùng cho đối tượng cũng là kí hiệu dùng cho lớp.

Hình 5.10-Ký hiệu đối tượng

            Hình trên được đọc như sau: CAH là đối tượng của lớp AccountHolder. Các thuộc tính được gán giá trị, đây là các giá trị khi lớp được thực thể hóa. Chú ý rằng kí hiệu đối tượng không chứa phần phương thức.

Hình 8- Các dấu hiệu hành động

Hình 9- Các giá trị mặc nhiên của tham số

4- Quan hỆ giỮa các lỚp

            Biểu đồ lớp thể hiện các lớp và các mối quan hệ giữa chúng. Quan hệ giữa các lớp gồm có bốn loại:

- Liên hệ (Association)

- Khái quát hóa (Generalization)

- Phụ thuộc (Dependency)

- Nâng cấp (Refinement)

            Một liên hệ là một sự nối kết giữa các lớp, cũng có nghĩa là sự nối kết giữa các đối tượng của các lớp này. Trong UML, một liên hệ được định nghĩa là một mối quan hệ miêu tả một tập hợp các nối kết (links), trong khi nối kết được định nghĩa là một sự liên quan về ngữ nghĩa (semantic connection) giữa một nhóm các đối tượng.

            Khái quát hóa là mối quan hệ giữa một yếu tố mang tính khái quát cao hơn và một yếu tố mang tính chuyên biệt hơn. Yếu tố mang tính chuyên biệt hơn có thể chứa chỉ các thông tin bổ sung. Một thực thể (một đối tượng là một thực thể của một lớp) của yếu tố mang tính chuyên biệt hơn có thể được sử dụng ở bất cứ nơi nào mà đối tượng mang tính khái quát hóa hơn được phép.

            Sự phụ thuộc là một mối quan hệ giữa các yếu tố, gồm một yếu tố mang tính độc lập và một yếu tố mang tính phụ thuộc. Một sự thay đổi trong yếu tố độc lập sẽ ảnh hưởng đến yếu tố phụ thuộc.

            Một sự nâng cấp là mối quan hệ giữa hai lời miêu tả của cùng một sự vật, nhưng ở những mức độ trừu tượng hóa khác nhau.

4.1  Liên hỆ (Association)

            Một liên hệ là một sự nối kết giữa các lớp, một liên quan về ngữ nghĩa giữa các đối tượng của các lớp tham gia. Liên hệ thường thường mang tính hai chiều, có nghĩa khi một đối tượng này có liên hệ với một đối tượng khác thì cả hai đối tượng này nhận thấy nhau. Một mối liên hệ biểu thị bằng các đối tượng của hai lớp có nối kết với nhau, ví dụ như  "cứ mỗi X lại có một Y", .... Lớp và liên hệ giữa các lớp là những công cụ rất mạnh mẽ cho việc mô hình hóa các hệ thống phức tạp, ví dụ như cấu trúc sản phẩm, cấu trúc văn bản và tất cả các cấu trúc thông tin khác.

Mối liên kết được thể hiện trong biểu đồ UML bằng một đường thẳng nối hai lớp.

Hình 10-Một lớp Author kết hợp với lớp Computer

4.1.1- Vai trò trong liên hệ:

            Một liên hệ có thể có các vai trò (Roles). Các vai trò được nối với mỗi lớp bao chứa trong quan hệ. Vai trò của một lớp là chức năng mà nó đảm nhận nhìn từ góc nhìn của lớp kia. Tên vai trò được viết kèm với một mũi tên chỉ từ hướng lớp chủ nhân ra, thể hiện lớp này đóng vai trò như thế nào đối với lớp mà mũi tên chỉ đến.

Hình 11- Vai trò trong liên hệ giữa Customer và Account

Trong ví dụ trên: một khách hàng có thể là chủ nhân của một tài khoản và tài khoản được chiếm giữ bởi khách hàng. Đường thẳng thể hiện liên hệ giữa hai lớp.

Một số điểm cần chú ý khi đặt tên vai trò :

- Tên vai trò có thể bỏ đi nếu trùng với tên lớp

- Tên vai trò phải là duy nhất.

- Tên vai trò phải khác với các thuộc tính của lớp.

- Tên vai trò phải miêu tả được chức năng mà lớp này đảm nhận trong quan hệ, tức cần phải là các khái niệm lấy ra từ phạm vi vấn đề, giống như tên các lớp.

4.1.2- Liên hệ một chiều (Uni-Directional Association):

            Liên hệ một chiều chỉ ra rằng sự nối kết chỉ có thể được sử dụng duy nhất theo chiều của mũi tên.

Hình 12- Liên hệ một chiều giữa Interest và Account

            Biểu đồ phần 5.15 thể hiện rằng giữa hai lớp có liên hệ, nhưng không hề có thông tin về số lượng các đối tượng trong quan hệ. Ta không thể biết một khách hàng có thể có bao nhiêu tài khoản và một tài khoản có thể là của chung cho bao nhiêu khách hàng. Trong UML, loại thông tin như thế được gọi là số lượng phần tử (Cardinality) trong quan hệ.

4.1.3- Số lượng (Cardinality) trong liên hệ:

Hình 13- Số lượng trong liên hệ giữa Customer và Account

            Biểu đồ trên nói rõ một khách hàng có thể mở một hoặc nhiều tài khoản và một tài khoản có thể thuộc về một cho tới ba khách hàng.

            Số lượng được ghi ở phía đầu đường thẳng thể hiện liên hệ, sát vào lớp là miền áp dụng của nó. Phạm vi của số lượng phần tử trong liên hệ có thể từ 0-tới-1 (0..1), 0-tới-nhiều (0..* hay ), một-tới-nhiều (1..), hai (2), năm-tới-mười một (5..11). Cũng có thể miêu tả một dãy số ví dụ (1,4,6, 8..12). Giá trị mặc định là 1.

4.1.4- Phát hiện liên hệ:

            Thường sẽ có nhiều mối liên hệ giữa các đối tượng trong một hệ thống. Quyết định liên hệ nào cần phải được thực thi là công việc thụôc giai đoạn thiết kế. Có thể tìm các mối liên hệ qua việc nghiên cứu các lời phát biểu vấn đề, các yêu cầu. Giống như danh từ đã giúp chúng ta tìm lớp, các động từ ở đây sẽ giúp ta tìm ra các mối quan hệ.

- Vị trí về mặt vật lý hoặc sự thay thế, đại diện: Mỗi cụm động từ xác định hay biểu lộ một vị trí đều là một biểu hiện chắc chắn cho liên hệ. Ví dụ: tại địa điểm, ngồi trong, …

- Sự bao chứa: Cụm động từ biểu lộ sự bao chứa, ví dụ như : là thành phần của....

- Giao tiếp: Có nhiều cụm động từ biểu lộ sự giao tiếp, ví dụ truyền thông điệp, nói chuyện với, …

- Quyền sở hữu: Ví dụ : thuộc về, của, …

- Thoả mãn một điều kiện: Những cụm từ như : làm việc cho, là chồng/vợ của, quản trị, ….

4.1.5 Liên hệ và yếu tố hạn định (Qualifier):

            Một liên hệ được hạn định liên hệ hai lớp và một yếu tố hạn định (Qualifier) với nhau. Yếu tố hạn định là một thuộc tính hạn chế số lượng thành phần tham gia trong một mối liên hệ. Có thể hạn định các mối liên hệ một-tới nhiều và nhiều-tới-nhiều. Yếu tố hạn định giúp phân biệt trong nhóm đối tượng đầu của nhiều của liên hệ.

            Ví dụ một thự mục có nhiều tập tin.Một tập tin chỉ thuộc về một thư mục mà thôi. Trong một thư mục xác định, tên của tập tin sẽ xác định duy nhất tập tin mang tên đó. Thư mục và Tập tin là hai lớp, và tên tập tin ở đây đóng vai trò yếu tố hạn định. Một thư mục và một tên tập tin xác định một tập tin. Yếu tố hạn định ở đây đã chuyển một mối liên hệ một-tới-nhiều thành liên hệ một-tới-một.

Hình 14- Liên hệ được hạn định

4.1..6. Liên hệ VÀ (AND Association)

            Ví dụ một ngân hàng  đưa ra quy định: khách hàng khi muốn mở một tài khoản ATM phải là chủ nhân của ít nhất một tài khoản đầu tư. Trong một trường hợp như thế, mối liên hệ VÀ (AND) sẽ được thể hiện như sau:

Hình 15- Liên hệ VÀ (AND Association)

            Biểu đồ trên cho thấy một khách hàng có thể có nhiều hơn một tài khoản đầu tư có thời hạn và chỉ một tài khoản ATM. Trong biểu đồ có một mối liên hệ VÀ ngầm được áp dụng giữa nhóm tài khoản đầu tư và tài khoản ATM mà một khách hàng có thể có.

4.1.7- Liên hệ HOẶC (OR Association)

            Ví dụ tại một hãng bảo hiểm quy đinh mỗi  cá nhân cũng công ty đều có thể ký hợp đồng bảo hiểm, nhưng cá nhân và công ty không được phép có cùng loại hợp đồng bảo hiểm như nhau. Trong một trường hợp như thế, giải pháp là sử dụng liên hệ HOẶC (OR Association). Một liên hệ HOẶC là một sự hạn chế đối với một nhóm hai hay nhiều liên hệ, xác định rằng đối tượng của một lớp này tại một thời điểm chỉ có thể tham gia vào nhiều nhất một trong các mối liên hệ đó.

Hình 16- Một liên hệ OR mà biểu thị chỉ một liên hệ là hợp lệ tại mỗi thời điểm

4.1.8- Liên hệ được sắp xếp (Ordered Association)

            Các mối nối kết (link) giữa các đối tượng có một trật tự ngầm định. Giá trị mặc định của trật tự này là ngẫu nhiên. Một liên hệ có trật tự rõ ràng có thể được hiểu là một liên hệ với trật tự sắp xếp (sort order) trong nhóm các nối kết, nó sẽ được thể hiện như sau:

Hình 17- Tài khoản tiết kiệm được sắp xếp theo khách hàng

Nhãn {ordered} được ghi gần lớp có đối tượng được sắp xếp. Biểu đồ trên được đọc là các tài khoản tiết kiệm được sắp xếp theo khách hàng.

4.1.9- Liên hệ tam nguyên (Ternary Association)

            Có thể có nhiều hơn hai lớp nối kết với nhau trong một liên hệ tam nguyên.

Hình 18- Liên hệ Tam nguyên

            Biểu đồ trên được đọc như sau: Một khách hàng có thể quan hệ với bộ phận đầu tư và một bộ phận đầu tư có thể có một hoặc nhiều khách hàng. Một giấy chứng nhận tài khoản đầu tư sẽ xuất hiện qua quan hệ giữa khách hàng và bộ phận đầu tư.

4.1.10- Lớp liên hệ (Association Class)

            Một lớp có thể được đính kèm theo một liên hệ, trong trường hợp này nó sẽ được gọi là một lớp liên hệ. Một lớp liên hệ không được nối tới bất kỳ một lớp nào của mối liên hệ, mà tới chính bản thân mối liên hệ. Cũng giống như một lớp bình thường, lớp liên hệ có thể có thuộc tính, Phương thức và các quan hệ khác. Lớp liên hệ được sử dụng để bổ sung thêm thông tin cho nối kết (link), ví dụ như thời điểm nối kết được thiết lập. Mỗi nối kết của liên hệ gắn liền với một đối tượng của lớp liên hệ.   

4.1.11- Liên hệ đệ quy (Recursive Association)

            Có thể liên kết một lớp với bản thân nó trong một mối liên hệ. Mối liên hệ ở đây vẫn thể hiện một sự liên quan ngữ nghĩa, nhưng các đối tượng được nối kết đều thuộc chung một lớp. Một liên hệ của một lớp với chính bản thân nó được gọi là một liên hệ đệ quy, và là nền tảng cho rất nhiều mô hình phức tạp, sử dụng ví dụ để miêu tả các cấu trúc sản phẩm. Hình 5.25 chỉ ra một ví dụ của liên hệ đệ quy và hình 5.26 là một biểu đồ đối tượng cho biểu đồ lớp trong hình 5.25.

Hình 19- Một mạng gồm nhiều nút nối với nhau.

4.1.12- Quan hệ kết tập  (Aggregation)

A- Khái niệm kết tập:

            Kết tập là một trường hợp đặc biệt của liên hệ. Kết tập biểu thị rằng quan hệ giữa các lớp dựa trên nền tảng của nguyên tắc "một tổng thể được tạo thành bởi các bộ phận". Nó được sử dụng khi chúng ta muốn tạo nên một thực thể mới bằng cách tập hợp các thực thể tồn tại với nhau. Một ví dụ tiêu biểu của kết tập là chiếc xe ô tô gồm có bốn bánh xe, một động cơ, một khung gầm, một hộp số, v.v....

            Quá trình ghép các bộ phận lại với nhau để tạo nên thực thể cần thiết được gọi là sự kết tập. Trong quá trình tìm lớp, kết tập sẽ được chú ý tới khi gặp các loại động từ “được tạo bởi", "gồm có", …. Quan hệ kết tập không có tên riêng. Tên ngầm chứa trong nó là "bao gồm các thành phần".

B- Kí hiệu kết tập:

            Kí hiệu UML cho kết tập là đường thẳng với hình thoi (diamond) đặt sát lớp biểu thị sự kết tập (tổng thể).

            Một lớp tài khoản được tạo bởi các lớp chi tiết về khách hàng, các lệnh giao dịch đối với tài khoản cũng như các quy định của nhà băng.

Quan hệ trên có thể được trình bày như sau:

Hình 20- Quan hệ kết tập (1)

            Mỗi thành phần tạo nên kết tập (tổng thể) được gọi là một bộ phận (aggregates). Mỗi bộ phận về phần nó lại có thể được tạo bởi các bộ phận khác.

Trong trường hợp tài khoản kể trên, một trong các bộ phận của nó là các chi tiết về khách hàng. Các chi tiết về khách hàng lại bao gồm danh sách chủ tài khoản, danh sách địa chỉ, các quy định về kỳ hạn cũng như các chi tiết khác khi mở tài khoản.

C- Kết tập và liên hệ:

Khái niệm kết tập nảy sinh trong tình huống một thực thể bao gồm nhiều thành phần khác nhau. Liên hệ giữa các lớp mặt khác là mối quan hệ giữa các thực thể.

Quan sát hình sau:

Hình 21- Kết tập và liên hệ

Một tài khoản được tạo bởi các chi tiết về khách hàng, các lệnh giao dịch đối với tài khoản cũng như các quy định của nhà băng. Khách hàng không phải là là bộ phận của tài khoản, nhưng có quan hệ với tài khoản.

Nhìn chung, nếu các lớp được nối kết với nhau một cách chặt chẽ qua quan hệ "toàn thể – bộ phận" thì người ta có thể coi quan hệ là kết tập. Không có lời hướng dẫn chắc chắn và rõ ràng cho việc bao giờ nên dùng kết tập và bao giờ nên dùng liên hệ. Một lối tiệm cận nhất quán đi kèm với những kiến thức sâu sắc về phạm vi vấn đề sẽ giúp nhà phân tích chọn giải pháp đúng đắn.

4.2- Khái quát hóa và chuyên biỆt hóa (Generalization & Specialization)

Hình 22- Chuyên biệt hoá (Specialization)

            Trong hình trên, tài khoản là khái niệm chung của các loại tài khoản khác nhau và chứa những đặc tả cần thiết cho tất cả các loại tài khoản. Ví dụ như nó có thể chứa số tài khoản và tên chủ tài khoản. Ta có thể có hai loại tài khoản đặc biệt suy ra từ dạng tài khoản chung này, một loại mang tính kỳ hạn và một loại mang tính giao dịch. Yếu tố chia cách hai lớp này với nhau là các quy định chuyên ngành hay đúng hơn là phương thức hoạt động của hai loại tài khoản.

            Loại cấu trúc lớp như thế được gọi là một cấu trúc hình cây hoặc cấu trúc phân cấp. Khi chúng ta dịch chuyển từ điểm xuất phát của cây xuống dưới, chúng ta sẽ gặp các khái niệm càng ngày càng được chuyên biệt hóa nhiều hơn. Theo con đường đi từ tài khoản đến tài khoản tiết kiệm, ta sẽ phải đi qua lớp tài khoản giao dịch. Lớp này tiếp tục phân loại các lớp chuyên biệt hóa cao hơn, tùy thuộc vào chức năng của chúng.

4.2.1- Kí hiệu khái quát hóa và chuyên biệt hóa

            Trong biểu đồ trên, các lớp trong một cấu trúc cây được nối với nhau bằng một mũi tên rỗng , chỉ từ lớp chuyên biệt hơn tới lớp khái quát hơn.

Hình 23- Khái quát hóa

            Quá trình bắt đầu với một lớp khái quát để sản xuất ra các lớp mang tính chuyên biệt cao hơn được gọi là quá trình chuyên biệt hoá (Specialization)

Chuyên biệt hóa: là quá trình tinh chế một lớp thành những lớp chuyên biệt hơn. Chuyên biệt hóa bổ sung thêm chi tiết và đặc tả cho lớp kết quả. Lớp mang tính khái quát được gọi là lớp cha (superclass), kết quả chuyên biệt hóa là việc tạo ra các lớp con (Subclass).

            Mặt khác, nếu chúng ta đi dọc cấu trúc cây từ dưới lên, ta sẽ gặp các lớp ngày càng mang tính khái quát cao hơn - Ví dụ từ lớp tài khoản tiết kiệm lên tới lớp tài khoản. Con đường bắt đầu từ một lớp chuyên biệt và khiến nó ngày càng mang tính khái quát cao hơn được gọi là quá trình khái quát hóa (GeneralizationChuyên biệt hóa và khái quát hóa là hai con đường khác nhau để xem xét cùng một mối quan hệ.

            Một lớp là lớp con của một lớp này có thể đóng vài trò là một lớp cha của lớp khác.

4.2.2- Lớp trừu tượng

Hình 24- Lớp trừu tượng

            Quan sát cấu trúc trong hình trên, ta thấy lớp tài khoản sẽ không bao giờ được thực thể hóa, có nghĩa là hệ thống sẽ không bao giờ tạo ra các đối tượng thuộc lớp này. Nguyên nhân là vì lớp tài khoản mang tính khái quát cao đến mức độ việc khởi tạo lớp này sẽ không có một ý nghĩa nào đáng kể. Lớp tài khoản mặc dù vậy vẫn đóng một vai trò quan trọng trong việc khái quát hóa các thuộc tính sẽ được cần đến trong các lớp dẫn xuất từ nó. Những loại lớp như thế được dùng để cung cấp một cây cấu trúc lớp và không có sự tồn tại đầy đủ ý nghĩa trong một mô hình thật sự ngoài đời, chúng được gọi là lớp trừu trượng (abstract class).

Tạo lớp trừu tượng

            Các lớp trừu trượng là kết quả của quá trình khái quát. Trong quá trình khái quát hóa, các thuộc tính được dùng chung trong các lớp chuyên biệt được đưa lên lớp cha. Lớp cha về cuối được tạo bởi các thuộc tính chung của tất cả các lớp dẫn xuất từ nó. Những lớp cha dạng như vậy trong rất nhiều trường hợp sẽ mang tính khái quát tuyệt đối và sẽ không theo đuổi mục đích khởi tạo, chúng có lối ứng xử giống như một thùng chứa (container) cho tất cả các thuộc tính chung của các lớp dẫn xuất.

Hình 25- Tạo lớp trừu tượng

4.2.3- Lớp cụ thể (concrete class)

            Lớp cụ thể là những lớp có thể thực thể hóa. Như đã nói từ trước, các lớp cụ thể khi thực thể hóa được gọi là các đối tượng. Trong ví dụ trên, các lớp tài khoản đầu tư ngắn hạn và tài khoản đầu tư dài hạn có thể được thực thể hóa thành đối tượng. Tương tự đối với tài khoản tiết kiệm và tài khoản bình thường.

4.3- Quan hỆ phỤ thuỘc và nâng cẤp (Dependency & Refinement)

            Bên cạnh liên hệ và khái quát hóa, UML còn định nghĩa hai loại quan hệ khác. Quan hệ phụ thuộc (Dependency) là một sự liên quan ngữ nghĩa giữa hai phần tử mô hình, một mang tính độc lập và một mang tính phụ thuộc. Mọi sự thay đổi trong phần tử độc lập sẽ ảnh hưởng đến phần tử phụ thuộc. Phần tử mô hình ở đây có thể là một lớp, một gói (package), một trường hợp sử dụng, .v.v...

            Ví dụ một lớp lấy tham số là đối tượng của một lớp khác, một lớp truy nhập một đối tượng toàn cục của một lớp khác, một lớp gọi một thủ tục thuộc thuộc một lớp khác. Trong tất cả các trường hợp trên đều có một sự phụ thuộc của một lớp này vào một lớp kia, mặc dù chúng không có liên hệ rõ ràng với nhau.

            Quan hệ phụ thuộc được thể hiện bằng đường thẳng gạch rời (dashed line) với mũi tên (và có thể thêm một nhãn) giữa các phần tử mô hình. Nếu sử dụng nhãn thì nó sẽ là một khuôn mẫu (stereotype), xác định loại phụ thuộc. Hình sau chỉ ra một sự phụ thuộc dạng "friend", có nghĩa rằng một phần tử mô hình nhận được quyền truy cập đặc biệt tới cấu trúc nội bộ của phần tử thứ hai (thậm chí tới cả những phần mang tính nhìn thấy là private).

Hình 26- Một quan hệ phụ thuộc giữa các lớp

            Nâng cấp (Refinement) là một quan hệ giữa hai lời miêu tả của cùng một sự vật, nhưng ở những mức độ trừu tượng hóa khác nhau. Nâng cấp có thể là mối quan hệ giữa một loại đối tượng và lớp thực hiện nó. Các nâng cấp thường gặp khác là quan hệ giữa một lớp phân tích (trong mô hình phân tích) và một lớp thiết kế (trong mô hình thiết kế) đều mô hình hóa cùng một thứ, quan hệ giữa một lời miêu tả có mức trừu tượng hóa cao và một lời miêu tả có mức trừu tượng hóa thấp (ví dụ một bức tranh khái quát của một sự cộng tác động và một biểu đồ chi tiết của cũng cộng tác đó). Quan hệ nâng cấp còn được sử dụng để mô hình hóa nhiều mức thực thi của cùng một thứ (một thực thi đơn giản và một thực thi phức tạp hơn, hiệu quả hơn).

Quan hệ nâng cấp được thể hiện bằng đường thẳng gạch rời (dashed line) với mũi tên rỗng.

Hình 27- Quan hệ nâng cấp

            Quan hệ nâng cấp được sử dụng trong việc phối hợp mô hình. Trong các dự án lớn, mọi mô hình đều cần phải được phối hợp với nhau. Phối hợp mô hình được sử dụng nhằm mục đích:

- Chỉ ra mối liên quan giữa các mô hình ở nhiều mức độ trừu tượng khác nhau.

- Chỉ ra mối liên quan giữa các mô hình ở nhiều giai đoạn khác nhau (phân tích yêu cầu, phân tích, thiết kế, thực thi, ...) .

- Hỗ trợ việc quản trị cấu hình.

- Hỗ trợ việc theo dõi trong mô hình.

5 CÁC LƯU Ý KHI XÂY DỰNG MÔ HÌNH HƯỚNG ĐỐI TƯỢNG

- Nghiên cứu để hiểu thấu đáo vấn đề cần giải quyết:

            Khi xây dựng mô hình đối tượng, không nên bắt đầu bằng cách viết ra các cấu trúc lớp, các mối liên hệ cũng như những mối quan hệ thừa kế lộ rõ trên bề mặt và đập thẳng vào mắt chúng ta. Hãy dành thời gian nghiên cứu kỹ bản chất vấn đề. Mô hình đối tượng phải được thiết kế để phù hợp với giải pháp cho vấn đề mà chúng ta nhắm tới.

- Cẩn thận khi chọn tên:

            Tên cần được chọn một cách cẩn thận bởi nó chứng nhận sự tồn tại các thực thể. Tên cần phải chính xác, ngắn gọn, tránh gây bàn cãi. Tên phải thể hiện tổng thể đối tượng chứ không chỉ nhắm tới một khía cạnh nào đó của đối tượng.

- Cần giữ cho mô hình đối tượng được đơn giản:

            Trong vòng đầu của quy trình mô hình hóa đối tượng, hãy xác định các mối liên hệ căn bản và gạt ra ngoài các chi tiết, việc xem xét tới các số lượng thành phần tham gia trong quan hệ được để dành cho giai đoạn sau; rất có thể là ở vòng thứ hai

- Nên sử dụng các mối liên hệ hạn định bất cứ khi nào có thể.

- Tránh khái quát hóa quá nhiều. Thường chỉ nên hạn chế ở ba tầng khái quát.

- Hãy nghiên cứu thật kỹ các mối liên hệ 1-tới-nhiều. Chúng thường có thể được chuyển thành các quan hệ 1-tới-0 hoặc 1-tới-1.

- Tất cả các mô hình cần phải được lấy làm đối tượng cho việc tiếp tục nâng cấp. Nếu không thực hiện những vòng nâng cấp sau đó, rất có thể mô hình của chúng ta sẽ thiếu hoàn chỉnh.

- Không nên mô hình hóa các mối liên hệ thành thuộc tính.

Việc viết tài liệu cho mô hình là vô cùng quan trọng. Các tài liệu cần phải nắm bắt thấu đáo những nguyên nhân nằm đằng sau mô hình và trình bày chúng chính xác như có thể.

6- Tóm tẮt vỀ mô hình đỐi tưỢng

            Khi tạo mô hình là chúng ta diễn giải các chi tiết về những gì mà chúng ta nghiên cứu, thế nhưng một yếu tố rất quan trọng là mô hình phải nắm bắt được những điểm trọng yếu của đối tượng nghiên cứu. Một đối tượng là một thứ gì đó mà chúng ta có thể nói về và có thể xử lý trong một số phương thức nào đó. Một đối tượng tồn tại trong thế giới thực (hoặc nói cho chính xác hơn là trong sự hiểu biết của chúng ta về thế giới thực). Một đối tượng có thể là một thành phần của một hệ thống nào đó trong thế giới – một chiếc máy, một tổ chức, một doanh nghịêp. Một lớp là lời miêu tả từ 0, 1 hoặc nhiều đối tượng với cùng lối ứng xử. Lớp và đối tượng được sử dụng để bàn luận về các hệ thống.

            Khi chúng ta mô hình hóa, chúng ta sử dụng một ngôn ngữ mô hình hóa ví dụ như UML, cung cấp cho chúng ta ngữ pháp và ngữ nghĩa để tạo dựng mô hình. Ngôn ngữ mô hình hóa mặc dù vậy không thể cho chúng ta biết liệu chúng ta đã tạo ra một mô hình tốt hay không. Chất lượng mô hình cần phải được chú ý riêng biệt, điều đó có nghĩa là tất cả các mô hình cần phải có một mục đích rõ ràng và chính xác và chúng phải nắm bắt được bản chất của đối tượng nghiên cứu. Tất cả các mô hình cần phải được làm sao để dễ giao tiếp, dễ thẩm tra, phê duyệt và bảo trì.

            UML cung cấp mô hình tĩnh, động và theo chức năng. Mô hình tĩnh được thể hiện qua các biểu đồ lớp, bao gồm các lớp và mối quan hệ giữa chúng. Quan hệ có thể là liên hệ, khái quát hoá, phụ thuộc hoặc là nâng cấp. Một mối quan hệ liên hệ là một sự nối kết giữa các lớp, có nghĩa là sự nối kết giữa các đối tượng của các lớp này. Khái quát hóa là quan hệ giữa một phần tử mang tính khái quát hơn và một phần tử mang tính chuyên biệt hơn. Phần tử mang tính chuyên biệt hơn có thể chỉ chứa các thông tin bổ sung. Một thực thể (một đối tượng là một thực thể của một lớp) của phần tử chuyên biệt hơn có thể được sử dụng bất cứ nơi nào mà thực thể của phần tử khái quát hơn được cho phép. Phụ thuộc là mối quan hệ giữa hai phần tử, một mang tính độc lập và một mang tính phụ thuộc. Mỗi thay đổi trong phần tử độc lập sẽ gây tác động đến phần tử phụ thuộc. Một quan hệ nâng cấp là một quan hệ giữa hai lời miêu tả của cùng một thứ nhưng ở những mức độ trừu tượng khác nhau.

----*****----