Detalhes sobre o curso http://www.cin.ufpe.br/~if711/

Apresentação em tema: "Detalhes sobre o curso http://www.cin.ufpe.br/~if711/"— Transcrição da apresentação:

0 Alexandre Mota e Augusto Sampaio Centro de Informática UFPE
Programação Concorrente e Distribuída Parte 2 Alexandre Mota e Augusto Sampaio Centro de Informática UFPE

1 Detalhes sobre o curso

2 Um cenário ideal de desenvolvimento …
Different presentations… but the same meaning. Requirements Natural Language Specification language Programming languages and their auxiliary tools Executable code Logic gates Virtual Machines Tool support and training! Specifications Precise semantics required Transformations must preserve behaviour Transformations Tools Rules … Compilers Verifiers Contexto ideal é transformar requisitos em programas que seja semanticamente equivalentes usando ferramentas que sejam capazes de interagir desde o nível mais abstrato até o nível mais concreto de forma que cada passo de transformação seja provado à partir de um modelo semântico que permeia todo o processo, com ajuda do usuário quando necessário (abstração de dados) ou de forma completamente automatizada (refinamentos). O objetivo do slide é mostrar que, assim como MDA, entretanto, mais formalmente, buscamos migrar do modelo abstrato para o concreto através de transformações, mas estas transformações precisam de semântica como chave da corretude. Só para lembrar do slide do contexto definido por Alexandre: Hipótese: Linguagens devem ter semântica formal Limitações: Este cenário sozinho (1) Aplicação de leis usualmente não automática, envolvendo interação com provador de teoremas (2) Necessita de especialista para aplicação das leis (3) Refinamento de dados é o grande obstáculo. MDA é uma alternativa prática. Programs … Hardware … Concrete Syntax Semantics

3 Cenário exemplo Requirements Use cases/CNL Specification CSP
Models (Diagrams) UML-RT Envolver Sidney e Joabe. Fazer exemplo simples onde tudo funcione de forma integrada. Code Java (JCSP)

4 Model checking Requirements Use Cases FDR (Automatic validation)
Specification CSP Models (Diagrams) UML-RT Envolver Sidney e Joabe. Fazer exemplo simples onde tudo funcione de forma integrada. Code Java (JCSP)

5 Visão crítica de model checking
Automatic validation (full analysis) In practice, state explosion Mechanised abstraction strategies is a challenge Does not guarantee correctness of code Use Cases FDR (Automatic validation) CSP UML-RT Java (JCSP)

6 Software (model) checking
Requirements Use Cases Specification CSP Models (Diagrams) UML-RT JPF, Bandera, ... Envolver Sidney e Joabe. Fazer exemplo simples onde tudo funcione de forma integrada. Validation Code Java (JCSP)

7 Alguns exemplos de ferramentas
Java PathFinder (JPF), BANDERA Gera modelo formal a partir do código Analisa bytecode Java (JVM específica) Explora todos os caminhos potenciais de execução em busca de violação de propriedades Propriedades de projeto e implementação Limitações Tamanho do código [~10KLOC ou ~30KLOC para aplicações específicas] Suporte limitado para algumas API Java [java.net, java.io] Nós temos as ferramentas Java PathFinder e o BANDERA que nos permitem analisar certas propriedades diretamente extraídas do código. Isso é possível porque tais ferramenta exercitam o código usando dados aleatórios e heurísticas e observam o que ocorre no estado das variáveis afetadas. Se tais estados satisfazem ou não o critério usado na busca (propriedade), então o usuário fica sabendo. No caso específico do JPF, uma JVM específica foi criada para poder instrumentar o código de forma transparente ao usuário da ferramenta e assim obter o que ocorre com as variáveis. Devido a lidar diretamente com código, os tipos de propriedades que podem ser investigadas não têm ligação direta com os requisitos e sim são mais de projeto e/ou implementação mesmo. Além disso, por lidar diretamente com código e tentar montar uma máquina de estados como em model checking tradicional, não é possível lidar com muitas linhas de código. Em geral 10 e em alguns casos 30. Outro ponto é que não ainda tem total suporte a algumas API’s, como…

8 Propriedades default do JPF
NoDeadlocked NoUncaughtExceptions NoAssertionViolated Exemplo: Propriedades novas podem ser implementadas ====================================================== error #1 gov.nasa.jpf.jvm.NoUncaughtExceptionsProperty java.lang.NoSuchMethodException: calling javax.swing.JPanel.<init>(Ljava/awt/LayoutManager;)V at PBookGUI.<init>(PBookGUI.java:21) at PBookGUI.main(PBookGUI.java:47) Bom, além de usar software model checking, temos ainda outras opções para verificar código… 8

9 AS NOTAÇÕES USADAS NO CURSO …

10 CSP Representação concisa e não ambígua de sistemas críticos e concorrentes Cada operador representa um padrão de interação entre processo P [] Q P ; Q P [|{|a|}|] Q Tradução para modelos de projeto/implementação pode não ser simples Linguagem destino pode não ser tão expressiva A tradução pode facilmente gerar inconsistências Sincronização de dois ou mais processos (multi-sincronização) Comportamentos dinâmicos

11 JCSP Biblioteca para Java que suporta CSP
Programação concorrente mais abstrata que Java Comunicação via passagem de mensagens memória compartilhada Todos os recursos de Java

12 Traduzir CSP para JCSP Aproxima a fase de especificação de uma implementação Valida os requisitos especificados operacionalmente (execução) Modelo de comunicação semelhante das duas linguagens facilita a tradução MAS ... JCSP implementa apenas um subconjunto dos operadores de CSP Não há suporte de análise formal específico para JCSP Mas ferramentas de Software Model Checking como JPF (Java PathFinder) podem ser utilizadas

13 UML-RT Representação gráfica da arquitetura de sistemas interativos e concorrentes Várias visões: estática (diagrama de classes ativas e protocolos) estrutural (diagrama de instâncias) e comportamental (diagrama de estados) Modelo de comunicação inclui modelo síncrono de CSP MAS ... UML-RT não oferece operadores para combinar processos (classes ativas) Difícil de formalizar e provar propriedades quando o modelo é extenso (trabalhos em andamento)

14 Traduzir CSP para UML-RT
Documenta graficamente o modelo formal Aproxima a fase de especificação da fase de projeto Valida os requisitos especificados Permite gerar código através do Rose RealTime para uma API Java semelhante a JCSP Traduzir UML-RT para CSP Permite formalizar parte da notação gráfica (semântica) Permite verificar propriedades usando FDR

15 Projeto da segunda parte
A partir do modelo (refinado) em CSP, implementar em JCSP ou UML-RT ou … Adicionar à implementação requisitos não-funcionais (em particular uma interface) Analisar a implementação e provar ausência de deadlock, por exemplo, usando o JPF Resultado: programa executável, analisado e com interface gráfica