Metodologia para Desenvolvimento de Sistemas Web

Apresentação em tema: "Metodologia para Desenvolvimento de Sistemas Web"— Transcrição da apresentação:

1 Metodologia para Desenvolvimento de Sistemas Web
Felipe Paulo Guazzi Bergo (Doutorando em Ciência da Computação) Milena Alexandre dos Santos Baesso (Mestranda em Engenharia Elétrica) Apresenta-se uma Metodologia para desenvolvimento de sistemas web, denominada Object-Oriented Hypermedia Design Method (OOHDM). A Metodologia OOHDM foi desenvolvida na Pontifícia Universidade Católica do Rio de Janeiro, por Gustavo Rossi e Daniel Schwabe. Trata-se de uma metodologia baseada em modelos para o desenvolvimento de aplicações hipermídia de grande porte. Ressalta-se que nesta apresentação será dada ênfase a fase de projeto do ciclo de desenvolvimento. MO409 – Introdução à Engenharia de Software Profª. Eliane Martins

2 Sistemas Web - Características
Uso de infra-estrutura de terceiros. Servidores Web, BD Cliente com Web Browser Internet A interface de usuário é responsável pela visualização e envio de informações no lado cliente. O núcleo funcional é responsável pelo processamento destas informações e pela geração dinâmica da interface no lado servidor. A comunicação cliente-servidor ocorre pela Internet. Manutenção Mínima, Tempo Zero de Configuração Terceirizável Aplicação

3 Sistemas Web - Características
Alta Usabilidade Uso em larga escala de componentes de software Segundo Pressman, um sistema web: Está sempre em evolução É voltado para execução em rede Possui grande valor de conteúdo A construção de grandes aplicações de hipermídia é extremamente difícil, devido, principalmente, à combinação de navegação controlada pelo usuário com a própria natureza dos dados multimídia. A utilização de componentes como browsers, servidores web, plugins, SGBDs, etc. leva a um processo acelerado de detecção e correção de falhas, que resulta em componentes mais robustos, a longo prazo. O conteúdo dos sistemas passou a ser mais complexo, não se resume apenas a questão transacional. A interface passou a ter outro sentido, já que esta se tornou a porta de entrada no mundo virtual, e o volume de informações a disposição é maior e mais variado.

4 Sistemas Web - Propósitos
Informativo: Prestar informações Funcional: Oferecer serviços Entretenimento: Divertir pessoas Verifica-se que sistemas possuem propósitos, e estes devem ser levados em consideração durante o seu desenvolvimento.

5 Sistemas Web - Propósitos
Apresenta-se um classificação de acordo com o propósito dos sistemas web e percebe-se que alguns possuem múltiplos propósitos. Fonte: Design e Usabilidade de Sistemas Web, Jair C. Leite (DIMAp – UFRN)

6 Requisitos Não - Funcionais
Confiabilidade: Maturidade, Tolerância a Falhas e Recuperabilidade; Funcionalidade: Adequação, Acurácia, Interoperabilidade, Conformidade e Segurança de Acesso; Requisitos não-funcionais representam restrições que a aplicação deve atender. No caso de sistemas web destaca-se o requisito usabilidade, onde o usuário deve ser capaz de perceber intuititivamente o que fazer no sistema e como fazer. É fundamental que o sistema seja fácil de utilizar isto é, o usuário deve cometer poucos erros durante a interação. Além da facilidade de uso é necessária a facilidade de aprendizado, o usuário deve aprender rápido a utilizar o sistema e deve também poder memorizar o que aprendeu. Outro fator é de produtividade, o usuário deve realizar suas tarefas com rapidez. Não menos importante a flexibilidade deve garantir que a interface ofereça alternativas de interação. Finalmente, a satisfação deve ser garantida, o usuário precisa gostar de utilizar o sistema. A funcionalidade, outro requisito não – funcional também é de fundamental importância, deve ser garantido que após o envio de dados o sistema irá processá-los corretamente. Usabilidade: Inteligibilidade, Apreensibilidade e Operacionalidade;

7 Requisitos Não - Funcionais
Eficiência: Tempo e Recursos; Manutenibilidade: Analisabilidade, Modificabilidade, Estabilidade e Testabilidade; Portabilidade: Adaptabilidade, Capacidade para ser instalado, Conformidade e Capacidade para substituir. O desempenho é outro requisito importante em aplicações web, deve-se evitar que problemas como: – A página demora a carregar! – O servidor não responde em tempo. – A página demora a ser exibida! ocorram durante a execução do sistema. A portabilidade também é de fundamental importância, deve-se garantir que a aplicação será exibida corretamente em qualquer browser e que a linguagem script funcionará independente do browser ou servidor.

8 Requisitos Não - Funcionais
A plataforma, o sistema gerenciador de banco de dados, isto é, a tecnologia que deve ser utilizada também é vista como requisito não-funcional, no caso de aplicações web tem-se como modelos e tecnologias principais: - A arquitetura cliente-servidor; - O hipertexto; - O protocolo HTTP; - A linguagem HTML; - O endereçamento através da URI. Sabe-se que aparentemente estes requisitos são óbvios, porém muitos projetos são perdidos pelo esquecimento de um dos requistos não funcionais fundamentais ao correto funcionamento da aplicação. A metodologia OOHDM não diz como estes requisitos devem ser especificados, então aconselha-se o uso de descrição textual para que os requisitos não funcionais constem da documentação do sistema. Fonte: Design e Usabilidade de Sistemas Web, Jair C. Leite (DIMAp – UFRN)

9 Estudo de Caso – Sistema de Hotel
Um grupo de empresários deseja que sua equipe desenvolva um sistema para gerenciar reservas e ocupações de apartamentos em uma rede de hotéis. O sistema será utilizado para controlar serviços internos de cada hotel e para a comunicação entre hotéis da rede de forma que seja possível que uma unidade da rede faça consultas sobre a disponibilidade de vagas em outras unidades da mesma cidade ou região. Descrição fornecida pela professora, do estudo de caso.

10 Estudo de Caso – Sistema de Hotel
Serviços Básicos: Cadastro de clientes (hóspedes), apartamentos e despesas; Verificação de disponibilidade (via atendente por telefone ou via WEB); Controle de reserva (e cancelamento de reserva) de apartamentos; Controle de ocupação de apartamentos; Controle de pagamento (emissão da conta, emissão de fatura e registro do pagamento); Emissão de relatórios gerenciais (que devem ser sugeridos pelos desenvolvedores). Serviços básicos, fornecidos pela professora, que a aplicação deve atender. Destaca-se o serviço que será mais detalhado durante a apresentação.

11 Estudo de Caso – Sistema de Hotel
Verificar Disponibilidade Descrição: Apresentar tipos de quarto disponíveis com seu valor para um determinado período. Atores: Usuário Web Prioridade: Alta (1) Pré-Condições: Cadastro de tipo de quarto. Optou-se por detalhar a funcionalidade: - Verificar Disponibilidade, onde são apresentados tipos de quarto disponíveis para um determinado período, com o seu valor. Cenário Normal: Sistema apresenta tela de busca de vagas Usuário informa localidade desejada para o sistema Sistema apresenta hotéis nesta localidade Usuário informa hotel para sistema Sistema solicita período de estadia Usuário informa período de estadia Sistema apresenta tipo de quarto disponível e seu valor para o período. Cenário Alternativo: Usuário informa evento para sistema Sistema apresenta hotel e solicita período de estadia Usuário informa periodo de estadia Sistema apresenta tipo de quarto disponível e seu valor para período

12 Diagrama de Classes Para facilitar a criação dos projetos navegacional e de interface abstrata, apresenta-se um diagrama de classes (modelo conceitual em OOHDM), que compreende a arquitetura do subsistema representando-o completamente. Observa-se que apenas os atributos mais relevantes foram considerados neste diagrama.

13 Arquitetura O Projeto Arquitetural deve descrever o sistema como um conjunto de componentes mais importantes, chamados de subsistemas, que fornecem um conjunto de sistemas específicos. Pode-se especificar a decomposição de cada subsistema em módulos. Num modelo orientado a objetos, os subsistemas são decompostos em um conjunto de objetos que se comunicam. Apresenta-se uma arquitetura para a aplicação completa, e em seguida detalha-se a arquitetura do subsistema Disponibilidade.

14 Arquitetura Subsistema: Tipo de Componente: Função: Disponibilidade
Buscador Função: buscar apartamentos disponíveis em um dado período em um dado Hotel. apresentar tipo de apto vago e seu valor Detalhamento do subsistema utilizado como estudo de caso.

