Basicamente, UML (Unified Modeling Language) é uma linguagem de notação (um jeito de escrever, ilustrar, comunicar) para uso em projetos de sistemas. Esta linguagem é expressa através de diagramas. Cada diagrama é composto por elementos (formas gráficas usadas para os desenhos) que possuem relação entre si. Os diagramas da UML se dividem em dois grandes grupos: diagramas estruturais e diagramas comportamentais.

1. Diagramas estruturais devem ser utilizados para especificar detalhes da estrutura do sistema (parte estática), por exemplo: classes, métodos, interfaces, namespaces, serviços, como componentes devem ser instalados, como deve ser a arquitetura do sistema etc.

2. Diagramas comportamentais devem ser utilizados para especificar** detalhes do comportamento do sistema** (parte dinâmica), por exemplo: como as funcionalidades devem funcionar, como um processo de negócio deve ser tratado pelo sistema, como componentes estruturais trocam mensagens e como respondem às chamadas etc.

UML ajuda muito a deixar o escopo claro, pois centraliza numa única visão (o diagrama) um determinado conceito, utilizando uma linguagem que todos os envolvidos no projeto podem facilmente entender. Mas ajuda desde que utilizada na medida certa, ou seja, apenas quando realmente é necessário. O maior problema na produção de software, a maior dor, em qualquer país do mundo, chama-se comunicação ruim.

Você já parou para pensar em como seria difícil desenvolver um sistema complexo, com dezenas de funcionalidades e requisitos, sem o apoio de uma documentação para guiar todo esse processo? Certamente, seria uma tarefa problemática e as chances de obter um resultado de baixa qualidade seriam altíssimas.

Por isso, os diagramas UML são essenciais para evitar dois problemas comuns no desenvolvimento de software: os erros das fases de especificação do projeto e a comunicação entre as diferentes partes envolvidas, como gerentes, pessoas desenvolvedoras, analistas, Scrum Master e Product Owner, por exemplo. Com o uso desses diagramas, é possível obter uma visão clara e única do sistema, deixando todas as entidades envolvidas no projeto a par do que será desenvolvido e evitando erros de implementação. Afinal, trata-se de uma linguagem padrão, objetiva e eficiente que facilmente será entendida por toda a equipe.

Pedro Jardel

Temos várias UML (Unified Modeling Language) e iremos mostrar alguns Exemplos.

Ricardo Santos

Esse diagrama documenta a funções do sistema para o lado do usuário, ou seja, ele descreve as principais funcionalidades do sistema e a interação dessas funcionalidades com os usuários do mesmo sistema. Nesse diagrama não nos aprofundamos em detalhes técnicos que dizem como o sistema faz. Este artefato é comumente derivado da especificação de requisitos, que por sua vez não faz parte da UML. Pode ser utilizado também para criar o documento de requisitos.

O bendito é composto por 4 partes. Veja:

1- Cenário: Sequência de eventos que acontecem quando um usuário interage com o sistema.

2- Ator: Usuário do sistema, ou melhor, um tipo de usuário.

3- Use Case: É uma tarefa ou uma funcionalidade realizada pelo ator (usuário)

4- Comunicação: é o que liga um ator com um caso de uso

Agora vamos ver um exemplo desse diagrama. Veja:

“A clínica médica Saúde Perfeita precisa de um sistema de agendamento de consultas e exames. Um paciente entra em contato com a clínica para marcar consultas visando realizar um check-up anual com seu médico de preferência. A recepcionista procura data e hora disponível mais próxima na agenda do médico e marca as consultas. Posteriormente o paciente realiza a consulta, e nela o médico pode prescrever medicações e exames, caso necessário”.

Podemos ver cada detalhe do diagrama. Para início, temos esses bonecos chamados de atores, eles representam alguém no sistema. Em seguida, há as setas, elas indicam a comunicação no sistema. E por fim, temos os casos de uso que são essas elipses com ações dentro.

Além disso, vale ressaltar outros elementos, como o include, extends e generalização

1- include: Quando o caso de uso A “inclui” o caso de uso B, significa que sempre que o caso de uso A for executado o caso de uso B também será executado. A direção do relacionamento é do caso de uso que está incluindo para o caso de uso incluído.

2- extends: Quando o caso de uso B estende o caso de uso A, significa que quando o caso de uso A for executado o caso de uso B poderá (poderá – talvez não seja) ser executado também. A direção do relacionamento é do caso de uso extensor (aqui o caso de uso B) para o caso de uso estendido (aqui o caso de uso A).

3- generalização: Quando o caso de uso B generaliza o caso de uso C isso significa que, além de fazer tudo que nele está especificado (ele = B), ele também executará tudo que está especificado no caso de uso C. Muitos profissionais falam que isso não deve ser compreendido como a herança da orientação a objetos, mas na minha opinião deve ser sim, apenas (em tempo de modelagem de caso de uso) estamos num nível de abstração diferente, mas o produto final desta modelagem será software codificado. A direção do relacionamento é sempre do generalizador (aqui o caso de uso B) para o generalizado (caso de uso C).

Luis Felipe Souza

Diagramas de classes estão entre os tipos mais úteis de diagramas UML pois mapeiam de forma clara a estrutura de um determinado sistema ao modelar suas classes, seus atributos, operações e relações entre objetos. Por meio do nosso software de criação de diagramas UML, criar estes tipos de diagramas não é tão assustador como pode parecer. Este guia lhe mostrará como entender, planejar e criar seus próprios diagramas de classes.

A Linguagem de modelagem unificada (UML) ajuda você a modelar sistemas de diversas maneiras. Um dos tipos mais populares na UML é o diagrama de classes. Bastante usado por engenheiros de software para documentar arquiteturas de software, os diagramas de classes são um tipo de diagrama da estrutura porque descrevem o que deve estar presente no sistema a ser modelado. Não importa seu nível de familiaridade com diagramas UML ou de classe, nosso software de UML online foi concebido para ser simples e fácil de usar.

Diagramas de classes oferecem uma série de benefícios para qualquer organização.

Use diagramas de classes UML para:

*Ilustrar modelos de dados para sistemas de informação, não importa quão simples ou complexo.

*Entender melhor a visão geral dos esquemas de uma aplicação.

*Expressar visualmente as necessidades específicas de um sistema e divulgar essas informações por toda a empresa.

*Criar gráficos detalhados que destacam qualquer código específico necessário para ser programado e implementado na estrutura descrita.

*Fornecer uma descrição independente de implementação de tipos utilizados em um sistema e passados posteriormente entre seus componentes.

Diagrama de classes não surge do nada ele é consequência do prévio levantamento de requisitos , definição de casos de usos e classes. Como exemplo vamos supor que você tivesse que desenvolver um sistema para automatizar um consultório dentário. As etapas básicas envolvidas seriam:

*Levantamento e análise de requisitos do sistema a ser desenvolvido. Entrevista com o dentista(s) e com as pessoas que trabalham no consultório.

* Definição dos objetos do sistema : Paciente , agenda , dentista , serviço , contrato , consulta , pagamento.

*Definição dos atores do sistema : paciente, dentista , secretária.

*Definição e detalhamento dos casos de uso: marcar consulta , confirmar consulta , cadastrar paciente , cadastrar serviços.

*Definição das classes : paciente , dentista , exame , agenda , serviço.

*Definir os atributos e métodos das classes.

Thiago Alves

Um diagrama de objetos UML representa uma instância específica de um diagrama de classes em um determinado momento. Quando representado visualmente, você verá muitas semelhanças ao diagrama de classes.

Um diagrama de objetos incide sobre os atributos de um conjunto de objetos, e como eles se relacionam entre si. Por exemplo, neste diagrama de objetos abaixo, as três contas bancárias estão relacionadas ao próprio banco. Os nomes da classe mostram os tipos de contas (poupança, corrente e de cartão de crédito) que um determinado cliente poderia ter neste banco. Os atributos de classe são diferentes para cada tipo de conta. Por exemplo, o objeto do cartão de crédito possui um limite de crédito, enquanto a poupança e a conta corrente possuem taxas de juros.

Diagramas de objetos não são usados apenas em casos de uso bancário. Você pode criar um diagrama de objetos para árvores genealógicas, departamentos corporativos ou qualquer outro sistema com partes inter-relacionadas.

Diagramas de objetos são fáceis de criar: são feitos de objetos, representados por retângulos e ligados entre si por linhas. Confira os principais elementos de um diagrama de objetos.

• Objetos: Objetos são instâncias de uma classe. Por exemplo, se um “carro” for uma classe, um modelo Nissan Altima de 2007 é um objeto de uma classe.

• Títulos de classe: Títulos de classe são os atributos específicos de uma determinada classe. No diagrama de objetos de árvores genealógicas, títulos de classe incluem o nome, sexo e idade dos membros da família. Você pode listar títulos de classe como itens no objeto ou até mesmo nas propriedades do próprio objeto (tal como a cor).

• Atributos de classe: Atributos de classe são representados por um retângulo com duas abas que indicam um elemento de software.

• Links: Ligações são as linhas que conectam duas formas de um diagrama de objetos, uma a outra. O diagrama de objetos corporativo abaixo mostra como departamentos são ligados no organograma tradicional.

Thalisson Dias

UML prevê um diagrama específico para modelar os diversos estados de um objeto durante o seu ciclo de vida. Tal diagrama é chamado de diagrama de estados. Ele é muito utilizado na área de eletrônica digital assim como em linguagens formais. Foi importado pela UML por ser uma maneira eficiente e clara de se descrever todos os possíveis estados de um sistema assim como quais eventos levam a transição de um estado para outro.

Um exemplo simples de um diagrama de estados. Neste exemplo, os possíveis estados de um objeto que representa a venda de itens quaisquer são apresentados assim como os eventos que levam a transição de um estado da venda para outro.

Outro exemplo

Luis Felipe Souza

Trata-se de um fluxo do sistema, onde um cliente após ser cadastrado sofre uma avaliação, e dependendo do resultado da avaliação (feita através do software) o fluxo pode tomar caminhos diferentes.

Se todo o fluxo completar-se, antes de encerrar-se, o cliente vai para uma situação de “espera”, onde outro fluxo, por exemplo, tratará o envio de uma nova oferta ao cliente que passou em todas as etapas.

Ricardo Santos