A disciplina de Teste

O objetivo fundamental é verificar a qualidade do sistema. Esta disciplina ganha intensidade ao longo da fase de Construção e tende a perder esta intensidade apenas no início da fase de Transição. Ou seja, implementação e teste não devem ser atividades serializadas. Equipes de desenvolvimento e teste podem trabalhar de forma paralela. Em geral é isso o que acontece entre as demais disciplinas também, mas está explicitamente descrito neste post para que alguns paradigmas tradicionais, como este que envolve implementação e teste, sejam esquecidos.

Apenas um artefato é produzido nesta disciplina:

• Modelo de Teste


Este modelo define um Plano de Teste, formado por duas fases principais: testes unitários e testes de integração.

Os teste unitários são fundamentais para garantir que cada um dos componentes integrantes da arquitetura do software esteja se comportando adequandamente. Este tipo de teste consiste na criação de casos de teste.

Cada caso de teste possui uma responsabilidade bem específica, geralmente a verificação da execução de um método do componente. O caso de teste deve prever a execução de todos os caminhos possíveis a serem percorridos durante a execução. É importante que o caso de teste também preveja variações nos dados recebidos (dados normais, dados limite e dados ruins).

Vamos supor que um determinado componente da arquitetura do seu sistema seja responsável por cálculos matemáticos complexos. Certa operação deste componente se propõe a calcular o valor fatorial de um número inteiro qualquer. Por se tratar de um cálculo que envolve valores muito altos, a operação possui um tratamento para considerar apenas os valores entre 1 e 100. Neste caso, dados normais são valores como 20, 50, 70. Já os dados limites, compreendem valores como 0, 1, 2, 99, 100, 101. Por fim, os dados ruins seriam números como -10, -1, 110, 200.

Após validar os componentes, estes devem ser integrados.
Os testes de integração podem ser orientados por casos de teste. Porém, neste caso, procuramos validar comportamentos mais abstratos, de maior granularidade.

O Engenheiro de Teste é um profissional especializado em metodologias para este fim. No exterior, esta é uma posição de muito prestígio em uma equipe de desenvolvimento, com plano de carreira bem definido e alta remuneração. É o profissional que efetivamente autoriza a publicação de um determinado sistema.

Infelizmente, esta realidade não é percebida em nosso país...

A disciplina de Implementação

O objetivo fundamental nesta disciplina é construir uma versão operacional do sistema a ser entregue aos clientes. Caso o projeto encontre-se no primeiro ciclo, é comum que esta versão do sistema seja beta, ou seja, será disponibilizada para avaliação.

Quando esta disciplina aumenta sua intensidade, o projeto provavelmente está na fase de Construção e as discussões passam a ser puramente técnicas. Neste estágio a arquitetura é desenhada em termos de componentes.

A criação do código-fonte também é uma atividade desta disciplina.

Dois artefatos são produzidos durante esta disciplina. São eles:

• Modelo de Implementação


Este modelo é formado por pacotes de implementação. Cada pacote representa um agrupamento lógico de diagramas de componentes da UML. Estes diagramas são responsáveis por discriminar os relacionamentos existentes entre os componentes. Predominantemente, são modeladas as dependências e as conexões entre interfaces exigidas e interfaces fornecidas. Cada componente pode compreender mais de uma classe de projeto.


Figura 1: Principal elemento dos diagramas de componentes da UML: componente.


Este modelo pode ser considerado correto quando contem todos os componentes necessários para realizar as funcionalidades especificadas pelos casos de uso e os requisitos não-funcionais.


• Códio-fonte


É a realização tecnológica dos modelos na linguagem de programação escolhida.

É importante que um padrão de codificação seja seguido e o código comentado para facilitar a leitura em futuras manutenções. Os modelos e o código devem sempre estar sincronizados, refletindo as mais recentes atualizações.

A disciplina de Projeto

Esta disciplina é a principal responsável pela elaboração da arquitetura. Ela utiliza-se dos artefatos produzidos na fase de Análise como base para a elaboração de uma arquitetura baseada em classes de projeto, ou classes concretas. Em geral procura-se unificar os diagramas e não mais manter um para cada caso de uso. Neste estágio é preciso ter uma idéia mais ampla da arquitetura como um todo, inclusive no que diz respeito a questões como flexibilidade, expansibilidade, manutenibilidade e reuso.

A disciplina de Projeto é fundamental em uma metodologia centrada em arquitetura. Realizar bem as tarefas neste momento pode garantir um bom tempo de resposta nas atualizações do software futuramente.

Questões como distribuição de objetos e utilização de frameworks também são consideradas.

Esta disciplina possui a mesma curva de intensidade da disciplina de Análise. Realmente, a análise e o projeto orientados a objetos estão altamente relacionados e se complementam.

Dois artefatos são produzidos durante esta disciplina. São eles:

• Modelo de Projeto:


Este modelo é formado por pacotes de projeto. Cada pacote representa um agrupamento lógico de diagramas estáticos, como o diagrama de classes, e dinâmicos, como o diagrama de seqüência e o diagrama de objetos.

