Phương pháp xây dựng mô hình đối tượng. Vì vậy, cách tiếp cận hướng đối tượng giúp giải quyết các vấn đề phức tạp như Tính song song là đặc tính phân biệt đối tượng chủ động với đối tượng thụ động

Cơ sở khái niệm của cách tiếp cận hướng đối tượng là mô hình đối tượng. Các nguyên tắc chính của việc xây dựng nó là:

· trừu tượng;

· đóng gói;

· tính mô-đun;

· hệ thống cấp bậc.

Trừu tượng hóa là việc lựa chọn các đặc điểm quan trọng nhất, thiết yếu nhất của một số đối tượng, giúp phân biệt nó với tất cả các loại đối tượng khác và do đó xác định rõ ràng ranh giới khái niệm của nó từ quan điểm xem xét và phân tích sâu hơn và bỏ qua những thứ ít quan trọng hơn hoặc không đáng kể. chi tiết.

Tính trừu tượng cho phép bạn quản lý độ phức tạp của hệ thống bằng cách tập trung vào các thuộc tính thiết yếu của đối tượng. Tính trừu tượng tập trung sự chú ý vào các tính năng bên ngoài của một đối tượng và cho phép bạn tách các tính năng quan trọng nhất về hành vi của nó khỏi các chi tiết triển khai chúng. Việc lựa chọn đúng tập hợp trừu tượng cho một miền vấn đề nhất định là thách thức chính của thiết kế hướng đối tượng. Tính trừu tượng phụ thuộc vào miền và quan điểm - điều quan trọng trong bối cảnh này có thể không quan trọng trong bối cảnh khác. Các đối tượng và các lớp là những khái niệm trừu tượng cơ bản của một miền.

Đóng gói là việc bản địa hóa vật lý các thuộc tính và hành vi trong một sự trừu tượng hóa duy nhất (được coi là "hộp đen"), ẩn việc triển khai chúng đằng sau một giao diện chung.

Đóng gói là quá trình tách biệt các phần tử riêng lẻ của một đối tượng xác định cấu trúc và hành vi của nó. Đóng gói dùng để tách biệt giao diện của một đối tượng, phản ánh hành vi bên ngoài của nó, khỏi việc triển khai bên trong của đối tượng. Cách tiếp cận đối tượng giả định rằng các tài nguyên của chính nó, chỉ có thể được thao tác bởi các hoạt động của chính đối tượng đó, được ẩn khỏi môi trường bên ngoài. Trừu tượng hóa và đóng gói là bổ sung cho nhau: tính trừu tượng tập trung sự chú ý vào các tính năng bên ngoài của một đối tượng, trong khi việc đóng gói (hoặc hạn chế quyền truy cập) ngăn cản đối tượng người dùng nhận ra cấu trúc bên trong của đối tượng.

Đóng gói cũng tương tự như khái niệm che giấu thông tin. Đây là khả năng che giấu nhiều chi tiết của một vật thể với thế giới bên ngoài. Thế giới bên ngoài của một đối tượng là mọi thứ bên ngoài nó, bao gồm cả phần còn lại của hệ thống. Việc ẩn giấu thông tin mang lại lợi ích tương tự như việc đóng gói: tính linh hoạt.

Tính mô đun là một đặc tính của một hệ thống gắn liền với khả năng phân rã của nó thành một số hệ thống con (mô-đun) được liên kết chặt chẽ bên trong nhưng được liên kết với nhau yếu.

Tính mô đun làm giảm độ phức tạp của hệ thống bằng cách cho phép phát triển độc lập các mô đun riêng lẻ. Đóng gói và mô đun hóa tạo ra rào cản giữa sự trừu tượng hóa.

Hệ thống phân cấp là một hệ thống trừu tượng được xếp hạng hoặc sắp xếp, sự sắp xếp của chúng theo cấp độ.

Các loại cấu trúc phân cấp chính liên quan đến các hệ thống phức tạp là cấu trúc lớp (phân cấp theo danh pháp) và cấu trúc của các đối tượng (phân cấp theo thành phần). Ví dụ về hệ thống phân cấp lớp là sự kế thừa đơn giản và đa dạng (một lớp sử dụng một phần cấu trúc hoặc chức năng tương ứng của một hoặc nhiều lớp khác) và hệ thống phân cấp đối tượng là sự tổng hợp.

Các lớp có thể được tổ chức theo cấu trúc phân cấp, trông giống như sơ đồ phân loại trong logic khái niệm. Hệ thống phân cấp của các khái niệm được xây dựng như sau. Khái niệm hoặc phạm trù chung nhất được coi là khái niệm có khối lượng lớn nhất và theo đó, có nội dung nhỏ nhất. Đây là mức độ trừu tượng cao nhất của một hệ thống phân cấp nhất định. Sau đó, khái niệm chung này được xác định, nghĩa là khối lượng của nó giảm và nội dung của nó tăng lên. Một khái niệm ít tổng quát hơn xuất hiện, khái niệm này trong sơ đồ phân cấp sẽ nằm dưới khái niệm ban đầu một cấp. Quá trình cụ thể hóa các khái niệm này có thể được tiếp tục cho đến khi đạt được ở mức độ thấp nhất một khái niệm mà việc cụ thể hóa sâu hơn khái niệm đó trong một bối cảnh nhất định là không thể hoặc không thực tế.

Sự phụ thuộc giữa các lớp (đối tượng)

Mỗi đối tượng được liên kết với một cấu trúc dữ liệu, các trường của nó là thuộc tính của đối tượng này và các con trỏ tới các hàm (đoạn mã) thực hiện các hoạt động của đối tượng này (lưu ý rằng các con trỏ hàm, do tối ưu hóa mã, thường được thay thế bằng cách gọi đến các chức năng này). Vì vậy, một đối tượng là một số cấu trúc dữ liệu có kiểu tương ứng với lớp của đối tượng này.

Bạn có thể cài đặt giữa các đối tượng sự phụ thuộc dựa theo. Những cái này sự phụ thuộc thể hiện thông tin liên lạc hoặc mối quan hệ giữa các lớp của đối tượng được chỉ định. Ví dụ về các phụ thuộc như vậy được hiển thị trong Hình 2.6 (hai phụ thuộc đầu tiên là nhị phân, phụ thuộc thứ ba là trenary). Sự phụ thuộc được mô tả bằng một đường nối các lớp, trên đó viết tên của phần phụ thuộc này hoặc chỉ ra vai trò của các đối tượng (lớp) trong phần phụ thuộc này (chỉ ra vai trò là cách thuận tiện nhất để xác định phần phụ thuộc).

Cơm. 2.6. Sự phụ thuộc giữa các lớp

Sự phụ thuộc giữa các lớp là hai chiều: tất cả các lớp trong phần phụ thuộc đều có quyền bình đẳng. Điều này đúng ngay cả trong trường hợp tên của phần phụ thuộc dường như đưa ra hướng đi cho phần phụ thuộc này. Vì vậy, trong ví dụ đầu tiên trong Hình 2.6, tên phụ thuộc has_capital gợi ý rằng sự phụ thuộc được hướng từ lớp quốc gia đến lớp thành phố (bản chất hai chiều của sự phụ thuộc dường như đã biến mất); nhưng cần lưu ý rằng sự phụ thuộc này có tính hai chiều theo nghĩa sự phụ thuộc nghịch đảo đồng thời là vốn. Theo cách tương tự, trong ví dụ thứ hai trong Hình 2.6, người ta có thể xem xét cặp phụ thuộc sở hữu riêng. Những hiểu lầm như vậy có thể tránh được nếu các phần phụ thuộc được xác định không phải bằng tên mà bằng tên vai trò của các lớp tạo nên phần phụ thuộc.

Trong các ngôn ngữ lập trình, sự phụ thuộc giữa các lớp (đối tượng) thường được triển khai bằng cách sử dụng các tham chiếu (con trỏ) từ lớp (đối tượng) này sang lớp (đối tượng) khác. Việc biểu diễn các phần phụ thuộc bằng cách sử dụng các tham chiếu cho thấy thực tế rằng phần phụ thuộc là thuộc tính của một cặp lớp chứ không phải của bất kỳ lớp nào trong số chúng, tức là. Nghiện là một mối quan hệ. Lưu ý rằng mặc dù sự phụ thuộc giữa các đối tượng là hai chiều, nhưng chúng không cần phải được triển khai hai chiều trong các chương trình, chỉ để lại các tham chiếu trong các lớp cần thiết cho chương trình.

Các ví dụ khác về sự phụ thuộc giữa các lớp được thể hiện trong Hình 2.7. Ví dụ đầu tiên cho thấy mối quan hệ giữa khách hàng của ngân hàng và tài khoản của anh ta. Một khách hàng của ngân hàng có thể có nhiều tài khoản tại ngân hàng này cùng một lúc hoặc không có tài khoản nào cả (khi anh ta lần đầu tiên trở thành khách hàng của ngân hàng). Vì vậy, cần mô tả mối quan hệ giữa khách hàng và một số tài khoản, được thể hiện trong Hình 2.7. Ví dụ thứ hai cho thấy mối quan hệ giữa các đường cong giao nhau (cụ thể là đường thẳng). Bạn có thể xem xét 2, 3 hoặc nhiều đường như vậy và chúng có thể có một số điểm giao nhau. Cuối cùng, ví dụ thứ ba cho thấy một sự phụ thuộc tùy chọn: máy tính có thể có hoặc không có chuột.

Sự phụ thuộc giữa các lớp tương ứng với sự phụ thuộc giữa các đối tượng của các lớp này. Hình 2.8 thể hiện sự phụ thuộc giữa các đối tượng đối với ví dụ đầu tiên của Hình 2.6; Hình 2.9 thể hiện sự phụ thuộc giữa các đối tượng đối với các ví dụ trong Hình 2.7.

Cơm. 2.7. Ví dụ khác về sự phụ thuộc. Chỉ định

Cơm. 2.8. Sự phụ thuộc giữa các đối tượng

Lưu ý rằng khi mô tả sự phụ thuộc giữa các đối tượng, theo quy luật, chúng ta biết số lượng đối tượng và không cần các ký hiệu như “một số”, “hai hoặc nhiều hơn”, “không nhất thiết”.

Khi thiết kế một hệ thống, sẽ thuận tiện hơn khi vận hành không phải với các đối tượng mà với các lớp.

Cơm. 2.9. Sự phụ thuộc phức tạp hơn giữa các đối tượng

Khái niệm về sự phụ thuộc đã được chuyển sang công nghệ hướng đối tượng để thiết kế hệ thống phần mềm từ công nghệ thiết kế (và mô hình hóa) cơ sở dữ liệu, nơi các sự phụ thuộc đã được sử dụng từ lâu. Theo quy định, các ngôn ngữ lập trình không hỗ trợ mô tả rõ ràng về các phần phụ thuộc. Tuy nhiên, việc mô tả các phụ thuộc rất hữu ích khi phát triển hệ thống phần mềm. Công nghệ OMT sử dụng các phần phụ thuộc để diễn giải các sơ đồ mô tả hệ thống.

Bây giờ chúng ta đã có tất cả các khái niệm cần thiết để mô tả quá trình xây dựng mô hình đối tượng. Quá trình này bao gồm các bước sau:

• xác định các đối tượng và lớp;
• chuẩn bị từ điển dữ liệu;
• xác định sự phụ thuộc giữa các đối tượng;
• xác định các thuộc tính và mối quan hệ của đối tượng;
• tổ chức, đơn giản hóa các lớp khi sử dụng tính kế thừa;
• tiếp tục nghiên cứu và cải tiến mô hình.

GIỚI THIỆU

Đặc điểm quan trọng nhất của bất kỳ hệ thống nào là cấu trúc và quá trình hoạt động của nó. Cấu trúc của một hệ thống được hiểu là một tập hợp các mối quan hệ ổn định theo thời gian giữa các phần tử hoặc thành phần của nó. Nó là cấu trúc liên kết tất cả các phần tử lại với nhau và ngăn chặn hệ thống tan rã thành các thành phần riêng biệt. Cấu trúc của một hệ thống có thể phản ánh nhiều mối quan hệ khác nhau, bao gồm cả việc lồng các phần tử của hệ thống này vào hệ thống khác. Trong trường hợp này, người ta thường gọi hệ thống nhỏ hơn hoặc hệ thống lồng nhau là hệ thống con. Quá trình hoạt động của hệ thống có liên quan chặt chẽ đến những thay đổi về đặc tính hoặc hành vi của nó theo thời gian. Trong trường hợp này, một đặc điểm quan trọng của hệ thống là trạng thái của nó, được hiểu là một tập hợp các thuộc tính hoặc đặc điểm mà tại mỗi thời điểm phản ánh những đặc điểm quan trọng nhất trong hành vi của hệ thống. Đặc tính chung của tất cả các mô hình là sự giống nhau của chúng với hệ thống ban đầu. Tầm quan trọng của việc xây dựng các mô hình nằm ở khả năng sử dụng chúng để thu được thông tin về các đặc tính hoặc hành vi của hệ thống ban đầu. Trong trường hợp này, quá trình xây dựng và áp dụng mô hình tiếp theo để thu được thông tin về hệ thống ban đầu được gọi là mô hình hóa. Mô hình hệ thống chung chứa một số thông tin quan trọng về các đặc điểm chức năng của một hệ thống nhất định, cung cấp cái nhìn sâu sắc về hành vi trong tương lai của nó.

Việc nghiên cứu quy trình mô hình hóa là đối tượng nghiên cứu của khóa học này. Việc xây dựng một mô hình đối tượng cụ thể và nghiên cứu hành vi của nó sẽ được coi là chủ đề nghiên cứu. Để đạt được mục tiêu này, các phương pháp sau được sử dụng: nghiên cứu tài liệu cần thiết, so sánh, ví dụ từ kinh nghiệm sống... Vì việc xây dựng mô hình đối tượng sẽ được thực hiện bằng cách sử dụng ví dụ về dịch vụ ô tô nên cần nghiên cứu cách vận hành nguyên tắc của tổ chức này. Để làm được điều này, chỉ cần truy cập trang web chính thức của nhiều dịch vụ ô tô khác nhau là đủ. Nhưng để nghiên cứu nguyên lý xây dựng mô hình đối tượng, tôi đã nghiên cứu các tài liệu khoa học trong và ngoài nước. Nó hóa ra là một hoạt động rất thú vị.

Do đó, mục tiêu khóa học của tôi là xây dựng mô hình đối tượng của hệ thống thông tin Autoservice, nghiên cứu nguyên tắc xây dựng mô hình đối tượng, mô tả quy trình xây dựng, chứng minh tầm quan trọng của việc sở hữu kiến ​​thức này và khả năng áp dụng nó trong luyện tập.

