Saltar para o conteúdo

UML

Origem: Wikipédia, a enciclopédia livre.
 Nota: Para outros significados, veja UML (desambiguação).
Unified Modeling Language (UML)
FamíliaLinguagem de modelagem
Página oficialwww.uml.org

Unified Modeling Language (em português: Linguagem de Modelagem Unificada), abreviado como UML, é uma linguagem de modelagem de uso padrão que busca fornecer uma padronização da estrutura de um sistema.[1]

A UML fornece uma notação padrão para muitos tipos de diagramas que podem ser divididos em três grupos principais: diagramas de comportamento, diagramas de interação e diagramas de estrutura.

A criação da UML foi originalmente motivada pelo desejo de padronizar os distintos sistemas notacionais e abordagens de projeto de software. Ela foi desenvolvida pela empresa Rational Software entre 1994 e 1995, com mais funções adicionadas por eles até 1996.[2]

Em 1997, a UML foi adotada como padrão pela Object Management Group (OMG) e vem sendo gerida por essa organização desde então. Em 2005, a UML também foi publicada pela Organização Internacional de Normalização (ISO) e pela Comissão Eletrotécnica Internacional (IEC) como a norma ISO/IEC 19501. Desde então, o padrão tem sido periodicamente revisado para abranger as versões mais recentes da UML.[3]

A UML é adequada para a modelagem de sistemas de software, cuja abrangência inclui desde sistemas de informação corporativos a serem distribuídos a aplicações baseadas na web e até em sistemas complexos embutidos de tempo real. É uma linguagem muito expressiva, abrangendo todas as visões necessárias ao desenvolvimento e implantação desses sistemas.[4] No entanto, algumas pesquisas apontam que a maioria dos profissionais em engenharia de software não utiliza UML formalmente, preferindo produzir diagramas informais feitos à mão, ainda que usando alguns elementos da linguagem.[5]

História

[editar | editar código-fonte]

Era uma vez um sistema UML que tinha origem na compilação das "melhores práticas de engenharia" que provaram ter sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Grady Booch, OMT (James Rumbaugh) e OOSE (Ivar Jacobson) fundindo-os numa única linguagem de modelagem comum e largamente utilizada. A UML pretende ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos.

A UML ainda não é um padrão da indústria, mas esse objetivo está a tomar forma sob os auspícios do Object Management Group (OMG). O OMG pediu informação acerca de metodologias orientadas a objetos que pudessem criar uma linguagem rigorosa de modelagem de software. Muitos líderes da indústria responderam na esperança de ajudar a criar o padrão.

Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Unified Process - Processo Unificado (como era conhecido). Nesta mesma época, Jacobson se associou à Rational e o escopo do projeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML.

Finalmente em 2000, a UML foi aprovada como padrão pelo OMG (Object Management Group), um consórcio internacional de empresas que define e ratifica padrões na área de Orientação a Objetos.

Diagramas

[editar | editar código-fonte]
Tipos de diagramas UML
Diagramas estruturais
Diagramas comportamentais ou dinâmicos

A partir do UML 2, a OMG definiu que a linguagem UML possui catorze tipos de diagramas, divididos nas categorias de diagramas "estruturais" e "comportamentais", cada uma com sete tipos. Estes diagramas podem ser visualizados de forma hierárquica, como apresentado no padrão de diagrama de classes abaixo:

Todos esses diagramas podem conter comentários ou notas explicando usos, restrições ou intenções.

Diagramas estruturais

[editar | editar código-fonte]

Os diagramas estruturais tratam o aspecto estrutural tanto do ponto de vista do sistema quanto das classes. Existem para visualizar, especificar, construir e documentar os aspectos estáticos de um sistema, ou seja, a representação de seu esqueleto e estruturas “relativamente estáveis”. Os aspectos estáticos de um sistema de software abrangem a existência e a colocação de itens como classes, interfaces, colaborações, componentes. E é representado em 7 tipos, segue abaixo as descrições:

Diagramas de classes

[editar | editar código-fonte]
Ver artigo principal: Diagrama de classes

O diagrama de classes é utilizado para fazer a representação de estruturas de classes de negócio, interfaces e outros sistemas e classes de controle. Além disso, o diagrama de classes é considerado o mais importante para a UML, pois serve de apoio para a maioria dos demais diagramas. Se dá pela formação de conjunto de informações sobre determinadas classes, que unidas entre si formam um sentido geral do projeto.

Exemplos:

Diagrama de classe

Diagramas de objetos

[editar | editar código-fonte]
Ver artigo principal: Diagrama de objetos

O diagrama de objetos representa os objetos de um diagrama de classes em um determinado instante de tempo, representando suas instâncias e seus relacionamentos, conforme definidos no diagrama de classes. Os objetos e suas instâncias demonstradas são utilizados para fazer a modelagem da visão estática do projeto de um sistema, a partir de situações da realidade ou de protótipos. Quando mostrado graficamente, é perceptível que o diagrama de objetos seja parecido com o de classes.