Os diagramas estáticos são responsáveis por discriminar os relacionamentos entre as classes de projeto. Deve-se buscar um baixo acoplamento.

Já os diagramas dinâmicos exibem como cada uma das classes de projeto se comporta em tempo de execução. Técnicas como a Inversão de Dependência só podem ser visualizadas em diagramas deste tipo.


• Modelo de Instalação:


Define a organização física do sistema em termos de nós computacionais, os quais são peças de hardware que representam um recurso, como um servidor, uma estação de trabalho ou algum outro software.

Os componentes que formam a arquitetura residem nos nós computacionais. A listagem dos componentes deve ser apresentada no interior de cada nó.

O principal artefato deste modelo é o diagrama de instalação da UML, que discrimina como os nós se relacionam. Os diagramas podem ser agrupados logicamente em pacotes, denominados pacotes de instalação.

Outro objetivo deste modelo é apresentar ao cliente qual a infra-estrutura necessária para a correta execução do software. Este tipo de informação, quando entregue ao final da fase de Elaboração, faz que o cliente tenha tempo para preparar o ambiente.

A disciplina de Análise

É comum dizer que esta disciplina do Processo Unificado tem como foco principal realizar o primeiro “corte” na arquitetura. Em geral, cada caso de uso selecionado é analisado em termos de classes de análise. Ou seja, temos uma primeira representação estática dos casos de uso, uma arquitetura candidata.

Por ainda não serem classes de projeto (ou concretas), esta estrutura estática sofrerá alterações em iterações futuras. Mas, de certa forma, o processo de desenvolvimento começa a se distanciar dos clientes e a ganhar um foco mais técnico. Este fato está ilustrado na figura 1 do post “A estrutura do Processo Unificado”. Nela podemos perceber que enquanto a curva da Análise vai se intensificando, a curva dos Requisitos perde intensidade. Neste momento, provavelmente o processo encontra-se no inicio da fase de Elaboração.

Um artefato principal é produzido durante esta disciplina:

• Modelo de Análise


Este modelo é formado por pacotes de análise. Cada pacote representa um agrupamento lógico de diagramas de robustez da UML desenhados com classes de análise (ou objetos de Jacobson – Sim, ele mesmo, um dos criadores da UML!), e relacionamentos.




Figura 1: Objetos de Jacobson.



Cada classe de análise é classificada como Fronteira, Controle ou Entidade. Fronteira é um tipo de classe que interage com o ator. O Controle detém o conhecimento necessário para a correta execução do caso de uso, possui lógica. Já a Entidade, representa um conceito do domínio, muitas vezes é mapeada em uma tabela de banco de dados.

A disciplina de Requisitos

O foco desta disciplina do Processo Unificado é trabalhar para construir o sistema certo. No inicio do primeiro ciclo de um projeto, ainda não se sabe exatamente qual o sistema a ser construído. O domínio é obscuro e a descrição dos requisitos pelos clientes pode vir acompanhada de ambigüidades, contradições e redundâncias.

A Engenharia de Requisitos, um dos braços da Engenharia de Software, é uma ciência destinada exclusivamente à compreensão das metas e das necessidades dos clientes em um projeto de desenvolvimento de software. As práticas, técnicas e ferramentas providas por esta ciência são grandes aliadas para um bom trabalho nesta disciplina.

Grupos como “The Requirements Engineering Specialist Group”, conferências internacionais e periódicos acadêmicos nos dão idéia da amplitude da Engenharia de Requisitos. Neste artigo vamos nos reter a discutir as atividades básicas executadas na disciplina. Em artigos futuros poderemos nos aprofundar neste tema tão complexo.

Um ponto interessante é perceber que ciências sociais, ciência cognitiva e relacionamento interpessoal são características importantes em um Engenheiro de Requisitos. Neste momento do processo, existe uma forte interação deste profissional com o cliente e é preciso preparo para identificar as ambigüidades, as contradições e as redundâncias que eventualmente aparecem.

Quatro artefatos são produzidos durante esta disciplina. São eles:

• Modelo de Domínio:


Este modelo é responsável por exibir os conceitos principais do domínio em que o software está inserido e como estes se relacionam.

É frequentemente representado por diagramas de classes conceituais da UML, ou seja, não são classes de projeto. Alguns conceitos são mantidos e tornam-se classes de projeto na elaboração da arquitetura em iterações futuras, porém, é comum que algumas classes sejam apenas conceituais e não participem do software efetivamente.

Este modelo nos permite compreender com mais clareza o cenário em que os clientes estão envolvidos. Também é utilizado como fonte de inspiração para a nomenclatura de classes em iterações futuras.


• Modelo de Casos de Uso:


Deve ser visto como uma guia para todo o processo de desenvolvimento, representa a força condutora. A idéia principal é identificar os requisitos funcionais do sistema.

Uma vez que um dos princípios fundamentais do Processo Unificado é ser dirigido por casos de uso, temos idéia do quão fundamental é este modelo.

É formado por pacotes de casos de uso, representando, cada um deles, um agrupamento lógico de diagramas de casos de uso da UML. Complementando o modelo, existem descrições textuais estruturadas para cada caso de uso. As descrições devem possuir, pelo menos, as seguintes informações: nome do caso de uso, ator principal, pré-condições, pós-condições, fluxo básico e fluxos alternativos de execução.


