UML significa Linguagem de Modelagem Unificada. É uma linguagem de modelagem padronizada composta por um conjunto integrado de diagramas desenvolvidos para ajudar desenvolvedores de sistemas e software a especificar, visualizar, construir e documentar os artefatos de sistemas de software, bem como para modelagem de negócios e outros sistemas não de software.

UML representa uma coleção das melhores práticas de engenharia que se provaram bem-sucedidas na modelagem de sistemas grandes e complexos. UML é uma parte importante no desenvolvimento de software orientado a objetos e no processo de desenvolvimento de software. UML utiliza principalmente notações gráficas para expressar o design de projetos de software. O uso de UML ajuda as equipes de projetos a se comunicarem, explorarem designs potenciais e validarem o design arquitetônico do software. Neste artigo, fornecemos informações detalhadas sobre o que é UML.

Origens do UML

O objetivo do UML é fornecer uma notação padrão que possa ser usada por todos os métodos orientados a objetos e selecionar e integrar os melhores elementos das notações anteriores. O UML é projetado para uma ampla gama de aplicações. Portanto, oferece construções para uma ampla variedade de sistemas e atividades (por exemplo, sistemas distribuídos, análise, design de sistemas e implantação).

O UML nasceu da unificação de três notações principais de modelagem orientada a objetos:

1. Técnica de Modelagem de Objetos (OMT) [James Rumbaugh 1991] – mais adequado para análise e sistemas de informação intensivos em dados.
2. Booch [Grady Booch 1994] – muito forte para design e implementação. Grady Booch trabalhou extensivamente com a linguagem Ada e foi um dos principais contribuintes para o desenvolvimento orientado a objetos dessa linguagem. Embora o método Booch fosse poderoso, sua notação não era muito popular (muitas formas em nuvem em seus modelos – não muito elegante).
3. OOSE (Engenharia de Software Orientada a Objetos [Ivar Jacobson 1992]) – caracterizado por um modelo chamado Casos de Uso. Casos de Uso são uma técnica poderosa para compreender o comportamento do sistema inteiro (uma área onde o OO tradicionalmente era fraco).

Em 1994, o mundo do software ficou chocado quando Jim Rumbaugh, criador do OMT, deixou a General Electric e se juntou a Grady Booch na Rational Software. A colaboração visava fundir suas ideias em um método unificado (título provisório era “Método Unificado”).

Em 1995, Ivar Jacobson, criador do OOSE, também se juntou à Rational, e suas ideias (particularmente o conceito de “Casos de Uso”) foram incorporadas ao novo método unificado – agora chamado Linguagem de Modelagem Unificada 1. A equipe de Rumbaugh, Booch e Jacobson era carinhosamente conhecida como os “Três Amigos”.

O UML também foi influenciado por outras notações orientadas a objetos na época:

• Mellor e Shlaer [1998]
• Coad e Yourdon [1995]
• Wirfs-Brock [1990]
• Martin e Odell [1992]

O UML também incluiu novos conceitos que não estavam presentes em outros métodos principais da época, como mecanismos de extensão e linguagens de restrição.

História do UML

1. Durante 1996, o Grupo de Gestão de Objetos (OMG) emitiu o primeiro Pedido de Proposta (RFP), que serviu como catalisador para que essas organizações colaborassem em uma resposta conjunta ao RFP.
2. A Rational formou o consórcio UML Partners com várias organizações dispostas a dedicar recursos a uma definição sólida do UML 1.0. As organizações que mais contribuíram para a definição do UML 1.0 incluíram:
   • Corporação de Equipamentos Digitais
   • Hewlett-Packard
   • I-Logix
   • IntelliCorp
   • IBM
   • ICON Computing
   • MCI Systemhouse
   • Microsoft
   • Oracle
   • Rational Software
   • Texas Instruments
   • Unisys
