Entendendo OCL. Apresentação e utilização da Object Constraint Language 1.1

Transcrição

1 Entendendo OCL Apresentação e utilização da Object Constraint Language 1.1 Daniel Henrique Alves Lima daniel.lima@ic.unicamp.br Universidade Estadual de Campinas Rafael Musial rafael.musial@ic.unicamp.br Universidade Estadual de Campinas A OCL é uma linguagem de expressões para especificar restrições sobre modelos orientados a objetos ou outros artefatos da linguagem UML. É uma linguagem precisa, textual e formal. Uma das suas principais características é que seu uso não exige um forte conhecimento matemático para obter corretude na sua manipulação. Neste artigo apresentaremos de uma maneira clara e prática os conceitos básicos da OCL e construiremos um exemplo de modelagem que mostre o uso da OCL para especificar um sistema. Mostraremos também algumas ferramentas de suporte a criação e verificação das construções. Este documento é parte do sistema de avaliação do curso de Engenharia de Software (MO409) oferecido pelo Instituto de Computação da Universidade Estadual de Campinas ministrado pela Profa. Eliane Martins (eliane@ic.unicamp.br)

2 Índice ÍNDICE INTRODUÇÃO A LINGUAGEM OBJECT CONSTRAINT LANGUAGE Expressões OCL Tipos de expressões Contexto de uma expressão Self Invariantes Pré condições Pós-condições Tipos de dados Hierarquia de classes Polimorfismo Meta tipos Tipos herdados de modelos UML Collecitions Set Bag Sequence Algumas Palavras Reservadas Let... in If then. else... end if Algumas operações sobre os tipos de dados OCL Select e Reject ForAll Exists OclIsTypeOf OclIsNew O MÉTODO As ferramentas EXEMPLO DE CASO DE USO Funções do sistema Funções básicas Casos de Uso UC : Comprar bebida UC : Obter histórico de vendas UC : Validar identificação do técnico Diagrama de seqüência Diagrama de classes Sistema Daniel Henrique Alves Lima, Rafael Musial

3 4.4.2 Bebidas Estoques Repositórios Registros de Venda Contratos com OCL Contrato para fornecerdinheiro Contrato para escolherbebida Restrições em OCL Constraint fornecer dinheiro Constraint escolher bebida VERIFICAÇÃO E VALIDAÇÃO DO MODELO Processo Resultados obtidos no exemplo de caso de uso...error! Bookmark not defined. 5.3 Ferramentas CONCLUSÕES Sumário...Error! Bookmark not defined. 6.2 Limitações Tipos de aplicações adequadas BIBLIOGRAFIA Daniel Henrique Alves Lima, Rafael Musial

4 1 Introdução Muitas linguagens, modelos e métodos para a análise e projeto em orientação a objetos foram criadas nas últimas décadas. Esses métodos normalmente compartilharam as mesmas idéias e conceitos básicos e diferenciavam-se apenas em suas terminologias e notações. Isto dificultava muito a comparação e a reutilização de casos já modelados com os artefatos até então inventados. Uma solução promissora para este problema foi o desenvolvimento da Unified Modeling Language (UML), a qual foi proposta para prover uma padronização e unificação dos artefatos em uma só linguagem para modelagem de sistemas orientados a objetos. A primeira versão da UML foi submetida ao Object Management Group (OMG), organizador do processo de padronização dos modelos e linguagens. A revisão desse modelo mostrou uma grande deficiência na clareza e consistência das definições da UML. Em particular, uma dificuldade encontrada foi que a semânitica da UML poderia ser interpretada em formas ambígüas. O problema foi minimizado com a elaboração de uma nova versão da Unified Modeling Language (UML) a qual foi publicada em O mais importante incremento nesta versão foi a criação da Object Constraint Language (OCL). A OCL é uma linguagem de expressões para especificar restrições sobre modelos orientados a objetos ou outros artefatos da linguagem UML. É uma linguagem precisa, textual e formal. Essa formalidade garante a não existência de interpretações ambígüas para as mesmas restrições, fato que ocorria antes da sua criação. Uma das suas principais características é que seu uso não exige um forte conhecimento matemático para ser utilizada corretamente, como ocorre nos modelos Z e VDM. O objetivo desse artigo é apresentar de uma maneira clara e prática os conceitos básicos da OCL e construir um exemplo de modelagem que mostre o uso da OCL para especificar um sistema. Mostraremos também algumas ferramentas de suporte a criação e verificação desta especificação. Após essa breve descrição, o artigo contém uma apresentação da linguagem OCL e a descrição de uma modelagem de especificação onde é usada a linguagem OCL. Além disso mostraremos uma maneira de verificar o modelo, apresentando inclusive algumas ferramentas que suportem a verificação. Daniel Henrique Alves Lima, Rafael Musial

