Entendendo OCL Modificadotechblog.desenvolvedores.net/wp-content/uploads/...Entendendo OCL Apresentação e utilização da Object Constraint Language 1.1 Daniel Henrique Alves Lima

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

1.1

Daniel Henrique Alves Lima [email protected]

Universidade Estadual de Campinas

Rafael Musial [email protected]


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 ([email protected])

Daniel Henrique Alves Lima, Rafael Musial 06.06.2001 1

Índice

ÍNDICE....................................................................................................................................... 1

1 INTRODUÇÃO ................................................................................................................... 3

2 A LINGUAGEM OBJECT CONSTRAINT LANGUAGE .................................................... 4

2.1 Expressões OCL ......................................................................................................................... 4 2.1.1 Tipos de expressões................................................................................................................ 4 2.1.2 Contexto de uma expressão.................................................................................................... 5 2.1.3 Self ......................................................................................................................................... 5 2.1.4 Invariantes .............................................................................................................................. 5 2.1.5 Pré condições ......................................................................................................................... 5 2.1.6 Pós-condições......................................................................................................................... 6

2.2 Tipos de dados ............................................................................................................................ 6 2.2.1 Hierarquia de classes.............................................................................................................. 6 2.2.2 Polimorfismo.......................................................................................................................... 7 2.2.3 Meta tipos............................................................................................................................... 7 2.2.4 Tipos herdados de modelos UML .......................................................................................... 7 2.2.5 Collecitions ............................................................................................................................ 7 2.2.6 Set........................................................................................................................................... 7 2.2.7 Bag ......................................................................................................................................... 7 2.2.8 Sequence ................................................................................................................................ 7

2.3 Algumas Palavras Reservadas .................................................................................................. 7 2.3.1 Let ... in .................................................................................................................................. 8 2.3.2 If… then.… else..... end if ...................................................................................................... 8

2.4 Algumas operações sobre os tipos de dados OCL ................................................................... 8 2.4.1 Select e Reject ........................................................................................................................ 8 2.4.2 ForAll ..................................................................................................................................... 8 2.4.3 Exists...................................................................................................................................... 8 2.4.4 OclIsTypeOf........................................................................................................................... 9 2.4.5 OclIsNew ............................................................................................................................... 9

3 O MÉTODO ...................................................................................................................... 10

3.1 As ferramentas ......................................................................................................................... 12

4 EXEMPLO DE CASO DE USO........................................................................................ 14

4.1 Funções do sistema................................................................................................................... 14 4.1.1 Funções básicas.................................................................................................................... 14

4.2 Casos de Uso ............................................................................................................................. 14 4.2.1 UC : Comprar bebida ........................................................................................................... 15 4.2.2 UC : Obter histórico de vendas ............................................................................................ 16 4.2.3 UC : Validar identificação do técnico .................................................................................. 17

4.3 Diagrama de seqüência ............................................................................................................ 18

4.4 Diagrama de classes ................................................................................................................. 19 4.4.1 Sistema ................................................................................................................................. 19


4.4.2 Bebidas................................................................................................................................. 19 4.4.3 Estoques ............................................................................................................................... 20 4.4.4 Repositórios.......................................................................................................................... 20 4.4.5 Registros de Venda .............................................................................................................. 21

4.5 Contratos com OCL................................................................................................................. 21 4.5.1 Contrato para fornecerDinheiro............................................................................................ 21 4.5.2 Contrato para escolherBebida .............................................................................................. 22

4.6 Restrições em OCL .................................................................................................................. 23 4.6.1 Constraint fornecer dinheiro................................................................................................. 23 4.6.2 Constraint escolher bebida ................................................................................................... 23

5 VERIFICAÇÃO E VALIDAÇÃO DO MODELO................................................................ 24

5.1 Processo..................................................................................................................................... 24

5.2 Resultados obtidos no exemplo de caso de uso ...........................Error! Bookmark not defined.

5.3 Ferramentas.............................................................................................................................. 24

6 CONCLUSÕES ................................................................................................................ 29

6.1 Sumário ..........................................................................................Error! Bookmark not defined.

6.2 Limitações ................................................................................................................................. 30

6.3 Tipos de aplicações adequadas................................................................................................ 30

7 BIBLIOGRAFIA................................................................................................................ 32


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 1997. 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.


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:

2.1.1 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;


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>.

2.1.3 Self Numa expressão em OCL, a palavra reservada self é usada para referenciar uma instância

do contexto.

2.1.4 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 > 0

2.1.5 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


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 = 2000

2.2 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.

2.2.1 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


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.

2.2.3 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.

2.2.4 Tipos herdados de modelos UML Estes são os possíveis característcas de modelos UML que são acessíveis em expressões

OCL: • 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

2.2.5 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.

2.2.6 Set Set é o conjunto matemático que conhecemos. Ele contém elementos que não podem ser

duplicados.

2.2.7 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.

2.2.8 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.


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 > 0

2.3.2 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]

2.4.1 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.

2.4.2 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.

2.4.3 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)


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

2.4.5 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


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.


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 System response

