Kursthemen
-
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. Acompanharemos palestras e material divulgado por empresas conhecidas do mercado internacional pelo tratamento dado à modelagem de sistemas, como Vitech e IBM.
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.
-
Entidade internacional que congrega pesquisa e desenvolvimento em Systems Engineering
-
Aula remota pelo sistema Google Meet.
-
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.7 é de outubro de 2022.
-
Slides da Aula em PDF
-
Esta semana introduziremos uma definição mais detalhada de sistemas, seguindo um modelo geral da teoria de sistemas e como uma representação do hólon sistema. Definiremos design de sistemas e um ciclo de vida canônico, fazendo um paralelo com outras propostas, baseados em diferentes paradigmas, geralmente feitos para produtos (ou software especificamente). O desafio real é ter uma primeira abordagem 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. Na verdade o que temos hoje é o resultado de anos de experiência e pesquisa, por isso é importante referenciar métodos e paradigmas que parece "antigos". 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 da 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.
-
Faça o upload de um texto em PDF sobre como você pensaria (e planejaria) um projeto de sistema de controle de acervo.
-
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: título, autores, abstract e palavras-chave. No máximo uma página.
-
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 que nos capacitar para enfrentar projetos complexos de sistemas, especialmente de sistemas automatizados. O domínio do design (composto pelo environment + problema a ser resolvido) é construído com base em paradigmas (e aqui consideramos apenas os mais proeminentes: o método estruturado e o design orientado a objetos), que dão suporte aos métodos da Engenharia de Sistemas. Sobre arcabouço vamos discutir os detalhes práticos do ciclo de vida de sistemas começando pelos requisitos.
O nosso foco será portanto consolidar a ligação entre conceitos, formalismo e boas práticas, consolidados em um ciclo de vida, 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 vamos usar 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 sistema de controle de acervo (biblioteca) que vocês fizeram depois da primeira aula. Além da intuição, que certamente já foi utilizada, tentem agora transformar o que fizeram em "modelo", seja usando uma linguagem que já dominem (UML, ou outra de propósito específico) ou usando a linguagem natural para tentar "formalizar" o modelo. O objetivo do exercício é justamente perceber na prática as dificuldades em formular um "modelo", além de entender melhor a sua definiçã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.
-
AULA - 5
Vamos dar mais um passo adiante na discussão sobre Engenharia de Requisitos e sobre uma proposta de processo do D-Lab, o Model Based Requirements Engineering, e sua aplicação no ciclo na modelagem de sistemas. Faremos um paralelo com o exercício de modelagem de um sistema de controle de acervo, usado nos exercícios práticos. A idéia é ter um processo de Engenharia de Requisitos aderente ao MBSE, de uso prático.
A proposta do MBRE é baseada no Model Based Systems Engineering, apresentado por A. Wayne Wymore, mas, o MBRE e tentaremos mostrar sua aderência de forma convincente sem entrar nos aspectos formais, focando primeiramente nos conceitos e na comparação mais intuitiva entre os métodos convencionais e novas propostas: GORE (Goal-Oriented Requirements Engineering e MBRE). Começaremos discutindo a abordagem funcional clássica em UML e a possibilidade de mudar para uma proposta alternativa, orientada a objetivos.A alternativa orientada a objetivos foi definida e desenvolvida neste século, denominada goal-oriented requirements engineering (GORE). Embora seja um método especialmente voltado para requisitos e não especificamente para Systems Design, o GORE se apresenta como uma alternativa para o ciclo de requisitos onde a abordagem puramente funcional é substituída por uma abordagem orientada a objetivos, mais abrangente. Também usa "visual diagrams", mostrados na figura abaixo, denominados diagramas KAOS (Knowledge Acquisition and Object Specification ou Keep All Objectives Satisfied, como dizem os alunos).
Exercício 3: O exercício agora é modelar os requisitos iniciais para o sistema de controle de acervos usando UML. A experiência é fazer uma escolha apropriada dos diagramas a serem usados, sem se restringir ao "use-case"ou somente à parte comportamental.
-
Slides da Aula5
-
Faça o upload do seu exercício 3. Agora o projeto do controle de acervos terá que ser modelado em UML.
-
Nuseibeh, B., Easterbrook, S.; Requirements Engineering: A Roadmap, Association for Computer Machinery (ACM), 2000
-
Aulas 6
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 como uma representação alternativa, o KAOS (Knowledge Acquisition and Objective Specification) . Discutiremos os princípios gerais desta formulação à partir desta aula, mas vamos também comparar as duas representações para tornar a discussão mais concreta e mais próxima da aplicação. Nesta aula vamos nos concentrar no método KAOS que tem como suporte computacional o Objectiver. Discutiremos os conceitos básicos da modelagem de requisitos por objetivos, destacando a adaptação desse modelo para sistemas. Discutiremos a possibilidade de explorar este modelo para o que chamamos de Model-based Requirements Engineering. Finalmente, baseado no artigo de Huzan Al-Subaye e Thomas Maibaum (leitura suplementar), vamos abrir uma discussão (para a próxima aula) para avaliar se o método KAOS realmente satisfaz aos postulados básicos da Engenharia de Requisitos, especialmente no que diz respeito à captura dos REOs (Requirements Engineering Objectives).
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.
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 7
Integrando Mode-based Systems Engineering, Tricotyledon Systems Design and Model-based Requirements Engineering 
Embora não tenhamos entrado nos detalhes do formalismo matemático do MBSE, temos a clara noção do relacionamento deste formalismo com a Teoria de Sistemas e com os paradigmas utilizados no "Systems Design". Na verdade exploramos os paradigmas gerais de design propostos pela Ciência da Computação (o método estruturado e o paradigma de design orientado a objetos). Porém, ficou uma questão em aberto: os métodos para modelagem e análise de requisitos foram desenvolvidos e geraram ferramentas eficientes para o design de software, mas será que seriam aplicáveis com a mesma eficiência ao design de sistemas? Especialmente quando passarmos de uma abordagem muito geral para os detalhes práticos? Como isso se reflete no uso do KAOS?
Nesta aula vamos aprofundar esta questão enquanto avançamos também no entendimento do Model-based Requirements Engineering (MBRE), especificamente no formalismo de verificação que nas aulas anteriores foi somente mencionado: as Redes de Petri. O uso de abordagens de propósito geral na modelagem e análise de requisitos de sistemas (seja em UML ou em KAOS) é objeto de pesquisa e de artigos acadêmicos e de white papers veiculados no mercado A Vitech trabalha especificamente no V model (ou BigV) e na especificação de requisitos em UML. O D-Lab e outros grupos de pesquisa (e algumas empresas) usam o KAOS e a abordagem orientada a objetivos.
O uso de linguagens formais para a especificação de requisitos e seu uso como input para o processo de design será o objetivo da nossa próxima aula.
Exercício 4:
No exercício 2 vocês tentaram ver o sistema de acervo com um sistema e não um software (aplicativo, BD, etc.). O desafio no Exercício 3 foi modelar os requisitos desse sistema usando uma linguagem diagramatica de propósito geral: UML. Agora a proposta é modelar o mesmo artefato como um sistema (de serviço) usando o KAOS e o Objectiver. O mas importante será perceber as diferenças entre cada abordagem, já que o artefato é o mesmo.
-
Faça o upload da nova versão do seu modelo para o projeto do controlador de acervo em KAOS. Pode ignorar o texto reminiscente dos exercícios anteriores. Vamos nos concentrar nesta versão e na sua validação como um modelo.
-
AULAS 8
Nesta aula vamos finalizar o módulo 2 (modelagem de requisitos) e nos preparar para passar para a fase de design (preliminar), buscando uma transição suave entre elas, baseada na modelagem formal. Se esta comunicação for preservada sem "perdas semânticas", podemos esperar um projeto com risco mais baixo, e esperar que o mesmo princípio se aplique no design detalhado e deployment). A formalização pode ser útil também para a síntese dos processos de teste, embora esta parte não pertença ao escopo desta disciplina.
Portanto, a vantagem da antecipação da formalização para a fase de requisitos é buscar a consistência do processo desde o início e potencializar uma transferência segura para as demais fases. É preciso trabalhar com representações formais que possam atuar tanto na fase de requisitos como na fase de design, facilitando o processo denominado "embodiment" (a expressão foi cunhada no design de produtos), reduzindo assim a necessidade de transferência semântica entre representações distintas.
A discussão de hoje é baseada em um livro (uma coletânea de artigos), em especial em um artigo em que se faz uma comparação entre as linguagens formais disponíveis. Henri Habrias e Mak Frapier, dois pesquisadores da Université du Sherbrooke, Canada, de 2006, revisado em 2013. 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.
Tanto o estudo como sua extensão apontam para OMT&B, Redes de Petri e Redes de Petri Orientadas a Objeto como as representações formais mais promissoras para o design de sistemas complexos, como mostra a figura acima. Justificaremos a preferência pelas Redes de Petri.-
Um artigo interessante que comentei durante a aula. Está parcialmente ligado ao curso, porque trata-se de uma discussão sobre a organização do processo de elaboração de um PhD (serviria para mestrado também), usando técnicas de design (e design sprint) e um canvas para visualização do processo. Os canvas são usados em design de startups e não os incluímos na discussão da disciplina porque estamos de fato trabalhando projetos e médio porte pra cima.
-
Artigo original do Naked Objects em versão revisada de 2021 (em inglês).
-
Aula 9
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 passa da especificação de requisitos para as propostas de solução (design). Por isso, avaliamos as representações disponíveis para a especificação dos requisitos e modelos de solução, buscando sobretudo essa unicidade. Frapier e Harbrias analisaram um conjunto de linguagens (existem outras mais recentes), considerando o desenvolvimento de software e de artefatos, sem focar nos sistemas. A proposta dessa aula (e talvez 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, isto é, para elencar soluções factíveis para uma dada especificação de requisitos.
Estaremos discutindo propostas em andamento e pesquisa 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.
Novo Milestone:
O próximo exercício será incrementar o artigo, agora com uma sessão sobre o background teórico da proposta do artigo e motivação (detalhando o que já foi proposto na introdução).-
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.
-
Continuando com o artigo, agora é preciso ter uma nova versão, incorporando todas os comentários até aqui, contendo, além do título, autores, abstract e introdução, uma seção de motivação e background, onde se detalha a proposta, a motivação (já apresentada na introdução) e justifica-se academicamente a proposta do artigo com referências bibliográficas. Embora não seja plenamente aplicável a todos os casos, é preciso incluir também a metodologia, isto é, como se vai fazer no restante do artigo (ou como foi feita a pesquisa) para atingir os resultados esperados.
-
Aula 10
Nesta aula vamos dar mais um passo para "passar o 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) elencando 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 mais tarde 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 por 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 é preparar um primeiro draft do artigo final incluindo a proposta de uso das técnicas discutidas no curso, mesmo que ainda sem análise de resultados e conclusão. Mas é fundamental que o artigo tenha a motivação, objetivo, background (as técnicas ou teorias utilizadas), incorporando as observações e criticas dos milestones anteriores.
-
Aula 11
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. O foco até aqui foram os sistemas em geral, uma tendência que promete dominar a cena dos sistemas voltados à cultura da "empresa", com métodos e processos internos. Pressupomos ainda que no Early Design seriam consideradas várias alternativas de solução e NUNCA apenas uma. Com isso se espera poder analisar as diversas possibilidades e ter "rationales" para a escolha de uma delas. No entanto, a continuidade do processo pressupõe também a escolha de uma delas e critérios precisam ser elaborados para isso.
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. Vamos nessa aula propor um "método" (portanto estaremos no domínio da pesquisa e não das práticas de mercado) que compõe a priorização dos requisitos (um problema em aberto para sistemas modelados 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 nos levam aos Sistemas de Sistema. 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
-
-
Aula 12
Chegamos ao final do nosso curso e nesta aula vamos destacar um dos grandes 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.
"Serviço" pare (e é de fato) um termo bastante usado e desgastado, portanto precisamos ter cuidado na sua definição como um "objeto" de estudo e desenvolvimento para sistemas automatizados. Em especial, precisaremos abordar com cuidado o processo de design de tais sistemas, especialmente quando se trata de sistemas automatizados e até de grande porte, compondo o que chamamos System of Services (SoServ), trabalhando sobre o conceito de System of System (SoS).
Assim, o system thinking, evolui para o System-of-Systems thinking, e agora para o System-of-Services thinking, uma tendência para o design de sistemas em geral.
================================================================
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
