MODELAGEM DE SOFTWARE

Pessoal, como a UML tem uma importância impar para o desenvolvimento das disciplinas Analise e Modelagem e Engenharia de Software - disciplinas que ministro, resolvi em tempo, disponibilizar aos interessados, mais um material complementar de estudo: o conteúdo abaixo.

Não se esqueçam de dar ênfase nos estudos sobre histórico da UML, na especificação da UML 2, na classificação quanto a organização da UML 2 e na definição dos Diagramas da UML 2 pois o domínio desses assuntos podem ajuda-los nas avaliações. 

Bons estudos e boa sorte.

MODELAGEM DE SOFTWARE

O crescimento vertiginoso dos softwares nas ultimas décadas teve, crescimento foi acentuado na década de 1990 com o início da massificação da tecnologia onde o número de novos softwares aumentou e ocasionando o surgimento de uma variedade muito grande de formas de modelagem para os sistemas orientados a objeto. Todavia, para se construir um software de qualidade são necessários grandes esforços e muita experiência. A esse respeito Silva e Videira (2001) afirmam:

Fazer software não é uma tarefa fácil. Fazer software de qualidade é ainda mais difícil. A generalidade dos resultados obtidos ao longo do tempo têm sistematicamente apresentado padrões de baixa qualidade, de custos e prazos completamente ultrapassados. (SILVA; VIDEIRA 2001, p.27)

Nesse sentido, com a necessidade de criar processos padronizados para o desenvolvimento de software, que surgiu o UML por volta de 1996 unificando as notações e diagramas. A UML (Unified Modeling Language ou Linguagem Unificada de Modelagem, em português) é uma linguagem visual para a modelagem de sistemas orientados a objeto, permitindo uma melhor visualização padronizada de um sistema.

A esse respeito Silva e Videira (2001) definem:

A ênfase do UML é na definição de uma linguagem de modelação standard, e, por conseguinte, o UML é independente das linguagens de programação, das ferramentas CASE, bem como dos processos de desenvolvimento. (SILVA; VIDEIRA 2001, p. 143)

A evolução da UML desde a sua criação até o ano de 2002 pode ser melhor visualizado a partir da análise da Figura abaixo.

Evolução da UML. 

Fonte: Adaptado de http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/historia_uml/historia_uml.htm

Como principais objetivos da UML destacam-se: simplicidade, especificação, documentação e estruturação. 

Segundo Silva e Videira (2001, p.145) os tipos de diagramas da UML podem ser classificados, destacando-se: os Diagramas de Casos de Uso; Diagramas de Classes e de Objetos; Diagramas de Comportamento. Os Diagramas de Comportamento se subdividem ainda em Diagramas de Estados; Diagramas de Atividades e Diagramas de Colaboração. E, por fim os Diagramas de Arquitetura são classificados como Diagramas de Componentes e Diagramas de Instalação.

A especificação de UML é composta por quatro documentos: infra-estrutura de UML(OMG, 2006), superestrutura de UML (OMG, 2005c), Object Constraint Language (OCL) (OMG, 2005a) e Intercâmbio de Diagramas (OMG, 2005b). 

• Infra-estrutura de UML: O conjunto de diagramas de UML constitui uma linguagem definida a partir de outra linguagem que define os elementos construtivos fundamentais. Esta linguagem que suporta a definição dos diagramas é apresentada no documento infra-estrutura de UML.
• Superestrutura de UML: Documento que complementa o documento de infra-estrutura e que define os elementos da linguagem no nível do usuário.
• Linguagem para Restrições de Objetos (OCL): Documento que apresenta a linguagem usada para descrever expressões em modelos UML, com pré-condições, pós-condições e invariantes.
• Intercâmbio de diagramas de UML: Apresenta uma extensão do metamodelo voltado a informações gráficas. A extensão permite a geração de uma descrição no estilo XMI orientada a aspectos gráficos que, em conjunto com o XMI original permite produzir representações portáveis de especificações UML.

Quanto a organização dos diagramas da UML 2.0 pode-se classifica-los em Diagramas Estruturais, Diagramas de comportamento e diagramas de interação.  Veja a imagem abaixo:

Figura: Organização dos diagramas de UML 2

Diagramas Estruturais Diagrama de classes Diagrama de objetos Diagrama de componentes Diagrama de instalação Diagrama de pacotes Diagrama de estrutura

Diagramas Comportamentais Diagrama de Caso de Uso Diagrama de transição de estados Diagrama de atividade

Diagramas de Interação Diagrama de sequência Diagrama de Interatividade Diagrama de colaboração ou comunicação Diagrama de tempo Fonte: http://pt.wikipedia.org/wiki/UML

