Treinamento UML

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Treinamento
UML – Análise de Requisitos
Introdução
UML
Na área de Engenharia de Software, a Linguagem de Modelagem Unificada (do inglês, UML - Unified Modeling Language) é uma linguagem de modelagem que permite representar um sistema de forma padronizada.
A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre os objetos.
Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma notação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML.
 	
Introdução
Engenharia de Requisitos
A engenharia de requisitos é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo.
O processo de engenharia de requisitos é composto por quatro atividades de alto nível:
Identificação e levantamento;
Análise e negociação;
Especificação e documentação (UML);
Validação.
 	
Levantamento de Requisitos
Levantamento de requisitos:
•	Conhecer o problema e alternativas para solução.
•	Exemplo de como não deve acontecer...
“Eu vou subir e ver o que eles querem o resto de vocês comecem a codificar.”
Habilidades de um analista:
•	Compreende conceitos abstratos.
•	Capacidade de sintetizar “soluções”.
•	Visualizar fatos em fontes conflitantes ou confusas.
•	Entender o ambiente do usuário.
•	Boa comunicação verbal e escrita.
 	
Especificação de Requisitos
ESPECIFICAÇÃO DE REQUISITOS:
•	Descrição do fluxo e estrutura da informação
•	Refinamento detalhado de todas as funções
•	Estabelecimento das características das interfaces.
•	Foco em “o que” o sistema deverá contemplar, não em “como”.
•	Detalhamento das restrições.(funcionais ou não funcionais)
•	Especificação dos critérios de validação.
•	Validação dos requisitos com o cliente.
 	
Produção de Artefatos de Requisitos
A cada fase do ciclo de vida do software produzimos um documento contendo uma representação distinta do software a ser construído. Cada um desses documentos representa o software em um determinado nível de abstração. A tendência é diminuirmos o nível de abstração através da inclusão de mais e mais detalhes, até que, sua última representação seja o código fonte na linguagem escolhida.
Artefatos:
Requisitos
Descrição dos Casos de Uso
Diagrama de Caso de Uso
Diagrama de Classe
Diagrama de Atividade*
Diagrama de Sequencia*
 	
Requisitos
A especificação de requisitos tem como objetivo obter produtos de software de melhor qualidade que satisfaçam às reais necessidades dos clientes dentro de prazo e orçamento adequados.
Podemos entender requisito como uma função, restrição ou propriedade que deve ser fornecida, encontrada ou atendida para satisfazer às necessidades do usuário do sistema. (Descreve um serviço ou uma limitação)
Por serem atividades bases do processo de desenvolvimento de software as falhas cometidas nas atividades de definição e validação de requisitos irão originar documentos de requisitos inconsistentes afetando as etapas seguintes de projeto , implementação e testes e gerando produtos de softwares de baixa qualidade.
Embora não exista um modelo padrão consagrado para gerenciar requisitos podemos definir alguns passos para um processo de especificação de requisitos :(Soares, 2005) (Os processos devem ser adaptados a cada necessidade/conjuntura)
 	
Requisitos
Mas o que é especificar um requisito ?
Especificar um requisito implica em compreender exatamente o que deve ser feito e que se espera receber como resultado.
Podemos classificar os requisitos em :
Funcionais - descrevem as funcionalidades do sistema desejadas pelos clientes ou seja O QUE se espera que o software faça;
Não funcionais - São as qualidades e restrições globais do sistema relacionados com manutenção , uso, desempenho, custo , interface, etc...
Exemplos de requisitos funcionais:
“O sistema deve possibilitar o cadastramento dos dados pessoais dos clientes;”
“O sistema deve emitir relatórios gerenciais;”
“O sistema deve permitir a baixa automática do estoque quando da venda de um produto;”
 	
Requisitos
Um requisito funcional deve ser:
1. Viável – pode ser realizado dada as restrições de recursos, orçamento, conhecimento, cronograma e tecnologia disponível para o projeto
2. Válido – é um requisito que o sistema “deve” atender, sendo revisado pelo solicitante do produto a ser desenvolvido. Deve-se diferenciar dos requisitos “desejáveis” , os quais acarretam custos sem agregar valor e podem atrasar a entrega do projeto
3. Inequívoco – requisitos devem ter uma interpretação única, sem ambiguidades: exemplos:
–o sistema de dados deve resistir a uma catástrofe (incêndio e ou inundação?)
–o relógio deve ser a prova d’agua (a qual profundidade?)
Requisitos ambíguos trazem como consequências atrasos no projeto e aumento de custos
 	
Requisitos
4. Verificável – ocorre quando o produto final pode ser testado para garantir que ele atende aos requisitos especificados. Exemplos: a) o carro deve ter freios (verificável); b) o carro deve parar completamente a 60 Km por hora em 5 segundos (inequívoco e verificável)
7. Completo – todos os requisitos corretos e relevantes estão presentes e há informação suficiente para a construção do produto. Completude implica em:
–respostas esperadas do sistema para as diversas variáveis de entrada (entradas válidas e inválidas)
–descrição completa de figuras, tabelas e diagramas, bem como glossário de termos e unidade de medidas
–quantificação dos requisitos não funcionais: critérios testáveis devem ser definidos para todos requisitos não funcionais
 	
Requisitos
Requisitos Não-Funcionais:
A Norma ISO / IEC 9126 define seis características de qualidade de software que devem ser avaliadas:
Funcionalidade (finalidade do produto);
Usabilidade (esforço para utilizar, aprender o produto);
Confiabilidade (freqüência de falhas, recuperabilidade);
Eficiência (característica relacionada ao desempenho);
Manutenibilidade (esforço necessário para modificar);
Portabilidade (capacidade de transferir o produto para outros ambientes).
Exemplos de requisitos não funcionais:
Tempo de resposta do sistema não deve ultrapassar 10 segundos;
Software deve ser operacionalizado no sistema Windows;
O banco de dados usado deverá ser o Oracle;
Obs: "Os requisitos não funcionais são críticos para o sucesso de sistemas de software e estão diretamente relacionados com a satisfação dos usuários. Devido a essa importância, alguns requisitos funcionais podem ser sacrificados para atender às restrições impostas pelos requisitos não funcionais"
 	
Casos de Uso
Os requisitos podem ser modelados e validados através de casos de uso que incluem o diagrama de casos de uso e a especificação do caso de uso.
Um caso de uso representa uma funcionalidade completa, conforme percebida pelo ator e é definido como "um conjunto de seqüências de ações que um sistema executa que produzem um resultado observável por um particular ator".
O Diagrama de Casos de Uso fornece um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível da funcionalidade do sistema mediante uma requisição do usuário.
 	
Casos de Uso
O modelo de casos de uso é um formato ágil para capturar requisitos de software. Ele contrasta com documentos maiores e descritivos que tentam conter todos os requerimentos possíveis antes do início da construção de um novo sistema, mas falham completamente neste intento. Os principais benefícios
dos casos de uso na modelagem de requisitos são:
os casos de uso podem ser facilmente adicionados ao projeto de software e removidos do projeto de software assim que as prioridades mudarem;
os casos de uso podem também servir como base para estimar, escalonar e validar esforços;
uma razão porque os casos de uso se tornaram populares: são fáceis de entender por pessoas da área de negócio e assim provaram ser uma excelente ponte entre quem desenvolve o software e os utilizadores finais.
Os casos de uso também têm as suas dificuldades. São excelentes para capturar os requisitos funcionais de um sistema, mas não têm tanto sucesso em capturar os não funcionais.
 	
Casos de Uso
É importante notar que os modelos de casos de uso não descrevem como o software deverá ser construído, e sim, como ele deverá se comportar. As descrições de casos de uso normalmente evitam o uso de termos técnicos, preferindo a linguagem do usuário final. Normalmente, os casos de uso são feitos por quem desenvolve o software e/ou por quem vai utilizar esse mesmo software.
Propósitos básicos:
decidir e descrever os requisitos funcionais do sistema;
prover uma descrição clara e consistente do que o sistema deve fazer;
prover a base para a realização de testes que validam e verificam o sistema;
prover facilidades para rastrear requisitos funcionais dentro das classes e operações do sistema.
 	
Casos de Uso
Principais Componentes do Modelo de Casos de Uso:
Caso de uso: especifica uma funcionalidade completa do sistema. É sempre iniciado por um ator (direta ou indiretamente ordena ao sistema a execução de um caso de uso);
Ator: entidade externa que interage com os casos de uso;
Sistema: conjunto de casos de uso
A seguir temos a sequência que pode ser usada para construir o modelo de casos de uso:
Definir o sistema (conjunto de casos de uso);
encontrar os atores;
encontrar e descrever os casos de uso;
definir os relacionamentos entre os casos de uso;
validar o modelo.
 	
Casos de Uso
Como identificar um ator ?
As respostas às seguintes perguntas podem auxiliar na identificação dos atores:
Quem utiliza a principal funcionalidade do sistema?
Quem vai precisar de suporte do sistema para realizar suas tarefas diárias?
Quem precisa manter, administrar e deixar o sistema "rodando"?
Quais dispositivos de hardware o sistema precisa manipular?
Com quais outros sistemas o sistema precisa interagir?
Quem ou o quê tem interesse nos resultados produzidos pelo sistema?
Casos de Uso
Como identificar um caso de uso ?
As respostas às perguntas abaixo podem auxiliar a identificar os Casos de Uso:
Quais funções o ator requer do sistema? O que o ator precisa fazer?
Ator precisa criar, ler, destruir, modificar ou armazenar algum tipo de informação dentro do sistema?
Ator precisa ser notificado de eventos do sistema? O ator precisa notificar o sistema sobre algum evento?
Trabalho diário do ator poderia ser simplificado ou tornado mais eficiente por meio de novas funcionalidades do sistema?
Quais entradas e saídas o sistema precisa?
Quais os principais problemas com o atual sistema?
Casos de Uso
Detalhando cada caso de uso:
Comece detalhando o cenário principal. À medida que fizer isso, você poderá identificar vários fluxos alternativos e de erro que o caso de uso pode seguir e então avaliá-los, rearranjá-los, eliminá-los e prioriza-los antes de detalhar dos cenários sobreviventes, então você poderá focar seus esforços no lugar certo.
Detalhe o fluxo básico de eventos (cenário principal):
Como ponto de partida, use a descrição passo-a-passo do cenário principal que você criou, então, adicione detalhes a esse cenário gradualmente, descrevendo o que o caso de uso faz, e não como, para resolver os problemas internos ao sistema.
Uma descrição de fluxo de eventos cobre:
Como e quando o caso de uso se inicia
Quando o caso de uso interage com os Atores, e quais dados eles trocam
Quando o caso de uso usa dados armazenados no sistema ou armazena dados no sistema
Como e quando o caso de uso termina
Casos de Uso
Descreva o fluxo de eventos do cenário principal da seguinte forma:
O caso de uso inicia quando o <Nome do ator> <faz algo>.
O sistema <faz algo em resposta>.
O <Nome do ator> <faz algo a mais>.
Casos de Uso
Exemplo:
Caso de uso primário
Atores: Cliente
Pré-condição: O usuário deve ter feito "log-in" e obtido autorização do sistema
Fluxo de Eventos (caminho básico):
O caso de uso começa quando o cliente seleciona "fazer pedido".
O cliente fornece seu nome e endereço.
Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e o estado.
O cliente fornece os códigos do produto. (veja alternativa)
O sistema devolve as descrições e o preço de cada produto. (Ponto de extensão - Produto em Oferta)
O sistema calculará os valores totais para cada produto fornecido. (Ponto de extensão - Cliente Especial)
O cliente fornece as informações sobre cartão de crédito.
O cliente submete os dados ao sistema.
O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade e pagamento.
Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente.
Casos de Uso
Detalhe os fluxos alternativos
Um caso de uso é formado por um conjunto de cenários, cada um representando instâncias específicas do caso de uso que correspondem a entradas específicas do Ator ou condições específicas do ambiente. Cada cenário descreve formas alternativas de comportamento do sistema, ou pode descrever falhas ou casos de exceção.
Revise a lista de fluxos alternativos que você capturou à medida que você detalha o cenário principal, você pode identificar fluxos alternativos adicionais fazendo as seguintes perguntas:
Existem opções diferentes, dependendo da entrada do Ator? (Por exemplo, se o Ator entrar uma senha inválida enquanto usa um caixa eletrônico)
Que regras de negócio podem estar em jogo? (Por exemplo: O Ator requisita ao caixa eletrônico mais dinheiro do que está disponível na sua conta).
O que poderia dar errado? (Por exemplo: Não há conexão de rede disponível quando é necessária uma transação).
Casos de Uso
Detalhe os fluxos alternativos
Inicie identificando-os.
Examine cada cenário possível para determinar se ele é relevante, se pode realmente acontecer e se é distinto dos outros cenários.
Elimine cenários redundantes ou desnecessários.
Priorize os cenários restantes e comece a elaborar os mais importantes.
Além de detalhar o fluxo de eventos de cada fluxo alternativo na forma descrita acima, cada fluxo alternativo deve descrever:
Onde pode ser inserido o fluxo alternativo no fluxo básico de eventos.
A condição que deve ser atendida para que o comportamento alternativo inicie.
Como e onde o fluxo básico de eventos continua, ou como o caso de uso termina.
Casos de Uso
Exemplo:
Fazer Pedido – Fluxo Alternativo
Atores: Cliente
Pré-condição: O usuário deve ter feito "log-in" e obtido autorização do sistema
O caso de uso começa quando o cliente seleciona "fazer pedido".
O cliente fornece seu nome e endereço.
Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e o estado.
Enquanto o cliente quiser pedir itens faça
 	O cliente fornece código do produto
 	O sistema fornece as descrição e preço do produto
 	O sistema atualiza o valor total
