Prof. Msc Roberta Andrade raaf@cin.ufpe.br

1. Laboratório de Programação Bacharelado em Sistema de Informação Prof. Msc Roberta Andrade raaf@cin.ufpe.br

2. Tópicos • Definição de Requisitos • Requisitos Funcionais • Requisitos não funcionais • Linguagem de Modelagem de Dados - UML • Diagrama de Caso

3. 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

4. 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

5. 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

6. 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

7. Exemplo • Um sistema de alarme contra ladrão Sensores de movimento Sensores das portas Controlador de alarme Sirene Sintetizador de voz

8. 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?

9. 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.

10. 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.

11. 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.

12. Componentes do modelo • O modelo de casos de uso de um sistema é composto de: • Casos de uso • Atores • Relacionamentos entre os elementos anteriores.

13. 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.

14. 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.)

15. 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

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. Exemplo (Notação)

22. Exemplo (Notação)

23. 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.

24. Notação

25. Notação

26. Notação

27. Notação

28. 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.

29. 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...