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, historicamente este curso é baseado em Sistemas de Informação, como símile computacional de sistemas supervisórios e/ou para tratamento de dados e informação. Recentemente um foco adicional foi adicionado para incluir 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.

    Portanto, conceitualmente, um dos pilares do curso é a Ciência da Computação e workflow e transition systems; outra são os sistemas produtivos distribuídos; e uma terceira são os sistemas discretos e de controle. Enquanto tratamos o problema teórico teremos também um olhar para as aplicações práticas, usando sistemas conhecidos no mercado como o Enterprise Architect e o ObjectiveER para documentação e modelagem de projetos. Acompanharemos palestras e material divulgado pela Vitech, que oferece serviços mundialmente na área de Model Based Engineering.

    Esperamos poder discutir com mais profundidade a fase de requisitos e as novas perspectivas da Engenharia de Requisitos, bem como sua recente difusão tanto na academia quanto no mercado.  

    Para a aula que vem cada aluno deve entregar (até o dia da aula) uma proposta de artigo (o abstract em inglês) que usa os conceitos de design discutidos genericamente nesta aula aos seus projetos de dissertação e mestrado. Recomenda-se conversar com os respectivos orientadores sobre o assunto. Aqueles que forem alunos especiais devem conversar com o professor da disciplina para definir um tema especial, já que ainda não possuem orientador.

    O abstract deve ser um arquivo PDF e o upload pode ser feito no coletor colocado abaixo.

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

    Para a próxima aula...

     


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

    Começaremos com o método estruturado, que surgiu nos anos 80 do século passado inserindo conceitos que persistem até hoje, convivendo com abordagens mais modernas.  Destacamos a necessidade de dar mais atenção à etapa de requisitos, e como avanço teórico e técnico apontamos para a Engenharia de Requisitos como uma área de pesquisa que reúne em um evento anual acadêmicos e praticantes tanto da área de Ciência da Computação quanto da Engenharia em geral, particularmente da Engenharia de Computação. Dentro deste escopo destacamos o surgimento dos viewpoints cujo uso prático tem atraído muita atenção, tanto na academia quanto no mercado.

    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. 

    A empresa Sparx tem um convênio com o Design Lab da Escola Politécnica da USP e especificamente com o D-Lab, onde se desenvolvem estudos sobre o design de serviços e alguns métodos citados neste curso que são implementados usando MDG para gerar bibliotecas que se incorporam ao sistema de base.

    A nova versão do EA promete uma ciclo de vida completo para os métodos ágeis e que tiver interesse direto nisso pode consultar o site http://www.sparxsystems.com.au/ para obter mais informação ou fazer o download deste módulo.

    __________________________________________________________________________________________________________


     


  • Tópico 3

    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) seriam a opção. Estes métodos têm a vantagem de poder fundir a modelagem dos requisitos funcionais com os não-funcionais.


    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.
      



  • Tópico 4

    AULA - 5

    Nesta aula veremos a diferença entre os métodos clássicos de análise de requisitos - uma fase crucial para o design de sistemas - os métodos modernos de modelagem e análise de requisitos. Na verdade estamos em busca de abordagens que integrem os conceitos clássicos - vistos na abordagem estruturada, baseada na possiblidade de composição e refinamento,  da utilização de viewpoints múltiplos (em contraposição às técnicas clássicas baseadas em um viewpoint único), e que permitam a fusão entre requisitos funcionais e não-funcionais. Abordagens que sejam capazes de capturar as restrições do domínio de aplicação (também definido no projeto), separando os assumptions (ligados ao relacionamento do sistema com o seu
    entorno 
    ou aproximação do domínio) dos demais requisitos

    Queremos ainda que estas técnicas sejam indiferentes (ou aderentes) ao fato de termos domínios próximos ou disjuntos (um conceito inserido pelo D-Lab e que portanto não aparece nas ferramentas clássicas). A abordagem orientada a objetivos (Goal-oriented Requirement Engineering) é uma candidata que preenche a agenda de pesquisa e também as opções de mercado.


    Na verdade temos duas propostas: 

    i) a primeira baseada nos métodos clássicos, que usam UML na eliciação, análise e modelagem de requisitos ; 

    ii) a segunda possibilidade usaria uma representação em KAOS (diretamente ou seguindo uma primeira fase de eliciação em UML) e seguiria para a fase de análise e verificação em LTL.

    Em ambos os casos podemos utilizar Redes de Petri como alternativa de representação para fazer a análise de sistemas distribuídos e automatizados (onde a verificação da demanda e fluxo de controle é importante).  

    Para consolidar esta fase, trabalharemos em um novo projeto de modo a combinar o estudo conceitual (e teórico mais adiante) com o "feeling" de como fazer o design de sistemas.


      


  • Tópico 5

    Aulas 6 e 7

    Nestas duas aulas vamos nos concentrar na parte mais prática, já que estamos cruzando a metade do curso. A perspectiva é que, além da discussão teórica, possamos também avaliar o uso dos conceitos no desenvolvimento de sistemas (e de sistemas de serviço) embora não seja de fato possível ter um projeto real de desenvolvimento durante uma disciplina. Ficaremos portanto no meio termo, entre o exercício da aula passada e a demanda de uso acadêmico ou prático dos conceitos estudados até aqui.

    Vamos portanto nos concentrar no método KAOS e na ferramenta mais recente para sua aplicação que é o ObjectivER. Em primeiro lugar (Aula 6) vamos nos concentrar no artigo de Huzan Al-Subaye e Thomas Maibaun, sobre o questionamento 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 implemente adequadamente estes princípios e consegue ainda gerar documentação de forma automática, de modo a viabilizar um ciclo de manutenção baseada nos requisitos, ao invés do código e do design diretamente.

    Portanto vamos trocar a abrangência do estudo das diversas propostas de métodos goal-oriented para concentrar no KAOS e seus aplicativos de implementação, para em troca poder ir mais fundo no uso prático destes recursos e técnicas. 

    Na Aula 7 voltaremos a esta discussão, agora com foco na performance obtida com o método GORE (e em particular com o ObjectivER.  O artigo do Frank Zicker propõe uma análise de performance das ferramentas GORE e em especial KAOS, como seu representante principal, 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. 



    Em compensação vamos poder agora retornar ao artigo com uma boa base para tratar  as propostas já elaboradas tanto do ponto de vista teórico e conceitual como com algum feeling da aplicação real. Assim, para a aula que vem teremos como meta fazer uma nova versão do artigo, agora incluindo (depois do título, abstract, introdução) uma seção com a descrição da proposta, deixando claro qual seria a contribuição do artigo. 

     


  • Tópico 6


    Um paradigma "é um conceito das ciências e da epstemologia que define um exemplo típico ou modelo de algo. É a representação de um padrão a ser seguido.


                                     

    Nesta aula faremos uma introdução geral aos critérios das representações formais e em particular ao paradigma Estado-Transição como suporte para o estudo dos sistemas discretos e para o desenvolvimento de sistemas em geral. Uma maneira de sintetizar requisitos em uma representação formal seria usando LTL, que é justamente a representação usada no ObjectivER.  Em seguida mostraremos que o paradigma Estado-Transição também pode ser formalmente representado por Transition Systems que serão definidos na nossa abordagem por Redes de Petri.  Na verdade sistemas autônomos podem ser representados por autômatos finitos, que por sua vez podem ser transferidos para transition graphs, onde se pode fazer uma análise de atingibilidade dos estados do sistemas. No entanto, sistemas distribuídos só poderiam ser analisados pelo "produto de autômatos".

    Alternativamente, as redes de Petri podem ser a base para a representação formal de sistemas distribuídos com várias aplicações, incluindo-se aí a modelagem de sistemas (distribuídos). Não faz parte do escopo da disciplina o estudo detalhado sobre Redes de Petri (é assunto de outra disciplina), mas poderemos ver uma comparação entre as principais linguagens usadas para representação formal (de requisitos e design) e como se situa as Redes de Petri neste conjunto.


     Trabalho para casa

    Como exercício vamos voltar ao desenvolvimento do artigo final. Agora vocês devem rever o artigo à luz das criticas e comentários feitos por mim ao que já foi submetido para inserir mais claramente uma proposta de contribuição.  Agora temos mais elementos e maturidade no uso do KAOS para esclarecer como inserir o método na proposta de cada um. Não é obrigatório "usar KAOS" mas o que se pede é uma re-avaliação se seria o caso de usá-lo direta ou indiretamente. O principal  objetivo na verdade é repensar sobre os paradigmas que é a discussão central desta aula. Estão usando algum? o problema é o uso de um destes paradigmas? Com base nisso faça uma revisão do seu artigo e tente avançar até ter um "primeiro draft". Com ele vamos fazer uma primeira (talvez não seja a primeira experiência para alguns) de submissão de artigo, na próxima entrega. 

  • Tópico 7

    Nesta aula vamos (já com algum atraso) fazer uma mudança no foco de discussão sobre projeto de sistemas: até aqui discutimos métodos em geral e fizemos um estudo sobre a fase preliminar - reconhecida como estratégica para o sucesso do projeto de sistemas - consistindo das etapas de eliciação modelagem, análise e formalização de requisitos até a fase onde se escolhe uma linguagem adequada para receber as especificações que resultam da fase de engenharia de requisitos. A discussão passou então a ser como modelar soluções usando a mesma linguagem de especificação, ou, em alguns casos procurar outra linguagem mais adequada para as soluções (lembrando que estamos trabalhando sobre a definição do problema e não sobre a solução de algum problema em particular). 

    Vamos agora direcionar o foco da discussão para a fase seguinte, a fase de design, onde o objetivo é encontrar uma solução para o problema delineado na fase de requisitos. Gostaríamos e minimizar a transferência semântica e uso de diferentes linguagens na fase de requisitos, ou no final, fazendo uma especificação formal em uma linguagem diferente da usada nos requisitos. O uso do ObjectivER nos levou a passar dos diagramas para o LTL, com a ressalva que para sistemas distribuídos esta especificação de requisitos poderia levar a alguma perda de informação ou a requisitos pouco claros no que diz respeito ao sincronismo de ações e processos. Assim,  Redes de Petri foram apresentadas no artigo publicado por Frapier e Harbrias como uma solução completa. O D-Lab trabalha diretamente na transferência de requisitos modelados por diagramas KAOS para Redes de Petri e Redes de Petri Hierárquicas. Os detalhes não fazem parte do escopo da disciplina, mas não precisamos deles para concluir que com o acréscimo das Redes de Petri fechamos o processo de engenharia de requisitos com uma especificação formal que pode ser usada na fase de design, onde a modelagem de sistemas pressupõe a análise de processos e workflow.

    Nesta aula vamos colocar justamente os conceitos básicos Engenharia de Sistemas e em particular do processo de design para logo em seguida direcionar o foco para a modelagem e design orientado a objetos, Object-oriented System Engineering. O método associado a esta abordagem OOSEM será apresentado na aula que vem. 


    Vocês submeter uma revisão do artigo na próxima segunda-feira. Esta versão (Milestone 4) deve ter título, abstract em inglês, abstract em português, Introdução, motivação (qual a contribuição do artigo e porque é interessante), seção explicando qual é a proposta do artigo. Podem inserir se já tiverem à mão, mas os estudos de caso podem ficar para o próximo milestone.



  • Tópico 8



    Nesta aula vamos entrar na discussão sobre o  Model Based System Engineering que de fato vem sendo discutido desde 1967, e que tem o artigo seminal de A. Wayne Waymore como proposta mais acabada de formalização. Mas o da discussão será o uso prático do MBSE, e as propostas existentes para isso. Portanto vamos estruturar os conceitos básicos vistos até aqui com a disponibilidade de plataformas que poderiam ser usadas como base para sua aplicação. O próprio desafio do design de sistemas, aqui encarados como sistemas distribuídos e eventualmente orientados a serviço, estará por trás de toda a discussão. 

    Como base para a discussão elegemos 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 aspectos conceituais contidos nele se coadunam com a base conceitual discutida o curso. 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 a "teoria não pode ser aplicada na prática", mesmo que a experiência de mercado aponte na direção oposta. A conclusão deve ser portanto uma motivação para o estudo do formalismo. 


    Exercício
    Como exercício, vamos teremos o desafio de, com base na experiência e vivência de cada um, propor uma aplicação para o MBSE em um caso prático que seja do conhecimento de cada um. Naturalmente não basta nominar a aplicação mas é preciso descrevê-la memo sem grandes detalhes, e, principalmente, justificar as vantagens de aplicar MBSE neste caso. Naturalmente estaremos supondo que a fase de requisitos deve seguir os conceitos discutidos (pode ser UML, não precisa ser KAOS, mas daí é preciso entrar no mérito das vantagens e desvantagens disso, incluindo a disponibilidade de plataformas para uso prático).

    Novo Milestone

    Agora os artigos precisam entrar na "reta final".  Portanto, o novo milestone será considerar as criticas ao artigo feitas por mim e preparar uma nova versão revisada. O deadline será para o dia 17/05 meianoite. 




  • Tópico atual

    Tópico 9

    AULAS 11 e 12


    Nestas últimas aulas vamos fazer uma discussão mais acadêmica dos mesmos conceitos já tratados, mas agora visando novas propostas e encaminhamentos da pesquisa na já área. Este processo deve afetar diretamente os respectivos artigos, embora com prazo mais curto para que haja um investimento maior. Infelizmente este é o dilema da disciplina: os tópicos mais avançados só podem ser inseridos no final, e no final o tempo é mais curto para que isso  seja transformado em um artigo mais aprofundado. Vamos ter que lidar com isso!

    Sugiro que revejam os artigos e comparem o que cada um propõe em termos de novidade acadêmica com estes novos encaminhamentos, mesmo que não possam seguir estritamente um deles - vai requerer uma pesquisa bibliográfica mais ampla e demorada, pra começar... - mas para ter uma idéia de como está o artigo em termos do que se apresenta na área e quais as chances de achar uma veículo ou congresso para publicação.

    Terminamos aqui a disciplina e espero que tenha sido útil no caminho e formação de cada um de vocês.

e-Disciplinas - Ambiente de apoio às disciplinas da USP