O cliente fornece as informações sobre cartão de crédito.
O cliente submete os dados ao sistema.
O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade e pagamento.
Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente.
Casos de Uso
Descreva as pré-condições e pós-condições
Uma pré-condição de um caso de uso descreve
o estado em que o sistema deve estar para que o caso de uso possa iniciar. Tome cuidado ao descrever o estado do sistema. Evite descrever detalhes de atividades incidentais que já podem ter acontecido.
Uma pós-condição de um caso de uso lista os possíveis estados que o sistema pode ficar ao término da execução do caso de uso. O sistema deve estar em um desses estados. Uma pós-condição também declara as ações que o sistema executa ao fim do caso de uso, independente do que ocorreu no caso de uso. 
As pós-condições podem ser categorizadas como Garantias Mínimas ou Garantias de Sucesso:
As Garantias Mínimas representam as condições que serão verdadeiras quando o caso de uso terminar, independente de como ele terminar.
As Garantias de Sucesso representam as condições que serão verdadeiras quando o caso de uso terminar com sucesso, independente de qual caminho ele seguiu.
Casos de Uso - Diagramação
Na UML o modelo de casos de uso consiste de diagramas de casos de uso que mostram os atores , os casos de uso e seus relacionamentos. Os elementos gráficos que representam atores, casos de uso e sistema são mostrados abaixo:
 	
O nome de um caso de uso pode ser qualquer sentença, mas a UML recomenda usar uma frase ativa curta (verbo + substantivo), por exemplo: "comprar itens'', "efetuar venda", ... (indicando uma ação)
Os elementos principais do diagrama são uma elipse para representar um caso de uso e um pequeno boneco para representar um ator.
Casos de Uso - Diagramação
Os relacionamentos possíveis são :
1- Inclusão : Se um caso de uso inicia ou inclui o comportamento de outro , dizemos que ele usa o outro.
Ex: No caso de uso Comprar Item se o pagamento for feito com dinheiro podemos ter a inclusão PagarComDinheiro
O relacionamento de inclusão em UML é ilustrado com uma linha de generalização com o rótulo <<include>>.
Então para o exemplo do cliente com o use case Solicitar Pedidos de peças teríamos:
As propriedades básicas da inclusão são :
realizar um decomposição funcional
reduzir a complexidade de um caso de uso
O caso de uso básico não pode executar sem a inclusão.
Comportamento comum
Casos de Uso - Diagramação
2- Extensão - Define pontos de extensão que adicionam comportamento a um caso de uso base descrevendo uma variação do comportamento normal. O caso de uso base pode ser executado mesmo sem a extensão.
Ex: O caso de uso Comprar Produto pode apresentar a extensão Compra por um Cliente Regular. Abaixo temos o diagrama UML
Casos de Uso - Diagramação
3- Generalização - Indica um caso de base que possui diferentes especializações e inclui comportamento ou sobrescreve o caso de uso base.
O caso de uso Pagar fatura apresenta as generalizações : Pagamento com cartão e Pagamento com Cheque , conforme o diagrama Abaixo: