Programação

  • Bemvindos ao curso PMR 5020



    O objetivo deste curso é introduzir conceitos de modelagem e design formal de sistemas, especialmente de sistemas automatizados. Comparado a outras disciplinas similares no exterior esta seria uma disciplina de Systems Design, que normalmente tem uma abordagem mais ligada a logística e/ou a sistemas de controle e supervisão. No entanto, apesar de considerar os detalhes logísticos que são de grande importância no projeto de sistemas, o foco deste curso é no processo de projeto, especialmente nas fases de requisitos e design. Além da discussão sobre os métodos de modelagem e design também abordaremos o uso de linguagens, em especial as linguagens formais, e entre elas B, OMT&B, Redes de Petri, Redes de Petri Orientadas a Objetos, além de Ontologias. Seguindo a tendencia atual, introduziremos os sistemas de serviço, que, além de serem o foco da nova manufatura distribuída e orientada a serviço permeia as demais atividades ligadas a automação. Terminaremos com a introdução do Robotic Process Automation (RPA), destacando a ligação deste tópico com os conceitos introduzidos previamente.

    Portanto, conceitualmente, a base formal do curso é a Ciência da Computação, workflow e transition systems; a parte aplicada é constituída dos sistemas produtivos distribuídos; e dos sistemas supervisórios. No que diz respeito aos aplicativos de mercado usaremos o ObjectiveER para análise de requisitos, PIPE2 e CPN Tools para Redes de Petri e UiPath para modelagem de RPA.. Acompanharemos palestras e material divulgado pela Vitech, que oferece serviços mundialmente na área de Model Based Engineering.

    Uma lista da bibliografia que cobre os conceitos básicos da disciplina é mostrada abaixo. Durante as aulas serão apresentados outros artigos, publicados em periódicos indexados e com um bom número de citações.

    Até o final da disciplina os alunos devem escrever um artigo ligando seu trabalho de dissertação ou tese aos conceitos discutidos.

     

             Nossa primeira aula será amanhã, 19/02 na sala MZ-02, piso superior do predio da Enga. Mecânica                                                   

  • Tópico 1

    Esta semana tratamos da definição mais detalhada de sistemas, seguindo uma representação formal baseada em conjuntos. Introduzimos a no\cão de contexto e domínio, de ambiente e fronteira na definição de um artefato. Esta é uma fronteira abstrata e o que importa é ter uma definição de pertinência clara para distinguirmos quais componentes pertencem ou não ao sistema.  Coincidentemente esta é a fase onde vocês estarão definindo os respectivos artigos e vão precisar de uma base conceitual sólida sobre a diferença entre a modelagem de sistemas (e de sistemas de serviço) e a modelagem de sistemas de informação ou de produto.
    O desafio real é ter claro o conceito de ciclo de vida de um sistema e as opções que temos para escolher um ciclo de vida adequado. O critério de escolha está sempre ligado aos métodos e aos paradigmas em que estes se baseiam. Por isso, vamos definir melhor estes métodos e paradigmas. Um deles é o método estruturado, proposto nos anos 80 por David Marca.   
    A leitura da semana será sobre o conceito e as definições básicas de sistema e de Engenharia de Sistemas, reunidas em um resumo de lecture ministrada pelo Prof. Matjaz Mulej no congresso do International Federation of Systems Research (IFSR) quando foi feita uma homenagem ao aniversário da morte de William Ross Ashby, um dos grandes nomes da cibernética, ao lado de Norbert Wiener. Trata-se de um texto mais conceitual. Teremos a oportunidade de tratar o formalismo para o problema de design mais adiante.




    Nossa aula nesta quarta-feira será na sala MZ-01, entrada pelo corredor impar.

                                                                                                                                                                 


    Para a próxima aula...
    exercicio1
     


  • Tópico 2

    Aula 3

     


    Nesta aula o nosso objetivo é comparar a "cultura" associada a projetos que nos é legada com a evolução teórica e prática já ocorrida, especialmente no que diz respeito à fase inicial: os requisitos.  

    Faremos uma breve revisão do que foi discutido na aula passada sobre os paradigmas, e introduziremos de forma abstrata o conceito de design orientado a objetos. Neste contexto destacaremos o papel da fase inicial de requisitos.

    O projeto de sistemas é, em última instância, um processo com conhecimento incompleto, onde não se sabe de fato todos as informações, funcionalidades, e restrições sobre o artefato que se quer gerar. A figura ao lado mostra o tamanho do desafio e foi retirada dos artigos do Projeto NATURE (Novel Approaches and Theories Underlying Requirements Engineering) - criado nos anos 90 - onde se insere a tentava de se antecipar a introdução de uma representação formal, ainda na fase de requisitos.

    Na prática há dificuldades em optar por um desenvolvimento mais formal, dado a carga e o volume dos projetos em desenvolvimento. Ainda assim, empresas se preocupam com o desenvolvimento formal e até em incorporar alguns destes métodos escondendo o formalismo atrás de um processo mais interativo com o usuário. 

    Entretanto, nesta aula trataremos mais das demandas em termos de análise de requisitos e da importância que está análise assume em projetos de inovação e automação. Voltaremos a discutir a formalização na aula que vem.

    __________________________________________________________________________________________________________


      


  • Model Based Requirements Engineering

    Na aula de hoje aula vamos começar a nos aproximar, primeiro de forma conceitual, depois de forma mais prática, do processo inicial de eliciação e análise de requisitos, tanto em geral, como no cado do design de sistemas. O ponto principal é que esta fase inicial costumava ser negligenciada na prática, e mesmo hoje são poucos as ferramentas e sistemas dedicados a apoiar engenheiros e pesquisadores neste processo (algo em torno de 5% do esforço dedicado às fases de especificação, dseign, otimização e implementação).

    Na aula passada nos referimos às dificuldades inerentes ao processo de design e ao fato de lidarmos sempre com conhecimento incompleto nesta fase. Outro ponto importante é a tentativa de antecipar a formalização da representação dos requisitos, antes mesmo de virarem especificação. Vamos analisar duas alternativas: uma é começar com UML - indo em busca de um uso mais racional do UML 2.5 - e portanto ter pela frente a necessidade de ter uma representação formal aderente (o SysML); outra alternativa é começar com outra abordagem mais moderna para representar e modelar requisitos: os métodos orientados a objetivos (Goal Oriented Requirements Engineering) . Esta discussão será introduzida na aula que vem.


    Embora a modelagem funcional seja bastante intuitiva, é um grande risco se basear unicamente nesta abordagem, dado que isso leva ao desenvolvimento de sistemas corretos mas não necessariamente completos. No caso da automação precisamos que estes sistemas sejam corretos e completos. 

    Optaremos portanto pelo desenvolvimento de projetos (e sistemas em especial) usando abordagens orientadas a objetivos ou GORE. A discussão passa a ser agora sobe as bases teóricas de uma abordagem goal-oriented, das vantagens e desvantagens, e do uso de ferramentas de apoio, no caso, do ObjetivER (consulte a página objectiver.com) que é hoje uma ferramenta comercial, mas que permite ainda o download de demos para avaliação com no mínimo 30 dias de prazo. O mesmo site pode prover documentação e manuais para facilitar o uso da ferramenta.
      

    Milestone 3:
    Teremos a oportunidade de avançar e eventualmente atualizar algum atraso, no milestone 3, onde, além de um título e abstract vocês vão exercitar fazer uma introdução ao artigo, explicando qual seriam os objetivos e resultados esperados. Uma bibliografia inicial deve ser inserida também. 





  • MBRE na prática

    AULA - 5

    Nesta aula dar mais um passo adiante na discussão de como trataríamos um processo de Model Based Requirements Engineering baseado no exercício de modelagem de um sistema de controle de acervo que usamos nas aulas anteriores (primeiro de forma livre e intuitiva, depois pensando na representação dos requisitos em UML). Entretanto, nas tentativas anteriores não se vislumbrava um ciclo de modelagem de requisitos, especialmente voltado para o Model Based Requirements Engineering.

    O processo que apresentaremos é baseado na proposta de Model Based Systems Engineering, apresentada por A. Wayne Wymore. No entanto nesta aula não entraremos nos aspectos formais, para que possamos focar nos conceitos e na comparação mais intuitiva que adotamos até aqui com o exercício de controle de acervo. Por outro lado vamos focar na base do MBSE que é eminentemente funcional. 

    Uma vez estabelecida esta base funcional, vamos agora considerar uma alternativa que foi definida e desenvolvida neste século: o goal-oriented requirements engineering (GORE). Embora seja um método especialmente voltado para requisitos e não para o Systems Design como um todo, o GORE se coloca como uma alternativa para o ciclo de requisitos onde a abordagem funcional é substituída por uma abordagem orientada a objetivos. É também baseada em "visual diagrams" como mostrado na figura abaixo, que são denominados diagramas KAOS (Knowledge Acquisition and Objective Specification ou Keep All Objectives Satisfied).


     


      


  • Usando modelagem formal de requisitos

    Aulas 6

    Na aula passada fizemos uma abordagem mais prática do processo de modelagem e análise de requisitos (pelo menos para compor um modelo inicial) seguindo a abordagem do Model Based Systems Engineering proposta por A. Wayne Wylmore. Está será a abordagem que usaremos para o Model Based Requirements Engineering no restante do curso. Nesta aula vamos fazer o contrário, elaborar um pouco, mesmo sem entrar em detalhes, o processo de formalização, usando como base o Event B, criado por Jean-Raymond Abrial. Com isso poderemos ter um feeling da diferença entre tratar o problema semi-formalmente e formalmente. Depois disso retornaremos à discussão sobre a mudança entre a abordagem eminentemente funcional e uma abordagem orientada a objetivos.

    Vamos portanto nos concentrar no método KAOS e na ferramenta mais recente para sua aplicação que é o Objectiver. Baseado no artigo de Huzan Al-Subaye e Thomas Maibaun (que será a leitura da semana), vamos ponderar se o método KAOS realmente satisfaz os postulados básicos da Engenharia de Requisitos, especialmente no que diz respeito à captura dos REOs (Requirements Engineering Objectives) e se a ferramenta de suporte mais difundida recentemente, o ObjectivER, implementa adequadamente estes princípios e consegue gerar documentação de forma automática, de modo a viabilizar um ciclo de manutenção baseada nos requisitos.

    Na Aula 7 voltaremos a esta discussão.  O tutorial do Objectiver está no site www.objetiver.com, onde poderão também fazer o download de uma versão trial. Como leitura apoio, temos o artigo de Frank Zicker, que propõe uma análise de performance das ferramentas GORE e em especial KAOS,  para tratar "complex tasks", pensando no universo do desenvolvimento de software. Caberá a nós fazer um paralelo deste questionamento para o tratamento de sistemas, e mais ainda, de sistemas propostos para resolver problemas complexos. Conceitualmente a transposição não é difícil, mas é preciso levar em conta as especificidades dos sistemas e é isso que vamos fazer nesta aula 7. 

    Finalizaremos por unificar a análise feita nestes (e em outros) artigos, permeado pela experiência prática (limitada) que vocês tiveram nos exercícios anteriores. 



    Nesta semana darei um feedback sobre as propostas de artigo encaminhadas pelo e-disciplinas (e algumas enviadas por e-mail, para aqueles que não têm acesso ao sistema). Vocês devem acompanhar os comentários e se preparar para dar mais um passo na elaboração do artigo, agora inserindo uma seção onde se faz uma descrição mais completa da proposta do artigo.



  • Aula 7


    Model Based Requirements Engineering (MBRE) pode ser feita alternativamente usando métodos semi-formais ou diretamente formais. No primeiro caso temos a opção entre uma abordagem funcional ou uma abordagem orientado a objetivos.


                                     

    Nesta aula faremos vamos aprofundar a comparação entre a abordagem orientada a objetos funcional e orientada a objetivos. Na aula passada nos referimos ao artigo de Al-Subaie e Tom Maibaum sobre as expectativas que podem ser geradas em torno do GORE (Goal-Oriented Requirements Engineering) o que nos leva a aprofundar a discussão e comparação de prós e contras em relação a optar por uma abordagem orientada a objetivos ou permanecer no modelo mais clássico da abordagem funcional. Assumiremos até aqui que é de fato mais abrangente (pensando em desenvolver sistemas automatizados e orientados a serviço) usar uma linguagem semi-formal - como UML ou KAOS. Linguagens mais fechadas entretanto podem ser mais adequadas para domínios específicos. 

    As redes de Petri podem ser a base para a representação formal (e dinâmica) para sistemas distribuídos, em especial para os sistemas automatizados. Não faz parte do escopo da disciplina o estudo detalhado sobre Redes de Petri (é assunto de outra disciplina. Na aula que vem voltaremos à discussão sobre outras alternativas de formalização além de Event B e Redes de Petri.


     Milestone 4

    Teremos agora como objetivo dar mais um passo na direção do Milestone 4. Agora temos que atualizar a proposta de artigo, que além do título, abstract, introdução terá uma seção que diz “qual é a proposta”. A principal definição (nesta fase) é se vocês adotarão um desenvolvimento funcional ou orientado a objetivos (goal-oriented).

  • Dos requisitos para o design

    Aula 8


    Nesta aula vamos (já com algum atraso) fazer uma mudança no foco de discussão sobre projeto de sistemas: até aqui discutimos uma abordagem geral e fizemos um estudo sobre a fase de requisitos - reconhecida como estratégica para o sucesso de qualquer projeto. Esta fase consiste das etapas de eliciação modelagem, análise e formalização de requisitos, até escolha de uma linguagem adequada para receber as especificações que devem então ser transferidas para a fase de design. A discussão passa a ser como modelar soluções, eventualmente usando a mesma linguagem de especificação, ou, em alguns casos usando outra linguagem mais adequada para  o design. Nesse caso será preciso fazer uma conversão do formalismo usado nos requisitos.   

    Gostaríamos e minimizar a transferência semântica entre diferentes linguagens, evitando  fazer a especificação  das soluções (design) em uma linguagem diferente da usada nos requisitos. Portanto precisamos avaliar quais as representações disponíveis para a especificação dos modelos de solução e considerar se este mesmo formalismo poderia ser aplicado na modelagem de requisitos.   Frapier e Harbrias analisaram esta possibilidade, considerando especificamente o desenvolvimento de software. A proposta dessa aula (e talvez da próxima) será analisar as representações formais disponíveis, sua aplicabilidade para modelar soluções, e em seguida (na aula que vem) a aplicação do mesmo formalismo para a análise de requisitos. Os processos de transferência não serão tratados nesta disciplina.

    A discussão será feita à luz dos conceitos básicos Engenharia de Sistemas, portanto devemos extrapolar a discussão do artigo do domínio do desenvolvimento de software para um contexto em que temos sistemas, eventualmente compostos de sistemas, que envolvem pessoas, máquinas e recursos, incluindo um sistema de controle baseado em software.  

     



  • Model Based Systems Design (MBSD)

    AULAS 9



    Nesta aula vamos dar um passo mais firme para passar da fase de requisitos (e do functional cotyledon) para a fase de design, incluindo a modelagem das alternativas de solução e seleção de uma proposta mais promissora que atenda aos requisitos para detalhar. Na verdade trata-se de seguir com o processo recursivo de modelagem (em termos de sub-sistemas que são também modelos) até ter um modelo do artefato (seja produto, sistema ou um híbrido dos dois). Este processo é chamado de Systems Analysis. 

    O termo parece (e de fato é) antigo, mas discutiremos como este termo é interpretado e utilizado hoje, tendo como base a discussão ocorrida em 2016 no Incose que já preconizava um avanço significativo nos métodos de design de sistema. Vamos usar esta discussão com base e seguir as definições mais formais de A. W.Wymore para Model Based System Engineering, agora na fase de design.

    Teremos dois exercícios para a próxima semana, aproveitando o dia do trabalho (na verdade será a semana do trabalho): um deles é repensar o mesmo exercício do sistema de controle de acervo (podem instanciar o dominio de aplicação na USP), agora usando os conceitos e proposta discutidos nesta aula; o outro é um estudo dirigido sobre métodos de escolha de alternativas de solução em processo de design. Vejam os slides da aula para mais detalhes.


  • MBSE e MBSD: desenvolvendo soluções de sistemas

    Aula 10



    Nesta aula vamos entrar na discussão sobre o  Model Based System Engineering, que de fato vem sendo discutido desde 1967, tendo o artigo seminal de A. Wayne Wymore como proposta mais acabada de formalização. Certamente, o nosso objetivo nesta disciplina será o uso prático do MBSE, mais do que a modelagem formal. Portanto, vamos estruturar os conceitos básicos vistos até aqui aprofundando a base conceitual do MBSE, para tratar a  sua aplicação na próxima aula. O passo a ser dado é baseado nestes conceitos e na hipótese de usar systems of systems e dos "sete samurais" do processo de design de sistemas.  Este modelo será depois enriquecido com o tratamento de  sistemas distribuídos e eventualmente orientados a serviço, trazendo a discussão para o domínio acadêmico, embora também haja casos práticos associados em domínios específicos como o dos sistemas críticos e heath care. 

    A leitura desta semana - base da discussão da próxima aula - será um white paper da empresa Vitech Co. escrito pelos seus principais diretores. Evidentemente a idéia não é tomar nenhum white paper como "bíblia" e sim verificar o quanto este documento, e os conceitos contidos nele, se coadunam com a base conceitual discutida na aula de hoje. Contaremos ainda com o Vitech University para trabalhar com o sistema Genesys, uma dos mais usados no mercado atualmente. Naturalmente a escolha não é por acaso, e podemos esperar uma boa aderência, senão total. A idéia é justamente colocar em cheque o "argumento" de que estes conceitos estariam restritos ao mundo acadêmico, mesmo reconhecendo as dificuldades de colocá-los em prática em projetos de mercado. 


    Novo Milestone do artigo

    Agora os artigos precisam entrar na "reta final".  Portanto, o novo milestone será considerar as criticas ao artigo feitas nos milestones anteriores e consolidar tudo em uma nova versão que além de rever tudo que foi feito, criticado, refeito, etc. agora entra mais diretamente na contribuição proposta, argumento e substanciado técnica e teoricamente esta proposta. Para detalhes veja os slides de aula.




  • MBSE: Métodos e Sistemas de Apoio

    Aula 11



    Nesta aula retomaremos a discussão sobre o MBDE partindo dos conceitos de system of systems e dos 7 samurais do SE, discutidos na aula passada, e da incorporação de novos conceitos extaídos de artigos e propostas do Jet Propulsion Lab (NASA) para montar um arcabouço que pode, tanto subsidiar a formalização, quanto a implementação de ambientes desenvolvimento - baseado em métodos ou em arranjos de métodos, técnicas etc. inseridos em uma  metodologia.  Esta metodologia pode ainda ser compilada em normas, como a ISO/IEC 15.288 que trata do Object-Oriented System Engineering and Management, ou OOSEM . Entretanto, este é apenas um detalhe para o nosso escopo dado que o nosso interesse é saber como os conceitos de design e o ciclo de projeto de sistemas se rearranjam em uma abordagem mais moderna, a de sistemas de sistemas.

    Pontuando a exposição nos referiremos ainda à possibilidade de formalização do design de sistemas, apenas para mostrar que os métodos e técnicas discutidos estão em perfeito acordo com a proposta formal de A. Wayne Wymore, para o Model Based System Engineering. Assim, os diferentes aspectos definidos durante o curso devem agora compor um quadro perfeitamente integrado. É portanto o momento de se perguntar se não falta algo para completar o quadro. Vamos nos preparar portanto para discutir na próxima aula sobre a relação entre o Design de Sistemas e Ciência de Serviços e a caracterização dos sistemas como product-service systems (PSS).


     Novo Milestone

    Estamos agora em condição de avançar na elaboração do artigo. A versão final deverá ser entregue (via e-disciplinas, como sempre) até a meia-noite do dia 3/06 (quarta-feira). Assim, o próximo passo é tentar compor o artigo completo até a próxima aula, para podermos ter uma revisão completa antes de preparar a versão final. Lembrem que no dia 20/05 teremos a última aula do curso. Depois disso teremos ainda office-hour no dia 22/05 e daí em diante vocês devem fechar o artigo por conta própria. 

    Como exercício final (para o dia 27/05 vocês devem usar o sistema Genesys da Vitech para - seguindo um método orientado a objetos - rever e re-editar o seu projeto de sistema de controle de acervo em uma versão final. Podem então usar o que já fizeram de modelagem e análise de requisitos para elaborar um modelo no Genesys e propor uma alternativa (escolhida entre várias) de solução. 

    • Slides da Aula11

    • Draft do artigo completo

    • Projeto final para sistema de controle de acervo. O exercício é compor uma documentação completa de projeto, como vimos discutindo em sala. Portanto, requisitos (seja qual for o tipo de diagrama usado), escopo tecnológico, formalização (se houver), propostas de solução, escolha (fundamentada) da solução, e especificação desta solução devem compor um documento PDF (na falta que temos de ferramentas específicas para documentação). 

  • MBSE for Service System

    Destaque



    Chegamos ao final do curso, que à partir da Aula 5 passou a ser integralmente virtual. Creio que a experiência foi boa, e mesmo estando longe pudemos discutir os tópicos programados e até avançar um pouco para atender interesses específicos de cada um. Perdemos um pouco da interatividade que as aulas presenciais conferem, mas, em compensação tivemos mais interação virtual com as "office hour".

    Nesta última aula vamos colocar, como diríamos "a última cereja do bolo" para configurar os sistemas que se apresentam com um desafio inteiramente novo para as próximas décadas: os sistemas de sistemas voltados a serviço ou produto-serviço. Estes sistemas desafiam métodos e técnicas de design, por um lado, mas por outro criam uma nova perspectiva para automação de sistemas, permeando todos os ramos de atividade, desde a manufatura até os sistemas de apoio e monitoração da vida, dentro que se convencionou chamar de telemedicina, passando por sistemas de transporte, atendimento a emergências, e pelos sistemas de suporte à própria atividade acadêmica.

    Faremos uma integração com outro "viewpoint", diferente do que foi apresentado na aula passada, para em seguida introduzir os conceitos de serviço e o Model Based Service Engineering.  Com isso teremos configurado uma área de pesquisa em si, e ao também conceitos que podem permear outras áreas de pesquisa e portanto ser de utilidade nas respectivas dissertações e teses. Esperamos ver isso configurado nos artigos finais.

    Foi uma experiência gratificante tê-los todos como alunos este semestre conturbado. Obrigado a todos!

    Reinaldo