• Requisitos Não-Funcionais:


Em 1992, Robert Grady listou cinco grupos de categorização de requisitos. A lista foi denominada FURPS, acrônimo com o seguinte significado, conforme o original em inglês:


• Functionality: Requisitos funcionais.


• Usability: Requisitos de usabilidade, como recursos de ajuda e acessibilidade.


• Reliability: Requisitos de confiabilidade, como capacidade de recuperação após falha.


• Performance: Requisitos de desempenho, como tempo de resposta e disponibilidade.


• Supportability: Requisitos de suporte, como facilidade de manutenção/configuração e internacionalização.


Como os requisitos funcionais já são cobertos pelo Modelo de Casos de Uso, o documento de requisitos não-funcionais deve conter apenas os quatro grupos restantes, ou seja, uma lista URPS.


• Referências:


Este documento é apenas uma sugestão e pode ser formado por três seções: Glossário, Premissas e Referências bibliográficas e eletrônicas.

O Glossário descreve os principais termos a serem utilizados no sistema. Cria um padrão de nomenclatura a ser utilizado pela equipe de desenvolvimento nos diálogos e na elaboração dos diversos artefatos durante o projeto. Frequentemente é uma derivação do Modelo de Domínio.

As Premissas são considerações que justificam algumas características do sistema. A idéia é fornecer um histórico dos pensamentos e das discussões ocorridas durante o desenvolvimento. Esta seção deve auxiliar na manutenção do sistema.

As Referências biográficas apontam quais os livros que auxiliaram no desenvolvimento pela sua teoria. Analogamente, as Referências eletrônicas apontam as páginas da Internet que foram utilizadas em eventuais pesquisas.

A estrutura do Processo Unificado

Em artigos anteriores, apresentei o conceito que define o paradigma do Processo Iterativo e os princípios fundamentais que definem uma de suas realizações mais evidentes, o Processo Unificado.

Mas como o UP (do original, em inglês, Unified Process) é estruturado?

Figura 1: Intensidade de cada uma das disciplinas no decorrer das fases em um ciclo.

Pois bem, a vida de um sistema de software é composta por uma série de ciclos. Ao final de cada ciclo, uma versão operacional do sistema é entregue aos interessados. Conforme ilustrado pela figura 1, um ciclo ainda é dividido em quatro fases: Concepção, Elaboração, Construção e Transição.

Resumidamente:

• A Concepção é a fase onde os objetivos do ciclo de vida são identificados. Esta fase diz o que deve ser feito. O domínio é analisado e os requisitos (funcionais e não-funcionais) são compreendidos e selecionados.


• A Elaboração é responsável pela arquitetura do sistema que será distribuído ao final do clico de vida. Esta fase diz como deve ser feito. É importante reforçar que a arquitetura deve suportar todos os requisitos selecionados. Lembre-se que um dos princípios fundamentais do UP é o fato deste ser Centrado em Arquitetura, ou seja, a Elaboração tende a ser uma fase crucial, recheada de desafios e questões complexas.


• Na Construção, como o próprio nome sugere, o sistema é implementado de acordo com o que foi elaborado na fase anterior. Questões puramente técnicas como o encapsulamento de classes lógicas em componentes físicos marcam a fase. O sistema deve possuir a capacidade operacional adequada.


• Por fim, a Transição é marcada pela liberação do produto aos interessados. O projeto deve ser preparado para possíveis ciclos futuros.

Cada fase é composta por uma seqüência de iterações. Tipicamente, a Concepção é composta de uma única iteração e a Transição de no máximo duas. Porém, as fases de Elaboração e de Construção contam com um número maior de iterações.

Uma característica marcante, também ilustrada na figura 1, é o fato de todas as iterações, e conseqüentemente todas as fases, serem atravessadas por todas as disciplinas, com maior ou menor intensidade.

São exatamente as disciplinas que possuem artefatos associados. Artefatos são documentos textuais ou diagramas da UML que facilitam a compreensão do sistema e a comunicação entre os envolvidos. Ou seja, é possível que um artefato de compreensão do domínio seja incrementado em mais de uma fase, mesmo sabendo que o entendimento do domínio é um dos principais objetivos da fase de Concepção.

A maioria dos artefatos produzidos ao longo dos ciclos pertence a um dos seis modelos apresentados na figura 2. Os modelos, contendo todos os seus artefatos, formam a documentação completa do processo de desenvolvimento. Esta documentação deve ser disponibilizada aos envolvidos a cada novo ciclo.

Um modelo por si só também pode ser considerado um artefato, porém, que possui outros artefatos internos, como diagramas completos e textos estruturados. Podemos qualificar um modelo como um agrupamento lógico semanticamente fechado.

Figura 2: Os seis modelos básicos do Processo Unificado.

Mesmo tendo mencionado que uma documentação que compreenda estes seis modelos é tida como completa, podemos adicionar outros documentos que sejam considerados relevantes.

Exemplos de documentos complementares:

• Modelo de Domínio


• Documento de requisitos não-funcionais


• Referências