dbcheck! uma ferramenta para teste de banco de dados apresentação dos artefatos produzidos do...

dbCheck! uma ferramenta para teste de banco de dados

Apresentação dos artefatos produzidos do software dbCheck!

(Requisitos, Análise e Projeto)

Trabalho de Conclusão de DisciplinaEngenharia de Software para Software Livre 2 (Requisitos, Análise e Projeto)Aluno: Fernando Martines – ESL109021

Agenda

Trabalho de Conclusão de DisciplinaEngenharia de Software para Software Livre 2 (Requisitos, Análise e Projeto)Autor: Fernando Martines – ESL109021

•As motivações•A proposta•As decisões tomadas•Os artefatos•As ferramentas•A documentação•Conclusão

dbCheck! Motivações


• Bancos de dados desempenham um papel crucial nos sistemas gerenciadores de informação.

• A engenharia de banco de dados deve ser considerada no processo de desenvolvimento.

• A modelagem conceitual, lógica e física do banco de dados pode utilizar os diagramas da UML.

• As ferramentas para geração de scripts geram instruções que precisam ser adaptadas.

• As técnicas de inspeção de software não se aplicam em sua totalidade para banco de dados.

• A aplicação de testes sem critérios bem definidos pode levar a conclusões incorretas.

dbCheck! Proposta


•Criação de uma ferramenta que seja capaz de:▫"entender" os modelos de dados (UML)▫definir elementos requeridos de acordo com

critérios de teste baseados em cobertura de diagramas UML

▫gerar casos de teste a partir dos elementos requeridos

▫executar os testes de maneira automatizada▫gerar resultados da execução e determinar se

a implementação atende a especificação▫gerenciar as suites de teste criadas

dbCheck! Sistema


dbCheck! Exemplo simples


dbCheck! Exemplo simples


índices

Cardinalidade

Ordenação

Restrições de chave

estrangeira

Etc.

• A liberação do código-fonte sob a licença GPLv3.• A especificação de requisitos foi baseada no

padrão IEEE 830 e foram identificados para propósitos de rastreabilidade.

• A análise e projeto foram realizadas sob a perpectiva de orientação a objetos▫Durante a Análise, a ênfase foi encontrar e

descrever objetos (ou conceitos) no domínio do problema

▫Durante o projeto, a ênfase foi encontrar objetos lógicos de software que poderão ser eventualmente implementados usando uma linguagem de programação OO.

dbCheck! Decisões tomadas


dbCheck! Casos de Uso


dbCheck! Contratos


dbCheck! Modelo conceitual


dbCheck! Modelo de dados


dbCheck! Visão lógica


dbCheck! Visão de processo


Gerar casos de teste

dbCheck! Visão de processo


Executar testes

dbCheck! Visão de implantação


dbCheck! Ferramentas


•Especificação de Requisitos e•Documento de Arquitetura de Software

▫OpenOffice▫ http://www.broffice.org/

•Artefatos (diagramas UML)▫JUDE community (change vision)▫ http://jude.change-vision.com

•Modelo de dados (diagrama ER)▫DbDesigner▫ http://sourceforge.net/projects/dbdesigner-fork/

dbCheck! Documentação


•Documento de Espec. de Requisitos de Software

•Documento de Arquitetura de Software•Artefatos

•Disponível emhttp://databasecheck.googlecode.com/svn/docs/

Conclusão


• “Um conjunto de atividades, métodos, práticas e transformações que as pessoas empregam para desenvolver e manter software e produtos associados.” [MCT1999].

• A Engenharia de Software prevê as fases de Requisito, Análise e Projeto no processo de desenvolvimento de software.

• As dificuldades estiveram associadas ao nível de aprofundamento da modelagem e, por sua vez, na escolha dos artefatos a serem gerados.

• A produção dos artefatos proporcionou um ganho imenso através uma aplicação prática dos conhecimentos teóricos adquiridos na disciplina.

• A documentação fornece as informações necessárias para as etapas subsequentes (implementação e testes).

• A expectativa é ver o produto se materializar a ser adotado como uma ferramenta de apoio ao teste de banco de dados.

Referências


• [MCT1999] Ministério da Ciência e Tecnologia/ Secretaria de Política de Informática (MCT/SEPING). Qualidade e Produtividade no Setor de Software Brasileiro. 1999.

• [SWE2004] Institute of Electrical and Electronics Engineers Computer Society. Guide to Software Engineering Body of Knowledge (SWEBOK). 2004. Disponível em: <http://www.swebok.org>. Acesso em: 22 de outubro de 2009.

• [IEEE1998] Institute of Electrical and Electronics Engineers Computer Society. IEEE Recommended Practice for Software Requirements Specifications. 1998Disponível em: <http://standards.ieee.org/reading/ieee/std/se/830-1998.pdf>

• Doug Rosenberg and Kendall Scott. Driving Design: The Problem Domain, Dr. Dobb´s site. June 29, 2001. <http://www.ddj.com/184414689>

• Craig Larman. Visualizing Concepts with a Domain Model. 2002.• http://laerer.rhs.dk/poulh/SoftwareDesignInt08/slides/DomainModel.ppt

• Craig Larman. Applying UML and Patterns. 2002. http://www.uml.org.cn/webForum/20040227Craig/Craig Larman´s Applying UML and Patterns.pdf



Espaço para perguntas



Obrigado!

dbcheck! uma ferramenta para teste de banco de dados apresentação dos artefatos produzidos do...

Documents