Tennessee Rational User Group

I received an email a while back from Tin Dizdarevic of the Rational User Group looking for a volunteer to lead the Tennessee Rational User Group. After much soul searching and a little procrastination, I decided to raise my hand and take this on.

If any of my readers from Tennessee would like to joint the Tennessee Rational User Group, please go to the Global Rational User Group web site, use the "Find a User Group" feature to search for the chapter in Tennessee, and register for the group.

I am also soliciting suggestions on the best (or least bad) times for the User Group to meet, how often it should meet, where it should meet, and what topics you would like to see addressed.

Learn to Love Your SAP IDoc

Over a year ago, I had a post in which I discussed how difficult it is for a custom application development person like myself to get adjusted to projects based on a packaged application like SAP. It had the somewhat humorous title How to Talk to an SAP Consultant (If You Must).

If you keep reading this post, you will see that I am now starting to understand some of the SAP terminology which once seemed so incomprehensible. I hope you will find this post helps accelerate your own understanding of SAP if you are thrust into it like I was.

I now have become all too familiar with the SAP interfaces for external system known by the name "IDoc".

SearchSAP.com provides the following definition:

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program.

Being relatively new to the SAP world, these complex documents reminded me of database schemas generated by the old Computer-Aided Software Engineering (CASE) tools with many cryptic table names and field names that only an automated tool could keep track of.

For example, suppose you want to create an order from an external system in the Customer Relationship Management (CRM) module of SAP. What would you expect the interface to be called? How about something like "Create Order"? Wrong! My client's CRM team first instructed us to use a standard IDoc going by the rather unintuitive name of "CRMXIF_ORDER_SAVE_M02". Shortly later, they decided that this standard IDoc would not meet all their business requirements and they created a new IDoc from the standard one and gave it a name they prefixed with a "Z" and added a different ending. I will stick with the standard create order IDoc for this post, however.

Ok, suppose you get past that detail, get into the right IDoc and start looking for the data representing the order header. Do you find it under something like "Order Header" or "Order"? No! Try looking for something SAP calls a "segment" and whose name is "E101CRMXIF_BUSTRANS".

help.sap.com has this to say about segments:

Segments form the basic building blocks of an IDoc type and are used to store the actual data.

A segment type is the name of a segment and is independent of the SAP release.

The segment definition is the release-specific name of a segment. By combining the segment type and the release, the required segment definition can be determined: This way, you can assign segment definitions from previous releases to an IDoc type in the current release. This may be necessary if, for example, the partner is using an older release which supports your current IDoc type but not your current segment definitions. You then have to "reset" these in the Partner profiles .

This segment type name is not completely random but is based on the phrase "business transaction" instead of order. I believe the addition of "E101CRMXIF_" to the beginning makes the segment type release-specific and specifies the segment definition.

Each segment can in turn have multiple fields. Some of these fields can contain data defined by another segment. These can be optional or mandatory. One segment can have a 1:1 or 1:n relationship with another segment. For example, the standard E101CRMXIF_BUSTRANS segment looks like this when I look at it in the XML editor of Rational Software Architect v7 (though truncated to what would display on my screen and still be readable):


Note that the order segment has many individual elements (mostly strings) followed my many references to other segments. The graphical representation looks a lot like an object model or database design.

An entire SAP IDoc can be huge! The entire IDoc for orders includes well over 200 IDoc segments. After I used my XML editor to format the XML schema of CRMXIF_ORDER_SAVE_M02 so that it was neatly indented and had line feeds before each level of nesting, the resulting XML schema file was a mere 38257 lines long.

If your next project takes you down to the implementation level of SAP, I hope you're a detail-oriented person.

(Dec 2007) English not your native language? I've begun making podcasts of popular posts and they are available at http://artsciita.podbean.com/. Listen online at that URL, with the MP3 player below, or subscribe to the podcast using the RSS feed and listen with your favorite MP3 player.

Powered by Podbean.com

Copyright © 2007 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Reverse Engineering of UML Class and Sequence Diagrams from Java

About a year ago I had to stop work on an interesting project. There were just too many projects going on at one time, not enough resources to work on them all, and the other projects were more important from a political point of view. The project involved our B2B application making a call to a service provided by a 3^rd party outside the firewall. One of the developers had built some great Java code to do this right before we stopped work.

I recently picked that project back up again and needed to dig into that code, understand how it worked, and create some design documentation for the overall project. I also had just recently made a conscious effort to upgrade my object modeling tool from Rational XDE to Rational Software Architect (RSA).