Cấu trúc của khóa học như sau: đầu tiên, lý thuyết xây dựng mô hình khách quan được nghiên cứu, sau đó việc thực hiện lý thuyết được kiểm tra bằng một ví dụ thực tế.

1. Các khái niệm cơ bản của phương pháp hướng đối tượng

Cách tiếp cận hướng đối tượng dựa trên việc sử dụng các mô hình một cách có hệ thống. Việc xây dựng mục tiêu liên quan đến các đối tượng và khái niệm về thế giới thực có liên quan đến hệ thống phần mềm đang được phát triển. Với cách tiếp cận hướng đối tượng, các đối tượng và khái niệm này được thay thế bằng mô hình của chúng, tức là. những cấu trúc hình thức nhất định đại diện cho chúng trong một hệ thống phần mềm.

Mô hình không chứa tất cả các tính năng và thuộc tính của đối tượng hoặc khái niệm mà nó đại diện mà chỉ chứa những tính năng và thuộc tính cần thiết cho hệ thống phần mềm đang được phát triển. Như vậy, mô hình đơn giản hơn đối tượng (khái niệm) mà nó đại diện. Điều này giúp đơn giản hóa cả việc phát triển và nghiên cứu (phân tích) các mô hình cũng như việc triển khai chúng trên máy tính. Đặc biệt, bản chất hình thức của các mô hình cho phép chúng ta có được mô hình hình thức của hệ thống phần mềm đang được phát triển dưới dạng tổng hợp các mô hình hình thức của các thành phần của nó.

Như vậy, cách tiếp cận hướng đối tượng giúp giải quyết các vấn đề phức tạp như giảm độ phức tạp của phần mềm; tăng độ tin cậy của phần mềm; đảm bảo khả năng sửa đổi các thành phần phần mềm riêng lẻ mà không thay đổi các thành phần còn lại của nó; đảm bảo khả năng sử dụng lại các thành phần phần mềm riêng lẻ.

Ứng dụng có hệ thống của cách tiếp cận hướng đối tượng cho phép phát triển các hệ thống phần mềm có cấu trúc tốt, đáng tin cậy và khá dễ dàng sửa đổi. Điều này giải thích sự quan tâm của các lập trình viên đối với cách tiếp cận hướng đối tượng. Cách tiếp cận hướng đối tượng là một trong những lĩnh vực phát triển nhanh nhất của lập trình lý thuyết và ứng dụng.

Phát triển phần mềm hướng đối tượng liên quan đến việc sử dụng các mô hình hướng đối tượng trong việc phát triển hệ thống phần mềm và các thành phần của chúng.

Phát triển hướng đối tượng có thể bắt đầu ngay từ giai đoạn đầu tiên của vòng đời; nó không liên quan đến ngôn ngữ lập trình mà hệ thống phần mềm đang được phát triển được cho là sẽ được triển khai: ngôn ngữ này có thể không hướng đối tượng. Ở giai đoạn phát triển, các đối tượng là một số cấu trúc chính thức (ví dụ: hình chữ nhật có các góc tròn, với sự trợ giúp của chúng được mô tả trên sơ đồ), chưa được kết nối theo bất kỳ cách nào với việc triển khai trong tương lai của chúng bằng một trong các ngôn ngữ lập trình.

Phát triển phần mềm hướng đối tượng liên quan đến việc sử dụng các phương pháp (công nghệ) hướng đối tượng. Thông thường, các phương pháp hướng đối tượng này được hỗ trợ bởi các công cụ phần mềm, nhưng ngay cả khi không có những công cụ đó, chúng vẫn hữu ích vì chúng cho phép hiểu rõ về các khía cạnh và thuộc tính khác nhau của hệ thống phần mềm đang được phát triển, sau đó tạo điều kiện thuận lợi đáng kể cho việc triển khai, thử nghiệm, bảo trì, phát triển các phiên bản mới và sửa đổi đáng kể hơn.

Thiết kế của một hệ thống phần mềm ứng dụng bắt đầu bằng việc phân tích các yêu cầu mà nó sẽ phải đáp ứng. Việc phân tích như vậy được thực hiện để hiểu đủ mục đích và điều kiện vận hành của hệ thống để có thể đưa ra thiết kế sơ bộ của nó.

Với cách tiếp cận hướng đối tượng, việc phân tích các yêu cầu hệ thống phụ thuộc vào việc phát triển các mô hình của hệ thống này. Mô hình của một hệ thống (hoặc bất kỳ đối tượng hoặc hiện tượng nào khác) là một mô tả hình thức của hệ thống, xác định các đối tượng chính tạo nên hệ thống và các mối quan hệ giữa các đối tượng này. Xây dựng mô hình là một cách phổ biến để nghiên cứu các đối tượng và hiện tượng phức tạp. Mô hình bỏ sót nhiều chi tiết gây khó hiểu. Mô hình hóa được phổ biến rộng rãi trong cả khoa học và công nghệ.

Các mô hình giúp kiểm tra hiệu suất của hệ thống đang được phát triển ở giai đoạn đầu của quá trình phát triển, giao tiếp với khách hàng của hệ thống, làm rõ các yêu cầu của hệ thống đối với hệ thống và thực hiện các thay đổi (nếu cần) đối với thiết kế hệ thống (cả ở giai đoạn đầu). thiết kế của nó và ở các giai đoạn khác trong vòng đời của nó).

Các mô hình được phát triển và gỡ lỗi trong giai đoạn đầu tiên của vòng đời hệ thống tiếp tục được sử dụng trong tất cả các giai đoạn tiếp theo, tạo điều kiện thuận lợi cho việc lập trình hệ thống, gỡ lỗi và thử nghiệm, bảo trì và sửa đổi thêm.

Mô hình đối tượng mô tả cấu trúc của các đối tượng tạo nên hệ thống, các thuộc tính, hoạt động và mối quan hệ của chúng với các đối tượng khác. Mô hình đối tượng phải phản ánh các khái niệm và đối tượng của thế giới thực quan trọng đối với hệ thống đang được phát triển. Mô hình đối tượng trước hết phản ánh tính thực dụng của hệ thống đang được phát triển, được thể hiện ở việc sử dụng thuật ngữ miền ứng dụng gắn liền với việc sử dụng hệ thống đang được phát triển.

Hãy xem xét các khái niệm cơ bản được sử dụng trong việc xây dựng một mô hình đối tượng.

Đối tượng là một sự trừu tượng hoặc bất kỳ thứ gì có ranh giới được xác định rõ ràng, có ý nghĩa trong bối cảnh của vấn đề ứng dụng hiện tại. Việc giới thiệu đối tượng nhằm hai mục tiêu: tìm hiểu nhiệm vụ (bài toán) được áp dụng và giới thiệu cơ sở thực hiện trên máy tính.

Mục đích của việc phát triển mô hình đối tượng là mô tả các đối tượng tạo nên hệ thống được thiết kế chung, cũng như xác định và chỉ ra các mối phụ thuộc khác nhau giữa các đối tượng.

Một lớp là một bộ mô tả cho một tập hợp các đối tượng có cùng thuộc tính. Một lớp mô tả các thuộc tính của một số đối tượng. Mỗi đối tượng chỉ là một thể hiện của một lớp.

Tất cả các đối tượng của cùng một lớp được đặc trưng bởi cùng một tập thuộc tính. Tuy nhiên, việc nhóm các đối tượng thành các lớp được xác định không phải bởi các tập thuộc tính mà bởi ngữ nghĩa. Vì vậy, ví dụ, các đồ vật ổn định và ngựa có thể có cùng thuộc tính: giá cả và tuổi. Hơn nữa, chúng có thể thuộc về cùng một lớp nếu chúng được xem xét trong bài toán đơn giản như một sản phẩm hoặc thuộc các lớp khác nhau, điều này tự nhiên hơn.

Việc kết hợp các đối tượng thành các lớp cho phép bạn đưa tính trừu tượng vào vấn đề và xem xét nó theo một công thức tổng quát hơn. Một lớp có một tên (chẳng hạn như ngựa) áp dụng cho tất cả các đối tượng của lớp đó. Ngoài ra, lớp còn chứa tên của các thuộc tính được xác định cho các đối tượng. Theo nghĩa này, mô tả của một lớp tương tự như mô tả của loại cấu trúc (bản ghi); Hơn nữa, mỗi đối tượng đều có ý nghĩa giống như một thể hiện của cấu trúc (biến hoặc hằng thuộc loại tương ứng).

Thuộc tính đối tượng là một giá trị đặc trưng cho một đối tượng trong lớp của nó. Ví dụ về các thuộc tính: nhãn hiệu, năm sản xuất, màu sắc (thuộc tính của các đối tượng thuộc loại ô tô), v.v.

Một thao tác là một hàm (hoặc phép biến đổi) có thể được áp dụng cho các đối tượng của một lớp nhất định. Ví dụ về các thao tác: kiểm tra, tháo, lắp (đối với đối tượng thuộc lớp phụ tùng).

Tất cả các đối tượng của một lớp nhất định đều sử dụng cùng một thể hiện của từng thao tác (nghĩa là việc tăng số lượng đối tượng của một lớp nhất định không dẫn đến tăng số lượng mã chương trình được tải). Đối tượng mà thao tác được gọi được truyền cho nó dưới dạng đối số (tham số) ngầm định.

Thao tác tương tự có thể được áp dụng cho các đối tượng thuộc các lớp khác nhau: thao tác như vậy được gọi là đa hình vì nó có thể có các dạng khác nhau cho các lớp khác nhau.

Sự phụ thuộc giữa các lớp là hai chiều: tất cả các lớp trong phần phụ thuộc đều có quyền bình đẳng. Điều này đúng ngay cả trong trường hợp tên của phần phụ thuộc dường như đưa ra hướng đi cho phần phụ thuộc này. Sự phụ thuộc giữa các lớp tương ứng với sự phụ thuộc giữa các đối tượng của các lớp này. Các phần phụ thuộc, giống như các lớp, có thể có các thuộc tính.

Bộ phân biệt đối xử là một thuộc tính thuộc loại "liệt kê" cho biết thuộc tính nào của đối tượng mà một khái quát hóa nhất định được tạo thành từ đó.

Vai trò xác định một mặt của sự phụ thuộc. Trong phần phụ thuộc nhị phân, hai vai trò được xác định. Tên vai trò xác định duy nhất một bên của phần phụ thuộc. Các vai trò cho phép xem một phụ thuộc nhị phân như một mối quan hệ giữa một đối tượng và một tập hợp các đối tượng phụ thuộc: mỗi vai trò là một chỉ định của một đối tượng hoặc một tập hợp các đối tượng được kết nối bởi một phụ thuộc với một đối tượng ở đầu kia của phụ thuộc. Tên vai trò có thể được coi là thuộc tính dẫn xuất có tập giá trị là tập hợp các đối tượng được liên kết với vai trò đó. Trong phần phụ thuộc nhị phân, một cặp tên vai trò có thể được sử dụng để xác định phần phụ thuộc đó.

Tên vai trò phải được chỉ định trong trường hợp thiết lập sự phụ thuộc giữa các đối tượng của cùng một lớp. Tên vai trò phải là duy nhất vì chúng được sử dụng để phân biệt các đối tượng liên quan đến phần phụ thuộc.

Vòng loại là một thuộc tính cho phép bạn giảm bội số hiệu quả của một phần phụ thuộc. Bộ định tính được sử dụng trong các mối quan hệ phụ thuộc một-nhiều hoặc nhiều-nhiều.

Tập hợp là sự phụ thuộc giữa một lớp các đối tượng tổng hợp và các lớp đại diện cho các thành phần của các đối tượng này (mối quan hệ “toàn bộ”-“bộ phận”).

Khái quát hóa và kế thừa giúp xác định sự tương tự giữa các lớp đối tượng khác nhau và xác định phân loại đối tượng đa cấp. Do đó, trong các hệ thống đồ họa có thể có các lớp xác định việc mô tả các hình dạng hình học khác nhau: điểm, đường thẳng (đường thẳng, cung tròn và đường cong được xác định bởi đường trục), đa giác, hình tròn, v.v.

Bộ phân biệt đối xử là một thuộc tính thuộc loại "liệt kê" cho biết thuộc tính nào của đối tượng mà một khái quát hóa nhất định được tạo thành từ đó.

Cần lưu ý rằng nên tránh phân loại đa cấp mở rộng vì hành vi của các lớp con ở các cấp thấp hơn của phân loại đa cấp có thể khó hiểu: hầu hết (và thường là tất cả) các thuộc tính và hoạt động của các lớp đó đều được xác định trong các siêu lớp của chúng ở nhiều cấp độ khác nhau. Nếu số lượng cấp độ phân loại trở nên quá lớn, bạn cần thay đổi một chút cấu trúc của hệ thống.

Khái quát hóa và kế thừa được sử dụng rộng rãi không chỉ trong việc phân tích các yêu cầu đối với hệ thống phần mềm và thiết kế sơ bộ mà còn trong việc triển khai chúng.

Đôi khi, một lớp con cần ghi đè một thao tác được xác định trong một trong các lớp cha của nó. Để đạt được điều này, một thao tác có thể bắt nguồn từ siêu lớp do kế thừa cũng được xác định trong lớp con; việc định nghĩa lại này "che khuất" định nghĩa của nó trong siêu lớp, do đó thao tác được ghi đè trong lớp con, không phải lớp kế thừa, được áp dụng. Hãy nhớ lại rằng mỗi thao tác được xác định bằng chữ ký của nó; do đó, chữ ký của thao tác ghi đè phải khớp với chữ ký của thao tác trong siêu lớp được thao tác ghi đè.

Việc ghi đè có thể phục vụ một trong các mục đích sau:

phần mở rộng: thao tác mới mở rộng thao tác kế thừa, có tính đến ảnh hưởng của các thuộc tính lớp con;

hạn chế: thao tác mới bị giới hạn ở việc chỉ thực hiện một phần hành động của thao tác kế thừa, sử dụng các đặc điểm cụ thể của các đối tượng của lớp con;

tối ưu hóa: sử dụng các chi tiết cụ thể của các đối tượng lớp con cho phép bạn đơn giản hóa và tăng tốc phương thức tương ứng;

sự tiện lợi.

Nên tuân thủ các quy tắc kế thừa ngữ nghĩa sau đây:

tất cả các thao tác truy vấn (các thao tác sử dụng giá trị thuộc tính nhưng không thay đổi chúng) phải được kế thừa bởi tất cả các lớp con;

tất cả các thao tác thay đổi giá trị thuộc tính phải được kế thừa trong tất cả các phần mở rộng của chúng;

