A class is an abstraction of a group of system elements that have the same set of features from the modeling point of view. Taking advantage of object orientation, SansGUI uses classes for categorizing and organizing system elements. SansGUI provides simulation developers with a mechanism to define the classes necessary to a simulator. The definitions of the classes become a contract between SansGUI and the simulator, through which SansGUI can gather proper model configuration and input data from the user and then pass them to the simulator for processing.
A class schema is a data structure that stores the properties of the class itself. It also contains a set of class attributes, which are used to define the properties of the objects derived from this class. The derived objects with specific values for the corresponding class attributes are instances of the class.
A simulation developer creates and defines classes that are related with the simulator in the modeling domain. The specifications of a class is captured in its class schema, which contains the following information: 1) Class Properties, 2) Sharing Options, and 3) Class Attributes.
The properties of a class consist of the following elements:
Identity: The identity information is important for SansGUI to manage compatible classes for the simulator, especially when there are shared classes among simulators, workgroups, or companies. The class identity contains the name of the class, a globally unique identifier (which is automatically generated by SansGUI), the current version number of the class, the class creator's company and work group, the simulator program in which the class is created, and the compatible options of the class in the simulator.
Status: The class status contains information for table orientation (row or column), internal data storage for programming (row-major order as in C or column-major order as in Fortran), and whether the class can be used to derive objects from or not.
Documentation Location: The simulation developer can specify a document file name for each class to utilize SansGUI's on-line help facility. A memo field is also provided for a short description of the class.
DLL function Entry Points: For in-process simulators, the behavior of component and reference classes are implemented as DLL functions called by the SansGUI environment. The specifications are stored on a per-class basis. The full set of the DLL Function Entry Points can be found in the SansGUI Reference Manual.
Port Definitions: For each component class, ports may be explicitly defined with port attributes. They may also be implicitly defined with a set of connection rules. By default, ports are defined implicitly with port numbers automatically incremented from 1. In other words, if you do not define ports, they will be numbered 1, 2, 3, and so on as the user creates links to the part derived from this component class. Details of port definitions can be found in the Defining Component Classes section in Chapter 2.
Connectivity Information: Connectivity information basically specifies what can or cannot be connected to the parts derived from this class. The link directions are also taken into account. By default, no connectivity restriction is defined, i.e., any part derived from this component class can be connected with any parts derived from any component class. By defining connectivity rules, the simulation developer can limit the connectivity of certain classes in the system. More details can be found in Defining Component Classes section in Chapter 2.
When a class is planned to be reused among multiple simulators, they can be defined as shared. SansGUI supports four levels of class sharing: 1) multiple options within a simulator, 2) among simulators within a workgroup, 3) among workgroups within a company, or 4) among all companies globally. With this feature, commonly used classes can be shared to avoid duplicates. The DLL functions for the shared classes can be integrated into the same simulator DLL before distribution. It can also be implemented as user overriding functions in a separate DLL so that when the classes are imported to different Project Models, the location of the class functions can be specified explicitly. An integrated DLL has higher performance than a separate DLL because of the overhead of loading the separate DLL prior to every function call.
The primary portion of a class schema contains the attributes of the class; therefore, the primary development in a Schema Definition is to specify the attributes of the classes involved in the simulator. These attributes are used to describe the properties of deriving objects. A class attribute contains the following information:
Name: describes the attribute, to be shown in the data entry form.
Code: serves as the key for identifying the attribute in schema maintenance and is used as the variable name for code generation.
Scope: specifies the attribute to be one of the input, in/out, output, or hidden scope or a port attribute (a special in/out attribute associated with explicit port definitions).
Logistic Properties: indicates if the value is not required, if a line break is to be appended when output to a textual model file, if symbolic parameter is allowed, or if it allows part overriding values.
Type: specifies the GUI Control and Object Data types of the attribute. See the chapter on SansGUI Data Types in the SansGUI Reference Manual for more details.
Internal Unit: specifies the unit of measure when numeric data values are sent to the simulator. It does not matter what unit is chosen by the user in the presentation layer. The simulator will always receive the data converted to this specified unit.
Validation Rules: specifies the default value, upper and lower bound, data format, qualitative interpretations of the values, etc. of the attribute. Details of the validation rules can be found in the Adding Attributes to Classes section in the next chapter.
Intrinsic classes may or may not have class attributes. A class without any attribute is called a generic class. Simulation developers create domain specific classes by deriving them from the intrinsic classes and extending the set of class attributes to include those important to the simulator. SansGUI provides simulation developers with a mechanism for creating and maintaining class attributes. A schema version evolution function is included in the SansGUI Run-Time Environment for simulation users to synchronize all their Object Libraries and Project Models with any versions of the simulator for backward and forward compatibility. See the next section on Class Schema Version Control for more details.
SansGUI supports multiple level classes in tree-like structures. A class may be used to derive multiple child classes and every child class can have exactly one parent class. In object-oriented terms, it is single inheritance. We call the parent class a super class and the child class a subclass. There are multiple root classes in the SansGUI environment. All the root classes are predefined and supplied with SansGUI. All the simulation developer defined classes are derived, directly or indirectly, from these root classes.
The operation of creating a subclass from an existing class is called subclassing. A subclass inherits all attributes from its parent class and all the ancestors of this parent class. In other words, the set of the attributes in the subclass is a superset of that of any ancestors. With this nature, the class functions in a superclass that act upon the class attributes can be called from a function in the subclass. The path that follows the inheritance relations from a root intrinsic class to a descendent class is the class path of the descendent.
When a class cannot be used to create subclasses, we call it a terminal class. When a class allows instantiation of objects, the class is a concrete class; otherwise, it is an abstract class. Whether a class is concrete or abstract is determined by the simulation developer.
The SansGUI intrinsic classes, or classes that are predefined and supplied with SansGUI, are organized into three categories: Simulator, Component, and Reference Classes.
Simulator Classes: contain simulation control classes and a unit class. The simulation control classes determine the program control types of simulation execution. A simulator must have at least one simulation control class. The unit class is used to define measuring units involved in the simulator.
Component Classes: represent classes of physical elements in a model. They can be used to create parts, links and assemblies.
Reference Classes: represent classes of reference data in a model. They are referred to by other objects, parts or links.
Creating subclasses from the SansGUI intrinsic classes for simulation control, system components, and data references is a primary task in the simulator development cycle. More on the SansGUI Intrinsic Classes can be found in the SansGUI Reference Manual.
|
|
SansGUI Modeling and Simulation Environment Version 1.2
Copyright © 2000-2003 ProtoDesign, Inc. All rights reserved.