6.CONCLUSÕES CONCLUSÕES

Documentos relacionados
5 METODOLOGIA PROPOSTA

Engenharia de Software. Processos. Desenvolvimento de Software Tradicionais 2014/2. Prof. Luís Fernando Garcia

Engenharia de Software Processo de Desenvolvimento. Ciclo de Vida - Modelo Cascata

Engenharia de Software. Herbert Rausch Fernandes

Engenharia de Software II

Processos de Software by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

RUP Unified Process. Profª Jocelma Rios

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPI JOÃO CÂMARA RATIONAL UNIFIED PROCESS - RUP

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

Engenharia de Software

Paradigmas de Software

As 10 Áreas da Engenharia de Software, Conforme o SWEBOK Prof. Elias Ferreira

Como Modelar com UML 2

Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS. Nome:

Requisitos de Sistemas

Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS

Subestações, diferenciando-se da automação industrial e/ou de processos produtivos [01], [02].

Cadeira: Engenharia de Software

MANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO

Prof. Esp. Fabiano Taguchi

Rational Unified Process (RUP)

UML e seus diagramas

RUP Rational Unified Proccess (Processo Unificado da Rational) Equipe WEB Cercomp

Aula 01 Conceito de Banco de Dados e SGBD

Curso de Sistemas de Informação. Karla Donato Fook DESU / DComp. Modelagem de Dados UML

UML 2.0 Método, Linguagem e Ferramenta. Prof. Cesar Augusto Tacla

Introdução à Análise e Projeto de Sistemas

Notas de Aula 03: Introdução a Orientação a Objetos e a UML

Visão Geral do RUP.

Análise e projeto de sistemas

Engenharia de Software

- Engenharia Reversa - Evolução de Sofware. Desenvolvimento como. Requisitos o que. Sistema porque. Profa. Dra. Sandra Fabbri. operacional.

15/04/2013. Pensar Orientado a Objetos. Projeto Orientado a Objetos. Características de Objetos. Classe de Objetos. Comunicação entre Objetos

Engenharia de Software

Processos de software

Conhecendo um pouco sobre RUP

2

GERENCIAMENTO DE PROJETOS - 20h - EaD

Lista de Exercícios AV1

RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS. Prof. Fabiano Papaiz IFRN

15/03/2018. Professor Ariel da Silva Dias Modelos de Processo de Software

UML. Rodrigo Leite Durães.

4 Caso de Uso no Ambiente Oracle

RUP/PSDS. Introdução e Comparação

Desenvolvimento de Projetos

Universidade Federal do Rio Grande do Norte Departamento de Engenharia de Computação e Automação CLPs: Norma IEC 61131

Fábricas de Software. Processos de Software. Fábricas de Software. Fábricas de Software 17/08/2010. Jorge Dias

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Unidade VII Ferramentas de PDS. Luiz Leão

Processo Unificado (PU) Unified Process

3 Uma Abordagem Orientada a Aspectos para o Desenvolvimento de Frameworks

CAPÍTULO 1 O AMBIENTE DE DESENVOLVIMENTO DE SISTEMAS. Tereza Gonçalves Kirner

Processos de Software

Análise e Projeto Orientado a Objetos

Engenharia de Software

Automatismos. Lino Marques. Versão de 15/02/2007. Automação Industrial. Lino Marques 2008

Os pontos mais fortes do MAS-School são: A técnica orientada a objetivos para a fase de requisitos utiliza o processo recursivo de decomposição de um

Aula 3 - Modelos de Processo - cascata, iterativo e incremental e ágil

Prof. Dr. Thiago Jabur Bittar

Unidade I MODELAGEM DE PROCESSOS. Profa. Gislaine Stachissini

Unidade II MODELAGEM DE PROCESSOS. Profa. Gislaine Stachissini

2 Fluxos no Ciclo de Vida do Processo Unificado. O Processo Unificado consiste da repetição de uma série de ciclos durante a vida de um sistema.

Capítulo 2. Orientação a Objetos

LINGUAGENS DE PROGRAMAÇÃO PARA CLP

condicionado proposta em Villani & Miyagi, (2004) e em seguida introduz as contribuições

3 FORMALISMO. ponderados. 3 FORMALISMO 70

2 REVISÃO BIBLIOGRÁFICA

RICARDO ALVES DE SIQUEIRA METODOLOGIA PARA MODELAGEM E ANÁLISE DE SISTEMAS PARA CONTROLE DE GERAÇÃO DE ENERGIA ELÉTRICA

0 MAR/09 EMISSÃO INICIAL GC MRC MRC REV. DATA NATUREZA DA REVISÃO ELAB. VERIF. APROV. EMPREENDIMENTO: ÁREA: ELÉTRICA