tất cả các hoạt động thay đổi giá trị của thuộc tính bị hạn chế hoặc thuộc tính xác định phụ thuộc phải chặn trong tất cả các phần mở rộng của chúng;

về cơ bản các hoạt động không nên được xác định lại; tất cả các phương thức thực hiện cùng một thao tác phải thực hiện chuyển đổi thuộc tính tương tự;

Các hoạt động kế thừa có thể được tinh chỉnh bằng cách thêm các hành động bổ sung.

Thật không may, bằng cách tuân theo các quy tắc này, vốn hiếm khi được hỗ trợ bởi các ngôn ngữ lập trình hướng đối tượng, bạn có thể làm cho chương trình bạn đang phát triển trở nên dễ hiểu hơn, dễ sửa đổi hơn và ít mắc phải các lỗi và sơ suất khác nhau.

Một lớp trừu tượng không thể có các đối tượng vì nó không định nghĩa các thao tác trên đối tượng; các đối tượng phải thuộc về các lớp con cụ thể của lớp trừu tượng. Các lớp trừu tượng được sử dụng để chỉ định các giao diện cho các hoạt động (các phương thức thực hiện các hoạt động này sau đó được định nghĩa trong các lớp con của lớp trừu tượng). Các lớp trừu tượng thuận tiện trong giai đoạn phân tích các yêu cầu hệ thống, vì chúng cho phép chúng ta xác định những điểm tương tự trong các hoạt động dường như khác nhau được xác định trong hệ thống đang được phân tích.

Đa kế thừa cho phép một lớp có nhiều hơn một siêu lớp, kế thừa các thuộc tính (thuộc tính và thao tác) của tất cả các siêu lớp của nó. Một lớp có nhiều siêu lớp được gọi là lớp hợp nhất. Các thuộc tính của lớp tổ tiên xuất hiện nhiều lần trong biểu đồ kế thừa chỉ được kế thừa trong một bản sao. Xung đột giữa các định nghĩa song song tạo ra sự mơ hồ cần được giải quyết trong quá trình thực hiện. Trong thực tế, nên tránh những sự mơ hồ hoặc hiểu biết kém như vậy ngay cả khi ngôn ngữ lập trình cụ thể được chọn để triển khai hệ thống cung cấp khả năng giải quyết chúng bằng cách sử dụng mức độ ưu tiên hoặc một số phương tiện khác.

Trong thiết kế hướng đối tượng, chúng ta xử lý các tập hợp các đối tượng được kết nối với nhau. Mỗi đối tượng có thể được coi là một biến hoặc hằng của một kiểu cấu trúc (theo cách này, các phương thức được mô tả trong đối tượng được coi là địa chỉ của các hàm được phép áp dụng cho đối tượng này). Do đó, một tập hợp các đối tượng là một tập hợp dữ liệu được kết nối với nhau, tức là một cái gì đó rất giống với một cơ sở dữ liệu. Vì vậy, việc áp dụng các khái niệm cơ sở dữ liệu thường hữu ích trong phân tích hướng đối tượng và thiết kế hướng đối tượng của hệ thống phần mềm ứng dụng.

Siêu dữ liệu là dữ liệu mô tả dữ liệu khác. Ví dụ: định nghĩa của một lớp là siêu dữ liệu, vì lớp đó mô tả các dữ liệu khác - các đối tượng của lớp này. Mô hình là siêu dữ liệu vì chúng mô tả các đối tượng được mô hình hóa. Một ví dụ khác về siêu dữ liệu là lớp trừu tượng.

Tác nhân là các vai trò được thực hiện bởi các thực thể tương tác trực tiếp với hệ thống.

Một tác nhân xác định vai trò của một số thực thể bên ngoài khi tương tác trực tiếp với một hệ thống nhất định. Nó có thể thể hiện vai trò của người dùng hoặc vai trò được thực hiện bởi một hệ thống hoặc phần cứng khác chạm đến ranh giới hệ thống.

Tôi rất thích cách mô tả khái niệm “diễn viên” trong tác phẩm “UML 2 và Quy trình thống nhất” của Jim Arlow và Isle Neustadt: “Để hiểu diễn viên, điều quan trọng là phải hiểu khái niệm về vai trò. Một vai trò có thể được coi như một chiếc mũ được đội trong một tình huống nhất định." (trang 92).

Khi đã biết các khái niệm cơ bản, chúng ta có thể xem xét việc xây dựng mô hình

1. Xây dựng mô hình đối tượng

1. Xác định lớp

Phân tích các yêu cầu bên ngoài đối với hệ thống ứng dụng được thiết kế cho phép chúng ta xác định các đối tượng và lớp đối tượng liên quan đến vấn đề ứng dụng mà hệ thống này phải giải quyết. Bạn cần bắt đầu bằng việc xác định các lớp có thể có từ tuyên bố bằng văn bản của vấn đề được áp dụng (thông số kỹ thuật và tài liệu khác do khách hàng cung cấp). Đây là một giai đoạn phát triển rất khó khăn và đầy trách nhiệm, vì số phận tương lai của dự án phần lớn phụ thuộc vào nó.

Khi xác định các lớp có thể có, bạn nên cố gắng xác định càng nhiều lớp càng tốt, viết ra tên của từng lớp mà bạn nghĩ đến. Đặc biệt, mỗi danh từ xuất hiện trong câu mở đầu của bài toán có thể có một lớp tương ứng. Vì vậy, khi xác định các lớp có thể, mỗi danh từ như vậy thường được liên kết với một lớp có thể.

các lớp dự phòng: nếu hai hoặc nhiều lớp thể hiện cùng một thông tin thì chỉ giữ lại một trong số chúng;

các lớp không liên quan (không liên quan trực tiếp đến vấn đề): đối với mỗi tên của một lớp có thể, người ta đánh giá mức độ cần thiết của nó trong hệ thống tương lai (thường rất khó để đánh giá điều này); các lớp không liên quan bị loại trừ;

các lớp được xác định một cách mơ hồ (từ quan điểm của vấn đề đang được xem xét);

thuộc tính: một số danh từ tương ứng với thuộc tính hơn là lớp; những danh từ như vậy, như một quy luật, mô tả các thuộc tính của đối tượng (ví dụ: tên, tuổi, trọng lượng, địa chỉ, v.v.);

các hoạt động: một số danh từ có nhiều khả năng là tên hoạt động hơn là các lớp (ví dụ:phone_call dường như không có nghĩa là bất kỳ lớp nào);

vai trò: một số danh từ xác định tên vai trò trong mô hình đối tượng (ví dụ: chủ sở hữu, người lái xe, ông chủ, nhân viên; tất cả các tên này đều được liên kết với các vai trò trong các phụ thuộc đối tượng khác nhau của lớp người);

cấu trúc triển khai: không nên so sánh các tên liên quan nhiều hơn đến lập trình và phần cứng máy tính với các lớp ở giai đoạn này, vì chúng không phản ánh các tính năng của hệ thống ứng dụng được thiết kế; ví dụ về các tên như vậy: chương trình con, quy trình, thuật toán, ngắt, v.v.

Sau khi loại bỏ tên của tất cả các lớp không cần thiết (thừa) có thể, sẽ thu được danh sách sơ bộ các lớp tạo nên hệ thống được thiết kế.

1. Chuẩn bị từ điển dữ liệu

Từ riêng lẻ có quá nhiều cách hiểu. Do đó, ngay từ đầu thiết kế, cần chuẩn bị một từ điển dữ liệu chứa các định nghĩa rõ ràng và rõ ràng về tất cả các đối tượng (lớp), thuộc tính, hoạt động, vai trò và các thực thể khác được xem xét trong dự án. Nếu không có từ điển như vậy, việc thảo luận về dự án với các nhà phát triển đồng nghiệp và khách hàng hệ thống là vô nghĩa vì mọi người đều có thể diễn giải các thuật ngữ được thảo luận theo cách riêng của mình.

2.3. Xác định sự phụ thuộc

Ở giai đoạn tiếp theo của việc xây dựng mô hình đối tượng, sự phụ thuộc giữa các lớp được xác định. Trước hết, các thuộc tính là liên kết rõ ràng đến các lớp khác sẽ bị loại khỏi các lớp; các thuộc tính như vậy được thay thế bằng các phụ thuộc. Mục đích của sự thay thế này là các phần phụ thuộc thể hiện sự trừu tượng hóa ở cùng cấp độ với các lớp và do đó không có tác động trực tiếp đến việc triển khai trong tương lai (tham chiếu đến một lớp chỉ là một cách để triển khai các phần phụ thuộc).

Giống như tên của các lớp có thể có được từ các danh từ tìm thấy trong phần trình bày sơ bộ của bài toán ứng dụng, tên của các phần phụ thuộc có thể có có thể được lấy từ các động từ hoặc cụm động từ được tìm thấy trong tài liệu đã chỉ định. Đây là cách họ thường mô tả: vị trí vật lý (follows_behind, is_part, is_contained), hành động được chỉ đạo (leadsto_movement), giao tiếp (talks_to), thuộc về (has, is_part), v.v.

Sau đó, bạn nên xóa các phần phụ thuộc không cần thiết hoặc không chính xác bằng cách sử dụng các tiêu chí sau:

sự phụ thuộc giữa các lớp bị loại trừ phải được loại bỏ hoặc được điều chỉnh lại theo các lớp còn lại;

Cần loại bỏ những phụ thuộc không liên quan và liên quan đến việc triển khai;

hành động: phần phụ thuộc phải mô tả các thuộc tính cấu trúc của miền ứng dụng chứ không phải các sự kiện không quan trọng;

phụ thuộc ba phần: hầu hết các phần phụ thuộc giữa ba lớp trở lên có thể được phân tách thành nhiều phần phụ thuộc nhị phân, sử dụng vòng loại nếu cần thiết; trong một số trường hợp (rất hiếm) việc phân hủy như vậy không thể thực hiện được; ví dụ, sự phụ thuộc ba cấp “Giáo sư đang giảng dạy một khóa học ở phòng 628” không thể phân tách thành nhị phân mà không làm mất thông tin;

các phụ thuộc dẫn xuất: cần loại trừ các phụ thuộc có thể được biểu diễn thông qua các phụ thuộc khác, vì chúng dư thừa; khi loại trừ các phần phụ thuộc dư thừa (dẫn xuất), bạn cần đặc biệt cẩn thận, vì không phải tất cả các phần phụ thuộc trùng lặp giữa các lớp đều dư thừa; trong một số trường hợp, các phụ thuộc khác chỉ cho phép chúng ta thiết lập sự tồn tại của một phụ thuộc dẫn xuất khác, nhưng không cho phép chúng ta thiết lập bội số của sự phụ thuộc này.

Sau khi loại bỏ các phụ thuộc dư thừa, bạn cần làm rõ ngữ nghĩa của các phụ thuộc còn lại như sau:

các phụ thuộc được đặt tên không chính xác: chúng nên được đổi tên để ý nghĩa của chúng trở nên rõ ràng;

tên vai trò: bạn cần thêm tên vai trò khi cần thiết; tên vai trò mô tả vai trò của lớp tương ứng trong một phần phụ thuộc nhất định theo quan điểm của một lớp khác tham gia vào phần phụ thuộc đó; nếu tên vai trò rõ ràng trong tên lớp thì có thể bỏ qua;

vòng loại: bằng cách thêm các vòng loại khi cần thiết, chúng tôi giới thiệu các yếu tố ngữ cảnh, cho phép chúng tôi đạt được sự nhận dạng rõ ràng về các đối tượng; vòng loại cũng giúp đơn giản hóa một số phụ thuộc bằng cách giảm tính bội số của chúng;

tính đa dạng: cần thêm các ký hiệu cho tính đa dạng của các phụ thuộc; Cần nhớ rằng tính đa dạng của các phụ thuộc có thể thay đổi trong quá trình phân tích sâu hơn các yêu cầu hệ thống;

các phụ thuộc không được tính toán phải được xác định và thêm vào mô hình.

2.4. Tinh chỉnh thuộc tính

Ở giai đoạn tiếp theo, hệ thống thuộc tính được làm rõ: thuộc tính lớp được điều chỉnh, thuộc tính mới được giới thiệu nếu cần thiết. Các thuộc tính thể hiện các thuộc tính của đối tượng thuộc lớp được đề cập hoặc xác định trạng thái hiện tại của chúng.

Các thuộc tính thường tương ứng với danh từ; ví dụ: car_color (thuộc tính đối tượng), vị trí con trỏ (trạng thái đối tượng). Các thuộc tính, như một quy luật, ít ảnh hưởng đến cấu trúc của mô hình đối tượng.

Cùng với thuộc tính đối tượng, cũng cần nhập thuộc tính phụ thuộc giữa các lớp (mối quan hệ giữa các đối tượng).

Khi chỉ định các thuộc tính, chúng được hướng dẫn bởi các tiêu chí sau:

Thay thế thuộc tính bằng đối tượng Nếu sự hiện diện của một thực thể nào đó quan trọng hơn giá trị của nó thì đó là một đối tượng; nếu giá trị quan trọng hơn thì đó là một thuộc tính: ví dụ: ông chủ là một đối tượng (bất kể ông chủ là ai , cái chính là có ai đó), lương là một thuộc tính ( tầm quan trọng của nó rất quan trọng); thành phố luôn là một đối tượng, mặc dù trong một số trường hợp, nó có vẻ như là một thuộc tính (ví dụ: thành phố là một phần của địa chỉ công ty); trong trường hợp bạn muốn thành phố là một thuộc tính, bạn nên xác định sự phụ thuộc (chẳng hạn như nằm) giữa các lớp công ty và thành phố.

Vòng loại. Nếu ý nghĩa của một thuộc tính phụ thuộc vào một ngữ cảnh cụ thể thì nó phải được coi là một định tính.

Tên. Tên thường được so khớp tốt hơn theo vòng loại hơn là theo thuộc tính đối tượng; trong mọi trường hợp tên cho phép người ta chọn từ các đối tượng của một tập hợp nhất định thì nó phải được coi là một định tính.

Định danh. Mã định danh đối tượng được liên kết với việc thực hiện chúng. Trong giai đoạn đầu của thiết kế, chúng không nên được coi là thuộc tính.

Các thuộc tính của kết nối. Nếu một thuộc tính nào đó không đặc trưng cho bản thân đối tượng mà là mối quan hệ của nó với một đối tượng (đối tượng) khác, thì đây là thuộc tính của kết nối chứ không phải thuộc tính của đối tượng.

Các giá trị nội tại. Các thuộc tính chỉ xác định trạng thái bên trong của một đối tượng, không thể nhìn thấy bên ngoài đối tượng, nên được loại khỏi việc xem xét.

Chi tiết không quan trọng. Nên bỏ qua các thuộc tính không ảnh hưởng đến việc thực hiện hầu hết các thao tác.

