Programação por Contrato na Disciplina de Introdução à Programação

Transcrição

1 Programação por Contrato na Disciplina de Introdução à Programação Sebenta de apoio Departamento de Informática Faculdade de Ciências Universidade de Lisboa Isabel Nunes Novembro 2004

2 Índice Introdução 1 Ocultação da representação 1 Programação por contrato.. 7 Pré e pós-condições. 7 Como exprimir asserções?.10 A linguagem de especificação..11 Construção de contratos.11 Invariantes.15 Correcção de uma classe.16 Monitorização de classes 16 Resumindo e concluindo 18 Alguns passos a seguir na construção de classes e seus contratos:18 Utilização de asserções:..18 Monitorização de asserções em tempo de execução:..19 Bibliografia 19

3 Introdução Esta sebenta pretende dar aos alunos um suporte de estudo para a programação por contrato. Não conhecemos nenhum livro introdutório de programação centrada em objectos, baseado na linguagem Java, que faça uma abordagem cuidada e completa desta filosofia de desenho e programação. Daí esta sebenta. Começamos por motivar a nossa opção de esconder a forma como representamos os objectos. Isso permite-nos introduzir, de uma forma bastante natural, a motivação para o uso da programação por contrato. Ocultação da representação Quando construimos uma classe estamos a implementar um tipo de dados pois escolhemos uma forma específica de representar o estado dos seus elementos uma representação e uma forma específica de implementar o seu comportamento. Existem várias razões para que a representação escolhida para o estado dos objectos os seus atributos seja escondida das classes cliente: 1. minimização das alterações às classes cliente aquando de uma mudança na representação da classe fornecedora; 2. segurança nas alterações aos valores dos atributos. Minimização das alterações: Se as classes cliente não dependerem da representação dos atributos do objecto fornecedor então, quando for necessário alterar essa representação, as classes cliente não terão que ser alteradas; Vamos supor que os atributos x e y da classe Point tinham sido declarados como public: * Uma classe que descreve pontos num plano ortonormado. public class Point { * A abcissa do ponto. public double x; * A ordenada do ponto. public double y; Introdução à Programação 2004/2005 1

4 * A distância deste ponto à origem. public double rho () { return Math.sqrt (x * x + y * y); * O ângulo que a recta que une este ponto à origem * faz com a parte positiva do eixo horizontal. public double theta () { if (iszero(x) && iszero(y)) return 0.0; if (iszero(x)) return x > 0.0? Math.PI / 2 : 3 * Math.PI / 2; return y > 0? Math.atan(y / x) : Math.atan(y / x) + Math.PI; //fim da classe Point Se assim fosse, nada seria escondido; tanto os atributos como os métodos seriam de domínio público. Os atributos x e y representam valores armazenados em memória. Os métodos rho e theta são implementados de forma a devolverem a distância à origem rho e o ângulo que o ponto faz com o eixo dos xx theta; estes valores são calculados a partir dos valores dos atributos x e y. Então, numa qualquer classe cliente da classe Point, por exemplo Rectangle, podemos ter algo do estilo: Point p; System.out.println("Abcissa=" + p.x + " Ordenada=" + p.y); System.out.println("Ordenada na origem=" + p.rho() + " Ângulo com o eixo dos xx=" + p.theta()); Agora imaginemos que decidimos alterar a representação de Point, ou seja, alterar a forma como representamos o seu estado. Porque os nossos clientes utilizam essencialmente rotações, interessa-nos antes armazenar a distância à origem e o ângulo que o ponto faz com o eixo dos xx. Então, a classe Point ficaria: public class Point { * A distância do ponto à origem. public double rho; * O ângulo que a recta que une o ponto à origem * faz com a parte positiva do eixo horizontal. public double theta; 2 Introdução à Programação 2004/2005

5 * A abcissa do ponto. public double x () { return rho * Math.cos(theta); * A ordenada do ponto. public double y () { return rho * Math.sin(theta);. //fim da classe Point Agora rho e theta são valores armazenados em memória e x() e y() são calculados a partir dos valores de rho e theta, ou seja, são métodos. Se voltarmos a olhar para o conjunto de instruções que tínhamos na classe Rectangle, verificamos que deixaram de estar correctas! Esta alteração da classe Point obriga a várias alterações na classe Rectangle, ou seja: Point p; System.out.println("Abcissa=" + p.x() + " Ordenada=" + p.y()); System.out.println("Ordenada na origem=" + p.rho + " Ângulo com o eixo dos xx=" + p.theta); As alterações a fazer aparecem a sublinhado no exemplo. Agora imaginem que a classe Point tinha muitos outros clientes em muitas e diversas aplicações Esta obrigação de alterar as classes cliente é provocada pelo facto de que estas classes dependem da representação escolhida para os objectos da classe Point, ou seja, a representação não foi escondida. A forma ideal de proceder é esconder os atributos e definir funções que revelam o estado, mas sem revelar o tipo de representação escolhido: public class Point { private double x,y; // atributos são privados * A abcissa do ponto. public double x () { return x; * A ordenada do ponto. public double y () { return y; Introdução à Programação 2004/2005 3

6 * A distância deste ponto à origem. public double rho () { return Math.sqrt (x * x + y * y); * O ângulo que a recta que une este ponto à origem * faz com a parte positiva do eixo horizontal. public double theta () { if (iszero(x) && iszero(y)) return 0.0; if (iszero(x)) return x > 0.0? Math.PI / 2 : 3 * Math.PI / 2; return y > 0? Math.atan(y / x) : Math.atan(y / x) + Math.PI;. //fim da classe Point ou: public class Point { * A distância do ponto à origem e o O ângulo que a * recta que une o ponto à origem * faz com a parte positiva do eixo horizontal. private double rho,theta; // atributos são privados * A distância do ponto à origem. public double rho () {return rho; * O ângulo que a recta que une este ponto à origem * faz com a parte positiva do eixo horizontal. public double theta () { return theta; * A abcissa do ponto. public double x () { return rho * Math.cos(theta);. * A ordenada do ponto. public double y () { return rho * Math.sin(theta); 4 Introdução à Programação 2004/2005

7 //fim da classe Point Qualquer classe cliente de Point teria que aceder ao seu estado através das funções postas ao seu dispôr: Point p; System.out.println("Abcissa=" + p.x() + " Ordenada=" + p.y()); System.out.println("Ordenada na origem=" + p.rho() + " Ângulo com o eixo dos xx=" + p.theta()); A classe a que pertence este excerto é um cliente correcto de ambas as classes, ou seja, se tivéssemos a representação cartesiana e a alterássemos para polar, não tínhamos que alterar estas instruções. Segurança nas alterações: Se as classes cliente não tiverem acesso directo aos atributos do objecto fornecedor, não poderão alterar os valores destes de formas não autorizadas; Consideremos agora uma classe que representa uma pessoa: * Uma classe que descreve uma pessoa, seu nome e idade. public class Person { * Nome da pessoa public String name; * A idade da pessoa public int age; * Construtor public Pessoa (String name, int age) { this.name = name; this.age = age;. //fim da classe Person Como os atributos são de acesso público, qualquer objecto do tipo Person pode ver alterada a sua idade para valores não autorizados, p.ex., valores negativos: Person p = new Person ("Miguel", 23); p.age = -10; Introdução à Programação 2004/2005 5

8 Devemos, então, declarar os atributos como sendo de acesso privado e, se for caso disso, fornecer métodos que permitam a sua alteração de forma controlada: public class Person { // Nome da pessoa private String name; // A idade da pessoa private int age; * Construtor public Pessoa (String name, int age) { this.name = name; this.age = age; * Nome da pessoa public String name () { return name; * A idade da pessoa public int age () { return age; * Alterar a idade da pessoa param newage O novo valor para a idade public void setage (int newage) { if (newage >= 0) age = newage; else. // o que fazer?. //fim da classe Person Desta forma, a idade de um objecto do tipo Person só poderá ser alterada para valores maiores ou iguais a zero. Concluindo: ocultamos a representação de todas as classes que criamos declarando os atributos como privados. Para aqueles que queremos dar a conhecer às classes cliente, construimos funções públicas que retornam o seu valor. Para aqueles cuja alteração (controlada) queremos permitir, construimos procedimentos que, dados novos valores para esses atributos, alterem, de forma controlada, os seus valores. 6 Introdução à Programação 2004/2005

9 Programação por contrato No último exemplo da secção anterior, no método setage (int newage), utilizámos aquilo a que se chama programação defensiva. Assim, demos à classe Person, que é a classe fornecedora do método, a responsabilidade de verificar a legalidade da invocação do método. A essa responsabilidade acresce ainda a de decidir o que fazer quando o valor do argumento newage é ilegal (menor que zero). Ora, no âmbito da classe Person não sabemos que classes é que vão usar objectos do tipo Person, para que é que os vão usar, em que contextos é que os vão usar e assim por diante. Ou seja, desconhecemos o que devemos fazer nos casos não autorizados de utilização do método. Se não sabemos como resolver o problema para todos os casos, resolvemo-lo bem apenas para aqueles casos que sabemos. Então, o ideal é que na documentação da classe Person apareça um "aviso" alertando para o facto de que o método setage só pode ser utilizado com argumentos de valor positivo ou zero. É desejável ainda que se informem as classes cliente de qual será o efeito da execução do método nos casos em que é chamado com valores legais para o argumento. Neste exemplo o efeito da execução do método será que a idade do objecto alvo da invocação ficará igual ao valor do argumento. Pré e pós-condições Usamos duas categorias adicionais de documentação associada a um método: précondições (@requires) e pós-condições (@ensures). Chamamos asserções a estas condições. As pré-condições exprimem restrições sob as quais um método funciona adequadamente. As pós-condições exprimem uma propriedade do estado resultante da execução do método (admitindo que foi invocado com a pré-condição satisfeita). public class Person { * Nome da pessoa private String name; * A idade da pessoa private int age; * Construtor public Pessoa (String name, int age) { this.name = name; this.age = age; Introdução à Programação 2004/2005 7

10 * Nome da pessoa public String name () { return name; * A idade da pessoa public int age () { return age; * Alterar a idade da pessoa param newage O novo valor para a idade requires o valor de newage deve ser positivo ou ensures a idade da pessoa tem um valor igual ao de public void setage (int newage) { if (newage >= 0) age = newage; else. // o que fazer?. //fim da classe Person As classes cliente de Person devem então ser responsáveis por chamar esse método unicamente em situações legais se querem obter o efeito desejado. Usando a informação que é fornecida pela pré-condição, só vamos invocar o método para valores do argumento positivos ou zero: Scanner scanner = new Scanner(System.in); Person p = new Person("Miguel", 23); System.out.println("Qual a nova idade para o " + p.name() + "?"); int nova = scanner.nextint(); if (nova >= 0) p.setage(nova); else System.out.println("Idade inválida"); A classe onde se encontram estas instruções é uma classe cliente bem comportada pois só invoca o método quando há a certeza que o pode fazer. É a classe onde se encontra a invocação do método que sabe o que fazer em situações ilegais! Neste caso poderíamos fazer sair uma mensagem no ecrã. Solução bastante diferente é adoptada no caso seguinte: pretende-se usar um objecto do tipo Person para representar a idade "estética" de alguém, idade esta que também deverá ser não negativa. As pessoas são sujeitas a tratamentos que, eventualmente, as rejuvenescem e que vão diminuir a sua idade estética. Se o número de anos que rejuvenesceu for maior que a idade que tem, então pretende-se que a nova idade seja zero - uma solução diferente da anterior que fazia sair uma mensagem no ecrã. 8 Introdução à Programação 2004/2005

11 Scanner scanner = new Scanner(System.in); Person p = new Person("Miguel", 34); System.out.println("Depois do tratamento de rejuvenescimento, + quantos anos acha que " + p.name() + " rejuvenesceu?"); int anos = scanner.nextint(); int nova = p.idade() - anos; // Nova idade "estética" if (nova >= 0) p.setidade(nova); else p.setidade(0); Verificamos por estes exemplos que, realmente, quem sabe o que deve ser feito em casos não autorizados são as classes cliente e não a classe fornecedora. Nesta abordagem verifica-se primeiro se o método pode ser invocado e só depois de ter a confirmação é que é feita a invocação. Como vimos acima, se o cliente é que sabe o que fazer em situações ilegais, então o fornecedor não deve testar no corpo do método se a invocação é legal ou não: Isto leva-nos ao princípio da não-redundância: "Em circunstância alguma deve o corpo do método testar a pré-condição". É esta a chave da programação por contrato. A ideia é que as classes cliente - C - e fornecedor - F - estabelecem um contrato em relação a cada método m i da classe fornecedora: "Se C invoca o método m i num estado que satisfaz a pré-condição de mi, então F garante que o estado obtido com a execução de m i satifaz a pós-condição de m i ". Nos casos em que m i é invocado num estado que não satisfaz a sua pré-condição, a classe fornecedora não se responsabiliza pelo estado que é obtido pela execução de m i. Nos casos em que m i é invocado num estado que satisfaz a sua pré-condição, é esperado que a execução do método leve a um estado que satisfaz a sua pós-condição. Podemos esquematizar estas ideias em termos de direitos e obrigações da seguinte forma: setage(int newage) Obrigações Direitos Cliente Fornecedor Satisfazer pré-condição (Invocar setage com um valor não negativo do argumento) Satisfazer pós-condição (Actualizar a idade) Ver satisfeita a pós-condição (Certeza de que a idade foi alterada como pretendido) Ver satisfeita a pré-condição ou, à falta disso, não ter obrigações (Código mais simples pois não tem que verificar a précondição) Isto leva-nos à regra da violação de asserções: "A violação de uma asserção em tempo de execução é uma manifestação de erro na aplicação" Mais especificamente: Introdução à Programação 2004/2005 9

12 "A violação de uma pré-condição é a manifestação de um erro no cliente; a violação de uma pós-condição é a manifestação de um erro no fornecedor." A metodologia do desenho por contrato estabelece que nunca devemos invocar um método sem termos a certeza que a pré-condição desse método se verifica. Diz-nos ainda que, sempre que invocarmos um método com a sua pré-condição satisfeita, podemos ter a certeza de que, após a execução, obtemos um estado que satisfaz a póscondição de método. Diz ainda que não devemos testar a pré-condição de um método no corpo do próprio método. É óbvio que isto não se deve aplicar a relações utilizador/programa! Não é o facto de dizermos ao utilizador que introduza um valor entre 15 e 50 que faz com que possamos confiar cegamente que o valor introduzido está nesse intervalo. Pelo contrário! Todos os valores solicitados ao utilizador devem ser validados antes de serem trabalhados. Por exemplo: Scanner scanner = new Scanner(System.in); Person p = new Person("Miguel",23); System.out.println("Qual a nova idade para o " + p.nome() + "? (deverá ser um valor entre 0 e 120)"); int nova = scanner.nextint(); p.setidade(nova); Isto seria impensável! Estamos aqui a usar um valor que é suposto representar uma idade sem nos certificarmos de que o utilizador introduziu um valor que possa realmente ser usado como uma idade (por exemplo entre zero e 120). Estamos a confiar cegamente no utilizador. No entanto todos nós sabemos que, mesmo sem intenção, qualquer utilizador se engana inúmeras vezes e deseja que o programa que está a utilizar seja suficientemente robusto para aguentar isso. A classe onde se encontra este conjunto de instruções não é uma boa classe cliente da classe Person pois não segue a metodologia do desenho por contrato: não se certifica que a pré-condição do método setage() é verdadeira antes de o invocar. Como exprimir asserções? Ou seja, como exprimir a especificação? A aplicação destas regras e dos princípios da programação por contrato leva-nos a exigir um muito maior rigor na forma como exprimimos as pré e as pós-condições: 1. Não podem ser ambíguas pois são elas que estabelecem o contrato; 2. Devem estar sempre acessíveis aos autores das classes cliente; 3. A pré-condição deve poder ser testada nas classes cliente; 4. Outras restrições que se prendem com a verificação e monitorização de contratos (mais adiante). A primeira destas restrições resolve-se usando uma linguagem para escrita de asserções que tenha uma sintaxe e uma semântica bem definidas. A segunda restrição obriga a um esforço, que é recompensador, de documentação da classe através da especificação dos contratos para os vários métodos. A terceira restrição resolve-se exprimindo as pré-condições à custa de elementos acessíveis na classe fornecedora (veremos mais adiante o que isto significa). 10 Introdução à Programação 2004/2005

13 A linguagem de especificação Existem várias linguagens de especificação de contratos cada uma com as suas características. Existe até uma linguagem de programação que tem asserções embebidas - a linguagem Eiffel, que é usada no livro do B. Meyer. Queremos uma linguagem para a qual existam ferramentas que permitam monitorizar os contratos em tempo de execução (mais adiante neste texto), o que reduz o conjunto das candidatas. Vamos adoptar a linguagem JML Java Modeling Language ( Nesta linguagem construimos asserções como expressões booleanas do Java com umas poucas extensões. São elas: 1. \result - representa o valor de retorno de uma função; só pode ser usado nas póscondições 2. \old - aplicado a uma expressão, denota o valor que a expressão tinha imediatamente antes do método ser executado; só pode ser usado nas póscondições 3. \implies ou ==> - operador booleano binário de operandos booleanos; o seu resultado é falso quando o primeiro operando (antecedente) é verdadeiro e o segundo operando (consequente) é falso; o resultado é verdadeiro nos outros casos 4. \forall - permite verificar se todos os elementos de um dado conjunto verificam uma determinada condição; 5. \exists - permite verificar se algum elemento de um dado conjunto satisfaz uma determinada condição. Tal como apresentado acima, as asserções colocam-se no cabeçalho (em comentário) imediatamente antes do método a que respeitam e são precedidas pelos * Alterar a idade da pessoa param newage O novo valor para a idade requires newage >= ensures age() == public void setage (int newage) {. Nota: para podermos usar a função age() neste contrato JML temos que a ter declarado como pure, significando que é um método que não altera o estado dos objectos envolvidos. A assinatura de age() deveria então ser: public /*@ int age () Construção de contratos Não incluimos o corpo do método propositadamente. Vamos olhar para o contrato com os olhos do autor de uma classe cliente e esse não conhece, nem deve conhecer, a Introdução à Programação 2004/

14 forma como a classe está implementada (ou seja, não conhece os atributos privados nem o corpo dos métodos). Consideremos a pré-condição como uma expressão boolena que vai ser avaliada no estado em que o método vai iniciar a sua execução; e a pós-condição como uma expressão boolena que vai ser avaliada no estado resultante da execução do método. A pré-condição será verdadeira nos estados em que o valor do parâmetro - newage - é positivo ou zero. A pós-condição será verdadeira nos estados em que o valor retornado pela função age() (que é, como sabemos, o valor da idade do objecto em causa) é igual ao valor do parâmetro. Isto significa que o fornecedor compromete-se a alterar a idade do objecto para o valor dado na invocação do método (se esse valor for não negativo, como é "dito" na pré-condição). O autor da classe cliente tem na pré-condição a informação do teste que deve fazer antes de invocar o método: certificar-se que o valor do argumento na invocação é não negativo. Tem na pós-condição a informação de que, após a execução do método, a função age() retorna, quando invocada, o valor dado como argumento. Então ele sabe que o seguinte excerto de programa está correcto, partindo do princípio que o fornecedor também está correcto: Scanner scanner = new Scanner(System.in); Person p = new Person("Miguel", 23); System.out.println("Qual a nova idade para o " + p.name() + "?"); int nova = scanner.nextint(); if (nova >= 0){ p.setidade(nova); System.out.println("Alteração efectuada com sucesso"); else System.out.println("Idade inválida"); O autor consegue obter estas informações porque sabe o que significam as várias componentes do contrato: o identificador newage é o parâmetro ao qual será atribuído o valor da variável nova aquando da execução de p.setidade(nova); a função age() é uma função pública da classe fornecedora e portanto ele sabe da sua existência e significado. Se num contrato usamos referências a componentes privadas, que o cliente não conhece, nem é suposto ter que conhecer, obtemos um contrato que não é útil para ser usado pelas classes cliente, porque elas não o vão poder usar para controlar a invocação do método e os efeitos dessa invocação. Por exemplo: * Alterar a idade da pessoa param newage O novo valor para a idade requires ensures age() == public void setage (int newage) {. 12 Introdução à Programação 2004/2005

15 * Um dado inteiro é superior ou igual a zero? param n O O inteiro private /*@ boolean checkvalue (int n) {. Repare-se que a função checkvalue(int n) é privada e, como tal, não aparece na documentação oficial da classe. Isto significa que é impossível a qualquer classe cliente perceber a pré-condição do método setage. É também impossível a qualquer classe cliente invocar esse método de forma correcta porque, para além de não entender a pré-condição, também não a consegue testar pois a função checkvalue, sendo privada, é inacessível a qualquer classe cliente. Enunciamos então o princípio da pré-condição razoável: "A pré-condição de cada método deve: i) aparecer na documentação oficial distribuída aos autores das classes cliente; ii) ser justificável em termos da especificação apenas." e ainda a regra da disponibilidade da pré-condição: "As referências que aparecem na pré-condição devem estar todas acessíveis - públicas - para que as classes cliente as possam testar". Isto inclui: funções públicas, argumentos dos métodos, constantes públicas. Não inclui: informação privada e métodos que alterem o estado (que não sejam pure). Voltando ao princípio da não-redundância Um entusiasta da programação defensiva poderá contrapôr: "posso obter o mesmo efeito que a partir das pré-condições fazendo com que o método retorne um código que identifique o (in)sucesso da operação", por exemplo: * Alterar a idade da pessoa se a nova idade for igual * ou superior a zero (usando programação defensiva) param newage O novo valor para a idade return 0 se newage >= 0; 1 caso contrário public int setage (int newage) { if (newage >= 0) { age = newage; return 0; else return 1; As alterações estão em sublinhado. Nas classes cliente apresentadas anteriormente seriam feitas as seguintes modificações: Scanner scanner = new Scanner(System.in); Person p = new Person("Miguel", 23); Introdução à Programação 2004/

16 e System.out.println("Qual a nova idade para o " + p.name() + "?"); int nova = scanner.nextint(); if (p.setage(nova) == 1) System.out.println("Idade inválida"); Scanner scanner = new Scanner(System.in); Person p = new Person("Miguel", 34); System.out.println("Depois do tratamento de rejuvenescimento, + quantos anos acha que " + p.name() + " rejuvenesceu?"); int anos = scanner.nextint(); int nova = p.idade() - anos; // Nova idade "estética" if (p.setage(nova) == 1) p.setidade(0); Lembrar que, sendo agora o método setage uma função, a sua invocação retorna um valor, valor esse que é testado para verificar do insucesso da operação. Ou seja, contrariamente à abordagem anterior, nesta invoca-se primeiro e verifica-se depois se a invocação era válida. Este tipo de abordagem tem vários inconvenientes. i) são feitos, sempre, dois testes à legalidade da execução - um aquando da execução do método invocado e outro para saber se teve sucesso ou não; ii) quanto maior a quantidade de instruções que se têm que escrever, maior é o número potencial de erros; iii) vai contra o princípio de que as funções não devem alterar o estado. O entusiasta da programação defensiva de que falámos atrás pode aceitar estes argumentos e aceitar que a dele não é realmente a melhor solução. Mas também vai dizer: "Mas assim posso construir programas errados e ninguém me avisa!". Claro que foi avisado! No método setage está bem clara a condição sob a qual o método funciona bem Porque é que aceitamos tão bem que a culpa é nossa quando, por exemplo, invocamos a divisão com um divisor nulo? - "Oops, claro que não posso dividir por zero!" Ou quando invocamos a raiz quadrada com um argumento negativo? - "Oops, claro que, no domínio dos reais, não posso calcular a raiz de um número negativo!" Porque é que não aceitamos tão bem que, embora sejamos avisados que o argumento tem que ser positivo ou zero, o método setage possa não funcionar bem quando invocado com um argumento negativo? Temos que ser criadores responsáveis de classes cliente e respeitar os contratos que as classes fornecedoras estabelem connosco. Claro que, até termos uma boa convicção de que as nossas classes estão correctas do ponto de vista do cumprimento dos contratos, devemos ter alguma hipótese de controlar o fluxo de execução de modo a percebermos onde é que os contratos estão a ser violados. Existem ferramentas associadas a algumas linguagens de asserções (nomeadamente o JML) que permitem fazer a monitorização dos nossos programas em tempo de execução detectando assim qualquer violação nos contratos das classes. (mais adiante neste texto). 14 Introdução à Programação 2004/2005

17 Invariantes Pré e pós-condições descrevem propriedades de métodos. Temos também qur ser capazes de exprimir propriedades globais das instâncias das classes. Fazêmo-lo através da invariante da classe * Uma classe que descreve uma pessoa, seu nome e idade. public class Person { invariant name()!= null && age() >= 0 ; * Nome da pessoa private String name; * A idade da pessoa private int age; * Construtor public Pessoa (String name, int age) { this.name = name; this.age = age; * Nome da pessoa public /*@ String name () { return name; * A idade da pessoa public /*@ int age () { return age; * Alterar a idade da pessoa param newage O novo valor para a idade requires newage >= ensures age() == public void setage (int newage) { age = newage. Introdução à Programação 2004/

18 //fim da classe Person Neste caso, a asserção invariante significa: durante toda a "vida" de todas as instâncias da classe Person, a função name() deverá ter um valor diferente de null e a função age() deverá ter um valor não negativo. Todos os métodos não construtores deverão preservar a invariante e os métodos construtores deverão estabelecer a invariante, ou seja, só deverão criar objectos que satisfaçam a invariante. Pela pós-condição do método setage, verificamos que o valor da função age(), ou seja, a idade da pessoa, irá ficar com o valor do parâmetro newage. Então, para que a invariante seja preservada, devemos exigir que o valor de newage seja não negativo: daí a pré-condição ser newage >= 0. Sabendo que o estado de um objecto é o conjunto de valores de todos os seus atributos (e que, portanto, caracteriza o objecto num dado instante da execução do programa), definimos estados estáveis como aqueles nos quais o objecto é visível do exterior. Ou seja, depois da criação da instância e antes e depois de cada invocação sobre a instância partindo do exterior. As invariantes são válidas nos estados estáveis. Permitimos que temporariamente o objecto não verifique a invariante, quando está em vias de executar uma série de tarefas internas. Chamadas qualificadas obj.meth(), executadas por clientes, são as únicas que têm de partir de um estado que verifique a invariante e têm de terminar num estado que satisfaça a invariante. Esta regra não se aplica a chamadas não qualificadas meth(), ou seja, internas à classe. Correcção de uma classe Quando é que uma classe está correcta relativamente à sua especificação, ou seja, às suas asserções? Sabemos que um construtor é sempre invocado num estado em que os atributos do (novo) objecto têm os valores por omissão para os seus tipos. Chamemos a este estado Omissão. Uma classe está correcta relativamente às suas asserções: a) Quando qualquer construtor que seja invocado num estado Omissão que também satisfaz a sua pré-condição resulte, após a sua execução, num estado que satisafaz a sua pós-condição e a invariante. b) Quando qualquer método não construtor público invocado num estado e com uns argumentos que satisfazem a sua pré-condição e a invariante resulte, após a sua execução, num estado que satisfaz a sua pós-condição e a invariante. Monitorização de classes Vimos até agora duas grandes aplicações dos contratos no desenvolvimento de software: criação de documentação de uma classe os contratos descrevem de uma forma concisa e precisa a forma como os métodos de uma classe podem e 16 Introdução à Programação 2004/2005

19 devem ser usados (pré e pós-condições) e as características das instâncias da classe (invariantes); ajuda à implementação dos métodos a que respeitam os contratos definem a semântica ou significado dos métodos, dizendo-nos, portanto, qual deve ser o efeito da sua execução (pós-condição e invariante) a partir de um estado com determinadas propriedades (pré-condições e invariante). Para além deste duplo papel, os contratos ainda nos podem ajudar a verificar se as nossas classes estão correctas relativamente à especificação, ou seja, se a implementação dos métodos está de acordo com a especificação fornecida pelos contratos. Ajudam-nos também a verificar se uma classe cliente é bem comportada, ou seja, se invoca os métodos com as pré-condições satisfeitas. Não vamos aqui referir nenhuma ferramenta que nos permite verificar de facto, e sem sombra de dúvida, se a classe está correcta. Informamos apenas que ferramentas destas existem que, de forma mais ou menos complicada, permitem este tipo de verificação. Referimos aqui outro tipo de ferramentas de monitorização de asserções em tempo de execução que, embora não nos permitam decidir, sem dúvidas, que uma classe está correcta relativamente a uma especificação, permitem-nos, no entanto, testar se os contratos são respeitados pelas classes envolvidas. Isto é feito testando a execução dos programas, verificando, a cada invocação, a validade dos contratos. Existem ferramentas, nomeadamente o JML run-time assertion checker, que funcionam como pré-processadores, gerando código de monitorização e inserindo-o em locais bem definidos das nossas classes. Assim, se usarmos o pré-processador do JML na nossa classe Person, por exemplo, vamos obter uma nova classe Person instrumentalizada ou seja, com instruções Java acrescentadas automaticamente, que verificam as pré-condições e a invariante antes da execução de qualquer método e código que verifica as pós-condições e a invariante no fim da execução de cada método, antes do seu retorno. O método setage(), por exemplo, ficaria assim: * Alterar a idade da pessoa param newage O novo valor para a idade requires newage >= ensures age() == public void setage (int newage) { instruções em Java que verificam: name()!= null && age() >= 0 newage >= 0 age = newage instruções em Java que verificam: age() == newage name()!= null && age() >= 0 // invariante // pré-condição // instruções do método // pós-condição // invariante Introdução à Programação 2004/

20 Estas instruções que verificam o contrato são geradas automaticamente e, portanto, são isentas de erros. De seguida compilamos as nossas classes da forma habitual e executamo-las. Se executarmos o nosso sistema várias vezes, para valores e situações relevantes, ficamos com um pouco mais de confiança na correcção das nossas classes, embora essa confiança não possa ser absoluta, já que se tratam de testes. As instruções geradas automaticamente que verificam os contratos estão feitas de forma a gerarem excepções em tempo de execução sempre que algum contrato é violado. Essas excepções podem ser de vários tipos, como seria de esperar: por exemplo, violação de pré-condição, de pós-condição e de invariante. Indicam ainda o método onde ocorreu a violação do contrato, tornando simples a correcção do erro. Relembre que uma violação de uma pré-condição é um erro na classe cliente e uma violação de uma pós-condição ou de um invariante é um erro na classe fornecedora. Resumindo e concluindo Alguns passos a seguir na construção de classes e seus contratos: 1. Decidir, a partir dos requisitos para a classe a construir, quais as funções que revelam o estado. Estas funções não têm pós-condição, mas, se tiverem algum parâmetro, podem ter pré-condição para controlar os valores desse(s) parâmetro(s); 2. Construir a asserção invariante; 3. Decidir quais os outros métodos que a classe tem que oferecer às suas classes cliente - para cada um decidir se é procedimento ou função, se tem parâmetros e, caso afirmativo, quais e de que tipo; 4. Documentar, escrevendo um cabeçalho javadoc, cada um desses métodos com uma descrição sucinta do que representa e, se tiver parâmetros, uma descrição de cada um deles; 5. Para cada um desses métodos construir o seu contrato e adicioná-lo à sua documentação. Este contrato irá ser, directa ou indirectamente, definido à custa das funções reveladoras do estado identificadas em 1; 6. Não usar atributos nos contratos para que não seja necessário refazê-los em caso de uma mudança na representação. De uma forma mais geral, não usar informação privada nos contratos para que as classes cliente os possam entender e, no caso das pré-condições, os possam testar. 7. Escolher uma representação para a classe através da escolha dos atributos e seus tipos; 8. Finalmente, implementar cada um dos métodos de acordo com a sua póscondição e com a invariante, e sabendo que o estado inicial de execução do método é um estado que satisfaz a invariante e a sua pré-condição. Em particular, nunca testar a pré-condição no corpo do método. Utilização de asserções: Metodologia para escrever software correcto; 18 Introdução à Programação 2004/2005

21 Preparação de documentação: asserções informam os clientes de uma classe sobre os serviços disponibilizados por essa classe, expressos de uma forma concisa e precisa; Dependendo da existência de ferramentas de monitorização das asserções, permitem o teste e depuração das classes. Monitorização de asserções em tempo de execução: P: Porquê monitorização em tempo de execução? R:Trata-se de uma alternativa à prova de correcção de software. P: Qual o efeito das asserções em tempo de execução? R: Depende do programador, baseado em opções de compilação; um efeito pode ser o lançamento de excepções cada vez que ocorre a violação de alguma asserção. P: Quanta monitorização? R: Compromisso entre: a) quão confiamos na correcção do nosso software; b) quão crucial é obter o máximo de eficiência; c) quão sérias são as consequências de erros não detectados. Um bom compromisso pode ser: em tempo de testes, monitorizar todas as asserções; em produção testar apenas as pré-condições. in "V.Vasconcelos, Guião de Programação Imperativa, FCUL, Setembro 2001" Bibliografia B.Meyer, Object-Oriented Software Construction, Prentice Hall 1997, 2a edição, ISBN: V.Vasconcelos, Guião de Programação Imperativa, DI-FCUL, Setembro Introdução à Programação 2004/