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.

AGRADECIMENTOSA 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

22

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

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 [...]”.

23

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.

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).

24

I.3.2 UML 0.9

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

25

no caminho do crescimento. Consequentemente muitos esforços ainda seriam

empreendidos.

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

26

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 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;

27

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;

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 ─

28

de fato, está baseado no diagrama de evento de Odell com uma notação

diferente de seus livros” (FURLAN, 1998, p.219);

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)

33

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:

[...] 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.

37

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

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

38

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

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

39

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

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.

40

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

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.

41

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

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

42

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

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.

43

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

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).

44

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

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;

45

UML 2.3: próxima versão, cuja revisão está em andamento desde setembro

de 2009

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.

46

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.

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.

47

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

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.

48

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.

49

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.

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.

50

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.

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

51

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.

52

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.

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.

53

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.

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