1. Modelagem de Software
Leinylson Fontinele Pereira
Engenharia de Software

2. 2
Modelagem de Software
• A modelagem de software é a construção de modelos
abstratos de um software:
• Apresenta uma visão ou perspectiva diferente do sistema,
• Modelos podem usar notações gráficas, tal como UML, ou
modelos formais com especificação formal
Ajuda na:
– Extração de requisitos
– Comunicação com a equipe – modelo técnico

3. Modelagem de Software
• Modelos são abstrações do sistema, e não uma
representação alternativa dele
– Representação: mantém todas as informações a
respeito da entidade apresentada
– Abstração: simplifica e seleciona as características
mais genéricas
– Exemplo:
• Representação: um livro traduzido em outra língua
• Abstração: um resumo pode ser considerado uma abstração
da entidade livro

4. Modelagem de Software
• Objetivos:
– Descrever o que o cliente deseja.
– Estabelecer a base para a criação de um projeto
de software.
– Definir um conjunto de requisitos que possa ser
validado quando o software for construído.

5. Modelagem de Software
• Podem ser usados em diferentes etapas da engenharia
de software
– Engenharia de requisitos – extrair requisitos do sistema,
esclarecer o que o sistema faz, tirar dúvidas, explicar os
requisitos para outros stakeholders
– Processo de Projeto – Descrever o sistema
– Outras etapas - Documentar a estrutura e operação do
sistema, estimular a discussão entre os engenheiros de
software, descrever detalhadamente o sistema

6. Modelagem de Software
• Diferentes modelos proporcionam
perspectivas (ou pontos de vista) diferentes:
– Perspectiva externa
• Modelo de contexto
– Perspectiva de interação
• Casos de uso, diagrama de sequencia...
– Perspectiva estrutural
• Classes, objetos, colaboração
– Perspectiva comportamental
• Diagrama de estados e derivados

7. Modelagem de Software
• Perspectiva externa: modela o contexto ou o ambiente do
sistema
• Perspectiva de interação: modela as interações entre um
sistema e seu ambiente, ou entre os componentes de um
sistema
• Perspectiva estrutural: modela a organização de um
sistema ou a estrutura dos dados processados pelo sistema
• Perspectiva comportamental: modela o comportamento
dinâmico do sistema e como ele reage aos eventos

8. Modelagem de Software
• A UML (Unified Modeling Language) é uma
linguagem de modelagem amplamente utilizada:
– Conjunto de notações que visam apoiar a
modelagem de sistemas orientados a objetos
– Não explicita como a modelagem deve ser
conduzida
– Pode ser usada para modelar sistemas não-OO
• Modelos de domínio
• Modelos de contexto

9. Modelagem de Software
– Diagramas de Atividade: atividades envolvidas em um
processo ou no processamento de dados
– Diagramas de Caso de Uso: interações entre um sistema e seu
ambiente
– Diagramas de Sequência: interação entre os atores e o
sistema, e entre os componente ou objetos do sistema
– Diagramas de Classe: mostram as classes de objetos do
sistema e as associações entre elas
– Diagramas de Estado: mostram como o sistema reage a
eventos internos e externos

10. Modelagem de Software
• Modelos de contexto
– Diagramas de Atividades
• Modelos de interação
– Diagramas de Casos de uso, Diagramas de Sequência
• Modelos estruturais
– Diagramas de Classe
• Modelos comportamentais
– Diagramas de Estado

11. Modelos de Contexto
• Definem os limites do sistema
• Normalmente usados em um estágio inicial da especificação
de um sistema
• Mostram quais outros sistemas fazem parte do ambiente, mas
não mostram os tipos de relacionamentos entre sistemas
• Os sistema externos podem:
– produzir dados para o sistema consumir dados deste
– compartilhar dados
– ser conectados diretamente por meio de uma rede
– estar fisicamente no mesmo local ou em locais separados

12. Modelos de Contexto
Ex: contexto de um Sistema Operacional

13. Modelo de Contexto
• Diagrama de Atividades da UML
– Modelam atividades, a ordem em que são realizadas
e dependências entre elas
• Podem também indicar entradas e saídas das
atividades
– Úteis para modelar fluxos de trabalho
– Exemplos:
• Sequência de passos da descrição de um requisito
• Processos dentro de uma empresa

14. Modelos de Contexto
Ex 1: diagrama de atividades (UML)

