10 ms·

All the UML you need to know

176 points by CaRDiaK 11y ago

vortico 11y ago
Yup, even if you never write OOP code, this is a somewhat common language you will encounter between colleagues, so it is worth knowing exactly what is on this page.
- arethuza 11y ago
  Personally, I find that the "closer" you get to code the less use formal detailed diagrams are - UML as sketch rather than UML as blueprint: http://martinfowler.com/bliki/UmlAsSketch.html http://martinfowler.com/bliki/UmlAsSketch.html
jmartinpetersen 11y ago
Key quote: "Keep in mind that UML is a communication tool, and you can omit details that are not necessary for expressing your message."
- Pamar 11y ago
  What about the parts that are necessary to express my message, but are not covered by UML? See: https://news.ycombinator.com/item?id=5876803 https://news.ycombinator.com/item?id=5876803
- k__ 11y ago
  Haha, yes. All the "Software Engineering" classes at university were just UML. Many years I thought SE was just that, UML. When I did my first job interview I was rather relieved that the hiring manager wanted me to draw UML. He was very pleased with my UML skills, but he always said, I shouldn't draw it with all the details, just the basics are enough :D That was 2011... I never had to use UML in an interview again. But I often used it as a documentation tool for a big PHP codebase, I had to manage. UML and ER diagrams are often an overkill when designing an app. But they are nice to visualize what is going on in legacy stuff.
cjg 11y ago
I've generally found UML to be a complete waste of time. I'd rather outline the major components of a system by drawing (on real paper) simple boxes and lines, or write the code that implements the system. Not sure what code-as-picture achieves - it's generally has worse tooling (less editable, less versionable, etc.) and tends to be used by 'architects' who don't write code, only for that UML to be essentially ignored by the coders on the ground.
- mironathetin 11y ago
  "I've generally found UML to be a complete waste of time." This!
- arethuza 11y ago
  I've found that diagrams generated from code or APIs can be useful sometimes - Graphviz is great for that. But I never really go beyond "simple boxes and lines" myself when sketching things.
- jeremysmyth 11y ago
  As long a the "simple boxes and lines" describe the functionality of your design at the level you wish to communicate, then you're doing good. You can stop reading here. The problem is that complex systems need complex design. As your design get more sophisticated, you need more sophisticated ways to communicate the design. Concepts like dependency, multiplicity, inheritance, inclusion, asynchronous message, exception, timed event are all things you can represent with boxes and lines, but unless you adorn the diagram with a huge amount of text you're not going to capture the distinctions between those different types of relationship. It's not unlike any other language: I can use the word thought to describe something in my head that isn't physically manifested, but words like lie, memory, hypothesis, idea, belief, image, nostalgia, forecast, imagination are all used to distinguish between types of thoughts. If I used only simple words like "thought" then I wouldn't be able to express anything more sophisticated while still being concise. In short, if you want to graphically describe something complex, you can either use a sophisticated visual language to do it concisely and unambiguously, or you can use a simple visual language and write tonnes of documentation to support it, with all the problems of attention, ambiguity, and rot that go along with it.
m_fayer 11y ago
My first real-world job in the industry was in a large-ish shop that worked as follows: Create a full-detail schematic of the system in version-controlled UML. At some point, "deploy" the UML by printing it into a 4 cm-thick binder of paper, then distribute these binders to the head architects. Iterate on the UML until the architects are happy. (The architects spent many years trying to auto-generate code from the UML diagrams and have the results "fleshed out" by lowest-bidder consultants, though this never really worked. Their stated goal was to no longer have to write any code in house, but rather nothing but UML.) Begin implementing the system in house with auto-generated code from the binder-of-UML as a baseline, after the lowest-bidder consultants had failed. Quickly get into big fights between the coders-on-the-ground and management when it was found that the UML diagrams contained major architectural flaws and the UML-phase would not, actually, account for 80% of the project's duration and budget. Needless to say, more than half of the projects failed entirely. This experience nearly made me leave the industry, before I discovered that there was plenty of software being written in a saner way. This was more than a decade ago, but to this day, just seeing UML diagrams turns my stomach.
- arethuza 11y ago
  I had a similar experience about 12 years ago - turned out the company in question simply used their UML based methodology as a sales tool. Projects never actually worked that way in reality - what they said they did and what they actually did were completely different. Once I realised that the development process was actually perfectly OK and nobody actually looked at the UML I was fine.... ;-)
  - henrik_w 11y ago
    I was developing SW in the 1990s (before XP, then Agile, become popular), and we were supposed to use UML, Rational Rose etc. However, that was how it was supposed to work, not how it actually worked. The biggest relief in starting to use XP was that the methodology described how we actually worked, not how we were supposed to work.
    - crdoconnor 11y ago
edpichler 11y ago
Plot twist: this article doesn't have all the UML you need to know, it's just the class diagram. Particularly, for my personal projects, I use the Use Cases diagram to map the requirements and the features my application will have, associated with my prototypes. Other diagrams, like Class diagram, usually I use just to map the Domain before develop the persistence. This is how all my projects start, even if I am working alone. It is good to me and it's part of my creative process.
saiki 11y ago
Personally I use quite a lot sketch like UML and find it very helpful for clarifying complex environments or ideas that are not clear yet. Most of the time sketches are just boxes, circles and lines, but those communicates and clarifies the problem for others very well. I don't use lot of time when sketching, system can be described graphically very quickly, just to get the idea out or it usually goes too detailed. We have also built a tool that helps sketching systems with remote teammates (https://sketchboard.me https://sketchboard.me).
- Pamar 11y ago
  Are you sure you are not actually using dataflow diagrams by another name? http://www.visual-paradigm.com/tutorials/data-flow-diagram-example-food-ordering-system.jsp http://www.visual-paradigm.com/tutorials/data-flow-diagram-e...
jasode 11y ago
Diagrams/notation I've found useful: ++ E-R (entity-relationship) diagrams. I find it easier to look at boxses for each table follow the lines signifying relationships to other boxes. The "crows feet" can signify 1-to-many. The diagram is easier than reading a sequential list of SQL CREATE TABLE statements and making a mental note of "FOREIGN KEY" strings and mentally backtracking to the parent table. ++ swim lanes to show how the "state" of a system is supposed to change with "time". This can succinctly show how data "flows" without having to actually run a program and watch variables in a debugger to manually recreate the "swim lane" in your head. ++ truth tables to summarize combinations of valid/invalid business rules and associated side effects. A grid is easier than parsing a long (and often nested) list of if/then/else/switch statements. As for UML, the notation never seems to be that succinct or helpful to me. On the surface level, it seems that UML (for code) should have the same return-on-investment as E-R (for db tables) but it doesn't in my experience. I also wonder if there is a cultural component to UML usage. It doesn't seem like tech companies (such as Microsoft/Google/Amazon/Ubisoft/etc) internally use UML as a prerequisite step for building systems. On the other hand, I could see more UML usage at non-tech companies (such as banks/manufacturing/government) building line-of-business CRUD apps. Grady Booch (Booch & UML notation) did consulting about software methodology at non-tech companies so that may have been a factor.
cubano 11y ago
I've never figured out how to use UML abstractions to fix client and/or user production bugs, or met anyone else who could, so who the hell has the time?
mark_l_watson 11y ago
Too bad he skipped sequence diagrams, saying that he had already covered them in class. Years ago I co-authored a book on UML, but the only UML diagrams that I still use are sequence diagrams which I think are great for explaining interactions between objects or separate services.
omellet 11y ago
This should have linked to a blank page.
DanielBMarkham 11y ago
I love UML. UML is overused. More people need to know UML. The less UML you do, the better. I believe all of these statements to be true. I had a contract many years ago with a large insurer. Their development process basically consisted of drawing really complex UML diagrams, then hitting the Big Red Button and having the modeling tool generate 40,000 lines of framework code. The chief architect explained to me that really the only work required was just a tiny bit of business logic in the appropriate places. Fortunately I was not part of the main dev team, which for some strange reason (at least in the lead architect's mind) had the damnedest time with this system. My job was to create an internal permissions system. Given app X, user Y, and action Z, was the action allowed or not. I looked at the problem for a while, and no matter how I thought about it, to me I had three lookup tables and one method. Boom, I'm done. The lead architect wanted me to still draw a diagram with one class, push the button, and get the 40,000 lines of code. For some reason, this did not appeal to me. Took me about 3 weeks to convince him that really 20 lines or so of code was all we needed. I still had to draw the diagram, though. That's the horror story -- one among dozens I have. But on the flip side, I've been with teams that interviewed the customer while sketching out a domain model. Since we all understood UML, a quick and lightweight sketch using the appropriate notation got agreement on a ton of detail just taking 30 minutes or so. That would have been very difficult using a conversation or word processor. Sketching without some common lightweight understanding could have led to rookie errors. There is nothing in this world better for getting quick technical agreement on complex problems than group sketching using lightweight UML. The trick is sticking to the absolute minimum.
- vladsanchez 11y ago
  One of the most productive comments on this thread. Thanks. ;-)