MATRIZ CURRICULAR BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO. 1º Período

PDS. Aula 1.6 Modelos de Processo. Prof. Dr. Bruno Moreno

Título PROCESSO LABES ESPECIALIZADO PARA DESENVOLVIMENTO SEGUNDO O PARADIGMA ESTRUTURADO. Projeto. Analista; Requisitos Funcionais Escopo; Cliente;

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA ENGENHARIA DE REQUISITOS

ENGENHARIA DE SOFTWARE. Aula 03 Processos de Software

MODELAGEM DE SISTEMAS Unidade 5 Ciclo de Vida Iterativo e Incremental. Luiz Leão

Perguntas da Aula 2. Respostas da Pergunta 2. Respostas da Pergunta 1. Respostas da Pergunta 4. Respostas da Pergunta 3. Processos de Software

Engenharia de Software

RUP RATIONAL UNIFIED PROCESS CONCEITOS CHAVES. Prof. Fabiano Papaiz IFRN

Aula 1 - Introdução à disciplina e Processos de desenvolvimento de software e suas atividades básicas

Engenharia de Software. Projeto de Software. Projeto: definição. Profa. Dra. Lúcia V. L. Filgueiras Profa. Dra. Selma Shin Shimizu Melnikoff

Model Driven Development (MDD)

As principais contribuições do presente trabalho são as seguintes:

Computação e Programação

Modelagem de Dados MODELAGEM DE DADOS. Sistemas de Banco de Dados. Profa. Rosemary Melo

1. INTRODUÇÃO A MODELAGEM DE DADOS

Aula 3.1 Introdução e Visão Geral do Processo Unificado

Introdução ao Processo Unificado. Prof. Edjandir Corrêa Costa

Processo Unificado Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Introdução

Visão Geral da UML. SSC Engenharia de Software I Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2012

Engenharia de Software

Professor Emiliano S. Monteiro

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE PROF. MSC. EMILIANO MONTEIRO

Análise e Projeto Orientados a Objetos

REENGENHARIA E ENGENHARIA REVERSA

Engenharia Reversa e Reengenharia. Engenharia de Software Profa. Dra. Elisa Yumi Nakagawa 1º semestre de 2015

Resumo parcial da Tese de Doutorado. Um modelo de Sistema de Gestão do Conhecimento para grupos de pesquisa e desenvolvimento.

Grade Curricular do Curso de Graduação em Engenharia de Computação

IEC : linguagens de programação. Douglas Wildgrube Bertol DEE - Engenharia Elétrica CCT

Generalização das técnicas de Piloto Automático para VANTs. Aluno: Raphael da Silva Teixeira (ED 14205) Professor: Cel R/R Cícero Garcez

Transcrição:

