Phân Tích Và Thiết Kế Hướng Đối Tượng (Ooad) Và Ngôn Ngữ Mô Hình Hóa (Uml)

Phân tích và xây đắp hướng đối tượng là một kỹ thuật tiếp cận phổ biến dùng để làm phân tích, thiết kế một ứng dụng, hệ thống. Nó dựa vào bộ các nguyên tắc chung, đó là một trong tập những hướng dẫn để giúp bọn họ tránh ngoài một kiến thiết xấu.

Bạn đang xem: Phân tích và thiết kế hướng đối tượng

1. Tư tưởng về so với và kiến thiết hướng đối tượng (Object Oriented Analysis & Design: OOAD)

Trong kỹ nghệ phần mềm để sản xuất được một sản phẩm phần mềm người ta phân tách quá trình trở nên tân tiến sản phẩm ra nhiều quy trình như thu thập và so sánh yêu cầu, đối chiếu và xây đắp hệ thống, cách tân và phát triển (coding), kiểm thử, triển khai và bảo trì. Vào đó, quá trình phân tích, thiết kế lúc nào cũng là giai đoạn khó khăn và tinh vi nhất. Quy trình tiến độ này giúp họ hiểu rõ yêu cầu đặt ra, xác minh giải pháp, mô tả cụ thể giải pháp. Nó vấn đáp 2 câu hỏi What (phần mượt này làm cái gì?) với How (làm nó như thế nào?).

Để phân tích cùng thiết kế một trong những phần mềm thì có rất nhiều cách làm, giữa những cách làm đó là xem khối hệ thống gồm những đối tượng người sử dụng sống trong các số đó và xúc tiến với nhau. Bài toán mô tả được toàn bộ các đối tượng và sự thúc đẩy của bọn chúng sẽ giúp chúng ta hiểu rõ hệ thống và thiết lập được nó. Phương thức này call là Phân tích thi công hướng đối tượng (OOAD)

Tham khảo khoá học tập lập trình web trong tầm 6 tháng, bảo vệ 100% việc làm đầu ra!

2. Khái niệm về UML (Unified Modeling Language)

UML là ngôn ngữ quy mô hóa vừa lòng nhất dùng làm biểu diễn hệ thống. Nói một cách dễ dàng là nó dùng để tạo ra các bạn dạng vẽ nhằm mô tả thiết kế hệ thống. Các bạn dạng vẽ này được thực hiện để các nhóm kiến thiết trao thay đổi với nhau tương tự như dùng để thi công hệ thống (phát triển), thuyết phục khách hàng hàng, những nhà chi tiêu v.v.

3. OOAD áp dụng UML

OOAD phải các bản vẽ nhằm mô tả khối hệ thống được thiết kế, còn UML là ngôn từ mô tả các phiên bản vẽ nên đề nghị nội dung thể hiện. Vì vậy, họ phân tích và kiến tạo theo hướng đối tượng người tiêu dùng và áp dụng UML để trình diễn các thiết kế đó cần chúng thường song song với nhau.

OOAD thực hiện UML bao gồm các nhân tố sau:

– View (góc nhìn)

– Diagram (bản vẽ)

– Notations (ký hiệu)

– Mechanisms (qui tắc, cơ chế)

3.1 View (góc nhìn)

– Use Case View: cung cấp ánh mắt về các ca áp dụng giúp chúng ta hiểu hệ thống có gì? ai cần sử dụng và cần sử dụng nó như vậy nào.

– Logical View: cung cấp ánh mắt về cấu tạo hệ thống, coi nó được tổ chức như thế nào. Phía bên trong nó tất cả gì.

– Process View:cung cấp ánh mắt động về hệ thống, xem những thành phần trong hệ thống tương tác với nhau như thế nào.

– Component View:Cũng là một ánh mắt về cấu trúc giúp chúng ta hiểu cách phân bổ và áp dụng lại các thành phần trong hệ thống ra sao.

– Deployment View: cung cấp ánh mắt về thực thi hệ thống, nó cũng tác động lớn đến kiến trúc hệ thống.

Tập hòa hợp các góc nhìn này sẽ giúp bọn họ hiểu rõ khối hệ thống cần phân tích, thiết kế. Vào hình 1 bọn họ thấy góc nhìn Use Case View nằm tại vị trí giữa và bỏ ra phối toàn bộ các góc nhìn còn lại. Chính vì thế bọn họ thường thấy các tài liệu nói đến 4 view + 1 chứ không phải 5 view nhằm mục đích nhấn bạo dạn vai trò của Use Case View.

3.2 Diagram (Bản vẽ)

Diagram các chúng ta có thể dịch là sơ đồ. Tuy nhiên ở đây bọn họ sử dụng từ bản vẽ đến dễ hình dung. Các bản vẽ được dùng để làm thể hiện các ánh mắt của hệ thống.

Xem thêm: Sơn chống rỉ đại bàng là gì? sơn chống rỉ đại bàng ( lon 1kg )

3.3 Notations (các ký hiệu)

