Giới thiệu

Mục đích của chương này là bàn đến tất cả những khía cạnh chính của việc định nghĩa 1 domain-specific langugue (DSL) với Microsoft DSL Tools.

Tạo một DSL Solution trong Visual Studio

New Project ->Nếu có cài Visual Studio SDK, trong phần Extensibility -> Domain-Specific Language Designer.

Các template bao gồm:

• Minimal Languages: Chỉ đủ thể hiện một loại box và một loại line.
• Components Models: Các box với các port
• Classes Diagrams: Tương tự như lược đồ lớp UML (UML class diagram).
• Task Flows: Tương tự như lược đồ hoạt động UML (UML activity diagram).

Tiếp theo, đặt tên cho ngôn ngữ và namespace của source code cho designer (trình thiết kế) và generation tools (các công cụ phát sinh), ta cũng đặt tên cho phần mở rộng tên file mà sẽ được sử dụng để chứa các model (mô hình)

Gần như tất cả code từ các file khác từ 2 project được phát sinh từ việc định nghĩa DSL. Khi ta muốn thay đổi từ các template DSL sang DSL của ta, thì ta sẽ làm việc trên DSL definition.

Code trong 2 project bao gồm 3 phần chính:

1. Trình thiết kế (Designer) (hay ngôn ngữ mà ta đang định nghĩa) – Trình soạn thảo mà DSL user sẽ vẽ các model

2. Trình phát sinh mã (Code generators) – sẽ nhận lấy các model (mô hình) và text template

3. Trình xuất bản (Serializer) – được thiết kế để lưu các model và trong các file có phần mở rộng mà ta đặt tên lúc đầu và tải chúng lên một lần nữa. Trình Serializer được sử dụng trong trình designer và trong trình code generator, và có thể được sử dụng trong bất cứ ứng dụng tách biệt nào mà tác giả DSL chọn để viết

