Captulo 1

Qualidade do software
O principal objetivo da Engenharia de Software contribuir para a produo de programas de
qualidade. Esta qualidade, porm, no uma idia simples; mas sim como um conjunto de noes e fatores.
desejvel que os programas produzidos sejam rpidos, confiveis, modulares, estruturados,
modularizados, etc. Esses qualificadores descrevem dois tipos de qualidade:
De um lado, considera-se aspectos como eficincia, facilidade de uso, extensibilidade, etc.
Estes elementos podem ser detectados pelos usurios do sistema. A esses fatores atribui-se a
qualidade externa do sofware.
Por outro lado, existe um conjunto de fatores do programa que s profissionais de computao
podem detectar. Por exemplo, legibilidade, modularidade, etc. A esses fatores atribui-se a
qualidade interna do sofware.
Na realidade, qualidade externa do programa em questo que importa quando de sua utilizao. No
entanto, os elementos de qualidade interna so a chave para a conquista da qualidade externa. Alguns
fatores de qualidade externa so apresentados na prxima seo. A seo posterior trata da qualidade
interna, analisando como a qualidade externa pode ser atingida a partir desta.

Fatores de qualidade externa

Corretude
a condio do programa de produzir respostas adequadas e corretas cumprindo
rigorosamente suas tarefas de acordo com sua especificao.
Obviamente, uma qualidade primordial. Se um sistema no faz o que ele foi proposto a fazer, ento
qualquer outra questo torna-se irrelevante.

Robustez
a capacidade do programa de funcionar mesmo sob condies anormais.
A robustez do programa diz respeito ao que acontece quando do aparecimento de situaes anmalas.
Isto diferente de corretude, que define como o programa se comporta dentro de sua especificao. Na
robustez, o programa deve saber encarar situaes que no foram previstas sem efeitos colaterais
catastrficos. Neste sentido, o termo confiabilidade muito utilizado para robustez; porm denota um
conceito mais amplo que melhor interpretado como que englobando os conceitos de corretude e
robustez.

Extensibilidade
definida como a facilidade com que o programa pode ser adaptado para mudanas em sua
especificao.
Neste aspecto, dois princpios so essenciais:
Simplicidade de design: uma arquitetura simples sempre mais simples de ser adaptada ou
modificada
Descentralizao: quanto mais autnomos so os mdulos de uma arquitetura, maior ser a
probabilidade de que uma alterao implicar na manuteno de um ou poucos mdulos.

Capacidade de reuso
a capacidade do programa de ser reutilizado, totalmente ou em partes, para novas
aplicaes.

A necessidade de reutilizao vem da observao de que muitos elementos dos sistemas seguem
padres especficos. Neste sentido, possvel explorar este aspecto e evitar que a cada sistema produzido
os programadores fiquem reinventando solues de problemas j resolvidos anteriormente.

Compatibilidade
a facilidade com que o programa pode ser combinado com outros.
Esta uma qualidade importante pois os programas no so desenvolvidos stand-alone. Normalmente,
existe uma interao entre diversos programas onde o resultado de um determinado sistema utilizado
como entrada para outro.

Outros aspectos
Os aspectos resumidos acima so aqueles que podem ser beneficiados com a boa utilizao das
tcnicas de orientao por objetos. No entanto, existem outros aspectos que no podem ser esquecidos:
Eficincia: o bom aproveitamento dos recursos computacionais como processadores,
memria, dispositivos de comunicao, etc. Apesar de no explicitamente citado anteriormente,
este um requisito essencial para qualquer produto. A linguagem C++ em particular, por ser
to eficiente quanto C, permite o desenvolvimento de sistemas eficientes.
Portabilidade: a facilidade com que um programa pode ser transferido de uma plataforma
(hardware, sistema operacional, etc.). Este fator depende muito da base sobre a qual o sistema
desenvolvido. A nvel de linguagem, C++ satisfaz este fator por ser uma linguagem
padronizada com implementaes nas mais diversas plataformas.
Facildade de uso: a facilidade de aprendizagem de como o programa funciona, sua operao,
etc.

