This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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?
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....
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 ]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: May 15, 2002
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’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com