5 2 A linguagem Object Constraint Language Como citado na introdução, a Object Constraint Language é uma linguagem textual e precisa para representar restrições. Sua estrutura está intimamente ligada a outros modelos da UML, como o Diagrama de Classes, por exemplo. É composta de expressões escritas em formas de afirmações. É uma linguagem que possui tipos de dados pré-definidos assim como algumas paravras reservadas. 2.1 Expressões OCL Toda expressão OCL é declarativa no sentido de que expressa o quê a restrição representa no sistema e não como essa restrição é implementada. A avaliação de uma expressão sempre resulta em um valor booleano e nunca muda o estado do sistema no modelo. As expressões OCL são utilizadas para definir condições invariantes nas classes representadas em um modelo e também são utilizadas para especificar as pré e pós-condições em operações aplicadas a classes deste modelo. Expressões OCL também podem ser utilizadas para fazer consultas a um modelo de classes da UML. Essas consultas podem ser úteis para validar modelos de classes na fase de projeto. A avaliação dessa expressão não devolve um valor booleano, e sim valores de um tipo específico da OCL. Nesta documento adotamos, além do caso da máquina de bebidas, o seguinte diagrama de classes de uma locadora como base para todos os exemplos a serem apresentados: Tipos de expressões As expressões OCL podem ser de 3 tipos: Expressões que representam condições invariantes em classes de objetos; Expressões que representam pré-condições de operações aplicáveis a uma classe de objetos; Expressões que indicam as pós-condições de operações aplicáveis a uma classe de objetos; Daniel Henrique Alves Lima, Rafael Musial

6 2.1.2 Contexto de uma expressão As expressões OCL requerem que as restrições estejam ligadas a um contexto de um modelo. O contexto de uma expressão pode ser uma classe de objetos ou pode ser uma operação aplicável a um objeto. Para representar um contexto em OCL utilizamos a palavra reservada context <contexto> Self Numa expressão em OCL, a palavra reservada self é usada para referenciar uma instância do contexto Invariantes Invariantes são condições que os objetos modelados devem respeitar durante toda sua existência no sistema. Em OCL, para indicar que uma expressão é uma invariante, utilizamos a palavra reservada inv após a declaração do contexto. Uma expressão típica em OCL e que representa uma condição invariante tem o sequinte formato: context <contexto> inv: <expressão> Utilizando o diagrama de classes da seçao 2.1, temos o exemplo de uma invariante: Todo veículo deve ter pelo menos uma roda context Vehicle inv: self.numwheels > Pré-condições Pré-condições são declarações que refletem o estado no qual deve se encontrar o sistema para que as operações sobre os objetos possam ser executadas. Em OCL, quando queremos expressar uma condição na forma de pré-condição, utilizamos a palavra reservada pre após a declaração do contexto seguido do símbolo :. A expressão típica em OCL usada para representar uma pre-condição tem a seguinte estrutura: context <contexto> pre: <expressão> Tomando como base o exemplo do diagrama de classes da locadora de veículos, temos: O salário de uma pessoa varia de acordo com uma data e essa deve ser posterior a 01/01/1950 context Person::income(d: Date) pre: d > 01/01/1950 Daniel Henrique Alves Lima, Rafael Musial

7 2.1.6 Pós-condições Pós-condições são declarações que apresentam o estado do sistema após a execução de uma determinada operação de um objeto. Em OCL, para declararmos uma expressão na forma de pós-condição utilizamos a palavra reservada post após a declaração do contexto seguido do seguido do símbolo :. Para as pós-condições temos a seguinte expressão típica context <contexto> post: <expressao> Utilizando o exemplo básico, segue um exemplo: O salário de uma pessoa varia de acordo com uma data context Person::income(d: Date) post: if d > 01/01/2001 then result = 3000 else result = Tipos de dados Uma das características da OCL é possuir uma classificação hierárquica para os tipos de dados. Toda informação manipulada, nas expressões construídas em OCL, tem que pertencer a um dos seguintes grupos de variáveis: Tipos básicos: Integer, Real, Boolean e String; Coleções: Collection, Set, Sequence e Bag; Tipos Especiais: OclAny, OclType e OclExpression; Tipos dos modelos UML: todas as classes, interfaces, associações e enumerações introduzidas por um diagrama de classes Hierarquia de classes O tipo OclAny é a superclasse de todos os tipos de dados. Cada tipo de dados define uma série de operações que podem ser aplicadas a ele próprio ou dos seus descendentes. Segue abaixo a hierarquia de classes da OCL: diagrama da hierarquia de classes Daniel Henrique Alves Lima, Rafael Musial

