UML

O que é diagrama de caso de uso?

Na Linguagem de modelagem unificada (UML), o diagrama de caso de
uso resume os detalhes dos usuários do seu sistema (também
conhecidos como atores) e as interações deles com o sistema. Para criar
um, use um conjunto de símbolos e conectores especializados. Um bom
diagrama de caso de uso ajuda sua equipe a representar e discutir:
• Cenários em que o sistema ou aplicativo interage com pessoas,
organizações ou sistemas externos
• Metas que o sistema ou aplicativo ajuda essas entidades
(conhecidas como atores) a atingir
•O escopo do sistema

Quando usar o diagrama de caso de uso

O diagrama de caso de uso não oferece muitos detalhes — não
espere, por exemplo, que ele mostre a ordem em que os passos
são executados. Em vez disso, um diagrama de caso de uso
adequado dá uma visão geral do relacionamento entre casos de
uso, atores e sistemas. Os especialistas recomendam usar o
diagrama de caso de uso para complementar um caso de uso
descrito em texto.

UML é o kit de ferramentas de modelagem para criar o diagrama.

O caso de uso é representado por uma forma oval rotulada.
Bonecos palito representam os atores no processo, e a
participação do ator no sistema é modelada com uma linha entre
o ator e o caso de uso. Para representar o limite do sistema,
desenhe uma caixa em torno do próprio caso de uso.

O diagrama de caso de uso UML é ideal para:

 • Representar as metas de interações entre sistemas e
usuários

• Definir e organizar requisitos funcionais no sistema

• Especificar o contexto e os requisitos do sistema

• Modelar o fluxo básico de eventos no caso de uso

Elementos do diagrama de caso de uso

Para entender o que é um diagrama de caso de uso, é necessário
primeiro saber como é ele feito. São componentes comuns:

• Atores: os usuários que interagem com o sistema. Ator

pode ser uma pessoa, organização ou sistema externo
que interage com seu aplicativo ou sistema. Eles devem
ser objetos externos que produzam ou consumam dados.
 • Sistema:uma sequência específica de ações e interações
entre os atores e o sistema. O sistema também pode ser
chamado de cenário.

• Metas: o resultado final da maioria dos casos de uso. Um

diagrama criado corretamente deve descrever as
atividades e variantes usadas para atingir a meta.

Símbolos e notação no diagrama de

caso de uso
A notação do diagrama de caso de uso é bastante objetiva e não
envolve a mesma quantidade de símbolos de outros diagramas
UML. Veja todas as formas que você encontra no Lucidchart:
 • Caso de uso: formato oval na horizontal e que representam
os diferentes usos que um usuário pode ter.

• Atores:
bonecos palito, representando as pessoas que
realmente implementam os casos de uso.

• Associações:uma linha entre atores e casos de uso. Nos

diagramas complexos, é importante saber quais atores
estão associados a quais casos de uso.

• Caixa de limite do sistema: caixa que define um escopo do

sistema para os casos de uso. Todos os casos de uso fora
da caixa são considerados fora do escopo do sistema. Por
exemplo: o Psycho Killer está fora do escopo de
ocupações no exemplo da serra elétrica abaixo.

• Pacote:
uma forma UML na qual colocar diferentes
elementos em grupos. Assim como no diagrama de
componentes, esses agrupamentos são representados
como pastas de arquivos.

Como fazer um diagrama de caso de

uso uml
Fazer um diagrama de caso de uso não é tão difícil quanto
parece. Os princípios de diagramação em si são bem simples. O
que pode deixá-lo mais complicado é a complexidade do próprio
sistema que você deseja representar.

Resumidamente, estes são os passos para fazer um diagrama de

caso de uso uml:

1. Comece inserindo a forma de sistema no seu diagrama

2. Adicione os atores primários (inicia a utilização do

sistema) e secundários (reage)
 3. Insira os casos de uso na ordem em que acontecem para
representar as tarefas realizadas dentro do sistema

4. Rotule os casos de usos usando verbos e descrições

simples para reforçar a ideia de que uma ação acontece

5. Conecte os atores e casos de uso para criar os

relacionamentos

6. Lembrando que os relacionamentos podem ser de

associação, inclusão (include), extensão (extend) ou de
generalização (herança), quando são entre casos de uso
gerais e especializados.

Exemplos de diagrama de caso de

uso
Exemplo de diagrama de caso de uso de publicação de livros

Este diagrama de caso de uso é uma representação visual do

processo necessário para escrever e publicar um livro. Seja você
autor, agente ou vendedor de livros, use esse diagrama no
cenário de caso de uso para ajudar sua equipe a publicar o
próximo grande sucesso do mercado. Personalize este modelo
pronto para criar seu próprio diagrama de caso de uso.
Exemplo de diagrama de caso de uso para venda de passagens
de trem

Você pode adaptar esse modelo para qualquer processo no