3. Essa colaboração produziu o UML 1.0, uma linguagem de modelagem bem definida, expressiva, poderosa e de propósito geral. Foi apresentado ao OMG como a resposta inicial ao RFP em janeiro de 1997.
4. Em janeiro de 1997, a IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies e Softeam também apresentaram respostas separadas ao RFP ao OMG. Essas empresas se juntaram aos Parceiros do UML para contribuir com suas ideias, e os parceiros produziram conjuntamente uma resposta revisada do UML 1.1. O UML 1.1 focou em melhorar a clareza da semântica do UML 1.0 e incorporar contribuições dos novos parceiros. Foi apresentado ao OMG para consideração e adotado no outono de 1997. As versões evoluíram de 1.1 a 1.5, seguidas pelo UML 2.0 até o 2.5 (a versão atual é o UML 2.5).

Por que UML?

À medida que o valor estratégico do software aumentava para muitas empresas, a indústria procurava tecnologias para automatizar a produção de software e melhorar a qualidade, reduzindo custos e tempo para o mercado. Essas tecnologias incluem tecnologia de componentes, programação visual, padrões e frameworks. As empresas também estão buscando formas de gerenciar a complexidade à medida que seu escopo e escala aumentam. Em particular, reconhecem a necessidade de abordar problemas arquitetônicos recorrentes, como distribuição física, concorrência, replicação, segurança, balanceamento de carga e tolerância a falhas. Além disso, o desenvolvimento da World Wide Web, embora tenha simplificado algumas coisas, agravou esses problemas arquitetônicos. A Linguagem de Modelagem Unificada (UML) foi projetada para atender a essas necessidades.

1. Fornecer aos usuários uma linguagem visual de modelagem pronta para uso, expressiva, para desenvolver e trocar modelos significativos.
2. Fornecer mecanismos de extensibilidade e especialização para expandir os conceitos centrais.
3. Ser independente de linguagens de programação e processos de desenvolvimento específicos.
4. Fornecer uma base formal para compreender a linguagem de modelagem.
5. Incentivar o crescimento do mercado de ferramentas orientadas a objetos.
6. Apoiar conceitos de desenvolvimento de nível superior, como colaborações, frameworks, padrões e componentes.
7. Integrar melhores práticas.

UML – Visão Geral

Antes de mergulharmos na teoria do UML, vamos apresentar brevemente alguns dos principais conceitos do UML.

A primeira coisa a notar sobre o UML é que existem muitos diagramas (modelos) diferentes para se acostumar. A razão disso é que um sistema pode ser visto de muitas perspectivas diferentes. O desenvolvimento de software envolve muitos interessados.

Por exemplo:

• Analistas
• Designers
• Programadores
• Testadores
• QA
• Clientes
• Autores técnicos

Todas essas pessoas estão interessadas em aspectos diferentes do sistema, e cada aspecto exige um nível diferente de detalhe. Por exemplo, os programadores precisam compreender o design do sistema e ser capazes de traduzir esse design em código de baixo nível. Em contraste, os autores técnicos estão interessados no comportamento geral do sistema e precisam compreender a funcionalidade do produto. O UML tenta fornecer uma linguagem expressiva o suficiente para que todos os interessados possam se beneficiar de pelo menos um diagrama UML.

Aqui está uma visão geral rápida de cada um dos 13 diagramas mostrados na Estrutura de Diagramas UML 2:

Diagramas Estruturaismostram a estrutura estática do sistema e suas partes em diferentes níveis de abstração e implementação, e como elas estão relacionadas. Os diagramas estruturais têm sete tipos:

• Diagrama de Classes
• Diagrama de Componentes
• Diagrama de Implantação
• Diagrama de Objetos
• Diagrama de Pacotes
• Diagrama de Estrutura Composta
• Diagrama de Perfil

Diagramas Comportamentaismostram o comportamento dinâmico dos objetos no sistema, que pode ser descrito como uma série de mudanças ao longo detempo. Existem sete tipos de diagramas comportamentais:

• Diagrama de Casos de Uso
• Diagrama de Atividades
• Diagrama de Máquina de Estados
• Diagrama de Sequência
• Diagrama de Comunicação
• Diagrama de Visão Geral de Interações
• Diagrama de Tempo

O que é um Diagrama de Classes?

Um diagrama de classes é uma técnica central de modelagem usada em quase todos os métodos orientados a objetos. O diagrama descreve os tipos de objetos no sistema e as diversas relações estáticas que existem entre eles.

Relações

Existem três relações principais que são importantes:

1. Associação – indica uma relação entre instâncias de tipos (por exemplo, uma pessoa trabalha em uma empresa, uma empresa possui múltiplas filiais).
2. Herança – a adição mais óbvia aos diagramas ER usados em PO. Tem uma correspondência direta com herança no design orientado a objetos.
3. Agregação – uma forma de composição de objetos no design orientado a objetos.

Exemplo de Diagrama de Classe

Para mais detalhes sobre diagramas de classe, leia o artigo O que é um Diagrama de Classe?

O que é um Diagrama de Componente?

Na Linguagem Unificada de Modelagem, um diagrama de componente mostra como os componentes são conectados para formar componentes maiores ou sistemas de software. Ilustra a arquitetura dos componentes de software e suas dependências. Esses componentes de software incluem componentes de tempo de execução, componentes executáveis e também componentes de código-fonte.

Exemplo de Diagrama de Componente

Para mais detalhes sobre diagramas de componente, leia o artigo O que é um Diagrama de Componente?

O que é um Diagrama de Implantação?

Diagramas de implantação ajudam a modelar os aspectos físicos de sistemas de software orientados a objetos. É um diagrama de estrutura que mostra a arquitetura do sistema como a implantação (distribuição) de artefatos de software para destinos de implantação. Artefatos representam elementos concretos no mundo físico que resultam do processo de desenvolvimento. Modela a configuração em tempo de execução em uma visão estática e visualiza a distribuição de artefatos em uma aplicação. Na maioria dos casos, envolve modelar configurações de hardware e os componentes de software que neles residem.

Exemplo de Diagrama de Implantação

Para mais detalhes sobre diagramas de implantação, leia o artigo O que é um Diagrama de Implantação?

O que é um Diagrama de Objeto?

Um diagrama de objeto é um grafo de instâncias, incluindo objetos e valores de dados. Um diagrama de objeto estático é uma instância de um diagrama de classe; ele mostra uma fotografia do estado detalhado do sistema em um momento específico. A diferença é que um diagrama de classe representa um modelo abstrato composto por classes e suas relações, enquanto um diagrama de objeto representa instâncias em um momento específico, que é intrinsecamente concreto. O uso de diagramas de objeto é bastante limitado, principalmente para mostrar exemplos de estruturas de dados.

Diagrama de Classe vs Diagrama de Objeto – Um Exemplo

Algumas pessoas podem achar difícil entender a diferença entre diagramas de classe UML e diagramas de objeto UML porque ambos contêm blocos retangulares nomeados com atributos e links entre eles, o que faz com que os dois diagramas UML pareçam semelhantes. Alguns até pensam que são iguais porque nas ferramentas UML os símbolos de diagrama de classe e diagrama de objeto são colocados no mesmo editor de diagrama – o diagrama de classe.

Mas na realidade, diagramas de classe e diagramas de objeto representam dois aspectos diferentes da base de código. Neste artigo, fornecemos algumas ideias sobre esses dois diagramas UML, o que são, como diferem e quando usá-los.

Relação entre Diagrama de Classe e Diagrama de Objeto

Você cria ‘classes’ ao programar. Por exemplo, em um sistema bancário online, você pode criar classes como ‘Usuário’, ‘Conta’, ‘Transação’, etc. Em um sistema de gestão de sala de aula, você pode criar classes como ‘Professor’, ‘Aluno’, ‘Tarefa’, etc. Em cada classe, há atributos e operações que representam as características e comportamentos da classe. Um diagrama de classe é um diagrama UML onde você pode visualizar essas classes, seus atributos, operações e relações entre si.

Um diagrama de objeto UML mostra como as instâncias de objetos de classes (desenhadas em um diagrama de classe UML) ‘parecem’ em um estado específico. Em outras palavras, um diagrama de objeto UML pode ser considerado como uma instância de como as classes (em um diagrama de classe UML) são usadas em um estado específico.

Se você não gostar dessas definições, dê uma olhada nos exemplos de diagramas UML abaixo. Acredito que você entenderá sua diferença em segundos.

Exemplo de Diagrama de Classe

O seguinte exemplo de diagrama de classe representa duas classes – Usuário e Anexo. Um usuário pode fazer upload de múltiplos anexos, então as duas classes estão associadas com uma associação com multiplicidade 0…* no lado do Anexo.

Exemplo de Diagrama de Objeto

O seguinte exemplo de diagrama de objeto mostra como as instâncias de objetos das classes Usuário e Anexo ‘parecem’ quando Peter (ou seja, um usuário) tenta fazer upload de dois anexos. Então existem duas especificações de instância dos dois anexos a serem enviados.

Para mais detalhes sobre diagramas de objeto, leia o artigo O que é um Diagrama de Objeto?

O que é um Diagrama de Pacote?

Um diagrama de pacote é um diagrama de estrutura UML que mostra pacotes e dependências entre pacotes. Diagramas de pacotes permitem mostrar diferentes visões de um sistema, por exemplo, como um aplicativo de múltiplas camadas (também chamado de múltiplos níveis) – modelo de aplicativo de múltiplas camadas.

Exemplo de Diagrama de Pacote

Para mais detalhes sobre diagramas de pacotes, leia o artigo O que é um Diagrama de Pacote?

O que é um Diagrama de Estrutura Composta?

Diagramas de estrutura composta são um dos novos artefatos adicionados ao UML 2.0. Um diagrama de estrutura composta é semelhante a um diagrama de classe e é um tipo de diagrama de componente, principalmente usado para modelar um sistema sob uma perspectiva microscópica, mas representa a estrutura interna de uma única parte, e não de uma classe inteira. É um diagrama de estrutura estática que mostra a estrutura interna de uma classe e as colaborações que essa estrutura torna possível.

O diagrama pode incluir partes internas, portas pelas quais as partes interagem entre si ou instâncias da classe interagem com o mundo exterior, e conectores entre partes ou portas. Uma estrutura composta é um conjunto de elementos interconectados que colaboram em tempo de execução para alcançar algum propósito. Cada elemento tem um papel definido nessa colaboração.

Exemplo de Diagrama de Estrutura Composta

Para mais detalhes sobre diagramas de estrutura composta, leia o artigo O que é um Diagrama de Estrutura Composta?

O que é um Diagrama de Perfil?

Com o diagrama de perfil, você pode criar estereótipos específicos para domínio e plataforma e definir suas relações. Você pode criar estereótipos desenhando formas de estereótipos e relacioná-los por meio de composição ou generalização através de uma interface centrada em recursos. Também é possível definir e visualizar valores com marcação de estereótipos.

Exemplo de Diagrama de Perfil

Para mais detalhes sobre diagramas de perfil, leia o artigo O que é um Diagrama de Perfil no UML?

O que é um Diagrama de Caso de Uso?

Um modelo de caso de uso descreve os requisitos funcionais de um sistema em termos de casos de uso. É um modelo das funções pretendidas do sistema (casos de uso) e de seu ambiente (atores). Os casos de uso permitem relacionar o que o sistema é obrigado a fazer com como o sistema atende a esses requisitos.

Pense em um modelo de caso de uso como um menu, como aquele que você encontra em um restaurante. Ao olhar para o menu, você pode ver quais pratos estão disponíveis, os pratos individuais e seus preços. Você também sabe que tipo de culinária o restaurante serve: italiana, mexicana, chinesa, etc. Ao olhar para o menu, você tem uma visão geral do que a experiência gastronômica espera por você nesse restaurante. O menu está, na verdade, “imitando” o comportamento do restaurante.

Como é uma ferramenta de planejamento tão poderosa, os modelos de caso de uso são utilizados por todos os membros da equipe em todas as fases do ciclo de desenvolvimento.

Exemplo de Diagrama de Caso de Uso

Para mais detalhes sobre diagramas de caso de uso, leia o artigo O que é um Diagrama de Caso de Uso?

O que é um Diagrama de Atividade?

Um diagrama de atividade é uma representação gráfica dos fluxos de atividades e ações passo a passo, com suporte para escolha, iteração e concorrência. Ele descreve o fluxo de controle do sistema-alvo, por exemplo, explorando regras e operações de negócios complexas, descrevendo casos de uso e processos de negócios. Na Linguagem de Modelagem Unificada, diagramas de atividade têm como objetivo modelar tanto processos computacionais quanto organizacionais (ou seja, fluxos de trabalho).

Exemplo de Diagrama de Atividade

Para mais detalhes sobre diagramas de atividade, leia o artigo O que é um Diagrama de Atividade?

O que é um Diagrama de Máquina de Estados?

Um diagrama de estado é um tipo de diagrama usado na UML para descrever o comportamento do sistema com base no conceito de statechart de David Harel. Os diagramas de estado representam os estados permitidos e as transições, bem como os eventos que afetam essas transições. Ajuda a visualizar todo o ciclo de vida de um objeto, facilitando assim uma melhor compreensão dos sistemas baseados em estado.

Exemplo de Diagrama de Máquina de Estados

Para mais detalhes sobre diagramas de máquina de estados, leia o artigo O que é um Diagrama de Máquina de Estados?

O que é um Diagrama de Sequência?

Um diagrama de sequência modela a colaboração de objetos de acordo com a sequência temporal. Mostra como os objetos interagem entre si em um cenário específico de caso de uso. Com capacidade avançada de modelagem visual, você pode criar diagramas de sequência complexos com apenas alguns cliques. Além disso, algumas ferramentas de modelagem (como o Visual Paradigm) podem gerar diagramas de sequência a partir do fluxo de eventos que você definiu nas descrições de casos de uso.

Exemplo de Diagrama de Sequência

Para mais detalhes sobre diagramas de sequência, leia o artigo O que é um Diagrama de Sequência?

O que é um Diagrama de Comunicação?

Semelhante a um diagrama de sequência, um diagrama de comunicação também é usado para modelar o comportamento dinâmico de um caso de uso. Em comparação com os diagramas de sequência, os diagramas de comunicação dão mais ênfase em mostrar a colaboração entre objetos do que a sequência temporal. São semanticamente equivalentes, portanto, algumas ferramentas de modelagem (como o Visual Paradigm) permitem gerar um a partir do outro.

Exemplo de Diagrama de Comunicação

Para mais detalhes sobre diagramas de comunicação, leia o artigo O que é um Diagrama de Comunicação?

O que é um Diagrama de Visão Geral de Interação?

Um diagrama de visão geral de interação foca na visão geral do fluxo de controle da interação. É uma variante do diagrama de atividades em que os nós são interações ou ocorrências de interação. O diagrama de visão geral de interação descreve as interações em que mensagens e linhas de vida são ocultas. Você pode vincular a diagramas “reais” e alcançar alta navegabilidade entre diagramas no diagrama de visão geral de interação.

Exemplo de Diagrama de Visão Geral de Interação

Para mais detalhes sobre diagramas de visão geral de interação, leia o artigo O que é um Diagrama de Visão Geral de Interação?

O que é um Diagrama de Tempo?

Um diagrama de tempo mostra o comportamento de objetos ao longo de um período de tempo determinado. Os diagramas de tempo são uma forma especial de diagrama de sequência. A diferença entre diagramas de tempo e diagramas de sequência é que os eixos são invertidos, de modo que o tempo aumenta da esquerda para a direita, e as linhas de vida são mostradas em compartimentos separados dispostos verticalmente.

Exemplo de Diagrama de Tempo

Para mais detalhes sobre diagramas de tempo, leia o artigo O que é um Diagrama de Tempo?

Aprenda UML. Desenhe UML.

Obtenha a Versão Comunitária do Visual Paradigm – uma ferramenta UML GRATUITA que ajuda você a aprender UML mais rapidamente e de forma mais eficaz. A Versão Comunitária do Visual Paradigm suporta todos os tipos de diagramas UML. Seu modelador UML premiado é intuitivo e fácil de usar.

Baixar Grátis

