reason uml

7/31/2019 Reason Uml

1/11

Five Reasons Developers Dont UseUML and Six Reasons to Use ItPosted on October 22, 2010 by billpollak | 13 Comments

In many professions, people use graphical models to

represent what they are creating or studying. For example,chemists have 2D and 3D diagrams to model molecules;

cartographers use various kinds of maps to represent

different geographical aspects of a region. If youre a

software developer, youve seen diagrams that represent

some facts about the software design. UML is a visual

language commonly used to create such diagrams.

UML is notspecific to any software process (e.g., XP, RUP),

programming paradigm (e.g., OOP), or technology (e.g.,

Java, .NET, embedded real-time). It originally targeted

object-oriented systems but has evolved and now can be

used to model any kind of software system.

Recently a friend asked me why people dont like using

UML. I gave him my opinion (which I share here) and also

pondered that even if you dont like UML, there are good

reasons to use it.

FIVE REASONS PEOPLE DONT USE UML

1. Dont know the notation

Some people dont use UML simply because they dont know

the notation. In many cases, the person can read UML

diagrams, but is not confident enough to create them. By

analogy, software developers in Latin America in general can

read English but are not comfortable writing in English (I

SATURN Network Blog

Architecture-Centric Engineering | Software Architecture | Systems Architecture


2/11

know that because I work a lot with developers in Brazil).

2. UML is too complex

UML has increased in complexity and size over the years.

Today there are 14 different types of diagrams! Thats too

much for a human being to grasp. Some people shy awayfrom UML because they judge that the effort to climb the

learning curve will not pay off.

3. Never took a UML class

Old timers (like me) didnt learn UML in college. Since UML

training is not so pervasive and people usually dont feel

compelled to buy and read UML books, many simply never

learned UML.

4. Informal notations do just fine

In many situations, people dont think they need UML

diagrams to communicate their designs. They get by with

informal, box-and-line diagrams, which are easy to create in

PowerPoint, in Visio, or on a whiteboard. Software

developers are accustomed to being formal at the code level

(after all, programming languages are formal languages and

the code has to compile and run). They dont like formalism

at the architecture level.

5. Architecture documentation not deemed important

In many projects, the software architecture is quite simple or

it just follows a reference architecture, and hence theres no

strong need to create diagrams to represent and

communicate the design. George Fairbanks calls this

situation architecture-indifferent design.

In some cases, design is communicated orally or using other

graphical notations, such as informal box-and-line diagrams

(as mentioned above).

Whether the lack of design documentation is a conscious

decision or a result of lack of architecture knowledge, such

situations are quite common, and in those cases creating

UML models is deemed unimportant.


3/11

SIX REASONS TO USE IT

Its easy to say Dont use UML, but its hard to say Use

this instead because there are no acclaimed substitutes for

UML. Or are there?

Informal notations? They help in many contexts but inothers the inherent ambiguity impairs the ability to

understand the design.

Absent design documentation? May be OK in some

cases, but the lack of documentation becomes a

problem when the design has to be communicated

across time (to a developer who will join the team six

months later) or space (to a developer working in

another country).

Domain-specific languages (DSLs) for visual modeling?

If youve developed using Visual Studio and have not

used its DSL SDK, that indicates that DSLs for visual

modeling have not found broad adoption.

(Formal) Architecture description languages (ADLs)?

Some formal ADLs, such asAADL, have found niches

where their applicability yields benefits that outweigh

the cost of learning the language and creating detailed

models. And yet, for many of these languages there are

UML profiles that let you work on designs using the

UML notation.

Thus, although I concur with some of the criticism over

UML, I cant point out a better all-purpose alternative. It is

healthier to think about good reasons to use UML. There are

at least six:

1. Its the standard

UML is the de facto standard notation for software design.

In other words, its the only software design notation thatyou can expect your peers to be familiar with.

2. Tool support

UML tools from FOSS to multi-thousand $ price abound in

the market, including plug-ins to most popular IDEs.

Besides drawing diagrams, some of these tools can generate


4/11

code, apply design patterns, mine requirements, reverse

engineer code, and perform impact analysis, refactorings,

and complexity analysis. The ability to generate code from

the design found in many UML tools alone is a good reason

to use UML.

3. UML is flexible

Stereotypes and profiles can let you tailor UML to your

needs. In other words, you can have modeling elements and

relations that are specialized for your domain or for the

technologies youre using.

4. UML models are portable