15 Arquitetura No projeto arquitetural do subsistema Disponibilidade, verificou-se a necessidade de dois controladores um de cadastro onde ocorre o controle dos dados cadastrais dos hotéis da rede e de posíveis eventos que venham ocorrer em algum hotel, visto que hotel é uma agregação de tipos de quarto e que estes podem possuir promoções em determinados períodos, o controle de cadastro também é responsável por estes dados. O segundo controle o de status deve ser capaz de nos dizer quais tipos de apto de um determinado hotel estão ocupados, reservados ou vagos num período fornecido previamente.

16 Projeto da Interface Abstrata
Projeto em OOHDM Atividade Produtos Mecanismos Interesses Projeto da Navegação Nós, elos, estruturas de acesso, contextos de navegação, transformações navegacionais. Mapeamento entre objetos conceituais e de navegação. Padrões de navegação para a descrição da estrutura geral da aplicação. Leva em conta o perfil do usuário e a tarefa; ênfase em aspectos conceituais e arquiteturais. Projeto da Interface Abstrata Objetos de interface abstrata, reações a eventos externos, transformações de interface. Mapeamento entre objetos de navegação e objetos de interface. Modelagem de objetos perceptíveis, implementa metáforas escolhidas. Descrição de interface para objetos navegacionais. A metodologia OOHDM entende a fase de projeto do desenvolvimento de uma aplicação web como sendo as fases de definição do projeto navegacional e do projeto de interface abstrata do sistema. Percebe-se assim o quão imatura a metodologia ainda se apresenta. A tabela apresenta de forma resumida as atividades da fase de projeto da metodologia OOHDM.

17 Design Navegacional Início da Consulta Detalhes do Lista de eventos
Busca de Hotel por Cidade Busca de Eventos Detalhes do Evento Lista de eventos nos próximos 18 meses Lista de Estados Lista de Cidades Busca por Quarto Lista de Hotéis Notação: caixas tracejadas: derivações simples de classe ou pontos de navegação. Triângulo preto: índice com múltiplas ordenações (por preço, por data, etc.). Retângulo preto: Lista dinâmica baseada no resultado anterior. Note que o usuário sempre pode retornar ao início da consulta, Não colocamos as setas para não poluir demais o diagrama. Tipos de Quarto Detalhes do Hotel Período de Estadia Lista de eventos neste hotel Quartos Disponíveis

18 Design de Interface Abstrata
ADV: Detalhes do Hotel Nome (texto) Endereço (texto) (link) ADV: características do hotel Foto do Hotel (imagem) Galeria de fotos (link) Tipos de quartos (link) ADV: Início da Consulta Nome da rede de hotéis (texto) Busca de Hotel por Cidade (link: ADV: Hotel por Cidade) Busca de Eventos (link: ADV: Busca de Eventos) ADV: Hotel por Cidade Lista de estados (listbox, ação: preenche lista de cidades) Lista de cidades (listbox dinâmica, ação: preenche lista de hotéis) Lista de Hotéis (lista dinâmica de links) Os elementos de Navegação são detalhados em ADVs (Abstract Data Views), que especificam quais informações aparecerão em cada momento. ADVs podem (e devem) referenciar outros ADVs, e estruturas complexas podem ser feitas com composição de ADVs.

19 Design de Interface Abstrata
ADV: Detalhes do Hotel Nome (texto) Endereço (texto) (link) ADV: características do hotel Foto do Hotel (imagem) Galeria de fotos (link) Tipos de quartos (link) Hotel XYZ Plaza Residence Maximus Av. Comendador Shinezaki 999 – Cambuí Campinas – SP – Fone (19) Fax (19) foto Centro de convenções para 500 pessoas, american bar, Restaurante húngaro, pista de boliche, heliponto. Mais Fotos Apartamentos & Suítes O posicionamento dos elementos dos ADVs pode ser especificado em uma ferramenta de prototipação, ou com rascunhos manuais. O projetista de interface não precisa ser o mesmo que especifica os ADVs textualmente. Note a composição com outra ADV (características do Hotel), que é “importada” pela ADV sendo especificada.