Tác giả DSL có thể thay đổi các chức năng này bằng cách viết thêm code (C#) ( thường thì ít thôi). Ví dụ, để thêm menu command hay validation constrainst (ràng buộc xác định hợp lệ) vào editor, hay thay đổi cách mà các models được serialize (xuất bản) xuống file( chương 6) hay cách mà text template được thông dịch và mã được phát sinh.

Có gì trong DSL solution?

Hai project được tạo lúc ban đầu bởi DSL creation wizard là Dsl và DslPackage.

Project Dsl cung cấp:

• Mốt serializer/deserializer (bộ xuất bản/hủy xuất bản) để đọc và ghi các thể hiện DSL của bạn xuống file.
• Những định nghĩa lớp (class) để xử lý DSL và các lược đồ của nó trong một ứng dụng.
• Một bộ xử lý chi dẫn(chỉ huy – directive processor) cho phép bạn có thể viết các text template mà sẽ xử lý DSL của bạn.
• Các thành phần thiết yếu của trình thiết kế mà sẽ biên tập (edit) DSL này trong Visual Studio.

Project DslPackage cung cấp code cho phép DSL được biên tập (edit) trong Visual Studio. (Có thể viết một ứng dụng stand-alone (đứng một mình – riêng rẽ) mà xử lý DSL chỉ sử dụng assembly được tạo bởi project Dsl ). Những file này thì tương tự nhau như trong các gói (pagkage) Visual Studio SDK khác.

• Tài liệu (document) xử lý code nhận biết được phần mở rộng file của DSL và mở trình thiết kế thích hợp.
• Các menu lệnh (menu command) kết hợp với trình thiết kế DSL.
• Các file item template từ đó các thể hiện mới của DSL có thể được tạo ra.

Trong mỗi project, có một thư mục có tên là GeneratedCode. Thư mục này chứa các file text template (phần mở rộng là .tt), mỗi file có một file được phát sinh (generated file) như là phần phụ trợ của nó. Trong solution explorer, click vào dấu [+] để thấy generated file. Hầu hết các file text template có nhiều tham chiếu đến các include file (các file này được chứa trong thư mục cài đặt DSL Tool có tên là “TextTemplate”)

Tất cả các generated file đều được xuất phát từ Dsl\DslDefinition.dsl. Bạn không nên thay đổi chúng (generated file), nhưng bạn có thể tùy biến generated code (mã được phát sinh) bằng cách thêm một phần các định nghĩa lớp trong các file riêng biệt. (chương 10 để biết các “tiện nghi” để tùy biến)

Chạy thử một DSL Solution

Để chạy được solution ta nhấn F5 (sẽ build solution và chạy trong chế độ debugging), việc tương đương với menu lệnh “Debugà Start Debgging”. Chúng ta sẽ xem DSL trong 1 trình thiết kế (trình biên tập đồ họa) chạy chung với Visual Studio. Khi nhấn F5 sẽ xuất hiện 1 thể hiện khác của Visual Studio, được khởi tạo để thể hiện 1 ví dụ của DSL.

Thể hiện mới của Visual Studio sẽ mở một project mẫu tên là Debugging, ta mở file mô hình là có tên là Sample.* (ví dụ Sample.iss)

• Cửa sổ lớn nhất là màn hình thiêt kế, phần trình bày chính của 1 thể hiện DSL. Ta phải biên tập lại việc định nghĩa DSL (trong thể hiện Visual Studio chính) để có thể thêm các định nghĩa của các thành phần. Khi toàn bộ DSL làm việc và được triển khai, người sử dụng DSL sẽ vẽ các lược đồ của họ ở đây.
• Bên trái là toolbox. Để thêm một phần tử mới, ta drag từ toolbox và kéo vào diagram (lược đồ); Để tạo 1 mối kết nối mới (connector) mới, ta click vào công cụ liên quan, click trên phần tử source, sau đó là phần tử đích trên lược đồ. Ta phải biên tập DSL definition để mà có thể thay đổi tên của công cụ và add thêm tool.
• Bên phải là model explorer. Nó hiện thị model dưới dạng cây. Nó hiện thị các phần tử (element) và các mối quan hệ nhúng của chúng. Trong một vài DSL, có nhiều phần tử không xuất hiện trong màn hình thiết kế chính nhưng sẽ luôn xuất hiện trong model explorer.
• Solution explorer hiện thị project Debugging chứa file mẫu. Ta có thể đổi tên project. Khi nó được triển khai, các bản sao của project này sẽ chạy cùng với mã của ứng dụng mà ta viết cho. Thêm các text template file mà sẽ đọc các thể hiện DSL của người sử dụng và tạo ra code.
• Bên dưới là properties window dùng để thay đổi các thuộc tính của các phần tử được chọn

Định nghĩa một DSL

Để định nghĩa DSL ta mở file DslDefinition.dsl trong project Dsl, sẽ mở ra trình thiết kế DSL. Trình thiết kế trong giống như trình thiết kế của Minimal language hay bất kỳ DSL cụ thể khác.

Cửa sổ chính gồm 2 swimlane hay cột: bên tay trái, là domain model là các domain class và relationship, bên tay phải là các shape và các connector mà thể hiện chúng lên màn hình. Ta có thể thêm mới các phần tử bằng cách sử dụng các công cụ trong toolbox. Trình thiết kế duy trì mốt sự trình bày dạng cây các phần tử và các mối quan hệ của chúng. Click phải lên domain class, sẽ tìm được lệnh sắp xếp lại cây.

Ta edit tên của domain class, shape, connector, diagram, role name (nhãn trên 2 cánh tay của mỗi relationship), và tên của relationship. Tất cả có thê edit trực tiếp trên diagram, ngoại trừ role name.

Để đổi tên của các công cụ sẽ xuất hiện trong toolbox. Những tên này không hiện thị trong main diagram của việc định nghĩa DSL – thay vào đó nhìn vào DSL explorer; sự định nghĩa các tool có thể được tìm thấy trong node Editor. Tên của chúng có thể được edit trong properties window cùng với các tooltip và tiêu đề mà sẽ hiện thị cho người sử dụng.

Phát sinh Code (mã) cho Designer (trình thiết kế)

Code (mã) cho trình thiết kế của DSL được phát sinh từ file định nghĩa DSL. Để thực hiện, vào solution explorer( trong Visual Studio chính) click vào nút “Transform All Templates”. Tất cả các file mã sẽ được phát sinh.

Thư mục “GeneratedCode” chứa các file text template với phần mở rộng là .tt. Mỗi file có có một file phụ trợ đó là kết quả được phát sinh. Click dấu [+] để xem. Các file được phát sinh bao gồm cả C# và resource file. Đừng thay đổi các file được phát sinh (generated file)

Nhấn F5 để qua experimental Visual Studio (Debugging project). Thêm file mới vào project Debugging (menu lệnh “Add new item”), thêm vào nó các phần tử và mối quan hệ.

Việc thêm vào trong DSL

Để thêm một phần tử *Element, nếu ta thấy nó nên được dẫn xuất từ lớp cơ sở trừu tượng chung. Thêm vào một vài domain class và 1 shape, định nghĩa lại shape map, và thiết đặt thuộc tính Inheritance của base class thành abstract (trong properties window), kết thúc việc định nghĩa DSL.

Để tạo một *Shape, sử dụng một hình học và set thuộc tính “geometry” thành : Circle, Retangle…. Ta cũng có thể thay đỏi các thuộc tính kích thước và màu sắc mặc định của các shape và connector khác. Một tool mới được yêu cầu cho shape mình mới tạo ra có thể được thêm vào trong node Editor trong cửa sổ DSL explorer. Nếu lưu tại thời điểm này sẽ bị lỗi vì chưa định nghĩa icon cho tool mới. Trong solution, vào thư mục Resource trong project Dsl và copy một trong những file hình ở đó và đổi tên  thành *ElementTool.bmp.

]]> http://bupbegiandon.wordpress.com/2008/06/06/ch%c6%b0%c6%a1ng-2-t%e1%ba%a1o-va-s%e1%bb%ad-d%e1%bb%a5ng-m%e1%bb%99t-dsl/feed/ 0 bupbegiandon http://bupbegiandon.wordpress.com/2008/06/06/ch%c6%b0%c6%a1ng-1-cont-cac-l%e1%bb%a3i-ich-c%e1%bb%a7a-domain-specific-development/ http://bupbegiandon.wordpress.com/2008/06/06/ch%c6%b0%c6%a1ng-1-cont-cac-l%e1%bb%a3i-ich-c%e1%bb%a7a-domain-specific-development/#comments Thu, 05 Jun 2008 21:28:07 +0000 bupbegiandon http://bupbegiandon.wordpress.com/?p=138 ]]>

