SlideShare uma empresa Scribd logo
UML
Requisitos, Casos de Uso e
Diagrama de Atividades no
Rational Rose
Baseado nos slides de Roberto Costa & Rodrigo Lumack
Tiago Vinícius
tvrc@cin.ufpe.br
Gleibson Rodrigo “dartanham”
grso@cin.ufpe.br
Roteiro
• Requisitos
– Funcionais
– Não-funcionais
• Problemas
• Possíveis Soluções
• UML
• Diagrama de Casos de Uso
• Diagrama de Atividades
• Diagramas de Caso de Uso no Rose
• Diagramas de Atividades no Rose
Requisitos
• Funcionais
– Descrevem as funcionalidades que se espera que o
sistema disponibilize, de uma forma completa e
consistente.
– Relacionados a Entradas, Funções, Saídas, Atores.
• Não-funcionais
– Referem-se às restrições nas quais o sistema deve
operar ou propriedades emergentes do sistema
(como viabilidade ou tempos de resposta).
– Tipos
• Produto (Eficiência, Portabilidade, Segurança, etc.);
• Organizacionais (Padrões, Entrega, etc.);
• Externos (Aspectos Éticos, Legais, etc.).
Problemas
• Grande parte dos problemas de um
projeto decorre de:
– Falta / Ineficiente compreensão dos
requisitos;
– Pouco / Inexistente feedback do cliente;
– Requisitos mal especificados.
Possíveis soluções
• Feedback
– Contar sempre com o cliente próximo na hora de
especificar/validar um requisito.
• Casos de Uso
– Descrição e/ou Diagrama UML.
• Prototipação
– Ferramentas RAD (Rapid Application Development );
– Paper Prototype – rápida e feedback imediato.
UML
A Unified Modeling Language (UML) é uma
linguagem de modelagem não proprietária de
terceira geração¹. A UML não é um método de
desenvolvimento mas ele lhe auxilia a visualizar
seu desenho e a comunicação entre objetos.
Basicamente, a UML permite que
desenvolvedores visualizem os produtos de seu
trabalho em diagramas padronizados
1 - projetada para ser facilmente entendida
Porque adotar UML?
• Padrão
– Academia, Indústria, etc.
• Notação Gráfica
– Facilita a comunicação
• Equipe-Clientes;
• Equipe-Equipe.
• Suporte de Ferramentas
– Rational Rose, Visio, Poseidon, ArgoUML.
Requisitos
Gerar nota de restituição
Identificação: Nome:
RF 018 Gerar nota de restituição
Descrição:
O usuário pode gerar uma nota que será enviada via correios
para contribuintes que tenham direito a restituição. Na nota
deve constar o endereço do imóvel correspondente e os dados
do proprietário, além de informar os passos para realizar a
solicitação de restituição do valor informado, juntamente com o
valor a ser restituído.
Usuários: DPLAN e ROOT
Essencial ▓ Importante Desejável
Caso de Uso
Identificaç
ão
Nome Status
UC 18 Gerar nota de restituição Validado
Referênci
as
RF 018
Autor Glerter Alcântara
Criado em 23/08/2006 Revisado
em
Atores:
Usuários DPLAN ou usuários ROOT
Entradas:
Seqüencial do imóvel (referente ao Corpo de Bombeiros).
Pré-condições:
1. O servidor deve estar funcionando corretamente
Fluxo de eventos:
1. O usuário escolhe a opção “gerenciar pagamento” na tela principal do
sistema;
2. Em seguida escolhe a opção “gerar nota de restituição”;
3. Na tela seguinte, preenche o campo “seqüencial do imóvel” e confirma a
operação clicando em “enviar”;
4. O sistema busca na base de dados informações referentes ao imóvel com
seqüencial igual ao passado como parâmetro;
5. O sistema mostra na tela uma nota de restituição, com as informações do
imóvel e do proprietário, o valor a ser restituído, a data atual e uma
seqüência de passos a serem seguidos para efetivar a restituição.
6. O usuário é capaz de imprimir essa nota de restituição clicando em “imprimir”
(opção que irá aparecer abaixo das informações da nota de restituição).
FS 01 - Fluxo Secundário 1: Campo “seqüencial do imóvel” em branco
1. O sistema mostra uma mensagem na tela informando a obrigatoriedade do
preenchimento do campo;
2. O sistema retorna para a tela “verificar pagamento”.
FS 02 – Fluxo Secundário 2: Seqüencial inválido
1. O sistema mostra uma mensagem na tela informando que o seqüencial
passado como parâmetro pelo usuário está num formato inválido ou possui
caracteres inválidos;
2. O formulário é re-exibido com todas as informações já fornecidas.
FS 03 – Fluxo Secundário 3: Imóvel não encontrado
1. O sistema mostra uma mensagem na tela informando que não foi encontrado
nenhum imóvel com o seqüencial passado pelo usuário;
2. O sistema retorna para a tela “verificar pagamento”.
FS 04 – Fluxo Secundário 4: Cancelamento da busca/verificação
1. O usuário pode cancelar a operação de busca/verificação;
2. O sistema retorna para a tela “gerenciar pagamento”;
Saídas e pós condições:
O sistema exibe na tela a situação do imóvel referido nos últimos cinco anos.
Diagrama de caso de uso
O Diagrama de Caso de Uso descreve a
funcionalidade proposta para o novo sistema. Um
Caso de Uso representa uma unidade discreta da
interação entre um usuário (humano ou máquina)
e o sistema.
– Capturar o comportamento;
– Particiona o sistema em funcionalidades;
– Elementos
• Atores
• Casos de Uso
• Relacionamentos
Diagrama de caso de uso
• Caso de uso
– Na Engenharia de Software, um caso de uso (ou use case)
é um tipo de classificador representando uma unidade
funcional coerente provida pelo sistema.
gerarRelatório
Os casos de uso foram propostos inicialmente por Ivar Jacobson
em sua metodologia de desenvolvimento de sistemas orientados a
objetos OOSE. Posteriormente foi incorporado à UML tornando seu
uso uma prática frequente na identificação de requisitos de um
sistema.
Diagrama de caso de uso
• Ator(es)
– Tipicamente, um ator representa um papel que um ser
humano, um dispositivo de hardware ou até outro sistema
desempenha com o sistema.
MatricularAluno
Diagrama de caso de uso
• Relações:
– Entre atores
– Entre casos de uso
MatricularAluno
Diagrama de caso de uso
– Entre casos de Uso
• Include, Extend, Generalization.
Diagrama de atividades
• O Diagrama de atividade é um diagrama definido
pela Linguagem de Modelagem Unificada(UML), e
representa os fluxos conduzidos por processamentos.
É essencialmente um gráfico de fluxo, mostrando o
fluxo de controle de uma atividade para outra.
Exemplo de Caso de uso
• Realizar um saque no caixa eletrônico
Identificação UC_01
Função Retirar Dinheiro do caixa eletrônico
Atores Cliente, Caixa eletrônico
Prioridade Essencial
Pré-condição Cliente precisa ter em mãos o cartão do
banco
Pós-condição Dinheiro sacado com sucesso
Fluxo
Principal
•Cliente insere cartão no dispositivo
Cliente digita a senha
Máquina autoriza login [FS001]
Cliente digita o montante
Máquina checa o saldo [FS002]
Máquina debita o dinheiro sacado do
saldo inicial
Máquina dispõe cédulas para cliente
Máquina mostra na tela no novo saldo
Máquina ejeta cartão
Cliente retira cartão
Fluxo
Secundário
[FS001]
Senha digitada é inválida
Máquina ejeta cartão
Cliente retira cartão
Fluxo
Secundário
[FS002]
Saldo é menor que o
montante requerido
Máquina mostra na tela o
saldo
Máquina ejeta o cartão
Cliente retira o cartão
Exemplo de Diagrama de Fluxo
Usando o Rational Rose
• Start -> All Programs ->
Rational Suite Enterprise ->
Rational Rose Enterprise Edition
Usando o Rational Rose
Exemplo
• Um sistema de Banco:
• O cliente poderá:
– Sacar, Depositar, Transferir e Tirar Extrato;
• Para cada operação o cliente deve se autenticar;
• Qualquer funcionário poderá:
– Tirar Extrato do cliente;
– Solicitar Cartão de crédito para cliente;
• O Gerente pode fazer qualquer operação dos
funcionários;
• Somente o Gerente pode cadastrar ou
descadastrar conta;
Resposta
Sacar
Depositar
Transferir
Tirar Extrato
Autenticar
Cadastrar Conta
Descadastrar Conta
Solicitar Cartão
Tirar Estrato do
cliente
Autenticação
Inválida
<<include>>
<<Include>>
<<include>>
<<include>>
<<extends>>
Tarefa 1
• Um sistema de controle de hospital
– A atendente pode acionar a emergência
• Existem dois tipos de emergência: cardíaca e pulmonar.
– A atendente pode cadastrar, procurar e atualizar uma
emergência.
– O gerente pode fazer tudo que a atendente faz.
– O gerente pode remover uma emergência
– Para cada tarefa, o usuário (qualquer que seja) deve
se autenticar no sistema.
Resposta 1
Procurar
Cadastrar
Atualizar
Remover
Emergência
Emergência
Cardíaca
Emergência
Pulmonar
Autenticar
Autenticação
Inválida
UML
Requisitos, Casos de Uso e
Diagrama de Atividades no
Rational Rose
Tiago Vinícius
tvrc@cin.ufpe.br
Baseado nos slides de Roberto Costa & Rodrigo Lumack
Gleibson Rodrigo “dartanham”
grso@cin.ufpe.br
Dúvidas?!

