UML – Linguagem

Unificada de
Modelagem
Professora: Fernanda Alencar
Aluna: Lubnnia Morais
Agenda

01 Introdução

02 UML

03 Diagrama de Caso de Uso

04 Histórias de Usuários
Introdução
 Modelagem de Software
• O surgimento de softwares complexos resultou na
necessidade de reavaliar a forma de desenvolver sistemas;

• As técnicas tem evoluído de forma positiva, no que tange à

modelagem de sistemas;

• Modelar sistemas é o processo de desenvolver modelos

abstratos de um sistema, de maneira que cada modelo
apresenta uma visão ou perspectiva diferente do sistema.
 Modelagem de Software
• A modelagem de sistemas ajuda o analista a entender a
funcionalidade do sistema e os modelos são usados para
comunicação com os clientes.

• Atualmente, a modelagem de sistemas se tornou a

representação de um sistema usando algum tipo de notação
gráfica, que hoje em dia quase sempre são baseadas em
notações em Unified Modeling Language (UML).
 Para que modelar?
• Ajuda no gerenciamento da complexidade inerente ao
desenvolvimento de software;

• Ajuda na comunicação entre as pessoas envolvidas;

• Ter uma melhor compreensão do sistema;

• Proporciona um guia para construção do sistema.

 Evolução da Modelagem
• Na primeira metade da década de 90 surgiram várias
propostas de técnicas para modelagem de software;

• Houve uma enorme proliferação de propostas para modelar

sistemas segundo o paradigma orientado a objetos;

• Existiam diferentes notações gráficas para modelar uma

mesma perspectiva de um software
 Padronização
• União de três metodologias de modelagem:

• Método de Booch - Grady Booch;

• Método OMT (Object Modeling Technique) - James

Rumbaugh;

• Método OOSE (Object Oriented Software Engineering) - Ivar

Jacobson.
UML
 UML
• Surge em 1996 a UML como a melhor candidata para ser a
linguagem unificadora de notações;

• Em 1997 a UML é aprovada como padrão pela OMG (Object

Management Group);

• Atualmente na versão 2.0;

Histórico UML
 UML
• É uma linguagem visual;

• É independente de linguagem de programação;

• É independente de processo de desenvolvimento;

• Não é uma linguagem de programação;

• Não é uma metodologia

 UML
• A UML 2.0 descreve 13 tipos de diagramas:

• Comportamentais

• Estruturais

• Interação

• Esta quantidade de diagramas é justificada pela necessidade

de analisar o sistema por meio de diferentes perspectivas
Modela aspectos Modela aspectos
estáticos de um dinâmicos de um
sistema sistema
UML - Ferramentas
Diagrama de
Caso de Uso
 UML - Diagrama de Caso de Uso
• Os casos de uso são uma técnica para captar os requisitos
funcionais de um sistema;

• Descrevem as interações típicas entre os usuários de um

sistema e o próprio sistema, fornecendo uma narrativa de
como o sistema é utilizado;

• Ajuda a esclarecer os requisitos do sistema;

 UML - Diagrama de Caso de Uso
• Componentes:

• Casos de Usos

• Atores

• Relacionamentos
 UML - Diagrama de Caso de Uso
• Caso de Uso

• Representa as diferentes funcionalidades que o sistema disponibiliza

aos usuários;

• Unidade discreta da interação entre um usuário e o

sistema;

• Descrição de um conjunto de ações sequenciais que um sistema

realiza para alcançar um resultado observável e de valor para um
Ator.

reservarLivro gerarRelatório fazerPedido

 UML - Diagrama de Caso de Uso
• Atores

• Elemento externo ao sistema que interage com o mesmo;

• Pessoas que interagem com o sistema.

 UML - Diagrama de Caso de Uso

Ator
 UML - Diagrama de Caso de Uso
• Relacionamento

• Componente responsável por representar a interação entre os atores

e casos de usos

• Ator <--> Caso de Uso;

• Também representa ligações entre casos de uso ou entre atores

• Ator <--> Ator;

• Caso de Uso <-->Caso de Uso;

 UML - Diagrama de Caso de Uso
• Tipos de Relacionamento

• Associação;

• Inclusão;

