Định hướng mô hình hóa dữ liệu

Định hướng mô hình hóa dữ liệu
Mục tiêu học tập
Sau khi nghiên cứu chương này, bạn sẽ có thể:
•

Xác định trong các điều khoản chủ yếu sau đây: lớp, đối tượng, nhà nước, hành vi, lớp

sơ đồ, biểu đồ đối tượng, hoạt động, đóng gói, vận hành nhà xây dựng, truy vấn
hoạt động, thao tác cập nhật, đẳng cấp phạm vi hoạt động, hiệp hội, vai trò của hiệp hội,
đa dạng, lớp liên kết, lớp trừu tượng, lớp bê tông, lớp-phạm vi thuộc tính,
trừu tượng hoạt động, phương pháp, đa hình, trọng, nhiều phân loại,
tập hợp, và thành phần.
•

Mô tả các hoạt động trong các giai đoạn khác nhau của sự phát triển hướng đối tượng

vòng đời.
•
•
•

•

•
•

Nhà nước ưu điểm của mô hình vis-à-vis phương pháp tiếp cận có cấu trúc hướng đối
tượng.
Hãy so sánh các mô hình hướng đối tượng với các mô hình ER và EER.
Mô hình một miền thế giới thực bằng cách sử dụng một (UML) lớp Unified Modeling
Language

giản đồ
Cung cấp một bản chụp của nhà nước chi tiết về một hệ thống tại một thời điểm nào đó,
bằng cách sử dụng một UML
sơ đồ đối tượng.
Nhận ra khi sử dụng khái quát, tổng hợp, và các mối quan hệ thành phần.
Cụ thể các loại quy tắc kinh doanh trong một sơ đồ lớp
GIỚI THIỆU
Trong chương 2 và 3, bạn đã học về mô hình hóa dữ liệu bằng cách sử dụng ER và
Mô hình EER. Trong những chương, bạn phát hiện ra như thế nào để mô hình nhu cầu dữ
liệu của một
tổ chức sử dụng các thực thể, các thuộc tính, và một loạt các mối quan hệ. Trong này
chương, bạn sẽ được giới thiệu đến các mô hình hướng đối tượng, mà đang trở thành
ngày càng phổ biến bởi vì nó có khả năng triệt để đại diện cho phức tạp
các mối quan hệ, cũng như đại diện cho dữ liệu và hệ thống hành vi một cách nhất quán,
ký hiệu tích hợp. May mắn thay, hầu hết các khái niệm bạn đã học được trong những
chương tương ứng với khái niệm trong mô hình hướng đối tượng, nhưng objectoriented
mô hình có ý nghĩa biểu cảm nhiều quyền lực hơn so với mô hình EER.
Như bạn đã học trong Chương 2 và 3, một mô hình dữ liệu là một trừu tượng của con
người thật


thế giới. Nó cho phép bạn để đối phó với sự phức tạp vốn có trong một vấn đề thế giới
bởi
tập trung vào các tính năng cần thiết và thú vị của các dữ liệu của một tổ chức
cần. Một mô hình hướng đối tượng được xây dựng xung quanh các đối tượng, cũng giống
như các mô hình ER là
xây dựng xung quanh các thực thể. Tuy nhiên, một đối tượng đóng gói cả dữ liệu và hành
vi,
ngụ ý rằng chúng ta có thể sử dụng cách tiếp cận hướng đối tượng không chỉ để mô hình
hóa dữ liệu, nhưng cũng cho hành vi hệ thống mô hình hóa. Để mô hình hoàn toàn bất kỳ

hệ thống thế giới thực,
bạn cần mô hình cả dữ liệu và các quy trình và hành vi tác động lên
dữ liệu (nhớ lại các cuộc thảo luận ở chương 1 về các đối tượng lập kế hoạch thông tin).
By
cho phép bạn chụp chúng lại với nhau trong một biểu tượng chung, và bởi
lợi ích của lễ như kế thừa và sử dụng lại mã, các mô hình hướng đối tượng
cách tiếp cận cung cấp một môi trường mạnh mẽ cho việc phát triển các hệ thống phức
tạp.
Chu trình phát triển hệ thống hướng đối tượng, mô tả trong hình 13-1,
bao gồm dần và lặp đi lặp lại phát triển đại diện đối tượng thông qua
ba giai đoạn phân tích, thiết kế và thực hiện-tương tự như trái tim của
chu kỳ hệ thống đời phát triển giải thích trong Chương 1. Trong một phát triển lặp
mô hình, trọng tâm chuyển từ nhiều khía cạnh trừu tượng của quá trình phát triển
(Phân tích) với những cái cụ thể hơn qua các đời của một dự án. Như vậy, trong
giai đoạn đầu của sự phát triển, mô hình bạn phát triển là trừu tượng, tập trung vào
phẩm chất bên ngoài của hệ thống. Theo mô hình tiến hóa, nó trở nên ngày càng nhiều
chi tiết, trọng tâm chuyển sang cách hệ thống sẽ được xây dựng và làm thế nào cần
chức năng. Sự nhấn mạnh trong mô hình cần được phân tích, thiết kế, tập trung vào
front-end vấn đề khái niệm hơn là back-end vấn đề thực hiện mà
không cần thiết hạn chế sự lựa chọn thiết kế (Larman, 2004).
Trong giai đoạn phân tích, bạn phát triển một mô hình của một ứng dụng thực thế giới,
cho thấy
tính chất quan trọng của nó. Mô hình tóm tắt khái niệm từ các miền ứng dụng
và mô tả những gì hệ thống dự định phải làm, chứ không phải là làm thế nào nó sẽ được
thực hiện. Nó
quy định cụ thể các hành vi chức năng của các hệ thống độc lập các mối quan tâm liên
quan đến
môi trường mà nó sẽ được thực hiện cuối cùng. Bạn cần phải cống hiến
đủ thời gian để hiểu rõ yêu cầu của vấn đề, trong khi
ghi nhớ rằng trong các mô hình phát triển lặp, các hoạt động phân tích sẽ

được xem xét lại nhiều lần trong một dự án phát triển vì vậy mà bạn có thể áp dụng các
bài học kinh nghiệm từ các hoạt động thiết kế và triển khai thực hiện giai đoạn đầu để
phân tích. Xin lưu ý rằng trong các hoạt động phân tích, tập trung của bạn nên được trên
phân tích và mô hình hóa các miền trên thế giới thực sự quan tâm, không phải là nội bộ
đặc điểm của các hệ thống phần mềm.
Trong giai đoạn thiết kế hướng đối tượng, bạn xác định cách định hướng ứng dụng các
Mô hình phân tích sẽ được thực hiện trong môi trường thực hiện. Do đó, bạn


Trọng tâm sẽ chuyển sang mô hình hóa các hệ thống phần mềm, mà sẽ rất mạnh
thông báo của các mô hình mà bạn tạo ra trong hoạt động phân tích. Jacobson et al.
(1992) trích dẫn ba lý do cho việc sử dụng thiết kế hướng đối tượng:
1. Các mô hình phân tích là không đủ chính thức được thực hiện trực tiếp trong một
chương trình
ngôn ngữ. Di chuyển hoàn toàn với mã nguồn yêu cầu tinh chế
các đối tượng bằng cách làm cho các quyết định về các hoạt động gì một đối tượng sẽ
cung cấp, những gì các thông tin liên lạc giữa các đối tượng như thế nào, những gì
thông điệp được được thông qua, và vân vân.
2. Hệ thống phải được thích nghi với môi trường mà trong đó hệ thống sẽ
thực sự được thực hiện. Để thực hiện điều đó, các mô hình phân tích có được
chuyển đổi thành một mô hình thiết kế, xem xét các yếu tố khác nhau như hiệu suất
yêu cầu, yêu cầu thời gian thực và đồng thời, mục tiêu
phần cứng và phần mềm hệ thống, các DBMS và ngôn ngữ lập trình được
thông qua, và vân vân.
3. Các kết quả phân tích có thể được xác nhận bằng cách sử dụng thiết kế hướng đối
tượng. Tại đây
sân khấu, bạn có thể xác minh xem các kết quả từ phân tích phù hợp cho
xây dựng hệ thống và thực hiện bất kỳ thay đổi cần thiết để mô hình phân tích
trong phiên bản kế tiếp của chu kỳ phát triển.
Để phát triển các mô hình thiết kế, bạn phải xác định và điều tra hậu quả

