Programação
-
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 analisando o processo de transferência dos requisitos para a fase de design, usando inclusive ferramentas largamente usadas no mercado.
A base formal do curso abrange a Ciência da Computação, workflow e transition systems; Engineering Design, especialmente com o MBSE (Model-Based System Engineering), e a Automática, ou Automation Science. No que diz respeito aos aplicativos de mercado usaremos o OMG Marte e o ObjectiveER para análise de requisitos, PIPE2 e CPN Tools para Redes de Petri, e outras.
Até o final da disciplina os alunos devem escrever um artigo ligando seu trabalho de dissertação ou tese, usando os conceitos e métodos discutidos na disciplina. A disciplina será basicamente virtual, baseada em "lives" e atividades que serão repassadas via o sistema e-disciplinas e coletadas somente através deste.
O curso será ministrado remotamente usando o sistema Google Meeting da Escola Politécnica.
-
Sobre o uso da Modelagem de Sistemas (Model-based System Engineering, MBSE) no mercado, segue um webinar promovido pela Vitech, uma das lídereas de mercado nessa área. A Vitech é uma empresa da da Virgínia, EUA, e atua no mercado tanto com consultoria e com dois produtos Genesys e CORE, ambos voltados para o design de sistemas. Coloco aqui a chamada do webinar apenas para deixar claro que o interesse nesse tema não é só acadêmico.
-
Entidade internacional que congrega pesquisa e desenvolvimento em Systems Engineering
-
O SeBok (System Engineering Body of Knowledge) é o documento oficial do INCOSE (International Council of System Engineering) e do IEEE Systems Council. As versões são revistas anualmente por um comitê especialmente designado para isso. A versão 2.9 é de novembro de 2023.
-
Slides da Aula em PDF
-
-
Esta semana introduziremos uma definição mais detalhada de sistemas, seguindo o modelo geral da teoria de sistemas. Definiremos design de sistemas e o ciclo de vida canônico, analisando também outras propostas e diferentes paradigmas. O desafio é ter uma referência para o projeto de sistemas. O planejamento do projeto e a escolha do ciclo de vida está sempre ligado aos métodos e paradigmas em que estes se baseiam. O que temos no momento é resultado de anos de experiência e pesquisa, por isso é importante referenciar métodos e paradigmas que parecem "antigos". Um deles é o método estruturado, proposto nos anos 80 por David Marca e bem desenvolvido na Engenharia de Software.
A leitura da semana (além das referências básicas temos sempre um artigo a cada semana) será sobre o conceito e as definições básicas de sistema e de Engenharia de Sistemas, reunidas em uma 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.
Notas do Exercício 1 (sistema de controle de acervo)
Andre Jin Nagano
6
Carlos K. de A. Hashizume
6
Felipe C. L. Namour
7
Fernando Malavasi
6
Higor F. de A. Silva
7
Julia Emi Ivano
7
Júlio César de Souza
0
Luiz A. C. dos Santos
6
Luiz F. F. da Silva
8
Marco A. J. G. Filho
6
Mateus de C. Del E. Mazzoco
7
Matheus Spinardi
6
Pedro Pimentel Fuoco
7
Pedro V. van Beeck
8
Rodrigo Gebara Reis
7
Thomaz A. Furukawa
6
Victor R. da Silva
7
Vitor Amaral Kiguchi
6
Welker F. Nogueira
7
-
Faça o upload de um texto em PDF sobre como você pensaria (e planejaria) um projeto de sistema de controle de acervo.
-
Usaremos o mesmo link em todas as aulas
-
A Aula2 foi gravada embora poucos tivessem visto em live. Ficamos sem internet no inicio da aula e a conexão foi restabelecida somente 30min depois do inicio da aula. Para que não houvesse prejuízos maiores disponibilizo a gravação da aula para podermos continuar a discussão na aula que vem.
-
Aula 3
Nesta aula vamos trabalhar nos principais paradigmas que compõem o arcabouço conceitual para design de sistemas: a orientação a objetos e sua relação, e os antigos conceitos de modularidade e estruturação. Acrescentaremos os conceitos elementares sobre sistemas e seu formalismo, para introduzir a definição de Model-based Systems Engineering, que compõe a estrutura geral para modelagem do projeto de sistemas. Utilizaremos como referência o Workshop on Systems Engineering de 2016 do INCOSE, e um resumo apresentado pela equipe do Jet Propulsion Lab (JPL) da NASA.
Apresentaremos ainda de forma conceitual os principais "samurais" que caracterizam o design de sistemas como uma rede de sub-sistemas integrado.
Nesta próxima semana vamos iniciar a discussão sobre o artigo final. Para preparar essa discussão vocês devem preparar uma página com o título do artigo, os autores ,e um abstract em inglês. O conteúdo do artigo deve ser previamente combinado com os respectivos orientadores. Se alguém não tiver orientador por favor entre em contato comigo para definir um tema para o artigo final.
-
Naked Objects, Richard Pawson and Robert Mattews, traduzido por
Osvaldo Kotaro Takai e João Eduardo Ferreira, do IME-USP
-
O INCOSE faz regularmente um exercício de visão do que está por vir como desafio para o Systems Engineering (SE). Em 2007 publicou um documento muito importante, o Vision 2020, que direcionou várias atividades em SE em todo o mundo. Agora publicou o Vision 2025 com diretrizes que valem a pensa ser vistas e usadas para reflexão, incluindo o desafio de interagir mais fortemente com os que atuam em SE na prática.
-
Template para o artigo baseado no IEEE Conferences. Esse template é para os que usam Microsoft Word.
-
Template para o artigo final da disciplina para os que usam Latex. Baseado no IEEE Conferences. Arquivo .zip, pode ser simplesmente copiado para o Overleaf.
-
Faça o upload da sua proposta de artigo (em PDF): título, autores, abstract e palavras-chave. No máximo uma página.
Os artigos podem ser feitos em duplas de alunos e, se se tratar de sistema, não de produto, podem estar associados, parcial ou integralmente, aos trabalhos de formatura. Recomenda-se nesse caso inserir como parceiro o orientador do trabalho.
-
Vídeo da Aula3, mesmo faltando a parte inicial
-
Nesta aula vamos avançar um pouco mais nos conceitos práticos e teóricos do MBSE que dão suporte aos métodos e boas práticas para enfrentar projetos complexos de sistemas, especialmente de sistemas automatizados. O domínio do design (composto inicialmente pelo contexto + problema a ser resolvido) é inspirado em paradigmas (e aqui consideramos apenas os mais proeminentes: o método estruturado e o design orientado a objetos), que dão o suporte básico. Vamos discutir mais adiante os detalhes práticos do ciclo de vida de sistemas começando pelos requisitos, e aí necessitaremos incluir diagramas semi-formais diferentes da UML.
O nosso foco será portanto consolidar a ligação entre conceito, formalismo e boas práticas, consolidados em um ciclo de vida adequados para trabalhar em projetos reais. Introduziremos a fase inicial de requisitos que será detalhada na próxima aula.
Para discutir as práticas e a abordagem direta para o System Design usaremos o artigo de James Martin, do INCOSE, que descreve de forma lúdica e precisa a estrutura básica do projeto de sistemas. Sobre esta base, métodos e processos vêm sendo desenvolvidos pelo INCOSE desde 2008 e foram sintetizados em 2016. O artigo tem como título "Os 7 Samurais do Design de Sistemas" em uma metáfora com o filme de Akira Kurosawa, que fez sucesso nos anos 50.
Exercício 2 O exercício para a aula que vem será rever o design que vocês já fizeram para o sistema de controle de acervo, agora pensando em uma aboradagem MBSE e usando KAOS como representação.
-
Survey of Model-based Systems Engineering Methodologies, Jeff A. Estefan, Jet Propulsion Lab, NASA.
-
Faça o upload do seu exercício 2 (uma revisão do projeto de sistema de controle de acervo, agora em uma abordagem holística de sistema). Deve ser um arquivo PDF contendo as fases iniciais da identificação do contexto, problema, modelagem dos objetos e diagrama ERA.
-
Clique aqui para entrar na sala virtual da Aula4
-
Aulas 5
Na aula passada introduzimos brevemente a modelagem de requisitos pelo método GORE (Goal-oriented Requirements Engineering), sem entrar em detalhe e nem tratar da adaptação deste método para a modelagem de sistemas. A modelagem orientada a objetivos pode ser feita tanto usando UML, mas nesta disciplina vamos explorar uma representação alternativa, o KAOS (Knowledge Acquisition and Objective Specification) . Usando essa representação vamos avançar no processo de modelagem de requisitos de sistemas. Nesta aula vamos nos concentrar no processo de modelagem de requisitos usando KAOS usando como suporte computacional o Objectiver. O foco será como usar o método goal-oriented para modelar sistemas (lembrando que todo o framework foi desenvolvido para desenvolvimento de software e depois amplicado). Uma breve consideração sobre as vantagens e desvantagens de usar esta opção de modelagem de requisitos de sistemas será feita, baseada no artigo de Huzan Al-Subaye e Thomas Maibaum (leitura suplementar). Fica em aberto avaliar se o método KAOS realmente satisfaz aos postulados básicos do Model-Based Systems Engineering. Introduziremos um método desenvolvido no D-Lab, o Model-Based Requirements Engineering (MBRE).
Um tutorial do Objectiver pode ser encontrado no site www.objetiver.com, onde também é possível fazer o download de uma versão trial que pode ser usada nesta disciplina.
Já foi colocado no e-disciplinas um feedback sobre as propostas de artigo encaminhadas. Sigam os comentários e se prepararem para dar mais um passo na elaboração do artigo, agora inserindo uma introdução para motivar a proposta. Este será o próximo milestone para a semana que vem.
Milestone 2 Voltaremos ao projeto do artigo, e agora que temos uma proposta (título, abstract) o desafio é escrever uma introdução dando a motivação e justificativa para o artigo e os objetivos que devem ser conseguidos. Seria também o momento de introduzir algumas referências bibliográficas.
-
Al-Subaie, H., Maibaum, T.S.E., Evaluating the Effectiveness of a Goal-Oriented Requirements Engineering Method, Tech. Rep., McMaster University, 2008
-
Matulevicius, R. and Heymans, P., Visually effective goals modeling using KAOS, Technical Report, Advances in Conceptual Modeling - Foundations and Applications, ER 2007, Lecture Notes in Computer Science, vol. 4802, Springer, Berlin.
-
Faça o upload de uma nova versão do artigo, agora com título, autores, abstract e uma introdução. Embora não seja um requisito obrigatório, é natural que seja necessário fazer citações na introdução, e portanto deverá ser incluída uma bibliografia, mesmo preliminar.
-
-
AULA - 6
Vamos avançar na discussão e prática da Engenharia de Requisitos trabalhando sobre o Model-Based Requirements Engineering, proposto pelo D-Lab. Como exemplo voltaremos ao exercício de modelagem do carro elétrico (apenas o sistema de navegação), mostrando a aplicabilidade da representação KAOS na modelagem de sistemas mecatrônicos.
O MBRE já foi criado com base no Model Based Systems Engineering, apresentado por A. Wayne Wymore e desenvolvimentos posteriores. Foi também criado com base na modelagem GORE (Goal-Oriented Requirements Engineering e MBRE), de modo a contornar a dificuldade do desenvolvimento puramente funcional.
Portanto o ciclo começa na eliciação (e vamos discutir os problemas desta fase), e, após ter um primeiro modelo GORE começa o ciclo do MBRE. Portanto é crucial enfrentar os problemas da eliciação, encontrar os objetivos iniciais do projeto, e colocar tudo na representação KAOS. Sugerimos já em aulas passadas a utilização do Objectiver como ferramenta de suporte (usada no mercado) para reduzir o tempo de modelagem e enfrentar a curva natural de aprendizado, para os que estão fazendo isso pela primeira vez.
-
Nuseibeh, B., Easterbrook, S.; Requirements Engineering: A Roadmap, Association for Computer Machinery (ACM), 2000
-
AULAS 7
Voltaresmos à discussão sobre a formalização da modelagem dos requisitos até chegar a uma especificação, e com ela fazer a transição para a fase de design. A vantagem é evitar múltiplas interpretações sobre os requisitos, e poder discernir com mais segurança entre as propostas de solução. A formalização pode ser útil também para a síntese dos processos de teste, que pertence ao deployment, e não pertence mais ao escopo desta disciplina.
É preciso trabalhar com representações formais que possam atuar tanto na fase de requisitos como na fase de design, facilitando o processo de teransição para o design, ou "embodiment" - expressão foi cunhada no design de produtos.
A discussão será baseada em coletânea de artigos, em que se faz uma comparação entre as linguagens formais disponíveis. Marc Frapier e Henri Habrias, dois pesquisadores da Université du Sherbrooke, Canada, publicaram um artigo em 2006, revisado em 2013, comparando as diversas representações formais. Inicialmente o foco era sobre as linguagens à disposição para o desenvolvimento de software, e mais tarde foi generalizado por vários autores para a especificação de qualquer artefato, incluindo os sistemas.====================================================================================
Sobre o artigo final: milestones e cronograma previsto (pode ser modificado)
milestone 1: título e abstract (10%) entrega: 03/03
o título reflete a contribuição do artigo e o abstract resume em um ou dois parágrafos qual
a principal contribuição do artigo, de modo a atrair o leitormilestone 2: Introdução (chamamos antes de abstract estendido)(15%) entrega: 17/04
Define o problema em termos técnicos, apresenta a motivação para o artigo, a proposta de
contribuição e descreve genericamente os
resultados obtidos (portanto se for escrito no inicio precisará ser revisto depois do artigo pronto).milestone 3: Contextualização e Background (20%) entrega 30/04
Explica o porque da existência do artigo, trabalhos semelhantes, porque eles não resolveram o
o assunto ainda (pelo menos na opinião do autor), e justifica a busca por uma alternativa, além
de falar sobre o background teórico necessário para o artigo.milestone 4: Proposta de contribuição do artigo (25%) entrega 14/05
Apresenta a contribuição do artigo, no nosso caso o uso dos métodos que discutimos em um
domínio específico (que também deve ser descrito com mais detalhes).milestone 5: Finalização do artigo (30%) entrega 28/05
Análise dos resultados (se houver), discussão e avaliação sobre a aplicação dos métodos de design
propostos, prós e contras. Conclusão e trabalhos futuros (pode ser em uma nova seção) e
finalização da bibliografia.-
Artigo original do Naked Objects em versão revisada de 2021 (em inglês).
-
Artigo final, agora incluindo a seção de background
-
Aula 8
Nosso objetivo agora é minimizar a transferência semântica na passagem dos requisitos para o design. Seria importante usar uma mesma linguagem para a formalização dos requisitos e para o design, evitando erros e omissões ao passar da especificação de requisitos para as propostas de solução (design). Por isso, avaliamos na aula passada as representações disponíveis para a especificação dos requisitos e modelos de solução, buscando essa unicidade. Frapier e Harbrias analisaram um conjunto de linguagens (existem outras mais recentes, incluindo o KAOS), considerando o desenvolvimento de software e de artefatos, sem focar nos sistemas. A proposta dessa aula (e da próxima) será analisar conceitualmente a transição das especificações formais (resultantes do MBRE) para o design de soluções (no plural) por um processo de embodiment (agora aplicado a sistemas). Este processo passa pela análise das representações disponíveis, e pelo desenvolvimento acadêmico de um processo de matching para elencar soluções factíveis associadas a uma dada especificação de requisitos.
Discutiremos propostas em andamento e pesquisas em aberto e não soluções consolidadas, embora também existam aplicações práticas de em vários domínios, especialmente na manufatura inteligente e no que se convencionou chamar de "Fábrica do Futuro", ou Indústria 4.0.
Exercício 3:
O próximo exercício será considerar a classificação de Habrias e Frappier e “incluir uma linha”, onde se mostra os valores para o KAOS, com uma breve comparação com o UML (também uma representação semi-formal).
-
A leitura desta semana não é apenas um artigo de suporte ao tema da aula mas um artigo sobre uma discussão científica sobre o uso do MBRE em Mecatrônica, e do seu conteúdo multidisciplinar. Assim, poderemos associar a discussão teórica e conceitual da aula de hoje com uma análise da tendência atual da Engenharia por abordagens transdisciplinares, envolvendo a modernização tecnológica inerente ao X4.0, a tendência a serviços e sua arquitetura, a necessidade ainda mais forte de considerar múltiplas alternativas de solução.
-
David Long and Zane Scott - Vitech Co.
-
Preencher todos os atributos e propriedades para a representação KAOS, seguindo o modelo e a tabela do artigo do Frapier e Habrias.
-
Aula 9
Nesta aula vamos focar na "passagem do bastão" de forma colaborativa entre a fase de modelagem, análise e formalização de requisitos e o design preliminar, onde se consolida o HOW (que sucede o WHY e WHAT) e as bases para elencar as várias alternativas de solução que satisfazem aos requisitos. Para cada uma das soluções candidatas, deveremos checar o grau de "matching" com os requisitos, e na próxima aula trataremos dos critérios e métodos de escolha de uma delas para iniciar o design detalhado. A escolha da linguagem para formalização pode fazer uma grande diferença, dada a possibilidade de unificar a representação de requisitos e proposta de solução, facilitando o processo de design e evitando perda semântica ao mudar de representação.
A sugestão é de usar como representação formal as Redes de Petri, tanto para requisitos quanto para proposta de solução, mesmo que as respectivas redes tenham interpretação diferente. Infelizmente não teremos tempo para aprofundar a discussão sobre o formalismo em si, o que dificulta o uso prático nos exercícios, que agora começam a ficar mais complexos. Os que se interessarem em aprofundar o conhecimento sobre o formalismo devem buscar outras disciplinas dedicadas a este tema, como PMR5023 (Prof. Paulo Miyagi), PMR5402 Controle de Sistemas Discretos (Prof. Diolino Santos Fo.), ou PMR5237 Modelagem e Design de Sistemas Discretos em Redes de Petri (Prof. José Reinaldo Silva).
Milestone 4
Nosso próximo assignment será inserir a proposta de contribuição do artigo, isto é, como os conhecimentos adquiridos na disciplina irão ser inseridos nas respectivas propostas de projeto, seguindo o nosso cronograma já colocado no e-disciplinas.
-
Devemos agora incluir a seção mais importante com a contribuição do artigo para a academia (não apenas para a disciplina). Embora seja uma tarefa da disciplina é também um exercício de preparação de publicações, uma tarefa essencial no trabalho acadêmico e portanto afeito aos cursos de pós-graduação. Esta seção deve descrever claramente como os conhecimentos e as propostas discutidas na disciplina se encaixam e contribuem para os respectivos projetos escolhidos por vocês.
-
Aula 10
Trilhamos o nosso "yellow brick road" do design partindo dos conceitos e paradigmas e nos aproximamos gradativamente de modelos de aplicação, respeitando o processo de aquisição de conhecimento, que começa com a eliciação, modelagem e análise de requisitos para em seguida fazer o "embodiment" para o design preliminar (early design). O foco até aqui foram os sistemas em geral, uma tendência que promete dominar a cena em automação, seja da manufatura ou de serviços. Pressupomos ainda que no Early Design seriam consideradas as propriedades das várias alternativas de solução - NUNCA apenas uma alternativa. Assim, esperamos estar aptos a analisar as diversas possibilidades de solução, e ter "rationales" para escolher de uma delas.
Os critérios de escolha devem ser baseados nos requisitos e na especificação que resultou do MBRE. Por outro lado, os métodos disponíveis ou são muito acoplados a requisitos modelados de modo funcional e sua priorização, ou acoplados a sistemas em domínios específicos. Estaremos novamente em uma situação conflitiva entre criatividade e praticidade. Nessa aula vamos propor um "método" (baseado nas pesquisas, mas também de apelo prático) que começa com a priorização dos requisitos (um problema em aberto para o design de sistemas de forma geral, especialmente seguindo o método goal-oriented): o SWOT (que pode nos conectar também com o business process e com as tecnologias disponíveis), mantendo ainda a possibilidade de composição de objetos concretos, que levam aos Sistema de Sistemas. Um dos exemplos práticos de tal sistema são os Sistemas Inteligentes de Transporte.
-
Artigo seminal sobre system-of-systems de Mark W. Maier, 1998.
-
AI Techniques for Software Requirements Prioritization, Alexander Felfernig, Graz University of Technology, Austria
-
Faça o dowload do softwares Objectiver para Mac
-
Faça o download do software Objectiver para Windows.
-
Video sobre os primeiros passos usando o Objectiver.
-
-
Aula 11
Chegamos ao final do curso e nesta aula vamos destacar um dos motivos para o desenvolvimento feito até aqui: a completa fusão entre sistemas artificiais e o que se chama normalmente de "human centered approach" ou "personalized mechatronics". Nesta abordagem, sistemas (sejam simples sistemas de controle, com automação inteligente, ou System of Systems) teriam que se tornar colaborativos, agindo em plena conexão com o seu "usuário". Nesse caso, o usuário assume um papel duplo: pode ser um agente externo que apenas recebe o serviço, ou pode ser parte do sistema, como nos smart grids e em alguns sistemas de healthcare. A Ciência de Serviços (Science Service) e o Model-Based Systems Engineering se juntam para dar conta de todas essas categorias de sistema de serviço e respectivas transações com usuários e outros sistemas.
O termo "Serviço" é bastante usado e desgastado. Portanto precisamos ter cuidado com a sua definição como um "objeto" de estudo e parte do desenvolvimento de sistemas automatizados. Precisaremos abordar com cuidado o processo de design desses sistemas, especialmente quando automatizados e de grande porte. Nesse caso podemos fazer um paralelo com os Sistemas de Sistemas (Systems of Systems) compondo o que chamamos Service of Services (SoServ), isto é, um serviço que é composto de outros serviços de forma modular, como fizemos com os (naked) objetos.
Assim, o system thinking, evolui para o System-of-Systems thinking, e agora para o Service-of-Services thinking, uma tendência para o design de sistemas automatizados interativos e colaborativo.
================================================================
Agradeço a todos por ter escolhido este curso e espero sinceramente ter contribuído, seja conceitualmente, tecnicamente, ou introduzindo métodos e conceitos para uma abordagem sistêmica e metodológica aplicável aos respectivos trabalhos de dissertação e tese.
Reinaldo
-
Submeta o artigo completo no formato PDF