Exemplo: Uma classe carro, e o modelo Nissan 2007. O Nissan 2007 é objeto da classe carro.

Diagramas de componentes

[editar | editar código-fonte]
Ver artigo principal: Diagrama de 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.

  • Modelar software baseado em componentes.
  • Indicar os componentes do software e seus relacionamentos.

Diagramas de instalação

[editar | editar código-fonte]
Ver artigo principal: Diagrama de instalação

O diagrama de instalação, também denominado diagrama de implementação ou implantação, consiste na organização do conjunto de elementos de um sistema para a sua execução.

  • Mostra o layout físico de um sistema, revelando quais partes do software são executadas em quais partes do hardware.
  • Enfoca a estrutura física sobre a qual o software irá ser implantado e executado em termos de hardware.
  • Define como as máquinas estarão conectadas e através de quais protocolos se comunicarão.
  • É útil quando o sistema a ser modelado for ser executado sobre múltiplas camadas.
  • Seus elementos são os nós e os caminhos de comunicação.

Diagramas de pacotes

[editar | editar código-fonte]
Ver artigo principal: Diagrama de pacotes

Um diagrama de pacotes é composto de:

  • Pacotes
  • Relacionamentos entre pacotes.
  • O diagrama de pacotes tem o objetivo de transformar as classes em pacotes. O critério para definir os pacotes é subjetivo e depende da visão e das necessidades do projetista. Este deve definir uma certa semântica e colocar os elementos similares e que tendem a serem modificados em conjunto num mesmo pacote. Como também, pode-se usar os pacotes para mostrar a arquitetura do sistema.

Diagramas de estrutura composta

[editar | editar código-fonte]
Ver artigo principal: Diagrama de estrutura composta

O diagrama de estrutura composta é utilizado para modelar Colaborações. Uma colaboração descreve uma visão de um conjunto de entidades cooperativas interpretadas por instâncias que cooperam entre si para executar uma função específica. O termo estrutura desse diagrama refere-se a uma composição de elementos interconectados, representando instâncias de tempo de execução colaboram, por meio de vínculos de comunicação, para atingir algum objetivo comum. Esse diagrama também pode ser utilizado para definir a estrutura interna de um classificador.

Diagramas de perfil

[editar | editar código-fonte]
Ver artigo principal: Diagrama de perfil

O diagrama de perfil destina-se a criar uma visão (ou customização de um metamodelo existente com construções específicas para um determinado domínio) do relacionamento entre classes para atender determinado domínio.[6]

Diagramas comportamentais

[editar | editar código-fonte]

Utilizado para visualizar, especificar, construir e documentar aspectos dinâmicos de um devido sistema. Considerando aspectos dinâmicos de um sistema como representação das suas partes que passam por alteração, assim como aspectos dinâmicos de uma casa abrangem a passagem de pessoas pelos cômodos, e a circulação de ar, também os aspectos dinâmicos de um sistema de software envolve itens como fluxo de mensagem ao longo do tempo.

UML também permite a representação de um sistema de forma padronizada, para facilitar na compreensão, e ainda auxilia a comunicação entre os objetos, e a identificação de processos.

Existem sete tipos de diagramas comportamentais, dentre os quais alguns estão listados a seguir.

Diagramas de caso de uso

[editar | editar código-fonte]
Ver artigo principal: Diagrama de caso de uso

O diagrama de caso de uso organiza os comportamentos do sistema. Um diagrama de caso de uso mostra um conjunto de casos de uso e atores (um tipo especial de classe) e seus relacionamentos. Aplique esses diagramas para ilustrar a visão estática do caso de uso de um sistema. Os diagramas de caso de uso são importantes principalmente para organização e modelagem dos comportamentos de um sistema.[7] Exemplos:

caso de uso

Diagrama de sequência

[editar | editar código-fonte]
Ver artigo principal: Diagrama de sequência

O diagrama de sequência enfatiza a ordem temporal das mensagens. Um diagrama de sequência é um diagrama de interação que da ênfase à ordenação temporal de mensagens. Um diagrama de sequência mostra um conjunto de papéis e as mensagens enviadas e recebidas pelas instâncias que representam os papéis. Use os diagramas de sequência para ilustrar a visão dinâmica de um sistema.[7]

Diagramas de colaboração

[editar | editar código-fonte]
Ver artigo principal: Diagrama de colaboração

O diagrama de colaboração enfatiza a organização estrutural de objetos que enviam e recebem mensagens. Um diagrama de comunicação é um diagrama de interação que da ênfase a organização estrutural dos objetos que enviam e recebem mensagens. Um diagrama de comunicação mostra um conjunto de papéis, as conexões existentes entre esses papéis e as mensagens enviadas e recebidas pelas instâncias que representam os papéis. Use os diagramas de comunicação para ilustrar a visão dinâmica de um sistema.[7]

Diagramas de transição de estados

