4 ms·

What would be better? Change tools every 3-5 years like the industry does, so by the time any given instructor actually has a grasp on a particular tool or para

What would be better? Change tools every 3-5 years like the industry does, so by the time any given instructor actually has a grasp on a particular tool or paradigm, its already obsolete (or at least fallen out of fashion) too? I'm no fan of UML, but the exercise is to teach students how to plan, how to express that plan, and how to reason about other people's plans. The students will certainly draw a lot of flow diagrams in their careers, and will almost certainly deal with fussy micromanagers who demand their flow diagrams adhere to some arbitrary schema that has only limited impact on the actual quality of their work or documentation. UML is complete, at least.

failbuffer 3y ago
A whiteboard is complete. Every other way of diagramming software is deficient. Change my mind. ;-)
- master-lincoln 3y ago
  A whiteboard is just a medium to draw. Uml is a standard that says how to express certain ideas as symbols that can be drawn. It's not clear to me what your argument is. Is it using whiteboards to draw uml instead of special uml software? If so, be prepared to take much longer to draw the diagram. Or do you mean uml is deficient compared to free drawing of symbols on a whiteboard without a standard? If so, be prepared that nobody will completely understand your diagram without explanation
  - OnlyMortal 3y ago
    UML is just the common parlance so that we all understand what’s represented. No need for a specific tool - unless you’re doing PowerPoint slides. Visio is good enough in that case if you have Windows.
- petsfed 3y ago
  Great! So, do you bring your whiteboard to lecture to turn in, or take a picture of it, or just schedule time with your professor to whiteboard in front of them? All I'm arguing for here is that UML serves the same purpose as those online homework apps. Correctly formatting your calculus homework to be accepted by that interface is as unrelated to calculus as UML mastery is to effective software design, but it resolves some of the same logistical challenges, while introducing others.
Kamq 3y ago
> Change tools every 3-5 years like the industry does, so by the time any given instructor actually has a grasp on a particular tool or paradigm, its already obsolete (or at least fallen out of fashion) too? I mean, yeah. Seeing that wave happen over the course of their college career would probably be better prep for a career than most CS classes.
__loam 3y ago
I haven't seen a UML diagram once in 7 years of working. The approach presented in the book "a philosophy of Software Design" is much better than the outdated bullshit from the 90s.
- rvdginste 3y ago
  I never got the hate against UML. To me, UML is just a language to communicate about several aspects of a technical design, and to visualize a technical design to make it easier to reason about it. I did not read the book "a philosophy of software design", but I just scanned the table of contents, and it is not clear to me how "a philosophy of software design" contradicts with using UML. Are you telling me that in those 7 years of working, you never once used a class diagram? Or a database diagram? Or an activity diagram, deployment diagram, sequence diagram, state diagram? I find that hard to believe... how do you explain your design to other people in the team? Or do you mean that you do make that kind of diagrams, but just use your own conventions instead of following the UML standard? Personally, I often use UML diagrams when I am working on a technical design and I use those diagrams to discuss the design with the team. On almost every project I create a class diagram for all entities in the system. I rarely make a database diagram because that often is a direct translation of the class diagram. For some of the more complex flows in the system, I create an activity diagram. For stuff that goes through state transitions, I create state diagrams. In my case, this really helps me to reason about the design and improve the design. And all those diagrams are also very useful to explain the whole software system to people who are new on the project. That does not mean that my diagrams are always strictly UML-compliant or that I make a diagram for every little piece in the software system. The goal is not to have UML-compliant diagrams, but to efficiently communicate the technical design to other people, and UML is nice for this because it is a standard.
  - PeterisP 3y ago
    UML is a tool to do something (namely, formal and detailed specification of systems) that in many places nowadays isn't really done. I think it is totally plausible that over 7 years of professional work OP has never been in a situation where one person has made a detailed design and wants to present it in a formal manner to other people in the team using diagrams (as opposed to answering specific questions of "what does this particular thing in the code do"). If they discuss the process, they tell about the process without using an activity diagram. If someone wants to view a database diagram, they use some tool that autogenerates one from the data, and discards it after viewing instead of attempting to maintain it as a formal documentation. I agree that all those diagrams are also very useful to explain the whole software system to people who are new on the project, however, that doesn't imply that having this ability is common, many (IMHO most, but I don't have the data) companies intentionally don't put in the time and effort to maintain such up to date diagrams for their systems.

failbuffer 3y ago

A whiteboard is complete. Every other way of diagramming software is deficient. Change my mind. ;-)

