 |
|
 |
 |
|||
|
 John Reynolds's BlogTools ArchivesLonging for an Integrated Maintenance EnvironmentPosted by johnreynolds on August 02, 2005 at 06:24 AM | Permalink | Comments (7)
When the dot.com boom went bust, I was fortunate enough to land a job as an enterprise architect in the development and production support group of a mid-sized corporation. After a career in R&D, I found myself in a more typical IT environment where keeping things running was way more important than implementing new features. This change in perspective from R&D to IT was a very good thing for me. After years of delivering solutions to customers and moving on to the next challenge, I was now the producer, consumer and supporter of my own team's creations. I now had to "eat my own dog food" in a production environment (24x7x365). When you really have to live with (and support) your own products, your perspective on what is important changes. For the most part, business applications are conceptually simple. You present a form to a user, validate the responses, and process the request. It's hard to conceive what could go wrong after deploying such Simple Business ApplicationsTM, but inevitably Murphy's Law kicks in at 2 a.m. during peak processing season. Another common factor of Simple Business ApplicationsTM is perpetual change. SBA's are living and breathing entities that evolve over time: Fields get added, fields get deleted, validation rules change. Edicts from governing agencies impose new constraints. Changing business partnerships impact workflow. Nothing is truly static. Add to the nature of SBA's the inevitability of staff rollover (developer's tend to change jobs frequently), and you start to place a premium on code that is robust, easy to fix and easy to learn. A Tale of Two Dialogs - Replacing Text in Netbeans and EclipsePosted by johnreynolds on September 03, 2004 at 08:28 AM | Permalink | Comments (15)I downloaded the NetBeans 4.0 beta, and I have to say that it's pretty slick. Two years ago, I switched from the Sun One Community Edition to Eclipse, and I am very happy with that choice, but I like to keep up with NetBeans progress. Each environment has strengths that the other lacks, and it's nice to see the cross-pollination leading to better tools for everybody. My switch from NetBean's predecessor to Eclipse hinged on one simple feature. It wasn't Refactoring, it wasn't Wizards, it wasn't Swing vs. SWT. The feature that chased me away was simple search and replace. NetBeans 4 has added a slew of great features, and I may switch back, but sadly that original pet peave of mine has still gone unaddressed.
Here is the NetBeans 4 Replace dialog:
Look's simple enough. Nothing to carp about here...
Oh wait! Take a look at the Eclipse 3 Replace dialog:
See the difference? Eclipse lets me limit the scope of the Replace function to the selected lines. That's it. That's why I switched from NetBeans to Eclipse. It's an amazingly trivial feature, but at the time I made the switch I really needed it. So what's the moral of this story? To some it may be that I am too picky and to heck with me. For others, I hope that they will grok my message. Basic text editing is still a huge part of code development and simple text editing features can make or break an IDE. NetBeans has some really cool features that dwarf this pet peave of mine, and I congratulate all of the folks who have contributed to it. Keep up the good work. UML and Process Definition for Java - JSR 207Posted by johnreynolds on November 14, 2003 at 11:01 AM | Permalink | Comments (3)Martin Fowler's blog on the Unwanted Modeling Language caught my eye and prompted me to re-examine my own feelings about UML. I've never been really fond of UML. I am fond of the less formal "CRC Cards" approach, and I'm drawn to the ideals of Extreme Programming. If I knew more about Agile Modeling I would probably embrace it. I was introduced to UML before it was called UML. Booch and Rumbaugh had not made peace yet, and you had to choose between "Fluffy Clouds" and OMT. OMT bothered me because it was not mandatory to specify the class interfaces. It also bothered me that I was encouraged to specify the data elements (attributes). To me, that violated what I considered the tenets of Object Oriented design. OMT had a data modeling feel to it and seemed to pay too much homage to Entity Relationship Diagrams. Perhaps this was more a failing of my instructors then of the methodology, but I never quite got over the bad first impression. Over the years, UML tools became better (and cheaper), several new diagram types were introduced, and I somewhat resigned myself to the ubiquity of the "Rational Unified Process". I still ranted at the inability of tools to reliably extract UML diagrams from existing code (round-trip-engineering), but essentially I gave in to the pressure and shut up. Why then did I race to read Martin Fowler's blog when I saw the tag "Unwanted Modeling Language"? UML 1.x provides nine standard diagram types (UML 2.x raises the count to 13), but I’m really only “fluent” with three:
Perhaps better tools would change my habits, but there is still a big stumbling block for me. Simply put, I have not mastered a UML diagram type that lends itself to the aspects of programming that I deal with most often. I gather a lot of requirements from users, and I design a lot of user interfaces. I have not found UML diagrams particularly helpful for either task, but have to admit that I really ought to learn more about the Activity diagrams.
"Activity diagrams are business process diagrams and track the flow of individual software objects from internally generated actions in a business context. They are often used to expose parallel and concurrent activities in use cases." Most of what I deal with involves defining or understanding processes. User interfaces are very process oriented because they deal with the communication between humans and machines, but I think that it's safe to say that most programs implement a process or part of a process. The UML activity diagrams seem well suited for my work, but there is a huge drawback (in my opinion). Nothing in the activity diagram is tied back to the source code (or visa-versa). You can't generate source from the activity diagram (not that I would really want to) and more importantly (for me) you cannot generate an activity diagram from source code. Perhaps JSR-207 will change things and provide the kick in the pants that will drive me to master the UML activity diagrams.
"Process Definition for Java will build on Java Language Metadata technology (JSR-175) to provide an easy to use syntax for describing a business process at the source code level for the J2EE platform. Metadata will bind data and tasks within the process definition to variables, classes, and tasks in the source code. The metadata will be amenable to manipulation by tools." JSR-207 (also known as PD4J) is still a work in progress, but it is based on BEA's Java Process Definition and close to fruition. JPD is included in Weblogic Workshop 8.1 and supports the following Process Definition Constructs:
JSR-207 is limited to J2EE. It doesn't define a standard Process Definition Diagram, but I think it could definitely nudge UML tools in that direction. I've seen the modeling tools in Weblogic Workshop 8.1 and the process diagrams have been instantly embraced by my business owners. I love the idea of being able to navigate between a process diagram and the source code that implements a specific step of the process. The more that I can associate a piece of code with what it does for the user, the more confidence I will have that I've implemented what the customer wanted. Another push for standardized process definitions comes from the Workflow Management Coalition's XML Process Definition Language - XPDL 1.0. From their press announcement "Together with other WfMC standards, XPDL provides a framework for implementing business process management and workflow engines, and for designing, analyzing, and exchanging business processes." This is great stuff and I sure hope the JSR-207 and XPDL groups are talking to each other. Much of the code that I have written has "died young' or been "stillborn", and unfortunately the same is true for many of my colleagues. There have been many reasons for this (changing technologies, company deaths, etc.) but I believe that in many cases I have been asked to develop software for a poorly thought out business process, or I have developed "tunnel vision" and implemented software that did not really match the desired process. Perhaps a stronger linkage between the business process definition and source code implementation will produce applications that will live longer. At the very least, it should make it much easier to develop modeling tools that are valuable throughout an application’s lifecycle. Update: See my later thoughts on BPEJ.
| |||
 java.net RSS Feeds
|
