requisitos - SourceForge

Transcrição

Análise e Projeto OO com UML
Curso de Análise e Projeto O.O. / Prof. Fábio Bianchi
Lição 3
Especificação e Modelagem de
Requisitos com UML
Prof. Fábio Bianchi Campos
Especificação e Modelagem de Requisitos com UML
1
Objetivos Gerais
2
• Apresentar as características básicas de uma
especificação de requisitos;
• Apresentar os conceitos básicos da modelagem de
requisitos, segundo a ótica dos “Use Cases”.;
• Apresentar o que são “Use Cases” e atores de
requisitos;
• Apresentar os diagramas da UML que podem ser
utilizados na modelagem de requisitos.
Roteiro
3
• O Levantamento de Requisitos e a Modelagem de Requisitos
no Mastermodel;
• Conceitos básicos e caracterização das fases;
• Atividades das fases;
• Conceitos de Use Case e atores e UML para a fase;
• Os modelos da fase com exemplos;
• Verificações e a fase;
• Iterações e a fase;
• Referências.
Motivação
4
• Quando vamos desenvolver um sistema, precisamos
inicialmente definir “o que” o sistema irá fazer antes
de efetivamente iniciarmos o desenvolvimento;
• Precisamos entender os reais “problemas” que o
sistema irá resolver;
• Precisamos saber claramente quem são as pessoas
afetadas, direta e indiretamente pelo sistema;
• Para esclarecer os pontos acima que é criada uma
especificação de requisitos.
Requisitos
• São características desejadas, propriedades, ou
comportamentos de um sistema;
• É uma condição ou capacitação que um sistema
ou componente do sistema precisa atender ou
ter para satisfazer um contrato, especificação ou
outro documento formalmente estabelecido.
5
Levantamento de Requisitos
• O que é: é a definição das características e
propriedades desejadas para o sistema que será
elaborado;
• Objetivos: Definir claramente o que se deseja do
sistema a ser implementado;
• Quem participa: Contratantes do sistema, futuros
usuários do sistema e analistas de requisitos;
• Técnicas utilizadas: Entrevistas e questionários,
workshops de requisitos, interpretação de papéis,
prototipação e outras.
6
Localização no MasterModel
AF 1.1
AF 3.2
Diagrama de Classes
(Negócio)
Descrição do Negócio
AF 3.4
Versão: 3.0
Agosto/1999
Autor: Fábio Bianchi Campos
Diagrama de Estados
F1
F3
Descrição
do
Negócio
Modelagem
do
Negócio
AF 3.3
Diagramas de Sequência
(Negócio)
AF 7.1.2
Case
Diagramas
V1
AF 7.1.1
Código Fonte
V3
F7.1
AF 6.1
Diagramas de Processadores e
Processos
AF 5.1
(Análise)
F5
V7.1
AF 7.2.2
F6
F9
F8
F7.2
Análise
V5
Início
da
Iteração n
Projeto
da
Arquitetura
de
Implementação
Integração
e
Testes
Preliminares
Projeto dos Componentes
de Serviços / Negócios
V6
V7.2
Testes de
Carga
e
Otimizações
V9
V8
AF 7.2.1
Código Fonte
AF 4.2
Modelos de Interface
(Protótipo Visual)
F2
AF 5.2
Diagrama de Classes
(Análise)
F4
Fim
da
Iteração n
F7.3
de Dados
AF 4.3
Planilha
Requisitos
V7.3
AF 6.2
Diagrama dos Subsistemas
Levantamento
de
Requisitos
AF 6.3
Modelagem
de
Requisitos
V2
Relatório de Projeto
V4
AF 7.3.2
AF 7.3.1
Diagramas
DDLs
Este documento é parte integrante
do curso de Análise e Projeto O.O
com UML
Artefato: especificação
de requisitos
Case
Diagramas
AF 3.1
Modelos Use Cases
(Negócio)
Fase: levantamento
de requisitos
AF 9.1
Produto Final
Versão X.Y
Projeto do Componentes
Visuais
AF 2.1
Especificação dos Requisitos
do Sistema
AF 2.2n
Case
AF 4.1
Modelos Use Cases
(Requisitos)
Revisões dos Requisitos
7
MasterModel (Simplificado)
Técnicas p/ Levantamento de Requisitos
8
• Uma das técnicas p/ levantamento de requisitos é a
técnica FAST;
• Leia o Texto1.pdf (do livro Engenharia de software /
Pressman) onde existem mais informações sobre esta
técnica;
• Após ler o texto faça o exercício proposto 1.
Exercício Proposto 1
• Qual a meta principal da técnica FAST?
• Quais são as 4 listas que os participantes de um
encontro FAST são solicitados a elaborar?
9
Principais atividades do
Levantamento de Requisitos
10
• Identificação e descrição do “problema” que o sistema
pretende resolver;
• Descrição dos interessados no sistema e suas
necessidades principais;
• Descrição das características do sistema para
atendimento das necessidades dos interessados;
• Descrição dos requisitos funcionais do software;
• Descrição dos requisitos suplementares.
Exemplo: Biblioteca estudantil
11
• Para melhor entendimento dos conceitos, utilizaremos um
exemplo de um sistema “real” ao longo de todo o curso;
• Este sistema deverá informatizar algumas operações de uma
biblioteca;
• Este “caso” servirá de referência para exercícios e trabalhos
ao longo do curso, portanto é importante a máxima atenção
na compreensão do mesmo;
• Serão mostradas a seguir algumas partes importantes da
especificação, a título de exemplo.
Descrição resumida do Problema
12
• O cadastramento de obras e o controle de empréstimos são as atividades
principais de uma biblioteca. A medida que o volume de obras em uma
biblioteca aumenta e o número de usuários também, as atividades de
controle deste acervo vão se tornando intensas, dificultando a administração
da biblioteca. Os usuários também enfrentam problemas, pois têm
dificuldade em localizar as obras desejadas, tendo que muitas vezes se
deslocar até a biblioteca e descobrir que o título desejado não existe no
cadastro, ou as obras deste título estão emprestadas para outro usuário. O
tempo elevado para a execução dos procedimentos operacionais da
biblioteca tem dificultado bastante a sua administração, requerendo um
grande número de funcionários. Os tempos de atendimento dos usuários da
biblioteca têm ficado cada vez maiores, o que tem causado insistentes
protestos dos alunos e professores que utilizam a biblioteca.
Identificação dos interessados
Os operadores são os funcionários da biblioteca responsáveis pelas funções
rotineiras como empréstimo de obras, cobrança de multas, cadastramento de usuários,
cadastramento de obras, reservas e outros.
• Os usuários cadastrados podem reservar e retirar obras da biblioteca na forma de
empréstimo. São aqueles que têm os seus dados cadastrados na biblioteca, como
nome, endereço etc.
• Os administradores são os funcionários que gerenciam a biblioteca e terão acesso a
dados globais como: quantitativos de livros emprestados, índices de atraso na
devolução, índice de perdas de livros, livros mais solicitados, áreas mais solicitadas
etc. São também os administradores que definem os parâmetros configuráveis do
sistema, como limite de tempo para empréstimo, número de obras para empréstimo e
etc.
13
•
Necessidades dos interessados
• Atender rapidamente os usuários cadastrados que desejam
tomar obras emprestadas.
• Fazer um controle rápido e eficiente das multas a pagar
pelos usuários devedores.
• Controlar as reservas de títulos feitas pelos usuários de
maneira eficiente.
• Cadastrar novos usuários da biblioteca de maneira mais
flexível, facilitando a alteração de dados do usuário.
• Cadastrar novos títulos e obras de maneira eficiente.
14
Os operadores têm as seguintes necessidades básicas:
Características do sistema
–
•
•
•
•
•
•
•
•
Manter atualizado o cadastro de títulos da biblioteca.
Manter atualizado o cadastro das obras disponíveis destes títulos e o seu status.
Manter atualizado o cadastro de usuários da biblioteca.
Permitir pesquisas remotas via internet usando computadores pessoais dos
usuários.
Pesquisas locais (na biblioteca) a partir de computadores da biblioteca.
Controlar o empréstimo de obras.
Permitir reservas via internet ou locais para os usuários cadastrados.
Manter o controle das multas dos usuários.
Gerar estatísticas de uso da biblioteca.
15
As principais características do sistema são:
Requisitos de software
• O usuário cadastrado quando verificar que não há disponibilidade de
obra do título desejado poderá fazer uma reserva para o mesmo. Esta
reserva poderá ser feita tanto em terminais locais da biblioteca como
via internet, pelo próprio usuário, ou poderá ser feita pelo operador,
por solicitação do usuário. A reserva de títulos exige que o usuário ou
o operador esteja previamente “logados” no sistema. Deve-se informar
ao sistema o código do usuário que deseja fazer a reserva e
posteriormente o código do título desejado, caso não haja nenhuma
restrição ao usuário ou ao título, o mesmo será reservado.
16
Reservar Título:
Texto complementar 2
17
• Leia o texto do arquivo Texto2.pdf (do livro
managing software requirements - Dean Leffingwell)
e responda as questões a seguir, sobre Requisitos de
software.
Exercício proposto 2
• Qual a importância para os desenvolvedores em
transformar as “características do sistema” em
“Requisitos de Software”?
18
• De acordo com o autor, quais são as cinco categorias
de requisitos que tornam os requisitos de software
satisfatórios?
Especificação completa
19
• Uma versão completa da especificação de requisitos
da biblioteca se encontra no arquivo
espreq50_01.pdf, que pertence à lição número 3;
• Faça uma leitura rápida deste documento para ter um
noção do conteúdo de uma especificação;
• Este documento é o artefato produzido na fase
levantamento de requisitos;
• Este documento será utilizado muitas outras vezes ao
longo do curso, portanto é importante ter o mesmo
sempre disponível nas aulas.
• Qual item da especificação de requisitos
(espereq50_01) você considera mais importante?
• Explique sua escolha.
20
Observações finais sobre requisitos
21
• O requisitos devem ser definidos de maneira
conservadora, isto é, deve-se centrar nas reais
necessidades, e não em coisas que seriam
interessantes, mas que não são realmente necessárias;
• A Especificação de requisitos pode sofrer várias
modificações no decorrer do sistema, estas
modificações devem ser documentadas e
controladas;
• A especificação de requisitos é puramente textual,
portanto independente da UML.
Detalhamento dos requisitos
22
• Após o levantamento dos requisitos e elaboração da
especificação, os requisitos de software devem ser
detalhados para facilitar a análise e projeto;
• O detalhamento destes requisitos será feito na fase
modelagem de requisitos;
• A técnica utilizada para a modelagem de requisitos
será a dos “Use Cases”.
Modelagem de requisitos
23
• O que é: Detalhamento dos requisitos funcionais definidos na
especificação de requisitos; A criação de modelos gráficos
representativos do que se deseja do sistema de informação a ser
implementado
• Objetivos: Permitir uma estruturação preliminar do sistema de
informação que se quer desenvolver, do ponto de vista de quem
utilizará o sistema;
• Quem participa: Contratantes do sistema, futuros usuários do sistema
e analistas de requisitos;
• Característica:Abstração quanto a detalhes internos do sistema de
informação, dando mais importância ao ponto de vista externo do
sistema.
• Técnica utilizada: Use Cases
Localização no MasterModel
AF 1.1
AF 3.2
Diagrama de Classes
(Negócio)
Descrição do Negócio
AF 3.4
Versão: 3.0
Agosto/1999
Autor: Fábio Bianchi Campos
Diagrama de Estados
F1
F3
Descrição
do
Negócio
Modelagem
do
Negócio
AF 3.3
(Negócio)
AF 7.1.2
Case
Diagramas
V1
AF 7.1.1
Código Fonte
V3
F7.1
AF 6.1
Diagramas de Processadores e
Processos
AF 5.1
(Análise)
F5
V7.1
AF 7.2.2
F6
Case
Diagramas
AF 3.1
Modelos Use Cases
(Negócio)
F9
F8
F7.2
Análise
V5
Início
da
Iteração n
Projeto
da
Arquitetura
de
Implementação
Integração
e
Testes
Preliminares
de Serviços / Negócios
V6
V7.2
Testes de
Carga
e
Otimizações
V9
V8
AF 7.2.1
Código Fonte
AF 4.2
Modelos de Interface
(Protótipo Visual)
Artefatos:
F2
AF 5.2
Diagrama de Classes
(Análise)
F4
Fim
da
Iteração n
F7.3
de Dados
AF 4.3
Planilha
Requisitos
V7.3
AF 6.2
Diagrama dos Subsistemas
Levantamento
de
Requisitos
AF 6.3
Modelagem
de
Requisitos
V2
Fase:modelagem de
requisitos
AF 9.1
Produto Final
Versão X.Y
Projeto do Componentes
Visuais
Relatório de Projeto
V4
AF 7.3.2
AF 7.3.1
Diagramas
DDLs
Este documento é parte integrante
do curso de Análise e Projeto O.O
com UML
AF 2.1
Especificação dos Requisitos
do Sistema
AF 2.2n
Case
AF 4.1
Modelos Use Cases
(Requisitos)
Revisões dos Requisitos
24
MasterModel (Simplificado)
Modelagem de Requisitos
25
• A modelagem de requisitos é a representação em
forma gráfica (Use Case Model), textual(Descrições)
e visual(Interfaces) dos requisitos do sistema que se
deseja implementar;
• O foco é a modelagem dos requisitos funcionais do
sistema.
Motivações para modelagem de requisitos
26
• Gerar um conjunto de diagramas e interfaces que
facilitem a definição dos requisitos;
• A partir dos diagramas facilitar a comunicação entre
analistas e contratante, tornando a captura de
requisitos mais eficiente;
• Servir como base para a implementação de sistemas
de informação, que irão realizar os requisitos
modelados.
Modelo de Requisitos
27
• Capturar os requisitos a partir de uma perspectiva do
usuário;
• Como um potencial usuário irá utilizar o sistema;
• Participação ativa dos usuários no acompanhamento
do desenvolvimento do modelo;
• Onde toda a funcionalidade do sistema é
especificada.
• Pesquise no MasterModel (entregue na lição 2) e
responda as questões a seguir:
• Qual artefato deve ser produzido antes da
modelagem de requisitos?
• Que artefatos são produzidos na Modelagem de
requisitos?
28
Atividades da Modelagem de Requisitos
Definição dos candidatos a Use Cases e Atores;
Elaborar diagrama preliminar com Use Cases e Atores;
Descrição resumida dos atores, e descrição dos Use Cases
Refinar o diagrama de Use Cases inicialmente elaborado;
Elaborar protótipos visuais equivalentes aos Use Cases;
Verificação geral dos diagramas.
29
•
•
•
•
•
•
Conceitos fundamentais
da Modelagem de Requisitos
• Use Cases;
• Atores.
30
Definição de Atores
Aquilo que existe fora do sistema;
Os atores representam aquilo que interage com o sistema;
Tudo que troca informações com o sistema;
O Atores são usuários desempenhando papéis específicos;
Um usuário pode desempenhar vários papéis;
Atores interagem com os “use cases”.
31
•
•
•
•
•
•
• Que diferentes papéis os funcionários da biblioteca
poderiam desempenhar?
32
• Que diferentes papéis um mesmo funcionário de uma
lanchonete tipo Mac Donalds poderia desempenhar
em um dia de trabalho?
Definição de Use Cases
33
• Quando um usuário utiliza o sistema, o mesmo irá conduzir
uma sequência de transações (na forma de diálogos) com o
sistema;
• A cada conjunto de transações com um objetivo específico
chama-se de um “use case”;
• Cada “use case” representa uma maneira específica de se
utilizar o sistema;
• Quando um usuário (no papel de um ator) gerar um estímulo
inicial para o “use case” o mesmo irá iniciar a sequência de
transações.
Exemplos de Use Cases (Banco)
• Terminal bancário:
–
–
–
–
–
Checar saldo;
fazer saque;
Tirar extrato;
Depositar cheques;
.....
34
Use Case segundo a UML
35
• Um “use case” é uma unidade coerente de funcionalidade,
provida por um sistema, manifestada por uma sequência de
mensagens trocadas entre o sistema e um ou mais elementos
de interação externo (atores), com ações executadas pelo
sistema;
• Um “use case” é a descrição de uma sequência de ações,
incluindo as variações, que um sistema executa para atingir
um resultado observável por um ator.
Definição original da UML
An actor defines a coherent set of roles that users of an entity can play
when interacting with the entity. An actor has one role for each use
case it communicates with.
36
A use case is a coherent unit of functionality provided by a system, a
subsystem, or a class as manifested by sequences of messages
exchanged among the system and one or more outside interactors
(called actors) together with actions performed by the system.
Atores segundo a UML
37
• Um ator é um objeto (ou objetos) fora do sistema
desempenhando papéis, que interagem diretamente com o
sistema como parte de uma unidade coerente que é o “use
case”;
• Um objeto pode desempenhar vários papéis sendo então
modelado por diversos atores;
• Pode ser representado por um retângulo com <<actor>> e o
nome do ator dentro do retângulo,
• Também podem ser representados pelo “homenzinho” (stick
man).
Diagrama de Use Cases e Atores
use case 2
ator 1
use case 1
use case 3
ator 2
38
fronteira do sistema
Identificação preliminar de atores (1)
Exemplo da biblioteca
• Os objetos externos que interagem com o sistema
(biblioteca):
–
–
–
–
–
Qualquer pessoa;
Usuários cadastrados;
Operadores;
Administradores;
Suporte.
39
Identificação preliminar de Use Cases (1)
Exemplo da biblioteca
– Qualquer pessoa:
• Pesquisar a existência de títulos;
– Usuários cadastrados:
• Pesquisar e Reservar obras;
– Operadores:
• Reservar e Emprestar obras;
• Cadastrar usuários; Receber obra, Receber multa...
– Administradores:
• Cadastrar funcionários e acesso a relatórios administrativos e
acesso total.
40
• Identificar as funcionalidades acessíveis a cada grupo de
objetos externos:
Candidatos a atores, papéis (2)
41
• Atendente (Faz empréstimo, reserva, recebe retorno,
- só pode ser funcionário-operador);
• Cadastrador (Faz cadastro de usuários, títulos e
obras - só pode ser funcionário-operador ) ;
• ......
Atores secundários
– Papéis executados pelos “objetos” como o administrador e
pessoal de suporte, irão executar atividades internas como
mudar valor da multa diária, alterar cotas de empréstimo,
etc...;
42
• Participam de “use cases” que não são fundamentais
do ponto de vista dos “usuários” do sistema;
• Exemplo:
Candidatos a Use Cases (2)
–
–
–
–
–
–
–
Pesquisar a existência de uma obra;
Reservar título;
Emprestar Obra;
Devolver obra;
Pagar multa;
Cadastrar calouro;
...............
43
• Conjuntos de transações com um objetivo específico:
Diagrama preliminar dos Use Cases
Cadastrar Obra
Cadastrador
Cadastrar Usuário
Emprestar de Obra
Devolver Obra
atendente
UMLib
44
Descrição detalhada do Use Case
•
•
•
•
•
•
•
•
•
Nome:
Atores que interagem:
Ator que inicia:
Pré-condições:
Dados consumidos e produzidos:
Resumo do curso principal:
Sub-fluxos:
Alternativas:
Requisitos especiais:
45
Resumo curso principal
– Um usuário cadastrado após ter escolhido a obra que deseja levar como
empréstimo, e estando de posse da mesma, solicitará ao funcionário (atendente)
que efetive o empréstimo desta. O atendente solicita ao usuário o seu código no
sistema, e preenche (em um formulário na tela do seu computador de
atendimento) o campo respectivo com o código do mesmo. Depois solicitará
ao usuário que digite a sua senha no “keypad” .Posteriormente verifica na
obra selecionada pelo usuário o número de tombo da mesmas entrando este
número no campo apropriado. Finalmente pressiona o botão para efetivar o
empréstimo. Caso o usuário esteja habilitado ao empréstimo das obras
solicitadas, o sistema dará uma mensagem de sucesso. O atendente então
carimbará as obras liberando as mesmas para o usuário.
46
• “use case” Emprestar obra (curso principal):
47
• Com base na especificação de requisitos fornecida
(espereq50_01.pdf) e no exemplo
(UseCaseEmpObra.pdf) tente fazer um detalhamento
semelhante para o Use Case Reservar título.
Associações entre Use Cases
48
• Comunicação - relação entre um ator e um “use
case”;
• Extends - quando a funcionalidade embutida em um
“use case” é uma opção de extensão da
funcionalidade de um outro “use case”;
• Include - indica que a funcionalidade de um “use
case” está incluída no outro, no curso principal.
Trabalho de pesquisa p/ casa
49
• Pesquise na norma UML e no livro texto do curso, as
relações Extend e Include entre Use Cases. Faça um
resumo do significado de cada uma, cite em que
casos devem ser usadas e dê exemplos.
• Este trabalho deve ser feito até o dia 30/8 e enviado
por e-mail para [email protected] colocando na linha
de assunto APSIIturmaTP1_matricula. Exemplo de
linha de assunto APSIINKATP1_98123456. Colocar
no corpo do trabalho o nome, matrícula e turma.
Protótipo das Interfaces
50
• Servem como complemento aos “use cases”;
• Pode ser utilizada a técnica de prototipação, para se
mostrar ao usuário uma sequência de telas ao se
“executar” um “use case”.
Formulário Principal Emprestar Obra
51
revisão das atividades
Definição dos canditados a Use Cases e Atores;
Elaborar diagrama preliminar com Use Cases e Atores;
Descrição resumida dos atores, e descrição dos Use Cases
Refinar o diagrama de Use Cases inicialmente elaborado;
Elaborar protótipos visuais equivalentes aos Use Cases;
Verificação geral dos diagramas.
52
•
•
•
•
•
•
Verificações e inspeções
53
• Verificar coerência entre os modelos gerados e
especificação de requisitos;
• Verificar coerência entre os use cases e as interfaces.
Iterações
54
• Na primeira iteração devem ser identificados e
modelados os use cases mais significativos dos
requisitos, Ex: EmprestarObra, ReservarTitulo,
DevolverObra, CadastrarTitulo, CadastrarObra e
CadastrarUsuario,.......
• Deve-se também tentar nas primeiras iterações
identificar os use cases que tenham maior interação
com os atores, que envolvam maiores riscos e que
venham a ter maiores impactos na arquitetura.
55
• No exemplo da biblioteca, qual Use Case você acha
que teria um maior impacto na arquitetura da
solução? Explique sua escolha.
Prática de laboratório
56
• Após estudar no tutorial da ferramenta Rose como
criar um Use Case, um ator e um diagrama de use
cases, criar (utilizando a versão 4.0 da ferramenta do
laboratório) um diagrama de use cases da biblioteca
(como o da transparência 44) com pelo menos 8 Use
Cases da biblioteca. Descrever o resumo do fluxo
principal de pelo menos 3 Use Cases.
• Obs: nesta fase não deve ser utilizada versão mais
recente da ferramenta.
Observações Finais
57
• Os use cases conduzem todo o desenvolvimento, o
que permite uma coerência entre os modelos gerados
nas diversas fases, pois todos estarão centrados em
refinar os use cases. Outras metodologias (ou
processos) não têm esta abordagem, tentam
identificar todos os objetos, suas relações e
posteriormente fazer algum tipo de modularização.
Referências
58
• Jacobson, Ivar; Booch, Grady; Rumbaugh, James. The
Unified Software Development Process. Addison-Wesley
Longman, Inc, 1999.
• Kruchten, Philippe. The Rational Unified Process - An
Introduction. Addisson Wesley Longman Inc, 1999.
• Unified Modeling Language - Notation Guide - V. 1.3 R9
January 1999. OMG.

requisitos - SourceForge

Transcrição

Documentos relacionados

Formulário Testes de corte PT

IND 2443 - Prática em Modelagem Matemática

D-Lab Meeting 2012

VISLUMBRE

processo seletivo público n° 02/2000

FUNCTIONAL CONSULTANT Se és perspicaz na compreensão de

Modelagem para Tomada de Decisão Financeira - CEFET-MG

RESULT HABILIT CN

Sistema de Capacitação em Modelagem e Simulação Dinâmica

Slides