qual o cliente adquire um serviço. Com esquemas de cores
atraentes, texto fácil de ler e de editar, além de uma ampla
biblioteca de formas UML, você tem o que precisa para começar
um projeto! Clique para editar esse modelo de caso uso UML.
Exemplo de diagrama de caso de uso de serra elétrica

Veja este exemplo: um homem com uma serra elétrica interage

com o ambiente ao redor. Dependendo da situação e do
contexto da situação, ele se enquadra em um de muitos casos
de uso diferentes. Ele parece estar a caminho do trabalho? O
modo de ele segurar a serra elétrica parece ameaçador? Por
exemplo: se ele estiver usando a serra elétrica em um ambiente
não ocupacional, temos motivos para pensar que ele se
enquadra no escopo de "assustador".
Documentação de Software

Na medida que o software cresce, torna-se mais difícil ententer,

manter e detectar erros. Grande parte destas questões é superada
quando há uma documentação do sofware.

Ao contrário do que pensamos, a documentação de um software

não é o código. Tendo em conta que existem milhares de
linguagens de programação, o código pode não ser percebido por
desenvolvedores de outras linguagens.

Devemos considerar que os Gestores ou Clientes não precisam ler

exaustivamente cada linha de código para entender o software. A
documentação deve ser percebida até para os não desenvolvedores.

A documentação não precisa ser complexa, muito formal ou focada

em muitos detalhes desnecessários. Apenas precisamos documentar
os aspectos que facilitam a compreensão do Software, tanto para os
desenvolvedores quanto para os outros envolvidos.
As imagens abaixo apresentam uma sugestão simples para
documentação de um software.

Documentação
Para começar, o que seria uma documentação de software?

Quando falamos sobre documentação de software (ou de código),

estamos nos referindo a qualquer material textual que times de
engenharia, teste, produto e demais profissionais utilizam para realizar
o seu trabalho.

Mas não somente isso: a documentação deve ser uma descrição

precisa sobre um sistema de software. Quanto maior a precisão desses
documentos, maior o status de autoridade que eles podem ter.

Aliás, documentações de software podem ser utilizadas como fonte de

evidência. Se está escrito, então é lei.

Documentações devem abstrair a tecnicidade de um assunto – seja de

implementações, configurações, etc. – e focar no que é essencial para o
usuário, trazendo informações completas e imprescindíveis para que
você possa alcançar um objetivo e/ou realizar uma ação.

Uma boa documentação é aquela capaz de apoiar o time nas etapas de

desenvolvimento, compreensão e manutenção de código. Deve ser,
também, capaz de auxiliar usuários e quem mais tiver interesse em
conhecer mais sobre o sistema de software e seus processos
relacionados.

Para que isso aconteça, é necessário que você identifique qual tipo de
documentação a sua equipe/projeto deve investir esforço e qual é o
perfil das pessoas que lerão os documentos criados.

Vou falar disso mais adiante, mas antes precisamos entender o porquê
da documentação está aquém do ideal na maioria dos projetos.

Quais são os tipos de documentação de código que posso usar no

meu projeto?

Existem diversos tipos de documentação, sendo cada tipo útil para

situações diferentes.

O livro Software Engineering at Google conta com um capítulo sobre

documentação de software. Os autores (Titus Winters, Tom Manshreck
e Hyrum Wright) listam diversos tipos de documentações técnicas, por
exemplo:

• Documentação de referência.
• Documentos de design.
• Tutoriais.
• Documentação conceitual.
• Landing pages.
Cada tipo de documentação tem seu propósito específico que deve ser
seguido à risca.

Assim como uma API, que deve fazer uma única coisa (e bem), o ideal é
que você evite criar documentos universais, mas sim documentos de
propósitos diferentes, organizados em uma ordem lógica.

Claro que essa lista está longe de ser definitiva. Um exemplo é o estudo
que levantou as “dores de documentação” que citamos anteriormente.
Nele, também encontramos os tipos de documentos considerados
úteis por devs.

Neste trabalho, os tipos de documentação foram levantados com base

na taxonomia de problemas identificados, o que resultou numa lista
com 13 itens:

1. API reference.
2. Comentário de código.
3. Guia de contribuição.
4. Guia de deploy.
5. Guia de migração.
6. Guia de instalação.
7. Guia de primeiros passos.
8. FAQ.
9. How-to/Tutorial.
10.Release Note/Change log.
11.Manual de usuário.
12.Tutorial em vídeo.
13.Threads no StackOverflow.

Informações que a documentação do software precisa ter