[editar | editar código-fonte]
Ver artigo principal: Diagrama de transição de estados

O diagrama de transição de estados enfatiza o estado de mudança de um sistema orientado por eventos. Um diagrama de estados mostra uma máquina de estados, que consiste de estados, transições, eventos e atividades. Use o diagrama de estados para ilustrar a visão dinâmica de um sistema. Esses diagramas são importantes principalmente para fazer a modelagem do comportamento de uma interface, classe ou colaboração. Os diagramas de estados dão ênfase ao comportamento de um objeto, solicitado por eventos, que é de grande ajuda para a modelagem de sistemas reativos.[7]

Diagramas de atividades

[editar | editar código-fonte]
Ver artigo principal: Diagrama de atividade

O diagrama de atividades enfatiza o fluxo de controle de uma atividade para outra. Um diagrama de atividades mostra o fluxo de uma atividade para outro em um sistema. Uma atividade mostra um conjunto de atividades, o fluxo sequencial ou ramificado de uma atividade para outra e os objetos que realizam ou sofrem ações. Use os diagramas de atividades para ilustrar a visão dinâmica de um sistema. Esses diagramas são importantes principalmente para fazer a modelagem da função de um sistema. Os diagramas de atividade dão ênfase ao fluxo de controle na execução de um comportamento. Os diagramas de atividades dependem um do outro, há uma relação de dependência entre eles.

Metamodelagem

[editar | editar código-fonte]
Ilustração da Meta-Object Facility

A OMG desenvolveu uma arquitetura de metamodelagem para definir o UML, chamada de Meta-Object Facility.[8] O MOF foi projetado como uma arquitetura de quatro camadas, como mostra a imagem à direita. Ele fornece um modelo meta-meta no topo, chamado camada M3. Este modelo M3 é a linguagem usada pelo Meta-Object Facility para construir metamodelos, chamados modelos M2.

O exemplo mais proeminente de um modelo Meta-Object Facility da camada 2 é o metamodelo UML, que descreve a própria UML. Esses modelos M2 descrevem elementos da camada M1 e, portanto, modelos M1. Esses seriam, por exemplo, modelos escritos em UML. A última camada é a camada M0 ou camada de dados. É usado para descrever instâncias de tempo de execução do sistema.[9]

O meta-modelo pode ser estendido usando um mecanismo chamado estereótipo. Isso foi criticado por ser insuficiente/insustentável por Brian Henderson-Sellers e Cesar Gonzalez-Perez em "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0".[10]

Elementos

[editar | editar código-fonte]

Ver também

[editar | editar código-fonte]

Referências

  1. ↑ Unified Modeling Language 2.5.1 (em inglês). [S.l.]: Object Management Group Standards Development Organization (OMG SDO). 5 de dezembro de 2017 
  2. ↑ Unified Modeling Language User Guide, The (em inglês) 2 ed. [S.l.]: Addison-Wesley. 2005. p. 492. ISBN 0321267974 
  3. ↑ «ISO/IEC 19505-1:2012 - Information technology - Object Management Group Unified Modeling Language (OMG UML) - Part 1: Infrastructure» (em inglês). Iso.org. 20 de abril de 2012. Consultado em 10 de abril de 2014 
  4. ↑ BOOCH, G; RUMBAUGH, J e JACOBSON, I: UML, Guia do Usuário: tradução; Fábio Freitas da Silva, Rio de Janeiro, Campus ,2012.
  5. ↑ Sebastian Baltes; Stephan Diehl (11 de novembro de 2014). «Sketches and diagrams in practice». Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. Col: FSE 2014 (em inglês). [S.l.]: Association for Computing Machinery. pp. 530–541. ISBN 978-1-4503-3056-5. arXiv:1706.09172Acessível livremente. doi:10.1145/2635868.2635891. S2CID 2436333 
  6. ↑ Fakhroutdinov, Kirill. «UML profile diagram is a structure diagram which describes UML extension mechanism by defining custom stereotypes, tagged values and constraints.». www.uml-diagrams.org (em inglês). Consultado em 18 de julho de 2018 
  7. ↑ a b c d UML - Guia do Usuário. Rio de Janeiro: ELSEVIER. 2012. pp. 105–107 
  8. ↑ Iman Poernomo (2006) "The Meta-Object Facility Typed" in: Proceeding SAC '06 Proceedings of the 2006 ACM symposium on Applied computing. pp. 1845-1849
  9. ↑ «UML 2.4.1 Infrastructure». Omg.org. 5 de agosto de 2011. Consultado em 10 de abril de 2014 
  10. ↑ B. Henderson-Sellers; C. Gonzalez-Perez (2006). "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". in: Model Driven Engineering Languages and Systems. Springer Berlin / Heidelberg.

Ligações externas

[editar | editar código-fonte]
O Commons possui imagens e outros ficheiros sobre UML
Obtida de "https://pt.wikipedia.org/w/index.php?title=UML&oldid=70366074"