04/07/2015 UML. Prof. Esp. Fabiano Taguchi DEFINIÇÃO DE REQUSIITOS

Transcrição

1 UML Prof. Esp. Fabiano Taguchi DEFINIÇÃO DE REQUSIITOS 1

2 REQUISITOS São os serviços fornecidos para um sistema. São classificados em requisitos funcionais e não funcionais. FUNCIONAIS = Descrevem as funcionalidade e serviços NÃO FUNCIONAIS = Definem propriedades e restrições REQUISITOS FUNCIONAIS Estes requisitos documentam como o sistema deve reagir a entradas específicas e como devem se comportar: Exemplos: Todo usuário poderá fazer consultas em um banco de dados; Cada nota fiscal deverá possuir um código; Sistema deve notificar o requisitante por quando a requisição estiver disponível para retirada. 2

3 REQUISITOS NÃO FUNCIONAIS Mapeiam aspectos qualitativos de um software: performance, segurança, perspectiva do usuário, comunicação e usabilidade. Exemplos: A interface do usuário deverá sem escrito em HTML simples; Todos os documentos devem segui o padrão de nome XYZ-00; O tempo de resposta de uma requisição deve ser de 0,2 segundos. ETAPAS DA ENGENHARIA DE REQUISITOS Quatro são as fases: 1. Estudo de viabilidade; 2. Elicitação de requisitos; 3. Especificação de requisitos 4. Validação de requisitos 3

4 ESPECIFICAÇÃO DOS REQUISITOS Construir o documento com os requisitos identificados. EXERCÍCIOS DE APRENDIZAGEM 4

5 EXERCÍCIOS DE APRENDIZAGEM UML 5

6 ORIENTAÇÃO A OBJETO Abstração Classes Objetos Atributos Métodos Método construtor Herança Polimorfismo Sobrecarga Encapsulamento Interface MODELAGEM O que é modelagem? Por que precisamos usar modelos? 6

7 HISTÓRICO A UML surgiu entre os anos de 1998 e Consiste em uma linguagem visual para especificação de sistemas orientados a objetos, independente da linguagem de programação a ser usada. Dados (Estrutural) Operações (Funcional) Eventos (Temporal) HISTÓRICO Em seu início notações diferentes eram usados para descrever projetos orientados a objetos, a UML acabou por se tornar a integração dessas várias notações. É uma linguagem não proprietária; Não é uma metodologia de desenvolvimento. 7

8 FERRAMENTAS Existe uma gama de ferramentas muito grande para modelagem a partir da UML, dentre as mais conhecidas: Rational Rose; Enterprise Architect; Astah; StarUML; ArgoUML. OBJETIVO DA UML Modelar sistemas usando os conceitos de orientação a objetos; Ajudar a equipe de projeto a visualizar um sistema como ele pretende ser; Auxiliar a especificar a estrutura e o comportamento do sistema ao passar do tempo; Proporcionar um modelo que sirva de guia para a construção do sistema. 8

9 CONCEITOS UML Dois conceitos iniciais são importantes : DIAGRAMA: É uma visão de um modelo. MODELO: É a descrição completa de um sistema em uma determinada perspectiva. ESTRUTURAÇÃO UML 13 DIAGRAMAS DIAGRAMAS ESTRUTURAIS Diagrama de classes, objetos e pacotes; Diagrama de implantação, componentes e estruturação composta. DIAGRAMAS COMPORTAMENTAIS Casos de uso e diagrama de atividades; Diagrama de máquinas de estado. DIAGRAMAS DE INTERAÇÃO Diagramas de sequência, comunicação, tempo e visão geral da interatividade. 9

10 SUGESTÕES PARA SISTEMAS EXERCÍCIO Em duplas, liste 10 requisitos funcionais e 10 requisitos não funcionais para um projeto de software, como sugestão: Posto de combustível; Venda de passagens; Pizzaria; Escola de idiomas; Padaria. 10

11 DEFINIÇÃO DO SISTEMA POSTO DE COMBUSTÍVEL O caso em questão será o desenvolvimento de um sistema para controle de pagamentos de abastecimento em um posto de combustível localizado no centro da cidade. Este sistema deverá armazenar todas as informações necessárias para que se possa fazer a venda de combustível ao cliente. DEFINIÇÃO DO SISTEMA VENDA DE PASSAGENS O sistema para venda de passagens atenderá uma empresa de transportes em específico, este sistema tem como objetivo fazer a venda e reservas de passagens rodoviárias. 11

12 DEFINIÇÃO DO SISTEMA PIZZARIA Uma pizzaria da cidade vai começar a trabalhar com tele entregas, para isso necessita de um sistema para controle de pedidos. O objetivo do sistema é gerenciar os pedidos de pizza e repassar ao setor de produção. DEFINIÇÃO DO SISTEMA ESCOLA DE IDIOMAS Uma escola de idiomas foi criada por dois amigos, e precisar de um sistema para matricular os alunos. O objetivo deste sistema é que se faça o cadastro e matrícula dos alunos. 12

13 DEFINIÇÃO DO SISTEMA PADARIA Para uma padaria, o sistema a ser desenvolvido será instalado apenas no caixa da padaria, ou seja, o objetivo principal deste sistema é fazer a gestão da cobrança das comandas. DIAGRAMAS CASOS DE USO 13

