Aula10_Requisitos de Sistemas_Slides

Prévia do material em texto

Requisitos de Sistemas
Marcelo Vasques de Oliveira
Aula 10
Aula 10 – Casos de Uso	
Introdução a UML
Qual a utilidade e contribuição de casos de uso para a engenharia de requisitos?
A estrutura de casos de uso.
2
UML – Unified Modelling Language
Na década de 80 o paradigma orientado a objeto ganha força com linguagens de programação poderosas.
Vários profissionais desenvolveram seus modelos de análise e projeto
Com apoio financeiro da Rational, 2 e depois 3 desses profissionais uniram seus modelos e usaram o melhor de cada um, dando inicio a UML, uma Linguagem Unificada de Modelagem
3
UML – Unified Modelling Language
A UML abrange hoje, em sua versão 2.0 um conjunto de diagramas que permite ver o sistema sob diferentes perspectivas.
Não é uma metodologia, pois não orienta no sentido de estabelecer que diagramas e a ordem de uso de cada um.
Apenas disponibiliza os diagramas e cada empresa pode usa-los, dentro de suas respectivas metodologias e processos de desenvolvimento de software, sob a ótica da orientação a objeto.
4
Diagramas da UML 2.0
5
Diagrama de Casos de Uso
A visão de casos de uso é do ponto de vista externo, do usuário
Mostra, de forma simples e informal, as funcionalidades (requisitos funcionais) do sistema  mostra O QUE o sistema faz.
Ferramenta de comunicação entre equipe de desenvolvimento de usuários
Ótima ferramenta para modelagem de Requisitos (funcionais), seja na Engenharia de Requisitos ou na fase de Análise do sistema.
6
Elementos-diagrama de casos de Uso
Atores (Stickman)
O ator é algo com comportamento, que interage diretamente com o sistema. 
Um ator participa (realiza) um ou mais casos de uso do sistema
Um ator é o papel que o agente desempenha em relação ao sistema.
7
Elementos-diagrama de casos de Uso
Atores (Stickman)
Um ator pode representar setores e departamentos da empresa (contabilidade e contas a pagar), bem como funções desempenhadas na empresa (almoxarifado), 
8
Elementos-diagrama de casos de Uso
Atores (Stickman)
Um ator pode ser dispositivos eletrônicos, como por exemplo hardware, servidores ou dispositivos lógicos, como por exemplo sistemas, de acordo com a imagem abaixo.
9
Identificando Atores
O primeiro passo para a construção do modelo de casos de uso é a identificação de atores. Algumas perguntas úteis:
Quais órgãos, empresas ou pessoas farão uso deste sistema de informação?
Que sistemas ou equipamentos irão se comunicar com o sistema que será desenvolvido?
Quem deve ser informado de alguma ocorrência no sistema?
A quem pode interessar os requisitos funcionais do sistema?
10
Elementos-diagrama de casos de Uso
Casos de uso (Elipse)
Um caso de uso é um conjunto de cenários.
Um caso de uso descreve uma sequência de ações do ator e do sistema.
Cada sequência de ações é chamada de CENÁRIO.
Um cenário é uma sequência específica de ações que ilustra o comportamento do caso de uso. 
11
 
