Trong phần đa năm cách đây không lâu phương thức thiết kế hướng đối tượng người dùng đã thống lĩnh thị phần lập trình phần mềm và UML cũng đã trở thành ngôn ngữ mô hình hóa phổ biến trong tiếp tế phần mềm. đa số các trường đại học, cao đẳng đã chuyển hai môn này vào huấn luyện chính khóa cùng cũng có nhiều tài liệu viết về những sự việc này. Mặc dù nhiên, nó vẫn còn đó rất cạnh tranh hiểu cùng khó áp dụng với sinh viên, cùng những bạn teen đang có tác dụng về công nghệ thông tin.
Bạn đang xem: Phân tích thiết kế hệ thống hướng đối tượng
Trong loạt bài xích này, chúng tôi sẽ cố gắng trình bày một cách dễ dàng và đơn giản và dễ hiểu nhất những kiến thức về so sánh và kiến tạo hướng đối tượng người tiêu dùng và UML để giúp các bạn hiểu và vận dụng vào thực tế. Các nội dung bài viết sẽ phía dẫn các bạn phân tích và thiết kế một ứng dụng ví dụ để từ kia tự rút ra bài học kinh nghiệm cho doanh nghiệp và liên tục nghiên cứu sâu hơn.
Bài đầu tiên sẽ bàn một cách cơ bản về Phân tích kiến thiết hướng đối tượng người sử dụng và UML.
Lưu ý: Để hiểu được loạt bài này bạn phải có kiến thức và kỹ năng cơ bạn dạng về lập trình hướng đối tượng, vì công ty chúng tôi sẽ không đi chi tiết vào những định nghĩa về lập trình hướng đối tượng.
1. Khái niệm về đối chiếu và xây dựng hướng đối tượng người sử dụng (Object Oriented Analysis và Design: OOAD)
Trong kỹ nghệ phần mềm để cấp dưỡng được một sản phẩm ứng dụng người ta chia quá trình cải cách và phát triển sản phẩm ra nhiều tiến trình như tích lũy và đối chiếu yêu cầu, đối chiếu và thiết kế hệ thống, cải cách và phát triển (coding), kiểm thử, triển khai và bảo trì. Trong đó, giai đoạn phân tích, thiết kế khi nào cũng là giai đoạn khó khăn và phức hợp nhất. Tiến độ này giúp chúng ta hiểu rõ yêu cầu đặt ra, khẳng định giải pháp, tế bào tả chi tiết giải pháp. Nó vấn đáp 2 câu hỏi What (phần mềm này làm cái gì?) cùng How (làm nó như vậy nào?).
Để phân tích với thiết kế một trong những phần mềm thì có khá 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 sống trong các số ấy và hệ trọng với nhau. Việc mô tả được tất cả các đối tượng người dùng và sự cửa hàng của bọn chúng sẽ giúp họ hiểu rõ khối hệ thống và cài đặt được nó. Cách thức này call là Phân tích kiến thiết hướng đối tượng người dùng (OOAD)
2. Khái niệm về UML (Unified Modeling Language)
UML là ngôn ngữ mô hình hóa thích hợp nhất dùng làm biểu diễn hệ thống. Nói một cách đơn giản dễ dàng là nó dùng để làm tạo ra các bạn dạng vẽ nhằm mục đích mô tả xây cất hệ thống. Các bản vẽ này được sử dụng để các nhóm xây đắp trao thay đổi với nhau tương tự như dùng nhằm thi công khối hệ thống (phát triển), thuyết phục khách hàng, các nhà đầu tư v.v.. (Giống như trong xây dựng người ta dùng các phiên bản vẽ thi công để giải đáp và kiểm soát và điều hành thi công, bán sản phẩm căn hộ v.v..)
3. Vì sao lại là OOAD với UML?
OOAD đề xuất các bạn dạng 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. Bởi vậy, bọn họ phân tích và kiến thiết theo hướng đối tượng người sử dụng và thực hiện UML để trình diễn các thi công đó đề xuất chúng thường song song với nhau.
4. OOAD áp dụng UML
UML thực hiện để vẽ cho những lĩnh vực khác biệt như phần mềm, cơ khí, thi công v… trong phạm vi các bài viết này bọn họ chỉ nghiên cứu và phân tích cách thực hiện UML đến phân tích và xây cất hướng đối tượng người sử dụng trong ngành phần mềm. OOAD sử dụng 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ẽ tò mò kỹ hơn các thành phần trên.
4.1 View (góc nhìn)Mỗi mắt nhìn như thầy bói xem voi, nó không thể hiện hết khối hệ thống nhưng diễn đạt rõ khối hệ thống ở một khía cạnh. Bởi vì thế trong xây cất có bạn dạng vẽ bản vẽ xây dựng (nhìn về mặt kiến trúc), bản vẽ kết cấu (nhìn về mặt kết cấu), bạn dạng vẽ kiến tạo (nhìn về phương diện thi công). Vào phần mềm cũng như vậy, OOAD áp dụng UML có các mắt nhìn sau:
Hình 1. Những View trong OOAD thực hiện UML
Trong đó,
– Use Case View: cung cấp ánh mắt về những ca thực hiện giúp chúng ta hiểu khối 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 góc nhìn về cấu tạo hệ thống, xem nó được tổ chức như vậy nào. Bên trong nó bao gồm gì.
– Process View: cung cấp ánh mắt động về hệ thống, xem những thành phần trong khối hệ thống tương tác cùng với nhau như vậy nào.
– Component View: Cũng là một ánh mắt về kết cấu giúp họ hiểu cách phân bổ và thực hiện lại các thành phần trong khối hệ thống ra sao.
– Deployment View: cung cấp ánh mắt về tiến hành hệ thống, nó cũng ảnh hưởng lớn đến phong cách thiết kế hệ thống.
Tập đúng theo các mắt nhìn này đang giúp bọn họ hiểu rõ hệ thống cần phân tích, thiết kế. Trong hình 1 bọn họ thấy góc nhìn Use Case View nằm ở vị trí giữa và bỏ ra phối toàn bộ các ánh mắt còn lại. Bởi vì thế bọn họ thường thấy những tài liệu nói về 4 view + 1 chứ không phải 5 view nhằm mục tiêu nhấn to gan lớn mật vai trò của Use Case View.
4.2 Diagram (Bản vẽ)Diagram các bạn cũng có thể dịch là sơ đồ. Mặc dù ở đây họ sử dụng từ bạn dạng vẽ mang đến dễ hình dung. Các bản vẽ được dùng làm thể hiện tại các ánh mắt của hệ thống.
Hình 2. Các bản vẽ vào OOAD sử dụng UML
Trong đó,
– Use Case Diagram: bản vẽ diễn tả về ca áp dụng của hệ thống. Phiên bản vẽ này sẽ giúp chúng ta biết được ai áp dụng hệ thống, khối hệ thống có những tác dụng gì. Lập được bản vẽ này bạn sẽ hiểu được yêu cầu của khối hệ thống cần xây dựng.
– Class Diagram: bản vẽ này tế bào tả cấu tạo của hệ thống, tức hệ thống được cấu trúc từ đa số thành phần nào. Nó bộc lộ khía cạnh tĩnh của hệ thống.
– Object Diagram: Tương từ như Class Diagram tuy nhiên nó mô tả đến đối tượng người sử dụng thay bởi vì lớp (Class).
– Sequence Diagarm: là bản vẽ biểu đạt sự thúc đẩy của các đối tượng trong hệ thống với nhau được biểu lộ tuần tự các bước tương tác theo thời gian.
– Collaboration Diagram: tương tự như sequence Diagram nhưng nhấn mạnh về việc tương tác thay vì tuần từ bỏ theo thời gian.
– State Diagram: bản vẽ biểu thị sự đổi khác trạng thái của một đối tượng. Nó được dùng để làm theo dõi các đối tượng người sử dụng có trạng thái biến hóa nhiều vào hệ thống.
Xem thêm: Ngôi sao màu nhuộm tiếng việt, lý thuyết về ngôi sao màu rất bổ ích
– Activity Diagram: bạn dạng vẽ diễn tả các hoạt động vui chơi của đối tượng, thường xuyên được áp dụng để đọc về nghiệp vụ của hệ thống.
– Component Diagram: bản vẽ thể hiện về việc bố trí các nguyên tố của hệ thống cũng giống như việc sử dụng các thành phần đó.
– Deployment Diagram: phiên bản vẽ diễn tả việc thực thi của khối hệ thống như việc kết nối, sở hữu đặt, hiệu năng của hệ thống v.v…
Chúng ta sẽ bàn kỹ các bạn dạng vẽ này trong số bài tiếp theo. Bởi vì nó đó là hạt nhân của loạt bài xích này.
Lưu ý: Ở đây bọn họ sử dụng từ hệ thống tương đương với thành phầm phần mềm.
4.3 Notations (các cam kết hiệu)Notations là các ký hiệu nhằm vẽ, nó như từ bỏ vựng trong ngôn ngữ tự nhiên. Bạn phải ghi nhận từ vựng thì mới 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ụ về notation.
Hình 3. Ký kết hiệu về Use Case
Hình 4. Ký hiệu về Class
Hình 5. Ký kết hiệu về Actor
Và còn rất nhiều ký hiệu nữa.
4.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ẽ tất cả qui tắc riêng biệt và bạn phải rứa được để tạo cho các phiên bản vẽ xây dựng đú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ẽ.
5. Kết luận
Nguyên tắc phân tích, thiết kế một hệ thống phần mềm cũng không khác bài toán xây dựng một cái nhà trong xây dựng. Bạn hãy nhớ phương pháp tiếp cận này để dễ nắm bắt hơn trong việc phân tích và kiến tạo hệ thống. Hãy giữ hầu như thứ mang lại thật đơn giản dễ dàng để dễ hiểu và dễ áp dụng.
Khi triển khai các dự án phần mềm, ứng dụng tôi có thói quen phân tách đôi thời gian thực hiện, một nửa giành cho việc tìm hiểu nghiệp vụ, phân tích tài năng và thi công database, một nửa thời hạn còn lại giành cho việc code. Vào thời đại mở của các nền tảng kỹ thuật họ hoàn toàn 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, hôm nay việc ứng dụng vận động ổn định, đúng nghiệp vụ, thuận lợi mở rộng theo yêu cầu đổi khác của tình hình thực tế lại là điều quan trọng hơn.
Phân tích và thiết kế 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ông dụng và được chuyển 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 tế 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 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 người tiêu 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 & Design)
Phân tích và thi công hướng đối tượng người tiêu dùng là một nghệ thuật tiếp cận phổ biến dùng để làm phân tích, kiến thiết một ứng dụng, hệ thống. Nó dựa trên bộ những nguyên tắc chung, đó là một trong những tập các hướng dẫn để giúp bọn họ tránh ngoài một kiến tạo xấu. 5 hình thức SOLID trong thi công hướng đối tượng:
Một lớp nên làm có một vì sao để cầm đổi, tức là một lớp chỉ nên xử lý một tính năng đơn lẻ, độc nhất vô nhị thôi. Nếu đặt nhiều tính năng vào vào một lớp vẫn dẫn đến sự phụ thuộc vào giữa các tác dụng với nhau cùng mặc dù tiếp đến ta chỉ thay đổi ở một tính năng thì cũng phá vỡ lẽ các chức năng còn lại.Các lớp, module, tác dụng nên dễ dàng Mở (Open) mang lại việc không ngừng mở rộng (thêm chức năng mới) cùng Đóng (Close) cho việc thay đổi.Lớp dẫn xuất phải có khả năng thay rứa được lớp phụ thân của nó.Chương trình tránh việc buộc phải thiết đặt một interface mà lại nó không sử dụng đến.Các module cao cấp không nên nhờ vào vào những module cung cấp 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 nhờ vào vào đưa ra tiết. Chi tiết nên phụ thuộc vào trừu tượngKhái niệm UML
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 đơn giản và dễ dàng là nó dùng để làm tạo ra các phiên bản vẽ nhằm mục đích mô tả kiến tạo hệ thống. Các bản vẽ này được sử dụng để những nhóm xây dựng trao thay đổi với nhau cũng như dùng để thi công khối hệ thống (phát triển), thuyết phục khách hàng hàng, những nhà đầu tư chi tiêu v.v..
Tại sao lại là OOAD và 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 bản vẽ nên yêu cầu nội dung thể hiện. Do vậy, chúng ta phân tích và kiến thiết theo hướng đối tượng người tiêu dùng và áp dụng UML để biểu diễn các xây cất đó đề nghị chúng thường đi đôi với nhau.
OOAD thực hiện UML
UML áp dụng để vẽ cho những lĩnh vực không giống nhau như phần mềm, cơ khí, xây đắp v… trong phạm vi các bài viết này bọn họ chỉ nghiên cứu và phân tích cách sử dụng UML đến phân tích và thi công hướng đối tượng người sử dụng trong ngành phần mềm. OOAD thực hiện UML bao gồm các yếu 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ẽ tìm hiểu kỹ hơn những thành phần trên.
View (góc nhìn)
Mỗi ánh mắt như thầy bói xem voi, nó không trình bày hết hệ thống nhưng trình bày rõ hệ thống ở một khía cạnh. Chính vì thế trong kiến tạo có bản vẽ phong cách xây dựng (nhìn về khía cạnh kiến trúc), bản vẽ kết cấu (nhìn về khía cạnh kết cấu), phiên bản vẽ thi công (nhìn về khía cạnh thi công). Vào phần mềm cũng giống như vậy, OOAD thực hiện UML gồm các ánh mắt sau:
Trong đó,
Use Case View: cung cấp góc nhìn về những ca áp dụng giúp bọn họ hiểu khối hệ thống có gì? ai cần sử dụng và dùng nó như thế nào.Logical View: cung cấp ánh mắt về cấu tạo hệ thống, xem nó được tổ chức như thế nào. Bên trong nó tất cả gì.Process View: cung cấp góc nhìn động về hệ thống, xem các thành phần trong khối hệ thống tương tác cùng với nhau như thế nào.Component View: cũng chính là một mắt nhìn về kết cấu giúp bọn họ hiểu cách phân chia và thực hiện lại những thành phần trong khối hệ thống ra sao.Deployment View: cung cấp ánh mắt về tiến hành hệ thống, nó cũng tác động lớn đến bản vẽ xây dựng hệ thống.Tập hợp các góc nhìn này đã giúp bọn họ hiểu rõ hệ thống cần phân tích, thiết kế. Vào hình trên họ thấy góc nhìn Use Case View nằm ở giữa và chi phối toàn bộ các góc nhìn còn lại. Cũng chính vì thế họ thường thấy những tài liệu nói đến 4 view + 1 chứ chưa hẳn 5 view nhằm mục tiêu nhấn khỏe mạnh vai trò của Use Case View.
Diagram (Bản vẽ)
Diagram chúng ta cũng có thể dịch là sơ đồ. Tuy nhiên ở đây bọn họ sử dụng từ phiên 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.
Trong đó,
Use Case Diagram: phiên bản vẽ miêu tả về ca thực hiện của hệ thống. Bạn dạng vẽ này sẽ giúp bọn họ biết được ai áp dụng hệ thống, khối 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 mong của hệ thống cần xây dựng.Class Diagram: phiên bản vẽ này mô tả cấu tạo của hệ thống, tức khối hệ thống được cấu trúc từ mọi thành phần nào. Nó biểu đạt khía cạnh tĩnh của hệ thống.Object Diagram: tựa như như Class Diagram nhưng lại nó mô tả đến đối tượng người dùng thay vì lớp (Class).Sequence Diagarm: là phiên bản vẽ biểu đạt sự shop của các đối tượng người tiêu dùng trong khối hệ thống với nhau được biểu hiện tuần tự các bước tương tác theo thời gian.Collaboration Diagram: giống như như sequence Diagram nhưng nhấn mạnh về sự tương tác thay vày tuần từ bỏ theo thời gian.State Diagram: bạn dạng vẽ biểu lộ sự chuyển đổi trạng thái của một đối tượng. Nó được dùng làm theo dõi các đối tượng người tiêu dùng có trạng thái biến hóa nhiều vào hệ thống.Activity Diagram: bạn dạng vẽ trình bày các hoạt động vui chơi của đối tượng, thường xuyên được thực hiện để hiểu về nghiệp vụ của hệ thống.Component Diagram: bản vẽ miêu tả về việc bố trí các thành phần của hệ thống cũng tương tự việc sử dụng những thành phần đó.Deployment Diagram: bản vẽ biểu đạt việc thực hiện của khối hệ thống như vấn đề kết nối, mua đặt, hiệu 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ừ bỏ vựng trong ngôn ngữ tự nhiên. Bọn họ phải biết tự vựng thì mới ghép thành câu, thành bài xích được. Họ sẽ khám phá kỹ những notations vào từng phiên bản vẽ sau này. Dưới đó là vài lấy ví dụ về notation.
Hình trên là lấy ví dụ về ký kết hiệu của Use Case, Class, Actor, bên cạnh đó còn không ít các cam kết hiệu khác
Mechanisms (Rules)
Mechanisms là những qui tắc để lập nên bạn dạng vẽ, mỗi bạn dạng vẽ có qui tắc riêng rẽ và chúng ta phải cố kỉnh được để tạo nên các bản vẽ kiến tạo đúng. Các qui tắc này bọn họ sẽ bàn kỹ trong các bài về các bản vẽ.
Tổng kết
Nguyên tắc phân tích, thiết kế một khối hệ thống phần mượt cũng ko khác vấn đề xây dựng một cái nhà trong xây dựng. Chúng ta nên nhớ biện pháp tiếp cận này để dễ hiểu hơn trong việc phân tích và thi công hệ thống. Hãy giữ rất nhiều thứ mang lại thật đơn giản và dễ dàng để dễ nắm bắt và dễ dàng áp dụng.
Trong thực tế, tùy theo độ tinh vi của dự án mà chúng ta có thể lược vứt đi một số bản vẽ không cần thiết (bản vẽ cho những phần đối chọi giản, không phức tạp). Tôi hay vẽ Use Case Diagram, Class Diagram như hai phiên bản bắt buộc cùng Activity Diagram cho một vài tính năng phức tạp.
Theo dõi các nội dung bài viết tiếp theo: Phân tích thiết kế hệ thống hướng đối tượng (OOAD) và ngôn ngữ quy mô hóa (UML)