Modularidade - qualidade interna

Alguns fatores apresentados na seo anterior podem ser beneficiados com o uso de orientao por
objetos. So eles: corretude, robustez, extensibilidade, reuso e compatibilidade. Estes refletem as mais
srias questes para o desenvolvimento de programas. A medida que se olha para estes cinco aspectos,
dois subgrupos surgem:
Extensibilidade, reuso e compatibilidade demandam arquiteturas que sejam flexveis, design
descentralizado e a construo de mdulos coerentes conectados por interfaces bem definidas.
Corretude e robustez so favorecidos por tcnicas que suportam o desenvolvimento de sistemas
baseados em uma especificao precisa de requisitos e limitaes.
Da necessidade da construo de arquiteturas de programas que sejam flexveis, surge a questo de
tornar os programas mais modulares.
Uma definio precisa para modularidade dificilmente encontrada. No entanto, esta tcnica no traz
benefcios se os mdulos no forem autonmos, coerentes e organizados em uma estrutura robusta. Ser
utilizado no decorrer deste texto um conjunto de cinco critrios e cinco princpios.

Critrios para modularidade

Seguem abaixo cinco critrios que ajudam a avaliar/construir a modularidade do design:

Decomposio
O critrio de decomposio modular alcanado quando o modelo de design ajuda a decomposio
do problema em diversos outros subproblemas cujas solues podem ser atingidas separadamente.
O mtodo deve ajudar a reduzir a aparente complexidade de problema inicial pela sua decomposio
em um conjunto de problemas menores conectados por uma estrutura simples. De modo geral, o processo
repetitivo: os subproblemas so tambm divididos em problemas menores e assim sucessivamente.
Uma exemplificao deste tipo de design o chamado mtodo top-down. Este mtodo dirige os
desenvolvedores a comear com uma viso mais abstrata do funcionamento do sistema. Esta viso
abstrata vai sendo refinada como um conjunto de passos sucessivos menores e assim por diante at que
seus elementos estejam em um nvel que permita sua implementao. Este processo pode ser modelado
como uma rvore.

Composio
O mtodo que satisfaz o critrio de composio favorece a produo de elementos de programas que
podem ser livremente combinados com os outros de forma a produzir novos sistemas, possivelmente em
um ambiente bem diferente daquele em que cada um destes elementos foi criado.
Enquanto que a decomposio se concentra na diviso do software em elementos menores a partir da
especificao, a composio se estabelece no sentido oposto: agregando elementos de programas que
podem ser aplicados para construo de novos sistemas.
A composio diretamente relacionada com a questo da reutilizao: o objetivo achar maneiras de
desenvolver pedaos de programas que executam tarefas bem definidas e utilizveis em outros contextos.
Este contexto reflete um sonho antigo: transformar o processo de design de programas como elementos
independentes onde programas so construdos pela combinao de elementos existentes.
Um exemplo deste tipo de abordagem a construo de bibliotecas como conjuntos de elementos que
podem ser utilizados em diversos programas (pacotes grficos, bibliotecas numricas, etc.).

Entendimento
Um mtodo que satisfaz o critrio de entendimento ajuda a produo de mdulos que podem ser
separadamente compreeendidos pelos desenvolvedores; no pior caso, o leitor deve ter ateno sobre
poucos mdulos vizinhos. Este critrio especialmente relevante quando se tem em vista o aspecto da
manuteno.
Um contra-exemplo deste tipo de mtodo quando h dependncia sequencial onde um conjunto de
mdulos elaborado de modo que a execuo dos mesmos seja feita em uma ordem determinada. Desta
forma, os mdulos no so entendidos de forma individual mas em conjunto com seus vizinhos.

