Linguagem de Modelagem Orientada a Objetos.

Histórico e
Aplicabilidade da UML(Unified Modeling Language)
André Ricardo Gnhoato1, Antônio Carlos Gimenez Junior1, Henrique Kazuo
Matsumoto1
1
Instituto de Informática –Universidade Tecnológica Federal do Paraná – Campi
Medianeira (UTFPR-MD)
Avenida Brasil, nº 4232 - CEP 85.884-000 - CP 271–Medianeira – PR – Brasil

andregnhoato@gmail.com, juniorgimenez@hotmail.com,
henriquekm@gmail.com
Abstract. This article presents the historical evolution of languages and
methodology, before the implementation of the UML 0.8. During the same will
be addressed to some authors, companies and organizations that were central
to what we now call UML
Resumo. Este artigo apresenta o histórico evolutivo das linguagens e
metodologia, antes da concretização da UML 0.8. No decorrer do mesmo será
abordado alguns autores, empresas e organizações que foram fundamentais
para o que chamamos hoje de UML.

1. Introdução
Com a criação do computador, surgiu um leque de novas tecnologias e produtos, o
desenvolvimento de softwares encaixa-se nesse leque. Com o passar do tempo foi
criando alguns métodos par a criação dessas ferramentas, mas como tudo que é recente,
ainda mais na área de tecnologia, exige um certo período para aperfeiçoamento e
padronização. O surgimento da orientação a objetos deu-se por volta dos anos 60, sendo
criadas algumas linguagens para a modelagem somente depois de algumas décadas, mas
de uma forma desorganizada. Na época o desenvolvedor escolhia um método qualquer
como base e procuravam utilizar as boas ideias e soluções dos outros métodos. Heis que
surge então um método de modelagem unificado, a UML.

2. Linguagens de Modelagem
As linguagens de modelagem orientadas a objetos surgiram entre a metade da década de
1970 e o final da década de 1980, à medida que o pessoal envolvido com metodologia,
diante de um novo gênero de linguagens de programação orientadas a objeto e de
aplicações cada vez mais complexas, começou a experimentar métodos alternativos de
análise e projeto. A quantidade de métodos orientados a objetos aumentou de pouco
mais de 10 para mais de 50 durante o período de 1989 a 1994. Muitos usuários desses
métodos tiveram dificuldades para encontrar uma linguagem de modelagem capaz de
atender inteiramente às suas necessidades.
Dentre todas essas linguagens, algumas se destacaram, mas todos eram métodos
completos, alguns se destacavam em algum ponto, porém tinham suas limitações.
Alguns destacava-se durante as fases de projeto e construção de sistemas, outros
forneciam excelente suporte para captura de requisitos, a análise e o projeto em alto
nível, e ainda tinha um terceiro que era mais útil com a análise e sistemas de
informações com uso de dados(FOWLER, 2005).

2.1. OOAD – Grady Booch

Analise e Design Orientado a Objetos (OOAD) é uma engenharia de software que
aborda os modelos de um sistema como um grupo de objetos interagindo. Cada objeto
representa uma entidade de interesse no sistema a ser modelado, e é caracterizada por
sua classe, seu estado de elementos (de dados), e seu comportamento. Vários modelos
podem ser criados para mostrar a estrutura estática, comportamento dinâmico, e de
tempo de implantação destes objetos de colaboração.
Análise orientada a objetos (OOA) aplica-se a objetos técnicas de modelagem
para analisar os requisitos funcionais para um sistema. Design orientado a objetos
(OOD) elabora os modelos de análise para produzir especificações de
implementação. OOA enfoca que o sistema faz, OOD sobre como o sistema faz
isso.(VARGAS, 2007).

2.2. OOSE – Jacobson