2.5. Cách ly các hệ thống con

Một hệ thống ứng dụng là một tập hợp các đối tượng phụ thuộc lẫn nhau. Mỗi đối tượng được đặc trưng bởi một tập hợp các thuộc tính, các giá trị của chúng xác định trạng thái của đối tượng và một tập hợp các thao tác có thể áp dụng cho đối tượng này. Khi phát triển các hệ thống ứng dụng, thật thuận tiện khi giả định rằng tất cả các thuộc tính của đối tượng là riêng tư (nghĩa là chúng không thể truy cập được bên ngoài đối tượng và để tìm ra giá trị của một thuộc tính của đối tượng khác trong một đối tượng hoặc thay đổi nó, bạn phải sử dụng một trong các hoạt động công khai của đối tượng này, tất nhiên, nếu hoạt động đó được xác định). Hoạt động của đối tượng có thể là công khai hoặc riêng tư.

Do đó, mỗi đối tượng có một giao diện được xác định nghiêm ngặt, tức là một tập hợp các hoạt động công cộng có thể được áp dụng cho đối tượng này. Tất cả các đối tượng của cùng một lớp đều có cùng một giao diện. Giao diện của một lớp (và do đó, của từng đối tượng của lớp này) được chỉ định bởi một danh sách các chữ ký của các hoạt động mở (công khai) của nó (và các phương thức triển khai chúng); chữ ký của các hoạt động đóng không được đưa vào giao diện của các đối tượng thuộc lớp tương ứng.

vân vân.................

Hệ thống ứng dụng đại diện cho một tập hợp các đối tượng phụ thuộc lẫn nhau. Mỗi đối tượng được đặc trưng bởi một tập hợp các thuộc tính, các giá trị của chúng xác định trạng thái của đối tượng và một tập hợp các thao tác có thể áp dụng cho đối tượng này.

Khi phát triển các hệ thống ứng dụng, thật thuận tiện khi giả định rằng tất cả các thuộc tính của đối tượng là riêng tư (nghĩa là chúng không thể truy cập được bên ngoài đối tượng). Hoạt động của đối tượng có thể là công khai hoặc riêng tư.

Do đó, mỗi đối tượng có một giao diện được xác định nghiêm ngặt, tức là một tập hợp các hoạt động công cộng có thể được áp dụng cho đối tượng này. Tất cả các đối tượng của cùng một lớp đều có cùng một giao diện.

Mô hình đối tượng thể hiện cấu trúc thống kê của hệ thống được thiết kế (hệ thống con). Tuy nhiên, kiến ​​thức về cấu trúc tĩnh là chưa đủ để hiểu và đánh giá hệ thống con robot. Cần có các phương tiện để mô tả những thay đổi xảy ra với các đối tượng và các kết nối của chúng trong quá trình hoạt động của hệ thống con.

Một trong những phương tiện này là mô hình động các hệ thống con. Nó được xây dựng sau khi mô hình đối tượng của hệ thống con đã được xây dựng và đã được thống nhất và gỡ lỗi trước đó. Mô hình động của một hệ thống con bao gồm các sơ đồ trạng thái của các đối tượng hệ thống con của nó.

Trạng thái hiện tại của một đối tượng được đặc trưng bởi một tập hợp các giá trị hiện tại của các thuộc tính và mối quan hệ của nó. Trong quá trình hoạt động của hệ thống, các đối tượng cấu thành của nó tương tác với nhau, do đó trạng thái của chúng thay đổi. Đơn vị ảnh hưởng là sự kiện: mỗi sự kiện dẫn đến sự thay đổi trạng thái của một hoặc nhiều đối tượng trong hệ thống hoặc dẫn đến sự xuất hiện của các sự kiện mới. Hoạt động của một hệ thống được đặc trưng bởi chuỗi các sự kiện xảy ra trong đó.

Một sự kiện xảy ra tại một thời điểm nào đó. Ví dụ về các sự kiện: phóng tên lửa, bắt đầu cuộc đua 100 m, bắt đầu nối dây, phát hành tiền, v.v. Sự kiện này không có thời lượng (chính xác hơn là mất một khoảng thời gian không đáng kể).

Nếu các sự kiện không có mối quan hệ nhân quả (tức là chúng độc lập về mặt logic) thì chúng được gọi là độc lập(đồng thời). Những sự kiện như vậy không ảnh hưởng lẫn nhau. Không có ích gì khi sắp xếp các sự kiện độc lập vì chúng có thể xảy ra theo bất kỳ thứ tự nào. Một mô hình hệ thống phân tán nhất thiết phải chứa các sự kiện và hoạt động độc lập.

Chuỗi sự kiện được gọi là kịch bản. Sau khi các kịch bản được phát triển và phân tích, các đối tượng tạo và nhận từng sự kiện kịch bản sẽ được xác định.

Khi một sự kiện xảy ra, không chỉ đối tượng chuyển sang trạng thái mới mà hành động liên quan đến sự kiện này cũng được thực hiện. Một hành động là một thao tác tức thời gắn liền với một sự kiện.

Quá trình xây dựng mô hình đối tượng bao gồm các bước sau:

Định nghĩa các đối tượng và lớp;

Chuẩn bị từ điển dữ liệu:

Xác định sự phụ thuộc giữa các đối tượng;

Xác định tính chất của đối tượng và các kết nối;

Tổ chức và đơn giản hóa các lớp khi sử dụng tính kế thừa;

Tiếp tục nghiên cứu và cải tiến mô hình.

Gửi công việc tốt của bạn trong cơ sở kiến ​​thức thật đơn giản. Sử dụng mẫu dưới đây

Các sinh viên, nghiên cứu sinh, các nhà khoa học trẻ sử dụng nền tảng kiến ​​thức trong học tập và công việc sẽ rất biết ơn các bạn.

Đăng trên http://www.allbest.ru/

GIỚI THIỆU

1.1 Những nguyên lý lý thuyết cơ bản của công nghệ lập trình hướng đối tượng; Các khái niệm cơ bản của phương pháp hướng đối tượng

1.2 Đối tượng khái niệm

2. xây dựng mô hình đối tượng của chủ đề “tổ chức các quy trình của câu lạc bộ thể thao” bằng ngôn ngữ mô hình hóa UML

2.1 Đặc điểm của ngôn ngữ mô hình hóa UML

2.1.1 Tóm tắt lịch sử của UML

2.1.2 Ngôn ngữ UML

2.1.3 Từ vựng UML

2.1.4 Khung nhìn điều khiển mô hình.

3.1 Mô tả cấu trúc ứng dụng

PHẦN KẾT LUẬN

DANH MỤC NGUỒN

Phụ lục A

GIỚI THIỆU

Câu lạc bộ thể thao thực hiện các hoạt động toàn diện nhằm phát triển văn hóa thể chất và thể thao trong thanh thiếu niên và các thành viên trong gia đình họ. Ngày càng có nhiều câu lạc bộ thể thao xuất hiện, trong đó có nhiều chuyên mục thể thao. Quá trình đăng ký thanh niên tham gia vào các phần này mất rất nhiều thời gian và phức tạp. Do đó, câu hỏi về tự động hóa quá trình này ngày càng trở nên phù hợp.

Khi sử dụng máy tính, quá trình này trở nên chính xác và nhanh chóng hơn nhiều, không gặp nhiều phức tạp phát sinh khi tổ chức thủ công.

Các đặc điểm của việc tổ chức các quy trình của câu lạc bộ thể thao được xác định bằng cách sử dụng mô hình đối tượng của lĩnh vực chủ đề. Những mô hình như vậy đặc biệt hữu ích trong việc tổ chức quá trình tính toán cho những người trẻ tuổi tham gia vào các bộ phận câu lạc bộ thể thao, vì việc lập mô hình lĩnh vực chủ đề này giúp có thể kiểm tra đối tượng từ mọi phía và nhờ đó có thể thấy trước mọi vấn đề có thể xảy ra. Ví dụ: khi lập lịch trình, mô hình đối tượng tổ chức quá trình giáo dục cho phép bạn tránh sự chồng chéo phát sinh khi phân bổ giờ cho các phần, vì điểm này sẽ được cung cấp trong quá trình phát triển.

Mô hình đối tượng của một miền có thể được xây dựng bằng ngôn ngữ mô hình hóa đối tượng trực quan UML hoặc dưới dạng sản phẩm phần mềm bằng một số ngôn ngữ lập trình hỗ trợ công nghệ lập trình đối tượng, một ví dụ là ngôn ngữ Object Pascal.

Mục đích của nghiên cứu này là nghiên cứu phương pháp luận và công nghệ lập trình hướng đối tượng sử dụng ví dụ về ngôn ngữ Object Pascal, các phương pháp và công cụ xây dựng mô hình đối tượng của các môn học và vận dụng kiến ​​thức đã học để xây dựng mô hình đối tượng của môn học “ Tổ chức công việc của câu lạc bộ thể thao.”

Để đạt được mục tiêu nghiên cứu này, các nhiệm vụ sau được đặt ra:

· Nghiên cứu các nguyên lý lý thuyết cơ bản của phương pháp hướng đối tượng;

· Xem xét ngôn ngữ UML và xây dựng mô hình đối tượng của lĩnh vực chủ đề sử dụng ngôn ngữ này;

· Phát triển một ứng dụng sử dụng một tập hợp các lớp để thể hiện thông tin về các vận động viên.

Đối tượng nghiên cứu của môn học này là phương pháp thiết kế hướng đối tượng.

Đối tượng của nghiên cứu này là mô hình đối tượng của lĩnh vực chủ đề “Tổ chức công việc của câu lạc bộ thể thao” và các đặc tính chính của nó.

Giả thuyết nghiên cứu là việc triển khai mô hình đối tượng trong môi trường phát triển trực quan Delphi, sử dụng các nguyên tắc cơ bản của phương pháp hướng đối tượng, sẽ đơn giản hóa quá trình thu thập, lưu trữ và xử lý thông tin về những người tham gia câu lạc bộ thể thao.

Ở giai đoạn phân tích môn học và thiết kế cấu trúc ứng dụng, cần xây dựng sơ đồ lớp UML.

Trong quá trình viết đồ án, luận án đã sử dụng các phương pháp nghiên cứu sau:

· Sử dụng phương pháp miêu tả để trình bày những mặt lý luận của vấn đề và mô tả ngắn gọn đặc điểm của đối tượng nghiên cứu;

· Phương pháp so sánh và phân tích. Cho phép bạn so sánh các quan điểm khác nhau về chủ đề đang được xem xét và chẩn đoán đối tượng nghiên cứu;

· Phương pháp tiếp cận hệ thống. Nó được sử dụng để tóm tắt các kết quả thu được và xác định mối quan hệ logic của chúng.

1. NHỮNG ĐIỀU CƠ BẢN LÝ LUẬN CỦA PHƯƠNG PHÁP HƯỚNG MỤC TIÊU

1.1 Các khái niệm cơ bản của cách tiếp cận hướng đối tượng

mô hình lập trình ngôn ngữ môn học

Trong một thời gian dài, lập trình đã sử dụng mô hình có cấu trúc và hướng thủ tục. Việc lựa chọn các mục tiêu của dự án được thực hiện bằng một trong hai cách tiếp cận, được gọi là “từ trên xuống” và theo đó là “từ dưới lên”.

1. Cách tiếp cận “từ trên xuống” ngụ ý rằng nhiệm vụ được chia thành các nhiệm vụ phụ, sau đó các nhiệm vụ này lại được chia thành các nhiệm vụ phụ của cấp độ tiếp theo, v.v. Quá trình này, được gọi là phân rã, tiếp tục cho đến khi việc đơn giản hóa các nhiệm vụ con được giảm xuống thành các hàm cơ bản có thể được hình thức hóa.

2. Cách tiếp cận “từ dưới lên” hàm ý rằng các quy trình được viết ra để giải quyết các vấn đề đơn giản, sau đó chúng được kết hợp lần lượt thành các quy trình phức tạp hơn cho đến khi đạt được hiệu quả mong muốn.

Các khái niệm lập trình quan trọng là lập trình hướng thủ tục và lập trình hướng đối tượng.

Lập trình hướng thủ tục là lập trình bằng ngôn ngữ mệnh lệnh, trong đó các câu lệnh được thực hiện tuần tự có thể được tập hợp thành các chương trình con, tức là các đơn vị mã tích hợp lớn hơn, sử dụng các cơ chế của chính ngôn ngữ đó.

Lập trình hướng đối tượng (OOP) là một phong cách lập trình nắm bắt hành vi trong thế giới thực theo cách che giấu các chi tiết triển khai của nó.

Một đối tượng là một thực thể riêng biệt nổi bật giữa các thực thể khác nhờ các thuộc tính, hành vi và sự tương tác của nó với các đối tượng ứng dụng khác.

Việc sử dụng công nghệ này giúp có thể biểu diễn cấu trúc của chương trình dưới dạng một tập hợp các đối tượng tương tác với nhau. Kết quả của sự tương tác như vậy, được thực hiện bằng cách truyền thông điệp giữa các đối tượng, các chức năng đã chỉ định của chương trình sẽ được triển khai. Sau khi nhận được tin nhắn, một đối tượng có thể thực hiện một hành động cụ thể, được gọi là phương thức.

Có hai điểm khác biệt quan trọng giữa OOP và lập trình hướng thủ tục:

1. Trong OOP, trước tiên người lập trình chọn các lớp từ mô tả của lĩnh vực chủ đề, sau đó xây dựng mô hình đối tượng để giải quyết vấn đề và chỉ sau đó mới tiến hành phân tích các phương thức và thuộc tính của chúng.

2. Các phương thức và thuộc tính được liên kết với một lớp nhằm thực hiện các hoạt động tương ứng.

Nếu chúng ta phân tích cách một người giải quyết các vấn đề thực tế khác nhau trong thế giới xung quanh anh ta, thì chúng ta có thể hiểu rằng thế giới này cũng hướng đối tượng. Ví dụ, để đi làm, một người thường tương tác với một đồ vật như một chiếc xe hơi. Ngược lại, phương tiện bao gồm các vật thể tương tác với nhau, khiến nó chuyển động, nhờ đó một người nhận ra nhiệm vụ của mình - đi đến điểm mong muốn. Đồng thời, cả người lái và hành khách đều không cần phải biết các vật thể tạo nên phương tiện tương tác như thế nào.

Trong lập trình hướng đối tượng, cũng như trong thế giới thực, người dùng chương trình bị cô lập khỏi logic cần thiết để hoàn thành nhiệm vụ. Ví dụ: để in một trang trong trình xử lý văn bản, người dùng gọi một chức năng nhất định bằng cách nhấp vào nút trên thanh công cụ, nhưng không thấy các quy trình bên trong đang diễn ra. Khi in một trang trong khi chương trình đang chạy, sẽ xảy ra sự tương tác phức tạp giữa các đối tượng, từ đó tương tác với máy in.