Continuidade
Um mtodo de design satisfaz a continuidade se uma pequena mudana na especificao do problema
resulta em alteraes em um nico ou poucos mdulos. Tal alterao no tem reflexos na arquitetura geral
do sistema; isto , no relacionamento inter-modular.
Este critrio reflete o problema de extensibilidade do sistema. A continuidade significa que eventuais
mudanas devem afetar os mdulos individualmente da estrutura do sistema e no a estrutura em si.
Um exemplo simples deste tipo de critrio a utilizao de constantes representadas por nomes
simblicos definidos em um nico local. Se o valor deve ser alterado, apenas a definio deve ser
alterada.

Proteo
Um mtodo de design satisfaz a proteo se este prov a arquitetura de isolamento quando da
ocorrncia de condies anmalas em tempo de execuo. Ao aparecimento de situaes anormais, seus
efeitos ficam restritos quele mdulo ou pelo menos se propagar a poucos mdulos vizinhos.
Os erros considerados neste critrio so somente aqueles ocorridos em tempo de execuo como falta
de espao em disco, falhas de hardware, etc. No se considera, neste caso, a correo de erros, mas um
aspecto importante para a modularidade: sua propagao.

Princpios de modularidade
Estabelecidos os critrios de modularidade, alguns princpios surgem e devem ser observados
cuidadosamente para se obter modularidade. O primeiro princpio se relaciona com a notao e os outros
se baseiam no modo de comunicao entre os mdulos.
Seguem abaixo estes princpios:

Lingustica modular
Este princpio expressa que o formalismo utilizado para expressar o design, programas, etc. deve
suportar uma viso modular; isto :
Mdulos devem correspoder s unidades sintticas da linguagem utilizada.
Onde a linguagem utilizada pode ser qualquer linguagem de programao, de design de sistemas, de
especificao, etc.
Este princpio segue de diversos critrios mencionados anteriormente:

Decomposio: Se pretende-se dividir o desenvolvimento do sistema em tarefas separadas,

cada uma destas deve resultar em uma unidade sinttica bem delimitada. (compilveis
separadamente no caso de linguagens de programao)
Composio: S pode-se combinar coisas como unidades bem delimitadas.
Proteo: Somente pode haver controle do efeito de erros se os mdulos esto bem
delimitados.

Poucas interfaces
Este princpio restringe o nmero de canais de comunicao entre os mdulos na arquitetura do
sistema. Isto quer dizer que:
Cada mdulo deve se comunicar o mnimo possvel com outros.
A comunicao pode ocorrer das mais diversas formas. Mdulos podem chamar funes de outros,
compartilhar estruturas de dados, etc. Este princpios limita o nmero destes tipos de conexo.

Pequenas interfaces
Este princpio relaciona o tamanho das interfaces e no suas quantidades. Isto quer dizer que:
Se dois mdulos possuem canal de comunicao, estes devem trocar o mnimo de informao
possvel; isto , os canais da comunicao inter-modular devem ser limitados.

Interfaces explcitas
Este um princpio que vai mais adiante do que poucas interfaces e pequenas interfaces. Alm de
impor limitaes no nmero de mdulos que se comunicam e na quantidade de informaes trocadas, h a
imposio de que se explicite claramente esta comunicao. Isto :
Quando da comunicao de dois mdulos A e B, isto deve ser explcito no texto de A, B ou
ambos.
Este princpio segue de diversos critrios mencionados anteriormente:
Decomposio e composio: Se um elemento formado pela composio ou decomposio
de outros, as conexes devem ser bem claras entre eles.
Entendimento: Como entender o funcionamento de um mdulo A se seu comportamento
influenciado por outro mdulo B de maneira no clara?

Ocultao de informao (information hiding)