15. Modelos de Contexto
• Diagramas de Atividades da UML
– Início do processo (círculo preenchido)
– Fim do processo (circulo dentro de outro círculo)
– Atividades (retângulo com canto arredondado)
– Objetos (retângulos -podem representar outros
sistemas)
– Fluxo de trabalho de uma atividade para outra (setas)
– Coordenação de atividades (barra sólida)
– Atividades podem ser executas em paralelo
– Anotações podem ser incluídas nas setas

16. Modelos de Contexto
Ex 2: diagrama de atividades (UML)

17. Modelos de Interação
• Mostra as interações :
– Do usuário com o sistema
– Entre sistemas
– Entre os componentes do sistema
• Existem duas abordagens para modelar a interação:
– Diagramas de Casos de uso: mostram, principalmente, interações com atores
externos (sistemas ou usuários)
– Diagramas de Sequência: mostram interações entre os componentes do sistema
• Ambas apresentam interações em diferentes níveis de detalhamento

18. Modelos de Interação
Caso de Uso
• Amplamente usado para apoiar a elicitação de requisitos
• Representa uma tarefa discreta que envolve a interação
externa com um sistema (pode ser
hardware/software/pessoa)
• Oferece uma visão simples de uma interação
– Necessário mais detalhes para entender o que está envolvido

19. Modelos de Interação
• Fornece uma visão global e de alto nível do sistema
• Um cenário é uma determinada sequência de
ações que ilustra um comportamento do sistema
• Uma designação alternativa para cenário, por vezes
utilizada, é “fluxo de ações”

20. Modelos de Interação
• Especificar o comportamento de um caso de uso com
uma descrição textual de um ou mais fluxos de ações
• Tal especificação deve incluir:
– Como e quando o caso de uso começa e termina;
– Quando é que o caso de uso interage com os atores;
– Que objetos são trocados;
– Cenário principal e Cenários alternativos (situações de
exceção)

21. Modelos de Interação
• Caso de Uso – Exemplo 3 “Nome: Validar Usuário”
• Cenário Principal
O caso de uso inicia-se quando o sistema apresenta uma tela que pede ao cliente o seu
cartão eletrônico. O cliente introduz o seu cartão magnético e, através de um pequeno
teclado, a sua senha. Note-se que o cliente pode limpar a introdução da sua senha
inúmeras vezes e re-introduzir um novo número antes de pressionar o botão “Entrar”. O
cliente ativa o botão “Entrar” para confirmar. O sistema lê a senha e a respectiva
identificação do cartão, e verifica se é válido. Se a senha for válida o sistema aceita a
entrada e o caso de uso termina.
• Cenário Alternativo 1 (Cliente cancela operação)
O cliente pode cancelar a transação em qualquer momento ativando o botão “Cancelar”,
implicando a re-inicialização do caso de uso. Não é realizada qualquer alteração à conta
do cliente.
• Cenário Alternativo 2 (senha inválida)
Se o cliente introduz uma senha inválida o cartão MB é ejetado e o caso de uso
reinicializado. Se tal ocorrer 3 vezes consecutivas, o sistema aciona medidas de segurança
e “recolhe” o cartão e cancela a transação; não permitindo qualquer interação nos 2
minutos seguintes.

22. • Caso de Uso – Notações UML
– O diagrama de Caso de Uso é representado por:
• Atores;
• Casos de uso;
• Relacionamentos entre estes elementos.
– Estes relacionamentos podem ser:
• Associações entre atores e casos de uso;
• Generalizações entre os atores;
• Generalizações, extends e includes entre os casos de uso.
– Casos de uso podem opcionalmente estar envolvidos por
um retângulo que representa os limites do sistema.

23. • Ator
– Usuário do sistema
• Humano ou um outro sistema.
• Caso de Uso
– Função do sistema que será automatizado.

24. • Relacionamentos
– Entre um ator e um caso de uso (Associação)
• Funcionalidade do sistema na visão do usuário.
– Entre atores (Generalização)
• Os casos de uso de B são também casos de uso de A
• A tem seus próprios casos de uso

25. – Entre casos de uso
• Include
– Quando um caso de uso “A” inclui (include) outro caso
de uso “B”. Isto implica que ao executar o caso de uso
“A” executa-se também o caso de uso “B”.

26. – Extend
• Quando um caso de uso “A” tem um relacionamento do tipo
extend com outro caso de uso “B”.
• Implica que ao executar o caso de uso “A” não
necessariamente “B” será exeutado.

27. • Sistema
– Limites do sistema: representado por um retângulo envolvendo
os casos de uso que compõem o sistema.
– Nome do sistema: Localizado dentro do retângulo.

