What path do I take to get the most from EA?

[petrel]

Okay, I 'get' UML and I 'get' EA.

But how can EA make my modelling more structured, cohesive and efficient?

I can't find documentation that describes a typical pathway I might take in using EA to model a system.

I really, really want to get ahead in using UML because my colleagues either don't do any system analysis/modelling (of systems used to run one of the largest river systems in Australia), or they use pre-UML approaches - structured programming, Gane and Sarson DFDs, process models etc.  

UML is a better way - but please how do I reuse  the various objects and elements I've created, when should they first be created and in what diagram.

I've asked this type-of question before in other fora - but sadly most responses have not quite understood my problem.  This is not a question about processes - eg. RUP etc. a it's a question about how I interact - about my Use Case - with Enterprise Architect....is that what I'm asking?

Thanks
Greg

[«Midnight»]

Hi Greg,

Perhaps UML Distilled by Fowler and Scott.

There are several senior members and gurus who have a feel for the best refereces to get you on the correct track. Hopefully they'll jump in and give some advice.

If I get your message, you aren't so much asking how to use EA, or how to do any specific thing in UML. You are more interested to get a feel for what it covers and find some candidates for where you can start from and what direction to head, in order to end up with specific types of results. [Surely I could have said that better...]

I read your previous post, and it seems like you got answers to interesting and valid questions, but not quite the ones you asked.

What say folks?

David

PS: Greg, search for "distilled" and "fowler" or "scott" and see what else has been said in some of those messages. I think you might get a lead on what you want, even if I'm off base.

[petrel]

David,

Your interpretation is pretty-well right..."in order to end up with specific types of results".

As for Fowler (3rd Ed.) - love it. But I also have Rosenberg and Scott; Roques; Arlow and Neustadt; B, R and J User Guide; some Ambler; even two Robertson and Robertson, some early Mellor, a Yourdon or two; and probably a Gane/Sarson somewhere, and they're all pre-UML  etc. etc.  (geez... I'm starting to sound like a gear freak!).

So, it seems my issue is not knowing where to start with EA.

Perhaps I don't have enough practical experience in UML to be able to apply EA as a tool.  

I think my problem is analogous to using EA as the toolkit to build a house - I know how to use EA, but I don't know how to apply it because I have no experience in building a house.

I'll revisit Fowler - but I really want to know how conceptually to 'drag-and-drop' components between diagrams (ie. reuse), structure my project project packages. etc.