I decided I would start by reverse engineering the Java code to create a class diagram. I had done this numerous times as a Rational Rose and Rational XDE user in the past so I had no worries. I managed to import the source code and began fumbling through the menu options looking for reverse engineering features. I got a sinking feeling at first that someone at Rational had taken the reverse engineering features away. I found numerous transformations for forward engineering from UML class diagrams into something else (like Java). It was not obvious, however, what to do if I already had the Java code and wanted to go in the reverse direction. I had a sinking feeling inside. Had the Model Driven Development / Model Driven Architecture adherents at Rational lost their minds? Had they taken those reverse engineering features away on purpose? Was this a heavy handed means of forcing the whole world to adopt a “forward engineering only” view of the application development process?

Luckily, I was able to determine that Rational had not lost its collective mind. Yes, it was indeed possible to reverse engineer code into a diagram and as I got more into it, I decided it was actually an improvement.

I highly recommend a meaty white paper I found on developerWorks called “The new IBM Rational design and construction products for Rose and XDE users” by William T. Smith, a Product Manager supporting model driven development at IBM Rational brand software. From it I discovered that many reverse engineering capabilities were available in RSA (as well as Rational Software Modeler (RSM)) and they appear to be significant improvements over what I was used to in Rose and XDE. There is a great deal of new terminology to get used to, however.

Here is a quick summary of what I learned about reverse engineering using RSA

• I can select Java classes of interest with my mouse and quickly reverse engineer a class diagram by “visualizing” a “Topic Diagram”. This diagram can be synchronized with code as the code is modified.
• I can “harvest” classes from the topic diagram and paste them into a separate UML diagram.
• I can mix “pure” UML classes and harvested classes on the same diagram and the tool will mark classes reverse engineered from code with a glyph in the upper left hand corner.
• There is a new “Browse Diagram” capability which allows the user to explore existing code by quickly generating class diagrams “on the fly” showing classes related to a selected class. Selecting a different class on this diagram will generated yet another diagram on the fly with all classes related to that class. This quick navigation from one diagram to another is a great way to “get to know” code someone else wrote. You can control which kinds of relationships are included when the class diagrams are created and how many levels (up to 3) removed from the selected class in the center of the diagram. I made great use of this on my project.
• (Drum roll please!) I can reverse engineer Java method bodies into UML Sequence Diagrams by “visualizing” a “Static Method Sequence Diagram.” This type of program understanding tool has long been missing from UML modeling tools. It will be a windfall to any poor soul who must maintain/modify poorly documented Java code created by someone else who is perhaps no longer around. The only downside is that if the method makes any calls to low-level Java classes like “Integer” those method calls will clutter the generated diagram. But.. think of the time you’ll save!

Together, these reverse engineering capabilities will just about take away the last excuses for not having design documentation match the “as implemented” state of the Java code. It really is easy to create both class and sequence diagrams and rapidly document both the static and dynamic behavior of “as is” Java software.

(Dec 2007) English not your native language? I've begun making podcasts of popular posts and they are available at http://artsciita.podbean.com/. Listen online at that URL, with the MP3 player below, or subscribe to the podcast using the RSS feed and listen with your favorite MP3 player.