28. Exemplos de Caso de Uso - Biblioteca
• R1. Para usar os serviços de uma biblioteca, os leitores
deverão estar registrados e possuir um cartão com número
de identificação e foto.
• R2. O sistema deve permitir que um leitor faça empréstimo
de um ou mais livros, por um período de tempo que varia
de 1 semana a 6 meses, dependendo do tipo de leitor (1
semana para estudantes de graduação, 15 dias para
estudantes de pós-graduação e 6 meses para docentes).

29. • R3. O leitor está apto a emprestar livros se não possuir em
seu poder livros com data de devolução vencida e desde
que o número de livros emprestados não ultrapasse o
máximo permitido, que depende do tipo de leitor.
• R4. O sistema deve permitir que o leitor devolva um ou
mais livros em seu poder, fazendo com que o livro volte a
ficar disponível na biblioteca

30. • De acordo com esses requisitos, existem 2 casos de uso:
– Emprestar Livro
– Devolver Livro
• Um requisito pode referir-se a mais de um caso de uso.
• Um caso de uso pode referir-se a mais de um requisito.

31. • Requisitos X Casos de Uso

32. • Atores:
– Leitor
– Atendente
– Bibliotecário
• Casos de Uso:
– Emprestar livro
– Devolver livro

35. • Cenário "comprar produto”:
– O cliente navega pelo catálogo e adiciona os itens
desejados ao carrinho de compras. Quando o
cliente desejar pagar, ele preenche os dados para
entrega e da forma de pagamento, confirmando a
compra no final. O sistema verifica o cartão de
crédito, tenta passar a compra no cartão e
confirma a venda com o envio de um e-mail.

36. • Tendo em vista que a verificação do cartão pode
dar não autorizado, gerando um segundo cenário.
• Seu cliente pode ser um cliente regular, não
necessitando preencher os dados de entrega ou
mesmo do cartão, isso já seria um terceiro cenário.
• Mas repare que a essência desses três cenários é
que o usuário tem o mesmo objetivo: comprar um
produto, nem sempre o usuário consegue, mas o
objetivo permanece.

38. • Os casos de uso informar endereço e preencher
dados do cartão de crédito são extends, pois só
haverá necessidade de informá-los se o cliente for
novo, ou se ele quiser alterar uma dessas
informações.
• Os casos de uso verificar dados do cartão de
crédito e faturar compra são include, pois sempre
que for informado um novo cartão será necessário
validar esse cartão e sempre que for finalizada uma
compra, ela deve ser faturada.

39. Relacionamento entre Casos de Uso
• Existem 3 formas para tratar relacionamentos
entre casos de uso:
– Include
– Extend
– Generalization

40. • Considerando três Casos de Uso – A, B e C, vejamos cada um dos
relacionamentos.
• Include
– Se o caso A “inclui” o caso B, então sempre que 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 (A -----> B)
• Extend
– Se o caso B estende o caso de uso A, então quando A for executado o
B poderá (poderá – talvez não seja) ser executado também.
– A direção do relacionamento é do caso de uso extensor para o caso de
uso estendido: (B ------> A)

41. • Generalization
– Quando o caso de uso B generaliza o caso de uso C isso
significa que, além de fazer tudo que nele está
especificado (B), ele também executará tudo que
está especificado no caso de uso C.
– A direção do relacionamento é sempre
do generalizador (B) para o generalizado (C): B → C

42. • Ex: No diagrama temos quatro Casos de Uso, e três
relacionamentos diferentes: Include, Extend e
Generalization.
• Include:
– O caso de uso “Solicitar Material” faz include no caso
de uso “Checar Estoque”.
– Isso se dá porque sempre que houver a solicitação de
material sempre haverá a consulta ao estoque para
saber se o material está disponível.
– Se sempre haverá, o relacionamento correto é o
include.

44. • Explicando o Extend
• O caso de uso “Comprar Material” estende o caso
de uso “Solicitar Material”. Isso se dá porque
quando houver a solicitação de material, caso o
material não exista em estoque (após consulta via
o caso de uso “Checar estoque”) poderá ser
solicitado a compra do item.
• Mas também poderá não ser solicitada a compra,
pois o item pode existir em estoque. Se poderá ser
solicitada a compra (e não sempre será solicitada a
compra) o relacionamento correto é o extend.

45. Modelos de Interação
• Caso de Uso – Exemplo Generalização
“Testar Senha” e “Leitura com Smartcard” são especializam
o caso de uso “Validar usuário”

46. Modelos de Interação
• Caso de Uso – Exemplo <<include>>
Relação de delegação, significando que o caso base
incorpora o comportamento do outro caso

47. • Extend
• 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).