Khi tạo một chương trình hướng đối tượng, vùng chủ đề được biểu diễn dưới dạng tập hợp các đối tượng được kết hợp thành các lớp. Việc thực thi chương trình bao gồm các đối tượng trao đổi thông điệp (tương tác với nhau). Khi biểu diễn một đối tượng thực thuộc một miền bằng lớp chương trình, cần làm nổi bật các đặc điểm cơ bản của nó trong đối tượng thực và bỏ qua nhiều thuộc tính khác, chỉ giới hạn ở những thuộc tính cần thiết để giải quyết một vấn đề thực tế. Kỹ thuật này được gọi là trừu tượng.

Trừu tượng hóa là việc xác định các đặc điểm cơ bản của một đối tượng để phân biệt nó với các đối tượng khác. Hơn nữa, danh sách các thuộc tính thiết yếu phụ thuộc vào mục đích mô hình hóa và có thể hoàn toàn khác nhau đối với các nhiệm vụ khác nhau. Ví dụ, đối tượng “chuột” theo quan điểm của một nhà sinh vật học di cư, bác sĩ thú y hoặc đầu bếp sẽ có những đặc điểm hoàn toàn khác.

Một lớp là một tập hợp các đối tượng có các thuộc tính và hành vi chung. Do đó, một lớp có thể được định nghĩa là một cộng đồng nhất định của các đối tượng cụ thể, như một mô tả về những gì chúng nên là và những gì chúng nên làm. Nếu các đối tượng thực sự tồn tại trong các ứng dụng thì lớp là một sự trừu tượng hóa, nhóm các đối tượng thành một nhóm theo thuộc tính và hành vi của chúng trong môi trường mà chúng tồn tại và tương tác. Ví dụ: Button1 trên một biểu mẫu, với tất cả các thuộc tính và hành động cụ thể của nó, là một đối tượng của lớp Button.

Hành vi là đặc điểm về cách một đối tượng ảnh hưởng đến các đối tượng khác hoặc tự thay đổi dưới ảnh hưởng của chúng. Hành vi ảnh hưởng đến cách trạng thái của một đối tượng thay đổi.

Công nghệ lập trình hướng đối tượng dựa trên “ba trụ cột”: đóng gói, kế thừa và đa hình.

Đóng gói là thuộc tính kết hợp trạng thái và hành vi trong một cấu trúc, đồng thời ẩn cấu trúc bên trong của một đối tượng và các chi tiết triển khai (từ từ “viên nang”). Một thuộc tính quan trọng của bất kỳ đối tượng nào là sự cô lập của nó. Chi tiết triển khai đối tượng, tức là Các cấu trúc dữ liệu nội bộ và thuật toán để xử lý chúng được ẩn khỏi người dùng đối tượng và không thể tiếp cận được với những thay đổi ngoài ý muốn. Đối tượng được sử dụng thông qua một giao diện - một bộ quy tắc truy cập. Ví dụ, để chuyển một chương trình truyền hình, chúng ta chỉ cần quay số của chương trình đó trên điều khiển từ xa, thao tác này sẽ khởi chạy một cơ chế phức tạp mà cuối cùng sẽ dẫn đến kết quả mong muốn. Chúng ta không nhất thiết cần biết điều gì đang xảy ra trong điều khiển từ xa và TV, chúng ta chỉ cần biết rằng TV có khả năng (phương pháp) này và cách kích hoạt nó. Đóng gói hoặc ẩn triển khai là một thuộc tính cơ bản của OOP. Nó cho phép bạn tạo các đối tượng tùy chỉnh có các phương thức được yêu cầu và sau đó thao tác với chúng mà không cần đi sâu vào cấu trúc của các đối tượng này. Do đó, đóng gói là một cơ chế kết hợp dữ liệu và các phương pháp xử lý (thao tác) dữ liệu này và bảo vệ cả hai khỏi sự can thiệp hoặc lạm dụng từ bên ngoài. Việc đóng gói mã trong một lớp đảm bảo rằng mã không thể bị “phá vỡ” bởi bất kỳ thay đổi nào trong chi tiết triển khai của từng lớp riêng lẻ. Do đó, bạn có thể sử dụng một đối tượng trong môi trường khác và đảm bảo rằng nó sẽ không làm hỏng các vùng bộ nhớ không thuộc về nó. Nếu bạn vẫn cần thay đổi hoặc thêm thứ gì đó vào lớp thì cơ chế kế thừa và đa hình sẽ được sử dụng.

Kế thừa là khả năng dựa trên hệ thống phân cấp của các lớp để kết hợp các thuộc tính và hành vi của các lớp tổ tiên và thêm hành vi và thuộc tính của riêng chúng vào chúng. Hàng năm trên thế giới có rất nhiều chương trình được viết và điều quan trọng là phải sử dụng mã đã được viết sẵn. Ưu điểm của lập trình hướng đối tượng là có thể định nghĩa các đối tượng con cho một đối tượng để sửa chữa hoặc bổ sung cho hành vi của nó. Trong trường hợp này, không chỉ cần lặp lại mã nguồn của đối tượng gốc mà thậm chí còn có quyền truy cập vào nó. Điều này giúp việc sửa đổi chương trình và tạo chương trình mới dựa trên chương trình hiện có trở nên dễ dàng hơn. Chỉ thông qua tính kế thừa, bạn mới có thể sử dụng các đối tượng có mã nguồn không có sẵn nhưng bạn cần thực hiện thay đổi. Do đó, khi kế thừa, bạn không chỉ có thể thêm chức năng mới mà còn có thể thay đổi những chức năng hiện có. Và điều này phần lớn đạt được nhờ tính đa hình.

Tính đa hình (“nhiều dạng”) - khả năng sử dụng cùng một biểu thức để biểu thị các hoạt động khác nhau, khả năng của các lớp con cháu thực hiện phương thức được mô tả cho lớp tổ tiên theo những cách khác nhau, tức là. khả năng thực hiện các hành động khác nhau hoặc truy cập các đối tượng thuộc các loại khác nhau bằng cùng một tên trong khi thực hiện chương trình. Tính đa hình được thực hiện thông qua việc ghi đè phương thức trong các lớp con (phương thức có cùng tên và cùng tham số nhưng hoạt động khác nhau) - đây là cơ chế của các phương thức ảo thông qua liên kết động. Tính đa hình cũng được triển khai dưới dạng "quá tải" các phương thức (một phương thức có cùng tên và các tham số khác nhau) - ví dụ: sử dụng dấu + để biểu thị phép cộng trong một lớp thực hoặc lớp số nguyên và một lớp chuỗi: các thông báo tương tự sẽ cho kết quả hoàn toàn khác nhau. Đa hình cung cấp khả năng trừu tượng hóa các thuộc tính chung.

Tính mô đun là một thuộc tính của một hệ thống đã được phân tách thành các mô đun gắn kết bên trong nhưng có liên kết với nhau yếu.
Trong quá trình chia hệ thống thành các module, hai quy tắc có thể hữu ích. Đầu tiên, vì các mô-đun phục vụ như các khối chương trình cơ bản và không thể phân chia được, có thể được sử dụng lại trong toàn hệ thống, nên việc phân bổ các lớp và đối tượng giữa các mô-đun phải tính đến điều này. Thứ hai, nhiều trình biên dịch tạo đoạn mã riêng cho từng mô-đun. Vì vậy, có thể có những hạn chế về kích thước mô-đun. Tính năng động của các cuộc gọi chương trình con và bố cục khai báo trong các mô-đun có thể ảnh hưởng lớn đến vị trí tham chiếu và quản lý trang bộ nhớ ảo. Khi các thủ tục được mô-đun hóa kém, các cuộc gọi lẫn nhau giữa các phân đoạn trở nên thường xuyên hơn, dẫn đến mất hiệu quả bộ đệm và thay đổi trang thường xuyên.

Khá khó để tập hợp các yêu cầu trái ngược nhau như vậy, nhưng điều chính là phải hiểu rằng việc tách biệt các lớp và đối tượng trong một dự án và việc tổ chức cấu trúc mô-đun là các hành động độc lập. Quá trình cô lập các lớp và đối tượng là một phần của quy trình thiết kế logic của một hệ thống và việc chia thành các mô-đun là một giai đoạn thiết kế vật lý. Tất nhiên, đôi khi không thể hoàn thành thiết kế logic của một hệ thống nếu không hoàn thành thiết kế vật lý và ngược lại. Hai quá trình này được thực hiện lặp đi lặp lại.

Đánh máy là một cách để bảo vệ chống lại việc sử dụng các đối tượng của một lớp thay vì lớp khác, hoặc ít nhất là để kiểm soát việc sử dụng đó.

Tính song song là đặc tính phân biệt đối tượng chủ động với đối tượng thụ động.

Tính bền bỉ là khả năng của một đối tượng tồn tại theo thời gian, tồn tại trong quá trình sinh ra nó và (hoặc) trong không gian, di chuyển từ không gian địa chỉ ban đầu của nó.

Các khái niệm cơ bản của OOP đã được chuyển sang lập trình từ các lĩnh vực kiến ​​thức khác, chẳng hạn như triết học, logic, toán học và ký hiệu học mà không trải qua bất kỳ thay đổi đặc biệt nào, ít nhất là về bản chất của các khái niệm này. Phương pháp phân rã đối tượng (biểu diễn) là tự nhiên và đã được sử dụng trong nhiều thế kỷ. Vì vậy, không có gì ngạc nhiên khi trong quá trình phát triển của công nghệ lập trình, nó đã chiếm được vị trí xứng đáng.

Vì vậy, trong quá trình phát triển các chương trình hướng đối tượng cần:

1. xác định tập hợp các lớp đối tượng hình thành nên nó (phân rã);

2. đối với mỗi lớp đối tượng, chỉ định một tập hợp dữ liệu cần thiết (các trường);

3. đối với mỗi lớp đối tượng, chỉ định một tập hợp các hành động (phương thức) được thực hiện bởi các đối tượng;

4. đối với mỗi lớp đối tượng, chỉ định các sự kiện mà đối tượng sẽ phản ứng và viết các thủ tục xử lý tương ứng.

Mã nguồn phải chứa các mô tả lớp cho tất cả các đối tượng phần mềm. Ngoài ra, các biến phải được mô tả có kiểu là tên của các lớp tương ứng. Các thể hiện của lớp (đối tượng) được tạo trong quá trình thực thi chương trình.

Sau khi được tạo, một thể hiện của một lớp phải nhận các giá trị cho tất cả các trường của nó. Các phiên bản khác nhau của cùng một lớp có thể có các giá trị trường khác nhau nhưng có cùng phương thức. Các trường lớp không có sẵn để truy cập trực tiếp, bao gồm cả bài tập. Điều này được thực hiện để tăng độ tin cậy của các chương trình. Thay vì gán trực tiếp một giá trị cho một trường đối tượng, một lệnh gọi phải được thực hiện theo một phương thức đặc biệt của lớp tương ứng, thực hiện phép gán đó và giám sát tính chính xác của giá trị đã nhập. Tương tự, các phương thức lớp đặc biệt cũng có thể được sử dụng để đọc giá trị của một trường. Để kết nối các trường với các phương thức đọc/ghi giá trị của chúng, các thành viên lớp được gọi là thuộc tính sẽ được sử dụng. Người dùng khi nhập dữ liệu để ghi vào các trường của đối tượng hoặc đọc giá trị của các trường sẽ xử lý các thuộc tính đại diện cho các trường này. Do đó, thuật ngữ "giá trị thuộc tính" thường được sử dụng thay cho thuật ngữ "giá trị trường".

Thành viên của lớp có thể là:

1. trường dùng để lưu trữ dữ liệu;

2. tài sản như một phương tiện truy cập vào các trường riêng tư;

3. các phương thức xác định chức năng của đối tượng;

4. các sự kiện và trình xử lý chúng như phương tiện quản lý chương trình.

1.2 Đối tượng khái niệm

Cách tiếp cận lập trình hướng đối tượng gợi ý rằng mọi thứ là một phần của ứng dụng đều được coi là các đối tượng tương tác với nhau và với người dùng theo các thuộc tính và hành vi được chỉ định trong chương trình, thực hiện các chức năng cần thiết của ứng dụng. Do đó, bất kỳ ứng dụng nào áp dụng phương pháp này đều là một tập hợp các đối tượng được kết nối với nhau nhằm thực hiện các yêu cầu chức năng cần thiết cho ứng dụng.

Một đối tượng luôn cụ thể và thực sự tồn tại dưới dạng hoặc ứng dụng, trong khi chỉ sở hữu các thuộc tính và hành vi riêng của nó. Đặc điểm của các đối tượng để phân biệt chúng với nhau là thuộc tính và hành vi của chúng. Trong thế giới thực, mỗi đối tượng hoặc quy trình có một tập hợp các đặc tính tĩnh và động (thuộc tính và hành vi). 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 tác động bên ngoài. Ví dụ, một vật “ô tô” sẽ không đi đến đâu nếu không có xăng trong bình, và nếu bạn bẻ lái thì vị trí của các bánh xe sẽ thay đổi. Do đó, một đối tượng được biểu diễn dưới dạng một tập hợp dữ liệu mô tả trạng thái và phương thức (thủ tục và hàm) của nó để xử lý chúng, mô hình hóa hành vi của nó. Việc gọi một thủ tục hoặc hàm để thực thi thường được gọi là gửi tin nhắn đến một đối tượng (ví dụ gọi thủ tục “quay vô lăng” thường được hiểu là gửi tin nhắn “ô tô, quay vô lăng!”). Như vậy, mỗi đối tượng được đặc trưng bởi các khái niệm cơ bản sau:

1. phương thức là một hàm hoặc thủ tục thực hiện các hành động có thể thực hiện được với một đối tượng;

2. Sự kiện là phương tiện tương tác giữa các sự vật với nhau. Các đối tượng tạo ra các sự kiện được chỉ định và thực hiện các hành động để phản hồi lại các sự kiện được chỉ định. Các sự kiện tương tự như các thông điệp mà các đối tượng nhận và gửi;

3. trạng thái - mỗi đối tượng luôn ở một trạng thái nhất định, được đặc trưng bởi một tập hợp các thuộc tính của đối tượng. Dưới tác động của các sự kiện, một vật chuyển sang trạng thái khác. Trong trường hợp này, bản thân đối tượng có thể tạo ra các sự kiện khi chuyển sang trạng thái khác;