8 2.2.2 Polimorfismo Os tipos de dados da UML podem ser criados a partir de polimorfismo, porém na definição formal da linguagem não há informações precisas de como fazer isto Meta-tipos Os tipos especiais de dados da OCL são tipos de dados que foram criados para especificar os que são realmente utilizados em modelagens. Na classe superior OclAny estão localizadas algumas operações de inferência sobre a própria classe e seus valores, as quais foram herdadas por todos os outros tipos de dados. OCL: Tipos herdados de modelos UML Estes são os possíveis característcas de modelos UML que são acessíveis em expressões Classifiers: Classifier são atributos da UML que servem para criar tipos de dados. Classes de objetos são a mais frequente ocorrência de classificadores encontrados em expressões OCL. Attributos: Atributos são propriedades estruturais que caracterizam um classifier Assossiações: Uma associação conecta 2 ou mais classifiers. Operações: Todas as operações e métodos que estiverem em um modelo podem fazer parte de expressões OCL. Enumerações: Enumerações são um tipo de conjunto extendido dos tipos básicos de dados Collections Collection é o supertipo abstrato de todas as coleções em OCL. Todo objeto que faz parte de uma coleção é chamado de elemento. Se ocorrer que um objeto apareça 2 vezes na coleção, teremos 2 elementos nessa coleção. Normalmente quando temos associações que foram derivadas de modelos UML, e nessa associação temos um relacionamento de um para muitos ou de muitos para muitos, a parte da assossiação que aparece multivalorada é considerada uma coleção Set Set é o conjunto matemático que conhecemos. Ele contém elementos que não podem ser duplicados Bag Bag é uma coleção de elementos que podem aparecer duplicados, isto é, um objeto pode ser um elemento na Bag por várias vezes. E não existe ordem entre os elementos Sequence Sequence é uma coleção onde os elementos estão ordenados segundo algum critério. Na sequencia também pode aparecer duplicatas. 2.3 Algumas Palavras Reservadas Para estruturar melhor algumas restrições em OCL, foram criadas algumas palavras especiais que desempenham funções especiais no contexto da expressão. Daniel Henrique Alves Lima, Rafael Musial

9 2.3.1 Let... in Algumas vezes uma pequena parte da expressão é utilizada mais de uma vez na expressão. As palavras reservadas let...in permitem a definição de uma variável (que contém a pequena parte da expressão) a qual pode ser usada na restrição a ser expressada. context Person inv: let income : integer = self.job.salary->sum in income > If then. else... end if Para uma restrição que envolve condições, foram criadas as palavras reservadas if...then...else...end if. context Person inv: let income : integer = self.job.salary->sum in if self.isunemployed then income < 100 else income >= 100 end if 2.4 Algumas operações sobre os tipos de dados Collection da OCL A sintaxe básica de uma operação sobre uma coleção é: [tipo de dado] -> [operação] Select e Reject Select é uma operação sobre uma collection que permite escolher dentre os seus elementos os que tem uma determinda característica. Reject é a operação que contém o complemento do conjunto selecionado por Select. A sintaxe desse comando é: collection -> select (expressão booleana) O resultado da expressão contém todos os elementos da collection que possuem a avaliação da expressão booleana como true ForAll Muitas vezes queremos que uma restrição seja aplicada a todos os elementos de uma collection. Para isso utilizamos a operação forall que tem a seguinte sintaxe: Collection -> forall (v: Type expressão booleana com v) A avaliação de uma expressão com forall retorna um valor booleano. O resultado é verdadeiro se todos os elementos da coleção são avaliados como verdadeiros em relação a expressão booelana com v Exists Muitas vezes necessitamos saber se pelo menos um dos elementos de um conjunto respeita uma restrição. Para isso utilizamos a operação exists, com o seguinte formato: Collection -> exists (v: Type expressão booleana com v) Daniel Henrique Alves Lima, Rafael Musial

10 2.4.4 OclIsTypeOf OclIsTypeOf é uma operação aplicada ao tipo de dados oclany (superclasse de todos os tipos de dados) que retorna verdadeiro se o objeto a qual a expressão foi aplicada é do tipo especificado. Object -> oclistypeof (type: OclType) : boolean OclIsNew Operação que permite saber se objeto ao qual foi aplicada essa operaçao é uma nova instância. Só pode ser utilizada em pós condições. Object -> oclisnew : boolean Daniel Henrique Alves Lima, Rafael Musial

