Sequence Of Design Diagrams !

[Manas Ahlaad]

Hello All,
I request all to give a vivid answer to the following question.
We have an Use Case Diagram, High level component diagram, low- level component diagram, sequence diagram, class diagram, state diagram.
How one is deduced from the previous one , like how component diagram is deduced from use case diagram since at that case only use case is input for deciding on component. should the high level component diagram be technical or business oriented ?
please clarify
Thanks In advance

[Frank Carver]

How one is deduced from the previous one , like how component diagram is deduced from use case diagram since at that case only use case is input for deciding on component.
If one diagram can be deduced mechanically from another, there is no real reason for it to exist. The whole point of having multiple types of diagram in the UML is to allow people to communicate different facets of a model. If you could fit it all on to any one diagram, there would only be one diagram type.
should the high level component diagram be technical or business oriented ?
You should ask yourself this question.
As I seem to repeat every few days: the sole purpose of UML diagrams is to communicate ideas between people. They have no mystic power - producing a UML diagram will not make your model, design or code any better, however much money you spend on it.
Who are you producing this diagram for? If it is to be read by people interested in technical aspects, cover technical issues. If it is to be read by people interested in business aspects, cover business issues. If it is to be read by people interested in graphics and layouts, forget the UML and show some screenshots!

[Manas Ahlaad]

thanks for that reply frank !
i wanted to know what can be called a component ,i mean what level of abstraction should it have?
lets take this scenario, drawing money at ATM machine, when we start doing high level design, we look at components ,can ATM machine be a component here,or is the transaction module in ATM a component?
please clarify

[Frank Carver]

Again, it all depends on who the diagram is for.
If your reader is interested in the interplay between screen, keypad, cash hoppers and delivery feeds, then show those.
If your reader is interested in remote authentication processes and messages sent to central accounting systems, show those.
This may sound vague, but I can't help more, because you still haven't given any hint as to who will be reading your diagrams, and what they will want to learn from them!

[Manas Ahlaad]

Hello Frank,
Diagrams are for developers sake for traceability.
Thanks

[Ilja Preuss]

Originally posted by manas ahlaad:
Diagrams are for developers sake for traceability.
[/QB]

Can you please elaborate on that? What do you want to be able to trace and why? In which ways do you hope diagrams would help with that? Are there possibly other ways for accomplishing this traceability?

[Manas Ahlaad]

Hello,
By traceability i meant traceability of ideas which led to design decision like what led to making a component a component.diagram can translate >60% of an idea which the designer had at the time of designing.
for this reason if we want to draw a component diagram ,what would be the parameters for deciding on identifying a component from a set of requirements !
Thanks

[Muriel Boutefeu]