Notations là các ký hiệu nhằm vẽ, nó như từ vựng trong ngữ điệu tự nhiên. Bạn phải ghi nhận từ vựng thì mới có thể ghép thành câu, thành bài được. Bọn họ sẽ khám phá kỹ các notations vào từng phiên bản vẽ sau này. Dưới đấy là vài lấy ví dụ như về notation.

Ký hiệu về Usecase
Ký hiệu về Class
Ký hiệu về Actor

Và còn rất nhiều ký hiệu nữa.

3.4 Mechanisms (Rules)

Mechanisms là các qui tắc nhằm lập nên bạn dạng vẽ, mỗi bạn dạng vẽ bao gồm qui tắc riêng rẽ và các bạn phải cầm được để tạo nên các bản vẽ xây đắp đúng. Các qui tắc này họ sẽ bàn kỹ trong số bài về các phiên bản vẽ.

Trong bài viết này chúng ta sẽ tiếp cận bằng phương pháp đơn giản những kiến thức về đối chiếu và xây dựng hướng đối tượng (OOAD) và những cơ chế trong khi xây đắp hướng đối tượng người tiêu dùng để cùng hiểu và áp dụng vào thực tế. Cho dù được gửi vào những trường học nhằm giảng dạy, tuy nhiên hầu như các bạn sinh viên đều cảm thấy sợ vì chưng môn học tập này kha khá khó.

I. Tổng quan về OOAD

OOAD (viết tắt của Object Oriented Analysis & Design) là 1 trong kỹ thuật tiếp cận phổ biến dùng để phân tích, thiết kế một ứng dụng, hệ thống. Nó dựa trên bộ những nguyên tắc chung, đó là 1 tập các hướng dẫn để giúp họ tránh khỏi một xây cất xấu.

Có 3 đặc điểm đặc biệt của 1 thi công xấu đề nghị tránh là:

Cứng nói (Rigidity) : Khó biến hóa vì mọi thay đổi đều tác động đến rất nhiều các phần tử khác của hệ thống
Mong manh (Fragility) : Khi thực hiện một ráng đổi, hệ thống có thể đổ đổ vỡ một giải pháp bất ngờ
Bất đụng (Immobility) : nặng nề tái thực hiện trong ứng dụng khác cũng chính vì nó cần yếu được gỡ từ các ứng dụng hiện nay hành.

II. Qua quýt 5 nguyên lý SOLID trong xây cất hướng đối tượng

1. Single Responsibility Principle (SRP)

“A class should have only one reason to lớn change”

Một lớp chỉ nên có một nguyên nhân để cố đổi, có nghĩa là một lớp nên làm xử lý một tác dụng đơn lẻ, tuyệt nhất thôi. Nếu đặt nhiều tác dụng vào vào một lớp đang dẫn mang đến sự dựa vào giữa các tính năng với nhau với mặc dù tiếp nối ta chỉ đổi khác ở một tác dụng thì cũng phá vỡ lẽ các tính năng còn lại.

2. Open-Closed Principle (OCP)

“Software entities like classes, modules & functions should be open for extension but closed for modifications”

Các lớp, module, công dụng nên dễ dàng Mở (Open) cho việc mở rộng (thêm tác dụng mới) với Đóng (Close) cho câu hỏi thay đổi.

3. Liskov’s Substitution Principle (LSP)

“Derived types must be completely substitutable for their base types”Lớp dẫn xuất phải có công dụng thay chũm được lớp phụ thân của nó.

4. Interface Segregation Principle (ISP)

“Clients should not be forced khổng lồ depend upon interfaces that they don’t use”Chương trình tránh việc buộc phải thiết lập một interface nhưng nó không áp dụng đến.

5. Dependency Inversion Principle (DIP)

“High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.”

Các module cao cấp không nên phụ thuộc vào vào các module cung cấp thấp. Cả nhì nên phụ thuộc thông qua lớp trừu tượng. Lớp trừu tượng không nên dựa vào vào bỏ ra tiết. Chi tiết nên nhờ vào vào trừu tượng

Ngoài những nguyên tắc SOLID sinh hoạt trên, còn tồn tại các chế độ khác cũng rất hữu ích gồm:

Don’t Repeat Yourself (DRY) : không viết đầy đủ đoạn code giống nhau trong thuộc một công tác mà nên dùng lớp trừu tượng hoặc viết thành thủ tục để sử dụng chung
Encapsulate Whate Varies : Đóng gói hầu như gì dễ rứa đổi
Favor Composition over Inheritance: yêu cầu dùng Composition rộng là Inheritance
Programming for Interface, not Implementation: luôn luôn lập trình đến Interface, ko lập trình cho bài toán cài đặt.Delegation principle: Đừng trường đoản cú mình làm hết đầy đủ thứ, hãy ủy nhiệm nó đến lớp tương ứng
Strive for loosely coupled designs between objects that interact: Giữ links giữa các đối tượng người tiêu dùng không quá chặt
Only talk to lớn your friends: Chỉ bàn bạc với các bạn bè, chưa hẳn với tất cả