Company logos and product graphics
These pictures are intended for press use only. The pictures must not be altered in any way. To download, right-click the link and choose Save As...
MetaCase company logos
- metacase_shine_huge.tif.zip 68.7 x 16.9 cm, 300 dpi, CMYK (8120 x 2000 pixels, for print)
- metacase_shine_large.tif 9.0 x 2.2 cm, 300 dpi, CMYK (1068 x 260 pixels, for print)
- metacase_shine_small.tif 5.4 x 1.3 cm, 300 dpi, CMYK (641 x 156 pixels, for print)
- metacase_shine_large.png 1068 x 260 pixels, RGB (for WWW and screen)
- metacase_shine_small.png 641 x 156 pixels, RGB (for WWW and screen)
- metacase_shine_tiny.png 147 x 36 pixels, RGB (for WWW and screen)
MetaEdit+ product logo
- metaedit.png 464 x 100 pixels, RGB (for WWW and screen)
MetaEdit+ screenshots
- Main window: For reusing and managing metamodel elements
- MetaEdit+ Embedded: Running customized and embedded MetaEdit+ inside other product
Metamodeling tools (MetaEdit+ Workbench)
- Object tool: For defining modeling concepts and their properties
- Symbol editor: For designing or importing modeling symbols
- Graph types definer: For combining concepts into a modeling language
- Constraints definer: For selecting modeling rules and constraints
- Generator Editor: For specifying the mapping from models to code
- Generator Debugger: For testing and debugging the generator with links back to models
Modeling tools (MetaEdit+ Modeler)
- Diagram editor: For modeling with diagrams: example 1, example 2, example 3
- Matrix editor: For viewing and editing design information in a matrix format
- Table editor: For viewing and editing design information in a table format
- Browsers for viewing and navigating in model elements: Graph browser, Object browser, Type browser
Architecture graphic
- Modeling in domain-terms
versus modeling in code terms
Application development is about bridging the gap between an idea (in domain terminology) and the finished product. Traditionally, we bridge this gap by mapping the idea to different abstraction layers like code (assembler, 3GL) or more recently, by first making a mapping to a code-based modeling language (e.g. UML). We thus solve the same problem multiple times. DSM takes an approach where we model the idea in domain terms and generate the final code directly from this high abstraction layer, without mapping.