F
ACULDADE DE
E
NGENHARIA DA
U
NIVERSIDADE DO
P
ORTO
Desenvolvimento e integração de editores
gráficos de elevado impacto visual
João Pedro Rocha Brito Martinho Antunes
Mestrado Integrado em Engenharia Informática e Computação
Orientador: António José Pessoa de Magalhães (Prof)
Desenvolvimento e integração de editores gráficos de
elevado impacto visual
João Pedro Rocha Brito Martinho Antunes
Mestrado Integrado em Engenharia Informática e Computação
Aprovado em provas públicas pelo júri:
Presidente: Hugo José Sereno Lopes Ferreira Doutor
Vogal Externo: José Gabriel de Figueiredo Coutinho Doutor Orientador: António José Pessoa Magalhães Doutor
Resumo
Actualmente os sistemas de controlo requerem uma grande estruturação, devido à sua elevada complexidade de programação. Métodos e ferramentas têm vindo a ser desen-volvidos, de modo a que os processos de especificação, estruturação e programação de controladores lógicos sejam mais rápido, fácil, flexível e elegante.
Este projecto visa desenvolver um editor gráfico que permita a criação de algoritmos gráficos específicos, GRAFCET, de uma forma intuitiva, rápida e agradável para utiliza-dor. Pretende-se utilizar no desenvolvimento do editor gráfico tecnologias de vanguarda, no que diz respeito à criação de interfaces gráficas orientadas ao utilizador. É desejado obter um produto que consiga competir com os restantes já existentes, pelos aspectos funcionais e gráficos.
A primeira parte do relatório começa por um estudo da norma GRAFCET e sensibi-lização para o tipo de diagrama que é tratado. Em seguida é feito um estudo sobre as aplicações existentes, analisando cuidadosamente os pontos positivos e negativos e con-ceitos adoptados pelas empresas que já desenvolvem software na área respectiva. Numa fase posterior são explicadas as tecnologias escolhidas bem como o motivo da sua es-colha. Em seguida é explicado de uma forma detalhada como decorreu o processo de implementação, onde são descritos os problemas e soluções encontradas. Como último ponto são apresentadas as conclusões e possíveis melhorias futuras identificadas.
Agradecimentos
Gostaria de começar por agradecer a todos os que contribuíram com os seus conheci-mentos, companheirismos e motivação, para a realização deste projecto, bem como para formação do seu autor.
Por conseguinte, deixo os meus sinceros agradecimentos:
À empresa Real Games, em particular ao Engo Bruno Vigário, pelo apoio e
compre-ensão demonstrados, bem como o auxílio e constante acompanhamento, pelos momentos vividos e pelo conhecimento transmitido, sem o qual não seria possível realizar esta dis-sertação.
Ao Professor António Pessoa de Magalhães, pela sabedoria e auxílio dispensados, sem descurar a compreensão demonstrada.
Em especial queria agradecer à minha família, por todo o apoio e motivação, assim como o carinho demonstrado.
A todos os colegas que me ajudaram e ultrapassaram os obstáculos encontrados, e nunca me deixaram de apoiar.
Aos meus amigos pelos momentos que me providenciaram, sem os quais não seria o mesmo.
A todos anteriormente referidos, e a todos de que algum modo, contribuíram para elaboração da presente dissertação, o meu mais sincero e sentido, Obrigado.
Conteúdo
1 Introdução 1
1.1 Contexto . . . 1
1.2 Motivação e Objectivos . . . 2
2 Revisão Bibliográfica 5 2.1 Controlo de sistemas de eventos discretos . . . 5
2.2 GRAFCET . . . 5
2.2.1 Noções básicas de GRAFCET . . . 5
2.2.2 Etapas . . . 6
2.2.3 Acções . . . 6
2.2.4 Transições . . . 9
2.2.5 Divergência e Convergência em “OU” . . . 10
2.2.6 Divergência e Convergência em “E” . . . 11
3 Aplicações existentes 15 3.1 SFCEDIT . . . 15
3.1.1 Aspectos positivos identificados . . . 16
3.1.2 Aspectos negativos identificados . . . 16
3.2 AutomGen . . . 18
3.2.1 Aspectos positivos identificados . . . 19
3.2.2 Aspectos negativos identificados . . . 19
3.3 Outros programas . . . 21
4 Tecnologias 23 4.1 WPF . . . 23
4.2 GoXAM . . . 26
4.2.1 Modelos de diagrama e Data Binding . . . 27
4.2.2 Data Templatespara os nós . . . 28
4.2.3 Data Templatespara as ligações . . . 28
4.2.4 Ligações com etiquetas . . . 29
4.2.5 Ligações com pontos de conexão . . . 30
4.2.6 Funcionalidades . . . 30
4.2.7 Ferramentas . . . 31
5 Implementação 33 5.1 Protótipos . . . 33
CONTEÚDO
5.1.2 Ligação entre elementos . . . 35
5.1.3 Portas, ligações por arraste e respectivas restrições . . . 36
5.1.4 Grelha padrão . . . 37
5.1.5 Forma de desenhar do diagrama . . . 40
5.2 Detalhes de implementação . . . 42
5.2.1 Regras de desenho . . . 42
5.2.2 Expansões possíveis e portas . . . 42
5.2.3 Restrições de movimentos . . . 43
5.2.4 Restrições de ligações . . . 44
5.2.5 Arquitectura . . . 45
5.3 Editor de GRAFCET . . . 51
6 Conclusões e trabalho futuro 55 6.1 Objectivos e satisfação . . . 56
6.2 Futuras expansões . . . 57
Lista de Figuras
2.1 Exemplo de um grafcet representativo de um ciclo automático . . . 6
2.2 Forma representativa de uma etapa inicial . . . 7
2.3 Exemplo de uma forma representativa de múltiplas acções associadas a uma etapa . . . 7
2.4 Representação gráfica de uma acção de activação . . . 7
2.5 Representação gráfica de uma acção de desactivação . . . 8
2.6 Representação gráfica de uma acção de condicional . . . 8
2.7 Representação gráfica de uma acção de evento . . . 9
2.8 Representação gráfica de uma acção de compensação . . . 9
2.9 Representação gráfica de uma transição com a receptividade associada . . 10
2.10 Representação gráfica de uma divergência em "OU" . . . 11
2.11 Representação gráfica de uma convergência em “OU” . . . 11
2.12 Representação gráfica de uma divergência em "E" . . . 12
2.13 Representação gráfica de uma convergência em "E" . . . 12
3.1 Interface do SFCEdit após o botão direito do rato ser pressionado . . . 17
3.2 Interface do AutomGen8 a correr em paralelo com um sistema virtual . . 21
4.1 Implementação declarativa de um botão utilizando o XAML e o respec-tivo resultado . . . 25
4.2 Implementação do comportamento de um botão em C# e respectivo re-sultado . . . 26
4.3 Exemplo da implementação de um template de nó e o respectivo resultado 29 4.4 Exemplo da implementação de um data template de ligações com cantos redondos e o respectivo resultado . . . 29
4.5 Exemplo de uma ligação com duas etiquetas . . . 30
4.6 Exemplo de um nó com três portas de conexão . . . 30
5.1 Esquema representativo da criação de um elemento . . . 34
5.2 Resultado do protótipo referente à criação de um elemento . . . 35
5.3 Esquema representativo da expansão e ligação entre dois elementos . . . 36
5.4 Resultado do protótipo referente à expansão e ligação de elementos . . . . 36
5.5 Pseudocódigo da aplicação de uma restrição . . . 37
5.6 Esquema representativo da definição de portas, ligações por arraste e res-pectivas restricções . . . 38
5.7 Resultado do protótipo referente à criação de portas, ligações por arraste e respectivas restricções . . . 38
LISTA DE FIGURAS
5.8 Esquema representativo da criação e definição dos elementos da grelha
padrão . . . 39
5.9 Transição com a área de ocupação visível . . . 40
5.10 Método de expansão de uma acção a partir de uma etapa inicial . . . 41
5.11 Exemplo de erros de movimento . . . 44
5.12 Representação dos três tipos de ligações possíveis . . . 48
5.13 Esquema representativo da restrição M1 . . . 49
5.14 Exemplo do código da detecção de colisões . . . 50
5.15 Exemplo da restrição M2 aplicada . . . 51
5.16 Esquema representativo da implementação da restrição M2 . . . 52
5.17 Esquema representativo da restrição M3 . . . 53
5.18 Esquema representativo da restrição M4 . . . 53
5.19 Grafcet criado pelo editor de desenvolvido . . . 54
Lista de Tabelas
Abreviaturas e Símbolos
EMF Enhanced MetaFile
FEUP Faculdade de Engenharia da Universidade do Porto GRAFCET Graphe Fonctionnel de Commande, Étapes Transitions GUI Graphical user interface
PLC Programmable logic controller SFC Sequential Function Charts WMF Windows Metafile
WPF Windows Presentation Foundation XAML Extended Application Markup Language XML Extended Markup Language
Capítulo 1
Introdução
Nesta secção é apresentado uma breve descrição do contexto do projecto e a sua fina-lidade. Abrange ainda a motivação e os objectivos do projecto que se pretende.
1.1
Contexto
Na área industrial cada vez mais observamos as máquinas ocuparem o trabalho do homem e o tipo de acções realizadas pelas máquinas tende a ser também mais complexo. Hoje em dia encontramos carros a serem praticamente construídos a partir de máquinas, que foram programadas previamente pelo homem e tal programação torna-se cada vez mais complexa.
No desenvolvimento de software uma simples sucessão de operações pode ser facil-mente codificada. No entanto quando se for pretendido programar um sistema de controlo orientado a eventos, tudo deve estar estritamente estruturado e coordenado de forma a que não exista um bloqueio de operações inesperado ou declarações condicionais entrelaça-das. À medida que aumenta o número de variáveis, restrições de tempo, acções, con-dições, entre outras, a complexidade da programação dos sistemas obviamente também aumenta e consequentemente a possível ocorrência de erros. Declarações condicionais ra-pidamente tornam-se mais complexas e incompreensíveis, principalmente quando se trata de condições simultâneas. A utilização de um diagrama de máquina de estados, pode-ria ser uma solução para este tipo de problema. Contudo quando pretendemos descrever um mecanismo de sincronização muito complexo, a sua especificação torna-se demasiado complexa e ilegível. Consequentemente a tarefa de compreender o comportamento global da aplicação e a identificação de erros revela-se complicada. Por este motivo foi criado um modelo gráfico de especificação, GRAFCET, que permite especificar graficamente o com-portamento de processos sequenciais. Este modelo oferece uma estruturação e descrição do comportamento, sobre como e quando realizar as acções de controlo. Especificações completas das operações que podem ser complexas e simultâneas, podem ser definidas de
Introdução
forma flexível, confiável e elegante [eBT99]. Actualmente, têm vindo a ser desenvolvidas ferramentas que permitem a criação de tais modelos GRAFCET, de forma a melhorar e acelerar o processo de especificação das aplicações de controlo industrial. Nos últimos anos tem existido uma grande evolução, na forma como estas ferramentas permitem criar os grafcets e nas funcionalidades que apresentam. Apesar disso, existe ainda um grande descontentamento em relação à qualidade gráfica e funcional destas aplicações, dado que existe ainda um longo cami0nho a percorrer nestes aspectos, comparativamente com ou-tras ferramentas que permitem a construção de outro tipo de esquemas gráficos.
1.2
Motivação e Objectivos
O uso do modelo GRAFCET começa a ter um papel muito importante para as empre-sas, que pretendem programar as suas aplicações industriais de forma estruturada, flexível e extensível.
O objectivo principal deste projecto visa a criação de um editor gráfico, que permita criar grafcets, de uma forma simples, rápida, intuitiva e que dê prazer ao utilizador usar a aplicação. Por esse motivo a qualidade gráfica e funcional são aspectos fulcrais no desenvolvimento da aplicação. Todos os elementos gráficos criados devem obedecer à norma de GRAFCETs IEC 60848, de forma a respeitar a forma como é construído o GRAFCET e não permitindo ambiguidade. O programa deverá permitir construção dos elementos básicos do grafcet tais como: etapas, transições, convergências, divergências, acções. Funcionalidades que permitam facilitar edição de diagramas como redo, undo, zoom, copiar e cortar elementos, que são usuais na edição de qualquer tipo de diagramas, deverão ser permitidas ao utilizador.
Pretende-se ainda automatizar a tradução de grafcets em código de programação de forma a acelerar o desenvolvimento de aplicações de controlo industrial. Parte deste pro-blema encontra-se resolvido, por outro aluno da FEUP, onde este desenvolveu uma aplica-ção que permite a geraaplica-ção automática do código de programaaplica-ção, a partir de um ficheiro em formato XML, com o grafcet devidamente especificado [Gom03]. Cabe então nesta dissertação, colmatar o que está em falta, um programa que permita a criação do grafcet e a sua consequente exportação para o formato predefinido.
Controlar o comportamento das aplicações industriais, em tempo real, através do uso de grafcets, em vez de ser efectuado pela leitura do código, é um dos objectivos preten-didos. Dado que o GRAFCET específica graficamente o comportamento e a estrutura de um controlador lógico programável de uma forma simples e legível, seria interessante e faria todo o sentido, ser possível identificar os erros a partir da estruturação gráfica. Ao invés do que é praticado normalmente, onde o controlo de erros lógicos passa pela aná-lise do códigos extensos e de complexos. Para além da complexidade envolvida é ainda
Introdução
necessário o conhecimento da linguagem de programação, para que seja possivel identifi-car os erros lógicos. Uma vez que a linguagem GRAFCET é standard e independente da linguagem de programação utilizada, esta funcionalidade permitiria facilitar e melhorar a eficiência no que diz respeito ao controlo de erros e na reprogramação lógica dos PLC’s. Para garantir esta funcionalidade, será necessário uma comunicação entre o editor e uma aplicação que simula ambientes de aplicações industriais programáveis. A aplicação que permite simular estes ambientes, foi desenvolvida pela empresa Real Games e tem como objectivo o ensino de sistemas controlados por controladores lógicos.
Estrutura da Dissertação
Neste capítulo foi elaborada uma contextualização do problema para um melhor en-quadramento do projecto. É descrito o projecto, bem como a especificação dos objectivos e motivação do trabalho proposto. Para além da introdução, esta dissertação contém mais cinco capítulos.
No segundo capítulo é feita uma abordagem ligeira à especificação GRAFCET de forma a compreender os conceitos inerentes.
No terceiro capítulo são descritas as aplicações existentes estudadas relacionadas com o produto pretendido. Foi elaborada uma pequena análise sobre os aspectos positivos e negativos identificados, com a intenção de compreender o estado actual das ferramentas.
O quarto capítulo é referente às tecnologias utilizadas. Neste capítulo são descritas as tecnologias e os motivos pelos quais foram escolhidas.
No quinto capítulo é descrito como decorreu a fase de implementação do projecto. Inicialmente é relatado como decorreu a fase de protótipos, descrevendo ainda as deci-sões tomadas e aspectos importantes identificados. Numa fase posterior é salientada a arquitectura definida e como foram implementados os aspectos mais importantes.
O último capítulo tem como objectivo demonstrar as conclusões retiradas sobre pro-jecto realizado. São descritos os pressupostos que foram alcançados, sendo também men-cionado as possíveis melhorias e trabalho futuro do projecto desenvolvido.
Capítulo 2
Revisão Bibliográfica
Neste capítulo pretende-se conhecer um pouco melhor a utilização do GRAFCET, na modelação gráfica do comportamento de controlos para sistemas de eventos discretos.
2.1
Controlo de sistemas de eventos discretos
Devido à necessidade crescente de projectar sistemas sequenciais cada vez mais com-plexos e sofisticados, torna-se necessário adoptar métodos standard de especificação do comportamento, que sejam flexíveis, elegantes e não dependam da linguagem de progra-mação dos controladores lógicos. Existem diversas ferramentas que permitem a modela-ção de sistemas de eventos discretos, sendo o GRAFCET um deles.
2.2
GRAFCET
O GRAFCET - Graph Fonctionel de Commande Etape/Transition teve a sua origem em França, em 1977, como uma metodologia específica para a modelação de sistemas sequenciais. Devido à sua elevada evolução e por ter sido uma metologia adoptada mun-dialmente, foi desenvolvida uma normalização pela Comissão Electrónica Internacional – a norma IEC 848 do ano de 1988 – e consequente mudança de nome para Sequential Function Chart– SFC [Gom03]. Na figura 2.1encontra-se um exemplo de um GRAF-CET.
2.2.1 Noções básicas de GRAFCET
O GRAFCET é baseado em alguns conceitos chave: “etapas”, “acções”, “transições” e “transições condicionais”. Um grafcet é divido em etapas, que por sua vez são separa-das por transições, de forma alternada. Cada etapa tem um conjunto de acções que são realizadas se a etapa estiver activa. Durante a execução de um grafcet podem existir várias
Revisão Bibliográfica
Figura 2.1: Exemplo de um grafcet representativo de um ciclo automático
etapas a correr em simultâneo. Cada transição tem uma condição lógica associada, se a condição verificar-se, a transição é disparada.
2.2.2 Etapas
Uma etapa representa um estado ou parte de um estado e é representado por um qua-drado numerado no seu interior. A numeração deve ser crescente e não podem existir mais que uma etapa com o mesmo número. Uma variável binária Xi é relacionada com cada etapa (onde i é o número da etapa). Se Xi = 1 a etapa diz-se activa, caso contrário a etapa encontra-se num estado inactivo. Existe ainda a possibilidade de identificar etapas iniciais, sendo representadas por um quadrado duplo. Um Grafcet tem pelo menos uma etapa inicial definida [Gom03]. Na figura 2.2é possível observar uma etapa inicial.
2.2.3 Acções
Quando uma etapa está activa, são realizadas as acções associadas, caso contrário as acções são ignoradas. Acções são outputs, ou saídas, que enviam comandos para o
Revisão Bibliográfica
Figura 2.2: Forma representativa de uma etapa inicial
processo que se pretende controlar. As acções são denotadas por rectângulos colocados do lado direito da etapa a que estão associadas. A ligação entre o rectângulo etapa e acção signifca que a acção está associada à etapa. Diversas etapas podem ser activadas ao mesmo tempo, de forma a ocorrerem acções simultâneas.
Figura 2.3: Exemplo de uma forma representativa de múltiplas acções associadas a uma etapa
2.2.3.1 Acção na activação
Figura 2.4: Representação gráfica de uma acção de activação
Este tipo de acção contem uma expressão que é activada sempre que a etapa a que se encontra ligada também o for. A acção só ocorre apenas uma vez enquanto a etapa estiver activa e para voltar a ocorrer terá de ser desactivada primeiro e mais tarde voltar ao estado activo. Como se pode ver na figura 2.4, distingue-se este tipo de acção pela seta ascendente no canto superior direito do rectângulo [Com00].
Revisão Bibliográfica
2.2.3.2 Acção na desactivação
Figura 2.5: Representação gráfica de uma acção de desactivação
Uma acção de desactivação, tal como o nome sugere, é o contrário duma acção de activação. Ocorre apenas uma vez e executa a expressão quando a etapa a que está as-sociada encontra-se num estado activo prévio, e posteriormente transita para um estado inactivo. Distingue-se este tipo de acção por conter uma seta descendente no canto in-ferior esquerdo do rectângulo. É possível verificar a representação gráfica deste tipo de acção na figura 2.5.
2.2.3.3 Acção condicional
Figura 2.6: Representação gráfica de uma acção de condicional
Uma acção poderá ter associada uma preposição lógica que influência de forma con-dicional o seu comportamento. Na imagem 2.6 pode-se observar uma linha vertical em cima do rectângulo e um asterisco do lado direito que representa o campo da expressão. O asterísco deverá ser substituído por uma expressão em formato de texto. De acordo com o conteúdo da condição é possível limitar o tempo de actuação da acção ou atrasar o seu início.
2.2.3.4 Acção no evento
A representação tradicional da acção por um rectângulo é concluída com um símbolo a cima, indicando que a acção é condicionada pela ocorrência de determinados eventos especificados pela expressão. A expressão é descrita em formato de texto no lugar do asterisco [Com00].
Revisão Bibliográfica
Figura 2.7: Representação gráfica de uma acção de evento 2.2.3.5 Acção na compensação
Imagem de acção de compensação
Figura 2.8: Representação gráfica de uma acção de compensação
Existem acções que por vezes podem estar ligadas a transições. Nesse caso estamos perante uma acção na compensação. Graficamente o que difere em relação aos outros tipos de acções é sua linha de ligação. A linha deverá ser oblíqua, partindo do centro da transição e liga-se ao canto superior esquerdo da acção, como está representado na fi-gura ˜reffig:accoesCompensacao. Qualquer um dos tipos de acções apresentados anterior-mente podem estar associados a uma transição, tornando-se assim acções de compensação [Com00].
2.2.4 Transições
As transições alternam com as etapas e definem a possível evolução do grafcet. Cada transição tem uma condição lógica associada denominada por receptividade. Se a re-ceptividade verificar-se verdadeira a transição é transposta, alterando o estado da etapa ascendente para inactiva e a etapa descendente passa a ter um estado activo. Etapas e transições estão ligadas por arcos orientados representados por linhas rectas. Setas podem
Revisão Bibliográfica
ser colocadas por cima das linhas de forma definir a orientação da ligação. Na ausência destas, uma ligação é interpretada com uma orientação de cima para baixo. As transições são representadas por um traço horizontal sobre a linha que liga as etapas. Para que uma transição seja transposta deverá obedecer a duas condições [eBT99]:
1. A transição precisa de estar activa: a etapa imediatamente anterior tem de estar activa.
2. Tem de ser possível disparar a transição: a condição associada tem de ser verdadeira [Gom03].
É possível observar na figura 2.9uma transição com uma receptividade associada e o respectivo número de identificação à esquerda. O número de identificação pode ser visível ou não de acordo com a intenção da pessoa.
Figura 2.9: Representação gráfica de uma transição com a receptividade associada
2.2.5 Divergência e Convergência em “OU” Divergência em “OU”
Neste tipo de ligação uma etapa possuiu mais do que uma transição de saída. Uma divergência “OU” é representada por um traço horizontal com uma única etapa de entrada e várias transições de saída.
A transposição de uma dessas transições desactiva a etapa em causa activando a etapa descendente.
Na figura 2.10pode ser evidenciado um exemplo de uma divergência em "OU".
Convergência em “OU”
Neste tipo de ligação uma etapa possui duas ou mais transições de entrada. Uma con-vergência “OU” é representada por um traço horizontal com várias transições de entrada associada e apenas a uma única etapa de saída.
A transposição de uma ou mais dessas transições activa a etapa de saída e desactiva as etapas de entrada [eBT99].
Na figura 2.11encontra-se um exemplo de uma convergência em "OU"e a sua possível representação gráfica.
Revisão Bibliográfica
Figura 2.10: Representação gráfica de uma divergência em "OU"
Figura 2.11: Representação gráfica de uma convergência em “OU” 2.2.6 Divergência e Convergência em “E”
Divergência em “E”
Uma divergência em “E” é representada por um traço duplo horizontal, como é de-monstrado na figura 2.12. Possui apenas uma única transição de entrada e várias etapas de saída.
Após a transposição dessa transição, a etapa de entrada é desactivada e são posterior-mente activadas todas as etapas de saída.
Convergência em "E"
Uma convergência em “E” é representada por um duplo traço horizontal com várias etapas de entrada e uma única transição de saída.
Revisão Bibliográfica
Figura 2.12: Representação gráfica de uma divergência em "E"
Após a transposição dessa transição são desactivadas todas as etapas de entrada e é activada a etapa de saída [eBT99]. Pode ser observado na figura 2.13 um exemplo da representação gráfica de uma convergência em "E".
Figura 2.13: Representação gráfica de uma convergência em "E"
Existem funcionalidades adicionais na norma de GRAFCET como a definição de hie-rarquia de grafcets e macroetapas.
Com a hierarquização dos grafcets é possível que um deles seja definido como hi-erarquicamente superior podendo condicionar a evolução dos grafcets hihi-erarquicamente abaixo. Um grafcet superior pode influenciar o comportamento dos seus descendentes utilizando macroacções. Este conceito foi pouco explorado dado que não foi identificado como relevante para o desenvolvimento do projecto.
O conceito da macroetapa é usado de forma a encapsular alguma da complexidade do grafcet, tornando-o menos extenso e simples de ler. Uma macroetapa é simplesmente um conjunto de etapas e transições representadas numa só etapa.
Revisão Bibliográfica
Uma vez que se pretende na dissertação apenas explorar os conceitos básicos do GRAFCET, não serão descritos em grande detalhe qual a sua representação gráfica.
Capítulo 3
Aplicações existentes
Actualmente existem aplicações comerciais que permitem a criação de grafcets, ex-portação e interacção com simuladores 2D e 3D em tempo real. Apesar de nos últimos anos estas aplicações terem sofrido melhorias significativas em relação à interacção com utilizador e às funcionalidades apresentadas, ainda existem pormenores que podem ser explorados e melhorados. Pretende-se nesta secção fazer um sumário das ferramentas mais utilizadas nesta área, salientando os seus pontos fortes e fracos.
3.1
SFCEDIT
O SFCEDIT é uma aplicação comercial que permite a criação rápida de grafcets. É um software utilizado essencialmente para a documentação de autómatos sequenciais. A sigla SFC significa Sequential Function Chart. Este é o nome pelo qual os diagramas grafcets também são conhecidos. O software têm como conceito a criação de grafcets com estruturação automática, respeitando a norma de GRAFCETs IEC 60848. Oferece ainda algumas funcionalidades automáticas na criação dos esquemas que permitem acelerar o processo de desenho dos grafcets [St1]. Em seguida são apresentadas as principais funcionalidades que software permite:
• Criar, editar e gravar grafcets;
• Exportar diagramas para ficheiros com diversos formatos (WMF, EMF e XML); • Imprimir grafcets.
Após a utilização do SFCEDIT foram identificados alguns aspectos positivos e nega-tivos, em relação à interface e na forma como é realizada a interacção com o utilizador. Estes pontos serão tidos em consideração no desenvolvimento do editor que é pretendido.
Aplicações existentes
3.1.1 Aspectos positivos identificados 3.1.1.1 Redundância
É possível realizar a mesma acção de diversas formas. Esta variedade permite que o utilizar não seja obrigado a procurar pela única forma de praticar a acção desejada. Uma vez que é possível realizar uma acção de múltiplas formas, fica ao critério do utilizador qual é que deve usar. A escolha pode ser influenciada por diversos factores: por ser o único método encontrado, por na presente situação ser a opção mais adequada ou simplesmente porque o utilizador se sente melhor a usar aquele tipo de método. Cada pessoa tem a sua preferência e deve ser dado ao utilizador o poder de escolha. Os utilizadores apreciam sentir o controlo e o poder sobre a aplicação.
3.1.1.2 Atalhos
A existência de atalhos permite aos utilizadores mais experientes a criação de grafcets mais rápidos. Deve sempre existir funcionalidades desenhadas tanto para utilizadores inexperientes como experientes.
3.1.1.3 Acções automáticas
Indexação automática ou criação de transições após ser criada uma etapa são alguns do tipo de acções automáticas oferecidas pelo editor. Este tipo de acções permite a criação de grafcets mais rápidos e oferece uma motivação ao utilizador para o uso deste tipo de editores.
3.1.2 Aspectos negativos identificados 3.1.2.1 Visibilidade
Existe alguma falta de consideração em relação à visibilidade dos ícones. Ícones que são utilizados frequentemente deviam ser maiores e mais acessíveis. Alguns ícones são pouco intuitivos, mesmo para pessoas com experiência na elaboração de grafcets.
3.1.2.2 Indicação
Algumas acções são complicadas de perceber como funcionam, pois não são intuitivas e a interface não indica exactamente o que o utilizador tem de fazer em dada situação. Um exemplo em que isto acontece é quando é pretendido utilizar uma divergência, onde não fica perceptível para que lado irá propagar o grafcet. Ao mesmo tempo não se percebe intuitivamente como funciona e para que serve a âncora apresentada.
Aplicações existentes
3.1.2.3 Liberdade
O facto de não ser possível mover o grafcet, provoca um desconforto no uso da fer-ramenta. Isto retira poder de controlo sobre a criação de diagramas, transmitindo auto-maticamente uma sensação de desmotivação ao utilizador. A funcionalidade de o grafcet permanecer estático, só facilita a implementação do programa, dificultando assim a acção do utilizador. Este é um caso óbvio em que a forma de implementação foi sobreposta às necessidades do utilizador.
Na figura 3.1 pode ser observado a interface gráfica do programa SFCEdit. Na parte debaixo do SFCEdit encontram-se os botões que permitem criar os elementos de grafcet. A parte de cima da ferramenta é dedicada às funcionalidades de edição usuais como o redo,undo,zoom, cortar, copiar, entre outras. O contexmenu, menu que é activado quando é pressionado o lado direito do rato, apresenta as acções que são permitidas usar sobre o elemento selecionado.
Figura 3.1: Interface do SFCEdit após o botão direito do rato ser pressionado
Em resumo o SFCedit preocupa-se em oferecer ao utilizador um método de criação de grafcets rápido, sem erros e bem formatado. A rapidez é proporcionada pelas acções automáticas, teclas de atalho e pelo facto de ao criar os elementos, estes já se encontrarem
Aplicações existentes
posicionados correctamente. O controlo de erros resulta pelo facto do programa estar altamente restringido, dando pouca liberdade ao utilizador. A forma de expansão dos nós é restringida de acordo com a norma, aliada ao posicionamento automático dos novos elementos expandidos e ao facto de não ser possível mexer os nós, permite criar um grafcet sem erros. Como contrapartida o utilizador tem de construir o grafcet de cima a baixo sem poder destruir ou separar partes interiores do grafcet. Existe um problema sério de liberdade dado que existem demasiadas restrições, com a intenção do utilizador não cometer erros. Por vezes isto provoca um descontentamento ao utilizador uma vez que não lhe é permitido praticar determinadas acções, mesmo que estas estejam de acordo com a norma. Ao permitir um número reduzido de acções ao utilizador torna-se mais simples o controlo de erros, dado que imprevisibilidade do tipo de acções realizadas pelo mesmo diminui. Conclui-se assim neste caso que as restrições excessivas só favorecem a implementação do editor, pois torna-se mais simples desta forma desenvolver o editor. Este é um caso em que o interesse de desenvolver uma interface orientada ao utilizador é sobreposto, sendo tomada uma medida para facilitar a implementação da interface.
3.2
AutomGen
O AutomGen é uma ferramenta muito poderosa na geração de autómatos e em simula-ção de sistemas industriais. O software é de origem francesa e continua a ser desenvolvido pela IRAI. Esta aplicação é como uma oficina para simulação de automação, processos SCADA com ambientes em 2D e 3D. Inclui sistemas pneumáticos, hidráulicos e eléctri-cos [Cor11a]. Em seguida encontra-se uma pequena lista das principais funcionalidades e capacidades que o software oferece:
• Programação de PLC;
• Criação e edição de grafcets;
• Supervisão Controlo e Aquisição de Dados (SCADA);
• Simulação de processos (2D e 3D);
• Simulações pneumáticas, hidráulicas e eléctricas;
• Importação de ficheiros 3D ( Solidworks , 3DStudio, etc„);
Aplicações existentes
3.2.1 Aspectos positivos identificados 3.2.1.1 Visibilidade
Os componentes relevantes estão bem à vista, pois os ícones possuem um tamanho considerável e estão acessíveis. O tamanho até pode ser considerado exagerado, dado que por vezes perturba a visibilidade do resto da interface.
3.2.1.2 Consistência
Existe uma consistência clara entre a criação dos diagramas grafcet dentro da interface com a criação de grafcet em papel. Esta consistência entre o mundo real e o virtual facilita a aprendizagem, dado que permite uma transferência de know-how.
3.2.1.3 Controlo
É dado um grande poder de controlo ao utilizador, pois este pode seleccionar e mover o grafet construindo o grafcet da forma que pretende. Para além disso é dada a oportunidade de criar a sua própria barra de tarefas. Isto tudo transmite ao utilizador uma sensação de poder fazer o que deseja e como deseja.
3.2.1.4 Feedback
Quando corremos o grafcet existe um retorno por parte da interface em relação aos erros que cometemos. Diferentes cores são utilizadas de forma a identificarmos os erros de forma mais clara.
3.2.2 Aspectos negativos identificados 3.2.2.1 Excesso de liberdade
A liberdade oferecida ao utilizador deve ser ponderada. Certas funcionalidades não devem ser permissíveis pela interface. Nesta interface é possível fechar todos botões, janelas, menus, ficando assim com um ambiente vazio. Para restaurar o estado inicial é necessário reiniciar o programa.
3.2.2.2 Redundância
Determinadas acções só são possíveis de realizar de uma única forma. Isto obriga ao utilizador descobrir exactamente como é que o programa “exige” funcionar. Na ver-dade deveria acontecer exactamente o oposto, o programa é que deve perceber como o utilizador funciona, dando uma variedade de opções possíveis para ser realizada a acção pretendida.
Aplicações existentes
3.2.2.3 Acções automáticas
Existem acções que podem ser executadas pelo sistema que devem ser automáticas, re-tirando assim parte do trabalho ao utilizador. O tempo despendido no processo de criação de grafcets pode diminuir caso as acções automáticas forem usadas de forma correcta. A indexação automática das etapas seria um exemplo possível de aplicação de acções automáticas.
3.2.2.4 Restrições
Acções que não façam sentido devem ser bloqueadas pela interface, diminuindo assim a possibilidade do utilizador cometer erros. O facto de podermos criar uma transição sem a ligar a uma etapa, não faz sentido. Este é um tipo de acção que não deveria ser permissível por parte da interface.
3.2.2.5 Erros
São visíveis perante o utilizador alguns erros e bugs. Os principais erros identificados dizem respeito à tradução errada de idiomas. Isto pode servir como factor de descredibi-lização da integridade e robustez do software desenvolvido.
Na figura 3.2 pode ser observado a interface gráfica do programa Automgen8. O programa está num estado de simulação. No canto inferior direito é possível observar um ambiente programado a ser simulado.É possível ao mesmo tempo seguir a específicação GRAFCET do controlador lógico e o seu comportamento em tempo real.
Em conclusão, o Autogem utiliza uma elevada redundância e liberdade na criação do grafcet, tornando a sua construção intuitiva mas com uma enorme possibilidade de ocorrência de erros praticados pelo utilizador. A intuitividade existe pelo facto do drag-and-dropser normalmente usado na criação de diagramas, que não possuam grandes res-trições. Não existindo restrições sobre a colocação dos elementos, fica como responsabi-lidade do utilizador sobre como construir correctamente o diagrama, semelhante à cons-trução de grafcets num papel. Isto possibilita uma enorme ocorrência de erros durante a fase de construção do grafcet, que só serão determinados após correr o programa. Para além disso o drag-and-drop obriga o posicionamento manual dos elementos. A falta de acções automáticas traduz um aumento do número de acções praticadas pelo utilizador, que poderá influenciar o tempo de construção de um grafcet.
Aplicações existentes
Figura 3.2: Interface do AutomGen8 a correr em paralelo com um sistema virtual
3.3
Outros programas
Existem diversos programas que permitem a construção de diagramas grafcets apesar desta não ser a sua principal funcionalidade. Foram então estudados programas vos de modo a identificar diferentes abordagens de desenho e identificar formas alternati-vas de representação de dados num diagrama. Os programas estudados foram: CodeSys, Zelio Software, Dia Drawing, PL7 Micro 4.4, KW Multiprog, Dia Drawing.
Programas como o PL7 Micro separam as partes estruturais e lógicas do grafcet. Tendo uma secção para visualizar apenas o desenho do grafcet e outra parte dedicada às expressões lógicas das acções e receptividades. Uma forma de desenho de diagramas utilizada em alguns dos programas referidos, é a expansão automática dos ramos, o que diminui a possibilidade de o utilizador cometer erros. Isto acontece pelo simples facto das acções automáticas estarem sempre de acordo com a norma de grafcet. O inconveni-ente desta abordagem é que os programas que a usam, não permitem o utilizador mover os elementos, retirando assim muita liberdade ao utilizador na construção dos diagramas. Esta falta de liberdade reflecte dificuldades na criação do grafcet em diversas situações. Entre elas existem problemas na edição dos elementos, restrições impostas pelos progra-mas sobre os elementos que podem ser apagados, por vezes não são lógicos e só existem de forma a facilitar a implementação do programa.
Aplicações existentes
A partir deste estudo não foi possível retirar grandes ideias alternativas, dado que todos os diagramas baseiam-se nos mesmos conceitos. Serviu apenas para um aumento de sensibilização de como construir um diagrama e os seus principais problemas. Como colisão de objectos quando estes usam expansão automática, conectores de ligação entre elementos, entre outros.
Capítulo 4
Tecnologias
O método de desenvolvimento de interfaces tem vindo a evoluir ao longo dos anos e têm surgindo no mercado tecnologias e métodos que revolucionaram a forma de desenvol-ver aplicações GUI. Sendo que esta dissertação incide sobre o tema de desenvolvimento de aplicações GUI, espera-se experimentar e utilizar as últimas tecnologias existentes nessa área. Pretende-se desenvolver um produto de vanguarda, tendo assim argumen-tos para competir com os restantes produargumen-tos existentes, e distinguir-se de produargumen-tos que utilizam tecnologias e métodos de desenvolvimento desactualizados.
4.1
WPF
O sistema de desenvolvimento de interfaces GUI encontrado no Windows XP, tem sido o mesmo utilizado à cerca de 20 anos, o que é extremamente significativo dada a evolução que ocorreu a nível tecnológico durante esse tempo. Considera-se por esse mo-tivo que o desenvolvimento de aplicações GUI, tem sido de certa maneira limitado [GS]. O WPF (The Windows Presentation Foundation), que foi construído sobre a nova fra-mework.NET, está preparado e adequa-se à evolução tecnológica existente sobre o hard-ware, aproveitando as vantagens oferecidas por essa mesma evolução. Para além disso o WPF foi definido de acordo com os novos métodos de desenvolvimento de interfaces gráficas orientadas ao utilizador.
Existem diversos pontos de melhoria no WPF, tais como: • Gráficos avançados
• Modelo de desenho do objecto • Aplicação de texto mais rica • Layout da interface adaptável • Contentores do modelo flexíveis
Tecnologias
• Controlos sem aparência pré-definida • Data-Driven UI
• Estilos consistentes • Triggers
• Programação declarativa
O núcleo do WPF consiste num mecanismo de rendering de resolução independente, baseada em vectores, construído e preparado para tirar proveito das mais recentes evo-luções tecnológicas desenvolvidas sobre o hardware gráfico. O WPF possui um núcleo com um vasto conjunto de funcionalidades para o desenvolvimento de aplicações, como o Extensible Application Markup Language (XAML), controladores, data biding, layout, gráficos 2-D e 3-D, animações, estilos, templates, documentos, media, texto e tipografia. WPF incluísse nas frameworks Microsoft. NET, possibilitando a incorporação de outros elementos de bibliotecas da Framework .NET [Cor11b]. O WPF oferece um novo método de programação para o desenvolvimento de aplicações cliente para o Windows. Com este método é possível desenvolver uma aplicação utilizando a marcação (markup) e code-behind, tal como é realizado na tecnologia ASP.NET. Geralmente é utilizada a linguagem de marcação, XAML, para a implementação da aparência da aplicação, enquanto que é utilizada linguagem de programação de gerência (code-behind), para implementar o com-portamento lógico da aplicação. De acordo com o que é dito no documento [Cor11b], existem diversos benefícios no uso desta tecnologia:
• Redução de custos de desenvolvimento e de manutenção, uma vez que a aparên-cia de marcação específica não está intimamente ligada com o comportamento de código específico.
• Desenvolvimento mais eficiente dado que os designers podem implementar a apa-rência de uma aplicação simultaneamente com os programadores que implementam o comportamento da aplicação.
• Múltiplas ferramentas de design podem ser usadas para implementar e compartilhar a marcação XAML com o code-behind. Microsoft Expression Blend [Mic10a], é utilizado pelos designers, enquanto o Visual Studio 2010 [Mic10b] é designado para os programadores.
• Globalização e localização das aplicações WPF são bastante simplificada.
A marcação XAML [Mic10c] é uma linguagem baseada no XML, que implementa a aparência de uma aplicação de forma declarativa. Normalmente é utilizada para criar janelas, caixas de texto, página, formas, gráficos, entre outros.
Tecnologias
Na figura 4.1é possível observar como é implementado de uma forma muito simples uma janela que contém um botão e ainda o respectivo resultado gráfico.
Figura 4.1: Implementação declarativa de um botão utilizando o XAML e o respectivo resultado Após ser definida a aparência do objecto é possível costumizar o seu comportamento através do uso do code-behind. Este código é o que permite implementar o comporta-mento dos objectos criados pela linguagem de marcação. Este código pode ser descrito em diferentes linguagem .NET, como C#,VisualBasic, entre outros. Utilizando o código de marcação descrito na figura 4.1, foi definido posteriormente o comportamento do bo-tão. Na figura 4.2 é possível observar como é efectuada a alteração do comportamento do botão, na ocorrência de um evento de click do rato e o correspondente resultado.
Dentro dos diversos pontos de evoluções referidos anteriormente, à que salientar os pontos mais revolucionários, que dizem respeito à arquitectura e método de programação das GUI. Pontos esses são a programação declarativa e ao Data-Driven UI.
O conceito de Data-Driven UI permite separar o método de visualização de um con-tentor (template), da lógica e da estrutura de dados que lhe é atribuída. Esta tecnologia permite que os dados apresentados sejam alterados dinamicamente. Para isso é definido uma norma de visualização do contentor, num DataTemplate em XAML, tendo um code-behind correspondente que define o seu comportamento lógico. Os templates de dados funcionam como uma ponte entre a interface do utilizador e os objectos. Isto permite grande flexibilidade aos designers na forma como a informação é representada, sem estes terem de se preocupar com a programação lógica do objecto [GS].
Tecnologias
Figura 4.2: Implementação do comportamento de um botão em C# e respectivo resultado Numa linguagem de programação declarativa, dá-se maior importância ao que é pre-ciso fazer do que à forma como é feito, tal como acontece na linguagem SQL. Normal-mente define-se o que pretendemos que o sistema faça, em vez de definir passo a passo o que é necessário realizar. Pessoas que pretendem desenvolver interfaces com poucos conceitos de programação, como acontece geralmente com os designers, torna-se mais simples desenvolver interfaces desta forma. Habitualmente programas elaborados utili-zando este método, tornam-se mais simples e fáceis de interpretar, por terem um código mais compacto e estruturado [GS].
Tendo em conta tudo o que foi referido anteriormente, o WPF é identificado como a plataforma do futuro, no que diz respeito ao desenvolvimento de interfaces para Windows.
4.2
GoXAM
Foi estabelecido como um dos pressupostos da dissertação, a utilização de tecnologia .NET de forma a poder integrar o editor com outras plataformas já existentes que utilizem a mesma plataforma. Para o desenvolvimento do editor de grafcets, foi então escolhido
Tecnologias
um toolkit que permitisse a construção de diagramas que utilize as tecnologias WPF e respeita-se os requisitos pré-definidos.
Existem diversas ferramentas .NET como: GoXAM, Nevron Diagram, Mindfusion, yFILES, ILOG Diagram, AddFlow, GoDiagram, Essential Diagram, entre outros, que permitem a elaboração de diagramas com inúmeras funcionalidades: Dentro destas fer-ramentas não existem grandes variações nas funcionalidades apresentadas, diferindo ape-nas os métodos de programação, forma de documentação, qualidade gráfica, tecnologia utilizada, suporte e custo. Dado que seria extremamente dispendioso analisar de forma aprofundada todos os toolkits comerciais disponíveis, foi feita apenas uma análise no que diz respeito ao custo, suporte e documentação de cada um deles. Toolkits de diagramas que não pudessem ser desenvolvidos utilizando tecnologia a WPF foram automaticamente descartados.
De acordo com os colaboradores, o GoXAM constituí um valor de mercado conside-rado razoável, e possuí ainda a vantagem de poder ser utilizada uma amostra do toolkit gratuitamente. Esta versão poderá ser utilizado por tempo indefinido apenas para fins de estudo. Como contrapartida a aplicação quando é executada contém uma marca de água, referindo que esta se trata de uma versão experimental. O método de documentação revelou-se suficientemente estruturado e perceptível, sendo disponibilizado ao programa-dor um tutorial que explica os conceitos e a maioria das funcionalidades do GoXAM. É possível ainda ter acesso a um suporte via-email, caso seja necessário esclarecer duvidas sobre o utilização toolkit. Este suporte revelou-se ser rápido e eficaz.
Os aspectos anteriormente referidos culminaram na escolha do GoXAM como plata-forma de desenvolvimento do editor gráfico.
O GoXAM providência controladores para a implementação de diagramas tanto em WPF como em Silverlight. Foi desenhado especificamente para aproveitar todas funcio-nalidades e recursos do WPF e Silverlight. O toolkit foi especificado essencialmente para o desenvolvimento de diagramas orientado a grafos [Nwo10a]. O GoXAM é dos primei-ros toolkit de desenvolvimento de diagramas, a integrar os conceitos de Data Biding e Data Template, inerentes no uso da tecnologia WPF como já foi referido anteriormente.
4.2.1 Modelos de diagrama e Data Binding
Uma das principais características que o XAML apresenta é o uso de ligação de dados. No entanto o toolkit, oferece um suporte de recursos mais complexos do que o controle típico oferecido pelo WPF, de modo a facilitar a implementação do diagrama.
Existe pelo menos dois tipos de relacionamentos de dados primitivos que um diagrama pode suportar:
Tecnologias
• Relações de grupos, em que um grupo contém membros. Utilizado essencialmente para a criação de subgrafos.
O GoXAM utiliza um modelo para procurar, navegar, modificar, manter e alterar as relações dos dados em relação ao diagrama que é vinculado. Uma vez que a complexidade dos dados pode variar, existem três classes de modelo primário que definem a estrutura de dados de acordo com as características do diagrama.
O primeiro modelo é o TreeModel, preparado para aplicações que possuem uma es-trutura de dados de grafos, semelhante a uma árvore. Este é o modelo mais simplista.
O GraphModel é utilizado quando cada nó possui uma lista de nós de ligação que partem ou ligam-se a partir desse nó. Este modelo suporta grupos de grafos simples.
Como último modelo primário existe o GraphLinksModel, onde existe uma estrutura de dados independente para os nós e outra para as ligações. Este modelo permite ainda informação sobre os pontos onde é possível estabelecer a ligação ao nó. É possível ainda criar etiquetas sobre as ligações.
Para desenvolver um diagrama é então necessário estabelecer o modelo a criar, inici-alizar os dados e associar ao diagrama o modelo respectivo. Uma vez isto feito as altera-ções feitas pelo utilizador no diagrama, ou no code-behind alteram de modo automático o modelo.
4.2.2 Data Templatespara os nós
A aparência de um nó ou de uma ligação é determinada tanto pelos dados que possuí, como pelo seu DataTemplate. O DataTemplate define o aspecto visual dos elementos de acordo com os dados a que está associado. O DataTemplate é descrito em XAML, se-parando assim a aparência do diagrama do código de uma forma muito simplista. Para alterar a aparência de um diagrama basta alterar a definição do DataTemplate dos nós e das ligações. Uma vez que os nós e as ligações são definidos de acordo com a especifica-ção XAML, é possível utilizar as funcionalidades associadas ao WPF, como rectângulos, texto, média, imagens, animações, entre outros de modo a criar uma interface bastante apelativa. Na figura 4.3do lado direito está representado em código XAML um dos tem-plates de nós mais simples, consistindo apenas numa caixa de texto. No lado esquerdo da figura 4.3está representado o resultado visual do template implementado
4.2.3 Data Templatespara as ligações
O GoXam suporta ainda o DataTemplate para as ligações com funcionalidades asso-ciadas que podem ser de grande utilidade. A partir deste contentor de dados é possível definir o formato da linha: ortogonal, bezier, normal. Este DataTemplate está também preparado para ser possível definir o routing da linha de acordo com as necessidades do
Tecnologias
Figura 4.3: Exemplo da implementação de um template de nó e o respectivo resultado
diagrama. O routing pode ser de quatro tipos: nenhum, bezier, saltar por cima de nós ou saltar por cima de ligações. Na imagem 4.4 é possível observar um exemplo de imple-mentação de um DataTemplate para ligações com cantos redondos.
Figura 4.4: Exemplo da implementação de um data template de ligações com cantos redondos e o respectivo resultado
4.2.4 Ligações com etiquetas
Nas ligações existe ainda a possibilidade criar etiquetas nas ligações de forma a de-senvolver ligações com formas mais complexas. As etiquetas podem ter qualquer formato de acordo com as funcionalidades do WPF, não necessitam de ser etiquetas de texto. Na figura 4.5pode-se observar uma ligação com duas etiquetas.
Tecnologias
Figura 4.5: Exemplo de uma ligação com duas etiquetas 4.2.5 Ligações com pontos de conexão
De uma forma padrão as ligações ligam-se à volta do nó. Uma vez que existem dia-gramas em que a posição de ligação possui regras e pontos específicos, é exequível criar pontos de ligação específicos. Estes pontos de ligação criados são designados como por-tas. Um nó pode ter qualquer número de portas associadas. Na figura 4.6encontra-se um exemplo de nós com portas associadas. Cada nó contém três portas: A, B e Out.
Figura 4.6: Exemplo de um nó com três portas de conexão
4.2.6 Funcionalidades
O GoXAM possui diversas funcionalidades que são observadas normalmente num di-agrama. Essas funcionalidades contêm estados padrão, que podem posteriormente ser activados ou desactivados. Se for desejo do programador também poderá customizar essas mesmas propriedades, de modo a que estas funcionem de acordo com o que é pre-tendido. Em seguida é aprestada uma lista de forma a enumerar as funcionalidades mais importantes para o desenvolvimento do editor de grafcets:
• Copiar, cortar, colar • Undo e redo ilimitado
Tecnologias
• Edição de texto
• Selecção, selecção múltipla e adornos personalizáveis • Formas pré-definidas e setas
• Paleta
• XML salvar e restaurar • Grelha
As funcionalidades apresentadas anteriormente são uma mais valia para o desenvolvi-mento do editor grafcet, visto que cobrem grande parte das funcionalidades identificadas nas aplicações existentes estudas.
4.2.7 Ferramentas
Cada diagrama tem um número de ferramentas que define o seu comportamento se-gundo os eventos do rato. Isto inclui ferramentas como DraggingTool, ResizingTool e LinkingTool, entre outras. Estas ferramentas possuem um comportamento padrão de fun-cionamento de acordo como os métodos que compõem as classes. Caso seja necessário é possível alterar o comportamento das ferramentas. Para proceder a essa alteração é preciso sobrepor os métodos constituintes da ferramenta pretendida. Se for necessário alterar a forma de movimentação de um nó, é preciso alterar o método da classe Drag-ginTool que diz respeito ao movimento de arraste dos elementos. Sempre que um nó é movido, os métodos associados à classe irão ser utilizados. Por exemplo, caso seja pre-tendido que o Draggingtool não permita mover nós, basta alterar um dos métodos para que isso aconteça. O método ComputeMove, referente à classe DraggingTool é que de-fine as coordenadas actuais do nó e quais as coordenadas para onde se pretende mover. Se este método for alterado de modo a retornar sempre a coordenada actual, automatica-mente toda a movimentação dos nós é bloqueada. Este é apenas um exemplo possível de customização dos métodos do GoXAM.
Este toolkit é de extrema complexidade possuindo uma documentação muito extensa, onde contêm todas as funcionalidades documentadas de forma estruturada. Por vezes torna-se demasiado complexo identificar que métodos são relevantes dada à quantidade de classes e métodos que o GoXAM dispõe.
No desenvolvimento do projecto a plataforma escolhida para utilizada a tecnologia WPF foi o Visual Studio Professional 2010 [Mic10b]. Esta escolha foi tomada pelo sim-ples facto do Visual Studio ter sido desenvolvido de forma a integrar com o WPF. Para
Tecnologias
além disso todos alunos do curso de Mestrado Integrado de Engenharia Informática da Faculdade de Engenharia do Porto têm direito a uma licença gratuita para o uso deste software. Sendo assim faz todo o sentido optar por esta plataforma de desenvolvimento.
Capítulo 5
Implementação
O editor de grafcets deve oferecer ao utilizador uma experiência agradável de dese-nho, dando-lhe liberdade “funcional” suficiente para desenhar o GRAFCET da forma que pretende. Quando é dito suficiente, significa que a liberdade não deve ser excessiva ao ponto de permitir construir GRAFCETs incorrectos (caso do AutomGEN). Por outro lado se limitarmos toda a movimentação de elementos e só permitirmos o utilizador expandir elementos fixos (caso do SFCedit), o utilizador não poderá desenhar o GRAFCET que tem em mente, mas sim apenas a sua ideia conceptual do que pretende que o diagrama represente. A liberdade deverá ser ponderada e respeitar as normas de criação de GRAF-CET [Com00]. De modo a estudar a liberdade que deve ser fornecida ao utilizador, foi necessário recorrer ao desenvolvimento de diversos protótipos.
5.1
Protótipos
O desenvolvimento dos protótipos teve dois principais objectivos. Um dos objectivos foi a adaptação e percepção de como funciona a tecnologia WPF e o toolkit GoXAM. Era tido como segundo objectivo determinar qual a abordagem de desenho a seguir ao mesmo tempo era avaliada a liberdade de desenho fornecida ao utilizador. Em seguida irão ser apresentados apenas os protótipos relevantes que foram desenvolvidos ao longo do projecto. Foi tomado um pressuposto para a realização dos protótipos que consistia em: cada protótipo deverá ser simples e abordar uma principal funcionalidade do sistema. 5.1.1 Criação de um elemento
No protótipo inicial o objectivo principal era criar e visualizar um elemento. Como primeiro passo para desenvolver um diagrama em GoXAM é necessário estabelecer o modelo de dados do diagrama. Existem como já foi referido três modelos de classes primários. De acordo com a complexidade do diagrama é escolhido o modelo. O mo-delo escolhido foi o GraphLinksModel por diversos motivos. Primeiro porque o diagrama
Implementação
GRAFCET possui restrições ao nível da posição de conexão dos elementos. Sendo que o modelo GraphLinksModel é o único que suporta este tipo de restrições, podemos auto-maticamente adoptar este modelo de dados. Existem outros motivos para a escolha deste modelo, como é o caso deste ser o único também que permite ligações com etiquetas, que serão necessárias para representar no futuro os diferentes tipos de ligações. Como por exemplo a ligação ascendente que é composta por uma seta vertical a meio da ligação.
Neste protótipo como segundo objectivo era pretendido criar uma palete que permi-tisse o drag-and-drop dos nós criados. A palete é um tipo de diagrama que o GoXAM contém, que permite demonstrar um número de nós num rectângulo, dispostos segundo uma grelha. Existe uma funcionalidade inerente à palete que permite o drag-and-drop dos elementos.
De modo a implementar o protótipo pretendido foram realizadas as etapas da figura
5.1
Figura 5.1: Esquema representativo da criação de um elemento
No passo 1 da figura 5.1são definidas as áreas de desenho do diagrama e da palete de forma declarativa, utilizando a linguagem XAML. No passo seguinte é estabelecido o modelo de nós e a consequente inicialização tanto do modelo de nós do diagrama como da palete. Estes dois passos foram execu tados pelo code-behind, utilizando a linguagem C#.
Implementação
Na figura 5.2 é possível observar o resultado final da elaboração do protótipo em questão.
Figura 5.2: Resultado do protótipo referente à criação de um elemento
5.1.2 Ligação entre elementos
No GoXAM os diagramas são constituídos por nós e ligações entre si, tal como acon-tece em qualquer diagrama orientado a grafos. Num diagrama GRAFCET aconacon-tece o mesmo. Uma etapa pode ser vista como um tipo de nó e uma acção como outro tipo. A ligação entre o nó etapa e o nó acção iria associar estes dois elementos. Ao ligar a acção a uma etapa, futuramente seria possível definir o comportamento da acção em re-lação à etapa associada, dado que se estes elementos estiverem conectados será possível percorre-los.
Neste protótipo foi pretendido expandir um nó partir da posição de outro e ligá-los automaticamente. Para isso é necessário definir dois tipos de nós e o tipo de ligação. A parte visual tanto dos nós como das ligações é elaborada através do uso dos DataTem-plate, onde é descrito o aspecto dos elementos em XAML. A criação de um novo nó e a informação sobre a posição dos nós envolventes, dizem respeito à lógica do programa, por esse motivo estas acções são realizadas no code-behind da aplicação.
Para a realização deste protótipo é necessário garantir as condições do protótipo an-terior e seguir os passos descritos no esquema da figura 5.3. Na figura 5.4 é possível observar o resultado final do desenvolvimento do protótipo de ligação entre dois elemen-tos.
Implementação
Figura 5.3: Esquema representativo da expansão e ligação entre dois elementos
Figura 5.4: Resultado do protótipo referente à expansão e ligação de elementos 5.1.3 Portas, ligações por arraste e respectivas restrições
As normas de grafcet têm grande preocupação com os pormenores de desenho do grafcet, como acontece no caso de só permitirem que as etapas e transições se liguem por
Implementação
cima e/ou por baixo, enquanto que nas acções só é permitido ligarem-se a etapas de forma lateral. Este protótipo foi desenvolvido com o intuito de estabelecer as portas para cada nó e definir restrições nas ligações, permitindo ligar apenas portas e nós possíveis.
A ferramenta LinkingTool permite criar ligações entre duas portas. Esta ferramenta é activada quando ocorre um evento do rato, mouse-drag. Uma vez que existem regras es-pecíficas de ligação entre elementos e posições de conexão, é necessário restringir o tipo de ligações possíveis. Para isso é preciso então alterar o comportamento da ferramenta LinkingToolno que diz respeito à validação das ligações entre nós. O método que corres-pondente a este tipo de controlo é dominado por isValidLink. Se o método retornar um valor verdadeiro, a ligação entre as duas portas é efectuada, caso contrário não permite a ligação.
Em seguida encontra-se um exemplo de como aplicar uma restrição:
Figura 5.5: Pseudocódigo da aplicação de uma restrição
Na figura 5.7 é possível identificar dois tipos de nós, etapa e transição com as res-pectivas portas de ligação a azul. Nessa imagem é possível ainda observar a ligação entre uma etapa e uma transição.
Estabelecendo regras de ligação entre portas e nós, podemos garantir que ao desenhar e ligar os nós respeitamos a norma GRAFCET. O utilizador deixa assim de correr o risco de criar um grafcet com elementos conectados de forma errada. Com estas restrições garantimos apenas que os elementos ligados entre si estão correctos, mas não garantimos que a linha de ligação e a posição dos elementos esteja correcta, de forma a criar um grafcet válido isso terá de ser garantido por outro tipo de restrições.
5.1.4 Grelha padrão
Ao utilizar os protótipos anteriores, verificou-se que o posicionamento correcto dos elementos efectuado manualmente era algo que demorava algum tempo a realizar, e nem sempre era possível verificar com precisão se estavam colocados de forma correcta. Foi então evidenciada a utilidade de uma grelha. Numa grelha é possível limitar as posições
Implementação
Figura 5.6: Esquema representativo da definição de portas, ligações por arraste e respectivas res-tricções
Figura 5.7: Resultado do protótipo referente à criação de portas, ligações por arraste e respectivas restricções
possíveis dos elementos. Através do uso da grelha padrão podemos oferecer ao utiliza-dor uma forma de posicionamento mais rápida e fácil. Isto porque o utilizautiliza-dor não tem de detectar variações de posicionamento de dimensões reduzidas, apenas variações de posicionamento de acordo com o tamanho do quadrado da grelha. Isto transmite uma
Implementação
facilidade no posicionamento dos elementos entre si e consequentemente estabelece a posição adequada para as linhas de ligação entre os elementos. O uso da grelha facilita ainda a implementação de detecção de colisões entre nós, dado que cada nó ocupa um determinado número de quadrados da grelha de acordo com a sua categoria como pode-se verificar na quarta etapa da figura 5.8. Dentro de cada quadrado da grelha, só é permitido estar um nó ou parte. No caso da transição presente na figura 5.9, é possível observar que este tipo de nó ocupa quatro quadrículas na horizontal. Em seguida é apresentado o número de quadrículas que cada elemento ocupa na horizontal:
Figura 5.8: Esquema representativo da criação e definição dos elementos da grelha padrão
• Etapa – 1 quadrícula • Transição – 4 quadrículas • Acção – 1 quadrículas
• Convergências/Divergências – 5 + 4*(N-2) quadrículas, em que N representa o nú-mero de portas
O ponto 4 e 5 do esquema da figura 5.8servem para garantir que todos os nós fiquem centrados nas células da grelha, mesmo que a forma visível do nó não seja quadrada
Implementação
ou rectangular, como é o caso da transição da figura 5.9. As convergências têm um número de portas inicial de dois. Sempre que é adicionada uma porta a uma convergên-cia/divergência o espaço que ocupa aumenta para mais quatro quadrículas.
Figura 5.9: Transição com a área de ocupação visível
5.1.5 Forma de desenhar do diagrama
Inicialmente foram consideradas e estudadas duas formas de inserir novos elementos na área do diagrama. Uma forma simples de drag-and-drop, arrastando os elementos de uma palete ou expandindo os nós através de outros nós já existentes.
Seria interessante utilizar as duas abordagens, existindo uma redundância na criação de elementos no diagrama, ficando à escolha do utilizador qual a opção mais viável e qual lhe agrada mais. Dado que seria necessário despender demasiado tempo para aplicar as duas abordagens de desenho, optou-se apenas pela implementação da segunda opção. O protótipo teve como objectivo estudar a forma de inserção dos nós etapa, acção, transição, divergências, convergências de modo a não ser permitido ao utilizador cometer erros. Ao desenvolver o protótipo, chegou-se a alguns conceitos que permitem diminuir o erro humano, respeitando a norma do GRAFCET:
• Podem ser criados sobre o diagrama sem ligações os elementos básicos (etapa, tran-sição, etapa inicial, comentário)
• Quando seleccionado um elemento é possível observar que nós são possíveis expan-dir
Esta abordagem permite ao utilizador fazer crescer/expandir um grafcet, de forma lógica e correcta de acordo com a norma. Como primeiro passo terá de criar um elemento que seja inicial na criação de um grafcet ou que faça sentido existir isolado. A partir desse
Implementação
elemento poderá visualizar que novos nós são possíveis, e se desejar poderá criar então o novo nó.
Figura 5.10: Método de expansão de uma acção a partir de uma etapa inicial
Cada nó contém um número de portas de ligação associado aos pontos de conexão que disponibiliza. Utilizando o exemplo torna-se mais simples perceber como funciona esta abordagem.
Uma etapa possui quatro portas de ligação: Cima, Baixo, Direita, Esquerda. Quando um utilizador passa o rato por cima da etapa é detectado o evento e tornam-se visíveis as quatro portas. O utilizador pode aceder ao menu de contexto de uma das quatro portas, observando que tipo de acções são possíveis realizar sobre a porta seleccionada. Ac-ções que nunca façam sentido realizar segundo a norma, não aparecem no menu, como por exemplo adicionar uma transição à porta direita de uma Etapa. Acções que não se-jam possíveis realizar, dadas as circunstâncias do diagrama, permanecem desactivadas até caso contrário. Quando o rato deixa de colidir com o nó as portas tornam-se novamente invisíveis.
Ao utilizarmos esta abordagem, o utilizador irá sempre construir um grafcet com ele-mentos ligados entre si de forma correcta, diminuindo assim a possibilidade do erro hu-mano na construção do diagrama. Para além disso o utilizador como irá construir novos nós a partir da posição do nó que pretende expandir, não precisa perder tempo a movi-mentar o rato até um objecto novo, arrasta-lo e posicioná-lo correctamente, uma vez que já tem o rato sobre o nó que pretende expandir, e este irá expandir, posicionando-se de forma automática.
Após a realização dos diversos protótipos foi possível ter uma maior sensibilidade para elaborar diversas regras para a implementação da aplicação, de forma a respeitar as normas de construção de grafcets. As regras definidas dizem respeito à forma de desenho, movimentação de elementos, ligações possíveis e expansões. As regras desenvolvidas serão apresentadas na próxima secção.
