04/07/2015
1
UML
Prof. Esp. Fabiano Taguchihttp://fabianotaguchi.wordpress.com
DEFINIÇÃO DE REQUSIITOS
04/07/2015
2
REQUISITOS
São os serviços fornecidos para um sistema. Sãoclassificados em requisitos funcionais e não funcionais.
� FUNCIONAISFUNCIONAISFUNCIONAISFUNCIONAIS = Descrevem as funcionalidade e serviços
� NÃONÃONÃONÃO FUNCIONAISFUNCIONAISFUNCIONAISFUNCIONAIS = Definem propriedades e restrições
REQUISITOS FUNCIONAIS
Estes requisitos documentam como o sistema deve reagir aentradas específicas e como devem se comportarcomportarcomportarcomportar:
ExemplosExemplosExemplosExemplos::::
� 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 e-mail quando arequisição estiver disponível para retirada.
04/07/2015
3
REQUISITOS NÃO FUNCIONAIS
Mapeiam aspectosaspectosaspectosaspectos qualitativosqualitativosqualitativosqualitativos de um software:performance, segurança, perspectiva do usuário, comunicação eusabilidade.
Exemplos:Exemplos:Exemplos: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,2segundos.
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
04/07/2015
4
ESPECIFICAÇÃO DOS REQUISITOS
Construir o documento com os requisitos identificados.Construir o documento com os requisitos identificados.Construir o documento com os requisitos identificados.Construir o documento com os requisitos identificados.
EXERCÍCIOS DE APRENDIZAGEM
04/07/2015
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?O que é modelagem?O que é modelagem?O que é modelagem?
Por que precisamos usar modelos?Por que precisamos usar modelos?Por que precisamos usar modelos?Por que precisamos usar modelos?
04/07/2015
7
HISTÓRICO
A UML surgiu entre os anos de 1998 e 2000.
Consiste em uma linguagemlinguagemlinguagemlinguagem visualvisualvisualvisual para especificaçãoespecificaçãoespecificaçãoespecificação dedededesistemassistemassistemassistemas orientadosorientadosorientadosorientados aaaa objetosobjetosobjetosobjetos, independente da linguagem deprogramação a ser usada.
� Dados (Estrutural)
�Operações (Funcional)
� Eventos (Temporal)
HISTÓRICO
Em seu início notações diferentes eram usados paradescrever projetos orientados a objetos, a UML acabou por setornar a integração dessas várias notações.
� É uma linguagem não proprietária;
� Não é uma metodologia de desenvolvimento.
04/07/2015
8
FERRAMENTAS
Existe uma gama de ferramentas muito grande paramodelagem a partir da UML, dentre as mais conhecidas:
� Rational Rose;
� Enterprise Architect;
� Astah;
� StarUML;
� ArgoUML.
OBJETIVO DA UML
� Modelar sistemas usando os conceitosconceitosconceitosconceitos dededede orientaçãoorientaçãoorientaçãoorientação aaaa objetosobjetosobjetosobjetos;
� Ajudar a equipe de projeto a visualizarvisualizarvisualizarvisualizar umumumum sistemasistemasistemasistema comocomocomocomo eleeleeleelepretendepretendepretendepretende serserserser;
� Auxiliar a especificarespecificarespecificarespecificar aaaa estruturaestruturaestruturaestrutura eeee oooo comportamentocomportamentocomportamentocomportamento dodododo sistemasistemasistemasistemaao passar do tempo;
� Proporcionar um modelo que sirva de guiaguiaguiaguia paraparaparapara aaaa construçãoconstruçãoconstruçãoconstruçãododododo sistemasistemasistemasistema.
04/07/2015
9
CONCEITOS UML
Dois conceitos iniciais são importantes :
� DIAGRAMADIAGRAMADIAGRAMADIAGRAMA: É uma visão de um modelo.
� MODELOMODELOMODELOMODELO: É a descrição completa de um sistema em umadeterminada perspectiva.
ESTRUTURAÇÃO UML – 13 DIAGRAMAS
DIAGRAMAS ESTRUTURAISDIAGRAMAS ESTRUTURAISDIAGRAMAS ESTRUTURAISDIAGRAMAS ESTRUTURAIS� Diagrama de classes, objetos e pacotes;� Diagrama de implantação, componentes e estruturação composta.
DIAGRAMAS COMPORTAMENTAISDIAGRAMAS COMPORTAMENTAISDIAGRAMAS COMPORTAMENTAISDIAGRAMAS COMPORTAMENTAIS� Casos de uso e diagrama de atividades;� Diagrama de máquinas de estado.
DIAGRAMAS DE INTERAÇÃODIAGRAMAS DE INTERAÇÃODIAGRAMAS DE INTERAÇÃODIAGRAMAS DE INTERAÇÃO� Diagramas de sequência, comunicação, tempo e visão geral da interatividade.
04/07/2015
10
SUGESTÕES PARA SISTEMAS
EXERCÍCIO
Em duplas, liste 10 requisitos funcionais e 10 requisitos nãofuncionais para um projeto de software, como sugestão:
� Posto de combustível;
� Venda de passagens;
� Pizzaria;
� Escola de idiomas;
� Padaria.
04/07/2015
11
DEFINIÇÃO DO SISTEMA – POSTO DE COMBUSTÍVEL
O caso em questão será o desenvolvimento de um sistema paracontrole de pagamentos de abastecimento em um posto decombustível localizado no centro da cidade. Este sistema deveráarmazenar todas as informações necessárias para que se possafazer a venda de combustível ao cliente.
DEFINIÇÃO DO SISTEMA – VENDA DE PASSAGENS
O sistema para venda de passagensatenderá uma empresa de transportes emespecífico, este sistema tem como objetivofazer a venda e reservas de passagensrodoviárias.
04/07/2015
12
DEFINIÇÃO DO SISTEMA – PIZZARIA
Uma pizzaria da cidade vaicomeçar a trabalhar com teleentregas, para isso necessita deum sistema para controle depedidos. O objetivo do sistema égerenciar os pedidos de pizza erepassar 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.
04/07/2015
13
DEFINIÇÃO DO SISTEMA – PADARIA
Para uma padaria, o sistema a ser desenvolvido será instaladoapenas no caixa da padaria, ou seja, o objetivo principal destesistema é fazer a gestão da cobrança das comandas.
DIAGRAMAS CASOS DE USO
04/07/2015
14
CASOS DE USO
Este diagrama é responsável por modelar o comportamentocomportamentocomportamentocomportamentodo sistema devido a interação com algum ator produzindo umresultado que pode ser observado.
A construção de um sistema é guiado pelos casos de uso.A construção de um sistema é guiado pelos casos de uso.A construção de um sistema é guiado pelos casos de uso.A construção de um sistema é guiado pelos casos de uso.
Um caso de uso indica uma funcionalidade que o sistema deve Um caso de uso indica uma funcionalidade que o sistema deve Um caso de uso indica uma funcionalidade que o sistema deve Um caso de uso indica uma funcionalidade que o sistema deve ofereceroferecerofereceroferecer
DIAGRAMA CASOS DE USO
Em geral, um sistema possui apenas um diagrama de casosde uso, mas em determinada situações pode ser necessária adecomposição dos diagramas em módulos, devido acomplexidade do sistema.
04/07/2015
15
CASOS DE USO
Os casos de são representados por elipses, com um textoque descreve sua funcionalidade. Essa descrição geralmente éum verboverboverboverbo.
IDENTIFICANDO CASOS DE USO
Uma loja de CDs possui discos para venda. Um cliente podecomprar uma quantidade ilimitada de discos para isto ele deve sedirigir à loja. A loja possui um atendente cuja função é atender osclientes durante a vendavendavendavenda dosdosdosdos discosdiscosdiscosdiscos. A loja também possui umgerente cuja função é administraradministraradministraradministrar oooo estoqueestoqueestoqueestoque para que não faltemdiscos. Além disso é ele quem dá folga ao atendente, ou seja, eletambém atende os clientes durante a vendavendavendavenda dosdosdosdos discosdiscosdiscosdiscos.
04/07/2015
16
ATOR
Em um diagrama casos de uso, o ator são todos osusuários, hardware e sistemas externos que irão de alguma formainteragirinteragirinteragirinteragir comcomcomcom osososos casoscasoscasoscasos dededede usousousouso. Um ator não faz parte do sistema,apenas interage. Sua simbologia é:
IDENTIFICANDO ATORES
Uma loja de CDs possui discos para venda. Um cliente podecomprar uma quantidade ilimitada de discos para isto ele deve sedirigir à loja. A loja possui um atendenteatendenteatendenteatendente cuja função é atenderos clientes durante a venda dos discos. A loja também possui umgerentegerentegerentegerente cuja função é administrar o estoque para que não faltemdiscos. Além disso é ele quem dá folga ao atendente, ou seja, eletambém atende os clientes durante a venda dos discos.
04/07/2015
17
RELACIONAMENTOS
Descrição que indica como atores e casos de uso irão serelacionar. 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 atorutiliza a função do sistema representado pelo caso de uso, seja:requisitandorequisitandorequisitandorequisitando aaaa execuçãoexecuçãoexecuçãoexecução dadadada funçãofunçãofunçãofunção ou recebendorecebendorecebendorecebendo oooo resultadoresultadoresultadoresultadoproduzidoproduzidoproduzidoproduzido pelapelapelapela funçãofunçãofunçãofunção....
04/07/2015
18
IDENTIFICANDO ASSOCIAÇÃO
Uma loja de CDs possui discos paravenda. Um cliente pode comprar umaquantidade ilimitada de discos para istoele deve se dirigir à loja. A loja possuium atendenteatendenteatendenteatendente cuja função é atender osclientes durante a vendavendavendavenda dededede discosdiscosdiscosdiscos. Aloja também possui um gerentegerentegerentegerente cujafunção é administraradministraradministraradministrar oooo estoqueestoqueestoqueestoque para quenão faltem discos. Além disso é elequem dá folga ao atendente, ou seja, eletambém atende os clientes durante avendavendavendavenda dededede discosdiscosdiscosdiscos.
RELACIONAMENTO ENTRE ATORES
Os relacionamento entre atores quando ocorrem são dotipo de comunicaçãocomunicaçãocomunicaçãocomunicação ou generalizaçãogeneralizaçãogeneralizaçãogeneralização. Um relacionamento decomunicação se refere a uma troca de mensagens entre osatores.
04/07/2015
19
RELACIONAMENTO - GENERALIZAÇÃO
Este relacionamento indica que um ator é um caso especialde um outro ator mais genérico.
Exemplo:
Gerente éééé umumumum funcionário
Analista também éééé umumumum 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. Noexemplo, a validação do uso pode ser: através de uma senha oudo escaneamento de retina.
04/07/2015
20
IDENTIFICADO GENERALIZAÇÃO
As vendas podem ser àààà vistavistavistavista ou aaaa prazoprazoprazoprazo. Em ambos os casos oestoque é atualizado e uma nota fiscal, entregue ao consumidor.
Em venda à vista, clientes cadastrados que compram mais de 5 CDs deuma só vez ganham um desconto de 1% para cada ano de cadastro.
Em venda a prazo, ela pode ser parcelada em 2 pagamentos com umacréscimo de 20%. Podem ser pagas no cartãocartãocartãocartão ou no boletoboletoboletoboleto. Empagamento no boleto, são gerados boletos bancários que sãoentregues ao cliente e armazenados no sistema para lançamento.Pagamento no cartão, os clientes com mais de 10 anos de cadastro naloja ganham o mesmo desconto das compras a vista.
IDENTIFICANDO GENERALIZAÇÃO
04/07/2015
21
RELACIONAMENTO - EXTENSÃO
Uma extensão permite que pontos opcionais no fluxo de eventos de um diagrama.
RELACIONAMENTO - EXTENSÃO
04/07/2015
22
IDENTIFICANDO EXTENSÃO
No caso de uma venda à vista, clientes cadastrados na loja e quecompram mais de 5 CDs de uma só vez ganham um descontodescontodescontodesconto de1% para cada ano de cadastro.
No caso de uma venda a prazo. Para pagamento com cartão, osclientes com mais de 10 anos de cadastro na loja ganham omesmo descontodescontodescontodesconto das compras à vista.
IDENTIFICANDO EXTENSÃO
04/07/2015
23
RELACIONAMENTO - INCLUSÃO
Evita que um mesmo fluxo de eventos seja repetido pordiversas vezes. Como exemplo podemos citar um sistema quecontrola pedidos de um usuário, para que este pedido sejaexecutado o usuário deve ter sido validado antes.
RELACIONAMENTO - INCLUSÃO
04/07/2015
24
IDENTIFICANDO INCLUSÃO
Para efetuar vendas ou administrar estoque, atendentes egerentes terão que validarvalidarvalidarvalidar suas respectivas senhas de acesso aosistema.
FRONTEIRAS DO SISTEMA
Uma fronteira de um sistema é um elemento opcional, queserve para delimitar a área de atuação.
04/07/2015
25
DOCUMENTAÇÃO DE UM CASO DE USO
DOCUMENTAÇÃO
Não existe um padrão para documentação. Em geral, asformas mais usadas são:
� Descrição passo a passo (Informal);
� Tabelas;
� Pseudocódigo;
� Fluxograma;
� CenáriosCenáriosCenáriosCenários (Típica).
04/07/2015
26
ANATOMIA DE UM CASO DE USO
Descrição
Fluxo Básico
Fluxo Alternativo 1
Fluxo Alternativo n
Pós-condição
Pré-condição
CENÁRIO
04/07/2015
27
CENÁRIO – OUTRO EXEMPLO
DescriçãoDescriçãoDescriçãoDescrição: Saque de dinheiro em um caixa eletrônico.
Pré condição: Pré condição: Pré condição: Pré condição: Cliente identificado corretamente.
Fluxo básico:Fluxo básico:Fluxo básico: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 Fluxo alternativo: A1 Fluxo alternativo: A1 Fluxo alternativo: A1 –––– VALOR INFORMADO INVÁLIDOVALOR INFORMADO INVÁLIDOVALOR INFORMADO INVÁLIDOVALOR INFORMADO INVÁLIDO1. No passo 4 do fluxo básico o sistema verificou que ovalor 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 Fluxo Fluxo Fluxo alternativo: A2 alternativo: A2 alternativo: A2 alternativo: A2 –––– SALDO INSUFICIENTESALDO INSUFICIENTESALDO INSUFICIENTESALDO INSUFICIENTE1. 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 Pós Pós Pós condição: condição: condição: condição: Cartão devolvido ao cliente