Glossary

This chapter contains the glossary to the complete documentation of all iss-base components.

Ace (Lace)Ace

active dialog (iss-build)

active element (iss-build)

active template (iss-build)

ancestor (Eiffel)

application event (TUNE)

application model (TUNE)


assertion (Eiffel)

Attributes page (iss-build)

binary file (TUNE)

BON (iss-case)

browsing (iss-bench)

builder (iss-build)

Buildtime mode (iss-build)

Class hole (iss-bench)

class interface (iss-bench)

Class Tool (iss-bench)

click (iss-base)

client-server (iss-net)

cluster (Lace)

command class (TUNE)

command creator (TUNE)

command ID (TUNE)

command label (TUNE)

command object (TUNE)

command paradigm (TUNE)

common address (iss-net)

Component Gallery (iss-build)

composite (TUNE)

configuration file (iss-build)

construction event (iss-build)

control-click (iss-base)

control-right-click (iss-base)

creator class (TUNE)

Current button (iss-bench)

data source (iss-store)

deferred (Eiffel)

DESC (iss-bench)

descendant (Eiffel)

dispatch command (TUNE)

drag-and-drop (iss-bench)

effecting (Eiffel)

Eiffel class (Eiffel)

event ID (TUNE)

event-command binding (TUNE)

Events page (iss-build)

exception (Eiffel)

exception handling (Eiffel)

Execution Object Tool (iss-bench)

Feature Tool (iss-bench)

File Selector (iss-base)

final code (iss-bench)

finalizing (iss-bench)

Flat format (iss-bench)

Flat-short format (iss-bench)

formatting character (iss-vision)

freezing (iss-bench)

gallery file (iss-build)

Gallery Page (iss-build)

garbage collection (iss-base)

Gotcha panel (iss-bench)

GUI

hole (iss-bench)

inheritance (Eiffel)

input format (iss-base)

input mask (iss-vision)

Inspector (iss-build)

invariant (Eiffel)

iss-base

iss-base message system

iss-baselib

iss-bench

iss-build

iss-case

iss-net

iss-report

iss-store

iss-tune

iss-uml

iss-vision

iss-webgate

iss-yacc

Lace

Lace options


melting (iss-bench)

Melting Ice Technology® (iss-bench)

message handler (iss-base)

Navigator (iss-build)

network (iss-net)

object creator (TUNE)

object-oriented (iss-base)

object-oriented environment (iss-base)

ODBC (iss-net)

ODBC driver (iss-net)

output formatting (iss-vision)

parent attribute (TUNE)

parent control (TUNE)

Parent page (iss-build)

PC-Warehouse

pebble (iss-bench)

polling (iss-net)

polymorphism (Eiffel)

postcondition (Eiffel)

precompilation (iss-bench)

predefined level (iss-net)

precondition (Eiffel)

project directory (iss-bench)

project file (iss-build)

Project History (iss-build)

Project Tool (iss-bench)

redefinition (Eiffel)

    • If the type of a feature, result, or argument is changed, the new type must be a descendent of the old.
    • For routines the number of arguments cannot be modified and there cannot be a switch between command and query.

renaming (Eiffel)

    A mechanism of inheritance enabling name changes for features that have been inherited. The very power of inheritance demands adequate means to keep it under control. Multiple inheritance, in particular, raises the question of name conflicts between features inherited from different parents. Such name conflicts can be resolved through renaming.
    Renaming also serves to provide more appropriate feature names in descendants leading to object coherent terminology.

rescue and retry (Eiffel)

    Eiffel constructs for handling exceptions. A rescue clause can be specified for each routine and contains instructions that are to be performed when an exception occurs during routine execution.

    Typically, a rescue clause will include instructions aimed at stabilizing the state of the current object. It can also contain a retry instruction at the end of the clause which causes the routine to restart its execution from the beginning, attempting again to fulfill its contract, usually through another strategy. This assumes that the instructions of the rescue clause, before the retry, have attempted to correct the cause of the exception. If the rescue clause does not contain a retry instruction, the routine fails.

resource call (TUNE)

    A call to a resource manager to determine the attribute of a TUNE object dynamically. In TUNE an attribute of a TUNE object can be configured by assigning to the attribute either a constant value, or a resource call that is evaluated by the specified resource manager when the template is instantiated.

resource file (TUNE)

    File containing information needed to configure an application dynamically at run time. One resource entry consists of a pair (resource key - value) to be read by the application.

resource manager (TUNE)

    An object of a type conforming to TUNE_RESOURCE_MANAGER providing an implementation for obtaining values associated to keys.

right-click (iss-base)

    A click (and immediately release) of the rightmost mouse button.

root class (Lace)

    A class designated in a system's Ace file as root class with a creation procedure that is designated as the root creation procedure.
    A valid system is executable. To execute it means to create an instance of the root class and to apply the creation procedure to that instance. The creation procedure, which plays a role similar to that of a test driver in more traditional approaches, will normally create other objects and call further features.

Run button (iss-bench)

    Starts the execution of an application once it has been compiled.
    Basic click on the Run button starts or resumes execution; however, you can right-click on that same button to specify the arguments for the next run.

    You can interrupt execution at any time by clicking on the End Run button, and terminate it by Control-clicking that button. When execution terminates, either normally or through Control-End Run, the Project Tool will display the message System terminated.

Runtime mode (iss-build)

    One of two modes in which a dialog can be opened in iss-build. To examine your dialog as it would appear in a real application, toggle to Runtime mode with the rightmost toolbar button of the iss-build bench.