rằng môi trường thực hiện sẽ có trên các thiết kế. Tất cả các thiết kế chiến lược
quyết định, chẳng hạn như làm thế nào các DBMS là được kết hợp, làm thế nào quá trình
thông tin liên lạc
và xử lý lỗi là phải đạt được, những gì thành phần thư viện sẽ được tái sử dụng,
được làm. Tiếp theo, bạn đưa ra những quyết định vào một mô hình thiết kế đầu tiên cắt
mà
thích nghi với môi trường thực hiện. Cuối cùng, bạn chính thức hóa các mô hình thiết kế
để mô tả cách các đối tượng tương tác với nhau cho mỗi kịch bản có thể tưởng tượng.
Trong mỗi lần lặp, các hoạt động thiết kế được thực hiện tiếp theo
hoạt động (ví dụ, thực hiện thiết kế bằng cách sử dụng một ngôn ngữ lập trình và / hoặc
một
hệ thống quản lý cơ sở dữ liệu). Nếu các thiết kế đã được thực hiện tốt, dịch nó thành
mã chương trình là một quá trình tương đối đơn giản, cho rằng các mô hình thiết kế
đã kết hợp các sắc thái của ngôn ngữ lập trình và các DBMS.
Coad và Yourdon (1991) xác định một số động cơ và lợi ích của objectoriented
mô hình:
• Khả năng giải quyết vấn đề khó khăn hơn các lĩnh vực
• Cải thiện giao tiếp giữa người sử dụng, các nhà phân tích, thiết kế, lập trình và
• Tăng thống nhất giữa các phân tích, hoạt động thiết kế và lập trình
• đại diện Explicit tương đồng giữa các thành phần hệ thống
• tính mạnh mẽ của hệ thống
• Có thể dùng lại các phân tích, thiết kế, lập trình và kết quả
• Tăng tính nhất quán trong tất cả các mô hình phát triển trong quá trình hướng đối tượng
phân tích, thiết kế, lập trình
Điểm cuối cùng cần chi tiết hơn. Trong tiếp cận mô hình khác, chẳng hạn như


phân tích cấu trúc và thiết kế (mô tả trong Chương 1), các mô hình đó là
phát triển thiếu một đại diện cơ bản phổ biến và, do đó, rất yếu ớt
kết nối. Ví dụ, không có cũng được xác định cấu trúc khái niệm cơ bản

sơ đồ liên kết các luồng dữ liệu được sử dụng để phân tích cấu trúc và biểu đồ được sử
dụng cho thiết kế trong
phân tích cấu trúc truyền thống và thiết kế. Trái ngược với sự đột ngột và tách rời
chuyển tiếp mà các phương pháp tiếp cận trước đó bị, các phương pháp tiếp cận hướng
đối tượng
cung cấp một sự liên tục của các đại diện từ các phân tích để thiết kế đến thực hiện,
lồng ghép một quá trình chuyển đổi liền mạch từ một mô hình khác. Ví dụ, các
hướng đối tượng mô hình phân tích thường được sử dụng gần như trực tiếp như là một
nền tảng cho các
hướng đối tượng mô hình thiết kế thay vì phát triển một đại diện hoàn toàn mới.
Trong chương này, chúng tôi trình bày mô hình dữ liệu hướng đối tượng như là một cấp
cao
hoạt động khái niệm. Như bạn sẽ được học trong Chương 14, một mô hình khái niệm tốt
là
vô giá cho việc thiết kế và thực hiện một ứng dụng hướng đối tượng sử dụng
một cơ sở dữ liệu quan hệ để cung cấp bền vững cho các đối tượng
UNIFIED MODELING LANGUAGE

Unified Modeling Language (UML) là một tập hợp các ký hiệu đồ họa được hỗ trợ bởi một phổ
biến
metamodel được sử dụng rộng rãi cho cả hai mô hình kinh doanh và để xác định, thiết kế,
và thực hiện các hệ thống phần mềm hiện vật. Nó lên đến đỉnh điểm từ những nỗ lực của ba hàng
đầu
các chuyên gia, Grady Booch, Ivar Jacobson, và James Rumbaugh, người được xác định này
objectoriented
ngôn ngữ mô hình mà đã trở thành một tiêu chuẩn công nghiệp. UML được xây dựng dựa và
thống nhất các ngữ nghĩa và ký hiệu của Booch (Booch, 1994), OOSE (Jacobson et al., 1992), và
OMT (Rumbaugh et al., 1991) phương pháp, cũng như những phương pháp hàng đầu khác.
UML gần đây đã được cập nhật để UML 2.2, duy trì bởi Tập đoàn Quản lý đối tượng.
UML ký hiệu là hữu ích cho các đồ họa miêu tả một phân tích hướng đối tượng, thiết kế

mô hình. Nó không chỉ cho phép bạn xác định các yêu cầu của hệ thống và nắm bắt được
quyết định thiết kế, nó cũng thúc đẩy sự giao tiếp giữa những người chủ chốt tham gia
nỗ lực phát triển. Một nhà phát triển có thể sử dụng một phân tích, thiết kế mô hình thể hiện
trong UML
ký hiệu như một phương tiện để giao tiếp với các chuyên gia tên miền, người dùng, và các bên
liên quan khác.


Cho đại diện cho một hệ thống phức tạp một cách hiệu quả, mô hình phát triển phải bao gồm bạn
một tập hợp các quan điểm độc lập hoặc phối cảnh. UML cho phép bạn đại diện cho nhiều
quan điểm của một hệ thống bằng cách cung cấp các loại khác nhau của sơ đồ đồ họa, chẳng hạn
như
sử dụng hợp sơ đồ, biểu đồ lớp, sơ đồ nhà nước, trình tự sơ đồ, biểu đồ thành phần,
và sơ đồ triển khai. Nếu các biểu đồ này được sử dụng một cách chính xác với nhau trong bối
cảnh
một quá trình làm mẫu cũng xác định, UML cho phép bạn phân tích, thiết kế và thực hiện một
Hệ thống dựa trên một mô hình khái niệm phù hợp
Bởi vì văn bản này là về cơ sở dữ liệu, chúng tôi sẽ chỉ mô tả sơ đồ lớp, mà
là một trong những sơ đồ tĩnh trong UML, giải quyết các đặc điểm chủ yếu về cấu trúc
các lĩnh vực quan tâm. Sơ đồ lớp cho phép chúng tôi cũng nắm bắt được trách nhiệm
rằng các lớp học có thể thực hiện, mà không có bất kỳ chi tiết cụ thể của hành vi. Chúng tôi sẽ
không
mô tả các loại biểu đồ khác bởi vì họ cung cấp các quan điểm mà không trực tiếp
liên quan đến một hệ thống cơ sở dữ liệu. Hãy nhớ rằng một hệ thống cơ sở dữ liệu thường là
một phần của một
hệ thống tổng thể, mà cơ bản mô hình nên bao gồm tất cả các quan điểm khác nhau.
Đối với một cuộc thảo luận về sơ đồ UML khác, xem Hoffer et al. (2010) và George et al.
(2007). Điều quan trọng cần lưu ý là các sơ đồ lớp UML có thể được sử dụng cho nhiều
mục đích ở các giai đoạn khác nhau của các mô hình vòng đời.
OBJECT-ORIENTED DATA MODELING

Trong phần này, chúng tôi giới thiệu mô hình dữ liệu bạn hướng đối tượng. Chúng tôi mô tả
khái niệm chính và kỹ thuật liên quan trong mô hình hướng đối tượng, bao gồm cả đối tượng
và các lớp học; đóng gói các thuộc tính và các hoạt động; hiệp hội, tổng quát, và
mối quan hệ kết tập; cardinalities và các loại khác của các ràng buộc; đa hình;
và thừa kế. Chúng tôi cho thấy làm thế nào bạn có thể phát triển sơ đồ lớp, sử dụng các ký hiệu
UML,
để cung cấp một cái nhìn khái niệm của hệ thống được mô hình hóa

Representing Objects and Classes


Trong cách tiếp cận hướng đối tượng, chúng ta mô hình thế giới trong các đối tượng. Trước khi
áp dụng
Phương pháp cho một vấn đề thực tế, do đó, chúng ta cần phải hiểu những gì một đối tượng
thực sự là. Một lớp là một loại thực thể có một vai trò được xác định rõ trong miền ứng dụng
về mà tổ chức mong muốn duy trì trạng thái, hành vi và nhận dạng. Một lớp là
một khái niệm, một sự trừu tượng, hoặc một điều có ý nghĩa trong bối cảnh ứng dụng (Blaha
và Rumbaugh, 2005). Một lớp học có thể đại diện cho một loại thực thể hữu hình hay nhìn thấy
được (ví dụ, một
người, địa điểm, hoặc điều); nó có thể là một khái niệm hay một sự kiện (ví dụ, Sở, Hiệu suất,
Hôn nhân, đăng ký, vv); hoặc nó có thể là một tạo tác của quá trình thiết kế (ví dụ, tài
Giao diện, điều khiển, Scheduler, vv). Một đối tượng là một thể hiện của một lớp học (ví dụ, một
cụ thể
người, địa điểm, hoặc điều) mà đóng gói dữ liệu và hành vi của chúng ta cần phải duy trì
về đối tượng đó. Một lớp học của các đối tượng chia sẻ một tập hợp chung các thuộc tính và
hành vi.
Bạn có thể tự hỏi làm thế nào các lớp học và các đối tượng khác nhau từ các loại thực thể
và trường hợp thực thể trong mô hình ER và EER bạn nghiên cứu trong Chương 2 và 3.
Rõ ràng, các loại thực thể trong mô hình ER có thể được biểu diễn như là các lớp học và các

