Methodology & UML
Mirek
bussines systems and that supports UML
I need your suggestions quickly.
Thanks.
Regards,
Miroslav
Phlip
> Wich methodolgy is the best for analysing, designing and developing
> bussines systems and that supports UML
> I need your suggestions quickly.
Here's the fastest one some shameless zealots on this group know:
http://c2.com/cgi/wiki?ExtremeProgramming
--
Phlip
======= http://users.deltanet.com/~tegan/home.html =======
Graham Perkins
> bussines systems and that supports UML
> I need your suggestions quickly.
We've tried to adapt Objectory for student group projects here.
It seemed to work well .. particularly by comparison with structured
methodologies and OMT tried in previous years.
er .. UML is a notation, not a goal. What you want is for the notation
to support your methodology, not the other way round! Yes, UML does
support Objectory to a great extent.
Some of our experiences are
- don't try to produce *all* the artifacts that can be produced
in UML.
- for any diagram/artifact you do produce, ensure you have a clear
goal in mind (eg, it will clarify a coding spec., act as cross-
check on another analysis artifact, document system structure for
developers an maintainers..)
- build diagrams as collabarative work on a whiteboard; only use
CASE tools and tarty printouts as audit trail
- possibly avoid CASE tools altogether unless they are VERY VERY
good, eg full round-trip.
- especially for iterative lifecycle, get version management and
configuration control well sorted out early on. This is an area
where you could well use a CASE tool profitably
- the domain is the easy bit .. start on the GUI and Persistence
much earlier than you would normally plan to, as these bits will
take much longer than you think.
- following on from previous point .. make sure to use a good UI
architecture such as MVC so that you can make big changes from
one iteration to the next without having to re-code everything
from scratch
We also found that groups who meet once a day or more frequently,
and review their class and instance models several times a week,
did much better. The "algorithm design" artifacts such as
Collaboration Diagrams were useful only as first cut design and to
check out associations and traversal paths. Once they got coded,
the actual code evolved in each iteration and there seemed little
point in going back to update the CDs. Think of them as prototypes
that are safe to throw away after they've served their purpose. By
contrast, the class and instance models need to be bang up to date
at all times!
Slavery to the notation is also a bad idea. Make it work for you,
not the other way around. We used CDs to sketch out interactions,
not detail the algorithms. Also OMT style event traces are much
clearer and more helpful than UMLs sequence diagrams. I encouraged
students to draw instance diagrams as linked blobs much like old
fashioned data structures. Partly to make them look different
from class diagrams (merging the two is a particularly stupid aspect
of UML), and partly for speed of drawing and erasing.
Let's hope this doesn't start a long argument, particularly about
whether you should use tables instead of UML ;-) I'm just relaying
our experience. The only points I'd want to argue are
- CASE tools are mostly more trouble than they're worth
- only produce things that will make a difference to the
system you implement .. anything else is "stamp collecting"
- Separation of concerns should apply to GUI programming
as much, or more, than anywhere else
good luck,
graham
Rusty Williamson
and did so with RUP in mind (or perhaps UP, it's milder sub-set). At any
rate RUP is what we're getting into now -- it's been evolving for about 20
years (RUP is the latest version of Objectory), covers a wider scope of
development environments then most, I hear the XP people are working with
Rational to create a RUP version of XP (XP is awesome and targets projects
with rapidly changing requirements), and finally, it's been submitted to OMG
for standardization. UP is the core development process, RUP is a life
cycle process and also a on-line product from Rational to guide teams.
I used UML for years with my own relaxed process (a watered down version of
UP, using noun/verb searches and CRC) and this works for great if its just
you or a small group. We have hundreds of developers and distributed teams
and so we researched development methods (and automation tools) for several
months -- we went Rational all the way. There's information on RUP at
www.rational.com -- on-line presentations, evals, white papers, feed CDs --
and if you have any questions I've just been through several months of
reading everything in print as well as training from Rational and running
their tools through the paces.
'Phases', 'workflows' and 'activities' oh my!
Rusty
PS: I'm not connected with Rational in anyway.
------------------------------------------------------------
Rusty Williamson
Sr. Systems Architect
GERS Retail Systems
http://www.gers.com/
The Object Workshop
http://home.san.rr.com/williamson/
Home Page
http://www.znet.com/~rusty/
------------------------------------------------------------
"Mirek" <mir...@iname.com> wrote in message
news:4r9evs8h3d8sioa97...@4ax.com...
> Wich methodolgy is the best for analysing, designing and developing
> bussines systems and that supports UML
> I need your suggestions quickly.
>
> Thanks.
>
> Regards,
> Miroslav
>
p.koot...@remove.ieee.org
> - following on from previous point .. make sure to use a good UI
> architecture such as MVC so that you can make big changes from
> one iteration to the next without having to re-code everything
> from scratch
Graham, do you have any good references (paper or electronic) for this
(MVC)?
> - only produce things that will make a difference to the
> system you implement .. anything else is "stamp collecting"
Having said that, "stamp collecting" the first time around is probably
a good idea --- if only for better identification of those "stamps"
you don't want/need to produce.
Ciao,
Peter K.
--
Peter J. Kootsookos Wb: www.clubi.ie/PeterK
"Here comes the future and you can't run from it,
If you've got a blacklist I want to be on it"
- 'Waiting for the great leap forwards', Billy Bragg
pat_t...@my-deja.com
The Unified modeling language user guide show some steps in the
software development process. From that book you can determine which
methodology is the best for analysis and design business system. You
can get the book for free at http://www.cambire.com. There are also
other UML book. Cambire.com was created for college students to enable
them to exchange, borrow, and donate textbooks to each other. There
are a lot of technical books available in the database.
The service is free.
In article <4r9evs8h3d8sioa97...@4ax.com>,
Mirek <mir...@iname.com> wrote:
> Wich methodolgy is the best for analysing, designing and developing
> bussines systems and that supports UML
> I need your suggestions quickly.
>
> Thanks.
>
> Regards,
> Miroslav
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
Graham Perkins
> (MVC)?
Check out some of the standard Smalltalk textbooks (see amazon) since
Digitalk and Visual Works versions both use MVC extensively. Probably
some of the others too.
I'm writing up some stuff which you'll find on my web page over the
next week or two.
The descriptions I've seen in Java textbooks are ERRONEOUS! Don't
touch them with a barge pole! Please email me again tomorrow as
I've got a paper on Java and MVC at home, but cannot remember the
author. Those articles by Alan Holub were erroneous.
Also worth looking up might be MVP architecture. Andy Blower and
Blair McGlashan at Object Arts Ltd wrote a tutorial paper for
ESUG 2000 which you might find online somewhere.
Both architectures make heavy use of Observer and Adaptor pattern,
so make sure to understand them first!
Tools
> Wich methodolgy is the best for analysing, designing and developing
> bussines systems and that supports UML
>
Visit http://www.excelsoftware.com for information on software models,
design methods and UML tools.
Cristiano Sadun
>Graham, do you have any good references (paper or electronic) for this
>(MVC)?
You can find an interesting discussion in the introduction of "Design
Patterns", by Gamma&C; or in the SmallTalk 80 manual. :)
--
God is Real, unless declared Integer.
ObjectZone - http://space.tin.it/computer/csadun
kiev...@my-deja.com
to get you started:
http://www.martinfowler.com/articles/newMethodology.html
But I agree with Rusty, RUP is the best;)
-Vlad
In article <4r9evs8h3d8sioa97...@4ax.com>,
Mirek <mir...@iname.com> wrote:
> Wich methodolgy is the best for analysing, designing and developing
> bussines systems and that supports UML
p.koot...@remove.ieee.org
and thinking material!
S. Zakon
> Which methodolgy is the best for analysing, designing and developing
> bussines systems and that supports UML
> I need your suggestions quickly.
>
We recommend Craig Larman's methodology, which is best described in his
book "Applying UML and Patterns".
For a review of the book, please see:
http://www.objectsbydesign.com/books/applying_uml.html
And for a summary of Larman's methodology:
http://www.objectsbydesign.com/books/larman_process.html
Stuart Zakon
Objects by Design
Paul Wells
I would LOVE to know what you think of Modelistic www.modelistic.com
Graham Perkins wrote in message <39F7FCB9...@dmu.ac.uk>...
>er .. UML is a notation, not a goal. What you want is for the notation
>to support your methodology, not the other way round!
>Some of our experiences are
> - don't try to produce *all* the artifacts that can be produced
> in UML.
> - for any diagram/artifact you do produce, ensure you have a clear
> goal in mind (eg, it will clarify a coding spec., act as cross-
> check on another analysis artifact, document system structure for
> developers an maintainers..)
> - build diagrams as collabarative work on a whiteboard; only use
> CASE tools and tarty printouts as audit trail
> - possibly avoid CASE tools altogether unless they are VERY VERY
> good, eg full round-trip.
Modelistic's only means of model persistence is source code, is that round
trip enough for you?
>Slavery to the notation is also a bad idea. Make it work for you,
>not the other way around.
Modelistic's first loyalty is to Java, and then secondly to UML
> - CASE tools are mostly more trouble than they're worth
It is very refreshing to hear you say this - most CASE tools make a big deal
of the time they save, but avoid discussion on the time which they cost to
use.
Regards,
Paul