• 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

UML diagrams vs. Structured diagrams

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi everyone,
just joined ur group.
i m presently working on some UML material for an introductory seminar at our place.
i m still not convinced why should i use Use cases,sequence charts and class diagrams when i already have everything depicted via DFDs,Process Flow diagrams and the like.
Differences between usecase and DFD,when both solve the same purpose in the same manner?
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Deepa,
The DFD's and flow diagrams are more of a Flow based approach to solve the problems or rather design the solutions.
While the Usecases and collaboration diagrams or sequence diagrams are rather structure based solutions to the problems.
The later is attahced to a mathodology which is evolved and mature to accommodate challenges in designiong the solutions. Also it's Object oriented approach in the later stages of UML
I hop this satisfies your concerns....
 
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Divyang.
You may find this thread useful CMM, TSP,PSP
(Ignore the CMM,TSP,PSP bit for now)

DFDs(or rather functional decomposition part of DFDs) it seems hasn't quite been relegated to the bin.
Personally , I'd start with the OO stuff first:
Use Cases, Class Diagrams etc and only consider functional decomposition within the context of a simple architecture(functionality based around a single computer). Only if you really need to.I can't see why the OO stuff can't work better in this latter case too.
Some people argue that Business Components like EJBs are function decompositions but I've yet to see any evidence of this.
regards
[ July 03, 2003: Message edited by: HS Thomas ]
 
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 Deepa Kuppa:
just joined ur group.


Welcome!

i m still not convinced why should i use Use cases,sequence charts and class diagrams when i already have everything depicted via DFDs,Process Flow diagrams and the like.


Well, they are certainly not identical, are they? Add UML to your bag of tools (as well as Use Cases, which are textual and not part of the UML) and apply them as you see them fit.


Differences between usecase and DFD,when both solve the same purpose in the same manner?


I don't think they do.
First, DFDs are graphical, whereas use cases are textual.
Second, DFDs show the flow of data through the system, whereas use cases concentrate on user actions and perceivable reactions of the system.
I'd think that they are complementary.
See also http://www.agilemodeling.com/artifacts/ and http://www.agilemodeling.com/essays/realisticUML.htm
Hope this helps...
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Personally , I'd start with the OO stuff first:
Use Cases, Class Diagrams etc and only consider functional decomposition within the context of a simple architecture(functionality based around a single computer). Only if you really need to.I can't see why the OO stuff can't work better in this latter case too.


I must correct the above somewhat in the light of Illja's post and links.
Use DFDs as the RIGHT artifact for describing existing legacy systems and if you are trying to move towards an Object Orientated approach to development , use Use Cases and the UML artifacts.

I'd think that they are complementary.


As you can see Illja probably doesn't agree with the above view.
But having worked on a project that started out OO, after some heavy DFD and Structured Analysis sessions you could hardly call it Object-Orientated. They could have done with more than a smidgin of the UML but no one had experience of using the two Analysis methodologies together.
But I bow to Illja's experience in these UML matters.
We were describing a legacy system for a new platform. There was 1:1 mapping between legacy and the new system.
1 business object equivalent to 1 relational table. No interfaces whatsoever.
To be fair experienced UML designers could probably factor in the required OO features with a whole new set of additional tools.
regards
[ July 06, 2003: Message edited by: HS Thomas ]
 
I have gone to look for myself. If I should return before I get back, keep me here with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic