Is UML the correct language for making software blueprints?

Question

I was having a conversation last week with a coworker about architecture (real architecture, as in designing buildings). During our talk it came up that architectural blueprints give an architect, civil engineer, and contractor all the detail they need to build something. It got both of us thinking about the state of software engineering and that there is no universally adopted approach for describing the design of software.

We have UML, but I find that it is often hard to convey enough detail without the diagrams being overly complex. Are there good examples of large software that was designed out using elaborate UML diagrams?

Then again, is having a large set of software blueprints even useful? After all refactoring and rebuilding software is much cheaper than rebuilding a skyscraper. Are architectural blueprints the wrong analogy for software design? Is there a better analogy that you can think of?

Answer 1

I think you can't compare software architecture with real architecture. When you build a house you have to have everything planned in advance and what's more important you also can plan almost everything in advance.

Recently I read that software engineering is more similar to gardening than it is to real architecture. I think this comparison comes closer to reality: you can't know what will work out and what won't; you have to rework things that seemed good in theory but prove to be impractical and you can constantly improve your plan while your garden/software is getting more complete.

In summary: Software blueprints shouldn't have the same level of detail than blueprints for building houses because more often than not you find that you simply cannot stick to your original plan.

Answer 2

I'd say that designing software is closer to Mad-Libs than blueprints

Answer 3

One of the arguments made in Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools is that UML is not adequate. Even with the addition of constraints, it is still unclear. Among other things, it does not express the authors intent sufficiently that good code could be reliably generated.

Answer 4

UML is fine, but photographs of whiteboard diagrams drawn roughly are just as good or better in practice (in a time/cost sense of things)

So it's more like drawing a strategy in the sand before lanching an attack, that attitude seems to work better in most cases.

Besides half the time UML gets drawn by some guy with lots of imagination and no investment in the actual implementation.

Answer 5

The combination of Text + Diagrams is usually the best way to explain how your architecture works. Rational Rose can only get you so far.

Answer 6

I think any metaphor is only going to stretch so far. You will get value comparing some aspects of programming to building houses and also from comparing different aspects to gardening / playing chess/ reading the dictionary whilst standing on your head...

I think it is easier in building to specify what level of detail is required for a particular project as there are generally accepted practices, that have been around for some time, for managing a building project.

Maybe in 50 years time, if everyone settles on a methodology, something similar will happen in our industry.

Answer 7

Architectural blueprints are a nearly-precise representation of the actual house. They are not - usually - an abstraction conforming to a model of how houses should look, they are a representation of how the house will be.

Contrast that with UML/Flowcharts/Rational Rose/Methodology-of-the-month - those are models. They abstract away implementation details, and presume that a given model(Say, OO) is how software should be, while in reality, software is always breaking those abstractions, because the models are not a good representation.

In a sense, this ties into a question of explanatory power and computability: a house blueprint is a fixed representation with a fixed expression, and a fixed input; whereas a software blueprint must account for variable input, possibly even of potentially unbounded length. Software that permits plugins or other "computing" tie-ins now has what amounts to a Turing machine operator embedded into it, which gives rise to a host of unpredictability. So the input space of software vis-a-vis a house is mathematically larger, meaning the representational techniques must be correspondingly more computationally powerful. And this is where UML et al. falls down - they are not homomorphic with real software.

Answer 8

For large, computationally dense, long-lived, safety-critical, software systems like DoD and FAA weapons and sensor systems, blueprints are essential to long term success. (phew, that was a mouthful :)) Without a set of blueprints for these behemoths, maintainers, and even the original developers, will experience distress and frustration when they try to locate/fix bugs or add major features. Without blueprints, incorporating changes, even small ones, will become a high risk game and failure could mean the loss of lives downstream.

Having said that, UML and it's offspring SysML, are (right now) the only game in town. Modeling and abstraction are important tools in the battle against ambiguity and complexity and they'll become more important in the future. The sooner they are embraced by people who want to grow, the better.

Thanx for listening.

Answer 9

In my experience, uml is garbage.

You can achieve much, more by using TDD and have 10000x more fun.. by jumping in and writing test cases and seeing how your objects interact.

UML designs just suck. I am a coder, not a data entry type person.

Before TDD I used random pieces of paper to sketch out the basic entities and relationships and then jumped right into coding.

I don't see these tools being used commonplace and the popularity of them is whaning.

Answer 10

I'd say that UML is limited. Yes, you can represent basic relationships, but you still don't get much when you think about interactions and constraints (even with OCL)

Answer 11

If you want to give a software team "all the detail they need to build something" then put your efforts into requirements analysis and creating a nailed-down functional specification. This will contain descriptions of every feature that the customer wants. If those descriptions include UML diagrams then all well and good - in many cases UML is a better language than English/French/German/whatever for describing software - but don't get hung up on creating UML diagrams for the sake of it. Joel on Software has a series of feature articles on how to write functional specs and they are well worth reading - start here: http://www.joelonsoftware.com/articles/fog0000000036.html.

Answer 12

I have just completed a successful C#/Sql Server project where I used a UML diagram to flesh out the application design. That UML diagram avoided any misunderstandings about what the application was designed to do and not do. All class relationships along with the class deletion rules (composite, aggregate, none) were spelled out. Along with a couple of easy to understand State diagrams and some OCL (Object Constraint Language), it was a breeze to discuss with the stakeholders how the application was supposed to work. UML and OCL abstract out a tremendous amount of mundane and low level programming that I was able to avoid. UML and OCL are simple enough that users can understand what is going on under the hood. When my users ask how calculations were arrived at, I simply refer them to the UML and OCL. What could be easier? So, yes, IMHO UML is very appropriate in making software blueprints. There is something to said about employing domain driven development.