Diagramas e UML 2

O que é UML

Definição: UML (Unified Modeling Language)

Linguagem de modelagem e documentação de software, criada por Grady Booch, James Rumbaugh e Ivar Jacobson — que, inicialmente, criaram separadamente suas próprias linguagens de modelagem para software orientado a objetos, e depois decidiram unir forças numa linguagem única, a UML. É composta por diversos diagramas com notações gráficas próprias, que ajudam a expressar tanto a estrutura de um software quanto o seu comportamento.

flowchart TD
    UML["Diagramas UML"] --> Estrutura["Diagramas de<br/>estrutura"]
    UML --> Comportamento["Diagramas de<br/>comportamento"]
    Estrutura --> DClasse["D. de classe"]
    Estrutura --> DPerfil["D. de perfil"]
    Estrutura --> DEstruturasCompostas["D. de estruturas<br/>compostas"]
    Estrutura --> DComponentes["D. de<br/>componentes"]
    Estrutura --> DImplantacao["D. de<br/>implantação"]
    Estrutura --> DObjetos["D. de<br/>objetos"]
    Estrutura --> DPacotes["D. de pacotes"]
    Comportamento --> DAtividade["D. de<br/>atividade"]
    Comportamento --> DCasoDeUso["D. de<br/>caso de uso"]
    DAtividade --> DInteracao["D. de<br/>interação"]
    DInteracao --> DSequencia["D. de<br/>sequência"]
    DInteracao --> DVisaoGeral["D. de visão<br/>geral de interação"]
    DInteracao --> DTempo["D. de tempo"]
    DInteracao --> DComunicacao["D. de<br/>comunicação"]
    Comportamento --> DMaquinaEstados["D. de máquina<br/>de estados"]

Definição: Nem todo diagrama precisa ser usado

A UML possui uma grande quantidade de diagramas — usá-los todos não é viável, nem é essa a proposta. Cada projeto/empresa deve empregar apenas os diagramas que fizerem sentido para seu contexto, ou que consiga manter atualizados. Por definição, todos os diagramas da UML são requisitos de software — alguns também podem ser utilizados como requisito de usuário, quando ajudam o solicitante a compreender certas partes do software.

O mais conhecido — e provavelmente o mais utilizado — é o Diagrama de Caso de Uso, mas outros três diagramas se destacam pelo uso frequente: Classe, Sequência e Estado.

Diagrama de Caso de Uso (DCU)

Definição: Diagrama de Caso de Uso (DCU)

Fornece a visão geral das funcionalidades de um software e de quem utiliza cada uma. Apresenta os nomes das funcionalidades e os atores que interagem com elas — um ator pode ser um usuário final (pessoa) ou outro software. É possível representar relações entre funcionalidades e atores, como especializações (extends) ou reuso (include).

flowchart LR
    Usuario["Usuário"] --> Funcionario["Funcionário"]
    Usuario --> Cliente
    Funcionario -->|Extends| Usuario
    Cliente -->|Extends| Usuario
    Funcionario --> CadastrarCliente["Cadastrar Cliente"]
    Funcionario --> FinalizarAluguel["Finalizar Aluguel"]
    Funcionario --> AlugarCarro["Alugar Carro"]
    FinalizarAluguel -.->|include| GerarRecibo["Gerar Recibo"]
    AlugarCarro -.->|include| SugerirOpcionais["Sugerir Opcionais"]
    Cliente --> FornecerComentario["Fornecer Comentário"]
    Funcionario --> FornecerFaturamento["Fornecer Faturamento Anual"]
    ReceitaFederal["Receita Federal"] --> FornecerFaturamento

Definição: DCU caiu em desuso com as Metodologias Ágeis

Embora ofereça uma visão ampla e geral do software, o Diagrama de Caso de Uso vem caindo em desuso desde a popularização das Metodologias Ágeis — artefatos como Histórias de Usuário tendem a cobrir a mesma necessidade de forma mais leve e incremental.