Manas,
Creation
1. You list your Use Case Name
2. Your write some text scenario for the main Use Cases
3. You draw a UML Use Case Diagram
Elaboration. In each iteration:
4. Your write text scenarii for almost all Use Cases
5. And in the same time you discover the conceptual data. You model them in a UML Class Diagram (no operation in classes at this step)
6. You can also write System Sequence Diagrams. These are main scenarii between Actors and [/B]System[/B]. You use UML Sequence Diagram
7. You refine your UML Use Case Diagram
Then you apply Design Patterns to simultaneously
8. Draw the interaction diagrams (either an UML Sequence Diagram or an UML Collaboration Diagram. An interaction diagram show how objects collaborate to fulffill one scenario.
9. Simultaneously you find Software classes and you create a new UML Use Case Diagram(this time with operations in classes )
10. You group your classes and collaborations diagrams in Packages(
11.To explain the architecture of your System, you draw an UML Package Diagram
12. Draw UML Deployment Diagram
Construction. In each iteration:
12. Refine the text and diagrams as needed.

[Ilja Preuss]

Muriel,
what you seem to describe mostly resembles the methodology called Waterfall, where you only start designing when you "finished" gathering requirements, start implementing when you "finished" your design etc. (pleases excuse me if I misread your post). Most of todays methodologists advice against such a process because of lack of critical feedback.
For example, in RUP (where you have nearly the same phases as you mentioned), the final delivery of *every* iteration, regardless of the phase, is a running system. In every iteration you do have requirements analysis, design, implementation and testing - it's only the balance between those activities that shifts when transitioning to the next phase.

[Ilja Preuss]

Originally posted by Muriel Boutefeu:
Then you apply Design Patterns to simultaneously
8. Draw the interaction diagrams (either an UML Sequence Diagram or an UML Collaboration Diagram. An interaction diagram show how objects collaborate to fulffill one scenario.
9. Simultaneously you find Software classes and you create a new UML Use Case Diagram(this time with operations in classes )

I would very much worry about overengineering the design by thinking to much about design patterns at this stage of development. Design Patterns are good ideas about handling dependencies at the implementation level, but they always also come with a cost. In my experience it is rather hard to balance costs versus benefits of design patterns without the direct feedback from the code.

[Ilja Preuss]

Originally posted by manas ahlaad:
By traceability i meant traceability of ideas which led to design decision like what led to making a component a component.

This is still rather nebulous to me...
Perhaps you can give me a concrete example of a situation where such information would become helpfull? Thanks!

diagram can translate >60% of an idea which the designer had at the time of designing.

Mhh, do you find this to be a convincing value?
For example, I would wonder how effective a *discussion* with the designer could be...

for this reason if we want to draw a component diagram ,what would be the parameters for deciding on identifying a component from a set of requirements!

I would kindly suggest that you are putting the cart before the horse here.
The motivation for drawing a diagram should be to communicate something you want to communicate rather persistently. So, before even thinking about drawing it, you should already *know* what your components are.
If you don't know, you should think hard about why you want to know - that could give you a good hint on how to find them. If it was only because you wanted to draw the diagram, that would seem to be rather pointless from my point of view...
[ October 14, 2002: Message edited by: Ilja Preuss ]

[Ilja Preuss]

Originally posted by Ilja Preuss:
The motivation for drawing a diagram should be to communicate something you want to communicate rather persistently. So, before even thinking about drawing it, you should already *know* what your components are.

Just wanted to clarify that I wouldn't hesitate to draw diagrams on a napkin or white board while identifying components in a discussion with colleagues. But, again, the diagram here is a tool, not a goal...

[Manas Ahlaad]

--------------------------------------------------------------------------------
Originally posted by manas ahlaad:
By traceability i meant traceability of ideas which led to design decision like what led to making a component a component.
--------------------------------------------------------------------------------
This is still rather nebulous to me...
Perhaps you can give me a concrete example of a situation where such information would become helpfull? Thanks!

when you design an application for a bank, you decide that funds manager is going to be a component.for that you have a reason as to why should you seperate this to a component.how to maintain this info for tracking such kind of reasons??

quote:
--------------------------------------------------------------------------------
diagram can translate >60% of an idea which the designer had at the time of designing.
--------------------------------------------------------------------------------
Mhh, do you find this to be a convincing value?
For example, I would wonder how effective a *discussion* with the designer could be...
it may not be a convincing value always.. but sometime , yes it is...

quote:
--------------------------------------------------------------------------------
for this reason if we want to draw a component diagram ,what would be the parameters for deciding on identifying a component from a set of requirements!
--------------------------------------------------------------------------------
I would kindly suggest that you are putting the cart before the horse here.
The motivation for drawing a diagram should be to communicate something you want to communicate rather persistently. So, before even thinking about drawing it, you should already *know* what your components are.
If you don't know, you should think hard about why you want to know - that could give you a good hint on how to find them. If it was only because you wanted to draw the diagram, that would seem to be rather pointless from my point of view...

hey ilja, i would agree to your argument. but, what i want to know is..
when a designer sits for looking at a requirments and drawing a component diagram, what parameters he takes into consideration???
thanks

[Manas Ahlaad]

ilja , waiting for reply.....

[Ilja Preuss]

Originally posted by manas ahlaad:
when you design an application for a bank, you decide that funds manager is going to be a component.for that you have a reason as to why should you seperate this to a component.

Yes. Typically this is because I need to implement some services which seem to belong together (for example because they are working on the same data), so I decide to join them into a component. Because of the nature of the services I then might think that "funds manager" probably is a good descriptive name.

how to maintain this info for tracking such kind of reasons??

I think that depends on *why* you want to track that info. I still don't understand what you want to do with that info later on. When would it become handy and for what purposes?

--------------------------------------------------------------------------------
diagram can translate >60% of an idea which the designer had at the time of designing.
--------------------------------------------------------------------------------
Mhh, do you find this to be a convincing value?
For example, I would wonder how effective a *discussion* with the designer could be...
it may not be a convincing value always.. but sometime , yes it is...

When, for example?

I would kindly suggest that you are putting the cart before the horse here.
The motivation for drawing a diagram should be to communicate something you want to communicate rather persistently. So, before even thinking about drawing it, you should already *know* what your components are.
If you don't know, you should think hard about why you want to know - that could give you a good hint on how to find them. If it was only because you wanted to draw the diagram, that would seem to be rather pointless from my point of view...

when a designer sits for looking at a requirments and drawing a component diagram, what parameters he takes into consideration???

I honestly don't know. The only time I tried something like that was when attending a lecture about Fusion, a very "waterfally" methodology. It simply didn't work for me...
Currently I am using test-driven development as design methodology - the design here is mainly shaped by writing tests first and refactoring the design mercilessly, diagram sketches are only sometimes used to communicate specific issues to coworkers - and it really seems to work fantastically.

[amit ang]

Hi Manas,
I think the the use case diagrams, the component diagrams or the High level diagrams all have there own values.
like use case diagram shows you the scenario's that can be present, i mean actor doing some process, typical representation of the process happening in the system. The component diagrams you talking about are the set of process that could form the components.
Now this is all i feel. Tell me if i am worng at any stage.
Now, These could be the business prospective
like you said the "withdrawal of money" from the ATM could be the use the High level diagram in the first iteration, which could be subsequently reduced to the low-level diagram, by showing the details in the the process "withdrawal of money", like it may require a authentication of the user, which could be the on more use case in it.
So, here the designer would be putting the business prospects in the diagram view, that may be usefull for the business understanding(for busines persons) and also usefull for the developer to understand the flow.
Hope that's what is the answer.
Regard's
Amit

Originally posted by manas ahlaad:
Hello All,
I request all to give a vivid answer to the following question.
We have an Use Case Diagram, High level component diagram, low- level component diagram, sequence diagram, class diagram, state diagram.
How one is deduced from the previous one , like how component diagram is deduced from use case diagram since at that case only use case is input for deciding on component. should the high level component diagram be technical or business oriented ?
please clarify
Thanks In advance

[Manas Ahlaad]

Ilja,
I as a designer ,want to track the reasons since , i dont want anyone in future to come to me after looking at my project design and ask me the justification.
If I have a diagram, and some points stored somewhere which state why that design decision was taken, my life becomes easier and my job is appreciated.
What say

[Ilja Preuss]

Originally posted by manas ahlaad:
I as a designer ,want to track the reasons since , i dont want anyone in future to come to me after looking at my project design and ask me the justification.

Mhh, I wonder why you feel that way. Personally, I always enjoy discussing my designs with co-workers.

If I have a diagram, and some points stored somewhere which state why that design decision was taken, my life becomes easier and my job is appreciated.

IMHO, automated unit/acceptance tests (preferably created test-first) might present much stronger arguments. After all, a diagram is just another view on the code, whereas tests *force* the component to exist (as they would fail without it).
Am I missing something?

[Frank Carver]

Am I missing something?
I think what you may be missing is "blame culture". The description of "traceability" above sounds a lot like "covering my ass".
I'd guess that manas ahlaad works (or thinks he does) in a place where a popular response to a problem in a system is to try and work out who made the "mistake". In a situation like that a good thick layer of design documentation works like armour.
You and I don't have that problem. We know it's all Chet's fault, after all. Unfortunately, not everyone knows Chet, though.
if you don't know Chet, look at this thread

[Manas Ahlaad]

Frank, You got it wrong dear !
here nobody wants to blame others.
But I am not sure that I will be in this organization to discuss things and name it as CHET's problem. Today I may go , someother may come.I just wanted to know how to convey my thoughts to him in my absense.
you got it ! right ! otherwise it's Chet's problem !

[Ilja Preuss]

OK, here is what I wanted to have if I had to maintain your code, in priority order:
- a month pair programming with you on your code
- automated customer acceptance tests, telling me immediately when I accidentally broke a feature
- perfect code: small classes/methods, descriptive names, no duplication
- automated developer unit tests, telling me when I broke a small part of the system
- some pages of high level description of the systems architecture, accompanied by some high level class diagrams
- possibly some collaboration/sequence/state diagrams for the most complex/critical parts of the system
What would others like to have?
[ October 21, 2002: Message edited by: Ilja Preuss ]

[Manas Ahlaad]

Ilja,

You cut my point of discussion to maintaining code . that's ok.
i wont agree to pair programming.since it can not bring the feature "conveyance clarity" to everyone. only the person associated with me in pair programming will get to know.
[I}automated customer acceptance tests, telling me immediately when I accidentally broke a feature
- perfect code: small classes/methods, descriptive names, no duplication
- automated developer unit tests, telling me when I broke a small part of the system[/I}
I agree to all these.

some pages of high level description of the systems architecture, accompanied by some high level class diagrams
possibly some collaboration/sequence/state diagrams for the most complex/critical parts of the system
this is what I was talking about.I was asking suggestions and guidelines for these. i was thinking whether we can write a document which has description of approach ot the diagrams and descrition documents.
you are in sync with me right now ilja, please try adding something.
TIA

[Ilja Preuss]

Originally posted by manas ahlaad:
i wont agree to pair programming.since it can not bring the feature "conveyance clarity" to everyone. only the person associated with me in pair programming will get to know.

Well, I guess that is one of the reasons why XP teams switch pairing partners several times a day...

some pages of high level description of the systems architecture, accompanied by some high level class diagrams
possibly some collaboration/sequence/state diagrams for the most complex/critical parts of the system
this is what I was talking about.I was asking suggestions and guidelines for these. i was thinking whether we can write a document which has description of approach ot the diagrams and descrition documents.

You might find something of interest at http://www.agilemodeling.com/ and/or the accompanying book.

[Fintan Conway]

Hi Manas,
Diagrams are going to show the design you chose rather than the reason behind why you chose that particular design.
I would say that you need a text document to define your Design Decisions - show alternatives and the pros and cons for each alternative, and the final reason why one alternative was chosen over another.
I have personally seen a situation in which one design decision was agreed upon by a team. The team next met over a week later and someone reintroduced the same problem. Others said "I know we agreed to solution X, but I don't know why". Solution Y was then agreed upon.
Later the user came back and said "We want something along the lines of X". Because no one had recorded the reasons for choosing X over Y, people were left to remembering why X was better than Y and perhaps forgot the real reason that X was better.
I would implement a process for documenting all design decisions. Note that there is no mention of diagrams here.
HTH,
Fintan

[Ilja Preuss]

Another interesting approach is presented at http://c2.com/cgi/wiki?VideoTapingDesign

[Thirumaran Somasundaram]

I'm new to uml designs and i'm here to get some help from somebody who is ready to help.
I need to create some use case models for pop-up messages which occurs in every web html/jsp pages.How do i go about to design those models.I want it in general or it can be with an instance if u have.I wish i could leanr UML in short period by haunting this site.
Thanks Folks
Thiru

[Manas Ahlaad]

Flinton
I strongly agree with you. my problem is to document it .yeh ! i got to know that you need not use diagrams for it , can put it in a simple document.
what kind of format you used for that document?
TIA

[Ilja Preuss]

Thiru,
I guess you should begin a new thread for your question.

[Fintan Conway]

Originally posted by manas ahlaad:
Flinton
I strongly agree with you. my problem is to document it .yeh ! i got to know that you need not use diagrams for it , can put it in a simple document.
what kind of format you used for that document?
TIA

Hi Manas,
The basic format is :
Design Problem

    [B]Alternative 1[/B]
        Advantages :
        Disadvantages :
    [B]Alternative 2[/B]
        Advantages :
        Disadvantages :
...
Design chosen
Reasons for choosing design

Basically you document the advantages and disadvantages of each alternative and the reason one alternative was chosen over the others.
HTH,
Fintan
[ November 05, 2002: Message edited by: Fintan Conway ]

[Manas Ahlaad]

Thanks Fintan !
Frank was telling that the intention of writing documents such as this is to cover the ass. I dont agree with him.there are many organization which follow documenting design decision.They are found useful even !

Manas

[Ilja Preuss]

Originally posted by manas ahlaad:
Frank was telling that the intention of writing documents such as this is to cover the ass.

I think you misunderstood him.
You stated that your life would become easier if you could somehow document design decisions. I wondered why you thought diagrams and the like would be more effective in this regard than automated tests and direct personal communication.
At this point, Frank remembered me about the fact that there seem to be environments where you could be blamed for simply not writing something down and therefore are forced to "cover your ass" by producing otherwise questionable documents.

there are many organization which follow documenting design decision.They are found useful even !

Yes, there are masses of organizations producing unbelievable amounts of paper documentation. That doesn't mean that there were no more effective ways to communicate for many of those projects.
I still wonder why you prefer written over spoken communication.
Of course, if you yourself can't remember your design decisions (and that gets into the way later), or you simply aren't accessible to your coworkers, you probably *should* write something down.
Nevertheless, I would strongly advice to use higher bandwith communication channels wherever possible and only fall back to purely written communication when nothing else does work. Also, attentively observe which of your documents really get used (and are found to be usefull), and which are just a waste of time to create.

[Frank Carver]

And don't forget the code itself!
In my experience the only documentation that developers really value is the code itself. Everything else is dangerously out of date as soon as you turn round. Even comments are sometimes untrustworthy, so you should consider spending the time making the code more obvious.

[Chris Mathews]

Originally posted by Frank Carver:
And don't forget the code itself!
In my experience the only documentation that developers really value is the code itself. Everything else is dangerously out of date as soon as you turn round. Even comments are sometimes untrustworthy, so you should consider spending the time making the code more obvious.

Amen to that. Unreadable code is never going to be cost effective to maintain... it doesn't matter how much documentation there might be.

[Manas Ahlaad]

I still wonder why you prefer written over spoken communication.

You are thinking of ideal teams here.Practically what happens when a designer is working on more than one project simulataneously i.e. vertical programmming (or something like that),he does his part of designing and walks out of project before the completion.now for resolutions of issues he cannot be roped in to the project again.
this situation mandates you to have some backup interms of documents which reflect the designer's frame of mind when he was desinging so that others can go through them and knowledge is transferred with out the designer's presence.
Frank , Yes ! Code is the most important thing which reflects design decisions. Agreed !

[Ilja Preuss]

Originally posted by manas ahlaad:
You are thinking of ideal teams here.Practically what happens when a designer is working on more than one project simulataneously i.e. vertical programmming (or something like that),he does his part of designing and walks out of project before the completion.now for resolutions of issues he cannot be roped in to the project again.

So I wonder why you would want to do *that*...

this situation mandates you to have some backup interms of documents which reflect the designer's frame of mind when he was desinging so that others can go through them and knowledge is transferred with out the designer's presence.

Certainly. I still think you should try to avoid the above situation. If you can't, you have to rely on less effective communication like written documentation, yes.