Vous êtes sur la page 1sur 52

LabVIEW

Manual Técnico e Manual de Exercícios de Engenharia de Software


Versão 4.0.4, Agosto de 2014.
Software Engineering Technical Manual and Exercises 2014

CONTEÚDO
Introduction to Software Engineering ..........................................................................................................................2
Software Configuration Management ..........................................................................................................................3
Exercise 1: Creating a SVN Repository and Adding Code* .........................................................................................4
Exercise 2: Checking Out Code and Commiting Changes ...........................................................................................9
Exercise 3: Tracking Changes to VIs Using SCC .........................................................................................................14
Tracking Requirements Coverage ..............................................................................................................................18
Exercise 4: Tracing Code to Requirements Documents.............................................................................................19
Performing Code Reviews ...........................................................................................................................................26
Exercise 5: Analyzing Code Quality............................................................................................................................27
Advanced Debugging and Dynamic Code Analysis....................................................................................................31
Exercise 6: Debugging Unexpected Behavior ............................................................................................................32
Testing and Validation ................................................................................................................................................38
Exercise 7: Unit Testing and Validation of Code ........................................................................................................39
More Information ........................................................................................................................................................51

Para fazer o download deste manual e da última versão do código do LabVIEW usado como referência nos
exercícios, acesse: http://bit.ly/lv_swe (http://bit.ly/lv_swe) Field Code Changed

Confira abaixo os programas de software usados neste manual.

Software da NI Software Externo


 NI LabVIEW 2015 (Professional Development  Pacotes de VIs:
System) o jki_tool_tortoisesvn
 NI Requirements Gateway 14.0 o viewpoint_tsvn_toolkit
 NI VI Analyzer Toolkit 14.0
 NI LabVIEW Desktop Execution Trace Toolkit  Controle do Código Fonte da subversão:
14.0 http://tortoisesvn.net/downloads.html
 NI LabVIEW Unit Test Framework Toolkit 14.0

1
Software Engineering Technical Manual and Exercises 2014

INTRODUÇÃO À ENGENHARIA DE SOFTWARE


O LabVIEW é um ambiente de projeto de sistemas gráficos que contém todas as ferramentas que engenheiros e
cientistas precisam para criar alguns dos sistemas mais avançados tecnologicamente e desafiantes de hoje.
Conforme a complexidade das aplicações no LabVIEW aumenta, se torna cada vez mais importante que seja
aplicada uma abordagem de desenvolvimento disciplinada e estruturada para oferecer aplicações profissionais de
alta qualidade.

Para essas aplicações, é preciso seguir um processo de programação regimentado e estruturado para garantir
qualidade e confiabilidade de todo o sistema. Este manual irá explicar e analisar o ciclo de vida de algumas
ferramentas que podem melhorar e automatizar as práticas comuns da engenharia de software.

2
Software Engineering Technical Manual and Exercises 2014

GERENCIAMENTO DA CONFIGURAÇÃO DO SOFTWARE


Muitos desenvolvedores já vivenciaram a frustração de trabalhar em ambientes não gerenciados, onde as pessoas
substituem as alterações umas das outras e não conseguem monitorar revisões. O gerenciamento de uma grande
quantidade de arquivos ou de vários desenvolvedores é um desafio em qualquer linguagem. Na verdade,
geralmente é um desafio gerenciar uma aplicação mesmo que haja apenas um desenvolvedor trabalhando em
uma pequena à média aplicação. O desenvolvimento de projetos de grande porte depende de ferramentas de
gerenciamento de configuração para satisfazer os seguintes objetivos:

1. Definir um repositório central de código


2. Gererenciar vários desenvolvedores
3. Detectar e solucionar colisões de códigos
4. Monitorar alterações comportamentais
5. Identificar alterações e quem as fez
6. Garantir que todos tenham a última cópia do código
7. Fazer o backup de versões antigas do código
8. Gerenciar todos os arquivos, não apenas o código fonte

O SCC (controle de código fonte) talvez seja a ferramenta SCM mais importante e mais conhecida. No entanto,
além de muitas ferramentas SCC de terceiros, veremos que existe uma quantidade de ferramentas adicionais
disponíveis no ambiente de desenvolvimento do LabVIEW que são projetadas para ajudar nesses objetivos.

Estabelecer diretrizes para armazenar e gerenciar arquivos exige previsão de como a aplicação será estruturada,
como as funções serão divididas e os tipos de arquivos, além do código fonte, que serão importantes serem
controlados. Dedique tempo para tomar decisões sobre como as funções serão divididas entre o código e para
trabalhar com os desenvolvedores sobre os locais de armazenamento de arquivo e de recursos ou arquivos
adicionais que eles precisarão que funcionem adequadamente.

O controle do código fonte oferece uma interface para enviar e recuperar as alterações de um repositório
centralizado onde o código está armazenado. Esse repositório deve ser configurado de forma que todos os
membros da equipe tenham acesso regular para recuperar atualizações de outros membros da equipe e para
enviar seus trabalhos. Além de simplificar o acesso ao código, o repositório contém todas as revisões enviadas do
código fonte, possibilitando voltar a uma versão anterior e comparar as alterações que foram feitas ao longo do
tempo. Isso é muito valioso em situações onde as alterações apresentam um comportamento inesperado ou
indesejável que exige a identificação da raiz do problema.

Um repositório centralizado também garante que alterações conflitantes possam ser detectadas e tratadas.
Esses conflitos geralmente ocorrem quando duas ou mais pessoas fazem modificações no mesmo código fonte ou
arquivo. O controle do código fonte é projetado para detectar e sinalizar esses problemas e pode passar por essa
etapa incorporando essas alterações.

3
Software Engineering Technical Manual and Exercises 2014

EXERCÍCIO 1: COMO CRIAR UM REPOSITÓRIO SVN E ADICIONAR UM CÓDIGO

OBJETIVO
Esse exercício explicará os conceitos necessários, fundamentalmente mais importantes, para usar o controle do
código fonte com o sistema LabVIEW.

CENÁRIO
Queremos armazenar nosso código fonte em um repositório da subversão para monitorar revisões, identificar
alterações e compartilhar o código.

DESCRIÇÃO
Iremos criar um novo repositório da subversão, adicionar nosso projeto do LabVIEW e, em seguida, verificar o
código de saída para iniciar a programação.

CONCEITOS ABORDADOS
 Como criar um repositório da subversão
 Como adicionar um código

CONFIGURAÇÃO (SIGA AS INSTRUÇÕES ABAIXO NA ORDEM APRESENTADA)


 Confira se o LabVIEW 2014 (ou versão mais recente) está instalado.
 Verifique se o TortoiseSVN está instalado.
o Se já estiverem instalados, clique com o botão direito no menu no Windows Explorer que terá o
‘TortoiseSVN’ listado com um submenu da função disponível. Verifique se você tem uma
exibição semelhante ao clicar com o botão direito em qualquer local dentro do Windows
Explorer.

o Se não estiverem instalados, faça o download e instalação a partir da web. Reinicie seu
computador após essa operação.
 Faça a instalação do Viewpoint’s Free TortoiseSVN Toolkit a partir do LabVIEW Tools Network, acesse
ni.com/labviewtoolsnetwork (você precisará reiniciar o LabVIEW após a instalação desse produto).

4
Software Engineering Technical Manual and Exercises 2014

5
Software Engineering Technical Manual and Exercises 2014