11 3 O método Visando a utilização de OCL como ferramenta para a especificação do sistema, o seguinte método, derivado do livro Applying UML and Patterns, foi utilizado : Primeiramente, os requisitos funcionais foram capturados na forma de casos de uso, havendo mapeamento direto destes às funções do sistema (obtidas nas primeiras aulas) através da propriedade CROSS REFERENCE do caso de uso extendido. Um caso de uso nada mais é do que um processo do domínio, um cenário sobre a utilização do sistema a ser desenvolvido. Comprar bebida Use case : Comprar bebida Actors : Cliente Purpose :? Overview : Cliente fornece dinheiro à máquina de bebidas e escolhe a bebida desejada. A bebida é produzida e, ao final, o cliente obtém a bebida Type : primária e essencial Cross references : R1.1,R1.2,R1.3,R1.4,R1.7,R1.8,R1.10 Exemplo de um caso de uso Funções do sistema Ref # Função Categoria R1.1 Permitir escolha de bebida R1.2 Receber pagamento R1.3 Disponibilizar troco R1.4 Disponibilizar bebida R1.5 Permitir reposição de produtos R1.6 Permitir reposição de dinheiro (troco) R1.7 Sinalizar falta de produtos R1.8 Sinalizar falta de dinheiro para troco R1.9 Emitir histórico de vendas R1.10 Devolver pagamento efetuado Exemplo de lista de funções de um sistema O próximo passo consistiu na construção de um modelo conceitual. Tal modelo corresponde, na verdade, a um diagrama de classes onde os "conceitos" (classes) de maior importância, do ponto de vista dos usuários do sistema e não do funcionamento interno do mesmo, são expostos junto a seus atributos e relacionamentos (associações e generalizações) entre tais conceitos. Cabe aqui ressaltar que tais classes não possuem comportamento. Estamos lidando com um modelo conceitual e a atribuição de responsabilidades a uma determinada classe faz parte da fase de projeto e não da análise. Em um processo de desenvolvimento como o RUP (Rational Unified Process), por exemplo, tal modelo seria semelhante a um modelo de negócios. Daniel Henrique Alves Lima, Rafael Musial

12 Exemplo de um diagrada de classes Através de cada caso de uso, os eventos ao quais o sistema deveria responder (e as operações correspondentes) foram identificados. Um evento corresponde a um estímulo externo (ao sistema) que provoca modificações no estado do sistema. As operações possuem o mesmo nome que o evento e funcionam como respostas ao mesmo. Actor action 1. Este caso de uso começa quando o cliente fornece dinheiro à máquina de bebidas 3. O cliente escolhe a bebida desejada dentre as bebidas disponíveis Exemplo de eventos e resposta System response 2. Sinaliza bebidas disponíveis de acordo com a quantia de dinheiro fornecida e com a disponibilidade (em estoque) das mesmas 4. Determinada a necessidade de troco, produz e disponibiliza a bebida desejada Para cada operação descoberta, as alterações que esta provocada no sistema (expostas na forma de instanciações, criação e destruição de associações e modificações de atributos de classes do modelo conceitual) foram descritas na forma de contratos. Na confecção destes contratos, OCL foi aplicada. Contrato para fornecerdinheiro Name: fornecerdinheiro(dinheiro:moeda) Responsibilities: Fornecer dinheiro à máquina de bebida. Atualizar contagem da quantia de dinheiro fornecida pelo cliente. Exibir bebidas disponíveis. Type: System Cross References: R2.1 Notes: Exceptions: Output: OCL Specification: context Sistema::fornecerDinheiro(dinheiro:Moeda) pre:dinheiro.valor=1.0 post:maquinadebebida.carteiradocliente@pre->size=0 implies maquinadebebida.carteiradocliente->size=1 and maquinadebebida.carteiradocliente.oclisnew=true post:maquinadebebida.carteiradocliente.oclisnew=true implies maquinadebebida.carteiradocliente.itemderepositoriodedinheiro- >size=1 and itemmaisrecente(maquinadebebida.carteiradocliente).oclisnew=true Daniel Henrique Alves Lima, Rafael Musial

13 then post:if itemmaisrecente(maquinadebebida.carteiradocliente).oclisnew itemmaisrecente(maquinadebebida.carteiradocliente).moeda=dinheiro and itemmaisrecente(maquinadebebida.carteiradocliente).quantidade=1 else itemmaisrecente(maquinadebebida.carteiradocliente).quantidade= endif Exemplo de um contrato usando OCL 3.1 As ferramentas Para a modelagem, usando UML, as ferramentas ObjectDomain e ArgoUML foram utilizadas. A primeira se trata de uma ferramenta shareware desenvolvida em Java e cuja limitação está no número de classifiers (classes, interfaces, tipos, atores e etc) que podem ser gerados. A Object Domain R3 - Version mostrou-se extremamente profissional e bem desenvolvida, estando apta a importar e exportar diagramas no formato utilizado pelo Rational Rose, além de utilizar um formato particular para seus arquivos. Além disto constatou-se que tal ferramenta é 100% UML 1.1 compliant, sendo capaz de gerar todos os diagramas (estáticos e dinâmicos) descritos na especificação da UML e de acordo com a mesma. Todavia, esta ferramenta não oferece suporte à OCL, nem promove integração a nenhum parser para tal linguagem. Desta deficiência surgiu a necessidade de utilização de outra ferramenta. Tela da janela do Object Domain 3.0 Daniel Henrique Alves Lima, Rafael Musial

