Phương pháp mô hình hóa hướng đối tượng. Cơ bản về trình bày dữ liệu đồ họa. Tạo sơ đồ ca sử dụng

Mô hình hướng đối tượng

Triết lý được chấp nhận chung trong hầu hết các hệ thống đồ họa hiện đại khi tạo bản vẽ trên máy tính là sử dụng các nguyên hàm hình học đơn giản nhất: điểm, đoạn và cung. Bằng cách sử dụng kết hợp khác nhau các nguyên thủy được liệt kê bằng cách gán các thuộc tính hình học của chúng những giá trị nhất định(điều này đề cập đến tọa độ của các điểm đặc trưng, ​​​​độ dài, bán kính, v.v.), đồng thời sử dụng các lệnh chỉnh sửa được tích hợp trong chương trình, người dùng có thể tạo một hình ảnh phức tạp tùy ý. Bạn có thể lập luận rằng hầu hết mọi hệ thống đồ họa cũng chứa nhiều lệnh hơn để xây dựng, chẳng hạn như đường cong Bezier hoặc đường cong NURBS. Tuy nhiên, đừng để điều này đánh lừa bạn: ở cấp độ phần cứng, tất cả các đường cong và đường trục này vẫn được dịch thành một tập hợp các đoạn liên tiếp gần giống với đường cong thực (nghĩa là càng gần vị trí thực tế của đường cong càng tốt) . Cách tiếp cận trong mô hình khối 3D gần giống nhau: phức tạp vật thể tíchđược tạo ra thông qua sự kết hợp liên tiếp của nhiều hình dạng ba chiều cơ bản khác nhau (khối lập phương, hình cầu, hình nón, hình xuyến, v.v.), cũng như sử dụng các thao tác tạo hình cơ bản (đùn, xoay, thao tác Boolean, v.v.).

Trong hầu hết các trường hợp, cách tiếp cận này khá hài lòng với người dùng vì nó cho phép bạn tạo hình ảnh và mô hình với hầu hết mọi hình dạng. Tuy nhiên, điều này phải trả giá bằng thời gian dành cho việc nắm vững chức năng của hệ thống đồ họa, cũng như thời gian dành cho việc tạo từng bản vẽ hoặc mô hình ba chiều như vậy. Về bản chất, mức phí không cao nhưng chẳng bao lâu sau, cách tiếp cận này không còn phù hợp với người dùng. Lý do cho điều này trước hết phải được coi là do khi thiết kế, người dùng tạo ra một mô hình hoặc hình ảnh của một vật thể vật chất có thật (mặc dù chưa tồn tại). Bất kỳ đối tượng nào như vậy thế giới thực có những đặc tính rất cụ thể mà không phải lúc nào cũng có thể truyền tải được qua hình ảnh của một bản vẽ thông thường hoặc mô hình 3D. Cần lưu ý rằng khả năng như vậy, với sự phát triển của các phương tiện và theo đó, các yêu cầu về thiết kế, sẽ không còn xa nữa. Chính điều này đã trở thành động lực buộc các nhà phát triển cá nhân phải đi theo một con đường hơi khác, do đó cách tiếp cận đối tượng đã được phát minh ra.

Trong mô hình hướng đối tượng, người dùng thao tác không phải với các nguyên hàm hình học đơn giản nhất mà với các đối tượng cụ thể. Ví dụ: khi xây dựng sơ đồ mặt bằng của một tòa nhà, giờ đây, thay vì các điểm, các đoạn và vòng cung, các bức tường, cửa sổ, cửa ra vào, các phòng riêng lẻ, v.v., được sử dụng, mỗi đối tượng như vậy được cung cấp một tập hợp các thuộc tính nhất định được chỉ định (. hoặc được gán theo mặc định) khi tạo đối tượng và được lưu trữ trong tệp tài liệu cùng với hình ảnh bản vẽ hoặc hình dạng của mô hình 3D. Đối với cửa sổ, các đặc tính này có thể bao gồm kích thước tổng thể và mô tả hình dạng cửa sổ (hình chữ nhật, hình bán nguyệt, hình vòm hoặc bất kỳ hình dạng nào khác), đặc tính quang học của kính, vật liệu và kết cấu của khung. Đối với tường - độ dày, chiều dài và chiều cao của tường, vật liệu tường, kết cấu của bề mặt bên ngoài và bên trong, sự hiện diện của cửa sổ hoặc cửa ra vào trên một bức tường nhất định, cũng như các liên kết đến các vật thể tương ứng với các cửa sổ hoặc cửa ra vào này. cửa.

Trong mô hình 3D, cảnh 3D cũng được xây dựng từ đồ vật riêng lẻ mà hệ thống đưa ra cho người dùng lựa chọn. Ví dụ: nếu một chương trình nhất định nhằm mục đích mô hình hóa thiết kế phòng dân cư hoặc cơ sở thương mại, thì cơ sở dữ liệu của chương trình đó có thể được biểu diễn bằng một tập hợp các đồ nội thất văn phòng, tủ, bàn, v.v. Đối tượng bên trong cũng có các thuộc tính cụ thể cho phép nó được sửa đổi trong một số giới hạn nhất định (thay đổi màu sắc, cấu hình, chọn vật liệu và các thuộc tính khác).

Ứng dụng cách tiếp cận đối tượng mang lại nhiều lợi ích.

Tốc độ tạo kế hoạch và bản vẽ tăng theo cấp độ lớn.

Bản vẽ hoặc mô hình trở nên giàu thông tin hơn: khi chọn (hoặc chỉnh sửa) một đối tượng, bạn có thể dễ dàng xác định (thay thế) các thuộc tính của nó và hầu hết các thuộc tính này, theo quy luật, không thể hiển thị trên bản vẽ hoặc mô hình thông thường.

Cơ sở dữ liệu về các đồ vật đôi khi không chỉ chứa đầy những đồ vật tùy ý, đã được chuẩn bị trước đó mà còn bằng những đồ vật hoàn toàn có thật (ví dụ: những món đồ nội thất ngoài đời thực của nhiều công ty khác nhau, vật liệu từ các nhà sản xuất cụ thể, v.v.). Trong những trường hợp như vậy, chương trình phải cung cấp địa chỉ của các công ty cung cấp và nhà sản xuất để bạn có thể liên hệ ngay và đặt mua các vật liệu cần thiết cũng như các đồ vật khác ngay sau khi hoàn thành dự án.

Các đối tượng dễ dàng thay đổi và sửa đổi, đồng thời chương trình giám sát tính chính xác của việc thiết lập các giá trị của một số thuộc tính nhất định (ví dụ: bạn không thể tạo một cửa sổ lớn hơn kích thước của bức tường nơi nó được đặt). Điều này giúp công việc của bạn trở nên dễ dàng hơn và tránh được những sai sót ngoài ý muốn.

Mô hình (bản vẽ) đã xây dựng có thể được trình bày dưới dạng cây phân cấp (Hình 1.1), giúp điều hướng dự án, tìm kiếm và chỉnh sửa các phần riêng lẻ của nó dễ dàng hơn.

Cơm. 1.1. Một ví dụ về cách trình bày theo cấp bậc của kế hoạch xây dựng được tạo dựa trên cách tiếp cận đối tượng

Ghi chú

Cách biểu diễn phân cấp không còn mới trong máy tính hỗ trợ thiết kế. Tuy nhiên, trong trong trường hợp này Các nút của cây không phải là các phần riêng lẻ của hình ảnh đồ họa, theo quy luật, không mang tính thông tin và không mang bất kỳ tải ngữ nghĩa nào, mà là các đối tượng cụ thể được phân chia theo một tiêu chí nhất định.

Một trong những ưu điểm chính nhưng không hề rõ ràng của phương pháp hướng đối tượng khi tạo hình ảnh đồ họa là khả năng chuyển đổi tự động nhanh chóng và hoàn toàn sang hình ảnh ba chiều (nói cách khác, khả năng tự động tạo ra hình ảnh ba chiều). mô hình chiều của đối tượng được thiết kế). Có tính đến thực tế là tập hợp các đối tượng mà người dùng có thể thao tác trong mọi trường hợp đều bị giới hạn và cũng tính đến thực tế là có thể đưa đủ thông tin vào các thuộc tính của từng đối tượng để có được bức tranh hoàn chỉnh về hình dạng của nó, có thể thực hiện “nâng cao” hình ảnh đồ họa ở dạng 3D mà không cần bất kỳ nỗ lực nào từ phía người dùng (đây chính xác là phương pháp được triển khai trong hệ thống ArCon). Kết quả là, người dùng gần như ngay lập tức nhận được bản trình bày ba chiều cho dự án của mình mà không tốn nhiều công sức. Sau đó, mô hình ba chiều thu được có thể được hiển thị và có được hình ảnh thực tế hoặc được chuyển sang hệ thống khác để chỉnh sửa thêm hoặc tính toán kỹ thuật. Hơn nữa, trong trường hợp này, người dùng hoàn toàn không cần bất kỳ kỹ năng tạo mô hình 3D đặc biệt nào.

Ghi chú