trường hợp thực thể
như các đối tượng trong mô hình đối tượng. Tuy nhiên, ngoài việc lưu trữ các trạng thái (thông
tin), một đối tượng
cũng thể hiện hành vi, thông qua các hoạt động có thể kiểm tra hoặc ảnh hưởng đến trạng thái
của nó.
Các trạng thái của một đối tượng bao gồm các thuộc tính của nó (thuộc tính và mối quan hệ) và
các giá trị những tài sản có, và hành vi của nó đại diện cho bao một hành vi đối tượng
và phản ứng (Booch, 1994). Như vậy, nhà nước của một đối tượng được xác định bởi các giá trị
thuộc tính của nó và
liên kết với các đối tượng khác. Hành vi của một đối tượng phụ thuộc vào trạng thái của nó và
các hoạt động được
thực hiện. Một hoạt động đơn giản chỉ là một hành động mà một đối tượng thực hiện để cung cấp
cho một


đáp ứng yêu cầu. Bạn có thể nghĩ về một hoạt động như một dịch vụ được cung cấp bởi một đối
tượng
(nhà cung cấp) cho các khách hàng của mình. Một khách hàng gửi tin nhắn đến một nhà cung
cấp, trong đó cung cấp các
dịch vụ mong muốn bằng cách thực hiện các hoạt động tương ứng.
Hãy xem xét một ví dụ của lớp sinh viên và một đối tượng cụ thể trong lớp này, Mary
Jones. Các trạng thái của đối tượng này được đặc trưng bởi các thuộc tính của nó, nói, tên, ngày
tháng năm sinh, năm,
địa chỉ, và số điện thoại, và các giá trị các thuộc tính hiện có. Ví dụ, tên là
"Mary Jones," năm nay là "đàn em", và như vậy. Hành vi của đối tượng được thể hiện qua
các hoạt động như calcGpa, được sử dụng để tính toán hiện tại điểm trung bình của học sinh.
Các đối tượng Mary Jones, do đó, gói trạng thái của nó và hành vi của mình với nhau.
Mỗi đối tượng có một bản sắc dai dẳng; đó là, không có hai đối tượng đều giống nhau. Đối với
Ví dụ, nếu có hai trường hợp sinh viên với cùng một giá trị của một thuộc tính định danh,
họ vẫn là hai đối tượng khác nhau. Ngay cả khi hai trường hợp có giá trị giống hệt nhau cho

tất cả các thuộc tính xác định của các đối tượng, các đối tượng duy trì bản sắc riêng biệt của họ.
Đồng thời, một đối tượng duy trì bản sắc riêng của mình trên cuộc sống của mình. Ví dụ, nếu
Mary
Jones kết hôn và, do đó, các giá trị của các thuộc tính tên, địa chỉ, và số điện thoại
thay đổi cho cô ấy, cô ấy sẽ vẫn được biểu diễn bởi cùng một đối tượng.
Bạn có thể miêu tả các lớp học đồ họa trong một sơ đồ lớp như trong hình 13-2a. Một lớp học
Biểu đồ cho thấy cấu trúc tĩnh của một mô hình hướng đối tượng: các lớp học, nội bộ của họ
cấu trúc, và các mối quan hệ mà họ tham gia. Trong UML, một lớp được biểu diễn
bằng một hình chữ nhật với ba ngăn cách nhau bởi các đường ngang. Tên lớp
xuất hiện trong các ngăn trên cùng, danh sách các thuộc tính trong khoang giữa, và
danh sách các hoạt động trong các ngăn dưới cùng của một hộp. Con số này cho thấy hai lớp,
Sinh viên và học, cùng với các thuộc tính và các hoạt động của họ.
Các lớp học của sinh viên là một nhóm đối tượng sinh viên có chung một cấu trúc chung và một
hành vi phổ biến. Tất cả học sinh đều có chung các thuộc tính của tên, DateOfBirth, năm,
địa chỉ, và số điện thoại. Họ cũng thể hiện hành vi phổ biến bằng cách chia sẻ calcAge, calcGpa,


và registerFor (tất nhiên) hoạt động. Một lớp học, do đó, cung cấp một mẫu hoặc giản đồ cho nó
trường hợp. Mỗi đối tượng biết để mà lớp nó thuộc; Ví dụ, đối tượng Mary Jones
biết rằng nó thuộc về các lớp sinh viên. Đối tượng thuộc các lớp học tương tự cũng có thể tham
gia
trong mối quan hệ tương tự với các đối tượng khác; Ví dụ, tất cả các sinh viên đăng ký
các khóa học và, do đó, các lớp sinh viên có thể tham gia vào một mối quan hệ được gọi là thanh
ghi Ví
với một lớp được gọi là Course (xem phần sau hiệp hội).
Một sơ đồ đối tượng, cũng được biết đến như một sơ đồ ví dụ, là một đồ thị của trường đó
tương thích với một sơ đồ lớp cho trước. Trong hình 13-2b, chúng tôi đã thể hiện một đối tượng
sơ đồ với hai trường hợp, một cho mỗi của hai lớp mà xuất hiện trong hình 13-2a
Một sơ đồ đối tượng tĩnh, như thể hiện trong hình, là một thể hiện của một lớp
sơ đồ, cung cấp một bản chụp của nhà nước chi tiết về một hệ thống tại một thời điểm.

Trong một sơ đồ đối tượng, một đối tượng được biểu diễn như là một hình chữ nhật với hai ngăn.
Tên của các đối tượng và các lớp học đang được gạch dưới và thể hiện trong các khoang trên
bằng cách sử dụng cú pháp sau:
objectname : classname
Các thuộc tính của đối tượng và giá trị của chúng được thể hiện trong ngăn thứ hai. Đối với
Ví dụ, chúng ta có một đối tượng tên là Mary Jones mà thuộc về các lớp sinh viên. Các giá trị
của tên, DateOfBirth, và các thuộc tính trong năm cũng được hiển thị. Các thuộc tính có giá trị là
không quan tâm đến bạn có thể bị ức chế; Ví dụ, chúng tôi đã không được hiển thị địa chỉ và
thuộc tính điện thoại cho Mary Jones. Nếu không có các thuộc tính được quan tâm, toàn bộ thứ hai
khoang có thể bị ức chế. Tên của đối tượng cũng có thể được bỏ qua, trong trường hợp này
đại tràng nên được giữ với tên lớp là chúng tôi đã thực hiện với sự thể hiện của khóa học. Nếu
tên của các đối tượng được hiển thị, tên lớp, cùng với đại tràng, có thể bị ức chế.
Giấy phép mô hình đối tượng đa giá trị, composite, nguồn gốc, và các loại khác
thuộc tính. Các ký hiệu điển hình là để mở đầu cho tên thuộc tính với một biểu tượng khuôn mẫu
cho biết tài sản của mình (ví dụ, << >> multivalued cho một thuộc tính đa trị). Cho composite
thuộc tính, hỗn hợp được định nghĩa như là một lớp riêng biệt và sau đó bất kỳ thuộc tính với


rằng cấu trúc phức hợp được định nghĩa là một kiểu dữ liệu của lớp composite. Ví dụ như,
cũng như chúng ta xác định các lớp sinh viên, chúng ta có thể định nghĩa một lớp được gọi là Địa chỉ đó
là sáng tác
các thuộc tính đường phố, thành phố, tiểu bang, và zip. Sau đó, trong hình 13-2a, nếu thuộc tính địa chỉ
là một thuộc tính tổng hợp như vậy, chúng tôi sẽ thay thế các dòng thuộc tính địa chỉ trong
Class Student với, ví dụ,
stuAddress : Address

mà chỉ ra rằng các thuộc tính stuAddress là các loại Địa chỉ. Đây là một mạnh mẽ
Tính năng của các mô hình đối tượng, trong đó chúng ta có thể sử dụng lại các cấu trúc được
định nghĩa trước.
Một hoạt động, chẳng hạn như calcGpa trong Student (xem hình 13-2a), là một chức năng hoặc

một
dịch vụ được cung cấp bởi tất cả các trường hợp của một lớp. Thông thường, các đối tượng khác
có thể truy cập
hay thao tác các thông tin được lưu trữ trong một đối tượng chỉ thông qua các hoạt động đó.
Các hoạt động, do đó, cung cấp một giao diện bên ngoài một lớp; giao diện trình bày
nhìn bên ngoài của lớp mà không hiển thị cấu trúc nội bộ của mình hoặc cách hoạt động của nó
là
triển khai thực hiện. Kỹ thuật này trong việc ẩn các chi tiết thực hiện nội bộ của một đối tượng
từ quan điểm bên ngoài của nó được biết đến như đóng gói, hoặc ẩn thông tin. Vì vậy, mặc dù
chúng tôi
cung cấp các khái niệm trừu tượng của hành vi phổ biến cho tất cả các trường hợp của một lớp
trong giao diện của nó,
chúng tôi gói gọn trong lớp cấu trúc của nó và những bí mật của các hành vi mong muốn.
Types of Operations
Hoạt động có thể được phân thành bốn loại, tùy thuộc vào loại dịch vụ yêu cầu
bởi khách hàng: (1) xây dựng, (2) truy vấn, (3) cập nhật, và (4) đẳng cấp phạm vi (UML
Notation
Hướng dẫn, 2003). Một hoạt động xây dựng tạo ra một thể hiện mới của một lớp. Ví dụ, bạn
có thể có một hoạt động được gọi là học sinh sinh viên trong đó tạo ra một sinh viên mới và khởi
tạo
trạng thái của nó. Hoạt động xây dựng như vậy có sẵn cho tất cả các lớp học và do đó