14 CASOS DE USO Este diagrama é responsável por modelar o comportamento do sistema devido a interação com algum ator produzindo um resultado que pode ser observado. A construção de um sistema é guiado pelos casos de uso. Um caso de uso indica uma funcionalidade que o sistema deve oferecer DIAGRAMA CASOS DE USO Em geral, um sistema possui apenas um diagrama de casos de uso, mas em determinada situações pode ser necessária a decomposição dos diagramas em módulos, devido a complexidade do sistema. 14

15 CASOS DE USO Os casos de são representados por elipses, com um texto que descreve sua funcionalidade. Essa descrição geralmente é um verbo. IDENTIFICANDO CASOS DE USO Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos. 15

16 ATOR Em um diagrama casos de uso, o ator são todos os usuários, hardware e sistemas externos que irão de alguma forma interagir com os casos de uso. Um ator não faz parte do sistema, apenas interage. Sua simbologia é: IDENTIFICANDO ATORES Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos. 16

17 RELACIONAMENTOS Descrição que indica como atores e casos de uso irão se relacionar. Essas relações podem ser: Atores e casos de uso; Dois ou mais atores; Dois ou mais casos de uso. RELACIONAMENTO - ASSOCIAÇÃO O relacionamento ator e caso de uso demostra que o ator utiliza a função do sistema representado pelo caso de uso, seja: requisitando a execução da função ou recebendo o resultado produzido pela função. 17

18 IDENTIFICANDO ASSOCIAÇÃO Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda de discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda de discos. RELACIONAMENTO ENTRE ATORES Os relacionamento entre atores quando ocorrem são do tipo de comunicação ou generalização. Um relacionamento de comunicação se refere a uma troca de mensagens entre os atores. 18

19 RELACIONAMENTO - GENERALIZAÇÃO Este relacionamento indica que um ator é um caso especial de um outro ator mais genérico. Exemplo: Gerente é um funcionário Analista também é um funcionário Funcionário é uma generalização Analista e gerente é uma especialização. RELACIONAMENTO - GENERALIZAÇÃO A generalização também é aplicada a casos de uso. No exemplo, a validação do uso pode ser: através de uma senha ou do escaneamento de retina. 19

20 IDENTIFICADO GENERALIZAÇÃO As vendas podem ser à vista ou a prazo. Em ambos os casos o estoque é atualizado e uma nota fiscal, entregue ao consumidor. Em venda à vista, clientes cadastrados que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro. Em venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo de 20%. Podem ser pagas no cartão ou no boleto. Em pagamento no boleto, são gerados boletos bancários que são entregues ao cliente e armazenados no sistema para lançamento. Pagamento no cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras a vista. IDENTIFICANDO GENERALIZAÇÃO 20

21 RELACIONAMENTO - EXTENSÃO Uma extensão permite que pontos opcionais no fluxo de eventos de um diagrama. RELACIONAMENTO - EXTENSÃO 21

22 IDENTIFICANDO EXTENSÃO No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro. No caso de uma venda a prazo. Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras à vista. IDENTIFICANDO EXTENSÃO 22

23 RELACIONAMENTO - INCLUSÃO Evita que um mesmo fluxo de eventos seja repetido por diversas vezes. Como exemplo podemos citar um sistema que controla pedidos de um usuário, para que este pedido seja executado o usuário deve ter sido validado antes. RELACIONAMENTO - INCLUSÃO 23

24 IDENTIFICANDO INCLUSÃO Para efetuar vendas ou administrar estoque, atendentes e gerentes terão que validar suas respectivas senhas de acesso ao sistema. FRONTEIRAS DO SISTEMA Uma fronteira de um sistema é um elemento opcional, que serve para delimitar a área de atuação. 24

25 DOCUMENTAÇÃO DE UM CASO DE USO DOCUMENTAÇÃO Não existe um padrão para documentação. Em geral, as formas mais usadas são: Descrição passo a passo (Informal); Tabelas; Pseudocódigo; Fluxograma; Cenários (Típica). 25

26 ANATOMIA DE UM CASO DE USO Descrição Pré-condição Fluxo Básico Fluxo Alternativo 1 Fluxo Alternativo n Pós-condição CENÁRIO 26

27 CENÁRIO OUTRO EXEMPLO Descrição: Saque de dinheiro em um caixa eletrônico. Pré condição: Cliente identificado corretamente. Fluxo básico: 1. O Cliente informa a opção de Saque. 2. O Sistema solicita o valor do saque. 3. O Cliente informa o valor e confirma a operação. 4. O Sistema verifica o valor informado. 5. O Sistema verifica o saldo do cliente.[a1] 6. O Sistema debita o valor sacado do saldo do cliente.[a2] 7. O Sistema entrega o dinheiro. 8. Fim do caso de uso. CENÁRIO OUTRO EXEMPLO Fluxo alternativo: A1 VALOR INFORMADO INVÁLIDO 1. No passo 4 do fluxo básico o sistema verificou que o valor informado é inválido. 2. O sistema informa que o valor é inválido. 3. O sistema informa as regras para valores válidos. 4. O caso de uso volta para o passo 2 do fluxo básico. Fluxo alternativo: A2 SALDO INSUFICIENTE 1. No passo 5 do fluxo básico o Sistema verificou que o cliente não possui saldo. 2. O Sistema informa o saldo disponível. 3. O caso de uso volta para o passo 8 do fluxo básico. Pós condição: Cartão devolvido ao cliente 27

28 EXEMPLOS EMPRÉSTIMOS DE EXEMPLARES 28

29 SISTEMA ACADÊMICO SISTEMA ACADÊMICO 29