- Email: [email protected]
The Unit Model versus code
PART
The Unit Model versus code
9
Whereas a programming language is defined by textual syntax and semantics, the Unit Model has a visual form that permits more concentrated focus on the semantics of the program being built. The Unit Modeler environment positions the Information Unit Model squarely in the dataflow programming paradigm, enabling manipulation via point, click, and drag interactions. However, it should be noted that the open structure of the Unit Model permits a number of programming paradigms, including imperative, object-oriented, functional, and model-driven approaches, and all are widely applied. Because of their dependence on syntax, programming languages—or more accurately, their compilers or interpreters—are highly sensitive. One missing character can lead to a frustratingly broken program. Modern Integrated Development Environments (IDEs) are well-equipped to point out likely errors, but they are not always able to find the root cause of the problem based on the developer’s intentions. The simplistic nature of the Unit Model makes syntactic errors hard to come by. The Unit Modeler is limited in its scope. Whereas most programming languages abstract machine-level instructions, the Unit Model abstracts a focused and powerful subset of instructions that are especially focused on operations in data analysis and manipulation of information. The Unit Modeler does implement concepts common to many programming languages, like classes, processes (functions in most programming), and variables, but it also introduces concepts with no obvious parallel in other languages—most notably, the information unit, elements, and paths. Paths allow developers to define relationships between units, and elements comprise the contents of units and can utilize paths on units to define more complex references. Whereas variables in most traditional languages refer to memory interpreted as a specific data type, like binary data representing an integer, units can hold any number of heterogeneous elements. With reference to executing processes, the Unit Modeler is built as an interpreter of the Unit Modeler. Each step of a process is interpreted when encountered, and the corresponding operation is carried out. Though reflection and runtime structural modifications are possible in some languages (consider JavaScript’s object model), the Unit Modeler is built for this type of behavior. Consider two examples: 1. Finding a class’s base class(es): In a language like Java, you can access a representation of a class’s base class by calling the getClass function on the object. Note that this is a runtime representation of the class, as the class itself
271
272
PART 9 The Unit Model versus code
is defined in code, not as a manipulable object itself. Instantiating an instance of that class dynamically requires knowledge and use of more advanced reflection techniques. Compare the Unit Modeler, wherein a class’s base class(es) are destinations of the “isinstanceof” path off of the unit. The actual class structures are referenced, so creating an instance is as simple as creating an instance of a class in any other scenario. 2. Runtime modifications: A common question asked about programming languages is whether or not functions are first-class objects. A first-class object can be created, modified, and passed around like a variable. In the Unit Modeler, not only are processes first-class objects, but nearly all entities are first-class objects, including elements, operators, and processes. This means that unit contents can be set to complex elements at runtime, and even the operator of a unit can be modified at runtime. A line like “c = a + b” cannot be dynamically changed to “c = a − b,” but in the Unit Modeler, the operator can very simply be changed from the “+” arithmetic operator to the “−” operator. Programming languages all have variables and structures that can be created to represent something. But there is no direct analog that is equivalent to the Information Unit. Declarations can be made that can represent anything, but these are not consistently used as the only means of representing information, data, or processes. There is no universally general declaration as for a Unit. Everything within a model is viewed as an assemblage of a single data type: the Information Unit. This universality does not exist in any programming language. Programming languages do implement the same type of flow as in the Unit Model. In the Unit Model a shock (or program execution) will travel down either a true or false path off the step being executed. This path can go to anywhere. There are some features of code that implement some direction of flow, such as if/then/else statements and for statements. The Unit Model supports meta programming or the creation of new program components on the fly. A process can create a new process or modify steps within an existing process. Some programming languages also support this ability. Programming languages have no direct corollary to the concept of a path. While the star (*) feature of the Unit Model is not entirely unique, it becomes much more powerful when combined with the utility of paths. For example, the element *Patients.Weight refers to all patient weights. In information-based applications, the ability to copy data is pivotal. Copying a complex structure is not always straightforward in a programming language, but the Unit Model exposes a straightforward way to define how components of a model should be copied and moved around via “deep copy.” This greatly improves the reuse of existing structures in ways not otherwise possible. Models are developed and viewed in two-dimensional visual layouts. Insights into the architecture of your application and the interconnectedness of its components are readily understood. You can zoom in and zoom out to see an overview or drill down to see its specifics.
The Unit Model versus code
Reuse of previous work is possible in unprecedented ways. Any two models can exist and work together in the same application. The domain libraries and the Development Resource Center make reusable components easy to find, and when referenced, are loaded automatically via a feature called dynamic loading. Updates occur automatically. Applications built within the Unit Modeler are not just is in a different language, but they are built upon an infrastructure that brings many benefits. One of these benefits is that updates that you may make to your application can automatically be distributed to your users. When an application is built in the Unit Modeler, no new infrastructure or installation program is necessary.
273
The Unit Model versus code
9
Whereas a programming language is defined by textual syntax and semantics, the Unit Model has a visual form that permits more concentrated focus on the semantics of the program being built. The Unit Modeler environment positions the Information Unit Model squarely in the dataflow programming paradigm, enabling manipulation via point, click, and drag interactions. However, it should be noted that the open structure of the Unit Model permits a number of programming paradigms, including imperative, object-oriented, functional, and model-driven approaches, and all are widely applied. Because of their dependence on syntax, programming languages—or more accurately, their compilers or interpreters—are highly sensitive. One missing character can lead to a frustratingly broken program. Modern Integrated Development Environments (IDEs) are well-equipped to point out likely errors, but they are not always able to find the root cause of the problem based on the developer’s intentions. The simplistic nature of the Unit Model makes syntactic errors hard to come by. The Unit Modeler is limited in its scope. Whereas most programming languages abstract machine-level instructions, the Unit Model abstracts a focused and powerful subset of instructions that are especially focused on operations in data analysis and manipulation of information. The Unit Modeler does implement concepts common to many programming languages, like classes, processes (functions in most programming), and variables, but it also introduces concepts with no obvious parallel in other languages—most notably, the information unit, elements, and paths. Paths allow developers to define relationships between units, and elements comprise the contents of units and can utilize paths on units to define more complex references. Whereas variables in most traditional languages refer to memory interpreted as a specific data type, like binary data representing an integer, units can hold any number of heterogeneous elements. With reference to executing processes, the Unit Modeler is built as an interpreter of the Unit Modeler. Each step of a process is interpreted when encountered, and the corresponding operation is carried out. Though reflection and runtime structural modifications are possible in some languages (consider JavaScript’s object model), the Unit Modeler is built for this type of behavior. Consider two examples: 1. Finding a class’s base class(es): In a language like Java, you can access a representation of a class’s base class by calling the getClass function on the object. Note that this is a runtime representation of the class, as the class itself
271
272
PART 9 The Unit Model versus code
is defined in code, not as a manipulable object itself. Instantiating an instance of that class dynamically requires knowledge and use of more advanced reflection techniques. Compare the Unit Modeler, wherein a class’s base class(es) are destinations of the “isinstanceof” path off of the unit. The actual class structures are referenced, so creating an instance is as simple as creating an instance of a class in any other scenario. 2. Runtime modifications: A common question asked about programming languages is whether or not functions are first-class objects. A first-class object can be created, modified, and passed around like a variable. In the Unit Modeler, not only are processes first-class objects, but nearly all entities are first-class objects, including elements, operators, and processes. This means that unit contents can be set to complex elements at runtime, and even the operator of a unit can be modified at runtime. A line like “c = a + b” cannot be dynamically changed to “c = a − b,” but in the Unit Modeler, the operator can very simply be changed from the “+” arithmetic operator to the “−” operator. Programming languages all have variables and structures that can be created to represent something. But there is no direct analog that is equivalent to the Information Unit. Declarations can be made that can represent anything, but these are not consistently used as the only means of representing information, data, or processes. There is no universally general declaration as for a Unit. Everything within a model is viewed as an assemblage of a single data type: the Information Unit. This universality does not exist in any programming language. Programming languages do implement the same type of flow as in the Unit Model. In the Unit Model a shock (or program execution) will travel down either a true or false path off the step being executed. This path can go to anywhere. There are some features of code that implement some direction of flow, such as if/then/else statements and for statements. The Unit Model supports meta programming or the creation of new program components on the fly. A process can create a new process or modify steps within an existing process. Some programming languages also support this ability. Programming languages have no direct corollary to the concept of a path. While the star (*) feature of the Unit Model is not entirely unique, it becomes much more powerful when combined with the utility of paths. For example, the element *Patients.Weight refers to all patient weights. In information-based applications, the ability to copy data is pivotal. Copying a complex structure is not always straightforward in a programming language, but the Unit Model exposes a straightforward way to define how components of a model should be copied and moved around via “deep copy.” This greatly improves the reuse of existing structures in ways not otherwise possible. Models are developed and viewed in two-dimensional visual layouts. Insights into the architecture of your application and the interconnectedness of its components are readily understood. You can zoom in and zoom out to see an overview or drill down to see its specifics.
The Unit Model versus code
Reuse of previous work is possible in unprecedented ways. Any two models can exist and work together in the same application. The domain libraries and the Development Resource Center make reusable components easy to find, and when referenced, are loaded automatically via a feature called dynamic loading. Updates occur automatically. Applications built within the Unit Modeler are not just is in a different language, but they are built upon an infrastructure that brings many benefits. One of these benefits is that updates that you may make to your application can automatically be distributed to your users. When an application is built in the Unit Modeler, no new infrastructure or installation program is necessary.
273