không được hiển thị một cách rõ ràng trong sơ đồ lớp.
Một hoạt động truy vấn là một hoạt động mà không có bất kỳ tác dụng phụ; nó truy cập vào
trạng thái
một đối tượng nhưng không làm thay đổi trạng thái (Fowler, 2003). Ví dụ, các lớp sinh viên có
thể
có một hoạt động được gọi là getYear (không hiển thị), mà chỉ đơn giản lấy năm (sinh viên năm
nhất,

thứ hai, cơ sở, hay cao cấp) của các đối tượng sinh viên quy định tại các truy vấn. Chú ý
mà không cần phải hiển thị rõ ràng một truy vấn như getYear trong sơ đồ lớp
vì nó lấy giá trị của một thuộc tính cơ sở độc lập. Xem xét, tuy nhiên,
hoạt động calcAge trong sinh viên. Đây cũng là một hoạt động truy vấn vì nó không
có bất kỳ tác dụng phụ. Lưu ý rằng đối số duy nhất cho truy vấn này là các sinh viên mục tiêu
Vật. Một truy vấn như vậy có thể được biểu diễn như là một thuộc tính có nguồn gốc (Blaha và
Rumbaugh,
2005); Ví dụ, chúng ta có thể đại diện cho "tuổi" như một thuộc tính có nguồn gốc từ sinh viên.
Bởi vìcác đối tượng mục tiêu luôn luôn là một đối số tiềm ẩn của một hoạt động, không có nhu
cầu
thể hiện điều đó một cách rõ ràng trong tuyên bố hoạt động. Trong tiêu chuẩn hướng đối tượng
ngữ lập trình, các phương pháp được sử dụng để đạt được quyền truy cập đọc đến một giá trị của
thuộc tính nội bộ của một đối tượng được gọi là phương pháp getter, và họ thuộc về thể loại
các phương pháp accessor.
Một cập nhật hoạt động làm thay đổi trạng thái của một đối tượng. Ví dụ, hãy xem xét một hoạt
động
của sinh viên gọi là promoteStudent (không hiển thị). Các hoạt động khuyến khích học sinh sang
mới
năm, nói, từ cơ sở đến cấp cao, do đó làm thay đổi trạng thái của đối tượng sinh viên (giá trị của
năm thuộc tính). Một ví dụ khác của một hoạt động cập nhật là registerFor (tất nhiên), trong đó,
khi được gọi, có hiệu lực của việc thiết lập một kết nối từ một đối tượng sinh viên đến một cụ
Đối tượng Course. Lưu ý rằng, ngoài việc có các đối tượng mục tiêu sinh viên như một tham số
ngầm,
các hoạt động có một lập luận rõ ràng được gọi là "Dĩ nhiên," trong đó xác định khóa học
mà sinh viên muốn đăng ký. Lập luận rõ ràng được hiển thị trong dấu ngoặc đơn.


Một lần nữa, trong thuật ngữ lập trình hướng đối tượng tiêu chuẩn, các phương pháp được sử
dụng
để thay đổi giá trị của thuộc tính nội bộ của một đối tượng được gọi là setter, hoặc mutator,

phương pháp.
Một hoạt động đẳng cấp phạm vi là một hoạt động mà áp dụng cho một lớp học chứ không phải
là một đối tượng
dụ. Ví dụ, avgGpa cho lớp học sinh (không được hiển thị với các hoạt động khác
cho lớp này trong hình 13-2a) tính trung bình cộng điểm trung bình trên tất cả các học sinh.
(Tên hoạt động được nhấn mạnh để cho biết rằng nó là một hoạt động phạm vi.) Trong hướng
đối tượng
lập trình, đẳng cấp phạm vi hoạt động được thực hiện với phương pháp lớp học
Representing Associations
Song song với việc định nghĩa một mối quan hệ đối với các mô hình ER, một hiệp hội là một
mối quan hệ có tên
giữa hai hoặc nhiều trường hợp các lớp đối tượng. Như trong mô hình E-R, mức độ
một mối quan hệ liên kết có thể là một (nhất nguyên), hai (nhị phân), ba (bậc ba), hoặc cao hơn
(n-ary). Trong hình 13-3, chúng tôi sử dụng các ví dụ từ Hình 2-12 để minh họa cho việc
objectoriented
mô hình có thể được sử dụng để đại diện cho các mối quan hệ liên quan giữa mức độ khác nhau.
An
Hiệp hội được thể hiện là một đường liền giữa các lớp tham gia. Sự kết thúc của một hiệp hội
nơi kết nối với một lớp được gọi là một vai trò hiệp hội (Rumbaugh et al., 2004). Mỗi
hiệp hội có hai hoặc nhiều vai trò. Một vai trò có thể được đặt tên một cách rõ ràng với một nhãn
gần cuối
của một hiệp hội (xem phần "quản lý" vai trò trong hình 13-3a). Tên vai trò chỉ ra vai trò
chơi bởi các lớp thuộc gần kết thúc mà tên xuất hiện. Sử dụng tên vai trò là
tùy chọn. Bạn có thể chỉ định tên vai trò thay, hoặc thêm vào, một tên hiệp hội.
Hình 13-3a cho thấy hai mối quan hệ nhất nguyên, là Married To và Quản lý. Ở một đầu
Quản lý mối quan hệ của chúng tôi đã đặt tên cho vai trò "quản lý", ngụ ý rằng một
nhân viên có thể đóng vai trò của một người quản lý. Chúng tôi đã không có tên các vai trò khác,
nhưng chúng tôi có
tên các hiệp hội. Khi tên vai trò không xuất hiện, bạn có thể nghĩ về vai trò

đặt tên như là của lớp gắn vào đó (Fowler, 2003). Ví dụ, vai trò cho
cuối bên phải của các mối quan hệ là Assigned trong hình 13-3b có thể được gọi là nơi đậu xe.
Mỗi vai diễn có một đa dạng, trong đó cho biết số lượng các đối tượng tham gia
trong một mối quan hệ nhất định. Trong một sơ đồ lớp, một đặc điểm kỹ thuật đa dạng được thể
hiện như
một chuỗi văn bản đại diện cho một khoảng thời gian (hoặc khoảng thời gian) của các số nguyên
trong các định dạng sau:
lower-bound..upper-bound

Khoảng thời gian được coi là đóng cửa, có nghĩa là phạm vi bao gồm cả
thấp hơn và cận trên. Ví dụ, một đa dạng của 2..5 biểu thị rằng tối thiểu
hai và tối đa là năm đối tượng có thể tham gia vào một mối quan hệ nhất định.
Multiplicities, do đó, chỉ đơn giản là hạn chế cardinality (thảo luận trong Chương 2). trong
Ngoài các giá trị số nguyên, các ràng buộc trên của một đa dạng có thể là một nhân vật ngôi sao
(*),
biểu thị một vô hạn ràng buộc trên. Nếu một giá trị số nguyên duy nhất là quy định, nó có nghĩa
là
rằng phạm vi chỉ bao gồm giá trị đó.
Các multiplicities phổ biến nhất, trong thực tế, là 0..1, *, và 1. 0..1 multiplicity
chỉ tối thiểu là zero và tối đa là một (tùy chọn một), trong khi đó *
(hoặc tương đương, 0 .. *) đại diện cho các phạm vi từ số không đến vô cùng (tùy chọn nhiều).
Một đơn 1 khán đài cho 1..1, ngụ ý rằng chính xác một đối tượng tham gia vào mối quan hệ
(một bắt buộc).

13.8
Các multiplicities cho cả hai vai trò trong mối quan hệ Is Married Để là 0..1, chỉ ra
rằng một người có thể là duy nhất hoặc kết hôn với một người. Sự đa dạng cho người quản lý
vai trò trong việc Quản lý mối quan hệ là 0..1 và đối với các vai trò khác là *, ngụ ý rằng một
nhân viên có thể được quản lý bởi chỉ một người quản lý, nhưng một người quản lý có thể quản

lý nhiều
nhân viên.
Hình 13-3b cho thấy mối quan hệ nhị phân ba: Sản phẩm được chỉ định (one-to-one), Có