A aplicao deste princpio assume que todo mdulo conhecido atravs de uma descrio oficial e
explcita; ou melhor sua interface. Pela definio, isto requer que haja uma viso restrita do mdulo.
Toda informao sobre um mdulo deve ser oculta (privada) para outro a no ser que seja
especificamente declarada pblica.
A razo fundamental para este princpio o critrio de continuidade. Se um mdulo precisa ser
alterado, mas de maneira que s haja manuteno de sua parte no pblica e no a interface; ento os
mdulos que utilizam seus recursos (clientes) no precisam ser alterados. Alm, quanto menor a interface,
maiores as chances de que isto ocorra.
Apesar de no haver uma regra absoluta sobre o que deve ser mantido pblico ou no, a idia geral
simples: a interface deve ser uma descrio do funcionamento do mdulo. Tudo que for relacionado com
sua implementao no deve ser pblico.
importante ressaltar que, neste caso, este princpio no implica em proteo no sentido de restries
de segurana. Embora seja invisvel, pode haver acesso s informaes internas do mdulo.

Calculadora RPN em C
Os primeiros exemplos sero feitos a partir de um programa escrito em C. Vrias modificaes sero
feitas at que este se torne um programa C++. O programa uma calculadora RPN (notao polonesa
reversa), apresentada nesta seo.

Este tipo de calculadora utiliza uma pilha para armazenar os seus dados. Esta pilha est implementada
em um mdulo parte. O header file et listado abaixo:
#ifndef stack_h
#define stack_h
#define MAX 50
struct Stack {
int top;
int elems[MAX];
};
void push(struct Stack* s, int i);
int pop(struct Stack* s);
int empty(struct Stack* s);
struct Stack* createStack(void);
#endif
A implementao destas funes est no arquivo stack-c.c:
#include <stdlib.h>
#include "stack-c.h"
void push(struct Stack*s, int i) { s->elems[s->top++] = i; }
int pop(struct Stack*s)
{ return s->elems[--(s->top)]; }
int empty(struct Stack*s)
{ return s->top == 0; }
struct Stack* createStack(void)
{
struct Stack* s = (struct Stack*)malloc(sizeof(struct Stack));
s->top = 0;
return s;
}
A calculadora propriamente dita utiliza estes arquivos:
#include <stdlib.h>
#include <stdio.h>
#include "stack-c.h"
/* dada uma pilha, esta funo pe nos
parmetros n1 e n2 os valores do topo
da pilha. Caso a pilha tenha menos de dois
valores na pilha, um erro retornado */
int getop(struct Stack* s, int* n1, int* n2)
{
if (empty(s))
{
printf("empty stack!\n");
return 0;
}
*n2 = pop(s);
if (empty(s))
{
push(s, *n2);
printf("two operands needed!\n");
return 0;
}
*n1 = pop(s);
return 1;
}

/* a funo main fica em um loop

lendo do teclado os comandos da calculadora.
Se for um nmero, apenas empilha.
Se for um operador, faz o calculo.
Se for o caracter 'q', termina a execuo.
Aps cada passo a pilha mostrada. */
int main(void)
{
struct Stack* s = createStack();
while (1)
{
char str[31];
int i;
printf("> ");
gets(str);
if (sscanf(str, "%d", &i)==1) push(s, i);
else
{
int n1, n2;
char c;
sscanf(str, "%c", &c);
switch(c)
{
case '+':
if (getop(s, &n1, &n2)) push(s, n1+n2);
break;
case '-':
if (getop(s, &n1, &n2)) push(s, n1-n2);
break;
case '/':
if (getop(s, &n1, &n2)) push(s, n1/n2);
break;
case '*':
if (getop(s, &n1, &n2)) push(s, n1*n2);
break;
case 'q':
return 0;
default:
printf("error\n");
}
}
{
int i;
for (i=0; i<s->top; i++)
printf("%d:%6d\n", i, s->elems[i]);
}
}
}

Tipos abstratos de dados

O conceito de tipo foi um passo importante no sentido de atingir uma linguagem capaz de suportar
programao estruturada. Porm, at agora, no possvel usar uma metodologia na qual os programas
sejam desenvolvidos por meio de decomposies de problemas baseadas no reconhecimento de
abstraes. Para a abstrao de dados adequada a este propsito no basta meramente classificar os
objetos quanto a suas estruturas de representao; em vez disso, os objetos devem ser classificados de
acordo com o seu comportamento esperado. Esse comportamento expressado em termos das operaes
que fazem sentido sobre esses dados; estas operaes so o nico meio de criar, modificar e se ter acesso
aos objetos.