INSTRUÇÕES
1. Abra uma cópia do código fonte do projeto que será adicionado ao repositório do controle do código
fonte.
a. Na tela de inicialização do LabVIEW, clique em Create Project. Filtre através de Demonstrations
à esquerda desse diálogo, selecione Software Engineering Tools e clique em Next.
b. Selecione um local temporário no disco para criar esse projeto, tal como
'…Desktop\Software Engineering Tools'.
2. Familiarize-se rapidamente com o que o sistema faz.
a. Quando o projeto estiver criado, abra o arquivo do projeto e o painel frontal do main.vi. Essa
aplicação simula um dispositivo que calcula a pressão arterial através da ação de um transdutor
de pressão. Em vez de conectar o hardware, essa versão irá calcular e taxa da pressão sistólica à
diastólica com base em dados registrados do paciente. Para calcular esse valor, a aplicação usa
uma máquina de estados bem simples que inclui aquisição básica (neste caso, de um arquivo),
filtragem simples e processamento de sinais. Clique na seta de execução para iniciar a
aplicação.
b. Como não temos o hardware próprio, será solicitado que você grave os dados antecipadamente.
Selecione ‘BP DATA exp 3 123x76 62 BPM'
c. Clique em ‘Take Blood Pressure’ para começar a adquirir os dados do paciente (será simulado o
tempo de aquisição - para ir para o próximo passo, desative o Booleano ‘Timing’). Observação:
esse controle está escrito incorretamente de forma intencional, pois detectaremos isso mais adiante
em uma etapa de análise.
d. A tela final deve exibir os resultados da análise conforme exibido abaixo:

a. Feche o projeto – essa será a fonte que alocaremos para o repositório nos próximos passos. Se
você fez alguma alteração, não salve.

3. Crie um repositório da subversão local (isso só será necessário se você não tiver ainda um repositório que
planeje usar). Por uma questão de simplicidade, nesse exercício, recomendamos que você coloque o
repositório no diretório principal: C:\. Observação: Se estiver usando um repositório da subversão para
desenvolvimento, é altamente recomendado que o repositório seja criado e armazenado em um servidor
remoto no qual todos os membros tenham acesso.

6
Software Engineering Technical Manual and Exercises 2014

a. Navegue até o diretório principal do seu computador e crie uma nova pasta chamada ‘Repo.’
Quando for criada, o caminho deve ser C:\Repo
b. Abra esse diretório e expanda o TortoiseSVN (clique com o botão direito na janela do Explorer) e
selecione Create Repository Here. Essa operação cria uma base de dados onde sua fonte será
armazenada e gerenciada.

c. Abra o navegador do repositório para visualizar esse repositório na interface do TortoiseSVN.


i. Opção 1: As versões mais recentes do TortoiseSVN devem exibir uma notificação para
abrir o navegador do repositório após concluir a etapa anterior. Se for solicitado,
selecione Start Repobrowser (conforme ilustrado abaixo).

ii. Opção 2 (para versões mais antigas do Tortoise): Se você não receber uma
notificação, abra o navegador do repositório a partir do TortoiseSVN>, clique com o
botão direito selecionando TortoiseSVN>Open repo-browser. Quando for solicitado,
insira file:///C:/Repo e clique em OK. Field Code Changed

7
Software Engineering Technical Manual and Exercises 2014

d. O navegador do repositório deve exibir agora os conteúdos do repositório recém-criado, que


estará vazio (conforme ilustrado abaixo). É aqui que adicionaremos nossos arquivos no próximo
passo.

OBSERVAÇÃO: Você nunca modificará diretamente os conteúdos do ‘C:\Repo’ no disco (ex: usando o Windows
Explorer). Essa é a base de dados da subversão – você usará o cliente TortoiseSVN para enviar e receber códigos
para a base de dados.

4. Adicione suas aplicações do LabVIEW ao repositório da subversão (se você pulou o passo anterior,
verifique se você abriu o navegador do repositório TortoiseSVN e indicou o local adequado).
a. Clique com o botão direito no painel direito do navegador do repositório e selecione 'Add
folder…' para importar o código fonte.
b. Selecione a localização do código fonte a ser adicionado '…Desktop\Software Engineering
Tools’ (se você seguiu a recomendação no primeiro passo) e clique em Select Folder. Quando for
solicitado para inserir uma mensagem de registro, digite Adding Files to the Repository e clique
em OK. O Tortoise irá carregar por alguns segundos enquanto esses arquivos são importados
para a base de dados.
c. Verifique se o navegador do repositório contém agora os arquivos fonte clicando na pasta
recém-criada. O navegador deve exibir agora os conteúdos do projeto que estão armazenados
no repositório da subversão.

d. Retorne à localização original no disco '…Desktop\Software Engineering Tools.’ Como os


arquivos estão adicionados no disco para o repositório, você pode excluir com segurança a pasta

8
Software Engineering Technical Manual and Exercises 2014

no disco e seu conteúdo, uma vez que a cópia desses arquivos fica agora no repositório da
subversão.

EXERCÍCIO 2: ALTERAÇÕES E VERIFICAÇÃO DO CÓDIGO

OBJETIVO
Esse exercício irá familiarizar os novos usuários do SCC com a prática de verificar o código e de fazer atualizações
regulares.

CENÁRIO
Um repositório da subversão foi criado e contém o código que precisamos. Iremos verificar uma cópia
localmente, começar o desenvolvimento e confirmar as alterações conforme elas forem sendo feitas.

DESCRIÇÃO
Ao usar a subversão para 'verificar o código', faça um download da cópia do código na sua máquina de
desenvolvimento local. Diferentemente de outras ferramentas, você não precisa verificar o código toda vez que
quiser fazer uma modificação. Uma vez verificado, os desenvolvedores terão todos os arquivos localmente. Se
fizerem alguma alteração, o arquivo terá um ícone vermelho sobreposto até que a alteração seja atribuída ao
repositório. Se outro desenvolvedor precisar dessas últimas alterações, ele simplesmente executará a operação
Update no arquivo que contiver a pasta.

Observe que algumas equipes de desenvolvedores optarão por bloquear os arquivos para evitar que várias
pessoas modifiquem o mesmo arquivo ao mesmo tempo. Esse comportamento não será abordado.

CONCEITOS ABORDADOS
 Verificação do seu código
 Alterações
 Verificação de um registro de revisões
 Reversão de alterações

9
Software Engineering Technical Manual and Exercises 2014

INSTRUÇÕES
1. Verifique uma instância controlada da versão da aplicação.
a. Use o Windows Explorer para navegar até o local da pasta onde você gostaria de verificar uma
instância dessa aplicação - esse local será onde o desenvolvimento é feito após o código ser
verificado. É recomendado que você crie uma nova pasta no Desktop chamada Software
Engineering Tools.
b. Dentro da pasta, clique com o botão direito para exibir o menu TortoiseSVN e selecione SVN
Checkout…

c. Se você utilizou os locais do diretório e os nomes dos arquivos no Exercício 1, a localização do


repositório será file:///C:/Repo.

d. O diretório Checkout deve ser configurado para o local onde você clicou. Verifique se a URL do
repositório está configurada para o local correto – se usar defaults, será file:///C:/Repo.
e. Clique em OK. O Tortoise fará o download de uma cópia local dos arquivos fonte que será uma
versão gerenciada pela subversão.
f. Após o término da verificação, veja se os arquivos foram verificados adequadamente e se estão
sendo monitorados pela subversão. Se essa operação for finalizada com sucesso, os arquivos

10
Software Engineering Technical Manual and Exercises 2014

terão sobreposições do ícone de status no Windows Explorer marcados na cor verde (conforme
ilustrado).

g. Abra a aplicação no LabVIEW clicando duas vezes no Software Engineering Tools.lvproj.


h. Se o plugin Viewpoint TortoiseSVN estiver instalado, os ícones também serão sobrepostos no
Project Explorer (veja que eles não aparecem nas pastas virtuais, mas serão sobrepostos em
seus conteúdos).

2. Faça alterações e confirme atribuindo-as ao repositório.