Thânia Clair de Souza Vargas (http://www.lavailama.com.br/arquivo/2.pdf) descreve cada um dos 13 diagramas na UML 2 e diz "Um diagrama é uma representação gráfica de um conjunto de elementos (classes, interfaces, colaborações, componentes, nós, etc) e são usados para visualizar o sistema sob diferentes perspectivas. A UML define um número de diagramas que permite dirigir o foco para aspectos diferentes do sistema de maneira independente. Se bem usados, os diagramas facilitam a compreensão do sistema que está sendo desenvolvido". 

Embora a UML tenha oferecido inúmeros e inquestionáveis benefícios procurando padronizar, simplificar, especificar, documentar e estruturar os processos de desenvolvimento de software, independente da linguagem de programação ou plataforma de desenvolvimento, a UML ainda deixa algumas lacunas como o problema relacionado à semântica, onde desenvolvedores distintos podem diagramar um mesmo sistema de formas diferentes. Na essência do princípio do UML, um mesmo sistema deveria ser diagramado de apenas uma forma, seja pelo desenvolvedor A, seja pelo desenvolvedor B. Todavia esse objetivo ainda não é possível para o UML atual. Talvez, pensando nisso os idealizadores do UML deixaram espaço para que no futuro a questão da semântica do UML seja resolvida

ENGENHARIA DE SOFTWARE

Somente na década de 1968 na  NATO Conference on Software Engineering (Conferência sobre Engenharia de Software da OTAN) a Engenharia de Software ganhou destaque e passou a ser um termo oficialmente usado. Historicamente os primeiros passos do que é entendido como Engenharia de Software na atualidade foi na década de 1960.

Nesse sentido, Mazzola (2010, p. 06) afirma que “engenharia de software é um conjunto de métodos, técnicas e ferramentas necessárias à produção de software de qualidade para todas as etapas do ciclo de vida do produto”. Já para Pressman (2006) a engenharia de software ocorre como resultado da engenharia de sistemas. A esse respeito ele diz:

Antes que o software possa ser submetido à engenharia, o “sistema” no qual ele reside deve ser entendido. Para conseguir isso, o objetivo geral do sistema deve ser determinado: o papel do hardware, software, pessoal, base de dados, procedimentos e outros elementos do sistema devem ser identificados; e requisitos operacionais devem ser conseguidos, analisados, especificados, modelados, validados e gerenciados. Essas atividades são à base da engenharia de sistemas. (PRESSMAN, 2006, p. 99).

Todavia, para a elaboração e implementação de um software ou programa de computador é necessário uma seqüência de práticas. Essa seqüência é conhecida como Processo de Software, ou Processo de Engenharia de Software e englobam as atividades de especificação, projeto, implementação, testes e caracterizam-se pela interação de ferramentas, pessoas e métodos.

Dentre várias possibilidades para o desenvolvimento de software, o desenvolvimento tradicional e o desenvolvimento ágil merecem atenção especial. Teles (2006, p.30) define “desenvolvimento tradicional” ou “clássico” quando os projetos de software são “baseados no modelo cascata” ou quando estão muitos próximos desse modelo como o RUP (Rational Unified Process). Esse modelo clássico foi o primeiro processo de desenvolvimento de software publicado (PRESSMAN, 2006).

Segundo Teles (2006) o modelo tradicional, sugere que a construção do programa de computador ou software deve seguir uma linha seqüencial ou fases: Análise onde o desenvolvedor procura buscar e entender as necessidades; Design é a projeção da arquitetura tendo como base a análise; Implementação que é quando a equipe define a arquitetura e as diversas partes do programa de computador; Teste que ajuda a identificar e verificar se o sistema atende aos requisitos específicos definidos pelo usuário; Implantação que é quando o sistema é colocado em operação; Manutenção que ocorre até o final da vida ou seja, até quando o software estiver em operação poderá sofrer alterações.

Para Sommerville (2003), como ilustrado na Figura 08 o ciclo de vida clássico do software tem cinco fases: definição de requisitos, projeto do software, implementação e teste unitário, integração e teste do sistema, operação e manutenção.

Fases do modelo de Desenvolvimento Clássico

Fonte: Adaptado de Sommerville (2003)

O Modelo em Cascata, também chamado de Ciclo de Vida Clássico, é um processo recomendado quando os requisitos de um problema são razoavelmente bem compreendidos, ou seja, quando o trabalho flui da comunicação até a implantação de um modo linear.O Modelo em Cascata, conforme ilustrado na figura 1, sugere uma abordagem sistemática e seqüencial para o desenvolvimento de softwares.
Fonte: http://julianakolb.com/2012/02/01/o-modelo-em-cascata/

Modelo em Cascata.

Fonte: PRESSMAN (2010).

Para o modelo de Desenvolvimento Ágil, Teles (2006, p. 31) refere-se ao desenvolvimento interativo ou espiral, de forma que todas as fases descritas no modelo cascata “sejam executadas diversas vezes ao longo do projeto, produzindo círculos”.

Trabalho Interdisciplinar Dirigido I

Atividade

Construir, individualmente, um artigo relacionando ao projeto de sua equipe tendo como base os documentos abaixo:

• artigo - As energias renová veis e o futuro
• artigo - Crise financeira energia e sustentabilidade no Brasil
• artigo - Um futuro com com energia sustentável iluminando o caminho

_____________________
Obs1. para baixar os artigos acima acesse a pasta da disciplina  Trabalho Interdisciplinar Dirigido I , clicando aqui.

Obs2. usar as normas da ABNT para produção de documentos acadêmicos
(veja mais aqui http://www.firb.br/abntmonograf.htm)

Obs3. Entregar a atividade por email ( marcosmoraisdesousa@gmail.com ) e impresso até: 20-04-2012.

Boa sorte e bons estudos.

Fiquem com Deus.

Sistemas de Informação é a profissão ideal para mim?

Sistemas de Informação

Bacharelado 

É a administração do fluxo de informações geradas e distribuídas por redes de computadores dentro de uma organização. O bacharel em Sistemas de Informação planeja e organiza o processamento, o armazenamento e a recuperação de informações e disponibiliza esse material para usuários. Cria, adapta e instala programas para facilitar as consultas e administra redes de computadores. Nas redes internas das empresas e outras instituições e na internet, monta e gerencia bancos de dados e ainda desenha páginas de sites, que devem ser funcionais e elegantes, trabalho que exige versatilidade e criatividade. Pode atuar em qualquer tipo de empresa, pública ou privada, de quase todos os setores - comércio, indústria ou de serviços. É fundamental que esse profissional tenha domínio do idioma inglês, já que praticamente todos os programas o utilizam.

O mercado de trabalho

Esse é um mercado que vive uma demanda constante em razão da popularização da internet e do uso crescente dos sistemas de tecnologia da informação. Apesar disso, os bacharéis sofrem com a falta de obrigatoriedade de diploma para exercer a profissão. "Qualquer bom autodidata pode enfrentar o mercado sem preocupação. Mas tanto ele como o profissional formado devem estar atentos à qualidade de sua mão de obra. O próprio mercado está regulando isso", alerta Marco Rodrigo Costa, coordenador do curso da PUC Minas. O bacharel encontra trabalho na área de suporte técnico (hardware e software), na criação e monitoramento de programas de segurança da informação, manutenção e monitoramento de bancos de dados até como analistas e programadores. Empresas especializadas como Totvs, IBM, Microsoft e Google são tradicionais empregadoras. "Mas as pequenas empresas, com projetos menores, também estão funcionando a pleno vapor e contratando. Elas atendem diretamente o cliente final onde um software será instalado, ou funcionam como prestadoras de serviço às grandes empresas", afirma o professor Costa. A Região Sudeste concentra as oportunidades de trabalho, mas Sul e Nordeste estão crescendo e demandando mais profissionais. 

Salário inicial: R$ 1.105,71 (analista de sistemas; fonte: Sindicato dos Empregados das Empresas de Processamento de Dados Rio de Janeiro).

O curso

A exigência básica para quem vai ingressar no curso é gostar muito de matemática. Cálculos e raciocínio lógico acompanham o aluno durante os quatro anos de curso. Entre as matérias específicas estão linguagem de programação, bancos de dados, sistemas de informação, redes de computadores e inteligência artificial. Estágio e um projeto de conclusão de curso são obrigatórios. Fique de olho: Algumas faculdades se voltam mais para os aspectos administrativos da profissão, outras, para os de computação. Outras instituições, ainda, oferecem licenciatura. Na Ufra, em Belém (PA), o curso é de Informática Agrária. 

Duração média: quatro anos. 

Outros nomes: Adm. de Sist. de Inf.; Análise de Sist.; Análise de Sist. (sist. de inf.); Análise de Sist. e Tecnol. da Inf.; Análise de Sist. e Tecnol. da Inf. (sist. e tecnol. da inf.); Análise de Sist. e Tecnol. da Inf. (tecnol. da inf.); Comput.; Comput. (sist. de inf.); Inf. - Sist. de Inf.; Inform.; Inform. (análise de sist.); Inform. Agr.; Sist. de Inf. (análise de sist.); Sist. de Inf. (gestão de redes); Sist. de Inf. (inform.); Tecnol. da Inf. (web designer).

O que você pode fazer

Desenvolvimento de softwares

Projetar e desenvolver sistemas, bem como tratar da estética e da funcionalidade de sites em empresas de todos os setores.

Ensino

Lecionar em escolas públicas ou particulares de Ensino Fundamental, Médio e técnico ou em faculdades.

Fluxo de informação

Modernizar e agilizar o processo de comunicação de uma empresa, criando, adaptando e instalando programas.

Logística

Planejar e administrar rotas, sistemas de armazenagem e o tempo de entrega de produtos.

Marketing e vendas

Gerenciar a comercialização de equipamentos, periféricos e softwares.

Modelagem

Construir modelos matemáticos que simulem situações reais, a fim de antever e prevenir problemas.

Suporte técnico

Fazer a manutenção de sistemas e de redes de computadores de uma organização.

Disponível em: http://guiadoestudante.abril.com.br/profissoes/ciencias-exatas-informatica/sistemas-informacao-602514.shtml   Acesso em: 12/04/2012 10h57

Introdução das premissas dos controles de versão

Introdução sobre algumas premissas sobre controles de versão. Muito útil para designers e iniciantes na área




Parece ser óbvio, mas muitos desenvolvedores desdenham de ter controle total sobre o código gerado no desenvolvimento. Muitos, por trabalharem sozinhos, entendem que não precisam manter um certo nível de organização do seu código exatamente porque talvez, somente eles, o verão.

Quem nunca ficou horas tentando debugar um código que você mesmo fez, mas não lembrava o que uma determinada função fazia… Esse código pode ter sido por você de madrugada, quando você estava pingando de sono, ou pior, bêbado… Vai saber…

Controlar seu código fonte deve ser uma premissa. Um princípio. Se você acha que o undo do seu editor predileto salva sua vida, imagina ter um undo do seu projeto inteiro. Imagine você ter a história de edição de cada um dos arquivos do seu projeto.

Os princípios abaixo servem para qualquer tipo de controle de versão que conhecemos hoje: GIT, SVN, Mercurial etc.

Branchs e trunks

A última revisão, a mais atual, normalmente é chamada de HEAD. Existem momentos onde teremos vários HEADs porque o projeto tem vários BRANCHES.

Um branch é uma cópia do projeto. Cada branch pode ser editado e evoluído independentemente.

Imagine que exista a versão de produção que é aquela que está no ar. É a versão o usuário está utilizando. É importante que nós não modifiquemos esta versão porque alguém pode commitar algo errado, quebrar tudo e o usuario reclamar. Por isso nós precisamos de outro ambiente, é aí que criamos um branch de desenvolvimento, onde podemos fazer o que quisermos ali, sem afetar o branch principal.


É muito útil criarmos novos trunks (tronco) quando precisamos fazer modificações drásticas de novas features, resolver bugs ou modificar layout.


Exemplo: imagine que você esteja trabalhando em uma nova feature, em um branch específico. O cliente liga e diz que encontrou um bug, originado de uma modificação feita na semana passada. Você sai do branch da nova feature e cria um novo branch. Este novo branch tem a cópia do código do branch de produção, que é o que o cliente está vendo. Você resolve o bug neste novo branch. Quando resolver o bug, você move as modificações deste branch para o branch de produção. Isso tudo sem ter que subir as modificações incompletas da nova feature que você estava trabalhando anteriormente.

Versionamento

Versionamento é uma das características mais básicas do controle de código. Quando comecei a desenvolver, normalmente eu trabalhava guardando pastas com nomes do tipo nomeDoProjeto-v1, nomeDoProjeto-v2 etc… Estas pastas guardavam apenas as versões com grandes modificações de projeto… algo como mudança geral de layout, uma feature importante ou algo do tipo. O problema são as pequenas edições… Quando juntamos as pequenas modificações, temos uma grande modificação. É muito provável que se você perder essa versão, você não se lembre de todas as pequenas modificações feitas e isso é um problemão.


Toda vez que o desenvolvedor termina uma determinada tarefa, ele geral um commit que por sua vez gera um ponto de referência, uma versão, daqueles arquivos modificados. Cada commit gera uma versão do seu código. A graça é que se você tem versões do código, você tem praticamente um undo gigante do seu projeto… Se depois de uma determinada modificação seu projeto começou a dar pau, você consegue entender com a história do seu versionamento – o famoso log – a partir de onde exatamente o problema foi iniciado.

Logs

Quando cada revisão é comitada, o desenvolvedor pode ou não adicionar uma mensagem explicando o que ele fez naquela tarefa. É importante que essa mensagem seja clara e rica em detalhes, mas não um texto gigante, apenas o suficiente para que você mesmo ou outras pessoas envolvidas entenda o que aquela submissão significa.

Diffs

Diffs são sensacionais. Imagine que você queira comparar duas versões de um mesmo arquivo para descobrir as linhas modificadas. Fazer um diff entre as versões do arquivo te possibilita encontrar exatamente onde está o erro e o melhor, quando juntamos com o Log, podemos saber exatamente o porque a pessoa incluiu aquela linha ou aquele código, e o melhor, quem fez aquela alteração.

Rollback

Mantendo uma história de commits, você tem pontos de volta na história do arquivo, possibilitando a facilidade de voltarmos para antes de alguma modificação. Você pode voltar a partir de um commit, por exemplo. Se o sistema ou o arquivo passou a dar problema depois de uma determinada revisão, é simples de você voltar o arquivo para a versão daquele determinado commit.

Edição multiusuário e merge

Isso é uma maravilha. Me lembro de equipes inteiras perdendo arquivos e partes de código porque dois membros abriam o mesmo arquivo para editar. Obviamente nunca, mas nunca dava certo. O que faziam que equipes inteiras criassem mecanismos da idade das pedras para avisar o resto do pessoal que determinado arquivo estava sendo usado. O trabalho em equipe remotamente nunca era possível. Com um controle de versão isso muda. Qualquer um pode editar qualquer arquivo a qualquer hora.

O sistema de controle de versão compara as modificações feitas no arquivo pelos dois (ou mais) desenvolvedores e junta os códigos automaticamente. Muito bonito, hein?

E quando os desenvolvedores modificam a mesma linha de código? Aí o controle de versão gera um conflito, esse conflito se resolve deve ser resolvido pelo desenvolvedor que executou o segundo commit. Funciona assim:

1. Dois desenvolvedores abrem o mesmo arquivo para editar.

2. Quando os desenvolvedores terminam, eles geram um commit. Se os desenvolvedores fizeram edições em partes diferentes do arquivo, por exemplo, um no topo do arquivo e o outro no final, o sistema junta os códigos fazendo um merge, e criando um arquivo atualizado com as duas revisões.

3. Se sistema percebe que os desenvolvedores fizeram as modificações na mesma linha, o sistema gera um conflito.

4. O conflito é resolvido pelo segundo desenvolvedor que comitar o código. Ou seja, o cara comitou a modificação dele primeiro que você. Quando você comitar a sua modificação, o controle de versão avisará que há um conflito em uma parte do seu código. O conflito é resolvido mostrando algo mais ou menos assim:

1 2 3 4 5 6 7

p { <<<<<<< HEAD:estilo.css    color: red; =======    color: blue; >>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:estilo.css }

A primeira linha mostra a sua linha. A segunda linha mostra a modificação do outro dev. Aquele hash maluco no final é a identificação do commit do outro dev.

Bom, nesses casos você precisa ver qual código é o correto, e isso as vezes inclui ir perguntar para o outro brother que diachos é aquela coisa que ele fez. Tudo na camaradagem… as vezes.

Concluindo

Estas são algumas premissas sobre controles de versão utilizados hoje em dia. Os controles de versão mais usados hoje são o GIT, SVN e Mercurial. Cada um deles tem comandos diferentes para lidar com as premissas acima e cada um deles faz o controle de sua forma particular. Mesmo assim todos trazem as vantagens que citamos no artigo. Mesmo que você trabalhe sozinho, é recomendado que você trabalhe com controle de versão. Assim você guarda seu projeto de forma segura e tem um histórico das suas modificações durante o tempo. Boas práticas, my friend.

Por Diego Eis

Diego Eis criou o Tableless para disseminar os padrões web no Brasil. Como consultor já treinou equipes de empresas como Nokia, Globo.com, Yahoo! e iG. É palestrante e empreendedor.

http://twitter.com/diegoeis/

Veja os outros posts de Diego Eis

PodCast sobre XP

Para um maior aprendizado, recomendo que escutem e relatem os principais pontos do PodCast sobre XP a seguir:

Introdução ao agilcast e apresentação do Manifesto Ágil. 20:25, 18,7 MB.
Episódio 02 - Uma visão geral de Programação eXtrema (XP). 20:48, 19,1 MB.
Episódio 03 - Testes automatizados. 15:39, 14,7 MB.
Episódio 04 - Bancos de dados ágeis e refatoração de bancos de dados. 14:09, 19,2 MB.
Episódio 05 - Ensino de XP na universidade: a experiência do Sistema Cigarra com o Ministério da Cultura (participação especial: Gilberto Gil). 16:22, 15,7 MB.
Episódio 06 - Entrevista com Eduardo Teruiya, gerente de projetos PMP, sobre gerenciamento de projetos usando XP. 26:42, 24,3 MB.
Episódio 07 - Respondendo perguntas dos Ouvintes. 33:46, 30,9 MB
Episódio 08 - Debate sobre Banco de Dados e CMM. 25:01, 22,9 MB
Episódio 09 - Apresentação da ferramenta Selenium. 10:18, 9,44 MB
Episódio 10 - Uma visão geral de Scrum. 23:38, 22,7 MB
Episódio 11 - Padrões para introduzir novas idéias. 25:52 22,8 MB

Bons estudos, fiquem com Deus e boa sorte.

Provas 2012.1 - UNIDADE I

Avaliações  

Caros colegas, está chegando a hora de nossas avaliações da Unidade I.
Fiquem alertas com relação as datas das avaliações indicadas abaixo.

Disciplina_________________________________ Data
Trabalho Interdisciplinar Dirigido I ______ avaliação contínua
Analise e Modelagem II ____________________ 10/04/2012
Introdução a Sistemas de Informação _______ 12/04/2012
Analise e Modelagem I _____________________ 13/04/2012
Engenharia de Software I __________________ 16/04/2012
Engenharia de Software II _________________ 18/04/2012

Importante: Não se prendam aos slides, estudem os assuntos pelos livros, internet, artigos e apostilas. O conteúdo das provas foi informado em sala de aula.

Não se prendam aos slides! Estudem!

Dicas e Assuntos para as avaliações:

Analise e Modelagem II ____________________ 10/04/2012

·      UML, Diagramas de sequencia, colaboração, estados, componentes, implantação, Processo de desenvolvimento de software e engenharia de Requisitos.

Introdução a Sistemas de Informação _______ 12/04/2012

·      Noções de sistemas de informação, princípios de sistemas de informação, Conceito de dados, informação e conhecimento, porque as empresas precisam de sistemas de informação, Teoria geral de Sistemas e Origem dos Sistemas, classificação dos Sistemas.

Analise e Modelagem I _____________________ 13/04/2012

·     UML, diagrama de caso de uso, diagrama de atividade e identificação de casos de uso.

Engenharia de Software I __________________ 16/04/2012

·     UML, Processos de Software, Engenharia de Requisitos, verificação e validação de software.

Engenharia de Software II _________________ 18/04/2012

·     Gestão de Qualidade, Processo de software, CMMI e MPS.BR,
ATIVIDADE 4 - Verificação de  Conhecimento ao MPS.BR e ATIVIDADE 5 - sobre MPS.BR e CMMI, Reuso de software, Reengenharia.

Fiquem com Deus, bons estudos e boa sorte.

Uma visão da técnica de teste de caixa branca

Pessoal, segue um artigo publicado no Devmedia sobre teste de software, escrito por Danilo Cardilli. Fiquem com Deus, bons estudos e boa sorte. 

Uma visão da técnica de teste de caixa branca

Introdução

A preocupação do engenheiro de sistema quando testa o software deve estar em encontrar alguma anomalia existente.

Os testes de software estabelecem os engenheiros de sistema pensar de maneira diferente do que estão freqüentemente acostumados, eles precisam elaborar casos de testes para descobrir defeitos no software (PRESSMAN, 2006).

A forma que a técnica de teste de caixa branca é aplicada torna se totalmente diferente da abordagem da técnica de caixa preta.

A técnica de teste de caixa branca é conhecida por vários nomes tais como teste estrutural e teste de caixa de vidro. O engenheiro de sistema realiza o teste direto no código fonte dosoftware. São determinados os dados de entrada para analisar a lógica do software(MYERS, 2004).

A desvantagem da técnica de caixa de caixa branca é que não analisa se a especificação esta certa, concentra apenas no código fonte e não verifica a lógica da especificação (LEWIS e VEERAPILLAI, 2005).

Na representação da figura 1 (um) demonstra a visão do engenheiro de sistema que vai realizar a técnica de teste de caixa branca, onde o quadrado representa o software e o desenho de dentro do quadrado demonstra como se fosse o código fonte que passará por teste. 

  

Figura 1- Representação da idéia da técnica de teste de caixa branca (BURNSTEIN, 2003).

Teste do caminho básico

O teste é uma técnica de caixa branca, onde calcula se a complexidade lógica do software e utiliza esta medida como base para descobrir os caminhos básicos do software e exercendo o teste de modo que todos os caminhos sejam efetuados (PRESSMAN, 2006; MCCABE, 1976).

Notação de grafo de fluxo

Para usar a técnica de teste de caixa branca o código fonte deve estar pronto, neste código fonte terminada, extrai se o grafo de fluxo que representa a lógica do código fonte (GAO, TSAO e WU, 2003).

O grafo de fluxo é um gráfico que demonstra a lógica do código fonte através de fios e ramos (MCCABE, 2010).

De acordo Pressman (2006) na construção do grafo de fluxo existem representações simbólicas correspondentes do grafo de fluxo. Usando o grafo de fluxo consegui visualizar os controles lógicos do software. Para cada círculos (ramos) demonstra uma ou varias linhas do código fonte e para cada setas (arestas) mostra o caminho ou caminhos que o código fonte pode fazer. Quando a existência de condições composta torna se mais difícil à construção do grafo de fluxo, encontra se quando ocorrem operações booleanas (ou, e, não-e, não-ou lógicos).

Todos os grafo de fluxo são construído através uma base principal de grafos tais como: seqüência, se, enquanto, até que e o caso (BURNSTEIN, 2003).   

Na representação da figura 2 (dois) demonstram conjuntos de notações bases de grafos que auxiliam para construções de grafos de fluxo.

Na representação da listagem 1 (um) demonstra um código fonte que realiza um calculo potencial.

Na demonstração da figura 3 (três) representa o grafo de fluxo do código fonte do calculo potencial representado na listagem 1 (um), que podemos ver que os ramos estão sendo representados pelos números que estão ao lado esquerdo do código fonte e as arestas são as direções possíveis.

Figura 2-Representação base para o grafo de fluxo (PRESSMAN, 2006).

Listagem 1-Representação do código fonte de calculo potencial.

/*1*/      import javax.swing.JOptionPane; 

/*1*/      public class PotencialTeste {

/*1*/      public static void main( String args[] )

/*1*/      {

/*1*/                      String PrimeiroNumero,SegundoNumero;

/*1*/                      float Base, Expoente,Resultado, Potencial;             

/*1*/                      PrimeiroNumero = JOptionPane.showInputDialog( "Entra com a base:" );

/*1*/                      SegundoNumero = JOptionPane.showInputDialog( "Entra com o expoente:" );

/*1*/                      Base = Integer.parseInt( PrimeiroNumero );

/*1*/                      Expoente = Integer.parseInt( SegundoNumero );

/*1*/                      if (Expoente < 0 ){

/*2*/                                      Potencial=0-Expoente;

/*3*/                      }

/*3*/                      else {

/*3*/                                      Potencial=Expoente;

/*4*/                      }

/*4*/      Resultado=1;

/*4*/                      while (Potencial !=0 ){

/*5*/                                      Resultado = Resultado * Base;

/*5*/                                      Potencial=Potencial-1;

/*5*/                      }

/*6*/                      if (Expoente<0 && Base !=0){

/*7*/                                                     Resultado=1/Resultado;

/*8*/                      }

/*8*/                      else{

/*8*/                      if(Base ==0){

/*9*/                                      JOptionPane.showMessageDialog( null, "A potencia é um valor finito " );}        

/*10*/                    }

/*10*/                    JOptionPane.showMessageDialog( null, "A potencia é " + Resultado, "Resultado", JOptionPane.PLAIN_MESSAGE );

/*10*/    System.exit( 0 );  

/*10*/    }

/*10*/    }

Figura 3-Representação do grafo de fluxo da listagem 1.

Caminho independente de programa

Seria algum caminho ao longo do código fonte que execute um novo comando e no grafo de fluxo seria uma nova área que não foi exercida antes (PRESSMAN, 2006).

Com esta ferramenta permite calcular um valor para os atributos do software e o calculo de complexidade ciclomática (V(G)) para o grafo de fluxo (BURNSTEIN, 2003).

V(G) é o calculo de complexidade da decisão estrutural do código fonte. É o numero de caminhos independentes possíveis e o numero mínimo de caminhos que pode ser testado para garantir que o código esteja livre de defeito (MCCABE, 2010). 

Conforme Pressman (2006) a V(G) podem ser calculadas de três formas:

   1. Pelos números de regiões do grafo de fluxo.

   2. V(G)= E – N + 2.

Onde

V(G) = e a complexidade ciclomática. 

G = representa o grafo de fluxo.

E = representa a quantidade de arestas no grafo.

N = representa a quantidade de ramos no grafo.

    

   3. V(G)= P + 1.

Onde

V(G) = e a complexidade ciclomática.

G = representa o grafo de fluxo.

P = representa a quantidade de ramos predicativos.

Através dos grafos de fluxo representados na figura 3 serão retirados os valores dos V(G) dessas formas:

   1. Cinco regiões.

   2. V(G) = 13 arestas – 10 ramos + 2 = 5.

   3. V(G) = 4 ramos predicativos + 1 = 5.

Por estas formulas calculada chegamos que o grafo de fluxo usado tem cinco caminhos diferentes para testar o código fonte por completo. Tais como:

       1. Caminho 1: 1-2-4-5-4-6-7-10.

       2. Caminho 2: 1-2-4-5-4-6-8-9-10.
       3. Caminho 3: 1-3-4-6-8-10.

       4. Caminho 4: 1-3-4-5-4-6-8-10.

        5. Caminho 5: 1-3-4-5-4-6-8-9-10.

  

Matrizes de grafos

A maneira para transforma o grafo de fluxo e executar os caminhos possíveis no grafo de fluxo de forma automática, é usada uma estrutura de dados. Uma matriz quadrada é usada e o tamanho é igual à quantidade de ramos encontrados no grafo de fluxo, onde cada linhas e colunas da matriz são correspondentes às quantidades de ramos (PRESSMAN, 2006).

Na demonstração da figura 4 (quatro) representa a utilização da matriz de grafos para um grafo de fluxo qualquer. As linhas e colunas são as mesmas quantidades de ramos e as arestas que são representadas as ligações entre os ramos por letras.  

Figura 4-Representação da matriz de grafos (PRESSMAN, 2006).

 

Teste de estrutura de controle

Com o uso do teste de estrutura de controle serve como um complemento para o teste do caminho básico e assim garantir uma alta qualidade para técnica de caixa branca (PRESSMAN, 2006).

Teste de condição

Este tipo de teste são feitos nas condições booleana simples ou composto para analisar os desvios possíveis existentes, onde o teste examina os lados positivos ou falsos da condição booleana (PEZZÈ e YOUNG, 2008).

Uma condição encontra se errada das seguintes formas:

   1. Erros de operador booleano,

   2. Erros de variáveis booleana,

   3. Erros de parêntese booleano,

   4. Erros de operador relacional e

   5. Erros de expressão aritmética (PRESSMAN, 2006).

Teste de ciclo

Os ciclos têm uma utilização freqüente na estrutura de controle. Com isso muitos erros são encontrados nas construções deles (BURNSTEIN, 2003).

O teste de ciclo é uma técnica de caixa branca que concentra se na validação da construção de ciclo (PRESSMAN, 2006).

São classificados quatro tipos de ciclos como: ciclos simples, concatenados, aninhados e desestruturados (PRESSMAN, 2006; BEIZER, 1990).

o    Ciclos simples. O teste é aplicado em no ciclo com o tamanho n de modo que:

1.    Pule o ciclo completamente;

2.    Uma passagem pelo ciclo;

3.    Duas passagens pelo ciclo;

4.    k passagens pelo ciclo em que k< n.

5.    n -1 passagens pelo ciclo;

6.    n +1 passagens pelo ciclo (BURNSTEIN, 2003).

o    Ciclos concatenados. Utiliza no ciclo concatenado a abordagem de ciclos simples para o caso dos ciclos forem independente um do outro, caso contrario é recomendado o uso da abordagem de ciclos aninhados (PRESSMAN, 2006).

o    Ciclos aninhados. Para esta abordagem testa se os ciclos mais internos que são aplicados à abordagem de ciclos simples e os outros ciclos externos permanecem com o valor mínimo (PRESSMAN, 2006; BEIZER, 1990).

o    Ciclos desestruturados. Sempre que ocorrer este caso deve se refazer o ciclo para pensar no uso da construção da programação estruturada (PRESSMAN, 2006).

Na demonstração da figura 5 (cinco) representam os quatros tipos dos ciclos.

Figura 5-Classificações de ciclos existentes (PRESSMAN, 2006).

Teste de decisão

Conseguir a cobertura inteira dos comandos sem executar todos os desvios existentes do código fonte. E conseguir com um único caso de teste a adequação de desvio para que o desvio do código fonte seja exercido (PEZZÈ e YOUNG, 2008).

Teste de fluxo de dados

Conforme Pressman (2006) o teste de fluxo de dados descobre os caminhos para que teste o código fonte, selecionar as definições (def) e uso das variáveis do código fonte. Para demonstrar o fluxo de dados de cada comando do código fonte é representada por números.

Esta abordagem de teste de software demonstra que na def das variáveis ao longo do grafo de fluxo localiza se caminhos simples. Assim torna o teste de caixa branca mais poderoso (Moreira Filho e Rios, 2003).

Com este teste de software verifica se o comportamento das variáveis ate localizar algum defeito que tenha passado despercebido e a propagação dele no código fonte (PEZZÈ e YOUNG, 2008).

As principais categorias do fluxo de dados são:

o    Bloco básico ou ramos,

o    Todos os usos,

o    Todos usos computacionais (c-uso),

o    Todos usos predicativos (p-uso) e

o    Caminho livre de def (Todos-du-Caminhos).

O bloco básico ou ramo são trechos de códigos fonte que são executados todos de uma vez. Todos o c-uso, todos o p-uso e todos usos são categorias mais mencionadas do fluxo de dados (PETERS e PEDRYCZ, 2001).

Todos os usos solicitam todas def de variáveis, seus p-uso e seus c-uso que sejam realizados no caso de teste pelo menos uma vez pelo caminho livre de def. Toda def solicita que cada def seja exercida pelo menos uma vez, não implicam os c-uso e os p-uso (MOREIRA FILHO e RIOS, 2003). 

Todos os usos c-uso seriam quando uma variável utilizada na def troca o seu valor ou como uma produção de valor. Todos os p-uso são utilizados para definir o verdadeiro ou falso de um valor predicativo e um predicativo associado para um limite (GAO, TSAO e WU, 2003).

Os Todos-du-Caminhos solicitam que todas as def de variáveis e subseqüências como c-uso e p-uso das variáveis sejam executadas por todos os caminhos livres de def e de laços (MOREIRA FILHO e RIOS, 2003).    

Na representação da figura 6 demonstra como usar o teste de fluxo de dados em um grafo de fluxo.

Figura 6- Representação do Teste de fluxo de dados.

Conclusão

Esta técnica de teste de software embora não é utilizada com freqüência, porém analisa o funcionamento do código fonte de maneira gráfica e possibilita ver a trajetória que o código fonte realiza. A aplicação desta técnica é interessante quando os códigos fonte possuem muitas condições.      

Para ver mais, visite o http://www.devmedia.com.br/uma-visao-da-tecnica-de-teste-de-caixa-branca/15610