A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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.

Apresentações semelhantes


Apresentação em tema: "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."— Transcrição da apresentação:

1 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

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 X T UML - 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 X T UML - 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 /Modelo formal Implementação síntese análise especificação/ modelação

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++) class Stack 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; end Stack

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: inv len 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; 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

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

18 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) push 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

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) 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 equipamentos 3. 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 pessoa 6. 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).

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

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

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

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

27 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

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 (*): TipoDescrição StringTcadeia de um ou mais caracteres Datedata 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 Timeinstante 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 Durationuma duração em minutos (*) 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.) TipoDescrição UserTimeIntervalintervalo entre dois instantes de tempo, fechado à esquerda e aberto à direita, representado por um par de valores do tipo UserTime TimeRegionregiã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 ResourceTypetipo enumerado que admite os valores, ou VisibilityTypetipo enumerado que admite os valores ou

33 Exemplo de definição de tipos de dados em VDM++ types public UserDate :: year : nat1 month: nat1 day : nat1 inv d == d.month = 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 -- 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

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;... "~" 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)

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

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 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 - sobre VDM++ e VDMTools – sobre UML executável – sobre UML, OCL, etc. – mais detalhes sobre o caso de estudo apresentado


Carregar ppt "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."

Apresentações semelhantes


Anúncios Google