a. Abra o Main.vi no Project Explorer.
b. Pressione CTRL+E para alterar para o diagrama de blocos.
c. Faça alterações no diagrama de blocos - fique à vontade para fazer e/ou alterar qualquer coisa,
pois as alterações serão desfeitas em um passo mais adiante. Algumas recomendações:
i. Mova os itens no diagrama de blocos.
ii. Adicione casos nas estrutura(s) case.
iii. Exclua os fios do diagrama de blocos.
d. Salve o VI (Pressione CTRL+S).

11
Software Engineering Technical Manual and Exercises 2014

e. Agora a sobreposição do ícone TortoiseSVN deve ser vermelha, indicando que esse arquivo foi
modificado, mas não está atribuído ao repositório ainda.

f. Clique com o botão direito no Main.vi no disco e selecione SVN Commit… para enviar a
alteração para o repositório. Isso pode ser feito de dentro do LabVIEW (se estiver usando o
plugin Viewpoint TortoiseSVN ou do Windows Explorer).

Observação: Você também pode executar uma operação de confirmação a partir do Quick Drop durante o
desenvolvimento. Com o VI aberto, inicialize o Quick Drop pressionando CTRL+Space e pressione CTRL+C para
confirmar.

g. Quando for solicitado para inserir uma mensagem de registro, escreva uma breve descrição da
alteração que você estiver fazendo, por exemplo, ‘alteração do estado inicial’. Pressione OK
quando tiver finalizado e essa modificação estiver pronta para ser confirmada.
h. Você pode repetir as instruções no passo 2 várias vezes para praticar a confirmação de várias
alterações.

Observação: As modificações que foram confirmadas podem ser baixadas por outros desenvolvedores que
estejam conectados ao mesmo repositório. Os outros desenvolvedores precisarão apenas selecionar o item do
menu SVN Update para os arquivos ou pastas que eles quiserem atualizar. Para simular isso, você pode repetir os
passos neste exercício para verificar outra cópia local do mesmo repositório.

3. Visualize o histórico das revisões que você fez usando o visualizador do registro da subversão.
a. Clique com o botão direito no Main.vi no Project Explorer e clique em Show log. Essa operação
aparecerá sob VSI TSV Tools, conforme ilustrado abaixo:

12
Software Engineering Technical Manual and Exercises 2014

b. O registro exibindo todas as modificações criadas no passo 2 deve estar visível:

4. Reverta para a versão inalterada com a qual iniciamos.


a. Verifique se o painel frontal do main.vi está fechado.
b. A Revisão 1 representa a cópia original do Main.vi que foi atribuída ao repositório. Clique com o
botão direito na revisão 1 e selecione Revert to this revision no menu que aparecer.

c. Abra novamente o main.vi e observe que ele foi revertido para a cópia original do código.
5. Confirme o VI revertido.

13
Software Engineering Technical Manual and Exercises 2014

a. Clique duas vezes no Main.vi e atribua-o ao repositório. Isso irá garantir que o VI original e ativo
(que será necessário em exercícios posteriores) seja agora a versão mais recente confirmada.

EXERCÍCIO 3: COMO MONITORAR AS ALTERAÇÕES NOS VIS USANDO SCC

OBJETIVO
Queremos poder comparar duas cópias de um VI para identificar o que foi modificado através do uso do controle
do código fonte.

CENÁRIO
Estamos desenvolvendo uma aplicação do LabVIEW com o apoio de uma equipe de desenvolvedores. Em
preparação para uma revisão do código, queremos comparar nossas modificações mais recentes com a versão
anterior.

DESCRIÇÃO
Faremos o download do código mais recente e poderemos comparar as modificações que fizemos com as versões
anteriores usando um recurso gráfico diferenciado do LabVIEW. Após fazer modificações indesejadas e salvá-las,
poderemos reverter para a versão anterior.

CONCEITOS ABORDADOS
 Monitoramento de modificações com um controle do código fonte
 Diferenciação gráfica de fora do ambiente de desenvolvimento
 Reversão para uma versão anterior

CONFIGURAÇÃO
Se você optar por não utilizar a ferramenta do Viewpoint no Exercício 1, você pode configurar manualmente o
cliente Tortoise para executar o Diff and Merge para os VIs usando os passos a seguir (o toolkit referido acima
faz isso para você, além de adicionar atalhos dentro do LabVIEW).

o Clique com o botão direito no Windows Explorer.


o Selecione TortoiseSVN > Settings> Diff Viewer.
o Selecione Advanced e insira a informação abaixo para um tipo de arquivo .vi, se este não
aparecer na lista (isso também pode ser usado para um .ctl). Faça isso clicando em Add na caixa
de diálogo Advanced.

"C:\Program Files\National Instruments\Shared\LabVIEW Compare\LVCompare.exe" %mine %base-nobdcosm -nobdpos

14
Software Engineering Technical Manual and Exercises 2014

15
Software Engineering Technical Manual and Exercises 2014

INSTRUÇÕES
1. Faça alterações e compare-as com a versão anterior.
a. Mude para o diagrama de blocos do Main.vi.
b. Faça diversas modificações que possam apresentar bugs, comportamento inesperado ou até
mesmo quebrar a execução. Modificações sugeridas:
1. Altere os parâmetros de temporização (especialmente aqueles de difícil localização,
mas que podem gerar problemas significantes).
2. Adicione casos na estrutura case.
3. Altere as constantes do diagrama de blocos.
4. Exclua e/ou mova o código.
b. Salve as modificações.
c. Observe que o Main.vi, que foi modificado, tem um ponto de exclamação vermelho sobre o
ícone do arquivo no disco (esquerdo) e no projeto (direito). Esse é o modo que a subversão indica
que um arquivo tem modificações que não foram adicionadas ao repositório.

d. Podemos comparar as modificações que fizemos com a última versão em um controle do código
fonte usando Graphical Differencing. Se o plugin Viewpoint TortoiseSVN estiver instalado,
simplesmente clique com o botão direito no arquivo e selecione Diff. Isso também pode ser feito
diretamente no cliente TortoiseSVN no Windows Explorer.

e. Isso irá inicializar o LVCompare.exe, mostrando uma comparação lado a lado dos objetos no
painel frontal e no diagrama de blocos.

16
Software Engineering Technical Manual and Exercises 2014

f. Clicar duas vezes nos itens da lista colocará uma marca de verificação próximo a ela, indicando
que você analisou e revisou cada modificação.
g. Clique no ‘X’ na janela Differences para fechar a caixa de diálogo.

Observação: Quanto ao LabVIEW 2014, não é possível exportar os resultados de uma operação Diff para um
arquivo para revisão externa. Use esse diálogo, selecione Create Report e o tipo de arquivo preferido.

2. Reverta para a versão inalterada com a qual iniciamos.


a. Verifique se o painel frontal do main.vi está fechado.
b. Clique com o botão direito no VI no Project Explorer e selecione VSI TSVN Tools > Revert para
desfazer todas as alterações que foram feitas.

c. Abra novamente o main.vi e observe que ele foi revertido para a cópia original do código.

17
Software Engineering Technical Manual and Exercises 2014

COMO MONITORAR OS REQUISITOS ATENDIDOS


A maioria dos projetos de engenharia inicia com especificações de alto nível, seguidas pela definição de
especificações mais detalhadas conforme o projeto avança. As especificações contêm requisitos técnicos e
processuais que norteiam o produto através de cada fase da engenharia. Além disso, documentos de trabalho,
tais como esquema de hardware, modelos de simulação, código fonte de software e procedimentos e
especificações de teste devem aderir e atender os requisitos definidos pelas especificações.

O agrupamento de requisitos é importante para garantir que você e seu cliente tenham discutido e definido o que
a aplicação fará. A granularidade dos documentos depende diretamente das necessidades da sua aplicação e da
criticidade dela. Para os sistemas de missão crítica, é típico ir mais além para definir os requisitos para módulos
individuais de código, unidades de código e até mesmo os testes para essas unidades. Parte desse processo
requer ter chegado a um consenso sobre qual é o comportamento esperado e como o sistema deve desempenhar
sob determinadas e quaisquer condições.