IDENTIFICANDO CASOS DE USO
1. Pensar nos casos de uso que representem os objetivos dos atores. Estes casos de uso representam os processos da empresa. Perguntas úteis:
Quais as necessidades e objetivos de cada ator em relação ao sistema?
Que informações serão produzidas pelo sistema?
O sistema realizará alguma ação que ocorre de forma regular no tempo?
Existe um caso de uso para atender cada requisito funcional?
12
Relacionamento Ator-Casos de Uso
Relacionamento entre atores e casos de uso, indicado por uma linha sólida, 
O Ator interage com o Caso de uso. 
A comunicação é bidirecional ou seja o ator informa dados ao caso de uso e recebe informações por ele processadas
13
Relacionamento entre Ator
Entre atores: relacionamento de generalização/especialização, 
Linha sólida com uma seta na extremidade que aponta pata o ator geral, 
14
O ator geral é o Funcionário e o ator especialista o Gerente. 
Relacionamento entre Atores
Útil para definir sobreposição de papéis.
15
Relacionamento entre casos de uso
INCLUSÃO (include ou uses): um caso de uso (principal) incorpora o comportamento de outro caso de uso (incluído). 
O caso de Uso incluído é parte integrante do caso de uso principal e a fatoração acontece pois outros casos de uso também poderão incorporar o Caso de Uso incluído e assim evitar repetições de fluxos. 
16
Relacionamento entre casos de uso
Validar Disciplina agrega o que é comum a Incluir Disciplina e a Eliminar Disciplina.
17
Relacionamento entre casos de uso
EXTENSÃO (extends): para descrever cenários opcionais em caso de uso, 
uma variação do comportamento normal.
Através de uma condição, o caso estendido á acionado, executado e retorna ao principal
O caso de uso estendido pode não ser executado.
18
Relacionamento entre casos de uso
19
Relacionamento entre casos de uso
20
Casos de Uso
Marcelo Vasques de Oliveira
Atividades
Exercícios
O Diagrama de caso de uso objetiva:
a. ( ) Mostrar o fluxo de informações do sistema
b. ( ) Apresentar as principais funcionalidades e as entidades externas que se relacionam com o sistema
c. ( ) Apresentar as principais funcionalidades e os atores que interage com as funcionalidades
d. ( ) Mostrar como funciona cada detalhe das funcionalidades
e. ( ) Mostrar as tecnologias envolvidas com a solução proposta
 
22
Exercícios
2)  Durante o levantamento de um sistema, um analista registrou o seguinte requisito funcional: “A função de efetivação de uma compra deverá exigir que o cliente se identifique novamente para o sistema, caso o valor da transação ultrapasse o limite de crédito definido pela gerência.” A partir desta declaração, o analista elaborou o diagrama de casos de uso UML 2.3 abaixo.
23
Exercícios
Qual deve ser o estereótipo da relação entre os casos de uso Efetiva Compra e Identifica Cliente, de modo que esse diagrama expresse o requisito funcional descrito anteriormente?
a. ( ) Include
b. ( ) Inherits
c. ( ) Implements
d. ( ) Extends
e. ( ) Overrides
24
Exercícios
3) Dentre as opções apresentas assinale aquela que não pode ser ator
a. ( ) Funcionário
b. ( ) Cliente
c. ( ) Incluir Cliente
d. ( ) Sistema Contábil
e. ( ) Servidor de banco de dados
25
Exercícios
4) No que se refere ao diagrama de casos de uso e seus elementos e a necessidade de especificarmos o passo a passo de cada caso de uso, analise as assertivas 
I. O diagrama de casos de uso objetiva apresentar os objetos que interagem com os atores do sistema.
II. Um diagrama de casos de uso é usado nas fases de levantamento e identificação dos requisitos do sistema
III. O relacionamento <include>, denota que no caso de uso principal haverá, obrigatoriamente, um desvio de curso para o caso de uso incluído.
IV. Quando o caso de uso principal esta relacionado a 3 casos de uso pelo <extends>, que serão executados após avaliação da mesma condição: significa dizer que apenas 1 desses 3 casos será usado a cada execução do caso principal.
 
26
Exercícios
Com base em sua análise das assertivas, assinale a ÚNICA opção correta.
( ) Estão corretas as assertivas I, II, III e IV
( ) Estão corretas apenas as assertivas II e IV
( ) Está correta apenas a assertiva III
( ) Está correta apenas a assertiva IV
( ) Estão corretas apenas as assertivas II, III e IV 
27
Exercícios
5) Sobre os possíveis relacionamentos entre casos de uso e entre atores, assinale a alternativa INCORRETA
a. ( ) No relacionamento Caso de uso A <include> Caso de uso B, podemos dizer que o caso de Uso B é parte do caso de uso A.
b. ( ) No relacionamento de <extends>, o caso de uso de extensão pode ou não ser executado.
c. ( ) não existe relacionamento possível entre atores, em um diagrama de casos de uso
d. ( ) No relacionamento de <include> o caso de uso de inclusão obrigatoriamente será executado.
e. ( ) O relacionamento de generalização/ especialização em casos de uso serve para aproveitar um caso já existente, adicionando alguma funcionalidade a ele, através do caso de uso especializado.
28