Esse artigo faz parte da revista SQL Magazine edição 61. Clique aqui para ler todos os artigos desta edição

img

os.

 

Introdução

Um dos problemas de se adotar a metodologia orientada a objetos nas etapas de análise de requisitos e análise de sistemas era o fato de não existir uma notação padronizada que realmente fosse eficiente e conseguisse retratar a aplicação a ser desenvolvida de forma completa.

Do mesmo modo que é impossível construir um prédio sem que antes se tenha a definição de uma planta e todo um planejamento prévio, é impossível construir um software eficiente sem definir sua arquitetura.

Segundo Philippe Kruchten da empresa Rational, programar é divertido, mas desenvolver software de qualidade é difícil. Entre ótimas idéias, requisitos ou “visões” e um produto de software que funcione, existe muito mais do que simplesmente programar.

Ao longo do tempo, muitas simbologias foram desenvolvidas, cada uma com seus próprios conceitos, sugerindo soluções milagrosas. O resultado destas várias terminologias e símbolos foi uma grande confusão de conceitos, principalmente para os que desejavam utilizar orientação a objetos além das setas e seus relacionamentos. Esta busca pela modelagem padrão parece ter chegado ao fim com o surgimento da UML.

Neste artigo abordaremos a UML mostrando em um primeiro momento seu contexto histórico, seus objetivos e principais ferramentas. Em seguida, veremos como podemos utilizá-la e por onde começar.

 

Histórico da UML

UML e linguagens de programação orientadas a objetos, a história de ambas se confundem. Além de compartilharem algumas vantagens, dividem também o contexto histórico de criação e maturidade.         

Entre a metade da década de 70 e final da década de 80, surgem as linguagens de programação orientadas a objetos. Diante de um novo gênero de linguagem de programação, surgem aplicações cada dia mais complexas, com uma necessidade mais aguçada de experimentar novos métodos 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 [Nogueira, 2008].

Durante este período, destacaram-se alguns métodos de análise como o Booch, o OOSE (Object-Oriented Software Engineering) de Jacobson, e o OMT (Object Modeling Technique) de Rumbaugh. Podemos citar outros métodos importantes como Fusion, Shlaer-Mellor e Coad-Yourdon. Todos eram métodos completos, alguns se destacavam em algum ponto, porém tinham suas limitações. O método Booch destacava-se durante as fases de projeto e construção de sistemas, o OOSE fornecia excelente suporte para captura de requisitos, a análise e o projeto em alto nível; o OMT-2 era mais útil com a análise e sistemas de informações com uso de dados [Booch, 2000].

A Linguagem de Modelagem Unificada (UML) emergiu como a notação diagramática padrão para a modelagem orientada a objetos. Ela começou como um esforço conjunto de Grady Booch e Jim Rumbaugh, em 1994, para combinar as notações diagramáticas dos seus dois difundidos e populares métodos – o Booch e OMT (Object Modeling Technique). Posteriormente, se juntou a eles Ivar Jacobson, o criador do método Objectory, e, como grupo, os três passaram a ser conhecidos como “os três amigos” (ver Figura 1).

 

img

Figura 1. UML é uma linguagem que concentra as melhores características e práticas dos métodos Booch, OMT e Objectory.

 

...

Quer ler esse conteúdo completo? Tenha acesso completo