Especificações vagas ou confusas para um projeto podem levar a um resultado que não atende às expectativas do
cliente. Considere um exemplo onde é solicitado que você crie um automóvel, mas não te fornecem informações
adicionais. Seria muito improvável que o produto final se assemelhasse ao que o cliente tinha em mente. Talvez
eles esperem um carro com duas portas e teto solar, mas você criou um conversível. Até mesmo em cenários
onde eles não são necessários, insistir em uma documentação extensiva de requisitos, complementada por
revisões de prova de conceito e protótipos, aumenta consideravelmente a probabilidade de sucesso de um
projeto.

Fazer protótipos e prova de conceito são passos muito importantes nos requisitos de desenvolvimento. Pode ser
muito difícil responder a todas as contingências e prever todas as formas nas quais o software se comportará. A
prova de conceito também é extremamente importante porque proporciona ao usuário final ou cliente uma
concepção do que o produto fará, o que ajuda os desenvolvedores e usuários chegarem a um consenso. Esse
princípio sob o qual o método de desenvolvimento Ágio foi derivado, que enfatiza iterações frequentes e
repetidas entre o desenvolvimento, é bastante amplo.

Um dos maiores desafios de desenvolvimento, em qualquer linguagem, é monitorar a implementação


considerando o requisito ou especificação que ela deve cumprir. Do ponto de vista do gerenciamento do projeto,
isso é importante para obter percepção do quão longe você está do projeto. Quando os requisitos são alterados,
também é valioso ter um registro de quais outras especificações ou implementações que os abrange também
podem ser afetadas.

A indústria de software tem uma grande variedade de ferramentas a sua disposição para gerenciamento de
especificações e requisitos. As ferramentas comuns incluem Telelogic DOORS e Requisite Pro. A National
Instruments oferece uma ferramenta para automatizar a integração desses produtos, o NI Requirements
Gateway. O Requirements Gateway facilita o monitoramento da cobertura dos requisitos para esses três tipos de
documentos.

18
Software Engineering Technical Manual and Exercises 2014

EXERCÍCIO 4: COMO RASTREAR UM CÓDIGO PARA DOCUMENTOS DE


REQUISITOS

OBJETIVO
Os desenvolvedores que definiram ou receberam requisitos devem poder documentar quando e onde os
requisitos são atendidos em suas aplicações para mostrar que eles fizeram o que eles deveriam. Nosso objetivo é
monitorar e entender o percentual dos requisitos que foram atendidos e onde. Também precisamos poder criar
matrizes de rastreamento e outras formas de documentação.

CENÁRIO
Recebemos os requisitos para uma aplicação simples e precisamos documentar que fizemos essa implementação.

DESCRIÇÃO
Usaremos o Requirements Gateway para analisar os documentos de requisitos escritos no Microsoft Word e gerar
relatórios. Considere que os requisitos também podem ser armazenados em DOORS, Requisite Pro, Excel, PDF e
vários outros formatos padrão.

CONCEITOS ABORDADOS
 Como adicionar um novo item em um projeto do Requirements Gateway
 Como documentar o código e a cobertura de requisitos
 Como monitorar o percentual de cobertura dos requisitos
 Geração de documentação e matrizes de rastreamento

19
Software Engineering Technical Manual and Exercises 2014

INSTRUÇÕES
1. Documente uma nova função em uma aplicação como se estivesse cobrindo um requisito.
a. Abra o documento de requisitos Blood Pressure Requirements – System Level no Microsoft
Word na pasta Requirements Documents no Project Explorer.
b. Familiarize-se com esse documento de requisitos simples. Observe que esses requisitos são
extremamente de alto nível (e, portanto, difíceis, se não impossíveis, de testar ou 'atender' com
uma implementação). Consequentemente, será necessário usar esses requisitos de alto nível
para derivar requisitos de baixo nível mais específicos.

c. Selecione um com seu cursor e clique em Styles (circulado acima) para observar se esse texto foi
selecionado como um Requirements_ID. Isso será usado para automatizar a análise desse
documento nos passos mais adiante.
d. Retorne para a pasta que contém o documento de requisitos e abra Detailed Software
Design.docx. Ele contém requisitos bem específicos para a implementação e o projeto do
software, que na verdade serão cobertos pela implementação do código. Veja que ele está
divido em duas seções principais: Implementações de Estado e Componentes da Interface
Gráfica de Usuário.
e. Desça a barra de rolagem até a última seção, nos requisitos dos Componentes da Interface
Gráfica de Usuário (página 12). Neste cenário, recebemos os requisitos e nos foi solicitado a

20
Software Engineering Technical Manual and Exercises 2014

implementação de um componente da interface de usuário para o indicador LED BPM. O


requisito conforme especificado é "A interface de usuário deve incluir uma exibição numérica
durante a aquisição que mostra as batidas instantâneas por minuto“. Opcional: Copie a
descrição desse requisito no clipboard destacando e pressionando CTRL+C.
f. Abra o Software Engineering Tools.lvproj e abra o painel frontal do Main.vi. Esse código tem a
função necessária implementada com sucesso para o indicador BMP (circulado acima), nós
apenas precisamos documentá-lo.

g. Para documentar que essa função foi implementada, clique com o botão direito na borda do
indicador e selecione Description and Tip. Este é o local onde colocaremos a tag apropriada
para que possamos analisar e rastrear automaticamente a relação entre esse componente e a
implementação atual.
h. No campo de descrição, digite [Covers: UIReq4]. Veja que você também deve incluir qualquer
outra informação relevante neste campo (se você copiou o texto do passo 'e', você pode colá-lo
aqui).

21
Software Engineering Technical Manual and Exercises 2014

i. Feche a caixa de diálogo Description and Tip clicando em OK.


j. Salve o VI pressionando CTRL + S.
2. Adicione o projeto do LabVIEW ao Requirements Gateway e analise os itens atendidos.
a. Retorne ao Project Explorer do LabVIEW e expanda o Requirements Documents.
b. Clique duas vezes em NIBP Monitor.rqtf, que abrirá o Requirements Gateway.
c. O projeto Requirements Gateway já foi parcialmente configurado e mostra a relação entre os
documentos de requisito, mas no momento não contém o código do LabVIEW.
d. Quando o Requirements Gateway for aberto, selecione Edit Project no menu File.
e. Clique no Add Document (circulado abaixo) e coloque um novo contêiner na janela superior
direita.

f. Tendo feito isso, altere o menu drop down sob Type of Analysis para LabVIEW.
g. Clique em File or Directory e clique em ‘…’
h. Na caixa de diálogo que aparecer, clique em Add LabVIEW File… e navegue até o arquivo
.lvproj.
i. Clique em OK para sair dessa caixa de diálogo.
j. Defina que o código do LabVIEW atende o documento de requisitos Detailed Software Design.
Clique em Add a cover no menu (ilustrado abaixo) e clique no documento do LabVIEW e, em
seguida, desenhe uma linha no documento Detailed Software Design indicando o que essa
aplicação está abrangendo.

22
Software Engineering Technical Manual and Exercises 2014

k. Clique em OK para sair da caixa de diálogo de configuração. Se for solicitado para analisar
novamente o projeto, clique em yes.
l. Pressione CTRL + S para salvar o projeto do Requirements Gateway.
m. Na guia Management View, verifique se o Requirements Gateway está analisando esses itens
conforme ilustrado abaixo:

n. Observe que os requisitos atendidos correspondem a menos de 100%. Clique na guia Coverage
Analysis View para visualizar a lista dos requisitos não atendidos.

23
Software Engineering Technical Manual and Exercises 2014