A metodologia OOSE é uma metodologia orientada a objetos, desenvolvida por Ivar
Jacobson em 1992, foi a primeira metodologia de projeto orientado á objeto a utilizar
casos de uso para definir os paradigmas do projeto de Software, cuja abordagem é
classificada como dirigida a cenário. O desenvolvimento de uma aplicação passa pelas
etapas de análise e construção. Na análise é construído um modelo de requisitos, que
apresenta uma especificação do sistema sob a ótica de um observador externo, e o
modelo de análise, que faz uma primeira aproximação da descrição interna do sistema.
Os autores estabelecem que a preocupação da análise é produzir uma descrição de
sistema independente da realidade de implementação. Não há grande preocupação nesta
etapa em definir atributos e serviços, o que é protelado para o projeto - os autores
preferem nesta etapa definir papéis e responsabilidades dos elementos do sistema.
A etapa chamada de construção se divide em projeto e implementação. A etapa
de projeto, onde é construído o modelo de projeto, visa "formalizar" o modelo de
análise e completá-lo com detalhes de implementação.
O principal elemento de descrição da metodologia são os casos de uso(USE
CASES). Os casos de uso são as situações a que o sistema pode ser submetido, ou seja,
as situações de processamento a que o sistema deve responder. As várias etapas de
descrição de um sistema em OOSE se baseiam na definição de casos de uso.
Engenharia de Software Orientada á Objeto (OOSE) é uma linguagem de
modelagem de objetos como também uma metodologia, desenvolvida por Ivar Jacobson
em 1992, foi a primeira metodologia de projeto orientado á objeto a utilizar casos de
uso para definir os paradigmas do projeto de Software. (VARGAS, 2007).
 Fonte: http://fit.faccat.br/~franzen/analise2/oose/

Figure 1: O modelo OOSE

2.3. OMT – Jim Rumbaugh

Segundo Rumbaugh a metodologia OMT (Técnica de de Modelagem de Objetos)
desenvolvido em 1991, se propõe a gerar um projeto de sistema a ser implementado em
linguagem orientada a objeto ou não. Para tanto, utiliza diferentes modelos de
representação, tendo cada um maior ou menor importância, em função de aspectos
como tipo de aplicação e linguagem de programação. Preconiza a construção de um
modelo do domínio de aplicação tratado (análise) e na posterior adição a este modelo,
dos detalhes de implementação (projeto).
A mesma descrição do domínio do problema será usada ao longo da análise e
projeto, sendo enriquecida em informações ao longo desta evolução. A metodologia
OMT utiliza três tipos de modelos para descrever um sistema: o modelo de objetos, que
descreve a estrutura estática de dados do sistema, ou seja, os objetos e seus
relacionamentos; o modelo dinâmico16, que descreve a sequencia de interações entre os
objetos do sistema e o modelo funcional, que descreve as transformações de valores dos
dados procedidas pelo sistema. (VARGAS, 2007).

2.4. COLEMAN – FUSION

A metodologia FUSION é uma metodologia orientada a objetos, cuja abordagem é
classificada como dirigida a dado. O desenvolvimento de uma aplicação passa pelas
etapas de análise, projeto e implementação. Na análise é construído o modelo de objetos
e o modelo de interface.
rface. O modelo de objetos de FUSION é muito semelhante ao
modelo de objetos de OMT, ou seja, com uma semântica muito próxima aos diagramas
ER. O modelo de interface contém a modelagem dinâmica desenvolvida na etapa de
análise. Durante a análise não existe a noção de método de classe, mas de operações do
sistema. São identificadas as possíveis interações do sistema a desenvolver com seu
meio externo - as "operações" - de uma forma semelhante à construção do modelo de
requisitos de OOSE. Após, as operações são são detalhadas. Na descrição das operações
durante a análise, o sistema é sempre visto como um todo, e nunca como um conjunto
de objetos interagindo.
Durante o projeto é produzida uma descrição do conjunto de classes, visando à
implementação - são definidos
efinidos novos atributos e o conjunto de métodos. O projeto
utiliza modelos diferentes dos modelos da análise. A especificação é composta pelos
modelos da análise e pelos modelos de projeto.
A implementação consiste na tradução da especificação produzida,
produzida, em linguagem
de programação. (VARGAS, 2007).

2.5. MARTIN e ODELL