• Extensão;

• Generalização.
 UML - Diagrama de Caso de Uso
• Relacionamento – Associação

• Informa a que caso de uso o ator está associado;

• Representa as trocas de informação entre os atores e

casos de uso;

• Um ator pode estar associado a vários casos de uso;

• Um caso de uso pode estar associado a vários atores;

• Representada por uma reta ligando o Ator ao Caso de

Uso

• Direcionada ou não
 UML - Diagrama de Caso de Uso
Relacionamento

reservarLivro

Ator Aluno
Caso de Uso

gerarRelatório

Funcionário
 UML - Diagrama de Caso de Uso
• Relacionamento – Inclusão

• Somente entre Casos de Usos;

• Utilizado quando um caso de uso é usado dentro de outro

caso de uso;

• Os relacionamentos de inclusão indicam obrigatoriedade

• A execução do primeiro obriga a execução do

segundo
 UML - Diagrama de Caso de Uso
• Relacionamento – Inclusão

• Representada por uma seta tracejada

• A seta aponta para o Caso de Uso incluído

• Possui a palavra “include” entre dois sinais de menor

(<<) e dois sinais de maior (>>)
 UML - Diagrama de Caso de Uso

acessarSistema

Aluno <<include>>
fazerLogin
 UML - Diagrama de Caso de Uso
• Relacionamento – Extensão

• Somente entre Casos de Usos;

• Um relacionamento de extensão é usado para

mostrar: comportamento opcional;

• Possui a palavra “extend” entre dois sinais de menor (<<)

e dois sinais de maior (>>)
 UML - Diagrama de Caso de Uso

substituirTexto
<<extend>>
editarDocumento

Escritor
<<extend>>
corrigirOrtografia
 UML - Diagrama de Caso de Uso
• Relacionamento – Generalização

• Pode existir entre dois Casos de Uso ou entre dois

atores;

• Permite que um Caso de Uso (ou um ator) herde

comportamento de outro Caso de Uso (ou ator);

• O Caso de Uso geral descreve as características

compartilhadas;

• As especializações definem características específicas.

UML - Diagrama de Caso de Uso

realizarPagamento

Cliente

realizarPagamento realizarPagamento
ComCartao ComDinheiro
UML - Diagrama de Caso de Uso

reservarLivro

Usuário
devolverLivro

solicitarCompraLivro

Professor
Histórias de
Usuários
 UML – Histórias de Usuários
• Uma história de usuário é a definição textual das necessidades de
uma pessoa;

• Possui três aspectos críticos, chamados de “os três C’s”:

• Cartão;

• Conversas;

• Confirmação.
 UML – Histórias de Usuários
• Cartão

• Descrição da necessidade do usuário, ou seja, a própria User Story.

Essa descrição é concisa, e assim suficiente para apenas identificar
qual é e de que se trata essa necessidade;

• O nome “Cartão” é dado porque frequentemente as User Stories são

escritas em cartões de índice ou fichas;

• Os padrões mais utilizados para se escrever o Cartão da User Story

estabelece três parâmetros da necessidade do usuário: “QUEM”, “O
QUÊ” e “POR QUÊ”.
 UML – Histórias de Usuários
• Cartão

• “QUEM” define quem é o usuário que tem a necessidade. Pode ser

representado por um tipo de usuário do produto (como “Comprador
de Livros” ou “Administrador do Sistema”, por exemplo), por uma
persona ou até mesmo por um usuário específico.

• “QUEM” ajuda a criar no leitor da User Story uma imagem mental

desse usuário.
 UML – Histórias de Usuários
• Cartão

• “O QUÊ” define qual é a necessidade do usuário. Os requisitos do

produto são representados apenas por essa parte.

• “POR QUÊ” define qual o benefício do usuário ao ter a

funcionalidade desenvolvida para atender a necessidade. Ou seja,
qual o valor direto obtido pelo usuário.
 UML – Histórias de Usuários

Eu como <ator>
Quero um/uma <necessidade>
Para que <problema a ser resolvido>
 UML – Histórias de Usuários

Eu como agente de precificação

quero consultar os preços do concorrente
para que eu possa comparar os valores que
pretendo praticar em minha loja sem ter de visitar
a loja de cada um deles.
 UML – Histórias de Usuários

