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

1. Integração de modelos formais e semi- formais: o caso de UML e VDM++ João Pascoal Faria Prof. Auxiliar, FEUP

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

3. 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 XTUML - 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++

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

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

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

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

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

9. 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 XTUML - 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++

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

11. 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/modelação síntese Especificação /Modelo formal Implementação análise

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

13. Exemplo de especificação formal baseada em modelos (VDM++) classStack instance variables elems : seq of int := []; operations Stack () == elems := [] ext wr elems post elems = []; Push (i: int) == elems := [i] ^ elems ext wr elems post stack = [i] ^ ~elems; Pop () == elems := tl elems ext wr elems pre elems <> [] post elems = tl ~elems; Top () res: int == return hd elems pre elems <> [] post res = hd elems; endStack

14. 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: invlen elems <= 1000;

15. Exemplo de especificação formal baseada em modelos (VDM++) Pop () == elems := tl elems ext wr elems pre elems <> [] post elems = tl ~elems; Corpo algorítmico (executável!) Variáveis de instância cujo valor pode ser alterado pela operação Pré-condição: condição nos argumentos de chamada e estado inicial do objecto a que tem de obedecer qualquer chamada válida. especificam semântica Pós-condição: relaciona resultado da operação e estado final do objecto com argumentos de chamada e estado inicial tail Valor antigo da variável de instância

16. Exemplo de especificação formal baseada em propriedades (OBJ) Spec: Stack; Extend Nat by Sorts: Stack; Operations: newstack:  Stack push: Stack  Nat  Stack pop: Stack  Stack top: Stack  Nat Variables: s: Stack; n: Nat Axioms: pop(newstack) = newstack; top(newstack) = zero; pop(push(s,n)) = s; top(push(s,n)) = n;

17. Exemplo de especificação formal baseada em propriedades (OBJ) • 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çãopush(3, push(2, push(1, newstack))) • Axiomas permitem simplificar/avaliar expressões top(pop(push(2, push(1, newstack)))) = = top(push(1, newstack)) = 1

18. Exemplo de especificação formal baseada em comportamento (CSP) envia a mensagem "EmptyStackExpression" pelo canal "top" e depois comporta-se como EmptyStack processos "ou" recebe um valor (mensagem) para xpelo canal "push" e depois comporta-se como a composição sequencial dos processos OneElemStack(x) e EmptyStack Mais operacional! 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) pop push top

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

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

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

22. Lista de requisitos (1) • O sistema deve permitir gerir a marcação de compromissos envolvendo vários recursos numa organização. • Os recursos englobam pessoas, espaços e equipamentos • Cada recurso tem uma agenda associada. • Cada agenda tem um dono, que é uma pessoa da organização. • O dono da agenda de uma pessoa é a própria pessoa • Uma agenda (datebook) tem elementos de dois tipos: compromissos (appointments) e disponibilidades (slots). • 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. • Deve ficar registado quem marcou um compromisso (autor do compromisso).

23. Lista de requisitos (2) • Um recurso não pode ter dois compromissos ao mesmo tempo. • Uma disponibilidade refere-se a um recurso, um tipo de compromisso e um intervalo de tempo ou um conjunto de intervalos de tempo. • 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. • As agendas podem ser consultadas por todas as pessoas da organização. • 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.

24. Lista de requisitos (3) • 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). • Compete ao administrador do sistema registar os recursos da organização (criando automaticamente as respectivas agendas) e definir os tipos de compromissos possíveis.

25. Modelo de casos de uso em UML(funcionalidades e perfis de utilizadores) actor fronteira do sistema generalização restrição caso de uso (use case) Agenda Corporativa

26. Modelo de domínio em UML (1)(modelação do estado do sistema) classe atributo agregação multiplicidade generalização associação role name para facilitar mapeamento para VDM++, associação bidireccional é representada por duas associações unidireccionais tipos de dados e valores por omissão definidos em VDM++ Faltam os invariantes ...

27. Modelo de domínio em UML (2)(modelação das operações sobre o estado) Falta a semântica das operações ... Agora com as operações mais importantes (assinaturas omitidas por falta de espaço) Principais transacções e consultas

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

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

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

31. Definição de tipos de dados em VDM++ (1) • Tipos de dados a definir neste caso (*): (*) Normalmente estes tipos de dados estariam definidos numa biblioteca

32. Definição de tipos de dados em VDM++ (2) • Tipos de dados a definir neste caso (cont.)

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

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

35. 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 -- datebooksand apointments, they "belong" to the company -- and are referenced by datebooks (and vice versa) ... só para facilitar testes conjunto de referências para objectos

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

37. 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; ... variável de instância que a operação pode alterar pré-condição implicada por invariante (pode-se efectuar verificação formal) "~" designa valor antigo da variável

38. 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ão dinter {...} – intersecção de elementos deconjunto dunion {...} – união de elementos de conjunto & - tal que

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

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

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

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

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

44. Índice • Introdução • Breve introdução às técnicas de especificação formal • Apresentação de um caso de estudo • Conclusões

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

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