o. Clique na guia Graphical View para visualizar uma relação gráfica entre os requisitos.
3. Gere uma documentação mostrando os requisitos atendidos.
a. Na guia Graphical View, destaque o que você quer incluir no relatório. Segure CTRL enquanto
seleciona o documento de requisitos e o projeto do LabVIEW.

b. Clique em Reports > Library Reports > Traceability Matrix.


c. Confira se você selecionou todos os itens que serão incluídos e clique em Continue.
d. Na caixa de diálogo Save que aparecer, verifique os diferentes formatos que estão disponíveis.
Selecione o PDF ou outro formato que desejar, navegue até o desktop e salve o arquivo como
Blood Pressure Traceability Matrix
e. Aparecerá a matrix de rastreamento.

24
Software Engineering Technical Manual and Exercises 2014

25
Software Engineering Technical Manual and Exercises 2014

COMO FAZER REVISÕES DO CÓDIGO


Revisões regulares e minuciosas do código são uma prática comum e importante para os engenheiros de software
que buscam mitigar o risco de problemas imprevisíveis, identificar a causa dos bugs que são difíceis de localizar,
alinhar os estilos de vários desenvolvedores e demonstrar que o código funciona. Essas revisões são uma
oportunidade para uma equipe de indivíduos qualificados para examinar a lógica do desenvolvedor e analisar o
desempenho do software.

As revisões por pares às vezes são referidas como um código ‘walk-through’. O revisor geralmente é guiado pelo
desenvolvedor pelo caminho principal da execução através do programa, durante o qual eles devem examinar o
estilo da programação, verificar a documentação adequada e revisar as perguntas que podem ser obstáculos
comuns, tais como:

 Com qual facilidade os recursos podem ser adicionados futuramente?


 Como os erros são apresentados e tratados?
 O código modular é suficiente?
 O código esgota o processador ou usa uma quantidade de memória proibitiva?
 Existe um plano de teste adequado?

Um dos motivos mais comuns para não fazer uma revisão do código é a quantidade de tempo necessária para
prepará-la e para fazer a revisão. Para simplificar esse processo, você precisa aproveitar as ferramentas que
podem ajudar a automatizar a inspeção do código e ajudar a identificar melhorias. Um exemplo é a ferramenta do
VI Analyzer do LabVIEW, que analisa qualquer código do LabVIEW e em seguida faz o usuário passar pelas falhas
nos testes. Você também pode gerar relatórios que permitem que você monitore as melhorias ao longo do
tempo, e podem ser verificados no software do controle do código fonte junto com seus VIs.

26
Software Engineering Technical Manual and Exercises 2014

EXERCÍCIO 5: ANÁLISE DA QUALIDADE DO CÓDIGO

OBJETIVO
Queremos analisar nosso código regularmente para identificar quaisquer problemas em potencial ou erros de
codificação que poderiam gerar um comportamento incorreto ou inapropriado.

CENÁRIO
Iremos configurar uma série de testes, examinar os resultados e gerar um relatório para documentar os
resultados.

DESCRIÇÃO
O LabVIEW VI Analyzer Toolkit será utilizado para executar mais de 90 testes na hierarquia da nossa aplicação e
gerar um relatório em HTML.

CONCEITOS ABORDADOS
 Carregamento da configuração de teste pré-configurada
 Geração de relatórios

27
Software Engineering Technical Manual and Exercises 2014

INSTRUÇÕES
1. Inicialize, configure e execute os testes analisadores.
a. Dentro do LabVIEW, selecione Tools > VI Analyzer > Analyze VIs…

b. Selecione a tarefa nomeada Load a previously saved analysis configuration file e clique em
Next.

c. O VI Analyzer nos permite customizar as configurações de teste e salvá-las para uso futuro.
Navegue até Software Engineering Tools > Code Reviews, e carregue o arquivo VI Analyzer Test
Configuration.cfg.

28
Software Engineering Technical Manual and Exercises 2014

d. O VI Analyzer exibirá uma lista dos arquivos que serão analisados. Podemos usar essa janela
para adicionar ou remover objetos. Após o main.vi ser selecionado, clique em Next.

e. Será exibida uma lista de todos os testes disponíveis. Selecione um teste para visualizar as
informações de configuração e definir prioridade. As recomendações incluem:
1. Documentation > User >Spell Check – isso pode ajudar a mitigar o risco de palavras
digitadas erradas na documentação e, mais importante, na interface de usuário.
2. Complexity Metrics >Cyclomatic Complexity – essa métrica de código padrão da
indústria ajuda a avaliar a quantidade de caminhos pelo código, que é útil no
desenvolvimento de planos de teste.
3. Block Diagram > Performance >Arrays and Strings in Loops – esse é um dos vários
testes que podem identificar as práticas de programação que podem entorpecer a
velocidade da execução.
f. Clique em Next.
g. Podemos agora salvar a configuração de teste, ou podemos fazer a análise em nossos VIs. Clique
em Analyze para começar a testar toda a hierarquia dos VIs.

Observação: Os testes devem levar aproximadamente trinta segundos para serem concluídos em um computador
rápido se você executá-los em toda hierarquia da aplicação.

2. Faça a revisão do VI Analyzer Results e corrija os erros.


a. A caixa de diálogo que aparece após a execução dos testes mostra a lista de VIs que foi
analisada. O número exibido na coluna da direita indica o número de itens que exigem atenção e
revisão. Comece expandindo os itens sob o Main.vi.

29
Software Engineering Technical Manual and Exercises 2014

b. As falhas de teste de grande importância serão indicadas usando um ponto de interrogação


vermelho. Como exemplo, amplie o teste Spell Check e selecione Occurrence 1. A descrição
deve explicar que, ‘O controle Timing contém a palavra “Timming” digitada incorretamente em
seu texto Booleano.’
c. Clique duas vezes em Occurrence 1. O LabVIEW deve destacar o botão no painel frontal com a
palavra digitada errada.
d. Explore os resultados restantes e consulte a descrição para obter detalhes de como corrigir o
erro.
3. Gere um relatório em HTML.
a. Clique em Export na janela do VI Analyzer Results.
b. Altere o Export File Path para a pasta Code Review no projeto e digite o nome do arquivo que
você quer salvar como.
c. No menu drop down, selecione HTML.
d. Clique em Export.
e. Clique em Done na janela do VI Analyzer Results. Clique em No para ignorar a caixa de diálogo
Save.
f. Quando for solicitado para retornar ao VI Analyzer, clique em No
g. Navegue até o local que você especificou no passo 'b' e clique duas vezes no HTML salvo.

30
Software Engineering Technical Manual and Exercises 2014

ANÁLISE DINÂMICA DO CÓDIGO E DEPURAÇÃO AVANÇADA


Identificar a fonte e corrigir a causa de um comportamento inesperado ou indesejado no software pode ser uma
tarefa tediosa, demorada e cara para os desenvolvedores. Até mesmo o código que está sintaticamente correto e
funcionalmente completo muitas vezes é contaminado com problemas como vazamento de memória ou tarefas
daemon que podem impactar no desempenho ou levar a um comportamento incorreto. Essa supervisão pode ser
difícil de reproduzir e ainda mais difícil de localizar, principalmente em aplicações complexas e de grande porte.

Com o LabVIEW Desktop Execution Trace Toolkit, você pode acompanhar a execução dos VIs do LabVIEW em um
target do Windows durante o run-time para detectar e localizar problemas no código que podem impactar o
desempenho ou provocar comportamentos inesperados. Isso será útil quando houver dificuldade para localizar a
fonte ou for difícil localizar ou reproduzir problemas. O Desktop Execution Trace Toolkit oferece uma visualização
cronológica dos eventos do sistema, das operações da fila, dos vazamentos da referência, da alocação de
memória, dos erros não tratados e da execução dos subVIs. Os usuários também podem gerar
programaticamente eventos definidos pelo usuário a partir do diagrama de blocos de uma aplicação do LabVIEW.

