Alexandre Correa, José Ricardo Xavier, Cláudia Werner 1 – Introdução
Fundamentalmente, o projeto de software envolve uma sistemática de decomposição da solução, a começar pela descrição em mais alto nível dos principais elementos do sistema e, em seguida, criando uma visão mais detalhada de como as características e funções deste sistema deverão estar integradas. Projetar software orientado a objetos é uma tarefa difícil, e projetar software orientado a objetos reutilizável e flexível é ainda mais difícil. Este trabalho apresenta mecanismos de suporte à representação, sugestão e identificação de conhecimentos obtidos a nível de projeto, no ambiente de desenvol- vimento de software
[...]
2 – Representação do Conhecimento de Projeto
Projetistas de sistemas de software vêm, ao longo dos anos, reconhecendo a importân- cia de se representar e explorar o conhecimento obtido durante a construção de siste- mas. Uma das formas consiste no reconhecimento e utilização de boas práticas, idéias e soluções já aplicadas em situações de sucesso e fracasso em projetos de software, como heurísticas de projeto, padrões e anti-padrões.
2.1 – Heurísticas de Projeto
Uma heurística de projeto é uma diretriz resultante de conhecimento e experiência que serve como um conselho para tomada de decisões de projeto, sendo de grande im- portância no sentido de guiar o projetista na elaboração de boas soluções ao longo do desenvolvimento. É importante notar que uma heurística não deve ser vista como uma regra inviolável que deva ser seguida em todas as circunstâncias. Possíveis violações a estas heurísticas devem ser consideradas como avisos ou indicadores de que alguma decisão de projeto pode ter sido tomada incorretamente.
2.2 – Padrões
Podemos pensar em um padrão como a reutilização da essência de uma solução para determinados problemas similares. Sintetizando as definições encontradas na literatura, podemos dizer que um padrão resolve um problema recorrente, em um determinado contexto, fornecendo uma solução que comprovadamente funcione, além de informar os resultados e compromissos da sua aplicação, e subsídios para que seja possível adap- tar esta solução a uma variante do problema. Ao contrário das heurísticas, os padrões disponíveis na literatura estão descritos de forma explícita e organizada. Embora exis- tam várias formas de descrição de um padrão, de modo geral, a descrição de um padrão deve conter as seguintes informações: Nome do padrão, o problema, o
contexto, a solução, as consequências, o uso conhecido e os padrões que são relacio- nados. Segundo Buschmann, quanto maior o número de padrões em um sistema de padrões, maior é a dificuldade de entendê-los e utilizá-los.
[...]
2.3 – Anti-Padrões
Um anti-padrão pode resultar da falta de conhecimento de uma solução mais adequada, ou ainda da aplicação de um padrão (teoricamente, uma boa solução) no contexto in- correto. Os anti-padrões descrevem soluções Inadequadas para um problema que resul- ta em uma situação ruim, ou então descrevem como sair de uma situação ruim e chegar a uma boa solução. A presença de “bons” padrões em um sistema bem sucedido pode não ser suficiente. É preciso mostrar que estes padrões geralmente não ocorrem em sistemas mal sucedidos, e que determinadas construções inadequadas (anti-padrões) encontradas em sistemas mal sucedidos geralmente não estão presentes em sistemas bem sucedidos.
[...]
3 – Suporte a Padrões no Ambiente Odyssey
A partir da representação do conhecimento de projeto através dos conceitos descritos na seção anterior, foi implementado um conjunto de mecanismos em um ambiente de desenvolvimento de software visando apoiar a utilização deste conhecimento durante o projeto de software orientado a objetos. Nesta seção, apresentamos detalhes sobre a implementação e funcionamento destes mecanismos.
Instanciação de Padrões de Projeto
O mecanismo de instanciação de padrões de projeto procura oferecer ao usuário proje- tista uma forma de replicar uma solução com base em um padrão identificado para uma situação adequada ao seu projeto em desenvolvimento. Para isso, o padrão, conforme representado no catálogo, é transportado para o diagrama de classes do projetista. Este transporte é caracterizado pela cópia da estrutura de classes e relacionamentos que cor- respondem ao padrão.
[...]
3.3 – Seleção de padrões arquiteturais
Um dos aspectos críticos de se desenvolver software com ênfase arquitetural é a seleção de um estilo, ou padrão arquitetural [9]. Neste sentido, identificamos a oportunidade de apoiar a seleção de padrões arquiteturais utilizando uma abordagem orientada pela necessidade de se obter determinadas características de qualidade para o software a ser produzido. Estas características são baseadas na norma ISO/IEC 9126-1.
O suporte a padrões do ambiente Odyssey oferece um mecanismo para realização de uma comparação entre os requisitos de qualidade arquiteturais identificados para a aplicação e os obtidos pela utilização de cada padrão catalogado, com a intenção de se chegar a um indicador de padrão que melhor represente uma solução para o atendi- mento aos requisitos esperados.
[...]
3.4 – Deteção de Padrões e Anti-Padrões
O suporte a padrões do ambiente Odyssey fornece um mecanismo de detecção de construções boas, assim como ruins. O principal objetivo desta detecção é fornecer su- porte para a reestruturação de sistemas orientados a objetos legados, e também para a avaliação de sistemas ainda em desenvolvimento. A detecção de construções típicas (padrões) permite que o projeto do sistema seja entendido em um nível maior de abs- tração, além de permitir uma avaliação sobre a utilização destes padrões no projeto.
Análise e Projeto de Sistemas – Como analisar, planejar, desenvolver e implementar sistemas de informação
Lucas Nogueira Padrão Editora: Viena
Sinopse: Para que um software atinja seu objetivo fi nal, são necessárias diversas etapas que são analisadas e discutidas neste livro. A análise e projeto de sistemas consiste em um extremo cuidado e infi nito esmero para chegar a um sistema de qualidade.
O livro Análise e Projeto de Sistemas – Como analisar, planejar, desenvolver e implementar sistemas de informação foi escrito de forma clara e objetiva. Entre os tópicos abordados estão: a análise de sistemas, ciclo de vida, metodologia de desenvolvimento, diagramas, projeto e implementação, análise de requisitos do sistema, tipos de objetos e métodos, herança e polimorfi smo, administração de banco de dados, modelagem de processamento de dados, redes e tecnologias de transmissão, sistemas distribuídos, engenharia de software e seus princípios, metodologias ágeis de desenvolvimento de softwares, testes de software e de validação, gerência de projetos PMBOK, gerência de projetos de TI. No fi nal do livro ainda temos um capítulo com exercícios para treinar os conhecimentos adquiridos.
Apresentação: Processo de Comunicação. Para saber mais sobre Processo de Comunicação, acesse o vídeo produzido pela profa. Daniela Karine Ramos. Dicas valiosas sobre comunicação.
Não perca!
Em: <http://www.youtube.com/watch?v=_C3AmzKpJbQ&feature=player_embedded> Acesso em: 20 de out. 2015.
Material Complementar Apresentação: Como trabalhar com testes de software? Nesse vídeo é dado algumas dicas
do por que escolher a área de teste de software que pode ser uma boa escolha para começar a trabalhar na área de TI, ou mesmo como uma opção para buscar um nova oportunidade do mercado de trabalho, visando crescimento na carreira profissional.
Em: <https://www.youtube.com/watch?v=rL48FS-99ac> Acesso em: 20 de out. 2015.
Apresentação: Atividades básicas ao processo de desenvolvimento de Software. Esse artigo demonstra as principais atividades básicas, comuns aos processos de desenvolvimento de software, seus conceitos relevantes, utilizados em organizações que buscam um padrão de qualidade no desenvolvimento de suas aplicações. Recomendo que tire um tempinho e leia as informações contidas neste link para complementar seus estudos. Acesse o site e leia o artigo na íntegra.
Em: <http://www.devmedia.com.br/atividades-basicas-ao-processo-de-desenvolvimento-de- software/5413#ixzz3p8FdCqmy>. Acesso em: 17 de maio 2016
2006.
DANTAS, A. R., VERONESE, G.; CORREA, A.; XAVIER, J. R.; WERNER, C. Suporte a Padrões no Projeto de Software. Caderno de Ferramentas do XVI Simpósio Brasileiro de Engenharia de Software. Gramado, 2002.
FALBO, R. de A. Projeto de Sistemas de Software: Notas de aula. Vitória: - Universi- dade Federal do Espírito Santo, 2012
MOLINARI, L. Testes de Software: Produzindo Sistemas Melhores e Mais Confiáveis. São Paulo: Érica, 2003.
PAULA FILHO, W. de P. Engenharia de Software: fundamentos, métodos e padrões. São Paulo: Editora LTC, 2009
PRESSMAN, R. Engenharia de Software. 7. Ed. Porto Alegre: AMGH, 2011.
REZENDE, D. A. Engenharia de Software e Sistemas de Informação. Rio de Janei- ro: Editora Brasport, 2005.
RIOS, E. Caratê Aplicado ao Teste de Software. Niterói: Imagem art Studio, 2008. RIOS, E.; MOREIRA, T. Teste de Software. 3 ed. Rio de Janeiro: Alta Books, 2013 SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Prentice Hall, 2011. WEBER, K. C., ROCHA, A. R. C.; MALDONADO, J. C. Qualidade de Software – Teoria e Prática. São Paulo: Prentice Hall, 2001.
VALENTIM, Lucio Gerônimo; DIAS, M. M.; SANTOS, R. C. S. P. Questões importantes na implementação de software. Revista Tecnológica. v. 17. Maringá: 2008, p. 73-80. Disponível em: <http://periodicos.uem.br /ojs/index .php/ RevTecnol/article/down- load /7985/5161>. Acesso em: 25 mar. 2016.
1. Após o levantamento dos requisitos de software, é iniciada a fase de Projeto de software.
2. Alternativa A - V, F, V, V.
3. Projeto: a fase de Projeto de Software faz parte dos processos da Engenharia de software, tendo início após a Análise de Requisitos ter sido levantada e seu objetivo é definir uma estrutura que possa ser implementada em um produto de software e que atenda os requisitos especificados para ele na análise.
Implementação: na fase de Implementação de Software são detalhados os com- ponentes que foram descritos na fase de projeto, como os códigos fonte que serão usados na linguagem de programação.
Teste: a fase de Teste de Software é uma atividade que deve ocorrer paralela ao desenvolvimento e conduzida nas diversas fases do processo de desenvolvi- mento de software.
4. Os grandes problemas de confiabilidade de software podem quase sempre ser associados a defeitos encontrados na fase de projeto ou de implementação, onde as falhas são de ambos, tanto do cliente, quanto de quem desenvolve o software.
5. Teste.
6. D - Projeto, implementação, teste
7. Projeto: o profissional responsável é conhecido como o Arquiteto de Software, que possui experiência como programador e possui amplos conhecimentos so- bre a Gerência de Projetos.
Implementação: o profissional responsável por esta etapa é o Programador ou Desenvolvedor, com um bom raciocínio lógico, gosta de resolver problemas. Teste: o profissional responsável por esta fase é o Testador, que pode ser conhe- cido por outras variações como: Gerente de Testes, Projetista de Testes, Analista de Testes entre outros nomes.
UNID
ADE