Cần chú ý nhiều hơn đến đặc tính này, vì việc tạo mô hình ba chiều từ bản vẽ từ lâu đã là trở ngại đối với tất cả các nhà phát triển hệ thống đồ họa kỹ thuật. Trên thực tế, nguyên tắc hoàn toàn ngược lại được thực hiện - tạo ra một bản vẽ (về cơ bản là hình chiếu của mô hình 3D) dựa trên mô hình đã hoàn thành. Cố gắng triển khai hành động đảo ngược(chuyển đổi từ hình ảnh hai chiều sang 3D) đã diễn ra trong một số hệ thống CAD nổi tiếng (đặc biệt là trong SolidWorks), nhưng khó có thể gọi là thành công. Các hạn chế quá nghiêm ngặt được áp dụng đối với hình ảnh hai chiều, không cho phép áp dụng chức năng đã khai báo ở mọi nơi. Tất nhiên, cách tiếp cận đối tượng mang đến cơ hội có được một mô hình ba chiều hoàn chỉnh, có tính đến các chi tiết cụ thể của các đối tượng cụ thể.

Cho dù một số lượng lớn Mặc dù có những ưu điểm nêu trên nhưng cách tiếp cận hướng đối tượng cũng có những nhược điểm.

Trước hết (và điều này là hiển nhiên) đây là tập hợp hạn chế của các đồ vật làm sẵn, cũng như không thể thay đổi chúng một cách tùy tiện. Điều này làm mất đi tính linh hoạt của chương trình, có nghĩa là nguyên tắc thiết kế dựa trên đối tượng chỉ có thể được áp dụng trong chuyên các hệ thống (như ArCon, Trang chủ chuyên nghiệp Thiết kế bạch kim, v.v.). Các nhà phát triển của các hệ thống như vậy cần phải tính đến kỹ lưỡng các đặc thù của ngành mà sản phẩm phần mềm nhằm mục đích tự động hóa và giải quyết vấn đề, đồng thời cũng tối đa hóa khả năng tùy chỉnh các thuộc tính của các đối tượng được đề xuất.

Ở đây vấn đề về chi phí và chức năng của hệ thống được đặt lên hàng đầu. Nếu bạn chắc chắn 100% rằng một chương trình chuyên biệt cụ thể phù hợp với mục đích của bạn thì không có gì phải nghi ngờ khi mua nó. Nếu không, bạn cần nghiên cứu chức năng chi tiết hơn để đảm bảo có thể giải quyết được các nhiệm vụ được giao hay trong trường hợp xấu nhất, bạn sẽ phải chi tiền cho một trình soạn thảo CAD “thông thường” và đắt tiền.

Nhược điểm thứ hai của hệ thống kỹ thuật đồ họa hướng đối tượng là vấn đề tích hợp với các hệ thống đồ họa khác. Đó là về không phải về bất kỳ vấn đề nào khi truyền dữ liệu - việc trao đổi cả thông tin hai chiều và ba chiều từ lâu đã được coi là một tiêu chuẩn cho bất kỳ chương trình thương mại. Bản chất của vấn đề nằm chính xác ở việc mất đi các giá trị thuộc tính của đối tượng, cũng như tất cả các mối quan hệ phân cấp được xây dựng giữa các đối tượng. Lý do rất rõ ràng: hệ thống mà bạn định xuất dự án có thể không hỗ trợ cách tiếp cận đối tượng hoặc có thể có danh sách các thuộc tính cho các đối tượng riêng của nó khác với danh sách này. Vì lý do này, khi lưu dự án từ chương trình ArCon sang một số định dạng khác (không phải đối tượng ArCon), chỉ có hình ảnh đồ họa được xuất.

Ghi chú

Nhìn về phía trước, tôi sẽ nói rằng các dự án ArCon+ 2005 có thể được xuất sang nhiều định dạng 2D và 3D khác nhau bằng cách sử dụng nhóm lệnh File? Xuất ở định dạng (Hình 1.2). Điều quan trọng cần lưu ý là chương trình hỗ trợ các định dạng trao đổi dữ liệu phổ biến như VRML, DXF, định dạng hệ thống 3ds Max, cũng như khả năng lưu dự án vào tệp EXE thực thi (xem thêm về điều này bên dưới).

Cơm. 1.2. Các định dạng được hỗ trợ để xuất dự án từ ArCon

Tình hình còn tệ hơn khi nhập dữ liệu từ hệ thống khác. Nếu chúng không được đưa về một định dạng cụ thể, hãy “đưa” chúng vào trong đối tượng hệ thống chuyên dụng không thể nào. Ví dụ: khi nhập bản vẽ từ AutoCAD vào ArCon, chỉ có thể tải hình ảnh. Đồng thời, ArCon sẽ không thể nhận biết độc lập vị trí trong hình ảnh mở có cửa sổ, cửa ra vào, tường, v.v., chứ đừng nói đến việc chỉ định đồ vật riêng lẻ tính chất khá hợp lý. Điều này có nghĩa là không thể chỉnh sửa thêm bản vẽ trong ArCon, cũng như “nâng” nó lên 3D. Việc nhập về cơ bản trở nên vô nghĩa, đó là lý do tại sao phần lớn các hệ thống thiết kế hướng đối tượng không có chức năng đọc dữ liệu đồ họa từ bên ngoài.

Tuy nhiên, bất chấp những thiếu sót đáng kể như vậy, tính dễ dàng làm việc và quan trọng nhất là tốc độ và sự rõ ràng trong việc thực hiện dự án vẫn chiếm ưu thế. Kết quả là, trong Gần đây các hệ thống giống như hệ thống được thảo luận trong cuốn sách này chương trình ArCon, đã tìm thấy ứng dụng rộng rãi trong việc giải quyết các vấn đề thiết kế khác nhau.

Ý tưởng mô hình hướng đối tượng(OOM) chắc chắn có liên quan đến lập trình hướng đối tượng(OOP). Cách tiếp cận phát triển phần mềm này, xuất hiện vào giữa những năm 1980, ban đầu nhằm giải quyết các vấn đề phát sinh từ sự phát triển không thể tránh khỏi và độ phức tạp của các chương trình, cũng như các nhiệm vụ xử lý và thao tác dữ liệu. Vào thời điểm đó, điều hiển nhiên là phương pháp truyền thống lập trình thủ tục Chúng tôi không thể đối phó với sự phức tạp ngày càng tăng của các chương trình và sự phát triển của chúng cũng như nhu cầu cải thiện độ tin cậy của chúng. Đồng thời, các nhiệm vụ tính toán và thuật toán tính toán, đặc biệt là trong lĩnh vực hỗ trợ kinh doanh, dần dần bắt đầu mờ nhạt, và các nhiệm vụ xử lý và thao tác dữ liệu bắt đầu chiếm vị trí đầu tiên.

Các khái niệm cơ bản của OOP là các khái niệm về lớp và đối tượng. Đồng thời, dưới lớp học sự trừu tượng nào đó của tổng thể được hiểu các đối tượng ai có bộ chung thuộc tính và có hành vi giống nhau. Mỗi đối tượng trong trường hợp này được coi là một thể hiện của lớp tương ứng. Theo định nghĩa, các đối tượng không có cùng thuộc tính hoặc hành vi giống nhau thì không thể được phân loại vào cùng một lớp. Mặc dù định nghĩa trên về một lớp có thể được cải tiến bằng cách tính đến các khái niệm OOP khác, nhưng nó mang tính tổng quát và đủ để tiến hành OOM.

Một đặc điểm quan trọng của các lớp là khả năng tổ chức của chúng dưới dạng một số cấu trúc phân cấp, trông giống như một sơ đồ phân loại cho các khái niệm logic hình thức. Về vấn đề này, cần lưu ý rằng mỗi khái niệm trong logic đều có phạm vi và nội dung. Phạm vi của một khái niệm đề cập đến tất cả các khái niệm có thể hình dung được khác mà khái niệm ban đầu có thể đóng vai trò là một phạm trù hoặc một phần xác định. Nội dung của một khái niệm là tổng thể tất cả các đặc điểm và thuộc tính của nó để phân biệt khái niệm này với tất cả các khái niệm khác. Trong logic hình thức, quy luật quan hệ nghịch đảo được biết đến: nếu nội dung của khái niệm A nằm trong nội dung của khái niệm B thì phạm vi của khái niệm B cũng nằm trong phạm vi của khái niệm A.

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 được xác định theo một cách nào đó, nhờ đó làm giảm khối lượng và tăng nội dung của nó. Một khái niệm ít tổng quát hơn xuất hiện, 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 thu được một khái niệm ở mức độ thấp nhất, việc cụ thể hóa thêm khái niệm này là không thể hoặc không thực tế.

Rõ ràng, nếu chúng ta lấy một mô hình nhất định làm khái niệm trừu tượng nhất để đạt được các mục tiêu OOM, thì sơ đồ khái niệm của mô hình hướng đối tượng có thể được biểu diễn như trong Hình. 4.5.

Hiện tại, ngôn ngữ thực hiện các phương pháp hướng đối tượng (bao gồm cả mô hình hóa quy trình nghiệp vụ) là ngôn ngữ UML (Ngôn ngữ mô hình hóa thống nhất), là ngôn ngữ mô hình hóa trực quan có mục đích chung được thiết kế để đặc tả, trực quan hóa, thiết kế và tài liệu hóa các thành phần phần mềm, quy trình kinh doanh và các hệ thống khác. Ngôn ngữ này có thể được sử dụng để xây dựng các mô hình khái niệm, logic và đồ họa hệ thống phức tạp cho nhiều mục đích khác nhau.

