Quadro de Notas

Vejam a relação de notas (conceitos) para os alunos aprovados.

Reinaldo

Introdução: O problema do design de sistemas

Nesta aula discutiremos o problema geral e conceitual do processo de design de sistema, alguns aspectos da teoria de sistemas de Ludwig von Bartalanffy em 1940, e a motivação da disciplina, que visa entender aos novos desafios do design dos SoS (System of Systems) e dos sistemas de informação que de fato são Sistemas de Serviço.



Discutiremos ainda o processo de design como inerente ao ser humano e como a atividade básica e primeira da Engenharia e como esta se coloca no novo contexto e nas novas demandas interdisciplinares da Engenharia Moderna, especialmente para os sistemas automatizados.

---

Os alunos devem desde já achar um tema base para o trabalho final, que irá nortear a avaliaçào da disciplina. Preferencialmente este tema deve estar relacionado com as respectivas teses e dissertações.

A abordagem sistêmica

Nesta aula avançaremos na discussão sobre a definição de sistemas, e do que chama sistemas discretos relacionais, descritos formalmente com base na teoria de conjuntos. Esta é a base para se entender o formalismo sistêmico, especialmente quando comparado com a abordagem analítica. Alguns exemplos serão mencionados como ilustração.

Em seguida esta abordagem será ampliada para colocar como desafio a sua aplicação no projeto de desenvolvimento de sistemas modernos, sejam voltados para serviço, sejam os sistemas de sistemas. Uma proposta de grande apelo histórico, e ainda hoje considerada de grande apleo prático é a de Mark Fox para o desenvolvimento de sistemas distribuídos, cujo esquema geral é mostrado abaixo.




Reinaldo

O problema dos requisitos

Nesta semana vamos trabalhar com as definições sobre o processo de projeto, após termos, de forma sucinta, passado pela definição geral de sistemas, como um conjunto de agentes que têm um conjunto de relações entre si. Este pode ainda ser um conjunto de conjuntos, onde cada um deles é um sub-sistema.

A fase mais sensível do processo de projeto é certamente a fase de requisitos, originando o que hoje se chama de Engenharia de Requisitos (ER). Esta consiste da fase de eliciação ou captura dos requisitos, à modelagem destes mesmos requisitos e finalmnte à análise e verificação. Pretende-se naturalmente que este processo seja parcialmente computável e que portanto existem sistemas de apoio à ER. Mas, infelizmente a grande maioria destes sistemas não inclui um apio efetivo à fase de análise e veririficação de requisitos.

Este é um problema sério dado que compromete todo o restante do projeto, cuja taxa de sucesso neste momento não é das melhores. Este assunto será tratado na aula desta semana à luz dos métodos baseados em conhecimento.

Modelagem e análise de requisitos

Nesta aula trataremos mais diretamente do problema da modelagem e análise de requisitos. O texto do Nuseibeh, que foi a leitura da semana passada será ainda bastante útil e alguns comentários serão feitos baseados em outro artigo, recomendado como leitura para esta semana.

A tonica da discussão é a separação entre os métodos e análise de requistos e os métodos e paradigmas de design. Na verdade as técnicas de análise podem ser adaptadas aos métodos e paradigmas. Consideraremos portanto dois grandes blocos de métodos de análise: os métodos de verificação da dinâmica (especialmente para o caso de sistemas) e os métodos baseados em conhecimento, que pressupõe o uso de técnicas de Inteligência Artificial. Neste último caso, este bloco será mencionado mas estará fora do escopo desta disciplina, uma vez que não é exigido um disciplina de IA como pre-requisito. Entraremos portanto mais detalhadamente na verificação da dinâmica, agora sugerindo o uso das Redes de Petri como suporte para este tipo de análise. Um exemplo clássico, baseado no comportamento de uma máquina ATM, será mostrado.



Reinaldo

Validação e gerenciamento de requisitos

Nesta aula vamos entrar na discussão sobre a validação e o gerenciamento de requisitos, enfatizando um problema que tenha sido destacado tanto na academia quanto no prática, desde os anos 90: o "traceability". No caso se trata de ter um ciclo evolutivo para cada requisito, desde a sua eliciação - podendo ainda ter um mapeamento para a classe de stakeholders responsável pela inserção - até o correspondente à especificação.

Em geral o traceability é parte do gerenciamento dos requisitos e pode ser suportado por várias ferramentas que se dedicam ao CARE (Computer Aided Requirements Engineering). Outro aspecto de especial importância é a matriz de requisitos que implementa e mapeia a relação de dependência entre requisitos, servindo de base para a análise de impacto, cada vez que algum requisito precisar ser modificado.