A análise dinâmica do código refere-se à habilidade de entender o que o software está fazendo durante a
execução por trás dos bastidores. Em outras palavras, ela fornece detalhes sobre os eventos e o contexto no qual
eles ocorrem para oferecer ao desenvolvedor uma visão mais ampla e mais informações de como ajudar a
solucionar os problemas.

A análise dinâmica do código tem diferentes casos de uso durante todo o ciclo de vida de desenvolvimento do
software, incluindo:

• Detecção de vazamentos de memória e referência.


• Isolação da fonte de um determinado evento ou comportamento indesejado.
• Verificação das áreas nas quais o desempenho de uma aplicação pode ser melhorado.
• Identificação do último chamado antes de um erro.
• Garantia de que a execução de uma aplicação será a mesma em diferentes targets.

Problemas como vazamento de memória podem gerar consequências dispendiosas para os sistemas que
precisam sustentar a operação por longos períodos de tempo ou para o software que tenha sido liberado a um
cliente. Se o software que precisar ser depurado foi implementado e o ambiente de desenvolvimento do
LabVIEW não estiver na máquina atual, pode ser benéfico executar uma análise dinâmica do código com o
Desktop Execution Trace Toolkit na rede. Para os sistemas implementados, mesmo se o ambiente de
desenvolvimento estiver disponível, pode ser pouco prático ou difícil solucionar um problema ou traçar o perfil de
execução de um sistema em execução.

31
Software Engineering Technical Manual and Exercises 2014

EXERCÍCIO 6: COMO DEPURAR UM COMPORTAMENTO INESPERADO

OBJETIVO
Queremos fazer um perfil da execução da aplicação do LabVIEW que desenvolvemos para localizar a fonte do
comportamento indesejado.

CENÁRIO
Considere que você tem um software em uso que aparenta funcionar bem, mas eventualmente começa a ficar
lento e menos responsivo ou fecha inesperadamente. Você suspeita que haja um vazamento de memória, mas a
aplicação é muito grande e poderia levar um tempo extremamente longo para rastrear a fonte desse problema.

DESCRIÇÃO
Usaremos o Desktop Execution Trace Toolkit para monitorar a execução da nossa aplicação suspeita e para ver se
podemos localizar a fonte desses comportamentos problemáticos.

CONCEITOS ABORDADOS
 Como organizar e configurar um rastreamento
 Como filtrar as informações
 Dados de rastreamento definidos pelo usuário
 Como localizar a fonte de um evento
 Como identificar vazamentos de memória
 Como descobrir erros não tratados

CONFIGURAÇÃO
 Verifique se o LabVIEW e o Desktop Execution Trace Toolkit estão instalados.
 Verifique se o firewall não está impedindo a comunicação entre a ferramenta e o LabVIEW.
 No LabVIEW, navegue em Tools >> Options e selecione a categoria Block Diagram. Remova a marca de
seleção em Enable Automatic Error Handling in new VIs e Enable Automatic Error handling dialogs.

 Para identificar a porta adequada do VI Server a ser usada, clique em ‘Help > About LabVIEW…’ no menu
de arquivo. Na tela que aparecer, ela será identificada como a porta na qual o servidor TCP está ativo ou
'TCP Server active on port ####'.

32
Software Engineering Technical Manual and Exercises 2014

INSTRUÇÕES
1. Demonstre que a aplicação não aparenta apresentar defeitos óbvios e mostre como a customização de
dados de rastreamento foi feita na aplicação.
a. No Project Explorer, abra o VI intitulado Main.vi. Conforme demonstrado nos exercícios
anteriores, a aplicação funciona corretamente e não tem nenhum bug que seja óbvio; no
entanto, os erros foram intencionalmente codificados nessa aplicação para demonstração,
incluindo vazamento de memória que degradará o desempenho ao longo do tempo.
b. No Project Explorer, expanda a pasta subVIs e abra o VI Peak-Valley-Noise.vi. Esse VI é
responsável por isolar os valores máximos e mínimos filtrados - por exemplo, se esse VI
apresentou incorretamente um ruído como um valor mínimo, poderemos notar que a média do
HR está um pouco fora do resultado. No curso de depuração desse problema, seria de grande
valia saber todos os parâmetros quando esse cálculo está sendo feito. Configurar um ponto de
interrupção seria impraticável porque esse VI é executado para cada ponto na forma de onda, o
que significa que uma aquisição pode executar esse VI mais de 10.000 vezes em apenas alguns
segundos. Se o VI retornar apenas resultados incorretos intermitentemente, é muito mais útil
poder gravar a execução e todos os parâmetros para revisão posterior. Para fazer isso, todos os
parâmetros usados neste cálculo são baseados no VI Send Debug Info to DETT quando um valor
mínimo é detectado.

c. Abra o diagrama de blocos do VI Send Debug Info to DETT para ver como as informações estão
alojadas. Esse VI usa a função primitiva Generate User-Defined Trace Event para transferir
dados ao Desktop Execution Trace, o que é extremamente útil ao tentar depurar um código que
itera rapidamente através de uma grande quantidade de dados. .

33
Software Engineering Technical Manual and Exercises 2014

2. Configure o Rastreamento.
a. Inicialize o Desktop Execution Trace Toolkit no menu iniciar navegando em National
Instruments > LabVIEW Desktop Execution Trace Toolkit.
b. Na guia Home, confira se a porta correta corresponde à porta do VI Server que o LabVIEW está
usando (veja as instruções de configuração) e clique em refresh (circulado acima) para carregar
as instâncias da aplicação que estão disponíveis.

c. Selecione a instância da aplicação que você quer rastrear no menu drop down - isso deve
corresponder ao nome do Project Explorer que você quer rastrear.
d. Clique em Capture Settings para definir o que será gravado.
e. Essa caixa de diálogo pode ser usada para customizar o tipo de informação que você quer ver.
Essa ferramenta pode retornar rapidamente grandes quantidades de informações, então é
bastante útil isolar seu rastreamento para os VIs e/ou informações principais. Clique em Load na
parte inferior para carregar uma configuração anterior. Navegue para o local do projeto no disco
e abra a pasta Code Reviews. Abra o arquivo Trace Configuration.ini.

34
Software Engineering Technical Manual and Exercises 2014

f. Clique em OK.

Observação: Fique à vontade para repetir o exercício e experimentar configurações diferentes. Há inúmeros
exemplos no Example Finder para o Desktop Execution Trace Toolkit que podem ser usados para ilustrar os
recursos das ferramentas.

3. Inicie o rastreamento da execução.


a. Selecione Start na barra de ferramentas.

b. Volte para o painel frontal do Main.vi.


c. Coloque o painel frontal no Desktop Execution Trace Toolkit na tela para que ambos possam ser
vistos simultaneamente.
d. Execute o VI e quando for solicitado, selecione os mesmos dados de amostra com da última vez.
e. Observe que você deve ver os dados aparecerem no rastreamento conforme ilustrado abaixo
após selecionar o conjunto de dados.

35
Software Engineering Technical Manual and Exercises 2014

f. A tela continuará a ser preenchida com Memory Resize uma vez que temos um código em nossa
aplicação que tem um vazamento.
g. Retorne à aplicação e clique em Take Blood Pressure. Como resultado, agora devemos ver
alguns dados gerados pelo usuário aparecerem uma vez que o arquivo está sendo processado.
Ao fim da execução, aparecerá uma mensagem de erro.
h. Após a execução do sistema parar, pare o rastreamento.
4. Como entender os dados
a. Recebemos várias colunas de dados, incluindo o VI no qual eles ocorreram, a descrição do
evento e outras informações, como o timestamp.
b. Destaque um evento clicando nele, por exemplo, alocação de memória. Além das informações
na tabela, a parte inferior da tela é preenchida com informações adicionais, como o call chain.

