4 ms·

"Their stated goal was to no longer have to write any code in house, but rather nothing but UML" This goal was promoted heavily in the late '90s and early '00s

by smoyer 11y ago

"Their stated goal was to no longer have to write any code in house, but rather nothing but UML" This goal was promoted heavily in the late '90s and early '00s. Some tools could supposedly "round-trip" between UML and code, but I never saw that actually work. As originally conceived, UML was supposed to foster communication and there are times when a UML diagram is the perfect means to communicate the intent. I tend to use sequence diagrams and ER diagrams the most (yes - I know ER diagrams aren't UML but they're roughly analogous to class diagrams and what we're usually trying to flesh out is the relationship between models). As an aside, there were/are graphical programming languages. I wrote a couple of Windows and Mac utilities in ProGraph [1] during the '90s. The ProGraph environment lives on as Marten [2] which I recently played with on Linux. It's not nearly as clean as I remember it being. [1] https://en.wikipedia.org/wiki/Prograph https://en.wikipedia.org/wiki/Prograph [2] http://www.andescotia.com/products/marten/ http://www.andescotia.com/products/marten/

nine_k 11y ago
There are two types if UML diagrams I willingly used: sequence diagrams and deployment diagrams. ER diagrams are super useful, too.
- detaro 11y ago
  Do you have link to an example of a "realistic"/real-world deployment diagrams? In my courses they always looked quite silly and useless, but I wouldn't be surprised if that's due to bad examples...
  - noxToken 11y ago
    It can be hard to convey the proper use of a technology/framework in academia when there is not a lot of background to work with. I felt the same about unit testing (shouldn't you know how your code works?) and UML diagrams (shouldn't you know the class/object relationships?) as well. They're all bigger picture than that. The point at which I started to realize the usefulness of diagrams was when I started working on projects that were more than a few hours worth of coding (my first internship). UML provides a way to visually represent how your code will both relate to itself (classes, interfaces, objects) and the overall project to both the developer AND the business analysts who have no idea what inheritance or polymorphism mean. I've included an early draft of a piece of a rather large data model. It won't mean anything to you without the overall diagram, but you see some relationships between the customer's account, application and product: http://s18.postimg.org/gxfkjytft/diag.png http://s18.postimg.org/gxfkjytft/diag.png You probably had an example like grocery store checkout software, hotel booking software, or library cataloging software. A UML diagram can show to everyone all the possible routes a customer can take such at starting points, ending points, resume milestones, activities that are and are not allowed, transient and permanent data and everything in between. This all applies to the academic scenarios listed above, but it's more in depth (likely) than an assignment that you'll have when learning about UML. Just keep in mind that large project will have multiple developers of varying expertise with business people who likely cannot write "Hello World!" in any language. UML attempts to bridge the gap between you, your superiors, your subordinates, and the non-tech side of the project.
pjc50 11y ago
> UML was supposed to foster communication > could supposedly "round-trip" between UML and code, but I never saw that actually work This is the root of the problem with UML-as-spec: it's used as a tool for one-way communication, for open-loop management that doesn't want to have feedback or dialogue stages in development.
- feider 11y ago
  I think this is the real problem with UML. It first kinda seems to work when project is managed with waterfall-style, but when actual development is done iteratively (when is it not?) it just adds confusion or work either by providing out-of-date spec or introducing more stuff to keep in sync.
  - jschwartzi 11y ago
    If you have a problem with out of date documentation, I think you might have a problem with the development team rather than the documentation. If you don't think the documentation is useful, please get rid of it. But blaming UML for your documentation problems is like blaming English for forcing you to rewrite comments that no longer make sense. My sense is that people associate bad processes and bad teams with the tools that they were using. Crappy tools exist, and people have had some pretty dumb ideas about how to use UML, but is useful as a way to express aspects of your design that may lend themselves to a more object-oriented approach. This is something for which no other widespread diagramming language exists. Whether you're using an iterative or waterfall approach, at some point it is necessary to provide some context for your software units, like explaining how they are associated or what their areas of responsibility are. That's all the documentation does.
  - mpdehaan2 11y ago
    UML is a way to talk about things. Just having a standard-ish way to draw on whiteboards is pretty helpful, even if the diagrams are super temporary. In practice in most industries, most folks can probably get away with just knowing the ISA/HASA type stuff and 1..N, * arrity, etc. Swimlanes are also somewhat useful as a concept (but so are regular flowcharts). There's a whole other ton of UML (see 5/7th of Rational Rose around the early 2000s, which is probably gone all deep and crazy now, etc) that is, IMHO, pretty skippable. I've not even seen some of the "stuff you have to know" (ball and socket, etc) used. I do think that designs get better when you can draw them, as when they get hard to draw, it becomes conceptually obvious there may be problems. UML generation code tools running against 1300+ Java classes and making some huge diagram covered up in arrows definitely doesn't work too well though :)
Marazan 11y ago
Together J had always in sync Code and UML. It was a really neat IDE.
mml 11y ago
Sequence diagrams are quite useful, static diagrams, not so much. I only find myself drawing them if I'm trying to do a necropsy to figure out hosed up object relationships. The other useful diagram tfa doesn't cover is the finite state machine diagram. Handy, plus, they look cool. As an aside, I find it's much, much easier to do with pen & paper than in any tool i've ever used (looking at you omnigraffle & visio!)

by smoyer 11y ago

nine_k 11y ago

There are two types if UML diagrams I willingly used: sequence diagrams and deployment diagrams. ER diagrams are super useful, too.

detaro 11y ago
Do you have link to an example of a "realistic"/real-world deployment diagrams? In my courses they always looked quite silly and useless, but I wouldn't be surprised if that's due to bad examples...
- noxToken 11y ago
  It can be hard to convey the proper use of a technology/framework in academia when there is not a lot of background to work with. I felt the same about unit testing (shouldn't you know how your code works?) and UML diagrams (shouldn't you know the class/object relationships?) as well. They're all bigger picture than that. The point at which I started to realize the usefulness of diagrams was when I started working on projects that were more than a few hours worth of coding (my first internship). UML provides a way to visually represent how your code will both relate to itself (classes, interfaces, objects) and the overall project to both the developer AND the business analysts who have no idea what inheritance or polymorphism mean. I've included an early draft of a piece of a rather large data model. It won't mean anything to you without the overall diagram, but you see some relationships between the customer's account, application and product: http://s18.postimg.org/gxfkjytft/diag.png http://s18.postimg.org/gxfkjytft/diag.png You probably had an example like grocery store checkout software, hotel booking software, or library cataloging software. A UML diagram can show to everyone all the possible routes a customer can take such at starting points, ending points, resume milestones, activities that are and are not allowed, transient and permanent data and everything in between. This all applies to the academic scenarios listed above, but it's more in depth (likely) than an assignment that you'll have when learning about UML. Just keep in mind that large project will have multiple developers of varying expertise with business people who likely cannot write "Hello World!" in any language. UML attempts to bridge the gap between you, your superiors, your subordinates, and the non-tech side of the project.

pjc50 11y ago

> UML was supposed to foster communication > could supposedly "round-trip" between UML and code, but I never saw that actually work This is the root of the problem with UML-as-spec: it's used as a tool for one-way communication, for open-loop management that doesn't want to have feedback or dialogue stages in development.

feider 11y ago
I think this is the real problem with UML. It first kinda seems to work when project is managed with waterfall-style, but when actual development is done iteratively (when is it not?) it just adds confusion or work either by providing out-of-date spec or introducing more stuff to keep in sync.
- jschwartzi 11y ago
  If you have a problem with out of date documentation, I think you might have a problem with the development team rather than the documentation. If you don't think the documentation is useful, please get rid of it. But blaming UML for your documentation problems is like blaming English for forcing you to rewrite comments that no longer make sense. My sense is that people associate bad processes and bad teams with the tools that they were using. Crappy tools exist, and people have had some pretty dumb ideas about how to use UML, but is useful as a way to express aspects of your design that may lend themselves to a more object-oriented approach. This is something for which no other widespread diagramming language exists. Whether you're using an iterative or waterfall approach, at some point it is necessary to provide some context for your software units, like explaining how they are associated or what their areas of responsibility are. That's all the documentation does.
- mpdehaan2 11y ago
  UML is a way to talk about things. Just having a standard-ish way to draw on whiteboards is pretty helpful, even if the diagrams are super temporary. In practice in most industries, most folks can probably get away with just knowing the ISA/HASA type stuff and 1..N, * arrity, etc. Swimlanes are also somewhat useful as a concept (but so are regular flowcharts). There's a whole other ton of UML (see 5/7th of Rational Rose around the early 2000s, which is probably gone all deep and crazy now, etc) that is, IMHO, pretty skippable. I've not even seen some of the "stuff you have to know" (ball and socket, etc) used. I do think that designs get better when you can draw them, as when they get hard to draw, it becomes conceptually obvious there may be problems. UML generation code tools running against 1300+ Java classes and making some huge diagram covered up in arrows definitely doesn't work too well though :)

Marazan 11y ago

Together J had always in sync Code and UML. It was a really neat IDE.

mml 11y ago

Sequence diagrams are quite useful, static diagrams, not so much. I only find myself drawing them if I'm trying to do a necropsy to figure out hosed up object relationships. The other useful diagram tfa doesn't cover is the finite state machine diagram. Handy, plus, they look cool. As an aside, I find it's much, much easier to do with pen & paper than in any tool i've ever used (looking at you omnigraffle & visio!)