• Một DSL cho khả năng làm việc dưới dạng “problem space”, với phạm vi ít hơn cho việc sinh ra các lỗi đến từ việc thể hiện nó trong một ngôn ngữ mục đích chung (general-purpose language).

• Làm việc dưới dạng “problem space”, làm cho model có thể sử dụng được với những người không quen với công nghệ cài đặt, bao gồm cả những người kinh doanh.

• Các model được thể hiện bằng cách sử dụng DSL có thể được validate (xác định tính hợp lệ) ở mức trừu tượng của problem space, có nghĩa là các lỗi trong sự hiểu biết hay sự thể hiện có thể được tìm kiếm một cách dễ dàng hơn trong quá trình phát triển.

• Các model có thể được sử dụng để giả lập một giải pháp một cách trực tiếp, cung cấp feedback một cách trực tiếp trên sự thích hợp của model.

• Các model cũng có thể được sử dụng để generate các model khác, và để cấu hình các hệ thống, network, và sản phẩm khác, có thể trong sự kết hợp với các công nghệ cho phép khác như các wizard.

• Một domain-specific language cung cấp một domain-specific API cho việc thao tác trên các model của nó, vì vậy cải tiến năng suất của nhà phát triển.

• Các artifact được phát sinh từ một DSL không cần phải là tất cả các artifact cài đặt công nghệ; một model thích hợp có thể được sử dụng để phát sinh các build script, purchase order, tài liệu, hóa đơn hay các material, kế hoạch, bộ khung của các hợp đồng hợp lệ.

• Một khi kiến thức kính doanh quan trọng được capture trong một model, nó trở nên dễ dàng một cách đáng kể để di trú một giải pháp từ một công nghệ này tới một công nghệ khác, hay giữa các phiên bản của cùng một công nghệ. Việc này thường được thực hiện một cách đơn giản bằng các thay đổi khiêm tốn tới các trình phát sinh (generator) hay trình thông dịch (interpreter).

Đây là một vài ví dụ “vertical” hơn mà ở đó domain-specific development có thể được áp dụng.

Software Defined Circuitry

