Programação
-
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.
-
Texto base sobre Systems Engineering
-
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...
-
Transparencias da Aula 1
-
Faça o upload da sua monografia sobre o método estruturado.
-
Discutiremos agora as diferenças principais entre uma abordagem analítica e uma abordagem sistêmica para o design, tentando deixar claro vantagens e desvantagens de cada uma. Como se poderá ver ambas as abordagens funcionam perfeitamente e existem casos em que uma é mais adequada do que a outra. No entanto pensando que os desafios atuais nos colocam diante do desafio de tratar o design de artefatos que exigem uma abordagem mais flexível e multidisciplinar, podemos pensar que uma abordagem sistêmica é mais adequada e mais presente. Mas é preciso ter em conta que para situações com domínio fechado com pouca interação contextual, e onde se pode minimizar o efeito holístico, isto é, onde o comportamento coletivo do sistema é o resultado direto dos componentes e das relações entre eles, a abordagem analítica é apropriada, especialmente quando se trata de controle contínuo, circuitos lógicos, e mesmo projetos com base em Elementos Finitos, etc.
Exercícios para a próxima aula 
-
Transparencias da Aula2.
-
Faça o upload da versão atualizada do seu artigo final
-
Nesta 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.
Não esqueçam a próxima etapa de elaboração do artigo. Nesse caso vocês precisam produzir mais uma seção onde se faz a proposta de contribuição e se explica claramente qusis os conceitos da disciplina serão utilizados no seu artigo.
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. -
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.
-
Aula 7
Nesta aula vamos trabalhar a possibilidade de antecipar a formalização mesmo dentro da fase de requisitos e também investigar mais de perto os benefícios que uma foamalização pode trazes para um projeto de sistemas, especialmente para sistemas automatizadods e orientados a serviço. Para isso vamos investigar de forma comparativa várias linguagens e representações - formais e semi-formais - na tentativa de enxergar o que tem por trás de cada uma delas. Assim, porderemos orientar a escolha de uma ou outra linguagem, ao tempo em que poderemos ser mais rigosos com as expetativas levandas para esta formalização, evitando erros por ter subestimado ou superestimado a força de algumas formalizações.
Um dos métodos que precisam de uma base formal é a reutilização de designs. Como vamos ver nesta aula a reutilização depende da possibilidade de se fazer uma transferência semântica entre os domínios de aplicação e também entre a descrição geral dos projetos (e de seus objetivos). Existem várias dificuldades técnicas e acadêmicas para se conseguir um bom resultado nesta empreitada, onde se destaca os resultados práticos do design orientado a objetos e as tentativas acadêmicas de se usar teoria de metáforas referenciar um projeto no domínio. Este é um tópico ainda em aberto em pesquisa, e, infelizmente, uma abordagem mais profunda deste tema está fora do escopo do nosso curso.
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.
Artigo Final
O próximo milestone para o artigo será na próxima aula. O artigo (que deve sempre ser revisado, tem título, autores, abstract, introdução, e agora deve ter também uma próxima sessão onde a proposta de contribuição é apresentada claramente. Ao mesmo tempo a bibliografia deve evoluir, na medida em que se sinta a necessidade de citar estes trabalhos durante a argumentação da proposta.
-
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 que têm até aqui, especialmente o capítulo 2 que falava do que tópico do curso seria usado como contribuição do artigo. No momento que fizeram esta escoha tinhamos 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. Ainda não tinhamos entrado mais a fundo no GORE (Goal oriented Requirements Engineering). Agora que fizemos um tour e alguns exercicios com KAOS e discutimos as bases do i*, seria bom rever esta decisão e conforme for você deverá rever o capítulo 2 para esclarecer isso e incluir uma apresentação curta sobre o que vai utilizar : Análise estruturada, KAOS e/ou i*, ou UML e algo ainda não definido que veremos adiante. Note que agora é que vamos entrar no assunto de Projeto de Sistemas como recomendado pelo INCOSE. Se não houve alteração significativa na sessão 2, siga adiante para a próxima, que descreve cada um dos resultados teóricos sobre o qual você vai basear o seu artigo.
-
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 simplemente 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.
(deadline: dia 29/11, terça-feira ao meio-dia)MILESTONES Agora o seu artigo final deve atingir uma fase de maturidade e o próximo milestone requer um artigo praticamente completo onde a aplicação de técnicas de modelagem e design já possa ser avaliada. Faremos a simulação de um processo de “submissão”, e agora os comentários serão aqueles típicos de um revisor.
-
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. Novo Milestone
Somente dois de vocês apresentaram a proposta de artigo esta semana. Pelos menos estes dois têm já um feedback sobre o que precisa ser melhorado e até como fazer isso. Teremos assim um novo milestone para o dia 13 de dezembro próximo (não teremos aula neste dia) e o artigo final fica para o dia 20/12 em caráter inadiaável.