Mais conteúdo relacionado

Semelhante a Requisitos monitoria

REA- Diagramas de Casos de Uso da UML
REA- Diagramas de Casos de Uso da UMLREA- Diagramas de Casos de Uso da UML
REA- Diagramas de Casos de Uso da UML
IFFar - SVS
 
Aps caso uso
Aps caso usoAps caso uso
I managerimplementado(1)
I managerimplementado(1)I managerimplementado(1)
I managerimplementado(1)
geanbt
 
UMLAulaI.pdf
UMLAulaI.pdfUMLAulaI.pdf
Aula6 diagrama casos de uso
Aula6 diagrama casos de usoAula6 diagrama casos de uso
Aula6 diagrama casos de uso
Computação Depressão
 
Aula3 casos de uso
Aula3 casos de usoAula3 casos de uso
Aula3 casos de uso
Diana Adamatti
 
Plano de projeto final
Plano de projeto finalPlano de projeto final
Plano de projeto final
Leo Paixão
 
4 casos-de-uso
4 casos-de-uso4 casos-de-uso
4 casos-de-uso
sou estudante
 
Plano de projeto final
Plano de projeto finalPlano de projeto final
Plano de projeto final
Leo Paixão
 
Dicas diagrama de casos de uso
Dicas diagrama de casos de usoDicas diagrama de casos de uso
Dicas diagrama de casos de uso
Rita Almeida
 
Trabalho OO clinica veterinária
Trabalho OO clinica veterináriaTrabalho OO clinica veterinária
Trabalho OO clinica veterinária
Valdir Junior
 
cap6.pdf
cap6.pdfcap6.pdf
Fundamentos de Sistemas de Informacao - Aula 14
Fundamentos de Sistemas de Informacao - Aula 14Fundamentos de Sistemas de Informacao - Aula 14
Fundamentos de Sistemas de Informacao - Aula 14
Ismar Silveira
 
Aula 04 - Diagrama de casos de uso
Aula 04 - Diagrama de casos de usoAula 04 - Diagrama de casos de uso
Aula 04 - Diagrama de casos de uso
Leinylson Fontinele
 
Tcc
TccTcc
casos de uso
casos de usocasos de uso
casos de uso
Márcia Rodrigues
 
Es 02 desenvolvimento de software dirigido por casos de uso - parte i
Es 02   desenvolvimento de software dirigido por casos de uso - parte iEs 02   desenvolvimento de software dirigido por casos de uso - parte i
Es 02 desenvolvimento de software dirigido por casos de uso - parte i
Rodrigo Gomes da Silva
 
Plano de teste sigcal
Plano de teste sigcalPlano de teste sigcal
Plano de teste sigcal
cadeirudo
 
Fluxo de Requisitos (RUP).pdf
Fluxo de Requisitos (RUP).pdfFluxo de Requisitos (RUP).pdf
Fluxo de Requisitos (RUP).pdf
mmarolla1
 
Trabalho OO Sistema de Advocacia
Trabalho OO Sistema de AdvocaciaTrabalho OO Sistema de Advocacia
Trabalho OO Sistema de Advocacia
Valdir Junior
 

Semelhante a Requisitos monitoria (20)

REA- Diagramas de Casos de Uso da UML
REA- Diagramas de Casos de Uso da UMLREA- Diagramas de Casos de Uso da UML
REA- Diagramas de Casos de Uso da UML
 
Aps caso uso
Aps caso usoAps caso uso
Aps caso uso
 
I managerimplementado(1)
I managerimplementado(1)I managerimplementado(1)
I managerimplementado(1)
 
UMLAulaI.pdf
UMLAulaI.pdfUMLAulaI.pdf
UMLAulaI.pdf
 
Aula6 diagrama casos de uso
Aula6 diagrama casos de usoAula6 diagrama casos de uso
Aula6 diagrama casos de uso
 
Aula3 casos de uso
Aula3 casos de usoAula3 casos de uso
Aula3 casos de uso
 
Plano de projeto final
Plano de projeto finalPlano de projeto final
Plano de projeto final
 
4 casos-de-uso
4 casos-de-uso4 casos-de-uso
4 casos-de-uso
 
Plano de projeto final
Plano de projeto finalPlano de projeto final
Plano de projeto final
 
Dicas diagrama de casos de uso
Dicas diagrama de casos de usoDicas diagrama de casos de uso
Dicas diagrama de casos de uso
 
Trabalho OO clinica veterinária
Trabalho OO clinica veterináriaTrabalho OO clinica veterinária
Trabalho OO clinica veterinária
 
cap6.pdf
cap6.pdfcap6.pdf
cap6.pdf
 
Fundamentos de Sistemas de Informacao - Aula 14
Fundamentos de Sistemas de Informacao - Aula 14Fundamentos de Sistemas de Informacao - Aula 14
Fundamentos de Sistemas de Informacao - Aula 14
 
Aula 04 - Diagrama de casos de uso
Aula 04 - Diagrama de casos de usoAula 04 - Diagrama de casos de uso
Aula 04 - Diagrama de casos de uso
 
Tcc
TccTcc
Tcc
 
casos de uso
casos de usocasos de uso
casos de uso
 
Es 02 desenvolvimento de software dirigido por casos de uso - parte i
Es 02   desenvolvimento de software dirigido por casos de uso - parte iEs 02   desenvolvimento de software dirigido por casos de uso - parte i
Es 02 desenvolvimento de software dirigido por casos de uso - parte i
 
Plano de teste sigcal
Plano de teste sigcalPlano de teste sigcal
Plano de teste sigcal
 
Fluxo de Requisitos (RUP).pdf
Fluxo de Requisitos (RUP).pdfFluxo de Requisitos (RUP).pdf
Fluxo de Requisitos (RUP).pdf
 
Trabalho OO Sistema de Advocacia
Trabalho OO Sistema de AdvocaciaTrabalho OO Sistema de Advocacia
Trabalho OO Sistema de Advocacia
 