Nhiều sản phẩm điện tử có circuitry được lập trình bằng cách dùng phần mềm. Ví dụ, các FPGA (Field Programable Gate Arrays) là các chip có thể lập trình được sử dụng trong các lĩnh vực như software defined radio, xử lý tính hiệu số, mô tả hình tượng y khoa và nhận dạng giọng nói. Lập trình các chip như thế một cách trực tiếp trong Hardware Description Language (HDL) (ngôn ngữ mô tả phần cứng) của chúng là một nhiệm vụ ở mức thấp và đòi hỏi phải rất cẩn thận. Hướng tiếp cận Domain-Specific Development có thể được sử dụng để nâng mức độ trừu tượng cho tới khi nó thể hiện một cách trực tiếp hơn domain được cài đặt; ví dụ, một DSL hướng tới software defined radio được thảo luận trong một bài báo bởi Bruce Track của PrismTech tại www.mil-embedded.com/articles/authors/track/.

Embedded Systems

Nhiều hệ thống nhúng thời gian thực có thể được khái niệm hóa như là một tập hợp các communicating finite state machine (cỗ máy trạng thái có giới hạn liên lạc). Tách biệt sự thiết kế của các hệ thống này vào các explicit state machine, cộng với một platform tổng quát cho các executing state machine có thể đơn giản hóa rất nhiều việc nghĩ về các hệ thống như thế. Trong trường hợp này, DSL là một ngôn ngữ cho việc thể hiện các state machine bao gồm các state và các transition giữa chúng¸trong khi execution platform (platform thực thi) thì hầu như được build sử dụng custom code.

Device Interfaces

Nhiều thiết bị hiện đại, như điện thoại di động, thiết bị HiFi, và v.v…, có các giao diện người dung phức tạp. Các giao diện này được tổ chức một cách điển hình thông qua các luật mà làm cho giao diện có thể tiên đoán được, như một luật mà nhấn một nút cancel luôn luôn dẫn bạn về một trạng thái đã biết, hay input text luôn luôn theo sau cùng một tập các rule dự đoán trước. Một DSL có thể được tạo ra cho việc thiết kế các hệ thống như thế, mà diện mạo đồ họa của ngôn ngữ tương ứng một cách chính xác với diện mạo của giao diện thực sự được thiết kế, và các luật tương tác tác của giao diện được capture trong cấu trúc của ngôn ngữ. Các ví dụ hay của hướng tiếp cận này có thể tìm thấy tại Domain-Specific Modeling Forum website tại www.dsmforum.org.

Software Development Process Customization

Ví dụ được sử dụng xuyên suốt cuốn sách này để minh họa DSL Tools trình bày làm thế nào sử dụng các DSL để định nghĩa các khía cạnh của tiến trình phát triển phần mềm, như việc xử lý các bug và issue, và làm thế nào sử dụng model để cấu hình các công cụ để thực thi tiến trình.

Tất cả những ví dụ này và nhiều ví dụ khác chia sẻ cùng một hướng tiếp cận:

(1) chỉ ra các khía cạnh của vấn đề mà cố định cho tất cả các sự xuất hiện và capture những khía cạnh đó trong một framework hay platform chung.

(2) chỉ ra các khía cạnh khác mà biến đổi giữa các sự xuất hiện và việc thiết kế một Domain-Specific Language mà các biểu thức hay model của nó sẽ chỉ một giải pháp cho vấn đề.

Trước tiên hãy xem một vài ví dụ mà DSL Tools đã được áp dụng trong thực tế.

Ví dụ đầu tiên đến từ Independent Software Vendor (ISV) có tên Himalia. Himalia đã tạo ra một tập các DSL cho việc cài đặt các giao diện người dùng phức tạp mà không phải coding chút nào. Himalia Navigation Model (Figure 1-3) định nghĩa sự di chuyển thông qua giao diện người dùng.

Use Case Model (Figure 1-4): Các Use Case, xem như các luồng điều khiển lớn bao gồm các activity và transition, được định nghĩa một cách tường minh trong một state machine view để chỉ ra sự phức tạp của chúng. Các Use Case state và transition được liên kết tới các Navigation Model element và action, theo thứ tự định sẵn.

User Profile Model (Figure 1-5) định nghĩa các user state (trạng thái người dùng) mà ảnh hưởng tới cách hành xử của user interface (giao diện người dùng).

Hệ thống Himalia hoàn chỉnh tích hợp những model này với những model khác vào trong Visual Studio 2005 để cài đặt các giao diện người dùng hoàn chỉnh dựa trên công nghệ Microsoft, bao gồm Windows Presentation Foundation (WPF).

