Home » Developing U++ » External resources » FMC
|
|
|
|
|
|
| Re: FMC [message #5997 is a reply to message #340] |
Fri, 27 October 2006 04:27   |
exolon
Messages: 62
Registered: July 2006
Location: 53'21N 6'18W
|
Member |
|
|
| luzr wrote on Thu, 08 December 2005 13:12 |
Actually, I always thought that those funny diagrams are the great way how to fetch more money from your customer, but do not really help to develop applications.
|
Yeah. It's only useful in design for rough sketches of ideas, say, which the different parts of the app will handle different tasks and how they interact with each other.
The real use, I think, is to document existing code so that others can come along and look at it without having to read and understand all of the code first. I know when I started working on quite big Java legacy projects, the auto-generated UML diagrams I made helped me understand what was going on better.
People who expect a rigid design to be implemented before diving into the code are probably going to be misguided... you're rarely going to know everything before you start working on it 
So I'd think of UML as a documentation tool rather than a design tool/necessity. For me, design should be as limited in depth as requirements and user stories from XP planning.
|
|
|
|
|
|
| Re: FMC [message #17333 is a reply to message #17332] |
Thu, 07 August 2008 22:17 |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| asif wrote on Thu, 07 August 2008 16:01 |
Hi,
I would like to respectfully add that UML is not just for diagramming. It's a complete design tool for object-oriented analysis, modeling and design. Just think about designing a greater-than-300-tables database without an entity-relationship diagram!
|
Well, my infamous agenda project has over 600 tables  And I never felt even the need to ER type diagrams.
I guess that once you are accustomed dealing with memory data structures, relation tables are not much different.
| Quote: |
Sameway, you are sure to hit design bugs if you try to write large object-oriented apps without expressing your design using UML.
|
I would argue you are going to hit design bugs with UML too...
Also, IME, UML implies sort of waterfall model, which, in my mind, is flawed from consumer's perspective. I mean, it is in fact very good for programming company, but does not lead to solving the problem. I am strong believer in the iterative approach. The application does not need to be "design bugs free" as long as you have playground area wide enough to fix them.
| Quote: |
I am not talking about just using UML. The UML tool you use should allow complete forward and reverse engineering of code - that is, your diagrams should change your source and your source should change the diagrams. The higher you go design/architecture wise, the more you realize the importance of UML.
|
Quite possible.
It is also true that "regular engineers" likely need some approach like that. Me, solving some problem, I am thinking about it 24 hours a day (even when sleeping). In that case, all these schema pictures just look funny
Mirek
|
|
|
|
Goto Forum:
Current Time: Fri Apr 19 04:05:53 CEST 2024
Total time taken to generate the page: 0.05987 seconds
|
Members
Pages
Help
Register
Login
Home