14 A ferramenta adotada foi a ArgoUML(v 8.0.1a). Tal decisão baseou-se em dois pontos principais : é um software freeware, implementado em Java, e provê integração a um parser OCL (o OCLCompiler). A ArgoUML apresenta uma série de limitações, dentre as quais vale citar : A forma como os atributos e operações de uma classe são definidas é não-uml, sendo semelhante a declarações em C++ e Java Não é possível a utilização de association classes o que, em nosso caso, acabou gerando um modelo conceitual extremamente poluído e com menor enfoque nos conceitos (classes) realmente importantes Não é possível remover diagramas de classes uma vez que estes tenham incluídos no modelo A definição de esteriótipos, para operações, não é explícita e uma vez realizada, não se torna visível no diagrama de classes Não é possível gerar diagramas de seqüência, apenas diagramas de colaboração Janela da ferramenta ARGO UML Janela do parser da ferramenta ARGO UML Daniel Henrique Alves Lima, Rafael Musial

15 4 Exemplo de caso de uso O exemplo do caso de uso abaixo está relacionado com a especificação de requisitos feita em sala de aula sobre uma máquina de auto-atendimento de venda de bebidas. 4.1 Funções do sistema Estas funções foram derivadas do documento de especificação de requisitos gerado em sala de aula e aprovado por todos os alunos Funções básicas Ref # Função Categoria R1.1 Permitir escolha de bebida R1.2 Receber pagamento R1.3 Disponibilizar troco R1.4 Disponibilizar bebida R1.5 Permitir reposição de produtos R1.6 Permitir reposição de dinheiro (troco) R1.7 Sinalizar falta de produtos R1.8 Sinalizar falta de dinheiro para troco R1.9 Emitir histórico de vendas R1.10 Devolver pagamento efetuado 4.2 Casos de Uso Estes são os casos de usos mapeados para o sistema da máquina de bebidas: Casos de uso desenhados pela ferramenta Object Domain Daniel Henrique Alves Lima, Rafael Musial

16 Referência Caso de uso R2.1 UC : Comprar bebida R2.2 UC : Obter histórico de venda R2.3 UC : Validar identificação do técnico Tabela dos casos de uso mapeados UC : Comprar bebida Use case : Comprar bebida Actors : Cliente Purpose :? Overview : Cliente fornece dinheiro à máquina de bebidas e escolhe a bebida desejada. A bebida é produzida e, ao final, o cliente obtém a bebida Type : primária e essencial Cross references : R1.1,R1.2,R1.3,R1.4,R1.7,R1.8,R1.10 Typical course of events Actor action 1. Este caso de uso começa quando o cliente fornece dinheiro à máquina de bebidas 3. O cliente escolhe a bebida desejada dentre as bebidas disponíveis 5. O cliente obtém a bebida desejada correspondente 7. O cliente obtém o troco System response 2. Sinaliza bebidas disponíveis de acordo com a quantia de dinheiro fornecida e com a disponibilidade em estoque das mesmas 4. Determinada a necessidade de troco, produz e disponibiliza a bebida desejada 6. Disponibiliza troco Alternative courses Actor action Linha 3: O cliente fornece mais dinheiro à máquina de bebidas Linha 3: O cliente escolhe a bebida desejada dentre as bebidas disponíveis O cliente cancela o pedido pela bebida Linha 3: O cliente cancela o pedido pela bebida System response Sinaliza bebidas disponíveis de acordo com a quantia de dinheiro fornecida até o momento e com a disponibilidade em estoque das mesmas Para a escolha feita, a quantia de dinheiro para troco é insuficiente. Notifica cliente. Cancela o pedido e disponibiliza o dinheiro fornecido pelo cliente Cancela o pedido e disponibiliza o dinheiro fornecido pelo cliente Daniel Henrique Alves Lima, Rafael Musial

17 4.2.2 UC : Obter histórico de vendas Use case : Obter histórico de vendas Actors : Técnico, Relógio Purpose :? Overview : Técnico provê identificação necessária e solicita histórico de vendas. Ao final, histórico correspondente é obtido Type : primária e essencial Cross references : R1.9 Typical course of events Actor action 1. Este caso de uso começa quando o técnico provê a identificação adequada à máquina de bebidas 3. Técnico solicita último histórico de vendas 5. Técnico obtém histórico de vendas e finaliza operação System response 2. Executa UC : Validar identificação do técnico, dando privilégios ao técnico, para obter histórico de vendas 4. Obtém data atual (a partir do relógio da máquina) e gera histórico de vendas 6. Termina privilégios para obtenção de histórico Alternative courses Actor action Linha 1 : Técnico provê identificação adequada à máquina de bebidas Linha 3 : Técnico solicita último histórico de vendas Linha 3 : Técnico finaliza operação de obtençâo de histórico System response Executa UC : Validar identificação do técnico. Identificação inválida. Bloquear acesso a operação de obtenção de histórico de venda Último histórico indisponível. Notifica técnico Privilégios para obtenção de históricos são terminados Daniel Henrique Alves Lima, Rafael Musial