Ví dụ thứ 2 là một Systems Intergrator (SI) có tên là Ordina có trụ sở ở Hà Lan. Ordian đã xây dựng một nhà máy phần mềm hướng mô hình hoàn hảo với Microsoft Development Center của nó, có tên là SMART-Microsoft Softwar Factory. Factory này sử dụng 4 DSL được kết nối với nhau. Để cho phép các DSL này cộng tác với nhau, Ordina đã tạo ra một lược đồ tham chiếu chéo (cross-referencing scheme) cho phép các element trong một DSL tham chiếu tới các element trong DSL khác.

Web Scenario DSL được sử dụng để mô hình các trang web và hành động của người dùng, và phát sinh ra các trang web ASP.NET (xem Figure 1-6)

Data Constract DSL được sử dụng để định nghĩa các đối tượng dữ liệu mà được làm trong suốt giữa các lớp khác nhau trong kiến trúc. Một ví dụ được thể hiện trong Figure 1-7, minh họa nhiều loại đối tượng dữ liệu khác nhau.

DSL thứ 3 trong Ordina factory là Service Model được show trong Figure 1-8, được sử dụng để phát sinh các service interface (giao diện dịch vụ) và skeleton (bộ khung) của các tiến trình thương mại mà cài đặt các dịch vụ.

DSL cuối cùng trong Ordina factory là Business Class Model được sử dụng để phát sinh code cho các tầng Bussiness Class và Data. Model này được show trong Figure 1-9.

Hai ví dụ này từ Himalia và Ordina là cho các DSL “horizontal” (ngang) mà ở đó các khách hàng được dự kiến cho phần mềm kết quả không phụ thuộc vào bất kì công nghiệp cụ thể nào.

Giới thiệu:

DSL Tools và một phần của Visual Studio SDK, có thể download từ http://www.microsoft.com/downloads/details.aspx?familyid=51A5C65B-C020-4E08-8AC0-3EB9C06996F4&displaylang=en nếu bạn dùng Visual Studio 2005 và http://www.microsoft.com/downloads/details.aspx?familyid=30402623-93CA-479A-867C-04DC45164F5B&displaylang=en nếu bạn dùng Visual Studio 2008.

DSL Tools tích hợp trong Microsoft Visual Studio 2005 và Microsoft Visual Studio 2008 để hỗ trợ một hướng phát triển phần mềm có tên là Domain-Specifc Development.

Domain-Specific Development dựa trên sự quan sát rằng: nhiều vấn đề phát triển phần mềm có thể được giải quyêt dễ dàng bằng cách thiết kế một ngôn ngữ mục đích đặc biệt (special-purpose language).

Ví dụ, hãy nghĩ đến việc tìm kiếm tất cả sự xuất hiện của một mẫu (pattern) trong một file, và làm một cái gì đó với mỗi sự xuất hiện mà bạn tìm thấy?

· Cách 1: Sử dụng lớp .NET System.Text.RegularExpression.Regex, biểu thức chính qui (regular expression) (?<user>[^@]+)?<host>.+) được áp dụng cho một chuỗi các kí tự sẽ tìm các địa chỉ email trong nó, và cho mỗi địa chỉ tìm thấy, gán chuỗi con ngay trước dấu”@” cho biến user, và chuỗi con ngay sau dấu “@” cho biến host.

· Cách 2: Nếu không có regular expresion, một developer sẽ phải viết một chương trình đặc biệt để nhận ra các pattern (mẫu) và gán các giá trị đúng cho các biến thích hợp. Đây là một nhiệm vụ khá nặng và sẽ gặp nhiều lỗi.

Domain-Specific Development áp dụng cùng hướng tiếp cận trên cho nhiều vấn đề, đặc biệt là những vấn đề bao gồm việc quản lý sự phức tạp của các hệ thống phân tán hiện đại ( ví dụ như những thứ có thể được phát triển trên .NET platform ). Thay vì chỉ sử dụng các ngôn ngữ lập trình mục đích chung (general-purpose programming language) để giải quyết những vấn đề này mỗi cái tại một thời điểm, người sử dụng Domain-Specific Development tạo và cài đặt các ngôn ngữ đặc biệt, mỗi ngôn ngữ giải quyết một cách hiệu quả toàn bộ một lớp các vấn đề tương tự nhau.