A metodologia de MARTIN e ODELL, a nível de análise, trabalha com uma visão em
que os atributos de um objeto sob descrição correspondem a outros objetos associados a
ele. Conceitualmente, não há em princípio, afronta ao paradigma de orientação a
objetos, em que todos os dados são objetos. Porém, a descrição gerada na análise tende
a diferir bastante daquela gerada nas metodologias citadas, extrapolando como se
demonstrará no próximo item, os princípios estabelecidos pelo paradigma de orientação
a objetos.
A metodologia de Martin e Odell caracteriza-se como uma metodologia
propriamente dita, apenas para análise. A nível de projeto os autores sugerem o
refinamento dos modelos de análise, porém não propõem uma sequencia de passos,
apenas estabelecem diretrizes a serem seguidas, bem como não estabelecem técnicas de
modelagem adicionais, por exemplo, para a descrição de algoritmos.
Segundo Martin e Odell, uma metodologia deve se apoiar numa base dinâmica que
incorpore a estrutural. Assim, a ênfase da metodologia de análise é a construção do
esquema de eventos; paralelamente aos passos desta construção, a descrição estática vai
sendo composta. No projeto é proposto um refinamento dos modelos da análise visando
chegar a operações básicas, e um mapeamento dos elementos dos modelos gerados para
a estrutura de uma linguagem de programação orientada a objetos. (VARGAS, 2007).

2.6. Coad e Yourdon

A metodologia de Coad e Yourdon é classificada como uma metodologia orientada a
objetos, dirigida a dado. A partir da necessidade estabelecida e do conhecimento do
domínio de aplicação, é construído um modelo do domínio (análise). A evolução da
descrição da análise para o projeto se dá a partir da inclusão ao modelo, de classes
pertencentes ao domínio da solução computacional. A mesma notação é utilizada na
análise e no projeto.
A metodologia utiliza como principal ferramenta de descrição, um modelo de
objetos. Como mecanismo auxiliar, utiliza "especificações de classe-&-objeto" para
detalhes não representados no modelo de objetos, como modelagem dinâmica
(incluindo descrição dos algoritmos dos métodos). Estas "especificações de classe-&-
objeto" misturam descrição textual, com técnicas de modelagem gráficas. (VARGAS,
2007).

3. Histórico Evolutivo
Todas essas linguagens e autores citados anteriormente lançaram seus métodos através
de livros, lançados entre 1988 e 1992, onde cada autor liderava uma espécie de grupo de
profissionais que gostavam daquela metodologia. Todos os métodos eram muito
parecidos, apesar de conterem várias pequenas diferenças entre si. Já nessa época houve
rumores sobre a padronização dos métodos, uma equipe da OMG1 (Object Management
Group) tentou fazer uma analise dos métodos para chegar numa padronização, isso

1
O Object Management Group, ou OMG, é uma organização internacional que aprova
padrões abertos para aplicações orientadas a objetos, OMG foi fundado em 1989.
gerou uma protesto de todos os metodologistas importantes da época, no fim nada foi
feito.(FOWLER, 2005)

3.1. Criação da UML

A criação da UML deu-se, quando Jim Rumbaugh deixou a General Eletric e se uniu a
Grady Booch, da Rational (empresa que pertencia a IBM nesta data). Essa aliança foi
vista com olhos gordos, pois seria a que podia obter uma boa fatia de mercado. Os dois
declararam, “Acabou a guerra entre os métodos. Nós vencemos”. Sendo essa a
padronização tão indesejada pelos outros metodologistas, que até tentaram criar uma
aliança contra. (FOWLER, 2005).
Em 1995 a dupla tinha preparado a versão 0.8, como mostra a figure 2,
lançando-a em uma conferencia chamada OOPSLA2, nessa conferencia anunciaram
também que a Rational Software, tinha comprado a Objectory, pertencente a Ivar
Jacobson, trazendo assim mais um metodologista respeitado para o grupo.
No ano seguinte a Rational adicionou as ideias de Jacobson, e também a OMG
decidiu se envolver mais significativamente. Isso deu-se por causa de pedidos de
fornecedores de ferramentas, e não dos metodologistas, por medo que um padrão
controlado pela Rational desse uma vantagem competitiva desleal à essa empresa. Os
fornecedores sugeriram a OMG fazer algo sobre a ferramenta CASE, pois era sua
estrutura era voltado para essa ferramenta, então a ideia foi criar a UML que permitisse
às ferramentas CASE trocar de modelos livremente.
Em 1997, foi lançada a verção 1.0 da UML, nela continha grande parte dos
conceitos dos métodos, BOOCH, OMT e OOSE, e mais, foi incluído também alguns
conceitos de outros métodos.