4. Thuộc tính - một dấu hiệu, một số phẩm chất (tham số) riêng biệt của một đối tượng.

Ví dụ: thuộc tính có thể là kích thước của một đối tượng, tiêu đề, tên của nó. Tập hợp các thuộc tính của một đối tượng xác định trạng thái của nó. Thông thường, các thuộc tính là một tập hợp các biến và hằng lưu trữ các giá trị xác định các tham số của một đối tượng.

Cần lưu ý rằng cùng với những vật chất, các vật thể trừu tượng cũng có thể tồn tại, đại diện điển hình của chúng là những con số. Vì vậy, một đối tượng là bất kỳ thực thể vật lý hoặc trừu tượng nào có thể nhận dạng rõ ràng và rõ ràng của một miền.

Các đối tượng được đặc trưng bởi các thuộc tính. Vì vậy, ví dụ, các thuộc tính của một chiếc ô tô là tốc độ tối đa, công suất động cơ, màu sắc thân xe, v.v. Các thuộc tính của bộ khuếch đại là dải tần, công suất đầu ra, độ méo sóng hài, độ ồn, v.v.

Ngoài các thuộc tính, các đối tượng còn có một số chức năng, trong OOP được gọi là thao tác, hàm hoặc phương thức. Vì vậy, một chiếc ô tô có thể lái, một con tàu có thể lái, một máy tính có thể thực hiện các phép tính.

Bằng cách này, một đối tượng đóng gói các thuộc tính và phương thức, ẩn việc triển khai nó khỏi các đối tượng khác tương tác với nó và sử dụng chức năng của nó.

Cách tiếp cận hướng đối tượng dựa trên việc sử dụng có hệ thống các mô hình để phát triển hệ thống phần mềm không phụ thuộc vào ngôn ngữ, dựa trên tính thực dụng của nó.

Thuật ngữ cuối cùng cần được làm rõ. Pragmatics được xác định bởi mục đích phát triển hệ thống phần mềm: phục vụ khách hàng ngân hàng, quản lý hoạt động của sân bay, phục vụ World Cup, v.v. Việc xây dựng mục tiêu liên quan đến các đối tượng và khái niệm về thế giới thực có liên quan đến hệ thống phần mềm đang được phát triển (xem Hình 1.2.1).

Với cách tiếp cận hướng đối tượng, các đối tượng và khái niệm này được thay thế bằng mô hình của chúng, tức là. những cấu trúc hình thức nhất định đại diện cho chúng trong một hệ thống phần mềm.

Hình.1.2.1 Ngữ nghĩa.

Mô hình không chứa tất cả các tính năng và thuộc tính của đối tượng (khái niệm) mà nó đại diện mà chỉ chứa những tính năng và thuộc tính cần thiết cho hệ thống phần mềm đang được phát triển. Do đó, mô hình “kém hơn” và do đó đơn giản hơn đối tượng (khái niệm) mà nó đại diện. Nhưng điều quan trọng thậm chí không phải là điều này mà là mô hình là một cấu trúc hình thức: bản chất hình thức của các mô hình cho phép chúng ta xác định sự phụ thuộc hình thức giữa chúng và các hoạt động hình thức lên chúng. Điều này giúp đơn giản hóa cả việc phát triển và nghiên cứu (phân tích) các mô hình cũng như việc triển khai chúng trên máy tính. Đặc biệt, bản chất hình thức của các mô hình cho phép chúng ta có được mô hình hình thức của hệ thống phần mềm đang được phát triển dưới dạng tổng hợp các mô hình hình thức của các thành phần của nó.

Vì vậy, cách tiếp cận hướng đối tượng giúp giải quyết các vấn đề phức tạp như

· giảm độ phức tạp của phần mềm;

· tăng độ tin cậy của phần mềm;

· cung cấp khả năng sửa đổi các thành phần phần mềm riêng lẻ mà không thay đổi các thành phần còn lại của nó;

· đảm bảo khả năng tái sử dụng các thành phần phần mềm riêng lẻ.

Ứng dụng có hệ thống của cách tiếp cận hướng đối tượng cho phép phát triển các hệ thống phần mềm có cấu trúc tốt, đáng tin cậy và khá dễ dàng sửa đổi. Điều này giải thích sự quan tâm của các lập trình viên đối với cách tiếp cận hướng đối tượng và ngôn ngữ lập trình hướng đối tượng. Cách tiếp cận hướng đối tượng là một trong những lĩnh vực phát triển nhanh nhất của lập trình lý thuyết và ứng dụng.

1.3 Công cụ thực hiện công nghệ lập trình hướng đối tượng

Trong công nghệ OOP, mối quan hệ giữa dữ liệu và thuật toán thường xuyên hơn: thứ nhất, một lớp (khái niệm cơ bản của công nghệ này) kết hợp dữ liệu (biến cấu trúc) và các phương thức (hàm). Thứ hai, mô hình tương tác giữa các chức năng và dữ liệu về cơ bản là khác nhau. Một phương thức (hàm) được gọi trên một đối tượng thường không gọi trực tiếp một hàm khác. Đầu tiên, anh ta phải có quyền truy cập vào một đối tượng khác (tạo, lấy con trỏ, sử dụng đối tượng bên trong trong đối tượng hiện tại, v.v.), sau đó anh ta có thể gọi một trong các phương thức đã biết trên đó. Như vậy, cấu trúc của chương trình được xác định bởi sự tương tác của các đối tượng thuộc các lớp khác nhau với nhau. Theo quy định, có một hệ thống phân cấp các lớp và công nghệ OOP có thể được gọi là lập trình “lớp này đến lớp khác”.

Bất kỳ chương trình nào được thực hiện theo một trong bốn nguyên tắc:

nguyên lý mô-đun hóa

nguyên tắc “từ tổng quát đến cụ thể”

· nguyên tắc từng bước

· nguyên lý cấu trúc

Lập trình mô-đun. Nguyên tắc mô đun hóa được xây dựng như yêu cầu phát triển một chương trình dưới dạng một tập hợp các mô đun (chức năng). Trong trường hợp này, việc phân chia thành các mô-đun không nên mang tính chất máy móc mà dựa trên logic của chương trình:

1. kích thước mô-đun phải được giới hạn;

2. mô-đun phải thực hiện một hành động hoàn chỉnh và hợp lý về mặt logic;

3. mô-đun phải có tính phổ quát, nghĩa là, bất cứ khi nào có thể, được tham số hóa: tất cả các đặc điểm có thể thay đổi của hành động đang được thực hiện phải được truyền qua các tham số;

4. Nên truyền các tham số đầu vào và kết quả của mô-đun không phải thông qua các biến toàn cục mà thông qua các tham số hình thức và kết quả của hàm.

Một đơn vị vật lý khác nhưng đã có của chương trình là một tệp văn bản chứa một số hàm và định nghĩa về các kiểu dữ liệu và biến. Lập trình mô-đun cấp độ tệp là khả năng chia văn bản hoàn chỉnh của chương trình thành nhiều tệp. Nguyên tắc mô-đun không chỉ áp dụng cho các chương trình mà còn cho dữ liệu: bất kỳ tập hợp tham số nào đặc trưng cho đối tượng logic hoặc vật lý phải được biểu diễn trong chương trình dưới dạng một cấu trúc dữ liệu duy nhất (biến có cấu trúc).

Hiện thân của nguyên lý mô-đun là thư viện các hàm tiêu chuẩn. Nó thường cung cấp một tập hợp đầy đủ các hành động được tham số hóa bằng cách sử dụng các cấu trúc dữ liệu phổ biến. Thư viện là các chương trình tương tự, được dịch độc lập và đặt trong danh mục thư viện.

Lập trình từ trên xuống. Thiết kế chương trình từ trên xuống là quá trình phát triển tiến hành từ công thức chung không chính thức của một số hành động chương trình bằng ngôn ngữ tự nhiên, “từ chung đến cụ thể”: đến thay thế nó bằng một trong ba cấu trúc ngôn ngữ lập trình chính thức:

· chuỗi hành động đơn giản;

· các cấu trúc lựa chọn hoặc các câu lệnh if;

· Cấu trúc lặp lại hoặc chu kỳ.

Trong ký hiệu của thuật toán, điều này tương ứng với sự chuyển động từ cấu trúc bên ngoài (bao gồm) sang cấu trúc bên trong (lồng nhau). Những thiết kế này cũng có thể chứa các mô tả không chính thức về các hành động trong các phần của chúng, nghĩa là, thiết kế từ trên xuống có tính chất là từng bước. Chúng ta hãy lưu ý các tính chất chính của phương pháp này:

· Ban đầu chương trình được xây dựng dưới dạng một số hành động không chính thức bằng ngôn ngữ tự nhiên;

· Các tham số đầu vào và kết quả của hành động được xác định ban đầu;

· Bước chi tiết tiếp theo không làm thay đổi cấu trúc của chương trình thu được ở các bước trước;

· nếu trong quá trình thiết kế thu được các hành động giống nhau ở các nhánh khác nhau, thì điều này có nghĩa là cần phải thiết kế hành động này như một chức năng riêng biệt;

· Các cấu trúc dữ liệu cần thiết được thiết kế đồng thời với việc chi tiết hóa chương trình.

Lập trình từng bước. Thiết kế từ trên xuống có bản chất tăng dần vì nó liên quan đến việc thay thế một công thức bằng lời nói mỗi lần bằng một cấu trúc ngôn ngữ duy nhất. Nhưng trong quá trình phát triển một chương trình, có thể có những bước khác liên quan đến việc đặc tả công thức bằng lời nói thành những công thức chi tiết hơn.

Việc nguyên tắc này được nêu bật riêng biệt cho thấy sự cần thiết phải ngăn chặn sự cám dỗ để trình bày chi tiết chương trình ngay lập tức từ đầu đến cuối và phát triển khả năng làm nổi bật và tập trung sự chú ý vào các chi tiết chính chứ không phải chi tiết phụ của thuật toán.

Nói chung, thiết kế chương trình từng bước từ trên xuống không đảm bảo chương trình “đúng”, nhưng nó cho phép bạn quay lại một trong các bước chi tiết phía trên khi phát hiện thấy bế tắc.

Lập trình có cấu trúc. Với việc sàng lọc chương trình từng bước từ trên xuống, các cấu trúc dữ liệu và các biến cần thiết cho hoạt động sẽ xuất hiện khi chúng ta chuyển từ các định nghĩa không chính thức sang các cấu trúc ngôn ngữ, nghĩa là các quá trình chi tiết hóa thuật toán và dữ liệu diễn ra song song. Tuy nhiên, điều này chủ yếu áp dụng cho các biến cục bộ riêng lẻ và các tham số nội bộ. Theo quan điểm chung nhất, đối tượng (trong trường hợp của chúng tôi là dữ liệu) luôn là đối tượng chính so với các hành động được thực hiện với nó (trong trường hợp của chúng tôi là thuật toán). Do đó, trên thực tế, cách chương trình tổ chức dữ liệu có tác động đáng kể đến cấu trúc thuật toán của nó hơn bất kỳ điều gì khác và quá trình thiết kế cấu trúc dữ liệu phải diễn ra trước quá trình thiết kế thuật toán để xử lý chúng.

Lập trình có cấu trúc là thiết kế mô-đun, từ trên xuống, từng bước của thuật toán và cấu trúc dữ liệu.

Cách tiếp cận lập trình hướng đối tượng bao gồm 3 thành phần chính:

· phân tích hướng đối tượng (OOA),

· Thiết kế hướng đối tượng (OOD),

· Lập trình hướng đối tượng (OOP).

Trong bất kỳ ngành kỹ thuật nào, thiết kế thường đề cập đến một cách tiếp cận thống nhất thông qua đó chúng ta tìm cách giải quyết một vấn đề cụ thể, đảm bảo rằng nhiệm vụ được hoàn thành. Trong bối cảnh thiết kế kỹ thuật, mục tiêu thiết kế được xác định là tạo ra một hệ thống

· đáp ứng các thông số kỹ thuật chức năng nhất định (có thể không chính thức);

· phù hợp với những hạn chế do thiết bị áp đặt;

· đáp ứng các yêu cầu rõ ràng và tiềm ẩn về hiệu suất và mức tiêu thụ tài nguyên;

· đáp ứng các tiêu chí thiết kế sản phẩm rõ ràng và tiềm ẩn;

· đáp ứng các yêu cầu đối với chính quá trình phát triển, chẳng hạn như thời gian và chi phí, cũng như việc sử dụng các công cụ bổ sung.

Thiết kế liên quan đến việc tính đến các yêu cầu xung đột. Sản phẩm của nó là những mô hình cho phép chúng tôi hiểu cấu trúc của hệ thống trong tương lai, cân bằng các yêu cầu và phác thảo kế hoạch triển khai.

Chương trình là một mô hình số của hệ thống đang được thiết kế (Hình 1.3.1.)

Cơm. 1.3.1. Cấu trúc chương trình.

Tầm quan trọng của việc xây dựng mô hình Mô hình hóa được phổ biến rộng rãi trong tất cả các ngành kỹ thuật, phần lớn là do nó thực hiện các nguyên tắc phân rã, trừu tượng hóa và phân cấp. Mỗi mô hình mô tả một phần nhất định của hệ thống đang được xem xét và đến lượt chúng tôi xây dựng các mô hình mới dựa trên các mô hình cũ mà chúng tôi ít nhiều tin tưởng. Các mô hình cho phép chúng ta kiểm soát những thất bại của mình. Chúng tôi đánh giá hành vi của từng mô hình trong các tình huống bình thường và bất thường, sau đó thực hiện các điều chỉnh phù hợp nếu chúng tôi không hài lòng với điều gì đó.

Các thành phần của thiết kế phần mềm. Rõ ràng là không có phương pháp chung nào có thể hướng dẫn kỹ sư phần mềm từ các yêu cầu của một hệ thống phần mềm phức tạp đến việc triển khai chúng. Thiết kế một hệ thống phần mềm phức tạp không phải là mù quáng tuân theo một loạt công thức nấu ăn. Đúng hơn, nó là một quá trình dần dần và lặp đi lặp lại. Chưa hết, việc sử dụng một phương pháp thiết kế sẽ mang lại một tổ chức nhất định cho quá trình phát triển. Các kỹ sư phần mềm đã phát triển hàng tá phương pháp khác nhau, chúng ta có thể phân loại thành ba loại. Bất chấp sự khác biệt, những phương pháp này có điểm chung. Đặc biệt, chúng được thống nhất bởi những điều sau:

· ký hiệu - ngôn ngữ mô tả từng mô hình;

· quy trình - quy tắc thiết kế mô hình;