UML models can be saved in the standard XMI format.

These XMI files can be read by different UML tools, though

some pain is expected (as usual with interchangeable data

formats).

5. Just Need a Subset of the Notation

UML has 14 different types of diagrams. You wont find

anyone who uses all 14 types to document a software system.

It is not a goal to try. Years ago a survey showed that in

practice developers regularly use class, sequence, and use-

case diagrams. The Pareto Principle seems to apply: 20% of

the UML language may cover 80% of your modeling needs.

That means you can learn a subset of the notation and

effectively communicate your designs using UML.

6. Architecture is important

The software architecture is the blueprint for the system; it

allows reasoning about performance, availability, security,

and other attributes, allows planning for incremental

development, and guides work assignments and tracking.

However, even the best architecture, created based on years

of experience and carefully selected design patterns, may be

useless if not properly communicated to the people who

need to use it. Paraphrasing Steuart Henderson, designing

an architecture without documenting it is like winking at a

girl in the dark. You know what youre doing, but nobody

else does. We use this argument in Documenting Software


5/11

Rate this: 8 Votes

Share this:

Like this: Be the first to like this post.

Architectures, Views and Beyond, 2nd Edition to explain

why should we document the architecture. UML is a well-

known visual language that can capture much of the

information that one needs to communicate about the

architecture.

Paulo Merson, SEI

13 RESPONSES TO FIVE REASONS DEVELOPERS DONT USE UML AND SIX

REASONS TO USE IT

This entry was posted in Architecture-Centric Practices and tagged AADL,

documentation, software architecture, software design, software development, UML.Bookmark the permalink.

SoIamAsking| November 7, 2010 at 3:17 pm | Reply

ok have you tried to port your UML models over 2 Applications or

even 3? Using XMI?My Experience is that it works very bad to

absolutely not, because each vendor uses its own meta Data

Andrew McVeigh| November 7, 2010 at 5:54 pm | Reply

Hi Bill,

> UML is a well-known visual language that can capture much of

> the information that one needs to communicate about the

architecture.

Yes, its a really good point. In a way, though, the use of UML for

architecture only really came of age in version 2 with the introduction

of full component diagrams and composite structures. These allow

UML to act as an architecture description language.

However, id argue that we can use diagrams to do much more than

communicate the architecture of a system. We can use them to fully

represent and create the stucture o f the systems, even with dynamic

changes. With that in mind, I created Evolve, a system using UML2

component and state diagrams to fully describe the architecture of a

system.

Id be interested in your views on it.

http://www.intrinsarc.com


6/11

Oh as an integral part, it includes powerful evolution and reuse

facilities which allow system variants to be described.

AkitaOnRails| November 7, 2010 at 8:21 pm | Reply

You dont touch on a more primordial question: are there any

necessity for a fo rmal abstract notation over code? And just saying

because the chemistry guys has one is not an answer, at all.

One may say that it is just too difficult to understand the architecture

of very complex systems just reading code. But then you will have to

explain how very complex systems such as the Linux kernel, the

MySQL database, the Apache webserver, and hundreds of other

systems came about, with tens of thousands of programmers being

able to not just understand it but also evolve it, without a single

diagram to support them.

As a simplistic answer, I would say that people that defend diagrams

and notations are simply not able to grasp code, at all.

Christian| November 8, 2010 at 4:31 am | Reply

The idea behind UML is wrong in many cases, since some people think

software engineering is like machine construction. But software

development is much more dynamic with continually changing

requirements. An UML diagram is one more artefact that needs to be

updated in an agile process, and model driven development doesnt

work in practise, because it is easier to write the code directly instead

of modelling every detail.

UML is fine to show some key aspects of a software design.

Paulo Merson| November 8, 2010 at 3:01 pm | Reply

An UML diagram is one more artefact that needs to

be updated in an agile process

Depending on the project, you may evaluate that a design diagram

has fulfilled its purpose once the first implementation of that piece

of the system is done (hopefully along with test cases that help

understand the behavior). In such cases, it may not pay off to

update the diagram. Thats fine! As I suggested in an InfoQ panel, in

such cases you can delete the design diagrams or mark them as out-

of-date. (See answer to the following question on the panel

discussion: What is the role of software architecture

documentation in development teams that are using Agile?)

Andrew McVeigh| November 8, 2010 at 8:33 am | Reply

> As a simplistic answer, I would say that people that defend

> diagrams and notations are simply not able to grasp code, at all.

well, it is simplistic. its also bad logic to jump from the truism that


7/11

people can understand systems without diagrams to then claim that

people who defend diagrams cannot code.

now, of course people can construct systems without diagrams. these

people have mental models of the system that lives in their heads.

diagrams are about communicating these models so that others can

also understand them.

there are also a great many diagrams of systems like linux etc around.

http://oss.org.cn/ossdocs/linux/kernel/a1/scheduler.gif

Paulo Merson| November 8, 2010 at 3:40 pm | Reply

I second Andrews words, and would like to add some tho ughts.

Several times I joined large software projects as a

developer/maintainer and the welcome email was usually like this:

Paulo, welcome to the team. Below is the URL to the svn

repository. Once you configure your local repository, lets go over

the list of features/bugs that will be assigned to you

Today Im in the architecture team for a project that comprises over

10K classes, not to mention other implementation artifacts (JS,

JSP, XSD, SQL, etc.). Whenever we have new develo pers joining the

team, we go over so me top level architecture diagrams that

describe:

how the codebase is structured in layers.

what are the main packages and their dependencies.

what are the major architectural patterns in use.

whats the typical sequence of steps to process a user request.

whats the runtime structure (tiers and respective types of

components, protocols, replication, databases).what are the main elements of the hardware infrastructure.

This information is transferred in a couple of hours with the aid of

diagrams. Newcomers get up to speed o n the codebase much faster

after this architecture walkthrough than I used to in projects where

I had to read tons of code to try to grasp the big picture. Besides, a

basic understanding of the architecture avoids that new developers

inadvertently fix bugs and implement new features by diverging

from the intended architecture, for example by introducing

disallowed dependencies.

I cant conclude that complex open source systems were designedand implemented without the aid of diagrams just because when I

download the source code I dont download UML models or design

diagrams. Indeed, the design of Unix (richly documented with

diagrams in The Design of the UNIX Operating System by

Maurice Bach; great book!) acted as a scaffolding for Linux.

I defend that people who create design diagrams must be able to

code.


8/11

Nicolas| November 9, 2010 at 5:18 am | Reply

It is the standard : For some fields yes. Not for all computer sciences

modeling cases : database, hardware, real time systems, business

rules, networks

Tool Support : Ok. But you need five minutes to draw an UML diagram

on the whiteboard, and from 30 minutes to 2Hours to do the same in

an UML tool. You want to be able to generate usable code with theses

diagrams. Count another 2 hours. The best you can have is taking a

photo of your sketch and put it in the wiki. When your sure of your

model, if your company need good looking diagrams, the go for a fast

UML tool (like UMLlet) when you dont waste time figuring the

details. If indeed you have written the code. Generate the diagrams

from it automatically. At least these diagrams will not be outdated.

UML is flexible (annotations) : Only usefull for formal UML when

you need code generation and all. Code generation with UML comes

with big merge problems (SCM), so much time spent to do the

diagram that your tool need to make the correct generation. Its not

uncommon to generate several time, to tweak the diagram for hours

so the tool generate the correct thing.

UML model are portable : No. there is a standard yes, XMI. But only

the basics is supported. Import/Export from software to sofware is

really limited. With errors, with loss of information. If you use a

software for your UML needs, better to stay with it or all the

generation, advenced features will be lost.

Just need a subset : Yes.

Architecture is important : Yes it is important. But we need highlevel architecture with only a few diagrams. The more diagrams you

make by hand, the more time you need to maintain them. Detailled

architecture is developper and code responsability. If you want the

help of diagrams to understand implementation details, better your

tool can make the diagram automatically from the code. Otherwise

your documents will be outdated as soon has you finished them.

You need to have a formal description of your software : it is code for

now. For now, UML diagrams fails to deliver the fine details you need

to make the software work. So UML diagrams are better just for

communication between humans.


> For now, UML diagrams fails to deliver the fine details you need

> to make the software work.

sure, this is the case in most UML tools. however, it doesnt have to

be. for instance, ObjecTime (which later became rational rose

realtime) was directly synched up to the code and was a description


9/11

of the system and the executable. it was widely used in avionics and

real-time domains. it shows that the disconnect between code and

diagrams is an oversight, not a necessity.

> So UML diagrams are better just for communication between

humans.

id simply say that the human to human aspect is a critical part ofengineering, and the breakdown of this is a key failing of many

failed systems. as per knuth:

Knuth: My shtick is to promote the idea that humans, not

computers, read programs.