2
OOPSLA é uma conferência anual que abrange temas sobre sistemas de programação
orientados a objeto, linguagens e aplicações. Como em outras conferências, OOPSLA
oferece várias trilhas e muitas sessões simultâneas e, portanto, tem um significado
diferente para pessoas diferentes. É mais do que algumas conferências acadêmicas, com
estudantes de doutorado que apresenta papéis de crédito
 Figure 2. Linha do tempo da UML

3.2. Aceitação da UML

Para estabelecer a UML, os desenvolvedores e a Rational perceberam que a linguagem
teria que estar disponível para todos. Consequentemente,
Consequentemente, a linguagem não é proprietária
e é aberta a todos. As companhias são livres para utilizá-la
utilizá la com seus próprios métodos.
Empresas de software são livres para criarem ferramentas para a utilização da UML.
Autores são encorajados a escrever sobre
sob o assunto.
Durante 1996, algumas companhias associaram-se
associaram se à Rational para formar um
consórcio de parceiros da UML.Estas organizações reconheceram a UML como
estratégica para seus negócios e estão dispostas a contribuir para a definição da UML.
Naturalmente
nte estas estão interessadas em privilegiar suas áreas de atuação na definição.
Esta diferentes companhias até janeiro de 1997 eram: Digital Equipment Corporation,
HP, I-Logix,
Logix, Intellicorp, IBM, ICON computing, MCI Systemhouse, Microsoft, Oracle,
Texas Instruments,
truments, Unisys, e claro, a Rational. Estas companhias estão também dando
suporte na proposta de adaptar a UML como padrão para linguagens de modelagem no
OMG - Grupo de Gerenciamento de Objetos.
4. Padronização OMG
Quando o trabalho com a UML iniciou, era a intenção de estalebelce-la como uma
padronização de fato, o que significa que através do uso por muitos desenvolvedores ela
seria reconhecida como a principal linguagem de modelagem. Contudo, quando a OMG
fez um requerimento por uma linguagem padrão de modelagem, os desenvolvedores da
UML perceberam que poderiam fazer a UML aceita como uma padronização formal e
aprimoraram a qualidade da linguagem. Uma padronização formal é importante para
várias indústrias antes de estarem dispostas a utilizar a nova tecnologia, como os
desenvolvedores de sistemas militares.
Seguiu-se então, um pequeno período de queda de braço, enquanto várias propostas
eram unificadas, a OMG adotou a versão 1.1 resultante domo o padrão oficial da OMG.
Posteriormente foram feitas revisões. A revisão 1.2 foi somente para melhorar as
aparências, mas a 1.3 foi mais significativa. A revisão 1.4 acrescentou vários conceitos
detalhados relativos a componentes e a perfis. A revisão 1.5 adicionou semântica de
ação.
A notação UML foi concebida pela primeira vez no método unificado de
Booch/Rumbaugh, desde então grande parte do trabalho foi liderado pelos comitês do
OMG, durante estes estágios posteriores Jim Rumbaugh foi o único a ter
comprometimento de forma intensa. Engana-se portanto que crê que Jim Rumbaugh,
Ivar Jacobson e Grady Booch foram os criadores da UML, quem merece esse status, são
os membros dos comitês da OMG relativo a UML.

References
Fowler, Martin
UML Essencial, um breve guia para a linguagem-padrão de modelagem de
objetos/Martin Fowler; trad. João Tortello. – 3.ed. – Porto Alegre: Bookman, 2005d.
NOGUEIRA, A. UML – Introdução e Histórico.
http://www.linhadecodigo.com.br/Artigo.aspx?id=763: [s.n.], 2005.
VARGAS, T. C. S. História da UML e seus diagramas.
http://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/artigo.tcc.pdf

http://fit.faccat.br/~franzen/analise2/oose/ acessado em 20/03 15:30

http://en.wikipedia.org/wiki/OOAD acessado em 20/03 14:00
http://cs-exhibitions.uni-klu.ac.at/index.php?id=449 acessado em 20/03 16:22
http://www.uml.org/ acessado em 21/03 9:13
http://pt.wikipedia.org/wiki/Object_Management_Group acessado em 21/03