A documentação de software auxilia o público a entender e utilizar o
produto, seja esse público composto de administradores, colegas,
técnicos ou usuários finais. Por isso, é fundamental que ela seja
clara, pesquisável e, acima de tudo, útil.
Uma boa documentação de software deve capacitar o público e não
frustrá-lo, para isso precisa ter alguns elementos básicos, como
suporte ao cliente. Mas não só isso. O documento também precisa
ter a construção da marca e da confiança.
Isso porque os usuários procuram o documento quando mais
precisam. E se as informações não estiverem lá de forma clara e
precisa, eles começarão a procurar alternativas e, neste caso, elas
podem não ser a melhor opção para a sua empresa. É por isso que a
maior parte da documentação de software está disponível no site da
empresa ou em páginas de ajuda em canais digitais.
A seguir, relacionamos 4 itens que consideramos essenciais em
uma documentação de software. São eles:

1. Suporte ao usuário final

Um guia de usuário, com notas de versão, sistemas de ajuda online,
programas de treinamento ou procedimentos operacionais, isto é,
qualquer detalhe que ajude os usuários a usar o produto.

2. Suporte de marketing
Uma publicidade focada no produto, usada para promover a marca
e a empresa, como fotos, vídeos explicativos, apresentações e
materiais que levam a páginas de destino com informações técnicas.

3. Suporte ao desenvolvimento
Especificações funcionais e técnicas, que servem como guias de
desenvolvimento de software ou simplesmente procedimentos e
ferramentas para ajudar desenvolvedores a fazer seu trabalho.

4. Suporte à organização
Informações sobre a empresa, sua estrutura, seus procedimentos,
fluxos de trabalho, as políticas e tudo o mais que os profissionais da
sua equipe precisam saber para realizar seus trabalhos.
Boas práticas de documentação

Para auxiliar você a documentar seu software com eficácia e a

garantir os resultados esperados, relacionamos 5 boas práticas
focadas no conteúdo da documentação. Para aspectos técnicos do
documento, há ferramentas disponíveis no mercado que podem
ajudar também.

1. Escreva o que seu público gostaria de ler

Entenda bem para qual público você está documentando e defina
com cuidado sobre o idioma, tom de voz, a estrutura e os tópicos
que você vai usar.

2. Adicione um índice, de fácil leitura

Prepare os leitores para o que eles irão encontrar no documento e
permita com que avancem ou retornem a um certo ponto com
facilidade.

3. Explique de maneira simples e detalhada

Sua documentação deve ser fácil de consumir, tanto para sua equipe
quanto para os usuários do software. Detalhe todos os itens, porém
faça isso de forma simples e direta, sem focar demais em
obviedades.
4. Crie um plano de atualização
Adicionar a data da última atualização é essencial para ambientar o
leitor da documentação. Além disso, garantir que o documento
esteja sempre relevante é fundamental.

5. Ajude os leitores a encontrar seu documento

Faça com que, ao ser procurado, seu documento seja encontrado.
Para isso, adicione recursos e nomes de produtos a títulos e
explicações, facilitando a indexação em canais digitais, por exemplo.
Passo a passo para uma boa documentação de softwares
Escrita, geralmente, por um especialista em redação técnica, a
documentação de softwares, ou documentação técnica, deve
traduzir detalhes do produto em um conteúdo que seja facilmente
compreendido pelos usuários finais.
Para isso, relacionamos abaixo um passo a passo em 5 etapas para
a hora de documentar um software.

1. Crie um plano de documentação

Tenha em mãos um planejamento para as etapas de documentação
de software, com: objetivos, recursos existentes, guias de estilo de
linguagem, esboço de tópicos que a documentação tratará,
ferramentas a serem utilizadas, como será o gerenciamento e, por
fim, prazo e resultados finais, que servirão para guiá-lo nesse projeto
de documentar.

2. Defina estrutura e design

Antes mesmo de começar a criar o conteúdo, defina como será a
estrutura da sua documentação de software e qual o design que
será apresentado, incluindo como será desenhada a hierarquia das
informações referentes aos documentos técnicos e qual a estrutura
de navegação do documento.

3. Faça um documento estruturado

O conteúdo de uma boa documentação de software deve ter uma
apresentação que facilite a análise. O usuário tem que conseguir
encontrar rapidamente o que precisa. Pense em um modelo que
contenha uma estrutura como: título, subtítulo, visão geral, índice,
características e talvez um “leia mais”, com informações adicionais.

4. Obtenha feedback antes de finalizar

Já a fase inicial, no rascunho ou esboço da documentação, procure

obter feedback do seu documento, tanto da parte estrutural como
de erros de gramática. Quando chegar na fase final, com cerca de
90% da sua documentação concluída, peça para seu público revisar
profundamente seu documento, para evitar surpresas desagradáveis
ao finalizar.

5. Edite, edite e edite mais

Lembre-se o processo contínuo de edição é que faz uma boa
redação. Por isso, após colher os feedbacks e revisar, exponha o
documento a edição de um profissional de redação técnica, para
que todos os itens sejam profundamente revisados. Alguém com
esse olhar pode garantir que a linguagem tenha um fluxo lógico e
seja consistente ao longo do texto.