(one-to-many), và Registers Đối (many-to-many). Một sự kết hợp nhị phân là vốn
hai chiều, mặc dù trong một sơ đồ lớp, tên hiệp hội có thể được đọc chỉ có một
hướng. Ví dụ, các hiệp hội Chứa được đọc từ dòng sản phẩm để sản phẩm.
(Lưu ý: Như trong ví dụ này, bạn có thể hiển thị một cách rõ ràng hướng bằng cách sử dụng một
hình tam giác rắn
bên cạnh tên hiệp hội.) Tiềm ẩn, tuy nhiên, là một traversal nghịch đảo của Contains
nói, Thuộc Để, mà biểu thị rằng một sản phẩm thuộc về một dòng sản phẩm cụ thể. Cả hai
hướng của traversal tham khảo các hiệp hội cơ bản giống nhau; tên đơn giản
thiết lập một hướng. Các sơ đồ cho các mối quan hệ Is Assigned cho thấy một
nhân viên được giao một chỗ đậu xe hoặc không được giao một lúc tất cả (tùy chọn một). Cách
đọc
theo một hướng khác, chúng ta nói rằng một chỗ đậu xe có thể được giao cho một đơn
nhân viên hoặc không được phân bổ ở tất cả (tùy chọn một lần nữa). Tương tự như vậy, chúng ta
nói rằng một sản phẩm
dòng có chứa rất nhiều các sản phẩm, nhưng ít nhất một, trong khi một sản phẩm nhất định thuộc
về
đúng một dòng sản phẩm (một bắt buộc). Các sơ đồ cho các hiệp hội nhị phân thứ ba
nói rằng một học sinh đăng ký cho nhiều khóa học, nhưng nó có thể là anh ta hoặc cô ấy
không đăng ký ở tất cả, và tất nhiên có không, một, hoặc nhiều sinh viên theo học trong đó
(tùy chọn nhiều trong cả hai hướng).
Trong hình 13-3c, chúng tôi cho thấy một mối quan hệ tam phân được gọi là Supplies giữa người
bán hàng,
Phần, và Warehouse. Như trong sơ đồ ER, chúng tôi đại diện cho một mối quan hệ tam phân sử
dụng
một biểu tượng kim cương và đặt tên của các mối quan hệ đó. Các mối quan hệ là

nhiều-nhiều-nhiều, và, như đã thảo luận ở Chương 2, nó không thể được thay thế bằng ba
mối quan hệ nhị phân mà không mất thông tin.
Sơ đồ lớp trong hình 13-4a lãm hiệp hội nhị phân giữa giảng viên và
Giảng viên, giữa học và khóa học chào, giữa giảng viên và học chào,
và giữa Khoa và Khóa học chào. Biểu đồ cho thấy rằng một học sinh có thể có


một cố vấn, trong khi một giảng viên có thể tư vấn cho đến tối đa là 10 học sinh.
Ngoài ra, mặc dù một khóa học có thể có nhiều lễ vật, một khóa học nhất định được dự kiến
cho chính xác một môn học.
Hình 13-4a cũng cho thấy một giảng viên đóng vai trò của một giảng viên, như
cũng như vai trò của một cố vấn. Trong khi đó, vai trò cố vấn xác định các đối tượng Khoa
liên kết với một đối tượng sinh viên, vai trò advisee xác định tập các đối tượng sinh viên
liên kết với một đối tượng khoa. Chúng ta có thể đặt tên là hiệp hội, nói, Cố vấn,
nhưng, trong trường hợp này, các tên vai trò là đầy đủ ý nghĩa để chuyển tải ý nghĩa của
mối quan hệ.
Hình 13-4b cho thấy một sơ đồ lớp cho một đơn đặt hàng. Tương ứng
sơ đồ đối tượng được trình bày trong hình 13-5; nó cho thấy một số các trường hợp của
các lớp học và các liên kết giữa chúng. (Lưu ý: Cũng như một ví dụ tương ứng với một lớp, một
liên kết tương ứng với một mối quan hệ.) Trong ví dụ này, chúng ta thấy các đơn đặt hàng của
hai
khách hàng, Joe và Jane. Joe đã đặt hai đơn đặt hàng, Ord20 và Ord56. Trong Ord20, Joe có
ra lệnh P93 sản phẩm từ dòng sản phẩm thể thao. Trong Ord56, ông đã ra lệnh cho cùng
thể thao sản phẩm một lần nữa, cũng như P50 sản phẩm từ dòng sản phẩm phần cứng. thông báo
mà Jane đã ra lệnh cho các sản phẩm phần cứng như Joe có, ngoài hai khác
sản phẩm (P9 và P10) từ dòng mỹ phẩm sản phẩm.

Representing Association Classes
Khi một hiệp hội tự nó có thuộc tính hoặc các hoạt động của riêng mình, hoặc khi nó tham gia
trong mối quan hệ với các lớp khác, nó rất hữu ích để mô hình hiệp hội như một hiệp hội

lớp (giống như chúng ta sử dụng một "thực thể kết hợp" trong Chương 2). Ví dụ, trong hình 136a,
thời hạn và số lớp thuộc tính thực sự thuộc về nhiều-nhiều mối liên hệ giữa
Sinh viên và học. Các lớp của một sinh viên cho một khóa học không thể được xác định trừ khi
cả học sinh và các khóa học được biết đến. Tương tự như vậy, để tìm các thuật ngữ (s) trong đó
sinh viên tham gia khoá học, cả học sinh và tất nhiên phải được biết. các checkEligibility
hoạt động, trong đó xác định xem một học sinh có đủ điều kiện để đăng ký một khóa học,


cũng thuộc về hiệp hội, chứ không phải bất kỳ của hai lớp tham gia. Chúng tôi
cũng đã nắm bắt được thực tế rằng, đối với một số đăng ký tất nhiên, một tài khoản máy tính là
cấp cho học sinh. Đối với những lý do này, chúng tôi mô hình đăng ký như là một lớp liên kết,
có thiết lập riêng của mình các tính năng và một hiệp hội với các lớp khác (Computer Account).
Tương tự như vậy, đối với các hiệp hội Tutors nhất nguyên, beginDate và numberOfHrs (số
giờ dạy kèm) thực sự nằm trong hiệp hội, và, do đó, xuất hiện trong một riêng biệt
lớp liên kết.
Bạn có tùy chọn hiển thị tên của một lớp liên kết vào hiệp hội
đường dẫn, hoặc biểu tượng lớp, hoặc cả hai. Khi một hiệp hội đã chỉ thuộc tính, nhưng không
có bất cứ hoạt động hoặc không tham gia vào các hiệp hội khác, các đề nghị
lựa chọn là để hiển thị tên trên con đường hiệp hội, nhưng để bỏ qua nó từ hiệp hội
biểu tượng lớp, để nhấn mạnh "tính chất hiệp hội" của nó (UML Notation Guide, 2003). Đó là
làm thế nào chúng tôi đã chỉ ra mối liên Tutors. Mặt khác, chúng tôi đã hiển thị các
Tên của hiệp hội đó đăng ký có hai thuộc tính và một hoạt động của nó
riêng, cũng như một hiệp hội gọi là vấn đề với máy tính Account-trong lớp
hình chữ nhật để nhấn mạnh của nó "bản chất giai cấp."
Hình 13-6b cho thấy một phần của sơ đồ đối tượng đại diện cho một học sinh, Mary
Jones, và các khóa học, cô đã đăng ký trong thời hạn Fall 2010: MKT350 và MIS385.
Tương ứng với một lớp liên kết trong một sơ đồ lớp, các đối tượng liên kết có trong một
sơ đồ đối tượng. Trong ví dụ này, có hai đối tượng liên kết (hiển thị như: đăng ký) cho
các lớp liên kết Đăng ký, chụp hai đăng ký khóa học. Sơ đồ
cũng cho thấy rằng đối với quá trình MIS385, Mary Jones đã được cấp một tài khoản máy tính

với một ID, mật khẩu, và một số lượng chỉ định của không gian trên máy chủ. Cô vẫn còn có
không nhận được một lớp cho khóa học này, nhưng, đối với quá trình MKT350, cô đã nhận được
các lớp
W vì cô đã rút khỏi khóa học.
Hình 13-7 cho thấy một mối quan hệ bậc ba trong số các sinh viên, phần mềm, và khóa học
lớp học. Nó nắm bắt thực tế là học sinh sử dụng các công cụ phần mềm khác nhau cho các khóa
học khác nhau.


Ví dụ, chúng ta có thể lưu trữ các thông tin mà Mary Jones sử dụng Microsoft Access và
Oracle cho quá trình quản lý cơ sở dữ liệu, Microsoft Visio cho Object-Oriented
Mô hình hóa quá trình, và Eclipse cho quá trình phát triển ứng dụng. Bây giờ giả sử
chúng ta muốn ước tính số giờ mỗi tuần Mary sẽ chi tiêu bằng cách sử dụng Oracle cho
Quản lý khóa cơ sở dữ liệu. Quá trình này thực sự thuộc về Hội tam phân, và
không để bất kỳ của các lớp học cá nhân. Do đó, chúng tôi đã tạo ra một lớp được gọi là hiệp hội
Đăng nhập, trong đó chúng ta đã khai báo một hoạt động gọi estimateUsage. Ngoài ra
để hoạt động này, chúng tôi đã xác định ba thuộc tính nằm trong hiệp hội:
beginDate, expiryDate, và hoursLogged.

