Part 3: Digitalk's PARTS: Parts Assembly and Reuse Tool Set

By John Kozacik


 * Component Programming and Digitalk's PARTS
 * Part 3 - Digitalk's PARTS - Parts Assembly and Reuse Tool Set

Introduction
In the previous two articles I laid groundwork for understanding this product. PARTS is object oriented both in its construction (it is written in Digitalk's SmallTalk) and in its use by an application developer (PARTS applications cannot be created outside the object oriented paradigm). One is provided with graphical representations of classes which one can create instances of and, if necessary, modify to change state (data) and behavior (functions). Messages between objects are specified by drawing connectors between instances of objects, thus specifying process. The event based programming aspect of this product is almost hidden by its obviousness. A completed application presents a display of objects to the user which can be manipulated; a labeled push button for example. A manipulation is an event, its occurrence results in a message being triggered by the recepient of the event; for example the appearance of a dialogue box in response to clicking on a push button.

The product category that PARTS fits into is called 'components programming'. As the name suggests, programming is done by manipulating pre-constructed software objects in order to create composite structures of components.

What does this give you
Why should I be interested in PARTS? Very simply, it provides you with a means of rapidily developing applications which have a graphical user interface in a modern powerful operating system environment, OS/2. Benefits come from working at a higher level of programming. PARTS provides pre-built solutions to many programming needs. An important 'in addition' is that PARTS offers extensibility.

One is not confined to the 'face value' limits of this product because it offers the ability to include DLL's from other products and the making of DDE links to other products. It thus qualifies as a production grade solution as well as a leading edge one. Applications are distributable royalty free (much to the dismay of our worthy Cincinnati Team OS/2 president, Kevin Royalty).

This is not your father's application development technology
In my experience, previous technologies that looked like this were interesting exercises in programming. They were not something you used to deliver an application to a production environment or end users. PARTS is designed to provide the professional application developer with the means of delivering and maintaining production-grade end-user applications in a business environment. It requires new / more abstract ways of thinking on the part of the developer. In creating PARTS applications, one is dealing with more complex programming entities hence one's work is more conceptual. While this is a fine tool for coming up with quick solutions to immediate problems, using PARTS in the design of a business system requires a deeper appreciation of system architecture and the nature of this technology. While little restriction is placed on the structure of an application, planning which results in high functional modularity will have substantial benefits in the understandability and maintainability of the finished product.

For the professional programmer just learning to use object oriented technology, this is an excellent top-down introduction to the field. For those who are after a deeper understanding of object oriented technologies, it may be usefull to do a comparative study between C++ and PARTS, using Stanley Lipmann's C++ Primer and the PARTS documentation as the subject material.

Conceptual model
Using PARTS one manipulates complex software constructs represented as visual components. These components are objects created in SmallTalk and have properties/data and behavior/functions. Control of process is via control of messaging between and among objects. An application is an assembly of components, and re-use is possible via the ability to create one's own components, either within PARTS or in another language to provide DLL's.

Implementation of the conceptual model
The basic model consists of two visible pieces; an OS/2 notebook called the Catalogue which provides the means of accessing iconized software components available for use in constructing an application; and the Workbench screen area which provides the means to 'wire' selected components together in order to create a process.

The Catalogue contains components; different functional categories are organized into different tabbed pages. In order to assists in identifying the components that the different icons on each page symbolize, PARTS displays a textual description of a component as the cursor passes over an icon. Selection of a component for use in an application is accomplished by dragging an instance of the class of the component from the Catalogue and dropping it anywhere on the Workbench. Attributes of the component may then be displayed by double-clicking on that component: color, font, position... are available for modification in a menu appropriate to that instance of the component.

Once the components needed to build an application or component of an application are dropped onto the Workbench, process is specified by click-drag operations between pairs of components. This operation results in a connector being drawn from an initiating component to a receiving component (e.g., a push button component whose pressing is intended to cause a dialogue box component to appear) and the appearance of a dialogue box which provides for the selection of the event / message communication required for the appropriate operation of the connected pair of components. Every component has events which, once selected, determine the behavior the object produces in response to a user or program action; e.g., a button component may be set to respond to a clicked, rightClicked or tabbed event on the part of the user. When an event occurs, it causes a message to execute in the receiving component. In the same manner the message appropriate to the process being defined is selected by the programmer from a menu. Custom messages can be created using a superset of Smalltalk included with PARTS. Thus the communication between two components can be very easily specified by mouse operations and responses to dialogue prompts. The complexity of the communication can be high, depending on the behavior of the pair of components; e.g., a number of parameters may be involved in the event/message communication.

The visible connection created between two parts is termed a Link. Digitalk's implementation of the Link allows communication between two components as described above to be extended, allowing determination of the entire process performed by the application. This is done by providing 3 different kinds of links; Event, Argument and Result. The composition of the Link itself is complex with event, message and argument(s) (if applicable) identifiers indicated graphically.

Components
There are several different categories of components in PARTS, serving to broaden the control the developer has over the capability of PARTS in a particular environment. Native components appear in the Catalogue as parts of the base product. Native component assemblies are composites of native components assembled by the developer and placed in the Catalogue for future use. Instances of native components can be modified via scripts and placed in the Catalogue as unique components. And finally, non-PARTS DLLs may be accessed to create a new component and include it in the Catalogue, providing a component which gives access to all the procedures in that DLL.

Additional capability is given in the way different components may be used. In a plain-vanilla usage one drags a native part from Catalogue and drops it onto Workbench. However customs parts which have been added to the Catalogue may be treated differently. One may simply imbed a custom part taking advantage of a prior construction. One may dissassemble a nested part and use some or all of its sub-components. One may link a custom part, tieing the part used to its source, ordinarily located on a server. This done, modification of the server-located component is duplicated in each instance of its use. This has substantial advantages in system-level code maintenance.

Extensibility
A product is extensible if it can reach outside of its own environment and include properties of the operating system it runs in and other applications that run in that environment. This aspect of PARTS is a particularly valuable attribute to those interested in system-level application generation. The number of ways that new components can be created has already been mentioned, the most significant aspect in regards to extensibility is the creation of new parts which access functions in non-PARTS DLLs. To deal with complex processing issues, one may create a fucntion in their own DLL and call it from a PARTS application. On a broader scale, as long as one knows what parameters any DLL resident function expects and what it returns, that function may be used in a PARTS application. Immediately usefull in this regard are all of the systems level functions in OS/2.

Very importantly, this ability is being expanded to include accessability to SOM and DSOM objects, which will result in an explosion of riches for a PARTS programmer. Dynamic Data Exchange components are available for both client and server allowing a PARTS application to converse with another application. This includes applications running in WIN-OS/2.

Tutorial
The tutorials included with this package are not only good, but makes you feel and see how PARTS allows you to take good advantage of the OS/2 environment. The use of non-modal windows point this out in particular. The tutorials make it obvious that 8meg is lower limit of what you want to run this on for development purposes. As an aside, the phone booke example came up with title bar (and system icon) off-screen and hence unaccessable. This made for some interesting learnings about how you can manipulate 'broken' images.

Considerations
Cost. At $1995 this product may limit its availablilty to professional developers who wish to make a fairly serious financial committment and/or construct a development strategy to present to one's employer. Those with limited budgets, such as the academic with research driven needs or the professional who is managing his/her own career development, may choose the only inexpensive (and less capacious) alternative in programming with components currently available on the OS/2 platform, CA-Realizer. The add-ons which allow extension of PARTS applications via additional components to access databases (DB 2, DB 2/2, SQL Server, SQLBase, Novel Netware SQL, XDB, dBASE, ORACLE), wrap COBOL, wrap CICS, communicate using APPC, communicate using EHLLAPI, access Lotus Notes, or utilze SOM/DSOM objects also represent a significant investment.

In using PARTS, one works only with object instances rather than classes. While this is a logical consequence of this type of product, it represents a restriction in what SmallTalk or other object oriented languages offer. In an object oriented language, inheritance is a very powerful property. It allows a programmer to make a single change in a class that is effectively duplicated in every object, class or instance, in the inheritance chain. A developer using PARTS has access to only a small fraction of that property. The objects the developer creates from the Catalogue are always instances of class objects. Hence it is not possible in PARTS use inheritance directly by sub-classing a class object as one would do in SmallTalk. The closest one comes to this capability is that a new component can be created by a developer and placed in the Catalogue as a linked component. Subsequent use of such a component will retain a link to the class of the component: if the parent component is modified, the change will occur in the component used in the application. Now the programming complexity associated with inheritance is substantial, and implementation of that property would greatly increase the complexity involved in using PARTS. I feel that Digitalk made the most reasonable decision regarding its implementation of inheritance in PARTS.

Multi-threading not directly accessable to the developer
Developer maturity. Some sort of well conceived methodology or approach is mandatory in order to develop an application of any real complexity using PARTS. This technology is ideally suited for demonstrating how a poor programmer can easily create a 5th generation example of spaghetti code. In one sense a PARTS application can be highly self documenting and facilitate maintenance. However this is very dependent on how well the application is designed (vidi infra).

An issue of real concern here is managing application complexity. It is easy, especially for a novice, to create an application which is a too complex visual representation of components and links. This complexity can be reduced greatly by creating scripts to define the process instead of creating Links. However, the advantage of PARTS is its visual representation of application development. Digitalk addresses this issue formally, giving examples of both visual and script implementation of the same routine, making the programmer aware of the trade-off's in each case. My view is that visual complexity can be avoided by taking advantage of the component creation and nesting capabilities provided by PARTS, reserving script writing for extreme situations. The nature of modern programming practice is to create modular applications. Since PARTS provides operations that facilitate this practice, pursuit of this goal should result in applications whose structure is intelligible.

Opinion
I have read in numerous articles that moving to this paradigm is more difficult if one already knows how to program in a 3rd generation language than if one is new to programming. I would agree with this statement only with a substantial qualification; viz. if you program from the bottom up, applying a fixed set of previously-learned algorithms to a problem that you have had no part in defining, then your previous programming experience will hinder your learning PARTS and a person new to programming will have an advantage in getting this technology up and running. However, if you understand programming in the large and view application development as a struggle to create the simplest, most modular solution to a problem in whose definition you have participated, then it will become quickly apparent that PARTS is a technology that allows you to create solutions much more rapidly and to create applications that have good properties; i.e., are understandable to others and easy to maintain. While a neophyte programmer will most certainly be unencumbered by an existing sense of how things should be 'said' in a programming syntax, this same programmer will also lack experience in the practice of creating simple and efficient architectures. Without a developed sense in this practice, programs in PARTS can quickly reach limits imposed by complexity. With this sense, PARTS can be used to create maintainable large and complex applications and systems of applications that serve their use well.

Summary
PARTS introduces a significant new means of rapid development of GUI applications. Its extensibility allows the system builder to integrate applications highly with OS/2 services and make user of other products that are offered under OS/2.