Resumo - Um dos grandes objectivos da Engenharia de Software é produzir software com qualidade. Significa isto que propriedades como robustez, correcção, reutilização, manutenção, compatibilidade, eficiência, portabilidade e funcionalidade, entre outras, têm que estar presentes num produto de software com qualidade. O Desenho por Contrato (DpC) com Object Constraint Language (OCL) e a Programação por Contrato (PpC) são reconhecidamente instrumentos potenciadores de qualidade que actuam em dois extremos, respectivamente no modelo e no código. Estabelecer a ponte entre estes dois extremos é um passo importante para o aumento da qualidade do produto final. Este artigo pretende constituir uma análise do estado da arte no que respeita às ferramentas que possibilitam modelação em Unified Modelling Language (UML) com OCL e implementação de DpC com a linguagem Java e que possam sustentar essa ponte.
——————————
1 http://ctp.di.fct.unl.pt/mei/qpp por um cacilheiro. Cada embarcação destas tem uma capacidade limitada quanto ao número de passageiros que pode transportar. Em cada viagem é transportado um determinado número de passageiros que não pode exceder o número de lugares disponíveis do cacilheiro que lhe está associado. Cada cacilheiro tem atribuído um conjunto de identificação único assim como cada viagem é identificada por um número de viagem único. Um passageiro não pode realizar mais do que uma viagem simultaneamente.
pelos objectos (DSOO) introduziu os conceitos de classes, objectos, abstracção, herança, polimorfismo e genericidade que se traduziram num passo importante na constante procura da qualidade do produto na engenharia de software. No entanto, expressar alguns factores de qualidade na programação, no sentido de tornar os programas legíveis, bem especificados e validados e entender as regras que estão por trás da sua forma de implementação, é algo que a maioria das ferramentas de apoio ao desenvolvimento orientado pelos objectos não contemplava. Esta necessidade despoletou o surgimento do DpC. pós-condições e invariantes permite-nos exprimir de uma maneira formal as especificações do contrato. Falta ainda, obviamente, especificar as consequências e respectivo tratamento das excepções às cláusulas contratuais.
pré-con dições, pós-condições e invariantes. As pré-condições
são uma obrigação da operação cliente, em benefício da
operação fornecedor; as pós -condições são uma obrigação da
operação fornecedor, em benefício da operação cliente.
Ambas, descrevem as propriedades de cada método
individualmente. Os invariantes expressam as propriedades
globais das instâncias de uma classe, as quais terão que ser
preservadas por todas as operações dessa classe [
TABELA 1 EXEMPLO DE UM CONTRAT O Cliente Fornecedor
Obrigações Tem que assegurar as pré-condições: 1. bilhete comprado.
2. estar no cacilheiro 5 minutos antes da partida.
Tem que assegurar a pós-condição: 1. transportar o clienteparaolocalpretendidoaté 10 minutos depois da hora prevista no horário.
Benefícios Da pós-condição: 1. estar no local pretendido às na hora prevista no horário com atraso mínimo de 10 minutos.
Da pré-condição: 1. não ter prejuízo por transportar clientes sem bilhete comprado e não partir com atraso.
O conceito chave do DpC assenta essencialmente na
expressão das relações entre uma classe (fornecedor) e os seus clientes
sob os auspícios de um acordo formal, contemplando os direitos
e obrigações de ambas as partes. Somente com a definição
precisa de todas as reivindicações e responsabilidades respeitantes a
cada módulo pertencentes a um determinado sistema, se lhe
pode depositar um alto grau de confiança [
Fazendo um paralelismo com os contratos efectuados, por exemplo entre duas organizações, podemos inferir algumas propriedades importantes de um contrato: 1. são firmados entre duas ou mais entidades , em que cada uma assume o papel de cliente ou fornecedor; 2. é explicitamente escrito numa linguagem conhecida por ambas as partes; 3. especifica as obrigações e benefícios mútuos;
da outra e vice-versa;
assegura as travessias do rio Tejo (fornecedor) e os seus passageiros (cliente) podemos formalizar alguns dos benefícios e obrigações correspondentes como está expresso na tabela 1.
condições, invariantes e tratamento de excepções. Conclui-se, facilmente, que a utilização do DpC elimina, por completo, a necessidade da programação defensiva , na qual as validações da utilização do serviço estão todas do lado do fornecedor não havendo obrigações por parte do cliente.
De modo a que a utilização deste conceito não invalide as
cláusulas do DpC, a redefinição de uma operação apenas
pode substituir a pré-condição original por uma igual ou
mais fraca (exigindo menos do cliente) e a pós-con dição
original por uma igual ou mais forte (oferecendo mais ao
cliente) [
A utilização do conceito de contrato pode ser utilizado em
todo o ciclo de vida do processo de DSOO. Assim a
utilização de pré-condições, pós -condições e invariantes começa na
modelação do sistema descrevendo os seus eventos. Na fase
de análise e na fase de implementação os contratos definem
as operações, os benefícios e as obrigações de cada comp
onente do sistema, respectivamente. Finalmente, na fase de
testes, os contratos definem a correcta especificação de cada
componente [
2 A linguagem Eiffel tem mecanismos nativos de suporte ao DpC.
A modelação de sistemas de software é tradicionalmente
sinónimo de construção de diagramas. Os diagramas,
simplesmente, não conseguem expressar toda a informação
necessária a uma especificação completa [
Context Viagem
inv:passageiros->size() <= cacilhero.numeroDeLugares Em virtude do exposto anteriormente surge a necessidade da integração do OCL, uma linguagem formal (sem a complexidade das tradicionais linguagens formais), no UML uma linguagem de modelação. Além disso expressões formais, dada a sua base matemática, não dão azo a interpretações ambíguas e podem ser verificadas automaticamente por ferramentas. Além de utilizar uma notação similar às linguagens de programação orientadas pelos objectos, é uma linguagem de expressões pura. Mais, as expressões em
alterar o estado do sistema, embora possam referenciá-lo.
[
classes;
permite-nos expressar os conceitos do DpC na fase de análise e desenho, utilizando ferramentas de modelação em
3
cujas características possam sustentar a ponte entre a modelação com UML e OCL e a correspondente implementação de código Java com PpC, bem como na eleição daquela ou daquelas que permitam alcançar esse objectivo originando um produto final com mais qualidade.
Assim sendo, para estabelecer essa ponte, uma ferramenta ou a utilização conjunta de várias, terão de assegurar três aspectos essenciais:
las de OCL;
artigo, com base na possibilidade de, à custa das características que apresentam, viabilizarem todos ou apenas alguns dos aspectos mencionados anteriormente, bem como a sua representatividade no segmento de mercado em que se inserem .
A tabela 2 contém a descrição abreviada de cada uma
das ferramentas seleccionadas. Para comparar as várias
ferramentas, foram identificadas e analisadas as
características que podem conferir sustentabilidade ao processo
pretendido. A tabela 3 apresenta para cada uma das
ferramentas seleccionadas a presença total (S) ou parcial (P) e
ausência (N) de cada uma dessas características.
Poseidon [
Ferramenta de análise e desenho em UML com suporte para OCL.
Ferramenta de implementação de DpC para Java. Traduz um ficheiro .jass ou .Java com as asserções especificadas em Javadoc para um ficheiro .java. Este ficheiro deverá por sua vez ser compilado com o compilador de Java tradicional.
Ferramenta de implementação de DpC para Java. Os contratos são escritos como métodos Java normais seguindo uma convenção de nomes intuit iva.
Compilador de Java com cláusulas de OCL. Partindo da fonte com as cláusulas OCL escritas em Javadoc, produz código Java adequado à sua implementação que introduz em cada classe.
Ferramenta de implementação de DpC para Java. As asserções são descritas à custas de etiquetas especiais em Javadoc e posteriormente são pré-processadas e compiladas num processo único. Para a compilação recorre ao compilador nativo da JVM (Java Virtual Machine).
Plugin do Eclipse que permite fazer a análise e o desenho em UML, implementar asserções com OCL, verificação de sintaxe de OCL e geração automática de código Java com adição de código de suporte às asserções. Ferramenta de análise e desenho em UML, com suporte a OCL e verificação de sintaxe e geração de código Java com adição de código de suporte às asserções.
Ferramenta de implementação de DpC com OCL em aspect-oriented programming (AspectJ). Recebe um ficheiro XMI ou a fonte com as cláusulas de OCL implementadas em Javadoc e gera o código Java e os aspectos necessários.
TABELA 3 PRINCIPAIS CARACTERÍSTICAS DAS FERRAMENTAS SELECCIONADAS
Características s a t n e m a r r e
F ArgoUML Poseidon MagicDraw Sparx Enterprise Architect jmsAssert iContract Jass jContractor Dresden OCL Toolkit jContract Octopus OCLe OCL2j
S S S S N N N N N N S S N
L M U m o c o ã ç a l e d o M 4 C p
D S S S S N P8 P9 N S N S S S
P N S N N P P N S N S S S e x a t n i s o L çã C a O c i f i r e V 5g n i r e e n i g n E d r a w r o
F S S S S N N N N N N S S S
S S S S S S 6 C p P 7o t n e m a s s e c o r p é r P o ã ç a l i p m o C s e t s e
T N N N N S S S S S N N N N
N N N N N N N N S S N N N
N N N N N N N N N N N N N s e õ ç a v r e s b
O Não inclui OCL na fonte gerada.
Não inclui OCL na fonte gerada.
Características baseadas apenas na informação dos autores.
Protótipo não disponível à data de redacção.
Do estudo comparativo efectuado, podemos concluir 4 Possibilidade de expressar restrições de OCL no modelo. 5 Possibilidade de gerar código Java a partir do modelo.
6 Possibilidade de implementação de pré-condições, pós-condições e invariantes na fonte.
7 A fonte com as cláusulas de DpC é pré-processada, dando origem a outra fonte que será posteriormente compilada.
8 Apenas contempla: implies, forAll, exists. 9 Apenas contempla: forAll, exists. que as funcionalidades apresentadas pelas ferramentasanalisadas podem constituir três grandes grupos. Um primeiro grupo (Grupo 1) com as funcionalidades relacionadas com a modelação UML e especificação de cláusulas OCL. Um segundo grupo (Grupo 2) com as funcionalidades relacionadas com a produção ou utilização de código fonte Java, com as cláusulas de OCL de algum modo aí introduzidas.
das funcionalidades relacionadas com a produção do código Java executável. A tabela 4 apresenta as ferramentas analisadas e os grupos de funcionalidades onde se inserem.
des no âmbito do primeiro grupo, importa referir que as distinções existem essencialmente entre o suporte de OCL e com que extensão, a verificação da sintaxe de OCL, e a validação das asserções contra o modelo UML existente.
TABELA 4 DISTRIBUIÇÃO DAS FERRAMENTAS PELOS GRUPOS DE FUN
CIONALIDADES DEFINIDOS Grupo 1
Grupo 2
Grupo 3 utilizam código Java com as cláusulas de OCL embebidas em Javadoc. Existem outras que produzem ou utilizam código Java, com as cláusulas de OCL implementadas também em Java, dentro das classes a que dizem respeito. E existem ainda outras ferramentas, que produzem ou utilizam código Java, sendo as cláusulas de OCL implementadas à parte, sob a forma de scripts ou aspectos.
No que diz respeito às ferramentas que implementam as funcionalidades do terceiro grupo, estas distinguem-se entre as que recorrem ao compilador tradicional de Java, as que recorrem ao compilador tradicional de Java adicionando-lhe parâmetros de compilação extraordinários, as que recorrem a compiladores próprios e as que recorrem a compiladores de aspectos.
De todas as ferramentas analisadas, poderíamos escolher apenas uma ou a combinação de várias para concretizar os objectivos pretendidos. No entanto, esta última opção levantaria algumas questões de compatibilidade entre as ferramentas a utilizar. Como o OCLe é a única ferramenta disponível que contempla todas as funcionalidades necessárias a este processo, mereceu de imediato a nossa atenção, sendo as restantes relegadas para segundo plano. Mesmo colocando de lado as questões de compatibilidade mencionadas anteriormente, o facto de se trabalhar numa única ferramenta é menos propício a falhas no processo de transição do desenho para a implementação, para além de implicar uma curva de aprendizagem significativamente menor. Além disso, o OCLe é a única ferramenta que valida as asserções contra o modelo UML, para além da comum validação sintáctica. Mais, já contempla o OCL 2.0 e gera automaticamente código Java correspondente às asserções especificadas, implementado quase na totalidade o OCL. Pelas razões anteriormente indicadas, o OCLe afigura-se como a alternativa tecnológica que nos assegurará maior qualidade no produto final, pelo que é a ferramenta eleita para implementar o caso de estudo. 4
A demonstração do processo, que nos leva da modelação em UML já com suporte ao DpC com OCL, passou pela utilização do modelo “Viagem Cacilheiro” cujo diagrama de classes está representado na figura 6. Para este fim, utilizámos a ferramenta eleita - OCLe - a partir do estudo comparativo efectuado na secção anterior.
Expressões em OCL implementadas. context Viagem::novoPassageiro(p:Passageiro) - - um passageiro só pode fazer uma viagem de cada vez. pre passageiroNaoExiste: not( self.passageiro ->includes(p) ) - - o numero de passageiros é incrementado. post numeroPassageiros: self.passageiro ->size() = self.passageiro ->size@pre + 1 context Viagem - - o numero de passageiros de uma viagem não pode ser exceder o numero de lugares disponíveis do cacilheiro. inv numeroPassageirosPorViagem: self.passageiro ->size() <= self.cacilheiro.numeroLugares - - Cada viagem tem um número único. inv uniqueViagem: Viagem.allInstances->forAll( c1,c2:Viagem |
c1<>c2 implies c1.nrViagem<>c2.nrViagem)
restrições no OCLe, é chegada a fase de gerar o código Java adequado. O OCLe gera código Java que implementa simultaneamente a interface das classes e as cláusulas de OCL, dentro de cada classe, no aplicável.
cação à ferramenta da acção pretendida. Antes de gerar o código Java, a ferramenta procede sempre à análise da sintaxe do OCL e à validação das restrições introduzidas, contra o modelo especificado no diagrama de classes. O código
as asserções correspondentes às expressões OCL definidas no ponto anterior encontra -se em apêndice.
xar de realçar a quantidade de código que é acrescentado a sulamento destes aquando do forward engineering.
cada classe, unicamente para implementar o DpC com O código Java gerado pelo OCLe para suportar o DpC é
OCL. O OCLe não suporta alguns dos mecanismos do DpC, muito extenso, constituindo factor de preocupação quanto
sendo exemplo disso a não implementação de restrições à manutenção. Esta preocupação é devida ao
emaranhacom carácter temporal (utilização do xpto@pre). Além disso, mento entre o código de suporte às asserções e o código
esta implementação de DpC contrasta com a do Eiffel, na de suporte às funcionalidades que é implementado em
qual as asserções podem ser inibidas ao critério do progra- conjunto dentro da mesma classe. Actualmente estão a ser
mador. Na implementação do OCLe passam a fazer parte desenvolvidas soluções com aspectos [
Já existe alguma variedade de ferramentas que supor- Como foi já referido o OCLe não suporta ainda, na sua tam o DpC. No entanto, atendendo à importância que o totalidade o DpC, sendo exemplos disso a não compilação OCL vai assumindo na modelação, aquelas que não o de asserções que recorrem ao estado anterior do objecto suportam irão previsivelmente começar a ser postas de (xpto@pre) e não permitir a inibição das asserções. Além lado pelos utilizadores. disso o OCLe não faz reverse engineering, pelo que qual
Havendo uma série de ferramentas que introduzem quer alteração no desenho originará novo código. Apesar as cláusulas de DpC em etiquetas de Javadoc, lamenta-se de tudo é uma ferramenta bastante completa e a única a inexistência de uma norma, ou pelo menos de uma capaz de sustentar o desenvolvimento de software com prática comum, quanto à sintaxe utilizada na declaração DpC e OCL ao longo de todo o ciclo de vida, bem como, das asserções, constatando-se que cada ferramenta utili- das ferramentas apreciadas, a única que valida as cláusuza um formato próprio. Este facto, para além de obrigar las de OCL introduzidas contra o modelo desenhado. a uma aprendizagem das etiquetas específicas da ferra- Apesar das vantagens evidentes trazidas pela utilizamenta com que se está a trabalhar, impede a comple- ção do DpC e do OCL à qualidade do software produzido, mentaridade entre as ferramentas que abrangem apenas não podemos ignorar o compromisso que lhe está assopartes do ciclo de vida, pois o resultado de uma não ciado – o desempenho. pode ser reutilizado por outra. Existem presentemente actividades de investigação no
O OCLe mostrou ser uma ferramenta bastante eficaz, sentido de implementar DpC à custa de notações gráficas
não obstante o facto de se mostrar pouco conforme no que [
} public void check_passageiroNaoExiste(Passageiro p) { Set setPassageiro = Viagem.this.getPassageiro(); boolean bIncludes = CollectionUtilities.includes( setPassageiro,
p); boolean bNot = !bIncludes; if (!bNot) { System.err.println("precondition 'passageiroNaoExiste'
failed for object "+Viagem.this); public void check_numeroPassageiros(Passageiro p) { Set setPassageiro = Viagem.this.getPassageiro(); int nSize = CollectionUtilities.size(setPassageiro); Set setPassageiro0 = Viagem.this.getPassageiro(); int nSize0 = CollectionUtilities.size(setPassageiro0); int nPlus = nSize0 + 1; boolean bEquals = nSize == nPlus; if (!bEquals) { System.err.println("postcondition 'numeroPassageiros' failed
for object "+Viagem.this); } ConstraintChecker checker = new ConstraintChecker(); checker.checkPreconditions(p); checker.result = internal_novoPassageiro(p); checker.checkPostconditions(p); return checker.result; } } } } } } } } } } } public final Cacilheiro getCacilheiro() { return cacilheiro; } public final void setCacilheiro(Cacilheiro arg) { if (cacilheiro != arg) { Cacilheiro temp = cacilheiro; cacilheiro = null;//to avoid infinite recursions if (temp != null) { temp.removeViagem(this); } if (arg != null) { cacilheiro = arg; arg.addViagem(this); public final Set getPassageiro() { if (passageiro == null) { return Java.util.Collections.EMPTY_SET; } return Java.util.Collections.unmodifiableSet(passageiro); public final void addPassageiro(Passageiro arg) { if (arg != null) { if (passageiro == null) passageiro = new LinkedHashSet(); if (passageiro.add(arg)) { arg.addViagem(this); public final void removePassageiro(Passageiro arg) { if (passageiro != null && arg != null) { if (passageiro.remove(arg)) { arg.removeViagem(this); } private void internal_novoPassageiro(Passageiro p) { } public Viagem() { } public class ConstraintChecker extends BasicConstraintChecker { public void checkConstraints() { super.checkConstraints(); check_Viagem_numeroPassageirosPorViagem(); check_Viagem_uniqueViagem(); public void check_Viagem_numeroPassageirosPorViagem() { Set setPassageiro = Viagem.this.getPassageiro(); int nSize = CollectionUtilities.size(setPassageiro); Cacilheiro cacilheiroCacilheiro = Viagem.this.getCacilheiro(); int nNumeroLugares = cacilheiroCacilheiro.numeroLugares; boolean bLessOrEqual = nSize <= nNumeroLugares; if (!bLessOrEqual) { System.err.println("invariant 'numeroPassageirosPorViagem'
failed for object "+Viagem.this); public void check_Viagem_uniqueViagem() { Set setAllInstances = Ocl.getType(
new Class[]{Viagem.class}).allInstances(); //evaluate 'forAll(c1,c2:Viagem|c1<>c2 implies //c1.nrViagem<>c2.nrViagem)': boolean bForAll = true; final Iterator iter = setAllInstances.iterator(); while (bForAll && iter.hasNext()) { final Viagem c1 = (Viagem)iter.next(); final Iterator iter0 = setAllInstances.iterator(); while (bForAll && iter0.hasNext()) { final Viagem c2 = (Viagem)iter0.next(); boolean bNotEquals = !c1.equals(c2); int nNrViagem = c1.nrViagem; int nNrViagem0 = c2.nrViagem; boolean bNotEquals0 = nNrViagem != nNrViagem0; boolean bImplies = !bNotEquals || bNotEquals0; bForAll = bImplies; } if (!bForAll) { System.err.println("invariant 'uniqueViagem'
failed for object "+Viagem.this); public int nrViagem; public Cacilheiro cacilheiro; public Set passageiro; {
OclType.registerInstance(this, Viagem.class); }
}