► 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  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”. 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 entando 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