(Al sounds pretty lame so I won't be offended by minimal responses, but it is frustrating).

Cheers
Greg

ERRATA: Just found a related discussion that covers some of my stuff... http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=UMLPRO;action=display;num=1083181679;start=0#0

[«Midnight»]

Greg,

There are a few folks hereabouts who teach. Better yet, from the way they write I think they must teach pretty good stuff, and pretty well. I'm sure they will wade in now that we have the scope in scope...

From the sounds of things you must be the person who's been leaving all my books out in my 'library.' I too went through the same pile, as well as many others, over the years.

Sounds more like you know exactly how to build a house, and how to use tools. What you really want to know is just how to go about building one of those (for some unexpected value of "those" that might not be a house at all) with these (for some value of "these" that might not resemble any tools you've ever seen before).

Have you used UML before? Regardless, have you investiged any UML-oriented (or tolerent) methodologies? Perhaps look at the Iconix page on the Sparx site. It's easy to find and it has links to a few books you may not have (yet). You could also look into UP (which is the methodology, versus RUP which is an implementation, an important distinction in the OO world, but one which many people seem blind to in this particular case.)

Wade in folks...

[petrel]

David

Greg,

Have you used UML before? Regardless, have you investiged any UML-oriented (or tolerent) methodologies? Wade in folks...

Actually I have (Charles Sturt Uni Post-Grad IT and work-related) but this is all piece-meal really. But here's a catch...I have 20-years of ER modelling and db development experience but this experience can actually make some UML confusing - eg Class associations/foreign keys and collaboration (deprecated?) diagrams etc. - but I digress.

I actually bought the ICONIX CD (the first CD) but I already had the book so I'm trying to negotiate a swapf for the 2nd CD.  Again it seems I need to get on and learn and apply.

My errata to last post also has a very helpful discussion so I'll go quietly, visit it and post back here if I don't make progress.

Thanks for your responses.

Greg

[«Midnight»]

Apologies not (ever) required. The forum is very rich, and the search tool is somewhat limited.

Like me, you have a deep background in IT (I am fast approaching my 40^th anniversary, which can make UML a greater challenge than it might otherwise be.

Tricks include forcing yourself to think in an object based way (I am purposely avoiding the phrase "object oriented" since it is overloaded here). Don't try to do the same things in a better way; try to do other things that will get you to where you should be going (i.e. things that are just as good as before, but put you on a better path to a better end point).

For example, there is a clear evolution from variable oriented programming, through abstract data types (you'll remember your old books from Aho et al), to object orientation. We all know that. What is so obvious that we often miss it, is that in order to be effective, each of these paradigms force you to think and work in a different fashion. Each asks you to un-learn what you knew before. That is, each approach may be invoked to solve the same problem, but the solutions themselves will be very different.

Now, taking that into consideration, reflect back on what you've seen, and consider not so much what you could have 'done' differently but on what you could have 'thought' differently, given that the end product (perhaps versus the goal) is different in each case.

Not much help in a direct sense I know, but I'm trying to compress quite a bit of tailchasing I did when I went through this.

David

[sargasso]

Not much help in a direct sense I know, but I'm trying to compress quite a bit of tailchasing I did when I went through this.

... and don't think you're the only one who had to go through it!  

But how can EA make my modelling more structured, cohesive and efficient?

To what end?  Why model?  Are your models intended to BE the answer or a step towards an answer?  Are you drawing blueprints or solving construction problems?  

These may sound trite but have a great bearing on how you wll use the tool.  

Start focussing on single areas that have a bearing on some current problem you have.  A typical type of thing may be something like a semi-formal repeatable process you can go through to generalise out use case commonalities into extends/includes. Another might be to get a handle on what level of communication or collaboration diagramming is needed at the various stages in your development process.

have a nice easter!

bruce

[Paolo F Cantoni]

[size=13][SNIP][/size]
Actually I have (Charles Sturt Uni Post-Grad IT and work-related) but this is all piece-meal really. But here's a catch...I have 20-years of ER modelling and db development experience but this experience can actually make some UML confusing - eg Class associations/foreign keys and collaboration (deprecated?) diagrams etc. - but I digress.
[size=13][SNIP][/size]

Hi Greg,
Sounds like you come from a similar background to me (except I was an object modeller before I was an ER modeller).  However, I have spent the vast bulk of my professional career in Data Management.

Possibly the greatest single distinction between ER and OO, in my view, is encapsulation - both of Data and Behaviour.  I say this because as an Object modeller before an ER modeller, my ER models are very object oriented - as I describe it: the Object model "at rest".

When you're considering a Class, make each attribute private and then ask: "Why do I need to make you public?"  Similarly, with methods.  I've found CRC techniques to be useful in correctly encapsulating behaviour (and thus associated data).  CRCs are often regarded as "old hat", but "there's gold in them thar hills..."

This is a link to a tutorial I found just now.. I haven't tried it, but it should get you started...
Object Oriented Analysis and Design using CRC Cards

A really nice feature of EA is that you can document the responsibilities in the Class' (internal requirements).  Elsewhere, Sparx have admitted these internal requirements are really Responsibilities of the element.

HTH,

Paolo

[petrel]

Paolo
Thanks for the link - I'll give it a shot.

And for the ideas with Class. I jumped on the OO model in the early 90's  (what was the aqua-coloured hard-copy OO book with the Platypus on the cover? searching my library....). I really like and gravitate to the concept of classes, instances etc., polymorphism, inheritance etc.  My 'users' too love the concept of Classes but they don't necessarily know about implementation :-)

Anyway, I'm acquiring some great advice and links here. Much obliged.

Greg