Save button (iss-bench)

    Saves the current state of the target object to the associated file.

    Indicates the contents of the tool have not been modified since the last Save or Save As command.

Search button (iss-bench)

    Opens a Search panel for searching the text contained in a tool window for occurrences of a certain string.
    Type the string that you want to find in the text of the tool's target into the text field at the top. Then press the Enter (or Return) key or click on the Next button. If there is no occurrence of the search string in the target's text, this operation will have no effect; otherwise, it will highlight the next occurrence of the string on or after the currently active position in the target. Searching is not case-sensitive.

    To search for successive occurrences, repeatedly press Enter, in the Search panel, or click on Next. The searching command wraps around the end of the text.

semantic consistency (iss-base)

    Semantic Consistency Principle:
    An object-oriented environment should enable its users, for any symbol (textual, graphical or otherwise) representing a development object in the user interface, to select the object through the symbol and apply any operation that is semantically valid for the object, regardless of the symbol's context -- tool, location, format, representation.

Shell Command button (iss-bench)

    Located at the bottom of the right border just above the rightmost format, invokes the currently defined shell command. By default, the default editor is started, targeted to the class being edited. The effect of clicking on the button can be redefined by right-clicking on the button.

shift-clicking (iss-base)

    A mouse click while holding the Shift key pressed.

Short format (iss-bench)

    Provides a filtered version of the class text ( class interface ) displaying an abstract form, without any implementation information. It is obtained from the class text by removing non-exported or selectively exported features, and routine bodies (once, do and external clauses). For each exported feature, the short form retains the feature name, the signature (arguments, result, and if any, their types), the header comment, and the assertions. It also retains the class invariant and the indexing clause

socket (iss-net)

    A communication port. A software system will exchange objects with another system by sending the objects to a socket. By connecting sockets you enable communication between systems, for example, a client and a server:


    iss-net has been designed to make sockets look very much like files. You send objects to a socket in the same way that you write objects onto a file, and receive objects from a socket in the same way that you read objects from a file. This fundamental commonality is reflected in the inheritance hierarchy of the corresponding classes.

special object (iss-baselib)

    A sequence of elements of identical type. Special objects are used to represent strings, for which the elements are characters, and arrays, for which the elements are of the type declared for the array.

strong typing (Eiffel)

    An approach to software construction where every object has a well-defined type, which results from the declaration of the corresponding entity. Eiffel is strongly typed for readability and reliability. Every entity is declared of a certain type, which may be either a reference type or an expanded type.
    Any type T is based on a class, which defines the operations that will be applicable to instances of T. The difference between the two categories of type affects the semantics of an entity x declared of type T: for a reference type, the most common case, possible values for x are references to objects; for an expanded type, the values are objects. In both cases, the type rules guarantee that the objects will be instances of T.

Suppliers Tool (iss-build)

    An iss-build Tool displaying the objects being used to build the active dialog .

syntactic check (iss-vision)

    Input checking performed during or after the input of a value into a formatting control.

System Tool (iss-bench)

    An iss-bench environment tool enabling the creation, examination, and modification of Ace files, also providing a convenient way to examine the overall structure of a system and access its clusters

template (TUNE)

    An instance of a template type describing the configuration and the dynamic behavior of a type of TUNE object.
    If the root of a template can be presented on the Windows desktop, the template is called a dialog.

Template History (iss-build)

    A list of the templates last accessed which appears at the bottom of the File menu. Selecting such an entry opens the corresponding template.

template type (TUNE)

    A hierarchically structured description representing the configuration of a number of TUNE objects , together with their dynamic behavior.

top-level window (iss-vision)

    A window displayed on the MS Windows desktop, showing a title bar, minimize and maximize buttons, a system menu, and so forth. The first window created by an application must be top-level window conforming to UI_MS_FRAME (part of iss-vision), and all other top-level windows should have this window as parent.

TUNE

    An acronym for " Template-based Universal Configuration Notation for Eiffel".

TUNE manager (TUNE)

    The run-time system of the TUNE system. An application which uses TUNE templates has to run under the control of a TUNE manager .

TUNE object (TUNE)

    Any object that can be configured using TUNE.

TUNE source (TUNE)

UIMS (TUNE)

universe (Lace)

    A set of directories, each defining a cluster, together containing all classes of any of the clusters associated with the given system. In other words, the classes of the universe are the contents of all the class files (by default, all the *.e files) in these directories.

validity constraint (Eiffel)

    Rule expressing properties that syntactically correct elements must satisfy if they are to yield meaningful software. Eiffel's consistency properties (also known as the static semantics of the language) are defined by seventy-three validity constraints. Such constraints serve to enforce the type rules (making Eiffel a statically typed language), the proper use of inheritance, the information hiding principle, and other important design rules associated with the Eiffel method and language.
    Each validity constraint is identified in the book "Eiffel: The Language" by a code of four letters of which the first is always V (for Validity). If such an error occurs and assuming the message was not sufficient to understand the error, the code could be drag-and-dropped into the corresponding Explanation hole of the Project Tool . This will display the complete text of the violated rule.

workbench code (iss-bench)

    Code resulting from a succession of freezing and melting operations, which is much less efficient than final code .

wrapper class (TUNE)

    Eiffel class providing to the application features for direct access to the exported TUNE objects of a template as well as other features for manipulating the template, e.g., loading, resetting, freeing, performing input validation, etc.

wrapper directory (iss-build)

wrapper window (iss-build)