Classes em C++
Uma classe em C++ o elemento bsico sobre o qual toda orientao por objetos est apoiada. Em
primeira instncia, uma classe uma extenso de uma estrutura, que passa a ter no apenas dados, mas
tambm funes. A idia que tipos abstratos de dados no so definidos pela sua representao interna, e
sim pelas operaes sobre o tipo. Ento no h nada mais natural do que incorporar estas operaes no
prprio tipo.Estas operaes s fazem sentido quando associadas s suas representaes.
No exemplo da calculadora, um candidato natural a se tornar uma classe a pilha. Esta uma
estrutura bem definida; no seu header file esto tanto a sua representao (struct Stack) quanto as funes
para a manipulao desta representao. Seguindo a idia de classe, estas funes no deveriam ser
globais, mas sim pertencerem estrutura Stack. A funo empty seria uma das que passariam para a
estrutura. A implementao de empty pode ficar dentro da prpria estrutura:
struct Stack {
// ...
int empty() { return top == 0; }
};
ou fora:
struct Stack {
// ...
int empty();
};
int Stack::empty(void) { return top == 0; }
No segundo caso a declarao fica no header file e a implementao no .c. A diferena entre as duas
opes ser explicada na seo sobre funes inline.
Com esta declarao, as funes so chamadas diretamente sobre a varivel que contm a
representao:
void main(void)
{
struct Stack s;
s.empty();
}
Repare que a funo deixou de ter como parmetro uma pilha. Isto era necessrio porque a funo
estava isolada da representao. Agora no, a funo faz parte da estrutura. Automaticamente todos os
campos da estrutura passam a ser visveis dentro da implementao da funo, sem necessidade se
especificar de qual pilha o campo top deve ser testado (caso da funo empty). Isto j foi dito na chamada
da funo.

O paradigma da orientao a objetos

Esta seo apresenta cinco componentes chave do paradigma de orientao por objetos. As
componentes so objeto, mensagem, classe, instncia e mtodo. Eis as definies:
Objeto: uma abstrao encapsulada que tem um estado interno dado por uma lista de
atributos cujos valores so nicos para o objeto. O objeto tambm conhece uma lista de
mensagens que ele pode responder e sabe como responder cada uma. Encapsulamento e
abstrao so definidos mais frente.
Mensagem: representada por um identificador que implica em uma ao a ser tomada pelo
objeto que a recebe. Mensagens podem ser simples ou podem incluir parmetros que afetam
como o objeto vai responder mensagem. A resposta tambm influenciada pelo estado
interno do objeto.
Classe: um modelo para a criao de um objeto. Inclui em sua descrio um nome para o tipo
de objeto, uma lista de atributos (e seus tipos) e uma lista de mensagens com os mtodos
correspondentes que o objeto desta classe sabe responder.
Instncia: um objeto que tem suas propriedades definidas na descrio da classe. As
propriedades que so nicas para as instncias so os valores dos atributos.
Mtodo: uma lista de instrues que define como um objeto responde a uma mensagem em
particular. Um mtodo tipicamente consiste de expresses que enviam mais mensagens para
objetos. Toda mensagem em uma classe tem um mtodo correspondente.

Traduzindo estas definies para o C++, classes so estruturas, objetos so variveis do tipo de
alguma classe (instncia de alguma classe), mtodos so funes de classes e enviar uma mensagem para
um objeto chamar um mtodo de um objeto.
Resumindo:
Objetos so instncias de classes que respondem a mensagens de acordo com os mtodos e
atributos, descritos na classe.

Exerccio 1 - Calculadora RPN com classes

Transformar a pilha utilizada pela calculadora em uma classe.