Các Domain-Specific Languaguage có thể là textual (text) hay graphical (đồ họa). Các ngôn ngữ đồ họa có các thuận lợi quan trọng hơn các ngôn ngữ text trên nhiều vấn đề, bởi vì chúng cho phép giải pháp được trực quan hóa một cách rất trực tiếp trên các diagram. DSL Tools làm cho việc cài đặt DSL đồ họa trở nên dễ dàng, và cho phép Domain-Specific Development được áp dụng cho một phạm vi rộng và cho nhiều vấn đề.

Domain-Specific Development

Domain-Specific Development là một cách giải quyết các vấn đề mà bạn có thể áp dụng khi một vấn đề cụ thể xuất hiện lặp đi lặp lại.

Mỗi sự xuất hiện của vấn đề có nhiều khía cạnh giống nhau, và mỗi phần có thể được giải quyết một lần và cho tất cả (xem Figure 1-1).

Các khía cạnh khác nhau của một vấn đề được thể hiện bởi một ngôn ngữ đặc biệt. Mỗi sự xuất hiện cụ thể đó được giải quyết bằng cách tạo ra một model hay biểu thức trong ngôn ngữ đặc biệt và gắn model này vào trong phần cố định của solution.

Phần cố định của solution được viết sử dụng các thiết kế, coding và testing truyền thống, phụ thuộc vào kích thước và hình dạng của vấn đề, phần cố định này của solution có thể được gọi là một framework, một platform, một trình thông dịch, hay một Aplication Programming Interface (API). Phần cố định capture các mẫu kiến trúc mà hình thành nên domain và đưa ra các điểm mở rộng cho phép nó được sử dụng trong nhiều solution.

What makes the approach applicable is the fact that you create the variable part of the solution by using a special-purpose language—a DSL.

DSL có thể là văn bản hay đồ họa. Vì công nghệ cho domain-specific development đã hoàn thiện, chúng ta mong đợi thấy các công cụ hổ trợ việc phát triển và tích hợp của các DSL text và đồ họa. Con người có một dãy các cảm giác về loại ngôn ngữ nào mà họ thích hơn. Ví dụ, nhiều người thích các ngôn ngữ text cho input, bởi vì họ có thể gõ nhanh, nhưng các ngôn ngữ đồ họa cho ouput, bởi vì có thể dàng xem “bức tranh lớn” (big picture) trong một diagram. Các biểu thức text thì dễ tính toán sự khác biệt và dễ kết hợp hơn, trong khi các biểu thức đồ họa thì dễ thấy các mối quan hệ hơn.

Để tạo ra một giải pháp hoạt động cho vấn đề được chỉ ra, phần cố định của giải pháp phải được tích hợp với phần thay đổi được thể hiện bởi model. Có 2 hướng tiếp cận phổ biến cho việc tích hợp này.

· Thứ nhất, là hướng tiếp cận trình diễn, mà phần cố định chứa một trình thông dịch cho DSL được sử dụng để thể hiện phần thay đổi. Một hướng tiếp cận như thế có thể linh hoạt, nhưng nó có thể có các bất lợi về việc thể hiện kém và khó khăn trong việc debug.

· Thứ hai, một biểu thức đặc biệt hay diagram (biểu đồ) có thể được convert một cách đầy đủ thành code và có thể được biên dịch cùng với phần còn lại của giải pháp – đó là hướng tiếp cận phát sinh code. Đây là một thủ tục biến đổi phức tạp hơn, nhưng nó cung cấp các thuận lợi trong khả năng mở rộng, biểu diễn, và debug.

Các DSL đồ họa không chỉ là các diagram. Nếu bạn chỉ muốn tạo ra các diagram, bạn có thể sử dụng các chương trình vẽ diagram nổi tiếng như Microsoft Visio để đạt được kết quả lớp thứ nhất (first-class result). Thay vào đó, bạn đang thực sự tạo ra các model thể hiện một cách khái niệm hệ thống mà bạn đang xây dựng, cùng với các sự thể hiện bằng biểu đồ nội dung của chúng. Một model được thể hiện đồng thời bởi một hay nhiều diagram, với mỗi diagram thể hiện một khía cạnh đặc biệt của model, xem Figure 1-2 để thấy rõ hơn