18 4.2.3 UC : Validar identificação do técnico Use case : Validar identificação do técnico Actors : Técnico Purpose :? Overview : Técnico provê identificação necessária. Tal identificação é verificada e, ao final, privilégios para a execução de operações especiais são concedidas ao mesmo. Type : primária e essencial Cross references : R1.5, R1.6 e R1.9 Typical course of events Actor action 1. Este caso de uso começa quando o técnico provê a identificação adequada à máquina de bebidas Alternative courses System response 2. Verifica que a identificação é valida, ou seja, se pertence à um técnico conhecido pelo sistema. Identificação válida : concede privilégios para execução de operações especiais Actor action Linha 1: Técnico provê identificação adequada à máquina de bebidas System response Identificação inválida : bloquear acesso as operações especiais Daniel Henrique Alves Lima, Rafael Musial

19 4.3 Diagrama de sequencia Daniel Henrique Alves Lima, Rafael Musial

20 4.4 Diagrama de classes Estes foram os diagramas de classes conceituais de algumas partes do sistema: Sistema Bebidas Daniel Henrique Alves Lima, Rafael Musial

21 4.4.3 Estoques Repositórios de Dinheiro Daniel Henrique Alves Lima, Rafael Musial

22 4.4.5 Registros de Venda 4.5 Contratos com OCL Nesta seção estão representados os contratos do sistema. Na orientação a objetos, o contrato descreve de forma clara e unívoca as obrigações de um objeto, sendo que este executará seus serviços (obrigações) mediante certas o cumprimento de certas estipulações (direitos ou condições iniciais sob as quais o serviço será prestado). Esta relacionado à definição da interface de um objeto. Difere do contrato legal por não necessitar de um cliente Contrato para fornecerdinheiro Name: fornecerdinheiro(dinheiro:moeda) Responsibilities: Fornecer dinheiro à máquina de bebida. Atualizar contagem da quantia de dinheiro fornecida pelo cliente. Exibir bebidas disponíveis. Type: System Cross References: R2.1 Notes: Exceptions: Output: OCL Specification: context Sistema::fornecerDinheiro(dinheiro:Moeda) pre:dinheiro.valor=1.0 post:maquinadebebida.carteiradocliente@pre->size=0 implies maquinadebebida.carteiradocliente->size=1 and maquinadebebida.carteiradocliente.oclisnew=true post:maquinadebebida.carteiradocliente.oclisnew=true implies maquinadebebida.carteiradocliente.itemderepositoriodedinheiro- >size=1 and itemmaisrecente(maquinadebebida.carteiradocliente).oclisnew=true Daniel Henrique Alves Lima, Rafael Musial

23 then post:if itemmaisrecente(maquinadebebida.carteiradocliente).oclisnew itemmaisrecente(maquinadebebida.carteiradocliente).moeda=dinheiro and itemmaisrecente(maquinadebebida.carteiradocliente).quantidade=1 else itemmaisrecente(maquinadebebida.carteiradocliente).quantidade= endif Contrato para escolherbebida Name: escolherbebida(idbebida:integer) Responsibilities: Escolher bebida. Calcular troco necessário baseado no que já foi pago e no preço da bebida. Produzir e disponibilizar bebida escolhida. Type: System Cross References: R2.1 Notes: Exceptions: Troco insuficiente : não produzir/disponibilizar a bebida e notificar o cliente. Output: OCL Specification: context Sistema::escolherBebida(idBebida:Integer) pre: bebidadisponivel(idbebida) and trocosuficiente(obterbebida(idbebida).preco) post:maquinadebebida@pre.historicodevenda->size=0 implies maquinadebebida.historicodevenda->size=1 and maquinadebebida.historicodevenda.oclisnew=true post:maquinadebebida.historicodevenda.oclisnew implies maquinadebebida.historicodevenda.datainicial=obterdataatual() post:if maquinadebebida.historicodevenda.oclisnew then maquinadebebida.historicodevenda.venda->size=1 else maquinadebebida.historicodevenda.venda->size= maquinadebebida.historicodevenda@pre.venda->size+1 endif post:vendaatual(maquinadebebida.historicodevenda).oclisnew=true and vendaatual(maquinadebebida.historicodevenda).bebida=obterbebida(idbebida) post:obteritem(maquinadebebida.estoquedebebida,obterbebida(idbebida)).quantidade= obteritem(maquinadebebida.estoquedebebida@pre,obterbebida(idbebida)).quanti dade-1 Daniel Henrique Alves Lima, Rafael Musial

