Components

Writing quality software is an expensive, time consuming process. Once tested, packaged, and accepted, software created by the best developers is not only usable, but maintainable as well.

Interestingly, when creating reusable components today, few think that it is possible to include a user interface. Before the rise of Object Orientation this belief was perhaps understandable – user interface frameworks not only had to be self-authored, but the graphical underpinnings themselves were often extremely device-specific. Lacking patterns, poorly encapsulated, and complicated to maintain, re-using one team's display 'technology' often resulted in another team's loss of sleep. Rather than expose oneself to the follies of poorly designed frameworks, it was often easier to just write everything yourself.

Today however things have changed. From a graphical interface point-of-view, component writers should increasingly consider providing graphical views into their software and / or systems. No matter if we are using C++, C#, VB.NET, Delphi or Java –When it comes to designing our tools, why not include a few graphical component add-ons, as well?

Say WHAT?

Impossible, you might say? Not at all! Indeed, much like when designing any complex piece of hardware, we software developers need to appreciate that the components we create will invariably become part of a “system of systems:”

under the hood

For example, when we pull the covers off of any modern vehicle, we are not looking at any single system. Instead, what we see is a plethora of components being managed by a central processor.

While it can be amazingly enjoyable to assemble, program, & test discreet sensory systems, the pressure is on for everyone to provide turn-key business-solutions. Why? Because the man-hour savings to be had when re-using things like a compete radar system, weapons system, or even flight control - can provide some serious saving to our clients. Saving that can be quickly translated into markup for we original-equipment manufacturers.

Profits for all ... that cannot be ignored!

In order to make / save some amazing coin therefore, in software as in hardware, system architects & developers alike must expect that the interface to any of our components might indeed be custom, or self-provided.

While describing the process of operational abstraction is well beyond the scope of this article, I felt the need to clearly demonstrate one of the many ways we can include a graphical interface as an integral part of our re-usable components.

Instrumentation Panels?

Of course whenever we want to create add-ons, the first thing we need to have is a properly designed framework. Fortunately, from C# to Java everyone has been using their own version of Delphi's panel:

When seen as a “black box”, the above fragment of an interface-signature has all the artifacts necessary to maintain a useful configuration: A file for input, a panel for output, as well as the associated framework for passing signals (button clicks, focus notifications, etc.) back to our component.

By merely providing a file at the receiving-end of our API, whenever our panel is either provisioned or operated, our component can both read from, as well as maintain, a user-provided configuration file.

Bolting the Panel

From the user's point of view, even software component configuration can be part of many other systems.

When part of a series of operations (the above is from a tool manager I am writing at the moment from Java to C/C++ to a device: We changed the add-on names to make them more applicable to our analogy) the user is also free to use our JPanel to create their own mash-up. -From .NET to Java, I have done the same device-to-GUI tricks for legacy C, C++, and even Assembly Languages.

So here is the magic: Today, all GUI frameworks worthy of the name have components. In this case, components that can contain other components.

In Java, while we have a plethora of panel-hosting options, I decided to use a JScrollPane:

Since our panel can be used by the JScrollPane, whenever the user selects my component, after reading a little about what to expect (the top panel is the factory) he or she can thereafter press the “Config” Button & get on with actually configuring my component. -All while enjoying both the add-on interface, as well as the add-on code, we provided.

For what it is worth, here is the complete configure-n-execute tool interface for my aforementioned add-on tool framework:

/** * Useful when a tool is to be used as part of a work-flow, or process, of * previously-completed operations. * * The file passed to a previous startRun() is to be used as input * to YOUR startRun(). * * @return The tools to run, in proper order. Array length must be ZERO if * the running of other tool(s) are not required. * */ public iPhatTool[] getPreviousWorkflow();

/** * A short name - suitable for use in a drop-down combo box. * @return A short name (typically class.name()) for your tool. */ public String getToolName();

/** * A descriptive paragraph. Suitable for use in a rich-text (HTML) display. * @return HTML text used to describe your tool. */ public String getToolDescription();

/** * Begin running of your tool - (we will provide the main thread) * @param status Check this status whilst running - we will signal if the user needs you to stop. * @param fileRun Here is where you can read / save your results to / from. Can be used for work-flow (etc.) * @param log The log - messages you want to share with the user. * @return TRUE if you ran to completion, false otherwise. (Only TRUE operations can be displayed and/or used by work-flow.) */ public boolean startRun(OpStop status, File fileRun, StatusLog log);

Conclusion

I hope you found this conceptual overview enlightening. No matter if the views we provide into our component be diagnostic, licensing, configuration... or even real-time monitoring, I am often surprised at how happy my clients are whenever we deliver alternative graphical interfaces as part of our designs, frameworks, & components.