Diagrama UML

Conteúdo

 [esconder] 

• 1 História
• 1.1 Antes da UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Desenho
• 2.1 Métodos de desenvolvimento de software
• 2.2 Modelagem
• 3 Diagramas
• 3.1 Diagramas de estrutura
• 3.2 Diagramas de comportamento
• 3.2.1 Diagramas de interação
• 4 Meta modelagem
• 5 Adoção
• 6 Críticas
• 6.1 Crítica da UML 1.x

História [editar fonte | editar]

História dos métodos e notações orientadas a objetos

A UML vem evoluindo desde a segunda metade dos anos 90 e tem suas raízes nos métodos orientados a objetos desenvolvidos no final dos anos 80 e início dos anos 90. A linha do tempo (ver imagem) mostra os destaques da história dos métodos e notações de modelagem orientada a objetos.

Ela se baseia originalmente nas notações do método Booch, a técnica de modelagem de objetos (OMT) e a engenharia de software orientada a objetos (OOSE), que ela integrou em uma única linguagem. ^[5]

Antes de UML 1.x [editar fonte | editar]

A Rational Software Corporation contratou James Rumbaugh da General Electric em 1994 e depois disso a empresa tornou-se a fonte para duas das mais populares abordagens de modelagem orientada a objetos da época:^{[6] A} técnica de modelagem de objetos (OMT) de Rumbaugh e o método de Grady Booch. Eles foram logo auxiliados em seus esforços por Ivar Jacobson, o criador do método de engenharia de software orientado a objeto (OOSE), que se juntou a eles na Rational em 1995^[1].

Sob a liderança técnica desses três (Rumbaugh, Jacobson e Booch), um consórcio chamado UML Partnerswas foi organizado em 1996 para completar a especificação da Linguagem de Modelagem Unificada (UML), e propô-la ao Grupo de Gerenciamento de Objetos (OMG) para padronização. A parceria também continha partes interessadas adicionais (por exemplo, HP, DEC, IBM e Microsoft). A minuta UML 1.0 dos parceiros UML foi proposta ao OMG em janeiro de 1997 pelo consórcio. Durante o mesmo mês, os Parceiros UML formaram um grupo, projetado para definir o significado exato das construções lingüísticas, presidido por Cris Kobryn e administrado por Ed Eykholt, para finalizar a especificação e integrá-la com outros esforços de padronização. O resultado deste trabalho, UML 1.1, foi submetido à OMG em agosto de 1997 e adotado pela OMG em novembro de 1997^[1][7].

UML 1.x[edit source | edit]

Após o primeiro lançamento foi formada uma força-tarefa^[1] para melhorar a linguagem, que liberou várias revisões menores, 1.3, 1.4, e 1.5^[8].

As normas que produziu (assim como a norma original) foram observadas como sendo ambíguas e inconsistentes. ^[9][10]

UML 2.x[edit source | edit]

A revisão principal da UML 2.0 substituiu a versão 1.5 em 2005, que foi desenvolvida com um consórcio ampliado para melhorar ainda mais a linguagem a fim de refletir a nova experiência no uso de suas características. ^[11]

Embora UML 2.1 nunca tenha sido lançado como uma especificação formal, as versões 2.1.1 e 2.1.2 apareceram em 2007, seguidas por UML 2.2 em fevereiro de 2009. O UML 2.3 foi lançado formalmente em maio de 2010.^[12] UML 2.4.1 foi lançado formalmente em agosto de 2011.^[12] UML 2.5 foi lançado em outubro de 2012 como uma versão "Em processo" e foi oficialmente lançado em junho de 2015.^[12]

Há quatro partes da especificação UML 2.x:

1. A superestrutura que define a notação e semântica para os diagramas e seus elementos modelo
2. A Infra-estrutura que define o metamodelo central sobre o qual se baseia a Superstrutura
3. A Linguagem de Restrição de Objeto (OCL) para definir regras para os elementos do modelo
4. O diagrama UML Interchange que define como os diagramas UML 2 são trocados