24 4.6 Restrições em OCL As restrições aqui colocadas foram retiradas dos contratos expressos na seção anterior Constraint fornecer dinheiro context Sistema::fornecerDinheiro(dinheiro:Moeda) pre:dinheiro.valor=1.0 implies maquinadebebida.carteiradocliente->size=1 and maquinadebebida.carteiradocliente.oclisnew=true post:maquinadebebida.carteiradocliente.oclisnew=true implies maquinadebebida.carteiradocliente.itemderepositoriodedinheiro- >size=1 and itemmaisrecente(maquinadebebida.carteiradocliente).oclisnew=true post:if itemmaisrecente(maquinadebebida.carteiradocliente).oclisnew then itemmaisrecente(maquinadebebida.carteiradocliente).moeda=dinheiro and itemmaisrecente(maquinadebebida.carteiradocliente).quantidade=1 else itemmaisrecente(maquinadebebida.carteiradocliente).quantidade= endif Constraint escolher bebida context Sistema::escolherBebida(idBebida:Integer) pre: bebidadisponivel(idbebida) and trocosuficiente(obterbebida(idbebida).preco) implies maquinadebebida.historicodevenda->size=1 and maquinadebebida.historicodevenda.oclisnew=true post:maquinadebebida.historicodevenda.oclisnew implies maquinadebebida.historicodevenda.datainicial=obterdataatual() post:if maquinadebebida.historicodevenda.oclisnew then maquinadebebida.historicodevenda.venda->size=1 else maquinadebebida.historicodevenda.venda->size= endif post:vendaatual(maquinadebebida.historicodevenda).oclisnew=true and vendaatual(maquinadebebida.historicodevenda).bebida=obterbebida(idbebida) post:obteritem(maquinadebebida.estoquedebebida,obterbebida(idbebida)).quantidade= dade-1 Daniel Henrique Alves Lima, Rafael Musial

25 5 Verificação e Validação do modelo As atividades de verificação e validação durante a modelagem são importantes no intuito de reduzir as falhas nas etapas posteriores do desenvolvimento, reduzindo custos e aumentando a qualidade do produto. A verificação consiste num conjunto de atividades para certificar se a forma conceitual adotada na formulação do modelo foi transcrita corretamente ao utilizar-se das linguagens de modelagem. A validação é uma coletânea de ações utilizadas para analisar se um dado modelo representa com fidedignidade o sistema em estudo. Podendo este procedimento ser conduzido em conjunto com a verificação, fato que imprimirá maior confiabilidade ao modelo. 5.1 Processo O processo utilizado para verificação e validação do nosso modelo baseou-se num conjunto de técnicas conhecidas para verificação e validação de modelos. Em primeira instância utilizamos a técnica de passeio. Construímos alguns cenários diferentes e passeamos pelo modelo, desde a lista básica de funções até os contratos para verificar se os requisitos necessários estavam no modelo especificado. Logo na etapa seguinte, baseado nas ligações (cross references) entre os casos de uso, as funções básicas do sistema e os contratos, percorremos as ligações para verificar se todas as funções básicas do sistema eram cobertas pelos casos de uso e pelos contratos. Para validar se o diagrama de classes satisfazia os requisitos, utilizamos de uma lista de falhas mais comuns para modelagens orientadas a objetos e fizemos mais uma inspeção no diagrama de classes Para finalizar, utilizamos a ferramenta ArgoUML para verificar a sintaxe e a semântica das especificações OCL de nossos contratos. 5.2 Considerações sobre a aplicação do processo no caso de uso Na tentativa de simplificar o modelo, operações com esteriótipo <<ocloperation>> foram escritas. Tais operações têm importância apenas para a especificação (não precisando ser implementadas e não correspondendo a funcionalidades do sistema) e são, necessariamente, consultas apenas (isquery=true) 1, não causando modificações nas classes para as quais são definidas (e nem em nenhuma outra classe). 5.3 Ferramentas 1 Para mais detalhes sobre isquery, observar figurar nesta página. Daniel Henrique Alves Lima, Rafael Musial

26 Para a verificação (de consistência e de tipo) das restrições OCL geradas, o software OCL Compiler foi utilizado. Na verdade, tal software corresponde a uma API Java que deve ser integrada a uma ferramenta de modelagem como a ArgoUML, por exemplo. O mecanismo utilizado para tal possibilitar tal integração é a implementação de determinadas interfaces 2 O OCL Compiler é acionado quando uma restrição é adicionada a um elemento do modelo e o parser é ativado. A análise sintática de consistência (verificação de consistência e de tipo) é realizada quando o botão Parse é pressionado. Erros durante a verificação de consistência assumem a forma exposta abaixo : 2 Para mais informações : Daniel Henrique Alves Lima, Rafael Musial