c. Clique com o botão direito em uma seta para ver as opções de menu adicionais, incluindo o
recurso de navegar diretamente para qualquer um dos VIs nessa call chain de eventos

36
Software Engineering Technical Manual and Exercises 2014

específicos. Você também pode filtrar o VI de todos os rastreamentos gravados ou


rastreamentos futuros (se você reiniciar esse rastreamento específico).

d. Clicar duas vezes em uma seta na tabela o levará para o local no código que gerou o evento
capturado.
5. Como usar filtros para analisar dados
a. Clique na guia View .
b. Clique em Filter Settings.

a. Vários eventos que indicam potenciais problemas em nossa aplicação foram capturados.
Desfaça a seleção de todos os eventos e clique nos quadros próximos aos itens abaixo. Tente
selecioná-los individualmente para estreitar mais ainda os dados de rastreamento.
i. Erros: dois erros devem ser capturados como resultado das referências inválidas do
objeto.
ii. Memória: o VI Logging Slope estará incrementalmente consumindo mais memória,
resultando em um potencial vazamento.
iii. Eventos de rastreamento definido pelo usuário: útil depurar as informações que os
programadores optaram capturar para melhor entender e depurar o comportamento
de seu sistema.
6. Opcional: A versão de 2014 do Desktop Execution Trace Toolkit oferece o recurso de comparar os
rastreamentos. Tente corrigir o vazamento de memória e/ou o erro não tratado e execute novamente o
rastreamento. Quando você tiver vários rastreamentos, retorne para a guia View e clique em Compare
Traces. Siga as instruções nessa caixa de diálogo para comparar os resultados das duas versões
diferentes do código. Isso é útil para garantir que você não tenha alterado acidentalmente quaisquer
outros aspectos de sua aplicação além do que você deseja modificar.

37
Software Engineering Technical Manual and Exercises 2014

TESTE E VALIDAÇÃO
A ideia por trás do teste de unidade é sofisticada e simples, mas pode ser expandida para permitir séries
sofisticadas de testes para validação do código e teste de regressão. Um teste de unidade é rigorosamente algo
que "exercita" ou executa o código sob teste. Muitos desenvolvedores desenvolvem manualmente o teste de
unidade regularmente no decurso do trabalho com um segmento do código. Em outras palavras, pode ser
simplesmente 'Sei o que o código deve fazer nessa tarefa quando eu forneço essa entrada; Vou tentar e verificar o
que acontece'. Se não se comportar conforme esperado, o desenvolvedor provavelmente modificaria o código e
repetiria esse processo até ele funcionar.

O problema em fazer isso manualmente é que isso pode facilmente ignorar grandes faixas de valores ou
diferentes combinações de entradas e não oferece percepção do quanto o código foi realmente executado
durante o teste. Além disso, não nos ajuda com a importante tarefa de comprovar para outra pessoa que isso
funcionou e de forma correta. O custo e tempo necessários são agravados pela realidade de que uma rodada de
teste raramente é suficiente; além de corrigir os bugs, quaisquer alterações posteriores que sejam feitas no código
no processo de desenvolvimento podem exigir investimento adicional de tempo e recursos para garantir que ele
esteja funcionando adequadamente.

Projetos de grande porte normalmente aumentam os procedimentos manuais com ferramentas como o LabVIEW
Unit Test Framework Toolkit para automatizar e melhorar esse processo. A automação reduz o risco de erros
não detectados, economiza custos ao detectar antecipadamente problemas no ciclo de vida do desenvolvimento
e economiza tempo mantendo os desenvolvedores concentrados na tarefa de escrever o software em vez de eles
mesmos fazerem os testes.

38
Software Engineering Technical Manual and Exercises 2014

EXERCÍCIO 7: TESTE DE UNIDADE E VALIDAÇÃO DO CÓDIGO

OBJETIVO
Queremos automatizar o processo de testar os VIs para garantir que eles apresentem o comportamento correto.

CENÁRIO
Considere que você recebeu alguns requisitos para implementar uma sub-rotina e você quer verificar se ela
funciona da forma esperada. Automatizar os testes possibilita executá-la de forma regular e desse modo reduz o
risco de fazer uma modificação que poderia trazer algum problema. Podemos gerar relatórios e obter
informações adicionais sobre nosso código que podem ajudar a melhorar ainda mais a qualidade e confiabilidade
da aplicação.

DESCRIÇÃO
Usaremos o LabVIEW Unit Test Framework Toolkit para gerar um caso de teste para um VI simples, analisar os
resultados e gerar um relatório.

CONCEITOS ABORDADOS
 Como criar um teste de unidade
 Como definir casos de teste
 Como monitorar os testes no Project Explorer
 Como importar parâmetros do painel frontal
 Execução de testes
 Como interpretar a caixa de diálogo de resultados de testes
 Geração de relatórios

CONFIGURAÇÃO
 Verifique se o diretório UFT está configurado adequadamente
o Clique com o botão direito no arquivo do projeto no Project Explorer e selecione Properties.
o Selecione Unit Test Framework.
o Desça a barra de rolagem até Test Creation e verifique se o diretório correto está selecionado.

39
Software Engineering Technical Manual and Exercises 2014

INSTRUÇÕES
1. Opcional: Faça um teste manual
a. No Project Explorer, expanda Algorithms e abra o VI Peak-Valley-Noise. Este VI executa um loop
para identificar os valores mínimos e máximos comparando a inclinação instantânea com a
inclinação anterior.
b. Faça revisão do documento de requisitos para obter o vetor do teste. Expanda Requirements
Documents e abra Blood Pressure Requirements – Software Unit Tests.doc
c. O VI Peak-Valley-Noise tem as seguintes entradas:
i. Slope – essa é a faixa na qual a pressão está sendo modificada entre os dois pontos
mais recentes.
ii. Last Slope – essa é a faixa na qual a pressão está sendo modificada entre os dois pontos
anteriores.
iii. Heart Rate Timer– isso corresponde à quantidade de pontos de dados que foi analisada
desde o valor mínimo. Se a quantidade de amostras for inferior a 300, ele deve retornar
para Noise.
iv. Pulse– configure para True após um valor mínimo e até um valor máximo.
v. Error in (no error) – se um erro for passado para esse VI, ele deve retornar o mesmo erro
e zeros para ambos os indicadores.
b. O VI Peak-Valley-Noise tem as seguintes saídas:
i. State– as opções são Peak, Valley ou Noise.
ii. Error out– se entradas inválidas receberem esse VI, ele apresentará um erro. Ele
também passará quaisquer erros que forem introduzidos nele.

d. Configure o VI para um teste manual.


i. Configure o Heart Rate Timer para 500.

40
Software Engineering Technical Manual and Exercises 2014

ii. Configure o Slope para 4.


iii. Configure o Last Slope para -9.
b. Execute o VI. As saídas devem ser:
i. State- deve ser o valor mínimo (Valley).
ii. Error Out- o status do error out não deve indicar um erro.
2. Defina o Teste de Unidade para o VI Peak-Valley-Noise
e. Embora tenhamos executado manualmente o VI para verificar e confirmar se ele está
funcionando, existem inúmeras condições que queremos verificar se esse VI pode tratá-las
adequadamente. Muitos testes já foram criados para esse VI, mas começaremos criando um
novo teste para valores positivos. Clique com o botão direito no VI e selecione Unit Tests > New
Test.

a. O LabVIEW irá gerar um novo arquivo no disco com uma extensão .lvtest. Por padrão, o teste
será criado próximo no VI sob teste, embora possamos especificar um local separado ou mover o

41
Software Engineering Technical Manual and Exercises 2014

teste no disco de dentro da guia Files. Clique duas vezes no teste de unidade no Project Explorer
para abrir a caixa de diálogo Test Properties.
b. Selecione a categoria Test Cases. Observe que um teste de unidade contém vários casos de
teste.

