|
 Nemanja Trifunovic wrote:
Also, I don't like any UML software I've tried so far (Visio, Rational Rose) and often end up drawing the diagrams on a sheet of paper or a whiteboard.
We use a tool called Select Component Architect (www.selectbs.com) - it combines UML with a couple of other standards to allow you to model Business Processes in flow-chart like diagrams (that can be understood by people who hate computers) and then you refine the specification through Use Case and then Sequence Diagrams (or Activity Diagrams, whatever your corporate choice). The software feels a bit home grown (it's not as polished as Rational) but it's fast and easy to use. The UK training courses are excellent (better than the tool) though I've no idea what their training outside of the UK is like.
Bernard
Everything has been said before, nothing left to say anymore
|
|
|
|
|
Shog9 wrote:
what do you feel it gains you?
A "big picture." We deal with large scale solutions across several platforms and layers. Using UML has helped us design, refine, and implement everything from the server to the mobile devices.
Shog9 wrote:
What problems are best tackled with UML ready at hand
All kinds of modelling, from business processes to software. It's not only useful as a tool to architect a software solution, but it has help us define business processes and help our customers refine and create new processes.
Shog9 wrote:
how has using it improved things over the tools you used previously?
Before, we'd have all kinds of notes and documents of varied formats (sometimes quite illegible!), and now everyone in our organization "speaks" UML. There's little confusion now where there was once quite a bit. It has also helped our sales force and business liasons understand and codify business problems, as well as helped our customers express their needs more clearly.
|
|
|
|
|
If you are making an app that is anything more than a trivial utility then it's absolutely necessary to have some way of pre-planning and fitting everything together *before* you write a line of code.
We use it because we make very large business applications.
I wouldn't touch it for making a small utility program, but anything bigger no question I would model it first.
It can save you unbelievable amounts of time by pre-planning in advance.
Also it's not necessary to use all parts of it, we just use what we need that fits our style of development.
If you have ever worked on a large scale application (non trivial, dozens of difference "screens" etc) then you would know immediately why it's useful, if not, then it's just a lot of acronyms.
There is much to be said in favor of modern journalism. By giving us the opinions of the uneducated, it keeps us in touch with the ignorance of the community.<br />
- Oscar Wilde<br />
|
|
|
|
|
My preference is state-sequence diagrams 
Norman Fung
|
|
|
|
|
We have yet to make a single Use-case diagram. We always have such clear docs that describe the features that our clients want etc that it's always seemed like something you would use if you were really clueless about what it was you actually needed to write and were coming from a place where you were building software for an industry that you know nothing about.
There is much to be said in favor of modern journalism. By giving us the opinions of the uneducated, it keeps us in touch with the ignorance of the community.<br />
- Oscar Wilde<br />
|
|
|
|
|
John Cardinal wrote:
building software for an industry that you know nothing about.
I like UML and thinks that it's actually pretty cool Visual Studio comes with tools to convert UML into code blocks. But, UML is just one element of documentation. And documentation is important for many reasons. I should say, a company don't own a piece of software unless it's documented - otherwise, reinventing the wheel may take just as much time and investment. However, half of battle is lost many times before project even get started - in my experience planning too aggressively is the most common cause of failure.
Norman Fung
|
|
|
|
|
For me it defines what you want to program and forces you to work out the design. I find that 95% of what programmers complain about "Requirements Creep" are really stating requirements misunderstanding. Even if you know your area fairly well it is amazing to me how many others that also know their area firmly believe in magic pixie dust when it comes to inserting new technologies or tools into the process. This is what my team is doing and keeping others somewhere close to the ground is immensely helped by doing modeling. Now what modeling is the most beneficial for you or your team varies. There is no magic answer.
I can recommend the following for a good starting point that addressed my needs.
http://odl-skopje.etf.ukim.edu.mk/uml-help/
The tool I use is Sparx's Enterprise Architect. I also have Rational and have not touched it in a year.
http://www.sparxsystems.com.au/
My needs are: I am surrounded by very smart and capable programmers and systems people who think they can do the work the same way they have for 20+ years. So the big impact is conveying what is different with evolving technologies. I start with Use Cases but very light. This is just to form a starting point to talk to customers and those that should be supporters. Generally the Use Cases are single bubbles that have business activity definitions. The next step is in creating business activity diagram for each use case listed. Both the tutorial and Sparx’s have examples here. The input information and process flow are captured here. From those diagrams you can have detailed discussions with whom ever on how the systems works. Even in those areas I am an expert in I find a substantial amount of information to add to the diagrams and notes to elements from these discussions. Usually clarifying information for the less informed that you take for granted! Plan for a 1/2 day for every diagram, I am not kidding. If you take 10 minuetes you have not discussed it! They can then be printed and shared and you have a major step in really defining your requirements. One thing I do try to add is at least a listing of known data sources and recipients to the work. Add schemas in the notes if you can. This is also shared and agreed to by the stakeholders.
Once this is done, and I find many doing UML skip this, you can define the components and responsibilities to be developed. Much of my work is with Services (mostly Web but not all) I define the interfaces to these with schemas. At this point the work can be handed off to the end coders and they can develop models off of this initial work or just start depending on who it is and how segmented this definition makes the project. Often it is fairly small pieced so detail models do not add a great deal of value and are not done.
Shog9 wrote:
how has using it improved things over the tools you used previously?
Previous tools were napkins. They got ruined every time water was spilled and seldom lasted more than a week. So any written agreement as to what the design was is lost. Also white boards but again they get erased so all is lost if not then captured in a model!
Deleted ConfessionCM 22 Feb '04
There are something you just should not claim MAB
|
|
|
|
|
For me, UML proves the adage that a picture is worth a thousand words. I couldn't imagine trying to describe aspects - particularly dynamic aspects - of complex software in words. Yet, the same concept can be very easily expressed as a UML diagram.
Then again, I'm a highly visual person so perhaps UML appeals to me at a fundamental level.
Brad
|
|
|
|
|
|
Brad Sokol wrote:
For me, UML proves the adage that a picture is worth a thousand words. I couldn't imagine trying to describe aspects - particularly dynamic aspects - of complex software in words. Yet, the same concept can be very easily expressed as a UML diagram.
I think that's the big problem with many design tools and strategies: what works fine for one person doesn't do diddly to another. A project I worked on used UML, but most of it was, to me, worthless when writing code. It did describe overall system actions reasonably well, but it didn't tell me how those actions should be performed. Use cases were probably the least useful of all. I must admit, though, that the component breakdown part (the name of which escapes me now, as it's been 3 years since I've been on that project, and the current one doesn't use object-oriented technology) was rather useful, as long as it was done "well" (however you want to define that).
Brad Sokol also wrote:
Then again, I'm a highly visual person so perhaps UML appeals to me at a fundamental level.
Then again, I've never found diagrams -- not even data flow diagrams or flowcharts -- to be of much use to me, even though I'm a visual person. Go figure.
|
|
|
|
|
We are just starting out on using Sparx Enterprise Architect - I won't give the URL as someone has already done so above.
As we're just starting, I don't have a lot to say about the tool itself, except that the development team seem to be very active in updating it, with new releases every couple of weeks, and it seems to have a decent set of functionality for a fraction of the price of the "heavyweight" solutions. All our developers are licensed.
Our reason for going this way is to provide us with a focus point for formalising and documenting our design. While we will certainly have to document things in other ways too, UML seems to us to be a good way of capturing the majority of our design decisions in one place, and in such a way that key parts of the design can more easily be presented and explained to non-technical business people. There isn't a single killer reason - it's because of the number of important things it helps to pull together.
Gavin Greig
"Haw, you're no deid," girned Charon. "Get aff ma boat or ah'll report ye."
Matthew Fitt - The Hoose O Haivers: The Twelve Trauchles O Heracles.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