Requisitos monitoria

  • 1. UML Requisitos, Casos de Uso e Diagrama de Atividades no Rational Rose Baseado nos slides de Roberto Costa & Rodrigo Lumack Tiago Vinícius tvrc@cin.ufpe.br Gleibson Rodrigo “dartanham” grso@cin.ufpe.br
  • 2. Roteiro • Requisitos – Funcionais – Não-funcionais • Problemas • Possíveis Soluções • UML • Diagrama de Casos de Uso • Diagrama de Atividades • Diagramas de Caso de Uso no Rose • Diagramas de Atividades no Rose
  • 3. Requisitos • Funcionais – Descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. – Relacionados a Entradas, Funções, Saídas, Atores. • Não-funcionais – Referem-se às restrições nas quais o sistema deve operar ou propriedades emergentes do sistema (como viabilidade ou tempos de resposta). – Tipos • Produto (Eficiência, Portabilidade, Segurança, etc.); • Organizacionais (Padrões, Entrega, etc.); • Externos (Aspectos Éticos, Legais, etc.).
  • 4. Problemas • Grande parte dos problemas de um projeto decorre de: – Falta / Ineficiente compreensão dos requisitos; – Pouco / Inexistente feedback do cliente; – Requisitos mal especificados.
  • 5. Possíveis soluções • Feedback – Contar sempre com o cliente próximo na hora de especificar/validar um requisito. • Casos de Uso – Descrição e/ou Diagrama UML. • Prototipação – Ferramentas RAD (Rapid Application Development ); – Paper Prototype – rápida e feedback imediato.
  • 6. UML A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira geração¹. A UML não é um método de desenvolvimento mas ele lhe auxilia a visualizar seu desenho e a comunicação entre objetos. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados 1 - projetada para ser facilmente entendida
  • 7. Porque adotar UML? • Padrão – Academia, Indústria, etc. • Notação Gráfica – Facilita a comunicação • Equipe-Clientes; • Equipe-Equipe. • Suporte de Ferramentas – Rational Rose, Visio, Poseidon, ArgoUML.
  • 8. Requisitos Gerar nota de restituição Identificação: Nome: RF 018 Gerar nota de restituição Descrição: O usuário pode gerar uma nota que será enviada via correios para contribuintes que tenham direito a restituição. Na nota deve constar o endereço do imóvel correspondente e os dados do proprietário, além de informar os passos para realizar a solicitação de restituição do valor informado, juntamente com o valor a ser restituído. Usuários: DPLAN e ROOT Essencial ▓ Importante Desejável
  • 9. Caso de Uso Identificaç ão Nome Status UC 18 Gerar nota de restituição Validado Referênci as RF 018 Autor Glerter Alcântara Criado em 23/08/2006 Revisado em Atores: Usuários DPLAN ou usuários ROOT Entradas: Seqüencial do imóvel (referente ao Corpo de Bombeiros). Pré-condições: 1. O servidor deve estar funcionando corretamente Fluxo de eventos: 1. O usuário escolhe a opção “gerenciar pagamento” na tela principal do sistema; 2. Em seguida escolhe a opção “gerar nota de restituição”; 3. Na tela seguinte, preenche o campo “seqüencial do imóvel” e confirma a operação clicando em “enviar”; 4. O sistema busca na base de dados informações referentes ao imóvel com seqüencial igual ao passado como parâmetro; 5. O sistema mostra na tela uma nota de restituição, com as informações do imóvel e do proprietário, o valor a ser restituído, a data atual e uma seqüência de passos a serem seguidos para efetivar a restituição. 6. O usuário é capaz de imprimir essa nota de restituição clicando em “imprimir” (opção que irá aparecer abaixo das informações da nota de restituição). FS 01 - Fluxo Secundário 1: Campo “seqüencial do imóvel” em branco 1. O sistema mostra uma mensagem na tela informando a obrigatoriedade do preenchimento do campo; 2. O sistema retorna para a tela “verificar pagamento”. FS 02 – Fluxo Secundário 2: Seqüencial inválido 1. O sistema mostra uma mensagem na tela informando que o seqüencial passado como parâmetro pelo usuário está num formato inválido ou possui caracteres inválidos; 2. O formulário é re-exibido com todas as informações já fornecidas. FS 03 – Fluxo Secundário 3: Imóvel não encontrado 1. O sistema mostra uma mensagem na tela informando que não foi encontrado nenhum imóvel com o seqüencial passado pelo usuário; 2. O sistema retorna para a tela “verificar pagamento”. FS 04 – Fluxo Secundário 4: Cancelamento da busca/verificação 1. O usuário pode cancelar a operação de busca/verificação; 2. O sistema retorna para a tela “gerenciar pagamento”; Saídas e pós condições: O sistema exibe na tela a situação do imóvel referido nos últimos cinco anos.
  • 10. Diagrama de caso de uso O Diagrama de Caso de Uso descreve a funcionalidade proposta para o novo sistema. Um Caso de Uso representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema. – Capturar o comportamento; – Particiona o sistema em funcionalidades; – Elementos • Atores • Casos de Uso • Relacionamentos
  • 11. Diagrama de caso de uso • Caso de uso – Na Engenharia de Software, um caso de uso (ou use case) é um tipo de classificador representando uma unidade funcional coerente provida pelo sistema. gerarRelatório Os casos de uso foram propostos inicialmente por Ivar Jacobson em sua metodologia de desenvolvimento de sistemas orientados a objetos OOSE. Posteriormente foi incorporado à UML tornando seu uso uma prática frequente na identificação de requisitos de um sistema.
  • 12. Diagrama de caso de uso • Ator(es) – Tipicamente, um ator representa um papel que um ser humano, um dispositivo de hardware ou até outro sistema desempenha com o sistema. MatricularAluno
  • 13. Diagrama de caso de uso • Relações: – Entre atores – Entre casos de uso MatricularAluno
  • 14. Diagrama de caso de uso – Entre casos de Uso • Include, Extend, Generalization.
  • 15. Diagrama de atividades • O Diagrama de atividade é um diagrama definido pela Linguagem de Modelagem Unificada(UML), e representa os fluxos conduzidos por processamentos. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra.
  • 16. Exemplo de Caso de uso • Realizar um saque no caixa eletrônico Identificação UC_01 Função Retirar Dinheiro do caixa eletrônico Atores Cliente, Caixa eletrônico Prioridade Essencial Pré-condição Cliente precisa ter em mãos o cartão do banco Pós-condição Dinheiro sacado com sucesso Fluxo Principal •Cliente insere cartão no dispositivo Cliente digita a senha Máquina autoriza login [FS001] Cliente digita o montante Máquina checa o saldo [FS002] Máquina debita o dinheiro sacado do saldo inicial Máquina dispõe cédulas para cliente Máquina mostra na tela no novo saldo Máquina ejeta cartão Cliente retira cartão Fluxo Secundário [FS001] Senha digitada é inválida Máquina ejeta cartão Cliente retira cartão Fluxo Secundário [FS002] Saldo é menor que o montante requerido Máquina mostra na tela o saldo Máquina ejeta o cartão Cliente retira o cartão
  • 18. Usando o Rational Rose • Start -> All Programs -> Rational Suite Enterprise -> Rational Rose Enterprise Edition
  • 20. Exemplo • Um sistema de Banco: • O cliente poderá: – Sacar, Depositar, Transferir e Tirar Extrato; • Para cada operação o cliente deve se autenticar; • Qualquer funcionário poderá: – Tirar Extrato do cliente; – Solicitar Cartão de crédito para cliente; • O Gerente pode fazer qualquer operação dos funcionários; • Somente o Gerente pode cadastrar ou descadastrar conta;
  • 21. Resposta Sacar Depositar Transferir Tirar Extrato Autenticar Cadastrar Conta Descadastrar Conta Solicitar Cartão Tirar Estrato do cliente Autenticação Inválida <<include>> <<Include>> <<include>> <<include>> <<extends>>
  • 22. Tarefa 1 • Um sistema de controle de hospital – A atendente pode acionar a emergência • Existem dois tipos de emergência: cardíaca e pulmonar. – A atendente pode cadastrar, procurar e atualizar uma emergência. – O gerente pode fazer tudo que a atendente faz. – O gerente pode remover uma emergência – Para cada tarefa, o usuário (qualquer que seja) deve se autenticar no sistema.
  • 24. UML Requisitos, Casos de Uso e Diagrama de Atividades no Rational Rose Tiago Vinícius tvrc@cin.ufpe.br Baseado nos slides de Roberto Costa & Rodrigo Lumack Gleibson Rodrigo “dartanham” grso@cin.ufpe.br Dúvidas?!