Mô tả chính thức về lĩnh vực chủ đề sử dụng UML dựa trên cấu trúc phân cấp của các biểu diễn mô hình (xem Hình 4.5), bao gồm bốn cấp độ: 1) siêu siêu mô hình; 2) siêu mô hình; 3) mô hình; 4) đồ vật.

Cơm. 4.5.

Cấp độ siêu mô hình tạo thành cơ sở ban đầu cho tất cả các chế độ xem siêu mô hình. Mục đích chính của nó là xác định ngôn ngữ để chỉ định siêu mô hình. Siêu mô hình xác định chính ngôn ngữ hình thức cấp độ cao trừu tượng và là mô tả ngắn gọn nhất của nó. Trong trường hợp này, một siêu mô hình có thể chỉ định một số siêu mô hình, nhờ đó đạt được tính linh hoạt tiềm năng khi bao gồm các khái niệm bổ sung.

Siêu mô hình là một phiên bản hoặc sự khởi tạo của siêu mô hình. Nhiệm vụ chính của cấp độ này là xác định ngôn ngữ để chỉ định mô hình. Cấp độ này mang tính xây dựng hơn cái trước vì nó có ngữ nghĩa phát triển hơn về các khái niệm cơ bản.

Mô hình trong bối cảnh ngôn ngữ UML là một thể hiện của siêu mô hình theo nghĩa là bất kỳ mô hình cụ thể nào của hệ thống chỉ nên sử dụng các khái niệm của siêu mô hình, chỉ định chúng liên quan đến một tình huống nhất định. Đây là cấp độ mô tả thông tin về một lĩnh vực chủ đề cụ thể. Tuy nhiên, nếu các khái niệm ngôn ngữ UML được sử dụng để xây dựng một mô hình thì cần phải có sự thống nhất hoàn toàn giữa các khái niệm cấp độ mô hình với các khái niệm ngôn ngữ cấp độ siêu mô hình. Việc cụ thể hóa các khái niệm mô hình xảy ra ở cấp độ đối tượng.

Từ quan điểm chung nhất, UML bao gồm hai phần tương tác: ngữ nghĩa ngôn ngữ và ký hiệu. Ngữ nghĩađược xác định cho hai loại mô hình: mô hình cấu trúc và mô hình hành vi. Mô hình cấu trúc, còn được gọi là mô hình tĩnh, mô tả cấu trúc của các thực thể hoặc thành phần (phần tử) của một số hệ thống, bao gồm các thuộc tính và mối quan hệ của chúng. Các mô hình hành vi, đôi khi được gọi là mô hình động, mô tả hành vi hoặc chức năng của các đối tượng hệ thống, sự tương tác giữa chúng, cũng như quá trình thay đổi trạng thái của các phần tử riêng lẻ và toàn bộ hệ thống. Cần lưu ý rằng UML được tạo ra ngay từ đầu là để hiển thị khía cạnh hành vi của hệ thống. Ký hiệu cùng một ngôn ngữ là một đặc tả đồ họa cho đại diện trực quan ngữ nghĩa của ngôn ngữ.

Trong ngôn ngữ UML, tất cả ý tưởng về mô hình của một hệ thống phức tạp đều được ghi lại dưới dạng cấu trúc đồ họa đặc biệt - sơ đồ Các loại sơ đồ sau đây được định nghĩa theo thuật ngữ UML (Hình 4.6):

• sử dụng sơ đồ trường hợp ( Sử dụng sơ đồ trường hợp);
• sơ đồ lớp ( Sơ đồ lớp);
• biểu đồ hành vi ( Sơ đồ hành vi);
• sơ đồ thực hiện ( Sơ đồ thực hiện).

Cơm. 4.6.

Mỗi sơ đồ này trình bày chi tiết và cụ thể hóa một góc nhìn khác nhau về mô hình hệ thống phức tạp theo thuật ngữ UML. Đồng thời, sơ đồ ca sử dụng thể hiện mô hình khái niệm tổng quát nhất của một hệ thống phức tạp, là điểm khởi đầu để xây dựng các sơ đồ khác. Sơ đồ lớp về cơ bản là một mô hình logic phản ánh các khía cạnh tĩnh của thiết kế cấu trúc của một hệ thống.

Sơ đồ hành vi đóng một vai trò đặc biệt, được thiết kế để phản ánh các khía cạnh năng động trong hoạt động của một hệ thống phức tạp. Loại sơ đồ này bao gồm:

• biểu đồ trạng thái ( Sơ đồ trạng thái);
• sơ đồ hoạt động (Sơ đồ hoạt động);
• sơ đồ tương tác (Sơ đồ tương tác):
• - sơ đồ tuần tự (Sơ đồ trình tự);
• - sơ đồ hợp tác (Sơ đồ hợp tác).

Cuối cùng, các sơ đồ thực hiện dùng để thể hiện thành phần vật lý hệ thống phức tạp. Bao gồm các:

• sơ đồ thành phần (Sơ đồ thành phần);
• sơ đồ triển khai (Sơ đồ triển khai).

Trong tài liệu hiện đại, tất cả các sơ đồ và đối tượng được liệt kê ở cấp độ siêu mô hình đều được xem xét một cách chi tiết.

Từ quan điểm của mô hình hóa quy trình nghiệp vụ, mô hình hóa trực quan trong IJML có thể được biểu diễn dưới dạng một quy trình nhất định đi xuống theo từng cấp độ từ mô hình khái niệm trừu tượng và tổng quát nhất hệ thống gốc sang mô hình logic và sau đó đến mô hình vật lý của hệ thống phần mềm tương ứng. Để đạt được những mục tiêu này, trước tiên một mô hình được xây dựng dưới dạng sơ đồ ca sử dụng (Sử dụng sơ đồ trường hợp), mô tả mục đích chức năng của hệ thống hay nói cách khác là hệ thống sẽ làm gì trong quá trình hoạt động. Sơ đồ ca sử dụng là sự biểu diễn khái niệm ban đầu hoặc mô hình khái niệm của một hệ thống trong quá trình thiết kế và phát triển của nó.

Việc phát triển sơ đồ ca sử dụng có các mục tiêu sau:

• xác định ranh giới và bối cảnh chung của lĩnh vực chủ đề được mô hình hóa ở giai đoạn đầu của thiết kế hệ thống;
• xây dựng Yêu câu chungđến hoạt động chức năng của hệ thống được thiết kế;
• phát triển mô hình khái niệm ban đầu của hệ thống để trình bày chi tiết tiếp theo dưới dạng mô hình logic và vật lý;
• chuẩn bị tài liệu ban đầu cho sự tương tác của nhà phát triển hệ thống với khách hàng và người dùng.

Bản chất của sơ đồ này như sau: hệ thống được thiết kế được biểu diễn dưới dạng tập hợp các thực thể hoặc tác nhân tương tác với hệ thống bằng cách sử dụng cái gọi là trường hợp sử dụng. trong đó diễn viên hoặc tác nhân là bất kỳ thực thể nào tương tác với hệ thống từ bên ngoài. Đó có thể là một người thiết bị kỹ thuật, chương trình hoặc bất kỳ hệ thống nào khác có khả năng đóng vai trò là nguồn ảnh hưởng đến hệ thống mô phỏng do chính nhà phát triển xác định. Đến lượt nó, trường hợp sử dụng dùng để mô tả các dịch vụ mà hệ thống cung cấp cho tác nhân. Nói cách khác, mỗi ca sử dụng xác định một tập hợp hành động nhất định được hệ thống thực hiện trong quá trình đối thoại với tác nhân. Tuy nhiên, không có gì được nói về cách thức tương tác của các tác nhân với hệ thống sẽ được thực hiện.

Các đối tượng chính của sơ đồ ca sử dụng được tóm tắt trong Bảng. 4.1.

Các đối tượng sơ đồ ca sử dụng UML cơ bản

Bảng 4.1

Cuối bàn. 4.1

	chỉ định	Mục đích
Các mối quan hệ trong sơ đồ ca sử dụng
mối quan hệ liên kết		Sự liên kết chỉ định các đặc điểm ngữ nghĩa của sự tương tác giữa các tác nhân và trường hợp sử dụng trong mô hình đồ họa của hệ thống
mở rộng mối quan hệ		Mối quan hệ mở rộng xác định mối quan hệ giữa các phiên bản của một trường hợp sử dụng cụ thể và một trường hợp sử dụng tổng quát hơn, các thuộc tính của chúng được xác định dựa trên cách các phiên bản này được kết hợp với nhau
Quan hệ khái quát hóa mối quan hệ khái quát hóa		Mối quan hệ khái quát hóa được sử dụng để chỉ ra thực tế là một số trường hợp sử dụng A có thể được khái quát hóa thành trường hợp sử dụng B. Trong trường hợp này, tùy chọn A sẽ là sự chuyên biệt hóa của tùy chọn B
Mối quan hệ bao gồm (bao gồm mối quan hệ)		Mối quan hệ bao hàm giữa hai trường hợp sử dụng chỉ ra rằng một số hành vi được chỉ định cho một trường hợp sử dụng được đưa vào như một thành phần cấu thành trong chuỗi hành vi của trường hợp sử dụng kia.

