Khi thực hiện các dự án phần mềm, áp dụng tôi bao gồm thói quen phân tách đôi thời hạn thực hiện, một nửa dành riêng cho việc tìm hiểu nghiệp vụ, phân tích công dụng và xây đắp database, một nửa thời gian còn lại giành riêng cho việc code. Trong thời đại mở của những nền tảng kỹ thuật bọn họ hoàn toàn rất có thể áp dụng những technology tốt độc nhất cho hiệu suất ứng dụng của mình, lúc này việc ứng dụng vận động ổn định, đúng nghiệp vụ, dễ dàng mở rộng theo yêu cầu biến hóa của tình hình thực tế lại là điều quan trọng đặc biệt hơn.

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

Phân tích và kiến tạo hướng đối tượng người tiêu dùng OOAD (Object Oriented Analysis and Design) cùng ngôn ngữ quy mô hóa UML (Unified Modeling Language) thịnh hành và được gửi vào các trường đào tạo và huấn luyện ngành CNTT tuy vậy để áp dụng thực tiễn với sinh viên vẫn tồn tại tương đối cạnh tranh khăn. Trong bài xích này chúng ta sẽ tiếp cận bằng cách đơn giản những kỹ năng về phân tích và thi công hướng đối tượng người dùng và UML để cùng hiểu và vận dụng vào thực tế.

Khái niệm OOAD (Object Oriented Analysis and Design)

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

Một lớp nên làm có một tại sao để nạm đổi, có nghĩa là một lớp nên làm xử lý một tính năng đơn lẻ, tuyệt nhất thôi. Nếu đặt nhiều công dụng vào trong một lớp đang dẫn cho sự dựa vào giữa các công dụng với nhau cùng mặc dù kế tiếp ta chỉ chuyển đổi ở một tính năng thì cũng phá vỡ các công dụng còn lại.Các lớp, module, công dụng nên dễ dàng Mở (Open) mang đến việc không ngừng mở rộng (thêm tác dụng mới) cùng Đóng (Close) cho vấn đề thay đổi.Lớp dẫn xuất phải có chức năng thay nạm được lớp cha của nó.Chương trình không nên buộc phải thiết đặt một interface mà nó không thực hiện đến.Các module cao cấp không nên nhờ vào vào các module cấp cho thấp. Cả hai nên phụ thuộc thông qua lớp trừu tượng. Lớp trừu tượng ko nên phụ thuộc vào vào bỏ ra tiết. Cụ thể nên phụ thuộc vào vào trừu tượng

Khái niệm UML

UML là ngôn ngữ mô hình hóa đúng theo nhất dùng để biểu diễn hệ thống. Nói một cách dễ dàng và đơn giản là nó dùng làm tạo ra các bản vẽ nhằm mục đích mô tả xây đắp hệ thống. Các phiên bản vẽ này được áp dụng để các nhóm thi công trao thay đổi với nhau cũng tương tự dùng nhằm thi công khối hệ thống (phát triển), thuyết phục khách hàng, những nhà đầu tư chi tiêu v.v..

Tại sao lại là OOAD cùng UML?

OOAD bắt buộc các bản vẽ nhằm mô tả 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 buộc phải nội dung thể hiện. Bởi vì vậy, bọn họ phân tích và thi công theo hướng đối tượng người dùng và thực hiện UML để màn trình diễn các kiến tạo đó yêu cầu chúng thường đi đôi với nhau.

OOAD áp dụng UML

UML áp dụng để vẽ cho những lĩnh vực khác biệt như phần mềm, cơ khí, thành lập v… vào phạm vi các bài viết này chúng ta chỉ phân tích cách thực hiện UML mang đến phân tích và thiết kế hướng đối tượng trong ngành phần mềm. OOAD thực hiện UML bao hà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ế)

Chúng ta sẽ mày mò kỹ hơn các thành phần trên.

View (góc nhìn)

Mỗi góc nhìn như thầy tướng xem voi, nó không bộc lộ hết hệ thống nhưng biểu thị rõ hệ thống ở một khía cạnh. Cũng chính vì thế trong phát hành có bạn dạng vẽ kiến trúc (nhìn về mặt kiến trúc), bạn dạng vẽ kết cấu (nhìn về phương diện kết cấu), phiên bản vẽ xây cất (nhìn về mặt thi công). Trong phần mềm cũng tương tự vậy, OOAD sử dụng UML có các góc nhìn sau:

Trong đó,

Use Case View: cung cấp ánh mắt về những ca sử dụng giúp bọn họ hiểu hệ thống có gì? ai cần sử dụng và cần sử dụng nó như thế nào.Logical View: cung cấp góc nhìn về cấu tạo hệ thống, coi nó được tổ chức như thế nào. Bên trong nó có gì.Process View: cung cấp ánh mắt động về hệ thống, xem các thành phần trong khối hệ thống tương tác với nhau như thế nào.Component View: cũng là một mắt nhìn 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 hiện hệ thống, nó cũng ảnh hưởng lớn đến phong cách xây dựng hệ thống.

Xem thêm: Gel Nhuộm Tóc Tạm Thời - Hiệu Quả, Rẻ Bất Ngờ, Cod Mọi

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

Diagram (Bản vẽ)

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

Trong đó,

Use Case Diagram: phiên bản vẽ biểu lộ về ca áp dụng của hệ thống. Bản vẽ này vẫn giúp chúng ta biết được ai thực hiện hệ thống, hệ thống có những công dụng gì. Lập được bạn dạng vẽ này bọn họ sẽ đọc được yêu cầu của khối hệ thống cần xây dựng.Class Diagram: bạn dạng vẽ này mô tả kết cấu của hệ thống, tức khối hệ thống được cấu tạo từ những thành phần nào. Nó miêu tả khía cạnh tĩnh của hệ thống.Object Diagram: tương tự như Class Diagram nhưng nó diễn đạt đến đối tượng người sử dụng thay vày lớp (Class).Sequence Diagarm: là phiên bản vẽ biểu lộ sự hệ trọng của các đối tượng người dùng trong hệ thống với nhau được biểu đạt tuần tự các bước tương tác theo thời gian.Collaboration Diagram: tương tự như sequence Diagram tuy vậy nhấn mạnh về sự việc tương tác thay do tuần tự theo thời gian.State Diagram: bạn dạng vẽ bộc lộ sự biến đổi trạng thái của một đối tượng. Nó được dùng để theo dõi các đối tượng có trạng thái biến đổi nhiều trong hệ thống.Activity Diagram: phiên bản vẽ thể hiện các hoạt động của đối tượng, thường xuyên được áp dụng để phát âm về nghiệp vụ của hệ thống.Component Diagram: bạn dạng vẽ mô tả về việc sắp xếp các yếu tố của hệ thống cũng như việc sử dụng các thành phần đó.Deployment Diagram: bạn dạng vẽ diễn tả việc xúc tiến của khối hệ thống như vấn đề kết nối, thiết lập đặt, tính năng của khối hệ thống v.v…

Notations (các cam kết hiệu)

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

Hình bên trên là lấy ví dụ như về ký hiệu của Use Case, Class, Actor, trong khi còn rất nhiều các ký kết hiệu khác

Mechanisms (Rules)

Mechanisms là những qui tắc để lập nên phiên bản vẽ, mỗi bản vẽ gồm qui tắc riêng rẽ và chúng ta phải cầm được để làm cho các bản vẽ kiến thiết đúng. Các qui tắc này bọn họ sẽ bàn kỹ trong những bài về các phiên bản vẽ.

 

Tổng kết

Nguyên tắc phân tích, xây cất một hệ thống phần mềm cũng ko khác bài toán xây dựng một chiếc nhà trong xây dựng. Chúng ta nên nhớ phương pháp tiếp cận này để dễ hiểu hơn trong câu hỏi phân tích và kiến thiết hệ thống. Hãy giữ mọi thứ mang lại thật đơn giản để dễ dàng nắm bắt và dễ dàng áp dụng.

Trong thực tế, tùy thuộc vào độ phức hợp của dự án mà bạn cũng có thể lược loại bỏ một số bản vẽ không quan trọng (bản vẽ cho các phần đối kháng giản, ko phức tạp). Tôi hay vẽ Use Case Diagram, Class Diagram như hai bản bắt buộc và Activity Diagram cho một số trong những tính năng phức tạp.

 

Theo dõi các bài viết tiếp theo: Phân tích thiết kế khối hệ thống hướng đối tượng người sử dụng (OOAD) với ngôn ngữ mô hình hóa (UML)