Powered by Podbean.com

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Methodology and SOA for the Methodology Nazi in You (and Don't Forget Governance)

The title is a little tounge-in-cheek but there is a segment of the software community that cares a lot about application development methodology and making it easier for a large team to follow the associated best practices (and correspondingly harder to make excuses for going off and doing their own thing). The current focus on Service Oriented Architecture has placed a really bright spot light on these issues and the stakes are high for ignoring best practices.

IBM's Rational Method Composer (RMC) can be used to customize an established development methodology such as the Rational Unified Process (RUP) for your particular project or organization. RMC comes with "multiple process content libraries, including RUP, RUP plug-ins, SUMMIT Ascendant methods, and other processes for Program, and Portfolios management."

Once you customize your development methodology, you can export it to Rational Portfolio Manager to help project managers create project plans. See Exploring Rational Method Composer and Rational Portfolio Manager integration.

You can also export your customized methodology into content that loads into Rational Application Developer for WebSphere (RAD) so that your developers can refer to the guidance from within the same Eclipse shell as they develop their Java code. The method content is displayed within RAD in a "Process Advisor" view as described in New Features of RAD 6 for WSAD v5 Developers Course Outline beginning on page 8.

For those of you who worry about making sure your organization follows a newly established SOA Governance policy as they start creating new business services, rolling out an Enterprise Service Bus, and making "grow my own" vs. reuse decisions, download IBM Rational Method Composer plug-in for SOA governance. This helps "identify appropriate best practices, merged with your existing IT processes, to provide proper governance of the capabilities introduced with SOA. The end result is a project plan to create your organization's unique governance framework." Note the project plan tie-in which would benefit from the integration of Rational Method Composer with Rational Portfolio Manager as described earlier.

For those of you who are both methology czars and service modelers there is a free download UML Profile for Software Services, RSA Plug-In which can be used to customize Ratonal Software Architect for modeling services in an SOA environment. It uses the conceptual model described in UML profile for software services and adds many useful stereotypes to your UML models such as Message, Service Partition, Service Provider, Service Consumer, Collaboration, Service Collaboration, Service Channel, Service Specification, Service, Service Gateway, and Message Attachment.

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Leading a Software Project Like Directing a Movie?

A couple of weeks ago a co-worker passed me an article that really got me thinking about what it takes to lead a significant software development project. In Successful software management style: Steering and balance* Walker Royce, Vice President Rational Brand Services, makes an interesting argument that running a major software project is a creative act, more like directing a movie than what most of us think of when we think of project management.

I must admit his argument is seductive. I think that as an architect, I consider myself more of a “creative type” who makes something out of nothing. Often I don’t like being held to a plan I had no part in making. And when I help make a plan, I budget some time for some tinkering.

Maybe Walker Royce has a point. Here are some quotes:

“Managing software projects successfully has proven to be very failure prone when using the traditional engineering management discipline. Comparing the challenge of software management to that of producing a major motion picture exposes some interesting perspectives. Both management problems are concerned with developing a complex piece of integrated intellectual property with constraints that are predominantly economic. This article introduces some comparisons between managing a software production and managing a movie production, then elaborates four software management practices observed from successful projects. The overall recommendation is to use a steering leadership style rather than the detailed plan-and-track leadership style encouraged by conventional wisdom.”

""Heresy!" some may shout. "Software projects need more disciplined engineering management, not less." Before you dismiss my claim as an insult to the profession, consider these observations:

• Most software professionals have no laws of physics, or properties of materials, to constrain their problems or solutions. They are bound only by human imagination, economic constraints, and platform performance once they get something executable. Some developers of embedded software are the obvious exception.
• In a software project, you can change almost anything at any time: plans, people, funding, milestones, requirements, designs, tests. Requirements -- probably the most misused word in our industry -- rarely describe anything that is truly required. Nearly everything is negotiable. "

"Metrics and measures for software products have no atomic units. Economic performance more typical in service industries (value as observed by the users vs. cost of production) has proven to be the best measure of success. Most aspects of quality are very subjective, such as maintainability, reliability, and usability."

"Process rigor should be much like the force of gravity: the closer you are to a product release, the stronger the influence of process, tools, and instrumentation on the day-to-day activities of the workforce. The farther you are from a release date, the weaker the influence. This axiom seems to be completely missing, or at least grossly underemphasized, by the process evangelists and literature, but it is usually very observable in successful software projects."

"Most unsuccessful projects exhibit one of these characteristics:

• Over-engineering on the early phases (creative aspects) of the life cycle. You need maneuverable processes that easily adapt to discovery and accommodate a degree of uncertainty to attack a few major risk items, prototype solutions, and build early and coarse artifacts. What creative discipline can you think of in which more process rigor is considered beneficial in helping humans think?
• Under-engineering on the later phases (production aspects) of the life cycle. Extensive change-managed baselines of detailed and elaborate artifacts need engineering processes with insightful instrumentation and attention to detailed consistency and completeness to converge on a quality product."

On the flip side, there is the problem of “Can my customer culturally handle the kind of “give and take” in a creative software development process? Do they understand the idea of “discovery” of requirements or do they think they've identified them all already? Can customers really admit how little they know about what they want or how poorly they sometimes articulate their “requirements”. Can they accept trying out an idea, deciding it was all that good, and throwing the work away?

Another problem area is that for most of us is that we have to live within a budget which often must be cast in stone very, very early in the process before those requirements (negotiable as they may be) are really well understood. How many customers really work in an organization that allows them to “go back to the well” and ask for more money without commiting some kind of career suicide?

Then there is the recurring problem of technical orgainzations expecting to have their budget estimates cut so they pad their numbers. Business users then come to expect to routinely receive padded numbers and promptly cut the estimate by an even larger percentage. For a humorous look at this situation see Project Approval Games: Three Fantasies mentioned in a previous post Feudal Line Management and Shared Resources.

My gut tells me to accept a lot of Walker Royce’s ideas and bake them into a project plan that appears more traditional by adding a lot of tasks with formal sounding names that really mean “verify we really understand what they want”. My experience is that customers often articulate pretty well the “happy path” of what they want when everything works like they hope. They are not so good, however, at telling you how many things can go wrong and telling us what the software should do when an exception occurs and we are no longer on the “happy path”. It may be wise to add a few formal sounding task names that really mean “contingency for exception handling we don’t know about yet goes here”.

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

IBM Proposes to Donate Part of Rational Unified Process to Open Source Community

IBM's Rational Division Proposes Major IP Donation to Open Source Community
— RUP is a software process platform that has guided some 500,000 developers around the world in projects ranging from small-scale product development to large industrial-strength systems, according to IBM. It comprises what IBM says is 'a vast collection of methods and best practices for promoting quality and efficiency throughout software development projects.' Now IBM proposes to donate a subset of the platform to the Eclipse Foundation.

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.