Coimbra, Abril de 2004

Integração de modelos formais e semi- formais: o caso de UML e VDM+

+João Pascoal Faria

Prof. Auxiliar, FEUP

Resumo

A linguagem de modelação visual UML é utilizada correntemente para efeito de especificação, análise, documentação e geração automática de partes da implementação

Esta comunicação aborda o enriquecimento dos modelos visuais em UML (semi-formais) através de: especificação formal de restrições (por invariantes),

semântica de operações (por pré e pós-condições) e concorrência, para obter modelos formais completos, rigorosos e verificáveis

especificação do corpo algorítmico de operações através de linguagens de acções de alto nível, para obter modelos executáveis e traduzíveis

Resumo

Em torno de UML têm surgido linguagens que permitem criar modelos formais - caso de OCL (Object Constraint Language) - e modelos executáveis e traduzíveis - caso de X

TUML - mas ainda não de forma perfeitamente integrada

Em contrapartida, VDM++ é uma linguagem de especificação formal orientada por objectos, que é baseada num standard maduro (VDM-SL), que permite criar modelos formais executáveis e traduzíveis, sendo suportada por ferramentas (VDMTools) que permitem sincronizar com Rational Rose, executar os modelos e gerar Java e C++

Índice

Introdução Modelos visuais (semi-formais) Dos modelos visuais aos modelos formais Dos modelos visuais aos modelos executáveis Dos modelos visuais aos modelos traduzíveis Modelos visuais, formais, executáveis e traduzíveis

Breve introdução às técnicas de especificação formal

Apresentação de um caso de estudo Conclusões

Modelos visuais (semi-formais)

Consensual e prática cada vez mais corrente: modelação visual (semi-formal) com

diagramas UML durante as fases de análise e especificação de requisitos, desenho de alto nível (arquitectura) e desenho detalhado

