4 ms·

It is good to hear that UML has some uses, even if I had always assumed this was most applicable to larger teams or companies. Can you comment more on the spec

It is good to hear that UML has some uses, even if I had always assumed this was most applicable to larger teams or companies. Can you comment more on the specific parts of UML that your models used? I do tend to think of your 4 Cs as all the same, though. In my experience, a team is either working together effectively or it isn't, and either achieves all of those "Cs" or none of them. I would even add that, often, a team lead must forego the "consensus" and simply make a decision. (This can even be true when dealing with customer requirements; occasionally, a software architect's design decision ultimately delivers a better thing than what the customer technically specified.)

DanielBMarkham 17y ago
So just look at UML as a formal way of talking and you'll be fine. The secret here is that pictures can convey bandwidth much higher than words. If you understand that, then UML is just a way to draw pictures without ambiguity. For communication, a lot of times I'll be describing something to another programmer on the phone -- or he'll be describing it to me. As they talk, I jot down what I think he's saying in lighweight UML. Then I show it to him by email or webcam or something. It identifies a lot of discrepancies very quickly. For collaboration, many times in a group we'll tag-team a problem by drawing up our idea of what we think it looks like. Either we trade-off, or everybody draws separately, or one person leads until the group replaces him. For consensus-building, a lot of times you'll have a subcontractor or person who's remote who is proposing some kind of work for the team. They can do a stand-up, or a presentation, or whatever, but the key thing is usually when they communicate their technical solution in terms of a diagram. This is very useful when talking about how a screen should flow, for instance, or about how a third-party tool acts. For coordination, a lot of times external groups want to be "in the loop" but don't have time to attend meetings and don't want a lot of paperwork. A lot of times an email with a couple of pictures attached can give them the gist of what's going on technically without a 50-page doc being there. To differentiate between the Cs, ask yourself: is the communication two-way? One-way? Formal? Informal? Modeling is just a high-bandwidth version of talking, that's it. I can say more in a model in 10 minutes than I could in 4 hours of explaining. But, like every freaking thing else in software engineering, people become too attached to it and it has developed all these features that nobody needs. And so it gets abused. To specifically answer your question, class or domain models seem to work for a LOT of stuff. Sequencing is good at showing things in layers, and Activity Diagrams is just flowcharting on steriods. To give a concrete example of using them, many times when the team is estimating a story and isn't comfortable with the details, we'll take 15 minutes or so and sketch out an activity diagram of how it's supposed to work. That usually either fixes the problem or gives us more questions to go answer :)

DanielBMarkham 17y ago

So just look at UML as a formal way of talking and you'll be fine. The secret here is that pictures can convey bandwidth much higher than words. If you understand that, then UML is just a way to draw pictures without ambiguity. For communication, a lot of times I'll be describing something to another programmer on the phone -- or he'll be describing it to me. As they talk, I jot down what I think he's saying in lighweight UML. Then I show it to him by email or webcam or something. It identifies a lot of discrepancies very quickly. For collaboration, many times in a group we'll tag-team a problem by drawing up our idea of what we think it looks like. Either we trade-off, or everybody draws separately, or one person leads until the group replaces him. For consensus-building, a lot of times you'll have a subcontractor or person who's remote who is proposing some kind of work for the team. They can do a stand-up, or a presentation, or whatever, but the key thing is usually when they communicate their technical solution in terms of a diagram. This is very useful when talking about how a screen should flow, for instance, or about how a third-party tool acts. For coordination, a lot of times external groups want to be "in the loop" but don't have time to attend meetings and don't want a lot of paperwork. A lot of times an email with a couple of pictures attached can give them the gist of what's going on technically without a 50-page doc being there. To differentiate between the Cs, ask yourself: is the communication two-way? One-way? Formal? Informal? Modeling is just a high-bandwidth version of talking, that's it. I can say more in a model in 10 minutes than I could in 4 hours of explaining. But, like every freaking thing else in software engineering, people become too attached to it and it has developed all these features that nobody needs. And so it gets abused. To specifically answer your question, class or domain models seem to work for a LOT of stuff. Sequencing is good at showing things in layers, and Activity Diagrams is just flowcharting on steriods. To give a concrete example of using them, many times when the team is estimating a story and isn't comfortable with the details, we'll take 15 minutes or so and sketch out an activity diagram of how it's supposed to work. That usually either fixes the problem or gives us more questions to go answer :)