Aula 7 - Modelagem de Software

Slides da disciplina de Engenharia de Software

1. Modelagem de Software
Leinylson Fontinele Pereira
Engenharia de Software

2. 2
Modelagemde 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. Modelagemde Software
•Modelos são abstraçõesdo sistema, e não uma
representaçãoalternativa 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. Modelagemde 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. Modelagemde 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. Modelagemde 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. Modelagemde 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. Modelagemde Software
•A UML (UnifiedModelingLanguage) é 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. Modelagemde 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. Modelagemde 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ênciade 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çãode 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ênciade
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,extendseincludesentre os casos de uso.
–Casos de usopodem 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 umcaso de uso (Associação)
•Funcionalidade do sistema na visão do usuário.
–Entre atores (Generalização)
•Oscasos de usode Bsão tambémcasos de usode A
•Atem seus próprioscasos de uso

25. –Entrecasos 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
extendcom 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
oscasos de usoque 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ãopode
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çoe preencher
dados do cartão de créditosãoextends, 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éditoe faturar comprasã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 ocasoA“inclui” o caso B,então sempreque Afor executado o caso
de usoBtambém será executado.
–A direção do relacionamento é do caso de uso que estáincluindopara
o caso de usoincluído (A -----> B)
•Extend
–Se o caso Bestende o caso de usoA, então quando Afor executado o
Bpoderá(poderá –talvez não seja) ser executado também.
–A direção do relacionamento é do caso de usoextensorpara o caso de
usoestendido: (B ------> A)

41. •Generalization
–Quando o caso de usoBgeneraliza o caso de usoCisso
significa que, além de fazer tudo que nele está
especificado (B), eletambém executará tudo que
estáespecificadono caso de usoC.
–A direção do relacionamento é sempre
dogeneralizador(B) para ogeneralizado(C): B →C

42. •Ex: No diagrama temos quatro Casos de Uso,e três
relacionamentos diferentes: Include, Extende
Generalization.
•Include:
–Ocaso de uso “Solicitar Material” faz include no caso
de uso “Checar Estoque”.
–Isso se dá porquesempreque houver a solicitação de
materialsemprehaverá 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. Sepoderáser
solicitada a compra (e nãosempreserá 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 usoBestende o caso de usoA, significa que
quando o caso de usoAfor executado o caso de
usoBpoderá(poderá –talvez não seja) ser executado também. A
direção do relacionamento é do caso de usoextensor(aqui o caso
de uso B) para o caso de usoestendido(aqui o caso de uso A).