As versões atuais dessas normas são as seguintes: UML Superstrutura versão 2.4.1, UML Infraestrutura versão 2.4.1, OCL versão 2.3.1, e UML Diagram Interchange versão 1.0.^[13] Ela continua a ser atualizada e melhorada pela força-tarefa de revisão, que resolve quaisquer problemas com o idioma. ^[14]

Design [editar fonte | editar]

A Unified Modeling Language (UML) oferece uma maneira de visualizar as plantas arquitetônicas de um sistema em um diagrama (ver imagem), incluindo elementos tais como:^[5]

• Quaisquer atividades (empregos)
• Componentes individuais do sistema
• E como eles podem interagir com outros componentes de software.
• Como o sistema irá funcionar
• Como as entidades interagem com outras (componentes e interfaces)
• Interface externa do usuário

Embora originalmente destinada exclusivamente à documentação de projeto orientada a objetos, a Linguagem de Modelagem Unificada (UML) foi ampliada para cobrir um conjunto maior de documentação de projeto (como listado acima)^[15], e foi considerada útil em muitos contextos. ^[16]

Métodos de desenvolvimento de software [edit source | edit]

UML não é um método de desenvolvimento por si só; ^[17] entretanto, foi projetado para ser compatível com os principais métodos de desenvolvimento de software orientados a objetos de seu tempo (por exemploOMT, método Booch, Objectory) e especialmente com o RUP que foi originalmente destinado a ser usado quando o trabalho começou na Rational Software Inc. (Rational Software Inc.).

Modelagem [editar fonte | editar]

É importante distinguir entre o modelo UML e o conjunto de diagramas de um sistema. Um diagrama é uma representação gráfica parcial do modelo de um sistema. O conjunto de diagramas não precisa cobrir completamente o modelo e a eliminação de um diagrama não altera o modelo. O modelo também pode conter documentação que aciona os elementos e diagramas do modelo (tais como casos de uso escrito).

Os diagramas UML representam duas visões diferentes de um modelo de sistema:^[18]

• Visão estática (ou estrutural): enfatiza a estrutura estática do sistema usando objetos, atributos, operações e relacionamentos. A visão estrutural inclui diagramas de classes e diagramas de estrutura composta.
• Visão dinâmica (ou comportamental): enfatiza o comportamento dinâmico do sistema, mostrando colaborações entre objetos e mudanças nos estados internos dos objetos. Esta visão inclui diagramas de seqüência, diagramas de atividade e diagramas de estado da máquina.

Os modelos UML podem ser trocados entre as ferramentas UML usando o formato de troca XML Metadata Interchange (XMI).

Diagramas [editar fonte | editar]

UML 2 tem muitos tipos de diagramas que estão divididos em duas categorias. ^[5] Alguns tipos representam informações estruturais, e os demais representam tipos gerais de comportamento, incluindo alguns que representam diferentes aspectos das interações. Estes diagramas podem ser categorizados hierarquicamente como mostrado no seguinte diagrama de classes:^[5]

Todos estes diagramas podem conter comentários ou notas que explicam o uso, restrição ou intenção.

Diagramas de estrutura [editar fonte | editar]

Os diagramas de estrutura enfatizam as coisas que devem estar presentes no sistema que está sendo modelado. Como os diagramas de estrutura representam a estrutura, eles são amplamente utilizados para documentar a arquitetura de software dos sistemas de software. Por exemplo, o diagrama de componentes que descreve como um sistema de software é dividido em componentes e mostra as dependências entre esses componentes.

• Diagrama de componentes
• Diagrama de classes

Diagramas de comportamento [edit fonte | edit]

Os diagramas de comportamento enfatizam o que deve acontecer no sistema que está sendo modelado. Como os diagramas de comportamento ilustram o comportamento de um sistema, eles são usados extensivamente para descrever a funcionalidade dos sistemas de software. Como exemplo, o diagrama de atividades descreve as atividades comerciais e operacionais passo a passo dos componentes em um sistema.

• Diagrama de atividades
• Diagrama de caso de uso

Diagramas de interação [editar fonte | editar]

Os diagramas de interação, um subconjunto de diagramas de comportamento, enfatizam o fluxo de controle e dados entre as coisas no sistema que está sendo modelado. Por exemplo, o diagrama de seqüência que mostra como os objetos se comunicam uns com os outros em termos de uma seqüência de mensagens.

• Diagrama de seqüências
• Diagrama de comunicação

Meta modelagem[edit fonte | edit]

Artigo principal: Facilidade Meta-Objeto

Ilustração da instalação Meta-Object

O Grupo de Gerenciamento de Objetos (OMG) desenvolveu uma arquitetura de metamodelagem para definir a Linguagem de Modelagem Unificada (UML), chamada de Meta-Objet Facility (MOF). ^[19] O Meta-Object Facility foi projetado como uma arquitetura em quatro camadas, como mostrado na imagem à direita. Ela fornece um modelo meta-meta na camada superior, chamada de camada M3. Este modelo M3 é a linguagem usada pelo Meta-Object Facility para construir metamodelos, chamados de modelos M2.

O exemplo mais proeminente de um modelo de Meta-Objeto de Layer 2 é o metamodelo UML, o modelo que descreve o próprio UML. Estes modelos M2 descrevem elementos da camada M1 e, portanto, os modelos M1. Estes seriam, por exemplo, modelos escritos em UML. A última camada é a camada M0 ou camada de dados. Ela é usada para descrever instâncias de tempo de execução do sistema. ^[20]

O meta-modelo pode ser estendido usando um mecanismo que se chama estereotipagem. Isto tem sido criticado como sendo insuficiente/desatendido por Brian Henderson-Sellers e Cesar Gonzalez-Perez em "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". ^[21]

Adoção [editar fonte | editar]

A UML foi considerada útil em muitos contextos de projeto^[16], tanto que se tornou quase ubíqua dentro da comunidade de TI. ^[22]

Ela tem sido tratada, às vezes, como uma bala de prata de design, o que levou a problemas em sua utilização. O uso indevido inclui o uso excessivo dela (projete cada pequena parte do código do sistema com ela, o que é desnecessário) e assumindo que qualquer um pode projetar qualquer coisa com ela (mesmo aqueles que não tenham programado). [^23]

É visto como uma linguagem grande, com muitas construções. Alguns (inclusive Jacobson) acham que são muitos e que isso dificulta o aprendizado (e, portanto, o uso) da mesma. ^[24]

Críticas [editar fonte | editar]

As críticas comuns à UML por parte da indústria incluem:^[4]

• não é útil: "[não lhes oferece vantagens sobre suas práticas e representações atuais e evoluídas".
• demasiado complexo, particularmente para a comunicação com os clientes: "desnecessariamente complexa" e "A melhor razão para não usar UML é que ela não é 'legível' para todos os interessados. Quanto vale UML se um usuário comercial (o cliente) não consegue entender o resultado de seu esforço de modelagem"?
• necessidade de manter a UML e o código em sincronia, como na documentação em geral

Crítica à UML 1.x [editar fonte | editar]

Notação de cardinalidade

Assim como nos diagramas Chen, Bachman e ISO ER, os modelos de classe são especificados para usar as cardinalidades "look-across", embora vários autores (Merise,^[25] Elmasri & Navathe[26] entre outros[27]⁾ prefiram o mesmo lado ou "look-here" para os papéis e tanto as cardinalidades mínimas quanto as máximas. Pesquisadores recentes (Feinerer,^[28] Dullea et. entre outros^[29]) demonstraram que a técnica "look-across" utilizada pelos diagramas UML e ER é menos eficaz e menos coerente quando aplicada às relações n-ary de ordem >2.

Feinerer diz: "Os problemas surgem se operamos sob a semântica de olhar para o outro lado, como é usado para as associações UML. Hartmann^[30] investiga esta situação e mostra como e por que as diferentes transformações falham". (Embora a "redução" mencionada seja espúria, pois os dois diagramas 3.4 e 3.5 são na verdade os mesmos) e também "como veremos nas próximas páginas, a interpretação look-across introduz várias dificuldades que impedem a extensão de mecanismos simples de associações binárias para associações n-árias".