· công cụ - công cụ giúp tăng tốc quá trình tạo mô hình và trong đó đã thể hiện quy luật hoạt động của các mô hình. Công cụ giúp xác định lỗi trong quá trình phát triển.

Một phương pháp thiết kế tốt phải dựa trên nền tảng lý thuyết vững chắc đồng thời cho phép người lập trình có được sự tự do ngôn luận ở một mức độ nhất định.

Các mô hình hướng đối tượng. Sẽ hữu ích nhất khi tạo các mô hình tập trung vào các đối tượng được tìm thấy trong chính miền đó, tạo thành cái được gọi là phân rã hướng đối tượng.

Phân tích và thiết kế hướng đối tượng là một phương pháp dẫn đến phân rã hướng đối tượng một cách hợp lý. Sử dụng thiết kế hướng đối tượng, các chương trình được tạo ra một cách linh hoạt và được viết theo cách tiết kiệm chi phí. Bằng cách phân chia không gian trạng thái một cách khôn ngoan, chúng ta có được sự tự tin lớn hơn về tính đúng đắn của chương trình. Nhờ đó, chúng tôi giảm thiểu rủi ro khi phát triển các hệ thống phần mềm phức tạp.

Vì việc xây dựng các mô hình là cực kỳ quan trọng khi thiết kế các hệ thống phức tạp, nên thiết kế hướng đối tượng cung cấp nhiều lựa chọn mô hình (thể hiện trong Hình 1.3.2). Các mô hình thiết kế hướng đối tượng phản ánh hệ thống phân cấp của cả các lớp và đối tượng hệ thống. Những mô hình này bao gồm đầy đủ các quyết định thiết kế quan trọng phải được xem xét khi thiết kế một hệ thống phức tạp và do đó truyền cảm hứng cho chúng tôi tạo ra các thiết kế thể hiện tất cả năm thuộc tính của các hệ thống phức tạp được thiết kế tốt.

Cơm. 1.3.2 Mô hình hướng đối tượng.

OOP là một hệ tư tưởng lập trình dựa trên việc kết hợp dữ liệu và các thủ tục có thể hoạt động chung với dữ liệu này, được gọi là các lớp.

Bản chất của OOP là việc sử dụng mô hình đối tượng quen thuộc trong cuộc sống hàng ngày. Mỗi đối tượng có thuộc tính riêng và bạn có thể thực hiện các hành động cụ thể cho nó. Một lớp là một loại đối tượng. Lớp mô tả và thực hiện các thuộc tính và hành động tương tự. Một đối tượng, theo cách hiểu của chúng tôi, sẽ là một biến, loại của nó sẽ là một loại lớp nào đó. Chúng ta sẽ gọi các trường của một lớp là thuộc tính của nó và các phương thức của nó là các hành động có thể được thực hiện với một thể hiện của lớp (đối tượng) này.

Để làm ví dụ về việc triển khai lớp, chúng ta hãy xem việc triển khai khái niệm một cuốn sách bằng cách sử dụng một lớp để xác định cách trình bày của cuốn sách TBook và một tập hợp các hàm để làm việc với các biến thuộc loại này:

Số trang: số nguyên;

hàm CompareWithBook(OtherBook: TBook): số nguyên;

thủ tục ShowTitle;