Glossário e Terminologia UML

• Classe abstrata – Uma classe que nunca é instanciada. Nenhuma instância dessa classe jamais existe.
• Ator – Um objeto ou pessoa que inicia eventos relacionados ao sistema.
• Atividade: Uma etapa ou ação em um diagrama de atividades. Representa uma operação realizada pelo sistema ou por um Ator.
• Diagrama de atividades: Um fluxograma aprimorado que mostra etapas e decisões em um processo, bem como operações paralelas, como um algoritmo ou processo de negócios.
• Agregação – É parte de outra classe. Representado por um losango vazio ao lado da classe que o contém no diagrama.
• Artifato – Um documento que descreve a saída de uma etapa no processo de design. A descrição pode ser gráfica, textual ou uma combinação de ambos.
• Associação – Uma conexão entre dois elementos no modelo. Isso pode representar uma variável membro em código, uma associação entre um registro de pessoal e a pessoa que ele representa, uma relação entre duas classes de trabalhadores, ou qualquer relação semelhante. Por padrão, ambos os elementos em uma associação se conhecem mutuamente e são iguais. Uma associação também pode ser navegável, significando que a extremidade de origem conhece a extremidade de destino, mas não o contrário.
• Classe de associação: Uma classe que representa uma associação entre duas outras classes e adiciona informações a ela.
• Atributo – Uma característica de um objeto que pode ser usada para referenciar outros objetos ou armazenar informações sobre o estado do objeto.
• Classe base: A classe que define atributos e operações herdadas por subclasses por meio de uma relação de generalização.
• Ramificação: Um ponto de decisão em um diagrama de atividades. Várias transições emergem de uma ramificação, cada uma com uma condição de guarda. Quando o controle atinge a ramificação, exatamente uma condição de guarda deve ser verdadeira, e o controle segue a transição correspondente.
• Classe: Uma categoria de objetos semelhantes, todos descritos pelos mesmos atributos e operações, e todos compatíveis com atribuição.
• Diagrama de classes – Mostra classes no sistema e relações entre elas.
• Classificador: Um elemento UML que possui atributos e operações. Especificamente, Ator, Classes e Interfaces.
• Colaboração: Uma relação entre dois objetos em um diagrama de comunicação, indicando que mensagens podem ser trocadas entre os objetos.
• Diagrama de comunicação – Um diagrama que mostra como uma operação é realizada, enfatizando os papéis dos objetos.
• Componente: Uma unidade implantável de código no sistema.
• Diagrama de componente: Um diagrama que mostra relações entre diversos componentes e interfaces.
• Conceito – Um substantivo ou conceito abstrato a ser incluído no modelo de domínio.
• Fase de construção – A terceira fase do Processo Unificado Racional, na qual múltiplas iterações funcionais são construídas no sistema construído. É aqui que ocorre a maior parte do trabalho.
• Dependência: Uma relação que indica que um classificador conhece os atributos e operações de outro classificador, mas não está diretamente conectado a quaisquer instâncias do segundo classificador.
• Diagrama de implantação: Um diagrama que mostra relações entre diversos processadores.
• Domínio – A parte do Universo de Discurso com a qual o sistema está envolvido.
• Fase de elaboração – A segunda fase do Processo Unificado Racional, permitindo planejamento adicional do projeto, incluindo iterações na fase de construção.
• Elemento: Qualquer item mostrado no modelo.
• Encapsulamento – Dados dentro de um objeto são privados.
• Generalização – Indica que uma classe é uma subclasse de outra (superclasse). A seta vazia aponta para a superclasse.
• Evento: Em um diagrama de estado, isso representa um sinal, evento ou entrada que faz o sistema tomar uma ação ou mudar de estado.
• Estado final: Em um diagrama de estado ou diagrama de atividade, isso representa o ponto em que o diagrama é concluído.
• Divisão: Um ponto em um diagrama de atividade onde múltios fluxos paralelos de controle começam.
• Generalização: Uma relação de herança em que uma subclasse herda e adiciona aos atributos e operações de uma classe base.
• GoF – Padrões de design do Grupo dos Quatro.
• Alta coesão – Um padrão avaliativo GRASP que garante que uma classe não seja muito complexa e não realize funções não relacionadas.
• Baixo acoplamento – Um padrão avaliativo GRASP que mede o grau em que uma classe depende ou está conectada a outra classe.
• Fase de Início – A primeira fase do Processo Unificado Racional que trata da conceituação inicial e do início do projeto.
• Herança – Uma subclasse herda atributos ou características da sua classe pai (superclasse). Esses atributos podem ser sobrescritos na subclasse.
• Estado inicial: Em um diagrama de estado ou diagrama de atividade, isso representa o ponto em que o diagrama começa.
• Instância – Um objeto é uma instância de uma classe. A classe atua como um modelo para a criação de objetos. Qualquer número de instâncias da classe pode ser criado.
• Interface: Um classificador que define atributos e operações que formam um contrato comportamental. Uma classe ou componente provedor pode optar por implementar a interface (ou seja, implementar seus atributos e operações). Classes ou componentes clientes podem então depender da interface, usando o provedor sem conhecer quaisquer detalhes da classe real provedora.
• Iteração – Uma parte mini-projeto em que algum pequeno trecho de funcionalidade é adicionado ao projeto. Inclui um ciclo de desenvolvimento de análise, design e codificação.
• Junção: Um ponto em um diagrama de atividade onde múltios fluxos paralelos de controle se sincronizam e se reúnem novamente.
• Membro: Um atributo ou operação em um classificador.
• Mesclagem: Um ponto em um diagrama de atividade onde diferentes caminhos de controle se unem.
• Mensagem – Um pedido de um objeto a outro, solicitando que o objeto receptor realize alguma ação. Isso é essencialmente uma chamada a um método no objeto receptor.
• Método – Uma função ou procedimento em um objeto.
• Modelo – O artefato central do UML. Composto por diversos elementos dispostos em hierarquias com relações entre os elementos.
• Multiplicidade – Exibido ao lado da caixa de conceito externo em um modelo de domínio e indica a relação quantitativa entre objetos e outros objetos.
• Navegação: Indica qual extremidade de uma relação conhece a outra extremidade. Uma relação pode ter navegação bidirecional (cada extremidade conhece a outra) ou navegação unidirecional (uma extremidade conhece a outra, mas não vice-versa).
• Notação – Documentação gráfica com regras para criar métodos de análise e design.
• Nota: Um comentário textual adicionado a um diagrama para explicar o diagrama com mais detalhes.
• Objeto – Em um diagrama de atividade, um objeto que recebe informações de ou fornece informações para uma atividade. Em um diagrama de colaboração ou sequência, um objeto que participa da cena descrita no diagrama. Geralmente: uma instância ou exemplo de um classificador dado (Ator, Classe ou Interface).
• Pacote – Um grupo de elementos UML que pertencem logicamente juntos.
• Diagrama de pacote: Um diagrama de classes onde todos os elementos são pacotes e dependências.
• Padrão – Uma solução para o problema de atribuição de responsabilidades em interações entre objetos. É uma solução nomeada para um problema comum e bem conhecido.
• Parâmetro: Um parâmetro de uma operação.
• Polimorfismo – Mesma mensagem, métodos diferentes. Também usado como um padrão.
• Privado: Nível de visibilidade aplicado a um atributo ou operação, indicando que apenas o código dentro do classificador que o contém pode acessar o membro.
• Processador: Em um diagrama de implantação, isso representa um computador ou outro dispositivo programável no qual o código pode ser implantado.
• Protegido: Nível de visibilidade aplicado a um atributo ou operação, indicando que apenas o código dentro do classificador que o contém ou suas subclasses pode acessar o membro.
• Público: Nível de visibilidade aplicado a um atributo ou operação, indicando que qualquer código pode acessar o membro.
• Seta de direção de leitura – Indica a direção de uma relação em um modelo de domínio.
• Realização: Indica que um componente ou classe fornece uma interface específica.
• Papel – Usado em um modelo de domínio, é uma descrição opcional sobre o papel desempenhado por uma entidade.
• Diagrama de sequência: Um diagrama que mostra a existência de objetos ao longo do tempo e as mensagens trocadas entre esses objetos ao longo do tempo para realizar algum comportamento. Diagrama de estado – Um diagrama que mostra todos os estados possíveis de um objeto.
• Estado: Em um diagrama de estado, isso representa uma condição ou estado do sistema ou sub-sistema: o que está fazendo em um determinado momento e seus valores de dados.
• Diagrama de estado: Um diagrama que mostra os estados de um sistema ou sub-sistema, as transições entre estados e os eventos que causam essas transições.
• Estático: Um modificador aplicado a um atributo indicando que apenas uma cópia desse atributo é compartilhada entre todas as instâncias do classificador. Um modificador aplicado a uma operação indicando que a operação é independente e não opera sobre uma instância específica do classificador.
• Estereótipo: Um modificador aplicado a um elemento de modelo indicando algo que normalmente não pode ser expresso em UML. Essencialmente, os estereótipos permitem que você defina sua própria “dialetização” de UML.
• Subclasse: Uma classe que herda atributos e operações definidos por uma superclasse por meio de uma relação de generalização.
• Linha de nado: Um elemento em um diagrama de atividade que indica qual parte do sistema ou domínio é responsável por uma atividade específica. Todas as atividades em uma linha de nado são responsabilidade do Objeto, Componente ou Ator representado pela linha de nado.
• Time boxing – Cada iteração tem um limite de tempo fixo com um objetivo específico.
• Transição: Em um diagrama de atividade, isso representa o fluxo de controle de uma atividade, ramificação, fusão, divisão ou junção para outra. Em um diagrama de estado, isso representa uma mudança de um estado para outro.
• Fase de transição – A fase final do Processo Unificado Racional na qual os usuários são treinados para usar o novo sistema e o sistema é disponibilizado para os usuários.
• UML – A Linguagem de Modelagem Unificada melhora a análise e o design de projetos de software ao permitir relações mais estreitas entre objetos por meio de documentação textual e gráfica.
• Caso de uso: Em um diagrama de caso de uso, isso representa uma ação realizada pelo sistema em resposta a um pedido de um Ator.
• Diagrama de caso de uso: Um diagrama que mostra as relações entre Ator e Casos de uso.
• Visibilidade: Um modificador para um atributo ou operação que indica qual código pode acessar o membro. Os níveis de visibilidade incluem Público, Protegido e Privado.
• Fluxo de trabalho – Um conjunto de atividades que produzem algum resultado específico.