c. O lado direito da caixa de diálogo Test Cases exibirá as entradas e saída do VI Under Test. A
partir dessa caixa de diálogo, podemos configurar:
i. As entradas a serem configuradas.
ii. Os valores da entrada.
iii. As entradas isentas.
iv. As entradas a serem comparadas.
v. As comparações a serem feitas entre os resultados atuais e os resultados esperados.
d. Por padrão, apenas os controles e indicadores conectados ao connector pane serão exibidos na
caixa de diálogo Test Case, mas podemos ajustar as configurações da categoria Advanced para
usar quaisquer e todos os controles e indicadores. Os testes podem ser criados para qualquer
tipo de dados no LabVIEW, incluindo arrays e clusters. Para os conjuntos de dados complexos,
pode ser melhor definir os valores no arquivo .lvtest, via painel frontal ou em um VI de
configuração.

42
Software Engineering Technical Manual and Exercises 2014

e. Defina os valores da entrada para os valores com base no documento de requisitos aberto em
um passo anterior. Alternativamente, você também pode apenas copiar os valores abaixo:

f. Opcional: Se você concluiu o primeiro passo deste exercício para testar manualmente o VI e
deixou o painel frontal aberto, você pode importar os valores do Painel Frontal clicando em
Import Values from VI.

43
Software Engineering Technical Manual and Exercises 2014

a. Opcional: Os parâmetros de teste também podem ser modificados fora do LabVIEW usando
ferramentas como Excel. Se o Excel estiver instalado, você pode clicar com o botão direito no
teste de unidade de dentro do Project Explorer e selecionar Open in external editor.

44
Software Engineering Technical Manual and Exercises 2014

b. Defina a string da saída como Valley.


c. Se você quiser definir casos de teste adicionais dessa caixa de diálogo, clique em New na parte
superior.
d. Quanto ao LabVIEW 2014, os testes podem ser executados diretamente a partir do editor. Sem
fechar a caixa de diálogo, clique na seta de execução na barra de menu para executar esse teste.

e. Quando a ação for concluída, se o VI funcionar corretamente, você deve ver que o teste foi
aprovado.

f. Se o teste não for aprovado, aparecerá uma falha na caixa de diálogo explicando quais
parâmetros não apresentaram os valores esperados:

45
Software Engineering Technical Manual and Exercises 2014

g. O Unit Test Framework também é projetado para permitir rápida iteração nos parâmetros de
teste e no código para corrigir eventuais falhas. Com a caixa de diálogo UTF ainda aberta, o VI
pode ser modificado e executado para iterar e corrigir eventuais problemas rapidamente. Os
valores do controle do painel frontal também podem ser importados ou exportados para um
caso de teste específico.
h. Opcional: Clique na categoria Configuration, que exibe a configuração básica do teste de
unidade. As informações exibidas incluem:
i. VI Under Test – será automaticamente configurado, mas podemos modificá-lo em
uma data posterior se movermos ou renomearmos um VI sob teste fora do LabVIEW
Project Explorer.
ii. Test Priority – esse número pode ser usado para agrupar os testes e testar os
resultados com base na sua importância. Por exemplo, você pode dizer ao Unit Test
Framework para executar apenas os testes que têm no mínimo uma certa prioridade.
iii. Requirements ID (Opcional) – esse ID pode ser lido pelo Requirements Gateway por
uma questão de rastreabilidade automatizada para os documentos de requisitos.
b. Opcional: Na página da categoria Configuration, insira o ID requerido: SwTestReq1 no campo
Requirements ID . Isso pode ser analisado pelo Requirements Gateway
i. Clique em OK.
j. Agora que o editor do Unit Test Framework foi fechado, os testes podem ser executados de
várias formas diferentes:
i. Eles podem ser executados individualmente ao clicar neles e selecionar Run.

46
Software Engineering Technical Manual and Exercises 2014

ii. Há um item da barra de ferramentas no projeto para executar todos os testes.

iii. As pastas que contêm os testes de unidade têm um item de menu aberto por um clique
que permite a execução de todos os testes dentro delas.
iv. O API UFT permite que os desenvolvedores executem esses testes programaticamente.
k. Clique com o botão direito no teste no Project Explorer e selecione Run.

47
Software Engineering Technical Manual and Exercises 2014

m. O teste deve ser aprovado, o que será indicado por um ícone verde que é sobreposto no teste na
árvore do projeto. Aparecerá também uma caixa de diálogo explicando os resultados.

n. Clique em OK.

48
Software Engineering Technical Manual and Exercises 2014

3. Ative a geração de relatório.


a. No Project Explorer, clique com o botão direito no arquivo do projeto e selecione Properties.

b. A caixa de diálogo Properties contém várias configurações e preferências para o Unit Test
Framework, incluindo filtros de teste e o local padrão para novos testes.
c. Na seção HTML Report, marque Generate HTML Report e View Report after Execution.
d. Na seção Report Details, marque todas as opções.

e. Selecione os teste de unidade: Generate Reports, Generate HTML Report e View Report after
Execution.
f. Clique no ícone na barra de ferramentas para executar os testes de unidade.

g. Após esses testes serem concluídos, o relatório do HTML deve ser exibido no seu navegador.
4. Opcional: Visualize a rastreabilidade dos arquivos de teste recém-criados no Requirements Gateway.
Isso só mostrará os requisitos atendidos se você concluiu os passos opcionais anteriores para adicionar o
ID requerido no arquivo .lvtest.

49
Software Engineering Technical Manual and Exercises 2014

a. Mova todos os arquivos do teste de unidade para uma única pasta no disco, pois direcionaremos
o Requirements Gateway para esse local.
b. Já foi incluído um documento de requisitos para os testes de unidade, Blood Pressure
Requirements – Software Unit Tests.doc. Apresente o mesmo projeto do Requirements
Gateway usado no Exercício 4 e abra a caixa de diálogo de configuração clicando em File > Edit
Project.
c. Já foi incluído um item da linha para os testes de unidade. Direcione esse item para o diretório
que contém os arquivos lvtest.
d. Clique em OK e deixe o Requirements Gateway analisar tudo.

50
Software Engineering Technical Manual and Exercises 2014

MAIS INFORMAÇÕES

FAÇA O DOWNLOAD DO CÓDIGO FONTE, MANUAL E SLIDES


 http://bit.ly/lv_swe

RECURSOS ONLINE
 ni.com/largeapps– encontre as melhores práticas, exemplos online e uma comunidade de usuários em
nível avançado no LabVIEW.
 ni.com/community/largeapps– participe de uma comunidade de outros usuários que desenvolvem
aplicações de grande porte no LabVIEW.
 ekerry.wordpress.com – siga o blog de Elijah Kerry sobre a engenharia de software e desenvolvimento
de aplicações de grande porte no LabVIEW.

CURSOS PARA FORMAÇÃO DO CLIENTE


 Gerenciamento da engenharia de software com o LabVIEW
o Aprenda a gerenciar o desenvolvimento de um projeto no LabVIEW da definição à
implementação.
o Selecione e use técnicas e ferramentas adequadas para gerenciar o desenvolvimento de uma
aplicação no LabVIEW.
o Preparação recomendada para o exame Certified LabVIEW Architect.
 Arquiteturas avançadas no LabVIEW
o Ganhe experiência e exposição com várias arquiteturas para aplicações médias e de grande
porte no LabVIEW.
o Aprenda como selecionar uma arquitetura adequada com base nos requisitos de alto nível.
o Preparação recomendada para o exame Certified LabVIEW Architect.
 Projeto e programação orientados a objeto no LabVIEW
o Projeto de aplicações pelos princípios de projeto orientado a objetos.
o Implementação de hierarquias de classes básicas usando as classes do LabVIEW.
o Modificação de aplicações do LabVIEW para substituir padrões comuns por objetos do
LabVIEW.

51