• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Regarding the order of UML diagrams in Design

 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Everybody
I started reading UML couple of days back and i read various diagrams used in designing.I wanted to know in what order wh should go.
For example we are designing a payroll system
I should start with preparing usecases.Once usecase is are finalized then i prepare scenario diagrams for each scenario in use case.Once scenaridiagram is ovce i prepare sequence then collaboration.
I know i should do activity and statechart diagrams also before starting class design but not sure where to fit.
Can some body help me.Please tell me whether the order i followed is correct.

Regards
Radha
[ August 28, 2003: Message edited by: Radha MahaLakshmi ]
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The order of and the combination of UML diagrams to use in a project varies according to the needs of the project. I know some rigid processes force you to produce this and that document/model before moving to the "next phase" but that's not necessarily the best approach.
 
Radha MahaLakshmi
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
You mean we can skip some of the diagrams depending on the project is it???

If you are following good design principals and wanted to trace back any time to find why you arrived to a particular decision i feel its alwys better to go through all steps insted of skipping.
I would like to know what is the order in general most of the designers follow though it varies from application to application depending on various factors.
Regards
Radha
[ August 29, 2003: Message edited by: Radha MahaLakshmi ]
 
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If you are following good design principals and wanted to trace back any time to find why you arrived to a particular decision i feel its alwys better to go through all steps insted of skipping.


The whole point of UML models is to help cut code.
Once your code is written , you may as well throw them away.
Modelling is a way to aid communication.
When you need to write more code, get into the habit to draw the models piece at a time.
Some models may be worth keeping.
I think Object Diagrams or the more abstract Class Diagrams, Data Model Diagrams( which is not UML), perhaps ?

The rest are possibly easily generated from code and give no added-value to the code. If you don't understand the code you probably shouldn't be working anywhere near the code.
A new one that's coming is Component Diagrams which I feel would be worth keeping.
My 2p.
regards
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You mean we can skip some of the diagrams depending on the project is it?
Almost. The point of the UML was to include as many types of drawings as were felt necessary to cover every design possibility. Whether that goal was achieved is another question.
An upshot of this is that for any particular design/communication problem, you only need a subset of the UML diagrams. If you don't need to commincate a particular aspect of your design, then there is simply no point in drawing that type of diagram. If your design is stateless, why draw an empty state diagram?
If you are following good design principals and wanted to trace back any time to find why you arrived to a particular decision i feel its alwys better to go through all steps insted of skipping.
I'm pretty sutre that what Lasse was trying to explain is that UML diagram types are just a "bag of tools". There is no set order, or even recommended order. Draw only the diagrams you need for your application, and only when you need them. This may mean that you draw one diagram type for one part of your application, and later find that you also need that diagram type for another part.
I can't help thinking that you have a misunderstanding of what UML is for. The act of drawing a UML diagram is not design itself, it is communication of a design. Some people may use UML diagrams as notes to themselves when designing. Some people may use UML diagrams as explanations to others. Design is an activity that happens in people's heads, UML is simply a standardized way to explain or record such designs. Programming is not the same as typing, designing is not the same as drawing.
And so we come back to your original question. You almost certainly don't need all the diagrams, and as diagrams are for communication of ideas not generation of ideas, you need to find out who the diagrams are for, and what they need to understand by studying them. Once you have that, you should produce only the diagrams which communicate the needed information, and include on them only the things which are relevant.
Has this helped?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Radha MahaLakshmi:
You mean we can skip some of the diagrams depending on the project is it???


Yes. Depending on the project, you could even skip *most* of them, or replace them by something else.


If you are following good design principals and wanted to trace back any time to find why you arrived to a particular decision i feel its alwys better to go through all steps insted of skipping.


When do you need to trace back and how do diagrams help???

I would like to know what is the order in general most of the designers follow though it varies from application to application depending on various factors.


I don't think there is a general order. The main purpose of a model is to enable you to do the next step, until you finally can write the code. So, if you know the requirements and are sure about how to code the system, you don't need any intermediate models. If, on the other hand, you have some doubts, you need to select the best model to examine that doubt. That model might be an UML diagram, or it might be something else (textual use cases, CRC cards, whatever).
Also notice that you don't "finish" one model, getting it "right", before you go to the next. That is because the next model will give you feedback about the ones before, so you might get new doubts (or new ideas) you want to explore. Even when working on the code, new questions about the requirements might arise, for example.
See http://www.agilemodeling.com/essays/iterateToAnotherArtifact.htm
 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Radha MahaLakshmi:
Hello Everybody
Please tell me whether the order i followed is correct.
[ August 28, 2003: Message edited by: Radha MahaLakshmi ]


First decide on the list of diagrams that help convey your design. Then order it based on the feasibility of generating the diagram. For instance, sequence diagram can be generated only after classes are identified. So a class diagram precedes sequence diagram. Subsystem and component identification happens before class identification. So a component diagram precedes class diagram.
Nalla
 
Radha MahaLakshmi
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello All
Thanks for your replis.
I understand what you are saying,but i am not able to realize the class diagrams from my use casses.
I am working on an applicaton which is used to place some trades for various funds.The UI is more or less similar for all the funds with slight variation.
Without thinking much i relaized that i need to have 5 clients for 5 typs of funds and a server program to receive the information and update the database.I can start coding by writing one calss for each client and a server to receive the information sent from client.
I dont know whether this is good way of doing or not but i thought if i go through all these steps it could have helped me in designing in a better way.
-Radha
[ August 29, 2003: Message edited by: Radha MahaLakshmi ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Nalla Senthilnathan:
For instance, sequence diagram can be generated only after classes are identified. So a class diagram precedes sequence diagram.


On the other hand to know which classes to build into your system, you need to know how to distribute responsibilities - and sequence/collaboration diagrams can help you do so. Another way to do this is using CRC cards (which are kind of an interactive mix of class and collaboration diagrams).

Subsystem and component identification happens before class identification. So a component diagram precedes class diagram.


Again, not necessarily. You might very well discover new components/subsystems while designing your classes.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Radha MahaLakshmi:
I understand what you are saying,but i am not able to realize the class diagrams from my use casses.


We should make an important distinction here: Are we speaking about an analysis or a design diagram?
The former is simply depicting (part of) the problem domain. It is used to foster understanding of the problem and often can rather easily derived from requirements.
The latter is depicting how you (plan to) build the solution - the software system. Even after fully understanding the problem domain, it often takes a considerable effort on creativity to get a good system design. There simply is no direct, automatic mapping from the former to the latter.


I dont know whether this is good way of doing or not but i thought if i go through all these steps it could have helped me in designing in a better way.


I agree with Frank here - drawing diagrams just means to depict your thoughts. If you aren't sure what makes a good desing, drawing diagrams won't help you much.
In fact I think spending too much time on diagrams can in fact handicap less experienced developers, as it delays feedback from actually coding the design and increases the effort of applying changes.
So my advice would be to do many experiments with actual code and getting good at refactoring (that is, finding out about problems in your design based on the existing code and applying changes without compromising functionality).
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Radha MahaLakshmi:
I dont know whether this is good way of doing or not but i thought if i go through all these steps it could have helped me in designing in a better way.[ August 29, 2003: Message edited by: Radha MahaLakshmi ]


Sorry if I'm beating a dead horse here but I think it is important that you understand the main point (not that I think it's not been explained well enough because it has).
UML is just a tool, a way of expressing/communicating ideas. The UML can help you organize your thoughts and have something to guide you while you create your application. But you have to be careful not to go overboard. If you're building a high-rise office tower, you'll have to create a number of plans. But if you're only making a chair, would you go to the trouble of making blueprints, plumbing and electrical layout plans, and architectural perspectives? A rough sketch will usually do, right?
Same concept with using UML. Don't think you have to use all of the diagrams it specifies. Create only the diagrams that will help you understand the problem and/or what you need to do. Anything else is just a waste of time, effort, and your client's money.
Yes, it can be confusing and it's a lot harder to decide what kind of diagram would be applicable especially if you don't have much experience using UML at all. But don't worry, there are a lot of people here who will be more than willing to help out. And if you ask them enough questions, you may not even need UML
 
The only thing that kept the leeches off of me was this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic