ESCOLA SUPERIOR ABERTA DO BRASIL - ESAB

CURSO DE PÓS-GRADUAÇÃO EM ENGENHARIA DE SISTEMAS

MARCÉLIO VIANA DE CARVALHO

UML – UMA ABORDAGEM HISTÓRICA

VILA VELHA - ES
2010
 MARCÉLIO VIANA DE CARVALHO

UML – UMA ABORDAGEM HISTÓRICA

Monografia apresentada à ESAB – Escola

Superior Aberta do Brasil, sob orientação
da Profª Maria Ionara Barbosa de
Andrade Gonçalves.

VILA VELHA – ES
2010
 MARCÉLIO VIANA DE CARVALHO

UML – UMA ABORDAGEM HISTÓRICA

Aprovada em ___ de _____________ de 2010.

_______________________________________

_______________________________________

_______________________________________

Vila Vela - ES
2010
Dedico este trabalho, com muito carinho e
respeito, aos meus pais: Moacir
Herculano de Carvalho – in memorian – e
Nealina Viana de Carvalho, que sempre
me deram crédito e incentivo.
 AGRADECIMENTOS
A Deus, por ter-me concedido mais uma
importante conquista. À minha família,
pela inspiração e compreensão.

LISTA DE ILUSTRAÇÕES
Figura 1 - Diagramas da UML 1.x...............................................................................28
Figura 2 – Diagramas da UML 2.0..............................................................................34

LISTA DE TABELAS
Tabela 1 - Principais propostas de modelagem OO anteriores à UML......................21
Tabela 2 – Cronologia da UML...................................................................................32

LISTA DE ABREVIATURAS E SIGLAS

AOO Análise Orientada a Objetos
POO Programação Orientada a Objetos
OO Orientação a Objetos
PU Processo Unificado
OMT Object Modeling Technique, Técnica de Modelagem de Objetos
OMG Object Management Group,
OOPSLA Conference on Object-Oriented Programming Systems, Languages and
Applications, Conferência de Desenvolvimento de Sistemas Orientados a Objeto
OOSE Object-Oriented Software Engineering, Engenharia de Software Orientada
a Objeto
UML Unified Modeling Language , Linguagem de Modelagem Unificada
RUP Rational Unified Process
J2EE plataforma da linguagem de programação Java, para aplicações robustas
.NET assim como o “.com”, um domínio web genérico de nível elevado
DFD Diagrama de fluxo de dados

RESUMO
O presente trabalho descreve a história da UML – Unified Modeling Language,
começando pela apresentação do pano de fundo que forneceu suporte ao
surgimento da tecnologia. As principais tecnologias que dominaram o cenário da
modelagem de sistemas nas décadas de 1960, 1970 e 1980 ─ fluxogramas, análise
estruturada, análise essencial e orientação a objeto ─ são descritas, demonstrando
como as mesmas conduziram ao surgimento da UML, inclusive a transição para a
linguagem unificadora. A apresentação da história da UML começa pela década de
1990 até o momento atual, com a descrição de um panorama das versões da UML,
com suas principais ênfases, visões e aperfeiçoamentos, demonstrando como a
modelagem de sistemas evoluiu a partir das novas versões. Os diagramas são
apresentados parcialmente à medida que as versões são amadurecidas e, na
descrição da UML 2.0, todos os atuais diagramas são apresentados com as
alterações introduzidas por ocasião de novas versões, de acordo com sua
classificação em diagramas estruturais ou comportamentais.

SUMÁRIO
INTRODUÇÃO............................................................................................................12

CAPÍTULO I – FUNDAMENTAÇÃO TEÓRICA.........................................................15

I.1 CONTEXTO HISTÓRICO......................................................................................15
I.1.1 O período dos fluxogramas e diagramas de módulos..................................15
I.1.2 O período da programação, projeto e análise estruturada..........................16
I.1.3 O período da análise orientada a objetos.......................................................17
I.2 A FRAGMENTAÇÃO DOS MÉTODOS ORIENTADOS A OBJETOS...................20
I.3 A CRIAÇÃO E A UNIFICAÇÃO DA UML...............................................................23
I.3.1 UML 0.8...............................................................................................................23
I.3.2 UML 0.9...............................................................................................................24
I.4 A PADRONIZAÇÃO DA UML................................................................................24
I.4.1 UML 1.0...............................................................................................................24
I.4.2 UML 1.1...............................................................................................................25
I.4.3 UML 1.2...............................................................................................................29
I.4.4 UML 1.3...............................................................................................................29
I.4.5 UML 1.4...............................................................................................................30
I.4.6 UML 1.5...............................................................................................................31
I.5 UML 2.0: A MAIOR REVISÃO DA HISTÓRIA DA UML........................................32
I.5.1. Diagramas estruturais da UML 2.0.................................................................34
I.5.1.2 Diagrama de classes........................................................................................34
I.5.1.3 Diagrama de objetos........................................................................................35
I.5.1.4 Diagrama de estrutura composta.....................................................................36
I.5.1.5 Diagrama de componentes..............................................................................36
I.5.1.6 Diagrama de implantação................................................................................37
I.5.1.7 Diagrama de pacotes.......................................................................................38
I.5.2. Diagramas dinâmicos da UML 2.0..................................................................38
I.5.2.1 Diagrama de caso de uso..............................................................................39
I.5.2.2 Diagramas de interação...................................................................................39
I.5.2.2.1 Diagrama de seqüência................................................................................40
I.5.2.2.2 Diagrama de comunicação...........................................................................41
I.5.2.2.3 Diagrama de visão geral...............................................................................42
I.5.2.2.4 Diagrama temporal........................................................................................42
I.5.2.3 Diagrama de atividades...................................................................................42
I.5.2.4 Diagrama de máquina de estados...................................................................43
I.5.3. Revisões 2.x da UML.......................................................................................44
I.6 A IMPORTÂNCIA DO AMADURECIMENTO DA UML..........................................45
I.7 PERSPECTIVAS DA UML.....................................................................................46

CAPÍTULO II – CONSIDERAÇÕES FINAIS..............................................................49

GLOSSÁRIO...............................................................................................................50

BIBLIOGRAFIA..........................................................................................................52
 12

INTRODUÇÃO HISTÓRIA DA UML VERSÕES DA UML DIAGRAMAS DA

UML

EXPOSIÇÃO E CONTEXTO DO ASSUNTO

Este trabalho aborda o desenvolvimento histórico da UML, desde o período anterior

ao seu início até chegar à última versão. Será possível entender como ela se tornou
um padrão mundial na indústria de software e ainda apresentar perspectivas para o
futuro da linguagem.

O entendimento da abordagem histórica da UML requer o conhecimento das

metodologias de desenvolvimento de sistemas em suas fases: fluxogramas, análise
estruturada e orientação a objetos. Ao discutir a UML em seu estágio atual, será
apresentada a sua contribuição às melhores práticas no desenvolvimento de
sistemas aplicativos de qualquer porte, contribuições estas respaldadas pela
Engenharia de Software.

PROBLEMA DE PESQUISA

Como tornar compreensível a evolução histórica da UML, com o seu caráter

dinâmico, da fragmentação à industrialização?

JUSTIFICATIVA E MOTIVAÇÃO PARA ESCOLHA DO TEMA

A escolha do tema foi motivada pela necessidade de preencher um vácuo existente

na literatura de língua portuguesa de uma apresentação suscinta, mas abrangente
da evolução histórica da UML, que fosse além do mero resumo histórico. Assim,
esta monografia integra informações dispersas por vários livros da área, que tratam
o assunto apenas de forma introdutória.
 13

Esta carência justifica a abordagem do tema, cujo estudo será relevante para o
aperfeiçoamento do conhecimento acadêmico do autor e para a teoria da
modelagem de sistemas, no que diz respeito à sistematização da história da UML.

OBJETIVOS

Objetivo geral
O objetivo deste trabalho é apresentar a história da UML, descrevendo como a sua
evolução tem contribuído para a modelagem de sistemas.

Objetivos específicos
Descrever e examinar as notações anteriores à UML, a fragmentação que originou a
UML, os principais autores da UML, a unificação da UML, a padronização da UML, a
industrialização da UML e a sua contribuição na construção de modelos de
sistemas.

DELIMITAÇÃO DO TRABALHO

A temática tratada deste trabalho é delimitada pelo seu propósito histórico. A sua
profundidade é, por conseguinte, de nível intermediário. Vários assuntos correlatos
deixaram de ser analisados e aprofundados, o que pode ser feito
complementarmente. Não pertence ao escopo desta pesquisa a descrição completa
dos conceitos e diagramas da UML, que aqui serão apresentados de forma
simplificada. Os interessados nas descrições completas devem consultar as
especificações oficiais da UML, que podem ser obtidas no sítio do OMG – Object
Management Group (www.omg.org).

METODOLOGIA DE PESQUISA

Utilizou-se a metodologia de pesquisa exploratória, com levantamento bibliográfico.

Foram consultadas várias obras de estudiosos da área de modelagem de sistemas,
 14

bem como foram realizadas consultas em sítios de referência na internet, com

prioridade para os acadêmicos e de organismos de padronização.
 15

CAPÍTULO I – FUNDAMENTAÇÃO TEÓRICA

I.1 CONTEXTO HISTÓRICO

Seguindo a tendência dos autores que descrevem a evolução histórica da

modelagem de sistemas, as referências históricas indicadas por datas têm apenas
um cunho didático, oferecendo uma perspectiva temporal para as fases ou divisões
da modelagem de sistemas. Bezerra esclarece que não há uma divisão tão clara das
diversas propostas de modelagem. Ele exemplifica afirmando que propostas iniciais
de modelagem orientada a objetos podem ser encontradas já em meados da década
de 1970 (BEZERRA, 2002). Coad & Yourdon (1992, p.4) retornam um pouco antes,
à década de 1960, declarando: “A programação baseada em objetos foi discutida
pela primeira vez no final dos anos sessenta por aqueles que trabalhavam com a
linguagem Simula. Nos anos setenta, ela era uma parte importante da linguagem
Smalltalk desenvolvida na Xerox”.

I.1.1 O período dos fluxogramas e diagramas de módulos

Nas décadas de 1950 e 1960, antes da análise estruturada clássica, a maioria dos
projetos de software utilizava um documento elaborado pelo analista de sistemas
que continha uma descrição textual dos requisitos do usuário. Este documento
apresentava alguns problemas: monolítico, difícil compreensão, redundância e
ambigüidade de informação, e consequentemente de difícil manutenção.

Para Yourdon (1990, p.563) esse é o período da análise de sistemas convencional,

que ainda se mantém até meados da década de 1970, “[...] caracterizada (se o
 16

fosse) por especificações narrativas semelhantes a novelas vitorianas, difíceis de ler

e compreender, e virtualmente impossíveis de manter [...]”.

Os sistemas de software eram bastante simples. O desenvolvimento desses

sistemas era feito de forma ‘ad-hoc’ 1. Os sistemas eram significativamente mais
simples e, consequentemente, as técnicas de modelagem também eram mais
simples: era a época dos fluxogramas e dos diagramas de módulos (BEZERRA,
2002).

I.1.2 O período da programação, projeto e análise estruturada

Ainda na década de 1970 começaram a surgir computadores mais avançados e

acessíveis, provocando uma grande expansão do mercado computacional. Com
essa demanda, também começaram a surgir sistemas mais complexos. Nesse
cenário surgem a programação estruturada e o projeto estruturado. Autores como
Larry Constantine e Edward Yourdon são grandes colaboradores dessas técnicas
(BEZERRA, 2002).

Na década de 1980, junto com o avanço crescente dos computadores, os preços se

tornaram mais acessíveis. Surgiu a necessidade de interfaces mais sofisticadas,
originando a produção de sistemas de softwares mais complexos. A análise
estruturada surgiu no início deste período com os trabalhos de Edward Yourdon,
Peter Coad, Tom DeMarco, James Martins e Chris Gane (BEZERRA, 2002).

Para Yourdon (1990) a análise estruturada é dividida em análise estruturada

clássica, de meados de 1970 a meados de 1980 e análise estruturada moderna ou
análise essencial, na segunda metade da década de 1980 e início da década de
1990.

1
“Direto ao assunto” ou “Direto ao que interessa”. Na primeira fase do desenvolvimento de sistemas
não havia planejamento inicial. O próprio código-fonte do programa era o modelo
 17

DeMarco (1989) deu notoriedade à expressão Análise Estruturada e inseriu

símbolos gráficos que permitiam ao analista utilizar documentos e/ou diagramas
(ferramentas), como: diagrama de fluxo de dados, dicionário de dados, português
estruturado, tabelas de decisão e árvore de decisão. O conceito de Análise
Estruturada é composto pelo uso das ferramentas acima citadas para a construção
da Especificação Estruturada. Este conceito considerou e minimizou os problemas e
falhas da fase de análise anterior, facilitando a comunicação entre os envolvidos no
projeto de software.

De acordo com Yourdon (1990) qualquer ferramenta de modelagem deve assim ser
caracterizada: ser gráfica com texto para apoio, permitir a visualização subdividida
em modo top-down, ter redundância mínima, ajudar o leitor a antever o
comportamento do sistema e ser transparente. Neste cenário, é uma falha grave
considerar apenas um único modelo para visualizar o sistema, como por exemplo,
somente o diagrama de fluxo de dados (DFD). De igual forma, usar todos os
modelos disponíveis de forma indiscriminada vai gerar o mesmo resultado
catastrófico.

A Análise Essencial surge como um processo natural de evolução da Análise

Estruturada, abordando processos, dados e controle, levando em consideração os
modelos ambiental, comportamental, de informação e de implementação. De acordo
com Mcmenamim & Palmer (1991) na análise essencial o sistema produz a resposta
correta através de estímulos do ambiente.

I.1.3 O período da análise orientada a objetos

Segundo Coad & Yourdon (1992, p.5) a década de 1980 foi um período em que
ocorreram algumas alterações, que se tornaram fatores importantes na década de
1990:
 18

Os conceitos básicos de um enfoque baseado em objetos tiveram uma

década para amadurecimento, e atenção mudou gradualmente de
considerações sobre codificação, para considerações sobre projeto e
análise. (...) A tecnologia básica para a elaboração de sistemas tornou-se
poderosa. (...) Os sistemas que elaboramos hoje são diferentes do que
eram há dez ou vinte anos. Em todos os aspectos, são maiores e mais
complexos; também são mais voláteis e sujeitos a alterações constantes.

Jacobson (apud PRESSMAN, 2006, p.51), discute a necessidade de um processo

de desenvolvimento adequado às expectativas de sistemas cada vez maiores e
complexos:

Hoje, a tendência em software é em direção a sistemas maiores, mais

complexos. Isso se deve, em parte, ao fato de que os computadores têm se
tornado mais potentes a cada ano, levando os usuários a esperar mais
deles. Essa tendência tem também sido influenciada pelo uso da internet,
que está se expandindo, para trocar toda espécie de informação... Nosso
apetite por softwares cada vez mais sofisticados cresce à medida que
aprendemos de uma versão de um produto para a seguinte como o produto
poderia ser aperfeiçoado. Desejamos softwares que sejam melhor
adaptados às nossas necessidades, mas que, por sua vez, não torne o
software somente mais complexo. Em resumo, desejamos mais.

Segundo Furlan (1998), o salto evolutivo do desenvolvimento de sistemas, gerado

pela evolução tecnológica, mudanças de arquiteturas (interfaces gráficas, cliente /
servidor, etc.), prazos mais curtos, dentre outros, provoca a mudança no foco de
sistemas para objeto, surgindo a Análise Orientada a Objetos. Na visão de
Pressman (2006) a Orientação a Objetos introduz uma série de novos conceitos,
como por exemplo, classe, objeto, atributos e operações, dentre outros.

A análise e projeto orientado a objetos foram derivados dos conceitos de

programação orientada a objetos, abordando o desenvolvimento de sistemas de
uma maneira inovadora. Segundo Rumbaugh et al (1991) orientação a objeto trata-
se de uma nova maneira de pensar os problemas utilizando modelos organizados a
partir de conceitos do mundo real, sendo o principal componente o objeto, que
combina dados e comportamento.

De acordo com Furlan (1998) os conceitos básicos da orientação a objetos são:

 Objeto: qualquer coisa do mundo real com limite e identidade bem definido,
contendo atributos e operações. Também denominado de instância da classe;
 19

 Classe: conjunto de objetos que compartilham os mesmos atributos,

operações e relações;
 Encapsulamento: capacidade do objeto de ocultar seus dados, deixando
visíveis operações que manipulam os dados. Tal recurso propicia segurança
e diminuição do trabalho de manutenção;
 Polimorfismo: possibilidade que uma operação tem de atuar de modos
diversos em objetos diferentes;
 Herança: capacidade de uma nova classe (subclasse) tomar atributos e
operações de uma classe já existente (superclasse), permitindo criar classes
complexas sem repetir código (reutilização);

Coad & Yourdon (1992, p.182), conscientes da necessidade de transição para a

nova tecnologia, apresentam um questionamento interessante, demonstrando
preocupação com o melhor momento para aplicar efetivamente a análise orientada a
objetos:

[...] a AOO é substancialmente diferente da decomposição funcional,

análise estruturada e métodos típicos de modelagem de informações. Mas,
mesmo que ela seja diferente e melhor (por assim dizer) do que outros
métodos, 1990 seria a melhor época para começar a usar a AOO? Seria
melhor para uma organização típica esperar até 1991? Ou 1995? Ou 2000?

Coad & Yourdon (1992, p.182) sugerem uma resposta nos seguintes termos: “[...] a
AOO e as técnicas baseadas em objetos representam uma nova curva de tecnologia
(...) a pergunta principal que uma organização típica tem que fazer é: agora é o
melhor momento para mudar de uma tecnologia para outra? [...]”.

Coad & Yourdon (1992, p.188) não escondem o seu entusiasmo com a orientação a
objetos:

Embora reconhecendo a importância e a relevância de muitos outros

métodos mais antigos, agora os deixamos para trás; nenhum dos autores
desenhou um único diagrama de fluxo de dados nos últimos anos, exceto
(em raras ocasiões) como um meio de particionar serviços complexos em
um modelo AOO. Para nós, a AOO é o futuro, e o futuro é aqui e agora. (...)
vemos os anos noventa como um período de aceitação gradual da AOO
 20

I.2 A FRAGMENTAÇÃO DOS MÉTODOS ORIENTADOS A OBJETOS

O início da década de 1990 é o período em que diversos métodos de modelagem

orientada a objetos foram apresentados para a comunidade ao mesmo tempo, com
a multiplicação das propostas. A fragmentação da época atrapalhava os usuários,
que não conseguiam encontrar uma forma comum e satisfatória de modelar os
sistemas. Isto gerou a expressão “guerra dos métodos”, com variadas notações
gráficas para modelar uma mesma perspectiva de um sistema, e cada uma com
seus pontos fortes e fracos. Page-Jones (2001, p.61), ao citar o caos das notações
orientadas a objeto do final da década de 1990, caracteriza aquele período como
uma verdadeira Torre de Babel. Pressman (2006, p.52) sugere que, em meio a
tantas opções, a comunidade tinha muitos métodos disponíveis, mas ao mesmo
tempo não tinha nenhum:

[...] Como a maioria dos novos paradigmas de engenharia de software, os

adeptos de cada um dos métodos POO e AOO argumentaram sobre qual
era o melhor, mas nenhum método ou linguagem individual dominou a
paisagem de engenharia de software.

Deitel (2005, p.16) afirma a percepção da necessidade de um padrão para a

modelagem de sistemas, que fosse aceito e utilizado amplamente, quando diz: “[...]
Claramente, uma notação-padrão e processos-padrão eram necessários”.

Diversos autores famosos contribuíram com publicações de seus respectivos

métodos segundo a orientação a objetos. Os principais foram: Booch (Grady Booch),
OMT (Rumbaugh), OOSE (Jacobson), Shlaer/Mellor (Sally Shlaer e Stephen Mellor),
Coad/Yourdon (Peter Coad e Ed Yourdon) e Rebeca Wirfs-Brock, dentre outros
(FURLAN, 1998). A tabela (tab.1) a seguir ajuda a visualizar as contribuições.
 21

Tabela 1 - Principais propostas de modelagem OO anteriores à UML

ANO AUTOR e/ou TÉCNICA

1990 Shlaer e Mellor (Object Lifecycles)
1991 Coad e Yourdon (OOAD – Object-Oriented Analysis and Design)
1993 Grady Booch (Booch Method)
1993 Ivar Jacobson (OOSE – Object-Oriented Software Engineering)
1995 James Rumbaugh… [et.al] (OMT – Object Modeling Technique)
1996 Wirfs-Brock (Responsibility Driven Design)
1996 HP Fusion (Operation descriptions and message numbering)
1994 Gamma… [et.al] (Frameworks, patterns)
Odell (Classificação)
Harel (Diagrama de Estado)
Embley (Classes “singleton”, Visão “high-level”)
Meyer (Pré e pós-condições, linguagem e ambiente Eiffel)
Fonte: Furlan (1998); Fowler (2005)

No início da década de 1990 três métodos se destacavam no mercado pelo seu

crescimento: Booch’93 de Grady Booch, OMT-2 de James Rumbaugh e OOSE de
Ivar Jacobson. Cada um deles possuía pontos fortes em algum aspecto, conforme
segue.

Booch – Este método, de Grady Booch, foi disponibilizado em muitas versões. O

método definiu a noção de que um sistema é analisado a partir de um número de
visões, onde cada visão é descrita por um número de modelos e diagramas.
Apresentava uma simbologia complexa para ser desenhada manualmente e um
processo onde os sistemas são analisados por macro e micro visões.

OMT – Técnica de Modelagem de Objetos (Object Modelling Technique),

desenvolvido por James Rumbaugh na GE (General Electric). Trata-se de um
método especialmente voltado para o teste dos modelos, baseado nas
especificações da análise de requisitos do sistema. O modelo total do sistema
baseado no método OMT é composto pela junção dos seguintes modelos: a) modelo
de objetos, representado por diagramas de objetos contendo classes de objetos; b)
modelo dinâmico, representado graficamente por diagramas de estados e; c) modelo
unidirecional, representado pelos diagramas de fluxo de dados (RUMBAUGH et al,
1991). Além dos diagramas citados – diagramas de objetos, diagramas de estados e
 22

diagramas de fluxos de dados –, podem ser incluídos: diagramas de classes,

diagrama de tempo, diagramas de módulos e diagramas de processos (DEREK et
al, 242).

OOSE/Objectory – Os métodos OOSE e o Objectory foram desenvolvidos a partir do

ponto de vista de Ivar Jacobson. OOSE é a visão de um método orientado a objetos,
já o Objectory é usado para a construção dos mais diversos tipos de sistemas. Os
dois são baseados nos casos de uso, que definem os requisitos iniciais do sistema,
a partir da visão de um ator externo. O método Objectory também foi adaptado para
a engenharia de negócios, onde é usado para modelar e melhorar os processos
envolvidos no funcionamento de empresas.

Em síntese, OOSE focava em casos de uso, OMT-2 se destacava na fase de análise

e Booch’93 era mais forte na fase de projeto. Cada um dos métodos possuía
notação, processos e ferramentas próprios. Os três eram independentes e não
seguiam outros métodos da época, mas, ainda que independentes e com focos
específicos, já convergiam entre si. Seria muito mais produtivo que os três
continuassem de forma conjunta (SAMPAIO, 2007).

Diante desta diversidade de conceitos, “os três amigos”, Grady Booch, James
Rumbaugh e Ivar Jacobson decidiram juntar esforços para criar uma Linguagem de
Modelagem Unificada. Segundo Pressman (2006, p.52), eles combinariam “[...] as
melhores características de cada um dos seus métodos individuais e adotariam
características adicionais propostas por outros especialistas, como Wirfs-Brock, no
ramo de OO [...]”. Furlan (1998, p.34) destaca a importante participação dos outros
autores, quando afirma: “[...] Os fomentadores da UML não inventaram a maioria das
idéias, em vez disso, seu papel foi selecionar e integrar as melhores práticas (best of
breed) do mercado [...]”. Por outro lado, Furlan (1998, p.34) também declara: “[...] Na
verdade, a UML não representa uma ruptura radical de Booch, OMT ou OOSE, é um
passo natural na escala de evolução [...]”.

Várias versões preliminares foram disponibilizadas para a comunidade de

desenvolvedores e a resposta incrementou muitas novas idéias que foram
melhorando progressivamente a linguagem.
 23

I.3 A CRIAÇÃO E A UNIFICAÇÃO DA UML

Assim como anteriormente foi apresentado um alerta a respeito da dificuldade de

precisão das datas, que são usadas com propósito didático, também a apresentação
das versões da UML apresenta uma dificuldade similar, o que torna esta pesquisa
vulnerável a erros e confusões.

I.3.1 UML 0.8

A criação da UML foi em si um processo iterativo e incremental, muito parecido com

a modelagem de um grande e complexo sistema de software (FOWLER, 2003;
FURLAN, 1998).

Em outubro de 1994 começaram os esforços para unificação dos métodos, liderados

por Booch e Rumbaugh, que se associaram através da Rational Corporation (hoje
uma divisão da IBM) para unificar os métodos Booch’93 e OMT-2, que já eram
evoluções dos métodos Booch’91 e OMT-1, respectivamente. Os esforços
resultaram na versão 0.8 do Método Unificado, lançado em outubro de 1995.
Tratava-se do rascunho inicial do Método Unificado, até então com a junção de dois
métodos. Nesse estágio ainda não existe a denominação UML, que só vai surgir
posteriormente. Método Unificado é o nome pelo qual a UML foi chamada no
princípio (FURLAN, 1998).
I.3.2 UML 0.9
 24

No final de 1995, Jacobson se juntou à equipe do projeto e o OOSE (Object-

Oriented Software Engineering) foi incorporado pelo “Método Unificado”. Em junho
de 1996, os três amigos, como já eram conhecidos, lançaram a primeira versão com
os três métodos - a versão 0.9, que foi batizada como UML – Unified Modeling
Language (FOWLER, 2003). Com a disponibilização da versão 0.9 em 1996, o grupo
solicitou e recebeu feedback da comunidade de engenharia de software do mundo
inteiro. O retorno recebido da comunidade gerou, em outubro de 1996, uma versão
intermediária pouco comentada pelos principais autores: a UML 0.91. Nesse período
o OMG solicitou propostas para uma linguagem-padrão de modelagem, conforme
declara Deitel (2005, p.16):

[...] Mais ou menos na mesma época, uma organização conhecida como

Object Management Group (OMG) solicitou idéias e sugestões para uma
linguagem de modelagem comum. O OMG é uma organização sem fins
lucrativos que promove a padronização de tecnologias orientadas a objetos
publicando diretrizes e especificações, como a UML [...].

I.4 A PADRONIZAÇÃO DA UML

De acordo com Bezerra (2002), na segunda metade da década de 1990 o

paradigma da OO atinge a sua maturidade. Os conceitos de padrões de projeto,
frameworks, componentes e qualidade começam a ganhar espaço.

I.4.1 UML 1.0

Uma linguagem de modelagem dever perecer ou evoluir, desenhando as suas

curvas na história. A evolução da 0.9 para a 1.0 demonstra que a UML despontava
como a melhor opção para ser a linguagem de modelagem unificadora e que estava
no caminho do crescimento. Consequentemente muitos esforços ainda seriam
empreendidos.
 25

Booch, Rumbaugh e Jacobson estavam motivados a continuar trabalhando para que

a UML se tornasse um padrão de linguagem unificada para modelar sistemas
complexos de qualquer tipo: missão crítica, tempo real, cliente/servidor ou outros
tipos de software padrões. Em resposta à solicitação do OMG, grandes empresas
que reconheciam tanto a necessidade de uma linguagem padronizada, quanto os
esforços da Rational, formaram o UML Partners (FURLAN, 1998; BOOCH, 2000;
DEITEL, 2005). Booch (2000, p.xvii) declara: “[...] Estabelecemos um consórcio de
UML com várias empresas que desejavam dedicar recursos com o propósito de
trabalhar a favor de uma definição mais forte e completa da UML [...]”. As empresas
foram: Microsoft, Hewlett-Packard, Oracle, IBM, Unisys, Ericsson, ICON Computing,
TIER Corporation, Taskon, Digital Equipment Corporation, Softeam, Expersoft
Corporation, Intellicorp, Unisys e Texas Instruments, dentre outras.

Essa colaboração permitiu que em janeiro de 1997 fosse lançada a UML 1.0, que foi
oferecida para padronização ao OMG, em resposta à sua solicitação de propostas
para uma linguagem-padrão. No período de janeiro a julho de 1997 o grupo original
de parceiros cresceu, incluindo virtualmente todos os participantes e colaboradores
da resposta inicial ao OMG. O trabalho da força-tarefa priorizou a semântica,
buscando formalizar a especificação da UML (BOOCH, 2000). A guerra dos métodos
orientados a objeto estava chegando ao fim, resolvendo a maioria das diferenças ─
muitas delas inconsequentes ─ entre as linguagens anteriores de modelagem,
conforme descrito anteriormente.

I.4.2 UML 1.1

Existe um conflito entre o uso do nome das versões 1.0 e 1.1 entre o OMG e a
Rational, que usam numerações diferentes para designar a mesma versão. Isso tem
provocado uma dificuldade de identificação na literatura e Fowler (2005, p. 143)
discorre sobre o assunto, declarando:

[...] Entretanto, devido a uma confusão, o OMG chamou esse padrão de

versão 1.0. Então, a UML era tanto a versão 1.0 do OMG como a versão 1.1
 26

da Rational, para não ser confudida com a versão 1.0 da Rational. Na

prática, todos chamam esse padrão de versão 1.1.

Os esforços dos colaboradores produziram uma versão revisada da UML, a 1.1, que
foi oferecida ao OMG para padronização em julho de 1997. Em setembro de 1997 a
versão foi aceita pela equipe de análise e design do OMG, bem como pela equipe de
arquitetura. A seguir foi submetida ao voto de todos os membros do OMG. Em 14 de
novembro de 1997 a UML 1.1, com foco na melhoria da limpidez das semânticas, foi
disponibilizada, após ter sido aprovada por todos os membros do OMG (BOOCH,
2000). Segundo Deitel (2005), ao aprovar a proposta, o OMG assumiu a
responsabilidade pela manutenção e revisão constantes da UML.

Ao adotar a UML como padrão, o OMG se responsabilizou, através da RTF –

Revision Task Force, pelas revisões futuras, analisando feedbacks sobre
inconsistências, ambigüidades e omissões. Essas revisões são controladas para
não provocar grandes alterações no escopo original. Um importante diferencial da
UML é que, a cada nova versão, as alterações e aperfeiçoamentos foram produzidos
de forma a não gerar grande impacto, o que facilitou sua disseminação pelo mundo.
Um dos principais motivos para o crescimento da UML no decorrer da sua história
após cada versão é a suavidade das mudanças, que não afetam a continuidade dos
projetos e do uso da notação pela indústria de sofware. As revisões ocorridas não
geraram grandes mudanças nas versões UML 1.2, UML 1.3 e UML 1.4. Somente na
versão 2.0 as alterações foram mais profundas, como será descrito mais adiante.

Segundo Fowler (2005) as principais mudanças da UML 1.0 para a UML 1.1 foram:

 Composição: anteriormente a composição implicava que o vínculo fosse

imutável pelo menos para componentes de valor único. Nesta versão essa
restrição foi excluída;

 Tipo e classe de implementação: a partir dessa versão todas as classes em

um diagrama de classes podem ser especializadas, tanto como tipos quanto
como classes de implementação;
 27

 Restrições discriminadoras completas e incompletas: uma restrição

{complete} indica que todos os subtipos dentro de uma partição foram
especificados – na época essa alteração gerou controvérsias entre os
estudiosos;

 Imutabilidade e congelamento: antes a UML estabelecia uma restrição para

definir a imutabilidade em papéis de associação, mas nesta versão isso não
se aplica a atributos ou classes;

 Retornos em diagramas de sequência: antes o retorno era diferenciado pelo

uso de uma ponta de seta, em vez de uma seta cheia. A UML 1.1 usa a seta
tracejada para um retorno, deixando-os mais óbvios;

 Termo “Papel”: Na UML 1.0 o termo indicava uma direção na associação, já

na UML 1.1 esse uso passa a ser denominado papel de associação. Passa a
ser incluído o papel de colaboração, que é o papel que uma instância de uma
classe desempenha em uma colaboração; assim, a ênfase recai sobre as
colaborações.

Os diagramas que constituíram a UML nesta fase foram:

 Diagrama de Casos de Uso, com aparência similar aos do OOSE, sendo mais
abrangente na UML;
 Diagrama de Classes, numa fusão de OMT, Booch e diagramas de classe da
maioria dos outros métodos OO;
 Diagrama de Objetos, oriundo do Método Booch;
 Diagramas de Implementação, são derivados do Método Booch e dos
diagramas de processo; existem sob duas formas: diagrama de componentes
e diagrama de implantação (FURLAN, 1998);
 Diagrama de Atividades, semelhante aos diagramas de fluxo de trabalho
desenvolvido por muitas fontes, mas é pouco conhecido “[...] porque não
estava presente nos trabalhos anteriores de Booch, Rumbaugh e Jacobson ─
de fato, está baseado no diagrama de evento de Odell com uma notação
diferente de seus livros” (FURLAN, 1998, p.219);
 28

 Diagramas de Interação, termo aplicado a vários tipos de diagramas que

enfatizam interações de objetos, apresentados de duas formas na UML:
o Diagrama de Sequência, oriundo de uma variedade de métodos OO,
inclusive anteriores à OO, com nomes como interação, rastreamento
de mensagem e evento de rastreamento;
o Diagrama de colaboração, “[...] é descendente direto do diagrama de
objeto de Booch, do gráfico de interação de objeto da Fusion e várias
outras fontes [...]” (FURLAN, 1998, p.199);
 Diagrama de Estados, baseados em David Harel.

Os diagramas citados acima são visualizados na figura abaixo (fig.1):

Figura 1 - Diagramas da UML 1.x

Fonte: Sampaio (2009)
 29

I.4.3 UML 1.2

Seguindo sua responsabilidade na manutenção da UML, o OMG lançou em junho de

1998 a UML 1.2. Não houve nenhuma mudança tecnológica radical, pois tratava-se
de uma revisão editorial, que apresentava apenas pequenas alterações, como por
exemplo, eliminação de erros de digitação e paginação. Na verdade o já citado
conflito entre o número das versões da Rational e do OMG gerou esta versão, que
foi lançada devido as disputas entre os autores dos dois grupos.

I.4.4 UML 1.3

Em mais uma RTF – Revisão Técnica Forma– no final de 1998 foi lançada a UML
1.3, que forneceu alguns aprimoramentos técnicos. Além disso, outras mudanças
foram incluídas, como: correção de inconsistência nos documentos, esclarecimento
de algumas definições e explicações, com a melhoria do mapeamento,
principalmente na semântica e notação, conforme descrito abaixo.

Anterior a esta versão existiam dois relacionamentos de casos de uso,

representados pelos estereótipos <<uses>> e <<extends>>, que representavam
generalizações. As mudanças na UML 1.3 relativas aos casos de uso envolvem três
novos tipos de relacionamentos entre os casos, representadas por um símbolo de
generalização de um caso de uso a outro. Os tipos de relacionamento são: a)
Inclusão, com o estereótipo <<include>>, que substitui o uso comum de <<uses>>: o
caminho de um caso de uso está incluído em outro, o que ocorre quando poucos
casos de uso compartilham passos em comum; b) Generalização (sem estereótipo)
de casos de uso: indica que um caso de uso é uma variação de outro; c) Construção
ou Extensão <<extend>>: é um estereótipo de dependência, o que fornece uma
forma mais controlada de extensão do que o relacionamento de generalização. O
 30

caso de uso base declara vários pontos de extensão e o caso de uso estendido
pode alterar o comportamento somente nos pontos de extensão (FOWLER, 2005).

As mudanças provocaram alguns conflitos no uso dos relacionamentos, conforme

discorre Fowler (2005, p.147):

Existe certa confusão sobre a relação entre os relacionamentos antigos e os

novos. A maioria das pessoas usava <<uses>> da maneira como
<<includes>> é usado na versão 1.3; portanto, para a maioria das pessoas,
podemos dizer que <<includes>> substitui <<uses>>. E a maioria das
pessoas usava <<extends>> da versão 1.1 tanto na maneira controlada da
palavra-chave <<extends>> da versão 1.3 quanto como uma sobreposição
geral no estilo da generalização da versão 1.3. Assim, você pode pensar
que <<extends>> da versão 1.1 foi dividida em <<extend>> e na
generalização da versão 1.3.

Os diagramas de atividades sofreram mudanças em aspectos semânticos, que

ficaram em aberto na UML 1.2. De acordo com Fowler (2005), a versão 1.3 promove
ajustes semânticos, conforme descritos a seguir:
 usar atividade de decisão, no formato de losango, para comportamento
condicional;
 referir-se à barra de sincronização como separação (na divisão do controle)
ou junção (na sincronização do controle);
 exclusão do recurso de disparo múltiplo, que foi substituído pela concorrência
dinâmica em uma atividade, visualizada por um asterisco (*).

I.4.5 UML 1.4

Segundo Fowler (2005, p.148) a mudança mais notável na UML 1.4 foi “[...] a adição
de perfis, que permitem que um grupo de extensões sejam coletadas em um
conjunto coerente [...]”. Além disso, é possível destacar que, “[...] junto com isso, há
um maior formalismo envolvido na definição de estereótipos, e elementos de modelo
 31

agora podem ter múltiplos estereótipos; na UML 1.3, eles eram limitados a um só”
(FOWLER, 2005, p.148).

De acordo com Larman (2004, p.583), “[...] Os estereótipos são usado para
classificar elementos. A partir da UML 1.4, um elemento pode ter muitos
estereótipos, mas apenas um deles é mostrado em um diagrama específico [...]”.

O diagrama de interação sofreu uma mudança que gerou um impacto maior, por ser
incompatível com as versões anteriores: a ponta de seta vazada do diagrama foi
transformada em um sinal assíncrono (FOWLER, 2005).

Destaque para o acréscimo dos artefatos na versão 1.4: “Artefatos foram

acrescentados na UML. Um artefato é uma manifestação física de um componente.
(...) Antes da versão 1.3, não havia nada no metamodelo da UML para tratar a
visibilidade de pacote da linguagem Java. Agora há, e o símbolo é ~ ” (FOWLER,
2005, p.148).

Em julho de 2004 o OMG lançou a UML 1.4.2. Esta mesma versão foi lançada em
janeiro de 2005 como a ISO/EC 19501.

I.4.6 UML 1.5

Em março de 2003 o OMG lançou a UML 1.5, que o organismo considera

combinada com a versão 1.4.

A mudança mais notável em relação às versões anteriores foi a inclusão da

semântica de ação na UML, considerado um passo indispensável para tornar a UML
uma linguagem de modelagem. Isso pode ser considerado uma antecipação à UML
2.0, pois permitiu que as pessoas trabalhassem sem esperar pela UML 2.0 completa
(FOWLER, 2005).
 32

I.5 UML 2.0: A MAIOR REVISÃO DA HISTÓRIA DA UML

A partir do presente estágio desta pesquisa, sempre que necessário, as versões

anteriores da UML serão simplesmente identificadas como UML 1.x, o que ajuda a
compreender a evolução da UML em duas grandes fases: o período da 1.x e o
período da 2.x. A tabela (tab.2) abaixo resume essa cronologia:

Tabela 2 – Cronologia da UML

ANO VERSÃO
Outubro de 1995 UML 0.8
Junho de 1996 UML 0.9
Janeiro de 1997 UML 1.0
Novembro de 1997 UML 1.1
Junho de 1998 UML 1.2
Final de 1998 UML 1.3
Setembro de 2001 UML 1.4
Março de 2003 UML 1.5
Julho de 2005 UML 2.0
Não foi lançada oficialmente UML 2.1
Agosto de 2007 UML 2.1.1
Novembro de 2007 UML 2.1.2
Fevereiro de 2009 UML 2.2
Em andamento desde setembro de 2009 UML 2.3
Elaboração própria (2010)

Em julho de 2005 o OMG lançou a UML 2.0 com muitas alterações, de forma que
“[...] a evolução (...) para a UML 2 produziu fortes alterações ao nível da sua própria
arquitetura, um refinamento e aumento de qualidade da generalidade dos
diagramas, e implicou também a introdução de novos diagramas.” (SILVA &
VIDEIRA, 2005, p.7)

A versão da UML 2.0 trouxe grandes mudanças necessárias à evolução do mercado

de informática, conforme defendido por Melo (2004).  Segundo Fowler (2005, p.148),
foram mudanças profundas no metamodelo, resultando na introdução de novos tipos
de diagramas:
 33

[...] Os diagramas de objetos e os diagramas de pacotes já eram

amplamente desenhados, mas não eram tipos de diagramas oficiais; agora,
eles são. A UML 2 mudou o nome dos diagramas de colaboração para
diagramas de comunicação. Ela também introduziu novos tipos de
diagrama: diagramas de visão geral da interação, diagramas de
temporização e diagramas de estrutura composta.

De acordo com os mais atuais documentos da OMG, a UML 2.0 consagra-se como
uma das mais expressivas linguagens para modelagem de sistemas OO. Por
sintetizar os principais métodos existentes, se consolida como a linguagem mais
usada para especificação, documentação, visualização e desenvolvimento de
sistemas orientados a objetos. Hoje os seus diagramas representam sistemas de
softwares sob diversas perspectivas de visualização e por seu vocabulário de fácil
visualização, facilita a comunicação de todas as pessoas envolvidas no processo de
desenvolvimento de um sistema ─ gerentes, coordenadores, analistas,
desenvolvedores (OMG, 2005a; OMG, 2005b; OMG, 2006).

A diversidade dos diagramas da UML 2.0 permite dirigir o foco para diferentes
aspectos de um sistema de maneira independente. Quando devidamente aplicados,
os diagramas tornam mais fácil a compreensão do sistema em desenvolvimento.

A respeito da quantidade de diagramas da UML 2.0, Guedes (2008, p.27) afirma que
“[...] o objetivo é fornecer múltiplas visões do sistema a ser modelado, analisando-o
e modelando-o sob diversos aspectos, procurando-se, assim, atingir a completitude
da modelagem, permitindo que cada diagrama complemente os outros”.

Treze diagramas compõem a UML 2.0, classsificados em estruturais ou estáticos e

dinâmicos. Enquanto os estruturais mostram as características que não mudam com
o tempo, os dinâmicos mostram como o sistema evolui no decorrer do tempo
(MELO, 2004). A figura a seguir (fig.3), usando a notação de diagrama de classes,
apresenta a estrutura das categorias (OMG, 2006).
 34

Figura 2 – Diagramas da UML 2.0

Fonte: OMG (2006); Fowler (2005)

I.5.1. Diagramas estruturais da UML 2.0

Os diagramas estruturais, conforme a especificação OMG (OMG, 2006), tratam o

aspecto estrutural tanto do ponto de vista do sistema quanto das classes, numa
representação de seu esqueleto em estruturas relativamente estáveis.

I.5.1.2 Diagrama de classes

Martins (2004) afirma que os diagramas de classes são utilizados para representar
estruturas de classes de negócio, interfaces com o usuário e outros sistemas e
classes de controle. Silva (2007) corrobora a afirmação acima quando sustenta que
um diagrama de classes é um modelo fundamental de uma especificação orientada
a objetos. Produz a descrição mais próxima da estrutura do código de um programa,
 35

ou seja, mostra o conjunto de classes com seus atributos e métodos e os

relacionamentos entre classes. Classes e relacionamentos constituem os elementos
sintáticos básicos do diagrama de classes.

Na mesma linha de raciocínio de Martins (2004) e Silva (2007), Guedes (2008, p.29)
reitera que um Diagrama de Classes é uma representação da estrutura e relações
das classes, ao passo em que coroa o diagrama de classes, quando afirma:

O Diagrama de Classes é o mais utilizado e o mais importante da UML.

Serve de apoio para a maioria dos demais diagramas. Como o próprio nome
diz, define a estrutura das classes utilizadas pelo sistema, determinando os
atributos e métodos que cada classe possui, além de estabelecer como as
classes se relacionam e trocam informações entre si.

Os diagramas de classes da UML 1.x para a UML 2 perderam as multiplicidades

descontínuas e a propriedade de congelamento, que foram eliminadas. Além disso,
os atributos e associações unidirecionais passaram a ser apenas notações distintas
para um mesmo conceito de propriedade (FOWLER, 2005).

I.5.1.3 Diagrama de objetos

Para Furlan (1998), este diagrama é composto pelos objetos e seus relacionamentos
em um determinado instante no tempo. É como uma fotografia de um diagrama de
classe ou diagrama de interação. Na realidade trata-se de uma variação do
diagrama de classes em que, em vez de classes, são representadas instâncias e
ligações entre instâncias. Os objetos e suas instâncias são usados para fazer a
modelagem da visão estática do projeto de um sistema, a partir da perspectiva de
instâncias de situações da realidade ou de protótipos.

Observando o que escreve Melo (2004), a representação gráfica de um objeto é

similar à de uma classe, ou seja, um retângulo com dois compartimentos, onde o
primeiro contém o nome do objeto e o segundo os atributos com seus respectivos
valores.  
 36

I.5.1.4 Diagrama de estrutura composta