27 Erros durante a verificação de tipos têm o seguinte feedback : A integração com o OCLParser foi parcialmente satisfatória. Pós-condições onde a manipulação de resultados da operação era necessária e expressões que fizessem uso de let não puderam ser utilizadas, o que ocasionou, novamente, crescimento desnecessário (em complexidade) do modelo gerado, resultando na falta de clareza do mesmo, Tal deficiência pode ser constatada nas restrições OCL abaixo e nas mensagens de erro geradas : Daniel Henrique Alves Lima, Rafael Musial

28 Daniel Henrique Alves Lima, Rafael Musial

29 Daniel Henrique Alves Lima, Rafael Musial

30 Daniel Henrique Alves Lima, Rafael Musial

31 6 Conclusões Neste artigo procuramos mostrar alguns conceitos fundamentais da linguagem OCL, suas características principais e alguns exemplos de sintaxe. Logo em seguida expusemos como a linguagem pode ser utilizada na modelagem conceitual de sistemas e um exemplo de uso do processo de modelagem. Para verificar o processo de modelagem, montamos um procedimento para verificar e validar nosso modelo que consistiu no uso de algumas técnicas bem conhecidas para aumentar a qualidade do software produzido. Utilizamos algumas ferramentas disponíveis no mercado e tecemos alguns comentários sobre elas, tanto na parte de modelagem quanto na parte de verificação. 6.1 Limitações Além das limitações ferramentais citadas no texto, constatamos que a linguagem oferece pouco suporte para trabalhar com restrições que não estejam ligadas a modelos orientados a objetos. Notamos ainda que existe uma deficiência em algumas operações sobre os tipos de dados da OCL que facilitariam a modelagem de restrições sobre os dados. 6.2 Tipos de aplicacoes adequadas Algumas aplicações de OCL: Especificar condições invariantes em classes e tipos num modelo de classes; Especificar pré e pós-condições em operações e Métodos; Como uma linguagem de navegação para modelos de objetos; Para especificar restrições em operações (design por contrato); OCL pode ser utilizada para especificar guard conditions e change events nos diagramas de transição de estados (em tais casos, a contextual class é a mesma usada no diagrama em questão). Definir esteriótipos. Por exemplo, a definição de um esteriótipo para classes de objetos imutáveis (como a classe String, em Java), poderia ser dada por : context Immutable inv : self.feature->select(ocliskindof(behavioralfeature))->forall(isquery=true) Especificar restrições de unicidade : context ItemDePedido inv : ItemDePedido.allInstances->forAll(ip self.produto<>ip.produto implies self<>ip) Daniel Henrique Alves Lima, Rafael Musial

32 6.3 Considerações gerais Da experiência adquirida com a utilização de OCL pôde-se constatar que esta se trata de uma linguagem extremamente poderosa quando aplicada corretamente. O que se pôde perceber foi que o método adotado e a tentativa de introduzir de OCL neste método não foram decisões muito acertadas. As restrições escritas emocl tornaram-se extremamente complexas devido a falta de "orientação à objetos" da especificação obtida. Uma vez que o diagrama de classes gerado tratava apenas de conceitos do domínio do problema, estes não poderiam ter responsabilidades ou qualquer comportamento. Desta forma, restrições como pré e pós-condições só poderiam ser escritas utilizando-se o conceito "Sistema" (o único a definir um comportamento através de um conjunto de operações). Uma possível alternativa teria sido especificar operações (para os conceitos do modelo) com esteriótipo <<ocloperation>>, mas de forma a deixar claro que tais operações só são interessantes para a especificação dos requisitos e para a análise, impedindo, assim, que projetistas e desenvolvedores fizessem uso destas informações para a implementação de métodos para estas "classes" (conceitos). Daniel Henrique Alves Lima, Rafael Musial

33 7 Bibliografia Jos Warmer and Anneke Kleppe The Object Constraint Language, 1998 Addison-Wesley Craig Larman Applying UML and Patterns, 1998 Prentice Hall PTR, Upper Saddle River, New Jersey Martin Fowler UML Distilled, 1997 Addison-Wesley Eliane Martins Revisões Técnicas Universidade Estadual de Campinas Thomas Baar and Reiner Hahnle An Integrated Metamodel for OCL Types Ali Haimie, Franco Civello, John Howse, Stuat Ket, Richard Mitchell Reflections on Object Constraint Language Reiner Hahnle and Aarne Ranta Connecting OCL with the Rest of the World Luis Mandel and Maria Victoria Cengarle On the Expressive power of the Object Constraint language OCL, 1999 Mandana Vazini and Daniel Jackson Some Shortcomings of OCL, the Object Constraint Language of UML, 1999 Mark Richters and Martin Gogolla On Formalizing the UML Object Constraint Language OCL, 1998 Mark Richters and Martin Gogolla On Constraints and Query in UML Daniel Henrique Alves Lima, Rafael Musial