1. Este caso de uso começa quando o cliente fornece dinheiro à máquina de bebidas

2. Sinaliza bebidas disponíveis de acordo com a quantia de dinheiro fornecida e com a disponibilidade (em estoque) das mesmas

3. O cliente escolhe a bebida desejada dentre as bebidas disponíveis

4. Determinada a necessidade de troco, produz e disponibiliza a bebida desejada

Exemplo de eventos e resposta 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


post:if itemMaisRecente(maquinaDeBebida.carteiraDoCliente).oclIsNew then

itemMaisRecente(maquinaDeBebida.carteiraDoCliente).moeda=dinheiro and

itemMaisRecente(maquinaDeBebida.carteiraDoCliente).quantidade=1

else

itemMaisRecente(maquinaDeBebida.carteiraDoCliente).quantidade=

itemMaisRecente(maquinaDeBebida.carteiraDoCliente@pre).quantidade+1 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 3.00.002 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


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


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.

4.1.1 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


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

4.2.1 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 System response 1. Este caso de uso começa quando o cliente fornece dinheiro à máquina de bebidas

2. Sinaliza bebidas disponíveis de acordo com a quantia de dinheiro fornecida e com a disponibilidade em estoque das mesmas

3. O cliente escolhe a bebida desejada dentre as bebidas disponíveis

4. Determinada a necessidade de troco, produz e

disponibiliza a bebida desejada 5. O cliente obtém a bebida desejada correspondente

6. Disponibiliza troco 7. O cliente obtém o troco

Alternative courses

Actor action System response Linha 3: O cliente fornece mais dinheiro à máquina de bebidas

Sinaliza bebidas disponíveis de acordo com a quantia de dinheiro fornecida até o momento e com a disponibilidade em estoque das mesmas

Linha 3: O cliente escolhe a bebida desejada dentre as bebidas disponíveis

Para a escolha feita, a quantia de dinheiro para troco é insuficiente. Notifica cliente.

O cliente cancela o pedido pela bebida

Cancela o pedido e disponibiliza o dinheiro fornecido pelo cliente

Linha 3: O cliente cancela o pedido pela bebida

Cancela o pedido e disponibiliza o dinheiro fornecido pelo cliente


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 System response 1. Este caso de uso começa quando o técnico provê a identificação adequada à máquina de bebidas

2. Executa UC : Validar identificação do técnico, dando privilégios ao técnico, para obter histórico de vendas

3. Técnico solicita último histórico de vendas 4. Obtém data atual (a partir do relógio da

máquina) e gera histórico de vendas 5. Técnico obtém histórico de vendas e finaliza operação

6. Termina privilégios para obtenção de histórico Alternative courses

Actor action System response Linha 1 : Técnico provê identificação adequada à máquina de bebidas

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

Linha 3 : Técnico solicita último histórico de vendas

Último histórico indisponível. Notifica técnico Linha 3 : Técnico finaliza operação de obtençâo de histórico

Privilégios para obtenção de históricos são terminados


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 System response 1. Este caso de uso começa quando o técnico provê a identificação adequada à máquina de bebidas

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

Alternative courses

Actor action System response Linha 1: Técnico provê identificação adequada à máquina de bebidas

Identificação inválida : bloquear acesso as operações especiais


4.3 Diagrama de sequencia


4.4 Diagrama de classes Estes foram os diagramas de classes conceituais de algumas partes do sistema:

4.4.1 Sistema

4.4.2 Bebidas


4.4.3 Estoques

4.4.4 Repositórios de Dinheiro


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.

4.5.1 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


post:if itemMaisRecente(maquinaDeBebida.carteiraDoCliente).oclIsNew then


itemMaisRecente(maquinaDeBebida.carteiraDoCliente).quantidade=1

else


itemMaisRecente(maquinaDeBebida.carteiraDoCliente@pre).quantidade+1 endif

4.5.2 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:[email protected]>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= [email protected]>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)).quantidade-1


4.6 Restrições em OCL As restrições aqui colocadas foram retiradas dos contratos expressos na seção anterior.

4.6.1 Constraint fornecer dinheiro 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 post:if itemMaisRecente(maquinaDeBebida.carteiraDoCliente).oclIsNew

then


itemMaisRecente(maquinaDeBebida.carteiraDoCliente).quantidade=1 else


itemMaisRecente(maquinaDeBebida.carteiraDoCliente@pre).quantidade+1 endif

4.6.2 Constraint escolher bebida context Sistema::escolherBebida(idBebida:Integer) pre: bebidaDisponivel(idBebida) and trocoSuficiente(obterBebida(idBebida).preco) post:[email protected]>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= [email protected]>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)).quantidade-1


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.


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 interfaces2

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 : http://dresden-ocl.sourceforge.net/index.html#interfaces


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 :





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)


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).


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


• 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

Documents

Entendendo OCL Modificadotechblog.desenvolvedores.net/wp-content/uploads/...Entendendo OCL Apresentação e utilização da Object Constraint Language 1.1 Daniel Henrique Alves Lima