Newbie help on UML/EA

[umlNewbie]

I am about to begin the redevelopment (total rewrite) of an application in VB.Net and am looking at EA to assist this process. I am new to UML and was hoping to get some feedback on the approach we are considering.

Because we already have a very good understanding of the requirements of the system (although mostly undocumented), what we need from a tool like EA is probably quite different to what we would need if we were starting with a new product. Also, the database design is basically set, and there will be very little change in that respect.

Therefore we were considering jumping straight into the design of our business objects, and then using this to generate the classes in VB.Net.

At this stage I don’t know if this is even possible, but if it is, will this approach cause problems later down the track? What I’m asking here is whether EA is structured in such a way that requires you to start with Use Cases and work your way down through the various layers of the design model?

Any suggestions/comments would be greatly appreciated.

[sargasso]

Step 1: Correct the following statement!
"we already have a very good understanding of the requirements of the system (although mostly undocumented)"

Step 2: If you ignored Step 1 {
                        go and read the CHAOS report (http://www.standishgroup.com/sample_research/chaos_1994.php,  especially note success factor #3)
                        goto step 1}
            else {
                        go to step 3.
                     }

Step 3: Start the design.


th
bruce

[umlNewbie]

Bruce,

Good point, but I probably should have been a little clearer on the "no documentation" comment.

We do have a document that specifies the requirements from a user's perspective, AND we currently have a full working system. What we don't have is any design documentation that says how we got there.

By the way, thanks for the reference to the article. I did read it and found it interesting.

David

[thomaskilian]

the CHAOS report (http://www.standishgroup.com/sample_research/chaos_1994.php,

can now be found at http://www.standishgroup.com/sample_research/chaos_1994_1.php

[sargasso]

Fair enough.  Then I would start by designing the design - dont commit to a two step business objects -> design classes and we'll get it done by 2pm way of thinking.  Consider the "new unwritten" requirements, in particular those concerning the decision to rewrite.  What is the project really trying to achieve - a technology refresh, a .net pilot, something else?  Split the business and project objectives and consider how best to achieve them.  For example, technology refresh may (IMO) be best achieved through some significant initial effort in the architecture to develop deployment, component and interface models to some degree of detail, including the investigation of alternatives, walk these through against your objectives.  Component models in particular can add real value in
1) revealing misconceptions, misunderstandings and unstated assumptions both betyond and within the design and develeopment teams.
2) creating a lucid understanding of who is responsible for what.
3) reducing the chance of duplicated programming effort (two programmers producing code with the same responsibilities.

Get a rudimentary use case model going, to be refined where necessary over the life of the project.  It will save sqillions when it comes to testing.

(although I will never, never, never, never condone the agile approaches - ever.   )  have a look at some of the Ambler stuff like

http://www.agilemodeling.com/artifacts/

to get a glimpse of how the uml models address particular matters ad how it is not necessary to design completely vertically from the outset.

hth
bruce

[TrtnJohn]

This sounds just like the position I was in a few years back.  I had to make the same decision to skip a few steps and try and design based on implied requirements.  There are definately some pitfalls to skipping some steps.  The biggest problem you have is that all members of your development team will tend to isolate their design based on the area of supposed know requirements they are assigned to implement.  This happens because your first step is to implement a design.  Instead, if the whole team is involved in analyzing requirements and Use Case definitions they have a much broader view of the system.  The end result will be smaller/tighter code.