A instabilidade dos requisitos será ainda um tema de discussão nesta aula onde, além de uma terminologia sobre os diversos tipos de requisitos, vamos inserir a noção de requisitos estáveis (enduring requirements) e requisitos voláteis (volatile requirements), que podem se modificar ainda durante o processo de modelagem e análise de requisitos. Tal instabilidade é a grande responsável pelas dificuldades, tanto na contratação quanto na execução do trabalho de engenharia de requisitos, especialmente de sistemas de grande porte.

Especificações

Esta semana vamos discutir o problema do fechamento da fase de Requisitos, que culmina com a produção de especificações. Estas, nada mais são do que os requisitos documentados, após a sua modelagem e validação, em que os processos de análise e avaliação dos requisitos não conseguem mais fazer evoluir o documento de requisitos.

Portanto, admitimos que, neste ponto, temos um conjunto de requisitos sem contradições, onde os aspectos não -funcionais foram devidadmente inseridos, as restrições, e que está pronto para ser formalizado, segundo alguma representação formal. Resta garantir o processo que foi seguido, a ausencia de falhas, e escolher a reprsentação formal apropriada. Discutiremos portanto os atributos para se ter uma base de escolha desta representação segundo um artigo recente de Frapier e Harbrias. A leitura da semana será justamente este artigo.



Reinaldo

RATIONALES

Esta semana encerraremos o nosso foco na fase inicial do desgin, a Engenharia de Requisitos, não só com a discussão sobre linguagens e representações formais - onde vamos agora inserir o SysML - mas mudando o nosso enfoque sobre o problema. Vistas as abordagens clássicas, teoricamente independentes de método e da metodologia e dos paradigmas de design, vamos agora buscar soluções inovadoras, tanto do ponto de vista da pesquisa na área do Design de Sistemas, como do ponto de vista da automação.

Portanto para fechar o processo questionaresmos em primeiro lugar o que deve estar faltando e porque, apesar do esforço feito até aqui ainda nos parece que o que foi proposto não teria sucesso na prática. O que está faltando neste caso são os rationales, que resmem a alma e o foco principal das tomadas de decisão na fase inicial do processo. Por que isso é importante? porque gostaríamos de resgatar esta informação no futuro, e até reutilizá-la. Portanto precisaremos ainda analisar a real dificuldade de fazer isso também. Esta possibilidade depende de fatores como a capacidade de encontrar uma componente reutilizável ainda na fase de eliciação e análise de requisitos, ou, até a fase do término das especificações (justamente a fase que estamos fechando agora). O importante seria ter um banco com os casos reutilizáveis e um processo de busca condizente.

Design orientado a modelos

Continuando a nossa discussão da aula passada notamos que o que estava "faltando" em todo o proceso era justamente esta "visão de todo" do artefato ou sistema que queremos construir. Isso parece ligeiramente em contradição com o inicio do processo, onde o mais importante é capturar os diferentes pontos de vista e uma visão orientada a modelos mas com diferentes enfoques é a mais indicada. Na verdade isto faz parte da natureza do processo de design de sistemas. E, o processo de antecipação da formalização passa também por ter um modelo unificado antes mesmo de chegar a uma especificação fehada.

Assim, a figura associada ao modelo do sistema itSIMPLE parece ter um significado mais profundo do que parecia: o processo de design, assim como o processo de Engenharia de requisitos passa por mudanças de representação (e assumimos que não é possível, embora seja desejável, usar somente uma representação), que poderiam ser mediadas pela XML. Nesse caso UML seria uma da "pontas" com seus múltiplos diagramas, mas poderiamos ter por exemplo redes de Petri na outra, o PDDL (para o caso de problemas de planning) ou ainda o B (ou Z), na outra "ponta".



Mas esta questão pode ser mais complicada do que parece, e na aula seguinte vamos prosseguir na discussão sobre os métodos de design de sistemas, sempre tendo em mente a possibilidade de ter uma sucessão de modelos baseados nestes métodos. Em outras palavras todo o método proposto passa a ser agora orientado a modelos, como indica a figura abaixo, que sintetiza a nossa discussão.

Paradigmas e métodos para o design de sistemas

