• 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

sequence diagram (OOA or OOD) ?

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi
just got a silly question.. In few resources it is mentioned that sequence diagrams comes under OOA, and in few it is mentioned that it comes under OOD. I would just like to know, under which phase does it come?

also what diagrams comes under OOA and what comes under OOD?

correct me if i am wrong?

OOA
Use case diagrams
Activity diagrams
class diagrams (primary level without any interactions)
sequence diagrams

OOD:

Class diagrams (detailed)

where does
state, object, collobration, deployment diagrams reside?

i hope you can help me in this regard.

thank you
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can do an "analysis model" where the objects are (more or less) real world things. The objective is usually to document how things really work with or without the system under study, perhaps including things that will never be part of any system. It's an analysis activity, not a software design activity. In this mode, you could do class diagrams, collaboration, sequence, state, activity, all kinds of things. Just remember that they are not software classes.

Then when you do real software design you might use all the same diagrams again, only this time modeling software classes and components. Real life things like paper forms, people may disappear, and artificial things like controllers and persistence tools may appear.

How was that for totally avoiding a clear & concrete answer?
[ January 24, 2005: Message edited by: Stan James ]
 
kumar Reddy
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for the reply.The answer from you was good

so from your reply, i understood as follows..correct me if i am wrong..

in the analysis phase, requirements are collected and all the type of diagrams can be used to model these requirements by realising them into real world objects.

In the design phase, the diagrams from the prev phase (real world objects and interactions are taken and a detailed diagrams are presented based on the object oriented programming language selected.

am i correct
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yup. I'm not sure how many people bother to do analysis models. Most of what I see is done in PowerPoint graphics rather than UML

The transition from analysis to design is far from mechanical. Taking your analysis objects too literally into software design can get you into bad places. I find the leap from analysis to design very hard to describe. It comes more naturally after trying it a few (or a few hundred) times.

The agile movement recognizes how hard it is to get a design completely right before you start coding and has practices that make it possible to refactor designs at low cost.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic