METODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS Prof. Dr. rer. nat. Daniel D. Abdala 1.

Apresentação em tema: "METODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS Prof. Dr. rer. nat. Daniel D. Abdala 1."— Transcrição da apresentação:

1 METODOLOGIA PARA DESENVOLVIMENTO DE SISTEMAS Prof. Dr. rer. nat. Daniel D. Abdala e-mail: abdala@das.ufsc.br 1

2 Apresentar técnicas para levantamento de requisitos; Demonstrar como levantar requisitos de usabilidade usando prototipação de interfaces; Discutir a decomposição de requisitos Apresentar como levantar requisitos de interação por meio de casos de uso. 2

3 Problemas relacionados ao levantamento de requisitos Documento de descrição do projeto Decomposição de requisitos Classificação de requisitos Especificação de interfaces do usuário Diagrama de Casos de Uso 3

4 Em que pé estamos? Sabemos quais os tipos de requisitos existentes Sabemos que requisitos podem ser definidos em vários níveis de detalhamento Sabemos como descrever os requisitos usando diagramas e tabelas E agora? Ao tentarmos especificar os requisitos nos deparamos com problemas e incertezas. Solução – Precisamos de uma metodologia para levantamento de requisitos! 4

5 Um bom ponto de partida para a identificação dos elementos que comporão o sistema Texto escrito pelo cliente e/ou usuário descrevendo como eles imaginam o sistema; Precisa ser minerado para a extração de requisitos A extração de requisitos via a descrição textual do sistema fornece uma maneira prática de levantar muitos requisitos. No entanto aspectos dinâmicos da execução do sistema podem não ser capturados corretamente. 5

6 O sistema consiste em um programa que permite 1 ou 2 pessoas jogar damas. Uma interface gráfica representado o tabuleiro é apresentada em estado inicial com as peças dispostas a cada início de partida. O jogador pode clicar na peça que deseja mover e em seguida na casa para a qual a peça deve ser movida. O sistema testará se o movimento é válido e se este for o caso, a peça será movimentada. O jogador pode também disputar uma partida contra o computador. O computador poderá jogar no modo fácil, normal, avançado, impossível. 6

7 7

8 Permite a identificação de funcionalidades, restrições e entidades do sistema; Ótimo ponto de partida para a especifica- ção inicial dos requisitos Problemas para a identificação de requisi- tos dinâmicos Serve como base para entender o objetivo do sistema e planejar as entrevis- tas subseqüentes de levantamento de requisitos 8

9 Maneira útil de definir requisitos de interação com o usuário Fornece uma base para discussão de funcionalidades com o usuário Parte visível do sistema, geralmente mais suscetível a críticas e pedidos de alteração 9

10 10

11 Muitas vezes a descrição inicial de um requisito pode ser muito extensa englobando diversas funcionalidades; Requisitos Funcionais e Não Funcionais tendem a se misturar, principalmente na etapa de elaboração de requisitos do usuário; Decompor requisitos significa dividir requisitos complexos em dois ou mais requisitos. 11

12 12 O Sistema deve ser capaz de registrar Contas para Clientes, recolhendo seus dados pessoais, de modo a identificá-los. Ele deve exigir do Cliente um Login único e uma Senha, para que ele possa ter uma Conta. Registrar Cliente Cadastrar Conta O Sistema deve exigir do Cliente um Login único e uma Senha, para que ele possa ter uma Conta. O Sistema deve ser capaz de registrar Contas para Clientes, recolhendo seus dados pessoais, de modo a identificá-los

13 Requisitos são a posteriori mapeados em artefatos de software Requisitos bem definidos com escopo específico são: mais simples de serem implementados Pertencerão a mesma unidade lógica Permitirão a adoção de uma arquitetura sólida para o sistema 13

14 Sistemas reais tendem a ter centenas ou até mesmo milhares de requisitos Classificar os requisitos auxilia a: Organizar os requisitos em subsistemas (pacotes) Executar o rastreamento de alterações Geralmente apenas requisitos não- funcionais são classificados, no entanto também é possível aplicar algum tipo de classificação aos requisitos funcionais 14

15 15

16 Casos de Uso (CdU) incluem tipicamente um ou mais cenários que descrevem as interações que ocorrem entre os atores e o sistema. CdUs também documentam as exceções que ocorrem do ponto de vista do usuário Cada CdU representa uma única interação repetível que um usuário ou ator vivencia ao utilizar o sistema Casos de uso podem incluir outros casos de uso como parte de um padrão de interação mais complexo. Eles também podem ser utilizados por outros casos de uso para lidar com situações excepcionais Diagrama UML (Unified Modeling Language) 16

17 Casos de uso Atores Relacionamentos envolvendo esses elementos 17

18 18

19 Modelar as funcionalidades do software (os casos de uso) O que o software faz (e não como faz) Modelar os elementos externos que interagem com o software (atores) 19

20 Uma funcionalidade do software Atômica, completa (não uma fração) Externamente perceptível EX: cada uma das opções do menu de um caixa eletrônico de banco emissão de extrato de conta corrente 20

21 Associado à noção de que um software interage com o meio externo Representa uma entidade externa que interage com o software sob modelagem Pessoa Equipamento (hardware) Outro software Função de um ator Representa a interação com um elemento externo Faz parte do sistema (elemento interno) Modela a interface com cada elemento externo 21

22 Apenas a identificação de uma funcionali- dade, sem qualquer referência a como ela é executada 22

23 UML prevê três tipos de relacionamentos Extensão Inclusão generalização 23

24 Estabelece uma relação em que um dos casos de uso ou atores tem seu comportamento estendido através do comportamento definido em outro caso de uso. Freqüentemente expressa um fluxo alternativo 24

25 Estabelece que parte do comportamento inerente a um caso de uso está definida em outro caso de uso Um caso de uso contém o comportamento definido em outro caso de uso Permite evitar repetições na modelagem 25

26 Estabelece uma relação de especiali- zação entre dois casos de uso, onde Um corresponde a um comportamento genérico O outro, a uma especialização deste para alguma situação específica 26

27 Utilização – indica que um elemento requer o outro para ser utilizado. Relacionamento básico dos CdUs; Associação – representa uma associação entre dois elementos do diagrama; Implementação – o elemento origem implementa o elemento destino ; Invocação – CdU A em algum ponto faz com que CdU B seja executado; Precedência – CdU A deve ser executado antes que CdU B o seja. 27

28 Diagrama de CdU fornece um resumo da interação Detalhamento da interação deve existir em forma textual em um documento associado ao CdU 28

29 Documento de descrição auxilia na identifi- cação de requisitos; Prototipação de Interfaces auxilia na identi- ficação de requisitos de usabilidade; Requisitos devem ser decompostos para que representem apenas funcionalidades ou restrições atômicas; Requisitos dinâmicos podem ser melhor levantados por meio de casos de uso. 29

30 R. S. Pressman, Engenharia de Software, McGraw Hill, 6a Ed., 2002. Chap. 12. I. Sommerville. Software Engineering. 7 th Ed. Addison-Wesley, 2004. Chap. 7,16. 30