Representing Derived Attributes, Derived Associations, and Derived Roles
Một thuộc tính có nguồn gốc, hiệp hội, hoặc vai trò là một trong đó có thể được tính hoặc có
nguồn gốc từ
các thuộc tính khác, các hiệp hội, và vai trò tương ứng. (Các khái niệm về một thuộc tính có
nguồn gốc
đã được giới thiệu trong chương 2.) Một yếu tố nguồn gốc (thuộc tính, hiệp hội hay vai trò) được
thường thể hiện bằng cách đặt hoặc là một dấu gạch chéo (/) hay một khuôn mẫu của << >> Xuất
phát trước
tên của phần tử. Ví dụ, trong hình 13-8, tuổi tác là một thuộc tính có nguồn gốc của sinh viên,
bởi vì nó có thể được tính từ ngày sinh và ngày hiện tại. Bởi vì việc tính toán
là một ràng buộc trên lớp, các tính toán được thể hiện trên sơ đồ này trong {} trên

các lớp sinh viên. Ngoài ra, các mối quan hệ Takes giữa giảng viên và học có nguồn gốc,
bởi vì nó có thể được suy ra từ Sổ đăng ký hộ và theo lịch trình Đối với các mối quan hệ. Bằng
cùng một mã thông báo, người tham gia là một vai trò có nguồn gốc bởi vì nó có thể được bắt
nguồn từ vai trò khác.

Representing Generalization
Bạn đã được giới thiệu khái quát và chuyên môn trong Chương 3. Sử dụng nâng cao
Mô hình ER, bạn đã học cách để tóm tắt các thuộc tính chung của hai hay nhiều thực thể,
cũng như các mối quan hệ chung mà trong đó họ tham gia, thành một thực thể tổng quát hơn
siêu kiểu, trong khi vẫn giữ các thuộc tính và các mối quan hệ mà không phải là phổ biến trong
các


các thực thể (subtype) mình. Trong mô hình hướng đối tượng, chúng tôi áp dụng các khái niệm
tương tự, nhưng với một sự khác biệt. Trong khái quát hóa một tập hợp các lớp đối tượng vào
một lớp tổng quát hơn,
chúng ta trừu tượng không chỉ có các thuộc tính chung và các mối quan hệ, nhưng các hoạt động
phổ biến
cũng. Các thuộc tính và các hoạt động của một lớp được gọi chung là
tính năng của lớp. Các lớp học được khái quát hóa được gọi là lớp con, và lớp
họ được khái quát hóa thành được gọi là một lớp cha, tương ứng hoàn hảo để phân nhóm và
siêu kiểu cho sơ đồ EER.
Hãy xem xét ví dụ thể hiện trong hình 13-9a. (Xem Hình 3-8 cho tương ứng
Sơ đồ EER) Có ba loại nhân viên:. Nhân viên theo giờ, nhân viên làm công ăn lương,
và chuyên gia tư vấn. Các tính năng được chia sẻ bởi tất cả các nhân viên-empName,
empNumber, địa chỉ, dateHired, và printLabel-được lưu trữ trong các lớp cha nhân viên,
trong khi các tính năng riêng biệt ở một loại nhân viên đặc biệt được lưu trữ trong
phân lớp tương ứng (ví dụ, hourlyRate và computeWages của nhân viên theo giờ).
Một con đường tổng quát được thể hiện như một dòng rắn từ các lớp con của lớp cha với một
tam giác rỗng ở cuối, và chỉ tay về phía, lớp cha. Bạn có thể hiển thị một nhóm

các đường dẫn tổng quát cho một lớp cha được coi là một cây với nhiều chi nhánh kết nối
các lớp con cá, và một phân đoạn được chia sẻ với một tam giác trỏ rỗng
về phía lớp cha. Trong hình 13-9b (tương ứng với hình 3-3), ví dụ, chúng tôi
đã kết hợp các đường dẫn khái quát từ ngoại trú cho bệnh nhân, và từ Resident
Bệnh nhân để bệnh nhân, vào một phân đoạn được chia sẻ với một hình tam giác hướng về bệnh
nhân. Chúng tôi cũng
xác định rằng khái quát này là năng động, có nghĩa là một đối tượng có thể thay đổi phân nhóm.
Bạn có thể chỉ ra các cơ sở của một sự tổng quát bằng cách xác định một phân biệt bên cạnh
con đường. Một phân biệt (tương ứng với phân biệt chủng được xác định trong
Chương 3) thể hiện các thuộc tính của một lớp đối tượng đang được trừu tượng hóa bằng một
đặc biệt
mối quan hệ tổng quát hóa. Bạn có thể phân biệt trên chỉ có một tài sản tại một thời điểm. Đối
với


Ví dụ, trong hình 13-9a, chúng ta phân biệt các lớp nhân viên trên cơ sở của việc làm
loại (theo giờ, lương, tư vấn). Để phổ biến một nhóm các mối quan hệ tổng quát
như trong hình 13-9b, chúng ta cần phải xác định phân biệt chỉ có một lần. Mặc dầu
chúng ta phân biệt các lớp bệnh nhân thành hai lớp con, ngoại trú và ngoại trú của bệnh nhân,
dựa vào cư trú, chúng tôi mang theo nhãn hiệu phân biệt chỉ một lần bên cạnh các dòng chia sẻ.
Một thể hiện của một lớp con cũng là một thể hiện của lớp cha của nó. Ví dụ trong
Hình 13-9b, một thể bệnh nhân ngoại trú cũng là một trường hợp bệnh nhân. Vì lý do đó, một sự
tổng quát
cũng được gọi là một là-một mối quan hệ. Ngoài ra, một lớp con thừa hưởng tất cả các
tính năng từ cha của nó. Ví dụ, trong hình 13-9a, ngoài đặc biệt riêng của mình
tính năng-hourlyRate và computeWages-phân lớp Employee được thừa hưởng hàng giờ
empName, empNumber, địa chỉ, dateHired, và printLabel từ nhân viên. An
thể hiện của nhân viên theo giờ sẽ lưu trữ các giá trị cho các thuộc tính của nhân viên và
Nhân viên theo giờ, và, khi được yêu cầu, sẽ áp dụng các printLabel và computeWages
hoạt động.

Khái quát và thừa kế được bắc cầu qua bất kỳ số lượng các cấp của một
lớp cha / lớp con thứ bậc. Ví dụ, chúng ta có thể có một lớp con của Tư vấn
gọi là Tư vấn máy tính đó sẽ kế thừa các tính năng của nhân viên và
Tư vấn. Một ví dụ của Tư vấn máy tính sẽ là một thể hiện của Tư vấn, và, do đó, một thể hiện
của nhân viên, quá. Nhân viên là tổ tiên của máy tính
Tư vấn, trong khi tư vấn máy tính là một hậu duệ của nhân viên; những thuật ngữ này
được sử dụng để tham khảo tổng quát của các lớp học trên nhiều cấp độ.
Thừa kế là một trong những lợi thế chính của việc sử dụng các mô hình hướng đối tượng. Nó
cho phép tái sử dụng mã: Không cần cho một nhà phát triển để thiết kế hoặc viết code mà có
đã được viết cho một lớp cha. Các nhà phát triển chỉ tạo ra mã mà là duy nhất cho
mới, lớp con tinh chế của một lớp học hiện có. Trong thực tế, các nhà phát triển hướng đối tượng
thường có quyền truy cập vào bộ sưu tập lớn các thư viện lớp học trong các lĩnh vực tương ứng
của họ.
Họ xác định những lớp học mà có thể được tái sử dụng và cải tiến để đáp ứng nhu cầu của các
mới


ứng dụng. Những người ủng hộ cách tiếp cận hướng đối tượng cho rằng kết quả tái sử dụng mã
trong
tăng năng suất của một số đơn đặt hàng của các cường độ.
Chú ý rằng trong hình 13-9b, lớp Bệnh nhân là in nghiêng, ngụ ý rằng nó là một
lớp trừu tượng. Một lớp trừu tượng là một lớp học mà không có trường hợp trực tiếp nhưng con
cháu
có thể có trường hợp trực tiếp (Booch, 1994;. Rumbaugh et al 1991,). (Lưu ý: Bạn có thể
bổ sung viết trừu tượng từ trong dấu ngoặc chỉ bên dưới hoặc ngay bên cạnh các lớp học
Tên. Điều này đặc biệt hữu ích khi bạn tạo ra một sơ đồ lớp bằng tay.) Một lớp học mà
có thể có trường hợp trực tiếp (ví dụ, bệnh nhân ngoại trú hoặc thường trú bệnh nhân) được gọi
là một lớp bê tông.
Trong ví dụ này, do đó, bệnh nhân ngoại trú và thường trú Bệnh nhân có thể có trường hợp trực
tiếp, nhưng

