Topic outline

  • Bemvindos ao curso PMR 5020



    O objetivo deste curso é introduzir conceitos de modelagem e design de sistemas, especialmente dos sistemas automatizados. Se comparado a outras disciplinas similares no exterior esta seria uma disciplina de Systems Design, que geralmente podem ter uma abordagem mais ligada a logística ou a sistemas de controle e supervisão. Historicamente este curso tem de debruçado sobre os Sistemas de Informação, como símile computacional de sistemas supervisórios e/ou sistemas de informação puros. Recentemente um foco adicional foi adicionado pensando sobre os sistemas de serviço, ainda que implementados sobre sistemas de informação e sua similaridade com os sistemas supervisórios.

    Conceitualmente, a ênfase tem sido colocada no arcabouço de Ciência da Computação e Sistemas computacionais. No que se refere ao processo de design sempre buscamos diferenciar o design de sistemas do design de produto. Neste semestre vamos direto ao ponto, isto é, ao design de sistemas tentando economizar tempo e com isso conseguir uma abordagem mais aprofundada em sistemas. Pensamos ainda em conseguir chegar até a implementação e com isso contribuir, eventualmente, para as respectivas teses e dissertações. Assim, adotamos como suporte de implementação o Enterprise Architecuture e o Objectiver, ambos distribuídos comercialmente. O Design-Lab (D-Lab) tem convênios com a Spanx, que fabrica o Enterprise Architecture, e adquiriu uma licença do Objectiver, além de ser possível utilizar demos para estudantes.

    Com isso esperamos poder discutir com mais profundidade a fase de requisitos e as novas perspectivas da Engenharia de Requisitos associada a sistemas bem como a fase de design de sistemas propriamente dita. 

  • Sistemas e seu processo de projeto

    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 sitema. Assim, munidos desta regra, que chamaremos "project statement" poderemos iniciar o trabalho de projetar um sistema. Coincidentemente esta é a fase onde vocês estarão definindo os respectivos artigos e eventualmente algum  sistema que deverá ser feito (pelo menos o design). 
    Mas o desafio real é ter claro o conceito de ciclo de vida de um sistema e as opções que temos para escolhe um ciclo de vida adequado. O critério de escolha está sempre ligado aos métodos usados e aos paradigmas utilizados. Por isso, vamos definir melhor estes métodos e paradigmas. Um deles é o método estruturado, proposto nos anos 80 por David Marca. Este também será o tema da nossa primeira monografia. 
    A leitura da semana será sobre o conceito e as definições básicas de sistema e de Engenharia de Sistemas, que foi o resumo de uma lecture ministrada pelo Prof. Matjaz Mulej no International Federation of Systems Research (IFSR) em homenagem ao aniversário da morte de William Ross Ashby, um dos grandes nomes da cibernética, ao lado de Nobert 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...

     


  • Modelagem e Análise de requisitos

    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 para projeto de sistemas temos várias discrepãncias e novas técnicas que devem ser observadas.

    Começa com os métodos estruturados, que surgiu nos anos 80 do século passado inserindo conceitos que persistem até hoje, convivendo com abordagens mais mdernas. Mas temos também algumas novas práticas, surgidas, por exemplo, com a Engenharia de Requisitos. 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 (Projeto NATURE) 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.

    __________________________________________________________________________________________________________


     


  • Eliciação e Análise de requisitos

    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 pesquisadore neste processo (algo em torno de 5% do esforço dedicado às fases de especificação, deisgn, 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 formalizaaçã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 repreentar e modelar requisitos. Os métodos orienados a objetivos (Goal Oriented Requiments Engineering) seriam a opção. Estes métodos têm a vantagem de poder fundir a modelgem 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 necessáriamente 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 desvantagnes, e do uso de ferramantas de apoio, no caso, do ObjetvER (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.
      



  • GORE - Goal Oriented Requirements Engineering

    AULA - 5

    Nesta aula veremos mais concretamente um dos métodos modernos para 
    modelagem de requisitos. Na verdade estamos em busca de formas que
    congreguem e integrem os 
    conceitos clássicos - vistos na abordagem estru-
    turada, baseada na possiblidade de composição e refinamento -,  de
    viewpoints 
    múltiplos (em contraposição às técnicas clássicas baseadas em
    um viewpoint único), que permitam 
    o devido balanço entre requisitos
    funcionais e não-funcionais sem exagerar no peso de 
    nenhum deles, que sejam
    capazes de capturar as restrições de domínio de aplicação (aproximado), 
    separando os assumptions (ligados ao relacionamento do sistema com o seu
    entorno 
    ou aproximação do domínio) dos demais requisitos funcionais e não
    funcionais - que 
    se referem ao funcionamento e às relações entre os componentes
    do sistema. 

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


    Como vamos ver temos duas propostas: i) a primeira baesada nos métodos
    clássicos (ou que usa mais diretamentes este métodos) e que usa UML na
    fase de eliciação dos requisitos e também na análise e modelagem, a fase de
    modelagem termina com SysML e/ou Redes de Petri e segue para o design
    tendo tando o sistema "as-is" como o "system-to-be" modelados desta forma
    para a fase de design; ii) a segunda possibilidade usa UML somente na fase
    de eliciação, modela os requisitos em KAOS e daí vai para LTL e/ouo Redes
    de Petri, daí segue para a fase de design, novamente tendo tanto o sistema
    "as-is" como o "system-to-be" modelados desta forma, para a fase de design.  
    Consideraremos (porém não de forma prática) a possibilidade de ter a 
    eliciação utilizando o i*, também pertencente ao bloco dos métodos GORE.

      


  • i*: o que faltava no processo de requisitos e o uso de linguagens formais

    Aula 7

    Nesta aula vamos combater a sensação de que "tem algo faltando neste processo que começa com os requisitos"! Se por um lado parece lógico e convincente o processo (espero que vocês compartilhem desta opinião), por outro parece algo como algumas generalizações acadêmicas que de fato se mostram muito mais complicadas na prática! 

    Vamos começar por admitir que este "feeling" é absolutamente correto! um processo de modelagem de requisitos em KAOS pressupõe um trabalho anterior de eliciação de requisitos.  A impressão de que vamos eliciar e modelar os requisitos ao mesmo tempo pode ser efetiva para projetos pequenos e ainda assim, para projetos onde o escopo já foi delimitado por outro engenheiro.  Para outros tipos de projeto a coisa pode ser bem diferente!.

    Vamos portanto introduzir o i* ou métodos de composição de intenções, originário da tese de doutorado de Eric Yu, hoje professor da Universidade de Toronto. Portanto temos sim uma fase preliminar de eliciação que antecede a fase de modelagem de requisitos em KAOS. Ao fazer isso estamos já antecipando a fase de modelagem formal e análise de  requisitos que será feita depois usando LTL ou Redes de Petri. Entretanto vamos dar pouca importância a esta fase de eliciação de requisitos (pode ser feita em i* ou em UML). Faremos isso para ter tempo suficiente de focar mais no método KAOS, que voltaremos a discutir na aula que vem.

    Falando na aula que vem, gostaríamos também de introduzir outro problema, que é justamente sobre a representação formal (uma linguagem de representação que não pode ser uma  linguagem natural). Estabeleceremos critérios de comparação entre linguagens formais que podem ser aplicadas ao projeto. 


    Podemos dizer, de forma metafórica, que usar uma linguagem ou representação formal em projetos de engenharia seria como atribuir uma referência ao processo de design, ou como "seguir a estrada de tijolos amarelos" (follow the yellow brick road), parafraseando o texto da peça "O Mágico de Oz". 

    Esta sensação é bastante razoável e além de prover mais confiança no processo, atende também a requisitos de correção, completeza e segurança, como é o caso de uma boa parte dos sistemas automatizados. A formalização pode ser a base para a aplicação de outros métodos como os métodos de verificação e simulação. Assim, análise baseada em simulação (ou prototipagem virtual) que sejam formais podem ter um papel de destaque no design de sistemas.

     


  • Paradigmas para o desenvolvimento de sistemas


    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 vamos aprofundar um pouco mais a noção de paradigmas e em especial aqueles usados no desenvolvimento de sistemas em engenharia. Começamos o curso patingo de um paradigma, o da estruturação, que por sua vez estava baseado nos conceitos de partição hierárquica e desenvolvimento top-down e bottom-up sobre esta estrutura hierárquica. Na verdade isso foi um dos exercícios e partimos disso e da revisão de alguns destes conceitos em aula como conhecimento de suporte para a disciplina.

    Na aula passada vimos algumas representações formais que podem ser usadas para a especificação de projetos de sistemas e analisamos, com base no artigo de Frapier e Harbrias as diferenças entre algumas destas linguagens (formais e semi-formais), bem como as vantagens e desvantagens em usá-las. Um dos critérios de análise era justamente o paradigma sobr o qual repousava a linguagem e o primeiro entre eles era a máquina de estado. Na verdade o paradigma por trás das próprias máquinas de estado é o Paradigma Estado-Transição, que pode ser representado formalmente por Transition Systems.

    Nesta aula faremos uma introdução geral ao paradigma Estado-Transição como suporte para o estudo dos sistemas discretos e para o desenvolvimento de sistemas em geral. Em seguida mostraremos que este paradigma pode ser formalmente representado por Transition Systems que serão definidos apenas (este tópico está fora do escopo da disciplina) e depois mostramos o caso em que estes sistemas são autômatos finitos, que por sua vez podem ser representados por transition graphs, onde se pode fazer uma análise de atingibilidade dos estados do sistemas. No entanto, sisetmas distribuidos 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).


    Trabalho para casa

    Como exercício vamos voltar ao desenvolvimento do artigo final. Agora vocês devem rever o artigo para inserir toda a discussão que foi feita sobre o tema e proposta de contribuição.   No momento que fizeram esta escolha tínhamos várias informações e material de estudo sobre sistemas, breves noções sobre a teoria de sistemas, e uma incursão sobre os métodos de especificação, modelagem e análise de requisitos, com foco no KAOS.   Agora temos mais elementos e maturidade no uso do KAOS para esclarecer como se usaria isso 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 usar direta ou indiretamente. O principal entretanto é 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. 

  • Systems Design

    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 indo desde a fase de eliciação modelagem e análise 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 os métodos e não sobre a solução de algum problema em particular, isso ficou, eventualmente, para os trabalhos e artigos). 

    Mas até aqui a discussão foi diretamente sobre os métodos e portanto um pouco acadêmica. É natural que vocês achem que há um "gap" entre o que discutimos e a prática de elaborar um projeto, especialmente se este é um projeto de grande porte. Esta é a mudança que vamos fazer nesta décima aula, passando a discutir sobre os métodos específicos para sistemas, começando sobre o conceito de sistema de sistemas. Com isso podemos ter a esperança de aplicar diretamente os métodos que discutimos para uma gama de sistemas de menor porte (ou de incluí-los simplesmente no projeto com a sua documentação), e usar estes sistemas como componentes de um sistema maior - note que aqui não se aplica o termo "sub-sistema". 

    A nossa discussão se pautará pelo SEBoK 1.4 que foi publicado em Julho de 2015.

    Vamos inserir também a nossa mais moderna de serviço e de associação produto-serviço e sua demanda por sistemas de informação.


    Vocês devem receber a revisão do artigo na próxima quarta-feira. Devem então fazer uma nova versão para a próxima aula, dia 3 de maio.



  • Model Based System Engineering

    Nesta aula vamos fazer a conexão com o Model Based System Engineering que de fato é algo que vem sendo discutido desde 1967, com o artigo seminal de A. Wayne Waymore, que também apresentou uma proposta de formalização dos MBSE, tratando-os como sistemas discretos. Mas o mais interessante é de fato os conceitos envolvidos que mudam por completo a abordagem para sistemas colocando os modelos como base do processo de design ao ivés de simples acessórios e base para simulação. É importante frisar que a razão da inversão não é privilegiar a simulação, embora este feature possa e deva ser de fato explorado, mas sim, substituir o foco em documentação por uma referência mais sintética e elaborada, que possa resumir vários aspectos do design do sistema usando para isso uma representação formal esquemática (ou diagramática). 

    Veremos ainda como inserir no processo os aspectos de design que discutimos durante todo o decorrer do curso. Note que na maior parte da discussão estes métodos não estão particularmente ligados ao Design de Sistemas (DS), mas ao conceito de design e modelagem. Entretanto, no escopo do Design de Sistemas os métodos mais enfatizados no curso se encaixam perfeitamente. Finalizando o escopo da discussão, voltaremos a considerar o design orientado a objetos, e com isso faremos uma preparação para a introdução do OOSEM na próxima aula.


    Exercicio
    Como exercicio, vamos considerar agora a inserção do SysML como linguagem de especificação (e eventualmente de design) para sistemas (e sistemas de sistemas). Assim, reveja as notas e o artigo do Frapier e Harbrias que serviu de base para a discussão sobre linguagens de especificação e modelagem e considere todos os atributos e recursos destas linguagens. Preencha mais uma linha em cada tabela para a lingugem SysML e avalie esta linguagem com respeito a cada um dos atributos. Deadline: 14/05

    Novo Milestone

    O novo milestone é considerar as criticas ao artigo e preparar uma nova versão. Entretanto, devido aos atrasos (por minha causa), o deadline será para o dia 17/05. 




  • MDE e OOSEM

    Nesta aula retomaremos a discussão sobre o MDE - sempre com vistas a sua aplicação a sistemas, portanto, na verdade MBSE - e os conceitos da aula passada que na verdade pertencem à norma ISO/IEC 12288 que tratam do Object-Oriented System Engineering and Management, o 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, e o que podemos acrescentar no problema já proposto em 1981 por Hiroyuke Yoshikawa de tentar formalizar o processo de design. Vimos no curso que isso é impossível formalizar integralmente a fase inicial e que sempre teremos uma fase inicial no mínimo semi-automática, a partir do qual é missão do engenheiro tentar passar para uma representação formal o mais breve possível, especialmente no caso de sistemas automatizados.

    Discutiremos os mesmos conceitos mas vinculados à formatação do ciclo de projeto de sistemas, focando agora na especificação de uma  linguagem formal para descrição do modelo que vem da fase de requisitos. Vamos seguir a leitura da semana que é  artigo "Model Driven Engineering:A survey supported by the unified conceptual model". Portanto embora tenhamos visto a formalização proposta por Waymore, vamos utilizar uma abordagem onde o formalismo fica mais implícito e, preferencialmente, gerenciado por ferramentas de software e suporte ao Systems Design disponíveis seja na academia ou no mercado.

  • Domain Specific Language

    Highlighted


    Terminaremos a sequencia de aulas do cursos com a discussão sobre as linguagens de domínio específico e a contraposição do uso destas linguagens na modelagem e design de sistemas com a discussão feita na Aula 7 sobre as linguagens (formais) de propósito geral. Certamente há uma vantagem prática no uso destas linguagens e na capacidade destas de "esconder" o formalismo subjacente. Em contrapartida é impossível negar que alguns "graus de liberdade" serão perdidos e isso, em algumas situações pode comprometer o grau de inovação do design. Mas certamente há um atrativo no mercado por estas linguagens e este é plenamente justificado pela melhor performance e capacidade de reutilização de modelos das DSLs.

    Seguiremos a leitura da semana passada, sempre com alguns acréscimos, mas com a vantagem de que vocês poderão reler o artigo agora com outros olhos. Poderão ainda pontuar os itens de interesse com as transparências e notas de aula.

    O que seria a nossa última aula será agora substituída (recebi uma mensagem encerrando o curso oficialmente no dia 15/05) por um webinar justamente de um CEO da Vitech, a empresa que se dedica ao Systems Design e usa fortemente o MBSE. É a autora do software Genesis da figura acima. Certamente o uso das mesmas frases que usei durante o curso não é coincidência, embora nunca tenha visto este webinar até ontem (que foi a primeira vez que foi veiculado). Também não conhecia o Zane, mas fiquei feliz com a coincidência e apreciei a forma simples como ele colocou as mesmas questões. O seminário coloca mais elementos na nossa discussão sobre o uso das técnicas "ágeis" no design de sistemas.  Infelizmente não teremos tempo de aprofundar esta discussão.

    Boa sorte a todos e sucesso nas futuras empreitadas na pós-graduação.

    ============================================================================================

    Não teremos outra aula na próxima quinta, já que o curso já terminou com a aula de hoje. O prazo para submissão do artigo final fica sendo o mesmo, 02/06, embora tenha prazo reduzido para entregar as notas para a PG. Divulgaremos a avaliação do artigo final e do curso no dia 22/06. 

    • More Agile than Agile: A layered approach to MBSE

                                              Zane Scott

      Solving complex problems in an agile and responsive manner has become the order of the day. Meeting this challenge while maintaining the discipline of the systems view is the focus of a layered approach to systems solution design. The layer-by-layer approach advances the design quickly and responsively without losing focus on system implications. It imposes design discipline without burdening the process and holds all four domains in relationship at every stage of development. This allows the approach to manage complex problems in an agile and responsive way with a high quality solution as its result.

      This webinar discusses this layered approach to system design and improvement. It shows the way to a process that is more agile than the traditional plan-driven methods and at the same time, maintains a disciplined system view that avoids the pitfalls of component engineering. We will discuss the concept of systems thinking, see the importance of understanding the business process components of the system, and explore the delivery of capability that is value-adding for the customer.

      (from Vitech webpage)