20 Validação de Projeto Conheça o modelo antes de validá-lo:
Para um dado cenário, examine todas as medidas de performance das saídas do modelo e pergunte “São razoáveis?”. Utilize parâmetros de entrada para validar o modelo: Quando alguma entrada for alterada, examine as tendências em medidas de performance comuns. Usualmente o caminho é conhecido, a menos que a mudança seja muito importante. Modelos são utilizados para representar o comportamento de um novo sistema, ou o comportamento de um sistema modificado, ou ainda, o comportamento de um sistema dentro de novas condições. Os modelos obtidos após a modelagem de um projeto, devem participar de uma série de atividades chamadas: debugging, verification e validation. Então o projeto será modificado ou aprovado. Ressalta-se que nenhum modelo será 100% verificado e validado, a validação não é absoluta, no entanto muitos problemas podem ser solucionados antes da fase de implementação. A metodologia OOHDM não especifica como deve ser feita a validação dos modelos por ela solicitados, assim aconselha-se o uso do framework apresentado na referência 9. Lembrando que a verificação ocorre quando o projetista exercita um modelo aparentemente correto, com o propósito de buscar e corrigir erros no modelo. A validação ocorre quando o projetista e pessoas conhecedoras do sistema real trabalham juntas para rever e avaliar como o modelo trabalha.

21 Validação de Projeto Quando estamos projetando um sistema novo,
uma validação científica completa não é possível, simplesmente porque um sistema real não existe para comparação. Nesta situação é essencial que os projetistas examinem e verifiquem a conduta dos modelos em cada nível. Isto inclui como o modelo responde em situações extremas bem como em situações normais.

22 Conclusões OOHDM permite a colaboração de profissionais de software e design gráfico na fase de projeto. OOHDM é voltada para aplicações hipermídia, facilitando a especificação e composição de imagens, vídeos e blocos de apresentação de informação multimídia É um metodo jovem, acadêmico e com pouco suporte. A única ferramenta de auxílio (OOHDMweb) apresentou muitas dificuldades para o uso. Não provê validação ou tratamento de requisitos não funcionais. Acreditamos que o tratamento de requisitos não funcionais em sistemas web realmente requerem um tratamento caso a caso.

23 Referências R.S. Pressman, (2001) “Software Engineering: A practitioner’s approach”, 5th ed. McGraw-Hill, ISBN B. Haire, B. Henderson-Sellers, D. Lowe (2001) “Supporting web development in the OPEN process: additional tasks” Submitted to COMPSAC'2001: International Computer Software and Applications Conference, Chicago, Illinois, USA. A.M.B.R. Carvalho, T.C.S. Chiossi, "Introdução à Engenharia de Software", Campinas, SP; Editora da Unicamp, (2001). G. Rossi “An Object-Oriented Method for Designing Hypermedia Applications”. PHD Thesis, Departamento de Informática, PUC-Rio, Brazil, July 1996 (in Portuguese). D. Schwabe, R.A. Pontes, I. Moura, "OOHDM-Web: An Environment for Implementation of Hypermedia Applications in the WWW", PUC-Rio, Brazil (1998). último acesso 09/11/2004. D. Schwabe, G. Rossi, “The Object-Oriented Hypermedia Design Model”, Comm. of the ACM, 38(8), pp 45-46, Aug D. Schwabe, G. Rossi, "Developing hypermedia applications using OOHDM“. In Workshop on Hypermedia Development, Pittsburgh, USA, June 1998 J. S. Carson, “Model Verification and Validation”. In Proceedings of the 2002 Winter Simulation Conference, ed. E. Yücesan, C. H. Chen, J. L. Snowdon, and J. M. Charnes, Piscataway, New Jersey: Institute of Electricel and electronics Engineers. Victor F.A. Santander, Jaelson F. B. Castro, Márcio A. S. Bueno, “Estudo de Princípios de Qualidade em Aplicações Web ”, Universidade Federal de Pernambuco – Centro de Informática Jair C. Leite, “Design e Usabolidade em Sistemas Web”, DIMAp-UFRN (2002) Eliane Martins, “Projeto Arquitetural”, IC-UNICAMP (2001) Apresenta-se as referências utilizadas para a preparação da apresentação, destaca-se as 4 últimas que deram suporte a atividades da fase de projeto não cobertas pela metodologia OOHDM.