- arandomJohn 11y ago
  I agree. Ten to fifteen years ago I saw stream of UML horror stories. The tools were expensive, complex, and you never needed or wanted 90% of what they could do. But PM's loved to show a stack of paperwork to the client. Now something like Lucidchart is a great way to knock out some swim lanes or ER diagrams without the nonsense of automatically generated code. You can use the diagrams to get your team and the client on the same page without UML becoming a religion.
agentgt 11y ago
I'm just curious and I'm not trying to be snide but is there any spec that OMG has produced that people actually like and use still? (they are also makers of CORBA) I live in the Boston rt128 area and I pass OMG's building all the time and I just have no idea how they are still in business (they are near Trip Advisors new complete awesome building). I wonder how many massive companies continuously donate to OMG and do not realize it.
CrLf 11y ago
The general feeling about UML is that it's overkill for most projects and actively harmful when used to generate code. On the other hand, most agree that parts of UML are useful as communication tools. However, UML was designed as a standard, near-UML is not UML. Ergo, UML is useless. I feel better already.
skrebbel 11y ago
The complete overapplication of UML for many years gave UML an undeservedly bad name. The top comments in this thread are testament to that: many programmers are simply all too happy to go "haha! UML! that's for enterprise losers in suits who prefer paper over working code!" Thing is, the core elements of UML are very useful in communicating a design or an idea. Class diagrams are a great way to discuss an OO-ish codebase in front of a whiteboard (or any data model, really). When you do that, it really helps when everybody knows that an arrow in static UML diagram types means "dependency" and not "the data flows from here to there". Similarly, I still haven't seen a better way to visualise state than with a UML state chart. It's also very nice if you can draw a UML object diagram that people understand (looks like a class diagram, except you basically draw a hypothetical runtime situation of instantiated classes and you underline the object identifier names). This works best when people understand that the picture on the left is a class diagram (design time) and the one on the right is an object diagram (runtime example) of the same classes. This is not complicated stuff, but it doesn't really work as well when half the team thinks UML is for losers. Now, bear with me, I'll be the first to agree, UML is a bloated piece of shit. Package diagrams, wtf, who needs that? Use case diagrams that show which use cases are specified, instead of how the use cases go - seriously? Activity diagrams so you can draw a 5-line method on an entire sheet of paper, big fucking what the hell were you guys thinking?? Why do I even know what this stuff is? What a waste of time - even the decent diagram types have 60% bullshit syntax and only 40% useful stuff. And message sequence charts are nice enough for protocols but impossible to draw right. But to dismiss UML just because some enterprise architects went a little overboard in 2002 is a bit like dismissing all of OOP because 15-level inheritance hierarchies used to be hip. I wish we could agree on a tiny subset of UML that actually makes sense, and all learn that. This post makes a good start for class diagrams, although IMO even the ball-and-socket notation is overblown nonsense from a time long gone. Maybe we should do this, and give it a separate name. On a mildly related note, one thing I like about OOP is that you can draw pictures of it easily. Does anyone here know of a good way to visualize functional code structure? You can draw a dependency chart of modules of functions but that only gets you so far.
- danmaz74 11y ago
  After many many years not touching UML, I recently had to design some state charts - because it's something really helpful in an app we're working on at the moment - and found that using an UML tool for that is very useful. So I agree that it's something good, if taken with a big grain of salt.
putzdown 11y ago
No, all the UML you need to know is this: (1) draw and label a box for each class; (2) draw an arrow from one class to another to show dependency; (3) draw a different kind of arrow from one class to another to show inheritance; (4) [bonus material, for super-geniuses like you] use regex-style symbols * , +, 1 and suchlike to mark the ends of dependency arrows in order to indicate when you have one-to-one or one-to-many relationships and so forth. There. My 20+ years of experience in software architecture in various fields from games to networking tells me that you now know enough to work out the classes and their relationships in a large software system. Don't fuss around with "aggregation" or "composition" or whatever. Don't spell out functions (though occasionally I'll jot one below a line to remind myself what the salient feature of the dependency is). And by no means write the class properties, their types, or their access specifiers (public, protected...)—this is way too much detail. A UML diagram is useful in modeling broad object relationships in a system. If you want to work out what properties a class should have, write the damn class. Any software developer worth his salt can figure out the code from a high-level diagram; don't write the code for him. Or do, but then don't call it an architectural diagram. I know there's a whole culture of software development where architects design code but don't dirty their hands with writing it, then hand it off to underlings who type it up for them, and so on down some kind of techno-bureaucracy Great Chain of Being. Rubbish. Code architecture is a thing and some kind of diagramming is helpful, but UML as such is the sort of busywork and IRS-style hierarchism that marks bloated government jobs, not real productivity or real teamwork. Give UML a miss and use something very, very simple.
makecheck 11y ago
Just think of UML as the C++ of diagrams: it is sometimes the best way to produce the result that you need but you have to choose a sane subset.
lisper 11y ago
Graphical representations are useful for representing spatial relationships because then you can take advantage of the inverse-GPU in the human visual cortex to do a lot of computation for you. But software doesn't have spatial relationships because it doesn't exist in space. So trying to represent software concepts graphically is generally doomed to fail. There are a few exceptions, like code indentation, but there's a reason that flowcharts aren't used much any more.
crocal 11y ago
All the UML I need to know? Frankly? Nothing. I am surprised people would still consider this thing useful.

176 points by CaRDiaK 11y ago

Yup, even if you never write OOP code, this is a somewhat common language you will encounter between colleagues, so it is worth knowing exactly what is on this page.

arethuza 11y ago
Personally, I find that the "closer" you get to code the less use formal detailed diagrams are - UML as sketch rather than UML as blueprint: http://martinfowler.com/bliki/UmlAsSketch.html http://martinfowler.com/bliki/UmlAsSketch.html

jmartinpetersen 11y ago

Key quote: "Keep in mind that UML is a communication tool, and you can omit details that are not necessary for expressing your message."

Pamar 11y ago
What about the parts that are necessary to express my message, but are not covered by UML? See: https://news.ycombinator.com/item?id=5876803 https://news.ycombinator.com/item?id=5876803
k__ 11y ago
Haha, yes. All the "Software Engineering" classes at university were just UML. Many years I thought SE was just that, UML. When I did my first job interview I was rather relieved that the hiring manager wanted me to draw UML. He was very pleased with my UML skills, but he always said, I shouldn't draw it with all the details, just the basics are enough :D That was 2011... I never had to use UML in an interview again. But I often used it as a documentation tool for a big PHP codebase, I had to manage. UML and ER diagrams are often an overkill when designing an app. But they are nice to visualize what is going on in legacy stuff.

cjg 11y ago

I've generally found UML to be a complete waste of time. I'd rather outline the major components of a system by drawing (on real paper) simple boxes and lines, or write the code that implements the system. Not sure what code-as-picture achieves - it's generally has worse tooling (less editable, less versionable, etc.) and tends to be used by 'architects' who don't write code, only for that UML to be essentially ignored by the coders on the ground.

mironathetin 11y ago
"I've generally found UML to be a complete waste of time." This!
arethuza 11y ago
I've found that diagrams generated from code or APIs can be useful sometimes - Graphviz is great for that. But I never really go beyond "simple boxes and lines" myself when sketching things.
jeremysmyth 11y ago
As long a the "simple boxes and lines" describe the functionality of your design at the level you wish to communicate, then you're doing good. You can stop reading here. The problem is that complex systems need complex design. As your design get more sophisticated, you need more sophisticated ways to communicate the design. Concepts like dependency, multiplicity, inheritance, inclusion, asynchronous message, exception, timed event are all things you can represent with boxes and lines, but unless you adorn the diagram with a huge amount of text you're not going to capture the distinctions between those different types of relationship. It's not unlike any other language: I can use the word thought to describe something in my head that isn't physically manifested, but words like lie, memory, hypothesis, idea, belief, image, nostalgia, forecast, imagination are all used to distinguish between types of thoughts. If I used only simple words like "thought" then I wouldn't be able to express anything more sophisticated while still being concise. In short, if you want to graphically describe something complex, you can either use a sophisticated visual language to do it concisely and unambiguously, or you can use a simple visual language and write tonnes of documentation to support it, with all the problems of attention, ambiguity, and rot that go along with it.

m_fayer 11y ago

My first real-world job in the industry was in a large-ish shop that worked as follows: Create a full-detail schematic of the system in version-controlled UML. At some point, "deploy" the UML by printing it into a 4 cm-thick binder of paper, then distribute these binders to the head architects. Iterate on the UML until the architects are happy. (The architects spent many years trying to auto-generate code from the UML diagrams and have the results "fleshed out" by lowest-bidder consultants, though this never really worked. Their stated goal was to no longer have to write any code in house, but rather nothing but UML.) Begin implementing the system in house with auto-generated code from the binder-of-UML as a baseline, after the lowest-bidder consultants had failed. Quickly get into big fights between the coders-on-the-ground and management when it was found that the UML diagrams contained major architectural flaws and the UML-phase would not, actually, account for 80% of the project's duration and budget. Needless to say, more than half of the projects failed entirely. This experience nearly made me leave the industry, before I discovered that there was plenty of software being written in a saner way. This was more than a decade ago, but to this day, just seeing UML diagrams turns my stomach.

arethuza 11y ago
I had a similar experience about 12 years ago - turned out the company in question simply used their UML based methodology as a sales tool. Projects never actually worked that way in reality - what they said they did and what they actually did were completely different. Once I realised that the development process was actually perfectly OK and nobody actually looked at the UML I was fine.... ;-)
- henrik_w 11y ago
  I was developing SW in the 1990s (before XP, then Agile, become popular), and we were supposed to use UML, Rational Rose etc. However, that was how it was supposed to work, not how it actually worked. The biggest relief in starting to use XP was that the methodology described how we actually worked, not how we were supposed to work.
  - crdoconnor 11y ago

