Is UML still seen as a viable way of a documenting a software design?
Extra points for references that back up any claims :)
Is UML still seen as a viable way of a documenting a software design?
Extra points for references that back up any claims :)
IMO, UML lost much of its image as the only-and-always-best solution for software development. While enthusiasts in the beginning are (and some still are) in the opinion that UML will solve design problems and everything should ideally be drawn with UML. Reality proved that it is not much better then any other kind of diagram.
IMO, UML is now widely seen as what it actually is: a standard for many diagrams needed in oo analysis and design. It is indeed the most popular diagram standard in use. There are more tools around and more people know UML then any other diagram style.
UML is a way of visually presenting a design, not the actual design method itself. It's just a tool that you use along your travels. As far as I know it is still pretty prevalent in the software engineering world because it is a standard and can be used to convey ideas between two people effectively (which is why it is referred to as a language).
The question sounds slightly back-to-front to me... I don't think UML is intended as a tool to design software, so much as a tool to document a design (in progress).
In my opinion, UML can be a valuable tool for such documentation since it standardises a number of views on a design... but by no means the only valid one. Any design document that is sufficiently clear and well written will do the job, even if it has no UML in it.
Thinking is the only viable way of designing software.
UML is sometimes seen as a viable way to partially describe the design you came up with.
UML, as @John Topley pointed out, is just a standard notation for describing aspects of an object-oriented design, so your question doesn't quite make sense.Personally, I find class diagrams to be the most useful aspect of UML; I seldom bother with most of the other stuff, as I find it easier to write short, descriptive documentation explaining interactions and behaviours. Class diagrams, however, provide a reasonable overview of the architecture.
One thing to keep in mind is that you shouldn't necessarily worry too much about writing "perfect" (i.e. normative) UML; the most important thing is to make sure people understand your design. That said, be careful about accidentally abusing notation, because that may well confuse people who are expecting things to have a specific meaning. If in doubt, annotate with text to be clear about what's going on.
UML can become part of the process of design and implementation. Enterprise Architect has some great tools for initial design. UML falls flat when this isn't backed up by their additional tools of re-importing after customization to update the design. It really does a good job of displaying your current structure, and allowing you to add detail in terms of other UML diagrams (Use Cases, State Diagrams, User Interface mockups and more).
Sadly though, UML really isn't used to it's full potential in practice.