Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

All You Need to Know About UML Diagrams

tallyfy.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: All You Need to Know About UML Diagrams

#31

Post by bane »

grzm wrote: post #30
bane wrote: post #29

Earlier quoted context omitted.

Because you're creating a waterfall that you can only slide down and the development process becomes an exercise in alignment to "the plan".

One doesn’t need to be wedded to diagrams one works out up front. Doing a bit of design upfront can be useful in fleshing out ideas. Whether that’s in UML, sequence diagrams, stories, or just some sketches on a whiteboard, or some notes on paper, what one does with them is up to the team. It need not determine everything that follows. You point out all of this yourself upthread.

Yes exactly. Pointing a development effort towards a goal or in some direction is a very different thing from an Enterprise Architect dropping a bible of UML on a team.

Re: All You Need to Know About UML Diagrams

#34

Post by diminoten »

bane wrote: post #31
grzm wrote: post #30

Earlier quoted context omitted.

One doesn’t need to be wedded to diagrams one works out up front. Doing a bit of design upfront can be useful in fleshing out ideas. Whether that’s in UML, sequence diagrams, stories, or just some sketches on a whiteboard, or some notes on paper, what one does with them is up to the team. It need not determine everything that follows. You point out all of this yourself upthread.

Yes exactly. Pointing a development effort towards a goal or in some direction is a very different thing from an Enterprise Architect dropping a bible of UML on a team.

It sounds like the problem is the rigid adherence to the original design, not UML itself.

Good, okay. I was worried that, because I liked drawing UML diagrams, I was somehow a bad engineer! Just keep being flexible, and I'll be in good shape.

Just last week I deleted a whole bunch of boxes on a UML diagram I had drawn because someone suggested a simpler approach.

Re: All You Need to Know About UML Diagrams

#35

Post by GorgeRonde »

Some thoughts I've had on "graphical based programming" (if UML can be deemed as such):

- Don't draw the product. Draw the organization that produces it. As per Conway's law, you'll be drawing the same thing in the end, but contrary to UML you won't face the problem of the representation of the product evolving faster than the ability of the organization to update it. The representation (the diagram) will just evolve as fast as the organization can represent itself. This require that:

- The diagram is the organization and the fundamental aspect of code is UI. There is no distinction between the primitives of the UI/UX system (clicking on that, moving this item from here to there, etc ...) and its computational primitives. This is the tipping-point that:

  - a) makes this system homoiconic
  
  - b) makes this system homoschematic.
Homoschematicity (same-representation/same-gesture in ancient Greek) is reached when the datastructure that is set in immediate relation to itself (typically lists in Lisp) is also what is directly presented to the end user and can be displayed as such, ie. immediately (lisp code is too ugly and limited for that).

Re: All You Need to Know About UML Diagrams

#36

Post by vram22 »

blattimwind wrote: post #23
vram22 wrote: post #20

Earlier quoted context omitted.

When UML was more popular at the height of the OO(AD) frenzy, there was a tool from Peter Coad's company called TogetherJ. IIRC it could do round-tripping between UML and Java code. I think I tried the tool out but not that feature. TogetherSoft was later acquired by Borland, as I remember.

In IntelliJ you can refactor from UML views.

Interesting, will check that out.
Post reply on HN