O diagrama de estrutura composta fornece meios de definir a estrutura de um

elemento e de focalizá-la no detalhe, na construção e em relacionamentos internos.
É um dos novos diagramas propostos na segunda versão da UML, voltado a
detalhar elementos de modelagem estrutural, como classes, pacotes e
componentes, descrevendo sua estrutura interna.

O diagrama de estrutura composta introduz a noção de “porto”, um ponto de

conexão do elemento modelado, a quem podem ser associadas interfaces. Também
utiliza a noção de “colaboração”, que consiste em um conjunto de elementos
interligados através de seus portos para a execução de uma funcionalidade
especifica – recurso útil para a modelagem de padrões de projeto (SILVA, 2007).

Para Melo (2004) este diagrama visa mostrar a composição de estruturas complexas
ou projetos de componentes, simplificando o relacionamento de composição. Deste
modo será exibido um diagrama de classes dentro de uma classe, contendo a
classe-todo com suas classes-partes ligadas através de conectores.

I.5.1.5 Diagrama de componentes

O diagrama de componentes é um dos dois diagramas de UML voltados a modelar

software baseado em componentes, pois indica os componentes do software e seus
relacionamentos ou associações entre os componentes. Este diagrama mostra os
artefatos de que os componentes são feitos, como arquivos de código fonte,
bibliotecas de programação ou tabelas de bancos de dados e as interfaces.

Na visão de Martins (2004) os diagramas de componentes representam os

elementos de software que serão criados como programas executáveis, tabelas de
 37

banco de dados, componentes, entre outros. O diagrama mostra a relação de

interdependência e comunicação entre os elementos.

De acordo com Melo (2004) o componente é identificado como uma unidade

modular com interfaces bem definidas e substituíveis dentro de seu ambiente. Tal
diagrama representa o tipo e não a instância, representando uma parte modular que
encapsula determinado comportamento bem definido.

I.5.1.6 Diagrama de implantação

O diagrama de implantação, também denominado diagrama de utilização, consiste

na organização do conjunto de elementos de um sistema para a sua execução. O
principal elemento deste diagrama é o nodo, que representa um recurso
computacional. Podem ser representados em um diagrama tantos os nodos como
instâncias de nodos. O diagrama de implantação é útil em projetos onde há muita
interdependência entre pedaços de hardware e software.

Segundo Furlan (1998) trata-se de um gráfico de nós conectados por associações

de comunicação. Os nós podem conter instâncias de componente que, por sua vez,
podem ser classes, bibliotecas ou executáveis.

Na visão de Melo (2004) os nós são tipicamente definidos de maneira aninhada e

representam dispositivos de hardware ou ambientes de execução de software. Já
artefatos representam elementos concretos do mundo físico que são resultado do
processo de desenvolvimento.

I.5.1.7 Diagrama de pacotes

O pacote é um elemento sintático que contém elementos sintáticos de uma

especificação orientada a objetos. Esse elemento foi definido na primeira versão da
UML para ser usado nos diagramas existentes na época, como o diagrama de
 38

classes, por exemplo. Até então não se tratava de um diagrama, mas de um

elemento que fazia parte dos diagramas existentes na primeira versão da UML. Na
segunda versão da UML o conceito de elemento constituinte evoluiu para compor
um novo diagrama: o diagrama de pacotes. Como o próprio nome indica, ele é
voltado a conter exclusivamente pacotes e relacionamentos entre pacotes (SILVA,
2007). O diagrama de pacotes trata a modelagem estrutural do sistema dividindo o
modelo em divisões lógicas e descrevendo as interações entre eles em alto nível.

De acordo com Page-Jones (2001) o diagrama de pacotes é usado para organizar

os elementos em módulos, geralmente coleções de classes, tornando claras suas
dependências, conforme demonstrado na próxima figura. Além disso, também pode
ser aplicado em bibliotecas adquiridas ou aplicação com características relativas.

Para Booch (2000) os pacotes possibilitam aos desenvolvedores trabalhar em

equipe, tornando seus modelos organizados em grupos inter-relacionados. De
acordo com esse entendimento, um pacote deve ser visto apenas como um
elemento básico de controle de configuração, armazenamento e acesso. Um pacote
gera uma rede no formato grafo, pois pode referenciar elementos de outro pacote.

I.5.2. Diagramas dinâmicos da UML 2.0

Os diagramas dinâmicos ou de comportamento, conforme a especificação OMG

(OMG, 2006), são voltados a descrever o sistema computacional modelado quando
em execução, isto é, como a modelagem dinâmica do sistema.
I.5.2.1 Diagrama de caso de uso

O diagrama de casos de uso tem por objetivo apresentar uma visão externa das
funções e serviços que o sistema deverá oferecer aos usuários, sem se preocupar
em como tais funções serão implementadas. O diagrama de casos de uso é de
 39

grande auxílio na etapa de análise de requisitos, ajudando a especificar, visualizar e

documentar as características, funções e serviços desejados pelo usuário. O
diagrama de casos de uso tentar identificar os tipos de usuários que irão interagir
com o sistema, quais papéis esses usuários irão assumir e quais funções serão
requisitadas por um usuário específico (GUEDES, 2008). 

Para Bezerra (2002, p.57), "[...] o enfoque ao utilizar casos de uso e seus
relacionamentos é identificar os objetivos do usuário, em vez das funções do
sistema. O modelo de caso de uso define uma visão externa do sistema [...]".

Os relacionamentos de dependência, generalização e associação são usados para

fazer a modelagem da visão estática do caso de uso do sistema. Essa visão
proporciona suporte principalmente para o comportamento de um sistema. Neste
caso os diagramas de caso de uso são usados para fazer a modelagem do contexto
de um sistema e fazer a modelagem dos requisitos de um sistema (SILVA, 2007).

I.5.2.2 Diagramas de interação

De acordo com Furlan (1998) os diagramas de interação descrevem cenários dos

casos de uso, compondo uma modelagem comportamental. Realizam um propósito
específico, ao utilizar as seqüências de trocas de mensagens entre as classes de
objetos, atores, componentes e subsistemas.

Apoiada no OMG, Melo (2004) enfatiza que os diagramas de interação são

apresentados em quatro formas: diagrama de seqüência, diagrama de comunicação,
diagrama de visão geral e diagrama temporal.

Para Furlan (1998) os diagramas de seqüência e comunicação tratam e expressam

informações semelhantes de modo diferente. O diagrama de seqüência é próprio
para entender a ordem de execução das operações na dimensão temporal; por sua
 40

vez, o diagrama de comunicação é útil para entender as relações entre as classes

na dimensão espacial.

I.5.2.2.1 Diagrama de seqüência

Na UML 1.x este diagrama era denominado diagrama de colaboração e foi

rebatizado como diagrama de sequência na UML 2.0. Uma das mudanças que pode
ser destacada “[...] é a notação de quadro de interação para diagramas de
sequência, para lidar com controles de comportamento iterativos, condicionais e
vários outros [...]” (FOWLER, 2005, p.149).

Um diagrama de sequência é um dos diagramas de interação da UML, utilizado para

modelagem de aspectos dinâmicos do sistema. Segundo Guedes (2008, p.31), um
diagrama de sequência

“[...] preocupa-se com a ordem temporal em que as mensagens são

trocadas entre os objetos envolvidos em um determinado processo. Em
geral, baseia-se em um Caso de Uso definido pelo diagrama de mesmo
nome e apóia-se no Diagrama de Classes para determinar os objetos das
classes envolvidas em um processo”.

Como é sabido, os casos de uso descrevem como os atores interagem com um

sistema. Nesta interação um ator gera eventos reconhecidos pelo sistema,
geralmente solicitando alguma operação como uma resposta. Isolar e ilustrar estas
interações entre os atores e o sistema, entre os objetos que serão responsáveis
pelas operações que levarão à resposta solicitada, é uma parte importante para o
entendimento e compreensão de um sistema em colaboração. Para Booch (2000),
os diagramas de seqüência fazem exatamente este trabalho.

Segundo Larman (2004, p.140): um “[...] diagrama de seqüência de sistemas é uma

figura que mostra os eventos que os atores externos geram para um cenário
específico de um caso de uso [...]”. Eles são elaborados para os fluxos principais dos
 41

casos de uso mais comuns e para os casos alternativos mais complexos. Martins
(2004) reitera que este diagrama mostra as interações entre as classes de objetos,
através de trocas de mensagens, no decorrer do tempo.

O diagrama de sequência é extremamente minuncioso, podendo mesmo provocar

confusão na modelagem. Furlan (1998) diz ser difícil entender o fluxo de controle em
um programa orientado a objetos, já que o modelo terá diversas operações básicas,
que confudem a sequência geral do comportamento.

I.5.2.2.2 Diagrama de comunicação

Os elementos de um sistema trabalham em conjunto para cumprir os objetos do

sistema e uma linguagem de modelagem precisa poder representar esta
característica. O diagrama de comunicação é voltado a descrever objetos
interagindo e seus principais elementos sintáticos são objeto e mensagem.
Corresponde a um formato alternativo para descrever interações entre objetos. Ao
contrário do diagrama de seqüência, o tempo não é modelado explicitamente, uma
vez que a ordem das mensagens é definida através de enumeração. Não pode-se
esquecer que o diagrama de comunicação e o de seqüência são diagramas de
interação. Segundo Martins (2004) o diagrama de comunicação mostra as trocas de
mensagens com ênfase nas relações entre as classes. Tais interações devem ser
numeradas para indicar a seqüência de tempo.

I.5.2.2.3 Diagrama de visão geral

O diagrama de visão geral de interação é uma variação do diagrama de atividades,

proposto na versão atual da UML. Seus elementos sintáticos são os mesmos do
diagrama de atividades. As interações que fazem parte do diagrama de visão geral
de interação podem ser referências a diagramas de interação existentes na
 42

especificação tratada. De acordo com Melo (2004) o Diagrama de Visão Geral é

uma variação do diagrama de atividades, mostrando o fluxo de controle geral do
sistema. Para tal utiliza a notação do diagrama de atividades, onde os nós
(atividades) são interações ou ocorrências de interações.

I.5.2.2.4 Diagrama temporal

Introduzido na segunda versão da UML, o diagrama temporal consiste na

modelagem de restrições temporais do sistema, modelando a interação e a evolução
de estados. Segundo Melo (2004) este diagrama mostra a mudança de estado no
tempo, em resposta a eventos externos. Este diagrama é muito utilizado em
sistemas de tempo real, onde a determinação do tempo passa ser um fator crucial.

I.5.2.3 Diagrama de atividades

De acordo com Fowler (2005, p.149), os principais destaques relativos ao diagrama

de atividades na UML 2.0 podem ser assim resumidos:

A UML 1 tratava os diagramas de atividades como um caso de uso especial

do diagrama de estados. A UML 2 quebrou esse vínculo e, como resultado,
removeu as regras de correspondência de separações e junções que os
diagramas de atividades da UML 2 tinham que manter. (...) Assim apareceu
muita notação nova, incluindo sinais de tempo e de aceitação, parâmetros,
especificações de junção, pinos, transformações de fluxo, ancinhos de
subdiagrama, regiões de expansão e finais de fluxo.

O diagrama de atividades representa a execução das ações e as transições que são

acionadas pela conclusão de outras ações ou atividades. Uma atividade pode ser
descrita como um conjunto de ações e um conjunto de atividades. A diferença
 43

básica entre os dois conceitos que descrevem comportamento é que a ação é

atômica, admitindo particionamento, o que não se aplica a atividade, que pode ser
detalhada em atividades e ações (SILVA, 2007).

Um diagrama de atividades é utilizado para expressar aspectos dinâmicos de um

sistema, através da modelagem das etapas seqüenciais de um processo (BOOCH,
2000). Também fornece suporte para comportamento condicional e execução de
atividades em paralelo. O diagrama de atividades “[...] preocupa-se em descrever os
passos a serem percorridos para a conclusão de uma atividade específica, muitas
vezes representada por um método com certo grau de complexidade” (GUEDES,
2008, p.33). A atividade é um estado onde se está fazendo algo, tanto um processo
no mundo real, como a execução de um modelo de uma classe em um determinado
software (FOWLER, 2005).

Segundo Furlan (1998) este diagrama é útil quando o analista deseja descrever um
comportamento paralelo ou interação entre os comportamentos de vários casos de
usos.

I.5.2.4 Diagrama de máquina de estados

Destaca-se a mudança no tratamento entre as atividades de vida curta e as de vida

longa: “A UML 1 separava as ações de vida curta das atividades de vida longa. A
UML 2 chama as duas de atividades e usa o termo realizar-atividade para as
atividades de vida longa” (Fowler, 2005, p.149).

Os elementos principais de um diagrama de máquina de estados são o estado e a

transição. O estado modela uma situação em que o elemento modelado pode estar
ao longo de sua existência, e a transição leva o elemento modelado de um estado
para o outro. O diagrama de máquina de estados vê os objetos como máquinas de
estados ou autômatos finitos que poderão estar em um estado pertencente a uma
 44

lista de estados finita e que poderão mudar o seu estado através de um estímulo
pertencente a um conjunto finito de estímulos. Para Furlan (1988), além do estado e
da transição, este diagrama também inclui o subestado e o evento. O subestado é
um estado que parte de um estado composto, podendo ser simultâneo ou
seqüencial, e o evento é toda ocorrência significativa que deve ser reconhecida pelo
sistema. Ele ainda enfatiza que a transição é um relacionamento entre dois estados,
indicando que houve mudança de estado e que determinadas ações foram
executadas. A desvantagem deste diagrama é ter de definir todos os estados
possíveis, tarefa difícil em sistemas complexos (FURLAN, 1988).

Na visão de Martins (2004) o diagrama de estados mostra o comportamento

dinâmico de uma classe, componente, subsistema ou objeto. Para Melo (2004) este
diagrama cobre o ciclo de vida do objeto, passando por vários estados em uma
seqüência lógica e cronológica.

I.5.3. Revisões 2.x da UML

A UML não pára de crescer e o OMG continua lançando atualizações, que podem
ser acompanhadas em seu sítio www.omg.org/UML:
 UML 2.1: uma versão que nunca foi lançada oficialmente como uma
especificação formal
 UML 2.1.1: versão lançada em agosto de 2007;
 UML 2.1.2: versão lançada em novembro de 2007;
 UML 2.2: versão lançada em fevereiro de 2009;
 UML 2.3: próxima versão, cuja revisão está em andamento desde setembro
de 2009
 45

I.6 A IMPORTÂNCIA DO AMADURECIMENTO DA UML

Uma linguagem de modelagem unificada é um fator essencial e necessário à

modelagem de qualquer sistema, principalmente os complexos, que não podem ser
visualizados em sua totalidade. No decorrer da história a UML amadureceu e hoje é
uma metodologia capaz de integrar as melhores práticas da indústria, com ampla
cobertura sobre diferentes visões nos níveis de abstração, arquiteturas, domínios,
ciclo de vida, tecnologias de aplicação e etc.

É unanimidade entre os principais autores que a UML é uma linguagem de

modelagem e não um método de desenvolvimento de sistemas. A UML conduz à
criação de modelos que possibilitam a visualização de diversos cenários do sistema,
mas não determina os modelos que serão criados, responsabilidade do processo de
desenvolvimento. Desta forma, a UML pode ser utilizada com qualquer processo de
desenvolvimento de software.

A UML é uma linguagem de modelagem que auxilia na definição das características

do software, características essas, como: seus requisitos, seu comportamento, sua
estrutura lógica, a dinâmica de seus processos e inclusive suas necessidades físicas
em relação ao equipamento sobre o qual o sistema deverá ser implantado
(GUEDES, 2007).

De acordo com Martins (2004), muitos desenvolvedores modelam os sistemas

apenas em suas mentes, provocando problemas, como: difícil comunicação do
modelo conceitual com o resto da equipe; alguns elementos não são bem projetados
e daí são entendidos apenas com uma linguagem de programação; o conhecimento
fica centralizado em apenas um desenvolvedor.

Neste contexto, a UML acabou com as diversas diferenças entres os processos de

desenvolvimento, unificando a comunicação entre os envolvidos no projeto, evitando
ambigüidades, independente da complexidade e segmento de negócio do sistema
em questão.
 46

Para Furlan(1998, p.34-36), a UML

[...] é um passo natural na escala de evolução com objetivo de: a) fornecer

aos usuários uma linguagem de modelagem visual expressiva e pronta para
uso visando o desenvolvimento de modelos de negócio; b) fornecer
mecanismos de extensibilidade e de especialização para apoiar os
conceitos essenciais; c) ser independente de linguagens de programação e
processos de desenvolvimento; d) prover uma base formal para entender a
linguagem de modelagem; e) encorajar o crescimento no número de
ferramentas orientadas a objeto no mercado; f) suportar conceitos de
desenvolvimento de nível mais elevado tais como colaborações, estrutura
de trabalho, padrões e componentes e; g) integrar as melhores práticas.

Além disso, Martins (2004) considera que o desenvolvimento de software deve ser
realizado utilizando um processo de desenvolvimento de sistemas consistente e
sedimentado no mercado, como por exemplo, RUP, e utilizando gerenciamento de
projetos, com suas áreas de conhecimento: gerenciamento do escopo, riscos, custo,
tempo, qualidade, dentre outros.

I.7 PERSPECTIVAS DA UML

A UML do futuro deverá tratar efetivamente as recorrentes complexidades

arquitetônicas em todas as suas escalas e domínios. Problemas como replicação,
segurança, balanceamento de carga, tolerância a falhas e distribuição física deverão
ser gerenciados por um conjunto de semântica e notações que aumentem o valor
estratégico da indústria do software.

A maioria dos autores defende que a UML será a linguagem de modelagem OO

padrão predominante nos próximos anos. A UML será a base para muitas
ferramentas de desenvolvimento, incluindo modelagem visual, simulações e
ambientes de desenvolvimento. A integração que a UML trouxe vai acelerar o uso do
desenvolvimento de softwares orientados a objetos. Fatores descritos nesta
pesquisa demonstram essa expectativa para a UML, como: participação de
 47

metodologistas de renome, participação de importantes empresas e aceitação pela

comunidade internacional como notação padrão , através do OMG.

A partir das revisões em andamento e futuras, diversas alterações podem surgir

livremente, onde os usuários customizarão a linguagem e adicionarão as
características que melhor descrevam suas regras de negócio. Os estudiosos
prevêem que ocorrerá uma evolução significativa quando os ambientes de
desenvolvimento suportarem os diagramas permitindo múltiplas visões do negócio.
A tendência será de um acoplamento através das extensões e modificações da UML
às frameworks de desenvolvimento, como o J2EE e .NET. Kobryn (2004) diz que a
evolução futura da UML poderá seguir dois caminhos. O primeiro, resolver os
problemas já conhecidos com a UML 2.0, utilizando o padrão de forma correta e
eficiente, ou seja, evoluindo no futuro. O segundo, evitar o desafio, criando novos
padrões de sintaxes e semânticas sem destino certo, modelando com linguagem
genérica, ou seja, retrocedendo para o passado.

É evidente que a história dinâmica da UML será honrada à medida que evoluir a
partir dos padrões já aceitos na atualidade, na busca constante por atender as mais
exigentes complexidades de software que ainda surgirem. Qualquer proposta de
modelagem que surgir deverá ser superior aos padrões atuais. Foi assim que
aconteceu quando a UML nasceu a partir da evolução das metodologias anteriores.

A UML revolucionou a metodologia de desenvolvimento de sistemas, tornando-se

uma linguagem padrão para o desenho orientado a objetos de todas as
metodologias. As revisões que forjaram a UML incorporaram vários diagramas,
visando atender as demandas oriundas da alta complexidade dos softwares. As
revisões apresentaram uma UML 2.0 bastante amadurecida em relação à UML 0.8.
Os diagramas atuais propiciam um entendimento global dos sistemas a serem
desenvolvimentos, inclusive antecipando as falhas do modelo.

O sucesso dos projetos de software passa por alianças concretas da UML com as
áreas de conhecimento da gerência de projeto no ciclo de desenvolvimento de um
sistema. É indispensável considerar que os requisitos de um software podem mudar
– e mudam! – durante a fase de desenvolvimento. Os diagramas da UML avaliam e
tratam as mudanças de escopo, prevendo os seus impactos.
 48

CAPÍTULO II – CONSIDERAÇÕES FINAIS

No transcurso deste trabalho foi possível desfrutar do privilégio de conhecer e

descrever a origem da UML, com seus conflitos, processos de aceitação e
padronização, e sua conseqüente aplicação na indústria de software.
 49

A tarefa foi árdua porque há um emaranhado de datas e versões na literatura

especializada, que geraram muitas dúvidas e ao mesmo tempo a motivação para
continuar pesquisando em busca de soluções e respostas aos questionamentos.
Através de muita leitura e esforços para confrontar os diversos autores, foi possível,
aos poucos, descrever a UML na linha do tempo. A pesquisa mostrou ser uma
contribuição extremamente importante ao conhecimento da modelagem de sistemas,
porque exigiu um consenso mínimo na descrição das versões e dos diagramas da
UML no plano histórico.

A todos os que estão envolvidos com desenvolvimento de sistemas, é sugerido

conhecer a história da UML, que resultará em um interesse crescente pela
linguagem de modelagem unificada.

A recomendação a favor do interesse pela história do UML é intensificada por uma

declaração inquestionável: a UML conhecida e utilizada hoje é um padrão que
evoluiu na história. Hoje ela está presente no desenho utilizado nos mais diversos
segmentos de software, facilitando a compreensão e a comunicação entre as
equipes envolvidas. Ao mesmo tempo em que a UML atual facilita a compreensão
dos sistemas modernos, ela aumenta o desafio da engenharia de software, pois a
tarefa de modelar e desenvolver software deve ser sempre encarada como um
grande desafio, onde cada sistema deve ser construído com o objetivo de atender os
mais exigentes requisitos e regras de negócio, produzindo uma documentação
científica consistente, que seja base para futuras evoluções, tanto dos sistemas,
quando da UML.

GLOSSÁRIO

Artefatos – diagramas e documentos

CASE – do inglês Computer-Aided Software Engineering, é uma classificação que
abrange toda ferramenta baseada em computadores que auxiliam atividades de
engenharia de software, desde análise de requisitos e modelagem até programação
e testes.
 50

Classes – coleção de objetos com propriedades, comportamento e relacionamentos

comuns
Estereótipo – é uma extensão do vocabulário de UML, permitindo a criação de
novos tipos de blocos de construção semelhante aos existentes, mas específicos a
determinado problema
Frameworks – base para o desenvolvimento de um sistema, que pode ser um
código-fonte, classes, funções, técnicas ou metodologias
Modelo – são abstrações semanticamente fechadas de um sistema, representando
uma simplificação consistente e completa da realidade.
Nó – dispositivo conectado a uma rede
Nota – símbolo gráfico para representação de restrições ou de comentários
anexados a um elemento ou a uma coleção de elementos.
Objeto – representação de um conceito real, que possui estados, operações e
dados
Pacotes – estrutura de dados unitária de transmissão em uma rede de
computadores ou telecomunicações.
Restrição – é uma extensão da semântica de um elemento da UML, permitindo
adicionar novas regras ou modificar as existentes.
Singleton – padrão de projeto de software
Sistema – coleção de subsistemas organizados para a realização de um objetivo e
descritos por um conjunto de modelos.
Software – é uma sequência de instruções a serem seguidas e/ou executadas, na
manipulação, redirecionamento ou modificação de um dado/informação ou
acontecimento.
Top-down – modelo descendente de modelagem, que decompõe o sistema do geral
para o específico
UML – do inglês Unified Moldeling Language, é a linguagem de modelagem
unificada.
Visão – abrange um subconjunto de itens que pertencem a um modelo, cujo foco
esta voltado para um único aspecto do
WEB – do inglês World Wide Web, é um sistema de documentos hipermídia que são
interligados e executados na internet.
Workflow – descrição de processo.
 51

BIBLIOGRAFIA

BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 3ª

ed. São Paulo: Elsevier - Campus, 2002.

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML Guia Prático do Usuário. São
Paulo: Campus, 2000.

DEMARCO, T. Análise Estruturada e Especificação de Sistemas. Rio de Janeiro:

Campus, 1989.
 52

COAD, Peter & YOURDON, Edward. Análise baseada em Objetos. 2ª ed. Rio de
Janeiro: Campus, 1992.

DEITEL, H.M; DEITEL, P. J. Java: Como Programar. 6ª Ed. São Paulo: Pearson
Education do Brasil, 2005.

DEREK, C et al. Desenvolvimento Orientado a Objetos: O Método Fusion. Rio de

Janeiro: Campus, 1996.

FOWLER, Martin. UML Essencial: um breve guia para a linguagem-padrão de

modelagem de dados. 3ª Ed. Porto Alegre: Bookman, 2005.

FURLAN, José Davi. Modelagem de Objetos Através da UML: análise e desenho

orientados a objeto. São Paulo: Makron Books, 1998.

GUEDES, Gilleanes. UML: Uma Abordagem Prática. 3ª Ed. Rio de Janeiro: Novatec,
2008.

JACOBSON, I; BOOCH, G.; RUMBAUGH, J. The Unified Development Process,

Addison-Wesley, 1999

LARMAN, Craig. Utilizando UML e Padrões: uma introdução à análise e ao

projeto orientados a objetos e ao Processo Unificado. 2ª ed. Porto Alegre:
Bookman, 2004.

KOBRYN, Cris. UML 3.0 and the future of modeling. Springer-Verlag: Fallbrook,
2004 

MARTINS, José Carlos Cordeiro. Gerenciamento de projetos de

desenvolvimento de software com PMI, RUP e UML. Rio de Janeiro: Brasport,
2004.

MCMENAMIM, S. M., PALMER, J. F. Análise Essencial de Sistemas. São Paulo:

Makron Books, 1991.

MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.0: do conceitual à

implementação. 2ª ed. Rio de Janeiro: Brasport, 2004.

OMG. OCL 2.0 Specification. 2005a.

OMG. Unified Modeling Language: superstructure. 2005b.

OMG. Unified Modeling Language: infrastructure. 2006.

PAGE-JONES, Meilir (2001) – Fundamentos do desenho orientado a objeto com

UML. São Paulo: Makron Books, 2001.

PRESSMAN, R. S. Engenharia de Software. São Paulo: 6ª ed. Makron Books,

2006.
 53

RUMBAUGH, J et al. Modelagem e Projetos Baseados em Objetos. Rio de

Janeiro: Campus, 1991.

SAMPAIO, Marcus. UML - Unified Modeling Language. Uma breve história.

Disponível em <http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/>. Acesso
em 22 dez 2009

SILVA, R. P. e. UML 2 em Modelagem Orientada a Objetos. Florianópolis: Visual

Books, 2007.

SILVA, A. M. R.; VIDEIRA, C. A. E. UML, Metodologias e Ferramentas CASE. 2ª

ed. Lisboa: Editora Centro Atlântico, 2005

SOUZA, Cleidson. Introdução a UML. Disponível em:

<http://www.ufpa.br/cdesouza/teaching/cedai/4-uml-introduction.pdf> Acesso em
14/01/2010

YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1990.

Documentação oficial da UML. Disponível em : <http://www.rational.com/uml>

Acesso em 12/01/2010

Especificação oficial da UML. Disponível em <http://www.omg.org./UML>. Acesso

em 05/01/2010