i.e. we program in high level languages so that humans can

understand them, not fo r machines. the machines are happy with

binary. anything therefore that we can do to understand code better

is a good thing, subject to not creating multiple redundant copies

which all need updating.

Jeff Dickey| November 10, 2010 at 12:43 am | Reply

UML excels at what it was originally developed for: selling consulting

and training contracts for Rational and their partners.

Every large project team that Ive been a part of that used UML either

was desperately trying to generate usable, maintainable code (and

failing spectacularly), or acknowledged that the diagrams had at best a

passing resemblance to the current code architecture and layout. We

old-timers often think of it as DOD 2167 without the bo xcars.

Ive been on dozens of agile projects over the last couple decades, sincelong before Agile became a marketing term. The next such project I

see that makes use of UML for anything more complex than back-of-

the-napkin thought exercises while planning a sprint will be the very

first.


> We old-timers often think of it as DOD 2167 without the boxcars.

well, im an old timer too coming from OTI and the original places

where agile were first practised well before it became a buzzword.

and ive successfully used UML on a number of large systems,

including a real-time live-to-air digital broadcasting system where we

kept the code completely in sync with the models. that part icular

example was the early days of rational rose (99 or so), but it created a

powerful synergy between the code and the architecture.

perhaps you just arent very good at it.


10/11

(and as an aside, when did we start blaming tools when we couldnt get

something working)

Jeff Dickey| November 11, 2010 at 9:57 am | Reply

@Andrew McVeigh I certainly didnt mean to sound as though I was

blaming the tool. I was merely stating my observation that every

project I have seen it used on (none of which I was involved in tool

selection) required copious amounts of consulting time to get the team

working reasonably effectively with it. This experience has been

consistent in my work in a dozen different countries, with teams of

varying levels of experience.

Any tool can be used effectively for its stated purpose bysomebody.

The question I was posing wasnt so much on the merits of the tool, as

on the way its often been marketed and especially on the race-to-

the-bottom mentality in recent software development that has

managers looking for silver bullet tools to cover for the fact that

they havent invested the resources to hire or grow an appropriately

effective team.

Andrew McVeigh| November 11, 2010 at 3:09 pm | Reply

@Jeff I hear you. My belief is also that code is what counts and if

something doesnt contribute to that or help with creating or

maintaining code then it is not helpful. Ive also seen UML used in very

bad ways, basically to demarcate between so-called architects (who

dont code) and the developers (who do). Bad stuff.

What Im reacting to though is the silly perception (and the

increasingly common viewpoint apparently) that visual depictions of a

system are always bad and that people who use them are deficient in

some way. Its almost become a mantra. Take an earlier comment from

AkitaOnRails which expresses a not uncommon sentiment: I would

say that people that defend diagrams and notations are simply not

able to grasp code, at all. Huh? These ill-thought out comments really

do programming a disservice and move it further away from the

notion of engineering back into an ad hoc approach to stringing code

together without any coherence.

Diagrams are very useful for showing the relationship between things,

and they are used by many engineering disciplines. They become

increasingly important as a system grows large. A sofware system has

many relationships, and displaying them visually is often the clearest

way to show them certainly far easier than forcing someone to

peruse a million lines of code to get the big picture.

Does that mean that diagrams are always good. Definitely not . They

serve a purpose and when they serve as the primary artifact then

something has gone very wrong. We also suffer from the multiple-

representation dilemma and code will always win the battle where

diagrams are overlapping. It doesnt have to be this way though, and


11/11

earlier systems like ObjecTime showed how synergistic code and

diagrams can be.

Further, as you pointed out, UML has been used for bad things and to

force people into accepting a false demarcation between architect and

programmer. I also think that class diagrams tend to be far too low

level. As UML also tends not to be used to directly create code,

diagrams have also been associated with waterfall and analysisparalysis.

However, we should be very careful not to throw the baby out with the

bathwater. Diagrams definitely have their place in distiling down a

view of the system, and a good technical lead will use them

appropriately. And hopefully, in the future, we will find a way to

accommodate a visual, diagrammatic view and a coding view without

tension. Its certainly a goal that Ive been working towards lately:

http://www.intrinsarc.com/evolve

And diagrams are very useful in the analysis of large systems. I have

used tools l ike structure101 (www.structure101.com) to quicklyunderstand and work with very large codebases that have gotten out of

control. i.e. 100+ developers, multi-year projects that tend towards

balls of mud.

reason uml

Documents