Bệnh nhân có thể không có bất kỳ trường hợp trực tiếp của riêng nó.
Lớp trừu tượng bệnh nhân tham gia vào một mối quan hệ được gọi là xử lý bởi với
Bác sĩ, ngụ ý rằng tất cả các bệnh nhân ngoại trú và bệnh nhân thường trú cũng như-là
điều trị bởi bác sĩ. Ngoài mối quan hệ di truyền này, lớp Bệnh nhân thường trú
đã quan hệ đặc biệt của riêng mình gọi là Assigned Để có Giường, ngụ ý rằng chỉ thường trú
bệnh nhân có thể được gán cho giường. Vì vậy, ngoài việc tinh chỉnh các thuộc tính và các hoạt
động
của một lớp, một lớp con cũng có thể chuyên các mối quan hệ mà trong đó nó tham gia.
Trong hình 13-9a và 13-9b, các từ "hoàn chỉnh", "không đầy đủ" và "tách bạch" có
được đặt trong dấu ngoặc, bên cạnh khái quát. Họ chỉ ra những hạn chế ngữ nghĩa
trong các lớp con. (Trong các ký hiệu EER, tương ứng hoàn toàn với tổng chuyên môn,
và không đầy đủ tương ứng với một phần chuyên môn.) Trong UML, một danh sách bằng dấu
phẩy của
từ khóa được đặt hoặc gần tam giác được chia sẻ, như trong hình 13-9b, hoặc gần một đường đứt
mà đi qua tất cả các dòng tổng quát liên quan, như trong hình 13-9a (UML Superstructure
Đặc điểm kỹ thuật, 2009). Bất kỳ của các từ khóa UML sau đây có thể được sử dụng: chồng
chéo, phân chia,
hoàn chỉnh, và không đầy đủ. Những thuật ngữ này có ý nghĩa như sau:


• Chồng chéo Một hậu duệ có thể có nguồn gốc từ hơn một trong những
lớp con. (Điều này cũng giống như quy luật chồng chéo trong sơ đồ EER.)
• rời nhau Một hậu duệ có thể không có nguồn gốc từ hơn một trong những
lớp con. (Đây là giống như quy tắc rời nhau trong sơ đồ EER.)
• Hoàn thành tất cả các lớp con đã được chỉ định (dù có hay không được hiển thị). Không có
thêm
lớp con đang mong đợi. (Điều này cũng giống như các quy tắc chuyên môn trong tổng số
EER biểu đồ.)
• Incomplete Một số lớp con đã được xác định, nhưng trong danh sách được biết đến là
không đầy đủ. Có thêm lớp con không còn ở trong các mô hình. (Đây là

giống như các quy tắc chuyên môn hóa một phần trong sơ đồ EER.)
Chồng chéo và tách rời là loại trừ lẫn nhau, như là đầy đủ và không đầy đủ.
Như vậy, sự kết hợp sau đây có thể là: {hoàn chỉnh, tách rời}, {không đầy đủ,
rời nhau}, {hoàn chỉnh, chồng chéo}, {không đầy đủ, chồng chéo} (UML Superstructure
Đặc điểm kỹ thuật, 2009).
Các khái quát trong cả hai hình 13-9a và 13-9b là rời nhau. Một nhân viên có thể
là một nhân viên theo giờ, một nhân viên làm công ăn lương, hoặc một nhà tư vấn, nhưng có thể
không, nói, là cả một
nhân viên làm công ăn lương và một chuyên gia tư vấn cùng một lúc. Tương tự như vậy, một
bệnh nhân có thể là một ngoại trú
hoặc một bệnh nhân cư trú, nhưng không phải cả hai. Các khái quát trong hình 13-9a là không
đầy đủ
(một sự khởi đầu từ những gì đã thể hiện trong hình 3-8), xác định rằng một nhân viên có thể
không
thuộc về một trong ba loại. Trong trường hợp này, một nhân viên sẽ được lưu giữ như là một ví
dụ
của nhân viên, một lớp bê tông. Ngược lại, khái quát trong hình 13-9b là hoàn chỉnh,
ngụ ý rằng một bệnh nhân có phải là một trong hai bệnh nhân ngoại trú hoặc một bệnh nhân cư
trú, và không có gì
khác. Vì lý do đó, bệnh nhân đã được xác định như là một lớp trừu tượng.
Trong hình 13-10, chúng tôi cho thấy một ví dụ về một ràng buộc chồng chéo. Sơ đồ


cho thấy rằng trợ lý nghiên cứu và trợ giảng là sinh viên đại học.
Ràng buộc chồng chéo chỉ ra rằng nó có thể cho một sinh viên tốt nghiệp để
phục vụ như là cả một trợ lý nghiên cứu và trợ giảng. Ví dụ, Sean
Bailey, một sinh viên đại học, có một Trợ lý nghiên cứu của 12 giờ một tuần và một
dạy làm trợ 8 giờ mỗi tuần. Cũng lưu ý rằng sinh viên tốt nghiệp có
được quy định như một lớp bê tông để sinh viên tốt nghiệp mà không một làm trợ
có thể được đại diện. Các dấu chấm lửng (...) Dưới dòng tổng quát dựa trên

"mức độ" phân biệt không đại diện cho một ràng buộc không đầy đủ. Nó chỉ đơn giản
chỉ ra rằng có những lớp con khác trong mô hình mà đã không được thể hiện trong
sơ đồ. Ví dụ, mặc dù undergrad Student là trong mô hình, chúng ta có
chọn không hiển thị nó trong sơ đồ kể từ khi tập trung được vào trợ giảng. Bạn có thể
cũng sử dụng một dấu chấm lửng khi có những hạn chế không gian.
Trong hình 13-11, chúng tôi đại diện cho cả đại học và sinh viên đại học trong một
mô hình phát triển cho thanh toán của học sinh. Các hoạt động calcTuition tính học phí một
sinh viên phải trả; số tiền này phụ thuộc vào học phí mỗi giờ tín dụng (tuitionPerCred),
các môn học và số giờ tín dụng (creditHrs) cho mỗi người trong những khóa học.
Học phí cho mỗi giờ tín dụng, đến lượt nó, phụ thuộc vào việc các sinh viên đã tốt nghiệp hoặc
một
sinh viên đại học. Trong ví dụ này, số tiền đó là $ 900 cho tất cả các sinh viên tốt nghiệp
và $ 750 cho tất cả các sinh viên đại học. Để biểu thị rằng, chúng tôi đã nhấn mạnh
tuitionPerCred thuộc tính trong mỗi của hai lớp con, cùng với giá trị của nó. một ví dụ
thuộc tính được gọi là một thuộc tính đẳng cấp phạm vi bởi vì nó xác định một giá trị chung cho
một
cả lớp chứ không phải là một giá trị cụ thể cho một ví dụ (Rumbaugh et al., 1991).
Bạn cũng có thể chỉ định một giá trị mặc định ban đầu của một thuộc tính bằng cách sử dụng một
= ký sau
tên thuộc tính. Đây là giá trị thuộc tính ban đầu của một trường hợp đối tượng mới được tạo ra.
Ví dụ, trong hình 13-11, các creditHrs thuộc tính có giá trị ban đầu của 3, ngụ ý
rằng khi một thể hiện mới của khóa học được tạo, giá trị của creditHrs được thiết lập để 3 bởi


mặc định. Bạn có thể viết một hoạt động xây dựng rõ ràng để sửa đổi các mặc định ban đầu
giá trị. Các giá trị cũng có thể được thay đổi muộn, thông qua các hoạt động khác. Sự khác biệt
giữa một đặc điểm kỹ thuật giá trị ban đầu và một thuộc tính đẳng cấp phạm vi là trong khi các
cựu
cho phép các khả năng của các giá trị thuộc tính khác nhau cho các trường hợp của một lớp học,
sau này

lực lượng tất cả các trường hợp để chia sẻ một giá trị chung.
Ngoài việc xác định sự đa dạng của một vai trò liên kết, bạn cũng có thể chỉ định
các tài sản khác, ví dụ, cho dù các đối tượng chơi vai trò được đặt hàng. Trong hình,
chúng tôi đặt những ràng buộc từ khóa "{} ra lệnh" bên cạnh các khóa học chào cuối
Dự kiến Đối với hiệp hội để biểu thị một thực tế là các dịch vụ cho một khóa học là
yêu cầu đưa vào danh sách, nói rằng, theo thời hạn và mục. Rõ ràng là nó làm cho tinh thần để
chỉ định một lệnh chỉ khi sự đa dạng về vai trò lớn hơn một. Mặc định
hạn chế trên một vai trò là "{} có thứ tự"; có nghĩa là, nếu bạn không xác định từ khóa
"{} Ra lệnh" bên cạnh vai trò, nó được giả định rằng các yếu tố liên quan tạo thành một thứ tự
thiết lập. Ví dụ, các khóa không liên quan đến một học sinh đăng ký cho những người
cúng dường trong bất kỳ thứ tự cụ thể.
Phân lớp Sinh viên Cao học chuyên lớp Student trừu tượng bằng cách thêm
bốn thuộc tính-undergradMajor, greScore, gmatScore, và tuitionPerCred và bởi
cải tiến các hoạt động calcTuition thừa kế. Chú ý rằng các hoạt động được thể hiện bằng chữ in
nghiêng
trong lớp Sinh viên, chỉ ra rằng nó là một hoạt động trừu tượng. Một hoạt động trừu tượng
có một hình thức được định hoặc giao thức, nhưng việc thực hiện không được định nghĩa
(Rumbaugh et al.,
1991). Trong ví dụ này, các lớp sinh viên xác định các giao thức của các hoạt động calcTuition,
mà không cung cấp phương pháp tương ứng (thực hiện thực tế của hoạt động).
Các giao thức bao gồm số lượng và kiểu của các đối số, các loại quả, và
ngữ nghĩa định của hoạt động. Hai lớp con cụ thể, Sinh viên Cao học
và undergrad Sinh viên, cung cấp triển khai riêng của họ về hoạt động calcTuition.
Lưu ý rằng bởi vì các lớp là bê tông, họ không thể lưu trữ các hoạt động trừu tượng.