Bill Wake, autor do livro “Extreme Programming Explored”

 UML – Histórias de Usuários
• Independente

• Toda história de usuário deve ser independente de outras histórias.

• Negociável

• Lembre-se toda história de usuário é apenas um desejo do usuário,

logo, pode considerar ela sendo apenas um ponto de partida.
Portanto, deve ser totalmente negociável.
 UML – Histórias de Usuários
• Valiosa

• Deve representar valor de negócio, sempre. Sem valor de negócio

não faz sentindo existir.

• Estimável

• O time deve ser capaz de estimá-la.

 UML – Histórias de Usuários
• Pequena (Small)

• Deve ser pequena e assim reduzindo as incertezas e dificuldades de

estimativas.

• Testável

• Todas histórias de usuário devem ser testáveis, ou seja, deve ser

possível validar se atingem os critérios de aceitação.
 UML – Histórias de Usuários
• Conversas

• São conversas sobre a User Story, por onde a solução de negócios e

os detalhes dessa solução são discutidos, negociados, definidos e
então documentados.

• As conversas são imprescindíveis para o trabalho do Time de

Desenvolvimento, uma vez que o Cartão não possui detalhes que
permitam que o item seja desenvolvido.

• Participam dessas conversas o Product Owner, membros do Time de

Desenvolvimento e outras pessoas de negócios envolvidas, caso
haja, mas qualquer pessoa que possa contribuir com detalhes pode
participar.
 UML – Histórias de Usuários
• Confirmação

• São regras que estabelecem como a funcionalidade deve se

comportar uma vez implementada. Esses critérios são chamados de
Critérios de Aceitação e os Testes de Aceitação.
 UML – Histórias de Usuários
• Critérios de Aceitação

• São expressos por enunciados pequenos e de fácil entendimento.

São utilizados para determinar quando a funcionalidade produzida
pelo Time de Desenvolvimento está completa e, assim, nada mais
deve ser adicionado a ela.
 UML – Histórias de Usuários
• Critérios de Aceitação

• Eu, como Comprador de Livros, quero utilizar meu cartão de

crédito no pagamento dos livros escolhidos, para ter praticidade e
segurança no pagamento.

• Critério #1: somente podemos aceitar cartões de crédito com bandeiras com que
temos convênio.

• Critério #2: somente podemos aceitar cartões de crédito com data de expiração
no futuro.
 UML – Histórias de Usuários
• Testes de Aceitação

• São criados a partir de aplicações de exemplos aos Critérios de

Aceitação, onde se verificam se dadas entradas estão produzindo os
resultados esperados.

• Servem para verificar se a funcionalidade está se comportando

conforme esperado, sob um ponto de vista de negócios.
 UML – Histórias de Usuários
• Critério #1: somente podemos aceitar cartões de crédito com
bandeiras com que temos convênio.

• Comprador de Livros utiliza cartão de crédito Visa

•Pode-se ver que a bandeira de cartão aceita é Visa,

Aceitou = correto.

• Recusou = errado,enquanto que Amex não.

deve ser corrigido!.

• Comprador de Livros utiliza cartão de crédito Amex

• Recusou = correto.

• Aceitou = errado, deve ser corrigido!

 UML – Histórias de Usuários
• Critério #2: somente podemos aceitar cartões de crédito com data
de expiração no futuro..

• Comprador de Livros utiliza cartão de crédito com expiração em

23/06/2022

• Aceitou = correto.

• Recusou = errado, deve ser corrigido!

• Comprador de Livros utilizou cartão de crédito com expiração em

01/01/2000

• Recusou = correto.

• Aceitou = errado, deve ser corrigido!

 Referências
• BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Elsevier Brasil, 2006.

• UML. Disponível em: https://www.uml.org/. Acesso em: 14/06/21.

• Como escrever histórias de usuário — templates e técnicas. Disponível em:

https://reynaldosouzajr.medium.com/como-escrever-hist%C3%B3rias-de-usu%C3%A1rio-templates-e-t
%C3%A9cnicas-ada8d5af5654. Acesso em: 14/06/21
Obrigada!