master-lincoln 3y ago
A whiteboard is just a medium to draw. Uml is a standard that says how to express certain ideas as symbols that can be drawn. It's not clear to me what your argument is. Is it using whiteboards to draw uml instead of special uml software? If so, be prepared to take much longer to draw the diagram. Or do you mean uml is deficient compared to free drawing of symbols on a whiteboard without a standard? If so, be prepared that nobody will completely understand your diagram without explanation
- OnlyMortal 3y ago
  UML is just the common parlance so that we all understand what’s represented. No need for a specific tool - unless you’re doing PowerPoint slides. Visio is good enough in that case if you have Windows.
petsfed 3y ago
Great! So, do you bring your whiteboard to lecture to turn in, or take a picture of it, or just schedule time with your professor to whiteboard in front of them? All I'm arguing for here is that UML serves the same purpose as those online homework apps. Correctly formatting your calculus homework to be accepted by that interface is as unrelated to calculus as UML mastery is to effective software design, but it resolves some of the same logistical challenges, while introducing others.

Kamq 3y ago

> Change tools every 3-5 years like the industry does, so by the time any given instructor actually has a grasp on a particular tool or paradigm, its already obsolete (or at least fallen out of fashion) too? I mean, yeah. Seeing that wave happen over the course of their college career would probably be better prep for a career than most CS classes.

__loam 3y ago

I haven't seen a UML diagram once in 7 years of working. The approach presented in the book "a philosophy of Software Design" is much better than the outdated bullshit from the 90s.

rvdginste 3y ago
I never got the hate against UML. To me, UML is just a language to communicate about several aspects of a technical design, and to visualize a technical design to make it easier to reason about it. I did not read the book "a philosophy of software design", but I just scanned the table of contents, and it is not clear to me how "a philosophy of software design" contradicts with using UML. Are you telling me that in those 7 years of working, you never once used a class diagram? Or a database diagram? Or an activity diagram, deployment diagram, sequence diagram, state diagram? I find that hard to believe... how do you explain your design to other people in the team? Or do you mean that you do make that kind of diagrams, but just use your own conventions instead of following the UML standard? Personally, I often use UML diagrams when I am working on a technical design and I use those diagrams to discuss the design with the team. On almost every project I create a class diagram for all entities in the system. I rarely make a database diagram because that often is a direct translation of the class diagram. For some of the more complex flows in the system, I create an activity diagram. For stuff that goes through state transitions, I create state diagrams. In my case, this really helps me to reason about the design and improve the design. And all those diagrams are also very useful to explain the whole software system to people who are new on the project. That does not mean that my diagrams are always strictly UML-compliant or that I make a diagram for every little piece in the software system. The goal is not to have UML-compliant diagrams, but to efficiently communicate the technical design to other people, and UML is nice for this because it is a standard.
- PeterisP 3y ago
  UML is a tool to do something (namely, formal and detailed specification of systems) that in many places nowadays isn't really done. I think it is totally plausible that over 7 years of professional work OP has never been in a situation where one person has made a detailed design and wants to present it in a formal manner to other people in the team using diagrams (as opposed to answering specific questions of "what does this particular thing in the code do"). If they discuss the process, they tell about the process without using an activity diagram. If someone wants to view a database diagram, they use some tool that autogenerates one from the data, and discards it after viewing instead of attempting to maintain it as a formal documentation. I agree that all those diagrams are also very useful to explain the whole software system to people who are new on the project, however, that doesn't imply that having this ability is common, many (IMHO most, but I don't have the data) companies intentionally don't put in the time and effort to maintain such up to date diagrams for their systems.