Một ví dụ về sơ đồ ca sử dụng được hiển thị trong Hình 2. 4.7.

Cơm. 4.7.

Từ góc độ mô hình hóa mô phỏng, sơ đồ ca sử dụng và sơ đồ hành vi được quan tâm nhiều nhất. Chính những sơ đồ này được thiết kế để mô tả chức năng (hoạt động, chuyển động) của các thành phần hệ thống. Ngoài ra, tổng thể các sơ đồ này xác định hoàn toàn mức độ khái niệm mô tả của một hệ thống phức tạp (mô hình khái niệm). Về vấn đề này, cần phải xem xét các sơ đồ này chi tiết hơn. Ví dụ: hãy lấy bộ phận bán hàng và tiếp thị của một công ty nào đó làm một hệ thống phức tạp. Mục đích chính của việc lập mô hình hệ thống này là tự động hóa công việc của bộ phận, tức là. trong việc xây dựng và triển khai hệ thống thông tin quản lý bán hàng. Người ta cho rằng không có sự tự động hóa các hoạt động sản xuất trong bộ phận.

Không đi sâu vào mô tả ngữ nghĩa của ngôn ngữ UML (nó được trình bày kỹ trong các tài liệu liên quan), chúng tôi sẽ chỉ trình bày các kết quả phân tích hướng đối tượng được hiển thị trong Hình. 4,8-4,12.

Dễ dàng nhận thấy rằng thời gian, với tư cách là thuộc tính quan trọng nhất của bất kỳ mô hình hành vi nào, chỉ hiện diện một cách gián tiếp trong các sơ đồ trên. Điều này có nghĩa là khi phân tích hành vi (hoặc thay đổi trạng thái), chỉ có thể thực hiện các đánh giá định tính như “không sớm hơn…”, “chỉ sau…”, v.v. Tuy nhiên, khi phân tích, ví dụ, một sơ đồ trạng thái (xem Hình 4.9), các câu hỏi sau sẽ xuất hiện một cách tự nhiên: “Tần suất các đơn hàng đến?”, “Họ mất bao lâu để xử lý?”, “Tỷ lệ giữa các đơn hàng là bao nhiêu?” số lượng máy trạm tự động (AWS) và số lượng người quản lý?”, “Hiệu suất của máy chủ phải như thế nào?” vân vân. Rõ ràng là không thể có được câu trả lời cho những câu hỏi này từ các sơ đồ đã cho nếu không sử dụng mô hình mô phỏng.

Cơm. 4.8.

Cơm. 4.9.

Cơm. 4.10.

Cơm. 4.11.

Cơm. 4.12.

Đồng thời, chúng tôi lưu ý khi xây dựng sơ đồ cuối cùng (sơ đồ thành phần và sơ đồ triển khai) phải chỉ rõ thông số kỹ thuật ví dụ như phần cứng, chẳng hạn như số lượng máy trạm (AWS), tốc độ xung nhịp bộ xử lý, tốc độ truyền mạng, dung lượng lưu trữ, v.v. Rõ ràng là các chỉ số được đánh giá quá cao có thể dẫn đến chi phí không hợp lý, còn những chỉ số được đánh giá thấp có thể dẫn đến giảm hiệu suất hiệu quả của toàn bộ hệ thống. Do đó, việc chứng minh các giá trị cần thiết của tất cả các chỉ số kỹ thuật chỉ có thể dựa trên kết quả của mô hình mô phỏng.

Các đối tượng sơ đồ UML mô hình hóa hành vi hệ thống có thể được liên kết với các đối tượng Mô hình mô phỏng. Các sơ đồ quan trọng nhất mang thông tin cần thiết trong trường hợp này là sơ đồ ca sử dụng và sơ đồ trạng thái. Mối quan hệ giữa các đối tượng của sơ đồ này và các đối tượng của mô hình mô phỏng được thể hiện trong Bảng. 4.2.

Bảng 4.2

Mối quan hệ giữa các đối tượng sơ đồ UML và các đối tượng mô hình mô phỏng

	Đối tượng biểu đồ trạng thái	Đối tượng mô hình mô phỏng

Đối tượng sơ đồ ca sử dụng	Đối tượng biểu đồ trạng thái	Đối tượng mô hình mô phỏng

Phân tích bảng 4.2 cho thấy rằng, mặc dù ngôn ngữ UML có đủ khả năng diễn đạt để xây dựng mô hình mô phỏng trực quan nhưng các công cụ của nó rõ ràng là chưa đủ. Các đối tượng trừu tượng nhất định của mô hình mô phỏng tạo thành một mô hình khái niệm về hoạt động của bộ phận bán hàng và tiếp thị.

Hiện nay, khái niệm về hướng đối tượng người mẫu . Khái niệm này là kết quả của sự phát triển khái niệm Và bản thể học người mẫu

Mô hình hóa khái niệm. Quá trình có mục đích là xác định, phân tích và mô tả các thực thể của lĩnh vực chủ đề liên quan đến mục tiêu của nó, mối quan hệ giữa chúng, những ràng buộc mà chúng phải đáp ứng, cũng như hành vi của chúng (theo nghĩa là những thay đổi trong trạng thái của chúng theo thời gian). ), được gọi là mô hình hóa khái niệm. Về cơ bản, mô hình khái niệm đại diện cho cấu trúc kiến ​​thức về lĩnh vực chủ đề của hệ thống, đây là điều kiện tiên quyết cần thiết để có trình độ chuyên môn thiết kế những hệ thống như vậy.

Mô hình hóa dựa trên ontology Khái niệm mô hình hóa khái niệm đã được làm rõ và mở rộng bằng cách sử dụng khái niệm ontology. Bản thể học là một đặc tả cấu trúc của một lĩnh vực chủ đề nhất định, cách biểu diễn chính thức của nó, bao gồm từ điển (hoặc tên) các con trỏ tới các thuật ngữ của lĩnh vực chủ đề đó và biểu thức logic, mô tả cách chúng liên hệ với nhau. Sự thay đổi về thuật ngữ đã dẫn đến sự xuất hiện của các khái niệm như mô hình bản thể học Và kỹ thuật bản thể học.

Kỹ thuật bản thể là quá trình thiết kế và phát triển ontology. Nó là cốt lõi của khái niệm “quản lý tri thức” và công nghệ kỹ thuật tri thức, bao gồm một loạt các phương pháp - từ khai thác kiến ​​thức đến cấu trúc và hình thức hóa nó.

Kỹ thuật bản thể học phát sinh vào giữa những năm 90 ở các tập đoàn lớn, nơi các vấn đề xử lý thông tin trở nên đặc biệt gay gắt và nghiêm trọng. Rõ ràng là nút thắt chính trong công nghệ quản trị doanh nghiệp là xử lý kiến ​​thứcđược các chuyên gia của công ty tích lũy, vì chính kiến ​​thức mang lại lợi thế so với đối thủ cạnh tranh. Đây là cách mà thuật ngữ “Quản lý tri thức” hay “Quản lý tri thức” (KM) xuất hiện. KM được hiểu là một tập hợp các quy trình quản lý việc tạo, phân phối, xử lý và sử dụng thông tin trong doanh nghiệp.

Mô hình hướng đối tượng. Mô hình bản thể học cũng hình thành nền tảng của các phương pháp luận mô hình hướng đối tượng(OOM), tập trung chủ yếu vào việc tạo lớn và phức tạp hệ thống, sự phát triển chung của họ, hỗ trợ tích cực tiếp theo trong quá trình vận hành và sửa đổi thường xuyên. OOM bao gồm:

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

• thiết kế hướng đối tượng (Object-Oriented Design, OOD),

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

Phương pháp OOA là một phương pháp để phân tích thực thể thực (hoặc lý tưởng) của thế giới dựa trên các khái niệm giai cấp (như kiểuđối tượng) và đối tượng (như sao chép lớp học). Các đối tượng và mối quan hệ của chúng được thể hiện trong sơ đồ lớp phân loại phương pháp này thành mô hình bản thể học.

Để triển khai các mô hình OO, một hướng đối tượng ngôn ngữ mô hình thống nhất(Ngôn ngữ mô hình hóa thống nhất, UML). Nó được sử dụng để chỉ định, trực quan hóa và ghi lại các thành phần của hệ thống thông tin (phần mềm) hướng đối tượng trong quá trình phát triển.

Để mô hình hóa các hệ thống như vậy, UML cung cấp hơn chục loại sơ đồ mô hình hóa cấu trúc và chức năng (“hành vi”) của các hệ thống đối tượng theo các quan điểm khác nhau. Mô hình hóa bắt đầu bằng việc phân tích và mô hình hóa lĩnh vực chủ đề của hệ thống phần mềm và phát triển các yêu cầu của người dùng. Danh sách các yêu cầu đã phát triển được thể hiện bằng sơ đồ Ca sử dụng UML. Cấu trúc của hệ thống sau đó được mô hình hóa dưới dạng sơ đồ “cấu trúc”:

Sơ đồ lớp,

Sơ đồ các thành phần phần mềm (Component) và

Sơ đồ triển khai các thành phần phần mềm trên nền tảng phần mềm và phần cứng (Deployment Diagram).

