Modeler is supplied with the following example models. These models are supplied in the Examples database, which is created, by default, during a Modeler Server or Standalone installation.
Each of the example models has been created to illustrate particular aspects of Modeler, although all the models can be used to explore the features of Modeler.
• Active Deferred Ball Game Example—This model demonstrates how making a Class active or applying the «C++ Deferred» stereotype to a Class affects the generation of C++ code.
• BallCpp—This model is a very simple model that has been included mainly to illustrate the use of Modeler Automatic Code Synchronizer (ACS). It will generate C++ code files that can quickly be built (using Visual C++) into a simple executable application. You can make use of ACS to illustrate how you can work seamlessly in both Modeler and an IDE such as Microsoft Visual C++ at the same time. For more information about ACS, see
Overview of ACS.
• Cabin—This model demonstrates how variability parameters can be used to set property values of artifacts in product models. It also demonstrates parameter propagation, derivation and validation.
• C# Another Block (Tetris) Example—This model demonstrates how a C# application can be modeled in Modeler. Through ACS and the C# Generator Code Generator DLL, you can generate a C# Tetris game from the model.
• Electric Car Charger (Java)—This model demonstrates how to use the ThingWorx Profile in a model. The ReadMe text diagram in the model provides information for generating the Java code, and building and running the system.
• Filling Station—This model is quite large and complex. The Filling Station model is a good vehicle for exploring the facilities and potential of the Configuration Management features of Modeler. It should be borne in mind that the Filling Station is essentially an analysis and design model; it has not been implemented through to code generation. For example, its state diagram actions are written in a form to relate easily to other design elements rather than to produce compilable code.
• Heart Monitor C—This model has been designed to illustrate code generation (to C) from both state machine and class information. This model has been designed to operate using state machine simulation linked to a Microsoft VisualBasic application that represents a heart monitor.
• Heart Monitor Java—This model has been designed to illustrate code generation (to Java) from both state machine and class information.
• HSUV—This model is a SysML, rather than UML, model. It is an almost complete implementation of the HSUV example provided in Annex B of the SysML Final Adopted Specification (May 2006). The model is largely self-documenting; it contains a couple of text files, including a ReadMe that describe the model content. This model is also used as an illustrative model in the SysML Tutorial, which can be downloaded from the PTC website.
• Search and Rescue—This model is a UPDM model. It is an almost complete implementation of the Search and Rescue example provided in Annex C of the 'Unified Profile for the Department of Defense Architecture Framework (DoDAF) and the Ministry of Defence Architecture Framework (MODAF)' (Beta 2, June 2009). Some of the diagrams in the model have been altered from that in Annex C to correct them and make the model more consistent.
• Speed Controller—This model models a system that controls the speed of a motor. Through SySim you can generate and run the speed controller system.
• Template - Component-based Products, Template - Incremental Process and Template - Small Project—These three models can be used as model structuring templates for different project types. Each model contains a structured set of packages, organized to hold the various model items that are likely to be produced for each project type. Each model contains a text diagram that describes the project type and the package structure. One or more class diagrams are also incorporated, specifying package dependencies. These models are there to be used and adapted as required – it is unlikely that one of these will be an exact fit to any specific project. To use one of these models, clone it to the appropriate repository.
• Traffic Lights—This model is a very simple model that illustrates the use of the automation interface in linking state machine code simulation with a Microsoft VisualBasic application. As with the Waste System no life cycle dimension is present. The Operations in this model contain C++ code.
• Traffic Lights - SySim—This model models a traffic light system that can be generated and run through SySim. See also, the Speed Controller model.
• VB Another Block (Tetris) Example—This model demonstrates how a Visual Basic application can be modeled in Modeler. Through ACS and the VB Generator Code Generator DLL, you can generate a Visual Basic Tetris game from the model.
• Waste System—This model has been designed to illustrate code generation (to C++) from both state machine and class information. It is a smaller and simpler model and consequently contains less in the way of Help information. It is not organized around a life cycle and therefore will produce only a limited subset of generated documents. The model can be viewed as a realistic prototype for exploring operator and diagnostic interaction. This model has been designed to operate using state machine simulation linked to a Microsoft VisualBasic application that represents a system visualization incorporating a diagnostic front panel. The model is supplied with both source and executable files.
Introduction to the Supplied State Machine Simulations
Modeler supports state machine simulation. So that you can see state machine simulations working, the following models are supplied with the files required to simulate their state machines:
• Traffic Lights model—uses C++ code
• Waste System model—uses C++ code
• Heart Monitor C model—uses C code
The user interfaces of the Waste System, Heart Monitor C, and Traffic Lights models are simulated using Microsoft Visual Basic applications.