edpichler 11y ago

Plot twist: this article doesn't have all the UML you need to know, it's just the class diagram. Particularly, for my personal projects, I use the Use Cases diagram to map the requirements and the features my application will have, associated with my prototypes. Other diagrams, like Class diagram, usually I use just to map the Domain before develop the persistence. This is how all my projects start, even if I am working alone. It is good to me and it's part of my creative process.

saiki 11y ago

Personally I use quite a lot sketch like UML and find it very helpful for clarifying complex environments or ideas that are not clear yet. Most of the time sketches are just boxes, circles and lines, but those communicates and clarifies the problem for others very well. I don't use lot of time when sketching, system can be described graphically very quickly, just to get the idea out or it usually goes too detailed. We have also built a tool that helps sketching systems with remote teammates (https://sketchboard.me https://sketchboard.me).

Pamar 11y ago
Are you sure you are not actually using dataflow diagrams by another name? http://www.visual-paradigm.com/tutorials/data-flow-diagram-example-food-ordering-system.jsp http://www.visual-paradigm.com/tutorials/data-flow-diagram-e...

jasode 11y ago

Diagrams/notation I've found useful: ++ E-R (entity-relationship) diagrams. I find it easier to look at boxses for each table follow the lines signifying relationships to other boxes. The "crows feet" can signify 1-to-many. The diagram is easier than reading a sequential list of SQL CREATE TABLE statements and making a mental note of "FOREIGN KEY" strings and mentally backtracking to the parent table. ++ swim lanes to show how the "state" of a system is supposed to change with "time". This can succinctly show how data "flows" without having to actually run a program and watch variables in a debugger to manually recreate the "swim lane" in your head. ++ truth tables to summarize combinations of valid/invalid business rules and associated side effects. A grid is easier than parsing a long (and often nested) list of if/then/else/switch statements. As for UML, the notation never seems to be that succinct or helpful to me. On the surface level, it seems that UML (for code) should have the same return-on-investment as E-R (for db tables) but it doesn't in my experience. I also wonder if there is a cultural component to UML usage. It doesn't seem like tech companies (such as Microsoft/Google/Amazon/Ubisoft/etc) internally use UML as a prerequisite step for building systems. On the other hand, I could see more UML usage at non-tech companies (such as banks/manufacturing/government) building line-of-business CRUD apps. Grady Booch (Booch & UML notation) did consulting about software methodology at non-tech companies so that may have been a factor.

