In the pre-Civil War days of programming, when men were men, and women were, well, not much seen out in the hinterlands, cowboy coders ruled the range. Cowboy coders started a project by writing the first line of code and kept on going until they came to the end of the trail. They needed only to know code syntax and the business problem. Experts decried cowboys, of course, and talked about the need for software tools, but on the whole, people considered software tools an oxymoron. Instead, they opted for long hours and splashy heroism, keyboards strapped to their sides, ready for a quick draw at the whisper of a CPU fan.
Then came methodologies, structured programming and object orientation, with its assertion that things could be easier if data and functions were conceived together, as nature intended. But nature’s complexity dashed OO’s originally simplistic assertions, resulting in UML—with its 150 concepts, 18 relationships, 48 elements and seven diagrams, not to mention Web services, frameworks, servers, servlets, protocol stacks, HTML, XML, J2EE and the details of the Rational Unified Process. And we can’t ignore the “exuberant creativity” of Goliath software vendors maintaining market share with short-term product manipulation—usually bolstered by advertising hype.
In response, vendors produced a potpourri of individual software tools to separately handle all these aspects. That potpourri was too mechanically cumbersome for the developer to keep synchronized on a project, and soon the tools marketplace converged onto what we now call integrated developer environments (IDE), which bolted together a collection of wizards to automate the previous potpourri. The result, however, forced too many wizards, icons and drop-downs into the too few pixels of the developer’s far-from-adequate screen. More importantly, these bells and whistles do little to help the developer organize the qualitative aspects and development sequences of today’s complex software creation process. So what’s a cowboy—or cowgirl—to do?
Enter, galloping over the horizon, the world’s first software tool tool: Jaczone’s WayPointer 3.0. What’s a tool tool? Consider a screwdriver: It’s a tool to ease the removal of a screw and is generally very useful by itself. But with tough screws, you put a glove on your hand to get a better grasp. The glove becomes a tool to make the original tool work better—it’s a tool tool. WayPointer wraps around Rational Software’s Developer Plus XDE modeling and system specification tool for UML and RUP. It then non-intrusively helps you tackle today’s tough software systems by providing proactive tips on how to proceed and continuously monitoring the modeled system for completeness, consistency and correctness.
WayPointer currently supports requirements gathering, use case creation, analysis, design and project management. Implementation and testing facilities will be available in a later release. Not all servers, OSes and framework environments are yet supported—see system requirements. Also, only Java design classes are currently supported (.NET classes will be available in a later release). Plans for IBM WebSphere and BEA WebLogic are also in the works, but Linux support depends on market demand, so enthusiasts wishing to develop their expertise should badger Svante Lidman, vice president of product development.
Starting it up
After a relatively trouble-free installation, I turned both Rational XDE and WayPointer on and then spent a day pushing buttons, drop-downs and generally mousing around as prompted by my overactive cowboy consciousness. But nothing useful happened; the product seemed impenetrable. I soon realized that I was tripping over my own metaphor. After all, how much can you learn about the glove-and-screwdriver combo by poking the glove with a fork?
Humbled into asking for directions, I went to the Jaczone website, took the audio-visual demo tours and then ran the installation CD’s tutorial scenarios, discovering scenarios for the currently supported development processes. So I told my inner cowboy to go watch a John Wayne movie, started the first scenario and basked in the unswervingly systematic guidance WayPointer offers when it’s used appropriately. I strongly recommend that you hang up your spurs and allow two to three days to complete all four scenarios. While you can get a general idea of how to use WayPointer by running one scenario for a few hours, it takes longer to learn how to rein in your cowboy habits and tailor WayPointer to your project’s needs. It’s not that using WayPointer is challenging; rather, its systematic style is necessarily very detailed, so it takes time to discover and choose all the useful bits.
How it works inside
WayPointer has a highly modular, extensible design (no one would expect less from the likes of its father and principal architect, Ivar Jacobson). The engine contains about 150 more or less asynchronous processes called agents. Each of the agents has access to a small piece of logic (called rule packages; for example RPA, RP-B and so on), built by Jaczone using the WayPointer Developer Kit. Each agent focuses on a specific aspect of either the model as a whole, such as getting started; a piece of a model, such as an individual use case; or the overall process of building software, such as “Develop Use Case Model.” Agents define a context and structure for the rules, which, through the WayPointer browser, provides an interactive way for software developers to use the knowledge contained in the rules in real time as they do their work. WayPointer has more than 800 rules, offering a variety of developer assistance. Among them are rules for getting started; building software system models by presenting more or less unpopulated models and then suggesting ways to identify and describe new elements within the model; rules for model completion that identify missing elements such as subsystems, classes, relationships and so on, and then propose corresponding model refinement; and rules for evaluating and reviewing models that identify checkpoints for things such as inconsistencies, errors or omissions in the model, and then propose corresponding model correction.
WayPointer rules work on data provided from one or more fact servers, which act as under-the-hood interfaces to an external tool like XDE, usually hiding details like the format of database or repository, and how to update and change it. WayPointer 3.0 has a fact server for XDE, Rational Rose, XML, UML itself and, potentially, custom-built repositories peculiar to particular development projects.
This screen is part personal trainer, part developer assistant and part book—providing expert guidance during the requirements-gathering and design process.
Waypointer in use
The “WayPointer Browser” presents a screen that is part personal trainer, part developer assistant and part book—providing expert design guidance during the requirements-gathering and design process, doing the drudge work of maintaining model correctness and acting as a real-time library reference tuned to the exact task at which the developer is working.
It can be configured to track that cowboy consciousness that wants to start at the beginning and keep on going until it comes to the end. It’s also sufficiently flexible in its modes of assistance to speak to you only when it’s spoken to, like a well-behaved child. WayPointer is the Trigger of the future.
From the agent menu item in the WayPointer browser, you select a major development activity such as “Develop Use Case Model.” That selection causes the browser window to fill with a large collection of activity steps that are a sequence, from top to bottom, of all the intermediate mini-tasks needed to build and refine a set of use cases. As you highlight each step in turn, WayPointer displays recommendations, wizards or explanations in the browser window’s detail area. Other steps in the sequence remind you to create actors for the use cases and make the appropriate associations to their respective use cases. Steps that represent checkpoints in the process may be marked with a check as a reminder that that step is completed. High-priority steps—those that WayPointer believes warrant serious attention—are flagged in the priority column.
If you use a wizard in the detail area to create a model element such as a use case or actor, a named graphic is automatically placed into the Rational XDE model window. Conversely, if you switch to XDE and directly place elements in the model, WayPointer detects that and factors it into its ongoing monitoring. If errors or omissions are made in either context, WayPointer instantly places an informative alert called a conclusion at the relevant step location in the browser window.
WayPointer provides much more than a UML syntax checker that simply raps your knuckles when you forget to assign an actor to a use case. Although it can’t yet tell you if the classes you design are the best ones for a given use case, its examination covers a considerable range of qualitative evaluations.
Adapting the software tool tool to your project’s needs.
With WayPointer, the developer can set exactly the degree of control or fussiness that best suits the task at hand. From its browser, WayPointer allows both the setting of thresholds for its various consistency and error-checking tests. The settings can also be tailored for both individual developers and globally for the team. The developer can also influence the degree to which RUP is followed according to the size of the project or other factors that might influence the degree of rigor needed in the documentation.
The presentation side of rules (the messages that are actually displayed) is written in XML, and can be hacked to suit installation requirements, although the out-of-the-box presentations are generally adequate. The developer isn’t locked into any particular architecture: WayPointer, as shipped, can be used on small real-time designs, as well as enterprise information systems that have complex layers and subsystems. However, new architectural mechanisms can be defined in XML.
Some companies might require very special rules or new agents. For example, an installation might want to limit access to only a small subset of J2EE security features by providing its own security layer interposed between the application and J2EE components. Or an installation might wish to write a wizard that aids the developer with something outside the typical J2EE realm, such as the configuration of an Apache Web server. For these circumstances, Jaczone offers the WayPointer Development Kit (WDK), which allows the specifications of patternmatching logic for error detection or mentoring, presentation of the results of a rule match, and formulation of the actions to take either on the model or the repository being controlled. Note that making extensions via the WDK is not required for typical development projects.
The WDK includes:
• A tutorial with step-by-step instructions on building and deploying agents.
• An agent checker that checks correctness of agent definitions.
• A rule language compiler that compiles from JRL (Jaczone Rule Language) to .NET (DLL).
• An API reference for the WayPointer platform, the UML fact server, the XML fact server and the rule language.
Agent building is a serious development effort, even though JRL itself has a relatively limited and easy syntax. For example, making the layer on top of J2EE restrict certain security aspects as mentioned above might take two to three weeks. The first pass at an Apache configuration wizard might take a week or two. Interfacing with a brand-new tool or repository could take many weeks. Once an agent is built, simply placing it in the same directory as the original agents shipped with the product is sufficient to get the new rule loaded at startup. For those interested in agent development, Jaczone recommends its short training course.
• Traceability links among the use case, analysis and design models.
• Potentially suspect structuring; for example, too many relationships, too many elements in a package, overuse of includes and extends relationships in use cases, and so on. (Too many is configurable in WayPointer settings, see “Tuning WayPointer,” page 23.)
• Uniqueness of names.
• Circular dependency relationships in hierarchies.
• Inverted dependencies among layers.
• Noncohesive packages/subsystems
WayPointer fills in a few gaps in the scope of RUP and UML: It reminds you to collect system specification criteria for persistence of data, security concerns, performance, system availability and modifiability that aren’t represented in UML graphics or are only vaguely referenced in RUP.
All these little nudges, presented amiably, patiently, consistently and at your discretion, gradually wire into your spine a parallel subconscious tendency to find the things that WayPointer looks for before WayPointer gets there. It’s not a competition; rather, your game gets improved without much effort. That inner cowboy gets to flex its muscles in a very satisfying way. And as such, WayPointer can effectively be used as a training tool for programmers inexperienced in UML or RUP, while simultaneously developing a real product.
When you decide to follow a WayPointer recommendation, it hooks into the Rational XDE and ensures that all model artifacts are fully updated with all the details. During the portions of the development cycle when you use WayPointer to review existing models, you may decide that there are either real bugs or feature enhancements that should be captured and passed on to other team members. WayPointer captures this review information into an XML file.
Similarly, if you invent a new use case, WayPointer inserts the appropriate details into the project plan, again saving you keystrokes. Wherever it can, WayPointer tirelessly takes care of the boring, no-brainer work for you. With the exception of Microsoft Word and XDE, WayPointer doesn’t link to any other external editing or graphic tool. Occasionally, I found myself wishing for more external linking capabilities, but because WayPointer automatically keeps everything in XDE updated, most tasks are accomplished in the relatively simple WayPointer browser instead of the more complex XDE GUI.
WayPointer as Book
A book has a fundamental flaw—it doesn’t know you’re reading it. It doesn’t know what you’re using it for, what your interests are or where you are in the task that led you to open it. And it can’t give you the one idea that you need right at that moment. Instead, it offers 30 ideas and leaves it to you to pick the correct order of assimilation.
Since WayPointer is always watching what you’re doing, it has precise knowledge of your specific task within the entire scope of software development. WayPointer can therefore present explanatory text that exactly suits your design purpose minute by minute.
For example, while prompting you to define the system’s actors, the WayPointer detail area presents a compact description of three kinds of actors that you might consider in a typical system, reminding you that in addition to the key actors that employ the system, you should think about those helper actors that provide data to the system for its inner workings and those support actors that do system startup and shutdown, maintain databases and provide logins. Typically, these compact descriptions also include hyperlinks to the exact pages in RUP that apply—saving you from searching through the thousands of RUP documentation pages.
If the WayPointer verbiage seems too fussy, its step sequence window can be split: You can drag the steps window away from the detail area window and dock the steps window on top of the Rational XDE, thus leaving the explanatory text window off in a corner somewhere to talk to itself.
WayPointer holds your hand, does your gopher work and prods you to think about aspects of system design you’ve forgotten that you had good instincts about. Aside from a feeling of comfort, this pioneering product calms your inner cowboy and affords a breathtaking acceleration of your technical prowess.
It’s rare that a product of this caliber comes along to a reviewer. In fact, I predict that in five years, any software product lacking WayPointer technology will head out on that lonesome trail to nowhere.