slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Prof. Msc Roberta Andrade raaf@cin.ufpe.br PowerPoint Presentation
Download Presentation
Prof. Msc Roberta Andrade raaf@cin.ufpe.br

Loading in 2 Seconds...

play fullscreen
1 / 29

Prof. Msc Roberta Andrade raaf@cin.ufpe.br - PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on

Laboratório de Programação. Bacharelado em Sistema de Informação. Prof. Msc Roberta Andrade raaf@cin.ufpe.br. Tópicos. Definição de Requisitos Requisitos Funcionais Requisitos não funcionais Linguagem de Modelagem de Dados - UML Diagrama de Caso. Motivação.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Prof. Msc Roberta Andrade raaf@cin.ufpe.br' - vala


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Laboratório de Programação

Bacharelado em Sistema de Informação

Prof. Msc Roberta Andrade

raaf@cin.ufpe.br

t picos
Tópicos
  • Definição de Requisitos
  • Requisitos Funcionais
  • Requisitos não funcionais
  • Linguagem de Modelagem de Dados - UML
    • Diagrama de Caso
motiva o
Motivação
  • É o processo de adquirir um sistema para uma organização suprir um necessidade
  • Um sistema pode ser comprado como um todo ou em partes
  • Antes de tomar decisões:
    • Completar alguma especificação do sistema
    • Completar algum projecto de arquitectura
  • É raro uma oraganização desenvolver todos os componentes de um sistema de grande porte
defini o requisitos
Definição Requisitos
  • Definição de requisitos do sistema
    • Estabelecer um conjunto de objectivos gerais do sistema
    • Tipos de requisitos
      • Requisitos funcionais gerais: definição das funções básicas, nível abstracto
      • Propriedades do sistema: não-funcionais
      • Características que o sistema não deve apresentar
defini o de requisitos
Definição de Requisitos
  • Desenho do Sistema

Particionar

os requisitos

Definir as

interfaces

dos sub-sistemas

Especificar a

funcionalidade

dos sub-sistemas

Identificar

sub-sistemas

Atribuir

requisitos a

sub-sistemas

exemplo de sistema
Exemplo de Sistema
  • O sistema é decompostoemsubsistemas
  • Cadasusb-sistema é decomposto de forma semelhanteatéque o sistemaestejadecompostoemcomponentesfuncionais
  • Um componentefuncionalprovêumafunçãoúnica
  • Um subsistema é, portanto, multi-funcional
  • Um modelo de AS identificacomponentes de HW e SW
  • ComponentesFuncionais:
    • Sensores: radar
    • Actuadores: válvulas
    • Processamento: processador de ponto-flutuante
    • Comunicação: ethernet
    • Coordenação: scheduler emsistemas de tempo real
    • Interface: sintetizador de voz
exemplo
Exemplo
  • Um sistema de alarme contra ladrão

Sensores de

movimento

Sensores das

portas

Controlador

de alarme

Sirene

Sintetizador

de voz

fatores humanos
Fatores Humanos
  • Qualquer sistema está inserido num contexto social e organizacional
  • Desenho de Interface apropriado é crítico para a operacionalização do sistema
  • Alguns pontos a serem levados em consideração:
    • Há modificação de procedimentos de trabalho no ambiente?
    • O sistema desqualifica os utilizadores?
    • O sistema muda a estrutura da força política na organização?
    • O sistema exige mudança na maneira de trabalhar?
introdu o
Introdução
  • O modelo de casos de uso é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com o mesmo.
  • O modelo de casos de uso modela os requisitos funcionais do sistema.
introdu o1
Introdução
  • O diagrama da UML utilizado na modelagem de casos de uso é o diagrama de casos de uso.
  • Técnica de modelagem idealizada por Ivar Jacobson, na década de 1970.
  • Mais tarde, incorporada ao método Objectory.
  • Posteriormente, a notação de casos de uso foi adicionada à UML.
introdu o2
Introdução
  • Este modelo direciona diversas das tarefas posteriores do ciclo de vida do sistema de software.
  • Além disso, o modelo de casos de uso força os desenvolvedores a moldar o sistema de acordo com o usuário.
componentes do modelo
Componentes do modelo
  • O modelo de casos de uso de um sistema é composto de:
    • Casos de uso
    • Atores
    • Relacionamentos entre os elementos anteriores.
atores
Atores
  • Elemento externo que interage com o sistema.
    • “externo”: atores não fazem parte do sistema.
    • “interage”: um ator troca informações com o sistema.
  • Casos de uso representam uma seqüência de interações entre o sistema e o ator.
    • no sentido de troca de informações entre eles.
  • Normalmente um agente externo inicia a seqüência de interações com o sistema, ou um evento acontece para que o sistema responda.
atores1
Atores
  • Categorias de atores:
    • pessoas (Empregado, Cliente, Gerente, Almoxarife, Vendedor, etc);
    • organizações (Empresa Fornecedora, Agência de Impostos, Administradora de Cartões, etc);
    • outros sistemas (Sistema de Cobrança, Sistema de Estoque de Produtos, etc).
    • equipamentos (Leitora de Código de Barras, Sensor, etc.)
relacionamentos
Relacionamentos
  • Casos de uso e atores não existem sozinhos. Podem haver relacionamentos entre eles.
  • A UML define diversos tipos de relacionamentos no modelo de casos de uso:
    • Comunicação
    • Inclusão
    • Extensão
    • Generalização
relacionamento de comunica o
Relacionamento de comunicação
  • Representa a informação de quais atores estão associados a que casos de uso
  • O fato de um ator estar associado a um caso de uso significa que esse ator interage (troca informações) com o sistema.
  • Um ator pode se relacionar com mais de um caso de uso.
  • É o mais comum dos relacionamentos.
relacionamento de inclus o
Relacionamento de inclusão
  • Existe somente entre casos de uso.
  • Analogia útil: rotina.
    • Em uma linguagem de programação, instruções podem ser agrupadas em uma unidade lógica chamada rotina.
    • Sempre que essas instruções devem ser executadas, a rotina correspondente é chamada.
  • Quando dois ou mais casos de uso incluem uma seqüência de interações comum, esta seqüência comum pode ser descrita em um outro caso de uso.
relacionamento de inclus o1
Relacionamento de inclusão
  • Este caso de uso comum:
    • evita a descrição de uma mesma seqüência de interações mais de uma vez e
    • torna a descrição dos casos de uso mais simples.
  • Um exemplo: considere um sistema de controle de transações bancárias. Alguns casos de uso deste sistema são Obter Extrato, Realizar Saque e Realizar Transferência.
    • Há uma seqüência de interações em comum: a seqüência de interações para validar a senha do cliente.
relacionamento de extens o
Relacionamento de extensão
  • Utilizado para modelar situações onde diferentes seqüências de interações podem ser inseridas em um caso de uso.
  • Sejam A e B dois casos de uso.
    • Um relacionamento de extensão de B para A indica que um ou mais dos cenários de A podem incluir o comportamento especificado por B.
    • Neste caso, diz-se que B estende A.
    • O caso de uso A é chamado de estendido e o caso de uso B de extensor.
relacionamento de extens o1
Relacionamento de extensão
  • Cada uma das diferentes seqüências representa um comportamento opcional, que só ocorre sob certas condições ou cuja realização depende da escolha do ator.
  • Quando um ator opta por executar a seqüência de interações definida no extensor, este é executado.
    • Após a sua execução, o fluxo de interações volta ao caso de uso estendido, recomeçando logo após o ponto em que o extensor foi inserido.
nota o
Notação
  • Os relacionamentosde inclusão e extensão são representados por uma seta direcionada de um caso de uso para outro.
  • A seta (tracejada) de um relacionamento de inclusão recebe o estereótipo <<inclui>>.
  • A seta (tracejada) de um relacionamento de extensão recebe o estereótipo <<estende>>.
  • A seta (sólida) de um relacionamento de herança não recebe estereótipo.
exerc cio
Exercício
  • Extrair da descrição abaixo abaixo os requisitos funcionais e construir o diagrama de caso de uso.
  • Descrição do Negócio.

A loja CdcomCarinhotrabalha com a venda, à vista e parcelada, de CD’s de todos os gêneros musicais. Ela oferece a seus clientes, do estado do Rio de Janeiro, um serviço de “delivery”, permitindo que eles recebam, em casa, produtos requisitados pelo telefone. Seus clientes estão acostumados a uma abordagem diferencial, ou seja, a loja costuma mandar mala direta quando chega algum produto cujo gênero se encaixe com o perfil daquele cliente. Há, também, ofertas promovidas durante datas especiais, por exemplo, no aniversário dos clientes, no dia dos namorados, etc. Clientes que já compraram mais de 20 CD’s na loja são classificados como “Clientes Prata” e recebem descontos de 10%. Clientes, com mais de 50 compras, são denominados “Clientes Ouro”, com descontos de 25%.

O Gerente da loja precisa de uma análise periódica de qual Gênero de CD está vendendo mais para planejar os próximos pedidos aos fornecedores. E deve saber, também, qual a região do Estado do Rio que mais compra, para definir o foco da equipe de Marketing. Os vendedores (por telefone ou na loja) recebem salário além da comissão sobre as suas vendas. A CdcomCarinhodeseja informatizar seu controle de vendas e de entregas. E, pretende, também, ampliar seu negócio através de vendas pela Internet.

exerc cio1
Exercício
  • Descrição do Negócio.
  • Sistema para cadastramento de livros e outros documentos controlados por uma biblioteca, como manuais, revistas, periódicos, informativos e etc., mantendo informações como Título, nome do autor, editora, número de volumes, local de arquivamento. Em função dos dados cadastrados, o sistema possibilita uma grande facilidade de recuperação de informações e pesquisas aleatórias. Possibilita ainda se manter um controle sobre os empréstimos efetuados, informando quem fez o empréstimo, quando, data prevista de devolução, etc...
  • As principais características do sistema são :
    • Possibilidade de criação de um Cadastro das Publicações que serão controladas, e facilidade de pesquisa por qualquer um dos campos existentes;
    • Possibilidade de criação de um Cadastro de Normas Técnicas, separado das demais publicações, em função de particularidades envolvidas neste controle;
    • Possibilidade de criação de um Cadastro de Revistas e outros periódicos, com acompanhamento de data de assinatura, data de vencimento, valor, distribuição para pessoas que irão recebe-las dentro de um esquema de circulação;
    • Possibilidade de criação de um Cadastro de Usuários da biblioteca, permitindo um controle eficiente dos empréstimos, bem como circulação de periódicos e revistas, além de possibilitar a localização imediata destes para consultas ou emissão de correspondências;
    • Controle dos empréstimos efetuados, mantendo uma posição atualizada, bem como uma posição histórica dos empréstimos ocorridos;
    • Emissão de relatórios do Cadastro de Publicações, Cadastro de empréstimos, Posição de empréstimos pendentes de devolução, Índice de publicações por assunto, etc...