cubano 11y ago

I've never figured out how to use UML abstractions to fix client and/or user production bugs, or met anyone else who could, so who the hell has the time?

mark_l_watson 11y ago

Too bad he skipped sequence diagrams, saying that he had already covered them in class. Years ago I co-authored a book on UML, but the only UML diagrams that I still use are sequence diagrams which I think are great for explaining interactions between objects or separate services.

omellet 11y ago

This should have linked to a blank page.

DanielBMarkham 11y ago

I love UML. UML is overused. More people need to know UML. The less UML you do, the better. I believe all of these statements to be true. I had a contract many years ago with a large insurer. Their development process basically consisted of drawing really complex UML diagrams, then hitting the Big Red Button and having the modeling tool generate 40,000 lines of framework code. The chief architect explained to me that really the only work required was just a tiny bit of business logic in the appropriate places. Fortunately I was not part of the main dev team, which for some strange reason (at least in the lead architect's mind) had the damnedest time with this system. My job was to create an internal permissions system. Given app X, user Y, and action Z, was the action allowed or not. I looked at the problem for a while, and no matter how I thought about it, to me I had three lookup tables and one method. Boom, I'm done. The lead architect wanted me to still draw a diagram with one class, push the button, and get the 40,000 lines of code. For some reason, this did not appeal to me. Took me about 3 weeks to convince him that really 20 lines or so of code was all we needed. I still had to draw the diagram, though. That's the horror story -- one among dozens I have. But on the flip side, I've been with teams that interviewed the customer while sketching out a domain model. Since we all understood UML, a quick and lightweight sketch using the appropriate notation got agreement on a ton of detail just taking 30 minutes or so. That would have been very difficult using a conversation or word processor. Sketching without some common lightweight understanding could have led to rookie errors. There is nothing in this world better for getting quick technical agreement on complex problems than group sketching using lightweight UML. The trick is sticking to the absolute minimum.

vladsanchez 11y ago
One of the most productive comments on this thread. Thanks. ;-)
arandomJohn 11y ago
I agree. Ten to fifteen years ago I saw stream of UML horror stories. The tools were expensive, complex, and you never needed or wanted 90% of what they could do. But PM's loved to show a stack of paperwork to the client. Now something like Lucidchart is a great way to knock out some swim lanes or ER diagrams without the nonsense of automatically generated code. You can use the diagrams to get your team and the client on the same page without UML becoming a religion.

agentgt 11y ago

I'm just curious and I'm not trying to be snide but is there any spec that OMG has produced that people actually like and use still? (they are also makers of CORBA) I live in the Boston rt128 area and I pass OMG's building all the time and I just have no idea how they are still in business (they are near Trip Advisors new complete awesome building). I wonder how many massive companies continuously donate to OMG and do not realize it.

CrLf 11y ago

The general feeling about UML is that it's overkill for most projects and actively harmful when used to generate code. On the other hand, most agree that parts of UML are useful as communication tools. However, UML was designed as a standard, near-UML is not UML. Ergo, UML is useless. I feel better already.

skrebbel 11y ago