Livros populares de UML

Aqui estão alguns dos livros de UML mais vendidos que você pode ler para aprender UML:

1. UML Distillado: Um Guia Breve para a Linguagem Padrão de Modelagem de Objetos
2. UML 2 e o Processo Unificado: Análise e Design Orientado a Objetos Prático
3. Aprendendo UML 2.0
4. Construindo Aplicações Web com UML
5. Manual de Referência da Linguagem de Modelagem Unificada
6. Os Elementos do Estilo UML™ 2.0
7. UML para Programadores Java
8. Esboço Schaum de UML
9. Guia do Usuário da Linguagem de Modelagem Unificada
10. Guia de Certificação UML 2: Exames Fundamentais e Intermediários
11. Fundamentos do Design Orientado a Objetos em UML
12. Aplicando Modelagem Orientada a Casos de Uso com UML: Um Exemplo Comentado de Comércio Eletrônico
13. Projetando Sistemas Orientados a Objetos Flexíveis com UML
14. Modelagem Orientada a Casos de Uso com UML
15. Análise e Projeto de Sistemas com UML Versão 2.0: Uma Abordagem Orientada a Objetos
16. UML 2.0 em Resumo
17. Análise e Projeto Orientados a Objetos com Aplicações
18. UML Explicado
19. Padrões de Projeto: Elementos de Software Orientado a Objetos Reutilizáveis
20. O Princípio do Objeto: Desenvolvimento Orientado a Modelos Ágil com UML 2.0

Links Relacionados

1. Ferramenta Profissional de Design UML para Modelagem Visual