hàm tạo Tạo (NewTitle, New

Khả năng nhận thức của con người còn hạn chế; chúng ta có thể mở rộng ranh giới của chúng bằng cách sử dụng phân tách, trừu tượng hóa và phân cấp.

Các hệ thống phức tạp có thể được nghiên cứu bằng cách tập trung vào các đối tượng hoặc quy trình; Có nhiều lý do chính đáng để sử dụng phân rã hướng đối tượng, trong đó thế giới được xem như một tập hợp có trật tự các đối tượng, trong quá trình tương tác với nhau, sẽ xác định hành vi của hệ thống.

Phân tích và thiết kế hướng đối tượng là phương pháp sử dụng phân rã đối tượng; Cách tiếp cận hướng đối tượng có ký hiệu riêng và cung cấp một tập hợp phong phú các mô hình vật lý và logic mà nhờ đó chúng ta có thể có được ý tưởng về các khía cạnh khác nhau của hệ thống đang được xem xét.

2. XÂY DỰNG MÔ HÌNH ĐỐI TƯỢNG CỦA LĨNH VỰC CHỦ ĐỀ “TỔ CHỨC QUY TRÌNH CÂU LẠC BỘ THỂ THAO” SỬ DỤNG NGÔN NGỮ MÔ HÌNH UML

2.1 Khái niệm về ngôn ngữ UML

UML (Ngôn ngữ mô hình hóa thống nhất) là ngôn ngữ mô hình hóa đồ họa thống nhất để mô tả, trực quan hóa, thiết kế và ghi lại các hệ thống hướng đối tượng. UML được thiết kế để hỗ trợ quá trình mô hình hóa phần mềm dựa trên cách tiếp cận hướng đối tượng, tổ chức mối quan hệ giữa các khái niệm khái niệm và phần mềm, đồng thời phản ánh các vấn đề về mở rộng quy mô các hệ thống phức tạp. Các mô hình UML được sử dụng ở tất cả các giai đoạn của vòng đời phần mềm, từ phân tích kinh doanh đến bảo trì hệ thống. Các tổ chức khác nhau có thể sử dụng UML khi họ thấy phù hợp, tùy thuộc vào vấn đề của họ và công nghệ họ sử dụng.

2.1.1 Tóm tắt lịch sử của UML

Vào giữa những năm 90, nhiều tác giả khác nhau đã đề xuất hàng chục phương pháp mô hình hóa hướng đối tượng, mỗi phương pháp sử dụng ký hiệu đồ họa riêng. Đồng thời, bất kỳ phương pháp nào trong số này đều có điểm mạnh nhưng không cho phép xây dựng một mô hình phần mềm đủ hoàn chỉnh, hiển thị nó “từ mọi phía”, tức là tất cả các dự đoán cần thiết. Ngoài ra, việc thiếu tiêu chuẩn cho mô hình hướng đối tượng khiến các nhà phát triển gặp khó khăn trong việc lựa chọn phương pháp phù hợp nhất, điều này cản trở việc áp dụng rộng rãi cách tiếp cận hướng đối tượng để phát triển phần mềm.

Theo yêu cầu của Nhóm quản lý đối tượng (OMG), tổ chức chịu trách nhiệm áp dụng các tiêu chuẩn trong lĩnh vực công nghệ đối tượng và cơ sở dữ liệu, vấn đề cấp thiết về thống nhất và tiêu chuẩn hóa đã được các tác giả của ba phương pháp hướng đối tượng phổ biến nhất - G giải quyết. Butch, D. Rambo và A. Jacobson, những người đã cộng tác để tạo ra UML 1.1, được OMG áp dụng làm tiêu chuẩn vào năm 1997.

Trước sự quan tâm ngày càng tăng đối với UML, các công ty như Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software đã tham gia phát triển các phiên bản mới của ngôn ngữ trong tập đoàn UML Partners. , Texas Instruments và Unisys. Kết quả của công việc chung là đặc tả UML 1.0, được phát hành vào tháng 1 năm 1997. Tiếp theo là phiên bản 1.1 vào tháng 11 cùng năm, bao gồm những cải tiến về ký hiệu cũng như một số phần mở rộng ngữ nghĩa. UML 1.4.2 đã được ISO/IEC 19501:2005 áp dụng làm tiêu chuẩn quốc tế.

Đặc tả chính thức cho phiên bản mới nhất của UML 2.0 được xuất bản vào tháng 8 năm 2005. Ngữ nghĩa của ngôn ngữ đã được tinh chỉnh và mở rộng đáng kể để hỗ trợ phương pháp Phát triển theo hướng mô hình - MDD. Phiên bản mới nhất của UML 2.4.1 được xuất bản vào tháng 8 năm 2011. UML 2.4.1 đã được ISO/IEC 19505-1, 19505-2 áp dụng làm tiêu chuẩn quốc tế.

2.1.2 ngôn ngữ UML

Bất kỳ ngôn ngữ nào cũng bao gồm từ vựng và quy tắc kết hợp các từ để tạo ra các cấu trúc có ý nghĩa. Đặc biệt, đây là cách cấu trúc các ngôn ngữ lập trình, chẳng hạn như UML. Đặc điểm nổi bật của nó là vốn từ vựng của ngôn ngữ được hình thành bởi các yếu tố đồ họa. Mỗi ký hiệu đồ họa có một ngữ nghĩa cụ thể được liên kết với nó, do đó, một mô hình do một nhà phát triển tạo ra có thể được người khác hiểu rõ ràng, cũng như bởi một công cụ phần mềm diễn giải UML. Cụ thể, từ đây, mô hình phần mềm được trình bày trong UML có thể được dịch tự động sang ngôn ngữ lập trình OO (chẳng hạn như Java, C++, VisualBasic), nghĩa là nếu có một công cụ tạo mô hình trực quan tốt hỗ trợ UML, có đã xây dựng mô hình, chúng ta cũng sẽ nhận được mã chương trình mẫu tương ứng với mô hình này.

Cần nhấn mạnh rằng UML là một ngôn ngữ, không phải một phương pháp. Nó giải thích những yếu tố nào để tạo mô hình và cách đọc chúng, nhưng không nói gì về mô hình nào sẽ được phát triển và trong trường hợp nào. Để tạo một phương pháp dựa trên UML, cần bổ sung thêm mô tả về quy trình phát triển phần mềm. Một ví dụ về quy trình như vậy là Quy trình hợp nhất hợp lý, sẽ được thảo luận trong các bài viết tiếp theo.

2.1.3 Từ điển UML

Mô hình được thể hiện dưới dạng các thực thể và mối quan hệ giữa chúng, được thể hiện dưới dạng sơ đồ.

Các thực thể là sự trừu tượng hóa, là thành phần cơ bản của mô hình. Có bốn loại thực thể - cấu trúc (lớp, giao diện, thành phần, trường hợp sử dụng, cộng tác, nút), hành vi (tương tác, trạng thái), nhóm (gói) và chú thích (nhận xét). Mỗi loại thực thể có biểu diễn đồ họa riêng. Các thực thể sẽ được thảo luận chi tiết khi nghiên cứu sơ đồ.

Mối quan hệ cho thấy các kết nối khác nhau giữa các thực thể. UML định nghĩa các loại mối quan hệ sau:

· Sự phụ thuộc thể hiện mối liên hệ như vậy giữa hai thực thể khi một sự thay đổi ở một trong số chúng - độc lập - có thể ảnh hưởng đến ngữ nghĩa của thực thể kia - phụ thuộc. Sự phụ thuộc được thể hiện bằng một mũi tên chấm hướng từ thực thể phụ thuộc đến thực thể độc lập.

· Liên kết là mối quan hệ mang tính cấu trúc thể hiện rằng các đối tượng của thực thể này được liên kết với các đối tượng của thực thể khác. Về mặt đồ họa, mối liên kết được hiển thị dưới dạng đường nối các thực thể liên quan. Các hiệp hội phục vụ để điều hướng giữa các đối tượng. Ví dụ: một mặt, sự liên kết giữa các lớp “Đơn hàng” và “Sản phẩm” có thể được sử dụng để tìm tất cả các sản phẩm được chỉ định theo một đơn hàng cụ thể hoặc mặt khác để tìm tất cả các đơn hàng có chứa sản phẩm này. Rõ ràng là các chương trình tương ứng phải triển khai một cơ chế cung cấp khả năng điều hướng như vậy. Nếu chỉ cần điều hướng theo một hướng, nó sẽ được biểu thị bằng một mũi tên ở cuối liên kết. Một trường hợp đặc biệt của liên kết là tập hợp - mối quan hệ có dạng “toàn bộ” - “một phần”. Về mặt đồ họa, nó được làm nổi bật bằng một viên kim cương ở cuối gần toàn bộ bản chất.

· Khái quát hóa là mối quan hệ giữa thực thể mẹ và thực thể con. Về cơ bản, mối quan hệ này phản ánh tính chất kế thừa của các lớp và đối tượng. Việc khái quát hóa được biểu diễn dưới dạng một đường kết thúc bằng hình tam giác hướng về thực thể mẹ. Con kế thừa cấu trúc (thuộc tính) và hành vi (phương thức) của cha mẹ, nhưng đồng thời nó có thể có các phần tử cấu trúc mới và các phương thức mới. UML cho phép đa kế thừa, trong đó một thực thể có liên quan đến nhiều thực thể cha.

· Triển khai - mối quan hệ giữa một thực thể xác định đặc tả hành vi (giao diện) với một thực thể xác định việc triển khai hành vi này (lớp, thành phần). Mối quan hệ này thường được sử dụng khi lập mô hình các thành phần và sẽ được mô tả chi tiết hơn trong các bài viết tiếp theo.

Sơ đồ. UML cung cấp các sơ đồ sau:

· Sơ đồ mô tả hoạt động của hệ thống:

Sơ đồ trạng thái

· Sơ đồ hoạt động,

· Sơ đồ đối tượng,

Sơ đồ trình tự

· Sơ đồ cộng tác;

· Sơ đồ mô tả triển khai vật lý của hệ thống:

· Sơ đồ thành phần;

· Sơ đồ triển khai.

2.1.4 Cơ cấu quản lý mô hình

Để con người có thể hiểu rõ một mô hình, cần phải tổ chức nó theo thứ bậc, để lại một số lượng nhỏ các thực thể ở mỗi cấp độ của hệ thống phân cấp. UML bao gồm một phương tiện tổ chức biểu diễn theo cấp bậc của một mô hình - các gói. Bất kỳ mô hình nào cũng bao gồm một tập hợp các gói có thể chứa các lớp, trường hợp sử dụng cũng như các thực thể và sơ đồ khác. Một gói có thể chứa các gói khác, cho phép tạo ra các hệ thống phân cấp. UML không cung cấp các sơ đồ gói riêng biệt nhưng chúng có thể xuất hiện trong các sơ đồ khác. Gói được mô tả dưới dạng hình chữ nhật có dấu trang.

UML cung cấp.

· mô tả phân cấp của một hệ thống phức tạp bằng cách làm nổi bật các gói;

· chính thức hóa các yêu cầu chức năng cho hệ thống bằng cách sử dụng bộ máy của các trường hợp sử dụng;

· chi tiết hóa các yêu cầu hệ thống bằng cách xây dựng sơ đồ và kịch bản hoạt động;

· xác định các lớp dữ liệu và xây dựng mô hình dữ liệu khái niệm dưới dạng sơ đồ lớp;

· xác định các lớp mô tả giao diện người dùng và tạo sơ đồ điều hướng màn hình;

· mô tả các quá trình tương tác giữa các đối tượng khi thực hiện các chức năng của hệ thống;

· mô tả hành vi của các đối tượng dưới dạng biểu đồ hoạt động và trạng thái;

· mô tả các thành phần phần mềm và sự tương tác của chúng thông qua các giao diện;

· mô tả kiến ​​trúc vật lý của hệ thống.

UML sẽ khó sử dụng trong mô hình hóa phần mềm thực tế nếu không có các công cụ mô hình hóa trực quan. Những công cụ như vậy cho phép bạn nhanh chóng trình bày sơ đồ trên màn hình hiển thị, ghi lại chúng, tạo mẫu mã chương trình bằng nhiều ngôn ngữ lập trình hướng đối tượng khác nhau và tạo sơ đồ cơ sở dữ liệu. Hầu hết trong số chúng bao gồm khả năng tái cấu trúc mã chương trình - khôi phục các dự đoán nhất định của mô hình phần mềm bằng cách tự động phân tích mã nguồn của chương trình, điều này rất quan trọng để đảm bảo tính nhất quán giữa mô hình và mã và khi thiết kế hệ thống kế thừa chức năng của hệ thống tiền nhiệm.

2.2 Mô tả chức năng của chuyên đề “Tổ chức hoạt động của câu lạc bộ thể thao”

Tùy thuộc vào bản chất của mối liên hệ giữa các bộ phận của doanh nghiệp, các loại cơ cấu tổ chức sau được phân biệt: tuyến tính, chức năng, chức năng tuyến tính và ma trận.

Công việc của câu lạc bộ thể thao này sử dụng cơ cấu quản lý tuyến tính.

Câu lạc bộ thể thao giải quyết các vấn đề sau:

· sự tham gia của thanh niên và các thành viên trong gia đình họ vào giáo dục thể chất và thể thao có hệ thống;

· giáo dục các phẩm chất thể chất và đạo đức-ý chí, tăng cường sức khỏe và giảm tỷ lệ mắc bệnh, nâng cao mức độ sẵn sàng nghề nghiệp và hoạt động xã hội của thanh niên;

· tổ chức và tiến hành các sự kiện giải trí, thể dục, thể thao đại chúng;

· thành lập các hiệp hội, câu lạc bộ, bộ phận và đội thể thao nghiệp dư;

· thúc đẩy văn hóa thể dục thể thao, lối sống lành mạnh, tổ chức các hoạt động giải trí có ý nghĩa, thu hút đông đảo thanh niên tham gia các sự kiện chính trị - xã hội đại chúng

Câu lạc bộ thể thao thực hiện các chức năng sau:

· Thực hiện văn hóa thể dục thể thao trong sinh hoạt, đời sống và giải trí của thanh niên; đề cao lối sống lành mạnh, đấu tranh khắc phục những thói quen xấu;

· tạo ra các điều kiện tổ chức và phương pháp cần thiết để thực hành các hình thức và loại hình văn hóa thể dục thể thao phù hợp với truyền thống lâu đời của đất nước;

· giới thiệu các hình thức và phương pháp giáo dục thể chất mới, kinh nghiệm tiên tiến và thành tựu khoa học; sử dụng nguồn lực vật chất hợp lý, hiệu quả;

· Phát triển các nguyên tắc xã hội bằng mọi cách có thể trong công tác giáo dục thể chất, y tế và thể thao đại chúng;

· hỗ trợ các trường trung học và cao đẳng trong việc tổ chức các hoạt động giải trí, thể dục và thể thao đại chúng;

· tổ chức quá trình giáo dục và đào tạo trong các bộ phận thể thao (đội tuyển quốc gia);

· Xây dựng và thực hiện kế hoạch lịch cho các sự kiện giải trí, thể dục thể thao đại chúng, đảm bảo an toàn cho việc thực hiện;

· cung cấp quyền kiểm soát quá trình giáo dục và đào tạo trong các bộ phận của câu lạc bộ thể thao để chuẩn bị cho các vận động viên có trình độ thể thao cao nhất, góp phần tạo điều kiện cần thiết cho sự phát triển các kỹ năng thể thao của họ;

· Cùng với cơ quan y tế tổ chức kiểm soát y tế về tình trạng sức khỏe của những người tham gia thể dục thể thao tại các bộ phận (đội tuyển quốc gia);

· Xây dựng kế hoạch hiện tại và dài hạn về phát triển các hoạt động giáo dục thể chất, y tế, giáo dục, thể thao đại chúng và dự toán kinh phí cho câu lạc bộ.

· Trong phạm vi thẩm quyền của mình, lựa chọn và bố trí nhân viên giáo dục thể chất;

· Có thể có cờ, biểu tượng, đồng phục thể thao, tem, tiêu đề thư;

· tổ chức các cuộc thi quần chúng, ngày hội thể thao (universiade), trại giáo dục và huấn luyện;

· Theo quy trình đã được phê duyệt, cử các đội, cá nhân vận động viên tham dự thi đấu;

· cấp giấy chứng nhận (huy hiệu) phù hợp cho các thành viên của các đội đại học;

2.3 Xây dựng sơ đồ lớp học môn học “Tổ chức hoạt động câu lạc bộ thể thao”

Câu lạc bộ thể thao có bốn phần dựa trên câu lạc bộ:

· Bóng rổ

· Bóng chuyền

· Quần vợt.

Khi ứng viên-vận động viên đăng ký vào câu lạc bộ thể thao để đăng ký vào bất kỳ phần nào, việc đăng ký sẽ được thực hiện, bao gồm các hành động sau:

· Dữ liệu về vận động viên được nhập vào bảng gồm 5 trường: Họ, Tên, Tuổi, Điện thoại, Mục.

· Các vận động viên được chia thành các phần mà đơn đăng ký đã được nộp.

· Phụ huynh của các vận động viên được cung cấp lịch trình các phần của câu lạc bộ thể thao.

Để tổ chức đúng công việc của câu lạc bộ, điều phối công việc của các bộ phận và tuyển dụng huấn luyện viên, người quản lý câu lạc bộ thể thao điền vào lịch trình.

Khi tham gia một câu lạc bộ, vận động viên được đưa vào một bảng chỉ rõ phần thi đó. Tất cả các vận động viên tham gia câu lạc bộ phải được đưa vào bảng chính chỉ rõ phần thi.

Để thể hiện trực quan quy trình làm việc của câu lạc bộ thể thao, một sơ đồ UML đã được xây dựng (Hình 2.3.1).

Cơm. 2.3.1 Mô hình câu lạc bộ thể thao hướng đối tượng.

3. XÂY DỰNG MÔ HÌNH ĐỐI TƯỢNG CỦA LĨNH VỰC CHỦ ĐỀ “TỔ CHỨC CÔNG VIỆC CỦA CÂU LẠC BỘ THỂ THAO” SỬ DỤNG MÔI TRƯỜNG LẬP TRÌNH TRỰC QUAN DELPHI

3.1 Mô tả cấu trúc ứng dụng

Ứng dụng này là một phần của gói Thể thao. Nó bao gồm một lớp: lớp TPeople.

Lớp “TPeople” cho phép bạn tạo và tích lũy thông tin về trẻ em tham gia câu lạc bộ thể thao này, được gọi là “Ogonyok”. Nó có năm trường: Tên được chỉ định bởi chuỗi “Tên”; Họ được chỉ định bởi chuỗi “Gia đình”; Tuổi được lưu trong biến số (int) “Tuổi”; số điện thoại được chỉ định bởi chuỗi “Tel”; Phần luyện tập của vận động viên được chỉ định bằng chuỗi “Sekc”.

TPeople = đẳng cấp

Tên: Chuỗi;

Gia đình: Chuỗi;

Tuổi: Số nguyên;

tel: Chuỗi;

sekc: Chuỗi;

hàm tạo Tạo (AName: String);

kết thúc;

Trong trường hợp này, các trường được nhập theo hai cách:

Đang tải một giá trị từ tệp đã lưu có phần mở rộng LST. (Hình 3.1.1.)

Phương thức này được tổ chức bằng hàm OpenDlg, với mỗi dòng của lớp được đọc dưới dạng một giá trị riêng biệt.

var F: TextFile;

i: Số nguyên;

bắt đầu

thử

với OpenDlg, PersonsList.Items làm được

bắt đầu

nếu không thực thi thì thoát;

LoadFromFile(Tên tệp);

GánFile(F, Copy(FileName,1,Length(FileName)-4)+".lso");

Đặt lại (F);

tôi:= 0;

trong khi Không phải EOF(F) thì có

bắt đầu

Đối tượng[i] := TPeople.Create("");

Readln(F, (Objects[i] as TPeople).Name);

Readln(F, (Objects[i] as TPeople).Famil);

Readln(F, (Objects[i] as TPeople).Age);

Readln(F, (Objects[i] as TPeople).tel);

Readln(F, (Objects[i] as TPeople).sekc);

Inc(i);

kết thúc;

CloseFile(F);

kết thúc;

ngoại trừ

trên E: EFOpenError do ShowMessage("Lỗi mở tập tin");

kết thúc; kết thúc;

Cơm. 3.1.1 Tải tập tin lên.

Phương pháp điền bảng thứ hai là nhập bằng cách sử dụng các thành phần Chỉnh sửa (Hình 3.1.2.)

Cơm. 3.1.2 Điền vào bảng bằng thành phần Chỉnh sửa.

Hơn nữa, giá trị của trường “Section” được chọn từ các giá trị của thành phần Combobox và được gán cho dòng “Sekc”. (Hình.3.1.3)

Cơm. 3.1.3 Thành phần Combobox.

Có thể điều chỉnh các giá trị đã nhập bằng cách chọn giá trị mong muốn và nhấp vào nút “Thay đổi” (Hình 3.1.4)

Cơm. 3.1.4 Thay đổi giá trị.

Chương trình cung cấp khả năng xóa một giá trị bằng cách xóa một mục nhập (Hình 3.1.5) và xóa tất cả các mục nhập (Hình 3.1.6).

Việc xóa một bản ghi được thực hiện bằng cách chọn một giá trị và nhấp vào nút “Xóa”.

Cơm. 3.1.5 Xóa một mục.

Để xóa tất cả các bản ghi, hãy nhấp vào nút “Xóa”.

Cơm. 3.1.6 Nút “Xóa”.

Cả hai phương pháp loại bỏ đều được thực hiện bằng các phương pháp sau:

thủ tục TMainForm.ToolButton4Click(Người gửi: TObject);

bắt đầu

với PersonsList thực hiện Items.Delete(ItemIndex);

kết thúc;

thủ tục TMainForm.ToolButton5Click(Người gửi: TObject);

bắt đầu

PersonsList.Items.Clear;

kết thúc;

Sau khi điền vào bảng vận động viên, cần lưu lại để sử dụng sau này. Việc này được thực hiện bằng cách nhấp vào nút “Lưu” (Hình 3.1.7). Sau khi nhấp vào nút này, một hộp thoại sẽ mở ra, trong đó thư mục lưu trữ tệp và tên của nó được chỉ định. (Hình 3.1.8).

Tài liệu tương tự

Mô tả ngắn gọn về lĩnh vực chủ đề. Sự liên quan của việc phát triển mô hình hệ thống thông tin hướng đối tượng cho thư viện giáo dục. Tạo sơ đồ ca sử dụng, sơ đồ trình tự, sơ đồ cộng tác, sơ đồ lớp.

bài tập khóa học, được thêm vào ngày 01/06/2009


Phát triển hệ thống con kế toán kho hàng hướng đối tượng cho công ty "KavkazYugAvto". Mô tả ngắn gọn về lĩnh vực chủ đề. Vẽ sơ đồ vị trí, trường hợp sử dụng, trình tự, thành phần và lớp. Tạo mã C++.

bài tập khóa học, được thêm vào ngày 26/06/2011


Các thành phần cơ bản của mô hình đối tượng Bản chất và ưu điểm của cách tiếp cận hướng đối tượng, khái niệm đối tượng và lớp. Ngôn ngữ mô hình hóa thống nhất UML. Sơ đồ lớp và tương tác: mục đích, cấu trúc và ví dụ sử dụng.

tóm tắt, thêm vào ngày 09/06/2009


Mô tả môn học “Cửa hàng bán linh kiện máy tính”. Xây dựng ER và dữ liệu quan hệ, các mô hình thực thể và mối quan hệ. Tạo ER và mô hình dữ liệu quan hệ, truy vấn, dạng xem, thủ tục lưu trữ cho lĩnh vực chủ đề.

bài tập khóa học, được thêm vào ngày 15/06/2014


Sự liên quan và ý nghĩa thực tiễn của hệ thống phần mềm câu lạc bộ máy tính. Phân tích tên miền. Sơ đồ lớp, mô hình vật lý của hệ thống. Phát triển dự án IS trực quan bằng ngôn ngữ UML2.0 và môi trường mô hình hóa Microsoft Visio.

bài tập khóa học, được thêm vào ngày 21/06/2014


Phân tích lĩnh vực chủ đề “Cuộc thi nhà thơ” dựa trên cách tiếp cận hướng đối tượng. Phát triển ứng dụng cửa sổ và mô tả mô hình thông tin của lĩnh vực chủ đề. Mô tả các thủ tục C++ được phát triển và kết quả thử nghiệm ứng dụng.

bài tập khóa học, được thêm vào ngày 18/06/2013


Mô hình chức năng IDEF0. Mô tả toàn bộ quy trình làm việc của bộ phận hỗ trợ kỹ thuật. Phân rã sơ đồ bối cảnh và các quy trình cốt lõi. Xây dựng mô hình các tiến trình miền theo chuẩn IDEF1X. Giao diện chương trình điều khiển giao thông.

báo cáo thực hành, bổ sung ngày 22/11/2014


Xây dựng mô hình thông tin của một lĩnh vực chủ đề bằng phương pháp sơ đồ ER. Tạo mối quan hệ cơ sở dữ liệu bằng ngôn ngữ SQL. Điền vào cơ sở dữ liệu. Tạo truy vấn tới cơ sở dữ liệu câu lạc bộ máy tính. Tạo báo cáo bằng Microsoft Word và Microsoft Excel.

bài tập khóa học, được thêm vào ngày 26/02/2009


Mô tả ngắn gọn về lĩnh vực chủ đề. Tạo ca sử dụng, trình tự, cộng tác, lớp, vị trí, sơ đồ thành phần. Thêm chi tiết vào mô tả hoạt động và xác định thuộc tính LỚP. Tạo mã C++.

bài tập khóa học, được thêm vào ngày 29/06/2011


Đặc điểm chung của nhà kho với tư cách là đối tượng của hoạt động kinh tế. Tạo ca sử dụng và sơ đồ trình tự. Xây dựng sơ đồ cộng tác của công ty. Mục đích của sơ đồ lớp và thành phần. Tạo mã C++.