Các đặc tính động của hệ thống được mô hình hóa bằng một tập hợp các sơ đồ về các loại “hành vi” xác định

Các thuật toán tương tác của các đối tượng phần mềm (Sơ đồ tuần tự và cộng tác),

Hành vi của các đối tượng riêng biệt (sơ đồ trạng thái),

Các quá trình xảy ra trong hệ thống đối tượng (Activity diagrams.

Như một ví dụ trong hình. 36 trình bày các yêu cầu của người dùng đối với một hiệu sách điện tử (dưới dạng sơ đồ Use-Case của hệ thống Rational Rose).

Hình 36. Sơ đồ Use Case của dự án Rose eBookShop

Cơm. 37. Sơ đồ lớp miền eBookShop Rose

Cơm. 38. Mô hình tĩnh hoàn chỉnh của dự án eBookShop Rose (dưới dạng Sơ đồ lớp UML)

Mô hình này dựa trên mô hình miền cửa hàng sách được hiển thị trong Hình 2. 37. Một mô hình tĩnh hoàn chỉnh của một hiệu sách điện tử đáp ứng mọi yêu cầu của người dùng được thể hiện trên Hình 2. 38.

Các kỹ thuật mô hình hóa hướng đối tượng đã cách mạng hóa kiến ​​trúc của các hệ thống thông tin hiện đại. Để thay thế kiến ​​trúc truyền thống xử lý dữ liệu thuật toánđã đến kiến trúc dựa trên mô hình (đối tượng)(Kiến trúc hướng mô hình, MDA).

Sách giáo khoa bao gồm: một bản tóm tắt ngắn gọn về ngôn ngữ UML - phần của nó có thể được sử dụng làm cơ sở cho ngôn ngữ để mô hình hóa các hệ thống động phức tạp; mô tả và khả năng của ngôn ngữ mô hình hóa mới được các tác giả đề xuất dựa trên automata lai, một phần mở rộng của UML; tổng quan lịch sử và ví dụ về các cách tiếp cận khác nhau để thiết kế các công cụ mô hình hóa; phân tích hướng đối tượng của các hệ thống động phức tạp. Cuốn sách này là cuốn thứ hai trong ba cuốn sách được hợp nhất dưới tựa đề chung là Mô hình hóa hệ thống.

Sự cần thiết của một ngôn ngữ mô tả mô hình thống nhất
Công nghệ truyền thống để thiết kế các hệ thống phức tạp, không liên quan đến mô hình máy tính sơ bộ, bao gồm các giai đoạn chính sau: xây dựng các yêu cầu cho hệ thống tương lai, phát triển tài liệu thiết kế dựa trên chúng, tạo ra nguyên mẫu, thử nghiệm sự tuân thủ các yêu cầu và duy trì kiểu dáng công nghiệp.

Lý tưởng nhất là một đặc tả chức năng hoàn chỉnh, được phát triển bởi các nhà phân tích hệ thống hoặc tự động bởi công nghệ máy tính, đã là quyết định thiết kế, tất cả những gì còn lại là xây dựng một mô hình vật lý theo thông số kỹ thuật này, đây sẽ là hệ thống được thiết kế. Thật không may, nó không phải vậy. Việc tạo ra một hệ thống thực tế đáp ứng các thông số kỹ thuật chức năng đã phát triển đòi hỏi các giải pháp kỹ thuật sáng tạo, không chính thức hóa và lao động thủ công.

Ngay cả “phần mềm” dường như đã được chính thức hóa đầy đủ của các hệ thống kỹ thuật hiện đại - phần mềm nhúng - thường được thực thi trên các máy tính nhúng hoặc bộ vi xử lý đặc biệt với các kênh trao đổi đặc biệt, hệ điều hành đặc biệt và các tính năng khác yêu cầu tinh chỉnh “thủ công” phần mềm đã phát triển. . Nếu không có “sổ tay” này, khâu chính thức hóa kém thì khó đảm bảo các yêu cầu đặc biệt Hoạt động đáng tin cậy hệ thống ở nhiệt độ nhất định, độ rung, quá tải, mức độ bức xạ, giới hạn thể tích và trọng lượng. Chương 5 thảo luận về các điều kiện theo đó thế hệ tự động phần mềm nhúng nhưng các thông số kỹ thuật chức năng và những điều kiện này vẫn còn rất xa so với thực tế ngày nay.

Mục lục
Mục lục
Lời nói đầu
Chương 1. Cách tiếp cận hướng đối tượng trong mô hình hóa
Sự cần thiết của một ngôn ngữ mô tả mô hình thống nhất
Các lớp, thể hiện và hệ thống đa thành phần
Sử dụng UML ở giai đoạn thiết kế ban đầu
Sơ đồ lớp
Thuộc tính
Hành vi
Hoạt động và phương pháp
Các lớp trừu tượng và cụ thể. Giao diện
Các lớp và mối quan hệ
Sự kết hợp
Sự khái quát
Tổng hợp
Di sản
Đa hình
Hành vi. Sơ đồ trạng thái
Phân loại có cấu trúc
Các thành phần
Sự kiện và tín hiệu
Gói
Người mẫu
Chương 2. Mô hình hóa hướng đối tượng của các hệ động lực phức tạp dựa trên hình thức ô tô lai
Lớp hoạt động và đối tượng động hoạt động
Gói và mô hình
Sử dụng đối tượng thụ động
Biến
Loại dữ liệu
Các loại vô hướng
Loại thực
Kiểu số nguyên
kiểu Boolean
Các loại enum
Các loại ký tự
Loại thông thường
Vectơ
Ma trận
Mảng
Danh sách
Loại kết hợp (bản ghi)
Các loại được xác định rõ ràng
Tín hiệu
Đúc kiểu tự động
Hệ phương trình
Bản đồ hành vi
Những trạng thái
Chuyển tiếp
Sơ đồ kết cấu
Các đối tượng
Kết nối
Cấu trúc thông thường
Kế thừa lớp
Thêm các yếu tố mô tả mới
Ghi đè các phần tử được kế thừa
Đa hình
Các lớp tham số
Chương 3. Mô hình hóa hệ thống hybrid và hướng tiếp cận hướng đối tượng trong các gói khác nhau
Mô hình hóa các hệ thống lai trong các công cụ cho máy tính lớn
Ngôn ngữ SLAM II
ngôn ngữ NEDIS
Mô hình lai trong các công cụ tạo mô hình hiện đại
Mô hình hóa các hệ thống lai trong gói Simulink ("mô hình khối")
Mô hình hóa các hệ thống lai bằng ngôn ngữ Modelica ("mô hình vật lý")
Hướng lai
Ngôn ngữ mô hình hóa hướng đối tượng
Simula-67 và NEDIS
đối tượngToán học
Omola
người mẫu
Công cụ tạo mô hình khối
Phân tích các ngôn ngữ OOM hiện có liên quan đến mô hình hóa các hệ thống động phức tạp
Chương 4. Mô hình đa đối tượng
Chương 5. Mô hình hóa hướng đối tượng và phân tích hướng đối tượng
Hệ thống kỹ thuật phức tạp
Phân tích hướng đối tượng trong việc phát triển các hệ thống kỹ thuật phức tạp
Mô hình hướng đối tượng ở các giai đoạn phát triển và bảo trì tiếp theo của hệ thống kỹ thuật phức tạp
Mô hình phân tích hệ thống làm nền tảng cho công nghệ thiết kế “end-to-end”
Văn học
Đọc thêm cho Chương 1
Đọc thêm cho Chương 2
Đọc thêm cho Chương 3
Đọc thêm cho Chương 4
Đọc thêm cho Chương 5
Chỉ số chủ đề.

Tải xuống miễn phí sách điện tửở dạng thuận tiện, hãy xem và đọc:
Tải xuống cuốn sách Mô hình hóa hệ thống, Cách tiếp cận hướng đối tượng, Kolesov Yu., Senichenkov Yu., 2012 - fileskachat.com, tải xuống nhanh và miễn phí.

Tải PDF
Bạn có thể mua cuốn sách này dưới đây giá tốt nhất với mức giảm giá khi giao hàng trên khắp nước Nga.

Mikhail Vasiliev, Igor Khomkov, Sergei Shapovalenko

Hầu như ở tất cả các giai đoạn vòng đời Hệ thống thông tin (IS) - cả về thiết kế, khi các đặc điểm chính của hệ thống được đặt ra cũng như việc bảo trì và quản lý IS đã được xây dựng - có nhiều câu hỏi có tầm quan trọng hàng đầu được đặt ra. Liệu nó có kiến trúc này IP để đáp ứng nhu cầu ngày càng tăng? Những điểm nghẽn nào cần được chú ý nhất? Những khoản đầu tư nào là cần thiết để IP duy trì tình trạng hoạt động trong một năm?.. ba năm?.. năm năm? Hiệu quả của IP được sử dụng là gì?

Trả lời tất cả những câu hỏi này không hề dễ dàng chút nào. Thậm chí còn khó hơn để trả lời chúng một cách chính xác. Phân tích hệ thống thông tin doanh nghiệp ở bất kỳ giai đoạn tồn tại nào của nó là một vấn đề phức tạp.

Có thể nói rằng sự phức tạp của hệ thống thông tin doanh nghiệp không phải là ngẫu nhiên mà là một đặc tính cần thiết. Nó được xác định bởi một số lý do, trong đó có những lý do sau:

Sự phức tạp của vấn đề đang được giải quyết;

Sự phức tạp của việc phát triển IS;

Khó khăn trong việc đảm bảo các thông số như tính đầy đủ, khả năng mở rộng, độ tin cậy, hiệu quả chi phí và bảo mật;

Khó khăn trong việc mô tả các hệ thống con IS riêng lẻ.

Đánh giá khách quan có thể được cung cấp bằng cách sử dụng các công nghệ mô hình hóa. Xây dựng mô hình, phân tích mô hình và tìm câu trả lời cho câu hỏi “điều gì sẽ xảy ra nếu…?” cho phép chúng tôi dự đoán hành vi của IS trong Những tình huống khác nhau. Việc tạo nguyên mẫu và xây dựng mô hình máy tính của IC thường được sử dụng nhất.

Hiện tại, có ba công ty dẫn đầu trong thị trường công cụ mô hình hóa hệ thống thông tin. Đó là các công ty Mỹ MIL3 (hệ thống mô hình OPNET), Make Systems (hệ thống NetMaker XA) và CACI Products Company (hệ thống COMNET). Trong bộ lễ phục. 1 hiển thị cửa sổ chính của hệ thống OPNET. (Trong PC Week/RE, số 34/98, trang 36, Hình 2 hiển thị một cửa sổ trình bày đồ họa các kết quả trong hệ thống OPNET.) Chúng ta hãy tập trung vào một trong những hệ thống này và cách tiếp cận được triển khai trong đó nhiều hơn. chi tiết.

Công nghệ mô hình hóa vi mạch sử dụng COMNET III

Cách rõ ràng để mô hình hóa các hệ thống phức tạp là phân rã chúng theo nguyên tắc cổ xưa của Divide et impera (Chia để trị - tiếng Latin). Biểu diễn phân cấp của IS phức tạp như một tập hợp các hệ thống con được kết nối với nhau là chìa khóa để khám phá tình huống này. Các hệ thống con thu được từ sự phân rã như vậy có thể lần lượt được chia thành các hệ thống con của cấp độ tiếp theo của hệ thống phân cấp, v.v. Khả năng phân rã các hệ thống phức tạp cho phép chúng ta tạo ra các mô hình của chúng. Tuy nhiên, trên con đường này, điều cực kỳ quan trọng là có thể dừng lại kịp thời.

Giai đoạn cuối cùng của quá trình phân rã được xác định bởi mức trừu tượng thấp nhất được áp dụng trong mỗi mô hình cụ thể. Sự phân mảnh quá chi tiết có thể dẫn đến một kết quả hoàn toàn trái ngược với những gì được mong đợi: thay vì đơn giản hóa hệ thống được mô hình hóa, bạn có thể kết thúc với sự phức tạp của nó, cái gọi là “bạn không thể nhìn thấy rừng nếu chỉ có cây”. Vì vậy, việc lựa chọn mức độ trừu tượng phù hợp là điều cần thiết để mô hình hóa thành công.

Bước tiếp theo để tạo điều kiện thuận lợi cho việc mô hình hóa các hệ thống phức tạp là phát hiện và tách biệt các khái niệm trừu tượng chung. Giả sử rằng chúng ta đã phân tách IS được mô hình hóa và thu được một hệ thống phân cấp thực thể nhất định. Ví dụ, bộ định tuyến của Cisco 7500 và NS7000, có nhiều card mạng và thực hiện định tuyến phần mềm, có thể được coi là hai đối tượng hoàn toàn khác nhau và là hai đối tượng thuộc cùng một loại bộ định tuyến. Việc phân tách hệ thống bằng cách sử dụng phép ẩn dụ lớp kết hợp với mức độ trừu tượng được chọn chính xác cho phép bạn đơn giản hóa triệt để việc xây dựng mô hình IS.

Cơm. 1. Cửa sổ chính của hệ thống OPNET

Thông thường, hai loại phân rã chính được xem xét: thuật toán, phân chia hệ thống đang nghiên cứu theo các nguyên tắc hoạt động của nó, tức là các quá trình xảy ra trong nó theo một thứ tự nhất định và hướng đối tượng, giúp phân chia hệ thống theo nghiên cứu các lớp trừu tượng tương tự. Cả hai kiểu phân rã đều tìm được đường vào COMNET III.

Cách tiếp cận xây dựng mô hình trong COMNET III có thể được trình bày dưới dạng trình tự chuẩn các bước:

Mô tả cấu trúc liên kết IC và xác định các thông số thiết bị;

Mô tả nguồn lưu lượng và hành vi của chúng, mô tả tải mạng;

Định nghĩa kịch bản mô phỏng.

Xác định cấu trúc liên kết IS và các kết nối giữa các nguồn lưu lượng và các nút cấu trúc liên kết là một lĩnh vực lý tưởng để áp dụng phân rã hướng đối tượng. Cần phải phân tách thuật toán để mô tả hành vi của các nguồn lưu lượng và những thay đổi về tải mạng theo thời gian.

Như đã đề cập, các điều kiện biên cho việc phân rã IS phụ thuộc vào mức độ trừu tượng được yêu cầu. Tính trừu tượng cho phép nhà phát triển tạo một dự án IS hoặc quản trị viên hệ thống duy trì nó, tách các tính năng quan trọng nhất về hành vi của nó khỏi cách chúng được triển khai chính xác. “Một sự trừu tượng tốt là một sự trừu tượng nhấn mạnh những chi tiết cần thiết để xem xét và sử dụng, đồng thời loại bỏ những chi tiết hiện không quan trọng hoặc làm phân tán sự chú ý”*1. Vì vậy, trong một tình huống, khi mô tả một máy tính, chỉ cần định nghĩa nó như một nguồn lưu lượng là đủ mà không cần đi sâu vào mô tả chi tiết về kiến ​​trúc, trong khi trong một tình huống khác, việc xem xét chi tiết các đặc điểm như số lượng bộ xử lý và các tham số hệ thống con đĩa có thể được yêu cầu.

*1. Shaw M. Kỹ thuật trừu tượng trong ngôn ngữ lập trình hiện đại. - Phần mềm IEEE, tháng 10. 1984, v. 1(4), tr.10.

Hệ thống COMNET áp dụng đầy đủ phương pháp phân rã hướng đối tượng, có thể giảm đáng kể thời gian lập mô hình và làm cho quy trình của nó trở nên trực quan, tương quan rõ ràng với hệ thống thực. Mô hình được tạo ra từ các đối tượng, một loại “khối xây dựng”, quen thuộc với người dùng qua trải nghiệm thực tế. Hệ thống COMNET đi kèm với một thư viện lớn gồm các đối tượng như vậy - các mô hình thiết bị mạng thực và các phương pháp truy cập vào môi trường. Chúng ta hãy xem xét kỹ hơn mô hình đối tượng COMNET (Hình 2).

Cơm. 2. Thư viện lớp COMNET III cơ bản

Các đối tượng trong hệ thống này có thể được chia thành hai lớp: những lớp được sử dụng, thứ nhất, để mô tả cấu trúc liên kết và thứ hai, để mô tả các đặc tính lưu lượng và tải của mạng. Màn hình COMNET III cơ bản với một tập hợp các lớp thư viện được hiển thị trong Hình 2. 3.

Cơm. 3. Màn hình chính hệ thống COMNET

Mô tả cấu trúc liên kết trong COMNET III

Các khái niệm cấu trúc liên kết cơ bản trong hệ thống COMNET III như nút, kết nối, cung đã được mô tả trong PC Week/RE, số 34/98, tr. 34.

Ngoài các nút, kết nối và cung để mô tả cấu trúc liên kết phân cấp và mô hình hóa các miền có thể định tuyến độc lập, hệ thống COMNET còn bao gồm một lớp bổ sung khác, các đối tượng của lớp này cũng có thể được đặt ở các đỉnh của biểu đồ - mạng con.

Việc sử dụng các cơ chế kế thừa, bao gồm nhiều cơ chế kế thừa, sẽ mở rộng phạm vi các lớp được sử dụng.

Lớp nút được kế thừa bởi bốn lớp mới.

Lớp “Nút Máy tính và Truyền thông” (Nút C&C, Nút Máy tính và Truyền thông)

Các đối tượng này có thể đóng vai trò là nguồn hoặc bộ thu lưu lượng và cũng được sử dụng để mô hình hóa các hệ thống phần mềm phức tạp có tính đến tải của bộ xử lý và hệ thống con đĩa. Các nút IC được mô tả bằng Nút C&C cũng có thể được sử dụng để mô hình hóa các bộ định tuyến phần mềm.

Lớp nút nhóm máy tính

Đối tượng chỉ có thể được sử dụng để mô hình hóa các hệ thống máy tính, vì chức năng của chúng chỉ bao gồm nguồn và bộ thu lưu lượng. Theo quy định, nó được sử dụng để mô tả các nhóm máy tính có hành vi giống hệt nhau.

Lớp nút bộ định tuyến

Các đối tượng thuộc loại này được sử dụng để mô hình hóa các bộ định tuyến phần cứng. Giống như Nút C&C, Nút Bộ định tuyến có thể hoạt động vừa là nguồn vừa là nơi nhận lưu lượng truy cập, đồng thời chạy các ứng dụng sử dụng tài nguyên phần cứng của nút (bộ xử lý, hệ thống con đĩa). Để mô tả chi tiết hơn về việc triển khai phần cứng của các đối tượng mô phỏng, một số thuộc tính bổ sung đã được giới thiệu, chẳng hạn như sự hiện diện và các thông số của bus nội bộ, cho phép bạn mô phỏng luồng lưu lượng nội bộ giữa các cổng đầu vào và đầu ra của đối tượng.

Chuyển lớp nút

Các đối tượng thuộc loại Nút chuyển mạch, có khả năng định tuyến, được sử dụng để mô hình hóa các thiết bị chuyển mạch dành một lượng thời gian không đáng kể để truyền lưu lượng giữa các cổng nội bộ. Tuy nhiên, những đối tượng này, không giống như ba đối tượng trước, không thể được sử dụng làm nguồn hoặc bộ thu lưu lượng.

Các đối tượng của các lớp nút C&C, Nút nhóm máy tính và Bộ định tuyến để mô hình hóa các hệ thống phần mềm phức tạp bao gồm một kho chứa các lệnh sử dụng các thuộc tính đối tượng đã được đề cập, chẳng hạn như các đặc điểm của hệ thống con đĩa. Đến một thư viện đối tượng được cập nhật liên tục nhiều lớp học khác nhau COMNET bao gồm nhiều mẫu thiết bị phần cứng thực tế.

Đối tượng liên kết kế thừa hai đối tượng mới.

Lớp “Liên kết điểm-điểm”

Lớp này được sử dụng để mô tả các kênh giữa hai nút. Ví dụ về các kết nối như vậy bao gồm các đường truyền thuê riêng kết nối các bộ định tuyến trong mạng diện rộng hoặc kết nối trong mạng chuyển mạch.

Lớp “Liên kết đa truy cập”

Trường ứng dụng của lớp này là các tình huống trong đó một số nút có quyền truy cập vào cùng một phương tiện truyền dữ liệu. Đổi lại, đối tượng này được kế thừa bởi một số đối tượng mới mô tả các sự kiện cụ thể về việc triển khai phương pháp truy cập phương tiện, chẳng hạn như Phát hiện sóng mang, Truyền mã thông báo, SONET, v.v. (xem Hình 2).

Cho đến nay chúng ta đã xem xét các trường hợp trong đó một đối tượng cha được kế thừa bởi một đối tượng con. Tuy nhiên, cách tiếp cận hướng đối tượng cũng cho phép xử lý các tình huống phức tạp hơn với nhiều kế thừa. Hình thức kế thừa này cũng được áp dụng trong hệ thống COMNET. Ở đây, đa kế thừa được sử dụng để tạo các đối tượng thuộc các lớp quan trọng như Mạng chuyển tiếp và Đám mây WAN.

Cả hai lớp đều là hậu duệ của hai lớp cha - Subnet và Link. Hình thức thừa kế được thể hiện trong hình. 2. Hãy xem xét tùy chọn này chi tiết hơn.

Lớp mạng con

Một lớp học cực kỳ quan trọng. Được sử dụng để tạo cấu trúc liên kết IC phân cấp, nó cho phép bạn mô tả chính xác các mạng con bằng các thuật toán định tuyến khác nhau, độc lập với thuật toán được sử dụng trên đường trục. Ngoài ra, mạng con còn được sử dụng để ẩn chi tiết quá mức khi lập mô hình IC phức tạp. Trong COMNET, chúng được sử dụng để mô tả các hệ thống có độ sâu lồng nhau tùy ý. Các kết nối giữa cấu trúc liên kết mạng con nội bộ và cấu trúc liên kết đường trục được thực hiện bằng cách sử dụng các điểm truy cập, số lượng điểm truy cập có thể tùy ý (xem Hình 3).

Lớp “Mạng quá cảnh”

Con của mạng con và kết nối là một đối tượng kết hợp các thuộc tính của đối tượng cha của nó. Mạng chuyển tuyến có thể được coi là cả kết nối và mạng con cùng một lúc. Với tư cách là một kết nối, nó chuyển tiếp các gói từ bộ đệm đầu ra của một nút tới bộ đệm đầu vào của nút khác. Ở dạng mạng con, mạng chuyển tuyến tạo ra trong phạm vi ranh giới của nó một khu vực có thuật toán định tuyến riêng.

Lớp “Đám mây” (WAN Cloud)

Các đối tượng của lớp này cho phép bạn tạo các biểu diễn trừu tượng cho mạng lưới toàn cầu, đồng thời kế thừa các thuộc tính của đối tượng cha - Subnet và Link. Từ góc độ cấu trúc liên kết, đối tượng Đám mây WAN hoạt động giống như một đối tượng kết nối, với biểu tượng của nó kết nối trực tiếp với các nút. Về cấu trúc bên trong, đám mây bao gồm một tập hợp các mạch ảo và liên kết truy cập, một loại kết nối điểm-điểm để mô hình hóa mạng toàn cầu.

Mô tả lưu lượng và tải mạng trong COMNET III

Như chúng tôi đã nói, mô hình IS trong COMNET bao gồm hai phần: mô tả cấu trúc liên kết hệ thống và mô tả nguồn lưu lượng và tải mạng. Chúng ta đã xem xét phạm vi cơ bản của các đối tượng liên quan đến cấu trúc liên kết. Bây giờ hãy chuyển sang các đối tượng mô tả giao thông.

COMNET cung cấp nhiều công cụ để mô tả lưu lượng truy cập.

Lớp tin nhắn

Các đối tượng thuộc lớp này cho phép bạn gửi một tin nhắn tới một đối tượng người nhận hoặc nhiều đối tượng. Việc chuyển tiếp các tin nhắn như vậy được coi là một chuỗi các datagram, trong đó mỗi gói được định tuyến độc lập với các gói khác.

Lớp “Phản hồi”

Các đối tượng của lớp này chỉ có thể được sử dụng để gửi tin nhắn phản hồi. Chúng được kiểm soát bởi sự xuất hiện của các thông báo được tạo bởi các đối tượng của lớp Thông báo hoặc Phản hồi. Người nhận các thông báo của lớp Phản hồi sẽ luôn là một đối tượng của lớp Nút mà nguồn của các thông báo điều khiển (của lớp Phản hồi hoặc Thông báo) được kết nối.

Lớp “Gọi”

Các đối tượng của lớp Call được sử dụng để tạo ra các mô hình mạng chuyển mạch. Nguồn cuộc gọi được mô tả bằng một tập hợp các tham số như luật phân phối, thời lượng và có tính đến lớp định tuyến, yêu cầu về băng thông.

Lớp phiên

Các đối tượng này được sử dụng để mô hình hóa các phiên bao gồm các tập hợp thông báo hoặc thông báo được định tuyến qua kết nối ảo. Một phiên được bắt đầu bằng cách gửi gói thiết lập phiên và nhận gói xác nhận. Sau đó, một số lượng tin nhắn tùy ý có thể được gửi trong phiên, cũng được mô tả trong đối tượng lớp Session. Các tin nhắn như vậy được định tuyến dưới dạng datagram hoặc dưới dạng kết nối ảo, tùy thuộc vào thuật toán định tuyến trên đường trục hoặc mạng con chứa đối tượng.

Cũng lưu ý rằng COMNET III sử dụng cái gọi là tệp lưu lượng truy cập bên ngoài, có thể thu được bằng nhiều máy phân tích lưu lượng truy cập khác nhau.

Đặc biệt quan tâm là các đối tượng của lớp “Ứng dụng”, là kết quả của sự kế thừa nhiều lần của các lớp Tin nhắn, Phản hồi, Cuộc gọi và Phiên (xem Hình 2). Các đối tượng của nó cho phép bạn mô tả linh hoạt nhất khối lượng công việc của mạng và hành vi của các nguồn lưu lượng trong mô hình. Hơn nữa, khi sử dụng chúng, hầu hết mọi loại hệ thống phần mềm đều có thể được mô phỏng dễ dàng, kể cả những hệ thống phân tán, chẳng hạn như DBMS, hệ thống bưu chính vân vân.

Ứng dụng thực sự được mô tả bởi các đối tượng của lớp này bao gồm ba thành phần. Đầu tiên, đây là các tham số của nút mà đối tượng lớp Ứng dụng được kết nối. Sử dụng các tham số này, bạn đặt các đặc tính và số lượng bộ xử lý cần thiết và các hệ thống con đĩa. Thứ hai, đây được gọi là kho lệnh sử dụng các đặc điểm nút nêu trên. Và thứ ba, đây chính là đối tượng Ứng dụng, nó điều khiển trình tự thực hiện các lệnh này.

Kho lưu trữ lệnh của nút và do đó đối tượng lớp Ứng dụng có thể chứa các lệnh sau:

Tin nhắn truyền tải (truyền tin nhắn). Lệnh này là kết quả của một đối tượng được lớp Ứng dụng kế thừa từ đối tượng cha của lớp Message.

Thiết lập là kết quả của việc kế thừa lớp Session.

Thông báo Trả lời là phần kế thừa của lớp Phản hồi.

Lọc tin nhắn (lọc tin nhắn). Lệnh này cho phép bạn tạm dừng tất cả các hoạt động được mô tả trong đối tượng lớp Ứng dụng cho đến khi nhận được thông báo thỏa mãn các điều kiện lọc.

Quá trình. Lệnh này mô phỏng quá trình xử lý gây ra tải CPU.

Đọc và Viết (đọc và viết). Hai lệnh này cũng cho phép bạn mô phỏng sự bận rộn của bộ xử lý nút, nhưng trong bối cảnh tương tác với hệ thống con đĩađọc và ghi tập tin.

Do đó, bằng cách sử dụng các lớp Ứng dụng, Tin nhắn, Phản hồi, Phiên và Cuộc gọi, có thể mô phỏng linh hoạt tải mạng hiện tại và miêu tả cụ thể hành vi của các hệ thống phần mềm có trong IS. Điều cực kỳ quan trọng là các lớp này cho phép bạn lập mô hình phân tán phức tạp hệ thống phần mềm và tác động của chúng lên cơ sở hạ tầng mạng hiện có.

Đối tượng COMNET III: Trừu tượng tham số

Khi nói về tập lõi của các lớp COMNET III, điều cực kỳ quan trọng là phải đề cập đến khả năng ứng dụng cái gọi là trừu tượng hóa tham số đối với chúng. Cách tiếp cận này cho phép bạn tạo các đối tượng mới - các thể hiện của một lớp với các thuộc tính khác nhau. Các giải pháp công nghệ quan trọng chẳng hạn như Gigabit Ethernet có thể được mô hình hóa rất đơn giản bằng cách thay đổi các tham số trừu tượng được đề cập - các thuộc tính của lớp đã chọn.

Hãy xem một ví dụ. Giả sử chúng ta mô phỏng mạng nội bộ, sử dụng phương pháp truy cập ngẫu nhiên với cảm biến sóng mang và phát hiện xung đột ở lớp con MAC (CSMA/CD, một lớp kết nối với nhiều quyền truy cập), tuy nhiên, tiêu chuẩn lớp liên kết do nhà sản xuất thiết bị mạng đề xuất hơi khác so với IEEE 802.3 “bản địa”. Tình trạng tương tự khi sử dụng một sản phẩm không triển khai cách tiếp cận hướng đối tượng, có thể gây ra một số điểm không chính xác. Nhà phát triển sẽ buộc phải sử dụng tiêu chuẩn do nhà sản xuất sản phẩm cung cấp, rất có thể là 802.3 cổ điển. Trong bộ lễ phục. Hình 4 hiển thị cửa sổ giao diện COMNET III, trong đó người dùng có thể chỉnh sửa các tham số của tiêu chuẩn này - số lần truyền lại trong trường hợp phát hiện xung đột, độ dài của tiêu đề khung, v.v. Nói cách khác, người dùng tự thực hiện việc tham số hóa của đối tượng.

Cơm. 4. Tham số hóa kết nối 10BaseT theo chuẩn IEEE 802.3

Vì vậy, chúng tôi quyết định sự tương ứng giữa tiêu chuẩn tham chiếu và tiêu chuẩn của nhà sản xuất. Các hành động tiếp theo của chúng tôi tập trung vào việc bổ sung thư viện các đối tượng lớp CSMA/CD bằng tiêu chuẩn mới do người dùng xác định. Để làm điều này, chỉ cần thêm các tham số mới. Chúng ta có thể làm tương tự với các nút phần cứng, nguồn lưu lượng, thông số Đám mây WAN, v.v.

Từ đó chúng ta có thể thấy rằng việc tham số hóa mang lại nhiều cơ hộiđể mở rộng thư viện cốt lõi của các đối tượng, cho phép nhà phát triển mô hình đưa ra quyết định linh hoạt hơn.

Mở rộng bộ cơ bản các lớp học có thể với sử dụng thêm cơ chế di truyền.

Chế độ Sao chép-Dán mô hình bên ngoài” (Sao chép-dán Intermodel)

Giả sử rằng chúng ta đang xây dựng một mô hình lớn có mô tả cấu trúc liên kết rất phức tạp. Ở đây chúng ta có thể thực hiện theo hai cách: kết hợp toàn bộ cấu trúc liên kết hệ thống trong một tệp hoặc xây dựng một số đoạn và sau đó kết hợp chúng. Tùy chọn thứ hai thuận tiện hơn cho nhà phát triển vì một số lý do. Điều này bao gồm việc dễ dàng gỡ lỗi từng đoạn riêng lẻ, khả năng hiển thị tốt và cuối cùng là độ tin cậy cao hơn.

Trong tương lai, toàn bộ vấn đề là chuyển các đối tượng từ mô hình này sang mô hình khác. Để giải quyết vấn đề này, thật thuận tiện khi sử dụng chế độ sao chép-dán COMNET III Intermodel (sao chép và dán mô hình bên ngoài), đảm bảo chuyển từ mô hình này sang mô hình khác của các đối tượng mới được tạo với tất cả các thuộc tính ngoại trừ các thuộc tính cục bộ của mô hình nguồn .

Hãy đưa ra một ví dụ. Giả sử chúng ta chuyển một đoạn mạng có tải từ mô hình này sang mô hình khác. Lưu lượng truy cập được mô tả bởi các đối tượng của lớp Message. Thuộc tính của các đối tượng cục bộ trong mô hình nguồn chính là đích đến của nó. Các thuộc tính còn lại sẽ được chuyển giao mà không có sự thay đổi từ các đối tượng kế thừa các lớp Node (Nút C&C, Nhóm máy tính, Bộ định tuyến, Switch), Liên kết, v.v., không bị ràng buộc với mô hình nguồn.

Thủ tục tham số hóa trong trường hợp này rất đơn giản. Đặc biệt, đối với một tin nhắn, bạn có thể chỉ định hướng của nó theo danh sách tên từ mô hình mới, được tự động gắn vào đối tượng.

Việc sử dụng phương pháp được mô tả sẽ mở ra nhiều khả năng xây dựng bất kỳ mô hình nào từ một tập hợp đối tượng linh hoạt, có thể mở rộng - các khối xây dựng, cho phép bạn giảm đáng kể chi phí lập mô hình.

Xây dựng mô-đun của các nút

Hãy xem xét thủ tục tạo một đối tượng của một lớp mới dựa trên đa kế thừa.

Giả sử một nhà phát triển được giao nhiệm vụ xây dựng mô hình chi tiết thiết bị phần cứng (ví dụ: bộ định tuyến, một số mô-đun giao diện được kết nối bằng bus giao diện). Mục đích của việc xây dựng mô hình là xác định độ trễ trên bus giao diện. TRONG mô tả tiêu chuẩn Bus COMNET III được mô tả bởi hai tham số: thông lượng và tần số. Rõ ràng là mô tả như vậy là không đủ đối với chúng tôi. Tuy nhiên, chúng ta có sẵn một đối tượng cho phép chúng ta mô tả lốp xe như thiết bị riêng biệt, - sự liên quan. Nói chung, đây không phải là một giải pháp hoàn toàn tiêu chuẩn, nhưng bằng cách thực hiện tham số hóa cần thiết của đối tượng lớp Link, chúng ta sẽ có được mô hình bus như một thiết bị đầy đủ chức năng thực hiện, chẳng hạn như chức năng phân xử. Hiển thị trong hình. 5, đối tượng MPRouter được mô hình hóa chính xác theo cách này. Bus giao diện ở đây hoạt động bằng thuật toán Token Bus.

Cơm. 5. Tham số hóa nguồn lưu lượng trong quá trình truyền

đoạn mô hình sang mô hình khác (Nguồn phiên)

Cần phải nói rằng nhà phát triển không nên lạm dụng các kỹ thuật như vậy, vì như đã đề cập, việc mô tả quá chính xác từng đối tượng trong một số tình huống có thể gây ra tác động ngược lại, điều này thể hiện ở việc làm giảm độ tin cậy của toàn bộ mô hình. Kỹ thuật này được áp dụng trong trường hợp cần mô tả chi tiết các đặc điểm của đối tượng.

Khả năng thiết lập trạng thái đối tượng

Bất kỳ đối tượng nào trong COMNET đều có thể ở nhiều trạng thái. Ví dụ, đối với các đối tượng của lớp Link và Node, các trạng thái có thể là up, down, failed (bật, tắt, lỗi). Bạn cũng có thể mô phỏng quá trình chuyển đổi giữa các trạng thái này và phân tích tác động của quá trình chuyển đổi trên IC mô phỏng (Hình 6).

Cơm. 6. Xác định các tham số trạng thái hiện tại của đối tượng (Node Properties)

Điều này mang lại cho nhà phát triển nhiều cơ hội để tạo ra các kịch bản động như “điều gì xảy ra nếu...?” và do đó làm tăng đáng kể tính linh hoạt của mô hình được tạo ra.

Vì vậy, chúng tôi đã xem xét các công cụ chính và các kỹ thuật phổ biến nhất để xây dựng mô hình trong COMNET III. Các tác giả có kế hoạch dành nhiều bài viết hơn nữa để mô hình hóa giải pháp khác nhau, được sử dụng rộng rãi trong các IC hiện đại.