The first thing I did at DHL Systems was learn and use Rational Rose, and learn more about the RUP methodology. The aim was to figure out how to marry classic ERD data models with the Object-Oriented development modeling, especially the Class Diagram. This actually involved a lot of discussion with the OO experts in our group. I even went on another UML course (my first visit to Denver), but I still wasn’t grokking it. I also read one of those “UML for Business Modeling” books, but it didn’t help.
So, I translated some of the existing ERD models into Class Diagrams, and then tried my hand at some Activity Diagrams to model how some Classes would be created in a business transaction. Frank (my boss and fellow Analyst) and I showed these to our chief OO designer/developer, and his reaction was negative. His opinion was that UML is a software design language, not be used for analysis or requirements. He stated that what OO developers needed from Business Analysts was a “concept diagram” ( a generalized Class diagram that just showed what the main things of interest are) and Conceptual Use Cases. Frank was concerned that my hard work had gone for naught, but we moved on. Our Architecture group was going to participate in a company wide pilot to use UML, OO, RUP and a new architectural approach to create new services for tracking shipments through the DHL website. My job was to first write the Conceptual Use Cases, which would be used to create a design and concrete use cases, to be vetted by DHL IT in Brussels and built by another DHL Systems group in Kuala Lumpur.
There were no business people involved directly, the KL group was positioned as our ‘customers’. As such, any requirements they had were technical and cause for much wrangling between them and the OO folks in my group (more about that later). So, I went back to the big data models built in years past because, as you might expect, they were all about Shipments and all the supporting things you needed to pick-up, send, and deliver a Shipment. I created a set of Query Use Cases based on the data models that would accept enough data to identify a shipment (or at least a short list of candidates) and return whatever data you needed about the contents of the shipment, where it was and so on. I actually thought they were pretty lame, as my IEF days had installed in me the belief that queries and reports didn’t need requirements the way Create, Update and Delete transactions did; but, they were accepted pretty well, mainly because previous attempts had produced requirements that were either too vague, or too technical… I had found the middle ground. Then the real fun began as we moved into design…
No comments:
Post a Comment