The complete overapplication of UML for many years gave UML an undeservedly bad name. The top comments in this thread are testament to that: many programmers are simply all too happy to go "haha! UML! that's for enterprise losers in suits who prefer paper over working code!" Thing is, the core elements of UML are very useful in communicating a design or an idea. Class diagrams are a great way to discuss an OO-ish codebase in front of a whiteboard (or any data model, really). When you do that, it really helps when everybody knows that an arrow in static UML diagram types means "dependency" and not "the data flows from here to there". Similarly, I still haven't seen a better way to visualise state than with a UML state chart. It's also very nice if you can draw a UML object diagram that people understand (looks like a class diagram, except you basically draw a hypothetical runtime situation of instantiated classes and you underline the object identifier names). This works best when people understand that the picture on the left is a class diagram (design time) and the one on the right is an object diagram (runtime example) of the same classes. This is not complicated stuff, but it doesn't really work as well when half the team thinks UML is for losers. Now, bear with me, I'll be the first to agree, UML is a bloated piece of shit. Package diagrams, wtf, who needs that? Use case diagrams that show which use cases are specified, instead of how the use cases go - seriously? Activity diagrams so you can draw a 5-line method on an entire sheet of paper, big fucking what the hell were you guys thinking?? Why do I even know what this stuff is? What a waste of time - even the decent diagram types have 60% bullshit syntax and only 40% useful stuff. And message sequence charts are nice enough for protocols but impossible to draw right. But to dismiss UML just because some enterprise architects went a little overboard in 2002 is a bit like dismissing all of OOP because 15-level inheritance hierarchies used to be hip. I wish we could agree on a tiny subset of UML that actually makes sense, and all learn that. This post makes a good start for class diagrams, although IMO even the ball-and-socket notation is overblown nonsense from a time long gone. Maybe we should do this, and give it a separate name. On a mildly related note, one thing I like about OOP is that you can draw pictures of it easily. Does anyone here know of a good way to visualize functional code structure? You can draw a dependency chart of modules of functions but that only gets you so far.

danmaz74 11y ago
After many many years not touching UML, I recently had to design some state charts - because it's something really helpful in an app we're working on at the moment - and found that using an UML tool for that is very useful. So I agree that it's something good, if taken with a big grain of salt.

putzdown 11y ago

No, all the UML you need to know is this: (1) draw and label a box for each class; (2) draw an arrow from one class to another to show dependency; (3) draw a different kind of arrow from one class to another to show inheritance; (4) [bonus material, for super-geniuses like you] use regex-style symbols * , +, 1 and suchlike to mark the ends of dependency arrows in order to indicate when you have one-to-one or one-to-many relationships and so forth. There. My 20+ years of experience in software architecture in various fields from games to networking tells me that you now know enough to work out the classes and their relationships in a large software system. Don't fuss around with "aggregation" or "composition" or whatever. Don't spell out functions (though occasionally I'll jot one below a line to remind myself what the salient feature of the dependency is). And by no means write the class properties, their types, or their access specifiers (public, protected...)—this is way too much detail. A UML diagram is useful in modeling broad object relationships in a system. If you want to work out what properties a class should have, write the damn class. Any software developer worth his salt can figure out the code from a high-level diagram; don't write the code for him. Or do, but then don't call it an architectural diagram. I know there's a whole culture of software development where architects design code but don't dirty their hands with writing it, then hand it off to underlings who type it up for them, and so on down some kind of techno-bureaucracy Great Chain of Being. Rubbish. Code architecture is a thing and some kind of diagramming is helpful, but UML as such is the sort of busywork and IRS-style hierarchism that marks bloated government jobs, not real productivity or real teamwork. Give UML a miss and use something very, very simple.

makecheck 11y ago

Just think of UML as the C++ of diagrams: it is sometimes the best way to produce the result that you need but you have to choose a sane subset.

lisper 11y ago

Graphical representations are useful for representing spatial relationships because then you can take advantage of the inverse-GPU in the human visual cortex to do a lot of computation for you. But software doesn't have spatial relationships because it doesn't exist in space. So trying to represent software concepts graphically is generally doomed to fail. There are a few exceptions, like code indentation, but there's a reason that flowcharts aren't used much any more.

crocal 11y ago

All the UML I need to know? Frankly? Nothing. I am surprised people would still consider this thing useful.