6.CONCLUSÕES 193 6 CONCLUSÕES Este trabalho apresentou uma proposta para modelagem e análise de Sistemas de Controle envolvidos na geração de energia elétrica hidráulica, tendo como base dois desenvolvimentos: (1) uma metodologia que envolve a teoria de controle de SDED juntamente com conceitos e pesquisas na área de Engenharia de Software e (2) um formalismo em Rede de Petri Interpretada por Sinais (RPIS) em conjunto com o paradigma de Orientação a Objetos (OO), representado pela proposta da _ (Rede de Petri Interpretada por Sinais Orientada a Objetos). Em relação à metodologia para o desenvolvimento deste tipo de sistema de controle, uma possível abordagem é dividi-lo em quatro fases, onde a partir de uma especificação informal (1ª. Fase), desenvolve-se a especificação formal dos modelos (2ª. Fase), efetua-se a análise por meio da Verificação dos modelos (3ª. Fase) e, por fim, faz-se Realização (4ª. Fase) que é a implementação dos modelos verificados em um IED (Intelligent Electronic Device) em uma das linguagens da IEC 61131-3, ou seja, software mais hardware. A abordagem para o desenvolvimento do Sistema de Controle em quatro fases, a qual é elaborada sob uma visão da teoria de SDED (apresentada no Capítulo 1), não é divergente com a abordagem proposta no Capítulo 5, a qual é construída sob uma perspectiva dos conceitos da Engenharia de Software, de acordo com o RUP (Rational Unified Process) [90]. Nesta última, tendo como base a abordagem incremental e iterativa de um sistema de software [90], propõe-se sua divisão em duas fases: - Fase 1, quando desenvolve-se o modelo do sistema, faz-se sua análise e conclui-se o projeto do modelo do algoritmo de controle e; - Fase 2, quando codifica-se o mesmo modelo em uma linguagem de programação (IEC 61131-3), efetuam-se os testes e faz-se sua implantação no ambiente do usuário (hardware mais software). Então, no que diz respeito a uma metodologia de modelagem e análise, este trabalho desenvolve e propõe uma abordagem considerando duas visões que são convergentes e se complementam: (1) a visão da teoria de SDED (2ª. e 3ª. fases ilustradas na Figura 1.1, do

6.CONCLUSÕES 194 Capítulo 1) e; (2) a visão da Engenharia de Software (fase 1 ilustrada nas Figuras 5.2 e 5.3, e a proposta de metodologia apresentada na Figura 5.4 do Capítulo 5). Esta metodologia possibilita que o sistema em estudo possa ser esmiuçado e compreendido ao longo de sucessivos detalhamentos sob diferentes óticas. Quanto ao formalismo para modelagem e análise do sistema, define-se e propõe-se a _ para modelagem formal e uma sistemática para análise dos modelos. Esta sistemática utiliza os conceitos de componentização e decomposição do modelo do sistema em sub-redes e objetos, o que leva a fragmentar o problema de análise, que poderia ser para uma rede significativamente extensa, em um conjunto de modelos menores e, consequentemente, mais simples. Outra vantagem da abordagem proposta é a possibilidade de criação de uma biblioteca de modelos permitindo a modularidade e reutilização dos mesmos. A análise dos modelos é feita com base na Verificação de propriedades funcionais padrões adaptadas e formalizadas para a _. O cumprimento de algumas dessas propriedades são consideradas obrigatórias para a confirmação do comportamento determinístico dos modelos, outras podem ser selecionadas ou não, de acordo com as exigências e tipos do Sistema de Controle e do Objeto de Controle. Dessa forma, a mesma sistemática, de uma forma flexível, poder ser aplicada em diferentes problemas, em outros sistemas e cenários para comparar a sua eficácia. Em síntese, este trabalho abordou o problema de como construir e analisar o modelo do Sistema de Controle integrado com o Objeto de Controle, para aplicações em Automação Elétrica, podendo estender sua aplicação para projetos de Automação Industrial. Também desenvolveu e propôs uma nova extensão de RP, a _, o que pode ser considerada como uma atualização do estado da arte na área de modelagem de sistemas sob uma abstração de SDED. 6.1 Principais Contribuições Aspirando colaborar para a evolução das técnicas de modelagem e análise de Sistemas de Controle utilizados na Automação Elétrica, resumem-se as principais contribuições deste trabalho nos seguintes pontos: (1) proposta de formalismo para construção dos modelos; (2) proposta de metodologia para concepção e modelagem de sistemas envolvidos na Automação Elétrica e; (3) proposta de formalismo e método para análise dos

6.CONCLUSÕES 195 modelos. (1) Em relação ao formalismo para construção dos modelos, este formalismo é o resultado alcançado pelo proveito de um formalismo existente, a Rede de Petri Interpretada por Sinais (RPIS), com algumas modificações, e a inclusão dos conceitos de Orientação a Objetos (OO), representado pelo desenvolvimento de uma nova extensão de RP: a _. As vantagens deste novo formalismo podem ser resumidas nos seguintes pontos: uma construção modular das classes e objetos; a reutilização dos modelos; sua análise com técnicas já desenvolvidas na área, com algumas adaptações; o aproveitamento, na elaboração do programa do CLP, da mesma estrutura em classes e objetos e dos mesmos sinais digitais de entrada e saída utilizados na modelagem, principalmente quando se tratar de linguagens como o CFC (Continuous Function Chart). Este formalismo foi aplicado e avaliado, de uma forma focalizada e detalhada, em um exemplo, o Sistema de Drenagem do Óleo de Infiltração, conforme Seção 3.5. Outro exemplo de aplicação foi desenvolvido e avaliado, utilizando-se as três contribuições no Sistema Hidráulico de Regulação de Velocidade (SHRV) de uma UHE apresentado no Apêndice A. Nestes exemplos de aplicação foi possível constatar a efetividade das propostas deste trabalho. (2) No que se refere à metodologia para concepção e modelagem de sistemas envolvidos na Automação Elétrica, sob uma visão da RUP, com algumas adaptações propostas, esta metodologia está dividida em etapas, sendo que cada uma é desdobrada em atividades que auxiliam na construção e documentação da modelagem e análise do sistema em desenvolvimento. As ferramentas auxiliares, como o PFS e os diagramas da UML possibilitam uma modelagem gradativamente aprimorada em função do entendimento das diferentes perspectivas da estrutura e do comportamento do sistema em desenvolvimento. A metodologia também possibilita uma coerência e consistência dos objetos modelados em _ com o PFS e alguns diagramas da UML. A utilização da UML como notação de linguagem no auxílio da modelagem de sistemas de controle, pode facilitar a comunicação entre especialistas de diferentes competências, como também auxiliar no processo de integração de diferentes áreas de conhecimento envolvidas. (3) Quanto à proposta de formalismo e método para análise dos modelos, ressalta-se primeiramente que o modelo do sistema a ser controlado (Objeto de Controle) é incluído na análise juntamente com o modelo do Sistema de Controle. As propriedades são então verificadas no sistema controlado (Sistema de Controle + Objeto de Controle), ou seja,

6.CONCLUSÕES 196 integrado por meio de suas interfaces, de acordo com o método proposto. O formalismo para análise dos modelos é baseado na Verificação de propriedades funcionais padrões, algumas fundamentadas no Grafo de Alcançabilidade (GA) e outras relacionas à Álgebra de Sinais de saída, dos modelos. Com a integração do Objeto de Controle com o Sistema de Controle, por meio de suas interfaces, ou seja, pela fusão de transições de seus objetos, pode-se considerar que a Verificação dos objetos integrados engloba os comportamentos esperados de ambos em uma única abordagem. Dessa forma, por exemplo, o possível não funcionamento de um sensor ou falha em um motor, a respectiva transição do seu modelo (objeto do Objeto de Controle) não dispara e consequentemente a mudança de estados do sistema (Objeto de Controle + Sistema de Controle) não evolui. Importa ressaltar que a metodologia proposta nesta tese não garante sempre uma solução ou uma solução mais adequada, pois a dependência da interpretação e interferência de quem realiza este procedimento pode ser vista como uma desvantagem. 6.2 Proposta de Trabalhos Futuros Entende-se que esta tese não pode ser considerada como um trabalho conclusivo e que podem existir várias possibilidades de aprofundamento e aprimoramento para o prosseguimento do tema. Entre estas possibilidades, sugerem-se algumas de maior relevância, quais sejam: Aplicação da metodologia proposta, de uma forma abrangente, no projeto completo de automação de uma UHE, considerando todos os sistemas envolvidos na automação da UG, prevendo-se a construção de uma biblioteca que comporta os objetos mais utilizados, tanto da parte do Objeto de Controle quanto da parte do Sistema de Controle (o que é mais trabalhoso) e também, uma estruturação baseada em uma arquitetura hierárquica ou distribuída híbrida (hierárquica-modificada) de todos os sistemas envolvidos, com base nos conceitos de componentização. Como também, expandir a metodologia proposta, por meio da inserção de cenários específicos que tratam de hipóteses que consideram combinações de diferentes situações consideradas críticas e restritivas sob o ponto de vista de segurança do sistema, como por exemplo: casos de falhas, atuação de alguma proteção na partida

6.CONCLUSÕES 197 ou no desligamento do sistema em estudo, perda de tensão auxiliar de comando quando da atuação de alguma proteção da UG, hierarquia de prioridades de atuação de proteções, etc. Construção de uma ferramenta computacional capaz de reproduzir de forma automática o formalismo e o método de análise dos modelos, com base no Grafo de Alcançabilidade e na Álgebra de Sinais de Saída. Como implementar o Sistema de Controle modelado e verificado, na forma de um algoritmo, em uma das linguagens de programação do CLP (IEC 61131-3), com a garantia que as propriedades padrões verificadas nestes modelos possam ser mantidas e certificadas após a operação normal do sistema. Ou seja, a 4ª. Fase Realização, conforme ilustrado Figura 1.1, do Capítulo 1 e a Fase 2, identificada nas Figuras 5.2 e 5.3 do Capítulo 5. Abordar outros tipos de sistemas como exemplos de aplicação da metodologia proposta, com o objetivo de desenvolver um maior número de modelos e aprimorar a metodologia. Aprofundamento da metodologia e formalismos de modelagem e análise propostos neste trabalho, por meio da introdução da variável independente tempo e de variáveis analógicas, mudando-se a abstração e a abordagem para Sistemas Híbridos em vez de SDED. Utilizar o formalismo de modelagem e análise para algoritmos de controle existentes, por meio da Reinterpretação da lógica do programa do CLP já implementado. Podem existir pelo menos duas razões para a Reinterpretação de um programa existente do CLP, em uma modelagem e análise formais:. Muitos programas de CLP não foram elaborados com uma base formal, ou seja, com diferentes técnicas de acordo com a cultura do programador.. Já existem muitos programas de CLP, os quais dificilmente podem ser formalmente tratados.