geração de algum código (Java, C#, SQL, XSD, etc.) a partir de UML e vice-versa

normalmente esqueletos de código, e não código completamente funcional

Modelos visuais são muito úteis para compreender e visualizar um sistema

Dos modelos visuais aos modelos formais

É possível enriquecer os modelos visuais (semi-formais) com especificações formais de

restrições (por invariantes) semântica de operações (por pré e pós-condições) aspectos de concorrência

Obtém-se um modelo formal que funciona como especificação completa, rigorosa (sem ambiguidades nem inconsistências) e verificável

Formal não quer dizer executável Modelos formais são importantes porque a

análise detalhada e o rigor necessários à sua construção permitem prevenir e detectar problemas mais cedo, quando a sua correcção é menos dispendiosa

Dos modelos visuais aos modelos executáveis

É possível enriquecer os modelos visuais com especificações do corpo algorítmico de operações (e actividades) em linguagens de acções de alto nível

Obtém-se um modelo executável (com a ajuda de ferramentas)

Modelos executáveis são importantes para efeito de teste e validação precoce do sistema (ainda na forma de modelo)

Dos modelos visuais aos modelos traduzíveis

É de esperar que os modelos executáveis sejam também traduzíveis (com a ajuda de ferramentas) para uma linguagem de implementação-alvo (Java, C++, C#, ...)

Geração automática de código completamente funcional e não só esqueletos de classes a partir de modelos de alto nível

Particularidades das linguagens, tecnologias e plataformas-alvo são embebidas nos geradores

Aumento de produtividade Acabam-se os programadores? Não! Apenas se programa a um nível mais

abstracto, e separa-se melhor o domínio do problema das tecnologias de implementação!

Modelos visuais, formais, executáveis e traduzíveis

Que solução integrada? Em torno de UML têm surgido linguagens que

permitem criar modelos formais - caso de OCL (Object Constraint Language) - e modelos executáveis e traduzíveis - caso de X

TUML - mas ainda não de forma perfeitamente integrada

Em contrapartida, o VDM++ é uma linguagem de especificação formal orientada por objectos que permite criar modelos formais, executáveis e traduzíveis, sendo suportada por ferramentas (VDMTools) que permitem sincronizar com Rational Rose, executar os modelos e gerar código Java e C++

Índice

Introdução Breve introdução às técnicas de especificação

formal O que são métodos formais? Especificação formal baseada em modelos Especificação formal baseada em propriedades Especificação formal baseada em comportamento Conclusões das técnicas de especificação formal

Apresentação de um caso de estudo Conclusões

O que são métodos formais?

Método Formal = Especificação Formal + Raciocínio Formal (verificação formal, ...)

As técnicas são suportadas por Matemática precisa Ferramentas de análise poderosas

Constituem um mecanismo rigoroso e efectivo para modelação, síntese e análise de sistemas

Especificação /Modelo formal

Implementaçãosíntese

análise

especificação/modelação

Classificação de linguagens de especificação formal

Baseadas em Modelos Sistema especificado em termos de um modelo de estado,

que é construído usando construções matemáticas como conjuntos e sequências, e de operações sobre esse estado

VDM, Z, VDM++, Object Z, ... Particularmente adequadas para especificar sistemas de

informação Baseadas em Propriedades

Sistema especificado em termos das suas operações e das relações entre essas operações

Algébricas – definem operações através de uma colecção de relações de equivalência (axiomas equacionais) - Obj, Larch, ...

Axiomáticas – definem operações através de predicados da lógica de primeira ordem - Larch, ...

Particularmente adequadas para especificar tipos de dados abstractos

Baseadas no Comportamento Sistema especificado em termos de sequências possíveis de

estados em vez de tipos de dados - Petri Nets, CSP, ... Particularmente adequadas para especificar sistemas

concorrentes e distribuídos

Exemplo de especificação formal baseada em modelos (VDM++)

class Stack instance variables

elems : seq of int := []; operations

Stack () == elems := []ext wr elemspost elems = [];

Push (i: int) ==elems := [i] ^ elemsext wr elemspost stack = [i] ^ ~elems;

Pop () ==elems := tl elemsext wr elemspre elems <> [] post elems = tl ~elems;

Top () res: int ==return hd elemspre elems <> [] post res = hd elems;

end Stack

Exemplo de especificação formal baseada em modelos (VDM++)

instance variables

elems : seq of int := [];

Escolhe-se uma representação (modelo) do estado baseada em construções matemáticas como conjuntos e sequências

Se fosse necessário, podiam-se especificar invariantes (restrições nos estados válidos).

Exemplo: inv len elems <= 1000;

Exemplo de especificação formal baseada em modelos (VDM++)

Pop () ==

elems := tl elems

ext wr elems

pre elems <> []

post elems = tl

~elems;

Pós-condição: relaciona resultado da operação e estado final do objecto com argumentos de chamada e estado inicial

Corpo algorítmico (executável!)

Pré-condição: condição nos argumentos de chamada e estado inicial do objecto a que tem de obedecer qualquer chamada válida.

Variáveis de instância cujo valor pode ser alterado pela operação

Valor antigo da variável de instância

tail

especificam semântica

Exemplo de especificação formal baseada em propriedades (OBJ)

Spec: Stack;Extend Nat bySorts: Stack;Operations:

newstack: Stackpush: Stack Nat Stackpop: Stack Stacktop: Stack Nat

Variables:s: Stack; n: Nat

Axioms:pop(newstack) = newstack;top(newstack) = zero;pop(push(s,n)) = s;top(push(s,n)) = n;

Mais abstracta: especifica semântica de operações por axiomas, sem necessidade de escolher uma representação de dados/estado interna (cf. noção de ADT)

Mas é mais difícil saber quando é que a especificação está completa!

Uma stack é sempre representada por uma expressão de construção

push(3, push(2, push(1, newstack)))

Axiomas permitem simplificar/avaliar expressões top(pop(push(2, push(1, newstack)))) = = top(push(1, newstack)) = 1

Exemplo de especificação formal baseada em propriedades (OBJ)

Exemplo de especificação formal baseada em comportamento (CSP)

Stack = EmptyStack

EmptyStack = top! EmptyStackException EmptyStack pop! EmptyStackException EmptyStack push? x OneElemStack(x); EmptyStack

OneElemStack(x) = top! x OneElemStack(x) pop! x Skip push? y OneElemStack(y); OneElemStack(x)

pu

sh

top

pop

Mais operacional!

envia a mensagem "EmptyStackExpression" pelo canal "top" e depois comporta-se como EmptyStack

"ou"processos

recebe um valor (mensagem) para x pelo canal "push" e depois comporta-se como a composição sequencial dos processos OneElemStack(x) e EmptyStack

Técnicas de especificação formal: conclusões e reflexões

As linguagens de especificação formal baseadas em modelos e orientadas por objectos (como VDM++ ou Object-Z) são as que se integram mais naturalmente com UML

Uma vantagem de VDM++ sobre Object-Z é que permite obter mais facilmente modelos executáveis e permite especificar mais naturalmente algoritmos

A linguagem OCL baseia-se (e enquadra-se) neste tipo de linguagens, sem ter ainda atingido o mesmo grau de maturidade

Índice

Objectivos e motivação Breve introdução às técnicas de especificação

formal Apresentação de um caso de estudo (agenda

corporativa) Caracterização sumária do sistema Lista de requisitos Modelo de casos de uso em UML Modelo de domínio em UML Tradução de UML para VDM++ Definição de tipos de dados em VDM++ Definição de classes em VDM++ Especificação de aspectos de concorrência em VDM++ Teste da especificação Documentação Geração de código

Conclusões

Caracterização sumária do sistema

Agenda "corporativa" Cada recurso (pessoa, espaço ou

equipamento) tem uma agenda associada (date book), com compromissos (appointments) e disponibilidades (slots)

Um compromisso pode envolver vários recursos e pode ocupar um conjunto de intervalos de tempo

Os compromissos marcados por terceiros estão sujeitos às disponibilidade manifestadas

O sistema deve ajudar o utilizador a marcar compromissos, mostrando hipóteses de marcação

Exemplos de aplicações: marcação de consultas, marcação de reuniões, reserva de equipamentos, etc.

Lista de requisitos (1)

1. O sistema deve permitir gerir a marcação de compromissos envolvendo vários recursos numa organização.

2. Os recursos englobam pessoas, espaços e equipamentos3. Cada recurso tem uma agenda associada.4. Cada agenda tem um dono, que é uma pessoa da

organização.5. O dono da agenda de uma pessoa é a própria pessoa6. Uma agenda (datebook) tem elementos de dois tipos:

compromissos (appointments) e disponibilidades (slots).7. Um compromisso é de um certo tipo (reunião, aula,

etc.), envolve um ou mais recursos e ocupa um intervalo de tempo ou um conjunto de intervalos de tempo, com resolução ao minuto.

8. Deve ficar registado quem marcou um compromisso (autor do compromisso).

Lista de requisitos (2)

9. Um recurso não pode ter dois compromissos ao mesmo tempo.

10. Uma disponibilidade refere-se a um recurso, um tipo de compromisso e um intervalo de tempo ou um conjunto de intervalos de tempo.

11. Uma pessoa só pode marcar um compromisso numa agenda de que não é dona, dentro das disponibilidades definidas pelo dono da agenda. Só o dono da agenda pode marcar compromissos sem verificação de disponibilidades.

12. As agendas podem ser consultadas por todas as pessoas da organização.

13. Os compromissos podem ser públicos ou privados. Um compromisso privado só pode ser consultado pelo autor do compromisso, pelas pessoas envolvidas no compromisso e pelos donos das agendas dos recursos envolvidos.

Lista de requisitos (3)

14. O sistema deve ajudar o utilizador a marcar compromissos da seguinte forma: o utilizador indica o tipo de compromisso a marcar (exemplo: reunião), os recursos envolvidos, a duração do compromisso e restrições temporais para a marcação do compromisso; o sistema deve fornecer uma lista de hipóteses de marcação; cada hipótese mostra um intervalo de tempo dentro do qual é possível marcar o compromisso em todos os recursos (porque têm declarada disponibilidade para o tipo de compromisso especificado e não têm marcados compromissos de qualquer tipo).

15. Compete ao administrador do sistema registar os recursos da organização (criando automaticamente as respectivas agendas) e definir os tipos de compromissos possíveis.

Modelo de casos de uso em UML(funcionalidades e perfis de utilizadores)

Can't see the details of private apointments in which he/she does not participate and was not the author and is not the owner of the datebook

MakePrivateApointment

MakePublicApointment

Can't create apointments in datebooks not owned by the user outside the slots previously defined

QueryDatebook

EmployeeActor MakeApointment SuggestSlots

<<extend>>

RegisterResourcesWithDatebooks

CreateApointmentTypes

SystemAdministrator

CreateSlotsForApointmentsDatebookOwner

Agenda Corporativa

actor

caso de uso(use case)

generalização

fronteira do sistema

restrição

Employee

DateBook

slots : map ApointmentType to TimeRegionT = {|->}

1+owner

1

Resource

rid : nat1name : StringTtype : ResourceType = <EMPLOYEE>

0..1+resource

0..1

0..1+datebook0..1

ApointmentType

description : StringC`StringT

Apointment

when : TimeRegionTvisibility : VisibilityTypedescription : StringT

1+author

1

0..n

+apointments

0..n

0..n

+datebooks

0..n

1+type 1

Company

name : StringT

0..n +resources0..n0..n+apointmentTypes

0..n

0..n+apointments

0..n

Modelo de domínio em UML (1)(modelação do estado do sistema)

tipos de dados e valores por omissão definidos em VDM++

para facilitar mapeamento para VDM++, associação bidireccional é representada por duas associações unidireccionais

classe

atributo

generalização

agregação

associação

role name

multiplicidade

Faltam os invariantes ...

Employee

Employee()

DateBook

slots : map ApointmentType to TimeRegionT = {|->}

DateBook()GetResource()GetOwner()AddSlot()AddApointment()GetApointments()GetSlotsOfType()

1+owner

1

Resource

rid : nat1name : StringTtype : ResourceType = <EMPLOYEE>

Resource()GetType()GetDatebook()

0..1+resource 0..1

0..1+datebook

0..1

ApointmentType

description : StringC`StringT

ApointmentType()GetDescription()

Apointment

when : TimeRegionTvisibility : VisibilityTypedescription : StringT

Apointment()GetType()GetWhen()GetAuthor()AddDatebook()GetDatebooks()

1+author

1

0..n

+apointments

0..n

0..n

+datebooks

0..n

1+type 1

Company

name : StringT

Company()AddApointmentType()AddEmployee()AddSpace()AddEquipment()AddSlot()AddApointment()SuggestSlots()GetApointments()GetSlots()GetName()GetApointmentTypes()FindApointmentType()GetResources()FindResource()AddResource()

0..n

+resources

0..n0..n

+apointmentTypes

0..n

0..n+apointments

0..n

Modelo de domínio em UML (2)(modelação das operações sobre o estado)

Agora com as operações mais importantes (assinaturas omitidas por falta de espaço)

Falta a semântica das operações ...

Principais transacções e

consultas

Tradução de UML para VDM++ (1)

Tradução de UML para VDM++ (2)

Definição de tipos de dados e classes em VDM++

Em VDM++, tipos e classes são conceitos diferentes Tipos são usados para representar tipos de

valores de atributos (tipos de dados) Classes são usadas para representar o

estado do sistema Instâncias de um tipo são valores puros Instâncias de uma classe são objectos Definição de um tipo pode ser acompanhada

de definição de valores (constantes) e funções (cf. paradigma funcional)

Definição de uma classe compreende a definição de variáveis de instância e operações (cf. paradigma de orientação por objectos)

Definição de tipos de dados em VDM++ (1)

Tipos de dados a definir neste caso (*):Tipo Descrição

StringT cadeia de um ou mais caracteres

Date data representada pelo número de dias decorridos desde uma data base, útil para processamento interno

UserDate data representada por uma combinação de dia, mês e ano

Time instante de tempo, representado pelo número de minutos decorridos desde as 0 horas da data base

UserTime instante de tempo, representado por uma combinação de minutos, horas, dia, mês e ano

TimeInterval

intervalo entre dois instantes de tempo, fechado à esquerda e aberto à direita, representado por 2 valores do tipo Time

Duration uma duração em minutos(*) Normalmente estes tipos de dados estariam definidos numa biblioteca

Definição de tipos de dados em VDM++ (2)

Tipos de dados a definir neste caso (cont.)Tipo Descrição

UserTimeInterval

intervalo entre dois instantes de tempo, fechado à esquerda e aberto à direita, representado por um par de valores do tipo UserTime

TimeRegion região de tempo (conjunto de intervalos de tempo) representada por um conjunto de intervalos de tempo unitários (com 1 min de duração), representados pelos seus inícios (valores do tipo Time)

representação abstracta pouco eficiente, mas que permite efectuar operações com regiões de tempo usando directamente os operadores de conjuntos (reunião, intersecção e diferença), simplificando a especificação

ResourceType tipo enumerado que admite os valores <EMPLOYEE>, <EQUIPMENT> ou <SPACE>

VisibilityType tipo enumerado que admite os valores <PUBLIC> ou <PRIVATE>

Exemplo de definição de tipos de dados em VDM++

types public UserDate :: year : nat1 month: nat1 day : nat1 inv d == d.month <= 12 and d.year >= Year0 and d.day <= DaysOfMonth(d.year, d.month);values private Year0 : nat1 = 1900; private UserDate0 : UserDate = mk_UserDate(Year0,1,1);

functions private static IsLeapYear(year: nat1) res : bool == year mod 4 = 0 and year mod 100 <> 0 or year mod 400 = 0;

private static DaysOfMonth(year, month: nat1) res : nat == (cases month : 1, 3, 5, 7, 8, 10, 12 -> 31, 4, 6, 9, 11 -> 30, 2 -> if IsLeapYear(year) then 29 else 28 end) pre month <= 12;(...)

definição de tipo de record

invariante

constantes construção de

record

pré-condição

Definição de classes em VDM++

Em VDM++, as classes são usadas para modelar o estado do sistema e as operações de consulta e alteração de estado

É possível gerar o esqueleto das classes em VDM++ a partir de um diagrama de classes UML (usando as ferramentas Rational Rose e VDMTools), e vice-versa

VDM++ permite completar a especificação das classes com invariantes de estado, pré e pós-condições das operações e corpo algorítmico das operações

Exemplo de definição de classe em VDM++ (variáveis de instância)

class Company

instance variables

public name : StringT;

public apointmentTypes : set of ApointmentType := {}; -- Must be initialized because of invariant.

public resources : set of Resource := {}; -- Must be initialized because of invariant.

public apointments : set of Apointment := {}; -- Because there is a many to many relationship between -- datebooks and apointments, they "belong" to the company -- and are referenced by datebooks (and vice versa)...

só para facilitar testes

conjunto de referências para objectos

Exemplo de definição de classe em VDM++ (invariantes)

... -- Key constraints -- uniqueness of Resource.rid inv forall r1, r2 in set resources & r1<> r2 => r1.rid <> r2.rid; -- Limitation: not checked if r.rid is changed...

-- Referential integrity constraints -- referential integrity of Apointment.type inv forall a in set apointments & a.type in set apointmentTypes; -- Limitation: not checked if a.type is changed...

-- Generic constraints...

Exemplo de definição de classe em VDM++ (operações de alteração)

operations

public AddApointmentType(desc: StringT) res : ApointmentType == ( dcl t: ApointmentType := new ApointmentType(desc); apointmentTypes := apointmentTypes union {t}; return t ) ext wr apointmentTypes pre desc not in set {at.description | at in set apointmentTypes} post apointmentTypes = apointmentTypes~ union {res} and res.description = desc;... "~" designa valor

antigo da variável

variável de instância que a operação pode alterar

pré-condição implicada por invariante (pode-se efectuar verificação formal)

Exemplo de definição de classe em VDM++ (operações de consulta)

public SuggestSlots(type: ApointmentType, rs: set of Resource, duration: TimeDurationT, within: TimeRegionT) res: set of UserTimeIntervalT == return {TimeIntervalToUserTimeInterval(ti) | ti in set TimeRegionToTimeIntervals( dinter { let r_slots = r.GetDatebook().GetSlotsOfType(type), r_apoints = dunion {a.when | a in set r.GetDatebook().GetApointments()} in (within inter r_slots \ r_apoints) | r in set rs } ) & Duration(ti)>=duration };

{f(x) | x in set ...} – define conjunto em compreensãodinter {...} – intersecção de elementos de conjuntodunion {...} – união de elementos de conjunto& - tal que

Especificação de aspectos de concorrência

Para além de suportar a definição de objectos activos (donos de threads), a linguagem VDM++ permite especificar declarativamente condições de sincronização sync per nome_operação => condição_de_guarda a execução da operação fica suspensa até a

condição de guardar se tornar verdadeira a condição de guarda pode basear-se no estado do

objecto e em contadores de execuções de operações (finalizadas, em espera, etc.)

Teste da especificação

Especificação pode ser testada interactivamente (com interpretador de VDM++) ou com base em casos de teste pré-definidos

Pode-se activar a verificação automática de invariantes, pré-condições e pós-condições

Um caso de teste tc1 é especificado por: ficheiro tc1.arg – com o comando a executar pelo

interpretador ficheiro tc1.arg.exp – com o resultado esperado da

execução do comando É produzida informação dos testes que

sucederam e dos testes que falharam É produzida informação de cobertura dos testes

o pretty printer "pinta" as partes da especificação que foram de facto executadas

são geradas tabelas com percentagem de cobertura e número de chamadas de cada operação e função

Documentação

Cada classe VDM++ é especificada num ficheiro em RTF, usando estilos pré-definidos para assinalar as partes de VDM++ (cf. programação literária)

Pretty printer formata as partes de VDM++ e gera versão mais bonita

Pode-se juntar tudo num documento final com paste link

Geração de código

Ferramentas geram código completamente funcional em Java e C++ Incluindo código para verificar pré-condições e pós-

condições

Facilmente legível no caso de Java

Código geralmente pouco eficiente tanto em Java como em C++

Principal dificuldade tem a ver com utilizar bibliotecas pré-existentes da linguagem alvo desde a fase de especificação

Limitações e melhoramentos a VDM++

Verificar invariantes quando muda o estado de objectos referenciados questão de conveniência, para suportar restrições

inter-objecto Definição de transacções permitindo diferir a

verificação de invariantes para o fim das transacções questão de necessidade, para suportar restrições

inter-objecto Na pós-condição de uma operação, poder

referir mensagens enviadas (chamada de operações ou envio de sinais) para poder especificar o comportamento de

operações que sinalizam eventos (exemplo: TextBox.setText)

OCL já permite referir mensagens enviadas, ainda que com limitações

problema: em geral, como se deve especificar o comportamento de operações envolvendo callbacks?

Índice

Introdução Breve introdução às técnicas de especificação

formal Apresentação de um caso de estudo Conclusões

Conclusões

A integração de UML com uma linguagem como VDM++ permite enriquecer os modelos visuais criados em UML com: especificação formal de restrições de estado e semântica

de operações especificação do corpo algorítmico de operações a um

nível de abstracção elevado especificação declarativa de aspectos de concorrência e

sincronização Obtém-se rapidamente uma especificação completa

(sintaxe + semântica) e rigorosa do sistema a desenvolver a um nível de abstracção elevado

Obtém-se rapidamente um modelo que pode ser executado, testado e validado

Suporta-se a geração automática de código completamente funcional

Facilita-se a verificação de conformidade da implementação com a especificação

Ganha-se em qualidade e produtividade (desde que se consiga evitar a duplicação de esforços)

Mais informação

www.ifad.dk/ - sobre VDM++ e VDMTools

www.projtech.com – sobre UML executável

www.uml.org – sobre UML, OCL, etc.

www.fe.up.pt/~jpf – mais detalhes sobre o caso de estudo apresentado