A Deep Dive into MagicGrid
Key Documentation
You can download the latest version of the MagicGrid BoK from :https://discover.3ds.com/magicgrid-book-of-knowledge. This is a no cost immediate download. You must understand which version you are working off of because they have differences.
MagicGrid Package Structure
Both MagicGrid versions have similar package structures which breakup the system into 3 domains to be modeled: the problem domain, the solution domain, and the implementation domain. They are described below.
Problem Domain
The problem domain is the initial problem or need that is identified and needs to be solved. This is the space in which the problem exists, and it’s the analyst’s job to identify and understand the problem in order to develop a solution. This includes the brainstorming phases at the beginning of the product lifecycle. The use case diagrams will live within here. This is scoping the problem, understanding what the customers want, refining the requirements from user needs, and creating a conceptual very abstract model of the system-of-interest. The conceptual model will likely point the modeler as to what the subsystems of the system will be and what the main interfaces into and out of the system will be. These interfaces will be abstract (ie. receive power, sense environmental data, pass data to host, provide logical commands to subsystems, etc.)
Solution Domain
The solution domain is the space in which the proposed solution exists. This is the area in which the analyst will develop the solution to the problem or need. This is where the engineer will create the framework or design of the solution. This is the logical aspect of the system development where refinement of the conceptual aspects created within the problem domain happens. The logical domain will be separate from the conceptual domain but related. The logical domain will be a lower level of abstraction (aka. more refined or specific) than the conceptual structure. The solution domain still keeps some of the trade space because it does not prescribe the specific part number or wiring schematic while the implementation domain there is no hardware trade space anymore, every pinout has been decided.
Implementation Domain
The implementation domain is the space in which the proposed solution is implemented. This is where the solution is put into practice and tested to see if it is successful (ie. cutting metal). This is the physical model. It will be more refined than the logical domain as pinouts and actual signals over the pins have been determined. The MagicGrid Boks primarily focus on explaining the methodology for creating the problem and solution domains and do not go into detail about how to build out the implementation domain. This allows for much greater flexibility for the engineer to model the implementation domain.
MagicGrid V1 vs MagicGrid V2 Differences
It is important to understand the key differences between MagicGrid Book of Knowledge A Practical Guide to Systems Modeling using MagicGrid from No Magic published in 2018 and MagicGrid Book of Knowledge A Practical Guide to Systems Modeling using MagicGrid from Dassault Systèmes 2nd edition published in 2021.
The key structural differences between the two editions of the MagicGrid Book of Knowledge are as follows:
Number of columns and order of columns within the MagicGrid. V2 has 5 columns while the original only has 4. V2 swaps the behavior and structural columns.
Slightly different package structure and numbering. It's very similar but different enough that it can confuse users. Be careful using premade Cameo templates thinking all MagicGrids are the same.
Comparison of Grid From MagicGrid V1 to V2
Notice the columns have changed order and V2 has added a 5th column. Also naming conventions have slightly changed within cells.
Grid From MagicGrid V1
Grid From MagicGrid V2
Comparison of Package Structure From MagicGrid V1 to V2
Notice: the package naming convention under "1 Black Box" does not match between V1 and V2. V1 has "3 System Context" while V2 has "2 System Context". This is because of the swapped structural and behavioral piller changes within the grids from V1 to V2.
While this change seems minor, you can put yourself in a rough situation if you are using the wrong MagicGrid template within Cameo and your package structure naming conventions doesn't match with other's models.
Problem Domain Black Box From MagicGrid V1
Problem Domain Black Box From MagicGrid V2
Notice package structure numbering and names have changed between V1 and V2.
Problem Domain White Box From MagicGrid V1
Problem Domain White Box From MagicGrid V2
Notice "3 System Structure" from V1 = "2 System Structure" from V2.
Solution Domain From MagicGrid V1
Solution Domain From MagicGrid V2
Takeaway: They are different so know which one you're using.