Como vimos na aula passada, tudo parece ir na direção de que devemos ter um processo mais sistemático e orientado a modelos para design de sistemas. Com isso poderíamos ter a oportunidade de ter sempre uma visão unificada do artefato enquanto se dá prosseguimento ao aumento da informação sobre ele. É preciso ainda estar atento às oportunidades de se antecipar a formalização, mesmo dos requisitos.

Entretanto nos falta discutir qual seria a influência dos métodos de design em um processo orientado a modelos. Nesta semana começaremos a discussão dos métodos e paradigmas de design em ordem cronológica, precedidos de uma breve discussão sobre a introdução deste termo, associado ao trabalho do fisico Thomas Samuel Kuhn (A estrutura das revoluções científicas), de 1962.

A análise estruturada é o primeiro método a ser discutido, e com ele o paradigma de estruturação, resumiremos em alguns conceitos básicos. Uma representação atualizada persiste até hoje e é o sistema de representação preferido das forças armadas americanas, certamente um bom stakeholder. Um exemplo do IDEF0 aplicado à modelagem funcional de um sistma simples de matricula de alunos é mostrado na figura a seguir.



Em seguida, o paradigma mais difundido e digno de nota é o de objetos, que já foi discutido nas aulas anteriores. Entretanto nos interessa explorar agora os aspectos de complementariedade dos objetos com os módulos e as tentativas anteriores de inserir o "separation of concerns". Um ponto ainda em aberto na discussão é então a perspectiva de ter um processo orientado a modelos (model driven) e também orientado a objetos (que é a proposta atual da OMG).

Mas, certamente este é um avanço no tratamento dos métodos de design de sistemas, e que, além disso previlegia o reuso, deixando ainda a descoberto o problema da representação de rationales, discutida na aula passada. Para este caso, embora esteja fora do escopo da disciplina, recomendamos o uso de "design patterns". Um breve olhada na figura a seguir, que mostra pictoricamente a relação de eficiência entre métodos de design no que se refere ao reuso, mostra claramente a razão desta distinção.

Não haverá aula

Estudo dirigido sobre o método orientado a objetos

Axiomatic Design

Nesta aula discutiremos o Axiomatic Design, uma proposta consistente dos anos 90 para formalizar, na medida do possível o processo de projeto, mesmo admintindo ainda que a fase inicial, que agora chamaresmos de sintese dos atributos do usuário, seria ainda informal.

O universo de projeto é dividido em quatro domínios: o dominio do usuário onde temos os Costumer Atributes (CAs), o domínio funcional, definido pelos Functional Requerements (FRs), o mundo físico, definido pelos Design Parameters (DPs), e finalmente pelo dominio dos processos, definido pelos Process Variables (PVs). Os dois primeiros domínios formam a base de definição do artefato, que responde à pergunta "o que?" seria o artefato desejado. Os dois últimos domínios poderiam responder à pergunda "como?" satisfazer os requisitos desejados.

Nesta primeira aula nos concentraremos nos conceitos e definições do Axiomatic Design, sem fazer distinção entre a sua aplicação para produtos (manufatura) ou para sistemas. Na aula que vem direcionaremos a discussão para sistemas, que é o foco de interesse da disciplina.

Axiomatic Design for Systems

Nesta aula trataremos dos conceitos e teoremas do Design Axiomático, mas apliado a sistemas. Nesse caso temos um conjunto de teoremas que cobrem as boas práticas e o conhecimento acumulado no design de sistemas. Veremos como os conceitos básicos de sistemas colocados na nossa segunda aula, agora podem ser re-interpretados mais profundamente e se encaixam perfeitamente nos teoremas do Axiomátic Design.

Este teoremas, por sua vez, formam um fremework onde os passos a serem incluidos parecem agora mais claros e transparentes, evitando a ambigidade característica do processo de design. Os critérios de qualidade e de escolha de alternativas de design também afloram naturalmente dos teoremas e corolários. Finalmente, a noção de qualidade associada ao design é enfaizada, acenando ainda com um critério para a escolha de soluções.

Entretanto, há ainda algumas críticas ao AD, e é parte inerente ao processo destacar estas criticas em sala. Teremos portanto um espaço no final da aula para esta discussão.

Reinaldo

Sistems (service) Axiomatic Design

Nesta última aula vamos encerrar o nosso curso abordando um último tópico de interesse que seria a categoria de sistemas conhecida como Sistemas de Serviço. Trata-se na verdade de uma sub-classe dos Systems of Systems (SoS), em que o paradigma básico muda do desenvolvimento de produto para o desenvolvimento de sistemas, o que é uma mudança conceitual significativa.