Điều quan trọng là phải lưu ý rằng mặc dù các sinh viên tốt nghiệp và Đại học
Sinh viên các lớp học chia sẻ các hoạt động calcTuition cùng, họ có thể thực hiện các hoạt động
theo những cách hoàn toàn khác nhau. Ví dụ, phương pháp mà thực hiện các hoạt động có
sinh viên tốt nghiệp có thể thêm một khoản phí sau đại học đặc biệt cho mỗi khóa học sinh thi.

Các
thực tế là một hoạt động có cùng tên có thể phản ứng theo những cách khác nhau tùy thuộc vào
bối cảnh lớp học được gọi là đa hình, một khái niệm quan trọng trong hệ thống hướng đối tượng.
Các hoạt động tuyển sinh trong hình 13-11 minh họa một ví dụ về đa hình.
Trong khi các hoạt động tuyển sinh trong khóa học Cung cấp tính tuyển sinh cho một
cung cấp khóa học đặc biệt hoặc phần, một hoạt động với cùng một tên trong khóa học
tính tuyển sinh kết hợp cho tất cả các phần của một khóa học.

Interpreting Inheritance and Overriding
Chúng ta đã thấy một phân lớp có thể tăng thêm các tính năng thừa hưởng từ tổ tiên của nó.
Trong
trường hợp như vậy, các phân lớp được cho là sử dụng thừa kế cho gia hạn. Mặt khác, nếu một
subclass buộc một số các tổ tiên thuộc tính hoặc hoạt động, nó được cho là sử dụng
thừa kế cho hạn chế (Booch, 1994;. Rumbaugh et al, 1991). Ví dụ, một lớp con
gọi là thuế Công ty được miễn thuế có thể ức chế hoặc ngăn chặn các thừa kế của một hoạt động
gọi là tính thuế từ lớp cha của nó, Company.
Việc thực hiện một hoạt động cũng có thể được ghi đè. Quan trọng nhất là các
Quá trình thay thế một phương pháp kế thừa từ một lớp cha bằng cách thực hiện cụ thể hơn
của phương thức đó trong một phân lớp. Những lý do cho trọng bao gồm phần mở rộng, hạn chế,
và tối ưu hóa (Rumbaugh et al., 1991). Tên của hoạt động mới vẫn giữ nguyên
giống như thừa hưởng một, nhưng nó phải được thể hiện một cách rõ ràng trong các lớp con để
chỉ
rằng các hoạt động được ghi đè.
Trong trọng cho phần mở rộng, một hoạt động được thừa kế bởi một lớp từ lớp cha của nó
được mở rộng bằng cách thêm một số hành vi (code). Ví dụ, một lớp con của
Công ty là Công ty nước ngoài được thừa hưởng một hoạt động được gọi là tính thuế nhưng


mở rộng các hành vi được thừa kế bằng cách thêm một khoản phụ thu nước ngoài để tính tổng số
số thuế.

Trong trọng để hạn chế, các giao thức hoạt động mới trong phân lớp là
hạn chế. Ví dụ, một hoạt động được gọi là placeStudent (công việc) trong Student có thể bị hạn
chế
trong phân lớp sinh viên quốc tế bằng cách thắt chặt các công việc đối số (xem Hình 13-12).
Trong khi sinh viên nói chung có thể được đặt trong tất cả các loại công việc trong suốt mùa hè,
sinh viên quốc tế có thể được giới hạn ở việc chỉ trong khuôn viên trường vì các hạn chế thị thực.
Các hoạt động mới ghi đè các hoạt động kế thừa bằng cách thắt chặt các đối số công việc,
hạn chế giá trị của nó để chỉ một nhóm nhỏ của tất cả các công việc có thể. Ví dụ này cũng minh
họa
việc sử dụng nhiều discriminators. Trong khi cơ sở cho một tập hợp các khái quát là một
"độ" của học sinh (đại học hoặc đại học), mà cho các thiết lập khác là "nơi cư trú" của mình
trạng thái (Hoa Kỳ hoặc quốc tế).
Trong trọng để tối ưu hóa, các hoạt động mới được thực hiện với sự cải thiện
mã bằng cách khai thác các hạn chế áp đặt bởi một lớp con. Xem xét, ví dụ, một
phân lớp của học sinh được gọi là Dean Danh sách sinh viên, đại diện cho tất cả những học sinh
nằm trong danh sách của hiệu trưởng. Để hội đủ điều kiện cho danh sách của hiệu trưởng, học
sinh phải có một lớp điểm
trung bình lớn hơn hoặc bằng 3.50. Sinh viên Giả sử có một hoạt động được gọi là
mailScholApps, mà mail ứng dụng cho merit- và có nghĩa là thử nghiệm để học bổng
những học sinh có điểm trung bình lớn hơn hoặc bằng 3,00, và có gia đình của tổng doanh thu
thu nhập dưới $ 30,000. Phương pháp cho các hoạt động trong sinh viên sẽ phải kiểm tra
các điều kiện, trong khi các phương pháp cho các hoạt động tương tự trong của Dean Danh sách
sinh viên
phân lớp có thể cải tiến tốc độ thực hiện bằng cách loại bỏ các điều kiện đầu tiên từ
mã của nó. Hãy xem xét một hoạt động gọi findMinGpa, mà thấy điểm trung bình tối thiểu
giữa các sinh viên. Giả sử lớp Danh sách sinh viên của Dean được sắp xếp thứ tự tăng dần
của điểm trung bình, nhưng các lớp sinh viên không phải là. Các phương pháp để findMinGpa
trong Student phải

thực hiện một tìm kiếm tuần tự thông qua tất cả các học sinh. Ngược lại, các hoạt động tương tự
trong
Dean Danh sách sinh viên có thể được thực hiện với một phương pháp đơn giản là lấy điểm
trung bình
học sinh đầu tiên trong danh sách, do đó loại bỏ việc cần thiết phải tìm kiếm một thời gian.

Representing Multiple Inheritance
Vì vậy, đến nay bạn đã tiếp xúc với thừa kế duy nhất, nơi một lớp kế thừa từ chỉ có một
lớp cha. Nhưng đôi khi, như chúng ta đã thấy trong ví dụ với nghiên cứu và giảng dạy trợ lý,
một đối tượng có thể là một thể hiện của nhiều hơn một lớp. Điều này được gọi là nhiều
phân loại (Fowler, 2003; UML Notation Guide, 2003). Ví dụ, Sean Bailey, người
có cả hai loại trợ giảng, có hai cách phân loại: một là một thể hiện của nghiên cứu
Trợ lý, và người kia là một thể hiện của Teaching Assistant. Các chuyên gia, tuy nhiên, không
khuyến khích
nhiều phân loại, và thông thường ngữ nghĩa UML và nhiều đối tượng theo định hướng
ngôn ngữ không hỗ trợ nó.
Để có được xung quanh vấn đề này, chúng ta có thể sử dụng đa thừa kế, cho phép một lớp
kế thừa các tính năng từ nhiều hơn một lớp cha. Ví dụ, trong hình 13-13, chúng tôi có
Nghiên cứu tạo Trợ giảng, mà là một lớp con của cả hai trợ lý nghiên cứu và
Trợ giảng. Tất cả các học sinh có cả nghiên cứu và giảng dạy trợ giảng
có thể được lưu trữ dưới các lớp mới. Bây giờ chúng ta có thể đại diện cho Sean Bailey như một
đối tượng
thuộc chỉ Research Trợ giảng lớp học, mà kế thừa các tính năng từ
cả cha và mẹ của nó, chẳng hạn như researchHrs và assignProject (proj) từ Trợ lý nghiên cứu
và teachingHrs và assignCourse (crse) từ Teaching Assistant (và không cung cấp
Nét độc đáo của riêng mình).

Representing Aggregation
Một tập hợp thể hiện một phần-các mối quan hệ giữa một đối tượng thành phần và một
tổng hợp đối tượng. Nó là một hình thức mạnh mẽ của mối quan hệ liên kết (với thêm

"Part-of" ngữ nghĩa) và được biểu diễn với một viên kim cương rỗng vào cuối tổng hợp. Đối với
Ví dụ, hình 13-14 cho thấy một máy tính cá nhân như là một tổng hợp của CPU (lên đến bốn