Diagrama de Classe (DC)

Definição: Diagrama de Classe (DC)

Provê a visão estrutural das classes que compõem o software — atributos, métodos e relacionamentos entre elas — além de metainformações como tipos de dados. É a partir dessas classes que os objetos serão criados em tempo de execução, fazendo o software funcionar. As classes representadas podem ser tanto conceitos e entidades quanto os processamentos que o software realiza sobre elas.

classDiagram
    class Pessoa {
        -nome: String
        -dataNascimento: Date
    }
    class Setor {
        -nome: String
    }
    class Funcionario {
        +baterPonto() void
    }
    Pessoa o--> Setor
    Pessoa <|-- Funcionario

Diagrama de Sequência (DS)

Definição: Diagrama de Sequência (DS)

Oferece a visão comportamental de determinadas partes do software, mostrando interações entre objetos em execução numa ordem temporal — é a partir dessas interações que se entende como o software de fato funciona passo a passo.

sequenceDiagram
    participant Compra
    participant Estoque
    participant EmissorNota
    Compra->>Estoque: baixarEstoque(idProduto)
    Estoque-->>Compra: baixa realizada
    Compra->>Compra: finalizarCompra()
    Compra->>EmissorNota: emitirNota()
    EmissorNota-->>Compra: emissão realizada e enviada para a impressora

Diagrama de Estado (DE)

Definição: Diagrama de Estado (DE)

Fornece uma visão comportamental representando os diferentes estados ou situações que um determinado objeto, elemento ou conceito pode assumir ao longo do tempo — um conjunto finito de estados e as transições possíveis entre eles. As transições podem ser rotuladas para indicar o que causa a mudança de estado, quando necessário.

stateDiagram-v2
    [*] --> VerificandoDados: Usuário e senha fornecidos
    VerificandoDados --> SessaoCriada: Dados válidos
    VerificandoDados --> SessaoNaoCriada: Dados inválidos
    SessaoNaoCriada --> VerificandoDados: Dados inválidos
    SessaoCriada --> [*]

Diagramas de banco de dados: MER x Modelo Físico

Além dos diagramas da UML, dois outros diagramas auxiliam especificamente na representação do banco de dados de um software — no jargão de bancos de dados, esses diagramas costumam ser chamados de modelos (ver também Modelagem de Dados).

Definição: Modelo de Entidade-Relacionamento (MER) x Modelo Físico de Dados (MFD)

O MER fornece uma visão de como as entidades/conceitos do software — representados pelas tabelas do banco de dados — se relacionam entre si. É mais abstrato: mostra só os nomes das entidades e seus relacionamentos (cardinalidade), sem se preocupar com colunas ou tipos de dados. O MFD dá um passo além: mostra como as tabelas de fato estão estruturadas para armazenar os dados — nomes de colunas, tipos, chaves primárias e estrangeiras — seguindo, por convenção, os mesmos nomes das entidades/conceitos que representam (frequentemente com prefixos padronizados, como tb_ para tabelas, tx_ para colunas de texto e dt_ para colunas de data).

erDiagram
    FUNCIONARIO }o--|| SETOR : pertence

erDiagram
    tb_funcionario {
        UniqueID id PK
        text tx_nome
        date dt_data_nascimento
        UniqueID id_setor FK
    }
    tb_setor {
        UniqueID id PK
        text tx_nome
    }
    tb_funcionario }o--|| tb_setor : id_setor

Definição: Por que o MFD pode ter mais tabelas que o DC ou o MER

O mundo orientado a objetos (representado no Diagrama de Classe) é diferente do mundo relacional (representado no MFD) — um relacionamento muitos-para-muitos entre duas classes, por exemplo, não existe diretamente no modelo relacional: ele precisa de uma tabela associativa própria (ver Many to Many) para existir — uma tabela a mais no MFD que não tinha equivalente direto no DC ou no MER.